From xen-devel-bounces@lists.xenproject.org Mon Jun 01 00:18:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 00:18:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfY9i-0004dn-5H; Mon, 01 Jun 2020 00:18:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfY9g-0004dh-U9 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 00:18:16 +0000 X-Inumbo-ID: 6327681c-a39d-11ea-9dbe-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6327681c-a39d-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 00:18:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=q14WyfTg+rbPiCt6Ll+4c+GhDY64mLlNrZT2CKlawHw=; b=7DSiHb59alR848vzfe1+pXx39 fPs2WJ55Faa2YBNMKFeRY8QxWQV6bynlN/9SQPDvBnAsbxzyviZ/3jg26mY0dofmmFC/IvvmaR3Ip lAmO/o4n/zKEYbCVIparUm3O6HvUBr6J/DbqwyOiYLHKGJGX3dLRiBZ3G+p4+I98T3Rig=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfY9e-000371-Ut; Mon, 01 Jun 2020 00:18:14 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfY9e-0007Pc-Jc; Mon, 01 Jun 2020 00:18:14 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfY9e-0007dD-J0; Mon, 01 Jun 2020 00:18:14 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150587: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ad33a573c009d72466432b41ba0591c64e819c19 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Mon, 01 Jun 2020 00:18:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150587 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150587/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen ad33a573c009d72466432b41ba0591c64e819c19 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 3 days Failing since 150465 2020-05-29 09:02:14 Z 2 days 25 attempts Testing same since 150515 2020-05-30 01:00:47 Z 1 days 15 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1196 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 01:59:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 01:59:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfZiv-0005WC-ER; Mon, 01 Jun 2020 01:58:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfZiu-0005W7-07 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 01:58:44 +0000 X-Inumbo-ID: 69ee12dc-a3ab-11ea-aacf-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 69ee12dc-a3ab-11ea-aacf-12813bfff9fa; Mon, 01 Jun 2020 01:58:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mZLvnpaoJg1VmjOAD4PBwCFPZM/bHVgANwwapITr/mQ=; b=Vb1PWQ2zDIJHYRwcF2p3Vxz2D wnYwmsJUV7LqqF/u5d/F3KSaTVHzigwatdm47pMOERW5jqzhHRhVc9japCW+3K1Hvz8zQxAW65j6H WdjxzD9YdfM+ba6puHAFukdYjim4aRfuP5m3BHTZgSKJhO3a1O8nS98rrqLu1y+ZclbmQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfZip-0006Sw-7J; Mon, 01 Jun 2020 01:58:39 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfZio-0003e0-VE; Mon, 01 Jun 2020 01:58:39 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfZio-0007ey-To; Mon, 01 Jun 2020 01:58:38 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150579: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-shadow:guest-localmigrate/x10:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=bdc48fa11e46f867ea4d75fa59ee87a7f48be144 X-Osstest-Versions-That: linux=ffeb595d84811dde16a28b33d8a7cf26d51d51b3 From: osstest service owner Date: Mon, 01 Jun 2020 01:58:38 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150579 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150579/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-shadow 18 guest-localmigrate/x10 fail REGR. vs. 150556 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 150556 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 150556 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150556 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150556 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150556 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150556 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150556 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150556 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150556 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150556 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: linux bdc48fa11e46f867ea4d75fa59ee87a7f48be144 baseline version: linux ffeb595d84811dde16a28b33d8a7cf26d51d51b3 Last test of basis 150556 2020-05-31 04:53:49 Z 0 days Testing same since 150579 2020-05-31 18:08:42 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Al Viro Alexander Dahl Alexander Potapenko Alexei Starovoitov Andy Lutomirski Antony Antony Arnd Bergmann Aya Levin Björn Töpel Bjørn Mork Borislav Petkov Chris Lew Chris Packham Chuhong Yuan Cong Wang Daniel Borkmann Daniele Palmas David Ahern David S. Miller Davide Caratti Dexuan Cui Edwin Peer Eric Dumazet Fugang Duan Guillaume Nault Hangbin Liu Heinrich Kuhn Ingo Molnar Jay Lang Jay Vosburgh Jens Axboe Jia He Joe Perches Johannes Berg John Fastabend Jonas Falkevik Jonathan Lemon KP Singh Linus Lüssing Linus Torvalds Maor Dickman Marcelo Ricardo Leitner Mark Bloch Michael Braun Michael Chan Michael Ellerman Nathan Chancellor Nicolas Dichtel Nikolay Aleksandrov Pablo Neira Ayuso Paolo Abeni Peter Zijlstra Petr Mladek Phil Sutter Pradeep Kumar Chitrapu Qiushi Wu Roi Dayan Sabrina Dubroca Saeed Mahameed Simon Horman Stefano Garzarella Steffen Klassert Tal Gilboa Thomas Falcon Thomas Gleixner Vasundhara Volam Vinay Kumar Yadav Vlad Buslov Vladimir Oltean wenxu Willem de Bruijn Xin Long Yang Yingliang Yonghong Song jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow fail test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 3074 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 03:54:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 03:54:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfbWc-0006r8-9V; Mon, 01 Jun 2020 03:54:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfbWb-0006r3-EX for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 03:54:09 +0000 X-Inumbo-ID: 8b527020-a3bb-11ea-aae0-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8b527020-a3bb-11ea-aae0-12813bfff9fa; Mon, 01 Jun 2020 03:54:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=15ND6z5VgHlnASd4U8IHK2j//8z47gcdRaxELYBpc/E=; b=Cp0psZTHa7jUps4gODPre8yhR 3c+3vhmOlJgqH+854uKJJDbh4YXhOdwpoFejIxK/rZLTe9PLu9MP+IUVOJqeB1IpfZkx5868Nml+i wR8dZD9rlPXcPSXezlRZ9geD/Bq3dpFwoRNvLMOSwl6Yqk3lahd9O1OCPuF0DxtYYWA2c=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfbWZ-00061M-Ox; Mon, 01 Jun 2020 03:54:07 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfbWZ-00087x-Be; Mon, 01 Jun 2020 03:54:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfbWZ-0002Rm-9O; Mon, 01 Jun 2020 03:54:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150588: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ad33a573c009d72466432b41ba0591c64e819c19 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Mon, 01 Jun 2020 03:54:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150588 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150588/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen ad33a573c009d72466432b41ba0591c64e819c19 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 3 days Failing since 150465 2020-05-29 09:02:14 Z 2 days 26 attempts Testing same since 150515 2020-05-30 01:00:47 Z 2 days 16 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1196 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 04:12:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 04:12:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfbnb-0000Lp-R2; Mon, 01 Jun 2020 04:11:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfbna-0000Lk-Sg for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 04:11:42 +0000 X-Inumbo-ID: ff97dc2a-a3bd-11ea-9947-bc764e2007e4 Received: from mail-qt1-x841.google.com (unknown [2607:f8b0:4864:20::841]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ff97dc2a-a3bd-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 04:11:42 +0000 (UTC) Received: by mail-qt1-x841.google.com with SMTP id i68so6751800qtb.5 for ; Sun, 31 May 2020 21:11:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3NwYwJLV2MbQSYU70QW25++6lGpRPnoUWdanU2rZBDo=; b=O7ZqEoNT28KJnf9C95fOAB8EdGl9FcZ4tTKnZPyk7SGY+NxGWwV4628CC6nTokzyKo 9+OuBHH4Ll5oNWHrkIuS8G6Q9RneMn0VOK28L38otr0hNYVmmrAfEsL84mRyym758n/h zJ5+/dPaIihGFHri+KG3Y7NsAOZW2myqVb3UY1IQNeqfajYEwFWOFMyf2fDNdqdmHhTQ O7xfYeSUt1e/oRY55R1Xbz4QgfQvyM3dP0M9FDcakedivtxMF/+W1hLjBHG1yxEkqvEw hoB0fJibvDqWRHdlde9QTTTTbfaogPGqD2fRzUYaRuCu+Bn8oAz+ok/WtB9XufLegKFz I3cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3NwYwJLV2MbQSYU70QW25++6lGpRPnoUWdanU2rZBDo=; b=OpL54FShoAdq9Q1MUpFPaQifsFlSLHHQwq/2v7kt1qXxNPSsGb6rCl0PkdVb9JJNfv QbQqIWonorUswCjGiHTI1G57EJGSdyg6H5rG1GWgA3DNxUnp2y49YnPVVOHfuAokbLEu WR92Se8k03Ee738n5ng9EMsoYIhHVrmzabJE6TM8hyZznc6OdQDpZp/mhmkjrwyxA9U4 L/LQ8R/QiIbR268rvR9YRd89dDFTpefYi2V9omPYGEo/h6ieNJm+cMWssfRK6PzrNSh5 kIeuoEe8c3EZd0QEzoSKcMzNzrmQlkl3vCuVSkWE38+tnIKRkQwbbo8vWMKrRyIr5MsK HB6g== X-Gm-Message-State: AOAM530axb5r6XG9QN3sUEViy6U2YtujAoKPHG6yqXLxJpMvSz1YAlwb k4Fp7S8WpbFBvAj8qjnRgUMuR4zi5dSsru8pED5gzA== X-Google-Smtp-Source: ABdhPJwiGh7pEagbUquDpKGrWMXh9pZto7E9lYO9/hE7z01B5uO5u5QNUsy1hvzUbL6vud4Yi2geytKa9hQsnJjHgDk= X-Received: by 2002:ac8:4d0e:: with SMTP id w14mr17550046qtv.266.1590984701735; Sun, 31 May 2020 21:11:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shaposhnik Date: Sun, 31 May 2020 21:11:30 -0700 Message-ID: Subject: Re: UEFI support in ARM DomUs To: Julien Grall Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Stefano Stabellini , Nataliya Korovkina Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Julien! On Sun, May 31, 2020 at 3:24 PM Julien Grall wrote: > > On Sun, 31 May 2020 at 23:05, Roman Shaposhnik wrote: > > Hi! > > > > with a lot of help from Stefano, we're getting RPi4 support in > > Project EVE pretty much on par between KVM and Xen. > > > > One big area that still remains is supporting UEFI boot sequence > > for DomUs. With KVM, given the qemu virt device model this is > > as simple as using either stock UEFI build for arm or even U-Boot > > EFI emulation environment and passing it via -bios option. > > > > Obviously with Xen on ARM we don't have the device model so > > my understanding is that the easiest way we can support it would > > be to port UEFI's OvmfPkg/OvmfXen target to ARM (it seems to > > be currently exclusively X64). > > EDK2 has been supporting Xen on Arm for the past 5 years. We don't use > OvmfPkg/OvmfXen but ArmVirtPkg/ArmVirtXen (see [1]). > I haven't tried to build it recently, but I should be able to help if > there is any issue with it. > > Cheers, > > [1] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtXen.fdf This is really, really awesome -- I guess it would be really helpful to document this someplace on the ARM/Xen wiki (I can volunteer if someone can grant me the karma). I've built XEN_EFI.fd and the rest worked out like a charm. All on Raspberry Pi 4! Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Mon Jun 01 05:28:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 05:28:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfczC-0006X3-IN; Mon, 01 Jun 2020 05:27:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfczB-0006Wy-Gt for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 05:27:45 +0000 X-Inumbo-ID: 9e1cd922-a3c8-11ea-aaee-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9e1cd922-a3c8-11ea-aaee-12813bfff9fa; Mon, 01 Jun 2020 05:27:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 80141B03E; Mon, 1 Jun 2020 05:27:43 +0000 (UTC) Subject: Re: [PATCH v10 05/12] libs: add libxenhypfs To: Andrew Cooper , xen-devel@lists.xenproject.org References: <20200519072106.26894-1-jgross@suse.com> <20200519072106.26894-6-jgross@suse.com> <8468b7ea-81ba-0512-c638-322803134576@citrix.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <91bd61d3-3f61-c8c8-8f7b-4547eb02b342@suse.com> Date: Mon, 1 Jun 2020 07:27:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <8468b7ea-81ba-0512-c638-322803134576@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 30.05.20 17:54, Andrew Cooper wrote: > On 19/05/2020 08:20, Juergen Gross wrote: >> diff --git a/tools/libs/hypfs/include/xenhypfs.h b/tools/libs/hypfs/include/xenhypfs.h >> new file mode 100644 >> index 0000000000..ab157edceb >> --- /dev/null >> +++ b/tools/libs/hypfs/include/xenhypfs.h >> @@ -0,0 +1,90 @@ >> +/* >> + * Copyright (c) 2019 SUSE Software Solutions Germany GmbH >> + * >> + * This library is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU Lesser General Public >> + * License as published by the Free Software Foundation; >> + * version 2.1 of the License. >> + * >> + * This library is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + * Lesser General Public License for more details. >> + * >> + * You should have received a copy of the GNU Lesser General Public >> + * License along with this library; If not, see . >> + */ >> +#ifndef XENHYPFS_H >> +#define XENHYPFS_H >> + >> +#include >> +#include >> +#include >> + >> +/* Callers who don't care don't need to #include */ >> +struct xentoollog_logger; >> + >> +typedef struct xenhypfs_handle xenhypfs_handle; >> + >> +struct xenhypfs_dirent { >> + char *name; >> + size_t size; >> + enum { >> + xenhypfs_type_dir, >> + xenhypfs_type_blob, >> + xenhypfs_type_string, >> + xenhypfs_type_uint, >> + xenhypfs_type_int, >> + xenhypfs_type_bool >> + } type; >> + enum { >> + xenhypfs_enc_plain, >> + xenhypfs_enc_gzip >> + } encoding; >> + bool is_writable; >> +}; > > I'm afraid this a blocker bug for 4.14. > > enum's aren't safe in public ABI structs, even under _GNU_SOURCE.  Use > unsigned int's, and declare the enumerations earlier. > > There is also 3/7 bytes of trailing padding and very little forward > extensibility.  How about an unsigned int flags, of which writeable is > the bottom bit, seeing as this is purely an informational field? Sounds fine. I'll send a patch on Tuesday (today is a local holiday in Germany and I need to do some outdoor work). Juergen From xen-devel-bounces@lists.xenproject.org Mon Jun 01 05:47:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 05:47:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfdHk-0008Eu-4w; Mon, 01 Jun 2020 05:46:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfdHi-0008Ep-I0 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 05:46:54 +0000 X-Inumbo-ID: 483cff84-a3cb-11ea-aaf3-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 483cff84-a3cb-11ea-aaf3-12813bfff9fa; Mon, 01 Jun 2020 05:46:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1jl+IasfXtivUEAkCkUYJQcewseljjIVGaP+Kk84O2w=; b=40Wq6v5Xgj2/6BqCsS7eIqSJy siLRTawXubpfWOXhAJBBbxkGK1sMloCdfqw+QgWhlM1fBW9fioCLJzsRltKqDca6gIxYRQyNET7D+ vV8P7AbgdBrwig36ujd+JpAGuYLSjkuVFAyABf8+YU2+gSFIT5gbZkJGdbGCo2Muc+GjA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfdHa-0000PF-TB; Mon, 01 Jun 2020 05:46:46 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfdHa-0004zR-Gm; Mon, 01 Jun 2020 05:46:46 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfdHa-00035A-DP; Mon, 01 Jun 2020 05:46:46 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150585: tolerable FAIL - PUSHED X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=ce20db593f50752badbc94d6a96e4576aa4a2443 X-Osstest-Versions-That: qemuu=c86274bc2e34295764fb44c2aef3cf29623f9b4b From: osstest service owner Date: Mon, 01 Jun 2020 05:46:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150585 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150585/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150532 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150532 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150532 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150532 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150532 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150532 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: qemuu ce20db593f50752badbc94d6a96e4576aa4a2443 baseline version: qemuu c86274bc2e34295764fb44c2aef3cf29623f9b4b Last test of basis 150532 2020-05-30 10:31:54 Z 1 days Testing same since 150585 2020-05-31 20:06:30 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Eric Blake Peter Maydell Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/qemu-xen.git c86274bc2e..ce20db593f ce20db593f50752badbc94d6a96e4576aa4a2443 -> upstream-tested From xen-devel-bounces@lists.xenproject.org Mon Jun 01 06:45:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 06:45:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfeBq-0004qf-9S; Mon, 01 Jun 2020 06:44:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfeBo-0004qa-LA for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 06:44:52 +0000 X-Inumbo-ID: 62078e5e-a3d3-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 62078e5e-a3d3-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 06:44:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tOw2cx5eIUTWnGqyL8YGmQgXq6clNcAASKn1YRzkrAg=; b=AyfGGO2CF/ywR6gozX4PDpy/b U2C5UV4c9EFRyqv+4TOefZQ6l6NLNquJx+rSxEgtPue9K22mtXBR5NUQuQ5koJpj8SuP8CHFKF6ud 3tRg/xgOUG+u07y29Fr0TBC1H6y5CTygsp1v/P7w3N2YUsdngsmnjzwdQJbaB0n58v19w=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfeBi-0001cM-8g; Mon, 01 Jun 2020 06:44:46 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfeBh-0002Rp-Ve; Mon, 01 Jun 2020 06:44:46 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfeBh-0000ou-Uy; Mon, 01 Jun 2020 06:44:45 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150591: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ad33a573c009d72466432b41ba0591c64e819c19 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Mon, 01 Jun 2020 06:44:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150591 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150591/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen ad33a573c009d72466432b41ba0591c64e819c19 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 3 days Failing since 150465 2020-05-29 09:02:14 Z 2 days 27 attempts Testing same since 150515 2020-05-30 01:00:47 Z 2 days 17 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1196 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 07:02:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 07:02:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfeT0-0006au-RB; Mon, 01 Jun 2020 07:02:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfeSz-0006ap-Af for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 07:02:37 +0000 X-Inumbo-ID: df49290c-a3d5-11ea-8993-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id df49290c-a3d5-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 07:02:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uLnQnc9J0buFK8eOJbyLD2dMaSL9g4+YrIjwHBt83oY=; b=lYQdUqnTFNqfs4OH2hLr/rFcC FOBKmvLjiYzrc2REZbrizRWMjTzcTL7TVQil1YJJaTBJI416JYI9G0yCjcbT1OClQJcnom4w+tDrV z9vYvLrJLLEW2vjIx+zRLAwMhv/3RtFaAijOLVmuhcfLBA1EN+xD8VwZZwfbCJIemiZ60=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfeSw-000217-Te; Mon, 01 Jun 2020 07:02:34 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfeSw-0003LL-MK; Mon, 01 Jun 2020 07:02:34 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfeSw-00016C-Kn; Mon, 01 Jun 2020 07:02:34 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 150592: regressions - FAIL X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression libvirt:build-i386-libvirt:libvirt-build:fail:regression libvirt:build-arm64-libvirt:libvirt-build:fail:regression libvirt:build-armhf-libvirt:libvirt-build:fail:regression libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking X-Osstest-Versions-This: libvirt=f6c79ca2af3607eb1cbbb7208c194f7cbf7a6abd X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5 From: osstest service owner Date: Mon, 01 Jun 2020 07:02:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150592 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/150592/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-build fail REGR. vs. 146182 build-i386-libvirt 6 libvirt-build fail REGR. vs. 146182 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 146182 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 146182 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a version targeted for testing: libvirt f6c79ca2af3607eb1cbbb7208c194f7cbf7a6abd baseline version: libvirt a1cd25b919509be2645dbe6f952d5263e0d4e4e5 Last test of basis 146182 2020-01-17 06:00:23 Z 136 days Failing since 146211 2020-01-18 04:18:52 Z 135 days 126 attempts Testing same since 150555 2020-05-31 04:18:53 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Arnaud Patard Artur Puzio Bjoern Walk Boris Fiuczynski Chen Hanxiao Chris Jester-Young Christian Borntraeger Christian Ehrhardt Christian Schoenebeck Collin Walling Cornelia Huck Daniel Henrique Barboza Daniel P. Berrangé Daniel Veillard Dario Faggioli Erik Skultety Gaurav Agrawal Han Han Jaak Ristioja Jamie Strandboge Jim Fehlig Jiri Denemark Jonathon Jongsma Julio Faracco Ján Tomko Laine Stump Leonid Bloch Liao Pingfang Lin Ma Marc-André Lureau Marek Marczykowski-Górecki Mark Asselstine Mauro S. M. Rodrigues Michal Privoznik Nikolay Shirokovskiy Paolo Bonzini Pavel Hrdina Pavel Mores Peter Krempa Philipp Hahn Pino Toscano Prathamesh Chavan Rafael Fonseca Richard W.M. Jones Rikard Falkeborn Ryan Moeller Sahid Orentino Ferdjaoui Sebastian Mitterle Seeteena Thoufeek Stefan Berger Stefan Berger Stefan Hajnoczi Thomas Huth Tobin Feldman-Fitzthum Tomáš Golembiovský Wu Qingliang Xu Yandong Yan Wang Yi Li Your Name Zhang Bo zhenwei pi Zhenyu Zheng Zhimin Feng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 19591 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 07:26:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 07:26:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfepx-0008Mk-Np; Mon, 01 Jun 2020 07:26:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfepw-0008Mf-Eu for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 07:26:20 +0000 X-Inumbo-ID: 2fba0926-a3d9-11ea-9dbe-bc764e2007e4 Received: from mail-ed1-x543.google.com (unknown [2a00:1450:4864:20::543]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2fba0926-a3d9-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 07:26:19 +0000 (UTC) Received: by mail-ed1-x543.google.com with SMTP id k8so6520359edq.4 for ; Mon, 01 Jun 2020 00:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=01TZDSO3dojveQeklKTr8Gf5qjCbs63AIjG69MKbth4=; b=SWPOBpENIza2X2ovj4OdRkqXs/ryMDs5pbXsYp0qV9Tqvikk43s4k4FA6pLWSZJcmA A8N4bNAUAWEnkUGqT9Ej8DTnxjW1j/5SXBQJ4atyzZ15ku4N4/sDUAUqhewYxv6SZo4O PKhADaAdEjTM+vlKXo0giH5kPQwgHstBHaCJFMPtZ1pwEk/KIOvMqO47cUpEKlsTUoSg JwkLaoqGqT7ypzkMpQTmqGUSLef1yRYADCZfbTzLuFBanxdvlXgPTx69CNlTvDsgPlrJ CqV1QpS1V7AHwmM7U4qwlh7nNbBMKwZVKDgLxeEKTDV+GxQVuhYgfqimCaLJ/BInDC0k 4ksA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=01TZDSO3dojveQeklKTr8Gf5qjCbs63AIjG69MKbth4=; b=lErEaNaKO1R5EnYzopmwTRXlgVZK16Ie465FXKDcDuq7SHncxAAIdO1+ebilvMJ2qF qZEggwLiUsJyeGzdGxrkipnzoUS3ZXFEjlMxBHWSuhhO8LZgpW8xCBl63mPC6lRpt8r/ JnDY+QgIpJT0XoWRl62mpEkCLcxI9/XsIPFGkOKusPKExyob+gh+nih69eoFipVZRdsS 63LXDNzx+gnxDZbJpzModfV2sT9p3BDjlznAR63FoPo+AsDoeZqrNjAD9dieBZYvu9Ln WrYvCJo74nER6X9BfC7OatB+siG0wgLRP8AAkjIeuyw5H0qeQm+8UKHXVvLb/gB9Sgo3 5YbA== X-Gm-Message-State: AOAM530/SzsFNflk8Bg1i4Tvv2hpl4kbkrtuFP3Yh5y/1yy/J6JGwBLA bu8DOiSsZkFxoA9ovdMnY9M= X-Google-Smtp-Source: ABdhPJyfRslWjZ3RjWM9oZQ++gfLq4y6Y5KnkAMbIiJFd+YvpBjLyYaKNlGBTfvqqWbxOr9NJ7Y0cg== X-Received: by 2002:aa7:cb94:: with SMTP id r20mr20679771edt.215.1590996378792; Mon, 01 Jun 2020 00:26:18 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id w12sm15278153eds.4.2020.06.01.00.26.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 00:26:18 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'Philippe_Mathieu-Daud=C3=A9'?= , References: <20200531173814.8734-1-f4bug@amsat.org> <20200531173814.8734-8-f4bug@amsat.org> In-Reply-To: <20200531173814.8734-8-f4bug@amsat.org> Subject: RE: [PATCH 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions Date: Mon, 1 Jun 2020 08:26:16 +0100 Message-ID: <000001d637e5$f0c4b4f0$d24e1ed0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQK5AEx/dP7iXwJVovNs/KrDX2tj3QLWDH7zpucakaA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Peter Maydell' , 'Stefano Stabellini' , 'Eduardo Habkost' , "'Michael S. Tsirkin'" , 'Andrew Jeffery' , 'Helge Deller' , 'Joel Stanley' , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?utf-8?Q?'Herv=C3=A9_Poussineau'?= , =?utf-8?Q?'C=C3=A9dric_Le_Goater'?= , 'Marcel Apfelbaum' , 'Paolo Bonzini' , 'Anthony Perard' , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, 'Richard Henderson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Philippe Mathieu-Daud=C3=A9 = On Behalf Of Philippe Mathieu-Daud=C3=A9 > Sent: 31 May 2020 18:38 > To: qemu-devel@nongnu.org > Cc: Andrew Jeffery ; Helge Deller ; = Peter Maydell > ; Richard Henderson ; = Eduardo Habkost > ; Paul Durrant ; Herv=C3=A9 = Poussineau ; Marcel > Apfelbaum ; = xen-devel@lists.xenproject.org; Paolo Bonzini > ; Stefano Stabellini ; = C=C3=A9dric Le Goater ; > qemu-trivial@nongnu.org; Joel Stanley ; = qemu-arm@nongnu.org; Michael S. Tsirkin > ; Anthony Perard ; = qemu-ppc@nongnu.org; Philippe Mathieu- > Daud=C3=A9 > Subject: [PATCH 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix = definitions >=20 > IEC binary prefixes ease code review: the unit is explicit. >=20 > Signed-off-by: Philippe Mathieu-Daud=C3=A9 > --- > hw/i386/xen/xen-hvm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c > index 82ece6b9e7..679d74e6a3 100644 > --- a/hw/i386/xen/xen-hvm.c > +++ b/hw/i386/xen/xen-hvm.c > @@ -9,6 +9,7 @@ > */ >=20 > #include "qemu/osdep.h" > +#include "qemu/units.h" >=20 > #include "cpu.h" > #include "hw/pci/pci.h" > @@ -230,7 +231,7 @@ static void xen_ram_init(PCMachineState *pcms, > * Xen does not allocate the memory continuously, it keeps a > * hole of the size computed above or passed in. > */ > - block_len =3D (1ULL << 32) + x86ms->above_4g_mem_size; > + block_len =3D 4 * GiB + x86ms->above_4g_mem_size; Not strictly necessary but could we retain the brackets please? Paul > } > memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len, > &error_fatal); > -- > 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 07:45:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 07:45:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jff8L-0001de-9e; Mon, 01 Jun 2020 07:45:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jff8K-0001dZ-7R for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 07:45:20 +0000 X-Inumbo-ID: d6b70fce-a3db-11ea-81bc-bc764e2007e4 Received: from mail-ed1-x52d.google.com (unknown [2a00:1450:4864:20::52d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d6b70fce-a3db-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 07:45:18 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id k19so6525115edv.9 for ; Mon, 01 Jun 2020 00:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=TArJAUPaOJGl/dVFKZA/jKFYGj1MPluOHDMaCWjmMmQ=; b=DHqB+pW0MAJHqCTA5tVl504adFCc20B1ew7m4sNHss0Xx4CKrfTN8SBA0Oi6Wf7mJQ iJkjtr0lZgpaP0URXWUNkGS3uDbzVbEvPy6TZHrGn6l9BTitANSoJBD02NZECp3IhpBP 4m1p1ByifW+gZ51/EV2fpdCqyXARNTmKvXzGigquFy3YOlOkG0UkDLXsycKUowhKie0P oNICSJfgpo4hFYuVQmo35ltz9YryeQEnjgiLdNe2DYevVqBYwVw1HYYQcj6gLMNuJDXs FOUfysjHff8aRkw8Ja6DB9BYUPvbt7J5R0aqAFeRjZnQc9ZqIK1fyWiLTfg/R1J6EKB5 dNvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=TArJAUPaOJGl/dVFKZA/jKFYGj1MPluOHDMaCWjmMmQ=; b=ZxBxZU4Am2x8qZzTIUJ5C6yxoFgIdygNBZW9hm6iBz2wkCcGz5y1yFxYOxrzlH/eQ/ Ittm0BmG424xhaOv38mFTEWCoIfxa7QjCFuoNoB4SkHndL2qGeByMKgzqMx+9fnrA/QB Tg4FEXaMnsO8oMF1Alxxuzt0TPAv9qWV5HtnpMdFm5yai8lBnR8EVEEZS5I229klDriU RosVGYrVMcH4HBZjjqPCI32TPGWGzbewt9FxvSie+FOuOuiQMEgAka9sZcB7/oIx9p5y v08pmv0KTtYOY4Lgkz8eU9QEQJQpz2OLyue5YmpA0cswyVfFjL6rTpqGomKJMhwCJE8H N89A== X-Gm-Message-State: AOAM532dQXEsL81iTdYlqmi2jD8rbTa3vbwkKZ7O5CqEsJWZ1VPreOb2 EveHRCpFV1H1EFxyFoc1si0= X-Google-Smtp-Source: ABdhPJyMKdqj27H988zXUIKL1s0lArYismBjxHi7mFWpfhkEwPMa9tl8fnyMYN/e4FYAQgCUbZn68g== X-Received: by 2002:a50:c017:: with SMTP id r23mr1935150edb.120.1590997517889; Mon, 01 Jun 2020 00:45:17 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id qt19sm10070817ejb.14.2020.06.01.00.45.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 00:45:17 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , References: <20200527173407.1398-1-paul@xen.org> <20200527173407.1398-6-paul@xen.org> <51f8cd86-9582-4fba-7e67-0c4b227870d1@citrix.com> In-Reply-To: <51f8cd86-9582-4fba-7e67-0c4b227870d1@citrix.com> Subject: RE: [PATCH v6 5/5] tools/libxc: make use of domain context SHARED_INFO record... Date: Mon, 1 Jun 2020 08:45:16 +0100 Message-ID: <000301d637e8$97b96ba0$c72c42e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQEXlIoBjHO/WiznBkx41DgoSMmbXAJ+udBDAYjKFSKqIGbNoA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Paul Durrant' , 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper On Behalf Of Andrew = Cooper > Sent: 30 May 2020 01:30 > To: Paul Durrant ; xen-devel@lists.xenproject.org > Cc: Paul Durrant ; Ian Jackson = ; Wei Liu > Subject: Re: [PATCH v6 5/5] tools/libxc: make use of domain context = SHARED_INFO record... >=20 > On 27/05/2020 18:34, Paul Durrant wrote: > > ... in the save/restore code. > > > > This patch replaces direct mapping of the shared_info_frame = (retrieved > > using XEN_DOMCTL_getdomaininfo) with save/load of the domain context > > SHARED_INFO record. > > > > No modifications are made to the definition of the migration stream = at > > this point. Subsequent patches will define a record in the libxc = domain > > image format for passing domain context and convert the save/restore = code > > to use that. > > > > Signed-off-by: Paul Durrant >=20 > I was going to fix up the remaining issues and commit this, but there = is > a rather major problem in the way. Therefore, here is a rather more > full review. >=20 Thanks, but I have to say that this is quite late, coming in v6. > > diff --git a/tools/libxc/xc_sr_common.c b/tools/libxc/xc_sr_common.c > > index dd9a11b4b5..1acb3765aa 100644 > > --- a/tools/libxc/xc_sr_common.c > > +++ b/tools/libxc/xc_sr_common.c > > @@ -138,6 +138,73 @@ int read_record(struct xc_sr_context *ctx, int = fd, struct xc_sr_record *rec) > > return 0; > > }; > > > > +int get_domain_context(struct xc_sr_context *ctx) > > +{ > > + xc_interface *xch =3D ctx->xch; > > + size_t len =3D 0; > > + int rc; > > + > > + if ( ctx->domain_context.buffer ) > > + { > > + ERROR("Domain context already present"); > > + return -1; > > + } > > + > > + rc =3D xc_domain_getcontext(xch, ctx->domid, NULL, &len); > > + if ( rc < 0 ) > > + { > > + PERROR("Unable to get size of domain context"); > > + return -1; > > + } > > + > > + ctx->domain_context.buffer =3D malloc(len); > > + if ( !ctx->domain_context.buffer ) > > + { > > + PERROR("Unable to allocate memory for domain context"); > > + return -1; > > + } >=20 > There is an xc_sr_blob interface, as this is a common pattern. >=20 Ok. > > + > > + rc =3D xc_domain_getcontext(xch, ctx->domid, = ctx->domain_context.buffer, > > + &len); > > + if ( rc < 0 ) > > + { > > + PERROR("Unable to get domain context"); > > + return -1; > > + } > > + > > + ctx->domain_context.len =3D len; > > + > > + return 0; > > +} > > + > > +int set_domain_context(struct xc_sr_context *ctx) > > +{ > > + xc_interface *xch =3D ctx->xch; > > + int rc; > > + > > + if ( !ctx->domain_context.buffer ) > > + { > > + ERROR("Domain context not present"); > > + return -1; > > + } > > + > > + rc =3D xc_domain_setcontext(xch, ctx->domid, = ctx->domain_context.buffer, > > + ctx->domain_context.len); > > + > > + if ( rc < 0 ) > > + { > > + PERROR("Unable to set domain context"); > > + return -1; > > + } > > + > > + return 0; > > +} > > + > > +void common_cleanup(struct xc_sr_context *ctx) > > +{ > > + free(ctx->domain_context.buffer); >=20 > There is only a single caller to this function, so there is a = (possibly > latent) memory leak. >=20 > > +} > > + > > static void __attribute__((unused)) build_assertions(void) > > { > > BUILD_BUG_ON(sizeof(struct xc_sr_ihdr) !=3D 24); > > diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h > > index 5dd51ccb15..0d61978b08 100644 > > --- a/tools/libxc/xc_sr_common.h > > +++ b/tools/libxc/xc_sr_common.h > > @@ -208,6 +208,11 @@ struct xc_sr_context > > > > xc_dominfo_t dominfo; > > > > + struct { > > + void *buffer; > > + unsigned int len; > > + } domain_context; >=20 > As noted above, xc_sr_blob domain_context; >=20 > > diff --git a/tools/libxc/xc_sr_restore_x86_pv.c = b/tools/libxc/xc_sr_restore_x86_pv.c > > index 904ccc462a..21982a38ad 100644 > > --- a/tools/libxc/xc_sr_restore_x86_pv.c > > +++ b/tools/libxc/xc_sr_restore_x86_pv.c > > @@ -865,7 +865,7 @@ static int handle_shared_info(struct = xc_sr_context *ctx, > > xc_interface *xch =3D ctx->xch; > > unsigned int i; > > int rc =3D -1; > > - shared_info_any_t *guest_shinfo =3D NULL; > > + shared_info_any_t *guest_shinfo; > > const shared_info_any_t *old_shinfo =3D rec->data; > > > > if ( !ctx->x86.pv.restore.seen_pv_info ) > > @@ -878,18 +878,14 @@ static int handle_shared_info(struct = xc_sr_context *ctx, > > { > > ERROR("X86_PV_SHARED_INFO record wrong size: length %u" > > ", expected 4096", rec->length); > > - goto err; > > + return -1; > > } > > > > - guest_shinfo =3D xc_map_foreign_range( > > - xch, ctx->domid, PAGE_SIZE, PROT_READ | PROT_WRITE, > > - ctx->dominfo.shared_info_frame); > > - if ( !guest_shinfo ) > > - { > > - PERROR("Failed to map Shared Info at mfn %#lx", > > - ctx->dominfo.shared_info_frame); > > - goto err; > > - } > > + rc =3D x86_pv_get_shinfo(ctx); > > + if ( rc ) > > + return rc; >=20 > If I'm following this logic correctly, we're now in the final throws = of > completing migration with data in hand, and we ask the hypervisor to > gather the entire domain context for this (not-yet-run) guest, copy it > (twice, even) down into userspace, so we can scan through it to find = the > appropriate tag, copy less than a page's worth of data, then pass the > full buffer back to Xen to unserialise the whole thing over the guest. >=20 That is the case at the moment yes. I do state quite clearly in the = commit comment: "No modifications are made to the definition of the migration stream at this point. Subsequent patches will define a record in the libxc domain image format for passing domain context and convert the save/restore = code to use that." > The restore path shouldn't be calling DOMCTL_get* at all. It is > conceptually wrong, and a waste of time/effort which would be better > spent with the guest unpaused. >=20 I refer to the quoted text above. > What the restore path should be doing is passing data from the stream, > straight into DOMCTL_set* (and attempting to do this will probably > demonstrate why hvmctxt was an especially poor API to copy). The = layout > of existing migration-v2 blocks was designed around blobs which Xen > produces and consumes directly, specifically to minimise the = processing > required. >=20 > I think it is a layering violation to have libxc pick apart and = reframe > the internals of another layers' blob. >=20 Again, that was a pragmatic choice at this stage. The layering violation = is already there; I have not added code to pick apart the shared info... = it was there already. I also don't think picking apart the domain = context buffer is necessarily a layering violation. > What is not currently clear is whether the domain context wants = sending > as a discrete blob itself (and have a new chunk type allocated for the > purpose), or each bit of it is going to want picking apart. This > largely depends on what else is going in the blob at a Xen level. >=20 > Also, I'd like to see the plans for the HVM side of this logic before > deciding on whether the PV side is appropriate. I know we have a > dedicated SHARED_INFO record right now, but it would be fine (AFAICT) = to > relax the migration spec to state that one of {SHARED_INFO, > DOMAIN_CONTEXT} must be sent for PV. >=20 If you object to this interim step then I think I will indeed abstract = away from SHARED_INFO instead. Very little of it is actually used in PV = migration anyway and different parts will be needed for guest = transparent live migration. > > @@ -854,13 +835,27 @@ static int write_x86_pv_p2m_frames(struct = xc_sr_context *ctx) > > */ > > static int write_shared_info(struct xc_sr_context *ctx) > > { > > + xc_interface *xch =3D ctx->xch; > > struct xc_sr_record rec =3D { > > .type =3D REC_TYPE_SHARED_INFO, > > .length =3D PAGE_SIZE, > > - .data =3D ctx->x86.pv.shinfo, > > }; > > + int rc; > > > > - return write_record(ctx, &rec); > > + if ( !(rec.data =3D calloc(1, PAGE_SIZE)) ) > > + { > > + ERROR("Cannot allocate buffer for SHARED_INFO data"); > > + return -1; > > + } > > + > > + BUILD_BUG_ON(sizeof(*ctx->x86.pv.shinfo) > PAGE_SIZE); > > + memcpy(rec.data, ctx->x86.pv.shinfo, = sizeof(*ctx->x86.pv.shinfo)); >=20 > These are some very contorted hoops to extend the data size sent. >=20 > write_split_record() is the the tool to use here, although the above > suggestions may render this change unnecessary. >=20 Indeed. > > @@ -1041,7 +1036,7 @@ static int x86_pv_setup(struct xc_sr_context = *ctx) > > if ( rc ) > > return rc; > > > > - rc =3D map_shinfo(ctx); > > + rc =3D x86_pv_get_shinfo(ctx); > > if ( rc ) > > return rc; > > > > @@ -1112,12 +1107,11 @@ static int x86_pv_cleanup(struct = xc_sr_context *ctx) > > if ( ctx->x86.pv.p2m ) > > munmap(ctx->x86.pv.p2m, ctx->x86.pv.p2m_frames * = PAGE_SIZE); > > > > - if ( ctx->x86.pv.shinfo ) > > - munmap(ctx->x86.pv.shinfo, PAGE_SIZE); > > - > > if ( ctx->x86.pv.m2p ) > > munmap(ctx->x86.pv.m2p, ctx->x86.pv.nr_m2p_frames * = PAGE_SIZE); > > > > + common_cleanup(ctx); > > + > > return 0; > > } >=20 > This pair highlights an asymmetry in the patch, which will need fixing > by whomever adds a second field to domain_context. Obtaining the > context for use should shouldn't be a hidden side effect of getting = the > shared info. >=20 Ok. Paul > ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 01 08:33:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 08:33:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jffsw-0006NC-HG; Mon, 01 Jun 2020 08:33:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jffsv-0006N7-BM for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 08:33:29 +0000 X-Inumbo-ID: 912979b8-a3e2-11ea-81bc-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 912979b8-a3e2-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 08:33:28 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id f185so10462543wmf.3 for ; Mon, 01 Jun 2020 01:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Wb302sgiYxfPaOUVMNPVZTgMDWXAbDEM/6w0YEYyXVI=; b=qpAUJ/XnT4mWsnqFMatowAbLLFJq43367/cBpfL/d3ZzTAp/DFEljArpThGY9+x18V mEWL8q9LN1y/Kzo+yPVP9NuX/kfEdhcwtUoUfgf7soF39oOD56i779EDikiWNdymrWiX iGGtrBcC2jcRqrRl9ppZVn/1WCbmq4vVN9DSxtAyiWa1+q4pxj6qRzoay8n+SQrsR0yw xppjqFmvZcRSAqBhzHi3l+z0IJbui5cI7X5kxEJ1zcyLOImgzgUXu2H10/7ZMwXcJ4zi f2UOMruKHQPpVSt0R+Z8WeJyW7oZywqw1PT6JFEm2PiEbYoqydIw6Ah5rnt5mxbRKRnd TU3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Wb302sgiYxfPaOUVMNPVZTgMDWXAbDEM/6w0YEYyXVI=; b=lzE6NX2A4E5oJ42/NqQMTgUzeZX3rt0qS8QuNkykSPpaSuweR59yaoDpQcx/tgTuMC e3CaCwzcCm9E2qmos9AlAhCRVhAMpVQPCv8t3jyKTQ4ZwwUfetO0zP9kAwmgoIgj2hhN EpjermF4+LcpaY8uJeCX3LI3E2YHBvH/aSYw0HZPxWiY9yuu779fTTA21bLxM6nwg8So Lprxue3SDsBC1/jW5AUjC/6JzWaVdCk6k70PwBzH6FqKIqhU7X1dRaBI/nskEF1zO0vy cMQz/tveFrYfOU3OOGIv/PsZwPJ4Hjsq5OgWAr7v1YfGBAZdp93cy+msoPfSjfhiDVpY r2Kw== X-Gm-Message-State: AOAM532E8dDAnJu6eX8dUEY0xyX717Ihte6FwSZR3yVFAVmfQapEu+JF PlECVcVjcQd09euJwTzrnuU= X-Google-Smtp-Source: ABdhPJxCUGyTLCx6nC4rkNK06m7YbI0ofoKV10ACf5rgyiIrixi/EROQbo/YLaDXpnfOfoBnf+b5TA== X-Received: by 2002:a1c:62d6:: with SMTP id w205mr19510946wmb.97.1591000407855; Mon, 01 Jun 2020 01:33:27 -0700 (PDT) Received: from [192.168.1.34] (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id l17sm11837037wmi.16.2020.06.01.01.33.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 01:33:27 -0700 (PDT) Subject: Re: [PATCH 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions To: paul@xen.org, qemu-devel@nongnu.org References: <20200531173814.8734-1-f4bug@amsat.org> <20200531173814.8734-8-f4bug@amsat.org> <000001d637e5$f0c4b4f0$d24e1ed0$@xen.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Message-ID: <63327be6-10c1-6a8c-b4ed-cbbd085a35a8@amsat.org> Date: Mon, 1 Jun 2020 10:33:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <000001d637e5$f0c4b4f0$d24e1ed0$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Peter Maydell' , 'Stefano Stabellini' , 'Eduardo Habkost' , "'Michael S. Tsirkin'" , 'Andrew Jeffery' , 'Helge Deller' , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?Q?=27Herv=c3=a9_Poussineau=27?= , 'Joel Stanley' , 'Marcel Apfelbaum' , xen-devel@lists.xenproject.org, 'Anthony Perard' , 'Paolo Bonzini' , 'Richard Henderson' , qemu-ppc@nongnu.org, =?UTF-8?Q?=27C=c3=a9dric_Le_Goater=27?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 9:26 AM, Paul Durrant wrote: >> -----Original Message----- >> From: Philippe Mathieu-Daudé On Behalf Of Philippe Mathieu-Daudé >> Sent: 31 May 2020 18:38 >> To: qemu-devel@nongnu.org >> Cc: Andrew Jeffery ; Helge Deller ; Peter Maydell >> ; Richard Henderson ; Eduardo Habkost >> ; Paul Durrant ; Hervé Poussineau ; Marcel >> Apfelbaum ; xen-devel@lists.xenproject.org; Paolo Bonzini >> ; Stefano Stabellini ; Cédric Le Goater ; >> qemu-trivial@nongnu.org; Joel Stanley ; qemu-arm@nongnu.org; Michael S. Tsirkin >> ; Anthony Perard ; qemu-ppc@nongnu.org; Philippe Mathieu- >> Daudé >> Subject: [PATCH 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions >> >> IEC binary prefixes ease code review: the unit is explicit. >> >> Signed-off-by: Philippe Mathieu-Daudé >> --- >> hw/i386/xen/xen-hvm.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c >> index 82ece6b9e7..679d74e6a3 100644 >> --- a/hw/i386/xen/xen-hvm.c >> +++ b/hw/i386/xen/xen-hvm.c >> @@ -9,6 +9,7 @@ >> */ >> >> #include "qemu/osdep.h" >> +#include "qemu/units.h" >> >> #include "cpu.h" >> #include "hw/pci/pci.h" >> @@ -230,7 +231,7 @@ static void xen_ram_init(PCMachineState *pcms, >> * Xen does not allocate the memory continuously, it keeps a >> * hole of the size computed above or passed in. >> */ >> - block_len = (1ULL << 32) + x86ms->above_4g_mem_size; >> + block_len = 4 * GiB + x86ms->above_4g_mem_size; > > Not strictly necessary but could we retain the brackets please? Sure. Laurent, if this can go via your trivial@ tree, can you do the change or you rather I resend the whole series? > > Paul > >> } >> memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len, >> &error_fatal); >> -- >> 2.21.3 > > > From xen-devel-bounces@lists.xenproject.org Mon Jun 01 09:13:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 09:13:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfgVG-0001KG-RB; Mon, 01 Jun 2020 09:13:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfgVF-0001KB-9k for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 09:13:05 +0000 X-Inumbo-ID: 18c47eae-a3e8-11ea-ab03-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 18c47eae-a3e8-11ea-ab03-12813bfff9fa; Mon, 01 Jun 2020 09:13:03 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: viemTyYNZzVUTDSU1LA4Tvf48+n77yXbjI0CMcFyKg5TBDNA9LGYwIdZRKLCZN2TM6NUDhM3wP FTeQgmOXn7NxK2TVdwBOB1mzuCuS0DywKcIXE8DrWZTyXRN9iwBAqTtPhfYVvHY+1LCSX1tn4i 39nT61HGHrp9rrXvXVFo8f6mQeIEDQLKjhKRi9Rs4KuvZwVQQn+JlZmbHLJDYc5sUQvsh5ugsn YFXP+OLx5nbw7ZWjBQr1qiUBTbODiqxKs9CSfZD6+Ff+TdiM5n2VUlmogBApYLy2k/yWcTCdyX iFE= X-SBRS: 2.7 X-MesageID: 18896880 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,460,1583211600"; d="scan'208";a="18896880" Date: Mon, 1 Jun 2020 11:12:56 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH v2 2/3] build32: don't discard .shstrtab in linker script Message-ID: <20200601091256.GR1195@Air-de-Roger> References: <20200528144023.10814-1-roger.pau@citrix.com> <20200528144023.10814-3-roger.pau@citrix.com> <41429ddc-a6c3-ddba-97d6-aeb413df1960@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41429ddc-a6c3-ddba-97d6-aeb413df1960@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 05:45:44PM +0200, Jan Beulich wrote: > On 28.05.2020 16:40, Roger Pau Monne wrote: > > LLVM linker doesn't support discarding .shstrtab, and complains with: > > > > ld -melf_i386_fbsd -N -T build32.lds -o reloc.lnk reloc.o > > ld: error: discarding .shstrtab section is not allowed > > Well, yes, GNU ld is more intelligent and doesn't extend the > discarding to the control sections in the first place. All > of .symtab, .strtab, and .shstrtab are still there. > > > Add an explicit .shstrtab section to the linker script after the text > > section in order to make LLVM LD happy. > > > > Signed-off-by: Roger Pau Monné > > Assuming the change was tested to not confuse GNU ld > Acked-by: Jan Beulich Yes, it's been tested on the gitlab CI, no issues reported on any of the builds: https://gitlab.com/xen-project/people/royger/xen/pipelines/151009839 > I wouldn't mind extending this to the other two control > sections named above. In case the binaries need picking > apart, them being present is surely helpful. I don't mind extending, it might make sense in case linkers start complaining about trying to discard those too. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 01 09:59:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 09:59:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfhDV-0004rP-B1; Mon, 01 Jun 2020 09:58:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfhDT-0004rK-Ar for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 09:58:47 +0000 X-Inumbo-ID: 7ba1b52c-a3ee-11ea-9dbe-bc764e2007e4 Received: from aserp2120.oracle.com (unknown [141.146.126.78]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7ba1b52c-a3ee-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 09:58:46 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0519v5qo042967; Mon, 1 Jun 2020 09:58:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=corp-2020-01-29; bh=+MWb0NMAavkFKneRr+1BaI52k7RdQE32+asYQPFsXs8=; b=u893gaEWiwlmBK8N8qW/iMWFiy9K5zfsfvTh3ZeQPvIb5CgpufH/2DtrtlbBxAX7l5Y+ pI+WsBDxM9X3W67JQ3+qOqBh9Aqk+qlL9nfvUpMIzKGhfX+tJrvevHKia8bhl4PAG6N2 6IenKHArPG5o8nBtOJdo8Ec8JbVsOyP0QU872/DSv3iz3ZtAd+TDH0JCEmtSmtsyYPPX /XDb4H1GZIl5FqW3HNqUXE4OZiUh+HUeQHY6/l9vfCrx05A5YbdXHUkGZUod805smOC/ KBm4+OPwuPR5Ba0wX8sgZvHlXvJVfluHby2mh3dpTyK8+NzA7jW4VDQ6Sejc7q+RmrqO 0Q== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 31bfekwv3b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 01 Jun 2020 09:58:22 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0519lqT9033852; Mon, 1 Jun 2020 09:56:21 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 31c25j7x1a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 01 Jun 2020 09:56:21 +0000 Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0519uElR022723; Mon, 1 Jun 2020 09:56:14 GMT Received: from tomti.i.net-space.pl (/10.175.213.92) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2020 02:56:13 -0700 Date: Mon, 1 Jun 2020 11:56:05 +0200 From: Daniel Kiper To: Andy Lutomirski Subject: Re: [BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot and others Message-ID: <20200601095605.oxhq74llusb7k6ma@tomti.i.net-space.pl> References: <20200529112735.qln44ds6z7djheof@tomti.i.net-space.pl> <7FE0DF48-C221-460E-99D5-00E42128283C@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7FE0DF48-C221-460E-99D5-00E42128283C@amacapital.net> User-Agent: NeoMutt/20170113 (1.7.2) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9638 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 spamscore=0 malwarescore=0 bulkscore=0 mlxscore=0 phishscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006010072 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9638 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 phishscore=0 clxscore=1011 impostorscore=0 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006010073 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: dpsmith@apertussolutions.com, alexander.burmashev@oracle.com, krystian.hebel@3mdeb.com, hpa@zytor.com, michal.zygowski@3mdeb.com, grub-devel@gnu.org, x86@kernel.org, javierm@redhat.com, kanth.ghatraju@oracle.com, ross.philipson@oracle.com, xen-devel@lists.xenproject.org, leif@nuviainc.com, trenchboot-devel@googlegroups.com, alec.brown@oracle.com, mtottenh@akamai.com, konrad.wilk@oracle.com, phcoder@gmail.com, piotr.krol@3mdeb.com, ard.biesheuvel@linaro.org, andrew.cooper3@citrix.com, linux-kernel@vger.kernel.org, mjg59@google.com, eric.snowberg@oracle.com, pjones@redhat.com, lukasz.hawrylko@linux.intel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 10:11:40AM -0700, Andy Lutomirski wrote: > > On May 29, 2020, at 4:30 AM, Daniel Kiper wrote: > > > > Hey, > > > > Below you can find my rough idea of the bootloader log format which is > > generic thing but initially will be used for TrenchBoot work. I discussed > > this proposal with Ross and Daniel S. So, the idea went through initial > > sanitization. Now I would like to take feedback from other folks too. > > So, please take a look and complain... > > > In general we want to pass the messages produced by the bootloader to the OS > > kernel and finally to the userspace for further processing and analysis. Below > > is the description of the structures which will be used for this thing. > > Is the intent for a human to read these, or to get them into the > system log file, or are they intended to actually change the behavior > of the system? > > IOW, what is this for? In general the idea is for a human to read these. There will be a separate tool which reads the bootloader log exposed via Linux kernel sysfs and displays its contents to the user. The tool will allow user to do various kinds of filtering. We are not going to put the contents of the bootloader log into any of system logs. However, if somebody wants to do that, in sensible way, I am OK with that. Daniel From xen-devel-bounces@lists.xenproject.org Mon Jun 01 10:14:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 10:14:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfhRv-0006cf-PD; Mon, 01 Jun 2020 10:13:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfhRu-0006ca-RQ for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 10:13:42 +0000 X-Inumbo-ID: 8eb10c38-a3f0-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8eb10c38-a3f0-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 10:13:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=T0OKdrCLZKPIKdEMLUwfBy5FW0gDDnm+IdqrwjXZEY4=; b=nBo+ECUFN5zvqDCzRk10jPvis UbQJimyoVZc41JFV1ij/9v4KGTbfwomBSaghC/nh9EleJnk8BP8sAEFMKeavFW5hBravIR+IvM+gd PoNGpkDnNZbVt3/ntXfuUi5SK8Ycd4vxvv+rpNYtfX3T0B+gUqpHE9p5QPYodefrLtkm0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfhRo-0006V9-Av; Mon, 01 Jun 2020 10:13:36 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfhRn-0005Yy-U7; Mon, 01 Jun 2020 10:13:36 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfhRn-0006b6-TW; Mon, 01 Jun 2020 10:13:35 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150594: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ad33a573c009d72466432b41ba0591c64e819c19 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Mon, 01 Jun 2020 10:13:35 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150594 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150594/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen ad33a573c009d72466432b41ba0591c64e819c19 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 3 days Failing since 150465 2020-05-29 09:02:14 Z 3 days 28 attempts Testing same since 150515 2020-05-30 01:00:47 Z 2 days 18 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1196 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 10:55:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 10:55:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfi5i-0001Zo-2A; Mon, 01 Jun 2020 10:54:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfi5g-0001Zj-9v for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 10:54:48 +0000 X-Inumbo-ID: 4e3e1794-a3f6-11ea-ab0a-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4e3e1794-a3f6-11ea-ab0a-12813bfff9fa; Mon, 01 Jun 2020 10:54:46 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: dE4OJlvFGeDUUtAzk3Pi5zV28ZQIW5UOP7UQrOT5lcQFU2YWh+Xc0k4Dbio1M5jzIQRGIdcbgX T0UA6G1hW8qVM0IXQuYrEA++MNqKuY+BQHzK8tdGNAXiBGrCA+PzIKy+tFZB/X5eMboLe8OBRi W/yT9uFgzTE+mD8IurFET4SeUBhqARgj1gOIEfCdjngudjQ7bEGpkuIoJXc0yVJffNpn7AyqoH Ac5ZSqvawoklGR18qCojrS7GFT73+YeKkHaDVpPE0iJZTpsNv82xn7a5GQ7gS4FqVLy6QkZWmH zDk= X-SBRS: 2.7 X-MesageID: 19251855 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,460,1583211600"; d="scan'208";a="19251855" Date: Mon, 1 Jun 2020 12:54:37 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Daniel Kiper Subject: Re: [BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot and others Message-ID: <20200601105437.GS1195@Air-de-Roger> References: <20200529112735.qln44ds6z7djheof@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <20200529112735.qln44ds6z7djheof@tomti.i.net-space.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: dpsmith@apertussolutions.com, alexander.burmashev@oracle.com, krystian.hebel@3mdeb.com, hpa@zytor.com, michal.zygowski@3mdeb.com, grub-devel@gnu.org, x86@kernel.org, javierm@redhat.com, kanth.ghatraju@oracle.com, phcoder@gmail.com, xen-devel@lists.xenproject.org, leif@nuviainc.com, trenchboot-devel@googlegroups.com, alec.brown@oracle.com, mtottenh@akamai.com, konrad.wilk@oracle.com, ross.philipson@oracle.com, piotr.krol@3mdeb.com, ard.biesheuvel@linaro.org, andrew.cooper3@citrix.com, linux-kernel@vger.kernel.org, mjg59@google.com, eric.snowberg@oracle.com, pjones@redhat.com, lukasz.hawrylko@linux.intel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 01:27:35PM +0200, Daniel Kiper wrote: > Hey, > > Below you can find my rough idea of the bootloader log format which is > generic thing but initially will be used for TrenchBoot work. I discussed > this proposal with Ross and Daniel S. So, the idea went through initial > sanitization. Now I would like to take feedback from other folks too. > So, please take a look and complain... > > In general we want to pass the messages produced by the bootloader to the OS > kernel and finally to the userspace for further processing and analysis. Below > is the description of the structures which will be used for this thing. > > struct bootloader_log_msgs > { > grub_uint32_t level; > grub_uint32_t facility; Nit: if this is aimed at cross-OS and cross-bootloader compatibility uint32_t should be used here instead of a grub specific alias. > char type[]; > char msg[]; I think you want char * here instead? Or are the above arrays expected to have a fixed size in the final spec? > } > > struct bootloader_log > { > grub_uint32_t version; > grub_uint32_t producer; > grub_uint32_t size; > grub_uint32_t next_off; > bootloader_log_msgs msgs[]; As I understand it this is not a pointer to an array of bootloader_log_msgs but rather in-place? > } > > The members of struct bootloader_log: > - version: the bootloader log format version number, 1 for now, > - producer: the producer/bootloader type; we can steal some values from > linux/Documentation/x86/boot.rst:type_of_loader, > - size: total size of the log buffer including the bootloader_log struct, > - next_off: offset in bytes, from start of the bootloader_log struct, > of the next byte after the last log message in the msgs[]; > i.e. the offset of the next available log message slot, So this will be a memory area that's shared between the OS and the bootloader and needs to be updated at runtime? If this is something that's created by the bootloader during loading and passed to the OS for consumption (but it's not further updated), I don't see much point in the next_off field. The size field could be updated to reflect the actual size of the produced messages? Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 01 11:15:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 11:15:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfiPR-0003LR-OQ; Mon, 01 Jun 2020 11:15:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfiPQ-0003LM-4w for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 11:15:12 +0000 X-Inumbo-ID: 2842b38a-a3f9-11ea-9dbe-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2842b38a-a3f9-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 11:15:11 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id u26so11832249wmn.1 for ; Mon, 01 Jun 2020 04:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:references:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WQfJzqFfEaKfIfQ4a6l8KRYhHeFJRpYVrfeth7NbeaI=; b=W205YNhfbTjoAc+Sq9+SlEL7WiYKF5b9v5yHkY4DXyopHwJPg1SVVv2w9oIR4mdeiZ ST7h/2FQ9CrppRhn/J3bbwaLc+m7JhXGYYfwf5FoKVkAUCjHbK313p/oDAqp2+OiuQ4r motnab8vc2Rmd52V5L1Dr5cM5M/i7mdN+/Dt0ouAXWYIbm5zhpt61VXyfHGvHPrr0CoC wKuMWlY18eN+lp9S+laQKKZIlnLpzKuhpFWE7JvJMAv3TcbsEatQsReoROr3bwq1WeHg vCiXw550PsuSZzZCt6W4rjSmzJMMRbo4nTwPZfhJQQRMppYXbS56RbzP2oVOjhURm1dj /GwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:references:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=WQfJzqFfEaKfIfQ4a6l8KRYhHeFJRpYVrfeth7NbeaI=; b=il1X+Re19Lg+wdconpcKe8VC7U5QMLNujdKLL4F0ARqPx4eWkXKD8u2x6dE+4FfRvk Vw3weHKdTee12P/2pni/xdjOzfJlngWaZwfkETmsSsQUB3li36GW/1SsXy/8blvGo4Af o7rahKq0WzDcShfEjvK/1yMvlz3b6jLJcS/MnpuwJ5ocYUAD2u5bjgkYYICQHoJv+mY+ NtH2PTRT3f7ky1pHyalJBLU6hLF3ZaRQuFjKLE0yOq1QHcCcaRJa3PtY8IuL3MBrBxFd JWQT2axIh3SJIuY9BEZWUAaNhBAHCFHM7p9/o+pzqq6KCZYad7g94UnIvi5mJ3JlDboC hdMQ== X-Gm-Message-State: AOAM533iV3CjNRDnO6HmMZeVsnMlI5bo2tPOFbwVdQVVCMFwtCOY4yB2 Q14Y+cmP+LMb+Fxv2PHbG6w= X-Google-Smtp-Source: ABdhPJyRaQ6tyLCXSzXBsr+8m+WKjmt1MKBaf3ZRhDkXsuFSkOG19192WzS4X+s7FDROQp6EsdbLZQ== X-Received: by 2002:a1c:305:: with SMTP id 5mr20766893wmd.60.1591010110216; Mon, 01 Jun 2020 04:15:10 -0700 (PDT) Received: from [192.168.1.34] (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id v27sm21731098wrv.81.2020.06.01.04.15.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 04:15:09 -0700 (PDT) Subject: Re: [PATCH 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= To: paul@xen.org, qemu-devel@nongnu.org References: <20200531173814.8734-1-f4bug@amsat.org> <20200531173814.8734-8-f4bug@amsat.org> <000001d637e5$f0c4b4f0$d24e1ed0$@xen.org> <63327be6-10c1-6a8c-b4ed-cbbd085a35a8@amsat.org> Autocrypt: addr=f4bug@amsat.org; keydata= mQINBDU8rLoBEADb5b5dyglKgWF9uDbIjFXU4gDtcwiga9wJ/wX6xdhBqU8tlQ4BroH7AeRl u4zXP0QnBDAG7EetxlQzcfYbPmxFISWjckDBFvDbFsojrZmwF2/LkFSzlvKiN5KLghzzJhLO HhjGlF8deEZz/d/G8qzO9mIw8GIBS8uuWh6SIcG/qq7+y+2+aifaj92EdwU79apZepT/U3vN YrfcAuo1Ycy7/u0hJ7rlaFUn2Fu5KIgV2O++hHYtCCQfdPBg/+ujTL+U+sCDawCyq+9M5+LJ ojCzP9rViLZDd/gS6jX8T48hhidtbtsFRj/e9QpdZgDZfowRMVsRx+TB9yzjFdMO0YaYybXp dg/wCUepX5xmDBrle6cZ8VEe00+UQCAU1TY5Hs7QFfBbjgR3k9pgJzVXNUKcJ9DYQP0OBH9P ZbZvM0Ut2Bk6bLBO5iCVDOco0alrPkX7iJul2QWBy3Iy9j02GnA5jZ1Xtjr9kpCqQT+sRXso Vpm5TPGWaWljIeLWy/qL8drX1eyJzwTB3A36Ck4r3YmjMjfmvltSZB1uAdo1elHTlFEULpU/ HiwvvqXQ9koB15U154VCuguvx/Qnboz8GFb9Uw8VyawzVxYVNME7xw7CQF8FYxzj6eI7rBf2 Dj/II6wxWPgDEy3oUzuNOxTB7sT3b/Ym76yOJzWX5BylXQIJ5wARAQABtDFQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoRjRCVUcpIDxmNGJ1Z0BhbXNhdC5vcmc+iQJVBBMBCAA/AhsPBgsJ CAcDAgYVCAIJCgsEFgIDAQIeAQIXgBYhBPqr514SkXIh3P1rsuPjLCzercDeBQJd660aBQks klzgAAoJEOPjLCzercDe2iMP+gMG2dUf+qHz2uG8nTBGMjgK0aEJrKVPodFA+iedQ5Kp3BMo jrTg3/DG1HMYdcvQu/NFLYwamUfUasyor1k+3dB23hY09O4xOsYJBWdilkBGsJTKErUmkUO2 3J/kawosvYtJJSHUpw3N6mwz/iWnjkT8BPp7fFXSujV63aZWZINueTbK7Y8skFHI0zpype9s loU8xc4JBrieGccy3n4E/kogGrTG5jcMTNHZ106DsQkhFnjhWETp6g9xOKrzZQbETeRBOe4P sRsY9YSG2Sj+ZqmZePvO8LyzGRjYU7T6Z80S1xV0lH6KTMvq7vvz5rd92f3pL4YrXq+e//HZ JsiLen8LH/FRhTsWRgBtNYkOsd5F9NvfJtSM0qbX32cSXMAStDVnS4U+H2vCVCWnfNug2TdY 7v4NtdpaCi4CBBa3ZtqYVOU05IoLnlx0miKTBMqmI05kpgX98pi2QUPJBYi/+yNu3fjjcuS9 K5WmpNFTNi6yiBbNjJA5E2qUKbIT/RwQFQvhrxBUcRCuK4x/5uOZrysjFvhtR8YGm08h+8vS n0JCnJD5aBhiVdkohEFAz7e5YNrAg6kOA5IVRHB44lTBOatLqz7ntwdGD0rteKuHaUuXpTYy CRqCVAKqFJtxhvJvaX0vLS1Z2dwtDwhjfIdgPiKEGOgCNGH7R8l+aaM4OPOd Message-ID: <3b4fdc66-ea78-2270-a67a-6d9138fc12c4@amsat.org> Date: Mon, 1 Jun 2020 13:15:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <63327be6-10c1-6a8c-b4ed-cbbd085a35a8@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Peter Maydell' , 'Stefano Stabellini' , 'Eduardo Habkost' , "'Michael S. Tsirkin'" , 'Andrew Jeffery' , 'Helge Deller' , qemu-trivial@nongnu.org, =?UTF-8?Q?=27C=c3=a9dric_Le_Goater=27?= , qemu-arm@nongnu.org, =?UTF-8?Q?=27Herv=c3=a9_Poussineau=27?= , 'Joel Stanley' , 'Paolo Bonzini' , 'Anthony Perard' , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, 'Richard Henderson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 10:33 AM, Philippe Mathieu-Daudé wrote: > On 6/1/20 9:26 AM, Paul Durrant wrote: >>> -----Original Message----- >>> From: Philippe Mathieu-Daudé On Behalf Of Philippe Mathieu-Daudé >>> Sent: 31 May 2020 18:38 >>> To: qemu-devel@nongnu.org >>> Cc: Andrew Jeffery ; Helge Deller ; Peter Maydell >>> ; Richard Henderson ; Eduardo Habkost >>> ; Paul Durrant ; Hervé Poussineau ; Marcel >>> Apfelbaum ; xen-devel@lists.xenproject.org; Paolo Bonzini >>> ; Stefano Stabellini ; Cédric Le Goater ; >>> qemu-trivial@nongnu.org; Joel Stanley ; qemu-arm@nongnu.org; Michael S. Tsirkin >>> ; Anthony Perard ; qemu-ppc@nongnu.org; Philippe Mathieu- >>> Daudé >>> Subject: [PATCH 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions >>> >>> IEC binary prefixes ease code review: the unit is explicit. >>> >>> Signed-off-by: Philippe Mathieu-Daudé >>> --- >>> hw/i386/xen/xen-hvm.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c >>> index 82ece6b9e7..679d74e6a3 100644 >>> --- a/hw/i386/xen/xen-hvm.c >>> +++ b/hw/i386/xen/xen-hvm.c >>> @@ -9,6 +9,7 @@ >>> */ >>> >>> #include "qemu/osdep.h" >>> +#include "qemu/units.h" >>> >>> #include "cpu.h" >>> #include "hw/pci/pci.h" >>> @@ -230,7 +231,7 @@ static void xen_ram_init(PCMachineState *pcms, >>> * Xen does not allocate the memory continuously, it keeps a >>> * hole of the size computed above or passed in. >>> */ >>> - block_len = (1ULL << 32) + x86ms->above_4g_mem_size; >>> + block_len = 4 * GiB + x86ms->above_4g_mem_size; >> >> Not strictly necessary but could we retain the brackets please? > > Sure. > > Laurent, if this can go via your trivial@ tree, can you do the change or > you rather I resend the whole series? I understood reading another thread that contributor should not overload maintainer, so I'll simply repost this as v2. https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00066.html > >> >> Paul >> >>> } >>> memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len, >>> &error_fatal); >>> -- >>> 2.21.3 >> >> >> > From xen-devel-bounces@lists.xenproject.org Mon Jun 01 11:29:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 11:29:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jficm-0004L1-4B; Mon, 01 Jun 2020 11:29:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfick-0004Ks-Vs for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 11:28:59 +0000 X-Inumbo-ID: 14ef78a2-a3fb-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 14ef78a2-a3fb-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 11:28:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CCeIz11SbT5mVtjZQPh0ajbQbevqMp4Axzmfr2VIXbA=; b=ziZGMxe/F8pNMz7ck5IOaUuTA +d6760bQlwXdn/OSc+EWGcVpL5HyUxxcXxoyTPgZS+coydHExg/Ukjzv9GThQU6rJAsl+fvnY/lF4 bD68kh5EbYDClQ4pC/aaEbWGcdY50+GNzM2qEZUqndyw/+49EKAVjNXwUkVm16UD6v3Hk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfici-00081b-Fn; Mon, 01 Jun 2020 11:28:56 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfici-0000PM-0j; Mon, 01 Jun 2020 11:28:56 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfici-00045P-08; Mon, 01 Jun 2020 11:28:55 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150589: tolerable FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug xen-unstable:test-amd64-coresched-i386-xl:guest-localmigrate:fail:heisenbug xen-unstable:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install/l1/l2:fail:heisenbug xen-unstable:test-amd64-amd64-qemuu-nested-intel:capture-logs/l1(18):fail:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Mon, 01 Jun 2020 11:28:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150589 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150589/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 16 guest-localmigrate fail in 150551 pass in 150589 test-amd64-coresched-i386-xl 16 guest-localmigrate fail pass in 150551 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail pass in 150551 Tests which did not succeed, but are not blocking: test-amd64-amd64-qemuu-nested-intel 18 capture-logs/l1(18) fail blocked in 150551 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150529 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150551 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150551 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150551 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150551 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150551 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150551 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150551 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150551 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150551 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150551 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass version targeted for testing: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150589 2020-06-01 01:52:18 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl fail test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Mon Jun 01 12:21:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 12:21:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjQn-0000p4-95; Mon, 01 Jun 2020 12:20:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjQm-0000oz-5c for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 12:20:40 +0000 X-Inumbo-ID: 4d683118-a402-11ea-8993-bc764e2007e4 Received: from mail-lj1-x231.google.com (unknown [2a00:1450:4864:20::231]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4d683118-a402-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 12:20:39 +0000 (UTC) Received: by mail-lj1-x231.google.com with SMTP id o9so7853048ljj.6 for ; Mon, 01 Jun 2020 05:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oWaSScPdF0/LBmZ/G8Aq2m32ZqmFc/6qkFfGD8k3UD0=; b=A9BhzkkN6NyjQx0Vt/b6gkwh5Q9VamXnhfXr4KFqQWmQnBPwhAcZHltq1hEptUQ6dy ZmPINi1CssA43O8icizcJKRqEQQ862NUE5pw0Tkc38SyeOHWPbfobmUP6bDokTXf7e0s o3SyBzKYTZGDD6Me5cpmS64eH7KWYoYUT1GCwQIaWKWPsCLiuMWAL0epQfhRHU4QK7NC Lm6oyMeLB/E9UxWap3AUPa7IwmuRTvhIdYAitekA85XBsEgcpdy0jRj9vrDqKY5qExAr UQG8jSujMT8C9ATrnmagJGm6r1L6Aq0cCXbRf1k5n+t2ZprGymLtyFVACRnzGIwG/57A w2Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oWaSScPdF0/LBmZ/G8Aq2m32ZqmFc/6qkFfGD8k3UD0=; b=rV/I3EDqItP4BxfUwlFc7r3MN2HfWXzQ5tQte3iGYfDKEo4kJ0yFr1wHsbFAYs1JAE 97yMnrZ40M2yFC22xx7v7JLmVZgESaEWxeFicTFe/l0mvmeGn5WZCd3FNUYUHAOjwHDc mrQsgRuCFYhuk0LFraenw0SovtSeey/8tYtZudHNymRArwsZvppdniLYFvP3rG0CXg1H ENSn7dOzUjlTvO2GfNrgukSfAaDzSsAHdqCUZKIR+HmLKyVTRJ2YNHLMKvKNUunnh6Jl fvisbgL97ZBAnN2JoMvRmadoyPBynTgtQKn1W3d3VgL7PSmzuGICX6gIUIlJ8he9vNKJ qSOw== X-Gm-Message-State: AOAM530hLRfg1FQAI7FagvrPVdGOZo3ypmDkpAU4Av1Ym1QendYL2ARq THNpr8FunGqxjpGEh4rNTIICXNyYH3XkNcxhXUY= X-Google-Smtp-Source: ABdhPJwTm3RfwGpbNOTTw9xuUm60S9zzPUiP8o4pCehKWu2KgF2wYiyl3+JsUsnQbdqJd2A4DRZXptcSDYqUaiqNYkU= X-Received: by 2002:a05:651c:105a:: with SMTP id x26mr10692350ljm.159.1591014037989; Mon, 01 Jun 2020 05:20:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: buy computer Date: Mon, 1 Jun 2020 15:20:25 +0300 Message-ID: Subject: Re: iommu=no-igfx To: "Tian, Kevin" Content-Type: multipart/alternative; boundary="000000000000912c6b05a704d248" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --000000000000912c6b05a704d248 Content-Type: text/plain; charset="UTF-8" On Thu, May 28, 2020 at 11:34 AM Tian, Kevin wrote: > You may search dma_map* in drivers/gpu/drm/i915, and then print mapped > addresses to see any match in VT-d reported faulting addresses. For > example, __setup_page_dma might be one example that you want to check. > Unfortunately, I'm not really clear on how to do that too. I've found drivers/gpu/drm/i915, and it contains one file, i915.ko. Using cat prints out unformatted text. How do I access this data? Internet searches have again come up dry for me, sorry if this question isn't on the level. --000000000000912c6b05a704d248 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000912c6b05a704d248-- From xen-devel-bounces@lists.xenproject.org Mon Jun 01 12:44:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 12:44:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjny-0002di-AO; Mon, 01 Jun 2020 12:44:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjnw-0002dd-6T for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 12:44:36 +0000 X-Inumbo-ID: a5a6d5b6-a405-11ea-9dbe-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a5a6d5b6-a405-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 12:44:35 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jfjnu-0006zf-FG; Mon, 01 Jun 2020 13:44:34 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 1/4] cs-bisection-step: Change some url. references to job. Date: Mon, 1 Jun 2020 13:44:27 +0100 Message-Id: <20200601124430.29761-1-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This query is going to turn into two variants, one of which doesn't have the url join. In the output, prefer to refer to fields from job. They are constrained to be equal (and they are not null) so this has no functional change. Also swap the conditions over for clarity. No functional change. Signed-off-by: Ian Jackson --- cs-bisection-step | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/cs-bisection-step b/cs-bisection-step index 16227234..f9ef1558 100755 --- a/cs-bisection-step +++ b/cs-bisection-step @@ -231,8 +231,8 @@ END SELECT url.val AS uval, rev.val AS rval, - url.job AS job, - ${\ other_revision_job_suffix('url.job','url.use',' ') } AS othrev, + rev.job AS job, + ${\ other_revision_job_suffix('rev.job','rev.use',' ') } AS othrev, url.name AS longname FROM tmp_build_info AS rev @@ -241,8 +241,8 @@ END WHERE (rev.name LIKE E'built\\_revision\\_%' OR rev.name LIKE E'revision\\_%') AND url.name LIKE E'tree\\_%' - AND rev.use = url.use - AND rev.job = url.job + AND url.use = rev.use + AND url.job = rev.job AND (rev.name = 'built_revision_' || substr(url.name,6) OR rev.name = 'revision_' || substr(url.name,6)) -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 12:44:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 12:44:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjo1-0002dy-Hu; Mon, 01 Jun 2020 12:44:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjo1-0002dr-51 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 12:44:41 +0000 X-Inumbo-ID: a5ccaf0c-a405-11ea-9947-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a5ccaf0c-a405-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 12:44:35 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jfjnu-0006zf-Qv; Mon, 01 Jun 2020 13:44:34 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 2/4] cs-bisection-step: flight_rmap Disassemble the revisions query Date: Mon, 1 Jun 2020 13:44:28 +0100 Message-Id: <20200601124430.29761-2-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200601124430.29761-1-ian.jackson@eu.citrix.com> References: <20200601124430.29761-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Break out various pieces that we are going to need to reuse for the other version of this query (which won't have the url join). Also, rather than retrieving the `tree_' runvar and calculating the tree name from that, use the `[built_]revision_' runvar from rev. No overall functional change. Signed-off-by: Ian Jackson --- cs-bisection-step | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/cs-bisection-step b/cs-bisection-step index f9ef1558..b36bac05 100755 --- a/cs-bisection-step +++ b/cs-bisection-step @@ -227,19 +227,30 @@ END AND flight = ? END - my $sth= db_prepare(<execute(); my $row; @@ -255,7 +265,7 @@ END my (@ttreenames, @ttreeurls, @trevisions); while ($row= $sth->fetchrow_hashref()) { next if $row->{othrev} eq 'DISCARD'; - $row->{longname} =~ m/^tree_/ or die "$row->{longname} ?"; + $row->{revname} =~ m/^(?:built_)?revision_/ or die "$row->{revname} ?"; my $name= $'; #' print DEBUG " $flight.$row->{job} uval=$row->{uval}". " rval=$row->{rval} name=$name othrev=\`$row->{othrev}'\n"; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 12:44:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 12:44:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjo6-0002eP-QF; Mon, 01 Jun 2020 12:44:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjo6-0002eE-4e for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 12:44:46 +0000 X-Inumbo-ID: a5ec422c-a405-11ea-9947-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a5ec422c-a405-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 12:44:35 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jfjnv-0006zf-13; Mon, 01 Jun 2020 13:44:35 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 3/4] cs-bisection-step: Provide no-urls variant of the main query Date: Mon, 1 Jun 2020 13:44:29 +0100 Message-Id: <20200601124430.29761-3-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200601124430.29761-1-ian.jackson@eu.citrix.com> References: <20200601124430.29761-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This variant just returns '' for urls. Unlike the with-urls variant, it does not ignore trees without urls. Signed-off-by: Ian Jackson --- cs-bisection-step | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/cs-bisection-step b/cs-bisection-step index b36bac05..2f75313e 100755 --- a/cs-bisection-step +++ b/cs-bisection-step @@ -181,6 +181,7 @@ END sub flight_rmap ($) { my ($flight) = @_; + my $need_urls = 1; $dbh_tests->do(<execute(); my $row; my $mixed=0; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 12:45:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 12:45:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjoC-0002fY-2n; Mon, 01 Jun 2020 12:44:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfjoB-0002fM-4r for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 12:44:51 +0000 X-Inumbo-ID: a606e636-a405-11ea-9947-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a606e636-a405-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 12:44:36 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jfjnv-0006zf-7q; Mon, 01 Jun 2020 13:44:35 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 4/4] cs-bisection-step: Do not insist on urls in main history search Date: Mon, 1 Jun 2020 13:44:30 +0100 Message-Id: <20200601124430.29761-4-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200601124430.29761-1-ian.jackson@eu.citrix.com> References: <20200601124430.29761-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" If a Xen build fails, but we are trying to bisect something involving libvirt, the libvirt job does not really run. It does not populate the tree_ values for its git submodules - that would involve actually booking out a host and cloning it. The effect is that xen build failures which occur somewhere in the range of a libvirt bisection cause total failure (actually, looping bisection) rather than treating the build failure as `blocked'. Fix this by tolerating trees with missing urls - but only during the main history search. Most of the rest of the time we need the urls, mainly because we are going to feed them to adhoc-revtuple-generator and mention them in our output. It could now happen that trees appear in the main bisection history which weren't in our bases. These end up being ignored by flight_rtuple. This is not ideal but it will do for now. In any case that aspect is no worse than before. Signed-off-by: Ian Jackson --- cs-bisection-step | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/cs-bisection-step b/cs-bisection-step index 2f75313e..478baa5b 100755 --- a/cs-bisection-step +++ b/cs-bisection-step @@ -179,9 +179,8 @@ sub relevant_hosts ($) { END } -sub flight_rmap ($) { - my ($flight) = @_; - my $need_urls = 1; +sub flight_rmap ($$) { + my ($flight, $need_urls) = @_; $dbh_tests->do(<{flight}); + my $failrmap = flight_rmap($tryfail->{flight},1); next unless $failrmap; my $checkbasisvcs = sub { my ($trybasisflight) = @_; - my $basisrmap = flight_rmap($trybasisflight); + my $basisrmap = flight_rmap($trybasisflight,1); my @bad; #print STDERR Dumper($failrmap, $basisrmap); foreach my $tree (keys %$failrmap) { @@ -480,8 +479,8 @@ END our (%nodes, @latest_rtuple, @basispass_rtuple); sub digraph_whole () { - my $latest_rmap= flight_rmap($latest_flight); - my $basispass_rmap= flight_rmap($basispass_flight); + my $latest_rmap= flight_rmap($latest_flight,1); + my $basispass_rmap= flight_rmap($basispass_flight,1); if (!defined $basispass_rmap) { die "Basis pass $basispass_flight rmap indeterminate/wrong\n"; } -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 12:57:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 12:57:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfk0O-0003sW-8T; Mon, 01 Jun 2020 12:57:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfk0N-0003sR-13 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 12:57:27 +0000 X-Inumbo-ID: 6ffea176-a407-11ea-ab1a-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6ffea176-a407-11ea-ab1a-12813bfff9fa; Mon, 01 Jun 2020 12:57:24 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: IF9IhDIb8z5HA63MExg7zcGbq0nBJdNoTHWrunxUYtLJYR+IXGLipaSg+S7ZnIonO0Lr+3scO0 srRpMHlInlXuv7qVUhviqypG42r7BBAYVzWMMToxHQOUoZBmtXrWCdlXbqQVwb/FJ6r3ao3cad 0wMWjvtD1iWgRc0se1mtJ41zBoCyvIb9Vpodif4IviotIItwCyC2yu1eC4vheP8J1VbTb7Bc59 MXjiPVLHfznVXGTNUfegKeK20kqkfvlZLAVy2macqJ9z7EebRH0m+MZgPYNkCaplMcoK93apOX Lg8= X-SBRS: 2.7 X-MesageID: 19171798 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,460,1583211600"; d="scan'208";a="19171798" From: George Dunlap To: Julien Grall Subject: Re: Xen XSM/FLASK policy, grub defaults, etc. Thread-Topic: Xen XSM/FLASK policy, grub defaults, etc. Thread-Index: AQHWND0/xSJFUOR5YU28XikgbPuX46i7+DWAgALLwwCAAANFAIAABtKAgAA4IwCAAAT9gIAAAZ+AgAAlWICABGw3AA== Date: Mon, 1 Jun 2020 12:57:20 +0000 Message-ID: References: <24270.35349.838484.116865@mariner.uk.xensource.com> <0D83AAA6-A205-4256-8A38-CC8122AC063D@citrix.com> <24272.59646.746545.343358@mariner.uk.xensource.com> <4a8e7cf2-8f63-d4d2-e051-9484a5b8c8ed@suse.com> <96F32637-E410-4EC8-937A-CFC8BE724352@citrix.com> <24273.8332.662607.125522@mariner.uk.xensource.com> <7eaa7541-f698-b29b-b4b3-1f40fc37c5d7@xen.org> <63838ce9-8dbf-aacf-521d-97540758a945@suse.com> <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> In-Reply-To: <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <18BC10998DB961448B4DC0AAABF0EEA0@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , Stefano Stabellini , "cjwatson@debian.org" , Wei Liu , Andrew Cooper , Jan Beulich , "xen-devel@lists.xenproject.org" , Ian Jackson , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gTWF5IDI5LCAyMDIwLCBhdCA2OjI0IFBNLCBKdWxpZW4gR3JhbGwgPGp1bGllbkB4 ZW4ub3JnPiB3cm90ZToNCj4gDQo+IEhpIEphbiwNCj4gDQo+IE9uIDI5LzA1LzIwMjAgMTY6MTEs IEphbiBCZXVsaWNoIHdyb3RlOg0KPj4gT24gMjkuMDUuMjAyMCAxNzowNSwgSnVsaWVuIEdyYWxs IHdyb3RlOg0KPj4+IE9uIDI5LzA1LzIwMjAgMTU6NDcsIElhbiBKYWNrc29uIHdyb3RlOg0KPj4+ PiBHZW9yZ2UgRHVubGFwIHdyaXRlcyAoIlJlOiBYZW4gWFNNL0ZMQVNLIHBvbGljeSwgZ3J1YiBk ZWZhdWx0cywgZXRjLiIpOg0KPj4+Pj4gV2hpY2ggaXNu4oCZdCB0byBzYXkgd2Ugc2hvdWxkbuKA mXQgZG8gaXQ7IGJ1dCBpdCBtaWdodCBiZSBuaWNlIHRvIGFsc28gaGF2ZSBhbiBpbnRlcm1lZGlh dGUgc29sdXRpb24gdGhhdCB3b3JrcyByaWdodCBub3csIGV2ZW4gaWYgaXTigJlzIG5vdCBvcHRp bWFsLg0KPj4+PiANCj4+Pj4gSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgYmVoYXZpb3VyIGJ5IHVw ZHN0ZS1ncnViOg0KPj4+PiANCj4+Pj4gICAxLiBMb29rIGZvciBhbiBFTEYgbm90ZSwgVEJELiAg SWYgaXQncyBmb3VuZCwgbWFrZSBYU00gYm9vdCBlbnRyaWVzLg0KPj4+PiAgICAgIChGb3Igbm93 LCBza2lwIHRoaXMgc3RlcCwgc2luY2UgdGhlIEVMRiBub3RlIGlzIG5vdCBkZWZpbmVkLikNCj4+ PiANCj4+PiBJIGFtIGFmcmFpZCB0aGUgRUxGIG5vdGUgaXMgYSB2ZXJ5IHg4NiB0aGluZy4gT24g QXJtLCB3ZSBkb24ndCBoYXZlIHN1Y2gNCj4+PiB0aGluZyBmb3IgdGhlIGtlcm5lbC94ZW4gKGFj dHVhbGx5IHRoZSBmaW5hbCBiaW5hcnkgaXMgbm90IGV2ZW4gYW4gRUxGKS4NCj4+IE91Y2ggLSBv ZiBjb3Vyc2UuIElzIHRoZXJlIGFueXRoaW5nIHNpbWlsYXIgb25lIGNvdWxkIGVtcGxveSB0aGVy ZT8NCj4gDQo+IEluIHRoZSBwYXN0LCB3ZSBkaXNjdXNzZWQgYWJvdXQgYWRkaW5nIHN1cHBvcnQg Zm9yIG5vdGUgaW4gdGhlIHpJbWFnZSAoYXJtMzIga2VybmVsIGZvcm1hdCkgYnV0IEkgbmV2ZXIg Z290IHRoZSBjaGFuY2UgdG8gcHVyc3VlIHRoZSBkaXNjdXNzaW9uLg0KPiANCj4gV2l0aCBKdWVy Z2VuJ3MgaHlwZnMgc2VyaWVzLCB0aGUgaHlwZXJ2aXNvciBub3cgZW1iYmVkIHRoZSAuY29uZmln LiBJcyBpdCBwb3NzaWJsZSB0byBleHRyYWN0IGl0Pw0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IHVw ZGF0ZS1ncnViIGRvZXNu4oCZdCB3YW50IHRoZSBjb25maWcgb2YgdGhlICpjdXJyZW50bHkgcnVu bmluZyogaHlwZXJ2aXNvciwgYnV0IG9mIHdoYXRldmVyIHNwZWNpZmljIGh5cGVydmlzb3IgdGhl cmUgaXMgaW4gL2Jvb3QuDQoNClNvIGZvciBpbnN0YW5jZSwgd2hlbiBzb21lb25lIGZpcnN0IGRv ZXMg4oCcYXB0LWdldCBpbnN0YWxsIHhlbuKAnSwgYWZ0ZXIgeGVuIGJpbmFyaWVzIGFyZSBwdXQg aW4gL2Jvb3QsIHVwZGF0ZS1ncnViIGlzIGNhbGxlZCB0byBtYWtlIG5ldyBlbnRyaWVzIGZvciBp dC4gIElkZWFsbHksIHdlIHdhbnQgaXQgdG8gY3JlYXRlIEZMQVNLIGdydWIgZW50cmllcywgYW5k IGJvb3QgdGhlbSBieSBkZWZhdWx0LCBpZiBhbmQgb25seSBpZiAqdGhhdCBYZW4gYmluYXJ5KiBo YXMgRkxBU0sgZW5hYmxlZCBhbmQgdGhlcmUgaXMgYSBwb2xpY3kgZm9yIGl0LiAgQXQgdGhlIHRp bWUgdXBkYXRlLWdydWIgcnVucywgWGVuIHdpbGwgbm90IGJlIHJ1bm5pbmcuDQoNCkFuZCBpZiBh IHVzZXIgaW5zdGFsbHMgc2V2ZXJhbCBYZW4gYmluYXJpZXMsIHNvbWUgb2Ygd2hpY2ggaGF2ZSBG TEFTSyBlbmFibGVkIGFuZCBzb21lIG9mIHdoaWNoIGRvbuKAmXQsIHdlIHdhbnQgdXBkYXRlLWdy dWIgdG8gZ2VuZXJhdGUgRkxBU0sgZW50cmllcyBmb3IgdGhlIGJpbmFyaWVzIHRoYXQgaGF2ZSBG TEFTSyBlbmFibGVkLCBhbmQgbm90IGZvciB0aGUgb25lcyB3aGljaCBkb27igJl0LiAgU28gaHlw ZnMgaXNu4oCZdCByZWFsbHkgYSBzdWl0YWJsZSBzb2x1dGlvbi4NCg0KVGhlIG9wdGlvbnMgcHJv cG9zZWQgaGF2ZSBpbmNsdWRlZDoNCg0KMS4gTWFraW5nIHRoZSB0b29scyBub3QgZ2VuZXJhdGUg YSBGTEFTSyBwb2xpY3kgdW5sZXNzIEZMQVNLIGlzIGVuYWJsZWQgaW4gdGhlIGh5cGVydmlzb3Ig YmVpbmcgYnVpbHQuICBUaGlzIGlzIGZsYWt5IGJlY2F1c2UgdGhlcmXigJlzIG5vIG5lY2Vzc2Fy eSBjb25uZWN0aW9uIGJldHdlZW4gdGhlIHR3byBidWlsZHMuDQoNCjIuIFVzaW5nIHRoZSB4ZW4g Y29uZmlnIGZpbGUgbm9ybWFsbHkgY29waWVkIGludG8gL2Jvb3QuICBUaGlzIHNob3VsZCB3b3Jr IG5vdywgYnV0IGl04oCZcyBiZWVuIHN1Z2dlc3RlZCB0aGF0IHBhY2thZ2VycyBtYXkgbm90IHdh bnQgdG8gY29udGludWUgcHV0dGluZyB0aGUgeGVuIGNvbmZpZyBpbiAvYm9vdCBhbG9uZyB3aXRo IHhlbi5neiwganVzdCBhcyB0aGV54oCZdmUgc3RvcHBlZCBwdXR0aW5nIHRoZSBMaW51eCBjb25m aWcgaW4gL2Jvb3QgYWxvbmcgd2l0aCB2bWxpbnV6Lg0KDQozLiBNYXJrIHRoZSB4ZW4uZ3ogYmlu YXJ5IGl0c2VsZiBzb21laG93IGFzIGhhdmluZyBGTEFTSy4gIFRoaXMgY291bGQgd29yayBmb3Ig eDg2IGluIHRoZSBmdXR1cmUsIGJ1dCB3b27igJl0IHdvcmsgZm9yIGN1cnJlbnQgYmluYXJpZXM7 IGFuZCBpdCBzb3VuZHMgbGlrZSBpdCB3b27igJl0IHdvcmsgZm9yIEFSTSBlaXRoZXIuDQoNClVs dGltYXRlbHksIEkgaGF2ZSB0aGUgZmVlbGluZyB0aGF0ICMxLCBhbHRob3VnaCBzb21ld2hhdCBh d2t3YXJkLCBpcyBnb2luZyB0byBiZSB0aGUgYmVzdCBzb2x1dGlvbjogcGFja2FnZXJzIGNhbiBh cnJhbmdlIHRoYXQgRkxBU0sgcG9saWNpZXMgb25seSBiZSBpbnN0YWxsZWQgd2hlbiBGTEFTSyBw b2xpY2llcyBhcmUgY3JlYXRlZC4gIFBlb3BsZSBkb2luZyBzZWxmLWJ1aWxkcyBiYXNlZCBvbiBk aXN0cm8gcGFja2FnZXMgd2lsbCBiZSBjb3ZlcmVkOyBwZW9wbGUgZG9pbmcgaG9tZS1ncm93biBz ZWxmLWJ1aWxkcyB3aXRoIG5vbi1kZWZhdWx0IEZMQVNLIHNldHRpbmdzIHdpbGwgbmVlZCB0byB0 YWtlIGV4dHJhIGNhcmUgdG8gbWFrZSBzdXJlIHRoZSB0b29scyBkbyB0aGUgcmlnaHQgdGhpbmcu DQoNCiAtR2Vvcmdl From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:10:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:10:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkD6-0005WK-FQ; Mon, 01 Jun 2020 13:10:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfji4-0001ra-AR for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 12:38:32 +0000 X-Inumbo-ID: cce7baa6-a404-11ea-9dbe-bc764e2007e4 Received: from mail-wm1-x32b.google.com (unknown [2a00:1450:4864:20::32b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cce7baa6-a404-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 12:38:31 +0000 (UTC) Received: by mail-wm1-x32b.google.com with SMTP id q25so2288109wmj.0 for ; Mon, 01 Jun 2020 05:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JtZOOyBRfnaNeKFw/9nMYFP4RFl0d8hwlEyGaKq4ijA=; b=p2AJgIp4Fjjn0vShApcpYgz/gPAsSywakUVxzVGIUgDSmMHFgXXbwlKZGW//u3z5PJ fgEmBOUnfvLDzBxSinPDc5tGOjhcmc984hBLewRFRZWFv5+YgvgnhruxQpGQuLS5bJyb 4WnPQmBIiVei2P7klmaQVTc1vsSCiKbXK1IktC1fFaH/QCTC7jHsQT7iz4GXr31f+B1g AI9owG8sRGyDfMWOhmFSfq0LZrdAEkMb+hxcoFTD4rlwp7YXAO/T/PVtPmhu8PMwve3+ gsU1SMUbmZC2DD2mi1saZyuJkL5vco9JoaQvnHap7ri+Ztw9dTJEeawDCnPzIFJUbCDk 0qwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JtZOOyBRfnaNeKFw/9nMYFP4RFl0d8hwlEyGaKq4ijA=; b=Wbe6iKAZo2UxjWYg+Gz57nbhl7GiXLKhiXgmf6zwA64k4bLY/2DeVJdyK4euO5YiZb JU07bTuqJz9hYLJGJjLfcIZsihGFCLZrsG2twu4tP5HaTYdL2hC8pj3BpTBzuxlk3aya WICAsj/sBGUXchgFH4WCqxTKgdQMEJwQOlnna5+2gEYm9QGRpLc78zHUml1bTSqT0P0r Fz1xIbgHIlCIVmBuZvd89QHbuIxx/hb7D0gV5n02u/5Ihvqs2ulmV6Ke47UpKmzKOdUF nKzjm8t2oaBxW07qa4QBmpSggzz5S/uO1rcx2ylZPswrk9DKZnYqEaL/63sdL9GPDGdF NYrQ== X-Gm-Message-State: AOAM533A3uKOTNgrqC4K+KdyMOm89K87m1BAYGjZlri/LIWgNaKA5w05 La8mBKnble49cs0JIaX7ruQFYwgQnM8Gm1v5Ou+t7qYBa8Z/4Ppm X-Google-Smtp-Source: ABdhPJwqCLMjrkS1BVMA5U5UzqEHkC/PGAfzzG4TwPqYWpzym+3h7QI/bpj+vAuNGoYtYFCtJV6TVDki2Eu7oUenskg= X-Received: by 2002:a1c:23d2:: with SMTP id j201mr21289447wmj.186.1591015110729; Mon, 01 Jun 2020 05:38:30 -0700 (PDT) MIME-Version: 1.0 From: CodeWiz2280 Date: Mon, 1 Jun 2020 08:38:16 -0400 Message-ID: Subject: Keystone Issue To: xen-devel@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000081e31905a70512b2" X-Mailman-Approved-At: Mon, 01 Jun 2020 13:10:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --00000000000081e31905a70512b2 Content-Type: text/plain; charset="UTF-8" To Whom it May Concern: Hello, I am using a Texas Instruments K2E Keystone Eval board with Linux 4.19.59. It has a 32-bit ARM Cortex A15 processor. There is keystone specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that executes during early_paging_init for LPAE support. This causes the kernel to switch its running 32-bit address space to a 36-bit address space and the hypervisor traps repeatedly and stops it from booting. I suspect this is because Xen only allowed for the original 32-bit memory range specified by the dom0 device tree. The 36-bit LPAE address is a fixed offset from the 32-bit address and is not physically different memory. Can you suggest any way to get through this problem? I am using the master branch of xen from earlier this year. Any help is greatly appreciated. Thanks, Dave --00000000000081e31905a70512b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To Whom it May Concern:
Hello, I am using a Texas Instruments K2E Keystone Eval board = with Linux 4.19.59.=C2=A0 It has a 32-bit ARM Cortex A15 processor. There i= s keystone specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that e= xecutes during early_paging_init for LPAE support.=C2=A0 This causes the ke= rnel to switch its running 32-bit address space to a 36-bit address space a= nd the hypervisor traps repeatedly and stops it from booting.=C2=A0 I suspe= ct this is because Xen only allowed for the original 32-bit memory range sp= ecified by the dom0 device tree. The 36-bit LPAE address is a fixed offset = from the 32-bit address and is not physically different memory.=C2=A0 Can y= ou suggest any way to get through this problem? I am using the master branc= h of xen from earlier this year.=C2=A0 Any help is greatly appreciated.

Thanks,
Dave
--00000000000081e31905a70512b2-- From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:10:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:10:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkD6-0005WQ-NY; Mon, 01 Jun 2020 13:10:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkD5-0005WE-OR for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:10:35 +0000 X-Inumbo-ID: 476c2c0e-a409-11ea-ab1a-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 476c2c0e-a409-11ea-ab1a-12813bfff9fa; Mon, 01 Jun 2020 13:10:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z+Z1Z70sMwfAK/8fETUXVUy+iRGNrRmTFJBAppBhpro=; b=gFMkPM6UvGLNaAupnL6SXD5Kt5 kop2NQkEG7ByJhsksqLN50E9sWPnnTZma2mQ1D6W5j/5kbJ8JH7aCYHjk3IPIEwgYniNWjjujxO2J 3HajibZI5P+nR686pXao32RPn0Ay1Pzd6+qqGngGADqLj1LQ53Vqy1rDVyHVMri+egrE=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkD2-0001gw-Ft; Mon, 01 Jun 2020 13:10:32 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jfkD2-0002T6-8X; Mon, 01 Jun 2020 13:10:32 +0000 Subject: Re: Xen XSM/FLASK policy, grub defaults, etc. To: George Dunlap References: <24270.35349.838484.116865@mariner.uk.xensource.com> <0D83AAA6-A205-4256-8A38-CC8122AC063D@citrix.com> <24272.59646.746545.343358@mariner.uk.xensource.com> <4a8e7cf2-8f63-d4d2-e051-9484a5b8c8ed@suse.com> <96F32637-E410-4EC8-937A-CFC8BE724352@citrix.com> <24273.8332.662607.125522@mariner.uk.xensource.com> <7eaa7541-f698-b29b-b4b3-1f40fc37c5d7@xen.org> <63838ce9-8dbf-aacf-521d-97540758a945@suse.com> <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> From: Julien Grall Message-ID: Date: Mon, 1 Jun 2020 14:10:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Stefano Stabellini , "cjwatson@debian.org" , Wei Liu , Andrew Cooper , Jan Beulich , "xen-devel@lists.xenproject.org" , Ian Jackson , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi George, On 01/06/2020 13:57, George Dunlap wrote: > > >> On May 29, 2020, at 6:24 PM, Julien Grall wrote: >> >> Hi Jan, >> >> On 29/05/2020 16:11, Jan Beulich wrote: >>> On 29.05.2020 17:05, Julien Grall wrote: >>>> On 29/05/2020 15:47, Ian Jackson wrote: >>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."): >>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal. >>>>> >>>>> I propose the following behaviour by updste-grub: >>>>> >>>>> 1. Look for an ELF note, TBD. If it's found, make XSM boot entries. >>>>> (For now, skip this step, since the ELF note is not defined.) >>>> >>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such >>>> thing for the kernel/xen (actually the final binary is not even an ELF). >>> Ouch - of course. Is there anything similar one could employ there? >> >> In the past, we discussed about adding support for note in the zImage (arm32 kernel format) but I never got the chance to pursue the discussion. >> >> With Juergen's hypfs series, the hypervisor now embbed the .config. Is it possible to extract it? > > The problem is that update-grub doesn’t want the config of the *currently running* hypervisor, but of whatever specific hypervisor there is in /boot. > > So for instance, when someone first does “apt-get install xen”, after xen binaries are put in /boot, update-grub is called to make new entries for it. Ideally, we want it to create FLASK grub entries, and boot them by default, if and only if *that Xen binary* has FLASK enabled and there is a policy for it. At the time update-grub runs, Xen will not be running. I am fully aware we want to get information of the binaries residing in /boot (I wouldn't have suggested zImage note otherwise). So I think you misundertood my question. > > And if a user installs several Xen binaries, some of which have FLASK enabled and some of which don’t, we want update-grub to generate FLASK entries for the binaries that have FLASK enabled, and not for the ones which don’t. So hypfs isn’t really a suitable solution. I have never suggested to use hypfs. Instead, I have pointed out that .config is embedded in the binary thanks to hypfs. So I was asking whether we can extract it. On Linux, they have a script to extract the .config from the Kernel Image (see scripts/extract-ikconfig). Now that the .config is part of the Xen binarry, I was wondering whether we could have extract it. > > The options proposed have included: > > 1. Making the tools not generate a FLASK policy unless FLASK is enabled in the hypervisor being built. This is flaky because there’s no necessary connection between the two builds. > > 2. Using the xen config file normally copied into /boot. This should work now, but it’s been suggested that packagers may not want to continue putting the xen config in /boot along with xen.gz, just as they’ve stopped putting the Linux config in /boot along with vmlinuz. > > 3. Mark the xen.gz binary itself somehow as having FLASK. This could work for x86 in the future, but won’t work for current binaries; and it sounds like it won’t work for ARM either. 4. Extract the .config from the binary using a similar script to script/extract-ikconfig. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOC-0006aV-MI; Mon, 01 Jun 2020 13:22:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOC-0006aQ-23 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:04 +0000 X-Inumbo-ID: dcedcdc2-a40a-11ea-8993-bc764e2007e4 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dcedcdc2-a40a-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 13:21:56 +0000 (UTC) IronPort-SDR: +BoH5IhwtvVz0OcmsrC/cDS4ULPjOhCjhVdV4VhWypMjtdD93xHOAOyi/ikgSJxysrteIYwEPP dVixSkxmwt1w== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:54 -0700 IronPort-SDR: 1TRWz9hm2TCT2jHDQTuifUSnC7LwgEsZkSiKA/34n4hyfzde9BPl2lsLdM9C6SgIGkrW9MIDKN K3azX4n2y3SA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887253" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:53 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks Date: Mon, 1 Jun 2020 06:21:35 -0700 Message-Id: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Tamas K Lengyel , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Tamas K Lengyel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" When running VM forks without device models (QEMU), it may be undesirable for Xen to inject interrupts. When creating such forks from Windows VMs we have observed the kernel trying to process interrupts immediately after the fork is executed. However without QEMU running such interrupt handling may not be possible because it may attempt to interact with devices that are not emulated by a backend. In the best case scenario such interrupt handling would only present a detour in the VM forks' execution flow, but in the worst case as we actually observed can completely stall it. By disabling interrupt injection a fuzzer can exercise the target code without interference. For other use-cases this option probably doesn't make sense, that's why this is not enabled by default. Forks & memory sharing are only available on Intel CPUs so this only applies to vmx. Note that this is part of the experimental VM forking feature that's completely disabled by default and can only be enabled by using XEN_CONFIG_EXPERT during compile time. Signed-off-by: Tamas K Lengyel Reviewed-by: Roger Pau Monné --- xen/arch/x86/hvm/vmx/intr.c | 6 ++++++ xen/arch/x86/mm/mem_sharing.c | 6 +++++- xen/include/asm-x86/hvm/domain.h | 2 +- xen/include/public/memory.h | 3 +++ 4 files changed, 15 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c index 000e14af49..80bfbb4787 100644 --- a/xen/arch/x86/hvm/vmx/intr.c +++ b/xen/arch/x86/hvm/vmx/intr.c @@ -256,6 +256,12 @@ void vmx_intr_assist(void) if ( unlikely(v->arch.vm_event) && v->arch.vm_event->sync_event ) return; +#ifdef CONFIG_MEM_SHARING + /* Block event injection for VM fork if requested */ + if ( unlikely(v->domain->arch.hvm.mem_sharing.block_interrupts) ) + return; +#endif + /* Crank the handle on interrupt state. */ pt_vector = pt_update_irq(v); diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c index 19922ab5d1..c428fd16ce 100644 --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -2106,7 +2106,8 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) rc = -EINVAL; if ( mso.u.fork.pad ) goto out; - if ( mso.u.fork.flags & ~XENMEM_FORK_WITH_IOMMU_ALLOWED ) + if ( mso.u.fork.flags & + ~(XENMEM_FORK_WITH_IOMMU_ALLOWED | XENMEM_FORK_BLOCK_INTERRUPTS) ) goto out; rc = rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_domain, @@ -2134,6 +2135,9 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) rc = hypercall_create_continuation(__HYPERVISOR_memory_op, "lh", XENMEM_sharing_op, arg); + else if ( !rc && (mso.u.fork.flags & XENMEM_FORK_BLOCK_INTERRUPTS) ) + d->arch.hvm.mem_sharing.block_interrupts = true; + rcu_unlock_domain(pd); break; } diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h index 95fe18cddc..9d247baf4d 100644 --- a/xen/include/asm-x86/hvm/domain.h +++ b/xen/include/asm-x86/hvm/domain.h @@ -67,7 +67,7 @@ struct hvm_ioreq_server { #ifdef CONFIG_MEM_SHARING struct mem_sharing_domain { - bool enabled; + bool enabled, block_interrupts; /* * When releasing shared gfn's in a preemptible manner, recall where diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index dbd35305df..850bd72c52 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -536,7 +536,10 @@ struct xen_mem_sharing_op { } debug; struct mem_sharing_op_fork { /* OP_FORK */ domid_t parent_domain; /* IN: parent's domain id */ +/* Only makes sense for short-lived forks */ #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0) +/* Only makes sense for short-lived forks */ +#define XENMEM_FORK_BLOCK_INTERRUPTS (1u << 1) uint16_t flags; /* IN: optional settings */ uint32_t pad; /* Must be set to 0 */ } fork; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkO5-0006Ze-U7; Mon, 01 Jun 2020 13:21:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkO5-0006ZZ-0M for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:21:57 +0000 X-Inumbo-ID: dc42d76e-a40a-11ea-ab1b-12813bfff9fa Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dc42d76e-a40a-11ea-ab1b-12813bfff9fa; Mon, 01 Jun 2020 13:21:54 +0000 (UTC) IronPort-SDR: uAtTg3fLpoTIMRRet8XzBfbpM1/hjbrkoNFueeSjioCTMsw5UFacIxJyZEfi9xoHRCQF+LwtTt wCqN/4+yaNpQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:53 -0700 IronPort-SDR: nNWIq1uD8ie8+x2jOfIxLgZ6NTtxtphM8yRjD0RWCh6CBrTs/5CHHxkpNk699d8CDzLq1CYq+6 PM1tGdbULxhg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887244" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:51 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 00/13] VM forking Date: Mon, 1 Jun 2020 06:21:34 -0700 Message-Id: X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Tamas K Lengyel , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Tamas K Lengyel , Jan Beulich , Anthony PERARD , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The following patches are part of the series that implement VM forking for Intel HVM guests to allow for the fast creation of identical VMs without the assosciated high startup costs of booting or restoring the VM from a savefile. JIRA issue: https://xenproject.atlassian.net/browse/XEN-89 The fork operation is implemented as part of the "xl fork-vm" command: xl fork-vm -C -Q By default a fully functional fork is created. The user is in charge however to create the appropriate config file for the fork and to generate the QEMU save file before the fork-vm call is made. The config file needs to give the fork a new name at minimum but other settings may also require changes. Certain settings in the config file of both the parent and the fork have to be set to default. Details are documented. The interface also allows to split the forking into two steps: xl fork-vm --launch-dm no \ -m \ -p xl fork-vm --launch-dm late \ -C \ -Q \ The split creation model is useful when the VM needs to be created as fast as possible. The forked VM can be unpaused without the device model being launched to be monitored and accessed via VMI. Note however that without its device model running (depending on what is executing in the VM) it is bound to misbehave or even crash when its trying to access devices that would be emulated by QEMU. We anticipate that for certain use-cases this would be an acceptable situation, in case for example when fuzzing is performed of code segments that don't access such devices. Launching the device model requires the QEMU Xen savefile to be generated manually from the parent VM. This can be accomplished simply by connecting to its QMP socket and issuing the "xen-save-devices-state" command. For example using the standard tool socat these commands can be used to generate the file: socat - UNIX-CONNECT:/var/run/xen/qmp-libxl- { "execute": "qmp_capabilities" } { "execute": "xen-save-devices-state", \ "arguments": { "filename": "/path/to/save/qemu_state", \ "live": false} } The series has been tested with Windows VMs and functions as expected. Linux VMs when forked from a running VM will have a frozen VNC screen. Linux VMs at this time can only be forked with a working device model when the parent VM was restored from a snapshot using "xl restore -p". This is a known limitation due to Linux VMs having to be made aware of being saved/migrated. New in v19: Including all the patches currently outstanding into the series Breaking up libxl/xl patch to many sub-patches to make it easier to review libxl/xl is now reduced to the bare essential to launch QEMU for a VM fork Tamas K Lengyel (13): x86/mem_sharing: block interrupt injection for forks tools/libxc: xc_memshr_fork with interrupts blocked tools/libxl: Split libxl__domain_make tools/libxl: populate xenstore entries when launching dm for VM fork tools/libxl: Add checks for dm_restore_file tools/libxl: adjust domcreate_bootloader_done tools/libxl: Adjust libxl__build_pre tools/libxl: Adjust libxl__build_post tools/libxl: libxl__build_hvm_fork tools/libxl: set QEMU saved_state from dm_restore_file tools/libxl: Add VM forking public functions tools/xl: Add xl fork-vm command tools/xl: document fork-vm command docs/man/xl.1.pod.in | 39 +++++++++ tools/libxc/include/xenctrl.h | 3 +- tools/libxc/xc_memshr.c | 4 +- tools/libxl/libxl.h | 10 +++ tools/libxl/libxl_create.c | 134 +++++++++++++++++++++++++------ tools/libxl/libxl_dm.c | 2 +- tools/libxl/libxl_dom.c | 59 +++++++++++--- tools/libxl/libxl_internal.h | 5 +- tools/libxl/libxl_types.idl | 1 + tools/xl/Makefile | 2 +- tools/xl/xl.h | 4 + tools/xl/xl_cmdtable.c | 13 +++ tools/xl/xl_forkvm.c | 122 ++++++++++++++++++++++++++++ tools/xl/xl_vmcontrol.c | 13 +++ xen/arch/x86/hvm/vmx/intr.c | 6 ++ xen/arch/x86/mm/mem_sharing.c | 6 +- xen/include/asm-x86/hvm/domain.h | 2 +- xen/include/public/memory.h | 3 + 18 files changed, 383 insertions(+), 45 deletions(-) create mode 100644 tools/xl/xl_forkvm.c -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkO9-0006Zp-5r; Mon, 01 Jun 2020 13:22:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkO7-0006Zk-93 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:21:59 +0000 X-Inumbo-ID: ddd06506-a40a-11ea-9dbe-bc764e2007e4 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ddd06506-a40a-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 13:21:57 +0000 (UTC) IronPort-SDR: EKWuFPQTlQo2nXmEb57T0pwfRBTs2DWQkl+jsOS4QmLECQY9zltaVs3Ky3gGsn+XjAWdf8rwqJ hyjhlsy5da/Q== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:55 -0700 IronPort-SDR: JYYGi1Zv63q1rClSv3u55YlsaJLhwwbopbhxoOvJBRFiPlzxskqtLck516JzHjYi6Gvvxy9p0B AiVbe0WNDnoQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887264" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:54 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 03/13] tools/libxl: Split libxl__domain_make Date: Mon, 1 Jun 2020 06:21:37 -0700 Message-Id: <853ceef8391bdfb7dc43ae2d9a9cb45818f256e4.1591017086.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Make part of libxl__domain_make into a separate function. No functional change. Signed-off-by: Tamas K Lengyel --- tools/libxl/libxl_create.c | 62 +++++++++++++++++++++++------------- tools/libxl/libxl_internal.h | 4 ++- 2 files changed, 42 insertions(+), 24 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 75862dc6ed..09cf99d304 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -579,15 +579,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, uint32_t *domid, bool soft_reset) { libxl_ctx *ctx = libxl__gc_owner(gc); - int ret, rc, nb_vm; - const char *dom_type; - char *uuid_string; - char *dom_path, *vm_path, *libxl_path; - struct xs_permissions roperm[2]; - struct xs_permissions rwperm[1]; - struct xs_permissions noperm[1]; - xs_transaction_t t = 0; - libxl_vminfo *vm_list; + int ret, rc; /* convenience aliases */ libxl_domain_create_info *info = &d_config->c_info; @@ -595,12 +587,6 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, assert(soft_reset || *domid == INVALID_DOMID); - uuid_string = libxl__uuid2string(gc, info->uuid); - if (!uuid_string) { - rc = ERROR_NOMEM; - goto out; - } - if (!soft_reset) { struct xen_domctl_createdomain create = { .ssidref = info->ssidref, @@ -731,7 +717,37 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, goto out; } - dom_path = libxl__xs_get_dompath(gc, *domid); + rc = libxl__domain_make_xs_entries(gc, d_config, state, *domid); + + out: + return rc; +} + +int libxl__domain_make_xs_entries(libxl__gc *gc, libxl_domain_config *d_config, + libxl__domain_build_state *state, + uint32_t domid) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + int rc, nb_vm; + const char *dom_type; + char *uuid_string; + char *dom_path, *vm_path, *libxl_path; + struct xs_permissions roperm[2]; + struct xs_permissions rwperm[1]; + struct xs_permissions noperm[1]; + xs_transaction_t t = 0; + libxl_vminfo *vm_list; + + /* convenience aliases */ + libxl_domain_create_info *info = &d_config->c_info; + + uuid_string = libxl__uuid2string(gc, info->uuid); + if (!uuid_string) { + rc = ERROR_NOMEM; + goto out; + } + + dom_path = libxl__xs_get_dompath(gc, domid); if (!dom_path) { rc = ERROR_FAIL; goto out; @@ -739,12 +755,12 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, vm_path = GCSPRINTF("/vm/%s", uuid_string); if (!vm_path) { - LOGD(ERROR, *domid, "cannot allocate create paths"); + LOGD(ERROR, domid, "cannot allocate create paths"); rc = ERROR_FAIL; goto out; } - libxl_path = libxl__xs_libxl_path(gc, *domid); + libxl_path = libxl__xs_libxl_path(gc, domid); if (!libxl_path) { rc = ERROR_FAIL; goto out; @@ -755,10 +771,10 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, roperm[0].id = 0; roperm[0].perms = XS_PERM_NONE; - roperm[1].id = *domid; + roperm[1].id = domid; roperm[1].perms = XS_PERM_READ; - rwperm[0].id = *domid; + rwperm[0].id = domid; rwperm[0].perms = XS_PERM_NONE; retry_transaction: @@ -776,7 +792,7 @@ retry_transaction: noperm, ARRAY_SIZE(noperm)); xs_write(ctx->xsh, t, GCSPRINTF("%s/vm", dom_path), vm_path, strlen(vm_path)); - rc = libxl__domain_rename(gc, *domid, 0, info->name, t); + rc = libxl__domain_rename(gc, domid, 0, info->name, t); if (rc) goto out; @@ -866,7 +882,7 @@ retry_transaction: vm_list = libxl_list_vm(ctx, &nb_vm); if (!vm_list) { - LOGD(ERROR, *domid, "cannot get number of running guests"); + LOGD(ERROR, domid, "cannot get number of running guests"); rc = ERROR_FAIL; goto out; } @@ -890,7 +906,7 @@ retry_transaction: t = 0; goto retry_transaction; } - LOGED(ERROR, *domid, "domain creation ""xenstore transaction commit failed"); + LOGED(ERROR, domid, "domain creation ""xenstore transaction commit failed"); rc = ERROR_FAIL; goto out; } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index c7ece066c4..19b367daca 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1983,7 +1983,9 @@ _hidden int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, libxl__domain_build_state *state, uint32_t *domid, bool soft_reset); - +_hidden int libxl__domain_make_xs_entries(libxl__gc *gc, libxl_domain_config *d_config, + libxl__domain_build_state *state, + uint32_t domid); _hidden int libxl__domain_build(libxl__gc *gc, libxl_domain_config *d_config, uint32_t domid, -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOA-0006a6-Dz; Mon, 01 Jun 2020 13:22:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkO9-0006Zz-SF for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:01 +0000 X-Inumbo-ID: ddea53d0-a40a-11ea-ab1b-12813bfff9fa Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ddea53d0-a40a-11ea-ab1b-12813bfff9fa; Mon, 01 Jun 2020 13:21:56 +0000 (UTC) IronPort-SDR: Ji+TwovGG1LW3mC7YDXtNoadPZpzsZgTKai+7RNf0SB1nKJj3xYVIwGblJs44kWIDMGttKAe2H WuVxZrpAZHRg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:54 -0700 IronPort-SDR: vyNToxXCPi1GYxEewQa8wW777KqdP2qZ/RwvvSPnmhxqv3gdY14S+abDy4+ksqb8Di5N8DUPHz Jb66VM7jxTIg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887260" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:54 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 02/13] tools/libxc: xc_memshr_fork with interrupts blocked Date: Mon, 1 Jun 2020 06:21:36 -0700 Message-Id: <03b382a38c62b5431c63d00f9acffacf43b55c1d.1591017086.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Tamas K Lengyel , Wei Liu , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Toolstack side for creating forks with interrupt injection blocked. Signed-off-by: Tamas K Lengyel Reviewed-by: Roger Pau Monné Acked-by: Ian Jackson --- tools/libxc/include/xenctrl.h | 3 ++- tools/libxc/xc_memshr.c | 4 +++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index f9e17ae424..5eeee1de46 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -2241,7 +2241,8 @@ int xc_memshr_range_share(xc_interface *xch, int xc_memshr_fork(xc_interface *xch, uint32_t source_domain, uint32_t client_domain, - bool allow_with_iommu); + bool allow_with_iommu, + bool block_interrupts); /* * Note: this function is only intended to be used on short-lived forks that diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c index 2300cc7075..a6cfd7dccf 100644 --- a/tools/libxc/xc_memshr.c +++ b/tools/libxc/xc_memshr.c @@ -240,7 +240,7 @@ int xc_memshr_debug_gref(xc_interface *xch, } int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid, - bool allow_with_iommu) + bool allow_with_iommu, bool block_interrupts) { xen_mem_sharing_op_t mso; @@ -251,6 +251,8 @@ int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid, if ( allow_with_iommu ) mso.u.fork.flags |= XENMEM_FORK_WITH_IOMMU_ALLOWED; + if ( block_interrupts ) + mso.u.fork.flags |= XENMEM_FORK_BLOCK_INTERRUPTS; return xc_memshr_memop(xch, domid, &mso); } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOG-0006bd-3Y; Mon, 01 Jun 2020 13:22:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOE-0006bE-SS for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:06 +0000 X-Inumbo-ID: dea7aff2-a40a-11ea-ab1b-12813bfff9fa Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dea7aff2-a40a-11ea-ab1b-12813bfff9fa; Mon, 01 Jun 2020 13:21:58 +0000 (UTC) IronPort-SDR: 7eWO+wTg+OD+E2zkbkm3GRWBTgtNS6aCZmQicZunUHASRlRfGwdwer19Xq2lPrBNTranExw6Qj hnDOMTq4QIjg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:56 -0700 IronPort-SDR: LEuwBODCIKLx545PJycekkq8RxaL8o3E7DHJvs7J4Cqfhf+06K1UkXYWFFeuEr9vUCpsVW90uC VxmKNAsxFN9w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887271" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:55 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 04/13] tools/libxl: populate xenstore entries when launching dm for VM fork Date: Mon, 1 Jun 2020 06:21:38 -0700 Message-Id: <52246b2d22313368a063902a868cc2c66fefaf82.1591017086.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" No need to call libxl__domain_make since the domain already exists, only need to populate the xenstore entries via libxl__domain_make_xs_entries. Signed-off-by: Tamas K Lengyel --- tools/libxl/libxl_create.c | 11 ++++++++++- tools/libxl/libxl_types.idl | 1 + 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 09cf99d304..c3614e5a30 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -1244,7 +1244,13 @@ static void initiate_domain_create(libxl__egc *egc, ret = libxl__domain_config_setdefault(gc,d_config,domid); if (ret) goto error_out; - ret = libxl__domain_make(gc, d_config, dbs, &domid, dcs->soft_reset); + /* If no dm_restore_file is specified we are in the normal path */ + if (!d_config->dm_restore_file) + ret = libxl__domain_make(gc, d_config, dbs, &domid, dcs->soft_reset); + else + ret = libxl__domain_make_xs_entries(gc, d_config, &dcs->build_state, + domid); + if (ret) { LOGD(ERROR, domid, "cannot make domain: %d", ret); dcs->guest_domid = domid; @@ -2052,6 +2058,9 @@ static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config, cdcs->dcs.domid = INVALID_DOMID; cdcs->dcs.soft_reset = false; + if (d_config->dm_restore_file) + cdcs->dcs.domid = *domid; + if (cdcs->dcs.restore_params.checkpointed_stream == LIBXL_CHECKPOINTED_STREAM_COLO) { cdcs->dcs.colo_proxy_script = diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 9d3f05f399..b9cc139b0a 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -961,6 +961,7 @@ libxl_domain_config = Struct("domain_config", [ ("on_watchdog", libxl_action_on_shutdown), ("on_crash", libxl_action_on_shutdown), ("on_soft_reset", libxl_action_on_shutdown), + ("dm_restore_file", string, {'const': True}), ], dir=DIR_IN) libxl_diskinfo = Struct("diskinfo", [ -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOI-0006dV-Bh; Mon, 01 Jun 2020 13:22:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOH-0006ct-2F for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:09 +0000 X-Inumbo-ID: df3da6c4-a40a-11ea-9dbe-bc764e2007e4 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id df3da6c4-a40a-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 13:21:59 +0000 (UTC) IronPort-SDR: C8ptVWxodiBB3EqGFrAnjm23FTmPKQY+qGvbMdzuOQ5cL59d+ufNks+0mr4Q2Eg1YMi1TLCZnn BK9utKMQXIig== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:56 -0700 IronPort-SDR: CSscI0DActZay7lfaxFXLbg3psQfkSGDofDsdx7FRzi1axZMAj514VZFPcJ4KqOUJ+k4+/WIWn WObTr+DekdPg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887275" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:56 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 05/13] tools/libxl: Add checks for dm_restore_file Date: Mon, 1 Jun 2020 06:21:39 -0700 Message-Id: <1f439c9d611458426917b5d6b9a350ff7dc6559f.1591017086.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" We can skip a bunch of steps a normal domain creation would entail, similar to how domain restore & soft_reset skips them. Signed-off-by: Tamas K Lengyel --- tools/libxl/libxl_create.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index c3614e5a30..3f0745acc6 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -1294,7 +1294,7 @@ static void initiate_domain_create(libxl__egc *egc, if (ret) goto error_out; - if (dbs->restore || dcs->soft_reset) { + if (dbs->restore || dcs->soft_reset || d_config->dm_restore_file) { LOGD(DEBUG, domid, "restoring, not running bootloader"); domcreate_bootloader_done(egc, &dcs->bl, 0); } else { @@ -1370,7 +1370,7 @@ static void domcreate_bootloader_done(libxl__egc *egc, dcs->sdss.dm.callback = domcreate_devmodel_started; dcs->sdss.callback = domcreate_devmodel_started; - if (restore_fd < 0 && !dcs->soft_reset) { + if (restore_fd < 0 && !dcs->soft_reset && !d_config->dm_restore_file) { rc = libxl__domain_build(gc, d_config, domid, state); domcreate_rebuild_done(egc, dcs, rc); return; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOK-0006f4-LQ; Mon, 01 Jun 2020 13:22:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOJ-0006eX-Se for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:11 +0000 X-Inumbo-ID: dea7aff3-a40a-11ea-ab1b-12813bfff9fa Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dea7aff3-a40a-11ea-ab1b-12813bfff9fa; Mon, 01 Jun 2020 13:21:59 +0000 (UTC) IronPort-SDR: ExGWDZMH5GWwQEkJjcFMcIanFAIhhumLpPK09RcYRo00igFeixwnxOyffCGITwYPRMc2ZfeJrJ VJJc76bbQ2/g== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:57 -0700 IronPort-SDR: AAatOggz3HYKUTbjHTpoBX7UjXaEbcFir0FwqigBWNA8hm4nXhBOwsx5nL1oNXc1iPQidkp7gn YQY/Qpjej3yA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887289" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:57 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 07/13] tools/libxl: Adjust libxl__build_pre Date: Mon, 1 Jun 2020 06:21:41 -0700 Message-Id: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Skips parts not relevant for VM forks. No functional change in existing code, only relocating some bits that don't need to be done at the very end. Signed-off-by: Tamas K Lengyel --- tools/libxl/libxl_dom.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index dd1aff89a3..1b55097a1a 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -249,9 +249,12 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid, libxl_domain_build_info *const info = &d_config->b_info; libxl_ctx *ctx = libxl__gc_owner(gc); char *xs_domid, *con_domid; - int rc; + int rc = 0; uint64_t size; + if (state->forked_vm) + goto skip_fork; + if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) { LOG(ERROR, "Couldn't set max vcpu count"); return ERROR_FAIL; @@ -374,6 +377,16 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid, return ERROR_FAIL; } + if ( (rc = libxl__arch_domain_create(gc, d_config, domid)) ) + return rc; + + /* Construct a CPUID policy, but only for brand new domains. Domains + * being migrated-in/restored have CPUID handled during the + * static_data_done() callback. */ + if (!state->restore) + libxl__cpuid_legacy(ctx, domid, info); + +skip_fork: xs_domid = xs_read(ctx->xsh, XBT_NULL, "/tool/xenstored/domid", NULL); state->store_domid = xs_domid ? atoi(xs_domid) : 0; free(xs_domid); @@ -385,14 +398,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid, state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->store_domid); state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, state->console_domid); - rc = libxl__arch_domain_create(gc, d_config, domid); - - /* Construct a CPUID policy, but only for brand new domains. Domains - * being migrated-in/restored have CPUID handled during the - * static_data_done() callback. */ - if (!state->restore) - libxl__cpuid_legacy(ctx, domid, info); - return rc; } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOM-0006gj-VH; Mon, 01 Jun 2020 13:22:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOM-0006gF-2B for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:14 +0000 X-Inumbo-ID: df4e475e-a40a-11ea-8993-bc764e2007e4 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id df4e475e-a40a-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 13:21:59 +0000 (UTC) IronPort-SDR: OiTlxfAXUtm6i+b2l+ZzI3kOknlRorIT78wliQmC8X7xL8saYQAuXRKZOVfQwoA2mtJDAwL2eV eMpEY7raiHSQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:57 -0700 IronPort-SDR: CVuO+4ehU7TfZV95N6Qju9mNN4lwVMxQYdLjW2RpEurT0ArwV6c/GEHsjkX9BPecavBOl1FcS4 GhG+5ki6KQBg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887281" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:56 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 06/13] tools/libxl: adjust domcreate_bootloader_done Date: Mon, 1 Jun 2020 06:21:40 -0700 Message-Id: <0772dc7d3002e02b2c5775b32980a7719a4176b7.1591017086.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add special handling when only the the device model needs launching for forks. Signed-off-by: Tamas K Lengyel --- tools/libxl/libxl_create.c | 9 +++++++++ tools/libxl/libxl_internal.h | 1 + 2 files changed, 10 insertions(+) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 3f0745acc6..ab3ac096ee 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -1376,6 +1376,15 @@ static void domcreate_bootloader_done(libxl__egc *egc, return; } + if (d_config->dm_restore_file) { + dcs->srs.dcs = dcs; + dcs->srs.ao = ao; + state->forked_vm = true; + rc = libxl__domain_build(gc, d_config, domid, state); + domcreate_rebuild_done(egc, dcs, rc); + return; + } + /* Prepare environment for domcreate_stream_done */ dcs->srs.dcs = dcs; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 19b367daca..eaae955658 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -1376,6 +1376,7 @@ typedef struct { char *saved_state; int dm_monitor_fd; + bool forked_vm; libxl__file_reference pv_kernel; libxl__file_reference pv_ramdisk; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOQ-0006in-7m; Mon, 01 Jun 2020 13:22:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOO-0006hy-Sl for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:16 +0000 X-Inumbo-ID: dfe2868a-a40a-11ea-ab1b-12813bfff9fa Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dfe2868a-a40a-11ea-ab1b-12813bfff9fa; Mon, 01 Jun 2020 13:22:00 +0000 (UTC) IronPort-SDR: dtsesG4qtqvwgW/7QUL6kHCpoISg2oRiSj5CcYVOCaDPVN6eDl5mgR+gbDSRgnzOfrr2fiFbRh CuTM/oE78Ykg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:59 -0700 IronPort-SDR: s05BZVyhXR9Xjv9kvjrGZR6UjA2OEFZ7oMD1wRB96A31J2ARk1FPu3vk378eDdVja7owOMV67R BePbFwgEmOUA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887309" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:59 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 10/13] tools/libxl: set QEMU saved_state from dm_restore_file Date: Mon, 1 Jun 2020 06:21:44 -0700 Message-Id: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" And make sure we don't remove the file once done. Signed-off-by: Tamas K Lengyel --- tools/libxl/libxl_create.c | 4 ++++ tools/libxl/libxl_dm.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index ab3ac096ee..27f790cae1 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -1602,6 +1602,7 @@ static void domcreate_rebuild_done(libxl__egc *egc, /* convenience aliases */ const uint32_t domid = dcs->guest_domid; libxl_domain_config *const d_config = dcs->guest_config; + libxl__domain_build_state *const state = &dcs->build_state; if (ret) { LOGD(ERROR, domid, "cannot (re-)build domain: %d", ret); @@ -1609,6 +1610,9 @@ static void domcreate_rebuild_done(libxl__egc *egc, goto error_out; } + if (d_config->dm_restore_file) + state->saved_state = GCSPRINTF("%s", d_config->dm_restore_file); + store_libxl_entry(gc, domid, &d_config->b_info); libxl__multidev_begin(ao, &dcs->multidev); diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index f2dc5696b9..9b22836e12 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -3104,7 +3104,7 @@ static void device_model_spawn_outcome(libxl__egc *egc, libxl__domain_build_state *state = dmss->build_state; - if (state->saved_state) { + if (state->saved_state && !state->forked_vm) { ret2 = unlink(state->saved_state); if (ret2) { LOGED(ERROR, dmss->guest_domid, "%s: failed to remove device-model state %s", -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOS-0006kj-HI; Mon, 01 Jun 2020 13:22:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOR-0006jj-3Z for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:19 +0000 X-Inumbo-ID: dfe0775a-a40a-11ea-8993-bc764e2007e4 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dfe0775a-a40a-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 13:22:00 +0000 (UTC) IronPort-SDR: eYkBbxAJMifG3uobCYKDtbUo66UTDRrtjr6rSuqfo4WRxHjrY2Wu0njUu8noRvfReD46pBDn1i gCp64f2LXSDQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:59 -0700 IronPort-SDR: 1cKPzYsYfgfjZpS+CJvwDNcWA1oIpmOii7uxMrS2NR4p369xdncM4O4Cb+skp6ZkpXnKytCb/w 9KI+RA07J8JQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887304" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:58 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 09/13] tools/libxl: libxl__build_hvm_fork Date: Mon, 1 Jun 2020 06:21:43 -0700 Message-Id: <688d79b662bce099e847329426dd6fd61479f8c2.1591017086.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add libxl__build_hvm_fork function that performs only the steps needed for VM forks, skipping a large chunk of libxl__build_hvm. Signed-off-by: Tamas K Lengyel --- tools/libxl/libxl_dom.c | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index 52d49437cc..28117f0907 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -741,14 +741,15 @@ static int hvm_build_set_params(xc_interface *handle, uint32_t domid, libxl_domain_build_info *info, int store_evtchn, unsigned long *store_mfn, int console_evtchn, unsigned long *console_mfn, - domid_t store_domid, domid_t console_domid) + domid_t store_domid, domid_t console_domid, + bool forked_vm) { struct hvm_info_table *va_hvm; uint8_t *va_map, sum; uint64_t str_mfn, cons_mfn; int i; - if (info->type == LIBXL_DOMAIN_TYPE_HVM) { + if (info->type == LIBXL_DOMAIN_TYPE_HVM && !forked_vm) { va_map = xc_map_foreign_range(handle, domid, XC_PAGE_SIZE, PROT_READ | PROT_WRITE, HVM_INFO_PFN); @@ -1053,6 +1054,28 @@ out: return rc; } +static int libxl__build_hvm_fork(libxl__gc *gc, uint32_t domid, + libxl_domain_config *d_config, + libxl__domain_build_state *state) +{ + libxl_ctx *ctx = libxl__gc_owner(gc); + libxl_domain_build_info *const info = &d_config->b_info; + + int rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port, + &state->store_mfn, state->console_port, + &state->console_mfn, state->store_domid, + state->console_domid, state->forked_vm); + + if ( rc ) + return rc; + + return xc_dom_gnttab_seed(ctx->xch, domid, true, + state->console_mfn, + state->store_mfn, + state->console_domid, + state->store_domid); +} + int libxl__build_hvm(libxl__gc *gc, uint32_t domid, libxl_domain_config *d_config, libxl__domain_build_state *state) @@ -1064,6 +1087,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid, struct xc_dom_image *dom = NULL; bool device_model = info->type == LIBXL_DOMAIN_TYPE_HVM ? true : false; + if (state->forked_vm) + return libxl__build_hvm_fork(gc, domid, d_config, state); + xc_dom_loginit(ctx->xch); /* @@ -1188,7 +1214,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid, rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port, &state->store_mfn, state->console_port, &state->console_mfn, state->store_domid, - state->console_domid); + state->console_domid, false); if (rc != 0) { LOG(ERROR, "hvm build set params failed"); goto out; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOU-0006nZ-R8; Mon, 01 Jun 2020 13:22:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOT-0006m3-Sq for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:21 +0000 X-Inumbo-ID: dfe2868b-a40a-11ea-ab1b-12813bfff9fa Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dfe2868b-a40a-11ea-ab1b-12813bfff9fa; Mon, 01 Jun 2020 13:22:01 +0000 (UTC) IronPort-SDR: Q/Mehip2yzTT5iUIc/0IwmuMBlveXybEMeJ7RqwJnMIMPACRFzKgM7ZMx39oZU8m6NtGRYSQlv WDdgPvOaQahQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:22:00 -0700 IronPort-SDR: kpzPta1L2TR2Hn5MiCYUdBSMcpJ4Q9SEdlvlxVA9nx4wfpYjCo7pZ3UFLt34zhjd2pmBEwP4Si Ew8Pd/1LBd+w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887319" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:59 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 11/13] tools/libxl: Add VM forking public functions Date: Mon, 1 Jun 2020 06:21:45 -0700 Message-Id: <5c477725d701be72172a6aebf983a1bf956cec40.1591017086.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Signed-off-by: Tamas K Lengyel --- tools/libxl/libxl.h | 10 +++++++++ tools/libxl/libxl_create.c | 44 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 71709dc585..79792d6e29 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -2704,6 +2704,16 @@ static inline int libxl_qemu_monitor_command_0x041200(libxl_ctx *ctx, */ int libxl_clear_domid_history(libxl_ctx *ctx); +/* + * Experimental VM forking functions + */ +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t *domid) + LIBXL_EXTERNAL_CALLERS_ONLY; + +int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config, + uint32_t domid, + const libxl_asyncprogress_how *aop_console_how) + LIBXL_EXTERNAL_CALLERS_ONLY; #endif /* LIBXL_H */ /* diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 27f790cae1..9190e4e263 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -2339,6 +2339,50 @@ int libxl_domain_soft_reset(libxl_ctx *ctx, aop_console_how); } +/* + * The parent domain is expected to be created with default settings for + * - max_evtch_port + * - max_grant_frames + * - max_maptrack_frames + */ +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t *domid) +{ + int rc; + xc_dominfo_t info; + struct xen_domctl_createdomain create = {0}; + + if ( 1 != xc_domain_getinfo(ctx->xch, pdomid, 1, &info) ) + return ERROR_INVAL; + + if ( info.domid != pdomid || !info.hvm || !info.hap ) + return ERROR_INVAL; + + create.flags |= XEN_DOMCTL_CDF_hvm; + create.flags |= XEN_DOMCTL_CDF_hap; + create.flags |= XEN_DOMCTL_CDF_oos_off; + create.arch.emulation_flags = info.arch_config.emulation_flags; + create.ssidref = info.ssidref; + create.max_vcpus = info.max_vcpu_id + 1; + create.max_evtchn_port = 1023; + create.max_grant_frames = LIBXL_MAX_GRANT_FRAMES_DEFAULT; + create.max_maptrack_frames = LIBXL_MAX_MAPTRACK_FRAMES_DEFAULT; + + if ( (rc = xc_domain_create(ctx->xch, domid, &create)) ) + return rc; + + if ( (rc = xc_memshr_fork(ctx->xch, pdomid, *domid, false, false)) ) + xc_domain_destroy(ctx->xch, *domid); + + return rc; +} + +int libxl_domain_fork_launch_dm(libxl_ctx *ctx, libxl_domain_config *d_config, + uint32_t domid, + const libxl_asyncprogress_how *aop_console_how) +{ + return do_domain_create(ctx, d_config, &domid, -1, -1, 0, 0, aop_console_how); +} + /* * Local variables: * mode: C -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOX-0006qK-A3; Mon, 01 Jun 2020 13:22:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOW-0006p5-35 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:24 +0000 X-Inumbo-ID: dfe083bc-a40a-11ea-9dbe-bc764e2007e4 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dfe083bc-a40a-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 13:22:00 +0000 (UTC) IronPort-SDR: XjUeCg2bF3qGzFJsbJOzRBFy5uuT9p5WuMZvn6HKmpY+KcPBONBM9i/zpgJ8EVPH1wyjeJpI/c dOBtgNG4c3Sg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:21:58 -0700 IronPort-SDR: zRzIgK3NLGrwOWakh5KTlXg84PUXiwRHwTb+oRhNxnL4DfIGf/h+7YZJJwdivG0FiLCHJuVfck sgCu+QJko7dQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887296" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:21:57 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 08/13] tools/libxl: Adjust libxl__build_post Date: Mon, 1 Jun 2020 06:21:42 -0700 Message-Id: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Skips parts not relevant to VM forks. Signed-off-by: Tamas K Lengyel --- tools/libxl/libxl_dom.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index 1b55097a1a..52d49437cc 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -455,6 +455,9 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid, char **ents; int i, rc; + if (state->forked_vm) + goto skip_fork; + if (info->num_vnuma_nodes && !info->num_vcpu_soft_affinity) { rc = set_vnuma_affinity(gc, domid, info); if (rc) @@ -475,6 +478,7 @@ int libxl__build_post(libxl__gc *gc, uint32_t domid, } } +skip_fork: ents = libxl__calloc(gc, 12 + (info->max_vcpus * 2) + 2, sizeof(char *)); ents[0] = "memory/static-max"; ents[1] = GCSPRINTF("%"PRId64, info->max_memkb); -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOc-0006wI-Ko; Mon, 01 Jun 2020 13:22:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOb-0006uV-3W for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:29 +0000 X-Inumbo-ID: e0867e0c-a40a-11ea-8993-bc764e2007e4 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e0867e0c-a40a-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 13:22:01 +0000 (UTC) IronPort-SDR: swwNZtVJOd6u4QhrFDPrBdlamAA74Yp2isDHdnSQf0hnEp3F2CBbYsaV1Cfa8JHOrQUN+UoiPY 91wY0fFtIAWA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:22:00 -0700 IronPort-SDR: 6fAP/sT786E5b+wVau0KnNKPiBUnslAnYMWwlPPMG2gDSjTHUFKlyREzr2kMpPdNsThtjKfXCD ptNRwxkDwFTA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887324" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:22:00 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 12/13] tools/xl: Add xl fork-vm command Date: Mon, 1 Jun 2020 06:21:46 -0700 Message-Id: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Adding the xl fork-vm command, compiled only on x86. Only the essential bits are available via this command to create a fork and launch QEMU for it. The command still allows to perform the task in a split-model, first creating the fork and launching QEMU only later. Signed-off-by: Tamas K Lengyel --- tools/xl/Makefile | 2 +- tools/xl/xl.h | 4 ++ tools/xl/xl_cmdtable.c | 13 +++++ tools/xl/xl_forkvm.c | 122 ++++++++++++++++++++++++++++++++++++++++ tools/xl/xl_vmcontrol.c | 13 +++++ 5 files changed, 153 insertions(+), 1 deletion(-) create mode 100644 tools/xl/xl_forkvm.c diff --git a/tools/xl/Makefile b/tools/xl/Makefile index af4912e67a..073222233b 100644 --- a/tools/xl/Makefile +++ b/tools/xl/Makefile @@ -15,7 +15,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS) CFLAGS_XL += $(CFLAGS_libxenlight) CFLAGS_XL += -Wshadow -XL_OBJS-$(CONFIG_X86) = xl_psr.o +XL_OBJS-$(CONFIG_X86) = xl_psr.o xl_forkvm.o XL_OBJS = xl.o xl_cmdtable.o xl_sxp.o xl_utils.o $(XL_OBJS-y) XL_OBJS += xl_parse.o xl_cpupool.o xl_flask.o XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o diff --git a/tools/xl/xl.h b/tools/xl/xl.h index 06569c6c4a..4b4442e875 100644 --- a/tools/xl/xl.h +++ b/tools/xl/xl.h @@ -50,6 +50,8 @@ struct domain_create { int migrate_fd; /* -1 means none */ int send_back_fd; /* -1 means none */ char **migration_domname_r; /* from malloc */ + uint32_t dm_restore_domid; /* restore dm for this domid */ + const char *dm_restore_file; /* path to dm restore file */ }; int create_domain(struct domain_create *dom_info); @@ -131,6 +133,8 @@ int main_restore(int argc, char **argv); int main_migrate_receive(int argc, char **argv); int main_save(int argc, char **argv); int main_migrate(int argc, char **argv); +int main_fork_vm(int argc, char **argv); +int main_fork_launch_dm(int argc, char **argv); #endif int main_dump_core(int argc, char **argv); int main_pause(int argc, char **argv); diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c index 08335394e5..523d955317 100644 --- a/tools/xl/xl_cmdtable.c +++ b/tools/xl/xl_cmdtable.c @@ -187,6 +187,19 @@ struct cmd_spec cmd_table[] = { "Restore a domain from a saved state", "- for internal use only", }, +#if defined(__i386__) || defined(__x86_64__) + { "fork-vm", + &main_fork_vm, 0, 1, + "Fork a domain from the running parent domid. Experimental. Most config settings must match parent.", + "[options] ", + "-h Print this help.\n" + "-C Use config file for VM fork.\n" + "-Q Use qemu save file for VM fork.\n" + "--launch-dm Launch device model (QEMU) for VM fork (default yes).\n" + "-p Do not unpause fork VM fork after operation.\n" + "-d Enable debug messages.\n" + }, +#endif #endif { "dump-core", &main_dump_core, 0, 1, diff --git a/tools/xl/xl_forkvm.c b/tools/xl/xl_forkvm.c new file mode 100644 index 0000000000..5ab57ae41b --- /dev/null +++ b/tools/xl/xl_forkvm.c @@ -0,0 +1,122 @@ +/* + * Copyright 2020 Intel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published + * by the Free Software Foundation; version 2.1 only. with the special + * exception on linking described in file LICENSE. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU Lesser General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include "xl.h" +#include "xl_utils.h" +#include "xl_parse.h" + +int main_fork_vm(int argc, char **argv) +{ + int rc, debug = 0; + uint32_t domid_in = INVALID_DOMID, domid_out = INVALID_DOMID; + int launch_dm = 1; + bool pause = 0; + const char *config_file = NULL; + const char *dm_restore_file = NULL; + + int opt; + static struct option opts[] = { + {"launch-dm", 1, 0, 'l'}, + COMMON_LONG_OPTS + }; + + SWITCH_FOREACH_OPT(opt, "phdC:Q:l:", opts, "fork-vm", 1) { + case 'd': + debug = 1; + break; + case 'p': + pause = 1; + break; + case 'C': + config_file = optarg; + break; + case 'Q': + dm_restore_file = optarg; + break; + case 'l': + if ( !strcmp(optarg, "no") ) + launch_dm = 0; + if ( !strcmp(optarg, "yes") ) + launch_dm = 1; + if ( !strcmp(optarg, "late") ) + launch_dm = 2; + break; + default: + fprintf(stderr, "Unimplemented option(s)\n"); + return EXIT_FAILURE; + } + + if (argc-optind == 1) { + domid_in = atoi(argv[optind]); + } else { + help("fork-vm"); + return EXIT_FAILURE; + } + + if (launch_dm && (!config_file || !dm_restore_file)) { + fprintf(stderr, "Currently you must provide both -C and -Q options\n"); + return EXIT_FAILURE; + } + + if (launch_dm == 2) { + domid_out = domid_in; + rc = EXIT_SUCCESS; + } else { + rc = libxl_domain_fork_vm(ctx, domid_in, &domid_out); + } + + if (rc == EXIT_SUCCESS) { + if ( launch_dm ) { + struct domain_create dom_info; + memset(&dom_info, 0, sizeof(dom_info)); + dom_info.dm_restore_domid = domid_out; + dom_info.dm_restore_file = dm_restore_file; + dom_info.debug = debug; + dom_info.paused = pause; + dom_info.config_file = config_file; + dom_info.migrate_fd = -1; + dom_info.send_back_fd = -1; + rc = create_domain(&dom_info) < 0 ? EXIT_FAILURE : EXIT_SUCCESS; + } else if ( !pause ) + rc = libxl_domain_unpause(ctx, domid_out, NULL); + } + + if (rc == EXIT_SUCCESS) + fprintf(stderr, "fork-vm command successfully returned domid: %u\n", domid_out); + else if ( domid_out != INVALID_DOMID ) + libxl_domain_destroy(ctx, domid_out, 0); + + return rc; +} + +/* + * Local variables: + * mode: C + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c index 17b4514c94..508a7c70bb 100644 --- a/tools/xl/xl_vmcontrol.c +++ b/tools/xl/xl_vmcontrol.c @@ -676,6 +676,12 @@ int create_domain(struct domain_create *dom_info) int restoring = (restore_file || (migrate_fd >= 0)); +#if defined(__i386__) || defined(__x86_64__) + /* VM forking, restore dm for this domain */ + uint32_t dm_restore_domid = dom_info->dm_restore_domid; + const char *dm_restore_file = dom_info->dm_restore_file; +#endif + libxl_domain_config_init(&d_config); if (restoring) { @@ -934,6 +940,13 @@ start: 0, autoconnect_console_how); domid = domid_soft_reset; domid_soft_reset = INVALID_DOMID; +#if defined(__i386__) || defined(__x86_64__) + } else if (dm_restore_file) { + d_config.dm_restore_file = dm_restore_file; + ret = libxl_domain_fork_launch_dm(ctx, &d_config, dm_restore_domid, + autoconnect_console_how); + domid = dm_restore_domid; +#endif } else { ret = libxl_domain_create_new(ctx, &d_config, &domid, 0, autoconnect_console_how); -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:22:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:22:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOg-00071P-Vc; Mon, 01 Jun 2020 13:22:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkOg-00070X-3m for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:22:34 +0000 X-Inumbo-ID: e14aa228-a40a-11ea-8993-bc764e2007e4 Received: from mga12.intel.com (unknown [192.55.52.136]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e14aa228-a40a-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 13:22:02 +0000 (UTC) IronPort-SDR: k2VvIlGHeuF5FHzawTp51swC4PNEusRm4BONrgxIy4XUSIsaVdm4B5QWKqUU3dwKOQqQwiyGkW OKZxsiPGsWJA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 06:22:01 -0700 IronPort-SDR: H1aV+v7D8iqBCn+kOObTwwAklxRSIFRI2v89rHm0OiToMY/GQuN4Op2Uk9MAHvIs6P9uNmgRXf XwA23kt8+UuA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="303887330" Received: from alayek-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.209.11.99]) by orsmga008.jf.intel.com with ESMTP; 01 Jun 2020 06:22:00 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v19 for-4.14 13/13] tools/xl: document fork-vm command Date: Mon, 1 Jun 2020 06:21:47 -0700 Message-Id: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Tamas K Lengyel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Signed-off-by: Tamas K Lengyel --- docs/man/xl.1.pod.in | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in index 09339282e6..9e87b0314f 100644 --- a/docs/man/xl.1.pod.in +++ b/docs/man/xl.1.pod.in @@ -708,6 +708,45 @@ above). =back +=item B [I] I + +Create a fork of a running VM. The domain will be paused after the operation +and remains paused while forks of it exist. Experimental and x86 only. +Forks can only be made of domains with HAP enabled and on Intel hardware. The +parent domain must be created with the xl toolstack and its configuration must +not manually define max_grant_frames, max_maptrack_frames or max_event_channels. + +B + +=over 4 + +=item B<-p> + +Leave the forked VM paused after creating it. The parent always remains paused +while there are forks active from it and that's enforced by the hypervisor. + +=item B<--launch-dm> + +Specify whether the device model (QEMU) should be launched for the fork. Late +launch allows to start the device model for an already running fork previously +created with "--launch-dm no". + +=item B<-C> + +The config file to use when launching the device model. Currently required when +launching the device model. Most config settings MUST match the parent domain +exactly, only change VM name, disk path and network configurations. + +=item B<-Q> + +The path to the QEMU save file to use when launching the device model. Currently +required when launching the device model. Generate it by connecting to the parent +domain's QMP socket and issuing: + { "execute": "qmp_capabilities" } + { "execute": "xen-save-devices-state", "arguments": { "filename": "/path/to/qemu.save", "live": false} } + +=back + =item B [I] Display the number of shared pages for a specified domain. If no domain is -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:29:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:29:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkV6-0007xz-PG; Mon, 01 Jun 2020 13:29:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkV5-0007xq-7H for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:29:11 +0000 X-Inumbo-ID: e07b8f64-a40b-11ea-9dbe-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e07b8f64-a40b-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 13:29:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GLHrgBGOFloKOwkupYiTD8oGR2dt6jDGmP+jyKOu7VY=; b=n4Ozb6I2PA7HX5cZtUfLvdvfeP LDL7tQPpyZvwraa+OtdCaLig1wMkbrkEubL4HcbU4om8lTGprhPz+wDZW/GJJucm133sovO953ZnD t827myyAAjqKBeDw/BoTSHqgbiPCPAKs2RUAhPimKjNapHffHWgJySGvsb1876Ox46EM=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkV4-0002Ah-Fe; Mon, 01 Jun 2020 13:29:10 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jfkV4-0003nL-93; Mon, 01 Jun 2020 13:29:10 +0000 Subject: Re: Keystone Issue To: CodeWiz2280 , xen-devel@lists.xenproject.org References: From: Julien Grall Message-ID: Date: Mon, 1 Jun 2020 14:29:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, I have a few questions in order to understand a bit more your problem. On 01/06/2020 13:38, CodeWiz2280 wrote: > Hello, I am using a Texas Instruments K2E Keystone Eval board with Linux > 4.19.59.  It has a 32-bit ARM Cortex A15 processor. There is keystone > specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that executes > during early_paging_init for LPAE support.  This causes the kernel to > switch its running 32-bit address space to a 36-bit address space and > the hypervisor traps repeatedly and stops it from booting. Without any log it is going to be difficult to help. Could you post the hypervisor log when debug is enabled? >  I suspect > this is because Xen only allowed for the original 32-bit memory range > specified by the dom0 device tree. How much RAM did you give to your Dom0? > The 36-bit LPAE address is a fixed > offset from the 32-bit address and is not physically different memory. I am not sure to understand this. Are you suggesting that the kernel is trying to relocate itself in a different part of the physical memory? Can you provide more details on the fixed offset? > > Can you suggest any way to get through this problem? I am using the > master branch of xen from earlier this year. Can you provide the exact baseline your are using? Did make any changes on top? > Any help is greatly > appreciated. Best regards, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:35:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:35:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkar-0000Ow-D0; Mon, 01 Jun 2020 13:35:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkaq-0000Or-2v for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:35:08 +0000 X-Inumbo-ID: b43e3112-a40c-11ea-81bc-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b43e3112-a40c-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 13:35:06 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: gIGn/qoA+JziYhNehlhIcC/pZdLQnJiivf3KBrvDAaLcZieoK0wv6rqSWzyN88jzaS5yZqjlpY RfxdKxbsGuQZbQNG6Z0BKhJhZ1tTyuSaQ+HatwoQ95vSQMppfi8G/6DHUtLhRtplwmx7Ca+GPr NUBb+UXwWCdL4zDy1goSOG2hkCOiftEr+u0andDI+Xw0pIXIw2feKZo/UTJLhWWXIHIoAXhTSm YbpurdtIXXmDJ1AB7Gu7W4O1D7hmYrjQa2RPlDPo4YOjQ/YvOhJX8/zTDPIa7lpg5TTQbsG9yo r5s= X-SBRS: 2.7 X-MesageID: 19176103 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,460,1583211600"; d="scan'208";a="19176103" From: George Dunlap To: Julien Grall Subject: Re: Xen XSM/FLASK policy, grub defaults, etc. Thread-Topic: Xen XSM/FLASK policy, grub defaults, etc. Thread-Index: AQHWND0/xSJFUOR5YU28XikgbPuX46i7+DWAgALLwwCAAANFAIAABtKAgAA4IwCAAAT9gIAAAZ+AgAAlWICABGw3AIAAA6yAgAAG3AA= Date: Mon, 1 Jun 2020 13:35:02 +0000 Message-ID: <4F8449D8-6023-4A40-9C87-875299DD0EEF@citrix.com> References: <24270.35349.838484.116865@mariner.uk.xensource.com> <0D83AAA6-A205-4256-8A38-CC8122AC063D@citrix.com> <24272.59646.746545.343358@mariner.uk.xensource.com> <4a8e7cf2-8f63-d4d2-e051-9484a5b8c8ed@suse.com> <96F32637-E410-4EC8-937A-CFC8BE724352@citrix.com> <24273.8332.662607.125522@mariner.uk.xensource.com> <7eaa7541-f698-b29b-b4b3-1f40fc37c5d7@xen.org> <63838ce9-8dbf-aacf-521d-97540758a945@suse.com> <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6CEBF200CDBC864B8DBA3D7D42DD55FF@citrix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= , Stefano Stabellini , "cjwatson@debian.org" , Wei Liu , Andrew Cooper , Jan Beulich , "xen-devel@lists.xenproject.org" , Ian Jackson , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On Jun 1, 2020, at 2:10 PM, Julien Grall wrote: > 4. Extract the .config from the binary using a similar script to script/e= xtract-ikconfig. Ah, gotcha. I did misunderstand your suggestion. -George= From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:41:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:41:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkgV-0001E7-2T; Mon, 01 Jun 2020 13:40:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkgT-0001E2-D3 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:40:57 +0000 X-Inumbo-ID: 84e9b336-a40d-11ea-81bc-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 84e9b336-a40d-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 13:40:56 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: EiEC/4LNeYzNvajZEdL3Yks2kRlluXttvjFpXKdHb7DO0ZMwGZoFv6vXdEGnI43ZsuBkXp6oG9 X5h6LMaGyEg0QQCDGSfXrMx+6HNtG5xQEqGw3YiIkEJswL6NlEuv2plg+U4QrTvpA3ueqZZivg I4sfJ83kT+H4K56t0xe53B4C23kHA5qeN1KeHy4sMMClQ8sAEVeWG0q/t7OW6XCxBZfORqQay4 uAGPFyWcsY3bWVY2ndCWps9y9He5bu9b5suoPwI3pkzpcA4ODVLhdM8bqg8E2AFkV/OdRnhZa8 q0I= X-SBRS: 2.7 X-MesageID: 19661962 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,460,1583211600"; d="scan'208";a="19661962" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14] docs/ucode: Extend runtime microcode loading documentation Date: Mon, 1 Jun 2020 14:40:25 +0100 Message-ID: <20200601134025.24142-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Paul Durrant , Jan Beulich , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Extend the disclaimer about runtime loading. While we've done our best to make the mechaism reliable, the safety of late loading does ultimately depend on the contents of the blobs. Extend the xen-ucode portion with examples of how to use it. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall CC: Paul Durrant --- docs/admin-guide/microcode-loading.rst | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst index 5f0f661a2e..8cd5d0351b 100644 --- a/docs/admin-guide/microcode-loading.rst +++ b/docs/admin-guide/microcode-loading.rst @@ -104,8 +104,8 @@ modules to find any CPIO archives, and search the archive for the applicable file. Xen will stop searching at the first match. -Run time microcode loading --------------------------- +Runtime microcode loading +------------------------- .. warning:: @@ -113,7 +113,23 @@ Run time microcode loading or at boot time. Not all microcode updates (or parts thereof) can be applied at runtime. -The ``xen-ucode`` utility can be used to initiate a runtime microcode load. + Given the proprietry nature of microcode, we are unable to make any claim + that a runtime microcode is risk-free. Any runtime microcode loading needs + adequate testing on a dev instance before being rolled out to production + systems. + +The ``xen-ucode`` utility can be used to initiate a runtime microcode load:: + + [root@host ~]# xen-ucode + xen-ucode: Xen microcode updating tool + Usage: xen-ucode + [root@host ~]# + +e.g. With a Linux dom0 on a Haswell system:: + + [root@host ~]# xen-ucode /lib/firmware/intel-ucode/06-3c-03 + [root@host ~]# + It will pass the blob to Xen, which will check to see whether the blob is correct for the processor, and newer than the running microcode. -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:54:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:54:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfktY-0002Gh-LR; Mon, 01 Jun 2020 13:54:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfktX-0002GY-D6 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:54:27 +0000 X-Inumbo-ID: 67c38028-a40f-11ea-ab1d-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 67c38028-a40f-11ea-ab1d-12813bfff9fa; Mon, 01 Jun 2020 13:54:26 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 4qt90VmACEPxtLEgjd+wGQwkhHFgATKLovXG0ynly1zRDj7WrmW/W0blK63cKyHDinM669+Ubb FrfZMH+NTlS8oriz16y3K5dciQ/MBzZ+u58ZQw5J0RxIHnB8QD+S8TQghNeedCabEV1wUtu2uK FGpVh1l+MCYedB2sqm5iBL/IcpzmAF2xiJGROuN3Ix8gMMGQfoNDT8iIt6eHvgDa2SE2clruoV 9xkn27QDFx+zpcB3v572iwdVAImHcD5KCZwf17uO001kYr9qd8L4ixhBqa6kKzMKS4EzFLb0si 2Hc= X-SBRS: 2.7 X-MesageID: 19215687 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,461,1583211600"; d="scan'208";a="19215687" From: Roger Pau Monne To: Subject: [PATCH v3 1/2] x86/mm: do not attempt to convert _PAGE_GNTTAB to a boolean Date: Mon, 1 Jun 2020 15:53:24 +0200 Message-ID: <20200601135325.34156-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200601135325.34156-1-roger.pau@citrix.com> References: <20200601135325.34156-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Clang 10 complains with: mm.c:1239:10: error: converting the result of '<<' to a boolean always evaluates to true [-Werror,-Wtautological-constant-compare] if ( _PAGE_GNTTAB && (l1e_get_flags(l1e) & _PAGE_GNTTAB) && ^ xen/include/asm/x86_64/page.h:161:25: note: expanded from macro '_PAGE_GNTTAB' #define _PAGE_GNTTAB (1U<<22) ^ Remove the conversion of _PAGE_GNTTAB to a boolean and instead use a preprocessor conditional to check if _PAGE_GNTTAB is defined. Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich --- Changes since v2: - Add comment. Changes since v1: - Use a preprocessor conditional. --- xen/arch/x86/mm.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 53e3dcb2d4..e376fc7e8f 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -1235,8 +1235,14 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain *l1e_owner) * * (Note that the undestroyable active grants are not a security hole in * Xen. All active grants can safely be cleaned up when the domain dies.) + * + * NB: the preprocessor conditional is required in order to prevent clang's + * -Wtautological-constant-compare complaining about converting the result + * of a << into a bool is always true if it's evaluated directly in the if + * condition. */ - if ( _PAGE_GNTTAB && (l1e_get_flags(l1e) & _PAGE_GNTTAB) && +#if _PAGE_GNTTAB + if ( (l1e_get_flags(l1e) & _PAGE_GNTTAB) && !l1e_owner->is_shutting_down && !l1e_owner->is_dying ) { gdprintk(XENLOG_WARNING, @@ -1244,6 +1250,7 @@ void put_page_from_l1e(l1_pgentry_t l1e, struct domain *l1e_owner) l1e_get_intpte(l1e)); domain_crash(l1e_owner); } +#endif /* * Remember we didn't take a type-count of foreign writable mappings -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:54:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:54:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfktV-0002GS-DU; Mon, 01 Jun 2020 13:54:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfktU-0002GN-DP for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:54:24 +0000 X-Inumbo-ID: 6616f160-a40f-11ea-81bc-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6616f160-a40f-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 13:54:23 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 4KYDU8yOE7cRy2lc3w4OLANl5w6fh7aqQN2GsYYg8FXBuUTEfQvqmJ5u5eucXNNFdNWCg7nbEj kgkx75+dKVRjFQf3Tjs/EHEVMTBLJeOyTzBUcyvYU072VwbJWB/08NvkaxSG9cr/dbZIL4baxC f3zccThPE/27BZYxiBCWNVYLNI9wlIC6mouHHUy0qVA3dickpgeSIovy/wGCvxtUpWar/5NtIN wHuedXb3EovSqPr7mo4CLcRn0r/+9zp8QbpHwTW3Ai3DoKn2uO1v3EKmXXUj76svPhagjw7m+b rHY= X-SBRS: 2.7 X-MesageID: 19273160 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,461,1583211600"; d="scan'208";a="19273160" From: Roger Pau Monne To: Subject: [PATCH v3 0/2] clang/llvm: build fixes Date: Mon, 1 Jun 2020 15:53:23 +0200 Message-ID: <20200601135325.34156-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, Two pending bug fixes for clang/llvm toolstacks. Roger Pau Monne (2): x86/mm: do not attempt to convert _PAGE_GNTTAB to a boolean build32: don't discard .shstrtab in linker script xen/arch/x86/boot/build32.lds | 14 ++++++++++++++ xen/arch/x86/mm.c | 9 ++++++++- 2 files changed, 22 insertions(+), 1 deletion(-) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:54:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:54:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfktd-0002HF-Tz; Mon, 01 Jun 2020 13:54:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfktc-0002Gy-BA for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:54:32 +0000 X-Inumbo-ID: 69163ce0-a40f-11ea-ab1d-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 69163ce0-a40f-11ea-ab1d-12813bfff9fa; Mon, 01 Jun 2020 13:54:28 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: sVIGuYT6wuHcAonyZ38W2nycDKp7UJw344QeU+pC4GVEpCF6iMHC2c3+fzesUdvrOvHW5waw1l 14tRczf9UcUAdiWTz1aTwvKden+IEVCntbDPMu75Nze0dXDG5A/OEDiA03NwboGx3+tgWSmyw4 452MGiLWj33XCMnplr+gb6bscf65+W1G1VP0aoNyI3svWOpnNIDKuGW/NZl4//YFsFyfiABiE1 c6SpcODi54eY3TV8+oKP1fq5vI/MrJzun9gooG+7qyb9Olyjh4Zo79WScNBr6Uj1/AD3cq6Zyq jpw= X-SBRS: 2.7 X-MesageID: 19215690 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,461,1583211600"; d="scan'208";a="19215690" From: Roger Pau Monne To: Subject: [PATCH v3 2/2] build32: don't discard .shstrtab in linker script Date: Mon, 1 Jun 2020 15:53:25 +0200 Message-ID: <20200601135325.34156-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200601135325.34156-1-roger.pau@citrix.com> References: <20200601135325.34156-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" LLVM linker doesn't support discarding .shstrtab, and complains with: ld -melf_i386_fbsd -N -T build32.lds -o reloc.lnk reloc.o ld: error: discarding .shstrtab section is not allowed Add an explicit .shstrtab, .strtab and .symtab sections to the linker script after the text section in order to make LLVM LD happy and match the behavior of GNU LD. Signed-off-by: Roger Pau Monné Acked-by: Jan Beulich --- Changes since v2: - Also add .strtab and .symtab sections to match GNU behavior. --- xen/arch/x86/boot/build32.lds | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/xen/arch/x86/boot/build32.lds b/xen/arch/x86/boot/build32.lds index 97454b40ff..1ab9418793 100644 --- a/xen/arch/x86/boot/build32.lds +++ b/xen/arch/x86/boot/build32.lds @@ -50,6 +50,20 @@ SECTIONS *(.got.plt) } + /* + * Discarding .shstrtab is not supported by LLD (LLVM LD) and will trigger an + * error. Also keep the rest of the control sections to match GNU LD behavior. + */ + .shstrtab : { + *(.shstrtab) + } + .strtab : { + *(.strtab) + } + .symtab : { + *(.symtab) + } + /DISCARD/ : { /* * Discard everything else, to prevent linkers from putting -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 13:57:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 13:57:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkwD-0002Zc-B2; Mon, 01 Jun 2020 13:57:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkwB-0002ZR-Ie for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 13:57:11 +0000 X-Inumbo-ID: ca231954-a40f-11ea-9dbe-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ca231954-a40f-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 13:57:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=RI26nJEjlSMT+f2wgvD/8C4nvY4PnmZob0X/mxL/G5k=; b=zTkV/8cF0m5u/kJ4SPZeHmeKGE SyEMYmhlO122dSqUT7sdZ9N7u+01MaxjklfBL5KQ2s937mpoqdceL0rIstFxFeDKHQSyb0W05nkIV hoMGmmiXkN/pWYIDWAbYzgsoZR5ka+FnK+bZyhv8V4aYnnqPCrDysm6t2KFWWQmvqsRo=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfkw9-0002l7-Ss; Mon, 01 Jun 2020 13:57:09 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jfkw9-0005bk-Lv; Mon, 01 Jun 2020 13:57:09 +0000 Subject: Re: Xen XSM/FLASK policy, grub defaults, etc. To: George Dunlap References: <24270.35349.838484.116865@mariner.uk.xensource.com> <0D83AAA6-A205-4256-8A38-CC8122AC063D@citrix.com> <24272.59646.746545.343358@mariner.uk.xensource.com> <4a8e7cf2-8f63-d4d2-e051-9484a5b8c8ed@suse.com> <96F32637-E410-4EC8-937A-CFC8BE724352@citrix.com> <24273.8332.662607.125522@mariner.uk.xensource.com> <7eaa7541-f698-b29b-b4b3-1f40fc37c5d7@xen.org> <63838ce9-8dbf-aacf-521d-97540758a945@suse.com> <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> <4F8449D8-6023-4A40-9C87-875299DD0EEF@citrix.com> From: Julien Grall Message-ID: <51c5e3db-48a9-9ef6-699c-e8b48db1b499@xen.org> Date: Mon, 1 Jun 2020 14:57:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <4F8449D8-6023-4A40-9C87-875299DD0EEF@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Stefano Stabellini , "cjwatson@debian.org" , Wei Liu , Andrew Cooper , Jan Beulich , "xen-devel@lists.xenproject.org" , Ian Jackson , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 01/06/2020 14:35, George Dunlap wrote: > > >> On Jun 1, 2020, at 2:10 PM, Julien Grall wrote: >> 4. Extract the .config from the binary using a similar script to script/extract-ikconfig. > > Ah, gotcha. I did misunderstand your suggestion. The advantage I can see with this solution is this is arch agnostic and can be easily extend to other options. But it also means at least some of CONFIG_* needs to be stable. Can this solution be an alternative to the ELF note? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:05:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:05:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfl4G-0003Yr-4d; Mon, 01 Jun 2020 14:05:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfl4E-0003Ym-2C for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:05:30 +0000 X-Inumbo-ID: f292ef3a-a410-11ea-ab1e-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f292ef3a-a410-11ea-ab1e-12813bfff9fa; Mon, 01 Jun 2020 14:05:29 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: vKrbtZoTEaGsAp+FDXIM5zE2w1ao9mmNZbEahv6IwLPK08ItENm+RpnF9+7U8IV1wH+gDTON+L Xv7CAeoBpgzY45phJsx1CfsLeSKuzxRuKiKVOvW0EumEYl8TAxFjo0H8zEEOHQwPURRr7gobpt OcHrRl0QAjHGIemis3Gd3dlxe+BVNHjFYprrOs6Zsz7ZvNiok/5egN0E1mN7oG9Lu9qHG39wA6 hxEWVRPhoetS8lRusDNW+RcHCf/Aau0E8aYAY4qT5BAuxISpAGEbEmmLvOXUr1L7Nt6SAA8IMJ M6o= X-SBRS: 2.7 X-MesageID: 18943836 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,461,1583211600"; d="scan'208";a="18943836" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <24277.2850.827651.585185@mariner.uk.xensource.com> Date: Mon, 1 Jun 2020 15:05:22 +0100 To: George Dunlap Subject: Re: Xen XSM/FLASK policy, grub defaults, etc. In-Reply-To: References: <24270.35349.838484.116865@mariner.uk.xensource.com> <0D83AAA6-A205-4256-8A38-CC8122AC063D@citrix.com> <24272.59646.746545.343358@mariner.uk.xensource.com> <4a8e7cf2-8f63-d4d2-e051-9484a5b8c8ed@suse.com> <96F32637-E410-4EC8-937A-CFC8BE724352@citrix.com> <24273.8332.662607.125522@mariner.uk.xensource.com> <7eaa7541-f698-b29b-b4b3-1f40fc37c5d7@xen.org> <63838ce9-8dbf-aacf-521d-97540758a945@suse.com> <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?iso-8859-1?Q?J=FCrgen_Gro=DF?= , Stefano Stabellini , Julien Grall , "cjwatson@debian.org" , Wei Liu , Andrew Cooper , Jan Beulich , "xen-devel@lists.xenproject.org" , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."): > The options proposed have included: Thanks for summarising! > 1. Making the tools not generate a FLASK policy unless FLASK is enabled in the hypervisor being built. This is flaky because there’s no necessary connection between the two builds. ... > Ultimately, I have the feeling that #1, although somewhat awkward, is going to be the best solution: packagers can arrange that FLASK policies only be installed when FLASK policies are created. People doing self-builds based on distro packages will be covered; people doing home-grown self-builds with non-default FLASK settings will need to take extra care to make sure the tools do the right thing. For these home-grown self-builds, making `flask=enforcing' the default boot entry will make the resulting entry not boot. So ISTM that `flask=enforcing' cannot be in the default boot entry unless it's *known* that FLASK is enabled in the hypervisor. (Right now update-grub does not make the XSM entries the default, but clearly it would be better for it to do so if FLASK is enabled.) Adding the /boot/.config fallback to update-grub now risks accidentally going back to non-FLASK booting at some future point when the xen packager decides not to ship the .config any more... Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:29:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:29:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRh-0005Pg-PM; Mon, 01 Jun 2020 14:29:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRg-0005PZ-Ks for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:29:44 +0000 X-Inumbo-ID: 51863440-a414-11ea-81bc-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 51863440-a414-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 14:29:36 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id r9so10881094wmh.2 for ; Mon, 01 Jun 2020 07:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vBrOLTqq31ej2e44mSMA9447regWRi/096me+XUNWFc=; b=aYp6jMcbZt1EvSCtzGVSDvw0LjOVZN9U9J6IPOWER7nZTfo2AJX9+2u9BbzugNhsHn Y37qYszwgtSp5Vi9meiZMPRCBrru/b392x/XySILcHH864UsCPa7D4edh2DtjgMpgeQF KB7IfsR9l+RvEZ41vlpb8yOXOfnby9TjY8pU9epCl8a2EIRP3GOpubRy0xq+tjioH92Q ZdZKA/fD+8ONkO9XePvj6FRtCYXyfnGwh41bJX2ZwRt55t3Wk2i7NgF8TKRcQ/D5WHp8 c0MPNHyco0u+zIe2mvXsvW8NO9B/YVxgKM1DhZ0+Xu714KN+vQ5Tl3CCM4/snBRMzpJh MyCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=vBrOLTqq31ej2e44mSMA9447regWRi/096me+XUNWFc=; b=QbaUt0u3c2+4FILIcsGY/b2eG3r3el9ObxRGcPO5wIytG3xKTYuXQBX0CGMSnr1sY8 Xx0byOmb2K38DGINqF6iwxHhKo6F9rXo78xzI/38IBsy6IjisiWaHXFXLQzffzEMC6fB XK0vyDrni/U5WEKOqYAvkEDiLPwzNcMta3DB9ag5l9+7TEAiOAlZPHojQunekx4dmgcm Flj38FyGr+BegAB1kDpIhcbfDzGK7c0cKGkEGeryVTVLV/XYjDVHzdi6nMIRrdy2q628 sBx4438ZvH/pFp5wbhmNJnnfO/iga91ZgZiZtBiXkXPwu6FEdbUnmuStE8vOyRLu2lY2 DqWQ== X-Gm-Message-State: AOAM533pUyQFaWwTlTGl8kT4WRus/0jehGKpxaEVkkhkN/bSU7bJHzIE P2M7nS38/bYXnajocOupFIE= X-Google-Smtp-Source: ABdhPJzOxS6SdO4MzNSLT95XruS6WV6AMszcyX4HNvgqW82fuRu7xSM8biS+Gv+YwkDeI9wFb3oYMQ== X-Received: by 2002:a1c:814c:: with SMTP id c73mr21234151wmd.140.1591021775955; Mon, 01 Jun 2020 07:29:35 -0700 (PDT) Received: from localhost.localdomain (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id u12sm6824954wrq.90.2020.06.01.07.29.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 07:29:35 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH v2 2/8] hw/pci-host/prep: Correct RAVEN bus bridge memory region size Date: Mon, 1 Jun 2020 16:29:24 +0200 Message-Id: <20200601142930.29408-3-f4bug@amsat.org> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200601142930.29408-1-f4bug@amsat.org> References: <20200601142930.29408-1-f4bug@amsat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" memory_region_set_size() handle the 16 Exabytes limit by special-casing the UINT64_MAX value. This is not a problem for the 32-bit maximum, 4 GiB. By using the UINT32_MAX value, the bm-raven MemoryRegion ends up missing 1 byte: $ qemu-system-ppc -M prep -S -monitor stdio -usb memory-region: bm-raven 0000000000000000-00000000fffffffe (prio 0, i/o): bm-raven 0000000000000000-000000003effffff (prio 0, i/o): alias bm-pci-memory @pci-memory 0000000000000000-000000003effffff 0000000080000000-00000000ffffffff (prio 0, i/o): alias bm-system @system 0000000000000000-000000007fffffff Fix by using the correct value. We now have: memory-region: bm-raven 0000000000000000-00000000ffffffff (prio 0, i/o): bm-raven 0000000000000000-000000003effffff (prio 0, i/o): alias bm-pci-memory @pci-memory 0000000000000000-000000003effffff 0000000080000000-00000000ffffffff (prio 0, i/o): alias bm-system @system 0000000000000000-000000007fffffff Reviewed-by: Peter Maydell Signed-off-by: Philippe Mathieu-Daudé --- hw/pci-host/prep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/pci-host/prep.c b/hw/pci-host/prep.c index 1a02e9a670..88e2fc66a9 100644 --- a/hw/pci-host/prep.c +++ b/hw/pci-host/prep.c @@ -294,7 +294,7 @@ static void raven_pcihost_initfn(Object *obj) &s->pci_memory, &s->pci_io, 0, TYPE_PCI_BUS); /* Bus master address space */ - memory_region_init(&s->bm, obj, "bm-raven", UINT32_MAX); + memory_region_init(&s->bm, obj, "bm-raven", 4 * GiB); memory_region_init_alias(&s->bm_pci_memory_alias, obj, "bm-pci-memory", &s->pci_memory, 0, memory_region_size(&s->pci_memory)); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:29:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:29:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRY-0005Ol-4z; Mon, 01 Jun 2020 14:29:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRW-0005Og-QM for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:29:34 +0000 X-Inumbo-ID: 4fd15c88-a414-11ea-9947-bc764e2007e4 Received: from mail-wm1-x331.google.com (unknown [2a00:1450:4864:20::331]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4fd15c88-a414-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 14:29:33 +0000 (UTC) Received: by mail-wm1-x331.google.com with SMTP id f185so11593464wmf.3 for ; Mon, 01 Jun 2020 07:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ZM7/znQriD0UhsswZg6MLv2Z3oBcZnpOAq0NEHbW664=; b=GGgHYPRiatHdFDW9BVH8eF+dSyAynNmKp7tCKjge/3dzd5/m4+sDYh6i+4CuC5eLnk d0K9s7FRYLtW94rL93bIkN/F7acb+khmY4E/jXZ1+TK0lKJF6DwpIBoGcy9+FjiVQ8J9 7rFPUqqlrBtnqHcc5XCpn7TgT39xntNtLVatlVAThT01V8OoIhDmcEhbQwH+v9/vTefx QbSfJSl1P16H7ir6sCNJi5IW6OyYMHqgHYolpGT/KvNvl6YtjqK/ZBPCr7uPoowpHCVJ jwhp67uNSCvqURSdBp37Z4gJjZsIkxpb3v1DRn+Brn7MWWRG4OMLkp7HpEQbF9T+B8Xc fbvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-transfer-encoding; bh=ZM7/znQriD0UhsswZg6MLv2Z3oBcZnpOAq0NEHbW664=; b=ToAZhxgcMOP6nm0qzcBbZ04/H9pJj/A99k7oJr0u+kty4drShD72uJQEe1oeBJEiG+ bYAkNoD96NbCrhoYf3O2XTErIGkj4u7dH/+/nQB4Ei1Fr3SkJSVTFuqK7ZbAAjyPpwHo vhr4pGqgaHssHkeDqSYdAqyMh02Qbu7lxe5DADIkwOl1fi+5tSIMc5xHCCbzYs6OLINg EOYQWKeHMztUg7NcwVcPvhksJ9eO/qpHEM0sexpDB1wQQBlQkJyfR9jmWOMwAViKEAE1 eNIWRxSqI/ynCC84WG9qvbf/R9tnLjgm5CKKGn37/aR491IdfnY+bOeUWq1UPEogaJlz ZU+g== X-Gm-Message-State: AOAM530WV5R5+qBERrXu5GjtoMW/9+JqPhBFQgyAnbHIeKElxWg9Mtj/ +nMwGlOJZUsJNSxLD0KQj50= X-Google-Smtp-Source: ABdhPJwufRnQl4HmwANVRDq93UByxPUJbZfC4pM9aQ9eCt/8cwII0ubngoSEbHzq8tnEDNEvDybD9g== X-Received: by 2002:a1c:998c:: with SMTP id b134mr22850671wme.78.1591021773028; Mon, 01 Jun 2020 07:29:33 -0700 (PDT) Received: from localhost.localdomain (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id u12sm6824954wrq.90.2020.06.01.07.29.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 07:29:32 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH v2 0/8] hw: Fix some incomplete memory region size Date: Mon, 1 Jun 2020 16:29:22 +0200 Message-Id: <20200601142930.29408-1-f4bug@amsat.org> X-Mailer: git-send-email 2.21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Series fully reviewed. Since v1: - Add parenthesis on the Xen patch (Paul Durrant) - Add Peter's R-b tags memory_region_set_size() handle the 16 Exabytes limit by special-casing the UINT64_MAX value. This is not a problem for the 32-bit maximum, 4 GiB, but in some places we incorrectly use UINT32_MAX instead of 4 GiB, and end up missing 1 byte in the memory region. This series fixes the cases I encountered. Also included few patches while reviewing, I replaced some magic values by the IEC binary prefix equivalent. Regards, Phil. Philippe Mathieu-Daudé (8): hw/arm/aspeed: Correct DRAM container region size hw/pci-host/prep: Correct RAVEN bus bridge memory region size hw/pci/pci_bridge: Correct pci_bridge_io memory region size hw/pci/pci_bridge: Use the IEC binary prefix definitions hw/pci-host: Use the IEC binary prefix definitions hw/hppa/dino: Use the IEC binary prefix definitions hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions target/i386/cpu: Use the IEC binary prefix definitions hw/arm/aspeed.c | 2 +- hw/hppa/dino.c | 4 ++-- hw/i386/xen/xen-hvm.c | 3 ++- hw/pci-host/i440fx.c | 3 ++- hw/pci-host/prep.c | 2 +- hw/pci-host/q35.c | 2 +- hw/pci-host/versatile.c | 5 +++-- hw/pci/pci_bridge.c | 7 ++++--- target/i386/cpu.c | 2 +- 9 files changed, 17 insertions(+), 13 deletions(-) -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:29:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:29:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRc-0005Oz-D2; Mon, 01 Jun 2020 14:29:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRb-0005Ot-Kj for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:29:39 +0000 X-Inumbo-ID: 50afece6-a414-11ea-8993-bc764e2007e4 Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 50afece6-a414-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 14:29:35 +0000 (UTC) Received: by mail-wm1-x343.google.com with SMTP id f185so11593562wmf.3 for ; Mon, 01 Jun 2020 07:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HzSo+FKM+7hllBEEZUwDzngvpJfgcJMgoiFq36o0B8U=; b=XTbutdDKkJKkajTBQBfb3gKAZ8HdQTRh7KPk2PRf4BKVCmPN/4PTUsFkxrz9l/MxyE WUpRpf229tNzjnPfHSCA8du3tlIB75OS5/RVT9l2X8Pi8CcwsUCX6HO+2vIyYWMLw2tC ebQhYTRJklmhotmYL2rx/GdLsCDfCBNHfnduxY4Q5bNFjSm8izV9JBOdMPkxXDwKlw4c 031Lz9blGnoP7VIxmgxsb+iWzGBmm5T0wI/Tv3aiTxDNGjcUF71CVDuNVRspxPMH9UPA 3nwu20FxG3BzD2wN0HUsD79p+AZtAAKT3qF+a+MxMkbmLHvKPtyLwMf0vUqt0hTFsvk2 JbNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=HzSo+FKM+7hllBEEZUwDzngvpJfgcJMgoiFq36o0B8U=; b=I6lssgU33SyusPhn97mHp5QEF+Y8kS64LSyi2vSDrUOMcU6AmjtLh6X6Qr5237ntJB ZGUPufjnURc0KJU0bJD7oZGyYv0p+YKZ/aiTqUHNvDh0V/Y6tHTf4DCDP/mYwBNqloky Wv0jh/CunPc5Vsi6LZARxULXIxjLKzW/xgl7hQTaolDe93iu5CeQKaSElv8BZHgjTyap 1ioU0787g5346F1yqx9GC66NqOOaLCLkIJnI780cJymp1Kp1sR53jwzWSor5nTqv3fMk axjMWL5lxtsRggNpe3V/7OZSVimXaU4vy6atFcBRGUlUXTOO6LsHGFzSWpgoBqUVAmNi jaFA== X-Gm-Message-State: AOAM531c9WRAFyz/UvAgHxctdI810ie+3pu8B8mFmS04Iy4Jp5X+WyDH F+u6KNe1Kg2QguYn099+QRw= X-Google-Smtp-Source: ABdhPJwBHE8bkJSVSp9Yf35551bkKIwhQ9ZWpujBeFh9r1gwWsJDZxkC3k++/FRQy/FR48XoWkpxlQ== X-Received: by 2002:a7b:c84b:: with SMTP id c11mr21338870wml.78.1591021774481; Mon, 01 Jun 2020 07:29:34 -0700 (PDT) Received: from localhost.localdomain (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id u12sm6824954wrq.90.2020.06.01.07.29.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 07:29:33 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH v2 1/8] hw/arm/aspeed: Correct DRAM container region size Date: Mon, 1 Jun 2020 16:29:23 +0200 Message-Id: <20200601142930.29408-2-f4bug@amsat.org> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200601142930.29408-1-f4bug@amsat.org> References: <20200601142930.29408-1-f4bug@amsat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" memory_region_set_size() handle the 16 Exabytes limit by special-casing the UINT64_MAX value. This is not a problem for the 32-bit maximum, 4 GiB. By using the UINT32_MAX value, the aspeed-ram-container MemoryRegion ends up missing 1 byte: $ qemu-system-arm -M ast2600-evb -S -monitor stdio (qemu) info mtree address-space: aspeed.fmc-ast2600-dma-dram 0000000080000000-000000017ffffffe (prio 0, i/o): aspeed-ram-container 0000000080000000-00000000bfffffff (prio 0, ram): ram 00000000c0000000-ffffffffffffffff (prio 0, i/o): max_ram Fix by using the correct value. We now have: address-space: aspeed.fmc-ast2600-dma-dram 0000000080000000-000000017fffffff (prio 0, i/o): aspeed-ram-container 0000000080000000-00000000bfffffff (prio 0, ram): ram 00000000c0000000-ffffffffffffffff (prio 0, i/o): max_ram Reviewed-by: Peter Maydell Signed-off-by: Philippe Mathieu-Daudé --- hw/arm/aspeed.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c index 2c23297edf..62344ac6a3 100644 --- a/hw/arm/aspeed.c +++ b/hw/arm/aspeed.c @@ -262,7 +262,7 @@ static void aspeed_machine_init(MachineState *machine) bmc = g_new0(AspeedBoardState, 1); memory_region_init(&bmc->ram_container, NULL, "aspeed-ram-container", - UINT32_MAX); + 4 * GiB); memory_region_add_subregion(&bmc->ram_container, 0, machine->ram); object_initialize_child(OBJECT(machine), "soc", &bmc->soc, -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:30:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:30:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRn-0005Qe-28; Mon, 01 Jun 2020 14:29:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRl-0005QA-Kb for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:29:49 +0000 X-Inumbo-ID: 5270d9b4-a414-11ea-9dbe-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5270d9b4-a414-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 14:29:38 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id d128so11621927wmc.1 for ; Mon, 01 Jun 2020 07:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=mxI9GbbijxDixix+zf0tcfiMCEcCufTLAytrxKWhnaw=; b=McijkDfUDfkGD5lMdNQ+M+R1KyklnbVnSE2xHGQXgc1FoZJoCchot8LzXFDjcv6KOM NfDZQCYHBzFyP55Su7iZS69grQCQSVbwDOPJ+fB1HbziyodXwYIRjrKQJxgmPT4ArVpq rm9Pu0LT63ray48uF1rziqp7IZcfFUNMkYG9A+LsNcigRtirUvuwvV444Ky81hpelupC +5N9EyRxBaOoygPIaPo+byEWNWCAKP5TJYnc3C0AUoXQLnUV2+IO/kOm471D5FNX4dGS PXeofGbkbTz3KyYJzwzy8JhQSJZBOmbcV67oJceaEhbsL8Eabp6qKyVKz5B+XRC8hlPA RKhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=mxI9GbbijxDixix+zf0tcfiMCEcCufTLAytrxKWhnaw=; b=ln2kB1BybxCf73EUlvDIgqcsP5a+sQJy8PF8FBXQ7ePpMOulOxpkgiEvZpY4y1Epmk IU6qxcXFV6b8OGAmNcz5wbpU+XpciqtZYiZOyYNEHIkkr/+/9yFWlX+vOgYJtdL1FO8T H0Qca5aSxjbLFd7KpkcNlypS5qjv8+QHZo8o3I5xJwbeeQHmssSWP/XAvr7LgXqPVe7e le3OCcMLKcjpo6MkrUTXEojJ08DQVQjZ6RHSLmm25n0qqGMsynhtqCHzNSwNHpa6q63H 9WSLHPiPnJ6hWMyic4K7azHgKTpZQC2J9AqrKQ1dWsb4udEop8mTciliNxIK6QH4Kihc EMrQ== X-Gm-Message-State: AOAM533jVFIMpTsrkc+DpKpz8YAhSHeoO8iBMFdYTlFKn3rZLoVnRG4o G/o1Iy117lAx9jVRcB/2pr4= X-Google-Smtp-Source: ABdhPJy45MyMB35sU56T7YLu7WldCE4HuCq6HN3F6gvzbGobgbl/tu9cwCNmdjlgEG1zdLyU9Mx++g== X-Received: by 2002:a7b:c248:: with SMTP id b8mr20855219wmj.2.1591021777436; Mon, 01 Jun 2020 07:29:37 -0700 (PDT) Received: from localhost.localdomain (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id u12sm6824954wrq.90.2020.06.01.07.29.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 07:29:36 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH v2 3/8] hw/pci/pci_bridge: Correct pci_bridge_io memory region size Date: Mon, 1 Jun 2020 16:29:25 +0200 Message-Id: <20200601142930.29408-4-f4bug@amsat.org> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200601142930.29408-1-f4bug@amsat.org> References: <20200601142930.29408-1-f4bug@amsat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" memory_region_set_size() handle the 16 Exabytes limit by special-casing the UINT64_MAX value. This is not a problem for the 32-bit maximum, 4 GiB. By using the UINT32_MAX value, the pci_bridge_io MemoryRegion ends up missing 1 byte: (qemu) info mtree memory-region: pci_bridge_io 0000000000000000-00000000fffffffe (prio 0, i/o): pci_bridge_io 0000000000000060-0000000000000060 (prio 0, i/o): i8042-data 0000000000000064-0000000000000064 (prio 0, i/o): i8042-cmd 00000000000001ce-00000000000001d1 (prio 0, i/o): vbe 0000000000000378-000000000000037f (prio 0, i/o): parallel 00000000000003b4-00000000000003b5 (prio 0, i/o): vga ... Fix by using the correct value. We now have: memory-region: pci_bridge_io 0000000000000000-00000000ffffffff (prio 0, i/o): pci_bridge_io 0000000000000060-0000000000000060 (prio 0, i/o): i8042-data 0000000000000064-0000000000000064 (prio 0, i/o): i8042-cmd ... Reviewed-by: Peter Maydell Signed-off-by: Philippe Mathieu-Daudé --- hw/pci/pci_bridge.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c index 97967d12eb..3ba3203f72 100644 --- a/hw/pci/pci_bridge.c +++ b/hw/pci/pci_bridge.c @@ -30,6 +30,7 @@ */ #include "qemu/osdep.h" +#include "qemu/units.h" #include "hw/pci/pci_bridge.h" #include "hw/pci/pci_bus.h" #include "qemu/module.h" @@ -381,7 +382,7 @@ void pci_bridge_initfn(PCIDevice *dev, const char *typename) memory_region_init(&br->address_space_mem, OBJECT(br), "pci_bridge_pci", UINT64_MAX); sec_bus->address_space_io = &br->address_space_io; memory_region_init(&br->address_space_io, OBJECT(br), "pci_bridge_io", - UINT32_MAX); + 4 * GiB); br->windows = pci_bridge_region_init(br); QLIST_INIT(&sec_bus->child); QLIST_INSERT_HEAD(&parent->child, sec_bus, sibling); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:30:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:30:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRr-0005Ru-AY; Mon, 01 Jun 2020 14:29:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRq-0005Rf-LR for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:29:54 +0000 X-Inumbo-ID: 5354e834-a414-11ea-9947-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5354e834-a414-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 14:29:39 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id h5so45439wrc.7 for ; Mon, 01 Jun 2020 07:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=WN1hnPJG9k0d4gUFGI62xXK6PTE3h6bC3clI/uY9zSA=; b=rQwXUg5DD3bZsQKBRP7+TLjtYRMRCkZaFS2Fc7UIHD4mZRBfDS/xiHu1Ue7JMj47lo YQCrXZP8AKSO/hQoXyFxRj5UVshxPxPHrfI8L5MRjJGqrtaXVeGmzmB9k3tsSYkegpHw rIZyb6oYca/YB/VWnAwFypBPoGjFMyWYhhvnp6dYTnCShgkU3DdL0ATl0WZqM+1xZXmC I1gkLtwqiSpUmsOC1Cw04fVuPZqiVTOd/bU8DnmQyuNBlhYQOcgvPtNCedgy/w67TQHv DYIcgr00vL3ihkHjppAsbuMqntmvih0rbRttVm6m483rOleYpDp9FZ9JTr7I1AgIraLC bcxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=WN1hnPJG9k0d4gUFGI62xXK6PTE3h6bC3clI/uY9zSA=; b=qfqkRYvNVHaoAxB55Bnii/mBzspbmaAzkPoqsjAuEtr8uLHqJ+dPMfzIjxyOHBCvCO XzE2yc7ltJiJBt7dWXY4y+6taQuYgSMEbZs6/A4g53Z6NvEgLnG3i474hdYcc/BtALlx yBa1keU8qAv9+2ZD5Zb70d9a4cfH4GcE7MkBUr67/eXaTGUoatipp4wwH3uejErSS45I dYHjnMdVVzLIaEVU0ewTVaQuIlYzznekosD+95hscYXXCChBk95d5LciNJxHPo54WCs8 OZ5eVwBQybXTGiggY1FexL2c7joJaTSGGjyYMj5YFPCr9nl6pw6qsUsBeAi7/5lyie0I LIHg== X-Gm-Message-State: AOAM533LSdUqQIS0dFzFDBtWK7QCwJakTtIPhdDj06RuOJHjsoh/KHbt R3fYv0QAeZLid85cACJOhzo= X-Google-Smtp-Source: ABdhPJwfd+Lxug+8AxI6OGeoNfDT9lWckWHvnv1aj7LAWzbZV5sI6ke1Qv8+v6JK7sIfbYizrcdCeQ== X-Received: by 2002:adf:bac8:: with SMTP id w8mr21300417wrg.47.1591021778914; Mon, 01 Jun 2020 07:29:38 -0700 (PDT) Received: from localhost.localdomain (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id u12sm6824954wrq.90.2020.06.01.07.29.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 07:29:38 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH v2 4/8] hw/pci/pci_bridge: Use the IEC binary prefix definitions Date: Mon, 1 Jun 2020 16:29:26 +0200 Message-Id: <20200601142930.29408-5-f4bug@amsat.org> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200601142930.29408-1-f4bug@amsat.org> References: <20200601142930.29408-1-f4bug@amsat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Peter Maydell Signed-off-by: Philippe Mathieu-Daudé --- hw/pci/pci_bridge.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/pci/pci_bridge.c b/hw/pci/pci_bridge.c index 3ba3203f72..3789c17edc 100644 --- a/hw/pci/pci_bridge.c +++ b/hw/pci/pci_bridge.c @@ -423,14 +423,14 @@ int pci_bridge_qemu_reserve_cap_init(PCIDevice *dev, int cap_offset, } if (res_reserve.mem_non_pref != (uint64_t)-1 && - res_reserve.mem_non_pref >= (1ULL << 32)) { + res_reserve.mem_non_pref >= 4 * GiB) { error_setg(errp, "PCI resource reserve cap: mem-reserve must be less than 4G"); return -EINVAL; } if (res_reserve.mem_pref_32 != (uint64_t)-1 && - res_reserve.mem_pref_32 >= (1ULL << 32)) { + res_reserve.mem_pref_32 >= 4 * GiB) { error_setg(errp, "PCI resource reserve cap: pref32-reserve must be less than 4G"); return -EINVAL; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:30:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:30:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRw-0005UD-J0; Mon, 01 Jun 2020 14:30:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflRv-0005Tp-KU for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:29:59 +0000 X-Inumbo-ID: 5430da60-a414-11ea-9947-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5430da60-a414-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 14:29:41 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id r15so11562762wmh.5 for ; Mon, 01 Jun 2020 07:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=R1c6Ywd2WY7bkeebkfpfDjPJtSo9TSSd8GLZEIuba7M=; b=KOMpvQ1h+cZ/GQVz8Qxdx0mis+TlMoxKHuaO2rSRSRaGWhvUFWWUqHiwcfE323UL85 aFEytOww3L6zSlWIZYTfxs/42vrUDiv9C6o/n7DgZcVeQbTpRmEyDlSCBhRvyEEe/q1E KTruiQ5Yb9wpzHMcL/S5jvbB3uNWlV8t7A15KU5YJuRpiEXQ8HrJAra1lGOBEpLrTZ3O 642Vmt3sR4HbgPjDypLJB8+Ui1R+27mPnBXP523uszOrtFVLjhJkd3kdzmV8PrhICcHq x0ChezwGeMAvWpPgfm2AcOw/MfHwRzWWgyDUEAGIrSzdPEIsC91vU304u1JiiHnltmvV YGWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=R1c6Ywd2WY7bkeebkfpfDjPJtSo9TSSd8GLZEIuba7M=; b=eceXSelJKc3Ns6ByncE03RFugJERuw285xfaabpympbGfERp7DqegewR/3wqYCYIRS 01C+m+0xJP/NQvaHac8uFZiVglPLfs+tDEePcm+1FqdvFB8UcQzF7yeBXuDsV0TTd6rE wGKKa6S1WKeozlboKfrCDHeutqk5zOBUhxKEWrszA5EO+8Uh443BsF4xrD6kM0oswnTx LwGHEXuppeztthwUKFqeMzMTNM7nohQ9i1g8zb+DNP7FhDilIk+4ezitrsJkkqBhvpbH 4zYEP2J5EbKgw196a2a5E+iXh0zoo6vxtAB4A7vC3T1ini1hFe07QVM+RRtzUiAdObUa +qNQ== X-Gm-Message-State: AOAM530S+CV37jdRWa66FcFT1bEUz4h22bFdif1fgbIaKomv5SQy9KO/ qUekrdBvk7Jq8qGOtV4Luik= X-Google-Smtp-Source: ABdhPJwdSMIYLsZyoLFaZUJVXdLPvSbS6G1a5vB2dplcqD0mIzzFuz5/mh32BbsK8QB7xfYYy+wUTQ== X-Received: by 2002:a1c:7f96:: with SMTP id a144mr21650923wmd.176.1591021780425; Mon, 01 Jun 2020 07:29:40 -0700 (PDT) Received: from localhost.localdomain (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id u12sm6824954wrq.90.2020.06.01.07.29.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 07:29:39 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH v2 5/8] hw/pci-host: Use the IEC binary prefix definitions Date: Mon, 1 Jun 2020 16:29:27 +0200 Message-Id: <20200601142930.29408-6-f4bug@amsat.org> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200601142930.29408-1-f4bug@amsat.org> References: <20200601142930.29408-1-f4bug@amsat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Peter Maydell Signed-off-by: Philippe Mathieu-Daudé --- hw/pci-host/i440fx.c | 3 ++- hw/pci-host/q35.c | 2 +- hw/pci-host/versatile.c | 5 +++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c index 0adbd77553..aefb416c8f 100644 --- a/hw/pci-host/i440fx.c +++ b/hw/pci-host/i440fx.c @@ -23,6 +23,7 @@ */ #include "qemu/osdep.h" +#include "qemu/units.h" #include "qemu/range.h" #include "hw/i386/pc.h" #include "hw/pci/pci.h" @@ -301,7 +302,7 @@ PCIBus *i440fx_init(const char *host_type, const char *pci_type, memory_region_set_enabled(&f->smram_region, true); /* smram, as seen by SMM CPUs */ - memory_region_init(&f->smram, OBJECT(d), "smram", 1ull << 32); + memory_region_init(&f->smram, OBJECT(d), "smram", 4 * GiB); memory_region_set_enabled(&f->smram, true); memory_region_init_alias(&f->low_smram, OBJECT(d), "smram-low", f->ram_memory, 0xa0000, 0x20000); diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c index 352aeecfa7..b788f17b2c 100644 --- a/hw/pci-host/q35.c +++ b/hw/pci-host/q35.c @@ -589,7 +589,7 @@ static void mch_realize(PCIDevice *d, Error **errp) memory_region_set_enabled(&mch->open_high_smram, false); /* smram, as seen by SMM CPUs */ - memory_region_init(&mch->smram, OBJECT(mch), "smram", 1ull << 32); + memory_region_init(&mch->smram, OBJECT(mch), "smram", 4 * GiB); memory_region_set_enabled(&mch->smram, true); memory_region_init_alias(&mch->low_smram, OBJECT(mch), "smram-low", mch->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE, diff --git a/hw/pci-host/versatile.c b/hw/pci-host/versatile.c index cfb9a78ea6..8ddfb8772a 100644 --- a/hw/pci-host/versatile.c +++ b/hw/pci-host/versatile.c @@ -8,6 +8,7 @@ */ #include "qemu/osdep.h" +#include "qemu/units.h" #include "hw/sysbus.h" #include "migration/vmstate.h" #include "hw/irq.h" @@ -399,8 +400,8 @@ static void pci_vpb_realize(DeviceState *dev, Error **errp) pci_map_irq_fn mapfn; int i; - memory_region_init(&s->pci_io_space, OBJECT(s), "pci_io", 1ULL << 32); - memory_region_init(&s->pci_mem_space, OBJECT(s), "pci_mem", 1ULL << 32); + memory_region_init(&s->pci_io_space, OBJECT(s), "pci_io", 4 * GiB); + memory_region_init(&s->pci_mem_space, OBJECT(s), "pci_mem", 4 * GiB); pci_root_bus_new_inplace(&s->pci_bus, sizeof(s->pci_bus), dev, "pci", &s->pci_mem_space, &s->pci_io_space, -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:30:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:30:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflS1-00061b-S9; Mon, 01 Jun 2020 14:30:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflS0-0005qv-Kf for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:30:04 +0000 X-Inumbo-ID: 55004566-a414-11ea-8993-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 55004566-a414-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 14:29:42 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id f5so11595330wmh.2 for ; Mon, 01 Jun 2020 07:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=XKZlJlfX9Xx9NUQxmLIoeX0hJAW9cFlHOUMdlpNFhrg=; b=uSgMGz3lX/zCVeS5N2hb8kMocWnJrBQD0iyV3MRylloSoTofEcoBsiR9QFxYNgbzRV qh0sLJ+RiNFsR4CIT2VAg2+CO6sT0D0sdl/G2m5Iu6v6cM/TOGhGbYSr5Xo9r6pD1DWI jp1YxowX9bE34rtK9aLe4e++e+a7K+9LrUMvhpkWmyyTfu/5M+ku9VfHOVsT2oZAMGk3 HGgIDmQRereUYlDCOeFKcsvo8+Dw2V7uUTFwNprKVWgTj5Q3a/RSyWhg2iXQiIdBfQbq Z2Of3QPTdmADNKrA5GfKeIcMFruSd5R0KWbHfTnHTzjpjE0TMDAyXSj/8s5aY1AanxyN xwyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=XKZlJlfX9Xx9NUQxmLIoeX0hJAW9cFlHOUMdlpNFhrg=; b=iF4MDk9H3ZqtTrxRPpzBqk81hJwIG0zs15cX+bBTCJtaVH0GdIPbIOvAJOSrdpwJ0+ xZZziGJ2j0wJh4nMx4hcRMofmQvitdhW5PeQT0FZwKuNXBp/+VRdJU2htqlaXqZu12tp RsQbEJIxSUj//+Lr++7bytF+UDHS2KyqOGXua1oB3DSzoGTdbk9PqhKulPM//IB02T6y lVKB6AUcFo5iJNi3xJZS/cLnQani/8cq9o5OIhJvgy8Sy4QIEuXTX3l7BGvU7AbQpM8S 3IL12WE2RklGc3xzWVGYm0Fn2P3WoKDopTTLIOADb87/ZnrhZ41I5rbTMHVVDzRiAnu3 omJw== X-Gm-Message-State: AOAM530kkCdKulU3bX1dRGGt79ZXmBLqd3zsaI2wntaffn8vEjDAk2W7 ebOZaToyGsakPAC7zxLV0lU= X-Google-Smtp-Source: ABdhPJyt8wH6JL4N0YS0dHM+IbzIPnoHhEte70jcFfAz1FX5YUjQQxAFfQgPQNYsKKu4k4TKF2I/Wg== X-Received: by 2002:a1c:f006:: with SMTP id a6mr21730886wmb.106.1591021781801; Mon, 01 Jun 2020 07:29:41 -0700 (PDT) Received: from localhost.localdomain (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id u12sm6824954wrq.90.2020.06.01.07.29.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 07:29:41 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH v2 6/8] hw/hppa/dino: Use the IEC binary prefix definitions Date: Mon, 1 Jun 2020 16:29:28 +0200 Message-Id: <20200601142930.29408-7-f4bug@amsat.org> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200601142930.29408-1-f4bug@amsat.org> References: <20200601142930.29408-1-f4bug@amsat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Peter Maydell Signed-off-by: Philippe Mathieu-Daudé --- hw/hppa/dino.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/hppa/dino.c b/hw/hppa/dino.c index 2b1b38c58a..7290f23962 100644 --- a/hw/hppa/dino.c +++ b/hw/hppa/dino.c @@ -542,7 +542,7 @@ PCIBus *dino_init(MemoryRegion *addr_space, &s->parent_obj.data_mem); /* Dino PCI bus memory. */ - memory_region_init(&s->pci_mem, OBJECT(s), "pci-memory", 1ull << 32); + memory_region_init(&s->pci_mem, OBJECT(s), "pci-memory", 4 * GiB); b = pci_register_root_bus(dev, "pci", dino_set_irq, dino_pci_map_irq, s, &s->pci_mem, get_system_io(), @@ -561,7 +561,7 @@ PCIBus *dino_init(MemoryRegion *addr_space, } /* Set up PCI view of memory: Bus master address space. */ - memory_region_init(&s->bm, OBJECT(s), "bm-dino", 1ull << 32); + memory_region_init(&s->bm, OBJECT(s), "bm-dino", 4 * GiB); memory_region_init_alias(&s->bm_ram_alias, OBJECT(s), "bm-system", addr_space, 0, 0xf0000000 + DINO_MEM_CHUNK_SIZE); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:30:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:30:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflS6-0006CR-B0; Mon, 01 Jun 2020 14:30:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflS5-0006CA-LT for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:30:09 +0000 X-Inumbo-ID: 564b440c-a414-11ea-9947-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 564b440c-a414-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 14:29:44 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id x6so5292wrm.13 for ; Mon, 01 Jun 2020 07:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=SXUn2QQFzfY6E+figfmQGRv5xI8cdi2Y+xrdtsaM+Sw=; b=MeXAw86ml412WTe/fsbzOJTWxjk+Rldv3qgzlTd0jJQsOtea9XegxhBH/8V5pQOVnP fXogzJSZ+hjZIrhND/m9A/vKYTfmeAue9Qox3ZjWrudLmjNTRT6YUl7fSOC4OPEIlXJx RDxRfuk+01gSofzmvWqhy4bmcEJtYSyOoEDLf9Vz3tGnb4sbwtp/IvgM0YmiX9BnMdy+ m3rwE3Ca/xJv9Yp5SGAtoLPnH78Dt0QnoGznahyxH5L6k+XnfS/yXI1RBRVSkde7GJaA PWlTD9aL49q5TbVDMJrh3zuTWmQZ57Gq2f36LyP3VNPOpbvIdY6Grm5OwshvQp3Xu/wS nDTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=SXUn2QQFzfY6E+figfmQGRv5xI8cdi2Y+xrdtsaM+Sw=; b=R2dkXCAgcZUdPt+4RaS37bRWBNXwwNabbf1llN1yHkAHNrsqyVGxzkwLU67e60GjaO bLgc355QV/+Ar2sTqScRYXpwdt++xfJox4848VEp+pzoCjYI9eNZoorbHosm3VQJON5W 1opQ6b1RFhmtA/2smBqIsZZNObeUHjwtppiYAStGE73X0rvLBJb58Pw04PLCi/Vhw1+n IgA6Pdy7iziHZqPHQGrSSr7dy8cyUN6FTVjh4Oh0XtpCdrbEaGRdPAzbaFxIikjvx63i lzORidjc4ZfKvYDwRY6kh5JXfNzcMv1U4BDoCTVHVCG+hH9YtZOUVhBi3ERw90znygHQ tDLQ== X-Gm-Message-State: AOAM5333Qe8oBypSG//LqfdvKBNdVichkgLWDY9VhD5pADzLizhcCxHo bikN5/AfMPriWDJA8hmJd1M= X-Google-Smtp-Source: ABdhPJxGfoEw6g2vJ9OfpCjaYwWCmMl8Ah+Lnpp6R9LdwbX3+s5BYxOV3Vc5ZpcNzQGowCfzq7ym7w== X-Received: by 2002:adf:fe8d:: with SMTP id l13mr21567252wrr.282.1591021783964; Mon, 01 Jun 2020 07:29:43 -0700 (PDT) Received: from localhost.localdomain (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id u12sm6824954wrq.90.2020.06.01.07.29.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 07:29:43 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH v2 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions Date: Mon, 1 Jun 2020 16:29:29 +0200 Message-Id: <20200601142930.29408-8-f4bug@amsat.org> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200601142930.29408-1-f4bug@amsat.org> References: <20200601142930.29408-1-f4bug@amsat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Peter Maydell Signed-off-by: Philippe Mathieu-Daudé --- hw/i386/xen/xen-hvm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index 82ece6b9e7..94fe5d65e9 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -9,6 +9,7 @@ */ #include "qemu/osdep.h" +#include "qemu/units.h" #include "cpu.h" #include "hw/pci/pci.h" @@ -230,7 +231,7 @@ static void xen_ram_init(PCMachineState *pcms, * Xen does not allocate the memory continuously, it keeps a * hole of the size computed above or passed in. */ - block_len = (1ULL << 32) + x86ms->above_4g_mem_size; + block_len = (4 * GiB) + x86ms->above_4g_mem_size; } memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len, &error_fatal); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:30:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:30:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflSB-0006G8-Ky; Mon, 01 Jun 2020 14:30:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflSA-0006FR-Li for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:30:14 +0000 X-Inumbo-ID: 571b3b3a-a414-11ea-9dbe-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 571b3b3a-a414-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 14:29:46 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id k26so11592076wmi.4 for ; Mon, 01 Jun 2020 07:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=BWyCSlaGZ5iGWtDERp092wuI7W/yJ6Q5PNPhUdRKhqE=; b=YYdDUqhdLC78jQgiEyQ97vcy07tygmsEfX05PhXA32BxLX4Qe9twTWzZmVHR3RVHIY +iIyt1j0gFZqOFSr605qHbE2POl+jt9MJdfiedY4UGCiWC/djzHGT4gJjI3nG74wfkyf E/2/Kkh958INFuor/mhxBoXRwW4pFSd1w3zYBCgs8YkNUZoMLPAcfgJcNIx2hjDevr1L kgbcUNCBqqQhZlc+JNsd85h9B66dOpEA3+cInY/WOBNWG0Lc1Pa92lK7g4BUtZ4aaTKV mwP8Slp3c6cYpbvlWHqG1VDHdhtDUaTiWEO7Y4qycQdTKuVs8LtVl4dH8Jffj0657DSq Qi1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=BWyCSlaGZ5iGWtDERp092wuI7W/yJ6Q5PNPhUdRKhqE=; b=Qp59LMxYXjpSC6XTYUwV1qyTfqWhH7Pn+7BdZ6wEiOdglnikr1S3hBDsgSLCWfOkCL wMtKHvYbJBZubxxlTj12R6qLPAN3vTYXeOcwHzpgfP8POqWaMYFI3un9ExDcNZXzOFdW wHgDCKAw90HiPqc6ycHNjlB4FMJOIPouXycsyKcrNPxIPacTMwqFtzcxwMinIJ+LZZZt JBL/gAgoapcYLbDplua9NNoKJLW7ABhAVaR68FxKoan4lPi5jyxFsIaAmXw+/4cjs8Lb 7hOnPUNPh9vpOWmkzS+1Rdr13L2ggq0c4eHoQpkOjYGwRKx1tAqPW2A9/pMUOsLLnTwO Pr6w== X-Gm-Message-State: AOAM532xHZxqvI8LcRHsTY7kdX4eHw607l8FRldeN6WW3u9KWg4aolcX pFUEQmV0w3OwrrZq1SYNSkU= X-Google-Smtp-Source: ABdhPJwzKaKvNJHEQ9IyYhEt4dQ3EvLLXvUAscQJQxiSIYHiAQMssMIh3EDSb2IIdm7moUjOASs4pA== X-Received: by 2002:a1c:b656:: with SMTP id g83mr23163858wmf.151.1591021785290; Mon, 01 Jun 2020 07:29:45 -0700 (PDT) Received: from localhost.localdomain (43.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.43]) by smtp.gmail.com with ESMTPSA id u12sm6824954wrq.90.2020.06.01.07.29.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 07:29:44 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH v2 8/8] target/i386/cpu: Use the IEC binary prefix definitions Date: Mon, 1 Jun 2020 16:29:30 +0200 Message-Id: <20200601142930.29408-9-f4bug@amsat.org> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200601142930.29408-1-f4bug@amsat.org> References: <20200601142930.29408-1-f4bug@amsat.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?q?Herv=C3=A9=20Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" IEC binary prefixes ease code review: the unit is explicit. Reviewed-by: Peter Maydell Signed-off-by: Philippe Mathieu-Daudé --- target/i386/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 3733d9a279..33ce4861fb 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -6159,7 +6159,7 @@ static void x86_cpu_machine_done(Notifier *n, void *unused) if (smram) { cpu->smram = g_new(MemoryRegion, 1); memory_region_init_alias(cpu->smram, OBJECT(cpu), "smram", - smram, 0, 1ull << 32); + smram, 0, 4 * GiB); memory_region_set_enabled(cpu->smram, true); memory_region_add_subregion_overlap(cpu->cpu_as_root, 0, cpu->smram, 1); } -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:33:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:33:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflUv-0006rm-71; Mon, 01 Jun 2020 14:33:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflUt-0006rc-Qg for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:33:03 +0000 X-Inumbo-ID: cc9fc5ba-a414-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cc9fc5ba-a414-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 14:33:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=s7Qt+u2HoXy5w2EV7PCVq4ApdLlYH/pIHTdRabPTeQs=; b=sGLykQJ+UNyZEU62TBPltsaVL f2tUtA2U4y3vzECO0wO0KTQ+CEvGWIHCE9aMlrExPnwCmfmKsE2RnSJ6nq6xECV6yhnL2/8yO28Bx W30IG4aTic1pXc5yUmAvd4EYIlUOhJcc/DTB9NMoafSDzX1PP2sDrK3aya2kNIaXmz4tE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jflUs-0003bm-KR; Mon, 01 Jun 2020 14:33:02 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jflUs-0000pF-BI; Mon, 01 Jun 2020 14:33:02 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jflUs-00022w-Ah; Mon, 01 Jun 2020 14:33:02 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150596: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ad33a573c009d72466432b41ba0591c64e819c19 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Mon, 01 Jun 2020 14:33:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150596 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150596/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen ad33a573c009d72466432b41ba0591c64e819c19 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 4 days Failing since 150465 2020-05-29 09:02:14 Z 3 days 29 attempts Testing same since 150515 2020-05-30 01:00:47 Z 2 days 19 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1196 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 14:58:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 14:58:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfltR-0000S6-Ci; Mon, 01 Jun 2020 14:58:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfltP-0000RN-NW for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 14:58:23 +0000 X-Inumbo-ID: 560f8602-a418-11ea-9947-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 560f8602-a418-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 14:58:22 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 3aa6tkOX8BFo1ojd5/NrdAWpp3pC7JcKZ3SmeR3zZnAv5DKz+B0DAVG6vj7BVrs9BYvyVo7Cxv kO5kXiqYsGF2rxoCE6QO1VauM50C2fm8CicaRLYEfnqHjXveI4IhVkV/31BbCXErOMUYma0dIO /bEfOmLov3BPZFrLfQwmGloVFUyjerfoC1s1eJ7+2ULXl6P+fq7sOvb7NrCMj6HtfTfHOkcXhZ NqXdPG2ZyP8ScGcPVFm1jfJ0bzccrtEuU4AOoMWXn0tHxKN43Ozvk1VIeL28fJlO7aYAU4WBLV DFo= X-SBRS: 2.7 X-MesageID: 19671656 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,461,1583211600"; d="scan'208";a="19671656" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14] x86/ucode: Fix errors with start/end_update() Date: Mon, 1 Jun 2020 15:57:55 +0100 Message-ID: <20200601145755.3661-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Paul Durrant , Wei Liu , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" c/s 9267a439c "x86/ucode: Document the behaviour of the microcode_ops hooks" identified several poor behaviours of the start_update()/end_update_percpu() hooks. AMD have subsequently confirmed that OSVW don't, and are not expected to, change across a microcode load, rendering all of this complexity unecessary. Instead of fixing up the logic to not leave the OSVW state reset in a number of corner cases, delete the logic entirely. This in turn allows for the removal of the poorly-named 'start_update' parameter to microcode_update_one(). Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant This wants backporting to 4.13, hence considering for 4.14 at this point. --- xen/arch/x86/acpi/power.c | 2 +- xen/arch/x86/cpu/microcode/amd.c | 17 ----------------- xen/arch/x86/cpu/microcode/core.c | 33 +++------------------------------ xen/arch/x86/cpu/microcode/private.h | 14 -------------- xen/arch/x86/smpboot.c | 2 +- xen/include/asm-x86/microcode.h | 2 +- 6 files changed, 6 insertions(+), 64 deletions(-) diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c index 0cda362045..dfffe08e18 100644 --- a/xen/arch/x86/acpi/power.c +++ b/xen/arch/x86/acpi/power.c @@ -287,7 +287,7 @@ static int enter_state(u32 state) console_end_sync(); watchdog_enable(); - microcode_update_one(true); + microcode_update_one(); if ( !recheck_cpu_features(0) ) panic("Missing previously available feature(s)\n"); diff --git a/xen/arch/x86/cpu/microcode/amd.c b/xen/arch/x86/cpu/microcode/amd.c index 3f0969e70d..11e24637e7 100644 --- a/xen/arch/x86/cpu/microcode/amd.c +++ b/xen/arch/x86/cpu/microcode/amd.c @@ -395,26 +395,9 @@ static struct microcode_patch *cpu_request_microcode(const void *buf, size_t siz return patch; } -#ifdef CONFIG_HVM -static int start_update(void) -{ - /* - * svm_host_osvw_init() will be called on each cpu by calling '.end_update' - * in common code. - */ - svm_host_osvw_reset(); - - return 0; -} -#endif - const struct microcode_ops amd_ucode_ops = { .cpu_request_microcode = cpu_request_microcode, .collect_cpu_info = collect_cpu_info, .apply_microcode = apply_microcode, -#ifdef CONFIG_HVM - .start_update = start_update, - .end_update_percpu = svm_host_osvw_init, -#endif .compare_patch = compare_patch, }; diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index d879d28787..18ebc07b13 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -546,9 +546,6 @@ static int do_microcode_update(void *patch) else ret = secondary_thread_fn(); - if ( microcode_ops->end_update_percpu ) - microcode_ops->end_update_percpu(); - return ret; } @@ -620,16 +617,6 @@ static long microcode_update_helper(void *data) } spin_unlock(µcode_mutex); - if ( microcode_ops->start_update ) - { - ret = microcode_ops->start_update(); - if ( ret ) - { - microcode_free_patch(patch); - goto put; - } - } - cpumask_clear(&cpu_callin_map); atomic_set(&cpu_out, 0); atomic_set(&cpu_updated, 0); @@ -728,28 +715,14 @@ static int __init microcode_init(void) __initcall(microcode_init); /* Load a cached update to current cpu */ -int microcode_update_one(bool start_update) +int microcode_update_one(void) { - int err; - if ( !microcode_ops ) return -EOPNOTSUPP; microcode_ops->collect_cpu_info(); - if ( start_update && microcode_ops->start_update ) - { - err = microcode_ops->start_update(); - if ( err ) - return err; - } - - err = microcode_update_cpu(NULL); - - if ( microcode_ops->end_update_percpu ) - microcode_ops->end_update_percpu(); - - return err; + return microcode_update_cpu(NULL); } /* BSP calls this function to parse ucode blob and then apply an update. */ @@ -790,7 +763,7 @@ static int __init early_microcode_update_cpu(void) spin_unlock(µcode_mutex); ASSERT(rc); - return microcode_update_one(true); + return microcode_update_one(); } int __init early_microcode_init(void) diff --git a/xen/arch/x86/cpu/microcode/private.h b/xen/arch/x86/cpu/microcode/private.h index dc5c7a81ae..c00ba590d1 100644 --- a/xen/arch/x86/cpu/microcode/private.h +++ b/xen/arch/x86/cpu/microcode/private.h @@ -46,20 +46,6 @@ struct microcode_ops { int (*apply_microcode)(const struct microcode_patch *patch); /* - * Optional. If provided and applicable to the specific update attempt, - * is run once by the initiating CPU. Returning an error will abort the - * load attempt. - */ - int (*start_update)(void); - - /* - * Optional. If provided, called on every CPU which completes a microcode - * load. May be called in the case of some errors, and not others. May - * be called even if start_update() wasn't. - */ - void (*end_update_percpu)(void); - - /* * Given two patches, are they both applicable to the current CPU, and is * new a higher revision than old? */ diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c index 13b3dade9c..f878a00760 100644 --- a/xen/arch/x86/smpboot.c +++ b/xen/arch/x86/smpboot.c @@ -369,7 +369,7 @@ void start_secondary(void *unused) initialize_cpu_data(cpu); - microcode_update_one(false); + microcode_update_one(); /* * If MSR_SPEC_CTRL is available, apply Xen's default setting and discard diff --git a/xen/include/asm-x86/microcode.h b/xen/include/asm-x86/microcode.h index 9da63f992e..3b0234e9fa 100644 --- a/xen/include/asm-x86/microcode.h +++ b/xen/include/asm-x86/microcode.h @@ -22,6 +22,6 @@ DECLARE_PER_CPU(struct cpu_signature, cpu_sig); void microcode_set_module(unsigned int idx); int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long len); int early_microcode_init(void); -int microcode_update_one(bool start_update); +int microcode_update_one(void); #endif /* ASM_X86__MICROCODE_H */ -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 15:08:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 15:08:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfm2f-0001PL-Du; Mon, 01 Jun 2020 15:07:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfm2e-0001PG-OA for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 15:07:56 +0000 X-Inumbo-ID: abe263fa-a419-11ea-81bc-bc764e2007e4 Received: from mail-ed1-x543.google.com (unknown [2a00:1450:4864:20::543]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id abe263fa-a419-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 15:07:55 +0000 (UTC) Received: by mail-ed1-x543.google.com with SMTP id k19so7506573edv.9 for ; Mon, 01 Jun 2020 08:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=r6FP2YosZWHFalCC+WBNkBLcjUgXO6VrNF/Y8BUD2FA=; b=KDbv2USn9gc6uxUznYqOp+eSQH7sAjYKnB1K2XF7xD1FGmIQZSSKv7M6ZLx2ZP5Hdd OJsBwAPD9iQVPJXfZtsSJ4omByHaT2e+cFiXxqAWk0FM+JnV6HJwoMTtTCqRwDaj/cYk ZoFMNnnnXoao99og8NpM1J0EknIpPOP/cRwywSfGSWN62lyhooHxYQFc36bR8bIENXqW 68AQ5tUeMX/s+QxiVawNlChEeJtC3n2Icx650qDUZibe1D6Z8JwTP3pO1SFXq3kcwnx2 /T82Brb9ZrkmYindIhuL7beBNBVH9edpQwDsWKjKlQZN4gUk7gM3BwnPSBUI9JKERR1f 6IwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=r6FP2YosZWHFalCC+WBNkBLcjUgXO6VrNF/Y8BUD2FA=; b=owigeTQcUtpD6fKG5hf9OKrWoWGG1LSYecyekvFFKG1KE+ky8WTXXbLmbGcTThxaIv vXHZQ5vx+5yJUTJY8iJU8bcC0Dum2A5ZKb+3IsdmfYkJFYRn8kzEYhTIZyhG0FAigsMS o1gfd2/DE0pIK5F8Xlb+yInAyVOCX2TkwaAmOTIVllvj/FT6urmwRsrJZCusPilJQv0p kjV/guJcfOfLXi/d+RO97PQ2YydLp3HnmOn86kXjYjGiz5Uez4s5UTdsz/qZUqTq0m9X SmAn4SlpDgnf1aDvEaHRlTjlGaEW03YcVzTCx1cipHWISlbpDy5ulql4DvJ2Dx0m2tTp 1K7Q== X-Gm-Message-State: AOAM530xfSu/ERLYWLTw6krXOsb9/hkg5CuhE18r2Qrjj+0MFLtLDczC 9SG+i26k8/r7qgpcKv+p3Ks= X-Google-Smtp-Source: ABdhPJySZHC+AaRIn80jw0F4XxN0lDGW7KyvsRgdqZT7PfcV87HgndLrXXemLMMglliswlUnBLO08w== X-Received: by 2002:a50:d490:: with SMTP id s16mr21405293edi.242.1591024074966; Mon, 01 Jun 2020 08:07:54 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id w21sm14248499ejc.11.2020.06.01.08.07.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 08:07:54 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Tamas K Lengyel'" , References: In-Reply-To: Subject: RE: [PATCH v19 for-4.14 00/13] VM forking Date: Mon, 1 Jun 2020 16:07:52 +0100 Message-ID: <000c01d63826$6d125900$47370b00$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLopxTEy5NbImEQwB/v9n5io2F1+qae/fDA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Kevin Tian' , 'Stefano Stabellini' , 'Julien Grall' , 'Jan Beulich' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Tamas K Lengyel' , 'Jun Nakajima' , 'Anthony PERARD' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = Tamas K Lengyel > Sent: 01 June 2020 14:22 > To: xen-devel@lists.xenproject.org > Cc: Kevin Tian ; Stefano Stabellini = ; Tamas K Lengyel > ; Jun Nakajima ; Wei = Liu ; Andrew Cooper > ; Ian Jackson ; = George Dunlap > ; Tamas K Lengyel ; Jan = Beulich ; > Anthony PERARD ; Julien Grall = ; Roger Pau Monn=C3=A9 > > Subject: [PATCH v19 for-4.14 00/13] VM forking Hi, This series looks to be largely un-acked so, since we are now past the = freeze date, I don't really think it can go into 4.14. Is there a = particular reason that you think it should be considered? Paul >=20 > The following patches are part of the series that implement VM forking = for > Intel HVM guests to allow for the fast creation of identical VMs = without the > assosciated high startup costs of booting or restoring the VM from a = savefile. >=20 > JIRA issue: https://xenproject.atlassian.net/browse/XEN-89 >=20 > The fork operation is implemented as part of the "xl fork-vm" command: > xl fork-vm -C -Q >=20 > By default a fully functional fork is created. The user is in charge = however to > create the appropriate config file for the fork and to generate the = QEMU save > file before the fork-vm call is made. The config file needs to give = the > fork a new name at minimum but other settings may also require = changes. Certain > settings in the config file of both the parent and the fork have to be = set to > default. Details are documented. >=20 > The interface also allows to split the forking into two steps: > xl fork-vm --launch-dm no \ > -m \ > -p > xl fork-vm --launch-dm late \ > -C \ > -Q \ > >=20 > The split creation model is useful when the VM needs to be created as = fast as > possible. The forked VM can be unpaused without the device model being = launched > to be monitored and accessed via VMI. Note however that without its = device > model running (depending on what is executing in the VM) it is bound = to > misbehave or even crash when its trying to access devices that would = be > emulated by QEMU. We anticipate that for certain use-cases this would = be an > acceptable situation, in case for example when fuzzing is performed of = code > segments that don't access such devices. >=20 > Launching the device model requires the QEMU Xen savefile to be = generated > manually from the parent VM. This can be accomplished simply by = connecting to > its QMP socket and issuing the "xen-save-devices-state" command. For = example > using the standard tool socat these commands can be used to generate = the file: > socat - UNIX-CONNECT:/var/run/xen/qmp-libxl- > { "execute": "qmp_capabilities" } > { "execute": "xen-save-devices-state", \ > "arguments": { "filename": "/path/to/save/qemu_state", \ > "live": false} } >=20 > The series has been tested with Windows VMs and functions as expected. = Linux > VMs when forked from a running VM will have a frozen VNC screen. Linux = VMs at > this time can only be forked with a working device model when the = parent VM was > restored from a snapshot using "xl restore -p". This is a known = limitation due > to Linux VMs having to be made aware of being saved/migrated. >=20 > New in v19: > Including all the patches currently outstanding into the series > Breaking up libxl/xl patch to many sub-patches to make it easier to = review > libxl/xl is now reduced to the bare essential to launch QEMU for a VM = fork >=20 > Tamas K Lengyel (13): > x86/mem_sharing: block interrupt injection for forks > tools/libxc: xc_memshr_fork with interrupts blocked > tools/libxl: Split libxl__domain_make > tools/libxl: populate xenstore entries when launching dm for VM fork > tools/libxl: Add checks for dm_restore_file > tools/libxl: adjust domcreate_bootloader_done > tools/libxl: Adjust libxl__build_pre > tools/libxl: Adjust libxl__build_post > tools/libxl: libxl__build_hvm_fork > tools/libxl: set QEMU saved_state from dm_restore_file > tools/libxl: Add VM forking public functions > tools/xl: Add xl fork-vm command > tools/xl: document fork-vm command >=20 > docs/man/xl.1.pod.in | 39 +++++++++ > tools/libxc/include/xenctrl.h | 3 +- > tools/libxc/xc_memshr.c | 4 +- > tools/libxl/libxl.h | 10 +++ > tools/libxl/libxl_create.c | 134 = +++++++++++++++++++++++++------ > tools/libxl/libxl_dm.c | 2 +- > tools/libxl/libxl_dom.c | 59 +++++++++++--- > tools/libxl/libxl_internal.h | 5 +- > tools/libxl/libxl_types.idl | 1 + > tools/xl/Makefile | 2 +- > tools/xl/xl.h | 4 + > tools/xl/xl_cmdtable.c | 13 +++ > tools/xl/xl_forkvm.c | 122 ++++++++++++++++++++++++++++ > tools/xl/xl_vmcontrol.c | 13 +++ > xen/arch/x86/hvm/vmx/intr.c | 6 ++ > xen/arch/x86/mm/mem_sharing.c | 6 +- > xen/include/asm-x86/hvm/domain.h | 2 +- > xen/include/public/memory.h | 3 + > 18 files changed, 383 insertions(+), 45 deletions(-) > create mode 100644 tools/xl/xl_forkvm.c >=20 > -- > 2.25.1 >=20 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 15:19:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 15:19:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmDY-0002NP-Mh; Mon, 01 Jun 2020 15:19:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmDW-0002NG-Sf for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 15:19:10 +0000 X-Inumbo-ID: 3daa2f6a-a41b-11ea-9dbe-bc764e2007e4 Received: from mail-ej1-x62d.google.com (unknown [2a00:1450:4864:20::62d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3daa2f6a-a41b-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 15:19:09 +0000 (UTC) Received: by mail-ej1-x62d.google.com with SMTP id n24so9579632ejd.0 for ; Mon, 01 Jun 2020 08:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=I3z+TGgCjqU+RgML/yFoOLMrSRU4S4kmaHi0OCyG2cU=; b=VLh1DfNTwHBdXvPmzJ0CSDEDIam+ai2OrNBLUvwWzTZ/ctWa8LdzbFixMftzps+wLQ F9s0fuMMqo/C7m8Po2abhjaQbTPFPYiVT1sXwOBngUHR3o9eGXLshEu7bJLtPocZqqrB SRy7JCKDmvZGh9d0NgKQijk/dHqLYMCrp1u6gPuogYN6Skm2lp0su2wjSZnOghV0SCv3 9MEJXsb3/YVCNNpG3dqIApctQjpKpXXEBZEiHV/gUTJ71r9s4zjQr8znd0VHTq07C9IB AJOOKxcxswcCeqVe/G9f7+yxpJO+XWfeTL8MCTeHGrglRc5BrVExlqM47HaXdTy2e+7u tl/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=I3z+TGgCjqU+RgML/yFoOLMrSRU4S4kmaHi0OCyG2cU=; b=U+t/bqMacH+EhL8ZgvmiSilgYLpljJDlvs4dVLDx6Jv7w9dHhRxL+c062/BnZT3eIE kVRJaQnDWZardvhHQL1YBvq7Qu7TdyHPGv2laeBTnzrRg7Y5iQGU45CM8YZGj9Q/YIjT 1B2U9ufDn4ih9YTcVbvCyb8wNvKTOIQP+mInpyHK7484ChhGwkDsJh+4c77jOaaeyp63 MVs6klhi+Q+qDLbf7HGperrM0fgrFv+/0O8BrfizM4mLXVW2/olUf3u0klpmaGsh033B /s3huW4aRp8ykXMfIJ3GM2JOO8OdPtaQSCKpLwB6sok47k4MrpDsBVjlh+Fy+EK9yhR1 JNQw== X-Gm-Message-State: AOAM5334Hwq/3h9i+AAI8diJvMVTZgqCOCgewHOOVvrevWv4Ow1/P9J1 o04fNE05WdA05fu491WE+z8= X-Google-Smtp-Source: ABdhPJwC463SFXhYeSRAiZDGbIujQCLoXRCd7HXbntfWsAHNxXdaEd++Fcd5SG0syzZxOzwcUVIGTA== X-Received: by 2002:a17:906:8d0:: with SMTP id o16mr20514557eje.196.1591024749047; Mon, 01 Jun 2020 08:19:09 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id q12sm8994614ejn.23.2020.06.01.08.19.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 08:19:08 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200601134025.24142-1-andrew.cooper3@citrix.com> In-Reply-To: <20200601134025.24142-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH for-4.14] docs/ucode: Extend runtime microcode loading documentation Date: Mon, 1 Jun 2020 16:19:07 +0100 Message-ID: <000e01d63827$fede4d70$fc9ae850$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGxKdezJRRpkuANC4vfHjenNW9S2akN+uKw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Konrad Rzeszutek Wilk' , 'George Dunlap' , 'Jan Beulich' , 'Ian Jackson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 01 June 2020 14:40 > To: Xen-devel > Cc: Andrew Cooper ; George Dunlap ; Ian > Jackson ; Jan Beulich ; Konrad Rzeszutek Wilk > ; Stefano Stabellini ; Wei Liu ; Julien > Grall ; Paul Durrant > Subject: [PATCH for-4.14] docs/ucode: Extend runtime microcode loading documentation > > Extend the disclaimer about runtime loading. While we've done our best to > make the mechaism reliable, the safety of late loading does ultimately depend > on the contents of the blobs. > > Extend the xen-ucode portion with examples of how to use it. > > Signed-off-by: Andrew Cooper > --- > CC: George Dunlap > CC: Ian Jackson > CC: Jan Beulich > CC: Konrad Rzeszutek Wilk > CC: Stefano Stabellini > CC: Wei Liu > CC: Julien Grall > CC: Paul Durrant > --- > docs/admin-guide/microcode-loading.rst | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst > index 5f0f661a2e..8cd5d0351b 100644 > --- a/docs/admin-guide/microcode-loading.rst > +++ b/docs/admin-guide/microcode-loading.rst > @@ -104,8 +104,8 @@ modules to find any CPIO archives, and search the archive for the applicable > file. Xen will stop searching at the first match. > > > -Run time microcode loading > --------------------------- > +Runtime microcode loading > +------------------------- > > .. warning:: > > @@ -113,7 +113,23 @@ Run time microcode loading > or at boot time. Not all microcode updates (or parts thereof) can be > applied at runtime. > > -The ``xen-ucode`` utility can be used to initiate a runtime microcode load. > + Given the proprietry nature of microcode, we are unable to make any claim s/proprietry/proprietary with that fixed this is... Release-acked-by: Paul Durrant > + that a runtime microcode is risk-free. Any runtime microcode loading needs > + adequate testing on a dev instance before being rolled out to production > + systems. > + > +The ``xen-ucode`` utility can be used to initiate a runtime microcode load:: > + > + [root@host ~]# xen-ucode > + xen-ucode: Xen microcode updating tool > + Usage: xen-ucode > + [root@host ~]# > + > +e.g. With a Linux dom0 on a Haswell system:: > + > + [root@host ~]# xen-ucode /lib/firmware/intel-ucode/06-3c-03 > + [root@host ~]# > + > It will pass the blob to Xen, which will check to see whether the blob is > correct for the processor, and newer than the running microcode. > > -- > 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 15:21:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 15:21:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmFp-0003BL-3a; Mon, 01 Jun 2020 15:21:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmFn-0003BG-H5 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 15:21:31 +0000 X-Inumbo-ID: 919f3c1e-a41b-11ea-9947-bc764e2007e4 Received: from mail-wm1-x32c.google.com (unknown [2a00:1450:4864:20::32c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 919f3c1e-a41b-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 15:21:30 +0000 (UTC) Received: by mail-wm1-x32c.google.com with SMTP id f185so11778501wmf.3 for ; Mon, 01 Jun 2020 08:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eEI0Z2ltjlEuzeKpCquZANxjoiXQ28qny9Vq/1zpwek=; b=luxm+kMHLNzW4UMsm7xZZ8Za1hmjW7ITKHzoFQTBrVVfuu7cCT+J4XzW7JrTMX6bZf aPsV52VI21L30Fyw7iOgdA8AXuoJqcbxGXspbXuSL1DozbDPFh5abGWERH0TLWfbYUlI mgFjcjXohXEyMOhPqTGh06w/KOhCFpF2OeHlgdjby8lExOC6uMZ0hK2dV/PRCSx1hylO n3XFFOke/ie1PJ3AfFD6596EjeNGn0T+SM8950lRIfHL6KjCCrvNC7Nhn7T8Odd12Kvy VwnpiE04D34QpNIPg8KzGN2cCEzBUbm7XlXaCj0tzohnuy8BBRHxASqo3KGLv26UfJZV vLqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eEI0Z2ltjlEuzeKpCquZANxjoiXQ28qny9Vq/1zpwek=; b=ZGZsCfIvdoq1geUdL67KC+XiDJuD5Bj7BqhwST1aAmN6t9GWrl+GShIjcZklULTxZf jrfdpyV0FGHR24N68DYTOiL2EEkl7mNHyDy3pnn8QVoXvh8k76BeXJDfTWD5/4hnkf8s sU2EQRgyb1OGCOxyzrwkiWzb07keuOSuaHcHXTW97DG46Q6/dgIreRyK9D9daVMIXO5O 0/bcUu66q9Y6ASJtP8GWOyv029SzPbGnLvLqz5fQwgpLt1Wh8K2S9sZf9AVz6dUuAPRq Wz4H8pp1quRFapaX5wsVxXEAz/+mdR2azGtb+PsDiLICPz6td1cZjYGvEaMpxR4IsXxd 8tlw== X-Gm-Message-State: AOAM532WhRqfVFYYo28xGhRHoWVZ9Kf1IZd8lTc7wZOO+Yg+THWNp4Xc OWPgMsqUzKnAm4xJxN+d2+dBXw1AyFfg6f5xxe40258ZNOM= X-Google-Smtp-Source: ABdhPJwqzcjBqvzUWw7ejJF1jpZfyVz9jSGQ0FArAOImK0f4qo90k/K6HVpxrG/Vp+UYxwy6Ntdy7ikDiWY6omHky3Q= X-Received: by 2002:a1c:e903:: with SMTP id q3mr21054474wmc.76.1591024889923; Mon, 01 Jun 2020 08:21:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: CodeWiz2280 Date: Mon, 1 Jun 2020 11:21:17 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: multipart/alternative; boundary="000000000000648c2a05a707595a" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --000000000000648c2a05a707595a Content-Type: text/plain; charset="UTF-8" Hi Julien, Thank you for your response. I will try and post a log for you. I have been switching back and forth between configurations and need to take a new one. The board has 4GB of memory. Uboot places the kernel/initramfs/dtb in the 0x8000_0000 region but then the kernel switches its code/data over to a 0x8_0000_0000 range via the pv-fixup-asm.S assembly code called from early_paging_init in arch/arm/mm/mmu.c. That code is exclusive to the keystone in the 4.19 kernel when "CONFIG_ARM_PV_FIXUP" and "ARM_LPAE" are enabled in the kernel . The upper 2GB of memory is above 0xFFFF_FFFF so LPAE is required. /proc/iomem looks like this without running xen after the switch and the kernel boots: 80000000 - 9fffffff : System RAM (boot alias) c8000000 - ffffffff : System RAM (boot alias) 800000000 - 1fffffff : System RAM 800008000-800dfffff : Kernel Code 801000000-80108ab3f : Kernel data 848000000-8ffffffff : System RAM I was able to duplicate this issue with a build of your latest "master" repository from this morning. On Mon, Jun 1, 2020 at 9:29 AM Julien Grall wrote: > Hello, > > I have a few questions in order to understand a bit more your problem. > > On 01/06/2020 13:38, CodeWiz2280 wrote: > > Hello, I am using a Texas Instruments K2E Keystone Eval board with Linux > > 4.19.59. It has a 32-bit ARM Cortex A15 processor. There is keystone > > specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that executes > > during early_paging_init for LPAE support. This causes the kernel to > > switch its running 32-bit address space to a 36-bit address space and > > the hypervisor traps repeatedly and stops it from booting. > > Without any log it is going to be difficult to help. Could you post the > hypervisor log when debug is enabled? > > > I suspect > > this is because Xen only allowed for the original 32-bit memory range > > specified by the dom0 device tree. > > How much RAM did you give to your Dom0? > > > The 36-bit LPAE address is a fixed > > offset from the 32-bit address and is not physically different memory. > > I am not sure to understand this. Are you suggesting that the kernel is > trying to relocate itself in a different part of the physical memory? > > Can you provide more details on the fixed offset? > > > > > Can you suggest any way to get through this problem? I am using the > > master branch of xen from earlier this year. > > Can you provide the exact baseline your are using? Did make any changes > on top? > > > Any help is greatly > > appreciated. > Best regards, > > -- > Julien Grall > --000000000000648c2a05a707595a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Julien,

Thank you for you= r response.=C2=A0 I will try and post a log for you.=C2=A0 I have been swit= ching back and forth between configurations and need to take a new one.

The board has 4GB of memory. Uboot places the kernel/= initramfs/dtb in the 0x8000_0000 region but then the kernel switches its co= de/data over to a 0x8_0000_0000 range via the pv-fixup-asm.S assembly code = called from early_paging_init in arch/arm/mm/mmu.c.=C2=A0 That code is excl= usive to the keystone in the 4.19 kernel when "CONFIG_ARM_PV_FIXUP&quo= t; and "ARM_LPAE" are enabled in the kernel .=C2=A0 The upper 2GB= of memory is above 0xFFFF_FFFF so LPAE is required.=C2=A0

/proc/iomem looks like this without running xen after the switch a= nd the kernel boots:

80000000 - 9fffffff : System = RAM (boot alias)
c8000000 - ffffffff : System RAM (boot alias)
800000000 - 1fffffff : System RAM
=C2=A0 =C2=A0 800008000= -800dfffff : Kernel Code
=C2=A0 =C2=A0 801000000-80108ab3f : Kern= el data
848000000-8ffffffff : System RAM

I was able to duplicate this issue with a build of your latest "maste= r" repository from this morning.

On Mon, Jun 1, 2020 at 9:29 AM J= ulien Grall <julien@xen.org> wr= ote:
Hello,

I have a few questions in order to understand a bit more your problem.

On 01/06/2020 13:38, CodeWiz2280 wrote:
> Hello, I am using a Texas Instruments K2E Keystone Eval board with Lin= ux
> 4.19.59.=C2=A0 It has a 32-bit ARM Cortex A15 processor. There is keys= tone
> specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that execute= s
> during early_paging_init for LPAE support.=C2=A0 This causes the kerne= l to
> switch its running 32-bit address space to a 36-bit address space and =
> the hypervisor traps repeatedly and stops it from booting.

Without any log it is going to be difficult to help. Could you post the hypervisor log when debug is enabled?

>=C2=A0 I suspect
> this is because Xen only allowed for the original 32-bit memory range =
> specified by the dom0 device tree.

How much RAM did you give to your Dom0?

> The 36-bit LPAE address is a fixed
> offset from the 32-bit address and is not physically different memory.=

I am not sure to understand this. Are you suggesting that the kernel is trying to relocate itself in a different part of the physical memory?

Can you provide more details on the fixed offset?

>=C2=A0
> Can you suggest any way to get through this problem? I am using the > master branch of xen from earlier this year.=C2=A0

Can you provide the exact baseline your are using? Did make any changes on top?

> Any help is greatly
> appreciated.
Best regards,

--
Julien Grall
--000000000000648c2a05a707595a-- From xen-devel-bounces@lists.xenproject.org Mon Jun 01 15:24:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 15:24:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmIG-0003Jn-HT; Mon, 01 Jun 2020 15:24:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmIF-0003Ji-W9 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 15:24:04 +0000 X-Inumbo-ID: ecaa9f36-a41b-11ea-9947-bc764e2007e4 Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ecaa9f36-a41b-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 15:24:03 +0000 (UTC) Received: by mail-ed1-x541.google.com with SMTP id g9so7542405edw.10 for ; Mon, 01 Jun 2020 08:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=KDyQ7eRFU+F2sXgfo58fLtKCGQlDoXeTCkcWOQx5ueM=; b=GmAqLKuYuEH+JTPDlliNo1Ju/OiRMqY/HPxvIIxX26xDOZl2iDzCf31rbumRV/xWQU i4cqFzO8TKJH10+E5nCAXKQ4i5jrIjo05/9UNfHhkbAX7rcAAdrOwnfFUc3wTExRVnTg FqrnjRoyikwEYtaqWUWCP4S1uKGd8ySYhi/g0D7VmeeYzefZ2KfS0Dt7/IGNbLsA1b8H b5+eiMF5LyzyocSkHLpGPLks6c6VEc6RGQYlxsMccFYWORHsf58N4/pkrrzvUimkS2MO 5L0T4+GjKpmmbiFZ03ccda5YOd6FawlTx/g+WTG9dv4c3og3IfSswn8M+/v+/x81/EUW n7OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=KDyQ7eRFU+F2sXgfo58fLtKCGQlDoXeTCkcWOQx5ueM=; b=dezSc/3TjF0DjEO3kzsbEkYFYZCDqWWzb2iuojpxREiX/1stVpuQvz0+PWEHLAprlP kKht6At0Aup4sL2OqrU+vpR9YAANIVrSMrBen+SUQsVtLGq8mRn4TvzjiTFOIX11WET3 oHl/pIorWT/892jdvLHq1y3ub01gQLD1EXgv+U/ECmdMGtSmP0DEJHGqjnCCiftFh1k2 xZDyRTyltlK2srWf2Ir2q03SG6ihJFx8Q/XzMtAbPjFcWRDTKvd+4X6YGxOVTuAqofuk GcPsKg0XihQLpvEgIJ8kckNfRS3qQr6I9WbTl9Tjj552+q39J1sfFLRmBrncYj+l9M+z xETg== X-Gm-Message-State: AOAM532yiGXY0eUVS0lMHzeROJq+CmNg0rao3apUeqd9pZPaZbCgCXpe gu0hXDboS9e7lrYxGFzbMpk= X-Google-Smtp-Source: ABdhPJxsN36QKbSB5RIKVHc9VgZ60gV24GKJHrFosR47xVSkRAPUqjMWvhFQ9iUD5qKByqGH3qJLYg== X-Received: by 2002:a50:e1c9:: with SMTP id m9mr21241697edl.196.1591025042724; Mon, 01 Jun 2020 08:24:02 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id i21sm10769058edr.68.2020.06.01.08.24.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 08:24:02 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200601135325.34156-1-roger.pau@citrix.com> In-Reply-To: <20200601135325.34156-1-roger.pau@citrix.com> Subject: RE: [PATCH v3 0/2] clang/llvm: build fixes Date: Mon, 1 Jun 2020 16:24:01 +0100 Message-ID: <001501d63828$add5de10$09819a30$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIVOh9pqoxe/+p3WNwiOV4e0Zxy86hF3LUQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 01 June 2020 14:53 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich ; Andrew > Cooper ; Wei Liu > Subject: [PATCH v3 0/2] clang/llvm: build fixes > > Hello, > > Two pending bug fixes for clang/llvm toolstacks. I'm assuming you intend this to be in 4.14. If so, Release-acked-by: Paul Durrant > > Roger Pau Monne (2): > x86/mm: do not attempt to convert _PAGE_GNTTAB to a boolean > build32: don't discard .shstrtab in linker script > > xen/arch/x86/boot/build32.lds | 14 ++++++++++++++ > xen/arch/x86/mm.c | 9 ++++++++- > 2 files changed, 22 insertions(+), 1 deletion(-) > > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 15:24:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 15:24:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmIv-0003Ni-R1; Mon, 01 Jun 2020 15:24:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmIu-0003NU-AX for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 15:24:44 +0000 X-Inumbo-ID: 0498edf0-a41c-11ea-8993-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0498edf0-a41c-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 15:24:43 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id o15so9539890ejm.12 for ; Mon, 01 Jun 2020 08:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=sxANU6nbFPCt0EhXkd5ZBvlOX0EDFxgYbGWL2UQmxw8=; b=aT3meGZ0q2O+/DvzNa1eI9jDNeDtfDBNnfp+nIxVOlgm3PenOJbYLI7lnI2kRdwtqT 2ozqN1dNVccR2WJJWJedL5075rx7h3jHQRj9PMCuXauiit5mWhoj/ANlWEOEUYsLa5um 3q4/399Wca9qZR3JnB1/RuLF56gFuzJfx5BSxpZdN4QqFlIYwhqHimJjYuKpjQnGfpGx 7qqRQ4b653H3zZcHr8GfNddHEKlaxu/i6fLVM1xLE1O5w3ptajY8S1E8PT/SCxMJLWRj LN6mvLaPxW2x3yIW7IML7S4HnFdVOzNJ8gGp1+/Tznw+ys1adjB4yMdRIaZ4kEMGceWh 0U8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=sxANU6nbFPCt0EhXkd5ZBvlOX0EDFxgYbGWL2UQmxw8=; b=ptICqP25wAF1iv/1OYq8Mq6LeRwbAJHr9LSmhx+cfK7tq7KM5IqASABf+ycDDOpuJ2 NdEeZOqF72pI9QVxQ5E1asYPDsz8nzRUEytCyIz3ahia9hhrSRwhNCphO4C6jAQL5fpt iWdIV0iX2s0xrtbOe8I6C4Cz6rt2FxH4GFKttvwqzlU0ziy7RBiBNpoprcxwkxpkW4sr 3mDvYEQovU1G7vxsQLvHxHSoqDYlOwveOrV2b7+pKsnxrUgxScoLvvcFORSs1hXozIFb M86qAS2rFEF5OM+IhIhpAsvPgM1+SDT/Wm+Esg9CyqIP/VPRvaSZ9/UpDyKIO18KNTz4 1feA== X-Gm-Message-State: AOAM530cYl+M4WCxuXNESXRb6TEmggrg2XEuWtqH1KnicwgYSwORYOut G02NeiGS02z6G7MlxnEsZEI= X-Google-Smtp-Source: ABdhPJz3eqjQudnsfEu5d5rwNc6qwUF/relN+aNRv0mT/kprvgtDTD/IPYh5uBXdHE8psgE0CfQOaA== X-Received: by 2002:a17:907:9484:: with SMTP id dm4mr21098613ejc.56.1591025082794; Mon, 01 Jun 2020 08:24:42 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id b21sm9163015ejz.28.2020.06.01.08.24.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 08:24:42 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'Philippe_Mathieu-Daud=C3=A9'?= , References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-8-f4bug@amsat.org> In-Reply-To: <20200601142930.29408-8-f4bug@amsat.org> Subject: RE: [PATCH v2 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions Date: Mon, 1 Jun 2020 16:24:40 +0100 Message-ID: <001601d63828$c5b132a0$511397e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQF4w9KWcHxvvYD3VioCudSt4ChIBAL7l7qKqWbtDxA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Peter Maydell' , 'Stefano Stabellini' , 'Eduardo Habkost' , "'Michael S. Tsirkin'" , 'Andrew Jeffery' , 'Helge Deller' , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?utf-8?Q?'Herv=C3=A9_Poussineau'?= , 'Joel Stanley' , 'Marcel Apfelbaum' , 'Paolo Bonzini' , 'Anthony Perard' , xen-devel@lists.xenproject.org, 'Richard Henderson' , qemu-ppc@nongnu.org, =?utf-8?Q?'C=C3=A9dric_Le_Goater'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Philippe Mathieu-Daud=C3=A9 = On Behalf Of Philippe Mathieu-Daud=C3=A9 > Sent: 01 June 2020 15:29 > To: qemu-devel@nongnu.org > Cc: xen-devel@lists.xenproject.org; Anthony Perard = ; Paolo Bonzini > ; Herv=C3=A9 Poussineau ; = Helge Deller ; qemu- > arm@nongnu.org; Marcel Apfelbaum ; Stefano = Stabellini > ; Michael S. Tsirkin ; Eduardo = Habkost ; > Paul Durrant ; Andrew Jeffery ; = qemu-trivial@nongnu.org; Peter Maydell > ; Joel Stanley ; C=C3=A9dric = Le Goater ; qemu- > ppc@nongnu.org; Richard Henderson ; Philippe = Mathieu-Daud=C3=A9 > Subject: [PATCH v2 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix = definitions >=20 > IEC binary prefixes ease code review: the unit is explicit. >=20 > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daud=C3=A9 Reviewed-by: Paul Durrant > --- > hw/i386/xen/xen-hvm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c > index 82ece6b9e7..94fe5d65e9 100644 > --- a/hw/i386/xen/xen-hvm.c > +++ b/hw/i386/xen/xen-hvm.c > @@ -9,6 +9,7 @@ > */ >=20 > #include "qemu/osdep.h" > +#include "qemu/units.h" >=20 > #include "cpu.h" > #include "hw/pci/pci.h" > @@ -230,7 +231,7 @@ static void xen_ram_init(PCMachineState *pcms, > * Xen does not allocate the memory continuously, it keeps a > * hole of the size computed above or passed in. > */ > - block_len =3D (1ULL << 32) + x86ms->above_4g_mem_size; > + block_len =3D (4 * GiB) + x86ms->above_4g_mem_size; > } > memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len, > &error_fatal); > -- > 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 15:38:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 15:38:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmVN-0004QG-Uk; Mon, 01 Jun 2020 15:37:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmVM-0004QB-I8 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 15:37:36 +0000 X-Inumbo-ID: d0880fbc-a41d-11ea-8993-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d0880fbc-a41d-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 15:37:35 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id y13so9630983eju.2 for ; Mon, 01 Jun 2020 08:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Jv6OLcuPiMadg4Gy5MXrfLGU1Fw3y+ypYx3GzGtHVNQ=; b=kJSAnnVRnctywj0SEBQdhKfpPDlyUXohjE8ty4wiPpM6c6ERAeHAwoDkzy4L9jK1uK QJl9rkBtKfCuA+o7gvsyrHzDgVgMuw7DxgG/QokrkZxmtmDrVMR6fcPp0hFvVkc8Qdex /kiiyi4al/vgQThjldAmpzx2ZFl4Ivol5ytOeq6UQ0frv9u9Usek6Q3DyoAkSnFsUxj+ 5G59AEZ59wtUO6Bk2/mqNen6G9STvSRFM/vxn0FvMX4j98nUKiftdVi8MooHDZgftOev FTlre0GpTtqGZZSKbyox0Ge6DbC2ZmyUpo3sSmC53vlG9dfN6xdJTjX7zSbtwSVp/Ibh feyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=Jv6OLcuPiMadg4Gy5MXrfLGU1Fw3y+ypYx3GzGtHVNQ=; b=dfxeZ0GKGEMwrAX3HE7ECc0Y+jaxvllD5QY950NIhdnMZmG8EQfqG3ZVze5c3me89q AhDlJk/pcOTLZ3FmprL7u/Ksq9vQmFwr0yNta3ebYefZ+Qx3cbnvbhjoAu8xUx22omLj /DNDitdgOPLCUD3DzoPmh2R8R0fA9+BZ/kDpqta1qYYBLXiAXkVdQNdmL6DRny1L+MoU fTPNw1pKbq8XjClertnF0RUSnMmVJbKNMJk0ln3mfKlQlvPjb7R77UBiQn36afqryY/V G4zoOhZzstUyy2BK3WbuvdhHcQ/oLXdItQQU033HcFYINRybQi2TzVOBu4/6QnNMhQuE xntg== X-Gm-Message-State: AOAM533amLV/DwupfXnd1Ni+BqotsEu0/lt46EQVlFL+e6gaiC0pFcxL pOT6sqK9WRhQo27toFeTbN/5UcbBMkE= X-Google-Smtp-Source: ABdhPJwItA1ZrD0csIEGa4tBgOSi3EAFJcENfk47bC4g0m0ceSjQghyh9qxWhM+FwJ5xqllBmCP/0A== X-Received: by 2002:a17:906:8387:: with SMTP id p7mr8985850ejx.323.1591025854414; Mon, 01 Jun 2020 08:37:34 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id b24sm7566342edw.70.2020.06.01.08.37.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jun 2020 08:37:33 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200601145755.3661-1-andrew.cooper3@citrix.com> In-Reply-To: <20200601145755.3661-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH for-4.14] x86/ucode: Fix errors with start/end_update() Date: Mon, 1 Jun 2020 16:37:32 +0100 Message-ID: <001701d6382a$91b94b70$b52be250$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIqvXK6hdkmpmdfDaUWiTnUn1sFw6ga2f/Q X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Wei Liu' , 'Jan Beulich' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 01 June 2020 15:58 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich = ; Wei Liu ; > Roger Pau Monn=C3=A9 ; Paul Durrant = > Subject: [PATCH for-4.14] x86/ucode: Fix errors with = start/end_update() >=20 > c/s 9267a439c "x86/ucode: Document the behaviour of the microcode_ops = hooks" > identified several poor behaviours of the = start_update()/end_update_percpu() > hooks. >=20 > AMD have subsequently confirmed that OSVW don't, and are not expected = to, > change across a microcode load, rendering all of this complexity = unecessary. >=20 > Instead of fixing up the logic to not leave the OSVW state reset in a = number > of corner cases, delete the logic entirely. This in turn allows for = the > removal of the poorly-named 'start_update' parameter to > microcode_update_one(). >=20 > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monn=C3=A9 > CC: Paul Durrant >=20 > This wants backporting to 4.13, hence considering for 4.14 at this = point. Release-acked-by: Paul Durrant > --- > xen/arch/x86/acpi/power.c | 2 +- > xen/arch/x86/cpu/microcode/amd.c | 17 ----------------- > xen/arch/x86/cpu/microcode/core.c | 33 = +++------------------------------ > xen/arch/x86/cpu/microcode/private.h | 14 -------------- > xen/arch/x86/smpboot.c | 2 +- > xen/include/asm-x86/microcode.h | 2 +- > 6 files changed, 6 insertions(+), 64 deletions(-) >=20 > diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c > index 0cda362045..dfffe08e18 100644 > --- a/xen/arch/x86/acpi/power.c > +++ b/xen/arch/x86/acpi/power.c > @@ -287,7 +287,7 @@ static int enter_state(u32 state) > console_end_sync(); > watchdog_enable(); >=20 > - microcode_update_one(true); > + microcode_update_one(); >=20 > if ( !recheck_cpu_features(0) ) > panic("Missing previously available feature(s)\n"); > diff --git a/xen/arch/x86/cpu/microcode/amd.c = b/xen/arch/x86/cpu/microcode/amd.c > index 3f0969e70d..11e24637e7 100644 > --- a/xen/arch/x86/cpu/microcode/amd.c > +++ b/xen/arch/x86/cpu/microcode/amd.c > @@ -395,26 +395,9 @@ static struct microcode_patch = *cpu_request_microcode(const void *buf, size_t siz > return patch; > } >=20 > -#ifdef CONFIG_HVM > -static int start_update(void) > -{ > - /* > - * svm_host_osvw_init() will be called on each cpu by calling = '.end_update' > - * in common code. > - */ > - svm_host_osvw_reset(); > - > - return 0; > -} > -#endif > - > const struct microcode_ops amd_ucode_ops =3D { > .cpu_request_microcode =3D cpu_request_microcode, > .collect_cpu_info =3D collect_cpu_info, > .apply_microcode =3D apply_microcode, > -#ifdef CONFIG_HVM > - .start_update =3D start_update, > - .end_update_percpu =3D svm_host_osvw_init, > -#endif > .compare_patch =3D compare_patch, > }; > diff --git a/xen/arch/x86/cpu/microcode/core.c = b/xen/arch/x86/cpu/microcode/core.c > index d879d28787..18ebc07b13 100644 > --- a/xen/arch/x86/cpu/microcode/core.c > +++ b/xen/arch/x86/cpu/microcode/core.c > @@ -546,9 +546,6 @@ static int do_microcode_update(void *patch) > else > ret =3D secondary_thread_fn(); >=20 > - if ( microcode_ops->end_update_percpu ) > - microcode_ops->end_update_percpu(); > - > return ret; > } >=20 > @@ -620,16 +617,6 @@ static long microcode_update_helper(void *data) > } > spin_unlock(µcode_mutex); >=20 > - if ( microcode_ops->start_update ) > - { > - ret =3D microcode_ops->start_update(); > - if ( ret ) > - { > - microcode_free_patch(patch); > - goto put; > - } > - } > - > cpumask_clear(&cpu_callin_map); > atomic_set(&cpu_out, 0); > atomic_set(&cpu_updated, 0); > @@ -728,28 +715,14 @@ static int __init microcode_init(void) > __initcall(microcode_init); >=20 > /* Load a cached update to current cpu */ > -int microcode_update_one(bool start_update) > +int microcode_update_one(void) > { > - int err; > - > if ( !microcode_ops ) > return -EOPNOTSUPP; >=20 > microcode_ops->collect_cpu_info(); >=20 > - if ( start_update && microcode_ops->start_update ) > - { > - err =3D microcode_ops->start_update(); > - if ( err ) > - return err; > - } > - > - err =3D microcode_update_cpu(NULL); > - > - if ( microcode_ops->end_update_percpu ) > - microcode_ops->end_update_percpu(); > - > - return err; > + return microcode_update_cpu(NULL); > } >=20 > /* BSP calls this function to parse ucode blob and then apply an = update. */ > @@ -790,7 +763,7 @@ static int __init early_microcode_update_cpu(void) > spin_unlock(µcode_mutex); > ASSERT(rc); >=20 > - return microcode_update_one(true); > + return microcode_update_one(); > } >=20 > int __init early_microcode_init(void) > diff --git a/xen/arch/x86/cpu/microcode/private.h = b/xen/arch/x86/cpu/microcode/private.h > index dc5c7a81ae..c00ba590d1 100644 > --- a/xen/arch/x86/cpu/microcode/private.h > +++ b/xen/arch/x86/cpu/microcode/private.h > @@ -46,20 +46,6 @@ struct microcode_ops { > int (*apply_microcode)(const struct microcode_patch *patch); >=20 > /* > - * Optional. If provided and applicable to the specific update = attempt, > - * is run once by the initiating CPU. Returning an error will = abort the > - * load attempt. > - */ > - int (*start_update)(void); > - > - /* > - * Optional. If provided, called on every CPU which completes a = microcode > - * load. May be called in the case of some errors, and not = others. May > - * be called even if start_update() wasn't. > - */ > - void (*end_update_percpu)(void); > - > - /* > * Given two patches, are they both applicable to the current = CPU, and is > * new a higher revision than old? > */ > diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c > index 13b3dade9c..f878a00760 100644 > --- a/xen/arch/x86/smpboot.c > +++ b/xen/arch/x86/smpboot.c > @@ -369,7 +369,7 @@ void start_secondary(void *unused) >=20 > initialize_cpu_data(cpu); >=20 > - microcode_update_one(false); > + microcode_update_one(); >=20 > /* > * If MSR_SPEC_CTRL is available, apply Xen's default setting and = discard > diff --git a/xen/include/asm-x86/microcode.h = b/xen/include/asm-x86/microcode.h > index 9da63f992e..3b0234e9fa 100644 > --- a/xen/include/asm-x86/microcode.h > +++ b/xen/include/asm-x86/microcode.h > @@ -22,6 +22,6 @@ DECLARE_PER_CPU(struct cpu_signature, cpu_sig); > void microcode_set_module(unsigned int idx); > int microcode_update(XEN_GUEST_HANDLE(const_void), unsigned long = len); > int early_microcode_init(void); > -int microcode_update_one(bool start_update); > +int microcode_update_one(void); >=20 > #endif /* ASM_X86__MICROCODE_H */ > -- > 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 01 15:48:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 15:48:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmg7-0005Nz-3J; Mon, 01 Jun 2020 15:48:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmg5-0005Nr-Lh for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 15:48:41 +0000 X-Inumbo-ID: 5d4a4d10-a41f-11ea-81bc-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5d4a4d10-a41f-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 15:48:40 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: qWPRz7rXOFHQ5gaus6W6RV8ThmlGiE8Hyrh1P5QTrKD5qAw3qreZTAdqRkWGnJcvlzn0PFDkt6 sZ7BLqXPlJEoV9I2+7C6VqJ/uDWS0NKXbDXMlXc2mK1GAK3A/z6jEPER/NzGUg/niezwUiMD/5 z+GpvtqE/SJKeQkMLE+KLDL8kcqydySSDG4Ky3hKLOfB3/r20vNjLi3cNKWiuQQflRorAVNDv+ ptjRkhFZI2w7aQa/JEdvyhqs8rkR7tNUM7Fc3hEVunYY5/Ahww94CX46KmAB39W5T53guA+4HO EnA= X-SBRS: 2.7 X-MesageID: 18931394 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,461,1583211600"; d="scan'208";a="18931394" Date: Mon, 1 Jun 2020 17:48:32 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Subject: Re: [PATCH for-4.14] x86/ucode: Fix errors with start/end_update() Message-ID: <20200601154832.GT1195@Air-de-Roger> References: <20200601145755.3661-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200601145755.3661-1-andrew.cooper3@citrix.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu , Jan Beulich , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 01, 2020 at 03:57:55PM +0100, Andrew Cooper wrote: > c/s 9267a439c "x86/ucode: Document the behaviour of the microcode_ops hooks" > identified several poor behaviours of the start_update()/end_update_percpu() > hooks. > > AMD have subsequently confirmed that OSVW don't, and are not expected to, > change across a microcode load, rendering all of this complexity unecessary. Is there a reference to some AMD PM or similar document that can be added here for completeness? > Instead of fixing up the logic to not leave the OSVW state reset in a number > of corner cases, delete the logic entirely. This in turn allows for the > removal of the poorly-named 'start_update' parameter to > microcode_update_one(). > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 01 15:50:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 15:50:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmhM-0005Sf-Dm; Mon, 01 Jun 2020 15:50:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmhK-0005SV-Oa for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 15:49:58 +0000 X-Inumbo-ID: 8b2d3990-a41f-11ea-ab2d-12813bfff9fa Received: from ppsw-31.csi.cam.ac.uk (unknown [131.111.8.131]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8b2d3990-a41f-11ea-ab2d-12813bfff9fa; Mon, 01 Jun 2020 15:49:58 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from 88-109-182-220.dynamic.dsl.as9105.com ([88.109.182.220]:51234 helo=[192.168.1.219]) by ppsw-31.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:465) with esmtpsa (PLAIN:amc96) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1jfmhG-000h9E-Ln (Exim 4.92.3) (return-path ); Mon, 01 Jun 2020 16:49:54 +0100 Subject: Re: [PATCH for-4.14] x86/ucode: Fix errors with start/end_update() To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200601145755.3661-1-andrew.cooper3@citrix.com> <20200601154832.GT1195@Air-de-Roger> From: Andrew Cooper Message-ID: Date: Mon, 1 Jun 2020 16:49:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200601154832.GT1195@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu , Jan Beulich , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 01/06/2020 16:48, Roger Pau Monné wrote: > On Mon, Jun 01, 2020 at 03:57:55PM +0100, Andrew Cooper wrote: >> c/s 9267a439c "x86/ucode: Document the behaviour of the microcode_ops hooks" >> identified several poor behaviours of the start_update()/end_update_percpu() >> hooks. >> >> AMD have subsequently confirmed that OSVW don't, and are not expected to, >> change across a microcode load, rendering all of this complexity unecessary. > Is there a reference to some AMD PM or similar document that can be > added here for completeness? Not at the moment.  (I'm attempting to solve this...) > >> Instead of fixing up the logic to not leave the OSVW state reset in a number >> of corner cases, delete the logic entirely. This in turn allows for the >> removal of the poorly-named 'start_update' parameter to >> microcode_update_one(). >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Roger Pau Monné Thanks, ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 01 16:02:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 16:02:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmsj-0007f6-Gx; Mon, 01 Jun 2020 16:01:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmsi-0007f1-EK for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 16:01:44 +0000 X-Inumbo-ID: 2f40963e-a421-11ea-ab2e-12813bfff9fa Received: from EUR02-HE1-obe.outbound.protection.outlook.com (unknown [40.107.1.52]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2f40963e-a421-11ea-ab2e-12813bfff9fa; Mon, 01 Jun 2020 16:01:43 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d8oPgprTr7PdcW2Qudkg9OxsdwXE+J/Nde90ZujYjtMivA68XQJYNLnfgOqayJYXC+QSNjw2oamHMGKA3wGmCfOwRAeNB+J0PQUpZRFdKti6B3XYFosh+QngDrgcHP0buDrGIwzSJQxYpxi0C61Hcf2T0MtWN12y022h5Sh3nrXljbqSIR7OGUN+aLN2LdSs+cYYSNPHiI4mR5SfAD+f/Pt7ILKdOf6h4JZ1uDvz/hA/57p+OgTNgWbJzTe5iM6mE3g9KujSYSw9cqIWx260SLKzFmDyko4WuemdJxuMthfMRddaLaMmIEJuiauZUO9VS0BfI3tSe1oxuRf9t138NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F6x7hE1q9AhvJqjX+yb/Z3jq0dzY+P9KCj9mE8kTXHs=; b=aHkVXPozvE3o8YFwjcX8x/LJivlJzeNgH4TgiH9+3/lTTnbwcEaa2ffMMxfxE7zERNx1fJgP/M5cE7onskzKbzI6DrWloeQuijbI1/ax5VR8P/wWJgcjngop8ef0CrnSsiSoW7m8hBsKPoAe0h58A2BkWqK1iy+mSApl0v3ljej1auAeeldQYlBXtIV+8jQjdwFgrGR5hs6vSwVPvBpmDK73H7KQH4cVcCq03xD1TXa1NiaYLD1wXVWxmVKskrSdUVRS/9gEDFww5+6dqXyeIv0zgCCVDg/m4aXHpLvOPc/AcrgY8NckCz9jBo6DPqVpU5DUUvIlwUHCQbJJBtB78w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F6x7hE1q9AhvJqjX+yb/Z3jq0dzY+P9KCj9mE8kTXHs=; b=aFgBzCGZVVGDOTD0jo+hchCGj/JsBrfoODwSYJt8DiU/bHFBQUpU4qKqDklADuQZwgUlqwhyoo37UxRFKIDf1fSNfhuc/gjtun415L00oWbpV072J+Qk+XNm55cLXcyeFPssBVsI2zd3nmarbseGkGRejP3+BrhC0EaKsbBnVTY= Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB4286.eurprd03.prod.outlook.com (2603:10a6:803:52::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Mon, 1 Jun 2020 16:01:41 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3045.024; Mon, 1 Jun 2020 16:01:41 +0000 From: Oleksandr Andrushchenko To: "xen-devel@lists.xenproject.org" , "jgross@suse.com" , "ian.jackson@eu.citrix.com" , "wl@xen.org" Subject: Re: [PATCH 0/2] displif: Protocol version 2 Thread-Topic: [PATCH 0/2] displif: Protocol version 2 Thread-Index: AQHWLoWt+Ro7bFPGqEmQq/EWm1xsZajD/tKA Date: Mon, 1 Jun 2020 16:01:41 +0000 Message-ID: References: <20200520090425.28558-1-andr2000@gmail.com> In-Reply-To: <20200520090425.28558-1-andr2000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a174fab5-2355-4def-ec84-08d8064512f0 x-ms-traffictypediagnostic: VI1PR03MB4286: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0421BF7135 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JKOltv8gKlNf0WHdLWkPII2ot580SdQ3kp8WButjMoVPBDw7b6iAsR6+KcaG19vIFC9VU01abtLxD2Vqd+I7V8ffRtSzqcwSmZ4MC35CWUPRGg044Z10QQYw1GHpYaTFt89AJJfRp0TUU47QMQKDf1+aY8a+bnlSvVNkUADIpoVWZoRlRrPW9eIsNY0GX/d/USJ1LRXYnPKIh3/e2lZ2XexFCOguCkinZcae4jnluMf0VNu5Xz5+c8cRWuxLZ5+Qc9UFu8VJHR7a3LRtwvePD1MM8I6Hp/vUxdadwNMpCXfEPHTVzGP+5zGgZSgdiZ1jByLrv/cseVWTMjteaFJYNu7kuXQWnqNT5t7RKiedJV0wSR0lqwDZ54RmrSqIGATCpPZHVxPOYB/d8tMU+IBMeg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(376002)(136003)(396003)(346002)(6512007)(2906002)(186003)(110136005)(478600001)(4326008)(26005)(966005)(31686004)(71200400001)(316002)(2616005)(5660300002)(8676002)(83380400001)(53546011)(86362001)(66556008)(6506007)(31696002)(66946007)(36756003)(64756008)(76116006)(8936002)(66476007)(66446008)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: n9WTsAs0cJN49jYW4kKNLH5uxQoIT27iBzPdyz1PCiufXwRyeb8K/IsYYbLLvZr4nZYKMY5kcppPdQborOxt0w7QJkEAmNgw2agrCEbNPYyn4Itn/D3jNdp1uanTp2ZXQP3wAOY1vdk9WstkCu8bt2G9r0nri964tH81C0vbuJhRw42TlVUMsvYwjy0Gho0kK3LVxNYrQBq4LKtXjv2QBlS6uKMZLloL+ur08Wf9T+rNl0sLs3wC1N1SjmL8WypfjGddCU3t0FuNKQSm0bga+8ytmp9JC6NHQWsdQiZeTbymBQC/3bBs8itwGLrlLVQl7/xnHx/48xoew96crDBVI9/WkZB38uS/JXB5DE5WJfhPELKRaYvd1j9olasXds6pB1cuBMJPdvR8Pl12Qu27wOXSE44aksp5dGAzeCpUWTebRCAt48oSr/Nk9d9UoDh01/teOpQnUjAg2d3s/kN0sEt3Ymovn20Qj9G1SGr2mbA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0C7984343B177B44A3E178C2AD2EF6A0@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: a174fab5-2355-4def-ec84-08d8064512f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2020 16:01:41.2134 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2e+WH25/OCSAxzj7RTCM18vpJsNEmkqFPB/7m3B792p+/87L1m/ZKPv9CIc3+7GGyf50Pxi0Yl0UixdilFyjdQXvSDuKRGCpmxicyW5chq1+vgTsxmRanbJ4NEYPMwxw X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4286 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andr2000@gmail.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" cGluZw0KDQpPbiA1LzIwLzIwIDEyOjA0IFBNLCBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbyB3cm90 ZToNCj4gRnJvbTogT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gPG9sZWtzYW5kcl9hbmRydXNoY2hl bmtvQGVwYW0uY29tPg0KPg0KPiBIZWxsbyBhbGwsDQo+DQo+IHRoaXMgc2VyaWVzIGV4dGVuZHMg dGhlIGV4aXN0aW5nIGRpc3BsaWYgcHJvdG9jb2wgd2l0aCBuZXcNCj4gcmVxdWVzdCBhbmQgYWRk cyBhZGRpdGlvbmFsIHBhcmFtZXRlciB0byB0aGUgZXhpdGluZyBvbmUuDQo+IEl0IGFsc28gcHJv dmlkZXMgc3VwcG9ydCBmb3IgdGhlIG5ldyBwYXJhbWV0ZXIgaW4gbGliZ250dGFiDQo+IHZpYSBp b2N0bC4gVGhlIHJlbGV2YW50IGNoYW5nZXMgaW4gdGhlIGJhY2tlbmQgY2FuIGJlIGZvdW5kIGF0 IFsxXQ0KPiBhbmQgdGhlIGZyb250ZW5kIGF0IFsyXS4NCj4NCj4gTGlzdCBvZiBjaGFuZ2VzOg0K Pg0KPiAxLiBDaGFuZ2UgcHJvdG9jb2wgdmVyc2lvbiBmcm9tIHN0cmluZyB0byBpbnRlZ2VyDQo+ DQo+IFZlcnNpb24gc3RyaW5nLCB3aGljaCBpcyBpbiBmYWN0IGFuIGludGVnZXIsIGlzIGhhcmQg dG8gaGFuZGxlIGluIHRoZQ0KPiBjb2RlIHRoYXQgc3VwcG9ydHMgZGlmZmVyZW50IHByb3RvY29s IHZlcnNpb25zLiBUbyBzaW1wbGlmeSB0aGF0DQo+IG1ha2UgdGhlIHZlcnNpb24gYW4gaW50ZWdl ci4NCj4NCj4gMi4gUGFzcyBidWZmZXIgb2Zmc2V0IHdpdGggWEVORElTUExfT1BfREJVRl9DUkVB VEUNCj4NCj4gVGhlcmUgYXJlIGNhc2VzIHdoZW4gZGlzcGxheSBkYXRhIGJ1ZmZlciBpcyBjcmVh dGVkIHdpdGggbm9uLXplcm8NCj4gb2Zmc2V0IHRvIHRoZSBkYXRhIHN0YXJ0LiBIYW5kbGUgc3Vj aCBjYXNlcyBhbmQgcHJvdmlkZSB0aGF0IG9mZnNldA0KPiB3aGlsZSBjcmVhdGluZyBhIGRpc3Bs YXkgYnVmZmVyLiBBZGQgdGhlIGNvcnJlc3BvbmRpbmcgZmlsZWQgdG8gdGhlDQo+IHByb3RvY29s IGFuZCBoYW5kbGUgaXQgaW4gbGliZ250dGFiLg0KPiBUaGlzIGNoYW5nZSBpcyByZXF1aXJlZCBm b3IgYnJpbmdpbmcgdmlydHVhbCBkaXNwbGF5IG9uIGlNWDgNCj4gcGxhdGZvcm0gd2hpY2ggdXNl cyBvZmZzZXQgb2YgNjQgYnl0ZXMgZm9yIHRoZSBidWZmZXJzIGFsbG9jYXRlZA0KPiBvbiBHUFUg c2lkZSBhbmQgdGhlbiBpbXBvcnRlZCBpbnRvIFBWIERSTSBmcm9udGVuZC4gT3RoZXJ3aXNlIHRo ZQ0KPiBmaW5hbCBwaWN0dXJlIGxvb2tzIHNoaWZ0ZWQuDQo+DQo+IDMuIEFkZCBYRU5ESVNQTF9P UF9HRVRfRURJRCBjb21tYW5kDQo+DQo+IEFkZCBhbiBvcHRpb25hbCByZXF1ZXN0IGZvciByZWFk aW5nIEV4dGVuZGVkIERpc3BsYXkgSWRlbnRpZmljYXRpb24NCj4gRGF0YSAoRURJRCkgc3RydWN0 dXJlIHdoaWNoIGFsbG93cyBiZXR0ZXIgY29uZmlndXJhdGlvbiBvZiB0aGUNCj4gZGlzcGxheSBj b25uZWN0b3JzIG92ZXIgdGhlIGNvbmZpZ3VyYXRpb24gc2V0IGluIFhlblN0b3JlLg0KPiBXaXRo IHRoaXMgY2hhbmdlIGNvbm5lY3RvcnMgbWF5IGhhdmUgbXVsdGlwbGUgcmVzb2x1dGlvbnMgZGVm aW5lZA0KPiB3aXRoIHJlc3BlY3QgdG8gZGV0YWlsZWQgdGltaW5nIGRlZmluaXRpb25zIGFuZCBh ZGRpdGlvbmFsIHByb3BlcnRpZXMNCj4gbm9ybWFsbHkgcHJvdmlkZWQgYnkgZGlzcGxheXMuDQo+ DQo+IElmIHRoaXMgcmVxdWVzdCBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBiYWNrZW5kIHRoZW4g dmlzaWJsZSBhcmVhDQo+IGlzIGRlZmluZWQgYnkgdGhlIHJlbGV2YW50IFhlblN0b3JlJ3MgInJl c29sdXRpb24iIHByb3BlcnR5Lg0KPg0KPiBJZiBiYWNrZW5kIHByb3ZpZGVzIGV4dGVuZGVkIGRp c3BsYXkgaWRlbnRpZmljYXRpb24gZGF0YSAoRURJRCkgd2l0aA0KPiBYRU5ESVNQTF9PUF9HRVRf RURJRCByZXF1ZXN0IHRoZW4gRURJRCB2YWx1ZXMgbXVzdCB0YWtlIHByZWNlZGVuY2UNCj4gb3Zl ciB0aGUgcmVzb2x1dGlvbnMgZGVmaW5lZCBpbiBYZW5TdG9yZS4NCj4NCj4gNC4gQnVtcCBwcm90 b2NvbCB2ZXJzaW9uIHRvIDIuDQo+DQo+IE9wZW4gcXVlc3Rpb25zIGFuZCBub3RlcyBvbiB0aGUg Y2hhbmdlczoNCj4NCj4gMS4gZ250dGFiIG1pbm9yIHZlcnNpb24gY2hhbmdlIGZyb20gMiB0byAz DQo+IEFzIHBlciBteSB1bmRlcnN0YW5kaW5nIGl0IGlzIHJlcXVpcmVkIHRvIGJ1bXAgdGhlIHZl cnNpb24gd2hlbg0KPiBJIGFkZCB0aGUgbmV3IGZ1bmN0aW9uYWxpdHksIGJ1dCBJIHdvdWxkIGxp a2UgdG8gaGVhciBmcm9tIHRoZQ0KPiBtYWludGFpbmVycyBvbiB0aGF0Lg0KPg0KPiAyLiBnbnR0 YWIgYW5kIHZlcnNpb24gMiBvZiB0aGUgaW9jdGxzDQo+IEJlY2F1c2Ugd2UgYWRkIGFuIGFkZGl0 aW9uYWwgcGFyYW1ldGVyIChkYXRhIG9mZnNldCkgYW5kIHRoZSBzdHJ1Y3R1cmVzDQo+IHVzZWQg dG8gcGFzcyBpb2N0bCBhcmd1bWVudHMgY2Fubm90IGJlIGV4dGVuZGVkICh0aGVyZSBhcmUgbm8g ZW5vdWdoDQo+IHJlc2VydmVkIGZpZWxkcyksIHNvIHRoZXJlIGFyZSB0byB3YXlzIHRvIHNvbHZl IHRoYXQ6DQo+IC0gYnJlYWsgdGhlIGV4aXN0aW5nIEFQSSBhbmQgYWRkIGRhdGFfb2ZzIGZpZWxk IGludG8gdGhlIGV4aXN0aW5nDQo+IHN0cnVjdHVyZXMNCj4gLSBjcmVhdGUgYSBjb3B5IG9mIHRo ZSBpb2N0bCAodjIpIHdpdGggdGhlIGFkZGl0aW9uYWwgcGFyYW1ldGVyLg0KPg0KPiBJdCBzZWVt cyB0byBiZSBlYXNpZXIgdG8gZ28gdGhlIGZpcnN0IHdheSwgYnV0IHRoaXMgYnJlYWtzIHRoaW5n cywNCj4gc28gSSBkZWNpZGVkIHRvIGludHJvZHVjZSB2MiBvZiB0aGUgc2FtZSBpb2N0bCB3aGlj aCBiZWhhdmVzIGdyYWNlZnVsbHkNCj4gd2l0aCByZXNwZWN0IHRvIHRoZSBleGlzdGluZyB1c2Vy cywgYnV0IGFkZHMgc29tZSBhbW91bnQgb2YNCj4gY29weS1wYXN0ZSBjb2RlIChJIHdhcyB0cnlp bmcgdG8gbWluaW1pemUgY29weS1wYXN0ZSBzbyBpdCBpcyBlYXNpZXINCj4gdG8gbWFpbnRhaW4s IGJ1dCB0aGUgcmVzdWx0IGxvb2tlZCB1Z2x5IHRvIG1lIGJlY2F1c2Ugb2YgbG90cyBvZg0KPiAi aWYgKHByb3RvY29sIHYxKSIgY29uc3RydWN0cy4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBzdHJ1 Y3QgaW9jdGxfZ250ZGV2X2RtYWJ1Zl9pbXBfdG9fcmVmcywgZS5nLg0KPiB2ZXJzaW9uIDEgb2Yg dGhlIGlvY3RsLCBoYXMgdWludDMyX3QgcmVzZXJ2ZWQgZmllbGQgd2hpY2ggY2FuIGJlDQo+IHVz ZWQgZm9yIHRoZSBkYXRhIG9mZnNldCwgYnV0IGl0cyBjb3VudGVycGFydCAoaW9jdGxfZ250ZGV2 X2RtYWJ1Zl9leHBfZnJvbV9yZWZzKQ0KPiBkb2Vzbid0IGhhdmUgYW55LCBzbyBpdCBzZWVtcyBu b3QgdG8gYmUgYWxpZ25lZCB0byBvbmx5IGludHJvZHVjZQ0KPiB2ZXJzaW9uIDIgb2YgdGhlIGlv Y3RsIGZvciB0aGUgbGF0ZXIuDQo+DQo+IFRoZSBvdGhlciBxdWVzdGlvbiBpcyBpZiB0byBrZWVw IHRoYXQgcmVzZXJ2ZWQgZmllbGQgaW4NCj4gaW9jdGxfZ250ZGV2X2RtYWJ1Zl9pbXBfdG9fcmVm c192MiBzdHJ1Y3R1cmUgb3IgZHJvcCBpdC4NCj4NCj4gMy4gZGlzcGxpZiBwcm90b2NvbCB2ZXJz aW9uIHN0cmluZyB0byBpbnQgY29udmVyc2lvbg0KPiBUaGUgZXhpc3RpbmcgcHJvdG9jb2wgZGVm aW5lcyBpdHMgdmVyc2lvbiBhcyBhIHN0cmluZyAiMSINCj4gd2hpY2ggaXMgb2ssIGJ1dCBtYWtl cyBpdCBub3Qgc28gZWFzeSB0byBiZSBkaXJlY3RseSB1c2VkIGJ5DQo+IEMvQysrIHByZXByb2Nl c3NvciB3aGljaCB3b3VsZCBsaWtlIHRvIHNlZSBhbiBpbnRlZ2VyIGZvciBjb25zdHJ1Y3RzDQo+ IGxpa2UgIiNpZiBYRU5ESVNQTF9QUk9UT0NPTF9WRVJTSU9OID4gMiINCj4NCj4gQXQgdGhlIHNh bWUgdGltZSB0aGlzIGNoYW5nZSBtYXkgYnJlYWsgdGhlIGV4aXN0aW5nIHVzZXJzIG9mIHRoZSBw cm90b2NvbA0KPiB3aGljaCBzdGlsbCBleHBlY3QgdmVyc2lvbiBhcyBhIHN0cmluZy4gSSB0cmll ZCBzb21ldGhpbmcgbGlrZQ0KPg0KPiAjZGVmaW5lIFNUUl9IRUxQRVIoeCkgI3gNCj4gI2RlZmlu ZSBTVFIoeCkgU1RSX0hFTFBFUih4KQ0KPg0KPiAjZGVmaW5lIFhFTkRJU1BMX1BST1RPQ09MX1ZF UlNJT05fSU5UIDENCj4gI2RlZmluZSBYRU5ESVNQTF9QUk9UT0NPTF9WRVJTSU9OIFNUUihYRU5E SVNQTF9QUk9UT0NPTF9WRVJTSU9OX0lOVCkNCj4NCj4gYnV0IG5vdCBzdXJlIGlmIHRoaXMgaXMg dGhlIHJpZ2h0IGFuZCBnb29kIHdheSB0byBzb2x2ZSB0aGUgaXNzdWUsDQo+IHNvIGluIHRoaXMg c2VyaWVzIEkgaGF2ZSBkZWxpYmVyYXRlbHkgY2hhbmdlZCB0aGUgcHJvdG9jb2wgdmVyc2lvbiB0 bw0KPiBpbnQuDQo+IE90aGVyIHBvc3NpYmxlIHdheSBjb3VsZCBiZSB0aGF0IGV2ZXJ5IHVzZXIg b2YgdGhlIGhlYWRlciBoYXMgaXRzIGxvY2FsDQo+IGNvcHkgKHRoaXMgaXMgd2hhdCB3ZSBub3cg dXNlIGluIHRoZSBkaXNwbGF5IGJhY2tlbmQpLiBUaGlzIHdheSB0aGUNCj4gbG9jYWwgY29weSBj YW4gYmUgY2hhbmdlZCBpbiBhIHdheSBzdWl0YWJsZSBmb3IgdGhlIGNvbmNyZXRlIHVzZXIuDQo+ IFRoaXMgY2Fubm90IGJlIGRvbmUgKD8pIGZvciB0aGUgTGludXggS2VybmVsIHRob3VnaC4NCj4N Cj4gVGhhbmsgeW91LA0KPiBPbGVrc2FuZHINCj4NCj4gWzFdIGh0dHBzOi8vZ2l0aHViLmNvbS94 ZW4tdHJvb3BzL2Rpc3BsX2JlDQo+IFsyXSBodHRwczovL2dpdGh1Yi5jb20veGVuLXRyb29wcy9s aW51eC9wdWxsLzg3DQo+DQo+IE9sZWtzYW5kciBBbmRydXNoY2hlbmtvICgyKToNCj4gICAgeGVu L2Rpc3BsaWY6IFByb3RvY29sIHZlcnNpb24gMg0KPiAgICBsaWJnbnR0YWI6IEFkZCBzdXBwb3J0 IGZvciBMaW51eCBkbWEtYnVmIG9mZnNldA0KPg0KPiAgIHRvb2xzL2luY2x1ZGUveGVuLXN5cy9M aW51eC9nbnRkZXYuaCAgfCA1MyArKysrKysrKysrKysrKysrKw0KPiAgIHRvb2xzL2xpYnMvZ250 dGFiL01ha2VmaWxlICAgICAgICAgICAgfCAgMiArLQ0KPiAgIHRvb2xzL2xpYnMvZ250dGFiL2Zy ZWVic2QuYyAgICAgICAgICAgfCAxNSArKysrKw0KPiAgIHRvb2xzL2xpYnMvZ250dGFiL2dudHRh Yl9jb3JlLmMgICAgICAgfCAxNyArKysrKysNCj4gICB0b29scy9saWJzL2dudHRhYi9pbmNsdWRl L3hlbmdudHRhYi5oIHwgMTMgKysrKw0KPiAgIHRvb2xzL2xpYnMvZ250dGFiL2xpYnhlbmdudHRh Yi5tYXAgICAgfCAgNiArKw0KPiAgIHRvb2xzL2xpYnMvZ250dGFiL2xpbnV4LmMgICAgICAgICAg ICAgfCA4NiArKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gICB0b29scy9saWJzL2dudHRh Yi9taW5pb3MuYyAgICAgICAgICAgIHwgMTUgKysrKysNCj4gICB0b29scy9saWJzL2dudHRhYi9w cml2YXRlLmggICAgICAgICAgIHwgIDkgKysrDQo+ICAgeGVuL2luY2x1ZGUvcHVibGljL2lvL2Rp c3BsaWYuaCAgICAgICB8IDgzICsrKysrKysrKysrKysrKysrKysrKysrKystDQo+ICAgMTAgZmls ZXMgY2hhbmdlZCwgMjk1IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0pDQo+ From xen-devel-bounces@lists.xenproject.org Mon Jun 01 16:07:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 16:07:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmxw-0007se-4f; Mon, 01 Jun 2020 16:07:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfmxv-0007rl-2F for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 16:07:07 +0000 X-Inumbo-ID: efcab39e-a421-11ea-9dbe-bc764e2007e4 Received: from 3.mo68.mail-out.ovh.net (unknown [46.105.58.60]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id efcab39e-a421-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 16:07:05 +0000 (UTC) Received: from player695.ha.ovh.net (unknown [10.110.103.195]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id A763116BFC7 for ; Mon, 1 Jun 2020 18:07:04 +0200 (CEST) Received: from kaod.org (82-64-250-170.subs.proxad.net [82.64.250.170]) (Authenticated sender: clg@kaod.org) by player695.ha.ovh.net (Postfix) with ESMTPSA id 55E0D12CAB066; Mon, 1 Jun 2020 16:06:43 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-98R002b8d09b32-b5d3-4353-abb8-6409bc852004,83E988B7E4CB5EF414800AC4A3AAD9DE61AE43FA) smtp.auth=clg@kaod.org Subject: Re: [PATCH v2 1/8] hw/arm/aspeed: Correct DRAM container region size To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-2-f4bug@amsat.org> From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= Message-ID: <10b20388-ee7a-9a61-83d5-7686369dab20@kaod.org> Date: Mon, 1 Jun 2020 18:06:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-2-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 2857533967562673072 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudefhedgkeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepveorughrihgtpgfnvggpifhorghtvghruceotghlgheskhgrohgurdhorhhgqeenucggtffrrghtthgvrhhnpeefffdvtddugeeifeduuefghfejgfeigeeigeeltedthefgieeiveeuiefhgeefgfenucfkpheptddrtddrtddrtddpkedvrdeigedrvdehtddrudejtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrheileehrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomheptghlgheskhgrohgurdhorhhgpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 4:29 PM, Philippe Mathieu-Daudé wrote: > memory_region_set_size() handle the 16 Exabytes limit by > special-casing the UINT64_MAX value. This is not a problem > for the 32-bit maximum, 4 GiB. > By using the UINT32_MAX value, the aspeed-ram-container > MemoryRegion ends up missing 1 byte: > > $ qemu-system-arm -M ast2600-evb -S -monitor stdio > (qemu) info mtree > > address-space: aspeed.fmc-ast2600-dma-dram > 0000000080000000-000000017ffffffe (prio 0, i/o): aspeed-ram-container > 0000000080000000-00000000bfffffff (prio 0, ram): ram > 00000000c0000000-ffffffffffffffff (prio 0, i/o): max_ram > > Fix by using the correct value. We now have: > > address-space: aspeed.fmc-ast2600-dma-dram > 0000000080000000-000000017fffffff (prio 0, i/o): aspeed-ram-container > 0000000080000000-00000000bfffffff (prio 0, ram): ram > 00000000c0000000-ffffffffffffffff (prio 0, i/o): max_ram > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Cédric Le Goater Thanks, C. > --- > hw/arm/aspeed.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c > index 2c23297edf..62344ac6a3 100644 > --- a/hw/arm/aspeed.c > +++ b/hw/arm/aspeed.c > @@ -262,7 +262,7 @@ static void aspeed_machine_init(MachineState *machine) > bmc = g_new0(AspeedBoardState, 1); > > memory_region_init(&bmc->ram_container, NULL, "aspeed-ram-container", > - UINT32_MAX); > + 4 * GiB); > memory_region_add_subregion(&bmc->ram_container, 0, machine->ram); > > object_initialize_child(OBJECT(machine), "soc", &bmc->soc, > From xen-devel-bounces@lists.xenproject.org Mon Jun 01 16:12:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 16:12:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfn3V-0000KW-Pa; Mon, 01 Jun 2020 16:12:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfn3U-0000KR-VT for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 16:12:53 +0000 X-Inumbo-ID: bdfab4ee-a422-11ea-ab2f-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bdfab4ee-a422-11ea-ab2f-12813bfff9fa; Mon, 01 Jun 2020 16:12:51 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 99760206C3; Mon, 1 Jun 2020 16:12:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591027970; bh=KR0RYgpHZ2PN6KaQgrrKmx5yqFIfhICtOodWI3QPFSg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=xRCt56M+uT7gaPF9KQh/HF/wm3gP3GII7msL8Zbv6PT9ucWdLsEBCaDQkIxuiIe6M 6pxa1R7EWFCPIBI+cNIYRtDIOedxKtUAr2Z+c2rSHU85M1OAkHjTcv7JtGcDTwdiKH +rRJ3srZYhb9EyItznW6AOU4X534gC+ih08LHcmw= Date: Mon, 1 Jun 2020 09:12:45 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Roman Shaposhnik Subject: Re: UEFI support in ARM DomUs In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Stefano Stabellini , George.Dunlap@citrix.com, Nataliya Korovkina , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" + George On Sun, 31 May 2020, Roman Shaposhnik wrote: > Hi Julien! > > On Sun, May 31, 2020 at 3:24 PM Julien Grall wrote: > > > > On Sun, 31 May 2020 at 23:05, Roman Shaposhnik wrote: > > > Hi! > > > > > > with a lot of help from Stefano, we're getting RPi4 support in > > > Project EVE pretty much on par between KVM and Xen. > > > > > > One big area that still remains is supporting UEFI boot sequence > > > for DomUs. With KVM, given the qemu virt device model this is > > > as simple as using either stock UEFI build for arm or even U-Boot > > > EFI emulation environment and passing it via -bios option. > > > > > > Obviously with Xen on ARM we don't have the device model so > > > my understanding is that the easiest way we can support it would > > > be to port UEFI's OvmfPkg/OvmfXen target to ARM (it seems to > > > be currently exclusively X64). > > > > EDK2 has been supporting Xen on Arm for the past 5 years. We don't use > > OvmfPkg/OvmfXen but ArmVirtPkg/ArmVirtXen (see [1]). > > I haven't tried to build it recently, but I should be able to help if > > there is any issue with it. > > > > Cheers, > > > > [1] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtXen.fdf > > This is really, really awesome -- I guess it would be really helpful to document > this someplace on the ARM/Xen wiki (I can volunteer if someone can grant > me the karma). Regarding the wiki: yes please! Let George know if you don't have write access. > I've built XEN_EFI.fd and the rest worked out like a charm. > > All on Raspberry Pi 4! Fantastic! From xen-devel-bounces@lists.xenproject.org Mon Jun 01 16:51:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 16:51:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfnec-0003yZ-8g; Mon, 01 Jun 2020 16:51:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfneb-0003yU-LU for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 16:51:13 +0000 X-Inumbo-ID: 19731ca8-a428-11ea-81bc-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 19731ca8-a428-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 16:51:12 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: NKYITG2Nna1s56beZgklef6jwSPFDnR0DvWsVEs7qjASBC12AIVJNkHr7X8LsCmNseY9g7+oiW 9dpkM0VYSfTOaBpP1CYvLIXbO4bVeX+PWaHr9sSSq0/OVQ2VslLxqbi3B7w2raVr5ZstXfu7cT YRkGVKIGaInch/AqT6h7etus5OftTxgWaookItUq1Rn2gRf2cJ3vWSayqj+bnViLT02UxQ7NeE 4+SjNND5lMZ0NdVmwqNATzcyVCZA7DPnRnjelHDeSw1v9Z7dRfyg2bx8UUqO9GcmzQYGQoYu9N u6Y= X-SBRS: 2.7 X-MesageID: 19197850 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,461,1583211600"; d="scan'208";a="19197850" Date: Mon, 1 Jun 2020 18:51:05 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Subject: Re: [PATCH for-4.14] docs/ucode: Extend runtime microcode loading documentation Message-ID: <20200601165105.GU1195@Air-de-Roger> References: <20200601134025.24142-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200601134025.24142-1-andrew.cooper3@citrix.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Paul Durrant , Jan Beulich , Ian Jackson , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 01, 2020 at 02:40:25PM +0100, Andrew Cooper wrote: > Extend the disclaimer about runtime loading. While we've done our best to > make the mechaism reliable, the safety of late loading does ultimately depend > on the contents of the blobs. > > Extend the xen-ucode portion with examples of how to use it. > > Signed-off-by: Andrew Cooper Reviewed-by: Roger Pau Monné > --- > CC: George Dunlap > CC: Ian Jackson > CC: Jan Beulich > CC: Konrad Rzeszutek Wilk > CC: Stefano Stabellini > CC: Wei Liu > CC: Julien Grall > CC: Paul Durrant > --- > docs/admin-guide/microcode-loading.rst | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst > index 5f0f661a2e..8cd5d0351b 100644 > --- a/docs/admin-guide/microcode-loading.rst > +++ b/docs/admin-guide/microcode-loading.rst > @@ -104,8 +104,8 @@ modules to find any CPIO archives, and search the archive for the applicable > file. Xen will stop searching at the first match. > > > -Run time microcode loading > --------------------------- > +Runtime microcode loading > +------------------------- > > .. warning:: > > @@ -113,7 +113,23 @@ Run time microcode loading > or at boot time. Not all microcode updates (or parts thereof) can be > applied at runtime. > > -The ``xen-ucode`` utility can be used to initiate a runtime microcode load. > + Given the proprietry nature of microcode, we are unable to make any claim > + that a runtime microcode is risk-free. Any runtime microcode loading needs > + adequate testing on a dev instance before being rolled out to production > + systems. > + > +The ``xen-ucode`` utility can be used to initiate a runtime microcode load:: > + > + [root@host ~]# xen-ucode > + xen-ucode: Xen microcode updating tool > + Usage: xen-ucode > + [root@host ~]# > + > +e.g. With a Linux dom0 on a Haswell system:: > + > + [root@host ~]# xen-ucode /lib/firmware/intel-ucode/06-3c-03 Could you expand a bit on the nomenclature used here? I assume it's something like -- but might be good to provide people a hint to know how to find the appropriate blob for their system if possible. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 01 17:11:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 17:11:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfnyP-0005pg-3U; Mon, 01 Jun 2020 17:11:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfnyN-0005pb-Ja for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 17:11:39 +0000 X-Inumbo-ID: f453026f-a42a-11ea-ab39-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f453026f-a42a-11ea-ab39-12813bfff9fa; Mon, 01 Jun 2020 17:11:38 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: jF0oiAQyTIrybsSM3EBmhIxPt6HS3disKI2bKJcE+rmei7ZmL/NyGWP+KfDwn2Ymnguhg+AFZV o9JAp1v7UFkFxmHFqIYhKKAAFMAy86vqi7k+ONt+bK2xc/Wp24KqDKrr0bDPPlE4LWY9nA3MEf 6C3olsprDhF8oNfbaYvqSl42N8/EdsKh4jOAw9OuPIqiYcg520tSJIHnKpI0m2Lz+a0cfpWcfD qqpxrcSCrYqrCGWNqInDlCaYubasjIPZmx2BYLxICTTXhabF0I7cfhx9Aid14SK3yKu0T2hC1b bR4= X-SBRS: 2.7 X-MesageID: 18941205 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,461,1583211600"; d="scan'208";a="18941205" From: George Dunlap To: "paul@xen.org" Subject: Re: [PATCH v19 for-4.14 00/13] VM forking Thread-Topic: [PATCH v19 for-4.14 00/13] VM forking Thread-Index: AQHWOBefMhAMazhbj0Srm4nW5RbX56jDuyAAgAAij4A= Date: Mon, 1 Jun 2020 17:11:33 +0000 Message-ID: <4017F2B3-BB9B-4E9F-813C-6FE68BA0D568@citrix.com> References: <000c01d63826$6d125900$47370b00$@xen.org> In-Reply-To: <000c01d63826$6d125900$47370b00$@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Kevin Tian , Stefano Stabellini , Tamas K Lengyel , Jan Beulich , Wei Liu , Andrew Cooper , Tamas K Lengyel , Jun Nakajima , Ian Jackson , Anthony Perard , xen-devel , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gSnVuIDEsIDIwMjAsIGF0IDQ6MDcgUE0sIFBhdWwgRHVycmFudCA8eGFkaW1nbmlr QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IFhlbi1kZXZlbCA8eGVuLWRldmVsLWJvdW5jZXNAbGlzdHMueGVucHJvamVjdC5vcmc+ IE9uIEJlaGFsZiBPZiBUYW1hcyBLIExlbmd5ZWwNCj4+IFNlbnQ6IDAxIEp1bmUgMjAyMCAxNDoy Mg0KPj4gVG86IHhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZw0KPj4gQ2M6IEtldmluIFRp YW4gPGtldmluLnRpYW5AaW50ZWwuY29tPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGlu aUBrZXJuZWwub3JnPjsgVGFtYXMgSyBMZW5neWVsDQo+PiA8dGFtYXMubGVuZ3llbEBpbnRlbC5j b20+OyBKdW4gTmFrYWppbWEgPGp1bi5uYWthamltYUBpbnRlbC5jb20+OyBXZWkgTGl1IDx3bEB4 ZW4ub3JnPjsgQW5kcmV3IENvb3Blcg0KPj4gPGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20+OyBJ YW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT47IEdlb3JnZSBEdW5sYXANCj4+ IDxnZW9yZ2UuZHVubGFwQGNpdHJpeC5jb20+OyBUYW1hcyBLIExlbmd5ZWwgPHRhbWFzQHRrbGVu Z3llbC5jb20+OyBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+Ow0KPj4gQW50aG9ueSBQ RVJBUkQgPGFudGhvbnkucGVyYXJkQGNpdHJpeC5jb20+OyBKdWxpZW4gR3JhbGwgPGp1bGllbkB4 ZW4ub3JnPjsgUm9nZXIgUGF1IE1vbm7DqQ0KPj4gPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPj4g U3ViamVjdDogW1BBVENIIHYxOSBmb3ItNC4xNCAwMC8xM10gVk0gZm9ya2luZw0KPiANCj4gSGks DQo+IA0KPiAgVGhpcyBzZXJpZXMgbG9va3MgdG8gYmUgbGFyZ2VseSB1bi1hY2tlZCBzbywgc2lu Y2Ugd2UgYXJlIG5vdyBwYXN0IHRoZSBmcmVlemUgZGF0ZSwgSSBkb24ndCByZWFsbHkgdGhpbmsg aXQgY2FuIGdvIGludG8gNC4xNC4gSXMgdGhlcmUgYSBwYXJ0aWN1bGFyIHJlYXNvbiB0aGF0IHlv dSB0aGluayBpdCBzaG91bGQgYmUgY29uc2lkZXJlZD8NCg0KVGFtYXPigJkgcHJvamVjdCBpdHNl bGYgbWFpbmx5IHVzZXMgbGlieGMgYW5kIGJlbG93LCBhcyBJIHVuZGVyc3RhbmQ7IGFuZCBzbyBn ZXR0aW5nIHBhdGNoZXMgMSBhbmQgMiBpbiB3b3VsZCBiZSBhbiBpbXBvcnRhbnQgbWlsZXN0b25l OyBib3RoIGhhdmUgaGFkIFItYuKAmXMgYmVmb3JlIHRoZSBmZWF0dXJlIGZyZWV6ZS4gIEFyZ3Vh Ymx5IHBhdGNoZXMgMSBhbmQgMiBhcmUgYSBidWcgZml4LiAgUGF0Y2ggMSBpcyBtaXNzaW5nIFZN WCAob3IgYSBnZW5lcmFsIHg4NikuDQoNClRoZSBsaWJ4bC94bCBzaWRlIGhhc27igJl0LCBhcyBJ IHVuZGVyc3RhbmQgaXQsIGhhZCBzaWduaWZpY2FudCByZXZpZXc7IEkgdGhpbmsgdGhhdCBzaG91 bGQgcHJvYmFibHkgd2FpdCB1bnRpbCA0LjE1Lg0KDQpXaGF0IGRvIHlvdSB0aGluaywgVGFtYXM/ DQoNCiAtR2Vvcmdl From xen-devel-bounces@lists.xenproject.org Mon Jun 01 17:19:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 17:19:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfo5b-00063Q-Rj; Mon, 01 Jun 2020 17:19:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfo5a-00063L-SE for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 17:19:06 +0000 X-Inumbo-ID: fea966b2-a42b-11ea-9947-bc764e2007e4 Received: from ppsw-31.csi.cam.ac.uk (unknown [131.111.8.131]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fea966b2-a42b-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 17:19:05 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from 88-109-182-220.dynamic.dsl.as9105.com ([88.109.182.220]:54576 helo=[192.168.1.219]) by ppsw-31.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:465) with esmtpsa (PLAIN:amc96) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1jfo5R-000aMz-Kp (Exim 4.92.3) (return-path ); Mon, 01 Jun 2020 18:18:57 +0100 Subject: Re: [PATCH for-4.14] docs/ucode: Extend runtime microcode loading documentation To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200601134025.24142-1-andrew.cooper3@citrix.com> <20200601165105.GU1195@Air-de-Roger> From: Andrew Cooper Message-ID: <46ae5234-5f0f-e963-7857-520743e047f9@citrix.com> Date: Mon, 1 Jun 2020 18:18:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200601165105.GU1195@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Paul Durrant , Jan Beulich , Ian Jackson , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 01/06/2020 17:51, Roger Pau Monné wrote: > > On Mon, Jun 01, 2020 at 02:40:25PM +0100, Andrew Cooper wrote: >> Extend the disclaimer about runtime loading. While we've done our best to >> make the mechaism reliable, the safety of late loading does ultimately depend >> on the contents of the blobs. >> >> Extend the xen-ucode portion with examples of how to use it. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Roger Pau Monné Thanks, > >> --- >> CC: George Dunlap >> CC: Ian Jackson >> CC: Jan Beulich >> CC: Konrad Rzeszutek Wilk >> CC: Stefano Stabellini >> CC: Wei Liu >> CC: Julien Grall >> CC: Paul Durrant >> --- >> docs/admin-guide/microcode-loading.rst | 22 +++++++++++++++++++--- >> 1 file changed, 19 insertions(+), 3 deletions(-) >> >> diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst >> index 5f0f661a2e..8cd5d0351b 100644 >> --- a/docs/admin-guide/microcode-loading.rst >> +++ b/docs/admin-guide/microcode-loading.rst >> @@ -104,8 +104,8 @@ modules to find any CPIO archives, and search the archive for the applicable >> file. Xen will stop searching at the first match. >> >> >> -Run time microcode loading >> --------------------------- >> +Runtime microcode loading >> +------------------------- >> >> .. warning:: >> >> @@ -113,7 +113,23 @@ Run time microcode loading >> or at boot time. Not all microcode updates (or parts thereof) can be >> applied at runtime. >> >> -The ``xen-ucode`` utility can be used to initiate a runtime microcode load. >> + Given the proprietry nature of microcode, we are unable to make any claim >> + that a runtime microcode is risk-free. Any runtime microcode loading needs >> + adequate testing on a dev instance before being rolled out to production >> + systems. >> + >> +The ``xen-ucode`` utility can be used to initiate a runtime microcode load:: >> + >> + [root@host ~]# xen-ucode >> + xen-ucode: Xen microcode updating tool >> + Usage: xen-ucode >> + [root@host ~]# >> + >> +e.g. With a Linux dom0 on a Haswell system:: >> + >> + [root@host ~]# xen-ucode /lib/firmware/intel-ucode/06-3c-03 > Could you expand a bit on the nomenclature used here? > > I assume it's something like -- but might be good > to provide people a hint to know how to find the appropriate blob for > their system if possible. It is $FAMILY-$MODEL-$STEPPING.  Currently only a single version of each microcode is installed at once by the microcode_ctl package. However, its infeasible to cater to all setup's/situations here.  Within linux, you could clone https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/ or use the slightly older single monolithic microcode.dat. And that is before you start considering non-Intel systems, or other ways of packaging microcode. I'm open to suggestions for how to make this clearer, but we definitely can't do an exhaustive list of places you might find microcode. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 01 17:34:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 17:34:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfoKJ-0007lo-4k; Mon, 01 Jun 2020 17:34:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfoKH-0007lh-9p for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 17:34:17 +0000 X-Inumbo-ID: 1ac9cfec-a42e-11ea-9dbe-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1ac9cfec-a42e-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 17:34:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lnB64VaB7NK4YTB0kxFse7q+3iNHVPVIe7lmiiR95Y0=; b=XiFdgqEvQSHllgo6CQZbTs6Mz 4iSFbC9SpxUlqW9lQ/2KbI3wKk6Hx4qmIVIyta6yrcg215PUdjcaLKJ8fZDLhHBPoRyoGFm797k5S alDhTb9vRUgu4uSsaWQ0oqO06A138KO3c4+LMnclZW38jZuw2+i3VB3iBHSE0jQ1onXzc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfoKA-0007s9-TC; Mon, 01 Jun 2020 17:34:10 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfoKA-0004pE-MD; Mon, 01 Jun 2020 17:34:10 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfoKA-0008BX-La; Mon, 01 Jun 2020 17:34:10 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150598: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ad33a573c009d72466432b41ba0591c64e819c19 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Mon, 01 Jun 2020 17:34:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150598 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150598/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen ad33a573c009d72466432b41ba0591c64e819c19 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 4 days Failing since 150465 2020-05-29 09:02:14 Z 3 days 30 attempts Testing same since 150515 2020-05-30 01:00:47 Z 2 days 20 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1196 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 17:39:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 17:39:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfoOw-0007wP-Nh; Mon, 01 Jun 2020 17:39:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfoOv-0007wI-87 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 17:39:05 +0000 X-Inumbo-ID: c868509c-a42e-11ea-9947-bc764e2007e4 Received: from mail-wm1-x32f.google.com (unknown [2a00:1450:4864:20::32f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c868509c-a42e-11ea-9947-bc764e2007e4; Mon, 01 Jun 2020 17:39:03 +0000 (UTC) Received: by mail-wm1-x32f.google.com with SMTP id f185so357484wmf.3 for ; Mon, 01 Jun 2020 10:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3L0nLA9rg9jYJ33/tCaYUBLuqLNlm/ZlH40+u3I3fhM=; b=blJvii5NIdN5+0Iehkx8vixVgg8MfXoB66AOXqUqBC06uRFI5b4D4Mcs68JCHCcxX4 WbtWK+7/FLmNxtzZOEH1/WxcyaQz6BKkZKgXbLs68J4Cx7OFgMnb4FIsGL7/WeskQgHW OTCE1bwDv06c8YhE7OT5PkrYr1PVXVm2+nU2c6EoXz0+je/qn59O2j+1lXu1FfIPRJTI 4ILgWdULG29gLfLpA41gc3IXu37MkhghGmKQmbWmXHBwhDcpECXrJ9h9w8l53f/n43Kw 0I6h5R7pg9wN/V9LCL1z7U/PAAjpqkLEH6P7/h2b8l96fDth8XecMuaVaSASoG2nBWvK COKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3L0nLA9rg9jYJ33/tCaYUBLuqLNlm/ZlH40+u3I3fhM=; b=P5/4pL8CtEyM3N877yxmo+30qJvpq74LOfQHBUyqR+wgjLilElMPEuIZuMsno+EslQ YYO5FGziq4asQ2qyibmk+SS/GlFB8eip7U1WrPRdAAfO1HxsuMvkD1b0UwOcfkgPoFkp bDkoefQs6V37svubZx2eCzgVhix2+S2+ZlrIMGuNwSlnDT08SPYCFV8WgRwE8WfXO4HW r/HEJS9TUoCykqyQWaKoYQDIiCOIEU0HU53z7bvOduKRhyOfgA2+TiIYITKu+uOGs+Gu sG/HuPW9WtaOh3rTTmsrcwCvR58sOYmMcFnsY/O4N0yz//R3C+fTAyDGVRzpVURt3OW0 IaoA== X-Gm-Message-State: AOAM5313EOwaPQuJklgipMaytAGMgVkC6yfupTcCiXBX5cIymItoV57Z 4NTLOMbEF2mP1EGVU3BtitkRzqJMyb6hmzd0QmA1mJM/lNQNMQ== X-Google-Smtp-Source: ABdhPJwXhFpgMKVp4A9hNBlD6jFiBBMDG1O2ewRnDVl6GYmY6m9VXpTusHZNJknDmCMIVopy1yfX9mT/fNNQnWkrt5k= X-Received: by 2002:a1c:6389:: with SMTP id x131mr387941wmb.90.1591033142100; Mon, 01 Jun 2020 10:39:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: CodeWiz2280 Date: Mon, 1 Jun 2020 13:38:51 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: multipart/alternative; boundary="00000000000042c39105a709453e" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --00000000000042c39105a709453e Content-Type: text/plain; charset="UTF-8" Hi Julien, As requested please see log below from the eval board booting dom0, some notes are as follows: 1. The offset that gets applied to the 32-bit address to translate it to 36-bits is 0x7_8000_0000 2. Uboot has been setup to not change the address of the memory in the device tree prior to launching xen, otherwise it would automatically offset it and replace it with a 36-bit address and xen would immediately panic at the 36-bit address for a 32-bit processor. 3. The RAM starting address placed in the device tree is 0x8000_0000, which gets carved up by xen and replaced with 0xA000_0000 prior to booting dom0.. I had to put in test code to have the kernel offset the 0xA000_0000 32-bit starting address to the 36-bit address needed before the kernel will attempt to switch. If it stays 32-bit then it will not switch over the address space. Note that without xen in play uboot would normally replace the address in the device tree with the 36-bit one. 4. The dom0 kernel will boot from xen if the early_paging_init switch step is skipped, and the low mem stays in 32-bit....but there is a problem with the peripherals so this is not an acceptable solution. It seems that either the kernel would need some API to tell xen that there is going to be a change in the memory its using prior to call early_paging_init(), or Xen would need to add the additional 36-bit addresses during the memory bank allocation step....but recognize that they are not actually different physical memory but just aliased to a different address. Thanks, Dave Xen 4.14-unstable (XEN) Xen version 4.14-unstable (arm-linux-gnueabihf-gcc (Linaro GCC 4.9-2015.05) 4.9.3 20150413 (prerelease)) debug=y Mon Jun 1 10:22:11 EDT 2020 (XEN) Latest ChangeSet: (XEN) build-id: 30ae91a06c71a885cfba2788965144999a864614 (XEN) Console output is synchronous. (XEN) Processor: 412fc0f4: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x4 (XEN) 32-bit Execution: (XEN) Processor Features: 00001131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 02010555 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10201105 20000000 01240000 02102211 (XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000 (XEN) Using SMC Calling Convention v1.0 (XEN) Using PSCI v0.1 (XEN) SMP: Allowing 4 CPUs (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 208333 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=0000000002561000 (XEN) gic_cpu_addr=0000000002562000 (XEN) gic_hyp_addr=0000000002564000 (XEN) gic_vcpu_addr=0000000002566000 (XEN) gic_maintenance_irq=25 (XEN) Using the new VGIC implementation. (XEN) GICv2: 512 lines, 4 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) (XEN) Initializing Credit2 scheduler (XEN) load_precision_shift: 18 (XEN) load_window_shift: 30 (XEN) underload_balance_tolerance: 0 (XEN) overload_balance_tolerance: -3 (XEN) runqueues arrangement: socket (XEN) cap enforcement granularity: 10ms (XEN) load tracking window length 1073741824 ns (XEN) Allocated console ring of 32 KiB. (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 (XEN) CPU0: Guest atomics will try 2 times before pausing the domain (XEN) Bringing up CPU1 (XEN) CPU1: Guest atomics will try 1 times before pausing the domain (XEN) CPU 1 booted. (XEN) Bringing up CPU2 (XEN) CPU2: Guest atomics will try 1 times before pausing the domain (XEN) CPU 2 booted. (XEN) Bringing up CPU3 (XEN) CPU3: Guest atomics will try 1 times before pausing the domain (XEN) CPU 3 booted. (XEN) Brought up 4 CPUs (XEN) I/O virtualisation disabled (XEN) P2M: 40-bit IPA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558 (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource (XEN) Adding cpu 0 to runqueue 0 (XEN) First cpu on runqueue, activating (XEN) Adding cpu 1 to runqueue 0 (XEN) Adding cpu 2 to runqueue 0 (XEN) Adding cpu 3 to runqueue 0 (XEN) alternatives: Patching with alt table 002c2530 -> 002c2578 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading d0 kernel from boot module @ 0000000083000000 (XEN) Loading ramdisk from boot module @ 0000000088000000 (XEN) Allocating 1:1 mappings totalling 1024MB for dom0: (XEN) BANK[0] 0x000000a0000000-0x000000e0000000 (1024MB) (XEN) Grant table range: 0x00000082000000-0x00000082040000 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading zImage from 0000000083000000 to 00000000a7a00000-00000000a7f36100 (XEN) Loading d0 initrd from 0000000088000000 to 0x00000000a8200000-0x00000000abe00000 (XEN) Loading d0 DTB to 0x00000000a8000000-0x00000000a8007872 (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Scrubbing Free RAM in background (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *************************************************** (XEN) WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) This option is intended to aid debugging of Xen by ensuring (XEN) that all output is synchronously delivered on the serial line. (XEN) However it can introduce SIGNIFICANT latencies and affect (XEN) timekeeping. It is NOT recommended for production use! (XEN) *************************************************** (XEN) WARNING: SILO mode is not enabled. (XEN) It has implications on the security of the system, (XEN) unless the communications have been forbidden between (XEN) untrusted domains. (XEN) *************************************************** (XEN) 3... 2... 1... (XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to switch input) (XEN) Freed 328kB init memory. (XEN) DOM0: [ 0.000000] Booting Linux on physical CPU 0x0 (XEN) DOM0: [ 0.000000] Linux version 4.19.59-g5f8c1c6121 (gcc version 8.3.0 (GNU Toolchain for the A-profile A (XEN) DOM0: rchitecture 8.3-2019.03 (arm-rel-8.36))) #52 SMP Mon Jun 1 12:13:51 EDT 2020 (XEN) DOM0: [ 0.000000] CPU: ARMv7 Processor [412fc0f4] revision 4 (ARMv7), cr=30c5387d (XEN) DOM0: [ 0.000000] CPU: div instructions available: patching division code (XEN) DOM0: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache (XEN) DOM0: [ 0.000000] OF: fdt: Machine model: Texas Instruments Keystone 2 Edison EVM (XEN) DOM0: [ 0.000000] bootconsole [earlycon0] enabled (XEN) DOM0: [ 0.000000] debug: ignoring loglevel setting. (XEN) DOM0: [ 0.000000] Memory policy: Data cache writealloc (XEN) DOM0: [ 0.000000] test : mem_start from dtb = 0xa0000000 (XEN) DOM0: [ 0.000000] test : force the mem_start = 0x800000000 (XEN) DOM0: [ 0.000000] test : note KEYSTONE_LOW_PHYS_START = 80000000, KEYSTONE_LOW_PHYS_END = ffffffff (XEN) DOM0: [ 0.000000] test : note KEYSTONE_HIGH_PHYS_START = 800000000, KEYSTONE_HIGH_PHYS_END = bffffffff (XEN) DOM0: [ 0.000000] test : Switch physical address space to 0x820000000 (0xa0000000 + 0x780000000) (XEN) DOM0: [ 0.000000] test : inside of early_paging_init() (XEN) traps.c:1980:d0v0 HSR=0x80000086 pc=0xa020010c gva=0xa020010c gpa=0x0000082000310c (XEN) traps.c:1980:d0v0 HSR=0x80000086 pc=0xffff000c gva=0xffff000c gpa=0x0000082000700c (XEN) traps.c:1980:d0v0 HSR=0x80000086 pc=0xffff000c gva=0xffff000c gpa=0x0000082000700c ... last line loops indefinitely On Mon, Jun 1, 2020 at 11:21 AM CodeWiz2280 wrote: > Hi Julien, > > Thank you for your response. I will try and post a log for you. I have > been switching back and forth between configurations and need to take a new > one. > > The board has 4GB of memory. Uboot places the kernel/initramfs/dtb in the > 0x8000_0000 region but then the kernel switches its code/data over to a > 0x8_0000_0000 range via the pv-fixup-asm.S assembly code called from > early_paging_init in arch/arm/mm/mmu.c. That code is exclusive to the > keystone in the 4.19 kernel when "CONFIG_ARM_PV_FIXUP" and "ARM_LPAE" are > enabled in the kernel . The upper 2GB of memory is above 0xFFFF_FFFF so > LPAE is required. > > /proc/iomem looks like this without running xen after the switch and the > kernel boots: > > 80000000 - 9fffffff : System RAM (boot alias) > c8000000 - ffffffff : System RAM (boot alias) > 800000000 - 1fffffff : System RAM > 800008000-800dfffff : Kernel Code > 801000000-80108ab3f : Kernel data > 848000000-8ffffffff : System RAM > > I was able to duplicate this issue with a build of your latest "master" > repository from this morning. > > On Mon, Jun 1, 2020 at 9:29 AM Julien Grall wrote: > >> Hello, >> >> I have a few questions in order to understand a bit more your problem. >> >> On 01/06/2020 13:38, CodeWiz2280 wrote: >> > Hello, I am using a Texas Instruments K2E Keystone Eval board with >> Linux >> > 4.19.59. It has a 32-bit ARM Cortex A15 processor. There is keystone >> > specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that executes >> > during early_paging_init for LPAE support. This causes the kernel to >> > switch its running 32-bit address space to a 36-bit address space and >> > the hypervisor traps repeatedly and stops it from booting. >> >> Without any log it is going to be difficult to help. Could you post the >> hypervisor log when debug is enabled? >> >> > I suspect >> > this is because Xen only allowed for the original 32-bit memory range >> > specified by the dom0 device tree. >> >> How much RAM did you give to your Dom0? >> >> > The 36-bit LPAE address is a fixed >> > offset from the 32-bit address and is not physically different memory. >> >> I am not sure to understand this. Are you suggesting that the kernel is >> trying to relocate itself in a different part of the physical memory? >> >> Can you provide more details on the fixed offset? >> >> > >> > Can you suggest any way to get through this problem? I am using the >> > master branch of xen from earlier this year. >> >> Can you provide the exact baseline your are using? Did make any changes >> on top? >> >> > Any help is greatly >> > appreciated. >> Best regards, >> >> -- >> Julien Grall >> > --00000000000042c39105a709453e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Julien,

As requested please see log below from the eval board boot= ing dom0, some notes are as follows:

1. The offset= that gets applied to the 32-bit address to translate it to=C2=A036-bits is= 0x7_8000_0000
2. Uboot has been setup to not change the address = of the memory in the device tree prior to launching xen, otherwise it would= automatically=C2=A0offset it and=C2=A0replace it with a=C2=A036-bit addres= s=C2=A0and xen would immediately panic at the 36-bit address for a 32-bit p= rocessor.
3. The RAM starting address placed in the device tree i= s 0x8000_0000, which gets carved up by=C2=A0xen and replaced with 0xA000_00= 00 prior to booting dom0..=C2=A0 I had to put in test code to have the kern= el offset the 0xA000_0000 32-bit starting address to the 36-bit address nee= ded before the kernel will attempt to switch.=C2=A0 If it stays 32-bit then= it will not switch over the address space.=C2=A0 Note that without xen in = play uboot would normally replace the address in the device tree with the 3= 6-bit one.
4.=C2=A0The dom0 kernel will boot from xen=C2=A0if the= early_paging_init switch step is skipped, and the low mem stays in 32-bit.= ...but there is a problem with the peripherals so this is not an acceptable= solution.

It seems that either the kernel would n= eed some API to tell xen that there is going to be a change in the memory i= ts using prior to call early_paging_init(), or Xen would need to add the ad= ditional 36-bit addresses during the memory bank allocation step....but rec= ognize that they are not actually different physical memory but just aliase= d to a different address.

Thanks,
Dave

=C2=A0Xen 4.14-unstable
(XEN) Xen version 4.= 14-unstable (arm-linux-gnueabihf-gcc (Linaro GCC 4.9-2015.05) 4.9.3 2015041= 3 (prerelease)) debug=3Dy=C2=A0 Mon Jun=C2=A0 1 10:22:11 EDT 2020
(XEN) = Latest ChangeSet:
(XEN) build-id: 30ae91a06c71a885cfba2788965144999a8646= 14
(XEN) Console output is synchronous.
(XEN) Processor: 412fc0f4: &q= uot;ARM Limited", variant: 0x2, part 0xc0f, rev 0x4
(XEN) 32-bit Ex= ecution:
(XEN)=C2=A0=C2=A0 Processor Features: 00001131:00011011
(XEN= )=C2=A0=C2=A0=C2=A0=C2=A0 Instruction Sets: AArch32 A32 Thumb Thumb-2 Thumb= EE Jazelle
(XEN)=C2=A0=C2=A0=C2=A0=C2=A0 Extensions: GenericTimer Securi= ty
(XEN)=C2=A0=C2=A0 Debug Features: 02010555
(XEN)=C2=A0=C2=A0 Auxil= iary Features: 00000000
(XEN)=C2=A0=C2=A0 Memory Model Features: 1020110= 5 20000000 01240000 02102211
(XEN)=C2=A0 ISA Features: 02101110 13112111= 21232041 11112131 10011142 00000000
(XEN) Using SMC Calling Convention = v1.0
(XEN) Using PSCI v0.1
(XEN) SMP: Allowing 4 CPUs
(XEN) Generi= c Timer IRQ: phys=3D30 hyp=3D26 virt=3D27 Freq: 208333 KHz
(XEN) GICv2 i= nitialization:
(XEN)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gic= _dist_addr=3D0000000002561000
(XEN)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 gic_cpu_addr=3D0000000002562000
(XEN)=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 gic_hyp_addr=3D0000000002564000
(XEN)=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gic_vcpu_addr=3D0000000002566000=
(XEN)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gic_maintenance_i= rq=3D25
(XEN) Using the new VGIC implementation.
(XEN) GICv2: 512 lin= es, 4 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Sch= eduler rev2 (credit2)
(XEN) Initializing Credit2 scheduler
(XEN)=C2= =A0 load_precision_shift: 18
(XEN)=C2=A0 load_window_shift: 30
(XEN)= =C2=A0 underload_balance_tolerance: 0
(XEN)=C2=A0 overload_balance_toler= ance: -3
(XEN)=C2=A0 runqueues arrangement: socket
(XEN)=C2=A0 cap en= forcement granularity: 10ms
(XEN) load tracking window length 1073741824= ns
(XEN) Allocated console ring of 32 KiB.
(XEN) VFP implementer 0x4= 1 architecture 4 part 0x30 variant 0xf rev 0x0
(XEN) CPU0: Guest atomics= will try 2 times before pausing the domain
(XEN) Bringing up CPU1
(X= EN) CPU1: Guest atomics will try 1 times before pausing the domain
(XEN)= CPU 1 booted.
(XEN) Bringing up CPU2
(XEN) CPU2: Guest atomics will = try 1 times before pausing the domain
(XEN) CPU 2 booted.
(XEN) Bring= ing up CPU3
(XEN) CPU3: Guest atomics will try 1 times before pausing th= e domain
(XEN) CPU 3 booted.
(XEN) Brought up 4 CPUs
(XEN) I/O vir= tualisation disabled
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with o= rder-1 root, VTCR 0x80003558
(XEN) Scheduling granularity: cpu, 1 CPU pe= r sched-resource
(XEN) Adding cpu 0 to runqueue 0
(XEN)=C2=A0 First c= pu on runqueue, activating
(XEN) Adding cpu 1 to runqueue 0
(XEN) Add= ing cpu 2 to runqueue 0
(XEN) Adding cpu 3 to runqueue 0
(XEN) altern= atives: Patching with alt table 002c2530 -> 002c2578
(XEN) *** LOADIN= G DOMAIN 0 ***
(XEN) Loading d0 kernel from boot module @ 00000000830000= 00
(XEN) Loading ramdisk from boot module @ 0000000088000000
(XEN) Al= locating 1:1 mappings totalling 1024MB for dom0:
(XEN) BANK[0] 0x000000a= 0000000-0x000000e0000000 (1024MB)
(XEN) Grant table range: 0x00000082000= 000-0x00000082040000
(XEN) Allocating PPI 16 for event channel interrupt=
(XEN) Loading zImage from 0000000083000000 to 00000000a7a00000-00000000= a7f36100
(XEN) Loading d0 initrd from 0000000088000000 to 0x00000000a820= 0000-0x00000000abe00000
(XEN) Loading d0 DTB to 0x00000000a8000000-0x000= 00000a8007872
(XEN) Initial low memory virq threshold set at 0x4000 page= s.
(XEN) Scrubbing Free RAM in background
(XEN) Std. Loglevel: All(XEN) Guest Loglevel: All
(XEN) ***************************************= ************
(XEN) WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) This = option is intended to aid debugging of Xen by ensuring
(XEN) that all ou= tput is synchronously delivered on the serial line.
(XEN) However it can= introduce SIGNIFICANT latencies and affect
(XEN) timekeeping. It is NOT= recommended for production use!
(XEN) *********************************= ******************
(XEN) WARNING: SILO mode is not enabled.
(XEN) It = has implications on the security of the system,
(XEN) unless the communi= cations have been forbidden between
(XEN) untrusted domains.
(XEN) **= *************************************************
(XEN) 3... 2... 1...(XEN) *** Serial input to DOM0 (type 'CTRL-a' three times to swit= ch input)
(XEN) Freed 328kB init memory.
(XEN) DOM0: [=C2=A0=C2=A0=C2= =A0 0.000000] Booting Linux on physical CPU 0x0
(XEN) DOM0: [=C2=A0=C2= =A0=C2=A0 0.000000] Linux version 4.19.59-g5f8c1c6121 (gcc version 8.3.0 (G= NU Toolchain for the A-profile A
(XEN) DOM0: rchitecture 8.3-2019.03 (ar= m-rel-8.36))) #52 SMP Mon Jun 1 12:13:51 EDT 2020
(XEN) DOM0: [=C2=A0=C2= =A0=C2=A0 0.000000] CPU: ARMv7 Processor [412fc0f4] revision 4 (ARMv7), cr= =3D30c5387d
(XEN) DOM0: [=C2=A0=C2=A0=C2=A0 0.000000] CPU: div instructi= ons available: patching division code
(XEN) DOM0: [=C2=A0=C2=A0=C2=A0 0.= 000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
= (XEN) DOM0: [=C2=A0=C2=A0=C2=A0 0.000000] OF: fdt: Machine model: Texas Ins= truments Keystone 2 Edison EVM
(XEN) DOM0: [=C2=A0=C2=A0=C2=A0 0.000000]= bootconsole [earlycon0] enabled
(XEN) DOM0: [=C2=A0=C2=A0=C2=A0 0.00000= 0] debug: ignoring loglevel setting.
(XEN) DOM0: [=C2=A0=C2=A0=C2=A0 0.0= 00000] Memory policy: Data cache writealloc
(XEN) DOM0: [=C2=A0=C2=A0=C2= =A0 0.000000] test : mem_start from dtb =3D 0xa0000000
(XEN) DOM0: [=C2= =A0=C2=A0=C2=A0 0.000000] test : force the mem_start =3D 0x800000000
(XE= N) DOM0: [=C2=A0=C2=A0=C2=A0 0.000000] test : note KEYSTONE_LOW_PHYS_START = =3D 80000000, KEYSTONE_LOW_PHYS_END =3D ffffffff
(XEN) DOM0: [=C2=A0=C2= =A0=C2=A0 0.000000] test : note KEYSTONE_HIGH_PHYS_START =3D 800000000, KEY= STONE_HIGH_PHYS_END =3D bffffffff
(XEN) DOM0: [=C2=A0=C2=A0=C2=A0 0.0000= 00] test : Switch physical address space to 0x820000000 (0xa0000000 + 0x780= 000000)
(XEN) DOM0: [=C2=A0=C2=A0=C2=A0 0.000000] test : inside of early= _paging_init()
(XEN) traps.c:1980:d0v0 HSR=3D0x80000086 pc=3D0xa020010c = gva=3D0xa020010c gpa=3D0x0000082000310c
(XEN) traps.c:1980:d0v0 HSR=3D0x= 80000086 pc=3D0xffff000c gva=3D0xffff000c gpa=3D0x0000082000700c
(XEN) t= raps.c:1980:d0v0 HSR=3D0x80000086 pc=3D0xffff000c gva=3D0xffff000c gpa=3D0x= 0000082000700c
... last line loops indefinitely
<= br>


On Mon, Jun 1, 2020 at 11:21 AM CodeWiz= 2280 <codewiz2280@gmail.com= > wrote:
Hi Julien,

Thank you for your response.=C2=A0 I will try and post= a log for you.=C2=A0 I have been switching back and forth between configur= ations and need to take a new one.

The board has 4= GB of memory. Uboot places the kernel/initramfs/dtb in the 0x8000_0000 regi= on but then the kernel switches its code/data over to a 0x8_0000_0000 range= via the pv-fixup-asm.S assembly code called from early_paging_init in arch= /arm/mm/mmu.c.=C2=A0 That code is exclusive to the keystone in the 4.19 ker= nel when "CONFIG_ARM_PV_FIXUP" and "ARM_LPAE" are enabl= ed in the kernel .=C2=A0 The upper 2GB of memory is above 0xFFFF_FFFF so LP= AE is required.=C2=A0

/proc/iomem looks like this = without running xen after the switch and the kernel boots:

80000000 - 9fffffff : System RAM (boot alias)
c8000000 -= ffffffff : System RAM (boot alias)
800000000 - 1fffffff : System= RAM
=C2=A0 =C2=A0 800008000-800dfffff : Kernel Code
= =C2=A0 =C2=A0 801000000-80108ab3f : Kernel data
848000000-8ffffff= ff : System RAM

I was able to duplicate this issue= with a build of your latest "master" repository from this mornin= g.

On Mon, Jun 1, 2020 at 9:29 AM Julien Grall <julien@xen.org> wrote:
Hello,

I have a few questions in order to understand a bit more your problem.

On 01/06/2020 13:38, CodeWiz2280 wrote:
> Hello, I am using a Texas Instruments K2E Keystone Eval board with Lin= ux
> 4.19.59.=C2=A0 It has a 32-bit ARM Cortex A15 processor. There is keys= tone
> specific code in the kernel in arch/arm/mm/pv-fixup-asm.s that execute= s
> during early_paging_init for LPAE support.=C2=A0 This causes the kerne= l to
> switch its running 32-bit address space to a 36-bit address space and =
> the hypervisor traps repeatedly and stops it from booting.

Without any log it is going to be difficult to help. Could you post the hypervisor log when debug is enabled?

>=C2=A0 I suspect
> this is because Xen only allowed for the original 32-bit memory range =
> specified by the dom0 device tree.

How much RAM did you give to your Dom0?

> The 36-bit LPAE address is a fixed
> offset from the 32-bit address and is not physically different memory.=

I am not sure to understand this. Are you suggesting that the kernel is trying to relocate itself in a different part of the physical memory?

Can you provide more details on the fixed offset?

>=C2=A0
> Can you suggest any way to get through this problem? I am using the > master branch of xen from earlier this year.=C2=A0

Can you provide the exact baseline your are using? Did make any changes on top?

> Any help is greatly
> appreciated.
Best regards,

--
Julien Grall
--00000000000042c39105a709453e-- From xen-devel-bounces@lists.xenproject.org Mon Jun 01 18:38:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 18:38:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfpKJ-0004rH-D3; Mon, 01 Jun 2020 18:38:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfpKH-0004rB-Vn for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 18:38:22 +0000 X-Inumbo-ID: 1133df64-a437-11ea-81bc-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1133df64-a437-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 18:38:21 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id n24so10191354ejd.0 for ; Mon, 01 Jun 2020 11:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ov6fhPMmTH34xS76zlZ27NhyD4IBg5jtrp6M3BzaGrU=; b=JLdyvDW5kgg6gDJewwUSQmhaVi8jS75aUFKXMb1T2B6Nr4ZbhaCjmcJLaAkXhF6b8K 35ceAfJGnuDJDbPKTR2+3iSEGqSE61uCRbybxeXR8w0e+q/rT9E3sOZxyXvclHNE/ty2 K+MjuAsRbDD+AZaLNGMXVparwICKyvy0fZ5uvhBqVEWlsKKZ/So3Emo96sde3snPAy55 aiSdOjS9trKCPbFiuguZlxteJdtoTVpskLQIjumHDhOqpPRbqmjkj5IakM8ADKBRJG87 h7TLOxsxrLFpoF3JY53Qq8YmDo1/vQ9ZcEUTTMJEE85xeUR8miSJesyUFLmX4uTTkkDg h1bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ov6fhPMmTH34xS76zlZ27NhyD4IBg5jtrp6M3BzaGrU=; b=GBIjFPflhMU0PXyGG/Tf7KoFZDeWVj5zJxt6yhDFteZAhNVLQCspwCWu9UiqBDTf+2 8PyDEqGw/tsiZwQb4nU3dlnRyPhGIH7h1yPdZ+dGiY4Dc46dP4RCNpYre/ejJ8RlCbA3 rDxaq1Lck0pJqp3nClUXjiL2R1izC0czXcm6t/4zIO+Rl9jz3wRyHz3Gm6O7WPufLCZV TxTBDhnza59H3t5TAF3BzXu6gw0oArsLyw2bFTcl9kdZqbuiOhT+tIq6LsC6WZLf4JNm UYt7ohZRiJobTc5UC9Ia7mzJUrCn9D4VHxTsYSADAwJSuTIbbTWMBnkf35DZaU3LiZgW KnGg== X-Gm-Message-State: AOAM532TxCuJQJxaUhP9Qh+Gb0Xpp+mPVgXoAiVh/xIn5MLEidD+FTzC WOFi/LY4sT4aRclv9HonUrTQ+BY6GGU= X-Google-Smtp-Source: ABdhPJy8pYOY6hYDlYOTEFeCLIfgKCrOAB6NhtEnRkQByc/D4C+bquZcvba9INRsLFRRDwVW4Ywlyg== X-Received: by 2002:a17:906:f6d6:: with SMTP id jo22mr19773216ejb.310.1591036699942; Mon, 01 Jun 2020 11:38:19 -0700 (PDT) Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com. [209.85.128.48]) by smtp.gmail.com with ESMTPSA id b21sm115905edt.15.2020.06.01.11.38.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 11:38:19 -0700 (PDT) Received: by mail-wm1-f48.google.com with SMTP id g10so474032wmh.4 for ; Mon, 01 Jun 2020 11:38:18 -0700 (PDT) X-Received: by 2002:a1c:23d2:: with SMTP id j201mr567836wmj.186.1591036698346; Mon, 01 Jun 2020 11:38:18 -0700 (PDT) MIME-Version: 1.0 References: <000c01d63826$6d125900$47370b00$@xen.org> <4017F2B3-BB9B-4E9F-813C-6FE68BA0D568@citrix.com> In-Reply-To: <4017F2B3-BB9B-4E9F-813C-6FE68BA0D568@citrix.com> From: Tamas K Lengyel Date: Mon, 1 Jun 2020 12:37:42 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v19 for-4.14 00/13] VM forking To: George Dunlap Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Kevin Tian , Stefano Stabellini , Tamas K Lengyel , Jan Beulich , Wei Liu , "paul@xen.org" , Andrew Cooper , Jun Nakajima , Ian Jackson , Anthony Perard , xen-devel , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 1, 2020 at 11:11 AM George Dunlap wr= ote: > > > > > On Jun 1, 2020, at 4:07 PM, Paul Durrant wrote: > > > >> -----Original Message----- > >> From: Xen-devel On Behalf Of = Tamas K Lengyel > >> Sent: 01 June 2020 14:22 > >> To: xen-devel@lists.xenproject.org > >> Cc: Kevin Tian ; Stefano Stabellini ; Tamas K Lengyel > >> ; Jun Nakajima ; Wei = Liu ; Andrew Cooper > >> ; Ian Jackson ; = George Dunlap > >> ; Tamas K Lengyel ; Jan= Beulich ; > >> Anthony PERARD ; Julien Grall ; Roger Pau Monn=C3=A9 > >> > >> Subject: [PATCH v19 for-4.14 00/13] VM forking > > > > Hi, > > > > This series looks to be largely un-acked so, since we are now past the= freeze date, I don't really think it can go into 4.14. Is there a particul= ar reason that you think it should be considered? > > Tamas=E2=80=99 project itself mainly uses libxc and below, as I understan= d; and so getting patches 1 and 2 in would be an important milestone; both = have had R-b=E2=80=99s before the feature freeze. Arguably patches 1 and 2= are a bug fix. Patch 1 is missing VMX (or a general x86). Correct. The first two patches going in would decide whether we will be able to use the 4.14 release without having to carry out-of-tree patches. Although as things stand at the moment regarding all the bugs being discovered in 4.13 and 4.14 we will likely still have to backport all of these patches to 4.12 by hand. > The libxl/xl side hasn=E2=80=99t, as I understand it, had significant rev= iew; I think that should probably wait until 4.15. Correct. It has been sent 19 times so far over a period of 9 months with no feedback from any of the maintainers other then that it's hard to review. We had some good discussion with other community members but evidently non of the toolstack maintainers care too much about it. I made the last-ditch effort to make it easier to review but at this point we started implementing our own toolstack to interact with VM forks. > What do you think, Tamas? If it's not going into 4.14 then it's going to be dropped. It has been made solely for the benefit of the community to make the new VM forking more accessible and useful for others. Without it the only way to use the feature is to implement your own toolstack. Initially we were hoping that integrating support to xl/libxl would eliminate the need for us to implement our own parallel toolstack but since we have to do that now anyway there is no benefit for us in carrying these patches any further. It's disheartening we had to resort to that and I certainly will try to avoid contributing to xl/libxl in the future since I personally consider it a waste of time. Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Mon Jun 01 18:59:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 18:59:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfpee-0006fs-6V; Mon, 01 Jun 2020 18:59:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfped-0006fn-46 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 18:59:23 +0000 X-Inumbo-ID: 00ec4d50-a43a-11ea-9dbe-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 00ec4d50-a43a-11ea-9dbe-bc764e2007e4; Mon, 01 Jun 2020 18:59:22 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id q19so4935702eja.7 for ; Mon, 01 Jun 2020 11:59:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S8Sc2b5ExnekXJv0JL3UL1F7c6say8fYme38PNg24Bg=; b=RPuea2EPsF4h/E9hvYiy0mua6WNck5xorxCAq4GF0WkSV95NKom1ILZxZvwSp47C2N zMl8Gz4CYD9mLRz+hFeyoYnZXDbOn4jfUABKRlQ8kPs3btSfjVDY9eGuhfFyFZRLrO8c HNl21qDUPT/kKYXgP0un03za/qwmEAJUXexhahKmN5QRdasMdb9uxzUChrK+jERW6LMh Awjjck/sG4pZ/CghB2Po7H248KhqYX391E5K0Kz1qLPTva8KrXVVRv/NPEuFdUmLWBg9 zkocX0YNoj36HMAdF9ytLTu88upa7ub38rB3u+EmActadngVdWeWrSVItXnMOAm+m+uJ q1PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S8Sc2b5ExnekXJv0JL3UL1F7c6say8fYme38PNg24Bg=; b=bNbifVAKKnn1Z5L9GVY2YRxVp7J6y40KPzYUmN3eo7KPRButsiEWVzDuIEqYNUrOyp qDpYCvZ5JugHQsXL7J5XCsfiTMEtCQCRREHcX/KwEtgcafiLH0n57q2zb2n3EPog3OlL 8CtIWDCOpd3PNeiWl1qhj7zgdyK0t/Ls8rxnacknDfYm8tH5LG7oNegOpn7KKyM9aLqO zad5G4tjmv7B7pS8cWlbvL6jmwiTFjrGqwAHu0DJ+REwATgtytFwYCZyIcuMWIfHNOie nYdrBFy5QIBJNlNns3cYhQtX+QuCO0wHtvX4kaDWlrhsM9c4Pd1cr/tJMcu6UzKzq0TV NNnQ== X-Gm-Message-State: AOAM533mawF426xF8I7z3S+yxboTzZymmOPqRplP7OWDDJ+sd7/LNOaN NGYK0RmPSNCKFvJBw0hC3ZX6t9X4z2s= X-Google-Smtp-Source: ABdhPJzdgXqjcJBxXCJ/UGnKl8OzXCjlP/hjNDx2mihjGi5UyiswoycgUexCkXMAar+R71h7mUw25w== X-Received: by 2002:a17:907:2486:: with SMTP id zg6mr21225542ejb.225.1591037960653; Mon, 01 Jun 2020 11:59:20 -0700 (PDT) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com. [209.85.221.50]) by smtp.gmail.com with ESMTPSA id 64sm148219eda.85.2020.06.01.11.59.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 11:59:19 -0700 (PDT) Received: by mail-wr1-f50.google.com with SMTP id l10so876595wrr.10 for ; Mon, 01 Jun 2020 11:59:19 -0700 (PDT) X-Received: by 2002:a5d:490f:: with SMTP id x15mr22795038wrq.259.1591037959312; Mon, 01 Jun 2020 11:59:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tamas K Lengyel Date: Mon, 1 Jun 2020 12:58:44 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 for-4.14 0/3] vm_event: fix race-condition when disabling monitor events To: Xen-devel Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, May 20, 2020 at 8:31 PM Tamas K Lengyel wrote: > > For the last couple years we have received numerous reports from users of > monitor vm_events of spurious guest crashes when using events. In particular, > it has observed that the problem occurs when vm_events are being disabled. The > nature of the guest crash varied widely and has only occured occasionally. This > made debugging the issue particularly hard. We had discussions about this issue > even here on the xen-devel mailinglist with no luck figuring it out. > > The bug has now been identified as a race-condition between register event > handling and disabling the vm_event interface. > > Patch 96760e2fba100d694300a81baddb5740e0f8c0ee, "vm_event: deny register writes > if refused by vm_event reply" is the patch that introduced the error. In this > patch emulation of register write events can be postponed until the > corresponding vm_event handler decides whether to allow such write to take > place. Unfortunately this can only be implemented by performing the deny/allow > step when the vCPU gets scheduled. Due to that postponed emulation of the event > if the user decides to pause the VM in the vm_event handler and then disable > events, the entire emulation step is skipped the next time the vCPU is resumed. > Even if the user doesn't pause during the vm_event handling but exits > immediately and disables vm_event, the situation becomes racey as disabling > vm_event may succeed before the guest's vCPUs get scheduled with the pending > emulation task. This has been particularly the case with VMS that have several > vCPUs as after the VM is unpaused it may actually take a long time before all > vCPUs get scheduled. > > The only solution currently is to poll each vCPU before vm_events are disabled > to verify they had been scheduled before it is safe to disable vm_events. The > following patches resolve this issue in a much nicer way. > > Patch 1 adds an option to the monitor_op domctl that needs to be specified if > the user wants to actually use the postponed register-write handling > mechanism. If that option is not specified then handling is performed the > same way as before patch 96760e2fba100d694300a81baddb5740e0f8c0ee. > > Patch 2 performs sanity checking when disabling vm_events to determine whether > its safe to free all vm_event structures. The vCPUs still get unpaused to > allow them to get scheduled and perform any of their pending operations, > but otherwise an -EAGAIN error is returned signaling to the user that they > need to wait and try again disabling the interface. > > Patch 3 adds a vm_event specifically to signal to the user when it is safe to > continue disabling the interface. > > Shout out to our friends at CERT.pl for stumbling upon a crucial piece of > information that lead to finally squashing this nasty bug. > > v2: minor adjustments based on Jan's comments Patch ping. Tamas From xen-devel-bounces@lists.xenproject.org Mon Jun 01 19:16:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 19:16:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfpub-0008RN-Ko; Mon, 01 Jun 2020 19:15:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfpua-0008RI-FI for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 19:15:52 +0000 X-Inumbo-ID: 4c4b873d-a43c-11ea-ab4c-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4c4b873d-a43c-11ea-ab4c-12813bfff9fa; Mon, 01 Jun 2020 19:15:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6AQUE0tUZ2I4RFIU7ygf6ZucxoYQhwPJPh8reQa9Egc=; b=ClH3Libi8oGa3NWtiDlYwkUPj b/OTqhcDxF0RIMjN7bL8AEmWt8WQnJM/fw5GF6Poej1HOufOHZgaRKd6Q+Z9muGjTpFunw1Y686Fd Wyu/0jck+5ddhcyXMdLvkHLWNmm/p8ZMU32FcCsc9F1V3Zo5SlBG9KJyJ0OLbnJJ+DlpA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfpuW-0001ae-9d; Mon, 01 Jun 2020 19:15:48 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfpuW-0002bO-0F; Mon, 01 Jun 2020 19:15:48 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfpuV-0003Wg-Vs; Mon, 01 Jun 2020 19:15:47 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150590: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore.2:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 X-Osstest-Versions-That: linux=ffeb595d84811dde16a28b33d8a7cf26d51d51b3 From: osstest service owner Date: Mon, 01 Jun 2020 19:15:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150590 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150590/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 150556 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail blocked in 150556 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150556 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150556 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150556 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150556 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150556 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150556 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150556 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150556 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: linux 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 baseline version: linux ffeb595d84811dde16a28b33d8a7cf26d51d51b3 Last test of basis 150556 2020-05-31 04:53:49 Z 1 days Failing since 150579 2020-05-31 18:08:42 Z 1 days 2 attempts Testing same since 150590 2020-06-01 02:00:27 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Al Viro Alexander Dahl Alexander Potapenko Alexei Starovoitov Andy Lutomirski Antony Antony Arnd Bergmann Aya Levin Björn Töpel Bjørn Mork Borislav Petkov Chris Lew Chris Packham Chuhong Yuan Cong Wang Daniel Borkmann Daniele Palmas David Ahern David S. Miller Davide Caratti Dexuan Cui Edwin Peer Eric Dumazet Fugang Duan Guillaume Nault Hangbin Liu Heinrich Kuhn Ingo Molnar Jay Lang Jay Vosburgh Jens Axboe Jia He Joe Perches Johannes Berg John Fastabend Jonas Falkevik Jonathan Lemon KP Singh Linus Lüssing Linus Torvalds Maor Dickman Marcelo Ricardo Leitner Mark Bloch Michael Braun Michael Chan Michael Ellerman Nathan Chancellor Nicolas Dichtel Nikolay Aleksandrov Pablo Neira Ayuso Paolo Abeni Peter Zijlstra Petr Mladek Phil Sutter Pradeep Kumar Chitrapu Qiushi Wu Roi Dayan Sabrina Dubroca Saeed Mahameed Simon Horman Stefano Garzarella Steffen Klassert Tal Gilboa Thomas Falcon Thomas Gleixner Vasundhara Volam Vinay Kumar Yadav Vlad Buslov Vladimir Oltean wenxu Willem de Bruijn Xin Long Yang Yingliang Yonghong Song jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git ffeb595d8481..3d77e6a8804a 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Mon Jun 01 20:47:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 20:47:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrKi-0007vI-QC; Mon, 01 Jun 2020 20:46:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrKh-0007vC-Jz for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 20:46:55 +0000 X-Inumbo-ID: 06a1e41c-a449-11ea-8993-bc764e2007e4 Received: from smtp-fw-9101.amazon.com (unknown [207.171.184.25]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 06a1e41c-a449-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 20:46:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591044415; x=1622580415; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=ZLQRMmjXeZ9LXwaaepYqyU0oq/QACExlx8fvTsISthA=; b=IBNbw6Y7aKVQzhbI2KorETSrm9zjm5H9j3fCY+IKvuFemRFb5AR7F1JG aff1aM79Yb2J9M03JBuf8e29P0RhT5CZyR3XA7KDebLUa9SWnwJ8azZqG Yd3p6IrZC/R651xcmPCB5aAL7lqoUtuqs0jANo+66X+XjspTIxEh8jxT0 g=; IronPort-SDR: xSAj6NUQuk1GI9XJvErr6FXDs1ApEMIJue3r2qVXTTl6oMfK95od4DorURWmH7QD72BU14905Q DHYsHdE8q+hQ== X-IronPort-AV: E=Sophos;i="5.73,462,1583193600"; d="scan'208";a="40686768" Subject: Re: [PATCH 05/12] genirq: Shutdown irq chips in suspend/resume during hibernation Thread-Topic: [PATCH 05/12] genirq: Shutdown irq chips in suspend/resume during hibernation Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-d0be17ee.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 01 Jun 2020 20:46:52 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2a-d0be17ee.us-west-2.amazon.com (Postfix) with ESMTPS id E0136A26B4; Mon, 1 Jun 2020 20:46:49 +0000 (UTC) Received: from EX13D10UWB004.ant.amazon.com (10.43.161.121) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 20:46:49 +0000 Received: from EX13D07UWB001.ant.amazon.com (10.43.161.238) by EX13D10UWB004.ant.amazon.com (10.43.161.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 20:46:49 +0000 Received: from EX13D07UWB001.ant.amazon.com ([10.43.161.238]) by EX13D07UWB001.ant.amazon.com ([10.43.161.238]) with mapi id 15.00.1497.006; Mon, 1 Jun 2020 20:46:49 +0000 From: "Agarwal, Anchal" To: Boris Ostrovsky , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "hpa@zytor.com" , "x86@kernel.org" , "jgross@suse.com" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "Kamata, Munehisa" , "sstabellini@kernel.org" , "konrad.wilk@oracle.com" , "roger.pau@citrix.com" , "axboe@kernel.dk" , "davem@davemloft.net" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "peterz@infradead.org" , "Valentin, Eduardo" , "Singh, Balbir" , "xen-devel@lists.xenproject.org" , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Woodhouse, David" , "benh@kernel.crashing.org" Thread-Index: AQHWLjTy8XV/vbMfPkSkRneQeZchzKjBVJ6AgAKFKQA= Date: Mon, 1 Jun 2020 20:46:48 +0000 Message-ID: <86B7AA7D-F32A-47CA-B258-8456D02B3EE6@amazon.com> References: <0471e6e3-b6ed-d2c6-db41-1688a0af9abd@oracle.com> In-Reply-To: <0471e6e3-b6ed-d2c6-db41-1688a0af9abd@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.90] Content-Type: text/plain; charset="utf-8" Content-ID: <2E803394E47DA743B7734743B9ED83BC@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQrvu78gICAgQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0 aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1 bmxlc3MgeW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMg c2FmZS4NCg0KDQoNCiAgICBPbiA1LzE5LzIwIDc6MjYgUE0sIEFuY2hhbCBBZ2Fyd2FsIHdyb3Rl Og0KICAgID4gTWFueSBsZWdhY3kgZGV2aWNlIGRyaXZlcnMgZG8gbm90IGltcGxlbWVudCBwb3dl ciBtYW5hZ2VtZW50IChQTSkNCiAgICA+IGZ1bmN0aW9ucyB3aGljaCBtZWFucyB0aGF0IGludGVy cnVwdHMgcmVxdWVzdGVkIGJ5IHRoZXNlIGRyaXZlcnMgc3RheQ0KICAgID4gaW4gYWN0aXZlIHN0 YXRlIHdoZW4gdGhlIGtlcm5lbCBpcyBoaWJlcm5hdGVkLg0KICAgID4NCiAgICA+IFRoaXMgZG9l cyBub3QgbWF0dGVyIG9uIGJhcmUgbWV0YWwgYW5kIG9uIG1vc3QgaHlwZXJ2aXNvcnMgYmVjYXVz ZSB0aGUNCiAgICA+IGludGVycnVwdCBpcyByZXN0b3JlZCBvbiByZXN1bWUgd2l0aG91dCBhbnkg bm90aWNhYmxlIHNpZGUgZWZmZWN0cyBhcw0KICAgID4gaXQgc3RheXMgY29ubmVjdGVkIHRvIHRo ZSBzYW1lIHBoeXNpY2FsIG9yIHZpcnR1YWwgaW50ZXJydXB0IGxpbmUuDQogICAgPg0KICAgID4g VGhlIFhFTiBpbnRlcnJ1cHQgbWVjaGFuaXNtIGlzIGRpZmZlcmVudCBhcyBpdCBtYWludGFpbnMg YSBtYXBwaW5nDQogICAgPiBiZXR3ZWVuIHRoZSBMaW51eCBpbnRlcnJ1cHQgbnVtYmVyIGFuZCBh IFhFTiBldmVudCBjaGFubmVsLiBJZiB0aGUNCiAgICA+IGludGVycnVwdCBzdGF5cyBhY3RpdmUg b24gaGliZXJuYXRpb24gdGhpcyBtYXBwaW5nIGlzIHByZXNlcnZlZCBidXQNCiAgICA+IHRoZXJl IGlzIHVuZm9ydHVuYXRlbHkgbm8gZ3VhcmFudGVlIHRoYXQgb24gcmVzdW1lIHRoZSBzYW1lIGV2 ZW50DQogICAgPiBjaGFubmVscyBhcmUgcmVhc3NpZ25lZCB0byB0aGVzZSBkZXZpY2VzLiBUaGlz IGNhbiByZXN1bHQgaW4gZXZlbnQNCiAgICA+IGNoYW5uZWwgY29uZmxpY3RzIHdoaWNoIHByZXZl bnQgdGhlIGFmZmVjdGVkIGRldmljZXMgZnJvbSBiZWluZw0KICAgID4gcmVzdG9yZWQgY29ycmVj dGx5Lg0KICAgID4NCiAgICA+IE9uZSB3YXkgdG8gc29sdmUgdGhpcyB3b3VsZCBiZSB0byBhZGQg dGhlIG5lY2Vzc2FyeSBwb3dlciBtYW5hZ2VtZW50DQogICAgPiBmdW5jdGlvbnMgdG8gYWxsIGFm ZmVjdGVkIGxlZ2FjeSBkZXZpY2UgZHJpdmVycywgYnV0IHRoYXQncyBhDQogICAgPiBxdWVzdGlv bmFibGUgZWZmb3J0IHdoaWNoIGRvZXMgbm90IHByb3ZpZGUgYW55IGJlbmVmaXRzIG9uIG5vbi1Y RU4NCiAgICA+IGVudmlyb25tZW50cy4NCiAgICA+DQogICAgPiBUaGUgbGVhc3QgaW50cnVzaXZl IGFuZCBtb3N0IGVmZmljaWVudCBzb2x1dGlvbiBpcyB0byBwcm92aWRlIGENCiAgICA+IG1lY2hh bmlzbSB3aGljaCBhbGxvd3MgdGhlIGNvcmUgaW50ZXJydXB0IGNvZGUgdG8gdGVhciBkb3duIHRo ZXNlDQogICAgPiBpbnRlcnJ1cHRzIG9uIGhpYmVybmF0aW9uIGFuZCBicmluZyB0aGVtIGJhY2sg dXAgYWdhaW4gb24gcmVzdW1lLiBUaGlzDQogICAgPiBhbGxvd3MgdGhlIFhFTiBldmVudCBjaGFu bmVsIG1lY2hhbmlzbSB0byBhc3NpZ24gYW4gYXJiaXRyYXJ5IGV2ZW50DQogICAgPiBjaGFubmVs IG9uIHJlc3VtZSB3aXRob3V0IGFmZmVjdGluZyB0aGUgZnVuY3Rpb25hbGl0eSBvZiB0aGVzZQ0K ICAgID4gZGV2aWNlcy4NCiAgICA+DQogICAgPiBGb3J0dW5hdGVseSBhbGwgdGhlc2UgZGV2aWNl IGludGVycnVwdHMgYXJlIGhhbmRsZWQgYnkgYSBkZWRpY2F0ZWQgWEVODQogICAgPiBpbnRlcnJ1 cHQgY2hpcCBzbyB0aGUgY2hpcCBjYW4gYmUgbWFya2VkIHRoYXQgYWxsIGludGVycnVwdHMgY29u bmVjdGVkDQogICAgPiB0byBpdCBhcmUgaGFuZGxlZCB0aGlzIHdheS4gVGhpcyBpcyBwcmV0dHkg bXVjaCBpbiBsaW5lIHdpdGggdGhlIG90aGVyDQogICAgPiBpbnRlcnJ1cHQgY2hpcCBzcGVjaWZp YyBxdWlya3MsIGUuZy4gSVJRQ0hJUF9NQVNLX09OX1NVU1BFTkQuDQogICAgPg0KICAgID4gQWRk IGEgbmV3IHF1aXJrIGZsYWcgSVJRQ0hJUF9TSFVURE9XTl9PTl9TVVNQRU5EIGFuZCBhZGQgc3Vw cG9ydCBmb3INCiAgICA+IGl0IHRoZSBjb3JlIGludGVycnVwdCBzdXNwZW5kL3Jlc3VtZSBwYXRo cy4NCiAgICA+DQogICAgPiBTaWduZWQtb2ZmLWJ5OiBBbmNoYWwgQWdhcndhbCA8YW5jaGFsYWdA YW1hem9uLmNvbT4NCiAgICA+IFNpZ25lZC1vZmYtLWJ5OiBUaG9tYXMgR2xlaXhuZXIgPHRnbHhA bGludXRyb25peC5kZT4NCg0KDQogICAgU2luY2UgVGhvbWFzIHdyb3RlIHRoaXMgcGF0Y2ggSSB0 aGluayBpdCBzaG91bGQgYWxzbyBoYXZlICJGcm9tOiAiIGhpbS4NCg0KVGhhdCBzb3VuZHMgYWJv dXQgcmlnaHQuIEkgd2lsbCB1cGRhdGUgaXQgbmV4dCByb3VuZCBhbmQgYWRkIFRlc3RlZC1ieS4N Cg0KICAgIC1ib3Jpcw0KDQotIEFuY2hhbA0KDQoNCg0K From xen-devel-bounces@lists.xenproject.org Mon Jun 01 20:57:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 20:57:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrUZ-0000RG-NG; Mon, 01 Jun 2020 20:57:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrUY-0000R8-FF for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 20:57:06 +0000 X-Inumbo-ID: 7267b31a-a44a-11ea-ab5a-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7267b31a-a44a-11ea-ab5a-12813bfff9fa; Mon, 01 Jun 2020 20:57:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xu9kx/Y/RWGy7LJuV0DCKJl4ZVP8YrAItfNllwGS2RA=; b=LEr2b8mgfgw+LF8dGozypBK19 sUSb+lfs9ACyGRs+zeShzwvTwriOnXN9qED9W9bQBGlAeqbiG5h0g5e+0nfXIJWHTQc4VJtoJINTK FQYGWYhK7MtC6RqMPckRtZY1yZUNCIvLjzZUEPgpz5Ih2cI7QMBuEVBxNGX9Wip+wylII=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrUV-0003ic-Qs; Mon, 01 Jun 2020 20:57:03 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfrUV-00015r-Hx; Mon, 01 Jun 2020 20:57:03 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfrUV-0004F4-H2; Mon, 01 Jun 2020 20:57:03 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150605: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ad33a573c009d72466432b41ba0591c64e819c19 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Mon, 01 Jun 2020 20:57:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150605 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150605/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen ad33a573c009d72466432b41ba0591c64e819c19 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 4 days Failing since 150465 2020-05-29 09:02:14 Z 3 days 31 attempts Testing same since 150515 2020-05-30 01:00:47 Z 2 days 21 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1196 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 21:00:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 21:00:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrXm-0001G7-3p; Mon, 01 Jun 2020 21:00:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrXk-0001G2-SY for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 21:00:24 +0000 X-Inumbo-ID: e8a41551-a44a-11ea-ab5b-12813bfff9fa Received: from smtp-fw-9101.amazon.com (unknown [207.171.184.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e8a41551-a44a-11ea-ab5b-12813bfff9fa; Mon, 01 Jun 2020 21:00:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591045225; x=1622581225; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=fEuvPWQ6mNxmTVIB4fqTSu3W/5TlhO+xWmDT2J2ohHQ=; b=rJhyrYOJ8eA47HrUsSOmGLvfJDltVGnKT6jKpF+gH6PfXkAkzPl6oYkg xFiWBZMOERts8g1HLmQ3No/WRyUd+5Ts+WwrO4OCjCPKYR/HhylOQ4ij3 62EmuAahW/hCU1hF4CMY4y77WE7OMm3UQ+Eq+uS3NxTe2xNQqgydyUJNg Q=; IronPort-SDR: WtI90cVJDGe5zcpw5pT/51BLBinCMfVLKX0OQSPdcY2u3K5rkd3R4wJTG/qwSRtUUaCusIRmae LfOE1m7vXruw== X-IronPort-AV: E=Sophos;i="5.73,462,1583193600"; d="scan'208";a="40694304" Subject: Re: [PATCH 01/12] xen/manage: keep track of the on-going suspend mode Thread-Topic: [PATCH 01/12] xen/manage: keep track of the on-going suspend mode Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-303d0b0e.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 01 Jun 2020 21:00:21 +0000 Received: from EX13MTAUWB001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-303d0b0e.us-east-1.amazon.com (Postfix) with ESMTPS id 66F69A2018; Mon, 1 Jun 2020 21:00:18 +0000 (UTC) Received: from EX13D10UWB002.ant.amazon.com (10.43.161.130) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 21:00:18 +0000 Received: from EX13D07UWB001.ant.amazon.com (10.43.161.238) by EX13D10UWB002.ant.amazon.com (10.43.161.130) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 21:00:17 +0000 Received: from EX13D07UWB001.ant.amazon.com ([10.43.161.238]) by EX13D07UWB001.ant.amazon.com ([10.43.161.238]) with mapi id 15.00.1497.006; Mon, 1 Jun 2020 21:00:17 +0000 From: "Agarwal, Anchal" To: Boris Ostrovsky , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "hpa@zytor.com" , "x86@kernel.org" , "jgross@suse.com" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "Kamata, Munehisa" , "sstabellini@kernel.org" , "konrad.wilk@oracle.com" , "roger.pau@citrix.com" , "axboe@kernel.dk" , "davem@davemloft.net" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "peterz@infradead.org" , "Valentin, Eduardo" , "Singh, Balbir" , "xen-devel@lists.xenproject.org" , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Woodhouse, David" , "benh@kernel.crashing.org" , "Agarwal, Anchal" Thread-Index: AQHWLjSzN2MZpZQ3bUyG5jE4qL1Bj6jBRlQAgAKXNgA= Date: Mon, 1 Jun 2020 21:00:17 +0000 Message-ID: References: <20200519232451.GA18632@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.208] Content-Type: text/plain; charset="utf-8" Content-ID: <55C40EA29EEBB04C9AC8B9FE1ACCA901@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQrvu78gICAgQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0 aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1 bmxlc3MgeW91IGNhbiBjb25maXJtIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMg c2FmZS4NCg0KDQoNCiAgICBPbiA1LzE5LzIwIDc6MjQgUE0sIEFuY2hhbCBBZ2Fyd2FsIHdyb3Rl Og0KICAgID4NCiAgICA+ICtlbnVtIHN1c3BlbmRfbW9kZXMgew0KICAgID4gKyAgICAgTk9fU1VT UEVORCA9IDAsDQogICAgPiArICAgICBYRU5fU1VTUEVORCwNCiAgICA+ICsgICAgIFBNX1NVU1BF TkQsDQogICAgPiArICAgICBQTV9ISUJFUk5BVElPTiwNCiAgICA+ICt9Ow0KICAgID4gKw0KICAg ID4gKy8qIFByb3RlY3RlZCBieSBwbV9tdXRleCAqLw0KICAgID4gK3N0YXRpYyBlbnVtIHN1c3Bl bmRfbW9kZXMgc3VzcGVuZF9tb2RlID0gTk9fU1VTUEVORDsNCiAgICA+ICsNCiAgICA+ICtib29s IHhlbl9zdXNwZW5kX21vZGVfaXNfeGVuX3N1c3BlbmQodm9pZCkNCiAgICA+ICt7DQogICAgPiAr ICAgICByZXR1cm4gc3VzcGVuZF9tb2RlID09IFhFTl9TVVNQRU5EOw0KICAgID4gK30NCiAgICA+ ICsNCiAgICA+ICtib29sIHhlbl9zdXNwZW5kX21vZGVfaXNfcG1fc3VzcGVuZCh2b2lkKQ0KICAg ID4gK3sNCiAgICA+ICsgICAgIHJldHVybiBzdXNwZW5kX21vZGUgPT0gUE1fU1VTUEVORDsNCiAg ICA+ICt9DQogICAgPiArDQogICAgPiArYm9vbCB4ZW5fc3VzcGVuZF9tb2RlX2lzX3BtX2hpYmVy bmF0aW9uKHZvaWQpDQogICAgPiArew0KICAgID4gKyAgICAgcmV0dXJuIHN1c3BlbmRfbW9kZSA9 PSBQTV9ISUJFUk5BVElPTjsNCiAgICA+ICt9DQogICAgPiArDQoNCg0KICAgIEkgZG9uJ3Qgc2Vl IHRoZXNlIGxhc3QgdHdvIHVzZWQgYW55d2hlcmUuIEFyZSB5b3UsIGluIGZhY3QsDQogICAgZGlz dGluZ3Vpc2hpbmcgYmV0d2VlbiBQTSBzdXNwZW5kIGFuZCBoaWJlcm5hdGlvbj8NCg0KWWVzLCBJ IGFtLiBVbmxlc3MgdGhlcmUgaXMgYSBiZXR0ZXIgd2F5IHRvIGRpc3Rpbmd1aXNoIGF0IHJ1bnRp bWUgd2hpY2ggSSBoYXZlbid0IGZpZ3VyZWQgb3V0IHlldC4NClRoZSBpbml0aWFsIGRlc2lnbiB3 YXMgdG8gaGF2ZSBzZXBhcmF0ZSBzdGF0ZXMgZm9yIHNlcGFyYXRlIG1vZGVzLiBDdXJyZW50bHks IFBNX0hJQkVSTkFUSU9OIGlzIGhhbmRsZWQgDQpieSAheGVuX3N1c3BlbmQgLiBIb3dldmVyLCBp ZiBhbnkgY2FzZSBhcmlzZXMgd2hlcmUgd2UgbmVlZCB0byBzZXQgdGhlIHN1c3BlbmRfbW9kZSwg aXRzIGF2YWlsYWJsZSB2aWEgDQp0aGlzIGludGVyZmFjZS4gVGhpcyBpcyBiYXNpY2FsbHkgdG8g c3VwcG9ydCBQTSogb3BzIHZpYSBBQ1BJIHBhdGguIFNpbmNlLCBQTV9TVVNQRU5EIGlzIG5vdCBo YW5kbGVkIGJ5IHRoZSBzZXJpZXMNCnRoZSBjb2RlIHBpZWNlIGNhbiBiZSByZW1vdmVkIGFuZCBh ZGRlZCBsYXRlci4gQW55IGNvbW1lbnRzPw0KDQoNCiAgICAoSSB3b3VsZCBhbHNvIHByb2JhYmx5 IHNob3J0ZW4gdGhlIG5hbWUgYSBiaXQsIHBlcmhhcHMNCiAgICB4ZW5faXNfcHYvcG1fc3VzcGVu ZCgpPykNCg0KU3VyZS4gV2lsbCBmaXggaW4gbXkgbmV4dCByb3VuZCBvZiBwb3N0Lg0KICAgIC1i b3Jpcw0KDQpUaGFua3MsDQpBbmNoYWwNCg0KDQoNCg0K From xen-devel-bounces@lists.xenproject.org Mon Jun 01 21:06:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 21:06:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrdc-0001Ur-O2; Mon, 01 Jun 2020 21:06:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrdb-0001Um-1a for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 21:06:27 +0000 X-Inumbo-ID: c1495186-a44b-11ea-ab5b-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c1495186-a44b-11ea-ab5b-12813bfff9fa; Mon, 01 Jun 2020 21:06:26 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 563D32073B; Mon, 1 Jun 2020 21:06:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591045585; bh=JKKCcPSQ16JBYHZKrRYFmH1gNliKgP1BlndNb+gssBE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=uCJYQiXodj60WSq0CnVF3iKVwa43WprWs1BZN9WRewFczGAqrs7i+Q3E8PaleOJyx HCN1p+zAxD9n38xJHpHaRnuIh13HMwwwprOxYhBIBOB2rAeU5sh0m29J2LC39rmfQQ CH8NGKE3y5IS9mlEOa72REboICezVZJ3c/cVcrxA= Date: Mon, 1 Jun 2020 14:06:24 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Dominique Martinet Subject: Re: [PATCH v2] 9p/xen: increase XEN_9PFS_RING_ORDER In-Reply-To: <20200522055847.GA2833@nautica> Message-ID: References: <20200521193242.15953-1-sstabellini@kernel.org> <20200522055847.GA2833@nautica> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, lucho@ionkov.net, Stefano Stabellini , ericvh@gmail.com, linux-kernel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" n Fri, 22 May 2020, Dominique Martinet wrote: > Stefano Stabellini wrote on Thu, May 21, 2020: > > From: Stefano Stabellini > > > > Increase XEN_9PFS_RING_ORDER to 9 for performance reason. Order 9 is the > > max allowed by the protocol. > > > > We can't assume that all backends will support order 9. The xenstore > > property max-ring-page-order specifies the max order supported by the > > backend. We'll use max-ring-page-order for the size of the ring. > > > > This means that the size of the ring is not static > > (XEN_FLEX_RING_SIZE(9)) anymore. Change XEN_9PFS_RING_SIZE to take an > > argument and base the calculation on the order chosen at setup time. > > > > Finally, modify p9_xen_trans.maxsize to be divided by 4 compared to the > > original value. We need to divide it by 2 because we have two rings > > coming off the same order allocation: the in and out rings. This was a > > mistake in the original code. Also divide it further by 2 because we > > don't want a single request/reply to fill up the entire ring. There can > > be multiple requests/replies outstanding at any given time and if we use > > the full ring with one, we risk forcing the backend to wait for the > > client to read back more replies before continuing, which is not > > performant. > > > > Signed-off-by: Stefano Stabellini > > LGTM, I'll try to find some time to test this by the end of next week or > will trust you if I can't make it -- ping me around June 1st if I don't > reply again until then... Ping :-) From xen-devel-bounces@lists.xenproject.org Mon Jun 01 21:16:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 21:16:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrnJ-0002SH-Mw; Mon, 01 Jun 2020 21:16:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrnI-0002SC-9E for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 21:16:28 +0000 X-Inumbo-ID: 270c775e-a44d-11ea-ab5d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 270c775e-a44d-11ea-ab5d-12813bfff9fa; Mon, 01 Jun 2020 21:16:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Aa+4iA4ScAO23Z6iHZqOcCtognGWgbZDB/KqpYe50YI=; b=dBL4KqDWZSRfqfFycm+XbDnT1 ywoybjvNVsKyh8qvLh4X7/txqvlMQ1BynPvqTs4R5ekbc+BlKPpWKX1ahm6mdBilCqM0lDwbE5cVH r5MtJZ+5vSJhKDuA4gwKmpcLegQPJr+1yi0RMUden3FPZT+VXEdtMSNyqTTXU3BkTQXgc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfrnG-00048M-3b; Mon, 01 Jun 2020 21:16:26 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfrnF-0001h4-In; Mon, 01 Jun 2020 21:16:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfrnF-0000C1-Hs; Mon, 01 Jun 2020 21:16:25 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150593: tolerable FAIL - PUSHED X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=4ec2a1f53e8aaa22924614b64dde97321126943e X-Osstest-Versions-That: qemuu=ce20db593f50752badbc94d6a96e4576aa4a2443 From: osstest service owner Date: Mon, 01 Jun 2020 21:16:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150593 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150593/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150585 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150585 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150585 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150585 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150585 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150585 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: qemuu 4ec2a1f53e8aaa22924614b64dde97321126943e baseline version: qemuu ce20db593f50752badbc94d6a96e4576aa4a2443 Last test of basis 150585 2020-05-31 20:06:30 Z 1 days Testing same since 150593 2020-06-01 05:49:17 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Peter Maydell Philippe Mathieu-Daudé Thomas Huth jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/qemu-xen.git ce20db593f..4ec2a1f53e 4ec2a1f53e8aaa22924614b64dde97321126943e -> upstream-tested From xen-devel-bounces@lists.xenproject.org Mon Jun 01 22:42:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 22:42:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jft8H-00021I-KS; Mon, 01 Jun 2020 22:42:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jft8G-00021D-4e for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 22:42:12 +0000 X-Inumbo-ID: 2185c3f6-a459-11ea-8993-bc764e2007e4 Received: from aserp2120.oracle.com (unknown [141.146.126.78]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2185c3f6-a459-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 22:42:11 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 051MaTdV181451; Mon, 1 Jun 2020 22:41:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=ClfAGnj9kbvTGjnaFDLYeq7cwLOZUUHC3TDrXMp6/U8=; b=iXpf44JQvXDltTQ5Z/z2UZULbc+XrX3N7kQnzwLwU9IagqzKpbSIBTLmBWESmSpMcMKb kRhHFrs+JmnmQ7HGnXulozmpgs4QJwUTS9YKAojS7AI7i1Ow8nK44VszxCqDFAhz1FEf 2M14z3Cv+ZfapxxVUR21wNTLigFVIsMTMvOIhXMwDCJeM7tQuW6IHrjQAzHngk17yYoE fe1Sr325o7mM1uQdNI3ljaZ+x22Vh5Ok1Sh0FHQmgRqSfYCp2TBo/NduZDGO2U4j4Z1M qk9grmo0RqeNDLoWYMS2cEm7GzHbrIWxL/zZ3Ah7cb2JrW4a1Tn7EjvBG1CDuwKGc9ZB 7w== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2120.oracle.com with ESMTP id 31bfem12fu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 01 Jun 2020 22:41:26 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 051MbrVh015955; Mon, 1 Jun 2020 22:39:25 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 31c25kxs6k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 01 Jun 2020 22:39:25 +0000 Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 051MdM8M011852; Mon, 1 Jun 2020 22:39:22 GMT Received: from [10.39.192.75] (/10.39.192.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 01 Jun 2020 15:39:21 -0700 Subject: Re: [PATCH 01/12] xen/manage: keep track of the on-going suspend mode To: "Agarwal, Anchal" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "hpa@zytor.com" , "x86@kernel.org" , "jgross@suse.com" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "Kamata, Munehisa" , "sstabellini@kernel.org" , "konrad.wilk@oracle.com" , "roger.pau@citrix.com" , "axboe@kernel.dk" , "davem@davemloft.net" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "peterz@infradead.org" , "Valentin, Eduardo" , "Singh, Balbir" , "xen-devel@lists.xenproject.org" , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Woodhouse, David" , "benh@kernel.crashing.org" References: <20200519232451.GA18632@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <763dc08a-0fdc-9b72-3d5f-eefb1d6e8453@oracle.com> Date: Mon, 1 Jun 2020 18:39:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9639 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 spamscore=0 malwarescore=0 bulkscore=0 mlxscore=0 phishscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006010164 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9639 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 phishscore=0 clxscore=1015 impostorscore=0 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006010164 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 5:00 PM, Agarwal, Anchal wrote: >  > > I don't see these last two used anywhere. Are you, in fact, > distinguishing between PM suspend and hibernation? > > Yes, I am. Unless there is a better way to distinguish at runtime which I haven't figured out yet. > The initial design was to have separate states for separate modes. Currently, PM_HIBERNATION is handled > by !xen_suspend . However, if any case arises where we need to set the suspend_mode, its available via > this interface. This is basically to support PM* ops via ACPI path. Since, PM_SUSPEND is not handled by the series > the code piece can be removed and added later. Any comments? Yes, if this is not being handled then I don't see any reason for this code to be there. -boris From xen-devel-bounces@lists.xenproject.org Mon Jun 01 23:35:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 23:35:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftxK-0006N0-Jx; Mon, 01 Jun 2020 23:34:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftxJ-0006Mv-Bv for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 23:34:57 +0000 X-Inumbo-ID: 80488c50-a460-11ea-8993-bc764e2007e4 Received: from mail-pf1-x443.google.com (unknown [2607:f8b0:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 80488c50-a460-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 23:34:56 +0000 (UTC) Received: by mail-pf1-x443.google.com with SMTP id 131so4147743pfv.13 for ; Mon, 01 Jun 2020 16:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SPELmbQOfJIxeMT9yjj8Ttxr0aEkF6JZGwDFAGf+QKo=; b=XeMGKj7BghBcp2AERgXZ3nTBeIoAIUH/QQeOWQNC1SpyJ1js2QYbZMbRSOUVUAt0j2 ncfOpuATtAdTP94XpGcKXfdqMoTdPJsi9CRR9fGsJS8NL4hIycPoqMeHTRJwkCJb1Zx4 qTobAVKXDsJVkVIa0rs0QP7WdEF+1We/S+eRQIVQrhP1cR2+K+gyzRvDFA73xoeeGgXl iTgkw5DkIVCBy8zLij67PnioIDXU2T4w1kxMyCiTDq66i2GWAKeGYCn5nyQXZu8vLT2p Ovw2B7DeBa0jZl6OU8E71U4mhttPCzWLF0KBArl4wt2PIgJ5xh4fsMTTeEp/PFZmfcgq ZTGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SPELmbQOfJIxeMT9yjj8Ttxr0aEkF6JZGwDFAGf+QKo=; b=l3tJz1pEZLOHXKuK1TcpCsG6oYPefjSDgTgxfO37m/6aWx6jkC3qdd+r5cT0UBIQld dCCIbajEFhojqLttK2LI9CMtmhq6yCVSh6vQ4YLC3eVNmNoVKXGS9tsOxBvIgtFxcZBi LO3fU1rQ5CxmiSOG4Sncc3UTG03d9+vfZvKmD6B/KGc1TtrTui9BJoXz4YEatGhqSox1 2hmVJfahSA1UkSGz+PgHWkV0Ta2FqGuifwwBD76njnulRryTvxE6sDt+FLZiKPfzlxBE NZKZvZ2EHOxa3LGxxOLcArL/UFx7vKe3gsmptkZ5KhKTjkpiEqAY50q5ixE1ns1o+SoM u7aA== X-Gm-Message-State: AOAM533Xil3emuiP3/balith5MdzFRGP9H+zbWlm4X+JcYx/kW50eYpY 9urd+k/mMw+A7xs2l88EnstNnQ== X-Google-Smtp-Source: ABdhPJy70MClJTNM3/F9rCQwlfST2nkGKHtgtJ3ON+z7WX0Mf7Rk+9MNvB5hr4p0gshkq+RehqkyPA== X-Received: by 2002:a63:d54b:: with SMTP id v11mr8829615pgi.198.1591054495930; Mon, 01 Jun 2020 16:34:55 -0700 (PDT) Received: from [192.168.1.11] (174-21-143-238.tukw.qwest.net. [174.21.143.238]) by smtp.gmail.com with ESMTPSA id p8sm477466pgs.29.2020.06.01.16.34.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 16:34:54 -0700 (PDT) Subject: Re: [PATCH v2 1/8] hw/arm/aspeed: Correct DRAM container region size To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-2-f4bug@amsat.org> From: Richard Henderson Message-ID: <0c840231-813a-20a4-62c0-a3d42c33914f@linaro.org> Date: Mon, 1 Jun 2020 16:34:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-2-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote: > memory_region_set_size() handle the 16 Exabytes limit by > special-casing the UINT64_MAX value. This is not a problem > for the 32-bit maximum, 4 GiB. > By using the UINT32_MAX value, the aspeed-ram-container > MemoryRegion ends up missing 1 byte: > > $ qemu-system-arm -M ast2600-evb -S -monitor stdio > (qemu) info mtree > > address-space: aspeed.fmc-ast2600-dma-dram > 0000000080000000-000000017ffffffe (prio 0, i/o): aspeed-ram-container > 0000000080000000-00000000bfffffff (prio 0, ram): ram > 00000000c0000000-ffffffffffffffff (prio 0, i/o): max_ram > > Fix by using the correct value. We now have: > > address-space: aspeed.fmc-ast2600-dma-dram > 0000000080000000-000000017fffffff (prio 0, i/o): aspeed-ram-container > 0000000080000000-00000000bfffffff (prio 0, ram): ram > 00000000c0000000-ffffffffffffffff (prio 0, i/o): max_ram > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/arm/aspeed.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~ From xen-devel-bounces@lists.xenproject.org Mon Jun 01 23:35:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 23:35:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfty5-0006QL-U2; Mon, 01 Jun 2020 23:35:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfty5-0006QE-15 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 23:35:45 +0000 X-Inumbo-ID: 9cc5b902-a460-11ea-8993-bc764e2007e4 Received: from mail-pl1-x641.google.com (unknown [2607:f8b0:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9cc5b902-a460-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 23:35:44 +0000 (UTC) Received: by mail-pl1-x641.google.com with SMTP id n9so573190plk.1 for ; Mon, 01 Jun 2020 16:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=X4I89W39vWdVNoghag0DFn1ebCW1eil3jLJKcfTKZ5M=; b=Rz09eZ1jDr2GqUZY/02LI/v+G4Mymsh044uItJIu+SnTWqBOlAr+pJ1tg3MAcjFFs1 Wl6k+fmHMq6vXzx2AY0IPGk7NZeU4+E1Sdxl6Mw5AoL9jND4oWQZEQZD+r57AvzHYH/N NuhvsCmxF/i2/oBgKNFahnAkMkXFOc81T1dqP9gwS5GJh/0SPKNFan23YgZ6NQ73MEYJ qtizNevWe96Vk8MzhSZxh7Hzp13L2QEO5pK/Ckpe0BVTVtsiYNZzxunfsbyOeIti92AR Gv4QktnI7lS9pbKOOeJaYUI0JaAylDORYJBmQBzWNsCRniPV5I/JXtMFJ7Pws0xd4Q6l nS0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=X4I89W39vWdVNoghag0DFn1ebCW1eil3jLJKcfTKZ5M=; b=k3oJxeOVfBUUZnEuJFVq4BPWwLnyTOBYXVTsC/EvNmJYRTFp6zOgVcg+Uu9XnuZ6DP 1BfiFCMKXpKD3yyH+8JEHkA02ZaLAM3RP7RvB4cLEPsUYwBhm3oJ1ZhzXt95A60IJvj0 obWzBvg+p7lwDR9CUKxNgQMvEEG/+lpZBH69dWCM++dqNKfZHbLTsRX3S1THeTkEA5hy yQ9h8RpaMsOLNk5HsWcUlF6QG0Xk1zgEUsTWNUd+c3MavBqwb+Ttiz6sN+RORMBQ5t+0 KbPxacrDyUxdpLO1QImqYMgQ5y7FQLflRq1nkbzaszi0HaAZgdBh9NYg4ifrTC+Bv4Yx GA3Q== X-Gm-Message-State: AOAM530MGDG2HHlf4yfZ0O5FVMODW5m0WONmUMTL3AKL+CkJaKhtpuKL VXeSXLoGoJ+DzxwN7MDyqqXzJQ== X-Google-Smtp-Source: ABdhPJxfVrNnYPK0N8OZPuZkt0Nk1A1urRieu/jIbg1ZT2QBbNMgMrB6P433MN9FZD6oMK1YrM174A== X-Received: by 2002:a17:902:7896:: with SMTP id q22mr23251618pll.216.1591054543738; Mon, 01 Jun 2020 16:35:43 -0700 (PDT) Received: from [192.168.1.11] (174-21-143-238.tukw.qwest.net. [174.21.143.238]) by smtp.gmail.com with ESMTPSA id z1sm441635pfr.88.2020.06.01.16.35.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 16:35:43 -0700 (PDT) Subject: Re: [PATCH v2 2/8] hw/pci-host/prep: Correct RAVEN bus bridge memory region size To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-3-f4bug@amsat.org> From: Richard Henderson Message-ID: <92a1fda6-0ee9-e7f2-7248-b79c01c7b2e3@linaro.org> Date: Mon, 1 Jun 2020 16:35:40 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-3-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote: > memory_region_set_size() handle the 16 Exabytes limit by > special-casing the UINT64_MAX value. This is not a problem > for the 32-bit maximum, 4 GiB. > By using the UINT32_MAX value, the bm-raven MemoryRegion > ends up missing 1 byte: > > $ qemu-system-ppc -M prep -S -monitor stdio -usb > memory-region: bm-raven > 0000000000000000-00000000fffffffe (prio 0, i/o): bm-raven > 0000000000000000-000000003effffff (prio 0, i/o): alias bm-pci-memory @pci-memory 0000000000000000-000000003effffff > 0000000080000000-00000000ffffffff (prio 0, i/o): alias bm-system @system 0000000000000000-000000007fffffff > > Fix by using the correct value. We now have: > > memory-region: bm-raven > 0000000000000000-00000000ffffffff (prio 0, i/o): bm-raven > 0000000000000000-000000003effffff (prio 0, i/o): alias bm-pci-memory @pci-memory 0000000000000000-000000003effffff > 0000000080000000-00000000ffffffff (prio 0, i/o): alias bm-system @system 0000000000000000-000000007fffffff > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/pci-host/prep.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~ From xen-devel-bounces@lists.xenproject.org Mon Jun 01 23:36:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 23:36:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftyO-0006Sp-6N; Mon, 01 Jun 2020 23:36:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftyM-0006SY-Mz for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 23:36:02 +0000 X-Inumbo-ID: a748da8a-a460-11ea-8993-bc764e2007e4 Received: from mail-pf1-x441.google.com (unknown [2607:f8b0:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a748da8a-a460-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 23:36:02 +0000 (UTC) Received: by mail-pf1-x441.google.com with SMTP id a127so2142318pfa.12 for ; Mon, 01 Jun 2020 16:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hGrlH3PqgBr3ZkLXs0ICSwS5m6e98ZxaoB6gTALk4to=; b=GFWJNcIJwd07F0D6M4IVLW6PM8NwXWcTh05r+2LsqCuNKmw3KcaiHOLhKJcdunMpKy k8C7roaMyHD4kAFgeLh1abx6yLpKVPoLQr+e1sZVtY3Aw9W8WkhIiKz6w76YB+JqcH4P MxkAomMSNK8vmd+4Jxt+xrrsCTPQEsE8onWo67228m4xttiom20ukivbUAHX8Q8JUeWg 0S/zSvXhSxLPN+S8RUH60vBO3/IgfMPExKMPz0QsEnIpgApVtllcayn9Qb0l9VfAtI6h +YQXQOC2rlmxeKBLJRIZWtdy0au/+c1OsjwAQZ0kpGZpn/9flGgboP2H4IxvkCRz+1fm FVJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hGrlH3PqgBr3ZkLXs0ICSwS5m6e98ZxaoB6gTALk4to=; b=PPtoQzyZ6S/yyjWWx8ipnKNmR2YfYemlAxGO/Tpk5dxuWZujkmyFIHdhbL2iD+GofR vqnvHic6EI+kEZAQDLf7qxH/2FUg60ITJnQr6n4BJjnWn2HfFbBg65qBWQYzksUFINtI pIQiArwNMV+qRDd5oC2DgYoK2tMIcI5tDGWpbdMRyOgreJq2lpbjcE5g9zBsoj1axzaO tVz6rXgvLyWNih/BsqlwdB9Sn6Bm5VvTdHlwWuQO6VCwdrcCHGTDvbokrwUFx4eXscI1 rxmTQ1Qtl2+jL83I+1IYiAc/ilNxpilrtSeH8yfm7aU6KrIslLWYNUOMYcbM8yaUajPI 8ukQ== X-Gm-Message-State: AOAM531mr6RNAD4PZ9wGGUzALOLAzmY7AgU08sKn9SYTva49rRCl5os6 uCvJ5AJitX3LHP/Ekp2qzjNn3A== X-Google-Smtp-Source: ABdhPJzQLtQYfpPCKrXikLqS/8usRLci/JPY1d5rfCIMc2sTmw/wqAqfi33AqaxVZO9QQc4TtjWvNw== X-Received: by 2002:a62:ee07:: with SMTP id e7mr22044574pfi.42.1591054561486; Mon, 01 Jun 2020 16:36:01 -0700 (PDT) Received: from [192.168.1.11] (174-21-143-238.tukw.qwest.net. [174.21.143.238]) by smtp.gmail.com with ESMTPSA id m14sm445894pgn.83.2020.06.01.16.36.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 16:36:00 -0700 (PDT) Subject: Re: [PATCH v2 3/8] hw/pci/pci_bridge: Correct pci_bridge_io memory region size To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-4-f4bug@amsat.org> From: Richard Henderson Message-ID: <35f77178-dc79-3b4a-7562-9bc37fad9d9b@linaro.org> Date: Mon, 1 Jun 2020 16:35:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-4-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote: > memory_region_set_size() handle the 16 Exabytes limit by > special-casing the UINT64_MAX value. This is not a problem > for the 32-bit maximum, 4 GiB. > By using the UINT32_MAX value, the pci_bridge_io MemoryRegion > ends up missing 1 byte: > > (qemu) info mtree > memory-region: pci_bridge_io > 0000000000000000-00000000fffffffe (prio 0, i/o): pci_bridge_io > 0000000000000060-0000000000000060 (prio 0, i/o): i8042-data > 0000000000000064-0000000000000064 (prio 0, i/o): i8042-cmd > 00000000000001ce-00000000000001d1 (prio 0, i/o): vbe > 0000000000000378-000000000000037f (prio 0, i/o): parallel > 00000000000003b4-00000000000003b5 (prio 0, i/o): vga > ... > > Fix by using the correct value. We now have: > > memory-region: pci_bridge_io > 0000000000000000-00000000ffffffff (prio 0, i/o): pci_bridge_io > 0000000000000060-0000000000000060 (prio 0, i/o): i8042-data > 0000000000000064-0000000000000064 (prio 0, i/o): i8042-cmd > ... > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/pci/pci_bridge.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson r~ From xen-devel-bounces@lists.xenproject.org Mon Jun 01 23:36:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 23:36:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftyl-0006X5-Fq; Mon, 01 Jun 2020 23:36:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftyk-0006Wp-Am for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 23:36:26 +0000 X-Inumbo-ID: b56f2cc2-a460-11ea-8993-bc764e2007e4 Received: from mail-pj1-x1041.google.com (unknown [2607:f8b0:4864:20::1041]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b56f2cc2-a460-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 23:36:25 +0000 (UTC) Received: by mail-pj1-x1041.google.com with SMTP id h95so533883pje.4 for ; Mon, 01 Jun 2020 16:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tdEZ0FE2fCkDdeCvjfAB13a3HzQjvtrN7+bWKrDiVJY=; b=QSSR3Tj/yGlftLB9YcpZ1IPdp82Oq7+Xb1W/zB0ce8Lpd6c/K8euxhHRJQzAI4a1E3 1KobbVvQyaCC1uCzRelaNzPSRDXazQXp0S4Dfysw3vyuEUTUMWHoEu2qjV8hhDAf2wNG fLvrpPn9nnwZP40nJV7l3OJj4NDHzApNYsv2Vm5kR4q7rI38ry719XhneDioE1H/su0b 2YaVgNOMMBWxj1xn2kqrtmX2tU6r78lX7kW/dTQXAkKrfIJIWxAotPPZHRf9HLeUL1SX nzuSL6fROjjw1xXXE03lAqSXRjuxHPqkPTZlPC7ytxiuFFZzwk7+dOkN2fAa6qxcObH5 sKRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tdEZ0FE2fCkDdeCvjfAB13a3HzQjvtrN7+bWKrDiVJY=; b=Cb0cL4qtHA55cRu73GhoHoEz+dBEoduHcaJ5itU6nFSM3CY7OJgpldhTGJ0Rl+0vR7 iK6Gjj/dnxxYQR7kalVNtAabJcPYquiGaN/U21UfsKV3GTM2XwcwfVLI0pxTJOmGWGpE lhQw4yQqdBp/JD59Dl99GiDBMTTEqd3PruJ04CaVKvhSCg76mCFvSn0WdGcnub1xqaYt JEV5K0DZxMmQ6EaqTdkAWNBwYzuF3D7xQsLVo9I6F5AXUDla9Y3qIgLnEe8SvIVirbY5 0h9R7aZkOTn8CWHtwrsh5J7XpL+s3Qa+J9/9DgPQJV451jl5xf/Oas62YTFbln25RfrH Felg== X-Gm-Message-State: AOAM532Vlu4CMbmx3mCql8yoannh7auXUi46cvTXZfHlRSFt1zoi1IC0 qCrOWPnbTr2bNwbDF+Ss3Ieb6g== X-Google-Smtp-Source: ABdhPJxpAGmqj3Dx0cH2lpPvMLKiH5ZdJ3xTJ4daeI/RNAe8QkFrgiIitY2pMAswbpMKPCy91j6fQA== X-Received: by 2002:a17:90a:a08d:: with SMTP id r13mr1978033pjp.96.1591054585155; Mon, 01 Jun 2020 16:36:25 -0700 (PDT) Received: from [192.168.1.11] (174-21-143-238.tukw.qwest.net. [174.21.143.238]) by smtp.gmail.com with ESMTPSA id x77sm454355pfc.4.2020.06.01.16.36.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 16:36:24 -0700 (PDT) Subject: Re: [PATCH v2 4/8] hw/pci/pci_bridge: Use the IEC binary prefix definitions To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-5-f4bug@amsat.org> From: Richard Henderson Message-ID: <761761ff-13ef-acf7-094d-b0406a4f9a02@linaro.org> Date: Mon, 1 Jun 2020 16:36:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-5-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote: > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/pci/pci_bridge.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Richard Henderson r~ From xen-devel-bounces@lists.xenproject.org Mon Jun 01 23:36:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 23:36:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftyz-0006c1-Si; Mon, 01 Jun 2020 23:36:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftyz-0006bp-A3 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 23:36:41 +0000 X-Inumbo-ID: be6dc3ce-a460-11ea-ab6a-12813bfff9fa Received: from smtp-fw-4101.amazon.com (unknown [72.21.198.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id be6dc3ce-a460-11ea-ab6a-12813bfff9fa; Mon, 01 Jun 2020 23:36:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591054601; x=1622590601; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=J/MloPbOinRJ95w81UPzW+FxLSViVtVGzpvoTyLM11E=; b=RZxK3wAOHv6CMin5dMxgBXCRZ9obWrv84xYhEPiBIL3JP2iPgWCZwwFw MM5UMHV9x/2Qdd3ctwiXXfVvBI85t5xZo9erEs3RhTlSWjyNfakuvmq83 GgvgzIF33CIaUY4r/+N2Gr61rKg5m85UmMgl/lUZo96Vx6jv+cr0f2+0i U=; IronPort-SDR: LkBdX1Jax7kcHTVh6vnZJsyZjBLWu31bHv/02Ku7vm+Mkckt6fxAI0NtZC78idaa9UVK8IjDRw A+7M5cTZONqA== X-IronPort-AV: E=Sophos;i="5.73,462,1583193600"; d="scan'208";a="33842841" Subject: Re: [PATCH 02/12] xenbus: add freeze/thaw/restore callbacks support Thread-Topic: [PATCH 02/12] xenbus: add freeze/thaw/restore callbacks support Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-5bdc5131.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 01 Jun 2020 23:36:26 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-5bdc5131.us-west-2.amazon.com (Postfix) with ESMTPS id C2C57A1F45; Mon, 1 Jun 2020 23:36:24 +0000 (UTC) Received: from EX13D10UWB001.ant.amazon.com (10.43.161.111) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 23:36:24 +0000 Received: from EX13D07UWB001.ant.amazon.com (10.43.161.238) by EX13D10UWB001.ant.amazon.com (10.43.161.111) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 1 Jun 2020 23:36:24 +0000 Received: from EX13D07UWB001.ant.amazon.com ([10.43.161.238]) by EX13D07UWB001.ant.amazon.com ([10.43.161.238]) with mapi id 15.00.1497.006; Mon, 1 Jun 2020 23:36:23 +0000 From: "Agarwal, Anchal" To: Boris Ostrovsky , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "hpa@zytor.com" , "x86@kernel.org" , "jgross@suse.com" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "Kamata, Munehisa" , "sstabellini@kernel.org" , "konrad.wilk@oracle.com" , "roger.pau@citrix.com" , "axboe@kernel.dk" , "davem@davemloft.net" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "peterz@infradead.org" , "Valentin, Eduardo" , "Singh, Balbir" , "xen-devel@lists.xenproject.org" , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Woodhouse, David" , "benh@kernel.crashing.org" Thread-Index: AQHWLjS9hSpS5JM2xU+iWpBujRQ276jBTrMAgAK6doA= Date: Mon, 1 Jun 2020 23:36:23 +0000 Message-ID: <687F52C0-A277-4D21-8802-3CF1358EEB31@amazon.com> References: <7fd12227f923eacc5841b47bd69f72b4105843a7.1589926004.git.anchalag@amazon.com> <835ca864-3e35-9a82-f3fd-24ca4e2ec06e@oracle.com> In-Reply-To: <835ca864-3e35-9a82-f3fd-24ca4e2ec06e@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.200] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCu+7vyAgICBDQVVUSU9OOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9m IHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRz IHVubGVzcyB5b3UgY2FuIGNvbmZpcm0gdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBp cyBzYWZlLg0KDQoNCg0KICAgIE9uIDUvMTkvMjAgNzoyNSBQTSwgQW5jaGFsIEFnYXJ3YWwgd3Jv dGU6DQogICAgPg0KICAgID4gIGludCB4ZW5idXNfZGV2X3Jlc3VtZShzdHJ1Y3QgZGV2aWNlICpk ZXYpDQogICAgPiAgew0KICAgID4gLSAgICAgaW50IGVycjsNCiAgICA+ICsgICAgIGludCBlcnIg PSAwOw0KDQoNCiAgICBUaGF0J3Mgbm90IG5lY2Vzc2FyeS4NCkFDSy4NCg0KICAgID4gICAgICAg c3RydWN0IHhlbmJ1c19kcml2ZXIgKmRydjsNCiAgICA+ICAgICAgIHN0cnVjdCB4ZW5idXNfZGV2 aWNlICp4ZGV2DQogICAgPiAgICAgICAgICAgICAgID0gY29udGFpbmVyX29mKGRldiwgc3RydWN0 IHhlbmJ1c19kZXZpY2UsIGRldik7DQogICAgPiAtDQogICAgPiArICAgICBib29sIHhlbl9zdXNw ZW5kID0geGVuX3N1c3BlbmRfbW9kZV9pc194ZW5fc3VzcGVuZCgpOw0KICAgID4gICAgICAgRFBS SU5USygiJXMiLCB4ZGV2LT5ub2RlbmFtZSk7DQogICAgPg0KICAgID4gICAgICAgaWYgKGRldi0+ ZHJpdmVyID09IE5VTEwpDQogICAgPiBAQCAtNjI3LDI0ICs2NDUsMzIgQEAgaW50IHhlbmJ1c19k ZXZfcmVzdW1lKHN0cnVjdCBkZXZpY2UgKmRldikNCiAgICA+ICAgICAgIGRydiA9IHRvX3hlbmJ1 c19kcml2ZXIoZGV2LT5kcml2ZXIpOw0KICAgID4gICAgICAgZXJyID0gdGFsa190b19vdGhlcmVu ZCh4ZGV2KTsNCiAgICA+ICAgICAgIGlmIChlcnIpIHsNCiAgICA+IC0gICAgICAgICAgICAgcHJf d2FybigicmVzdW1lICh0YWxrX3RvX290aGVyZW5kKSAlcyBmYWlsZWQ6ICVpXG4iLA0KICAgID4g KyAgICAgICAgICAgICBwcl93YXJuKCIlcyAodGFsa190b19vdGhlcmVuZCkgJXMgZmFpbGVkOiAl aVxuIiwNCg0KDQogICAgUGxlYXNlIHVzZSBkZXZfd2FybigpIGV2ZXJ5d2hlcmUsIHdlIGp1c3Qg aGFkIGEgYnVuY2ggb2YgcGF0Y2hlcyB0aGF0DQogICAgcmVwbGFjZWQgcHJfd2FybigpLiBJbiBm YWN0LCAgdGhpcyBpcyBvbmUgb2YgdGhlIGxpbmVzIHRoYXQgZ290IGNoYW5nZWQuDQoNCkFDSy4g V2lsbCBzZW5kIGZpeGVzIGluIG5leHQgc2VyaWVzDQoNCiAgICA+DQogICAgPiAgaW50IHhlbmJ1 c19kZXZfY2FuY2VsKHN0cnVjdCBkZXZpY2UgKmRldikNCiAgICA+ICB7DQogICAgPiAtICAgICAv KiBEbyBub3RoaW5nICovDQogICAgPiAtICAgICBEUFJJTlRLKCJjYW5jZWwiKTsNCiAgICA+ICsg ICAgIGludCBlcnIgPSAwOw0KDQoNCiAgICBBZ2Fpbiwgbm8gbmVlZCB0byBpbml0aWFsaXplLg0K DQpBQ0suDQogICAgPiArICAgICBzdHJ1Y3QgeGVuYnVzX2RyaXZlciAqZHJ2Ow0KICAgID4gKyAg ICAgc3RydWN0IHhlbmJ1c19kZXZpY2UgKnhkZXYNCiAgICA+ICsgICAgICAgICAgICAgPSBjb250 YWluZXJfb2YoZGV2LCBzdHJ1Y3QgeGVuYnVzX2RldmljZSwgZGV2KTsNCg0KDQogICAgeGVuZGV2 IHBsZWFzZSB0byBiZSBjb25zaXN0ZW50IHdpdGggb3RoZXIgY29kZS4gQW5kIHVzZSB0b194ZW5i dXNfZGV2aWNlKCkuDQpBQ0suDQoNCiAgICAtYm9yaXMNCg0KSSB3aWxsIHB1dCB0aGUgZml4ZXMg aW4gbmV4dCByb3VuZCBvZiBwYXRjaGVzLg0KDQpUaGFua3MsDQpBbmNoYWwNCg0KDQo= From xen-devel-bounces@lists.xenproject.org Mon Jun 01 23:36:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 23:36:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftz7-0006eL-5G; Mon, 01 Jun 2020 23:36:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftz5-0006dr-Mo for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 23:36:47 +0000 X-Inumbo-ID: c22a70ac-a460-11ea-8993-bc764e2007e4 Received: from mail-pf1-x441.google.com (unknown [2607:f8b0:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c22a70ac-a460-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 23:36:47 +0000 (UTC) Received: by mail-pf1-x441.google.com with SMTP id f3so4159674pfd.11 for ; Mon, 01 Jun 2020 16:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=utp8UPhvpVOjKQDHheJJZxOdw9rN2rKIwvixqFfY6I0=; b=xTG7Mc8Ke+P7C8o56JElmLFbH18twbQfttKAc5G/dIXmkm2onWlNspWFfvusLOTgLg pTRDJq/tgRyR7y8JuLP6CZFE2Egd7bg09ZKOeD396awq3y3Wt4q7J+Liinm2BBOuvUrx PPw+rh9aMrrdNIj2zKTtH0aArySoR9V7wv0LwGc+yun4GQvO89nczwsvBnve0Xlf9HLH 7jA8bUorURzKagLbFYICNCER7T+CBwhJkzcywpFi0y9NCCGAjDZRm5Uhst8GI6Mk+SKq qe0DI8YoF1wc321Lg2a7uLv3QwcS6piwxXYRRqVkl86ZgCgMmu7bDWT6NTv4v2CVRdQd XsRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=utp8UPhvpVOjKQDHheJJZxOdw9rN2rKIwvixqFfY6I0=; b=Y+5JKUB04BBOZgp9V0mWMZGd7vsNQx+s1KrWExHUJRFjUNhSOphbXF2a9wzTHw35DO Icn+MT4qim71A+HC6O4L7mFrDUTU4cQtJ5HVdt1Q8hrjIUFTJfOiUVfoEd9WmYLsHWgj r3lEMgum1NbVqQZFD6Hgsdy2SeBrlAKIm/SLdH/2e3rqabaTm6+jyeTDj0bW15KbWDRM QTzRfRbzdiXVlUu8rg5d00BnVJm5rzIjFPQaihhv1UEWwwjRX81FaefD63/w+ny3ieiA HRNuP0r1hQuDVRD8UHpTsgEcIN+qkoZW8frqGPCEYY0dRw+C/dGkRkEVb/sANl8GmJtB E8ww== X-Gm-Message-State: AOAM532oTL018Hxmy3D4Pszw+okWUfEwuf48GIBg8VkXyqWxi+9/HX9B CMHjXMwmIrItpkn+XRfNoewzmg== X-Google-Smtp-Source: ABdhPJylPCz6NJ8Nv/4CwG5eFZALKyaW9WbeoXC1cmJzPEV4oHq3Rbd3WXYgkQZHOnN28B1WNZx0MQ== X-Received: by 2002:aa7:8c53:: with SMTP id e19mr22646004pfd.264.1591054606599; Mon, 01 Jun 2020 16:36:46 -0700 (PDT) Received: from [192.168.1.11] (174-21-143-238.tukw.qwest.net. [174.21.143.238]) by smtp.gmail.com with ESMTPSA id k7sm452101pga.87.2020.06.01.16.36.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 16:36:45 -0700 (PDT) Subject: Re: [PATCH v2 5/8] hw/pci-host: Use the IEC binary prefix definitions To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-6-f4bug@amsat.org> From: Richard Henderson Message-ID: <2aa683fc-ff9d-17ed-a35f-f177bb5c9e77@linaro.org> Date: Mon, 1 Jun 2020 16:36:43 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-6-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote: > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/pci-host/i440fx.c | 3 ++- > hw/pci-host/q35.c | 2 +- > hw/pci-host/versatile.c | 5 +++-- > 3 files changed, 6 insertions(+), 4 deletions(-) Reviewed-by: Richard Henderson r~ From xen-devel-bounces@lists.xenproject.org Mon Jun 01 23:37:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 23:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftzi-0006og-Fm; Mon, 01 Jun 2020 23:37:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftzh-0006oN-Bs for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 23:37:25 +0000 X-Inumbo-ID: d892e504-a460-11ea-81bc-bc764e2007e4 Received: from mail-pj1-x1042.google.com (unknown [2607:f8b0:4864:20::1042]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d892e504-a460-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 23:37:24 +0000 (UTC) Received: by mail-pj1-x1042.google.com with SMTP id fs4so488206pjb.5 for ; Mon, 01 Jun 2020 16:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PlBT1B/hjs0RZ4Sv/xaBn5v/munjW/EVMnZ0HWetFtY=; b=h0ouO/8u5iRqZlDoPrAMhkSSqFRTrfSwQdo19a4i9ahzvmGjW0r6DS5w0CXaMbbJtL /So9QK85DTtEQdWnTr0axxftFQZvGnF2jLt5EJ82ylkw5vJgvgWrdemTxnGl2T/EDVPy tkR6x9ZtBtuv7G7WnqinFAypKDbsLrHF/El7N5SmOAmTwcd1ObkvDQR+XLnQz3/9dSLv 0ZcCXDtQJwZmlIpqQUJaKcsDiDMKHRBkg+3uD47Izs61TD3fhbbFgPUiS3tX1lMruyO8 oXK1ML5f8Zah4SLGKt/6mY+IX6klJBO8Hynj6yjeHoSrie0ul9t9XWocNqYuw8RjfcaO h/iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PlBT1B/hjs0RZ4Sv/xaBn5v/munjW/EVMnZ0HWetFtY=; b=hshqRu888yUQTP48XBnPkL8nqLOkRkYoxYhQ7PYa1zSqs7EBmiUv1RURT/rqcJHGrP viPp7ah3XhnaW1sknPEfV843RrWvEc2cuQj0CWn5p9eH/SVa0WTshC/T7REuwMbau2Qx GZCsVn9/tZfff6EH9coSA45/u2jXRXvIocf+Wov8Buf8B0P727hUmXae/VyEU/4OYDjq LB5rwpCB5VlMYfFTOVlhXbSs9af8RPjbLyX+zXeoh7OVM1NoqmJ2Nux5ySShNbHA9VYk M3oGjZw2xCgBF2kx76DDGJsqgIAYrXvrREZexC+kTONgeMm4BbcWNF+ozpq5L+KIBscT Fa/A== X-Gm-Message-State: AOAM530vTCf9t8QIP/NlzHKlYBTaaBXDykC4tJifnxzax0h988LdI20r kSe5wJbvrzhb08obq3rkrlAEYA== X-Google-Smtp-Source: ABdhPJzzzU+9Uf4BtnV7qNbKvl+iUuKO6qwD6miyTuur8YHPtfQ7XV0BnKoxEbCJaOSgLcuxhYk+Pw== X-Received: by 2002:a17:902:710b:: with SMTP id a11mr6593788pll.156.1591054644135; Mon, 01 Jun 2020 16:37:24 -0700 (PDT) Received: from [192.168.1.11] (174-21-143-238.tukw.qwest.net. [174.21.143.238]) by smtp.gmail.com with ESMTPSA id l187sm400253pfl.218.2020.06.01.16.37.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 16:37:23 -0700 (PDT) Subject: Re: [PATCH v2 6/8] hw/hppa/dino: Use the IEC binary prefix definitions To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-7-f4bug@amsat.org> From: Richard Henderson Message-ID: <57783e28-09e5-8545-7a90-e52ad0dac9d8@linaro.org> Date: Mon, 1 Jun 2020 16:37:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-7-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote: > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/hppa/dino.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Richard Henderson r~ From xen-devel-bounces@lists.xenproject.org Mon Jun 01 23:37:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 23:37:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftzx-0006tS-OO; Mon, 01 Jun 2020 23:37:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jftzw-0006t6-L5 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 23:37:40 +0000 X-Inumbo-ID: e1b666d8-a460-11ea-8993-bc764e2007e4 Received: from mail-pg1-x541.google.com (unknown [2607:f8b0:4864:20::541]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e1b666d8-a460-11ea-8993-bc764e2007e4; Mon, 01 Jun 2020 23:37:40 +0000 (UTC) Received: by mail-pg1-x541.google.com with SMTP id s10so4211369pgm.0 for ; Mon, 01 Jun 2020 16:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KUapqzqKD/nil8AJP/KRmcd5zCFEf0jfxXrXYdNEGQI=; b=FatqtVOR5hD/fcjlHQiJxex0C6zQusiasYEb/yEipsUHJ8XYLQsy5xfoCZP0e+yu2k iuyeevu0q7AhEwUlWsJu32GG5SazukklQ7e67apLyPFjt5a/kRoa7XobmxW3KegBIMKP ENP/BSizdgxJ2u8Tvh8iFJAyCgLU5iLwR4aQ1m509XvSedk9+fo6MComm8rgpnGt+o0N Q98WvROsPGMZBjMcvm6JrmLaNrnVanswonOdPV+SMxS43AgLRfuApjZXh5bhpv+tDGdz MMCTMQ66HTYSfiIMqxA5Ki+niSFNrxoUK9Dpm02g07u76J4kojC7ItRwfO6gs62s6NM6 DARQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KUapqzqKD/nil8AJP/KRmcd5zCFEf0jfxXrXYdNEGQI=; b=RFa/WiI4Pybh8QrzXQrUoril5f/v0xgaja7BzjBcfTKoDu9JcKnhdvOnpOD9laF1DI AfskaIN+/pUTdyUU+owFKyiGamHmKGLAvG36Hnci+YhXsojRMUBbC08rF685MwzK8Pob vyWIMOGd3Raa8TZQ9WRWfibaHidHCFb87c/6IA5bWuKabHx0ChXbIxA67CEMYQ6YUODL 4DeD/6Y3ysyfSq4Bc7eHE4srVxfHGLrrBiy39s3IPpbh4VxDzbASE70F9JyyJDRgwi27 l5+4QQAJ3B6XEOTfMvNy6XtzKTERhIMMzJs83fIQT+zDj9jkEaCQ0Fsn7dXVxf+M4Ms8 df2Q== X-Gm-Message-State: AOAM531wFXMFLSlrg6wt3IO6cYsohJyfx8xJKhh9tYA2VMsdM/7BcArR 9+OJAqabBLgg0rzy3PXdU2ekQQ== X-Google-Smtp-Source: ABdhPJxhd+PX2dAfPlV44Fx/pz/N3NFXKQtVkApW6bgZq/7EFs6cRCLgC6WvnR+4RiTgTsBqwCGGXQ== X-Received: by 2002:a63:6345:: with SMTP id x66mr20915001pgb.156.1591054659488; Mon, 01 Jun 2020 16:37:39 -0700 (PDT) Received: from [192.168.1.11] (174-21-143-238.tukw.qwest.net. [174.21.143.238]) by smtp.gmail.com with ESMTPSA id g19sm415680pfo.209.2020.06.01.16.37.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 16:37:38 -0700 (PDT) Subject: Re: [PATCH v2 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-8-f4bug@amsat.org> From: Richard Henderson Message-ID: <403c7efe-bfa4-c6e3-7ab7-0592bc16bfc8@linaro.org> Date: Mon, 1 Jun 2020 16:37:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-8-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote: > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/i386/xen/xen-hvm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson r~ From xen-devel-bounces@lists.xenproject.org Mon Jun 01 23:38:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 01 Jun 2020 23:38:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfu0H-000704-1X; Mon, 01 Jun 2020 23:38:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfu0E-0006zR-U2 for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 23:37:58 +0000 X-Inumbo-ID: ec9d4e86-a460-11ea-81bc-bc764e2007e4 Received: from mail-pj1-x1042.google.com (unknown [2607:f8b0:4864:20::1042]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ec9d4e86-a460-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 23:37:58 +0000 (UTC) Received: by mail-pj1-x1042.google.com with SMTP id nm22so490606pjb.4 for ; Mon, 01 Jun 2020 16:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HfFhYalJY0owExcssF2oPatU+OO5rT0/qJC/uP661lE=; b=D6RFiyd3vhs4PAjso9chbZyN90KGj+KGNss4NJQQ8ZtfXqYr8rob/58LqdkivyQ18S l8MM5DCaRgDBwmpNMqKrdYLfNRH4UDuLUbWD+FrxdZlCs7oRa7NWFLsPTWt+x02Cg+Y8 cq/LBMagSbGn+1O9fmyA2upRrb1DRGWB3KkOBS4QZLb8bwrISwNs2qMqtQ5CMDZRh+fI HSymYViN4Vz251sbBkoz7+QKOmlsXmmdPwlsLYqWFEzzYkaFl1BQKctLNlp4pOMzWc6H lAQS+t6tOCAJf70J2cbezgmakkny+l09OEdidLQyiADzbfoocJWYEiW1gmFcQPbIpryA 8FcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HfFhYalJY0owExcssF2oPatU+OO5rT0/qJC/uP661lE=; b=teh+8MQskn5fPa2yCUgAHjZi/7OQVgePvDTXjkPgkIm0aEUoxv1uGDVvR74omLUU/E YS9VSFuRNrG+FZNMa1CDBx5AIeSVMy0HZDjJ0eLX4xWD0YIK6OXRxPXwiV+JW4Yb56pJ QO7GkPAgkBh2F8TDTQ+JmXgGTZQDeOCnPYxZVix0QzZjbh4wTWXfu0wDp5ZCJykVgGU6 KFFvCEQJkoKNl41WDoByJ2VdxhaCQsKQyGUxh9cNMcZdHgAQqvFWKHbhb8zwRPGlPZ8w XAiHCw1MkQDbeipINTbTuUnhLTswIvcEzOvvLFXnL2WwEhyoz2C5fXQxTFzybuA7YW9X wmIQ== X-Gm-Message-State: AOAM531QTodeyuIRGUnVc/Is4Lyu64MIgpyfk4puExtwNtU14vToih03 xYMyzbbQ9t0RectxMqQxtrSmqgormfI= X-Google-Smtp-Source: ABdhPJwQbu/car7bKu2JAjkABhB4S+ApIJr/aipBL4QQbfu0LhpD4XGgfdkXxwi8pkIXezTuXqaYwg== X-Received: by 2002:a17:902:bf43:: with SMTP id u3mr21921053pls.240.1591054677830; Mon, 01 Jun 2020 16:37:57 -0700 (PDT) Received: from [192.168.1.11] (174-21-143-238.tukw.qwest.net. [174.21.143.238]) by smtp.gmail.com with ESMTPSA id h13sm444790pfk.25.2020.06.01.16.37.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2020 16:37:57 -0700 (PDT) Subject: Re: [PATCH v2 8/8] target/i386/cpu: Use the IEC binary prefix definitions To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-9-f4bug@amsat.org> From: Richard Henderson Message-ID: Date: Mon, 1 Jun 2020 16:37:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-9-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/1/20 7:29 AM, Philippe Mathieu-Daudé wrote: > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > target/i386/cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Richard Henderson r~ From xen-devel-bounces@lists.xenproject.org Tue Jun 02 01:12:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 01:12:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfvTZ-0002cV-Vf; Tue, 02 Jun 2020 01:12:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfvTZ-0002cP-1u for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 01:12:21 +0000 X-Inumbo-ID: 1aea3ea4-a46e-11ea-ab73-12813bfff9fa Received: from EUR01-HE1-obe.outbound.protection.outlook.com (unknown [40.107.13.55]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1aea3ea4-a46e-11ea-ab73-12813bfff9fa; Tue, 02 Jun 2020 01:12:20 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dv9JJ+yZzjAYZICrp691FDqCkFIDFwQFVP53uZg6dNi9LLZi3V81nHtDIao/IATRoGmaznx0xi0mPgV9Ehnjyhy0RTRVGRRFQWTCnHf3X3F/I8MGXCTdea0tMbA+P1PPFm/CMmrSYX1a86C6OutLbTv+3Nn9r/eZer/Dd2rEZkaakTvfMjJL9uBMFjIW8MPqtkqscAx+UOc64R4l64IDx28H6fJrf5GyOr2hWLyYQDId0cbVhL+bkRtdFQsC/4z8w+RWOoti2KgDzF04N5aZAtz65RqkCzTE7spFhHyUghgHDBxqbOVLOTlz+IcBlf3FhR531hwSYRXiUX4vGEArww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3xQrngUYPEu8lqWQhL3J7bxSr1SPE39TjnwqMaCAlhQ=; b=KhIERCZwWXJe9qSTsOSz1sNueCeC+AdJ7QI65gIoywrbsF9YJdQ2NERBIrSKSkgbLWbC3Vq+FhoT71uZPaiz/CeQgn/VjObmaE7Iw20AO0MEJ4m5yuFwZXHOYYfX/dXT039kZ9eVFV74zJXeU/LWCxKodW+U9SmR0EltBKEvejlP4KIVyJY5iaxgY7esiU5UN2N9AWeXx+tj7qZU0uJRPa9JOJDDVL0lHbEWfGkeYfrzYfXndq8dNd60IkI9BqFp/YjcPmm8q7LLSO8hyG7j5hLDGRlakmrfkJL9+lfPJwKGEVFa8CfAhMJYPClqZwAjwcPpqLM60YeYn6Fx0KOiiQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3xQrngUYPEu8lqWQhL3J7bxSr1SPE39TjnwqMaCAlhQ=; b=K8RCKsB2PtS5JAUcyyhbWsCbyu4PyWyTr4eJbtyWmrlvSwF8AXBBtlJj3oZlE1aUW24GYbOU+AV1Si8DVA1bSFYWb0Y4Y/g1Bpp3ug7Xuj65Wx0N25/eOOasoWepFFMRPzuXl1OyHZ0qAOB+UEZIT1xTHuetxB/O3Ff52TcoSd8= Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB3215.eurprd03.prod.outlook.com (2603:10a6:803:1f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Tue, 2 Jun 2020 01:12:16 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3045.024; Tue, 2 Jun 2020 01:12:16 +0000 From: Volodymyr Babchuk To: "dfaggioli@suse.com" , "george.dunlap@eu.citrix.com" , "julien.grall@arm.com" , "xen-devel@lists.xenproject.org" Subject: Re: [Xen-devel] [RFC 1/9] schedule: Introduce per-pcpu time accounting Thread-Topic: [Xen-devel] [RFC 1/9] schedule: Introduce per-pcpu time accounting Thread-Index: AQHVaIxKZPZB1+b+UEeHqKVXpxsigKdwZuYAgA3xnYCBPODKAIAFIZCAgAXJvoA= Date: Tue, 2 Jun 2020 01:12:16 +0000 Message-ID: <061528bf93664a3ca00fce5d4bd3c585af1282e9.camel@epam.com> References: <1568197942-15374-1-git-send-email-andrii.anisov@gmail.com> <1568197942-15374-2-git-send-email-andrii.anisov@gmail.com> <8c74cacb-ff73-eddc-626c-f6fa862cf5a6@arm.com> <0e46fc4b29b7c3b3e6b4ca4704b9e7dac5738868.camel@epam.com> <6fcdb69457e5768b0fa2259f83a23158e9c939f5.camel@suse.com> In-Reply-To: <6fcdb69457e5768b0fa2259f83a23158e9c939f5.camel@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.2 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7afffd39-0500-416c-b203-08d80691fd48 x-ms-traffictypediagnostic: VI1PR0302MB3215: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0422860ED4 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: veRA4+akgna7zXvP4bBjKavm3EWuIzh9vg7wucHZPPvauBdrLZEN28ksQ3/ILJCIeorHJsjXy0HUddi3No6mnjptdPD0fYKdMilMKWLNCBGQgR+83WhBmh3D+1wqaLj8EPldzhlINAFfob8K8Ue4eVVe6MoRTKWhzOBltidaNK8+Pu0mtBj7LFMeM0uiPvNRGmk7c19JvM9T5PRRlss3QIbGaJWa3GEtEXecnZlnJ0EmiMrKlkSROquNyO9BlhbJ1sADfSLlbUNeT9lNw2WEuV4uMg34qhCfWHloFjMX4YFfFntix9ueBVuKkt3r64MJn4u6+Pz0SVJu0ysQf48PqA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(396003)(366004)(39860400002)(346002)(15650500001)(5660300002)(316002)(2906002)(2616005)(8676002)(86362001)(6512007)(6486002)(478600001)(71200400001)(55236004)(6506007)(54906003)(110136005)(36756003)(7416002)(8936002)(66446008)(91956017)(76116006)(26005)(186003)(64756008)(66476007)(66946007)(4326008)(83380400001)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AMjjh/ZDAZ2oOKYDxZWq742fDzKK0AhfzzoYVngVY5Mr+RtjU6bgDTCahcmTn1YN5y1x0m3ZjJrcro8BPIqUaClIbthIYLj1sv+fBlpLKFnGLsje3bAtRHzzpdIUjDn/Lb5o+dOeItzz2EUB9rhwTFdhuTnaj03s02Fev/uoPIAtTT5A7gZd/EpBeFc21NgPuorOYVGFZgpssDr7+sRlHTT/n+pRLFyaE6PSXVdIsdR3SI+5jmMhcmoRDZTavt0YXC5Jm05xIMNwx5gwHJOod6xxsjILAyFtvKyHdmo4KoD3X2M0qS8XA+uC60bmmQOYFf9MGQS/Vnx0OYV0LXqUVACi7o5xtB2PkuvF1cA3iS+rmlRVqZI9viaxsWlu3vFcwQU33AcmbhTLVN7l9U2Y1t8hCd8XbydR1Imk1Tg/N46rNvroynSP35thLXNCCieYOW+fELzUoixyShXla8/55YlgedVIqYKQ4+bWzC13Xhs= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7afffd39-0500-416c-b203-08d80691fd48 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2020 01:12:16.1037 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9hW3MwH7P2IioEvuam8Rbr9Z2n3COiLOh+tVSELzsKeugJSkDaedxE/yb0ZUJxvID5kEp5Sp05EoSfrmMw62P7KeNU72em7TyXL7tINg0JU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB3215 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "konrad.wilk@oracle.com" , "ian.jackson@eu.citrix.com" , "tim@xen.org" , "jbeulich@suse.com" , "andrew.cooper3@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gRnJpLCAyMDIwLTA1LTI5IGF0IDEwOjQ4ICswMjAwLCBEYXJpbyBGYWdnaW9saSB3cm90ZToN Cj4gT24gVHVlLCAyMDIwLTA1LTI2IGF0IDAyOjI3ICswMDAwLCBWb2xvZHlteXIgQmFiY2h1ayB3 cm90ZToNCj4gPiBIZWxsbyBBbGwsDQo+ID4gDQo+IEhlbGxvIFZvbG9keW15ciwNCj4gDQoNCkhp IERhcmlvLA0KDQo+ID4gVGhpcyBpcyBnZW50bGUgcmVtaW5kZXIgYWJvdXQgdGhpcyBSRkMuIA0K PiA+IA0KPiA+IFNhZGx5LCBBbmRyaWkgQW5pc292IGhhcyBsZWZ0IG91ciB0ZWFtLiBCdXQgSSdt IGNvbW1pdGVkIHRvIGNvbnRpbnVlDQo+ID4gaGlzIHdvcmsgb24gdGltZSBhY2NvdW50aW5nIGFu ZCByZWFsIHRpbWUgc2NoZWR1bGluZy4NCj4gPiANCj4gT2ssIHNvLCBmaXJzdCBvZiBhbGwsIHNv cnJ5IHRoYXQgdGhpcyBoYXMgbm90IGJlZW4gcHJvcGVybHkgYWRkcmVzc2VkLg0KPiANCj4gSSBw ZXJzb25hbGx5IG5ldmVyIGZvcmdvdCBhYm91dCBpdCBvciBhbnl0aGluZy4uLiBTdGlsbCwgSSBo YXZlbid0IGJlZW4NCj4gYWJsZSB0byBsb29rIGludG8gaXQgcHJvcGVybHkuDQo+IA0KDQpJIHNl ZS4uIEFueXdheXMsIHRoYW5rcyBmb3IgdGhlIHJlcGx5LiANCg0KQWN0dWFsbHksIEkgdHJpZWQg dG8gbm90IG9ubHkgcmViYXNlIHRoaXMgcGF0Y2ggc2VyaWVzIHRvIHRoZSBjdXJyZW50DQptYWlu bGluZSwgYnV0IGFsc28gdG8gYWRkIHg4NiBzdXBwb3J0LiBUaGlzIGdhdmUgbWUgZGVlcGVyDQp1 bnN0ZXJzdGFuZGluZyBvZiB0aGUgaW5uZXIgd29ya2luZ3MuIEF0IGxlYXN0IEkgaG9wZSBzbyA6 KQ0KDQpBbnl3YXlzLCBJIHdhbnQgdG8gZGlzY3VzcyB0aGUgbWF0dGVyIGJlZm9yZSBjb250aW51 aW5nIHJld29ya2luZyB0aGUNCnBhdGNoZXMuIFRoZSBnb2FsIG9mIHRob3NlIHBhdGNoZXMgaXMg dG8gYWNjb3VudCBndWVzdCB0aW1lIG1vcmUNCnByZWNpc2VseS4gDQoNClJpZ2h0IG5vdyBJIGNh biBzZWUgb25seSB0d28gbWFpbiByZWFzb25zLCB3aGVuIGd1ZXN0IGNhbiBiZSBjaGFyZ2VkDQpm b3IgYSB0aW1lIGl0IGRpbmRuJ3QgdXNlZDogaW50ZXJydXB0cyBhbmQgc29mdCBpcnFzLiANCg0K LSBkb19zb2Z0aXJxKCkgaXMgY2FsbGVkIGV2ZXJ5IHRpbWUgd2UgbGVhdmUgaHlwZXJ2aXNvciBt b2RlLiBJdCBpcw0KdXNlZCB0byBkbyBob3VzZWtlZXBpbmcgZm9yIHRoZSBoeXBlcnZpc29yIGl0 c2VsZi4gQnV0LCBzb21lIHJhbmRvbQ0KZ3Vlc3Qgd2lsbCBjaGFyZ2VkIGZvciB0aW1lIHNwZW50 IGluIGRvX3NvZnRpcnEoKSB1bmxlc3MgdGhpcyBmdW5jdGlvbg0KaXMgbm90IGNhbGxlZCBvbiBh IGlkbGUgdmNwdS4NCg0KLSBhbHNvLCBwQ1BVIGNhbiBiZSBpbnRlcnJ1cHRlZCBieSBJUlEgYXNz aWduZWQgdG8gc29tZSBvdGhlciBndWVzdCBvcg0KdG8gaHlwZXJ2aXNvciBpdHNlbGYuIEJ1dCB0 aW1lIHNwZW50IGluIGludGVycnVwdCBoYW5kbGVyIHdpbGwgYmUNCmNoYXJnZWQgZm9yIGEgZ3Vl c3QgYmVpbmcgaW50ZXJydXB0ZWQuDQoNClNvLCBiYXNpY2FsbHksIHRvIGFjY291bnQgZ3Vlc3Qg dGltZSBjb3JyZWN0bHksIHdlIG5lZWQgdG8gc3Vic3RyYWN0DQp0aW1lIHNwZW50IGluIGRvX3Nv ZnRpcnEoKSBhbmQgaW4gZG9fSVJRKCkuIA0KDQpBY3R1YWxseSwgd2UgY2FuIGNoYXJnZSB0aGUg Y29ycmVjdCBndWVzdCBmb3IgdGltZSBzcGVudCBpbiBkb19JUlEoKSwNCmJlY2F1c2UgaGFuZGxl ciBjb2RlIHdpbGwgZXZlbnR1YWxseSBrbm93IHRhcmdldCB2Q1BVIGZvciB0aGUNCmludGVycnVw dC4gVGhlcmUgaXMgdGVjaG5pY2FsIHByb2JsZW0gd2l0aCBpbnRlcnJ1cHQgbmVzdGluZy4gV2Ug d2lsbA0KbmVlZCBzb21lIHN0YWNrIHRvIHRyYWNrIG5lc3RpbmcgY29ycmVjdGx5LiBCdXQgdGhp cyBpcyBkb2FibGUuDQoNCkp1c3QgZm9yIHN0YXRpc3RpY2FsIHB1cnBvc2VzIHdlIGNhbiB0cmFj ayBoeXBlcnZpc29yIHRpbWUgc29td2hlcmUsDQpidXQgaXQgaXMgbm90IG5lZWRlZCBmb3Igc2No ZWR1bGluZyBkZWNpc2lvbnMuDQoNCkFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCg0K From xen-devel-bounces@lists.xenproject.org Tue Jun 02 03:49:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 03:49:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfxvW-0007F3-OT; Tue, 02 Jun 2020 03:49:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfxvU-0007Ey-4X for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 03:49:20 +0000 X-Inumbo-ID: 08ee76be-a484-11ea-ab8b-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 08ee76be-a484-11ea-ab8b-12813bfff9fa; Tue, 02 Jun 2020 03:49:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591069757; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ExLd1Z+1FIxt0ntrrBRLTV4rcrryp6L3gYgD3JMEe7Y=; b=NBW72FDhpLe52v1SNV4xZxz7ETgpbVoM3nIswTun+gGALr12gJT6LUgiw7MJ3cHcfeQm85 KxuhG4vInCiXzLemhm3NFPfU0BKeDgjF/dOwKC4HfQ40lJKltjnhaMQpEFvdnTs3kuGePW d1ZkPilbswuTPfodPk0smjD72ZZFUhk= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-513-v18-1bDFPyKc62xwSlhAWQ-1; Mon, 01 Jun 2020 23:49:16 -0400 X-MC-Unique: v18-1bDFPyKc62xwSlhAWQ-1 Received: by mail-wr1-f70.google.com with SMTP id m14so817680wrj.12 for ; Mon, 01 Jun 2020 20:49:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=UPZhIAGyj/VLbIsoUlC2KngQ5PLwTgQRP4hRk68ZAN8=; b=UpTxBq2qegW9ICRJClvBrPLzUrq7PYtOVMIDkL0C2uVJS3S9eVktkAucUrdEnFI/JB Mu/l0nPxgQUK5rEpE33joWO0OIOAeEo3E1z7QNalbwT/yIwTR1/ylaW9llWvn7T4qABK YV9wOD/epGEALPGwRW6UcJl/u9LSN3+O5GVDuySnyGeN/qQio/8qc2AW0R7bXkQC/Tcq 8zZVDqyuaWiWsaP2Rf0s89k0BZ+VP+6BG2XO/Gk3vGYGw/B6ME9B/KdtEohAZ4J3oPet Uo/rnCifsdeF+BZbL+9UpTVokibf3yTyrVww3Pzcqk85dO7rKwAr2ZXYc6YA+iL2BI3j 72aw== X-Gm-Message-State: AOAM530Q5hpNmzLdecSxS8o6+p342tVlQqAtWLjNYvon8EzUXxnHVqfI qCwlZbvP3bQ91FUSWH+qGW8r9f5Mg88r6/PnrfG3U2ebDpUbD91IvBFowygQ+ExewMJfciSuWBv YtO1FsMWf+rkVcHunJn8i0T5RL8o= X-Received: by 2002:a5d:4a43:: with SMTP id v3mr25958765wrs.115.1591069755171; Mon, 01 Jun 2020 20:49:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbFuz2uv/TDCU4M0qN37P/g2y+Wa4iddh/8yNcs/CsBmvsOG4NKyvS+2vtx6Nf23TXqpMcXQ== X-Received: by 2002:a5d:4a43:: with SMTP id v3mr25958746wrs.115.1591069754999; Mon, 01 Jun 2020 20:49:14 -0700 (PDT) Received: from redhat.com (bzq-109-64-41-91.red.bezeqint.net. [109.64.41.91]) by smtp.gmail.com with ESMTPSA id g18sm1578601wme.17.2020.06.01.20.49.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 20:49:14 -0700 (PDT) Date: Mon, 1 Jun 2020 23:49:11 -0400 From: "Michael S. Tsirkin" To: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= Subject: Re: [PATCH v2 0/8] hw: Fix some incomplete memory region size Message-ID: <20200601234822-mutt-send-email-mst@kernel.org> References: <20200601142930.29408-1-f4bug@amsat.org> MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-1-f4bug@amsat.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , Paul Durrant , Andrew Jeffery , Helge Deller , qemu-devel@nongnu.org, qemu-trivial@nongnu.org, qemu-arm@nongnu.org, =?iso-8859-1?Q?Herv=E9?= Poussineau , Joel Stanley , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson , qemu-ppc@nongnu.org, =?iso-8859-1?Q?C=E9dric?= Le Goater Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 01, 2020 at 04:29:22PM +0200, Philippe Mathieu-Daudé wrote: > Series fully reviewed. > > Since v1: > - Add parenthesis on the Xen patch (Paul Durrant) > - Add Peter's R-b tags PCI things: Reviewed-by: Michael S. Tsirkin I'll queue pci patches in my tree. > memory_region_set_size() handle the 16 Exabytes limit by > special-casing the UINT64_MAX value. > This is not a problem for the 32-bit maximum, 4 GiB, but > in some places we incorrectly use UINT32_MAX instead of > 4 GiB, and end up missing 1 byte in the memory region. > > This series fixes the cases I encountered. > Also included few patches while reviewing, I replaced some > magic values by the IEC binary prefix equivalent. > > Regards, > > Phil. > > Philippe Mathieu-Daudé (8): > hw/arm/aspeed: Correct DRAM container region size > hw/pci-host/prep: Correct RAVEN bus bridge memory region size > hw/pci/pci_bridge: Correct pci_bridge_io memory region size > hw/pci/pci_bridge: Use the IEC binary prefix definitions > hw/pci-host: Use the IEC binary prefix definitions > hw/hppa/dino: Use the IEC binary prefix definitions > hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions > target/i386/cpu: Use the IEC binary prefix definitions > > hw/arm/aspeed.c | 2 +- > hw/hppa/dino.c | 4 ++-- > hw/i386/xen/xen-hvm.c | 3 ++- > hw/pci-host/i440fx.c | 3 ++- > hw/pci-host/prep.c | 2 +- > hw/pci-host/q35.c | 2 +- > hw/pci-host/versatile.c | 5 +++-- > hw/pci/pci_bridge.c | 7 ++++--- > target/i386/cpu.c | 2 +- > 9 files changed, 17 insertions(+), 13 deletions(-) > > -- > 2.21.3 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 04:17:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 04:17:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfyM7-0001QE-1I; Tue, 02 Jun 2020 04:16:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfpBm-00041O-LR for xen-devel@lists.xenproject.org; Mon, 01 Jun 2020 18:29:34 +0000 X-Inumbo-ID: d5e29be0-a435-11ea-81bc-bc764e2007e4 Received: from mailout01.mx.bawue.net (unknown [193.7.176.62]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d5e29be0-a435-11ea-81bc-bc764e2007e4; Mon, 01 Jun 2020 18:29:32 +0000 (UTC) Received: from n-dimensional.de (p5b17584c.dip0.t-ipconnect.de [91.23.88.76]) (Authenticated sender: pdim@bawue.de) by smtp.bawue.net (Postfix) with ESMTPSA id 6B0A320623; Mon, 1 Jun 2020 20:25:37 +0200 (CEST) Date: Mon, 1 Jun 2020 20:25:29 +0200 From: Hans Ulrich Niedermann To: Daniel Kiper Subject: Re: [BOOTLOADER SPECIFICATION RFC] The bootloader log format for TrenchBoot and others Message-ID: <20200601202529.6936930b@n-dimensional.de> In-Reply-To: <20200529112735.qln44ds6z7djheof@tomti.i.net-space.pl> References: <20200529112735.qln44ds6z7djheof@tomti.i.net-space.pl> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanner: SAV Dynamic Interface 2.6.0, Engine: 3.77.1, SAV: 5.75 (9763E680) on relay01.mx.bawue.net using milter-sssp 0.1.0 X-Virus-Scan: Found to be clean. X-Mailman-Approved-At: Tue, 02 Jun 2020 04:16:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: dpsmith@apertussolutions.com, alexander.burmashev@oracle.com, krystian.hebel@3mdeb.com, hpa@zytor.com, michal.zygowski@3mdeb.com, The development of GNU GRUB , x86@kernel.org, javierm@redhat.com, kanth.ghatraju@oracle.com, ross.philipson@oracle.com, xen-devel@lists.xenproject.org, leif@nuviainc.com, trenchboot-devel@googlegroups.com, alec.brown@oracle.com, mtottenh@akamai.com, konrad.wilk@oracle.com, phcoder@gmail.com, piotr.krol@3mdeb.com, ard.biesheuvel@linaro.org, andrew.cooper3@citrix.com, linux-kernel@vger.kernel.org, mjg59@google.com, eric.snowberg@oracle.com, pjones@redhat.com, lukasz.hawrylko@linux.intel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 29 May 2020 13:27:35 +0200 Daniel Kiper wrote: > Below you can find my rough idea of the bootloader log format which is > generic thing but initially will be used for TrenchBoot work. I > discussed this proposal with Ross and Daniel S. So, the idea went > through initial sanitization. Now I would like to take feedback from > other folks too. So, please take a look and complain... > > In general we want to pass the messages produced by the bootloader to > the OS kernel and finally to the userspace for further processing and > analysis. Below is the description of the structures which will be > used for this thing. This should mention that this about having one contiguous block of memory which contains a struct bootloader_log. > struct bootloader_log_msgs Why the plural with the trailing letter s in the struct name? This looks like a single message to me, and should thus be signular without a trailing letter s. > { > grub_uint32_t level; > grub_uint32_t facility; > char type[]; > char msg[]; > } How would this work? How could a compiler know where msg starts? gcc just reports "error: flexible array member not at end of struct" here as there is no way of knowing. Where are the sizes of type[] and msg[] defined? Only implicitly by just having two NUL terminated strings right after each other? That would mean you need to change the struct to struct bootloader_log_msg { grub_uint32_t level; grub_uint32_t facility; char strings[]; } and have anyone parsing this structure walk through all characters in strings[] looking for NULs to eventually find out where the msg string actually starts. This looks at least a bit ugly to me, unless you absolutely need to save the last bit of code and data memory in the bootloader. To help find where the msg actually starts without needing to look for a NUL character, you could add a struct member showing where the msg string actually starts within strings[]: struct bootloader_log_msg { grub_uint32_t level; grub_uint32_t facility; grub_uint32_t msg_start; char strings[]; } This msg_start value could be defined as an character offset into strings[]. Then accessing msg->strings or &msg->strings[0] would access the type string, and &msg->strings[msg_ofs] would access the message: struct bootloader_log_msg *msg = ...; printf("msg type: %s\n", &msg->strings[0]); printf("msg: %s\n", &msg->strings[msg->msg_start]); For quick parsing of the messages, having a "grub_uint32_t size" struct member to quickly skip the current struct bootloader_log_msg completely and jump directly to the next struct would be helpful, regardless of how the strings are actually stored: struct bootloader_log_msg { grub_uint32_t level; grub_uint32_t facility; grub_uint32_t size; [ ... string storage ... ] } > struct bootloader_log > { > grub_uint32_t version; > grub_uint32_t producer; > grub_uint32_t size; > grub_uint32_t next_off; > bootloader_log_msgs msgs[]; > } > > The members of struct bootloader_log: > - version: the bootloader log format version number, 1 for now, > - producer: the producer/bootloader type; we can steal some values > from linux/Documentation/x86/boot.rst:type_of_loader, > - size: total size of the log buffer including the bootloader_log > struct, "size in bytes"? > - next_off: offset in bytes, from start of the bootloader_log > struct, of the next byte after the last log message in the msgs[]; > i.e. the offset of the next available log message slot, It appears to me that next_off is only interesting for code which appends log messages to that structure. For reading such a struct, next_off is useless and could thus be a private variable inside that bootloader which is not passed on to a next stage bootloader or an OS kernel. So specifying next_off as something other than a "reserved" uint32_t is for when you have a chain of bootloaders which all append messages to that buffer, and you want to avoid all the bootloaders having to parse the messages from the previous bootloader's messages in order to find out where to append messages. If that is the intention, this procedure should at least be mentioned somewhere. I am also missing any mention of memory alignment. With the number of CPUs in the field which cannot directly read misaligned words increasing, specifying a 4 byte or 8 byte alignment for these structures could significantly reduce the code complexity for such CPUs at the cost of a few bytes of memory. And while on the topic of memory layout: With all these uint32_t values, is this only for a 32bit protocol, or will this remain 32bit even for otherwise 64bit code, or what is the plan here? > - msgs: the array of log messages. > > The members of struct bootloader_log_msgs: > - level: similar to syslog meaning; can be used to differentiate > normal messages from debug messages; exact interpretation depends > on the current producer/bootloader type specified in the > bootloader_log.producer, > - facility: similar to syslog meaning; can be used to differentiate > the sources of the messages, e.g. message produced by networking > module; exact interpretation depends on the current > producer/bootloader type specified in the bootloader_log.producer, > - type: similar to the facility member but NUL terminated string > instead of integer; this will be used by GRUB for messages printed > using grub_dprintf(), Just to get an idea of what type[] is supposed to be for: What part of grub_dprintf() is supposed to end up in the type[] string? "file:line"? > - msg: the bootloader log message, NUL terminated string. > > Note: The bootloaders are free to use/ignore any given set of level, > facility and/or type members. Though the usage of these members > has to be clearly defined. Ignored integer members should be set > to 0. Ignored type member should contain an empty NUL terminated > string. msg member is mandatory but can be an empty NUL > terminated string. Is there any idea of what is supposed to happen when too many messages are being generated to fit into the memory area allocated for the log messages? One could copy the data into a bigger memory area and continue appending messages, or just stop appending messages, or copy all the messages towards the beginning of msgs[] by a few messages such that a few older messages are being lost by being overwritten and new space for appending messages is created. In any case, the consumer of the log messages may be interested in knowing when some messages have been lost. > Taking into account [1] and [2] I want to make this functionality > generic as much as possible. So, this bootloader log can be used with > any bootloader and OS kernel. However, initially the functionality > will be implemented for the Linux kernel and its boot protocol. > > In case of Linux kernel the pointer to the bootloader_log struct > should be passed from the bootloader to the kernel through the > boot_params and the bootloader_log struct contents should be exposed > via sysfs. E.g. somewhere at /sys/kernel/debug or /sys/kernel/tracing > or maybe we should create new /sys/bootloader/log node. > > If everybody is OK with this rough proposal then I will start working > on making it a part of Multiboot2 specification (the text above is > just raw description of the idea; it is not final text which land > into the spec). If you see better place for this thing just drop me a > line. Starting purely from a Grub and Multiboot 2 point of view, this Bootloader Log Message spec would fit into a @subsection of the "Boot Information" @section, even if that @subsection would be a large one. Eventually, the Linux docs, the Grub docs, the Multiboot2 docs, BSD kernel docs etc all need to reference the Bootloader Log Message spec (Is "BLM spec" already taken? Or "Bootloader Log Message Block" aka "BLMB"?). If the Bootloader Log Message spec does not need to describe for each and every bit how it is supposed to work with Grub, Linux, BSD, etc, keeping the Bootloader Log Message inside Multiboot2 would be OK. Otherwise, I would consider the Bootloader Log Message spec not being its own separate spec being a bit weird. > Daniel > > [1] > https://lists.gnu.org/archive/html/grub-devel/2019-10/msg00107.html > [2] > https://lists.gnu.org/archive/html/grub-devel/2019-11/msg00079.html Uli From xen-devel-bounces@lists.xenproject.org Tue Jun 02 05:13:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 05:13:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzEF-0006sm-CG; Tue, 02 Jun 2020 05:12:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzED-0006s2-TD for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 05:12:45 +0000 X-Inumbo-ID: ad2b2488-a48f-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ad2b2488-a48f-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 05:12:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=40E6PteJwaLi+rniTnFJJa2rRB8PWrUrgseei4uYSd8=; b=bRNyqSKHv1hJ6By9kaBUrkjsq Oqxi1alqlg5t25FBstLujEZwf8bMoJVehr1BhQDCUUyDrO9Poi3ZYdHGA1h3p2r9J8jf1QMcvbaBA IvBGYMt4uMfCoW7Ryo0Z3X7lF90YO/SUomWQTQj+HAA4Szuu4NFy9WzdkrDJTMrPYfuD0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzE5-000284-AS; Tue, 02 Jun 2020 05:12:37 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jfzE4-0005sc-Up; Tue, 02 Jun 2020 05:12:36 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jfzE4-0002Nc-Tv; Tue, 02 Jun 2020 05:12:36 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150606: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0 X-Osstest-Versions-That: linux=3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 From: osstest service owner Date: Tue, 02 Jun 2020 05:12:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150606 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150606/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 15 guest-saverestore fail REGR. vs. 150590 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150590 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150590 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150590 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150590 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150590 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150590 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150590 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150590 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150590 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: linux 9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0 baseline version: linux 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 Last test of basis 150590 2020-06-01 02:00:27 Z 1 days Testing same since 150606 2020-06-01 19:40:10 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: AceLan Kao Adam Thomson Aishwarya R Aishwarya R Akinobu Mita Alex Qiu Alistair Francis Andrej Picej Andy Shevchenko Angelo Dureghello Anson Huang Ard Biesheuvel Aristeu Rozanski Arnd Bergmann Ashish Kumar Baolin Wang Barry Song Bartosz Golaszewski Benjamin Gaignard Benjamin Herrenschmidt Bjorn Andersson Boris Brezillon Borislav Petkov Bruno Meneguele Charles Keepax Chris Ruehl Christophe JAILLET Christophe Kerello Christopher Hill Clement Leger Colin Ian King Corentin Labbe Corentin Labbe Daniel Jordan Dejin Zheng dillon min Dinghao Liu Dinh Nguyen Eric Biggers Ethon Paul Etienne Carriere Evan Green Feng Tang Florian Fainelli Geert Uytterhoeven Georgy Vlasov Gilad Ben-Yossef Guenter Roeck Gustavo A. R. Silva Hadar Gat hailizheng Han Xu Hans Verkuil Hao Fang Herbert Xu Hui Tang Iskren Chernev Iuliana Prodan J. Bruce Fields Jacko Dirks Jaegeuk Kim Jarkko Nikula Jarkko Sakkinen Jason Yan Jay Fang John Garry Jonathan Bakker Jonathan Cameron Josh Lehan Jules Irenge Jungseung Lee Justin Chen Kai Ye Kamal Dasu Kangmin Park kbuild test robot Kees Cook Krzysztof Kozlowski Kuldeep Singh Kunihiko Hayashi Lee Jones Liang Jin J Linus Torvalds Linus Walleij Lionel Debieve Longfang Liu Lukas Bulwahn Lukas Wunner Marco Felsch Marek Szyprowski Mark Brown Markus Elfring Martin Sperl Matti Vaittinen Maxim Kaurkin Michael Ellerman (powerpc) Michael Walle Michal Orzel Michał Mirosław Mihai Carabas Nathan Chancellor Naveen Krishna Chatradhi Nicolas Pitre Nicolas Saenz Julienne Nicolas Toromanoff Pali Rohár Patrice Chotard Pavel Tatashin Peng Fan Peng Ma Peter Rosin Petr Mladek Qiuxu Zhuo Rafał Hibner Ramil Zaripov Randy Dunlap # build-tested Reinette Chatre Rikard Falkeborn Robin Gong Sanjay R Mehta Sascha Hauer Sebastian Duda Serge Semin Sergey Senozhatsky Shengju Zhang Shreyas Joshi Shukun Tan Stephan Mueller Stephan Müller Stephen Rothwell Tang Bin Tetsuo Handa Thomas Hebb Tiezhu Yang Tim Harvey Tom Lendacky Tony Luck Vinod Koul Vladimir Oltean Wan Ahmad Zainie Wei Yongjun Weili Qian WeiXiong Liao Wolfram Sang Yang Shen Yicong Yang Yuechao Zhao Zaibo Xu Zhang Shengju Zhou Wang zhouchuangao zhouchuangao Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 3d77e6a8804a..9bf9511e3d9f 9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Tue Jun 02 05:30:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 05:30:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzVG-000085-0f; Tue, 02 Jun 2020 05:30:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzVD-000080-OG for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 05:30:20 +0000 X-Inumbo-ID: 255ab7c8-a492-11ea-9dbe-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 255ab7c8-a492-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 05:30:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591075818; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qzoUxl/WLYb+063eW2TIeYv68TR2Bx8Y1d1JB0krKgI=; b=ZyGRy+SXgEYFXq6JNlVCwDe92HiUNkW0jfkU9jj0A29vb5iDmx1FPR2H0rd+hWSy9Lk5nq pDdmTDnpZjX674rtKeuAO30Z4HAxwo/iqsfuIPnlxX+Hp4ZqyopHzuI/DvbOFr4vTLjXSM bIO+cpXummYQb2EWtcWLxwJeO7+7B7I= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-388-0NEp_VBUMfeNpBWwLBdMqg-1; Tue, 02 Jun 2020 01:30:17 -0400 X-MC-Unique: 0NEp_VBUMfeNpBWwLBdMqg-1 Received: by mail-wm1-f71.google.com with SMTP id j128so498769wmj.6 for ; Mon, 01 Jun 2020 22:30:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qzoUxl/WLYb+063eW2TIeYv68TR2Bx8Y1d1JB0krKgI=; b=f5nVgZS4aPeCSpz7HOxgQFnB2whtQz4ju7VKnY61AT7GFuL0MwVvvFOBTWLP5HlV0R eGGhg6BOTvRxfgDLUZ9fwCA/4Dq8qpk+9EDpffUK4aceorsS+su2Ok1ODnlAHYjVvtN+ wvmLbAuaFdvYojV+s0BQEDzBMujlP8R5v4LkPkb7O+Ao3Y1DxaCtAsMX/1hT6ZC1Rm3f BrEaxdOb7b1oTvDrb4/c64oua7DwIaentGvpmgdRwT9tX9GkeDajUeUy39aH/tnELAC2 +wtfzD+HEV7Kw50fXtwuWZYZkNheM9uyoHs3Ayf7rKgT9a0zKznJdrUs29dJLaxNofCa n0Xg== X-Gm-Message-State: AOAM533NtBWOQRhUMRyLJpIUA46AtVisCKXVldWm+QcGcOVo6i1Jfivu Lxf+DN2TNO32UDaHqlRFotpJW//SdNbtJsJkkkphkbRSP5aZoN2zxPm8HMWf475DEOJRyYtW845 Pj8zA6PRQEV1xF7wKlE/YpX7IRb0= X-Received: by 2002:adf:fb0f:: with SMTP id c15mr26298839wrr.410.1591075815776; Mon, 01 Jun 2020 22:30:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxm9pd8/UBwSfLvzSGS3kH8718EtuelpkpKCVpKrXAc490C5Bc8iBs799ATExgZ/w+YruoNzg== X-Received: by 2002:adf:fb0f:: with SMTP id c15mr26298819wrr.410.1591075815494; Mon, 01 Jun 2020 22:30:15 -0700 (PDT) Received: from redhat.com (bzq-109-64-41-91.red.bezeqint.net. [109.64.41.91]) by smtp.gmail.com with ESMTPSA id 30sm2040428wrd.47.2020.06.01.22.30.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 22:30:14 -0700 (PDT) Date: Tue, 2 Jun 2020 01:30:11 -0400 From: "Michael S. Tsirkin" To: Gerd Hoffmann Subject: Re: [PATCH v3 0/4] microvm: memory config tweaks Message-ID: <20200602012911-mutt-send-email-mst@kernel.org> References: <20200529073957.8018-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: <20200529073957.8018-1-kraxel@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , Paul Durrant , qemu-devel@nongnu.org, imammedo@redhat.com, Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , philmd@redhat.com, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 09:39:53AM +0200, Gerd Hoffmann wrote: > With more microvm memory config tweaks split this into its owns series, > the microvm acpi patch series is already big enough ... Okay. We might want to add pci to microvm and maybe we'll need more space then, but let's leave this for another day. Reviewed-by: Michael S. Tsirkin > v2: > - use 3G split. > - add patch to move virtio-mmio region. > - pick up acks & reviews. > v3: > - fix xen build. > - pick up acks & reviews. > > take care, > Gerd > > Gerd Hoffmann (4): > microvm: use 3G split unconditionally > microvm: drop max-ram-below-4g support > x86: move max-ram-below-4g to pc > microvm: move virtio base to 0xfeb00000 > > include/hw/i386/microvm.h | 2 +- > include/hw/i386/pc.h | 2 ++ > include/hw/i386/x86.h | 4 ---- > hw/i386/microvm.c | 35 +---------------------------- > hw/i386/pc.c | 46 +++++++++++++++++++++++++++++++++++++++ > hw/i386/pc_piix.c | 10 ++++----- > hw/i386/pc_q35.c | 10 ++++----- > hw/i386/x86.c | 46 --------------------------------------- > hw/i386/xen/xen-hvm.c | 2 +- > 9 files changed, 61 insertions(+), 96 deletions(-) > > -- > 2.18.4 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 06:00:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 06:00:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzyN-0002nm-5p; Tue, 02 Jun 2020 06:00:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzyL-0002nh-Ll for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 06:00:25 +0000 X-Inumbo-ID: 599ed8f8-a496-11ea-8993-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 599ed8f8-a496-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 06:00:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 09BD5AFA7; Tue, 2 Jun 2020 06:00:25 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 1/2] tools: check return value of asprintf() in xenhypfs Date: Tue, 2 Jun 2020 08:00:20 +0200 Message-Id: <20200602060021.23289-2-jgross@suse.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200602060021.23289-1-jgross@suse.com> References: <20200602060021.23289-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Andrew Cooper , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" asprintf() can fail, so check its return value. Additionally fix a memory leak in xenhypfs. Reported-by: Andrew Cooper Signed-off-by: Juergen Gross --- tools/misc/xenhypfs.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/misc/xenhypfs.c b/tools/misc/xenhypfs.c index 158b901f42..5145b8969f 100644 --- a/tools/misc/xenhypfs.c +++ b/tools/misc/xenhypfs.c @@ -148,9 +148,14 @@ static int xenhypfs_tree_sub(char *path, unsigned int depth) printf("%*s%s%s\n", depth * 2, "", ent[i].name, ent[i].type == xenhypfs_type_dir ? "/" : ""); if (ent[i].type == xenhypfs_type_dir) { - asprintf(&p, "%s%s%s", path, (depth == 1) ? "" : "/", ent[i].name); + if (asprintf(&p, "%s%s%s", path, (depth == 1) ? "" : "/", + ent[i].name) < 0) { + ret = 2; + break; + } if (xenhypfs_tree_sub(p, depth + 1)) ret = 2; + free(p); } } -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 06:00:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 06:00:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzyP-0002nx-E2; Tue, 02 Jun 2020 06:00:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzyO-0002ns-HM for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 06:00:28 +0000 X-Inumbo-ID: 59a040db-a496-11ea-ab98-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 59a040db-a496-11ea-ab98-12813bfff9fa; Tue, 02 Jun 2020 06:00:25 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 252CDAFB0; Tue, 2 Jun 2020 06:00:26 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 2/2] tools: make libxenhypfs interface more future proof Date: Tue, 2 Jun 2020 08:00:21 +0200 Message-Id: <20200602060021.23289-3-jgross@suse.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200602060021.23289-1-jgross@suse.com> References: <20200602060021.23289-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Andrew Cooper , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" As compilers are free to choose the width of an enum they should be avoided in stable interfaces when declaring a variable. So the struct xenhypfs_dirent definition should be modified to have explicitly sized members for type and encoding and the related enums should be defined separately. Additionally it is better to have a larger flags member in that struct with the "writable" indicator occupying only a single bit. This will make future additions easier. Suggested-by: Andrew Cooper Signed-off-by: Juergen Gross --- tools/libs/hypfs/core.c | 2 +- tools/libs/hypfs/include/xenhypfs.h | 31 +++++++++++++++++------------ tools/misc/xenhypfs.c | 3 ++- 3 files changed, 21 insertions(+), 15 deletions(-) diff --git a/tools/libs/hypfs/core.c b/tools/libs/hypfs/core.c index d4309b5ae2..c91e165705 100644 --- a/tools/libs/hypfs/core.c +++ b/tools/libs/hypfs/core.c @@ -204,7 +204,7 @@ static void xenhypfs_set_attrs(struct xen_hypfs_direntry *entry, dirent->type = xenhypfs_type_blob; } - dirent->is_writable = entry->max_write_len; + dirent->flags = entry->max_write_len ? XENHYPFS_FLAG_WRITABLE : 0; } void *xenhypfs_read_raw(xenhypfs_handle *fshdl, const char *path, diff --git a/tools/libs/hypfs/include/xenhypfs.h b/tools/libs/hypfs/include/xenhypfs.h index ab157edceb..25432d2a16 100644 --- a/tools/libs/hypfs/include/xenhypfs.h +++ b/tools/libs/hypfs/include/xenhypfs.h @@ -26,22 +26,27 @@ struct xentoollog_logger; typedef struct xenhypfs_handle xenhypfs_handle; +enum xenhypfs_type { + xenhypfs_type_dir, + xenhypfs_type_blob, + xenhypfs_type_string, + xenhypfs_type_uint, + xenhypfs_type_int, + xenhypfs_type_bool, +}; + +enum xenhypfs_encoding { + xenhypfs_enc_plain, + xenhypfs_enc_gzip +}; + struct xenhypfs_dirent { char *name; size_t size; - enum { - xenhypfs_type_dir, - xenhypfs_type_blob, - xenhypfs_type_string, - xenhypfs_type_uint, - xenhypfs_type_int, - xenhypfs_type_bool - } type; - enum { - xenhypfs_enc_plain, - xenhypfs_enc_gzip - } encoding; - bool is_writable; + unsigned short type; + unsigned short encoding; + unsigned int flags; +#define XENHYPFS_FLAG_WRITABLE 0x00000001 }; xenhypfs_handle *xenhypfs_open(struct xentoollog_logger *logger, diff --git a/tools/misc/xenhypfs.c b/tools/misc/xenhypfs.c index 5145b8969f..5da24aed90 100644 --- a/tools/misc/xenhypfs.c +++ b/tools/misc/xenhypfs.c @@ -125,7 +125,8 @@ static int xenhypfs_ls(char *path) } else { for (i = 0; i < n; i++) printf("%s r%c %s\n", xenhypfs_type(ent + i), - ent[i].is_writable ? 'w' : '-', ent[i].name); + (ent[i].flags & XENHYPFS_FLAG_WRITABLE) ? 'w' : '-', + ent[i].name); free(ent); } -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 06:00:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 06:00:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzyU-0002qd-Ma; Tue, 02 Jun 2020 06:00:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jfzyT-0002oG-CB for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 06:00:33 +0000 X-Inumbo-ID: 599edfa6-a496-11ea-ab98-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 599edfa6-a496-11ea-ab98-12813bfff9fa; Tue, 02 Jun 2020 06:00:25 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EB5DDAFA0; Tue, 2 Jun 2020 06:00:25 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 0/2] tools: some fixes for the hypervisor file system Date: Tue, 2 Jun 2020 08:00:19 +0200 Message-Id: <20200602060021.23289-1-jgross@suse.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Juergen Gross (2): tools: check return value of asprintf() in xenhypfs tools: make libxenhypfs interface more future proof tools/libs/hypfs/core.c | 2 +- tools/libs/hypfs/include/xenhypfs.h | 31 +++++++++++++++++------------ tools/misc/xenhypfs.c | 10 ++++++++-- 3 files changed, 27 insertions(+), 16 deletions(-) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 06:03:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 06:03:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg00v-00036d-4X; Tue, 02 Jun 2020 06:03:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg00t-00036X-Ip for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 06:03:03 +0000 X-Inumbo-ID: b76d8c18-a496-11ea-9dbe-bc764e2007e4 Received: from nautica.notk.org (unknown [2001:41d0:1:7a93::1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b76d8c18-a496-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 06:03:02 +0000 (UTC) Received: by nautica.notk.org (Postfix, from userid 1001) id 4FC2AC009; Tue, 2 Jun 2020 08:03:01 +0200 (CEST) Date: Tue, 2 Jun 2020 08:02:46 +0200 From: Dominique Martinet To: Stefano Stabellini Subject: Re: [PATCH v2] 9p/xen: increase XEN_9PFS_RING_ORDER Message-ID: <20200602060246.GA16791@nautica> References: <20200521193242.15953-1-sstabellini@kernel.org> <20200522055847.GA2833@nautica> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, lucho@ionkov.net, ericvh@gmail.com, linux-kernel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Stefano Stabellini wrote on Mon, Jun 01, 2020: > > LGTM, I'll try to find some time to test this by the end of next week or > > will trust you if I can't make it -- ping me around June 1st if I don't > > reply again until then... > > Ping :-) I actually did think about this patch this weekend! . . .but didn't quite make it :/ Anyway, as promised pushed to linux-next, I'll submit this for 5.8 -- Dominique From xen-devel-bounces@lists.xenproject.org Tue Jun 02 06:50:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 06:50:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg0kj-0007Jr-Rx; Tue, 02 Jun 2020 06:50:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg0ki-0007Jm-Cj for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 06:50:24 +0000 X-Inumbo-ID: 5149c576-a49d-11ea-ab9e-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5149c576-a49d-11ea-ab9e-12813bfff9fa; Tue, 02 Jun 2020 06:50:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jxrn252LR/aWcXY86V5pwwlEExH3p10U75Y+w5ArSSA=; b=ZS7XGCMSrc7FOA6HrkM00vEI2 nNk2cq3hjBKFJ14uKaFfmSG/iGBs3BKZo4Hu/VkYmFuM8JnSkyaTyCuNUwUzyP1cWAm9K5FZTrxZb Z4KsgaDDCVjzU7UJk1S55BybCAndvSiLIrMf8eZVlezHmKRE16JPziskbLRJ6nAHKXuIA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg0ka-00049b-O1; Tue, 02 Jun 2020 06:50:16 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jg0ka-0004g4-Eb; Tue, 02 Jun 2020 06:50:16 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jg0ka-0001hE-Du; Tue, 02 Jun 2020 06:50:16 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 150612: regressions - FAIL X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression libvirt:build-i386-libvirt:libvirt-build:fail:regression libvirt:build-arm64-libvirt:libvirt-build:fail:regression libvirt:build-armhf-libvirt:libvirt-build:fail:regression libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking X-Osstest-Versions-This: libvirt=ab55a8a0871207de5fe194f55cbbcecae7a3cfe9 X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5 From: osstest service owner Date: Tue, 02 Jun 2020 06:50:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150612 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/150612/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-build fail REGR. vs. 146182 build-i386-libvirt 6 libvirt-build fail REGR. vs. 146182 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 146182 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 146182 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a version targeted for testing: libvirt ab55a8a0871207de5fe194f55cbbcecae7a3cfe9 baseline version: libvirt a1cd25b919509be2645dbe6f952d5263e0d4e4e5 Last test of basis 146182 2020-01-17 06:00:23 Z 137 days Failing since 146211 2020-01-18 04:18:52 Z 136 days 127 attempts Testing same since 150612 2020-06-02 04:19:20 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Arnaud Patard Artur Puzio Bjoern Walk Boris Fiuczynski Chen Hanxiao Chris Jester-Young Christian Borntraeger Christian Ehrhardt Christian Schoenebeck Collin Walling Cornelia Huck Daniel Henrique Barboza Daniel P. Berrangé Daniel Veillard Dario Faggioli Erik Skultety Gaurav Agrawal Han Han Jaak Ristioja Jamie Strandboge Jim Fehlig Jiri Denemark Jonathon Jongsma Julio Faracco Ján Tomko Laine Stump Leonid Bloch Liao Pingfang Lin Ma Marc-André Lureau Marek Marczykowski-Górecki Mark Asselstine Mauro S. M. Rodrigues Michal Privoznik Nikolay Shirokovskiy Paolo Bonzini Pavel Hrdina Pavel Mores Peter Krempa Philipp Hahn Pino Toscano Prathamesh Chavan Rafael Fonseca Richard W.M. Jones Rikard Falkeborn Ryan Moeller Sahid Orentino Ferdjaoui Sebastian Mitterle Seeteena Thoufeek Stefan Berger Stefan Berger Stefan Hajnoczi Thomas Huth Tobin Feldman-Fitzthum Tomáš Golembiovský Wu Qingliang Xu Yandong Yan Wang Yi Li Your Name Zhang Bo zhenwei pi Zhenyu Zheng Zhimin Feng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 19603 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 02 07:21:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 07:21:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1F0-0001a2-C2; Tue, 02 Jun 2020 07:21:42 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1Ey-0001Zx-De for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 07:21:40 +0000 X-Inumbo-ID: b2a7cec2-a4a1-11ea-aba2-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b2a7cec2-a4a1-11ea-aba2-12813bfff9fa; Tue, 02 Jun 2020 07:21:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 86086B016; Tue, 2 Jun 2020 07:21:39 +0000 (UTC) Subject: Re: Xen XSM/FLASK policy, grub defaults, etc. To: Julien Grall References: <24270.35349.838484.116865@mariner.uk.xensource.com> <0D83AAA6-A205-4256-8A38-CC8122AC063D@citrix.com> <24272.59646.746545.343358@mariner.uk.xensource.com> <4a8e7cf2-8f63-d4d2-e051-9484a5b8c8ed@suse.com> <96F32637-E410-4EC8-937A-CFC8BE724352@citrix.com> <24273.8332.662607.125522@mariner.uk.xensource.com> <7eaa7541-f698-b29b-b4b3-1f40fc37c5d7@xen.org> <63838ce9-8dbf-aacf-521d-97540758a945@suse.com> <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> From: Jan Beulich Message-ID: <1a08fcca-e890-a735-682d-635e9d11f2a4@suse.com> Date: Tue, 2 Jun 2020 09:21:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Stefano Stabellini , "cjwatson@debian.org" , Wei Liu , Andrew Cooper , George Dunlap , "xen-devel@lists.xenproject.org" , Ian Jackson , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.05.2020 19:24, Julien Grall wrote: > On 29/05/2020 16:11, Jan Beulich wrote: >> On 29.05.2020 17:05, Julien Grall wrote: >>> On 29/05/2020 15:47, Ian Jackson wrote: >>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."): >>>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal. >>>> >>>> I propose the following behaviour by updste-grub: >>>> >>>> 1. Look for an ELF note, TBD. If it's found, make XSM boot entries. >>>> (For now, skip this step, since the ELF note is not defined.) >>> >>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such >>> thing for the kernel/xen (actually the final binary is not even an ELF). >> >> Ouch - of course. Is there anything similar one could employ there? > > In the past, we discussed about adding support for note in the zImage > (arm32 kernel format) but I never got the chance to pursue the discussion. > > With Juergen's hypfs series, the hypervisor now embbed the .config. Is > it possible to extract it? How easy is it to reliably find a random blob of gzip-ed data in an otherwise unstructured (as in: no ELF sections, and hence no way to put the data of interest into a separate section for easy recognition) binary? Also don't forget that the embedding of .config is an optional thing. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 07:37:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 07:37:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1UA-0002dt-S5; Tue, 02 Jun 2020 07:37:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1U9-0002do-Kv for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 07:37:21 +0000 X-Inumbo-ID: e41d6884-a4a3-11ea-9947-bc764e2007e4 Received: from mail-wr1-x434.google.com (unknown [2a00:1450:4864:20::434]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e41d6884-a4a3-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 07:37:20 +0000 (UTC) Received: by mail-wr1-x434.google.com with SMTP id e1so2278338wrt.5 for ; Tue, 02 Jun 2020 00:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=smgXUEnbUOqCTa7UdLSxwfWpNtvZxyfJM2S+DjegPqs=; b=IP4GX8B78/gZwlNy6ZC9Vc9T7B3ANhEu4HwKGSE+KMxBsbGk6NsvIHaVnK6HNQsBWw O1VZBaDFjxJbl27Jn7KEuCyGdZ1tCLsYszgPRj+mYMICIRdLwTbIftgdt+80rKfaHwQ/ dqMX6ddrM16k/bhOHyW3rAMo8ArBPm+Su1UrF1DRwGI/iOKXKaak7vIWtqqSs0347oOS RVSN07W4dzpktcSWdiJQAyK5kbqeZtJkOVTYbxt5y1wQAnSssAdepNWwCunM2xHkOtid 8pPnplg/ZocqUN2wsReOQwOblMtlMA0k/AzZYEbh6V9ZajqngET5jtrCqcwDDBLB/rhU dx+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=smgXUEnbUOqCTa7UdLSxwfWpNtvZxyfJM2S+DjegPqs=; b=oNMZIyMYnsCauAP3wy834o8ooz7pWVo0rvkFzqs8+8T18Kv9sQI2iYR79aRfPPJzOl M2QtGK81bwcEiLcaet60/wJUhx+M3xKqQxogV+/so/14ulpzMC8u9QSSuSdSlqw2tEzQ SDyG3XyczTY7lO764yRVheZZojsHq6UTwIeQ25YtoD5gr/KChsBJCADA93vRv0XppdAv QPONF2Vh77PvPyU+qqCmcdNVtsGcHcfb9J5/V+2/JjKUUDaxnXwPQP2f8o3y2TW4pICV OftlIRcPfv/ArZtUI12jU+HuOIIW9g8Bw6dFoUaYScfiRbzBvcfKRWUrJXtMcAyqckq7 JV4Q== X-Gm-Message-State: AOAM531lFARcwzvX9HBVVzgZqYP8JxmEWH6WZVjHayHofup9oBSBdl7r Kjz1wLoC1O96sTZfj1gHuZQ= X-Google-Smtp-Source: ABdhPJxzJE9qZ5cOwQ7LBpa2EkvN7bGPuPAWpHmy8ZSFfUUCSUwZje++z7e/gUg9koICqQ9jb0yIqg== X-Received: by 2002:adf:e84c:: with SMTP id d12mr24777097wrn.284.1591083439864; Tue, 02 Jun 2020 00:37:19 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id a15sm2413742wra.86.2020.06.02.00.37.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 00:37:19 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Tamas K Lengyel'" , "'George Dunlap'" References: <000c01d63826$6d125900$47370b00$@xen.org> <4017F2B3-BB9B-4E9F-813C-6FE68BA0D568@citrix.com> In-Reply-To: Subject: RE: [PATCH v19 for-4.14 00/13] VM forking Date: Tue, 2 Jun 2020 08:37:17 +0100 Message-ID: <002401d638b0$a5460f80$efd22e80$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLopxTEy5NbImEQwB/v9n5io2F1+gMP6IwmAaxohFACR164haZn9NSQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Julien Grall' , 'Kevin Tian' , 'Stefano Stabellini' , 'Tamas K Lengyel' , 'Jan Beulich' , 'Wei Liu' , 'Andrew Cooper' , 'Jun Nakajima' , 'Ian Jackson' , 'Anthony Perard' , 'xen-devel' , 'Roger Pau Monne' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Tamas K Lengyel > Sent: 01 June 2020 19:38 > To: George Dunlap > Cc: paul@xen.org; Tamas K Lengyel ; xen-devel = devel@lists.xenproject.org>; Kevin Tian ; = Stefano Stabellini > ; Jun Nakajima ; Wei = Liu ; Andrew Cooper > ; Ian Jackson ; Jan = Beulich ; > Anthony Perard ; Julien Grall = ; Roger Pau Monne > > Subject: Re: [PATCH v19 for-4.14 00/13] VM forking >=20 > On Mon, Jun 1, 2020 at 11:11 AM George Dunlap = wrote: > > > > > > > > > On Jun 1, 2020, at 4:07 PM, Paul Durrant = wrote: > > > > > >> -----Original Message----- > > >> From: Xen-devel On = Behalf Of Tamas K Lengyel > > >> Sent: 01 June 2020 14:22 > > >> To: xen-devel@lists.xenproject.org > > >> Cc: Kevin Tian ; Stefano Stabellini = ; Tamas K > Lengyel > > >> ; Jun Nakajima ; = Wei Liu ; Andrew > Cooper > > >> ; Ian Jackson = ; George Dunlap > > >> ; Tamas K Lengyel = ; Jan Beulich > ; > > >> Anthony PERARD ; Julien Grall = ; Roger Pau Monn=C3=A9 > > >> > > >> Subject: [PATCH v19 for-4.14 00/13] VM forking > > > > > > Hi, > > > > > > This series looks to be largely un-acked so, since we are now = past the freeze date, I don't > really think it can go into 4.14. Is there a particular reason that = you think it should be considered? > > > > Tamas=E2=80=99 project itself mainly uses libxc and below, as I = understand; and so getting patches 1 and 2 > in would be an important milestone; both have had R-b=E2=80=99s before = the feature freeze. Arguably patches 1 > and 2 are a bug fix. Patch 1 is missing VMX (or a general x86). >=20 > Correct. The first two patches going in would decide whether we will > be able to use the 4.14 release without having to carry out-of-tree > patches. Although as things stand at the moment regarding all the bugs > being discovered in 4.13 and 4.14 we will likely still have to > backport all of these patches to 4.12 by hand. That sounds like a reasonable justification. Maintainers/committers, can we please get those patches in a.s.a.p.? Paul From xen-devel-bounces@lists.xenproject.org Tue Jun 02 07:41:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 07:41:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1Y3-0003T8-Ct; Tue, 02 Jun 2020 07:41:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1Y1-0003T2-Uj for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 07:41:21 +0000 X-Inumbo-ID: 73a4afee-a4a4-11ea-8993-bc764e2007e4 Received: from mail-wr1-x42b.google.com (unknown [2a00:1450:4864:20::42b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 73a4afee-a4a4-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 07:41:21 +0000 (UTC) Received: by mail-wr1-x42b.google.com with SMTP id l11so2322045wru.0 for ; Tue, 02 Jun 2020 00:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=J2qzcc0mM6+evxoK3O/eOKWETXObcDS1zCOMTzA+6+8=; b=gAL25/v9ExCE1WBka8eJ/dQ2kRbDKpMpYWf7XcKQfCjPIbpNy80IJjPleRH7PdZoXI DyJGmY6LOZWC527IMq0w928o5f1Lss0/HIlAwqHdDzqw2e2Ka0+EyORGNC8VHnWfigK8 Pc33BIhelYqHpPP2vUzy2+rrDUE/VEAi7sbQqZmYZOXea09/s/YTXREbGHabysz62MOY B3nu9A/wgy1xeige/D2M3Ej5HBjpOXjpR1IisuBayBvjb2Z9JQ6Xw93U6IOKedjpv9Jy E9e0R1Nxd0aHYzCD9u5LmWydfgMrE87ZEsrJD5YRYDMJgzQ/2QDomPwvfe6XpTqgfScE 9I4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=J2qzcc0mM6+evxoK3O/eOKWETXObcDS1zCOMTzA+6+8=; b=UIYi5shuKNoKmzH/L0h4+CXd6ic54RuyxZ8j8LdPmScF8OrpmExhibiIWZxMZn/Yh7 OSrs8PTRDId00FI+S8PnPRWaOyFk3j64cww5uA10k8TLjJtjU3rjvvp2bZswpeUUSICq i8CZgqlZmpoAYCDgERxb6fmyuPKrjaX7pQrrvRsfobB0gwgb3v5Gl3mgOKXhoM0WGxax 5xrq3NlAo5DoCKDjpox9GBpJEQRc3WFPfZsAZYMusrMqo6ekwF2hKSpGP6JfgAzBM4Dx dSVsVtXKAJ0kOFMt4CyV3B3xOWPDLmDb2DW2tOEdibX2UtZMr1jJUjA5g4fz0aPo3Tnj objQ== X-Gm-Message-State: AOAM531WnyMcjTKtSLU2WPgaLTTHGaeazkY9iFnSQbERILbdv7A4B18s AdR5PDD/XAWZ/tHqxge1srAy2ExuCKk= X-Google-Smtp-Source: ABdhPJzF1FLdDbyKjJBq7bScm6ULi33CXiK9QomLLNWD+YhDQDKHooQmgNBcitVJDw5+HFKQ4hrkDA== X-Received: by 2002:a5d:4d92:: with SMTP id b18mr26664313wru.296.1591083680684; Tue, 02 Jun 2020 00:41:20 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id l5sm2137061wml.27.2020.06.02.00.41.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 00:41:20 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Juergen Gross'" , References: <20200602060021.23289-1-jgross@suse.com> In-Reply-To: <20200602060021.23289-1-jgross@suse.com> Subject: RE: [PATCH-for-4.14 0/2] tools: some fixes for the hypervisor file system Date: Tue, 2 Jun 2020 08:41:19 +0100 Message-ID: <003301d638b1$34e8d7d0$9eba8770$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFvI0wj0/JVpgBgdcOTnMUdilmoB6mTG5Hw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of Juergen Gross > Sent: 02 June 2020 07:00 > To: xen-devel@lists.xenproject.org > Cc: Juergen Gross ; Ian Jackson ; Wei Liu > Subject: [PATCH-for-4.14 0/2] tools: some fixes for the hypervisor file system > > Juergen Gross (2): > tools: check return value of asprintf() in xenhypfs > tools: make libxenhypfs interface more future proof > > tools/libs/hypfs/core.c | 2 +- > tools/libs/hypfs/include/xenhypfs.h | 31 +++++++++++++++++------------ > tools/misc/xenhypfs.c | 10 ++++++++-- > 3 files changed, 27 insertions(+), 16 deletions(-) Release-acked-by: Paul Durrant > > -- > 2.26.2 > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 07:43:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 07:43:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1a5-0003bF-PB; Tue, 02 Jun 2020 07:43:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1a3-0003aw-Sq for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 07:43:27 +0000 X-Inumbo-ID: be7efc18-a4a4-11ea-9947-bc764e2007e4 Received: from mail-wm1-x336.google.com (unknown [2a00:1450:4864:20::336]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id be7efc18-a4a4-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 07:43:27 +0000 (UTC) Received: by mail-wm1-x336.google.com with SMTP id j198so1607130wmj.0 for ; Tue, 02 Jun 2020 00:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=afxo1YQhq8R7tiHBruiDK5cfcarcjaUlnwjiDlODfu8=; b=rjo9dKcKbAs8wTTD5FBH4a5g+lAZPaxTQ6acl+H6oy7kejefmSdqDdRv6RwZaKGKPI Xvdpl1JYjI6As7ziQHGnIFGp3jzRAC00waGXeABmtieYF/i8yqQ/R59CnPQjsuhFxUC7 o77ojgbmE2Z2dmDN0fv8W3nuftT+jkyrXtCED6z0nE/VZ/oDlIz33UrwDrw4cSocnvuD fYkCv6ju8Kl+crqdtxK+ddS1W/5iM7LKq6g9YzlEhaK43xrovJnH6Jz35daeGx41xbaT AuNzqIyTrysz4G2Y1tdteqwNinRjnOwXgRaayyoAtygZICblJkZmAVYOZkhxFrt0kNs/ sbYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=afxo1YQhq8R7tiHBruiDK5cfcarcjaUlnwjiDlODfu8=; b=pooBOpRsJ5OPN2XEuv0ouoJBE1CpRncWKaUnySewEBjw+vP9+WBACiyBF79L7zHw16 C5vX83Rk1ga/816B9ARnTLuZaT1fiAQ6j/22L0SMz2iI/6DaqxjhplnAV855URiIm1Wv MNuH4niiIQkadaxOyq9gnCDP2qLtpYhHob43i3n1woGjlEv8Yy12dVWPG6wrBiLXq68+ 5sbYPimKaU44K8HurPbVMCSqICgEjStnyQFnE8tg7Gw5GSn+8oZywSZUlEcQ6hSK/J/S 9RZFdwhRLfdJxLVgPUf/e/KopM1NsSmgJLmNeoChjB2UL8n6YLbFk4ea16yuNmkY0le8 wDlg== X-Gm-Message-State: AOAM530m3m9riyWPUCLG+Y9IJShoZlkpdAbUtUFGM+iwz/58kArha4ey ekXBeNUsCUHxFEqwUvE+Y1E= X-Google-Smtp-Source: ABdhPJyzYzsB2gz1MGSl3SQAh8o+sU/a+d1sKn5/kO8bvSpsx682/I7qpqdwk/eB5sy4pR6+pgYWbw== X-Received: by 2002:a1c:28c5:: with SMTP id o188mr2779879wmo.62.1591083806130; Tue, 02 Jun 2020 00:43:26 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id j18sm2606270wrn.59.2020.06.02.00.43.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 00:43:25 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Tamas K Lengyel'" , References: In-Reply-To: Subject: RE: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks Date: Tue, 2 Jun 2020 08:43:24 +0100 Message-ID: <003401d638b1$7f99efd0$7ecdcf70$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLopxTEy5NbImEQwB/v9n5io2F1+gFjtKKwppT2/KA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Kevin Tian' , 'Stefano Stabellini' , 'Julien Grall' , 'Jan Beulich' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Tamas K Lengyel' , 'Jun Nakajima' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = Tamas K Lengyel > Sent: 01 June 2020 14:22 > To: xen-devel@lists.xenproject.org > Cc: Kevin Tian ; Stefano Stabellini = ; Tamas K Lengyel > ; Jun Nakajima ; Wei = Liu ; Andrew Cooper > ; Ian Jackson ; = George Dunlap > ; Tamas K Lengyel ; Jan = Beulich ; > Julien Grall ; Roger Pau Monn=C3=A9 = > Subject: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt = injection for forks >=20 > When running VM forks without device models (QEMU), it may > be undesirable for Xen to inject interrupts. When creating such forks = from > Windows VMs we have observed the kernel trying to process interrupts > immediately after the fork is executed. However without QEMU running = such > interrupt handling may not be possible because it may attempt to = interact with > devices that are not emulated by a backend. In the best case scenario = such > interrupt handling would only present a detour in the VM forks' = execution > flow, but in the worst case as we actually observed can completely = stall it. > By disabling interrupt injection a fuzzer can exercise the target code = without > interference. For other use-cases this option probably doesn't make = sense, > that's why this is not enabled by default. >=20 > Forks & memory sharing are only available on Intel CPUs so this only = applies > to vmx. Note that this is part of the experimental VM forking feature = that's > completely disabled by default and can only be enabled by using > XEN_CONFIG_EXPERT during compile time. >=20 > Signed-off-by: Tamas K Lengyel > Reviewed-by: Roger Pau Monn=C3=A9 Release-acked-by: Paul Durrant > --- > xen/arch/x86/hvm/vmx/intr.c | 6 ++++++ > xen/arch/x86/mm/mem_sharing.c | 6 +++++- > xen/include/asm-x86/hvm/domain.h | 2 +- > xen/include/public/memory.h | 3 +++ > 4 files changed, 15 insertions(+), 2 deletions(-) >=20 > diff --git a/xen/arch/x86/hvm/vmx/intr.c b/xen/arch/x86/hvm/vmx/intr.c > index 000e14af49..80bfbb4787 100644 > --- a/xen/arch/x86/hvm/vmx/intr.c > +++ b/xen/arch/x86/hvm/vmx/intr.c > @@ -256,6 +256,12 @@ void vmx_intr_assist(void) > if ( unlikely(v->arch.vm_event) && v->arch.vm_event->sync_event ) > return; >=20 > +#ifdef CONFIG_MEM_SHARING > + /* Block event injection for VM fork if requested */ > + if ( unlikely(v->domain->arch.hvm.mem_sharing.block_interrupts) ) > + return; > +#endif > + > /* Crank the handle on interrupt state. */ > pt_vector =3D pt_update_irq(v); >=20 > diff --git a/xen/arch/x86/mm/mem_sharing.c = b/xen/arch/x86/mm/mem_sharing.c > index 19922ab5d1..c428fd16ce 100644 > --- a/xen/arch/x86/mm/mem_sharing.c > +++ b/xen/arch/x86/mm/mem_sharing.c > @@ -2106,7 +2106,8 @@ int = mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) > rc =3D -EINVAL; > if ( mso.u.fork.pad ) > goto out; > - if ( mso.u.fork.flags & ~XENMEM_FORK_WITH_IOMMU_ALLOWED ) > + if ( mso.u.fork.flags & > + ~(XENMEM_FORK_WITH_IOMMU_ALLOWED | = XENMEM_FORK_BLOCK_INTERRUPTS) ) > goto out; >=20 > rc =3D = rcu_lock_live_remote_domain_by_id(mso.u.fork.parent_domain, > @@ -2134,6 +2135,9 @@ int = mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg) > rc =3D = hypercall_create_continuation(__HYPERVISOR_memory_op, > "lh", = XENMEM_sharing_op, > arg); > + else if ( !rc && (mso.u.fork.flags & = XENMEM_FORK_BLOCK_INTERRUPTS) ) > + d->arch.hvm.mem_sharing.block_interrupts =3D true; > + > rcu_unlock_domain(pd); > break; > } > diff --git a/xen/include/asm-x86/hvm/domain.h = b/xen/include/asm-x86/hvm/domain.h > index 95fe18cddc..9d247baf4d 100644 > --- a/xen/include/asm-x86/hvm/domain.h > +++ b/xen/include/asm-x86/hvm/domain.h > @@ -67,7 +67,7 @@ struct hvm_ioreq_server { > #ifdef CONFIG_MEM_SHARING > struct mem_sharing_domain > { > - bool enabled; > + bool enabled, block_interrupts; >=20 > /* > * When releasing shared gfn's in a preemptible manner, recall = where > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h > index dbd35305df..850bd72c52 100644 > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -536,7 +536,10 @@ struct xen_mem_sharing_op { > } debug; > struct mem_sharing_op_fork { /* OP_FORK */ > domid_t parent_domain; /* IN: parent's domain id = */ > +/* Only makes sense for short-lived forks */ > #define XENMEM_FORK_WITH_IOMMU_ALLOWED (1u << 0) > +/* Only makes sense for short-lived forks */ > +#define XENMEM_FORK_BLOCK_INTERRUPTS (1u << 1) > uint16_t flags; /* IN: optional settings */ > uint32_t pad; /* Must be set to 0 */ > } fork; > -- > 2.25.1 >=20 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 07:44:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 07:44:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1ay-0003fs-2M; Tue, 02 Jun 2020 07:44:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1aw-0003fg-4t for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 07:44:22 +0000 X-Inumbo-ID: defd9fda-a4a4-11ea-81bc-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id defd9fda-a4a4-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 07:44:21 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id u26so1603764wmn.1 for ; Tue, 02 Jun 2020 00:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=koEIlgZs2d8H8p9FpJD2bIP4CIQi8B1hPb8TlcbuqXM=; b=k2rziECOt3ZeGegY1Zx3VBvuRF7L7cEpXPVkyPC6mB4Vxo02fLYhzl5ZfzgGeHlg7e 2q+Mq+LYR/74aob+VoVXU2X806FtJ0Edi1wa2klf6pDa+eosQvhWX92fV+/TbuGGoqoq zlDROpn8oH1V2CIlAPkgKW93PLePR2JGTzPZL4/TmCkKqOGSzImwBIyJnm6PolZD4sZw 6OZyjGhRjKT6c49nAzbQeoF415H+VW2IlupdsrRiGgPM5BiIi34dT6CbsFKR1Eo/SiHu 69ltY+bjZqJ9LXTD00xg17bdgPiSkGWdIeRI5g1y0X39v4pbnu2DlSSgSCId6k0dqyYA +38w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=koEIlgZs2d8H8p9FpJD2bIP4CIQi8B1hPb8TlcbuqXM=; b=ng+E2lZBt+MqPhwDqLf+r4LqkgJV43rb2No8YvYLX/ASErrneKRyYhfni1oa0Cv+Bx QaAOw3E4DIU+3/JeOWqJYaQvPwOl7UgpZkHaXG3J7driV4I+FiIAZNdnSDmu/68+2FX1 DW1916FB7Of0T90dFpRKlB8hG4D6seNGI1J2vh6rPvcfQIK3R+EAULURq2zzjZQK8EWF j+R4nqwvgId0cJnhmzwqH7YQS6U+NhC2MkKhyb5diLBwsEI/Y7MWCl4bMXDlUplRuWf5 fAyPE9gjpgibRFQ/VwKrVpQgCva3SpRA0J0LU2/LJIe7dzAOKhaRGbLd8mmn4BSGDvip hbJw== X-Gm-Message-State: AOAM532upYJuiT5Gw4icXPUElPZPtHqQGYJ/d0hNfRbh3ttIxtb1OF3f 4O5zGUGzsS2UdME7uKxQkWQ= X-Google-Smtp-Source: ABdhPJylMVUeMguFDgXcEPBRHx8WISVCKGbn4b1ucGZiU66wJ9R5JSqFoEZpxMM/GSvxtvlbddw8Qw== X-Received: by 2002:a05:600c:29a:: with SMTP id 26mr2832697wmk.76.1591083860708; Tue, 02 Jun 2020 00:44:20 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id c65sm2359428wme.8.2020.06.02.00.44.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 00:44:20 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Tamas K Lengyel'" , References: <03b382a38c62b5431c63d00f9acffacf43b55c1d.1591017086.git.tamas.lengyel@intel.com> In-Reply-To: <03b382a38c62b5431c63d00f9acffacf43b55c1d.1591017086.git.tamas.lengyel@intel.com> Subject: RE: [PATCH v19 for-4.14 02/13] tools/libxc: xc_memshr_fork with interrupts blocked Date: Tue, 2 Jun 2020 08:44:19 +0100 Message-ID: <003501d638b1$a03038d0$e090aa70$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLopxTEy5NbImEQwB/v9n5io2F1+gJjgvcxpoz40jA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Ian Jackson' , 'Wei Liu' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = Tamas K Lengyel > Sent: 01 June 2020 14:22 > To: xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Tamas K Lengyel = ; Wei Liu > ; Roger Pau Monn=C3=A9 > Subject: [PATCH v19 for-4.14 02/13] tools/libxc: xc_memshr_fork with = interrupts blocked >=20 > Toolstack side for creating forks with interrupt injection blocked. >=20 > Signed-off-by: Tamas K Lengyel > Reviewed-by: Roger Pau Monn=C3=A9 > Acked-by: Ian Jackson Release-acked-by: Paul Durrant > --- > tools/libxc/include/xenctrl.h | 3 ++- > tools/libxc/xc_memshr.c | 4 +++- > 2 files changed, 5 insertions(+), 2 deletions(-) >=20 > diff --git a/tools/libxc/include/xenctrl.h = b/tools/libxc/include/xenctrl.h > index f9e17ae424..5eeee1de46 100644 > --- a/tools/libxc/include/xenctrl.h > +++ b/tools/libxc/include/xenctrl.h > @@ -2241,7 +2241,8 @@ int xc_memshr_range_share(xc_interface *xch, > int xc_memshr_fork(xc_interface *xch, > uint32_t source_domain, > uint32_t client_domain, > - bool allow_with_iommu); > + bool allow_with_iommu, > + bool block_interrupts); >=20 > /* > * Note: this function is only intended to be used on short-lived = forks that > diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c > index 2300cc7075..a6cfd7dccf 100644 > --- a/tools/libxc/xc_memshr.c > +++ b/tools/libxc/xc_memshr.c > @@ -240,7 +240,7 @@ int xc_memshr_debug_gref(xc_interface *xch, > } >=20 > int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t = domid, > - bool allow_with_iommu) > + bool allow_with_iommu, bool block_interrupts) > { > xen_mem_sharing_op_t mso; >=20 > @@ -251,6 +251,8 @@ int xc_memshr_fork(xc_interface *xch, uint32_t = pdomid, uint32_t domid, >=20 > if ( allow_with_iommu ) > mso.u.fork.flags |=3D XENMEM_FORK_WITH_IOMMU_ALLOWED; > + if ( block_interrupts ) > + mso.u.fork.flags |=3D XENMEM_FORK_BLOCK_INTERRUPTS; >=20 > return xc_memshr_memop(xch, domid, &mso); > } > -- > 2.25.1 >=20 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 07:55:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 07:55:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1lh-0004da-4U; Tue, 02 Jun 2020 07:55:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1lg-0004dV-0W for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 07:55:28 +0000 X-Inumbo-ID: 6b26939e-a4a6-11ea-abaa-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6b26939e-a4a6-11ea-abaa-12813bfff9fa; Tue, 02 Jun 2020 07:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gw50YR9qN1TFRldofTyrGB2vfBHZ5IexJO8LOHubZQw=; b=Lzi9QVOybm4t90MbZM40DPtQf Rl3OuuNgA1oJ+hra5zdAqtrToRtv4OltWha9A/SXGn3IfX9PsEVf8J7K0Jmuh+et74UOLZKY7yhF6 mQpcveqWMiaaZ8zCFwtBwanf+JJdpuXRPEOolEkluXy74Fax7FfiMgCXbarmZM9RjYfVo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg1lc-0005WP-Gz; Tue, 02 Jun 2020 07:55:24 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jg1lc-00071D-73; Tue, 02 Jun 2020 07:55:24 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jg1lc-0001P8-5E; Tue, 02 Jun 2020 07:55:24 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150611: all pass - PUSHED X-Osstest-Versions-This: ovmf=4403bbd7c0964144ea72f27e2bc8048b0c0a26e1 X-Osstest-Versions-That: ovmf=568eee7cf319fa95183c8d3b5e8dcf6e078ab8b3 From: osstest service owner Date: Tue, 02 Jun 2020 07:55:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150611 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150611/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 4403bbd7c0964144ea72f27e2bc8048b0c0a26e1 baseline version: ovmf 568eee7cf319fa95183c8d3b5e8dcf6e078ab8b3 Last test of basis 150392 2020-05-27 02:39:30 Z 6 days Testing same since 150611 2020-06-02 03:09:41 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Bret Barkelew Bret Barkelew jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 568eee7cf3..4403bbd7c0 4403bbd7c0964144ea72f27e2bc8048b0c0a26e1 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Tue Jun 02 08:27:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 08:27:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2GL-0007om-41; Tue, 02 Jun 2020 08:27:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2GJ-0007oe-78 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 08:27:07 +0000 X-Inumbo-ID: d47784b2-a4aa-11ea-abae-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d47784b2-a4aa-11ea-abae-12813bfff9fa; Tue, 02 Jun 2020 08:27:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uAPnBN0B4iiAtoT1qh9vzb5X2lKrkrGg9r+FZnrxvXc=; b=jvN6CTfgVziaINzNNtIcusZh+D qDsIAnNFkFNEtVXW8SIdykF+XRBtevf3/lQ+oWVZ1We5AVoiSkMVZY8WwWcyfx4HaGh6nYjkRSruY RIDIc8y7PDYvZ/mMLYQEKJg10s0jbmvFV+5LY2y0JYHrYBkvX40skXOY+n9rlJFJel/U=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2G8-0006is-TD; Tue, 02 Jun 2020 08:26:56 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jg2G8-0006sF-MA; Tue, 02 Jun 2020 08:26:56 +0000 Subject: Re: Xen XSM/FLASK policy, grub defaults, etc. To: Jan Beulich References: <24270.35349.838484.116865@mariner.uk.xensource.com> <0D83AAA6-A205-4256-8A38-CC8122AC063D@citrix.com> <24272.59646.746545.343358@mariner.uk.xensource.com> <4a8e7cf2-8f63-d4d2-e051-9484a5b8c8ed@suse.com> <96F32637-E410-4EC8-937A-CFC8BE724352@citrix.com> <24273.8332.662607.125522@mariner.uk.xensource.com> <7eaa7541-f698-b29b-b4b3-1f40fc37c5d7@xen.org> <63838ce9-8dbf-aacf-521d-97540758a945@suse.com> <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> <1a08fcca-e890-a735-682d-635e9d11f2a4@suse.com> From: Julien Grall Message-ID: <6673669b-19c7-306c-8988-8156a1e49d85@xen.org> Date: Tue, 2 Jun 2020 09:26:54 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <1a08fcca-e890-a735-682d-635e9d11f2a4@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Stefano Stabellini , "cjwatson@debian.org" , Wei Liu , Andrew Cooper , George Dunlap , "xen-devel@lists.xenproject.org" , Ian Jackson , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02/06/2020 08:21, Jan Beulich wrote: > On 29.05.2020 19:24, Julien Grall wrote: >> On 29/05/2020 16:11, Jan Beulich wrote: >>> On 29.05.2020 17:05, Julien Grall wrote: >>>> On 29/05/2020 15:47, Ian Jackson wrote: >>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, etc."): >>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to also have an intermediate solution that works right now, even if it’s not optimal. >>>>> >>>>> I propose the following behaviour by updste-grub: >>>>> >>>>> 1. Look for an ELF note, TBD. If it's found, make XSM boot entries. >>>>> (For now, skip this step, since the ELF note is not defined.) >>>> >>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have such >>>> thing for the kernel/xen (actually the final binary is not even an ELF). >>> >>> Ouch - of course. Is there anything similar one could employ there? >> >> In the past, we discussed about adding support for note in the zImage >> (arm32 kernel format) but I never got the chance to pursue the discussion. >> >> With Juergen's hypfs series, the hypervisor now embbed the .config. Is >> it possible to extract it? > > How easy is it to reliably find a random blob of gzip-ed data in an > otherwise unstructured (as in: no ELF sections, and hence no way to > put the data of interest into a separate section for easy > recognition) binary? As I pointed out in another reply, Linux is already doing it (see scripts/extract-ikconfig). In fact I was able to extract the .config from an Linux Arm64 Image. AFAICT, Linux will look up with to specific value in the kernel image which surround the gzipped .config. If Linux is able to do it, then we should be able to do it. I don't know whether this is 100% reliable, however we could make sure your .config is towards the end of the image. So it reduces the chance you find something different. > Also don't forget that the embedding of .config > is an optional thing. I don't really see this as a blocker. Embedding the .config can be made mandatory going forward. This is not going to significantly increase the size of Xen and would help to when debugging as you could exactly know which .config was used. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 02 08:30:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 08:30:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2Jz-0000CN-JF; Tue, 02 Jun 2020 08:30:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2Jx-0000CI-UU for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 08:30:53 +0000 X-Inumbo-ID: 5e0423de-a4ab-11ea-abae-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5e0423de-a4ab-11ea-abae-12813bfff9fa; Tue, 02 Jun 2020 08:30:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 928CBAC4A; Tue, 2 Jun 2020 08:30:52 +0000 (UTC) Subject: Re: Xen XSM/FLASK policy, grub defaults, etc. To: Julien Grall , Jan Beulich References: <24270.35349.838484.116865@mariner.uk.xensource.com> <0D83AAA6-A205-4256-8A38-CC8122AC063D@citrix.com> <24272.59646.746545.343358@mariner.uk.xensource.com> <4a8e7cf2-8f63-d4d2-e051-9484a5b8c8ed@suse.com> <96F32637-E410-4EC8-937A-CFC8BE724352@citrix.com> <24273.8332.662607.125522@mariner.uk.xensource.com> <7eaa7541-f698-b29b-b4b3-1f40fc37c5d7@xen.org> <63838ce9-8dbf-aacf-521d-97540758a945@suse.com> <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> <1a08fcca-e890-a735-682d-635e9d11f2a4@suse.com> <6673669b-19c7-306c-8988-8156a1e49d85@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <6919b0e1-3b2b-4864-b0a8-162da9c1d9ec@suse.com> Date: Tue, 2 Jun 2020 10:30:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <6673669b-19c7-306c-8988-8156a1e49d85@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , "cjwatson@debian.org" , Wei Liu , Andrew Cooper , George Dunlap , "xen-devel@lists.xenproject.org" , Ian Jackson , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.20 10:26, Julien Grall wrote: > > > On 02/06/2020 08:21, Jan Beulich wrote: >> On 29.05.2020 19:24, Julien Grall wrote: >>> On 29/05/2020 16:11, Jan Beulich wrote: >>>> On 29.05.2020 17:05, Julien Grall wrote: >>>>> On 29/05/2020 15:47, Ian Jackson wrote: >>>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, >>>>>> etc."): >>>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to >>>>>>> also have an intermediate solution that works right now, even if >>>>>>> it’s not optimal. >>>>>> >>>>>> I propose the following behaviour by updste-grub: >>>>>> >>>>>>     1. Look for an ELF note, TBD.  If it's found, make XSM boot >>>>>> entries. >>>>>>        (For now, skip this step, since the ELF note is not defined.) >>>>> >>>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't have >>>>> such >>>>> thing for the kernel/xen (actually the final binary is not even an >>>>> ELF). >>>> >>>> Ouch - of course. Is there anything similar one could employ there? >>> >>> In the past, we discussed about adding support for note in the zImage >>> (arm32 kernel format) but I never got the chance to pursue the >>> discussion. >>> >>> With Juergen's hypfs series, the hypervisor now embbed the .config. Is >>> it possible to extract it? >> >> How easy is it to reliably find a random blob of gzip-ed data in an >> otherwise unstructured (as in: no ELF sections, and hence no way to >> put the data of interest into a separate section for easy >> recognition) binary? > > As I pointed out in another reply, Linux is already doing it (see > scripts/extract-ikconfig). In fact I was able to extract the .config > from an Linux Arm64 Image. > > AFAICT, Linux will look up with to specific value in the kernel image > which surround the gzipped .config. > > If Linux is able to do it, then we should be able to do it. I don't know > whether this is 100% reliable, however we could make sure your .config > is towards the end of the image. So it reduces the chance you find > something different. > >> Also don't forget that the embedding of .config >> is an optional thing. > > I don't really see this as a blocker. Embedding the .config can be made > mandatory going forward. This is not going to significantly increase the > size of Xen and would help to when debugging as you could exactly know > which .config was used. If you can find an embedded .config via a special pattern you can just define a pattern and embed that only in case of a flask-enabled Xen. This would remove the need to make the config option a stable ABI. Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 02 08:39:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 08:39:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2S6-0000Rl-DT; Tue, 02 Jun 2020 08:39:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2S5-0000Rg-QV for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 08:39:17 +0000 X-Inumbo-ID: 8b6e4592-a4ac-11ea-abae-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8b6e4592-a4ac-11ea-abae-12813bfff9fa; Tue, 02 Jun 2020 08:39:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=X/fbmrrcpG02apB1t6aeNgi9uVwvghABUyItqe4N0gs=; b=tzzWr3eGr+UO+kh87MygpfDtn4 AmL43ta/iSH64yPyJvftFjgQZaa9ev3DMY/bJHDaHsM618A75KozBnLhKNPmbmD1hEAUy+TlndJft 0WqxB2QEKOIMilWROnJqJI/+Opd+fjvFYXI8Wbv237kn1Kp4jWTs713b5+odr7WrkkGY=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2S1-0006xm-6N; Tue, 02 Jun 2020 08:39:13 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jg2S0-0007rT-VR; Tue, 02 Jun 2020 08:39:13 +0000 Subject: Re: Xen XSM/FLASK policy, grub defaults, etc. To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Jan Beulich References: <24270.35349.838484.116865@mariner.uk.xensource.com> <0D83AAA6-A205-4256-8A38-CC8122AC063D@citrix.com> <24272.59646.746545.343358@mariner.uk.xensource.com> <4a8e7cf2-8f63-d4d2-e051-9484a5b8c8ed@suse.com> <96F32637-E410-4EC8-937A-CFC8BE724352@citrix.com> <24273.8332.662607.125522@mariner.uk.xensource.com> <7eaa7541-f698-b29b-b4b3-1f40fc37c5d7@xen.org> <63838ce9-8dbf-aacf-521d-97540758a945@suse.com> <429e81a2-80d5-0d50-6352-6471cd4698a8@xen.org> <1a08fcca-e890-a735-682d-635e9d11f2a4@suse.com> <6673669b-19c7-306c-8988-8156a1e49d85@xen.org> <6919b0e1-3b2b-4864-b0a8-162da9c1d9ec@suse.com> From: Julien Grall Message-ID: Date: Tue, 2 Jun 2020 09:39:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <6919b0e1-3b2b-4864-b0a8-162da9c1d9ec@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , "cjwatson@debian.org" , Wei Liu , Andrew Cooper , George Dunlap , "xen-devel@lists.xenproject.org" , Ian Jackson , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Juergen, On 02/06/2020 09:30, Jürgen Groß wrote: > On 02.06.20 10:26, Julien Grall wrote: >> >> >> On 02/06/2020 08:21, Jan Beulich wrote: >>> On 29.05.2020 19:24, Julien Grall wrote: >>>> On 29/05/2020 16:11, Jan Beulich wrote: >>>>> On 29.05.2020 17:05, Julien Grall wrote: >>>>>> On 29/05/2020 15:47, Ian Jackson wrote: >>>>>>> George Dunlap writes ("Re: Xen XSM/FLASK policy, grub defaults, >>>>>>> etc."): >>>>>>>> Which isn’t to say we shouldn’t do it; but it might be nice to >>>>>>>> also have an intermediate solution that works right now, even if >>>>>>>> it’s not optimal. >>>>>>> >>>>>>> I propose the following behaviour by updste-grub: >>>>>>> >>>>>>>     1. Look for an ELF note, TBD.  If it's found, make XSM boot >>>>>>> entries. >>>>>>>        (For now, skip this step, since the ELF note is not defined.) >>>>>> >>>>>> I am afraid the ELF note is a very x86 thing. On Arm, we don't >>>>>> have such >>>>>> thing for the kernel/xen (actually the final binary is not even an >>>>>> ELF). >>>>> >>>>> Ouch - of course. Is there anything similar one could employ there? >>>> >>>> In the past, we discussed about adding support for note in the zImage >>>> (arm32 kernel format) but I never got the chance to pursue the >>>> discussion. >>>> >>>> With Juergen's hypfs series, the hypervisor now embbed the .config. Is >>>> it possible to extract it? >>> >>> How easy is it to reliably find a random blob of gzip-ed data in an >>> otherwise unstructured (as in: no ELF sections, and hence no way to >>> put the data of interest into a separate section for easy >>> recognition) binary? >> >> As I pointed out in another reply, Linux is already doing it (see >> scripts/extract-ikconfig). In fact I was able to extract the .config >> from an Linux Arm64 Image. >> >> AFAICT, Linux will look up with to specific value in the kernel image >> which surround the gzipped .config. >> >> If Linux is able to do it, then we should be able to do it. I don't >> know whether this is 100% reliable, however we could make sure your >> .config is towards the end of the image. So it reduces the chance you >> find something different. >> >>> Also don't forget that the embedding of .config >>> is an optional thing. >> >> I don't really see this as a blocker. Embedding the .config can be >> made mandatory going forward. This is not going to significantly >> increase the size of Xen and would help to when debugging as you could >> exactly know which .config was used. > > If you can find an embedded .config via a special pattern you can just > define a pattern and embed that only in case of a flask-enabled Xen. This is a fair point. However, this would be very specific to flask-enabled Xen. In that case, it might be better to consider a zImage/Image note style on Arm. > This would remove the need to make the config option a stable ABI. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 02 08:43:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 08:43:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2WO-0001I1-VC; Tue, 02 Jun 2020 08:43:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2WO-0001Hw-1G for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 08:43:44 +0000 X-Inumbo-ID: 2924e14c-a4ad-11ea-abae-12813bfff9fa Received: from mail-wr1-f66.google.com (unknown [209.85.221.66]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2924e14c-a4ad-11ea-abae-12813bfff9fa; Tue, 02 Jun 2020 08:43:42 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id y17so2451869wrn.11 for ; Tue, 02 Jun 2020 01:43:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8dypxLySplyxbKkucnutwAQQmF7+T2g+TNYmx/UT01E=; b=I9nvrNiDFaCMfJVUODXJumVgW2vRRL8B2O8O7GZvjeC5pzW3sIKIl4yc/5MlXBuAYm HlGAyL2jun7mdsqkJJLG/SXPONO0VEtGKyAHYg+p3QTuGH7akzncb1Y4dnOO1ADm9kIj 0Hg+Ks0Ud+wOg2lDNhlizPv3QkBrXp9wWB0Crj0yASLWYa9p9Z92ExxRH7lnXgqapnpQ FUh+WdPnjTNxsneVyGV45J5pYwYINh2wnAVk8096xtJZxkgWLjEfhfyAj4w03/LTH5Cb BUY1stgCgnrfmAIE3t6dnaQqMdwQArA8WR77QOs7wFM07boUdU+IB8R6F7WcfZfsWbrF SPJQ== X-Gm-Message-State: AOAM533n4myUb8bfc/HIw1Tmm+sE7DZrXTjmgn8fOqgHWzE46SR6bq5s rG97/TqayENbKV1YtO2OVkU= X-Google-Smtp-Source: ABdhPJw+7eiucoHO/9lp4A4QO/76L3VOoKD9NgQq0M0+mqTLjJ2+MVPIVFIxMLREL0vbGZK9Cwe+pQ== X-Received: by 2002:adf:fdcd:: with SMTP id i13mr24097934wrs.190.1591087421147; Tue, 02 Jun 2020 01:43:41 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id g18sm2496143wme.17.2020.06.02.01.43.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 01:43:40 -0700 (PDT) Date: Tue, 2 Jun 2020 08:43:38 +0000 From: Wei Liu To: Olaf Hering Subject: Re: [PATCH v1] INSTALL: remove TODO section Message-ID: <20200602084338.a55bbjbhal4gbyvh@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: <20200529135303.18457-1-olaf@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200529135303.18457-1-olaf@aepfle.de> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 03:53:03PM +0200, Olaf Hering wrote: > The default value '/' for DESTDIR is unusual, but does probably not hurt. > > Fixes commit f2b40dababedcd8355bf3e85d00baf17f9827131 > Fixes commit 8e986e5a61efeca92b9b268e77957d45d8316ee4 > > Signed-off-by: Olaf Hering Acked-by: Wei Liu Based on the fact that you're the original author of this documentation. :-) Cc Paul. > --- > INSTALL | 7 ------- > 1 file changed, 7 deletions(-) > > diff --git a/INSTALL b/INSTALL > index 72dc4b67dd..0d3eb89f02 100644 > --- a/INSTALL > +++ b/INSTALL > @@ -365,12 +365,5 @@ make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ > DESTDIR=/some/path install > > > -TODO > -==== > - > - - DESTDIR should be empty, not "/" > - - add make uninstall targets > - - replace private path variables as needed (SBINDIR/sbindir) > - - ... > > # vim: tw=72 et From xen-devel-bounces@lists.xenproject.org Tue Jun 02 08:52:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 08:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2el-0002AZ-RB; Tue, 02 Jun 2020 08:52:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2ek-0002AU-4P for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 08:52:22 +0000 X-Inumbo-ID: 5eb059b2-a4ae-11ea-81bc-bc764e2007e4 Received: from mail-wm1-f65.google.com (unknown [209.85.128.65]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5eb059b2-a4ae-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 08:52:21 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id r15so2246806wmh.5 for ; Tue, 02 Jun 2020 01:52:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=AXfrBNb20l0kugH4AbqVdXHLCoJGjbhs7pF82Rmx8cU=; b=MLN+qrzGlc708D0vPX0kykFmPuQocTwFs5cjFbPgDkZ2THTSmhJRa4NVKsXzB5spYY lskt7MCUFTzhMh13rLyFKgPBw/L6okT8SSMZCU2HfGPp2hOaewCjMzFolTk0BXzTlz+g pfkFW6HJ073kBHM///MzESey83LiW+1Y38zyQuqbGDlzEjMnJTTNzTbQxfZe6jomNrT6 SRNBwQ8QSy+5gU95VSApuYhpIf9k2a/nLtPuU0/J64kGCZh8dU30wq6ycKWIRb5SJvo/ itMAugzi9CJvT5qpeXHYb3AywMUj7B/tnuuRmbX/FaxtX4cbPnB84OVwtICDuIxbGJNz ipiA== X-Gm-Message-State: AOAM530K6VCD6NuravsEO1cSRd7eZCHhVJ6KTbqZjf1mHg9NHvLl0OBS BeaKQq8/uFOBFhoElsmTYtE= X-Google-Smtp-Source: ABdhPJyazCE9fYV3sfsQOtAyu0l6qmM0AU5cTVF80Sg2d+jFkkA6x84g6haLXSpF2Ph6jlgPoP5H/Q== X-Received: by 2002:a1c:ed0b:: with SMTP id l11mr3357344wmh.31.1591087940338; Tue, 02 Jun 2020 01:52:20 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id g82sm2488098wmf.1.2020.06.02.01.52.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 01:52:19 -0700 (PDT) Date: Tue, 2 Jun 2020 08:52:18 +0000 From: Wei Liu To: Juergen Gross Subject: Re: [PATCH-for-4.14 0/2] tools: some fixes for the hypervisor file system Message-ID: <20200602085218.btmbixmkrbnx2btq@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: <20200602060021.23289-1-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200602060021.23289-1-jgross@suse.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 08:00:19AM +0200, Juergen Gross wrote: > Juergen Gross (2): > tools: check return value of asprintf() in xenhypfs > tools: make libxenhypfs interface more future proof > > tools/libs/hypfs/core.c | 2 +- > tools/libs/hypfs/include/xenhypfs.h | 31 +++++++++++++++++------------ > tools/misc/xenhypfs.c | 10 ++++++++-- Good improvements. Acked-by: Wei Liu > 3 files changed, 27 insertions(+), 16 deletions(-) > > -- > 2.26.2 > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:02:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:02:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2np-000379-RF; Tue, 02 Jun 2020 09:01:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2nn-000374-RB for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:01:43 +0000 X-Inumbo-ID: adb4e34c-a4af-11ea-81bc-bc764e2007e4 Received: from mail-wm1-f65.google.com (unknown [209.85.128.65]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id adb4e34c-a4af-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 09:01:43 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id r9so2111949wmh.2 for ; Tue, 02 Jun 2020 02:01:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=3JNG7ZWFZFUreW9L1zqRVccKLXwRJSgbQ6YgyQQA0f0=; b=IN/IUtOO9onupCSCc+1cnFrmVyBv0CN4GE4Eje04Jr3pmswY0klQk1x0kpoD7odDQj H9aVc9ujHQiE4CoSf8/iDHjh09HVLmn50nYncAvKBjS79xWogYTIp5vWMZhD6VjkEEpZ Ti3O/iqS8RiN5NL0On4vi2J2BEJkJEhLmYTT8bIc25y7UUx5W+EO38esTuaQ/Mi+IF7h nZ3Vxs/4CSs39kjlRjx6Rbst/iKoOhdIhX3Ll4zs2944bKM59J3SwLFth4yX1NzghJMP Q3rFGMl6x7PqZorsbH+OzqU+y0GM/Ls2Acih8/qdubMqRqqJWMt/BZEvx0pLtWMlkqUU HjsA== X-Gm-Message-State: AOAM530scjsBnhEdiMtHKquucNjkUr0MTHJ3qBw1Cz3BQNwmMf28bxmN Q7kthvrdFuYrEGJKfrYe/OcDT6NL X-Google-Smtp-Source: ABdhPJylltjD0CFAqG7U19U+D11dZnub9ISStuvQGfwt9kuUahdwU/AHozVyhY9XGouhvZoq19Pb4w== X-Received: by 2002:a1c:c203:: with SMTP id s3mr3098455wmf.174.1591088502270; Tue, 02 Jun 2020 02:01:42 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id b81sm2932688wmc.5.2020.06.02.02.01.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 02:01:40 -0700 (PDT) From: Wei Liu To: Xen Development List Subject: [[PATCH v2 for-4.14]] m4: use test instead of [] Date: Tue, 2 Jun 2020 09:01:38 +0000 Message-Id: <20200602090138.28656-1-wl@xen.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: paul@xen.org, Roger Pau Monne , Ian Jackson , Wei Liu , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" It is reported that [] was removed by autoconf, which caused the following error: ./configure: line 4681: -z: command not found Switch to test. That's what is used throughout our configure scripts. Also put the variable expansion in quotes. Signed-off-by: Wei Liu Reported-by: Bertrand Marquis Fixes: 8a6b1665d987 ("configure: also add EXTRA_PREFIX to {CPP/LD}FLAGS") Signed-off-by: Wei Liu --- v2: Address Ian's comment. Run autogen.sh before committing. Cc: Bertrand Marquis Cc: Roger Pau Monne Cc: paul@xen.org --- m4/set_cflags_ldflags.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/set_cflags_ldflags.m4 b/m4/set_cflags_ldflags.m4 index 08f5c983cc63..23706e256b42 100644 --- a/m4/set_cflags_ldflags.m4 +++ b/m4/set_cflags_ldflags.m4 @@ -15,7 +15,7 @@ for ldflag in $APPEND_LIB do APPEND_LDFLAGS="$APPEND_LDFLAGS -L$ldflag" done -if [ ! -z $EXTRA_PREFIX ]; then +if test ! -z "$EXTRA_PREFIX" ; then CPPFLAGS="$CPPFLAGS -I$EXTRA_PREFIX/include" LDFLAGS="$LDFLAGS -L$EXTRA_PREFIX/lib" fi -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:03:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:03:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2ps-0003Ea-80; Tue, 02 Jun 2020 09:03:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2pr-0003EV-Pk for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:03:51 +0000 X-Inumbo-ID: f9f67996-a4af-11ea-81bc-bc764e2007e4 Received: from ppsw-30.csi.cam.ac.uk (unknown [131.111.8.130]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f9f67996-a4af-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 09:03:51 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from 88-109-182-220.dynamic.dsl.as9105.com ([88.109.182.220]:53456 helo=[192.168.1.219]) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:465) with esmtpsa (PLAIN:amc96) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1jg2pn-000AqR-dG (Exim 4.92.3) (return-path ); Tue, 02 Jun 2020 10:03:47 +0100 Subject: Re: [PATCH v10 08/12] xen: add /buildinfo/config entry to hypervisor filesystem To: Juergen Gross , xen-devel@lists.xenproject.org References: <20200519072106.26894-1-jgross@suse.com> <20200519072106.26894-9-jgross@suse.com> From: Andrew Cooper Message-ID: Date: Tue, 2 Jun 2020 10:03:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200519072106.26894-9-jgross@suse.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/05/2020 08:21, Juergen Gross wrote: > diff --git a/xen/common/Makefile b/xen/common/Makefile > index bf7d0e25a3..3d61239fbf 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -1,6 +1,7 @@ > obj-$(CONFIG_ARGO) += argo.o > obj-y += bitmap.o > obj-y += bsearch.o > +obj-$(CONFIG_HYPFS_CONFIG) += config_data.o > obj-$(CONFIG_CORE_PARKING) += core_parking.o > obj-y += cpu.o > obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o > @@ -73,3 +74,14 @@ obj-$(CONFIG_UBSAN) += ubsan/ > > obj-$(CONFIG_NEEDS_LIBELF) += libelf/ > obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ > + > +config.gz: ../.config > + gzip -c $< >$@ I had to disable HYPFS in the XenServer build.  Inside RPM, this fails with make[3]: *** No rule to make target `../.config', needed by `config.gz'.  Stop. make[3]: *** Waiting for unfinished jobs.... This needs to be an expression involving $(KCONFIG_CONFIG) because .config is only the default, and it surely needs a $(XEN_ROOT) in there? ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:05:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:05:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2rs-0003NQ-O2; Tue, 02 Jun 2020 09:05:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2rr-0003NK-AT for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:05:55 +0000 X-Inumbo-ID: 43733ab4-a4b0-11ea-81bc-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 43733ab4-a4b0-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 09:05:54 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: kJuVVCqWaC1yKgF0MoFq3FN+IQNKhZXJa/N49pGfOOE/yUUZ4DCgg2cf5ie6lmdLvDW5SmXl+S ggcxJv+6eAPKZPrTRRWrHAj586Godgjp+LqQzKRw1EHueIin6j0i7JRjjpP5PllP653lyHJoPX JJPpefpzpElyLvM2r74A6mKV7ftrec8Xe6NgzzZfD2bCys5wCL8kMH2kKjgEz3LXMHV+v5y8hH 9/VD+H/q56btrB9bIItjoBuTCQsZdKglxd9VoaCxytSQi7PaWrd0sciJiAHY5Vu33eohWWGjNg 32U= X-SBRS: 2.7 X-MesageID: 19253843 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,463,1583211600"; d="scan'208";a="19253843" From: Roger Pau Monne To: Subject: [PATCH for-4.14] x86/cpu: fix build with clang 3.5 Date: Tue, 2 Jun 2020 11:05:36 +0200 Message-ID: <20200602090536.38064-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Clang 3.5 complains with: common.c:794:24: error: statement expression not allowed at file scope i < ARRAY_SIZE(this_cpu(tss_page).ist_ssp); ++i ) ^ /build/xen/include/asm/percpu.h:14:7: note: expanded from macro 'this_cpu' (*RELOC_HIDE(&per_cpu__##var, get_cpu_info()->per_cpu_offset)) ^ /build/xen/include/xen/compiler.h:104:3: note: expanded from macro 'RELOC_HIDE' ({ unsigned long __ptr; \ ^ /build/xen/include/xen/lib.h:68:69: note: expanded from macro 'ARRAY_SIZE' #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x)) ^ /build/xen/include/xen/compiler.h:85:57: note: expanded from macro '__must_be_array' BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0]))) ^ /build/xen/include/xen/lib.h:39:57: note: expanded from macro 'BUILD_BUG_ON_ZERO' #define BUILD_BUG_ON_ZERO(cond) sizeof(struct { int:-!!(cond); }) ^ Workaround this by defining the tss_page as a local variable. Adjust other users of the per-cpu tss_page to also use the newly introduced local variable. No functional change expected. Signed-off-by: Roger Pau Monné --- xen/arch/x86/cpu/common.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index 58f0876180..da74172776 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -738,9 +738,14 @@ void load_system_tables(void) unsigned int i, cpu = smp_processor_id(); unsigned long stack_bottom = get_stack_bottom(), stack_top = stack_bottom & ~(STACK_SIZE - 1); + /* + * NB: define tss_page as a local variable because clang 3.5 doesn't + * support using ARRAY_SIZE against per-cpu variables. + */ + struct tss_page *tss_page = &this_cpu(tss_page); /* The TSS may be live. Disuade any clever optimisations. */ - volatile struct tss64 *tss = &this_cpu(tss_page).tss; + volatile struct tss64 *tss = &tss_page->tss; seg_desc_t *gdt = this_cpu(gdt) - FIRST_RESERVED_GDT_ENTRY; @@ -783,15 +788,14 @@ void load_system_tables(void) * volatile qualifier. */ if (cpu_has_xen_shstk) { - volatile uint64_t *ist_ssp = this_cpu(tss_page).ist_ssp; + volatile uint64_t *ist_ssp = tss_page->ist_ssp; ist_ssp[0] = 0x8600111111111111ul; ist_ssp[IST_MCE] = stack_top + (IST_MCE * IST_SHSTK_SIZE) - 8; ist_ssp[IST_NMI] = stack_top + (IST_NMI * IST_SHSTK_SIZE) - 8; ist_ssp[IST_DB] = stack_top + (IST_DB * IST_SHSTK_SIZE) - 8; ist_ssp[IST_DF] = stack_top + (IST_DF * IST_SHSTK_SIZE) - 8; - for ( i = IST_DF + 1; - i < ARRAY_SIZE(this_cpu(tss_page).ist_ssp); ++i ) + for ( i = IST_DF + 1; i < ARRAY_SIZE(tss_page->ist_ssp); ++i ) ist_ssp[i] = 0x8600111111111111ul; wrmsrl(MSR_INTERRUPT_SSP_TABLE, (unsigned long)ist_ssp); -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:07:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:07:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2tL-0003Te-2c; Tue, 02 Jun 2020 09:07:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2tJ-0003TY-LD for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:07:25 +0000 X-Inumbo-ID: 790ce602-a4b0-11ea-abaf-12813bfff9fa Received: from mail-wr1-f67.google.com (unknown [209.85.221.67]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 790ce602-a4b0-11ea-abaf-12813bfff9fa; Tue, 02 Jun 2020 09:07:24 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id c3so2524670wru.12 for ; Tue, 02 Jun 2020 02:07:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=bCtDczNiIvM6dn7XFsIWZta7yPzY8mB6emd9+VqAWQA=; b=XijJhpqa0EFASp6djiIX0/lZ/rTR2Ceww8YFiw44Ii3ZfRxu1vC82nUVFVPDMs/1xl ahuZwGh9NGfiu0yfbxvcNqvTPyy/c7kVCTn0BzFKE6wWfBmTofPvUGsgbuqGGDAUV+om RBdft/MKE6lZg5TOkmJRN0zqbMM+3C3zXue9mWP1HyKGbnp05anaXJNbIrJLPWbqkway NCwqWTppWM3f0VNg0UE3m3sBQaMPts2J+b89exo9XjVT59ev0dy/2fIjpx9oYv81z0te bnco8DA4779IrUKsbzAQsCKAQadXa0DV+khtM9d7g452dsilNngToCBJRj2J2g7eLRyy Uf8w== X-Gm-Message-State: AOAM532HAnJY2y6oglzR+QTGaW6+BjRmucO36cw43OpZMqiAhrf7cgv1 rfTqvIyrHhhSGrvhAGnMO/k= X-Google-Smtp-Source: ABdhPJzamQgOM6bbB9fIxfy3bNy9BxSvHtSAcgK2Q8eJEDWcf0q2qgNDTEVWFIzEtOIHa24XGsDSqQ== X-Received: by 2002:adf:ef47:: with SMTP id c7mr27502156wrp.57.1591088843647; Tue, 02 Jun 2020 02:07:23 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id w10sm2665858wrp.16.2020.06.02.02.07.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 02:07:23 -0700 (PDT) Date: Tue, 2 Jun 2020 09:07:21 +0000 From: Wei Liu To: Dario Faggioli Subject: Re: [PATCH 0/3] Automation: improve openSUSE containers + podman Message-ID: <20200602090721.r62ho7cagazgr2ji@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: <158827088416.19371.17008531228521109457.stgit@Palanthas> <86969ba1ea7e270267cfaa3408a89b55c86b3dca.camel@suse.com> <78e986122386915cacba8b4c3b572a460f9622e1.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78e986122386915cacba8b4c3b572a460f9622e1.camel@suse.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Paul Durrant , Doug Goldstein , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 12:20:25PM +0200, Dario Faggioli wrote: > On Thu, 2020-05-21 at 09:43 +0200, Dario Faggioli wrote: > > On Thu, 2020-04-30 at 20:27 +0200, Dario Faggioli wrote: > > > Hello, > > > > > > This short series contains some improvements for building Xen in > > > openSUSE containers. In fact, the build dependencies inside the > > > Tumbleweed container are updated and more handy helpers are added, > > > in > > > containerize, for referring to both Leap and Tumbleweed containers. > > > > > > In addition to that, in patch 3, the containerize script is > > > enhanced > > > so > > > that it is now possible to use podman, instead of docker. Rootless > > > mode > > > for podman also works (provided the system is properly configured) > > > which, > > > IMO, is rather nice. > > > > > > Docker of course continue to work, and is kept as the default. > > > > > Ping? > > > Ping^2? :-D > > Adding Wei. get-maintainers.pl seems told me I should no Cc him, so I > dind't, but I've seen automation/ stuff Acked-by him recently, so... I think these are good improvements, so in Doug's absence: Acked-by: Wei Liu You can already push to the container registries right? Cc Paul. Gitlab CI is not gating pushes. I think there is very low risk involved in committing this series during freeze. > > Thanks and Regards > -- > Dario Faggioli, Ph.D > http://about.me/dario.faggioli > Virtualization Software Engineer > SUSE Labs, SUSE https://www.suse.com/ > ------------------------------------------------------------------- > <> (Raistlin Majere) > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:08:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:08:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2um-0003bD-Dt; Tue, 02 Jun 2020 09:08:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2uk-0003b6-UG for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:08:54 +0000 X-Inumbo-ID: ae947dda-a4b0-11ea-9dbe-bc764e2007e4 Received: from mail-wr1-f66.google.com (unknown [209.85.221.66]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ae947dda-a4b0-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 09:08:54 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id c3so2529810wru.12 for ; Tue, 02 Jun 2020 02:08:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Ibp+xKt5PP9drAqQA2xRugrbmqMz3rwjwdKXKe9l/h4=; b=Re+IzVD8WRVcfls6iC/TY7L0StB2ntSa9cjBQPwziphVr22batvb5bij4ixkvqRpzO LWszSUf2SRNiIpsabHYMVd/DzJjY5vPRf89fy/5qgLtSC8Ao9atBDzWlNtE6m/9yMnRe 4InM06Jub9A3qUfq0BKT6pD/8xLVOZo91oZ68Sdp+vJRbqpjEFaHOi6GfYnNGqioLuvM LQqu6jCArjwKOa5+UsLixr6c5E6+Y6Elt2uuzhKT2afTyzXDg4bZw1RR4qWW5+iyaeGC bL7wCSI92PO2sldzbUxet7iYJjj9qNpvDWViO4pZjhntiP/9kH2S7T0cvTtlNPn53Q7z zo8w== X-Gm-Message-State: AOAM530ZSwBl8lNo94cX/X6Qvm7zYHcjVzSGFCsTZPK+HhHWCYiAxTkf n1DqGk//qR89V3pG2JWAKfI= X-Google-Smtp-Source: ABdhPJzs0tOPjipDIPNVUgCVsYq8A3AMHd+T5fBp+j+WGIAw1CnQyQTxMItbSrpZDeV8xu3HQ+Rrfw== X-Received: by 2002:a5d:4701:: with SMTP id y1mr24975008wrq.310.1591088933470; Tue, 02 Jun 2020 02:08:53 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id j11sm2735544wru.69.2020.06.02.02.08.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 02:08:52 -0700 (PDT) Date: Tue, 2 Jun 2020 09:08:51 +0000 From: Wei Liu To: Hongyan Xia Subject: Re: [PATCH 00/16] Remove the direct map Message-ID: <20200602090851.hxfxwoiflip6kcym@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: <20200501120715.hjak2gjp7ialwfq5@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <689a7c860a8a551e3b6009b16590e812dbf21055.camel@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <689a7c860a8a551e3b6009b16590e812dbf21055.camel@xen.org> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , julien@xen.org, Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org, Volodymyr Babchuk , Roger Pau =?utf-8?B?TW9ubsOp?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 01, 2020 at 02:53:08PM +0100, Hongyan Xia wrote: > On Fri, 2020-05-01 at 12:07 +0000, Wei Liu wrote: > > On Thu, Apr 30, 2020 at 09:44:09PM +0100, Hongyan Xia wrote: > > > From: Hongyan Xia > > > > > > This series depends on Xen page table domheap conversion: > > > > https://lists.xenproject.org/archives/html/xen-devel/2020-04/msg01374.html > > > . > > > > > > After breaking the reliance on the direct map to manipulate Xen > > > page > > > tables, we can now finally remove the direct map altogether. > > > > > > This series: > > > - fixes many places that use the direct map incorrectly or assume > > > the > > > presence of an always-mapped direct map in a wrong way. > > > - includes the early vmap patches for global mappings. > > > - initialises the mapcache for all domains, disables the fast path > > > that > > > uses the direct map for mappings. > > > - maps and unmaps xenheap on-demand. > > > - adds a boot command line switch to enable or disable the direct > > > map. > > > > > > This previous version was in RFC state and can be found here: > > > > https://lists.xenproject.org/archives/html/xen-devel/2019-09/msg02647.html > > > , > > > which has since been broken into small series. > > > > OOI have you done any performance measurements? > > > > Seeing that now even guest table needs mapping / unmapping during > > restore, I'm curious to know how that would impact performance. > > I actually have a lot of performance numbers but unfortunately on an > older version of Xen, not staging. I need to evaluate it again before > coming back to you. As you suspected, one strong signal from the > performance results is definitely the impact of walking guest tables. > For EPT, mapping and unmapping 20 times is no fun. This shows up in > micro-benchmarks, although larger benchmarks tend to be fine. > > My question is, do we care about hiding EPT? I think it is fine to just > use xenheap pages (or any other form which does the job) so that we go > down from 20 mappings to only 4. I have done this hack with EPT and saw > significantly reduced impact for HVM guests in micro-benchmarks. Not sure about hiding EPT. I will leave this question to Jan and Andrew... Wei. > > Hongyan > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:09:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:09:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2ur-0003cA-M3; Tue, 02 Jun 2020 09:09:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg2up-0003bt-Rl for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:08:59 +0000 X-Inumbo-ID: b0112f96-a4b0-11ea-81bc-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b0112f96-a4b0-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 09:08:56 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id d128so2326406wmc.1 for ; Tue, 02 Jun 2020 02:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=imkcr8mnWFJu8IPMt5D0KkvYAOE2rToIq4VEcJIUbqU=; b=XTOi1rXEv7/Zd38zzg0XTLjsa6uVKwA/0R2BUReHoIc6SKyEt/pgBcEDeZjprZ/HZW SDWeeZQO1/KU2L5xHLNUndIN7R0vht3zUIEcdIa53GmSgfimD2YSyMClSbKnlUebo395 kqKbYL66d7r8NjbH1Jz065mOACWegtJIOFfrf0cuNRX74gfrB6eM5L9LNkZ/0csiSWVY /WXgw7iK/bsG69V9go2fT2qVS3yswCtrCG2wMDJwAHZXZ+POjf1C04K/xaxLw7qipeHa f8y7vd0+M3RBZAMGsxXcXjkuxIxCpnh0n1OFODETQa2Damc8PQ2lZw+Nv9mfowmEPwpg 9tGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=imkcr8mnWFJu8IPMt5D0KkvYAOE2rToIq4VEcJIUbqU=; b=TpoDhfHpiWyK3UCPJgv3gzqtvTHDx3fMXgvUbDmcPeLOwQWXdLIBzDpWZQSe0BjuUn WqPF2ZnWtTQRfYjQ5lxaXhLFE+amcJ4TwfXLrwBw9/sRlTx1uehF5rOjbizEWhaw0NP2 Hw6cyqvBb46jKFyz8ln8QiQpmQBh1ygaglt1pDw8vCUhKEVFT2CruXddSjl5eaKZpN9Y vbrRLkbtwgKufQn2eVT6FkgsJA5xbLDaO5iDcCZ5DW5mg79VBDMdgDOwybgrx0yMvvzJ DON+SPtzAixQLbQssyDmUSTuVDi3ZtNahVx6WZ1C2u7CcNSVTDAlB9i2bty8qUw9HoGU jJNQ== X-Gm-Message-State: AOAM5317GK0+VQJTr6xgchBaVrGKcC3GhfWfCG/dxP9GAhnHwDRLGTja jPnnKtD7P65EdLfRMqp3th0= X-Google-Smtp-Source: ABdhPJzCRrZoybgW1R15Q2EL8uQzunVRYQnJy8vzp6zkOLbHzZVKqBNHBgZ8LE2NvG+oy8zrV9+1vg== X-Received: by 2002:a1c:e908:: with SMTP id q8mr3161115wmc.116.1591088935865; Tue, 02 Jun 2020 02:08:55 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id u23sm2773416wmu.20.2020.06.02.02.08.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 02:08:55 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Wei Liu'" , "'Olaf Hering'" References: <20200529135303.18457-1-olaf@aepfle.de> <20200602084338.a55bbjbhal4gbyvh@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> In-Reply-To: <20200602084338.a55bbjbhal4gbyvh@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> Subject: RE: [PATCH v1] INSTALL: remove TODO section Date: Tue, 2 Jun 2020 10:08:54 +0100 Message-ID: <003601d638bd$7133c180$539b4480$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIceqY+i+rjeo+ohPEdqGqT/4ozeAHZGh3WqCm8qVA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Wei Liu > Sent: 02 June 2020 09:44 > To: Olaf Hering > Cc: xen-devel@lists.xenproject.org; Andrew Cooper ; George Dunlap > ; Ian Jackson ; Jan Beulich ; > Julien Grall ; Stefano Stabellini ; Wei Liu ; Paul > Durrant > Subject: Re: [PATCH v1] INSTALL: remove TODO section > > On Fri, May 29, 2020 at 03:53:03PM +0200, Olaf Hering wrote: > > The default value '/' for DESTDIR is unusual, but does probably not hurt. > > > > Fixes commit f2b40dababedcd8355bf3e85d00baf17f9827131 > > Fixes commit 8e986e5a61efeca92b9b268e77957d45d8316ee4 > > > > Signed-off-by: Olaf Hering > > Acked-by: Wei Liu > > Based on the fact that you're the original author of this documentation. > :-) > > Cc Paul. Release-acked-by: Paul Durrant > > > --- > > INSTALL | 7 ------- > > 1 file changed, 7 deletions(-) > > > > diff --git a/INSTALL b/INSTALL > > index 72dc4b67dd..0d3eb89f02 100644 > > --- a/INSTALL > > +++ b/INSTALL > > @@ -365,12 +365,5 @@ make XEN_TARGET_ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ > > DESTDIR=/some/path install > > > > > > -TODO > > -==== > > - > > - - DESTDIR should be empty, not "/" > > - - add make uninstall targets > > - - replace private path variables as needed (SBINDIR/sbindir) > > - - ... > > > > # vim: tw=72 et From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:14:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:14:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg30D-0004Yc-BT; Tue, 02 Jun 2020 09:14:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg30B-0004YX-Vv for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:14:32 +0000 X-Inumbo-ID: 777301c2-a4b1-11ea-81bc-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 777301c2-a4b1-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 09:14:31 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id h5so2583476wrc.7 for ; Tue, 02 Jun 2020 02:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=2gtBXT2WEaFsOyVBj6fU7pOgQwyc+PWjyl4kh85zrzQ=; b=g6cSZ64QO2CexPzzxnFwOeRNMr9TRyv3ozGyqY7SYbgYqQ26cPu1VIK/AIPd1I40eM BJRg/vibrWG9ooGQ7Shs2rsXDM/5Ds3ImAx43/mNReiXiCv2aFc8y7FRkqO5MC2nSNBD HTqjYihxbuYViHRNc+WV4Qm2L5xkyaZDvP9y2qLaTfz3p39xMmUl8msB6EgO1B5Lctia j2jSSBxcDgYUg94n4r9Im1lZFAmY5BVfcEDGnIXzq/P8A5I4DlPRAWHWn8gO/09rH2L+ olPfh/cdJvnQBPv4r3X2pNhx7gKDNvHB2gkj2ShWrx0ocZjIuyfSxCgNpAFF1BQqyRgq OBmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=2gtBXT2WEaFsOyVBj6fU7pOgQwyc+PWjyl4kh85zrzQ=; b=XB5dwbCrnlahFuUEBpoxfDlr/4briRLAf0//Y0w9ddff96obt8Fh0gc3t5QwZ1u7HT wLqsUAn3VZtJ94ZAHvoZ3ubXYonQZa94K1K3oJyxDxb5+AXG32U3YkGXq2FgPbpeNMEc edmN+Jnbyec/vZSruX7aH183ZPeyo+Lkl638uR7qK9fZxZwlRjpb9BvYLMWZX05IJOSD V56nwcU7hMJ0n2u7zkssT55ERVIonkPo0eOGYHCCSBShfr9psJD0SQgwVC+oC2HhxuaY 84TuDBjDeIV8v+9xVU0UKd2KzlOT8oaLVbI3zJanP1GmSn7uyDZRB0yWoCOSnpXBVQEd ZMhw== X-Gm-Message-State: AOAM531ZDF3wAIi98ilzlYJ6IAiVRwxws3u2o5BSo/O04osdQ3qM45Ng BJKIlZcZSUdqE7BaWQtVk0s= X-Google-Smtp-Source: ABdhPJw0VXcV8e7xC2bR8JDv8ZUgdD5eEIPSzV8tJCOfe3d9rREfqcCtxYLdHBms3ykP+UgEX6re2A== X-Received: by 2002:adf:e90b:: with SMTP id f11mr25018933wrm.248.1591089270428; Tue, 02 Jun 2020 02:14:30 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id q1sm2541712wmc.12.2020.06.02.02.14.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 02:14:29 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Wei Liu'" , "'Xen Development List'" References: <20200602090138.28656-1-wl@xen.org> In-Reply-To: <20200602090138.28656-1-wl@xen.org> Subject: RE: [[PATCH v2 for-4.14]] m4: use test instead of [] Date: Tue, 2 Jun 2020 10:14:29 +0100 Message-ID: <003701d638be$38a3d110$a9eb7330$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQMAVpDG94+7TqBfX8RhE9XZuCEtz6ZwzqEg X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Roger Pau Monne' , 'Ian Jackson' , 'Bertrand Marquis' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Wei Liu > Sent: 02 June 2020 10:02 > To: Xen Development List > Cc: Wei Liu ; Bertrand Marquis ; Roger Pau Monne > ; paul@xen.org; Ian Jackson > Subject: [[PATCH v2 for-4.14]] m4: use test instead of [] > > It is reported that [] was removed by autoconf, which caused the > following error: > > ./configure: line 4681: -z: command not found > > Switch to test. That's what is used throughout our configure scripts. > Also put the variable expansion in quotes. > > Signed-off-by: Wei Liu > Reported-by: Bertrand Marquis > Fixes: 8a6b1665d987 ("configure: also add EXTRA_PREFIX to {CPP/LD}FLAGS") > Signed-off-by: Wei Liu > --- > v2: Address Ian's comment. > > Run autogen.sh before committing. > > Cc: Bertrand Marquis > Cc: Roger Pau Monne > Cc: paul@xen.org Yes, pretty clearly wrong in the original patch. Release-acked-by: Paul Durrant > --- > m4/set_cflags_ldflags.m4 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/m4/set_cflags_ldflags.m4 b/m4/set_cflags_ldflags.m4 > index 08f5c983cc63..23706e256b42 100644 > --- a/m4/set_cflags_ldflags.m4 > +++ b/m4/set_cflags_ldflags.m4 > @@ -15,7 +15,7 @@ for ldflag in $APPEND_LIB > do > APPEND_LDFLAGS="$APPEND_LDFLAGS -L$ldflag" > done > -if [ ! -z $EXTRA_PREFIX ]; then > +if test ! -z "$EXTRA_PREFIX" ; then > CPPFLAGS="$CPPFLAGS -I$EXTRA_PREFIX/include" > LDFLAGS="$LDFLAGS -L$EXTRA_PREFIX/lib" > fi > -- > 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:16:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:16:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg31t-0004eW-NM; Tue, 02 Jun 2020 09:16:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg31s-0004eM-KX for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:16:16 +0000 X-Inumbo-ID: b5c946c0-a4b1-11ea-81bc-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b5c946c0-a4b1-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 09:16:15 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ObfmshO7MUpzAWv2u8Tp58LY3B3Q9QKxgtTNAyWosXS7LDQCkbivotRG3MRGwc+YNaAvaZvWTQ 5Sx0/JXs6y6vG60NaqS8glmGLtcyhleJSLD+//uB3jYxqM4rBfgwQPsZXyn/coQAs2X+Qs75DU QwaqDRnYYvMjbFBSG6Rw4YDXOlNAg0Hj9At2jCVA31Y9EApJaLXm+i6HqkrNa/6mzVHrVNzYDu +W3G5BpR6V/0uXSZJM3KLUYlopxLX/YmBKMOq//9QX9K/M5U9ZRt6FfL60/D56WrtVyjatdI6N HI8= X-SBRS: 2.7 X-MesageID: 19254563 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,463,1583211600"; d="scan'208";a="19254563" From: Roger Pau Monne To: Subject: [PATCH for-4.14] compilers/clang: always use _Static_assert with clang Date: Tue, 2 Jun 2020 11:16:02 +0200 Message-ID: <20200602091602.38422-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" All versions of clang used by Xen support _Static_assert, so use it unconditionally when building Xen with clang. No functional change expected. Signed-off-by: Roger Pau Monné --- Not sure whether this fully qualifies as a bugfix, as the current behavior should also work fine under clang. Note that all versions of clang from 3.5 to trunk (11) seem to return __GNUC__ == 4 and __GNUC_MINOR__ == 2. --- xen/include/xen/lib.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h index e5b0a007b8..076bcfb67d 100644 --- a/xen/include/xen/lib.h +++ b/xen/include/xen/lib.h @@ -25,7 +25,9 @@ #define BUG_ON(p) do { if (unlikely(p)) BUG(); } while (0) #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0) -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) +/* All clang versions supported by Xen have _Static_assert. */ +#if defined(__clang__) || \ + (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)) /* Force a compilation error if condition is true */ #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); }) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:22:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:22:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg37B-0005WY-FI; Tue, 02 Jun 2020 09:21:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg379-0005WT-Io for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:21:43 +0000 X-Inumbo-ID: 78a2c1d0-a4b2-11ea-81bc-bc764e2007e4 Received: from mail-wm1-x331.google.com (unknown [2a00:1450:4864:20::331]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 78a2c1d0-a4b2-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 09:21:42 +0000 (UTC) Received: by mail-wm1-x331.google.com with SMTP id l26so2169331wme.3 for ; Tue, 02 Jun 2020 02:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=c6EcvBNdTMkEI0s+7ft7aSZ+qJqaRGOF9ngjNVb0KdE=; b=RK20Jdfk+zV6ObNkKkEO63thZSCN0TAcpbUtRqJGUDacKbe/+ecNqV9RQUVI6gthg1 dkgfralWgK1xwQFg7xX29VE+08KfEFyD4RIHDACG+RQJnkIIFyV6T/WaA5Ma8Yaf8MdF 5HxUXaKAQKqw21xYW/TldnxrIL8XawKIcS/bWoC+pLQKHsbLryNy88bp7gIinaQZIJlH N0gK+nhmiT/XiMZF60LxQ++1DsIxhlrRaVUmzlQB1utweibYXXX0QvPwGYgDbe5fWDSI cN+pn3zFX+mOfkscz5dqHtp0qjk4oPaK7E+8Xa3a/iRiV7obb0/3axyvDAyEvNuAgdgX mUfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=c6EcvBNdTMkEI0s+7ft7aSZ+qJqaRGOF9ngjNVb0KdE=; b=Xi5SlBkFsu22yN5YbuHwemnV1jKxxS9nhnP0jzW8MtgVl4mKG3AOPZVJ1fdmYxBb9/ T6tXfjEmsjPkeYmA+r7Lfi64Zz8IcBYUwFuu+KRjCRhSJDDYHgNVe6FxpGm5Q/v0CoxC xaXow5n43NZWihYIjUpHurIJnEgj85Mzjk/BPMd3jJ4wp4/N1G3I2+uAebFO6817WKFL 5tcFfqTcbhj2k/oI9KDO3NNnRc+tLKQbmTQcLHQYHbJXvM0ulOQL+m8kiIM8jKSfpSUg ek3VKU9tBH3bcNRnQAtN1m+N8H53inapNemRYO9DwXZ8F/+T/h73qvQzzQEyVDK1WsYk k7vA== X-Gm-Message-State: AOAM5304uwWXoc3V5bW6VdIvVbC/+1l2DKc1uAWXgIgZ/JVF1YI+v4L9 LWbDuZ9daeTfdVr3XUBTCmc= X-Google-Smtp-Source: ABdhPJy+cZqs+S7/mA+P71md4/F1u+nFxcQJXOk/ZB/EQzUfAS/99KrYUT4lAxt3HxigFAgeOE/TZA== X-Received: by 2002:a1c:22c1:: with SMTP id i184mr3153312wmi.187.1591089702021; Tue, 02 Jun 2020 02:21:42 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id o15sm2710585wmm.31.2020.06.02.02.21.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 02:21:41 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200602090536.38064-1-roger.pau@citrix.com> In-Reply-To: <20200602090536.38064-1-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14] x86/cpu: fix build with clang 3.5 Date: Tue, 2 Jun 2020 10:21:40 +0100 Message-ID: <003801d638bf$39e50e30$adaf2a90$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJon9qKp2HjrlA96kxsuOa/M+4KF6egPp8A X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 02 June 2020 10:06 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich = ; Andrew > Cooper ; Wei Liu > Subject: [PATCH for-4.14] x86/cpu: fix build with clang 3.5 >=20 > Clang 3.5 complains with: >=20 > common.c:794:24: error: statement expression not allowed at file scope > i < ARRAY_SIZE(this_cpu(tss_page).ist_ssp); ++i = ) > ^ > /build/xen/include/asm/percpu.h:14:7: note: expanded from macro = 'this_cpu' > (*RELOC_HIDE(&per_cpu__##var, get_cpu_info()->per_cpu_offset)) > ^ > /build/xen/include/xen/compiler.h:104:3: note: expanded from macro = 'RELOC_HIDE' > ({ unsigned long __ptr; \ > ^ > /build/xen/include/xen/lib.h:68:69: note: expanded from macro = 'ARRAY_SIZE' > #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + = __must_be_array(x)) > ^ > /build/xen/include/xen/compiler.h:85:57: note: expanded from macro = '__must_be_array' > BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), = typeof(&a[0]))) > ^ > /build/xen/include/xen/lib.h:39:57: note: expanded from macro = 'BUILD_BUG_ON_ZERO' > #define BUILD_BUG_ON_ZERO(cond) sizeof(struct { int:-!!(cond); }) > ^ >=20 > Workaround this by defining the tss_page as a local variable. Adjust > other users of the per-cpu tss_page to also use the newly introduced > local variable. >=20 > No functional change expected. >=20 > Signed-off-by: Roger Pau Monn=C3=A9 Release-acked-by: Paul Durrant > --- > xen/arch/x86/cpu/common.c | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) >=20 > diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c > index 58f0876180..da74172776 100644 > --- a/xen/arch/x86/cpu/common.c > +++ b/xen/arch/x86/cpu/common.c > @@ -738,9 +738,14 @@ void load_system_tables(void) > unsigned int i, cpu =3D smp_processor_id(); > unsigned long stack_bottom =3D get_stack_bottom(), > stack_top =3D stack_bottom & ~(STACK_SIZE - 1); > + /* > + * NB: define tss_page as a local variable because clang 3.5 doesn't > + * support using ARRAY_SIZE against per-cpu variables. > + */ > + struct tss_page *tss_page =3D &this_cpu(tss_page); >=20 > /* The TSS may be live. Disuade any clever optimisations. */ > - volatile struct tss64 *tss =3D &this_cpu(tss_page).tss; > + volatile struct tss64 *tss =3D &tss_page->tss; > seg_desc_t *gdt =3D > this_cpu(gdt) - FIRST_RESERVED_GDT_ENTRY; >=20 > @@ -783,15 +788,14 @@ void load_system_tables(void) > * volatile qualifier. > */ > if (cpu_has_xen_shstk) { > - volatile uint64_t *ist_ssp =3D this_cpu(tss_page).ist_ssp; > + volatile uint64_t *ist_ssp =3D tss_page->ist_ssp; >=20 > ist_ssp[0] =3D 0x8600111111111111ul; > ist_ssp[IST_MCE] =3D stack_top + (IST_MCE * IST_SHSTK_SIZE) - 8; > ist_ssp[IST_NMI] =3D stack_top + (IST_NMI * IST_SHSTK_SIZE) - 8; > ist_ssp[IST_DB] =3D stack_top + (IST_DB * IST_SHSTK_SIZE) - 8; > ist_ssp[IST_DF] =3D stack_top + (IST_DF * IST_SHSTK_SIZE) - 8; > - for ( i =3D IST_DF + 1; > - i < ARRAY_SIZE(this_cpu(tss_page).ist_ssp); ++i ) > + for ( i =3D IST_DF + 1; i < ARRAY_SIZE(tss_page->ist_ssp); ++i ) > ist_ssp[i] =3D 0x8600111111111111ul; >=20 > wrmsrl(MSR_INTERRUPT_SSP_TABLE, (unsigned long)ist_ssp); > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:22:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:22:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg37l-0005ZK-OA; Tue, 02 Jun 2020 09:22:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg37k-0005ZB-2S for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:22:20 +0000 X-Inumbo-ID: 8e90c79e-a4b2-11ea-81bc-bc764e2007e4 Received: from mail-wr1-f67.google.com (unknown [209.85.221.67]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8e90c79e-a4b2-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 09:22:19 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id t18so2615061wru.6 for ; Tue, 02 Jun 2020 02:22:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=tBdBgDV0rZWSymEOBaGzVwieg/DhEZ+F/kAr9Qw8t/U=; b=JFxI9JKGug2rHLwNms7V9ZWIre1/qO0qsHolY7jpCqyrFqPlGSE0rc5jz1ypGhDqpY yzKrORl+cXrO+F8fKjwUvy6GiQ9IUKria9zLRmnhnJNtxebVDjxkwx3hn7rZdohwdR7q agI/slUbt8NZXo1J8og1OSjUnAPbIBXxXTm1LK9WfBx/dnBmRsoepqr0GjBxpyOicUPd KhMiyUveVlXaAl5LB5YutEZldtECBaK/JZ3OwXcnhHyxmVlwBnml0Kkn9S2TrqMp3Nlx nrdQK6e0r6fwusDNGhhViaAmuwAgYNFFAoRNP1METatUsJDWM2eulnMAqhR34FaLTVkX wT6w== X-Gm-Message-State: AOAM533OOi2shQ5ptJruTfish0pmhuXVAD4oVuYIMGbC//YKVpQ1SvM+ 5f0jZOEpxsAzNZOXVUxV3+M= X-Google-Smtp-Source: ABdhPJy6X+gcAcNWktzplCq3ncZUQABJZ+EfmamoqzrLWe/nW4ZZE8mEPZCOqlF6JVNOWFdSljittw== X-Received: by 2002:adf:e7ce:: with SMTP id e14mr27502326wrn.217.1591089738754; Tue, 02 Jun 2020 02:22:18 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id h15sm2664383wrt.73.2020.06.02.02.22.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 02:22:18 -0700 (PDT) Date: Tue, 2 Jun 2020 09:22:17 +0000 From: Wei Liu To: Roger Pau Monne Subject: Re: [PATCH for-4.14] x86/cpu: fix build with clang 3.5 Message-ID: <20200602092217.uxcpjhv2gz6we47h@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: <20200602090536.38064-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200602090536.38064-1-roger.pau@citrix.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 11:05:36AM +0200, Roger Pau Monne wrote: > Clang 3.5 complains with: > > common.c:794:24: error: statement expression not allowed at file scope > i < ARRAY_SIZE(this_cpu(tss_page).ist_ssp); ++i ) > ^ > /build/xen/include/asm/percpu.h:14:7: note: expanded from macro 'this_cpu' > (*RELOC_HIDE(&per_cpu__##var, get_cpu_info()->per_cpu_offset)) > ^ > /build/xen/include/xen/compiler.h:104:3: note: expanded from macro 'RELOC_HIDE' > ({ unsigned long __ptr; \ > ^ > /build/xen/include/xen/lib.h:68:69: note: expanded from macro 'ARRAY_SIZE' > #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x)) > ^ > /build/xen/include/xen/compiler.h:85:57: note: expanded from macro '__must_be_array' > BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0]))) > ^ > /build/xen/include/xen/lib.h:39:57: note: expanded from macro 'BUILD_BUG_ON_ZERO' > #define BUILD_BUG_ON_ZERO(cond) sizeof(struct { int:-!!(cond); }) > ^ > > Workaround this by defining the tss_page as a local variable. Adjust > other users of the per-cpu tss_page to also use the newly introduced > local variable. > > No functional change expected. > > Signed-off-by: Roger Pau Monn Reviewed-by: Wei Liu From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:23:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:23:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg38S-0005fg-19; Tue, 02 Jun 2020 09:23:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg38R-0005fX-E6 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:23:03 +0000 X-Inumbo-ID: a85af67c-a4b2-11ea-9947-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a85af67c-a4b2-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 09:23:02 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id y17so2584180wrn.11 for ; Tue, 02 Jun 2020 02:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=+YYjsK4KRgX34vzfUAgKWTPBD+k2YZNB2ALORVkyR2g=; b=dqdCBoqgj+Q61Z4UDyQnpHPYTAX6wDXjgurPA9T++vmU2ZOSU3wdMH6pPayo4JD3E7 9I5YnkbpG38/+NW9DPmkrOOCZbfkmGW3eMnTebRh6pxJVcDMUcKuLjX80/fmMSzzxxAi 4Hl62j8fMz6NCY9nDnrvfXdjX1PS86f6B3wmnKzAPE9mjiT2GIPZTYwwryoF0Gb/kyCY MfIueLbXyN/+emFob1w30QPtKpvyZGBWgKo2elUgqE6jIhsqE/0JJNflLfSeiXaD0tFf id5JsE1lgsgpFze8T4Jrk5KZU/MDGVXUjCqVkuRBH/OwaPVmtFq7nCPnE6Lr2C8vG0Vz /U1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=+YYjsK4KRgX34vzfUAgKWTPBD+k2YZNB2ALORVkyR2g=; b=CyfgsA81fBnS40jtq8a/M4E6K1x9XQnmq5FT+Q2pZpcoXOvzCEOSwkCabAav1iAwau qh4EMjRgD1ueyC8WBF02kynUYbeVoq/TeOV4uEKfAKqKz6fuqra8ONxlFR5x/QDxsWaY o6gVXfssyZkOtxChC8+7urPIevvr9Mb78VC19POkqaSV4Z6kisHGOWPiO6v66Ce61KJt ZzCAK5U+xPEOIs+YDmmzmoZ+pmulByX7Hu31BXhiqrYbh4sk8wkqPG37fPIkEJDoR7hk TFEzI/ff3Mt3+8sOxV/mcaRUJmO10FP3Q0LEo3bWpcZhphTjpTLZTuv7kspRRAHOb98Y qfGg== X-Gm-Message-State: AOAM531zVknri245h51qzPSHN6OaZr2yrhDqvue0L6JkrLHhaWdVf4uZ SyKQdOGgRyRjsdkFVqdEQbQ= X-Google-Smtp-Source: ABdhPJyoGpSqppZ/7yfbp9Fs6Uj3MCQBivPDMAwPH+A9dG3MEdSlfEuRYLOcwaAgt6pFL8E90Jd7Zw== X-Received: by 2002:a5d:6b81:: with SMTP id n1mr25158179wrx.411.1591089782068; Tue, 02 Jun 2020 02:23:02 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id a126sm2568527wme.28.2020.06.02.02.23.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 02:23:01 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Wei Liu'" , "'Dario Faggioli'" References: <158827088416.19371.17008531228521109457.stgit@Palanthas> <86969ba1ea7e270267cfaa3408a89b55c86b3dca.camel@suse.com> <78e986122386915cacba8b4c3b572a460f9622e1.camel@suse.com> <20200602090721.r62ho7cagazgr2ji@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> In-Reply-To: <20200602090721.r62ho7cagazgr2ji@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> Subject: RE: [PATCH 0/3] Automation: improve openSUSE containers + podman Date: Tue, 2 Jun 2020 10:23:00 +0100 Message-ID: <003901d638bf$69917e20$3cb47a60$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLJzs6x995B/uNQdEw2qPaFLQGt1wHxU21fAiyNZtYCqBw6I6ansRaA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Doug Goldstein' , 'Andrew Cooper' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Wei Liu > Sent: 02 June 2020 10:07 > To: Dario Faggioli > Cc: xen-devel@lists.xenproject.org; Andrew Cooper ; Doug Goldstein > ; Wei Liu ; Paul Durrant > Subject: Re: [PATCH 0/3] Automation: improve openSUSE containers + podman > > On Fri, May 29, 2020 at 12:20:25PM +0200, Dario Faggioli wrote: > > On Thu, 2020-05-21 at 09:43 +0200, Dario Faggioli wrote: > > > On Thu, 2020-04-30 at 20:27 +0200, Dario Faggioli wrote: > > > > Hello, > > > > > > > > This short series contains some improvements for building Xen in > > > > openSUSE containers. In fact, the build dependencies inside the > > > > Tumbleweed container are updated and more handy helpers are added, > > > > in > > > > containerize, for referring to both Leap and Tumbleweed containers. > > > > > > > > In addition to that, in patch 3, the containerize script is > > > > enhanced > > > > so > > > > that it is now possible to use podman, instead of docker. Rootless > > > > mode > > > > for podman also works (provided the system is properly configured) > > > > which, > > > > IMO, is rather nice. > > > > > > > > Docker of course continue to work, and is kept as the default. > > > > > > > Ping? > > > > > Ping^2? :-D > > > > Adding Wei. get-maintainers.pl seems told me I should no Cc him, so I > > dind't, but I've seen automation/ stuff Acked-by him recently, so... > > I think these are good improvements, so in Doug's absence: > > Acked-by: Wei Liu > > You can already push to the container registries right? > > Cc Paul. Gitlab CI is not gating pushes. I think there is very low risk > involved in committing this series during freeze. > I'll trust your judegment :-) Release-acked-by: Paul Durrant > > > > > Thanks and Regards > > -- > > Dario Faggioli, Ph.D > > http://about.me/dario.faggioli > > Virtualization Software Engineer > > SUSE Labs, SUSE https://www.suse.com/ > > ------------------------------------------------------------------- > > <> (Raistlin Majere) > > > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:23:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:23:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg38i-0005iW-9w; Tue, 02 Jun 2020 09:23:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg38g-0005iG-Ph for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:23:18 +0000 X-Inumbo-ID: b1448a64-a4b2-11ea-abb3-12813bfff9fa Received: from mail-wm1-f68.google.com (unknown [209.85.128.68]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b1448a64-a4b2-11ea-abb3-12813bfff9fa; Tue, 02 Jun 2020 09:23:17 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id u13so2188002wml.1 for ; Tue, 02 Jun 2020 02:23:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ObTAJIfIjh3vYqUzrP8hxx5f7jiiEVpYKHOGoi58jGc=; b=GsvqhvGm4ZE1xA4IzY/fLVNsXoynT5UEF5W/M0lN4MhPc79hdJyKiH/Eq6kc2x6SaE BlmG9EJjELfjJkiHc+pki1yJp3qbZzNTeSGaLkz5htA21it9TZILtQWdwqxHEm/w95kR WE0n414ZTI77/EvePK0GHIqj/DNlEfupmB5jVRpaqhBISBlEO8gLfwBOxMNfYp9aFgbI IlgFXVbk/Ar2LLhcVTc/D0Sq3dZEy09xd06ARp7tC2dSmCRgNRHDhznbWn9NDYPNy/iV LDzkvf806jsfBlf4lzjE/qPQUzWtZpcTjsHcr2i45UptTa+GrrLe8pKrxmB5loa+0Bls dLfw== X-Gm-Message-State: AOAM5333h/po61ION0Eo/fqoEZzR8Ap4CslBdGKAmIOsCaNW0EUHIaVk PVXhYyGjZw+vXGODewjX6hU= X-Google-Smtp-Source: ABdhPJxFmvGs6GZb3i/SgrNBQ3jxIEWek+N2DOeQuJInSXa9c5Savoqeu0g/tBaHoGaX6yOtiRjfNg== X-Received: by 2002:a1c:b656:: with SMTP id g83mr3213783wmf.27.1591089796967; Tue, 02 Jun 2020 02:23:16 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id y80sm2838210wmc.34.2020.06.02.02.23.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 02:23:16 -0700 (PDT) Date: Tue, 2 Jun 2020 09:23:14 +0000 From: Wei Liu To: Roger Pau Monne Subject: Re: [PATCH for-4.14] compilers/clang: always use _Static_assert with clang Message-ID: <20200602092314.uydguwrje4bomktf@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: <20200602091602.38422-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200602091602.38422-1-roger.pau@citrix.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 11:16:02AM +0200, Roger Pau Monne wrote: > All versions of clang used by Xen support _Static_assert, so use it > unconditionally when building Xen with clang. > > No functional change expected. > > Signed-off-by: Roger Pau Monn Reviewed-by: Wei Liu > --- > Not sure whether this fully qualifies as a bugfix, as the current > behavior should also work fine under clang. Note that all versions of > clang from 3.5 to trunk (11) seem to return __GNUC__ == 4 and > __GNUC_MINOR__ == 2. IMHO it wouldn't hurt to apply this patch since any breakage is easy to catch. > --- > xen/include/xen/lib.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h > index e5b0a007b8..076bcfb67d 100644 > --- a/xen/include/xen/lib.h > +++ b/xen/include/xen/lib.h > @@ -25,7 +25,9 @@ > #define BUG_ON(p) do { if (unlikely(p)) BUG(); } while (0) > #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0) > > -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) > +/* All clang versions supported by Xen have _Static_assert. */ > +#if defined(__clang__) || \ > + (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)) > /* Force a compilation error if condition is true */ > #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); }) > > -- > 2.26.2 > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:26:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:26:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3BN-0005xI-O0; Tue, 02 Jun 2020 09:26:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3BM-0005xB-6a for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:26:04 +0000 X-Inumbo-ID: 140e2d80-a4b3-11ea-8993-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 140e2d80-a4b3-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 09:26:03 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id r15so2355203wmh.5 for ; Tue, 02 Jun 2020 02:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=ZEaYjWeN2XFm/ghGqVKRcX8WRVihSGkqtc6SPAjPdts=; b=k0ee3+EdMYA4r6L5EypuXiOL+KcbdedCZGbty3Bn2lCVnufGvkP7M5Ff5SnYysQ1xw FWL0bIIk+9b3d2doWhlyqSU9xTs9y+MOuZNFFSUVHvYI8dJi3Bw9Tx4rAdPEnOF0rl1L PQiq2w75CT0V0uJNUoHNkH2bCsdGsRibPg6JZBVt7tgp/o+kGM0TZWEXDrGmgBi94MJv xrPX1GCPXEQ+g/5WmcYnyNfJKSdEJJCI6ZqmERVv4W0VZnEn//7DYmLuRGFxxtqDs/0u 4Y1XGN7sKD5QM/ATN9q8rePIeMokBPpvb5aHvdf5HkgAgVpTkjvPnIBtcKLWTbBHFtM5 G8pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=ZEaYjWeN2XFm/ghGqVKRcX8WRVihSGkqtc6SPAjPdts=; b=cD0KxgzQjcP+i8mv3AulsvULUrnBOzhRr8ea4cc0ZOHnfAi0ZjjekIu8kgbBEXFjWN XiIFzRKwCqxS4Xuge7GxcRRw8UTYwyp/5jOitDYNzUS++HrSQFkWgy3hVt3OdiRnR/s5 uqHDpOu3OUal4Jd21zfZnKuIwYCB/V1W6g2UWX3TvtzI+JvAxX3CfpGStn4s4u3QbPnR Bb0LKEzlVmUayxcTrbKgTb/ATTqym2LXqJNOX4bGbBHC3Ny375vomxMA/OGiuhIrD7A3 84/m6/ly0XpCEYw9EXTF6pG1KGXyKCDlRoneMIaikHSxTnE8TVOV+4joTec22eyvNoQ7 Nm9Q== X-Gm-Message-State: AOAM532Zn47JJAhm80cxW95SLdmWYoSHgfCzvZycEEyhE/kkqD4CihwH POAsHWq94yFdqVpYv9txR5o= X-Google-Smtp-Source: ABdhPJzv3i97CadNbDFzUwvwAiBt6NrvZZ/A1+KA0AiQFU30mt/ShxEb+HmLya0qOTu4Szht0Xt2cg== X-Received: by 2002:a1c:4c16:: with SMTP id z22mr3467312wmf.17.1591089962795; Tue, 02 Jun 2020 02:26:02 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id y17sm3204873wrn.12.2020.06.02.02.26.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 02:26:02 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Wei Liu'" , "'Roger Pau Monne'" References: <20200602091602.38422-1-roger.pau@citrix.com> <20200602092314.uydguwrje4bomktf@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> In-Reply-To: <20200602092314.uydguwrje4bomktf@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> Subject: RE: [PATCH for-4.14] compilers/clang: always use _Static_assert with clang Date: Tue, 2 Jun 2020 10:26:01 +0100 Message-ID: <003a01d638bf$d54dc100$7fe94300$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIe/3Blvy/dLIniPJQXflJrQIvotwHksC7fqCRay6A= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Wei Liu > Sent: 02 June 2020 10:23 > To: Roger Pau Monne > Cc: xen-devel@lists.xenproject.org; paul@xen.org; Andrew Cooper = ; George > Dunlap ; Ian Jackson = ; Jan Beulich > ; Julien Grall ; Stefano Stabellini = ; Wei > Liu > Subject: Re: [PATCH for-4.14] compilers/clang: always use = _Static_assert with clang >=20 > On Tue, Jun 02, 2020 at 11:16:02AM +0200, Roger Pau Monne wrote: > > All versions of clang used by Xen support _Static_assert, so use it > > unconditionally when building Xen with clang. > > > > No functional change expected. > > > > Signed-off-by: Roger Pau Monn=E9 >=20 > Reviewed-by: Wei Liu >=20 > > --- > > Not sure whether this fully qualifies as a bugfix, as the current > > behavior should also work fine under clang. Note that all versions = of > > clang from 3.5 to trunk (11) seem to return __GNUC__ =3D=3D 4 and > > __GNUC_MINOR__ =3D=3D 2. >=20 > IMHO it wouldn't hurt to apply this patch since any breakage is easy = to > catch. Yes, seems reasonable. Release-acked-by: Paul Durrant >=20 > > --- > > xen/include/xen/lib.h | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h > > index e5b0a007b8..076bcfb67d 100644 > > --- a/xen/include/xen/lib.h > > +++ b/xen/include/xen/lib.h > > @@ -25,7 +25,9 @@ > > #define BUG_ON(p) do { if (unlikely(p)) BUG(); } while (0) > > #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0) > > > > -#if __GNUC__ > 4 || (__GNUC__ =3D=3D 4 && __GNUC_MINOR__ >=3D 6) > > +/* All clang versions supported by Xen have _Static_assert. */ > > +#if defined(__clang__) || \ > > + (__GNUC__ > 4 || (__GNUC__ =3D=3D 4 && __GNUC_MINOR__ >=3D 6)) > > /* Force a compilation error if condition is true */ > > #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond = ")"); }) > > > > -- > > 2.26.2 > > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:39:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:39:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3Ny-0006wX-V3; Tue, 02 Jun 2020 09:39:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3Nx-0006wQ-VM for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:39:05 +0000 X-Inumbo-ID: e457061e-a4b4-11ea-abb5-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e457061e-a4b4-11ea-abb5-12813bfff9fa; Tue, 02 Jun 2020 09:39:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 15303B019; Tue, 2 Jun 2020 09:39:02 +0000 (UTC) Subject: Re: [PATCH v19 for-4.14 00/13] VM forking To: paul@xen.org References: <000c01d63826$6d125900$47370b00$@xen.org> <4017F2B3-BB9B-4E9F-813C-6FE68BA0D568@citrix.com> <002401d638b0$a5460f80$efd22e80$@xen.org> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 11:38:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <002401d638b0$a5460f80$efd22e80$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Julien Grall' , 'Kevin Tian' , 'Tamas K Lengyel' , 'Tamas K Lengyel' , 'Wei Liu' , 'Andrew Cooper' , 'George Dunlap' , 'Stefano Stabellini' , 'Jun Nakajima' , 'Ian Jackson' , 'Anthony Perard' , 'xen-devel' , 'Roger Pau Monne' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 09:37, Paul Durrant wrote: > Maintainers/committers, can we please get those patches in a.s.a.p.? The sole reason I didn't put in at least the 1st patch on Friday (perhaps also the 2nd, as it is suitably ack-ed) was that it's still missing a VMX maintainer ack, and Kevin had provided comments on v2 of the smaller (2-patch) series. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:49:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:49:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3Xa-0007si-1P; Tue, 02 Jun 2020 09:49:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3XZ-0007sd-Gh for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:49:01 +0000 X-Inumbo-ID: 48c75076-a4b6-11ea-8993-bc764e2007e4 Received: from ppsw-30.csi.cam.ac.uk (unknown [131.111.8.130]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 48c75076-a4b6-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 09:49:00 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from 88-109-182-220.dynamic.dsl.as9105.com ([88.109.182.220]:53906 helo=[192.168.1.219]) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:465) with esmtpsa (PLAIN:amc96) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1jg3XT-000lLb-eL (Exim 4.92.3) (return-path ); Tue, 02 Jun 2020 10:48:55 +0100 Subject: Re: [PATCH for-4.14] compilers/clang: always use _Static_assert with clang To: paul@xen.org, 'Wei Liu' , 'Roger Pau Monne' References: <20200602091602.38422-1-roger.pau@citrix.com> <20200602092314.uydguwrje4bomktf@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <003a01d638bf$d54dc100$7fe94300$@xen.org> From: Andrew Cooper Message-ID: <8507bef6-9277-6960-b878-14adb387e42b@citrix.com> Date: Tue, 2 Jun 2020 10:48:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <003a01d638bf$d54dc100$7fe94300$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02/06/2020 10:26, Paul Durrant wrote: >> On Tue, Jun 02, 2020 at 11:16:02AM +0200, Roger Pau Monne wrote: >>> All versions of clang used by Xen support _Static_assert, so use it >>> unconditionally when building Xen with clang. >>> >>> No functional change expected. >>> >>> Signed-off-by: Roger Pau Monné >> Reviewed-by: Wei Liu >> >>> --- >>> Not sure whether this fully qualifies as a bugfix, as the current >>> behavior should also work fine under clang. Note that all versions of >>> clang from 3.5 to trunk (11) seem to return __GNUC__ == 4 and >>> __GNUC_MINOR__ == 2. >> IMHO it wouldn't hurt to apply this patch since any breakage is easy to >> catch. > Yes, seems reasonable. > > Release-acked-by: Paul Durrant Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Jun 02 09:49:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 09:49:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3YJ-0007vq-Ag; Tue, 02 Jun 2020 09:49:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3YI-0007vi-Jm for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 09:49:46 +0000 X-Inumbo-ID: 63f7a558-a4b6-11ea-9947-bc764e2007e4 Received: from ppsw-30.csi.cam.ac.uk (unknown [131.111.8.130]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 63f7a558-a4b6-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 09:49:46 +0000 (UTC) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from 88-109-182-220.dynamic.dsl.as9105.com ([88.109.182.220]:53914 helo=[192.168.1.219]) by ppsw-30.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:465) with esmtpsa (PLAIN:amc96) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) id 1jg3YF-000lhP-eF (Exim 4.92.3) (return-path ); Tue, 02 Jun 2020 10:49:43 +0100 Subject: Re: [PATCH for-4.14] x86/cpu: fix build with clang 3.5 To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20200602090536.38064-1-roger.pau@citrix.com> From: Andrew Cooper Message-ID: <025f047c-bf92-1ffd-031d-ec46e17f6ffa@citrix.com> Date: Tue, 2 Jun 2020 10:49:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200602090536.38064-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02/06/2020 10:05, Roger Pau Monne wrote: > Clang 3.5 complains with: > > common.c:794:24: error: statement expression not allowed at file scope > i < ARRAY_SIZE(this_cpu(tss_page).ist_ssp); ++i ) > ^ > /build/xen/include/asm/percpu.h:14:7: note: expanded from macro 'this_cpu' > (*RELOC_HIDE(&per_cpu__##var, get_cpu_info()->per_cpu_offset)) > ^ > /build/xen/include/xen/compiler.h:104:3: note: expanded from macro 'RELOC_HIDE' > ({ unsigned long __ptr; \ > ^ > /build/xen/include/xen/lib.h:68:69: note: expanded from macro 'ARRAY_SIZE' > #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]) + __must_be_array(x)) > ^ > /build/xen/include/xen/compiler.h:85:57: note: expanded from macro '__must_be_array' > BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0]))) > ^ > /build/xen/include/xen/lib.h:39:57: note: expanded from macro 'BUILD_BUG_ON_ZERO' > #define BUILD_BUG_ON_ZERO(cond) sizeof(struct { int:-!!(cond); }) > ^ > > Workaround this by defining the tss_page as a local variable. Adjust > other users of the per-cpu tss_page to also use the newly introduced > local variable. > > No functional change expected. > > Signed-off-by: Roger Pau Monné Sorry for more carnage. Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Tue Jun 02 10:00:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 10:00:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3iD-0000Tf-9I; Tue, 02 Jun 2020 10:00:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg3iC-0000Ta-0N for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 10:00:00 +0000 X-Inumbo-ID: d12468b8-a4b7-11ea-abc2-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d12468b8-a4b7-11ea-abc2-12813bfff9fa; Tue, 02 Jun 2020 09:59:58 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: d2Mu1LQtWWzeflpB18rpXYYVCxEvmvsmgsp/f2Lnpo5NKs3sdUyh4idN4VlKV1ycu5slUKKX1n TKLMTKpnhcp3HfjlB0IcJ8G1ZNKtfxj2VhPwf9nLzxrqWiVNM/3O1ktRB8YbhdaPky+Vg7Z6K2 jvRSdE8LO9a7iDggTjqiEdkcFT4ZHB+jwbPL6yUfitL0baH/GKNrdRdsshgumvbnTEUnYM4qql sgMvbZFBvKLF88mxuZoLDQT8aasDWXN4Cuf1DJIQJAqJQYiUGGpzGN0lsCBRekpqa2dJn506MH pnI= X-SBRS: 2.7 X-MesageID: 18998554 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,463,1583211600"; d="scan'208";a="18998554" Date: Tue, 2 Jun 2020 11:59:44 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Wei Liu Subject: Re: [[PATCH v2 for-4.14]] m4: use test instead of [] Message-ID: <20200602092447.GV1195@Air-de-Roger> References: <20200602090138.28656-1-wl@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200602090138.28656-1-wl@xen.org> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen Development List , paul@xen.org, Ian Jackson , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" There's a double [] enclosure in the subject On Tue, Jun 02, 2020 at 09:01:38AM +0000, Wei Liu wrote: > It is reported that [] was removed by autoconf, which caused the > following error: > > ./configure: line 4681: -z: command not found > > Switch to test. That's what is used throughout our configure scripts. > Also put the variable expansion in quotes. > > Signed-off-by: Wei Liu > Reported-by: Bertrand Marquis > Fixes: 8a6b1665d987 ("configure: also add EXTRA_PREFIX to {CPP/LD}FLAGS") > Signed-off-by: Wei Liu There's a double SoB ;) Reviewed-by: Roger Pau Monné Thanks for taking care of this. From xen-devel-bounces@lists.xenproject.org Tue Jun 02 10:26:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 10:26:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg47Z-00039O-DW; Tue, 02 Jun 2020 10:26:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg47Y-00039J-1U for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 10:26:12 +0000 X-Inumbo-ID: 7a4dc378-a4bb-11ea-9dbe-bc764e2007e4 Received: from mail-wm1-f66.google.com (unknown [209.85.128.66]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7a4dc378-a4bb-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 10:26:11 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id q25so2569227wmj.0 for ; Tue, 02 Jun 2020 03:26:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=nUCCIq84c7rWxewj8ROr+keME7J3I7bnw6MaVKLaJoo=; b=rd+EpPKKvRM3eWBKWUvX0Z1EBgru6zrmVGQ24H2ixbvLD2/bb4EjfrcrxfwOMe9BFq WSZNf91iUlv0rVocO9NY0gUsIDd4wThfr7e5245BpC2Fv/sphCZdMdsj2u7b/ObuC+5B XF4HHEK3MxyURLxk3Sj3a0KnoUEU4slGzMyJP5WFpEmjhQ65RgBqh8alm7kOOa5bm6EC SPc3RbIKfcvIei+4VaGP9wOhhnxBsPq/fXaXp/W5SzRlBRyEZ+E1i2jfakg37GgQv73u HAFRTWbOSTxTxlsqWbpwquLdyC9eNVQvhMAvhoAm5zdfudr1FD5uwFzfH568n0YXl5T/ 89XQ== X-Gm-Message-State: AOAM533qSmAfGN5QWa1/zxdR1gqVGsLbFuQ5cD4DMIXwOMIjAY+N3FYd yvD+hKX/sdU5Xt+gMBAUQv8= X-Google-Smtp-Source: ABdhPJzv7gjHN2hz4bTy5846mYUDKjgmN0IWTuB9aIRonWW6xC/DNf1vkdFkDKHRQRmZ0Y5MCXhGTw== X-Received: by 2002:a1c:ba86:: with SMTP id k128mr3393397wmf.19.1591093570174; Tue, 02 Jun 2020 03:26:10 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id h18sm3097579wru.7.2020.06.02.03.26.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 03:26:09 -0700 (PDT) Date: Tue, 2 Jun 2020 10:26:07 +0000 From: Wei Liu To: Tamas K Lengyel Subject: Re: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks Message-ID: <20200602102607.hwdfpkbg3fthurug@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Tamas K Lengyel , Jan Beulich , xen-devel@lists.xenproject.org, Roger Pau =?utf-8?B?TW9ubsOp?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 01, 2020 at 06:21:35AM -0700, Tamas K Lengyel wrote: > When running VM forks without device models (QEMU), it may > be undesirable for Xen to inject interrupts. When creating such forks from > Windows VMs we have observed the kernel trying to process interrupts > immediately after the fork is executed. However without QEMU running such > interrupt handling may not be possible because it may attempt to interact with > devices that are not emulated by a backend. In the best case scenario such > interrupt handling would only present a detour in the VM forks' execution > flow, but in the worst case as we actually observed can completely stall it. > By disabling interrupt injection a fuzzer can exercise the target code without > interference. For other use-cases this option probably doesn't make sense, > that's why this is not enabled by default. > > Forks & memory sharing are only available on Intel CPUs so this only applies > to vmx. Note that this is part of the experimental VM forking feature that's > completely disabled by default and can only be enabled by using > XEN_CONFIG_EXPERT during compile time. > > Signed-off-by: Tamas K Lengyel > Reviewed-by: Roger Pau Monn Reviewed-by: Wei Liu From xen-devel-bounces@lists.xenproject.org Tue Jun 02 10:26:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 10:26:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg47t-0003A2-Lm; Tue, 02 Jun 2020 10:26:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg47s-00039q-Fo for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 10:26:32 +0000 X-Inumbo-ID: 8586aa3e-a4bb-11ea-abc9-12813bfff9fa Received: from mail-wr1-f67.google.com (unknown [209.85.221.67]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8586aa3e-a4bb-11ea-abc9-12813bfff9fa; Tue, 02 Jun 2020 10:26:29 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id l11so2860867wru.0 for ; Tue, 02 Jun 2020 03:26:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=D6kJV+3QSzhZxH/1tco0e7UkStmVDCdOoRvJ1GRjAsc=; b=E64HxZO5eujMARn9FyebY3wAgZyBoLgREDQZZ3KvwlD0sSLDa0Yr3UkaJr+MLdQ/xL A0GsBqZ6cXzB13QhecZxD/zHQsrrX8EwLSEdwdrFW0iuM8s6InAOoHxx06miA0RHc/fz 4SUX5FfwewtXB75ZGgAIZNW/FUbYKFxGnoTcaOUwcVDuVP3KRxavzOO1jEpe0guuxy7B +0q2FURAcTjKFcnWlJx6tUW984RSR93KRKHpVnpQMtGWGrLHij1rha/DaUUvm0MIHb9C 6+TcgpUhRqJdnmKCGFhndCrFwaHMTZ/t8A5PsoKN8ndsHxmbNJXty2chJqUvkFGeAqb2 nTsA== X-Gm-Message-State: AOAM533i+IZKTs+oVTrHa4b0PgUBJSSfxXAofQDoeUCzJMJAVmgTA8no iTppcS1egZ6O+v80HQDXpLk= X-Google-Smtp-Source: ABdhPJwAma/4C2NBcxz+KGhxMFUU5+G0Ggb0pp+e8nXhzEd/JIlGIGBwrmy42kdC4gcxVku21DDevw== X-Received: by 2002:a5d:6cc1:: with SMTP id c1mr26729975wrc.144.1591093588813; Tue, 02 Jun 2020 03:26:28 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id o20sm3220786wra.29.2020.06.02.03.26.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 03:26:28 -0700 (PDT) Date: Tue, 2 Jun 2020 10:26:27 +0000 From: Wei Liu To: Tamas K Lengyel Subject: Re: [PATCH v19 for-4.14 02/13] tools/libxc: xc_memshr_fork with interrupts blocked Message-ID: <20200602102626.2i3vsnhygqp6f2ne@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: <03b382a38c62b5431c63d00f9acffacf43b55c1d.1591017086.git.tamas.lengyel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <03b382a38c62b5431c63d00f9acffacf43b55c1d.1591017086.git.tamas.lengyel@intel.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Ian Jackson , Wei Liu , Roger Pau =?utf-8?B?TW9ubsOp?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 01, 2020 at 06:21:36AM -0700, Tamas K Lengyel wrote: > Toolstack side for creating forks with interrupt injection blocked. > > Signed-off-by: Tamas K Lengyel > Reviewed-by: Roger Pau Monn > Acked-by: Ian Jackson Acked-by: Wei Liu From xen-devel-bounces@lists.xenproject.org Tue Jun 02 10:43:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 10:43:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4O1-0004wV-4h; Tue, 02 Jun 2020 10:43:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4O0-0004wQ-AW for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 10:43:12 +0000 X-Inumbo-ID: da8af3b2-a4bd-11ea-9947-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id da8af3b2-a4bd-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 10:43:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A3E56AC96; Tue, 2 Jun 2020 10:43:12 +0000 (UTC) Subject: Re: [PATCH v10 08/12] xen: add /buildinfo/config entry to hypervisor filesystem To: Andrew Cooper , xen-devel@lists.xenproject.org References: <20200519072106.26894-1-jgross@suse.com> <20200519072106.26894-9-jgross@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <95e4a29c-85e1-b7ed-ee7e-5517a094bd6a@suse.com> Date: Tue, 2 Jun 2020 12:43:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.20 11:03, Andrew Cooper wrote: > On 19/05/2020 08:21, Juergen Gross wrote: >> diff --git a/xen/common/Makefile b/xen/common/Makefile >> index bf7d0e25a3..3d61239fbf 100644 >> --- a/xen/common/Makefile >> +++ b/xen/common/Makefile >> @@ -1,6 +1,7 @@ >> obj-$(CONFIG_ARGO) += argo.o >> obj-y += bitmap.o >> obj-y += bsearch.o >> +obj-$(CONFIG_HYPFS_CONFIG) += config_data.o >> obj-$(CONFIG_CORE_PARKING) += core_parking.o >> obj-y += cpu.o >> obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o >> @@ -73,3 +74,14 @@ obj-$(CONFIG_UBSAN) += ubsan/ >> >> obj-$(CONFIG_NEEDS_LIBELF) += libelf/ >> obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ >> + >> +config.gz: ../.config >> + gzip -c $< >$@ > > I had to disable HYPFS in the XenServer build.  Inside RPM, this fails with Disabling CONFIG_HYPFS_CONFIG should work, too. > > make[3]: *** No rule to make target `../.config', needed by > `config.gz'.  Stop. > make[3]: *** Waiting for unfinished jobs.... > > This needs to be an expression involving $(KCONFIG_CONFIG) because > .config is only the default, and it surely needs a $(XEN_ROOT) in there? Will send a patch. Oh, in fact I'll send two patches, as I guess pv-shim doesn't want to have CONFIG_HYPFS set. Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:01:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:01:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4fk-0006pc-2a; Tue, 02 Jun 2020 11:01:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4fi-0006pV-G1 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:01:30 +0000 X-Inumbo-ID: 65ad747c-a4c0-11ea-abd2-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 65ad747c-a4c0-11ea-abd2-12813bfff9fa; Tue, 02 Jun 2020 11:01:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qeuEp4MCAdwJtxTFTW/s2su7IXBP3D2HWjbbXuRnYzQ=; b=P3bvBX9BlnL436gvLGpGQjqxn U3gEpZDuBYD118nfmyEL8prL4cWdGmTgbt0v83Cj/zhZGobJGkNZDbl+8i58E4L8oMDtbJGc6MKh8 GQ3KHFpFpyqE+PsuW3cECAYivUyHXEPruFs313y9ZKpRTddk+e+BIID+3+GoK++jQCId4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4fb-0001bg-36; Tue, 02 Jun 2020 11:01:23 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jg4fa-00089A-Px; Tue, 02 Jun 2020 11:01:22 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jg4fa-0003IS-Ow; Tue, 02 Jun 2020 11:01:22 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150609: tolerable FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Tue, 02 Jun 2020 11:01:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150609 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150609/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150589 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150589 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150589 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150589 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150589 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150589 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150589 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150589 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150589 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150589 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150589 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass version targeted for testing: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150609 2020-06-02 01:52:31 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:06:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:06:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4kl-00074D-Pq; Tue, 02 Jun 2020 11:06:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4kj-000742-O4 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:06:41 +0000 X-Inumbo-ID: 22952e54-a4c1-11ea-9dbe-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 22952e54-a4c1-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 11:06:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 26D98AD4D; Tue, 2 Jun 2020 11:06:42 +0000 (UTC) Subject: Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus [and 1 more messages] To: Jan Beulich References: <20200406082704.13994-1-jgross@suse.com> <24203.2251.628483.557280@mariner.uk.xensource.com> <26161282-7bad-5888-16c9-634647e6fde8@xen.org> <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com> <24203.2546.728186.463143@mariner.uk.xensource.com> <24203.2996.819908.965198@mariner.uk.xensource.com> <799396b3-0304-e149-cc3f-45c5a46c7c0c@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <715f6143-38b3-3f70-b9e3-1ac4a240282f@suse.com> Date: Tue, 2 Jun 2020 13:06:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , Ian Jackson , Julien Grall , Wei Liu , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 06.04.20 14:09, Jan Beulich wrote: > On 06.04.2020 13:54, Jürgen Groß wrote: >> On 06.04.20 13:11, Jan Beulich wrote: >>> On 06.04.2020 13:00, Ian Jackson wrote: >>>> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"): >>>>> There are no correlation between event channels and vCPUs. The number of >>>>> event channels only depends on the number of frontend you have in your >>>>> guest. So... >>>>> >>>>> Hi Ian, >>>>> >>>>> On 06/04/2020 11:47, Ian Jackson wrote: >>>>>> If ARM folks want to have a different formula for the default then >>>>>> that is of course fine but I wonder whether this might do ARMk more >>>>>> harm than good in this case. >>>>> >>>>> ... 1023 event channels is going to be plenty enough for most of the use >>>>> cases. >>>> >>>> OK, thanks for the quick reply. >>>> >>>> So, Jürgen, I think everyone will be happy with this: >>> >>> I don't think I will be - my prior comment still holds on there not >>> being any grounds to use a specific OS kernel's (and to be precise >>> a specific OS kernel version's) requirements for determining >>> defaults. If there was to be such a dependency, then OS kernel >>> [variant] should be part of the inputs to such a (set of) formula(s). >> >> IMO this kind of trying to be perfect will completely block a sane >> heuristic for being able to boot large guests at all. > > This isn't about being perfect - I'm suggesting to leave the > default alone, not to improve the calculation, not the least > because I've been implying ... > >> The patch isn't about to find an as stringent as possible upper >> boundary for huge guests, but a sane value being able to boot most of >> those. >> >> And how should Xen know the OS kernel needs exactly after all? > > ... the answer of "It can#t" to this question. > >> And it is not that we talking about megabytes of additional memory. A >> guest with 256 vcpus will just be able to use additional 36 memory >> pages. The maximum non-PV domain (the probably only relevant case >> of another OS than Linux being used) with 128 vcpus would "waste" >> 32 kB. In case the guest misbehaves. > > Any extra page counts, or else - where do you draw the line? Any > single page may decide between Xen (not) being out of memory, > and hence also not being able to fulfill certain other requests. > >> The alternative would be to do nothing and having to let the user >> experience a somewhat cryptic guest crash. He could google for a >> possible solution which would probably end in a rather high static >> limit resulting in wasting even more memory. > > I realize this. Otoh more people running into this will improve > the chances of later ones finding useful suggestions. Of course > there's also nothing wrong with trying to make the error less > cryptic. Reviving this discussion. I strongly disagree with your reasoning. Rejecting to modify tools defaults for large guests to make them boot is a bad move IMO. We are driving more people away from Xen this way. The fear of a misbehaving guest of that size to use a few additional pages on a machine with at least 100 cpus is fine from the academical point of view, but should not be weighed higher than the usability aspect in this case IMO. Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:08:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:08:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4mL-0007B4-4X; Tue, 02 Jun 2020 11:08:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4mJ-0007Ax-TT for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:08:19 +0000 X-Inumbo-ID: 5c66761a-a4c1-11ea-8993-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5c66761a-a4c1-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 11:08:17 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: CA6JXN5taPJIG5chtMC3k/73aTWN226RsB1rFfHpGv4KZ/MhlIPozAKeYMftYN+ZF2T/HgQ1fC 8pEJgZqpUdqqERGNhKrxdFcib4FSl15h/tey1hxjI1H/1DESSDbotM5LoH+/Z5eQFM1axKbD08 MOcTsFSncQRMVr4xCkH69zpVEkudx1pJamUSZ8Mt+Lx9koZavCtCqSjO2BcoxGdpbI3MClf+s9 HdGOsZ/idZQtkGQjJ6/XNT6VZQmhUUTXloE9yv4EFvsVJLwcwYoMdUDPYkewubfhpkevERZ0mQ KOE= X-SBRS: 2.7 X-MesageID: 19356099 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,464,1583211600"; d="scan'208";a="19356099" Date: Tue, 2 Jun 2020 13:08:07 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values Message-ID: <20200602110223.GW1195@Air-de-Roger> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: > Extend the monitor_op domctl to include option that enables > controlling what values certain registers are permitted to hold > by a monitor subscriber. I think the change could benefit for some more detail commit message here. Why is this useful? There already seems to be some support for gating MSR writes, which seems to be expanded by this commit? Is it solving some kind of bug reported? > Signed-off-by: Tamas K Lengyel > --- > xen/arch/x86/hvm/hvm.c | 25 ++++++++++++++++--------- > xen/arch/x86/monitor.c | 10 +++++++++- > xen/include/asm-x86/domain.h | 1 + > xen/include/public/domctl.h | 1 + > 4 files changed, 27 insertions(+), 10 deletions(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 09ee299bc7..e6780c685b 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -2263,7 +2263,8 @@ int hvm_set_cr0(unsigned long value, bool may_defer) > { > ASSERT(v->arch.vm_event); > > - if ( hvm_monitor_crX(CR0, value, old_value) ) > + if ( hvm_monitor_crX(CR0, value, old_value) && > + v->domain->arch.monitor.control_register_values ) > { > /* The actual write will occur in hvm_do_resume(), if permitted. */ > v->arch.vm_event->write_data.do_write.cr0 = 1; > @@ -2362,7 +2363,8 @@ int hvm_set_cr3(unsigned long value, bool may_defer) > { > ASSERT(v->arch.vm_event); > > - if ( hvm_monitor_crX(CR3, value, old) ) > + if ( hvm_monitor_crX(CR3, value, old) && > + v->domain->arch.monitor.control_register_values ) > { > /* The actual write will occur in hvm_do_resume(), if permitted. */ > v->arch.vm_event->write_data.do_write.cr3 = 1; > @@ -2443,7 +2445,8 @@ int hvm_set_cr4(unsigned long value, bool may_defer) > { > ASSERT(v->arch.vm_event); > > - if ( hvm_monitor_crX(CR4, value, old_cr) ) > + if ( hvm_monitor_crX(CR4, value, old_cr) && > + v->domain->arch.monitor.control_register_values ) I think you could return control_register_values in hvm_monitor_crX instead of having to add the check to each caller? > { > /* The actual write will occur in hvm_do_resume(), if permitted. */ > v->arch.vm_event->write_data.do_write.cr4 = 1; > @@ -3587,13 +3590,17 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content, > > ASSERT(v->arch.vm_event); > > - /* The actual write will occur in hvm_do_resume() (if permitted). */ > - v->arch.vm_event->write_data.do_write.msr = 1; > - v->arch.vm_event->write_data.msr = msr; > - v->arch.vm_event->write_data.value = msr_content; > - > hvm_monitor_msr(msr, msr_content, msr_old_content); > - return X86EMUL_OKAY; > + > + if ( v->domain->arch.monitor.control_register_values ) Is there any value in limiting control_register_values to MSR that represent control registers, like EFER and XSS? > + { > + /* The actual write will occur in hvm_do_resume(), if permitted. */ > + v->arch.vm_event->write_data.do_write.msr = 1; > + v->arch.vm_event->write_data.msr = msr; > + v->arch.vm_event->write_data.value = msr_content; > + > + return X86EMUL_OKAY; > + } You seem to change the previous flow of the function here, that would just call hvm_monitor_msr and return previously. Don't you need to move the return from outside the added if condition in order to keep previous behavior? Or else the write is committed straight away. > } > > if ( (ret = guest_wrmsr(v, msr, msr_content)) != X86EMUL_UNHANDLEABLE ) > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > index bbcb7536c7..1517a97f50 100644 > --- a/xen/arch/x86/monitor.c > +++ b/xen/arch/x86/monitor.c > @@ -144,7 +144,15 @@ int arch_monitor_domctl_event(struct domain *d, > struct xen_domctl_monitor_op *mop) > { > struct arch_domain *ad = &d->arch; > - bool requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op); > + bool requested_status; > + > + if ( XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS == mop->op ) > + { > + ad->monitor.control_register_values = true; I think strictly speaking you need to use 1 here, since this variable is not a boolean. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:13:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:13:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4qu-00083M-NX; Tue, 02 Jun 2020 11:13:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4qt-00083H-RO for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:13:03 +0000 X-Inumbo-ID: 0615fc58-a4c2-11ea-abd4-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0615fc58-a4c2-11ea-abd4-12813bfff9fa; Tue, 02 Jun 2020 11:13:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C97A3AD4D; Tue, 2 Jun 2020 11:13:03 +0000 (UTC) Subject: Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus [and 1 more messages] To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= References: <20200406082704.13994-1-jgross@suse.com> <24203.2251.628483.557280@mariner.uk.xensource.com> <26161282-7bad-5888-16c9-634647e6fde8@xen.org> <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com> <24203.2546.728186.463143@mariner.uk.xensource.com> <24203.2996.819908.965198@mariner.uk.xensource.com> <799396b3-0304-e149-cc3f-45c5a46c7c0c@suse.com> <715f6143-38b3-3f70-b9e3-1ac4a240282f@suse.com> From: Jan Beulich Message-ID: <08eff8dd-59b2-9f3e-9664-ff126eecd123@suse.com> Date: Tue, 2 Jun 2020 13:12:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <715f6143-38b3-3f70-b9e3-1ac4a240282f@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , Ian Jackson , Julien Grall , Wei Liu , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 13:06, Jürgen Groß wrote: > On 06.04.20 14:09, Jan Beulich wrote: >> On 06.04.2020 13:54, Jürgen Groß wrote: >>> On 06.04.20 13:11, Jan Beulich wrote: >>>> On 06.04.2020 13:00, Ian Jackson wrote: >>>>> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"): >>>>>> There are no correlation between event channels and vCPUs. The number of >>>>>> event channels only depends on the number of frontend you have in your >>>>>> guest. So... >>>>>> >>>>>> Hi Ian, >>>>>> >>>>>> On 06/04/2020 11:47, Ian Jackson wrote: >>>>>>> If ARM folks want to have a different formula for the default then >>>>>>> that is of course fine but I wonder whether this might do ARMk more >>>>>>> harm than good in this case. >>>>>> >>>>>> ... 1023 event channels is going to be plenty enough for most of the use >>>>>> cases. >>>>> >>>>> OK, thanks for the quick reply. >>>>> >>>>> So, Jürgen, I think everyone will be happy with this: >>>> >>>> I don't think I will be - my prior comment still holds on there not >>>> being any grounds to use a specific OS kernel's (and to be precise >>>> a specific OS kernel version's) requirements for determining >>>> defaults. If there was to be such a dependency, then OS kernel >>>> [variant] should be part of the inputs to such a (set of) formula(s). >>> >>> IMO this kind of trying to be perfect will completely block a sane >>> heuristic for being able to boot large guests at all. >> >> This isn't about being perfect - I'm suggesting to leave the >> default alone, not to improve the calculation, not the least >> because I've been implying ... >> >>> The patch isn't about to find an as stringent as possible upper >>> boundary for huge guests, but a sane value being able to boot most of >>> those. >>> >>> And how should Xen know the OS kernel needs exactly after all? >> >> ... the answer of "It can#t" to this question. >> >>> And it is not that we talking about megabytes of additional memory. A >>> guest with 256 vcpus will just be able to use additional 36 memory >>> pages. The maximum non-PV domain (the probably only relevant case >>> of another OS than Linux being used) with 128 vcpus would "waste" >>> 32 kB. In case the guest misbehaves. >> >> Any extra page counts, or else - where do you draw the line? Any >> single page may decide between Xen (not) being out of memory, >> and hence also not being able to fulfill certain other requests. >> >>> The alternative would be to do nothing and having to let the user >>> experience a somewhat cryptic guest crash. He could google for a >>> possible solution which would probably end in a rather high static >>> limit resulting in wasting even more memory. >> >> I realize this. Otoh more people running into this will improve >> the chances of later ones finding useful suggestions. Of course >> there's also nothing wrong with trying to make the error less >> cryptic. > > Reviving this discussion. > > I strongly disagree with your reasoning. > > Rejecting to modify tools defaults for large guests to make them boot > is a bad move IMO. We are driving more people away from Xen this way. > > The fear of a misbehaving guest of that size to use a few additional > pages on a machine with at least 100 cpus is fine from the academical > point of view, but should not be weighed higher than the usability > aspect in this case IMO. Very simple question then: Where do you draw the boundary if you don't want this to be a pure "is permitted" or "is not permitted" underlying rule? If we had a model where _all_ resources consumed by a guest were accounted against its tool stack requested allocation, things would be easier. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:18:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:18:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4wA-0008Dl-Bc; Tue, 02 Jun 2020 11:18:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg4w8-0008Dg-UM for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:18:28 +0000 X-Inumbo-ID: c8040f9e-a4c2-11ea-abd7-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c8040f9e-a4c2-11ea-abd7-12813bfff9fa; Tue, 02 Jun 2020 11:18:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EC03BAA6F; Tue, 2 Jun 2020 11:18:28 +0000 (UTC) Subject: Re: [PATCH for-4.14] docs/ucode: Extend runtime microcode loading documentation To: Andrew Cooper References: <20200601134025.24142-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 13:18:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200601134025.24142-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Paul Durrant , Ian Jackson , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 01.06.2020 15:40, Andrew Cooper wrote: > Extend the disclaimer about runtime loading. While we've done our best to > make the mechaism reliable, the safety of late loading does ultimately depend > on the contents of the blobs. > > Extend the xen-ucode portion with examples of how to use it. > > Signed-off-by: Andrew Cooper > --- > CC: George Dunlap > CC: Ian Jackson > CC: Jan Beulich > CC: Konrad Rzeszutek Wilk > CC: Stefano Stabellini > CC: Wei Liu > CC: Julien Grall > CC: Paul Durrant > --- > docs/admin-guide/microcode-loading.rst | 22 +++++++++++++++++++--- > 1 file changed, 19 insertions(+), 3 deletions(-) > > diff --git a/docs/admin-guide/microcode-loading.rst b/docs/admin-guide/microcode-loading.rst > index 5f0f661a2e..8cd5d0351b 100644 > --- a/docs/admin-guide/microcode-loading.rst > +++ b/docs/admin-guide/microcode-loading.rst > @@ -104,8 +104,8 @@ modules to find any CPIO archives, and search the archive for the applicable > file. Xen will stop searching at the first match. > > > -Run time microcode loading > --------------------------- > +Runtime microcode loading > +------------------------- > > .. warning:: > > @@ -113,7 +113,23 @@ Run time microcode loading > or at boot time. Not all microcode updates (or parts thereof) can be > applied at runtime. > > -The ``xen-ucode`` utility can be used to initiate a runtime microcode load. > + Given the proprietry nature of microcode, we are unable to make any claim > + that a runtime microcode is risk-free. Any runtime microcode loading needs "that runtime microcode loading is risk-free" (or some such, including the word "load")? Then Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:23:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:23:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg50g-0000ff-UJ; Tue, 02 Jun 2020 11:23:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg50f-0000fY-0p for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:23:09 +0000 X-Inumbo-ID: 6e749178-a4c3-11ea-abd8-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6e749178-a4c3-11ea-abd8-12813bfff9fa; Tue, 02 Jun 2020 11:23:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 83AAFAD1E; Tue, 2 Jun 2020 11:23:08 +0000 (UTC) Subject: Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus [and 1 more messages] To: Jan Beulich References: <20200406082704.13994-1-jgross@suse.com> <24203.2251.628483.557280@mariner.uk.xensource.com> <26161282-7bad-5888-16c9-634647e6fde8@xen.org> <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com> <24203.2546.728186.463143@mariner.uk.xensource.com> <24203.2996.819908.965198@mariner.uk.xensource.com> <799396b3-0304-e149-cc3f-45c5a46c7c0c@suse.com> <715f6143-38b3-3f70-b9e3-1ac4a240282f@suse.com> <08eff8dd-59b2-9f3e-9664-ff126eecd123@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <01ff5111-d5bf-f4ba-6fba-a156b89eaf85@suse.com> Date: Tue, 2 Jun 2020 13:23:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <08eff8dd-59b2-9f3e-9664-ff126eecd123@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , Ian Jackson , Julien Grall , Wei Liu , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.20 13:12, Jan Beulich wrote: > On 02.06.2020 13:06, Jürgen Groß wrote: >> On 06.04.20 14:09, Jan Beulich wrote: >>> On 06.04.2020 13:54, Jürgen Groß wrote: >>>> On 06.04.20 13:11, Jan Beulich wrote: >>>>> On 06.04.2020 13:00, Ian Jackson wrote: >>>>>> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"): >>>>>>> There are no correlation between event channels and vCPUs. The number of >>>>>>> event channels only depends on the number of frontend you have in your >>>>>>> guest. So... >>>>>>> >>>>>>> Hi Ian, >>>>>>> >>>>>>> On 06/04/2020 11:47, Ian Jackson wrote: >>>>>>>> If ARM folks want to have a different formula for the default then >>>>>>>> that is of course fine but I wonder whether this might do ARMk more >>>>>>>> harm than good in this case. >>>>>>> >>>>>>> ... 1023 event channels is going to be plenty enough for most of the use >>>>>>> cases. >>>>>> >>>>>> OK, thanks for the quick reply. >>>>>> >>>>>> So, Jürgen, I think everyone will be happy with this: >>>>> >>>>> I don't think I will be - my prior comment still holds on there not >>>>> being any grounds to use a specific OS kernel's (and to be precise >>>>> a specific OS kernel version's) requirements for determining >>>>> defaults. If there was to be such a dependency, then OS kernel >>>>> [variant] should be part of the inputs to such a (set of) formula(s). >>>> >>>> IMO this kind of trying to be perfect will completely block a sane >>>> heuristic for being able to boot large guests at all. >>> >>> This isn't about being perfect - I'm suggesting to leave the >>> default alone, not to improve the calculation, not the least >>> because I've been implying ... >>> >>>> The patch isn't about to find an as stringent as possible upper >>>> boundary for huge guests, but a sane value being able to boot most of >>>> those. >>>> >>>> And how should Xen know the OS kernel needs exactly after all? >>> >>> ... the answer of "It can#t" to this question. >>> >>>> And it is not that we talking about megabytes of additional memory. A >>>> guest with 256 vcpus will just be able to use additional 36 memory >>>> pages. The maximum non-PV domain (the probably only relevant case >>>> of another OS than Linux being used) with 128 vcpus would "waste" >>>> 32 kB. In case the guest misbehaves. >>> >>> Any extra page counts, or else - where do you draw the line? Any >>> single page may decide between Xen (not) being out of memory, >>> and hence also not being able to fulfill certain other requests. >>> >>>> The alternative would be to do nothing and having to let the user >>>> experience a somewhat cryptic guest crash. He could google for a >>>> possible solution which would probably end in a rather high static >>>> limit resulting in wasting even more memory. >>> >>> I realize this. Otoh more people running into this will improve >>> the chances of later ones finding useful suggestions. Of course >>> there's also nothing wrong with trying to make the error less >>> cryptic. >> >> Reviving this discussion. >> >> I strongly disagree with your reasoning. >> >> Rejecting to modify tools defaults for large guests to make them boot >> is a bad move IMO. We are driving more people away from Xen this way. >> >> The fear of a misbehaving guest of that size to use a few additional >> pages on a machine with at least 100 cpus is fine from the academical >> point of view, but should not be weighed higher than the usability >> aspect in this case IMO. > > Very simple question then: Where do you draw the boundary if you don't > want this to be a pure "is permitted" or "is not permitted" underlying > rule? If we had a model where _all_ resources consumed by a guest were > accounted against its tool stack requested allocation, things would be > easier. I'd say it should be allowed in case the additional resource use is much smaller than the already used implicit resources for such a guest (e.g. less than an additional 1% of implicitly used memory). In cases like this, where a very small subset of guests is affected, and the additional need of resources will apply only in very extreme cases (I'm considering this case as extreme, as only non-Linux guests with huge numbers of vcpus _and_ which are misbehaving will need additional resources) I'd even accept higher margins like 5%. Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:23:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:23:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg50s-0000hj-9n; Tue, 02 Jun 2020 11:23:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg50r-0000hW-Bb for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:23:21 +0000 X-Inumbo-ID: 7676f2da-a4c3-11ea-abd8-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7676f2da-a4c3-11ea-abd8-12813bfff9fa; Tue, 02 Jun 2020 11:23:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0B259AD48; Tue, 2 Jun 2020 11:23:21 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/ucode: Fix errors with start/end_update() To: Andrew Cooper References: <20200601145755.3661-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 13:23:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200601145755.3661-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 01.06.2020 16:57, Andrew Cooper wrote: > --- a/xen/arch/x86/cpu/microcode/amd.c > +++ b/xen/arch/x86/cpu/microcode/amd.c > @@ -395,26 +395,9 @@ static struct microcode_patch *cpu_request_microcode(const void *buf, size_t siz > return patch; > } > > -#ifdef CONFIG_HVM > -static int start_update(void) > -{ > - /* > - * svm_host_osvw_init() will be called on each cpu by calling '.end_update' > - * in common code. > - */ > - svm_host_osvw_reset(); > - > - return 0; > -} > -#endif > - > const struct microcode_ops amd_ucode_ops = { > .cpu_request_microcode = cpu_request_microcode, > .collect_cpu_info = collect_cpu_info, > .apply_microcode = apply_microcode, > -#ifdef CONFIG_HVM > - .start_update = start_update, > - .end_update_percpu = svm_host_osvw_init, As a result the function can (and imo should) become static. Preferably with that Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:41:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:41:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5I3-0002Xt-AJ; Tue, 02 Jun 2020 11:41:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5I1-0002WP-FN for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:41:05 +0000 X-Inumbo-ID: eab6ee8c-a4c5-11ea-9dbe-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eab6ee8c-a4c5-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 11:40:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DC1E7ABF4; Tue, 2 Jun 2020 11:40:55 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 2/2] xen/config: disable hypervisor filesystem for pv-shim Date: Tue, 2 Jun 2020 13:40:50 +0200 Message-Id: <20200602114050.5964-3-jgross@suse.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200602114050.5964-1-jgross@suse.com> References: <20200602114050.5964-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , paul@xen.org, Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The pv-shim doesn't need the hypervisor filesystem, so disable it. Signed-off-by: Juergen Gross --- xen/arch/x86/configs/pvshim_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig index 9710aa6238..830660e022 100644 --- a/xen/arch/x86/configs/pvshim_defconfig +++ b/xen/arch/x86/configs/pvshim_defconfig @@ -6,6 +6,7 @@ CONFIG_PV_SHIM=y CONFIG_PV_SHIM_EXCLUSIVE=y CONFIG_NR_CPUS=32 # Disable features not used by the PV shim +# CONFIG_HYPFS is not set # CONFIG_SHADOW_PAGING is not set # CONFIG_BIGMEM is not set # CONFIG_HVM_FEP is not set -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:41:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:41:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5Hy-0002WB-2C; Tue, 02 Jun 2020 11:41:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5Hw-0002W2-Ef for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:41:00 +0000 X-Inumbo-ID: ea9fb35c-a4c5-11ea-9dbe-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ea9fb35c-a4c5-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 11:40:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 78663AD5D; Tue, 2 Jun 2020 11:40:55 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 0/2] xen: build fixes for CONFIG_HYPFS Date: Tue, 2 Jun 2020 13:40:48 +0200 Message-Id: <20200602114050.5964-1-jgross@suse.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Fixing an issue Andrew met, and disabling CONFIG_HYPFS in pv-shim. Juergen Gross (2): xen: fix build with CONFIG_HYPFS_CONFIG enabled xen/config: disable hypervisor filesystem for pv-shim xen/arch/x86/configs/pvshim_defconfig | 1 + xen/common/Makefile | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:41:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:41:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5Hs-0002VF-Ph; Tue, 02 Jun 2020 11:40:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5Hr-0002VA-J8 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:40:55 +0000 X-Inumbo-ID: eaa3c488-a4c5-11ea-9dbe-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eaa3c488-a4c5-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 11:40:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A364FAE00; Tue, 2 Jun 2020 11:40:55 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 1/2] xen: fix build with CONFIG_HYPFS_CONFIG enabled Date: Tue, 2 Jun 2020 13:40:49 +0200 Message-Id: <20200602114050.5964-2-jgross@suse.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200602114050.5964-1-jgross@suse.com> References: <20200602114050.5964-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Commit 58263ed7713e ("xen: add /buildinfo/config entry to hypervisor filesystem") added a dependency to .config, but the hypervisor's build config could be have another name via setting KCONFIG_CONFIG. Fix that by using $(KCONFIG_CONFIG) instead. Additionally reference the config file via $(XEN_ROOT) instead of a relative path. Reported-by: Andrew Cooper Signed-off-by: Juergen Gross --- xen/common/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/common/Makefile b/xen/common/Makefile index 91581e1815..2799f6510c 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -75,7 +75,7 @@ obj-$(CONFIG_UBSAN) += ubsan/ obj-$(CONFIG_NEEDS_LIBELF) += libelf/ obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ -config.gz: ../.config +config.gz: $(XEN_ROOT)/xen/$(KCONFIG_CONFIG) gzip -c $< >$@ config_data.o: config.gz -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:42:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:42:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5JO-0002kr-Kk; Tue, 02 Jun 2020 11:42:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5JM-0002ki-BZ for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:42:28 +0000 X-Inumbo-ID: 21ee075a-a4c6-11ea-abe2-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 21ee075a-a4c6-11ea-abe2-12813bfff9fa; Tue, 02 Jun 2020 11:42:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591098146; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=n86EWlLVVQJF888j88kFvnEq87VILobhIPcTVq7aNUg=; b=KgBhIuzv+mm524anh0uNKwEZCuQmR1SkeB4MPg5b/OVVZlJ13IvdgwX7Fwco+Zq8ASHUUS hPaKiTLwU0jb+XoArXRYoehnwxnokEKsyiTR1kohiY+KvmVhSz81pXeFZHkXhEoTZ8YAOU ifHX70lvIAvtYWeyJEzbxa1MVo02pIU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-98-J1Kd89-tN1aLuY9q9_gUgQ-1; Tue, 02 Jun 2020 07:42:24 -0400 X-MC-Unique: J1Kd89-tN1aLuY9q9_gUgQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EC87819200C9; Tue, 2 Jun 2020 11:42:22 +0000 (UTC) Received: from linux.fritz.box (ovpn-113-75.ams2.redhat.com [10.36.113.75]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9C70D7F0A8; Tue, 2 Jun 2020 11:42:05 +0000 (UTC) Date: Tue, 2 Jun 2020 13:42:03 +0200 From: Kevin Wolf To: Roman Kagan , Markus Armbruster , qemu-devel@nongnu.org, Fam Zheng , Stefano Stabellini , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Eduardo Habkost , qemu-block@nongnu.org, Paul Durrant , John Snow , "Michael S. Tsirkin" , Laurent Vivier , Max Reitz , Keith Busch , Gerd Hoffmann , Stefan Hajnoczi , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= Subject: Re: [PATCH v8 2/8] block: consolidate blocksize properties consistency checks Message-ID: <20200602114203.GG5940@linux.fritz.box> References: <20200528225516.1676602-1-rvkagan@yandex-team.ru> <20200528225516.1676602-3-rvkagan@yandex-team.ru> <87r1v3m5ih.fsf@dusky.pond.sub.org> <20200529105636.GB1255099@rvkaganb.lan> MIME-Version: 1.0 In-Reply-To: <20200529105636.GB1255099@rvkaganb.lan> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Am 29.05.2020 um 12:56 hat Roman Kagan geschrieben: > On Fri, May 29, 2020 at 11:53:26AM +0200, Markus Armbruster wrote: > > Roman Kagan writes: > > > > > Several block device properties related to blocksize configuration must > > > be in certain relationship WRT each other: physical block must be no > > > smaller than logical block; min_io_size, opt_io_size, and > > > discard_granularity must be a multiple of a logical block. > > > > > > To ensure these requirements are met, add corresponding consistency > > > checks to blkconf_blocksizes, adjusting its signature to communicate > > > possible error to the caller. Also remove the now redundant consistency > > > checks from the specific devices. > > > > > > Signed-off-by: Roman Kagan > > > Reviewed-by: Eric Blake > > > Reviewed-by: Paul Durrant > > > --- > > > include/hw/block/block.h | 2 +- > > > hw/block/block.c | 30 +++++++++++++++++++++++++++++- > > > hw/block/fdc.c | 5 ++++- > > > hw/block/nvme.c | 5 ++++- > > > hw/block/swim.c | 5 ++++- > > > hw/block/virtio-blk.c | 7 +------ > > > hw/block/xen-block.c | 6 +----- > > > hw/ide/qdev.c | 5 ++++- > > > hw/scsi/scsi-disk.c | 12 +++++------- > > > hw/usb/dev-storage.c | 5 ++++- > > > tests/qemu-iotests/172.out | 2 +- > > > 11 files changed, 58 insertions(+), 26 deletions(-) > > > > > > diff --git a/include/hw/block/block.h b/include/hw/block/block.h > > > index d7246f3862..784953a237 100644 > > > --- a/include/hw/block/block.h > > > +++ b/include/hw/block/block.h > > > @@ -87,7 +87,7 @@ bool blk_check_size_and_read_all(BlockBackend *blk, void *buf, hwaddr size, > > > bool blkconf_geometry(BlockConf *conf, int *trans, > > > unsigned cyls_max, unsigned heads_max, unsigned secs_max, > > > Error **errp); > > > -void blkconf_blocksizes(BlockConf *conf); > > > +bool blkconf_blocksizes(BlockConf *conf, Error **errp); > > > bool blkconf_apply_backend_options(BlockConf *conf, bool readonly, > > > bool resizable, Error **errp); > > > > > > diff --git a/hw/block/block.c b/hw/block/block.c > > > index bf56c7612b..b22207c921 100644 > > > --- a/hw/block/block.c > > > +++ b/hw/block/block.c > > > @@ -61,7 +61,7 @@ bool blk_check_size_and_read_all(BlockBackend *blk, void *buf, hwaddr size, > > > return true; > > > } > > > > > > -void blkconf_blocksizes(BlockConf *conf) > > > +bool blkconf_blocksizes(BlockConf *conf, Error **errp) > > > { > > > BlockBackend *blk = conf->blk; > > > BlockSizes blocksizes; > > > @@ -83,6 +83,34 @@ void blkconf_blocksizes(BlockConf *conf) > > > conf->logical_block_size = BDRV_SECTOR_SIZE; > > > } > > > } > > > + > > > + if (conf->logical_block_size > conf->physical_block_size) { > > > + error_setg(errp, > > > + "logical_block_size > physical_block_size not supported"); > > > + return false; > > > + } > > > > Pardon me if this has been answered already for prior revisions: do we > > really support physical block sizes that are not a multiple of the > > logical block size? > > Both physical and logical block sizes are required to be powers of two, > so the former is certain to be a multiple of the latter. > > > > + > > > + if (!QEMU_IS_ALIGNED(conf->min_io_size, conf->logical_block_size)) { > > > + error_setg(errp, > > > + "min_io_size must be a multiple of logical_block_size"); > > > + return false; > > > + } > > > + > > > + if (!QEMU_IS_ALIGNED(conf->opt_io_size, conf->logical_block_size)) { > > > + error_setg(errp, > > > + "opt_io_size must be a multiple of logical_block_size"); > > > + return false; > > > + } > > > + > > > + if (conf->discard_granularity != -1 && > > > + !QEMU_IS_ALIGNED(conf->discard_granularity, > > > + conf->logical_block_size)) { > > > + error_setg(errp, "discard_granularity must be " > > > + "a multiple of logical_block_size"); > > > + return false; > > > + } > > > + > > > + return true; > > > } > > > > > > bool blkconf_apply_backend_options(BlockConf *conf, bool readonly, > > > diff --git a/hw/block/fdc.c b/hw/block/fdc.c > > > index c5fb9d6ece..8eda572ef4 100644 > > > --- a/hw/block/fdc.c > > > +++ b/hw/block/fdc.c > > > @@ -554,7 +554,10 @@ static void floppy_drive_realize(DeviceState *qdev, Error **errp) > > > read_only = !blk_bs(dev->conf.blk) || blk_is_read_only(dev->conf.blk); > > > } > > > > > > - blkconf_blocksizes(&dev->conf); > > > + if (!blkconf_blocksizes(&dev->conf, errp)) { > > > + return; > > > + } > > > + > > > if (dev->conf.logical_block_size != 512 || > > > dev->conf.physical_block_size != 512) > > > { > > > diff --git a/hw/block/nvme.c b/hw/block/nvme.c > > > index 2f3100e56c..672650e162 100644 > > > --- a/hw/block/nvme.c > > > +++ b/hw/block/nvme.c > > > @@ -1390,7 +1390,10 @@ static void nvme_realize(PCIDevice *pci_dev, Error **errp) > > > host_memory_backend_set_mapped(n->pmrdev, true); > > > } > > > > > > - blkconf_blocksizes(&n->conf); > > > + if (!blkconf_blocksizes(&n->conf, errp)) { > > > + return; > > > + } > > > + > > > if (!blkconf_apply_backend_options(&n->conf, blk_is_read_only(n->conf.blk), > > > false, errp)) { > > > return; > > > diff --git a/hw/block/swim.c b/hw/block/swim.c > > > index 8f124782f4..74f56e8f46 100644 > > > --- a/hw/block/swim.c > > > +++ b/hw/block/swim.c > > > @@ -189,7 +189,10 @@ static void swim_drive_realize(DeviceState *qdev, Error **errp) > > > assert(ret == 0); > > > } > > > > > > - blkconf_blocksizes(&dev->conf); > > > + if (!blkconf_blocksizes(&dev->conf, errp)) { > > > + return; > > > + } > > > + > > > if (dev->conf.logical_block_size != 512 || > > > dev->conf.physical_block_size != 512) > > > { > > > diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c > > > index 413083e62f..4ffdb130be 100644 > > > --- a/hw/block/virtio-blk.c > > > +++ b/hw/block/virtio-blk.c > > > @@ -1162,12 +1162,7 @@ static void virtio_blk_device_realize(DeviceState *dev, Error **errp) > > > return; > > > } > > > > > > - blkconf_blocksizes(&conf->conf); > > > - > > > - if (conf->conf.logical_block_size > > > > - conf->conf.physical_block_size) { > > > - error_setg(errp, > > > - "logical_block_size > physical_block_size not supported"); > > > + if (!blkconf_blocksizes(&conf->conf, errp)) { > > > return; > > > } > > > > > > diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c > > > index 570489d6d9..e17fec50e1 100644 > > > --- a/hw/block/xen-block.c > > > +++ b/hw/block/xen-block.c > > > @@ -239,11 +239,7 @@ static void xen_block_realize(XenDevice *xendev, Error **errp) > > > return; > > > } > > > > > > - blkconf_blocksizes(conf); > > > - > > > - if (conf->logical_block_size > conf->physical_block_size) { > > > - error_setg( > > > - errp, "logical_block_size > physical_block_size not supported"); > > > + if (!blkconf_blocksizes(conf, errp)) { > > > return; > > > } > > > > > > diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c > > > index 06b11583f5..b4821b2403 100644 > > > --- a/hw/ide/qdev.c > > > +++ b/hw/ide/qdev.c > > > @@ -187,7 +187,10 @@ static void ide_dev_initfn(IDEDevice *dev, IDEDriveKind kind, Error **errp) > > > return; > > > } > > > > > > - blkconf_blocksizes(&dev->conf); > > > + if (!blkconf_blocksizes(&dev->conf, errp)) { > > > + return; > > > + } > > > + > > > if (dev->conf.logical_block_size != 512) { > > > error_setg(errp, "logical_block_size must be 512 for IDE"); > > > return; > > > diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c > > > index 387503e11b..8ce68a9dd6 100644 > > > --- a/hw/scsi/scsi-disk.c > > > +++ b/hw/scsi/scsi-disk.c > > > @@ -2346,12 +2346,7 @@ static void scsi_realize(SCSIDevice *dev, Error **errp) > > > return; > > > } > > > > > > - blkconf_blocksizes(&s->qdev.conf); > > > - > > > - if (s->qdev.conf.logical_block_size > > > > - s->qdev.conf.physical_block_size) { > > > - error_setg(errp, > > > - "logical_block_size > physical_block_size not supported"); > > > + if (!blkconf_blocksizes(&s->qdev.conf, errp)) { > > > return; > > > } > > > > > > @@ -2436,7 +2431,9 @@ static void scsi_hd_realize(SCSIDevice *dev, Error **errp) > > > if (s->qdev.conf.blk) { > > > ctx = blk_get_aio_context(s->qdev.conf.blk); > > > aio_context_acquire(ctx); > > > - blkconf_blocksizes(&s->qdev.conf); > > > + if (!blkconf_blocksizes(&s->qdev.conf, errp)) { > > > + goto out; > > > + } > > > } > > > s->qdev.blocksize = s->qdev.conf.logical_block_size; > > > s->qdev.type = TYPE_DISK; > > > @@ -2444,6 +2441,7 @@ static void scsi_hd_realize(SCSIDevice *dev, Error **errp) > > > s->product = g_strdup("QEMU HARDDISK"); > > > } > > > scsi_realize(&s->qdev, errp); > > > +out: > > > if (ctx) { > > > aio_context_release(ctx); > > > } > > > diff --git a/hw/usb/dev-storage.c b/hw/usb/dev-storage.c > > > index 4eba47538d..de461f37bd 100644 > > > --- a/hw/usb/dev-storage.c > > > +++ b/hw/usb/dev-storage.c > > > @@ -599,7 +599,10 @@ static void usb_msd_storage_realize(USBDevice *dev, Error **errp) > > > return; > > > } > > > > > > - blkconf_blocksizes(&s->conf); > > > + if (!blkconf_blocksizes(&s->conf, errp)) { > > > + return; > > > + } > > > + > > > if (!blkconf_apply_backend_options(&s->conf, blk_is_read_only(blk), true, > > > errp)) { > > > return; > > > diff --git a/tests/qemu-iotests/172.out b/tests/qemu-iotests/172.out > > > index 7abbe82427..59cc70aebb 100644 > > > --- a/tests/qemu-iotests/172.out > > > +++ b/tests/qemu-iotests/172.out > > > @@ -1204,7 +1204,7 @@ Testing: -drive if=none,file=TEST_DIR/t.qcow2 -device floppy,drive=none0,physica > > > drive-type = "144" > > > > > > Testing: -drive if=none,file=TEST_DIR/t.qcow2 -device floppy,drive=none0,logical_block_size=4096 > > > -QEMU_PROG: -device floppy,drive=none0,logical_block_size=4096: Physical and logical block size must be 512 for floppy > > > +QEMU_PROG: -device floppy,drive=none0,logical_block_size=4096: logical_block_size > physical_block_size not supported > > > > > > Testing: -drive if=none,file=TEST_DIR/t.qcow2 -device floppy,drive=none0,physical_block_size=1024 > > > QEMU_PROG: -device floppy,drive=none0,physical_block_size=1024: Physical and logical block size must be 512 for floppy > > > > This no longer exercises floppy_drive_realize()'s check of > > logical_block_size: > > > > if (dev->conf.logical_block_size != 512 || > > dev->conf.physical_block_size != 512) > > Right, this check of logical_block_size here becomes redundant now, > because eariler it's verified to be no less than 512 and no more than > physical_block_size, which is required to be 512 here. I thought it > made no harm to leave it here as it was, and decided not to bother > replacing it with a comment as to why the condition is known to be true. > > > { > > error_setg(errp, "Physical and logical block size must " > > "be 512 for floppy"); > > return; > > } > > > > Please update the test. > > The test still makes sense, it just triggers another assertion now. How > do you suggest to update it? I guess we could just add another case with physical=logical=4096 so we test both the original floppy check (with the new case) and your new check (with the existing case). But as you explained above, it's kind of redundant and we can't tell from the result whether the logical or the physical check failed (they are then both unsuitable for floppy), so maybe adding that case is rather pointless. Kevin From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:47:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:47:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5OF-00032x-DQ; Tue, 02 Jun 2020 11:47:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5OE-00032s-Ko for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:47:30 +0000 X-Inumbo-ID: d6019bc6-a4c6-11ea-9947-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d6019bc6-a4c6-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 11:47:29 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /GoGzeFUN7WsRiQTJ1TYFzktZgzfei0w8bPzjNlIDkSYd2hmXwx/SbGYqvIao7Dv5z2xH9b94u vaxOszn/fVF+/vimswcvhyH0uj5UAtFGHajA9N3JWGtIioeRZNJalKLld3WngycpEfZl72VRiy j4+oZ0uO/ACc5kw1DusfN+ae9Or5364CckQCbds8Zrbwy9r10MCGTuQ9yB3H9ozyPeY/1bwA9V SLra5pZdjwKymXzgVnDVdHaZIbzKILkYZXqu1AZRz/JvYvdcQUQKri+ofnO8xlM2KYw7c3cuuv Z/Y= X-SBRS: 2.7 X-MesageID: 19753068 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,464,1583211600"; d="scan'208";a="19753068" Date: Tue, 2 Jun 2020 13:47:22 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH v2 for-4.14 2/3] xen/vm_event: add vm_event_check_pending_op Message-ID: <20200602114722.GX1195@Air-de-Roger> References: <52492e7b44f311b09e9a433f2e5a2ba607a85c78.1590028160.git.tamas@tklengyel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <52492e7b44f311b09e9a433f2e5a2ba607a85c78.1590028160.git.tamas@tklengyel.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Jan Beulich , Alexandru Isaila , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, May 20, 2020 at 08:31:53PM -0600, Tamas K Lengyel wrote: > Perform sanity checking when shutting vm_event down to determine whether > it is safe to do so. Error out with -EAGAIN in case pending operations > have been found for the domain. > > Signed-off-by: Tamas K Lengyel > --- > xen/arch/x86/vm_event.c | 23 +++++++++++++++++++++++ > xen/common/vm_event.c | 17 ++++++++++++++--- > xen/include/asm-arm/vm_event.h | 7 +++++++ > xen/include/asm-x86/vm_event.h | 2 ++ > 4 files changed, 46 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c > index 848d69c1b0..a23aadc112 100644 > --- a/xen/arch/x86/vm_event.c > +++ b/xen/arch/x86/vm_event.c > @@ -297,6 +297,29 @@ void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp) > }; > } > > +bool vm_event_check_pending_op(const struct vcpu *v) > +{ > + struct monitor_write_data *w = &v->arch.vm_event->write_data; const > + > + if ( !v->arch.vm_event->sync_event ) > + return false; > + > + if ( w->do_write.cr0 ) > + return true; > + if ( w->do_write.cr3 ) > + return true; > + if ( w->do_write.cr4 ) > + return true; > + if ( w->do_write.msr ) > + return true; > + if ( v->arch.vm_event->set_gprs ) > + return true; > + if ( v->arch.vm_event->emulate_flags ) > + return true; Can you please group this into a single if, ie: if ( w->do_write.cr0 || w->do_write.cr3 || ... ) return true; > + > + return false; > +} > + > /* > * Local variables: > * mode: C > diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c > index 127f2d58f1..2df327a42c 100644 > --- a/xen/common/vm_event.c > +++ b/xen/common/vm_event.c > @@ -183,6 +183,7 @@ static int vm_event_disable(struct domain *d, struct vm_event_domain **p_ved) > if ( vm_event_check_ring(ved) ) > { > struct vcpu *v; > + bool pending_op = false; > > spin_lock(&ved->lock); > > @@ -192,9 +193,6 @@ static int vm_event_disable(struct domain *d, struct vm_event_domain **p_ved) > return -EBUSY; > } > > - /* Free domU's event channel and leave the other one unbound */ > - free_xen_event_channel(d, ved->xen_port); > - > /* Unblock all vCPUs */ > for_each_vcpu ( d, v ) > { > @@ -203,8 +201,21 @@ static int vm_event_disable(struct domain *d, struct vm_event_domain **p_ved) > vcpu_unpause(v); > ved->blocked--; > } > + > + if ( vm_event_check_pending_op(v) ) > + pending_op = true; You could just do: pending_op |= vm_event_check_pending_op(v); and avoid the initialization of pending_op above. Or alternatively: if ( !pending_op && vm_event_check_pending_op(v) ) pending_op = true; Which avoid repeated calls to vm_event_check_pending_op when at least one vCPU is known to be busy. > } > > + /* vm_event ops are still pending until vCPUs get scheduled */ > + if ( pending_op ) > + { > + spin_unlock(&ved->lock); > + return -EAGAIN; What happens when this gets called from vm_event_cleanup? AFAICT the result there is ignored, and could leak the vm_event allocated memory? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:50:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:50:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5RS-0003tV-0d; Tue, 02 Jun 2020 11:50:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5RQ-0003tQ-Ji for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:50:48 +0000 X-Inumbo-ID: 4bee20de-a4c7-11ea-abe3-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4bee20de-a4c7-11ea-abe3-12813bfff9fa; Tue, 02 Jun 2020 11:50:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 1A66CACA3; Tue, 2 Jun 2020 11:50:48 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14 2/3] xen/vm_event: add vm_event_check_pending_op To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <52492e7b44f311b09e9a433f2e5a2ba607a85c78.1590028160.git.tamas@tklengyel.com> <20200602114722.GX1195@Air-de-Roger> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 13:50:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200602114722.GX1195@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Tamas K Lengyel , Julien Grall , Wei Liu , Andrew Cooper , Stefano Stabellini , Alexandru Isaila , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 13:47, Roger Pau Monné wrote: > On Wed, May 20, 2020 at 08:31:53PM -0600, Tamas K Lengyel wrote: >> Perform sanity checking when shutting vm_event down to determine whether >> it is safe to do so. Error out with -EAGAIN in case pending operations >> have been found for the domain. >> >> Signed-off-by: Tamas K Lengyel >> --- >> xen/arch/x86/vm_event.c | 23 +++++++++++++++++++++++ >> xen/common/vm_event.c | 17 ++++++++++++++--- >> xen/include/asm-arm/vm_event.h | 7 +++++++ >> xen/include/asm-x86/vm_event.h | 2 ++ >> 4 files changed, 46 insertions(+), 3 deletions(-) >> >> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c >> index 848d69c1b0..a23aadc112 100644 >> --- a/xen/arch/x86/vm_event.c >> +++ b/xen/arch/x86/vm_event.c >> @@ -297,6 +297,29 @@ void vm_event_emulate_check(struct vcpu *v, vm_event_response_t *rsp) >> }; >> } >> >> +bool vm_event_check_pending_op(const struct vcpu *v) >> +{ >> + struct monitor_write_data *w = &v->arch.vm_event->write_data; > > const > >> + >> + if ( !v->arch.vm_event->sync_event ) >> + return false; >> + >> + if ( w->do_write.cr0 ) >> + return true; >> + if ( w->do_write.cr3 ) >> + return true; >> + if ( w->do_write.cr4 ) >> + return true; >> + if ( w->do_write.msr ) >> + return true; >> + if ( v->arch.vm_event->set_gprs ) >> + return true; >> + if ( v->arch.vm_event->emulate_flags ) >> + return true; > > Can you please group this into a single if, ie: > > if ( w->do_write.cr0 || w->do_write.cr3 || ... ) > return true; > >> + >> + return false; >> +} >> + >> /* >> * Local variables: >> * mode: C >> diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c >> index 127f2d58f1..2df327a42c 100644 >> --- a/xen/common/vm_event.c >> +++ b/xen/common/vm_event.c >> @@ -183,6 +183,7 @@ static int vm_event_disable(struct domain *d, struct vm_event_domain **p_ved) >> if ( vm_event_check_ring(ved) ) >> { >> struct vcpu *v; >> + bool pending_op = false; >> >> spin_lock(&ved->lock); >> >> @@ -192,9 +193,6 @@ static int vm_event_disable(struct domain *d, struct vm_event_domain **p_ved) >> return -EBUSY; >> } >> >> - /* Free domU's event channel and leave the other one unbound */ >> - free_xen_event_channel(d, ved->xen_port); >> - >> /* Unblock all vCPUs */ >> for_each_vcpu ( d, v ) >> { >> @@ -203,8 +201,21 @@ static int vm_event_disable(struct domain *d, struct vm_event_domain **p_ved) >> vcpu_unpause(v); >> ved->blocked--; >> } >> + >> + if ( vm_event_check_pending_op(v) ) >> + pending_op = true; > > You could just do: > > pending_op |= vm_event_check_pending_op(v); > > and avoid the initialization of pending_op above. The initialization has to stay, or it couldn't be |= afaict. > Or alternatively: > > if ( !pending_op && vm_event_check_pending_op(v) ) > pending_op = true; > > Which avoid repeated calls to vm_event_check_pending_op when at least > one vCPU is known to be busy. if ( !pending_op ) pending_op = vm_event_check_pending_op(v); ? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:55:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:55:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5VP-00043g-Ix; Tue, 02 Jun 2020 11:54:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5VN-00043b-SK for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:54:53 +0000 X-Inumbo-ID: dbc562a8-a4c7-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dbc562a8-a4c7-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 11:54:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Kf4rrLec+XLg/DmZFrjWNhvjqKekXm9hFEX1Okphkx8=; b=mfwEYwMHAFFRdaKI6QvFBa1nO aYZmA44xCN40E5ZwHt11Wqr3IZa20hPe7mw7kqxg0tJkQX7JG1/jqSIYLKkr8I+HoA80InpUbPnkI xMRC2fJUDwQ0U1YVA76NsQKFrlGjTSvW/uVBvr7P4im3PmNfcwjOxvL+cYB+3oV1iX/VU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5VH-0002kx-Ed; Tue, 02 Jun 2020 11:54:47 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jg5VH-00019E-59; Tue, 02 Jun 2020 11:54:47 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jg5VH-0005xQ-4W; Tue, 02 Jun 2020 11:54:47 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150614: all pass - PUSHED X-Osstest-Versions-This: ovmf=ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 X-Osstest-Versions-That: ovmf=4403bbd7c0964144ea72f27e2bc8048b0c0a26e1 From: osstest service owner Date: Tue, 02 Jun 2020 11:54:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150614 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150614/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 baseline version: ovmf 4403bbd7c0964144ea72f27e2bc8048b0c0a26e1 Last test of basis 150611 2020-06-02 03:09:41 Z 0 days Testing same since 150614 2020-06-02 08:10:08 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel Gary Lin Laszlo Ersek jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 4403bbd7c0..ca407c7246 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:55:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:55:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5Vl-000462-RP; Tue, 02 Jun 2020 11:55:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5Vl-00045w-Hq for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:55:17 +0000 X-Inumbo-ID: ecc97fee-a4c7-11ea-8993-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ecc97fee-a4c7-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 11:55:17 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4BB56AD63; Tue, 2 Jun 2020 11:55:18 +0000 (UTC) Subject: Re: [PATCH-for-4.14 1/2] xen: fix build with CONFIG_HYPFS_CONFIG enabled To: Juergen Gross References: <20200602114050.5964-1-jgross@suse.com> <20200602114050.5964-2-jgross@suse.com> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 13:55:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200602114050.5964-2-jgross@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 13:40, Juergen Gross wrote: > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -75,7 +75,7 @@ obj-$(CONFIG_UBSAN) += ubsan/ > obj-$(CONFIG_NEEDS_LIBELF) += libelf/ > obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ > > -config.gz: ../.config > +config.gz: $(XEN_ROOT)/xen/$(KCONFIG_CONFIG) Looking at all pre-existing uses of KCONFIG_CONFIG this is the first one assuming it holds a relative path. The doc also doesn't indicate it can't be an absolute one. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 11:55:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 11:55:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5WL-0004Aw-51; Tue, 02 Jun 2020 11:55:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5WK-0004Aj-A1 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 11:55:52 +0000 X-Inumbo-ID: 0186c40a-a4c8-11ea-9947-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0186c40a-a4c8-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 11:55:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 33440ACA3; Tue, 2 Jun 2020 11:55:53 +0000 (UTC) Subject: Re: [PATCH-for-4.14 2/2] xen/config: disable hypervisor filesystem for pv-shim To: Juergen Gross References: <20200602114050.5964-1-jgross@suse.com> <20200602114050.5964-3-jgross@suse.com> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 13:55:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200602114050.5964-3-jgross@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 13:40, Juergen Gross wrote: > The pv-shim doesn't need the hypervisor filesystem, so disable it. > > Signed-off-by: Juergen Gross Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:06:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:06:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5gP-0005Ib-J6; Tue, 02 Jun 2020 12:06:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5gN-0005IW-Nc for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:06:15 +0000 X-Inumbo-ID: 74d990da-a4c9-11ea-9dbe-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 74d990da-a4c9-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 12:06:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 37B31ACA3; Tue, 2 Jun 2020 12:06:16 +0000 (UTC) Subject: Re: [PATCH v2 03/14] x86/shstk: Introduce Supervisor Shadow Stack support To: Andrew Cooper References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-4-andrew.cooper3@citrix.com> <4f535d4c-b3b3-fe5b-8b57-af736dc0a360@suse.com> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 14:06:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , Xen-devel , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.05.2020 20:36, Andrew Cooper wrote: > On 29/05/2020 12:59, Jan Beulich wrote: >> On 28.05.2020 20:10, Andrew Cooper wrote: >>> On 28/05/2020 11:25, Jan Beulich wrote: >>>> On 27.05.2020 21:18, Andrew Cooper wrote: >>>>> --- a/xen/arch/x86/Kconfig >>>>> +++ b/xen/arch/x86/Kconfig >>>>> @@ -34,6 +34,10 @@ config ARCH_DEFCONFIG >>>>> config INDIRECT_THUNK >>>>> def_bool $(cc-option,-mindirect-branch-register) >>>>> >>>>> +config HAS_AS_CET >>>>> + # binutils >= 2.29 and LLVM >= 7 >>>>> + def_bool $(as-instr,wrssq %rax$(comma)0;setssbsy;endbr64) >>>> So you put me in a really awkward position: I'd really like to see >>>> this series go in for 4.14, yet I've previously indicated I want the >>>> underlying concept to first be agreed upon, before any uses get >>>> introduced. >>> There are already users.  One of them is even in context. >> Hmm, indeed. I clearly didn't notice this aspect when reviewing >> Anthony's series. >> >>> I don't see that there is anything open for dispute in the first place.  >>> Being able to do exactly this was a one key driving factor to a newer >>> Kconfig, because it is superior mechanism to the ad-hoc mess we had >>> previously (not to mention, a vast detriment to build time). >> This "key driving factor" was presumably from your perspective. >> Could you point me to a discussion (and resulting decision) that >> this is an explicit goal of that work? I don't recall any, and >> hence I also don't recall having been given a chance in influence >> the direction, decision, and overall outcome. > > It took up a large chunk of the build system design session in Chicago. I don't recall; perhaps I was in another parallel session? If it's the one with notes at https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00786.html then a remark close to the top suggests I was there, but there's no sign of this aspect having got discussed. There is, among the issues listed, "Xen build re-evaluates compiler support for every translation unit", but that's only remotely related. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:06:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:06:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5gT-0005Ip-RG; Tue, 02 Jun 2020 12:06:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5gS-0005Ih-IX for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:06:20 +0000 X-Inumbo-ID: 757a7720-a4c9-11ea-8993-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 757a7720-a4c9-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 12:06:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591099575; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=d7m2QFyJVw1rLrp1fry7cSRUKAvbCa1EjKPWalkfzgM=; b=Wjxdx6Axfwo17oakcxQFwF9SYRLwqy66yjHXu/kDOsTZtusISnlLxffYDhyC+21Wk8dgdG pQP/0XWIef7iwdz0YZHkEHKpP+w9kRN+SVOcwVo5s1Pi4zX1dAHILyHZsQZCpg1eej79ws mZzo/u/OHojx4rOdGQ23Jz/G1Yjh6Jk= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-379-HzgcIdNxPJWTTIpM-n8EoA-1; Tue, 02 Jun 2020 08:06:11 -0400 X-MC-Unique: HzgcIdNxPJWTTIpM-n8EoA-1 Received: by mail-wm1-f72.google.com with SMTP id 11so760394wmj.6 for ; Tue, 02 Jun 2020 05:06:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=d7m2QFyJVw1rLrp1fry7cSRUKAvbCa1EjKPWalkfzgM=; b=rK+B0h51qW5Ga0n9gTAKG3vPQ2qSOIjkMM/cH5Yxr22u91yzypnEcs4dKyu0Xw8uHl hIjKRsHvQBm9GWzQ217vjLSw9LR4JoC8WrEgWsADieZMAGXr7iHhIQDB8G+fbZs5VISC k//MhSjtlSVVAOEuh6UOKqWS3mHaBmpSLiMm0yuSm4gCmfUicExQ9KMftYeUV5BCOVD8 0I605bMqFNbGKJm+WQ93E7t75QXRqh+rRLupQ9uZFDP+sKtqAnkRmDPAlkjZKuL675eA Opu8jv15JXlfXkrFFw3AUaM+R49sKjRMt9ukUDbCG9Pe7uscnK+uo6A/nKTQDm15x2WG 5Vpg== X-Gm-Message-State: AOAM533TtLneQkSd0QAHsS3IIL1uDLi3W05fdA4/q2Ngn26m5PskxihA 8Kmu6+bt/32Q5K0MZvl0txEdhao6eZddaOdebDPu1atkl9IZJt09cTkTivkAFuXt1kCHjsVfFyh TvRLnivr0CaLvqNPZSV8AS5x9DAE= X-Received: by 2002:a1c:e20a:: with SMTP id z10mr3595243wmg.63.1591099570434; Tue, 02 Jun 2020 05:06:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6/5iO0FjobYpMpwbo/RzDPk0W+RqLPZyFssRcCX6GjUd4vY6UZSLo9NiCzNn0T62+PgeDMA== X-Received: by 2002:a1c:e20a:: with SMTP id z10mr3595223wmg.63.1591099570229; Tue, 02 Jun 2020 05:06:10 -0700 (PDT) Received: from [192.168.1.43] (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id k14sm3392890wrq.97.2020.06.02.05.06.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 05:06:09 -0700 (PDT) Subject: Re: [PATCH v8 5/8] qdev-properties: make blocksize accept size suffixes To: Roman Kagan , qemu-devel@nongnu.org References: <20200528225516.1676602-1-rvkagan@yandex-team.ru> <20200528225516.1676602-6-rvkagan@yandex-team.ru> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: <3b747d26-4bba-7691-c13b-a48c8df5257b@redhat.com> Date: Tue, 2 Jun 2020 14:06:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200528225516.1676602-6-rvkagan@yandex-team.ru> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Fam Zheng , Kevin Wolf , Stefano Stabellini , =?UTF-8?Q?Daniel_P=2e_Berrang=c3=a9?= , Eduardo Habkost , qemu-block@nongnu.org, Paul Durrant , Eric Blake , "Michael S. Tsirkin" , Laurent Vivier , Max Reitz , Keith Busch , Gerd Hoffmann , Stefan Hajnoczi , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, John Snow Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 5/29/20 12:55 AM, Roman Kagan wrote: > It appears convenient to be able to specify physical_block_size and > logical_block_size using common size suffixes. > > Teach the blocksize property setter to interpret them. Also express the > upper and lower limits in the respective units. > > Signed-off-by: Roman Kagan > Reviewed-by: Eric Blake > --- > hw/core/qdev-properties.c | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) Reviewed-by: Philippe Mathieu-Daudé From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:07:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:07:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5hb-0005SP-5o; Tue, 02 Jun 2020 12:07:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5hZ-0005SH-KL for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:07:29 +0000 X-Inumbo-ID: a125bf60-a4c9-11ea-81bc-bc764e2007e4 Received: from mail-wr1-f68.google.com (unknown [209.85.221.68]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a125bf60-a4c9-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 12:07:29 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id r7so3177176wro.1 for ; Tue, 02 Jun 2020 05:07:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Wp/6lUDFZC0s0sD2fAFwXs/FjyFtaZK74th7zSxlrUE=; b=GthVZyVMOBlCmH2sFB4u0lz8yGz91M2pLCmMM/XTdacEhHu9w5ndfQcXTThV5Tby3T ghGMOLvz77Ujp5aNdKiSc2nIGKMobRXD+LyqM18z4XyWSnfAck1EaB58pHusSeqCyp1V OPjji8XVkDzm4nz3LbsTvvKKNtdaAaBdVYnz2CZh1HtHZCRSKCOczwwVI4XQIifn/8Cg 2vB3uhjbZhJY9j9xNK9/hAKWDJabtPH/m1LgzlkN0RHczmmg10SFb7AfHgvPoTw6opo/ ZmSJ5L83zr2H384LhNJh2T3wUxSSLzQYp8nNFeufo4DSLsoqPt3Ye9Aik9LYAmwSkM8L XKDQ== X-Gm-Message-State: AOAM531ZySOLP5auHabSzKw9PR+XRO69baCfElrOhthQvwpWgsOJ8Gm3 m9duNdbyX5fFup4A0XDLLAU= X-Google-Smtp-Source: ABdhPJwJYjiX5YIK2lY2jtMizJ+82pMOXwhkx4ebDOvOmRWJoUwPm9uURIVjwmyl1uogusiKhX1KFw== X-Received: by 2002:adf:dec5:: with SMTP id i5mr23657004wrn.16.1591099648355; Tue, 02 Jun 2020 05:07:28 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id k17sm3246435wmj.15.2020.06.02.05.07.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 05:07:27 -0700 (PDT) Date: Tue, 2 Jun 2020 12:07:26 +0000 From: Wei Liu To: Jan Beulich Subject: Re: [PATCH-for-4.14 1/2] xen: fix build with CONFIG_HYPFS_CONFIG enabled Message-ID: <20200602120726.vm3br27ygbvbs2bx@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: <20200602114050.5964-1-jgross@suse.com> <20200602114050.5964-2-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 01:55:14PM +0200, Jan Beulich wrote: > On 02.06.2020 13:40, Juergen Gross wrote: > > --- a/xen/common/Makefile > > +++ b/xen/common/Makefile > > @@ -75,7 +75,7 @@ obj-$(CONFIG_UBSAN) += ubsan/ > > obj-$(CONFIG_NEEDS_LIBELF) += libelf/ > > obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ > > > > -config.gz: ../.config > > +config.gz: $(XEN_ROOT)/xen/$(KCONFIG_CONFIG) > > Looking at all pre-existing uses of KCONFIG_CONFIG this is the > first one assuming it holds a relative path. The doc also doesn't > indicate it can't be an absolute one. This is not an objection to this patch right? Wei. > > Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:09:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:09:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5jA-0005cM-H2; Tue, 02 Jun 2020 12:09:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5j9-0005cH-1k for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:09:07 +0000 X-Inumbo-ID: db1ece96-a4c9-11ea-9947-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id db1ece96-a4c9-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 12:09:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DCCD5AE2C; Tue, 2 Jun 2020 12:09:07 +0000 (UTC) Subject: Re: [PATCH v2 03/14] x86/shstk: Introduce Supervisor Shadow Stack support To: Andrew Cooper References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-4-andrew.cooper3@citrix.com> <4f535d4c-b3b3-fe5b-8b57-af736dc0a360@suse.com> <20200529155118.GL2105@perard.uk.xensource.com> <4c759ccc-b256-c074-0bd8-fe2d5c728715@citrix.com> From: Jan Beulich Message-ID: <2f22aac8-6fb0-95a0-3c2f-47c4379b87dc@suse.com> Date: Tue, 2 Jun 2020 14:09:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <4c759ccc-b256-c074-0bd8-fe2d5c728715@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Xen-devel , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.05.2020 20:39, Andrew Cooper wrote: > On 29/05/2020 16:51, Anthony PERARD wrote: >> On Fri, May 29, 2020 at 01:59:55PM +0200, Jan Beulich wrote: >>> On 28.05.2020 20:10, Andrew Cooper wrote: >>>> On 28/05/2020 11:25, Jan Beulich wrote: >>>>> On 27.05.2020 21:18, Andrew Cooper wrote: >>>>>> --- a/xen/scripts/Kconfig.include >>>>>> +++ b/xen/scripts/Kconfig.include >>>>>> @@ -31,6 +31,10 @@ cc-option = $(success,$(CC) -Werror $(CLANG_FLAGS) $(1) -E -x c /dev/null -o /de >>>>>> # Return y if the linker supports , n otherwise >>>>>> ld-option = $(success,$(LD) -v $(1)) >>>>>> >>>>>> +# $(as-instr,) >>>>>> +# Return y if the assembler supports , n otherwise >>>>>> +as-instr = $(success,printf "%b\n" "$(1)" | $(CC) $(CLANG_FLAGS) -c -x assembler -o /dev/null -) >>>>> Is this actually checking the right thing in the clang case? >>>> Appears to work correctly for me.  (Again, its either fine, or need >>>> bugfixing anyway for 4.14, and raising with Linux as this is unmodified >>>> upstream code like the rest of Kconfig.include). >>> This answer made me try it out: On a system with clang 5 and >>> binutils 2.32 "incsspd %eax" translates fine with >>> -no-integrated-as but doesn't without. The previously mentioned >>> odd use of CLANG_FLAGS, perhaps together with the disconnect >>> from where we establish whether to use -no-integrated-as in the >>> first place (arch.mk; I have no idea whether the CFLAGS >>> determined would be usable by the kconfig invocation, nor how >>> to solve the chicken-and-egg problem there if this is meant to >>> work that way), may be the reason for this. Cc-ing Anthony once >>> again ... >> I've just prepare/sent a patch which should fix this CLANG_FLAGS issue >> and allows to tests the assembler in Kconfig. >> >> See: [XEN PATCH] xen/build: introduce CLANG_FLAGS for testing other CFLAGS > > Thanks.  I've checked carefully, and this is an improvement from before. > > Therefore I have acked and included the patch. > > However, I think there is a further problem.  When -no-integrated-as > does get passed down, I don't see Clang falling back to using the Gnu > assember, so I suspect we have a further plumbing problem.  (It only > affects Clang 5.0 and earlier, so obsolete toolchains these days). Hmm, what exactly do you mean saying "I don't see Clang falling back ..."? In the playing I did, I specifically passed -v to see what gets or does not get invoked, and it was /usr/bin/as that did get used (clang 5.0.1). Obviously it'll be whatever /usr/bin/as is then. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:19:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:19:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5sy-0006Zz-GN; Tue, 02 Jun 2020 12:19:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5sx-0006Zu-2v for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:19:15 +0000 X-Inumbo-ID: 458b0cda-a4cb-11ea-9947-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 458b0cda-a4cb-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 12:19:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6EEADACF1; Tue, 2 Jun 2020 12:19:15 +0000 (UTC) Subject: Re: [PATCH-for-4.14 1/2] xen: fix build with CONFIG_HYPFS_CONFIG enabled To: Wei Liu , Jan Beulich References: <20200602114050.5964-1-jgross@suse.com> <20200602114050.5964-2-jgross@suse.com> <20200602120726.vm3br27ygbvbs2bx@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <7157b762-014b-802a-ea85-ae7bf89a5d73@suse.com> Date: Tue, 2 Jun 2020 14:19:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200602120726.vm3br27ygbvbs2bx@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.20 14:07, Wei Liu wrote: > On Tue, Jun 02, 2020 at 01:55:14PM +0200, Jan Beulich wrote: >> On 02.06.2020 13:40, Juergen Gross wrote: >>> --- a/xen/common/Makefile >>> +++ b/xen/common/Makefile >>> @@ -75,7 +75,7 @@ obj-$(CONFIG_UBSAN) += ubsan/ >>> obj-$(CONFIG_NEEDS_LIBELF) += libelf/ >>> obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ >>> >>> -config.gz: ../.config >>> +config.gz: $(XEN_ROOT)/xen/$(KCONFIG_CONFIG) >> >> Looking at all pre-existing uses of KCONFIG_CONFIG this is the >> first one assuming it holds a relative path. The doc also doesn't >> indicate it can't be an absolute one. > > This is not an objection to this patch right? I can see his point. In case KCONFIG_CONFIG is set to an absolute path the result won't build. The proper solution would be to test KCONFIG_CONFIG for being an absolute path and do the prefixing of $(XEN_ROOT)/xen/ only if this isn't the case. I'll send V2 of this patch. Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:26:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:26:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5zs-0007Ru-87; Tue, 02 Jun 2020 12:26:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg5zq-0007Rp-Cs for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:26:22 +0000 X-Inumbo-ID: 43e99fd0-a4cc-11ea-abe9-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 43e99fd0-a4cc-11ea-abe9-12813bfff9fa; Tue, 02 Jun 2020 12:26:21 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 38/cUJF2n0GRfQ+3xT75snHQEgyfJAy0Rp8BwX8JHd0piM+97kIXtswsoOlVLZBfHEvj9onD+c DbucfAn17gJJ5pR1kk3RWpWuOdel3ejeb4JJRPf6CBviHaId7w6PMzUTP6ptbrC1RHnNJtfo9h HZo2lSIJqiV8PmX+OowjsAJLOq3xJl6SJyV2YjVcH7+q9TgMTXNsNCduLkR9zRQOOVAD6+GT4p 1Hhe7JH4oGMMYpRIdcxvciTwiZxVoPhNSWQ2OYGh+VnOB4WP1pbT9ybdP189JUp1VFbxwivLP2 v/8= X-SBRS: 2.7 X-MesageID: 19009501 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,464,1583211600"; d="scan'208";a="19009501" Date: Tue, 2 Jun 2020 13:26:14 +0100 From: Anthony PERARD To: Jan Beulich , Andrew Cooper Subject: Re: [PATCH v2 03/14] x86/shstk: Introduce Supervisor Shadow Stack support Message-ID: <20200602122614.GN2105@perard.uk.xensource.com> References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-4-andrew.cooper3@citrix.com> <4f535d4c-b3b3-fe5b-8b57-af736dc0a360@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu , Roger Pau =?iso-8859-1?Q?Monn=E9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 02:06:11PM +0200, Jan Beulich wrote: > I don't recall; perhaps I was in another parallel session? If it's > the one with notes at > https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00786.html > then a remark close to the top suggests I was there, but there's no > sign of this aspect having got discussed. There is, among the issues > listed, "Xen build re-evaluates compiler support for every translation > unit", but that's only remotely related. What is a "translation unit"? What would that have to do with Kconfig? Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:32:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:32:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg65S-0008JK-Ta; Tue, 02 Jun 2020 12:32:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg65S-0008JF-CL for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:32:10 +0000 X-Inumbo-ID: 13721886-a4cd-11ea-9947-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 13721886-a4cd-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 12:32:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D6405ABD1; Tue, 2 Jun 2020 12:32:10 +0000 (UTC) Subject: Re: [PATCH v2 06/14] x86/shstk: Create shadow stacks To: Andrew Cooper References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-7-andrew.cooper3@citrix.com> <8a02b933-3b7e-ded9-8bf3-a1c35f2ef7ae@suse.com> From: Jan Beulich Message-ID: <0c194c45-e8a2-30e9-19bd-241bc20fd89a@suse.com> Date: Tue, 2 Jun 2020 14:32:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.05.2020 23:45, Andrew Cooper wrote: > On 29/05/2020 20:35, Andrew Cooper wrote: >>>> + } >>>> + map_pages_to_xen((unsigned long)p, virt_to_mfn(p), 1, PAGE_HYPERVISOR_SHSTK); >>> As already hinted at in reply to the previous patch, I think this wants >>> to remain _PAGE_NONE when we don't use CET-SS. >> The commit message discussed why that is not an option (currently), and >> why I don't consider it a good idea to make possible. > > Apologies.  I thought I'd written it in the commit message, but it was > half in the previous patch, and not terribly clear.  I've reworked both. Thanks, I've looked at them, but it's still not really clear to me: > The current practical reason is to do with clone_mappings() in the XPTI > case. What exactly is the problem here? clone_mapping(), afaict, deals fine with non-present PTEs. The original memguard_is_stack_guard_page() check was more as a safe guard, to avoid establishing a mapping of a guard page as much as possible. > A wild off-stack read is far far less likely than hitting the guard page > with a push first, which means that a R/O guard page is about the same > usefulness to us, but results in a much more simple stack setup, as it > doesn't vary attributes with enabled features. While OoB stack reads may indeed be less likely, such aren't necessarily "wild" (assuming my understanding of the term is what you mean): A function epilogue can certainly pop (by the respective insn or by incrementing %rsp by too much) too many slots, which would be detected earlier with non-present mappings than with r/o ones. So I'd prefer to stick to non-present guard pages when CET-SS is not in use, unless there's indeed a technical reason not to do so. The two uses of PAGE_HYPERVISOR_SHSTK can't be that bad a "variation" to alternatively make _PAGE_NONE. In fact PAGE_HYPERVISOR_SHSTK could itself resolve to _PAGE_NONE when !cpu_has_xen_shstk ... Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:35:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:35:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg68T-0008T9-GE; Tue, 02 Jun 2020 12:35:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg68S-0008T4-GW for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:35:16 +0000 X-Inumbo-ID: 819c5a1a-a4cd-11ea-81bc-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 819c5a1a-a4cd-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 12:35:16 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id BEA70AA7C; Tue, 2 Jun 2020 12:35:15 +0000 (UTC) Subject: Re: [PATCH v2 06/14] x86/shstk: Create shadow stacks To: Andrew Cooper References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-7-andrew.cooper3@citrix.com> <8a02b933-3b7e-ded9-8bf3-a1c35f2ef7ae@suse.com> From: Jan Beulich Message-ID: <77701f03-9755-3d1f-101e-21b02e525231@suse.com> Date: Tue, 2 Jun 2020 14:35:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.05.2020 21:35, Andrew Cooper wrote: > On 28/05/2020 13:50, Jan Beulich wrote: >> On 27.05.2020 21:18, Andrew Cooper wrote: >>> + /* Primary Shadow Stack. 1x 4k in stack page 5. */ >>> p += PRIMARY_SHSTK_SLOT * PAGE_SIZE; >>> - map_pages_to_xen((unsigned long)p, virt_to_mfn(p), 1, _PAGE_NONE); >>> + if ( IS_ENABLED(CONFIG_XEN_SHSTK) ) >>> + write_sss_token(p + PAGE_SIZE - 8); >>> + >>> + map_pages_to_xen((unsigned long)p, virt_to_mfn(p), 1, PAGE_HYPERVISOR_SHSTK); >>> } >>> >>> void memguard_unguard_stack(void *p) >> Would this function perhaps better zap the tokens? > > Why?  We don't zap any other stack contents, and let the regular page > scrubbing clean it. Except that Xen used pages, if re-used by Xen itself, may not go through a round of scrubbing. As long as we use 1:1 mappings, re-using the same page for a shadow stack will end up having the necessary token already in place. Looks like a defense-in-depth measure to zap them off as soon as a page goes out of (shadow stack) use. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:36:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:36:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg69O-00006X-Qw; Tue, 02 Jun 2020 12:36:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg69N-00006P-Jt for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:36:13 +0000 X-Inumbo-ID: a46c1dbe-a4cd-11ea-abe9-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a46c1dbe-a4cd-11ea-abe9-12813bfff9fa; Tue, 02 Jun 2020 12:36:12 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D8C2EAA7C; Tue, 2 Jun 2020 12:36:13 +0000 (UTC) Subject: Re: [PATCH-for-4.14 1/2] xen: fix build with CONFIG_HYPFS_CONFIG enabled To: Wei Liu References: <20200602114050.5964-1-jgross@suse.com> <20200602114050.5964-2-jgross@suse.com> <20200602120726.vm3br27ygbvbs2bx@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> From: Jan Beulich Message-ID: <7b8db01f-3cd0-ac09-210f-a9cfbe2ce447@suse.com> Date: Tue, 2 Jun 2020 14:36:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200602120726.vm3br27ygbvbs2bx@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 14:07, Wei Liu wrote: > On Tue, Jun 02, 2020 at 01:55:14PM +0200, Jan Beulich wrote: >> On 02.06.2020 13:40, Juergen Gross wrote: >>> --- a/xen/common/Makefile >>> +++ b/xen/common/Makefile >>> @@ -75,7 +75,7 @@ obj-$(CONFIG_UBSAN) += ubsan/ >>> obj-$(CONFIG_NEEDS_LIBELF) += libelf/ >>> obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ >>> >>> -config.gz: ../.config >>> +config.gz: $(XEN_ROOT)/xen/$(KCONFIG_CONFIG) >> >> Looking at all pre-existing uses of KCONFIG_CONFIG this is the >> first one assuming it holds a relative path. The doc also doesn't >> indicate it can't be an absolute one. > > This is not an objection to this patch right? It is. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:40:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:40:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6Dv-00011I-CO; Tue, 02 Jun 2020 12:40:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6Dt-00011D-HY for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:40:53 +0000 X-Inumbo-ID: 4b3f562e-a4ce-11ea-9947-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4b3f562e-a4ce-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 12:40:52 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id l27so12633483ejc.1 for ; Tue, 02 Jun 2020 05:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/BNPzpCU+JYVl4JM0G4t79R1G/0WgOO94YUq/xwsvh0=; b=fPnUp5DNceOrBqVXbvFIrQlzoS9c09Xtj9tSLPsRIhW2E/5cz0qeFXna7Fh8PxxuPq Vy3/pQFMF818322BU0BwEkfSwXdJ6nBMpuh4zOpQtKimsE1fd5f2s9u9pePOFG5pZC5a xZe9Y3UjsFejnfFjRvqpyQL7ggKUgav1tFL/TK4rEVDzGDod+Wadxa/wHfwysxQQvhMc O3I4npJ/QRn3zow4xzEx9oBTgR1aw+1GpDQDeSJnY81//mizdQ5aTF6UeEtIy5WHOSk1 YT3xwuBBjOv+6b3EUYjy9ACDzMVP05gjLxr1GohYPwvaJ//KAMyIAYiNhnAPnJlGC3x8 GVUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/BNPzpCU+JYVl4JM0G4t79R1G/0WgOO94YUq/xwsvh0=; b=ih3UdfDKWiwyl5HIk+Od+yX1V3/zYe0RaaI/VBUBq/wD5sdHBNX5kSi9xPrhVOnGXJ fdcO8AkLhFF045dfRs6PDn59phiH138KbEk7JQ33hqy0eP/PDkWH8jGPzbZoXHEJvDLj vGKCMU7ItXtC0sPlkqDR+kVqdELNu2ZeV9Dw2S2wsjK3SU6AphQJ/a1SPzScRoxqX5Ob JmCry8Zhs/werO/BTPSJT/vGWRfeAow3B9+i21gsGli7XotVUYOvJQwgaB260oShJhgu FzhLHyadfAJhClpgI4YDzo9jGunBPmnA3SzCTkFqjWchy5DUzYyYl2UAWUr2SJBi1NKG 8CHQ== X-Gm-Message-State: AOAM532PDCu2cjmo84OOsdlOV67HSPUXqTQONCbC33yClAcYHgQjLxK5 88K0Kt4VZw9tG0tWtVSGFYSZJuk/k/4= X-Google-Smtp-Source: ABdhPJy38H8K/vqWFNCOXGODY9EbIbiw7NLzLx4mb2oEwk9p9m5NR9pYMS0Zg/tRSJ8wYYdQ3p6mwA== X-Received: by 2002:a17:906:af84:: with SMTP id mj4mr17496679ejb.473.1591101650611; Tue, 02 Jun 2020 05:40:50 -0700 (PDT) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com. [209.85.221.44]) by smtp.gmail.com with ESMTPSA id cx13sm1510951edb.20.2020.06.02.05.40.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 05:40:49 -0700 (PDT) Received: by mail-wr1-f44.google.com with SMTP id e1so3265481wrt.5 for ; Tue, 02 Jun 2020 05:40:49 -0700 (PDT) X-Received: by 2002:adf:e648:: with SMTP id b8mr27260840wrn.386.1591101648925; Tue, 02 Jun 2020 05:40:48 -0700 (PDT) MIME-Version: 1.0 References: <20200602110223.GW1195@Air-de-Roger> In-Reply-To: <20200602110223.GW1195@Air-de-Roger> From: Tamas K Lengyel Date: Tue, 2 Jun 2020 06:40:12 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monn=C3=A9 = wrote: > > On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: > > Extend the monitor_op domctl to include option that enables > > controlling what values certain registers are permitted to hold > > by a monitor subscriber. > > I think the change could benefit for some more detail commit message > here. Why is this useful? You would have to ask the Bitdefender folks who made the feature. I don't use it. Here we are just making it optional as it is buggy so it is disabled by default. > > There already seems to be some support for gating MSR writes, which > seems to be expanded by this commit? We don't expand on any existing features, we make an existing feature optio= nal. > > Is it solving some kind of bug reported? It does, please take a look at the cover letter. > > > Signed-off-by: Tamas K Lengyel > > --- > > xen/arch/x86/hvm/hvm.c | 25 ++++++++++++++++--------- > > xen/arch/x86/monitor.c | 10 +++++++++- > > xen/include/asm-x86/domain.h | 1 + > > xen/include/public/domctl.h | 1 + > > 4 files changed, 27 insertions(+), 10 deletions(-) > > > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > > index 09ee299bc7..e6780c685b 100644 > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -2263,7 +2263,8 @@ int hvm_set_cr0(unsigned long value, bool may_def= er) > > { > > ASSERT(v->arch.vm_event); > > > > - if ( hvm_monitor_crX(CR0, value, old_value) ) > > + if ( hvm_monitor_crX(CR0, value, old_value) && > > + v->domain->arch.monitor.control_register_values ) > > { > > /* The actual write will occur in hvm_do_resume(), if perm= itted. */ > > v->arch.vm_event->write_data.do_write.cr0 =3D 1; > > @@ -2362,7 +2363,8 @@ int hvm_set_cr3(unsigned long value, bool may_def= er) > > { > > ASSERT(v->arch.vm_event); > > > > - if ( hvm_monitor_crX(CR3, value, old) ) > > + if ( hvm_monitor_crX(CR3, value, old) && > > + v->domain->arch.monitor.control_register_values ) > > { > > /* The actual write will occur in hvm_do_resume(), if perm= itted. */ > > v->arch.vm_event->write_data.do_write.cr3 =3D 1; > > @@ -2443,7 +2445,8 @@ int hvm_set_cr4(unsigned long value, bool may_def= er) > > { > > ASSERT(v->arch.vm_event); > > > > - if ( hvm_monitor_crX(CR4, value, old_cr) ) > > + if ( hvm_monitor_crX(CR4, value, old_cr) && > > + v->domain->arch.monitor.control_register_values ) > > I think you could return control_register_values in hvm_monitor_crX > instead of having to add the check to each caller? We could, but this way the code is more consistent. > > > { > > /* The actual write will occur in hvm_do_resume(), if perm= itted. */ > > v->arch.vm_event->write_data.do_write.cr4 =3D 1; > > @@ -3587,13 +3590,17 @@ int hvm_msr_write_intercept(unsigned int msr, u= int64_t msr_content, > > > > ASSERT(v->arch.vm_event); > > > > - /* The actual write will occur in hvm_do_resume() (if permitte= d). */ > > - v->arch.vm_event->write_data.do_write.msr =3D 1; > > - v->arch.vm_event->write_data.msr =3D msr; > > - v->arch.vm_event->write_data.value =3D msr_content; > > - > > hvm_monitor_msr(msr, msr_content, msr_old_content); > > - return X86EMUL_OKAY; > > + > > + if ( v->domain->arch.monitor.control_register_values ) > > Is there any value in limiting control_register_values to MSR that > represent control registers, like EFER and XSS? I don't know, you would have to ask Bitdefender about it who made this feat= ure. > > > + { > > + /* The actual write will occur in hvm_do_resume(), if perm= itted. */ > > + v->arch.vm_event->write_data.do_write.msr =3D 1; > > + v->arch.vm_event->write_data.msr =3D msr; > > + v->arch.vm_event->write_data.value =3D msr_content; > > + > > + return X86EMUL_OKAY; > > + } > > You seem to change the previous flow of the function here, that would > just call hvm_monitor_msr and return previously. > > Don't you need to move the return from outside the added if condition > in order to keep previous behavior? Or else the write is committed > straight away. That's exactly what we want to achieve. Postponing the write is buggy. We want to make that feature optional. Before Bitdefender contributed that feature writes were always commited straight away, so with this patch we are actually reverting default behavior to what it was like to start with. > > > } > > > > if ( (ret =3D guest_wrmsr(v, msr, msr_content)) !=3D X86EMUL_UNHAN= DLEABLE ) > > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > > index bbcb7536c7..1517a97f50 100644 > > --- a/xen/arch/x86/monitor.c > > +++ b/xen/arch/x86/monitor.c > > @@ -144,7 +144,15 @@ int arch_monitor_domctl_event(struct domain *d, > > struct xen_domctl_monitor_op *mop) > > { > > struct arch_domain *ad =3D &d->arch; > > - bool requested_status =3D (XEN_DOMCTL_MONITOR_OP_ENABLE =3D=3D mop= ->op); > > + bool requested_status; > > + > > + if ( XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS =3D=3D mop->op ) > > + { > > + ad->monitor.control_register_values =3D true; > > I think strictly speaking you need to use 1 here, since this variable > is not a boolean. Sure. Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:41:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:41:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6EY-00014T-Ll; Tue, 02 Jun 2020 12:41:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6EY-00014M-2Q for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:41:34 +0000 X-Inumbo-ID: 6369f3bc-a4ce-11ea-abea-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6369f3bc-a4ce-11ea-abea-12813bfff9fa; Tue, 02 Jun 2020 12:41:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7614EAA7C; Tue, 2 Jun 2020 12:41:34 +0000 (UTC) Subject: Re: [PATCH v2 03/14] x86/shstk: Introduce Supervisor Shadow Stack support To: Anthony PERARD References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-4-andrew.cooper3@citrix.com> <4f535d4c-b3b3-fe5b-8b57-af736dc0a360@suse.com> <20200602122614.GN2105@perard.uk.xensource.com> From: Jan Beulich Message-ID: <3328fabd-c133-00a9-2ec0-addcf15dbff5@suse.com> Date: Tue, 2 Jun 2020 14:41:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200602122614.GN2105@perard.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 14:26, Anthony PERARD wrote: > On Tue, Jun 02, 2020 at 02:06:11PM +0200, Jan Beulich wrote: >> I don't recall; perhaps I was in another parallel session? If it's >> the one with notes at >> https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00786.html >> then a remark close to the top suggests I was there, but there's no >> sign of this aspect having got discussed. There is, among the issues >> listed, "Xen build re-evaluates compiler support for every translation >> unit", but that's only remotely related. > > What is a "translation unit"? What would that have to do with Kconfig? A translation unit is the collective input from all source and header files seen by the compiler during the processing of one top level input file's worth of compilation. The connection to Kconfig here is that by switching to it, the compiler flags don't get re-constructed once per CU. Of course doing it via Kconfig is not the only possible solution to the problem (as can be seen from the patch that I had intermediately submitted to get at least the HAVE_AS_* out of that set), but for us the change in behavior is one intended (side-)effect of the switch to newer Kconfig. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:44:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:44:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6H9-0001GG-3Q; Tue, 02 Jun 2020 12:44:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6H7-0001GB-NA for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:44:13 +0000 X-Inumbo-ID: c29bffec-a4ce-11ea-81bc-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c29bffec-a4ce-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 12:44:12 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id o15so12568477ejm.12 for ; Tue, 02 Jun 2020 05:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KzNwH7AZbuX1qGWWD4DT1VKxH2TD04CejRr/he0oH7s=; b=YkSlxQGMj3cUwQf3aJMUzrhVQwpGAN1TT3slWdgzZMRfr1yb3I5349YL3WoypnFFxT q5KRu4z0W1MBs3qFHHMIdXyfMZdO9npQx80dDmac13Z5kwBS6XPdKmdtftTKU1Y6I1zx zeHw+hbJgB4ntU0w6yr4xsIEejXxVZ3OhtT+ZcVXUwpEZzD1qlY+CJfmxHTWCHdNR29K l4g4FtJyahB0OBE78GZH+lg0PWNXu9ZwglfGB6J7xDNSnbHKtm1yzDwKVFa96CuBeBVi UhDl+3puZWoDnjO97G6V9sDM7m4/I085fEp/OHtLoMvVWlQ1OBTDrwM5oEaLLDQuyKdq 7jJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KzNwH7AZbuX1qGWWD4DT1VKxH2TD04CejRr/he0oH7s=; b=cM7gKmaCy8rEb7PVO/lkXaYwGjzfvEe02BGbLL6W1RTeUly9+zhEU9GP6/VZpAspzf HC+To2BubdStPZL0+AfHraahLzkHM04OGqFJXwcpILYk78BpJVeEFOS8gx4KdoMIUmTF eya8mkyhU1QLNpyofiB5ldkepWf+L9UGEMh0eYZZJGfnsnGuyoYyIXcIMGPJaM16bmXy SHyhblzMGRFRjxLuM/p2Fvz+Yv8nJkPBg3v7VtFD5f/bLsBpaddv7wtzp4fMNavcbinZ YDMw/4AhoH/kkavGSMzPCtGJ651v/XWD1AiRr13L+DJq+iAzxdX8n9cCG9WAnzfRS2WI vd+g== X-Gm-Message-State: AOAM5327apjFHHgIzy7P77Dm0jV/t7y44ux5mMQG33ZtN+S6X2CJXsa6 DjTg0DCEpjoUaEYP3+ZVcYl2jLol6EM= X-Google-Smtp-Source: ABdhPJxiZIkrYCtqh+pxOjN2N9+VT+HrohbGn2229AXN0Li5CLYe9p16qyZAW49p9f2K/pxZ3j+ltg== X-Received: by 2002:a17:906:e0c5:: with SMTP id gl5mr22866347ejb.524.1591101851720; Tue, 02 Jun 2020 05:44:11 -0700 (PDT) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com. [209.85.128.45]) by smtp.gmail.com with ESMTPSA id gj10sm1586904ejb.61.2020.06.02.05.44.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 05:44:11 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id r15so2966926wmh.5 for ; Tue, 02 Jun 2020 05:44:11 -0700 (PDT) X-Received: by 2002:a1c:acc8:: with SMTP id v191mr4213661wme.154.1591101850829; Tue, 02 Jun 2020 05:44:10 -0700 (PDT) MIME-Version: 1.0 References: <52492e7b44f311b09e9a433f2e5a2ba607a85c78.1590028160.git.tamas@tklengyel.com> <20200602114722.GX1195@Air-de-Roger> In-Reply-To: <20200602114722.GX1195@Air-de-Roger> From: Tamas K Lengyel Date: Tue, 2 Jun 2020 06:43:34 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 for-4.14 2/3] xen/vm_event: add vm_event_check_pending_op To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Jan Beulich , Alexandru Isaila , Xen-devel , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 2, 2020 at 5:47 AM Roger Pau Monn=C3=A9 = wrote: > > On Wed, May 20, 2020 at 08:31:53PM -0600, Tamas K Lengyel wrote: > > Perform sanity checking when shutting vm_event down to determine whethe= r > > it is safe to do so. Error out with -EAGAIN in case pending operations > > have been found for the domain. > > > > Signed-off-by: Tamas K Lengyel > > --- > > xen/arch/x86/vm_event.c | 23 +++++++++++++++++++++++ > > xen/common/vm_event.c | 17 ++++++++++++++--- > > xen/include/asm-arm/vm_event.h | 7 +++++++ > > xen/include/asm-x86/vm_event.h | 2 ++ > > 4 files changed, 46 insertions(+), 3 deletions(-) > > > > diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c > > index 848d69c1b0..a23aadc112 100644 > > --- a/xen/arch/x86/vm_event.c > > +++ b/xen/arch/x86/vm_event.c > > @@ -297,6 +297,29 @@ void vm_event_emulate_check(struct vcpu *v, vm_eve= nt_response_t *rsp) > > }; > > } > > > > +bool vm_event_check_pending_op(const struct vcpu *v) > > +{ > > + struct monitor_write_data *w =3D &v->arch.vm_event->write_data; > > const > > > + > > + if ( !v->arch.vm_event->sync_event ) > > + return false; > > + > > + if ( w->do_write.cr0 ) > > + return true; > > + if ( w->do_write.cr3 ) > > + return true; > > + if ( w->do_write.cr4 ) > > + return true; > > + if ( w->do_write.msr ) > > + return true; > > + if ( v->arch.vm_event->set_gprs ) > > + return true; > > + if ( v->arch.vm_event->emulate_flags ) > > + return true; > > Can you please group this into a single if, ie: > > if ( w->do_write.cr0 || w->do_write.cr3 || ... ) > return true; > > > + > > + return false; > > +} > > + > > /* > > * Local variables: > > * mode: C > > diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c > > index 127f2d58f1..2df327a42c 100644 > > --- a/xen/common/vm_event.c > > +++ b/xen/common/vm_event.c > > @@ -183,6 +183,7 @@ static int vm_event_disable(struct domain *d, struc= t vm_event_domain **p_ved) > > if ( vm_event_check_ring(ved) ) > > { > > struct vcpu *v; > > + bool pending_op =3D false; > > > > spin_lock(&ved->lock); > > > > @@ -192,9 +193,6 @@ static int vm_event_disable(struct domain *d, struc= t vm_event_domain **p_ved) > > return -EBUSY; > > } > > > > - /* Free domU's event channel and leave the other one unbound *= / > > - free_xen_event_channel(d, ved->xen_port); > > - > > /* Unblock all vCPUs */ > > for_each_vcpu ( d, v ) > > { > > @@ -203,8 +201,21 @@ static int vm_event_disable(struct domain *d, stru= ct vm_event_domain **p_ved) > > vcpu_unpause(v); > > ved->blocked--; > > } > > + > > + if ( vm_event_check_pending_op(v) ) > > + pending_op =3D true; > > You could just do: > > pending_op |=3D vm_event_check_pending_op(v); > > and avoid the initialization of pending_op above. Or alternatively: > > if ( !pending_op && vm_event_check_pending_op(v) ) > pending_op =3D true; > > Which avoid repeated calls to vm_event_check_pending_op when at least > one vCPU is known to be busy. > > > } > > > > + /* vm_event ops are still pending until vCPUs get scheduled */ > > + if ( pending_op ) > > + { > > + spin_unlock(&ved->lock); > > + return -EAGAIN; > > What happens when this gets called from vm_event_cleanup? > > AFAICT the result there is ignored, and could leak the vm_event > allocated memory? Thanks for the feedback. I'm going to drop this patch at let Bitdefender pick it up if they feel like fixing their buggy feature. As things stand for my use-case I only need patch 1 from this series. Tamas From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:47:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:47:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6Kf-0001OM-L5; Tue, 02 Jun 2020 12:47:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6Ke-0001OH-0s for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:47:52 +0000 X-Inumbo-ID: 44d5b408-a4cf-11ea-abea-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 44d5b408-a4cf-11ea-abea-12813bfff9fa; Tue, 02 Jun 2020 12:47:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 52389ACF1; Tue, 2 Jun 2020 12:47:52 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values To: Tamas K Lengyel References: <20200602110223.GW1195@Air-de-Roger> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 14:47:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 14:40, Tamas K Lengyel wrote: > On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monné wrote: >> >> On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: >>> Extend the monitor_op domctl to include option that enables >>> controlling what values certain registers are permitted to hold >>> by a monitor subscriber. >> >> I think the change could benefit for some more detail commit message >> here. Why is this useful? > > You would have to ask the Bitdefender folks who made the feature. I > don't use it. Here we are just making it optional as it is buggy so it > is disabled by default. Now that's exactly the opposite of what I had derived from the description here so far. Perhaps an at least weak indication that you want to reword this. For example, from your reply to Roger I understand it's rather that the new flag allows to "suppress" the controlling (since presumably you don't change default behavior), rather then "enabling" it. >> There already seems to be some support for gating MSR writes, which >> seems to be expanded by this commit? > > We don't expand on any existing features, we make an existing feature optional. > >> >> Is it solving some kind of bug reported? > > It does, please take a look at the cover letter. Please can such important aspects also go in the commit message, so they're available later without needing to hunt down mail threads (besides this way being more readily available to reviewers)? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:52:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:52:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6PF-0002G9-Bt; Tue, 02 Jun 2020 12:52:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6PE-0002G4-2a for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:52:36 +0000 X-Inumbo-ID: ee1bb83c-a4cf-11ea-81bc-bc764e2007e4 Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ee1bb83c-a4cf-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 12:52:35 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id g9so9959276edw.10 for ; Tue, 02 Jun 2020 05:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SC2aYUuLkEh9YWcBjGQ8OFPka9a6woGYTDWf4xa8Aos=; b=NDKDMWTzXVb+QLnEiV03jjuFO19cpEZjFHMvpoJoWQ5lb1vAUJrQ9KrBEQ3fF6j0EM 68rBAfP4WWHnye3+dSXf2iVuNikXqrttD2HWFJuLSBHAkREcoaLR148hHdaNAF8M6qpI 5fcuiPUMHH7RRWPYcmWgwyqV4+K4UFPwpUlP1IElgIdje9YcDsL+5jw1jQfthxIl4yzO RJtqmn28FlD3cgE9UiX2fIMH/dYNZo2pbOJBpermjznuFF5v3GFUEpXdLd6KL9HfXK0f 3XK4Ky3lMdc40YTjKiRnlmQDVBebtN+uhEhEzYSkZES7iQW574qECfPcGGwZRWThmxbr mgKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SC2aYUuLkEh9YWcBjGQ8OFPka9a6woGYTDWf4xa8Aos=; b=NH++/TXZcPN99cx4HJiF6zOOMBVeIHrlz7t3l24/cUCBtxfZqVOvyhEPXnPVMc6sip ND+Ie/4eU3B6LSJc/eE01Xecx+oRcdBRR4lnyFkduhUD3da8g6K71aTxKuM6bBV7wWOW EHxaj4XOO+6VdIRtf40yXJ2NkROrIxMm8EaA7OertwfT3wk+Du0RXyvFCx1K0a9iekq/ bFuDgI8mWCVchwSWt/hAR7syoYqTxUIdXO1nRXyPg5u7lc9JXfaBPMrJEhf9JGhWzvbw yUFNxOB6HRSrYpinqoHzP8rEF/gLbBT4yJtYOqTuyyQhW+TY6Imj/hK7/dgnwoAjTkWe SOuQ== X-Gm-Message-State: AOAM530QuQpULcu/z8nJ9TAljnjEHBV88nwo+eX+XINwCXyow0lRlXhR 9PhzrZvLj1n3iBluHSEkFpJE/RbWBps= X-Google-Smtp-Source: ABdhPJxPOEs0bMsATGINlVeTV4UxcXrqAwa0MbZkd9C9KoK0ZhE558y56dYsOsjBhaBTdECo4FrKgA== X-Received: by 2002:a50:9b13:: with SMTP id o19mr21068354edi.143.1591102354147; Tue, 02 Jun 2020 05:52:34 -0700 (PDT) Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com. [209.85.221.42]) by smtp.gmail.com with ESMTPSA id d6sm1549054edn.75.2020.06.02.05.52.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 05:52:33 -0700 (PDT) Received: by mail-wr1-f42.google.com with SMTP id q11so3313679wrp.3 for ; Tue, 02 Jun 2020 05:52:33 -0700 (PDT) X-Received: by 2002:a5d:490f:: with SMTP id x15mr26040237wrq.259.1591102353002; Tue, 02 Jun 2020 05:52:33 -0700 (PDT) MIME-Version: 1.0 References: <20200602110223.GW1195@Air-de-Roger> In-Reply-To: From: Tamas K Lengyel Date: Tue, 2 Jun 2020 06:51:56 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values To: Jan Beulich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 2, 2020 at 6:47 AM Jan Beulich wrote: > > On 02.06.2020 14:40, Tamas K Lengyel wrote: > > On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monn=C3=A9 wrote: > >> > >> On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: > >>> Extend the monitor_op domctl to include option that enables > >>> controlling what values certain registers are permitted to hold > >>> by a monitor subscriber. > >> > >> I think the change could benefit for some more detail commit message > >> here. Why is this useful? > > > > You would have to ask the Bitdefender folks who made the feature. I > > don't use it. Here we are just making it optional as it is buggy so it > > is disabled by default. > > Now that's exactly the opposite of what I had derived from the > description here so far. Perhaps an at least weak indication > that you want to reword this. For example, from your reply to > Roger I understand it's rather that the new flag allows to > "suppress" the controlling (since presumably you don't change > default behavior), rather then "enabling" it. What we are adding is a domctl you need to call that enables this feature. It's not an option to suppress it. It shouldn't have been enabled by default to begin with. That was a mistake when the feature was contributed and it is buggy. > > >> There already seems to be some support for gating MSR writes, which > >> seems to be expanded by this commit? > > > > We don't expand on any existing features, we make an existing feature o= ptional. > > > >> > >> Is it solving some kind of bug reported? > > > > It does, please take a look at the cover letter. > > Please can such important aspects also go in the commit message, > so they're available later without needing to hunt down mail > threads (besides this way being more readily available to > reviewers)? Noted. Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:54:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:54:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6RG-0002OU-Oo; Tue, 02 Jun 2020 12:54:42 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6RF-0002OP-Mq for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:54:41 +0000 X-Inumbo-ID: 38e77536-a4d0-11ea-abea-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 38e77536-a4d0-11ea-abea-12813bfff9fa; Tue, 02 Jun 2020 12:54:40 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: KKi2eqdfOPWnuZddKE7EZJ0z/Ujn0YJYCM0WfQqZCRSph7z8MTWW2w1+vyM76hpO4jtTTAFPcB m/h+UQkCFGhX4Kf7gyTkDDrOq8mYhBUXldS0BHytmc6/+5NbvHqlNqVXSao7T26UEQsKTP9mzg SNIrYOe7CrN7GLpwuvftFfBcGyD8sb6HNPrQ7yyThFdxpnzEoeM2y5hIHZciQ5BjZSVHiwkJr4 tbO6JWVJi53HRDVircbrkcMgjJTbriVbiW64Q1m9LT5MiSFBJoIsr2m+6YSEVVdUea/b2oODnM PeM= X-SBRS: 2.7 X-MesageID: 19364950 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,464,1583211600"; d="scan'208";a="19364950" Date: Tue, 2 Jun 2020 14:54:33 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH v2 for-4.14 3/3] xen/vm_event: Add safe to disable vm_event Message-ID: <20200602125433.GY1195@Air-de-Roger> References: <682dde916f982e2889b2be2263418e9506a82c1e.1590028160.git.tamas@tklengyel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <682dde916f982e2889b2be2263418e9506a82c1e.1590028160.git.tamas@tklengyel.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, May 20, 2020 at 08:31:54PM -0600, Tamas K Lengyel wrote: > Instead of having to repeatedly try to disable vm_events, Why not use a hypercall continuation instead so that this is all hidden from the caller? I take that the current interface requires the user to repeatedly issue hypercalls in order to disable vm_events until one of those succeeds? > request a specific > vm_event to be sent when the domain is safe to continue with shutting down > the vm_event interface. > > Signed-off-by: Tamas K Lengyel > --- > xen/arch/x86/hvm/hvm.c | 38 ++++++++++++++++++++++++++----- > xen/arch/x86/hvm/monitor.c | 14 ++++++++++++ > xen/arch/x86/monitor.c | 13 +++++++++++ > xen/include/asm-x86/domain.h | 1 + > xen/include/asm-x86/hvm/monitor.h | 1 + > xen/include/public/domctl.h | 2 ++ > xen/include/public/vm_event.h | 8 +++++++ > 7 files changed, 71 insertions(+), 6 deletions(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index e6780c685b..fc7e1e2b22 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -563,15 +563,41 @@ void hvm_do_resume(struct vcpu *v) > v->arch.hvm.inject_event.vector = HVM_EVENT_VECTOR_UNSET; > } > > - if ( unlikely(v->arch.vm_event) && v->arch.monitor.next_interrupt_enabled ) > + if ( unlikely(v->arch.vm_event) ) > { > - struct x86_event info; > + struct domain *d = v->domain; > + > + if ( v->arch.monitor.next_interrupt_enabled ) > + { > + struct x86_event info; > + > + if ( hvm_get_pending_event(v, &info) ) > + { > + hvm_monitor_interrupt(info.vector, info.type, info.error_code, > + info.cr2); > + v->arch.monitor.next_interrupt_enabled = false; > + } > + } > > - if ( hvm_get_pending_event(v, &info) ) > + if ( d->arch.monitor.safe_to_disable ) > { > - hvm_monitor_interrupt(info.vector, info.type, info.error_code, > - info.cr2); > - v->arch.monitor.next_interrupt_enabled = false; > + const struct vcpu *check_vcpu; > + bool pending_op = false; > + > + for_each_vcpu ( d, check_vcpu ) > + { > + if ( vm_event_check_pending_op(check_vcpu) ) Don't you need some kind of lock here, since you are poking at another vCPU which could be modifying any of those bits? > + { > + pending_op = true; > + break; > + } > + } > + > + if ( !pending_op ) > + { > + hvm_monitor_safe_to_disable(); > + d->arch.monitor.safe_to_disable = false; > + } > } > } > } > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c > index f5d89e71d1..75fd1a4b68 100644 > --- a/xen/arch/x86/hvm/monitor.c > +++ b/xen/arch/x86/hvm/monitor.c > @@ -300,6 +300,20 @@ bool hvm_monitor_check_p2m(unsigned long gla, gfn_t gfn, uint32_t pfec, > return monitor_traps(curr, true, &req) >= 0; > } > > +void hvm_monitor_safe_to_disable(void) > +{ > + struct vcpu *curr = current; > + struct arch_domain *ad = &curr->domain->arch; const > + vm_event_request_t req = {}; > + > + if ( !ad->monitor.safe_to_disable ) > + return; Should this rather be an ASSERT? I don't think you are supposed to call hvm_monitor_safe_to_disable when the bit is not set? > + > + req.reason = VM_EVENT_REASON_SAFE_TO_DISABLE; I think you cat set the field at definition time. > + > + monitor_traps(curr, 0, &req); > +} > + > /* > * Local variables: > * mode: C > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > index 1517a97f50..86e0ba2fbc 100644 > --- a/xen/arch/x86/monitor.c > +++ b/xen/arch/x86/monitor.c > @@ -339,6 +339,19 @@ int arch_monitor_domctl_event(struct domain *d, > break; > } > > + case XEN_DOMCTL_MONITOR_EVENT_SAFE_TO_DISABLE: > + { > + bool old_status = ad->monitor.safe_to_disable; > + > + if ( unlikely(old_status == requested_status) ) > + return -EEXIST; > + > + domain_pause(d); > + ad->monitor.safe_to_disable = requested_status; Maybe I'm missing something, but I don't see any check that others events are disabled before safe_to_disable is set? In the same way, you should prevent setting any events when safe_to_disable is set IMO, likely returning -EBUSY in both cases. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:58:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:58:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6UH-0002Vz-7d; Tue, 02 Jun 2020 12:57:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6UG-0002Vu-AU for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:57:48 +0000 X-Inumbo-ID: a81d0a42-a4d0-11ea-abee-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a81d0a42-a4d0-11ea-abee-12813bfff9fa; Tue, 02 Jun 2020 12:57:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id ABAA7ABD1; Tue, 2 Jun 2020 12:57:48 +0000 (UTC) Subject: Re: [PATCH v2 10/14] x86/extable: Adjust extable handling to be shadow stack compatible To: Andrew Cooper References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-11-andrew.cooper3@citrix.com> <0c7f425a-996f-8840-f1e2-79381edb6456@citrix.com> From: Jan Beulich Message-ID: <79074c8d-adf0-7df5-e13b-bfa6551112e5@suse.com> Date: Tue, 2 Jun 2020 14:57:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <0c7f425a-996f-8840-f1e2-79381edb6456@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.05.2020 21:43, Andrew Cooper wrote: > On 28/05/2020 17:15, Jan Beulich wrote: >> On 27.05.2020 21:18, Andrew Cooper wrote: >>> @@ -763,6 +775,56 @@ static void do_reserved_trap(struct cpu_user_regs *regs) >>> trapnr, vec_name(trapnr), regs->error_code); >>> } >>> >>> +static void extable_shstk_fixup(struct cpu_user_regs *regs, unsigned long fixup) >>> +{ >>> + unsigned long ssp, *ptr, *base; >>> + >>> + asm ( "rdsspq %0" : "=r" (ssp) : "0" (1) ); >>> + if ( ssp == 1 ) >>> + return; >>> + >>> + ptr = _p(ssp); >>> + base = _p(get_shstk_bottom(ssp)); >>> + >>> + for ( ; ptr < base; ++ptr ) >>> + { >>> + /* >>> + * Search for %rip. The shstk currently looks like this: >>> + * >>> + * ... [Likely pointed to by SSP] >>> + * %cs [== regs->cs] >>> + * %rip [== regs->rip] >>> + * SSP [Likely points to 3 slots higher, above %cs] >>> + * ... [call tree to this function, likely 2/3 slots] >>> + * >>> + * and we want to overwrite %rip with fixup. There are two >>> + * complications: >>> + * 1) We cant depend on SSP values, because they won't differ by 3 >>> + * slots if the exception is taken on an IST stack. >>> + * 2) There are synthetic (unrealistic but not impossible) scenarios >>> + * where %rip can end up in the call tree to this function, so we >>> + * can't check against regs->rip alone. >>> + * >>> + * Check for both reg->rip and regs->cs matching. >>> + */ >>> + >>> + if ( ptr[0] == regs->rip && ptr[1] == regs->cs ) >>> + { >>> + asm ( "wrssq %[fix], %[stk]" >>> + : [stk] "=m" (*ptr) >> Could this be ptr[0], to match the if()? >> >> Considering how important it is that we don't fix up the wrong stack >> location here, I continue to wonder if we wouldn't better also >> include the SSP value on the stack in the checking, at the very >> least by way of an ASSERT() or BUG_ON(). > > Well no, for the reason discussed in point 1. I don't see my suggestion in conflict with that point. I didn't suggest an check using == ; instead what I'm thinking about here is something as weak as "Does this point somewhere into the stack range for this CPU?" After all there are only a limited set of classes of entries that can be on a shadow stack: - LIP (Xen .text, livepatching area) - CS (<= 0xffff) - SSP (within stack range for the CPU) - supervisor token (a single precise address) - padding (zero) The number ranges covered by these classes are entirely disjoint, so qualifying all three slots accordingly can be done without any risk of getting an entry wrong. > Its not technically an issue right now, but there is no possible way to > BUILD_BUG_ON() someone turning an exception into IST, or stopping the > use of the extable infrastructure on a #DB. > > Such a check would lie in wait and either provide an unexpected tangent > to someone debugging a complicated issue (I do use #DB for a fair bit), > or become a security vulnerability. > >> Since, with how the code is >> currently written, this would require a somewhat odd looking ptr[-1] >> I also wonder whether "while ( ++ptr < base )" as the loop header >> wouldn't be better. The first entry on the stack can't be the RIP >> we look for anyway, can it? > > Yes it can. How, when there's the return address of this function plus an SSP value preceding it? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:59:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:59:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6VW-0002dO-Qq; Tue, 02 Jun 2020 12:59:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6VV-0002d6-J1 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:59:05 +0000 X-Inumbo-ID: d6265100-a4d0-11ea-abee-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d6265100-a4d0-11ea-abee-12813bfff9fa; Tue, 02 Jun 2020 12:59:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A592AAF69; Tue, 2 Jun 2020 12:59:05 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 v2 1/2] xen: fix build with CONFIG_HYPFS_CONFIG enabled Date: Tue, 2 Jun 2020 14:58:59 +0200 Message-Id: <20200602125900.4424-2-jgross@suse.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200602125900.4424-1-jgross@suse.com> References: <20200602125900.4424-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Commit 58263ed7713e ("xen: add /buildinfo/config entry to hypervisor filesystem") added a dependency to .config, but the hypervisor's build config could be have another name via setting KCONFIG_CONFIG. Fix that by using $(KCONFIG_CONFIG) instead. Additionally reference the config file via $(XEN_ROOT) instead of a relative path. Reported-by: Andrew Cooper Signed-off-by: Juergen Gross --- V2: - accept an absolute path in KCONFIG_CONFIG (Jan Beulich) --- xen/common/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/common/Makefile b/xen/common/Makefile index 91581e1815..fc2c8eb4a3 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -75,7 +75,8 @@ obj-$(CONFIG_UBSAN) += ubsan/ obj-$(CONFIG_NEEDS_LIBELF) += libelf/ obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ -config.gz: ../.config +CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(XEN_ROOT)/xen/$(KCONFIG_CONFIG),$(KCONFIG_CONFIG)) +config.gz: $(CONF_FILE) gzip -c $< >$@ config_data.o: config.gz -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:59:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:59:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6VW-0002dG-IX; Tue, 02 Jun 2020 12:59:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6VU-0002cz-Un for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:59:04 +0000 X-Inumbo-ID: d615a4f4-a4d0-11ea-9dbe-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d615a4f4-a4d0-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 12:59:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 73E82AF5D; Tue, 2 Jun 2020 12:59:05 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 v2 0/2] xen: build fixes for CONFIG_HYPFS Date: Tue, 2 Jun 2020 14:58:58 +0200 Message-Id: <20200602125900.4424-1-jgross@suse.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Fixing an issue Andrew met, and disabling CONFIG_HYPFS in pv-shim. Juergen Gross (2): xen: fix build with CONFIG_HYPFS_CONFIG enabled xen/config: disable hypervisor filesystem for pv-shim xen/arch/x86/configs/pvshim_defconfig | 1 + xen/common/Makefile | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 12:59:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 12:59:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6Vb-0002eQ-2n; Tue, 02 Jun 2020 12:59:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6VZ-0002e9-Tc for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 12:59:09 +0000 X-Inumbo-ID: d62fb358-a4d0-11ea-9947-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d62fb358-a4d0-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 12:59:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DD6A3AF72; Tue, 2 Jun 2020 12:59:05 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 v2 2/2] xen/config: disable hypervisor filesystem for pv-shim Date: Tue, 2 Jun 2020 14:59:00 +0200 Message-Id: <20200602125900.4424-3-jgross@suse.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200602125900.4424-1-jgross@suse.com> References: <20200602125900.4424-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , paul@xen.org, Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The pv-shim doesn't need the hypervisor filesystem, so disable it. Signed-off-by: Juergen Gross Acked-by: Jan Beulich --- xen/arch/x86/configs/pvshim_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig index 9710aa6238..830660e022 100644 --- a/xen/arch/x86/configs/pvshim_defconfig +++ b/xen/arch/x86/configs/pvshim_defconfig @@ -6,6 +6,7 @@ CONFIG_PV_SHIM=y CONFIG_PV_SHIM_EXCLUSIVE=y CONFIG_NR_CPUS=32 # Disable features not used by the PV shim +# CONFIG_HYPFS is not set # CONFIG_SHADOW_PAGING is not set # CONFIG_BIGMEM is not set # CONFIG_HVM_FEP is not set -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:00:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:00:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6Wu-0003YX-FA; Tue, 02 Jun 2020 13:00:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6Wt-0003YS-Nc for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:00:31 +0000 X-Inumbo-ID: 09aed8b2-a4d1-11ea-9947-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 09aed8b2-a4d1-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 13:00:31 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2F617AA7C; Tue, 2 Jun 2020 13:00:32 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values To: Tamas K Lengyel References: <20200602110223.GW1195@Air-de-Roger> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 15:00:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 14:51, Tamas K Lengyel wrote: > On Tue, Jun 2, 2020 at 6:47 AM Jan Beulich wrote: >> >> On 02.06.2020 14:40, Tamas K Lengyel wrote: >>> On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monné wrote: >>>> >>>> On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: >>>>> Extend the monitor_op domctl to include option that enables >>>>> controlling what values certain registers are permitted to hold >>>>> by a monitor subscriber. >>>> >>>> I think the change could benefit for some more detail commit message >>>> here. Why is this useful? >>> >>> You would have to ask the Bitdefender folks who made the feature. I >>> don't use it. Here we are just making it optional as it is buggy so it >>> is disabled by default. >> >> Now that's exactly the opposite of what I had derived from the >> description here so far. Perhaps an at least weak indication >> that you want to reword this. For example, from your reply to >> Roger I understand it's rather that the new flag allows to >> "suppress" the controlling (since presumably you don't change >> default behavior), rather then "enabling" it. > > What we are adding is a domctl you need to call that enables this > feature. It's not an option to suppress it. It shouldn't have been > enabled by default to begin with. That was a mistake when the feature > was contributed and it is buggy. Okay, in this case it's important to point out that you alter default behavior. The BitDefender folks may not like this, yet they've been surprisingly silent so far. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:01:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:01:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6Xj-0003i6-Sr; Tue, 02 Jun 2020 13:01:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6Xi-0003hx-S6 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:01:22 +0000 X-Inumbo-ID: 27c3bab6-a4d1-11ea-8993-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 27c3bab6-a4d1-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 13:01:21 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 0KWG/YLmAy5MK5j0B40MXUnpVfifbGGzRFCRgV3cUb1QE1+23EPD6DaD/pWvqMAr1UOjwM4vpw fpAoIj+xRU5S3QI122LQ5c2swcN2GfiwysXXDLFB8ubg20VZ7cTFntvJxFvG3z5gUElhrqq1Ay TRJzZW/ZGG1FH+EUkPdC6YoEJU66FktR6mdiA89TUV+IyOQpc9lXus31QVcPNJ5Nj1WUUro4mn ukpWgylOYN+8eFPfz6LcF/wQkkFr7dl9lIrinUgfMnVkPpMBR1/7sccDZMwDxfx6d4nexCAVo4 0Yw= X-SBRS: 2.7 X-MesageID: 19760336 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,464,1583211600"; d="scan'208";a="19760336" Date: Tue, 2 Jun 2020 15:01:14 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values Message-ID: <20200602130114.GZ1195@Air-de-Roger> References: <20200602110223.GW1195@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 06:40:12AM -0600, Tamas K Lengyel wrote: > On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monné wrote: > > > > On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: > > > Extend the monitor_op domctl to include option that enables > > > controlling what values certain registers are permitted to hold > > > by a monitor subscriber. > > > > I think the change could benefit for some more detail commit message > > here. Why is this useful? > > You would have to ask the Bitdefender folks who made the feature. I > don't use it. Here we are just making it optional as it is buggy so it > is disabled by default. > > > > > There already seems to be some support for gating MSR writes, which > > seems to be expanded by this commit? > > We don't expand on any existing features, we make an existing feature optional. > > > > > Is it solving some kind of bug reported? > > It does, please take a look at the cover letter. Please copy the relevant bits here for reference. > > > > > Signed-off-by: Tamas K Lengyel > > > --- > > > xen/arch/x86/hvm/hvm.c | 25 ++++++++++++++++--------- > > > xen/arch/x86/monitor.c | 10 +++++++++- > > > xen/include/asm-x86/domain.h | 1 + > > > xen/include/public/domctl.h | 1 + > > > 4 files changed, 27 insertions(+), 10 deletions(-) > > > > > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > > > index 09ee299bc7..e6780c685b 100644 > > > --- a/xen/arch/x86/hvm/hvm.c > > > +++ b/xen/arch/x86/hvm/hvm.c > > > @@ -2263,7 +2263,8 @@ int hvm_set_cr0(unsigned long value, bool may_defer) > > > { > > > ASSERT(v->arch.vm_event); > > > > > > - if ( hvm_monitor_crX(CR0, value, old_value) ) > > > + if ( hvm_monitor_crX(CR0, value, old_value) && > > > + v->domain->arch.monitor.control_register_values ) > > > { > > > /* The actual write will occur in hvm_do_resume(), if permitted. */ > > > v->arch.vm_event->write_data.do_write.cr0 = 1; > > > @@ -2362,7 +2363,8 @@ int hvm_set_cr3(unsigned long value, bool may_defer) > > > { > > > ASSERT(v->arch.vm_event); > > > > > > - if ( hvm_monitor_crX(CR3, value, old) ) > > > + if ( hvm_monitor_crX(CR3, value, old) && > > > + v->domain->arch.monitor.control_register_values ) > > > { > > > /* The actual write will occur in hvm_do_resume(), if permitted. */ > > > v->arch.vm_event->write_data.do_write.cr3 = 1; > > > @@ -2443,7 +2445,8 @@ int hvm_set_cr4(unsigned long value, bool may_defer) > > > { > > > ASSERT(v->arch.vm_event); > > > > > > - if ( hvm_monitor_crX(CR4, value, old_cr) ) > > > + if ( hvm_monitor_crX(CR4, value, old_cr) && > > > + v->domain->arch.monitor.control_register_values ) > > > > I think you could return control_register_values in hvm_monitor_crX > > instead of having to add the check to each caller? > > We could, but this way the code is more consistent. OK, I guess it's a matter of taste. I would rather prefer those checks to be confined to hvm_monitor_crX because then the generic code is not polluted with monitor checks, but that's likely just my taste. > > > > > { > > > /* The actual write will occur in hvm_do_resume(), if permitted. */ > > > v->arch.vm_event->write_data.do_write.cr4 = 1; > > > @@ -3587,13 +3590,17 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content, > > > > > > ASSERT(v->arch.vm_event); > > > > > > - /* The actual write will occur in hvm_do_resume() (if permitted). */ > > > - v->arch.vm_event->write_data.do_write.msr = 1; > > > - v->arch.vm_event->write_data.msr = msr; > > > - v->arch.vm_event->write_data.value = msr_content; > > > - > > > hvm_monitor_msr(msr, msr_content, msr_old_content); > > > - return X86EMUL_OKAY; > > > + > > > + if ( v->domain->arch.monitor.control_register_values ) > > > > Is there any value in limiting control_register_values to MSR that > > represent control registers, like EFER and XSS? > > I don't know, you would have to ask Bitdefender about it who made this feature. > > > > > > + { > > > + /* The actual write will occur in hvm_do_resume(), if permitted. */ > > > + v->arch.vm_event->write_data.do_write.msr = 1; > > > + v->arch.vm_event->write_data.msr = msr; > > > + v->arch.vm_event->write_data.value = msr_content; > > > + > > > + return X86EMUL_OKAY; > > > + } > > > > You seem to change the previous flow of the function here, that would > > just call hvm_monitor_msr and return previously. > > > > Don't you need to move the return from outside the added if condition > > in order to keep previous behavior? Or else the write is committed > > straight away. > > That's exactly what we want to achieve. Postponing the write is buggy. > We want to make that feature optional. Before Bitdefender contributed > that feature writes were always commited straight away, so with this > patch we are actually reverting default behavior to what it was like > to start with. Oh, could this be made clear on the commit message then? When I first saw the code I assumed this was wrong (I'm likely not familiar enough with the code anyway). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:03:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:03:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6ZJ-0003r3-7h; Tue, 02 Jun 2020 13:03:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6ZH-0003qw-Ey for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:02:59 +0000 X-Inumbo-ID: 61d923a8-a4d1-11ea-9dbe-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 61d923a8-a4d1-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 13:02:59 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 20BC9AA7C; Tue, 2 Jun 2020 13:03:00 +0000 (UTC) Subject: Re: [PATCH-for-4.14 v2 1/2] xen: fix build with CONFIG_HYPFS_CONFIG enabled To: Juergen Gross References: <20200602125900.4424-1-jgross@suse.com> <20200602125900.4424-2-jgross@suse.com> From: Jan Beulich Message-ID: <2b6e9630-8181-d035-cc32-4d4793f1a326@suse.com> Date: Tue, 2 Jun 2020 15:02:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200602125900.4424-2-jgross@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 14:58, Juergen Gross wrote: > Commit 58263ed7713e ("xen: add /buildinfo/config entry to hypervisor > filesystem") added a dependency to .config, but the hypervisor's build > config could be have another name via setting KCONFIG_CONFIG. > > Fix that by using $(KCONFIG_CONFIG) instead. Additionally reference > the config file via $(XEN_ROOT) instead of a relative path. > > Reported-by: Andrew Cooper > Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich albeit ... > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -75,7 +75,8 @@ obj-$(CONFIG_UBSAN) += ubsan/ > obj-$(CONFIG_NEEDS_LIBELF) += libelf/ > obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ > > -config.gz: ../.config > +CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(XEN_ROOT)/xen/$(KCONFIG_CONFIG),$(KCONFIG_CONFIG)) ... I'll be tempted to shorten this to CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(XEN_ROOT)/xen/)$(KCONFIG_CONFIG) Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:04:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:04:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6ai-0003zA-IZ; Tue, 02 Jun 2020 13:04:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6ah-0003z2-2Z for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:04:27 +0000 X-Inumbo-ID: 957ae296-a4d1-11ea-abef-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 957ae296-a4d1-11ea-abef-12813bfff9fa; Tue, 02 Jun 2020 13:04:25 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B0831ABD1; Tue, 2 Jun 2020 13:04:26 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values To: Tamas K Lengyel References: <20200602110223.GW1195@Air-de-Roger> <20200602130114.GZ1195@Air-de-Roger> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 15:04:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200602130114.GZ1195@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 15:01, Roger Pau Monné wrote: > On Tue, Jun 02, 2020 at 06:40:12AM -0600, Tamas K Lengyel wrote: >> On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monné wrote: >>> On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: >>>> --- a/xen/arch/x86/hvm/hvm.c >>>> +++ b/xen/arch/x86/hvm/hvm.c >>>> @@ -2263,7 +2263,8 @@ int hvm_set_cr0(unsigned long value, bool may_defer) >>>> { >>>> ASSERT(v->arch.vm_event); >>>> >>>> - if ( hvm_monitor_crX(CR0, value, old_value) ) >>>> + if ( hvm_monitor_crX(CR0, value, old_value) && >>>> + v->domain->arch.monitor.control_register_values ) >>>> { >>>> /* The actual write will occur in hvm_do_resume(), if permitted. */ >>>> v->arch.vm_event->write_data.do_write.cr0 = 1; >>>> @@ -2362,7 +2363,8 @@ int hvm_set_cr3(unsigned long value, bool may_defer) >>>> { >>>> ASSERT(v->arch.vm_event); >>>> >>>> - if ( hvm_monitor_crX(CR3, value, old) ) >>>> + if ( hvm_monitor_crX(CR3, value, old) && >>>> + v->domain->arch.monitor.control_register_values ) >>>> { >>>> /* The actual write will occur in hvm_do_resume(), if permitted. */ >>>> v->arch.vm_event->write_data.do_write.cr3 = 1; >>>> @@ -2443,7 +2445,8 @@ int hvm_set_cr4(unsigned long value, bool may_defer) >>>> { >>>> ASSERT(v->arch.vm_event); >>>> >>>> - if ( hvm_monitor_crX(CR4, value, old_cr) ) >>>> + if ( hvm_monitor_crX(CR4, value, old_cr) && >>>> + v->domain->arch.monitor.control_register_values ) >>> >>> I think you could return control_register_values in hvm_monitor_crX >>> instead of having to add the check to each caller? >> >> We could, but this way the code is more consistent. > > OK, I guess it's a matter of taste. I would rather prefer those checks > to be confined to hvm_monitor_crX because then the generic code is not > polluted with monitor checks, but that's likely just my taste. +1 Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:07:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:07:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6dB-00046s-0F; Tue, 02 Jun 2020 13:07:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6dA-00046l-Ax for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:07:00 +0000 X-Inumbo-ID: f130c57e-a4d1-11ea-9dbe-bc764e2007e4 Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f130c57e-a4d1-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 13:06:59 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id s19so9996920edt.12 for ; Tue, 02 Jun 2020 06:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jq/8DuZTwVrHzI5sV2zSQsVEqQI0253zJLMQa/OcF1I=; b=1gLKxNIMLOMirKgcKQe0Os6Rv2ch8K9aJoPz8cqc5f9wTAw0He17nGfidIzY6WUVVc RmOWwlKmc8Ffa21fSBSgWDlgLPLBA+ngPGb1msLI0gZiFYOhdtGiPMvrAf0bmOdg10Dh 6cABkEw412lVUxrdC1lp2WkmmFIH6KmwIEv+5JQtznbYR+38jg3KfSWqGnJcmBlCcnm4 wTY4PZQha1B18bdabwiehDzXAzbkYAVxe1LvA/gd2Q22NZQaweSInW2yuKKNQC0z2aCV jxKpGLs2IdXmt4sDYHvVPuNv6gYWv+Eyn31Ok7Kg+jNeJ9lN9XGfd99SiBrT0KEqOUfY tx1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jq/8DuZTwVrHzI5sV2zSQsVEqQI0253zJLMQa/OcF1I=; b=nlBvDrYECK89BwboQRwELb5xChuE3IxijHT30x8cI4OMhhpx25Gg9VVk5IVAiN+8dN QEz89vnepwyT+GKzUD8VWQkKaErJ81sdv7lypsoRpz17+YSrQLyKZU9GAdVsNOYy3U8E 8nDyLGiGTgf5b5sJvxruAud+OPEc4tuUzT+IRCmh5XVNuG7B0MkWyMXKI7cfas1hRCzZ gZVyNiuuOxR5wRE+ulh5jjNw16Fjv8o6NAYHcoaqLXvIhlpxhxYiXmjCSVZGdFoPyxzb vkXSHkoo6/zgRvZ7i1pHs/+HPxqKHwztWrjZ0WNHw5avlA2Jztjq29qsyy1uRWa6I1lu hBmw== X-Gm-Message-State: AOAM531lf+edeZSm6T32TR1iSuTEEOhJZ1/mATif5p+1EbEKdBViVbMz Ce/YTUct38/YlmU0LtxxHCWMIyjQc5I= X-Google-Smtp-Source: ABdhPJxFd8GpfDtFM+Hr+tYNOdGH+dC2TicLFi4931qEws0ZQKVyHFr4BsrIrTT9XmYoHW3Bbt6TpA== X-Received: by 2002:a50:a981:: with SMTP id n1mr25239615edc.377.1591103218309; Tue, 02 Jun 2020 06:06:58 -0700 (PDT) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com. [209.85.128.53]) by smtp.gmail.com with ESMTPSA id i15sm1550976edy.80.2020.06.02.06.06.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 06:06:57 -0700 (PDT) Received: by mail-wm1-f53.google.com with SMTP id l26so2854965wme.3 for ; Tue, 02 Jun 2020 06:06:57 -0700 (PDT) X-Received: by 2002:a1c:1b13:: with SMTP id b19mr4005212wmb.84.1591103217442; Tue, 02 Jun 2020 06:06:57 -0700 (PDT) MIME-Version: 1.0 References: <682dde916f982e2889b2be2263418e9506a82c1e.1590028160.git.tamas@tklengyel.com> <20200602125433.GY1195@Air-de-Roger> In-Reply-To: <20200602125433.GY1195@Air-de-Roger> From: Tamas K Lengyel Date: Tue, 2 Jun 2020 07:06:21 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 for-4.14 3/3] xen/vm_event: Add safe to disable vm_event To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 2, 2020 at 6:54 AM Roger Pau Monn=C3=A9 = wrote: > > On Wed, May 20, 2020 at 08:31:54PM -0600, Tamas K Lengyel wrote: > > Instead of having to repeatedly try to disable vm_events, > > Why not use a hypercall continuation instead so that this is all > hidden from the caller? > > I take that the current interface requires the user to repeatedly > issue hypercalls in order to disable vm_events until one of those > succeeds? No, it succeeds right away. And then the guest crashes in unique and unpredictable ways. > > > request a specific > > vm_event to be sent when the domain is safe to continue with shutting d= own > > the vm_event interface. > > > > Signed-off-by: Tamas K Lengyel > > --- > > xen/arch/x86/hvm/hvm.c | 38 ++++++++++++++++++++++++++----- > > xen/arch/x86/hvm/monitor.c | 14 ++++++++++++ > > xen/arch/x86/monitor.c | 13 +++++++++++ > > xen/include/asm-x86/domain.h | 1 + > > xen/include/asm-x86/hvm/monitor.h | 1 + > > xen/include/public/domctl.h | 2 ++ > > xen/include/public/vm_event.h | 8 +++++++ > > 7 files changed, 71 insertions(+), 6 deletions(-) > > > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > > index e6780c685b..fc7e1e2b22 100644 > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -563,15 +563,41 @@ void hvm_do_resume(struct vcpu *v) > > v->arch.hvm.inject_event.vector =3D HVM_EVENT_VECTOR_UNSET; > > } > > > > - if ( unlikely(v->arch.vm_event) && v->arch.monitor.next_interrupt_= enabled ) > > + if ( unlikely(v->arch.vm_event) ) > > { > > - struct x86_event info; > > + struct domain *d =3D v->domain; > > + > > + if ( v->arch.monitor.next_interrupt_enabled ) > > + { > > + struct x86_event info; > > + > > + if ( hvm_get_pending_event(v, &info) ) > > + { > > + hvm_monitor_interrupt(info.vector, info.type, info.err= or_code, > > + info.cr2); > > + v->arch.monitor.next_interrupt_enabled =3D false; > > + } > > + } > > > > - if ( hvm_get_pending_event(v, &info) ) > > + if ( d->arch.monitor.safe_to_disable ) > > { > > - hvm_monitor_interrupt(info.vector, info.type, info.error_c= ode, > > - info.cr2); > > - v->arch.monitor.next_interrupt_enabled =3D false; > > + const struct vcpu *check_vcpu; > > + bool pending_op =3D false; > > + > > + for_each_vcpu ( d, check_vcpu ) > > + { > > + if ( vm_event_check_pending_op(check_vcpu) ) > > Don't you need some kind of lock here, since you are poking at another > vCPU which could be modifying any of those bits? > > > + { > > + pending_op =3D true; > > + break; > > + } > > + } > > + > > + if ( !pending_op ) > > + { > > + hvm_monitor_safe_to_disable(); > > + d->arch.monitor.safe_to_disable =3D false; > > + } > > } > > } > > } > > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c > > index f5d89e71d1..75fd1a4b68 100644 > > --- a/xen/arch/x86/hvm/monitor.c > > +++ b/xen/arch/x86/hvm/monitor.c > > @@ -300,6 +300,20 @@ bool hvm_monitor_check_p2m(unsigned long gla, gfn_= t gfn, uint32_t pfec, > > return monitor_traps(curr, true, &req) >=3D 0; > > } > > > > +void hvm_monitor_safe_to_disable(void) > > +{ > > + struct vcpu *curr =3D current; > > + struct arch_domain *ad =3D &curr->domain->arch; > > const > > > + vm_event_request_t req =3D {}; > > + > > + if ( !ad->monitor.safe_to_disable ) > > + return; > > Should this rather be an ASSERT? I don't think you are supposed to > call hvm_monitor_safe_to_disable when the bit is not set? > > > + > > + req.reason =3D VM_EVENT_REASON_SAFE_TO_DISABLE; > > I think you cat set the field at definition time. > > > + > > + monitor_traps(curr, 0, &req); > > +} > > + > > /* > > * Local variables: > > * mode: C > > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > > index 1517a97f50..86e0ba2fbc 100644 > > --- a/xen/arch/x86/monitor.c > > +++ b/xen/arch/x86/monitor.c > > @@ -339,6 +339,19 @@ int arch_monitor_domctl_event(struct domain *d, > > break; > > } > > > > + case XEN_DOMCTL_MONITOR_EVENT_SAFE_TO_DISABLE: > > + { > > + bool old_status =3D ad->monitor.safe_to_disable; > > + > > + if ( unlikely(old_status =3D=3D requested_status) ) > > + return -EEXIST; > > + > > + domain_pause(d); > > + ad->monitor.safe_to_disable =3D requested_status; > > Maybe I'm missing something, but I don't see any check that others > events are disabled before safe_to_disable is set? > > In the same way, you should prevent setting any events when > safe_to_disable is set IMO, likely returning -EBUSY in both cases. > > Thanks, Roger. Thanks for the feedback again. I won't have the bandwidth to address these so I'm dropping this patch. If Bitdefender is so inclined to pick-up later they are welcome to do so. This is only needed if their buggy feature is enabled. Tamas From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:08:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:08:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6ek-0004D6-C1; Tue, 02 Jun 2020 13:08:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6ej-0004D0-Hl for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:08:37 +0000 X-Inumbo-ID: 2b42dacc-a4d2-11ea-8993-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2b42dacc-a4d2-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 13:08:36 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id a2so12641913ejb.10 for ; Tue, 02 Jun 2020 06:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IyEANLQ0o6/Fw9Bto3i5SOm9Shq6rYVQG+4iJJiLZ44=; b=t1ND66yVJPWmZ0YVI4WzbKjikgqyjyq6GFLylPD82yMUGoDrx3r5vSDE8vC6WyJFV6 y8rjCUx+XpWUDklb68MQwDJjjfH8g7/e8499G77lQ8/7tYcioX+kUXFs/rFUbBAn9iYS BQs/JZ53m36KEygkdzxw69i7ZEx04SIIJS54Tww04Fxpxp3w9pa0+qPHWCRRiWZVNYiW 6MPKYSZTQT1IU74FGlYjsmMoMM2WuAfOYVm02olTdVUmRCRpjxJK5JslR8ho1L9p200N Xt+fPKlJRI+55XvTqc4QzQgLSuTdG9elteJg3HYc/Zw53CasqEGOyEMSsffobq+n3kNS gEdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IyEANLQ0o6/Fw9Bto3i5SOm9Shq6rYVQG+4iJJiLZ44=; b=ckf0vYrmLBhg46LoHZJqPevpVTKs+pR+E0dEhzukQzjtsRueL6uM9U97B71ebDxfL/ 6DFZ4Xpnf6bHNET8WSeC1SFL31io+x90Es3X/Baue6OvXZtvxDYBNSm17/aTFm9iXWLl YflJkq/k4LMFOiI2tleFr5DW1Xo77NrVS2mFiNOEzLATA0MUdA2fE10a0g/Y3E75D2JG i5nJ6gmZ26Go6Aw8m0MpdfbpmbAW373yqjZAJKYAYdLMuP8SE/oeafWbq9FDiRqJ2HwX EqDWwIrj6xl42F4F7jCLrWK2URJi9i2CLv1lusbo4ylmOHeHc1BoHdghLr9W0dRVrfqe tLEg== X-Gm-Message-State: AOAM532aWnDKR1cc8Yi3WXqAvR+YZWaVp45hRCCPibfVu41rUA5UoClY H0kINnjLwR1uwK+x2Wp203L5vys0mBY= X-Google-Smtp-Source: ABdhPJz4SDFX0arws/MdHr1wSjx+xR7dNvk+nHbOne1hlYIza9X5L57UELqrt/8RtUBSI0E7TXF/1g== X-Received: by 2002:a17:906:2a4d:: with SMTP id k13mr24432698eje.253.1591103315077; Tue, 02 Jun 2020 06:08:35 -0700 (PDT) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com. [209.85.128.46]) by smtp.gmail.com with ESMTPSA id gt26sm1611680ejb.107.2020.06.02.06.08.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 06:08:34 -0700 (PDT) Received: by mail-wm1-f46.google.com with SMTP id f5so3063720wmh.2 for ; Tue, 02 Jun 2020 06:08:34 -0700 (PDT) X-Received: by 2002:a05:600c:2294:: with SMTP id 20mr4311282wmf.51.1591103314027; Tue, 02 Jun 2020 06:08:34 -0700 (PDT) MIME-Version: 1.0 References: <20200602110223.GW1195@Air-de-Roger> <20200602130114.GZ1195@Air-de-Roger> In-Reply-To: From: Tamas K Lengyel Date: Tue, 2 Jun 2020 07:07:57 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values To: Jan Beulich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 2, 2020 at 7:04 AM Jan Beulich wrote: > > On 02.06.2020 15:01, Roger Pau Monn=C3=A9 wrote: > > On Tue, Jun 02, 2020 at 06:40:12AM -0600, Tamas K Lengyel wrote: > >> On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monn=C3=A9 wrote: > >>> On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: > >>>> --- a/xen/arch/x86/hvm/hvm.c > >>>> +++ b/xen/arch/x86/hvm/hvm.c > >>>> @@ -2263,7 +2263,8 @@ int hvm_set_cr0(unsigned long value, bool may_= defer) > >>>> { > >>>> ASSERT(v->arch.vm_event); > >>>> > >>>> - if ( hvm_monitor_crX(CR0, value, old_value) ) > >>>> + if ( hvm_monitor_crX(CR0, value, old_value) && > >>>> + v->domain->arch.monitor.control_register_values ) > >>>> { > >>>> /* The actual write will occur in hvm_do_resume(), if p= ermitted. */ > >>>> v->arch.vm_event->write_data.do_write.cr0 =3D 1; > >>>> @@ -2362,7 +2363,8 @@ int hvm_set_cr3(unsigned long value, bool may_= defer) > >>>> { > >>>> ASSERT(v->arch.vm_event); > >>>> > >>>> - if ( hvm_monitor_crX(CR3, value, old) ) > >>>> + if ( hvm_monitor_crX(CR3, value, old) && > >>>> + v->domain->arch.monitor.control_register_values ) > >>>> { > >>>> /* The actual write will occur in hvm_do_resume(), if p= ermitted. */ > >>>> v->arch.vm_event->write_data.do_write.cr3 =3D 1; > >>>> @@ -2443,7 +2445,8 @@ int hvm_set_cr4(unsigned long value, bool may_= defer) > >>>> { > >>>> ASSERT(v->arch.vm_event); > >>>> > >>>> - if ( hvm_monitor_crX(CR4, value, old_cr) ) > >>>> + if ( hvm_monitor_crX(CR4, value, old_cr) && > >>>> + v->domain->arch.monitor.control_register_values ) > >>> > >>> I think you could return control_register_values in hvm_monitor_crX > >>> instead of having to add the check to each caller? > >> > >> We could, but this way the code is more consistent. > > > > OK, I guess it's a matter of taste. I would rather prefer those checks > > to be confined to hvm_monitor_crX because then the generic code is not > > polluted with monitor checks, but that's likely just my taste. > > +1 OK. From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:09:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:09:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6fl-0004Kj-Q3; Tue, 02 Jun 2020 13:09:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6fk-0004KU-GS for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:09:40 +0000 X-Inumbo-ID: 50deddee-a4d2-11ea-9947-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 50deddee-a4d2-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 13:09:40 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id k11so12681099ejr.9 for ; Tue, 02 Jun 2020 06:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Y0VI3BFaJ2TpWY0+LCvNtzL2bHJDl3kh0XWsQa1fc7Q=; b=c/6K4uTPOziyS0c5akldbuiokBOj9ahySML4TFYdwByyqZAnkT2IzIXOYkBTP8u1Mg mjZh32ABUg5lBo2XVTGHKzKGYiA9YEgR7dHWye+bddFpO883fMJfKb/bXY1Pf1flYZRm DJK8x/PwZCvmmoUrOsxeZ6tqlMxHy+QEOsNZ6Y/ApVWsB+8JVJ1rqbp2yLlGQaOKDxln W0enF2ThtIuPXEwjR8+RYmVuh9WlTIH9HcyqxE5CYyj0BnuUvCRxlg1krX9TBh3xB3/4 4Ezc3XRmQXX2UVor0HkKa6Yq0+KULtTo0bXdME0BvLhcWcT+52q9yr9bHm1IBtxvRCNN OsYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Y0VI3BFaJ2TpWY0+LCvNtzL2bHJDl3kh0XWsQa1fc7Q=; b=OJssEOjjqnfWbe2XqXDHIEVvEYYbWbOtDRO7Bf8TUeTp87KUltSd3GLSAq4VOppJTZ xti8DJgdLEvWhiGslvzwp/a9ZqS70kntGIHYvuZMgxmh73FIJmTJL792sWWWQ0cND/4e 4xDXNwWHgNjpaQMMw5D0/rzvyGgVsEFTEVIMZX+SsOXiwGEUzMFfl87I3GyymlAu9Qwj FHZ/t0B5PEM6dVtJtQVweiRAAU9Fmp5kGjpDbe4r1SWqiqAP/5Djt4vtbxCArEmpERBE GvQkkwtvAlUpCD+QJTFyWvFBuesTnkH94Igd8Us4JQcvaBIRXtS6PSWROavaNcjtxdvZ z9Ew== X-Gm-Message-State: AOAM531Afov3sSes2CAoQNVEkMRzYY+YgBkILUqLkkROiieYIPvi5gcm GNflz5heUVYjhUbZ13zucbzDrPwxn8o= X-Google-Smtp-Source: ABdhPJzgc419qfArCFHDWP4/MrHBSYYCoWpyikl8SJOghuN2dKYU7AahlElj6EtYdMFVBZZgCHwnEw== X-Received: by 2002:a17:906:c7da:: with SMTP id dc26mr1875344ejb.500.1591103378756; Tue, 02 Jun 2020 06:09:38 -0700 (PDT) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com. [209.85.128.50]) by smtp.gmail.com with ESMTPSA id bs1sm1535751edb.43.2020.06.02.06.09.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 06:09:38 -0700 (PDT) Received: by mail-wm1-f50.google.com with SMTP id v19so2883266wmj.0 for ; Tue, 02 Jun 2020 06:09:38 -0700 (PDT) X-Received: by 2002:a05:600c:23ce:: with SMTP id p14mr4108328wmb.77.1591103377846; Tue, 02 Jun 2020 06:09:37 -0700 (PDT) MIME-Version: 1.0 References: <20200602110223.GW1195@Air-de-Roger> <20200602130114.GZ1195@Air-de-Roger> In-Reply-To: <20200602130114.GZ1195@Air-de-Roger> From: Tamas K Lengyel Date: Tue, 2 Jun 2020 07:09:01 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 2, 2020 at 7:01 AM Roger Pau Monn=C3=A9 = wrote: > > On Tue, Jun 02, 2020 at 06:40:12AM -0600, Tamas K Lengyel wrote: > > On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monn=C3=A9 wrote: > > > > > > On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: > > > > Extend the monitor_op domctl to include option that enables > > > > controlling what values certain registers are permitted to hold > > > > by a monitor subscriber. > > > > > > I think the change could benefit for some more detail commit message > > > here. Why is this useful? > > > > You would have to ask the Bitdefender folks who made the feature. I > > don't use it. Here we are just making it optional as it is buggy so it > > is disabled by default. > > > > > > > > There already seems to be some support for gating MSR writes, which > > > seems to be expanded by this commit? > > > > We don't expand on any existing features, we make an existing feature o= ptional. > > > > > > > > Is it solving some kind of bug reported? > > > > It does, please take a look at the cover letter. > > Please copy the relevant bits here for reference. Sure. As things stand I'm dropping patch 2 & 3 anyway so I'll just use the cover letter as the commit message. Tamas From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:10:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:10:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6gq-00058n-3g; Tue, 02 Jun 2020 13:10:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6go-00058d-LE for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:10:46 +0000 X-Inumbo-ID: 78445cb0-a4d2-11ea-8993-bc764e2007e4 Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 78445cb0-a4d2-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 13:10:46 +0000 (UTC) Received: by mail-ed1-x541.google.com with SMTP id k19so10011428edv.9 for ; Tue, 02 Jun 2020 06:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fh1MChi4ucV0aKbtrjKRJQeQqvw0jax4gFsFyQpw5wo=; b=o4VCA6Z6cQjY+4Fu8+4LnJlrzSiNCqW4PWTyKlInMymg3r+5askL3jrX/yEgj73iUI zWUCcSnpzkoDCbPf5Fz+uVUFsmUyYMlblia7PNcn86c+5fLF7UBB1DS5wj0CQjPqgQBD 8E6lx9LheX99M5SefzMstyux/BnXvbH7f7PT6r/78mBvBNTdZv4OB+4TcR6cjUSdOiTw 0kgG81fz35iKjqXlcvuU1vDZrMwNeMqXKJv27I3mbq7gOjQ0XhR5x3d3zksb0qKRdLcJ kOVbtGPmKjIzWnwqNbGSs4yjzKdY+7YKznpI/+dyGQbRnOrT2VNJ0RkBZr2XIWUQD645 wzRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fh1MChi4ucV0aKbtrjKRJQeQqvw0jax4gFsFyQpw5wo=; b=g+bzGQgFaBWZrJA9SrDMVffrHxdecCO+z1Xa92wOeViAJki4DDWN0gJ6hcV+DIwRe9 5QIZk+CoX9vwl1+K+dmObstSzAXGVf/+Q9Ap3pezxiJAaxFpr+Ekbmlg3152mHmuBeTV G+HGcLM1AAghGLv9aIxlMPbwHKclV+Htygrw33P1yefSl/VvgyaxfsYGvtKboQC8JL9D UEbqS7KqJOlUU4dZ3jPyDcb4TrXKC6RR/03cXOsI3Zc/Cj1NtreLm2ISschDRgVgCzsX YcpVBqR34Br0WHnWcSf2i8KpCRRDmSFI3KUR8SiBeqG1GT6mSpO6ztlFNaFx0lWi2rrb 1foQ== X-Gm-Message-State: AOAM530JbG/1Z29NhlE8WmqXwELzubDv9IVMntkX9XmOMwsr48B0npvZ CVGCh/ijhAoo5lBm52B7P7AsWcRVK14= X-Google-Smtp-Source: ABdhPJzjQX4CGB30tzJgq7PlowZEqxaBkH2/tr0S6isMimsdh52oPF7OohzhzfZRarDlSWCiSqfD0w== X-Received: by 2002:aa7:d613:: with SMTP id c19mr13542036edr.321.1591103444849; Tue, 02 Jun 2020 06:10:44 -0700 (PDT) Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com. [209.85.128.42]) by smtp.gmail.com with ESMTPSA id z3sm1659543ejl.38.2020.06.02.06.10.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 06:10:44 -0700 (PDT) Received: by mail-wm1-f42.google.com with SMTP id c71so2860705wmd.5 for ; Tue, 02 Jun 2020 06:10:44 -0700 (PDT) X-Received: by 2002:a1c:1b13:: with SMTP id b19mr4019032wmb.84.1591103443840; Tue, 02 Jun 2020 06:10:43 -0700 (PDT) MIME-Version: 1.0 References: <20200602110223.GW1195@Air-de-Roger> In-Reply-To: From: Tamas K Lengyel Date: Tue, 2 Jun 2020 07:10:07 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values To: Jan Beulich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 2, 2020 at 7:00 AM Jan Beulich wrote: > > On 02.06.2020 14:51, Tamas K Lengyel wrote: > > On Tue, Jun 2, 2020 at 6:47 AM Jan Beulich wrote: > >> > >> On 02.06.2020 14:40, Tamas K Lengyel wrote: > >>> On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monn=C3=A9 wrote: > >>>> > >>>> On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: > >>>>> Extend the monitor_op domctl to include option that enables > >>>>> controlling what values certain registers are permitted to hold > >>>>> by a monitor subscriber. > >>>> > >>>> I think the change could benefit for some more detail commit message > >>>> here. Why is this useful? > >>> > >>> You would have to ask the Bitdefender folks who made the feature. I > >>> don't use it. Here we are just making it optional as it is buggy so i= t > >>> is disabled by default. > >> > >> Now that's exactly the opposite of what I had derived from the > >> description here so far. Perhaps an at least weak indication > >> that you want to reword this. For example, from your reply to > >> Roger I understand it's rather that the new flag allows to > >> "suppress" the controlling (since presumably you don't change > >> default behavior), rather then "enabling" it. > > > > What we are adding is a domctl you need to call that enables this > > feature. It's not an option to suppress it. It shouldn't have been > > enabled by default to begin with. That was a mistake when the feature > > was contributed and it is buggy. > > Okay, in this case it's important to point out that you alter > default behavior. The BitDefender folks may not like this, yet > they've been surprisingly silent so far. Well, it was Bitdefender who altered the default behavior. We are reverting their mistake and making it optional. But I can certainly make that more clear. Tamas From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:11:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:11:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6hO-0005E7-Fn; Tue, 02 Jun 2020 13:11:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6hN-0005Dy-RC for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:11:21 +0000 X-Inumbo-ID: 8d468872-a4d2-11ea-9dbe-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8d468872-a4d2-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 13:11:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A421CABCE; Tue, 2 Jun 2020 13:11:22 +0000 (UTC) Subject: Re: [PATCH v2 10/14] x86/extable: Adjust extable handling to be shadow stack compatible To: Andrew Cooper References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-11-andrew.cooper3@citrix.com> <0c7f425a-996f-8840-f1e2-79381edb6456@citrix.com> <9d86ecf8-eaaa-7c2c-a3cc-b832d013a225@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 2 Jun 2020 15:11:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <9d86ecf8-eaaa-7c2c-a3cc-b832d013a225@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.05.2020 23:17, Andrew Cooper wrote: > On 29/05/2020 20:43, Andrew Cooper wrote: >> On 28/05/2020 17:15, Jan Beulich wrote: >>> On 27.05.2020 21:18, Andrew Cooper wrote: >>>> + >>>> + if ( ptr[0] == regs->rip && ptr[1] == regs->cs ) >>>> + { >>>> + asm ( "wrssq %[fix], %[stk]" >>>> + : [stk] "=m" (*ptr) >>> Could this be ptr[0], to match the if()? >>> >>> Considering how important it is that we don't fix up the wrong stack >>> location here, I continue to wonder if we wouldn't better also >>> include the SSP value on the stack in the checking, at the very >>> least by way of an ASSERT() or BUG_ON(). >> Well no, for the reason discussed in point 1. >> >> Its not technically an issue right now, but there is no possible way to >> BUILD_BUG_ON() someone turning an exception into IST, or stopping the >> use of the extable infrastructure on a #DB. >> >> Such a check would lie in wait and either provide an unexpected tangent >> to someone debugging a complicated issue (I do use #DB for a fair bit), >> or become a security vulnerability. > > Also (which I forgot first time around), > > The ptr[1] == regs->cs check is 64 bits wide, and the way to get that on > the shadow stack would be to execute a call instruction ending at at > 0xe008 linear, or from a bad WRSSQ edit, both of which are serious > errors and worthy of hitting the BUG(). Maybe you misunderstood me then: By suggesting more strict checking I'm actually asking for it to become more likely to hit that BUG(), not less likely. (This is despite agreeing that the very limited range of CS values on the stack already makes it practically impossible to mistake the frame found.) Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:22:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:22:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6rT-0006L6-PK; Tue, 02 Jun 2020 13:21:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg6rS-0006L1-V9 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:21:46 +0000 X-Inumbo-ID: 01786ad4-a4d4-11ea-9947-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 01786ad4-a4d4-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 13:21:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 18356AF7F; Tue, 2 Jun 2020 13:21:47 +0000 (UTC) Subject: Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus [and 1 more messages] To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= References: <20200406082704.13994-1-jgross@suse.com> <24203.2251.628483.557280@mariner.uk.xensource.com> <26161282-7bad-5888-16c9-634647e6fde8@xen.org> <8a6f6e41-9395-6c68-eae9-4c1aeb7d96e2@suse.com> <24203.2546.728186.463143@mariner.uk.xensource.com> <24203.2996.819908.965198@mariner.uk.xensource.com> <799396b3-0304-e149-cc3f-45c5a46c7c0c@suse.com> <715f6143-38b3-3f70-b9e3-1ac4a240282f@suse.com> <08eff8dd-59b2-9f3e-9664-ff126eecd123@suse.com> <01ff5111-d5bf-f4ba-6fba-a156b89eaf85@suse.com> From: Jan Beulich Message-ID: <9e55d7b3-8e5a-49f2-9ed0-059073d63eb2@suse.com> Date: Tue, 2 Jun 2020 15:21:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <01ff5111-d5bf-f4ba-6fba-a156b89eaf85@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , Ian Jackson , Julien Grall , Wei Liu , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 13:23, Jürgen Groß wrote: > On 02.06.20 13:12, Jan Beulich wrote: >> On 02.06.2020 13:06, Jürgen Groß wrote: >>> On 06.04.20 14:09, Jan Beulich wrote: >>>> On 06.04.2020 13:54, Jürgen Groß wrote: >>>>> On 06.04.20 13:11, Jan Beulich wrote: >>>>>> On 06.04.2020 13:00, Ian Jackson wrote: >>>>>>> Julien Grall writes ("Re: [PATCH v2] tools/libxl: make default of max event channels dependant on vcpus"): >>>>>>>> There are no correlation between event channels and vCPUs. The number of >>>>>>>> event channels only depends on the number of frontend you have in your >>>>>>>> guest. So... >>>>>>>> >>>>>>>> Hi Ian, >>>>>>>> >>>>>>>> On 06/04/2020 11:47, Ian Jackson wrote: >>>>>>>>> If ARM folks want to have a different formula for the default then >>>>>>>>> that is of course fine but I wonder whether this might do ARMk more >>>>>>>>> harm than good in this case. >>>>>>>> >>>>>>>> ... 1023 event channels is going to be plenty enough for most of the use >>>>>>>> cases. >>>>>>> >>>>>>> OK, thanks for the quick reply. >>>>>>> >>>>>>> So, Jürgen, I think everyone will be happy with this: >>>>>> >>>>>> I don't think I will be - my prior comment still holds on there not >>>>>> being any grounds to use a specific OS kernel's (and to be precise >>>>>> a specific OS kernel version's) requirements for determining >>>>>> defaults. If there was to be such a dependency, then OS kernel >>>>>> [variant] should be part of the inputs to such a (set of) formula(s). >>>>> >>>>> IMO this kind of trying to be perfect will completely block a sane >>>>> heuristic for being able to boot large guests at all. >>>> >>>> This isn't about being perfect - I'm suggesting to leave the >>>> default alone, not to improve the calculation, not the least >>>> because I've been implying ... >>>> >>>>> The patch isn't about to find an as stringent as possible upper >>>>> boundary for huge guests, but a sane value being able to boot most of >>>>> those. >>>>> >>>>> And how should Xen know the OS kernel needs exactly after all? >>>> >>>> ... the answer of "It can#t" to this question. >>>> >>>>> And it is not that we talking about megabytes of additional memory. A >>>>> guest with 256 vcpus will just be able to use additional 36 memory >>>>> pages. The maximum non-PV domain (the probably only relevant case >>>>> of another OS than Linux being used) with 128 vcpus would "waste" >>>>> 32 kB. In case the guest misbehaves. >>>> >>>> Any extra page counts, or else - where do you draw the line? Any >>>> single page may decide between Xen (not) being out of memory, >>>> and hence also not being able to fulfill certain other requests. >>>> >>>>> The alternative would be to do nothing and having to let the user >>>>> experience a somewhat cryptic guest crash. He could google for a >>>>> possible solution which would probably end in a rather high static >>>>> limit resulting in wasting even more memory. >>>> >>>> I realize this. Otoh more people running into this will improve >>>> the chances of later ones finding useful suggestions. Of course >>>> there's also nothing wrong with trying to make the error less >>>> cryptic. >>> >>> Reviving this discussion. >>> >>> I strongly disagree with your reasoning. >>> >>> Rejecting to modify tools defaults for large guests to make them boot >>> is a bad move IMO. We are driving more people away from Xen this way. >>> >>> The fear of a misbehaving guest of that size to use a few additional >>> pages on a machine with at least 100 cpus is fine from the academical >>> point of view, but should not be weighed higher than the usability >>> aspect in this case IMO. >> >> Very simple question then: Where do you draw the boundary if you don't >> want this to be a pure "is permitted" or "is not permitted" underlying >> rule? If we had a model where _all_ resources consumed by a guest were >> accounted against its tool stack requested allocation, things would be >> easier. > > I'd say it should be allowed in case the additional resource use is much > smaller than the already used implicit resources for such a guest (e.g. > less than an additional 1% of implicitly used memory). > > In cases like this, where a very small subset of guests is affected, and > the additional need of resources will apply only in very extreme cases > (I'm considering this case as extreme, as only non-Linux guests with > huge numbers of vcpus _and_ which are misbehaving will need additional > resources) I'd even accept higher margins like 5%. IOW if we had 20 such cases, doubling resource consumption would be okay to you? Not to me... FAOD: If I'm the (almost?) only one to object here, I'll be okay to be outvoted. But I'd like people agreeing with the change to explicitly ack that they're fine with the unwanted (as I'd call it) side effects. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:48:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7HG-0008EH-Vc; Tue, 02 Jun 2020 13:48:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7HF-0008EC-Sb for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:48:25 +0000 X-Inumbo-ID: bac12cbc-a4d7-11ea-81bc-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bac12cbc-a4d7-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 13:48:25 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 46143AC2D; Tue, 2 Jun 2020 13:48:26 +0000 (UTC) Subject: Re: [PATCH-for-4.14 v2 1/2] xen: fix build with CONFIG_HYPFS_CONFIG enabled To: Jan Beulich References: <20200602125900.4424-1-jgross@suse.com> <20200602125900.4424-2-jgross@suse.com> <2b6e9630-8181-d035-cc32-4d4793f1a326@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Tue, 2 Jun 2020 15:48:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <2b6e9630-8181-d035-cc32-4d4793f1a326@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.20 15:02, Jan Beulich wrote: > On 02.06.2020 14:58, Juergen Gross wrote: >> Commit 58263ed7713e ("xen: add /buildinfo/config entry to hypervisor >> filesystem") added a dependency to .config, but the hypervisor's build >> config could be have another name via setting KCONFIG_CONFIG. >> >> Fix that by using $(KCONFIG_CONFIG) instead. Additionally reference >> the config file via $(XEN_ROOT) instead of a relative path. >> >> Reported-by: Andrew Cooper >> Signed-off-by: Juergen Gross > > Reviewed-by: Jan Beulich > albeit ... > >> --- a/xen/common/Makefile >> +++ b/xen/common/Makefile >> @@ -75,7 +75,8 @@ obj-$(CONFIG_UBSAN) += ubsan/ >> obj-$(CONFIG_NEEDS_LIBELF) += libelf/ >> obj-$(CONFIG_HAS_DEVICE_TREE) += libfdt/ >> >> -config.gz: ../.config >> +CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(XEN_ROOT)/xen/$(KCONFIG_CONFIG),$(KCONFIG_CONFIG)) > > ... I'll be tempted to shorten this to > > CONF_FILE := $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(XEN_ROOT)/xen/)$(KCONFIG_CONFIG) Yes, this is better. Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:49:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:49:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7I8-0008J0-8r; Tue, 02 Jun 2020 13:49:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7I7-0008Is-3p for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:49:19 +0000 X-Inumbo-ID: daa80b86-a4d7-11ea-9dbe-bc764e2007e4 Received: from mail-io1-xd44.google.com (unknown [2607:f8b0:4864:20::d44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id daa80b86-a4d7-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 13:49:18 +0000 (UTC) Received: by mail-io1-xd44.google.com with SMTP id d5so10860620ios.9 for ; Tue, 02 Jun 2020 06:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=oF/8KhHOgHMbkhjKw/xnVx3BTmm6D4iMvttQzgguYhI=; b=cQbZA+A50U1m+HC9Bi1/XuXXEqmsW1/7H4TCBvrJEteQlJMkUMY+cf/Cbi2XUYSv+I XSl/aMSo6Tk/Sgrumi/R8cYcbN/+gBz2+RzbXHiPlBD5WVAskoMetsya45vstrLoD8ZL B03qJiuZi3c7ITheHnmgfoghmhOEQS/3MzMlk1/GRZfhUkveQJMMAHaC1SIFWcG8VocQ APMUW/9SzrXPgYWn1yV2cHuNvCp8kIBMiuI5RKcWXniu7jFhfinIU5wLylZRpHKYr9CA MjKMGIyDHU3zIU4mFbFe2iFgO7kdFezvlirlmf7ZM0uvrN/0un/q9IymxaTV6NwjqEry qS+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=oF/8KhHOgHMbkhjKw/xnVx3BTmm6D4iMvttQzgguYhI=; b=SwKPkRKvWNEXJnylbujU6ajEOkESjEl3lk25rDagk0YjAqeRV9M6GlDcarBdz9l+pc f2/hXa3XVFdrfAG9mjF114A18Y2IVlMHs9jQcgREVD1BzP3IsXluVwyicuFRvXGWTicA 6paiPXOecYjAovaNkyHtzsq5t+GEyPHZzDFLsxs+3DBGnxcr6npYiK6qTkG1gRZK/hKk ryB3hIqYYQLcoTKz+iCT0vTpSEeHlKqgrIQ+oyaIlh/Mg9BEABMMJV3WMDnMGYMXF9kI JnSsFfIg7pmANttj0RkdZZ1sdSnvHiwfanb54QiU1k+WX11cF+x9h4KuMrn/EneLFSUu i2jg== X-Gm-Message-State: AOAM532wl6DKAmoG4AQZvzKWGL2apNZjRAYc7g+DBF+IXEg4BVdUprab /OeTjaozhMOls/8xnU3DHHtDuI8V3Po= X-Google-Smtp-Source: ABdhPJx7ehSiQv4rgi7EvcxJkehaVspEalVhjAQC3QEvm30PjluqVTm0qwpP3xrPsodvXva/9GXfKQ== X-Received: by 2002:a02:ac0a:: with SMTP id a10mr25417901jao.97.1591105754364; Tue, 02 Jun 2020 06:49:14 -0700 (PDT) Received: from localhost (c-71-205-12-124.hsd1.co.comcast.net. [71.205.12.124]) by smtp.gmail.com with ESMTPSA id p5sm1335943ilg.88.2020.06.02.06.49.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Jun 2020 06:49:12 -0700 (PDT) From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v3 for-4.14] x86/monitor: revert default behavior when monitoring register write events Date: Tue, 2 Jun 2020 07:49:09 -0600 Message-Id: <20200602134909.66581-1-tamas@tklengyel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Tamas K Lengyel , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Stefano Stabellini , Jan Beulich , Alexandru Isaila , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" For the last couple years we have received numerous reports from users of monitor vm_events of spurious guest crashes when using events. In particular, it has observed that the problem occurs when vm_events are being disabled. The nature of the guest crash varied widely and has only occured occasionally. This made debugging the issue particularly hard. We had discussions about this issue even here on the xen-devel mailinglist with no luck figuring it out. The bug has now been identified as a race-condition between register event handling and disabling the monitor vm_event interface. Patch 96760e2fba100d694300a81baddb5740e0f8c0ee, "vm_event: deny register writes if refused by vm_event reply" is the patch that introduced the error. In this patch the default behavior regarding emulation of register write events is changed so that they get postponed until the corresponding vm_event handler decides whether to allow such write to take place. Unfortunately this can only be implemented by performing the deny/allow step when the vCPU gets scheduled. Due to that postponed emulation of the event if the user decides to pause the VM in the vm_event handler and then disable events, the entire emulation step is skipped the next time the vCPU is resumed. Even if the user doesn't pause during the vm_event handling but exits immediately and disables vm_event, the situation becomes racey as disabling vm_event may succeed before the guest's vCPUs get scheduled with the pending emulation task. This has been particularly the case with VMS that have several vCPUs as after the VM is unpaused it may actually take a long time before all vCPUs get scheduled. In this patch we are reverting the default behavior to always perform emulation of register write events when the event occurs. To postpone them can be turned on as an option. In that case the user of the interface still has to take care of only disabling the interface when its safe as it remains buggy. Signed-off-by: Tamas K Lengyel --- xen/arch/x86/hvm/hvm.c | 14 ++++++++------ xen/arch/x86/hvm/monitor.c | 13 ++++++++----- xen/arch/x86/monitor.c | 10 +++++++++- xen/include/asm-x86/domain.h | 1 + xen/include/asm-x86/hvm/monitor.h | 7 +++---- xen/include/public/domctl.h | 1 + 6 files changed, 30 insertions(+), 16 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 74c9f84462..5bb47583b3 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -3601,13 +3601,15 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content, ASSERT(v->arch.vm_event); - /* The actual write will occur in hvm_do_resume() (if permitted). */ - v->arch.vm_event->write_data.do_write.msr = 1; - v->arch.vm_event->write_data.msr = msr; - v->arch.vm_event->write_data.value = msr_content; + if ( hvm_monitor_msr(msr, msr_content, msr_old_content) ) + { + /* The actual write will occur in hvm_do_resume(), if permitted. */ + v->arch.vm_event->write_data.do_write.msr = 1; + v->arch.vm_event->write_data.msr = msr; + v->arch.vm_event->write_data.value = msr_content; - hvm_monitor_msr(msr, msr_content, msr_old_content); - return X86EMUL_OKAY; + return X86EMUL_OKAY; + } } if ( (ret = guest_wrmsr(v, msr, msr_content)) != X86EMUL_UNHANDLEABLE ) diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c index 8aa14137e2..36894b33a4 100644 --- a/xen/arch/x86/hvm/monitor.c +++ b/xen/arch/x86/hvm/monitor.c @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long old) .u.write_ctrlreg.old_value = old }; - if ( monitor_traps(curr, sync, &req) >= 0 ) - return 1; + return monitor_traps(curr, sync, &req) >= 0 && + curr->domain->arch.monitor.control_register_values; } - return 0; + return false; } bool hvm_monitor_emul_unimplemented(void) @@ -77,7 +77,7 @@ bool hvm_monitor_emul_unimplemented(void) monitor_traps(curr, true, &req) == 1; } -void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value) +bool hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value) { struct vcpu *curr = current; @@ -92,8 +92,11 @@ void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value) .u.mov_to_msr.old_value = old_value }; - monitor_traps(curr, 1, &req); + return monitor_traps(curr, 1, &req) >= 0 && + curr->domain->arch.monitor.control_register_values; } + + return false; } void hvm_monitor_descriptor_access(uint64_t exit_info, diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c index bbcb7536c7..1517a97f50 100644 --- a/xen/arch/x86/monitor.c +++ b/xen/arch/x86/monitor.c @@ -144,7 +144,15 @@ int arch_monitor_domctl_event(struct domain *d, struct xen_domctl_monitor_op *mop) { struct arch_domain *ad = &d->arch; - bool requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op); + bool requested_status; + + if ( XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS == mop->op ) + { + ad->monitor.control_register_values = true; + return 0; + } + + requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op); switch ( mop->event ) { diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h index e8cee3d5e5..6fd94c2e14 100644 --- a/xen/include/asm-x86/domain.h +++ b/xen/include/asm-x86/domain.h @@ -418,6 +418,7 @@ struct arch_domain * This is used to filter out pagefaults. */ unsigned int inguest_pagefault_disabled : 1; + unsigned int control_register_values : 1; struct monitor_msr_bitmap *msr_bitmap; uint64_t write_ctrlreg_mask[4]; } monitor; diff --git a/xen/include/asm-x86/hvm/monitor.h b/xen/include/asm-x86/hvm/monitor.h index 66de24cb75..a75cd8545c 100644 --- a/xen/include/asm-x86/hvm/monitor.h +++ b/xen/include/asm-x86/hvm/monitor.h @@ -29,15 +29,14 @@ enum hvm_monitor_debug_type }; /* - * Called for current VCPU on crX/MSR changes by guest. - * The event might not fire if the client has subscribed to it in onchangeonly - * mode, hence the bool return type for control register write events. + * Called for current VCPU on crX/MSR changes by guest. Bool return signals + * whether emulation should be postponed. */ bool hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long old); #define hvm_monitor_crX(cr, new, old) \ hvm_monitor_cr(VM_EVENT_X86_##cr, new, old) -void hvm_monitor_msr(unsigned int msr, uint64_t value, uint64_t old_value); +bool hvm_monitor_msr(unsigned int msr, uint64_t value, uint64_t old_value); void hvm_monitor_descriptor_access(uint64_t exit_info, uint64_t vmx_exit_qualification, uint8_t descriptor, bool is_write); diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index 1ad34c35eb..cbcd25f12c 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -1025,6 +1025,7 @@ struct xen_domctl_psr_cmt_op { #define XEN_DOMCTL_MONITOR_OP_DISABLE 1 #define XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES 2 #define XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP 3 +#define XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS 4 #define XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG 0 #define XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR 1 -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 13:50:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 13:50:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7J8-0000e5-NN; Tue, 02 Jun 2020 13:50:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7J7-0000du-TF for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 13:50:21 +0000 X-Inumbo-ID: ffd2557e-a4d7-11ea-9947-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ffd2557e-a4d7-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 13:50:21 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: E7Rn2YMmA958G1Z6kBO/USICXAcuI7mINNu7W7fIaBoWckAbew7dnM0Y1+xVB8aqy+cq6YWfOB iQKNG88JWG7uraQFJI0aAZp652XMm1oybedDGy/RuCpHTSMxzqObV9OXNgXqMTh/DNqKNn/ubg /bNX5jnwLrjxgKlWpVtOGfMd41z8sAzk1JlkoHf801okrFvVHDXCxdyLx7Q4mir5mS4oiwPGRM gMhmxtqyMPhXT8UGGzRZ6KGhcyOytch/KthGTUW4pI5FCu+qteJvgJJuEhS45j08pUKLLc9j9g GVk= X-SBRS: 2.7 X-MesageID: 19313578 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,464,1583211600"; d="scan'208";a="19313578" Date: Tue, 2 Jun 2020 14:50:10 +0100 From: Anthony PERARD To: Jan Beulich Subject: Re: [PATCH v2 03/14] x86/shstk: Introduce Supervisor Shadow Stack support Message-ID: <20200602135010.GO2105@perard.uk.xensource.com> References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-4-andrew.cooper3@citrix.com> <4f535d4c-b3b3-fe5b-8b57-af736dc0a360@suse.com> <20200602122614.GN2105@perard.uk.xensource.com> <3328fabd-c133-00a9-2ec0-addcf15dbff5@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <3328fabd-c133-00a9-2ec0-addcf15dbff5@suse.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau =?iso-8859-1?Q?Monn=E9?= , Wei Liu , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 02:41:30PM +0200, Jan Beulich wrote: > On 02.06.2020 14:26, Anthony PERARD wrote: > > On Tue, Jun 02, 2020 at 02:06:11PM +0200, Jan Beulich wrote: > >> I don't recall; perhaps I was in another parallel session? If it's > >> the one with notes at > >> https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00786.html > >> then a remark close to the top suggests I was there, but there's no > >> sign of this aspect having got discussed. There is, among the issues > >> listed, "Xen build re-evaluates compiler support for every translation > >> unit", but that's only remotely related. > > > > What is a "translation unit"? What would that have to do with Kconfig? > > A translation unit is the collective input from all source and > header files seen by the compiler during the processing of one > top level input file's worth of compilation. Thanks. Now it feels like the issue listed in the design session note isn't exactly correct, compiler didn't used to be evaluated once per CU, but only once per Makefile loaded/executed. > The connection to > Kconfig here is that by switching to it, the compiler flags > don't get re-constructed once per CU. Of course doing it via > Kconfig is not the only possible solution to the problem (as > can be seen from the patch that I had intermediately submitted > to get at least the HAVE_AS_* out of that set), but for us the > change in behavior is one intended (side-)effect of the switch > to newer Kconfig. Well, with a recent patch of mine, tool chain support should already be only evaluated only once in the root Makefile. So I do also think that we don't need to move all of them to Kconfig. So advantage of evaluating some compiler flags in Kconfig is that we can have other CONFIG_* depends on those flags; the inconvenient is to figure out when do we need to re-evaluate the .config. -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Jun 02 14:13:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 14:13:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7fk-0002i1-1r; Tue, 02 Jun 2020 14:13:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7fi-0002ht-Na for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 14:13:42 +0000 X-Inumbo-ID: 42d43434-a4db-11ea-8993-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 42d43434-a4db-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 14:13:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4BF6AAC12; Tue, 2 Jun 2020 14:13:43 +0000 (UTC) Subject: Re: [PATCH v2 03/14] x86/shstk: Introduce Supervisor Shadow Stack support To: Anthony PERARD References: <20200527191847.17207-1-andrew.cooper3@citrix.com> <20200527191847.17207-4-andrew.cooper3@citrix.com> <4f535d4c-b3b3-fe5b-8b57-af736dc0a360@suse.com> <20200602122614.GN2105@perard.uk.xensource.com> <3328fabd-c133-00a9-2ec0-addcf15dbff5@suse.com> <20200602135010.GO2105@perard.uk.xensource.com> From: Jan Beulich Message-ID: <54ea28e3-0a07-a296-4328-62633b76d5c3@suse.com> Date: Tue, 2 Jun 2020 16:13:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200602135010.GO2105@perard.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 15:50, Anthony PERARD wrote: > On Tue, Jun 02, 2020 at 02:41:30PM +0200, Jan Beulich wrote: >> On 02.06.2020 14:26, Anthony PERARD wrote: >>> On Tue, Jun 02, 2020 at 02:06:11PM +0200, Jan Beulich wrote: >>>> I don't recall; perhaps I was in another parallel session? If it's >>>> the one with notes at >>>> https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00786.html >>>> then a remark close to the top suggests I was there, but there's no >>>> sign of this aspect having got discussed. There is, among the issues >>>> listed, "Xen build re-evaluates compiler support for every translation >>>> unit", but that's only remotely related. >>> >>> What is a "translation unit"? What would that have to do with Kconfig? >> >> A translation unit is the collective input from all source and >> header files seen by the compiler during the processing of one >> top level input file's worth of compilation. > > Thanks. Now it feels like the issue listed in the design session note > isn't exactly correct, compiler didn't used to be evaluated once per CU, > but only once per Makefile loaded/executed. > >> The connection to >> Kconfig here is that by switching to it, the compiler flags >> don't get re-constructed once per CU. Of course doing it via >> Kconfig is not the only possible solution to the problem (as >> can be seen from the patch that I had intermediately submitted >> to get at least the HAVE_AS_* out of that set), but for us the >> change in behavior is one intended (side-)effect of the switch >> to newer Kconfig. > > Well, with a recent patch of mine, tool chain support should already be > only evaluated only once in the root Makefile. So I do also think that > we don't need to move all of them to Kconfig. > > So advantage of evaluating some compiler flags in Kconfig is that we > can have other CONFIG_* depends on those flags; I'm not even certain this is an advantage: CET-SS is going a different direction than the majority of cases we have had in the tree so far (INDIRECT_THUNK is another such case). In the majority of cases, though, the tool chain capabilities don't affect functionality, but just code quality. And indeed I think that's how Kconfig should be used: When configuring Xen, it ought to be specified what functionality is wanted, irrespective of compilers used/available. In particular a syncconfig run would better not require a host compiler to be available at all, such that configurations for targets for which there's no cross compiler can also be produced. (Not sure whether that's still the case, but our internal kernel processing used to work that way, without requiring everyone to have compilers for all target architectures our kernels support.) It would be the responsibility of the person doing the config to ensure only options get enabled that can actually be built in the environment that the full build is actually to be run in. (That is, for the case it's inconvenient [CET-SS] or impossible [INDIRECT_THUNK] to build without suitable tool chain support, I'm not questioning the desire to have certain features outright unavailable. It's just that I don't see why this unavailability needs to be expressed at the Kconfig level.) Jan > the inconvenient is to > figure out when do we need to re-evaluate the .config. > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 14:21:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 14:21:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7n6-0003j5-UI; Tue, 02 Jun 2020 14:21:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7n6-0003j0-9h for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 14:21:20 +0000 X-Inumbo-ID: 53999f92-a4dc-11ea-ac12-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 53999f92-a4dc-11ea-ac12-12813bfff9fa; Tue, 02 Jun 2020 14:21:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 1C16EAE21; Tue, 2 Jun 2020 14:21:21 +0000 (UTC) To: Andrew Cooper From: Jan Beulich Subject: Re [PATCH] x86/CET: Fix build following c/s 43b98e7190 Message-ID: <1eeb47f4-b9b9-c4d8-a5c9-58d78f0e0aeb@suse.com> Date: Tue, 2 Jun 2020 16:21:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > OSSTest reports: > > x86_64.S: Assembler messages: > x86_64.S:57: Error: no such instruction: `setssbsy' > /home/osstest/build.150510.build-amd64/xen/xen/Rules.mk:183: recipe for target 'head.o' failed > make[4]: Leaving directory '/home/osstest/build.150510.build-amd64/xen/xen/arch/x86/boot' > make[4]: *** [head.o] Error 1 > > All use of CET instructions, even those inside alternative blocks, needs to be > behind CONFIG_XEN_SHSTK, as it indicates suitable toolchain support. > > Signed-off-by: Andrew Cooper That's quite a bit of #ifdef-ary here. Simple (operand-less) insns like SETSSBSY could easily be made available via .byte directives. Would you be amenable to to ack-ing a patch to replace some of the #ifdef-s (at least the ones at the lstar, cstar, and sysenter entry points), after 4.14? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 02 14:30:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 14:30:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7w7-0004h8-SQ; Tue, 02 Jun 2020 14:30:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg7w6-0004h3-II for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 14:30:38 +0000 X-Inumbo-ID: a06d0d44-a4dd-11ea-81bc-bc764e2007e4 Received: from mail-wm1-x331.google.com (unknown [2a00:1450:4864:20::331]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a06d0d44-a4dd-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 14:30:37 +0000 (UTC) Received: by mail-wm1-x331.google.com with SMTP id f185so3352054wmf.3 for ; Tue, 02 Jun 2020 07:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=UGliGAMK0m7S2tSvoytJT1swPRZuq7C5chivfM4iRi8=; b=WdeV/WfXnBxpJhKno2k/iLPnk5kWwTGK7oskeyrQCJFGHvZerlhFh0cJTU/QQqNmYN k9mybIySypjoabXvUzIIUK4FRZKOaxTTBPjQZKnp77YuCe5DRmd7ApCwYCLLiKihcCqe /4posYPjhHS7MeK6uzk6k1dKiGc8MXBgifZ+RP7dXP+fEOsZab9CMqTbZGvbn1RLUft1 E39+tfhhE+ReI+FF9XzcqcTLzMhaUu9m/Q0eLhBVa6y1bJ76D4ksUDOF/9xJXfkHQ6W5 C7t6zNMIEVzvsWhZxyUB1WCngzoP5o9i9K6YNQoP3RDaMG+9Zg02O8dwTjhMxKxl7fGA NZTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=UGliGAMK0m7S2tSvoytJT1swPRZuq7C5chivfM4iRi8=; b=bvLgkOa/jZFLm8ZXrm0zop67ZT8pBfZpCmjOPn6JXHHWl4WAcV1OwRhj+OSK2PVuTQ 3xYXQ4X3NAGgDE1gCc+OyhbbzKqRzYS3utAiUxfBmaC79lhGT5ItOr8iJwMrGVt6Fs1C A15Wj2wG3wDg/tWSazN7LDvQhop6n5TeR+Mdqfy+0zsDLGCmGttSlpL0hUo61YcbVBWH EPi/Il0Jnj/5PIN6AYV1b6jjAjuJHB40vSRxPd6zymNKPRx/HBWY/JXWajXW4g0VRQg4 N9Jn0EA8AM46aME6oFz8ieV3CJ1VOKzH+++97ULaQAm9BWLW1WW2zh7nMtcvyFsKqI9L FXNg== X-Gm-Message-State: AOAM530El1YoXxy5Cssboy3rpv5yKZvqywpDNlTRfazXKG3SrsuqXE3x igezPVgD8eXtCsa9vM9bOak= X-Google-Smtp-Source: ABdhPJwYp7BP2qX1mz1wbRd6y26QhJ5Cc5KQc7xTVHbJJKfk9J5V+6lpIVgCjICgPOb7tMgFPo+MdQ== X-Received: by 2002:a1c:de46:: with SMTP id v67mr4359702wmg.146.1591108237093; Tue, 02 Jun 2020 07:30:37 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id l18sm3497613wmj.22.2020.06.02.07.30.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jun 2020 07:30:36 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Juergen Gross'" , References: <20200602125900.4424-1-jgross@suse.com> In-Reply-To: <20200602125900.4424-1-jgross@suse.com> Subject: RE: [PATCH-for-4.14 v2 0/2] xen: build fixes for CONFIG_HYPFS Date: Tue, 2 Jun 2020 15:30:35 +0100 Message-ID: <003b01d638ea$61a16c40$24e444c0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJKOXQt7xRe1uFXwlCBkJ1ef6M2OqfdYa6w X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Juergen Gross > Sent: 02 June 2020 13:59 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Juergen Gross ; Andrew Cooper = ; George > Dunlap ; Ian Jackson = ; Jan Beulich > ; Julien Grall ; Stefano Stabellini = ; Wei > Liu ; Roger Pau Monn=C3=A9 > Subject: [PATCH-for-4.14 v2 0/2] xen: build fixes for CONFIG_HYPFS >=20 > Fixing an issue Andrew met, and disabling CONFIG_HYPFS in pv-shim. >=20 > Juergen Gross (2): > xen: fix build with CONFIG_HYPFS_CONFIG enabled > xen/config: disable hypervisor filesystem for pv-shim >=20 > xen/arch/x86/configs/pvshim_defconfig | 1 + > xen/common/Makefile | 3 ++- > 2 files changed, 3 insertions(+), 1 deletion(-) >=20 Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Tue Jun 02 15:19:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 15:19:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg8gb-0008MB-Ih; Tue, 02 Jun 2020 15:18:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg8gZ-0008M0-T5 for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 15:18:40 +0000 X-Inumbo-ID: 4876f5c6-a4e4-11ea-81bc-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4876f5c6-a4e4-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 15:18:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=9JDpRruYN8FFXnlaEBKZNJuuVIZoXAd8aOfxQ7SNZDY=; b=nRoxJl915R5xmM6BzMjtpCBkbL ZpbpNLRk0eVz3ngl+KrShKLJrygSoxaBBdTdxzEtds1c457v2c/Yv1QkSGF95LOT9xL5IOyIyRXyk LyCekSihCBIGV8nTTKVJpd5FS6UfbkYQBlgqwckg0GxRvIP38iBbEpmSybPlQK3fln0dg6T8ZXKuO WOnIL/WSmZGmRrCK76m9qMvZW4Lkzud2uksgE6FwPD1ImcVhhkqTxMVbB3DW6svjaRKsMrj//7qLU M4XI+Twn8+xgeaQj0pPpERPHQqlEiLtES3D9sx2fHvWfdx7ZhAODZbewufZUy7gpaxae+DtINizb/ h4lR/i+Q==; Received: from [2601:1c0:6280:3f0:897c:6038:c71d:ecac] by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1jg8gB-0002Ib-Ai; Tue, 02 Jun 2020 15:18:15 +0000 Subject: Re: linux-next: Tree for Jun 2 (x86/xen) To: Stephen Rothwell , Linux Next Mailing List References: <20200602203737.6eec243f@canb.auug.org.au> From: Randy Dunlap Message-ID: <8bc4e983-7563-20f2-2c15-3cea055ae264@infradead.org> Date: Tue, 2 Jun 2020 08:18:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200602203737.6eec243f@canb.auug.org.au> Content-Type: multipart/mixed; boundary="------------B398FCF96F2D103F53958B07" Content-Language: en-US X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , xen-devel , Boris Ostrovsky , Stefano Stabellini , Linux Kernel Mailing List Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This is a multi-part message in MIME format. --------------B398FCF96F2D103F53958B07 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 6/2/20 3:37 AM, Stephen Rothwell wrote: > Hi all, > > News: The merge window has opened, so please do *not* add v5.9 material > to your linux-next included branches until after v5.8-rc1 has been > released. > > Changes since 20200529: > on x86_64: CC arch/x86/xen/suspend_hvm.o In file included from ../include/xen/interface/hvm/params.h:24:0, from ../include/xen/hvm.h:6, from ../arch/x86/xen/suspend_hvm.c:5: ../include/xen/interface/hvm/hvm_op.h:29:5: error: unknown type name domid_t domid_t domid; /* IN */ ^~~~~~~ ../include/xen/interface/hvm/hvm_op.h:33:1: warning: data definition has no type or storage class DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_param); ^~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/xen/interface/hvm/hvm_op.h:33:1: error: type defaults to int in declaration of DEFINE_GUEST_HANDLE_STRUCT [-Werror=implicit-int] ../include/xen/interface/hvm/hvm_op.h:33:1: warning: parameter names (without types) in function declaration ../include/xen/interface/hvm/hvm_op.h:39:5: error: unknown type name domid_t domid_t domid; ^~~~~~~ ../include/xen/interface/hvm/hvm_op.h:44:1: warning: data definition has no type or storage class DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_pagetable_dying_t); ^~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/xen/interface/hvm/hvm_op.h:44:1: error: type defaults to int in declaration of DEFINE_GUEST_HANDLE_STRUCT [-Werror=implicit-int] ../include/xen/interface/hvm/hvm_op.h:56:5: error: unknown type name domid_t domid_t domid; ^~~~~~~ ../include/xen/interface/hvm/hvm_op.h:63:1: warning: data definition has no type or storage class DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_get_mem_type); ^~~~~~~~~~~~~~~~~~~~~~~~~~ ../include/xen/interface/hvm/hvm_op.h:63:1: error: type defaults to int in declaration of DEFINE_GUEST_HANDLE_STRUCT [-Werror=implicit-int] ../include/xen/interface/hvm/hvm_op.h:63:1: warning: parameter names (without types) in function declaration Full randconfig file is attached. -- ~Randy Reported-by: Randy Dunlap --------------B398FCF96F2D103F53958B07 Content-Type: text/plain; charset=UTF-8; name="config-r3046" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="config-r3046" # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 5.7.0 Kernel Configuration # CONFIG_CC_VERSION_TEXT="gcc (SUSE Linux) 7.5.0" CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=70500 CONFIG_LD_VERSION=232000000 CONFIG_CLANG_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_CAN_LINK_STATIC=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_ASM_INLINE=y CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_TABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_INIT="" CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_WATCH_QUEUE is not set CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_USELIB=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_GENERIC_IRQ_INJECTION=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_GENERIC_MSI_IRQ_DOMAIN=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_IRQ_DEBUGFS=y # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # end of Timers subsystem CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_HAVE_SCHED_AVG_IRQ=y # CONFIG_SCHED_THERMAL_PRESSURE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_PSI is not set # end of CPU/Task time and stats accounting # CONFIG_CPU_ISOLATION is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_RCU_EXPERT is not set CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU_GENERIC=y CONFIG_TASKS_RUDE_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y # end of RCU Subsystem CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_IKHEADERS=m CONFIG_LOG_BUF_SHIFT=17 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # CONFIG_UCLAMP_TASK is not set # end of Scheduler features CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_CC_HAS_INT128=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_KMEM=y # CONFIG_BLK_CGROUP is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CFS_BANDWIDTH is not set CONFIG_RT_GROUP_SCHED=y CONFIG_CGROUP_PIDS=y CONFIG_CGROUP_RDMA=y # CONFIG_CGROUP_FREEZER is not set CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set # CONFIG_CGROUP_DEVICE is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_CGROUP_PERF=y # CONFIG_CGROUP_BPF is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_TIME_NS=y # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set CONFIG_PID_NS=y CONFIG_CHECKPOINT_RESTORE=y CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set CONFIG_RD_LZMA=y CONFIG_RD_XZ=y # CONFIG_RD_LZO is not set CONFIG_RD_LZ4=y CONFIG_BOOT_CONFIG=y CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y # CONFIG_EXPERT is not set CONFIG_UID16=y CONFIG_MULTIUSER=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y CONFIG_FHANDLE=y CONFIG_POSIX_TIMERS=y CONFIG_PRINTK=y CONFIG_PRINTK_NMI=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_FUTEX_PI=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_IO_URING=y CONFIG_ADVISE_SYSCALLS=y CONFIG_MEMBARRIER=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y CONFIG_KALLSYMS_BASE_RELATIVE=y CONFIG_BPF_SYSCALL=y CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y # CONFIG_USERFAULTFD is not set CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y CONFIG_RSEQ=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # end of Kernel Performance Events And Counters CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set CONFIG_SLAB_MERGE_DEFAULT=y # CONFIG_SLAB_FREELIST_RANDOM is not set # CONFIG_SHUFFLE_PAGE_ALLOCATOR is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y # end of General setup CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MIN=28 CONFIG_ARCH_MMAP_RND_BITS_MAX=32 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16 CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_FILTER_PGPROT=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_KASAN_SHADOW_OFFSET=0xdffffc0000000000 CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DYNAMIC_PHYSICAL_MASK=y CONFIG_PGTABLE_LEVELS=4 CONFIG_CC_HAS_SANE_STACKPROTECTOR=y # # Processor type and features # CONFIG_ZONE_DMA=y CONFIG_SMP=y CONFIG_X86_FEATURE_NAMES=y CONFIG_X86_X2APIC=y # CONFIG_X86_MPPARSE is not set # CONFIG_GOLDFISH is not set # CONFIG_RETPOLINE is not set # CONFIG_X86_CPU_RESCTRL is not set CONFIG_X86_EXTENDED_PLATFORM=y CONFIG_X86_VSMP=y CONFIG_X86_GOLDFISH=y # CONFIG_X86_INTEL_LPSS is not set CONFIG_X86_AMD_PLATFORM_DEVICE=y CONFIG_IOSF_MBI=y CONFIG_IOSF_MBI_DEBUG=y CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y # CONFIG_SCHED_OMIT_FRAME_POINTER is not set CONFIG_HYPERVISOR_GUEST=y CONFIG_PARAVIRT=y CONFIG_PARAVIRT_XXL=y CONFIG_PARAVIRT_SPINLOCKS=y CONFIG_X86_HV_CALLBACK_VECTOR=y CONFIG_XEN=y CONFIG_XEN_PV=y CONFIG_XEN_PV_SMP=y # CONFIG_XEN_DOM0 is not set CONFIG_XEN_PVHVM=y CONFIG_XEN_PVHVM_SMP=y # CONFIG_XEN_512GB is not set CONFIG_XEN_SAVE_RESTORE=y CONFIG_XEN_DEBUG_FS=y # CONFIG_XEN_PVH is not set CONFIG_KVM_GUEST=y CONFIG_ARCH_CPUIDLE_HALTPOLL=y CONFIG_PVH=y CONFIG_PARAVIRT_TIME_ACCOUNTING=y CONFIG_PARAVIRT_CLOCK=y # CONFIG_JAILHOUSE_GUEST is not set CONFIG_ACRN_GUEST=y # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_MATOM is not set CONFIG_GENERIC_CPU=y CONFIG_X86_INTERNODE_CACHE_SHIFT=12 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_IA32_FEAT_CTL=y CONFIG_X86_VMX_FEATURE_NAMES=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_HYGON=y CONFIG_CPU_SUP_CENTAUR=y CONFIG_CPU_SUP_ZHAOXIN=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y # CONFIG_GART_IOMMU is not set CONFIG_NR_CPUS_RANGE_BEGIN=2 CONFIG_NR_CPUS_RANGE_END=512 CONFIG_NR_CPUS_DEFAULT=64 CONFIG_NR_CPUS=64 CONFIG_SCHED_SMT=y # CONFIG_SCHED_MC is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set CONFIG_X86_MCE=y # CONFIG_X86_MCELOG_LEGACY is not set CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_X86_MCE_THRESHOLD=y # CONFIG_X86_MCE_INJECT is not set CONFIG_X86_THERMAL_VECTOR=y # # Performance monitoring # # CONFIG_PERF_EVENTS_INTEL_UNCORE is not set CONFIG_PERF_EVENTS_INTEL_RAPL=m CONFIG_PERF_EVENTS_INTEL_CSTATE=y CONFIG_PERF_EVENTS_AMD_POWER=y # end of Performance monitoring CONFIG_X86_16BIT=y CONFIG_X86_ESPFIX64=y CONFIG_X86_VSYSCALL_EMULATION=y # CONFIG_X86_IOPL_IOPERM is not set CONFIG_I8K=m # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # CONFIG_X86_5LEVEL is not set CONFIG_X86_DIRECT_GBPAGES=y # CONFIG_X86_CPA_STATISTICS is not set CONFIG_AMD_MEM_ENCRYPT=y CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=y # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y # CONFIG_ARCH_MEMORY_PROBE is not set CONFIG_ARCH_PROC_KCORE_TEXT=y CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000 CONFIG_X86_CHECK_BIOS_CORRUPTION=y # CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set CONFIG_X86_RESERVE_LOW=64 CONFIG_MTRR=y # CONFIG_MTRR_SANITIZER is not set CONFIG_X86_PAT=y CONFIG_ARCH_USES_PG_UNCACHED=y CONFIG_ARCH_RANDOM=y CONFIG_X86_SMAP=y CONFIG_X86_UMIP=y # CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS is not set # CONFIG_X86_INTEL_TSX_MODE_OFF is not set # CONFIG_X86_INTEL_TSX_MODE_ON is not set CONFIG_X86_INTEL_TSX_MODE_AUTO=y # CONFIG_EFI is not set # CONFIG_SECCOMP is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_SCHED_HRTICK=y # CONFIG_KEXEC is not set CONFIG_KEXEC_FILE=y CONFIG_ARCH_HAS_KEXEC_PURGATORY=y # CONFIG_KEXEC_SIG is not set CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x1000000 CONFIG_RELOCATABLE=y # CONFIG_RANDOMIZE_BASE is not set CONFIG_PHYSICAL_ALIGN=0x200000 CONFIG_HOTPLUG_CPU=y CONFIG_BOOTPARAM_HOTPLUG_CPU0=y CONFIG_DEBUG_HOTPLUG_CPU0=y # CONFIG_COMPAT_VDSO is not set # CONFIG_LEGACY_VSYSCALL_EMULATE is not set # CONFIG_LEGACY_VSYSCALL_XONLY is not set CONFIG_LEGACY_VSYSCALL_NONE=y CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="" CONFIG_MODIFY_LDT_SYSCALL=y CONFIG_HAVE_LIVEPATCH=y # end of Processor type and features CONFIG_ARCH_HAS_ADD_PAGES=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y CONFIG_ARCH_ENABLE_THP_MIGRATION=y # # Power management and ACPI options # # CONFIG_SUSPEND is not set CONFIG_HIBERNATE_CALLBACKS=y CONFIG_PM_SLEEP=y CONFIG_PM_SLEEP_SMP=y CONFIG_PM_AUTOSLEEP=y CONFIG_PM_WAKELOCKS=y CONFIG_PM_WAKELOCKS_LIMIT=100 CONFIG_PM_WAKELOCKS_GC=y CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_PM_ADVANCED_DEBUG=y CONFIG_PM_SLEEP_DEBUG=y CONFIG_PM_TRACE=y CONFIG_PM_TRACE_RTC=y CONFIG_PM_CLK=y CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y CONFIG_ENERGY_MODEL=y CONFIG_ARCH_SUPPORTS_ACPI=y CONFIG_ACPI=y CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y CONFIG_ACPI_DEBUGGER=y CONFIG_ACPI_DEBUGGER_USER=y CONFIG_ACPI_SPCR_TABLE=y CONFIG_ACPI_LPIT=y CONFIG_ACPI_PROCFS_POWER=y # CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not set # CONFIG_ACPI_EC_DEBUGFS is not set CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_TINY_POWER_BUTTON=m CONFIG_ACPI_TINY_POWER_BUTTON_SIGNAL=38 CONFIG_ACPI_FAN=y # CONFIG_ACPI_TAD is not set # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_CPU_FREQ_PSS=y CONFIG_ACPI_PROCESSOR_CSTATE=y CONFIG_ACPI_PROCESSOR_IDLE=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_PROCESSOR_AGGREGATOR=y # CONFIG_ACPI_THERMAL is not set CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y CONFIG_ACPI_TABLE_UPGRADE=y CONFIG_ACPI_DEBUG=y # CONFIG_ACPI_PCI_SLOT is not set CONFIG_ACPI_CONTAINER=y # CONFIG_ACPI_HOTPLUG_MEMORY is not set CONFIG_ACPI_HOTPLUG_IOAPIC=y CONFIG_ACPI_SBS=m CONFIG_ACPI_HED=y CONFIG_ACPI_CUSTOM_METHOD=y CONFIG_HAVE_ACPI_APEI=y CONFIG_HAVE_ACPI_APEI_NMI=y # CONFIG_ACPI_APEI is not set # CONFIG_DPTF_POWER is not set CONFIG_PMIC_OPREGION=y # CONFIG_XPOWER_PMIC_OPREGION is not set CONFIG_CHT_DC_TI_PMIC_OPREGION=y # CONFIG_ACPI_CONFIGFS is not set CONFIG_X86_PM_TIMER=y CONFIG_SFI=y # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_ATTR_SET=y CONFIG_CPU_FREQ_GOV_COMMON=y CONFIG_CPU_FREQ_STAT=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y # # CPU frequency scaling drivers # # CONFIG_CPUFREQ_DT is not set CONFIG_X86_INTEL_PSTATE=y CONFIG_X86_PCC_CPUFREQ=y # CONFIG_X86_ACPI_CPUFREQ is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set CONFIG_X86_P4_CLOCKMOD=m # # shared options # CONFIG_X86_SPEEDSTEP_LIB=m # end of CPU Frequency scaling # # CPU Idle # CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y CONFIG_CPU_IDLE_GOV_TEO=y # CONFIG_CPU_IDLE_GOV_HALTPOLL is not set # CONFIG_HALTPOLL_CPUIDLE is not set # end of CPU Idle # CONFIG_INTEL_IDLE is not set # end of Power management and ACPI options # # Bus options (PCI etc.) # CONFIG_PCI_DIRECT=y # CONFIG_PCI_MMCONFIG is not set CONFIG_PCI_XEN=y CONFIG_ISA_DMA_API=y CONFIG_AMD_NB=y CONFIG_X86_SYSFB=y # end of Bus options (PCI etc.) # # Binary Emulations # CONFIG_IA32_EMULATION=y CONFIG_X86_X32=y CONFIG_COMPAT_32=y CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y # end of Binary Emulations # # Firmware Drivers # CONFIG_EDD=y CONFIG_EDD_OFF=y CONFIG_FIRMWARE_MEMMAP=y CONFIG_DMIID=y # CONFIG_DMI_SYSFS is not set CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y CONFIG_FW_CFG_SYSFS=y CONFIG_FW_CFG_SYSFS_CMDLINE=y # CONFIG_GOOGLE_FIRMWARE is not set CONFIG_EFI_EARLYCON=y # # Tegra firmware driver # # end of Tegra firmware driver # end of Firmware Drivers CONFIG_HAVE_KVM=y # CONFIG_VIRTUALIZATION is not set CONFIG_AS_AVX512=y CONFIG_AS_SHA1_NI=y CONFIG_AS_SHA256_NI=y CONFIG_AS_TPAUSE=y # # General architecture-dependent options # CONFIG_CRASH_CORE=y CONFIG_KEXEC_CORE=y CONFIG_HOTPLUG_SMT=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y # CONFIG_KPROBES is not set CONFIG_JUMP_LABEL=y # CONFIG_STATIC_KEYS_SELFTEST is not set CONFIG_UPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_KPROBES_ON_FTRACE=y CONFIG_HAVE_FUNCTION_ERROR_INJECTION=y CONFIG_HAVE_NMI=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_ARCH_HAS_FORTIFY_SOURCE=y CONFIG_ARCH_HAS_SET_MEMORY=y CONFIG_ARCH_HAS_SET_DIRECT_MAP=y CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y CONFIG_HAVE_ASM_MODVERSIONS=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_RSEQ=y CONFIG_HAVE_FUNCTION_ARG_ACCESS_API=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_HARDLOCKUP_DETECTOR_PERF=y CONFIG_HAVE_PERF_REGS=y CONFIG_HAVE_PERF_USER_STACK_DUMP=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_HAVE_ARCH_JUMP_LABEL_RELATIVE=y CONFIG_MMU_GATHER_TABLE_FREE=y CONFIG_MMU_GATHER_RCU_TABLE_FREE=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_HAVE_CMPXCHG_LOCAL=y CONFIG_HAVE_CMPXCHG_DOUBLE=y CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y CONFIG_HAVE_ARCH_STACKLEAK=y CONFIG_HAVE_STACKPROTECTOR=y CONFIG_CC_HAS_STACKPROTECTOR_NONE=y CONFIG_STACKPROTECTOR=y # CONFIG_STACKPROTECTOR_STRONG is not set CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y CONFIG_HAVE_CONTEXT_TRACKING=y CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y CONFIG_HAVE_MOVE_PMD=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y CONFIG_HAVE_ARCH_HUGE_VMAP=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_HAVE_ARCH_SOFT_DIRTY=y CONFIG_HAVE_MOD_ARCH_SPECIFIC=y CONFIG_MODULES_USE_ELF_RELA=y CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y CONFIG_ARCH_HAS_ELF_RANDOMIZE=y CONFIG_HAVE_ARCH_MMAP_RND_BITS=y CONFIG_HAVE_EXIT_THREAD=y CONFIG_ARCH_MMAP_RND_BITS=28 CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES=y CONFIG_HAVE_COPY_THREAD_TLS=y CONFIG_HAVE_STACK_VALIDATION=y CONFIG_HAVE_RELIABLE_STACKTRACE=y CONFIG_ISA_BUS_API=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_COMPAT_OLD_SIGACTION=y CONFIG_COMPAT_32BIT_TIME=y CONFIG_HAVE_ARCH_VMAP_STACK=y # CONFIG_VMAP_STACK is not set CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y CONFIG_STRICT_KERNEL_RWX=y CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y CONFIG_STRICT_MODULE_RWX=y CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y CONFIG_ARCH_USE_MEMREMAP_PROT=y CONFIG_LOCK_EVENT_COUNTS=y CONFIG_ARCH_HAS_MEM_ENCRYPT=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y # end of GCOV-based kernel profiling CONFIG_HAVE_GCC_PLUGINS=y # end of General architecture-dependent options CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_ASM_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_MODULE_SIG is not set CONFIG_MODULE_COMPRESS=y CONFIG_MODULE_COMPRESS_GZIP=y # CONFIG_MODULE_COMPRESS_XZ is not set # CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is not set CONFIG_UNUSED_SYMBOLS=y CONFIG_MODULES_TREE_LOOKUP=y CONFIG_BLOCK=y CONFIG_BLK_SCSI_REQUEST=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_BSGLIB=y # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLK_DEV_ZONED=y # CONFIG_BLK_CMDLINE_PARSER is not set # CONFIG_BLK_WBT is not set # CONFIG_BLK_DEBUG_FS is not set # CONFIG_BLK_SED_OPAL is not set CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_EFI_PARTITION=y # end of Partition Types CONFIG_BLOCK_COMPAT=y CONFIG_BLK_MQ_PCI=y CONFIG_BLK_MQ_VIRTIO=y CONFIG_BLK_PM=y # # IO Schedulers # CONFIG_MQ_IOSCHED_DEADLINE=y # CONFIG_MQ_IOSCHED_KYBER is not set # CONFIG_IOSCHED_BFQ is not set # end of IO Schedulers CONFIG_PADATA=y CONFIG_ASN1=y CONFIG_INLINE_SPIN_UNLOCK_IRQ=y CONFIG_INLINE_READ_UNLOCK=y CONFIG_INLINE_READ_UNLOCK_IRQ=y CONFIG_INLINE_WRITE_UNLOCK=y CONFIG_INLINE_WRITE_UNLOCK_IRQ=y CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y CONFIG_MUTEX_SPIN_ON_OWNER=y CONFIG_RWSEM_SPIN_ON_OWNER=y CONFIG_LOCK_SPIN_ON_OWNER=y CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y CONFIG_QUEUED_SPINLOCKS=y CONFIG_ARCH_USE_QUEUED_RWLOCKS=y CONFIG_QUEUED_RWLOCKS=y CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE=y CONFIG_ARCH_HAS_SYNC_CORE_BEFORE_USERMODE=y CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y CONFIG_FREEZER=y # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_ELFCORE=y CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y # CONFIG_BINFMT_SCRIPT is not set # CONFIG_BINFMT_MISC is not set CONFIG_COREDUMP=y # end of Executable file formats # # Memory Management options # CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_HAVE_FAST_GUP=y CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTPLUG_SPARSE=y CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y # CONFIG_MEMORY_HOTREMOVE is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_COMPACTION=y CONFIG_PAGE_REPORTING=y CONFIG_MIGRATION=y CONFIG_PHYS_ADDR_T_64BIT=y # CONFIG_BOUNCE is not set CONFIG_VIRT_TO_BUS=y CONFIG_MMU_NOTIFIER=y CONFIG_KSM=y CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y # CONFIG_MEMORY_FAILURE is not set CONFIG_TRANSPARENT_HUGEPAGE=y # CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y CONFIG_ARCH_WANTS_THP_SWAP=y # CONFIG_CLEANCACHE is not set # CONFIG_CMA is not set CONFIG_MEM_SOFT_DIRTY=y # CONFIG_ZPOOL is not set CONFIG_ZBUD=m # CONFIG_ZSMALLOC is not set CONFIG_GENERIC_EARLY_IOREMAP=y # CONFIG_DEFERRED_STRUCT_PAGE_INIT is not set # CONFIG_IDLE_PAGE_TRACKING is not set CONFIG_ARCH_HAS_PTE_DEVMAP=y CONFIG_FRAME_VECTOR=y CONFIG_PERCPU_STATS=y CONFIG_GUP_BENCHMARK=y CONFIG_READ_ONLY_THP_FOR_FS=y CONFIG_ARCH_HAS_PTE_SPECIAL=y # end of Memory Management options # CONFIG_NET is not set CONFIG_HAVE_EBPF_JIT=y # # Device Drivers # CONFIG_HAVE_EISA=y # CONFIG_EISA is not set CONFIG_HAVE_PCI=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_PCIEAER=y CONFIG_PCIEAER_INJECT=m CONFIG_PCIE_ECRC=y CONFIG_PCIEASPM=y CONFIG_PCIEASPM_DEFAULT=y # CONFIG_PCIEASPM_POWERSAVE is not set # CONFIG_PCIEASPM_POWER_SUPERSAVE is not set # CONFIG_PCIEASPM_PERFORMANCE is not set CONFIG_PCIE_PME=y # CONFIG_PCIE_DPC is not set CONFIG_PCIE_PTM=y CONFIG_PCIE_BW=y CONFIG_PCI_MSI=y CONFIG_PCI_MSI_IRQ_DOMAIN=y CONFIG_PCI_QUIRKS=y # CONFIG_PCI_REALLOC_ENABLE_AUTO is not set # CONFIG_PCI_STUB is not set # CONFIG_PCI_PF_STUB is not set CONFIG_XEN_PCIDEV_FRONTEND=m CONFIG_PCI_ATS=y CONFIG_PCI_ECAM=y CONFIG_PCI_LOCKLESS_CONFIG=y CONFIG_PCI_IOV=y CONFIG_PCI_PRI=y CONFIG_PCI_PASID=y CONFIG_PCI_LABEL=y # CONFIG_PCI_HYPERV is not set CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_ACPI is not set # CONFIG_HOTPLUG_PCI_CPCI is not set CONFIG_HOTPLUG_PCI_SHPC=y # # PCI controller drivers # # CONFIG_PCI_FTPCI100 is not set CONFIG_PCI_HOST_COMMON=y CONFIG_PCI_HOST_GENERIC=y # CONFIG_PCIE_XILINX is not set CONFIG_VMD=m CONFIG_PCI_HYPERV_INTERFACE=y # # DesignWare PCI Core Support # CONFIG_PCIE_DW=y CONFIG_PCIE_DW_HOST=y CONFIG_PCIE_DW_EP=y CONFIG_PCIE_DW_PLAT=y # CONFIG_PCIE_DW_PLAT_HOST is not set CONFIG_PCIE_DW_PLAT_EP=y CONFIG_PCIE_INTEL_GW=y CONFIG_PCI_MESON=y # end of DesignWare PCI Core Support # # Mobiveil PCIe Core Support # # end of Mobiveil PCIe Core Support # # Cadence PCIe controllers support # CONFIG_PCIE_CADENCE=y CONFIG_PCIE_CADENCE_HOST=y CONFIG_PCIE_CADENCE_EP=y CONFIG_PCIE_CADENCE_PLAT=y CONFIG_PCIE_CADENCE_PLAT_HOST=y CONFIG_PCIE_CADENCE_PLAT_EP=y # end of Cadence PCIe controllers support # end of PCI controller drivers # # PCI Endpoint # CONFIG_PCI_ENDPOINT=y # CONFIG_PCI_ENDPOINT_CONFIGFS is not set # CONFIG_PCI_EPF_TEST is not set # end of PCI Endpoint # # PCI switch controller drivers # CONFIG_PCI_SW_SWITCHTEC=y # end of PCI switch controller drivers # CONFIG_PCCARD is not set CONFIG_RAPIDIO=m CONFIG_RAPIDIO_TSI721=m CONFIG_RAPIDIO_DISC_TIMEOUT=30 # CONFIG_RAPIDIO_ENABLE_RX_TX_PORTS is not set CONFIG_RAPIDIO_DMA_ENGINE=y CONFIG_RAPIDIO_DEBUG=y CONFIG_RAPIDIO_ENUM_BASIC=m # CONFIG_RAPIDIO_CHMAN is not set CONFIG_RAPIDIO_MPORT_CDEV=m # # RapidIO Switch drivers # CONFIG_RAPIDIO_TSI57X=m # CONFIG_RAPIDIO_CPS_XX is not set CONFIG_RAPIDIO_TSI568=m # CONFIG_RAPIDIO_CPS_GEN2 is not set # CONFIG_RAPIDIO_RXS_GEN3 is not set # end of RapidIO Switch drivers # # Generic Driver Options # # CONFIG_UEVENT_HELPER is not set CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y # # Firmware loader # CONFIG_FW_LOADER=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_EXTRA_FIRMWARE="" CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set CONFIG_FW_LOADER_COMPRESS=y CONFIG_FW_CACHE=y # end of Firmware loader CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_TEST_ASYNC_DRIVER_PROBE=m CONFIG_SYS_HYPERVISOR=y CONFIG_GENERIC_CPU_AUTOPROBE=y CONFIG_GENERIC_CPU_VULNERABILITIES=y CONFIG_REGMAP=y CONFIG_REGMAP_I2C=m CONFIG_REGMAP_MMIO=y CONFIG_REGMAP_IRQ=y CONFIG_REGMAP_SOUNDWIRE=m CONFIG_REGMAP_SCCB=m CONFIG_DMA_SHARED_BUFFER=y CONFIG_DMA_FENCE_TRACE=y # end of Generic Driver Options # # Bus devices # # CONFIG_SIMPLE_PM_BUS is not set # CONFIG_MHI_BUS is not set # end of Bus devices # CONFIG_GNSS is not set CONFIG_MTD=y # CONFIG_MTD_TESTS is not set # # Partition parsers # CONFIG_MTD_AR7_PARTS=m # CONFIG_MTD_CMDLINE_PARTS is not set # CONFIG_MTD_OF_PARTS is not set CONFIG_MTD_REDBOOT_PARTS=m CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1 # CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set # CONFIG_MTD_REDBOOT_PARTS_READONLY is not set # end of Partition parsers # # User Modules And Translation Layers # CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y CONFIG_FTL=y # CONFIG_NFTL is not set CONFIG_INFTL=y CONFIG_RFD_FTL=m CONFIG_SSFDC=m CONFIG_SM_FTL=y # CONFIG_MTD_OOPS is not set CONFIG_MTD_PARTITIONED_MASTER=y # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set CONFIG_MTD_JEDECPROBE=y CONFIG_MTD_GEN_PROBE=y CONFIG_MTD_CFI_ADV_OPTIONS=y # CONFIG_MTD_CFI_NOSWAP is not set # CONFIG_MTD_CFI_BE_BYTE_SWAP is not set CONFIG_MTD_CFI_LE_BYTE_SWAP=y # CONFIG_MTD_CFI_GEOMETRY is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y CONFIG_MTD_OTP=y # CONFIG_MTD_CFI_INTELEXT is not set # CONFIG_MTD_CFI_AMDSTD is not set # CONFIG_MTD_CFI_STAA is not set CONFIG_MTD_CFI_UTIL=y CONFIG_MTD_RAM=m # CONFIG_MTD_ROM is not set CONFIG_MTD_ABSENT=y # end of RAM/ROM/Flash chip drivers # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set CONFIG_MTD_PHYSMAP=y # CONFIG_MTD_PHYSMAP_COMPAT is not set # CONFIG_MTD_PHYSMAP_OF is not set # CONFIG_MTD_AMD76XROM is not set CONFIG_MTD_ICHXROM=y CONFIG_MTD_ESB2ROM=y # CONFIG_MTD_CK804XROM is not set CONFIG_MTD_SCB2_FLASH=y CONFIG_MTD_NETtel=y CONFIG_MTD_L440GX=y CONFIG_MTD_INTEL_VR_NOR=m CONFIG_MTD_PLATRAM=m # end of Mapping drivers for chip access # # Self-contained MTD device drivers # CONFIG_MTD_PMC551=y # CONFIG_MTD_PMC551_BUGFIX is not set CONFIG_MTD_PMC551_DEBUG=y CONFIG_MTD_SLRAM=y # CONFIG_MTD_PHRAM is not set CONFIG_MTD_MTDRAM=y CONFIG_MTDRAM_TOTAL_SIZE=4096 CONFIG_MTDRAM_ERASE_SIZE=128 # CONFIG_MTD_BLOCK2MTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOCG3 is not set # end of Self-contained MTD device drivers CONFIG_MTD_ONENAND=y # CONFIG_MTD_ONENAND_VERIFY_WRITE is not set # CONFIG_MTD_ONENAND_GENERIC is not set # CONFIG_MTD_ONENAND_OTP is not set # CONFIG_MTD_ONENAND_2X_PROGRAM is not set CONFIG_MTD_NAND_ECC_SW_HAMMING=y CONFIG_MTD_NAND_ECC_SW_HAMMING_SMC=y # CONFIG_MTD_RAW_NAND is not set # # LPDDR & LPDDR2 PCM memory drivers # # CONFIG_MTD_LPDDR is not set # end of LPDDR & LPDDR2 PCM memory drivers # CONFIG_MTD_UBI is not set # CONFIG_MTD_HYPERBUS is not set CONFIG_DTC=y CONFIG_OF=y # CONFIG_OF_UNITTEST is not set CONFIG_OF_FLATTREE=y CONFIG_OF_EARLY_FLATTREE=y CONFIG_OF_KOBJ=y CONFIG_OF_ADDRESS=y CONFIG_OF_IRQ=y CONFIG_OF_RESERVED_MEM=y # CONFIG_OF_OVERLAY is not set CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y # CONFIG_PARPORT is not set CONFIG_PNP=y # CONFIG_PNP_DEBUG_MESSAGES is not set # # Protocols # CONFIG_PNPACPI=y # CONFIG_BLK_DEV is not set # # NVME Support # CONFIG_NVME_CORE=y CONFIG_BLK_DEV_NVME=y CONFIG_NVME_MULTIPATH=y # CONFIG_NVME_HWMON is not set # CONFIG_NVME_FC is not set # CONFIG_NVME_TARGET is not set # end of NVME Support # # Misc devices # # CONFIG_AD525X_DPOT is not set CONFIG_DUMMY_IRQ=m CONFIG_IBM_ASM=m # CONFIG_PHANTOM is not set CONFIG_TIFM_CORE=y CONFIG_TIFM_7XX1=y CONFIG_ICS932S401=m CONFIG_ENCLOSURE_SERVICES=m CONFIG_HP_ILO=y # CONFIG_APDS9802ALS is not set # CONFIG_ISL29003 is not set # CONFIG_ISL29020 is not set CONFIG_SENSORS_TSL2550=m CONFIG_SENSORS_BH1770=m CONFIG_SENSORS_APDS990X=m # CONFIG_HMC6352 is not set CONFIG_DS1682=m # CONFIG_VMWARE_BALLOON is not set CONFIG_SRAM=y CONFIG_PCI_ENDPOINT_TEST=y # CONFIG_XILINX_SDFEC is not set CONFIG_MISC_RTSX=y # CONFIG_PVPANIC is not set CONFIG_C2PORT=y CONFIG_C2PORT_DURAMAR_2150=m # # EEPROM support # CONFIG_EEPROM_AT24=m CONFIG_EEPROM_LEGACY=m CONFIG_EEPROM_MAX6875=m # CONFIG_EEPROM_93CX6 is not set # CONFIG_EEPROM_IDT_89HPESX is not set CONFIG_EEPROM_EE1004=m # end of EEPROM support CONFIG_CB710_CORE=y CONFIG_CB710_DEBUG=y CONFIG_CB710_DEBUG_ASSUMPTIONS=y # # Texas Instruments shared transport line discipline # # end of Texas Instruments shared transport line discipline # CONFIG_SENSORS_LIS3_I2C is not set # # Altera FPGA firmware download module (requires I2C) # # CONFIG_ALTERA_STAPL is not set CONFIG_INTEL_MEI=y CONFIG_INTEL_MEI_ME=m CONFIG_INTEL_MEI_TXE=y CONFIG_VMWARE_VMCI=m # # Intel MIC & related support # CONFIG_INTEL_MIC_BUS=y # CONFIG_SCIF_BUS is not set CONFIG_VOP_BUS=y CONFIG_VOP=y # end of Intel MIC & related support CONFIG_GENWQE=y CONFIG_GENWQE_PLATFORM_ERROR_RECOVERY=0 CONFIG_ECHO=m CONFIG_MISC_ALCOR_PCI=y CONFIG_MISC_RTSX_PCI=y CONFIG_HABANA_AI=y CONFIG_UACCE=y # end of Misc devices CONFIG_HAVE_IDE=y CONFIG_IDE=y # # Please see Documentation/ide/ide.rst for help/info on IDE drives # CONFIG_IDE_XFER_MODE=y CONFIG_IDE_TIMINGS=y # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_IDE_GD is not set # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEACPI=y # CONFIG_IDE_TASK_IOCTL is not set # CONFIG_IDE_PROC_FS is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=m CONFIG_BLK_DEV_PLATFORM=y CONFIG_BLK_DEV_CMD640=m CONFIG_BLK_DEV_CMD640_ENHANCED=y CONFIG_BLK_DEV_IDEPNP=m CONFIG_BLK_DEV_IDEDMA_SFF=y # # PCI IDE chipsets support # CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_PCIBUS_ORDER=y CONFIG_BLK_DEV_OFFBOARD=y # CONFIG_BLK_DEV_GENERIC is not set CONFIG_BLK_DEV_OPTI621=y # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_BLK_DEV_AEC62XX=m CONFIG_BLK_DEV_ALI15X3=y CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_ATIIXP=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_TRIFLEX=m CONFIG_BLK_DEV_HPT366=y # CONFIG_BLK_DEV_JMICRON is not set CONFIG_BLK_DEV_PIIX=m CONFIG_BLK_DEV_IT8172=y CONFIG_BLK_DEV_IT8213=m # CONFIG_BLK_DEV_IT821X is not set CONFIG_BLK_DEV_NS87415=y # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set CONFIG_BLK_DEV_SIS5513=y CONFIG_BLK_DEV_SLC90E66=y CONFIG_BLK_DEV_TRM290=m # CONFIG_BLK_DEV_VIA82CXXX is not set CONFIG_BLK_DEV_TC86C001=y CONFIG_BLK_DEV_IDEDMA=y # # SCSI device support # CONFIG_SCSI_MOD=m # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=m CONFIG_SCSI_DMA=y # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_ENCLOSURE=m CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set CONFIG_SCSI_SCAN_ASYNC=y # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m # CONFIG_SCSI_SAS_ATA is not set # CONFIG_SCSI_SAS_HOST_SMP is not set # CONFIG_SCSI_SRP_ATTRS is not set # end of SCSI Transports # CONFIG_SCSI_LOWLEVEL is not set CONFIG_SCSI_DH=y CONFIG_SCSI_DH_RDAC=m # CONFIG_SCSI_DH_HP_SW is not set # CONFIG_SCSI_DH_EMC is not set # CONFIG_SCSI_DH_ALUA is not set # end of SCSI device support CONFIG_ATA=m CONFIG_SATA_HOST=y CONFIG_PATA_TIMINGS=y # CONFIG_ATA_VERBOSE_ERROR is not set CONFIG_ATA_FORCE=y # CONFIG_ATA_ACPI is not set CONFIG_SATA_PMP=y # # Controllers with non-SFF native interface # # CONFIG_SATA_AHCI is not set CONFIG_SATA_AHCI_PLATFORM=m CONFIG_AHCI_CEVA=m CONFIG_AHCI_QORIQ=m CONFIG_SATA_INIC162X=m CONFIG_SATA_ACARD_AHCI=m CONFIG_SATA_SIL24=m CONFIG_ATA_SFF=y # # SFF controllers with custom DMA interface # CONFIG_PDC_ADMA=m CONFIG_SATA_QSTOR=m # CONFIG_SATA_SX4 is not set CONFIG_ATA_BMDMA=y # # SATA SFF controllers with BMDMA # # CONFIG_ATA_PIIX is not set # CONFIG_SATA_DWC is not set CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m # CONFIG_SATA_SIL is not set CONFIG_SATA_SIS=m CONFIG_SATA_SVW=m CONFIG_SATA_ULI=m # CONFIG_SATA_VIA is not set CONFIG_SATA_VITESSE=m # # PATA SFF controllers with BMDMA # # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set CONFIG_PATA_ARTOP=m # CONFIG_PATA_ATIIXP is not set CONFIG_PATA_ATP867X=m # CONFIG_PATA_CMD64X is not set CONFIG_PATA_CYPRESS=m # CONFIG_PATA_EFAR is not set CONFIG_PATA_HPT366=m CONFIG_PATA_HPT37X=m CONFIG_PATA_HPT3X2N=m CONFIG_PATA_HPT3X3=m # CONFIG_PATA_HPT3X3_DMA is not set CONFIG_PATA_IT8213=m CONFIG_PATA_IT821X=m CONFIG_PATA_JMICRON=m CONFIG_PATA_MARVELL=m CONFIG_PATA_NETCELL=m CONFIG_PATA_NINJA32=m CONFIG_PATA_NS87415=m CONFIG_PATA_OLDPIIX=m CONFIG_PATA_OPTIDMA=m # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_PDC_OLD is not set CONFIG_PATA_RADISYS=m CONFIG_PATA_RDC=m # CONFIG_PATA_SCH is not set CONFIG_PATA_SERVERWORKS=m # CONFIG_PATA_SIL680 is not set CONFIG_PATA_SIS=m # CONFIG_PATA_TOSHIBA is not set # CONFIG_PATA_TRIFLEX is not set CONFIG_PATA_VIA=m CONFIG_PATA_WINBOND=m # # PIO-only SFF controllers # # CONFIG_PATA_CMD640_PCI is not set CONFIG_PATA_MPIIX=m # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set CONFIG_PATA_RZ1000=m # # Generic fallback / legacy drivers # # CONFIG_ATA_GENERIC is not set CONFIG_PATA_LEGACY=m CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m # CONFIG_MD_RAID0 is not set CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m # CONFIG_MD_MULTIPATH is not set CONFIG_MD_FAULTY=m CONFIG_BCACHE=y CONFIG_BCACHE_DEBUG=y # CONFIG_BCACHE_CLOSURES_DEBUG is not set # CONFIG_BCACHE_ASYNC_REGISTRAION is not set # CONFIG_BLK_DEV_DM is not set CONFIG_TARGET_CORE=m # CONFIG_TCM_IBLOCK is not set CONFIG_TCM_FILEIO=m CONFIG_TCM_PSCSI=m # CONFIG_LOOPBACK_TARGET is not set CONFIG_SBP_TARGET=m CONFIG_FUSION=y CONFIG_FUSION_SPI=m CONFIG_FUSION_SAS=m CONFIG_FUSION_MAX_SGE=128 # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LOGGING is not set # # IEEE 1394 (FireWire) support # CONFIG_FIREWIRE=m # CONFIG_FIREWIRE_OHCI is not set CONFIG_FIREWIRE_SBP2=m CONFIG_FIREWIRE_NOSY=m # end of IEEE 1394 (FireWire) support # CONFIG_MACINTOSH_DRIVERS is not set # CONFIG_NVM is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_LEDS=m CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=m CONFIG_INPUT_SPARSEKMAP=y CONFIG_INPUT_MATRIXKMAP=y # # Userland interfaces # # CONFIG_INPUT_MOUSEDEV is not set CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_EVDEV is not set CONFIG_INPUT_EVBUG=y # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ADP5588=m CONFIG_KEYBOARD_ADP5589=m CONFIG_KEYBOARD_ATKBD=m CONFIG_KEYBOARD_QT1050=m # CONFIG_KEYBOARD_QT1070 is not set # CONFIG_KEYBOARD_QT2160 is not set # CONFIG_KEYBOARD_DLINK_DIR685 is not set CONFIG_KEYBOARD_LKKBD=m # CONFIG_KEYBOARD_GPIO is not set # CONFIG_KEYBOARD_GPIO_POLLED is not set # CONFIG_KEYBOARD_TCA6416 is not set CONFIG_KEYBOARD_TCA8418=m CONFIG_KEYBOARD_MATRIX=y CONFIG_KEYBOARD_LM8323=m CONFIG_KEYBOARD_LM8333=m CONFIG_KEYBOARD_MAX7359=m CONFIG_KEYBOARD_MCS=m # CONFIG_KEYBOARD_MPR121 is not set CONFIG_KEYBOARD_NEWTON=y # CONFIG_KEYBOARD_OPENCORES is not set CONFIG_KEYBOARD_SAMSUNG=m CONFIG_KEYBOARD_STOWAWAY=m CONFIG_KEYBOARD_SUNKBD=m # CONFIG_KEYBOARD_IQS62X is not set # CONFIG_KEYBOARD_OMAP4 is not set # CONFIG_KEYBOARD_TM2_TOUCHKEY is not set # CONFIG_KEYBOARD_XTKBD is not set CONFIG_KEYBOARD_CROS_EC=m # CONFIG_KEYBOARD_CAP11XX is not set CONFIG_KEYBOARD_BCM=y CONFIG_KEYBOARD_MTK_PMIC=m # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m CONFIG_JOYSTICK_A3D=m # CONFIG_JOYSTICK_ADI is not set # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set CONFIG_JOYSTICK_GRIP=m # CONFIG_JOYSTICK_GRIP_MP is not set CONFIG_JOYSTICK_GUILLEMOT=m CONFIG_JOYSTICK_INTERACT=y CONFIG_JOYSTICK_SIDEWINDER=y CONFIG_JOYSTICK_TMDC=y # CONFIG_JOYSTICK_IFORCE is not set CONFIG_JOYSTICK_WARRIOR=y CONFIG_JOYSTICK_MAGELLAN=y CONFIG_JOYSTICK_SPACEORB=m CONFIG_JOYSTICK_SPACEBALL=y CONFIG_JOYSTICK_STINGER=m # CONFIG_JOYSTICK_TWIDJOY is not set CONFIG_JOYSTICK_ZHENHUA=y # CONFIG_JOYSTICK_AS5011 is not set # CONFIG_JOYSTICK_JOYDUMP is not set # CONFIG_JOYSTICK_FSIA6B is not set CONFIG_INPUT_TABLET=y # CONFIG_TABLET_SERIAL_WACOM4 is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_PROPERTIES=y # CONFIG_TOUCHSCREEN_AD7879 is not set CONFIG_TOUCHSCREEN_AR1021_I2C=m CONFIG_TOUCHSCREEN_ATMEL_MXT=m # CONFIG_TOUCHSCREEN_ATMEL_MXT_T37 is not set CONFIG_TOUCHSCREEN_AUO_PIXCIR=m # CONFIG_TOUCHSCREEN_BU21013 is not set CONFIG_TOUCHSCREEN_BU21029=m # CONFIG_TOUCHSCREEN_CHIPONE_ICN8318 is not set # CONFIG_TOUCHSCREEN_CHIPONE_ICN8505 is not set # CONFIG_TOUCHSCREEN_CY8CTMA140 is not set CONFIG_TOUCHSCREEN_CY8CTMG110=m # CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set # CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set # CONFIG_TOUCHSCREEN_DYNAPRO is not set CONFIG_TOUCHSCREEN_HAMPSHIRE=y CONFIG_TOUCHSCREEN_EETI=m CONFIG_TOUCHSCREEN_EGALAX=m # CONFIG_TOUCHSCREEN_EGALAX_SERIAL is not set CONFIG_TOUCHSCREEN_EXC3000=m CONFIG_TOUCHSCREEN_FUJITSU=m CONFIG_TOUCHSCREEN_GOODIX=m # CONFIG_TOUCHSCREEN_HIDEEP is not set CONFIG_TOUCHSCREEN_ILI210X=m # CONFIG_TOUCHSCREEN_S6SY761 is not set # CONFIG_TOUCHSCREEN_GUNZE is not set CONFIG_TOUCHSCREEN_EKTF2127=m CONFIG_TOUCHSCREEN_ELAN=m # CONFIG_TOUCHSCREEN_ELO is not set CONFIG_TOUCHSCREEN_WACOM_W8001=m # CONFIG_TOUCHSCREEN_WACOM_I2C is not set CONFIG_TOUCHSCREEN_MAX11801=m CONFIG_TOUCHSCREEN_MCS5000=m CONFIG_TOUCHSCREEN_MMS114=m CONFIG_TOUCHSCREEN_MELFAS_MIP4=m # CONFIG_TOUCHSCREEN_MTOUCH is not set CONFIG_TOUCHSCREEN_IMX6UL_TSC=y CONFIG_TOUCHSCREEN_INEXIO=m CONFIG_TOUCHSCREEN_MK712=y CONFIG_TOUCHSCREEN_PENMOUNT=m CONFIG_TOUCHSCREEN_EDT_FT5X06=m # CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set CONFIG_TOUCHSCREEN_TOUCHWIN=m CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y CONFIG_TOUCHSCREEN_PIXCIR=m CONFIG_TOUCHSCREEN_WDT87XX_I2C=m # CONFIG_TOUCHSCREEN_WM97XX is not set CONFIG_TOUCHSCREEN_MC13783=m # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set CONFIG_TOUCHSCREEN_TSC_SERIO=m CONFIG_TOUCHSCREEN_TSC200X_CORE=m CONFIG_TOUCHSCREEN_TSC2004=m # CONFIG_TOUCHSCREEN_TSC2007 is not set CONFIG_TOUCHSCREEN_RM_TS=m CONFIG_TOUCHSCREEN_SILEAD=m CONFIG_TOUCHSCREEN_SIS_I2C=m CONFIG_TOUCHSCREEN_ST1232=m # CONFIG_TOUCHSCREEN_STMFTS is not set # CONFIG_TOUCHSCREEN_SX8654 is not set CONFIG_TOUCHSCREEN_TPS6507X=m CONFIG_TOUCHSCREEN_ZET6223=m # CONFIG_TOUCHSCREEN_ZFORCE is not set CONFIG_TOUCHSCREEN_ROHM_BU21023=m CONFIG_TOUCHSCREEN_IQS5XX=m CONFIG_INPUT_MISC=y CONFIG_INPUT_88PM80X_ONKEY=m # CONFIG_INPUT_AD714X is not set CONFIG_INPUT_ATMEL_CAPTOUCH=m CONFIG_INPUT_BMA150=m CONFIG_INPUT_E3X0_BUTTON=y # CONFIG_INPUT_PCSPKR is not set CONFIG_INPUT_MAX77650_ONKEY=m CONFIG_INPUT_MC13783_PWRBUTTON=m CONFIG_INPUT_MMA8450=m # CONFIG_INPUT_APANEL is not set CONFIG_INPUT_GPIO_BEEPER=m CONFIG_INPUT_GPIO_DECODER=m # CONFIG_INPUT_GPIO_VIBRA is not set # CONFIG_INPUT_ATLAS_BTNS is not set CONFIG_INPUT_KXTJ9=m CONFIG_INPUT_REGULATOR_HAPTIC=y CONFIG_INPUT_TPS65218_PWRBUTTON=m CONFIG_INPUT_AXP20X_PEK=m # CONFIG_INPUT_UINPUT is not set CONFIG_INPUT_PCF50633_PMU=m CONFIG_INPUT_PCF8574=m CONFIG_INPUT_GPIO_ROTARY_ENCODER=m # CONFIG_INPUT_DA9063_ONKEY is not set CONFIG_INPUT_ADXL34X=m CONFIG_INPUT_ADXL34X_I2C=m CONFIG_INPUT_IQS269A=m # CONFIG_INPUT_CMA3000 is not set CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m # CONFIG_INPUT_IDEAPAD_SLIDEBAR is not set CONFIG_INPUT_DRV260X_HAPTICS=m CONFIG_INPUT_DRV2665_HAPTICS=m CONFIG_INPUT_DRV2667_HAPTICS=m CONFIG_INPUT_RAVE_SP_PWRBUTTON=m # CONFIG_RMI4_CORE is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_SERIO_ALTERA_PS2 is not set CONFIG_SERIO_PS2MULT=m CONFIG_SERIO_ARC_PS2=y CONFIG_SERIO_APBPS2=y CONFIG_HYPERV_KEYBOARD=m # CONFIG_SERIO_GPIO_PS2 is not set CONFIG_USERIO=y CONFIG_GAMEPORT=y # CONFIG_GAMEPORT_NS558 is not set CONFIG_GAMEPORT_L4=m CONFIG_GAMEPORT_EMU10K1=m # CONFIG_GAMEPORT_FM801 is not set # end of Hardware I/O ports # end of Input device support # # Character devices # CONFIG_TTY=y CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_VT_CONSOLE_SLEEP=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_LDISC_AUTOLOAD is not set # # Serial drivers # CONFIG_SERIAL_EARLYCON=y CONFIG_SERIAL_8250=m # CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_16550A_VARIANTS=y # CONFIG_SERIAL_8250_FINTEK is not set CONFIG_SERIAL_8250_DMA=y # CONFIG_SERIAL_8250_PCI is not set CONFIG_SERIAL_8250_MEN_MCB=m CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_ASPEED_VUART=m # CONFIG_SERIAL_8250_SHARE_IRQ is not set CONFIG_SERIAL_8250_DETECT_IRQ=y # CONFIG_SERIAL_8250_RSA is not set CONFIG_SERIAL_8250_DWLIB=y CONFIG_SERIAL_8250_DW=m CONFIG_SERIAL_8250_RT288X=y # CONFIG_SERIAL_8250_LPSS is not set CONFIG_SERIAL_8250_MID=m # CONFIG_SERIAL_OF_PLATFORM is not set # # Non-8250 serial port support # CONFIG_SERIAL_UARTLITE=y # CONFIG_SERIAL_UARTLITE_CONSOLE is not set CONFIG_SERIAL_UARTLITE_NR_UARTS=1 CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_SERIAL_JSM=m CONFIG_SERIAL_SIFIVE=m CONFIG_SERIAL_LANTIQ=m CONFIG_SERIAL_SCCNXP=m # CONFIG_SERIAL_SC16IS7XX is not set CONFIG_SERIAL_ALTERA_JTAGUART=m # CONFIG_SERIAL_ALTERA_UART is not set CONFIG_SERIAL_XILINX_PS_UART=y CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y CONFIG_SERIAL_ARC=m CONFIG_SERIAL_ARC_NR_PORTS=1 CONFIG_SERIAL_RP2=y CONFIG_SERIAL_RP2_NR_UARTS=32 CONFIG_SERIAL_FSL_LPUART=m CONFIG_SERIAL_FSL_LINFLEXUART=m # CONFIG_SERIAL_CONEXANT_DIGICOLOR is not set # CONFIG_SERIAL_MEN_Z135 is not set CONFIG_SERIAL_SPRD=y CONFIG_SERIAL_SPRD_CONSOLE=y # end of Serial drivers CONFIG_SERIAL_MCTRL_GPIO=m CONFIG_SERIAL_NONSTANDARD=y CONFIG_ROCKETPORT=m # CONFIG_CYCLADES is not set CONFIG_MOXA_INTELLIO=y CONFIG_MOXA_SMARTIO=y # CONFIG_SYNCLINK is not set CONFIG_SYNCLINKMP=y CONFIG_SYNCLINK_GT=y CONFIG_ISI=y # CONFIG_N_HDLC is not set CONFIG_NOZOMI=m CONFIG_NULL_TTY=m CONFIG_TRACE_ROUTER=m CONFIG_TRACE_SINK=m CONFIG_HVC_DRIVER=y # CONFIG_HVC_XEN is not set CONFIG_SERIAL_DEV_BUS=m CONFIG_VIRTIO_CONSOLE=m # CONFIG_IPMI_HANDLER is not set # CONFIG_IPMB_DEVICE_INTERFACE is not set CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_TIMERIOMEM=m CONFIG_HW_RANDOM_INTEL=m # CONFIG_HW_RANDOM_AMD is not set # CONFIG_HW_RANDOM_VIA is not set CONFIG_HW_RANDOM_VIRTIO=m CONFIG_HW_RANDOM_CCTRNG=y # CONFIG_APPLICOM is not set CONFIG_MWAVE=m CONFIG_DEVMEM=y # CONFIG_DEVKMEM is not set CONFIG_NVRAM=m CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=256 # CONFIG_DEVPORT is not set CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_HPET_MMAP_DEFAULT=y # CONFIG_HANGCHECK_TIMER is not set # CONFIG_TCG_TPM is not set CONFIG_TELCLOCK=y CONFIG_XILLYBUS=m # CONFIG_XILLYBUS_PCIE is not set CONFIG_XILLYBUS_OF=m # end of Character devices # CONFIG_RANDOM_TRUST_CPU is not set CONFIG_RANDOM_TRUST_BOOTLOADER=y # # I2C support # CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_COMPAT=y # CONFIG_I2C_CHARDEV is not set # CONFIG_I2C_MUX is not set CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_SMBUS=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCA=m # # I2C Hardware Bus support # # # PC SMBus host controller drivers # CONFIG_I2C_ALI1535=m CONFIG_I2C_ALI1563=m CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m # CONFIG_I2C_AMD756_S4882 is not set CONFIG_I2C_AMD8111=m # CONFIG_I2C_AMD_MP2 is not set CONFIG_I2C_I801=m # CONFIG_I2C_ISCH is not set # CONFIG_I2C_ISMT is not set CONFIG_I2C_PIIX4=m CONFIG_I2C_NFORCE2=m CONFIG_I2C_NFORCE2_S4985=m CONFIG_I2C_NVIDIA_GPU=m CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set CONFIG_I2C_VIAPRO=m # # ACPI drivers # CONFIG_I2C_SCMI=m # # I2C system bus drivers (mostly embedded / system-on-chip) # CONFIG_I2C_CBUS_GPIO=m CONFIG_I2C_DESIGNWARE_CORE=m CONFIG_I2C_DESIGNWARE_SLAVE=y # CONFIG_I2C_DESIGNWARE_PLATFORM is not set CONFIG_I2C_DESIGNWARE_PCI=m # CONFIG_I2C_EMEV2 is not set # CONFIG_I2C_GPIO is not set CONFIG_I2C_KEMPLD=m # CONFIG_I2C_OCORES is not set CONFIG_I2C_PCA_PLATFORM=m CONFIG_I2C_RK3X=m CONFIG_I2C_SIMTEC=m # CONFIG_I2C_XILINX is not set # # External I2C/SMBus adapter drivers # CONFIG_I2C_TAOS_EVM=m # # Other I2C/SMBus bus drivers # CONFIG_I2C_MLXCPLD=m CONFIG_I2C_CROS_EC_TUNNEL=m CONFIG_I2C_FSI=m # end of I2C Hardware Bus support CONFIG_I2C_STUB=m CONFIG_I2C_SLAVE=y # CONFIG_I2C_SLAVE_EEPROM is not set CONFIG_I2C_DEBUG_CORE=y # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # end of I2C support # CONFIG_I3C is not set # CONFIG_SPI is not set CONFIG_SPMI=m CONFIG_HSI=m CONFIG_HSI_BOARDINFO=y # # HSI controllers # # # HSI clients # CONFIG_HSI_CHAR=m CONFIG_PPS=y CONFIG_PPS_DEBUG=y # CONFIG_NTP_PPS is not set # # PPS clients support # CONFIG_PPS_CLIENT_KTIMER=y CONFIG_PPS_CLIENT_LDISC=y CONFIG_PPS_CLIENT_GPIO=y # # PPS generators support # # # PTP clock support # # # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # # end of PTP clock support CONFIG_PINCTRL=y CONFIG_GENERIC_PINCTRL_GROUPS=y CONFIG_PINMUX=y CONFIG_GENERIC_PINMUX_FUNCTIONS=y CONFIG_PINCONF=y CONFIG_GENERIC_PINCONF=y # CONFIG_PINCTRL_AXP209 is not set CONFIG_PINCTRL_AMD=m CONFIG_PINCTRL_DA9062=m CONFIG_PINCTRL_MCP23S08_I2C=m CONFIG_PINCTRL_MCP23S08=m # CONFIG_PINCTRL_SINGLE is not set # CONFIG_PINCTRL_STMFX is not set # CONFIG_PINCTRL_OCELOT is not set # CONFIG_PINCTRL_BAYTRAIL is not set # CONFIG_PINCTRL_CHERRYVIEW is not set CONFIG_PINCTRL_LYNXPOINT=m CONFIG_PINCTRL_INTEL=y CONFIG_PINCTRL_BROXTON=y CONFIG_PINCTRL_CANNONLAKE=y # CONFIG_PINCTRL_CEDARFORK is not set CONFIG_PINCTRL_DENVERTON=m # CONFIG_PINCTRL_GEMINILAKE is not set CONFIG_PINCTRL_ICELAKE=y CONFIG_PINCTRL_JASPERLAKE=m # CONFIG_PINCTRL_LEWISBURG is not set CONFIG_PINCTRL_SUNRISEPOINT=y CONFIG_PINCTRL_TIGERLAKE=y CONFIG_PINCTRL_EQUILIBRIUM=y CONFIG_GPIOLIB=y CONFIG_GPIOLIB_FASTPATH_LIMIT=512 CONFIG_OF_GPIO=y CONFIG_GPIO_ACPI=y CONFIG_GPIOLIB_IRQCHIP=y CONFIG_GPIO_SYSFS=y CONFIG_GPIO_GENERIC=y # # Memory mapped GPIO drivers # # CONFIG_GPIO_74XX_MMIO is not set CONFIG_GPIO_ALTERA=m # CONFIG_GPIO_AMDPT is not set CONFIG_GPIO_CADENCE=m CONFIG_GPIO_DWAPB=m CONFIG_GPIO_FTGPIO010=y CONFIG_GPIO_GENERIC_PLATFORM=m # CONFIG_GPIO_GRGPIO is not set CONFIG_GPIO_HLWD=y CONFIG_GPIO_ICH=y CONFIG_GPIO_LOGICVC=m CONFIG_GPIO_MB86S7X=y CONFIG_GPIO_MENZ127=m # CONFIG_GPIO_SAMA5D2_PIOBU is not set CONFIG_GPIO_SIFIVE=y CONFIG_GPIO_SIOX=m # CONFIG_GPIO_SYSCON is not set CONFIG_GPIO_VX855=y # CONFIG_GPIO_XILINX is not set CONFIG_GPIO_AMD_FCH=m # end of Memory mapped GPIO drivers # # Port-mapped I/O GPIO drivers # CONFIG_GPIO_F7188X=m # CONFIG_GPIO_IT87 is not set # CONFIG_GPIO_SCH is not set CONFIG_GPIO_SCH311X=m CONFIG_GPIO_WINBOND=y CONFIG_GPIO_WS16C48=y # end of Port-mapped I/O GPIO drivers # # I2C GPIO expanders # CONFIG_GPIO_ADP5588=m CONFIG_GPIO_ADNP=m CONFIG_GPIO_GW_PLD=m # CONFIG_GPIO_MAX7300 is not set CONFIG_GPIO_MAX732X=m # CONFIG_GPIO_PCA953X is not set # CONFIG_GPIO_PCF857X is not set CONFIG_GPIO_TPIC2810=m # end of I2C GPIO expanders # # MFD GPIO expanders # # CONFIG_GPIO_BD9571MWV is not set # CONFIG_GPIO_JANZ_TTL is not set CONFIG_GPIO_KEMPLD=m CONFIG_GPIO_LP3943=m CONFIG_GPIO_LP873X=m CONFIG_GPIO_LP87565=m # CONFIG_GPIO_MAX77650 is not set # CONFIG_GPIO_TPS65086 is not set # CONFIG_GPIO_TPS65218 is not set # CONFIG_GPIO_TPS65912 is not set CONFIG_GPIO_TQMX86=m # end of MFD GPIO expanders # # PCI GPIO expanders # # CONFIG_GPIO_AMD8111 is not set CONFIG_GPIO_ML_IOH=m CONFIG_GPIO_PCI_IDIO_16=y CONFIG_GPIO_PCIE_IDIO_24=y # CONFIG_GPIO_RDC321X is not set CONFIG_GPIO_SODAVILLE=y # end of PCI GPIO expanders CONFIG_GPIO_AGGREGATOR=y # CONFIG_GPIO_MOCKUP is not set CONFIG_W1=m # # 1-wire Bus Masters # CONFIG_W1_MASTER_MATROX=m CONFIG_W1_MASTER_DS2482=m CONFIG_W1_MASTER_DS1WM=m # CONFIG_W1_MASTER_GPIO is not set CONFIG_W1_MASTER_SGI=m # end of 1-wire Bus Masters # # 1-wire Slaves # CONFIG_W1_SLAVE_THERM=m CONFIG_W1_SLAVE_SMEM=m CONFIG_W1_SLAVE_DS2405=m CONFIG_W1_SLAVE_DS2408=m CONFIG_W1_SLAVE_DS2408_READBACK=y # CONFIG_W1_SLAVE_DS2413 is not set CONFIG_W1_SLAVE_DS2406=m CONFIG_W1_SLAVE_DS2423=m # CONFIG_W1_SLAVE_DS2805 is not set # CONFIG_W1_SLAVE_DS2430 is not set CONFIG_W1_SLAVE_DS2431=m # CONFIG_W1_SLAVE_DS2433 is not set # CONFIG_W1_SLAVE_DS2438 is not set # CONFIG_W1_SLAVE_DS250X is not set CONFIG_W1_SLAVE_DS2780=m CONFIG_W1_SLAVE_DS2781=m CONFIG_W1_SLAVE_DS28E04=m # CONFIG_W1_SLAVE_DS28E17 is not set # end of 1-wire Slaves CONFIG_POWER_AVS=y # CONFIG_QCOM_CPR is not set CONFIG_POWER_RESET=y CONFIG_POWER_RESET_GPIO=y # CONFIG_POWER_RESET_GPIO_RESTART is not set # CONFIG_POWER_RESET_LTC2952 is not set # CONFIG_POWER_RESET_MT6323 is not set # CONFIG_POWER_RESET_RESTART is not set # CONFIG_POWER_RESET_SYSCON is not set # CONFIG_POWER_RESET_SYSCON_POWEROFF is not set CONFIG_REBOOT_MODE=m CONFIG_SYSCON_REBOOT_MODE=m CONFIG_NVMEM_REBOOT_MODE=m CONFIG_POWER_SUPPLY=y CONFIG_POWER_SUPPLY_DEBUG=y # CONFIG_POWER_SUPPLY_HWMON is not set # CONFIG_PDA_POWER is not set CONFIG_TEST_POWER=m # CONFIG_CHARGER_ADP5061 is not set CONFIG_BATTERY_CW2015=m CONFIG_BATTERY_DS2760=m # CONFIG_BATTERY_DS2780 is not set CONFIG_BATTERY_DS2781=m CONFIG_BATTERY_DS2782=m CONFIG_BATTERY_SBS=m CONFIG_CHARGER_SBS=m CONFIG_BATTERY_BQ27XXX=y CONFIG_BATTERY_BQ27XXX_I2C=m CONFIG_BATTERY_BQ27XXX_HDQ=m CONFIG_BATTERY_BQ27XXX_DT_UPDATES_NVM=y # CONFIG_BATTERY_DA9150 is not set CONFIG_BATTERY_MAX17040=m # CONFIG_BATTERY_MAX17042 is not set # CONFIG_BATTERY_MAX1721X is not set CONFIG_CHARGER_PCF50633=m CONFIG_CHARGER_MAX8903=y # CONFIG_CHARGER_LP8727 is not set # CONFIG_CHARGER_GPIO is not set CONFIG_CHARGER_MANAGER=y # CONFIG_CHARGER_LT3651 is not set CONFIG_CHARGER_MAX14577=m CONFIG_CHARGER_DETECTOR_MAX14656=m CONFIG_CHARGER_MAX77650=m CONFIG_CHARGER_BQ2415X=m CONFIG_CHARGER_BQ24190=m # CONFIG_CHARGER_BQ24257 is not set # CONFIG_CHARGER_BQ24735 is not set CONFIG_CHARGER_BQ25890=m CONFIG_CHARGER_SMB347=m CONFIG_CHARGER_TPS65217=m CONFIG_BATTERY_GAUGE_LTC2941=m # CONFIG_BATTERY_RT5033 is not set CONFIG_CHARGER_RT9455=m # CONFIG_CHARGER_CROS_USBPD is not set # CONFIG_CHARGER_UCS1002 is not set # CONFIG_CHARGER_BD99954 is not set CONFIG_CHARGER_WILCO=m CONFIG_HWMON=y CONFIG_HWMON_VID=y CONFIG_HWMON_DEBUG_CHIP=y # # Native drivers # # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7414 is not set # CONFIG_SENSORS_AD7418 is not set CONFIG_SENSORS_ADM1021=m # CONFIG_SENSORS_ADM1025 is not set CONFIG_SENSORS_ADM1026=m # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set CONFIG_SENSORS_ADM1177=m CONFIG_SENSORS_ADM9240=m # CONFIG_SENSORS_ADT7410 is not set CONFIG_SENSORS_ADT7411=m CONFIG_SENSORS_ADT7462=m # CONFIG_SENSORS_ADT7470 is not set CONFIG_SENSORS_ADT7475=m CONFIG_SENSORS_AS370=y # CONFIG_SENSORS_ASC7621 is not set CONFIG_SENSORS_AXI_FAN_CONTROL=y CONFIG_SENSORS_K8TEMP=y CONFIG_SENSORS_K10TEMP=m CONFIG_SENSORS_FAM15H_POWER=y CONFIG_SENSORS_AMD_ENERGY=y CONFIG_SENSORS_APPLESMC=m CONFIG_SENSORS_ASB100=m # CONFIG_SENSORS_ASPEED is not set # CONFIG_SENSORS_ATXP1 is not set CONFIG_SENSORS_DRIVETEMP=m CONFIG_SENSORS_DS620=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_DELL_SMM=m CONFIG_SENSORS_I5K_AMB=m CONFIG_SENSORS_F71805F=y # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_MC13783_ADC is not set CONFIG_SENSORS_FSCHMD=m # CONFIG_SENSORS_GL518SM is not set CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_G760A=m CONFIG_SENSORS_G762=m CONFIG_SENSORS_GPIO_FAN=y CONFIG_SENSORS_HIH6130=m CONFIG_SENSORS_I5500=y # CONFIG_SENSORS_CORETEMP is not set # CONFIG_SENSORS_IT87 is not set CONFIG_SENSORS_JC42=m CONFIG_SENSORS_POWR1220=m # CONFIG_SENSORS_LINEAGE is not set # CONFIG_SENSORS_LTC2945 is not set CONFIG_SENSORS_LTC2947=m CONFIG_SENSORS_LTC2947_I2C=m # CONFIG_SENSORS_LTC2990 is not set # CONFIG_SENSORS_LTC4151 is not set # CONFIG_SENSORS_LTC4215 is not set # CONFIG_SENSORS_LTC4222 is not set CONFIG_SENSORS_LTC4245=m CONFIG_SENSORS_LTC4260=m # CONFIG_SENSORS_LTC4261 is not set # CONFIG_SENSORS_MAX16065 is not set CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_MAX1668=m CONFIG_SENSORS_MAX197=y # CONFIG_SENSORS_MAX31730 is not set CONFIG_SENSORS_MAX6621=m CONFIG_SENSORS_MAX6639=m CONFIG_SENSORS_MAX6642=m CONFIG_SENSORS_MAX6650=m CONFIG_SENSORS_MAX6697=m # CONFIG_SENSORS_MAX31790 is not set CONFIG_SENSORS_MCP3021=m CONFIG_SENSORS_MLXREG_FAN=y # CONFIG_SENSORS_TC654 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM73 is not set CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m # CONFIG_SENSORS_LM93 is not set CONFIG_SENSORS_LM95234=m CONFIG_SENSORS_LM95241=m CONFIG_SENSORS_LM95245=m # CONFIG_SENSORS_PC87360 is not set CONFIG_SENSORS_PC87427=y # CONFIG_SENSORS_NTC_THERMISTOR is not set CONFIG_SENSORS_NCT6683=m # CONFIG_SENSORS_NCT6775 is not set CONFIG_SENSORS_NCT7802=m CONFIG_SENSORS_NPCM7XX=y CONFIG_SENSORS_PCF8591=m # CONFIG_PMBUS is not set # CONFIG_SENSORS_SHT15 is not set # CONFIG_SENSORS_SHT21 is not set CONFIG_SENSORS_SHT3x=m CONFIG_SENSORS_SHTC1=m CONFIG_SENSORS_SIS5595=m CONFIG_SENSORS_DME1737=m CONFIG_SENSORS_EMC1403=m # CONFIG_SENSORS_EMC2103 is not set CONFIG_SENSORS_EMC6W201=m CONFIG_SENSORS_SMSC47M1=y CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m # CONFIG_SENSORS_STTS751 is not set CONFIG_SENSORS_SMM665=m # CONFIG_SENSORS_ADC128D818 is not set CONFIG_SENSORS_ADS7828=m CONFIG_SENSORS_AMC6821=m CONFIG_SENSORS_INA209=m CONFIG_SENSORS_INA2XX=m CONFIG_SENSORS_INA3221=m CONFIG_SENSORS_TC74=m CONFIG_SENSORS_THMC50=m CONFIG_SENSORS_TMP102=m CONFIG_SENSORS_TMP103=m # CONFIG_SENSORS_TMP108 is not set # CONFIG_SENSORS_TMP401 is not set # CONFIG_SENSORS_TMP421 is not set CONFIG_SENSORS_TMP513=m CONFIG_SENSORS_VIA_CPUTEMP=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=y # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83773G is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set CONFIG_SENSORS_W83793=m # CONFIG_SENSORS_W83795 is not set # CONFIG_SENSORS_W83L785TS is not set CONFIG_SENSORS_W83L786NG=m CONFIG_SENSORS_W83627HF=y CONFIG_SENSORS_W83627EHF=m # # ACPI drivers # CONFIG_SENSORS_ACPI_POWER=y CONFIG_SENSORS_ATK0110=y CONFIG_THERMAL=y # CONFIG_THERMAL_STATISTICS is not set CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0 CONFIG_THERMAL_HWMON=y CONFIG_THERMAL_OF=y CONFIG_THERMAL_WRITABLE_TRIPS=y CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y # CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set # CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set CONFIG_THERMAL_GOV_FAIR_SHARE=y CONFIG_THERMAL_GOV_STEP_WISE=y CONFIG_THERMAL_GOV_BANG_BANG=y CONFIG_THERMAL_GOV_USER_SPACE=y # CONFIG_THERMAL_GOV_POWER_ALLOCATOR is not set # CONFIG_CPU_THERMAL is not set # CONFIG_THERMAL_EMULATION is not set # CONFIG_THERMAL_MMIO is not set CONFIG_QORIQ_THERMAL=m CONFIG_DA9062_THERMAL=m # # Intel thermal drivers # CONFIG_INTEL_POWERCLAMP=m # CONFIG_X86_PKG_TEMP_THERMAL is not set CONFIG_INTEL_SOC_DTS_IOSF_CORE=y CONFIG_INTEL_SOC_DTS_THERMAL=m # # ACPI INT340X thermal drivers # CONFIG_INT340X_THERMAL=y CONFIG_ACPI_THERMAL_REL=y # end of ACPI INT340X thermal drivers CONFIG_INTEL_PCH_THERMAL=m # end of Intel thermal drivers # CONFIG_WATCHDOG is not set CONFIG_SSB_POSSIBLE=y CONFIG_SSB=m CONFIG_SSB_PCIHOST_POSSIBLE=y # CONFIG_SSB_PCIHOST is not set CONFIG_SSB_SDIOHOST_POSSIBLE=y # CONFIG_SSB_SDIOHOST is not set # CONFIG_SSB_DRIVER_GPIO is not set CONFIG_BCMA_POSSIBLE=y # CONFIG_BCMA is not set # # Multifunction device drivers # CONFIG_MFD_CORE=y # CONFIG_MFD_ACT8945A is not set CONFIG_MFD_ATMEL_FLEXCOM=m CONFIG_MFD_ATMEL_HLCDC=y # CONFIG_MFD_BCM590XX is not set CONFIG_MFD_BD9571MWV=m CONFIG_MFD_AXP20X=m CONFIG_MFD_AXP20X_I2C=m CONFIG_MFD_CROS_EC_DEV=m # CONFIG_MFD_MADERA is not set CONFIG_MFD_DA9062=m # CONFIG_MFD_DA9063 is not set CONFIG_MFD_DA9150=m # CONFIG_MFD_GATEWORKS_GSC is not set CONFIG_MFD_MC13XXX=m CONFIG_MFD_MC13XXX_I2C=m # CONFIG_MFD_MP2629 is not set # CONFIG_MFD_HI6421_PMIC is not set # CONFIG_HTC_PASIC3 is not set CONFIG_MFD_INTEL_QUARK_I2C_GPIO=m CONFIG_LPC_ICH=y CONFIG_LPC_SCH=y CONFIG_INTEL_SOC_PMIC_CHTDC_TI=m CONFIG_MFD_INTEL_LPSS=y # CONFIG_MFD_INTEL_LPSS_ACPI is not set CONFIG_MFD_INTEL_LPSS_PCI=y CONFIG_MFD_IQS62X=m CONFIG_MFD_JANZ_CMODIO=y CONFIG_MFD_KEMPLD=y CONFIG_MFD_88PM800=m CONFIG_MFD_88PM805=m CONFIG_MFD_MAX14577=m CONFIG_MFD_MAX77650=m # CONFIG_MFD_MAX77686 is not set # CONFIG_MFD_MAX77693 is not set CONFIG_MFD_MAX8907=m # CONFIG_MFD_MT6360 is not set CONFIG_MFD_MT6397=m # CONFIG_MFD_MENF21BMC is not set # CONFIG_MFD_RETU is not set CONFIG_MFD_PCF50633=m CONFIG_PCF50633_ADC=m # CONFIG_PCF50633_GPIO is not set # CONFIG_UCB1400_CORE is not set CONFIG_MFD_RDC321X=m CONFIG_MFD_RT5033=m # CONFIG_MFD_RK808 is not set CONFIG_MFD_RN5T618=m # CONFIG_MFD_SI476X_CORE is not set CONFIG_MFD_SM501=m CONFIG_MFD_SM501_GPIO=y CONFIG_MFD_SKY81452=m # CONFIG_ABX500_CORE is not set CONFIG_MFD_SYSCON=y CONFIG_MFD_TI_AM335X_TSCADC=y CONFIG_MFD_LP3943=m CONFIG_MFD_TI_LMU=m # CONFIG_TPS6105X is not set CONFIG_TPS65010=m # CONFIG_TPS6507X is not set CONFIG_MFD_TPS65086=m CONFIG_MFD_TPS65217=m CONFIG_MFD_TI_LP873X=m CONFIG_MFD_TI_LP87565=m CONFIG_MFD_TPS65218=m CONFIG_MFD_TPS65912=m CONFIG_MFD_TPS65912_I2C=m CONFIG_MFD_WL1273_CORE=m CONFIG_MFD_LM3533=m CONFIG_MFD_TQMX86=m CONFIG_MFD_VX855=y # CONFIG_MFD_ARIZONA_I2C is not set # CONFIG_MFD_WM8994 is not set # CONFIG_MFD_STMFX is not set CONFIG_RAVE_SP_CORE=m # end of Multifunction device drivers CONFIG_REGULATOR=y # CONFIG_REGULATOR_DEBUG is not set CONFIG_REGULATOR_FIXED_VOLTAGE=y # CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set # CONFIG_REGULATOR_USERSPACE_CONSUMER is not set # CONFIG_REGULATOR_88PG86X is not set CONFIG_REGULATOR_88PM800=m # CONFIG_REGULATOR_ACT8865 is not set CONFIG_REGULATOR_AD5398=m CONFIG_REGULATOR_AXP20X=m CONFIG_REGULATOR_BD9571MWV=m # CONFIG_REGULATOR_DA9062 is not set CONFIG_REGULATOR_DA9210=m CONFIG_REGULATOR_DA9211=m # CONFIG_REGULATOR_FAN53555 is not set CONFIG_REGULATOR_GPIO=m CONFIG_REGULATOR_ISL9305=m CONFIG_REGULATOR_ISL6271A=m CONFIG_REGULATOR_LM363X=m # CONFIG_REGULATOR_LP3971 is not set CONFIG_REGULATOR_LP3972=m CONFIG_REGULATOR_LP872X=m CONFIG_REGULATOR_LP873X=m CONFIG_REGULATOR_LP8755=m CONFIG_REGULATOR_LP87565=m CONFIG_REGULATOR_LTC3589=m CONFIG_REGULATOR_LTC3676=m # CONFIG_REGULATOR_MAX14577 is not set CONFIG_REGULATOR_MAX1586=m CONFIG_REGULATOR_MAX77650=m # CONFIG_REGULATOR_MAX8649 is not set CONFIG_REGULATOR_MAX8660=m CONFIG_REGULATOR_MAX8907=m CONFIG_REGULATOR_MAX8952=m # CONFIG_REGULATOR_MAX8973 is not set CONFIG_REGULATOR_MAX77826=m CONFIG_REGULATOR_MC13XXX_CORE=m CONFIG_REGULATOR_MC13783=m # CONFIG_REGULATOR_MC13892 is not set # CONFIG_REGULATOR_MCP16502 is not set # CONFIG_REGULATOR_MP5416 is not set CONFIG_REGULATOR_MP8859=m # CONFIG_REGULATOR_MP886X is not set CONFIG_REGULATOR_MPQ7920=m # CONFIG_REGULATOR_MT6311 is not set CONFIG_REGULATOR_MT6323=m CONFIG_REGULATOR_MT6397=m # CONFIG_REGULATOR_PCF50633 is not set CONFIG_REGULATOR_PFUZE100=m # CONFIG_REGULATOR_PV88060 is not set # CONFIG_REGULATOR_PV88080 is not set # CONFIG_REGULATOR_PV88090 is not set CONFIG_REGULATOR_QCOM_SPMI=m # CONFIG_REGULATOR_RN5T618 is not set CONFIG_REGULATOR_RT5033=m CONFIG_REGULATOR_SKY81452=m # CONFIG_REGULATOR_SLG51000 is not set CONFIG_REGULATOR_SY8106A=m # CONFIG_REGULATOR_SY8824X is not set # CONFIG_REGULATOR_TPS51632 is not set # CONFIG_REGULATOR_TPS62360 is not set # CONFIG_REGULATOR_TPS65023 is not set CONFIG_REGULATOR_TPS6507X=m CONFIG_REGULATOR_TPS65086=m CONFIG_REGULATOR_TPS65132=m CONFIG_REGULATOR_TPS65217=m CONFIG_REGULATOR_TPS65218=m CONFIG_REGULATOR_TPS65912=m CONFIG_REGULATOR_VCTRL=y CONFIG_RC_CORE=y CONFIG_RC_MAP=m CONFIG_LIRC=y # CONFIG_BPF_LIRC_MODE2 is not set # CONFIG_RC_DECODERS is not set CONFIG_RC_DEVICES=y # CONFIG_IR_ENE is not set CONFIG_IR_HIX5HD2=y CONFIG_IR_ITE_CIR=y # CONFIG_IR_FINTEK is not set CONFIG_IR_NUVOTON=m # CONFIG_IR_WINBOND_CIR is not set CONFIG_RC_LOOPBACK=m CONFIG_IR_GPIO_CIR=m CONFIG_IR_GPIO_TX=y # CONFIG_IR_SERIAL is not set CONFIG_IR_SIR=m CONFIG_CEC_CORE=m CONFIG_CEC_NOTIFIER=y # CONFIG_MEDIA_CEC_RC is not set CONFIG_MEDIA_CEC_SUPPORT=y CONFIG_CEC_CROS_EC=m # CONFIG_CEC_SECO is not set CONFIG_MEDIA_SUPPORT=y # CONFIG_MEDIA_SUPPORT_FILTER is not set # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set # # Media device types # CONFIG_MEDIA_CAMERA_SUPPORT=y CONFIG_MEDIA_ANALOG_TV_SUPPORT=y CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y CONFIG_MEDIA_RADIO_SUPPORT=y CONFIG_MEDIA_SDR_SUPPORT=y CONFIG_MEDIA_PLATFORM_SUPPORT=y CONFIG_MEDIA_TEST_SUPPORT=y # end of Media device types # # Media core support # CONFIG_VIDEO_DEV=y CONFIG_MEDIA_CONTROLLER=y CONFIG_DVB_CORE=m # end of Media core support # # Video4Linux options # CONFIG_VIDEO_V4L2=m CONFIG_VIDEO_V4L2_I2C=y CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_VIDEO_ADV_DEBUG=y # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set CONFIG_VIDEO_TUNER=m CONFIG_V4L2_MEM2MEM_DEV=m CONFIG_V4L2_FLASH_LED_CLASS=m CONFIG_V4L2_FWNODE=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_VMALLOC=m # end of Video4Linux options # # Media controller options # CONFIG_MEDIA_CONTROLLER_DVB=y # end of Media controller options # # Digital TV options # # CONFIG_DVB_MMAP is not set CONFIG_DVB_MAX_ADAPTERS=16 CONFIG_DVB_DYNAMIC_MINORS=y CONFIG_DVB_DEMUX_SECTION_LOSS_LOG=y # CONFIG_DVB_ULE_DEBUG is not set # end of Digital TV options # # Media drivers # CONFIG_TTPCI_EEPROM=m CONFIG_MEDIA_PCI_SUPPORT=y # # Media capture support # CONFIG_VIDEO_SOLO6X10=m # CONFIG_VIDEO_TW5864 is not set CONFIG_VIDEO_TW68=m CONFIG_VIDEO_TW686X=m # # Media capture/analog TV support # CONFIG_VIDEO_IVTV=m # CONFIG_VIDEO_IVTV_DEPRECATED_IOCTLS is not set CONFIG_VIDEO_IVTV_ALSA=m CONFIG_VIDEO_HEXIUM_GEMINI=m # CONFIG_VIDEO_HEXIUM_ORION is not set CONFIG_VIDEO_MXB=m # CONFIG_VIDEO_DT3155 is not set # # Media capture/analog/hybrid TV support # CONFIG_VIDEO_CX18=m CONFIG_VIDEO_CX18_ALSA=m CONFIG_VIDEO_CX23885=m # CONFIG_MEDIA_ALTERA_CI is not set # CONFIG_VIDEO_CX25821 is not set CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m # CONFIG_VIDEO_CX88_BLACKBIRD is not set # CONFIG_VIDEO_CX88_DVB is not set CONFIG_VIDEO_BT848=m CONFIG_DVB_BT8XX=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m # CONFIG_VIDEO_SAA7134_RC is not set CONFIG_VIDEO_SAA7134_DVB=m CONFIG_VIDEO_SAA7164=m # # Media digital TV PCI Adapters # CONFIG_DVB_AV7110_IR=y CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y # CONFIG_DVB_BUDGET_CORE is not set CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_PCI_DEBUG=y CONFIG_DVB_PLUTO2=m # CONFIG_DVB_DM1105 is not set CONFIG_DVB_PT1=m CONFIG_DVB_PT3=m CONFIG_MANTIS_CORE=m # CONFIG_DVB_MANTIS is not set CONFIG_DVB_HOPPER=m # CONFIG_DVB_NGENE is not set # CONFIG_DVB_DDBRIDGE is not set CONFIG_DVB_SMIPCIE=m # CONFIG_VIDEO_IPU3_CIO2 is not set CONFIG_VIDEO_PCI_SKELETON=m CONFIG_RADIO_ADAPTERS=y CONFIG_RADIO_TEA575X=m # CONFIG_RADIO_SI470X is not set # CONFIG_RADIO_SI4713 is not set CONFIG_RADIO_MAXIRADIO=m # CONFIG_RADIO_TEA5764 is not set # CONFIG_RADIO_SAA7706H is not set CONFIG_RADIO_TEF6862=m CONFIG_RADIO_WL1273=m CONFIG_VIDEO_CX2341X=m CONFIG_VIDEO_TVEEPROM=m CONFIG_VIDEOBUF2_CORE=m CONFIG_VIDEOBUF2_V4L2=m CONFIG_VIDEOBUF2_MEMOPS=m CONFIG_VIDEOBUF2_DMA_CONTIG=m CONFIG_VIDEOBUF2_VMALLOC=m CONFIG_VIDEOBUF2_DMA_SG=m CONFIG_VIDEOBUF2_DVB=m CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_DEBUG=y CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m # CONFIG_V4L_PLATFORM_DRIVERS is not set CONFIG_V4L_MEM2MEM_DRIVERS=y CONFIG_VIDEO_MEM2MEM_DEINTERLACE=m CONFIG_DVB_PLATFORM_DRIVERS=y # CONFIG_SDR_PLATFORM_DRIVERS is not set # # MMC/SDIO DVB adapters # # CONFIG_SMS_SDIO_DRV is not set # CONFIG_V4L_TEST_DRIVERS is not set # # FireWire (IEEE 1394) Adapters # # CONFIG_DVB_FIREDTV is not set # end of Media drivers # # Media ancillary drivers # CONFIG_MEDIA_ATTACH=y CONFIG_VIDEO_IR_I2C=m # # Audio decoders, processors and mixers # # CONFIG_VIDEO_TVAUDIO is not set # CONFIG_VIDEO_TDA7432 is not set CONFIG_VIDEO_TDA9840=m CONFIG_VIDEO_TDA1997X=m # CONFIG_VIDEO_TEA6415C is not set CONFIG_VIDEO_TEA6420=m CONFIG_VIDEO_MSP3400=m CONFIG_VIDEO_CS3308=m CONFIG_VIDEO_CS5345=m CONFIG_VIDEO_CS53L32A=m CONFIG_VIDEO_TLV320AIC23B=m CONFIG_VIDEO_UDA1342=m CONFIG_VIDEO_WM8775=m CONFIG_VIDEO_WM8739=m CONFIG_VIDEO_VP27SMPX=m CONFIG_VIDEO_SONY_BTF_MPX=m # end of Audio decoders, processors and mixers # # RDS decoders # CONFIG_VIDEO_SAA6588=m # end of RDS decoders # # Video decoders # CONFIG_VIDEO_ADV7180=m CONFIG_VIDEO_ADV7183=m # CONFIG_VIDEO_ADV748X is not set CONFIG_VIDEO_ADV7604=m CONFIG_VIDEO_ADV7604_CEC=y # CONFIG_VIDEO_ADV7842 is not set CONFIG_VIDEO_BT819=m CONFIG_VIDEO_BT856=m # CONFIG_VIDEO_BT866 is not set CONFIG_VIDEO_KS0127=m # CONFIG_VIDEO_ML86V7667 is not set CONFIG_VIDEO_SAA7110=m CONFIG_VIDEO_SAA711X=m CONFIG_VIDEO_TC358743=m CONFIG_VIDEO_TC358743_CEC=y CONFIG_VIDEO_TVP514X=m CONFIG_VIDEO_TVP5150=m CONFIG_VIDEO_TVP7002=m CONFIG_VIDEO_TW2804=m CONFIG_VIDEO_TW9903=m # CONFIG_VIDEO_TW9906 is not set # CONFIG_VIDEO_TW9910 is not set CONFIG_VIDEO_VPX3220=m # # Video and audio decoders # CONFIG_VIDEO_SAA717X=m CONFIG_VIDEO_CX25840=m # end of Video decoders # # Video encoders # CONFIG_VIDEO_SAA7127=m CONFIG_VIDEO_SAA7185=m # CONFIG_VIDEO_ADV7170 is not set CONFIG_VIDEO_ADV7175=m CONFIG_VIDEO_ADV7343=m # CONFIG_VIDEO_ADV7393 is not set CONFIG_VIDEO_ADV7511=m CONFIG_VIDEO_ADV7511_CEC=y CONFIG_VIDEO_AD9389B=m CONFIG_VIDEO_AK881X=m # CONFIG_VIDEO_THS8200 is not set # end of Video encoders # # Video improvement chips # CONFIG_VIDEO_UPD64031A=m CONFIG_VIDEO_UPD64083=m # end of Video improvement chips # # Audio/Video compression chips # # CONFIG_VIDEO_SAA6752HS is not set # end of Audio/Video compression chips # # SDR tuner chips # CONFIG_SDR_MAX2175=m # end of SDR tuner chips # # Miscellaneous helper chips # # CONFIG_VIDEO_THS7303 is not set CONFIG_VIDEO_M52790=m # CONFIG_VIDEO_I2C is not set # CONFIG_VIDEO_ST_MIPID02 is not set # end of Miscellaneous helper chips # # Camera sensor devices # CONFIG_VIDEO_APTINA_PLL=m CONFIG_VIDEO_HI556=m CONFIG_VIDEO_IMX214=m CONFIG_VIDEO_IMX219=m CONFIG_VIDEO_IMX258=m CONFIG_VIDEO_IMX274=m CONFIG_VIDEO_IMX290=m CONFIG_VIDEO_IMX319=m CONFIG_VIDEO_IMX355=m CONFIG_VIDEO_OV2640=m # CONFIG_VIDEO_OV2659 is not set CONFIG_VIDEO_OV2680=m CONFIG_VIDEO_OV2685=m CONFIG_VIDEO_OV2740=m # CONFIG_VIDEO_OV5640 is not set CONFIG_VIDEO_OV5645=m # CONFIG_VIDEO_OV5647 is not set CONFIG_VIDEO_OV6650=m CONFIG_VIDEO_OV5670=m CONFIG_VIDEO_OV5675=m # CONFIG_VIDEO_OV5695 is not set CONFIG_VIDEO_OV7251=m CONFIG_VIDEO_OV772X=m CONFIG_VIDEO_OV7640=m # CONFIG_VIDEO_OV7670 is not set # CONFIG_VIDEO_OV7740 is not set CONFIG_VIDEO_OV8856=m CONFIG_VIDEO_OV9640=m CONFIG_VIDEO_OV9650=m CONFIG_VIDEO_OV13858=m CONFIG_VIDEO_VS6624=m CONFIG_VIDEO_MT9M001=m CONFIG_VIDEO_MT9M032=m # CONFIG_VIDEO_MT9M111 is not set CONFIG_VIDEO_MT9P031=m CONFIG_VIDEO_MT9T001=m # CONFIG_VIDEO_MT9T112 is not set CONFIG_VIDEO_MT9V011=m CONFIG_VIDEO_MT9V032=m CONFIG_VIDEO_MT9V111=m CONFIG_VIDEO_SR030PC30=m # CONFIG_VIDEO_NOON010PC30 is not set CONFIG_VIDEO_M5MOLS=m # CONFIG_VIDEO_RJ54N1 is not set # CONFIG_VIDEO_S5K6AA is not set CONFIG_VIDEO_S5K6A3=m CONFIG_VIDEO_S5K4ECGX=m CONFIG_VIDEO_S5K5BAF=m # CONFIG_VIDEO_SMIAPP is not set CONFIG_VIDEO_ET8EK8=m # end of Camera sensor devices # # Lens drivers # CONFIG_VIDEO_AD5820=m CONFIG_VIDEO_AK7375=m CONFIG_VIDEO_DW9714=m # CONFIG_VIDEO_DW9807_VCM is not set # end of Lens drivers # # Flash devices # CONFIG_VIDEO_ADP1653=m # CONFIG_VIDEO_LM3560 is not set CONFIG_VIDEO_LM3646=m # end of Flash devices # # SPI helper chips # # end of SPI helper chips CONFIG_MEDIA_TUNER=m # # Customize TV tuners # CONFIG_MEDIA_TUNER_SIMPLE=m # CONFIG_MEDIA_TUNER_TDA18250 is not set # CONFIG_MEDIA_TUNER_TDA8290 is not set # CONFIG_MEDIA_TUNER_TDA827X is not set # CONFIG_MEDIA_TUNER_TDA18271 is not set CONFIG_MEDIA_TUNER_TDA9887=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_MEDIA_TUNER_TEA5767=m # CONFIG_MEDIA_TUNER_MT20XX is not set CONFIG_MEDIA_TUNER_MT2060=m CONFIG_MEDIA_TUNER_MT2063=m # CONFIG_MEDIA_TUNER_MT2266 is not set # CONFIG_MEDIA_TUNER_MT2131 is not set CONFIG_MEDIA_TUNER_QT1010=m # CONFIG_MEDIA_TUNER_XC2028 is not set # CONFIG_MEDIA_TUNER_XC5000 is not set CONFIG_MEDIA_TUNER_XC4000=m CONFIG_MEDIA_TUNER_MXL5005S=m CONFIG_MEDIA_TUNER_MXL5007T=m # CONFIG_MEDIA_TUNER_MC44S803 is not set # CONFIG_MEDIA_TUNER_MAX2165 is not set # CONFIG_MEDIA_TUNER_TDA18218 is not set CONFIG_MEDIA_TUNER_FC0011=m CONFIG_MEDIA_TUNER_FC0012=m # CONFIG_MEDIA_TUNER_FC0013 is not set CONFIG_MEDIA_TUNER_TDA18212=m # CONFIG_MEDIA_TUNER_E4000 is not set # CONFIG_MEDIA_TUNER_FC2580 is not set CONFIG_MEDIA_TUNER_M88RS6000T=m CONFIG_MEDIA_TUNER_TUA9001=m CONFIG_MEDIA_TUNER_SI2157=m CONFIG_MEDIA_TUNER_IT913X=m CONFIG_MEDIA_TUNER_R820T=m CONFIG_MEDIA_TUNER_MXL301RF=m CONFIG_MEDIA_TUNER_QM1D1C0042=m CONFIG_MEDIA_TUNER_QM1D1B0004=m # end of Customize TV tuners # # Customise DVB Frontends # # # Multistandard (satellite) frontends # CONFIG_DVB_STB0899=m CONFIG_DVB_STB6100=m CONFIG_DVB_STV090x=m CONFIG_DVB_STV0910=m CONFIG_DVB_STV6110x=m CONFIG_DVB_STV6111=m CONFIG_DVB_MXL5XX=m # # Multistandard (cable + terrestrial) frontends # # CONFIG_DVB_DRXK is not set CONFIG_DVB_TDA18271C2DD=m CONFIG_DVB_SI2165=m CONFIG_DVB_MN88472=m CONFIG_DVB_MN88473=m # # DVB-S (satellite) frontends # CONFIG_DVB_CX24110=m # CONFIG_DVB_CX24123 is not set # CONFIG_DVB_MT312 is not set # CONFIG_DVB_ZL10036 is not set CONFIG_DVB_ZL10039=m # CONFIG_DVB_S5H1420 is not set # CONFIG_DVB_STV0288 is not set # CONFIG_DVB_STB6000 is not set # CONFIG_DVB_STV0299 is not set CONFIG_DVB_STV6110=m CONFIG_DVB_STV0900=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA10086=m CONFIG_DVB_TDA8261=m # CONFIG_DVB_VES1X93 is not set # CONFIG_DVB_TUNER_ITD1000 is not set CONFIG_DVB_TUNER_CX24113=m # CONFIG_DVB_TDA826X is not set CONFIG_DVB_TUA6100=m CONFIG_DVB_CX24116=m CONFIG_DVB_CX24117=m # CONFIG_DVB_CX24120 is not set CONFIG_DVB_SI21XX=m CONFIG_DVB_TS2020=m CONFIG_DVB_DS3000=m # CONFIG_DVB_MB86A16 is not set CONFIG_DVB_TDA10071=m # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_S5H1432=m CONFIG_DVB_DRXD=m # CONFIG_DVB_L64781 is not set CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m # CONFIG_DVB_ZL10353 is not set # CONFIG_DVB_DIB3000MB is not set CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m CONFIG_DVB_DIB9000=m # CONFIG_DVB_TDA10048 is not set # CONFIG_DVB_EC100 is not set CONFIG_DVB_STV0367=m CONFIG_DVB_CXD2820R=m CONFIG_DVB_CXD2841ER=m CONFIG_DVB_ZD1301_DEMOD=m # # DVB-C (cable) frontends # CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m # CONFIG_DVB_TDA10023 is not set CONFIG_DVB_STV0297=m # # ATSC (North American/Korean Terrestrial/Cable DTV) frontends # CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_OR51132=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m CONFIG_DVB_LGDT3305=m CONFIG_DVB_LG2160=m # CONFIG_DVB_S5H1409 is not set CONFIG_DVB_AU8522=m CONFIG_DVB_AU8522_DTV=m CONFIG_DVB_AU8522_V4L=m # CONFIG_DVB_S5H1411 is not set # # ISDB-T (terrestrial) frontends # # CONFIG_DVB_S921 is not set CONFIG_DVB_DIB8000=m CONFIG_DVB_MB86A20S=m # # ISDB-S (satellite) & ISDB-T (terrestrial) frontends # CONFIG_DVB_TC90522=m CONFIG_DVB_MN88443X=m # # Digital terrestrial only tuners/PLL # CONFIG_DVB_PLL=m CONFIG_DVB_TUNER_DIB0070=m # CONFIG_DVB_TUNER_DIB0090 is not set # # SEC control devices for DVB-S # CONFIG_DVB_DRX39XYJ=m CONFIG_DVB_LNBH25=m CONFIG_DVB_LNBH29=m CONFIG_DVB_LNBP21=m # CONFIG_DVB_LNBP22 is not set CONFIG_DVB_ISL6405=m CONFIG_DVB_ISL6421=m CONFIG_DVB_ISL6423=m CONFIG_DVB_A8293=m CONFIG_DVB_LGS8GL5=m CONFIG_DVB_LGS8GXX=m CONFIG_DVB_ATBM8830=m CONFIG_DVB_TDA665x=m CONFIG_DVB_IX2505V=m CONFIG_DVB_M88RS2000=m # CONFIG_DVB_AF9033 is not set CONFIG_DVB_HORUS3A=m CONFIG_DVB_ASCOT2E=m CONFIG_DVB_HELENE=m # # Common Interface (EN50221) controller drivers # CONFIG_DVB_CXD2099=m # CONFIG_DVB_SP2 is not set # end of Customise DVB Frontends # # Tools to develop new frontends # CONFIG_DVB_DUMMY_FE=m # end of Media ancillary drivers # # Graphics support # CONFIG_AGP=m # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set CONFIG_AGP_SIS=m CONFIG_AGP_VIA=m CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 CONFIG_VGA_SWITCHEROO=y # CONFIG_DRM is not set # # ARM devices # # end of ARM devices # CONFIG_DRM_XEN is not set # # Frame buffer Devices # # CONFIG_FB is not set # end of Frame buffer Devices # # Backlight & LCD device support # # CONFIG_LCD_CLASS_DEVICE is not set # CONFIG_BACKLIGHT_CLASS_DEVICE is not set # end of Backlight & LCD device support CONFIG_HDMI=y # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set CONFIG_DUMMY_CONSOLE=y CONFIG_DUMMY_CONSOLE_COLUMNS=80 CONFIG_DUMMY_CONSOLE_ROWS=25 # end of Console display driver support # end of Graphics support CONFIG_SOUND=y CONFIG_SOUND_OSS_CORE=y # CONFIG_SOUND_OSS_CORE_PRECLAIM is not set CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_PCM_ELD=y CONFIG_SND_DMAENGINE_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_SEQ_DEVICE=m CONFIG_SND_RAWMIDI=m CONFIG_SND_COMPRESS_OFFLOAD=m CONFIG_SND_JACK=y CONFIG_SND_JACK_INPUT_DEV=y CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m # CONFIG_SND_PCM_OSS is not set CONFIG_SND_PCM_TIMER=y CONFIG_SND_HRTIMER=m CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_MAX_CARDS=32 # CONFIG_SND_SUPPORT_OLD_API is not set CONFIG_SND_PROC_FS=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_VMASTER=y CONFIG_SND_DMA_SGBUF=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_SEQUENCER_OSS=m # CONFIG_SND_SEQ_HRTIMER_DEFAULT is not set CONFIG_SND_SEQ_MIDI_EVENT=m CONFIG_SND_SEQ_MIDI=m CONFIG_SND_SEQ_VIRMIDI=m CONFIG_SND_MPU401_UART=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y # CONFIG_SND_PCSP is not set CONFIG_SND_DUMMY=m CONFIG_SND_ALOOP=m CONFIG_SND_VIRMIDI=m # CONFIG_SND_MTPAV is not set CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 # CONFIG_SND_PCI is not set # # HD-Audio # CONFIG_SND_HDA=m CONFIG_SND_HDA_HWDEP=y # CONFIG_SND_HDA_RECONFIG is not set # CONFIG_SND_HDA_INPUT_BEEP is not set # CONFIG_SND_HDA_PATCH_LOADER is not set CONFIG_SND_HDA_CODEC_REALTEK=m CONFIG_SND_HDA_CODEC_ANALOG=m CONFIG_SND_HDA_CODEC_SIGMATEL=m CONFIG_SND_HDA_CODEC_VIA=m # CONFIG_SND_HDA_CODEC_HDMI is not set CONFIG_SND_HDA_CODEC_CIRRUS=m CONFIG_SND_HDA_CODEC_CONEXANT=m CONFIG_SND_HDA_CODEC_CA0110=m CONFIG_SND_HDA_CODEC_CA0132=m CONFIG_SND_HDA_CODEC_CA0132_DSP=y CONFIG_SND_HDA_CODEC_CMEDIA=m # CONFIG_SND_HDA_CODEC_SI3054 is not set CONFIG_SND_HDA_GENERIC=m CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0 # end of HD-Audio CONFIG_SND_HDA_CORE=m CONFIG_SND_HDA_DSP_LOADER=y CONFIG_SND_HDA_EXT_CORE=m CONFIG_SND_HDA_PREALLOC_SIZE=2048 CONFIG_SND_INTEL_NHLT=y CONFIG_SND_INTEL_DSP_CONFIG=m # CONFIG_SND_FIREWIRE is not set CONFIG_SND_SOC=m CONFIG_SND_SOC_AC97_BUS=y CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM=y CONFIG_SND_SOC_COMPRESS=y CONFIG_SND_SOC_TOPOLOGY=y CONFIG_SND_SOC_ACPI=m CONFIG_SND_SOC_AMD_ACP=m CONFIG_SND_SOC_AMD_CZ_DA7219MX98357_MACH=m CONFIG_SND_SOC_AMD_CZ_RT5645_MACH=m CONFIG_SND_SOC_AMD_ACP3x=m CONFIG_SND_SOC_AMD_RV_RT5682_MACH=m # CONFIG_SND_SOC_AMD_RENOIR is not set CONFIG_SND_ATMEL_SOC=m CONFIG_SND_SOC_MIKROE_PROTO=m CONFIG_SND_BCM63XX_I2S_WHISTLER=m CONFIG_SND_DESIGNWARE_I2S=m CONFIG_SND_DESIGNWARE_PCM=y # # SoC Audio for Freescale CPUs # # # Common SoC Audio options for Freescale CPUs: # CONFIG_SND_SOC_FSL_ASRC=m CONFIG_SND_SOC_FSL_SAI=m CONFIG_SND_SOC_FSL_MQS=m CONFIG_SND_SOC_FSL_AUDMIX=m CONFIG_SND_SOC_FSL_SSI=m CONFIG_SND_SOC_FSL_SPDIF=m # CONFIG_SND_SOC_FSL_ESAI is not set # CONFIG_SND_SOC_FSL_MICFIL is not set # CONFIG_SND_SOC_FSL_EASRC is not set CONFIG_SND_SOC_IMX_AUDMUX=m # end of SoC Audio for Freescale CPUs # CONFIG_SND_I2S_HI6210_I2S is not set CONFIG_SND_SOC_IMG=y CONFIG_SND_SOC_IMG_I2S_IN=m CONFIG_SND_SOC_IMG_I2S_OUT=m CONFIG_SND_SOC_IMG_PARALLEL_OUT=m CONFIG_SND_SOC_IMG_SPDIF_IN=m CONFIG_SND_SOC_IMG_SPDIF_OUT=m # CONFIG_SND_SOC_IMG_PISTACHIO_INTERNAL_DAC is not set CONFIG_SND_SOC_INTEL_SST_TOPLEVEL=y CONFIG_SND_SST_IPC=m CONFIG_SND_SST_IPC_PCI=m CONFIG_SND_SST_IPC_ACPI=m CONFIG_SND_SOC_INTEL_SST_ACPI=m CONFIG_SND_SOC_INTEL_SST=m CONFIG_SND_SOC_INTEL_SST_FIRMWARE=m CONFIG_SND_SOC_INTEL_HASWELL=m CONFIG_SND_SST_ATOM_HIFI2_PLATFORM=m CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_PCI=m CONFIG_SND_SST_ATOM_HIFI2_PLATFORM_ACPI=m CONFIG_SND_SOC_INTEL_SKYLAKE=m CONFIG_SND_SOC_INTEL_SKL=m CONFIG_SND_SOC_INTEL_APL=m CONFIG_SND_SOC_INTEL_KBL=m CONFIG_SND_SOC_INTEL_GLK=m CONFIG_SND_SOC_INTEL_CNL=m CONFIG_SND_SOC_INTEL_CFL=m CONFIG_SND_SOC_INTEL_CML_H=m # CONFIG_SND_SOC_INTEL_CML_LP is not set CONFIG_SND_SOC_INTEL_SKYLAKE_FAMILY=m CONFIG_SND_SOC_INTEL_SKYLAKE_SSP_CLK=m CONFIG_SND_SOC_INTEL_SKYLAKE_HDAUDIO_CODEC=y CONFIG_SND_SOC_INTEL_SKYLAKE_COMMON=m CONFIG_SND_SOC_ACPI_INTEL_MATCH=m CONFIG_SND_SOC_INTEL_MACH=y # CONFIG_SND_SOC_INTEL_USER_FRIENDLY_LONG_NAMES is not set # CONFIG_SND_SOC_INTEL_SKL_RT286_MACH is not set CONFIG_SND_SOC_INTEL_SKL_NAU88L25_SSM4567_MACH=m CONFIG_SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH=m CONFIG_SND_SOC_INTEL_DA7219_MAX98357A_GENERIC=m # CONFIG_SND_SOC_INTEL_BXT_RT298_MACH is not set CONFIG_SND_SOC_INTEL_KBL_RT5663_MAX98927_MACH=m CONFIG_SND_SOC_INTEL_KBL_DA7219_MAX98357A_MACH=m # CONFIG_SND_SOC_INTEL_KBL_DA7219_MAX98927_MACH is not set # CONFIG_SND_SOC_INTEL_KBL_RT5660_MACH is not set CONFIG_SND_SOC_MTK_BTCVSD=m # CONFIG_SND_SOC_SOF_TOPLEVEL is not set # # STMicroelectronics STM32 SOC audio support # # end of STMicroelectronics STM32 SOC audio support CONFIG_SND_SOC_XILINX_I2S=m CONFIG_SND_SOC_XILINX_AUDIO_FORMATTER=m # CONFIG_SND_SOC_XILINX_SPDIF is not set CONFIG_SND_SOC_XTFPGA_I2S=m CONFIG_ZX_TDM=m CONFIG_SND_SOC_I2C_AND_SPI=m # # CODEC drivers # CONFIG_SND_SOC_AC97_CODEC=m CONFIG_SND_SOC_ADAU1701=m # CONFIG_SND_SOC_ADAU1761_I2C is not set CONFIG_SND_SOC_ADAU7002=m CONFIG_SND_SOC_ADAU7118=m CONFIG_SND_SOC_ADAU7118_HW=m # CONFIG_SND_SOC_ADAU7118_I2C is not set CONFIG_SND_SOC_AK4118=m CONFIG_SND_SOC_AK4458=m CONFIG_SND_SOC_AK4554=m CONFIG_SND_SOC_AK4613=m CONFIG_SND_SOC_AK4642=m CONFIG_SND_SOC_AK5386=m CONFIG_SND_SOC_AK5558=m CONFIG_SND_SOC_ALC5623=m CONFIG_SND_SOC_BD28623=m # CONFIG_SND_SOC_BT_SCO is not set CONFIG_SND_SOC_CROS_EC_CODEC=m CONFIG_SND_SOC_CS35L32=m CONFIG_SND_SOC_CS35L33=m CONFIG_SND_SOC_CS35L34=m # CONFIG_SND_SOC_CS35L35 is not set CONFIG_SND_SOC_CS35L36=m # CONFIG_SND_SOC_CS42L42 is not set CONFIG_SND_SOC_CS42L51=m CONFIG_SND_SOC_CS42L51_I2C=m CONFIG_SND_SOC_CS42L52=m CONFIG_SND_SOC_CS42L56=m # CONFIG_SND_SOC_CS42L73 is not set # CONFIG_SND_SOC_CS4265 is not set # CONFIG_SND_SOC_CS4270 is not set # CONFIG_SND_SOC_CS4271_I2C is not set CONFIG_SND_SOC_CS42XX8=m CONFIG_SND_SOC_CS42XX8_I2C=m CONFIG_SND_SOC_CS43130=m # CONFIG_SND_SOC_CS4341 is not set CONFIG_SND_SOC_CS4349=m # CONFIG_SND_SOC_CS53L30 is not set CONFIG_SND_SOC_CX2072X=m CONFIG_SND_SOC_DA7213=m CONFIG_SND_SOC_DA7219=m CONFIG_SND_SOC_DMIC=m # CONFIG_SND_SOC_ES7134 is not set CONFIG_SND_SOC_ES7241=m # CONFIG_SND_SOC_ES8316 is not set CONFIG_SND_SOC_ES8328=m CONFIG_SND_SOC_ES8328_I2C=m CONFIG_SND_SOC_GTM601=m CONFIG_SND_SOC_HDAC_HDMI=m CONFIG_SND_SOC_HDAC_HDA=m CONFIG_SND_SOC_INNO_RK3036=m CONFIG_SND_SOC_MAX98088=m CONFIG_SND_SOC_MAX98357A=m CONFIG_SND_SOC_MAX98504=m CONFIG_SND_SOC_MAX9867=m CONFIG_SND_SOC_MAX98927=m CONFIG_SND_SOC_MAX98373=m CONFIG_SND_SOC_MAX98390=m CONFIG_SND_SOC_MAX9860=m CONFIG_SND_SOC_MSM8916_WCD_ANALOG=m CONFIG_SND_SOC_MSM8916_WCD_DIGITAL=m # CONFIG_SND_SOC_PCM1681 is not set CONFIG_SND_SOC_PCM1789=m CONFIG_SND_SOC_PCM1789_I2C=m CONFIG_SND_SOC_PCM179X=m CONFIG_SND_SOC_PCM179X_I2C=m CONFIG_SND_SOC_PCM186X=m CONFIG_SND_SOC_PCM186X_I2C=m # CONFIG_SND_SOC_PCM3060_I2C is not set # CONFIG_SND_SOC_PCM3168A_I2C is not set # CONFIG_SND_SOC_PCM512x_I2C is not set CONFIG_SND_SOC_RK3328=m CONFIG_SND_SOC_RL6231=m CONFIG_SND_SOC_RT1308_SDW=m CONFIG_SND_SOC_RT5616=m CONFIG_SND_SOC_RT5631=m CONFIG_SND_SOC_RT5645=m CONFIG_SND_SOC_RT5663=m CONFIG_SND_SOC_RT5682=m CONFIG_SND_SOC_RT5682_I2C=m # CONFIG_SND_SOC_RT5682_SDW is not set CONFIG_SND_SOC_RT700=m CONFIG_SND_SOC_RT700_SDW=m # CONFIG_SND_SOC_RT711_SDW is not set CONFIG_SND_SOC_RT715=m CONFIG_SND_SOC_RT715_SDW=m CONFIG_SND_SOC_SGTL5000=m CONFIG_SND_SOC_SIGMADSP=m CONFIG_SND_SOC_SIGMADSP_I2C=m CONFIG_SND_SOC_SIMPLE_AMPLIFIER=m # CONFIG_SND_SOC_SIRF_AUDIO_CODEC is not set CONFIG_SND_SOC_SPDIF=m CONFIG_SND_SOC_SSM2305=m CONFIG_SND_SOC_SSM2602=m CONFIG_SND_SOC_SSM2602_I2C=m CONFIG_SND_SOC_SSM4567=m CONFIG_SND_SOC_STA32X=m CONFIG_SND_SOC_STA350=m # CONFIG_SND_SOC_STI_SAS is not set CONFIG_SND_SOC_TAS2552=m CONFIG_SND_SOC_TAS2562=m CONFIG_SND_SOC_TAS2770=m # CONFIG_SND_SOC_TAS5086 is not set CONFIG_SND_SOC_TAS571X=m CONFIG_SND_SOC_TAS5720=m # CONFIG_SND_SOC_TAS6424 is not set # CONFIG_SND_SOC_TDA7419 is not set # CONFIG_SND_SOC_TFA9879 is not set CONFIG_SND_SOC_TLV320AIC23=m CONFIG_SND_SOC_TLV320AIC23_I2C=m # CONFIG_SND_SOC_TLV320AIC31XX is not set # CONFIG_SND_SOC_TLV320AIC32X4_I2C is not set CONFIG_SND_SOC_TLV320AIC3X=m CONFIG_SND_SOC_TLV320ADCX140=m # CONFIG_SND_SOC_TS3A227E is not set CONFIG_SND_SOC_TSCS42XX=m CONFIG_SND_SOC_TSCS454=m CONFIG_SND_SOC_UDA1334=m CONFIG_SND_SOC_WM8510=m CONFIG_SND_SOC_WM8523=m CONFIG_SND_SOC_WM8524=m CONFIG_SND_SOC_WM8580=m # CONFIG_SND_SOC_WM8711 is not set CONFIG_SND_SOC_WM8728=m CONFIG_SND_SOC_WM8731=m # CONFIG_SND_SOC_WM8737 is not set CONFIG_SND_SOC_WM8741=m CONFIG_SND_SOC_WM8750=m # CONFIG_SND_SOC_WM8753 is not set CONFIG_SND_SOC_WM8776=m CONFIG_SND_SOC_WM8782=m # CONFIG_SND_SOC_WM8804_I2C is not set CONFIG_SND_SOC_WM8903=m # CONFIG_SND_SOC_WM8904 is not set # CONFIG_SND_SOC_WM8960 is not set CONFIG_SND_SOC_WM8962=m # CONFIG_SND_SOC_WM8974 is not set # CONFIG_SND_SOC_WM8978 is not set CONFIG_SND_SOC_WM8985=m CONFIG_SND_SOC_WSA881X=m CONFIG_SND_SOC_ZX_AUD96P22=m CONFIG_SND_SOC_MAX9759=m CONFIG_SND_SOC_MT6351=m # CONFIG_SND_SOC_MT6358 is not set # CONFIG_SND_SOC_MT6660 is not set CONFIG_SND_SOC_NAU8540=m CONFIG_SND_SOC_NAU8810=m CONFIG_SND_SOC_NAU8822=m CONFIG_SND_SOC_NAU8824=m CONFIG_SND_SOC_NAU8825=m CONFIG_SND_SOC_TPA6130A2=m # end of CODEC drivers CONFIG_SND_SIMPLE_CARD_UTILS=m CONFIG_SND_SIMPLE_CARD=m CONFIG_SND_AUDIO_GRAPH_CARD=m # CONFIG_SND_X86 is not set # CONFIG_SND_XEN_FRONTEND is not set CONFIG_AC97_BUS=m # # HID support # # CONFIG_HID is not set # # I2C HID support # # CONFIG_I2C_HID is not set # end of I2C HID support # # Intel ISH HID support # # CONFIG_INTEL_ISH_HID is not set # end of Intel ISH HID support # end of HID support CONFIG_USB_OHCI_LITTLE_ENDIAN=y # CONFIG_USB_SUPPORT is not set CONFIG_MMC=y # CONFIG_PWRSEQ_EMMC is not set # CONFIG_PWRSEQ_SIMPLE is not set # CONFIG_MMC_BLOCK is not set # CONFIG_SDIO_UART is not set CONFIG_MMC_TEST=m # # MMC/SD/SDIO Host Controller Drivers # # CONFIG_MMC_DEBUG is not set CONFIG_MMC_SDHCI=m # CONFIG_MMC_SDHCI_PCI is not set CONFIG_MMC_SDHCI_ACPI=m # CONFIG_MMC_SDHCI_PLTFM is not set CONFIG_MMC_WBSD=y CONFIG_MMC_ALCOR=y CONFIG_MMC_TIFM_SD=y CONFIG_MMC_CB710=m # CONFIG_MMC_VIA_SDMMC is not set CONFIG_MMC_USDHI6ROL0=y CONFIG_MMC_REALTEK_PCI=y CONFIG_MMC_CQHCI=m CONFIG_MMC_HSQ=y CONFIG_MMC_TOSHIBA_PCI=y CONFIG_MMC_MTK=y CONFIG_MEMSTICK=y CONFIG_MEMSTICK_DEBUG=y # # MemoryStick drivers # CONFIG_MEMSTICK_UNSAFE_RESUME=y # CONFIG_MSPRO_BLOCK is not set CONFIG_MS_BLOCK=m # # MemoryStick Host Controller Drivers # # CONFIG_MEMSTICK_TIFM_MS is not set CONFIG_MEMSTICK_JMICRON_38X=m CONFIG_MEMSTICK_R592=y CONFIG_MEMSTICK_REALTEK_PCI=m CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=m CONFIG_LEDS_CLASS_FLASH=m CONFIG_LEDS_BRIGHTNESS_HW_CHANGED=y # # LED drivers # CONFIG_LEDS_AAT1290=m # CONFIG_LEDS_AN30259A is not set CONFIG_LEDS_APU=m CONFIG_LEDS_AS3645A=m CONFIG_LEDS_AW2013=m CONFIG_LEDS_BCM6328=m CONFIG_LEDS_BCM6358=m CONFIG_LEDS_LM3530=m # CONFIG_LEDS_LM3532 is not set # CONFIG_LEDS_LM3533 is not set CONFIG_LEDS_LM3642=m CONFIG_LEDS_LM3692X=m CONFIG_LEDS_LM3601X=m CONFIG_LEDS_MT6323=m CONFIG_LEDS_PCA9532=m CONFIG_LEDS_PCA9532_GPIO=y CONFIG_LEDS_GPIO=m CONFIG_LEDS_LP3944=m # CONFIG_LEDS_LP3952 is not set CONFIG_LEDS_LP55XX_COMMON=m # CONFIG_LEDS_LP5521 is not set CONFIG_LEDS_LP5523=m CONFIG_LEDS_LP5562=m CONFIG_LEDS_LP8501=m # CONFIG_LEDS_LP8860 is not set # CONFIG_LEDS_CLEVO_MAIL is not set CONFIG_LEDS_PCA955X=m CONFIG_LEDS_PCA955X_GPIO=y # CONFIG_LEDS_PCA963X is not set CONFIG_LEDS_REGULATOR=m CONFIG_LEDS_BD2802=m CONFIG_LEDS_INTEL_SS4200=m # CONFIG_LEDS_LT3593 is not set # CONFIG_LEDS_MC13783 is not set # CONFIG_LEDS_TCA6507 is not set # CONFIG_LEDS_TLC591XX is not set CONFIG_LEDS_MAX77650=m CONFIG_LEDS_LM355x=m CONFIG_LEDS_KTD2692=m CONFIG_LEDS_IS31FL319X=m # CONFIG_LEDS_IS31FL32XX is not set # # LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM) # CONFIG_LEDS_BLINKM=m CONFIG_LEDS_MLXCPLD=m CONFIG_LEDS_MLXREG=m # CONFIG_LEDS_USER is not set # CONFIG_LEDS_NIC78BX is not set CONFIG_LEDS_TI_LMU_COMMON=m CONFIG_LEDS_LM3697=m # CONFIG_LEDS_LM36274 is not set CONFIG_LEDS_SGM3140=m # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m # CONFIG_LEDS_TRIGGER_ONESHOT is not set CONFIG_LEDS_TRIGGER_DISK=y CONFIG_LEDS_TRIGGER_MTD=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y # CONFIG_LEDS_TRIGGER_BACKLIGHT is not set CONFIG_LEDS_TRIGGER_CPU=y CONFIG_LEDS_TRIGGER_ACTIVITY=m CONFIG_LEDS_TRIGGER_GPIO=m CONFIG_LEDS_TRIGGER_DEFAULT_ON=m # # iptables trigger is under Netfilter config (LED target) # CONFIG_LEDS_TRIGGER_TRANSIENT=y # CONFIG_LEDS_TRIGGER_CAMERA is not set # CONFIG_LEDS_TRIGGER_PANIC is not set CONFIG_LEDS_TRIGGER_PATTERN=y CONFIG_LEDS_TRIGGER_AUDIO=y # CONFIG_ACCESSIBILITY is not set CONFIG_EDAC_ATOMIC_SCRUB=y CONFIG_EDAC_SUPPORT=y # CONFIG_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_MC146818_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_SYSTOHC=y CONFIG_RTC_SYSTOHC_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set CONFIG_RTC_NVMEM=y # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y # CONFIG_RTC_INTF_DEV is not set CONFIG_RTC_DRV_TEST=y # # I2C RTC drivers # # CONFIG_RTC_DRV_88PM80X is not set # CONFIG_RTC_DRV_ABB5ZES3 is not set CONFIG_RTC_DRV_ABEOZ9=m CONFIG_RTC_DRV_ABX80X=m CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1307_CENTURY=y CONFIG_RTC_DRV_DS1374=m # CONFIG_RTC_DRV_DS1374_WDT is not set CONFIG_RTC_DRV_DS1672=m # CONFIG_RTC_DRV_HYM8563 is not set CONFIG_RTC_DRV_MAX6900=m # CONFIG_RTC_DRV_MAX8907 is not set # CONFIG_RTC_DRV_RS5C372 is not set CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_ISL12022=m # CONFIG_RTC_DRV_ISL12026 is not set CONFIG_RTC_DRV_X1205=m # CONFIG_RTC_DRV_PCF8523 is not set CONFIG_RTC_DRV_PCF85063=m CONFIG_RTC_DRV_PCF85363=m CONFIG_RTC_DRV_PCF8563=m # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set CONFIG_RTC_DRV_BQ32K=m CONFIG_RTC_DRV_RC5T619=m # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # CONFIG_RTC_DRV_RX8010 is not set CONFIG_RTC_DRV_RX8581=m CONFIG_RTC_DRV_RX8025=m # CONFIG_RTC_DRV_EM3027 is not set # CONFIG_RTC_DRV_RV3028 is not set # CONFIG_RTC_DRV_RV8803 is not set CONFIG_RTC_DRV_SD3078=m # # SPI RTC drivers # CONFIG_RTC_I2C_AND_SPI=m # # SPI and I2C RTC drivers # CONFIG_RTC_DRV_DS3232=m # CONFIG_RTC_DRV_DS3232_HWMON is not set CONFIG_RTC_DRV_PCF2127=m CONFIG_RTC_DRV_RV3029C2=m CONFIG_RTC_DRV_RV3029_HWMON=y # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=m CONFIG_RTC_DRV_DS1286=y CONFIG_RTC_DRV_DS1511=m # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1685_FAMILY is not set CONFIG_RTC_DRV_DS1742=y CONFIG_RTC_DRV_DS2404=m # CONFIG_RTC_DRV_DA9063 is not set CONFIG_RTC_DRV_STK17TA8=y CONFIG_RTC_DRV_M48T86=y CONFIG_RTC_DRV_M48T35=m # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_MSM6242 is not set CONFIG_RTC_DRV_BQ4802=m # CONFIG_RTC_DRV_RP5C01 is not set # CONFIG_RTC_DRV_V3020 is not set CONFIG_RTC_DRV_PCF50633=m # CONFIG_RTC_DRV_ZYNQMP is not set # CONFIG_RTC_DRV_CROS_EC is not set # # on-CPU RTC drivers # # CONFIG_RTC_DRV_CADENCE is not set CONFIG_RTC_DRV_FTRTC010=m CONFIG_RTC_DRV_MC13XXX=m CONFIG_RTC_DRV_MT6397=m CONFIG_RTC_DRV_R7301=y # # HID Sensor RTC drivers # CONFIG_RTC_DRV_WILCO_EC=m CONFIG_DMADEVICES=y CONFIG_DMADEVICES_DEBUG=y # CONFIG_DMADEVICES_VDEBUG is not set # # DMA Devices # CONFIG_DMA_ENGINE=y CONFIG_DMA_VIRTUAL_CHANNELS=y CONFIG_DMA_ACPI=y CONFIG_DMA_OF=y CONFIG_ALTERA_MSGDMA=y CONFIG_DW_AXI_DMAC=y CONFIG_FSL_EDMA=y CONFIG_INTEL_IDMA64=m CONFIG_INTEL_IDXD=y # CONFIG_INTEL_IOATDMA is not set # CONFIG_INTEL_MIC_X100_DMA is not set # CONFIG_PLX_DMA is not set CONFIG_QCOM_HIDMA_MGMT=y CONFIG_QCOM_HIDMA=m CONFIG_DW_DMAC_CORE=y CONFIG_DW_DMAC=y # CONFIG_DW_DMAC_PCI is not set CONFIG_DW_EDMA=y CONFIG_DW_EDMA_PCIE=m CONFIG_HSU_DMA=m CONFIG_SF_PDMA=y # # DMA Clients # # CONFIG_ASYNC_TX_DMA is not set # CONFIG_DMATEST is not set # # DMABUF options # # CONFIG_SYNC_FILE is not set # CONFIG_UDMABUF is not set # CONFIG_DMABUF_MOVE_NOTIFY is not set CONFIG_DMABUF_SELFTESTS=y # CONFIG_DMABUF_HEAPS is not set # end of DMABUF options CONFIG_AUXDISPLAY=y CONFIG_HD44780=y CONFIG_IMG_ASCII_LCD=y CONFIG_PANEL_CHANGE_MESSAGE=y CONFIG_PANEL_BOOT_MESSAGE="" CONFIG_CHARLCD_BL_OFF=y # CONFIG_CHARLCD_BL_ON is not set # CONFIG_CHARLCD_BL_FLASH is not set CONFIG_CHARLCD=y CONFIG_UIO=y CONFIG_UIO_CIF=y CONFIG_UIO_PDRV_GENIRQ=y CONFIG_UIO_DMEM_GENIRQ=m CONFIG_UIO_AEC=m CONFIG_UIO_SERCOS3=y CONFIG_UIO_PCI_GENERIC=y CONFIG_UIO_NETX=y CONFIG_UIO_PRUSS=y CONFIG_UIO_MF624=m # CONFIG_UIO_HV_GENERIC is not set # CONFIG_VFIO is not set # CONFIG_VIRT_DRIVERS is not set CONFIG_VIRTIO=y # CONFIG_VIRTIO_MENU is not set CONFIG_VDPA=m # CONFIG_VDPA_SIM is not set CONFIG_IFCVF=m CONFIG_VHOST_IOTLB=y CONFIG_VHOST_RING=y CONFIG_VHOST=m CONFIG_VHOST_MENU=y CONFIG_VHOST_SCSI=m CONFIG_VHOST_VDPA=m # CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set # # Microsoft Hyper-V guest support # CONFIG_HYPERV=y CONFIG_HYPERV_TIMER=y CONFIG_HYPERV_BALLOON=m # end of Microsoft Hyper-V guest support # # Xen driver support # # CONFIG_XEN_BALLOON is not set CONFIG_XEN_DEV_EVTCHN=y CONFIG_XEN_BACKEND=y CONFIG_XENFS=y # CONFIG_XEN_COMPAT_XENFS is not set CONFIG_XEN_SYS_HYPERVISOR=y CONFIG_XEN_XENBUS_FRONTEND=m CONFIG_XEN_GNTDEV=y # CONFIG_XEN_GRANT_DEV_ALLOC is not set # CONFIG_XEN_GRANT_DMA_ALLOC is not set CONFIG_SWIOTLB_XEN=y CONFIG_XEN_PCIDEV_BACKEND=m CONFIG_XEN_SCSI_BACKEND=m CONFIG_XEN_PRIVCMD=y CONFIG_XEN_HAVE_PVMMU=y CONFIG_XEN_AUTO_XLATE=y CONFIG_XEN_ACPI=y CONFIG_XEN_HAVE_VPMU=y # end of Xen driver support CONFIG_GREYBUS=y # CONFIG_STAGING is not set # CONFIG_X86_PLATFORM_DEVICES is not set CONFIG_PMC_ATOM=y # CONFIG_MFD_CROS_EC is not set CONFIG_CHROME_PLATFORMS=y CONFIG_CHROMEOS_LAPTOP=m CONFIG_CHROMEOS_PSTORE=m # CONFIG_CHROMEOS_TBMC is not set CONFIG_CROS_EC=m # CONFIG_CROS_EC_I2C is not set CONFIG_CROS_EC_LPC=m CONFIG_CROS_EC_PROTO=y CONFIG_CROS_KBD_LED_BACKLIGHT=m CONFIG_CROS_EC_CHARDEV=m CONFIG_CROS_EC_LIGHTBAR=m CONFIG_CROS_EC_VBC=m # CONFIG_CROS_EC_DEBUGFS is not set CONFIG_CROS_EC_SENSORHUB=m CONFIG_CROS_EC_SYSFS=m CONFIG_CROS_USBPD_NOTIFY=m CONFIG_WILCO_EC=m # CONFIG_WILCO_EC_DEBUGFS is not set CONFIG_WILCO_EC_EVENTS=m CONFIG_WILCO_EC_TELEMETRY=m CONFIG_MELLANOX_PLATFORM=y CONFIG_MLXREG_HOTPLUG=m # CONFIG_MLXREG_IO is not set CONFIG_HAVE_CLK=y CONFIG_CLKDEV_LOOKUP=y CONFIG_HAVE_CLK_PREPARE=y CONFIG_COMMON_CLK=y # CONFIG_CLK_HSDK is not set CONFIG_COMMON_CLK_MAX9485=m CONFIG_COMMON_CLK_SI5341=m CONFIG_COMMON_CLK_SI5351=m CONFIG_COMMON_CLK_SI514=m CONFIG_COMMON_CLK_SI544=m CONFIG_COMMON_CLK_SI570=m CONFIG_COMMON_CLK_CDCE706=m CONFIG_COMMON_CLK_CDCE925=m CONFIG_COMMON_CLK_CS2000_CP=m CONFIG_COMMON_CLK_VC5=m # CONFIG_COMMON_CLK_FIXED_MMIO is not set CONFIG_CLK_LGM_CGU=y CONFIG_HWSPINLOCK=y # # Clock Source drivers # CONFIG_CLKEVT_I8253=y CONFIG_I8253_LOCK=y CONFIG_CLKBLD_I8253=y # CONFIG_MICROCHIP_PIT64B is not set # end of Clock Source drivers # CONFIG_MAILBOX is not set CONFIG_IOMMU_IOVA=y CONFIG_IOASID=y CONFIG_IOMMU_API=y CONFIG_IOMMU_SUPPORT=y # # Generic IOMMU Pagetable Support # # end of Generic IOMMU Pagetable Support CONFIG_IOMMU_DEBUGFS=y CONFIG_IOMMU_DEFAULT_PASSTHROUGH=y CONFIG_OF_IOMMU=y # CONFIG_AMD_IOMMU is not set CONFIG_DMAR_TABLE=y CONFIG_INTEL_IOMMU=y CONFIG_INTEL_IOMMU_DEBUGFS=y # CONFIG_INTEL_IOMMU_SVM is not set # CONFIG_INTEL_IOMMU_DEFAULT_ON is not set CONFIG_INTEL_IOMMU_FLOPPY_WA=y CONFIG_INTEL_IOMMU_SCALABLE_MODE_DEFAULT_ON=y CONFIG_IRQ_REMAP=y CONFIG_HYPERV_IOMMU=y # # Remoteproc drivers # # CONFIG_REMOTEPROC is not set # end of Remoteproc drivers # # Rpmsg drivers # # CONFIG_RPMSG_VIRTIO is not set # end of Rpmsg drivers CONFIG_SOUNDWIRE=y # # SoundWire Devices # # CONFIG_SOUNDWIRE_INTEL is not set # # SOC (System On Chip) specific Drivers # # # Amlogic SoC drivers # # end of Amlogic SoC drivers # # Aspeed SoC drivers # # end of Aspeed SoC drivers # # Broadcom SoC drivers # # end of Broadcom SoC drivers # # NXP/Freescale QorIQ SoC drivers # # end of NXP/Freescale QorIQ SoC drivers # # i.MX SoC drivers # # end of i.MX SoC drivers # # Qualcomm SoC drivers # # end of Qualcomm SoC drivers CONFIG_SOC_TI=y # # Xilinx SoC drivers # # CONFIG_XILINX_VCU is not set # end of Xilinx SoC drivers # end of SOC (System On Chip) specific Drivers # CONFIG_PM_DEVFREQ is not set CONFIG_EXTCON=y # # Extcon Device Drivers # CONFIG_EXTCON_FSA9480=m CONFIG_EXTCON_GPIO=m # CONFIG_EXTCON_INTEL_INT3496 is not set # CONFIG_EXTCON_MAX14577 is not set CONFIG_EXTCON_MAX3355=y CONFIG_EXTCON_PTN5150=m CONFIG_EXTCON_RT8973A=m CONFIG_EXTCON_SM5502=m CONFIG_EXTCON_USB_GPIO=m CONFIG_EXTCON_USBC_CROS_EC=m CONFIG_MEMORY=y # CONFIG_IIO is not set CONFIG_NTB=y CONFIG_NTB_MSI=y CONFIG_NTB_AMD=m CONFIG_NTB_IDT=m CONFIG_NTB_INTEL=y # CONFIG_NTB_SWITCHTEC is not set CONFIG_NTB_PINGPONG=y CONFIG_NTB_TOOL=y # CONFIG_NTB_PERF is not set # CONFIG_NTB_MSI_TEST is not set CONFIG_NTB_TRANSPORT=m CONFIG_VME_BUS=y # # VME Bridge Drivers # CONFIG_VME_CA91CX42=m CONFIG_VME_TSI148=y CONFIG_VME_FAKE=y # # VME Board Drivers # # CONFIG_VMIVME_7805 is not set # # VME Device Drivers # # CONFIG_PWM is not set # # IRQ chip support # CONFIG_IRQCHIP=y # CONFIG_AL_FIC is not set # end of IRQ chip support CONFIG_IPACK_BUS=y CONFIG_BOARD_TPCI200=m CONFIG_SERIAL_IPOCTAL=y # CONFIG_RESET_CONTROLLER is not set # # PHY Subsystem # CONFIG_GENERIC_PHY=y CONFIG_GENERIC_PHY_MIPI_DPHY=y # CONFIG_BCM_KONA_USB2_PHY is not set # CONFIG_PHY_CADENCE_TORRENT is not set CONFIG_PHY_CADENCE_DPHY=y CONFIG_PHY_CADENCE_SALVO=y CONFIG_PHY_FSL_IMX8MQ_USB=m CONFIG_PHY_MIXEL_MIPI_DPHY=y CONFIG_PHY_PXA_28NM_HSIC=m CONFIG_PHY_PXA_28NM_USB2=y CONFIG_PHY_OCELOT_SERDES=m # CONFIG_PHY_INTEL_COMBO is not set # CONFIG_PHY_INTEL_EMMC is not set # end of PHY Subsystem # CONFIG_POWERCAP is not set CONFIG_MCB=y CONFIG_MCB_PCI=m # CONFIG_MCB_LPC is not set # # Performance monitor support # # end of Performance monitor support CONFIG_RAS=y # CONFIG_USB4 is not set # # Android # CONFIG_ANDROID=y # CONFIG_ANDROID_BINDER_IPC is not set # end of Android CONFIG_DAX=y # CONFIG_DEV_DAX is not set CONFIG_NVMEM=y CONFIG_NVMEM_SYSFS=y CONFIG_NVMEM_SPMI_SDAM=m # CONFIG_RAVE_SP_EEPROM is not set # # HW tracing support # CONFIG_STM=y CONFIG_STM_PROTO_BASIC=m # CONFIG_STM_PROTO_SYS_T is not set CONFIG_STM_DUMMY=y CONFIG_STM_SOURCE_CONSOLE=m CONFIG_STM_SOURCE_HEARTBEAT=m CONFIG_STM_SOURCE_FTRACE=m # CONFIG_INTEL_TH is not set # end of HW tracing support # CONFIG_FPGA is not set CONFIG_FSI=m CONFIG_FSI_NEW_DEV_NODE=y CONFIG_FSI_MASTER_GPIO=m CONFIG_FSI_MASTER_HUB=m # CONFIG_FSI_MASTER_ASPEED is not set # CONFIG_FSI_SCOM is not set CONFIG_FSI_SBEFIFO=m CONFIG_FSI_OCC=m CONFIG_TEE=m # # TEE drivers # # end of TEE drivers CONFIG_UNISYS_VISORBUS=m CONFIG_SIOX=m CONFIG_SIOX_BUS_GPIO=m # CONFIG_SLIMBUS is not set # CONFIG_INTERCONNECT is not set CONFIG_COUNTER=y # CONFIG_FTM_QUADDEC is not set CONFIG_MOST=m # end of Device Drivers # # File systems # CONFIG_DCACHE_WORD_ACCESS=y CONFIG_VALIDATE_FS_PARSER=y # CONFIG_FSINFO is not set CONFIG_FS_IOMAP=y CONFIG_EXT2_FS=m # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT3_FS is not set CONFIG_EXT4_FS=m # CONFIG_EXT4_FS_POSIX_ACL is not set # CONFIG_EXT4_FS_SECURITY is not set # CONFIG_EXT4_DEBUG is not set CONFIG_EXT4_KUNIT_TESTS=m CONFIG_JBD2=m # CONFIG_JBD2_DEBUG is not set CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=y CONFIG_REISERFS_CHECK=y # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_REISERFS_FS_XATTR is not set CONFIG_JFS_FS=y # CONFIG_JFS_POSIX_ACL is not set # CONFIG_JFS_SECURITY is not set CONFIG_JFS_DEBUG=y # CONFIG_JFS_STATISTICS is not set # CONFIG_XFS_FS is not set CONFIG_GFS2_FS=m # CONFIG_BTRFS_FS is not set CONFIG_NILFS2_FS=y # CONFIG_F2FS_FS is not set CONFIG_ZONEFS_FS=y CONFIG_FS_DAX=y CONFIG_FS_POSIX_ACL=y CONFIG_EXPORTFS=y # CONFIG_EXPORTFS_BLOCK_OPS is not set CONFIG_FILE_LOCKING=y # CONFIG_MANDATORY_FILE_LOCKING is not set # CONFIG_FS_ENCRYPTION is not set # CONFIG_FS_VERITY is not set CONFIG_FSNOTIFY=y CONFIG_DNOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_FANOTIFY=y CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y # CONFIG_MOUNT_NOTIFICATIONS is not set # CONFIG_SB_NOTIFICATIONS is not set CONFIG_QUOTA=y CONFIG_PRINT_QUOTA_WARNING=y CONFIG_QUOTA_DEBUG=y # CONFIG_QFMT_V1 is not set # CONFIG_QFMT_V2 is not set CONFIG_QUOTACTL=y CONFIG_QUOTACTL_COMPAT=y CONFIG_AUTOFS4_FS=m CONFIG_AUTOFS_FS=m # CONFIG_FUSE_FS is not set CONFIG_OVERLAY_FS=m CONFIG_OVERLAY_FS_REDIRECT_DIR=y CONFIG_OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW=y # CONFIG_OVERLAY_FS_INDEX is not set # CONFIG_OVERLAY_FS_XINO_AUTO is not set CONFIG_OVERLAY_FS_METACOPY=y # # Caches # CONFIG_FSCACHE=m # CONFIG_FSCACHE_STATS is not set CONFIG_FSCACHE_HISTOGRAM=y # CONFIG_FSCACHE_DEBUG is not set CONFIG_FSCACHE_OBJECT_LIST=y CONFIG_CACHEFILES=m CONFIG_CACHEFILES_DEBUG=y # CONFIG_CACHEFILES_HISTOGRAM is not set # end of Caches # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set CONFIG_UDF_FS=y # end of CD-ROM/DVD Filesystems # # DOS/FAT/EXFAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_FAT_DEFAULT_UTF8 is not set CONFIG_EXFAT_FS=m CONFIG_EXFAT_DEFAULT_IOCHARSET="utf8" # CONFIG_NTFS_FS is not set # end of DOS/FAT/EXFAT/NT Filesystems # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y # CONFIG_PROC_VMCORE is not set CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_PROC_CHILDREN=y CONFIG_PROC_PID_ARCH_STATUS=y CONFIG_KERNFS=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_TMPFS_XATTR is not set # CONFIG_HUGETLBFS is not set CONFIG_MEMFD_CREATE=y CONFIG_ARCH_HAS_GIGANTIC_PAGE=y CONFIG_CONFIGFS_FS=y # end of Pseudo filesystems # CONFIG_MISC_FILESYSTEMS is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=y # CONFIG_NLS_CODEPAGE_850 is not set CONFIG_NLS_CODEPAGE_852=m # CONFIG_NLS_CODEPAGE_855 is not set CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=y # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set CONFIG_NLS_CODEPAGE_863=m # CONFIG_NLS_CODEPAGE_864 is not set CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=y CONFIG_NLS_CODEPAGE_869=y CONFIG_NLS_CODEPAGE_936=y CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m # CONFIG_NLS_CODEPAGE_874 is not set CONFIG_NLS_ISO8859_8=m # CONFIG_NLS_CODEPAGE_1250 is not set CONFIG_NLS_CODEPAGE_1251=m # CONFIG_NLS_ASCII is not set # CONFIG_NLS_ISO8859_1 is not set CONFIG_NLS_ISO8859_2=y # CONFIG_NLS_ISO8859_3 is not set CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=y # CONFIG_NLS_ISO8859_6 is not set CONFIG_NLS_ISO8859_7=y CONFIG_NLS_ISO8859_9=y # CONFIG_NLS_ISO8859_13 is not set CONFIG_NLS_ISO8859_14=y CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=y # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_MAC_ROMAN=m # CONFIG_NLS_MAC_CELTIC is not set # CONFIG_NLS_MAC_CENTEURO is not set CONFIG_NLS_MAC_CROATIAN=y CONFIG_NLS_MAC_CYRILLIC=m CONFIG_NLS_MAC_GAELIC=m CONFIG_NLS_MAC_GREEK=m # CONFIG_NLS_MAC_ICELAND is not set # CONFIG_NLS_MAC_INUIT is not set CONFIG_NLS_MAC_ROMANIAN=m CONFIG_NLS_MAC_TURKISH=m # CONFIG_NLS_UTF8 is not set CONFIG_UNICODE=y CONFIG_UNICODE_NORMALIZATION_SELFTEST=y CONFIG_IO_WQ=y # end of File systems # # Security options # CONFIG_KEYS=y # CONFIG_KEYS_REQUEST_CACHE is not set CONFIG_PERSISTENT_KEYRINGS=y CONFIG_ENCRYPTED_KEYS=y CONFIG_KEY_DH_OPERATIONS=y # CONFIG_SECURITY_DMESG_RESTRICT is not set CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y # CONFIG_PAGE_TABLE_ISOLATION is not set CONFIG_SECURITY_PATH=y CONFIG_INTEL_TXT=y CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y CONFIG_HARDENED_USERCOPY=y CONFIG_HARDENED_USERCOPY_FALLBACK=y CONFIG_FORTIFY_SOURCE=y CONFIG_STATIC_USERMODEHELPER=y CONFIG_STATIC_USERMODEHELPER_PATH="/sbin/usermode-helper" CONFIG_SECURITY_LOADPIN=y # CONFIG_SECURITY_LOADPIN_ENFORCE is not set # CONFIG_SECURITY_YAMA is not set CONFIG_SECURITY_SAFESETID=y # CONFIG_SECURITY_LOCKDOWN_LSM is not set # CONFIG_INTEGRITY is not set CONFIG_DEFAULT_SECURITY_DAC=y CONFIG_LSM="lockdown,yama,loadpin,safesetid,integrity,bpf" # # Kernel hardening options # # # Memory initialization # CONFIG_INIT_STACK_NONE=y # CONFIG_INIT_ON_ALLOC_DEFAULT_ON is not set # CONFIG_INIT_ON_FREE_DEFAULT_ON is not set # end of Memory initialization # end of Kernel hardening options # end of Security options CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_SKCIPHER=y CONFIG_CRYPTO_SKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_RNG_DEFAULT=y CONFIG_CRYPTO_AKCIPHER2=y CONFIG_CRYPTO_AKCIPHER=y CONFIG_CRYPTO_KPP2=y CONFIG_CRYPTO_KPP=y CONFIG_CRYPTO_ACOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_NULL2=y CONFIG_CRYPTO_PCRYPT=y CONFIG_CRYPTO_CRYPTD=y CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_TEST=m CONFIG_CRYPTO_SIMD=y CONFIG_CRYPTO_GLUE_HELPER_X86=y CONFIG_CRYPTO_ENGINE=y # # Public-key cryptography # CONFIG_CRYPTO_RSA=y CONFIG_CRYPTO_DH=y CONFIG_CRYPTO_ECC=m CONFIG_CRYPTO_ECDH=m CONFIG_CRYPTO_ECRDSA=m CONFIG_CRYPTO_CURVE25519=m CONFIG_CRYPTO_CURVE25519_X86=y # # Authenticated Encryption with Associated Data # CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=y CONFIG_CRYPTO_CHACHA20POLY1305=y # CONFIG_CRYPTO_AEGIS128 is not set CONFIG_CRYPTO_AEGIS128_AESNI_SSE2=y # CONFIG_CRYPTO_SEQIV is not set CONFIG_CRYPTO_ECHAINIV=y # # Block modes # CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CFB is not set CONFIG_CRYPTO_CTR=y # CONFIG_CRYPTO_CTS is not set CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_OFB=m CONFIG_CRYPTO_PCBC=y CONFIG_CRYPTO_XTS=y CONFIG_CRYPTO_KEYWRAP=m CONFIG_CRYPTO_NHPOLY1305=y CONFIG_CRYPTO_NHPOLY1305_SSE2=y # CONFIG_CRYPTO_NHPOLY1305_AVX2 is not set # CONFIG_CRYPTO_ADIANTUM is not set # CONFIG_CRYPTO_ESSIV is not set # # Hash modes # CONFIG_CRYPTO_CMAC=m CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set CONFIG_CRYPTO_VMAC=y # # Digest # CONFIG_CRYPTO_CRC32C=y # CONFIG_CRYPTO_CRC32C_INTEL is not set CONFIG_CRYPTO_CRC32=y # CONFIG_CRYPTO_CRC32_PCLMUL is not set CONFIG_CRYPTO_XXHASH=m CONFIG_CRYPTO_BLAKE2B=y # CONFIG_CRYPTO_BLAKE2S is not set CONFIG_CRYPTO_BLAKE2S_X86=m CONFIG_CRYPTO_CRCT10DIF=m CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m CONFIG_CRYPTO_GHASH=y CONFIG_CRYPTO_POLY1305=y CONFIG_CRYPTO_POLY1305_X86_64=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m # CONFIG_CRYPTO_MICHAEL_MIC is not set CONFIG_CRYPTO_RMD128=m # CONFIG_CRYPTO_RMD160 is not set CONFIG_CRYPTO_RMD256=m CONFIG_CRYPTO_RMD320=m CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA1_SSSE3=y # CONFIG_CRYPTO_SHA256_SSSE3 is not set CONFIG_CRYPTO_SHA512_SSSE3=m CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_SHA3=y CONFIG_CRYPTO_SM3=y CONFIG_CRYPTO_STREEBOG=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=y CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m # # Ciphers # CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_TI=m CONFIG_CRYPTO_AES_NI_INTEL=y CONFIG_CRYPTO_ANUBIS=m # CONFIG_CRYPTO_ARC4 is not set CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_BLOWFISH_COMMON=m CONFIG_CRYPTO_BLOWFISH_X86_64=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAMELLIA_X86_64=y CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=y # CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 is not set CONFIG_CRYPTO_CAST_COMMON=y # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST5_AVX_X86_64 is not set CONFIG_CRYPTO_CAST6=y CONFIG_CRYPTO_CAST6_AVX_X86_64=m CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_DES3_EDE_X86_64=y CONFIG_CRYPTO_FCRYPT=m # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set CONFIG_CRYPTO_CHACHA20=y # CONFIG_CRYPTO_CHACHA20_X86_64 is not set # CONFIG_CRYPTO_SEED is not set CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m # CONFIG_CRYPTO_SERPENT_AVX_X86_64 is not set # CONFIG_CRYPTO_SERPENT_AVX2_X86_64 is not set CONFIG_CRYPTO_SM4=y CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=y CONFIG_CRYPTO_TWOFISH_X86_64=y CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m # # Compression # CONFIG_CRYPTO_DEFLATE=m # CONFIG_CRYPTO_LZO is not set CONFIG_CRYPTO_842=m CONFIG_CRYPTO_LZ4=y CONFIG_CRYPTO_LZ4HC=y CONFIG_CRYPTO_ZSTD=m # # Random Number Generation # CONFIG_CRYPTO_ANSI_CPRNG=m CONFIG_CRYPTO_DRBG_MENU=y CONFIG_CRYPTO_DRBG_HMAC=y CONFIG_CRYPTO_DRBG_HASH=y # CONFIG_CRYPTO_DRBG_CTR is not set CONFIG_CRYPTO_DRBG=y CONFIG_CRYPTO_JITTERENTROPY=y # # Crypto library routines # CONFIG_CRYPTO_LIB_AES=y CONFIG_CRYPTO_ARCH_HAVE_LIB_BLAKE2S=m CONFIG_CRYPTO_LIB_BLAKE2S_GENERIC=m CONFIG_CRYPTO_LIB_BLAKE2S=m CONFIG_CRYPTO_LIB_CHACHA_GENERIC=y CONFIG_CRYPTO_LIB_CHACHA=m CONFIG_CRYPTO_ARCH_HAVE_LIB_CURVE25519=y CONFIG_CRYPTO_LIB_CURVE25519_GENERIC=y # CONFIG_CRYPTO_LIB_CURVE25519 is not set CONFIG_CRYPTO_LIB_DES=y CONFIG_CRYPTO_LIB_POLY1305_RSIZE=11 CONFIG_CRYPTO_ARCH_HAVE_LIB_POLY1305=m CONFIG_CRYPTO_LIB_POLY1305_GENERIC=y CONFIG_CRYPTO_LIB_POLY1305=m CONFIG_CRYPTO_LIB_CHACHA20POLY1305=m CONFIG_CRYPTO_LIB_SHA256=y CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_DEV_PADLOCK is not set CONFIG_CRYPTO_DEV_ATMEL_I2C=m CONFIG_CRYPTO_DEV_ATMEL_ECC=m # CONFIG_CRYPTO_DEV_ATMEL_SHA204A is not set CONFIG_CRYPTO_DEV_CCP=y # CONFIG_CRYPTO_DEV_CCP_DD is not set CONFIG_CRYPTO_DEV_QAT=y CONFIG_CRYPTO_DEV_QAT_DH895xCC=y CONFIG_CRYPTO_DEV_QAT_C3XXX=m # CONFIG_CRYPTO_DEV_QAT_C62X is not set # CONFIG_CRYPTO_DEV_QAT_DH895xCCVF is not set CONFIG_CRYPTO_DEV_QAT_C3XXXVF=y CONFIG_CRYPTO_DEV_QAT_C62XVF=m CONFIG_CRYPTO_DEV_NITROX=y CONFIG_CRYPTO_DEV_NITROX_CNN55XX=y CONFIG_CRYPTO_DEV_VIRTIO=y CONFIG_CRYPTO_DEV_SAFEXCEL=m CONFIG_CRYPTO_DEV_CCREE=m CONFIG_CRYPTO_DEV_AMLOGIC_GXL=y CONFIG_CRYPTO_DEV_AMLOGIC_GXL_DEBUG=y CONFIG_ASYMMETRIC_KEY_TYPE=y # CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE is not set # # Certificates for signature checking # CONFIG_SYSTEM_TRUSTED_KEYRING=y CONFIG_SYSTEM_TRUSTED_KEYS="" # CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set CONFIG_SECONDARY_TRUSTED_KEYRING=y # CONFIG_SYSTEM_BLACKLIST_KEYRING is not set # end of Certificates for signature checking CONFIG_BINARY_PRINTF=y # # Library routines # CONFIG_RAID6_PQ=m # CONFIG_RAID6_PQ_BENCHMARK is not set CONFIG_LINEAR_RANGES=y # CONFIG_PACKING is not set CONFIG_BITREVERSE=y CONFIG_GENERIC_STRNCPY_FROM_USER=y CONFIG_GENERIC_STRNLEN_USER=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_CORDIC=y CONFIG_RATIONAL=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y CONFIG_ARCH_HAS_FAST_MULTIPLIER=y CONFIG_ARCH_USE_SYM_ANNOTATIONS=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC_T10DIF=m CONFIG_CRC_ITU_T=y CONFIG_CRC32=y CONFIG_CRC32_SELFTEST=m CONFIG_CRC32_SLICEBY8=y # CONFIG_CRC32_SLICEBY4 is not set # CONFIG_CRC32_SARWATE is not set # CONFIG_CRC32_BIT is not set CONFIG_CRC64=y CONFIG_CRC4=y CONFIG_CRC7=m CONFIG_LIBCRC32C=y CONFIG_CRC8=m CONFIG_XXHASH=y # CONFIG_RANDOM32_SELFTEST is not set CONFIG_842_COMPRESS=m CONFIG_842_DECOMPRESS=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_LZ4_COMPRESS=y CONFIG_LZ4HC_COMPRESS=y CONFIG_LZ4_DECOMPRESS=y CONFIG_ZSTD_COMPRESS=m CONFIG_ZSTD_DECOMPRESS=m CONFIG_XZ_DEC=y CONFIG_XZ_DEC_X86=y CONFIG_XZ_DEC_POWERPC=y CONFIG_XZ_DEC_IA64=y CONFIG_XZ_DEC_ARM=y CONFIG_XZ_DEC_ARMTHUMB=y CONFIG_XZ_DEC_SPARC=y CONFIG_XZ_DEC_BCJ=y # CONFIG_XZ_DEC_TEST is not set CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_XZ=y CONFIG_DECOMPRESS_LZ4=y CONFIG_GENERIC_ALLOCATOR=y CONFIG_INTERVAL_TREE=y CONFIG_XARRAY_MULTI=y CONFIG_ASSOCIATIVE_ARRAY=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y CONFIG_HAS_DMA=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_DMA_DECLARE_COHERENT=y CONFIG_ARCH_HAS_FORCE_DMA_UNENCRYPTED=y CONFIG_SWIOTLB=y CONFIG_DMA_NONCOHERENT_MMAP=y CONFIG_DMA_REMAP=y CONFIG_DMA_COHERENT_POOL=y CONFIG_DMA_API_DEBUG=y CONFIG_DMA_API_DEBUG_SG=y CONFIG_SGL_ALLOC=y CONFIG_CHECK_SIGNATURE=y CONFIG_GLOB=y CONFIG_GLOB_SELFTEST=y CONFIG_CLZ_TAB=y # CONFIG_IRQ_POLL is not set CONFIG_MPILIB=y CONFIG_LIBFDT=y CONFIG_OID_REGISTRY=m CONFIG_HAVE_GENERIC_VDSO=y CONFIG_GENERIC_GETTIMEOFDAY=y CONFIG_GENERIC_VDSO_TIME_NS=y CONFIG_FONT_SUPPORT=y CONFIG_FONT_8x16=y CONFIG_FONT_AUTOSELECT=y CONFIG_SG_POOL=y CONFIG_ARCH_HAS_PMEM_API=y CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y CONFIG_ARCH_HAS_UACCESS_MCSAFE=y CONFIG_ARCH_STACKWALK=y CONFIG_STACKDEPOT=y CONFIG_SBITMAP=y CONFIG_STRING_SELFTEST=y # end of Library routines # # Kernel hacking # # # printk and dmesg options # # CONFIG_PRINTK_TIME is not set CONFIG_PRINTK_CALLER=y CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7 CONFIG_CONSOLE_LOGLEVEL_QUIET=4 CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4 # CONFIG_DYNAMIC_DEBUG is not set CONFIG_DYNAMIC_DEBUG_CORE=y # CONFIG_SYMBOLIC_ERRNAME is not set CONFIG_DEBUG_BUGVERBOSE=y # end of printk and dmesg options # # Compile-time checks and compiler options # CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_HEADERS_INSTALL is not set # CONFIG_DEBUG_SECTION_MISMATCH is not set # CONFIG_SECTION_MISMATCH_WARN_ONLY is not set CONFIG_STACK_VALIDATION=y # end of Compile-time checks and compiler options # # Generic Kernel Debugging Instruments # CONFIG_MAGIC_SYSRQ=y CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1 CONFIG_MAGIC_SYSRQ_SERIAL=y CONFIG_MAGIC_SYSRQ_SERIAL_SEQUENCE="" CONFIG_DEBUG_FS=y CONFIG_HAVE_ARCH_KGDB=y CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y CONFIG_UBSAN=y # CONFIG_UBSAN_TRAP is not set # CONFIG_UBSAN_BOUNDS is not set CONFIG_UBSAN_MISC=y CONFIG_UBSAN_SANITIZE_ALL=y # CONFIG_UBSAN_ALIGNMENT is not set CONFIG_TEST_UBSAN=m # end of Generic Kernel Debugging Instruments # CONFIG_DEBUG_KERNEL is not set # # Memory Debugging # CONFIG_PAGE_EXTENSION=y # CONFIG_PAGE_POISONING is not set CONFIG_DEBUG_RODATA_TEST=y CONFIG_ARCH_HAS_DEBUG_WX=y # CONFIG_DEBUG_WX is not set CONFIG_GENERIC_PTDUMP=y CONFIG_HAVE_DEBUG_KMEMLEAK=y CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE=y CONFIG_DEBUG_VM_PGTABLE=y CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y CONFIG_DEBUG_MEMORY_INIT=y CONFIG_HAVE_ARCH_KASAN=y CONFIG_HAVE_ARCH_KASAN_VMALLOC=y CONFIG_CC_HAS_KASAN_GENERIC=y CONFIG_KASAN=y CONFIG_KASAN_GENERIC=y CONFIG_KASAN_OUTLINE=y # CONFIG_KASAN_INLINE is not set CONFIG_KASAN_STACK=1 CONFIG_KASAN_VMALLOC=y # CONFIG_TEST_KASAN is not set # end of Memory Debugging # # Debug Oops, Lockups and Hangs # # CONFIG_PANIC_ON_OOPS is not set CONFIG_PANIC_ON_OOPS_VALUE=0 CONFIG_PANIC_TIMEOUT=0 CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y CONFIG_TEST_LOCKUP=y # end of Debug Oops, Lockups and Hangs # # Scheduler Debugging # # end of Scheduler Debugging # CONFIG_DEBUG_TIMEKEEPING is not set # # Lock Debugging (spinlocks, mutexes, etc...) # CONFIG_LOCK_DEBUGGING_SUPPORT=y # CONFIG_WW_MUTEX_SELFTEST is not set # end of Lock Debugging (spinlocks, mutexes, etc...) CONFIG_STACKTRACE=y # CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set # # Debug kernel data structures # CONFIG_DEBUG_LIST=y CONFIG_BUG_ON_DATA_CORRUPTION=y # end of Debug kernel data structures # # RCU Debugging # CONFIG_RCU_CPU_STALL_TIMEOUT=21 # end of RCU Debugging CONFIG_USER_STACKTRACE_SUPPORT=y CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y CONFIG_HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HAVE_FENTRY=y CONFIG_HAVE_C_RECORDMCOUNT=y CONFIG_TRACER_MAX_TRACE=y CONFIG_TRACE_CLOCK=y CONFIG_RING_BUFFER=y CONFIG_EVENT_TRACING=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_TRACING=y CONFIG_GENERIC_TRACER=y CONFIG_TRACING_SUPPORT=y CONFIG_FTRACE=y # CONFIG_BOOTTIME_TRACING is not set CONFIG_FUNCTION_TRACER=y # CONFIG_FUNCTION_GRAPH_TRACER is not set # CONFIG_DYNAMIC_FTRACE is not set CONFIG_FUNCTION_PROFILER=y CONFIG_STACK_TRACER=y # CONFIG_PREEMPTIRQ_EVENTS is not set # CONFIG_IRQSOFF_TRACER is not set CONFIG_SCHED_TRACER=y CONFIG_HWLAT_TRACER=y CONFIG_MMIOTRACE=y # CONFIG_FTRACE_SYSCALLS is not set CONFIG_TRACER_SNAPSHOT=y # CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set CONFIG_BRANCH_PROFILE_NONE=y # CONFIG_PROFILE_ANNOTATED_BRANCHES is not set # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_UPROBE_EVENTS=y CONFIG_BPF_EVENTS=y CONFIG_DYNAMIC_EVENTS=y CONFIG_PROBE_EVENTS=y # CONFIG_SYNTH_EVENTS is not set # CONFIG_HIST_TRIGGERS is not set # CONFIG_TRACE_EVENT_INJECT is not set CONFIG_TRACEPOINT_BENCHMARK=y CONFIG_RING_BUFFER_BENCHMARK=m CONFIG_TRACE_EVAL_MAP_FILE=y # CONFIG_FTRACE_STARTUP_TEST is not set CONFIG_RING_BUFFER_STARTUP_TEST=y CONFIG_MMIOTRACE_TEST=m CONFIG_PREEMPTIRQ_DELAY_TEST=m # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set CONFIG_SAMPLES=y CONFIG_SAMPLE_AUXDISPLAY=y # CONFIG_SAMPLE_TRACE_EVENTS is not set CONFIG_SAMPLE_TRACE_PRINTK=m CONFIG_SAMPLE_TRACE_ARRAY=m # CONFIG_SAMPLE_KOBJECT is not set CONFIG_SAMPLE_HW_BREAKPOINT=m CONFIG_SAMPLE_KFIFO=m CONFIG_SAMPLE_CONFIGFS=m CONFIG_SAMPLE_WATCHDOG=y CONFIG_HAVE_ARCH_KCSAN=y CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y # CONFIG_STRICT_DEVMEM is not set # # x86 Debugging # # CONFIG_DEBUG_AID_FOR_SYZBOT is not set CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_EARLY_PRINTK_USB=y # CONFIG_X86_VERBOSE_BOOTUP is not set CONFIG_EARLY_PRINTK=y # CONFIG_EARLY_PRINTK_DBGP is not set CONFIG_EARLY_PRINTK_USB_XDBC=y CONFIG_HAVE_MMIOTRACE_SUPPORT=y # CONFIG_IO_DELAY_0X80 is not set # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set CONFIG_IO_DELAY_NONE=y CONFIG_PUNIT_ATOM_DEBUG=y CONFIG_UNWINDER_ORC=y # CONFIG_UNWINDER_FRAME_POINTER is not set # end of x86 Debugging # # Kernel Testing and Coverage # CONFIG_KUNIT=m CONFIG_KUNIT_DEBUGFS=y CONFIG_KUNIT_TEST=m CONFIG_KUNIT_EXAMPLE_TEST=m CONFIG_KUNIT_ALL_TESTS=m CONFIG_ARCH_HAS_KCOV=y CONFIG_CC_HAS_SANCOV_TRACE_PC=y CONFIG_KCOV=y CONFIG_KCOV_INSTRUMENT_ALL=y CONFIG_KCOV_IRQ_AREA_SIZE=0x40000 CONFIG_RUNTIME_TESTING_MENU=y CONFIG_LKDTM=y CONFIG_TEST_LIST_SORT=m CONFIG_TEST_MIN_HEAP=m CONFIG_TEST_SORT=m # CONFIG_REED_SOLOMON_TEST is not set # CONFIG_ATOMIC64_SELFTEST is not set CONFIG_ASYNC_RAID6_TEST=m CONFIG_TEST_HEXDUMP=y # CONFIG_TEST_STRING_HELPERS is not set CONFIG_TEST_STRSCPY=m # CONFIG_TEST_KSTRTOX is not set CONFIG_TEST_PRINTF=m # CONFIG_TEST_BITMAP is not set CONFIG_TEST_BITFIELD=m # CONFIG_TEST_UUID is not set CONFIG_TEST_XARRAY=y CONFIG_TEST_OVERFLOW=m CONFIG_TEST_RHASHTABLE=m CONFIG_TEST_HASH=m CONFIG_TEST_IDA=y # CONFIG_TEST_LKM is not set # CONFIG_TEST_BITOPS is not set CONFIG_TEST_VMALLOC=m CONFIG_TEST_USER_COPY=m # CONFIG_FIND_BIT_BENCHMARK is not set CONFIG_TEST_FIRMWARE=y CONFIG_TEST_SYSCTL=y CONFIG_SYSCTL_KUNIT_TEST=m CONFIG_LIST_KUNIT_TEST=m CONFIG_LINEAR_RANGES_TEST=m CONFIG_TEST_UDELAY=m # CONFIG_TEST_STATIC_KEYS is not set # CONFIG_TEST_MEMCAT_P is not set CONFIG_TEST_STACKINIT=y CONFIG_TEST_MEMINIT=y CONFIG_MEMTEST=y CONFIG_HYPERV_TESTING=y # end of Kernel Testing and Coverage # end of Kernel hacking --------------B398FCF96F2D103F53958B07-- From xen-devel-bounces@lists.xenproject.org Tue Jun 02 15:48:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 15:48:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg990-0002g8-PY; Tue, 02 Jun 2020 15:48:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg98z-0002g3-Na for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 15:48:01 +0000 X-Inumbo-ID: 6ed22e58-a4e8-11ea-ac2c-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6ed22e58-a4e8-11ea-ac2c-12813bfff9fa; Tue, 02 Jun 2020 15:47:59 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: WG0yBtzVoLjaZ8Z0nvlOcMIIOaHUvHbOHixTxHma52lOACGW/5wkEke0E6aEl9RtN1UbMcnHxZ jRxXPDRo1mCWOi7kCr3zsQlw3+AG4hjXxvZQmtlUZm3Zq9nIdb7ainGi+Yt+o9o+iw+ZjD68e6 WGiG6TGkMU0941sR/g1FSas90YJXHuGRpbvXzwvL6GQjYU9Kgovj7qA9GUnQpUXjB2UqkjkhS5 +VvzstNUWGmDztKIUb+gwjPpYPnatZ8VW0wyQxip3jbmRu1PWldEQEhnD6rYYubnSGbBWOUU04 Vp0= X-SBRS: 2.7 X-MesageID: 19386188 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,465,1583211600"; d="scan'208";a="19386188" From: Ian Jackson To: Subject: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update) Date: Tue, 2 Jun 2020 16:47:45 +0100 Message-ID: <20200602154745.15054-1-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Ian Jackson , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Prior to 2621d48f005a "gnulib: delete all gnulib integration", one could pass ./autogen.sh --no-git to prevent the libvirt build system from running git submodule update. This feature is needed by systems like the Xen Project CI which want to explicitly control the revisions of every tree. These will typically arrange to initialise the submodules check out the right version of everything, and then expect the build system not to mess with it any more. Despite to the old documentation comments referring only to gnulib, the --no-git feature is required not only because of gnulib but also because of the other submodule, src/keycodemapdb. (And in any case, even if it were no longer required because all the submodules were removed, it ought ideally to have been retained as a no-op for compaibility reasons.) So restore the --no-git feature. Because of the way the argument parsing of autogen.sh works, it is easiest to recognise this option only if it comes first. This works for the Xen Project CI, which has always passed this option first. If something else is using this option (and hasn't introduced a different workaround in the meantime), not in the first position, then perhaps a more sophisticated approach will be needed. But I think this will do for now. Signed-off-by: Ian Jackson --- autogen.sh | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index 4e1bbceb0a..1c98273452 100755 --- a/autogen.sh +++ b/autogen.sh @@ -1,5 +1,10 @@ #!/bin/sh # Run this to generate all the initial makefiles, etc. +# +# THe following options must come first. All other or subsequent +# arguments are passed to configure: +# --no-git skip `git submodule update --init` + test -n "$srcdir" || srcdir=$(dirname "$0") test -n "$srcdir" || srcdir=. @@ -13,7 +18,11 @@ cd "$srcdir" exit 1 } -git submodule update --init || exit 1 +if [ "x$1" = x--no-git ]; then + shift +else + git submodule update --init || exit 1 +fi autoreconf --verbose --force --install || exit 1 -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 15:55:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 15:55:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg9Fu-0003i8-HS; Tue, 02 Jun 2020 15:55:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jg9Ft-0003i1-DD for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 15:55:09 +0000 X-Inumbo-ID: 6f20f654-a4e9-11ea-8993-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6f20f654-a4e9-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 15:55:09 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1CDFD2067B; Tue, 2 Jun 2020 15:55:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591113308; bh=PRxYptlqDh/ho5Adpy8HLDZHSmhfvJbp9cjTmMciy58=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=rqolI2+cJdcgCjFb938OQrKwiPnmVdg09hq9mw0rg3s/2xntd5muOFt2qIOjCU6yt JL5oyl+4M1uHTMXcV7sDlr3yTxMpdCvOXSYOxOHXfujuQRMO5vZEztUqutLOtD3Atb GDB+AIu2CqT/LfTdGrDSRzpjlKflJrrfpVV6Seho= Date: Tue, 2 Jun 2020 08:55:07 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Dominique Martinet Subject: Re: [PATCH v2] 9p/xen: increase XEN_9PFS_RING_ORDER In-Reply-To: <20200602060246.GA16791@nautica> Message-ID: References: <20200521193242.15953-1-sstabellini@kernel.org> <20200522055847.GA2833@nautica> <20200602060246.GA16791@nautica> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, lucho@ionkov.net, Stefano Stabellini , ericvh@gmail.com, linux-kernel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 2 Jun 2020, Dominique Martinet wrote: > Stefano Stabellini wrote on Mon, Jun 01, 2020: > > > LGTM, I'll try to find some time to test this by the end of next week or > > > will trust you if I can't make it -- ping me around June 1st if I don't > > > reply again until then... > > > > Ping :-) > > I actually did think about this patch this weekend! . . .but didn't > quite make it :/ > Anyway, as promised pushed to linux-next, I'll submit this for 5.8 Thank you! From xen-devel-bounces@lists.xenproject.org Tue Jun 02 16:47:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 16:47:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgA4F-0000EM-JA; Tue, 02 Jun 2020 16:47:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgA4E-0000EG-Bn for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 16:47:10 +0000 X-Inumbo-ID: b30cbf4a-a4f0-11ea-8993-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b30cbf4a-a4f0-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 16:47:09 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ujbwwpWRYI4lp6XtfnrvdBbGL8PHUQFdC6lxYSro5hgMQzPRoxte6LGxLr2HVq2m07FWCRNsuc VtEzJi2gRN/IJZSeAaPL4BHlDJBC6EQRE5DhOgPSN+u2PhjqNhBUKTDGO3j45ekqlIEQCtpl5Y 9ISJUkrJjW544TAi68yi7SW1vPASFhpuog04d8hPR6BPAu789IAPEbXMlvcD89f8BVy8JusEY8 wfAMKcLkC3fBUj7ZbTWeaybZeQXR8hMSVmxnSMBKdq/RqtLVFhFjesOKjVHMtSJ8cjWl2zMMo6 mCg= X-SBRS: 2.7 X-MesageID: 19789751 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,465,1583211600"; d="scan'208";a="19789751" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <24278.33416.384684.587646@mariner.uk.xensource.com> Date: Tue, 2 Jun 2020 17:47:04 +0100 To: Roger Pau Monne Subject: Re: [[PATCH v2 for-4.14]] m4: use test instead of [] In-Reply-To: <20200602092447.GV1195@Air-de-Roger> References: <20200602090138.28656-1-wl@xen.org> <20200602092447.GV1195@Air-de-Roger> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen Development List , "paul@xen.org" , Wei Liu , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Roger Pau Monne writes ("Re: [[PATCH v2 for-4.14]] m4: use test instead of []"): > There's a double [] enclosure in the subject > > On Tue, Jun 02, 2020 at 09:01:38AM +0000, Wei Liu wrote: > > It is reported that [] was removed by autoconf, which caused the > > following error: > > > > ./configure: line 4681: -z: command not found > > > > Switch to test. That's what is used throughout our configure scripts. > > Also put the variable expansion in quotes. > > > > Signed-off-by: Wei Liu > > Reported-by: Bertrand Marquis > > Fixes: 8a6b1665d987 ("configure: also add EXTRA_PREFIX to {CPP/LD}FLAGS") > > Signed-off-by: Wei Liu > > There's a double SoB ;) > > Reviewed-by: Roger Pau Monn Pushed, thanks. Ian. From xen-devel-bounces@lists.xenproject.org Tue Jun 02 16:50:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 16:50:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgA77-00011Q-1V; Tue, 02 Jun 2020 16:50:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgA76-00011L-9l for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 16:50:08 +0000 X-Inumbo-ID: 1d3e069e-a4f1-11ea-ac41-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1d3e069e-a4f1-11ea-ac41-12813bfff9fa; Tue, 02 Jun 2020 16:50:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oXEfiVKgjPqbSWi1yk7pTXpCoytb3Ep5nmt50LvME28=; b=1XBfo2hSXoTLXP3syfMF7mCxW muOkDdIX5Rh9DszzbDFQkIhR1TI2dGSFdZV8VVqhB/IyR4bqsjNXNoc6V1iRrGHZlh4rxKwiqjYPa VJmfKGbSKd/X3njge2CuEz4XAHr2Yw9DjTeVJjfnIReOYfMLyhYOzG5VucK/tIBQtleGA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgA74-0001C4-Gd; Tue, 02 Jun 2020 16:50:06 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgA74-0006zG-6f; Tue, 02 Jun 2020 16:50:06 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgA74-0002De-5h; Tue, 02 Jun 2020 16:50:06 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150607: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=ad33a573c009d72466432b41ba0591c64e819c19 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Tue, 02 Jun 2020 16:50:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150607 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150607/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen ad33a573c009d72466432b41ba0591c64e819c19 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 5 days Failing since 150465 2020-05-29 09:02:14 Z 4 days 32 attempts Testing same since 150515 2020-05-30 01:00:47 Z 3 days 22 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Juergen Gross Julien Grall Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1196 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 02 16:56:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 16:56:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgADW-0001IU-O2; Tue, 02 Jun 2020 16:56:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgADV-0001IP-DR for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 16:56:45 +0000 X-Inumbo-ID: 099fecf0-a4f2-11ea-81bc-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 099fecf0-a4f2-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 16:56:44 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: E6zHjL5Cmq8wqMRpDIS2tgJUs6gOdceXEP+b4ju2ZHP0OZPkvzS/7eSYXkOzhfSWDwEmkPhK4o 5tv0UURmzWeD98gbrFZgUcIVltVu8JkjWEiszmDl9aeuuLynZQ4qKBmkVrUpUy3BHxTHCNFLFU w7btscuvedU2ldqjaMDtZHEoRrCk0ZtxLW/7RtgyxfbA5AQ+/LJSKAio/31F4HpFMihd/FoUjS 8sOje+1D+VsZmLfkZtGqX7AUlYNlro7QkjpnK5wuF6AFaaTHWENx1tzkSmAX6QMUclIYWpL1Gi c9I= X-SBRS: 2.7 X-MesageID: 19790883 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,465,1583211600"; d="scan'208";a="19790883" From: Igor Druzhinin To: Subject: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately Date: Tue, 2 Jun 2020 17:56:21 +0100 Message-ID: <1591116981-30162-1-git-send-email-igor.druzhinin@citrix.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain; charset="y" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Igor Druzhinin , wl@xen.org, andrew.cooper3@citrix.com, george.dunlap@citrix.com, jbeulich@suse.com, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" A recalculation NPT fault doesn't always require additional handling in hvm_hap_nested_page_fault(), moreover in general case if there is no explicit handling done there - the fault is wrongly considered fatal. This covers a specific case of migration with vGPU assigned on AMD: at a moment log-dirty is enabled globally, recalculation is requested for the whole guest memory including directly mapped MMIO regions of vGPU which causes a page fault being raised at the first access to those; but due to MMIO P2M type not having any explicit handling in hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled SVM violation. Instead of trying to be opportunistic - use safer approach and handle P2M recalculation in a separate NPT fault by attempting to retry after making the necessary adjustments. This is aligned with Intel behavior where there are separate VMEXITs for recalculation and EPT violations (faults) and only faults are handled in hvm_hap_nested_page_fault(). Do it by also unifying do_recalc return code with Intel implementation where returning 1 means P2M was actually changed. Since there was no case previously where p2m_pt_handle_deferred_changes() could return a positive value - it's safe to replace ">= 0" with just "== 0" in VMEXIT_NPF handler. finish_type_change() is also not affected by the change as being able to deal with >0 return value of p2m->recalc from EPT implementation. Reviewed-by: Roger Pau Monné Signed-off-by: Igor Druzhinin --- Changes in v2: - replace rc with recalc_done bool - updated comment in finish_type_change() - significantly extended commit description --- xen/arch/x86/hvm/svm/svm.c | 5 +++-- xen/arch/x86/mm/p2m-pt.c | 7 ++++++- xen/arch/x86/mm/p2m.c | 2 +- 3 files changed, 10 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 46a1aac..7f6f578 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2923,9 +2923,10 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) v->arch.hvm.svm.cached_insn_len = vmcb->guest_ins_len & 0xf; rc = vmcb->exitinfo1 & PFEC_page_present ? p2m_pt_handle_deferred_changes(vmcb->exitinfo2) : 0; - if ( rc >= 0 ) + if ( rc == 0 ) + /* If no recal adjustments were being made - handle this fault */ svm_do_nested_pgfault(v, regs, vmcb->exitinfo1, vmcb->exitinfo2); - else + else if ( rc < 0 ) { printk(XENLOG_G_ERR "%pv: Error %d handling NPF (gpa=%08lx ec=%04lx)\n", diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c index 5c05017..070389e 100644 --- a/xen/arch/x86/mm/p2m-pt.c +++ b/xen/arch/x86/mm/p2m-pt.c @@ -341,6 +341,7 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) unsigned int level = 4; l1_pgentry_t *pent; int err = 0; + bool recalc_done = false; table = map_domain_page(pagetable_get_mfn(p2m_get_pagetable(p2m))); while ( --level ) @@ -402,6 +403,8 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) clear_recalc(l1, e); err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); ASSERT(!err); + + recalc_done = true; } } unmap_domain_page((void *)((unsigned long)pent & PAGE_MASK)); @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) clear_recalc(l1, e); err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); ASSERT(!err); + + recalc_done = true; } out: unmap_domain_page(table); - return err; + return err ?: (recalc_done ? 1 : 0); } int p2m_pt_handle_deferred_changes(uint64_t gpa) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 17f320b..db7bde0 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1197,7 +1197,7 @@ static int finish_type_change(struct p2m_domain *p2m, rc = p2m->recalc(p2m, gfn); /* * ept->recalc could return 0/1/-ENOMEM. pt->recalc could return - * 0/-ENOMEM/-ENOENT, -ENOENT isn't an error as we are looping + * 0/1/-ENOMEM/-ENOENT, -ENOENT isn't an error as we are looping * gfn here. If rc is 1 we need to have it 0 for success. */ if ( rc == -ENOENT || rc > 0 ) -- 2.7.4 From xen-devel-bounces@lists.xenproject.org Tue Jun 02 17:15:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 17:15:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgAVb-00037S-6n; Tue, 02 Jun 2020 17:15:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgAVa-00037N-8u for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 17:15:26 +0000 X-Inumbo-ID: a5a7906a-a4f4-11ea-8993-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a5a7906a-a4f4-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 17:15:25 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 66j4nB9tX4MKCNNEx3k4bJt96of05gtniKtRPYJL+KSKT+5uUKDFbF2VJUyb4jQ1PHlR9x35Ci KuiAykyO9bxDXsjH9/otQn6p2wVnBq/cinzjJ4HY6ILxMbstXoiblqgMOUTfDhkH/3uDv6S+PA bJQG6cXMLJSq2mlyfJKvfP3oZcD+AwJXT8PK8I619db2BU1wg+qt4+S5o4SDj5u27WeO3wO0qf vQP7ImvLPJjxMvdPRsKuup5Zh1vlQRatzAVzJB0CQs/1GW7ECIqpAIl6GqQlElGUGZocJz6mUX 4nk= X-SBRS: 2.7 X-MesageID: 19338013 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,465,1583211600"; d="scan'208";a="19338013" Subject: Re: Re [PATCH] x86/CET: Fix build following c/s 43b98e7190 To: Jan Beulich References: <1eeb47f4-b9b9-c4d8-a5c9-58d78f0e0aeb@suse.com> From: Andrew Cooper Message-ID: Date: Tue, 2 Jun 2020 18:15:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1eeb47f4-b9b9-c4d8-a5c9-58d78f0e0aeb@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02/06/2020 15:21, Jan Beulich wrote: >> OSSTest reports: >> >> x86_64.S: Assembler messages: >> x86_64.S:57: Error: no such instruction: `setssbsy' >> /home/osstest/build.150510.build-amd64/xen/xen/Rules.mk:183: recipe for target 'head.o' failed >> make[4]: Leaving directory '/home/osstest/build.150510.build-amd64/xen/xen/arch/x86/boot' >> make[4]: *** [head.o] Error 1 >> >> All use of CET instructions, even those inside alternative blocks, needs to be >> behind CONFIG_XEN_SHSTK, as it indicates suitable toolchain support. >> >> Signed-off-by: Andrew Cooper > That's quite a bit of #ifdef-ary here. Simple (operand-less) insns > like SETSSBSY could easily be made available via .byte directives. > Would you be amenable to to ack-ing a patch to replace some of the > #ifdef-s (at least the ones at the lstar, cstar, and sysenter > entry points), after 4.14? Yeah - that was a bit of a mess in the end.  (But given the circumstances, and that I've got past form typo'ing the SETSSBSY opcode, it probably was the right move even in hindsight). Reducing it to .byte should be fine so long as some form of /* setssbsy */ comment appears. One other option would be to introduce a SETSSBSY macro, but that hides the alternative so is something I'd prefer to avoid. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 02 18:34:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 18:34:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgBk2-0001pM-8C; Tue, 02 Jun 2020 18:34:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgBk1-0001pH-Kf for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 18:34:25 +0000 X-Inumbo-ID: af0b8bec-a4ff-11ea-9947-bc764e2007e4 Received: from mail-ot1-x331.google.com (unknown [2607:f8b0:4864:20::331]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id af0b8bec-a4ff-11ea-9947-bc764e2007e4; Tue, 02 Jun 2020 18:34:25 +0000 (UTC) Received: by mail-ot1-x331.google.com with SMTP id e5so4358473ote.11 for ; Tue, 02 Jun 2020 11:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:reply-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=sKWUgJpThmKqU1P7r9B8mHRzCHfP384f5WiFg0t3rG4=; b=BrCAm/GZaP3OSihkbJSVTifT4Gy9Nx+6gqAV3OkoN77N2rnDnmjObhM3Zd371su4WQ Hy5zFobxJYWXRQTb73J2cxrhJM67yGi4aOcdCI5Om7mMBb58Fw8WR3saEOpu/1pKVuCH J8oa+hLJMjtS0dkJjCl/uqn0FaoYMSgiUM8dI02XXdwgnPHN9vppWJfwpMOh0+S1JIWq 3aNKVHpfY80nFsKFX2tv3EVHTIEc3XoJrplYdRD48FoqjSyRVJjAQN8l/ac3sVcBn1kW K+T8GDwp/574911RqJM/Vsl5nN7XgXtst4OFSPJ013HC9ZEzMT6bDcugVEav6rNI19os sxQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :reply-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=sKWUgJpThmKqU1P7r9B8mHRzCHfP384f5WiFg0t3rG4=; b=fKhG7MluOnSZ5ZLUDSF9IQgCo28rZdby5vwawbiwGYGaty0TfnApmp8oRDg9wK29t+ WUIRFdMQjXYEkeeFjz3Os2hxJLiIj0oCXvMuuby23PBkTbPFUmHU9bbI4Gv1jHa6sCrF iq+3VdRR0Ki5cOeaP2w2FmN64EEkpcqlxngstfhjKwVjcPxtJwClsyplYItq+sbTHtz1 0cwUlMmBtXuDXCLFXWb4uSVAJcHVKlDXo/H1BdqPwie4oi1yky3YmEsRvAH0kIosZe3s 0RYzujwIVbmMavCfXKNWoIi0Sdp0n1O6jbtAdLibvknUj6cWsgZ6TXXvyvjwg5znclUp q4mw== X-Gm-Message-State: AOAM532rIQ8gwkfHXjmLRMGGzQ3gImXlNhHM+5x44zZg/6E3OQqxS/jr 8Ab64X7q3WQ7f+TPsYaegA== X-Google-Smtp-Source: ABdhPJzROjGKYIIh+KssdSku7RLfTwrW7l20Fq2IPX/64kpQaHOQfXHtnPPuKGsepolWnkD8lfJgKw== X-Received: by 2002:a9d:768a:: with SMTP id j10mr497816otl.188.1591122864395; Tue, 02 Jun 2020 11:34:24 -0700 (PDT) Received: from serve.minyard.net ([47.184.146.204]) by smtp.gmail.com with ESMTPSA id k61sm816593otc.21.2020.06.02.11.34.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jun 2020 11:34:23 -0700 (PDT) Received: from minyard.net (unknown [IPv6:2001:470:b8f6:1b:c5fe:632c:ef7e:a82b]) by serve.minyard.net (Postfix) with ESMTPSA id 14024180044; Tue, 2 Jun 2020 18:34:22 +0000 (UTC) Date: Tue, 2 Jun 2020 13:34:20 -0500 From: Corey Minyard To: Stefano Stabellini Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU Message-ID: <20200602183420.GE2880@minyard.net> References: <2187cd7c-4d48-986b-77d6-4428e8178404@oracle.com> <42253259-9663-67e8-117f-8ba631243585@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: minyard@acm.org Cc: jgross@suse.com, Peng Fan , Julien Grall , roman@zededa.com, "jeff.kubascik@dornerworks.com" , Julien Grall , Nataliya Korovkina , "xen-devel@lists.xenproject.org" , boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Snip > > > > > whether > > > > > this was already done: > > > > >      1) Does the kernel boot on baremetal (i.e without Xen)? This should > > > > > help > > > > > to confirm whether the bug is Xen is related. > > > > > > > > Yes it boots > > > > > > > > >      2) Swiotlb should not be necessary for basic dom0 boot on Arm. Did > > > > > you try > > > > > to disable it? This should help to confirm whether swiotlb is the > > > > > problem or > > > > > not. > > > > > > > > It boots disabling swiotlb-xen > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for dom0. So > > > this suggests swiotlb is doing some transformation on the DMA address. > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to assume > > > the DMA address space and CPU address space is the same. Is RPI using the > > > same address space? > > > > Another question, is the DMA request bounced? If so, are we sure the bounce > > buffer is in the first GB? > > Yes, it is. This is actually where we spent the last few days, and I > found another little related bug in the initialization of the > swiotlb-xen but now I am sure the memory is under 1GB (0x34000000-0x38000000) Was anything ever resolved on this issue? It just kind of ended for me, and I looked in the main kernel and didn't find anything that looked related. Thanks, -corey From xen-devel-bounces@lists.xenproject.org Tue Jun 02 19:00:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 19:00:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgC95-0004Ph-8m; Tue, 02 Jun 2020 19:00:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgC93-0004Pc-Kp for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 19:00:17 +0000 X-Inumbo-ID: 47b0d0b6-a503-11ea-9dbe-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 47b0d0b6-a503-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 19:00:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uH0QPGIkMyONMWaImU6Lm4OTgfA37BRk4Ro+WsL24qY=; b=G/JsNR71NbP4VZL3+a3PlZwkj VFCOKDGUyF0Qjn2rYJi7B0iBMWuxkmoaEUSBXkjWSPRgoHCmrg1CYPYEcelu5ycrU/4vmI8Ig2WV7 ghnLgPu2Gdz3Gx+38deX+KydT+XdbpH4Xmy2CUKy8RGMmSLJQVVEAY5TP9ZHOvUEYvObg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgC8v-0003x4-6D; Tue, 02 Jun 2020 19:00:09 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgC8u-0004fS-UI; Tue, 02 Jun 2020 19:00:08 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgC8u-00023S-Tb; Tue, 02 Jun 2020 19:00:08 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150613: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: linux-linus:build-arm64-pvops:kernel-build:fail:regression linux-linus:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: linux=f359287765c04711ff54fbd11645271d8e5ff763 X-Osstest-Versions-That: linux=9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0 From: osstest service owner Date: Tue, 02 Jun 2020 19:00:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150613 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150613/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 6 kernel-build fail REGR. vs. 150606 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-examine 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 15 guest-saverestore fail like 150606 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150606 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150606 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150606 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150606 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150606 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150606 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150606 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150606 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-win7-amd64 2 hosts-allocate starved n/a version targeted for testing: linux f359287765c04711ff54fbd11645271d8e5ff763 baseline version: linux 9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0 Last test of basis 150606 2020-06-01 19:40:10 Z 0 days Testing same since 150613 2020-06-02 05:14:57 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: "Eric W. Biederman" "Paul E. McKenney" Adrian Freund Adrian Hunter Al Viro Alessia Mantegazza Alex Shi Alex Shi # translations/zh_CN Alexander Stein Alexandre Chartre Alexey Budankov Amit Daniel Kachhap Andreas Gerstmayr Andrei Vagin Andrew Donnellan Andrew Morton Andrew Scull Andy Lutomirski Andy Shevchenko Anju T Sudhakar Anshuman Khandual Ard Biesheuvel Arnaldo Carvalho de Melo Arnd Bergmann Arvind Sankar Atish Patra Babu Moger Barret Rhoden Bartlomiej Zolnierkiewicz Benjamin Thiel Bjorn Helgaas Björn Töpel Borislav Petkov Borislav Petkov Bumsik Kim Bumsik Kim Casey Schaufler Catalin Marinas Christian Brauner Christoph Hellwig Christophe Leroy Chucheng Luo CodyYao-oc Corentin Labbe Cristian Souza Dan Williams Daniel Borkmann Daniel Kiss Daniel Thompson Dave Hansen Dave Hansen Dave Martin David Howells David Sterba # fs/affs/Kconfig Dimitri Sivanich Dmitry Safonov Doug Berger Douglas Anderson Eric W. Biederman Ethon Paul Etienne Carriere Fangrui Song Federico Vaga Federico Vaga # translations/it_IT Fenghua Yu Finn Thain Flavio Suligoi Florian Fainelli Frederic Weisbecker Gal Pressman Gavin Shan Geert Uytterhoeven Geert Uytterhoeven George Spelvin Giuseppe Scrivano Gregory Fong Guixiong Wei Gustavo A. R. Silva Gustavo A. R. Silva Hanjun Guo Hans Verkuil He Zhe Helge Deller Ian Rogers Ingo Molnar Jagadeesh Pagadala James Morris James Morse Jan Kara Jason Wang Jason Yan Jean-Philippe Brucker Jeremy Kerr Jessica Yu Jian Cai Jimmy Assarsson Jin Yao Jiri Olsa Jiri Olsa Jiri Slaby Joe Perches Joel Fernandes (Google) Joerg Roedel Johan Hovold Jonathan Corbet Jonathan Neuschäfer Josh Poimboeuf Joshua Abraham Joshua Abraham Juan Manuel Méndez Rey Jules Irenge Julia Cartwright Julien Thierry Kairui Song Kaitao Cheng Kajol Jain Kan Liang Kees Cook Kevin Cernekee Kevin Hao Kim Phillips Konstantin Kharlamov Konstantin Khlebnikov Lai Jiangshan Leo Yan Leonardo Bras Linus Torvalds Linus Walleij Lionel Landwerlin Lorenzo Pieralisi Luke Nelson Luke Nelson Marc Zyngier Marc Zyngier # kvm/arm64 Mark Brown Mark Gross Mark Rutland Masahiro Yamada Masami Hiramatsu Matt Helsley Matthew Wilcox (Oracle) Mauro Carvalho Chehab Michael Ellerman Michael S. Tsirkin Michal Hocko Michal Suchanek Michel Lespinasse Mike Galbraith Mike Leach Mike Rapoport Mike Rapoport Miklos Szeredi Miroslav Benes Muchun Song Namhyung Kim Nick Desaulniers Oded Gabbay Paul E. McKenney Paul Gortmaker Peter Zijlstra (Intel) Peter Zijlstra Petr Mladek Qais Yousef Qi Liu Qi Zheng Randy Dunlap Raphael Gault Ricardo Cañuelo Ricardo Ribalda Ricardo Ribalda Delgado Rikard Falkeborn Rob Herring Ronald G. Minnich Russell King Sai Prakash Ranjan Sam Ravnborg Sami Tolvanen Sandipan Das Sebastian Andrzej Siewior Sedat Dilek Serge E. Hallyn Shaokun Zhang Song Liu Stan Johnson Stefan Richter Stephane Eranian Stephen Boyd Stephen Kitt Stephen Smalley Steve Wahl Steven Rostedt (VMware) Sudeep Holla Sumanth Korikkar Suzuki K Poulose Tamas Zsoldos Tang Bin Thomas Backlund Thomas Gleixner Thomas Richter Tom Zanussi Tommi Rantala Tuan Phan Uros Bizjak Vamshi K Sthambamkadi Vincent Whitchurch Vincenzo Frascino Vitor Massaru Iha Vlastimil Babka Waiman Long Wang Wenhu Will Deacon Wolfram Sang Wolfram Sang Wolfram Sang Xi Wang Yu-cheng Yu YueHaibing Yunfeng Ye Zenghui Yu Zhaolong Zhang Zhou Wang Zou Wei Łukasz Stelmach jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops fail build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl blocked test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 starved test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine blocked test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 20159 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 02 19:24:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 19:24:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgCWF-0006Jr-V6; Tue, 02 Jun 2020 19:24:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgCWE-0006Jm-7D for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 19:24:14 +0000 X-Inumbo-ID: a439194e-a506-11ea-8993-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a439194e-a506-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 19:24:13 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 75312206E2; Tue, 2 Jun 2020 19:24:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591125852; bh=CStxKi7GNxsvMOGhzKrkhSxML7SEV2wR10QVNYr+zVQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Ytsu3/KDvFSbmo4EBLSvzSQUqp49j6YwqLJF6HIJ0L3/EzovGzwYB4kBfS4zklWFw rOp4KdEOMBf/Xy4mOamRhjui9bq7qpePkiL6AyeqnikFIxOsUH8tELfE2ftVujQdPH XHHl54Svr0a4OukEQMXivIq0umgf5/xUQUPdZOrc= Date: Tue, 2 Jun 2020 12:24:05 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Corey Minyard Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU In-Reply-To: <20200602183420.GE2880@minyard.net> Message-ID: References: <2187cd7c-4d48-986b-77d6-4428e8178404@oracle.com> <42253259-9663-67e8-117f-8ba631243585@xen.org> <20200602183420.GE2880@minyard.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-2140389372-1591125815=:6774" Content-ID: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Peng Fan , Stefano Stabellini , Julien Grall , roman@zededa.com, "jeff.kubascik@dornerworks.com" , Julien Grall , Nataliya Korovkina , "xen-devel@lists.xenproject.org" , boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-2140389372-1591125815=:6774 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 2 Jun 2020, Corey Minyard wrote: > Snip > > > > > > > whether > > > > > > this was already done: > > > > > >      1) Does the kernel boot on baremetal (i.e without Xen)? This should > > > > > > help > > > > > > to confirm whether the bug is Xen is related. > > > > > > > > > > Yes it boots > > > > > > > > > > >      2) Swiotlb should not be necessary for basic dom0 boot on Arm. Did > > > > > > you try > > > > > > to disable it? This should help to confirm whether swiotlb is the > > > > > > problem or > > > > > > not. > > > > > > > > > > It boots disabling swiotlb-xen > > > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for dom0. So > > > > this suggests swiotlb is doing some transformation on the DMA address. > > > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to assume > > > > the DMA address space and CPU address space is the same. Is RPI using the > > > > same address space? > > > > > > Another question, is the DMA request bounced? If so, are we sure the bounce > > > buffer is in the first GB? > > > > Yes, it is. This is actually where we spent the last few days, and I > > found another little related bug in the initialization of the > > swiotlb-xen but now I am sure the memory is under 1GB (0x34000000-0x38000000) > > Was anything ever resolved on this issue? It just kind of ended for me, > and I looked in the main kernel and didn't find anything that looked > related. Yes, we have a patch series on the list for the Linux kernel to fix this issue but it hasn't been merged yet: https://marc.info/?l=linux-kernel&m=159001831406263&w=2 --8323329-2140389372-1591125815=:6774-- From xen-devel-bounces@lists.xenproject.org Tue Jun 02 21:00:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 21:00:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgE11-0006ms-Lm; Tue, 02 Jun 2020 21:00:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgE10-0006mm-PE for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 21:00:06 +0000 X-Inumbo-ID: 037e036d-a514-11ea-ac7b-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 037e036d-a514-11ea-ac7b-12813bfff9fa; Tue, 02 Jun 2020 20:59:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JhxiZs47yOkF144jMvsSxOiarbHSpdo3gzr0+4/ffvU=; b=vnkacDkGbRMlKW2mqlstn+FxW mqn5KsIHKqXhtaRpwanpuKpDEmrxcPiqW2blN9Q92RNzZlEa9oID4okEHPuV3sc2qGCSi1b50nvY2 LxIo8yab33oHVNZ6nTVzh0GJpISaLoISkkFFB5zqQUJPBjpgApyr/ZhWHHWvcVpMd1LEI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgE0r-0006RP-B4; Tue, 02 Jun 2020 20:59:57 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgE0r-0000iy-38; Tue, 02 Jun 2020 20:59:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgE0r-0002ID-2Z; Tue, 02 Jun 2020 20:59:57 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150623: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=e181db8ba4e0797b8f9b55996adfa71ffb5b4081 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Tue, 02 Jun 2020 20:59:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150623 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150623/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen e181db8ba4e0797b8f9b55996adfa71ffb5b4081 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 5 days Failing since 150465 2020-05-29 09:02:14 Z 4 days 33 attempts Testing same since 150623 2020-06-02 17:08:22 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1434 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 02 21:48:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 21:48:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgElJ-000244-6r; Tue, 02 Jun 2020 21:47:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgElH-00023z-PU for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 21:47:55 +0000 X-Inumbo-ID: b7132456-a51a-11ea-8993-bc764e2007e4 Received: from aserp2120.oracle.com (unknown [141.146.126.78]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b7132456-a51a-11ea-8993-bc764e2007e4; Tue, 02 Jun 2020 21:47:55 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 052LgRum145391; Tue, 2 Jun 2020 21:47:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=K5xWiXEDtKWHBbuo8e/WKOZpij8IqUU1XYWXVjvX2AA=; b=puzwLelWQrgoipacbfkPgNqieZ3mObbXyTqR1PT0vxic7QZMlXOggNmZc3tmuWMPzunJ OCGRiPJ/bllCTk9ViDBrSY5hK3ow7U04Cps/8fAfPUDXOzE1J6/do5q0o2J1oijU7xxO +yU5uc5JYBPxy4k1d+bpu04PUUb44KzgExX/0qTQrTBeG8uhPU774vv5rtaKP6WDFLmJ Ot0f0A1iFuGyAe1w4VLaUAWmku9U6p04y4z4VHoAccsMMUUnG7uYuJ3nLvCXWWUlTVPr Tg4gZyLwwafHLKeZePCNiZo53HJk0Zzrq98KqjWawcLoIzyEP04aHSIVPzOGyyCXQC3B +g== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 31bfem65x7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 02 Jun 2020 21:47:26 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 052LlPSG014448; Tue, 2 Jun 2020 21:47:25 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 31c12pvufr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 02 Jun 2020 21:47:25 +0000 Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 052LlM0Q007551; Tue, 2 Jun 2020 21:47:22 GMT Received: from [10.39.241.85] (/10.39.241.85) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Jun 2020 14:47:22 -0700 Subject: Re: linux-next: Tree for Jun 2 (x86/xen) To: Randy Dunlap , Stephen Rothwell , Linux Next Mailing List References: <20200602203737.6eec243f@canb.auug.org.au> <8bc4e983-7563-20f2-2c15-3cea055ae264@infradead.org> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <4e5e87cb-daa9-fc75-bf12-401a912bb3dd@oracle.com> Date: Tue, 2 Jun 2020 17:47:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <8bc4e983-7563-20f2-2c15-3cea055ae264@infradead.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9640 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0 adultscore=0 suspectscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006020154 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9640 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 phishscore=0 clxscore=1011 impostorscore=0 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006020153 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , xen-devel , Thomas Gleixner , Stefano Stabellini , Linux Kernel Mailing List Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/2/20 11:18 AM, Randy Dunlap wrote: > On 6/2/20 3:37 AM, Stephen Rothwell wrote: >> Hi all, >> >> News: The merge window has opened, so please do *not* add v5.9 material >> to your linux-next included branches until after v5.8-rc1 has been >> released. >> >> Changes since 20200529: >> > on x86_64: > > CC arch/x86/xen/suspend_hvm.o > In file included from ../include/xen/interface/hvm/params.h:24:0, > from ../include/xen/hvm.h:6, > from ../arch/x86/xen/suspend_hvm.c:5: > ../include/xen/interface/hvm/hvm_op.h:29:5: error: unknown type name domid_t (+Thomas) This has been addressed by https://lore.kernel.org/lkml/159101612916.17951.7492360776296750785.tip-bot2@tip-bot2/ -boris > domid_t domid; /* IN */ > ^~~~~~~ > ../include/xen/interface/hvm/hvm_op.h:33:1: warning: data definition has no type or storage class > DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_param); > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > ../include/xen/interface/hvm/hvm_op.h:33:1: error: type defaults to int in declaration of DEFINE_GUEST_HANDLE_STRUCT [-Werror=implicit-int] > ../include/xen/interface/hvm/hvm_op.h:33:1: warning: parameter names (without types) in function declaration > ../include/xen/interface/hvm/hvm_op.h:39:5: error: unknown type name domid_t > domid_t domid; > ^~~~~~~ > ../include/xen/interface/hvm/hvm_op.h:44:1: warning: data definition has no type or storage class > DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_pagetable_dying_t); > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > ../include/xen/interface/hvm/hvm_op.h:44:1: error: type defaults to int in declaration of DEFINE_GUEST_HANDLE_STRUCT [-Werror=implicit-int] > ../include/xen/interface/hvm/hvm_op.h:56:5: error: unknown type name domid_t > domid_t domid; > ^~~~~~~ > ../include/xen/interface/hvm/hvm_op.h:63:1: warning: data definition has no type or storage class > DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_get_mem_type); > ^~~~~~~~~~~~~~~~~~~~~~~~~~ > ../include/xen/interface/hvm/hvm_op.h:63:1: error: type defaults to int in declaration of DEFINE_GUEST_HANDLE_STRUCT [-Werror=implicit-int] > ../include/xen/interface/hvm/hvm_op.h:63:1: warning: parameter names (without types) in function declaration > > > Full randconfig file is attached. > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 21:51:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 21:51:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgEoK-0002tr-M5; Tue, 02 Jun 2020 21:51:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgEoJ-0002tm-QY for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 21:51:03 +0000 X-Inumbo-ID: 275e99fc-a51b-11ea-9dbe-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 275e99fc-a51b-11ea-9dbe-bc764e2007e4; Tue, 02 Jun 2020 21:51:03 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8AA68206E2; Tue, 2 Jun 2020 21:51:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591134662; bh=OG5HRGyKV3zEjimah4a0c6gJZ7mOncwrp6JlgmZTJXU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=mDaApVbv13sLSvUPxDLg7qf18jrKrHmMzTnkjukv5eL/Ku5u0trpjQZW8FgRBbpE7 uBfuTN+v5BZDdxYgO2H6sOcDNFN74Qf468AoUzW3+fytW0qRePC2BAmt9zbt8oMYoD zmqTdVRF9X0/E+gGvz8I7eQlQC2c74oIBtYkeX9k= Date: Tue, 2 Jun 2020 14:51:02 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: Re: [PATCH 00/10] fix swiotlb-xen for RPi4 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, tamas@tklengyel.com, sstabellini@kernel.org, linux-kernel@vger.kernel.org, roman@zededa.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" I would like to ask the maintainers, Juergen, Boris, Konrad, whether you have any more feedback before I send v2 of the series. Cheers, Stefano On Wed, 20 May 2020, Stefano Stabellini wrote: > Hi all, > > This series is a collection of fixes to get Linux running on the RPi4 as > dom0. > > Conceptually there are only two significant changes: > > - make sure not to call virt_to_page on vmalloc virt addresses (patch > #1) > - use phys_to_dma and dma_to_phys to translate phys to/from dma > addresses (all other patches) > > In particular in regards to the second part, the RPi4 is the first > board where Xen can run that has the property that dma addresses are > different from physical addresses, and swiotlb-xen was written with the > assumption that phys addr == dma addr. > > This series adds the phys_to_dma and dma_to_phys calls to make it work. > > > Cheers, > > Stefano > From xen-devel-bounces@lists.xenproject.org Tue Jun 02 22:51:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 22:51:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgFjx-0008NE-Hp; Tue, 02 Jun 2020 22:50:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgFjw-0008N8-2p for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 22:50:36 +0000 X-Inumbo-ID: 789a3f62-a523-11ea-81bc-bc764e2007e4 Received: from mail-qv1-xf42.google.com (unknown [2607:f8b0:4864:20::f42]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 789a3f62-a523-11ea-81bc-bc764e2007e4; Tue, 02 Jun 2020 22:50:35 +0000 (UTC) Received: by mail-qv1-xf42.google.com with SMTP id r16so170055qvm.6 for ; Tue, 02 Jun 2020 15:50:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+QEXNvJJupTq9Fc0kGu/z00JuIQCytaVsg1Z3JMDJMA=; b=R+iMx6576lqXbvTX7zjBl3MzVXvF0W07XF0DORDTwG3EeJc0alRMOoWM9J8L5uiR/X ERjiqDTuGkAEjLgT/T2C8+EmwtnQJDWzPiloifdVDgRQ6BEPmlKHb63yavV3LKB95C61 RJ0ujxieuY18YgHGlzBo/4iw8LXJJwoINUCB5LPfpjApUewRpN1jYL4q3Hyli4osw2EM R3pfcYgRsgqObbiE2P+AQvj7cmSwKzIHTjE8UZhz0v5TTCHAnyU9r1IPNWXrZEz8/LPM K7KIjFraKeBCxhRhBrTGyUJlu5RyhmvFlW1cvLEuYsSOP+88HymMVhvQ3Msn1dtIjxz0 e6TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+QEXNvJJupTq9Fc0kGu/z00JuIQCytaVsg1Z3JMDJMA=; b=r4ru9bI+JJIyBNIWI2S/j39oUcwjw7qIOqo3YuE9X7R8H8MRqzmI3twMvr4fNUDAc5 0efjciNVZWoOUkf98envq7Gm6GD19wCSlo4F0ojLAEG6AzwEqAsvGLnBnkrcq7mbXSC1 OLJBYua1WYSIbisoih3OYMcCXycKXzBndROpmDLB7shjvZDjL4sXR9h4EMy6YThCBcfc NgFYZLbbYykbjuszEQo5mhyzDCrVJaweTBu3IRjdbQQYNqbW8S4n7M7jUoVYT7OE+6mI 2ULKgYpDPS3r2VRDtmjeEn2dgxxpAwGVcVglSL1BSK9ZAcefJfrRnLSpjDYNVxBrDpUc EoJA== X-Gm-Message-State: AOAM532vxucB9o7WzYsLPCNBnlyLY8AQOS29aGdHd7yudBrajvR/RXpo o486OqokgAIIVlie1Z3JEvK56zK96GHpjp+aj/IIRw== X-Google-Smtp-Source: ABdhPJw8DGBoajL9Xc6Q0k3mRpFLrhh3tCCY8P3rcRZoSmZcEatzWPCSRxiO8ttQtySl31mh0yoNksAmh0O4czSNgPU= X-Received: by 2002:a0c:8386:: with SMTP id k6mr28319468qva.213.1591138235133; Tue, 02 Jun 2020 15:50:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shaposhnik Date: Tue, 2 Jun 2020 15:50:24 -0700 Message-ID: Subject: Re: UEFI support in ARM DomUs To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , George Dunlap , Nataliya Korovkina , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 1, 2020 at 9:12 AM Stefano Stabellini wrote: > > + George > > On Sun, 31 May 2020, Roman Shaposhnik wrote: > > Hi Julien! > > > > On Sun, May 31, 2020 at 3:24 PM Julien Grall wrote: > > > > > > On Sun, 31 May 2020 at 23:05, Roman Shaposhnik wrote: > > > > Hi! > > > > > > > > with a lot of help from Stefano, we're getting RPi4 support in > > > > Project EVE pretty much on par between KVM and Xen. > > > > > > > > One big area that still remains is supporting UEFI boot sequence > > > > for DomUs. With KVM, given the qemu virt device model this is > > > > as simple as using either stock UEFI build for arm or even U-Boot > > > > EFI emulation environment and passing it via -bios option. > > > > > > > > Obviously with Xen on ARM we don't have the device model so > > > > my understanding is that the easiest way we can support it would > > > > be to port UEFI's OvmfPkg/OvmfXen target to ARM (it seems to > > > > be currently exclusively X64). > > > > > > EDK2 has been supporting Xen on Arm for the past 5 years. We don't use > > > OvmfPkg/OvmfXen but ArmVirtPkg/ArmVirtXen (see [1]). > > > I haven't tried to build it recently, but I should be able to help if > > > there is any issue with it. > > > > > > Cheers, > > > > > > [1] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtXen.fdf > > > > This is really, really awesome -- I guess it would be really helpful to document > > this someplace on the ARM/Xen wiki (I can volunteer if someone can grant > > me the karma). > > Regarding the wiki: yes please! Let George know if you don't have write access. Hey Geroge -- FWIW: my wiki account name is rvs -- please let me know once you enable whatever needs to be enabled for my write access. Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Tue Jun 02 23:25:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 23:25:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgGHZ-0002m0-8o; Tue, 02 Jun 2020 23:25:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgGHY-0002lv-0p for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 23:25:20 +0000 X-Inumbo-ID: 4ec8b5a6-a528-11ea-ac9e-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4ec8b5a6-a528-11ea-ac9e-12813bfff9fa; Tue, 02 Jun 2020 23:25:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Pp846L/mMR056L3aDbHvCunGX8x99x/19DQPKuSeGG0=; b=zIeJ51xyR07eL4eT++tMKC+8g h48n6AsM1ILkbYOC654ES4S/5acBtTa5AZbIIOXSCJ7BgmjG0j4pc7slhi62v/p2CP01HAlg4KKhS 7ttgvZLXSc0NE3miu3kLSdqQdLcihrJRGX0N8EZV2a3HnIOv6w5Ga4AvnFJPZcz7LMobE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgGHP-0000xk-Vt; Tue, 02 Jun 2020 23:25:12 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgGHP-0007zq-K0; Tue, 02 Jun 2020 23:25:11 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgGHP-0008MQ-ED; Tue, 02 Jun 2020 23:25:11 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150608: tolerable FAIL - PUSHED X-Osstest-Failures: qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=6bb228190ef0b45669d285114cf8a280c55f4b39 X-Osstest-Versions-That: qemuu=4ec2a1f53e8aaa22924614b64dde97321126943e From: osstest service owner Date: Tue, 02 Jun 2020 23:25:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150608 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150608/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 150593 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150593 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150593 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150593 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150593 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150593 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150593 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: qemuu 6bb228190ef0b45669d285114cf8a280c55f4b39 baseline version: qemuu 4ec2a1f53e8aaa22924614b64dde97321126943e Last test of basis 150593 2020-06-01 05:49:17 Z 1 days Testing same since 150608 2020-06-01 21:38:00 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Bastian Koppelmann Dr. David Alan Gilbert Huacai Chen Huacai Chen John Snow Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé Robert Foley Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/qemu-xen.git 4ec2a1f53e..6bb228190e 6bb228190ef0b45669d285114cf8a280c55f4b39 -> upstream-tested From xen-devel-bounces@lists.xenproject.org Tue Jun 02 23:54:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 02 Jun 2020 23:54:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgGj1-0005Qw-Kf; Tue, 02 Jun 2020 23:53:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgGj0-0005Qr-Hw for xen-devel@lists.xenproject.org; Tue, 02 Jun 2020 23:53:42 +0000 X-Inumbo-ID: 48428550-a52c-11ea-aca1-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 48428550-a52c-11ea-aca1-12813bfff9fa; Tue, 02 Jun 2020 23:53:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dhuVJCIEkiN2KYVRHX8kKSxEKvHC5HLWoLXhb3UOwy4=; b=6vtHGoB81wfoVEuO1xmqx/gWu h3z7aXWQHKGZE5mBqTgvU7RBDzbN1/SmItWSJumXe0/pOrhGQ5IswApwU6TjZcC+cJAlKB+hHSPtW 2W2f2FV3Xs3SQTfZaO7OzgW1y4WqCwYV12GeyPIvdoqQVwYHICZBSflJEBdgHD8VGLLts=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgGix-0001Wd-Du; Tue, 02 Jun 2020 23:53:39 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgGix-0002Af-3E; Tue, 02 Jun 2020 23:53:39 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgGix-0000vz-2e; Tue, 02 Jun 2020 23:53:39 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150629: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=99a76a88d5e7f4693bb6b286e366006e1da1c954 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Tue, 02 Jun 2020 23:53:39 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150629 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150629/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 99a76a88d5e7f4693bb6b286e366006e1da1c954 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 5 days Failing since 150465 2020-05-29 09:02:14 Z 4 days 34 attempts Testing same since 150629 2020-06-02 21:00:40 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1494 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 00:16:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 00:16:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgH4Q-00081Q-F6; Wed, 03 Jun 2020 00:15:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgH4O-00081L-Lh for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 00:15:48 +0000 X-Inumbo-ID: 5f357792-a52f-11ea-aca3-12813bfff9fa Received: from userp2120.oracle.com (unknown [156.151.31.85]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5f357792-a52f-11ea-aca3-12813bfff9fa; Wed, 03 Jun 2020 00:15:47 +0000 (UTC) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0530CX4A179866; Wed, 3 Jun 2020 00:15:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=XpvZ9y5bmE7ucbmocB95E/AWCXmiOoV+z0bmuLh/XqA=; b=NoBQ97teGkUvEqj/aXe/3b5BNDQSyjb/nUweHFQ90dyh/5qi7drsTZnAeZTw2y1mKasR 1QyAYXCUcwEAOWGtJzrhKhyYGpKNBtctqMKCiqyzNzAEWVArVslEsNGU9aKV9JdVy+z5 7pVpnRCC6IbBWQbVu4S3qFGgOlXvzNPBI7+fKA/xe4cKxqTn2HcdIU6AKLzsn7sfb0b4 QM87q/jaeVJBVg3BPGMX+DP7ymJFb/HgZKpj3kZW5G6T8wFZo3l97apGzkERtfhuNnbx nuwiak9ntJip/Dhw4+fK27sZovrGYbxbDywZrNyzq7u3up4yddp08rJ7QDhSENuqfpvB PA== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 31dkrukm8b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 03 Jun 2020 00:15:45 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0530E0CX039237; Wed, 3 Jun 2020 00:15:45 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 31dju2axpp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 03 Jun 2020 00:15:45 +0000 Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 0530FhiV021622; Wed, 3 Jun 2020 00:15:43 GMT Received: from [10.39.242.67] (/10.39.242.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 02 Jun 2020 17:15:43 -0700 Subject: Re: [PATCH 00/10] fix swiotlb-xen for RPi4 To: Stefano Stabellini , jgross@suse.com, konrad.wilk@oracle.com References: From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <206125bc-6f84-47e6-a419-2313ec333d52@oracle.com> Date: Tue, 2 Jun 2020 20:15:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9640 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 mlxscore=0 adultscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006020167 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9640 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 clxscore=1011 adultscore=0 mlxlogscore=999 cotscore=-2147483648 phishscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006020167 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, tamas@tklengyel.com, linux-kernel@vger.kernel.org, roman@zededa.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/2/20 5:51 PM, Stefano Stabellini wrote: > I would like to ask the maintainers, Juergen, Boris, Konrad, whether you > have any more feedback before I send v2 of the series. I think I only had one comment and that's all. Most were from Julien. -boris > > Cheers, > > Stefano > > > On Wed, 20 May 2020, Stefano Stabellini wrote: >> Hi all, >> >> This series is a collection of fixes to get Linux running on the RPi4 as >> dom0. >> >> Conceptually there are only two significant changes: >> >> - make sure not to call virt_to_page on vmalloc virt addresses (patch >> #1) >> - use phys_to_dma and dma_to_phys to translate phys to/from dma >> addresses (all other patches) >> >> In particular in regards to the second part, the RPi4 is the first >> board where Xen can run that has the property that dma addresses are >> different from physical addresses, and swiotlb-xen was written with the >> assumption that phys addr == dma addr. >> >> This series adds the phys_to_dma and dma_to_phys calls to make it work. >> >> >> Cheers, >> >> Stefano >> From xen-devel-bounces@lists.xenproject.org Wed Jun 03 02:38:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 02:38:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgJIF-00062K-2w; Wed, 03 Jun 2020 02:38:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgJID-00062F-UI for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 02:38:13 +0000 X-Inumbo-ID: 423794d6-a543-11ea-8993-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 423794d6-a543-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 02:38:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Bu0m75/ZUrDkcGZzp0Yf0nFswPmR1DJjFh0nsRXquh8=; b=WBkWEWKTQBJylxu/JgHwZk09y FKevKxzhsUnHuf2dIjS7kWdyHxf2aNvCWBTy8pbtA4r3GDTX0cV2nwFvYW8GVEu33GMSV+f6+vAs1 rSHUPYirOdi3qQ0iZj62mosgzTp/vbpqAMOVBlF4I+DnvsmnsrodVVIRtpa2fUree6dcg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgJI7-0007KH-Fm; Wed, 03 Jun 2020 02:38:07 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgJI7-0002Ng-93; Wed, 03 Jun 2020 02:38:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgJI7-0005hq-8S; Wed, 03 Jun 2020 02:38:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150633: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=99a76a88d5e7f4693bb6b286e366006e1da1c954 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Wed, 03 Jun 2020 02:38:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150633 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150633/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 99a76a88d5e7f4693bb6b286e366006e1da1c954 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 5 days Failing since 150465 2020-05-29 09:02:14 Z 4 days 35 attempts Testing same since 150629 2020-06-02 21:00:40 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1494 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 02:43:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 02:43:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgJNc-0006zL-Nz; Wed, 03 Jun 2020 02:43:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgJNb-0006zG-A1 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 02:43:47 +0000 X-Inumbo-ID: 0bb5b0a4-a544-11ea-8993-bc764e2007e4 Received: from mail-qt1-x82d.google.com (unknown [2607:f8b0:4864:20::82d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0bb5b0a4-a544-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 02:43:46 +0000 (UTC) Received: by mail-qt1-x82d.google.com with SMTP id w90so819927qtd.8; Tue, 02 Jun 2020 19:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N6goEOlN4qAAs1j28VEI7Cco90TR2wupjCzPlDjwyLg=; b=jxnE/6HFKMC+fI8zc/aNqgCoenD1lUbYQhf4wDZvaS1LpMRtQfWdpD3sUq+u+OEekI kFhr8CMwc1UFKIjQ7b3PUKpbX8zKu0TMIxuFS9saT8DnoMYu7xavDuVSN2Pd1wLWD+p5 YDYl1UboIfLlydCgx2gpxi+gkHIGSljEu+wSsdOZjHvpIKFmjGrcsimU9L2DDEhJ7JMJ lHpacabHmhIev8XU9Wh5PFHLZCLf2oRyMG6ROlh0VYVv8wqnlUQ9Fes0wsCWUnHDyz3k cpK75fB3YrovIzmo710eIVqldcXR1fIA5k/AHrLiHGx1APs/uIbm7WHHuqGf9aPl75x/ 2ACw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N6goEOlN4qAAs1j28VEI7Cco90TR2wupjCzPlDjwyLg=; b=EHvdaDrthjwMIBMdx62vnX2ygNBARHe9Cuy/MHtAftIRrURdoI9qg53/9JFJVio5u4 mMasK2DdMDF+BIWVztYdeeisVtmo8HODKjfhCxYLhaGE4iQ4SDP+RxUf2qtwj68wGjGk YpDzwlxF6NvstEpO+sRbUF6s8bBLHSgmVF/ePu5Kp3GJk4YNZs6xF6UDUELTMOyqoMur 6Mu8yn/QErFzRhuUVjyqUg9lekjFgWryJYYEYLTrhD9x170hbSjQRn/13IoiU8QUy55f uJpHMD9TKNt7zdrjkiL+EjfSQMiVqtk2hVMEH4vc76INTePIWOe/FIALF4nKXWwNAEhO ZmBg== X-Gm-Message-State: AOAM533cTTpqheW6nqBQ5gIrMgnLKo7eFdSE61Q51CD8p997qTWAPQDf QM9cmNQuVmhHN+iIwcYwybNrL0jOTSKcXHWNNh4= X-Google-Smtp-Source: ABdhPJzNA3JJZVwAjiZDa6wCmDh/nFa8ofCf4SoppoFs1xgAJx5/q1QjgOIKaNU6JshSXpTtTe4abFWF3ULH9HFnPFI= X-Received: by 2002:aed:2ca5:: with SMTP id g34mr15152669qtd.13.1591152225678; Tue, 02 Jun 2020 19:43:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tomas Mozes Date: Wed, 3 Jun 2020 04:43:33 +0200 Message-ID: Subject: Re: [Xen-users] xen domU stall on 4.12.1 To: Glen Content-Type: multipart/alternative; boundary="00000000000031fb0805a724ff8c" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --00000000000031fb0805a724ff8c Content-Type: text/plain; charset="UTF-8" On Mon, Feb 24, 2020 at 6:02 PM Tomas Mozes wrote: > > > On Mon, Feb 24, 2020 at 4:55 PM Glen wrote: > >> On Sun, Feb 23, 2020 at 11:12 PM Tomas Mozes >> wrote: >> > As reported in >> https://lists.xenproject.org/archives/html/xen-devel/2020-01/msg00361.html >> and >> https://lists.xenproject.org/archives/html/xen-users/2020-02/msg00042.html, >> switching back to credit1 scheduler seems to make it working again. I've >> migrated 6 machines to Xen 4.12 with sched=credit xen option and haven't >> observed a hang for more than a week now. >> >> My experience is the same. I have migrated all 16 of my physical >> hosts back to OpenSuse 15.1 with Xen 4.12.1 with sched=credit . All >> guests are now running perfectly, without any issues at all. Over >> this past week I performed directed stress-testing against several of >> my guests, and they all survived without any problems at all. I've >> now completely my migration to the new guests, and everyone is happy. >> >> I'm now going to bring one of the previously-live guests on its own >> host back to credit2 so I can crash it and try to capture debugging >> output for xen-devel as requested. But sched=credit is definitely >> what we needed to solve this problem! Thank you all for helping us >> get there! >> >> Glen >> > > Thank you too for your report. Hope we'll find the reason why credit2 > misbehaves. > > Tomas > Just tested Xen 4.12.3, but a domU hanged again with credit2. It works rock solid with credit1. Tomas --00000000000031fb0805a724ff8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 24, 2020 at 6:02 PM Tomas= Mozes <hydrapolic@gmail.com= > wrote:


On Mon, Feb 24, 2020 at 4:55 PM Glen <= glenbarney@gmail.= com> wrote:
On Sun, Feb 23, 2020 at 11:12 PM Tomas Mozes <hydrapolic@gmail.com> wrote:
> As reported in https:= //lists.xenproject.org/archives/html/xen-devel/2020-01/msg00361.html an= d https://lists.xenproject= .org/archives/html/xen-users/2020-02/msg00042.html, switching back to c= redit1 scheduler seems to make it working again. I've migrated 6 machin= es to Xen 4.12 with sched=3Dcredit xen option and haven't observed a ha= ng for more than a week now.

My experience is the same.=C2=A0 I have migrated all 16 of my physical
hosts back to OpenSuse 15.1 with Xen 4.12.1 with sched=3Dcredit .=C2=A0 All=
guests are now running perfectly, without any issues at all.=C2=A0 Over
this past week I performed directed stress-testing against several of
my guests, and they all survived without any problems at all.=C2=A0 I'v= e
now completely my migration to the new guests, and everyone is happy.

I'm now going to bring one of the previously-live guests on its own
host back to credit2 so I can crash it and try to capture debugging
output for xen-devel as requested.=C2=A0 But sched=3Dcredit is definitely what we needed to solve this problem!=C2=A0 Thank you all for helping us get there!

Glen

Thank you too for your report. Hop= e we'll find the reason why credit2 misbehaves.

Tomas

Just test= ed Xen 4.12.3, but a domU hanged again with credit2. It works rock solid wi= th credit1.

Tomas=C2=A0
--00000000000031fb0805a724ff8c-- From xen-devel-bounces@lists.xenproject.org Wed Jun 03 06:03:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 06:03:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgMUH-00017o-VL; Wed, 03 Jun 2020 06:02:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgMUG-00017i-Cn for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 06:02:52 +0000 X-Inumbo-ID: d8ba9f5e-a55f-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d8ba9f5e-a55f-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 06:02:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6DBE/X5SGiWjsyA5R6sp9gKcGII5yathg9/uFXEI32k=; b=1zD5DdhhNMmffnr1obeb0/7NB 4I74rHlhJYnxyUhji1tzeTbk+DmEqmc6wv6MfGf6Su8CMh/CQO92lCRHOnIbSaxgb7QvvM2vKztxA mCLaT+VN3ZRMDuqzHwpGn70qBsnQ/adwYi5OfxlAQvEGPxhItgn9bdQpkXH85lNiBrQ8I=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgMUA-0003cm-5g; Wed, 03 Jun 2020 06:02:46 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgMU9-0005iu-OZ; Wed, 03 Jun 2020 06:02:45 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgMU9-0002AE-Nt; Wed, 03 Jun 2020 06:02:45 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150637: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=99a76a88d5e7f4693bb6b286e366006e1da1c954 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Wed, 03 Jun 2020 06:02:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150637 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150637/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 99a76a88d5e7f4693bb6b286e366006e1da1c954 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 5 days Failing since 150465 2020-05-29 09:02:14 Z 4 days 36 attempts Testing same since 150629 2020-06-02 21:00:40 Z 0 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1494 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 06:11:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 06:11:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgMcB-000288-T1; Wed, 03 Jun 2020 06:11:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgMc9-000283-Dr for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 06:11:02 +0000 X-Inumbo-ID: fe1b139a-a560-11ea-9947-bc764e2007e4 Received: from mo4-p01-ob.smtp.rzone.de (unknown [81.169.146.165]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fe1b139a-a560-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 06:10:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591164658; s=strato-dkim-0002; d=aepfle.de; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=rl+vparLycNdfteqAgJA+SUTyfN1PPe3UardQIEADzU=; b=YMud8+ojFndirgjcaw4Hu7K5knUED87IbyLmobLq3xpDVAduU3Bg5vOgIWLmrzdS+z iDnwGYCGHmXWzQbbd8kEDcC92wfuEMxvlLemxVB3sY8ny+jsWI0teqTy+082ecGdvDvF V2sAa66GG1czsToRtvS9bNsFP9fT5ABqsTYFp6c7w3G5yLDodUMNtwMlpJU2+Dvpgv9P XiYkicNIr0nk9/11RTRhAKR7TpANsfB1P8I9cgy0a4Fpy6QdRpXyoRfT3IPbP2bvzUxd HQYniAPtTjAJF4VdUwROCGSOdSsv1zb5MUiWHLqhT419B8T1aFVVJidTfrkSUvzNUK8E 20HA== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QXkBR9MXjAuzBW/OdlBZQ4AHSS325Ojw==" X-RZG-CLASS-ID: mo00 Received: from aepfle.de by smtp.strato.de (RZmta 46.9.1 SBL|AUTH) with ESMTPSA id 205482w536Av04J (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 3 Jun 2020 08:10:57 +0200 (CEST) Date: Wed, 3 Jun 2020 08:10:53 +0200 From: Olaf Hering To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Subject: Re: [Xen-devel] [PATCH v3 5/9] libs: add libxenhypfs Message-ID: <20200603061053.GA19484@aepfle.de> References: <20200121084330.18309-1-jgross@suse.com> <20200121084330.18309-6-jgross@suse.com> <20200131155753.gyv4n67oz3znsxt5@debian> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 03, J=C3=BCrgen Gro=C3=9F wrote: > On 31.01.20 16:57, Wei Liu wrote: > > On Tue, Jan 21, 2020 at 09:43:26AM +0100, Juergen Gross wrote: > > > +Requires.private: xentoolcore,xentoollog,xencall > > Need to list libz here? > Probably, yes. See "rpm -qf --provides /usr/include/zlib.h" for the proper value within th= e "pkgconfig" namespace. It is 'zlib' instead of 'z'. Olaf --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7XPucACgkQ86SN7mm1 DoAA/Q//XnekQcHQ7IfLcQDfvQrVoG+JEKrdpEB1OUAElnYSSj8Z8+uhwYeC4pnY KPgCD8tgatMGW6UVsPyLTHnTObX3MqOIRR/50nO/PXrhTGIuBfAxymebBtA3ooQW 3oxEsNibcv19bXTWFqYGQQexXPcQWZ4l8szh49iWB0S+FbAKH1c8B/F52D3ZeKTT gAvQc5M7ceJ/vl1r2lkkAaa6qPmIiVPKdqxfwHfJkPAN9cVtz5ZGN85foPQu1iep WrXDqbRxZ5uZwMRf++tqYJTlx4uKdt6s7BHxCN/oKF5QsqL/oDvVjsKae5Lq5pKG ht3FQfsPQ8ebzjhQhGW5X9K82BVF+ctYnKFREEen3O7YeWBzn4wTyD+jxx0uSzrk ecstwu9NQZuLXtWwR4ohKkTmVTpDyHywqzBYnz5azOTHJjsVW21UMBa/TH/25QsJ sthgUBI0pHWmlfRVghhGESwDqMKD/iHQte3B/EDpVvG1DILRqWpHw7HG7Xa44Vbm 8Xs6RzLWw/9loHy2YB88vNQC1OOpfpkllSP3VuyL5fTgDrS55WdBBpuTxEqSBkrm 1gheDq11ApWqEF+8O3xKOqP4v0nJbqnvRphVoNxfTCMlFKXqxrbCJNXDRRLbVCRk YRUj3q+HKpdgv+0bKC8e9jOGxpN0u2g5AL3+RpOF99KyVBq2PLY= =ES5v -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From xen-devel-bounces@lists.xenproject.org Wed Jun 03 06:32:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 06:32:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgMwy-00045j-PD; Wed, 03 Jun 2020 06:32:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgMwx-00045e-Vu for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 06:32:32 +0000 X-Inumbo-ID: fc270672-a563-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fc270672-a563-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 06:32:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2r7GRIisuPrMmgs6u0HPEj9TNtMpJ6/HuQMyglyGHoc=; b=m93HzKtRqzGU9ZFgY6TPtjWlB CZZ3IGHvO9wfhTQsDLb37wcFNo1fPZiTPOM+y/McojOEwwqGXLNZ35g5gNckauK5dJIEAmmrEEfSy xhjvHDpsGWXCR7G8aZnvepQ793Wd7Vjw788PdLhfBD9fd+4WOFm+0oIVg4WNsJoDoy3uk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgMwp-0004EQ-IZ; Wed, 03 Jun 2020 06:32:23 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgMwp-00077W-AF; Wed, 03 Jun 2020 06:32:23 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgMwp-0002xK-9c; Wed, 03 Jun 2020 06:32:23 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150627: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:build-arm64-pvops:kernel-build:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start:fail:heisenbug linux-linus:test-armhf-armhf-xl-vhd:leak-check/check:fail:heisenbug linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-examine:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-xl:build-check(1):blocked:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking linux-linus:test-amd64-amd64-xl-rtds:guest-saverestore:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: linux=f359287765c04711ff54fbd11645271d8e5ff763 X-Osstest-Versions-That: linux=9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0 From: osstest service owner Date: Wed, 03 Jun 2020 06:32:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150627 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150627/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 150606 build-arm64-pvops 6 kernel-build fail in 150613 REGR. vs. 150606 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail pass in 150613 test-armhf-armhf-xl-vhd 18 leak-check/check fail pass in 150613 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-thunderx 1 build-check(1) blocked in 150613 n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked in 150613 n/a test-arm64-arm64-examine 1 build-check(1) blocked in 150613 n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked in 150613 n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked in 150613 n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked in 150613 n/a test-arm64-arm64-xl 1 build-check(1) blocked in 150613 n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked in 150613 n/a test-amd64-amd64-xl-rtds 16 guest-localmigrate fail blocked in 150606 test-amd64-amd64-xl-rtds 15 guest-saverestore fail in 150613 like 150606 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 150613 like 150606 test-armhf-armhf-xl-rtds 13 migrate-support-check fail in 150613 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 150613 never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150606 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150606 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150606 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150606 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150606 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150606 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150606 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150606 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-win7-amd64 2 hosts-allocate starved in 150613 n/a version targeted for testing: linux f359287765c04711ff54fbd11645271d8e5ff763 baseline version: linux 9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0 Last test of basis 150606 2020-06-01 19:40:10 Z 1 days Testing same since 150613 2020-06-02 05:14:57 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: "Eric W. Biederman" "Paul E. McKenney" Adrian Freund Adrian Hunter Al Viro Alessia Mantegazza Alex Shi Alex Shi # translations/zh_CN Alexander Stein Alexandre Chartre Alexey Budankov Amit Daniel Kachhap Andreas Gerstmayr Andrei Vagin Andrew Donnellan Andrew Morton Andrew Scull Andy Lutomirski Andy Shevchenko Anju T Sudhakar Anshuman Khandual Ard Biesheuvel Arnaldo Carvalho de Melo Arnd Bergmann Arvind Sankar Atish Patra Babu Moger Barret Rhoden Bartlomiej Zolnierkiewicz Benjamin Thiel Bjorn Helgaas Björn Töpel Borislav Petkov Borislav Petkov Bumsik Kim Bumsik Kim Casey Schaufler Catalin Marinas Christian Brauner Christoph Hellwig Christophe Leroy Chucheng Luo CodyYao-oc Corentin Labbe Cristian Souza Dan Williams Daniel Borkmann Daniel Kiss Daniel Thompson Dave Hansen Dave Hansen Dave Martin David Howells David Sterba # fs/affs/Kconfig Dimitri Sivanich Dmitry Safonov Doug Berger Douglas Anderson Eric W. Biederman Ethon Paul Etienne Carriere Fangrui Song Federico Vaga Federico Vaga # translations/it_IT Fenghua Yu Finn Thain Flavio Suligoi Florian Fainelli Frederic Weisbecker Gal Pressman Gavin Shan Geert Uytterhoeven Geert Uytterhoeven George Spelvin Giuseppe Scrivano Gregory Fong Guixiong Wei Gustavo A. R. Silva Gustavo A. R. Silva Hanjun Guo Hans Verkuil He Zhe Helge Deller Ian Rogers Ingo Molnar Jagadeesh Pagadala James Morris James Morse Jan Kara Jason Wang Jason Yan Jean-Philippe Brucker Jeremy Kerr Jessica Yu Jian Cai Jimmy Assarsson Jin Yao Jiri Olsa Jiri Olsa Jiri Slaby Joe Perches Joel Fernandes (Google) Joerg Roedel Johan Hovold Jonathan Corbet Jonathan Neuschäfer Josh Poimboeuf Joshua Abraham Joshua Abraham Juan Manuel Méndez Rey Jules Irenge Julia Cartwright Julien Thierry Kairui Song Kaitao Cheng Kajol Jain Kan Liang Kees Cook Kevin Cernekee Kevin Hao Kim Phillips Konstantin Kharlamov Konstantin Khlebnikov Lai Jiangshan Leo Yan Leonardo Bras Linus Torvalds Linus Walleij Lionel Landwerlin Lorenzo Pieralisi Luke Nelson Luke Nelson Marc Zyngier Marc Zyngier # kvm/arm64 Mark Brown Mark Gross Mark Rutland Masahiro Yamada Masami Hiramatsu Matt Helsley Matthew Wilcox (Oracle) Mauro Carvalho Chehab Michael Ellerman Michael S. Tsirkin Michal Hocko Michal Suchanek Michel Lespinasse Mike Galbraith Mike Leach Mike Rapoport Mike Rapoport Miklos Szeredi Miroslav Benes Muchun Song Namhyung Kim Nick Desaulniers Oded Gabbay Paul E. McKenney Paul Gortmaker Peter Zijlstra (Intel) Peter Zijlstra Petr Mladek Qais Yousef Qi Liu Qi Zheng Randy Dunlap Raphael Gault Ricardo Cañuelo Ricardo Ribalda Ricardo Ribalda Delgado Rikard Falkeborn Rob Herring Ronald G. Minnich Russell King Sai Prakash Ranjan Sam Ravnborg Sami Tolvanen Sandipan Das Sebastian Andrzej Siewior Sedat Dilek Serge E. Hallyn Shaokun Zhang Song Liu Stan Johnson Stefan Richter Stephane Eranian Stephen Boyd Stephen Kitt Stephen Smalley Steve Wahl Steven Rostedt (VMware) Sudeep Holla Sumanth Korikkar Suzuki K Poulose Tamas Zsoldos Tang Bin Thomas Backlund Thomas Gleixner Thomas Richter Tom Zanussi Tommi Rantala Tuan Phan Uros Bizjak Vamshi K Sthambamkadi Vincent Whitchurch Vincenzo Frascino Vitor Massaru Iha Vlastimil Babka Waiman Long Wang Wenhu Will Deacon Wolfram Sang Wolfram Sang Wolfram Sang Xi Wang Yu-cheng Yu YueHaibing Yunfeng Ye Zenghui Yu Zhaolong Zhang Zhou Wang Zou Wei Łukasz Stelmach jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 20159 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 07:10:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 07:10:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgNXS-0007me-0a; Wed, 03 Jun 2020 07:10:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgNXQ-0007mZ-F7 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 07:10:12 +0000 X-Inumbo-ID: 4030392e-a569-11ea-8993-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4030392e-a569-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 07:10:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jMg2PX30kQdQlhd/T/udZYp8OPoLtwjBvAcXgZHHQGY=; b=wENk4ZDbeMQibY167iCTa0nFm egr2yRCplmSUZOXZ3+XUxXjogqsKMJRxowNtyJRZe6ICV+8S9ghdRIWLsHoyEXhvoN8xr0jMoIiF0 fBODha8R4UTohpC/NNlL3U5yR1LZvRLCN1S9ZjGxyH2c72UVmSNgZNteXN9p7fLneIa+w=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgNXI-0004ze-VL; Wed, 03 Jun 2020 07:10:05 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgNXI-0001SH-Js; Wed, 03 Jun 2020 07:10:04 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgNXI-0007Ap-JA; Wed, 03 Jun 2020 07:10:04 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150631: tolerable FAIL - PUSHED X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=5cc7a54c2e91d82cb6a52e4921325c511fd90712 X-Osstest-Versions-That: qemuu=6bb228190ef0b45669d285114cf8a280c55f4b39 From: osstest service owner Date: Wed, 03 Jun 2020 07:10:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150631 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150631/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 150608 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150608 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150608 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150608 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150608 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150608 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150608 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: qemuu 5cc7a54c2e91d82cb6a52e4921325c511fd90712 baseline version: qemuu 6bb228190ef0b45669d285114cf8a280c55f4b39 Last test of basis 150608 2020-06-01 21:38:00 Z 1 days Testing same since 150631 2020-06-02 23:27:48 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: David Gibson Dr. David Alan Gilbert Eduardo Habkost Igor Mammedov John Paul Adrian Glaubitz Laurent Vivier Lukas Straub Miklos Szeredi Nick Hudson Pan Nengyuan Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé Richard Henderson Vivek Goyal jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/qemu-xen.git 6bb228190e..5cc7a54c2e 5cc7a54c2e91d82cb6a52e4921325c511fd90712 -> upstream-tested From xen-devel-bounces@lists.xenproject.org Wed Jun 03 07:23:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 07:23:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgNkf-0000ZW-AF; Wed, 03 Jun 2020 07:23:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgNke-0000ZR-LY for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 07:23:52 +0000 X-Inumbo-ID: 2c633c46-a56b-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2c633c46-a56b-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 07:23:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=s4siQdGA4lmrgEGX6yt71nMsmiYQLiRxp78VXfsCapc=; b=TesRJ6ai1JCO2pKzAOhdLpCPC bw4LwkoZIyjMjuPLBb9o9LFqw8khLsz+8pgR0Yf5SI67RI3DU90znDt6NQ/rDG5ZKpgqykFsya4FF KChQrngsqoRqmuL2rl8wK8OgQAvk2inopNwU1GMXTlHpAP7bqLm+Y4FAAbEYLyj/qzSQg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgNkc-0005GI-Hk; Wed, 03 Jun 2020 07:23:50 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgNkb-0001sR-V6; Wed, 03 Jun 2020 07:23:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgNkb-0004Sl-UR; Wed, 03 Jun 2020 07:23:49 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 150639: regressions - FAIL X-Osstest-Failures: libvirt:build-amd64-libvirt:libvirt-build:fail:regression libvirt:build-i386-libvirt:libvirt-build:fail:regression libvirt:build-arm64-libvirt:libvirt-build:fail:regression libvirt:build-armhf-libvirt:libvirt-build:fail:regression libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking libvirt:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking libvirt:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking libvirt:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking X-Osstest-Versions-This: libvirt=a5a297f387fee9e9aa4cbc2df6788c330fd33ad1 X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5 From: osstest service owner Date: Wed, 03 Jun 2020 07:23:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150639 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/150639/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-build fail REGR. vs. 146182 build-i386-libvirt 6 libvirt-build fail REGR. vs. 146182 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 146182 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 146182 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt a5a297f387fee9e9aa4cbc2df6788c330fd33ad1 baseline version: libvirt a1cd25b919509be2645dbe6f952d5263e0d4e4e5 Last test of basis 146182 2020-01-17 06:00:23 Z 138 days Failing since 146211 2020-01-18 04:18:52 Z 137 days 128 attempts Testing same since 150639 2020-06-03 04:26:10 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Arnaud Patard Artur Puzio Bjoern Walk Boris Fiuczynski Chen Hanxiao Chris Jester-Young Christian Borntraeger Christian Ehrhardt Christian Schoenebeck Collin Walling Cornelia Huck Daniel Henrique Barboza Daniel P. Berrangé Daniel Veillard Dario Faggioli Erik Skultety Gaurav Agrawal Han Han Jaak Ristioja Jamie Strandboge Jim Fehlig Jiri Denemark Jonathon Jongsma Julio Faracco Ján Tomko Laine Stump Leonid Bloch Liao Pingfang Lin Ma Marc-André Lureau Marek Marczykowski-Górecki Mark Asselstine Mauro S. M. Rodrigues Michal Privoznik Nikolay Shirokovskiy Paolo Bonzini Pavel Hrdina Pavel Mores Peter Krempa Philipp Hahn Pino Toscano Prathamesh Chavan Rafael Fonseca Richard W.M. Jones Rikard Falkeborn Ryan Moeller Sahid Orentino Ferdjaoui Sebastian Mitterle Seeteena Thoufeek Stefan Berger Stefan Berger Stefan Hajnoczi Thomas Huth Tobin Feldman-Fitzthum Tomáš Golembiovský Wu Qingliang Xu Yandong Yan Wang Yi Li Your Name Zhang Bo zhenwei pi Zhenyu Zheng Zhimin Feng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt blocked test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 19658 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 08:05:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 08:05:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgOOQ-00051E-3Y; Wed, 03 Jun 2020 08:04:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgOOO-000517-Ik for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 08:04:56 +0000 X-Inumbo-ID: e8ebe3b8-a570-11ea-9dbe-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e8ebe3b8-a570-11ea-9dbe-bc764e2007e4; Wed, 03 Jun 2020 08:04:55 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /I5ZVj8U7HfHGRMlpH5DQhW4Ul0ywGV4njgOWh+sg48a/eq0rqRa/PL/hQ6ICNEoaNtSv4N7pF uX2rhUAADtVp/MuMTptwUgKUtNhrYx5+ubRSb0vVNG/wzdFlP0X97Btold2Dy0XQ26uCzuoIDy HPdl5FFij5kKiGqEAnle10c2gDcVBc9IsecuUGywEqHo4AZWmJskpL7wAbjq4FDGh0tKIeqkoi LeddxBA051LO27SfhKqEuudH/eQZPYv3HFMon+zvMMAkuwKHISxf03Xf03VNt0Q/i3mA0ctis/ Oio= X-SBRS: 2.7 X-MesageID: 19842000 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19842000" Date: Wed, 3 Jun 2020 10:04:40 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel , Alexandru Isaila , Petre Pircalabu Subject: Re: [PATCH v2 for-4.14 1/3] xen/monitor: Control register values Message-ID: <20200603080440.GB1195@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 07:10:07AM -0600, Tamas K Lengyel wrote: > On Tue, Jun 2, 2020 at 7:00 AM Jan Beulich wrote: > > > > On 02.06.2020 14:51, Tamas K Lengyel wrote: > > > On Tue, Jun 2, 2020 at 6:47 AM Jan Beulich wrote: > > >> > > >> On 02.06.2020 14:40, Tamas K Lengyel wrote: > > >>> On Tue, Jun 2, 2020 at 5:08 AM Roger Pau Monné wrote: > > >>>> > > >>>> On Wed, May 20, 2020 at 08:31:52PM -0600, Tamas K Lengyel wrote: > > >>>>> Extend the monitor_op domctl to include option that enables > > >>>>> controlling what values certain registers are permitted to hold > > >>>>> by a monitor subscriber. > > >>>> > > >>>> I think the change could benefit for some more detail commit message > > >>>> here. Why is this useful? > > >>> > > >>> You would have to ask the Bitdefender folks who made the feature. I > > >>> don't use it. Here we are just making it optional as it is buggy so it > > >>> is disabled by default. > > >> > > >> Now that's exactly the opposite of what I had derived from the > > >> description here so far. Perhaps an at least weak indication > > >> that you want to reword this. For example, from your reply to > > >> Roger I understand it's rather that the new flag allows to > > >> "suppress" the controlling (since presumably you don't change > > >> default behavior), rather then "enabling" it. > > > > > > What we are adding is a domctl you need to call that enables this > > > feature. It's not an option to suppress it. It shouldn't have been > > > enabled by default to begin with. That was a mistake when the feature > > > was contributed and it is buggy. > > > > Okay, in this case it's important to point out that you alter > > default behavior. The BitDefender folks may not like this, yet > > they've been surprisingly silent so far. > > Well, it was Bitdefender who altered the default behavior. We are > reverting their mistake and making it optional. But I can certainly > make that more clear. I would like some input from the Bitdefender guys. Is there a bugfix planned for this feature? It would be nice to get this in before 4.14 releases. Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 08:22:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 08:22:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgOf6-0006z9-JH; Wed, 03 Jun 2020 08:22:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgOf5-0006z4-8r for xen-devel@lists.xen.org; Wed, 03 Jun 2020 08:22:11 +0000 X-Inumbo-ID: 51143f60-a573-11ea-acc2-12813bfff9fa Received: from smtp-fw-9101.amazon.com (unknown [207.171.184.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 51143f60-a573-11ea-acc2-12813bfff9fa; Wed, 03 Jun 2020 08:22:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1591172529; x=1622708529; h=from:to:cc:subject:date:message-id:mime-version; bh=ARn20Ks4gi+MwJ5XghU+Mr/g0WdxCT6F+9//DF8fqCw=; b=ppY58cH1XRS0lRK1gw96mof4ssk1wVeOHvmfxVoJiOXwllkTkK3FRctL kBwi/MVpEDSDiU3DikfYnJcM9F5GNWtTpRb1Xv+JCoKtgA1zAI2yG/3EY zXlQoNLaiEvVrFNB1Xq191+G33VoOCTNDNF9wgLm6HbayIaqkqyp6B8xU g=; IronPort-SDR: Xb2wbzz0PQOxjYaZUgbaf/vRYZ5inswviuO6tk2vCNMO47g0BdXWE0YGwtqx9CuD/iM0hSs22s 8i0z3G1FhLVw== X-IronPort-AV: E=Sophos;i="5.73,467,1583193600"; d="scan'208";a="41173025" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 03 Jun 2020 08:22:07 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-37fd6b3d.us-east-1.amazon.com (Postfix) with ESMTPS id 17F0928661B; Wed, 3 Jun 2020 08:22:05 +0000 (UTC) Received: from EX13D05EUB004.ant.amazon.com (10.43.166.115) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 08:22:05 +0000 Received: from EX13MTAUWB001.ant.amazon.com (10.43.161.207) by EX13D05EUB004.ant.amazon.com (10.43.166.115) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 08:22:03 +0000 Received: from dev-dsk-wipawel-1a-0c4e6d58.eu-west-1.amazon.com (10.4.134.33) by mail-relay.amazon.com (10.43.161.249) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Wed, 3 Jun 2020 08:22:00 +0000 From: Pawel Wieczorkiewicz To: Subject: [XTF] xenbus: fix xenbus_write() ring overflow Date: Wed, 3 Jun 2020 08:21:41 +0000 Message-ID: <20200603082141.42683-1-wipawel@amazon.de> X-Mailer: git-send-email 2.16.6 MIME-Version: 1.0 Content-Type: text/plain Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Pawel Wieczorkiewicz , julien@xen.org, wipawel@xen.org, andrew.cooper3@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Currently the xenbus_write() does not handle ring wrapping around correctly. When ring buffer is almost full and there is not enough space for next packet (e.g. there is 12 bytes of space left, but the packet header needs to transmit 16 bytes) the memcpy() goes out of the ring buffer boundry. Instead, the part variable should be limited to the space available in the ring buffer, so the memcpy() can fill up the buffer, update len variable (to indicate that there is still some data to be copied) and thereby the xenbus_write() loop can iterate again to finish copying the remainder of data to the beginning of the ring buffer. Signed-off-by: Pawel Wieczorkiewicz --- common/xenbus.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/common/xenbus.c b/common/xenbus.c index 59159f2..24fff48 100644 --- a/common/xenbus.c +++ b/common/xenbus.c @@ -31,9 +31,7 @@ static void xenbus_write(const void *data, size_t len) uint32_t prod = ACCESS_ONCE(xb_ring->req_prod); uint32_t cons = ACCESS_ONCE(xb_ring->req_cons); - uint32_t used = mask_xenbus_idx(prod - cons); - - part = (XENBUS_RING_SIZE - 1) - used; + part = (XENBUS_RING_SIZE - 1) - mask_xenbus_idx(prod - cons); /* No space? Kick xenstored and wait for it to consume some data. */ if ( !part ) @@ -47,7 +45,7 @@ static void xenbus_write(const void *data, size_t len) } /* Don't overrun the ring. */ - part = min(part, XENBUS_RING_SIZE - used); + part = min(part, XENBUS_RING_SIZE - mask_xenbus_idx(prod)); /* Don't write more than necessary. */ part = min(part, (unsigned int)len); -- 2.16.6 Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 08:28:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 08:28:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgOlI-0007Av-7h; Wed, 03 Jun 2020 08:28:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgOlH-0007Aq-Ai for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 08:28:35 +0000 X-Inumbo-ID: 354fc758-a574-11ea-acc2-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 354fc758-a574-11ea-acc2-12813bfff9fa; Wed, 03 Jun 2020 08:28:32 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 5Pfd5EA0FO29FX/5b5K50PyQN2pKtRGvcejWlONWK1Ob81Dtm2wlUUXtbTIPTJ/TZ09a0RgERK wlTcfTJdI2gomLzUalE5WXNoWHTFt+X+ZAvmGoS9ajHgmFn9jtWefkdWLR6G5Fv2cMdAB8Is9Q GwPXa4xLDW3uuPJBuap0X7HieuAXwjaB2psBGZYmDdfXifGYQAgIRNRYNQhachE63eE7KOtHky nkDHChw0ACKXaaotL84cDkO1326bi71w/M0mlzmCkijAhm1l7ubaauLBUMewOjCAah5CsEbqfk 37c= X-SBRS: 2.7 X-MesageID: 19093770 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19093770" Date: Wed, 3 Jun 2020 10:28:24 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH v3 for-4.14] x86/monitor: revert default behavior when monitoring register write events Message-ID: <20200603082824.GC1195@Air-de-Roger> References: <20200602134909.66581-1-tamas@tklengyel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <20200602134909.66581-1-tamas@tklengyel.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 07:49:09AM -0600, Tamas K Lengyel wrote: > For the last couple years we have received numerous reports from users of > monitor vm_events of spurious guest crashes when using events. In particular, > it has observed that the problem occurs when vm_events are being disabled. The > nature of the guest crash varied widely and has only occured occasionally. This > made debugging the issue particularly hard. We had discussions about this issue > even here on the xen-devel mailinglist with no luck figuring it out. > > The bug has now been identified as a race-condition between register event > handling and disabling the monitor vm_event interface. > > Patch 96760e2fba100d694300a81baddb5740e0f8c0ee, "vm_event: deny register writes > if refused by vm_event reply" is the patch that introduced the error. In this FWIW, we use the 'Fixes:' tag in order to make it easier for maintainers of stable trees to know which bugfixes to pick. This should have: Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event reply') Before the SoB. > patch the default behavior regarding emulation of register write events is > changed so that they get postponed until the corresponding vm_event handler > decides whether to allow such write to take place. Unfortunately this can only > be implemented by performing the deny/allow step when the vCPU gets scheduled. > Due to that postponed emulation of the event if the user decides to pause the > VM in the vm_event handler and then disable events, the entire emulation step > is skipped the next time the vCPU is resumed. Even if the user doesn't pause > during the vm_event handling but exits immediately and disables vm_event, the > situation becomes racey as disabling vm_event may succeed before the guest's > vCPUs get scheduled with the pending emulation task. This has been particularly > the case with VMS that have several vCPUs as after the VM is unpaused it may > actually take a long time before all vCPUs get scheduled. > > In this patch we are reverting the default behavior to always perform emulation > of register write events when the event occurs. To postpone them can be turned > on as an option. In that case the user of the interface still has to take care > of only disabling the interface when its safe as it remains buggy. > > Signed-off-by: Tamas K Lengyel Thanks for taking care of this! > --- > xen/arch/x86/hvm/hvm.c | 14 ++++++++------ > xen/arch/x86/hvm/monitor.c | 13 ++++++++----- > xen/arch/x86/monitor.c | 10 +++++++++- > xen/include/asm-x86/domain.h | 1 + > xen/include/asm-x86/hvm/monitor.h | 7 +++---- > xen/include/public/domctl.h | 1 + > 6 files changed, 30 insertions(+), 16 deletions(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 74c9f84462..5bb47583b3 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -3601,13 +3601,15 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content, > > ASSERT(v->arch.vm_event); > > - /* The actual write will occur in hvm_do_resume() (if permitted). */ > - v->arch.vm_event->write_data.do_write.msr = 1; > - v->arch.vm_event->write_data.msr = msr; > - v->arch.vm_event->write_data.value = msr_content; > + if ( hvm_monitor_msr(msr, msr_content, msr_old_content) ) > + { > + /* The actual write will occur in hvm_do_resume(), if permitted. */ > + v->arch.vm_event->write_data.do_write.msr = 1; > + v->arch.vm_event->write_data.msr = msr; > + v->arch.vm_event->write_data.value = msr_content; > > - hvm_monitor_msr(msr, msr_content, msr_old_content); > - return X86EMUL_OKAY; > + return X86EMUL_OKAY; > + } > } > > if ( (ret = guest_wrmsr(v, msr, msr_content)) != X86EMUL_UNHANDLEABLE ) > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c > index 8aa14137e2..36894b33a4 100644 > --- a/xen/arch/x86/hvm/monitor.c > +++ b/xen/arch/x86/hvm/monitor.c > @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long old) > .u.write_ctrlreg.old_value = old > }; > > - if ( monitor_traps(curr, sync, &req) >= 0 ) > - return 1; > + return monitor_traps(curr, sync, &req) >= 0 && > + curr->domain->arch.monitor.control_register_values; Nit (it can be fixed while committing IMO): curr should be aligned to monitor. > } > > - return 0; > + return false; > } > > bool hvm_monitor_emul_unimplemented(void) > @@ -77,7 +77,7 @@ bool hvm_monitor_emul_unimplemented(void) > monitor_traps(curr, true, &req) == 1; > } > > -void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value) > +bool hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value) > { > struct vcpu *curr = current; > > @@ -92,8 +92,11 @@ void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value) > .u.mov_to_msr.old_value = old_value > }; > > - monitor_traps(curr, 1, &req); > + return monitor_traps(curr, 1, &req) >= 0 && > + curr->domain->arch.monitor.control_register_values; Same here. > } > + > + return false; > } > > void hvm_monitor_descriptor_access(uint64_t exit_info, > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > index bbcb7536c7..1517a97f50 100644 > --- a/xen/arch/x86/monitor.c > +++ b/xen/arch/x86/monitor.c > @@ -144,7 +144,15 @@ int arch_monitor_domctl_event(struct domain *d, > struct xen_domctl_monitor_op *mop) > { > struct arch_domain *ad = &d->arch; > - bool requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op); > + bool requested_status; > + > + if ( XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS == mop->op ) > + { > + ad->monitor.control_register_values = true; > + return 0; I think this would be better implemented in arch_monitor_domctl_op which already handles other XEN_DOMCTL_MONITOR_OP_* options, and also skips the arch_monitor_domctl_event call? > + } > + > + requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op); > > switch ( mop->event ) > { > diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h > index e8cee3d5e5..6fd94c2e14 100644 > --- a/xen/include/asm-x86/domain.h > +++ b/xen/include/asm-x86/domain.h > @@ -418,6 +418,7 @@ struct arch_domain > * This is used to filter out pagefaults. > */ > unsigned int inguest_pagefault_disabled : 1; > + unsigned int control_register_values : 1; > struct monitor_msr_bitmap *msr_bitmap; > uint64_t write_ctrlreg_mask[4]; > } monitor; > diff --git a/xen/include/asm-x86/hvm/monitor.h b/xen/include/asm-x86/hvm/monitor.h > index 66de24cb75..a75cd8545c 100644 > --- a/xen/include/asm-x86/hvm/monitor.h > +++ b/xen/include/asm-x86/hvm/monitor.h > @@ -29,15 +29,14 @@ enum hvm_monitor_debug_type > }; > > /* > - * Called for current VCPU on crX/MSR changes by guest. > - * The event might not fire if the client has subscribed to it in onchangeonly > - * mode, hence the bool return type for control register write events. > + * Called for current VCPU on crX/MSR changes by guest. Bool return signals > + * whether emulation should be postponed. > */ > bool hvm_monitor_cr(unsigned int index, unsigned long value, > unsigned long old); > #define hvm_monitor_crX(cr, new, old) \ > hvm_monitor_cr(VM_EVENT_X86_##cr, new, old) > -void hvm_monitor_msr(unsigned int msr, uint64_t value, uint64_t old_value); > +bool hvm_monitor_msr(unsigned int msr, uint64_t value, uint64_t old_value); > void hvm_monitor_descriptor_access(uint64_t exit_info, > uint64_t vmx_exit_qualification, > uint8_t descriptor, bool is_write); > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h > index 1ad34c35eb..cbcd25f12c 100644 > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -1025,6 +1025,7 @@ struct xen_domctl_psr_cmt_op { > #define XEN_DOMCTL_MONITOR_OP_DISABLE 1 > #define XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES 2 > #define XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP 3 > +#define XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS 4 Could you please add a note that this is broken? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 09:16:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 09:16:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgPVo-0003W8-1G; Wed, 03 Jun 2020 09:16:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgPVm-0003W3-OU for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 09:16:38 +0000 X-Inumbo-ID: ed7841d8-a57a-11ea-9dbe-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ed7841d8-a57a-11ea-9dbe-bc764e2007e4; Wed, 03 Jun 2020 09:16:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=boeBwvLycEOU4JA4Sm6V9LSyGxUpTFD0jdYR3b8L1D4=; b=QrfJA42y+aY5OJxf7gisp2/wb D0O/wt7DY1ckvloq6Vp0H4G/nO6+J6ReUF3llbN0xAmeOYcCKEyvXmDcA+v0TeuXoI39gtkIjY6B2 tbepP3bA1RKn02eZe40nOzVMJySaYb5oUbwLoc6THdSaNMvoOjG2LnhCKWQElC9OFZzm0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgPVl-00086G-Au; Wed, 03 Jun 2020 09:16:37 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgPVl-0007io-0j; Wed, 03 Jun 2020 09:16:37 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgPVk-0006ha-WC; Wed, 03 Jun 2020 09:16:36 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150643: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=99a76a88d5e7f4693bb6b286e366006e1da1c954 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Wed, 03 Jun 2020 09:16:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150643 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150643/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 99a76a88d5e7f4693bb6b286e366006e1da1c954 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 5 days Failing since 150465 2020-05-29 09:02:14 Z 5 days 37 attempts Testing same since 150629 2020-06-02 21:00:40 Z 0 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1494 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 09:51:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 09:51:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQ2w-0007Gh-5t; Wed, 03 Jun 2020 09:50:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQ2u-0007GW-K4 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 09:50:52 +0000 X-Inumbo-ID: b58289b4-a57f-11ea-9947-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b58289b4-a57f-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 09:50:51 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: jAKVYADhKXmHgeV57P88emxFvokNBwAnDTXSfzbeJCqwwg0mRHq9Ozx9Yf5Re/Ntspoi65gswj FRHiyIADw4YmK2tk8nOPjs7jnZGKSlkqMhajQ+tog6LFpTXQYhYaghDgm1HzoRHuUcUhfZ56Uv cNDNmkY35ELHjrMcNbCCWhdekkGGzXBzATOPTBYbaXfb99ScaVvN7DrffJINj6fmhILQVpwjn0 eSBV6ejHStlTsjwvGFhvUyzWYYn4jSwTnH5WA59Q01ANpT6lyQf80dZXelEVLmLJxYB/ZxlO0W DvU= X-SBRS: 2.7 X-MesageID: 19452336 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19452336" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24279.29302.517771.382439@mariner.uk.xensource.com> Date: Wed, 3 Jun 2020 10:50:46 +0100 To: Roger Pau Monne Subject: Re: [PATCH 0/2] osstest: update FreeBSD guest tests In-Reply-To: <20200528102648.8724-1-roger.pau@citrix.com> References: <20200528102648.8724-1-roger.pau@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Roger Pau Monne writes ("[PATCH 0/2] osstest: update FreeBSD guest tests"): > The following series adds FreeBSD 11 and 12 guests tests to osstest. > ATM this is only tested on amd64, since the i386 versions had a bug. > > The result can be seen at: > > http://logs.test-lab.xenproject.org/osstest/logs/150428/ Thanks, Roger. I think that for this change I ought to get an ack from Paul as the RM. Paul: how do you want to handle osstest changes during the freeze ? I already pushed on Monday - without asking you - a series to fix a problem with bisection which was stopping osstest from bisecting the libvirt failure in the smoke tests. Please let me know if you think I should have checked with you. I think we should take this change from Roger. Right now we are still waiting for even the smoke tests from staging to pass. I don't think this would interfere with that nor will it get in the way of the osstest buster upgrade. Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 09:51:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 09:51:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQ2p-0007Fy-RE; Wed, 03 Jun 2020 09:50:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQ2n-0007Ft-Vp for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 09:50:46 +0000 X-Inumbo-ID: b15eb524-a57f-11ea-acd3-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b15eb524-a57f-11ea-acd3-12813bfff9fa; Wed, 03 Jun 2020 09:50:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D0502ACB1; Wed, 3 Jun 2020 09:50:46 +0000 (UTC) Subject: Re: Re [PATCH] x86/CET: Fix build following c/s 43b98e7190 To: Andrew Cooper References: <1eeb47f4-b9b9-c4d8-a5c9-58d78f0e0aeb@suse.com> From: Jan Beulich Message-ID: Date: Wed, 3 Jun 2020 11:50:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 19:15, Andrew Cooper wrote: > On 02/06/2020 15:21, Jan Beulich wrote: >>> OSSTest reports: >>> >>> x86_64.S: Assembler messages: >>> x86_64.S:57: Error: no such instruction: `setssbsy' >>> /home/osstest/build.150510.build-amd64/xen/xen/Rules.mk:183: recipe for target 'head.o' failed >>> make[4]: Leaving directory '/home/osstest/build.150510.build-amd64/xen/xen/arch/x86/boot' >>> make[4]: *** [head.o] Error 1 >>> >>> All use of CET instructions, even those inside alternative blocks, needs to be >>> behind CONFIG_XEN_SHSTK, as it indicates suitable toolchain support. >>> >>> Signed-off-by: Andrew Cooper >> That's quite a bit of #ifdef-ary here. Simple (operand-less) insns >> like SETSSBSY could easily be made available via .byte directives. >> Would you be amenable to to ack-ing a patch to replace some of the >> #ifdef-s (at least the ones at the lstar, cstar, and sysenter >> entry points), after 4.14? > > Yeah - that was a bit of a mess in the end.  (But given the > circumstances, and that I've got past form typo'ing the SETSSBSY opcode, > it probably was the right move even in hindsight). > > Reducing it to .byte should be fine so long as some form of /* setssbsy > */ comment appears. Sure. > One other option would be to introduce a SETSSBSY macro, but that hides > the alternative so is something I'd prefer to avoid. With this you mean you'd rather not see us go the CLAC/STAC route? I was instead thinking of a pure assembly macro named "setssbsy". In fact we could switch the CLAC/STAC ugliness to some such, if we end up being happy with the model. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 03 09:52:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 09:52:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQ4F-0007PY-Gg; Wed, 03 Jun 2020 09:52:15 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQ4E-0007PO-OI for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 09:52:14 +0000 X-Inumbo-ID: e691a79c-a57f-11ea-acd3-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e691a79c-a57f-11ea-acd3-12813bfff9fa; Wed, 03 Jun 2020 09:52:14 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: GWqx20nbRQ5mQca92paAidzTrGGh/rAd7kPxvmds8CSIyLwxxAd9Xmbncc2XvP40iHHdo5D9PN YwuYb4VPzkbbqfG+PqivFRh40M+rdHeC0/UNUjlljYvN84qoNqnnvsf1esQyNwVH9kV8NCjhmz PWv0cYZj47bv0ycXZXNBj/rC+Ddsc0WXckwjXu1SFEBSLRwEZ4OnI/JCuT8iNt70rvXTHHUEAx /5ASFaOE7oGZHPibf6BouB9dHqqkAXLWkWz4lL4OwCLZqhCYlDk/R/5Kyoa+h57U7o/vRr5IYC qyw= X-SBRS: 2.7 X-MesageID: 19452395 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19452395" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24279.29385.267956.941601@mariner.uk.xensource.com> Date: Wed, 3 Jun 2020 10:52:09 +0100 To: Roger Pau Monne Subject: Re: [PATCH 0/2] osstest: update FreeBSD guest tests In-Reply-To: <20200528102648.8724-1-roger.pau@citrix.com> References: <20200528102648.8724-1-roger.pau@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Roger Pau Monne writes ("[PATCH 0/2] osstest: update FreeBSD guest tests"): > The following series adds FreeBSD 11 and 12 guests tests to osstest. > ATM this is only tested on amd64, since the i386 versions had a bug. > > The result can be seen at: > > http://logs.test-lab.xenproject.org/osstest/logs/150428/ Oh, I forgot to say, both patches Acked-by: Ian Jackson From xen-devel-bounces@lists.xenproject.org Wed Jun 03 10:03:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 10:03:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQF0-00008N-J7; Wed, 03 Jun 2020 10:03:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQEz-00008I-5K for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 10:03:21 +0000 X-Inumbo-ID: 73c36d52-a581-11ea-acd3-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 73c36d52-a581-11ea-acd3-12813bfff9fa; Wed, 03 Jun 2020 10:03:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 43B14AEEF; Wed, 3 Jun 2020 10:03:22 +0000 (UTC) Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately To: Igor Druzhinin References: <1591116981-30162-1-git-send-email-igor.druzhinin@citrix.com> From: Jan Beulich Message-ID: <37e6e543-564d-2625-b8d9-ccca6106efd2@suse.com> Date: Wed, 3 Jun 2020 12:03:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <1591116981-30162-1-git-send-email-igor.druzhinin@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: wl@xen.org, Paul Durrant , andrew.cooper3@citrix.com, george.dunlap@citrix.com, xen-devel@lists.xenproject.org, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 02.06.2020 18:56, Igor Druzhinin wrote: > A recalculation NPT fault doesn't always require additional handling > in hvm_hap_nested_page_fault(), moreover in general case if there is no > explicit handling done there - the fault is wrongly considered fatal. > > This covers a specific case of migration with vGPU assigned on AMD: > at a moment log-dirty is enabled globally, recalculation is requested > for the whole guest memory including directly mapped MMIO regions of vGPU > which causes a page fault being raised at the first access to those; > but due to MMIO P2M type not having any explicit handling in > hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled > SVM violation. > > Instead of trying to be opportunistic - use safer approach and handle > P2M recalculation in a separate NPT fault by attempting to retry after > making the necessary adjustments. This is aligned with Intel behavior > where there are separate VMEXITs for recalculation and EPT violations > (faults) and only faults are handled in hvm_hap_nested_page_fault(). > Do it by also unifying do_recalc return code with Intel implementation > where returning 1 means P2M was actually changed. > > Since there was no case previously where p2m_pt_handle_deferred_changes() > could return a positive value - it's safe to replace ">= 0" with just "== 0" > in VMEXIT_NPF handler. finish_type_change() is also not affected by the > change as being able to deal with >0 return value of p2m->recalc from > EPT implementation. > > Reviewed-by: Roger Pau Monné > Signed-off-by: Igor Druzhinin Reviewed-by: Jan Beulich albeit preferably with ... > @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) > clear_recalc(l1, e); > err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); > ASSERT(!err); > + > + recalc_done = true; > } > > out: > unmap_domain_page(table); > > - return err; > + return err ?: (recalc_done ? 1 : 0); ... this shrunk to return err ?: recalc_done; (easily doable while committing). Also Cc Paul. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 03 10:17:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 10:17:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQS7-0001F8-SI; Wed, 03 Jun 2020 10:16:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQS6-0001F3-Qt for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 10:16:54 +0000 X-Inumbo-ID: 58e9964e-a583-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 58e9964e-a583-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 10:16:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=8mRhuUxnO156PHabG+ARbKCVHN7CrvZydkVf9zuTDu4=; b=ySbFCUK3RDRAnNekLYwWLNjZlt k7pgmSOYIp624eiRyfYPa4S1U+yUWpT0DqwWGeOFO65ouLjd47rx1Hg+6AqNAQLprA4PPgPt7trbx cirMj/aW+Yx2AKZF4mN0J/wW5eklHpt+nS8va+7TbdIZwnX3ACFQ1tvnsNvQTLmawcX4=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQS5-000156-OT; Wed, 03 Jun 2020 10:16:53 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgQS5-0004LH-I0; Wed, 03 Jun 2020 10:16:53 +0000 Subject: Re: UEFI support in ARM DomUs To: Roman Shaposhnik , Julien Grall References: From: Julien Grall Message-ID: <7fe687e0-092b-6477-76cc-24eabc966ef8@xen.org> Date: Wed, 3 Jun 2020 11:16:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Stefano Stabellini , Nataliya Korovkina Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 01/06/2020 05:11, Roman Shaposhnik wrote: > Hi Julien! Hi Roman, > > On Sun, May 31, 2020 at 3:24 PM Julien Grall wrote: >> >> On Sun, 31 May 2020 at 23:05, Roman Shaposhnik wrote: >>> Hi! >>> >>> with a lot of help from Stefano, we're getting RPi4 support in >>> Project EVE pretty much on par between KVM and Xen. >>> >>> One big area that still remains is supporting UEFI boot sequence >>> for DomUs. With KVM, given the qemu virt device model this is >>> as simple as using either stock UEFI build for arm or even U-Boot >>> EFI emulation environment and passing it via -bios option. >>> >>> Obviously with Xen on ARM we don't have the device model so >>> my understanding is that the easiest way we can support it would >>> be to port UEFI's OvmfPkg/OvmfXen target to ARM (it seems to >>> be currently exclusively X64). >> >> EDK2 has been supporting Xen on Arm for the past 5 years. We don't use >> OvmfPkg/OvmfXen but ArmVirtPkg/ArmVirtXen (see [1]). >> I haven't tried to build it recently, but I should be able to help if >> there is any issue with it. >> >> Cheers, >> >> [1] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtXen.fdf > > This is really, really awesome -- I guess it would be really helpful to document > this someplace on the ARM/Xen wiki (I can volunteer if someone can grant > me the karma). There used to be a page on the Linaro wiki when they did the port. But it looks like any Xen pages have been removed/relocated :(. Anyway, a page on Xen Project wiki would definitely be appreciated. > > I've built XEN_EFI.fd and the rest worked out like a charm. Glad to hear that it worked :). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 03 10:26:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 10:26:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQbP-0002H6-RL; Wed, 03 Jun 2020 10:26:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQbP-0002H1-60 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 10:26:31 +0000 X-Inumbo-ID: b055b9d4-a584-11ea-8993-bc764e2007e4 Received: from mail-wm1-x334.google.com (unknown [2a00:1450:4864:20::334]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b055b9d4-a584-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 10:26:30 +0000 (UTC) Received: by mail-wm1-x334.google.com with SMTP id v19so1387331wmj.0 for ; Wed, 03 Jun 2020 03:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=N8FbJHJO1QHHYhzbzBEwMk+G+iLLSzH6Hh+aqkR54q0=; b=LDZXNgZXrRc7xLsN1ig1XK86LUXAwXZ8blvSpl/ov8/HEWelEhNcEiPX+R0ZCZp2WI ibxLjCfylSlwiwiI5OM7NJ5aH5E6gahbFsNow5hioP6wgZGazFERiCF3QUbzlWXwFN0t k+uzqiQfH3J6n1vfSRYapMA15I29dit4L8IF4ijIjeWrFSr/mWGzmD+RtObNYJqTLi8J H5BdIG55v8v8d/GgZR+3nMXWGHtCVKsf7yha+SMnRHI4bhTTnAa1K132Xry24rBWyfZk 5JITkh+3tDnkhHEg2pjFbk8TGuhQqmUBeJTS1+RXaPv+y82B9wbatfHAgtycLWFqw6AK o+UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=N8FbJHJO1QHHYhzbzBEwMk+G+iLLSzH6Hh+aqkR54q0=; b=NELJ+R9EcicA3cnrjqrHsRTrkMpRGWEZlPL68v5PwUo7YSw2MWKl86ut9QurlY1/FZ k55qQjCIZ64RMMq2VoeD+E0rvI9EV3LpbY3cIPZy/xAkTmG2NGY6/AZg27HaltuZDuko Id1TdRb7AaNZ/JGYQ6UjCjG67Ew24lUkqOChrJjdyjHj48Z5Cr63wesVjOzPHMFFYJT/ IoVovOjbXx1Wv6z/apy9az2QNKzLZKd4QVhtZp+dKV6qGAqsMvcgevyzsU4iqlpvi8Br RfSxJHHFeVSzkkTn4fvMfpuCPtMakzmTAxSLwGAY6gKvqLwA1l7KS3cN37CQdx29+wO4 8LOA== X-Gm-Message-State: AOAM531kggBDpfZ20uBE7IvpkDwWYkTiv7FDh/l5qP2SVI4edMjx3hjr 7TgS6kAgauZR9qT+GK/QTZs= X-Google-Smtp-Source: ABdhPJyM/J6a5Sm752fgnA+7iBOfx/lZjzYotSG9dNGE+6DxuwTUomfNZ6pcJuiPupW9NZ28PHAGXA== X-Received: by 2002:a1c:8048:: with SMTP id b69mr7768316wmd.169.1591179989754; Wed, 03 Jun 2020 03:26:29 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id q1sm2192126wmc.12.2020.06.03.03.26.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2020 03:26:29 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , "'Igor Druzhinin'" References: <1591116981-30162-1-git-send-email-igor.druzhinin@citrix.com> <37e6e543-564d-2625-b8d9-ccca6106efd2@suse.com> In-Reply-To: <37e6e543-564d-2625-b8d9-ccca6106efd2@suse.com> Subject: RE: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately Date: Wed, 3 Jun 2020 11:26:27 +0100 Message-ID: <000f01d63991$717b5e80$54721b80$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGQ4llbDaBtW772ehRPn2nRu43DNwHKaT0mqUMJt2A= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com, george.dunlap@citrix.com, wl@xen.org, andrew.cooper3@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 03 June 2020 11:03 > To: Igor Druzhinin > Cc: xen-devel@lists.xenproject.org; andrew.cooper3@citrix.com; = wl@xen.org; roger.pau@citrix.com; > george.dunlap@citrix.com; Paul Durrant > Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT = faults immediately >=20 > On 02.06.2020 18:56, Igor Druzhinin wrote: > > A recalculation NPT fault doesn't always require additional handling > > in hvm_hap_nested_page_fault(), moreover in general case if there is = no > > explicit handling done there - the fault is wrongly considered = fatal. > > > > This covers a specific case of migration with vGPU assigned on AMD: > > at a moment log-dirty is enabled globally, recalculation is = requested > > for the whole guest memory including directly mapped MMIO regions of = vGPU > > which causes a page fault being raised at the first access to those; > > but due to MMIO P2M type not having any explicit handling in > > hvm_hap_nested_page_fault() a domain is erroneously crashed with = unhandled > > SVM violation. > > > > Instead of trying to be opportunistic - use safer approach and = handle > > P2M recalculation in a separate NPT fault by attempting to retry = after > > making the necessary adjustments. This is aligned with Intel = behavior > > where there are separate VMEXITs for recalculation and EPT = violations > > (faults) and only faults are handled in hvm_hap_nested_page_fault(). > > Do it by also unifying do_recalc return code with Intel = implementation > > where returning 1 means P2M was actually changed. > > > > Since there was no case previously where = p2m_pt_handle_deferred_changes() > > could return a positive value - it's safe to replace ">=3D 0" with = just "=3D=3D 0" > > in VMEXIT_NPF handler. finish_type_change() is also not affected by = the > > change as being able to deal with >0 return value of p2m->recalc = from > > EPT implementation. > > > > Reviewed-by: Roger Pau Monn=C3=A9 > > Signed-off-by: Igor Druzhinin >=20 > Reviewed-by: Jan Beulich > albeit preferably with ... >=20 > > @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, = unsigned long gfn) > > clear_recalc(l1, e); > > err =3D p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); > > ASSERT(!err); > > + > > + recalc_done =3D true; > > } > > > > out: > > unmap_domain_page(table); > > > > - return err; > > + return err ?: (recalc_done ? 1 : 0); >=20 > ... this shrunk to >=20 > return err ?: recalc_done; >=20 > (easily doable while committing). >=20 > Also Cc Paul. >=20 paging_log_dirty_enable() still fails global enable if has_arch_pdevs() = is true, so presumably there's no desperate need for this to go in 4.14? Paul > Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 03 10:31:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 10:31:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQgF-0003Do-Cz; Wed, 03 Jun 2020 10:31:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQgE-0003Dj-K1 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 10:31:30 +0000 X-Inumbo-ID: 619c62b0-a585-11ea-acd7-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 619c62b0-a585-11ea-acd7-12813bfff9fa; Wed, 03 Jun 2020 10:31:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591180287; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eplq3qDmNGcf1W708KD7q7ueZA7JgQRUtchbp+fE59Q=; b=Ib2MylZ4H4Yc7b9gjOf5OT4Z/oLNiiVp+JdOUdZkO9evXR0etpq0ymBAmQnmwIwI2v/Zhj thOD7+RPOs136QmXKWmxKfI5ySMb/zf3HojUkgzQDgz883p/xxrpQQNVQfjS8/uc4/jNKq KiCSR2EUoY8zTqi7BwMIAxLjww+s/qY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-215-Os11wg3GOE67oqNX6TQE1g-1; Wed, 03 Jun 2020 06:31:17 -0400 X-MC-Unique: Os11wg3GOE67oqNX6TQE1g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2CB5F1005510; Wed, 3 Jun 2020 10:31:16 +0000 (UTC) Received: from antique-laptop (unknown [10.40.194.48]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4098C5117E; Wed, 3 Jun 2020 10:31:12 +0000 (UTC) Date: Wed, 3 Jun 2020 12:31:09 +0200 From: Pavel Hrdina To: Ian Jackson Subject: Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update) Message-ID: <20200603103109.GA11390@antique-laptop> References: <20200602154745.15054-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 In-Reply-To: <20200602154745.15054-1-ian.jackson@eu.citrix.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: libvir-list@redhat.com, xen-devel@lists.xenproject.org, George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote: > Prior to 2621d48f005a "gnulib: delete all gnulib integration", > one could pass ./autogen.sh --no-git to prevent the libvirt build > system from running git submodule update. >=20 > This feature is needed by systems like the Xen Project CI which want > to explicitly control the revisions of every tree. These will > typically arrange to initialise the submodules check out the right > version of everything, and then expect the build system not to mess > with it any more. To be honest I don't understand why would anyone want to keep track of all submodules of all projects for any CI and update it manually every time the upstream project changes these submodules. Sounds like a lot of unnecessary work but maybe I'm missing something. > Despite to the old documentation comments referring only to gnulib, > the --no-git feature is required not only because of gnulib but also > because of the other submodule, src/keycodemapdb. >=20 > (And in any case, even if it were no longer required because all the > submodules were removed, it ought ideally to have been retained as a > no-op for compaibility reasons.) Well, we will break a lot more by switching to Meson build system where everyone building libvirt will have to change their scripts as it will not be compatible at all. Pavel > So restore the --no-git feature. >=20 > Because of the way the argument parsing of autogen.sh works, it is > easiest to recognise this option only if it comes first. This works > for the Xen Project CI, which has always passed this option first. >=20 > If something else is using this option (and hasn't introduced a > different workaround in the meantime), not in the first position, > then perhaps a more sophisticated approach will be needed. But I > think this will do for now. >=20 > Signed-off-by: Ian Jackson > --- > autogen.sh | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) >=20 > diff --git a/autogen.sh b/autogen.sh > index 4e1bbceb0a..1c98273452 100755 > --- a/autogen.sh > +++ b/autogen.sh > @@ -1,5 +1,10 @@ > #!/bin/sh > # Run this to generate all the initial makefiles, etc. > +# > +# THe following options must come first. All other or subsequent > +# arguments are passed to configure: > +# --no-git skip `git submodule update --init` > + > test -n "$srcdir" || srcdir=3D$(dirname "$0") > test -n "$srcdir" || srcdir=3D. > =20 > @@ -13,7 +18,11 @@ cd "$srcdir" > exit 1 > } > =20 > -git submodule update --init || exit 1 > +if [ "x$1" =3D x--no-git ]; then > +=09shift > +else > +=09git submodule update --init || exit 1 > +fi > =20 > autoreconf --verbose --force --install || exit 1 > =20 > --=20 > 2.11.0 >=20 --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEcbzs91ho/coWWY7aUi1kczAH4YwFAl7Xe+0ACgkQUi1kczAH 4Yw/eQ//VI3yZCI1HsDahzC2XRk1jJnfstDdfa9DtytOqHhS8QuTRg10y7NGBl1Q QbdOH/fmBnMUPKyl/eYZSFumu8q8CDjw6LvFpcjFad2poh16QF2y8qNbn8yr+mCp wvI2mqTgymvrBfP9MENZzkgJBNe9GFsESnPW7iuSzSfVlICoF9bWRTQZFVbR8PvD xRw3Mun8I7ocisqDQglsu5zyFpKlZP8IuvBQXvg10vxZE5tPojraLmPNhnigMQmh wdSBP0ENZiCJoBRdf7j2ZhHoOCnoyxiXlFzCHg48sZa8BUI2qiaWb6I2yU8lQEpF 4WUxM+T6Q/IfRUBXYzvDz/GI41WTHAu9qSGf8GSrHHTAXUHpqmndsAngdqRwTfhH T+sNpVSU1D87vnDJCD0X+J8JnBQ89SNf83pU3VvnrjwAHvuEmxqUmpTY2isjKJbd HCzduU3WoiZr9dB/VH9pIBlTbk4OwIHc8DB/k2Dwh8P9kRl5QU964/fTj/lYU715 Nvuw8MN2CibaVDu1F37JYJQYmi1NVJn+hxee3YLNbgDPMODTalbKg5XfDy9lOfGu luWY1Ucdy2sjVdVffkOrZMP9e5AvL9AM/8fDGGBWhfsydYFZPZuddzweLSTHYWIw gUeJ+XwUztir7/cZmia4b2UC+RJm8pHpxjUgwkBtUXCEj9zPgvU= =46Cx -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq-- From xen-devel-bounces@lists.xenproject.org Wed Jun 03 10:37:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 10:37:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQm3-0003P4-1s; Wed, 03 Jun 2020 10:37:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQm2-0003Oz-4H for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 10:37:30 +0000 X-Inumbo-ID: 37c91613-a586-11ea-acd8-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 37c91613-a586-11ea-acd8-12813bfff9fa; Wed, 03 Jun 2020 10:37:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591180647; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=VkqhYSS98jc06kx+9BWIV21Ktmm8jMwWjON+J/rxSC8=; b=HAdVywNyLHVP2z5YCamBFxusoBz5/6QS8hCprgIxucMzBuAbxsXqqKRn4U60s5z2Pprv5V 8dljF5pxl0lTw7h0qQeA3obk5/2IZt2lk5JdOsYoEtUGrzJauQG2pfbqiNZ+/bfJjj97G7 8FSc5zNWtxlKvJa3pNGsYer/hikXQH0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-344-r3Mbu2wOMXmbVxnWXY9FCg-1; Wed, 03 Jun 2020 06:37:16 -0400 X-MC-Unique: r3Mbu2wOMXmbVxnWXY9FCg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B4213835B46; Wed, 3 Jun 2020 10:37:15 +0000 (UTC) Received: from redhat.com (unknown [10.36.110.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6AC195117E; Wed, 3 Jun 2020 10:37:11 +0000 (UTC) Date: Wed, 3 Jun 2020 11:37:08 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Pavel Hrdina Subject: Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update) Message-ID: <20200603103708.GB2892653@redhat.com> References: <20200602154745.15054-1-ian.jackson@eu.citrix.com> <20200603103109.GA11390@antique-laptop> MIME-Version: 1.0 In-Reply-To: <20200603103109.GA11390@antique-laptop> User-Agent: Mutt/1.13.4 (2020-02-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: libvir-list@redhat.com, xen-devel@lists.xenproject.org, Ian Jackson , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 12:31:09PM +0200, Pavel Hrdina wrote: > On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote: > > Prior to 2621d48f005a "gnulib: delete all gnulib integration", > > one could pass ./autogen.sh --no-git to prevent the libvirt build > > system from running git submodule update. > > > > This feature is needed by systems like the Xen Project CI which want > > to explicitly control the revisions of every tree. These will > > typically arrange to initialise the submodules check out the right > > version of everything, and then expect the build system not to mess > > with it any more. > > To be honest I don't understand why would anyone want to keep track of > all submodules of all projects for any CI and update it manually every > time the upstream project changes these submodules. Sounds like a lot > of unnecessary work but maybe I'm missing something. Two possible scenarios that I think are valid - The CI job script does not have network access - The CI job script sees the source dir as read-only In both cases the CI harness would have to initialize the submodule before runing the CI job. I don't know if this is what Xen CI is hitting, but I think the request is reasonable none the less. Both Jenkins and GitLab CI have option to make the harness init submodules prior to the job running. > > Despite to the old documentation comments referring only to gnulib, > > the --no-git feature is required not only because of gnulib but also > > because of the other submodule, src/keycodemapdb. > > > > (And in any case, even if it were no longer required because all the > > submodules were removed, it ought ideally to have been retained as a > > no-op for compaibility reasons.) > > Well, we will break a lot more by switching to Meson build system where > everyone building libvirt will have to change their scripts as it will > not be compatible at all. Yes, but I think that's tangential, as the two above reasons will still apply, and Meson will cope with having submodules pre-initialized. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| From xen-devel-bounces@lists.xenproject.org Wed Jun 03 10:37:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 10:37:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQmI-0003RV-DS; Wed, 03 Jun 2020 10:37:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgQmG-0003RG-Pf for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 10:37:44 +0000 X-Inumbo-ID: 41c40ec4-a586-11ea-9dbe-bc764e2007e4 Received: from mail-wm1-x331.google.com (unknown [2a00:1450:4864:20::331]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 41c40ec4-a586-11ea-9dbe-bc764e2007e4; Wed, 03 Jun 2020 10:37:44 +0000 (UTC) Received: by mail-wm1-x331.google.com with SMTP id l26so1408938wme.3 for ; Wed, 03 Jun 2020 03:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=MLU5khfbr7JsqvosO9o/P4FiYWqNa4DvdOELnUFqTOE=; b=fq5yD9vPOzqXwmPUbjASn3g2y/dI5Z43yaS6K5HsqaW/jMeybE+JuZ3OXbzP21Nz0h ++CWpcR7owQrdIJ37yad+NNbl3S5zPpGKt3+2j9pVfcebs6PREY8jtejWv+K2z2Hhvls Q5uW1f1zTLFMDJmGPxAmka6EsKhXc+neRUnUX3EWp7yBqFluYQtNgAnf9ehnfSzdxxgc F6AbZHxT0anE06KTNXPQbbmA8qzjSONVJmB2keK+qwZb2SF/1d7M4K9kqF4pXX2nIxUW L2wfgtYYWwxF72hA5jdlV1xnY+/9S81RTXV9p3dfWdxBCICRLwgcXn4vqk3u96e/Xf/y rNEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=MLU5khfbr7JsqvosO9o/P4FiYWqNa4DvdOELnUFqTOE=; b=SbDYhmB6q6gFaEfEiLmv0zv6vmVluSMhIqwhiHcI3MsyuAuQwutfHNkidutWzob5tz UK5/dyoYQnsbccsONX6J8KSJtdIP3fu0EVl3guSOUwM76/2qYYtpSf9mI3IVxDeDplOJ 7Sbri9z6KWluZ1QYx5DP9rH0zEMnUMo/f7cjHe2Cez+gSGpx45A2R4Lk5G7BuTFY9Q5o gwSxRmmJxGaldblQM9jOsivBHPOEnb9+Tp0H6By4InxOq6/b6BOE8KxlwgnG59MIgKE/ Rshv4hVzOoChd4Mxd5V962argdS7tTGnmqzI0snrsHgCMFirt9N9L7XquvB1DbnmEAVs W8MQ== X-Gm-Message-State: AOAM531qo+J0SNHPP2rfDqMBvysEnFY8m7U2lXaF5cZ+iReTPkyQk0HJ er87Co0rGQqjthAMsXsuLJE= X-Google-Smtp-Source: ABdhPJzjL1a5ycQj8kmeVmMg8kvy3hEVZT7aNfil4y1xpKaz+MhTJ/pjSnWigSqNOsXopjT8TJaH/g== X-Received: by 2002:a1c:24c6:: with SMTP id k189mr8638556wmk.9.1591180663194; Wed, 03 Jun 2020 03:37:43 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id o6sm2717059wrp.3.2020.06.03.03.37.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2020 03:37:42 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Roger Pau Monne'" References: <20200528102648.8724-1-roger.pau@citrix.com> <24279.29302.517771.382439@mariner.uk.xensource.com> In-Reply-To: <24279.29302.517771.382439@mariner.uk.xensource.com> Subject: RE: [PATCH 0/2] osstest: update FreeBSD guest tests Date: Wed, 3 Jun 2020 11:37:41 +0100 Message-ID: <001901d63993$02f73720$08e5a560$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJmWAE7/fGO/u5K1e2UODFOX0tHRAM8LhApp4yRnBA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Paul Durrant' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 03 June 2020 10:51 > To: Roger Pau Monne > Cc: xen-devel@lists.xenproject.org; Paul Durrant > Subject: Re: [PATCH 0/2] osstest: update FreeBSD guest tests > > Roger Pau Monne writes ("[PATCH 0/2] osstest: update FreeBSD guest tests"): > > The following series adds FreeBSD 11 and 12 guests tests to osstest. > > ATM this is only tested on amd64, since the i386 versions had a bug. > > > > The result can be seen at: > > > > http://logs.test-lab.xenproject.org/osstest/logs/150428/ > > Thanks, Roger. > > I think that for this change I ought to get an ack from Paul as the > RM. > > Paul: how do you want to handle osstest changes during the freeze ? I > already pushed on Monday - without asking you - a series to fix a > problem with bisection which was stopping osstest from bisecting the > libvirt failure in the smoke tests. Please let me know if you think I > should have checked with you. > I'm no expert in osstest so I need to trust your judgement as to whether a patch is needed for 4.14 testing. That fix was clearly necessary to help diagnose the libvirt issue so I don't think you need check with me for such things. > I think we should take this change from Roger. Right now we are still > waiting for even the smoke tests from staging to pass. I don't > think this would interfere with that nor will it get in the way of the > osstest buster upgrade. We should certainly try to limit changes to only those where really are beneficial for 4.14 at this stage, but it looks like this series is adding more relevant testing (i.e. on newer OS) so I think it qualifies. Paul > > Thanks, > Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 11:22:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 11:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRTG-0008Iy-RT; Wed, 03 Jun 2020 11:22:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRTF-0008It-Ho for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 11:22:09 +0000 X-Inumbo-ID: 744d005c-a58c-11ea-ace1-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 744d005c-a58c-11ea-ace1-12813bfff9fa; Wed, 03 Jun 2020 11:22:05 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A790FAC91; Wed, 3 Jun 2020 11:22:07 +0000 (UTC) Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately To: paul@xen.org References: <1591116981-30162-1-git-send-email-igor.druzhinin@citrix.com> <37e6e543-564d-2625-b8d9-ccca6106efd2@suse.com> <000f01d63991$717b5e80$54721b80$@xen.org> From: Jan Beulich Message-ID: Date: Wed, 3 Jun 2020 13:22:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <000f01d63991$717b5e80$54721b80$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Igor Druzhinin' , wl@xen.org, andrew.cooper3@citrix.com, george.dunlap@citrix.com, xen-devel@lists.xenproject.org, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03.06.2020 12:26, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 03 June 2020 11:03 >> To: Igor Druzhinin >> Cc: xen-devel@lists.xenproject.org; andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; >> george.dunlap@citrix.com; Paul Durrant >> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately >> >> On 02.06.2020 18:56, Igor Druzhinin wrote: >>> A recalculation NPT fault doesn't always require additional handling >>> in hvm_hap_nested_page_fault(), moreover in general case if there is no >>> explicit handling done there - the fault is wrongly considered fatal. >>> >>> This covers a specific case of migration with vGPU assigned on AMD: >>> at a moment log-dirty is enabled globally, recalculation is requested >>> for the whole guest memory including directly mapped MMIO regions of vGPU >>> which causes a page fault being raised at the first access to those; >>> but due to MMIO P2M type not having any explicit handling in >>> hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled >>> SVM violation. >>> >>> Instead of trying to be opportunistic - use safer approach and handle >>> P2M recalculation in a separate NPT fault by attempting to retry after >>> making the necessary adjustments. This is aligned with Intel behavior >>> where there are separate VMEXITs for recalculation and EPT violations >>> (faults) and only faults are handled in hvm_hap_nested_page_fault(). >>> Do it by also unifying do_recalc return code with Intel implementation >>> where returning 1 means P2M was actually changed. >>> >>> Since there was no case previously where p2m_pt_handle_deferred_changes() >>> could return a positive value - it's safe to replace ">= 0" with just "== 0" >>> in VMEXIT_NPF handler. finish_type_change() is also not affected by the >>> change as being able to deal with >0 return value of p2m->recalc from >>> EPT implementation. >>> >>> Reviewed-by: Roger Pau Monné >>> Signed-off-by: Igor Druzhinin >> >> Reviewed-by: Jan Beulich >> albeit preferably with ... >> >>> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) >>> clear_recalc(l1, e); >>> err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); >>> ASSERT(!err); >>> + >>> + recalc_done = true; >>> } >>> >>> out: >>> unmap_domain_page(table); >>> >>> - return err; >>> + return err ?: (recalc_done ? 1 : 0); >> >> ... this shrunk to >> >> return err ?: recalc_done; >> >> (easily doable while committing). >> >> Also Cc Paul. >> > > paging_log_dirty_enable() still fails global enable if has_arch_pdevs() > is true, so presumably there's no desperate need for this to go in 4.14? The MMIO case is just the particular situation here. Aiui the same issue could potentially surface with other p2m types. Also given I'd consider this a backporting candidate, while it may not be desperately needed for the release, I think it deserves considering beyond the specific aspect you mention. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 03 11:28:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 11:28:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRZQ-0008Ud-Gt; Wed, 03 Jun 2020 11:28:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRZP-0008UY-Q1 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 11:28:31 +0000 X-Inumbo-ID: 599abc8a-a58d-11ea-81bc-bc764e2007e4 Received: from mail-ed1-x52b.google.com (unknown [2a00:1450:4864:20::52b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 599abc8a-a58d-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 11:28:30 +0000 (UTC) Received: by mail-ed1-x52b.google.com with SMTP id w7so1447973edt.1 for ; Wed, 03 Jun 2020 04:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=kgayONtgpl++/r/ziuQqKKOQ09tlFEGVK58WaG5UvPI=; b=p8ZAxBbIoOj4W5OiB8EQyNNX4z7nA9PpL9Mf+Vs8Ohd23JT9zJyHMrs1SEBgUqlyvz 0duEc4G2Rid84dqt5kzP8HiAqAXvk4Ct1Ip25othuhEvTQ9+wwvY7aYNhLqCKCGLY8QV UAlfJ9sGDX+INtQDL0FEmcyNPxpCW5UL4c7jgckP2wVtla1EUvXYZtJr2pSmpGOKhPjA keMq34laikkChpMvGD++cuSn+Cg1SmbxZC0KAKt02to/5z4JQ1/Qy2TuzuajBPqBROEm x0ZCIxitCwujcFvsY//l0b0LV5Q1QCJdgoIC3uFz0nKc1eRTbdd+htXXMjJgzITmb0xU WJdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=kgayONtgpl++/r/ziuQqKKOQ09tlFEGVK58WaG5UvPI=; b=GlSvgUR/EWUmNwOMExxMTFTuqch6AFTFKcOTtnz0Sc5wZIajxzoMaU83tg4XMiDuxE lvXn/3KxTDbilq2zhU1dVQD7La1UK388s9xF/xQ/Lah/8zXbNAxf+lehckgjXlZXd6IA Dy7ujqJsCD9SmzAutB+kGvCQSLh+ERhSZYrFPmsOwRPi1Dxtg85/eLSLBHcOfCqxT6xt jvh4MezfY7ft9IKAgzbbkvg7a8xG3pgEEJV/9/A6ReJc15RGoJj3IrNtigRzQmzG4wi7 N6SNwVJJFqyw7sDtob6GPzO0/yosLQuAFfqgCcsw/G5nw4LcymRksLcNx10s0VqdCf83 d14A== X-Gm-Message-State: AOAM532sKw7ocDBfYFUZVBOIeJIB/rZGzITLdz1d3MV9an3NLbxsRZrG 74cRP0Jd5gI3rglFWBqT17c= X-Google-Smtp-Source: ABdhPJz+X0NFQB3B6Cq7BopG/QKpUpBbhEosDWPtc/b7ZfuFTPQIMy4R0mvE//sgmN75YaYZbY2mkg== X-Received: by 2002:a50:d7d1:: with SMTP id m17mr31946110edj.126.1591183709642; Wed, 03 Jun 2020 04:28:29 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id 93sm1044740edy.49.2020.06.03.04.28.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2020 04:28:29 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <1591116981-30162-1-git-send-email-igor.druzhinin@citrix.com> <37e6e543-564d-2625-b8d9-ccca6106efd2@suse.com> <000f01d63991$717b5e80$54721b80$@xen.org> In-Reply-To: Subject: RE: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately Date: Wed, 3 Jun 2020 12:28:27 +0100 Message-ID: <001e01d6399a$1ac56820$50503860$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGQ4llbDaBtW772ehRPn2nRu43DNwHKaT0mAbXxiPcBOYrBC6krn8XA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Igor Druzhinin' , wl@xen.org, andrew.cooper3@citrix.com, george.dunlap@citrix.com, xen-devel@lists.xenproject.org, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 03 June 2020 12:22 > To: paul@xen.org > Cc: 'Igor Druzhinin' ; = xen-devel@lists.xenproject.org; > andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; = george.dunlap@citrix.com > Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT = faults immediately >=20 > On 03.06.2020 12:26, Paul Durrant wrote: > >> -----Original Message----- > >> From: Jan Beulich > >> Sent: 03 June 2020 11:03 > >> To: Igor Druzhinin > >> Cc: xen-devel@lists.xenproject.org; andrew.cooper3@citrix.com; = wl@xen.org; roger.pau@citrix.com; > >> george.dunlap@citrix.com; Paul Durrant > >> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT = faults immediately > >> > >> On 02.06.2020 18:56, Igor Druzhinin wrote: > >>> A recalculation NPT fault doesn't always require additional = handling > >>> in hvm_hap_nested_page_fault(), moreover in general case if there = is no > >>> explicit handling done there - the fault is wrongly considered = fatal. > >>> > >>> This covers a specific case of migration with vGPU assigned on = AMD: > >>> at a moment log-dirty is enabled globally, recalculation is = requested > >>> for the whole guest memory including directly mapped MMIO regions = of vGPU > >>> which causes a page fault being raised at the first access to = those; > >>> but due to MMIO P2M type not having any explicit handling in > >>> hvm_hap_nested_page_fault() a domain is erroneously crashed with = unhandled > >>> SVM violation. > >>> > >>> Instead of trying to be opportunistic - use safer approach and = handle > >>> P2M recalculation in a separate NPT fault by attempting to retry = after > >>> making the necessary adjustments. This is aligned with Intel = behavior > >>> where there are separate VMEXITs for recalculation and EPT = violations > >>> (faults) and only faults are handled in = hvm_hap_nested_page_fault(). > >>> Do it by also unifying do_recalc return code with Intel = implementation > >>> where returning 1 means P2M was actually changed. > >>> > >>> Since there was no case previously where = p2m_pt_handle_deferred_changes() > >>> could return a positive value - it's safe to replace ">=3D 0" with = just "=3D=3D 0" > >>> in VMEXIT_NPF handler. finish_type_change() is also not affected = by the > >>> change as being able to deal with >0 return value of p2m->recalc = from > >>> EPT implementation. > >>> > >>> Reviewed-by: Roger Pau Monn=C3=A9 > >>> Signed-off-by: Igor Druzhinin > >> > >> Reviewed-by: Jan Beulich > >> albeit preferably with ... > >> > >>> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, = unsigned long gfn) > >>> clear_recalc(l1, e); > >>> err =3D p2m->write_p2m_entry(p2m, gfn, pent, e, level + = 1); > >>> ASSERT(!err); > >>> + > >>> + recalc_done =3D true; > >>> } > >>> > >>> out: > >>> unmap_domain_page(table); > >>> > >>> - return err; > >>> + return err ?: (recalc_done ? 1 : 0); > >> > >> ... this shrunk to > >> > >> return err ?: recalc_done; > >> > >> (easily doable while committing). > >> > >> Also Cc Paul. > >> > > > > paging_log_dirty_enable() still fails global enable if = has_arch_pdevs() > > is true, so presumably there's no desperate need for this to go in = 4.14? >=20 > The MMIO case is just the particular situation here. Aiui the same = issue > could potentially surface with other p2m types. Also given I'd = consider > this a backporting candidate, while it may not be desperately needed = for > the release, I think it deserves considering beyond the specific = aspect > you mention. >=20 In which case I think the commit message probably ought to be rephrased, = since it appears to focus on a case that cannot currently happen. Paul From xen-devel-bounces@lists.xenproject.org Wed Jun 03 11:32:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 11:32:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRdc-00011Y-0d; Wed, 03 Jun 2020 11:32:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRda-00011T-UQ for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 11:32:50 +0000 X-Inumbo-ID: f4b7d446-a58d-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f4b7d446-a58d-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 11:32:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hrefAA9Jg4cRJk55r6WANYtsWiWZsDqnYSBXDaZiI+4=; b=5n7vyFDxYnxUgR/unYz6AjUAP2 6B4/LuVvWVBW/2C2whcJoPpekPEOs+uwWkgaZusn28F2hGPYkdZzK+/AWpMwsOv4HV9ZeuVxrlkmq PoLCYq5P2KiUJYoLWJHtS4JpS584zwYRNaGbOARohn/OqUWwtVBnk0Anz+umkQOF3D+c=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRdZ-0002kn-8x; Wed, 03 Jun 2020 11:32:49 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgRdZ-0008W5-2e; Wed, 03 Jun 2020 11:32:49 +0000 Subject: Re: Keystone Issue To: CodeWiz2280 References: From: Julien Grall Message-ID: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> Date: Wed, 3 Jun 2020 12:32:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" (+Bertrand and Stefano) On 01/06/2020 18:38, CodeWiz2280 wrote: > Hi Julien, Hi Dave, > > As requested please see log below from the eval board booting dom0, some > notes are as follows: Thanks for the logs and the notes. They are useful to understand your issue. > 1. The offset that gets applied to the 32-bit address to translate it > to 36-bits is 0x7_8000_0000 Is this offset present in the Device-Tree? > 2. Uboot has been setup to not change the address of the memory in the > device tree prior to launching xen, otherwise it would > automatically offset it and replace it with a 36-bit address and xen > would immediately panic at the 36-bit address for a 32-bit processor. What is the list of the memory banks Xen will see? Xen is able to support 36-bit address, can you point to the panic() you are hitting? > 3. The RAM starting address placed in the device tree is 0x8000_0000, > which gets carved up by xen and replaced with 0xA000_0000 prior to > booting dom0..  I had to put in test code to have the kernel offset the > 0xA000_0000 32-bit starting address to the 36-bit address needed before > the kernel will attempt to switch.  If it stays 32-bit then it will not > switch over the address space.  Note that without xen in play uboot > would normally replace the address in the device tree with the 36-bit one. IIUC, in the case of Linux boot directly, the Device-Tree will not describe the low memory range. Is that correct? > 4. The dom0 kernel will boot from xen if the early_paging_init switch > step is skipped, and the low mem stays in 32-bit....but there is a > problem with the peripherals so this is not an acceptable solution. Can you details a bit more the problem with the peripherals? > > It seems that either the kernel would need some API to tell xen that > there is going to be a change in the memory its using prior to call > early_paging_init(), From my understanding, the problem is very specific to the KeyStone. So I would rather avoid to introduce an hypercall specific to your platform. But... > or Xen would need to add the additional 36-bit > addresses during the memory bank allocation step....but recognize that > they are not actually different physical memory but just aliased to a > different address. ... I think it is possible to fix it entirely in Xen without any modification in the device-tree. It is seems better that Xen treats the low memory region as "not usable" and only use the high memory region internally. When allocating a Dom0 memory banks, it would need to ensure that there is a corresponding alias in low memory. Xen will also need to do two mappings in the Dom0 stage-2 page-tables. The extra one is for the alias. This approach will prevent to use hypercall buffer from low memory and therefore require your guest to support LPAE. Is it going to be an issue for you? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 03 11:34:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 11:34:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRfI-0001AI-Fi; Wed, 03 Jun 2020 11:34:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRfG-0001AD-SA for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 11:34:35 +0000 X-Inumbo-ID: 3179963a-a58e-11ea-ace8-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 3179963a-a58e-11ea-ace8-12813bfff9fa; Wed, 03 Jun 2020 11:34:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591184072; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jbak0LTaAnQiiMFNvn9Gt/Y2OHMAg9Z1OTjz5g3/Lb8=; b=U0gB0G6A4jI9OAogEgZF9zROw4s0dsmsGsOQYE5+73fJ+TF3ljCYjhBjIzFUVB48TjA+ED LZ0MrER/ng8TvywB6Ns5l90nCQKB6avkK9UJnSlxgILWpLTU05XpwdjA64XcU2+/eypJyz UEyyZ2gpbHyKjiKR7QvC0c71KiECIEE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-62-Bepr0SE1PoO1ikwAqzQbEA-1; Wed, 03 Jun 2020 07:34:26 -0400 X-MC-Unique: Bepr0SE1PoO1ikwAqzQbEA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4EF7C107ACCD; Wed, 3 Jun 2020 11:34:25 +0000 (UTC) Received: from antique-laptop (unknown [10.40.194.48]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 38B7F7E7F1; Wed, 3 Jun 2020 11:34:21 +0000 (UTC) Date: Wed, 3 Jun 2020 13:34:18 +0200 From: Pavel Hrdina To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Subject: Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update) Message-ID: <20200603113418.GB11390@antique-laptop> References: <20200602154745.15054-1-ian.jackson@eu.citrix.com> <20200603103109.GA11390@antique-laptop> <20200603103708.GB2892653@redhat.com> MIME-Version: 1.0 In-Reply-To: <20200603103708.GB2892653@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uZ3hkaAS1mZxFaxD" Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: libvir-list@redhat.com, xen-devel@lists.xenproject.org, Ian Jackson , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 03, 2020 at 11:37:08AM +0100, Daniel P. Berrang=C3=A9 wrote: > On Wed, Jun 03, 2020 at 12:31:09PM +0200, Pavel Hrdina wrote: > > On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote: > > > Prior to 2621d48f005a "gnulib: delete all gnulib integration", > > > one could pass ./autogen.sh --no-git to prevent the libvirt build > > > system from running git submodule update. > > >=20 > > > This feature is needed by systems like the Xen Project CI which want > > > to explicitly control the revisions of every tree. These will > > > typically arrange to initialise the submodules check out the right > > > version of everything, and then expect the build system not to mess > > > with it any more. > >=20 > > To be honest I don't understand why would anyone want to keep track of > > all submodules of all projects for any CI and update it manually every > > time the upstream project changes these submodules. Sounds like a lot > > of unnecessary work but maybe I'm missing something. >=20 > Two possible scenarios that I think are valid >=20 > - The CI job script does not have network access > - The CI job script sees the source dir as read-only >=20 > In both cases the CI harness would have to initialize the submodule > before runing the CI job. >=20 > I don't know if this is what Xen CI is hitting, but I think the > request is reasonable none the less. >=20 > Both Jenkins and GitLab CI have option to make the harness init > submodules prior to the job running. My point was that running 'git submodule update --init' will not change anything if all submodules are updated to the correct revision and if the repository was pre-created with submodules and is read-only when the test is executed the git command will not fail as well and everything will be fine. If the submodules are not updated to the correct revision then it will fail and notify the CI users that something is broken. There should not be any need to disable this explicitly unless you want to build libvirt with different revisions of submodules. > > > Despite to the old documentation comments referring only to gnulib, > > > the --no-git feature is required not only because of gnulib but also > > > because of the other submodule, src/keycodemapdb. > > >=20 > > > (And in any case, even if it were no longer required because all the > > > submodules were removed, it ought ideally to have been retained as a > > > no-op for compaibility reasons.) > >=20 > > Well, we will break a lot more by switching to Meson build system where > > everyone building libvirt will have to change their scripts as it will > > not be compatible at all. >=20 > Yes, but I think that's tangential, as the two above reasons will > still apply, and Meson will cope with having submodules pre-initialized. Yes, these are unrelated and I just wanted to point out that compaibility reasons are in most cases not valid to changes to build system or moving files around in git repository and so on. Pavel --uZ3hkaAS1mZxFaxD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEcbzs91ho/coWWY7aUi1kczAH4YwFAl7XiroACgkQUi1kczAH 4Yy+UxAAqbVqkN2Cc0PyW3DI637tUGNiPTgO4rdD4D9sL4IVgRVGBDQvJxk8+qv/ ifbVs139Amrn5ELB2comrvsWFF5PVjbbQMYH0DnuIz3AHGvjKb7uUzcmx0HgWLbE uhMqPkD1ClzzeNJXd73eFcSJPn72UZP1Opsm6KZOhIb1KXA1BDC4v5V96GvY0N69 W9j2L+uuMiiWtBJWBCsTBKxd1Eokq38djuoaaHzup87+jCwkmGEnNqLTdVIYqSPt D9WffH/9RA5KT92PPccpNfl8CuOn0lGf2H6JY+F7Q8PonC9vVNWlS2mB+NymErLf Hihs216IiGs4I58TJ2hkEpj8rfxIa4ygUg6DgUBgsnS+HICcr6xehyYchgfv6nhC rhn0flQDa39ib/jKscRagkL6Wkbb872EDGDn85LaLz3kzOVmrBn6CmjaKXTlfJkJ HqnJ/OpEySQUt2SjPBdalLkAebjr8CF1jCogkd8XzyTFpTSdOr+l164jBBMXdZy+ RGN3wskVv0bk6q9RZik3rE3Ivdc8WMABX4gvJN2I9ZwXwjSpjkMBWMWV1WYi1XaV CoVFKzWY/LaVcQU+f2jLOXVxe6rIW+qxaYhA2J50E2zl2gM7Xu0EFP+KEenH2sw7 Kx60uvc7aAK0XZdQ5W3IOKlsr2HzzaYtvew26EQPCqv/1kDjDys= =TnYM -----END PGP SIGNATURE----- --uZ3hkaAS1mZxFaxD-- From xen-devel-bounces@lists.xenproject.org Wed Jun 03 11:44:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 11:44:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRp2-0002Fd-K2; Wed, 03 Jun 2020 11:44:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRp1-0002FX-5I for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 11:44:39 +0000 X-Inumbo-ID: 9a4a56d0-a58f-11ea-8993-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9a4a56d0-a58f-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 11:44:38 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: IZTmpl3bIBHHpNBltS3GaBREVzm7EROitnIadLmDc9/nwLtsOAhbbcXCXJRHkYx+zMRfdgBwqz NY5bnZ+L04Ha7xEenfUNCbQwBC0yNVuRTXdgqDRIqtdm0dHIMDqszkFpGVXKWS1yLaOw1znWd0 M3I3HKVW8c1eObfptRBINhiDrN7Sp9X6aXqD9/2cTLHPhYV5KvQUQeef5UFz37v2AH9uqS2T9q ccEyMexJbE1mAn9OLZJHb9FW5Uta8Jjj8ywG0U+xzfv9F1eILGY2LRWlc1F8kAOLrW7iCPsRcJ mo8= X-SBRS: 2.7 X-MesageID: 19856069 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19856069" Subject: Re: Re [PATCH] x86/CET: Fix build following c/s 43b98e7190 To: Jan Beulich References: <1eeb47f4-b9b9-c4d8-a5c9-58d78f0e0aeb@suse.com> From: Andrew Cooper Message-ID: <1c507672-bc8e-bc7e-df45-a652fb4c21f2@citrix.com> Date: Wed, 3 Jun 2020 12:44:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03/06/2020 10:50, Jan Beulich wrote: > On 02.06.2020 19:15, Andrew Cooper wrote: >> On 02/06/2020 15:21, Jan Beulich wrote: >>>> OSSTest reports: >>>> >>>> x86_64.S: Assembler messages: >>>> x86_64.S:57: Error: no such instruction: `setssbsy' >>>> /home/osstest/build.150510.build-amd64/xen/xen/Rules.mk:183: recipe for target 'head.o' failed >>>> make[4]: Leaving directory '/home/osstest/build.150510.build-amd64/xen/xen/arch/x86/boot' >>>> make[4]: *** [head.o] Error 1 >>>> >>>> All use of CET instructions, even those inside alternative blocks, needs to be >>>> behind CONFIG_XEN_SHSTK, as it indicates suitable toolchain support. >>>> >>>> Signed-off-by: Andrew Cooper >>> That's quite a bit of #ifdef-ary here. Simple (operand-less) insns >>> like SETSSBSY could easily be made available via .byte directives. >>> Would you be amenable to to ack-ing a patch to replace some of the >>> #ifdef-s (at least the ones at the lstar, cstar, and sysenter >>> entry points), after 4.14? >> Yeah - that was a bit of a mess in the end.  (But given the >> circumstances, and that I've got past form typo'ing the SETSSBSY opcode, >> it probably was the right move even in hindsight). >> >> Reducing it to .byte should be fine so long as some form of /* setssbsy >> */ comment appears. > Sure. > >> One other option would be to introduce a SETSSBSY macro, but that hides >> the alternative so is something I'd prefer to avoid. > With this you mean you'd rather not see us go the CLAC/STAC route? > I was instead thinking of a pure assembly macro named "setssbsy". > In fact we could switch the CLAC/STAC ugliness to some such, if we > end up being happy with the model. The thing about the current STAC / CLAC is that, as written, they give the impression of being unconditional.  This is poor in terms of code clarity. Furthermore, making them indistinguishable from the plain instructions is definitely a no-go, because then we've got assembly source (again, which appears unconditional) which doesn't match its disassembly (the backing nops) - at least with the macros in upper case, it is obvious that something is up, even if you have to searching for why. If we went for pure assembly macros with an alt_ or maybe_ prefix, then that would be reasonable.  It looks as close to regular instruction as possible, but also makes it explicitly clear that it is conditional. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 03 11:45:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 11:45:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRpt-0002JV-Um; Wed, 03 Jun 2020 11:45:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRpt-0002Ij-Ek for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 11:45:33 +0000 X-Inumbo-ID: bace524e-a58f-11ea-acf0-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bace524e-a58f-11ea-acf0-12813bfff9fa; Wed, 03 Jun 2020 11:45:32 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: T1wGLoubHyylm5a0q8mo2I0DXdp536zzAPMoUI0aj5YpdoDYFwW9wj0bNoNs8AEUhx/NCYXZRG /Fb6K2MgoYL0h375Nq7pPur5+Mv/Vdsm97NkA8FocLPIQh9K9f2ebDwZrdWC8ub9W8Yb168Pqo Edjz24ghYqyrjZQWUeFEX+Rvmb8EAr7Z690+O9nLWFqV8HLFQhxvOagwsAq0yfGlW8l4gSN2wQ migTWuQY5UwNR6f1D2em7rh7b6/GGzqKkYdlvM9KrRZ2PGk/yp7wRGr0kXh0mR2Ngeu5YK5ovD JA8= X-SBRS: 2.7 X-MesageID: 19106376 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19106376" Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately To: , 'Jan Beulich' References: <1591116981-30162-1-git-send-email-igor.druzhinin@citrix.com> <37e6e543-564d-2625-b8d9-ccca6106efd2@suse.com> <000f01d63991$717b5e80$54721b80$@xen.org> <001e01d6399a$1ac56820$50503860$@xen.org> From: Igor Druzhinin Message-ID: Date: Wed, 3 Jun 2020 12:45:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <001e01d6399a$1ac56820$50503860$@xen.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com, george.dunlap@citrix.com, wl@xen.org, andrew.cooper3@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03/06/2020 12:28, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 03 June 2020 12:22 >> To: paul@xen.org >> Cc: 'Igor Druzhinin' ; xen-devel@lists.xenproject.org; >> andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; george.dunlap@citrix.com >> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately >> >> On 03.06.2020 12:26, Paul Durrant wrote: >>>> -----Original Message----- >>>> From: Jan Beulich >>>> Sent: 03 June 2020 11:03 >>>> To: Igor Druzhinin >>>> Cc: xen-devel@lists.xenproject.org; andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; >>>> george.dunlap@citrix.com; Paul Durrant >>>> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately >>>> >>>> On 02.06.2020 18:56, Igor Druzhinin wrote: >>>>> A recalculation NPT fault doesn't always require additional handling >>>>> in hvm_hap_nested_page_fault(), moreover in general case if there is no >>>>> explicit handling done there - the fault is wrongly considered fatal. >>>>> >>>>> This covers a specific case of migration with vGPU assigned on AMD: >>>>> at a moment log-dirty is enabled globally, recalculation is requested >>>>> for the whole guest memory including directly mapped MMIO regions of vGPU >>>>> which causes a page fault being raised at the first access to those; >>>>> but due to MMIO P2M type not having any explicit handling in >>>>> hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled >>>>> SVM violation. >>>>> >>>>> Instead of trying to be opportunistic - use safer approach and handle >>>>> P2M recalculation in a separate NPT fault by attempting to retry after >>>>> making the necessary adjustments. This is aligned with Intel behavior >>>>> where there are separate VMEXITs for recalculation and EPT violations >>>>> (faults) and only faults are handled in hvm_hap_nested_page_fault(). >>>>> Do it by also unifying do_recalc return code with Intel implementation >>>>> where returning 1 means P2M was actually changed. >>>>> >>>>> Since there was no case previously where p2m_pt_handle_deferred_changes() >>>>> could return a positive value - it's safe to replace ">= 0" with just "== 0" >>>>> in VMEXIT_NPF handler. finish_type_change() is also not affected by the >>>>> change as being able to deal with >0 return value of p2m->recalc from >>>>> EPT implementation. >>>>> >>>>> Reviewed-by: Roger Pau Monné >>>>> Signed-off-by: Igor Druzhinin >>>> >>>> Reviewed-by: Jan Beulich >>>> albeit preferably with ... >>>> >>>>> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) >>>>> clear_recalc(l1, e); >>>>> err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); >>>>> ASSERT(!err); >>>>> + >>>>> + recalc_done = true; >>>>> } >>>>> >>>>> out: >>>>> unmap_domain_page(table); >>>>> >>>>> - return err; >>>>> + return err ?: (recalc_done ? 1 : 0); >>>> >>>> ... this shrunk to >>>> >>>> return err ?: recalc_done; >>>> >>>> (easily doable while committing). >>>> >>>> Also Cc Paul. >>>> >>> >>> paging_log_dirty_enable() still fails global enable if has_arch_pdevs() >>> is true, so presumably there's no desperate need for this to go in 4.14? >> >> The MMIO case is just the particular situation here. Aiui the same issue >> could potentially surface with other p2m types. Also given I'd consider >> this a backporting candidate, while it may not be desperately needed for >> the release, I think it deserves considering beyond the specific aspect >> you mention. >> > > In which case I think the commit message probably ought to be rephrased, since it appears to focus on a case that cannot currently happen. This can happen without has_arch_pdevs() being true. It's enough to just directly map some physical memory into a guest to get p2m_direct_mmio type present in the page tables. Igor From xen-devel-bounces@lists.xenproject.org Wed Jun 03 11:48:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 11:48:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRsx-0002Uq-DB; Wed, 03 Jun 2020 11:48:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgRsv-0002Ue-RR for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 11:48:41 +0000 X-Inumbo-ID: 2b16b226-a590-11ea-9dbe-bc764e2007e4 Received: from mail-wr1-x42c.google.com (unknown [2a00:1450:4864:20::42c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2b16b226-a590-11ea-9dbe-bc764e2007e4; Wed, 03 Jun 2020 11:48:41 +0000 (UTC) Received: by mail-wr1-x42c.google.com with SMTP id x14so2042006wrp.2 for ; Wed, 03 Jun 2020 04:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=wxlEp7b8EAjlLU05U12sz2OC14B8X0NELJbXvi3+0HU=; b=Udtt7A10MsR+gT9+OIPvbjd7g+iHgOyhWwYi7wkhvzmFY/J50WrH/n5u4DLTqhklbB Glt00yvO9mY4XNDRNJhjn22qqZd0oE4Rh9N0zN1VmjbYx2pwL1iaHXuRTnwEjzJ12ZKr Ei+x5Qn+S2dsYkwc/3jZShlsvXMqaDRmlsuD996q/SuIdYKcB9tR7XCW3hjclqcgsrM7 b3aqNylrDXR9zQvXkIRhDg0T3rhz3KWZ0vZXG2Hie6jilRnQfxZFuw7xuKdJH/j5VssM Dpx6WiRXDT6jVjHfb9TXRL2j42HxWOMfOSSUNnZedVJ1NxBp9iXi3qIgne5hoga2VbG7 QC5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=wxlEp7b8EAjlLU05U12sz2OC14B8X0NELJbXvi3+0HU=; b=ieutdAWoMJNP3x+ItQin9Y/vIasQDM571VtFY7eILAcVDM1Za1t/EaSBs/7YTrM4Va 5jo1kWKe9LIcrwOo2+GucALJRzSS+BwUfWaxtAos3pTaZiEiK1P7rg+yzKwqB4rQsCVD PdK9ImDZdqqU/xW5dFFuVLP9wKa3dfn9hjOjr6lBAXGVzr+auTGVL9oXWDxukRFUDSN/ tB2V8qgIOMWmGN/yCOSkPKnJkqSvhveZanwa0xOYKWuigeQwI4v83c+IeS2GVd65yfzp WQIULYhD1F0STcknfjABmGDNDHoA8gf6sXJU1nzjFYEoE0nUyCFOiob6SRMqPpIYsx6x my1Q== X-Gm-Message-State: AOAM530lLk66qirtmS5InHA4IGMKW9TOjfyuXCCYm2/FIPMmtJoa+Nsi 7L1xKojW0XBaEZegLHcrJj8= X-Google-Smtp-Source: ABdhPJy/q07+vd7ladIVpOFjlOjN88C6Y++gEMTK7K8wvunjn+WC6Q8/17UxdiVkfTtzAG1noWWazQ== X-Received: by 2002:adf:97cb:: with SMTP id t11mr20758570wrb.314.1591184920029; Wed, 03 Jun 2020 04:48:40 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id q5sm3033250wrm.62.2020.06.03.04.48.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2020 04:48:39 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Igor Druzhinin'" , "'Jan Beulich'" References: <1591116981-30162-1-git-send-email-igor.druzhinin@citrix.com> <37e6e543-564d-2625-b8d9-ccca6106efd2@suse.com> <000f01d63991$717b5e80$54721b80$@xen.org> <001e01d6399a$1ac56820$50503860$@xen.org> In-Reply-To: Subject: RE: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately Date: Wed, 3 Jun 2020 12:48:37 +0100 Message-ID: <002d01d6399c$ec115a90$c4340fb0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGQ4llbDaBtW772ehRPn2nRu43DNwHKaT0mAbXxiPcBOYrBCwMrk2dKAi+np2+pAMulwA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com, george.dunlap@citrix.com, wl@xen.org, andrew.cooper3@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Igor Druzhinin > Sent: 03 June 2020 12:45 > To: paul@xen.org; 'Jan Beulich' > Cc: xen-devel@lists.xenproject.org; andrew.cooper3@citrix.com; = wl@xen.org; roger.pau@citrix.com; > george.dunlap@citrix.com > Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT = faults immediately >=20 > On 03/06/2020 12:28, Paul Durrant wrote: > >> -----Original Message----- > >> From: Jan Beulich > >> Sent: 03 June 2020 12:22 > >> To: paul@xen.org > >> Cc: 'Igor Druzhinin' ; = xen-devel@lists.xenproject.org; > >> andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; = george.dunlap@citrix.com > >> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT = faults immediately > >> > >> On 03.06.2020 12:26, Paul Durrant wrote: > >>>> -----Original Message----- > >>>> From: Jan Beulich > >>>> Sent: 03 June 2020 11:03 > >>>> To: Igor Druzhinin > >>>> Cc: xen-devel@lists.xenproject.org; andrew.cooper3@citrix.com; = wl@xen.org; roger.pau@citrix.com; > >>>> george.dunlap@citrix.com; Paul Durrant > >>>> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT = faults immediately > >>>> > >>>> On 02.06.2020 18:56, Igor Druzhinin wrote: > >>>>> A recalculation NPT fault doesn't always require additional = handling > >>>>> in hvm_hap_nested_page_fault(), moreover in general case if = there is no > >>>>> explicit handling done there - the fault is wrongly considered = fatal. > >>>>> > >>>>> This covers a specific case of migration with vGPU assigned on = AMD: > >>>>> at a moment log-dirty is enabled globally, recalculation is = requested > >>>>> for the whole guest memory including directly mapped MMIO = regions of vGPU > >>>>> which causes a page fault being raised at the first access to = those; > >>>>> but due to MMIO P2M type not having any explicit handling in > >>>>> hvm_hap_nested_page_fault() a domain is erroneously crashed with = unhandled > >>>>> SVM violation. > >>>>> > >>>>> Instead of trying to be opportunistic - use safer approach and = handle > >>>>> P2M recalculation in a separate NPT fault by attempting to retry = after > >>>>> making the necessary adjustments. This is aligned with Intel = behavior > >>>>> where there are separate VMEXITs for recalculation and EPT = violations > >>>>> (faults) and only faults are handled in = hvm_hap_nested_page_fault(). > >>>>> Do it by also unifying do_recalc return code with Intel = implementation > >>>>> where returning 1 means P2M was actually changed. > >>>>> > >>>>> Since there was no case previously where = p2m_pt_handle_deferred_changes() > >>>>> could return a positive value - it's safe to replace ">=3D 0" = with just "=3D=3D 0" > >>>>> in VMEXIT_NPF handler. finish_type_change() is also not affected = by the > >>>>> change as being able to deal with >0 return value of p2m->recalc = from > >>>>> EPT implementation. > >>>>> > >>>>> Reviewed-by: Roger Pau Monn=C3=A9 > >>>>> Signed-off-by: Igor Druzhinin > >>>> > >>>> Reviewed-by: Jan Beulich > >>>> albeit preferably with ... > >>>> > >>>>> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain = *p2m, unsigned long gfn) > >>>>> clear_recalc(l1, e); > >>>>> err =3D p2m->write_p2m_entry(p2m, gfn, pent, e, level + = 1); > >>>>> ASSERT(!err); > >>>>> + > >>>>> + recalc_done =3D true; > >>>>> } > >>>>> > >>>>> out: > >>>>> unmap_domain_page(table); > >>>>> > >>>>> - return err; > >>>>> + return err ?: (recalc_done ? 1 : 0); > >>>> > >>>> ... this shrunk to > >>>> > >>>> return err ?: recalc_done; > >>>> > >>>> (easily doable while committing). > >>>> > >>>> Also Cc Paul. > >>>> > >>> > >>> paging_log_dirty_enable() still fails global enable if = has_arch_pdevs() > >>> is true, so presumably there's no desperate need for this to go in = 4.14? > >> > >> The MMIO case is just the particular situation here. Aiui the same = issue > >> could potentially surface with other p2m types. Also given I'd = consider > >> this a backporting candidate, while it may not be desperately = needed for > >> the release, I think it deserves considering beyond the specific = aspect > >> you mention. > >> > > > > In which case I think the commit message probably ought to be = rephrased, since it appears to focus > on a case that cannot currently happen. >=20 > This can happen without has_arch_pdevs() being true. It's enough to = just > directly map some physical memory into a guest to get p2m_direct_mmio > type present in the page tables. OK, that's fine, but when will that happen without pass-through? If we = can have a commit message justifying the change based on what can = actually happen now, then I would not be opposed to it going in 4.14. Paul >=20 > Igor From xen-devel-bounces@lists.xenproject.org Wed Jun 03 12:10:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 12:10:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSE0-0005Fp-Hc; Wed, 03 Jun 2020 12:10:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSDz-0005Fk-2Z for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 12:10:27 +0000 X-Inumbo-ID: 348c31fc-a593-11ea-9dbe-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 348c31fc-a593-11ea-9dbe-bc764e2007e4; Wed, 03 Jun 2020 12:10:25 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: al/iUDHjbqCLo0Dbfa69Rh48/RKETZ0BT/JrPri5Aah68Cb0hOBUwW7v/mlj7AaU7J6ROesNhG FhRnZCy4HfY0XLOXrc4CMvDa1cnKUzhT4T1gDG9Bh/LR8MOCP/5LqgSdJ6DW7zN8clTSB/87eD fXVb80bAvG9cA0yHgRjvNyqbDAyHhxQTJtYcKQXyda10M+YuSWG80qF5VXIzGHY67+x4tXxgH1 5TpERorVuNPt+9TIE8RZySL833osFWs4AZdxb5llAqAL6mNxHD9kRjdHOMgLS8VMUhAtUCB6nY x6I= X-SBRS: 2.7 X-MesageID: 19461645 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19461645" Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately To: , 'Jan Beulich' References: <1591116981-30162-1-git-send-email-igor.druzhinin@citrix.com> <37e6e543-564d-2625-b8d9-ccca6106efd2@suse.com> <000f01d63991$717b5e80$54721b80$@xen.org> <001e01d6399a$1ac56820$50503860$@xen.org> <002d01d6399c$ec115a90$c4340fb0$@xen.org> From: Igor Druzhinin Message-ID: Date: Wed, 3 Jun 2020 13:10:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <002d01d6399c$ec115a90$c4340fb0$@xen.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com, george.dunlap@citrix.com, wl@xen.org, andrew.cooper3@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03/06/2020 12:48, Paul Durrant wrote: >> -----Original Message----- >> From: Igor Druzhinin >> Sent: 03 June 2020 12:45 >> To: paul@xen.org; 'Jan Beulich' >> Cc: xen-devel@lists.xenproject.org; andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; >> george.dunlap@citrix.com >> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately >> >> On 03/06/2020 12:28, Paul Durrant wrote: >>>> -----Original Message----- >>>> From: Jan Beulich >>>> Sent: 03 June 2020 12:22 >>>> To: paul@xen.org >>>> Cc: 'Igor Druzhinin' ; xen-devel@lists.xenproject.org; >>>> andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; george.dunlap@citrix.com >>>> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately >>>> >>>> On 03.06.2020 12:26, Paul Durrant wrote: >>>>>> -----Original Message----- >>>>>> From: Jan Beulich >>>>>> Sent: 03 June 2020 11:03 >>>>>> To: Igor Druzhinin >>>>>> Cc: xen-devel@lists.xenproject.org; andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; >>>>>> george.dunlap@citrix.com; Paul Durrant >>>>>> Subject: Re: [PATCH v2] x86/svm: do not try to handle recalc NPT faults immediately >>>>>> >>>>>> On 02.06.2020 18:56, Igor Druzhinin wrote: >>>>>>> A recalculation NPT fault doesn't always require additional handling >>>>>>> in hvm_hap_nested_page_fault(), moreover in general case if there is no >>>>>>> explicit handling done there - the fault is wrongly considered fatal. >>>>>>> >>>>>>> This covers a specific case of migration with vGPU assigned on AMD: >>>>>>> at a moment log-dirty is enabled globally, recalculation is requested >>>>>>> for the whole guest memory including directly mapped MMIO regions of vGPU >>>>>>> which causes a page fault being raised at the first access to those; >>>>>>> but due to MMIO P2M type not having any explicit handling in >>>>>>> hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled >>>>>>> SVM violation. >>>>>>> >>>>>>> Instead of trying to be opportunistic - use safer approach and handle >>>>>>> P2M recalculation in a separate NPT fault by attempting to retry after >>>>>>> making the necessary adjustments. This is aligned with Intel behavior >>>>>>> where there are separate VMEXITs for recalculation and EPT violations >>>>>>> (faults) and only faults are handled in hvm_hap_nested_page_fault(). >>>>>>> Do it by also unifying do_recalc return code with Intel implementation >>>>>>> where returning 1 means P2M was actually changed. >>>>>>> >>>>>>> Since there was no case previously where p2m_pt_handle_deferred_changes() >>>>>>> could return a positive value - it's safe to replace ">= 0" with just "== 0" >>>>>>> in VMEXIT_NPF handler. finish_type_change() is also not affected by the >>>>>>> change as being able to deal with >0 return value of p2m->recalc from >>>>>>> EPT implementation. >>>>>>> >>>>>>> Reviewed-by: Roger Pau Monné >>>>>>> Signed-off-by: Igor Druzhinin >>>>>> >>>>>> Reviewed-by: Jan Beulich >>>>>> albeit preferably with ... >>>>>> >>>>>>> @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) >>>>>>> clear_recalc(l1, e); >>>>>>> err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); >>>>>>> ASSERT(!err); >>>>>>> + >>>>>>> + recalc_done = true; >>>>>>> } >>>>>>> >>>>>>> out: >>>>>>> unmap_domain_page(table); >>>>>>> >>>>>>> - return err; >>>>>>> + return err ?: (recalc_done ? 1 : 0); >>>>>> >>>>>> ... this shrunk to >>>>>> >>>>>> return err ?: recalc_done; >>>>>> >>>>>> (easily doable while committing). >>>>>> >>>>>> Also Cc Paul. >>>>>> >>>>> >>>>> paging_log_dirty_enable() still fails global enable if has_arch_pdevs() >>>>> is true, so presumably there's no desperate need for this to go in 4.14? >>>> >>>> The MMIO case is just the particular situation here. Aiui the same issue >>>> could potentially surface with other p2m types. Also given I'd consider >>>> this a backporting candidate, while it may not be desperately needed for >>>> the release, I think it deserves considering beyond the specific aspect >>>> you mention. >>>> >>> >>> In which case I think the commit message probably ought to be rephrased, since it appears to focus >> on a case that cannot currently happen. >> >> This can happen without has_arch_pdevs() being true. It's enough to just >> directly map some physical memory into a guest to get p2m_direct_mmio >> type present in the page tables. > > OK, that's fine, but when will that happen without pass-through? If we can have a commit message justifying the change based on what can actually happen now, then I would not be opposed to it going in 4.14. Yes, it can happen now - we had regular (not SR-IOV) vGPU migration totally broken because of this on AMD - never got tested before at all. You don't need special patches on top of Xen or anything. To get p2m_mmio_direct you just need to call XEN_DOMCTL_memory_mapping on a domain. All Igor From xen-devel-bounces@lists.xenproject.org Wed Jun 03 12:26:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 12:26:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSSs-0006kx-8Q; Wed, 03 Jun 2020 12:25:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSSr-0006kn-D8 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 12:25:49 +0000 X-Inumbo-ID: 5a809464-a595-11ea-acfa-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5a809464-a595-11ea-acfa-12813bfff9fa; Wed, 03 Jun 2020 12:25:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Yme0DZFnFPgs1zkIGQJxbk7qEBBJ7cyoW/vrSMLcZz0=; b=2b/lqFlkvhlgfkjFuREUUwWkO K+69YSRCtNcHigwNBEBgNfPpGeC37h8pDPvfwUvagtE/8KN7XN/ARhJiRf1PqPT34g19jBnoq/ZUA G1C8Rl5HKubKK5p4geh/I9rRDvOltkksVAJ0mKJhY0fM+0Tg7aXQ1pDB40WFZyp9WS+5I=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSSo-0003pu-Vh; Wed, 03 Jun 2020 12:25:47 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgSSo-0000Q1-NC; Wed, 03 Jun 2020 12:25:46 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgSSo-00051p-KI; Wed, 03 Jun 2020 12:25:46 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150635: tolerable FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Wed, 03 Jun 2020 12:25:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150635 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150635/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150609 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150609 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150609 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150609 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150609 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150609 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150609 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150609 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150609 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150609 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150609 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150635 2020-06-03 01:52:00 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 12:26:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 12:26:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSTF-0006nj-HY; Wed, 03 Jun 2020 12:26:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSTE-0006nV-AW for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 12:26:12 +0000 X-Inumbo-ID: 685293b2-a595-11ea-9dbe-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 685293b2-a595-11ea-9dbe-bc764e2007e4; Wed, 03 Jun 2020 12:26:11 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id gl26so1930188ejb.11 for ; Wed, 03 Jun 2020 05:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WJ5W6AxroBMLD68IaEhFmZy4K36m34K2nIdGZSm2vB8=; b=oxh35808L0reWI07HJzgVLpcJ2ClaFwGumrNPds6D3/P2yHHugicz71Ju3s0/OEDod v/k3XjIveBc/xe/GCgeBQvY32IKmvCNHFBkWWGCI7IbmMdTy5lSyQH1VoruUMp2Q6rf3 W8UjkKw/NXucIANHacVhJY3DOfH9RHO8CgYhfgXlIGAYYPNQxiOFESIaaOMT+iAu2DEx X+k5jT26VeHS6S5dPM6xl/2lHCTUXr9AkQVbKIXLgL02G0sB1I5nhXSHw5yp6oadNKVm cISRiPm/cYREtudy3LKo4yPM0I/jY+TxLENioNXx7gy6M3O50PNefpNU0scUOzGAorIm uYuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WJ5W6AxroBMLD68IaEhFmZy4K36m34K2nIdGZSm2vB8=; b=PG3dlm39igNYaXOYsfZWJpgo2H8vBWJF6PoP/uvBO0KBy7Gzf9gAVI4aZUNI9GMXe8 DYNFY/spalYn/aUNMvoHfVYBSkCiizbT0GkZTmq8LPyEwduqFbuYtpINybawH2eq/ftq dbLcvTJhE4iQq8IhCSSPCX30h/Z6qYfPFA1RDiwgtdRGkko+s/WgNYgwPqS54QuX8qrZ IobC+KNaUSDdDCKJ5XrvZqemkhtcndcg0BOVOAl4renvVP4S0TOtwXnDh3UvTKVw/yxb GsnUiNmBjnyk1BbrvzLmNBpKndbBhsIauumSp41HLS1iOVMs0egzOI988Mp1MEKrmNX3 u8Vg== X-Gm-Message-State: AOAM531laIkQ6KmOvst/Y7sHmVAOGDACNuzLxfEmwXSxzJhOOWDVdSCD qQrg0jeW4OeHFtzdrXe251UoqmNFFyg= X-Google-Smtp-Source: ABdhPJwN7ROwWqEZTJ+pFtur98VTAZ6ShX82sB8trP8oOuiiTsFKO2R0gA5l1P8EBBJj1tuoeP76VA== X-Received: by 2002:a17:906:746:: with SMTP id z6mr13108987ejb.12.1591187169208; Wed, 03 Jun 2020 05:26:09 -0700 (PDT) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com. [209.85.128.51]) by smtp.gmail.com with ESMTPSA id a7sm591133edx.3.2020.06.03.05.26.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 05:26:08 -0700 (PDT) Received: by mail-wm1-f51.google.com with SMTP id u13so1738340wml.1 for ; Wed, 03 Jun 2020 05:26:07 -0700 (PDT) X-Received: by 2002:a05:600c:23ce:: with SMTP id p14mr8553265wmb.77.1591187167541; Wed, 03 Jun 2020 05:26:07 -0700 (PDT) MIME-Version: 1.0 References: <20200602134909.66581-1-tamas@tklengyel.com> <20200603082824.GC1195@Air-de-Roger> In-Reply-To: <20200603082824.GC1195@Air-de-Roger> From: Tamas K Lengyel Date: Wed, 3 Jun 2020 06:25:31 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 3, 2020 at 2:28 AM Roger Pau Monn=C3=A9 = wrote: > > On Tue, Jun 02, 2020 at 07:49:09AM -0600, Tamas K Lengyel wrote: > > For the last couple years we have received numerous reports from users = of > > monitor vm_events of spurious guest crashes when using events. In parti= cular, > > it has observed that the problem occurs when vm_events are being disabl= ed. The > > nature of the guest crash varied widely and has only occured occasional= ly. This > > made debugging the issue particularly hard. We had discussions about th= is issue > > even here on the xen-devel mailinglist with no luck figuring it out. > > > > The bug has now been identified as a race-condition between register ev= ent > > handling and disabling the monitor vm_event interface. > > > > Patch 96760e2fba100d694300a81baddb5740e0f8c0ee, "vm_event: deny registe= r writes > > if refused by vm_event reply" is the patch that introduced the error. = In this > > FWIW, we use the 'Fixes:' tag in order to make it easier for > maintainers of stable trees to know which bugfixes to pick. This > should have: > > Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_eve= nt reply') > > Before the SoB. > > > patch the default behavior regarding emulation of register write events= is > > changed so that they get postponed until the corresponding vm_event han= dler > > decides whether to allow such write to take place. Unfortunately this c= an only > > be implemented by performing the deny/allow step when the vCPU gets sch= eduled. > > Due to that postponed emulation of the event if the user decides to pau= se the > > VM in the vm_event handler and then disable events, the entire emulatio= n step > > is skipped the next time the vCPU is resumed. Even if the user doesn't = pause > > during the vm_event handling but exits immediately and disables vm_even= t, the > > situation becomes racey as disabling vm_event may succeed before the gu= est's > > vCPUs get scheduled with the pending emulation task. This has been part= icularly > > the case with VMS that have several vCPUs as after the VM is unpaused i= t may > > actually take a long time before all vCPUs get scheduled. > > > > In this patch we are reverting the default behavior to always perform e= mulation > > of register write events when the event occurs. To postpone them can be= turned > > on as an option. In that case the user of the interface still has to ta= ke care > > of only disabling the interface when its safe as it remains buggy. > > > > Signed-off-by: Tamas K Lengyel > > Thanks for taking care of this! > > > --- > > xen/arch/x86/hvm/hvm.c | 14 ++++++++------ > > xen/arch/x86/hvm/monitor.c | 13 ++++++++----- > > xen/arch/x86/monitor.c | 10 +++++++++- > > xen/include/asm-x86/domain.h | 1 + > > xen/include/asm-x86/hvm/monitor.h | 7 +++---- > > xen/include/public/domctl.h | 1 + > > 6 files changed, 30 insertions(+), 16 deletions(-) > > > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > > index 74c9f84462..5bb47583b3 100644 > > --- a/xen/arch/x86/hvm/hvm.c > > +++ b/xen/arch/x86/hvm/hvm.c > > @@ -3601,13 +3601,15 @@ int hvm_msr_write_intercept(unsigned int msr, u= int64_t msr_content, > > > > ASSERT(v->arch.vm_event); > > > > - /* The actual write will occur in hvm_do_resume() (if permitte= d). */ > > - v->arch.vm_event->write_data.do_write.msr =3D 1; > > - v->arch.vm_event->write_data.msr =3D msr; > > - v->arch.vm_event->write_data.value =3D msr_content; > > + if ( hvm_monitor_msr(msr, msr_content, msr_old_content) ) > > + { > > + /* The actual write will occur in hvm_do_resume(), if perm= itted. */ > > + v->arch.vm_event->write_data.do_write.msr =3D 1; > > + v->arch.vm_event->write_data.msr =3D msr; > > + v->arch.vm_event->write_data.value =3D msr_content; > > > > - hvm_monitor_msr(msr, msr_content, msr_old_content); > > - return X86EMUL_OKAY; > > + return X86EMUL_OKAY; > > + } > > } > > > > if ( (ret =3D guest_wrmsr(v, msr, msr_content)) !=3D X86EMUL_UNHAN= DLEABLE ) > > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c > > index 8aa14137e2..36894b33a4 100644 > > --- a/xen/arch/x86/hvm/monitor.c > > +++ b/xen/arch/x86/hvm/monitor.c > > @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned lo= ng value, unsigned long old) > > .u.write_ctrlreg.old_value =3D old > > }; > > > > - if ( monitor_traps(curr, sync, &req) >=3D 0 ) > > - return 1; > > + return monitor_traps(curr, sync, &req) >=3D 0 && > > + curr->domain->arch.monitor.control_register_values; > > Nit (it can be fixed while committing IMO): curr should be aligned to > monitor. This is the established style already in-place, see http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/arch/x86/hvm/mo= nitor.c;h=3D8aa14137e25a47d3826843441e244decf81dc855;hb=3Drefs/heads/stagin= g#l76: 76 return curr->domain->arch.monitor.emul_unimplemented_enabled && 77 monitor_traps(curr, true, &req) =3D=3D 1; I don't really care either way but at least we should be consistent. > > > } > > > > - return 0; > > + return false; > > } > > > > bool hvm_monitor_emul_unimplemented(void) > > @@ -77,7 +77,7 @@ bool hvm_monitor_emul_unimplemented(void) > > monitor_traps(curr, true, &req) =3D=3D 1; > > } > > > > -void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t ol= d_value) > > +bool hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t ol= d_value) > > { > > struct vcpu *curr =3D current; > > > > @@ -92,8 +92,11 @@ void hvm_monitor_msr(unsigned int msr, uint64_t new_= value, uint64_t old_value) > > .u.mov_to_msr.old_value =3D old_value > > }; > > > > - monitor_traps(curr, 1, &req); > > + return monitor_traps(curr, 1, &req) >=3D 0 && > > + curr->domain->arch.monitor.control_register_values; > > Same here. > > > } > > + > > + return false; > > } > > > > void hvm_monitor_descriptor_access(uint64_t exit_info, > > diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c > > index bbcb7536c7..1517a97f50 100644 > > --- a/xen/arch/x86/monitor.c > > +++ b/xen/arch/x86/monitor.c > > @@ -144,7 +144,15 @@ int arch_monitor_domctl_event(struct domain *d, > > struct xen_domctl_monitor_op *mop) > > { > > struct arch_domain *ad =3D &d->arch; > > - bool requested_status =3D (XEN_DOMCTL_MONITOR_OP_ENABLE =3D=3D mop= ->op); > > + bool requested_status; > > + > > + if ( XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS =3D=3D mop->op ) > > + { > > + ad->monitor.control_register_values =3D true; > > + return 0; > > I think this would be better implemented in arch_monitor_domctl_op > which already handles other XEN_DOMCTL_MONITOR_OP_* options, and also > skips the arch_monitor_domctl_event call? Hm, yea, that would be better placement for it, you are right. > > > + } > > + > > + requested_status =3D (XEN_DOMCTL_MONITOR_OP_ENABLE =3D=3D mop->op)= ; > > > > switch ( mop->event ) > > { > > diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.= h > > index e8cee3d5e5..6fd94c2e14 100644 > > --- a/xen/include/asm-x86/domain.h > > +++ b/xen/include/asm-x86/domain.h > > @@ -418,6 +418,7 @@ struct arch_domain > > * This is used to filter out pagefaults. > > */ > > unsigned int inguest_pagefault_disabled = : 1; > > + unsigned int control_register_values = : 1; > > struct monitor_msr_bitmap *msr_bitmap; > > uint64_t write_ctrlreg_mask[4]; > > } monitor; > > diff --git a/xen/include/asm-x86/hvm/monitor.h b/xen/include/asm-x86/hv= m/monitor.h > > index 66de24cb75..a75cd8545c 100644 > > --- a/xen/include/asm-x86/hvm/monitor.h > > +++ b/xen/include/asm-x86/hvm/monitor.h > > @@ -29,15 +29,14 @@ enum hvm_monitor_debug_type > > }; > > > > /* > > - * Called for current VCPU on crX/MSR changes by guest. > > - * The event might not fire if the client has subscribed to it in onch= angeonly > > - * mode, hence the bool return type for control register write events. > > + * Called for current VCPU on crX/MSR changes by guest. Bool return si= gnals > > + * whether emulation should be postponed. > > */ > > bool hvm_monitor_cr(unsigned int index, unsigned long value, > > unsigned long old); > > #define hvm_monitor_crX(cr, new, old) \ > > hvm_monitor_cr(VM_EVENT_X86_##cr, new, old) > > -void hvm_monitor_msr(unsigned int msr, uint64_t value, uint64_t old_va= lue); > > +bool hvm_monitor_msr(unsigned int msr, uint64_t value, uint64_t old_va= lue); > > void hvm_monitor_descriptor_access(uint64_t exit_info, > > uint64_t vmx_exit_qualification, > > uint8_t descriptor, bool is_write); > > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h > > index 1ad34c35eb..cbcd25f12c 100644 > > --- a/xen/include/public/domctl.h > > +++ b/xen/include/public/domctl.h > > @@ -1025,6 +1025,7 @@ struct xen_domctl_psr_cmt_op { > > #define XEN_DOMCTL_MONITOR_OP_DISABLE 1 > > #define XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES 2 > > #define XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP 3 > > +#define XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS 4 > > Could you please add a note that this is broken? Sure. Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 03 12:52:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 12:52:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSsu-0001R3-Rr; Wed, 03 Jun 2020 12:52:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSst-0001Qy-8P for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 12:52:43 +0000 X-Inumbo-ID: 1cd95be2-a599-11ea-8993-bc764e2007e4 Received: from mail-oi1-x243.google.com (unknown [2607:f8b0:4864:20::243]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1cd95be2-a599-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 12:52:42 +0000 (UTC) Received: by mail-oi1-x243.google.com with SMTP id x202so1659999oix.11 for ; Wed, 03 Jun 2020 05:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=TI9bV+LeMVxfdt8lcpN5FNLTi4bVZXWnT3tiy2sCbRI=; b=E9GQUJjq8yL4WVda/KAG/4p1XS8/EyBKH+3kntmWoYZleJfi/1S/ulX0WPTx/fnjiA OIeCKlHLVMFnZxWwY5pdsHBmCArKjhy2RkuNcCwtcjywWFydtEb7UjQBzGqGY92KDcb/ ITuRQJpS1FYT9TVvLAGlNSadM++If1X1oyqJcauW0VHVaJuEE6QQ2Yerj+S+sjJ/rXP2 OAMKv9OTRMtGqChbOooPwf3+OGDIMbAHFGHsxn/VlT3Ofm8SgFJcyG4jnnQ+cqxKqv2A bfV1qYoNdEVQsg72PNOvJPoNd93issxs52vgIf1beaIXUu18R7RnLyANwWSNPO7DrUJl BMdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=TI9bV+LeMVxfdt8lcpN5FNLTi4bVZXWnT3tiy2sCbRI=; b=Ew8YSg3dKZJJKUE+6ILmtRQT7LdLdLdzk5zmnLdI1i7GZe7mz/1oVlrTbtPf9IYLP4 xWDV8l1BkNzfY+qbmrcRxA8h0B2Mc7bIqADNWWLiJ5qZCOTT1vXSTTCklucq45vYeTdG X08JmiDDdqCE768zoQf8dItUHsicwCa1zWe8Rs27Oz840Vbe/ivUql2hJ0rUk/WWqFDS 9BEQ9Tanzj3HX457Go+MLHu/ZmvTNcZLJoS4V4s7+bFkxeY9UnxJBY6FfKJTGwRdePiK 0f7BEzVD7zVzeFX5AnUFpniC6dHQYfeDgndiKI31/JOHSnDgSUgsEBgaz3xxGyjEtHaY kZ1w== X-Gm-Message-State: AOAM531wI1p565KR6Zz7ZI/RqC7+SPpATdRbjz+ukuyBW+9rafhL3QRa 7OzDbKG6ld3y8dmAFtqHKOOM+LUduVQ= X-Google-Smtp-Source: ABdhPJx3zN5OBrSLzPMWqgMC1+eM4NK2sJzjVscfJyr+3jaLdle6IneNwN6us47Q/rxyn1/hxoiiSA== X-Received: by 2002:a54:460f:: with SMTP id p15mr5890733oip.84.1591188761256; Wed, 03 Jun 2020 05:52:41 -0700 (PDT) Received: from localhost (c-71-205-12-124.hsd1.co.comcast.net. [71.205.12.124]) by smtp.gmail.com with ESMTPSA id 89sm471962oth.9.2020.06.03.05.52.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 05:52:40 -0700 (PDT) From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events Date: Wed, 3 Jun 2020 06:52:37 -0600 Message-Id: <20200603125237.100041-1-tamas@tklengyel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Tamas K Lengyel , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Stefano Stabellini , Jan Beulich , Alexandru Isaila , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" For the last couple years we have received numerous reports from users of monitor vm_events of spurious guest crashes when using events. In particular, it has observed that the problem occurs when vm_events are being disabled. The nature of the guest crash varied widely and has only occured occasionally. This made debugging the issue particularly hard. We had discussions about this issue even here on the xen-devel mailinglist with no luck figuring it out. The bug has now been identified as a race-condition between register event handling and disabling the monitor vm_event interface. The default behavior regarding emulation of register write events is changed so that they get postponed until the corresponding vm_event handler decides whether to allow such write to take place. Unfortunately this can only be implemented by performing the deny/allow step when the vCPU gets scheduled. Due to that postponed emulation of the event if the user decides to pause the VM in the vm_event handler and then disable events, the entire emulation step is skipped the next time the vCPU is resumed. Even if the user doesn't pause during the vm_event handling but exits immediately and disables vm_event, the situation becomes racey as disabling vm_event may succeed before the guest's vCPUs get scheduled with the pending emulation task. This has been particularly the case with VMS that have several vCPUs as after the VM is unpaused it may actually take a long time before all vCPUs get scheduled. In this patch we are reverting the default behavior to always perform emulation of register write events when the event occurs. To postpone them can be turned on as an option. In that case the user of the interface still has to take care of only disabling the interface when its safe as it remains buggy. Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event reply'). Signed-off-by: Tamas K Lengyel --- xen/arch/x86/hvm/hvm.c | 14 ++++++++------ xen/arch/x86/hvm/monitor.c | 13 ++++++++----- xen/include/asm-x86/domain.h | 1 + xen/include/asm-x86/hvm/monitor.h | 7 +++---- xen/include/asm-x86/monitor.h | 4 ++++ xen/include/public/domctl.h | 6 ++++++ 6 files changed, 30 insertions(+), 15 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 74c9f84462..5bb47583b3 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -3601,13 +3601,15 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content, ASSERT(v->arch.vm_event); - /* The actual write will occur in hvm_do_resume() (if permitted). */ - v->arch.vm_event->write_data.do_write.msr = 1; - v->arch.vm_event->write_data.msr = msr; - v->arch.vm_event->write_data.value = msr_content; + if ( hvm_monitor_msr(msr, msr_content, msr_old_content) ) + { + /* The actual write will occur in hvm_do_resume(), if permitted. */ + v->arch.vm_event->write_data.do_write.msr = 1; + v->arch.vm_event->write_data.msr = msr; + v->arch.vm_event->write_data.value = msr_content; - hvm_monitor_msr(msr, msr_content, msr_old_content); - return X86EMUL_OKAY; + return X86EMUL_OKAY; + } } if ( (ret = guest_wrmsr(v, msr, msr_content)) != X86EMUL_UNHANDLEABLE ) diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c index 8aa14137e2..e4a09964a0 100644 --- a/xen/arch/x86/hvm/monitor.c +++ b/xen/arch/x86/hvm/monitor.c @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long old) .u.write_ctrlreg.old_value = old }; - if ( monitor_traps(curr, sync, &req) >= 0 ) - return 1; + return monitor_traps(curr, sync, &req) >= 0 && + curr->domain->arch.monitor.control_register_values; } - return 0; + return false; } bool hvm_monitor_emul_unimplemented(void) @@ -77,7 +77,7 @@ bool hvm_monitor_emul_unimplemented(void) monitor_traps(curr, true, &req) == 1; } -void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value) +bool hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value) { struct vcpu *curr = current; @@ -92,8 +92,11 @@ void hvm_monitor_msr(unsigned int msr, uint64_t new_value, uint64_t old_value) .u.mov_to_msr.old_value = old_value }; - monitor_traps(curr, 1, &req); + return monitor_traps(curr, 1, &req) >= 0 && + curr->domain->arch.monitor.control_register_values; } + + return false; } void hvm_monitor_descriptor_access(uint64_t exit_info, diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h index e8cee3d5e5..6fd94c2e14 100644 --- a/xen/include/asm-x86/domain.h +++ b/xen/include/asm-x86/domain.h @@ -418,6 +418,7 @@ struct arch_domain * This is used to filter out pagefaults. */ unsigned int inguest_pagefault_disabled : 1; + unsigned int control_register_values : 1; struct monitor_msr_bitmap *msr_bitmap; uint64_t write_ctrlreg_mask[4]; } monitor; diff --git a/xen/include/asm-x86/hvm/monitor.h b/xen/include/asm-x86/hvm/monitor.h index 66de24cb75..a75cd8545c 100644 --- a/xen/include/asm-x86/hvm/monitor.h +++ b/xen/include/asm-x86/hvm/monitor.h @@ -29,15 +29,14 @@ enum hvm_monitor_debug_type }; /* - * Called for current VCPU on crX/MSR changes by guest. - * The event might not fire if the client has subscribed to it in onchangeonly - * mode, hence the bool return type for control register write events. + * Called for current VCPU on crX/MSR changes by guest. Bool return signals + * whether emulation should be postponed. */ bool hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long old); #define hvm_monitor_crX(cr, new, old) \ hvm_monitor_cr(VM_EVENT_X86_##cr, new, old) -void hvm_monitor_msr(unsigned int msr, uint64_t value, uint64_t old_value); +bool hvm_monitor_msr(unsigned int msr, uint64_t value, uint64_t old_value); void hvm_monitor_descriptor_access(uint64_t exit_info, uint64_t vmx_exit_qualification, uint8_t descriptor, bool is_write); diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h index 4afb0665e8..01c6d63bb9 100644 --- a/xen/include/asm-x86/monitor.h +++ b/xen/include/asm-x86/monitor.h @@ -59,6 +59,10 @@ int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop) domain_unpause(d); break; + case XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS: + d->arch.monitor.control_register_values = true; + break; + default: rc = -EOPNOTSUPP; } diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index 1ad34c35eb..59bdc28c89 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -1025,6 +1025,12 @@ struct xen_domctl_psr_cmt_op { #define XEN_DOMCTL_MONITOR_OP_DISABLE 1 #define XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES 2 #define XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP 3 +/* + * Control register feature can result in guest-crashes when the monitor + * subsystem is being turned off. User has to take special precautions + * to ensure all vCPUs have resumed before it is safe to turn it off. + */ +#define XEN_DOMCTL_MONITOR_OP_CONTROL_REGISTERS 4 #define XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG 0 #define XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR 1 -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 12:53:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 12:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgStb-0001Tg-4z; Wed, 03 Jun 2020 12:53:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSta-0001TZ-F1 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 12:53:26 +0000 X-Inumbo-ID: 36cc0b6c-a599-11ea-8993-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 36cc0b6c-a599-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 12:53:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OSz1Xa9yam1G8SOQx0ffBVQeHiRY2cCxbLwnBYId70k=; b=ofSlL7hfE7COqGYqdN4MWJp3o HRaer9XKM1yA7XNm+MEwhLDuPrRgeFul7O9+qSUM2AQJoBN2j7a8YvfFH0QifAYB87lkuaR1LTXiM 1LMEBFmLG9qM+Mzhp/iDedwCMP3PlSAH5AmohQ+IYQlHXdIZbO5woLLUe8hcvp5glcBAQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgStZ-0004Pc-8K; Wed, 03 Jun 2020 12:53:25 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgStZ-0002uf-0f; Wed, 03 Jun 2020 12:53:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgStY-0005wE-VW; Wed, 03 Jun 2020 12:53:24 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150646: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=99a76a88d5e7f4693bb6b286e366006e1da1c954 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Wed, 03 Jun 2020 12:53:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150646 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150646/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 99a76a88d5e7f4693bb6b286e366006e1da1c954 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 5 days Failing since 150465 2020-05-29 09:02:14 Z 5 days 38 attempts Testing same since 150629 2020-06-02 21:00:40 Z 0 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1494 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 12:53:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 12:53:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgStt-0001XD-E2; Wed, 03 Jun 2020 12:53:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgSts-0001Wu-5U for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 12:53:44 +0000 X-Inumbo-ID: 4093a588-a599-11ea-ad08-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4093a588-a599-11ea-ad08-12813bfff9fa; Wed, 03 Jun 2020 12:53:42 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ClC1T8q0TfvbFhJbMQVpB6SxFbPK6eGxf+0bEPe3KjfZk01tta5B8PK51pO6RMenNCHVPPiR+6 pL0c5WE6jjE+pLAzsXOOkRfDJ9zjHUa6v+sCHQJe0hFuXdr3XNqdJSmZFYu15oekse4xK7SzR0 VDbk65QWfsEuMpIuS9mjmC/uiRPECEuH0OlLhCgl1EzM+NOqNM+2/Yt230PXrB747O692foUQx oqCaEPsYYucsiaoDD9RqK/K7s49c2uKKRVHQlIicI2sLfhnGCB34WffArQpUG4NXIgoHi6hJJJ S2s= X-SBRS: 2.7 X-MesageID: 19134236 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19134236" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24279.40273.27032.753151@mariner.uk.xensource.com> Date: Wed, 3 Jun 2020 13:53:37 +0100 To: Pavel Hrdina Subject: Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update) In-Reply-To: <20200603113418.GB11390@antique-laptop> References: <20200602154745.15054-1-ian.jackson@eu.citrix.com> <20200603103109.GA11390@antique-laptop> <20200603103708.GB2892653@redhat.com> <20200603113418.GB11390@antique-laptop> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: libvir-list@redhat.com, xen-devel@lists.xenproject.org, "Daniel P.=?iso-8859-1?Q?Berrang=E9?=" , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Pavel Hrdina writes ("Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)"): > There should not be any need to disable this explicitly unless you want > to build libvirt with different revisions of submodules. The Xen Project CI has a cross-tree bisector. It is capable of automatically selecting revisions, including revisions of submodules, for testing. It therefore needs to be able to build with different revisions of submodules, indeed. Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 13:29:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 13:29:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgTS7-0005KA-EL; Wed, 03 Jun 2020 13:29:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgTS5-0005Jv-KB for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 13:29:05 +0000 X-Inumbo-ID: 3122cb56-a59e-11ea-ad11-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3122cb56-a59e-11ea-ad11-12813bfff9fa; Wed, 03 Jun 2020 13:29:04 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: TPcMrBTyqfwu7Yg3jS+r/X+y+/0BOtVpY4flKzhRZBjZVIen+rtVFe0pQT14WBGPsZRB2oRjkO 9kDnIDr7rFOFxs0J/65UdIIxUl1GpSK/gUHCWkQMCLiu9hhjgq7tGOcrdOBiOvfZcqoG0c9dgg FcYG/dMfwwLsB18xIgsJzIaKHzkjz2hWMGJcIs8+ssqkndQ3Heldm5Z40CO/nGqHPVpJAhyb8y JXG/VOQhc5cgKMKWza1Q3QD0ewcQc420shP29nIjyXy0Hz+WZX+kmlEZWElkex/+Q6fbZdJnF0 +oA= X-SBRS: 2.7 X-MesageID: 19138435 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19138435" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24279.42394.719346.971506@mariner.uk.xensource.com> Date: Wed, 3 Jun 2020 14:28:58 +0100 To: Pavel Hrdina Subject: Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update) In-Reply-To: <20200603103109.GA11390@antique-laptop> References: <20200602154745.15054-1-ian.jackson@eu.citrix.com> <20200603103109.GA11390@antique-laptop> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: libvir-list@redhat.com, xen-devel@lists.xenproject.org, George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Pavel Hrdina writes ("Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)"): > To be honest I don't understand why would anyone want to keep track of > all submodules of all projects for any CI and update it manually every > time the upstream project changes these submodules. Sounds like a lot > of unnecessary work but maybe I'm missing something. Maybe I should answer this. The short answer is that this can be done entirely automatically. > Well, we will break a lot more by switching to Meson build system where > everyone building libvirt will have to change their scripts as it will > not be compatible at all. When that occurs we'll have to change our build rune, of course. Our CI system (which does bisection and stable tracking and so on) will wants to build old versions, so it'll have to have both build runes and look for something in-tree to tell the two methods apart. Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 13:57:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 13:57:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgTtB-0008U2-OT; Wed, 03 Jun 2020 13:57:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgTtB-0008Tx-Dc for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 13:57:05 +0000 X-Inumbo-ID: 1ac75814-a5a2-11ea-81bc-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1ac75814-a5a2-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 13:57:04 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: px/94CR6m58rgUqn6TH2mprv/7R8t7s1G9T0cktCs4f83+xtzc0DJ8jJM3JxeQmdfhskB8m+Xb CCHptaD+G4jKbxXluDq5hd6HpOmKnl3n2SY0cOJjVcbJUbd17wCeSaX3Hmk0l930MvfDxZz1KG XT0wv+VXqMs6eERI5ygRxhFVTGoJx1dEGZKOPQD23aX7+ZCbG5uO8lcERmtwyzJldqIcC+DXz4 04btNGA05xI9s2KAkpi1L3m8KMrNXLEgx12upkApPC4niCsNGpbtE7xY4dDb4pNTPxuV7u3v/8 OAY= X-SBRS: 2.7 X-MesageID: 19471919 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19471919" Date: Wed, 3 Jun 2020 15:56:56 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH v3 for-4.14] x86/monitor: revert default behavior when monitoring register write events Message-ID: <20200603135656.GE1195@Air-de-Roger> References: <20200602134909.66581-1-tamas@tklengyel.com> <20200603082824.GC1195@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 06:25:31AM -0600, Tamas K Lengyel wrote: > On Wed, Jun 3, 2020 at 2:28 AM Roger Pau Monné wrote: > > > > On Tue, Jun 02, 2020 at 07:49:09AM -0600, Tamas K Lengyel wrote: > > > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c > > > index 8aa14137e2..36894b33a4 100644 > > > --- a/xen/arch/x86/hvm/monitor.c > > > +++ b/xen/arch/x86/hvm/monitor.c > > > @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigned long value, unsigned long old) > > > .u.write_ctrlreg.old_value = old > > > }; > > > > > > - if ( monitor_traps(curr, sync, &req) >= 0 ) > > > - return 1; > > > + return monitor_traps(curr, sync, &req) >= 0 && > > > + curr->domain->arch.monitor.control_register_values; > > > > Nit (it can be fixed while committing IMO): curr should be aligned to > > monitor. > > This is the established style already in-place, see > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/monitor.c;h=8aa14137e25a47d3826843441e244decf81dc855;hb=refs/heads/staging#l76: > > 76 return curr->domain->arch.monitor.emul_unimplemented_enabled && > 77 monitor_traps(curr, true, &req) == 1; > > I don't really care either way but at least we should be consistent. Oh, OK. This is slightly different from the indentation that I tend to use, sorry for the request then. Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 14:06:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 14:06:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgU2b-0001DG-PF; Wed, 03 Jun 2020 14:06:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgU2a-0001DB-4V for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 14:06:48 +0000 X-Inumbo-ID: 761d2a08-a5a3-11ea-81bc-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 761d2a08-a5a3-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 14:06:47 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id e2so2277564eje.13 for ; Wed, 03 Jun 2020 07:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rdDXsiPxGSJU2BtwbPhpcMj2P5mFJwWwZcKY6DLpIbw=; b=HSnDEB2SMNO4n9KsnRD//6k/52vtDufIxaSIpwL/58X6YZDCZpHaCMoY74Ki4C+EP5 36RajTCquG2qBIK+W5IV5LL4tTXO7ePdJlPTITDQXOeeSrTsnqqb1SL877kewz6hIo3B koLMs83qaGmwPBrOpQHGfrmxzlK/eD/1W1+Oho9g2Db7CdpAjlqGnwx9W+iLC0RGyxOn au3OYlccTtMUYt1n4UByJNav/hNMS3J5dY1g74yV3Wur6qBrLkgsUmC663aVKugJgEn0 A158lSvknQVVyf1CXOEbIB0/7xlEmnG12XihepuDUsieYI5tGrJ1+vbKsSsQYKnkcbnG 6WdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rdDXsiPxGSJU2BtwbPhpcMj2P5mFJwWwZcKY6DLpIbw=; b=lWljiaJfAown907s31AOrNcKE4mXOBcyGss0IZNhZtNIxz3oOL6pVA/srlLhjfwYUd C8kHgc+UmHuKJTtHJCROVRqZ/Mjq6DAS255tEKhwDHgN4UWPmCo5i9DDsUKkSZopkFUP 12MVRaUZnNCRCTXbfaF4W2QSujZ2ackv6VgblcawuCtM7uk40pK5qCyxtZH+6Z1M13e+ bCWTW75uIY2K6y9ny9Bl7xeOjUnlYgWLSLBWvvDQCYVT9QsDZFn6jTiVVtYklCGP65RK f/hixjuFUSiunWBwJEex3NoPDxSgKy4D0LpRR2d92XBWnw/hLk8v9wrK6DT6il799tMY UpCQ== X-Gm-Message-State: AOAM532nseEmS7cT31vBBfy7ig8VlEJDPg4308bwFvQ1URNjXAHo+wS8 8q/Gmsmv2yYiK+Dhyru5MSIRyPrfOf8= X-Google-Smtp-Source: ABdhPJwXWaFYtdEiDKU2C6gfDcx03M6ZL22N6597CHY8WoN/KbdNPamfdEi8WVptWt5qJaAtm6cS0w== X-Received: by 2002:a17:906:1d5b:: with SMTP id o27mr20959702ejh.344.1591193206082; Wed, 03 Jun 2020 07:06:46 -0700 (PDT) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com. [209.85.221.47]) by smtp.gmail.com with ESMTPSA id ce23sm1276985edb.79.2020.06.03.07.06.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 07:06:45 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id e1so2530281wrt.5 for ; Wed, 03 Jun 2020 07:06:45 -0700 (PDT) X-Received: by 2002:adf:f0c6:: with SMTP id x6mr33671775wro.301.1591193204812; Wed, 03 Jun 2020 07:06:44 -0700 (PDT) MIME-Version: 1.0 References: <20200602134909.66581-1-tamas@tklengyel.com> <20200603082824.GC1195@Air-de-Roger> <20200603135656.GE1195@Air-de-Roger> In-Reply-To: <20200603135656.GE1195@Air-de-Roger> From: Tamas K Lengyel Date: Wed, 3 Jun 2020 08:06:08 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 3, 2020 at 7:57 AM Roger Pau Monn=C3=A9 = wrote: > > On Wed, Jun 03, 2020 at 06:25:31AM -0600, Tamas K Lengyel wrote: > > On Wed, Jun 3, 2020 at 2:28 AM Roger Pau Monn=C3=A9 wrote: > > > > > > On Tue, Jun 02, 2020 at 07:49:09AM -0600, Tamas K Lengyel wrote: > > > > diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.= c > > > > index 8aa14137e2..36894b33a4 100644 > > > > --- a/xen/arch/x86/hvm/monitor.c > > > > +++ b/xen/arch/x86/hvm/monitor.c > > > > @@ -53,11 +53,11 @@ bool hvm_monitor_cr(unsigned int index, unsigne= d long value, unsigned long old) > > > > .u.write_ctrlreg.old_value =3D old > > > > }; > > > > > > > > - if ( monitor_traps(curr, sync, &req) >=3D 0 ) > > > > - return 1; > > > > + return monitor_traps(curr, sync, &req) >=3D 0 && > > > > + curr->domain->arch.monitor.control_register_values; > > > > > > Nit (it can be fixed while committing IMO): curr should be aligned to > > > monitor. > > > > This is the established style already in-place, see > > http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dxen/arch/x86/hv= m/monitor.c;h=3D8aa14137e25a47d3826843441e244decf81dc855;hb=3Drefs/heads/st= aging#l76: > > > > 76 return curr->domain->arch.monitor.emul_unimplemented_enabled &= & > > 77 monitor_traps(curr, true, &req) =3D=3D 1; > > > > I don't really care either way but at least we should be consistent. > > Oh, OK. This is slightly different from the indentation that I tend to > use, sorry for the request then. I made the change regardless. Feel free to re-adjust the style or change the alignment of the above return on commit. Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 03 14:21:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 14:21:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgUGz-0003D4-8d; Wed, 03 Jun 2020 14:21:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgUGy-0003Cz-8L for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 14:21:40 +0000 X-Inumbo-ID: 8838b3fe-a5a5-11ea-ad2b-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 8838b3fe-a5a5-11ea-ad2b-12813bfff9fa; Wed, 03 Jun 2020 14:21:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591194096; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=dG/yQ9a63s7lXKLvQbG7qj+rieUda3Umi2z626t+lmM=; b=K9ZWXO42oERx2aZNu46gm/rS20+NdEFVkl/9wO+7QGdyM4z6iNlquBAJBmjReLZSYvIir2 f9ZK/yIYMpSzEfp3pWeulVuwQ4jXU0Zx7Ntf4hVA6QBkzy35+7v3svUllGGR4qo0sgBvxv 3S6Ym6qu6Q1TXdwKh7rcgjA01+67ClA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-237-oCDvC9PbNs2o3V9QRXd3ag-1; Wed, 03 Jun 2020 10:21:25 -0400 X-MC-Unique: oCDvC9PbNs2o3V9QRXd3ag-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3820B18A0761; Wed, 3 Jun 2020 14:21:24 +0000 (UTC) Received: from antique-laptop (unknown [10.40.194.48]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5D05A60C47; Wed, 3 Jun 2020 14:21:20 +0000 (UTC) Date: Wed, 3 Jun 2020 16:21:17 +0200 From: Pavel Hrdina To: Ian Jackson Subject: Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update) Message-ID: <20200603142117.GD11390@antique-laptop> References: <20200602154745.15054-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 In-Reply-To: <20200602154745.15054-1-ian.jackson@eu.citrix.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="F8dlzb82+Fcn6AgP" Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: libvir-list@redhat.com, xen-devel@lists.xenproject.org, George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --F8dlzb82+Fcn6AgP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote: > Prior to 2621d48f005a "gnulib: delete all gnulib integration", > one could pass ./autogen.sh --no-git to prevent the libvirt build > system from running git submodule update. >=20 > This feature is needed by systems like the Xen Project CI which want > to explicitly control the revisions of every tree. These will > typically arrange to initialise the submodules check out the right > version of everything, and then expect the build system not to mess > with it any more. >=20 > Despite to the old documentation comments referring only to gnulib, > the --no-git feature is required not only because of gnulib but also > because of the other submodule, src/keycodemapdb. >=20 > (And in any case, even if it were no longer required because all the > submodules were removed, it ought ideally to have been retained as a > no-op for compaibility reasons.) >=20 > So restore the --no-git feature. >=20 > Because of the way the argument parsing of autogen.sh works, it is > easiest to recognise this option only if it comes first. This works > for the Xen Project CI, which has always passed this option first. >=20 > If something else is using this option (and hasn't introduced a > different workaround in the meantime), not in the first position, > then perhaps a more sophisticated approach will be needed. But I > think this will do for now. >=20 > Signed-off-by: Ian Jackson > --- > autogen.sh | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) >=20 > diff --git a/autogen.sh b/autogen.sh > index 4e1bbceb0a..1c98273452 100755 > --- a/autogen.sh > +++ b/autogen.sh > @@ -1,5 +1,10 @@ > #!/bin/sh > # Run this to generate all the initial makefiles, etc. > +# > +# THe following options must come first. All other or subsequent > +# arguments are passed to configure: > +# --no-git skip `git submodule update --init` > + > test -n "$srcdir" || srcdir=3D$(dirname "$0") > test -n "$srcdir" || srcdir=3D. > =20 > @@ -13,7 +18,11 @@ cd "$srcdir" > exit 1 > } > =20 > -git submodule update --init || exit 1 > +if [ "x$1" =3D x--no-git ]; then > +=09shift > +else > +=09git submodule update --init || exit 1 I changed the TAB into spaces. > +fi > =20 > autoreconf --verbose --force --install || exit 1 Reviewed-by: Pavel Hrdina and pushed. --F8dlzb82+Fcn6AgP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEcbzs91ho/coWWY7aUi1kczAH4YwFAl7Xsd0ACgkQUi1kczAH 4YwW0A//YKePxHaQmxH2flmbCR5i5WvXmCHbvROj6ql2lKIu9d80NLqICeb8p5UL iS+S6e+l5L18DmCKT6XYQpIz+oKR7oj+EL/bnt8KF3B+tQS3pXLmTZ7QJeAMXw2a 8KjBH1P5BMQ1/mR8vbF0UKAW/luk1OYSlF/pH74GfK+fqlNP5rJgiIQf/X7m8FsU 2MCPko9JLYdGq959KThgR2WbbibhmhM7iDxxcYzUYpT777bBbCn53Efvdn/2khnA l4rMe1eAPVFdVPHU62mckLOF7fZFTCicr8BU3JIX87Lx4N4I8TMl+Zd0ZYG0QOX3 lnoNSZBPOtzWPdJb3zLIWIHCm50460jw+SAThsaIa0BbzkcS/Yy40A/K0ynbRPRt SF+N7PF3+dlOLz9RsNVgKf1/eiNBVNmzLDxYsqp7AatMEftbTnSwXtqc5/tLwWxv lLufxuc3GBb60M0pum+xzF0CE1IfZXAxOpSTk//gVdjAPasQOJUE6nyWO4iDzPut raCUVkaGyxazSX/Gu7atOEF6C2qO7VYYhFVsduEMcmza9lzwmjrzvmNBFRQ4RXpU YIf4PmhdpB8bZxQl8QI8da4Kqibeq3Een0enSM4zXf8gEYDm7BRWUgh1ZAAKfwj8 zTUy5ldjjGyHEt5IMnTGLZkaFZ1mm647dTjElFKUatlPQofCOtg= =SGHf -----END PGP SIGNATURE----- --F8dlzb82+Fcn6AgP-- From xen-devel-bounces@lists.xenproject.org Wed Jun 03 14:23:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 14:23:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgUIq-0003I6-KZ; Wed, 03 Jun 2020 14:23:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgUIp-0003I0-4h for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 14:23:35 +0000 X-Inumbo-ID: ce6e569e-a5a5-11ea-ad2b-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ce6e569e-a5a5-11ea-ad2b-12813bfff9fa; Wed, 03 Jun 2020 14:23:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8EB09B1A7; Wed, 3 Jun 2020 14:23:36 +0000 (UTC) Subject: Re: Re [PATCH] x86/CET: Fix build following c/s 43b98e7190 To: Andrew Cooper References: <1eeb47f4-b9b9-c4d8-a5c9-58d78f0e0aeb@suse.com> <1c507672-bc8e-bc7e-df45-a652fb4c21f2@citrix.com> From: Jan Beulich Message-ID: <76b88620-9d36-3981-a468-a56dd54deffd@suse.com> Date: Wed, 3 Jun 2020 16:23:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <1c507672-bc8e-bc7e-df45-a652fb4c21f2@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03.06.2020 13:44, Andrew Cooper wrote: > On 03/06/2020 10:50, Jan Beulich wrote: >> On 02.06.2020 19:15, Andrew Cooper wrote: >>> On 02/06/2020 15:21, Jan Beulich wrote: >>>>> OSSTest reports: >>>>> >>>>> x86_64.S: Assembler messages: >>>>> x86_64.S:57: Error: no such instruction: `setssbsy' >>>>> /home/osstest/build.150510.build-amd64/xen/xen/Rules.mk:183: recipe for target 'head.o' failed >>>>> make[4]: Leaving directory '/home/osstest/build.150510.build-amd64/xen/xen/arch/x86/boot' >>>>> make[4]: *** [head.o] Error 1 >>>>> >>>>> All use of CET instructions, even those inside alternative blocks, needs to be >>>>> behind CONFIG_XEN_SHSTK, as it indicates suitable toolchain support. >>>>> >>>>> Signed-off-by: Andrew Cooper >>>> That's quite a bit of #ifdef-ary here. Simple (operand-less) insns >>>> like SETSSBSY could easily be made available via .byte directives. >>>> Would you be amenable to to ack-ing a patch to replace some of the >>>> #ifdef-s (at least the ones at the lstar, cstar, and sysenter >>>> entry points), after 4.14? >>> Yeah - that was a bit of a mess in the end.  (But given the >>> circumstances, and that I've got past form typo'ing the SETSSBSY opcode, >>> it probably was the right move even in hindsight). >>> >>> Reducing it to .byte should be fine so long as some form of /* setssbsy >>> */ comment appears. >> Sure. >> >>> One other option would be to introduce a SETSSBSY macro, but that hides >>> the alternative so is something I'd prefer to avoid. >> With this you mean you'd rather not see us go the CLAC/STAC route? >> I was instead thinking of a pure assembly macro named "setssbsy". >> In fact we could switch the CLAC/STAC ugliness to some such, if we >> end up being happy with the model. > > The thing about the current STAC / CLAC is that, as written, they give > the impression of being unconditional.  This is poor in terms of code > clarity. > > Furthermore, making them indistinguishable from the plain instructions > is definitely a no-go, because then we've got assembly source (again, > which appears unconditional) which doesn't match its disassembly (the > backing nops) - at least with the macros in upper case, it is obvious > that something is up, even if you have to searching for why. > > If we went for pure assembly macros with an alt_ or maybe_ prefix, then > that would be reasonable.  It looks as close to regular instruction as > possible, but also makes it explicitly clear that it is conditional. That wasn't the plan - I didn't mean to hide the alternatives aspect. I wanted to have simple "setssbsy", "clac", and "stac" macros expanding to just the insns, getting instantiated when !HAVE_AS_. This would make assembly code look descriptive no matter what assembler capabilities there are (for these operand-less insns, that is, not in general). Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 03 15:07:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 15:07:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgUzM-0007T5-6w; Wed, 03 Jun 2020 15:07:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgUzL-0007T0-AL for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 15:07:31 +0000 X-Inumbo-ID: f18f2b52-a5ab-11ea-9947-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f18f2b52-a5ab-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 15:07:30 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /WgkDs/icnrRkxrfZ5EuDKaR7SvsXSddDbMaxvp4qdegV01Q6FsqD1EMTL1E0Vr9ftNRBzjE7J Zw6bIsqlRad+xFB959P+xnslb3FHqVgUeSA59fQ+GfFMjbHJfk9QS0spNVsCmjkvavwzxkVLam muX/9JsZs7FiwkPbIRpa9XKwVEGonQfH/pDUSP7zccolISm2o8DSh5M7vjybKk8+CZHXtS4GzH Hee0dRXPss9u7aJMIWcggEGiHL5z6qDdUwUiTUUq2tzs5BVX6mjTixpyWjC4SS54M/uqUkgtGu n4o= X-SBRS: 2.7 X-MesageID: 19425457 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,467,1583211600"; d="scan'208";a="19425457" Date: Wed, 3 Jun 2020 17:07:21 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events Message-ID: <20200603150721.GF1195@Air-de-Roger> References: <20200603125237.100041-1-tamas@tklengyel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200603125237.100041-1-tamas@tklengyel.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 06:52:37AM -0600, Tamas K Lengyel wrote: > For the last couple years we have received numerous reports from users of > monitor vm_events of spurious guest crashes when using events. In particular, > it has observed that the problem occurs when vm_events are being disabled. The > nature of the guest crash varied widely and has only occured occasionally. This > made debugging the issue particularly hard. We had discussions about this issue > even here on the xen-devel mailinglist with no luck figuring it out. > > The bug has now been identified as a race-condition between register event > handling and disabling the monitor vm_event interface. The default behavior > regarding emulation of register write events is changed so that they get > postponed until the corresponding vm_event handler decides whether to allow such > write to take place. Unfortunately this can only be implemented by performing the > deny/allow step when the vCPU gets scheduled. > > Due to that postponed emulation of the event if the user decides to pause the > VM in the vm_event handler and then disable events, the entire emulation step > is skipped the next time the vCPU is resumed. Even if the user doesn't pause > during the vm_event handling but exits immediately and disables vm_event, the > situation becomes racey as disabling vm_event may succeed before the guest's > vCPUs get scheduled with the pending emulation task. This has been particularly > the case with VMS that have several vCPUs as after the VM is unpaused it may > actually take a long time before all vCPUs get scheduled. > > In this patch we are reverting the default behavior to always perform emulation > of register write events when the event occurs. To postpone them can be turned > on as an option. In that case the user of the interface still has to take care > of only disabling the interface when its safe as it remains buggy. > > Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event > reply'). > > Signed-off-by: Tamas K Lengyel Thanks! Reviewed-by: Roger Pau Monné I would like to get some input from Bitdefender really, and whether they are fine with this approach. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 15:23:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 15:23:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVEQ-0000z4-Is; Wed, 03 Jun 2020 15:23:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVEP-0000yz-4M for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 15:23:05 +0000 X-Inumbo-ID: 1e03105c-a5ae-11ea-8993-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1e03105c-a5ae-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 15:23:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 9D135AE39; Wed, 3 Jun 2020 15:23:05 +0000 (UTC) Message-ID: <6f090fd58272b1daceae95eb4ff27c1d2e6494c5.camel@suse.com> Subject: Re: [Xen-devel] [RFC 1/9] schedule: Introduce per-pcpu time accounting From: Dario Faggioli To: Volodymyr Babchuk , "george.dunlap@eu.citrix.com" , "julien.grall@arm.com" , "xen-devel@lists.xenproject.org" Date: Wed, 03 Jun 2020 17:22:59 +0200 In-Reply-To: <061528bf93664a3ca00fce5d4bd3c585af1282e9.camel@epam.com> References: <1568197942-15374-1-git-send-email-andrii.anisov@gmail.com> <1568197942-15374-2-git-send-email-andrii.anisov@gmail.com> <8c74cacb-ff73-eddc-626c-f6fa862cf5a6@arm.com> <0e46fc4b29b7c3b3e6b4ca4704b9e7dac5738868.camel@epam.com> <6fcdb69457e5768b0fa2259f83a23158e9c939f5.camel@suse.com> <061528bf93664a3ca00fce5d4bd3c585af1282e9.camel@epam.com> Organization: SUSE Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-boRCyQDAoLs8jWz6/Fgf" User-Agent: Evolution 3.36.2 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "konrad.wilk@oracle.com" , "ian.jackson@eu.citrix.com" , "tim@xen.org" , "jbeulich@suse.com" , "andrew.cooper3@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --=-boRCyQDAoLs8jWz6/Fgf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2020-06-02 at 01:12 +0000, Volodymyr Babchuk wrote: > On Fri, 2020-05-29 at 10:48 +0200, Dario Faggioli wrote: > >=20 > Actually, I tried to not only rebase this patch series to the current > mainline, but also to add x86 support. This gave me deeper > unsterstanding of the inner workings. At least I hope so :) >=20 Right. > Anyways, I want to discuss the matter before continuing reworking the > patches. The goal of those patches is to account guest time more > precisely.=20 >=20 Yes, I agree. IIRC, the patches are doing more than that, e.g., discriminating between the runtime of the idle vCPUs and the time during which the CPUs were actually idle, and even trying to classify somehow what the hypervisor was actually doing (guest sync, etc). But, indeed, I would very much start with the one yous stated above, as a goal. > Right now I can see only two main reasons, when guest can be charged > for a time it dindn't used: interrupts and soft irqs.=20 >=20 > - do_softirq() is called every time we leave hypervisor mode. It is > used to do housekeeping for the hypervisor itself. But, some random > guest will charged for time spent in do_softirq() unless this > function > is not called on a idle vcpu. >=20 > - also, pCPU can be interrupted by IRQ assigned to some other guest > or > to hypervisor itself. But time spent in interrupt handler will be > charged for a guest being interrupted. >=20 I think those are the ones, yes. > So, basically, to account guest time correctly, we need to substract > time spent in do_softirq() and in do_IRQ().=20 >=20 That's how I'd try to do this, if it were me doing it. > Actually, we can charge the correct guest for time spent in do_IRQ(), > because handler code will eventually know target vCPU for the > interrupt. There is technical problem with interrupt nesting. We will > need some stack to track nesting correctly. But this is doable. >=20 Yes, there's this, and maybe a few other "dependencies" that we may discuss about, and try to track and account for, for even greather fairness. But maybe this can come as a second step? > Just for statistical purposes we can track hypervisor time somwhere, > but it is not needed for scheduling decisions. >=20 What we need is, I think, a way to tell the used/admin that that time is being spent in the hypervisor. E.g., if we were spending (let's exaggerate) 20% of the time processing interrupts and softirqs, the user would see some of this 20% load coming from each guest. It certainly wasn't ideal, but we do not want for such 20% to suddenly vanish either. > Am I missing something? > To me, it seems you're not. :-) Regards --=20 Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <> (Raistlin Majere) --=-boRCyQDAoLs8jWz6/Fgf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl7XwFMACgkQFkJ4iaW4 c+7q5w/9HVCMnBwn9QhwUbdraYKesML82Aps2WpbgWx2SdATI6IH5TKEp/xHI5uo /bQDt0DJKLMRfenlNcpS3rhbI/xgzAvo0vVJr8r+ZOVb+chjwOWb9jPjp18kXArW u92/DTl44duad+ZfuyG8VSr4FucDnvL7xWHFInRMYMwxuXE0nYwbgdqQ6WAwIId4 /7lX3rKXAfTwYvq397Qxo/14wgDpSsTEsln+xpPscQEBSwbbF2P+bN+kc172y6ZB wQzAo39nTxOyMAmhTWW/fqpMsKY9Lk3uFxHsQW1nu4JnPjTiC3l4oz48pF1fFf+K VaagEtFmhuF30J2CEu2zENEtQF8jVQGV0FbkVFy0e3ujNDn/t5Q4FAko7aCV7DTA LhFvE8pm2jdG9RxHXxnWHwprRliOnoYjiC+uR9gtHIZjxv+ZjVpVxuL/ome92GW5 xL+eQl0npwisNa3P7V/d+tcyKzvv5qghLWnSPG2DpozXoJqJU6WfubwIEe0xWmrQ xBeGk7v7IikXUrj22pGn8IBdlrLpvw39eVZF6XBzuoHT37MGJheVMED7ZjSU1YS0 6YMYSC9+t0eUXF5hCyS1ujVMUChkvrZeCQS8hCLzQb3jgpF9nCwSis0odcFuCkjS TTXMyDwDldxe7oTCAhX/anyNCNY64Dcl4WkQdy9SHJNOLvNSIG0= =ZgGZ -----END PGP SIGNATURE----- --=-boRCyQDAoLs8jWz6/Fgf-- From xen-devel-bounces@lists.xenproject.org Wed Jun 03 15:27:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 15:27:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVIP-00018y-4H; Wed, 03 Jun 2020 15:27:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVIN-00018t-3l for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 15:27:11 +0000 X-Inumbo-ID: b041b22b-a5ae-11ea-ad4a-12813bfff9fa Received: from mail-lj1-f194.google.com (unknown [209.85.208.194]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b041b22b-a5ae-11ea-ad4a-12813bfff9fa; Wed, 03 Jun 2020 15:27:09 +0000 (UTC) Received: by mail-lj1-f194.google.com with SMTP id y11so1624289ljm.9 for ; Wed, 03 Jun 2020 08:27:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=TI71EQkgRiykB9cwyrszJwVo6ai3Du0dG7EYNU5AcZI=; b=aztgwI5ND/gKIXZrIKxfgotansGLpy+RY0QTPJxtCD3DxXGAvMWu1yrNRnXZOT6DcQ ZGSQaCwfbHGHQ0kX+DvyAGcmxnVMvnzd5mTtOWjfstdNXUYKqhYlPIXIGiE80ksx8Q2F 3nGMqjJ98ilqDR/F4gfML0m3xzJ5IYuJyELEt6n6je0Dj0TB4DYVcadMdvD+52UTXwE6 QBOfH4n361svG+ZTV8XJG1J/4SSz4yrPTHQV6lIpdqUf5gZOTizwzQMh9q30pASvkPgq 0N2a05zGyt5qAqS28cCJZfNM/1W431RReeMGxUrb5eLf3uvBMd+vGCjleDxcCQIwpGS4 Vklw== X-Gm-Message-State: AOAM532sEq9FNyB3V5Yqo1JxXIXHmtc5cOtHC+DfWmfOWORlloPH28Dn Lr8FGgUakPgNmSFQjfOimOw= X-Google-Smtp-Source: ABdhPJwfYTS9uPM/HnqTboQLV6Ltg2RwfZqWlLMLltkoaHufYDdfd//e3kI/YThjJUvVF6uDszv/jw== X-Received: by 2002:a2e:b8ce:: with SMTP id s14mr2196638ljp.89.1591198028574; Wed, 03 Jun 2020 08:27:08 -0700 (PDT) Received: from localhost.localdomain (broadband-37-110-38-130.ip.moscow.rt.ru. [37.110.38.130]) by smtp.googlemail.com with ESMTPSA id e21sm631714ljb.135.2020.06.03.08.27.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 08:27:07 -0700 (PDT) From: Denis Efremov To: "David S. Miller" Subject: [PATCH] xen-netback: use kstrdup() in connect_data_rings() Date: Wed, 3 Jun 2020 18:26:43 +0300 Message-Id: <20200603152643.18215-1-efremov@linux.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Wei Liu , linux-kernel@vger.kernel.org, Denis Efremov , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Use kstrdup() instead of opencoded alloc and copy. kzalloc() is excessive here. Signed-off-by: Denis Efremov --- drivers/net/xen-netback/xenbus.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 286054b60d47..69352154a51b 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -839,13 +839,12 @@ static int connect_data_rings(struct backend_info *be, * queue-N. */ if (num_queues == 1) { - xspath = kzalloc(strlen(dev->otherend) + 1, GFP_KERNEL); + xspath = kstrdup(dev->otherend, GFP_KERNEL); if (!xspath) { xenbus_dev_fatal(dev, -ENOMEM, "reading ring references"); return -ENOMEM; } - strcpy(xspath, dev->otherend); } else { xspathsize = strlen(dev->otherend) + xenstore_path_ext_size; xspath = kzalloc(xspathsize, GFP_KERNEL); -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 15:29:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 15:29:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVKW-0001Fr-Hh; Wed, 03 Jun 2020 15:29:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVKV-0001Fm-Ik for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 15:29:23 +0000 X-Inumbo-ID: 000b88f8-a5af-11ea-9947-bc764e2007e4 Received: from mail-oi1-x241.google.com (unknown [2607:f8b0:4864:20::241]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 000b88f8-a5af-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 15:29:22 +0000 (UTC) Received: by mail-oi1-x241.google.com with SMTP id x202so2137752oix.11 for ; Wed, 03 Jun 2020 08:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:reply-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=xnAZW8Hcs0EBvLh2XT6BI1/B/SOSnuCqGjNo31qBRqA=; b=uhAsCM5DRqzK2H/ZlNZUANO5IObmtrlHcQROWLCswPX1jqb9/ZcOwYRaJoZRqWsGu3 6ozscz+GREokNWqZbcVphFTrCITCvdZOEvA7i33umvUfDLAJVoD4FW4oUktRbq/NF8e4 tJLfz59DnS4UwMigVJU1qHATwpmKbdLbByjRZ3WUTQGTGJdDi1WGxMZAiusKIWAvFALN IWQb71k80iPkcKWWUTNH6tU+w2NlFSZhcZGCXtingOU+ov7wZRfLUQ6/9r5Ashbu2Pbm /c4+wrIsOEnFpObMGC5Gn31OHqT0BzoTryzB96HyTK5KzfoZXz4/1MFIl1q16fOny9Ul Z/Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :reply-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=xnAZW8Hcs0EBvLh2XT6BI1/B/SOSnuCqGjNo31qBRqA=; b=mZT8kI668gUcdGFHQt/VFKD9Fne1h34ZXUBhg8txICTJc1rzJG3YkFeRCGFCIiuAdo 1kqydR7ESOJPbab6HYvUk+ad3uZieN/NNj5GsndB3yb33JDTfPXdr9aqc6yRthlQvfjP Ait5+coHBUwJ6U/VPBhU7YKplI30n9pD1MHhf87AEETDD/mKCx4I0osjhydczj2LDKET v8EBeXAuuIrX6DtbPpkQOArYpHSjRGRZcOLJQDCXlfQh2B+0AG4WftwPKdd9vy3bUprC 1orOUJV+cQZdL/rZlJiZCtphOM++a2lB4Sg4Q13R9id9GrHVmWcSTireidqEKQzlxfHB 697w== X-Gm-Message-State: AOAM53302aMyelXgD+j5pSFI22U0nTdtA08EY+dEeq2tjY/qVCivbwbb Lh6NvZmgV0cnLeksqw48Zg== X-Google-Smtp-Source: ABdhPJwLU6Qm0QCv6BTBhGtToMQLZFTYPnXO+ZOcILCHQRthbTlo+szYAQmpggIZ8Qgkx+YBu39KAQ== X-Received: by 2002:aca:210a:: with SMTP id 10mr152772oiz.153.1591198157511; Wed, 03 Jun 2020 08:29:17 -0700 (PDT) Received: from serve.minyard.net ([47.184.146.204]) by smtp.gmail.com with ESMTPSA id v14sm264062oie.20.2020.06.03.08.29.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 08:29:16 -0700 (PDT) Received: from minyard.net (unknown [IPv6:2001:470:b8f6:1b:38b2:c4d3:8035:d79b]) by serve.minyard.net (Postfix) with ESMTPSA id 85184180044; Wed, 3 Jun 2020 15:29:15 +0000 (UTC) Date: Wed, 3 Jun 2020 10:29:14 -0500 From: Corey Minyard To: Stefano Stabellini Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU Message-ID: <20200603152914.GJ2880@minyard.net> References: <42253259-9663-67e8-117f-8ba631243585@xen.org> <20200602183420.GE2880@minyard.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: minyard@acm.org Cc: jgross@suse.com, Peng Fan , Julien Grall , roman@zededa.com, "jeff.kubascik@dornerworks.com" , Julien Grall , Nataliya Korovkina , "xen-devel@lists.xenproject.org" , boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote: > On Tue, 2 Jun 2020, Corey Minyard wrote: > > Snip > > > > > > > > > whether > > > > > > > this was already done: > > > > > > >      1) Does the kernel boot on baremetal (i.e without Xen)? This should > > > > > > > help > > > > > > > to confirm whether the bug is Xen is related. > > > > > > > > > > > > Yes it boots > > > > > > > > > > > > >      2) Swiotlb should not be necessary for basic dom0 boot on Arm. Did > > > > > > > you try > > > > > > > to disable it? This should help to confirm whether swiotlb is the > > > > > > > problem or > > > > > > > not. > > > > > > > > > > > > It boots disabling swiotlb-xen > > > > > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for dom0. So > > > > > this suggests swiotlb is doing some transformation on the DMA address. > > > > > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to assume > > > > > the DMA address space and CPU address space is the same. Is RPI using the > > > > > same address space? > > > > > > > > Another question, is the DMA request bounced? If so, are we sure the bounce > > > > buffer is in the first GB? > > > > > > Yes, it is. This is actually where we spent the last few days, and I > > > found another little related bug in the initialization of the > > > swiotlb-xen but now I am sure the memory is under 1GB (0x34000000-0x38000000) > > > > Was anything ever resolved on this issue? It just kind of ended for me, > > and I looked in the main kernel and didn't find anything that looked > > related. > > Yes, we have a patch series on the list for the Linux kernel to fix this > issue but it hasn't been merged yet: > > https://marc.info/?l=linux-kernel&m=159001831406263&w=2 Just FYI, I pulled the changes on top of https://github.com/raspberrypi/linux.git rpi-5.4.y Along with change 56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_* before the series so it applies on 5.4, and I was able to boot and create a domU. So: Tested-by: Corey Minyard At least on 5.4. If you think it would be valuable, I can test on rpi-5.7.y. I'll be integrating this in with our Pi Xen yocto layer at https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen Thanks again, -corey From xen-devel-bounces@lists.xenproject.org Wed Jun 03 15:30:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 15:30:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVLo-000247-CU; Wed, 03 Jun 2020 15:30:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVLm-00023s-R4 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 15:30:42 +0000 X-Inumbo-ID: 2c72665a-a5af-11ea-9947-bc764e2007e4 Received: from mail-qt1-x843.google.com (unknown [2607:f8b0:4864:20::843]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2c72665a-a5af-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 15:30:37 +0000 (UTC) Received: by mail-qt1-x843.google.com with SMTP id c12so2344091qtq.11; Wed, 03 Jun 2020 08:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=14Oc4IIbH5lfOi6aqd01Xj+O/vzK1lMBVdL+M+b9qEo=; b=AeP1muxBvJ8Ah5fjIx/lOzHsPS2dY52HDYR9P4MMr2BX3Y9MpXeDPxThi0V2HfxHwg 8K00mTUYj/D4BsSNp8yNoRcfC9gEA8IZkBxCrb0Kwu9T27RRcL3n8bjm2WUbdnrpBes9 NGhv5Ei8bEUZsdZAK92A9+hMgCl+emMyKa5pIRnIjKz2dFZLrI5jh63XuZyJbxFY+EJJ uu4KliNUkxLdUQU3W3+0yRDVdBNg0Q2ryDAnvA7BJlmuPkFvh0Ol3NavDhrIRF2WIWK7 g+uwRKp0MXYOHW7zDqIKqTuhSWSSSokbZDx4/OzM+7QzqgCOCL25byJHIJKFCOBj0jsC 6bVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=14Oc4IIbH5lfOi6aqd01Xj+O/vzK1lMBVdL+M+b9qEo=; b=EYs2dR+GZbqhyPqUpMR19waCBLgjEfCK3ezPqJZJAIS0K68Y6WRhVojQKk0IqnkdwU 4+emLGy8FVdrUoAgc1fBkn8YE0Y1KygSulMxuGmVTtqpjhu57RJRxonIA7ywwEGP9bBN JyGuGcYsYKSiFKfSF9udPHsMqsMfBMaqZcET4BLSWYAnf4yDSWzIPnF1gxF0X/32mu8Q Rec1LHRStfzoTjnisH80vwyIqr+7tqowiSV8mmByzQ016rsOC33zvxglFEASw+XvYusF YVxeJii1NPDO+fZQaDTHC9ew6F/aSa4I1Jgsr0BnXeslpP3ObhNaEMhbBNFi8LASCFP5 WA1A== X-Gm-Message-State: AOAM532Dc53nbRp1EIPUl/6YR29Iet1Hpzuzayh7I+7J5KwqleinYZ+B CRdvfOtY5VyuX+4ZocgdYSfCq8GuZbfAJaoV+hbKU1Py X-Google-Smtp-Source: ABdhPJyNSWpPY64RY+qSK3E7xvi3A2r1Klf5W2PdU1VHfuLglYenpIkfs6+2+QK8vHkLyipsx224MnDjGRijQuxY5mo= X-Received: by 2002:ac8:5148:: with SMTP id h8mr31684113qtn.316.1591198236813; Wed, 03 Jun 2020 08:30:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Glen Date: Wed, 3 Jun 2020 08:30:23 -0700 Message-ID: Subject: Re: [Xen-users] xen domU stall on 4.12.1 To: Tomas Mozes Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Tomas - On Tue, Jun 2, 2020 at 7:43 PM Tomas Mozes wrote: >> On Mon, Feb 24, 2020 at 4:55 PM Glen wrote: >>> I'm now going to bring one of the previously-live guests on its own >>> host back to credit2 so I can crash it and try to capture debugging >>> output for xen-devel as requested. But sched=credit is definitely >>> what we needed to solve this problem! Thank you all for helping us >>> get there! > Just tested Xen 4.12.3, but a domU hanged again with credit2. It works rock solid with credit1. I have several hosts back on credit2, no problems so far. But the bulk of my production hosts are still on credit1, and they do seem to run "better" (subjectively, looking at responsiveness and load averages) but of course by subjectively I mean that I have no real data to back this feeling. I was hoping one of my domU's on credit2 would crash so I could grab debugging info for the development team - I hope you are/were able to grab and submit data on that crash??? Glen From xen-devel-bounces@lists.xenproject.org Wed Jun 03 15:37:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 15:37:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVS6-0002Xb-2Y; Wed, 03 Jun 2020 15:37:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVS4-0002XW-6Y for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 15:37:12 +0000 X-Inumbo-ID: 172a2c5a-a5b0-11ea-ad4f-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 172a2c5a-a5b0-11ea-ad4f-12813bfff9fa; Wed, 03 Jun 2020 15:37:11 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 46ADA20679; Wed, 3 Jun 2020 15:37:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591198630; bh=qMrrpXKqDomN/H9XypBdOxNN+kTZteJOVlUEUDdt0Bs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=00ilQPtQMJCCZMfdLU0AypaH0oAU8L/iH2sXRkmS03kJQOGsokmxcBRsC1LU7LnbG NznBp81SdxV6A+LY3z209EFJZ0oBlL6yg57pmmizOJgWkGlYfopkRHJUAc9D42B8Up dQ8jwKW6w7S72MMa5VMkXuW/kB3xjoVVq+dzoT3Y= Date: Wed, 3 Jun 2020 08:37:09 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Corey Minyard Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU In-Reply-To: <20200603152914.GJ2880@minyard.net> Message-ID: References: <42253259-9663-67e8-117f-8ba631243585@xen.org> <20200602183420.GE2880@minyard.net> <20200603152914.GJ2880@minyard.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1675369806-1591198630=:6774" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Peng Fan , Stefano Stabellini , Julien Grall , roman@zededa.com, "jeff.kubascik@dornerworks.com" , Julien Grall , Nataliya Korovkina , "xen-devel@lists.xenproject.org" , boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1675369806-1591198630=:6774 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 3 Jun 2020, Corey Minyard wrote: > On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote: > > On Tue, 2 Jun 2020, Corey Minyard wrote: > > > Snip > > > > > > > > > > > whether > > > > > > > > this was already done: > > > > > > > >      1) Does the kernel boot on baremetal (i.e without Xen)? This should > > > > > > > > help > > > > > > > > to confirm whether the bug is Xen is related. > > > > > > > > > > > > > > Yes it boots > > > > > > > > > > > > > > >      2) Swiotlb should not be necessary for basic dom0 boot on Arm. Did > > > > > > > > you try > > > > > > > > to disable it? This should help to confirm whether swiotlb is the > > > > > > > > problem or > > > > > > > > not. > > > > > > > > > > > > > > It boots disabling swiotlb-xen > > > > > > > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for dom0. So > > > > > > this suggests swiotlb is doing some transformation on the DMA address. > > > > > > > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to assume > > > > > > the DMA address space and CPU address space is the same. Is RPI using the > > > > > > same address space? > > > > > > > > > > Another question, is the DMA request bounced? If so, are we sure the bounce > > > > > buffer is in the first GB? > > > > > > > > Yes, it is. This is actually where we spent the last few days, and I > > > > found another little related bug in the initialization of the > > > > swiotlb-xen but now I am sure the memory is under 1GB (0x34000000-0x38000000) > > > > > > Was anything ever resolved on this issue? It just kind of ended for me, > > > and I looked in the main kernel and didn't find anything that looked > > > related. > > > > Yes, we have a patch series on the list for the Linux kernel to fix this > > issue but it hasn't been merged yet: > > > > https://marc.info/?l=linux-kernel&m=159001831406263&w=2 > > Just FYI, I pulled the changes on top of > https://github.com/raspberrypi/linux.git rpi-5.4.y > Along with change > 56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_* > before the series so it applies on 5.4, and I was able to boot and > create a domU. So: > > Tested-by: Corey Minyard > > At least on 5.4. If you think it would be valuable, I can test on > rpi-5.7.y. I'd feel better adding your Tested-by to my next upstream submission of the series if you could also test on 5.7. Thank you in advance! > I'll be integrating this in with our Pi Xen yocto layer at > https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen That's great! --8323329-1675369806-1591198630=:6774-- From xen-devel-bounces@lists.xenproject.org Wed Jun 03 15:41:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 15:41:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVWF-0003XS-M0; Wed, 03 Jun 2020 15:41:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVWE-0003XG-T0 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 15:41:30 +0000 X-Inumbo-ID: b127a288-a5b0-11ea-81bc-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b127a288-a5b0-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 15:41:29 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: HzwGjKx+1VFbfjfukQbA0u95ffo7kBAZKRM/7XcCYhmfkR0U39ZnP7ShlcIIZgRT3+yaaVm8Cd JQqJS2wYUu/mTXrK+itLJECG9UMA3Rm9oSIok/qbgLajNYgBBF8L77padSKSWd0n12hP92Wo5y RJCzDQkMkxtAYTdF3uXg4bciLqV4929udvMGsyRU53Css9N0gcD0NdmSm6kX3/E95seeDthHof l1ywAvrQWpVKGV9z2MbznP0b4hseRrK3U7jFYiNrEgoUh+QNWFckLg4Ia0IxxSLUSPt6vKrh7y CHo= X-SBRS: 2.7 X-MesageID: 19387777 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,468,1583211600"; d="scan'208";a="19387777" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24279.50340.497516.299188@mariner.uk.xensource.com> Date: Wed, 3 Jun 2020 16:41:24 +0100 To: Pavel Hrdina Subject: Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update) In-Reply-To: <20200603142117.GD11390@antique-laptop> References: <20200602154745.15054-1-ian.jackson@eu.citrix.com> <20200603142117.GD11390@antique-laptop> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: libvir-list@redhat.com, xen-devel@lists.xenproject.org, George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Pavel Hrdina writes ("Re: [PATCH] autogen.sh: Restore --no-git (avoid git submodule update)"): > On Tue, Jun 02, 2020 at 04:47:45PM +0100, Ian Jackson wrote: > > -git submodule update --init || exit 1 > > +if [ "x$1" = x--no-git ]; then > > + shift > > +else > > + git submodule update --init || exit 1 > > I changed the TAB into spaces. Ah, sorry for not following the right style. > Reviewed-by: Pavel Hrdina > > and pushed. Thanks :-). Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 15:52:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 15:52:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVh6-0004eu-Ob; Wed, 03 Jun 2020 15:52:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVh5-0004ep-7V for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 15:52:43 +0000 X-Inumbo-ID: 41bf58ee-a5b2-11ea-ad55-12813bfff9fa Received: from mail-wm1-f68.google.com (unknown [209.85.128.68]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 41bf58ee-a5b2-11ea-ad55-12813bfff9fa; Wed, 03 Jun 2020 15:52:41 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id f185so2629086wmf.3 for ; Wed, 03 Jun 2020 08:52:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=GshwwJK66k7h/1UU+52GCjHZuAKqpljzNfx76xeZPt4=; b=enT8HCI9OMw2joljmRdGfAU788Emf5KObjrcpW8S7gDnaIfPCHFuvTy86QFHevtnhJ mWCLqL8qg1Akkip8oKdD9QdyMVjdBMeMmui/QyK2NlLgxBCoUu4Z9FBZGNtvaJJrVwAP tS3uC/gQ6busJ8VPjAIX+NXCMNphEi0h1hMg51/OW1TomNkB7Zu5yEB5J38XJ7LfspMl VDDh815+Whli7U37bmUxB6BtGli9jr3qRLa5+WRJoRdSO7OOT7jVHt67jJEMQizSsDIr tH/EpArN1iyBw0q+2R4o3y1bVqV/4ccupDAPksfj3Eqd1xH9wj41qH6pafde8Y21/AUT mUzA== X-Gm-Message-State: AOAM531ouwqzV3GBCjFYJEqB6EjJIA0Q0/8eFxKbrZI6KlkbTTL5xLKl 2gZJ5hy8gOu0BEJPWKdaHvk= X-Google-Smtp-Source: ABdhPJy45eTUcvKlAMQ1mw383qBdgAbYNBqftkPcf5LN6qB0nnXU+RkkQ6r2u0ExFdKJmaCb6WDfng== X-Received: by 2002:a7b:cd10:: with SMTP id f16mr9537000wmj.149.1591199531131; Wed, 03 Jun 2020 08:52:11 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id q4sm3439264wma.47.2020.06.03.08.52.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 08:52:10 -0700 (PDT) Date: Wed, 3 Jun 2020 15:52:08 +0000 From: Wei Liu To: Denis Efremov Subject: Re: [PATCH] xen-netback: use kstrdup() in connect_data_rings() Message-ID: <20200603155208.qmko4nd5on76k7c4@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> References: <20200603152643.18215-1-efremov@linux.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603152643.18215-1-efremov@linux.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Wei Liu , "David S. Miller" , linux-kernel@vger.kernel.org, Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 06:26:43PM +0300, Denis Efremov wrote: > Use kstrdup() instead of opencoded alloc and copy. kzalloc() is > excessive here. > > Signed-off-by: Denis Efremov Acked-by: Wei Liu > --- > drivers/net/xen-netback/xenbus.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c > index 286054b60d47..69352154a51b 100644 > --- a/drivers/net/xen-netback/xenbus.c > +++ b/drivers/net/xen-netback/xenbus.c > @@ -839,13 +839,12 @@ static int connect_data_rings(struct backend_info *be, > * queue-N. > */ > if (num_queues == 1) { > - xspath = kzalloc(strlen(dev->otherend) + 1, GFP_KERNEL); > + xspath = kstrdup(dev->otherend, GFP_KERNEL); > if (!xspath) { > xenbus_dev_fatal(dev, -ENOMEM, > "reading ring references"); > return -ENOMEM; > } > - strcpy(xspath, dev->otherend); > } else { > xspathsize = strlen(dev->otherend) + xenstore_path_ext_size; > xspath = kzalloc(xspathsize, GFP_KERNEL); > -- > 2.26.2 > From xen-devel-bounces@lists.xenproject.org Wed Jun 03 15:55:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 15:55:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVjL-0004ls-5l; Wed, 03 Jun 2020 15:55:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVjJ-0004lk-K8 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 15:55:01 +0000 X-Inumbo-ID: 909ba31e-a5b2-11ea-ad55-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 909ba31e-a5b2-11ea-ad55-12813bfff9fa; Wed, 03 Jun 2020 15:54:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8FmIhavsb7LtY5tEbY1ggkgDVkzYoNUwMvFtNdS1NaI=; b=aNvr6ZhZCeCU646R/18JeE+6H iA1ZSKhAMFysJriUJqzjATLfx6t9MPWzUEAVWuyAUgJ/gy3m5W5H27S8XpGOM4TptmcQq/QTF5R8F cOr7gRf8b2YTfVZDi6eS6YfwWatAPVXuECd+4LOYKJYPPpbZPhJKiKpUyEqs5fDTdme3E=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVjB-0008HS-3X; Wed, 03 Jun 2020 15:54:53 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgVjA-0005RD-RI; Wed, 03 Jun 2020 15:54:52 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgVjA-0004FS-Qj; Wed, 03 Jun 2020 15:54:52 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150649: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d9f58cd54fe2f05e1f05e2fe254684bd1840de8e X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Wed, 03 Jun 2020 15:54:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150649 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150649/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d9f58cd54fe2f05e1f05e2fe254684bd1840de8e baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 6 days Failing since 150465 2020-05-29 09:02:14 Z 5 days 39 attempts Testing same since 150649 2020-06-03 13:01:44 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1522 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 16:05:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 16:05:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVsq-0006OJ-42; Wed, 03 Jun 2020 16:04:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgVso-0006OE-Ld for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 16:04:50 +0000 X-Inumbo-ID: f36bd8d2-a5b3-11ea-9947-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f36bd8d2-a5b3-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 16:04:49 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: iclSOewnqgMnEYbbuNZOrWgIki0MUWsRaG9w+d9ZEdBdU2pNLfDnytVvDhdvgBBZhAPGG+paFg AY+e3TVmPNe2G00vsJU9M4vl0KXn5UYtoq22C6YiYpWkBHTZjO0tmmDF9buWjcgViyifwacrd7 vXBYSHhzT26BbNF9ZsWLVcg4u5G6bX+NTocDLVXAbOCsxcNgfILfw6v/zk91Z0+cVfDyNKfbBk k/dMcjig/zOJYrzqqyqaEJPJKnMWTCGVSgZ0AIcOoTPqHbBIElMFD9VmmHSHCeLbc08R9PZdqE FoQ= X-SBRS: 2.7 X-MesageID: 19489761 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,468,1583211600"; d="scan'208";a="19489761" From: Anthony PERARD To: Subject: [PATCH v3] xen: fix build without pci passthrough Date: Wed, 3 Jun 2020 17:04:42 +0100 Message-ID: <20200603160442.3151170-1-anthony.perard@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Paul Durrant , Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony PERARD , Paolo Bonzini , Roger Pau Monne , Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Roger Pau Monne Xen PCI passthrough support may not be available and thus the global variable "has_igd_gfx_passthru" might be compiled out. Common code should not access it in that case. Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in xen-common.c so this patch instead move access to the has_igd_gfx_passthru variable via function and those functions are also implemented as stubs. The stubs will be used when QEMU is built without passthrough support. Now, when one will want to enable igd-passthru via the -machine property, they will get an error message if QEMU is built without passthrough support. Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator property') Reported-by: Roger Pau Monné Signed-off-by: Anthony PERARD --- Notes: Changes in v3: - reworked to use stubs instead of #ifdef CONFIG_XEN_PCI_PASSTHROUGH CONFIG_XEN_PCI_PASSTHROUGH isn't available in xen-common.c moving CONFIG_XEN_PCI_PASSTHROUGH to be in config_host_mak isn't really possible, or at least I didn't managed to make that work. hw/i386/pc_piix.c | 2 +- hw/xen/xen-common.c | 4 ++-- hw/xen/xen_pt.c | 12 +++++++++++- hw/xen/xen_pt.h | 6 ++++-- stubs/Makefile.objs | 1 + stubs/xen-pt.c | 22 ++++++++++++++++++++++ 6 files changed, 41 insertions(+), 6 deletions(-) create mode 100644 stubs/xen-pt.c diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index f66e1d73ce0b..347fb8c6c807 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -375,7 +375,7 @@ static void pc_init_isa(MachineState *machine) #ifdef CONFIG_XEN static void pc_xen_hvm_init_pci(MachineState *machine) { - const char *pci_type = has_igd_gfx_passthru ? + const char *pci_type = xen_igd_gfx_pt_enabled() ? TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : TYPE_I440FX_PCI_DEVICE; pc_init1(machine, diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c index 70564cc952d5..dd2c22cc4c0b 100644 --- a/hw/xen/xen-common.c +++ b/hw/xen/xen-common.c @@ -129,12 +129,12 @@ static void xen_change_state_handler(void *opaque, int running, static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp) { - return has_igd_gfx_passthru; + return xen_igd_gfx_pt_enabled(); } static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error **errp) { - has_igd_gfx_passthru = value; + xen_igd_gfx_pt_set(value, errp); } static void xen_setup_post(MachineState *ms, AccelState *accel) diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index 81d5ad8da7f0..ab84443d5ec8 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -65,7 +65,17 @@ #include "qemu/range.h" #include "exec/address-spaces.h" -bool has_igd_gfx_passthru; +static bool has_igd_gfx_passthru; + +bool xen_igd_gfx_pt_enabled(void) +{ + return has_igd_gfx_passthru; +} + +void xen_igd_gfx_pt_set(bool value, Error **errp) +{ + has_igd_gfx_passthru = value; +} #define XEN_PT_NR_IRQS (256) static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0}; diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h index 179775db7b22..6e9cec95f3b7 100644 --- a/hw/xen/xen_pt.h +++ b/hw/xen/xen_pt.h @@ -5,6 +5,9 @@ #include "hw/pci/pci.h" #include "xen-host-pci-device.h" +bool xen_igd_gfx_pt_enabled(void); +void xen_igd_gfx_pt_set(bool value, Error **errp); + void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3); #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a) @@ -322,10 +325,9 @@ extern void *pci_assign_dev_load_option_rom(PCIDevice *dev, unsigned int domain, unsigned int bus, unsigned int slot, unsigned int function); -extern bool has_igd_gfx_passthru; static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev) { - return (has_igd_gfx_passthru + return (xen_igd_gfx_pt_enabled() && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA)); } int xen_pt_register_vga_regions(XenHostPCIDevice *dev); diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs index 6a9e3135e8f9..564527e00997 100644 --- a/stubs/Makefile.objs +++ b/stubs/Makefile.objs @@ -40,6 +40,7 @@ stub-obj-y += target-get-monitor-def.o stub-obj-y += vmgenid.o stub-obj-y += xen-common.o stub-obj-y += xen-hvm.o +stub-obj-y += xen-pt.o stub-obj-y += pci-host-piix.o stub-obj-y += ram-block.o stub-obj-y += ramfb.o diff --git a/stubs/xen-pt.c b/stubs/xen-pt.c new file mode 100644 index 000000000000..2d8cac8d54b9 --- /dev/null +++ b/stubs/xen-pt.c @@ -0,0 +1,22 @@ +/* + * Copyright (C) 2020 Citrix Systems UK Ltd. + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" +#include "hw/xen/xen_pt.h" +#include "qapi/error.h" + +bool xen_igd_gfx_pt_enabled(void) +{ + return false; +} + +void xen_igd_gfx_pt_set(bool value, Error **errp) +{ + if (value) { + error_setg(errp, "Xen PCI passthrough support not built in"); + } +} -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Jun 03 16:20:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 16:20:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgW7j-0008Bu-LI; Wed, 03 Jun 2020 16:20:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgW7i-0008Bp-Ar for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 16:20:14 +0000 X-Inumbo-ID: 1a20e920-a5b6-11ea-8993-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1a20e920-a5b6-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 16:20:13 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id p5so2990823wrw.9 for ; Wed, 03 Jun 2020 09:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=TYmMypin88PIgsNnuhnXSrwDk/qjEP7rFAeGHOmIs8Q=; b=nPEft3Fe8mDalSlOB167Wrd3voYsItlxlNMsQCNslyS0iWGtnMSzuCwAjX7MuZnbNw QOWq60mNplhziB9fwEPc9rJmIKy6zwrTCkwcA97B1jjJa6z5yYEC7h12eJ+t2R+AW3eB dmJmk5XtMQi1kTidorZvlmLH/urPKOjNC4+WxwPwYq/PXmgxe18e86mUshiXp0HWJS6v Wz3owSTA2Bqk5DKzZzToAq7jiqS6U7zZxeMxVXBtRNH/LBA2LTSmsYfm2iX89fZKTtAp IXevYq5K90MeilEobxKjY5xpP6k9NoTeMAAZr8DT4OBHekCxx90E6gi10EGfZW/pm+mA Q+Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=TYmMypin88PIgsNnuhnXSrwDk/qjEP7rFAeGHOmIs8Q=; b=iMiLbfw4s0orXfi9fxcGlHZjVACmnet1hlQ74Ccv0J2wkliKRZJXngQtbqOMQXSfc8 sE0L0GIhc23veDi5+7Qz68qQ7i1+1djw0lrD/6oMnscaLO70Gs2R7BdFLmLYwJGg+oUM 3kWuiLtKyLTbyQY4clhUyDCMI5sd3gy3Px0V7CuJUvEb6SGcaEx6r29JeLiDRvDnRHoy n5mUfInFdHYTVd8W/w+lOZlJSChbjeOMJhVWai9F8+btQZqm7CrU0XVKaHA3FZmxSoan bwYfxFMkvadHQcXcI9Pzz5rrSm/5x+hV6ZeVDIe1dd4y5HUTwpRtYjgUIgEKdkr02v+K lTYQ== X-Gm-Message-State: AOAM5325bFoNZzMFz7G/EdCzaq+GVvsujqgSzNHGBwzAqlw000DIjPgu KFQ36MtrLHvTJB7ElLRFzVk= X-Google-Smtp-Source: ABdhPJyW4/QzKyTUNOkL1Hgt3Um3mDrRl8mE0vNYIq+Nq1VgoKMEv7pquWeyiyDtboKE0jWn5oN9Zg== X-Received: by 2002:adf:e381:: with SMTP id e1mr233632wrm.320.1591201212565; Wed, 03 Jun 2020 09:20:12 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id j5sm3992708wrq.39.2020.06.03.09.20.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2020 09:20:11 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Anthony PERARD'" , References: <20200603160442.3151170-1-anthony.perard@citrix.com> In-Reply-To: <20200603160442.3151170-1-anthony.perard@citrix.com> Subject: RE: [PATCH v3] xen: fix build without pci passthrough Date: Wed, 3 Jun 2020 17:20:10 +0100 Message-ID: <005d01d639c2$db48d370$91da7a50$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGyQ6RA4n1W3DCtViLPILQo6PvvUKkO/R6w X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Eduardo Habkost' , "'Michael S. Tsirkin'" , 'Marcel Apfelbaum' , xen-devel@lists.xenproject.org, 'Paolo Bonzini' , 'Roger Pau Monne' , 'Richard Henderson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Anthony PERARD > Sent: 03 June 2020 17:05 > To: qemu-devel@nongnu.org > Cc: Anthony PERARD ; Roger Pau Monne = ; Michael S. > Tsirkin ; Marcel Apfelbaum = ; Paolo Bonzini > ; Richard Henderson ; Eduardo = Habkost ; > Stefano Stabellini ; Paul Durrant = ; xen- > devel@lists.xenproject.org > Subject: [PATCH v3] xen: fix build without pci passthrough >=20 > From: Roger Pau Monne >=20 > Xen PCI passthrough support may not be available and thus the global > variable "has_igd_gfx_passthru" might be compiled out. Common code > should not access it in that case. >=20 > Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in > xen-common.c so this patch instead move access to the > has_igd_gfx_passthru variable via function and those functions are > also implemented as stubs. The stubs will be used when QEMU is built > without passthrough support. >=20 > Now, when one will want to enable igd-passthru via the -machine > property, they will get an error message if QEMU is built without > passthrough support. >=20 > Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an = accelerator property') > Reported-by: Roger Pau Monn=C3=A9 > Signed-off-by: Anthony PERARD Acked-by: Paul Durrant > --- >=20 > Notes: > Changes in v3: > - reworked to use stubs instead of #ifdef = CONFIG_XEN_PCI_PASSTHROUGH > CONFIG_XEN_PCI_PASSTHROUGH isn't available in xen-common.c >=20 > moving CONFIG_XEN_PCI_PASSTHROUGH to be in config_host_mak isn't > really possible, or at least I didn't managed to make that work. >=20 > hw/i386/pc_piix.c | 2 +- > hw/xen/xen-common.c | 4 ++-- > hw/xen/xen_pt.c | 12 +++++++++++- > hw/xen/xen_pt.h | 6 ++++-- > stubs/Makefile.objs | 1 + > stubs/xen-pt.c | 22 ++++++++++++++++++++++ > 6 files changed, 41 insertions(+), 6 deletions(-) > create mode 100644 stubs/xen-pt.c >=20 > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > index f66e1d73ce0b..347fb8c6c807 100644 > --- a/hw/i386/pc_piix.c > +++ b/hw/i386/pc_piix.c > @@ -375,7 +375,7 @@ static void pc_init_isa(MachineState *machine) > #ifdef CONFIG_XEN > static void pc_xen_hvm_init_pci(MachineState *machine) > { > - const char *pci_type =3D has_igd_gfx_passthru ? > + const char *pci_type =3D xen_igd_gfx_pt_enabled() ? > TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : = TYPE_I440FX_PCI_DEVICE; >=20 > pc_init1(machine, > diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c > index 70564cc952d5..dd2c22cc4c0b 100644 > --- a/hw/xen/xen-common.c > +++ b/hw/xen/xen-common.c > @@ -129,12 +129,12 @@ static void xen_change_state_handler(void = *opaque, int running, >=20 > static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp) > { > - return has_igd_gfx_passthru; > + return xen_igd_gfx_pt_enabled(); > } >=20 > static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error = **errp) > { > - has_igd_gfx_passthru =3D value; > + xen_igd_gfx_pt_set(value, errp); > } >=20 > static void xen_setup_post(MachineState *ms, AccelState *accel) > diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c > index 81d5ad8da7f0..ab84443d5ec8 100644 > --- a/hw/xen/xen_pt.c > +++ b/hw/xen/xen_pt.c > @@ -65,7 +65,17 @@ > #include "qemu/range.h" > #include "exec/address-spaces.h" >=20 > -bool has_igd_gfx_passthru; > +static bool has_igd_gfx_passthru; > + > +bool xen_igd_gfx_pt_enabled(void) > +{ > + return has_igd_gfx_passthru; > +} > + > +void xen_igd_gfx_pt_set(bool value, Error **errp) > +{ > + has_igd_gfx_passthru =3D value; > +} >=20 > #define XEN_PT_NR_IRQS (256) > static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] =3D {0}; > diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h > index 179775db7b22..6e9cec95f3b7 100644 > --- a/hw/xen/xen_pt.h > +++ b/hw/xen/xen_pt.h > @@ -5,6 +5,9 @@ > #include "hw/pci/pci.h" > #include "xen-host-pci-device.h" >=20 > +bool xen_igd_gfx_pt_enabled(void); > +void xen_igd_gfx_pt_set(bool value, Error **errp); > + > void xen_pt_log(const PCIDevice *d, const char *f, ...) = GCC_FMT_ATTR(2, 3); >=20 > #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, = __func__, ##_a) > @@ -322,10 +325,9 @@ extern void = *pci_assign_dev_load_option_rom(PCIDevice *dev, > unsigned int domain, > unsigned int bus, = unsigned int slot, > unsigned int function); > -extern bool has_igd_gfx_passthru; > static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev) > { > - return (has_igd_gfx_passthru > + return (xen_igd_gfx_pt_enabled() > && ((dev->class_code >> 0x8) =3D=3D = PCI_CLASS_DISPLAY_VGA)); > } > int xen_pt_register_vga_regions(XenHostPCIDevice *dev); > diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs > index 6a9e3135e8f9..564527e00997 100644 > --- a/stubs/Makefile.objs > +++ b/stubs/Makefile.objs > @@ -40,6 +40,7 @@ stub-obj-y +=3D target-get-monitor-def.o > stub-obj-y +=3D vmgenid.o > stub-obj-y +=3D xen-common.o > stub-obj-y +=3D xen-hvm.o > +stub-obj-y +=3D xen-pt.o > stub-obj-y +=3D pci-host-piix.o > stub-obj-y +=3D ram-block.o > stub-obj-y +=3D ramfb.o > diff --git a/stubs/xen-pt.c b/stubs/xen-pt.c > new file mode 100644 > index 000000000000..2d8cac8d54b9 > --- /dev/null > +++ b/stubs/xen-pt.c > @@ -0,0 +1,22 @@ > +/* > + * Copyright (C) 2020 Citrix Systems UK Ltd. > + * > + * This work is licensed under the terms of the GNU GPL, version 2 or = later. > + * See the COPYING file in the top-level directory. > + */ > + > +#include "qemu/osdep.h" > +#include "hw/xen/xen_pt.h" > +#include "qapi/error.h" > + > +bool xen_igd_gfx_pt_enabled(void) > +{ > + return false; > +} > + > +void xen_igd_gfx_pt_set(bool value, Error **errp) > +{ > + if (value) { > + error_setg(errp, "Xen PCI passthrough support not built in"); > + } > +} > -- > Anthony PERARD From xen-devel-bounces@lists.xenproject.org Wed Jun 03 16:40:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 16:40:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWQk-0001AZ-C1; Wed, 03 Jun 2020 16:39:54 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWQi-0001AU-LI for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 16:39:52 +0000 X-Inumbo-ID: d4096838-a5b8-11ea-ad64-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d4096838-a5b8-11ea-ad64-12813bfff9fa; Wed, 03 Jun 2020 16:39:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eyv/IIPTseaLyNri/YMQDRTExD4+A+Z6okwkVhYNVXM=; b=OXK+uYcWivL7b23GrMRQwc0Hb WzhCradXFw/In5fojuOAeY0CHP3HsqTTIUWs+KiN8YrTPCCSv1L1Z4hVkoDY5KJ+7jtO0eMmETNPS EBTstoQZJAmhKCfJMuES1KwedktIY6q7El3tvxbQT6utlD9blwEhoSA/DPYMafM6zk5tQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWQZ-0001Kl-HO; Wed, 03 Jun 2020 16:39:43 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgWQY-0006ar-VB; Wed, 03 Jun 2020 16:39:43 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgWQY-0002B7-Tk; Wed, 03 Jun 2020 16:39:42 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 150642: trouble: broken/fail/pass X-Osstest-Failures: linux-5.4:test-amd64-i386-libvirt::broken:regression linux-5.4:test-amd64-i386-qemuu-rhel6hvm-amd::broken:regression linux-5.4:test-amd64-i386-libvirt:host-install(4):broken:regression linux-5.4:test-amd64-i386-qemuu-rhel6hvm-amd:host-install(4):broken:regression linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=55852b3fd146ce90d4d4306b467261f2c4869293 X-Osstest-Versions-That: linux=e0d81ce760044efd3f26004aa32821c34968512a From: osstest service owner Date: Wed, 03 Jun 2020 16:39:42 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150642 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/150642/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-i386-libvirt 4 host-install(4) broken REGR. vs. 150508 test-amd64-i386-qemuu-rhel6hvm-amd 4 host-install(4) broken REGR. vs. 150508 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150423 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150508 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 55852b3fd146ce90d4d4306b467261f2c4869293 baseline version: linux e0d81ce760044efd3f26004aa32821c34968512a Last test of basis 150508 2020-05-29 22:40:26 Z 4 days Testing same since 150642 2020-06-03 06:40:26 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: "Eric W. Biederman" Al Viro Alaa Hleihel Alan Stern Alex Deucher Alex Sierra Alexander Dahl Alexander Potapenko Alexei Starovoitov Amy Shih Andreas Gruenbacher Andrew Morton Andrew Oakley Andy Lutomirski Andy Shevchenko Antony Antony Arnaldo Carvalho de Melo Arnd Bergmann ASSOGBA Emery Bartosz Golaszewski Björn Töpel Bob Peterson Boris Sukholitko Borislav Petkov Brendan Shanks Changbin Du Changming Liu Chris Chiu Christian König Christophe JAILLET Chuhong Yuan Daniel Borkmann Dave Wysochanski David Ahern David Howells David S. Miller DENG Qingfang Denis V. Lunev Dennis Dalessandro Dennis YC Hsieh Dmitry Torokhov Doug Ledford Edward Cree Eran Ben Elisha Eric Dumazet Eric W. Biederman Evan Green Evan Quan Felipe Balbi Felix Kuehling Florian Fainelli Greg Kroah-Hartman Grygorii Strashko Guenter Roeck Guo Ren Hamish Martin Hans Verkuil Heiko Stuebner Helge Deller Hsin-Yi Wang Hugh Dickins Ian Ray Ido Schimmel Ilya Dryomov Jakub Kicinski Jamal Hadi Salim James Hilliard Jason Gunthorpe Jay Vosburgh Jeff Layton Jens Axboe Jere Leppänen Jerry Lee Jiri Olsa Jiri Pirko Joerg Roedel Johan Jonker Johannes Berg Johannes Weiner Jonathan Lemon Kaike Wan Kailang Yang Kees Cook Kefeng Wang Kevin Locke Kirill A. Shutemov Konstantin Khlebnikov Lei Xue Leon Romanovsky Linus Lüssing Linus Torvalds Linus Walleij Liu Yibin Madhuparna Bhowmik Manivannan Sadhasivam Mao Han Maor Gottlieb Marc Payne Marcelo Ricardo Leitner Martin KaFai Lau Masahiro Yamada Matteo Croce Matthias Brugger Michael Braun Michael Chan Moshe Shemesh Nathan Chancellor Neil Horman Nicolas Dichtel Nikolay Aleksandrov Pablo Neira Ayuso Palmer Dabbelt Paul Cercueil Peng Hao Phil Sutter Pradeep Kumar Chitrapu Qiushi Wu Robert Beckett Roi Dayan Roman Mashak Russell King Sabrina Dubroca Saeed Mahameed Sam Ravnborg Sasha Levin Sebastian Reichel Shaokun Zhang Shawn Guo Shay Drory Shiraz Saleem Simon Ser Song Liu Stefan Wahren Steffen Klassert Stephen Boyd Stephen Warren Stephen Worley Steve French Takashi Iwai Tariq Toukan Tero Kristo Tiezhu Yang Tony Lindgren Ulf Hansson Vadim Fedorenko Valentine Fatiev Vinay Kumar Yadav Vincent Stehlé Vinod Koul Vladimir Oltean Vlastimil Babka Wei Yongjun Xin Long Yonghong Song Yuqi Jin Łukasz Patron Łukasz Stelmach jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt broken test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-i386-libvirt broken broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken broken-step test-amd64-i386-libvirt host-install(4) broken-step test-amd64-i386-qemuu-rhel6hvm-amd host-install(4) Not pushing. (No revision log; it would be 4541 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 16:43:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 16:43:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWUD-00028Y-0v; Wed, 03 Jun 2020 16:43:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWUB-00028T-Sr for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 16:43:27 +0000 X-Inumbo-ID: 562dbed6-a5b9-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 562dbed6-a5b9-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 16:43:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=85NI97GHdoKjkfO5we6qMz1uo7X8fxNGUgDltHMrihU=; b=adpNz2FW2wgMZ8cmtR8gLwxdf uJih3BxMnGkqJrp3GfPwIjboWFNO9BvfJvZSKo4AoGr/1w8JKxcsnVLKGytIOB2byXGoI40n6C8US 0txxnxSKAtYS7lj+H6NzyPZgm4xkSPQyXXrwzcPaxo9FLWiIyJxupDB3nXXnurOrMNZsI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWU6-0001QC-06; Wed, 03 Jun 2020 16:43:22 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgWU5-0006gV-Mx; Wed, 03 Jun 2020 16:43:21 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgWU5-0003Yc-MH; Wed, 03 Jun 2020 16:43:21 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150653: all pass - PUSHED X-Osstest-Versions-This: ovmf=7191dd3c5990416cf473ce36b3fb84ecb2f7b950 X-Osstest-Versions-That: ovmf=ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 From: osstest service owner Date: Wed, 03 Jun 2020 16:43:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150653 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150653/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 7191dd3c5990416cf473ce36b3fb84ecb2f7b950 baseline version: ovmf ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 Last test of basis 150614 2020-06-02 08:10:08 Z 1 days Testing same since 150653 2020-06-03 14:09:17 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git ca407c7246..7191dd3c59 7191dd3c5990416cf473ce36b3fb84ecb2f7b950 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Wed Jun 03 16:51:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 16:51:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWcB-0003CQ-SJ; Wed, 03 Jun 2020 16:51:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWcA-0003CL-RZ for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 16:51:42 +0000 X-Inumbo-ID: 7fa57f0a-a5ba-11ea-ad67-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7fa57f0a-a5ba-11ea-ad67-12813bfff9fa; Wed, 03 Jun 2020 16:51:41 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 4decgFsKWVfn1fWOoLwMQVuM72S682hSoKwo8se4vZ+1DVD4ts/5dVGfITtwNzfl+5JVQGgS34 B79x6y2Nw2Vkal3x6wnsBCOQX3JfUHDOZZpaEEL4O5cTQa0XEmolumQ1UMkCaLdHy95vw67HOh IKuxQbsUto2Yk2AlzO+fGHE7jr6QcCnpiSfSSXpHBDLyt9YWCvxCDlL/GCcXBvTIjTNcPe3Jt5 HfoCkTjys8DX/p7u2o9orlu69ySp80ehc3kQyFaJOr7G5aZm/tp6wW48H3y8yeOljyNkZk3DkD SBw= X-SBRS: 2.7 X-MesageID: 19395688 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,468,1583211600"; d="scan'208";a="19395688" Date: Wed, 3 Jun 2020 18:51:34 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Anthony PERARD Subject: Re: [PATCH v3] xen: fix build without pci passthrough Message-ID: <20200603165134.GG1195@Air-de-Roger> References: <20200603160442.3151170-1-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200603160442.3151170-1-anthony.perard@citrix.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Paul Durrant , qemu-devel@nongnu.org, Marcel Apfelbaum , xen-devel@lists.xenproject.org, Paolo Bonzini , Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 05:04:42PM +0100, Anthony PERARD wrote: > From: Roger Pau Monne > > Xen PCI passthrough support may not be available and thus the global > variable "has_igd_gfx_passthru" might be compiled out. Common code > should not access it in that case. > > Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in > xen-common.c so this patch instead move access to the > has_igd_gfx_passthru variable via function and those functions are > also implemented as stubs. The stubs will be used when QEMU is built > without passthrough support. > > Now, when one will want to enable igd-passthru via the -machine > property, they will get an error message if QEMU is built without > passthrough support. > > Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator property') > Reported-by: Roger Pau Monné > Signed-off-by: Anthony PERARD Tested-by: Roger Pau Monné Fixes the build for me on FreeBSD without pci-passthrough. Thanks! From xen-devel-bounces@lists.xenproject.org Wed Jun 03 16:56:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 16:56:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWgy-0003Mq-RZ; Wed, 03 Jun 2020 16:56:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWgx-0003Ml-9R for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 16:56:39 +0000 X-Inumbo-ID: 2dcbdb9c-a5bb-11ea-81bc-bc764e2007e4 Received: from mail-qk1-x736.google.com (unknown [2607:f8b0:4864:20::736]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2dcbdb9c-a5bb-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 16:56:33 +0000 (UTC) Received: by mail-qk1-x736.google.com with SMTP id w1so2864338qkw.5; Wed, 03 Jun 2020 09:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lC+LcmDTqWh6iLD+2pjOV/lv74IVE5D+i7ERR9trLK8=; b=bddfWtgFvJwv9TfQtWQi1eI7fC8hIU20r42V3p/APxe332Yv8CABJZ5GPKsgH3Hyg9 3GxnH7r4CZz4Fm5EgvwyFaQV5nqKIl/+lIxt0WHVHszSIlEUgsSGgrN2EKdO22WAv8KX kZx2e4ZkJO2CnX9R7hAd2ijZZ+3yGKJcy1P/XQlxlUtl3cLPkq5JcVHiFxuAX/NUEFGm GYlZUXS2eWnTRsA7c5AKLePKpv8Xdb/MIGbnXyoEIMUJ08vq3fsnWOi+j76nwmww3fSF WLwXPYeVR0Ce4B1bBziymocgrv+lOpdxAY63vqPgSP6OBhF5ps5CdmF3xGGzYXbLJXUh jCjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lC+LcmDTqWh6iLD+2pjOV/lv74IVE5D+i7ERR9trLK8=; b=qGeg2aUYtJO8iVY4VqsduobZIc5/tlh1C9yognLLM+3lw1adj9gGH/uNiBQU4ljYSd CvqyGkjNgkQ5obo4SBGSMrMrx5nS0e+SjTvZyNitOT51HEkYTkHYFN1bQX+GZCOoEMG8 vB9rUjt1rSomxpZB700DIFMxjTnW8tWIz+qo4dMMNBSiqFyjoMCZgHzcHc/kgg6J7Qc1 bHx0WXf7auG5oOL6TxWTHTfcy71Yepo7GO13kOMCEZoYJXYV+YrVb/Q4eCUVX4gNXVRF 43p3Dk2p++mpwRIE4QdC6y2fS55ELPWKNiQKrgnt02JeHNZkLPcWIllfvcE2ilANOlG+ QpYQ== X-Gm-Message-State: AOAM531kNAcEV6tx0xi2g+/0AwHJeMDVLFCHijVtn7viCOraslCoLaz9 hKqR1tybW5wb7DBRB2UqKtTCWJwKa9abX2tRtnk= X-Google-Smtp-Source: ABdhPJxBMhu1IsrZsNhB0Ndr9iYzrI6ZmDyp1Dxt2IccgmEBTVIWdtgGHS+pkyh8YBCZ36HD62oiLGBokF9RGO4sK1o= X-Received: by 2002:a05:620a:210e:: with SMTP id l14mr549263qkl.242.1591203392929; Wed, 03 Jun 2020 09:56:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tomas Mozes Date: Wed, 3 Jun 2020 18:56:21 +0200 Message-ID: Subject: Re: [Xen-users] xen domU stall on 4.12.1 To: Glen Content-Type: multipart/alternative; boundary="00000000000000494a05a730e992" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --00000000000000494a05a730e992 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 3, 2020 at 5:30 PM Glen wrote: > Tomas - > > On Tue, Jun 2, 2020 at 7:43 PM Tomas Mozes wrote: > >> On Mon, Feb 24, 2020 at 4:55 PM Glen wrote: > >>> I'm now going to bring one of the previously-live guests on its own > >>> host back to credit2 so I can crash it and try to capture debugging > >>> output for xen-devel as requested. But sched=credit is definitely > >>> what we needed to solve this problem! Thank you all for helping us > >>> get there! > > Just tested Xen 4.12.3, but a domU hanged again with credit2. It works > rock solid with credit1. > > I have several hosts back on credit2, no problems so far. But the > bulk of my production hosts are still on credit1, and they do seem to > run "better" (subjectively, looking at responsiveness and load > averages) but of course by subjectively I mean that I have no real > data to back this feeling. > > I was hoping one of my domU's on credit2 would crash so I could grab > debugging info for the development team - I hope you are/were able to > grab and submit data on that crash??? > > Glen > Unfortunately no, it was one of my production hosts so I wanted to get it back working as quickly as possible. Tomas --00000000000000494a05a730e992 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 3, 2020 at 5:30 PM Glen &= lt;glenbarney@gmail.com> wro= te:
Tomas -

On Tue, Jun 2, 2020 at 7:43 PM Tomas Mozes <hydrapolic@gmail.com> wrote:
>> On Mon, Feb 24, 2020 at 4:55 PM Glen <glenbarney@gmail.com> wrote:
>>> I'm now going to bring one of the previously-live guests o= n its own
>>> host back to credit2 so I can crash it and try to capture debu= gging
>>> output for xen-devel as requested.=C2=A0 But sched=3Dcredit is= definitely
>>> what we needed to solve this problem!=C2=A0 Thank you all for = helping us
>>> get there!
> Just tested Xen 4.12.3, but a domU hanged again with credit2. It works= rock solid with credit1.

I have several hosts back on credit2, no problems so far.=C2=A0 But the
bulk of my production hosts are still on credit1, and they do seem to
run "better" (subjectively, looking at responsiveness and load averages) but of course by subjectively I mean that I have no real
data to back this feeling.

I was hoping one of my domU's on credit2 would crash so I could grab debugging info for the development team - I hope you are/were able to
grab and submit data on that crash???

Glen

Unfortunately no, it was one of my= production hosts so I wanted to get it back working as quickly as possible= .

Tomas

--00000000000000494a05a730e992-- From xen-devel-bounces@lists.xenproject.org Wed Jun 03 17:09:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 17:09:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWt0-0004iH-1H; Wed, 03 Jun 2020 17:09:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWsy-0004iB-7X for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 17:09:04 +0000 X-Inumbo-ID: ec1d692a-a5bc-11ea-81bc-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id ec1d692a-a5bc-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 17:09:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591204142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rS446/KGlPZUtACxgdHjhWpFjUqIoulxEPtmo1bYVf0=; b=NFkfD1y/1cjBscvec3lcAChFOdAToCC6gclyRgZKKQq6K2F623VNuW2fSp1l4xw16pI37/ YyajD2h1RxpnTzwKFWke7jPIPXScXf+OOjzr8WhABgK9a+dcxTZMW61g4ENPt/XV0B7fky keFKrp842tIic09fgajZMwbnMuTBSlM= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-399-NY8uc4IjMZuSSMc4ajEDUQ-1; Wed, 03 Jun 2020 13:09:00 -0400 X-MC-Unique: NY8uc4IjMZuSSMc4ajEDUQ-1 Received: by mail-wm1-f69.google.com with SMTP id t145so1105005wmt.2 for ; Wed, 03 Jun 2020 10:09:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rS446/KGlPZUtACxgdHjhWpFjUqIoulxEPtmo1bYVf0=; b=c65Ry72VaXhSG2wMKjY4a780gCZ4+Je9EIji4j3H9ClkxUrjl8TJw0Ncd/lvYMp1Xs IkxO4d/yfkfnW0RVzHBXInOIIJce8Y7yxClao7538UXVMi75sCgThXUCqARh/4Jt1jzm 3Sa6z9tSf0DGEb9gTVeo6yHr1aOQaqNcyG8pNXDmw4y9ywPnZacoJC7PiydPMJvPpPD7 HJNXxZcf2bn13vaSoac9f1Q77Zy10dUOS4n8wA5o9aHHffwVRWDi9PerAH2T2GHmXIL6 m7G9j9TRQHSx/JoSY9gUQxc8DOuqL2DkD5T582ks8Q0OdTexe5DWBNgH1VDVwVTucqmR JrtA== X-Gm-Message-State: AOAM530i2vknsAdW5q2apEatc0TYQOgshocBzBjS5qMSj92Lt2/mOUiC t7aGjZlo4plu5KY4CmpfAGSd2IIyMBuflMftbBx9iP9VGi0i0Jxg8hqZn2ypm1tHCLZaGL5Hh3q a3qXwFrBtc29VUFQ6Vn8IGTLBXks= X-Received: by 2002:a1c:a74f:: with SMTP id q76mr154438wme.65.1591204138900; Wed, 03 Jun 2020 10:08:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwkCPAEMXCpG0Na33VwxpLRawCgnRsNwVIi22brbtvYEWZ1vj1f5fkIdqzSEPamlLCfBJurw== X-Received: by 2002:a1c:a74f:: with SMTP id q76mr154409wme.65.1591204138545; Wed, 03 Jun 2020 10:08:58 -0700 (PDT) Received: from [192.168.178.58] ([151.20.243.176]) by smtp.gmail.com with ESMTPSA id j5sm4281911wrm.57.2020.06.03.10.08.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 10:08:57 -0700 (PDT) Subject: Re: [PATCH v3] xen: fix build without pci passthrough To: Anthony PERARD , qemu-devel@nongnu.org References: <20200603160442.3151170-1-anthony.perard@citrix.com> From: Paolo Bonzini Message-ID: <8bf5371c-713a-c9f4-fffb-4a2ddc50dd1b@redhat.com> Date: Wed, 3 Jun 2020 19:08:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200603160442.3151170-1-anthony.perard@citrix.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Paul Durrant , Marcel Apfelbaum , xen-devel@lists.xenproject.org, Roger Pau Monne , Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03/06/20 18:04, Anthony PERARD wrote: > From: Roger Pau Monne > > Xen PCI passthrough support may not be available and thus the global > variable "has_igd_gfx_passthru" might be compiled out. Common code > should not access it in that case. > > Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in > xen-common.c so this patch instead move access to the > has_igd_gfx_passthru variable via function and those functions are > also implemented as stubs. The stubs will be used when QEMU is built > without passthrough support. > > Now, when one will want to enable igd-passthru via the -machine > property, they will get an error message if QEMU is built without > passthrough support. > > Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator property') > Reported-by: Roger Pau Monné > Signed-off-by: Anthony PERARD > --- > > Notes: > Changes in v3: > - reworked to use stubs instead of #ifdef CONFIG_XEN_PCI_PASSTHROUGH > CONFIG_XEN_PCI_PASSTHROUGH isn't available in xen-common.c > > moving CONFIG_XEN_PCI_PASSTHROUGH to be in config_host_mak isn't > really possible, or at least I didn't managed to make that work. > > hw/i386/pc_piix.c | 2 +- > hw/xen/xen-common.c | 4 ++-- > hw/xen/xen_pt.c | 12 +++++++++++- > hw/xen/xen_pt.h | 6 ++++-- > stubs/Makefile.objs | 1 + > stubs/xen-pt.c | 22 ++++++++++++++++++++++ > 6 files changed, 41 insertions(+), 6 deletions(-) > create mode 100644 stubs/xen-pt.c > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > index f66e1d73ce0b..347fb8c6c807 100644 > --- a/hw/i386/pc_piix.c > +++ b/hw/i386/pc_piix.c > @@ -375,7 +375,7 @@ static void pc_init_isa(MachineState *machine) > #ifdef CONFIG_XEN > static void pc_xen_hvm_init_pci(MachineState *machine) > { > - const char *pci_type = has_igd_gfx_passthru ? > + const char *pci_type = xen_igd_gfx_pt_enabled() ? > TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : TYPE_I440FX_PCI_DEVICE; > > pc_init1(machine, > diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c > index 70564cc952d5..dd2c22cc4c0b 100644 > --- a/hw/xen/xen-common.c > +++ b/hw/xen/xen-common.c > @@ -129,12 +129,12 @@ static void xen_change_state_handler(void *opaque, int running, > > static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp) > { > - return has_igd_gfx_passthru; > + return xen_igd_gfx_pt_enabled(); > } > > static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error **errp) > { > - has_igd_gfx_passthru = value; > + xen_igd_gfx_pt_set(value, errp); > } > > static void xen_setup_post(MachineState *ms, AccelState *accel) > diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c > index 81d5ad8da7f0..ab84443d5ec8 100644 > --- a/hw/xen/xen_pt.c > +++ b/hw/xen/xen_pt.c > @@ -65,7 +65,17 @@ > #include "qemu/range.h" > #include "exec/address-spaces.h" > > -bool has_igd_gfx_passthru; > +static bool has_igd_gfx_passthru; > + > +bool xen_igd_gfx_pt_enabled(void) > +{ > + return has_igd_gfx_passthru; > +} > + > +void xen_igd_gfx_pt_set(bool value, Error **errp) > +{ > + has_igd_gfx_passthru = value; > +} > > #define XEN_PT_NR_IRQS (256) > static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0}; > diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h > index 179775db7b22..6e9cec95f3b7 100644 > --- a/hw/xen/xen_pt.h > +++ b/hw/xen/xen_pt.h > @@ -5,6 +5,9 @@ > #include "hw/pci/pci.h" > #include "xen-host-pci-device.h" > > +bool xen_igd_gfx_pt_enabled(void); > +void xen_igd_gfx_pt_set(bool value, Error **errp); > + > void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3); > > #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a) > @@ -322,10 +325,9 @@ extern void *pci_assign_dev_load_option_rom(PCIDevice *dev, > unsigned int domain, > unsigned int bus, unsigned int slot, > unsigned int function); > -extern bool has_igd_gfx_passthru; > static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev) > { > - return (has_igd_gfx_passthru > + return (xen_igd_gfx_pt_enabled() > && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA)); > } > int xen_pt_register_vga_regions(XenHostPCIDevice *dev); > diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs > index 6a9e3135e8f9..564527e00997 100644 > --- a/stubs/Makefile.objs > +++ b/stubs/Makefile.objs > @@ -40,6 +40,7 @@ stub-obj-y += target-get-monitor-def.o > stub-obj-y += vmgenid.o > stub-obj-y += xen-common.o > stub-obj-y += xen-hvm.o > +stub-obj-y += xen-pt.o > stub-obj-y += pci-host-piix.o > stub-obj-y += ram-block.o > stub-obj-y += ramfb.o > diff --git a/stubs/xen-pt.c b/stubs/xen-pt.c > new file mode 100644 > index 000000000000..2d8cac8d54b9 > --- /dev/null > +++ b/stubs/xen-pt.c > @@ -0,0 +1,22 @@ > +/* > + * Copyright (C) 2020 Citrix Systems UK Ltd. > + * > + * This work is licensed under the terms of the GNU GPL, version 2 or later. > + * See the COPYING file in the top-level directory. > + */ > + > +#include "qemu/osdep.h" > +#include "hw/xen/xen_pt.h" > +#include "qapi/error.h" > + > +bool xen_igd_gfx_pt_enabled(void) > +{ > + return false; > +} > + > +void xen_igd_gfx_pt_set(bool value, Error **errp) > +{ > + if (value) { > + error_setg(errp, "Xen PCI passthrough support not built in"); > + } > +} > Queued, thanks (I have other conflicting patches in the queue). Paolo From xen-devel-bounces@lists.xenproject.org Wed Jun 03 17:09:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 17:09:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWtb-0004ld-Ak; Wed, 03 Jun 2020 17:09:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWta-0004lX-SN for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 17:09:42 +0000 X-Inumbo-ID: 039812ee-a5bd-11ea-ad6e-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 039812ee-a5bd-11ea-ad6e-12813bfff9fa; Wed, 03 Jun 2020 17:09:42 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: RxCigYnqJ8jwZmk/BnaWuBkWK8CJG/CYdKGnGEhOOGkJ4ti0ZQx2I4/eBYI1ciJvXNT/LAl0qb WuZ4vAymWUTwjMhjt6EBGNAuKoVWYiaPpVVElaim9YpiuNhh4KVQeF8I95h4ErcJ8xkoI6rjJK XGCvByEJLNcIL2CJt7hguVeem6NAdahe/3b0ALhYYPXHUARYWqtpRo1S+baVbGa4FymKMqyUsn m5mxe2AqNfC5N+33AD92hprQQZxdCmhURzEx5javsoMZl2ozYa6fKw+XFAX/nIUCKicU7grxgx rlo= X-SBRS: 2.7 X-MesageID: 19166954 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,468,1583211600"; d="scan'208";a="19166954" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14] x86/shim: Fix defconfig selection and trim the build further Date: Wed, 3 Jun 2020 18:09:08 +0100 Message-ID: <20200603170908.13239-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , Paul Durrant , Andrew Cooper , Dario Faggioli , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Several options (TBOOT, XENOPROF, Scheduler) depend on EXPERT to be able to deselect/configure. Enabling EXPERT now causes the request of the Credit1 scheduler to be honoured (rather than giving us Credit2), but take this opportunity to switch to Null, as the previously problematic issues are now believed to be fixed. Enabling EXPERT also allows XEN_SHSTK to be selected, and we don't want this being built for shim. We also don't want TRACEBUFFER or GDBSX either. Take this oppotunity to swap the disable of HVM_FEP for a general disable of HVM (likely to have wider impliciations in the future), and disable ARGO (will necesserily need plumbing work to function in shim). Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Juergen Gross CC: Paul Durrant CC: Dario Faggioli --- xen/arch/x86/configs/pvshim_defconfig | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/configs/pvshim_defconfig b/xen/arch/x86/configs/pvshim_defconfig index 830660e022..3af48d6c06 100644 --- a/xen/arch/x86/configs/pvshim_defconfig +++ b/xen/arch/x86/configs/pvshim_defconfig @@ -5,19 +5,25 @@ CONFIG_PVH_GUEST=y CONFIG_PV_SHIM=y CONFIG_PV_SHIM_EXCLUSIVE=y CONFIG_NR_CPUS=32 +CONFIG_EXPERT=y +CONFIG_SCHED_NULL=y # Disable features not used by the PV shim +# CONFIG_HVM is not set +# CONFIG_XEN_SHSTK is not set # CONFIG_HYPFS is not set # CONFIG_SHADOW_PAGING is not set # CONFIG_BIGMEM is not set -# CONFIG_HVM_FEP is not set # CONFIG_TBOOT is not set # CONFIG_KEXEC is not set # CONFIG_XENOPROF is not set # CONFIG_XSM is not set +# CONFIG_ARGO is not set +# CONFIG_SCHED_CREDIT is not set # CONFIG_SCHED_CREDIT2 is not set # CONFIG_SCHED_RTDS is not set # CONFIG_SCHED_ARINC653 is not set -# CONFIG_SCHED_NULL is not set # CONFIG_LIVEPATCH is not set # CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set +# CONFIG_TRACEBUFFER is not set # CONFIG_DEBUG is not set +# CONFIG_GDBSX is not set -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 17:14:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 17:14:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWxh-0005oc-0b; Wed, 03 Jun 2020 17:13:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgWxf-0005oX-KV for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 17:13:55 +0000 X-Inumbo-ID: 9a16d52a-a5bd-11ea-8993-bc764e2007e4 Received: from mail-ej1-x62a.google.com (unknown [2a00:1450:4864:20::62a]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9a16d52a-a5bd-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 17:13:54 +0000 (UTC) Received: by mail-ej1-x62a.google.com with SMTP id y13so3001980eju.2 for ; Wed, 03 Jun 2020 10:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jOW/QelkbErSI7Qz7IIvYJZTZKsKByoXf52FyLHxkbw=; b=e/4+BpLo3RSLv2gE3vHbF3cYIyOmx8SA1nOdiw0u5zOXkRQUtJQJSwifjhUbAhT+yG LNVXrwOqnkLm9f06g4eqbF28lI7ameyBQM+jfrfPr5mS3PG1Y4REcgkvbpC6Q/FKWhuU +t1TPN7m2y7wzdXvSO5Zyqj41s1FN54gqHwupMLlDwj8TZ4WLqnEzMCwHR8MNMV8cnk1 28GAOXFEWXy37Lp751PqFGQw24wubbYklbrE8Ez9G5x3bTF4J1SHDPS/tYQ/+N3V14AR ct8hCXPyFAzYlTQVapnAYkUGupRXTPXslNvTCQSM5vROBQ2ngcDkvMQZc2nAvF+bkBWi 4Y4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jOW/QelkbErSI7Qz7IIvYJZTZKsKByoXf52FyLHxkbw=; b=IM6pmPqR+nypGZmFT96z66hfrUq9iVcI5BF9x7jVtaqi6UDjYAxQZugGYsYJM2e01S tTgwe+8SdrHwrzrao+Br8Uj173nhVUStBALUTh5MRA/QaIRe9nPy0pZdxFKyMo+8Xb9/ AGinwT/TUZrnYsMrGrF93bKjuI+OThKdWjE8MQszIfWj0UFNBOTcAiATCpZv6Di++swq uPGBCG/d3lQLEZa/Zyk+Ra9N+Z/NROUTvxuiA/KEvX37CGz+SYrPVx5ph9cXTo28XX+f NVBVOobv0t5QerQFgCmu4BOYcfE4INYShlvVdqjpi8Fe3HfJFPM4kG3gwSvouSPzDOmN 4/XQ== X-Gm-Message-State: AOAM532OL2/46dZ34IzC+W3icZz/3j7UlxP0ZCvjQrdA7UPPXBgoMB1T tB5YP0QbTcq4OtfLqVsLmaP6FgjNw6PYXwoI0JU= X-Google-Smtp-Source: ABdhPJzIxljgPURkW5qbY10abuUMcG6YbuPHmq/ME+PmhaGwYmoklx0eFYFN5GVdRk9wTfKCzjG4/y0ipwN304YZ/oU= X-Received: by 2002:a17:906:11d9:: with SMTP id o25mr248561eja.377.1591204433742; Wed, 03 Jun 2020 10:13:53 -0700 (PDT) MIME-Version: 1.0 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> In-Reply-To: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> From: CodeWiz2280 Date: Wed, 3 Jun 2020 13:13:39 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: multipart/alternative; boundary="00000000000009cde605a7312762" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --00000000000009cde605a7312762 Content-Type: text/plain; charset="UTF-8" Hi Julien, The offset is already applied to the memory nodes in the device tree, meaning a direct Linux boot from uboot would have only the 36-bit addresses in the device tree (0x8_0000_0000 and 0x8_8000_0000). Linux would start executing from a 32-bit address space however and then switch over to the aliased 36-bit addresses in the device tree as discussed below by early_paging_init(). I had to add the 32-bit memory node 0x8000_0000 in uboot in place of the 0x8_0000_0000 node otherwise Xen would detect the 32-bit processor and panic on "Unable to detect the first memory bank" in domain_build.c. If I leave only the 36-bit addresses in the device tree and skip past the panic check in domain_build.c, then I could not get the dom0 kernel to boot at all. I believe I would only see "Serial input to DOM0" and nothing else at that point. Yes, leaving LPAE support on for the kernel is preferred. Thank you for your help in this matter. Respectfully, Dave On Wed, Jun 3, 2020 at 7:32 AM Julien Grall wrote: > (+Bertrand and Stefano) > > On 01/06/2020 18:38, CodeWiz2280 wrote: > > Hi Julien, > > Hi Dave, > > > > > As requested please see log below from the eval board booting dom0, some > > notes are as follows: > > Thanks for the logs and the notes. They are useful to understand your > issue. > > > 1. The offset that gets applied to the 32-bit address to translate it > > to 36-bits is 0x7_8000_0000 > > Is this offset present in the Device-Tree? > > > 2. Uboot has been setup to not change the address of the memory in the > > device tree prior to launching xen, otherwise it would > > automatically offset it and replace it with a 36-bit address and xen > > would immediately panic at the 36-bit address for a 32-bit processor. > > What is the list of the memory banks Xen will see? > > Xen is able to support 36-bit address, can you point to the panic() you > are hitting? > > > 3. The RAM starting address placed in the device tree is 0x8000_0000, > > which gets carved up by xen and replaced with 0xA000_0000 prior to > > booting dom0.. I had to put in test code to have the kernel offset the > > 0xA000_0000 32-bit starting address to the 36-bit address needed before > > the kernel will attempt to switch. If it stays 32-bit then it will not > > switch over the address space. Note that without xen in play uboot > > would normally replace the address in the device tree with the 36-bit > one. > > IIUC, in the case of Linux boot directly, the Device-Tree will not > describe the low memory range. Is that correct? > > > 4. The dom0 kernel will boot from xen if the early_paging_init switch > > step is skipped, and the low mem stays in 32-bit....but there is a > > problem with the peripherals so this is not an acceptable solution. > > Can you details a bit more the problem with the peripherals? > > > > > It seems that either the kernel would need some API to tell xen that > > there is going to be a change in the memory its using prior to call > > early_paging_init(), > > From my understanding, the problem is very specific to the KeyStone. So > I would rather avoid to introduce an hypercall specific to your > platform. But... > > > or Xen would need to add the additional 36-bit > > addresses during the memory bank allocation step....but recognize that > > they are not actually different physical memory but just aliased to a > > different address. > > ... I think it is possible to fix it entirely in Xen without any > modification in the device-tree. > > It is seems better that Xen treats the low memory region as "not usable" > and only use the high memory region internally. When allocating a Dom0 > memory banks, it would need to ensure that there is a corresponding > alias in low memory. > > Xen will also need to do two mappings in the Dom0 stage-2 page-tables. > The extra one is for the alias. > > This approach will prevent to use hypercall buffer from low memory and > therefore require your guest to support LPAE. Is it going to be an issue > for you? > > Cheers, > > -- > Julien Grall > --00000000000009cde605a7312762 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Julien,

The offset is already applie= d to the memory nodes in the device tree, meaning a direct Linux boot from = uboot would have only the 36-bit addresses in the device tree (0x8_0000_000= 0 and 0x8_8000_0000).=C2=A0 Linux would start executing from a 32-bit addre= ss space however and then switch over to the aliased 36-bit addresses in th= e device tree as discussed below by early_paging_init().

I had to add the 32-bit memory node 0x8000_0000 in uboot in place of= the 0x8_0000_0000 node otherwise Xen would detect the 32-bit processor and= panic on "Unable to detect the first memory bank" in domain_buil= d.c.=C2=A0 If I leave only the 36-bit addresses in the device tree and skip= past the panic check in domain_build.c, then I could not get the dom0 kern= el to boot at all.=C2=A0 I believe I would only see "Serial input to D= OM0" and nothing else at that point.=C2=A0=C2=A0

<= div>Yes, leaving LPAE support on for the kernel is preferred.
Thank you for your help in this matter.

Respectfully,
Dave=C2=A0

On Wed, Jun 3, 2020 at 7:32 AM Ju= lien Grall <julien@xen.org> wro= te:
(+Bertrand a= nd Stefano)

On 01/06/2020 18:38, CodeWiz2280 wrote:
> Hi Julien,

Hi Dave,

>
> As requested please see log below from the eval board booting dom0, so= me
> notes are as follows:

Thanks for the logs and the notes. They are useful to understand your issue= .

> 1. The offset that gets applied to the 32-bit address to translate it =
> to=C2=A036-bits is 0x7_8000_0000

Is this offset present in the Device-Tree?

> 2. Uboot has been setup to not change the address of the memory in the=
> device tree prior to launching xen, otherwise it would
> automatically=C2=A0offset it and=C2=A0replace it with a=C2=A036-bit ad= dress=C2=A0and xen
> would immediately panic at the 36-bit address for a 32-bit processor.<= br>
What is the list of the memory banks Xen will see?

Xen is able to support 36-bit address, can you point to the panic() you are hitting?

> 3. The RAM starting address placed in the device tree is 0x8000_0000, =
> which gets carved up by=C2=A0xen and replaced with 0xA000_0000 prior t= o
> booting dom0..=C2=A0 I had to put in test code to have the kernel offs= et the
> 0xA000_0000 32-bit starting address to the 36-bit address needed befor= e
> the kernel will attempt to switch.=C2=A0 If it stays 32-bit then it wi= ll not
> switch over the address space.=C2=A0 Note that without xen in play ubo= ot
> would normally replace the address in the device tree with the 36-bit = one.

IIUC, in the case of Linux boot directly, the Device-Tree will not
describe the low memory range. Is that correct?

> 4.=C2=A0The dom0 kernel will boot from xen=C2=A0if the early_paging_in= it switch
> step is skipped, and the low mem stays in 32-bit....but there is a > problem with the peripherals so this is not an acceptable solution.
Can you details a bit more the problem with the peripherals?

>
> It seems that either the kernel would need some API to tell xen that <= br> > there is going to be a change in the memory its using prior to call > early_paging_init(),

=C2=A0From my understanding, the problem is very specific to the KeyStone. = So
I would rather avoid to introduce an hypercall specific to your
platform. But...

> or Xen would need to add the additional 36-bit
> addresses during the memory bank allocation step....but recognize that=
> they are not actually different physical memory but just aliased to a =
> different address.

... I think it is possible to fix it entirely in Xen without any
modification in the device-tree.

It is seems better that Xen treats the low memory region as "not usabl= e"
and only use the high memory region internally. When allocating a Dom0
memory banks, it would need to ensure that there is a corresponding
alias in low memory.

Xen will also need to do two mappings in the Dom0 stage-2 page-tables.
The extra one is for the alias.

This approach will prevent to use hypercall buffer from low memory and
therefore require your guest to support LPAE. Is it going to be an issue for you?

Cheers,

--
Julien Grall
--00000000000009cde605a7312762-- From xen-devel-bounces@lists.xenproject.org Wed Jun 03 17:33:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 17:33:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgXGO-0007sB-MO; Wed, 03 Jun 2020 17:33:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgXGN-0007s6-8A for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 17:33:15 +0000 X-Inumbo-ID: 4d01541a-a5c0-11ea-ad77-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4d01541a-a5c0-11ea-ad77-12813bfff9fa; Wed, 03 Jun 2020 17:33:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EhIhen1+T9ftkUrKhNSKwKjMYnMSbkaMmxzXqMNWLV8=; b=kS30b1WTShO2RgTYHmIkC/ABi i3AU8AVAZk+Re5h1n0Pse1eTqx66fRbbrRNjRej99LYfevP3EYknVxjNkObHpjoTbKYzVXRxNU8oN 8MN0k9w/m1Y787e3fcBRjG+2xOyrmGEeDGzILD297RF0svyl8kIuAoWhNAXRRSxcZqRDU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgXGK-0002T8-S6; Wed, 03 Jun 2020 17:33:12 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgXGJ-0007nq-Ok; Wed, 03 Jun 2020 17:33:11 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgXGJ-0004h2-N4; Wed, 03 Jun 2020 17:33:11 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150641: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=d6f9469a03d832dcd17041ed67774ffb5f3e73b3 X-Osstest-Versions-That: linux=9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0 From: osstest service owner Date: Wed, 03 Jun 2020 17:33:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150641 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150641/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 150606 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150606 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150606 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150606 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150606 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150606 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150606 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150606 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150606 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150606 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: linux d6f9469a03d832dcd17041ed67774ffb5f3e73b3 baseline version: linux 9bf9511e3d9f328c03f6f79bfb741c3d18f2f2c0 Last test of basis 150606 2020-06-01 19:40:10 Z 1 days Failing since 150613 2020-06-02 05:14:57 Z 1 days 3 attempts Testing same since 150641 2020-06-03 06:35:03 Z 0 days 1 attempts ------------------------------------------------------------ 719 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 9bf9511e3d9f..d6f9469a03d8 d6f9469a03d832dcd17041ed67774ffb5f3e73b3 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Wed Jun 03 17:44:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 17:44:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgXRX-0000Yq-U3; Wed, 03 Jun 2020 17:44:47 +0000 Resent-Date: Wed, 03 Jun 2020 17:44:47 +0000 Resent-Message-Id: Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgXRW-0000Yl-SX for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 17:44:46 +0000 X-Inumbo-ID: e8cb258c-a5c1-11ea-81bc-bc764e2007e4 Received: from sender4-of-o57.zoho.com (unknown [136.143.188.57]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e8cb258c-a5c1-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 17:44:44 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1591206280; cv=none; d=zohomail.com; s=zohoarc; b=mf/5XO/WCJa1vO5yYUsqcbuRELmvxawB3oAlsgo1GFDLn3WYnL0zvpSyIQPCaYppY18vdtgomHWZZZG6qyKqfuIbZorQY24lB4SJjXMTZPSjH5cS6oKmysEXHsfvxGCSiyhiBfp5Y/2CYZERrVrzzGJBb2tovPGUnci4DDhN/Zc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1591206280; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:Reply-To:Subject:To; bh=aDOnCV6IQtXJX8qeg6Ku1tNLl+yTLwktKpyCW/ob1pM=; b=mhR1GP5JJqctNZ2mdMFAeIgbG7IOWyxxVsAHd6Ax8xxJm/Xwy602ySHCplhJ4xCYv2fM3NirSJ4wv/oqoZDaHsbtgpdeNfW1/A6uacjxWN+XtdWQwufjtKCVsqm4z1H8I25LPgS4rvaardjeoHWKMxuSWmiuctnydlA23Xgcg4Q= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=no-reply@patchew.org; dmarc=pass header.from= header.from= Received: from [172.17.0.3] (23.253.156.214 [23.253.156.214]) by mx.zohomail.com with SMTPS id 1591206278372849.3348416366575; Wed, 3 Jun 2020 10:44:38 -0700 (PDT) Message-ID: <159120627656.23398.3742621530752770397@45ef0f9c86ae> In-Reply-To: <20200603160442.3151170-1-anthony.perard@citrix.com> Subject: Re: [PATCH v3] xen: fix build without pci passthrough MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Resent-From: From: no-reply@patchew.org To: anthony.perard@citrix.com Date: Wed, 3 Jun 2020 10:44:38 -0700 (PDT) X-ZohoMailClient: External X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: qemu-devel@nongnu.org Cc: sstabellini@kernel.org, ehabkost@redhat.com, paul@xen.org, mst@redhat.com, qemu-devel@nongnu.org, marcel.apfelbaum@gmail.com, pbonzini@redhat.com, anthony.perard@citrix.com, xen-devel@lists.xenproject.org, rth@twiddle.net, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" UGF0Y2hldyBVUkw6IGh0dHBzOi8vcGF0Y2hldy5vcmcvUUVNVS8yMDIwMDYwMzE2MDQ0Mi4zMTUx MTcwLTEtYW50aG9ueS5wZXJhcmRAY2l0cml4LmNvbS8KCgoKSGksCgpUaGlzIHNlcmllcyBmYWls ZWQgdGhlIGRvY2tlci1taW5nd0BmZWRvcmEgYnVpbGQgdGVzdC4gUGxlYXNlIGZpbmQgdGhlIHRl c3RpbmcgY29tbWFuZHMgYW5kCnRoZWlyIG91dHB1dCBiZWxvdy4gSWYgeW91IGhhdmUgRG9ja2Vy IGluc3RhbGxlZCwgeW91IGNhbiBwcm9iYWJseSByZXByb2R1Y2UgaXQKbG9jYWxseS4KCj09PSBU RVNUIFNDUklQVCBCRUdJTiA9PT0KIyEgL2Jpbi9iYXNoCmV4cG9ydCBBUkNIPXg4Nl82NAptYWtl IGRvY2tlci1pbWFnZS1mZWRvcmEgVj0xIE5FVFdPUks9MQp0aW1lIG1ha2UgZG9ja2VyLXRlc3Qt bWluZ3dAZmVkb3JhIEo9MTQgTkVUV09SSz0xCj09PSBURVNUIFNDUklQVCBFTkQgPT09CgogIEND ICAgICAgaW8vY2hhbm5lbC1zb2NrZXQubwpJbiBmaWxlIGluY2x1ZGVkIGZyb20gL3RtcC9xZW11 LXRlc3Qvc3JjL2h3L3hlbi94ZW5fcHQuaDo0LAogICAgICAgICAgICAgICAgIGZyb20gL3RtcC9x ZW11LXRlc3Qvc3JjL3N0dWJzL3hlbi1wdC5jOjk6Ci90bXAvcWVtdS10ZXN0L3NyYy9pbmNsdWRl L2h3L3hlbi94ZW5fY29tbW9uLmg6MTM6MTA6IGZhdGFsIGVycm9yOiB4ZW5jdHJsLmg6IE5vIHN1 Y2ggZmlsZSBvciBkaXJlY3RvcnkKICNpbmNsdWRlIDx4ZW5jdHJsLmg+CiAgICAgICAgICBefn5+ fn5+fn5+fgpjb21waWxhdGlvbiB0ZXJtaW5hdGVkLgptYWtlOiAqKiogWy90bXAvcWVtdS10ZXN0 L3NyYy9ydWxlcy5tYWs6Njk6IHN0dWJzL3hlbi1wdC5vXSBFcnJvciAxCm1ha2U6ICoqKiBXYWl0 aW5nIGZvciB1bmZpbmlzaGVkIGpvYnMuLi4uCiAgQ0MgICAgICBpby9jaGFubmVsLXRscy5vCiAg Q0MgICAgICBpby9jaGFubmVsLXdhdGNoLm8KLS0tCiAgICByYWlzZSBDYWxsZWRQcm9jZXNzRXJy b3IocmV0Y29kZSwgY21kKQpzdWJwcm9jZXNzLkNhbGxlZFByb2Nlc3NFcnJvcjogQ29tbWFuZCAn WydzdWRvJywgJy1uJywgJ2RvY2tlcicsICdydW4nLCAnLS1sYWJlbCcsICdjb20ucWVtdS5pbnN0 YW5jZS51dWlkPWNkMDNlY2VhNGM0MzQ1Mjk4ODY0NTI5YzhiZDU2Y2MyJywgJy11JywgJzEwMDEn LCAnLS1zZWN1cml0eS1vcHQnLCAnc2VjY29tcD11bmNvbmZpbmVkJywgJy0tcm0nLCAnLWUnLCAn VEFSR0VUX0xJU1Q9JywgJy1lJywgJ0VYVFJBX0NPTkZJR1VSRV9PUFRTPScsICctZScsICdWPScs ICctZScsICdKPTE0JywgJy1lJywgJ0RFQlVHPScsICctZScsICdTSE9XX0VOVj0nLCAnLWUnLCAn Q0NBQ0hFX0RJUj0vdmFyL3RtcC9jY2FjaGUnLCAnLXYnLCAnL2hvbWUvcGF0Y2hldy8uY2FjaGUv cWVtdS1kb2NrZXItY2NhY2hlOi92YXIvdG1wL2NjYWNoZTp6JywgJy12JywgJy92YXIvdG1wL3Bh dGNoZXctdGVzdGVyLXRtcC1mbXkzbWYxei9zcmMvZG9ja2VyLXNyYy4yMDIwLTA2LTAzLTEzLjQy LjE5LjIyMDU5Oi92YXIvdG1wL3FlbXU6eixybycsICdxZW11OmZlZG9yYScsICcvdmFyL3RtcC9x ZW11L3J1bicsICd0ZXN0LW1pbmd3J10nIHJldHVybmVkIG5vbi16ZXJvIGV4aXQgc3RhdHVzIDIu CmZpbHRlcj0tLWZpbHRlcj1sYWJlbD1jb20ucWVtdS5pbnN0YW5jZS51dWlkPWNkMDNlY2VhNGM0 MzQ1Mjk4ODY0NTI5YzhiZDU2Y2MyCm1ha2VbMV06ICoqKiBbZG9ja2VyLXJ1bl0gRXJyb3IgMQpt YWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Zhci90bXAvcGF0Y2hldy10ZXN0ZXItdG1wLWZt eTNtZjF6L3NyYycKbWFrZTogKioqIFtkb2NrZXItcnVuLXRlc3QtbWluZ3dAZmVkb3JhXSBFcnJv ciAyCgpyZWFsICAgIDJtMTcuODAzcwp1c2VyICAgIDBtOS4xMDRzCgoKVGhlIGZ1bGwgbG9nIGlz IGF2YWlsYWJsZSBhdApodHRwOi8vcGF0Y2hldy5vcmcvbG9ncy8yMDIwMDYwMzE2MDQ0Mi4zMTUx MTcwLTEtYW50aG9ueS5wZXJhcmRAY2l0cml4LmNvbS90ZXN0aW5nLmRvY2tlci1taW5nd0BmZWRv cmEvP3R5cGU9bWVzc2FnZS4KLS0tCkVtYWlsIGdlbmVyYXRlZCBhdXRvbWF0aWNhbGx5IGJ5IFBh dGNoZXcgW2h0dHBzOi8vcGF0Y2hldy5vcmcvXS4KUGxlYXNlIHNlbmQgeW91ciBmZWVkYmFjayB0 byBwYXRjaGV3LWRldmVsQHJlZGhhdC5jb20= From xen-devel-bounces@lists.xenproject.org Wed Jun 03 18:09:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 18:09:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgXpH-0003Bz-Pl; Wed, 03 Jun 2020 18:09:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgXpG-0003Bq-Hi for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 18:09:18 +0000 X-Inumbo-ID: 5745ba88-a5c5-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5745ba88-a5c5-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 18:09:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z3kV3c89rh2AGBiuIci0itQ8FahxqdbX55Sg4/68Wpk=; b=vpvCVmSJtRB+3wEyXgiHXAbjpA HJEIvPJ3ei/LjkdVHDyArp+9ZqcUih1Nq5PYd6DcyPXshj9BJgVPOQt5TQl+cxrv1hHBkOTurqi4s SXdynXjjHQqGVSwqhQQElMlE3ZHw+iN44zSOvXe4faLLU7G8TYrDziF5kCs9Zb9jq5Qs=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgXpF-0003H7-1S; Wed, 03 Jun 2020 18:09:17 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgXpE-0008Lg-RE; Wed, 03 Jun 2020 18:09:16 +0000 Subject: Re: Keystone Issue To: CodeWiz2280 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> From: Julien Grall Message-ID: Date: Wed, 3 Jun 2020 19:09:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03/06/2020 18:13, CodeWiz2280 wrote: > Hi Julien, Hello, In general, we avoid top post on xen-devel, instead we reply inline. I believe gmail should allow you to do it :). > > The offset is already applied to the memory nodes in the device tree, > meaning a direct Linux boot from uboot would have only the 36-bit > addresses in the device tree (0x8_0000_0000 and 0x8_8000_0000).  Linux > would start executing from a 32-bit address space however and then > switch over to the aliased 36-bit addresses in the device tree as > discussed below by early_paging_init(). > > I had to add the 32-bit memory node 0x8000_0000 in uboot in place of the > 0x8_0000_0000 node otherwise Xen would detect the 32-bit processor and > panic on "Unable to detect the first memory bank" in domain_build.c. So for 32-bit Xen requires to have the first bank below 4GB. This is because you can't boot from a physical address above 32-bit. Obviously, this check wouldn't work on your platform because all your memory will be above 4GB. > If > I leave only the 36-bit addresses in the device tree and skip past the > panic check in domain_build.c, then I could not get the dom0 kernel to > boot at all.  I believe I would only see "Serial input to DOM0" and > nothing else at that point. Which would make sense per above. > > Yes, leaving LPAE support on for the kernel is preferred. Ok, so the solution I suggested below should work. Unfortunately, I don't have time to work on it. Although, I would be more than happy to answers questions and reviewing the patches. Would you be willing to have a try to implement it? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 03 18:37:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 18:37:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgYGd-0006I4-SC; Wed, 03 Jun 2020 18:37:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgYGd-0006Hz-4I for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 18:37:35 +0000 X-Inumbo-ID: 4a3a4f4e-a5c9-11ea-81bc-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4a3a4f4e-a5c9-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 18:37:34 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id k11so3241619ejr.9 for ; Wed, 03 Jun 2020 11:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5IM+1eJnx61x/IN6roxRxnyQCN8z8HzRz5YxqAqCivE=; b=dNtC8d4TNtsPGJFcW/rU+bO/AFRwsmECL4f5H+D9+fQsJ/E5uqcZpmJum5yq53WcTs HSah0iCDkZMcooRTO4C8iS/CojCaKrSxWhXleBg+hudfkxZoo/wl/nRo8wWRSyRMBFTQ yDHrZec+pQHYl8YH5XFDQU036A2xcRu7I76dZTgOerL5IXtXhRI7KBhhKQ34vgbbu0mx /0S7ONmn+fdk459sC3hA27dc4gWrmFRUlKMGCaXfZqUBeiN4lT9uyTyjVknWE1kVFCfL th6XFXCV0ydS6ZTKfqOtt4AS80xi1EdYelnldIPDj5J/jnzAmKZiXqV7rKh52BDMPGGC DWRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5IM+1eJnx61x/IN6roxRxnyQCN8z8HzRz5YxqAqCivE=; b=UdInyb5MAYBLjEwo4wyvuXX5BKCwNF6uWBlOFmsOY3pyTsDwPyrJwZu8lYvzQZJMw+ 3l2gHelwZJUb5YsctXfp4/HOjnGrIk4dCuZNLVjHIJONMurH+hoiUTJZw2xl/FLWp0Dz PqlVi5v3eyVP5fE23kkRtLQS/ffkpZhImkptag5XncjGkTJxXEAyJA9H1/5RlwL7RAUc pmGJILtQLORelCqi+kR0VBuxSH5HkCoB4SoPqmHYd/DqfYCjHOa7TYtw8j9KOLJuAUyg f8P+OBsFmUUxlHXaMCC3jg2NVoFvNFbF5O5eNDZipqw3vro1srxxI9H7swnKSKzrcXOO r/rg== X-Gm-Message-State: AOAM533Bgqd1Gb6W0Vk/fbkvKVkD7Dn46I0cTmevu/OrxrFqltwG5J76 6gw85orx4Ms+GvqLyyMzlsBAlmEtwDd0ZvRpMno= X-Google-Smtp-Source: ABdhPJxSCpf5wuL8r445BYXlysTjmcWZXMt+acSaWWj/bBmmF/qLZknOk1xKIGuBtJUMLG/AlMSGAZzWEcmnfgN3jQc= X-Received: by 2002:a17:906:14cb:: with SMTP id y11mr533992ejc.131.1591209453680; Wed, 03 Jun 2020 11:37:33 -0700 (PDT) MIME-Version: 1.0 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> In-Reply-To: From: CodeWiz2280 Date: Wed, 3 Jun 2020 14:37:20 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 3, 2020 at 2:09 PM Julien Grall wrote: > > > > On 03/06/2020 18:13, CodeWiz2280 wrote: > > Hi Julien, > > Hello, > > In general, we avoid top post on xen-devel, instead we reply inline. I > believe gmail should allow you to do it :). > I'm sorry about that. Hopefully this looks right now. > > > > The offset is already applied to the memory nodes in the device tree, > > meaning a direct Linux boot from uboot would have only the 36-bit > > addresses in the device tree (0x8_0000_0000 and 0x8_8000_0000). Linux > > would start executing from a 32-bit address space however and then > > switch over to the aliased 36-bit addresses in the device tree as > > discussed below by early_paging_init(). > > > > I had to add the 32-bit memory node 0x8000_0000 in uboot in place of the > > 0x8_0000_0000 node otherwise Xen would detect the 32-bit processor and > > panic on "Unable to detect the first memory bank" in domain_build.c. > > So for 32-bit Xen requires to have the first bank below 4GB. This is > because you can't boot from a physical address above 32-bit. > > Obviously, this check wouldn't work on your platform because all your > memory will be above 4GB. > > > If > > I leave only the 36-bit addresses in the device tree and skip past the > > panic check in domain_build.c, then I could not get the dom0 kernel to > > boot at all. I believe I would only see "Serial input to DOM0" and > > nothing else at that point. > > Which would make sense per above. > > > > > Yes, leaving LPAE support on for the kernel is preferred. > > Ok, so the solution I suggested below should work. Unfortunately, I > don't have time to work on it. Although, I would be more than happy to > answers questions and reviewing the patches. > > Would you be willing to have a try to implement it? > Unfortunately, I am not familiar enough with the Xen codebase to attempt to make the changes. Thank you for your support and insight. > Cheers, > > -- > Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 03 18:51:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 18:51:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgYU8-0008HG-41; Wed, 03 Jun 2020 18:51:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgYU7-0008HB-A0 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 18:51:31 +0000 X-Inumbo-ID: 3c9b6cf4-a5cb-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3c9b6cf4-a5cb-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 18:51:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JzXLYmBMygsIyLg8V79TkBUE1Ib2i8Iij+y9bQjFcBk=; b=JypQg0CJFar/G/9f2V7fKniUd LoftgBNX0blbL3dd2oew1ZFXMfys5SKpdRyVK9T6ZfF7Vue1tJFGemV3XxYQjwjoNGbhIfAo6P8Ib mzwUMgDIVI2Sm4YopMjM4x48wJFmL5mRp6v61rZ1BehIs0xaKhUOO3Ir/GxLFAtuUEoyA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgYU5-00046V-FY; Wed, 03 Jun 2020 18:51:29 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgYU5-00022E-5h; Wed, 03 Jun 2020 18:51:29 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgYU5-0006QK-59; Wed, 03 Jun 2020 18:51:29 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150658: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d9f58cd54fe2f05e1f05e2fe254684bd1840de8e X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Wed, 03 Jun 2020 18:51:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150658 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150658/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d9f58cd54fe2f05e1f05e2fe254684bd1840de8e baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 6 days Failing since 150465 2020-05-29 09:02:14 Z 5 days 40 attempts Testing same since 150649 2020-06-03 13:01:44 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1522 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 19:49:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 19:49:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgZNx-000544-Jc; Wed, 03 Jun 2020 19:49:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgZNw-00053z-K2 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 19:49:12 +0000 X-Inumbo-ID: 4be1165c-a5d3-11ea-9947-bc764e2007e4 Received: from mail-oo1-xc42.google.com (unknown [2607:f8b0:4864:20::c42]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4be1165c-a5d3-11ea-9947-bc764e2007e4; Wed, 03 Jun 2020 19:49:11 +0000 (UTC) Received: by mail-oo1-xc42.google.com with SMTP id z145so756470ooa.13 for ; Wed, 03 Jun 2020 12:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:reply-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=BjoQVhQ+xvPgNl9Z3U7D5+seTgkSC/GbBFtHU5et3Hc=; b=t8/gQnm7BUa1a2dJXcr7l12yBuIa/tgL/Pc7VXe1B7MVeCOMy9nkf5p6rlNKssTX1B YTZceJ7XT/uh/0jeMrZOhKEB74iQpxXnR8exYW7BHQD02AMiqOa7cuS8eudMFCp01WcZ KydSSId1lRL1EywY3pLolhYiV2FRnbiSUTRNWSuvfv43V2IEpB02X4/lx7Oz7c83u+rl b7Z17MVIR/XqFmjlccDJz7ypWfRfsDfsKRLgr0Kn18z1BJIuH3bSmCDK5jrKr31HGTVv 7PpzOImpyhO7N0XyOPTDDDu2i83577zQGPqXCIW81nomHBnDJtntueikSA3Jnovrs4Cg osrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :reply-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=BjoQVhQ+xvPgNl9Z3U7D5+seTgkSC/GbBFtHU5et3Hc=; b=EOb67L9GFyOewZGYtGIHeMeabUoYF+Nlpu5rzNPzHxbw30bcCNsofZI1hXclKp5Yu2 MdFqcjqQwwLnaHbbcCPbSRK5Q+Q2sb1GIkSFd5OoRxCe2+Y9pzJt/mnh+C/bWSXDb4Tt iR7f+pWEo/R4IwU1yAQG7X4S72xG7FBiz9HwqlDEJYELDIfmVlcALTXq9mIoOfuRc65p AyOe5EDOmR8uBi4wF+sjoXCnayhSGOSCsAZIiFZH7LizhFdrwrqva2WhnZEtvQCB6foc V0BFKHqs3KDsnWY1H2wpOqhuYd6JxmONxumSuuDNiuJjRpXkw0xBTsofjNHUoWOgWoPm AAbQ== X-Gm-Message-State: AOAM530mATIHYPEoDxzofmB4uJHjGI0NKaeonJIPhaqyG3qWvRFg8kqc xP+tiilRLrmYAkMvSwm8bw== X-Google-Smtp-Source: ABdhPJyjAaiGJMdnfUFXumSSQrllyfRCCzBhO4Dfk9s9kG0Pu+ogj1CkP4aoQfjUIpChG0U+kZYP8g== X-Received: by 2002:a4a:3559:: with SMTP id w25mr1229951oog.6.1591213751312; Wed, 03 Jun 2020 12:49:11 -0700 (PDT) Received: from serve.minyard.net ([47.184.146.204]) by smtp.gmail.com with ESMTPSA id m9sm741686oon.14.2020.06.03.12.49.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 12:49:10 -0700 (PDT) Received: from minyard.net (unknown [IPv6:2001:470:b8f6:1b:9d35:f7bd:647:6545]) by serve.minyard.net (Postfix) with ESMTPSA id 4BAEF180050; Wed, 3 Jun 2020 19:49:09 +0000 (UTC) Date: Wed, 3 Jun 2020 14:49:08 -0500 From: Corey Minyard To: Stefano Stabellini Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU Message-ID: <20200603194908.GK2880@minyard.net> References: <42253259-9663-67e8-117f-8ba631243585@xen.org> <20200602183420.GE2880@minyard.net> <20200603152914.GJ2880@minyard.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: minyard@acm.org Cc: jgross@suse.com, Peng Fan , Julien Grall , roman@zededa.com, "jeff.kubascik@dornerworks.com" , Julien Grall , Nataliya Korovkina , "xen-devel@lists.xenproject.org" , boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 08:37:09AM -0700, Stefano Stabellini wrote: > On Wed, 3 Jun 2020, Corey Minyard wrote: > > On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote: > > > On Tue, 2 Jun 2020, Corey Minyard wrote: > > > > Snip > > > > > > > > > > > > > whether > > > > > > > > > this was already done: > > > > > > > > >      1) Does the kernel boot on baremetal (i.e without Xen)? This should > > > > > > > > > help > > > > > > > > > to confirm whether the bug is Xen is related. > > > > > > > > > > > > > > > > Yes it boots > > > > > > > > > > > > > > > > >      2) Swiotlb should not be necessary for basic dom0 boot on Arm. Did > > > > > > > > > you try > > > > > > > > > to disable it? This should help to confirm whether swiotlb is the > > > > > > > > > problem or > > > > > > > > > not. > > > > > > > > > > > > > > > > It boots disabling swiotlb-xen > > > > > > > > > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for dom0. So > > > > > > > this suggests swiotlb is doing some transformation on the DMA address. > > > > > > > > > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to assume > > > > > > > the DMA address space and CPU address space is the same. Is RPI using the > > > > > > > same address space? > > > > > > > > > > > > Another question, is the DMA request bounced? If so, are we sure the bounce > > > > > > buffer is in the first GB? > > > > > > > > > > Yes, it is. This is actually where we spent the last few days, and I > > > > > found another little related bug in the initialization of the > > > > > swiotlb-xen but now I am sure the memory is under 1GB (0x34000000-0x38000000) > > > > > > > > Was anything ever resolved on this issue? It just kind of ended for me, > > > > and I looked in the main kernel and didn't find anything that looked > > > > related. > > > > > > Yes, we have a patch series on the list for the Linux kernel to fix this > > > issue but it hasn't been merged yet: > > > > > > https://marc.info/?l=linux-kernel&m=159001831406263&w=2 > > > > Just FYI, I pulled the changes on top of > > https://github.com/raspberrypi/linux.git rpi-5.4.y > > Along with change > > 56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_* > > before the series so it applies on 5.4, and I was able to boot and > > create a domU. So: > > > > Tested-by: Corey Minyard > > > > At least on 5.4. If you think it would be valuable, I can test on > > rpi-5.7.y. > > I'd feel better adding your Tested-by to my next upstream submission of > the series if you could also test on 5.7. Thank you in advance! Well, rpi-5.7.y fails to bootup completely without Xen, and doesn't even display any console output on top of Xen :-(. So there are issues, but probably not with Xen. I did try rpi-5.6.y and it works. -corey > > > > I'll be integrating this in with our Pi Xen yocto layer at > > https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen > > That's great! From xen-devel-bounces@lists.xenproject.org Wed Jun 03 19:56:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 19:56:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgZUb-00067V-EJ; Wed, 03 Jun 2020 19:56:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgZUZ-00067P-Qh for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 19:56:03 +0000 X-Inumbo-ID: 4024ba02-a5d4-11ea-81bc-bc764e2007e4 Received: from mail-qk1-x743.google.com (unknown [2607:f8b0:4864:20::743]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4024ba02-a5d4-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 19:56:01 +0000 (UTC) Received: by mail-qk1-x743.google.com with SMTP id q8so3510940qkm.12 for ; Wed, 03 Jun 2020 12:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k2W1eXLJo+wIryPHXd9bNoAzHFLoc5awp3RPJsnVKfg=; b=RCs7DT+GET4pG5HUmWbUCIsY8MjRxEz4cXFtCs53LzKAEEGQuiTosYVcwO1judnbFW EZhIq/P7l8GmdVtUnWmme/Aa4NnaWyRtBRPIBRppC1rlmNuwTSGTpM5zUjARncpu9G2t LFXBVLj73gutMfQ1EwDN49ARpO2wUSZ8hAdqcQDjfNlser18D3ye6WvxcZ9ps+ViK94h xLQ/y8bHw5JVo2eXcLQnt48ZFiKpWTb6Fgy7sSJfFh5lnRQIBH78iQM+/te2xBL7IbyT laHmZ7cIfI8UO1J3/kIZqoeSCHeGEVtj414s24bQFiopz6v2vvFicrL2WMSsmKj+FpG7 oOVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k2W1eXLJo+wIryPHXd9bNoAzHFLoc5awp3RPJsnVKfg=; b=JXHhSn+3ceY8vmV7QyODLVlYSxyyWjihoSFq8YcKdYX2lya4C/+SXPc2UFkuPgO+L0 iC+soi6kVb0UyJxoZ2POEQTJI6nL4nU1V6nhH396Dtccfr1zQTcs9LkwLYQ8Sqf4QPBr ngQInYZISaO3Xp/z7/5jG4nnjHZhYTFlLKsOkmTLMp3SB8eXVMgcTOPyXwvNZqbS7tKt 5kPgdmK00MA66VCfmPmjlH8dQEwjk2z5SN3Qa4qEjgg908uS6NFB74zjjrve7hrUL90O xtcU0WGwQRYcgN5fAlLnkCRXzh1Q6Z1WRfDsSobPsEPKW05wYwY9W+iRUEEz/MxaVum6 Grtw== X-Gm-Message-State: AOAM533fEgNJ4KPeHyND5tOEyww0J7fAqSmtOijI68fz1OzL0xXpZ0CN OuNCv+Cos6E2lJfRHY1nzwupfAKzKuyUBN76q4yF9Q== X-Google-Smtp-Source: ABdhPJwS6Rrx7oQF4n3QWuFwqxLWZNOTDEBBbKK363AC/SbW+fwMgo8lyTvyaBNjc8A5PON2Jw+FksE3132/e36XXCY= X-Received: by 2002:a37:5283:: with SMTP id g125mr1332987qkb.157.1591214161274; Wed, 03 Jun 2020 12:56:01 -0700 (PDT) MIME-Version: 1.0 References: <42253259-9663-67e8-117f-8ba631243585@xen.org> <20200602183420.GE2880@minyard.net> <20200603152914.GJ2880@minyard.net> In-Reply-To: From: Roman Shaposhnik Date: Wed, 3 Jun 2020 12:55:50 -0700 Message-ID: Subject: Re: Troubles running Xen on Raspberry Pi 4 with 5.6.1 DomU To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Peng Fan , Julien Grall , Corey Minyard , "jeff.kubascik@dornerworks.com" , Julien Grall , Nataliya Korovkina , "xen-devel@lists.xenproject.org" , Boris Ostrovsky , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Well it goes without saying, but both Julian's branch and your patchset can have: Tested-by: Roman Shaposhnik Thanks, Roman. P.S. For anyone interested I'll be curating the patchset over here: https://github.com/rvs/eve/tree/rpi4/pkg/xen/arch/aarch64 https://github.com/rvs/eve/tree/rpi4/pkg/new-kernel/patches-5.6.x On Wed, Jun 3, 2020 at 8:37 AM Stefano Stabellini wrote: > > On Wed, 3 Jun 2020, Corey Minyard wrote: > > On Tue, Jun 02, 2020 at 12:24:05PM -0700, Stefano Stabellini wrote: > > > On Tue, 2 Jun 2020, Corey Minyard wrote: > > > > Snip > > > > > > > > > > > > > whether > > > > > > > > > this was already done: > > > > > > > > > 1) Does the kernel boot on baremetal (i.e without Xen)? This should > > > > > > > > > help > > > > > > > > > to confirm whether the bug is Xen is related. > > > > > > > > > > > > > > > > Yes it boots > > > > > > > > > > > > > > > > > 2) Swiotlb should not be necessary for basic dom0 boot on Arm. Did > > > > > > > > > you try > > > > > > > > > to disable it? This should help to confirm whether swiotlb is the > > > > > > > > > problem or > > > > > > > > > not. > > > > > > > > > > > > > > > > It boots disabling swiotlb-xen > > > > > > > > > > > > > > Thank you for the answer! swiotlb-xen should basically be a NOP for dom0. So > > > > > > > this suggests swiotlb is doing some transformation on the DMA address. > > > > > > > > > > > > > > I have an idea what may have gone wrong. AFAICT, xen-swiotlb seems to assume > > > > > > > the DMA address space and CPU address space is the same. Is RPI using the > > > > > > > same address space? > > > > > > > > > > > > Another question, is the DMA request bounced? If so, are we sure the bounce > > > > > > buffer is in the first GB? > > > > > > > > > > Yes, it is. This is actually where we spent the last few days, and I > > > > > found another little related bug in the initialization of the > > > > > swiotlb-xen but now I am sure the memory is under 1GB (0x34000000-0x38000000) > > > > > > > > Was anything ever resolved on this issue? It just kind of ended for me, > > > > and I looked in the main kernel and didn't find anything that looked > > > > related. > > > > > > Yes, we have a patch series on the list for the Linux kernel to fix this > > > issue but it hasn't been merged yet: > > > > > > https://marc.info/?l=linux-kernel&m=159001831406263&w=2 > > > > Just FYI, I pulled the changes on top of > > https://github.com/raspberrypi/linux.git rpi-5.4.y > > Along with change > > 56e35f9c5b87ec dma-mapping: drop the dev argument to arch_sync_dma_for_* > > before the series so it applies on 5.4, and I was able to boot and > > create a domU. So: > > > > Tested-by: Corey Minyard > > > > At least on 5.4. If you think it would be valuable, I can test on > > rpi-5.7.y. > > I'd feel better adding your Tested-by to my next upstream submission of > the series if you could also test on 5.7. Thank you in advance! > > > > I'll be integrating this in with our Pi Xen yocto layer at > > https://github.com/MontaVista-OpenSourceTechnology/meta-raspberrypi-xen > > That's great! From xen-devel-bounces@lists.xenproject.org Wed Jun 03 20:46:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 20:46:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgaHH-0002pM-6J; Wed, 03 Jun 2020 20:46:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgaHF-0002pH-Px for xen-devel@lists.xen.org; Wed, 03 Jun 2020 20:46:21 +0000 X-Inumbo-ID: 47119d10-a5db-11ea-adaf-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 47119d10-a5db-11ea-adaf-12813bfff9fa; Wed, 03 Jun 2020 20:46:20 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ZEa2eF+s/eaIrs3thAnFPIjtP2GgNPrHpZ2geRiHgP3i9ORY3LjT0Z1DZdhMB0Bs0xLKnfEAyA DurC/XM+xhBC+/tT7TNx1/o24bs/hu+kMh1VEor0x9YW30LQJ4kHvRGA8bof/xkcsdZb18Bjxo SH06ymt2caW+StrAiNPbNJH/3zZ4ftdh9tk152jO6F/IJWi03fQUNNZ2+Fm/L/yhk0y3+C3E99 qP7oB33MvEE8kLeNxsd/bmawkZG1Ml+vARc4YBIpElE4XG6H5NidHlt7Tvo36K+RkLyKoqM6f5 NTo= X-SBRS: 2.7 X-MesageID: 19185429 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,469,1583211600"; d="scan'208";a="19185429" Subject: Re: [XTF] xenbus: fix xenbus_write() ring overflow To: Pawel Wieczorkiewicz , References: <20200603082141.42683-1-wipawel@amazon.de> From: Andrew Cooper Message-ID: <75f655aa-6bea-cfe9-84de-bd4ef0195ab3@citrix.com> Date: Wed, 3 Jun 2020 21:46:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200603082141.42683-1-wipawel@amazon.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: julien@xen.org, wipawel@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03/06/2020 09:21, Pawel Wieczorkiewicz wrote: > Currently the xenbus_write() does not handle ring wrapping around > correctly. When ring buffer is almost full and there is not enough > space for next packet (e.g. there is 12 bytes of space left, but the > packet header needs to transmit 16 bytes) the memcpy() goes out of the > ring buffer boundry. > Instead, the part variable should be limited to the space available in > the ring buffer, so the memcpy() can fill up the buffer, update len > variable (to indicate that there is still some data to be copied) and > thereby the xenbus_write() loop can iterate again to finish copying > the remainder of data to the beginning of the ring buffer. > > Signed-off-by: Pawel Wieczorkiewicz Oops.  Reviewed-by: Andrew Cooper and pushed. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:15:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:15:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbfS-0003Vv-Sb; Wed, 03 Jun 2020 22:15:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbfS-0003Vq-DK for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:15:26 +0000 X-Inumbo-ID: b5a74084-a5e7-11ea-adbe-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b5a74084-a5e7-11ea-adbe-12813bfff9fa; Wed, 03 Jun 2020 22:15:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6OxDBR2snl2npbb3UJyTDf5nnFn7wmPqkfhbUfEImWk=; b=Lv44RZRwtSks8k5VAADEVdz7P 4z3sfaEbJKsO+kYuNyhSvtEejTECw1wvD1xlK5lbM8QNZsD/TE+Ust77+NAwHYRBLsevyxMZJg+2J NOg9TwMETRuHVQgls7bLcO0hDEiEGIjFFU9WwWlTDbHuoJbfsTTzzmvbOxeM+0k0oKq8g=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbfK-0008Lc-UV; Wed, 03 Jun 2020 22:15:18 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgbfK-0005f2-Me; Wed, 03 Jun 2020 22:15:18 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgbfK-0005TK-M1; Wed, 03 Jun 2020 22:15:18 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150664: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:heisenbug xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d9f58cd54fe2f05e1f05e2fe254684bd1840de8e X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Wed, 03 Jun 2020 22:15:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150664 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150664/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail pass in 150658 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d9f58cd54fe2f05e1f05e2fe254684bd1840de8e baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 6 days Failing since 150465 2020-05-29 09:02:14 Z 5 days 41 attempts Testing same since 150649 2020-06-03 13:01:44 Z 0 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1522 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:22:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:22:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmT-0004ZP-NW; Wed, 03 Jun 2020 22:22:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmS-0004ZK-Da for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:22:40 +0000 X-Inumbo-ID: bc40f006-a5e8-11ea-9dbe-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bc40f006-a5e8-11ea-9dbe-bc764e2007e4; Wed, 03 Jun 2020 22:22:40 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0902F2067B; Wed, 3 Jun 2020 22:22:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222959; bh=FbZizFCbXTo82zhp90elPXeQrp3LeJltCz9UBkieMa0=; h=Date:From:To:cc:Subject:From; b=UliQ4Xc0s6kZlNyoqhnZToK1IzE2Oj4wUjDuW8fE4ZVtpg23emU+hIIetm/p3gS6X I5fikv0SrWzGlcMWVVAA/OXGN5h8aK+xYKoyKk0nyhLQCEVjiGuNTKdL5S/YGdf+Y6 zofhZFz2KDHQnFwvSm3nSU0DF9MBACdKFzRLyvTM= Date: Wed, 3 Jun 2020 15:22:38 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 00/11] fix swiotlb-xen for RPi4 Message-ID: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, sstabellini@kernel.org, tamas@tklengyel.com, linux-kernel@vger.kernel.org, roman@zededa.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi all, This series is a collection of fixes to get Linux running on the RPi4 as dom0. Conceptually there are only two significant changes: - make sure not to call virt_to_page on vmalloc virt addresses (patch #1) - use phys_to_dma and dma_to_phys to translate phys to/from dma addresses (all other patches) In particular in regards to the second part, the RPi4 is the first board where Xen can run that has the property that dma addresses are different from physical addresses, and swiotlb-xen was written with the assumption that phys addr == dma addr. This series adds the phys_to_dma and dma_to_phys calls to make it work. Cheers, Stefano The following changes since commit b85051e755b0e9d6dd8f17ef1da083851b83287d: Merge tag 'fixes-for-5.7-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux (2020-05-20 13:23:55 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git fix-rpi4-v2 for you to fetch changes up to 49783ba67f75da3490d2c01ed9b445d8a89bbb0d: xen/arm: call dma_to_phys on the dma_addr_t parameter of dma_cache_maint (2020-06-03 15:05:53 -0700) ---------------------------------------------------------------- Boris Ostrovsky (1): swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses Stefano Stabellini (10): swiotlb-xen: remove start_dma_addr swiotlb-xen: add struct device* parameter to xen_phys_to_bus swiotlb-xen: add struct device* parameter to xen_bus_to_phys swiotlb-xen: add struct device* parameter to xen_dma_sync_for_cpu swiotlb-xen: add struct device* parameter to xen_dma_sync_for_device swiotlb-xen: add struct device* parameter to is_xen_swiotlb_buffer swiotlb-xen: introduce phys_to_dma/dma_to_phys translations swiotlb-xen: rename xen_phys_to_bus to xen_phys_to_dma and xen_bus_to_phys to xen_dma_to_phys xen/arm: introduce phys/dma translations in xen_dma_sync_for_* xen/arm: call dma_to_phys on the dma_addr_t parameter of dma_cache_maint arch/arm/xen/mm.c | 32 +++++++++++++++++++------------- drivers/xen/swiotlb-xen.c | 72 +++++++++++++++++++++++++++++++++++++----------------------------------- include/xen/swiotlb-xen.h | 10 ++++++---- 3 files changed, 62 insertions(+), 52 deletions(-) From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:22:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:22:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbme-0004b7-76; Wed, 03 Jun 2020 22:22:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmd-0004ad-7B for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:22:51 +0000 X-Inumbo-ID: c2a0bb66-a5e8-11ea-81bc-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c2a0bb66-a5e8-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 22:22:50 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DD192207ED; Wed, 3 Jun 2020 22:22:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222970; bh=8roukE2cTqX3x3U/iL+TWs1iGe9wtzQx9xz7olDA5jo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Qfq6j7xRVNuYFJciHIBfv0Hg3QKcp+rEpTkPApdVaF/0j83toOfu9Qb2RDayzq07g eWKPjP2zWTV/ifm1xQvO+4YmzvyVJYmqgiUwWnpxQitIuHoRSHJxXT/YY2jtK9kkWD 9g33HwxMV7DGdAnc5ryX5OYBot/+trzQbyHC4d8E= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 03/11] swiotlb-xen: add struct device* parameter to xen_phys_to_bus Date: Wed, 3 Jun 2020 15:22:39 -0700 Message-Id: <20200603222247.11681-3-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Stefano Stabellini The parameter is unused in this patch. No functional changes. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- drivers/xen/swiotlb-xen.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index ed09f8ac34c5..1c44dbc69b70 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -57,7 +57,7 @@ static unsigned long xen_io_tlb_nslabs; * can be 32bit when dma_addr_t is 64bit leading to a loss in * information if the shift is done before casting to 64bit. */ -static inline dma_addr_t xen_phys_to_bus(phys_addr_t paddr) +static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) { unsigned long bfn = pfn_to_bfn(XEN_PFN_DOWN(paddr)); dma_addr_t dma = (dma_addr_t)bfn << XEN_PAGE_SHIFT; @@ -78,9 +78,9 @@ static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr) return paddr; } -static inline dma_addr_t xen_virt_to_bus(void *address) +static inline dma_addr_t xen_virt_to_bus(struct device *dev, void *address) { - return xen_phys_to_bus(virt_to_phys(address)); + return xen_phys_to_bus(dev, virt_to_phys(address)); } static inline int range_straddles_page_boundary(phys_addr_t p, size_t size) @@ -309,7 +309,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size, * Do not use virt_to_phys(ret) because on ARM it doesn't correspond * to *dma_handle. */ phys = *dma_handle; - dev_addr = xen_phys_to_bus(phys); + dev_addr = xen_phys_to_bus(hwdev, phys); if (((dev_addr + size - 1 <= dma_mask)) && !range_straddles_page_boundary(phys, size)) *dma_handle = dev_addr; @@ -367,7 +367,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page, unsigned long attrs) { phys_addr_t map, phys = page_to_phys(page) + offset; - dma_addr_t dev_addr = xen_phys_to_bus(phys); + dma_addr_t dev_addr = xen_phys_to_bus(dev, phys); BUG_ON(dir == DMA_NONE); /* @@ -392,7 +392,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page, return DMA_MAPPING_ERROR; phys = map; - dev_addr = xen_phys_to_bus(map); + dev_addr = xen_phys_to_bus(dev, map); /* * Ensure that the address returned is DMA'ble @@ -536,7 +536,7 @@ xen_swiotlb_sync_sg_for_device(struct device *dev, struct scatterlist *sgl, static int xen_swiotlb_dma_supported(struct device *hwdev, u64 mask) { - return xen_virt_to_bus(xen_io_tlb_end - 1) <= mask; + return xen_virt_to_bus(hwdev, xen_io_tlb_end - 1) <= mask; } const struct dma_map_ops xen_swiotlb_dma_ops = { -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:22:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:22:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmd-0004av-Ve; Wed, 03 Jun 2020 22:22:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmd-0004ac-62 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:22:51 +0000 X-Inumbo-ID: c205ff4a-a5e8-11ea-adbf-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c205ff4a-a5e8-11ea-adbf-12813bfff9fa; Wed, 03 Jun 2020 22:22:49 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D431C2067B; Wed, 3 Jun 2020 22:22:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222969; bh=KkHGhoUNVUm6PPU2Wc3n69d1PFrjoUPau99hvQGcD1E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iS/9d1NEK4nODfzf/8QcScf3N+hmvvrgLTCxl91JpBRBcydxeV138kYdTqiJMEt9b nhYp1DoW/P0X+h2Do5xbSeYfbg7p+rgwfDoq04oiBlfmzPiGObo11WusHd99feCP+G hdz7+XBkfDJCmzl8jFCi1R+GtcVCvV0kGA2FLHcQ= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 01/11] swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses Date: Wed, 3 Jun 2020 15:22:37 -0700 Message-Id: <20200603222247.11681-1-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Boris Ostrovsky xen_alloc_coherent_pages might return pages for which virt_to_phys and virt_to_page don't work, e.g. ioremap'ed pages. So in xen_swiotlb_free_coherent we can't assume that virt_to_page works. Instead add a is_vmalloc_addr check and use vmalloc_to_page on vmalloc virt addresses. This patch fixes the following crash at boot on RPi4: https://marc.info/?l=xen-devel&m=158862573216800 Signed-off-by: Boris Ostrovsky Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- Changes in v2: - update commit message --- drivers/xen/swiotlb-xen.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index b6d27762c6f8..a42129cba36e 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -335,6 +335,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, int order = get_order(size); phys_addr_t phys; u64 dma_mask = DMA_BIT_MASK(32); + struct page *pg; if (hwdev && hwdev->coherent_dma_mask) dma_mask = hwdev->coherent_dma_mask; @@ -346,9 +347,11 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, /* Convert the size to actually allocated. */ size = 1UL << (order + XEN_PAGE_SHIFT); + pg = is_vmalloc_addr(vaddr) ? vmalloc_to_page(vaddr) : + virt_to_page(vaddr); if (!WARN_ON((dev_addr + size - 1 > dma_mask) || range_straddles_page_boundary(phys, size)) && - TestClearPageXenRemapped(virt_to_page(vaddr))) + TestClearPageXenRemapped(pg)) xen_destroy_contiguous_region(phys, order); xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs); -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:22:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:22:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbme-0004bt-N2; Wed, 03 Jun 2020 22:22:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmd-0004ao-KV for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:22:51 +0000 X-Inumbo-ID: c2f0fc0c-a5e8-11ea-81bc-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c2f0fc0c-a5e8-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 22:22:51 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6AE2320810; Wed, 3 Jun 2020 22:22:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222970; bh=9EMRvn5Dc8JT3MH0CrfmZw6otCxJqhqF6+OrT0rmyo4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UMkfTrY//kEo3frQh5UBqXlCY9gFA+q6O15I10yf40UHEg4tU61PHkQsi8VdYPfSO xsOTh7eIQ4IPEZPYj3ZapuGsrb9NoQ7wtwIaS1B35AciFYGS+Ad43u6D+yn07Q0fQN barpbM44FRjfXKV+ngWD+/yMJGKIZKzXQEoDlbe4= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 04/11] swiotlb-xen: add struct device* parameter to xen_bus_to_phys Date: Wed, 3 Jun 2020 15:22:40 -0700 Message-Id: <20200603222247.11681-4-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Stefano Stabellini The parameter is unused in this patch. No functional changes. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- drivers/xen/swiotlb-xen.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 1c44dbc69b70..e38a1cce4100 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -67,7 +67,7 @@ static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) return dma; } -static inline phys_addr_t xen_bus_to_phys(dma_addr_t baddr) +static inline phys_addr_t xen_bus_to_phys(struct device *dev, dma_addr_t baddr) { unsigned long xen_pfn = bfn_to_pfn(XEN_PFN_DOWN(baddr)); dma_addr_t dma = (dma_addr_t)xen_pfn << XEN_PAGE_SHIFT; @@ -339,7 +339,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, /* do not use virt_to_phys because on ARM it doesn't return you the * physical address */ - phys = xen_bus_to_phys(dev_addr); + phys = xen_bus_to_phys(hwdev, dev_addr); /* Convert the size to actually allocated. */ size = 1UL << (order + XEN_PAGE_SHIFT); @@ -420,7 +420,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page, static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr, size_t size, enum dma_data_direction dir, unsigned long attrs) { - phys_addr_t paddr = xen_bus_to_phys(dev_addr); + phys_addr_t paddr = xen_bus_to_phys(hwdev, dev_addr); BUG_ON(dir == DMA_NONE); @@ -436,7 +436,7 @@ static void xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr, size_t size, enum dma_data_direction dir) { - phys_addr_t paddr = xen_bus_to_phys(dma_addr); + phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr); if (!dev_is_dma_coherent(dev)) xen_dma_sync_for_cpu(dma_addr, paddr, size, dir); @@ -449,7 +449,7 @@ static void xen_swiotlb_sync_single_for_device(struct device *dev, dma_addr_t dma_addr, size_t size, enum dma_data_direction dir) { - phys_addr_t paddr = xen_bus_to_phys(dma_addr); + phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr); if (is_xen_swiotlb_buffer(dma_addr)) swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE); -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:22:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:22:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmi-0004eZ-W5; Wed, 03 Jun 2020 22:22:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmi-0004e1-6H for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:22:56 +0000 X-Inumbo-ID: c2534aac-a5e8-11ea-adbf-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c2534aac-a5e8-11ea-adbf-12813bfff9fa; Wed, 03 Jun 2020 22:22:50 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 62443207D0; Wed, 3 Jun 2020 22:22:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222969; bh=z/W3HOqwZFpxh5RTvZrhBEC0DsqYoSYR2jgxAVw6hXQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A8Gw2iZrApw37MILwEXd0XFn8MbQQTyVONoBAo2odDCqo4bx9EMQ0+3ZRahBnmF3c 0SbM5LE5YCEo4zkcQTFe/l6VXtj6IYfiLHSIpwoMiuBD/hlmH+w7eZtnJoVwe8uH1F EBekaEg39hytF9DxdM0Q7iKp0OHg9bfrinazSkS8= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 02/11] swiotlb-xen: remove start_dma_addr Date: Wed, 3 Jun 2020 15:22:38 -0700 Message-Id: <20200603222247.11681-2-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Stefano Stabellini It is not strictly needed. Call virt_to_phys on xen_io_tlb_start instead. It will be useful not to have a start_dma_addr around with the next patches. Note that virt_to_phys is not the same as xen_virt_to_bus but actually it is used to compared again __pa(xen_io_tlb_start) as passed to swiotlb_init_with_tbl, so virt_to_phys is actually what we want. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- Changes in v2: - update commit message --- --- drivers/xen/swiotlb-xen.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index a42129cba36e..ed09f8ac34c5 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -52,8 +52,6 @@ static unsigned long xen_io_tlb_nslabs; * Quick lookup value of the bus address of the IOTLB. */ -static u64 start_dma_addr; - /* * Both of these functions should avoid XEN_PFN_PHYS because phys_addr_t * can be 32bit when dma_addr_t is 64bit leading to a loss in @@ -241,7 +239,6 @@ int __ref xen_swiotlb_init(int verbose, bool early) m_ret = XEN_SWIOTLB_EFIXUP; goto error; } - start_dma_addr = xen_virt_to_bus(xen_io_tlb_start); if (early) { if (swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs, verbose)) @@ -389,8 +386,8 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page, */ trace_swiotlb_bounced(dev, dev_addr, size, swiotlb_force); - map = swiotlb_tbl_map_single(dev, start_dma_addr, phys, - size, size, dir, attrs); + map = swiotlb_tbl_map_single(dev, virt_to_phys(xen_io_tlb_start), + phys, size, size, dir, attrs); if (map == (phys_addr_t)DMA_MAPPING_ERROR) return DMA_MAPPING_ERROR; -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:22:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:22:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmj-0004eu-88; Wed, 03 Jun 2020 22:22:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmi-0004e2-6b for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:22:56 +0000 X-Inumbo-ID: c4728ac8-a5e8-11ea-9dbe-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c4728ac8-a5e8-11ea-9dbe-bc764e2007e4; Wed, 03 Jun 2020 22:22:53 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EAB97207F5; Wed, 3 Jun 2020 22:22:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222973; bh=p13t7h6OgZd3c3rlyfugdVMmCRk9goZBfF3/sQLkgpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AurZxJAJFOB7GSce2yJBE5z0Eu104WUXUTPvSKeFv/irIMHX/PuBIfT0tdjwggKaW 7GCQsJ2VWCh327dm4Ybc2CJe54tOeeR6oSZ7Eo14y3kYiRMph040HSWsEV6/ddWT2r FSteCb/rY0YjJJSQg6BgK7qST3egSc9aGEbLg8l0= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 09/11] swiotlb-xen: rename xen_phys_to_bus to xen_phys_to_dma and xen_bus_to_phys to xen_dma_to_phys Date: Wed, 3 Jun 2020 15:22:45 -0700 Message-Id: <20200603222247.11681-9-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" so that their names can better describe their behavior. No functional changes. Signed-off-by: Stefano Stabellini --- drivers/xen/swiotlb-xen.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 60ef07440905..41129c02d59a 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -57,7 +57,7 @@ static unsigned long xen_io_tlb_nslabs; * can be 32bit when dma_addr_t is 64bit leading to a loss in * information if the shift is done before casting to 64bit. */ -static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) +static inline dma_addr_t xen_phys_to_dma(struct device *dev, phys_addr_t paddr) { unsigned long bfn = pfn_to_bfn(XEN_PFN_DOWN(paddr)); dma_addr_t dma = (dma_addr_t)bfn << XEN_PAGE_SHIFT; @@ -67,7 +67,7 @@ static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) return phys_to_dma(dev, dma); } -static inline phys_addr_t xen_bus_to_phys(struct device *dev, +static inline phys_addr_t xen_dma_to_phys(struct device *dev, dma_addr_t dma_addr) { phys_addr_t baddr = dma_to_phys(dev, dma_addr); @@ -80,7 +80,7 @@ static inline phys_addr_t xen_bus_to_phys(struct device *dev, static inline dma_addr_t xen_virt_to_bus(struct device *dev, void *address) { - return xen_phys_to_bus(dev, virt_to_phys(address)); + return xen_phys_to_dma(dev, virt_to_phys(address)); } static inline int range_straddles_page_boundary(phys_addr_t p, size_t size) @@ -309,7 +309,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size, * Do not use virt_to_phys(ret) because on ARM it doesn't correspond * to *dma_handle. */ phys = dma_to_phys(hwdev, *dma_handle); - dev_addr = xen_phys_to_bus(hwdev, phys); + dev_addr = xen_phys_to_dma(hwdev, phys); if (((dev_addr + size - 1 <= dma_mask)) && !range_straddles_page_boundary(phys, size)) *dma_handle = dev_addr; @@ -340,7 +340,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, /* do not use virt_to_phys because on ARM it doesn't return you the * physical address */ - phys = xen_bus_to_phys(hwdev, dev_addr); + phys = xen_dma_to_phys(hwdev, dev_addr); /* Convert the size to actually allocated. */ size = 1UL << (order + XEN_PAGE_SHIFT); @@ -369,7 +369,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page, unsigned long attrs) { phys_addr_t map, phys = page_to_phys(page) + offset; - dma_addr_t dev_addr = xen_phys_to_bus(dev, phys); + dma_addr_t dev_addr = xen_phys_to_dma(dev, phys); BUG_ON(dir == DMA_NONE); /* @@ -394,7 +394,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page, return DMA_MAPPING_ERROR; phys = map; - dev_addr = xen_phys_to_bus(dev, map); + dev_addr = xen_phys_to_dma(dev, map); /* * Ensure that the address returned is DMA'ble @@ -422,7 +422,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page, static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr, size_t size, enum dma_data_direction dir, unsigned long attrs) { - phys_addr_t paddr = xen_bus_to_phys(hwdev, dev_addr); + phys_addr_t paddr = xen_dma_to_phys(hwdev, dev_addr); BUG_ON(dir == DMA_NONE); @@ -438,7 +438,7 @@ static void xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr, size_t size, enum dma_data_direction dir) { - phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr); + phys_addr_t paddr = xen_dma_to_phys(dev, dma_addr); if (!dev_is_dma_coherent(dev)) xen_dma_sync_for_cpu(dev, dma_addr, paddr, size, dir); @@ -451,7 +451,7 @@ static void xen_swiotlb_sync_single_for_device(struct device *dev, dma_addr_t dma_addr, size_t size, enum dma_data_direction dir) { - phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr); + phys_addr_t paddr = xen_dma_to_phys(dev, dma_addr); if (is_xen_swiotlb_buffer(dev, dma_addr)) swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE); -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:23:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:23:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmo-0004iS-JE; Wed, 03 Jun 2020 22:23:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmn-0004hd-5s for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:23:01 +0000 X-Inumbo-ID: c33e5a56-a5e8-11ea-adbf-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c33e5a56-a5e8-11ea-adbf-12813bfff9fa; Wed, 03 Jun 2020 22:22:51 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E818620825; Wed, 3 Jun 2020 22:22:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222971; bh=hleYg6Qbw/sbGMUlPa36xrs33ic7PVU17RkZWi4JSOc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H48sy6PRrexnpig6zg/Ifh30welmOW/RgCZvJE24bKzptkLnoHxe6CD3XtYznJR1Z g/7vTXEThsmDhDcUXgnxo/kYi4ETQVwDvUV+okySRzaDfRNfrGuv1spo860JgzG17Y 2jGkWt59KGDd6Ii1SepySY0X9yhSSXtlJcc+dhQ8= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 05/11] swiotlb-xen: add struct device* parameter to xen_dma_sync_for_cpu Date: Wed, 3 Jun 2020 15:22:41 -0700 Message-Id: <20200603222247.11681-5-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Stefano Stabellini The parameter is unused in this patch. No functional changes. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- arch/arm/xen/mm.c | 5 +++-- drivers/xen/swiotlb-xen.c | 4 ++-- include/xen/swiotlb-xen.h | 5 +++-- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index d40e9e5fc52b..1a00e8003c64 100644 --- a/arch/arm/xen/mm.c +++ b/arch/arm/xen/mm.c @@ -71,8 +71,9 @@ static void dma_cache_maint(dma_addr_t handle, size_t size, u32 op) * pfn_valid returns true the pages is local and we can use the native * dma-direct functions, otherwise we call the Xen specific version. */ -void xen_dma_sync_for_cpu(dma_addr_t handle, phys_addr_t paddr, size_t size, - enum dma_data_direction dir) +void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, + phys_addr_t paddr, size_t size, + enum dma_data_direction dir) { if (pfn_valid(PFN_DOWN(handle))) arch_sync_dma_for_cpu(paddr, size, dir); diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index e38a1cce4100..d9b3d9f2a7d1 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -425,7 +425,7 @@ static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr, BUG_ON(dir == DMA_NONE); if (!dev_is_dma_coherent(hwdev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) - xen_dma_sync_for_cpu(dev_addr, paddr, size, dir); + xen_dma_sync_for_cpu(hwdev, dev_addr, paddr, size, dir); /* NOTE: We use dev_addr here, not paddr! */ if (is_xen_swiotlb_buffer(dev_addr)) @@ -439,7 +439,7 @@ xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr, phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr); if (!dev_is_dma_coherent(dev)) - xen_dma_sync_for_cpu(dma_addr, paddr, size, dir); + xen_dma_sync_for_cpu(dev, dma_addr, paddr, size, dir); if (is_xen_swiotlb_buffer(dma_addr)) swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_CPU); diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h index ffc0d3902b71..f62d1854780b 100644 --- a/include/xen/swiotlb-xen.h +++ b/include/xen/swiotlb-xen.h @@ -4,8 +4,9 @@ #include -void xen_dma_sync_for_cpu(dma_addr_t handle, phys_addr_t paddr, size_t size, - enum dma_data_direction dir); +void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, + phys_addr_t paddr, size_t size, + enum dma_data_direction dir); void xen_dma_sync_for_device(dma_addr_t handle, phys_addr_t paddr, size_t size, enum dma_data_direction dir); -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:23:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:23:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmo-0004il-S1; Wed, 03 Jun 2020 22:23:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmn-0004he-78 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:23:01 +0000 X-Inumbo-ID: c4bafb82-a5e8-11ea-8993-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c4bafb82-a5e8-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 22:22:54 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7467820734; Wed, 3 Jun 2020 22:22:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222973; bh=Hrv3PVcXYaGZU+pmnuCIi7L6rjwMar9STJmksuaPXR4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RkQYce7A5IplQKy36VI3JG/7NujFadE1r+EI0c7RL3uFRJEv69DT3i7TAokkTisYb OkLyN10vvmp1i3ZZTO217L6kktfqJefvAssILhG2e3n3170XdT5olphDHA/tvEY80M ndiCNcRva4MAWM/5xUun6d1LH7Ih6/Zg1XaGuG24= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_* Date: Wed, 3 Jun 2020 15:22:46 -0700 Message-Id: <20200603222247.11681-10-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Stefano Stabellini xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are getting called passing dma addresses. On some platforms dma addresses could be different from physical addresses. Before doing any operations on these addresses we need to convert them back to physical addresses using dma_to_phys. Add dma_to_phys calls to xen_dma_sync_for_cpu, xen_dma_sync_for_device, and xen_arch_need_swiotlb. dma_cache_maint is fixed by the next patch. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- Changes in v2: - improve commit message - don't use pfn_valid --- arch/arm/xen/mm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index f2414ea40a79..bbad712a890d 100644 --- a/arch/arm/xen/mm.c +++ b/arch/arm/xen/mm.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-only #include +#include #include #include #include @@ -75,7 +76,7 @@ void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, phys_addr_t paddr, size_t size, enum dma_data_direction dir) { - if (pfn_valid(PFN_DOWN(handle))) + if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle)))) arch_sync_dma_for_cpu(paddr, size, dir); else if (dir != DMA_TO_DEVICE) dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL); @@ -85,7 +86,7 @@ void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle, phys_addr_t paddr, size_t size, enum dma_data_direction dir) { - if (pfn_valid(PFN_DOWN(handle))) + if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle)))) arch_sync_dma_for_device(paddr, size, dir); else if (dir == DMA_FROM_DEVICE) dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL); @@ -98,7 +99,7 @@ bool xen_arch_need_swiotlb(struct device *dev, dma_addr_t dev_addr) { unsigned int xen_pfn = XEN_PFN_DOWN(phys); - unsigned int bfn = XEN_PFN_DOWN(dev_addr); + unsigned int bfn = XEN_PFN_DOWN(dma_to_phys(dev, dev_addr)); /* * The swiotlb buffer should be used if -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:23:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:23:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmt-0004mN-7E; Wed, 03 Jun 2020 22:23:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbms-0004lR-5w for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:23:06 +0000 X-Inumbo-ID: c38d7f6e-a5e8-11ea-adbf-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c38d7f6e-a5e8-11ea-adbf-12813bfff9fa; Wed, 03 Jun 2020 22:22:52 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6D2EF20829; Wed, 3 Jun 2020 22:22:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222971; bh=nFPjt4xgM/UfJuFdimg7/s4ZMaLcT6FSSZOQ40J3kTw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZVoeRa4O3eMIypf/td9dPsshZyL3824CEB0vUz9dxYjRwAY2AY0cyFWPcNa8PZvNk Q0mogU5QtAE7AI0+UjtnixCEXyEj9GvIesGSo1aXychYg/UTS6AzKd5+SMogSZT5To MqxGPMv56WACn0tKs1AS8IJKC7RTUH29U/81d5qI= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 06/11] swiotlb-xen: add struct device* parameter to xen_dma_sync_for_device Date: Wed, 3 Jun 2020 15:22:42 -0700 Message-Id: <20200603222247.11681-6-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Stefano Stabellini The parameter is unused in this patch. No functional changes. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- arch/arm/xen/mm.c | 5 +++-- drivers/xen/swiotlb-xen.c | 4 ++-- include/xen/swiotlb-xen.h | 5 +++-- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index 1a00e8003c64..f2414ea40a79 100644 --- a/arch/arm/xen/mm.c +++ b/arch/arm/xen/mm.c @@ -81,8 +81,9 @@ void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL); } -void xen_dma_sync_for_device(dma_addr_t handle, phys_addr_t paddr, size_t size, - enum dma_data_direction dir) +void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle, + phys_addr_t paddr, size_t size, + enum dma_data_direction dir) { if (pfn_valid(PFN_DOWN(handle))) arch_sync_dma_for_device(paddr, size, dir); diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index d9b3d9f2a7d1..9b846c143c90 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -405,7 +405,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, struct page *page, done: if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) - xen_dma_sync_for_device(dev_addr, phys, size, dir); + xen_dma_sync_for_device(dev, dev_addr, phys, size, dir); return dev_addr; } @@ -455,7 +455,7 @@ xen_swiotlb_sync_single_for_device(struct device *dev, dma_addr_t dma_addr, swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE); if (!dev_is_dma_coherent(dev)) - xen_dma_sync_for_device(dma_addr, paddr, size, dir); + xen_dma_sync_for_device(dev, dma_addr, paddr, size, dir); } /* diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h index f62d1854780b..6d235fe2b92d 100644 --- a/include/xen/swiotlb-xen.h +++ b/include/xen/swiotlb-xen.h @@ -7,8 +7,9 @@ void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, phys_addr_t paddr, size_t size, enum dma_data_direction dir); -void xen_dma_sync_for_device(dma_addr_t handle, phys_addr_t paddr, size_t size, - enum dma_data_direction dir); +void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle, + phys_addr_t paddr, size_t size, + enum dma_data_direction dir); extern int xen_swiotlb_init(int verbose, bool early); extern const struct dma_map_ops xen_swiotlb_dma_ops; -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:23:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:23:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmt-0004mm-HR; Wed, 03 Jun 2020 22:23:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbms-0004lW-7l for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:23:06 +0000 X-Inumbo-ID: c502df1a-a5e8-11ea-81bc-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c502df1a-a5e8-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 22:22:54 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E899D20897; Wed, 3 Jun 2020 22:22:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222974; bh=lK4AfabqfBMg+UgGk9XZHrVioJuYeQJmxxbhRHjLG1Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HU0yb8Se8hTNLEEvdnECpahuasRiicyLghp6oTLQ6baEadzpC09vZdyPb/DNQntF5 2cm5wkWTrm3qbvlueLnW1tYtdJd8pLuLNtcbZd/mDyiu2uPR+ZrQ7jvTXiQetm74Ec xqJAsL1OE7ZMCQrK2T3CUYQVNY6ZfhynSrMCDYa8= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 11/11] xen/arm: call dma_to_phys on the dma_addr_t parameter of dma_cache_maint Date: Wed, 3 Jun 2020 15:22:47 -0700 Message-Id: <20200603222247.11681-11-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Stefano Stabellini dma_cache_maint is getting called passing a dma address which could be different from a physical address. Add a struct device* parameter to dma_cache_maint. Translate the dma_addr_t parameter of dma_cache_maint by calling dma_to_phys. Do it for the first page and all the following pages, in case of multipage handling. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- Changes in v2: - improve commit message --- arch/arm/xen/mm.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index bbad712a890d..1dc20f4bdc33 100644 --- a/arch/arm/xen/mm.c +++ b/arch/arm/xen/mm.c @@ -43,15 +43,18 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order) static bool hypercall_cflush = false; /* buffers in highmem or foreign pages cannot cross page boundaries */ -static void dma_cache_maint(dma_addr_t handle, size_t size, u32 op) +static void dma_cache_maint(struct device *dev, dma_addr_t handle, + size_t size, u32 op) { struct gnttab_cache_flush cflush; - cflush.a.dev_bus_addr = handle & XEN_PAGE_MASK; cflush.offset = xen_offset_in_page(handle); cflush.op = op; + handle &= XEN_PAGE_MASK; do { + cflush.a.dev_bus_addr = dma_to_phys(dev, handle); + if (size + cflush.offset > XEN_PAGE_SIZE) cflush.length = XEN_PAGE_SIZE - cflush.offset; else @@ -60,7 +63,7 @@ static void dma_cache_maint(dma_addr_t handle, size_t size, u32 op) HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1); cflush.offset = 0; - cflush.a.dev_bus_addr += cflush.length; + handle += cflush.length; size -= cflush.length; } while (size); } @@ -79,7 +82,7 @@ void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle)))) arch_sync_dma_for_cpu(paddr, size, dir); else if (dir != DMA_TO_DEVICE) - dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL); + dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL); } void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle, @@ -89,9 +92,9 @@ void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle, if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle)))) arch_sync_dma_for_device(paddr, size, dir); else if (dir == DMA_FROM_DEVICE) - dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL); + dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL); else - dma_cache_maint(handle, size, GNTTAB_CACHE_CLEAN); + dma_cache_maint(dev, handle, size, GNTTAB_CACHE_CLEAN); } bool xen_arch_need_swiotlb(struct device *dev, -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:23:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:23:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmy-0004rm-1S; Wed, 03 Jun 2020 22:23:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbmx-0004qu-5u for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:23:11 +0000 X-Inumbo-ID: c3d72efc-a5e8-11ea-adbf-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c3d72efc-a5e8-11ea-adbf-12813bfff9fa; Wed, 03 Jun 2020 22:22:52 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EA27C20872; Wed, 3 Jun 2020 22:22:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222972; bh=rOC8u/GP/YnBySLRTiNQTpMbuYdIjD0O7PCIgWG9wIE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hu2DRe+TkdcV+6abc7EOrpvaGRQAjn0UTkKID03ucjKZlicTCoUJ/0mOTE7Q0GdBn cpB8oj/ZrHJub+xseWoI3lPp1ARiFe+gh3jDJOUsq0PDZjjtAHyl1p6+aALT5p2pFL xgwEM8EVciiWcURbrwdY+NsDEdR1wLDmTAe8nRNc= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 07/11] swiotlb-xen: add struct device* parameter to is_xen_swiotlb_buffer Date: Wed, 3 Jun 2020 15:22:43 -0700 Message-Id: <20200603222247.11681-7-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Stefano Stabellini The parameter is unused in this patch. No functional changes. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- drivers/xen/swiotlb-xen.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 9b846c143c90..0a6cb67f0fc4 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -97,7 +97,7 @@ static inline int range_straddles_page_boundary(phys_addr_t p, size_t size) return 0; } -static int is_xen_swiotlb_buffer(dma_addr_t dma_addr) +static int is_xen_swiotlb_buffer(struct device *dev, dma_addr_t dma_addr) { unsigned long bfn = XEN_PFN_DOWN(dma_addr); unsigned long xen_pfn = bfn_to_local_pfn(bfn); @@ -428,7 +428,7 @@ static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr, xen_dma_sync_for_cpu(hwdev, dev_addr, paddr, size, dir); /* NOTE: We use dev_addr here, not paddr! */ - if (is_xen_swiotlb_buffer(dev_addr)) + if (is_xen_swiotlb_buffer(hwdev, dev_addr)) swiotlb_tbl_unmap_single(hwdev, paddr, size, size, dir, attrs); } @@ -441,7 +441,7 @@ xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr, if (!dev_is_dma_coherent(dev)) xen_dma_sync_for_cpu(dev, dma_addr, paddr, size, dir); - if (is_xen_swiotlb_buffer(dma_addr)) + if (is_xen_swiotlb_buffer(dev, dma_addr)) swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_CPU); } @@ -451,7 +451,7 @@ xen_swiotlb_sync_single_for_device(struct device *dev, dma_addr_t dma_addr, { phys_addr_t paddr = xen_bus_to_phys(dev, dma_addr); - if (is_xen_swiotlb_buffer(dma_addr)) + if (is_xen_swiotlb_buffer(dev, dma_addr)) swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE); if (!dev_is_dma_coherent(dev)) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:23:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:23:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbn3-0004xM-Ce; Wed, 03 Jun 2020 22:23:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbn2-0004wH-6e for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:23:16 +0000 X-Inumbo-ID: c42582a0-a5e8-11ea-adbf-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c42582a0-a5e8-11ea-adbf-12813bfff9fa; Wed, 03 Jun 2020 22:22:53 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6D5D6207ED; Wed, 3 Jun 2020 22:22:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591222972; bh=+z55nUlwZHxq9stQuss6H0bHixpaR3RARWD3UmReZtk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A6ia45bnDvUyQkxDk+aoX+tqGp81s5QYe9FvIOXr9V8o56IcdT842aYnX5xSpdRLf EcLyEWx6YxKPWFBZRUWoL3CSCiAne8JEWk5TnFtJEl42rqbJt+bTaCv0a3cIBYT0Cn jviQoYUCQs/dtqo1eNn6gWFdozsjjrBggRJoOsJ0= From: Stefano Stabellini To: jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations Date: Wed, 3 Jun 2020 15:22:44 -0700 Message-Id: <20200603222247.11681-8-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Stefano Stabellini With some devices physical addresses are different than dma addresses. To be able to deal with these cases, we need to call phys_to_dma on physical addresses (including machine addresses in Xen terminology) before returning them from xen_swiotlb_alloc_coherent and xen_swiotlb_map_page. We also need to convert dma addresses back to physical addresses using dma_to_phys in xen_swiotlb_free_coherent and xen_swiotlb_unmap_page if we want to do any operations on them. Call dma_to_phys in is_xen_swiotlb_buffer. Call phys_to_dma in xen_phys_to_bus. Call dma_to_phys in xen_bus_to_phys. Everything is taken care of by these changes except for xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a few explicit phys_to_dma/dma_to_phys calls. Signed-off-by: Stefano Stabellini Tested-by: Corey Minyard Tested-by: Roman Shaposhnik --- Changes in v2: - improve commit message --- drivers/xen/swiotlb-xen.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index 0a6cb67f0fc4..60ef07440905 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) dma |= paddr & ~XEN_PAGE_MASK; - return dma; + return phys_to_dma(dev, dma); } -static inline phys_addr_t xen_bus_to_phys(struct device *dev, dma_addr_t baddr) +static inline phys_addr_t xen_bus_to_phys(struct device *dev, + dma_addr_t dma_addr) { + phys_addr_t baddr = dma_to_phys(dev, dma_addr); unsigned long xen_pfn = bfn_to_pfn(XEN_PFN_DOWN(baddr)); - dma_addr_t dma = (dma_addr_t)xen_pfn << XEN_PAGE_SHIFT; - phys_addr_t paddr = dma; - - paddr |= baddr & ~XEN_PAGE_MASK; + phys_addr_t paddr = (xen_pfn << XEN_PAGE_SHIFT) | + (baddr & ~XEN_PAGE_MASK); return paddr; } @@ -99,7 +99,7 @@ static inline int range_straddles_page_boundary(phys_addr_t p, size_t size) static int is_xen_swiotlb_buffer(struct device *dev, dma_addr_t dma_addr) { - unsigned long bfn = XEN_PFN_DOWN(dma_addr); + unsigned long bfn = XEN_PFN_DOWN(dma_to_phys(dev, dma_addr)); unsigned long xen_pfn = bfn_to_local_pfn(bfn); phys_addr_t paddr = XEN_PFN_PHYS(xen_pfn); @@ -304,11 +304,11 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size, if (hwdev && hwdev->coherent_dma_mask) dma_mask = hwdev->coherent_dma_mask; - /* At this point dma_handle is the physical address, next we are + /* At this point dma_handle is the dma address, next we are * going to set it to the machine address. * Do not use virt_to_phys(ret) because on ARM it doesn't correspond * to *dma_handle. */ - phys = *dma_handle; + phys = dma_to_phys(hwdev, *dma_handle); dev_addr = xen_phys_to_bus(hwdev, phys); if (((dev_addr + size - 1 <= dma_mask)) && !range_straddles_page_boundary(phys, size)) @@ -319,6 +319,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size, xen_free_coherent_pages(hwdev, size, ret, (dma_addr_t)phys, attrs); return NULL; } + *dma_handle = phys_to_dma(hwdev, *dma_handle); SetPageXenRemapped(virt_to_page(ret)); } memset(ret, 0, size); @@ -351,7 +352,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, TestClearPageXenRemapped(pg)) xen_destroy_contiguous_region(phys, order); - xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs); + xen_free_coherent_pages(hwdev, size, vaddr, phys_to_dma(hwdev, phys), + attrs); } /* -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:32:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:32:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbvU-0006hC-9z; Wed, 03 Jun 2020 22:32:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgbvT-0006h7-1j for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:31:59 +0000 X-Inumbo-ID: 092b3416-a5ea-11ea-81bc-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 092b3416-a5ea-11ea-81bc-bc764e2007e4; Wed, 03 Jun 2020 22:31:58 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s.hsd1.ca.comcast.net (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B954F2067B; Wed, 3 Jun 2020 22:31:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591223518; bh=y0pwcX6CXfJoRYSOzlsliNS8HcDu032oeBcqYJ8YDtg=; h=From:To:Cc:Subject:Date:From; b=Twr04paC3T7wh/8UQkngPzj2fBcGsMrA0yjHW6GpY1X0O340Ms5VtN0WgInBTuZtw X4FOAYf/+EyibX0EXZsJ4qKvGzC9ACNfyp/mgXoo5k9AT18Ed0iBLn5ojOdXCyn+ez 3zLEBDh7vgrLLVPd1tUJdcY86TBV6aFrDrYsFBlQ= From: Stefano Stabellini To: julien@xen.org Subject: [PATCH] xen/rpi4: implement watchdog-based reset Date: Wed, 3 Jun 2020 15:31:56 -0700 Message-Id: <20200603223156.12767-1-sstabellini@kernel.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: cminyard@mvista.com, tamas@tklengyel.com, roman@zededa.com, Stefano Stabellini , xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Touching the watchdog is required to be able to reboot the board. The implementation is based on drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. Signed-off-by: Stefano Stabellini --- xen/arch/arm/platforms/brcm-raspberry-pi.c | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c b/xen/arch/arm/platforms/brcm-raspberry-pi.c index f5ae58a7d5..0214ae2b3c 100644 --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c @@ -18,6 +18,10 @@ */ #include +#include +#include +#include +#include static const char *const rpi4_dt_compat[] __initconst = { @@ -37,12 +41,68 @@ static const struct dt_device_match rpi4_blacklist_dev[] __initconst = * The aux peripheral also shares a page with the aux UART. */ DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"), + /* Special device used for rebooting */ + DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"), { /* sentinel */ }, }; + +#define PM_PASSWORD 0x5a000000 +#define PM_RSTC 0x1c +#define PM_WDOG 0x24 +#define PM_RSTC_WRCFG_FULL_RESET 0x00000020 +#define PM_RSTC_WRCFG_CLR 0xffffffcf + +static void __iomem *rpi4_map_watchdog(void) +{ + void __iomem *base; + struct dt_device_node *node; + paddr_t start, len; + int ret; + + node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm"); + if ( !node ) + return NULL; + + ret = dt_device_get_address(node, 0, &start, &len); + if ( ret ) + { + dprintk(XENLOG_ERR, "Cannot read watchdog register address\n"); + return NULL; + } + + base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE); + if ( !base ) + { + dprintk(XENLOG_ERR, "Unable to map watchdog register!\n"); + return NULL; + } + + return base; +} + +static void rpi4_reset(void) +{ + u32 val; + void __iomem *base = rpi4_map_watchdog(); + if ( !base ) + return; + + /* use a timeout of 10 ticks (~150us) */ + writel(10 | PM_PASSWORD, base + PM_WDOG); + val = readl(base + PM_RSTC); + val &= PM_RSTC_WRCFG_CLR; + val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET; + writel(val, base + PM_RSTC); + + /* No sleeping, possibly atomic. */ + mdelay(1); +} + PLATFORM_START(rpi4, "Raspberry Pi 4") .compatible = rpi4_dt_compat, .blacklist_dev = rpi4_blacklist_dev, + .reset = rpi4_reset, .dma_bitsize = 30, PLATFORM_END -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:40:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:40:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgc3c-0007XC-4v; Wed, 03 Jun 2020 22:40:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgc3a-0007X7-UO for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:40:22 +0000 X-Inumbo-ID: 3536f436-a5eb-11ea-adc4-12813bfff9fa Received: from smtp-fw-9101.amazon.com (unknown [207.171.184.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3536f436-a5eb-11ea-adc4-12813bfff9fa; Wed, 03 Jun 2020 22:40:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591224023; x=1622760023; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=Myq6ZV85It0R/N8eLRhclOg1iR9ZpMgAQsNUyFxW00E=; b=NnQnwO0JfVBrOCEVdhRSeA4I93sEuDrZNXu4j8m6AscIntOfLMMQCz4J VFCAtlEqVwGzxpUj9mLcxLv3eYukp/V+RfrJLM+r9HDOcIAG/abIavv2T aKirMSKkHhJj7iOOduNXG9Bml2WR8tCGJ8ocpSLUORfl0+C/uamiiwE8q Y=; IronPort-SDR: HGlszbAaMjRlQSBHjzfb07Sq8D3XcgSehxso6VS97ueiDdkojxtD16vl+YaA7qNIELHPqOLb9F PkJE9W82B+IA== X-IronPort-AV: E=Sophos;i="5.73,470,1583193600"; d="scan'208";a="41391349" Subject: Re: [PATCH 04/12] x86/xen: add system core suspend and resume callbacks Thread-Topic: [PATCH 04/12] x86/xen: add system core suspend and resume callbacks Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-17c49630.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 03 Jun 2020 22:40:18 +0000 Received: from EX13MTAUWB001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-17c49630.us-east-1.amazon.com (Postfix) with ESMTPS id 5F279A179C; Wed, 3 Jun 2020 22:40:16 +0000 (UTC) Received: from EX13D05UWB001.ant.amazon.com (10.43.161.181) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 22:40:15 +0000 Received: from EX13D07UWB001.ant.amazon.com (10.43.161.238) by EX13D05UWB001.ant.amazon.com (10.43.161.181) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 22:40:15 +0000 Received: from EX13D07UWB001.ant.amazon.com ([10.43.161.238]) by EX13D07UWB001.ant.amazon.com ([10.43.161.238]) with mapi id 15.00.1497.006; Wed, 3 Jun 2020 22:40:15 +0000 From: "Agarwal, Anchal" To: Boris Ostrovsky , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "hpa@zytor.com" , "x86@kernel.org" , "jgross@suse.com" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "Kamata, Munehisa" , "sstabellini@kernel.org" , "konrad.wilk@oracle.com" , "roger.pau@citrix.com" , "axboe@kernel.dk" , "davem@davemloft.net" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "peterz@infradead.org" , "Valentin, Eduardo" , "Singh, Balbir" , "xen-devel@lists.xenproject.org" , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Woodhouse, David" , "benh@kernel.crashing.org" , "Agarwal, Anchal" Thread-Index: AQHWLjTkyZyRRrOMA06VZoqhuNYdW6jBUn0AgAXLpQA= Date: Wed, 3 Jun 2020 22:40:15 +0000 Message-ID: References: <79cf02631dc00e62ebf90410bfbbdb52fe7024cb.1589926004.git.anchalag@amazon.com> <4b577564-e4c3-0182-2b9e-5f79004f32a1@oracle.com> In-Reply-To: <4b577564-e4c3-0182-2b9e-5f79004f32a1@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.48] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ICAgIENBVVRJT046IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9y Z2FuaXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNz IHlvdSBjYW4gY29uZmlybSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUu DQoNCg0KDQogICAgT24gNS8xOS8yMCA3OjI2IFBNLCBBbmNoYWwgQWdhcndhbCB3cm90ZToNCiAg ICA+IEZyb206IE11bmVoaXNhIEthbWF0YSA8a2FtYXRhbUBhbWF6b24uY29tPg0KICAgID4NCiAg ICA+IEFkZCBYZW4gUFZIVk0gc3BlY2lmaWMgc3lzdGVtIGNvcmUgY2FsbGJhY2tzIGZvciBQTSBz dXNwZW5kIGFuZA0KICAgID4gaGliZXJuYXRpb24gc3VwcG9ydC4gVGhlIGNhbGxiYWNrcyBzdXNw ZW5kIGFuZCByZXN1bWUgWGVuDQogICAgPiBwcmltaXRpdmVzLGxpa2Ugc2hhcmVkX2luZm8sIHB2 Y2xvY2sgYW5kIGdyYW50IHRhYmxlLiBOb3RlIHRoYXQNCiAgICA+IFhlbiBzdXNwZW5kIGNhbiBo YW5kbGUgdGhlbSBpbiBhIGRpZmZlcmVudCBtYW5uZXIsIGJ1dCBzeXN0ZW0NCiAgICA+IGNvcmUg Y2FsbGJhY2tzIGFyZSBjYWxsZWQgZnJvbSB0aGUgY29udGV4dC4NCg0KDQogICAgSSBkb24ndCB0 aGluayBJIHVuZGVyc3RhbmQgdGhhdCBsYXN0IHNlbnRlbmNlLg0KDQpMb29rcyBsaWtlIGl0IG1h eSBoYXZlIGNyeXB0aWMgbWVhbmluZyBvZiBzdGF0aW5nIHRoYXQgeGVuX3N1c3BlbmQgY2FsbHMg c3lzY29yZV9zdXNwZW5kIGZyb20geGVuX3N1c3BlbmQNClNvLCBpZiB0aGVzZSBzeXNjb3JlIG9w cyBnZXRzIGNhbGxlZCAgZHVyaW5nIHhlbl9zdXNwZW5kIGRvIG5vdCBkbyBhbnl0aGluZy4gQ2hl Y2sgaWYgdGhlIG1vZGUgaXMgaW4geGVuIHN1c3BlbmQgDQphbmQgcmV0dXJuIGZyb20gdGhlcmUu IFRoZXNlIHN5c2NvcmVfb3BzIGFyZSBzcGVjaWZpY2FsbHkgZm9yIGRvbVUgaGliZXJuYXRpb24u DQpJIG11c3QgYWRtaXQsIEkgbWF5IGhhdmUgb3Zlcmxvb2tlZCBsYWNrIG9mIGV4cGxhbmF0aW9u IG9mIHNvbWUgaW1wbGljaXQgZGV0YWlscyBpbiB0aGUgb3JpZ2luYWwgY29tbWl0IG1zZy4gDQoN CiAgICA+ICBTbyBpZiB0aGUgY2FsbGJhY2tzDQogICAgPiBhcmUgY2FsbGVkIGZyb20gWGVuIHN1 c3BlbmQgY29udGV4dCwgcmV0dXJuIGltbWVkaWF0ZWx5Lg0KICAgID4NCg0KDQogICAgPiArDQog ICAgPiArc3RhdGljIGludCB4ZW5fc3lzY29yZV9zdXNwZW5kKHZvaWQpDQogICAgPiArew0KICAg ID4gKyAgICAgc3RydWN0IHhlbl9yZW1vdmVfZnJvbV9waHlzbWFwIHhyZnA7DQogICAgPiArICAg ICBpbnQgcmV0Ow0KICAgID4gKw0KICAgID4gKyAgICAgLyogWGVuIHN1c3BlbmQgZG9lcyBzaW1p bGFyIHN0dWZmcyBpbiBpdHMgb3duIGxvZ2ljICovDQogICAgPiArICAgICBpZiAoeGVuX3N1c3Bl bmRfbW9kZV9pc194ZW5fc3VzcGVuZCgpKQ0KICAgID4gKyAgICAgICAgICAgICByZXR1cm4gMDsN CiAgICA+ICsNCiAgICA+ICsgICAgIHhyZnAuZG9taWQgPSBET01JRF9TRUxGOw0KICAgID4gKyAg ICAgeHJmcC5ncGZuID0gX19wYShIWVBFUlZJU09SX3NoYXJlZF9pbmZvKSA+PiBQQUdFX1NISUZU Ow0KICAgID4gKw0KICAgID4gKyAgICAgcmV0ID0gSFlQRVJWSVNPUl9tZW1vcnlfb3AoWEVOTUVN X3JlbW92ZV9mcm9tX3BoeXNtYXAsICZ4cmZwKTsNCiAgICA+ICsgICAgIGlmICghcmV0KQ0KICAg ID4gKyAgICAgICAgICAgICBIWVBFUlZJU09SX3NoYXJlZF9pbmZvID0gJnhlbl9kdW1teV9zaGFy ZWRfaW5mbzsNCiAgICA+ICsNCiAgICA+ICsgICAgIHJldHVybiByZXQ7DQogICAgPiArfQ0KICAg ID4gKw0KICAgID4gK3N0YXRpYyB2b2lkIHhlbl9zeXNjb3JlX3Jlc3VtZSh2b2lkKQ0KICAgID4g K3sNCiAgICA+ICsgICAgIC8qIFhlbiBzdXNwZW5kIGRvZXMgc2ltaWxhciBzdHVmZnMgaW4gaXRz IG93biBsb2dpYyAqLw0KICAgID4gKyAgICAgaWYgKHhlbl9zdXNwZW5kX21vZGVfaXNfeGVuX3N1 c3BlbmQoKSkNCiAgICA+ICsgICAgICAgICAgICAgcmV0dXJuOw0KICAgID4gKw0KICAgID4gKyAg ICAgLyogTm8gbmVlZCB0byBzZXR1cCB2Y3B1X2luZm8gYXMgaXQncyBhbHJlYWR5IG1vdmVkIG9m ZiAqLw0KICAgID4gKyAgICAgeGVuX2h2bV9tYXBfc2hhcmVkX2luZm8oKTsNCiAgICA+ICsNCiAg ICA+ICsgICAgIHB2Y2xvY2tfcmVzdW1lKCk7DQogICAgPiArDQogICAgPiArICAgICBnbnR0YWJf cmVzdW1lKCk7DQoNCg0KICAgIERvIHlvdSBjYWxsIGdudHRhYl9zdXNwZW5kKCkgaW4gcG0gc3Vz cGVuZCBwYXRoPw0KTm8sIHNpbmNlIGl0IGRvZXMgbm90aGluZyBmb3IgSFZNIGd1ZXN0cy4gVGhl IHVubWFwX2ZyYW1lcyBpcyBvbmx5IGFwcGxpY2FibGUgZm9yIFBWIGd1ZXN0cyByaWdodD8NCg0K ICAgID4gK30NCiAgICA+ICsNCiAgICA+ICsvKg0KICAgID4gKyAqIFRoZXNlIGNhbGxiYWNrcyB3 aWxsIGJlIGNhbGxlZCB3aXRoIGludGVycnVwdHMgZGlzYWJsZWQgYW5kIHdoZW4gaGF2aW5nIG9u bHkNCiAgICA+ICsgKiBvbmUgQ1BVIG9ubGluZS4NCiAgICA+ICsgKi8NCiAgICA+ICtzdGF0aWMg c3RydWN0IHN5c2NvcmVfb3BzIHhlbl9odm1fc3lzY29yZV9vcHMgPSB7DQogICAgPiArICAgICAu c3VzcGVuZCA9IHhlbl9zeXNjb3JlX3N1c3BlbmQsDQogICAgPiArICAgICAucmVzdW1lID0geGVu X3N5c2NvcmVfcmVzdW1lDQogICAgPiArfTsNCiAgICA+ICsNCiAgICA+ICt2b2lkIF9faW5pdCB4 ZW5fc2V0dXBfc3lzY29yZV9vcHModm9pZCkNCiAgICA+ICt7DQogICAgPiArICAgICBpZiAoeGVu X2h2bV9kb21haW4oKSkNCg0KDQogICAgSGF2ZSB5b3UgdGVzdGVkIHRoaXMgKHRoZSB3aG9sZSBm ZWF0dXJlLCBub3QganVzdCB0aGlzIHBhdGNoKSB3aXRoIFBWSA0KICAgIGd1ZXN0IEJUVz8gQW5k IFBWSCBkb20wIGZvciB0aGF0IG1hdHRlcj8NCg0KTm8gSSBoYXZlbid0LiBUaGUgd2hvbGUgc2Vy aWVzIGlzIGp1c3QgdGVzdGVkIHdpdGggaHZtL3B2aHZtIGd1ZXN0cy4NCg0KICAgIC1ib3Jpcw0K VGhhbmtzLA0KQW5jaGFsDQoNCiAgICA+ICsgICAgICAgICAgICAgcmVnaXN0ZXJfc3lzY29yZV9v cHMoJnhlbl9odm1fc3lzY29yZV9vcHMpOw0KICAgID4gK30NCg0KDQoNCg0K From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:42:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:42:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgc5T-0007sS-FZ; Wed, 03 Jun 2020 22:42:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgc5S-0007sM-UF for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:42:18 +0000 X-Inumbo-ID: 79cb1578-a5eb-11ea-8993-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 79cb1578-a5eb-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 22:42:17 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: qNUUHcsHPR5/ZX5jfA7j6npFLJxUeGnPzbb4ZqKdxW5bVbQArf/pY3ydnF9iDS/6BcwVeUIPP+ yUyESqrysuG+3b1Q+7wVTG54qvd6IP2F7xMOV0nnckNU+PN2hvwNfX1a6cXm7Ica42rSJowKNU E7ho/Yp15AlvDzJoLaQ+7eBo5hvkO5eIuD1PIBmZjN0hKtMqYikPViBlOmmKoLCdxoNoq+VA7y Ki4Ig4JU/Jn4Vk7ueNSU21915059hJrg9ey6Ex/uAMziSqyy8nGuUXV+vhvC7WEy4iWE8hf3li oFc= X-SBRS: 2.7 X-MesageID: 19193519 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,470,1583211600"; d="scan'208";a="19193519" From: Igor Druzhinin To: Subject: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately Date: Wed, 3 Jun 2020 23:41:48 +0100 Message-ID: <1591224108-564-1-git-send-email-igor.druzhinin@citrix.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain; charset="y" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Igor Druzhinin , wl@xen.org, paul@xen.org, andrew.cooper3@citrix.com, george.dunlap@citrix.com, jbeulich@suse.com, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" A recalculation NPT fault doesn't always require additional handling in hvm_hap_nested_page_fault(), moreover in general case if there is no explicit handling done there - the fault is wrongly considered fatal. This covers a specific case of migration with vGPU assigned which uses direct MMIO mappings made by XEN_DOMCTL_memory_mapping hypercall: at a moment log-dirty is enabled globally, recalculation is requested for the whole guest memory including those mapped MMIO regions which causes a page fault being raised at the first access to them; but due to MMIO P2M type not having any explicit handling in hvm_hap_nested_page_fault() a domain is erroneously crashed with unhandled SVM violation. Instead of trying to be opportunistic - use safer approach and handle P2M recalculation in a separate NPT fault by attempting to retry after making the necessary adjustments. This is aligned with Intel behavior where there are separate VMEXITs for recalculation and EPT violations (faults) and only faults are handled in hvm_hap_nested_page_fault(). Do it by also unifying do_recalc return code with Intel implementation where returning 1 means P2M was actually changed. Since there was no case previously where p2m_pt_handle_deferred_changes() could return a positive value - it's safe to replace ">= 0" with just "== 0" in VMEXIT_NPF handler. finish_type_change() is also not affected by the change as being able to deal with >0 return value of p2m->recalc from EPT implementation. Reviewed-by: Jan Beulich Reviewed-by: Roger Pau Monné Signed-off-by: Igor Druzhinin --- Changes in v2: - replace rc with recalc_done bool - updated comment in finish_type_change() - significantly extended commit description Changes in v3: - covert bool to int implicitly - a little bit more info of the usecase in the message --- xen/arch/x86/hvm/svm/svm.c | 5 +++-- xen/arch/x86/mm/p2m-pt.c | 7 ++++++- xen/arch/x86/mm/p2m.c | 2 +- 3 files changed, 10 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c index 46a1aac..7f6f578 100644 --- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2923,9 +2923,10 @@ void svm_vmexit_handler(struct cpu_user_regs *regs) v->arch.hvm.svm.cached_insn_len = vmcb->guest_ins_len & 0xf; rc = vmcb->exitinfo1 & PFEC_page_present ? p2m_pt_handle_deferred_changes(vmcb->exitinfo2) : 0; - if ( rc >= 0 ) + if ( rc == 0 ) + /* If no recal adjustments were being made - handle this fault */ svm_do_nested_pgfault(v, regs, vmcb->exitinfo1, vmcb->exitinfo2); - else + else if ( rc < 0 ) { printk(XENLOG_G_ERR "%pv: Error %d handling NPF (gpa=%08lx ec=%04lx)\n", diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c index 5c05017..070389e 100644 --- a/xen/arch/x86/mm/p2m-pt.c +++ b/xen/arch/x86/mm/p2m-pt.c @@ -341,6 +341,7 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) unsigned int level = 4; l1_pgentry_t *pent; int err = 0; + bool recalc_done = false; table = map_domain_page(pagetable_get_mfn(p2m_get_pagetable(p2m))); while ( --level ) @@ -402,6 +403,8 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) clear_recalc(l1, e); err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); ASSERT(!err); + + recalc_done = true; } } unmap_domain_page((void *)((unsigned long)pent & PAGE_MASK)); @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, unsigned long gfn) clear_recalc(l1, e); err = p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); ASSERT(!err); + + recalc_done = true; } out: unmap_domain_page(table); - return err; + return err ?: recalc_done; } int p2m_pt_handle_deferred_changes(uint64_t gpa) diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c index 17f320b..db7bde0 100644 --- a/xen/arch/x86/mm/p2m.c +++ b/xen/arch/x86/mm/p2m.c @@ -1197,7 +1197,7 @@ static int finish_type_change(struct p2m_domain *p2m, rc = p2m->recalc(p2m, gfn); /* * ept->recalc could return 0/1/-ENOMEM. pt->recalc could return - * 0/-ENOMEM/-ENOENT, -ENOENT isn't an error as we are looping + * 0/1/-ENOMEM/-ENOENT, -ENOENT isn't an error as we are looping * gfn here. If rc is 1 we need to have it 0 for success. */ if ( rc == -ENOENT || rc > 0 ) -- 2.7.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 22:50:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 22:50:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgcD0-0000JY-Co; Wed, 03 Jun 2020 22:50:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgcCz-0000JT-N6 for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 22:50:05 +0000 X-Inumbo-ID: 8eb91772-a5ec-11ea-adc5-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8eb91772-a5ec-11ea-adc5-12813bfff9fa; Wed, 03 Jun 2020 22:50:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xMNQ1mGdzFIgdv2uPlq2yp/4T480G5Ev9rwZQbPG/7I=; b=moGakZ7QBIB3laFib/XZ++tb7 l2r3hOPq/G0znx/sYlv17wMcHV4Vmnc7rMjQe2fFv0VsLAOIBEnbC/dUhRPrY6fw0lgfBiYDtwNAP DGAZGehOVMAsOskfCdhO8A+tBJD4qGmHZWoGyTjB8+YgniKcw4CLQi2rq5QYbaDpafq8M=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgcCu-0000fs-Sn; Wed, 03 Jun 2020 22:50:00 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgcCu-0000C1-IF; Wed, 03 Jun 2020 22:50:00 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgcCu-000132-Hc; Wed, 03 Jun 2020 22:50:00 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 150661: tolerable FAIL - PUSHED X-Osstest-Failures: linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=55852b3fd146ce90d4d4306b467261f2c4869293 X-Osstest-Versions-That: linux=e0d81ce760044efd3f26004aa32821c34968512a From: osstest service owner Date: Wed, 03 Jun 2020 22:50:00 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150661 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/150661/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150423 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 55852b3fd146ce90d4d4306b467261f2c4869293 baseline version: linux e0d81ce760044efd3f26004aa32821c34968512a Last test of basis 150508 2020-05-29 22:40:26 Z 5 days Testing same since 150642 2020-06-03 06:40:26 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: "Eric W. Biederman" Al Viro Alaa Hleihel Alan Stern Alex Deucher Alex Sierra Alexander Dahl Alexander Potapenko Alexei Starovoitov Amy Shih Andreas Gruenbacher Andrew Morton Andrew Oakley Andy Lutomirski Andy Shevchenko Antony Antony Arnaldo Carvalho de Melo Arnd Bergmann ASSOGBA Emery Bartosz Golaszewski Björn Töpel Bob Peterson Boris Sukholitko Borislav Petkov Brendan Shanks Changbin Du Changming Liu Chris Chiu Christian König Christophe JAILLET Chuhong Yuan Daniel Borkmann Dave Wysochanski David Ahern David Howells David S. Miller DENG Qingfang Denis V. Lunev Dennis Dalessandro Dennis YC Hsieh Dmitry Torokhov Doug Ledford Edward Cree Eran Ben Elisha Eric Dumazet Eric W. Biederman Evan Green Evan Quan Felipe Balbi Felix Kuehling Florian Fainelli Greg Kroah-Hartman Grygorii Strashko Guenter Roeck Guo Ren Hamish Martin Hans Verkuil Heiko Stuebner Helge Deller Hsin-Yi Wang Hugh Dickins Ian Ray Ido Schimmel Ilya Dryomov Jakub Kicinski Jamal Hadi Salim James Hilliard Jason Gunthorpe Jay Vosburgh Jeff Layton Jens Axboe Jere Leppänen Jerry Lee Jiri Olsa Jiri Pirko Joerg Roedel Johan Jonker Johannes Berg Johannes Weiner Jonathan Lemon Kaike Wan Kailang Yang Kees Cook Kefeng Wang Kevin Locke Kirill A. Shutemov Konstantin Khlebnikov Lei Xue Leon Romanovsky Linus Lüssing Linus Torvalds Linus Walleij Liu Yibin Madhuparna Bhowmik Manivannan Sadhasivam Mao Han Maor Gottlieb Marc Payne Marcelo Ricardo Leitner Martin KaFai Lau Masahiro Yamada Matteo Croce Matthias Brugger Michael Braun Michael Chan Moshe Shemesh Nathan Chancellor Neil Horman Nicolas Dichtel Nikolay Aleksandrov Pablo Neira Ayuso Palmer Dabbelt Paul Cercueil Peng Hao Phil Sutter Pradeep Kumar Chitrapu Qiushi Wu Robert Beckett Roi Dayan Roman Mashak Russell King Sabrina Dubroca Saeed Mahameed Sam Ravnborg Sasha Levin Sebastian Reichel Shaokun Zhang Shawn Guo Shay Drory Shiraz Saleem Simon Ser Song Liu Stefan Wahren Steffen Klassert Stephen Boyd Stephen Warren Stephen Worley Steve French Takashi Iwai Tariq Toukan Tero Kristo Tiezhu Yang Tony Lindgren Ulf Hansson Vadim Fedorenko Valentine Fatiev Vinay Kumar Yadav Vincent Stehlé Vinod Koul Vladimir Oltean Vlastimil Babka Wei Yongjun Xin Long Yonghong Song Yuqi Jin Łukasz Patron Łukasz Stelmach jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git e0d81ce76004..55852b3fd146 55852b3fd146ce90d4d4306b467261f2c4869293 -> tested/linux-5.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 03 23:22:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 23:22:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgche-0003Z2-Sk; Wed, 03 Jun 2020 23:21:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgchd-0003Yt-Sn for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 23:21:45 +0000 X-Inumbo-ID: fd4aa896-a5f0-11ea-8993-bc764e2007e4 Received: from mail-qk1-x744.google.com (unknown [2607:f8b0:4864:20::744]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fd4aa896-a5f0-11ea-8993-bc764e2007e4; Wed, 03 Jun 2020 23:21:44 +0000 (UTC) Received: by mail-qk1-x744.google.com with SMTP id n141so4181110qke.2 for ; Wed, 03 Jun 2020 16:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=viHdAaovZfZLny6/K1OkFJ6S08Git+InCrEIHu5pizw=; b=C5r8Uthbh9S5TrzKsjBJusBQi81im4pyZEzlrIimJDKAFNrILSBL7UJkov33BQY0dj IOC8js358LOtHACLpVTD9EkcFBK7ivejDrIz0X79/QTr2mBVKSL80JUID3PLxnNPjUt7 AM5b/DfaLiyg6iIrbfFkdXY28h1Mv+e2krYRsF9YPGc576INMjlRZy8cAYD9UfUnifWm dBEhv4kPNY9MlNf1vRKW2RtQCaqsTgcf0ZcmEbqZugdmzaoEpZnzX3dCZZ+Gz4e6GZPr mNWqQjtw9jCTcBpIAuN/XChbXQcCqhUGEAe6mzp+gxMQc/IcmACZMJ4HcmXMDWL8YkLT uGog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=viHdAaovZfZLny6/K1OkFJ6S08Git+InCrEIHu5pizw=; b=o5kNYGcEclOa9mAXKhSYOLSoJZb220jcms0yP4rcuiad3zxjAOg8R8qTQuvBaff8zl vTQ4B3eWs+kMGPUQi41pFKnldywg/VD3kMjFhnf8VdbovcOubypEAOg7bPY9rVjI0kM3 ga0a60Omm1dp3MLmrWt1Vnq81mZJb3s7DZOSVI9C4HIUpVs87u/gMiwV3qmDP49iZFqf vK/i2Gn1/YZ9VQx9v5jOVofBu3vLaTnUjHhZmrGQbG20jVn07h3zy/etifh45kWRupwS LW29XK3dn2E2474Vj3S+5iHWJOmXnb+NNtJtUhU/NzDf6Fwd4aMvK0pkJDUzKc4AME3L H8Qw== X-Gm-Message-State: AOAM533bgtOdbEqCZIIDMCWrOd7dwAjewlr+YRerU+qQX2UUPO5pN464 WMQ8vSo9eJNWMNBxoRx4TVXMbibND6zkBlwILD0q4w== X-Google-Smtp-Source: ABdhPJw9W66DBBxUF1Xcku92BsMzHxkg4qumsdT7oP9BMRG8p7Y/sNTmF7udpGJpmUUk0p0bUfjnXKILGsSCDiUBSlU= X-Received: by 2002:a05:620a:90a:: with SMTP id v10mr2169214qkv.22.1591226504632; Wed, 03 Jun 2020 16:21:44 -0700 (PDT) MIME-Version: 1.0 References: <20200603223156.12767-1-sstabellini@kernel.org> In-Reply-To: <20200603223156.12767-1-sstabellini@kernel.org> From: Roman Shaposhnik Date: Wed, 3 Jun 2020 16:21:33 -0700 Message-ID: Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , tamas@tklengyel.com, Julien Grall , Stefano Stabellini , cminyard@mvista.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 3, 2020 at 3:31 PM Stefano Stabellini wrote: > > Touching the watchdog is required to be able to reboot the board. > > The implementation is based on > drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > Signed-off-by: Stefano Stabellini Tested-by: Roman Shaposhnik Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Wed Jun 03 23:34:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 03 Jun 2020 23:34:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgctg-0004i4-2h; Wed, 03 Jun 2020 23:34:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgcte-0004hv-6f for xen-devel@lists.xenproject.org; Wed, 03 Jun 2020 23:34:10 +0000 X-Inumbo-ID: b93295a4-a5f2-11ea-adcc-12813bfff9fa Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b93295a4-a5f2-11ea-adcc-12813bfff9fa; Wed, 03 Jun 2020 23:34:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591227250; x=1622763250; h=from:to:date:message-id:content-id: content-transfer-encoding:mime-version:subject; bh=qtEIBasy+ByN1wQKHZce6qFboTnE33aTP8MgD2Faj7A=; b=NIZW7Npv8feNJThOxWuk236ixLJeO0r37WGvqesz0HgGalI1LfENcsn+ AXnitld7FBp9p6YuBsr9dmtDpGw66YioTBK+XAxMf8CRJOz49jsKY+Dew q4NhCiM6oDRi4Ln/kkio1/X0Jhkt0xmZS6T7X1V+NFPD4sMyJB5GCV8WD 8=; IronPort-SDR: hYC7Rd5aXF9gcmmrZFET2z0O1qHevCxYSnU5rShDMp5CIOGvCIQB39MuSF97f/H/Zyqw/9NADH n4VgTf0d8zCg== X-IronPort-AV: E=Sophos;i="5.73,470,1583193600"; d="scan'208";a="34377725" Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Thread-Topic: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-2a-53356bf6.us-west-2.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 03 Jun 2020 23:33:56 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2a-53356bf6.us-west-2.amazon.com (Postfix) with ESMTPS id BE86FA20E2; Wed, 3 Jun 2020 23:33:53 +0000 (UTC) Received: from EX13D05UWB003.ant.amazon.com (10.43.161.26) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 23:33:53 +0000 Received: from EX13D07UWB001.ant.amazon.com (10.43.161.238) by EX13D05UWB003.ant.amazon.com (10.43.161.26) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 3 Jun 2020 23:33:52 +0000 Received: from EX13D07UWB001.ant.amazon.com ([10.43.161.238]) by EX13D07UWB001.ant.amazon.com ([10.43.161.238]) with mapi id 15.00.1497.006; Wed, 3 Jun 2020 23:33:53 +0000 From: "Agarwal, Anchal" To: Boris Ostrovsky , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "hpa@zytor.com" , "x86@kernel.org" , "jgross@suse.com" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "Kamata, Munehisa" , "sstabellini@kernel.org" , "konrad.wilk@oracle.com" , "roger.pau@citrix.com" , "axboe@kernel.dk" , "davem@davemloft.net" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "peterz@infradead.org" , "Valentin, Eduardo" , "Singh, Balbir" , "xen-devel@lists.xenproject.org" , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Woodhouse, David" , "benh@kernel.crashing.org" Thread-Index: AQHWOf9xCt3yRncxCEGi+Dc47/9Nhw== Date: Wed, 3 Jun 2020 23:33:52 +0000 Message-ID: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.162.208] Content-Type: text/plain; charset="utf-8" Content-ID: <2F5E420224B9AC4D82F71EDB24A9BF71@amazon.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" IENBVVRJT046IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2Fu aXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlv dSBjYW4gY29uZmlybSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQoN Cg0KDQogICAgT24gVHVlLCBNYXkgMTksIDIwMjAgYXQgMTE6Mjc6NTBQTSArMDAwMCwgQW5jaGFs IEFnYXJ3YWwgd3JvdGU6DQogICAgPiBGcm9tOiBNdW5laGlzYSBLYW1hdGEgPGthbWF0YW1AYW1h em9uLmNvbT4NCiAgICA+IA0KICAgID4gUzQgcG93ZXIgdHJhbnNpdGlvbiBzdGF0ZXMgYXJlIG11 Y2ggZGlmZmVyZW50IHRoYW4geGVuDQogICAgPiBzdXNwZW5kL3Jlc3VtZS4gRm9ybWVyIGlzIHZp c2libGUgdG8gdGhlIGd1ZXN0IGFuZCBmcm9udGVuZCBkcml2ZXJzIHNob3VsZA0KICAgID4gYmUg YXdhcmUgb2YgdGhlIHN0YXRlIHRyYW5zaXRpb25zIGFuZCBzaG91bGQgYmUgYWJsZSB0byB0YWtl IGFwcHJvcHJpYXRlDQogICAgPiBhY3Rpb25zIHdoZW4gbmVlZGVkLiBJbiB0cmFuc2l0aW9uIHRv IFM0IHdlIG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgYXQgbGVhc3QNCiAgICA+IGFsbCB0aGUgaW4t ZmxpZ2h0IGJsa2lmIHJlcXVlc3RzIGdldCBjb21wbGV0ZWQsIHNpbmNlIHRoZXkgcHJvYmFibHkg Y29udGFpbg0KICAgID4gYml0cyBvZiB0aGUgZ3Vlc3QncyBtZW1vcnkgaW1hZ2UgYW5kIHRoYXQn cyBub3QgZ29pbmcgdG8gZ2V0IHNhdmVkIGFueQ0KICAgID4gb3RoZXIgd2F5LiBIZW5jZSwgcmUt aXNzdWluZyBvZiBpbi1mbGlnaHQgcmVxdWVzdHMgYXMgaW4gY2FzZSBvZiB4ZW4gcmVzdW1lDQog ICAgPiB3aWxsIG5vdCB3b3JrIGhlcmUuIFRoaXMgaXMgaW4gY29udHJhc3QgdG8geGVuLXN1c3Bl bmQgd2hlcmUgd2UgbmVlZCB0bw0KICAgID4gZnJlZXplIHdpdGggYXMgbGl0dGxlIHByb2Nlc3Np bmcgYXMgcG9zc2libGUgdG8gYXZvaWQgZGlydHlpbmcgUkFNIGxhdGUgaW4NCiAgICA+IHRoZSBt aWdyYXRpb24gY3ljbGUgYW5kIHdlIGtub3cgdGhhdCBpbi1mbGlnaHQgZGF0YSBjYW4gd2FpdC4N CiAgICA+IA0KICAgID4gQWRkIGZyZWV6ZSwgdGhhdyBhbmQgcmVzdG9yZSBjYWxsYmFja3MgZm9y IFBNIHN1c3BlbmQgYW5kIGhpYmVybmF0aW9uDQogICAgPiBzdXBwb3J0LiBBbGwgZnJvbnRlbmQg ZHJpdmVycyB0aGF0IG5lZWRzIHRvIHVzZSBQTV9ISUJFUk5BVElPTi9QTV9TVVNQRU5EDQogICAg PiBldmVudHMsIG5lZWQgdG8gaW1wbGVtZW50IHRoZXNlIHhlbmJ1c19kcml2ZXIgY2FsbGJhY2tz LiBUaGUgZnJlZXplIGhhbmRsZXINCiAgICA+IHN0b3BzIGJsb2NrLWxheWVyIHF1ZXVlIGFuZCBk aXNjb25uZWN0IHRoZSBmcm9udGVuZCBmcm9tIHRoZSBiYWNrZW5kIHdoaWxlDQogICAgPiBmcmVl aW5nIHJpbmdfaW5mbyBhbmQgYXNzb2NpYXRlZCByZXNvdXJjZXMuIEJlZm9yZSBkaXNjb25uZWN0 aW5nIGZyb20gdGhlDQogICAgPiBiYWNrZW5kLCB3ZSBuZWVkIHRvIHByZXZlbnQgYW55IG5ldyBJ TyBmcm9tIGJlaW5nIHF1ZXVlZCBhbmQgd2FpdCBmb3IgZXhpc3RpbmcNCiAgICA+IElPIHRvIGNv bXBsZXRlLiBGcmVlemUvdW5mcmVlemUgb2YgdGhlIHF1ZXVlcyB3aWxsIGd1YXJhbnRlZSB0aGF0 IHRoZXJlIGFyZSBubw0KICAgID4gcmVxdWVzdHMgaW4gdXNlIG9uIHRoZSBzaGFyZWQgcmluZy4g SG93ZXZlciwgZm9yIHNhbml0eSB3ZSBzaG91bGQgY2hlY2sNCiAgICA+IHN0YXRlIG9mIHRoZSBy aW5nIGJlZm9yZSBkaXNjb25uZWN0aW5nIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZXJlIGFyZSBubw0K ICAgID4gb3V0c3RhbmRpbmcgcmVxdWVzdHMgdG8gYmUgcHJvY2Vzc2VkIG9uIHRoZSByaW5nLiBU aGUgcmVzdG9yZSBoYW5kbGVyDQogICAgPiByZS1hbGxvY2F0ZXMgcmluZ19pbmZvLCB1bnF1aWVz Y2VzIGFuZCB1bmZyZWV6ZXMgdGhlIHF1ZXVlIGFuZCByZS1jb25uZWN0IHRvDQogICAgPiB0aGUg YmFja2VuZCwgc28gdGhhdCByZXN0IG9mIHRoZSBrZXJuZWwgY2FuIGNvbnRpbnVlIHRvIHVzZSB0 aGUgYmxvY2sgZGV2aWNlDQogICAgPiB0cmFuc3BhcmVudGx5Lg0KICAgID4gDQogICAgPiBOb3Rl OkZvciBvbGRlciBiYWNrZW5kcyxpZiBhIGJhY2tlbmQgZG9lc24ndCBoYXZlIGNvbW1pdCcxMmVh NzI5NjQ1YWNlJw0KICAgID4geGVuL2Jsa2JhY2s6IHVubWFwIGFsbCBwZXJzaXN0ZW50IGdyYW50 cyB3aGVuIGZyb250ZW5kIGdldHMgZGlzY29ubmVjdGVkLA0KICAgID4gdGhlIGZyb250ZW5kIG1h eSBzZWUgbWFzc2l2ZSBhbW91bnQgb2YgZ3JhbnQgdGFibGUgd2FybmluZyB3aGVuIGZyZWVpbmcN CiAgICA+IHJlc291cmNlcy4NCiAgICA+IFsgICAzNi44NTI2NTldIGRlZmVycmluZyBnLmUuIDB4 ZjkgKHBmbiAweGZmZmZmZmZmZmZmZmZmZmYpDQogICAgPiBbICAgMzYuODU1MDg5XSB4ZW46Z3Jh bnRfdGFibGU6IFdBUk5JTkc6ZS5nLiAweDExMiBzdGlsbCBpbiB1c2UhDQogICAgPiANCiAgICA+ IEluIHRoaXMgY2FzZSwgcGVyc2lzdGVudCBncmFudHMgd291bGQgbmVlZCB0byBiZSBkaXNhYmxl ZC4NCiAgICA+IA0KICAgID4gW0FuY2hhbCBDaGFuZ2Vsb2c6IFJlbW92ZWQgdGltZW91dC9yZXF1 ZXN0IGR1cmluZyBibGtmcm9udCBmcmVlemUuDQogICAgPiBSZXdvcmtlZCB0aGUgd2hvbGUgcGF0 Y2ggdG8gd29yayB3aXRoIGJsay1tcSBhbmQgaW5jb3Jwb3JhdGUgdXBzdHJlYW0ncw0KICAgID4g Y29tbWVudHNdDQoNCiAgICBQbGVhc2UgdGFnIHZlcnNpb25zIHVzaW5nIHZYIGFuZCBpdCB3b3Vs ZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBsaXN0DQogICAgdGhlIHNwZWNpZmljIGNoYW5nZXMg dGhhdCB5b3UgcGVyZm9ybWVkIGJldHdlZW4gdmVyc2lvbnMuIFRoZXJlIHdoZXJlDQogICAgMyBS RkMgdmVyc2lvbnMgSUlSQywgYW5kIHRoZXJlJ3Mgbm8gbG9nIG9mIHRoZSBjaGFuZ2VzIGJldHdl ZW4gdGhlbS4NCg0KSSB3aWxsIGVsYWJvcmF0ZSBvbiAidXBzdHJlYW0ncyBjb21tZW50cyIgaW4g bXkgY2hhbmdlbG9nIGluIG15IG5leHQgcm91bmQgb2YgcGF0Y2hlcy4NCiAgICA+IA0KICAgID4g U2lnbmVkLW9mZi1ieTogQW5jaGFsIEFnYXJ3YWwgPGFuY2hhbGFnQGFtYXpvbi5jb20+DQogICAg PiBTaWduZWQtb2ZmLWJ5OiBNdW5laGlzYSBLYW1hdGEgPGthbWF0YW1AYW1hem9uLmNvbT4NCiAg ICA+IC0tLQ0KICAgID4gIGRyaXZlcnMvYmxvY2sveGVuLWJsa2Zyb250LmMgfCAxMjIgKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrLS0NCiAgICA+ICAxIGZpbGUgY2hhbmdlZCwgMTE1 IGluc2VydGlvbnMoKyksIDcgZGVsZXRpb25zKC0pDQogICAgPiANCiAgICA+IGRpZmYgLS1naXQg YS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jIGIvZHJpdmVycy9ibG9jay94ZW4tYmxrZnJv bnQuYw0KICAgID4gaW5kZXggM2I4ODllYTk1MGMyLi40NjQ4NjNlZDcwOTMgMTAwNjQ0DQogICAg PiAtLS0gYS9kcml2ZXJzL2Jsb2NrL3hlbi1ibGtmcm9udC5jDQogICAgPiArKysgYi9kcml2ZXJz L2Jsb2NrL3hlbi1ibGtmcm9udC5jDQogICAgPiBAQCAtNDgsNiArNDgsOCBAQA0KICAgID4gICNp bmNsdWRlIDxsaW51eC9saXN0Lmg+DQogICAgPiAgI2luY2x1ZGUgPGxpbnV4L3dvcmtxdWV1ZS5o Pg0KICAgID4gICNpbmNsdWRlIDxsaW51eC9zY2hlZC9tbS5oPg0KICAgID4gKyNpbmNsdWRlIDxs aW51eC9jb21wbGV0aW9uLmg+DQogICAgPiArI2luY2x1ZGUgPGxpbnV4L2RlbGF5Lmg+DQogICAg PiANCiAgICA+ICAjaW5jbHVkZSA8eGVuL3hlbi5oPg0KICAgID4gICNpbmNsdWRlIDx4ZW4veGVu YnVzLmg+DQogICAgPiBAQCAtODAsNiArODIsOCBAQCBlbnVtIGJsa2lmX3N0YXRlIHsNCiAgICA+ ICAgICAgIEJMS0lGX1NUQVRFX0RJU0NPTk5FQ1RFRCwNCiAgICA+ICAgICAgIEJMS0lGX1NUQVRF X0NPTk5FQ1RFRCwNCiAgICA+ICAgICAgIEJMS0lGX1NUQVRFX1NVU1BFTkRFRCwNCiAgICA+ICsg ICAgIEJMS0lGX1NUQVRFX0ZSRUVaSU5HLA0KICAgID4gKyAgICAgQkxLSUZfU1RBVEVfRlJPWkVO DQoNCiAgICBOaXQ6IGFkZGluZyBhIHRlcm1pbmF0aW5nICcsJyB3b3VsZCBwcmV2ZW50IGZ1cnRo ZXIgYWRkaXRpb25zIGZyb20NCiAgICBoYXZpbmcgdG8gbW9kaWZ5IHRoaXMgbGluZS4NCkFDSy4N CiAgICA+ICB9Ow0KICAgID4gDQogICAgPiAgc3RydWN0IGdyYW50IHsNCiAgICA+IEBAIC0yMTks NiArMjIzLDcgQEAgc3RydWN0IGJsa2Zyb250X2luZm8NCiAgICA+ICAgICAgIHN0cnVjdCBsaXN0 X2hlYWQgcmVxdWVzdHM7DQogICAgPiAgICAgICBzdHJ1Y3QgYmlvX2xpc3QgYmlvX2xpc3Q7DQog ICAgPiAgICAgICBzdHJ1Y3QgbGlzdF9oZWFkIGluZm9fbGlzdDsNCiAgICA+ICsgICAgIHN0cnVj dCBjb21wbGV0aW9uIHdhaXRfYmFja2VuZF9kaXNjb25uZWN0ZWQ7DQogICAgPiAgfTsNCiAgICA+ IA0KICAgID4gIHN0YXRpYyB1bnNpZ25lZCBpbnQgbnJfbWlub3JzOw0KICAgID4gQEAgLTEwMDUs NiArMTAxMCw3IEBAIHN0YXRpYyBpbnQgeGx2YmRfaW5pdF9ibGtfcXVldWUoc3RydWN0IGdlbmRp c2sgKmdkLCB1MTYgc2VjdG9yX3NpemUsDQogICAgPiAgICAgICBpbmZvLT5zZWN0b3Jfc2l6ZSA9 IHNlY3Rvcl9zaXplOw0KICAgID4gICAgICAgaW5mby0+cGh5c2ljYWxfc2VjdG9yX3NpemUgPSBw aHlzaWNhbF9zZWN0b3Jfc2l6ZTsNCiAgICA+ICAgICAgIGJsa2lmX3NldF9xdWV1ZV9saW1pdHMo aW5mbyk7DQogICAgPiArICAgICBpbml0X2NvbXBsZXRpb24oJmluZm8tPndhaXRfYmFja2VuZF9k aXNjb25uZWN0ZWQpOw0KICAgID4gDQogICAgPiAgICAgICByZXR1cm4gMDsNCiAgICA+ICB9DQog ICAgPiBAQCAtMTA1Nyw3ICsxMDYzLDcgQEAgc3RhdGljIGludCB4ZW5fdHJhbnNsYXRlX3ZkZXYo aW50IHZkZXZpY2UsIGludCAqbWlub3IsIHVuc2lnbmVkIGludCAqb2Zmc2V0KQ0KICAgID4gICAg ICAgICAgICAgICBjYXNlIFhFTl9TQ1NJX0RJU0s1X01BSk9SOg0KICAgID4gICAgICAgICAgICAg ICBjYXNlIFhFTl9TQ1NJX0RJU0s2X01BSk9SOg0KICAgID4gICAgICAgICAgICAgICBjYXNlIFhF Tl9TQ1NJX0RJU0s3X01BSk9SOg0KICAgID4gLSAgICAgICAgICAgICAgICAgICAgICpvZmZzZXQg PSAoKm1pbm9yIC8gUEFSVFNfUEVSX0RJU0spICsNCiAgICA+ICsgICAgICAgICAgICAgICAgICAg ICAqb2Zmc2V0ID0gKCptaW5vciAvIFBBUlRTX1BFUl9ESVNLKSArDQogICAgPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAoKG1ham9yIC0gWEVOX1NDU0lfRElTSzFfTUFKT1IgKyAxKSAq IDE2KSArDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFTVVMQVRFRF9TRF9E SVNLX05BTUVfT0ZGU0VUOw0KICAgID4gICAgICAgICAgICAgICAgICAgICAgICptaW5vciA9ICpt aW5vciArDQogICAgPiBAQCAtMTA3Miw3ICsxMDc4LDcgQEAgc3RhdGljIGludCB4ZW5fdHJhbnNs YXRlX3ZkZXYoaW50IHZkZXZpY2UsIGludCAqbWlub3IsIHVuc2lnbmVkIGludCAqb2Zmc2V0KQ0K ICAgID4gICAgICAgICAgICAgICBjYXNlIFhFTl9TQ1NJX0RJU0sxM19NQUpPUjoNCiAgICA+ICAg ICAgICAgICAgICAgY2FzZSBYRU5fU0NTSV9ESVNLMTRfTUFKT1I6DQogICAgPiAgICAgICAgICAg ICAgIGNhc2UgWEVOX1NDU0lfRElTSzE1X01BSk9SOg0KICAgID4gLSAgICAgICAgICAgICAgICAg ICAgICpvZmZzZXQgPSAoKm1pbm9yIC8gUEFSVFNfUEVSX0RJU0spICsNCiAgICA+ICsgICAgICAg ICAgICAgICAgICAgICAqb2Zmc2V0ID0gKCptaW5vciAvIFBBUlRTX1BFUl9ESVNLKSArDQoNCiAg ICBVbnJlbGF0ZWQgY2hhbmdlcywgcGxlYXNlIHNwbGl0IHRvIGEgcHJlLXBhdGNoLg0KDQpJIG11 c3QgYWRtaXQsIHRoaXMgbWF5IGhhdmUgb2NjdXJyZWQgZHVlIHRvIHNvbWUgaXNzdWVzIHdpdGgg bXkgbG9jYWwgdmltIHNldHRpbmdzLiBJIHdpbGwgZml4IHRoaXMuDQogICAgPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAoKG1ham9yIC0gWEVOX1NDU0lfRElTSzhfTUFKT1IgKyA4KSAq IDE2KSArDQogICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFTVVMQVRFRF9TRF9E SVNLX05BTUVfT0ZGU0VUOw0KICAgID4gICAgICAgICAgICAgICAgICAgICAgICptaW5vciA9ICpt aW5vciArDQogICAgPiBAQCAtMTM1Myw2ICsxMzU5LDggQEAgc3RhdGljIHZvaWQgYmxraWZfZnJl ZShzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1c3BlbmQpDQogICAgPiAgICAgICB1 bnNpZ25lZCBpbnQgaTsNCiAgICA+ICAgICAgIHN0cnVjdCBibGtmcm9udF9yaW5nX2luZm8gKnJp bmZvOw0KICAgID4gDQogICAgPiArICAgICBpZiAoaW5mby0+Y29ubmVjdGVkID09IEJMS0lGX1NU QVRFX0ZSRUVaSU5HKQ0KICAgID4gKyAgICAgICAgICAgICBnb3RvIGZyZWVfcmluZ3M7DQogICAg PiAgICAgICAvKiBQcmV2ZW50IG5ldyByZXF1ZXN0cyBiZWluZyBpc3N1ZWQgdW50aWwgd2UgZml4 IHRoaW5ncyB1cC4gKi8NCiAgICA+ICAgICAgIGluZm8tPmNvbm5lY3RlZCA9IHN1c3BlbmQgPw0K ICAgID4gICAgICAgICAgICAgICBCTEtJRl9TVEFURV9TVVNQRU5ERUQgOiBCTEtJRl9TVEFURV9E SVNDT05ORUNURUQ7DQogICAgPiBAQCAtMTM2MCw2ICsxMzY4LDcgQEAgc3RhdGljIHZvaWQgYmxr aWZfZnJlZShzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbywgaW50IHN1c3BlbmQpDQogICAgPiAg ICAgICBpZiAoaW5mby0+cnEpDQogICAgPiAgICAgICAgICAgICAgIGJsa19tcV9zdG9wX2h3X3F1 ZXVlcyhpbmZvLT5ycSk7DQogICAgPiANCiAgICA+ICtmcmVlX3JpbmdzOg0KICAgID4gICAgICAg Zm9yX2VhY2hfcmluZm8oaW5mbywgcmluZm8sIGkpDQogICAgPiAgICAgICAgICAgICAgIGJsa2lm X2ZyZWVfcmluZyhyaW5mbyk7DQogICAgPiANCiAgICA+IEBAIC0xNTYzLDggKzE1NzIsMTAgQEAg c3RhdGljIGlycXJldHVybl90IGJsa2lmX2ludGVycnVwdChpbnQgaXJxLCB2b2lkICpkZXZfaWQp DQogICAgPiAgICAgICBzdHJ1Y3QgYmxrZnJvbnRfcmluZ19pbmZvICpyaW5mbyA9IChzdHJ1Y3Qg YmxrZnJvbnRfcmluZ19pbmZvICopZGV2X2lkOw0KICAgID4gICAgICAgc3RydWN0IGJsa2Zyb250 X2luZm8gKmluZm8gPSByaW5mby0+ZGV2X2luZm87DQogICAgPiANCiAgICA+IC0gICAgIGlmICh1 bmxpa2VseShpbmZvLT5jb25uZWN0ZWQgIT0gQkxLSUZfU1RBVEVfQ09OTkVDVEVEKSkNCiAgICA+ IC0gICAgICAgICAgICAgcmV0dXJuIElSUV9IQU5ETEVEOw0KICAgID4gKyAgICAgaWYgKHVubGlr ZWx5KGluZm8tPmNvbm5lY3RlZCAhPSBCTEtJRl9TVEFURV9DT05ORUNURUQNCiAgICA+ICsgICAg ICAgICAgICAgICAgICYmIGluZm8tPmNvbm5lY3RlZCAhPSBCTEtJRl9TVEFURV9GUkVFWklORykp ew0KDQogICAgRXh0cmEgdGFiIGFuZCBtaXNzaW5nIHNwYWNlIGJldHdlZW4gJyl7Jy4gQWxzbyBt eSBwcmVmZXJlbmNlIHdvdWxkIGJlDQogICAgZm9yIHRoZSAmJiB0byBnbyBhdCB0aGUgZW5kIG9m IHRoZSBwcmV2aW91cyBsaW5lLCBsaWtlIGl0J3MgZG9uZQ0KICAgIGVsc2V3aGVyZSBpbiB0aGUg ZmlsZS4NCk9rLg0KICAgID4gKyAgICAgICAgIHJldHVybiBJUlFfSEFORExFRDsNCiAgICA+ICsg ICAgIH0NCiAgICA+IA0KICAgID4gICAgICAgc3Bpbl9sb2NrX2lycXNhdmUoJnJpbmZvLT5yaW5n X2xvY2ssIGZsYWdzKTsNCiAgICA+ICAgYWdhaW46DQogICAgPiBAQCAtMjAyNyw2ICsyMDM4LDcg QEAgc3RhdGljIGludCBibGtpZl9yZWNvdmVyKHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvKQ0K ICAgID4gICAgICAgdW5zaWduZWQgaW50IHNlZ3M7DQogICAgPiAgICAgICBzdHJ1Y3QgYmxrZnJv bnRfcmluZ19pbmZvICpyaW5mbzsNCiAgICA+IA0KICAgID4gKyAgICAgYm9vbCBmcm96ZW4gPSBp bmZvLT5jb25uZWN0ZWQgPT0gQkxLSUZfU1RBVEVfRlJPWkVOOw0KDQogICAgUGxlYXNlIHB1dCB0 aGlzIHRvZ2V0aGVyIHdpdGggdGhlIHJlc3Qgb2YgdGhlIHZhcmlhYmxlIGRlZmluaXRpb25zLA0K ICAgIGFuZCBsZWF2ZSB0aGUgZW1wdHkgbGluZSBhcyBhIHNwbGl0IGJldHdlZW4gdmFyaWFibGUg ZGVmaW5pdGlvbnMgYW5kDQogICAgY29kZS4gSSd2ZSBhbHJlYWR5IHJlcXVlc3RlZCB0aGlzIG9u IFJGQyB2MyBidXQgeW91IHNlZW0gdG8gaGF2ZQ0KICAgIGRyb3BwZWQgc29tZSBvZiB0aGUgcmVx dWVzdHMgSSd2ZSBtYWRlIHRoZXJlLg0KDQpJIGFtIHNvcnJ5IGlmIEkgbWlzc2VkIHRoaXMuIEkg dGhpbmsgSSBmaXhlZCBldmVyeXRoaW5nIHlvdSBjb21tZW50ZWQgYnV0IG1heSBiZSB0aGlzIGdv dCBsZWZ0IG91dC4gV2lsbCBmaXguDQpJIHdpbGwgY3Jvc3MtY2hlY2sgUkZDVjMgdG8gc2VlIGlm IEkgbWlzc2VkIGFueXRoaW5nIGVsc2UuDQoNCiAgICA+ICAgICAgIGJsa2Zyb250X2dhdGhlcl9i YWNrZW5kX2ZlYXR1cmVzKGluZm8pOw0KICAgID4gICAgICAgLyogUmVzZXQgbGltaXRzIGNoYW5n ZWQgYnkgYmxrX21xX3VwZGF0ZV9ucl9od19xdWV1ZXMoKS4gKi8NCiAgICA+ICAgICAgIGJsa2lm X3NldF9xdWV1ZV9saW1pdHMoaW5mbyk7DQogICAgPiBAQCAtMjA0OCw2ICsyMDYwLDkgQEAgc3Rh dGljIGludCBibGtpZl9yZWNvdmVyKHN0cnVjdCBibGtmcm9udF9pbmZvICppbmZvKQ0KICAgID4g ICAgICAgICAgICAgICBraWNrX3BlbmRpbmdfcmVxdWVzdF9xdWV1ZXMocmluZm8pOw0KICAgID4g ICAgICAgfQ0KICAgID4gDQogICAgPiArICAgICBpZiAoZnJvemVuKQ0KICAgID4gKyAgICAgICAg ICAgICByZXR1cm4gMDsNCiAgICA+ICsNCiAgICA+ICAgICAgIGxpc3RfZm9yX2VhY2hfZW50cnlf c2FmZShyZXEsIG4sICZpbmZvLT5yZXF1ZXN0cywgcXVldWVsaXN0KSB7DQogICAgPiAgICAgICAg ICAgICAgIC8qIFJlcXVldWUgcGVuZGluZyByZXF1ZXN0cyAoZmx1c2ggb3IgZGlzY2FyZCkgKi8N CiAgICA+ICAgICAgICAgICAgICAgbGlzdF9kZWxfaW5pdCgmcmVxLT5xdWV1ZWxpc3QpOw0KICAg ID4gQEAgLTIzNjQsNiArMjM3OSw3IEBAIHN0YXRpYyB2b2lkIGJsa2Zyb250X2Nvbm5lY3Qoc3Ry dWN0IGJsa2Zyb250X2luZm8gKmluZm8pDQogICAgPiANCiAgICA+ICAgICAgICAgICAgICAgcmV0 dXJuOw0KICAgID4gICAgICAgY2FzZSBCTEtJRl9TVEFURV9TVVNQRU5ERUQ6DQogICAgPiArICAg ICBjYXNlIEJMS0lGX1NUQVRFX0ZST1pFTjoNCiAgICA+ICAgICAgICAgICAgICAgLyoNCiAgICA+ ICAgICAgICAgICAgICAgICogSWYgd2UgYXJlIHJlY292ZXJpbmcgZnJvbSBzdXNwZW5zaW9uLCB3 ZSBuZWVkIHRvIHdhaXQNCiAgICA+ICAgICAgICAgICAgICAgICogZm9yIHRoZSBiYWNrZW5kIHRv IGFubm91bmNlIGl0J3MgZmVhdHVyZXMgYmVmb3JlDQogICAgPiBAQCAtMjQ4MSwxMiArMjQ5Nywz NiBAQCBzdGF0aWMgdm9pZCBibGtiYWNrX2NoYW5nZWQoc3RydWN0IHhlbmJ1c19kZXZpY2UgKmRl diwNCiAgICA+ICAgICAgICAgICAgICAgYnJlYWs7DQogICAgPiANCiAgICA+ICAgICAgIGNhc2Ug WGVuYnVzU3RhdGVDbG9zZWQ6DQogICAgPiAtICAgICAgICAgICAgIGlmIChkZXYtPnN0YXRlID09 IFhlbmJ1c1N0YXRlQ2xvc2VkKQ0KICAgID4gKyAgICAgICAgICAgICBpZiAoZGV2LT5zdGF0ZSA9 PSBYZW5idXNTdGF0ZUNsb3NlZCkgew0KICAgID4gKyAgICAgICAgICAgICAgICAgICAgIGlmIChp bmZvLT5jb25uZWN0ZWQgPT0gQkxLSUZfU1RBVEVfRlJFRVpJTkcpIHsNCiAgICA+ICsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGJsa2lmX2ZyZWUoaW5mbywgMCk7DQogICAgPiArICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBpbmZvLT5jb25uZWN0ZWQgPSBCTEtJRl9TVEFURV9GUk9a RU47DQogICAgPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb21wbGV0ZSgmaW5mby0+ d2FpdF9iYWNrZW5kX2Rpc2Nvbm5lY3RlZCk7DQogICAgPiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBicmVhazsNCg0KICAgIFRoZXJlJ3Mgbm8gbmVlZCBmb3IgdGhlIGJyZWFrIGhlcmUs IHlvdSBjYW4gcmVseSBvbiB0aGUgYnJlYWsgYmVsb3cuDQpBY2suDQogICAgPiArICAgICAgICAg ICAgICAgICAgICAgfQ0KICAgID4gKw0KICAgID4gICAgICAgICAgICAgICAgICAgICAgIGJyZWFr Ow0KICAgID4gKyAgICAgICAgICAgICB9DQogICAgPiArDQogICAgPiArICAgICAgICAgICAgIC8q DQogICAgPiArICAgICAgICAgICAgICAqIFdlIG1heSBzb21laG93IHJlY2VpdmUgYmFja2VuZCdz IENsb3NlZCBhZ2FpbiB3aGlsZSB0aGF3aW5nDQogICAgPiArICAgICAgICAgICAgICAqIG9yIHJl c3RvcmluZyBhbmQgaXQgY2F1c2VzIHRoYXdpbmcgb3IgcmVzdG9yaW5nIHRvIGZhaWwuDQogICAg PiArICAgICAgICAgICAgICAqIElnbm9yZSBzdWNoIHVuZXhwZWN0ZWQgc3RhdGUgcmVnYXJkbGVz cyBvZiB0aGUgYmFja2VuZCBzdGF0ZS4NCiAgICA+ICsgICAgICAgICAgICAgICovDQogICAgPiAr ICAgICAgICAgICAgIGlmIChpbmZvLT5jb25uZWN0ZWQgPT0gQkxLSUZfU1RBVEVfRlJPWkVOKSB7 DQoNCiAgICBJIHRoaW5rIHlvdSBjYW4gam9pbiB0aGlzIHdpdGggdGhlIHByZXZpb3VzIGRldi0+ c3RhdGUgPT0gWGVuYnVzU3RhdGVDbG9zZWQ/DQoNCiAgICBBbHNvLCB3b24ndCB0aGUgZGV2aWNl IGJlIGluIHRoZSBDbG9zZWQgc3RhdGUgYWxyZWFkeSBpZiBpdCdzIGluIHN0YXRlDQogICAgZnJv emVuPw0KWWVzIGJ1dCBJIHRoaW5rIHRoaXMgbW9zdGx5IGR1ZSB0byBhIGh5cG90aGV0aWNhbCBj YXNlIGlmIGR1cmluZyB0aGF3aW5nIGJhY2tlbmQgc3dpdGNoZXMgdG8gQ2xvc2VkIHN0YXRlLg0K SSBhbSBub3QgZW50aXJlbHkgc3VyZSBpZiB0aGF0IGNvdWxkIGhhcHBlbi4gQ291bGQgdXNlIHNv bWUgZXhwZXJ0aXNlIGhlcmUuDQoNCiAgICA+ICsgICAgICAgICAgICAgICAgICAgICBkZXZfZGJn KCZkZXYtPmRldiwNCiAgICA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Imlnbm9yZSB0aGUgYmFja2VuZCdzIENsb3NlZCBzdGF0ZTogJXMiLA0KICAgID4gKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZXYtPm5vZGVuYW1lKTsNCiAgICA+ICsgICAg ICAgICAgICAgICAgICAgICBicmVhazsNCiAgICA+ICsgICAgICAgICAgICAgfQ0KICAgID4gICAg ICAgICAgICAgICAvKiBmYWxsIHRocm91Z2ggKi8NCiAgICA+ICAgICAgIGNhc2UgWGVuYnVzU3Rh dGVDbG9zaW5nOg0KICAgID4gLSAgICAgICAgICAgICBpZiAoaW5mbykNCiAgICA+IC0gICAgICAg ICAgICAgICAgICAgICBibGtmcm9udF9jbG9zaW5nKGluZm8pOw0KICAgID4gKyAgICAgICAgICAg ICBpZiAoaW5mbykgew0KICAgID4gKyAgICAgICAgICAgICAgICAgICAgIGlmIChpbmZvLT5jb25u ZWN0ZWQgPT0gQkxLSUZfU1RBVEVfRlJFRVpJTkcpDQogICAgPiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB4ZW5idXNfZnJvbnRlbmRfY2xvc2VkKGRldik7DQogICAgPiArICAgICAgICAg ICAgICAgICAgICAgZWxzZQ0KICAgID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYmxr ZnJvbnRfY2xvc2luZyhpbmZvKTsNCiAgICA+ICsgICAgICAgICAgICAgfQ0KICAgID4gICAgICAg ICAgICAgICBicmVhazsNCiAgICA+ICAgICAgIH0NCiAgICA+ICB9DQogICAgPiBAQCAtMjYzMCw2 ICsyNjcwLDcxIEBAIHN0YXRpYyB2b2lkIGJsa2lmX3JlbGVhc2Uoc3RydWN0IGdlbmRpc2sgKmRp c2ssIGZtb2RlX3QgbW9kZSkNCiAgICA+ICAgICAgIG11dGV4X3VubG9jaygmYmxrZnJvbnRfbXV0 ZXgpOw0KICAgID4gIH0NCiAgICA+IA0KICAgID4gK3N0YXRpYyBpbnQgYmxrZnJvbnRfZnJlZXpl KHN0cnVjdCB4ZW5idXNfZGV2aWNlICpkZXYpDQogICAgPiArew0KICAgID4gKyAgICAgdW5zaWdu ZWQgaW50IGk7DQogICAgPiArICAgICBzdHJ1Y3QgYmxrZnJvbnRfaW5mbyAqaW5mbyA9IGRldl9n ZXRfZHJ2ZGF0YSgmZGV2LT5kZXYpOw0KICAgID4gKyAgICAgc3RydWN0IGJsa2Zyb250X3Jpbmdf aW5mbyAqcmluZm87DQogICAgPiArICAgICAvKiBUaGlzIHdvdWxkIGJlIHJlYXNvbmFibGUgdGlt ZW91dCBhcyB1c2VkIGluIHhlbmJ1c19kZXZfc2h1dGRvd24oKSAqLw0KICAgID4gKyAgICAgdW5z aWduZWQgaW50IHRpbWVvdXQgPSA1ICogSFo7DQogICAgPiArICAgICB1bnNpZ25lZCBsb25nIGZs YWdzOw0KICAgID4gKyAgICAgaW50IGVyciA9IDA7DQogICAgPiArDQogICAgPiArICAgICBpbmZv LT5jb25uZWN0ZWQgPSBCTEtJRl9TVEFURV9GUkVFWklORzsNCiAgICA+ICsNCiAgICA+ICsgICAg IGJsa19tcV9mcmVlemVfcXVldWUoaW5mby0+cnEpOw0KICAgID4gKyAgICAgYmxrX21xX3F1aWVz Y2VfcXVldWUoaW5mby0+cnEpOw0KICAgID4gKw0KICAgID4gKyAgICAgZm9yX2VhY2hfcmluZm8o aW5mbywgcmluZm8sIGkpIHsNCiAgICA+ICsgICAgICAgICAvKiBObyBtb3JlIGdudHRhYiBjYWxs YmFjayB3b3JrLiAqLw0KICAgID4gKyAgICAgICAgIGdudHRhYl9jYW5jZWxfZnJlZV9jYWxsYmFj aygmcmluZm8tPmNhbGxiYWNrKTsNCiAgICA+ICsgICAgICAgICAvKiBGbHVzaCBnbnR0YWIgY2Fs bGJhY2sgd29yay4gTXVzdCBiZSBkb25lIHdpdGggbm8gbG9ja3MgaGVsZC4gKi8NCiAgICA+ICsg ICAgICAgICBmbHVzaF93b3JrKCZyaW5mby0+d29yayk7DQogICAgPiArICAgICB9DQogICAgPiAr DQogICAgPiArICAgICBmb3JfZWFjaF9yaW5mbyhpbmZvLCByaW5mbywgaSkgew0KICAgID4gKyAg ICAgICAgIHNwaW5fbG9ja19pcnFzYXZlKCZyaW5mby0+cmluZ19sb2NrLCBmbGFncyk7DQogICAg PiArICAgICAgICAgaWYgKFJJTkdfRlVMTCgmcmluZm8tPnJpbmcpDQogICAgPiArICAgICAgICAg ICAgICAgICB8fCBSSU5HX0hBU19VTkNPTlNVTUVEX1JFU1BPTlNFUygmcmluZm8tPnJpbmcpKSB7 DQoNCiAgICAnfHwnIHNob3VsZCBnbyBhdCB0aGUgZW5kIG9mIHRoZSBwcmV2aW91cyBsaW5lLg0K QWNrLg0KICAgID4gKyAgICAgICAgICAgICB4ZW5idXNfZGV2X2Vycm9yKGRldiwgZXJyLCAiSGli ZXJuYXRpb24gRmFpbGVkLg0KICAgID4gKyAgICAgICAgICAgICAgICAgICAgIFRoZSByaW5nIGlz IHN0aWxsIGJ1c3kiKTsNCiAgICA+ICsgICAgICAgICAgICAgaW5mby0+Y29ubmVjdGVkID0gQkxL SUZfU1RBVEVfQ09OTkVDVEVEOw0KICAgID4gKyAgICAgICAgICAgICBzcGluX3VubG9ja19pcnFy ZXN0b3JlKCZyaW5mby0+cmluZ19sb2NrLCBmbGFncyk7DQoNCiAgICBZb3UgbmVlZCB0byB1bmZy ZWV6ZSB0aGUgcXVldWVzIGhlcmUsIG9yIGVsc2UgdGhlIGRldmljZSB3aWxsIGJlIGluIGENCiAg ICBibG9ja2VkIHN0YXRlIEFGQUlDVC4NClllcywgSSB3YXMgdW5kZXIgd3JvbmcgYXNzdW1wdGlv biB0aGF0IGlmIGZyZWV6ZSBmYWlscyBldmVyeXRoaW5nIHNob3VsZCB0aGF3IGJhY2sgY29ycmVj dGx5IGFwcGFyZW50bHkgbm90Lg0KSSB3aWxsIGZpeCB0aGlzLg0KICAgID4gKyAgICAgICAgICAg ICByZXR1cm4gLUVCVVNZOw0KICAgID4gKyAgICAgfQ0KICAgID4gKyAgICAgICAgIHNwaW5fdW5s b2NrX2lycXJlc3RvcmUoJnJpbmZvLT5yaW5nX2xvY2ssIGZsYWdzKTsNCiAgICA+ICsgICAgIH0N Cg0KICAgIFRoaXMgYmxvY2sgaGFzIGluZGVudGF0aW9uIGFsbCBtZXNzZWQgdXAuDQpUb28gbWFu eSBvZiB0aGVzZSAoIA0KICAgID4gKyAgICAgLyogS2ljayB0aGUgYmFja2VuZCB0byBkaXNjb25u ZWN0ICovDQogICAgPiArICAgICB4ZW5idXNfc3dpdGNoX3N0YXRlKGRldiwgWGVuYnVzU3RhdGVD bG9zaW5nKTsNCiAgICA+ICsNCiAgICA+ICsgICAgIC8qDQogICAgPiArICAgICAgKiBXZSBkb24n dCB3YW50IHRvIG1vdmUgZm9yd2FyZCBiZWZvcmUgdGhlIGZyb250ZW5kIGlzIGRpY29ubmVjdGVk DQogICAgPiArICAgICAgKiBmcm9tIHRoZSBiYWNrZW5kIGNsZWFubHkuDQogICAgPiArICAgICAg Ki8NCiAgICA+ICsgICAgIHRpbWVvdXQgPSB3YWl0X2Zvcl9jb21wbGV0aW9uX3RpbWVvdXQoJmlu Zm8tPndhaXRfYmFja2VuZF9kaXNjb25uZWN0ZWQsDQogICAgPiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHRpbWVvdXQpOw0KICAgID4gKyAgICAgaWYgKCF0aW1l b3V0KSB7DQogICAgPiArICAgICAgICAgICAgIGVyciA9IC1FQlVTWTsNCg0KICAgIE5vdGUgZXJy IGlzIG9ubHkgdXNlZCBoZXJlLCBhbmQgSSB0aGluayBjb3VsZCBqdXN0IGJlIGRyb3BwZWQuDQoN ClRoaXMgZXJyIGlzIHdoYXQncyBiZWluZyByZXR1cm5lZCBmcm9tIHRoZSBmdW5jdGlvbi4gQW0g SSBtaXNzaW5nIGFueXRoaW5nPw0KDQogICAgPiArICAgICAgICAgICAgIHhlbmJ1c19kZXZfZXJy b3IoZGV2LCBlcnIsICJGcmVlemluZyB0aW1lZCBvdXQ7Ig0KICAgID4gKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICJ0aGUgZGV2aWNlIG1heSBiZWNvbWUgaW5jb25zaXN0ZW50IHN0YXRl Iik7DQoNCiAgICBMZWF2aW5nIHRoZSBkZXZpY2UgaW4gdGhpcyBzdGF0ZSBpcyBxdWl0ZSBiYWQs IGFzIGl0J3MgaW4gYSBjbG9zZWQNCiAgICBzdGF0ZSBhbmQgd2l0aCB0aGUgcXVldWVzIGZyb3pl bi4gWW91IHNob3VsZCBtYWtlIGFuIGF0dGVtcHQgdG8NCiAgICByZXN0b3JlIHRoaW5ncyB0byBh IHdvcmtpbmcgc3RhdGUuDQoNCllvdSBtZWFuIGlmIGJhY2tlbmQgY2xvc2VkIGFmdGVyIHRpbWVv dXQ/IElzIHRoZXJlIGEgd2F5IHRvIGtub3cgdGhhdD8gSSB1bmRlcnN0YW5kIGl0J3Mgbm90IGdv b2QgdG8gDQpsZWF2ZSBpdCBpbiB0aGlzIHN0YXRlIGhvd2V2ZXIsIEkgYW0gc3RpbGwgdHJ5aW5n IHRvIGZpbmQgaWYgdGhlcmUgaXMgYSBnb29kIHdheSB0byBrbm93IGlmIGJhY2tlbmQgaXMgc3Rp bGwgY29ubmVjdGVkIGFmdGVyIHRpbWVvdXQuDQpIZW5jZSB0aGUgbWVzc2FnZSAiIHRoZSBkZXZp Y2UgbWF5IGJlY29tZSBpbmNvbnNpc3RlbnQgc3RhdGUiLiAgSSBkaWRuJ3Qgc2VlIGEgdGltZW91 dCBub3QgZXZlbiBvbmNlIG9uIG15IGVuZCBzbyB0aGF0J3Mgd2h5IA0KSSBtYXkgYmUgbG9va2lu ZyBmb3IgYW4gYWx0ZXJuYXRlIHBlcnNwZWN0aXZlIGhlcmUuIG1heSBiZSBuZWVkIHRvIHRoYXcg ZXZlcnl0aGluZyBiYWNrIGludGVudGlvbmFsbHkgaXMgb25lIHRoaW5nIEkgY291bGQgdGhpbmsg b2YuDQoNCiAgICA+ICsgICAgIH0NCiAgICA+ICsNCiAgICA+ICsgICAgIHJldHVybiBlcnI7DQog ICAgPiArfQ0KICAgID4gKw0KICAgID4gK3N0YXRpYyBpbnQgYmxrZnJvbnRfcmVzdG9yZShzdHJ1 Y3QgeGVuYnVzX2RldmljZSAqZGV2KQ0KICAgID4gK3sNCiAgICA+ICsgICAgIHN0cnVjdCBibGtm cm9udF9pbmZvICppbmZvID0gZGV2X2dldF9kcnZkYXRhKCZkZXYtPmRldik7DQogICAgPiArICAg ICBpbnQgZXJyID0gMDsNCiAgICA+ICsNCiAgICA+ICsgICAgIGVyciA9IHRhbGtfdG9fYmxrYmFj ayhkZXYsIGluZm8pOw0KICAgID4gKyAgICAgYmxrX21xX3VucXVpZXNjZV9xdWV1ZShpbmZvLT5y cSk7DQogICAgPiArICAgICBibGtfbXFfdW5mcmVlemVfcXVldWUoaW5mby0+cnEpOw0KICAgID4g KyAgICAgaWYgKCFlcnIpDQogICAgPiArICAgICAgICAgYmxrX21xX3VwZGF0ZV9ucl9od19xdWV1 ZXMoJmluZm8tPnRhZ19zZXQsIGluZm8tPm5yX3JpbmdzKTsNCg0KICAgIEJhZCBpbmRlbnRhdGlv bi4gQWxzbyBzaG91bGRuJ3QgeW91IGZpcnN0IHVwZGF0ZSB0aGUgcXVldWVzIGFuZCB0aGVuDQog ICAgdW5mcmVlemUgdGhlbT8NClBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcsIGJsa19t cV91cGRhdGVfbnJfaHdfcXVldWVzIGZyZWV6ZXMgdGhlIHF1ZXVlDQpTbyBJIGRvbid0IHRoaW5r IHRoZSBvcmRlciBjb3VsZCBiZSByZXZlcnNlZC4NCg0KICAgIFRoYW5rcywgUm9nZXIuDQoNClRo YW5rcywNCkFuY2hhbA0KDQoNCg== From xen-devel-bounces@lists.xenproject.org Thu Jun 04 00:10:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 00:10:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgdSd-0000HZ-L0; Thu, 04 Jun 2020 00:10:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgdSb-0000HU-BM for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 00:10:17 +0000 X-Inumbo-ID: c49fe0b8-a5f7-11ea-81bc-bc764e2007e4 Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c49fe0b8-a5f7-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 00:10:16 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id q13so3230220edi.3 for ; Wed, 03 Jun 2020 17:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SBCn6+ywtwKDSrFyNeGcQyKLX9pJa482RffEcN0lApc=; b=v6f7ml3ifkrHNnNmCnQaEh6TEX4qn6KXUvnIiOoWv2i+pttTmhrthhwQ3wiMiGZU/l Lk+lx2oWuqlHFcDLPjiye7azpPW+BKWdS4paPA6NkDur7yLP589TrG+BSJquETjqnHPM fNXGSLRmA9NFq60yxW3NR8m1kakFjxe+GAeT+XM2/7WU26XQO2iKRq8br3p549h0appb TR1Ftp3mrLpxWsaD+rskVhT4wyC5FmUKs7yR//vNPwReUGTDdBZLJ2dAkj/gnA6BmU5p Iz5hAa/6+Kjh+mIU1uRlgwTDDqMsBftRxMOqESQMlOh+bZCqJZeKHWlBg9aeWPnsu7wf B/GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SBCn6+ywtwKDSrFyNeGcQyKLX9pJa482RffEcN0lApc=; b=fHhcWBfqWcrpk+hE6E2desAHr46NA44rzAzUgpVsC/LtL0cdXoGj4HLpFzBUcuxDve xppIKHrOT5h2R+GrGx278gdlyJwPei5vCkQBW4l9lHY2WF8pBR6qBQG1VaPcDvhTQ/xs Q1unLV6/O1GttEjSWVZzmrKTi3d+Sjw1wnTyTBM2F1qIhFfeBwbSlZcVKMKwFlCrYhO/ L72kESpx333Qb3lwRRijCRJxLgGcHOawndnYy4+MMO0HuW45z6I8DWmmLidw8saQ8wJr cKDnyLS/0/kGyrV55cvzo8BWxMgCrNbrZfaQaALh2rXyjCQZ1a1a6OPkgGEKSlYF5d5M Uycw== X-Gm-Message-State: AOAM533TbWVGkXjJ5XcQfdL2k8U+XVFa4ASXCW605mQU2onQoA38x+Iq CWEWprVfXBTSrWPNAB4IkWNbu5scVsQ= X-Google-Smtp-Source: ABdhPJw7rexVsbQBKgrsyOziuJp7x4bxDjgXXKhjFjv5bh5ghRQi48PSQrrcW35d2yo+I8zoIH/FMA== X-Received: by 2002:a50:8b05:: with SMTP id l5mr1822301edl.276.1591229415662; Wed, 03 Jun 2020 17:10:15 -0700 (PDT) Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com. [209.85.221.47]) by smtp.gmail.com with ESMTPSA id p26sm254204eds.57.2020.06.03.17.10.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 17:10:14 -0700 (PDT) Received: by mail-wr1-f47.google.com with SMTP id x13so4190281wrv.4 for ; Wed, 03 Jun 2020 17:10:13 -0700 (PDT) X-Received: by 2002:adf:e648:: with SMTP id b8mr1788954wrn.386.1591229413535; Wed, 03 Jun 2020 17:10:13 -0700 (PDT) MIME-Version: 1.0 References: <20200603223156.12767-1-sstabellini@kernel.org> In-Reply-To: <20200603223156.12767-1-sstabellini@kernel.org> From: Tamas K Lengyel Date: Wed, 3 Jun 2020 18:09:37 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Roman Shaposhnik , Julien Grall , Stefano Stabellini , cminyard@mvista.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 3, 2020 at 4:32 PM Stefano Stabellini wrote: > > Touching the watchdog is required to be able to reboot the board. > > The implementation is based on > drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > Signed-off-by: Stefano Stabellini Ah, fantastic, it's been very annoying not being able to reboot the board via ssh. Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Thu Jun 04 00:16:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 00:16:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgdY7-0000WR-BI; Thu, 04 Jun 2020 00:15:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgdY6-0000WM-MF for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 00:15:58 +0000 X-Inumbo-ID: 8ebf0d10-a5f8-11ea-81bc-bc764e2007e4 Received: from mail-oi1-x244.google.com (unknown [2607:f8b0:4864:20::244]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8ebf0d10-a5f8-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 00:15:55 +0000 (UTC) Received: by mail-oi1-x244.google.com with SMTP id p70so3491538oic.12 for ; Wed, 03 Jun 2020 17:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=xNaE8BU6OnVudV+0jcBlA9EVCk9/AsZCS2vA0geAa4Y=; b=lM8tc5nSF85XXZ9shJIIrnNTmYah9p+3ij5LyA6KzyiD0gWSLGfvrwnj5FTO6evu6Q BJ81o89iBaf7Nn9wlv/Tr+yTgQATCKixCpBBOhRaE6598wn0xV2i5HVbnBBPH1+nXVyn f1rtOKqf3yGjvc8NrJTtNGFvfO65+kznCRn3tOjhkOdTpAITJWt9MiaJb46eHEH8nXtx twU6oh8+U+nzAs0/R5BkrEIiUDR/tf72gngriLoov7CZgYE9IE7W8cuu9tALG2ypa4OG 5U5LL8K+A9xj/Q1EGUNbtleFSZivu5UULISfyVB0CG3+4BDWkFwolGC2pHtAKjKXKk2m Iicw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=xNaE8BU6OnVudV+0jcBlA9EVCk9/AsZCS2vA0geAa4Y=; b=pMMVcZ5sknOy8mtO6WDwJnJBhCkYndEMp9okzqrYa9TuNO6KL7hhJql4N22eJ0OOJu B8kMHvm9FDg+lArv0VQOi1p+fwRoh3LMurDIC+bubut4sJSOzGTusStu7dqQCof/oCnY 9BXeMPnlTtz7KmMPaB3VXZYlWHpCrZ+z/ZPzh5Z9D+mPoDfhzWkeAGcF2T9byVYBzUAr vtJDG/0FPGPmXiu6oGX6T3Hp3HY2JGR8xLw1JJ6oJ/PBybH0by3qcS12y9UyEKyoW+ue KofjfFcN66Sa7JpSMlojJWxBosWyhylDnn43K+xkz7nz40QjYZudhXRtnJWC3iff7IZk vWjg== X-Gm-Message-State: AOAM530m6jFyZ7z/HXAG8+gd1GqUrD/SCrGFwKmfnib50s3C8OevwrpP mds7cmZgmIMz5EPvVNR1B7sqOA== X-Google-Smtp-Source: ABdhPJwAzowLe8zoLzVaeSS1eYVvpg4W92K/C0JBzgt54bnfnjfO1APESwKUIcCaGqEKmrnTsWjwdQ== X-Received: by 2002:aca:4f4a:: with SMTP id d71mr1421012oib.123.1591229754912; Wed, 03 Jun 2020 17:15:54 -0700 (PDT) Received: from minyard.net ([2001:470:b8f6:1b:9d35:f7bd:647:6545]) by smtp.gmail.com with ESMTPSA id g10sm840201otn.34.2020.06.03.17.15.54 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Jun 2020 17:15:54 -0700 (PDT) Date: Wed, 3 Jun 2020 19:15:52 -0500 From: Corey Minyard To: Stefano Stabellini Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset Message-ID: <20200604001552.GC2903@minyard.net> References: <20200603223156.12767-1-sstabellini@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603223156.12767-1-sstabellini@kernel.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: cminyard@mvista.com Cc: xen-devel@lists.xenproject.org, roman@zededa.com, julien@xen.org, Stefano Stabellini , tamas@tklengyel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote: > Touching the watchdog is required to be able to reboot the board. > > The implementation is based on > drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. Ah, I was looking at this just today, as it had been annoying me greatly. This works for me, so: Tested-by: Corey Minyard However, I was wondering if it might be better to handle this by failing the operation in xen and passing it back to dom0 to do. On the Pi you send a firmware message to reboot, and that seems like too much to do in Xen, but it would seem possible to send this back to dom0. Just a thought, as it might be a more general fix for other devices in the same situation. Thanks, -corey > > Signed-off-by: Stefano Stabellini > --- > xen/arch/arm/platforms/brcm-raspberry-pi.c | 60 ++++++++++++++++++++++ > 1 file changed, 60 insertions(+) > > diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c b/xen/arch/arm/platforms/brcm-raspberry-pi.c > index f5ae58a7d5..0214ae2b3c 100644 > --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c > +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c > @@ -18,6 +18,10 @@ > */ > > #include > +#include > +#include > +#include > +#include > > static const char *const rpi4_dt_compat[] __initconst = > { > @@ -37,12 +41,68 @@ static const struct dt_device_match rpi4_blacklist_dev[] __initconst = > * The aux peripheral also shares a page with the aux UART. > */ > DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"), > + /* Special device used for rebooting */ > + DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"), > { /* sentinel */ }, > }; > > + > +#define PM_PASSWORD 0x5a000000 > +#define PM_RSTC 0x1c > +#define PM_WDOG 0x24 > +#define PM_RSTC_WRCFG_FULL_RESET 0x00000020 > +#define PM_RSTC_WRCFG_CLR 0xffffffcf > + > +static void __iomem *rpi4_map_watchdog(void) > +{ > + void __iomem *base; > + struct dt_device_node *node; > + paddr_t start, len; > + int ret; > + > + node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm"); > + if ( !node ) > + return NULL; > + > + ret = dt_device_get_address(node, 0, &start, &len); > + if ( ret ) > + { > + dprintk(XENLOG_ERR, "Cannot read watchdog register address\n"); > + return NULL; > + } > + > + base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE); > + if ( !base ) > + { > + dprintk(XENLOG_ERR, "Unable to map watchdog register!\n"); > + return NULL; > + } > + > + return base; > +} > + > +static void rpi4_reset(void) > +{ > + u32 val; > + void __iomem *base = rpi4_map_watchdog(); > + if ( !base ) > + return; > + > + /* use a timeout of 10 ticks (~150us) */ > + writel(10 | PM_PASSWORD, base + PM_WDOG); > + val = readl(base + PM_RSTC); > + val &= PM_RSTC_WRCFG_CLR; > + val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET; > + writel(val, base + PM_RSTC); > + > + /* No sleeping, possibly atomic. */ > + mdelay(1); > +} > + > PLATFORM_START(rpi4, "Raspberry Pi 4") > .compatible = rpi4_dt_compat, > .blacklist_dev = rpi4_blacklist_dev, > + .reset = rpi4_reset, > .dma_bitsize = 30, > PLATFORM_END > > -- > 2.17.1 > From xen-devel-bounces@lists.xenproject.org Thu Jun 04 00:47:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 00:47:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jge2Y-0003Cc-KM; Thu, 04 Jun 2020 00:47:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jge2X-0003CX-Ng for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 00:47:25 +0000 X-Inumbo-ID: f4d4dfea-a5fc-11ea-ade3-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f4d4dfea-a5fc-11ea-ade3-12813bfff9fa; Thu, 04 Jun 2020 00:47:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mxch3F3T3jroPzPBnscaEsJ5/G/fsUmzIBEqKuEiyCc=; b=NtPDq4+uGCBVyrcj6h6CquMfj yJNSBAXRrbz7PvPZzTK+aNXBDFXSvZ/fL1Qa4OkdkQjgr5fWtBb9FtDQXNPP7CZ2t//fo6507a7Tw w6/0EJIQ8R5Jkw/XwxCnaVLebcbRukTucD3h0vEDjzd1UOf/0vVqMIM0gdM8y5eaTi93M=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jge2W-0003h8-88; Thu, 04 Jun 2020 00:47:24 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jge2W-0005MZ-02; Thu, 04 Jun 2020 00:47:24 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jge2V-0002Wl-Va; Thu, 04 Jun 2020 00:47:23 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xtf test] 150667: all pass - PUSHED X-Osstest-Versions-This: xtf=cce0ffab7cc43c810580889a197662d77f2d8ebd X-Osstest-Versions-That: xtf=9d934985adb9eb8290e62df187e044105c9dd6b8 From: osstest service owner Date: Thu, 04 Jun 2020 00:47:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150667 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150667/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf cce0ffab7cc43c810580889a197662d77f2d8ebd baseline version: xtf 9d934985adb9eb8290e62df187e044105c9dd6b8 Last test of basis 147207 2020-02-17 18:39:34 Z 107 days Testing same since 150667 2020-06-03 21:09:33 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Igor Druzhinin Pawel Wieczorkiewicz jobs: build-amd64-xtf pass build-amd64 pass build-amd64-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xtf.git 9d93498..cce0ffa cce0ffab7cc43c810580889a197662d77f2d8ebd -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Thu Jun 04 01:46:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 01:46:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgexg-00012w-66; Thu, 04 Jun 2020 01:46:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgexe-00012r-IE for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 01:46:26 +0000 X-Inumbo-ID: 3324945e-a605-11ea-ade5-12813bfff9fa Received: from out1-smtp.messagingengine.com (unknown [66.111.4.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3324945e-a605-11ea-ade5-12813bfff9fa; Thu, 04 Jun 2020 01:46:25 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 155DD5C00B7 for ; Wed, 3 Jun 2020 21:46:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 03 Jun 2020 21:46:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=bx/CQ+vstaFVaJlSsi8G0wcmiGz0b 8b7zkvx/mq9B/M=; b=0lLRWR14PXyb6sC7675eRhGPAyzTluc6zfYOe4egM4z/P GmcqrCtwasfY3lOQt6JCaktpNPakAVN86NQbWTAVmrsLDJjfyE4OtA3k5sLxti6N iUpfUfAvca4vudlgriJ854So5ywp6kNeWElvCne2xFi4AlQpFjqRyUAcwBw8Qs/k MY9iNeXr+5YtSXEhmEDrzclUBT1o6rtf1C9yy95PBw2OpxmJFKX5L6YsIBqQimvc 98GgA1Nd+Hd7p4+ljPfKNzc8V1TcNI3DsVunfY6esyCXKr0n5CGr0jUXwBSDD0bn gGKlWFH6pZPEvrdqTT4G4rQIHOqgCx1Um5H4jZttg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegtddggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd dtjeenucfhrhhomhepofgrrhgvkhcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhi uceomhgrrhhmrghrvghksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqne cuggftrfgrthhtvghrnhepteduteeiudevkeegvefhtdekhfelgffhhedukedvvdeuuddv jeehvddtieehudfgnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepledurd eihedrfeegrdeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtoh hm X-ME-Proxy: Received: from mail-itl (unknown [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 8630C30614FA for ; Wed, 3 Jun 2020 21:46:24 -0400 (EDT) Date: Thu, 4 Jun 2020 03:46:21 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: xen-devel Subject: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Message-ID: <20200604014621.GA203658@mail-itl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --bg08WKrSYDhXBjb5 Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Hi, (continuation of a thread from #xendevel) During system shutdown quite often I hit infinite stream of errors like this: (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff (XEN) domain_crash called from io.c:178 This is all running on Xen 4.13.0 (I think I've got this with 4.13.1 too), nested within KVM. The KVM part means everything is very slow, so various race conditions are much more likely to happen. It started happening not long ago, and I'm pretty sure it's about updating to qemu 4.2.0 (in linux stubdom), previous one was 3.0.0. Thanks to Andrew and Roger, I've managed to collect more info. Context: dom0: pv dom1: hvm dom2: stubdom for dom1 dom3: hvm dom4: stubdom for dom3 dom5: pvh dom6: pvh It starts I think ok: (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. (XEN) d3v0 handle_pio port 0xb004 read 0x0000 (XEN) d3v0 handle_pio port 0xb004 read 0x0000 (XEN) d3v0 handle_pio port 0xb004 write 0x0001 (XEN) d3v0 handle_pio port 0xb004 write 0x2001 (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. (XEN) d1v0 handle_pio port 0xb004 read 0x0000 (XEN) d1v0 handle_pio port 0xb004 read 0x0000 (XEN) d1v0 handle_pio port 0xb004 write 0x0001 (XEN) d1v0 handle_pio port 0xb004 write 0x2001 (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 But then (after a second or so) when the toolstack tries to clean it up, things go sideways: (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 got domain_lock (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 ret -85 (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 got domain_lock (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 ret -85 (... long stream of domain destroy that can't really finish ...) =20 And then, similar also for dom1: (XEN) d0v1 XEN_DOMCTL_destroydomain domain 1 (XEN) d0v1 XEN_DOMCTL_destroydomain domain 1 got domain_lock (XEN) d0v1 XEN_DOMCTL_destroydomain domain 1 ret -85 (... now a stream of this for dom1 and dom6 interleaved ...) At some point, domain 2 (stubdom for domain 1) and domain 5 join too.=20 Then, we get the main issue: (XEN) d3v0 handle_pio port 0xb004 read 0x0000 (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff (XEN) domain_crash called from io.c:178 Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. Full log of the shutdown: https://gist.github.com/marmarek/fbfe1b5d8f4c7b47df5a5e28bd95ea66 And the patch adding those extra messages: https://gist.github.com/marmarek/dc739a820928e641a1ed6b4759cdf6f3 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7YUmwACgkQ24/THMrX 1yzCSQf+OAz2io9qtyBkdpqNjDPcLtz8DfIxhftj9CV/Rp2kqTc/Idl0bxoufa3A pGIyfp9XIlytEg1c34fwJq8/fQQ2sBLol78wlJI4eW2oi5bJktFjZUi425UJOGc5 ttXMRAZimXswr8FAtcaqw+lbKhbkdZufcNagEAqIdzD37SvKl7ZT7nIbJfSbHPcc ubxGZ+pBvpvL8bhCsgGCkEkNCfMI0AFXViJJbsTH0iFp3NI7IsF4DH8b2uk5ohvB UXgpubEfhOteBFEbvHVAjEfnU6Z+HE1p+N185WI+l+kFN6vgpihfoCjn7ix4kToQ /zggge9iTxL6JC5ycKGbFkt6mKdSWw== =OgE6 -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From xen-devel-bounces@lists.xenproject.org Thu Jun 04 01:51:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 01:51:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgf2Q-0001uJ-Qj; Thu, 04 Jun 2020 01:51:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgf2P-0001uE-RW for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 01:51:21 +0000 X-Inumbo-ID: e3861bb0-a605-11ea-8993-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e3861bb0-a605-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 01:51:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XIyEst5VTC/qBtoeVF/hSzjy/gGlmCxSfumFXnNMW3Y=; b=SUH2x+ykkfIGpDIlv00R1pRe/ TjPeAf2F/nhcOFa9EpHRiFqFXYK5FcSVirctsvLWcCC5e5j12OwB7U0wmrAaK97FwcgvV0aVC/Hoj ewrUW4zXQFKJ6w/0tnRaM1Mc8D6XTyWfV4gdLBXm9kXXszzQiBB7mHHziwxaXwz0HY6r4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgf2O-0006K6-CX; Thu, 04 Jun 2020 01:51:20 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgf2N-0007wH-UF; Thu, 04 Jun 2020 01:51:20 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgf2N-0007WC-Ti; Thu, 04 Jun 2020 01:51:19 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150668: all pass - PUSHED X-Osstest-Versions-This: ovmf=68d720fd92bbdbbfae5adee02d6d9fd24ca38f30 X-Osstest-Versions-That: ovmf=7191dd3c5990416cf473ce36b3fb84ecb2f7b950 From: osstest service owner Date: Thu, 04 Jun 2020 01:51:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150668 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150668/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 68d720fd92bbdbbfae5adee02d6d9fd24ca38f30 baseline version: ovmf 7191dd3c5990416cf473ce36b3fb84ecb2f7b950 Last test of basis 150653 2020-06-03 14:09:17 Z 0 days Testing same since 150668 2020-06-03 21:39:18 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 7191dd3c59..68d720fd92 68d720fd92bbdbbfae5adee02d6d9fd24ca38f30 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Thu Jun 04 01:57:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 01:57:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgf8I-00027R-Hb; Thu, 04 Jun 2020 01:57:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgf8G-00027M-6s for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 01:57:24 +0000 X-Inumbo-ID: b9ef87b8-a606-11ea-9dbe-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.87]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b9ef87b8-a606-11ea-9dbe-bc764e2007e4; Thu, 04 Jun 2020 01:57:21 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OSf8+PWJgvAqr2BbxFWYQ6dV1fskRIAlKyr+poUVF3DCXPb0xBQ/95F0sMpkbn5MAECumD7cZGoCOxJsoke9ABqB64YIfrSYpeBiL3V/KpNYjed4nfQua9IzeF54szhaqXIm3Pu6xBISaB/loRToTXb8ve6H9GXXkF3bksqVCL9WHaUk9bJvpj5eRaAONyg2h0tz4+5Z7dkWs7vcY6he/XO1XXwjZQHJLootroWqyvbAN9fHS6f7ebVsYT1pTgy6bv0wK/3HXsArlG6nV97NULVUBYtt4nXCgo5Z6jVoOlqo+0CZvjDliyxT2aeGRWb//rZK/URytXCiydf2AiVcVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vT6nonjitpnfq1bzXR3wNoE8C3LpPoO7EwxMSIFAtr8=; b=dSCntGv1JmWr5Z3NRUaMSJAUF2YECyGIToNcsRhfuChF2lVAZvkogCG1Svzogm0CoJuvgt62pi8V72/sJhOm3d7zFqpNMdaRkBM6SxqKoiZzIpfSqF1DUIZc+Pz9sspdfkVWVYSdofBPjHLoXF8pP7rjwfPOfV1f7LuRxs7gI6XvVY2G6ngkQMq1uqxn9YBNdyn/3wXC4zrdXxiBC/UcYMhFUJCkJYKTqMPHVE9Ta4xPTD0bVsIckWzMWwVtGpSXBWFeYL55Yxcqqz8R/sD4iFdIpDsOWgy3Y517ghmoFkEJfmBkmaWeGRaP/NFxPCbBFtlcEI2++w0l8L5lmjy13g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vT6nonjitpnfq1bzXR3wNoE8C3LpPoO7EwxMSIFAtr8=; b=szhNizpZoX1nNT4MJz0JruHq0laPFpsGeRQh6d8faGV1dCr76Xxi9pymg+WtNtLFOuafYc1+3dWlVkxtqBp5pik0cz/nTsWCL+SaGq2VpW3iHCKjxwsVaiuq/iChfd/tHUQIUL+RigR/IYI12a5kXzgw0LCuJ/xrCUP7FtnagBU= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2695.eurprd04.prod.outlook.com (2603:10a6:4:95::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 01:57:19 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::d17b:d767:19c3:b871]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::d17b:d767:19c3:b871%6]) with mapi id 15.20.3066.018; Thu, 4 Jun 2020 01:57:18 +0000 From: Peng Fan To: Roman Shaposhnik , Xen-devel Subject: RE: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWN5exllox/cqJUUS0HFcLChNz8ajHt2rg Date: Thu, 4 Jun 2020 01:57:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: zededa.com; dkim=none (message not signed) header.d=none;zededa.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 861a47d8-6dea-4283-5eae-08d8082a9d13 x-ms-traffictypediagnostic: DB6PR0402MB2695: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04244E0DC5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EsUxZoBxQ6wQufOy4K6hBVkl0APckSDvLbsL5q0sHYCoU0O1rgQxyCnV116SJtG9INFVHVuNwWEbb2vrz2+OuObGjytODE0CtRpaMvC9BU4o0SZ40uUBYJeKVc0Rz8lRUb+B0gd+mHQ+IVRfQlLnecuHyczWvl9YCYWws8of7iFWXHyuQOfiDhrTKZGgCGy1vTfd7YtRvZuNOP6aGV58+uV2DYU6PNck+I4BMG1l0tDFT5FVAFxdgk/YgP6NBYbwLX57iP6+vVAsli9f7I6iAdZnBH9GbFBokpEKthsZ6/GBUnGSezz+4xH4jHTbXE8YP2jcNqjKoBp+7ISwBvj6pQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(376002)(366004)(39860400002)(8936002)(8676002)(4326008)(2906002)(186003)(71200400001)(55016002)(9686003)(64756008)(66476007)(66946007)(66446008)(76116006)(26005)(478600001)(110136005)(44832011)(66556008)(86362001)(52536014)(7696005)(6506007)(5660300002)(33656002)(316002)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EoCWoGKspogbR8kFidX4y+XakePVNtOQadRuQsZAA7e/AjuFXKhPs0UvPWhOSRoAKaeG+5A3zuvz1zYsc8ETCyO4gwYafwev7xllgsC9DGIetXXTG3C5uvASIlcsXJX5iLnji3cwsDs2WVs3l64p51KVm7Gb7uOkM/tPe2uGBMreQbJWZRSrjwfFsR6z72bQDkupIXpbAkqXdDABnXbv0nkoqAty6PdhAgyhps67XcVu2tLN0g1UGdSH0YvpP2bkxJEben4nOurv1fAqGq0xk4YdflO4Xz8Abyk3yDmWrCLPnyYlTSgGb7SaaItu6aqXMdbQVu2mEcRD0vZTL828V1Tv0PY+VB+x1fncD1HZlcZ67nIPR0Yhmb38GCW3FNwfCUcTvr9gDo5ZDcv9zTvs8W3w9yBjrett+KqFMUsp+vJ0zUJsutaspvKpWvGgI54KWS6BGNoaEC/mHStUMsZj/76VL9UxvFwu2kSRGvWH370gZAdYPDabkic+vQ04sDU4 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 861a47d8-6dea-4283-5eae-08d8082a9d13 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 01:57:18.8956 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OvOHi1RxBSIVj1viJhAXpHRDlymBSJ2z/XH2Vg0HYVvWHfLIzJ1bBSjjRlAU0o3TG8ySXJj3A9DrYJfp5Our2w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2695 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Nataliya Korovkina Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" R3JhbGwgPGp1bGllbkB4ZW4ub3JnPjsNCj4gTmF0YWxpeWEgS29yb3ZraW5hIDxtYWx1cy5icmFu ZHl3aW5lQGdtYWlsLmNvbT4NCj4gU3ViamVjdDogVUVGSSBzdXBwb3J0IGluIEFSTSBEb21Vcw0K DQpXZSBoYXZlIG1hZGUgVS1Cb290IHJ1biBpbnNpZGUgWEVOIERvbVUsIGJ1dCBqdXN0IG9ubHkg UFYgY29uc29sZSBwYXJ0LA0Kbm90IGltcGxlbWVudCBvdGhlciBmcm9udGVuZCBkcml2ZXJzIGN1 cnJlbnRseS4gV291bGQgdGhpcyBoZWxwIGZvciB5b3VyDQpjYXNlIGlmIGVuYWJsZSBFRkkgaW4g VS1Cb290Pw0KDQpSZWdhcmRzLA0KUGVuZy4NCg0KPiANCj4gSGkhDQo+IA0KPiB3aXRoIGEgbG90 IG9mIGhlbHAgZnJvbSBTdGVmYW5vLCB3ZSdyZSBnZXR0aW5nIFJQaTQgc3VwcG9ydCBpbiBQcm9q ZWN0IEVWRQ0KPiBwcmV0dHkgbXVjaCBvbiBwYXIgYmV0d2VlbiBLVk0gYW5kIFhlbi4NCj4gDQo+ IE9uZSBiaWcgYXJlYSB0aGF0IHN0aWxsIHJlbWFpbnMgaXMgc3VwcG9ydGluZyBVRUZJIGJvb3Qg c2VxdWVuY2UgZm9yIERvbVVzLg0KPiBXaXRoIEtWTSwgZ2l2ZW4gdGhlIHFlbXUgdmlydCBkZXZp Y2UgbW9kZWwgdGhpcyBpcyBhcyBzaW1wbGUgYXMgdXNpbmcgZWl0aGVyDQo+IHN0b2NrIFVFRkkg YnVpbGQgZm9yIGFybSBvciBldmVuIFUtQm9vdCBFRkkgZW11bGF0aW9uIGVudmlyb25tZW50IGFu ZA0KPiBwYXNzaW5nIGl0IHZpYSAtYmlvcyBvcHRpb24uDQo+IA0KPiBPYnZpb3VzbHkgd2l0aCBY ZW4gb24gQVJNIHdlIGRvbid0IGhhdmUgdGhlIGRldmljZSBtb2RlbCBzbyBteQ0KPiB1bmRlcnN0 YW5kaW5nIGlzIHRoYXQgdGhlIGVhc2llc3Qgd2F5IHdlIGNhbiBzdXBwb3J0IGl0IHdvdWxkIGJl IHRvIHBvcnQNCj4gVUVGSSdzIE92bWZQa2cvT3ZtZlhlbiB0YXJnZXQgdG8gQVJNIChpdCBzZWVt cyB0byBiZSBjdXJyZW50bHkgZXhjbHVzaXZlbHkNCj4gWDY0KS4NCj4gDQo+IFNvIGhlcmUncyBt eSBmaXJzdCBxdWVzdGlvbjogaWYgdGhlcmUncyBhbnlib2R5IG9uIHRoaXMgbGlzdCB3aG8gaGFk IGEgaGFuZCBpbg0KPiBpbXBsZW1lbnRpbmcgT3ZtZlBrZy9Pdm1mWGVuIGNhbiB5b3UgcGxlYXNl IHNoYXJlIHlvdXIgdGhvdWdodHMgb24gaG93DQo+IG11Y2ggd29yayB0aGF0IHBvcnQgbWF5IGJl IChvciB3aGV0aGVyIGl0IGlzIGV2ZW4gZmVhc2libGUgLS0gSSBtYXkgdG90YWxseSBiZQ0KPiBt aXNzaW5nIHNvbWV0aGluZyByZWFsbHkgb2J2aW91cyBoZXJlKS4NCj4gDQo+IEFuZCBhcyBsb25n IGFzIEkndmUgZ290IHlvdXIgYXR0ZW50aW9uOiB0d28gbW9yZSBxdWVzdGlvbnM6DQo+ICAgIDEu LiBjb21wYXJlZCB0byB0aGUgYWJvdmUsIHdvdWxkIHBvcnRpbmcgcHZncnViIHRvIEFSTSBiZSBh bnkNCj4gICAgZWFzaWVyIG9yIG1vcmUgZGlmZmljdWx0Pw0KPiANCj4gICAgMi4gc2FtZSBxdWVz dGlvbiBmb3IgdGVhY2hpbmcgdS1ib290IGFib3V0IFBWIGNhbGxzLg0KPiANCj4gVGhhbmtzLA0K PiBSb21hbi4NCj4gDQo+IFAuUy4gT2ggYW5kIEkgZ3Vlc3MgYmV0d2VlbjoNCj4gICAgMC4gT3Zt ZlBrZy9Pdm1mWGVuIG9uIEFSTTY0DQo+ICAgIDEuIHB2Z3J1YiBvbiBBUk02NA0KPiAgICAyLiB1 LWJvb3QvRUZJIGVtdWxhdGlvbiB3aXRoIFBWIGNhbGxzIGJhY2tlbmQgSSBkaWRuJ3QgbWlzcyBh bnkgb3RoZXINCj4gb2J2aW91cyB3YXkgb2YgbWFraW5nIFVFRkktYXdhcmUgVk0gaW1hZ2VzIHRv IGJvb3Qgb24gWGVuIEFSTTY0IERvbVUsDQo+IHJpZ2h0Pw0KDQo= From xen-devel-bounces@lists.xenproject.org Thu Jun 04 02:01:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 02:01:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgfCC-0003Kd-6P; Thu, 04 Jun 2020 02:01:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgfCB-0003KY-6I for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 02:01:27 +0000 X-Inumbo-ID: 4c41eef8-a607-11ea-9dbe-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4c41eef8-a607-11ea-9dbe-bc764e2007e4; Thu, 04 Jun 2020 02:01:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kNVwiaLCN66lXTLeVcrhQ79wDAx9h7v9OVlQrEqgslE=; b=KA3s9CA4u3TllqR7iBC+Vydhp 88UstE+CcwgStF8Kd0YF6GvOTCX9u9L3nWK6J089byswpIjNJhZRYRUv1q/GxXFjs2I98jpCXCUCk PdN1OyUQxpPY5ANoAWfKyPT2ylOz+gA3D2IdarOmRZ/7UaOfR9I+zR9Vjqga1XwDeE65s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgfC9-0006zk-Kg; Thu, 04 Jun 2020 02:01:25 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgfC9-0008A1-C8; Thu, 04 Jun 2020 02:01:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgfC9-00079H-BO; Thu, 04 Jun 2020 02:01:25 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150671: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d9f58cd54fe2f05e1f05e2fe254684bd1840de8e X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Thu, 04 Jun 2020 02:01:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150671 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150671/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d9f58cd54fe2f05e1f05e2fe254684bd1840de8e baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 6 days Failing since 150465 2020-05-29 09:02:14 Z 5 days 42 attempts Testing same since 150649 2020-06-03 13:01:44 Z 0 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1522 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 04 05:02:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 05:02:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgi1Y-0002cj-Lv; Thu, 04 Jun 2020 05:02:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgi1X-0002ce-0d for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 05:02:39 +0000 X-Inumbo-ID: 9c0f059c-a620-11ea-ae0d-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9c0f059c-a620-11ea-ae0d-12813bfff9fa; Thu, 04 Jun 2020 05:02:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A54A6AE16 for ; Thu, 4 Jun 2020 05:02:40 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Subject: Xenstore quota and driver domains Message-ID: <35df958d-eff8-9ca7-fd72-05694f07248d@suse.com> Date: Thu, 4 Jun 2020 07:02:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" A recent report on xen-users surfaced a problem we have with driver domains in medium sized or large configuration: the driver domain can easily hit the default Xenstore quota (in the report it was a driver domain for disks which hit the quota when 15 domUs were active at the same time). Setting the quota to a higher limit will work, of course, but this enables "normal" domUs to use this quota, too, thus hogging lots of Xenstore resources. I believe the most sensible way to solve that would be to have a way to set per-domain quota in Xenstore. As the original reporter already raised concerns regarding rebooting the server for applying new global quota, I believe new quota settings should be possible at runtime. The question is how this interface should look like. Right now I could think of two variants: 1. A new XS_SET_QUOTA and XS_GET_QUOTA wire command pair which can set and get the quota (both, default values for new domains and for any existing domain) 2. A new XS_CONTROL command for setting/getting quota (same scope as 1.) Both variants have advantages and disadvantages: 1. Pros: - clear interface, easily usable Cons: - requires more code churn in tools (libxenstore, xl, libxl) for support in domain-config - any extension will again require similar churn 2. Pros: - easy extensible domain-config possible (via a single item, e.g. "xenstore-quota='watches=10 entries=2000'") Cons: - text parsing in Xenstore instead of xl/libxl - XS_CONTROL sub-options for quota will be ABI Any thoughts? Juergen From xen-devel-bounces@lists.xenproject.org Thu Jun 04 06:07:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 06:07:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgj28-0007yv-De; Thu, 04 Jun 2020 06:07:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgj27-0007yq-61 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 06:07:19 +0000 X-Inumbo-ID: a18d2ef0-a629-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a18d2ef0-a629-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 06:07:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hwbbbp5ex9//xlM5sIx6tRsyBd2Jce7DwnRBkYkOqOM=; b=2cemS/jepikixIrdn7bgh3YTx DZnirIEpGysLL1NqbYvx1oeMGobB5JXzLGBpGsRX48Z2hE6P3Nt/ImWXc8t0BB/EWdhP+dAGIvEx1 f+UZYV3c7FCUw/4SwitlXw0ZBNJ/TxYAdtXV+IVTHGle1wKzBjlneY//HME6AvP5A8stU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgj1z-000477-Ir; Thu, 04 Jun 2020 06:07:11 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgj1z-0003fu-8X; Thu, 04 Jun 2020 06:07:11 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgj1z-0005M1-7j; Thu, 04 Jun 2020 06:07:11 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150663: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=f6aee505c71bbb035dde146caf5a6abbf3ccbe47 X-Osstest-Versions-That: linux=d6f9469a03d832dcd17041ed67774ffb5f3e73b3 From: osstest service owner Date: Thu, 04 Jun 2020 06:07:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150663 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150663/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 150641 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150641 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150641 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150641 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150641 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150641 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150641 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150641 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150641 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150641 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: linux f6aee505c71bbb035dde146caf5a6abbf3ccbe47 baseline version: linux d6f9469a03d832dcd17041ed67774ffb5f3e73b3 Last test of basis 150641 2020-06-03 06:35:03 Z 0 days Testing same since 150663 2020-06-03 18:38:46 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: "Wesley W. Terpstra" Alexandre Belloni Andy Shevchenko Anson Huang Anup Patel Atish Patra Bartosz Golaszewski Christophe JAILLET Colin Ian King Dan Carpenter Daniel Lezcano Dejin Zheng Fenghua Yu Geert Uytterhoeven Ingo Molnar Ingo Rohloff Jason Yan Jiaxun Yang Johan Hovold John Garry Jonathan Cameron #for IIO Krzysztof Piecuch Kyung Min Park Linus Torvalds Lokesh Vutla Marc Zyngier Marek Vasut Michael Ellerman Palmer Dabbelt Paul Burton Rob Herring Saravana Kannan Serge Semin Shaokun Zhang Thomas Gleixner Tony Lindgren Valentin Schneider Wesley W. Terpstra jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git d6f9469a03d8..f6aee505c71b f6aee505c71bbb035dde146caf5a6abbf3ccbe47 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Thu Jun 04 06:19:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 06:19:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgjDP-0000YR-LS; Thu, 04 Jun 2020 06:18:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgjDO-0000YJ-GO for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 06:18:58 +0000 X-Inumbo-ID: 424a0af6-a62b-11ea-ae1c-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 424a0af6-a62b-11ea-ae1c-12813bfff9fa; Thu, 04 Jun 2020 06:18:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UNk8hARPznmxf9XPF4jn5i3hEYv6aE0eHosQteFXCKE=; b=JfkSnyDN+gnu/YfL09IaSRcCg VyyswO3nQvfHa+unzxjUF3iyUxmF5oK07XmIzbgb8A2rgnu+SFgcfJ9RT06IbTHcWlvqlY2UI45s0 ZA6+ggR6R8kVMkSS5DsM9CrOHZDAvxDNYua9dab3wqZWRNRdyQHQ3xgU7Q7L9qx4ICf7U=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgjDG-0004Lm-Om; Thu, 04 Jun 2020 06:18:50 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgjDG-0004Dp-Dh; Thu, 04 Jun 2020 06:18:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgjDG-00056B-Cv; Thu, 04 Jun 2020 06:18:50 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150676: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d9f58cd54fe2f05e1f05e2fe254684bd1840de8e X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Thu, 04 Jun 2020 06:18:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150676 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150676/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d9f58cd54fe2f05e1f05e2fe254684bd1840de8e baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 6 days Failing since 150465 2020-05-29 09:02:14 Z 5 days 43 attempts Testing same since 150649 2020-06-03 13:01:44 Z 0 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1522 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 04 06:43:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 06:43:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgjbF-00039y-Oh; Thu, 04 Jun 2020 06:43:37 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgjbE-00039t-36 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 06:43:36 +0000 X-Inumbo-ID: b629319d-a62e-11ea-ae1e-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b629319d-a62e-11ea-ae1e-12813bfff9fa; Thu, 04 Jun 2020 06:43:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id BC70CACA3; Thu, 4 Jun 2020 06:43:37 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/shim: Fix defconfig selection and trim the build further To: Andrew Cooper References: <20200603170908.13239-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <1a158ff8-e11e-432c-236d-ff884602d48a@suse.com> Date: Thu, 4 Jun 2020 08:43:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200603170908.13239-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , Paul Durrant , Dario Faggioli , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03.06.2020 19:09, Andrew Cooper wrote: > Several options (TBOOT, XENOPROF, Scheduler) depend on EXPERT to be able to > deselect/configure. > > Enabling EXPERT now causes the request of the Credit1 scheduler to be honoured > (rather than giving us Credit2), but take this opportunity to switch to Null, > as the previously problematic issues are now believed to be fixed. > > Enabling EXPERT also allows XEN_SHSTK to be selected, and we don't want this > being built for shim. We also don't want TRACEBUFFER or GDBSX either. > > Take this oppotunity to swap the disable of HVM_FEP for a general disable of > HVM (likely to have wider impliciations in the future), and disable ARGO (will > necesserily need plumbing work to function in shim). Odd. I was quite sure this is the case already; in particular my own build test of a shim config has this already. > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich I have a question though (without implying the patch here needs adjusting, but rather with a look towards after 4.14): > --- a/xen/arch/x86/configs/pvshim_defconfig > +++ b/xen/arch/x86/configs/pvshim_defconfig > @@ -5,19 +5,25 @@ CONFIG_PVH_GUEST=y > CONFIG_PV_SHIM=y > CONFIG_PV_SHIM_EXCLUSIVE=y > CONFIG_NR_CPUS=32 > +CONFIG_EXPERT=y > +CONFIG_SCHED_NULL=y > # Disable features not used by the PV shim > +# CONFIG_HVM is not set > +# CONFIG_XEN_SHSTK is not set > # CONFIG_HYPFS is not set > # CONFIG_SHADOW_PAGING is not set > # CONFIG_BIGMEM is not set > -# CONFIG_HVM_FEP is not set > # CONFIG_TBOOT is not set > # CONFIG_KEXEC is not set > # CONFIG_XENOPROF is not set > # CONFIG_XSM is not set > +# CONFIG_ARGO is not set > +# CONFIG_SCHED_CREDIT is not set > # CONFIG_SCHED_CREDIT2 is not set > # CONFIG_SCHED_RTDS is not set > # CONFIG_SCHED_ARINC653 is not set > -# CONFIG_SCHED_NULL is not set > # CONFIG_LIVEPATCH is not set > # CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set > +# CONFIG_TRACEBUFFER is not set > # CONFIG_DEBUG is not set > +# CONFIG_GDBSX is not set I assume both the "enable" and "disable" sections here are ordered like they would be in a resulting full .config. But this being two separate sections, doing so doesn't help e.g. diff-ing. How about we sort both sections alphabetically (short of other good sorting criteria, yet better than entirely unsorted)? Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 04 07:06:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 07:06:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgjx1-00053P-FH; Thu, 04 Jun 2020 07:06:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgjwz-00053K-Ir for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 07:06:05 +0000 X-Inumbo-ID: da2abac2-a631-11ea-ae22-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id da2abac2-a631-11ea-ae22-12813bfff9fa; Thu, 04 Jun 2020 07:06:03 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 9zAhf83GSgEwVQAlNLIU0pGVdGDAshbC0Sjobq4FVFCviv2UJIg1ceYEsq+Yy0UQBCh1NFfEVy iMLTX3yV7vbF6Waw25yG9y+zEinLLz1zR9Lro1huou6GtYPZBtzM7yyyrAbkeV8wwEgZAesGPR 9t4kRazxWGZKk+HF81fNvmBeezr3rFw/eWaf2A0imOXifNpt7cl+sNxzIbSZAhzYx7lP3DUvFq UuLfxFcBZb2rPfRlU+omrackTfSfGDW1cThP56PbO0AyoTGYXRLwTK9XnJksPbOfMd9H9U2L+p U9U= X-SBRS: 2.7 X-MesageID: 19486747 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,471,1583211600"; d="scan'208";a="19486747" Date: Thu, 4 Jun 2020 09:05:48 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: "Agarwal, Anchal" Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Message-ID: <20200604070548.GH1195@Air-de-Roger> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On Tue, May 19, 2020 at 11:27:50PM +0000, Anchal Agarwal wrote: > > From: Munehisa Kamata > > > > S4 power transition states are much different than xen > > suspend/resume. Former is visible to the guest and frontend drivers should > > be aware of the state transitions and should be able to take appropriate > > actions when needed. In transition to S4 we need to make sure that at least > > all the in-flight blkif requests get completed, since they probably contain > > bits of the guest's memory image and that's not going to get saved any > > other way. Hence, re-issuing of in-flight requests as in case of xen resume > > will not work here. This is in contrast to xen-suspend where we need to > > freeze with as little processing as possible to avoid dirtying RAM late in > > the migration cycle and we know that in-flight data can wait. > > > > Add freeze, thaw and restore callbacks for PM suspend and hibernation > > support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND > > events, need to implement these xenbus_driver callbacks. The freeze handler > > stops block-layer queue and disconnect the frontend from the backend while > > freeing ring_info and associated resources. Before disconnecting from the > > backend, we need to prevent any new IO from being queued and wait for existing > > IO to complete. Freeze/unfreeze of the queues will guarantee that there are no > > requests in use on the shared ring. However, for sanity we should check > > state of the ring before disconnecting to make sure that there are no > > outstanding requests to be processed on the ring. The restore handler > > re-allocates ring_info, unquiesces and unfreezes the queue and re-connect to > > the backend, so that rest of the kernel can continue to use the block device > > transparently. > > > > Note:For older backends,if a backend doesn't have commit'12ea729645ace' > > xen/blkback: unmap all persistent grants when frontend gets disconnected, > > the frontend may see massive amount of grant table warning when freeing > > resources. > > [ 36.852659] deferring g.e. 0xf9 (pfn 0xffffffffffffffff) > > [ 36.855089] xen:grant_table: WARNING:e.g. 0x112 still in use! > > > > In this case, persistent grants would need to be disabled. > > > > [Anchal Changelog: Removed timeout/request during blkfront freeze. > > Reworked the whole patch to work with blk-mq and incorporate upstream's > > comments] > > Please tag versions using vX and it would be helpful if you could list > the specific changes that you performed between versions. There where > 3 RFC versions IIRC, and there's no log of the changes between them. > > I will elaborate on "upstream's comments" in my changelog in my next round of patches. Sorry for being picky, but can you please make sure your email client properly quotes previous emails on reply. Note the lack of '>' added to the quoted parts of your reply. > > + } > > + > > break; > > + } > > + > > + /* > > + * We may somehow receive backend's Closed again while thawing > > + * or restoring and it causes thawing or restoring to fail. > > + * Ignore such unexpected state regardless of the backend state. > > + */ > > + if (info->connected == BLKIF_STATE_FROZEN) { > > I think you can join this with the previous dev->state == XenbusStateClosed? > > Also, won't the device be in the Closed state already if it's in state > frozen? > Yes but I think this mostly due to a hypothetical case if during thawing backend switches to Closed state. > I am not entirely sure if that could happen. Could use some expertise here. I think the frontend seeing the backend in the closed state during restore would be a bug that should prevent the frontend from resuming. > > + /* Kick the backend to disconnect */ > > + xenbus_switch_state(dev, XenbusStateClosing); > > + > > + /* > > + * We don't want to move forward before the frontend is diconnected > > + * from the backend cleanly. > > + */ > > + timeout = wait_for_completion_timeout(&info->wait_backend_disconnected, > > + timeout); > > + if (!timeout) { > > + err = -EBUSY; > > Note err is only used here, and I think could just be dropped. > > This err is what's being returned from the function. Am I missing anything? Just 'return -EBUSY;' directly, and remove the top level variable. You can also use -EBUSY directly in the xenbus_dev_error call. Anyway, not that important. > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > + "the device may become inconsistent state"); > > Leaving the device in this state is quite bad, as it's in a closed > state and with the queues frozen. You should make an attempt to > restore things to a working state. > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. You can manually force this state, and then check that it will behave correctly. I would expect that on a failure to disconnect from the backend you should switch the frontend to the 'Init' state in order to try to reconnect to the backend when possible. > > + } > > + > > + return err; > > +} > > + > > +static int blkfront_restore(struct xenbus_device *dev) > > +{ > > + struct blkfront_info *info = dev_get_drvdata(&dev->dev); > > + int err = 0; > > + > > + err = talk_to_blkback(dev, info); > > + blk_mq_unquiesce_queue(info->rq); > > + blk_mq_unfreeze_queue(info->rq); > > + if (!err) > > + blk_mq_update_nr_hw_queues(&info->tag_set, info->nr_rings); > > Bad indentation. Also shouldn't you first update the queues and then > unfreeze them? > Please correct me if I am wrong, blk_mq_update_nr_hw_queues freezes the queue > So I don't think the order could be reversed. Regardless of what blk_mq_update_nr_hw_queues does, I don't think it's correct to unfreeze the queues without having updated them. Also the freezing/unfreezing uses a refcount, so I think it's perfectly fine to call blk_mq_update_nr_hw_queues first and then unfreeze the queues. Also note that talk_to_blkback returning an error should likely prevent any unfreezing, as the queues won't be updated to match the parameters of the backend. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 04 07:09:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 07:09:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgjzl-0005Bk-Uk; Thu, 04 Jun 2020 07:08:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgjzk-0005Be-SE for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 07:08:56 +0000 X-Inumbo-ID: 40ecd56a-a632-11ea-ae22-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 40ecd56a-a632-11ea-ae22-12813bfff9fa; Thu, 04 Jun 2020 07:08:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A0B66AD4A; Thu, 4 Jun 2020 07:08:58 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= References: <20200604014621.GA203658@mail-itl> From: Jan Beulich Message-ID: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> Date: Thu, 4 Jun 2020 09:08:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200604014621.GA203658@mail-itl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: > During system shutdown quite often I hit infinite stream of errors like > this: > > (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > (XEN) domain_crash called from io.c:178 > > This is all running on Xen 4.13.0 (I think I've got this with 4.13.1 > too), nested within KVM. The KVM part means everything is very slow, so > various race conditions are much more likely to happen. > > It started happening not long ago, and I'm pretty sure it's about > updating to qemu 4.2.0 (in linux stubdom), previous one was 3.0.0. > > Thanks to Andrew and Roger, I've managed to collect more info. > > Context: > dom0: pv > dom1: hvm > dom2: stubdom for dom1 > dom3: hvm > dom4: stubdom for dom3 > dom5: pvh > dom6: pvh > > It starts I think ok: > > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > But then (after a second or so) when the toolstack tries to clean it up, > things go sideways: > > (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 > (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 got domain_lock > (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 ret -85 > (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 > (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 got domain_lock > (XEN) d0v0 XEN_DOMCTL_destroydomain domain 6 ret -85 > (... long stream of domain destroy that can't really finish ...) > > And then, similar also for dom1: > > (XEN) d0v1 XEN_DOMCTL_destroydomain domain 1 > (XEN) d0v1 XEN_DOMCTL_destroydomain domain 1 got domain_lock > (XEN) d0v1 XEN_DOMCTL_destroydomain domain 1 ret -85 > (... now a stream of this for dom1 and dom6 interleaved ...) > > At some point, domain 2 (stubdom for domain 1) and domain 5 join too. What makes you think this is an indication of things going sideways? -85 is -ERESTART, which is quite normal to see for a period of time while cleaning up a domain. > Then, we get the main issue: > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > (XEN) domain_crash called from io.c:178 > > Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom > yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. I'd guess an issue with the shutdown deferral logic. Did you / can you check whether XEN_DMOP_remote_shutdown managed to pause all CPUs (I assume it didn't, since once they're paused there shouldn't be any I/O there anymore, and hence no I/O emulation)? Another question though: In 4.13 the log message next to the domain_crash() I assume you're hitting is "Weird HVM ioemulation status", not "Weird PIO status", and the debugging patch you referenced doesn't have any change there. Andrew's recent change to master, otoh, doesn't use the word "weird" anymore. I can therefore only guess that the value logged is still hvmemul_do_pio_buffer()'s return value, i.e. X86EMUL_UNHANDLEABLE. Please confirm. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 04 07:17:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 07:17:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgk7j-00066O-Pi; Thu, 04 Jun 2020 07:17:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgk7i-00066J-9W for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 07:17:10 +0000 X-Inumbo-ID: 66cda650-a633-11ea-81bc-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 66cda650-a633-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 07:17:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 9A2ACAC6C; Thu, 4 Jun 2020 07:17:11 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom From: Jan Beulich To: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> Message-ID: Date: Thu, 4 Jun 2020 09:17:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.2020 09:08, Jan Beulich wrote: > On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: >> Then, we get the main issue: >> >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff >> (XEN) domain_crash called from io.c:178 >> >> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom >> yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. > > I'd guess an issue with the shutdown deferral logic. Did you / can > you check whether XEN_DMOP_remote_shutdown managed to pause all > CPUs (I assume it didn't, since once they're paused there shouldn't > be any I/O there anymore, and hence no I/O emulation)? > > Another question though: In 4.13 the log message next to the > domain_crash() I assume you're hitting is "Weird HVM ioemulation > status", not "Weird PIO status", and the debugging patch you > referenced doesn't have any change there. Andrew's recent > change to master, otoh, doesn't use the word "weird" anymore. I > can therefore only guess that the value logged is still > hvmemul_do_pio_buffer()'s return value, i.e. X86EMUL_UNHANDLEABLE. > Please confirm. If so, the prime candidate source of the X86EMUL_UNHANDLEABLE would seem to be hvmemul_do_io()'s first switch(). Could you instrument that one as well, so see what vio->io_req.state has caused it? Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 04 07:49:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 07:49:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkcl-0000Q2-Aa; Thu, 04 Jun 2020 07:49:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkcj-0000Px-Gf for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 07:49:13 +0000 X-Inumbo-ID: e144065a-a637-11ea-9947-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e144065a-a637-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 07:49:12 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id y13so5014175eju.2 for ; Thu, 04 Jun 2020 00:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=19uOk58PH69NQ0JMuow4/Erep/Zgdt87/SsuR3J05QM=; b=M2CjCNzBIqnh0CAkeaDcJUiE/YVrCMHA5TbRg9ffvE+qOEOQCNnjAqYqfVqB6gRm4P TW5cb3/FLpYqmbR5xCXZZL1PiFD7YUV+3Bdyx/kckx3eBjcd+BHhA74bMgryUNEgGRcu 2A/b+X7J4U+V3iqmkq8W9WqBraUiSk/w9amrlZMmjQJ1indVChSRWonbPsMSw0ircl6l 2CboHoakl2W5pQT2VqTyhFLUM7a3NzbMZcxNZdzdob3h3JTUkf2Jv5xSc3T3qt0wJ6np wa8yucMwWrjX38z0OTFi/Wej9v6buh1SyNfPfRHEjo9tlUULopVFFWtTNMe9zT3sq9iJ 7XCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=19uOk58PH69NQ0JMuow4/Erep/Zgdt87/SsuR3J05QM=; b=mDUoV14eofoqUEBNmvfV1VOnGJWQIJAewz1Tb02c/6evvbvVQiASFA2a4Ams3vjx+e PVaIV0ceOrq09jPPq35a/RoKaicl5on015tQqCJH2EzaG3TaewIHZ4cr2h5mVWHnaZ5p uoYFMhNtyPgdHe/2wxVjb4DU8tuaXM3KwkpacdZLP/0vi8KNvEfLG7JhKaYTCooT769K 0QUb7FTdyz/zN4/YQpu/dwGXPkrfMD22MqIR4fMigqcy19j6adPfdzaTVcQpe/cV3lew W+rhcY1TSLu/1TC2ysKWyX10eXjfGBC83uUv4e8jf1DWzhVXNcagSKKIRqXxkLf6/Vno 2crg== X-Gm-Message-State: AOAM5338CD3Mp4o0L58C6DWJ5NS8ottgTieV/t+PNJGmy5ReqXmuc1Cz rSsVaH0UZp8VaTH5hssbTG4= X-Google-Smtp-Source: ABdhPJyE1rU6SDPxCX9paZnnqCGpntFePH5Vkcj0AY1ZGlwq/JdCJXxNxlFYGCfphrB1Yo+z3MdO4Q== X-Received: by 2002:a17:906:ecfa:: with SMTP id qt26mr2786774ejb.493.1591256951657; Thu, 04 Jun 2020 00:49:11 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id k22sm1570811edr.93.2020.06.04.00.49.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 00:49:11 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Igor Druzhinin'" , References: <1591224108-564-1-git-send-email-igor.druzhinin@citrix.com> In-Reply-To: <1591224108-564-1-git-send-email-igor.druzhinin@citrix.com> Subject: RE: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately Date: Thu, 4 Jun 2020 08:49:09 +0100 Message-ID: <006401d63a44$a27349e0$e759dda0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKnLWBT9mNjQEOL+u7d2oiXq95SHqcmLb0g X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: andrew.cooper3@citrix.com, george.dunlap@citrix.com, wl@xen.org, jbeulich@suse.com, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Igor Druzhinin > Sent: 03 June 2020 23:42 > To: xen-devel@lists.xenproject.org > Cc: jbeulich@suse.com; andrew.cooper3@citrix.com; wl@xen.org; = roger.pau@citrix.com; > george.dunlap@citrix.com; paul@xen.org; Igor Druzhinin = > Subject: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT = faults immediately >=20 > A recalculation NPT fault doesn't always require additional handling > in hvm_hap_nested_page_fault(), moreover in general case if there is = no > explicit handling done there - the fault is wrongly considered fatal. >=20 > This covers a specific case of migration with vGPU assigned which > uses direct MMIO mappings made by XEN_DOMCTL_memory_mapping hypercall: > at a moment log-dirty is enabled globally, recalculation is requested > for the whole guest memory including those mapped MMIO regions I still think it is odd to put this in the commit comment since, as I = said before, Xen ensures that this situation cannot happen at the moment. > which causes a page fault being raised at the first access to them; > but due to MMIO P2M type not having any explicit handling in > hvm_hap_nested_page_fault() a domain is erroneously crashed with = unhandled > SVM violation. >=20 > Instead of trying to be opportunistic - use safer approach and handle > P2M recalculation in a separate NPT fault by attempting to retry after > making the necessary adjustments. This is aligned with Intel behavior > where there are separate VMEXITs for recalculation and EPT violations > (faults) and only faults are handled in hvm_hap_nested_page_fault(). > Do it by also unifying do_recalc return code with Intel implementation > where returning 1 means P2M was actually changed. >=20 > Since there was no case previously where = p2m_pt_handle_deferred_changes() > could return a positive value - it's safe to replace ">=3D 0" with = just "=3D=3D 0" > in VMEXIT_NPF handler. finish_type_change() is also not affected by = the > change as being able to deal with >0 return value of p2m->recalc from > EPT implementation. >=20 > Reviewed-by: Jan Beulich > Reviewed-by: Roger Pau Monn=C3=A9 > Signed-off-by: Igor Druzhinin However, it's a worthy fix so... Release-acked-by: Paul Durrant > --- > Changes in v2: > - replace rc with recalc_done bool > - updated comment in finish_type_change() > - significantly extended commit description > Changes in v3: > - covert bool to int implicitly > - a little bit more info of the usecase in the message > --- > xen/arch/x86/hvm/svm/svm.c | 5 +++-- > xen/arch/x86/mm/p2m-pt.c | 7 ++++++- > xen/arch/x86/mm/p2m.c | 2 +- > 3 files changed, 10 insertions(+), 4 deletions(-) >=20 > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 46a1aac..7f6f578 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -2923,9 +2923,10 @@ void svm_vmexit_handler(struct cpu_user_regs = *regs) > v->arch.hvm.svm.cached_insn_len =3D vmcb->guest_ins_len & = 0xf; > rc =3D vmcb->exitinfo1 & PFEC_page_present > ? p2m_pt_handle_deferred_changes(vmcb->exitinfo2) : 0; > - if ( rc >=3D 0 ) > + if ( rc =3D=3D 0 ) > + /* If no recal adjustments were being made - handle this = fault */ > svm_do_nested_pgfault(v, regs, vmcb->exitinfo1, = vmcb->exitinfo2); > - else > + else if ( rc < 0 ) > { > printk(XENLOG_G_ERR > "%pv: Error %d handling NPF (gpa=3D%08lx = ec=3D%04lx)\n", > diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c > index 5c05017..070389e 100644 > --- a/xen/arch/x86/mm/p2m-pt.c > +++ b/xen/arch/x86/mm/p2m-pt.c > @@ -341,6 +341,7 @@ static int do_recalc(struct p2m_domain *p2m, = unsigned long gfn) > unsigned int level =3D 4; > l1_pgentry_t *pent; > int err =3D 0; > + bool recalc_done =3D false; >=20 > table =3D = map_domain_page(pagetable_get_mfn(p2m_get_pagetable(p2m))); > while ( --level ) > @@ -402,6 +403,8 @@ static int do_recalc(struct p2m_domain *p2m, = unsigned long gfn) > clear_recalc(l1, e); > err =3D p2m->write_p2m_entry(p2m, gfn, pent, e, level = + 1); > ASSERT(!err); > + > + recalc_done =3D true; > } > } > unmap_domain_page((void *)((unsigned long)pent & PAGE_MASK)); > @@ -448,12 +451,14 @@ static int do_recalc(struct p2m_domain *p2m, = unsigned long gfn) > clear_recalc(l1, e); > err =3D p2m->write_p2m_entry(p2m, gfn, pent, e, level + 1); > ASSERT(!err); > + > + recalc_done =3D true; > } >=20 > out: > unmap_domain_page(table); >=20 > - return err; > + return err ?: recalc_done; > } >=20 > int p2m_pt_handle_deferred_changes(uint64_t gpa) > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c > index 17f320b..db7bde0 100644 > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -1197,7 +1197,7 @@ static int finish_type_change(struct p2m_domain = *p2m, > rc =3D p2m->recalc(p2m, gfn); > /* > * ept->recalc could return 0/1/-ENOMEM. pt->recalc could = return > - * 0/-ENOMEM/-ENOENT, -ENOENT isn't an error as we are = looping > + * 0/1/-ENOMEM/-ENOENT, -ENOENT isn't an error as we are = looping > * gfn here. If rc is 1 we need to have it 0 for success. > */ > if ( rc =3D=3D -ENOENT || rc > 0 ) > -- > 2.7.4 From xen-devel-bounces@lists.xenproject.org Thu Jun 04 07:50:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 07:50:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkeB-0001Bf-MG; Thu, 04 Jun 2020 07:50:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkeA-0001BY-7T for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 07:50:42 +0000 X-Inumbo-ID: 164fd9b4-a638-11ea-9947-bc764e2007e4 Received: from mail-ed1-x52d.google.com (unknown [2a00:1450:4864:20::52d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 164fd9b4-a638-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 07:50:41 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id p18so3884927eds.7 for ; Thu, 04 Jun 2020 00:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=KuNf6C8p5U/pV3cH0HVswaojeUwltwpCkRZOPJXfz5U=; b=Y7FVr2ngIEYiTZl0edDmqaq9hjMiz1SmKQ1oDwyTCFTi/JqtYouQr+coxnkN8/bJ6S UttOnOwPTlxH2RLs+d2qsCPfvHLfCSeGD6GYiWE9/gEssC9KMvVJ9Kce+yvmYUU6c98s +ORackNhRTr35ij070nHuJBJ0Dti4Bn9SII7MP8KrmigtSZf/3DfjzW8LGPb5fGkmb3P Xz32erOHc63npK4zPMbOPqIpu/rEv9RDbWY1KkvrcaYnur0Bo9xMtBEYYjry3E06Rjt4 Zn5Mynf+Zwju4RdzJhq700/wXU+tLJKq65NHFK1y0TlocrEtZPodGYsUBIghWtQ9Sh7u Ihhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=KuNf6C8p5U/pV3cH0HVswaojeUwltwpCkRZOPJXfz5U=; b=W0Jq7IFp2/RUmQtbYgW470D5CnsLcAI3fbJVG6zBHU4oQR2fgmoHsFYDf+pZ4ZwKgy MFRQ8CCiqApo0gzsS2xTqUCXzLNh3A4qbrnvXolIzbx5h2d58izqte6fHhUZN1HZM3CM Hkt+4uPY7G4icA2WpccMQlu76ALiQFx2fVADnGYO5BGY/qDtmrjyu76eJgMQ1UhrN2la m7e6jHEfEhcbwPo3j2flUaDdEE6pBIl73fk91uO6PDn1ml4Afbo+TS89/++OwnDvFsIB lph9glUTXVrc0pOVZCgjP6cL2DXDd68oSDhTvUZkpfofFDB92eB93fo+2InI0r+tUSJu ATdA== X-Gm-Message-State: AOAM531T50lw69f6xwwoIRLqiG2RK8/AlE+4fkYXB9/fvu2GIhJFSjti f2YKNT4R853l3h7HJMgzzPA= X-Google-Smtp-Source: ABdhPJzJ0sjZoihPlAmf98Qw/AKjHh5M3IVSEWx63Kk3T1jB0sk90e4VwRp2MBwMtOHhrUn3IipHUg== X-Received: by 2002:a50:fd01:: with SMTP id i1mr3346973eds.32.1591257040795; Thu, 04 Jun 2020 00:50:40 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id n6sm1557427edv.24.2020.06.04.00.50.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 00:50:40 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , "'Andrew Cooper'" References: <20200603170908.13239-1-andrew.cooper3@citrix.com> <1a158ff8-e11e-432c-236d-ff884602d48a@suse.com> In-Reply-To: <1a158ff8-e11e-432c-236d-ff884602d48a@suse.com> Subject: RE: [PATCH for-4.14] x86/shim: Fix defconfig selection and trim the build further Date: Thu, 4 Jun 2020 08:50:38 +0100 Message-ID: <006501d63a44$d771e0c0$8655a240$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQDiB7eoitU4qCF1PTePgHsB/Nx/GAHHmGl6qqI9QAA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Juergen Gross' , 'Xen-devel' , 'Dario Faggioli' , 'Wei Liu' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 04 June 2020 07:43 > To: Andrew Cooper > Cc: Xen-devel ; Wei Liu ; = Roger Pau Monn=C3=A9 > ; Juergen Gross ; Paul Durrant = ; Dario Faggioli > > Subject: Re: [PATCH for-4.14] x86/shim: Fix defconfig selection and = trim the build further >=20 > On 03.06.2020 19:09, Andrew Cooper wrote: > > Several options (TBOOT, XENOPROF, Scheduler) depend on EXPERT to be = able to > > deselect/configure. > > > > Enabling EXPERT now causes the request of the Credit1 scheduler to = be honoured > > (rather than giving us Credit2), but take this opportunity to switch = to Null, > > as the previously problematic issues are now believed to be fixed. > > > > Enabling EXPERT also allows XEN_SHSTK to be selected, and we don't = want this > > being built for shim. We also don't want TRACEBUFFER or GDBSX = either. > > > > Take this oppotunity to swap the disable of HVM_FEP for a general = disable of > > HVM (likely to have wider impliciations in the future), and disable = ARGO (will > > necesserily need plumbing work to function in shim). >=20 > Odd. I was quite sure this is the case already; in particular my > own build test of a shim config has this already. >=20 > > Signed-off-by: Andrew Cooper >=20 > Reviewed-by: Jan Beulich Release-acked-by: Paul Durrant >=20 > I have a question though (without implying the patch here needs > adjusting, but rather with a look towards after 4.14): >=20 > > --- a/xen/arch/x86/configs/pvshim_defconfig > > +++ b/xen/arch/x86/configs/pvshim_defconfig > > @@ -5,19 +5,25 @@ CONFIG_PVH_GUEST=3Dy > > CONFIG_PV_SHIM=3Dy > > CONFIG_PV_SHIM_EXCLUSIVE=3Dy > > CONFIG_NR_CPUS=3D32 > > +CONFIG_EXPERT=3Dy > > +CONFIG_SCHED_NULL=3Dy > > # Disable features not used by the PV shim > > +# CONFIG_HVM is not set > > +# CONFIG_XEN_SHSTK is not set > > # CONFIG_HYPFS is not set > > # CONFIG_SHADOW_PAGING is not set > > # CONFIG_BIGMEM is not set > > -# CONFIG_HVM_FEP is not set > > # CONFIG_TBOOT is not set > > # CONFIG_KEXEC is not set > > # CONFIG_XENOPROF is not set > > # CONFIG_XSM is not set > > +# CONFIG_ARGO is not set > > +# CONFIG_SCHED_CREDIT is not set > > # CONFIG_SCHED_CREDIT2 is not set > > # CONFIG_SCHED_RTDS is not set > > # CONFIG_SCHED_ARINC653 is not set > > -# CONFIG_SCHED_NULL is not set > > # CONFIG_LIVEPATCH is not set > > # CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set > > +# CONFIG_TRACEBUFFER is not set > > # CONFIG_DEBUG is not set > > +# CONFIG_GDBSX is not set >=20 > I assume both the "enable" and "disable" sections here are ordered > like they would be in a resulting full .config. But this being two > separate sections, doing so doesn't help e.g. diff-ing. How about > we sort both sections alphabetically (short of other good sorting > criteria, yet better than entirely unsorted)? >=20 > Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 04 08:02:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 08:02:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkpq-0002mM-7l; Thu, 04 Jun 2020 08:02:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkpo-0002mH-J9 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 08:02:44 +0000 X-Inumbo-ID: c4986c1a-a639-11ea-9dbe-bc764e2007e4 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe0a::625]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c4986c1a-a639-11ea-9dbe-bc764e2007e4; Thu, 04 Jun 2020 08:02:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=moBe8p8eAcPFKrm34g8hl0lNqeABwxW8qltbFSjliJM=; b=n5q5il/NCe1hcUd2N7vF+AoMCrnlpywiYHiOx0rzld8DxGepJLykJ3Sz8dDhOw+rJXrQYbYJsWP5uhm+mQAYMoBWQRUO8sfYy4SIAV7UWqdcKGJzvRfx1exeCxYSOVC4e2sLc6Pj9buoQKZBZc8LyN/5zlZ/YtbHOzB3o7CbWho= Received: from DB3PR06CA0002.eurprd06.prod.outlook.com (2603:10a6:8:1::15) by AM0PR08MB3764.eurprd08.prod.outlook.com (2603:10a6:208:ff::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 08:02:41 +0000 Received: from DB5EUR03FT007.eop-EUR03.prod.protection.outlook.com (2603:10a6:8:1:cafe::b0) by DB3PR06CA0002.outlook.office365.com (2603:10a6:8:1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Thu, 4 Jun 2020 08:02:41 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT007.mail.protection.outlook.com (10.152.20.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Thu, 4 Jun 2020 08:02:41 +0000 Received: ("Tessian outbound d078647f4174:v57"); Thu, 04 Jun 2020 08:02:41 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: a9b7b248646322a6 X-CR-MTA-TID: 64aa7808 Received: from 1355224e9e85.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7EC93A50-16AD-49EF-825A-954974912EE3.1; Thu, 04 Jun 2020 08:02:36 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1355224e9e85.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 04 Jun 2020 08:02:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fu95l64+BGAY4SbzCIfNuHNH55B0v0bUQjYib06pvL8yhFMnhOUUafeSab5rt+UR9NUaJ52WLySV1lV8Y1ugvGDvSBm2YJUm0WcgsBphNKqEHVCz0wegbEJaPoOirXl1nV+905+TDYtahtx82kzr3jzqoENn+Jm1fF1sxFZqRnv0/eXKqtFd505pCzv+950CmXYc87aC757Nb4KcEOF1j2Dbu0TFUdZYIHAwopWwonCFWw+SvUUS+rsGu7mrL5pUM3uKUNhwlO8ZRuMXtIQF1l7zlS01PMHd5I2U+4dOVKuy93ZwG6q1zQjNqJTCOcFAjx29wsXMyUonIjp+00MLZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=moBe8p8eAcPFKrm34g8hl0lNqeABwxW8qltbFSjliJM=; b=X9n7ASBHtdnraXOabO7KlWw5Hb08YWsLN0adf/bDKiLX5IEu4FtBac5DFF1uSoXOwHE7tveuGy5qZLEd/rFHIV/mI9cjyuUqCGFGMWV6P05YhBgxqRr0MG7fvSKiQQEXAzWkR4bf6KxNjSot8/79ah/d3KOSubnhS4N2DqNCU0ZWNHvbf29Jjzm3lzpr6LrJ58YLYLkLWS0ULUzzBIXsbkp1PBkL0Yprz275qTHz+S3Y8/WUwesAqQPQmCYUvajTzjkmIKvaqqNF/iLRfS61P3Q1CxBbvw6beoeDtNLQVvmOQVzLLO/MYIZRQIw/PLgWpJiOfLjYdqAQvXeDXg9NfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=moBe8p8eAcPFKrm34g8hl0lNqeABwxW8qltbFSjliJM=; b=n5q5il/NCe1hcUd2N7vF+AoMCrnlpywiYHiOx0rzld8DxGepJLykJ3Sz8dDhOw+rJXrQYbYJsWP5uhm+mQAYMoBWQRUO8sfYy4SIAV7UWqdcKGJzvRfx1exeCxYSOVC4e2sLc6Pj9buoQKZBZc8LyN/5zlZ/YtbHOzB3o7CbWho= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3052.eurprd08.prod.outlook.com (2603:10a6:5:28::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Thu, 4 Jun 2020 08:02:33 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3066.019; Thu, 4 Jun 2020 08:02:33 +0000 From: Bertrand Marquis To: CodeWiz2280 Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEA Date: Thu, 4 Jun 2020 08:02:33 +0000 Message-ID: <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b8a2ba95-0f71-4cc8-5dd0-08d8085da810 x-ms-traffictypediagnostic: DB7PR08MB3052:|AM0PR08MB3764: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04244E0DC5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: MYQ1cNRKIwRA1JIwOYL0qsJwtm4Rl4wUCW4nhEam5OaC7XG36NNWmwH04WI5xGyNgGyVF6LWqVyPC4cOeLy9hOOGZj1cJLDeykdWvSaWyTtx8ftaaGI3gO3Na6KDqUfLHsOh0sZbNc+p7EteHdwpKT1GK4/BgyNU61KZDO1SMwJlGcl0Z2Jk3ZKW5dDRL69HiTDvgf75jRe8pLS1Sga1WD7R4ZGun2dy2hM6gMiDL7i47iFl0v8CubtD04+H9y+q9WIcACHf6CRjUJS/CuvDoypr2ZQ0NebKmANYkCr9uAZj3eMnVmrIEAn/L23HRdb5 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(346002)(376002)(136003)(39860400002)(76116006)(91956017)(66476007)(7116003)(26005)(316002)(66556008)(36756003)(71200400001)(33656002)(66946007)(3480700007)(64756008)(478600001)(6506007)(4326008)(54906003)(8936002)(2616005)(5660300002)(66446008)(53546011)(83380400001)(186003)(8676002)(6486002)(86362001)(6916009)(2906002)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ybTSivK4YnL1mMVTevgunokPYwOvl3eKNUSp9EdvHyCIDPwQwjrVVutMnttKBnoCGTJGo8PzA3S4yiwve1pWxidOc84e5ElwwspaDFklJqxZeG/AgPL+6mLj5NpvdUXhOmkbC787QH2wldVVGnxBBS7XVJ18F/qzioP21sJl+Z+uhJxLIYrMrJ8QSXQRtkeQ2n41VWDVaGYF33z/Sp96VEqNYJkn05PtBqh5DeejNXPmxqeU7MgCyW8ugi2VHD7OFbKVCM9LNa2zqR/ZZhIO4nmLWk8gZufcXoa4VfUoL6s2T6STY5eR7tjwNcAvqzch7GcUPg31L+fv4sIEzhsK5TcMXX2nrnxJ251csnkijujBpUWfryIJwyAwSZ7MIvq/lgegqMNDIE3JNiW2ip95C+EiOBxmy5muIHscS/2w3oC2UjUtg4w7Lp2kjbPB/V2EkmH7WPdRXQu/MIZ6ld1Bg1esc63IEXvf3y4NHLY+Vkez0RT1Nx9bPkwngZB6FGZ5 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <90A25ABBFC7FF24E91EB0EEA65AE3526@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3052 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT007.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(39860400002)(346002)(46966005)(478600001)(186003)(336012)(2906002)(8936002)(26005)(36756003)(70206006)(83380400001)(316002)(3480700007)(8676002)(6512007)(82740400003)(47076004)(4326008)(54906003)(7116003)(33656002)(6862004)(6486002)(5660300002)(6506007)(2616005)(53546011)(86362001)(81166007)(356005)(82310400002)(70586007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: b2c72dca-47f8-4ef4-2c5f-08d8085da323 X-Forefront-PRVS: 04244E0DC5 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: F1LMXB9p50IIgWGmqCL1EaCUtF39OFaxNK60FqxNkrNYkIGuqVsML+VW8uvh2uKfZeFDI7FMHBRRZeZN8FhgfDuTtoweNfAi8cMUgqSGzpa3mpOmqcjSgmkI8vXzD/To3+UP9BI4JRK6wkAIYNg9LOjPHCT1ImByfNUO8OyiWtFmdy/rX7ghDjHVT20Sjo8/Vh0wO8jRjvqkeG2dxmTqbFSBdR4IQJ4UhFga4a/o1e0+I4zk7SHGDoIQys/7FqEbkewUcCI1BSgAVRtMVArGQxrLM4S43huYish3pJ6XlYGfW9u3aIPj69TSSlxGsdklSWGA1lxL/sRh5GeRncZVTfq5r+M5CPD7vxRgrkJtcLknjEelZatMoQjLNI3zNR17mj6lYvJjEs2o+KrHWikfyQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2020 08:02:41.7480 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b8a2ba95-0f71-4cc8-5dd0-08d8085da810 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3764 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, > On 3 Jun 2020, at 19:09, Julien Grall wrote: >=20 >=20 >=20 > On 03/06/2020 18:13, CodeWiz2280 wrote: >> Hi Julien, >=20 > Hello, >=20 > In general, we avoid top post on xen-devel, instead we reply inline. I be= lieve gmail should allow you to do it :). >=20 >> The offset is already applied to the memory nodes in the device tree, me= aning a direct Linux boot from uboot would have only the 36-bit addresses i= n the device tree (0x8_0000_0000 and 0x8_8000_0000). Linux would start exe= cuting from a 32-bit address space however and then switch over to the alia= sed 36-bit addresses in the device tree as discussed below by early_paging_= init(). >> I had to add the 32-bit memory node 0x8000_0000 in uboot in place of the= 0x8_0000_0000 node otherwise Xen would detect the 32-bit processor and pan= ic on "Unable to detect the first memory bank" in domain_build.c.=20 >=20 > So for 32-bit Xen requires to have the first bank below 4GB. This is beca= use you can't boot from a physical address above 32-bit. >=20 > Obviously, this check wouldn't work on your platform because all your mem= ory will be above 4GB. I think that the Keystone board has low memory accessible at 2 different ad= dress (one low and one high). I would here suggest to have a dtb with 2 regions (one under 4GB and one ov= er) and remove from the region over 4G the area already addressed by the re= gion under 4GB. Does that make sense ? Cheers Bertrand >=20 >> If I leave only the 36-bit addresses in the device tree and skip past th= e panic check in domain_build.c, then I could not get the dom0 kernel to bo= ot at all. I believe I would only see "Serial input to DOM0" and nothing e= lse at that point. >=20 > Which would make sense per above. >=20 >> Yes, leaving LPAE support on for the kernel is preferred. >=20 > Ok, so the solution I suggested below should work. Unfortunately, I don't= have time to work on it. Although, I would be more than happy to answers q= uestions and reviewing the patches. >=20 > Would you be willing to have a try to implement it? >=20 > Cheers, >=20 > --=20 > Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 08:08:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 08:08:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkus-0002x2-Sj; Thu, 04 Jun 2020 08:07:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkur-0002wx-Fw for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 08:07:57 +0000 X-Inumbo-ID: 7f508fa6-a63a-11ea-81bc-bc764e2007e4 Received: from mail-wr1-x42c.google.com (unknown [2a00:1450:4864:20::42c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7f508fa6-a63a-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 08:07:56 +0000 (UTC) Received: by mail-wr1-x42c.google.com with SMTP id c3so4993588wru.12 for ; Thu, 04 Jun 2020 01:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=NxmGzct06XRMEU7rIZKUdCcw+WTOot7HRLTCpNpzNhA=; b=W6u56uDh31Or3xU/MYyaAR9l6lGl5ww6JdAlW7JGq38DHhlOwMNERBDkvlPQguQPqH +0vKVB541h2vSsXwgDpFV0eOHZHLwsVe6XAzTp/Yfi8BDP2RJ8AhF3+BnQFwQp1ZCr49 HcP+2hCUu1/wuF/jME8/Y0S+wXQneY1c+/s4kIyiYoAr/fvd67xMiSMDeLM9VSGxEyW0 J2+mDKLHc4iQxY6/ZANuL96AcFwTuv8QBY1VBqcBOR+Y6Ujt/jps1GdG5K3u4j0oDmPH hNA/xyRWSV9Jg32jBkWaKGvyOOGCkNzzxGbs1GhafGsN5qldWPLqCaRnCEK+RPsrFuZM JWpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=NxmGzct06XRMEU7rIZKUdCcw+WTOot7HRLTCpNpzNhA=; b=i1hb3B3LXlCkQvVl/kAZ7aYrXDOiDGMLs0pRDGGNnTBECEp5aNBfmC0ksr2mjtNIMF jUvivfTCmg3x59V0byOIdlHa72Stj8bSiiN8TfgapqUHb353HXN9bW599ruOKbWPs6b+ zSu9HUL8aDg6OKOly/n0SgwRoibFYRIe+Uwj7X5+ri/7ozEyNGhBuqC9Z/N4Af/2VqHm fQDCFU9lW7dPRWqsuayCIQ8QNLmqIi+aZZGCIB7V+xSPvRO4oaWGP8g/JwViuQ83pqhL IMXj0O1Ngo3XjMEzzoLCUvg+zUlDYGZzviQRKH2lEiSjGOmHIk4w0aOrIqH6I4DmmVDh 0XZw== X-Gm-Message-State: AOAM532dTcP5wMAFf3ywaPkgpKotuFFhSJB6H2dQP3/P/eNBX62dPelY rOdmGEwlaSpVvyYrZPA/gM4= X-Google-Smtp-Source: ABdhPJwgJ9yWrVGNGFftYWPtCLSOqlkCY+Mt84OPjicEO2z/QGgC0Ybkin5dabwdej2i8OW8qdo8rQ== X-Received: by 2002:a5d:468d:: with SMTP id u13mr3422084wrq.73.1591258075866; Thu, 04 Jun 2020 01:07:55 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id h7sm6116417wml.24.2020.06.04.01.07.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 01:07:55 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= , References: <35df958d-eff8-9ca7-fd72-05694f07248d@suse.com> In-Reply-To: <35df958d-eff8-9ca7-fd72-05694f07248d@suse.com> Subject: RE: Xenstore quota and driver domains Date: Thu, 4 Jun 2020 09:07:54 +0100 Message-ID: <006701d63a47$408511c0$c18f3540$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJua4BClDl1csHN5IQ1VoJLzvIqqqeXtW4Q X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = J=C3=BCrgen Gro=C3=9F > Sent: 04 June 2020 06:03 > To: xen-devel@lists.xenproject.org > Subject: Xenstore quota and driver domains >=20 > A recent report on xen-users surfaced a problem we have with driver > domains in medium sized or large configuration: the driver domain can > easily hit the default Xenstore quota (in the report it was a driver > domain for disks which hit the quota when 15 domUs were active at the > same time). Which quota is hit? Node or watch? >=20 > Setting the quota to a higher limit will work, of course, but this > enables "normal" domUs to use this quota, too, thus hogging lots of > Xenstore resources. >=20 > I believe the most sensible way to solve that would be to have a way > to set per-domain quota in Xenstore. As the original reporter already > raised concerns regarding rebooting the server for applying new global > quota, I believe new quota settings should be possible at runtime. >=20 > The question is how this interface should look like. Right now I could > think of two variants: >=20 > 1. A new XS_SET_QUOTA and XS_GET_QUOTA wire command pair which can set > and get the quota (both, default values for new domains and for = any > existing domain) >=20 > 2. A new XS_CONTROL command for setting/getting quota (same scope as = 1.) >=20 > Both variants have advantages and disadvantages: >=20 > 1. Pros: - clear interface, easily usable > Cons: - requires more code churn in tools (libxenstore, xl, libxl) > for support in domain-config > - any extension will again require similar churn >=20 > 2. Pros: - easy extensible domain-config possible (via a single item, > e.g. "xenstore-quota=3D'watches=3D10 entries=3D2000'") > Cons: - text parsing in Xenstore instead of xl/libxl > - XS_CONTROL sub-options for quota will be ABI >=20 > Any thoughts? Even though 1 requires more code churn, I still think it is the better = way to go. Paul >=20 >=20 > Juergen From xen-devel-bounces@lists.xenproject.org Thu Jun 04 08:11:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 08:11:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkxp-0003mu-Fc; Thu, 04 Jun 2020 08:11:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgkxo-0003mo-PZ for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 08:11:00 +0000 X-Inumbo-ID: eca15b9e-a63a-11ea-9dbe-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eca15b9e-a63a-11ea-9dbe-bc764e2007e4; Thu, 04 Jun 2020 08:11:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C15F7AD93; Thu, 4 Jun 2020 08:11:02 +0000 (UTC) Subject: Re: Xenstore quota and driver domains To: paul@xen.org, xen-devel@lists.xenproject.org References: <35df958d-eff8-9ca7-fd72-05694f07248d@suse.com> <006701d63a47$408511c0$c18f3540$@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Thu, 4 Jun 2020 10:10:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <006701d63a47$408511c0$c18f3540$@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.20 10:07, Paul Durrant wrote: >> -----Original Message----- >> From: Xen-devel On Behalf Of Jürgen Groß >> Sent: 04 June 2020 06:03 >> To: xen-devel@lists.xenproject.org >> Subject: Xenstore quota and driver domains >> >> A recent report on xen-users surfaced a problem we have with driver >> domains in medium sized or large configuration: the driver domain can >> easily hit the default Xenstore quota (in the report it was a driver >> domain for disks which hit the quota when 15 domUs were active at the >> same time). > > Which quota is hit? Node or watch? Node. > >> >> Setting the quota to a higher limit will work, of course, but this >> enables "normal" domUs to use this quota, too, thus hogging lots of >> Xenstore resources. >> >> I believe the most sensible way to solve that would be to have a way >> to set per-domain quota in Xenstore. As the original reporter already >> raised concerns regarding rebooting the server for applying new global >> quota, I believe new quota settings should be possible at runtime. >> >> The question is how this interface should look like. Right now I could >> think of two variants: >> >> 1. A new XS_SET_QUOTA and XS_GET_QUOTA wire command pair which can set >> and get the quota (both, default values for new domains and for any >> existing domain) >> >> 2. A new XS_CONTROL command for setting/getting quota (same scope as 1.) >> >> Both variants have advantages and disadvantages: >> >> 1. Pros: - clear interface, easily usable >> Cons: - requires more code churn in tools (libxenstore, xl, libxl) >> for support in domain-config >> - any extension will again require similar churn >> >> 2. Pros: - easy extensible domain-config possible (via a single item, >> e.g. "xenstore-quota='watches=10 entries=2000'") >> Cons: - text parsing in Xenstore instead of xl/libxl >> - XS_CONTROL sub-options for quota will be ABI >> >> Any thoughts? > > Even though 1 requires more code churn, I still think it is the better way to go. Noted. Juergen From xen-devel-bounces@lists.xenproject.org Thu Jun 04 08:15:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 08:15:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgl2K-0003xl-0m; Thu, 04 Jun 2020 08:15:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgl2J-0003xg-5Z for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 08:15:39 +0000 X-Inumbo-ID: 92c8179c-a63b-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 92c8179c-a63b-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 08:15:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=JyNypDenEJwPw5zBl+ee8iQL3WsDRedh1zsb+turEhM=; b=XwMV41fU6d8QY/rP+hk/t3iFhL aLMZYFhG65HNXaUzxXVMk5rbFiRkaKmM/eKxBzvX3LHtl9N9erYY+jXMTOt+PELazoMHwF6M1tEsd pxpMYKVdkTDWn03aJWUTMH5Z8n0ybXkQgEpNKEV2uAJHTLedP4ocoOUtyNfkaGJuUeHY=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgl2G-0007IH-4v; Thu, 04 Jun 2020 08:15:36 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgl2F-00081M-UZ; Thu, 04 Jun 2020 08:15:36 +0000 Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: cminyard@mvista.com, Stefano Stabellini References: <20200603223156.12767-1-sstabellini@kernel.org> <20200604001552.GC2903@minyard.net> From: Julien Grall Message-ID: <50ad4bca-5eb8-8db0-0aae-dc7febfdb56a@xen.org> Date: Thu, 4 Jun 2020 09:15:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200604001552.GC2903@minyard.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, roman@zededa.com, tamas@tklengyel.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 04/06/2020 01:15, Corey Minyard wrote: > On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote: >> Touching the watchdog is required to be able to reboot the board. >> >> The implementation is based on >> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > Ah, I was looking at this just today, as it had been annoying me > greatly. This works for me, so: > > Tested-by: Corey Minyard > > However, I was wondering if it might be better to handle this by failing > the operation in xen and passing it back to dom0 to do. On the Pi you > send a firmware message to reboot, and that seems like too much to do in > Xen, but it would seem possible to send this back to dom0. I don't think this is possible in the current setup. Xen will usually restart the platform if Dom0 requested a clean reboot or crashed. So the domain wouldn't be in state to service such call. > Just a > thought, as it might be a more general fix for other devices in the same > situation. What are the devices you have in mind? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 08:16:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 08:16:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgl38-000416-AX; Thu, 04 Jun 2020 08:16:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgl36-00040u-Oe for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 08:16:28 +0000 X-Inumbo-ID: b02f3d56-a63b-11ea-81bc-bc764e2007e4 Received: from mail-wm1-x32f.google.com (unknown [2a00:1450:4864:20::32f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b02f3d56-a63b-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 08:16:28 +0000 (UTC) Received: by mail-wm1-x32f.google.com with SMTP id r9so4306912wmh.2 for ; Thu, 04 Jun 2020 01:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=0kzTUsAILuup2XHBaZJ9VmrOmJ8KV8vfdvWS4tomuL4=; b=PgzxATi+cjGGK+/FErIbu1HM6HKn61VlQj0TJacPUUz6RfZ8LLDvCAeUz0iclQl+Tr h83gMH3/O73FpvVmptyRlrEsLgrzAUNk2gK1gAMFvpdpys+oeSoA+wzVw7mlToDamaT9 7eS2X44qa7degm0q8U/cq8CVfRlazvv5P/Pu+Rwb41SgxvqohSXm1oaZN7HtX62JnoNf tM/4YfTzLtpHQaxknIComLPLcku0Wnlb5mrc9trOLGvXcZ9pz/ZghIjS0LNCjC3Mz1xg rt4N6X8dP7fk7Q9KTG/nOyzHIeyjw53gkcrBLy6/v38xmdTfJ7Sbre4Nm8VLNve3ZNQr satQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=0kzTUsAILuup2XHBaZJ9VmrOmJ8KV8vfdvWS4tomuL4=; b=bCke1OqdGdyy+7N2mVzqlK0yU617cEWCe11LrC4koIu/P5a43EkKt0H0DNhWIHA8Oy 4mU3gVZhjSawlFbxJkbKXUf4wiR3uWJIFXCeSLafgNx9jcutCejwf2wX9XkdzgzUsX5v pfjl9MNNZvOfmyHrpWpd+CZFVEkyRzO7AImphMhP0kevwQm3XOogmaEyit38euYQF5Re 5/AXlxvG/H8CJTdHRMAoUCQC2M+i3D72zZFPqqmffVNTiHw5olsq4j0sPJgQvRHBsgma iT336xbl5p7uiA66WdwrHJJC54VSLTBnfqJYtw5vd8Fd594j3LyRqzedtGHqzPwptBIk S1tg== X-Gm-Message-State: AOAM532rfo/AdnWvv+EWJ73qR1vQbwgeMQnPucSSgG2GLU7eA0n/XBVh Onn6++UVbB1YMm7GiAmVjVg= X-Google-Smtp-Source: ABdhPJyMLVjwiXBSeTEOpFxIHkG8MPyGNaT5eib3zyfpYoOt6rO4pCG1NoTTiI0hSpKbkTlws4zt2w== X-Received: by 2002:a7b:cd83:: with SMTP id y3mr2801082wmj.5.1591258587409; Thu, 04 Jun 2020 01:16:27 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id h12sm6598995wro.80.2020.06.04.01.16.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 01:16:26 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= , References: <35df958d-eff8-9ca7-fd72-05694f07248d@suse.com> <006701d63a47$408511c0$c18f3540$@xen.org> In-Reply-To: Subject: RE: Xenstore quota and driver domains Date: Thu, 4 Jun 2020 09:16:25 +0100 Message-ID: <006801d63a48$7173f750$545be5f0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJua4BClDl1csHN5IQ1VoJLzvIqqgHU1vnUAjwCJFOndzHUwA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: J=C3=BCrgen Gro=C3=9F > Sent: 04 June 2020 09:11 > To: paul@xen.org; xen-devel@lists.xenproject.org > Subject: Re: Xenstore quota and driver domains >=20 > On 04.06.20 10:07, Paul Durrant wrote: > >> -----Original Message----- > >> From: Xen-devel On Behalf = Of J=C3=BCrgen Gro=C3=9F > >> Sent: 04 June 2020 06:03 > >> To: xen-devel@lists.xenproject.org > >> Subject: Xenstore quota and driver domains > >> > >> A recent report on xen-users surfaced a problem we have with driver > >> domains in medium sized or large configuration: the driver domain = can > >> easily hit the default Xenstore quota (in the report it was a = driver > >> domain for disks which hit the quota when 15 domUs were active at = the > >> same time). > > > > Which quota is hit? Node or watch? >=20 > Node. >=20 Ok. Since each individual backend is going to watch at least its = frontend's 'state' node then a watch quota of 128 is still probably = going to be restrictive for a global driver domain so this ought to be = settable on a per-domain basis as well as the node quota. Paul From xen-devel-bounces@lists.xenproject.org Thu Jun 04 08:25:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 08:25:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jglBp-00050k-6p; Thu, 04 Jun 2020 08:25:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jglBn-00050f-3i for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 08:25:27 +0000 X-Inumbo-ID: f0c42588-a63c-11ea-ae3d-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f0c42588-a63c-11ea-ae3d-12813bfff9fa; Thu, 04 Jun 2020 08:25:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B7777AC96; Thu, 4 Jun 2020 08:25:28 +0000 (UTC) Subject: Re: Xenstore quota and driver domains To: paul@xen.org, xen-devel@lists.xenproject.org References: <35df958d-eff8-9ca7-fd72-05694f07248d@suse.com> <006701d63a47$408511c0$c18f3540$@xen.org> <006801d63a48$7173f750$545be5f0$@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Thu, 4 Jun 2020 10:25:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <006801d63a48$7173f750$545be5f0$@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.20 10:16, Paul Durrant wrote: >> -----Original Message----- >> From: Jürgen Groß >> Sent: 04 June 2020 09:11 >> To: paul@xen.org; xen-devel@lists.xenproject.org >> Subject: Re: Xenstore quota and driver domains >> >> On 04.06.20 10:07, Paul Durrant wrote: >>>> -----Original Message----- >>>> From: Xen-devel On Behalf Of Jürgen Groß >>>> Sent: 04 June 2020 06:03 >>>> To: xen-devel@lists.xenproject.org >>>> Subject: Xenstore quota and driver domains >>>> >>>> A recent report on xen-users surfaced a problem we have with driver >>>> domains in medium sized or large configuration: the driver domain can >>>> easily hit the default Xenstore quota (in the report it was a driver >>>> domain for disks which hit the quota when 15 domUs were active at the >>>> same time). >>> >>> Which quota is hit? Node or watch? >> >> Node. >> > > Ok. Since each individual backend is going to watch at least its frontend's 'state' node then a watch quota of 128 is still probably going to be restrictive for a global driver domain so this ought to be settable on a per-domain basis as well as the node quota. TBH I'd go with any quota to be settable via the new interface. Currently we have: - number of nodes - max size of a node - number of watches - number of concurrent active transactions and there might be more coming in the future. Juergen From xen-devel-bounces@lists.xenproject.org Thu Jun 04 08:48:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 08:48:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jglYR-0006v3-6U; Thu, 04 Jun 2020 08:48:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jglYP-0006uy-QZ for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 08:48:49 +0000 X-Inumbo-ID: 354a0c92-a640-11ea-8993-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 354a0c92-a640-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 08:48:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=iQIB/lvec4x/vrxGo08+YIUYpANYdEkGnyXNKnZaR3w=; b=rgjjwEc4SKcu8G1bbZOAHyjC/5 ycMHFwNRrfH6pwHd3N/MoFcBx9cyFjv1CaufSXC0Z3PMAbnyPm6mOOVPypE+vvThIo9uXwMCjSgm0 Hyoba0jK+bxjtrOwAHUOTOUNB2Xf8qWsHxVs5xwSaNahoQDCQpdN/Ml97+2aEATeSymk=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jglYL-0007xf-Ry; Thu, 04 Jun 2020 08:48:45 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jglYL-0001Cv-Ki; Thu, 04 Jun 2020 08:48:45 +0000 Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: Stefano Stabellini References: <20200603223156.12767-1-sstabellini@kernel.org> From: Julien Grall Message-ID: <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> Date: Thu, 4 Jun 2020 09:48:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200603223156.12767-1-sstabellini@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: cminyard@mvista.com, tamas@tklengyel.com, Andre Przywara , roman@zededa.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" (+ Andre) Hi, On 03/06/2020 23:31, Stefano Stabellini wrote: > Touching the watchdog is required to be able to reboot the board. In general the preferred method is PSCI. Does it mean RPI 4 doesn't support PSCI at all? > > The implementation is based on > drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. Can you give the baseline? This would allow us to track an issue and port them. > > Signed-off-by: Stefano Stabellini > --- > xen/arch/arm/platforms/brcm-raspberry-pi.c | 60 ++++++++++++++++++++++ > 1 file changed, 60 insertions(+) > > diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c b/xen/arch/arm/platforms/brcm-raspberry-pi.c > index f5ae58a7d5..0214ae2b3c 100644 > --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c > +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c > @@ -18,6 +18,10 @@ > */ > > #include > +#include > +#include > +#include > +#include We are trying to keep the headers ordered alphabetically within each directory and then 'xen/' first following by 'asm/'. > > static const char *const rpi4_dt_compat[] __initconst = > { > @@ -37,12 +41,68 @@ static const struct dt_device_match rpi4_blacklist_dev[] __initconst = > * The aux peripheral also shares a page with the aux UART. > */ > DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"), > + /* Special device used for rebooting */ > + DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"), > { /* sentinel */ }, > }; > > + > +#define PM_PASSWORD 0x5a000000 > +#define PM_RSTC 0x1c > +#define PM_WDOG 0x24 > +#define PM_RSTC_WRCFG_FULL_RESET 0x00000020 > +#define PM_RSTC_WRCFG_CLR 0xffffffcf NIT: It is a bit odd you introduce the 5 define together but the first 3 have a different indentation compare to the last 2. > + > +static void __iomem *rpi4_map_watchdog(void) > +{ > + void __iomem *base; > + struct dt_device_node *node; > + paddr_t start, len; > + int ret; > + > + node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm"); > + if ( !node ) > + return NULL; > + > + ret = dt_device_get_address(node, 0, &start, &len); > + if ( ret ) > + { > + dprintk(XENLOG_ERR, "Cannot read watchdog register address\n"); I would suggest to use printk() rather than dprintk. It would be useful for a normal user to know that we didn't manage to reset the platform and why. > + return NULL; > + } > + > + base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE); > + if ( !base ) > + { > + dprintk(XENLOG_ERR, "Unable to map watchdog register!\n"); > + return NULL; > + } > + > + return base; > +} > + > +static void rpi4_reset(void) > +{ > + u32 val; We are trying to get rid of any use of u32 in Xen code (the coding style used in this file). Please use uint32_t instead. > + void __iomem *base = rpi4_map_watchdog(); Newline here please. > + if ( !base ) > + return; > + > + /* use a timeout of 10 ticks (~150us) */ > + writel(10 | PM_PASSWORD, base + PM_WDOG); > + val = readl(base + PM_RSTC); > + val &= PM_RSTC_WRCFG_CLR; > + val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET; > + writel(val, base + PM_RSTC); > + > + /* No sleeping, possibly atomic. */ > + mdelay(1); > +} > + > PLATFORM_START(rpi4, "Raspberry Pi 4") > .compatible = rpi4_dt_compat, > .blacklist_dev = rpi4_blacklist_dev, > + .reset = rpi4_reset, > .dma_bitsize = 30, > PLATFORM_END > > Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 08:59:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 08:59:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgliz-0007uK-4o; Thu, 04 Jun 2020 08:59:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jglix-0007uF-Qh for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 08:59:43 +0000 X-Inumbo-ID: bb180d32-a641-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bb180d32-a641-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 08:59:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=r4y/N2C0djKsg8FqZM/vBcEgbQvLvqVDERZBiJhJQoY=; b=tk0S+4L+BXkHROMRjVXWGBsiZ+ csk98VfX8f4EFc+5hw2ZRUksiB/ngPDa4VIHTJYcLV3N4CRnHco4r/WXxN/tJWR/BI3lWVnbZJPab F/gO2O254Kd6lrWW6LHgmRdc5sQeiKtd4PkxR0OG9ie0FM1CWS3IcLuYpOf9vmurmte8=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgliw-0008B6-P5; Thu, 04 Jun 2020 08:59:42 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgliw-0001nt-I0; Thu, 04 Jun 2020 08:59:42 +0000 Subject: Re: Keystone Issue To: Bertrand Marquis , CodeWiz2280 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> From: Julien Grall Message-ID: <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> Date: Thu, 4 Jun 2020 09:59:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 09:02, Bertrand Marquis wrote: > Hi, Hi Bertrand, > >> On 3 Jun 2020, at 19:09, Julien Grall wrote: >> >> >> >> On 03/06/2020 18:13, CodeWiz2280 wrote: >>> Hi Julien, >> >> Hello, >> >> In general, we avoid top post on xen-devel, instead we reply inline. I believe gmail should allow you to do it :). >> >>> The offset is already applied to the memory nodes in the device tree, meaning a direct Linux boot from uboot would have only the 36-bit addresses in the device tree (0x8_0000_0000 and 0x8_8000_0000). Linux would start executing from a 32-bit address space however and then switch over to the aliased 36-bit addresses in the device tree as discussed below by early_paging_init(). >>> I had to add the 32-bit memory node 0x8000_0000 in uboot in place of the 0x8_0000_0000 node otherwise Xen would detect the 32-bit processor and panic on "Unable to detect the first memory bank" in domain_build.c. >> >> So for 32-bit Xen requires to have the first bank below 4GB. This is because you can't boot from a physical address above 32-bit. >> >> Obviously, this check wouldn't work on your platform because all your memory will be above 4GB. > > I think that the Keystone board has low memory accessible at 2 different address (one low and one high). > > I would here suggest to have a dtb with 2 regions (one under 4GB and one over) and remove from the region over 4G the area already addressed by the region under 4GB. I thought about this. However, in an earlier reply, David wrote: "4. The dom0 kernel will boot from xen if the early_paging_init switch step is skipped, and the low mem stays in 32-bit....but there is a problem with the peripherals so this is not an acceptable solution." It is not clear to me what sort of issues will arise with the peripherals. But I have assumed that it wouldn't be possible for Dom0 to keep using the memory below 4GB. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 09:00:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 09:00:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgljM-0000Af-D3; Thu, 04 Jun 2020 09:00:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgljL-0000AT-B6 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 09:00:07 +0000 X-Inumbo-ID: c8dab884-a641-11ea-9dbe-bc764e2007e4 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id c8dab884-a641-11ea-9dbe-bc764e2007e4; Thu, 04 Jun 2020 09:00:06 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CE92755D; Thu, 4 Jun 2020 02:00:05 -0700 (PDT) Received: from [192.168.2.22] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D3AE63F6CF; Thu, 4 Jun 2020 02:00:04 -0700 (PDT) Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: Julien Grall , Stefano Stabellini References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= Autocrypt: addr=andre.przywara@arm.com; prefer-encrypt=mutual; keydata= xsFNBFNPCKMBEAC+6GVcuP9ri8r+gg2fHZDedOmFRZPtcrMMF2Cx6KrTUT0YEISsqPoJTKld tPfEG0KnRL9CWvftyHseWTnU2Gi7hKNwhRkC0oBL5Er2hhNpoi8x4VcsxQ6bHG5/dA7ctvL6 kYvKAZw4X2Y3GTbAZIOLf+leNPiF9175S8pvqMPi0qu67RWZD5H/uT/TfLpvmmOlRzNiXMBm kGvewkBpL3R2clHquv7pB6KLoY3uvjFhZfEedqSqTwBVu/JVZZO7tvYCJPfyY5JG9+BjPmr+ REe2gS6w/4DJ4D8oMWKoY3r6ZpHx3YS2hWZFUYiCYovPxfj5+bOr78sg3JleEd0OB0yYtzTT esiNlQpCo0oOevwHR+jUiaZevM4xCyt23L2G+euzdRsUZcK/M6qYf41Dy6Afqa+PxgMEiDto ITEH3Dv+zfzwdeqCuNU0VOGrQZs/vrKOUmU/QDlYL7G8OIg5Ekheq4N+Ay+3EYCROXkstQnf YYxRn5F1oeVeqoh1LgGH7YN9H9LeIajwBD8OgiZDVsmb67DdF6EQtklH0ycBcVodG1zTCfqM AavYMfhldNMBg4vaLh0cJ/3ZXZNIyDlV372GmxSJJiidxDm7E1PkgdfCnHk+pD8YeITmSNyb 7qeU08Hqqh4ui8SSeUp7+yie9zBhJB5vVBJoO5D0MikZAODIDwARAQABzS1BbmRyZSBQcnp5 d2FyYSAoQVJNKSA8YW5kcmUucHJ6eXdhcmFAYXJtLmNvbT7CwXsEEwECACUCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheABQJTWSV8AhkBAAoJEAL1yD+ydue63REP/1tPqTo/f6StS00g NTUpjgVqxgsPWYWwSLkgkaUZn2z9Edv86BLpqTY8OBQZ19EUwfNehcnvR+Olw+7wxNnatyxo D2FG0paTia1SjxaJ8Nx3e85jy6l7N2AQrTCFCtFN9lp8Pc0LVBpSbjmP+Peh5Mi7gtCBNkpz KShEaJE25a/+rnIrIXzJHrsbC2GwcssAF3bd03iU41J1gMTalB6HCtQUwgqSsbG8MsR/IwHW XruOnVp0GQRJwlw07e9T3PKTLj3LWsAPe0LHm5W1Q+euoCLsZfYwr7phQ19HAxSCu8hzp43u zSw0+sEQsO+9wz2nGDgQCGepCcJR1lygVn2zwRTQKbq7Hjs+IWZ0gN2nDajScuR1RsxTE4WR lj0+Ne6VrAmPiW6QqRhliDO+e82riI75ywSWrJb9TQw0+UkIQ2DlNr0u0TwCUTcQNN6aKnru ouVt3qoRlcD5MuRhLH+ttAcmNITMg7GQ6RQajWrSKuKFrt6iuDbjgO2cnaTrLbNBBKPTG4oF D6kX8Zea0KvVBagBsaC1CDTDQQMxYBPDBSlqYCb/b2x7KHTvTAHUBSsBRL6MKz8wwruDodTM 4E4ToV9URl4aE/msBZ4GLTtEmUHBh4/AYwk6ACYByYKyx5r3PDG0iHnJ8bV0OeyQ9ujfgBBP B2t4oASNnIOeGEEcQ2rjzsFNBFNPCKMBEACm7Xqafb1Dp1nDl06aw/3O9ixWsGMv1Uhfd2B6 it6wh1HDCn9HpekgouR2HLMvdd3Y//GG89irEasjzENZPsK82PS0bvkxxIHRFm0pikF4ljIb 6tca2sxFr/H7CCtWYZjZzPgnOPtnagN0qVVyEM7L5f7KjGb1/o5EDkVR2SVSSjrlmNdTL2Rd zaPqrBoxuR/y/n856deWqS1ZssOpqwKhxT1IVlF6S47CjFJ3+fiHNjkljLfxzDyQXwXCNoZn BKcW9PvAMf6W1DGASoXtsMg4HHzZ5fW+vnjzvWiC4pXrcP7Ivfxx5pB+nGiOfOY+/VSUlW/9 GdzPlOIc1bGyKc6tGREH5lErmeoJZ5k7E9cMJx+xzuDItvnZbf6RuH5fg3QsljQy8jLlr4S6 8YwxlObySJ5K+suPRzZOG2+kq77RJVqAgZXp3Zdvdaov4a5J3H8pxzjj0yZ2JZlndM4X7Msr P5tfxy1WvV4Km6QeFAsjcF5gM+wWl+mf2qrlp3dRwniG1vkLsnQugQ4oNUrx0ahwOSm9p6kM CIiTITo+W7O9KEE9XCb4vV0ejmLlgdDV8ASVUekeTJkmRIBnz0fa4pa1vbtZoi6/LlIdAEEt PY6p3hgkLLtr2GRodOW/Y3vPRd9+rJHq/tLIfwc58ZhQKmRcgrhtlnuTGTmyUqGSiMNfpwAR AQABwsFfBBgBAgAJBQJTTwijAhsMAAoJEAL1yD+ydue64BgP/33QKczgAvSdj9XTC14wZCGE U8ygZwkkyNf021iNMj+o0dpLU48PIhHIMTXlM2aiiZlPWgKVlDRjlYuc9EZqGgbOOuR/pNYA JX9vaqszyE34JzXBL9DBKUuAui8z8GcxRcz49/xtzzP0kH3OQbBIqZWuMRxKEpRptRT0wzBL O31ygf4FRxs68jvPCuZjTGKELIo656/Hmk17cmjoBAJK7JHfqdGkDXk5tneeHCkB411p9WJU vMO2EqsHjobjuFm89hI0pSxlUoiTL0Nuk9Edemjw70W4anGNyaQtBq+qu1RdjUPBvoJec7y/ EXJtoGxq9Y+tmm22xwApSiIOyMwUi9A1iLjQLmngLeUdsHyrEWTbEYHd2sAM2sqKoZRyBDSv ejRvZD6zwkY/9nRqXt02H1quVOP42xlkwOQU6gxm93o/bxd7S5tEA359Sli5gZRaucpNQkwd KLQdCvFdksD270r4jU/rwR2R/Ubi+txfy0dk2wGBjl1xpSf0Lbl/KMR5TQntELfLR4etizLq Xpd2byn96Ivi8C8u9zJruXTueHH8vt7gJ1oax3yKRGU5o2eipCRiKZ0s/T7fvkdq+8beg9ku fDO4SAgJMIl6H5awliCY2zQvLHysS/Wb8QuB09hmhLZ4AifdHyF1J5qeePEhgTA+BaUbiUZf i4aIXCH3Wv6K Organization: ARM Ltd. Message-ID: <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> Date: Thu, 4 Jun 2020 09:59:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, roman@zededa.com, tamas@tklengyel.com, Stefano Stabellini , cminyard@mvista.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 09:48, Julien Grall wrote: Hi, > On 03/06/2020 23:31, Stefano Stabellini wrote: >> Touching the watchdog is required to be able to reboot the board. > > In general the preferred method is PSCI. Does it mean RPI 4 doesn't > support PSCI at all? There is mainline Trusted Firmware (TF-A) support for the RPi4 for a few months now, which includes proper PSCI support (both for SMP bringup and system reset/shutdown). At least that should work, if not, it's a bug. An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF-A without it, with or without U-Boot: It works as a drop-in replacement for armstub.bin. Instruction for building it (one line!) are here: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi4.rst >> >> The implementation is based on >> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > Can you give the baseline? This would allow us to track an issue and > port them. Given the above I don't think it's a good idea to add extra platform specific code to Xen. Cheers, Andre > >> >> Signed-off-by: Stefano Stabellini >> --- >>   xen/arch/arm/platforms/brcm-raspberry-pi.c | 60 ++++++++++++++++++++++ >>   1 file changed, 60 insertions(+) >> >> diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c >> b/xen/arch/arm/platforms/brcm-raspberry-pi.c >> index f5ae58a7d5..0214ae2b3c 100644 >> --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c >> +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c >> @@ -18,6 +18,10 @@ >>    */ >>     #include >> +#include >> +#include >> +#include >> +#include > > We are trying to keep the headers ordered alphabetically within each > directory and then 'xen/' first following by 'asm/'. > >>     static const char *const rpi4_dt_compat[] __initconst = >>   { >> @@ -37,12 +41,68 @@ static const struct dt_device_match >> rpi4_blacklist_dev[] __initconst = >>        * The aux peripheral also shares a page with the aux UART. >>        */ >>       DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"), >> +    /* Special device used for rebooting */ >> +    DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"), >>       { /* sentinel */ }, >>   }; >>   + >> +#define PM_PASSWORD         0x5a000000 >> +#define PM_RSTC             0x1c >> +#define PM_WDOG             0x24 >> +#define PM_RSTC_WRCFG_FULL_RESET    0x00000020 >> +#define PM_RSTC_WRCFG_CLR           0xffffffcf > > NIT: It is a bit odd you introduce the 5 define together but the first 3 > have a different indentation compare to the last 2. > >> + >> +static void __iomem *rpi4_map_watchdog(void) >> +{ >> +    void __iomem *base; >> +    struct dt_device_node *node; >> +    paddr_t start, len; >> +    int ret; >> + >> +    node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm"); >> +    if ( !node ) >> +        return NULL; >> + >> +    ret = dt_device_get_address(node, 0, &start, &len); >> +    if ( ret ) >> +    { >> +        dprintk(XENLOG_ERR, "Cannot read watchdog register address\n"); > > I would suggest to use printk() rather than dprintk. It would be useful > for a normal user to know that we didn't manage to reset the platform > and why. > > >> +        return NULL; >> +    } >> + >> +    base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE); >> +    if ( !base ) >> +    { >> +        dprintk(XENLOG_ERR, "Unable to map watchdog register!\n"); >> +        return NULL; >> +    } >> + >> +    return base; >> +} >> + >> +static void rpi4_reset(void) >> +{ >> +    u32 val; > > We are trying to get rid of any use of u32 in Xen code (the coding style > used in this file). Please use uint32_t instead. > >> +    void __iomem *base = rpi4_map_watchdog(); > > Newline here please. > >> +    if ( !base ) >> +        return; >> + >> +    /* use a timeout of 10 ticks (~150us) */ >> +    writel(10 | PM_PASSWORD, base + PM_WDOG); >> +    val = readl(base + PM_RSTC); >> +    val &= PM_RSTC_WRCFG_CLR; >> +    val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET; >> +    writel(val, base + PM_RSTC); >> + >> +    /* No sleeping, possibly atomic. */ >> +    mdelay(1); >> +} >> + >>   PLATFORM_START(rpi4, "Raspberry Pi 4") >>       .compatible     = rpi4_dt_compat, >>       .blacklist_dev  = rpi4_blacklist_dev, >> +    .reset = rpi4_reset, >>       .dma_bitsize    = 30, >>   PLATFORM_END >>   > > Cheers, > From xen-devel-bounces@lists.xenproject.org Thu Jun 04 09:08:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 09:08:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jglrb-0000Z5-E3; Thu, 04 Jun 2020 09:08:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jglra-0000Yu-Ax for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 09:08:38 +0000 X-Inumbo-ID: f958f74a-a642-11ea-81bc-bc764e2007e4 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:7e1a::61a]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f958f74a-a642-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 09:08:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UkgxyVdMG3hPkxRUYURCQ8qGCtpJOxqrUT6RtKnXsXA=; b=xLsPhkYdNBYj96pIV0hBEyEE/mI6IDSy4oOux6bTg018gAjX2ge2PlnWnat8QEUYeVs2K3X128daywV7WtxsiUr1vYtmCsRLlE7DzVHPB5Ojcu/9LM9aszfH3v216lZB6EPRVa7lXsW4YO7xqc4mjxwiLR3w/M133jvEdk36ywE= Received: from AM0PR04CA0071.eurprd04.prod.outlook.com (2603:10a6:208:1::48) by VI1PR08MB5357.eurprd08.prod.outlook.com (2603:10a6:803:12e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 09:08:34 +0000 Received: from AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:1:cafe::62) by AM0PR04CA0071.outlook.office365.com (2603:10a6:208:1::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Thu, 4 Jun 2020 09:08:33 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT031.mail.protection.outlook.com (10.152.16.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Thu, 4 Jun 2020 09:08:33 +0000 Received: ("Tessian outbound 952576a3272a:v57"); Thu, 04 Jun 2020 09:08:33 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: ef18dfa405aa7f49 X-CR-MTA-TID: 64aa7808 Received: from 19b7b11a8bfc.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D4BE9F9D-3B69-4563-A915-F1B2A599C087.1; Thu, 04 Jun 2020 09:08:27 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 19b7b11a8bfc.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 04 Jun 2020 09:08:27 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iEmtfAlPwn8YkEqBs8ujWDsTDXqMCrJ5JrA1Sb2e3W8liWYVs2V9133qj8s6z2U3tSe/YlvQQb99V1L8y80vsITtF1IYaHRXi22fj9VLyXyywEMGL4SqBdOCkzWkHole2BVOQVOkqGi65M+TpPpWaCqVoqDAprFFebf92WtT41xng2GRvL1nHX7ArVyp4fuWqmx+pa/djgqg6VB14zkaljAsVZohF+v1WAefvSOX1/9kpXMM1NY6gsHufdZPPhDuE0q3IG6h4znR9+oFkFdGr7EzfM6Xtv1rFfhBeCG4fFkQizxt3iXilBVE1UvRh3p8io8tkYmBqJldepOCjXy7Ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UkgxyVdMG3hPkxRUYURCQ8qGCtpJOxqrUT6RtKnXsXA=; b=KZLtmbUqniLHDJU966WUFwLwU09rmuXjF4rbeoHtl00DgK17pPJA76BC7QcO75bgslwieJcV3WwVLnot9aui50KQJ1TnL1WD6vWGB8FqoJyL/ia531+0WOXEri/BaSAMbQr6IiXxjU8aIvRoKkYdWy6QVWGKWSuNJqjqxCs2PK6uusb41rSFIKmPcob9pCB8SeTco6DCM0vqUcTPpD1plAHLyVUe1gUp9gFz2VbnfogogEpP0bm41QNHVgg/vDCe43EUxaspajsbcuY5qRglvmjN2biU4weTu5k0+gr0zLjuZ+d7hl6IB/EWAxVXE77808iPJWRdMn/6DcbRQn6SMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UkgxyVdMG3hPkxRUYURCQ8qGCtpJOxqrUT6RtKnXsXA=; b=xLsPhkYdNBYj96pIV0hBEyEE/mI6IDSy4oOux6bTg018gAjX2ge2PlnWnat8QEUYeVs2K3X128daywV7WtxsiUr1vYtmCsRLlE7DzVHPB5Ojcu/9LM9aszfH3v216lZB6EPRVa7lXsW4YO7xqc4mjxwiLR3w/M133jvEdk36ywE= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3627.eurprd08.prod.outlook.com (2603:10a6:10:49::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Thu, 4 Jun 2020 09:08:26 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3066.019; Thu, 4 Jun 2020 09:08:26 +0000 From: Bertrand Marquis To: Julien Grall Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgA== Date: Thu, 4 Jun 2020 09:08:26 +0000 Message-ID: <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> In-Reply-To: <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 128cf710-ce50-43dc-53ba-08d80866db82 x-ms-traffictypediagnostic: DB7PR08MB3627:|VI1PR08MB5357: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04244E0DC5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: OzxdE0fB5tP4nWhuehPuRzPmJbfknOyURO1gjvDnRqXr/lpJorAfvfOZARCVGxmrriAOlRyXxQzsPGoQL5V/qo3Ik/NVysOQtLb1lAAeMZr4SwU+sGP16OBqcTh0JA4g+w39Tlq8PQzbmHjlGitmPfo7cgaRbI2QyBdH7o+9Le4kityO/tpU7t8mefTGfFF44kJNwpW4tJ5TV6ZNWnlJZgI+BEYAjOGY+IfX5jjykO+EskS5XUregvoN5tQL4EvOTJLB9r/Ama3L9R67eJcsMnUuOoC5hssf+TUAkc3oLn6RLRlmHb3NdohKH61jv1By X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(346002)(136003)(39860400002)(376002)(36756003)(7116003)(3480700007)(26005)(6506007)(478600001)(6512007)(6916009)(4326008)(53546011)(54906003)(86362001)(6486002)(71200400001)(8676002)(316002)(83380400001)(91956017)(2616005)(186003)(76116006)(8936002)(33656002)(66556008)(2906002)(66946007)(66446008)(64756008)(5660300002)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HmVT2DZR8qWV/HMOsWHb65GKSFNJPsU9tbr3IW1IHd24zIGWweFA614+zwZlbVrmYh9WeSWRF1vZXOrXtoaD+fZSukZqniS778GX0x83oAJVxQdzW70BdG1aWPU4d+kF7gbYznLfemnnSJWFCgKdLt5W38NdhUYnN05LCMCkMSl1z0LwWv0j4taelibOjeMriuXbK8rtE4qnqTdkRHtZ5a7YK9HAVkWG34rTTy/+MqUl/LhFbLCoRI+pI53f/2fH3GW/YQOn2dAyc4cgXucNyANhXKrh8pCNkkOFoTpuSOwfW/CI6cIcuCrCJ1F9v/kQT4kuHhrVgq+QqcRS3UQ1EPCx0F64v208zRKYMJbkbWMWQgImi8kFuJ4m25AnyortA31/Ifgi10iPCmWyKJhLnuCgqiZESPp6FalAvk5v/x/Y3cQ6ek5rj9gAQNjzjH3SUSoWxDVf9KmyXTs+Qz2Hzq9ofBrcLYRZTK+k/Y1FeECyONL4CPqVdtJHfLIhdEm4 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3627 Original-Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(396003)(39860400002)(376002)(46966005)(81166007)(83380400001)(6486002)(33656002)(8676002)(336012)(478600001)(82740400003)(2906002)(5660300002)(82310400002)(36756003)(8936002)(356005)(70206006)(2616005)(7116003)(53546011)(3480700007)(47076004)(54906003)(86362001)(36906005)(4326008)(316002)(70586007)(186003)(6862004)(6506007)(6512007)(26005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 5ccd4846-90ab-43e3-425c-08d80866d743 X-Forefront-PRVS: 04244E0DC5 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4p6D+tEIiOwD+aw5m3dWgsRLmpxtxtlMcoZdL9DB6m9dVhEs2YxENx6+6KV8IbDZOm1U4NmfWLbAD8DKrfZ+cOE/85cCbk0oW0VLSlDWFCkA8XUWOH5VnrGxa6AdLzdfqAGjutsaKIqqUwC5D98nrxW0lm+2XtOXh/mIWAjgOPCgZJ0P/sJwJQURH6n3lcrT+j5rS+xwhBwxjOGoV75+PUFabsEnoPyP/fNOEkIiwzL6J2EK43Xo+sKX6CmN/P8qy0hFWoVt5UhrXIuhPT9zxpBnDOVOdj27OQJNdyK+GceoXTb8vemFtz7FmWHwRIzrEduqKCg2If454LbCLjRN9Ure6z6jVkVD9qD3RwbI575CBhyw1E+X5i8wzZFtLINxaF5vdyfERC8ctbkN8KzfjQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2020 09:08:33.4513 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 128cf710-ce50-43dc-53ba-08d80866db82 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5357 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , CodeWiz2280 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gNCBKdW4gMjAyMCwgYXQgMDk6NTksIEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5v cmc+IHdyb3RlOg0KPiANCj4gDQo+IA0KPiBPbiAwNC8wNi8yMDIwIDA5OjAyLCBCZXJ0cmFuZCBN YXJxdWlzIHdyb3RlOg0KPj4gSGksDQo+IA0KPiBIaSBCZXJ0cmFuZCwNCj4gDQo+Pj4gT24gMyBK dW4gMjAyMCwgYXQgMTk6MDksIEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+IHdyb3RlOg0K Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9uIDAzLzA2LzIwMjAgMTg6MTMsIENvZGVXaXoyMjgwIHdy b3RlOg0KPj4+PiBIaSBKdWxpZW4sDQo+Pj4gDQo+Pj4gSGVsbG8sDQo+Pj4gDQo+Pj4gSW4gZ2Vu ZXJhbCwgd2UgYXZvaWQgdG9wIHBvc3Qgb24geGVuLWRldmVsLCBpbnN0ZWFkIHdlIHJlcGx5IGlu bGluZS4gSSBiZWxpZXZlIGdtYWlsIHNob3VsZCBhbGxvdyB5b3UgdG8gZG8gaXQgOikuDQo+Pj4g DQo+Pj4+IFRoZSBvZmZzZXQgaXMgYWxyZWFkeSBhcHBsaWVkIHRvIHRoZSBtZW1vcnkgbm9kZXMg aW4gdGhlIGRldmljZSB0cmVlLCBtZWFuaW5nIGEgZGlyZWN0IExpbnV4IGJvb3QgZnJvbSB1Ym9v dCB3b3VsZCBoYXZlIG9ubHkgdGhlIDM2LWJpdCBhZGRyZXNzZXMgaW4gdGhlIGRldmljZSB0cmVl ICgweDhfMDAwMF8wMDAwIGFuZCAweDhfODAwMF8wMDAwKS4gIExpbnV4IHdvdWxkIHN0YXJ0IGV4 ZWN1dGluZyBmcm9tIGEgMzItYml0IGFkZHJlc3Mgc3BhY2UgaG93ZXZlciBhbmQgdGhlbiBzd2l0 Y2ggb3ZlciB0byB0aGUgYWxpYXNlZCAzNi1iaXQgYWRkcmVzc2VzIGluIHRoZSBkZXZpY2UgdHJl ZSBhcyBkaXNjdXNzZWQgYmVsb3cgYnkgZWFybHlfcGFnaW5nX2luaXQoKS4NCj4+Pj4gSSBoYWQg dG8gYWRkIHRoZSAzMi1iaXQgbWVtb3J5IG5vZGUgMHg4MDAwXzAwMDAgaW4gdWJvb3QgaW4gcGxh Y2Ugb2YgdGhlIDB4OF8wMDAwXzAwMDAgbm9kZSBvdGhlcndpc2UgWGVuIHdvdWxkIGRldGVjdCB0 aGUgMzItYml0IHByb2Nlc3NvciBhbmQgcGFuaWMgb24gIlVuYWJsZSB0byBkZXRlY3QgdGhlIGZp cnN0IG1lbW9yeSBiYW5rIiBpbiBkb21haW5fYnVpbGQuYy4NCj4+PiANCj4+PiBTbyBmb3IgMzIt Yml0IFhlbiByZXF1aXJlcyB0byBoYXZlIHRoZSBmaXJzdCBiYW5rIGJlbG93IDRHQi4gVGhpcyBp cyBiZWNhdXNlIHlvdSBjYW4ndCBib290IGZyb20gYSBwaHlzaWNhbCBhZGRyZXNzIGFib3ZlIDMy LWJpdC4NCj4+PiANCj4+PiBPYnZpb3VzbHksIHRoaXMgY2hlY2sgd291bGRuJ3Qgd29yayBvbiB5 b3VyIHBsYXRmb3JtIGJlY2F1c2UgYWxsIHlvdXIgbWVtb3J5IHdpbGwgYmUgYWJvdmUgNEdCLg0K Pj4gSSB0aGluayB0aGF0IHRoZSBLZXlzdG9uZSBib2FyZCBoYXMgbG93IG1lbW9yeSBhY2Nlc3Np YmxlIGF0IDIgZGlmZmVyZW50IGFkZHJlc3MgKG9uZSBsb3cgYW5kIG9uZSBoaWdoKS4NCj4+IEkg d291bGQgaGVyZSBzdWdnZXN0IHRvIGhhdmUgYSBkdGIgd2l0aCAyIHJlZ2lvbnMgKG9uZSB1bmRl ciA0R0IgYW5kIG9uZSBvdmVyKSBhbmQgcmVtb3ZlIGZyb20gdGhlIHJlZ2lvbiBvdmVyIDRHIHRo ZSBhcmVhIGFscmVhZHkgYWRkcmVzc2VkIGJ5IHRoZSByZWdpb24gdW5kZXIgNEdCLg0KPiANCj4g SSB0aG91Z2h0IGFib3V0IHRoaXMuIEhvd2V2ZXIsIGluIGFuIGVhcmxpZXIgcmVwbHksIERhdmlk IHdyb3RlOg0KPiANCj4gIjQuIFRoZSBkb20wIGtlcm5lbCB3aWxsIGJvb3QgZnJvbSB4ZW4gaWYg dGhlIGVhcmx5X3BhZ2luZ19pbml0IHN3aXRjaCBzdGVwIGlzIHNraXBwZWQsIGFuZCB0aGUgbG93 IG1lbSBzdGF5cyBpbiAzMi1iaXQuLi4uYnV0IHRoZXJlIGlzIGENCj4gcHJvYmxlbSB3aXRoIHRo ZSBwZXJpcGhlcmFscyBzbyB0aGlzIGlzIG5vdCBhbiBhY2NlcHRhYmxlIHNvbHV0aW9uLiINCj4g DQo+IEl0IGlzIG5vdCBjbGVhciB0byBtZSB3aGF0IHNvcnQgb2YgaXNzdWVzIHdpbGwgYXJpc2Ug d2l0aCB0aGUgcGVyaXBoZXJhbHMuIEJ1dCBJIGhhdmUgYXNzdW1lZCB0aGF0IGl0IHdvdWxkbid0 IGJlIHBvc3NpYmxlIGZvciBEb20wIHRvIGtlZXAgdXNpbmcgdGhlIG1lbW9yeSBiZWxvdyA0R0Iu DQoNCkkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgbGludXggd291bGQgaGF2ZSBuZWVkIHNvbWUg bWVtb3J5LCBldmVuIHNtYWxsIGluIHRoZSAzMmJpdCBzcGFjZSBpbiBvcmRlciB0byBib290Lg0K SSBjb3VsZCB1bmRlcnN0YW5kIHRoYXQgc29tZSBtZW1vcnkgaW4gdGhlIGxvdyBhZGRyZXNzIHNw YWNlIG5lZWRzIHRvIGJlIHJlc2VydmVkIGJ5IExpbnV4IGFzIERNQSBhcmVhIGZvciBwZXJpcGhl cmFscyBub3Qgc3VwcG9ydGluZyAzNi1iaXQgYWRkcmVzc2VzLCBidXQgdGhlIHdob2xlIGxvdyBt ZW1vcnkgc291bmRzIGxpa2UgYSBiaWcgcmVzdHJpY3Rpb24uDQoNCldvdWxkIGl0IGJlIHBvc3Np YmxlIHRvIGhhdmUgYSBiaXQgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGUg4oCccHJvYmxlbSB3aXRo IHBlcmlwaGVyYWxz4oCdIGhlcmUgPw0KDQpDaGVlcnMNCkJlcnRyYW5kDQoNCg== From xen-devel-bounces@lists.xenproject.org Thu Jun 04 09:58:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 09:58:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgmcy-00050p-CB; Thu, 04 Jun 2020 09:57:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgmcx-00050k-K6 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 09:57:35 +0000 X-Inumbo-ID: cd368784-a649-11ea-ae4f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cd368784-a649-11ea-ae4f-12813bfff9fa; Thu, 04 Jun 2020 09:57:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ors9XBe/l/rZknNeOLY+nfrcH68s8OcY06gQKoXMBfQ=; b=V8uBnkV1nMxA3PVvj90HbGzkl SncC2247lujC+w6HPUc5agOp4DEqdRvbUZ59N9e+HKaD6IOPzd0alBoYwlD7HBotUW+x24vqstInK otxERf8Xza0olDv6Qn51z9lYYDlLsj0QurEqGlc3KdpoJQq5KDdLZAI7In6baTEVe2jFY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgmcr-0000vy-8I; Thu, 04 Jun 2020 09:57:29 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgmcq-0002Lh-Tv; Thu, 04 Jun 2020 09:57:29 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgmcq-0008Mk-Sa; Thu, 04 Jun 2020 09:57:28 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150682: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d9f58cd54fe2f05e1f05e2fe254684bd1840de8e X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Thu, 04 Jun 2020 09:57:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150682 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150682/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d9f58cd54fe2f05e1f05e2fe254684bd1840de8e baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 6 days Failing since 150465 2020-05-29 09:02:14 Z 6 days 44 attempts Testing same since 150649 2020-06-03 13:01:44 Z 0 days 6 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1522 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 04 10:12:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 10:12:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgmqs-0006qS-NR; Thu, 04 Jun 2020 10:11:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgmqr-0006qN-0D for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 10:11:57 +0000 X-Inumbo-ID: d18b419c-a64b-11ea-ae57-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d18b419c-a64b-11ea-ae57-12813bfff9fa; Thu, 04 Jun 2020 10:11:56 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: JW+8Ma8rK3J/RLJ/tobmpVsemQwnCPOWbgFx6kLfufZt5muS+5Z9R4iCkdKkQREccG2xdpxHm7 T8EgDVCNf8cctxeGgHJ3wX3bkNjMcONxyHoUJgAFwsUWn1UiNgK4qLDIq+cbvrPp8tb4U+CNBm x7OuvGOoA4ZpfyYw+uk8mVUtqjTi8+JLKHVWPJZXygZ5D0+cl3skK8PSW3OiD6JyFBdUSnAhDH htv070kDndjSrxnp3RML6LgjVJP52v+9ORn6JuJWGsW4nIMxxXlMiqMwesQl8s/H+CNssG5Glt Jw8= X-SBRS: 2.7 X-MesageID: 19557215 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="19557215" Subject: Re: [PATCH for-4.14] x86/shim: Fix defconfig selection and trim the build further To: Jan Beulich References: <20200603170908.13239-1-andrew.cooper3@citrix.com> <1a158ff8-e11e-432c-236d-ff884602d48a@suse.com> From: Andrew Cooper Message-ID: Date: Thu, 4 Jun 2020 11:11:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1a158ff8-e11e-432c-236d-ff884602d48a@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , Paul Durrant , Dario Faggioli , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 07:43, Jan Beulich wrote: > On 03.06.2020 19:09, Andrew Cooper wrote: >> Several options (TBOOT, XENOPROF, Scheduler) depend on EXPERT to be able to >> deselect/configure. >> >> Enabling EXPERT now causes the request of the Credit1 scheduler to be honoured >> (rather than giving us Credit2), but take this opportunity to switch to Null, >> as the previously problematic issues are now believed to be fixed. >> >> Enabling EXPERT also allows XEN_SHSTK to be selected, and we don't want this >> being built for shim. We also don't want TRACEBUFFER or GDBSX either. >> >> Take this oppotunity to swap the disable of HVM_FEP for a general disable of >> HVM (likely to have wider impliciations in the future), and disable ARGO (will >> necesserily need plumbing work to function in shim). > Odd. I was quite sure this is the case already; in particular my > own build test of a shim config has this already. It is currently off because of its default in Xen, but even if that were to change, its not usable in shim without further development work. > >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Thanks. > > I have a question though (without implying the patch here needs > adjusting, but rather with a look towards after 4.14): > >> --- a/xen/arch/x86/configs/pvshim_defconfig >> +++ b/xen/arch/x86/configs/pvshim_defconfig >> @@ -5,19 +5,25 @@ CONFIG_PVH_GUEST=y >> CONFIG_PV_SHIM=y >> CONFIG_PV_SHIM_EXCLUSIVE=y >> CONFIG_NR_CPUS=32 >> +CONFIG_EXPERT=y >> +CONFIG_SCHED_NULL=y >> # Disable features not used by the PV shim >> +# CONFIG_HVM is not set >> +# CONFIG_XEN_SHSTK is not set >> # CONFIG_HYPFS is not set >> # CONFIG_SHADOW_PAGING is not set >> # CONFIG_BIGMEM is not set >> -# CONFIG_HVM_FEP is not set >> # CONFIG_TBOOT is not set >> # CONFIG_KEXEC is not set >> # CONFIG_XENOPROF is not set >> # CONFIG_XSM is not set >> +# CONFIG_ARGO is not set >> +# CONFIG_SCHED_CREDIT is not set >> # CONFIG_SCHED_CREDIT2 is not set >> # CONFIG_SCHED_RTDS is not set >> # CONFIG_SCHED_ARINC653 is not set >> -# CONFIG_SCHED_NULL is not set >> # CONFIG_LIVEPATCH is not set >> # CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set >> +# CONFIG_TRACEBUFFER is not set >> # CONFIG_DEBUG is not set >> +# CONFIG_GDBSX is not set > I assume both the "enable" and "disable" sections here are ordered > like they would be in a resulting full .config. They are, yes. > But this being two > separate sections, doing so doesn't help e.g. diff-ing. Having them in order helps massively with scanning through the two files together. I'm not entirely certain why the two sections are separate to begin with.  Merging them would probably make things even easier, but I think the file does want to stay in .config order. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 04 10:16:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 10:16:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgmuw-00070y-96; Thu, 04 Jun 2020 10:16:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgmuu-00070F-J2 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 10:16:08 +0000 X-Inumbo-ID: 64cc8e3e-a64c-11ea-ae57-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 64cc8e3e-a64c-11ea-ae57-12813bfff9fa; Thu, 04 Jun 2020 10:16:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=abCn9t+cnQcKoWG+FfX/UQ1+boT+CWGrlGLJFkWts7M=; b=AJtxA9bHCg8v0/Mn9yxG5MZ01w mw63MIec+49lCuQEwkajuX4BgHPv/pq43YKyayhUxkQiMIFcwdM+KpfXAD71c5bt8XrTQM17h1n3l UTFlylz8P6hUBEBMgyKsvD0DOovyMbjmA1zbHeRfds9rO+1fRChArFXG/DcEAypwViPY=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgmuo-0001PY-Fn; Thu, 04 Jun 2020 10:16:02 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgmuo-0006AN-8H; Thu, 04 Jun 2020 10:16:02 +0000 Subject: Re: Keystone Issue To: Bertrand Marquis References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> From: Julien Grall Message-ID: Date: Thu, 4 Jun 2020 11:15:59 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , CodeWiz2280 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 04/06/2020 10:08, Bertrand Marquis wrote: > I would have thought that linux would have need some memory, even small in the 32bit space in order to boot. Yes it needs some, but then they are switching to use the high memory alias after the MMU has been switch on. From my understanding, the only difference is the page-tables will point to the high memory alias address rather than the low memory one. Linux will still be located at the same place but now accessed from the high memory alias rather than the low one. Note that AFAICT the secondary CPUs will still be brought-up using the low memory alias. > I could understand that some memory in the low address space needs to be reserved by Linux as DMA area for peripherals not supporting 36-bit addresses, but the whole low memory sounds like a big restriction. Many platforms have devices only supporting 32-bit DMA, but none of them require such aliasing. So this doesn't look to be the issue here. TBH, this code is only used by Keystone and switching address space is expensive (you have to turn off the MMU, updates page-tables, flush the cache...). I find hard to believe a developper would have come up with this complexity if it were possible to always use the low memory address range. It is even harder to believe Linux community would have accepted it. > > Would it be possible to have a bit more information on the “problem with peripherals” here ? I am curious as well, so I looked in more depth :). Going through the Linux history, one of the commit message [1] suggests they are switching to a coherent address space. The datasheet [2] (page 75) also confirm that the low region is not IO coherent. So I think you would not be able to do DMA without flush the cache which can be pretty expensive. For a PoC, it might be possible to force Linux flushing the area before and after each DMA request. This should be possible by marking the devices as not coherent. Although, I am not entirely sure if there is any fallout. @Dave, do you think it is possible for you to have a try? I can provide the patch for Linux to disable DMA coherency if possible. For a proper solution, I think we need to implement something similar to what I wrote earlier. Cheers, [1] 5eb3da7246a5b2dfac9f38a7be62b1a0295584c7 [2] https://www.ti.com/lit/ds/symlink/tci6638k2k.pdf?ts=1591183242813 -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 10:22:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 10:22:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgn0v-0007vp-2W; Thu, 04 Jun 2020 10:22:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgn0t-0007vk-J1 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 10:22:19 +0000 X-Inumbo-ID: 44a9d7dc-a64d-11ea-9947-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 44a9d7dc-a64d-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 10:22:18 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AB93BB157; Thu, 4 Jun 2020 10:22:20 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: Jan Beulich Subject: [PATCH] build: fix dependency tracking for preprocessed files Message-ID: Date: Thu, 4 Jun 2020 12:22:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , Andrew Cooper , Ian Jackson , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" While the issue is more general, I noticed that asm-macros.i not getting re-generated as needed. This was due to its .*.d file mentioning asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds dependency tracking files. While there, further avoid open-coding $(CPP) and drop the bogus -Ui386. Signed-off-by: Jan Beulich --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -201,13 +201,13 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) $(call if_changed,obj_init_o) quiet_cmd_cpp_i_c = CPP $@ -cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ +cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ -MQ $@ quiet_cmd_cc_s_c = CC $@ cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@ quiet_cmd_s_S = CPP $@ -cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@ +cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@ -MQ $@ %.i: %.c FORCE $(call if_changed,cpp_i_c) --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -123,9 +123,7 @@ asm-offsets.s: $(TARGET_SUBARCH)/asm-off $(CC) $(filter-out -flto,$(c_flags)) -S -o $@ $< xen.lds: xen.lds.S - $(CC) -P -E -Ui386 $(a_flags) -o $@ $< - sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new - mv -f .xen.lds.d.new .xen.lds.d + $(CPP) -P $(a_flags) -o $@ -MQ $@ $< dtb.o: $(CONFIG_DTB_FILE) --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -244,9 +244,7 @@ $(BASEDIR)/include/asm-x86/asm-macros.h: efi.lds: AFLAGS-y += -DEFI xen.lds efi.lds: xen.lds.S - $(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $< - sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new - mv -f .$(@F).d.new .$(@F).d + $(CPP) -P $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ -MQ $@ $< boot/mkelf32: boot/mkelf32.c $(HOSTCC) $(HOSTCFLAGS) -o $@ $< From xen-devel-bounces@lists.xenproject.org Thu Jun 04 10:22:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 10:22:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgn14-0007wX-Br; Thu, 04 Jun 2020 10:22:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgn12-0007wE-QG for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 10:22:28 +0000 X-Inumbo-ID: 499b0590-a64d-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 499b0590-a64d-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 10:22:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DxLH4QoqVxRkhb/OQhVpTEbheGWTLzOWUKw++pDpK3E=; b=bDQV+S4bqdk9WxXJtxRkq97Vh oKH9z0tckU8KEkoQp6n9L9DINHig3GJb0bzUtqvWAB1vOiI0XPkSu15yusYxMxPiVYpQ9Mbvrsb7G Ywio20nwCYRJx26G8/7GBW3UPt+N9wk6+7tic8t8lDqxdFdd3ZhOilN9tvgtNPJqfWDG0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgn10-0001YW-2G; Thu, 04 Jun 2020 10:22:26 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgn0z-0002v6-GV; Thu, 04 Jun 2020 10:22:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgn0z-00024O-Fy; Thu, 04 Jun 2020 10:22:25 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150680: regressions - trouble: blocked/broken/fail/pass X-Osstest-Failures: linux-linus:build-armhf::broken:regression linux-linus:build-armhf:hosts-allocate:broken:regression linux-linus:build-amd64-libvirt:libvirt-build:fail:regression linux-linus:build-i386-xsm:xen-build:fail:regression linux-linus:build-arm64-libvirt:libvirt-build:fail:regression linux-linus:build-amd64-pvops:kernel-build:fail:regression linux-linus:build-armhf-pvops:kernel-build:fail:regression linux-linus:build-i386-pvops:kernel-build:fail:regression linux-linus:build-arm64-pvops:kernel-build:fail:regression linux-linus:build-i386:xen-build:fail:regression linux-linus:test-amd64-amd64-libvirt-xsm:build-check(1):running:regression linux-linus:test-armhf-armhf-xl-credit1:build-check(1):running:regression linux-linus:test-armhf-armhf-xl-rtds:build-check(1):running:regression linux-linus:test-armhf-armhf-xl-arndale:build-check(1):running:regression linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):running:regression linux-linus:test-amd64-amd64-libvirt-vhd:build-check(1):running:regression linux-linus:test-armhf-armhf-xl-credit2:build-check(1):running:regression linux-linus:test-armhf-armhf-examine:build-check(1):running:regression linux-linus:test-armhf-armhf-xl-multivcpu:build-check(1):running:regression linux-linus:test-arm64-arm64-xl-thunderx:build-check(1):running:regression linux-linus:test-arm64-arm64-xl-credit2:build-check(1):running:regression linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):running:regression linux-linus:test-armhf-armhf-xl-vhd:build-check(1):running:regression linux-linus:build-armhf-libvirt:build-check(1):running:regression linux-linus:test-amd64-amd64-libvirt:build-check(1):running:regression linux-linus:test-arm64-arm64-xl:build-check(1):running:regression linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):running:regression linux-linus:test-arm64-arm64-xl-credit1:build-check(1):running:regression linux-linus:test-armhf-armhf-libvirt:build-check(1):running:regression linux-linus:test-armhf-armhf-libvirt-raw:build-check(1):running:regression linux-linus:test-amd64-amd64-libvirt-pair:build-check(1):running:regression linux-linus:test-arm64-arm64-xl-xsm:build-check(1):running:regression linux-linus:test-armhf-armhf-xl:build-check(1):running:regression linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):running:regression linux-linus:test-armhf-armhf-xl-cubietruck:build-check(1):running:regression linux-linus:test-arm64-arm64-examine:build-check(1):running:regression linux-linus:test-amd64-i386-xl-xsm:build-check(1):running:regression linux-linus:test-arm64-arm64-libvirt-xsm:build-check(1):running:regression linux-linus:test-arm64-arm64-xl-seattle:build-check(1):running:regression linux-linus:build-amd64-libvirt:syslog-server:running:regression linux-linus:build-i386-xsm:syslog-server:running:regression linux-linus:build-arm64-libvirt:syslog-server:running:regression linux-linus:build-armhf-pvops:syslog-server:running:regression linux-linus:build-i386-pvops:syslog-server:running:regression linux-linus:build-arm64-pvops:syslog-server:running:regression linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking linux-linus:test-amd64-coresched-amd64-xl:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-examine:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-pvshim:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking linux-linus:test-amd64-coresched-i386-xl:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-examine:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-pvhv2-intel:build-check(1):blocked:nonblocking linux-linus:build-i386-libvirt:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-pvhv2-amd:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-pair:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-pair:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking linux-linus:build-armhf:capture-logs:broken:nonblocking linux-linus:build-i386-xsm:capture-logs:broken:nonblocking linux-linus:build-arm64-libvirt:capture-logs:broken:nonblocking linux-linus:build-amd64-libvirt:capture-logs:broken:nonblocking linux-linus:build-i386-pvops:capture-logs:broken:nonblocking linux-linus:build-arm64-pvops:capture-logs:broken:nonblocking linux-linus:build-armhf-pvops:capture-logs:broken:nonblocking X-Osstest-Versions-This: linux=6929f71e46bdddbf1c4d67c2728648176c67c555 X-Osstest-Versions-That: linux=f6aee505c71bbb035dde146caf5a6abbf3ccbe47 From: osstest service owner Date: Thu, 04 Jun 2020 10:22:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150680 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150680/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf 2 hosts-allocate broken REGR. vs. 150663 build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150663 build-i386-xsm 6 xen-build fail REGR. vs. 150663 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150663 build-amd64-pvops 6 kernel-build fail REGR. vs. 150663 build-armhf-pvops 6 kernel-build fail REGR. vs. 150663 build-i386-pvops 6 kernel-build fail REGR. vs. 150663 build-arm64-pvops 6 kernel-build fail REGR. vs. 150663 build-i386 6 xen-build fail REGR. vs. 150663 test-amd64-amd64-libvirt-xsm 1 build-check(1) running test-armhf-armhf-xl-credit1 1 build-check(1) running test-armhf-armhf-xl-rtds 1 build-check(1) running test-armhf-armhf-xl-arndale 1 build-check(1) running test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) running test-amd64-amd64-libvirt-vhd 1 build-check(1) running test-armhf-armhf-xl-credit2 1 build-check(1) running test-armhf-armhf-examine 1 build-check(1) running test-armhf-armhf-xl-multivcpu 1 build-check(1) running test-arm64-arm64-xl-thunderx 1 build-check(1) running test-arm64-arm64-xl-credit2 1 build-check(1) running test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) running test-armhf-armhf-xl-vhd 1 build-check(1) running build-armhf-libvirt 1 build-check(1) running test-amd64-amd64-libvirt 1 build-check(1) running test-arm64-arm64-xl 1 build-check(1) running test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) running test-arm64-arm64-xl-credit1 1 build-check(1) running test-armhf-armhf-libvirt 1 build-check(1) running test-armhf-armhf-libvirt-raw 1 build-check(1) running test-amd64-amd64-libvirt-pair 1 build-check(1) running test-arm64-arm64-xl-xsm 1 build-check(1) running test-armhf-armhf-xl 1 build-check(1) running test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) running test-armhf-armhf-xl-cubietruck 1 build-check(1) running test-arm64-arm64-examine 1 build-check(1) running test-amd64-i386-xl-xsm 1 build-check(1) running test-arm64-arm64-libvirt-xsm 1 build-check(1) running test-arm64-arm64-xl-seattle 1 build-check(1) running build-amd64-libvirt 3 syslog-server running build-i386-xsm 3 syslog-server running build-arm64-libvirt 3 syslog-server running build-armhf-pvops 3 syslog-server running build-i386-pvops 3 syslog-server running build-arm64-pvops 3 syslog-server running Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a build-armhf 3 capture-logs broken blocked in 150663 build-i386-xsm 7 capture-logs broken blocked in 150663 build-arm64-libvirt 7 capture-logs broken blocked in 150663 build-amd64-libvirt 7 capture-logs broken blocked in 150663 build-i386-pvops 7 capture-logs broken blocked in 150663 build-arm64-pvops 7 capture-logs broken blocked in 150663 build-armhf-pvops 7 capture-logs broken blocked in 150663 version targeted for testing: linux 6929f71e46bdddbf1c4d67c2728648176c67c555 baseline version: linux f6aee505c71bbb035dde146caf5a6abbf3ccbe47 Last test of basis 150663 2020-06-03 18:38:46 Z 0 days Testing same since 150680 2020-06-04 06:12:40 Z 0 days 1 attempts ------------------------------------------------------------ 690 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm fail build-amd64 pass build-arm64 pass build-armhf broken build-i386 fail build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-pvops fail build-arm64-pvops fail build-armhf-pvops fail build-i386-pvops fail test-amd64-amd64-xl blocked test-amd64-coresched-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-coresched-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-amd64-examine blocked test-arm64-arm64-examine blocked test-armhf-armhf-examine blocked test-amd64-i386-examine blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-xl-pvshim blocked test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job build-armhf broken broken-step build-armhf capture-logs broken-step build-armhf hosts-allocate broken-step build-i386-xsm capture-logs broken-step build-arm64-libvirt capture-logs broken-step build-amd64-libvirt capture-logs broken-step build-i386-pvops capture-logs broken-step build-arm64-pvops capture-logs broken-step build-armhf-pvops capture-logs Not pushing. (No revision log; it would be 79962 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 04 10:34:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 10:34:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnCC-0000bu-KR; Thu, 04 Jun 2020 10:34:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnCB-0000bm-BK for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 10:33:59 +0000 X-Inumbo-ID: e5b40e6c-a64e-11ea-ae5d-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e5b40e6c-a64e-11ea-ae5d-12813bfff9fa; Thu, 04 Jun 2020 10:33:58 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 90A30ABCF; Thu, 4 Jun 2020 10:34:00 +0000 (UTC) Subject: Re: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately To: paul@xen.org References: <1591224108-564-1-git-send-email-igor.druzhinin@citrix.com> <006401d63a44$a27349e0$e759dda0$@xen.org> From: Jan Beulich Message-ID: <4d1da8eb-a06e-c97a-09a0-e84070dc5ec8@suse.com> Date: Thu, 4 Jun 2020 12:33:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <006401d63a44$a27349e0$e759dda0$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Igor Druzhinin' , wl@xen.org, andrew.cooper3@citrix.com, george.dunlap@citrix.com, xen-devel@lists.xenproject.org, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.2020 09:49, Paul Durrant wrote: >> -----Original Message----- >> From: Igor Druzhinin >> Sent: 03 June 2020 23:42 >> To: xen-devel@lists.xenproject.org >> Cc: jbeulich@suse.com; andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; >> george.dunlap@citrix.com; paul@xen.org; Igor Druzhinin >> Subject: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately >> >> A recalculation NPT fault doesn't always require additional handling >> in hvm_hap_nested_page_fault(), moreover in general case if there is no >> explicit handling done there - the fault is wrongly considered fatal. >> >> This covers a specific case of migration with vGPU assigned which >> uses direct MMIO mappings made by XEN_DOMCTL_memory_mapping hypercall: >> at a moment log-dirty is enabled globally, recalculation is requested >> for the whole guest memory including those mapped MMIO regions > > I still think it is odd to put this in the commit comment since, as I > said before, Xen ensures that this situation cannot happen at > the moment. Aiui Igor had replaced reference to passed-through devices by reference to mere handing of an MMIO range to a guest. Are you saying we suppress log-dirty enabling in this case as well? I didn't think we do: if ( has_arch_pdevs(d) && log_global ) { /* * Refuse to turn on global log-dirty mode * if the domain is sharing the P2M with the IOMMU. */ return -EINVAL; } Seeing this code I wonder about the non-sharing case: If what the comment says was true, the condition would need to change, but I think it's the comment which is wrong, and we don't want global log-dirty as long as an IOMMU is in use at all for a domain. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 04 10:50:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 10:50:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnSQ-0002Ow-5H; Thu, 04 Jun 2020 10:50:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnSO-0002Or-OF for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 10:50:44 +0000 X-Inumbo-ID: 3d0a2df2-a651-11ea-81bc-bc764e2007e4 Received: from mail-wr1-x431.google.com (unknown [2a00:1450:4864:20::431]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3d0a2df2-a651-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 10:50:43 +0000 (UTC) Received: by mail-wr1-x431.google.com with SMTP id j10so5547653wrw.8 for ; Thu, 04 Jun 2020 03:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=nUFyO32duoOSfs+J/3Tj+DbYbB4ZRTeXA2objZH1viU=; b=KTty5MTz6rh24hiJjjvJpDqqqamqP00bb75wpNNsCRCfzgxMwgUJ7cpDCEXQYEOmKx mGXxY0+rhe0FbxIm1L0/YDS2DlOwVjptqARdnUwdy+EU63UsGO3meFwcK1+BQygg5vZf VI1mWZzCPeKx0F00OfegMeAEB0KmeilCeTwvGsXsC8dvzV1xBJv23MTzcJ3kNF8u/s4G 7aQBqscvgTTPiX/OiS//Hfok2AfDIZKFLZ8q7fV4muvAJQwh/mJdAx0nW4zg+CDHjpKQ TeQOVxqUjsfWwb9WPLkXPrgFKhR6cSHv83ZBngFyz6W2uHQtLSZA9Ib72rPgiOauxeiy haew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :thread-index:content-language; bh=nUFyO32duoOSfs+J/3Tj+DbYbB4ZRTeXA2objZH1viU=; b=eE+9C61pzENVryzuJ+FOtapDAqDY01yUzuygoqrySHY8QYqm4h3y/2mZgCloEeOA2t wFmfDKRSy4bUao/0QNv/lQL88nTGpZbKuoH0S3QIkuiHMJHPbrLI3SWFHnubYSrMaL9G Z9QMaVi8LcbRA22cJhhS0zjnBVIEfbjNMW2VvXKz8NbB2j1UgFf52IDve95djleXg3SM 2wvmmpx/l/1ouBFKv9AUyOc8z7suwYx0fzguUfuTDFB3fUhQYca/5AHYLqI8fo+i2+gs mKoHv6wzhhwP7N6MTbXA+2Vsbpz4rCXxYdmlIvI+aF+6LSPg57ntrhPev1NxpXtui2gc ebdQ== X-Gm-Message-State: AOAM5316A5xUneUDeE8z0444Fb8G/RoHXvRKps2dn+Mr4ifhGBQZ5Kjn 84T061K29ZNjonAArqs9/wc= X-Google-Smtp-Source: ABdhPJy5dPNM2tGSqf+FwA/Rxze+LaLDvtwAbx5siXV5WGg8ViuwjroM0J0giqPhKaVHi81yrxp5WA== X-Received: by 2002:adf:a1c1:: with SMTP id v1mr3941049wrv.205.1591267843180; Thu, 04 Jun 2020 03:50:43 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id d16sm6822665wmd.42.2020.06.04.03.50.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 03:50:42 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <1591224108-564-1-git-send-email-igor.druzhinin@citrix.com> <006401d63a44$a27349e0$e759dda0$@xen.org> <4d1da8eb-a06e-c97a-09a0-e84070dc5ec8@suse.com> In-Reply-To: <4d1da8eb-a06e-c97a-09a0-e84070dc5ec8@suse.com> Subject: RE: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately Date: Thu, 4 Jun 2020 11:50:40 +0100 Message-ID: <000f01d63a5d$fe3787f0$faa697d0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKnLWBT9mNjQEOL+u7d2oiXq95SHgJRYkBUAnFt9OGnAEkYcA== Content-Language: en-gb X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Igor Druzhinin' , wl@xen.org, andrew.cooper3@citrix.com, george.dunlap@citrix.com, xen-devel@lists.xenproject.org, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 04 June 2020 11:34 > To: paul@xen.org > Cc: 'Igor Druzhinin' ; = xen-devel@lists.xenproject.org; > andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; = george.dunlap@citrix.com > Subject: Re: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc = NPT faults immediately >=20 > On 04.06.2020 09:49, Paul Durrant wrote: > >> -----Original Message----- > >> From: Igor Druzhinin > >> Sent: 03 June 2020 23:42 > >> To: xen-devel@lists.xenproject.org > >> Cc: jbeulich@suse.com; andrew.cooper3@citrix.com; wl@xen.org; = roger.pau@citrix.com; > >> george.dunlap@citrix.com; paul@xen.org; Igor Druzhinin = > >> Subject: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc = NPT faults immediately > >> > >> A recalculation NPT fault doesn't always require additional = handling > >> in hvm_hap_nested_page_fault(), moreover in general case if there = is no > >> explicit handling done there - the fault is wrongly considered = fatal. > >> > >> This covers a specific case of migration with vGPU assigned which > >> uses direct MMIO mappings made by XEN_DOMCTL_memory_mapping = hypercall: > >> at a moment log-dirty is enabled globally, recalculation is = requested > >> for the whole guest memory including those mapped MMIO regions > > > > I still think it is odd to put this in the commit comment since, as = I > > said before, Xen ensures that this situation cannot happen at > > the moment. >=20 > Aiui Igor had replaced reference to passed-through devices by = reference > to mere handing of an MMIO range to a guest. Are you saying we = suppress > log-dirty enabling in this case as well? I didn't think we do: No, but the comment says "migration with vGPU *assigned*" (my emphasis), = which surely means has_arch_pdevs() will be true. >=20 > if ( has_arch_pdevs(d) && log_global ) > { > /* > * Refuse to turn on global log-dirty mode > * if the domain is sharing the P2M with the IOMMU. > */ > return -EINVAL; > } >=20 > Seeing this code I wonder about the non-sharing case: If what the > comment says was true, the condition would need to change, but I > think it's the comment which is wrong, and we don't want global > log-dirty as long as an IOMMU is in use at all for a domain. I think is the comment that is correct, not the condition. It is only = when using shared EPT that enabling logdirty is clearly an unsafe thing = to do. Using sync-ed IOMMU mappings should be ok. Paul From xen-devel-bounces@lists.xenproject.org Thu Jun 04 10:54:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 10:54:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnWJ-0002ZD-Mu; Thu, 04 Jun 2020 10:54:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnWI-0002Z8-Nc for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 10:54:46 +0000 X-Inumbo-ID: cc9a3480-a651-11ea-ae63-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cc9a3480-a651-11ea-ae63-12813bfff9fa; Thu, 04 Jun 2020 10:54:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xvc3tk3MgveuCCv+xgkUU20Otl5YBfB8LGN8wrnHOX4=; b=fs8MqAxNW0wwFTtBzgefiezDS LvXMlbSsiC2A2yWAsxYVC7enjm868HyF1w2oP4LDpxqQV7aNDT1pK9FIw92vDcL0Q1VzrwsvvcIMM PTMvIKeTPEziv2/jnYJRZfOk2oOMPubvi7mHGl7gm3DeQ9PotSGED6ONZF2PRHGXQWOOU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnWG-0002C9-6d; Thu, 04 Jun 2020 10:54:44 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgnWF-0003lR-UT; Thu, 04 Jun 2020 10:54:43 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgnWF-0001Uc-Tv; Thu, 04 Jun 2020 10:54:43 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150687: all pass - PUSHED X-Osstest-Versions-This: ovmf=bb78cfbec07eda45118b630a09b0af549b43a135 X-Osstest-Versions-That: ovmf=68d720fd92bbdbbfae5adee02d6d9fd24ca38f30 From: osstest service owner Date: Thu, 04 Jun 2020 10:54:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150687 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150687/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf bb78cfbec07eda45118b630a09b0af549b43a135 baseline version: ovmf 68d720fd92bbdbbfae5adee02d6d9fd24ca38f30 Last test of basis 150668 2020-06-03 21:39:18 Z 0 days Testing same since 150687 2020-06-04 09:14:34 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Derek Lin Nickle Wang Ray Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 68d720fd92..bb78cfbec0 bb78cfbec07eda45118b630a09b0af549b43a135 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Thu Jun 04 10:59:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 10:59:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnaz-0002jr-AS; Thu, 04 Jun 2020 10:59:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnay-0002jm-3h for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 10:59:36 +0000 X-Inumbo-ID: 794d7688-a652-11ea-81bc-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 794d7688-a652-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 10:59:34 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: XVxB87/Z9g5o5YKbU2OBpRABk1sML0trbpWTiJ0zUHsznL9Ul24n3cKKc0zfuvprxY67muag5Y rJCOnGelI58TqsyAyn3HtL9r06Cxf4y0tZsiepM8xymJkhbeOTkYnCdueP24ZWPtCMYwxYj0x2 k4p76QZ1y6a63AQEQ/WVWxaJZH2apWQfbqeasWfw7DV/abLRbEtnPwNKXKYvWv+1q5nCgGEGQr UmqhgAXukFApC1qH0U1bvfNK4gE0VFpPQO22vphqQcfC/eINoigF8Si6oqnm3XXJFNAiDvZZbT 1r0= X-SBRS: 2.7 X-MesageID: 19502629 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="19502629" Subject: Re: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately To: , 'Jan Beulich' References: <1591224108-564-1-git-send-email-igor.druzhinin@citrix.com> <006401d63a44$a27349e0$e759dda0$@xen.org> <4d1da8eb-a06e-c97a-09a0-e84070dc5ec8@suse.com> <000f01d63a5d$fe3787f0$faa697d0$@xen.org> From: Igor Druzhinin Message-ID: Date: Thu, 4 Jun 2020 11:59:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <000f01d63a5d$fe3787f0$faa697d0$@xen.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com, george.dunlap@citrix.com, wl@xen.org, andrew.cooper3@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 11:50, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 04 June 2020 11:34 >> To: paul@xen.org >> Cc: 'Igor Druzhinin' ; xen-devel@lists.xenproject.org; >> andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; george.dunlap@citrix.com >> Subject: Re: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately >> >> On 04.06.2020 09:49, Paul Durrant wrote: >>>> -----Original Message----- >>>> From: Igor Druzhinin >>>> Sent: 03 June 2020 23:42 >>>> To: xen-devel@lists.xenproject.org >>>> Cc: jbeulich@suse.com; andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; >>>> george.dunlap@citrix.com; paul@xen.org; Igor Druzhinin >>>> Subject: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately >>>> >>>> A recalculation NPT fault doesn't always require additional handling >>>> in hvm_hap_nested_page_fault(), moreover in general case if there is no >>>> explicit handling done there - the fault is wrongly considered fatal. >>>> >>>> This covers a specific case of migration with vGPU assigned which >>>> uses direct MMIO mappings made by XEN_DOMCTL_memory_mapping hypercall: >>>> at a moment log-dirty is enabled globally, recalculation is requested >>>> for the whole guest memory including those mapped MMIO regions >>> >>> I still think it is odd to put this in the commit comment since, as I >>> said before, Xen ensures that this situation cannot happen at >>> the moment. >> >> Aiui Igor had replaced reference to passed-through devices by reference >> to mere handing of an MMIO range to a guest. Are you saying we suppress >> log-dirty enabling in this case as well? I didn't think we do: > > No, but the comment says "migration with vGPU *assigned*" (my emphasis), which surely means has_arch_pdevs() will be true. You may replace it with 'associated' or something if you don't like this word. >> >> if ( has_arch_pdevs(d) && log_global ) >> { >> /* >> * Refuse to turn on global log-dirty mode >> * if the domain is sharing the P2M with the IOMMU. >> */ >> return -EINVAL; >> } >> >> Seeing this code I wonder about the non-sharing case: If what the >> comment says was true, the condition would need to change, but I >> think it's the comment which is wrong, and we don't want global >> log-dirty as long as an IOMMU is in use at all for a domain. > > I think is the comment that is correct, not the condition. It is only when using shared EPT that enabling logdirty is clearly an unsafe thing to do. Using sync-ed IOMMU mappings should be ok. It seems that the case of simple MMIO mappings made without IOMMU being enabled for a domain, in fact, irrelevant to the this condition. I take it as a separate discussion on a different topic. Igor From xen-devel-bounces@lists.xenproject.org Thu Jun 04 11:13:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 11:13:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnoD-0004WY-Hh; Thu, 04 Jun 2020 11:13:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnoC-0004WT-FG for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 11:13:16 +0000 X-Inumbo-ID: 6234bd4c-a654-11ea-8993-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6234bd4c-a654-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 11:13:14 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: oDor9dntqjX/CZq4EOWuvzz9MMJkD1I0M0gt1qCcqHU8OYVP/SXpQfJUsnrYO80Au6Z92f+w7x QGsytnEB2UhRDZmMNQO1Y68PX/sPqhaAnkKn51Kb6NxsQ1Mb8wsSZe8HkZOoVtRyEfUug/RxsX /tjKRvMNCQHdi5gRfSjXcKcl05ZzxHdtE/N7ThPYcvnejsDuLLHAxlsUNHZD1vb0bR8cr0X96b J56Rr4V4xod7gtciHGhqDVDpwdZgJNaTxMS20JoCSuJLKu8kDP0OR8dGgK0e48n/w01py8m+C5 ng4= X-SBRS: 2.7 X-MesageID: 19460865 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208,217";a="19460865" Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: Jan Beulich , =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> From: Andrew Cooper Message-ID: Date: Thu, 4 Jun 2020 12:13:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> Content-Type: multipart/alternative; boundary="------------DCC7A6CAB5EFD944658332FB" Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --------------DCC7A6CAB5EFD944658332FB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 04/06/2020 08:08, Jan Beulich wrote: > On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: >> Then, we get the main issue: >> >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff >> (XEN) domain_crash called from io.c:178 >> >> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom >> yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. > I'd guess an issue with the shutdown deferral logic. Did you / can > you check whether XEN_DMOP_remote_shutdown managed to pause all > CPUs (I assume it didn't, since once they're paused there shouldn't > be any I/O there anymore, and hence no I/O emulation)? The vcpu in question is talking to Qemu, so will have v->defer_shutdown intermittently set, and skip the pause in domain_shutdown() I presume this lack of pause is to allow the vcpu in question to still be scheduled to consume the IOREQ reply?  (Its fairly opaque logic with 0 clarifying details). What *should* happen is that, after consuming the reply, the vcpu should notice and pause itself, at which point it would yield to the scheduler.  This is the purpose of vcpu_{start,end}_shutdown_deferral(). Evidentially, this is not happening. Marek: can you add a BUG() after the weird PIO printing?  That should confirm whether we're getting into handle_pio() via the handle_hvm_io_completion() path, or via the vmexit path (at which case, we're fully re-entering the guest). I suspect you can drop the debugging of XEN_DOMCTL_destroydomain - I think its just noise atm. However, it would be very helpful to see the vcpus which fall into domain_shutdown()'s "else if ( v->defer_shutdown ) continue;" path. > Another question though: In 4.13 the log message next to the > domain_crash() I assume you're hitting is "Weird HVM ioemulation > status", not "Weird PIO status", and the debugging patch you > referenced doesn't have any change there. Andrew's recent > change to master, otoh, doesn't use the word "weird" anymore. I > can therefore only guess that the value logged is still > hvmemul_do_pio_buffer()'s return value, i.e. X86EMUL_UNHANDLEABLE. > Please confirm. It's the first draft of the patch which I did, before submitting to xen-devel.  We do have X86EMUL_UNHANDLEABLE at this point, but its not terribly helpful - there are loads of paths which fail silently with this error. ~Andrew --------------DCC7A6CAB5EFD944658332FB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
On 04/06/2020 08:08, Jan Beulich wrote:
On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote:

Then, we get the main issue:

    (XEN) d3v0 handle_pio port 0xb004 read 0x0000
    (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff
    (XEN) domain_crash called from io.c:178

Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom
yet. But XEN_DMOP_remote_shutdown for domain 3 was called already.

I'd guess an issue with the shutdown deferral logic. Did you / can
you check whether XEN_DMOP_remote_shutdown managed to pause all
CPUs (I assume it didn't, since once they're paused there shouldn't
be any I/O there anymore, and hence no I/O emulation)?

The vcpu in question is talking to Qemu, so will have v->defer_shutdown intermittently set, and skip the pause in domain_shutdown()

I presume this lack of pause is to allow the vcpu in question to still be scheduled to consume the IOREQ reply?  (Its fairly opaque logic with 0 clarifying details).

What *should* happen is that, after consuming the reply, the vcpu should notice and pause itself, at which point it would yield to the scheduler.  This is the purpose of vcpu_{start,end}_shutdown_deferral().

Evidentially, this is not happening.

Marek: can you add a BUG() after the weird PIO printing?  That should confirm whether we're getting into handle_pio() via the handle_hvm_io_completion() path, or via the vmexit path (at which case, we're fully re-entering the guest).

I suspect you can drop the debugging of XEN_DOMCTL_destroydomain - I think its just noise atm.

However, it would be very helpful to see the vcpus which fall into domain_shutdown()'s "else if ( v->defer_shutdown ) continue;" path.

Another question though: In 4.13 the log message next to the
domain_crash() I assume you're hitting is "Weird HVM ioemulation
status", not "Weird PIO status", and the debugging patch you
referenced doesn't have any change there. Andrew's recent
change to master, otoh, doesn't use the word "weird" anymore. I
can therefore only guess that the value logged is still
hvmemul_do_pio_buffer()'s return value, i.e. X86EMUL_UNHANDLEABLE.
Please confirm.

It's the first draft of the patch which I did, before submitting to xen-devel.  We do have X86EMUL_UNHANDLEABLE at this point, but its not terribly helpful - there are loads of paths which fail silently with this error.

~Andrew
--------------DCC7A6CAB5EFD944658332FB-- From xen-devel-bounces@lists.xenproject.org Thu Jun 04 11:23:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 11:23:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnyF-0005VI-JU; Thu, 04 Jun 2020 11:23:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgnyF-0005VC-4D for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 11:23:39 +0000 X-Inumbo-ID: d1ffe6d2-a655-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d1ffe6d2-a655-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 11:23:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=U6gLJvE6cdgDcJtWERX00zQ6FtuHH6YaMzEzww7bW6s=; b=CUrnD+mk6DEmI0bzlhR3I6oic mrsdcYfSweY6LIZ9Lkp1PFgPLSBoFbdbRJzpJdoAx0zxNlSyRE/uHBcJX4uK7BHZyF7jvgrLOrIaF Nr00E5vFz5QfKYxRKvV9f89rm8It0dMd4VGbN8+r20mPs0efru6dax9hpWCyan7EUhagk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgny7-0002pP-3L; Thu, 04 Jun 2020 11:23:31 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgny6-0004OG-QE; Thu, 04 Jun 2020 11:23:30 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgny6-0007WR-PZ; Thu, 04 Jun 2020 11:23:30 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150674: trouble: broken/fail/pass X-Osstest-Failures: xen-unstable:test-amd64-coresched-i386-xl::broken:regression xen-unstable:test-amd64-i386-qemuu-rhel6hvm-intel::broken:regression xen-unstable:test-amd64-amd64-xl-shadow::broken:regression xen-unstable:test-amd64-i386-qemut-rhel6hvm-amd::broken:regression xen-unstable:test-armhf-armhf-libvirt::broken:regression xen-unstable:test-amd64-coresched-amd64-xl::broken:regression xen-unstable:test-amd64-i386-qemut-rhel6hvm-intel::broken:regression xen-unstable:test-amd64-i386-qemuu-rhel6hvm-amd::broken:regression xen-unstable:test-amd64-i386-xl-raw::broken:regression xen-unstable:test-amd64-amd64-xl-qemuu-ovmf-amd64::broken:regression xen-unstable:test-amd64-i386-xl-qemuu-ovmf-amd64::broken:regression xen-unstable:test-xtf-amd64-amd64-5::broken:regression xen-unstable:test-xtf-amd64-amd64-4::broken:regression xen-unstable:test-amd64-amd64-qemuu-nested-intel::broken:regression xen-unstable:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow::broken:regression xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-amd64::broken:regression xen-unstable:test-amd64-i386-xl-qemut-debianhvm-amd64::broken:regression xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64::broken:regression xen-unstable:test-xtf-amd64-amd64-2::broken:regression xen-unstable:test-amd64-i386-xl-qemut-win7-amd64::broken:regression xen-unstable:test-armhf-armhf-libvirt-raw:capture-logs(11):running:regression xen-unstable:test-armhf-armhf-libvirt-raw:syslog-server:running:regression xen-unstable:test-amd64-i386-xl-qemut-debianhvm-amd64:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-coresched-i386-xl:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-i386-xl-qemuu-ovmf-amd64:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-amd64:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-coresched-amd64-xl:host-install(4):broken:heisenbug xen-unstable:test-amd64-i386-qemut-rhel6hvm-amd:host-install(4):broken:heisenbug xen-unstable:test-xtf-amd64-amd64-2:host-install(4):broken:heisenbug xen-unstable:test-xtf-amd64-amd64-4:host-install(4):broken:heisenbug xen-unstable:test-xtf-amd64-amd64-5:host-install(4):broken:heisenbug xen-unstable:test-amd64-i386-qemut-rhel6hvm-intel:host-install(4):broken:heisenbug xen-unstable:test-amd64-amd64-xl-shadow:host-install(4):broken:heisenbug xen-unstable:test-xtf-amd64-amd64-2:syslog-server:broken:heisenbug xen-unstable:test-xtf-amd64-amd64-4:syslog-server:broken:heisenbug xen-unstable:test-xtf-amd64-amd64-5:syslog-server:broken:heisenbug xen-unstable:test-amd64-coresched-amd64-xl:syslog-server:broken:heisenbug xen-unstable:test-amd64-i386-qemut-rhel6hvm-amd:syslog-server:broken:heisenbug xen-unstable:test-amd64-i386-qemut-rhel6hvm-intel:syslog-server:broken:heisenbug xen-unstable:test-amd64-amd64-xl-shadow:syslog-server:broken:heisenbug xen-unstable:test-amd64-i386-xl:syslog-server:broken:heisenbug xen-unstable:test-armhf-armhf-xl-rtds:syslog-server:broken:heisenbug xen-unstable:test-amd64-i386-qemuu-rhel6hvm-intel:host-ping-check-xen:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-ovmf-amd64:guest-localmigrate:fail:heisenbug xen-unstable:test-amd64-i386-qemuu-rhel6hvm-amd:guest-start/redhat.repeat:fail:heisenbug xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-localmigrate:fail:heisenbug xen-unstable:test-amd64-i386-xl-raw:guest-saverestore:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:guest-start/debianhvm.repeat:fail:heisenbug xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt-raw:debian-di-install:fail:heisenbug xen-unstable:test-amd64-amd64-qemuu-nested-intel:capture-logs/l1(20):fail:heisenbug xen-unstable:test-armhf-armhf-libvirt:guest-start/debian.repeat:fail:heisenbug xen-unstable:test-amd64-i386-qemut-rhel6hvm-intel:capture-logs(5):broken:nonblocking xen-unstable:test-amd64-amd64-xl-shadow:capture-logs(5):broken:nonblocking xen-unstable:test-xtf-amd64-amd64-2:capture-logs(5):broken:nonblocking xen-unstable:test-xtf-amd64-amd64-4:capture-logs(5):broken:nonblocking xen-unstable:test-xtf-amd64-amd64-5:capture-logs(5):broken:nonblocking xen-unstable:test-amd64-i386-qemut-rhel6hvm-amd:capture-logs(5):broken:nonblocking xen-unstable:test-amd64-i386-qemuu-rhel6hvm-intel:capture-logs(9):broken:nonblocking xen-unstable:test-amd64-i386-qemuu-rhel6hvm-amd:capture-logs(13):broken:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ovmf-amd64:capture-logs(15):broken:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:capture-logs(15):broken:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:capture-logs(11):broken:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-intel:capture-logs(21):broken:nonblocking xen-unstable:test-armhf-armhf-libvirt:capture-logs(17):broken:nonblocking xen-unstable:test-amd64-coresched-amd64-xl:capture-logs(5):broken:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:capture-logs(19):broken:nonblocking xen-unstable:test-amd64-i386-xl-raw:capture-logs(15):broken:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Thu, 04 Jun 2020 11:23:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150674 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150674/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-coresched-i386-xl broken test-amd64-i386-qemuu-rhel6hvm-intel broken test-amd64-amd64-xl-shadow broken test-amd64-i386-qemut-rhel6hvm-amd broken test-armhf-armhf-libvirt broken test-amd64-coresched-amd64-xl broken test-amd64-i386-qemut-rhel6hvm-intel broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-i386-xl-raw broken test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-i386-xl-qemuu-ovmf-amd64 broken test-xtf-amd64-amd64-5 broken test-xtf-amd64-amd64-4 broken test-amd64-amd64-qemuu-nested-intel broken test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken test-amd64-amd64-xl-qemut-debianhvm-amd64 broken test-amd64-i386-xl-qemut-debianhvm-amd64 broken test-amd64-i386-xl-qemuu-ws16-amd64 broken test-xtf-amd64-amd64-2 broken test-amd64-i386-xl-qemut-win7-amd64 broken test-armhf-armhf-libvirt-raw 11 capture-logs(11) running test-armhf-armhf-libvirt-raw 3 syslog-server running Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemut-debianhvm-amd64 2 hosts-allocate broken pass in 150635 test-amd64-coresched-i386-xl 2 hosts-allocate broken pass in 150635 test-amd64-i386-xl-qemuu-ovmf-amd64 2 hosts-allocate broken pass in 150635 test-amd64-amd64-xl-qemut-debianhvm-amd64 2 hosts-allocate broken pass in 150635 test-amd64-coresched-amd64-xl 4 host-install(4) broken pass in 150635 test-amd64-i386-qemut-rhel6hvm-amd 4 host-install(4) broken pass in 150635 test-xtf-amd64-amd64-2 4 host-install(4) broken pass in 150635 test-xtf-amd64-amd64-4 4 host-install(4) broken pass in 150635 test-xtf-amd64-amd64-5 4 host-install(4) broken pass in 150635 test-amd64-i386-qemut-rhel6hvm-intel 4 host-install(4) broken pass in 150635 test-amd64-amd64-xl-shadow 4 host-install(4) broken pass in 150635 test-xtf-amd64-amd64-2 3 syslog-server broken pass in 150635 test-xtf-amd64-amd64-4 3 syslog-server broken pass in 150635 test-xtf-amd64-amd64-5 3 syslog-server broken pass in 150635 test-amd64-coresched-amd64-xl 3 syslog-server broken pass in 150635 test-amd64-i386-qemut-rhel6hvm-amd 3 syslog-server broken pass in 150635 test-amd64-i386-qemut-rhel6hvm-intel 3 syslog-server broken pass in 150635 test-amd64-amd64-xl-shadow 3 syslog-server broken pass in 150635 test-amd64-i386-xl 3 syslog-server broken pass in 150635 test-armhf-armhf-xl-rtds 3 syslog-server broken pass in 150635 test-amd64-i386-qemuu-rhel6hvm-intel 8 host-ping-check-xen fail pass in 150635 test-amd64-amd64-xl-qemuu-ovmf-amd64 14 guest-localmigrate fail pass in 150635 test-amd64-i386-qemuu-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 150635 test-amd64-i386-xl-qemut-win7-amd64 14 guest-localmigrate fail pass in 150635 test-amd64-i386-xl-raw 14 guest-saverestore fail pass in 150635 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 18 guest-start/debianhvm.repeat fail pass in 150635 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail pass in 150635 test-armhf-armhf-libvirt-raw 10 debian-di-install fail pass in 150635 test-amd64-amd64-qemuu-nested-intel 20 capture-logs/l1(20) fail pass in 150635 test-armhf-armhf-libvirt 16 guest-start/debian.repeat fail pass in 150635 Tests which did not succeed, but are not blocking: test-amd64-i386-qemut-rhel6hvm-intel 5 capture-logs(5) broken blocked in 150635 test-amd64-amd64-xl-shadow 5 capture-logs(5) broken blocked in 150635 test-xtf-amd64-amd64-2 5 capture-logs(5) broken blocked in 150635 test-xtf-amd64-amd64-4 5 capture-logs(5) broken blocked in 150635 test-xtf-amd64-amd64-5 5 capture-logs(5) broken blocked in 150635 test-amd64-i386-qemut-rhel6hvm-amd 5 capture-logs(5) broken blocked in 150635 test-amd64-i386-qemuu-rhel6hvm-intel 9 capture-logs(9) broken blocked in 150635 test-amd64-i386-qemuu-rhel6hvm-amd 13 capture-logs(13) broken blocked in 150635 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 capture-logs(15) broken blocked in 150635 test-amd64-i386-xl-qemut-win7-amd64 15 capture-logs(15) broken blocked in 150635 test-amd64-i386-xl-qemuu-ws16-amd64 11 capture-logs(11) broken blocked in 150635 test-amd64-amd64-qemuu-nested-intel 21 capture-logs(21) broken blocked in 150635 test-armhf-armhf-libvirt 17 capture-logs(17) broken blocked in 150635 test-amd64-coresched-amd64-xl 5 capture-logs(5) broken never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 19 capture-logs(19) broken never pass test-amd64-i386-xl-raw 15 capture-logs(15) broken never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 150635 like 150609 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 150635 like 150609 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 150635 like 150609 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 150635 never pass test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150635 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150635 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150635 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150635 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150635 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150635 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150635 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150635 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150674 2020-06-04 01:58:27 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 broken test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 broken test-xtf-amd64-amd64-5 broken test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl broken test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemut-debianhvm-amd64 broken test-amd64-i386-xl-qemut-debianhvm-amd64 broken test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-i386-xl-qemuu-ovmf-amd64 broken test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 broken test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 broken test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel broken test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel broken test-amd64-i386-qemuu-rhel6hvm-intel broken test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt broken test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw broken test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow broken test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-coresched-i386-xl broken broken-job test-amd64-i386-qemuu-rhel6hvm-intel broken broken-job test-amd64-amd64-xl-shadow broken broken-job test-amd64-i386-qemut-rhel6hvm-amd broken broken-job test-armhf-armhf-libvirt broken broken-job test-amd64-coresched-amd64-xl broken broken-job test-amd64-i386-qemut-rhel6hvm-intel broken broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken broken-job test-amd64-i386-xl-raw broken broken-job test-amd64-amd64-xl-qemuu-ovmf-amd64 broken broken-job test-amd64-i386-xl-qemuu-ovmf-amd64 broken broken-job test-xtf-amd64-amd64-5 broken broken-job test-xtf-amd64-amd64-4 broken broken-job test-amd64-amd64-qemuu-nested-intel broken broken-job test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken broken-job test-amd64-amd64-xl-qemut-debianhvm-amd64 broken broken-job test-amd64-i386-xl-qemut-debianhvm-amd64 broken broken-job test-amd64-i386-xl-qemuu-ws16-amd64 broken broken-job test-xtf-amd64-amd64-2 broken broken-job test-amd64-i386-xl-qemut-win7-amd64 broken broken-step test-amd64-i386-qemut-rhel6hvm-intel capture-logs(5) broken-step test-amd64-i386-xl-qemut-debianhvm-amd64 hosts-allocate broken-step test-amd64-coresched-i386-xl hosts-allocate broken-step test-amd64-i386-xl-qemuu-ovmf-amd64 hosts-allocate broken-step test-amd64-amd64-xl-qemut-debianhvm-amd64 hosts-allocate broken-step test-amd64-amd64-xl-shadow capture-logs(5) broken-step test-xtf-amd64-amd64-2 capture-logs(5) broken-step test-xtf-amd64-amd64-4 capture-logs(5) broken-step test-xtf-amd64-amd64-5 capture-logs(5) broken-step test-amd64-i386-qemut-rhel6hvm-amd capture-logs(5) broken-step test-amd64-coresched-amd64-xl capture-logs(5) broken-step test-amd64-coresched-amd64-xl host-install(4) broken-step test-amd64-i386-qemut-rhel6hvm-amd host-install(4) broken-step test-xtf-amd64-amd64-2 host-install(4) broken-step test-xtf-amd64-amd64-4 host-install(4) broken-step test-xtf-amd64-amd64-5 host-install(4) broken-step test-amd64-i386-qemut-rhel6hvm-intel host-install(4) broken-step test-amd64-amd64-xl-shadow host-install(4) broken-step test-amd64-i386-qemuu-rhel6hvm-intel capture-logs(9) broken-step test-xtf-amd64-amd64-2 syslog-server broken-step test-xtf-amd64-amd64-4 syslog-server broken-step test-xtf-amd64-amd64-5 syslog-server broken-step test-amd64-i386-qemuu-rhel6hvm-amd capture-logs(13) broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 capture-logs(15) broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow capture-logs(19) broken-step test-amd64-coresched-amd64-xl syslog-server broken-step test-amd64-i386-qemut-rhel6hvm-amd syslog-server broken-step test-amd64-i386-xl-raw capture-logs(15) broken-step test-amd64-i386-qemut-rhel6hvm-intel syslog-server broken-step test-amd64-i386-xl-qemut-win7-amd64 capture-logs(15) broken-step test-amd64-i386-xl-qemuu-ws16-amd64 capture-logs(11) broken-step test-amd64-amd64-xl-shadow syslog-server broken-step test-amd64-i386-xl syslog-server broken-step test-amd64-amd64-qemuu-nested-intel capture-logs(21) broken-step test-armhf-armhf-libvirt capture-logs(17) broken-step test-armhf-armhf-xl-rtds syslog-server Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Thu Jun 04 11:36:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 11:36:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoA8-0006WC-SW; Thu, 04 Jun 2020 11:35:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoA8-0006W7-4B for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 11:35:56 +0000 X-Inumbo-ID: 8cf2d980-a657-11ea-81bc-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8cf2d980-a657-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 11:35:55 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: B/2NPJysEtlF5iTqSkXZRVP925RDlvp2ZZBlE9KU/CLGxRgRdzEU6/RhJ+JXwp1GYufnrGE/Gb s8aFiR0mVk9imNJBm5m41nO2Ue6BdKfpdSFdla9Pb0TUAjtzez9hKl3q+j1/xy5bU4o3GirNqx 1e311TVg8FEoSbllvQnsiGssmxZRkjJQNTk3luHer36l5DMzRQsVw1JGy4HCaDBabZ79iyHTqh U1sed9m+l6h2QGttP+x4uG3XAvXqCnlxHIscKYi6if170slsMMDpANO4arpLIZ3IUvF1LgADGp YRU= X-SBRS: 2.7 X-MesageID: 19505023 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="19505023" Subject: Re: [PATCH] build: fix dependency tracking for preprocessed files To: Jan Beulich , "xen-devel@lists.xenproject.org" References: From: Andrew Cooper Message-ID: <0f8afd27-2af5-580e-48f8-65c01881e568@citrix.com> Date: Thu, 4 Jun 2020 12:35:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , Ian Jackson , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 11:22, Jan Beulich wrote: > While the issue is more general, I noticed that asm-macros.i not getting > re-generated as needed. This was due to its .*.d file mentioning > asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at > it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds > dependency tracking files. While there, further avoid open-coding $(CPP) > and drop the bogus -Ui386. Its not bogus.  It really is needed to prevent OUTPUT_ARCH(i386:x86-64) being preprocessed to OUTPUT_ARCH(1:x86-64) This explodes properly with 32bit builds, but we might get away with it now on a 64bit build (preprocessing without -m32 does appear to skip this transformation). However, the robust way to deal with it is: /* Don't clobber the ld directive */ #undef i386 unconditionally in xen.lds.S > Signed-off-by: Jan Beulich > > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -201,13 +201,13 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) > $(call if_changed,obj_init_o) > > quiet_cmd_cpp_i_c = CPP $@ > -cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ > +cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ -MQ $@ Please can -MQ come before $<, so the input and output files are still at the end of the command.  It is a very useful property of the current setup, when playing build system surgery. If you're happy with both of these suggestions, Reviewed-by: Andrew Cooper to save another round trip. Alternatively, I'm happy to submit the i386 as a prereq patch, seeing as it isn't now such a trivial change any more. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 04 11:47:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 11:47:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoLR-0007XI-VU; Thu, 04 Jun 2020 11:47:37 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoLQ-0007XD-Ac for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 11:47:36 +0000 X-Inumbo-ID: 2e562e02-a659-11ea-ae6a-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2e562e02-a659-11ea-ae6a-12813bfff9fa; Thu, 04 Jun 2020 11:47:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 31358AC52; Thu, 4 Jun 2020 11:47:37 +0000 (UTC) Subject: Re: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately To: paul@xen.org References: <1591224108-564-1-git-send-email-igor.druzhinin@citrix.com> <006401d63a44$a27349e0$e759dda0$@xen.org> <4d1da8eb-a06e-c97a-09a0-e84070dc5ec8@suse.com> <000f01d63a5d$fe3787f0$faa697d0$@xen.org> From: Jan Beulich Message-ID: Date: Thu, 4 Jun 2020 13:47:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <000f01d63a5d$fe3787f0$faa697d0$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Igor Druzhinin' , wl@xen.org, andrew.cooper3@citrix.com, george.dunlap@citrix.com, xen-devel@lists.xenproject.org, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.2020 12:50, Paul Durrant wrote: >> From: Jan Beulich >> Sent: 04 June 2020 11:34 >> >> On 04.06.2020 09:49, Paul Durrant wrote: >>>> -----Original Message----- >>>> From: Igor Druzhinin >>>> Sent: 03 June 2020 23:42 >>>> To: xen-devel@lists.xenproject.org >>>> Cc: jbeulich@suse.com; andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; >>>> george.dunlap@citrix.com; paul@xen.org; Igor Druzhinin >>>> Subject: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately >>>> >>>> A recalculation NPT fault doesn't always require additional handling >>>> in hvm_hap_nested_page_fault(), moreover in general case if there is no >>>> explicit handling done there - the fault is wrongly considered fatal. >>>> >>>> This covers a specific case of migration with vGPU assigned which >>>> uses direct MMIO mappings made by XEN_DOMCTL_memory_mapping hypercall: >>>> at a moment log-dirty is enabled globally, recalculation is requested >>>> for the whole guest memory including those mapped MMIO regions >>> >>> I still think it is odd to put this in the commit comment since, as I >>> said before, Xen ensures that this situation cannot happen at >>> the moment. >> >> Aiui Igor had replaced reference to passed-through devices by reference >> to mere handing of an MMIO range to a guest. Are you saying we suppress >> log-dirty enabling in this case as well? I didn't think we do: > > No, but the comment says "migration with vGPU *assigned*" (my emphasis), which surely means has_arch_pdevs() will be true. > >> >> if ( has_arch_pdevs(d) && log_global ) >> { >> /* >> * Refuse to turn on global log-dirty mode >> * if the domain is sharing the P2M with the IOMMU. >> */ >> return -EINVAL; >> } >> >> Seeing this code I wonder about the non-sharing case: If what the >> comment says was true, the condition would need to change, but I >> think it's the comment which is wrong, and we don't want global >> log-dirty as long as an IOMMU is in use at all for a domain. > > I think is the comment that is correct, not the condition. It is > only when using shared EPT that enabling logdirty is clearly an > unsafe thing to do. Using sync-ed IOMMU mappings should be ok. Even with sync-ed IOMMU mappings dirtying happening by I/O won't be noticed, and hence the purpose of global log-dirty is undermined. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 04 11:55:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 11:55:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoSy-0008Ud-O6; Thu, 04 Jun 2020 11:55:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoSw-0008UY-Lp for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 11:55:22 +0000 X-Inumbo-ID: 44763d34-a65a-11ea-81bc-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 44763d34-a65a-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 11:55:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id F2671AC52; Thu, 4 Jun 2020 11:55:23 +0000 (UTC) Subject: Re: [PATCH] build: fix dependency tracking for preprocessed files To: Andrew Cooper References: <0f8afd27-2af5-580e-48f8-65c01881e568@citrix.com> From: Jan Beulich Message-ID: Date: Thu, 4 Jun 2020 13:55:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <0f8afd27-2af5-580e-48f8-65c01881e568@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , Ian Jackson , George Dunlap , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.2020 13:35, Andrew Cooper wrote: > On 04/06/2020 11:22, Jan Beulich wrote: >> While the issue is more general, I noticed that asm-macros.i not getting >> re-generated as needed. This was due to its .*.d file mentioning >> asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at >> it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds >> dependency tracking files. While there, further avoid open-coding $(CPP) >> and drop the bogus -Ui386. > > Its not bogus.  It really is needed to prevent OUTPUT_ARCH(i386:x86-64) > being preprocessed to OUTPUT_ARCH(1:x86-64) > > This explodes properly with 32bit builds, but we might get away with it > now on a 64bit build (preprocessing without -m32 does appear to skip > this transformation). We haven't been doing 32-bit builds for quite a while, hence I continue to assert the -U option is bogus; I'm not claiming it always has been (that's true just for Arm). > However, the robust way to deal with it is: > > /* Don't clobber the ld directive */ > #undef i386 > > unconditionally in xen.lds.S This would mean to add code with no effect, which I'd prefer to avoid. >> --- a/xen/Rules.mk >> +++ b/xen/Rules.mk >> @@ -201,13 +201,13 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) >> $(call if_changed,obj_init_o) >> >> quiet_cmd_cpp_i_c = CPP $@ >> -cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ >> +cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ -MQ $@ > > Please can -MQ come before $<, so the input and output files are still > at the end of the command.  It is a very useful property of the current > setup, when playing build system surgery. Ah yes, but then I'll make it " -MQ $@ -o $@ $<", better matching the .lds rules (where I'll also move -MQ ahead of -o). > If you're happy with both of these suggestions, Reviewed-by: Andrew > Cooper to save another round trip. As per above, only the latter, so for now I won't put it into the patch. > Alternatively, I'm happy to submit the i386 as a prereq patch, seeing as > it isn't now such a trivial change any more. As per above, I don't think such an adjustment is wanted or needed. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 04 11:58:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 11:58:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoW0-0000CO-6X; Thu, 04 Jun 2020 11:58:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoVz-0000CJ-I6 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 11:58:31 +0000 X-Inumbo-ID: b51ed1ae-a65a-11ea-9947-bc764e2007e4 Received: from mail-wr1-x432.google.com (unknown [2a00:1450:4864:20::432]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b51ed1ae-a65a-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 11:58:30 +0000 (UTC) Received: by mail-wr1-x432.google.com with SMTP id r7so5807854wro.1 for ; Thu, 04 Jun 2020 04:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=cNAuUPcCaciSyOFWPd6BJu6y9TZPieUoikaUPOLBltY=; b=G3BA3qKwpoQrQT2givVUUQrCkQcWl/0RaYNR80VftP/VvvqG35TFRKTePRdezRdUxt gM+FxZDxmZQ4L3pQei9A/RPLwtS+D09NvYskmrnU/WmS77fTiloTu67SsGqNCzaXcCCs DnnWqKoN245/8s4gTCwWaq4P6DBRU2/nqLFLNSU9DaemmnKj76uyegYkEesn8Qk4/bau AyjKr376Lpv1ukwYOtZZ1IqxacUmW1/rtLWuOdojc8I9zLpj8JseTSsLSom2HIxs26Ln sNbQjtGvTK6X065WQBNjY8jKqW/U/5ZxAYahUVW7x0IbjKsHB7nXhsc8UXtyq+YqmL50 qWdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :thread-index:content-language; bh=cNAuUPcCaciSyOFWPd6BJu6y9TZPieUoikaUPOLBltY=; b=CaBY7ltRR6SrV364ItdCgExiVS6XpiOQKBEWl6dV62ly1Q43Hch6vSt2FZ0Rs9POoV A9EDnMzQ+ebg0y2HHyybQr1/bRRQuwRodz1s2EzlPPRIDXOzS+AcOX1Jk14VrhRd+gNi +I/gxVZmmY8oOJER8uWvmpltqhLBul/BkFdqOwlx8j+BaInTZgeZG0gtWYIIMsXMt00E 7pk1O8pKaCo4ZWQw1O7FelwD5/uYBCyvkdHHePUY6rLwHCATKDYlI4M4knRY7MHYpT0y K1PtW4kPDneCvYzpIcH9WFJqae/6Y/k5fzY0iNSsLaU8gY84yObxpngS1KOQYqekQBp0 hwuQ== X-Gm-Message-State: AOAM530LKyHi/ZetiUye37tWs9TBr+CQ6kcAgv92DpX8MBoqj48w9zvO /RoNp0UeZBsFg5FEuZgPFnk= X-Google-Smtp-Source: ABdhPJx3pyZ+2yfqfX6IwOd6p299idt+NCIYMiybC/FarcClMxnVstqQeNZO0xPSEy0qDjDU492XwA== X-Received: by 2002:adf:aad7:: with SMTP id i23mr4180792wrc.331.1591271909989; Thu, 04 Jun 2020 04:58:29 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id s7sm7958628wrr.60.2020.06.04.04.58.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jun 2020 04:58:29 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <1591224108-564-1-git-send-email-igor.druzhinin@citrix.com> <006401d63a44$a27349e0$e759dda0$@xen.org> <4d1da8eb-a06e-c97a-09a0-e84070dc5ec8@suse.com> <000f01d63a5d$fe3787f0$faa697d0$@xen.org> In-Reply-To: Subject: RE: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc NPT faults immediately Date: Thu, 4 Jun 2020 12:58:27 +0100 Message-ID: <001401d63a67$763f9810$62bec830$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKnLWBT9mNjQEOL+u7d2oiXq95SHgJRYkBUAnFt9OEB/ZZVsALqGHDzptkfTAA= Content-Language: en-gb X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Igor Druzhinin' , wl@xen.org, andrew.cooper3@citrix.com, george.dunlap@citrix.com, xen-devel@lists.xenproject.org, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 04 June 2020 12:47 > To: paul@xen.org > Cc: 'Igor Druzhinin' ; = xen-devel@lists.xenproject.org; > andrew.cooper3@citrix.com; wl@xen.org; roger.pau@citrix.com; = george.dunlap@citrix.com > Subject: Re: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc = NPT faults immediately >=20 > On 04.06.2020 12:50, Paul Durrant wrote: > >> From: Jan Beulich > >> Sent: 04 June 2020 11:34 > >> > >> On 04.06.2020 09:49, Paul Durrant wrote: > >>>> -----Original Message----- > >>>> From: Igor Druzhinin > >>>> Sent: 03 June 2020 23:42 > >>>> To: xen-devel@lists.xenproject.org > >>>> Cc: jbeulich@suse.com; andrew.cooper3@citrix.com; wl@xen.org; = roger.pau@citrix.com; > >>>> george.dunlap@citrix.com; paul@xen.org; Igor Druzhinin = > >>>> Subject: [PATCH for-4.14 v3] x86/svm: do not try to handle recalc = NPT faults immediately > >>>> > >>>> A recalculation NPT fault doesn't always require additional = handling > >>>> in hvm_hap_nested_page_fault(), moreover in general case if there = is no > >>>> explicit handling done there - the fault is wrongly considered = fatal. > >>>> > >>>> This covers a specific case of migration with vGPU assigned which > >>>> uses direct MMIO mappings made by XEN_DOMCTL_memory_mapping = hypercall: > >>>> at a moment log-dirty is enabled globally, recalculation is = requested > >>>> for the whole guest memory including those mapped MMIO regions > >>> > >>> I still think it is odd to put this in the commit comment since, = as I > >>> said before, Xen ensures that this situation cannot happen at > >>> the moment. > >> > >> Aiui Igor had replaced reference to passed-through devices by = reference > >> to mere handing of an MMIO range to a guest. Are you saying we = suppress > >> log-dirty enabling in this case as well? I didn't think we do: > > > > No, but the comment says "migration with vGPU *assigned*" (my = emphasis), which surely means > has_arch_pdevs() will be true. > > > >> > >> if ( has_arch_pdevs(d) && log_global ) > >> { > >> /* > >> * Refuse to turn on global log-dirty mode > >> * if the domain is sharing the P2M with the IOMMU. > >> */ > >> return -EINVAL; > >> } > >> > >> Seeing this code I wonder about the non-sharing case: If what the > >> comment says was true, the condition would need to change, but I > >> think it's the comment which is wrong, and we don't want global > >> log-dirty as long as an IOMMU is in use at all for a domain. > > > > I think is the comment that is correct, not the condition. It is > > only when using shared EPT that enabling logdirty is clearly an > > unsafe thing to do. Using sync-ed IOMMU mappings should be ok. >=20 > Even with sync-ed IOMMU mappings dirtying happening by I/O won't be > noticed, and hence the purpose of global log-dirty is undermined. It is, but there are point solutions in some devices and, if not in the = device, in the emulator managing the device. This is why migration with = assigned h/w is currently feasible even without IOMMU faulting. Paul >=20 > Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 04 11:59:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 11:59:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoWh-0000GR-G9; Thu, 04 Jun 2020 11:59:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoWg-0000GE-0x for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 11:59:14 +0000 X-Inumbo-ID: ccdd0e1e-a65a-11ea-9947-bc764e2007e4 Received: from mail-oi1-x243.google.com (unknown [2607:f8b0:4864:20::243]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ccdd0e1e-a65a-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 11:59:10 +0000 (UTC) Received: by mail-oi1-x243.google.com with SMTP id j189so4799463oih.10 for ; Thu, 04 Jun 2020 04:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MP+MSIIv1u5nMjP12qFOOqmxhDupPPSuAsiS0Q7kPh8=; b=KPoKu+QjsSf/3CVTmbiW61qyvxa7L+kfeCuQwJ7CXjFHy6Jrb8LGGHLeqYrfju3vBG L76jKx9fpWPIj8bZnoWTlmwf6zKlo+I8hOYjD+KpPevMKiwD3lTqoTpJE/QGiHqvEQSv Lc27GYfLqWo3oqXL7fFIB5xn8NQVBddMcyDJ5/57eltI7wFCk2FJcf88HsGxeQjc97PK 9kCN0T2nwIIzSeVvhfHskZ1REDJ/mYOSE0qJNHDjRWIWyyDxxcW1r0dMTW4jy98qkx5T Ss+BIHPRFQSH38zquhl2xOWJe/zj9S0zw+sCw/ptRGBBAvGV+WmAZwqnTP0lmIc+YmPI 6jSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=MP+MSIIv1u5nMjP12qFOOqmxhDupPPSuAsiS0Q7kPh8=; b=sl6RFw29NsZe67XLHtHdrMRYfMjdBDao0pWbE8g84FTCkMAeic1AeRaEU0desGvht1 3aSj/SBLark+kKZK7ioq+n3wO0/PB6wJzKJc9jk0tE/Qgy3j29RPm7JTk8FmRJwHrxoK 9lXv+LtBfWtGNsy5P7AVBMicM0Po6o7H9aFwKN4gIeTNXP/5/ugMwnshyyqOethYXmQ3 DyZgSqT+nl7kprdopl0+/Vq9wqvmE7RQtuTXC42OaO3Uy/fRbRFTeYXF/rJ8IVTxTM1Q Jea5aN2OJejVEKdz4cM3f9jPaUsboUTdAaPjuWoqmmthbqy9f/XfLUNrXHzBREGKE2Pw tFVg== X-Gm-Message-State: AOAM5301jAPkKnF64C1/lZ0gHNidLDq+6u4yF7v7VEZfJOWksturN5vv K5wX6kxtK1iSDYdBsxG46mK9eEj0IEo= X-Google-Smtp-Source: ABdhPJz69RfwEVipNTi6DzGS/HAU+oavhlaLxYHsKLyUUrMcde30wMQgCwHOLB4sDkS4PgZ/lk+1OQ== X-Received: by 2002:aca:d583:: with SMTP id m125mr2821909oig.138.1591271949814; Thu, 04 Jun 2020 04:59:09 -0700 (PDT) Received: from minyard.net ([2001:470:b8f6:1b:9d35:f7bd:647:6545]) by smtp.gmail.com with ESMTPSA id j2sm1059292otk.61.2020.06.04.04.59.08 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Jun 2020 04:59:09 -0700 (PDT) Date: Thu, 4 Jun 2020 06:59:07 -0500 From: Corey Minyard To: Julien Grall Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset Message-ID: <20200604115907.GD2903@minyard.net> References: <20200603223156.12767-1-sstabellini@kernel.org> <20200604001552.GC2903@minyard.net> <50ad4bca-5eb8-8db0-0aae-dc7febfdb56a@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50ad4bca-5eb8-8db0-0aae-dc7febfdb56a@xen.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: cminyard@mvista.com Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , tamas@tklengyel.com, roman@zededa.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 04, 2020 at 09:15:33AM +0100, Julien Grall wrote: > Hi, > > On 04/06/2020 01:15, Corey Minyard wrote: > > On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote: > > > Touching the watchdog is required to be able to reboot the board. > > > > > > The implementation is based on > > > drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > > > Ah, I was looking at this just today, as it had been annoying me > > greatly. This works for me, so: > > > > Tested-by: Corey Minyard > > > > However, I was wondering if it might be better to handle this by failing > > the operation in xen and passing it back to dom0 to do. On the Pi you > > send a firmware message to reboot, and that seems like too much to do in > > Xen, but it would seem possible to send this back to dom0. > I don't think this is possible in the current setup. Xen will usually > restart the platform if Dom0 requested a clean reboot or crashed. So the > domain wouldn't be in state to service such call. Ok, I hadn't looked at Xen yet, I didn't know how much shutdown of dom0 happens on a reset. > > > Just a > > thought, as it might be a more general fix for other devices in the same > > situation. > > What are the devices you have in mind? Nothing in particular, but other systems might have the same issue. I guess you have ACPI implemented on x86 already. It just seemed that Linux already has to be able to do this, and passing the buck back there might be a more general solution. Thanks, -corey > > Cheers, > > -- > Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:07:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:07:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoef-0001Tu-20; Thu, 04 Jun 2020 12:07:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgoee-0001Tp-1W for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:07:28 +0000 X-Inumbo-ID: f4d4c8a2-a65b-11ea-81bc-bc764e2007e4 Received: from mail-ej1-x62d.google.com (unknown [2a00:1450:4864:20::62d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f4d4c8a2-a65b-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 12:07:27 +0000 (UTC) Received: by mail-ej1-x62d.google.com with SMTP id gl26so5786170ejb.11 for ; Thu, 04 Jun 2020 05:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=t8SM/nW4BgsQUF9t4J8KD3LG9JTs+VZPVRCmaFf19EA=; b=OnPLxcVONbZ7KuTqzhXnAMGZiE8s67E1GRJBdYggpQaX6fyfNHOza3L8RJ7kyYH/JF hAOVJy6pC/XtBWtayokLeNipZkB4IQQVia02SIZbPwORzg94P0GHKHTISobYggfJDEdz zYsKVD4JO0rTViTwpFUVRb9Z+V4uh9Bmrza3hKSU/pjPAh+kgu0fNa278Z04oa6LMnKy Ps7pIEPsG04fqlMPFvPZYBKxijY6pUc2/Cieui1146bhaTohMNpNN7HqsDbHiZFACKaS ExCcVyaLGBsEy9y8dkkLGblF/wYRkWadn6B0HaY6CfLhHpl+LkqF8JL6iAYcrW0kkKyz ja9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t8SM/nW4BgsQUF9t4J8KD3LG9JTs+VZPVRCmaFf19EA=; b=gPqlAVSKJSuMEVSSrZQqkPGtQfbcDHk4WIsADs9CroAxR0Uk3Vs0UvaEdcDzZtppNr q9ICd5rS/Qosu3zPvnFBaqxbQ16zytLQ2sKezBnwjJy3QALIUYegjuA60dSIjExT0e9J xh1bjjw5iSEUD6+wtwc0JJeZP4CtAj0CHcjaRXNPwiorj43tPC7VqIdcXtuMOHybxsER oTqnJ0cyv+KkwcP9sRzokapbPg8y6mS2OrDss5jDUoVrrBoNsJsmL2epNqi01rAktQOk ARk2XqAx1QR7xrjjL8IvJPaUtlsajrP8kC2cNBSCdVlrZWcqGPSc+GnmqWBDH3IEZgMj XSZA== X-Gm-Message-State: AOAM531lpqr8KX1eokWuUmu06xcEisjAoHyzoqJ6oHTvlHqE1hwrrYH7 xf+jCgCWrk5ciY5UUZG8YS+ypBBbgE1GiFABnas= X-Google-Smtp-Source: ABdhPJzAHrGLZ4/teiEH9hBk2XKVEV8+V4SSypNIyKR8OnSBQ/4gRRtI48+JwLfz+HR71aUWp8xv/O+HGU37p8ShCyw= X-Received: by 2002:a17:906:11d9:: with SMTP id o25mr3420151eja.377.1591272446418; Thu, 04 Jun 2020 05:07:26 -0700 (PDT) MIME-Version: 1.0 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> In-Reply-To: From: CodeWiz2280 Date: Thu, 4 Jun 2020 08:07:12 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 4, 2020 at 6:16 AM Julien Grall wrote: > > Hi, > > On 04/06/2020 10:08, Bertrand Marquis wrote: > > I would have thought that linux would have need some memory, even small= in the 32bit space in order to boot. > > Yes it needs some, but then they are switching to use the high memory > alias after the MMU has been switch on. > > From my understanding, the only difference is the page-tables will > point to the high memory alias address rather than the low memory one. > Linux will still be located at the same place but now accessed from the > high memory alias rather than the low one. > > Note that AFAICT the secondary CPUs will still be brought-up using the > low memory alias. > > > I could understand that some memory in the low address space needs to b= e reserved by Linux as DMA area for peripherals not supporting 36-bit addre= sses, but the whole low memory sounds like a big restriction. > Many platforms have devices only supporting 32-bit DMA, but none of them > require such aliasing. So this doesn't look to be the issue here. > > TBH, this code is only used by Keystone and switching address space is > expensive (you have to turn off the MMU, updates page-tables, flush the > cache...). I find hard to believe a developper would have come up with > this complexity if it were possible to always use the low memory address > range. It is even harder to believe Linux community would have accepted i= t. > > > > > Would it be possible to have a bit more information on the =E2=80=9Cpro= blem with peripherals=E2=80=9D here ? > > I am curious as well, so I looked in more depth :). Going through the > Linux history, one of the commit message [1] suggests they are switching > to a coherent address space. The datasheet [2] (page 75) also confirm > that the low region is not IO coherent. > > So I think you would not be able to do DMA without flush the cache which > can be pretty expensive. For a PoC, it might be possible to force Linux > flushing the area before and after each DMA request. This should be > possible by marking the devices as not coherent. > > Although, I am not entirely sure if there is any fallout. > > @Dave, do you think it is possible for you to have a try? I can provide > the patch for Linux to disable DMA coherency if possible. I attempted to do that, where I removed the "dma-coherent" flags from the device tree. There are likely other issues, but the most glaring problem that I ran into is that the ethernet does not work. Eth0 shows up in ifconfig but there is no activity on it after a small handful of message exchanges, whereas booting without Xen it seems to work fine even if left in 32-bit mode (with the dma-coherent disabled). I don't know what implications behind the scenes there are trying to stay in the lower 0x8000_0000 alias range either though. I would rather run it as intended by switching to the upper 0x8_0000_0000 alias region. > > For a proper solution, I think we need to implement something similar to > what I wrote earlier. > > Cheers, > > [1] 5eb3da7246a5b2dfac9f38a7be62b1a0295584c7 > [2] https://www.ti.com/lit/ds/symlink/tci6638k2k.pdf?ts=3D1591183242813 > > > -- > Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:08:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:08:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgofG-0001Xq-BC; Thu, 04 Jun 2020 12:08:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgofF-0001Xj-9s for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:08:05 +0000 X-Inumbo-ID: 0aa5d84c-a65c-11ea-ae6e-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0aa5d84c-a65c-11ea-ae6e-12813bfff9fa; Thu, 04 Jun 2020 12:08:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ToApL6M3YpuTxJGQ/fa/KnrLblFVeDhK9sd/egpbrx0=; b=4wnPiAeDjwGsorvFS7FkejL7XO qiyeY4lb5p/qnDwq9HeGS3DI+dmai0aAXP+bxkCzNq3ttIepjgKZqoS94Hvth4rZrMSbs3bau5+SL wLDHiyR3Cy4dNWmby9XxR/uyT0CJdh465OrByIk8EDDEKc85dsJyDUbwnTtDm7v1D4Ig=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgofB-0003ma-FU; Thu, 04 Jun 2020 12:08:01 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgofB-0003u2-8m; Thu, 04 Jun 2020 12:08:01 +0000 Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: cminyard@mvista.com References: <20200603223156.12767-1-sstabellini@kernel.org> <20200604001552.GC2903@minyard.net> <50ad4bca-5eb8-8db0-0aae-dc7febfdb56a@xen.org> <20200604115907.GD2903@minyard.net> From: Julien Grall Message-ID: <14d94375-c895-a8ae-c083-59ff8296b308@xen.org> Date: Thu, 4 Jun 2020 13:07:59 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200604115907.GD2903@minyard.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , tamas@tklengyel.com, roman@zededa.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 12:59, Corey Minyard wrote: > On Thu, Jun 04, 2020 at 09:15:33AM +0100, Julien Grall wrote: >> Hi, >> >> On 04/06/2020 01:15, Corey Minyard wrote: >>> On Wed, Jun 03, 2020 at 03:31:56PM -0700, Stefano Stabellini wrote: >>>> Touching the watchdog is required to be able to reboot the board. >>>> >>>> The implementation is based on >>>> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. >>> >>> Ah, I was looking at this just today, as it had been annoying me >>> greatly. This works for me, so: >>> >>> Tested-by: Corey Minyard >>> >>> However, I was wondering if it might be better to handle this by failing >>> the operation in xen and passing it back to dom0 to do. On the Pi you >>> send a firmware message to reboot, and that seems like too much to do in >>> Xen, but it would seem possible to send this back to dom0. >> I don't think this is possible in the current setup. Xen will usually >> restart the platform if Dom0 requested a clean reboot or crashed. So the >> domain wouldn't be in state to service such call. > > Ok, I hadn't looked at Xen yet, I didn't know how much shutdown of dom0 > happens on a reset. > >> >>> Just a >>> thought, as it might be a more general fix for other devices in the same >>> situation. >> >> What are the devices you have in mind? > > Nothing in particular, but other systems might have the same issue. I > guess you have ACPI implemented on x86 already. It just seemed that > Linux already has to be able to do this, and passing the buck back there > might be a more general solution. I don't really see how you can make a generic solution here. Each devices may have a different way to act. For anything related to power control, the right solution is to implement PSCI/SCMI in your firmware so you don't need to rely on Dom0 (which may not exist) for such thing. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:36:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:36:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgp6l-0004Q4-CU; Thu, 04 Jun 2020 12:36:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgp6j-0004Pz-Og for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:36:29 +0000 X-Inumbo-ID: 02f2fc52-a660-11ea-ae73-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 02f2fc52-a660-11ea-ae73-12813bfff9fa; Thu, 04 Jun 2020 12:36:29 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4A43AAC4A; Thu, 4 Jun 2020 12:36:31 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: Andrew Cooper References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> From: Jan Beulich Message-ID: Date: Thu, 4 Jun 2020 14:36:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.2020 13:13, Andrew Cooper wrote: > On 04/06/2020 08:08, Jan Beulich wrote: >> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: >>> Then, we get the main issue: >>> >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff >>> (XEN) domain_crash called from io.c:178 >>> >>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom >>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. >> I'd guess an issue with the shutdown deferral logic. Did you / can >> you check whether XEN_DMOP_remote_shutdown managed to pause all >> CPUs (I assume it didn't, since once they're paused there shouldn't >> be any I/O there anymore, and hence no I/O emulation)? > > The vcpu in question is talking to Qemu, so will have v->defer_shutdown > intermittently set, and skip the pause in domain_shutdown() > > I presume this lack of pause is to allow the vcpu in question to still > be scheduled to consume the IOREQ reply?  (Its fairly opaque logic with > 0 clarifying details). > > What *should* happen is that, after consuming the reply, the vcpu should > notice and pause itself, at which point it would yield to the > scheduler.  This is the purpose of vcpu_{start,end}_shutdown_deferral(). > > Evidentially, this is not happening. We can't tell yet, until ... > Marek: can you add a BUG() after the weird PIO printing?  That should > confirm whether we're getting into handle_pio() via the > handle_hvm_io_completion() path, or via the vmexit path (at which case, > we're fully re-entering the guest). ... we know this. handle_pio() gets called from handle_hvm_io_completion() after having called hvm_wait_for_io() -> hvm_io_assist() -> vcpu_end_shutdown_deferral(), so the issue may be that we shouldn't call handle_pio() (etc) at all anymore in this state. IOW perhaps hvm_wait_for_io() should return "!sv->vcpu->domain->is_shutting_down" instead of plain "true"? Adding Paul to Cc, as being the maintainer here. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:37:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:37:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgp84-0004Un-Na; Thu, 04 Jun 2020 12:37:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgp83-0004Uf-Mx for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:37:51 +0000 X-Inumbo-ID: 30eba5aa-a660-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 30eba5aa-a660-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 12:37:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z6on047sTkTqf7RK7HnpG17kjSpIkAEN+hNO252eXns=; b=l+Iw7lU1v0RFZmh6LJVzivyi8 g9PCJ85k378VdtL46Wc50Pj3SrCKlt/dbZFg2YUJ5zC1AqIEdjQz7UpcvFcwkwoEotiH0+tkCSQhV xow2JTQ32ovPLVqN3nHBRQVCV9AJzD2Dalk/4u+I2qvKzFR593J4S4zoPwONh+thrzGEQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgp7w-0004NE-Rd; Thu, 04 Jun 2020 12:37:44 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgp7w-00009u-8Z; Thu, 04 Jun 2020 12:37:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgp7w-0002nI-7u; Thu, 04 Jun 2020 12:37:44 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150690: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d9f58cd54fe2f05e1f05e2fe254684bd1840de8e X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Thu, 04 Jun 2020 12:37:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150690 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150690/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d9f58cd54fe2f05e1f05e2fe254684bd1840de8e baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 6 days Failing since 150465 2020-05-29 09:02:14 Z 6 days 45 attempts Testing same since 150649 2020-06-03 13:01:44 Z 0 days 7 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1522 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:45:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:45:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpF4-0005VX-FN; Thu, 04 Jun 2020 12:45:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpF2-0005VR-Dw for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:45:04 +0000 X-Inumbo-ID: 35bab20a-a661-11ea-9947-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 35bab20a-a661-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 12:45:03 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jgpF0-0006vr-PK; Thu, 04 Jun 2020 13:45:02 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 0/4] bisection: Skip some useless repros Date: Thu, 4 Jun 2020 13:44:55 +0100 Message-Id: <20200604124459.18453-1-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This arranges for an ongoing bisection to be able to restart more efficiently when the staging tip advances, and yet the test being bisected still fails. This will speed up the current osstest bisection of the smoke test libvirt failure. There are no code changes outside the bisector and the bisector is not itself subject to the osstest self-test. I am therefore going to force-push these four changes straight into osstest production. (Obviously I have tested them locally and seen that bisection still basically works and also that this fixes the issue.) Ian Jackson (4): cs-bisection-step: need_repro_sequence: Provide info to callback cs-bisection-step: need_repro: Provision for $xinfo cs-bisection-step: need_repro: Support $consider_parents cs-bisection-step: Do not needlessly repro on tip cs-bisection-step | 34 ++++++++++++++++++++++++++++------ 1 file changed, 28 insertions(+), 6 deletions(-) -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:45:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:45:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpF8-0005W0-OH; Thu, 04 Jun 2020 12:45:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpF7-0005Vi-E5 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:45:09 +0000 X-Inumbo-ID: 36fed506-a661-11ea-81bc-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 36fed506-a661-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 12:45:05 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jgpF2-0006vr-U6; Thu, 04 Jun 2020 13:45:05 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 2/4] cs-bisection-step: need_repro: Provision for $xinfo Date: Thu, 4 Jun 2020 13:44:57 +0100 Message-Id: <20200604124459.18453-3-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200604124459.18453-1-ian.jackson@eu.citrix.com> References: <20200604124459.18453-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This becomes part of the message but right now it is juse "". So no functional change yet. Signed-off-by: Ian Jackson --- cs-bisection-step | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cs-bisection-step b/cs-bisection-step index 35085e89..90e0601a 100755 --- a/cs-bisection-step +++ b/cs-bisection-step @@ -828,6 +828,7 @@ sub need_repro ($$$) { return 1 if conflicted_warning($n, $what); my $fl= $n->{Flights} || []; + my $xinfo=''; foreach my $f (sort { $a->{Flight} <=> $b->{Flight} } @$fl) { next unless $f->{Flight} > $repro_lastflight; if ($f->{Result} ne $st) { @@ -837,7 +838,7 @@ sub need_repro ($$$) { } print STDERR " ". ($repro_count ? "Repro" : "Result"). - " found: flight $f->{Flight} ($st), for $what\n"; + " found: flight $f->{Flight} ($st), for $what$xinfo\n"; $repro_lastflight= $f->{Flight}; $repro_firstflight ||= $f->{Flight}; return 0; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:45:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:45:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpFD-0005XU-0d; Thu, 04 Jun 2020 12:45:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpFC-0005XL-C0 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:45:14 +0000 X-Inumbo-ID: 371a3fa8-a661-11ea-9947-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 371a3fa8-a661-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 12:45:05 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jgpF3-0006vr-5i; Thu, 04 Jun 2020 13:45:05 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 3/4] cs-bisection-step: need_repro: Support $consider_parents Date: Thu, 4 Jun 2020 13:44:58 +0100 Message-Id: <20200604124459.18453-4-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200604124459.18453-1-ian.jackson@eu.citrix.com> References: <20200604124459.18453-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This flag tells need_repro to look at parent commits of the indicated rtuple node, as well as the node itself. We walk up the tree. If there are multiple parents, we stop; likewise if we find any rtuple which doesn't have the expected results. Signed-off-by: Ian Jackson --- cs-bisection-step | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/cs-bisection-step b/cs-bisection-step index 90e0601a..bc6fb794 100755 --- a/cs-bisection-step +++ b/cs-bisection-step @@ -822,13 +822,31 @@ sub need_repro_sequence ($$) { } } -sub need_repro ($$$) { - my ($st, $n, $what) = @_; +sub need_repro ($$$;$) { + my ($st, $n, $what, $consider_parents) = @_; return 1 if conflicted_warning($n, $what); my $fl= $n->{Flights} || []; my $xinfo=''; + if ($consider_parents) { + $fl = [ @$fl ]; + my $nloop = $n; + my $iters = 0; + for (;;) { + last unless @{ $nloop->{Parents} } == 1; + $nloop = $nloop->{Parents}[0]; + $iters++; + $xinfo = " (at ancestor ~$iters)"; + my @others = grep { $_->{Result} ne $st } @{ $nloop->{Flights} }; + if (@others) { + print STDERR + " For $what, parent search stopping at $nloop->{Rtuple}, results @others"; + } + push @$fl, @{ $nloop->{Flights} }; + } + } + foreach my $f (sort { $a->{Flight} <=> $b->{Flight} } @$fl) { next unless $f->{Flight} > $repro_lastflight; if ($f->{Result} ne $st) { -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:45:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:45:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpFI-0005Ze-Bq; Thu, 04 Jun 2020 12:45:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpFH-0005ZI-Cc for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:45:19 +0000 X-Inumbo-ID: 36dc180e-a661-11ea-81bc-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 36dc180e-a661-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 12:45:05 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jgpF2-0006vr-Nt; Thu, 04 Jun 2020 13:45:04 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 1/4] cs-bisection-step: need_repro_sequence: Provide info to callback Date: Thu, 4 Jun 2020 13:44:56 +0100 Message-Id: <20200604124459.18453-2-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200604124459.18453-1-ian.jackson@eu.citrix.com> References: <20200604124459.18453-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This will be used by the callback in a moment. No functional change yet. Signed-off-by: Ian Jackson --- cs-bisection-step | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/cs-bisection-step b/cs-bisection-step index 478baa5b..35085e89 100755 --- a/cs-bisection-step +++ b/cs-bisection-step @@ -805,7 +805,8 @@ our $repro_count; sub need_repro_sequence ($$) { my ($need_each, $code) = @_; # - # $code->() should call, in turn for each required event, + # $code->($repro_count, $is_last_repro) + # should call, in turn for each required event, # need_repro('pass', $nodes{SOMETHING}, $what) or # need_repro('fail', $nodes{SOMETHING}, $what) # and return true as soon as any of the need_repro's return true. @@ -817,7 +818,7 @@ sub need_repro_sequence ($$) { local ($repro_lastflight) = 0; local ($repro_count); for ($repro_count=0; $repro_count<$need_each; $repro_count++) { - return 1 if $code->(); + return 1 if $code->($repro_count, $repro_count==$need_each-1); } } @@ -851,6 +852,7 @@ sub search () { return if need_repro_sequence(2, sub { + my ($repro_count, $is_last_repro) = @_; need_repro('pass', $nodes{"@basispass_rtuple"}, "basis pass") || need_repro('fail', $nodes{"@latest_rtuple"}, "basis failure"); }); -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:45:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:45:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpFN-0005c6-L8; Thu, 04 Jun 2020 12:45:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpFM-0005bg-Bn for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:45:24 +0000 X-Inumbo-ID: 3745003a-a661-11ea-9947-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3745003a-a661-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 12:45:06 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jgpF3-0006vr-Bn; Thu, 04 Jun 2020 13:45:05 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 4/4] cs-bisection-step: Do not needlessly repro on tip Date: Thu, 4 Jun 2020 13:44:59 +0100 Message-Id: <20200604124459.18453-5-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200604124459.18453-1-ian.jackson@eu.citrix.com> References: <20200604124459.18453-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" If we were halfway through bisecting, we treat the incident failure as the basis failure. But our previous bisection results can count as indications that things are really failing - we don't need to repro on the very final commit. Signed-off-by: Ian Jackson --- cs-bisection-step | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cs-bisection-step b/cs-bisection-step index bc6fb794..9a0fee39 100755 --- a/cs-bisection-step +++ b/cs-bisection-step @@ -873,7 +873,8 @@ sub search () { need_repro_sequence(2, sub { my ($repro_count, $is_last_repro) = @_; need_repro('pass', $nodes{"@basispass_rtuple"}, "basis pass") || - need_repro('fail', $nodes{"@latest_rtuple"}, "basis failure"); + need_repro('fail', $nodes{"@latest_rtuple"}, "basis failure", + !$is_last_repro); }); foreach my $startfail (@failures) { -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 04 12:51:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 12:51:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpKt-0006pv-9W; Thu, 04 Jun 2020 12:51:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpKs-0006pq-0X for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 12:51:06 +0000 X-Inumbo-ID: 0c3e3f40-a662-11ea-ae76-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0c3e3f40-a662-11ea-ae76-12813bfff9fa; Thu, 04 Jun 2020 12:51:04 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: puB0HrZYKQcJ/e6j5iky5ms+gFHd3m9ro5GG+Zfs4IvWBR9ap5dfGMcja46rRfWZhIigt/yWfK bbRsZujuRBk/8FLJ16O4tRdUzy/1xPbj10d7YsX/l4DTN8vsN3k+By5SftsRDMfNuV9lmSc5Fx ZGgXDk3qB6Yvrs+oTAXIwxgwQLKCv+nVi34lNdaprxzd37JLjLfXdL0xVx4cZnO54ZyhxJrPVd m771OMwHqAmVPT+EfcX3BqLrwY+eOi1vRoQMFuprHfnhuTr+7jDwp3r7k9VLESl3yqHtCKFSN2 ZTw= X-SBRS: 2.7 X-MesageID: 19971885 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="19971885" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24280.60980.488961.267238@mariner.uk.xensource.com> Date: Thu, 4 Jun 2020 13:51:00 +0100 To: Jim Fehlig Subject: Re: [libvirt test] 149773: regressions - FAIL In-Reply-To: <7c47a937-551f-2c7a-edd3-8b172155a506@suse.com> References: <7c47a937-551f-2c7a-edd3-8b172155a506@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , osstest service owner Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jim Fehlig writes ("Re: [libvirt test] 149773: regressions - FAIL"): > On 4/24/20 3:53 AM, osstest service owner wrote: > > flight 149773 libvirt real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/149773/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > build-amd64-libvirt 6 libvirt-build fail REGR. vs. 146182 > > build-i386-libvirt 6 libvirt-build fail REGR. vs. 146182 > > build-arm64-libvirt 6 libvirt-build fail REGR. vs. 146182 > > build-armhf-libvirt 6 libvirt-build fail REGR. vs. 146182 > > Probably best to disable these tests to avoid all the spam. I have fixed the build bug now... Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 04 13:31:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 13:31:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpxM-0002Nr-JC; Thu, 04 Jun 2020 13:30:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgpxL-0002Nl-1f for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 13:30:51 +0000 X-Inumbo-ID: 9ac63d76-a667-11ea-9947-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9ac63d76-a667-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 13:30:50 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: XE7ialVyZEW8eWC7san8djLnSSs3Mf4xl9IuDfkBvl91ONgwbprqOHlnc26hz5SO7BFPX974Uv gfyrC2PSOCFNdBeLraRWrSWDzYW5M33JsI2b2jM6rI7ewWZjBpYhJt7Seq2DJS0q8kMpLRbXq3 Bnw6rhgUNg15FOM5RbFOoRl42owJERjY56GgtUgQp0zC2TOZ0P4Dye5KbaefC4Oi4NG+tFi38P 4kBEJfb/MXOvw+7oXWy8dzyOaSvJ10c3t3NZSs2Huij9fMbEZS5TIQaTlhN0wwmRbOwh4xlpEV QuU= X-SBRS: 2.7 X-MesageID: 19475987 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="19475987" From: Anthony PERARD To: , Paolo Bonzini Subject: [PATCH v4] xen: fix build without pci passthrough Date: Thu, 4 Jun 2020 14:30:42 +0100 Message-ID: <20200604133042.3380585-1-anthony.perard@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <159120627656.23398.3742621530752770397@45ef0f9c86ae> References: <159120627656.23398.3742621530752770397@45ef0f9c86ae> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Paul Durrant , "Michael S. Tsirkin" , Marcel Apfelbaum , Anthony PERARD , xen-devel@lists.xenproject.org, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Xen PCI passthrough support may not be available and thus the global variable "has_igd_gfx_passthru" might be compiled out. Common code should not access it in that case. Unfortunately, we can't use CONFIG_XEN_PCI_PASSTHROUGH directly in xen-common.c so this patch instead move access to the has_igd_gfx_passthru variable via function and those functions are also implemented as stubs. The stubs will be used when QEMU is built without passthrough support. Now, when one will want to enable igd-passthru via the -machine property, they will get an error message if QEMU is built without passthrough support. Fixes: 46472d82322d0 ('xen: convert "-machine igd-passthru" to an accelerator property') Reported-by: Roger Pau Monné Signed-off-by: Anthony PERARD Acked-by: Paul Durrant Tested-by: Roger Pau Monné --- Notes: v4: - fix build when Xen headers aren't available. By building stubs/xen-pt.c only when CONFIG_XEN=y (The alternative would be to move the prototypes used by the stub into xen.h, which doesn't depends on xen headers.) Changes in v3: - reworked to use stubs instead of #ifdef CONFIG_XEN_PCI_PASSTHROUGH CONFIG_XEN_PCI_PASSTHROUGH isn't available in xen-common.c moving CONFIG_XEN_PCI_PASSTHROUGH to be in config_host_mak isn't really possible, or at least I didn't managed to make that work. hw/i386/pc_piix.c | 2 +- hw/xen/xen-common.c | 4 ++-- hw/xen/xen_pt.c | 12 +++++++++++- hw/xen/xen_pt.h | 6 ++++-- stubs/Makefile.objs | 1 + stubs/xen-pt.c | 22 ++++++++++++++++++++++ 6 files changed, 41 insertions(+), 6 deletions(-) create mode 100644 stubs/xen-pt.c diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index f66e1d73ce0b..347fb8c6c807 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -375,7 +375,7 @@ static void pc_init_isa(MachineState *machine) #ifdef CONFIG_XEN static void pc_xen_hvm_init_pci(MachineState *machine) { - const char *pci_type = has_igd_gfx_passthru ? + const char *pci_type = xen_igd_gfx_pt_enabled() ? TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : TYPE_I440FX_PCI_DEVICE; pc_init1(machine, diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c index 70564cc952d5..dd2c22cc4c0b 100644 --- a/hw/xen/xen-common.c +++ b/hw/xen/xen-common.c @@ -129,12 +129,12 @@ static void xen_change_state_handler(void *opaque, int running, static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp) { - return has_igd_gfx_passthru; + return xen_igd_gfx_pt_enabled(); } static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error **errp) { - has_igd_gfx_passthru = value; + xen_igd_gfx_pt_set(value, errp); } static void xen_setup_post(MachineState *ms, AccelState *accel) diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index 81d5ad8da7f0..ab84443d5ec8 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -65,7 +65,17 @@ #include "qemu/range.h" #include "exec/address-spaces.h" -bool has_igd_gfx_passthru; +static bool has_igd_gfx_passthru; + +bool xen_igd_gfx_pt_enabled(void) +{ + return has_igd_gfx_passthru; +} + +void xen_igd_gfx_pt_set(bool value, Error **errp) +{ + has_igd_gfx_passthru = value; +} #define XEN_PT_NR_IRQS (256) static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0}; diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h index 179775db7b22..6e9cec95f3b7 100644 --- a/hw/xen/xen_pt.h +++ b/hw/xen/xen_pt.h @@ -5,6 +5,9 @@ #include "hw/pci/pci.h" #include "xen-host-pci-device.h" +bool xen_igd_gfx_pt_enabled(void); +void xen_igd_gfx_pt_set(bool value, Error **errp); + void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3); #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a) @@ -322,10 +325,9 @@ extern void *pci_assign_dev_load_option_rom(PCIDevice *dev, unsigned int domain, unsigned int bus, unsigned int slot, unsigned int function); -extern bool has_igd_gfx_passthru; static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev) { - return (has_igd_gfx_passthru + return (xen_igd_gfx_pt_enabled() && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA)); } int xen_pt_register_vga_regions(XenHostPCIDevice *dev); diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs index 6a9e3135e8f9..e0427158132f 100644 --- a/stubs/Makefile.objs +++ b/stubs/Makefile.objs @@ -40,6 +40,7 @@ stub-obj-y += target-get-monitor-def.o stub-obj-y += vmgenid.o stub-obj-y += xen-common.o stub-obj-y += xen-hvm.o +stub-obj-$(CONFIG_XEN) += xen-pt.o stub-obj-y += pci-host-piix.o stub-obj-y += ram-block.o stub-obj-y += ramfb.o diff --git a/stubs/xen-pt.c b/stubs/xen-pt.c new file mode 100644 index 000000000000..2d8cac8d54b9 --- /dev/null +++ b/stubs/xen-pt.c @@ -0,0 +1,22 @@ +/* + * Copyright (C) 2020 Citrix Systems UK Ltd. + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" +#include "hw/xen/xen_pt.h" +#include "qapi/error.h" + +bool xen_igd_gfx_pt_enabled(void) +{ + return false; +} + +void xen_igd_gfx_pt_set(bool value, Error **errp) +{ + if (value) { + error_setg(errp, "Xen PCI passthrough support not built in"); + } +} -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Thu Jun 04 14:13:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 14:13:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgqc1-0006By-OK; Thu, 04 Jun 2020 14:12:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgqc1-0006Bt-1l for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 14:12:53 +0000 X-Inumbo-ID: 799c51c0-a66d-11ea-8993-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 799c51c0-a66d-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 14:12:51 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: r7lOM1xHIpM87SQ0kT3E1TYuTair+lwl4sJwUNQoAHk1W+k5+iTppNTfEMAPNN+EAw9DZgyUlw ZJD9zwmCSVS8KEVaWvhwIhuj/iEwwrndr79c5SNqaraplltwwCrWiA9GuXtSGMkT3kwRujXOia 2UtlxMW5TG2t6BGqkb/nfyvGydSFXLEsx05SzAv9qoDjYEAdbNufJk5/bKOYa518Gz5ImvYPHo CWr17MqI4pJDUojKIudlgrLH3OdE9ByeOwHX9u16IKUl7bigdaGf3Bm5f5pRY34S1F6+/cKRhY qCo= X-SBRS: 2.7 X-MesageID: 19251302 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="19251302" From: Andrew Cooper To: Subject: [PATCH XTF] vsnprintf: Expand \n to \r\n for console output Date: Thu, 4 Jun 2020 15:12:23 +0100 Message-ID: <20200604141223.14153-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Pawel Wieczorkiewicz , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" xenconsoled doesn't automatically convert \n into \r\n, which causes test output appear like this in a terminal: [root@host ~]# xl create -c tests/selftest/test-pv64-selftest.cfg Parsing config from tests/selftest/test-pv64-selftest.cfg --- Xen Test Framework --- Environment: PV 64bit (Long mode 4 levels) XTF Selftests There are a number of ways to do this, but by far the most efficient way is to have vsnprintf() expand \n's in the output buffer. This however is non-standard behaviour for vsnprintf(). Rename it to vsnprintf_internal() and take extra flags, and have vprintk() use the new LF_TO_CRLF control flag. Inside vsnprintf_internal(), rearrange the non-format and %c logic to share the expansion logic, as well as extending the logic to fmt_string(). Extend the selftests to confirm correct behaviour in both modes, for all ways of being able to pass newline characters into a format operation. Reported-by: Pawel Wieczorkiewicz Signed-off-by: Andrew Cooper --- Pawel: Does this fix the issues you were seeing? --- common/console.c | 2 +- common/libc/vsnprintf.c | 23 +++++++++++++++-------- include/xtf/libc.h | 15 ++++++++++++++- tests/selftest/main.c | 38 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 68 insertions(+), 10 deletions(-) diff --git a/common/console.c b/common/console.c index 0724fc9f..b3e89473 100644 --- a/common/console.c +++ b/common/console.c @@ -122,7 +122,7 @@ void vprintk(const char *fmt, va_list args) unsigned int i; int rc; - rc = vsnprintf(buf, sizeof(buf), fmt, args); + rc = vsnprintf_internal(buf, sizeof(buf), fmt, args, LF_TO_CRLF); if ( rc > (int)sizeof(buf) ) panic("vprintk() buffer overflow\n"); diff --git a/common/libc/vsnprintf.c b/common/libc/vsnprintf.c index a49fd308..c907d42b 100644 --- a/common/libc/vsnprintf.c +++ b/common/libc/vsnprintf.c @@ -47,6 +47,7 @@ static int isdigit(int c) /* Conversions */ #define UPPER (1u << 5) #define SIGNED (1u << 6) +/* Careful not to overlap with vsnprintf_internal() flags. */ /* Shorthand for ensuring str moves forwards, but not overruning the buffer. */ #define PUT(c) \ @@ -185,7 +186,11 @@ char *fmt_string(char *str, char *end, const char *val, PUT(' '); for ( i = 0; i < len; ++i ) + { + if ( (flags & LF_TO_CRLF) && val[i] == '\n' ) + PUT('\r'); PUT(val[i]); + } while ( len < width-- ) PUT(' '); @@ -268,7 +273,8 @@ static char *pointer( width, precision, flags); } -int vsnprintf(char *buf, size_t size, const char *fmt, va_list args) +int vsnprintf_internal(char *buf, size_t size, const char *fmt, va_list args, + unsigned int caller_flags) { char *str = buf, *end = buf + size; @@ -277,15 +283,15 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args) const char *spec_start = fmt; /* For rewinding on error. */ unsigned long long num; - unsigned int base, flags = 0; + unsigned int base, flags = caller_flags; int width = -1, precision = -1; - char length_mod = 'i'; + char c, length_mod = 'i'; /* Put regular characters into the destination. */ if ( *fmt != '%' ) { - PUT(*fmt); - continue; + c = *fmt; + goto put_char; } next_flag: /* Process any flags. */ @@ -359,20 +365,21 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args) continue; case 'c': /* Unsigned char. */ - { - unsigned char c = va_arg(args, int); + c = va_arg(args, int); if ( !(flags & LEFT) ) while ( --width > 0 ) PUT(' '); + put_char: + if ( (flags & LF_TO_CRLF) && c == '\n' ) + PUT('\r'); PUT(c); while ( --width > 0 ) PUT(' '); continue; - } case 's': /* String. */ str = fmt_string(str, end, va_arg(args, const char *), diff --git a/include/xtf/libc.h b/include/xtf/libc.h index 66f834b4..f24a631f 100644 --- a/include/xtf/libc.h +++ b/include/xtf/libc.h @@ -37,8 +37,21 @@ int memcmp(const void *s1, const void *s2, size_t n); size_t strnlen(const char *str, size_t max); +/* + * Internal version of vsnprintf(), taking extra control flags. + * + * LF_TO_CRLF causes "\n" to be expanded to "\r\n" in the output buffer. + */ +#define LF_TO_CRLF (1u << 7) int __printf(3, 0) - vsnprintf(char *buf, size_t size, const char *fmt, va_list args); + vsnprintf_internal(char *buf, size_t size, const char *fmt, va_list args, + unsigned int flags); + +static inline int __printf(3, 0) + vsnprintf(char *buf, size_t size, const char *fmt, va_list args) +{ + return vsnprintf_internal(buf, size, fmt, args, 0); +} int __printf(3, 4) snprintf(char *buf, size_t size, const char *fmt, ...); diff --git a/tests/selftest/main.c b/tests/selftest/main.c index c2f6e727..a5c205ba 100644 --- a/tests/selftest/main.c +++ b/tests/selftest/main.c @@ -340,6 +340,43 @@ static void test_driver_init(void) xtf_failure("Fail: xtf_init_grant_table(2) returned %d\n", rc); } +static void test_vsnprintf_crlf_one(const char *fmt, ...) +{ + va_list args; + + char buf[4]; + int rc; + + va_start(args, fmt); + rc = vsnprintf(buf, sizeof(buf), fmt, args); + va_end(args); + + if ( rc != 1 ) + return xtf_failure("Fail: '%s', expected length 1, got %d\n", fmt, rc); + if ( strcmp(buf, "\n") ) + return xtf_failure("Fail: '%s', expected \"\\n\", got %*ph\n", + fmt, (int)sizeof(buf), buf); + + va_start(args, fmt); + rc = vsnprintf_internal(buf, sizeof(buf), fmt, args, LF_TO_CRLF); + va_end(args); + + if ( rc != 2 ) + return xtf_failure("Fail: '%s', expected length 2, got %d\n", fmt, rc); + if ( strcmp(buf, "\r\n") ) + return xtf_failure("Fail: '%s', expected \"\\r\\n\", got %*ph\n", + fmt, (int)sizeof(buf), buf); +} + +static void test_vsnprintf_crlf(void) +{ + printk("Test: vsnprintf() with CRLF expansion\n"); + + test_vsnprintf_crlf_one("\n"); + test_vsnprintf_crlf_one("%c", '\n'); + test_vsnprintf_crlf_one("%s", "\n"); +} + void test_main(void) { /* @@ -368,6 +405,7 @@ void test_main(void) test_extable_handler(); test_custom_idte(); test_driver_init(); + test_vsnprintf_crlf(); if ( has_xenstore ) test_xenstore(); -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Thu Jun 04 14:26:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 14:26:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgqoa-0007Ol-9Z; Thu, 04 Jun 2020 14:25:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgqoY-0007Of-6e for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 14:25:50 +0000 X-Inumbo-ID: 4946ae60-a66f-11ea-ae9c-12813bfff9fa Received: from wout2-smtp.messagingengine.com (unknown [64.147.123.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4946ae60-a66f-11ea-ae9c-12813bfff9fa; Thu, 04 Jun 2020 14:25:49 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 1C164588; Thu, 4 Jun 2020 10:25:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 04 Jun 2020 10:25:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=bDtBHF WaN5CLSwkbqcp31cYLJxcUXX1vGtm06j7NDQQ=; b=uKTgCnmN7iQXfXMCIL4Bqp cCdDUzvrSnkR/3trM0rC68KaeGQUQN8S+OH/El4NSCu8CncirLzAvGVTACxMpr2S GOgcc+PZdvWLnZnqFu7eAgFSA6uZtVd5QDS6tw28D7lBMLPzB0nRQwK4tJi9Zm10 qquljhxHt+6J+NTMRzpkI4+8/7GwYNdbZ23IfPQOEevLl3x0XWY9zDnaw2VYRaYG TFejM1uBNkwmjHoF+oK2O2aq6R8NXKRBDGwWzl80IZvJZdEY1rjkmt7AyuDIJp9i uoRIKLiNJ5CSSBqvXg2RhqxCMNY9rtuFPP6RQQ9DwjdqHGbvm9g2UYRWi69IyvjQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeguddgjeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeetveff iefghfekhffggeeffffhgeevieektedthfehveeiheeiiedtudegfeetffenucfkpheple durdeihedrfeegrdeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd gtohhm X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 7E696328005D; Thu, 4 Jun 2020 10:25:46 -0400 (EDT) Date: Thu, 4 Jun 2020 16:25:42 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Message-ID: <20200604142542.GC98582@mail-itl> References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+RqgOR8y65RRYhVY" Content-Disposition: inline In-Reply-To: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Paul Durrant , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --+RqgOR8y65RRYhVY Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: > On 04.06.2020 13:13, Andrew Cooper wrote: > > On 04/06/2020 08:08, Jan Beulich wrote: > >> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > >>> Then, we get the main issue: > >>> > >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > >>> (XEN) domain_crash called from io.c:178 > >>> > >>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stub= dom > >>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. > >> I'd guess an issue with the shutdown deferral logic. Did you / can > >> you check whether XEN_DMOP_remote_shutdown managed to pause all > >> CPUs (I assume it didn't, since once they're paused there shouldn't > >> be any I/O there anymore, and hence no I/O emulation)? > >=20 > > The vcpu in question is talking to Qemu, so will have v->defer_shutdown > > intermittently set, and skip the pause in domain_shutdown() > >=20 > > I presume this lack of pause is to allow the vcpu in question to still > > be scheduled to consume the IOREQ reply?=C2=A0 (Its fairly opaque logic= with > > 0 clarifying details). > >=20 > > What *should* happen is that, after consuming the reply, the vcpu should > > notice and pause itself, at which point it would yield to the > > scheduler.=C2=A0 This is the purpose of vcpu_{start,end}_shutdown_defer= ral(). > >=20 > > Evidentially, this is not happening. >=20 > We can't tell yet, until ... >=20 > > Marek: can you add a BUG() after the weird PIO printing?=C2=A0 That sho= uld > > confirm whether we're getting into handle_pio() via the > > handle_hvm_io_completion() path, or via the vmexit path (at which case, > > we're fully re-entering the guest). >=20 > ... we know this. handle_pio() gets called from handle_hvm_io_completion() > after having called hvm_wait_for_io() -> hvm_io_assist() -> > vcpu_end_shutdown_deferral(), so the issue may be that we shouldn't call > handle_pio() (etc) at all anymore in this state. IOW perhaps > hvm_wait_for_io() should return "!sv->vcpu->domain->is_shutting_down" > instead of plain "true"? >=20 > Adding Paul to Cc, as being the maintainer here. Got it, by sticking BUG() just before that domain_crash() in handle_pio(). And also vcpu 0 of both HVM domains do have v->defer_shutdown. (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. (XEN) d3v0 handle_pio port 0xb004 read 0x0000 (XEN) d3v0 handle_pio port 0xb004 read 0x0000 (XEN) d3v0 handle_pio port 0xb004 write 0x0001 (XEN) d3v0 handle_pio port 0xb004 write 0x2001 (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. (XEN) d1v0 handle_pio port 0xb004 read 0x0000 (XEN) d1v0 handle_pio port 0xb004 read 0x0000 (XEN) d1v0 handle_pio port 0xb004 write 0x0001 (XEN) d1v0 handle_pio port 0xb004 write 0x2001 (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 (XEN) d3v0 handle_pio port 0xb004 read 0x0000 (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff (XEN) Xen BUG at io.c:178 (XEN) ----[ Xen-4.13.0 x86_64 debug=3Dy Not tainted ]---- (XEN) CPU: 1 (XEN) RIP: e008:[] handle_pio+0x1e4/0x1e6 (XEN) RFLAGS: 0000000000010282 CONTEXT: hypervisor (d3v0) (XEN) rax: ffff8301ba6fffff rbx: 0000000000000002 rcx: 0000000000000000 (XEN) rdx: 0000000000000001 rsi: 000000000000000a rdi: ffff82d080438698 (XEN) rbp: ffff8301ba6ffe90 rsp: ffff8301ba6ffe58 r8: 0000000000000001 (XEN) r9: ffff8301ba6ffdc0 r10: 0000000000000001 r11: 000000000000000f (XEN) r12: 000000000000b004 r13: ffff8300bfcf1000 r14: 0000000000000001 (XEN) r15: ffff8300bfcf4000 cr0: 000000008005003b cr4: 00000000000006e0 (XEN) cr3: 00000000bebb8000 cr2: 00007d081d9b82a0 (XEN) fsb: 00007d081cafcb80 gsb: ffff9ae510c00000 gss: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen code around (handle_pio+0x1e4/0x1e6): (XEN) 03 09 00 e8 5b 83 f4 ff <0f> 0b 55 48 89 e5 e8 b2 f5 ff ff 48 85 c0 = 74 0f (XEN) Xen stack trace from rsp=3Dffff8301ba6ffe58: (XEN) 000000000000ffff ffff8300bfcfffff 000000000000007b ffff8301ba6ffef8 (XEN) ffff8300bfcf1000 ffff8300bfcf4000 0000000000000000 ffff8301ba6ffee8 (XEN) ffff82d0803128f1 00ff8301ba6ffec0 ffff82d08030c257 ffff8301ba6ffef8 (XEN) ffff8300bfcf1000 ffff8300bfcf4000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 00007cfe459000e7 ffff82d08031470b (XEN) 0000000000000010 0000000000000010 0000000000000010 ffffa92ec001fd0c (XEN) 000000000000b004 0000000000000010 0000000000000001 0000000000000000 (XEN) 0000000000000002 000000000000b004 ffffa92ec001fca4 0000000000000002 (XEN) 000000000000b004 ffffa92ec001fd0c 000000000000b004 0000beef0000beef (XEN) ffffffffaa5d43bf 000000bf0000beef 0000000000000046 ffffa92ec001fca0 (XEN) 000000000000beef 000000000000beef 000000000000beef 000000000000beef (XEN) 000000000000beef 0000e01000000001 ffff8300bfcf4000 000000313a1d6000 (XEN) 00000000000006e0 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 (XEN) Xen call trace: (XEN) [] R handle_pio+0x1e4/0x1e6 (XEN) [] F svm_vmexit_handler+0x97a/0x165b (XEN) [] F svm_stgi_label+0x8/0x18 (XEN)=20 (XEN)=20 (XEN) **************************************** (XEN) Panic on CPU 1: (XEN) Xen BUG at io.c:178 (XEN) **************************************** (XEN)=20 (XEN) Reboot in five seconds... --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --+RqgOR8y65RRYhVY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7ZBGUACgkQ24/THMrX 1yyfegf+NN6ftiu7aH5eyEwvj+jE9XK595wR39HTVkAnWUCu3vTMxe19rjtoSGCg LkxVgwtgO4IKpiVBcIl7U+pYnXuh95+/RsPDabuudKuMdIyw8rgoIMV3CtHf8EM0 SoxsyCHO9AIAHRogYykTpZECvm32YlWLV+bGEajb82BsdXSAe19EVKifbiOMEbXm +EQ/hchwTLFRCvBvQpco8WtkILhH/1H56/QE0Qf4ct0huaNpVPxlfVLzEIat6iNV HVV7lCb/h+HLF496t7G7tNnYgsnwxG6B8NqDl3YvgGUQEPWLMiW/QhdHSP7nVXwV 4lO1h1VeDdvEnu4dC6jEVJIaOa9PYQ== =Pwft -----END PGP SIGNATURE----- --+RqgOR8y65RRYhVY-- From xen-devel-bounces@lists.xenproject.org Thu Jun 04 15:27:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 15:27:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgrlQ-0004bw-MT; Thu, 04 Jun 2020 15:26:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgrlP-0004br-Nn for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 15:26:40 +0000 X-Inumbo-ID: c7dfac10-a677-11ea-aeac-12813bfff9fa Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.74]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c7dfac10-a677-11ea-aeac-12813bfff9fa; Thu, 04 Jun 2020 15:26:37 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YimXXOGgOnzg8mhXfJu/SvC6xmfuKVnoCGB8DlxRAp0nCmN4dj0faB4Rgb0ZhcM89f6rLeMVaMVFlwxHnysR9Ne8XRiBsb3VWG3k2o8dM2Nu1T8r7RnmRVbWx+OxKSCTVP6H93sJntiWFNGs+alS22c08FCWnWgI9ItAxphp/732Ze0vnpgdZTKwzHrK6Uu5ykegolZ+WNpnhAL9C/xBZXDklms+kAOJD6qM19okqCV1abHRFHQ1w/MHL092e+0sB2kMXQleon66piZyoP3JKufMLtMKwdGpOY5N65dsNxmpsybtrwr1b+EJflOL7IAkQIk5JbrmTTuwybYNJKLTLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JwytaLmNBen2071IMziFp2czcHYUHvt/1SiO5iMgFQw=; b=lgFGJcXABF7i2gZWTn4oMJyQxqoHEiqOuDgtj6C4Lvm+b3XGcVyFMqFVqJCXjTqzf1znBP4BkkwZVN8EF29eErPWyZD8e72DYVYKewdaNs/R/X7QXETKq5S73dzaPugVNWg3LuL8u9jsCLXGClzKO+osrOJ9V6cMaYoGKOvUZ45bv3Tm7RgTRkVk89xuKhgd86/gImF6318Km+RDR//t7ICtyM9ot9JlWCXZknliUjHt4aR/okJM3eDfPuTuettZCmE+HOTfcK5aq9ghuqp9Bf9rBJ+3PuAKgdZkqdEfRqRdV/1fq9/oFq6eW3kRyWMpF7QrHmbyt+yP46eMfyoBLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JwytaLmNBen2071IMziFp2czcHYUHvt/1SiO5iMgFQw=; b=DrwGVmMZQQ95ta6bfPfb/EZDnsC3wCuFxQAO7uzHBm6UX6LbWnZ9iXLyTG4cWMdWyu01ubEZUdmOwajSreGZ0dJds7hkSPJJVYXc67OPiysWb4KSxPHsuDLpExfwEboblb0vCBDq6Noa6jPhdn522OGBOhZ+xUB9YMPj5iUASnY= Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB6240.eurprd03.prod.outlook.com (2603:10a6:800:13d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 4 Jun 2020 15:26:36 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3066.019; Thu, 4 Jun 2020 15:26:36 +0000 From: Oleksandr Andrushchenko To: Peng Fan , Roman Shaposhnik , Xen-devel Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyQ== Date: Thu, 4 Jun 2020 15:26:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45869b7d-8152-4932-1970-08d8089bab6b x-ms-traffictypediagnostic: VI1PR03MB6240: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04244E0DC5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +IVdjqUZfWf3nhKxwkV6NOOOe3pUnOvdfoVY4PBmk+Xjkcm93LLPuotBbOf9RDNyfEi7MlNRwjopGL1aaUGdGqfl4tNr23iMxa01mOS7WGc05sVaQta34rzvzT7hqoWgkkKk9AgiBjaIX+PsCJVLvrkGH+YCVH6NXELQC8qGrCDusht4bFAGKHxlEI49Jm6Xp6T8bH16YgpkSDzybVKpaCz4Kepm34WROrB8zog18ksHjyBG2Wwi3YyoyNTnlLeHyVGx1L4OHkgCft9ZAy3Mcqb73msImi+eI7zjm6zVbINtPZNewt/uCn+6/2NjAPpixkKx0xfuYrkYdn1NAaUtfA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(136003)(346002)(376002)(8936002)(5660300002)(31696002)(6506007)(8676002)(86362001)(53546011)(54906003)(316002)(4326008)(110136005)(83380400001)(31686004)(71200400001)(36756003)(26005)(64756008)(6486002)(2616005)(76116006)(6512007)(66946007)(66556008)(2906002)(186003)(478600001)(66476007)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0whMbMqrj28v1ye2WvqHkZ4IvmX9In40HAk7kZz1RtnRnrP6S8ih+RPedgA2b/8AtKm86OeC3jtF+4HujiTLXYCGcWIFjo/56F+IFr+iZUzXbRzeCbu8N20hL1iISU4HDJukmI4NL9JiNg3hKMY4uFI1OhDjZjaaG/5pAaWkj9FwGHWxD6eZ5ojb9/+ms72ySp09uSHFm+HKFdyQD5P9nyG33SZklEkETPTFvWCyruEQa+cS6MPyDJWvoonLw0UaiwMv2PZHJGYEfLAEapglQ+juXNdsGc5kzjurslNPxbPxDkzCvAwqwu+Wlv6+7YnrOevGTMJu9qC0jwJxqr0yzp7prrJjPIWUgpKxGhz5rQVf+Yf/rodRTxdZRX5DVZZRCk37Y4mc5LZXPNaVV2W6vu6eG9vxNV0kPzQV23wrm3gjrsq8Kxc4k8pwoJorPRk8DRIdc955Gc3eIju2J73EQLkQAADQNjM167WuM7vLthM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <825F4633972D3C4099A8393F3656225B@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45869b7d-8152-4932-1970-08d8089bab6b X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 15:26:36.1131 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yVX2BbWA5fV7Ba/aQPs4I4oRW8RbuFDyqDeT/LqNVQJOyWiqVXtp9PvA2dAXN52grD1zi+MluC/xAMSu9diHr7zexuy6HEmrwwUwoK6Qq2wfV2aL/GrdBk2cxXgelj5a X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6240 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Nataliya Korovkina Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gNi80LzIwIDQ6NTcgQU0sIFBlbmcgRmFuIHdyb3RlOg0KPiBHcmFsbCA8anVsaWVuQHhlbi5v cmc+Ow0KPj4gTmF0YWxpeWEgS29yb3ZraW5hIDxtYWx1cy5icmFuZHl3aW5lQGdtYWlsLmNvbT4N Cj4+IFN1YmplY3Q6IFVFRkkgc3VwcG9ydCBpbiBBUk0gRG9tVXMNCj4gV2UgaGF2ZSBtYWRlIFUt Qm9vdCBydW4gaW5zaWRlIFhFTiBEb21VLCBidXQganVzdCBvbmx5IFBWIGNvbnNvbGUgcGFydCwN Cj4gbm90IGltcGxlbWVudCBvdGhlciBmcm9udGVuZCBkcml2ZXJzIGN1cnJlbnRseS4gV291bGQg dGhpcyBoZWxwIGZvciB5b3VyDQo+IGNhc2UgaWYgZW5hYmxlIEVGSSBpbiBVLUJvb3Q/DQoNCldl bGwsIHdlIGhhdmUgYSB3b3JraW5nIFBWIGJsb2NrIGltcGxlbWVudGF0aW9uIG9uIHRvcCBvZiB0 aGF0IG9uIGlNWDgNCg0KcGxhdGZvcm0sIG1vc3RseSBwb3J0ZWQgZnJvbSBtaW5pLW9zLiBDdXJy ZW50bHkgd2UgYXJlIGZpbmFsaXppbmcgdGhlIHdvcmsNCg0KYW5kIGNsZWFuaW5nIHVwIChpdCdz IGdvaW5nIHRvIHRha2UgYSB3ZWVrIG9yIHNvIGhvcGVmdWxseSkuIFRoZW4sIHdlIHdlJ2xsIHBv c3QNCg0KaXQgb24gb3VyIHB1YmxpYyBnaXRodWIuIFdlIGFyZSBhbHNvIHRoaW5raW5nIGFib3V0 IHVwc3RyZWFtaW5nIHRoZSB3b3JrLCBidXQgaXQgbWF5DQoNCnRha2UgcXVpdGUgc29tZSB0aW1l IGlmIHRoZSB3aG9sZSBpZGVhIGZpdHMgdS1ib290J3MgdmlldyBvbiBzdWNoIGFuIGV4dGVuc2lv biBhdCBhbGwuDQoNClJlZ2FyZHMsDQoNCk9sZWtzYW5kcg0KDQo+IFJlZ2FyZHMsDQo+IFBlbmcu DQo+DQo+PiBIaSENCj4+DQo+PiB3aXRoIGEgbG90IG9mIGhlbHAgZnJvbSBTdGVmYW5vLCB3ZSdy ZSBnZXR0aW5nIFJQaTQgc3VwcG9ydCBpbiBQcm9qZWN0IEVWRQ0KPj4gcHJldHR5IG11Y2ggb24g cGFyIGJldHdlZW4gS1ZNIGFuZCBYZW4uDQo+Pg0KPj4gT25lIGJpZyBhcmVhIHRoYXQgc3RpbGwg cmVtYWlucyBpcyBzdXBwb3J0aW5nIFVFRkkgYm9vdCBzZXF1ZW5jZSBmb3IgRG9tVXMuDQo+PiBX aXRoIEtWTSwgZ2l2ZW4gdGhlIHFlbXUgdmlydCBkZXZpY2UgbW9kZWwgdGhpcyBpcyBhcyBzaW1w bGUgYXMgdXNpbmcgZWl0aGVyDQo+PiBzdG9jayBVRUZJIGJ1aWxkIGZvciBhcm0gb3IgZXZlbiBV LUJvb3QgRUZJIGVtdWxhdGlvbiBlbnZpcm9ubWVudCBhbmQNCj4+IHBhc3NpbmcgaXQgdmlhIC1i aW9zIG9wdGlvbi4NCj4+DQo+PiBPYnZpb3VzbHkgd2l0aCBYZW4gb24gQVJNIHdlIGRvbid0IGhh dmUgdGhlIGRldmljZSBtb2RlbCBzbyBteQ0KPj4gdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBl YXNpZXN0IHdheSB3ZSBjYW4gc3VwcG9ydCBpdCB3b3VsZCBiZSB0byBwb3J0DQo+PiBVRUZJJ3Mg T3ZtZlBrZy9Pdm1mWGVuIHRhcmdldCB0byBBUk0gKGl0IHNlZW1zIHRvIGJlIGN1cnJlbnRseSBl eGNsdXNpdmVseQ0KPj4gWDY0KS4NCj4+DQo+PiBTbyBoZXJlJ3MgbXkgZmlyc3QgcXVlc3Rpb246 IGlmIHRoZXJlJ3MgYW55Ym9keSBvbiB0aGlzIGxpc3Qgd2hvIGhhZCBhIGhhbmQgaW4NCj4+IGlt cGxlbWVudGluZyBPdm1mUGtnL092bWZYZW4gY2FuIHlvdSBwbGVhc2Ugc2hhcmUgeW91ciB0aG91 Z2h0cyBvbiBob3cNCj4+IG11Y2ggd29yayB0aGF0IHBvcnQgbWF5IGJlIChvciB3aGV0aGVyIGl0 IGlzIGV2ZW4gZmVhc2libGUgLS0gSSBtYXkgdG90YWxseSBiZQ0KPj4gbWlzc2luZyBzb21ldGhp bmcgcmVhbGx5IG9idmlvdXMgaGVyZSkuDQo+Pg0KPj4gQW5kIGFzIGxvbmcgYXMgSSd2ZSBnb3Qg eW91ciBhdHRlbnRpb246IHR3byBtb3JlIHF1ZXN0aW9uczoNCj4+ICAgICAxLi4gY29tcGFyZWQg dG8gdGhlIGFib3ZlLCB3b3VsZCBwb3J0aW5nIHB2Z3J1YiB0byBBUk0gYmUgYW55DQo+PiAgICAg ZWFzaWVyIG9yIG1vcmUgZGlmZmljdWx0Pw0KPj4NCj4+ICAgICAyLiBzYW1lIHF1ZXN0aW9uIGZv ciB0ZWFjaGluZyB1LWJvb3QgYWJvdXQgUFYgY2FsbHMuDQo+Pg0KPj4gVGhhbmtzLA0KPj4gUm9t YW4uDQo+Pg0KPj4gUC5TLiBPaCBhbmQgSSBndWVzcyBiZXR3ZWVuOg0KPj4gICAgIDAuIE92bWZQ a2cvT3ZtZlhlbiBvbiBBUk02NA0KPj4gICAgIDEuIHB2Z3J1YiBvbiBBUk02NA0KPj4gICAgIDIu IHUtYm9vdC9FRkkgZW11bGF0aW9uIHdpdGggUFYgY2FsbHMgYmFja2VuZCBJIGRpZG4ndCBtaXNz IGFueSBvdGhlcg0KPj4gb2J2aW91cyB3YXkgb2YgbWFraW5nIFVFRkktYXdhcmUgVk0gaW1hZ2Vz IHRvIGJvb3Qgb24gWGVuIEFSTTY0IERvbVUsDQo+PiByaWdodD8= From xen-devel-bounces@lists.xenproject.org Thu Jun 04 15:31:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 15:31:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgrqE-0005WJ-AD; Thu, 04 Jun 2020 15:31:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgrqC-0005WE-MJ for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 15:31:36 +0000 X-Inumbo-ID: 79acae2a-a678-11ea-9dbe-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 79acae2a-a678-11ea-9dbe-bc764e2007e4; Thu, 04 Jun 2020 15:31:35 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0AFB5207D8; Thu, 4 Jun 2020 15:31:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591284695; bh=Vte9wiWyZgKhi4h1DiODPR1O5zkDeEOTtH15miC2eEA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=YZcuohFD4IgHhCkqUnaBEHvLn/6M+XcjeeMkWd8W4CdGLgip1TptCHZPzs90WArn0 CELGX1ghA8ntSPOKO48U0GfxpJ1hzYtTTdh7xEh/3jkQE34g5G+arp2JwAU4+dVwmW IKoE8zb7RdX3pFTE/s9mHo7P7xr4c6wv9K6oj54M= Date: Thu, 4 Jun 2020 08:31:34 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Oleksandr Andrushchenko Subject: Re: UEFI support in ARM DomUs In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peng Fan , Stefano Stabellini , Julien Grall , Roman Shaposhnik , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote: > On 6/4/20 4:57 AM, Peng Fan wrote: > > Grall ; > >> Nataliya Korovkina > >> Subject: UEFI support in ARM DomUs > > We have made U-Boot run inside XEN DomU, but just only PV console part, > > not implement other frontend drivers currently. Would this help for your > > case if enable EFI in U-Boot? > > Well, we have a working PV block implementation on top of that on iMX8 > > platform, mostly ported from mini-os. Currently we are finalizing the work > > and cleaning up (it's going to take a week or so hopefully). Then, we we'll post > > it on our public github. We are also thinking about upstreaming the work, but it may > > take quite some time if the whole idea fits u-boot's view on such an extension at all. Yes please to both of you! :-) In the meantime, while we wait for those changes to go upstream in uboot, could you please post a branch on github and a link on this email thread? Maybe we should have a wikipage on wiki.xenproject.org about work-in-progress uboot items. > > Regards, > > Peng. > > > >> Hi! > >> > >> with a lot of help from Stefano, we're getting RPi4 support in Project EVE > >> pretty much on par between KVM and Xen. > >> > >> One big area that still remains is supporting UEFI boot sequence for DomUs. > >> With KVM, given the qemu virt device model this is as simple as using either > >> stock UEFI build for arm or even U-Boot EFI emulation environment and > >> passing it via -bios option. > >> > >> Obviously with Xen on ARM we don't have the device model so my > >> understanding is that the easiest way we can support it would be to port > >> UEFI's OvmfPkg/OvmfXen target to ARM (it seems to be currently exclusively > >> X64). > >> > >> So here's my first question: if there's anybody on this list who had a hand in > >> implementing OvmfPkg/OvmfXen can you please share your thoughts on how > >> much work that port may be (or whether it is even feasible -- I may totally be > >> missing something really obvious here). > >> > >> And as long as I've got your attention: two more questions: > >> 1.. compared to the above, would porting pvgrub to ARM be any > >> easier or more difficult? > >> > >> 2. same question for teaching u-boot about PV calls. > >> > >> Thanks, > >> Roman. > >> > >> P.S. Oh and I guess between: > >> 0. OvmfPkg/OvmfXen on ARM64 > >> 1. pvgrub on ARM64 > >> 2. u-boot/EFI emulation with PV calls backend I didn't miss any other > >> obvious way of making UEFI-aware VM images to boot on Xen ARM64 DomU, > >> right? From xen-devel-bounces@lists.xenproject.org Thu Jun 04 15:38:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 15:38:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgrxC-0005kF-3m; Thu, 04 Jun 2020 15:38:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgrxA-0005kA-6Y for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 15:38:48 +0000 X-Inumbo-ID: 7afd8848-a679-11ea-aeb0-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7afd8848-a679-11ea-aeb0-12813bfff9fa; Thu, 04 Jun 2020 15:38:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eyBkw7dJwBtByMaT7riuWQsouHwxln5MXJ2TYAmqFRE=; b=DDjCM/y/CGJDuVyBsNuVWdxW9o VJ87P1PgHFrJ5zWanRH9+qYjV220WXnMIHnHrm7nI9RKcQBgPxw2k9xjNaAthHqdobYe453fv9S5p VFpYYnahyyAEsVIihWdSaVa4jRB5ViLoxdx73VBkgY7qAo+5vo68Wm4u0Y2AYAj3V6CA=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgrx8-00089H-D0; Thu, 04 Jun 2020 15:38:46 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgrx8-0008Vz-6X; Thu, 04 Jun 2020 15:38:46 +0000 Subject: Re: UEFI support in ARM DomUs To: Oleksandr Andrushchenko , Peng Fan , Roman Shaposhnik , Xen-devel References: From: Julien Grall Message-ID: Date: Thu, 4 Jun 2020 16:38:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Nataliya Korovkina Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 04/06/2020 16:26, Oleksandr Andrushchenko wrote: > On 6/4/20 4:57 AM, Peng Fan wrote: >> Grall ; >>> Nataliya Korovkina >>> Subject: UEFI support in ARM DomUs >> We have made U-Boot run inside XEN DomU, but just only PV console part, >> not implement other frontend drivers currently. Would this help for your >> case if enable EFI in U-Boot? > > Well, we have a working PV block implementation on top of that on iMX8 That's a nice work and will be a good addition. However... > > platform, mostly ported from mini-os. Currently we are finalizing the work ... AFAICT mini-os is licensed using BSD-2 while U-boot is using GPLv2. So I would be careful with the licensing here. It might be better to consider to port Linux PV driver instead or rewrite them completely. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:00:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:00:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsHZ-0007fk-S9; Thu, 04 Jun 2020 15:59:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsHZ-0007ff-5p for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 15:59:53 +0000 X-Inumbo-ID: 6a040988-a67c-11ea-81bc-bc764e2007e4 Received: from m4a0072g.houston.softwaregrp.com (unknown [15.124.2.130]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6a040988-a67c-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 15:59:50 +0000 (UTC) Received: FROM m4a0072g.houston.softwaregrp.com (15.120.17.147) BY m4a0072g.houston.softwaregrp.com WITH ESMTP; Thu, 4 Jun 2020 15:58:33 +0000 Received: from M9W0067.microfocus.com (2002:f79:be::f79:be) by M4W0335.microfocus.com (2002:f78:1193::f78:1193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 4 Jun 2020 15:57:27 +0000 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (15.124.72.12) by M9W0067.microfocus.com (15.121.0.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10 via Frontend Transport; Thu, 4 Jun 2020 15:57:26 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bw24vyHk0Rn/HJNdsY9XVANEFLWcnLa0rrhq+ZhvpVefgDFrX6cHC83UhkQKFM6erMlSjmKNFKyHZijFwJdqUNyi/Jll2ZLvHdJnkqHHrQQPbzGbFfHpU/POVj8f07R/k1Qeu04ZQZGudk9jgvjZIZME27dXwDcpGbb1JY+Bk7FEPe6DavDI5DU59QI6DzsXCgdQVV/iw2WH6hJ9CPCbreo399nX34XTz+5BtubJPYWEExJrLnnJt4abZpn/2RRCNC9xYr7uriMu0lg4KRieyiDcGxifPuP1i1dHwz99dICnG7r7W7vwpAy/spcE1P3tasR4/d0TKnReufczrxQ7Cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a/w+lXdLh32mZEP9wP3L7bFEMzEAM7IawwazQl/OO6I=; b=hUfKSCBX1PdI+TxG46FM8uttz0CtlKfPlvge2c9tN+DoxrdcK+jmbC83pb0dUgGqIS99AtkoZRZx7t3u03NXLAGaKQAqX7YrCBcndbFhSq3dJHIkMPG7QRhEEzvuH01uGqiPqyqsHtJeqz8xbulBvWHSxEZ4we5VqT4dk2jytjTxEcKJq51wrlwjCWi1fHvXGklb6GZXik778tCy6jobzYt0vtJz8kst7RpBR/G0OR/KHlUcLkK37Py4ccn5PqfnkS56eFP+BAh8FVYJq76TDximz461bb/lNOnhO+cjG3oWi2HHK5GNyoq4kHGcqPW7a9joAy9jSLMLfNk/9fsO0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none Authentication-Results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com; Received: from CY4PR1801MB2071.namprd18.prod.outlook.com (2603:10b6:910:79::35) by CY4PR1801MB1958.namprd18.prod.outlook.com (2603:10b6:910:7b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.21; Thu, 4 Jun 2020 15:57:24 +0000 Received: from CY4PR1801MB2071.namprd18.prod.outlook.com ([fe80::412:7771:b22b:7f67]) by CY4PR1801MB2071.namprd18.prod.outlook.com ([fe80::412:7771:b22b:7f67%6]) with mapi id 15.20.3045.024; Thu, 4 Jun 2020 15:57:24 +0000 Subject: Re: [libvirt test] 149773: regressions - FAIL To: Ian Jackson References: <7c47a937-551f-2c7a-edd3-8b172155a506@suse.com> <24280.60980.488961.267238@mariner.uk.xensource.com> From: Jim Fehlig Message-ID: Date: Thu, 4 Jun 2020 09:57:21 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 In-Reply-To: <24280.60980.488961.267238@mariner.uk.xensource.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MWHPR11CA0015.namprd11.prod.outlook.com (2603:10b6:301:1::25) To CY4PR1801MB2071.namprd18.prod.outlook.com (2603:10b6:910:79::35) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.55] (192.225.185.129) by MWHPR11CA0015.namprd11.prod.outlook.com (2603:10b6:301:1::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Thu, 4 Jun 2020 15:57:23 +0000 X-Originating-IP: [192.225.185.129] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9ddefc06-5c08-4fd3-e3dc-08d8089ff902 X-MS-TrafficTypeDiagnostic: CY4PR1801MB1958: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4714; X-Forefront-PRVS: 04244E0DC5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dWS6R1ls7GtiEFnKIXYDwr09k8JyAnXfPVTJMTSCylepiwMkTyeU7l5JgieDVU0D4weiklCdjm8kkBzVRaYRSEjQq+prUqYaIgXO5j3pgoim/ROTXaq7p/+mJ78pJb6Kt086YXQ2eMSxjf9X32vWZE/2IFr0F/TLxiMrFFP864Y+QaT3jKvN7S0a0I5ySkZwS/3CaO8JnY3vzB5w61RvoPkfIRlXWdf/s5xqUZALYIMCV+o7h5GekXqFeyYeceN5DkpxBJorxFXZMz3tPDlirbX57fAmoOD8aJz5yIUSTfC4j5WhwRcdIVaoMmdEd4TRIsDgF0wG58UD7LB173bm1bLk6lV+N2NM08sbWe1WxeCLGK281vSbjCmAh2lDiT3ch7+YfEl688JnsdNBkt3Gb3j+lU1NrzHcZ5SYAxKDdCzgdCFMyyYU5lhzzs4aFQ2zPqvb9g6bb9YCXXZVoWR5aw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1801MB2071.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(376002)(396003)(346002)(39860400002)(316002)(16576012)(31696002)(86362001)(4326008)(6916009)(6486002)(36756003)(478600001)(83380400001)(31686004)(8676002)(2906002)(54906003)(66556008)(186003)(66946007)(8936002)(5660300002)(66476007)(26005)(16526019)(956004)(2616005)(52116002)(53546011)(966005)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: Y5wLnPE2D2IHh06f8tNl/q6hbMmFKM/L6dQ2nPKW10atAeFpDcHhehX2vZJqCl2xx966S5uervZM/CZi6E8guwfWufLiUpSiOBiQJd+Ov1WShONe0B989mUMJPM9ekeQAfI6Dn+WLyQANrHQ2iaEl6t3XVqR0ePsQ0yrcUGK8c7Q+DZB74iH8VOQGvKKjRiHquKZ0fCG4Zk9axFZgY3WKrkOuHMMrT5OMdQ7gnART/NF3Oie8V96VOWuMF1AXp0uqYp4zz4LxRdklFXhXZNViTCQF9hoNBysVkudJyiAj8qSz8kSoAWkGcRPGTHpKt0fsgLG7BJ9RidGU37ij111crZ63DWI7guMekYU3vQKFGOsCoMC0k9acK1NsfzLX7TiyRVgMoHmgr2k7zlTuOzuLOafjz3KkC4YEsYFyoTfW4g2r9CEzgED/owFJR4cQV3P7vsuSLfpiLK6zpizXRfVXAm9BQaCfZOxJRY3E5Q2fT0= X-MS-Exchange-CrossTenant-Network-Message-Id: 9ddefc06-5c08-4fd3-e3dc-08d8089ff902 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2020 15:57:24.5062 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 856b813c-16e5-49a5-85ec-6f081e13b527 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: UQOUxS8p5VfjPDj7N3plOMtRIHDqlMMmCfBCtyVIKaC5Ey6/TOlNP++WZNJHrr8gorhXZS1Etlb++Qf0xRaYdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1801MB1958 X-OriginatorOrg: suse.com X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , osstest service owner Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/4/20 6:51 AM, Ian Jackson wrote: > Jim Fehlig writes ("Re: [libvirt test] 149773: regressions - FAIL"): >> On 4/24/20 3:53 AM, osstest service owner wrote: >>> flight 149773 libvirt real [real] >>> http://logs.test-lab.xenproject.org/osstest/logs/149773/ >>> >>> Regressions :-( >>> >>> Tests which did not succeed and are blocking, >>> including tests which could not be run: >>> build-amd64-libvirt 6 libvirt-build fail REGR. vs. 146182 >>> build-i386-libvirt 6 libvirt-build fail REGR. vs. 146182 >>> build-arm64-libvirt 6 libvirt-build fail REGR. vs. 146182 >>> build-armhf-libvirt 6 libvirt-build fail REGR. vs. 146182 >> >> Probably best to disable these tests to avoid all the spam. > > I have fixed the build bug now... I saw your patch on the libvirt dev list, thanks! I'm a bit embarrassed for not considering a fix on the libvirt side while trying to address this a few months back :-/. I suspect the upcoming move to meson will be a bit more disruptive and will likely require changes to osstest. Regards, Jim From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:07:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:07:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsP7-0000hq-MY; Thu, 04 Jun 2020 16:07:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsP6-0000hl-V8 for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:07:40 +0000 X-Inumbo-ID: 82b2351d-a67d-11ea-aeb7-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 82b2351d-a67d-11ea-aeb7-12813bfff9fa; Thu, 04 Jun 2020 16:07:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pa1+JEA6TLbcBrAQjrey+FIHpwepwMWnqCkY8TOeefs=; b=W5m0gWA5eXx1ga73eIS9o1Woo phVazE4RWv7BDCjNwAm13xt3LbcWgJDaLGrP+4XiZrykvQwj47ImAdUkuLx4VKySsRLVCZB/wQZ1S er15HuOa9yFgQaAxdrh7O6lZsGXtcs/6JdlDeQwf0oQZ0SFaTsG1nv6Nu0zb7wHWzJpqg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsP5-0000rt-C3; Thu, 04 Jun 2020 16:07:39 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgsP5-0002dT-0H; Thu, 04 Jun 2020 16:07:39 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgsP4-0008Iu-Vq; Thu, 04 Jun 2020 16:07:38 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150695: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d9f58cd54fe2f05e1f05e2fe254684bd1840de8e X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Thu, 04 Jun 2020 16:07:38 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150695 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150695/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d9f58cd54fe2f05e1f05e2fe254684bd1840de8e baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 7 days Failing since 150465 2020-05-29 09:02:14 Z 6 days 46 attempts Testing same since 150649 2020-06-03 13:01:44 Z 1 days 8 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1522 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:23:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:23:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgseC-0002Vl-8P; Thu, 04 Jun 2020 16:23:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgseB-0002Vg-AK for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:23:15 +0000 X-Inumbo-ID: b060eee8-a67f-11ea-aeba-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id b060eee8-a67f-11ea-aeba-12813bfff9fa; Thu, 04 Jun 2020 16:23:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591287793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=B9O2XRCyHbxIKDpgPXguyD8DdCt9q+W4Q9datrk8x4s=; b=ItApGjCZH0NMikyQeVk5tCc3wuXuo4QXBNvsyGVc16gRrax8ByWAo3hH+x+uVm93EfH254 2cwv0ZRACG8tylIwwAKlc0B04J5fz884Jh2AT8+dbOjzDna1K+IJRl1fCNGdpcrE9ww9wg heTUoQoDaVFhrM700z4yiXkEypo7B1o= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-221-BMnhRSqjMo279_wER0NzJw-1; Thu, 04 Jun 2020 12:23:11 -0400 X-MC-Unique: BMnhRSqjMo279_wER0NzJw-1 Received: by mail-wr1-f69.google.com with SMTP id s7so2630487wrm.16 for ; Thu, 04 Jun 2020 09:23:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=B9O2XRCyHbxIKDpgPXguyD8DdCt9q+W4Q9datrk8x4s=; b=UBjY16q8lCdThyRRpZ6KYb8W0lAjfhUvUL28mFi629AgoZyQRdkrhlLXXHOCxLGgXF bd5hsUEJ0lU5jZzyhL43Gj8j044TFZ9DDtPQEfUDsLn3GubHe6NLjusqFo5UBOFjBTMu Jf5kBrX4ZREMkBCR0TL4KLFlee4H82lwEjp6qOyFNHErXT8SFZtPJxJA+rdTWXI8uUgY 8B9sOfzyQPzoQgyqqzHWy2Nz751PgpHLyjYJmS40eJPbZQ2FkIiMdvgQMcz/kCJIUex2 l9UyvIqh+Qpw9RsYFprZAU8zfiV/bvPkIEyJ8fbcVIKVb+KOkJczl9ZaA3Y1uI77E8wd /cag== X-Gm-Message-State: AOAM532sHQ4f7faBNVZWdH2NdJJ5uXWfao53j5Gc6hEE/97hdUD/GfxR j3sfYChT2mrTUnr+iT1rUl9cXamXhAOFeoHRtlrOn2im2aVwxEWyuEaNbfn2+k8tdXYkzL5vZW7 2V8m7YLEwjVSz9C3uZUMI8o1QHpw= X-Received: by 2002:a1c:a906:: with SMTP id s6mr4990769wme.171.1591287790592; Thu, 04 Jun 2020 09:23:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycKqtmToIFUJXoVJkBh8yjxsCrh0nHVi0wwyICMooJNi/z+/a+wLrtUjUmghlHzqr7a90aQA== X-Received: by 2002:a1c:a906:: with SMTP id s6mr4990745wme.171.1591287790313; Thu, 04 Jun 2020 09:23:10 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:a0c0:5d2e:1d35:17bb? ([2001:b07:6468:f312:a0c0:5d2e:1d35:17bb]) by smtp.gmail.com with ESMTPSA id p1sm8323048wrx.44.2020.06.04.09.23.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 09:23:09 -0700 (PDT) Subject: Re: [PATCH v4] xen: fix build without pci passthrough To: Anthony PERARD , qemu-devel@nongnu.org References: <159120627656.23398.3742621530752770397@45ef0f9c86ae> <20200604133042.3380585-1-anthony.perard@citrix.com> From: Paolo Bonzini Message-ID: Date: Thu, 4 Jun 2020 18:23:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200604133042.3380585-1-anthony.perard@citrix.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Paul Durrant , "Michael S. Tsirkin" , Marcel Apfelbaum , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/20 15:30, Anthony PERARD wrote: > - fix build when Xen headers aren't available. > By building stubs/xen-pt.c only when CONFIG_XEN=y > (The alternative would be to move the prototypes used by the stub into > xen.h, which doesn't depends on xen headers.) Good catch. I think we can also drop the whole hw/xen/ directory when CONFIG_XEN=n, and move stubs/xen-pt.c there. I'll send a v5 myself. Paolo > Changes in v3: > - reworked to use stubs instead of #ifdef CONFIG_XEN_PCI_PASSTHROUGH > CONFIG_XEN_PCI_PASSTHROUGH isn't available in xen-common.c > > moving CONFIG_XEN_PCI_PASSTHROUGH to be in config_host_mak isn't > really possible, or at least I didn't managed to make that work. > > hw/i386/pc_piix.c | 2 +- > hw/xen/xen-common.c | 4 ++-- > hw/xen/xen_pt.c | 12 +++++++++++- > hw/xen/xen_pt.h | 6 ++++-- > stubs/Makefile.objs | 1 + > stubs/xen-pt.c | 22 ++++++++++++++++++++++ > 6 files changed, 41 insertions(+), 6 deletions(-) > create mode 100644 stubs/xen-pt.c > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > index f66e1d73ce0b..347fb8c6c807 100644 > --- a/hw/i386/pc_piix.c > +++ b/hw/i386/pc_piix.c > @@ -375,7 +375,7 @@ static void pc_init_isa(MachineState *machine) > #ifdef CONFIG_XEN > static void pc_xen_hvm_init_pci(MachineState *machine) > { > - const char *pci_type = has_igd_gfx_passthru ? > + const char *pci_type = xen_igd_gfx_pt_enabled() ? > TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE : TYPE_I440FX_PCI_DEVICE; > > pc_init1(machine, > diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c > index 70564cc952d5..dd2c22cc4c0b 100644 > --- a/hw/xen/xen-common.c > +++ b/hw/xen/xen-common.c > @@ -129,12 +129,12 @@ static void xen_change_state_handler(void *opaque, int running, > > static bool xen_get_igd_gfx_passthru(Object *obj, Error **errp) > { > - return has_igd_gfx_passthru; > + return xen_igd_gfx_pt_enabled(); > } > > static void xen_set_igd_gfx_passthru(Object *obj, bool value, Error **errp) > { > - has_igd_gfx_passthru = value; > + xen_igd_gfx_pt_set(value, errp); > } > > static void xen_setup_post(MachineState *ms, AccelState *accel) > diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c > index 81d5ad8da7f0..ab84443d5ec8 100644 > --- a/hw/xen/xen_pt.c > +++ b/hw/xen/xen_pt.c > @@ -65,7 +65,17 @@ > #include "qemu/range.h" > #include "exec/address-spaces.h" > > -bool has_igd_gfx_passthru; > +static bool has_igd_gfx_passthru; > + > +bool xen_igd_gfx_pt_enabled(void) > +{ > + return has_igd_gfx_passthru; > +} > + > +void xen_igd_gfx_pt_set(bool value, Error **errp) > +{ > + has_igd_gfx_passthru = value; > +} > > #define XEN_PT_NR_IRQS (256) > static uint8_t xen_pt_mapped_machine_irq[XEN_PT_NR_IRQS] = {0}; > diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h > index 179775db7b22..6e9cec95f3b7 100644 > --- a/hw/xen/xen_pt.h > +++ b/hw/xen/xen_pt.h > @@ -5,6 +5,9 @@ > #include "hw/pci/pci.h" > #include "xen-host-pci-device.h" > > +bool xen_igd_gfx_pt_enabled(void); > +void xen_igd_gfx_pt_set(bool value, Error **errp); > + > void xen_pt_log(const PCIDevice *d, const char *f, ...) GCC_FMT_ATTR(2, 3); > > #define XEN_PT_ERR(d, _f, _a...) xen_pt_log(d, "%s: Error: "_f, __func__, ##_a) > @@ -322,10 +325,9 @@ extern void *pci_assign_dev_load_option_rom(PCIDevice *dev, > unsigned int domain, > unsigned int bus, unsigned int slot, > unsigned int function); > -extern bool has_igd_gfx_passthru; > static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev) > { > - return (has_igd_gfx_passthru > + return (xen_igd_gfx_pt_enabled() > && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA)); > } > int xen_pt_register_vga_regions(XenHostPCIDevice *dev); > diff --git a/stubs/Makefile.objs b/stubs/Makefile.objs > index 6a9e3135e8f9..e0427158132f 100644 > --- a/stubs/Makefile.objs > +++ b/stubs/Makefile.objs > @@ -40,6 +40,7 @@ stub-obj-y += target-get-monitor-def.o > stub-obj-y += vmgenid.o > stub-obj-y += xen-common.o > stub-obj-y += xen-hvm.o > +stub-obj-$(CONFIG_XEN) += xen-pt.o > stub-obj-y += pci-host-piix.o > stub-obj-y += ram-block.o > stub-obj-y += ramfb.o > diff --git a/stubs/xen-pt.c b/stubs/xen-pt.c > new file mode 100644 > index 000000000000..2d8cac8d54b9 > --- /dev/null > +++ b/stubs/xen-pt.c > @@ -0,0 +1,22 @@ > +/* > + * Copyright (C) 2020 Citrix Systems UK Ltd. > + * > + * This work is licensed under the terms of the GNU GPL, version 2 or later. > + * See the COPYING file in the top-level directory. > + */ > + > +#include "qemu/osdep.h" > +#include "hw/xen/xen_pt.h" > +#include "qapi/error.h" > + > +bool xen_igd_gfx_pt_enabled(void) > +{ > + return false; > +} > + > +void xen_igd_gfx_pt_set(bool value, Error **errp) > +{ > + if (value) { > + error_setg(errp, "Xen PCI passthrough support not built in"); > + } > +} > From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:24:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:24:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsfm-0002d6-KH; Thu, 04 Jun 2020 16:24:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsfl-0002cv-6d for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:24:53 +0000 X-Inumbo-ID: eb04e95a-a67f-11ea-81bc-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eb04e95a-a67f-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 16:24:52 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A77DD2053B; Thu, 4 Jun 2020 16:24:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591287892; bh=ukrGrGORqvH+sAsyI0NWX88q0bFOxhvCuNQwV63W9H0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=HhwLA5H12LWCMIx96y7AwnnO86K2Mj+EpWmQFE7VfRAuhzgQAg6n7/ddvMnCigIEJ B1n5Sgn6kBepWwfRkHYgIpbF2hR4/f610TknkBdemf/u356wkjciEoOaTI5uFPHOtE Ncofv8zqKn+wo22LY5CwKZPE0x58zNIpQCacd3ao= Date: Thu, 4 Jun 2020 09:24:51 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: =?UTF-8?Q?Andr=C3=A9_Przywara?= Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset In-Reply-To: <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> Message-ID: References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1824644307-1591287891=:6774" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: cminyard@mvista.com, Stefano Stabellini , Julien Grall , roman@zededa.com, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1824644307-1591287891=:6774 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 4 Jun 2020, André Przywara wrote: > On 04/06/2020 09:48, Julien Grall wrote: > > Hi, > > > On 03/06/2020 23:31, Stefano Stabellini wrote: > >> Touching the watchdog is required to be able to reboot the board. > > > > In general the preferred method is PSCI. Does it mean RPI 4 doesn't > > support PSCI at all? > > There is mainline Trusted Firmware (TF-A) support for the RPi4 for a few > months now, which includes proper PSCI support (both for SMP bringup and > system reset/shutdown). At least that should work, if not, it's a bug. > An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF-A > without it, with or without U-Boot: It works as a drop-in replacement > for armstub.bin. Instruction for building it (one line!) are here: > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi4.rst > > >> > >> The implementation is based on > >> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > > > Can you give the baseline? This would allow us to track an issue and > > port them. > > Given the above I don't think it's a good idea to add extra platform > specific code to Xen. The RPi4, at least the one I have, doesn't come with any TF, and it doesn't come with PSCI in device tree. As a user, I would rather have this patch (even downstream) than having to introduce TF in my build and deployment just to be able to reboot. Do other RPi4 users on this thread agree? But fortunately this one of the few cases where we can have our cake and eat it too :-) If PSCI is supported on the RPi4, Xen automatically uses the PSCI reboot method first. (We could even go one step further and check for PSCI support in rpi4_reset below.) See xen/arch/arm/shutdown.c:machine_restart: /* This is mainly for PSCI-0.2, which does not return if success. */ call_psci_system_reset(); /* Alternative reset procedure */ while ( 1 ) { platform_reset(); mdelay(100); } In other words, this patch won't take anything away from the good work done in TF, and when/if available, Xen will use it. > >> > >> Signed-off-by: Stefano Stabellini > >> --- > >>   xen/arch/arm/platforms/brcm-raspberry-pi.c | 60 ++++++++++++++++++++++ > >>   1 file changed, 60 insertions(+) > >> > >> diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c > >> b/xen/arch/arm/platforms/brcm-raspberry-pi.c > >> index f5ae58a7d5..0214ae2b3c 100644 > >> --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c > >> +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c > >> @@ -18,6 +18,10 @@ > >>    */ > >>     #include > >> +#include > >> +#include > >> +#include > >> +#include > > > > We are trying to keep the headers ordered alphabetically within each > > directory and then 'xen/' first following by 'asm/'. > > > >>     static const char *const rpi4_dt_compat[] __initconst = > >>   { > >> @@ -37,12 +41,68 @@ static const struct dt_device_match > >> rpi4_blacklist_dev[] __initconst = > >>        * The aux peripheral also shares a page with the aux UART. > >>        */ > >>       DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"), > >> +    /* Special device used for rebooting */ > >> +    DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"), > >>       { /* sentinel */ }, > >>   }; > >>   + > >> +#define PM_PASSWORD         0x5a000000 > >> +#define PM_RSTC             0x1c > >> +#define PM_WDOG             0x24 > >> +#define PM_RSTC_WRCFG_FULL_RESET    0x00000020 > >> +#define PM_RSTC_WRCFG_CLR           0xffffffcf > > > > NIT: It is a bit odd you introduce the 5 define together but the first 3 > > have a different indentation compare to the last 2. > > > >> + > >> +static void __iomem *rpi4_map_watchdog(void) > >> +{ > >> +    void __iomem *base; > >> +    struct dt_device_node *node; > >> +    paddr_t start, len; > >> +    int ret; > >> + > >> +    node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm"); > >> +    if ( !node ) > >> +        return NULL; > >> + > >> +    ret = dt_device_get_address(node, 0, &start, &len); > >> +    if ( ret ) > >> +    { > >> +        dprintk(XENLOG_ERR, "Cannot read watchdog register address\n"); > > > > I would suggest to use printk() rather than dprintk. It would be useful > > for a normal user to know that we didn't manage to reset the platform > > and why. > > > > > >> +        return NULL; > >> +    } > >> + > >> +    base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE); > >> +    if ( !base ) > >> +    { > >> +        dprintk(XENLOG_ERR, "Unable to map watchdog register!\n"); > >> +        return NULL; > >> +    } > >> + > >> +    return base; > >> +} > >> + > >> +static void rpi4_reset(void) > >> +{ > >> +    u32 val; > > > > We are trying to get rid of any use of u32 in Xen code (the coding style > > used in this file). Please use uint32_t instead. > > > >> +    void __iomem *base = rpi4_map_watchdog(); > > > > Newline here please. > > > >> +    if ( !base ) > >> +        return; > >> + > >> +    /* use a timeout of 10 ticks (~150us) */ > >> +    writel(10 | PM_PASSWORD, base + PM_WDOG); > >> +    val = readl(base + PM_RSTC); > >> +    val &= PM_RSTC_WRCFG_CLR; > >> +    val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET; > >> +    writel(val, base + PM_RSTC); > >> + > >> +    /* No sleeping, possibly atomic. */ > >> +    mdelay(1); > >> +} > >> + > >>   PLATFORM_START(rpi4, "Raspberry Pi 4") > >>       .compatible     = rpi4_dt_compat, > >>       .blacklist_dev  = rpi4_blacklist_dev, > >> +    .reset = rpi4_reset, > >>       .dma_bitsize    = 30, > >>   PLATFORM_END > >>   > > > > Cheers, > > > --8323329-1824644307-1591287891=:6774-- From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:27:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:27:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsiC-0002kx-1e; Thu, 04 Jun 2020 16:27:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsiB-0002ks-2d for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:27:23 +0000 X-Inumbo-ID: 447f7158-a680-11ea-8993-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 447f7158-a680-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 16:27:22 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D6B9E206DC; Thu, 4 Jun 2020 16:27:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591288042; bh=n+z53JuTQBr7A6TWR+WcVKvp5mm7k/fZNd4gEOeQgdE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Qzzv4gofa7uoTMFNqYBbKReANB5dy5FBWlb2U754TKIplg4Krn91GZR80gWjeiWEp hc5R+dJTIaFOOTma9WaAbpZemnHdSZP2JPMr5UljTKF271tXp+Yi6ireXSlKoPqDPF TR0PIx8Iv2mit6Fcnev7PPipImhRdlW1vQjt6yaY= Date: Thu, 4 Jun 2020 09:27:20 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: UEFI support in ARM DomUs In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peng Fan , Stefano Stabellini , Oleksandr Andrushchenko , Roman Shaposhnik , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 4 Jun 2020, Julien Grall wrote: > On 04/06/2020 16:26, Oleksandr Andrushchenko wrote: > > On 6/4/20 4:57 AM, Peng Fan wrote: > > > Grall ; > > > > Nataliya Korovkina > > > > Subject: UEFI support in ARM DomUs > > > We have made U-Boot run inside XEN DomU, but just only PV console part, > > > not implement other frontend drivers currently. Would this help for your > > > case if enable EFI in U-Boot? > > > > Well, we have a working PV block implementation on top of that on iMX8 > > That's a nice work and will be a good addition. However... > > > > > platform, mostly ported from mini-os. Currently we are finalizing the work > > ... AFAICT mini-os is licensed using BSD-2 while U-boot is using GPLv2. So I > would be careful with the licensing here. > > It might be better to consider to port Linux PV driver instead or rewrite them > completely. Julien, I might be misunderstanding what you wrote. MiniOS is BSD-2 so MiniOS code can be integrated into a GPLv2 project without issues (becoming GPLv2.) So it should be OK to take MiniOS code and add it to Uboot? The other way around would be an issue: you cannot take GPLv2 code and add it to a BSD-2 project. From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:34:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:34:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsol-0003h9-Q2; Thu, 04 Jun 2020 16:34:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsok-0003h0-Ti for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:34:10 +0000 X-Inumbo-ID: 3766eac2-a681-11ea-aebe-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3766eac2-a681-11ea-aebe-12813bfff9fa; Thu, 04 Jun 2020 16:34:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=NBXJUJsJTzOpO6WNXRcTt1YH0gFs7vUGy9SndxnqndI=; b=xk4g9a9JFWLEE7OpR1bK4mhWfH 1giPl+YO/Bca+Obo2Gc15s3n3+fVKWUmhjD1cR7VtI+Fe/1AuPYObPG3so4zleLoqEAX5FR+n5Gns CN9GDejQ9+oNMl9N4iEaXk+qT3f2M8zw6HPxXDsl7K3C+oit2BdQVeXezOo8QZo1ovtw=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsoj-0001Pi-Hv; Thu, 04 Jun 2020 16:34:09 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgsoj-0003G5-Au; Thu, 04 Jun 2020 16:34:09 +0000 Subject: Re: UEFI support in ARM DomUs To: Stefano Stabellini References: From: Julien Grall Message-ID: <9b4163cf-9cba-e094-cfff-594a3530f891@xen.org> Date: Thu, 4 Jun 2020 17:34:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Peng Fan , Roman Shaposhnik , Nataliya Korovkina , Oleksandr Andrushchenko Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 04/06/2020 17:27, Stefano Stabellini wrote: > On Thu, 4 Jun 2020, Julien Grall wrote: >> On 04/06/2020 16:26, Oleksandr Andrushchenko wrote: >>> On 6/4/20 4:57 AM, Peng Fan wrote: >>>> Grall ; >>>>> Nataliya Korovkina >>>>> Subject: UEFI support in ARM DomUs >>>> We have made U-Boot run inside XEN DomU, but just only PV console part, >>>> not implement other frontend drivers currently. Would this help for your >>>> case if enable EFI in U-Boot? >>> >>> Well, we have a working PV block implementation on top of that on iMX8 >> >> That's a nice work and will be a good addition. However... >> >>> >>> platform, mostly ported from mini-os. Currently we are finalizing the work >> >> ... AFAICT mini-os is licensed using BSD-2 while U-boot is using GPLv2. So I >> would be careful with the licensing here. >> >> It might be better to consider to port Linux PV driver instead or rewrite them >> completely. > > Julien, I might be misunderstanding what you wrote. MiniOS is BSD-2 so > MiniOS code can be integrated into a GPLv2 project without issues > (becoming GPLv2.) So it should be OK to take MiniOS code and add it to > Uboot? Yes I did realized that afterwards. Sorry for the noise :(. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:36:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:36:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsr8-0003oF-7a; Thu, 04 Jun 2020 16:36:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsr6-0003oA-Iw for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:36:36 +0000 X-Inumbo-ID: 8e76ea6a-a681-11ea-aec2-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8e76ea6a-a681-11ea-aec2-12813bfff9fa; Thu, 04 Jun 2020 16:36:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3GYK2KCQ3WUbCDYvaFcSHDf0670NtWTEbYye5IIai8Q=; b=CwQ0ewc0ZgH+piIPvFd9yekR4S VkSqqIZCzUi7FEpor5rt6prHFydBmEl5URRVxK3WUB5qFoi6Xxq4h3j9cPAGMFIdJO2jhzj4IeHjW +3RjsryXtDwufZYC4Byb3An6+x/u+20v2fIKOKani0E2b04q2kU3bUgX33C8kIvLNbw8=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsr1-0001Ru-9c; Thu, 04 Jun 2020 16:36:31 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgsr1-0003QA-37; Thu, 04 Jun 2020 16:36:31 +0000 Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: Stefano Stabellini , =?UTF-8?Q?Andr=c3=a9_Przywara?= References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> From: Julien Grall Message-ID: Date: Thu, 4 Jun 2020 17:36:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, roman@zededa.com, tamas@tklengyel.com, Stefano Stabellini , cminyard@mvista.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 04/06/2020 17:24, Stefano Stabellini wrote: > On Thu, 4 Jun 2020, André Przywara wrote: >> On 04/06/2020 09:48, Julien Grall wrote: >> >> Hi, >> >>> On 03/06/2020 23:31, Stefano Stabellini wrote: >>>> Touching the watchdog is required to be able to reboot the board. >>> >>> In general the preferred method is PSCI. Does it mean RPI 4 doesn't >>> support PSCI at all? >> >> There is mainline Trusted Firmware (TF-A) support for the RPi4 for a few >> months now, which includes proper PSCI support (both for SMP bringup and >> system reset/shutdown). At least that should work, if not, it's a bug. >> An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF-A >> without it, with or without U-Boot: It works as a drop-in replacement >> for armstub.bin. Instruction for building it (one line!) are here: >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi4.rst >> >>>> >>>> The implementation is based on >>>> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. >>> >>> Can you give the baseline? This would allow us to track an issue and >>> port them. >> >> Given the above I don't think it's a good idea to add extra platform >> specific code to Xen. > > The RPi4, at least the one I have, doesn't come with any TF, and it > doesn't come with PSCI in device tree. As a user, I would rather have > this patch (even downstream) than having to introduce TF in my build and > deployment just to be able to reboot. So what are you using for the firmware? Do you boot Xen directly? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:38:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:38:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgssy-0003xU-Nc; Thu, 04 Jun 2020 16:38:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgssx-0003xN-Fu for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:38:31 +0000 X-Inumbo-ID: d2e530d0-a681-11ea-aec2-12813bfff9fa Received: from foss.arm.com (unknown [217.140.110.172]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id d2e530d0-a681-11ea-aec2-12813bfff9fa; Thu, 04 Jun 2020 16:38:30 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6FEA31FB; Thu, 4 Jun 2020 09:38:30 -0700 (PDT) Received: from [192.168.2.22] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 651183F6CF; Thu, 4 Jun 2020 09:38:29 -0700 (PDT) Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: Stefano Stabellini References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= Autocrypt: addr=andre.przywara@arm.com; prefer-encrypt=mutual; keydata= xsFNBFNPCKMBEAC+6GVcuP9ri8r+gg2fHZDedOmFRZPtcrMMF2Cx6KrTUT0YEISsqPoJTKld tPfEG0KnRL9CWvftyHseWTnU2Gi7hKNwhRkC0oBL5Er2hhNpoi8x4VcsxQ6bHG5/dA7ctvL6 kYvKAZw4X2Y3GTbAZIOLf+leNPiF9175S8pvqMPi0qu67RWZD5H/uT/TfLpvmmOlRzNiXMBm kGvewkBpL3R2clHquv7pB6KLoY3uvjFhZfEedqSqTwBVu/JVZZO7tvYCJPfyY5JG9+BjPmr+ REe2gS6w/4DJ4D8oMWKoY3r6ZpHx3YS2hWZFUYiCYovPxfj5+bOr78sg3JleEd0OB0yYtzTT esiNlQpCo0oOevwHR+jUiaZevM4xCyt23L2G+euzdRsUZcK/M6qYf41Dy6Afqa+PxgMEiDto ITEH3Dv+zfzwdeqCuNU0VOGrQZs/vrKOUmU/QDlYL7G8OIg5Ekheq4N+Ay+3EYCROXkstQnf YYxRn5F1oeVeqoh1LgGH7YN9H9LeIajwBD8OgiZDVsmb67DdF6EQtklH0ycBcVodG1zTCfqM AavYMfhldNMBg4vaLh0cJ/3ZXZNIyDlV372GmxSJJiidxDm7E1PkgdfCnHk+pD8YeITmSNyb 7qeU08Hqqh4ui8SSeUp7+yie9zBhJB5vVBJoO5D0MikZAODIDwARAQABzS1BbmRyZSBQcnp5 d2FyYSAoQVJNKSA8YW5kcmUucHJ6eXdhcmFAYXJtLmNvbT7CwXsEEwECACUCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheABQJTWSV8AhkBAAoJEAL1yD+ydue63REP/1tPqTo/f6StS00g NTUpjgVqxgsPWYWwSLkgkaUZn2z9Edv86BLpqTY8OBQZ19EUwfNehcnvR+Olw+7wxNnatyxo D2FG0paTia1SjxaJ8Nx3e85jy6l7N2AQrTCFCtFN9lp8Pc0LVBpSbjmP+Peh5Mi7gtCBNkpz KShEaJE25a/+rnIrIXzJHrsbC2GwcssAF3bd03iU41J1gMTalB6HCtQUwgqSsbG8MsR/IwHW XruOnVp0GQRJwlw07e9T3PKTLj3LWsAPe0LHm5W1Q+euoCLsZfYwr7phQ19HAxSCu8hzp43u zSw0+sEQsO+9wz2nGDgQCGepCcJR1lygVn2zwRTQKbq7Hjs+IWZ0gN2nDajScuR1RsxTE4WR lj0+Ne6VrAmPiW6QqRhliDO+e82riI75ywSWrJb9TQw0+UkIQ2DlNr0u0TwCUTcQNN6aKnru ouVt3qoRlcD5MuRhLH+ttAcmNITMg7GQ6RQajWrSKuKFrt6iuDbjgO2cnaTrLbNBBKPTG4oF D6kX8Zea0KvVBagBsaC1CDTDQQMxYBPDBSlqYCb/b2x7KHTvTAHUBSsBRL6MKz8wwruDodTM 4E4ToV9URl4aE/msBZ4GLTtEmUHBh4/AYwk6ACYByYKyx5r3PDG0iHnJ8bV0OeyQ9ujfgBBP B2t4oASNnIOeGEEcQ2rjzsFNBFNPCKMBEACm7Xqafb1Dp1nDl06aw/3O9ixWsGMv1Uhfd2B6 it6wh1HDCn9HpekgouR2HLMvdd3Y//GG89irEasjzENZPsK82PS0bvkxxIHRFm0pikF4ljIb 6tca2sxFr/H7CCtWYZjZzPgnOPtnagN0qVVyEM7L5f7KjGb1/o5EDkVR2SVSSjrlmNdTL2Rd zaPqrBoxuR/y/n856deWqS1ZssOpqwKhxT1IVlF6S47CjFJ3+fiHNjkljLfxzDyQXwXCNoZn BKcW9PvAMf6W1DGASoXtsMg4HHzZ5fW+vnjzvWiC4pXrcP7Ivfxx5pB+nGiOfOY+/VSUlW/9 GdzPlOIc1bGyKc6tGREH5lErmeoJZ5k7E9cMJx+xzuDItvnZbf6RuH5fg3QsljQy8jLlr4S6 8YwxlObySJ5K+suPRzZOG2+kq77RJVqAgZXp3Zdvdaov4a5J3H8pxzjj0yZ2JZlndM4X7Msr P5tfxy1WvV4Km6QeFAsjcF5gM+wWl+mf2qrlp3dRwniG1vkLsnQugQ4oNUrx0ahwOSm9p6kM CIiTITo+W7O9KEE9XCb4vV0ejmLlgdDV8ASVUekeTJkmRIBnz0fa4pa1vbtZoi6/LlIdAEEt PY6p3hgkLLtr2GRodOW/Y3vPRd9+rJHq/tLIfwc58ZhQKmRcgrhtlnuTGTmyUqGSiMNfpwAR AQABwsFfBBgBAgAJBQJTTwijAhsMAAoJEAL1yD+ydue64BgP/33QKczgAvSdj9XTC14wZCGE U8ygZwkkyNf021iNMj+o0dpLU48PIhHIMTXlM2aiiZlPWgKVlDRjlYuc9EZqGgbOOuR/pNYA JX9vaqszyE34JzXBL9DBKUuAui8z8GcxRcz49/xtzzP0kH3OQbBIqZWuMRxKEpRptRT0wzBL O31ygf4FRxs68jvPCuZjTGKELIo656/Hmk17cmjoBAJK7JHfqdGkDXk5tneeHCkB411p9WJU vMO2EqsHjobjuFm89hI0pSxlUoiTL0Nuk9Edemjw70W4anGNyaQtBq+qu1RdjUPBvoJec7y/ EXJtoGxq9Y+tmm22xwApSiIOyMwUi9A1iLjQLmngLeUdsHyrEWTbEYHd2sAM2sqKoZRyBDSv ejRvZD6zwkY/9nRqXt02H1quVOP42xlkwOQU6gxm93o/bxd7S5tEA359Sli5gZRaucpNQkwd KLQdCvFdksD270r4jU/rwR2R/Ubi+txfy0dk2wGBjl1xpSf0Lbl/KMR5TQntELfLR4etizLq Xpd2byn96Ivi8C8u9zJruXTueHH8vt7gJ1oax3yKRGU5o2eipCRiKZ0s/T7fvkdq+8beg9ku fDO4SAgJMIl6H5awliCY2zQvLHysS/Wb8QuB09hmhLZ4AifdHyF1J5qeePEhgTA+BaUbiUZf i4aIXCH3Wv6K Organization: ARM Ltd. Message-ID: Date: Thu, 4 Jun 2020 17:37:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: cminyard@mvista.com, tamas@tklengyel.com, Julien Grall , roman@zededa.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 17:24, Stefano Stabellini wrote: > On Thu, 4 Jun 2020, André Przywara wrote: >> On 04/06/2020 09:48, Julien Grall wrote: >> >> Hi, >> >>> On 03/06/2020 23:31, Stefano Stabellini wrote: >>>> Touching the watchdog is required to be able to reboot the board. >>> >>> In general the preferred method is PSCI. Does it mean RPI 4 doesn't >>> support PSCI at all? >> >> There is mainline Trusted Firmware (TF-A) support for the RPi4 for a few >> months now, which includes proper PSCI support (both for SMP bringup and >> system reset/shutdown). At least that should work, if not, it's a bug. >> An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF-A >> without it, with or without U-Boot: It works as a drop-in replacement >> for armstub.bin. Instruction for building it (one line!) are here: >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi4.rst >> >>>> >>>> The implementation is based on >>>> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. >>> >>> Can you give the baseline? This would allow us to track an issue and >>> port them. >> >> Given the above I don't think it's a good idea to add extra platform >> specific code to Xen. > > The RPi4, at least the one I have, doesn't come with any TF, and it My RPi4 didn't come with anything, actually ;-) It's just a matter of what you put in the uSD card slot. > doesn't come with PSCI in device tree. TF-A patches the PSCI nodes in: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/plat/rpi/rpi4?id=f67fa69cb6937a7fc559bbec4a7acce5edefa888 > As a user, I would rather have > this patch (even downstream) than having to introduce TF in my build and > deployment just to be able to reboot. I get your point, but would rather put more pressure on people using TF-A. After all you run without CPU hotplug, A72 errata workarounds and without Spectre/Meltdown fixes. What was the IP address of your board again? ;-) > > Do other RPi4 users on this thread agree? > > > But fortunately this one of the few cases where we can have our cake and > eat it too :-) > > If PSCI is supported on the RPi4, Xen automatically uses the PSCI reboot > method first. (We could even go one step further and check for PSCI > support in rpi4_reset below.) See > xen/arch/arm/shutdown.c:machine_restart: > > /* This is mainly for PSCI-0.2, which does not return if success. */ > call_psci_system_reset(); > > /* Alternative reset procedure */ > while ( 1 ) > { > platform_reset(); > mdelay(100); > } > > > In other words, this patch won't take anything away from the good work > done in TF, and when/if available, Xen will use it. Sure, it doesn't block anything. I won't be in your way, after all I don't have much of a say anyway ;-) But how do you actually run Xen on the board? I guess this involves quite some hacks on the firmware side to get it running (bootloader? EFI? grub? hack the DTB?). I wonder if adding bl31.bin is really your biggest problem, then. Cheers, Andre >>>> >>>> Signed-off-by: Stefano Stabellini >>>> --- >>>>   xen/arch/arm/platforms/brcm-raspberry-pi.c | 60 ++++++++++++++++++++++ >>>>   1 file changed, 60 insertions(+) >>>> >>>> diff --git a/xen/arch/arm/platforms/brcm-raspberry-pi.c >>>> b/xen/arch/arm/platforms/brcm-raspberry-pi.c >>>> index f5ae58a7d5..0214ae2b3c 100644 >>>> --- a/xen/arch/arm/platforms/brcm-raspberry-pi.c >>>> +++ b/xen/arch/arm/platforms/brcm-raspberry-pi.c >>>> @@ -18,6 +18,10 @@ >>>>    */ >>>>     #include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>> >>> We are trying to keep the headers ordered alphabetically within each >>> directory and then 'xen/' first following by 'asm/'. >>> >>>>     static const char *const rpi4_dt_compat[] __initconst = >>>>   { >>>> @@ -37,12 +41,68 @@ static const struct dt_device_match >>>> rpi4_blacklist_dev[] __initconst = >>>>        * The aux peripheral also shares a page with the aux UART. >>>>        */ >>>>       DT_MATCH_COMPATIBLE("brcm,bcm2835-aux"), >>>> +    /* Special device used for rebooting */ >>>> +    DT_MATCH_COMPATIBLE("brcm,bcm2835-pm"), >>>>       { /* sentinel */ }, >>>>   }; >>>>   + >>>> +#define PM_PASSWORD         0x5a000000 >>>> +#define PM_RSTC             0x1c >>>> +#define PM_WDOG             0x24 >>>> +#define PM_RSTC_WRCFG_FULL_RESET    0x00000020 >>>> +#define PM_RSTC_WRCFG_CLR           0xffffffcf >>> >>> NIT: It is a bit odd you introduce the 5 define together but the first 3 >>> have a different indentation compare to the last 2. >>> >>>> + >>>> +static void __iomem *rpi4_map_watchdog(void) >>>> +{ >>>> +    void __iomem *base; >>>> +    struct dt_device_node *node; >>>> +    paddr_t start, len; >>>> +    int ret; >>>> + >>>> +    node = dt_find_compatible_node(NULL, NULL, "brcm,bcm2835-pm"); >>>> +    if ( !node ) >>>> +        return NULL; >>>> + >>>> +    ret = dt_device_get_address(node, 0, &start, &len); >>>> +    if ( ret ) >>>> +    { >>>> +        dprintk(XENLOG_ERR, "Cannot read watchdog register address\n"); >>> >>> I would suggest to use printk() rather than dprintk. It would be useful >>> for a normal user to know that we didn't manage to reset the platform >>> and why. >>> >>> >>>> +        return NULL; >>>> +    } >>>> + >>>> +    base = ioremap_nocache(start & PAGE_MASK, PAGE_SIZE); >>>> +    if ( !base ) >>>> +    { >>>> +        dprintk(XENLOG_ERR, "Unable to map watchdog register!\n"); >>>> +        return NULL; >>>> +    } >>>> + >>>> +    return base; >>>> +} >>>> + >>>> +static void rpi4_reset(void) >>>> +{ >>>> +    u32 val; >>> >>> We are trying to get rid of any use of u32 in Xen code (the coding style >>> used in this file). Please use uint32_t instead. >>> >>>> +    void __iomem *base = rpi4_map_watchdog(); >>> >>> Newline here please. >>> >>>> +    if ( !base ) >>>> +        return; >>>> + >>>> +    /* use a timeout of 10 ticks (~150us) */ >>>> +    writel(10 | PM_PASSWORD, base + PM_WDOG); >>>> +    val = readl(base + PM_RSTC); >>>> +    val &= PM_RSTC_WRCFG_CLR; >>>> +    val |= PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET; >>>> +    writel(val, base + PM_RSTC); >>>> + >>>> +    /* No sleeping, possibly atomic. */ >>>> +    mdelay(1); >>>> +} >>>> + >>>>   PLATFORM_START(rpi4, "Raspberry Pi 4") >>>>       .compatible     = rpi4_dt_compat, >>>>       .blacklist_dev  = rpi4_blacklist_dev, >>>> +    .reset = rpi4_reset, >>>>       .dma_bitsize    = 30, >>>>   PLATFORM_END >>>>   >>> >>> Cheers, >>> From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:40:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:40:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsv8-0004o3-4q; Thu, 04 Jun 2020 16:40:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgsv7-0004ny-1w for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:40:45 +0000 X-Inumbo-ID: 224119b4-a682-11ea-aec5-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 224119b4-a682-11ea-aec5-12813bfff9fa; Thu, 04 Jun 2020 16:40:44 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: RaUK3moPoeydGah68lZURMNhv2cBJk0MzoqWx6HAWOF1NxjHAgyjvO2s9vS5nbyIkRwu5HnLun 9TLfH3/yWl5s3iGXl12qEYXDzmcOD524fsIsoMiI6dKXjpVpNA+8W/q3hGQkVvCDe9gB+r6Tgg aCy5lhPbs6OzM/xdgsnG8eiThEnki8HV7IVOxbUSE/oAA+O0AaxqrRy9RmO8y4khbvNaBXL7wZ 0h/9qthVh244kJlYJmEXDXFeQyamkebGS87WMNGPN8lMmGNUsmlc09kUXef28tDMvAWvUbYj4Z AoY= X-SBRS: 2.7 X-MesageID: 19600144 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="19600144" From: George Dunlap To: xen-devel Subject: Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile Thread-Topic: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile Thread-Index: AQHWM6tS08XNp9FsPk2dfrAVrD4GiajIlOUA Date: Thu, 4 Jun 2020 16:40:40 +0000 Message-ID: <5CF4AE1D-C80C-4E4C-B4AA-0779E7DC53E7@citrix.com> References: <20200526221612.900922-1-george.dunlap@citrix.com> <20200526221612.900922-2-george.dunlap@citrix.com> In-Reply-To: <20200526221612.900922-2-george.dunlap@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gTWF5IDI2LCAyMDIwLCBhdCAxMToxNiBQTSwgR2VvcmdlIER1bmxhcCA8Z2Vvcmdl LmR1bmxhcEBjaXRyaXguY29tPiB3cm90ZToNCj4gDQo+IFRoZSBnZW5lcmF0ZWQgZ29sYW5nIGJp bmRpbmdzICh0eXBlcy5nZW4uZ28gYW5kIGhlbHBlcnMuZ2VuLmdvKSBhcmUNCj4gbGVmdCBjaGVj a2VkIGluIHNvIHRoYXQgdGhleSBjYW4gYmUgZmV0Y2hlZCBmcm9tIHhlbmJpdHMgdXNpbmcgdGhl DQo+IGdvbGFuZyB0b29saW5nLiAgVGhpcyBtZWFucyB0aGF0IHRoZXkgbXVzdCBiZSB1cGRhdGVk IHdoZW5ldmVyDQo+IGxpYnhsX3R5cGVzLmlkbCAob3Igb3RoZXIgZGVwZW5kZW5jaWVzKSBhcmUg dXBkYXRlZC4gIEhvd2V2ZXIsIHRoZQ0KPiBnb2xhbmcgYmluZGluZ3MgYXJlIG9ubHkgYnVpbHQg b3B0aW9uYWxseTsgd2UgY2FuJ3QgYXNzdW1lIHRoYXQgYW55b25lDQo+IHVwZGF0aW5nIGxpYnhs X3R5cGVzLmlkbCB3aWxsIGFsc28gZGVzY2VuZCBpbnRvIHRoZSB0b29scy9nb2xhbmcgdHJlZQ0K PiB0byByZS1nZW5lcmF0ZSB0aGUgYmluZGluZ3MuDQo+IA0KPiBGaXggdGhpcyBieSByZS1nZW5l cmF0aW5nIHRoZSBnb2xhbmcgYmluZGluZ3MgZnJvbSB0aGUgbGlieGwgTWFrZWZpbGUNCj4gd2hl biB0aGUgSURMIGRlcGVuZGVuY2llcyBhcmUgdXBkYXRlZCwgc28gdGhhdCBhbnlvbmUgd2hvIHVw ZGF0ZXMNCj4gbGlieGxfdHlwZXMuaWRsIHdpbGwgYWxzbyBlbmQgdXAgdXBkYXRpbmcgdGhlIGdv bGFuZyBnZW5lcmF0ZWQgZmlsZXMNCj4gYXMgd2VsbC4NCj4gDQo+IC0gTWFrZSBhIHZhcmlhYmxl IGZvciB0aGUgZ2VuZXJhdGVkIGZpbGVzLCBhbmQgYSB0YXJnZXQgaW4NCj4gICB4ZW5saWdodC9N YWtlZmlsZSB3aGljaCB3aWxsIG9ubHkgcmUtZ2VuZXJhdGUgdGhlIGZpbGVzLg0KPiANCj4gLSBB ZGQgYSB0YXJnZXQgaW4gbGlieGwvTWFrZWZpbGUgdG8gY2FsbCBleHRlcm5hbCBpZGwgZ2VuZXJh dGlvbg0KPiAgIHRhcmdldHMgKGN1cnJlbnRseSBvbmx5IGdvbGFuZykuDQoNChBTbyBhcyB3cml0 dGVuIHRoaXMgdHVybnMgb3V0IG5vdCB0byB3b3JrIGNvcnJlY3RseTogIGBnZW5nb3R5cGVzLnB5 YCBzcGl0cyBvdXQgc3ludGFjdGljYWxseSB2YWxpZCBidXQgdW5mb3JtYXR0ZWQgR28gY29kZSwg YW5kIHRoZW4gcnVucyBgZ28gZm10YCBvbiBpdCB0byBnZXQgdGhlIHJpZ2h0IHN0eWxlIChpbmNs dWRpbmcgdGFicywgJmMpLiAgQnV0IHRoZSBlcnJvciBjb2RlIG9mIGBnbyBmbXRgIGlzbuKAmXQg Y2hlY2tlZDsgc28gb24gYSBzeXN0ZW0gd2l0aG91dCBnbyBpbnN0YWxsZWQsIGlmIHRoZSBidWls ZCBzeXN0ZW0gZGVjaWRlcyBpdCBuZWVkcyB0byByZS1ydW4gYGdlbmdvdHlwZXMucHlgIGZvciB3 aGF0ZXZlciByZWFzb24sIHRoZSBidWlsZCBzdWNjZWVkcyBidXQgdGhlIHRyZWUgZW5kcyB1cCDi gJxkaXJ0aWVk4oCdIHdpdGggYW4gdW5mb3JtYXR0ZWQgdmVyc2lvbiBmbyB0aGUgZ2VuZXJhdGVk IHRleHQuDQoNClRoZSBzaW1wbGVzdCBzaG9ydC10ZXJtIHdheSB0byBmaXggdGhpcyB3b3VsZCBi ZSB0byByZW1vdmUgdGhlIGBnbyBmbXRgIGNhbGwgZnJvbSBgZ2VuZ290eXBlcy5weWAuICBJdOKA mXMgYWN0dWFsbHkgcmVsYXRpdmVseSB1bnVzdWFsIGZvciBnZW5lcmF0ZWQgY29kZSB0byBsb29r IHByZXR0eSAob3IgZXZlbiBiZSBsb29rZWQgYXQpLiAgV2UgY291bGQgYWxzbyBjb25zaWRlciBh ZGRpbmcgaW4gc29tZSDigJxtYW51YWzigJ0gZm9ybWF0dGluZyBpbiBnZW5nb3R5cGVzLnB5LCBs aWtlIGluZGVudGF0aW9uLCBzbyB0aGF0IGl0IGRvZXNu4oCZdCBsb29rIHRvbyB0ZXJyaWJsZS4N Cg0KTmljaywgZG8geW91IGhhdmUgdGltZSB0byB3b3JrIG9uIGEgcGF0Y2ggbGlrZSB0aGF0Pw0K DQogLUdlb3JnZQ== From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:46:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:46:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt0V-0004zg-Qe; Thu, 04 Jun 2020 16:46:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt0U-0004yw-Ax for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:46:18 +0000 X-Inumbo-ID: e91bdb28-a682-11ea-8993-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e91bdb28-a682-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 16:46:17 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DE86C2072E; Thu, 4 Jun 2020 16:46:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591289177; bh=NELNoHY3KOTWSTuVEaCyPLnvtKoBrCrIckPS0kLq3qY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FU9WWIpTZ0GOwcaVPjAEKey+JLvS2U2Ja2PujVG55s60/QLtvKmOlujrnfjLKHSj2 7AHItklziaoTvlt1FTFoJAfhF6vglsFgIAlMrTqhQaEyGg9jMpuHWZxDWkR5Lu45m9 OPx9hFZFeR2ooxo9wfyPF7oC2igMNOabxyPRnxhg= Date: Thu, 4 Jun 2020 09:46:16 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: =?UTF-8?Q?Andr=C3=A9_Przywara?= Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset In-Reply-To: Message-ID: References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-237091267-1591288954=:6774" Content-ID: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: cminyard@mvista.com, Stefano Stabellini , Julien Grall , roman@zededa.com, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-237091267-1591288954=:6774 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 4 Jun 2020, André Przywara wrote: > On 04/06/2020 17:24, Stefano Stabellini wrote: > > On Thu, 4 Jun 2020, André Przywara wrote: > >> On 04/06/2020 09:48, Julien Grall wrote: > >> > >> Hi, > >> > >>> On 03/06/2020 23:31, Stefano Stabellini wrote: > >>>> Touching the watchdog is required to be able to reboot the board. > >>> > >>> In general the preferred method is PSCI. Does it mean RPI 4 doesn't > >>> support PSCI at all? > >> > >> There is mainline Trusted Firmware (TF-A) support for the RPi4 for a few > >> months now, which includes proper PSCI support (both for SMP bringup and > >> system reset/shutdown). At least that should work, if not, it's a bug. > >> An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF-A > >> without it, with or without U-Boot: It works as a drop-in replacement > >> for armstub.bin. Instruction for building it (one line!) are here: > >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi4.rst > >> > >>>> > >>>> The implementation is based on > >>>> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > >>> > >>> Can you give the baseline? This would allow us to track an issue and > >>> port them. > >> > >> Given the above I don't think it's a good idea to add extra platform > >> specific code to Xen. > > > > The RPi4, at least the one I have, doesn't come with any TF, and it > > My RPi4 didn't come with anything, actually ;-) It's just a matter of > what you put in the uSD card slot. > > > doesn't come with PSCI in device tree. > > TF-A patches the PSCI nodes in: > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/plat/rpi/rpi4?id=f67fa69cb6937a7fc559bbec4a7acce5edefa888 > > > As a user, I would rather have > > this patch (even downstream) than having to introduce TF in my build and > > deployment just to be able to reboot. > > I get your point, but would rather put more pressure on people using > TF-A. After all you run without CPU hotplug, A72 errata workarounds and > without Spectre/Meltdown fixes. What was the IP address of your board > again? ;-) Please send a pull request to remove __bcm2835_restart from the Linux kernel, once it is removed from there I'd be happy to take it away from Xen too ;-) I know I am being cheeky but we have enough battles to fight and enough problems with Xen -- I don't think we should use the hypervisor as a leverage to get people to use or upgrade TF. We just need to get good functionalities to our users with the less amount of friction possible. Everything you mentioned are good reason to use TF, and this patch does not take anything away from it. My suggestion would be to work with raspberrypi.org to have TF installed by default by the Raspberry Pi Imager. --8323329-237091267-1591288954=:6774-- From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:48:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:48:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt2P-00054T-5H; Thu, 04 Jun 2020 16:48:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt2N-00054M-Re for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:48:15 +0000 X-Inumbo-ID: 2f54d16c-a683-11ea-8993-bc764e2007e4 Received: from mail-qk1-x742.google.com (unknown [2607:f8b0:4864:20::742]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2f54d16c-a683-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 16:48:15 +0000 (UTC) Received: by mail-qk1-x742.google.com with SMTP id w3so6716444qkb.6 for ; Thu, 04 Jun 2020 09:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=49KSsDYfaMp0JAKGbfCbqPQmJSRNYHSOckrgHd5Fxvo=; b=jWpNIzthP0qLhfuehNGCu+QIAqxQyLqCwL+6+SUi/LjTu9sEEJuH5eQ7qLqHoyRFEZ mJzLlz4fyc/4s22fuWq1rwAqXQvwGLholFYXYbRoDD0Jh8/gaetWsjDOtW71jBKtKoo4 vr4cFrJuz+Nw94ZHui+K4tuu0pvn/GI9hMwG6HtbzINex5YX/+ImMiSe1aIuBY6tmUyA EJY3OurwKLT14uYnw1yf8iIe0R+N1lOUlKMICByPFCE9b/9BB7sRQoc1I+6qC7rLgliq c/jS2NUddeKrZ5ohJTzs4Toj0v5JlRcY9xXmy4QYdOsluu1cKlQrwnWIg0y86ODt/pMW Q2OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=49KSsDYfaMp0JAKGbfCbqPQmJSRNYHSOckrgHd5Fxvo=; b=SjzgAcfhmNAp958FPe7DOuG9xFE6+9wL9MlQVNh6FGut+pgoeBi18ygmibgcyIA4XH fMForYjS71mIj4/4gzN9I022RbdpLFXyl2oivPw/dWU2vSEHAdEVRVC6jrWFGb0FrXUG ZYAs+yor0c7qFNgY9LN1nHoXaTa7n5we5i+jo7nu3ZJuLwZ4tTxabIBhkpxK/5v4sm4h LL/kMTHc7m9kwyQAJt3LfHKrUeZliA/Y+PIbBfNiYUkojk3p0GpF9YWqjqke9SyVbgwo pSCTPt5xCq5+qHHa7L9u51JO3gpvqxqfiQD/nfGijq45rCN/qJFp+HSnNmX7bEQBJs1Y imug== X-Gm-Message-State: AOAM5313UJRsKWy+K5vMFslUmLHB9zjO87ktQKYInIonLG0PVSvcqEPY 9YljCrj91qtZgYMK5y71/Abjb55u/CUCFChjIF6Qug== X-Google-Smtp-Source: ABdhPJxcV9vSRJGX61CYXDUU/0OSP61BA6T5ErtCI79Y97YsQvB1NHlQc+dweLTtnV87JwpO6j4dSJ7Ft5Fn86/0j/4= X-Received: by 2002:a05:620a:147:: with SMTP id e7mr5492235qkn.267.1591289295019; Thu, 04 Jun 2020 09:48:15 -0700 (PDT) MIME-Version: 1.0 References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> In-Reply-To: From: Roman Shaposhnik Date: Thu, 4 Jun 2020 09:48:03 -0700 Message-ID: Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: Julien Grall Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Corey Minyard , Stefano Stabellini , =?UTF-8?Q?Andr=C3=A9_Przywara?= , tamas@tklengyel.com, Xen-devel , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 4, 2020 at 9:36 AM Julien Grall wrote: > > Hi, > > On 04/06/2020 17:24, Stefano Stabellini wrote: > > On Thu, 4 Jun 2020, Andr=C3=A9 Przywara wrote: > >> On 04/06/2020 09:48, Julien Grall wrote: > >> > >> Hi, > >> > >>> On 03/06/2020 23:31, Stefano Stabellini wrote: > >>>> Touching the watchdog is required to be able to reboot the board. > >>> > >>> In general the preferred method is PSCI. Does it mean RPI 4 doesn't > >>> support PSCI at all? > >> > >> There is mainline Trusted Firmware (TF-A) support for the RPi4 for a f= ew > >> months now, which includes proper PSCI support (both for SMP bringup a= nd > >> system reset/shutdown). At least that should work, if not, it's a bug. > >> An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF= -A > >> without it, with or without U-Boot: It works as a drop-in replacement > >> for armstub.bin. Instruction for building it (one line!) are here: > >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/= plat/rpi4.rst > >> > >>>> > >>>> The implementation is based on > >>>> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > >>> > >>> Can you give the baseline? This would allow us to track an issue and > >>> port them. > >> > >> Given the above I don't think it's a good idea to add extra platform > >> specific code to Xen. > > > > The RPi4, at least the one I have, doesn't come with any TF, and it > > doesn't come with PSCI in device tree. As a user, I would rather have > > this patch (even downstream) than having to introduce TF in my build an= d > > deployment just to be able to reboot. > > So what are you using for the firmware? Do you boot Xen directly? You've got 3 options: 1. booting directly (see Dornernerworks build: https://github.com/dornerworks/xen-rpi4-builder/blob/master/rpixen.sh#L143) 2. booting via u-boot (with efiboot) 3. booting via honest, upstream UEFI (https://github.com/pftf/RPi4/releases/tag/v1.5) So far we've been mostly doing #2 since it is the most flexible one. Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:51:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:51:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt55-0005xg-K8; Thu, 04 Jun 2020 16:51:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt53-0005xa-Qo for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:51:01 +0000 X-Inumbo-ID: 9246fe94-a683-11ea-81bc-bc764e2007e4 Received: from mail-qk1-x72b.google.com (unknown [2607:f8b0:4864:20::72b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9246fe94-a683-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 16:51:01 +0000 (UTC) Received: by mail-qk1-x72b.google.com with SMTP id s1so6705518qkf.9 for ; Thu, 04 Jun 2020 09:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FBGB4XsK5b1qj5WNIKaL17NGc9eizHT9b9nWp44b7S0=; b=b4Nyf2MCwPXFrZ1eEP7n0atGpyWQBuRDTmlpA95HMEbXKwC55juaHNBsZ5uGtqXr7o lJz/2eosZcZ+lfF4rGxnxMASeTSLQq8reM7aMrOzUkpnQA7vTuSmBf3ISmpm7lnll7Gj Y/V2gc61vDtLvD6sG1w4JKz9jBmIB7l95OrX54/GQtMxeLgb+1B0gmgfAq95OLgBwGn4 iSCDrrOn1Ve89o6n5C7lkVnfqIcqlO3iKoOKSfCgarwH1c0p5C3tn+2p/EWlYnf0xgsj 1LFQ1Z4H0+DPlDQl0/O6O6me5q6UJpUU5AHWYYFRcR5IOQTMLc+qKbf4P4I9TpTRzVgL B8ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FBGB4XsK5b1qj5WNIKaL17NGc9eizHT9b9nWp44b7S0=; b=nZGNdnx1GLu0HPFhNPQCJraD7OZMl7B6l2b//KhZX5e0ofX4Lz0akJxTsrawIQ+d1L vgNLF2tNM9qPPr3zLouysh1E9XLw2tVygyiPk9kenqBjB7k1wCfNtH2Z37OHRFf69A/F wifpgxDl6YR7PKaNyepSXVOx8ptHeRktf9yEYVRPIKLLo4XjO/jpyRG7h1vVm2pWvjXc R7SdA4Q4AQpWSAHedBwilas099N1s3EovaN63YOzW7f/M+cH1tRCcrYG5txtWp/MTYlN 6gov9AVXDzR7AVwV7HcvXQMcupBC4UqEHUQOK92CNW0cxsYg2n4w0GZoKbLBBqerHJXe 4NAA== X-Gm-Message-State: AOAM530XCc+34dgS+Tt6a8sPDAbA4+a8ZM3BF5YN4/T2LLSgJFHbytKG wB2ncel8Cc5YHdy9lngnGNcQT4Mdawb1MamV0Pb4BGa2 X-Google-Smtp-Source: ABdhPJzAbqgo59c7H+4t6SE1G8SLFOml6zn+IzzNnYc8yD5d35YErpAOwQBlgNGajibC/vrYXSxbiascXfVpNNBrEFY= X-Received: by 2002:a05:620a:147:: with SMTP id e7mr5502750qkn.267.1591289461041; Thu, 04 Jun 2020 09:51:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shaposhnik Date: Thu, 4 Jun 2020 09:50:50 -0700 Message-ID: Subject: Re: UEFI support in ARM DomUs To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Peng Fan , Julien Grall , Nataliya Korovkina , Oleksandr Andrushchenko Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 4, 2020 at 8:31 AM Stefano Stabellini wrote: > > On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote: > > On 6/4/20 4:57 AM, Peng Fan wrote: > > > Grall ; > > >> Nataliya Korovkina > > >> Subject: UEFI support in ARM DomUs > > > We have made U-Boot run inside XEN DomU, but just only PV console part, > > > not implement other frontend drivers currently. Would this help for your > > > case if enable EFI in U-Boot? > > > > Well, we have a working PV block implementation on top of that on iMX8 > > > > platform, mostly ported from mini-os. Currently we are finalizing the work > > > > and cleaning up (it's going to take a week or so hopefully). Then, we we'll post > > > > it on our public github. We are also thinking about upstreaming the work, but it may > > > > take quite some time if the whole idea fits u-boot's view on such an extension at all. > > Yes please to both of you! :-) > > In the meantime, while we wait for those changes to go upstream in > uboot, could you please post a branch on github and a link on this email > thread? > > Maybe we should have a wikipage on wiki.xenproject.org about > work-in-progress uboot items. Yes!!! Speaking of which -- I've been meaning to update the wiki for quite a few things already, but I'm still waiting on someone (George?) to give user 'rvs' proper karma. Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:53:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:53:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt7M-00065k-5i; Thu, 04 Jun 2020 16:53:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt7L-00065f-Dj for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:53:23 +0000 X-Inumbo-ID: e68bb918-a683-11ea-8993-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e68bb918-a683-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 16:53:23 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1F70B20738; Thu, 4 Jun 2020 16:53:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591289602; bh=tTXrQF+jYnTBgxstYZvDBZo9b/K5xAO5D8pKbn9pQJ4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=qNur6mP9jZ8+lL+lkGJPy9naOxXwVADfri3ZZ/4BC2lF16sAnPTQ38qeu+oHfKNOV 4g+nKA0LCPcYYKOikp8EkaJpXmatx6+A4JoXd1msKANJc3Xho8ZmcXpEhLulAopGeQ lkLxpAXBmI8gACDGIRZk0jVmGUprfkle8UyxiP/M= Date: Thu, 4 Jun 2020 09:53:21 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset In-Reply-To: Message-ID: References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1078383510-1591289602=:6774" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: cminyard@mvista.com, Stefano Stabellini , =?UTF-8?Q?Andr=C3=A9_Przywara?= , roman@zededa.com, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1078383510-1591289602=:6774 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 4 Jun 2020, Julien Grall wrote: > Hi, > > On 04/06/2020 17:24, Stefano Stabellini wrote: > > On Thu, 4 Jun 2020, André Przywara wrote: > > > On 04/06/2020 09:48, Julien Grall wrote: > > > > > > Hi, > > > > > > > On 03/06/2020 23:31, Stefano Stabellini wrote: > > > > > Touching the watchdog is required to be able to reboot the board. > > > > > > > > In general the preferred method is PSCI. Does it mean RPI 4 doesn't > > > > support PSCI at all? > > > > > > There is mainline Trusted Firmware (TF-A) support for the RPi4 for a few > > > months now, which includes proper PSCI support (both for SMP bringup and > > > system reset/shutdown). At least that should work, if not, it's a bug. > > > An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF-A > > > without it, with or without U-Boot: It works as a drop-in replacement > > > for armstub.bin. Instruction for building it (one line!) are here: > > > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi4.rst > > > > > > > > > > > > > The implementation is based on > > > > > drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > > > > > > > Can you give the baseline? This would allow us to track an issue and > > > > port them. > > > > > > Given the above I don't think it's a good idea to add extra platform > > > specific code to Xen. > > > > The RPi4, at least the one I have, doesn't come with any TF, and it > > doesn't come with PSCI in device tree. As a user, I would rather have > > this patch (even downstream) than having to introduce TF in my build and > > deployment just to be able to reboot. > > So what are you using for the firmware? Do you boot Xen directly? The raspberry pi comes with its own firmware/bootloader. It is possible to boot Linux from it directly, that's how it comes configured by default. For Xen, I am booting uboot from the RPi bootloader first, mostly because uboot is very convenient and adds tftp support which I use to load Xen and Linux. (I think it would be possible to boot Xen directly from the RPi firmware/bootloader but it would probably require some work to get dom0 to load too.) --8323329-1078383510-1591289602=:6774-- From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:54:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:54:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt8K-0006CY-FW; Thu, 04 Jun 2020 16:54:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgt8J-0006CO-1I for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:54:23 +0000 X-Inumbo-ID: 0a0d6ca6-a684-11ea-8993-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0a0d6ca6-a684-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 16:54:22 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BA63920738; Thu, 4 Jun 2020 16:54:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591289662; bh=Zl0hrsGzj9cil62c+jGNmHMczbRxow76mes3BLiZASc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eanfuantrZAal7bwR7a6S0xwR4ri8gYlQmivhBUWcWiHAFBJiOXWNoyi8oqPn57Fb YQm7/3x6D/mtnBn2iLxUlwsK8BjQMpnyFe7511uYLSL5NayeKxZixPoM8Omt6R6Zht Q/j9GSW9V5icJu7NGkPClSWWFBeKul8/sSuqhe8E= Date: Thu, 4 Jun 2020 09:54:21 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Roman Shaposhnik Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset In-Reply-To: Message-ID: References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1440638441-1591289662=:6774" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Corey Minyard , Stefano Stabellini , Julien Grall , =?UTF-8?Q?Andr=C3=A9_Przywara?= , tamas@tklengyel.com, Xen-devel , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1440638441-1591289662=:6774 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 4 Jun 2020, Roman Shaposhnik wrote: > On Thu, Jun 4, 2020 at 9:36 AM Julien Grall wrote: > > > > Hi, > > > > On 04/06/2020 17:24, Stefano Stabellini wrote: > > > On Thu, 4 Jun 2020, André Przywara wrote: > > >> On 04/06/2020 09:48, Julien Grall wrote: > > >> > > >> Hi, > > >> > > >>> On 03/06/2020 23:31, Stefano Stabellini wrote: > > >>>> Touching the watchdog is required to be able to reboot the board. > > >>> > > >>> In general the preferred method is PSCI. Does it mean RPI 4 doesn't > > >>> support PSCI at all? > > >> > > >> There is mainline Trusted Firmware (TF-A) support for the RPi4 for a few > > >> months now, which includes proper PSCI support (both for SMP bringup and > > >> system reset/shutdown). At least that should work, if not, it's a bug. > > >> An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF-A > > >> without it, with or without U-Boot: It works as a drop-in replacement > > >> for armstub.bin. Instruction for building it (one line!) are here: > > >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi4.rst > > >> > > >>>> > > >>>> The implementation is based on > > >>>> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > >>> > > >>> Can you give the baseline? This would allow us to track an issue and > > >>> port them. > > >> > > >> Given the above I don't think it's a good idea to add extra platform > > >> specific code to Xen. > > > > > > The RPi4, at least the one I have, doesn't come with any TF, and it > > > doesn't come with PSCI in device tree. As a user, I would rather have > > > this patch (even downstream) than having to introduce TF in my build and > > > deployment just to be able to reboot. > > > > So what are you using for the firmware? Do you boot Xen directly? > > You've got 3 options: > 1. booting directly (see Dornernerworks build: > https://github.com/dornerworks/xen-rpi4-builder/blob/master/rpixen.sh#L143) Ah! I didn't realize they were booting directly, nice! --8323329-1440638441-1591289662=:6774-- From xen-devel-bounces@lists.xenproject.org Thu Jun 04 16:59:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 16:59:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtCq-0006Ny-07; Thu, 04 Jun 2020 16:59:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtCo-0006Nt-LY for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 16:59:02 +0000 X-Inumbo-ID: b0782b76-a684-11ea-81bc-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b0782b76-a684-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 16:59:01 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: zBxrXxW1NKsizCqIwCu8DyfbL2NqTlo9YvzPdRw8qFYcPe3Tdw9CIXz4DhfKL/jvfLjIcn74JO vV8jyOCnX+N0B7DFoUdm4FecGBGEo1L68UQ4BMPJ8bv7iYAI2yb5CP8Y3HKp59g25j01Y8iL8G ZgrAsGPLT12/avmeUre+/wsFSSzJ/uO2c5SX0NeVQ1dpjg4koYK59dsuHWlEzoplZSNroehFub P4u+tocZO2X+3tZP6/FA55C2BpgA3Os3eH+eQjb4RmhDsXaeYIVf/80Y5m/0xucsTelbqY/BE1 au8= X-SBRS: 2.7 X-MesageID: 19499881 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="19499881" From: George Dunlap To: Roman Shaposhnik Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOC+BaY+gtpA/Okm3pVStoso6DajFzoEAgALCeQA= Date: Thu, 4 Jun 2020 16:58:58 +0000 Message-ID: <82519E50-54C5-49F9-9955-D6D23BE636B1@citrix.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Stefano Stabellini , Nataliya Korovkina , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On Jun 2, 2020, at 11:50 PM, Roman Shaposhnik wrote: >=20 > On Mon, Jun 1, 2020 at 9:12 AM Stefano Stabellini > wrote: >>=20 >> + George >>=20 >> On Sun, 31 May 2020, Roman Shaposhnik wrote: >>> Hi Julien! >>>=20 >>> On Sun, May 31, 2020 at 3:24 PM Julien Grall wrote: >>>>=20 >>>> On Sun, 31 May 2020 at 23:05, Roman Shaposhnik wrot= e: >>>>> Hi! >>>>>=20 >>>>> with a lot of help from Stefano, we're getting RPi4 support in >>>>> Project EVE pretty much on par between KVM and Xen. >>>>>=20 >>>>> One big area that still remains is supporting UEFI boot sequence >>>>> for DomUs. With KVM, given the qemu virt device model this is >>>>> as simple as using either stock UEFI build for arm or even U-Boot >>>>> EFI emulation environment and passing it via -bios option. >>>>>=20 >>>>> Obviously with Xen on ARM we don't have the device model so >>>>> my understanding is that the easiest way we can support it would >>>>> be to port UEFI's OvmfPkg/OvmfXen target to ARM (it seems to >>>>> be currently exclusively X64). >>>>=20 >>>> EDK2 has been supporting Xen on Arm for the past 5 years. We don't use >>>> OvmfPkg/OvmfXen but ArmVirtPkg/ArmVirtXen (see [1]). >>>> I haven't tried to build it recently, but I should be able to help if >>>> there is any issue with it. >>>>=20 >>>> Cheers, >>>>=20 >>>> [1] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/ArmVirtXe= n.fdf >>>=20 >>> This is really, really awesome -- I guess it would be really helpful to= document >>> this someplace on the ARM/Xen wiki (I can volunteer if someone can gran= t >>> me the karma). >>=20 >> Regarding the wiki: yes please! Let George know if you don't have write = access. >=20 > Hey Geroge -- FWIW: my wiki account name is rvs -- please let me know > once you enable whatever needs to be enabled for my write access. Hmm, not sure if I have the appropriate permissions yet. Let me look into = this. -George= From xen-devel-bounces@lists.xenproject.org Thu Jun 04 17:14:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 17:14:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtRF-0008Df-Ai; Thu, 04 Jun 2020 17:13:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtRD-0008Da-IG for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 17:13:55 +0000 X-Inumbo-ID: c47ac8e8-a686-11ea-81bc-bc764e2007e4 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id c47ac8e8-a686-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 17:13:54 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C52531FB; Thu, 4 Jun 2020 10:13:53 -0700 (PDT) Received: from [192.168.2.22] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7649A3F6CF; Thu, 4 Jun 2020 10:13:52 -0700 (PDT) Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: Stefano Stabellini References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> From: =?UTF-8?Q?Andr=c3=a9_Przywara?= Autocrypt: addr=andre.przywara@arm.com; prefer-encrypt=mutual; keydata= xsFNBFNPCKMBEAC+6GVcuP9ri8r+gg2fHZDedOmFRZPtcrMMF2Cx6KrTUT0YEISsqPoJTKld tPfEG0KnRL9CWvftyHseWTnU2Gi7hKNwhRkC0oBL5Er2hhNpoi8x4VcsxQ6bHG5/dA7ctvL6 kYvKAZw4X2Y3GTbAZIOLf+leNPiF9175S8pvqMPi0qu67RWZD5H/uT/TfLpvmmOlRzNiXMBm kGvewkBpL3R2clHquv7pB6KLoY3uvjFhZfEedqSqTwBVu/JVZZO7tvYCJPfyY5JG9+BjPmr+ REe2gS6w/4DJ4D8oMWKoY3r6ZpHx3YS2hWZFUYiCYovPxfj5+bOr78sg3JleEd0OB0yYtzTT esiNlQpCo0oOevwHR+jUiaZevM4xCyt23L2G+euzdRsUZcK/M6qYf41Dy6Afqa+PxgMEiDto ITEH3Dv+zfzwdeqCuNU0VOGrQZs/vrKOUmU/QDlYL7G8OIg5Ekheq4N+Ay+3EYCROXkstQnf YYxRn5F1oeVeqoh1LgGH7YN9H9LeIajwBD8OgiZDVsmb67DdF6EQtklH0ycBcVodG1zTCfqM AavYMfhldNMBg4vaLh0cJ/3ZXZNIyDlV372GmxSJJiidxDm7E1PkgdfCnHk+pD8YeITmSNyb 7qeU08Hqqh4ui8SSeUp7+yie9zBhJB5vVBJoO5D0MikZAODIDwARAQABzS1BbmRyZSBQcnp5 d2FyYSAoQVJNKSA8YW5kcmUucHJ6eXdhcmFAYXJtLmNvbT7CwXsEEwECACUCGwMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheABQJTWSV8AhkBAAoJEAL1yD+ydue63REP/1tPqTo/f6StS00g NTUpjgVqxgsPWYWwSLkgkaUZn2z9Edv86BLpqTY8OBQZ19EUwfNehcnvR+Olw+7wxNnatyxo D2FG0paTia1SjxaJ8Nx3e85jy6l7N2AQrTCFCtFN9lp8Pc0LVBpSbjmP+Peh5Mi7gtCBNkpz KShEaJE25a/+rnIrIXzJHrsbC2GwcssAF3bd03iU41J1gMTalB6HCtQUwgqSsbG8MsR/IwHW XruOnVp0GQRJwlw07e9T3PKTLj3LWsAPe0LHm5W1Q+euoCLsZfYwr7phQ19HAxSCu8hzp43u zSw0+sEQsO+9wz2nGDgQCGepCcJR1lygVn2zwRTQKbq7Hjs+IWZ0gN2nDajScuR1RsxTE4WR lj0+Ne6VrAmPiW6QqRhliDO+e82riI75ywSWrJb9TQw0+UkIQ2DlNr0u0TwCUTcQNN6aKnru ouVt3qoRlcD5MuRhLH+ttAcmNITMg7GQ6RQajWrSKuKFrt6iuDbjgO2cnaTrLbNBBKPTG4oF D6kX8Zea0KvVBagBsaC1CDTDQQMxYBPDBSlqYCb/b2x7KHTvTAHUBSsBRL6MKz8wwruDodTM 4E4ToV9URl4aE/msBZ4GLTtEmUHBh4/AYwk6ACYByYKyx5r3PDG0iHnJ8bV0OeyQ9ujfgBBP B2t4oASNnIOeGEEcQ2rjzsFNBFNPCKMBEACm7Xqafb1Dp1nDl06aw/3O9ixWsGMv1Uhfd2B6 it6wh1HDCn9HpekgouR2HLMvdd3Y//GG89irEasjzENZPsK82PS0bvkxxIHRFm0pikF4ljIb 6tca2sxFr/H7CCtWYZjZzPgnOPtnagN0qVVyEM7L5f7KjGb1/o5EDkVR2SVSSjrlmNdTL2Rd zaPqrBoxuR/y/n856deWqS1ZssOpqwKhxT1IVlF6S47CjFJ3+fiHNjkljLfxzDyQXwXCNoZn BKcW9PvAMf6W1DGASoXtsMg4HHzZ5fW+vnjzvWiC4pXrcP7Ivfxx5pB+nGiOfOY+/VSUlW/9 GdzPlOIc1bGyKc6tGREH5lErmeoJZ5k7E9cMJx+xzuDItvnZbf6RuH5fg3QsljQy8jLlr4S6 8YwxlObySJ5K+suPRzZOG2+kq77RJVqAgZXp3Zdvdaov4a5J3H8pxzjj0yZ2JZlndM4X7Msr P5tfxy1WvV4Km6QeFAsjcF5gM+wWl+mf2qrlp3dRwniG1vkLsnQugQ4oNUrx0ahwOSm9p6kM CIiTITo+W7O9KEE9XCb4vV0ejmLlgdDV8ASVUekeTJkmRIBnz0fa4pa1vbtZoi6/LlIdAEEt PY6p3hgkLLtr2GRodOW/Y3vPRd9+rJHq/tLIfwc58ZhQKmRcgrhtlnuTGTmyUqGSiMNfpwAR AQABwsFfBBgBAgAJBQJTTwijAhsMAAoJEAL1yD+ydue64BgP/33QKczgAvSdj9XTC14wZCGE U8ygZwkkyNf021iNMj+o0dpLU48PIhHIMTXlM2aiiZlPWgKVlDRjlYuc9EZqGgbOOuR/pNYA JX9vaqszyE34JzXBL9DBKUuAui8z8GcxRcz49/xtzzP0kH3OQbBIqZWuMRxKEpRptRT0wzBL O31ygf4FRxs68jvPCuZjTGKELIo656/Hmk17cmjoBAJK7JHfqdGkDXk5tneeHCkB411p9WJU vMO2EqsHjobjuFm89hI0pSxlUoiTL0Nuk9Edemjw70W4anGNyaQtBq+qu1RdjUPBvoJec7y/ EXJtoGxq9Y+tmm22xwApSiIOyMwUi9A1iLjQLmngLeUdsHyrEWTbEYHd2sAM2sqKoZRyBDSv ejRvZD6zwkY/9nRqXt02H1quVOP42xlkwOQU6gxm93o/bxd7S5tEA359Sli5gZRaucpNQkwd KLQdCvFdksD270r4jU/rwR2R/Ubi+txfy0dk2wGBjl1xpSf0Lbl/KMR5TQntELfLR4etizLq Xpd2byn96Ivi8C8u9zJruXTueHH8vt7gJ1oax3yKRGU5o2eipCRiKZ0s/T7fvkdq+8beg9ku fDO4SAgJMIl6H5awliCY2zQvLHysS/Wb8QuB09hmhLZ4AifdHyF1J5qeePEhgTA+BaUbiUZf i4aIXCH3Wv6K Organization: ARM Ltd. Message-ID: <6c5912f1-29b1-dd27-6072-1b9acb49646f@arm.com> Date: Thu, 4 Jun 2020 18:12:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: cminyard@mvista.com, tamas@tklengyel.com, Julien Grall , roman@zededa.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 17:46, Stefano Stabellini wrote: > On Thu, 4 Jun 2020, André Przywara wrote: >> On 04/06/2020 17:24, Stefano Stabellini wrote: >>> On Thu, 4 Jun 2020, André Przywara wrote: >>>> On 04/06/2020 09:48, Julien Grall wrote: >>>> >>>> Hi, >>>> >>>>> On 03/06/2020 23:31, Stefano Stabellini wrote: >>>>>> Touching the watchdog is required to be able to reboot the board. >>>>> >>>>> In general the preferred method is PSCI. Does it mean RPI 4 doesn't >>>>> support PSCI at all? >>>> >>>> There is mainline Trusted Firmware (TF-A) support for the RPi4 for a few >>>> months now, which includes proper PSCI support (both for SMP bringup and >>>> system reset/shutdown). At least that should work, if not, it's a bug. >>>> An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF-A >>>> without it, with or without U-Boot: It works as a drop-in replacement >>>> for armstub.bin. Instruction for building it (one line!) are here: >>>> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi4.rst >>>> >>>>>> >>>>>> The implementation is based on >>>>>> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. >>>>> >>>>> Can you give the baseline? This would allow us to track an issue and >>>>> port them. >>>> >>>> Given the above I don't think it's a good idea to add extra platform >>>> specific code to Xen. >>> >>> The RPi4, at least the one I have, doesn't come with any TF, and it >> >> My RPi4 didn't come with anything, actually ;-) It's just a matter of >> what you put in the uSD card slot. >> >>> doesn't come with PSCI in device tree. >> >> TF-A patches the PSCI nodes in: >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/plat/rpi/rpi4?id=f67fa69cb6937a7fc559bbec4a7acce5edefa888 >> >>> As a user, I would rather have >>> this patch (even downstream) than having to introduce TF in my build and >>> deployment just to be able to reboot. >> >> I get your point, but would rather put more pressure on people using >> TF-A. After all you run without CPU hotplug, A72 errata workarounds and >> without Spectre/Meltdown fixes. What was the IP address of your board >> again? ;-) > > Please send a pull request to remove __bcm2835_restart from the Linux > kernel, once it is removed from there I'd be happy to take it away from > Xen too ;-) The kernel needs to support all RPi models, so we definitely need this. Also it's already in there, so removing it is more churn. The reason I am bringing this up is that we should get away from those platform specific files in Xen at all. The only reason we have it for the RPi4 is the non-page-aligned MMIO regions and overlaps, which could actually be determined much better at runtime ... > I know I am being cheeky but we have enough battles to fight and enough > problems with Xen -- I don't think we should use the hypervisor as a > leverage to get people to use or upgrade TF. We just need to get good > functionalities to our users with the less amount of friction possible. As I said: it's not my call, just pointing that out. It's just sad that people everywhere work around the limited firmware instead of doing it properly. > Everything you mentioned are good reason to use TF, and this patch does > not take anything away from it. My suggestion would be to work with > raspberrypi.org to have TF installed by default by the Raspberry Pi > Imager. As far as I know there are (were?) efforts underway. For years ;-) Cheers, Andre From xen-devel-bounces@lists.xenproject.org Thu Jun 04 17:19:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 17:19:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtWS-0008Ok-Us; Thu, 04 Jun 2020 17:19:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtWQ-0008OC-Sz for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 17:19:18 +0000 X-Inumbo-ID: 85998bfe-a687-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 85998bfe-a687-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 17:19:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=gyUeud3LAHOQgArjc8k9cmbOBFeQ4cDOX7SmrC9NY90=; b=RupD+k6Ldk8z1x8bgfjerbCVXq lgWAF8lhO2wE/17bNw6yv+JuQ87nFUJ+SAyrBBjmNp/pAaFI05VOazcyMbtt82Qexs9gYmvW+JfcK K4KHNX0ouJSpFFXgHhoLFaIq/HvcSkgjOtGK0vfupgnBMYHL8QMR3mK14COt9VZCwMbg=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtWN-0002OE-Qk; Thu, 04 Jun 2020 17:19:15 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jgtWN-0005bf-It; Thu, 04 Jun 2020 17:19:15 +0000 Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset To: Stefano Stabellini , =?UTF-8?Q?Andr=c3=a9_Przywara?= References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> From: Julien Grall Message-ID: Date: Thu, 4 Jun 2020 18:19:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, roman@zededa.com, tamas@tklengyel.com, Stefano Stabellini , cminyard@mvista.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 17:46, Stefano Stabellini wrote: > On Thu, 4 Jun 2020, André Przywara wrote: >> On 04/06/2020 17:24, Stefano Stabellini wrote: >>> On Thu, 4 Jun 2020, André Przywara wrote: >>>> On 04/06/2020 09:48, Julien Grall wrote: >>>> >>>> Hi, >>>> >>>>> On 03/06/2020 23:31, Stefano Stabellini wrote: >>>>>> Touching the watchdog is required to be able to reboot the board. >>>>> >>>>> In general the preferred method is PSCI. Does it mean RPI 4 doesn't >>>>> support PSCI at all? >>>> >>>> There is mainline Trusted Firmware (TF-A) support for the RPi4 for a few >>>> months now, which includes proper PSCI support (both for SMP bringup and >>>> system reset/shutdown). At least that should work, if not, it's a bug. >>>> An EDK-2 build for RPi4 bundles TF-A automatically, but you can use TF-A >>>> without it, with or without U-Boot: It works as a drop-in replacement >>>> for armstub.bin. Instruction for building it (one line!) are here: >>>> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/plat/rpi4.rst >>>> >>>>>> >>>>>> The implementation is based on >>>>>> drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. >>>>> >>>>> Can you give the baseline? This would allow us to track an issue and >>>>> port them. >>>> >>>> Given the above I don't think it's a good idea to add extra platform >>>> specific code to Xen. >>> >>> The RPi4, at least the one I have, doesn't come with any TF, and it >> >> My RPi4 didn't come with anything, actually ;-) It's just a matter of >> what you put in the uSD card slot. >> >>> doesn't come with PSCI in device tree. >> >> TF-A patches the PSCI nodes in: >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/plat/rpi/rpi4?id=f67fa69cb6937a7fc559bbec4a7acce5edefa888 >> >>> As a user, I would rather have >>> this patch (even downstream) than having to introduce TF in my build and >>> deployment just to be able to reboot. >> >> I get your point, but would rather put more pressure on people using >> TF-A. After all you run without CPU hotplug, A72 errata workarounds and >> without Spectre/Meltdown fixes. What was the IP address of your board >> again? ;-) > > Please send a pull request to remove __bcm2835_restart from the Linux > kernel, once it is removed from there I'd be happy to take it away from > Xen too ;-) Xen is not a slave of Linux. We make our own informed decision ;). > > I know I am being cheeky but we have enough battles to fight and enough > problems with Xen -- I don't think we should use the hypervisor as a > leverage to get people to use or upgrade TF. We just need to get good > functionalities to our users with the less amount of friction possible. Well it is nice to have functionality but you also need to have Xen running reliably and safely. No-one wants to drive in car with no brake on a windy road. Or maybe I am wrong? ;) > > Everything you mentioned are good reason to use TF, and this patch does > not take anything away from it. My suggestion would be to work with > raspberrypi.org to have TF installed by default by the . We actually did use the hypervisor as a leverage in the past. A pretty good example is RPI 3. Anyway, the patch is pretty simple and limited to the platform. So I would be inclined to accept it. Although this is just sweeping stability concern under the carpet and hoping for the best. What are the odds this is going to be used in production like that? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 17:47:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 17:47:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtxt-0002gx-9a; Thu, 04 Jun 2020 17:47:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtxs-0002gs-NP for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 17:47:40 +0000 X-Inumbo-ID: 7b07b932-a68b-11ea-8993-bc764e2007e4 Received: from userp2130.oracle.com (unknown [156.151.31.86]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7b07b932-a68b-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 17:47:38 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 054Hg1B1108564; Thu, 4 Jun 2020 17:47:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : from : to : cc : references : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=H+yjHdHVMgAwN/YdZHBsmqCfOgg0+bl2Ldo7Ah9xkgY=; b=h/tHb5PG66kAghNFzUd4Vx1LQoi84zpsyWuil5mUNGpR75OinkDaDwpEWmF82WG66zPA 9HQSynWSTEUs4S+nwEVmkL8TvXLYIV69wL30uXv0J5rd79GuLgJiEW/GBIyy5tKFf52+ Po6sn/SimYgWZQAeivgWvl5yWSTver6PhtoJo2K5NpejDCyDkyw6JJGhDuhdsICAU2kC 54hI2iCtEVFoCGmQ90vIj2wK+1lHF2YLMo/yO4Yf5rdW4UUewUKbgyzrEnJr1bGqsS45 x2QeRmLAsAcLoR7f0C2QSjjbkMZ36FOXSRyDj+7+GKndxG3v7EkwFlr3vaWS6C91apHy cw== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 31evvn2ukg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 04 Jun 2020 17:47:36 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 054HbPvP128619; Thu, 4 Jun 2020 17:47:36 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 31c1e25s33-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Jun 2020 17:47:36 +0000 Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 054HlY4G002987; Thu, 4 Jun 2020 17:47:34 GMT Received: from [10.39.223.159] (/10.39.223.159) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Jun 2020 10:47:34 -0700 Subject: Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations From: boris.ostrovsky@oracle.com To: Stefano Stabellini , jgross@suse.com, konrad.wilk@oracle.com References: <20200603222247.11681-8-sstabellini@kernel.org> Organization: Oracle Corporation Message-ID: <4aba4b53-5f24-6c7e-d874-682313eb1798@oracle.com> Date: Thu, 4 Jun 2020 13:47:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9642 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 adultscore=0 suspectscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006040123 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9642 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 cotscore=-2147483648 suspectscore=0 phishscore=0 clxscore=1015 malwarescore=0 mlxscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 adultscore=0 mlxlogscore=999 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006040123 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, tamas@tklengyel.com, linux-kernel@vger.kernel.org, Stefano Stabellini , roman@zededa.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/4/20 1:46 PM, Boris Ostrovsky wrote: > On 6/3/20 6:22 PM, Stefano Stabellini wrote: >> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c >> index 0a6cb67f0fc4..60ef07440905 100644 >> --- a/drivers/xen/swiotlb-xen.c >> +++ b/drivers/xen/swiotlb-xen.c >> @@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) > > Weren't you going to rename this to xen_phys_to_dma()? (And the the one > below to xen_dma_to_phys())? Nevermind, I see you did that in the next patch. -boris From xen-devel-bounces@lists.xenproject.org Thu Jun 04 17:48:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 17:48:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtyo-0002m0-Jg; Thu, 04 Jun 2020 17:48:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgtyn-0002lr-Sy for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 17:48:37 +0000 X-Inumbo-ID: 9e04b4d0-a68b-11ea-9dbe-bc764e2007e4 Received: from userp2120.oracle.com (unknown [156.151.31.85]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9e04b4d0-a68b-11ea-9dbe-bc764e2007e4; Thu, 04 Jun 2020 17:48:37 +0000 (UTC) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 054HmahN121097; Thu, 4 Jun 2020 17:48:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=LH/X5HxwQdBaUYabhBH9v/jDWKVE1Mx/V+ryFL/r/5I=; b=uIb0KSi2lCSG9pB7uHG2rQSkHiEdNBMHRjWQcoI6PkASryhYM2u32quzzOFQfmSFnJru oSfloPZM//pCXRqPwpcxaI2XXMuEnhBTJZWYZ01cPU97m6r5RcD0mDhEpVWsoevY0dxN SVzNj72cCfH3oVoQTwqll4aQgmzjmBxTFjj6Kxt6u+dmE08Tu2yoGSzAkySwTFFEjpBn IE9lF1mj4Trymo9Unfo+4e/wJlPrHhzeIUjGuBFaR6ujPpMocsKPmQ9DgzsAVLXw26TD qHy+ZE9x0FhFeMriK9YycGcHnRiE/nrHaZzHyoYjChtZOgJJK08g/kGvDPiNkROJNG2D RA== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 31ev96u2ct-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 04 Jun 2020 17:48:35 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 054Hc7An123543; Thu, 4 Jun 2020 17:46:35 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 31dju5c7ys-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Jun 2020 17:46:35 +0000 Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 054HkXaM002314; Thu, 4 Jun 2020 17:46:33 GMT Received: from [10.39.203.50] (/10.39.203.50) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Jun 2020 10:46:30 -0700 Subject: Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations To: Stefano Stabellini , jgross@suse.com, konrad.wilk@oracle.com References: <20200603222247.11681-8-sstabellini@kernel.org> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: Date: Thu, 4 Jun 2020 13:46:28 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200603222247.11681-8-sstabellini@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9642 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 mlxscore=0 adultscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006040123 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9642 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 malwarescore=0 priorityscore=1501 cotscore=-2147483648 impostorscore=0 spamscore=0 phishscore=0 mlxscore=0 clxscore=1015 bulkscore=0 mlxlogscore=999 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006040124 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, tamas@tklengyel.com, linux-kernel@vger.kernel.org, Stefano Stabellini , roman@zededa.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/3/20 6:22 PM, Stefano Stabellini wrote: > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c > index 0a6cb67f0fc4..60ef07440905 100644 > --- a/drivers/xen/swiotlb-xen.c > +++ b/drivers/xen/swiotlb-xen.c > @@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct dev= ice *dev, phys_addr_t paddr) Weren't you going to rename this to xen_phys_to_dma()? (And the the one below to xen_dma_to_phys())? -boris > =20 > dma |=3D paddr & ~XEN_PAGE_MASK; > =20 > - return dma; > + return phys_to_dma(dev, dma); > } > =20 > -static inline phys_addr_t xen_bus_to_phys(struct device *dev, dma_addr= _t baddr) > +static inline phys_addr_t xen_bus_to_phys(struct device *dev, > + dma_addr_t dma_addr) > { > + phys_addr_t baddr =3D dma_to_phys(dev, dma_addr); > unsigned long xen_pfn =3D bfn_to_pfn(XEN_PFN_DOWN(baddr)); > - dma_addr_t dma =3D (dma_addr_t)xen_pfn << XEN_PAGE_SHIFT; > - phys_addr_t paddr =3D dma; > - > - paddr |=3D baddr & ~XEN_PAGE_MASK; > + phys_addr_t paddr =3D (xen_pfn << XEN_PAGE_SHIFT) | > + (baddr & ~XEN_PAGE_MASK); > =20 From xen-devel-bounces@lists.xenproject.org Thu Jun 04 18:25:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 18:25:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jguXx-0006Um-FC; Thu, 04 Jun 2020 18:24:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jguXv-0006Uh-4v for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 18:24:55 +0000 X-Inumbo-ID: afe91718-a690-11ea-9947-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id afe91718-a690-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 18:24:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=o2u7qRwIyA6KctdfLGyL3Welp9ALHkwiNc9pTMz3FFQ=; b=20ytp0FBg7R51BGBpDWkPmN2aR lqrLBXyGtY7AwnRONBzgWLvgSH6lfPOhRHqumhitKGO4QgFLwJ3o38TRVRtVV6xDamrjq6oBt2pKz stUw+INya/GKEeQLGeUt+xKxqfQeFtP+ZVmfPKNsVC4HDajBfzBfWLO7dvKqeQBj6118=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jguXu-0003o2-9C; Thu, 04 Jun 2020 18:24:54 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jguXu-0001GI-2r; Thu, 04 Jun 2020 18:24:54 +0000 Subject: Re: Keystone Issue To: CodeWiz2280 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> From: Julien Grall Message-ID: Date: Thu, 4 Jun 2020 19:24:52 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 04/06/2020 13:07, CodeWiz2280 wrote: > On Thu, Jun 4, 2020 at 6:16 AM Julien Grall wrote: >> >> Hi, >> >> On 04/06/2020 10:08, Bertrand Marquis wrote: >>> I would have thought that linux would have need some memory, even small in the 32bit space in order to boot. >> >> Yes it needs some, but then they are switching to use the high memory >> alias after the MMU has been switch on. >> >> From my understanding, the only difference is the page-tables will >> point to the high memory alias address rather than the low memory one. >> Linux will still be located at the same place but now accessed from the >> high memory alias rather than the low one. >> >> Note that AFAICT the secondary CPUs will still be brought-up using the >> low memory alias. >> >>> I could understand that some memory in the low address space needs to be reserved by Linux as DMA area for peripherals not supporting 36-bit addresses, but the whole low memory sounds like a big restriction. >> Many platforms have devices only supporting 32-bit DMA, but none of them >> require such aliasing. So this doesn't look to be the issue here. >> >> TBH, this code is only used by Keystone and switching address space is >> expensive (you have to turn off the MMU, updates page-tables, flush the >> cache...). I find hard to believe a developper would have come up with >> this complexity if it were possible to always use the low memory address >> range. It is even harder to believe Linux community would have accepted it. >> >>> >>> Would it be possible to have a bit more information on the “problem with peripherals” here ? >> >> I am curious as well, so I looked in more depth :). Going through the >> Linux history, one of the commit message [1] suggests they are switching >> to a coherent address space. The datasheet [2] (page 75) also confirm >> that the low region is not IO coherent. >> >> So I think you would not be able to do DMA without flush the cache which >> can be pretty expensive. For a PoC, it might be possible to force Linux >> flushing the area before and after each DMA request. This should be >> possible by marking the devices as not coherent. >> >> Although, I am not entirely sure if there is any fallout. >> >> @Dave, do you think it is possible for you to have a try? I can provide >> the patch for Linux to disable DMA coherency if possible. > I attempted to do that, where I removed the "dma-coherent" flags from > the device tree. There are likely other issues, but the most glaring > problem that I ran into is that the ethernet does not work. Eth0 > shows up in ifconfig but there is no activity on it after a small > handful of message exchanges, whereas booting without Xen it seems to > work fine even if left in 32-bit mode (with the dma-coherent > disabled). I don't know what implications behind the scenes there are > trying to stay in the lower 0x8000_0000 alias range either though. Thank you for the answer. As wrote, Linux is working fine in 32-bit mode when dma-coherent is left in 32-bit mode. So this suggest a different issue on the platform. Given that you receive an handful of packet and then nothing, this would lead to maybe an interrupt problem. Can you check whether the number of interrupts increments the same way on baremetal and on Xen? Dumping /proc/interrupts should be sufficient. > I > would rather run it as intended by switching to the upper > 0x8_0000_0000 alias region. I agree this would be ideal :). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 04 18:29:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 18:29:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgucb-0006f3-1J; Thu, 04 Jun 2020 18:29:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgucY-0006ey-VJ for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 18:29:43 +0000 X-Inumbo-ID: 5b8309f8-a691-11ea-9dbe-bc764e2007e4 Received: from mail-qk1-x72f.google.com (unknown [2607:f8b0:4864:20::72f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5b8309f8-a691-11ea-9dbe-bc764e2007e4; Thu, 04 Jun 2020 18:29:42 +0000 (UTC) Received: by mail-qk1-x72f.google.com with SMTP id w1so7123698qkw.5 for ; Thu, 04 Jun 2020 11:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=CJA+hJ4ec5VLveyR3UagHk4xdzxq7p5jRQtG2F/X6bU=; b=vKDu4lQWqCxp1NgCJMEt11L0IHZGi37HECbkTi6hzZ4H54AsQjwCrqUilo+oIJl/MP yYfKdQ2DxG7ksAv7Uq0btH9fyG1c9O29fUcPHSqa1BTrmY3HaOiLXkgt1R751Ump0ni4 aEGq7Ui4jvt6EkF4UMH9VzvpXV+SHnMqOzHATbBSH5x4T49uCq2NraqHktKZoc0KqugH 7L/7C5TevAO/9ZsfSJpyYTV6Oho8tQKsG0FGcqDt7BrtOBh2XiLEPxWVAZ7UplqAsJx/ n+EwWXxAvGju4yUsqtmiuYBQamHnQ0Fjp9OLxb/NDydaYLIRYUSuZNxE6hMBRF8kuPPZ SxIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=CJA+hJ4ec5VLveyR3UagHk4xdzxq7p5jRQtG2F/X6bU=; b=T7D3Y8S7oD5UZPbsW4RY1q8gdhgMHlFQuZQOFemd3hTAkkRUpFcuzJZ0sYuFRE/JUr j339s9NS0C7ikZrHsF5ftYtBEADtW8j91KebPBdbYqu1nid7ON8iVYFgFdHCemuGNKJB 2F13tlVFK2rDH5nMTQZDMJHUoNZO4DrAwpkVWq3qavIC94OAJNeFOEW0IMWu/vXjshEV HitqMi5rE4NAdVZowmKRuZcDl5RbSgT2d+3BLRu2KTWQEbTNSMxgnGnB6UfTSJbCYVhw uExtmY7pMphJeL/Ib41fMYZ+aQMvbiaQZCu+DUNbvqStIv5nfOuVeBYmhnrvhecxcj2C dltA== X-Gm-Message-State: AOAM530Va2PfZLvBiZ5578cxDiwfEAI4ELoBWCdw4q297QnW4GKH1VG8 wOVNBItmgR7++12VL8+Md2k= X-Google-Smtp-Source: ABdhPJx2ED58lZs4YjATtbxalaJYUotC9VyC+IQ3SDxiuYWG7Mq914reT3S60ysH/wYEjoGDi7VT+A== X-Received: by 2002:a37:a0b:: with SMTP id 11mr6018192qkk.501.1591295382043; Thu, 04 Jun 2020 11:29:42 -0700 (PDT) Received: from six (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252]) by smtp.gmail.com with ESMTPSA id b12sm4888250qkk.43.2020.06.04.11.29.40 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 04 Jun 2020 11:29:41 -0700 (PDT) Date: Thu, 4 Jun 2020 14:29:38 -0400 From: Nick Rosbrook To: George Dunlap Subject: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile Message-ID: <20200604182938.GA10975@six> References: <20200526221612.900922-1-george.dunlap@citrix.com> <20200526221612.900922-2-george.dunlap@citrix.com> <5CF4AE1D-C80C-4E4C-B4AA-0779E7DC53E7@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5CF4AE1D-C80C-4E4C-B4AA-0779E7DC53E7@citrix.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , xen-devel , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > The simplest short-term way to fix this would be to remove the `go fmt` call from `gengotypes.py`. It’s actually relatively unusual for generated code to look pretty (or even be looked at). We could also consider adding in some “manual” formatting in gengotypes.py, like indentation, so that it doesn’t look too terrible. > > Nick, do you have time to work on a patch like that? Yes, I have time to work on a quick patch for this. I'll see what it would take to add a bit of basic manual formatting, but of course the original purpose of using gofmt was to avoid re-creating formatting logic. I'll likely just remove the call to go fmt. Out of curiosity, would it be totally out of the question to require having gofmt installed (not for 4.14, but in the future)? I ask because I haven't seen it discussed one way or the other. Thanks, -NR From xen-devel-bounces@lists.xenproject.org Thu Jun 04 18:32:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 18:32:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgufe-0007Wd-Gr; Thu, 04 Jun 2020 18:32:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgufd-0007WX-Kk for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 18:32:53 +0000 X-Inumbo-ID: ccc7de04-a691-11ea-9947-bc764e2007e4 Received: from aserp2120.oracle.com (unknown [141.146.126.78]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ccc7de04-a691-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 18:32:53 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 054IMfnt017698; Thu, 4 Jun 2020 18:32:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=A4QZV2GTyDxhLtS6+iS2i/ZvHsElXA2WyGUlklwEGnM=; b=Qa27ZUGz9DCwHY8//UGyndpQtZM8OTtJLKL87gPXMPJ1+UI0yxLiBYbVv3y8mDapbtPF BmoTaeForzupxSAS6Ojm4FcF8M5cDRZveNMuCXX2dog5xGNBErd4sBrf1rSkfu/71nVW Es8D9fyfIuwoOdl2rj37Il37NS4Ca+n8VmxN/37nXQjUMC300nMD6FMhYFWmJFNVdzcM VMD+XedB1vkozfELx7kkIxRpN0yAQj35zt79rFmhkPh7EsQya37LII0zOi6m7tLDMxXK 1+kEW0DJkBTanjedxpcmiTfUOTnhzrOv6Wj3qP1+NU+s/Jp/8ZVpvVP4fG/VTaNcUjI1 1w== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 31evap37qv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 04 Jun 2020 18:32:48 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 054IJNmJ172543; Thu, 4 Jun 2020 18:32:47 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 31c1e27fgd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Jun 2020 18:32:47 +0000 Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 054IWjtu000814; Thu, 4 Jun 2020 18:32:45 GMT Received: from [10.39.203.50] (/10.39.203.50) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Jun 2020 11:32:45 -0700 Subject: Re: [PATCH v2 00/11] fix swiotlb-xen for RPi4 To: Stefano Stabellini , jgross@suse.com, konrad.wilk@oracle.com References: From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <359d08b7-974e-f755-6019-9fa043cc9921@oracle.com> Date: Thu, 4 Jun 2020 14:32:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9642 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 adultscore=0 suspectscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006040129 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9642 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 phishscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006040129 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, julien.grall@arm.com, tamas@tklengyel.com, linux-kernel@vger.kernel.org, roman@zededa.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/3/20 6:22 PM, Stefano Stabellini wrote: > Hi all, > > This series is a collection of fixes to get Linux running on the RPi4 a= s > dom0. > > Conceptually there are only two significant changes: > > - make sure not to call virt_to_page on vmalloc virt addresses (patch > #1) > - use phys_to_dma and dma_to_phys to translate phys to/from dma > addresses (all other patches) > > In particular in regards to the second part, the RPi4 is the first > board where Xen can run that has the property that dma addresses are > different from physical addresses, and swiotlb-xen was written with the= > assumption that phys addr =3D=3D dma addr. > > This series adds the phys_to_dma and dma_to_phys calls to make it work.= > > Cheers, > > Stefano (+ Julien) Reviewed-by: Boris Ostrovsky From xen-devel-bounces@lists.xenproject.org Thu Jun 04 18:34:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 18:34:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgugj-0007eS-VS; Thu, 04 Jun 2020 18:34:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgugi-0007eE-Lm for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 18:34:00 +0000 X-Inumbo-ID: f4e1a8de-a691-11ea-81bc-bc764e2007e4 Received: from smtp-fw-9101.amazon.com (unknown [207.171.184.25]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f4e1a8de-a691-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 18:34:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591295641; x=1622831641; h=date:from:to:cc:message-id:references:mime-version: in-reply-to:subject; bh=HTqcTU628wYZT8oBd+ArbsC8bAoTC8fUsqm9xVXgmro=; b=SAaXs7pokykunMTWUj65jwQyokdkFbwc0cGtac2kn5UVn3+HVsvG+gWi RCIQdqIQ0E9upBydp+072qA8IL/Qyn/Uqng4kYlpJGNhu+yOsquCbXQvv EURfAnvUNJHdqggaImjBcUiZo70kqda3l4ioZlU0JL71TlhMJOChO1hNS o=; IronPort-SDR: Bp9sXjz5OL6Qmgdn1t2NjI2Ij78oRPs1ANk1UfVNxYHuSJrPGMGuWQ5o01KOARrU4ThWIT/DpG g10L4tLv3oVA== X-IronPort-AV: E=Sophos;i="5.73,472,1583193600"; d="scan'208";a="41639696" Subject: Re: [PATCH 09/12] x86/xen: save and restore steal clock Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 04 Jun 2020 18:33:58 +0000 Received: from EX13MTAUEB002.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2a-90c42d1d.us-west-2.amazon.com (Postfix) with ESMTPS id 2AEAAA22B6; Thu, 4 Jun 2020 18:33:56 +0000 (UTC) Received: from EX13D08UEB004.ant.amazon.com (10.43.60.142) by EX13MTAUEB002.ant.amazon.com (10.43.60.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 18:33:36 +0000 Received: from EX13MTAUEB002.ant.amazon.com (10.43.60.12) by EX13D08UEB004.ant.amazon.com (10.43.60.142) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 18:33:36 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.60.234) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 4 Jun 2020 18:33:36 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 5663D403BB; Thu, 4 Jun 2020 18:33:36 +0000 (UTC) Date: Thu, 4 Jun 2020 18:33:36 +0000 From: Anchal Agarwal To: Boris Ostrovsky Message-ID: <20200604183336.GA25251@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <6f39a1594a25ab5325f34e1e297900d699cd92bf.1589926004.git.anchalag@amazon.com> <5edb4147-af12-3a0e-e8f7-5b72650209ac@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <5edb4147-af12-3a0e-e8f7-5b72650209ac@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: eduval@amazon.com, len.brown@intel.com, peterz@infradead.org, benh@kernel.crashing.org, x86@kernel.org, linux-mm@kvack.org, pavel@ucw.cz, hpa@zytor.com, sstabellini@kernel.org, kamatam@amazon.com, mingo@redhat.com, xen-devel@lists.xenproject.org, sblbir@amazon.com, axboe@kernel.dk, konrad.wilk@oracle.com, anchalag@amazon.com, bp@alien8.de, tglx@linutronix.de, jgross@suse.com, netdev@vger.kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, vkuznets@redhat.com, davem@davemloft.net, dwmw@amazon.co.uk, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sat, May 30, 2020 at 07:44:06PM -0400, Boris Ostrovsky wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On 5/19/20 7:28 PM, Anchal Agarwal wrote: > > From: Munehisa Kamata > > > > Save steal clock values of all present CPUs in the system core ops > > suspend callbacks. Also, restore a boot CPU's steal clock in the system > > core resume callback. For non-boot CPUs, restore after they're brought > > up, because runstate info for non-boot CPUs are not active until then. > > > > Signed-off-by: Munehisa Kamata > > Signed-off-by: Anchal Agarwal > > --- > > arch/x86/xen/suspend.c | 13 ++++++++++++- > > arch/x86/xen/time.c | 3 +++ > > 2 files changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c > > index 784c4484100b..dae0f74f5390 100644 > > --- a/arch/x86/xen/suspend.c > > +++ b/arch/x86/xen/suspend.c > > @@ -91,12 +91,20 @@ void xen_arch_suspend(void) > > static int xen_syscore_suspend(void) > > { > > struct xen_remove_from_physmap xrfp; > > - int ret; > > + int cpu, ret; > > > > /* Xen suspend does similar stuffs in its own logic */ > > if (xen_suspend_mode_is_xen_suspend()) > > return 0; > > > > + for_each_present_cpu(cpu) { > > + /* > > + * Nonboot CPUs are already offline, but the last copy of > > + * runstate info is still accessible. > > + */ > > + xen_save_steal_clock(cpu); > > + } > > + > > xrfp.domid = DOMID_SELF; > > xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT; > > > > @@ -118,6 +126,9 @@ static void xen_syscore_resume(void) > > > > pvclock_resume(); > > > Doesn't make any difference but I think since this patch is where you > are dealing with clock then pvclock_resume() should be added here and > not in the earlier patch. > > > -boris I think the reason it may be in previous patch because it was a part of syscore_resume and steal clock fix came in later. It could me moved to this patch that deals with all clock stuff. -Anchal > > > > > > + /* Nonboot CPUs will be resumed when they're brought up */ > > + xen_restore_steal_clock(smp_processor_id()); > > + > > gnttab_resume(); > > } > > > > diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c > > index c8897aad13cd..33d754564b09 100644 > > --- a/arch/x86/xen/time.c > > +++ b/arch/x86/xen/time.c > > @@ -545,6 +545,9 @@ static void xen_hvm_setup_cpu_clockevents(void) > > { > > int cpu = smp_processor_id(); > > xen_setup_runstate_info(cpu); > > + if (cpu) > > + xen_restore_steal_clock(cpu); > > + > > /* > > * xen_setup_timer(cpu) - snprintf is bad in atomic context. Hence > > * doing it xen_hvm_cpu_notify (which gets called by smp_init during > > > From xen-devel-bounces@lists.xenproject.org Thu Jun 04 20:13:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 20:13:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwEu-0000DT-Nj; Thu, 04 Jun 2020 20:13:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwEt-0000Cx-Su for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 20:13:23 +0000 X-Inumbo-ID: d67ae6e0-a69f-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d67ae6e0-a69f-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 20:13:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e0eVbrkSh4tcZBwFitQBczGU8lE9EqdXCjDf0dzaMcQ=; b=eSgCyFyZe//E+WfvaDW6dvLpT zGo+Agp7j5/3aH02yw47BCjmA3bMjdgO91s6PBDITcR++Bb8797zmFVu6z90UYc5gNv0hcnuDar+g UCD5GVVrjXZBxM8udc1r3sGvsGWH8gVzeT6xeGArUxYXBTzClK2GFvGwwGskoKDecPGco=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwEr-00066v-6j; Thu, 04 Jun 2020 20:13:21 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgwEq-0000zK-QI; Thu, 04 Jun 2020 20:13:20 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgwEq-0003lZ-Pg; Thu, 04 Jun 2020 20:13:20 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150694: tolerable FAIL - PUSHED X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e X-Osstest-Versions-That: qemuu=5cc7a54c2e91d82cb6a52e4921325c511fd90712 From: osstest service owner Date: Thu, 04 Jun 2020 20:13:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150694 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150694/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150631 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150631 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150631 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150631 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150631 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150631 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150631 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e baseline version: qemuu 5cc7a54c2e91d82cb6a52e4921325c511fd90712 Last test of basis 150631 2020-06-02 23:27:48 Z 1 days Testing same since 150694 2020-06-04 11:44:20 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alistair Francis Bin Meng Peter Maydell jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/qemu-xen.git 5cc7a54c2e..66234fee9c 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e -> upstream-tested From xen-devel-bounces@lists.xenproject.org Thu Jun 04 20:18:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 20:18:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwJo-0000P3-C8; Thu, 04 Jun 2020 20:18:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwJn-0000Ox-Kd for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 20:18:27 +0000 X-Inumbo-ID: 893c79a6-a6a0-11ea-81bc-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 893c79a6-a6a0-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 20:18:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l0uq6O4krP262rp+A/XIV1TbxyijkADKDEIiRNhsFhM=; b=5Tvjt+soVQZpjnTldkao1G397 gw4yhwQjYwycpX0jWWGLgEmCgfumc5Q7dlSbQra+QDgHTj/EhMid5EakTvDug9eRBE6xK7Zjkvpnc FZs3QHw795q+k1/9mdWrNWObxVSPy4TOTcwDSdYFmcPwBr9moWZZA4EiCzAFXPjvHSIPQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwJh-0006Do-Et; Thu, 04 Jun 2020 20:18:21 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgwJh-00018g-7O; Thu, 04 Jun 2020 20:18:21 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgwJh-0004ub-6q; Thu, 04 Jun 2020 20:18:21 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150702: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d9f58cd54fe2f05e1f05e2fe254684bd1840de8e X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Thu, 04 Jun 2020 20:18:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150702 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150702/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d9f58cd54fe2f05e1f05e2fe254684bd1840de8e baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 7 days Failing since 150465 2020-05-29 09:02:14 Z 6 days 47 attempts Testing same since 150649 2020-06-03 13:01:44 Z 1 days 9 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1522 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 04 20:31:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 20:31:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwWZ-0002CO-Mj; Thu, 04 Jun 2020 20:31:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwWX-0002CJ-SV for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 20:31:38 +0000 X-Inumbo-ID: 620b1a16-a6a2-11ea-8993-bc764e2007e4 Received: from USG02-CY1-obe.outbound.protection.office365.us (unknown [2001:489a:2202:d::625]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 620b1a16-a6a2-11ea-8993-bc764e2007e4; Thu, 04 Jun 2020 20:31:35 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=SE8SKJZSt6xQNEmGLgiV9GF8P6Okk4uzWhZUcN0q7YBtwFPiJ15kiVZZ34J9ftidUYYPIw5yO+g3PkJuTN1Evb8v06EyHATSh0mRzvdPJUwbfbinB5dR5zhFS5KtLxvmr/Hj4qkfKDkcYxnVShZjvZYPrPaYXUiGqmbF7F11mtHZ+GoFIXfH4LkHLyVpQFolhwehjyUyS6CvlZjXX3iTcOFcT2c9hqQ9rLGLH+O+35pGlLd25Wt2Xb8z77K7zFzXvL6SaY2e+M2IvvtsAfj2kJyQWPGprMIGnvLsq23CA/gvqc/fWdALUkYe3wl0Is5BYUNF2IRNpH8/+iX8kpEVWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=59mar/+RoylVT7yyoQC/RF9nvtJV+CcBIhHU3qYaAlk=; b=f4NHssBaYPqqOjdGWrtEByGWKa4u+1NmB/PeDvdS9z9AQfhAxXnvwzqaKERoETfRxw2lhGBMVbiuSuBQ1SZ7+uZeaLNNm2U/ys8VwFaEaBOJ7s/LaVLMf3zlhApeg/QckYd4lorXb9H3pA0ziDzaRxXKQHPDdv58/GlFcluDyeIJ7Jx/t+kJVQQnv7yhS1XLb9JRq/1Njl6nO9XbFLeurTTxU0oTSTxISvbaQkjeabJFTeCFWHZBaVDKE0aT5XMsfNwLO4JT3FdnKQbw0KgcWat1A7XxRPv6Vb3JLPDSzwBxaXvqtKe+mU0Y3q1tuUmwn4GEN346KJRMbaw9Elwm5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ainfosec.com; dmarc=pass action=none header.from=ainfosec.com; dkim=pass header.d=ainfosec.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ainfosec.onmicrosoft.com; s=selector1-ainfosec-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=59mar/+RoylVT7yyoQC/RF9nvtJV+CcBIhHU3qYaAlk=; b=ToRj2T5rBoREdV1c19KfM49WHjkjOp4kt7RjuB/S52+hEGCtM6ixecBZagDHiTiVjMenbej8We9szpL1EtMq3mcPYZQtnAE5ac2lxmy2OY9/D48T6t+W6lG3ZCLtvNIK5mr1FwbH6TVMoCjUD4pJXeg+tmHYWLU5igzJf5UbUdQ= Received: from SN5P110MB0575.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:41c::18) by SN5P110MB0430.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:41a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.32; Thu, 4 Jun 2020 20:31:32 +0000 Received: from SN5P110MB0575.NAMP110.PROD.OUTLOOK.COM ([fe80::fc21:c1b1:b54f:8bc4]) by SN5P110MB0575.NAMP110.PROD.OUTLOOK.COM ([fe80::fc21:c1b1:b54f:8bc4%10]) with mapi id 15.20.3021.036; Thu, 4 Jun 2020 20:31:32 +0000 From: Rian Quinn To: "xen-devel@lists.xenproject.org" Subject: Bareflank Hypervisor Community Call on 6/12/2020 at 3pm UTC Thread-Topic: Bareflank Hypervisor Community Call on 6/12/2020 at 3pm UTC Thread-Index: AQHWOq5p5w+0IvuZ4k2F8eRFCHspnQ== Date: Thu, 4 Jun 2020 20:31:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=ainfosec.com; x-originating-ip: [2601:283:4600:d83:5d70:a85c:ba25:790d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa32afe3-e9cb-4c16-9016-08d808c644f5 x-ms-traffictypediagnostic: SN5P110MB0430: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 04244E0DC5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN5P110MB0575.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(366004)(86362001)(8936002)(4744005)(5660300002)(83380400001)(52536014)(8676002)(9686003)(498600001)(33656002)(55016002)(66476007)(64756008)(186003)(966005)(71200400001)(2906002)(7696005)(6506007)(66556008)(6916009)(66946007)(66446008)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ainfosec.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa32afe3-e9cb-4c16-9016-08d808c644f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 20:31:32.4036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 82614573-95ee-4948-be35-3c0a8fc6ff9c X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN5P110MB0430 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" During the Xen Community Call today, I was asked to forward information abo= ut the Bareflank Community Call taking place next week.=A0=0A= =0A= The Zoom information for this call will be posted to this issue prior to th= e meeting. Also, if you have something specific you would like to add to th= e agenda, please post it to this ticket as well.=A0=0A= https://github.com/Bareflank/hypervisor/issues/915=0A= =0A= Thanks,=0A= Rian Quinn=0A= =0A= From xen-devel-bounces@lists.xenproject.org Thu Jun 04 20:53:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 20:53:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwr3-00045P-FD; Thu, 04 Jun 2020 20:52:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwr1-00045K-Vu for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 20:52:48 +0000 X-Inumbo-ID: 57f02e4c-a6a5-11ea-9dbe-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 57f02e4c-a6a5-11ea-9dbe-bc764e2007e4; Thu, 04 Jun 2020 20:52:46 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 1kMOpVy3ctgqYlT+UbIEH6sLSUAD2XqAn/s1CTLwT/vgKdmqdxbmPM5Mv0eCQUb1t0ravf5nWy 8jazkTu23leOedKQeuvXwO5N51v18RK6NwyjNj/Q6lrBBhi9ED6p4V+C+65fXf6K/qtD1YiOya bXtwgla+Wa6REtsgHMCGBNnFWzUd1/ao/fPYyklsPRcAXz9Ss3PHf9QptuxKoKkAo7ksXxISN+ R0+6A7zs//anF7sSH++PZcddxvb4NtqnlYyn+3N666r6IPrkToezzAM1LNbQ+SFxjk5aL2Jmua 8yY= X-SBRS: 2.7 X-MesageID: 20027619 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="20027619" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14 RFC] docs/support-matrix: Gross bodge to unbreak docs rendering Date: Thu, 4 Jun 2020 21:52:26 +0100 Message-ID: <20200604205226.14518-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Paul Durrant , Jan Beulich , Anthony PERARD , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a while. commitish_version() pulls an old version of xen/Makefile out of history, and uses the xenversion rule. Currently, this fails with: tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory which is because the Makefile legitimately references Kbuild.include with a relative rather than absolute path. Rearrange $CWD of the make rune to be in xen/ Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall CC: Anthony PERARD CC: Paul Durrant This is obviously not a proper fix. It will break in an unfixable way if we ever delete a file from the xen/ build system. I don't think pulling a makefile out of history and expecting it to work in the current working tree is a reasonable expectation. --- docs/support-matrix-generate | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate index a3d93321f1..2a1c3fad57 100755 --- a/docs/support-matrix-generate +++ b/docs/support-matrix-generate @@ -102,8 +102,8 @@ commitish_version () { esac git cat-file blob "$commitish:$versionfile" >"$tmp_versionfile" - version=$(make --no-print-directory -C docs \ - -f "${tmp_versionfile#docs/}" xenversion) + version=$(make --no-print-directory -C xen \ + -f "../${tmp_versionfile}" xenversion) case "$version" in *.*.*) version="${version%.*}" ;; esac -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Thu Jun 04 20:58:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 20:58:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwwP-0004Fs-3H; Thu, 04 Jun 2020 20:58:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwwN-0004Fn-Ni for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 20:58:19 +0000 X-Inumbo-ID: 1bd3447a-a6a6-11ea-af24-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1bd3447a-a6a6-11ea-af24-12813bfff9fa; Thu, 04 Jun 2020 20:58:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cXleue4jdFK6juHlo3vuHIo3vcTf/U53qu1kYErayEc=; b=ocRVSTEdJ8fsDkzCjeQaspXaV uaKV6ekzQheWmYVQo/7QceJMWaAUL6kAy6W+ck0ZYPimk2Y8Er0fCqSfmeqcKoKsihizvOg31Whzn gdAqsG21ceNP5b/pw8O+/A0fkfGOsRCgU/BCTKZFEd10MzHlCs13xCp9chJlmVFfm+hZY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwwI-00072l-Gd; Thu, 04 Jun 2020 20:58:14 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgwwI-0002Re-23; Thu, 04 Jun 2020 20:58:14 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgwwI-0000px-1S; Thu, 04 Jun 2020 20:58:14 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150691: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-examine:reboot:fail:regression linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=6929f71e46bdddbf1c4d67c2728648176c67c555 X-Osstest-Versions-That: linux=f6aee505c71bbb035dde146caf5a6abbf3ccbe47 From: osstest service owner Date: Thu, 04 Jun 2020 20:58:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150691 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150691/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-examine 8 reboot fail REGR. vs. 150663 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 150663 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150663 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150663 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150663 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150663 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150663 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150663 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150663 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150663 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: linux 6929f71e46bdddbf1c4d67c2728648176c67c555 baseline version: linux f6aee505c71bbb035dde146caf5a6abbf3ccbe47 Last test of basis 150663 2020-06-03 18:38:46 Z 1 days Testing same since 150680 2020-06-04 06:12:40 Z 0 days 2 attempts ------------------------------------------------------------ 690 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine fail test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 79962 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 04 20:58:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 20:58:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwwX-0004HY-D7; Thu, 04 Jun 2020 20:58:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgwwW-0004HO-2h for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 20:58:28 +0000 X-Inumbo-ID: 22d85db4-a6a6-11ea-81bc-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 22d85db4-a6a6-11ea-81bc-bc764e2007e4; Thu, 04 Jun 2020 20:58:27 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: NTr8wPCtadSgKrmYquzmaqZQe+gEChFrGnrWsg7LpnJPJBDJnMvF9mwXNUfohEZGdSoUOm7UMM 4E2UV2Ab6p+jca8C1gzoI2tDS30Nh3QWiBfYij+GpZjSAilVT05QGcUNM2YiPOM6Q2TY6yTA/k jQqfTNS2QIC1d8Gcqa5QNbP1QVuePJn6W/N543oThOLfSiIZel+DDf2oFPyFM8QvTKBPZ4hTW8 7CoScj2ED75gKDXp8yrSlEMR67+ascYe20qrS5I3jhvyigvErQMB1oBqA/WVEM84biIxnBjb/m Wqw= X-SBRS: 2.7 X-MesageID: 19567633 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,472,1583211600"; d="scan'208";a="19567633" Subject: Re: [PATCH for-4.14 RFC] docs/support-matrix: Gross bodge to unbreak docs rendering To: Xen-devel References: <20200604205226.14518-1-andrew.cooper3@citrix.com> From: Andrew Cooper Message-ID: Date: Thu, 4 Jun 2020 21:58:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200604205226.14518-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Paul Durrant , Jan Beulich , Anthony PERARD , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04/06/2020 21:52, Andrew Cooper wrote: > The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a > while. commitish_version() pulls an old version of xen/Makefile out of > history, and uses the xenversion rule. > > Currently, this fails with: > > tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory > > which is because the Makefile legitimately references Kbuild.include with a > relative rather than absolute path. > > Rearrange $CWD of the make rune to be in xen/ > > Signed-off-by: Andrew Cooper > --- > CC: George Dunlap > CC: Ian Jackson > CC: Jan Beulich > CC: Konrad Rzeszutek Wilk > CC: Stefano Stabellini > CC: Wei Liu > CC: Julien Grall > CC: Anthony PERARD > CC: Paul Durrant > > This is obviously not a proper fix. It will break in an unfixable way if we > ever delete a file from the xen/ build system. > > I don't think pulling a makefile out of history and expecting it to work in > the current working tree is a reasonable expectation. Actually - it occurs to me that we only want the major and minor number. I think it is reasonable to expect that those will always be plain numbers, and we can grep them directly out of the file, rather than feeding the thing to make. Thoughts? ~Andrew > --- > docs/support-matrix-generate | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate > index a3d93321f1..2a1c3fad57 100755 > --- a/docs/support-matrix-generate > +++ b/docs/support-matrix-generate > @@ -102,8 +102,8 @@ commitish_version () { > esac > > git cat-file blob "$commitish:$versionfile" >"$tmp_versionfile" > - version=$(make --no-print-directory -C docs \ > - -f "${tmp_versionfile#docs/}" xenversion) > + version=$(make --no-print-directory -C xen \ > + -f "../${tmp_versionfile}" xenversion) > case "$version" in > *.*.*) version="${version%.*}" ;; > esac From xen-devel-bounces@lists.xenproject.org Thu Jun 04 23:04:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 04 Jun 2020 23:04:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgytx-0007qL-Os; Thu, 04 Jun 2020 23:03:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgytv-0007qG-Sh for xen-devel@lists.xenproject.org; Thu, 04 Jun 2020 23:03:55 +0000 X-Inumbo-ID: aa20ad9c-a6b7-11ea-9947-bc764e2007e4 Received: from smtp-fw-4101.amazon.com (unknown [72.21.198.25]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id aa20ad9c-a6b7-11ea-9947-bc764e2007e4; Thu, 04 Jun 2020 23:03:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591311836; x=1622847836; h=date:from:to:cc:message-id:references:mime-version: in-reply-to:subject; bh=XlvjY2cbK79XKJQbABj6I52DuwNCmkoPmmNUgRZuzx4=; b=FsgtDi4Pv7uJuxVHUmYuYmjeDKtjri0bEhdXdULKxXlXZik0elc8l+1H Okxa5LoVs10W2+uh5dWu2Zf9V5m9t2BE0I58KYm4xTOcr/TBdkUTsGe8X xlus2sPLU/yRrLu7yrqqc7QwunL6zfIgt1D1iFB1k5N0GuJGFiMgyqMB0 I=; IronPort-SDR: BU/B31Mc2p1teKXE8T0M/Qekrk1iOuiIqPmHAVira61H+IDlK+H6BZmL2NxaskgX4guwfy+OUc I5F/nNdpGkaw== X-IronPort-AV: E=Sophos;i="5.73,472,1583193600"; d="scan'208";a="34541182" Subject: Re: [PATCH 03/12] x86/xen: Introduce new function to map HYPERVISOR_shared_info on Resume Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-57e1d233.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 04 Jun 2020 23:03:43 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-57e1d233.us-east-1.amazon.com (Postfix) with ESMTPS id 7E52614194D; Thu, 4 Jun 2020 23:03:35 +0000 (UTC) Received: from EX13D05UWC001.ant.amazon.com (10.43.162.82) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 23:03:07 +0000 Received: from EX13MTAUWC001.ant.amazon.com (10.43.162.135) by EX13D05UWC001.ant.amazon.com (10.43.162.82) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Jun 2020 23:03:07 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.162.232) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 4 Jun 2020 23:03:07 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 705A940712; Thu, 4 Jun 2020 23:03:07 +0000 (UTC) Date: Thu, 4 Jun 2020 23:03:07 +0000 From: Anchal Agarwal To: Boris Ostrovsky Message-ID: <20200604230307.GB25251@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <529f544a64bb93b920bf86b1d3f86d93b0a4219b.1589926004.git.anchalag@amazon.com> <72989b50-0c13-7a2b-19e2-de4a3646c83f@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <72989b50-0c13-7a2b-19e2-de4a3646c83f@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: eduval@amazon.com, len.brown@intel.com, peterz@infradead.org, benh@kernel.crashing.org, x86@kernel.org, linux-mm@kvack.org, pavel@ucw.cz, hpa@zytor.com, sstabellini@kernel.org, kamatam@amazon.com, mingo@redhat.com, xen-devel@lists.xenproject.org, sblbir@amazon.com, axboe@kernel.dk, konrad.wilk@oracle.com, bp@alien8.de, tglx@linutronix.de, jgross@suse.com, netdev@vger.kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, vkuznets@redhat.com, davem@davemloft.net, dwmw@amazon.co.uk, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sat, May 30, 2020 at 07:02:01PM -0400, Boris Ostrovsky wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On 5/19/20 7:25 PM, Anchal Agarwal wrote: > > Introduce a small function which re-uses shared page's PA allocated > > during guest initialization time in reserve_shared_info() and not > > allocate new page during resume flow. > > It also does the mapping of shared_info_page by calling > > xen_hvm_init_shared_info() to use the function. > > > > Signed-off-by: Anchal Agarwal > > --- > > arch/x86/xen/enlighten_hvm.c | 7 +++++++ > > arch/x86/xen/xen-ops.h | 1 + > > 2 files changed, 8 insertions(+) > > > > diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c > > index e138f7de52d2..75b1ec7a0fcd 100644 > > --- a/arch/x86/xen/enlighten_hvm.c > > +++ b/arch/x86/xen/enlighten_hvm.c > > @@ -27,6 +27,13 @@ > > > > static unsigned long shared_info_pfn; > > > > +void xen_hvm_map_shared_info(void) > > +{ > > + xen_hvm_init_shared_info(); > > + if (shared_info_pfn) > > + HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn)); > > +} > > + > > > AFAICT it is only called once so I don't see a need for new routine. > > HYPERVISOR_shared_info can only be mapped in this scope without refactoring much of the code. > And is it possible for shared_info_pfn to be NULL in resume path (which > is where this is called)? > > I don't think it should be, still a sanity check but I don't think its needed there because hibernation will fail in any case if thats the case. However, HYPERVISOR_shared_info does needs to be re-mapped on resume as its been marked to dummy address on suspend. Its also safe in case va changes. Does the answer your question? > -boris -Anchal > > From xen-devel-bounces@lists.xenproject.org Fri Jun 05 00:01:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 00:01:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgzn1-0005VJ-Nl; Fri, 05 Jun 2020 00:00:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgzn0-0005VE-4f for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 00:00:50 +0000 X-Inumbo-ID: 9d02dfec-a6bf-11ea-8993-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9d02dfec-a6bf-11ea-8993-bc764e2007e4; Fri, 05 Jun 2020 00:00:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VvMcz+Ql1QVb2AdeGDMvMHJ59t5yy8GLLfduanSRg+g=; b=aKoDwhGOyrKJvZ28HJ0bqmfHc qCBpEmECNdfI5G9Dv20FCvwzJWZWuVeTnY01K4DG6JfQUgyd6L9ISfEWbjZtcsofrvCimyyId/7wu vUXjKSR26PIHtwQIBWgTk00RTJB39K0u0Sj3bUAFWaQ5jfTSvSZp08x57yAUCyY7UoJEI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jgzmy-00030o-Ba; Fri, 05 Jun 2020 00:00:48 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jgzmy-0001hL-3J; Fri, 05 Jun 2020 00:00:48 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jgzmy-0007gE-2b; Fri, 05 Jun 2020 00:00:48 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150708: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Fri, 05 Jun 2020 00:00:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150708 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150708/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 7 days Failing since 150465 2020-05-29 09:02:14 Z 6 days 48 attempts Testing same since 150708 2020-06-04 21:07:16 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1546 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 05 02:30:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 02:30:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh276-00030o-Ha; Fri, 05 Jun 2020 02:29:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh274-00030j-Of for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 02:29:42 +0000 X-Inumbo-ID: 68f6ee68-a6d4-11ea-9dbe-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 68f6ee68-a6d4-11ea-9dbe-bc764e2007e4; Fri, 05 Jun 2020 02:29:41 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id e2so8320139eje.13 for ; Thu, 04 Jun 2020 19:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=t2NFtE9sz42OOu0h+GgXPWg/xv0bMlss/DfefnWMZYk=; b=VOLo/rMpfj0CPqsnUN4/Yn14PGO8Fa23WQvfhNDvAtGRdmSUbNnOEH+O0qyGWhj0a5 h/Uv89WcnuwjlyEGwMcXzuY3JiSpMLLmm3kSJJ5LKKTgrAVZ4JegO/Zr7pYA36kcocoK 4bcMprcXZ+sUqLebHAwHv8dUR5f/mFH961dtEhbi5vhBjNEKRdfM+xWDid9GzZ3N1Lwa sjFoB3dTf9Wh0ci230G6BkO+CeujMYjI+xweHgxqD8kppYpzv5LIxSr+K0K2wgGm46Hw Lz7sSaiy6T65G/HAEDX+NzsJ6h5mgOwxKHAxEjilavjZurNkSrmXKoWxk/einCxibrHK WbQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t2NFtE9sz42OOu0h+GgXPWg/xv0bMlss/DfefnWMZYk=; b=YJvpGZpHw10fEGKd3VvsTuPP/5XvPc9XtMvRDnsNC0SbDe2NotcmPpSf4kgAe5pnkF FoxVfZpVN3BCFiBSOtk/8gQ1rZI+XehJf0N5uO7FsYzVswuLHdrJAI7bhLkA+urukWVx kviaDgFjBQGRngA96O48TVA/fU2ib4pXWSwUgW8u+t44pIhNrts9AXBX7ddw++m0X4nQ kxy0ikke3QIpKzc6rbXEj0gfQ44R/Fj6uVoSFmjnd1Z+YwhhttCixd4NmYf3180ipkSF ym0d06lyvitduKJVkr+3l221Uf+oSjFTo8Wt5fhoD1cAPYpx4n20tnOnWlsPRH6dn93C 5K7Q== X-Gm-Message-State: AOAM533Bcvw07zHv3GbwERgrFaK22HBSMPyUbBVqauj8htt/35frqfZ6 CceiUhM9/X/eXqmy1TULfq+1kpDZhssuQc0QBC8= X-Google-Smtp-Source: ABdhPJx+jgGQH5nSmZzWNGsn0gRLTNmFwkPn7uFYKFceyB7Gwxhi0Xdece7coAO/YjkWA0lCDqCLnZmO9FLEFPKk2Xw= X-Received: by 2002:a17:906:11d9:: with SMTP id o25mr6335701eja.377.1591324180865; Thu, 04 Jun 2020 19:29:40 -0700 (PDT) MIME-Version: 1.0 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> In-Reply-To: From: CodeWiz2280 Date: Thu, 4 Jun 2020 22:29:28 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 4, 2020 at 2:24 PM Julien Grall wrote: > > Hi, > > On 04/06/2020 13:07, CodeWiz2280 wrote: > > On Thu, Jun 4, 2020 at 6:16 AM Julien Grall wrote: > >> > >> Hi, > >> > >> On 04/06/2020 10:08, Bertrand Marquis wrote: > >>> I would have thought that linux would have need some memory, even sma= ll in the 32bit space in order to boot. > >> > >> Yes it needs some, but then they are switching to use the high memory > >> alias after the MMU has been switch on. > >> > >> From my understanding, the only difference is the page-tables will > >> point to the high memory alias address rather than the low memory one. > >> Linux will still be located at the same place but now accessed from th= e > >> high memory alias rather than the low one. > >> > >> Note that AFAICT the secondary CPUs will still be brought-up using the > >> low memory alias. > >> > >>> I could understand that some memory in the low address space needs to= be reserved by Linux as DMA area for peripherals not supporting 36-bit add= resses, but the whole low memory sounds like a big restriction. > >> Many platforms have devices only supporting 32-bit DMA, but none of th= em > >> require such aliasing. So this doesn't look to be the issue here. > >> > >> TBH, this code is only used by Keystone and switching address space is > >> expensive (you have to turn off the MMU, updates page-tables, flush th= e > >> cache...). I find hard to believe a developper would have come up with > >> this complexity if it were possible to always use the low memory addre= ss > >> range. It is even harder to believe Linux community would have accepte= d it. > >> > >>> > >>> Would it be possible to have a bit more information on the =E2=80=9Cp= roblem with peripherals=E2=80=9D here ? > >> > >> I am curious as well, so I looked in more depth :). Going through the > >> Linux history, one of the commit message [1] suggests they are switchi= ng > >> to a coherent address space. The datasheet [2] (page 75) also confirm > >> that the low region is not IO coherent. > >> > >> So I think you would not be able to do DMA without flush the cache whi= ch > >> can be pretty expensive. For a PoC, it might be possible to force Linu= x > >> flushing the area before and after each DMA request. This should be > >> possible by marking the devices as not coherent. > >> > >> Although, I am not entirely sure if there is any fallout. > >> > >> @Dave, do you think it is possible for you to have a try? I can provid= e > >> the patch for Linux to disable DMA coherency if possible. > > I attempted to do that, where I removed the "dma-coherent" flags from > > the device tree. There are likely other issues, but the most glaring > > problem that I ran into is that the ethernet does not work. Eth0 > > shows up in ifconfig but there is no activity on it after a small > > handful of message exchanges, whereas booting without Xen it seems to > > work fine even if left in 32-bit mode (with the dma-coherent > > disabled). I don't know what implications behind the scenes there are > > trying to stay in the lower 0x8000_0000 alias range either though. > > Thank you for the answer. As wrote, Linux is working fine in 32-bit mode > when dma-coherent is left in 32-bit mode. So this suggest a different > issue on the platform. > > Given that you receive an handful of packet and then nothing, this would > lead to maybe an interrupt problem. Can you check whether the number of > interrupts increments the same way on baremetal and on Xen? > > Dumping /proc/interrupts should be sufficient. > I am able to ping the board from itself, do you think it could still be an interrupt issue? It just cannot seem to ping out to a different host (or ping from my pc). Unfortunately, the interrupts for the netcp Ethernet driver on this board don't show up in the cat /proc/interrupts output under the non-Xen kernel or Xen loaded kernel from what I can tell. I'm not sure how I would confirm t= hat. > > I > > would rather run it as intended by switching to the upper > > 0x8_0000_0000 alias region. > > I agree this would be ideal :). > > Cheers, > > -- > Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 05 03:55:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 03:55:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh3Ri-0002kq-MC; Fri, 05 Jun 2020 03:55:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh3Rh-0002kl-MV for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 03:55:05 +0000 X-Inumbo-ID: 56d36aa2-a6e0-11ea-8993-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 56d36aa2-a6e0-11ea-8993-bc764e2007e4; Fri, 05 Jun 2020 03:55:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vyCDEDzyXQrnB41+dNVPQ0oc12rv8KOS9P/d1bG4/yU=; b=HH3F7Cfw0Fq7NPcThjQ0lE8NB cArE2AZO3F66eKLLjkmb2fTNIXHd52nTaRN+uz6xxjo+xKWcdJhnAciTXCEpn0EvYJ9z8Iv+icay2 8eQdfvb824iFA/DQxIgXOc2FDxHRjSeqeSoZOHOO5Q/LaM7gTEn/AREWwK4nNNJ3qnb5g=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh3Rg-00018f-3q; Fri, 05 Jun 2020 03:55:04 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jh3Rf-0004lx-Pv; Fri, 05 Jun 2020 03:55:03 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jh3Rf-0007Ed-PC; Fri, 05 Jun 2020 03:55:03 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150712: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Fri, 05 Jun 2020 03:55:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150712 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150712/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 7 days Failing since 150465 2020-05-29 09:02:14 Z 6 days 49 attempts Testing same since 150708 2020-06-04 21:07:16 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1546 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 05 04:33:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 04:33:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh435-0006kT-3I; Fri, 05 Jun 2020 04:33:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh433-0006kL-96 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 04:33:41 +0000 X-Inumbo-ID: b7896400-a6e5-11ea-9dbe-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b7896400-a6e5-11ea-9dbe-bc764e2007e4; Fri, 05 Jun 2020 04:33:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6dP+2QcoKCEmNMQ/jffWLbL5q3bbn26HCxgNSpp8Wu4=; b=AQr0aPBpxJPkoj6fScngldqDB uWQNCBZBabynJE///HoDs5bBknWbJbW718vQyyM3FXo0Yz+5boXDWkHvEcPmbAG39pJ+Oj8WMAToI vX8bq0pbg8sd3wgvlvs9O1GU09kkngvnR7BDmnrt/7AFpnzlNgLCvoMyo2hjKt9Kzk6o4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh42v-00029S-Mg; Fri, 05 Jun 2020 04:33:33 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jh42v-0006PV-37; Fri, 05 Jun 2020 04:33:33 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jh42v-0006BK-2O; Fri, 05 Jun 2020 04:33:33 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150709: regressions - FAIL X-Osstest-Failures: linux-linus:build-amd64-libvirt:libvirt-build:fail:regression linux-linus:test-amd64-coresched-i386-xl:debian-install:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start:fail:allowable linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=9fb4c5250f10dc4d8257cd766991be690eb25c5b X-Osstest-Versions-That: linux=f6aee505c71bbb035dde146caf5a6abbf3ccbe47 From: osstest service owner Date: Fri, 05 Jun 2020 04:33:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150709 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150709/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150663 test-amd64-coresched-i386-xl 10 debian-install fail REGR. vs. 150663 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 150663 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150663 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150663 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150663 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150663 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150663 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150663 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150663 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150663 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150663 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: linux 9fb4c5250f10dc4d8257cd766991be690eb25c5b baseline version: linux f6aee505c71bbb035dde146caf5a6abbf3ccbe47 Last test of basis 150663 2020-06-03 18:38:46 Z 1 days Failing since 150680 2020-06-04 06:12:40 Z 0 days 3 attempts Testing same since 150709 2020-06-04 21:10:05 Z 0 days 1 attempts ------------------------------------------------------------ 856 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl fail test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 96394 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 05 07:00:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 07:00:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh6Kl-0004af-MX; Fri, 05 Jun 2020 07:00:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh6Kk-0004aZ-Tf for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 07:00:07 +0000 X-Inumbo-ID: 2fa0195c-a6fa-11ea-8993-bc764e2007e4 Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2fa0195c-a6fa-11ea-8993-bc764e2007e4; Fri, 05 Jun 2020 07:00:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1591340407; x=1622876407; h=from:to:cc:date:message-id:references:in-reply-to: subject; bh=pAI+O6HG26lMSTO4ql/EoYXSYiXCwcq7FuQs+M3pdk0=; b=uF8EJAYAxeAQ+4n05DgmFYXXQDRrJzZjIjdRvrGHWT3kdM61PJuQ9vzG Uk57u9fzIE4Z/9/H1kPbqwsxhgrCm+grd2ttvWVj4jSyo1bmQkYuGD7kW PTCNf1Al3uJEDP2GzDWRzDw92MAuP+JUzfe6MZce3t9YdN5U0vW9vpJqt o=; IronPort-SDR: ipqgH8aG2Bmg7QxbccHkHuji0fFBDO+clA4xl7BWbYthmbkJvQZ0N24T1SUqadKbooF1yxTkzR y76GXyYxlYbQ== X-Amazon-filename: signature.asc X-IronPort-AV: E=Sophos;i="5.73,475,1583193600"; d="asc'?scan'208";a="50004469" Subject: Re: [PATCH XTF] vsnprintf: Expand \n to \r\n for console output Thread-Topic: [PATCH XTF] vsnprintf: Expand \n to \r\n for console output Content-Type: multipart/mixed; boundary="===============1242854288525243043==" MIME-Version: 1.0 Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1e-a70de69e.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 05 Jun 2020 07:00:02 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-a70de69e.us-east-1.amazon.com (Postfix) with ESMTPS id 86587A1812; Fri, 5 Jun 2020 07:00:00 +0000 (UTC) Received: from EX13D05EUB003.ant.amazon.com (10.43.166.253) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 06:59:59 +0000 Received: from EX13D05EUB003.ant.amazon.com (10.43.166.253) by EX13D05EUB003.ant.amazon.com (10.43.166.253) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Jun 2020 06:59:59 +0000 Received: from EX13D05EUB003.ant.amazon.com ([10.43.166.253]) by EX13D05EUB003.ant.amazon.com ([10.43.166.253]) with mapi id 15.00.1497.006; Fri, 5 Jun 2020 06:59:59 +0000 From: "Wieczorkiewicz, Pawel" To: Andrew Cooper Thread-Index: AQHWOnqJjCAwY1e/p06UxvrJMnpmrqjJmOQA Date: Fri, 5 Jun 2020 06:59:59 +0000 Message-ID: References: <20200604141223.14153-1-andrew.cooper3@citrix.com> In-Reply-To: <20200604141223.14153-1-andrew.cooper3@citrix.com> Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.164.214] MIME-Version: 1.0 Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "Wieczorkiewicz, Pawel" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --===============1242854288525243043== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_81375728-4C83-4629-A8C4-EECBF7B638FD"; protocol="application/pgp-signature"; micalg=pgp-sha256 --Apple-Mail=_81375728-4C83-4629-A8C4-EECBF7B638FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 4. Jun 2020, at 16:12, Andrew Cooper = wrote: >=20 > CAUTION: This email originated from outside of the organization. Do = not click links or open attachments unless you can confirm the sender = and know the content is safe. >=20 >=20 >=20 > xenconsoled doesn't automatically convert \n into \r\n, which causes = test > output appear like this in a terminal: >=20 > [root@host ~]# xl create -c tests/selftest/test-pv64-selftest.cfg > Parsing config from tests/selftest/test-pv64-selftest.cfg > --- Xen Test Framework --- > Environment: PV 64bit (Long mode 4 levels) > = XTF Selftests >=20 > There are a number of ways to do this, but by far the most efficient = way is to > have vsnprintf() expand \n's in the output buffer. >=20 > This however is non-standard behaviour for vsnprintf(). Rename it to > vsnprintf_internal() and take extra flags, and have vprintk() use the = new > LF_TO_CRLF control flag. >=20 > Inside vsnprintf_internal(), rearrange the non-format and %c logic to = share > the expansion logic, as well as extending the logic to fmt_string(). >=20 > Extend the selftests to confirm correct behaviour in both modes, for = all ways > of being able to pass newline characters into a format operation. >=20 > Reported-by: Pawel Wieczorkiewicz > Signed-off-by: Andrew Cooper > --- > Pawel: Does this fix the issues you were seeing? Yes, it does fix the issue. Thanks. > --- > common/console.c | 2 +- > common/libc/vsnprintf.c | 23 +++++++++++++++-------- > include/xtf/libc.h | 15 ++++++++++++++- > tests/selftest/main.c | 38 ++++++++++++++++++++++++++++++++++++++ > 4 files changed, 68 insertions(+), 10 deletions(-) >=20 >=20 Best Regards, Pawel Wieczorkiewicz wipawel@amazon.com --Apple-Mail=_81375728-4C83-4629-A8C4-EECBF7B638FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEMfesMdpdS8dLoCFipZXgubqFgvsFAl7Z7W4ACgkQpZXgubqF gvt2Ug//bdEKML+MI8Wm9M3dsIST1KrHlGdTdVoTqyt/tTpdqiE22TIkxH2GpA2E XxNH4zsTX3vUaD6Dx8bqNNaTscQXTLKw4BR+aDSEpyUzQ9BN3QVI9ny7oMYk8QPH Tsx2hTqOgrQvn2sMXJdICM7mryjSJ5Ef0Mvio/kYkUE3h6FtWVZBaadnpD46X8xx eopksyedcgbFN7bgCh2hUOMZRmry5up6XWpoNyhxFwqqMIH/DXXWD53UbHO4vr5e d9B1xhkp37d96v7xYwgFgo0NII3AOpet6tryHGZEEDm3abtpPnNxgeDiNHb2NYsx l1vhBnQUKbZaHvraX2pJ+/9glkP7JbCm+7uRMtSN3hofzPTf9QFWSC/MdOEXJlxA gZ9dAgcnYzHmN3gnKVbuEz4U7MZI6hKEJzdEOqi3GkZkNA8j94UOnn3nG3Xwy2oh 4zbdKwEwmK5uJxfSg+rtVuz/8tYqqQbMkuz+X7PSe10TgRyg0pGiGhzqXBlA1jyF /QGjNG2AK29z0YAW49OPzHgI+ek/yWPmP+rKOhBkMjFRvx+3JufeM0wwJpPUqemq zqNviu21Mpq7tQnS8OvApjnvYToG+FeqQ3JgeeujhvGAaZz1IhaubfxCZdEZZT69 ILvUhfD9ejFGM0/jPZxC2UrRiVftSiMUoJYICGn5ikZR/GxbKKg= =PHPe -----END PGP SIGNATURE----- --Apple-Mail=_81375728-4C83-4629-A8C4-EECBF7B638FD-- --===============1242854288525243043== Content-Type: multipart/alternative; boundary="===============2324291855882853979==" MIME-Version: 1.0 Content-Disposition: inline --===============2324291855882853979== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 --===============2324291855882853979== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable


Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


--===============2324291855882853979==-- --===============1242854288525243043==-- From xen-devel-bounces@lists.xenproject.org Fri Jun 05 07:37:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 07:37:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh6uV-0007kq-Nk; Fri, 05 Jun 2020 07:37:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh6uU-0007kk-Bi for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 07:37:02 +0000 X-Inumbo-ID: 5747a614-a6ff-11ea-9947-bc764e2007e4 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (unknown [40.107.14.43]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5747a614-a6ff-11ea-9947-bc764e2007e4; Fri, 05 Jun 2020 07:37:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oS4GeH4syZsy3Q4SJZki0dJdK4ND1m4un0EFcCshH+M=; b=NosHQ5kd5qvK0c+vsJRa5LnlAu9S0Ug77/9u4euA8uM/vOsthi/aZSs50jhm+gwjevMu4FEmYQ+8UuyvLO4W5eyRigCMwvnfPe8Ksb02JmjAPz8YCc+THMaGTiYzX6F6B9OuFG5eVxpgSP8DysX9ZswdleeK9a7afiFBhXgmTdo= Received: from AM6P191CA0046.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:7f::23) by DB8PR08MB5097.eurprd08.prod.outlook.com (2603:10a6:10:38::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 5 Jun 2020 07:36:58 +0000 Received: from VE1EUR03FT062.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:7f:cafe::a2) by AM6P191CA0046.outlook.office365.com (2603:10a6:209:7f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Fri, 5 Jun 2020 07:36:58 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT062.mail.protection.outlook.com (10.152.18.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Fri, 5 Jun 2020 07:36:57 +0000 Received: ("Tessian outbound 1145f7a293ca:v59"); Fri, 05 Jun 2020 07:36:57 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 11b8019d5157e191 X-CR-MTA-TID: 64aa7808 Received: from e926d9de3310.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6FFB7350-1F37-4B3A-B88E-9B572D622BF0.1; Fri, 05 Jun 2020 07:36:52 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e926d9de3310.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 05 Jun 2020 07:36:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IFr+vkharbEUx3TpKrqsS0PpSIz+6321uOwyFNztoiV0NXrHueDgQQCktZmn+8PFSt2d+Td8pwaPpaxzQTsPqjzaqLRxMj12J3ZFjpnsC41zGFQG/WW+nQDXmgG03rDNTUe2jKx1xe3kx0GQseCeqA2+WwTE5pZvPJBW54SbBogAEptXjiMjsLr2KFufePx2wGaPW8HT7bxSv+UMKfgEhAXeilbsnTxEAPjYa+u94DTYMzZQSVcnsGPiYFR4qOX4+re0t6hxjQwnTEndzepgfsxirSM9vv5IzbPa8LzUz3JPRzVqGo9b8CC0KirNVcZ9SP696exCCTALG2BanBF33g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oS4GeH4syZsy3Q4SJZki0dJdK4ND1m4un0EFcCshH+M=; b=OxWQUqjmZzX9C4pm6JNLWk4cBPmXga23MC9a3ZQLNgpL13NNdyJprZ7KZS8rYd8RzyPw6LyJku1kcatIPeyH2kCR5/jT0TyahjA+pDq858PpbUqQ7alfbYf9pC5covNBzo/rQoUBfobH0jmxCPKfkzOeW29ytTYJUwi+uZ+mOEidYEbEyPIoIPBos6Cb4JJRSAfTpy8sWJVmQWoP2GaDbjGP+CT6PFY7nfB5kAoxmo5tAKG3a79LoDH4bhYmaMb/6riwNnqnPpvkXvYvtzCoq9Jfwb1s7pLXDkKO3E30K61ZjtJJA1pVzsuw8oEQ7pLB66Rhs6zyt/6Zqj4fcmv9Gg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oS4GeH4syZsy3Q4SJZki0dJdK4ND1m4un0EFcCshH+M=; b=NosHQ5kd5qvK0c+vsJRa5LnlAu9S0Ug77/9u4euA8uM/vOsthi/aZSs50jhm+gwjevMu4FEmYQ+8UuyvLO4W5eyRigCMwvnfPe8Ksb02JmjAPz8YCc+THMaGTiYzX6F6B9OuFG5eVxpgSP8DysX9ZswdleeK9a7afiFBhXgmTdo= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB2953.eurprd08.prod.outlook.com (2603:10a6:5:1b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 5 Jun 2020 07:36:50 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3066.019; Fri, 5 Jun 2020 07:36:50 +0000 From: Bertrand Marquis To: CodeWiz2280 Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34A= Date: Fri, 5 Jun 2020 07:36:50 +0000 Message-ID: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: dab7e4f5-1cfe-4f0c-7114-08d809233a55 x-ms-traffictypediagnostic: DB7PR08MB2953:|DB8PR08MB5097: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0425A67DEF X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: G6eKBvkPDUJpxurHI+QaGpDakSzHI/uV7g6dS7k8P3ZXxqR0izssxtP+UILCrTdHWAcm+WWYG9HDzh2+ucSBwyvtIqGaeH57e7/PdrZm/0MpTTiMnE95ouvYQeEEcX68YPeGFdJerkMCVNbMKrGmmIS1jlCkuP2Pe+ljOgt9f5TReL0x9yRdT4XgAvvnEyhzOaGAvJvW1vRrKxS9cSF8AHMKmuE+nUs2fxt+80FHsuiquD6gbPLHaGwxMLvnQMS15/O6y8PDg51vgQHCAZfJBWd1HOadwgvSA3SkEpuZdMnY7iCU+fm73RXyVmz3hEGvp8VcNJPvch/3sNU4ivyB7/E/pQYy0N6B8IuWRYxXmtBFrUShIWitxdSmHiz6XBan7Tin9sb3LjyG42ep3Q0AtA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(396003)(39860400002)(346002)(136003)(2906002)(71200400001)(6486002)(5660300002)(186003)(6512007)(36756003)(6916009)(26005)(7116003)(4326008)(6506007)(53546011)(2616005)(91956017)(66946007)(54906003)(478600001)(64756008)(316002)(86362001)(66476007)(966005)(33656002)(76116006)(83380400001)(66556008)(8936002)(66446008)(8676002)(3480700007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: eRf1A9iMPCHbm2osfjOH8HGiNPa29cKhNsfxMkD2EHzKO0nJm3IjBQtDhvcevZ+3y1+EJBORAj8nhe74jeWgYmCm5g8xG9GJZ+KWYiHkhBOnwwd+s/a6N1OtVctZhM2YYwICEZ1kNSIkSTi4Hg4GyELw1jzkAv70doGwU00RQvUyr7rnoxkVQcEXwWeDZZhRTDLRJLWjmoVwJU4DXkH8rqaqT+ienHeEuUdZPbYN9QL0PNEffHTHFlXdE0osCRAneMNPHV/yye1989I9jqrdwDDN+CzUPzG8BPQLlm8tv98pzYxD0sSuBRg08g5P/IEtgQIBArapw5V8rxrkIFp4fILLw3w7ZfIxTeERxV8LIPWuW5wml8hC4WXHys7YTq4XMJETlyS4tkMeO7Isbw1n+Sj7qiiJU0rjijGXA1hK8OIfuPrjvz7oLi7GvFhQCUJxdyHfqrRm9gfRs20yD+68//g5qwHw5nA5aS+JL57kVJA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6F07A1C8C7DF914B9301268046F2B8C6@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB2953 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT062.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(396003)(136003)(46966005)(53546011)(186003)(26005)(6486002)(47076004)(70206006)(70586007)(5660300002)(6512007)(86362001)(966005)(81166007)(7116003)(356005)(8676002)(3480700007)(83380400001)(82310400002)(36756003)(33656002)(316002)(336012)(6506007)(2906002)(54906003)(478600001)(8936002)(4326008)(2616005)(82740400003)(6862004)(36906005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 9adf43f7-289e-4833-3715-08d8092335ba X-Forefront-PRVS: 0425A67DEF X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f5hyy50exEbq++K+KjY14NijEjIGzoiG3czuJ+AUtrzHQ5JmZlfj69F1nQQ6PpVZTOCcjZY/x5VINgN9EZaEliO1IlajiO49mDCyGqcxjVlDEI734dtgDN5LlWJsEceaqm1wbuLfIxX0kfEqz3FK6Nci4ZYPAM3oK1R2/EIcpZRNjhzddvLZ7lEgq6IdBiIU717UOMEP17/oarWYeQS82Vb6BTbezVCMM5KvINOkZCg7c2ACzKzmJZP5ANwW+MLLKwvgoxHnaorW+c2lLPNhtI53dU4B+xUrrQWN8+Kvg027xE7oz7/OyBXiU8zTSlAjlzFhujMI8AoZuKybe7V9GK7CEZSoFZ1Jj0ktO58jzqqDcKjCelrtON6RY6yjLMJ9Z5yxA+C/FuAnaiM2VcJoKvBgHTKeFQfURbFWoNNyFqg3AgMSWI5JzIYUIptyO3KbXMydobS3D8vGrjfVSKRFDtQWYYHngibHIidcTmDOLmA= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2020 07:36:57.9029 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dab7e4f5-1cfe-4f0c-7114-08d809233a55 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5097 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGksDQoNCj4gT24gNSBKdW4gMjAyMCwgYXQgMDM6MjksIENvZGVXaXoyMjgwIDxjb2Rld2l6MjI4 MEBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gVGh1LCBKdW4gNCwgMjAyMCBhdCAyOjI0IFBN IEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+IHdyb3RlOg0KPj4gDQo+PiBIaSwNCj4+IA0K Pj4gT24gMDQvMDYvMjAyMCAxMzowNywgQ29kZVdpejIyODAgd3JvdGU6DQo+Pj4gT24gVGh1LCBK dW4gNCwgMjAyMCBhdCA2OjE2IEFNIEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+IHdyb3Rl Og0KPj4+PiANCj4+Pj4gSGksDQo+Pj4+IA0KPj4+PiBPbiAwNC8wNi8yMDIwIDEwOjA4LCBCZXJ0 cmFuZCBNYXJxdWlzIHdyb3RlOg0KPj4+Pj4gSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhhdCBsaW51 eCB3b3VsZCBoYXZlIG5lZWQgc29tZSBtZW1vcnksIGV2ZW4gc21hbGwgaW4gdGhlIDMyYml0IHNw YWNlIGluIG9yZGVyIHRvIGJvb3QuDQo+Pj4+IA0KPj4+PiBZZXMgaXQgbmVlZHMgc29tZSwgYnV0 IHRoZW4gdGhleSBhcmUgc3dpdGNoaW5nIHRvIHVzZSB0aGUgaGlnaCBtZW1vcnkNCj4+Pj4gYWxp YXMgYWZ0ZXIgdGhlIE1NVSBoYXMgYmVlbiBzd2l0Y2ggb24uDQo+Pj4+IA0KPj4+PiAgRnJvbSBt eSB1bmRlcnN0YW5kaW5nLCB0aGUgb25seSBkaWZmZXJlbmNlIGlzIHRoZSBwYWdlLXRhYmxlcyB3 aWxsDQo+Pj4+IHBvaW50IHRvIHRoZSBoaWdoIG1lbW9yeSBhbGlhcyBhZGRyZXNzIHJhdGhlciB0 aGFuIHRoZSBsb3cgbWVtb3J5IG9uZS4NCj4+Pj4gTGludXggd2lsbCBzdGlsbCBiZSBsb2NhdGVk IGF0IHRoZSBzYW1lIHBsYWNlIGJ1dCBub3cgYWNjZXNzZWQgZnJvbSB0aGUNCj4+Pj4gaGlnaCBt ZW1vcnkgYWxpYXMgcmF0aGVyIHRoYW4gdGhlIGxvdyBvbmUuDQo+Pj4+IA0KPj4+PiBOb3RlIHRo YXQgQUZBSUNUIHRoZSBzZWNvbmRhcnkgQ1BVcyB3aWxsIHN0aWxsIGJlIGJyb3VnaHQtdXAgdXNp bmcgdGhlDQo+Pj4+IGxvdyBtZW1vcnkgYWxpYXMuDQo+Pj4+IA0KPj4+Pj4gSSBjb3VsZCB1bmRl cnN0YW5kIHRoYXQgc29tZSBtZW1vcnkgaW4gdGhlIGxvdyBhZGRyZXNzIHNwYWNlIG5lZWRzIHRv IGJlIHJlc2VydmVkIGJ5IExpbnV4IGFzIERNQSBhcmVhIGZvciBwZXJpcGhlcmFscyBub3Qgc3Vw cG9ydGluZyAzNi1iaXQgYWRkcmVzc2VzLCBidXQgdGhlIHdob2xlIGxvdyBtZW1vcnkgc291bmRz IGxpa2UgYSBiaWcgcmVzdHJpY3Rpb24uDQo+Pj4+IE1hbnkgcGxhdGZvcm1zIGhhdmUgZGV2aWNl cyBvbmx5IHN1cHBvcnRpbmcgMzItYml0IERNQSwgYnV0IG5vbmUgb2YgdGhlbQ0KPj4+PiByZXF1 aXJlIHN1Y2ggYWxpYXNpbmcuIFNvIHRoaXMgZG9lc24ndCBsb29rIHRvIGJlIHRoZSBpc3N1ZSBo ZXJlLg0KPj4+PiANCj4+Pj4gVEJILCB0aGlzIGNvZGUgaXMgb25seSB1c2VkIGJ5IEtleXN0b25l IGFuZCBzd2l0Y2hpbmcgYWRkcmVzcyBzcGFjZSBpcw0KPj4+PiBleHBlbnNpdmUgKHlvdSBoYXZl IHRvIHR1cm4gb2ZmIHRoZSBNTVUsIHVwZGF0ZXMgcGFnZS10YWJsZXMsIGZsdXNoIHRoZQ0KPj4+ PiBjYWNoZS4uLikuIEkgZmluZCBoYXJkIHRvIGJlbGlldmUgYSBkZXZlbG9wcGVyIHdvdWxkIGhh dmUgY29tZSB1cCB3aXRoDQo+Pj4+IHRoaXMgY29tcGxleGl0eSBpZiBpdCB3ZXJlIHBvc3NpYmxl IHRvIGFsd2F5cyB1c2UgdGhlIGxvdyBtZW1vcnkgYWRkcmVzcw0KPj4+PiByYW5nZS4gSXQgaXMg ZXZlbiBoYXJkZXIgdG8gYmVsaWV2ZSBMaW51eCBjb21tdW5pdHkgd291bGQgaGF2ZSBhY2NlcHRl ZCBpdC4NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIGhhdmUg YSBiaXQgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGUg4oCccHJvYmxlbSB3aXRoIHBlcmlwaGVyYWxz 4oCdIGhlcmUgPw0KPj4+PiANCj4+Pj4gSSBhbSBjdXJpb3VzIGFzIHdlbGwsIHNvIEkgbG9va2Vk IGluIG1vcmUgZGVwdGggOikuIEdvaW5nIHRocm91Z2ggdGhlDQo+Pj4+IExpbnV4IGhpc3Rvcnks IG9uZSBvZiB0aGUgY29tbWl0IG1lc3NhZ2UgWzFdIHN1Z2dlc3RzIHRoZXkgYXJlIHN3aXRjaGlu Zw0KPj4+PiB0byBhIGNvaGVyZW50IGFkZHJlc3Mgc3BhY2UuIFRoZSBkYXRhc2hlZXQgWzJdIChw YWdlIDc1KSBhbHNvIGNvbmZpcm0NCj4+Pj4gdGhhdCB0aGUgbG93IHJlZ2lvbiBpcyBub3QgSU8g Y29oZXJlbnQuDQo+Pj4+IA0KPj4+PiBTbyBJIHRoaW5rIHlvdSB3b3VsZCBub3QgYmUgYWJsZSB0 byBkbyBETUEgd2l0aG91dCBmbHVzaCB0aGUgY2FjaGUgd2hpY2gNCj4+Pj4gY2FuIGJlIHByZXR0 eSBleHBlbnNpdmUuIEZvciBhIFBvQywgaXQgbWlnaHQgYmUgcG9zc2libGUgdG8gZm9yY2UgTGlu dXgNCj4+Pj4gZmx1c2hpbmcgdGhlIGFyZWEgYmVmb3JlIGFuZCBhZnRlciBlYWNoIERNQSByZXF1 ZXN0LiBUaGlzIHNob3VsZCBiZQ0KPj4+PiBwb3NzaWJsZSBieSBtYXJraW5nIHRoZSBkZXZpY2Vz IGFzIG5vdCBjb2hlcmVudC4NCj4+Pj4gDQo+Pj4+IEFsdGhvdWdoLCBJIGFtIG5vdCBlbnRpcmVs eSBzdXJlIGlmIHRoZXJlIGlzIGFueSBmYWxsb3V0Lg0KPj4+PiANCj4+Pj4gQERhdmUsIGRvIHlv dSB0aGluayBpdCBpcyBwb3NzaWJsZSBmb3IgeW91IHRvIGhhdmUgYSB0cnk/IEkgY2FuIHByb3Zp ZGUNCj4+Pj4gdGhlIHBhdGNoIGZvciBMaW51eCB0byBkaXNhYmxlIERNQSBjb2hlcmVuY3kgaWYg cG9zc2libGUuDQo+Pj4gSSBhdHRlbXB0ZWQgdG8gZG8gdGhhdCwgd2hlcmUgSSByZW1vdmVkIHRo ZSAiZG1hLWNvaGVyZW50IiBmbGFncyBmcm9tDQo+Pj4gdGhlIGRldmljZSB0cmVlLiAgVGhlcmUg YXJlIGxpa2VseSBvdGhlciBpc3N1ZXMsIGJ1dCB0aGUgbW9zdCBnbGFyaW5nDQo+Pj4gcHJvYmxl bSB0aGF0IEkgcmFuIGludG8gaXMgdGhhdCB0aGUgZXRoZXJuZXQgZG9lcyBub3Qgd29yay4gIEV0 aDANCj4+PiBzaG93cyB1cCBpbiBpZmNvbmZpZyBidXQgdGhlcmUgaXMgbm8gYWN0aXZpdHkgb24g aXQgYWZ0ZXIgYSBzbWFsbA0KPj4+IGhhbmRmdWwgb2YgbWVzc2FnZSBleGNoYW5nZXMsIHdoZXJl YXMgYm9vdGluZyB3aXRob3V0IFhlbiBpdCBzZWVtcyB0bw0KPj4+IHdvcmsgZmluZSBldmVuIGlm IGxlZnQgaW4gMzItYml0IG1vZGUgKHdpdGggdGhlIGRtYS1jb2hlcmVudA0KPj4+IGRpc2FibGVk KS4gIEkgZG9uJ3Qga25vdyB3aGF0IGltcGxpY2F0aW9ucyBiZWhpbmQgdGhlIHNjZW5lcyB0aGVy ZSBhcmUNCj4+PiB0cnlpbmcgdG8gc3RheSBpbiB0aGUgbG93ZXIgMHg4MDAwXzAwMDAgYWxpYXMg cmFuZ2UgZWl0aGVyIHRob3VnaC4NCj4+IA0KPj4gVGhhbmsgeW91IGZvciB0aGUgYW5zd2VyLiBB cyB3cm90ZSwgTGludXggaXMgd29ya2luZyBmaW5lIGluIDMyLWJpdCBtb2RlDQo+PiB3aGVuIGRt YS1jb2hlcmVudCBpcyBsZWZ0IGluIDMyLWJpdCBtb2RlLiBTbyB0aGlzIHN1Z2dlc3QgYSBkaWZm ZXJlbnQNCj4+IGlzc3VlIG9uIHRoZSBwbGF0Zm9ybS4NCj4+IA0KPj4gR2l2ZW4gdGhhdCB5b3Ug cmVjZWl2ZSBhbiBoYW5kZnVsIG9mIHBhY2tldCBhbmQgdGhlbiBub3RoaW5nLCB0aGlzIHdvdWxk DQo+PiBsZWFkIHRvIG1heWJlIGFuIGludGVycnVwdCBwcm9ibGVtLiBDYW4geW91IGNoZWNrIHdo ZXRoZXIgdGhlIG51bWJlciBvZg0KPj4gaW50ZXJydXB0cyBpbmNyZW1lbnRzIHRoZSBzYW1lIHdh eSBvbiBiYXJlbWV0YWwgYW5kIG9uIFhlbj8NCj4+IA0KPj4gRHVtcGluZyAvcHJvYy9pbnRlcnJ1 cHRzIHNob3VsZCBiZSBzdWZmaWNpZW50Lg0KPj4gDQo+IEkgYW0gYWJsZSB0byBwaW5nIHRoZSBi b2FyZCBmcm9tIGl0c2VsZiwgZG8geW91IHRoaW5rIGl0IGNvdWxkIHN0aWxsDQo+IGJlIGFuIGlu dGVycnVwdCBpc3N1ZT8gIEl0IGp1c3QgY2Fubm90IHNlZW0gdG8gcGluZyBvdXQgdG8gYSBkaWZm ZXJlbnQNCj4gaG9zdCAob3IgcGluZyBmcm9tDQo+IG15IHBjKS4gIFVuZm9ydHVuYXRlbHksIHRo ZSBpbnRlcnJ1cHRzIGZvciB0aGUgbmV0Y3AgRXRoZXJuZXQgZHJpdmVyDQo+IG9uIHRoaXMgYm9h cmQgZG9uJ3Qgc2hvdyB1cCBpbiB0aGUgY2F0IC9wcm9jL2ludGVycnVwdHMgb3V0cHV0IHVuZGVy DQo+IHRoZSBub24tWGVuIGtlcm5lbCBvcg0KPiBYZW4gbG9hZGVkIGtlcm5lbCBmcm9tIHdoYXQg SSBjYW4gdGVsbC4gIEknbSBub3Qgc3VyZSBob3cgSSB3b3VsZCBjb25maXJtIHRoYXQuDQoNCkNv dWxkIHlvdSBjaGVjayB0aGUgY29udGVudCBvZiAvcHJvYy9pbnRlcnJ1cHRzID8NCg0KSSBkaWQg cmFpc2UgYW4gaXNzdWUgc2V2ZXJhbCB5ZWFycyBhZ28gb24gdGhlIGtleXN0b25lIDIgcmVsYXRl ZCB0byBpbnRlcnJ1cHRzIGFuZCB2aXJ0dWFsaXphdGlvbiAobm8gd2l0aCBYZW4gYnV0IHRoZSBj b250ZXh0IHNob3VsZCBzdGlsbCBiZSByaWdodCk6DQpodHRwczovL2UyZS50aS5jb20vc3VwcG9y dC9wcm9jZXNzb3JzL2YvNzkxL3QvNDYyMTI2P0tleXN0b25lLTItbm8taW50ZXJydXB0cy1yZWNl aXZlZC1vdXQtb2YtODAtYW5kLTkyLQ0KDQpUaGVyZSBtaWdodCBiZSBzb21ldGhpbmcgdG8gY2hl Y2sgaW4gcmVnYXJkcyB0byBsZXZlbCB2cyBmcm9udCBpbnRlcnJ1cHRzIGZvciBmb3J3YXJkZWQg aW50ZXJydXB0cy4NCg0KUmVnYXJkcw0KQmVydHJhbmQNCg0KDQoNCj4gDQo+Pj4gSQ0KPj4+IHdv dWxkIHJhdGhlciBydW4gaXQgYXMgaW50ZW5kZWQgYnkgc3dpdGNoaW5nIHRvIHRoZSB1cHBlcg0K Pj4+IDB4OF8wMDAwXzAwMDAgYWxpYXMgcmVnaW9uLg0KPj4gDQo+PiBJIGFncmVlIHRoaXMgd291 bGQgYmUgaWRlYWwgOikuDQo+PiANCj4+IENoZWVycywNCj4+IA0KPj4gLS0NCj4+IEp1bGllbiBH cmFsbA0KDQo= From xen-devel-bounces@lists.xenproject.org Fri Jun 05 07:50:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 07:50:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh77N-00011K-0A; Fri, 05 Jun 2020 07:50:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh77L-00011F-U7 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 07:50:19 +0000 X-Inumbo-ID: 333bf8ae-a701-11ea-9947-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 333bf8ae-a701-11ea-9947-bc764e2007e4; Fri, 05 Jun 2020 07:50:18 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: UfAALRlWE6qiXUKQ5xipb/JQm0FMueBWje/OyMcykw03jdL2F2idFe4vUdael29xJf9Vyr7k+H lmM3UupEoir8p1ECyAb6y1PN69hiI8soAIx4AqSdkBHz+E4taCqw+yZdieHY4g28bCYp3wFVAX R1iC1mHd7ZLoUWTUJiWiCyxSvPVMEamSh1ZYmhUKRl+StjY4wyfI93DM2nRowGpYHXC5v8k1w7 Z+ywdco4eJ+pd6Hkahn5p1FtQ6STwgVDcfrQzRDdjqMaJBEYVBonj70/bg1BhwHlguZQo8srOk UN8= X-SBRS: 2.7 X-MesageID: 19550453 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,475,1583211600"; d="scan'208";a="19550453" From: Roger Pau Monne To: Subject: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 Date: Fri, 5 Jun 2020 09:50:06 +0200 Message-ID: <20200605075006.51238-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" At some point (maybe PVHv1?) mediated access to the RTC was provided for PVH dom0 using the PV code paths (guest_io_{write/read}). At some point this code has been made PV specific and unhooked from the current PVH IO path. This patch provides such mediated access to the RTC for PVH dom0, just like it's provided for a classic PV dom0. Instead of re-using the PV paths implement such handler together with the vRTC code for HVM, so that calling rtc_init will setup the appropriate handlers for all HVM based guests. Without this a Linux PVH dom0 will read garbage when trying to access the RTC, and one vCPU will be constantly looping in rtc_timer_do_work. Note that such issue doesn't happen on domUs because the ACPI NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing the RTC. Signed-off-by: Roger Pau Monné --- for-4.14 reasoning: the fix is completely isolated to PVH dom0, and as such the risk is very low of causing issues to other guests types, but without this fix one vCPU when using a Linux dom0 will be constantly looping over rtc_timer_do_work with 100% CPU usage, at least when using Linux 4.19 or newer. --- xen/arch/x86/hvm/rtc.c | 69 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c index 5bbbdc0e0f..5d637cf018 100644 --- a/xen/arch/x86/hvm/rtc.c +++ b/xen/arch/x86/hvm/rtc.c @@ -808,10 +808,79 @@ void rtc_reset(struct domain *d) s->pt.source = PTSRC_isa; } +/* RTC mediator for HVM hardware domain. */ +static unsigned int hw_read(unsigned int port) +{ + const struct domain *currd = current->domain; + unsigned long flags; + unsigned int data = 0; + + switch ( port ) + { + case RTC_PORT(0): + data = currd->arch.cmos_idx; + break; + + case RTC_PORT(1): + spin_lock_irqsave(&rtc_lock, flags); + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); + data = inb(RTC_PORT(1)); + spin_unlock_irqrestore(&rtc_lock, flags); + break; + } + + return data; +} + +static void hw_write(unsigned int port, unsigned int data) +{ + struct domain *currd = current->domain; + unsigned long flags; + + switch ( port ) + { + case RTC_PORT(0): + currd->arch.cmos_idx = data; + break; + + case RTC_PORT(1): + spin_lock_irqsave(&rtc_lock, flags); + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); + outb(data, RTC_PORT(1)); + spin_unlock_irqrestore(&rtc_lock, flags); + break; + } +} + +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, + uint32_t *val) +{ + if ( size != 1 ) + { + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); + *val = ~0; + return X86EMUL_OKAY; + } + + if ( dir == IOREQ_WRITE ) + hw_write(port, *val); + else + *val = hw_read(port); + + return X86EMUL_OKAY; +} + void rtc_init(struct domain *d) { RTCState *s = domain_vrtc(d); + if ( is_hardware_domain(d) ) + { + /* Hardware domain gets mediated access to the physical RTC. */ + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); + return; + } + if ( !has_vrtc(d) ) return; -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 05 07:51:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 07:51:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh78L-0001Ca-DX; Fri, 05 Jun 2020 07:51:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh78J-0001CQ-TB for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 07:51:19 +0000 X-Inumbo-ID: 555ba286-a701-11ea-af7f-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 555ba286-a701-11ea-af7f-12813bfff9fa; Fri, 05 Jun 2020 07:51:16 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7B094AB7D; Fri, 5 Jun 2020 07:51:18 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: Jan Beulich Subject: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers Message-ID: Date: Fri, 5 Jun 2020 09:51:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Both match prior generation processors as far as LBR and C-state MSRs go (SDM rev 072) as well as applicability of the if_pschange_mc erratum (recent spec updates). Signed-off-by: Jan Beulich --- Such changes having been subject to backporting in the past, this change may want considering for 4.14. --- I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum for Ice Lake indicating that MDS_NO may wrongly be set. But this is apparently addressed by ucode update, so we may not need to deal with it in software. --- a/xen/arch/x86/acpi/cpu_idle.c +++ b/xen/arch/x86/acpi/cpu_idle.c @@ -180,9 +180,15 @@ static void do_get_hw_residencies(void * case 0x4E: case 0x55: case 0x5E: + /* Ice Lake */ + case 0x7D: + case 0x7E: /* Kaby Lake */ case 0x8E: case 0x9E: + /* Comet Lake */ + case 0xA5: + case 0xA6: GET_PC2_RES(hw_res->pc2); GET_CC7_RES(hw_res->cc7); /* fall through */ --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2438,8 +2438,12 @@ static bool __init has_if_pschange_mc(vo case 0x4e: /* Skylake M */ case 0x5e: /* Skylake D */ case 0x55: /* Skylake-X / Cascade Lake */ + case 0x7d: /* Ice Lake */ + case 0x7e: /* Ice Lake */ case 0x8e: /* Kaby / Coffee / Whiskey Lake M */ case 0x9e: /* Kaby / Coffee / Whiskey Lake D */ + case 0xa5: /* Comet Lake H/S */ + case 0xa6: /* Comet Lake U */ return true; /* @@ -2781,10 +2785,14 @@ static const struct lbr_info *last_branc case 0x66: /* Goldmont Plus */ case 0x7a: + /* Ice Lake */ + case 0x7d: case 0x7e: /* Tremont */ case 0x86: /* Kaby Lake */ case 0x8e: case 0x9e: + /* Comet Lake */ + case 0xa5: case 0xa6: return sk_lbr; /* Atom */ case 0x1c: case 0x26: case 0x27: case 0x35: case 0x36: From xen-devel-bounces@lists.xenproject.org Fri Jun 05 08:02:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 08:02:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh7J5-0002ou-VY; Fri, 05 Jun 2020 08:02:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh7J4-0002op-Kn for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 08:02:26 +0000 X-Inumbo-ID: e496088c-a702-11ea-81bc-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e496088c-a702-11ea-81bc-bc764e2007e4; Fri, 05 Jun 2020 08:02:26 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 1Fir6SCJy07Mb9hBDhX5diiysi44fAOlzD9d6Jd24qPm0w5k3fmGO5I7YWrivQcuzvHf52DaR7 qnL1/clsR17O7B3TH9c/gAcIQEWuhmnelNJ66y31WP5RqLhBCU+tK30QYPT6w1ZsropqvaOcqp O4+fVDNjaomlcOMt2iatu75FADCDbUP+PC5NH1QzMWOqQBQEL5r6u3AbUTM/d5frHG5ZbTha+l pcbvDDH/NLKO8L7hw3VY2OpXFYP9x3N28Db1vog8gsLn7MFFXcRnZsbNKjTwDEug9R1d3Of6Ky 8Xk= X-SBRS: 2.7 X-MesageID: 19653011 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,475,1583211600"; d="scan'208";a="19653011" Date: Fri, 5 Jun 2020 10:02:16 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers Message-ID: <20200605080216.GI1195@Air-de-Roger> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote: > Both match prior generation processors as far as LBR and C-state MSRs > go (SDM rev 072) as well as applicability of the if_pschange_mc erratum > (recent spec updates). > > Signed-off-by: Jan Beulich > --- > Such changes having been subject to backporting in the past, this > change may want considering for 4.14. > --- > I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum > for Ice Lake indicating that MDS_NO may wrongly be set. But this is > apparently addressed by ucode update, so we may not need to deal with > it in software. > > --- a/xen/arch/x86/acpi/cpu_idle.c > +++ b/xen/arch/x86/acpi/cpu_idle.c What about mwait-idle? I guess we pick that from Linux and no patch has been added so far? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 08:03:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 08:03:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh7Js-0002ro-8o; Fri, 05 Jun 2020 08:03:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh7Jr-0002ri-Fo for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 08:03:15 +0000 X-Inumbo-ID: 01afb58a-a703-11ea-9dbe-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 01afb58a-a703-11ea-9dbe-bc764e2007e4; Fri, 05 Jun 2020 08:03:14 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id h5so8735000wrc.7 for ; Fri, 05 Jun 2020 01:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=IJW0YoI83OHwBJp1AzrB9MzmLzqcr4fHNqYiyV3R2Zc=; b=FjvYfeTYZUgBrL17MzC/o1MtAP6p9qgHOZ9El4CRyy7ncDi3eMQvyJPX8qZCWwy+jd 0swAtfRsGIa81CNCR0B9zLfGpUs0GDE75YotEh0K+n0yQHwPwOT7aneEUqtv4Lem1nOy zmTJ+fDJqJ9LIIKLcRKBA718ouuwAicTPJgX6/Nq51pluSkINikQnMWwQUl0X9VXd8RP FdlLvAvtwgB8TTY6+c/c5FkXNVxEHbIGfegm+TzqwNw0dpQ1U4fvtPhrPeUBneKuNc+x 9lvZ7AKDQ4/8r0PevwbZBLLh8BSMvu7hNJY2zm440rCy4T2RO81E8dNGP3ghU61tsNjp Hkxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=IJW0YoI83OHwBJp1AzrB9MzmLzqcr4fHNqYiyV3R2Zc=; b=YvWk6+oIi282CiNfjarPLly1i1WdZ+AWozlCUU60iNAjwBwXPbGPdqgVU8Gwwuln28 4NSWcCZpaQuPY4fvzXcQjFoBlRk0vEtl6gthj+W1iz4YoNQndsP/hbqedvcQSOFsSsGx 2gWFCccCPUhbmV1sWOz+XhYBRojd/rVDvOSCXLSUznLXmeGHPpQZ4gYuZmD/ixZwVCET f/iD0QsiyUNPMhiXXdNrA7jgcueWPf5rHmuTKCiUE5MzJk4+1zLFIs+ytX/RLR4AKvEN Ka7Nzy7kEBxe0fTgrGVD2a4sI7Nm9/ZAiKZD4YsMc5G/juUxbWmZt2xyT4PuSvnqSI5V 7XJQ== X-Gm-Message-State: AOAM533jYBzaumJ26HWXhWpnSG0uLtxGQhWlBoTY3gYnz89a/COGC7XW 2296hJg+/evlzxcPALyDB1Q= X-Google-Smtp-Source: ABdhPJwVYPE0FOLcYVycEOHbiW4fDC4tBYMJDwn0aILQM+STcDyBuckCweyVguaPg0Rcps4dlaW/dw== X-Received: by 2002:a05:6000:120b:: with SMTP id e11mr8324881wrx.107.1591344193978; Fri, 05 Jun 2020 01:03:13 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id 138sm10815915wma.23.2020.06.05.01.03.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 01:03:13 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200605075006.51238-1-roger.pau@citrix.com> In-Reply-To: <20200605075006.51238-1-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 Date: Fri, 5 Jun 2020 09:03:11 +0100 Message-ID: <000201d63b0f$c2d27910$48776b30$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFb0qjaKgty6gtStLgr1bY9c1VYP6m+eZUA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 05 June 2020 08:50 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich = ; Andrew > Cooper ; Wei Liu > Subject: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for = PVH dom0 >=20 > At some point (maybe PVHv1?) mediated access to the RTC was provided > for PVH dom0 using the PV code paths (guest_io_{write/read}). At some > point this code has been made PV specific and unhooked from the > current PVH IO path. This patch provides such mediated access to the > RTC for PVH dom0, just like it's provided for a classic PV dom0. >=20 > Instead of re-using the PV paths implement such handler together with > the vRTC code for HVM, so that calling rtc_init will setup the > appropriate handlers for all HVM based guests. >=20 > Without this a Linux PVH dom0 will read garbage when trying to access > the RTC, and one vCPU will be constantly looping in > rtc_timer_do_work. >=20 > Note that such issue doesn't happen on domUs because the ACPI > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > the RTC. >=20 > Signed-off-by: Roger Pau Monn=C3=A9 > --- > for-4.14 reasoning: the fix is completely isolated to PVH dom0, and as > such the risk is very low of causing issues to other guests types, but > without this fix one vCPU when using a Linux dom0 will be constantly > looping over rtc_timer_do_work with 100% CPU usage, at least when > using Linux 4.19 or newer. > --- I can't say I'm a big fan of the code duplication with emul-priv-op.c, = but it's not much code and it does keep this patch small. If the = maintainers are happy to ack then consider this... Release-acked-by: Paul Durrant > xen/arch/x86/hvm/rtc.c | 69 = ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 69 insertions(+) >=20 > diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c > index 5bbbdc0e0f..5d637cf018 100644 > --- a/xen/arch/x86/hvm/rtc.c > +++ b/xen/arch/x86/hvm/rtc.c > @@ -808,10 +808,79 @@ void rtc_reset(struct domain *d) > s->pt.source =3D PTSRC_isa; > } >=20 > +/* RTC mediator for HVM hardware domain. */ > +static unsigned int hw_read(unsigned int port) > +{ > + const struct domain *currd =3D current->domain; > + unsigned long flags; > + unsigned int data =3D 0; > + > + switch ( port ) > + { > + case RTC_PORT(0): > + data =3D currd->arch.cmos_idx; > + break; > + > + case RTC_PORT(1): > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + data =3D inb(RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + } > + > + return data; > +} > + > +static void hw_write(unsigned int port, unsigned int data) > +{ > + struct domain *currd =3D current->domain; > + unsigned long flags; > + > + switch ( port ) > + { > + case RTC_PORT(0): > + currd->arch.cmos_idx =3D data; > + break; > + > + case RTC_PORT(1): > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + outb(data, RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + } > +} > + > +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, > + uint32_t *val) > +{ > + if ( size !=3D 1 ) > + { > + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); > + *val =3D ~0; > + return X86EMUL_OKAY; > + } > + > + if ( dir =3D=3D IOREQ_WRITE ) > + hw_write(port, *val); > + else > + *val =3D hw_read(port); > + > + return X86EMUL_OKAY; > +} > + > void rtc_init(struct domain *d) > { > RTCState *s =3D domain_vrtc(d); >=20 > + if ( is_hardware_domain(d) ) > + { > + /* Hardware domain gets mediated access to the physical RTC. = */ > + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); > + return; > + } > + > if ( !has_vrtc(d) ) > return; >=20 > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 05 08:10:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 08:10:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh7QU-0003kD-1h; Fri, 05 Jun 2020 08:10:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh7QS-0003YP-RC for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 08:10:04 +0000 X-Inumbo-ID: f55dd2ac-a703-11ea-af82-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f55dd2ac-a703-11ea-af82-12813bfff9fa; Fri, 05 Jun 2020 08:10:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AC97AAD4F; Fri, 5 Jun 2020 08:10:05 +0000 (UTC) Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200605080216.GI1195@Air-de-Roger> From: Jan Beulich Message-ID: <32c4cdf7-0fdd-8b12-ee42-dfe8fe096935@suse.com> Date: Fri, 5 Jun 2020 10:10:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200605080216.GI1195@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 10:02, Roger Pau Monné wrote: > On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote: >> Both match prior generation processors as far as LBR and C-state MSRs >> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum >> (recent spec updates). >> >> Signed-off-by: Jan Beulich >> --- >> Such changes having been subject to backporting in the past, this >> change may want considering for 4.14. >> --- >> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum >> for Ice Lake indicating that MDS_NO may wrongly be set. But this is >> apparently addressed by ucode update, so we may not need to deal with >> it in software. >> >> --- a/xen/arch/x86/acpi/cpu_idle.c >> +++ b/xen/arch/x86/acpi/cpu_idle.c > > What about mwait-idle? I guess we pick that from Linux and no patch > has been added so far? Correct. I've looked at recent history there, and I'm uncertain they'll add further models there. They look to prefer to use ACPI _CST now again with, as it seems, not overly much of a difference to the ACPI driver (which, if we were to follow, I'd rather see us integrate there). Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 08:26:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 08:26:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh7gJ-0004zf-GA; Fri, 05 Jun 2020 08:26:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh7gH-0004za-Kt for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 08:26:25 +0000 X-Inumbo-ID: 3dfaf4de-a706-11ea-af89-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3dfaf4de-a706-11ea-af89-12813bfff9fa; Fri, 05 Jun 2020 08:26:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8C944ACD0; Fri, 5 Jun 2020 08:26:26 +0000 (UTC) Subject: Re: [PATCH for-4.14 RFC] docs/support-matrix: Gross bodge to unbreak docs rendering To: Andrew Cooper References: <20200604205226.14518-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 10:26:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Paul Durrant , Ian Jackson , Anthony PERARD , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.2020 22:58, Andrew Cooper wrote: > On 04/06/2020 21:52, Andrew Cooper wrote: >> The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a >> while. commitish_version() pulls an old version of xen/Makefile out of >> history, and uses the xenversion rule. >> >> Currently, this fails with: >> >> tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory >> >> which is because the Makefile legitimately references Kbuild.include with a >> relative rather than absolute path. >> >> Rearrange $CWD of the make rune to be in xen/ >> >> Signed-off-by: Andrew Cooper >> --- >> CC: George Dunlap >> CC: Ian Jackson >> CC: Jan Beulich >> CC: Konrad Rzeszutek Wilk >> CC: Stefano Stabellini >> CC: Wei Liu >> CC: Julien Grall >> CC: Anthony PERARD >> CC: Paul Durrant >> >> This is obviously not a proper fix. It will break in an unfixable way if we >> ever delete a file from the xen/ build system. >> >> I don't think pulling a makefile out of history and expecting it to work in >> the current working tree is a reasonable expectation. > > Actually - it occurs to me that we only want the major and minor number. > > I think it is reasonable to expect that those will always be plain > numbers, and we can grep them directly out of the file, rather than > feeding the thing to make. > > Thoughts? I was about to ask why we don't do that. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 08:47:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 08:47:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh807-0006vb-8r; Fri, 05 Jun 2020 08:46:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh806-0006vW-Ba for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 08:46:54 +0000 X-Inumbo-ID: 1a5c33f0-a709-11ea-af8e-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1a5c33f0-a709-11ea-af8e-12813bfff9fa; Fri, 05 Jun 2020 08:46:53 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: f8OXVohKE4k/nmQym3ANfLiLOliTUROI64UtVoj82JVSSfs3jUgD3fWlSRFUsScnhLIKYjUuxg 7h0yEHX13DAaxvE7FC2p2EE09WVvZuYvLa6zm8bsKuIiQgon3gFrxqu8zVj+9Yjvu0KKg7s57i /zU6ABQm9BC8mGaOLXbp9YnBKNU5bts4rNU4Ud9u/qP6TvwN/1LUaueUCB2vOEQ0TPMvUGhocd N++covbL6KVNXQGjoiunLDY7kGbVQvyjnc6Oolglr6IGcYtifpcJfgvhCkscObBkNvjGywHdmz /aI= X-SBRS: 2.7 X-MesageID: 19553588 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,475,1583211600"; d="scan'208";a="19553588" Date: Fri, 5 Jun 2020 10:46:44 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers Message-ID: <20200605084644.GJ1195@Air-de-Roger> References: <20200605080216.GI1195@Air-de-Roger> <32c4cdf7-0fdd-8b12-ee42-dfe8fe096935@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <32c4cdf7-0fdd-8b12-ee42-dfe8fe096935@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 10:10:01AM +0200, Jan Beulich wrote: > On 05.06.2020 10:02, Roger Pau Monné wrote: > > On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote: > >> Both match prior generation processors as far as LBR and C-state MSRs > >> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum > >> (recent spec updates). > >> > >> Signed-off-by: Jan Beulich > >> --- > >> Such changes having been subject to backporting in the past, this > >> change may want considering for 4.14. > >> --- > >> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum > >> for Ice Lake indicating that MDS_NO may wrongly be set. But this is > >> apparently addressed by ucode update, so we may not need to deal with > >> it in software. > >> > >> --- a/xen/arch/x86/acpi/cpu_idle.c > >> +++ b/xen/arch/x86/acpi/cpu_idle.c > > > > What about mwait-idle? I guess we pick that from Linux and no patch > > has been added so far? > > Correct. I've looked at recent history there, and I'm uncertain they'll > add further models there. They look to prefer to use ACPI _CST now again > with, as it seems, not overly much of a difference to the ACPI driver > (which, if we were to follow, I'd rather see us integrate there). Urg, OK, that's a shame as using mwait-idle was IMO better from a Xen PoV as we didn't rely on dom0 in order to discover C states. I wonder if we could continue to update mwait-idle on our own for newer models. FWIW, wikichip also lists 6c and 6a [0] as Ice Lake Server model versions, but I'm not sure if this has been confirmed in any way? Roger. [0] https://en.wikichip.org/wiki/intel/cpuid#Big_Cores_.28Server.29 From xen-devel-bounces@lists.xenproject.org Fri Jun 05 08:48:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 08:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh81z-00071y-LJ; Fri, 05 Jun 2020 08:48:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh81y-00071r-Vp for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 08:48:51 +0000 X-Inumbo-ID: 5f2a125f-a709-11ea-af8e-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5f2a125f-a709-11ea-af8e-12813bfff9fa; Fri, 05 Jun 2020 08:48:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8B85CAE5E; Fri, 5 Jun 2020 08:48:52 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 To: Roger Pau Monne References: <20200605075006.51238-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 10:48:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200605075006.51238-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 09:50, Roger Pau Monne wrote: > At some point (maybe PVHv1?) mediated access to the RTC was provided > for PVH dom0 using the PV code paths (guest_io_{write/read}). At some > point this code has been made PV specific and unhooked from the > current PVH IO path. I don't suppose you've identified the commit which did? This would help deciding whether / how far to backport such a change. > This patch provides such mediated access to the > RTC for PVH dom0, just like it's provided for a classic PV dom0. > > Instead of re-using the PV paths implement such handler together with > the vRTC code for HVM, so that calling rtc_init will setup the > appropriate handlers for all HVM based guests. Hooking this into rtc_init() makes sense as long as it's really just the RTC. Looking at the PV code you're cloning from, I wonder though whether pv_pit_handler() should also regain callers for PVH. As it stands the function is called for PV only, yet was deliberately put/kept outside of pv/. So along the lines of Paul's reply I think it would be better if code was shared between PV and PVH Dom0, perhaps by breaking out respective pieces from guest_io_{read,write}(). > Note that such issue doesn't happen on domUs because the ACPI > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > the RTC. Will it? I'm pretty sure Linux may (have?) ignore(d) this flag. > --- a/xen/arch/x86/hvm/rtc.c > +++ b/xen/arch/x86/hvm/rtc.c > @@ -808,10 +808,79 @@ void rtc_reset(struct domain *d) > s->pt.source = PTSRC_isa; > } > > +/* RTC mediator for HVM hardware domain. */ > +static unsigned int hw_read(unsigned int port) > +{ > + const struct domain *currd = current->domain; > + unsigned long flags; > + unsigned int data = 0; > + > + switch ( port ) > + { > + case RTC_PORT(0): > + data = currd->arch.cmos_idx; > + break; > + > + case RTC_PORT(1): > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + data = inb(RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); Avoiding to clone the original code would also avoid omissions like the ioports_access_permitted() calls you've dropped from here as well as the write counterpart. This may seem redundant as we never deny access right now, but should imo be there in case we decide to do (e.g. on NO_CMOS_RTC systems). Actually, "never" wasn't quite right I think: Late-hwdom creation will revoke access from dom0 and instead grant it to the new hwdom. Without the check, dom0 would continue to be able to access the RTC. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 08:54:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 08:54:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh87I-0007yj-Fy; Fri, 05 Jun 2020 08:54:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh87H-0007ye-02 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 08:54:19 +0000 X-Inumbo-ID: 239672ae-a70a-11ea-9b55-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 239672ae-a70a-11ea-9b55-bc764e2007e4; Fri, 05 Jun 2020 08:54:18 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: aZMt2FD1IV9QWwNk8SKVGu61Py02cuLTD6W6fo2h9CuTR5FocdgXdWUusNyxbIQs/DsB14qbk8 QA6FxinrgLmRrz2Two4GCQIKfSxqHwkBnQ/awUvEecH14I199y/QgFaiRrzXA8vXFY8mcZ8WTt fozyh9FktrIDSLF3gI6zY1zeUGAzutcNqoM+8MH+/d6HNXCPZpXoAJnNGBB1FyjmkbaAMHJX6H y2yDIZKqe0XzT5XNe0+9d666EUMyYVRvR1AmsWXRgEFsu1u4g5g3sYBwT+sT7m4FhnhcPQngKZ D84= X-SBRS: 2.7 X-MesageID: 19599463 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,475,1583211600"; d="scan'208";a="19599463" Date: Fri, 5 Jun 2020 10:54:10 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Subject: Re: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200605085150.GK1195@Air-de-Roger> References: <20200605075006.51238-1-roger.pau@citrix.com> <000201d63b0f$c2d27910$48776b30$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <000201d63b0f$c2d27910$48776b30$@xen.org> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Wei Liu' , 'Jan Beulich' , 'Andrew Cooper' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 09:03:11AM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Roger Pau Monne > > Sent: 05 June 2020 08:50 > > To: xen-devel@lists.xenproject.org > > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich ; Andrew > > Cooper ; Wei Liu > > Subject: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 > > > > At some point (maybe PVHv1?) mediated access to the RTC was provided > > for PVH dom0 using the PV code paths (guest_io_{write/read}). At some > > point this code has been made PV specific and unhooked from the > > current PVH IO path. This patch provides such mediated access to the > > RTC for PVH dom0, just like it's provided for a classic PV dom0. > > > > Instead of re-using the PV paths implement such handler together with > > the vRTC code for HVM, so that calling rtc_init will setup the > > appropriate handlers for all HVM based guests. > > > > Without this a Linux PVH dom0 will read garbage when trying to access > > the RTC, and one vCPU will be constantly looping in > > rtc_timer_do_work. > > > > Note that such issue doesn't happen on domUs because the ACPI > > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > > the RTC. > > > > Signed-off-by: Roger Pau Monné > > --- > > for-4.14 reasoning: the fix is completely isolated to PVH dom0, and as > > such the risk is very low of causing issues to other guests types, but > > without this fix one vCPU when using a Linux dom0 will be constantly > > looping over rtc_timer_do_work with 100% CPU usage, at least when > > using Linux 4.19 or newer. > > --- > > I can't say I'm a big fan of the code duplication with emul-priv-op.c, but it's not much code and it does keep this patch small. If the maintainers are happy to ack then consider this... Calling guest_io_{write/read} straight away is no acceptable IMO (and it would have to be moved out of emul-priv-op.c), and splitting the RTC accessors into separate helpers seemed like a lot of churn for the actual code that such helpers would contain. > Release-acked-by: Paul Durrant Thanks. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 08:54:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 08:54:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh87U-0007zt-OD; Fri, 05 Jun 2020 08:54:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh87S-0007ze-SW for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 08:54:30 +0000 X-Inumbo-ID: 2acbeebe-a70a-11ea-af8f-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2acbeebe-a70a-11ea-af8f-12813bfff9fa; Fri, 05 Jun 2020 08:54:30 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 82A39AFC6; Fri, 5 Jun 2020 08:54:32 +0000 (UTC) Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200605080216.GI1195@Air-de-Roger> <32c4cdf7-0fdd-8b12-ee42-dfe8fe096935@suse.com> <20200605084644.GJ1195@Air-de-Roger> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 10:54:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200605084644.GJ1195@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 10:46, Roger Pau Monné wrote: > On Fri, Jun 05, 2020 at 10:10:01AM +0200, Jan Beulich wrote: >> On 05.06.2020 10:02, Roger Pau Monné wrote: >>> On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote: >>>> Both match prior generation processors as far as LBR and C-state MSRs >>>> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum >>>> (recent spec updates). >>>> >>>> Signed-off-by: Jan Beulich >>>> --- >>>> Such changes having been subject to backporting in the past, this >>>> change may want considering for 4.14. >>>> --- >>>> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum >>>> for Ice Lake indicating that MDS_NO may wrongly be set. But this is >>>> apparently addressed by ucode update, so we may not need to deal with >>>> it in software. >>>> >>>> --- a/xen/arch/x86/acpi/cpu_idle.c >>>> +++ b/xen/arch/x86/acpi/cpu_idle.c >>> >>> What about mwait-idle? I guess we pick that from Linux and no patch >>> has been added so far? >> >> Correct. I've looked at recent history there, and I'm uncertain they'll >> add further models there. They look to prefer to use ACPI _CST now again >> with, as it seems, not overly much of a difference to the ACPI driver >> (which, if we were to follow, I'd rather see us integrate there). > > Urg, OK, that's a shame as using mwait-idle was IMO better from a Xen > PoV as we didn't rely on dom0 in order to discover C states. I wonder > if we could continue to update mwait-idle on our own for newer models. This would be nice indeed, but would require Intel to provide us with the necessary data. > FWIW, wikichip also lists 6c and 6a [0] as Ice Lake Server model versions, > but I'm not sure if this has been confirmed in any way? SDM vol 4 confirms this, but mentions the two model numbers exclusively in the table matching signatures to model names ("Future Intel Xeon processors based on Ice Lake microarchitecture"). Without there being an actual table for these I don't think we should "speculatively" add the numbers anywhere. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 09:09:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 09:09:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8Ly-0000l9-6M; Fri, 05 Jun 2020 09:09:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8Lw-0000l4-RE for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 09:09:28 +0000 X-Inumbo-ID: 41b835ae-a70c-11ea-96fb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 41b835ae-a70c-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 09:09:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 15D32AAC6; Fri, 5 Jun 2020 09:09:30 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> From: Jan Beulich Message-ID: <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> Date: Fri, 5 Jun 2020 11:09:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200604142542.GC98582@mail-itl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Paul Durrant , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.2020 16:25, Marek Marczykowski-Górecki wrote: > On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: >> On 04.06.2020 13:13, Andrew Cooper wrote: >>> On 04/06/2020 08:08, Jan Beulich wrote: >>>> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: >>>>> Then, we get the main issue: >>>>> >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff >>>>> (XEN) domain_crash called from io.c:178 >>>>> >>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom >>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. >>>> I'd guess an issue with the shutdown deferral logic. Did you / can >>>> you check whether XEN_DMOP_remote_shutdown managed to pause all >>>> CPUs (I assume it didn't, since once they're paused there shouldn't >>>> be any I/O there anymore, and hence no I/O emulation)? >>> >>> The vcpu in question is talking to Qemu, so will have v->defer_shutdown >>> intermittently set, and skip the pause in domain_shutdown() >>> >>> I presume this lack of pause is to allow the vcpu in question to still >>> be scheduled to consume the IOREQ reply?  (Its fairly opaque logic with >>> 0 clarifying details). >>> >>> What *should* happen is that, after consuming the reply, the vcpu should >>> notice and pause itself, at which point it would yield to the >>> scheduler.  This is the purpose of vcpu_{start,end}_shutdown_deferral(). >>> >>> Evidentially, this is not happening. >> >> We can't tell yet, until ... >> >>> Marek: can you add a BUG() after the weird PIO printing?  That should >>> confirm whether we're getting into handle_pio() via the >>> handle_hvm_io_completion() path, or via the vmexit path (at which case, >>> we're fully re-entering the guest). >> >> ... we know this. handle_pio() gets called from handle_hvm_io_completion() >> after having called hvm_wait_for_io() -> hvm_io_assist() -> >> vcpu_end_shutdown_deferral(), so the issue may be that we shouldn't call >> handle_pio() (etc) at all anymore in this state. IOW perhaps >> hvm_wait_for_io() should return "!sv->vcpu->domain->is_shutting_down" >> instead of plain "true"? >> >> Adding Paul to Cc, as being the maintainer here. > > Got it, by sticking BUG() just before that domain_crash() in > handle_pio(). And also vcpu 0 of both HVM domains do have > v->defer_shutdown. As per the log they did get it set. I'd be curious of the flag's value (as well as v->paused_for_shutdown's) at the point of the problematic handle_pio() invocation (see below). It may be worthwhile to instrument vcpu_check_shutdown() (inside its if()) - before exiting to guest context (in order to then come back and call handle_pio()) the vCPU ought to be getting through there. No indication of it doing so would be a sign that there's a code path bypassing the call to vcpu_end_shutdown_deferral(). > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 > (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 Perhaps in this message could you also log v->domain->is_shutting_down, v->defer_shutdown, and v->paused_for_shutdown? (Would be nice if, after having made changes to your debugging patch, you could point again at the precise version you've used for the log provided.) > (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff > (XEN) Xen BUG at io.c:178 Btw, instead of BUG(), WARN() or dump_execution_state() would likely also do, keeping Xen alive. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 09:12:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 09:12:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8Oe-0001e4-MF; Fri, 05 Jun 2020 09:12:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh7pw-0005zC-Ll for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 08:36:24 +0000 X-Inumbo-ID: a2762860-a707-11ea-adb3-bc764e2007e4 Received: from trent.utfs.org (unknown [2a03:3680:0:3::67]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a2762860-a707-11ea-adb3-bc764e2007e4; Fri, 05 Jun 2020 08:36:23 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by trent.utfs.org (Postfix) with ESMTPS id 76A4760125; Fri, 5 Jun 2020 10:36:21 +0200 (CEST) Date: Fri, 5 Jun 2020 01:36:21 -0700 (PDT) From: Christian Kujau To: linux-kernel@vger.kernel.org Subject: 5.7.0 / BUG: kernel NULL pointer dereference / setup_cpu_watcher Message-ID: User-Agent: Alpine 2.22 (DEB 395 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 05 Jun 2020 09:12:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, I'm running a small Xen PVH domain and upgrading from vanilla 5.6.0 to 5.7.0 caused the splat below, really early during boot. The configuration has not changed, all new "make oldconfig" prompts have been answered with "N". Old and new config, dmesg are here: http://nerdbynature.de/bits/5.7.0/ Searching the interwebs for similar reports didn't return much: * drm_sched_get_cleanup_job: BUG: kernel NULL pointer dereference https://bugzilla.redhat.com/show_bug.cgi?id=1822984 -- but this appears to be really DRM related. - https://lkml.org/lkml/2020/4/10/545 * A recent mm/vmstat patch, mentioning "device_offline" in its output https://patchwork.kernel.org/patch/11563009/ But other than a few overlapping strings, I guess all of that is totally unrelated :( Thanks, Christian. Note: that "Xen Platform PCI: unrecognised magic value" on the top appears in 5.6 kernels as well, but no ill effects so far. --------------------------------------------------------------- Xen Platform PCI: unrecognised magic value ACPI: No IOAPIC entries present BUG: kernel NULL pointer dereference, address: 00000000000002d0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0 #2 RIP: 0010:device_offline+0x8/0xf0 Code: 48 89 e7 e8 3a ee f3 ff 4c 89 e0 48 83 c4 10 5b 41 5c c3 45 31 e4 48 83 c4 10 4c 89 e0 5b 41 5c c3 90 41 54 55 53 48 83 ec 10 87 d0 02 00 00 01 0f 85 ca 00 00 00 48 89 fb 48 8b 7f 48 48 85 RSP: 0000:ffffbd9100013e78 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000820001fa RDX: ffff9c9c3dd00000 RSI: 00000000820001fa RDI: 0000000000000000 RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000000000000 R10: ffff9c9c3d5072a8 R11: 0000000000000000 R12: ffff9c9c3d594720 R13: ffffffff8a57e5a8 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9c9c3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000002d0 CR3: 000000006b00a001 CR4: 00000000001606b0 Call Trace: setup_cpu_watcher+0x44/0x60 ? plt_clk_driver_init+0xe/0xe setup_vcpu_hotplug_event+0x23/0x26 do_one_initcall+0x47/0x180 kernel_init_freeable+0x13b/0x19d ? rest_init+0x95/0x95 kernel_init+0x5/0xeb ret_from_fork+0x35/0x40 Modules linked in: CR2: 00000000000002d0 ---[ end trace b0cc587db609787f ]--- -- BOFH excuse #440: Cache miss - please take better aim next time From xen-devel-bounces@lists.xenproject.org Fri Jun 05 09:18:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 09:18:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8Ur-0001qo-EX; Fri, 05 Jun 2020 09:18:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8Uq-0001qj-7o for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 09:18:40 +0000 X-Inumbo-ID: 89ae0248-a70d-11ea-af92-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 89ae0248-a70d-11ea-af92-12813bfff9fa; Fri, 05 Jun 2020 09:18:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 55BAEAEE7; Fri, 5 Jun 2020 09:18:40 +0000 (UTC) Subject: Re: 5.7.0 / BUG: kernel NULL pointer dereference / setup_cpu_watcher To: Christian Kujau , linux-kernel@vger.kernel.org References: From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <7e2dec0c-8e27-6454-7793-d1246262283d@suse.com> Date: Fri, 5 Jun 2020 11:18:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.20 10:36, Christian Kujau wrote: > Hi, > > I'm running a small Xen PVH domain and upgrading from vanilla 5.6.0 to > 5.7.0 caused the splat below, really early during boot. The configuration > has not changed, all new "make oldconfig" prompts have been answered with > "N". Old and new config, dmesg are here: > > http://nerdbynature.de/bits/5.7.0/ > > Searching the interwebs for similar reports didn't return much: > > * drm_sched_get_cleanup_job: BUG: kernel NULL pointer dereference > https://bugzilla.redhat.com/show_bug.cgi?id=1822984 -- but this > appears to be really DRM related. - https://lkml.org/lkml/2020/4/10/545 > > * A recent mm/vmstat patch, mentioning "device_offline" in its output > https://patchwork.kernel.org/patch/11563009/ > > But other than a few overlapping strings, I guess all of that is totally > unrelated :( Do you happen to start the guest with vcpus < maxvcpus? If yes there is already a patch pending for 5.8: https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-5.8&id=c54b071c192dfe8061336f650ceaf358e6386e0b Juergen > > Thanks, > Christian. > > > Note: that "Xen Platform PCI: unrecognised magic value" on the top appears > in 5.6 kernels as well, but no ill effects so far. > > --------------------------------------------------------------- > Xen Platform PCI: unrecognised magic value > ACPI: No IOAPIC entries present > BUG: kernel NULL pointer dereference, address: 00000000000002d0 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops: 0000 [#1] SMP PTI > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0 #2 > RIP: 0010:device_offline+0x8/0xf0 > Code: 48 89 e7 e8 3a ee f3 ff 4c 89 e0 48 83 c4 10 5b 41 5c c3 45 31 e4 48 83 c4 10 4c 89 e0 5b 41 5c c3 90 41 54 55 53 48 83 ec 10 87 d0 02 00 00 01 0f 85 ca 00 00 00 48 89 fb 48 8b 7f 48 48 85 > RSP: 0000:ffffbd9100013e78 EFLAGS: 00010286 > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000820001fa > RDX: ffff9c9c3dd00000 RSI: 00000000820001fa RDI: 0000000000000000 > RBP: 0000000000000002 R08: 0000000000000001 R09: 0000000000000000 > R10: ffff9c9c3d5072a8 R11: 0000000000000000 R12: ffff9c9c3d594720 > R13: ffffffff8a57e5a8 R14: 0000000000000000 R15: 0000000000000000 > FS: 0000000000000000(0000) GS:ffff9c9c3dc00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000002d0 CR3: 000000006b00a001 CR4: 00000000001606b0 > Call Trace: > setup_cpu_watcher+0x44/0x60 > ? plt_clk_driver_init+0xe/0xe > setup_vcpu_hotplug_event+0x23/0x26 > do_one_initcall+0x47/0x180 > kernel_init_freeable+0x13b/0x19d > ? rest_init+0x95/0x95 > kernel_init+0x5/0xeb > ret_from_fork+0x35/0x40 > Modules linked in: > CR2: 00000000000002d0 > ---[ end trace b0cc587db609787f ]--- > From xen-devel-bounces@lists.xenproject.org Fri Jun 05 09:20:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 09:20:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8Wt-0002k7-Qx; Fri, 05 Jun 2020 09:20:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8Wr-0002k1-QP for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 09:20:45 +0000 X-Inumbo-ID: d49f7b9c-a70d-11ea-af92-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d49f7b9c-a70d-11ea-af92-12813bfff9fa; Fri, 05 Jun 2020 09:20:43 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Y4RzL7ZlZtLJOn65u7lt07CElv8iMPCsqdoRiOwZegPpKjaQQAjeYkp3dOz+df6GnNvtbrq7+d uwQCauS7MSRrIcsoXAs7/lku7RTfK7IeByYJ3sCwsuJ0HY2dZKrujactrmMUAlOqAHP6URbJ9D +YN0k4iDsT7yPoQ7Rh82jbML4CVp+XdA/3IOZHtim+FGbce0twK6+3CsvWTY4q6iW8/F96ZKbf QEoBXQtZ4PGcie4zJPPjjNiyi7ERjiJ3EFW66tLQna9anauLURW94kJDdl2NUxFUFWIQ2oy2oh 1Yc= X-SBRS: 2.7 X-MesageID: 19601042 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,475,1583211600"; d="scan'208";a="19601042" Date: Fri, 5 Jun 2020 11:20:35 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200605092035.GL1195@Air-de-Roger> References: <20200605075006.51238-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 10:48:48AM +0200, Jan Beulich wrote: > On 05.06.2020 09:50, Roger Pau Monne wrote: > > At some point (maybe PVHv1?) mediated access to the RTC was provided > > for PVH dom0 using the PV code paths (guest_io_{write/read}). At some > > point this code has been made PV specific and unhooked from the > > current PVH IO path. > > I don't suppose you've identified the commit which did? This would > help deciding whether / how far to backport such a change. I've attempted to, but failed to find the exact commit. I guess it might have happened at ecaba067e1e433 when guest_io_{read/write} was moved into emul-priv-op.c and made PV specific, but that's just a hint. > > This patch provides such mediated access to the > > RTC for PVH dom0, just like it's provided for a classic PV dom0. > > > > Instead of re-using the PV paths implement such handler together with > > the vRTC code for HVM, so that calling rtc_init will setup the > > appropriate handlers for all HVM based guests. > > Hooking this into rtc_init() makes sense as long as it's really > just the RTC. Looking at the PV code you're cloning from, I > wonder though whether pv_pit_handler() should also regain callers > for PVH. As it stands the function is called for PV only, yet was > deliberately put/kept outside of pv/. IIRC pv_pit_handler was also used by PVHv1 dom0, but we decided to not enable it for PVHv2 because no one really knew why the PIT was actually needed for by dom0. I think it's in emul-i8524.c (outside of pv/) because it calls into static functions on that file that are also used by HVM (handle_pit_io)? > So along the lines of Paul's reply I think it would be better if > code was shared between PV and PVH Dom0, perhaps by breaking out > respective pieces from guest_io_{read,write}(). OK, I can try but it will involve more code churn. > > > Note that such issue doesn't happen on domUs because the ACPI > > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > > the RTC. > > Will it? I'm pretty sure Linux may (have?) ignore(d) this flag. Seems like it's acknowledged now: https://elixir.bootlin.com/linux/latest/source/arch/x86/kernel/acpi/boot.c#L969 PVHv2 support is fairly recent anyway, and I wouldn't recommend using anything below Linux 4.19, which also has this implemented. > > --- a/xen/arch/x86/hvm/rtc.c > > +++ b/xen/arch/x86/hvm/rtc.c > > @@ -808,10 +808,79 @@ void rtc_reset(struct domain *d) > > s->pt.source = PTSRC_isa; > > } > > > > +/* RTC mediator for HVM hardware domain. */ > > +static unsigned int hw_read(unsigned int port) > > +{ > > + const struct domain *currd = current->domain; > > + unsigned long flags; > > + unsigned int data = 0; > > + > > + switch ( port ) > > + { > > + case RTC_PORT(0): > > + data = currd->arch.cmos_idx; > > + break; > > + > > + case RTC_PORT(1): > > + spin_lock_irqsave(&rtc_lock, flags); > > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > > + data = inb(RTC_PORT(1)); > > + spin_unlock_irqrestore(&rtc_lock, flags); > > Avoiding to clone the original code would also avoid omissions > like the ioports_access_permitted() calls you've dropped from > here as well as the write counterpart. This may seem redundant > as we never deny access right now, but should imo be there in > case we decide to do (e.g. on NO_CMOS_RTC systems). > > Actually, "never" wasn't quite right I think: Late-hwdom > creation will revoke access from dom0 and instead grant it to > the new hwdom. Without the check, dom0 would continue to be > able to access the RTC. TBH I'm not sure late-hwdom switching from an initial PVH domain will work work very well, as we would already have to modify the vmcs/vmcb io_bitmap in order to convey the changes to the allowed IO port ranges which we don't do now. Let me see if I can split the helpers. Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 09:21:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 09:21:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8XY-0002o7-7a; Fri, 05 Jun 2020 09:21:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8XX-0002nx-4E for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 09:21:27 +0000 X-Inumbo-ID: ee185ab2-a70d-11ea-af92-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ee185ab2-a70d-11ea-af92-12813bfff9fa; Fri, 05 Jun 2020 09:21:26 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: L+UWBliUE3jgTH6GDv2zRb3XTL5nA7ZNrHBlwtGKEU2BWjJbH6cmXzRmdMdlE55XU3Fx7VEtul 5Pskt52HdPVR+lEokf8AvD3u4DyFEbMHCBs8vmbbFN8kCGJpGd4t5hTmzzeLA5qUBEX1D9o+kb qFV7ts+qld26h8rwwS5v2w1NYteWUO0YBlCUhRTMoCA71Ksr1dEJIURHIzUzYboVTFHidwRE3v Sx82K3WQzFzsgk7o1yr7pNWoBqSQNuEYFCWVWJhp9uZTyCNbC5PsKTCwv6u2rqo+/dG4JvyqDS 65c= X-SBRS: 2.7 X-MesageID: 19601087 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,475,1583211600"; d="scan'208";a="19601087" Date: Fri, 5 Jun 2020 11:21:18 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers Message-ID: <20200605092118.GM1195@Air-de-Roger> References: <20200605080216.GI1195@Air-de-Roger> <32c4cdf7-0fdd-8b12-ee42-dfe8fe096935@suse.com> <20200605084644.GJ1195@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 10:54:22AM +0200, Jan Beulich wrote: > On 05.06.2020 10:46, Roger Pau Monné wrote: > > On Fri, Jun 05, 2020 at 10:10:01AM +0200, Jan Beulich wrote: > >> On 05.06.2020 10:02, Roger Pau Monné wrote: > >>> On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote: > >>>> Both match prior generation processors as far as LBR and C-state MSRs > >>>> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum > >>>> (recent spec updates). > >>>> > >>>> Signed-off-by: Jan Beulich > >>>> --- > >>>> Such changes having been subject to backporting in the past, this > >>>> change may want considering for 4.14. > >>>> --- > >>>> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum > >>>> for Ice Lake indicating that MDS_NO may wrongly be set. But this is > >>>> apparently addressed by ucode update, so we may not need to deal with > >>>> it in software. > >>>> > >>>> --- a/xen/arch/x86/acpi/cpu_idle.c > >>>> +++ b/xen/arch/x86/acpi/cpu_idle.c > >>> > >>> What about mwait-idle? I guess we pick that from Linux and no patch > >>> has been added so far? > >> > >> Correct. I've looked at recent history there, and I'm uncertain they'll > >> add further models there. They look to prefer to use ACPI _CST now again > >> with, as it seems, not overly much of a difference to the ACPI driver > >> (which, if we were to follow, I'd rather see us integrate there). > > > > Urg, OK, that's a shame as using mwait-idle was IMO better from a Xen > > PoV as we didn't rely on dom0 in order to discover C states. I wonder > > if we could continue to update mwait-idle on our own for newer models. > > This would be nice indeed, but would require Intel to provide us with > the necessary data. > > > FWIW, wikichip also lists 6c and 6a [0] as Ice Lake Server model versions, > > but I'm not sure if this has been confirmed in any way? > > SDM vol 4 confirms this, but mentions the two model numbers exclusively > in the table matching signatures to model names ("Future Intel Xeon > processors based on Ice Lake microarchitecture"). Without there being an > actual table for these I don't think we should "speculatively" add the > numbers anywhere. Ack. Reviewed-by: Roger Pau Monné Thanks. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 09:22:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 09:22:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8Ys-0002wr-Ih; Fri, 05 Jun 2020 09:22:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8Yr-0002wk-4B for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 09:22:49 +0000 X-Inumbo-ID: 1f0b13bc-a70e-11ea-ba62-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1f0b13bc-a70e-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 09:22:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 00B61AFC8; Fri, 5 Jun 2020 09:22:50 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom From: Jan Beulich To: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> Message-ID: Date: Fri, 5 Jun 2020 11:22:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , xen-devel , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 11:09, Jan Beulich wrote: > On 04.06.2020 16:25, Marek Marczykowski-Górecki wrote: >> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 >> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 >> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done >> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 >> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 >> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done >> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 >> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > Perhaps in this message could you also log > v->domain->is_shutting_down, v->defer_shutdown, and > v->paused_for_shutdown? And v->domain->is_shut_down please. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 09:38:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 09:38:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8nt-00042o-Uw; Fri, 05 Jun 2020 09:38:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh8ns-00042j-2n for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 09:38:20 +0000 X-Inumbo-ID: 49c5030e-a710-11ea-af92-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 49c5030e-a710-11ea-af92-12813bfff9fa; Fri, 05 Jun 2020 09:38:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AD08FAD1A; Fri, 5 Jun 2020 09:38:21 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= References: <20200604014621.GA203658@mail-itl> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 11:38:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200604014621.GA203658@mail-itl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: > Hi, > > (continuation of a thread from #xendevel) > > During system shutdown quite often I hit infinite stream of errors like > this: > > (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > (XEN) domain_crash called from io.c:178 > > This is all running on Xen 4.13.0 (I think I've got this with 4.13.1 > too), nested within KVM. The KVM part means everything is very slow, so > various race conditions are much more likely to happen. > > It started happening not long ago, and I'm pretty sure it's about > updating to qemu 4.2.0 (in linux stubdom), previous one was 3.0.0. > > Thanks to Andrew and Roger, I've managed to collect more info. > > Context: > dom0: pv > dom1: hvm > dom2: stubdom for dom1 > dom3: hvm > dom4: stubdom for dom3 > dom5: pvh > dom6: pvh > > It starts I think ok: > > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 I can't seem to be able to spot the call site of this, in any of qemu, libxl, or libxc. I'm in particular curious as to the further actions taken on the domain after this was invoked: Do any ioreq servers get unregistered immediately (which I think would be a problem)? Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 10:05:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 10:05:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh9E1-0006xS-6k; Fri, 05 Jun 2020 10:05:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh9Dz-0006xN-HQ for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 10:05:19 +0000 X-Inumbo-ID: 0efff0d6-a714-11ea-af92-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0efff0d6-a714-11ea-af92-12813bfff9fa; Fri, 05 Jun 2020 10:05:18 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DA86CAA6F; Fri, 5 Jun 2020 10:05:20 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200605075006.51238-1-roger.pau@citrix.com> <20200605092035.GL1195@Air-de-Roger> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 12:05:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200605092035.GL1195@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 11:20, Roger Pau Monné wrote: > On Fri, Jun 05, 2020 at 10:48:48AM +0200, Jan Beulich wrote: >> On 05.06.2020 09:50, Roger Pau Monne wrote: >>> At some point (maybe PVHv1?) mediated access to the RTC was provided >>> for PVH dom0 using the PV code paths (guest_io_{write/read}). At some >>> point this code has been made PV specific and unhooked from the >>> current PVH IO path. >> >> I don't suppose you've identified the commit which did? This would >> help deciding whether / how far to backport such a change. > > I've attempted to, but failed to find the exact commit. I guess it > might have happened at ecaba067e1e433 when guest_io_{read/write} was > moved into emul-priv-op.c and made PV specific, but that's just a hint. Looks like it was never hooked up for PVHv2, and removed together with a lot of other PVHv1 code by your 33e5c32559e1. >>> This patch provides such mediated access to the >>> RTC for PVH dom0, just like it's provided for a classic PV dom0. >>> >>> Instead of re-using the PV paths implement such handler together with >>> the vRTC code for HVM, so that calling rtc_init will setup the >>> appropriate handlers for all HVM based guests. >> >> Hooking this into rtc_init() makes sense as long as it's really >> just the RTC. Looking at the PV code you're cloning from, I >> wonder though whether pv_pit_handler() should also regain callers >> for PVH. As it stands the function is called for PV only, yet was >> deliberately put/kept outside of pv/. > > IIRC pv_pit_handler was also used by PVHv1 dom0, but we decided to not > enable it for PVHv2 because no one really knew why the PIT was > actually needed for by dom0. I think the reason PV Dom0 has it applies to PVH Dom0 as well: At least back at the time there were video BIOSes needing this. As it now turns out to have been a mistake to not enable the RTC handling for v2, I would still think it would be better to enable the PIT logic as well there, just to be on the safe side. > I think it's in emul-i8524.c (outside of pv/) because it calls into > static functions on that file that are also used by HVM > (handle_pit_io)? Ah, likely. >>> --- a/xen/arch/x86/hvm/rtc.c >>> +++ b/xen/arch/x86/hvm/rtc.c >>> @@ -808,10 +808,79 @@ void rtc_reset(struct domain *d) >>> s->pt.source = PTSRC_isa; >>> } >>> >>> +/* RTC mediator for HVM hardware domain. */ >>> +static unsigned int hw_read(unsigned int port) >>> +{ >>> + const struct domain *currd = current->domain; >>> + unsigned long flags; >>> + unsigned int data = 0; >>> + >>> + switch ( port ) >>> + { >>> + case RTC_PORT(0): >>> + data = currd->arch.cmos_idx; >>> + break; >>> + >>> + case RTC_PORT(1): >>> + spin_lock_irqsave(&rtc_lock, flags); >>> + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); >>> + data = inb(RTC_PORT(1)); >>> + spin_unlock_irqrestore(&rtc_lock, flags); >> >> Avoiding to clone the original code would also avoid omissions >> like the ioports_access_permitted() calls you've dropped from >> here as well as the write counterpart. This may seem redundant >> as we never deny access right now, but should imo be there in >> case we decide to do (e.g. on NO_CMOS_RTC systems). >> >> Actually, "never" wasn't quite right I think: Late-hwdom >> creation will revoke access from dom0 and instead grant it to >> the new hwdom. Without the check, dom0 would continue to be >> able to access the RTC. > > TBH I'm not sure late-hwdom switching from an initial PVH domain will > work work very well, as we would already have to modify the vmcs/vmcb > io_bitmap in order to convey the changes to the allowed IO port ranges > which we don't do now. FAOD: I didn't mean to suggest I believe this transition would be working right now. But if someone wanted to make it work, they shouldn't be put at risk to unknowingly leave the original dom0 with more permissions than it's supposed to have. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 10:16:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 10:16:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh9OI-0007yG-8H; Fri, 05 Jun 2020 10:15:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh9OH-0007yB-Jo for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 10:15:57 +0000 X-Inumbo-ID: 8b597a98-a715-11ea-9ad7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8b597a98-a715-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 10:15:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9ywsy3JZogqjsh7TVZP3ln7hqcm6jqmNYVuOfqUSikA=; b=s3IoNWPmndn7rj4guZUiFgqw5 LxZ7GRxojzpRIZKcWcOZm6dtiOMLH1SSTn653+gLLfXUYwmrKW4jtGK4GsALKm/mSYps3y5Gkb/8B 0w9zIdt0nVoWQgiafRLcRPNxuoX2XC+4OKQg1Y7V2/P+0AsizpfvLzWKVoE0PCcuncmYQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh9OG-0001lk-0l; Fri, 05 Jun 2020 10:15:56 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jh9OF-0004cy-Oy; Fri, 05 Jun 2020 10:15:55 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jh9OF-0003iS-O1; Fri, 05 Jun 2020 10:15:55 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150813: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Fri, 05 Jun 2020 10:15:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150813 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150813/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 7 days Failing since 150465 2020-05-29 09:02:14 Z 7 days 51 attempts Testing same since 150708 2020-06-04 21:07:16 Z 0 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1546 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 05 10:43:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 10:43:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh9oV-0002L6-JO; Fri, 05 Jun 2020 10:43:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh9oT-0002L1-Uy for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 10:43:01 +0000 X-Inumbo-ID: 5389bb10-a719-11ea-ba62-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5389bb10-a719-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 10:43:01 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 23zX8ds8QyQcYc9ZrqaxSSv0vBqLE8gSrVpYrjdtdC5iHDH2/FfDBW0ydI+yUhfby0skY93Mq6 7pafHzwsfYcbN0fvYxiWaX9yWNFmcX2YvYps9P7Y1bZpcLei2u0MUYzCACE8eDFQsGkNeRp7hf wBFDbAOHZA+FDY1OY3794suz/e/rgTiL6j+9mZtlxz18LGCyV2mQwwP8FI1YRVXwdj9DwG5BFe Z8dWbDj96aJtCa7kuS4JbX96p7v5yj8Z4qf+A+35hBu5kbsdxcvobOI+4EBs8AyNv48A5uZ5po wYM= X-SBRS: 2.7 X-MesageID: 19560445 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="scan'208";a="19560445" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24282.8623.166241.87718@mariner.uk.xensource.com> Date: Fri, 5 Jun 2020 11:42:55 +0100 To: Andrew Cooper Subject: Re: [PATCH for-4.14 RFC] docs/support-matrix: Gross bodge to unbreak docs rendering In-Reply-To: References: <20200604205226.14518-1-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , Paul Durrant , George Dunlap , Jan Beulich , Anthony Perard , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("Re: [PATCH for-4.14 RFC] docs/support-matrix: Gross bodge to unbreak docs rendering"): > Actually - it occurs to me that we only want the major and minor number. > > I think it is reasonable to expect that those will always be plain > numbers, and we can grep them directly out of the file, rather than > feeding the thing to make. > > Thoughts? I would be happy with that approach. The alternative would be to move these settings into a separate makefile where we promise that support-matrix-generate's assumption (that you can make -f just-that-file and get sensible behaviour) is going to be kept true. Perhaps I should apologise for perpetrating the existing now-broken code. But there was no less insane official way of getting the version out without checking out the whole tree... Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 10:45:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 10:45:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh9rB-0002Tr-1J; Fri, 05 Jun 2020 10:45:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jh9r9-0002Tm-Jc for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 10:45:47 +0000 X-Inumbo-ID: b4b29952-a719-11ea-af98-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b4b29952-a719-11ea-af98-12813bfff9fa; Fri, 05 Jun 2020 10:45:44 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: QTg5fgQPoWKe6zwATi+kwHZFL/E6D7Su4vkTGv++D7ihitAjb9mOPhR/91uzUCFM8hL4Cwl0ax Scob+SCUVpfKOm9jcSiHeZsjcak6ODodG3KCyHu7PAfbou//KJDcSg9r5DY9L/9sYGAug50uLR 56jxxlUqAZiR1HQpVaSQV5gAWnWMyacsSxDhrD2bqv4xvkPWrRO2rYpXONX6pKSMSVo/M06cMm EnZYC14qoMQyhrLxyY27VNCeHzlxvh+aX3k+NXsFNqLXoJBB1FT0Jik795kJTE7xMu/UOKBrXl 1Ow= X-SBRS: 2.7 X-MesageID: 19311942 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="scan'208";a="19311942" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24282.8784.496525.724949@mariner.uk.xensource.com> Date: Fri, 5 Jun 2020 11:45:36 +0100 To: Jan Beulich Subject: Re: [PATCH for-4.14 RFC] docs/support-matrix: Gross bodge to unbreak docs rendering In-Reply-To: References: <20200604205226.14518-1-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , Andrew Cooper , Paul Durrant , George Dunlap , Anthony Perard , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jan Beulich writes ("Re: [PATCH for-4.14 RFC] docs/support-matrix: Gross bodge to unbreak docs rendering"): > I was about to ask why we don't do that. When I wrote the code in question, I was afraid that this makefile would change in a way that would break that approach. Unfortunately it seems I guessed wrong and instead it changed in a way that broke the approach I took instead. So +1 to this. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:02:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:02:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhA7f-0004P9-M3; Fri, 05 Jun 2020 11:02:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhA7e-0004P4-BR for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:02:50 +0000 X-Inumbo-ID: 17bb47d6-a71c-11ea-af9d-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 17bb47d6-a71c-11ea-af9d-12813bfff9fa; Fri, 05 Jun 2020 11:02:49 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ocq4NPS5Lxg6hYuvKZHSF2ee9D1Y0mCrj0p2EcWgZT7OsyifM2RmZeaSDSIDnJl3hIS6906KgS fc6bYPw005hY9H6LSaGimQKzv0zMWjKbWytSWi2nS43l3B7AYaus+FuUYelcAXuVTexGlVJQRB MwlgYeqONzpSXYBo84rEMKZl3BmCyPotSb9b5Wcy6b4BE8fq9m1TQZHefotnzlzlCl9sm6wfRt 2jwAmdvD4XnF3kCJUU6eHDJHyo6uZLWkjv/eUvpaFQvaXO22qSAxK4ncwsxJJGIarW4FmN35zN E50= X-SBRS: 2.7 X-MesageID: 19313218 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="scan'208";a="19313218" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC for PVH dom0 Date: Fri, 5 Jun 2020 13:02:39 +0200 Message-ID: <20200605110240.52545-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Mediated access to the RTC was provided for PVHv1 dom0 using the PV code paths (guest_io_{write/read}), but those accesses where never implemented for PVHv2 dom0. This patch provides such mediated accesses to the RTC for PVH dom0, just like it's provided for a classic PV dom0. Pull out some of the RTC logic from guest_io_{read/write} into specific helpers that can be used by both PV and HVM guests. The setup of the handlers for PVH is done in rtc_init, which is already used to initialize the fully emulated RTC. Without this a Linux PVH dom0 will read garbage when trying to access the RTC, and one vCPU will be constantly looping in rtc_timer_do_work. Note that such issue doesn't happen on domUs because the ACPI NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the accesses are not emulated but rather forwarded to the physical hardware. No functional change expected for classic PV dom0. Signed-off-by: Roger Pau Monné --- for-4.14 reasoning: the fix is mostly isolated to PVH dom0, and as such the risk is very low of causing issues to other guests types, but without this fix one vCPU when using a Linux dom0 will be constantly looping over rtc_timer_do_work with 100% CPU usage, at least when using Linux 4.19 or newer. --- Changes since v1: - Share the code with PV. - Add access checks to the IO ports. --- xen/arch/x86/hvm/rtc.c | 34 ++++++++++++++++++ xen/arch/x86/pv/emul-priv-op.c | 28 +++------------ xen/arch/x86/time.c | 59 +++++++++++++++++++++++++++++++ xen/include/asm-x86/mc146818rtc.h | 3 ++ 4 files changed, 100 insertions(+), 24 deletions(-) diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c index 5bbbdc0e0f..9f304a0fb4 100644 --- a/xen/arch/x86/hvm/rtc.c +++ b/xen/arch/x86/hvm/rtc.c @@ -22,6 +22,7 @@ * IN THE SOFTWARE. */ +#include #include #include #include @@ -808,10 +809,43 @@ void rtc_reset(struct domain *d) s->pt.source = PTSRC_isa; } +/* RTC mediator for HVM hardware domain. */ +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, + uint32_t *val) +{ + if ( dir == IOREQ_READ ) + *val = ~0; + + if ( size != 1 ) + { + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); + return X86EMUL_OKAY; + } + if ( !ioports_access_permitted(current->domain, port, port) ) + { + gdprintk(XENLOG_WARNING, "access to RTC port %x not allowed\n", port); + return X86EMUL_OKAY; + } + + if ( dir == IOREQ_WRITE ) + rtc_guest_write(port, *val); + else + *val = rtc_guest_read(port); + + return X86EMUL_OKAY; +} + void rtc_init(struct domain *d) { RTCState *s = domain_vrtc(d); + if ( is_hardware_domain(d) ) + { + /* Hardware domain gets mediated access to the physical RTC. */ + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); + return; + } + if ( !has_vrtc(d) ) return; diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index fad6c754ad..1597f27ed9 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -280,19 +280,10 @@ static uint32_t guest_io_read(unsigned int port, unsigned int bytes, { sub_data = pv_pit_handler(port, 0, 0); } - else if ( port == RTC_PORT(0) ) - { - sub_data = currd->arch.cmos_idx; - } - else if ( (port == RTC_PORT(1)) && + else if ( (port == RTC_PORT(0) || port == RTC_PORT(1)) && ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) { - unsigned long flags; - - spin_lock_irqsave(&rtc_lock, flags); - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); - sub_data = inb(RTC_PORT(1)); - spin_unlock_irqrestore(&rtc_lock, flags); + sub_data = rtc_guest_read(port); } else if ( (port == 0xcf8) && (bytes == 4) ) { @@ -413,21 +404,10 @@ static void guest_io_write(unsigned int port, unsigned int bytes, { pv_pit_handler(port, (uint8_t)data, 1); } - else if ( port == RTC_PORT(0) ) - { - currd->arch.cmos_idx = data; - } - else if ( (port == RTC_PORT(1)) && + else if ( (port == RTC_PORT(0) || port == RTC_PORT(1)) && ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) { - unsigned long flags; - - if ( pv_rtc_handler ) - pv_rtc_handler(currd->arch.cmos_idx & 0x7f, data); - spin_lock_irqsave(&rtc_lock, flags); - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); - outb(data, RTC_PORT(1)); - spin_unlock_irqrestore(&rtc_lock, flags); + rtc_guest_write(port, data); } else if ( (port == 0xcf8) && (bytes == 4) ) { diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c index bbaea3aa65..e1c81067ce 100644 --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include #include @@ -1110,6 +1111,64 @@ static unsigned long get_cmos_time(void) return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); } +/* Helpers for guest accesses to the physical RTC. */ +unsigned int rtc_guest_read(unsigned int port) +{ + const struct domain *currd = current->domain; + unsigned long flags; + unsigned int data = ~0; + + ASSERT(port == RTC_PORT(0) || port == RTC_PORT(1)); + if ( !ioports_access_permitted(currd, port, port) ) + { + ASSERT_UNREACHABLE(); + return data; + } + + switch ( port ) + { + case RTC_PORT(0): + data = currd->arch.cmos_idx; + break; + + case RTC_PORT(1): + spin_lock_irqsave(&rtc_lock, flags); + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); + data = inb(RTC_PORT(1)); + spin_unlock_irqrestore(&rtc_lock, flags); + break; + } + + return data; +} + +void rtc_guest_write(unsigned int port, unsigned int data) +{ + struct domain *currd = current->domain; + unsigned long flags; + + ASSERT(port == RTC_PORT(0) || port == RTC_PORT(1)); + if ( !ioports_access_permitted(currd, port, port) ) + { + ASSERT_UNREACHABLE(); + return; + } + + switch ( port ) + { + case RTC_PORT(0): + currd->arch.cmos_idx = data; + break; + + case RTC_PORT(1): + spin_lock_irqsave(&rtc_lock, flags); + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); + outb(data, RTC_PORT(1)); + spin_unlock_irqrestore(&rtc_lock, flags); + break; + } +} + static unsigned long get_wallclock_time(void) { #ifdef CONFIG_XEN_GUEST diff --git a/xen/include/asm-x86/mc146818rtc.h b/xen/include/asm-x86/mc146818rtc.h index 8758528f7c..803b236c0a 100644 --- a/xen/include/asm-x86/mc146818rtc.h +++ b/xen/include/asm-x86/mc146818rtc.h @@ -110,4 +110,7 @@ outb_p((val),RTC_PORT(1)); \ #define RTC_IRQ 8 +unsigned int rtc_guest_read(unsigned int port); +void rtc_guest_write(unsigned int port, unsigned int data); + #endif /* _ASM_MC146818RTC_H */ -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:06:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:06:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAAi-0004YB-4I; Fri, 05 Jun 2020 11:06:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAAg-0004Y6-VL for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:05:59 +0000 X-Inumbo-ID: 8856a800-a71c-11ea-96fb-bc764e2007e4 Received: from mail-wr1-x42f.google.com (unknown [2a00:1450:4864:20::42f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8856a800-a71c-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 11:05:58 +0000 (UTC) Received: by mail-wr1-x42f.google.com with SMTP id l11so9339022wru.0 for ; Fri, 05 Jun 2020 04:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=sMLA6y3VrYdV8WDI4utr8jCM/UWPfkD7O7iwOFlk4f0=; b=N3JzRNAaU46CHQUDw1WDMWo+HWpBuORl6eRylvN7nf2vvepZiUZzWC7ahEnYH1FQdi pjOvO5MZk+EfVnjbmv6Nkxys4X+taJJdBrcqhvT5nAx3O5UObIbb6z+HVAEKOagXCLyS RzVS6Jdkl/dW2kpaelWEPxYmA0tap7hia5Er7N7acnvF3keQO1R9M0bsd9w2czDI6qjQ 2ig5uXKgQNXZ/zxm2JB85DI44RRxAhWSdPv/jKfPaSoZ8JjmnMWhP9p2BMRVEInLTpTC 4xdCr8acvWJyUUXBw4FDBHhZNYcfsQXjjmHRkq1vVhkO0b/gnTwSGtbU9mntQivstpYy iRPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=sMLA6y3VrYdV8WDI4utr8jCM/UWPfkD7O7iwOFlk4f0=; b=FvnU7KFHmOrTCfoO10DQRi7+eJj40Ylq5pmJQb1uI+fL3V6tO9A+hNhzGJkyFWv4G/ ngDmprjaj3ai5HbsIYz7xR7MDBmVZbQvXkgwICcxMhzprVQCNK+B5KZhyjjo+P/500XE VxRuJ0wyoAgSIWkbrEhJvAiTz08jxcSMLtFrRAqGg+93UUSMnYcJJFvaxOqEDQo0zz0/ OsSN2OpLWe0NVyTo9zlKXefgq1z05ae4TIo+a4jUfPu86H4mk5Ylyz7KHt6rsZ/BTq9N vQiy4/Y602BOvz18K5D3+DsKPOQDANAJGgnP/fejVToPxHNFTBk5qtmXNbZiA29lVO31 89qA== X-Gm-Message-State: AOAM532WPJ/agl8vBRPXnoCj0Atva+xEL1BYDocd2qGVMXwNFMgQxB+q y5wBZAojv7RH9Za5vwmOQwQ= X-Google-Smtp-Source: ABdhPJzRQ2L07jIo+z6l1Yl0Wd2Ae71FPuuduYeNSIeWnIYJVeFhxaz5V7C1OwL9cnAmyb2FH/8q8A== X-Received: by 2002:adf:db09:: with SMTP id s9mr8853520wri.256.1591355157309; Fri, 05 Jun 2020 04:05:57 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id y5sm12169453wrs.63.2020.06.05.04.05.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 04:05:56 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> In-Reply-To: <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 12:05:55 +0100 Message-ID: <000501d63b29$496ce6e0$dc46b4a0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoACJ30jDAXuEodcCsFgQ5AHivRJwAUZxxQCo8P3IUA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Sorry, only just catching up with this... > -----Original Message----- > From: Jan Beulich > Sent: 05 June 2020 10:09 > To: Marek Marczykowski-G=C3=B3recki > Cc: Andrew Cooper ; xen-devel = ; Paul > Durrant > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > > On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: > >> On 04.06.2020 13:13, Andrew Cooper wrote: > >>> On 04/06/2020 08:08, Jan Beulich wrote: > >>>> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > >>>>> Then, we get the main issue: > >>>>> > >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > >>>>> (XEN) domain_crash called from io.c:178 > >>>>> > >>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its = stubdom > >>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called = already. > >>>> I'd guess an issue with the shutdown deferral logic. Did you / = can > >>>> you check whether XEN_DMOP_remote_shutdown managed to pause all > >>>> CPUs (I assume it didn't, since once they're paused there = shouldn't > >>>> be any I/O there anymore, and hence no I/O emulation)? > >>> > >>> The vcpu in question is talking to Qemu, so will have = v->defer_shutdown > >>> intermittently set, and skip the pause in domain_shutdown() > >>> > >>> I presume this lack of pause is to allow the vcpu in question to = still > >>> be scheduled to consume the IOREQ reply? (Its fairly opaque logic = with > >>> 0 clarifying details). > >>> > >>> What *should* happen is that, after consuming the reply, the vcpu = should > >>> notice and pause itself, at which point it would yield to the > >>> scheduler. This is the purpose of = vcpu_{start,end}_shutdown_deferral(). > >>> > >>> Evidentially, this is not happening. > >> > >> We can't tell yet, until ... > >> > >>> Marek: can you add a BUG() after the weird PIO printing? That = should > >>> confirm whether we're getting into handle_pio() via the > >>> handle_hvm_io_completion() path, or via the vmexit path (at which = case, > >>> we're fully re-entering the guest). > >> > >> ... we know this. handle_pio() gets called from = handle_hvm_io_completion() > >> after having called hvm_wait_for_io() -> hvm_io_assist() -> > >> vcpu_end_shutdown_deferral(), so the issue may be that we shouldn't = call > >> handle_pio() (etc) at all anymore in this state. IOW perhaps > >> hvm_wait_for_io() should return = "!sv->vcpu->domain->is_shutting_down" > >> instead of plain "true"? > >> > >> Adding Paul to Cc, as being the maintainer here. > > > > Got it, by sticking BUG() just before that domain_crash() in > > handle_pio(). And also vcpu 0 of both HVM domains do have > > v->defer_shutdown. >=20 > As per the log they did get it set. I'd be curious of the flag's > value (as well as v->paused_for_shutdown's) at the point of the > problematic handle_pio() invocation (see below). It may be > worthwhile to instrument vcpu_check_shutdown() (inside its if()) > - before exiting to guest context (in order to then come back > and call handle_pio()) the vCPU ought to be getting through > there. No indication of it doing so would be a sign that there's > a code path bypassing the call to vcpu_end_shutdown_deferral(). >=20 > > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > > (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > > (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 = d6 > > (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 = d6 > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >=20 > Perhaps in this message could you also log > v->domain->is_shutting_down, v->defer_shutdown, and > v->paused_for_shutdown? (Would be nice if, after having made > changes to your debugging patch, you could point again at the > precise version you've used for the log provided.) >=20 > > (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff > > (XEN) Xen BUG at io.c:178 >=20 > Btw, instead of BUG(), WARN() or dump_execution_state() would > likely also do, keeping Xen alive. >=20 A shutdown deferral problem would result in X86EMUL_RETRY wouldn't it? = That would mean we wouldn't be seeing the "Unexpected PIO" message. From = that message this clearly X86EMUL_UNHANDLEABLE which suggests a race = with ioreq server teardown, possibly due to selecting a server but then = not finding a vcpu match in ioreq_vcpu_list. Paul > Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:19:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:19:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAN5-0005az-9m; Fri, 05 Jun 2020 11:18:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAN3-0005au-M6 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:18:46 +0000 X-Inumbo-ID: 51c78c8a-a71e-11ea-af9f-12813bfff9fa Received: from out3-smtp.messagingengine.com (unknown [66.111.4.27]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 51c78c8a-a71e-11ea-af9f-12813bfff9fa; Fri, 05 Jun 2020 11:18:45 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 049FC5C012C; Fri, 5 Jun 2020 07:18:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 05 Jun 2020 07:18:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=8tbOzL dqHoqtee8s7JzdRooeTy5fY0jAVkxsEy3PYkU=; b=jreeL1NDetYYbk51rbHgXV rKJXOfwAJA8R9G/uwNkpUeTyY7COvHoH1GbsuKa5KaJbKyOckwgGQ2Wmbyi9ycRI zO0rbnh9Mn8507alpSSV4cduv8kxEb8qoindgeyQxMihHXw9YeqUG4wrxCrdSKtD n8m6hMU8F8rNKu8jkrDrz9NGh4R/R1krWFma6MjoW23Al4esnV6jUbpp3Fs+R3C0 ShwTDcfgOqykoRs+CQh8+R/NOoMBd4o6knvt85BCiEWIsFf45uL7SnODJ8RcifoW HvkwzGHpGrXjswbvXGu9S0fbWLNU4Vnf2QB2jNtskZ+yQW1ftDPLPZswSBo2dQEg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeekgedt gfdvieehhfehtddvleeiieeuteevheetffejjeejvdeijeevhfeufeefgeenucffohhmrg hinhepghhithhhuhgsrdgtohhmnecukfhppeeluddrieehrdefgedrfeefnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghkse hinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 57AEE328005A; Fri, 5 Jun 2020 07:18:44 -0400 (EDT) Date: Fri, 5 Jun 2020 13:18:40 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Message-ID: <20200605111840.GE98582@mail-itl> References: <20200604014621.GA203658@mail-itl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/7F8UcOhwbEJvS7n" Content-Disposition: inline In-Reply-To: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --/7F8UcOhwbEJvS7n Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom On Fri, Jun 05, 2020 at 11:38:17AM +0200, Jan Beulich wrote: > On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > > Hi, > >=20 > > (continuation of a thread from #xendevel) > >=20 > > During system shutdown quite often I hit infinite stream of errors like > > this: > >=20 > > (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > > (XEN) domain_crash called from io.c:178 > >=20 > > This is all running on Xen 4.13.0 (I think I've got this with 4.13.1 > > too), nested within KVM. The KVM part means everything is very slow, so > > various race conditions are much more likely to happen. > >=20 > > It started happening not long ago, and I'm pretty sure it's about > > updating to qemu 4.2.0 (in linux stubdom), previous one was 3.0.0. > >=20 > > Thanks to Andrew and Roger, I've managed to collect more info. > >=20 > > Context: > > dom0: pv > > dom1: hvm > > dom2: stubdom for dom1 > > dom3: hvm > > dom4: stubdom for dom3 > > dom5: pvh > > dom6: pvh > >=20 > > It starts I think ok: > >=20 > > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 >=20 > I can't seem to be able to spot the call site of this, in any of > qemu, libxl, or libxc. I'm in particular curious as to the further > actions taken on the domain after this was invoked: Do any ioreq > servers get unregistered immediately (which I think would be a > problem)? It is here: https://github.com/qemu/qemu/blob/master/hw/i386/xen/xen-hvm.c#L1539 I think it's called from cpu_handle_ioreq(), and I think the request state is set to STATE_IORESP_READY before exiting (unless there is some exit() hidden in another function used there). --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --/7F8UcOhwbEJvS7n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7aKhEACgkQ24/THMrX 1yxDHAf+NCJzXnzBD4v148UxdvvTkENOTAZwdNbopbDpxkG1z+EcUES6FBtF1AGa oEeKB0MXVTZWCbiIrKe1LiiToeAJx+8eQH8xCXTGPezNOFC8OYPuc57I6lkY4q6k UvvWOv+d5bwe+aos3bp5PZvMptEwMdvG9S6fVURWRPgpP6rVkRRS6eA94fBnChEP y8gOkq/617gZ6kAR1Dvys0RJ0m0IIqEAKeBJWLMgZ4eKTSg+aE/mayNIP9LhWvWM rCJDKu6Jc80Lfr2Dq8Uzqq44KY5DwfANZSOq1umSqkUPtByOhOYFQssjhenIjNd1 RrcDYzjpdllQklL/6INmW3E+oaSE7A== =lyNc -----END PGP SIGNATURE----- --/7F8UcOhwbEJvS7n-- From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:25:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:25:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhATy-0006Zq-1L; Fri, 05 Jun 2020 11:25:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhATw-0006Zl-5k for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:25:52 +0000 X-Inumbo-ID: 4f2c5748-a71f-11ea-9ad7-bc764e2007e4 Received: from mail-wm1-x336.google.com (unknown [2a00:1450:4864:20::336]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4f2c5748-a71f-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 11:25:50 +0000 (UTC) Received: by mail-wm1-x336.google.com with SMTP id v19so8110081wmj.0 for ; Fri, 05 Jun 2020 04:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=dlYTlG/wymsby/4U+vjonCAb2F5ntKKcsWFlhfbgi5I=; b=WS09KQ7EsjMBoQrJ/ZgYKD0icqMrZlH2uMwwQ1V0z14uHzqhUHlwSycHxvCnPqEaNV MD8pjL8UYBv5yWhsDVCjvyzKnHUKxVNuz+QbP8sO0m6x8EjSEI2bu2dVCjDC969Kz+bL bta7ek6CqH3jaUrEF6+VxnrUghfEzbHUWIZ6lAhPKl0EdOoXLSxPfhuXfQKLz//pRcxn RFQ5S1bvwfNJNkMBZyM0ZZd5/FkUVtQbnSfv1EhFT/wvFh/a70yHrN42wQknianrTDkF f2hPd1peQ4WsIq7PO3H/6rplKsFZNT4EEek1dII6p8ZsyyjlUPDyY0s/EJpxjP7ERZmW 0aTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=dlYTlG/wymsby/4U+vjonCAb2F5ntKKcsWFlhfbgi5I=; b=PpeUh7uTFQBg8rGZ+Lm66KuhTA9sfczGNb89OIixVjFtF+GSnnF5vniyXihsN5vD12 hx4ZWds603TSoj1Snzc8gVcHHgHZMmv09SYuKvJk9HTSN6U/MGp/AphGiR9YHoIOvrHm PXvidsBLfzEA0Fg9/g7EK7Br+IPhNjzAyl8AORmPli+baj3gBN6vzG/yHJo41/J9zi/+ 2qR5eZae5EUOas0/Pr9vpQeizsOYLa4ih4pUjP9aw6q6K4L13kysV794dcsgvFI58WOK xQe0dlfT0PE5j0NnEEM6y8Cj4z9fFrVcMHbup869kPkzxniGgXd5d6Kp0zq3FOy1ncVc G8ag== X-Gm-Message-State: AOAM531gtFMuYU0IuKQq7LLjJVDHbbL2ReVkExR9aibsyhkNezcAZDNp tn/cv6+2mZGUc3gnlkawZGM= X-Google-Smtp-Source: ABdhPJyJP2N4Y/lD+1IJcoUcakf+Edk6oYfMzMR1pUMbN70kPPRbFXOaj66o/SPsSoCw6F+qt+E/kg== X-Received: by 2002:a1c:4008:: with SMTP id n8mr2375719wma.118.1591356349822; Fri, 05 Jun 2020 04:25:49 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id j5sm11644078wrq.39.2020.06.05.04.25.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 04:25:49 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: , "'Jan Beulich'" , =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> In-Reply-To: <000501d63b29$496ce6e0$dc46b4a0$@xen.org> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 12:25:48 +0100 Message-ID: <000701d63b2c$10536930$30fa3b90$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoACJ30jDAXuEodcCsFgQ5AHivRJwAUZxxQAClbGaTqjcVVBw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Paul Durrant > Sent: 05 June 2020 12:06 > To: 'Jan Beulich' ; 'Marek = Marczykowski-G=C3=B3recki' > Cc: 'Andrew Cooper' ; 'xen-devel' = > Subject: RE: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > Sorry, only just catching up with this... >=20 > > -----Original Message----- > > From: Jan Beulich > > Sent: 05 June 2020 10:09 > > To: Marek Marczykowski-G=C3=B3recki = > > Cc: Andrew Cooper ; xen-devel = ; Paul > > Durrant > > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > > > > On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > > > On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: > > >> On 04.06.2020 13:13, Andrew Cooper wrote: > > >>> On 04/06/2020 08:08, Jan Beulich wrote: > > >>>> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > > >>>>> Then, we get the main issue: > > >>>>> > > >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > > >>>>> (XEN) domain_crash called from io.c:178 > > >>>>> > > >>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor = its stubdom > > >>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called = already. > > >>>> I'd guess an issue with the shutdown deferral logic. Did you / = can > > >>>> you check whether XEN_DMOP_remote_shutdown managed to pause all > > >>>> CPUs (I assume it didn't, since once they're paused there = shouldn't > > >>>> be any I/O there anymore, and hence no I/O emulation)? > > >>> > > >>> The vcpu in question is talking to Qemu, so will have = v->defer_shutdown > > >>> intermittently set, and skip the pause in domain_shutdown() > > >>> > > >>> I presume this lack of pause is to allow the vcpu in question to = still > > >>> be scheduled to consume the IOREQ reply? (Its fairly opaque = logic with > > >>> 0 clarifying details). > > >>> > > >>> What *should* happen is that, after consuming the reply, the = vcpu should > > >>> notice and pause itself, at which point it would yield to the > > >>> scheduler. This is the purpose of = vcpu_{start,end}_shutdown_deferral(). > > >>> > > >>> Evidentially, this is not happening. > > >> > > >> We can't tell yet, until ... > > >> > > >>> Marek: can you add a BUG() after the weird PIO printing? That = should > > >>> confirm whether we're getting into handle_pio() via the > > >>> handle_hvm_io_completion() path, or via the vmexit path (at = which case, > > >>> we're fully re-entering the guest). > > >> > > >> ... we know this. handle_pio() gets called from = handle_hvm_io_completion() > > >> after having called hvm_wait_for_io() -> hvm_io_assist() -> > > >> vcpu_end_shutdown_deferral(), so the issue may be that we = shouldn't call > > >> handle_pio() (etc) at all anymore in this state. IOW perhaps > > >> hvm_wait_for_io() should return = "!sv->vcpu->domain->is_shutting_down" > > >> instead of plain "true"? > > >> > > >> Adding Paul to Cc, as being the maintainer here. > > > > > > Got it, by sticking BUG() just before that domain_crash() in > > > handle_pio(). And also vcpu 0 of both HVM domains do have > > > v->defer_shutdown. > > > > As per the log they did get it set. I'd be curious of the flag's > > value (as well as v->paused_for_shutdown's) at the point of the > > problematic handle_pio() invocation (see below). It may be > > worthwhile to instrument vcpu_check_shutdown() (inside its if()) > > - before exiting to guest context (in order to then come back > > and call handle_pio()) the vCPU ought to be getting through > > there. No indication of it doing so would be a sign that there's > > a code path bypassing the call to vcpu_end_shutdown_deferral(). > > > > > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > > > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > > > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > > > (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > > > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > > > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > > > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > > > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > > (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > > > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > > > (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags = 0x2 d6 > > > (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags = 0x2 d6 > > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > > Perhaps in this message could you also log > > v->domain->is_shutting_down, v->defer_shutdown, and > > v->paused_for_shutdown? (Would be nice if, after having made > > changes to your debugging patch, you could point again at the > > precise version you've used for the log provided.) > > > > > (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff > > > (XEN) Xen BUG at io.c:178 > > > > Btw, instead of BUG(), WARN() or dump_execution_state() would > > likely also do, keeping Xen alive. > > >=20 > A shutdown deferral problem would result in X86EMUL_RETRY wouldn't it? = That would mean we wouldn't be > seeing the "Unexpected PIO" message. From that message this clearly = X86EMUL_UNHANDLEABLE which > suggests a race with ioreq server teardown, possibly due to selecting = a server but then not finding a > vcpu match in ioreq_vcpu_list. Actually looking at remote_shutdown... the test of ( reason =3D=3D = SHUTDOWN_crash ) and then clearing defer_shutdown looks a bit odd... = Just because the domain shutdown code has been set that way doesn't mean = that a vcpu is not deferred in emulation; SCHEDOP_shutdown_code could = easily be called from one vcpu whilst another has emulation pending. Paul >=20 > Paul >=20 > > Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:37:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:37:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAfD-0007cj-9K; Fri, 05 Jun 2020 11:37:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAfC-0007ce-Bv for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:37:30 +0000 X-Inumbo-ID: efeae05e-a720-11ea-afa3-12813bfff9fa Received: from mail-wr1-f66.google.com (unknown [209.85.221.66]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id efeae05e-a720-11ea-afa3-12813bfff9fa; Fri, 05 Jun 2020 11:37:29 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id l10so9386843wrr.10 for ; Fri, 05 Jun 2020 04:37:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=6rwoWVKrSvqfrI6Iyp/Gjae4Z7e8hfSug4PMkSldLdA=; b=dLPrVCZGlNTXcDg6O7dNkPx0WGntv7PXJ4FK5Nfq2AKgqhBUISFZ2JIV0EXeic1gnm zVd8Te4DznfzOgfB/vgbhohDlOavKcw0ykVZrwLZWDjg4oVxricdrLRtfTmJ8E1kqrEb nYLD86dPrNpkrRXCdn8chONQFXioDSGJ8CC42jqqwPMG7YKvkqLNXKeAh0D/ACuqKAlG NVcIfAa8rP7H0Xyuemc0CZOHKDmV4il2iTL5ev2yST3V8cApaetR6nn0iD2u87cDRxvj APdTLNnw9nlQMKLkBrVY9kJZbXiPSXgOWurL7IhZBkXvfAj+T+js6zXPO0YIhSQIGx0z TwAw== X-Gm-Message-State: AOAM532WkiYDNmBzQQgJLrM55VF30z04EClJfGBVm6Jp+p31RdE29Be1 NnBDzTdmoMX0m71TRn/2P24jwVQg X-Google-Smtp-Source: ABdhPJyz1oEsfnBmGLJmXHLwhhEomtCn9kKaRcZhZEyWxNAOtw4SJnKGfOju83LUCj0xqyTot93Cxw== X-Received: by 2002:a5d:5351:: with SMTP id t17mr8863579wrv.287.1591357048741; Fri, 05 Jun 2020 04:37:28 -0700 (PDT) Received: from liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id z25sm10887532wmf.10.2020.06.05.04.37.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2020 04:37:28 -0700 (PDT) From: Wei Liu To: Xen Development List Subject: [PATCH for-4.14] libs/hypfs: use correct zlib name in pc file Date: Fri, 5 Jun 2020 11:37:25 +0000 Message-Id: <20200605113725.30982-1-wl@xen.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Olaf Hering , Ian Jackson , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Its name is "zlib" not "z". Reported-by: Olaf Hering Fixes: 86234eafb952 ("libs: add libxenhypfs") Signed-off-by: Wei Liu --- Cc: paul@xen.org Cc: jgross@suse.com --- tools/libs/hypfs/xenhypfs.pc.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libs/hypfs/xenhypfs.pc.in b/tools/libs/hypfs/xenhypfs.pc.in index 92a262c7a252..ef9fcc87bf37 100644 --- a/tools/libs/hypfs/xenhypfs.pc.in +++ b/tools/libs/hypfs/xenhypfs.pc.in @@ -7,4 +7,4 @@ Description: The Xenhypfs library for Xen hypervisor Version: @@version@@ Cflags: -I${includedir} @@cflagslocal@@ Libs: @@libsflag@@${libdir} -lxenhypfs -Requires.private: xentoolcore,xentoollog,xencall,z +Requires.private: xentoolcore,xentoollog,xencall,zlib -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:43:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:43:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAkb-000086-Vz; Fri, 05 Jun 2020 11:43:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAkb-000081-CQ for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:43:05 +0000 X-Inumbo-ID: b762d0a6-a721-11ea-96fb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b762d0a6-a721-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 11:43:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B49E5AF39; Fri, 5 Jun 2020 11:43:06 +0000 (UTC) Subject: Re: [PATCH for-4.14] libs/hypfs: use correct zlib name in pc file To: Wei Liu , Xen Development List References: <20200605113725.30982-1-wl@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <034b6887-640e-a051-3821-00ef7615e010@suse.com> Date: Fri, 5 Jun 2020 13:43:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200605113725.30982-1-wl@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Olaf Hering , Ian Jackson , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.20 13:37, Wei Liu wrote: > Its name is "zlib" not "z". > > Reported-by: Olaf Hering > Fixes: 86234eafb952 ("libs: add libxenhypfs") > Signed-off-by: Wei Liu Reviewed-by: Juergen Gross Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:43:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:43:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAlP-0000CI-8u; Fri, 05 Jun 2020 11:43:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAlN-0000C4-PE for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:43:53 +0000 X-Inumbo-ID: d3e0148c-a721-11ea-afa3-12813bfff9fa Received: from mail-wr1-f67.google.com (unknown [209.85.221.67]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d3e0148c-a721-11ea-afa3-12813bfff9fa; Fri, 05 Jun 2020 11:43:52 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id t18so9430762wru.6 for ; Fri, 05 Jun 2020 04:43:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=nAlcKlfPk6ZczuCNLD7Qy+W72K+JE/r+jEbqZSuN73A=; b=LSM+JFO+48v0Ohu2oRr1HSBfue+MY/8ChkSX0YunZd4u9wdJTcCGevgSacmxyjkn6t gui/hyn2ea/wub8YR7cS2Hhf4Khu/SeTy18R401WUNjrheumv68uqlHdE3xW26ciG9ll t7irBfo146kYW5Nx9/dD77AOjOH8ACXJXNLhIPLTS5l3Z01Uuot1kgIfJE8mqK/C2bOm /4yjUB9Yc4H0gy1mMpE7sC8xqQvvmBp5G30Fs6VfLhQyiiNholh+psFUyXsZzY9Q11n7 SvWwVDIVUnbOPH4E3z/0PssN0pBUsLDZ0ncHI69cKqbszpNdwMM8GdP8OWA9Fsuzk01d wQDA== X-Gm-Message-State: AOAM530edHQb9mhpROk7rpT4RfqNXuhhFth+qnIslNQF/oKqMAI8NBqK 2YYFvBPh/ORr+0cp4ZWEcIw= X-Google-Smtp-Source: ABdhPJwk5JFiutWhFvs6jtx9brPV918LsB6xJJvSQR+LoY3m8DPWWV6wksSIZFnDc1TDPludAcWYcw== X-Received: by 2002:a5d:5084:: with SMTP id a4mr9464565wrt.416.1591357431548; Fri, 05 Jun 2020 04:43:51 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id e12sm11154197wro.52.2020.06.05.04.43.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jun 2020 04:43:51 -0700 (PDT) Date: Fri, 5 Jun 2020 11:43:49 +0000 From: Wei Liu To: Roger Pau Monne Subject: Re: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200605114349.5ugjbwwoot5jq6qs@liuwe-devbox-debian-v2> References: <20200605110240.52545-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200605110240.52545-1-roger.pau@citrix.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 01:02:39PM +0200, Roger Pau Monne wrote: > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > code paths (guest_io_{write/read}), but those accesses where never > implemented for PVHv2 dom0. This patch provides such mediated accesses > to the RTC for PVH dom0, just like it's provided for a classic PV > dom0. > > Pull out some of the RTC logic from guest_io_{read/write} into > specific helpers that can be used by both PV and HVM guests. The > setup of the handlers for PVH is done in rtc_init, which is already > used to initialize the fully emulated RTC. > > Without this a Linux PVH dom0 will read garbage when trying to access > the RTC, and one vCPU will be constantly looping in > rtc_timer_do_work. > > Note that such issue doesn't happen on domUs because the ACPI > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > accesses are not emulated but rather forwarded to the physical > hardware. > > No functional change expected for classic PV dom0. > > Signed-off-by: Roger Pau Monn Reviewed-by: Wei Liu From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:54:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:54:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAvk-0001GB-96; Fri, 05 Jun 2020 11:54:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAvj-0001G6-13 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:54:35 +0000 X-Inumbo-ID: 526195be-a723-11ea-afa4-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 526195be-a723-11ea-afa4-12813bfff9fa; Fri, 05 Jun 2020 11:54:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=I90I8iOj7Xwt5/Mw1Doijh+XXWNpGPeBgsp1iEMgf1U=; b=lr2PfaBCIE96SUtVDdIPDn+UY K5GlaPjStCsDYWH1QFKSbfQJVV04mv3Sad0QxTjOQ/GrW3iiWq6gnVy8B6+zG8sZ3lLRxHm959xMn QAEhC/wLZb8WLjTOirzAmsdkHgxS/PXlWdqjXd6wQlmw0ZbxfCGg33/9tb2jBwUPJeBRs=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAvh-0003op-6v; Fri, 05 Jun 2020 11:54:33 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhAvh-00026S-0M; Fri, 05 Jun 2020 11:54:33 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhAvg-0000tv-Vv; Fri, 05 Jun 2020 11:54:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150819: all pass - PUSHED X-Osstest-Versions-This: ovmf=8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae X-Osstest-Versions-That: ovmf=bb78cfbec07eda45118b630a09b0af549b43a135 From: osstest service owner Date: Fri, 05 Jun 2020 11:54:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150819 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150819/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae baseline version: ovmf bb78cfbec07eda45118b630a09b0af549b43a135 Last test of basis 150687 2020-06-04 09:14:34 Z 1 days Testing same since 150819 2020-06-05 08:09:18 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Vijayenthiran Subramaniam jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git bb78cfbec0..8035edbe12 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:57:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:57:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAyh-0001PJ-P1; Fri, 05 Jun 2020 11:57:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAyg-0001PE-8W for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:57:38 +0000 X-Inumbo-ID: bf8e9fce-a723-11ea-ba62-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bf8e9fce-a723-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 11:57:37 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id r9so8176464wmh.2 for ; Fri, 05 Jun 2020 04:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=/Z3IiW4Dj+Tgq0+EAhnruPPTjwya0rgFqiypjw0GVPk=; b=EvpctvPPcTlUBgxjXtKAkel+uxUrQ4y9ICz6HP7MfG7P9Avj7YGY+EtycnXSVpUO72 gx5bg8fxhFqL58uBgvX/1jUPRQS+jzNsQPYZHR7VZF17wDX5fNfQGJOlVCrXHx56TI4u Y5REPTMPrFu9anN16bJPa4kjBd1itRHdFaqoE2rl9Oc3ULLOjEAq5lGfuX43FoJvJQBk gvQH6/3Wk4ALHmpklWAiXgBrmp5xq5MEZRU6FQiozuTNvXN08NJOH7ROplE0lHLm96dQ b29TVSPbG1ercEt1rc73+MXWbzFcw8oB0tdBOF0yu6yn8gTojBij6b3wM/4KWJpllET8 0BSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=/Z3IiW4Dj+Tgq0+EAhnruPPTjwya0rgFqiypjw0GVPk=; b=tx9GbYX6sJNIHUHh/Hzpu41Q3vxPTp9AisbCyA3CFZP7wVitrcxhI6cHvvMPMtzkXv cIv7cV+VTDlfZOOGbhvGgZy4w2aNczlMd/YcFuang0Hu52c/rcF6PT9DXhYwz7TvWe0B M0pl0MDcmiYkHItKWTaZjHbSwj8Nc811CrtPNKjjiDGdnP4ABvupSQ8q7jG9jMT2kQZy 9yXobVtvxKIIIbl2EdkzhzkznS6z0wcxBEAFYmZgi4ET3fmBcqCkDBX02wRJPJyOgmzQ 75zwXFzkdZxnPpCk0ty8SxbHFYCI+YSoRKP5+SSKZ39p1wgF8feQ4jLLZcEVX/5072nS P17Q== X-Gm-Message-State: AOAM531C7293nQ1fZx7NrioaJfWAe/8fmdUMWFgONdO+h/7b4UPApSsi ExH2FgHbRb+ECxTnxb9hUR4= X-Google-Smtp-Source: ABdhPJxM67AMJEzfD0cpU7FdnjtAdgsVWOvElYNcBxc1ppRbzGCeTxQGm1M5agGrLufD30Kjb5l3tg== X-Received: by 2002:a1c:6a1a:: with SMTP id f26mr2449090wmc.80.1591358256354; Fri, 05 Jun 2020 04:57:36 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id x66sm11488392wmb.40.2020.06.05.04.57.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 04:57:35 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200605110240.52545-1-roger.pau@citrix.com> In-Reply-To: <20200605110240.52545-1-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC for PVH dom0 Date: Fri, 5 Jun 2020 12:57:34 +0100 Message-ID: <000801d63b30$8099f250$81cdd6f0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQH6D0FLdGtfhWalmvEJkq2BGOkEaaiCQlbg X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 05 June 2020 12:03 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich = ; Andrew > Cooper ; Wei Liu > Subject: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC = for PVH dom0 >=20 > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > code paths (guest_io_{write/read}), but those accesses where never > implemented for PVHv2 dom0. This patch provides such mediated accesses > to the RTC for PVH dom0, just like it's provided for a classic PV > dom0. >=20 > Pull out some of the RTC logic from guest_io_{read/write} into > specific helpers that can be used by both PV and HVM guests. The > setup of the handlers for PVH is done in rtc_init, which is already > used to initialize the fully emulated RTC. >=20 > Without this a Linux PVH dom0 will read garbage when trying to access > the RTC, and one vCPU will be constantly looping in > rtc_timer_do_work. >=20 > Note that such issue doesn't happen on domUs because the ACPI > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > accesses are not emulated but rather forwarded to the physical > hardware. >=20 > No functional change expected for classic PV dom0. >=20 > Signed-off-by: Roger Pau Monn=C3=A9 Release-acked-by: Paul Durrant > --- > for-4.14 reasoning: the fix is mostly isolated to PVH dom0, and as > such the risk is very low of causing issues to other guests types, but > without this fix one vCPU when using a Linux dom0 will be constantly > looping over rtc_timer_do_work with 100% CPU usage, at least when > using Linux 4.19 or newer. > --- > Changes since v1: > - Share the code with PV. > - Add access checks to the IO ports. > --- > xen/arch/x86/hvm/rtc.c | 34 ++++++++++++++++++ > xen/arch/x86/pv/emul-priv-op.c | 28 +++------------ > xen/arch/x86/time.c | 59 = +++++++++++++++++++++++++++++++ > xen/include/asm-x86/mc146818rtc.h | 3 ++ > 4 files changed, 100 insertions(+), 24 deletions(-) >=20 > diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c > index 5bbbdc0e0f..9f304a0fb4 100644 > --- a/xen/arch/x86/hvm/rtc.c > +++ b/xen/arch/x86/hvm/rtc.c > @@ -22,6 +22,7 @@ > * IN THE SOFTWARE. > */ >=20 > +#include > #include > #include > #include > @@ -808,10 +809,43 @@ void rtc_reset(struct domain *d) > s->pt.source =3D PTSRC_isa; > } >=20 > +/* RTC mediator for HVM hardware domain. */ > +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, > + uint32_t *val) > +{ > + if ( dir =3D=3D IOREQ_READ ) > + *val =3D ~0; > + > + if ( size !=3D 1 ) > + { > + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); > + return X86EMUL_OKAY; > + } > + if ( !ioports_access_permitted(current->domain, port, port) ) > + { > + gdprintk(XENLOG_WARNING, "access to RTC port %x not = allowed\n", port); > + return X86EMUL_OKAY; > + } > + > + if ( dir =3D=3D IOREQ_WRITE ) > + rtc_guest_write(port, *val); > + else > + *val =3D rtc_guest_read(port); > + > + return X86EMUL_OKAY; > +} > + > void rtc_init(struct domain *d) > { > RTCState *s =3D domain_vrtc(d); >=20 > + if ( is_hardware_domain(d) ) > + { > + /* Hardware domain gets mediated access to the physical RTC. = */ > + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); > + return; > + } > + > if ( !has_vrtc(d) ) > return; >=20 > diff --git a/xen/arch/x86/pv/emul-priv-op.c = b/xen/arch/x86/pv/emul-priv-op.c > index fad6c754ad..1597f27ed9 100644 > --- a/xen/arch/x86/pv/emul-priv-op.c > +++ b/xen/arch/x86/pv/emul-priv-op.c > @@ -280,19 +280,10 @@ static uint32_t guest_io_read(unsigned int port, = unsigned int bytes, > { > sub_data =3D pv_pit_handler(port, 0, 0); > } > - else if ( port =3D=3D RTC_PORT(0) ) > - { > - sub_data =3D currd->arch.cmos_idx; > - } > - else if ( (port =3D=3D RTC_PORT(1)) && > + else if ( (port =3D=3D RTC_PORT(0) || port =3D=3D = RTC_PORT(1)) && > ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) > { > - unsigned long flags; > - > - spin_lock_irqsave(&rtc_lock, flags); > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > - sub_data =3D inb(RTC_PORT(1)); > - spin_unlock_irqrestore(&rtc_lock, flags); > + sub_data =3D rtc_guest_read(port); > } > else if ( (port =3D=3D 0xcf8) && (bytes =3D=3D 4) ) > { > @@ -413,21 +404,10 @@ static void guest_io_write(unsigned int port, = unsigned int bytes, > { > pv_pit_handler(port, (uint8_t)data, 1); > } > - else if ( port =3D=3D RTC_PORT(0) ) > - { > - currd->arch.cmos_idx =3D data; > - } > - else if ( (port =3D=3D RTC_PORT(1)) && > + else if ( (port =3D=3D RTC_PORT(0) || port =3D=3D = RTC_PORT(1)) && > ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) > { > - unsigned long flags; > - > - if ( pv_rtc_handler ) > - pv_rtc_handler(currd->arch.cmos_idx & 0x7f, data); > - spin_lock_irqsave(&rtc_lock, flags); > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > - outb(data, RTC_PORT(1)); > - spin_unlock_irqrestore(&rtc_lock, flags); > + rtc_guest_write(port, data); > } > else if ( (port =3D=3D 0xcf8) && (bytes =3D=3D 4) ) > { > diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c > index bbaea3aa65..e1c81067ce 100644 > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1110,6 +1111,64 @@ static unsigned long get_cmos_time(void) > return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, = rtc.sec); > } >=20 > +/* Helpers for guest accesses to the physical RTC. */ > +unsigned int rtc_guest_read(unsigned int port) > +{ > + const struct domain *currd =3D current->domain; > + unsigned long flags; > + unsigned int data =3D ~0; > + > + ASSERT(port =3D=3D RTC_PORT(0) || port =3D=3D RTC_PORT(1)); > + if ( !ioports_access_permitted(currd, port, port) ) > + { > + ASSERT_UNREACHABLE(); > + return data; > + } > + > + switch ( port ) > + { > + case RTC_PORT(0): > + data =3D currd->arch.cmos_idx; > + break; > + > + case RTC_PORT(1): > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + data =3D inb(RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + } > + > + return data; > +} > + > +void rtc_guest_write(unsigned int port, unsigned int data) > +{ > + struct domain *currd =3D current->domain; > + unsigned long flags; > + > + ASSERT(port =3D=3D RTC_PORT(0) || port =3D=3D RTC_PORT(1)); > + if ( !ioports_access_permitted(currd, port, port) ) > + { > + ASSERT_UNREACHABLE(); > + return; > + } > + > + switch ( port ) > + { > + case RTC_PORT(0): > + currd->arch.cmos_idx =3D data; > + break; > + > + case RTC_PORT(1): > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + outb(data, RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + } > +} > + > static unsigned long get_wallclock_time(void) > { > #ifdef CONFIG_XEN_GUEST > diff --git a/xen/include/asm-x86/mc146818rtc.h = b/xen/include/asm-x86/mc146818rtc.h > index 8758528f7c..803b236c0a 100644 > --- a/xen/include/asm-x86/mc146818rtc.h > +++ b/xen/include/asm-x86/mc146818rtc.h > @@ -110,4 +110,7 @@ outb_p((val),RTC_PORT(1)); \ >=20 > #define RTC_IRQ 8 >=20 > +unsigned int rtc_guest_read(unsigned int port); > +void rtc_guest_write(unsigned int port, unsigned int data); > + > #endif /* _ASM_MC146818RTC_H */ > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 05 11:58:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 11:58:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAzO-0001Sx-1t; Fri, 05 Jun 2020 11:58:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhAzN-0001Sr-GU for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 11:58:21 +0000 X-Inumbo-ID: d9a70752-a723-11ea-ba62-bc764e2007e4 Received: from mail-wr1-x42e.google.com (unknown [2a00:1450:4864:20::42e]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d9a70752-a723-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 11:58:21 +0000 (UTC) Received: by mail-wr1-x42e.google.com with SMTP id x14so9483626wrp.2 for ; Fri, 05 Jun 2020 04:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=X70M0hlzZe8eXowF5APwX6NaELX9i1ZwBfvg/wb42UU=; b=YMwsAhHQJQpd101MeIH3DDI41TfllaBIGK3NVl4qz+Q72cYOcPwUbqopTD4c60OBTh uU13SOW96YHmLdaWMKmuBN1G71cy/JMrQnB82PKISkYWVu2F9Po88jAn3PgBjDWRbzuJ +fNh9RxKVu108bhPGmzep1hMeILgfsKv2o2pVqgTgHh94byKu4J75WA+m9ZjDV755JRY 7RiCLjT9h8TTidqv3L/dn4uIk0354vLsIkMKhzqIV/hTGJlcCHFLiPBAKcpaI/vNP9RX HxdULG0v/a3afsqLH5Yadad4ng3ANvWRVdrTreTx+zTFGDK4i0Bv5rh4BTUhr252onp+ j9MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=X70M0hlzZe8eXowF5APwX6NaELX9i1ZwBfvg/wb42UU=; b=DPj0Dg3R7+g66kSSYB6a44QjZ1PTjv7kwHbw6SBKzvpaKkf0M2+xsRJEd4k7le3fxB lkw4z1bK8NtXj8Dn0KzGebh9//nj+FuW3T1paq21sE4aV4WTg/qvA9YfYNShB+1JpYBB 8zTe0L34iqp7A7rpjeiaOCgWTbMvVdZ+GA5XNxF8DXALanpAAqviF4deEa5UPWKIt7X+ FLo7OCQjBbGp3mHVz/lkLy0QGhL8qk0jD8QxoGrI8IFMNR59M76OEewrwdymBPeCkXD3 lg2E18olU3XfoAWXb5jTyrvDqhODDBQYpJF78Wmu8GKd81Dq4LjKkLiBkso1glI1OwAz XSjw== X-Gm-Message-State: AOAM532fshoRId9bzWETSqxyl82aPZHU2mOkJcukDkoknLWVAQTLpi1r i43QKl1qqYTfUBDLPBIAKck= X-Google-Smtp-Source: ABdhPJzzk81kTzUgl4+UgSD5CtnQysKx6Y8qRJBuYHCOhNC6BxIoFviWwifSRgLUkqDlsYgetLgT3w== X-Received: by 2002:a5d:4f81:: with SMTP id d1mr9760699wru.95.1591358300265; Fri, 05 Jun 2020 04:58:20 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id d17sm13305715wrg.75.2020.06.05.04.58.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 04:58:19 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?UTF-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= , "'Wei Liu'" , "'Xen Development List'" References: <20200605113725.30982-1-wl@xen.org> <034b6887-640e-a051-3821-00ef7615e010@suse.com> In-Reply-To: <034b6887-640e-a051-3821-00ef7615e010@suse.com> Subject: RE: [PATCH for-4.14] libs/hypfs: use correct zlib name in pc file Date: Fri, 5 Jun 2020 12:58:18 +0100 Message-ID: <000901d63b30$9ae387c0$d0aa9740$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJZ2oA9oTpBQ9HF2jO5jtyhfN6PPAK/A/bLp6yz+LA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Olaf Hering' , 'Ian Jackson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: J=C3=BCrgen Gro=C3=9F > Sent: 05 June 2020 12:43 > To: Wei Liu ; Xen Development List = > Cc: Olaf Hering ; paul@xen.org; Ian Jackson = > Subject: Re: [PATCH for-4.14] libs/hypfs: use correct zlib name in pc = file >=20 > On 05.06.20 13:37, Wei Liu wrote: > > Its name is "zlib" not "z". > > > > Reported-by: Olaf Hering > > Fixes: 86234eafb952 ("libs: add libxenhypfs") > > Signed-off-by: Wei Liu >=20 > Reviewed-by: Juergen Gross > Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Fri Jun 05 12:01:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 12:01:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhB2e-0002VV-Vs; Fri, 05 Jun 2020 12:01:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhB2d-0002VQ-J1 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 12:01:43 +0000 X-Inumbo-ID: 5155f347-a724-11ea-afa5-12813bfff9fa Received: from wout3-smtp.messagingengine.com (unknown [64.147.123.19]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5155f347-a724-11ea-afa5-12813bfff9fa; Fri, 05 Jun 2020 12:01:42 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 3384B60F; Fri, 5 Jun 2020 08:01:41 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 05 Jun 2020 08:01:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Tgwya9 oSsAp2RwRCuoKIgeUwTMvQcQrcDwbg3ZtqayY=; b=OdEo6UUDSaKwwhyYKEHA3M ifv1+yHJeWkbUkZvCyh9lllpq/L+Sel3s/wHf6vMXhtw+it8qDVSPPWPrGX0a/G8 EQXea0W6avwV971LZx3cZhwpDLvJWBwG+gtv4o2nFR2R2yQbr/HaBqCFTtPqh4mS 65vRlqIk7Cr2VSr0LEdsAWbf06ep1dF+V9ndK+TbWjASpOfmse4SxR70qXQrGrxC i58fa6512Qq/bWIJO9Iz1i9Pb6SLEgDTq181SjibKi7LWZrilv9akCqDnNn32NXU K+PrI1T2hd+OAsKb0aJtEfe9L1Z/bzVZi0071SDl+NrQih6IIgjF13FXMz58qc2A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeetveff iefghfekhffggeeffffhgeevieektedthfehveeiheeiiedtudegfeetffenucfkpheple durdeihedrfeegrdeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd gtohhm X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id D094430618B7; Fri, 5 Jun 2020 08:01:39 -0400 (EDT) Date: Fri, 5 Jun 2020 14:01:37 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jan Beulich Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Message-ID: <20200605120137.GF98582@mail-itl> References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YCGSkTKVt49j0xAo" Content-Disposition: inline In-Reply-To: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , xen-devel , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --YCGSkTKVt49j0xAo Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom On Fri, Jun 05, 2020 at 11:22:46AM +0200, Jan Beulich wrote: > On 05.06.2020 11:09, Jan Beulich wrote: > > On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > >> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > >> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > >> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > >> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > >> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > >> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > >> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 > >> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >=20 > > Perhaps in this message could you also log > > v->domain->is_shutting_down, v->defer_shutdown, and > > v->paused_for_shutdown? >=20 > And v->domain->is_shut_down please. Here it is: (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shut= down 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shut= down 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d3v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer_shu= tdown 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d3v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer_shu= tdown 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shut= down 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shut= down 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d1v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer_shu= tdown 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d1v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer_shu= tdown 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done (XEN) grant_table.c:3702:d0v1 Grant release 0x3 ref 0x125 flags 0x2 d6 (XEN) grant_table.c:3702:d0v1 Grant release 0x4 ref 0x126 flags 0x2 d6 (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 1 defer_shut= down 1 paused_for_shutdown 0 is_shut_down 0 (XEN) d1v0 Unexpected PIO status 1, port 0xb004 read 0xffff (and then the stacktrace saying it's from vmexit handler) Regarding BUG/WARN - do you think I could get any more info then? I really don't mind crashing that system, it's a virtual machine currently used only for debugging this issue. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --YCGSkTKVt49j0xAo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7aNCAACgkQ24/THMrX 1yyxzgf9HLTtJBMDyDhKjMlHR/zTr/kgWaborb8SY3XT0jFfEGmIN2i+ufMRz/zO SKDBDRQfLQCINcu+RnkOEHVDrIzkm2zPpW26eeZ7FnlHpMfPhCONp3rekvXgtHUP +++54nmnAF1QgHLWfznF2DECuLnDETlDQGVSEgb1pcnqEco2NbvPOYZiBDu844hJ b4aC0caFB+jUEkt16g/RceDaH8XI0sFJ2K+dnoTa7Wa2heWjKAKhXpFoY0NqgUDd U4usKPo2BVDM2lBJw3FRw/5I4X8q1YeE2D/jACmteOZdn4IIFseo0RHKASdKX8QS 1zcVKCaoE5Xrxt9zq213UpXE87PY2A== =4JaN -----END PGP SIGNATURE----- --YCGSkTKVt49j0xAo-- From xen-devel-bounces@lists.xenproject.org Fri Jun 05 12:26:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 12:26:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBPz-0004Yt-3L; Fri, 05 Jun 2020 12:25:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBPy-0004Yo-JE for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 12:25:50 +0000 X-Inumbo-ID: b040c8f4-a727-11ea-ba62-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b040c8f4-a727-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 12:25:49 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id l12so6127542ejn.10 for ; Fri, 05 Jun 2020 05:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=f2LAqKOptg+KacV4p0Xdmg+M+FNYWQVRRgYfWTzbnYo=; b=a/K45qyX1YAgqK+s6WPHbjFUStj52TCRaQGYmmpe8qzIwG17BbY9mEG/o+EtV4WLzF diQ8LzQ9xJnMfz6ZazRLmWZC4DwkviIOwMnmSR5+11hRVc7D3AzA8ETtbMRm36HRgqW0 /CsOfk0BzqAhgQOHStCqRlpUWYam6NZhBP1JWHOy0hEqbyteWeM5xmkw6fDbnMkH0OtC RDLoyfT31gl/87V2wfUuqP90Tl7O77v+Trkq+9db3ww7ECtC3PNFBhKQQdbA5yVB6LdJ 7Qg4zU+8SahrmDVwwQLDz66uQMjYtr/9Hjw/M6/ouQFB9ri1OcQIXcQ9j7UJIwKM7V8E TSrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=f2LAqKOptg+KacV4p0Xdmg+M+FNYWQVRRgYfWTzbnYo=; b=bl2iX9mfG8IkcnOF3rijpZA2je91Tt7SXJoLh+ADfNnLrI/iQ3OeD1xF99oOlTlmS2 ER50+tkulTj36/aARiPFTRYsNei1nbzn09sUknTGOaWBX0d3S2w7m4xge3mvjlL39QYi a8DjBLL1Zq2xxXbBHppi7tTlwfkl5z9x9KOibIOXx86KPaCr4+aanVhRvxBD8xbL9BCi EFqYpJ5gns0xFqq7a7CAWF2eN2hrrtxr1CnEnsAH67tr43pS9ZHYkzYfkxr4yzFWdLy/ gDNT7lrBu173nxRWEeLwVV8Ey5t8hw8tQMAZtWu2++hsb2fQp+xKRt002NVwGCfbGEPS +KFA== X-Gm-Message-State: AOAM530fWNEj5pleGNKyxGexQ6hBLRVCJyX73Csbo7mDKCjmR0gyEyIA 3XIRtl3SiQVMc1M6enVGkkA48mI7Mlr04XPJey4= X-Google-Smtp-Source: ABdhPJwCFXVCpyYlwn2irhMpkBJs3xwaIS9By65SJehmMSk5qRUy7/8C2YmCTWhM8tnCAcOqXlb+LdIykqLTLv1tBGE= X-Received: by 2002:a17:906:11d9:: with SMTP id o25mr8182151eja.377.1591359948627; Fri, 05 Jun 2020 05:25:48 -0700 (PDT) MIME-Version: 1.0 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> In-Reply-To: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> From: CodeWiz2280 Date: Fri, 5 Jun 2020 08:25:34 -0400 Message-ID: Subject: Re: Keystone Issue To: Bertrand Marquis Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 5, 2020 at 3:37 AM Bertrand Marquis wrote: > > Hi, > > > On 5 Jun 2020, at 03:29, CodeWiz2280 wrote: > > > > On Thu, Jun 4, 2020 at 2:24 PM Julien Grall wrote: > >> > >> Hi, > >> > >> On 04/06/2020 13:07, CodeWiz2280 wrote: > >>> On Thu, Jun 4, 2020 at 6:16 AM Julien Grall wrote: > >>>> > >>>> Hi, > >>>> > >>>> On 04/06/2020 10:08, Bertrand Marquis wrote: > >>>>> I would have thought that linux would have need some memory, even s= mall in the 32bit space in order to boot. > >>>> > >>>> Yes it needs some, but then they are switching to use the high memor= y > >>>> alias after the MMU has been switch on. > >>>> > >>>> From my understanding, the only difference is the page-tables will > >>>> point to the high memory alias address rather than the low memory on= e. > >>>> Linux will still be located at the same place but now accessed from = the > >>>> high memory alias rather than the low one. > >>>> > >>>> Note that AFAICT the secondary CPUs will still be brought-up using t= he > >>>> low memory alias. > >>>> > >>>>> I could understand that some memory in the low address space needs = to be reserved by Linux as DMA area for peripherals not supporting 36-bit a= ddresses, but the whole low memory sounds like a big restriction. > >>>> Many platforms have devices only supporting 32-bit DMA, but none of = them > >>>> require such aliasing. So this doesn't look to be the issue here. > >>>> > >>>> TBH, this code is only used by Keystone and switching address space = is > >>>> expensive (you have to turn off the MMU, updates page-tables, flush = the > >>>> cache...). I find hard to believe a developper would have come up wi= th > >>>> this complexity if it were possible to always use the low memory add= ress > >>>> range. It is even harder to believe Linux community would have accep= ted it. > >>>> > >>>>> > >>>>> Would it be possible to have a bit more information on the =E2=80= =9Cproblem with peripherals=E2=80=9D here ? > >>>> > >>>> I am curious as well, so I looked in more depth :). Going through th= e > >>>> Linux history, one of the commit message [1] suggests they are switc= hing > >>>> to a coherent address space. The datasheet [2] (page 75) also confir= m > >>>> that the low region is not IO coherent. > >>>> > >>>> So I think you would not be able to do DMA without flush the cache w= hich > >>>> can be pretty expensive. For a PoC, it might be possible to force Li= nux > >>>> flushing the area before and after each DMA request. This should be > >>>> possible by marking the devices as not coherent. > >>>> > >>>> Although, I am not entirely sure if there is any fallout. > >>>> > >>>> @Dave, do you think it is possible for you to have a try? I can prov= ide > >>>> the patch for Linux to disable DMA coherency if possible. > >>> I attempted to do that, where I removed the "dma-coherent" flags from > >>> the device tree. There are likely other issues, but the most glaring > >>> problem that I ran into is that the ethernet does not work. Eth0 > >>> shows up in ifconfig but there is no activity on it after a small > >>> handful of message exchanges, whereas booting without Xen it seems to > >>> work fine even if left in 32-bit mode (with the dma-coherent > >>> disabled). I don't know what implications behind the scenes there ar= e > >>> trying to stay in the lower 0x8000_0000 alias range either though. > >> > >> Thank you for the answer. As wrote, Linux is working fine in 32-bit mo= de > >> when dma-coherent is left in 32-bit mode. So this suggest a different > >> issue on the platform. > >> > >> Given that you receive an handful of packet and then nothing, this wou= ld > >> lead to maybe an interrupt problem. Can you check whether the number o= f > >> interrupts increments the same way on baremetal and on Xen? > >> > >> Dumping /proc/interrupts should be sufficient. > >> > > I am able to ping the board from itself, do you think it could still > > be an interrupt issue? It just cannot seem to ping out to a different > > host (or ping from > > my pc). Unfortunately, the interrupts for the netcp Ethernet driver > > on this board don't show up in the cat /proc/interrupts output under > > the non-Xen kernel or > > Xen loaded kernel from what I can tell. I'm not sure how I would confi= rm that. > > Could you check the content of /proc/interrupts ? > > I did raise an issue several years ago on the keystone 2 related to inter= rupts and virtualization (no with Xen but the context should still be right= ): > https://e2e.ti.com/support/processors/f/791/t/462126?Keystone-2-no-interr= upts-received-out-of-80-and-92- > > There might be something to check in regards to level vs front interrupts= for forwarded interrupts. > The Keystone uses the netcp driver, which has interrupts from 40-79 listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). I'm using the same device tree between my non-xen standalone kernel and my dom0 kernel booted by xen. In the standalone (non-xen) kernel the ethernet works fine, but I don't see any of its interrupts in the output of /proc/iomem. I'm not seeing them in /proc/iomem when running dom0 under Xen either. When booting with Xen I get this behavior where the ifconfig output shows 1 RX message and 1 TX message, and then nothing else. > Regards > Bertrand > > > > > > >>> I > >>> would rather run it as intended by switching to the upper > >>> 0x8_0000_0000 alias region. > >> > >> I agree this would be ideal :). > >> > >> Cheers, > >> > >> -- > >> Julien Grall > From xen-devel-bounces@lists.xenproject.org Fri Jun 05 12:30:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 12:30:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBU9-0005M8-L4; Fri, 05 Jun 2020 12:30:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBU8-0005LI-Nq for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 12:30:08 +0000 X-Inumbo-ID: 4a879cc6-a728-11ea-afad-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4a879cc6-a728-11ea-afad-12813bfff9fa; Fri, 05 Jun 2020 12:30:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0JQ0JgUkd4aa0wYgbrQpBpjuIBYOmxVvjimtwAdDBx8=; b=oolBT7qrGJRr3LYa52ACtASyn9 sddyWdGl052N1nktcFyjfM9Vy83LXJxEVeQ4pVVpzfoRtRTQxSkWX1rxwtCuYrCEklu5txgbLRB5G xpU72nibw1RuFOi5N4WtjpPralDCIjJ7nNOlJ6gkNJet3ovZTi8jRn4mbAYVhmLdbK9Y=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBU7-0004Zc-MW; Fri, 05 Jun 2020 12:30:07 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jhBU7-0001Q5-G6; Fri, 05 Jun 2020 12:30:07 +0000 Subject: Re: Keystone Issue To: CodeWiz2280 , Bertrand Marquis References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> From: Julien Grall Message-ID: <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> Date: Fri, 5 Jun 2020 13:30:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 05/06/2020 13:25, CodeWiz2280 wrote: > The Keystone uses the netcp driver, which has interrupts from 40-79 > listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). > I'm using the same device tree between my non-xen standalone kernel > and my dom0 kernel booted by xen. In the standalone (non-xen) kernel > the ethernet works fine, but I don't see any of its interrupts in the > output of /proc/iomem. I'm not seeing them in /proc/iomem when > running dom0 under Xen either. When booting with Xen I get this > behavior where the ifconfig output shows 1 RX message and 1 TX > message, and then nothing else. I am not sure whether this is a typo in the e-mail. /proc/iomem is listing the list of the MMIO regions. You want to use /proc/interrupts. Can you confirm which path you are dumping? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 05 12:39:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 12:39:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBdI-0005i6-JV; Fri, 05 Jun 2020 12:39:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBdH-0005i1-4g for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 12:39:35 +0000 X-Inumbo-ID: 9b956dea-a729-11ea-96fb-bc764e2007e4 Received: from mail-ej1-x631.google.com (unknown [2a00:1450:4864:20::631]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9b956dea-a729-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 12:39:34 +0000 (UTC) Received: by mail-ej1-x631.google.com with SMTP id x1so9912624ejd.8 for ; Fri, 05 Jun 2020 05:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=y7ZbTDjEZID7JxufTackG+ISWZQimmY0w3U+s6CBkyE=; b=EWfydwxVB/wul9AW4p/QELCnc2/P3WDDLQuUvMu7AfbRwLgSoxluX5UIKcnf4Y0PZ9 ETEc1lJqnB3oNZBBlbBW+QB9+FN9oAdyaDk7q2yUgszcn6K8IX3g6zJ+7ld6Ar5qc4uv 7kFKuKNelRcONh0XExIwWC+l9xZdaTbVBopJ9KrmhmkwOegJG27OliSiCeEfuNQctdnl 5vZ2g8/6J4J6Mq9YDOWQs803UzqrKb+TInyqmF55XGF4UfN2x0HjbzGoGgMjsTN6wQu5 QeU68hUSipAzB7qqD3+W29euCcXbbXXUJiyO/3F5n0dsq8vbak97h+j6VGkAWEC40oZo KBdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=y7ZbTDjEZID7JxufTackG+ISWZQimmY0w3U+s6CBkyE=; b=Lb1DpF7U+B39H69yUR+113f/03+1oj+qHkS7u2kCwEEObjjPaxGgBSgZr/jfbmB7eZ 7v0PR/jM2ot68QMkAgEqcqclnIxk3g6Oa0HTDUJTAmkpIeKR1yoTCZq597xEfCmG7PPY K0vAzhKmNtObvUGRUY1duuW+JLMWx+PRth+iqwBWXPvXVxMi/gwSmwohxgy4pxv81kfF XHqku155I0Bao9bm0kV0oxGPhcjZ5DjomoMT3w9T9FfkyS/5UCmW5wlt6BQKsKypHLoe iOh+/vw1tsKGGEE9oXVZLjM29AUqxjhOsxhBM5WYKID1l6LenYw0E81RDhtg1rewaSba 3poA== X-Gm-Message-State: AOAM5325QJgWFEYYLHLzSQ5fIjwtwcHMSiISGKy0XSMnfXoKocmYD+B/ S0oYPLQWhYjWcz7z1wTrq4Q= X-Google-Smtp-Source: ABdhPJyTBVepzEaY8my0WQ673//qu/a4aJneftnfwoNtAPln1tJetBBmH4zhrMK8FCL31hifokXQtQ== X-Received: by 2002:a17:907:9486:: with SMTP id dm6mr8860641ejc.248.1591360773031; Fri, 05 Jun 2020 05:39:33 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id f13sm4741774edk.36.2020.06.05.05.39.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 05:39:32 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= , "'Jan Beulich'" References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <20200605120137.GF98582@mail-itl> In-Reply-To: <20200605120137.GF98582@mail-itl> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 13:39:31 +0100 Message-ID: <000a01d63b36$5ca617b0$15f24710$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoACJ30jDAXuEodcCsFgQ5AHivRJwAUZxxQABFk5KigGiA5kJqNtVkMA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Marek Marczykowski-G=C3=B3recki = > Sent: 05 June 2020 13:02 > To: Jan Beulich > Cc: Andrew Cooper ; Paul Durrant = ; xen-devel devel@lists.xenproject.org> > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On Fri, Jun 05, 2020 at 11:22:46AM +0200, Jan Beulich wrote: > > On 05.06.2020 11:09, Jan Beulich wrote: > > > On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > > >> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > > >> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > > >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > > >> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > > >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > > >> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > > >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > >> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > > >> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > > >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > >> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > > >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > > >> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags = 0x2 d6 > > >> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags = 0x2 d6 > > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > > > > Perhaps in this message could you also log > > > v->domain->is_shutting_down, v->defer_shutdown, and > > > v->paused_for_shutdown? > > > > And v->domain->is_shut_down please. >=20 > Here it is: >=20 > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > (XEN) grant_table.c:3702:d0v1 Grant release 0x3 ref 0x125 flags 0x2 d6 > (XEN) grant_table.c:3702:d0v1 Grant release 0x4 ref 0x126 flags 0x2 d6 > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 1 = defer_shutdown 1 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d1v0 Unexpected PIO status 1, port 0xb004 read 0xffff >=20 > (and then the stacktrace saying it's from vmexit handler) >=20 > Regarding BUG/WARN - do you think I could get any more info then? I > really don't mind crashing that system, it's a virtual machine > currently used only for debugging this issue. In your logging, is that handle_pio with is_shutting_down =3D=3D 1 the = very last one, or is the 'Unexpected PIO' coming from another one issued = afterwards? The reason I ask is that hvmemul_do_io() can call hvm_send_ioreq() to = start an I/O when is_shutting_down is set, but will write the local = io_req.state back to NONE even when X86EMUL_RETRY is returned. Thus = another call to handle_pio() will try to start a new I/O but will fail = with X86EMUL_UNHANDLEABLE in hvm_send_ioreq() because the ioreq state in = the shared page will not be NONE. Paul >=20 > -- > Best Regards, > Marek Marczykowski-G=C3=B3recki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? From xen-devel-bounces@lists.xenproject.org Fri Jun 05 12:42:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 12:42:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBg6-0006cx-6Q; Fri, 05 Jun 2020 12:42:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBg4-0006cs-Qb for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 12:42:28 +0000 X-Inumbo-ID: 038a3f2a-a72a-11ea-96fb-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 038a3f2a-a72a-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 12:42:28 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id x1so9922150ejd.8 for ; Fri, 05 Jun 2020 05:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7gDE5ftp8pEVvtW1JgGQS31oKVudle1B73F3+TfRCJU=; b=tzoKny5QrTn9O8a5QtdURekaFnSepbgiaSdd/YNn7oa1M9FtL7/JzOU+21tPoy9BN9 sjGMjQ3sx4tfMdacDawQhJH/LlZ3UJS9Q9RwVzGxWWdtE7MFeDAIuPOLM8LUd1zjSGeA PqE8sMkLzyV5M7p1ymvHFInL/CCHKgP358772GPM3ad9m8dw1DypxeBAH7ceZ4/q4C5X Ai3oF1iap86M+nqUi0Q8zheJ/De3e0N1nD2RFw5vvMiuj4EOCbWgLFQu68+JCRfrDZRE JKMJH7wff92gV237F0TPYXK24WMmGkWI5z0Ai+4cx/ao7Mo7+zP/OhaxwLhsPbKIj6/A 8EJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7gDE5ftp8pEVvtW1JgGQS31oKVudle1B73F3+TfRCJU=; b=kd9QDzua2/5CPAJ/AMyVozXwoxlzOE6Hb/3ZOBu9PI3TxC/1pXce/tESgl0ySByv7J qqy47UfxRhug/b7OPVcxjpyPssktpKBWOJSpHhDfIrBtqZQAopPB0fhY259o70JbyDKm zaI/ZiXtsf92VSq0jfqwnk3JXzvacqrb4XtJIsEstVFEhRY2yBXSG94MWcWYU2FVzEXI M/6fCmzJ3EYj4fSmJ5qZd78Y5b+hmyv3BRoUgnUCcVp718dFRgbiS6jewC97uaGSuW/K Tp2E8FPy8YrQMdTXeagAE3eKns+HAXQHwp9TgpR7S8RldU+aCAZ/Pr0fivLct3vTqAYS N51w== X-Gm-Message-State: AOAM533pO53dqOMUY/LjXFKhSyV6mvVYig3mYAVETKk+r/vXyB2kLh4c K41qHiE42nnwggI1l0Cq/fyn8QWUQMzMXrkYs1iDMPEI X-Google-Smtp-Source: ABdhPJwgoXdzC3T3k2GsSNP9FxvFRmlpJM/O49j2fgGcdtv8C3Ttz+W/5pQj3HiKXRyOj3pyxgkCD+dKsr675ap0ffU= X-Received: by 2002:a17:906:5f93:: with SMTP id a19mr8386660eju.10.1591360947505; Fri, 05 Jun 2020 05:42:27 -0700 (PDT) MIME-Version: 1.0 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> In-Reply-To: <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> From: CodeWiz2280 Date: Fri, 5 Jun 2020 08:42:14 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 5, 2020 at 8:30 AM Julien Grall wrote: > > Hi, > > On 05/06/2020 13:25, CodeWiz2280 wrote: > > The Keystone uses the netcp driver, which has interrupts from 40-79 > > listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). > > I'm using the same device tree between my non-xen standalone kernel > > and my dom0 kernel booted by xen. In the standalone (non-xen) kernel > > the ethernet works fine, but I don't see any of its interrupts in the > > output of /proc/iomem. I'm not seeing them in /proc/iomem when > > running dom0 under Xen either. When booting with Xen I get this > > behavior where the ifconfig output shows 1 RX message and 1 TX > > message, and then nothing else. > > I am not sure whether this is a typo in the e-mail. /proc/iomem is > listing the list of the MMIO regions. You want to use /proc/interrupts. > > Can you confirm which path you are dumping? Yes, that was a typo. Sorry about that. I meant that I am dumping /proc/interrupts and do not see them under the non-xen kernel or xen booted dom0. > > Cheers, > > -- > Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 05 12:45:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 12:45:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBir-0006lx-LC; Fri, 05 Jun 2020 12:45:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBiq-0006ls-E4 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 12:45:20 +0000 X-Inumbo-ID: 698161dc-a72a-11ea-afad-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 698161dc-a72a-11ea-afad-12813bfff9fa; Fri, 05 Jun 2020 12:45:19 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: vel0pPoaFd46hVvlqul1HNTdMuk/V3VM5eqeEQvXyDhgCvi0slzrDpYVB26bgQgoO/pmEx82s6 5YqooUMzknCsIGYjQIXvP3UFRUuuFHq7DrjM3qIH8nwr4vkEMaInR1cjESpbOFIqtMB20QRJ2Q QvHuN7qrE/ty/0Blvq03c5xC7w6tzEIRXNXGU16uPOQEDxbRt/AADVeDh0GkTkEcijTe5vGRCe GjdjVo5en4ssYxQSg1rOfkl2ZvOhmpVpj0CJAg/ppAki3xz3dLAkqu5gFBxlfwGScVhLPqYMMn L+U= X-SBRS: 2.7 X-MesageID: 19320157 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="asc'?scan'208";a="19320157" Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= , Jan Beulich References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <20200605120137.GF98582@mail-itl> From: Andrew Cooper Message-ID: <38121217-988a-40e1-f220-4643652a8609@citrix.com> Date: Fri, 5 Jun 2020 13:44:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200605120137.GF98582@mail-itl> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zLORsC50kkiBCzUXwngisULTRAa30TRIs" X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --zLORsC50kkiBCzUXwngisULTRAa30TRIs Content-Type: multipart/mixed; boundary="wCLS4FvVOeyXnND98kb7g2fVrTH67g8jK" --wCLS4FvVOeyXnND98kb7g2fVrTH67g8jK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB On 05/06/2020 13:01, Marek Marczykowski-G=C3=B3recki wrote: > On Fri, Jun 05, 2020 at 11:22:46AM +0200, Jan Beulich wrote: >> On 05.06.2020 11:09, Jan Beulich wrote: >>> On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: >>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 >>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 >>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 >>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done >>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. >>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 >>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 >>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 >>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done >>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 = d6 >>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 = d6 >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>> Perhaps in this message could you also log >>> v->domain->is_shutting_down, v->defer_shutdown, and >>> v->paused_for_shutdown? >> And v->domain->is_shut_down please. > Here it is: > > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_= shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_= shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer= _shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer= _shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_= shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_= shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer= _shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer= _shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > (XEN) grant_table.c:3702:d0v1 Grant release 0x3 ref 0x125 flags 0x2 d6 > (XEN) grant_table.c:3702:d0v1 Grant release 0x4 ref 0x126 flags 0x2 d6 > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 1 defer_= shutdown 1 paused_for_shutdown 0 is_shut_down 0 > (XEN) d1v0 Unexpected PIO status 1, port 0xb004 read 0xffff > > (and then the stacktrace saying it's from vmexit handler) > > Regarding BUG/WARN - do you think I could get any more info then? I > really don't mind crashing that system, it's a virtual machine > currently used only for debugging this issue. I specifically recommended BUG() so it crashed cleanly and didn't loop infinitely spewing into the logs. =46rom the analysis so far, whatever is going wrong is going wrong betwee= n XEN_DMOP_remote_shutdown and the first bad PIO, so I don't think letting the system loop further is going to be helpful. ~Andrew --wCLS4FvVOeyXnND98kb7g2fVrTH67g8jK-- --zLORsC50kkiBCzUXwngisULTRAa30TRIs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEzzVJW36m9w6nfSF2ZcP5BqXXn6AFAl7aPlYACgkQZcP5BqXX n6A7ABAAn9bkSaPLulmkahc0e0aEcANlpPYjLbqDEjj1ij8TEldfjfCmvVDrzFDo j86sMPl39wSUD7rwdKOZo3g/ZCnFwXTBDIfQmjPWIXfJW8U2n32/wHr0xsE8SRXn 5hCCmjR5LOJY1Yr//hGScEy4hCGgbBlSe+eODVzTJZJKsVe3jcgmufofqoXDO8As JpNwdq2npA3Y2eUvzQpKpUBfSkEci7ckVFjQojunM1FzB65ZUo5X2f4chPDCxM81 VZEaECCX4EtG9gPWElyQ0fkkJ9ySuSbFt4FcfWIxBvrYolc83bL7o1m/FXtehR95 XEj45jdIM0YQb5eWFKrfEpC1MImzItG7+7WSFmQUSTwfgf0FhslP0GXjttzh9Xwm 2ytEKDhzt/E38iwXpachegyKD/9oB9okF8zHpGopoSkiMqgaskyX4jGvN0KNrMBE 8tVQiQpRDGKFHQgauvy+bOvriUkXxOeiprShBexcfvQZleF6rb9hWvrpySUvu9vC ZVedoitMS0wUnVJKd+918zJE352Xf83fWbab9olGmfRPmLB7eYVno/3ggHuwnuDs ctp87H1rb0s1gPnuCJ5FmeIypihPooDbbPwHofIxNL41xZj+5Idshse/jNTMRO7w pOU3/Gs7C4yqOzHUi+T6kqGlroyh2loHGd3jMiqd4O2wKAvRr4U= =pxyN -----END PGP SIGNATURE----- --zLORsC50kkiBCzUXwngisULTRAa30TRIs-- From xen-devel-bounces@lists.xenproject.org Fri Jun 05 12:48:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 12:48:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBlP-0006uA-4z; Fri, 05 Jun 2020 12:47:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhBlN-0006u5-LN for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 12:47:57 +0000 X-Inumbo-ID: c7304f6e-a72a-11ea-ba62-bc764e2007e4 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:7e1a::605]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c7304f6e-a72a-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 12:47:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mteM1wNltbXTw5kY/XIrXv2xFQSiYbFD/2Hznhk6rPY=; b=eStDKL9+9e0UVGIuGZiIfkuyk4fqTngiISf/FULrW0+fvy/erukWZWO2b9KIGtFVXNbObser6bYn7izTJFKccBpQHiKrZadGRXyZHov4mNUT69FwQY8dWGBtLP+3LgqisVHp1uSTmXVQkAjnrrPWxeCQvl+VPwCjeuMHNDwZK3I= Received: from DB6PR0601CA0016.eurprd06.prod.outlook.com (2603:10a6:4:7b::26) by VI1PR08MB3677.eurprd08.prod.outlook.com (2603:10a6:803:7f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 5 Jun 2020 12:47:54 +0000 Received: from DB5EUR03FT025.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:7b:cafe::6c) by DB6PR0601CA0016.outlook.office365.com (2603:10a6:4:7b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Fri, 5 Jun 2020 12:47:54 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT025.mail.protection.outlook.com (10.152.20.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Fri, 5 Jun 2020 12:47:53 +0000 Received: ("Tessian outbound 3e82c366635e:v59"); Fri, 05 Jun 2020 12:47:53 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 51fbe6779753dcb4 X-CR-MTA-TID: 64aa7808 Received: from 0fa81f2ceb15.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B6F749F8-E2BB-4989-BA02-08061816C785.1; Fri, 05 Jun 2020 12:47:48 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 0fa81f2ceb15.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 05 Jun 2020 12:47:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MSmk2dKhLsCYElS9Bn4uLEwRd9u8iNz4xCtpODzblBe19kWWSRcQYeePNoP9nuApKreHtwZSoJZMAnSa5eurkTboADCFNeOl+PYnVv0aaCPm0Oiqljeh6+bgcJWX8ghZMUrsJwdOw39MGEpRHSrb1wF3F6zPWdqcWTdqmfSL+2wRWW6v/NsoiOYwf9TR3JGJzsiBdVYoZJ0HN+0dvkAFTTh/T7Rh6qQRTX6QuGBBqnXH7i+5NJLc8/xrPFzPFJ/V/Yl2opAWIbwmJ73+oRZZrv34Cx2s0kWqPBvNjg9Nf2Gd5KCoBVYq+6CPeA5OzXDXNKjvNg3mAozF99opIykUAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mteM1wNltbXTw5kY/XIrXv2xFQSiYbFD/2Hznhk6rPY=; b=EsJWRhVKAcyCqM5dygUQTFD1sQM354LTmi5kigDrMn39v58f5hcFyTY7kzV8SfeBwlTeFgtDUDXo+xn8qcyhTFazDoVS0ejLp27iOVSfSfbCvayJXMgqC/tZGnaDWHabnmuSU3+Sj/jhaGXhAokPnRdD2g9x92LTetPz8Jl74NLhts7AOg4V/G6yGm0zvqoMUYf90ft9Aza/VKDiMcokwxAtSu6u0pWs9ohWWEineClNvBd/0/pVnSu0+NB9H9Lhm/75MpZOspMLr0AENNBc5xonOqj26czoiSQnGtntmKs68q7BzLiCSUtF9H5hwkZT4JH5oGNcTNrhesXkXZmzlQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mteM1wNltbXTw5kY/XIrXv2xFQSiYbFD/2Hznhk6rPY=; b=eStDKL9+9e0UVGIuGZiIfkuyk4fqTngiISf/FULrW0+fvy/erukWZWO2b9KIGtFVXNbObser6bYn7izTJFKccBpQHiKrZadGRXyZHov4mNUT69FwQY8dWGBtLP+3LgqisVHp1uSTmXVQkAjnrrPWxeCQvl+VPwCjeuMHNDwZK3I= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3868.eurprd08.prod.outlook.com (2603:10a6:10:32::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Fri, 5 Jun 2020 12:47:46 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3066.019; Fri, 5 Jun 2020 12:47:46 +0000 From: Bertrand Marquis To: CodeWiz2280 Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgA== Date: Fri, 5 Jun 2020 12:47:46 +0000 Message-ID: <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: c1e1e56e-fd8f-486e-0aed-08d8094eaa28 x-ms-traffictypediagnostic: DB7PR08MB3868:|VI1PR08MB3677: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:3513;OLM:3513; x-forefront-prvs: 0425A67DEF X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: CEA0K4L8rLGpgex7wKHPW1A8zdY/8RBOf9NoAHL3akQ5DujtK9AuAYZA9Rp+aVMe3OwIKmPz0nHmxLviEgo7mo05dKBFBA9nszjeR4R0ZsUL/L0taW7pPfJai8S5n96Thzt5OgHaesXX7YZQrcI1yFeIlNIK9knXcO9fgnzPv5peJduyXllI0vg33r4x9fhMfBh9qUGpdKA/hJ/TPOME9ngMxqZirQRbwFQ3/xQzSxU2EfxlIPqYBlzcikXD2Q2novG3xBksLPmCVLz11VCzRDGdSVvRmga1WAWICLKi9KBLPH1u9mDYSvCw8LQpM2NYKRMgNUVxSLKJw3QhgjIaNA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(54906003)(6486002)(71200400001)(5660300002)(2906002)(2616005)(3480700007)(316002)(36756003)(86362001)(6916009)(33656002)(66946007)(26005)(83380400001)(66476007)(4326008)(66556008)(186003)(76116006)(66446008)(64756008)(8676002)(8936002)(91956017)(7116003)(53546011)(6506007)(6512007)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HsTh1RVkVD4WD7/2XVo4sj2WpF98m60yOqK937Min+Tt598yhrnrjmJUTuzXi8+r+1iAo9/ITGUd5oU9g7DLJDji2XttJESQqufvmfKDtVxVT0xsHKUQ596RtF7GBZuD5ndlXhtkQUfu2WlS6Asrsn6CTEMqmcrIhmezx3RHE35M6venlaHJ9DqWpITPlkgqDk7wm2AoV3XGHPYbb7Ksega/fo9+QGAdo5aftFI8d8EPJDiEf0NA7iR94Lun9GTDYTDA81R2LcFptKJxO40ZeUa9cFv/f9fDD2Ym9I6/VUtuteeHymNcCsOjJfQju55tX4YyjCoAcxV/YwxmVzaFK0opnjWJrTB5xbH5SZXuL9E6UvH8ljHx5/NDnsZ26L68FfuVJDdD761O1j9FBjTKEYLZltvQk4CJ69xXF5Zl9IuVErZpoE4bFHUDHHNsT2WhYtMkGNjJjnOvdoXmilhoDMjhSRBNDXEDSt5kaeyadRl/UU/dUmn25v90s/JH1UBD x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3868 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT025.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(136003)(396003)(46966005)(70206006)(186003)(2906002)(81166007)(82740400003)(6512007)(36756003)(316002)(53546011)(6486002)(47076004)(336012)(356005)(86362001)(5660300002)(33656002)(6506007)(82310400002)(478600001)(54906003)(8936002)(70586007)(8676002)(6862004)(26005)(3480700007)(4326008)(2616005)(83380400001)(7116003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 39f7cb6f-8904-4bc2-beff-08d8094ea5bd X-Forefront-PRVS: 0425A67DEF X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UrR5iBxtppLF/tYBRRzdK8dXmcXGNnkqmi/+HnInPsUx+yi7MiahM2H+v1/V7Y44vZfckUiMqeJIlF2uYj5YKcVmbL3i3Tl7Ysh2EkhRO/LmSbgPmUgmwXHz0rvmOqldAfZ01PixPX5rRG/bamsr5qV1gBKPd8VwPKTAB4jA4nRd7x1HvYzjGcQpaM/eBJ290QNcJiiYKPHKvbg+USSsvYZFytgmI75G4RdlSmBlaw1wedwFOx6hygwyj8u1hBVVsboPBXZE4D0ZxySjaOnFuV7h3egvn57e19FZHH/aTwBQfAzk6vAzXlhxbtRWgHe+tfIecUgX51uvMZYms+ev92OSY4VSId53II/jzFxvXtdM182soT8kVo8UprqGBio1e1bhkkRZpvF8JMhNJV8Qxw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jun 2020 12:47:53.9705 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c1e1e56e-fd8f-486e-0aed-08d8094eaa28 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3677 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On 5 Jun 2020, at 13:42, CodeWiz2280 wrote: >=20 > On Fri, Jun 5, 2020 at 8:30 AM Julien Grall wrote: >>=20 >> Hi, >>=20 >> On 05/06/2020 13:25, CodeWiz2280 wrote: >>> The Keystone uses the netcp driver, which has interrupts from 40-79 >>> listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). >>> I'm using the same device tree between my non-xen standalone kernel >>> and my dom0 kernel booted by xen. In the standalone (non-xen) kernel >>> the ethernet works fine, but I don't see any of its interrupts in the >>> output of /proc/iomem. I'm not seeing them in /proc/iomem when >>> running dom0 under Xen either. When booting with Xen I get this >>> behavior where the ifconfig output shows 1 RX message and 1 TX >>> message, and then nothing else. >>=20 >> I am not sure whether this is a typo in the e-mail. /proc/iomem is >> listing the list of the MMIO regions. You want to use /proc/interrupts. >>=20 >> Can you confirm which path you are dumping? > Yes, that was a typo. Sorry about that. I meant that I am dumping > /proc/interrupts and do not > see them under the non-xen kernel or xen booted dom0. Could you post both /proc/interrupts content ? Cheers Bertrand From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:04:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:04:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhC1A-0000Ns-LW; Fri, 05 Jun 2020 13:04:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhC18-0000Nn-Qr for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:04:15 +0000 X-Inumbo-ID: 0dcbd3b0-a72d-11ea-9b55-bc764e2007e4 Received: from wout4-smtp.messagingengine.com (unknown [64.147.123.20]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0dcbd3b0-a72d-11ea-9b55-bc764e2007e4; Fri, 05 Jun 2020 13:04:13 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C075959D; Fri, 5 Jun 2020 09:04:12 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 05 Jun 2020 09:04:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=gsMNM6 L0WQQkqWnkTPeSQhmnMIonhYIndfng/RGnFmc=; b=HI1czHP/JDX0YSS0n8cqj8 XaqBHO1ZupDP7SvNA7nNGCe9dMgEkQaYMOwJgnOPrE82CJtMRiqehYY3MDwDXelH HzjmxyPKYaVB2ljVRj7LH45NI/fR3578yUWTu9UT8n1wcLUq9CjU/iWGapw3BAC2 1HAbTpoFF420AmHWCJ9WE5hQJFsNOdcLB8c42bODyg+tC3g/e1AEu3DIh15xImnh mSHaLSR39ASXw6ck2r36v+8xP+xdFPMd01ROznYp9vBBcZaJ+8euMfkSotW70CQ8 0y60r+zGp/qmvtgGnl3aH79RZmxG+VEFSn19dhPg6eJwCZrEVFpwNZ4ehyBB4XXQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpedkofgrrhgv khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhikdcuoehmrghrmhgrrhgvkhesih hnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeff gfdugeegtdeggeetheefveffteeigeekjedtueelhedtvdeuffejkeelhfekheenucffoh hmrghinhepghhithhhuhgsrdgtohhmnecukfhppeeluddrieehrdefgedrfeefnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvg hksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D8B63280059; Fri, 5 Jun 2020 09:04:11 -0400 (EDT) Date: Fri, 5 Jun 2020 15:04:08 +0200 From: 'Marek =?utf-8?Q?Marczykowski-G=C3=B3recki'?= To: paul@xen.org Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Message-ID: <20200605130408.GI98582@mail-itl> References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <20200605120137.GF98582@mail-itl> <000a01d63b36$5ca617b0$15f24710$@xen.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PqX6tBBuHl4HmZHK" Content-Disposition: inline In-Reply-To: <000a01d63b36$5ca617b0$15f24710$@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , 'Jan Beulich' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --PqX6tBBuHl4HmZHK Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom On Fri, Jun 05, 2020 at 01:39:31PM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Marek Marczykowski-G=C3=B3recki > > Sent: 05 June 2020 13:02 > > To: Jan Beulich > > Cc: Andrew Cooper ; Paul Durrant ; xen-devel > devel@lists.xenproject.org> > > Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0= in stubdom > >=20 > > On Fri, Jun 05, 2020 at 11:22:46AM +0200, Jan Beulich wrote: > > > On 05.06.2020 11:09, Jan Beulich wrote: > > > > On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > > > >> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > >> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > > > >> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > > > >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > > > >> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > > > >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > > > >> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > > > >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > > >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > > >> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > > > >> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > > > >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > > >> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > > > >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > > > >> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x= 2 d6 > > > >> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x= 2 d6 > > > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > > > > > > Perhaps in this message could you also log > > > > v->domain->is_shutting_down, v->defer_shutdown, and > > > > v->paused_for_shutdown? > > > > > > And v->domain->is_shut_down please. > >=20 > > Here it is: > >=20 > > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_= shutdown 0 paused_for_shutdown > > 0 is_shut_down 0 > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_= shutdown 0 paused_for_shutdown > > 0 is_shut_down 0 > > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer= _shutdown 0 paused_for_shutdown > > 0 is_shut_down 0 > > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer= _shutdown 0 paused_for_shutdown > > 0 is_shut_down 0 > > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > > (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_= shutdown 0 paused_for_shutdown > > 0 is_shut_down 0 > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_= shutdown 0 paused_for_shutdown > > 0 is_shut_down 0 > > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer= _shutdown 0 paused_for_shutdown > > 0 is_shut_down 0 > > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer= _shutdown 0 paused_for_shutdown > > 0 is_shut_down 0 > > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > > (XEN) grant_table.c:3702:d0v1 Grant release 0x3 ref 0x125 flags 0x2 d6 > > (XEN) grant_table.c:3702:d0v1 Grant release 0x4 ref 0x126 flags 0x2 d6 > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 1 defer_= shutdown 1 paused_for_shutdown > > 0 is_shut_down 0 > > (XEN) d1v0 Unexpected PIO status 1, port 0xb004 read 0xffff > >=20 > > (and then the stacktrace saying it's from vmexit handler) > >=20 > > Regarding BUG/WARN - do you think I could get any more info then? I > > really don't mind crashing that system, it's a virtual machine > > currently used only for debugging this issue. >=20 > In your logging, is that handle_pio with is_shutting_down =3D=3D 1 the ve= ry last one, or is the 'Unexpected PIO' coming from another one issued afte= rwards? That's the same function call - handle_pio message is before hvmemul_do_pio= _buffer() and Unexpected PIO is after. Here is the current debugging patch: https://gist.github.com/marmarek/da37d= a3722179057a6e7add4fb361e06 > The reason I ask is that hvmemul_do_io() can call hvm_send_ioreq() to sta= rt an I/O when is_shutting_down is set, but will write the local io_req.sta= te back to NONE even when X86EMUL_RETRY is returned. Thus another call to h= andle_pio() will try to start a new I/O but will fail with X86EMUL_UNHANDLE= ABLE in hvm_send_ioreq() because the ioreq state in the shared page will no= t be NONE. Isn't it a problem that hvm_send_ioreq() can be called called if is_shuttin= g_down is set? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --PqX6tBBuHl4HmZHK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7aQscACgkQ24/THMrX 1ywwcQf/Uyl9MhWtHyawitPXnGCrbzUdE2fqJE6R0IKThUCmWa2PIvMIE9HUfvUe dl5i+gBq1FHYUDSX6M4QxoyCOyw7xnhnJyJFVhMSmljUlqdp73TLYbPdIkgBcX1Z TF0X4OP4QmtZcArFniYSqhH4NoaILPwBWSF9cfOz2crWUAjEwRBJG9DGwRiuRH9h DgIQb10a4MOF+hfjjTxWvy3XxQkX3rGaD3k/RjJrhBRLIZs413BMcwyT9WjyfbYJ +fcyROKEUH7MUe4TZR/NX6YiUPUP1sXKyOGIQirvFu84y0t9WpvCGgpFZCBm2yHx 1px8CN8ypgMNOLw6DQB5TDGn6bE3Lw== =7dQV -----END PGP SIGNATURE----- --PqX6tBBuHl4HmZHK-- From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:24:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:24:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCKQ-0002LT-FP; Fri, 05 Jun 2020 13:24:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCKP-0002LO-Bd for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:24:09 +0000 X-Inumbo-ID: d59d5fc4-a72f-11ea-9ad7-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d59d5fc4-a72f-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 13:24:08 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id y20so1387735wmi.2 for ; Fri, 05 Jun 2020 06:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Bbfs/rhLlMur6P/6rL8uZWFD5SdAbhUlixtrc25R3jE=; b=ID1GphIsNI+cdg3iyJOSme9h2G0y3+xWbw/mhQj+4wN0Fic+T4RrwVjuu1JH4tuSQa 7tn8rqpddmUlkmH2F35w9Txs1skA04zJ8a4ds0bk8a4TlxZ0yKj2FYYE+vQpVV/LPfUn 4kkH1nqd/QYRjQr98AAL3MWNIKETl7b3FUvxHUEkhO9r6WAcqXwqTyfPF5FSdRokNVgP k0Aomuz346LJCnUrhbf8sxu0xaEpoqqP2b4hTrl44VKXqk+SX4EO6qUPhmNF9yqGm95C RrlvPE3bCXFzyBEFmo07ONCW5us2BTM0HrVmU1b0ZMmfzodlVCR+vlDxi3ixmnA+IaDJ GJfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=Bbfs/rhLlMur6P/6rL8uZWFD5SdAbhUlixtrc25R3jE=; b=HHDOYeTlm3n/WKg1fOv9wGPHa+ltYk/cPrWT2iyYrtDEPdqDnRe7IOzORnUaFAd0ru MMYsJMOunE5hgz7wcAhNtCWj7VXaof8gNTgkwyxT7kKf6RN68p33av9pT81ADDcc+Dj8 2GK1urVZnW6KGXrkKj3y1fWX1ZM4RlnxIkGpb9Cj89T7DWJ9ofVL2jVob2NjcRyPjcCS nTQ9wEvXX3w2oCdGe1u2XrA3J1gOozPWgKy4WX24RNW5tEUjYcJsVaszm/7AyextSSGz 4guC3EnH/KaOH0zn8bJo/TeWcCAjDYk9o5t8vWCJMWqyYGmZMqz70Cqw8vA3Es0kOSuc wr3w== X-Gm-Message-State: AOAM532bK5QhoNqeYi586pqfAXDG5KOSm7QiFzQ5cScyHzG/s1owip2h VreoCISnb9h22SHLdQJ7rvA= X-Google-Smtp-Source: ABdhPJwxOXwwKDoILiKrM+sJfKdDv+NTPW0aDulH+I7j5VnmZPawysucbRGQxEJIag/TDrIk6zxmaw== X-Received: by 2002:a1c:790a:: with SMTP id l10mr2547618wme.80.1591363447413; Fri, 05 Jun 2020 06:24:07 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id h7sm11204560wml.24.2020.06.05.06.24.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 06:24:06 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <20200605120137.GF98582@mail-itl> <000a01d63b36$5ca617b0$15f24710$@xen.org> <20200605130408.GI98582@mail-itl> In-Reply-To: <20200605130408.GI98582@mail-itl> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 14:24:05 +0100 Message-ID: <001f01d63b3c$96ce3020$c46a9060$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoACJ30jDAXuEodcCsFgQ5AHivRJwAUZxxQABFk5KigGiA5kJAgWY+ZMB7ft0Fai7xl2w X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Jan Beulich' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: 'Marek Marczykowski-G=C3=B3recki' = > Sent: 05 June 2020 14:04 > To: paul@xen.org > Cc: 'Jan Beulich' ; 'Andrew Cooper' = ; 'xen-devel' devel@lists.xenproject.org> > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On Fri, Jun 05, 2020 at 01:39:31PM +0100, Paul Durrant wrote: > > > -----Original Message----- > > > From: Marek Marczykowski-G=C3=B3recki = > > > Sent: 05 June 2020 13:02 > > > To: Jan Beulich > > > Cc: Andrew Cooper ; Paul Durrant = ; xen-devel > > devel@lists.xenproject.org> > > > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > > > > > > On Fri, Jun 05, 2020 at 11:22:46AM +0200, Jan Beulich wrote: > > > > On 05.06.2020 11:09, Jan Beulich wrote: > > > > > On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > > > > >> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > > > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > > >> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > > > > >> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > > > > >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > > > > >> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown = 1 > > > > >> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > > > > >> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > > > > >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > > > >> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > > > >> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > > > > >> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > > > > >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > > > >> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown = 1 > > > > >> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > > > > >> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d = flags 0x2 d6 > > > > >> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e = flags 0x2 d6 > > > > >> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > > > > > > > > > Perhaps in this message could you also log > > > > > v->domain->is_shutting_down, v->defer_shutdown, and > > > > > v->paused_for_shutdown? > > > > > > > > And v->domain->is_shut_down please. > > > > > > Here it is: > > > > > > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 > paused_for_shutdown > > > 0 is_shut_down 0 > > > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 > paused_for_shutdown > > > 0 is_shut_down 0 > > > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 = defer_shutdown 0 > paused_for_shutdown > > > 0 is_shut_down 0 > > > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 = defer_shutdown 0 > paused_for_shutdown > > > 0 is_shut_down 0 > > > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > > > (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > > > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > > > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 > paused_for_shutdown > > > 0 is_shut_down 0 > > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 > paused_for_shutdown > > > 0 is_shut_down 0 > > > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 = defer_shutdown 0 > paused_for_shutdown > > > 0 is_shut_down 0 > > > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 = defer_shutdown 0 > paused_for_shutdown > > > 0 is_shut_down 0 > > > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > > (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > > > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > > > (XEN) grant_table.c:3702:d0v1 Grant release 0x3 ref 0x125 flags = 0x2 d6 > > > (XEN) grant_table.c:3702:d0v1 Grant release 0x4 ref 0x126 flags = 0x2 d6 > > > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 1 = defer_shutdown 1 > paused_for_shutdown > > > 0 is_shut_down 0 > > > (XEN) d1v0 Unexpected PIO status 1, port 0xb004 read 0xffff > > > > > > (and then the stacktrace saying it's from vmexit handler) > > > > > > Regarding BUG/WARN - do you think I could get any more info then? = I > > > really don't mind crashing that system, it's a virtual machine > > > currently used only for debugging this issue. > > > > In your logging, is that handle_pio with is_shutting_down =3D=3D 1 = the very last one, or is the > 'Unexpected PIO' coming from another one issued afterwards? >=20 > That's the same function call - handle_pio message is before = hvmemul_do_pio_buffer() and Unexpected > PIO is after. >=20 > Here is the current debugging patch: = https://gist.github.com/marmarek/da37da3722179057a6e7add4fb361e06 >=20 Ok. > > The reason I ask is that hvmemul_do_io() can call hvm_send_ioreq() = to start an I/O when > is_shutting_down is set, but will write the local io_req.state back to = NONE even when X86EMUL_RETRY is > returned. Thus another call to handle_pio() will try to start a new = I/O but will fail with > X86EMUL_UNHANDLEABLE in hvm_send_ioreq() because the ioreq state in = the shared page will not be NONE. >=20 > Isn't it a problem that hvm_send_ioreq() can be called called if = is_shutting_down is set? >=20 I don't think so... as long as it is not called again a second time. Paul > -- > Best Regards, > Marek Marczykowski-G=C3=B3recki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:32:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:32:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCSG-0003Kw-9L; Fri, 05 Jun 2020 13:32:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCSF-0003Kr-0x for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:32:15 +0000 X-Inumbo-ID: f6ab83e8-a730-11ea-9b55-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f6ab83e8-a730-11ea-9b55-bc764e2007e4; Fri, 05 Jun 2020 13:32:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8C515AEE8; Fri, 5 Jun 2020 13:32:15 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: paul@xen.org References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 15:32:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <000501d63b29$496ce6e0$dc46b4a0$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 13:05, Paul Durrant wrote: > Sorry, only just catching up with this... > >> -----Original Message----- >> From: Jan Beulich >> Sent: 05 June 2020 10:09 >> To: Marek Marczykowski-Górecki >> Cc: Andrew Cooper ; xen-devel ; Paul >> Durrant >> Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom >> >> On 04.06.2020 16:25, Marek Marczykowski-Górecki wrote: >>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: >>>> On 04.06.2020 13:13, Andrew Cooper wrote: >>>>> On 04/06/2020 08:08, Jan Beulich wrote: >>>>>> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: >>>>>>> Then, we get the main issue: >>>>>>> >>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff >>>>>>> (XEN) domain_crash called from io.c:178 >>>>>>> >>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom >>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. >>>>>> I'd guess an issue with the shutdown deferral logic. Did you / can >>>>>> you check whether XEN_DMOP_remote_shutdown managed to pause all >>>>>> CPUs (I assume it didn't, since once they're paused there shouldn't >>>>>> be any I/O there anymore, and hence no I/O emulation)? >>>>> >>>>> The vcpu in question is talking to Qemu, so will have v->defer_shutdown >>>>> intermittently set, and skip the pause in domain_shutdown() >>>>> >>>>> I presume this lack of pause is to allow the vcpu in question to still >>>>> be scheduled to consume the IOREQ reply? (Its fairly opaque logic with >>>>> 0 clarifying details). >>>>> >>>>> What *should* happen is that, after consuming the reply, the vcpu should >>>>> notice and pause itself, at which point it would yield to the >>>>> scheduler. This is the purpose of vcpu_{start,end}_shutdown_deferral(). >>>>> >>>>> Evidentially, this is not happening. >>>> >>>> We can't tell yet, until ... >>>> >>>>> Marek: can you add a BUG() after the weird PIO printing? That should >>>>> confirm whether we're getting into handle_pio() via the >>>>> handle_hvm_io_completion() path, or via the vmexit path (at which case, >>>>> we're fully re-entering the guest). >>>> >>>> ... we know this. handle_pio() gets called from handle_hvm_io_completion() >>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> >>>> vcpu_end_shutdown_deferral(), so the issue may be that we shouldn't call >>>> handle_pio() (etc) at all anymore in this state. IOW perhaps >>>> hvm_wait_for_io() should return "!sv->vcpu->domain->is_shutting_down" >>>> instead of plain "true"? >>>> >>>> Adding Paul to Cc, as being the maintainer here. >>> >>> Got it, by sticking BUG() just before that domain_crash() in >>> handle_pio(). And also vcpu 0 of both HVM domains do have >>> v->defer_shutdown. >> >> As per the log they did get it set. I'd be curious of the flag's >> value (as well as v->paused_for_shutdown's) at the point of the >> problematic handle_pio() invocation (see below). It may be >> worthwhile to instrument vcpu_check_shutdown() (inside its if()) >> - before exiting to guest context (in order to then come back >> and call handle_pio()) the vCPU ought to be getting through >> there. No indication of it doing so would be a sign that there's >> a code path bypassing the call to vcpu_end_shutdown_deferral(). >> >>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 >>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 >>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 >>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 >>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done >>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. >>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 >>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 >>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 >>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 >>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done >>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 >>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >> >> Perhaps in this message could you also log >> v->domain->is_shutting_down, v->defer_shutdown, and >> v->paused_for_shutdown? (Would be nice if, after having made >> changes to your debugging patch, you could point again at the >> precise version you've used for the log provided.) >> >>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff >>> (XEN) Xen BUG at io.c:178 >> >> Btw, instead of BUG(), WARN() or dump_execution_state() would >> likely also do, keeping Xen alive. >> > > A shutdown deferral problem would result in X86EMUL_RETRY wouldn't it? Where would this originate? > That would mean we wouldn't be seeing the "Unexpected PIO" message. From that message this clearly X86EMUL_UNHANDLEABLE which suggests a race with ioreq server teardown, possibly due to selecting a server but then not finding a vcpu match in ioreq_vcpu_list. I was suspecting such, but at least the tearing down of all servers happens only from relinquish-resources, which gets started only after ->is_shut_down got set (unless the tool stack invoked XEN_DOMCTL_destroydomain without having observed XEN_DOMINF_shutdown set for the domain). For individually unregistered servers - yes, if qemu did so, this would be a problem. They need to remain registered until all vCPU-s in the domain got paused. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:37:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:37:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCWt-0003Vm-Tb; Fri, 05 Jun 2020 13:37:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCWs-0003Vg-Gd for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:37:02 +0000 X-Inumbo-ID: a289268e-a731-11ea-9ad7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a289268e-a731-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 13:37:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 00E8DAAD0; Fri, 5 Jun 2020 13:37:03 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: paul@xen.org References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <000701d63b2c$10536930$30fa3b90$@xen.org> From: Jan Beulich Message-ID: <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> Date: Fri, 5 Jun 2020 15:36:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <000701d63b2c$10536930$30fa3b90$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 13:25, Paul Durrant wrote: >> -----Original Message----- >> From: Paul Durrant >> Sent: 05 June 2020 12:06 >> To: 'Jan Beulich' ; 'Marek Marczykowski-Górecki' >> Cc: 'Andrew Cooper' ; 'xen-devel' >> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom >> >> Sorry, only just catching up with this... >> >>> -----Original Message----- >>> From: Jan Beulich >>> Sent: 05 June 2020 10:09 >>> To: Marek Marczykowski-Górecki >>> Cc: Andrew Cooper ; xen-devel ; Paul >>> Durrant >>> Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom >>> >>> On 04.06.2020 16:25, Marek Marczykowski-Górecki wrote: >>>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: >>>>> On 04.06.2020 13:13, Andrew Cooper wrote: >>>>>> On 04/06/2020 08:08, Jan Beulich wrote: >>>>>>> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: >>>>>>>> Then, we get the main issue: >>>>>>>> >>>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff >>>>>>>> (XEN) domain_crash called from io.c:178 >>>>>>>> >>>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom >>>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. >>>>>>> I'd guess an issue with the shutdown deferral logic. Did you / can >>>>>>> you check whether XEN_DMOP_remote_shutdown managed to pause all >>>>>>> CPUs (I assume it didn't, since once they're paused there shouldn't >>>>>>> be any I/O there anymore, and hence no I/O emulation)? >>>>>> >>>>>> The vcpu in question is talking to Qemu, so will have v->defer_shutdown >>>>>> intermittently set, and skip the pause in domain_shutdown() >>>>>> >>>>>> I presume this lack of pause is to allow the vcpu in question to still >>>>>> be scheduled to consume the IOREQ reply? (Its fairly opaque logic with >>>>>> 0 clarifying details). >>>>>> >>>>>> What *should* happen is that, after consuming the reply, the vcpu should >>>>>> notice and pause itself, at which point it would yield to the >>>>>> scheduler. This is the purpose of vcpu_{start,end}_shutdown_deferral(). >>>>>> >>>>>> Evidentially, this is not happening. >>>>> >>>>> We can't tell yet, until ... >>>>> >>>>>> Marek: can you add a BUG() after the weird PIO printing? That should >>>>>> confirm whether we're getting into handle_pio() via the >>>>>> handle_hvm_io_completion() path, or via the vmexit path (at which case, >>>>>> we're fully re-entering the guest). >>>>> >>>>> ... we know this. handle_pio() gets called from handle_hvm_io_completion() >>>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> >>>>> vcpu_end_shutdown_deferral(), so the issue may be that we shouldn't call >>>>> handle_pio() (etc) at all anymore in this state. IOW perhaps >>>>> hvm_wait_for_io() should return "!sv->vcpu->domain->is_shutting_down" >>>>> instead of plain "true"? >>>>> >>>>> Adding Paul to Cc, as being the maintainer here. >>>> >>>> Got it, by sticking BUG() just before that domain_crash() in >>>> handle_pio(). And also vcpu 0 of both HVM domains do have >>>> v->defer_shutdown. >>> >>> As per the log they did get it set. I'd be curious of the flag's >>> value (as well as v->paused_for_shutdown's) at the point of the >>> problematic handle_pio() invocation (see below). It may be >>> worthwhile to instrument vcpu_check_shutdown() (inside its if()) >>> - before exiting to guest context (in order to then come back >>> and call handle_pio()) the vCPU ought to be getting through >>> there. No indication of it doing so would be a sign that there's >>> a code path bypassing the call to vcpu_end_shutdown_deferral(). >>> >>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 >>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 >>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 >>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done >>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. >>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 >>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 >>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 >>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done >>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 >>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>> >>> Perhaps in this message could you also log >>> v->domain->is_shutting_down, v->defer_shutdown, and >>> v->paused_for_shutdown? (Would be nice if, after having made >>> changes to your debugging patch, you could point again at the >>> precise version you've used for the log provided.) >>> >>>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff >>>> (XEN) Xen BUG at io.c:178 >>> >>> Btw, instead of BUG(), WARN() or dump_execution_state() would >>> likely also do, keeping Xen alive. >>> >> >> A shutdown deferral problem would result in X86EMUL_RETRY wouldn't it? That would mean we wouldn't be >> seeing the "Unexpected PIO" message. From that message this clearly X86EMUL_UNHANDLEABLE which >> suggests a race with ioreq server teardown, possibly due to selecting a server but then not finding a >> vcpu match in ioreq_vcpu_list. > > Actually looking at remote_shutdown... the test of ( reason == SHUTDOWN_crash ) and then clearing defer_shutdown looks a bit odd... Just because the domain shutdown code has been set that way doesn't mean that a vcpu is not deferred in emulation; SCHEDOP_shutdown_code could easily be called from one vcpu whilst another has emulation pending. I'm confused: The deferral is of shutting down the domain, not of a specific instance of emulation. When a guest crashed I understand this code is intended to make sure shutting down because of the crash won't get deferred because of in-progress emulation anywhere. Marek didn't provide any hints so far that the guest may be crashing, so I think if there is an issue here, it's likely only a tangential one anyway. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:37:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:37:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCXZ-0003YC-6Z; Fri, 05 Jun 2020 13:37:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCXX-0003Y5-LG for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:37:43 +0000 X-Inumbo-ID: bb1239ac-a731-11ea-9ad7-bc764e2007e4 Received: from mail-wm1-x335.google.com (unknown [2a00:1450:4864:20::335]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bb1239ac-a731-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 13:37:42 +0000 (UTC) Received: by mail-wm1-x335.google.com with SMTP id l26so8464581wme.3 for ; Fri, 05 Jun 2020 06:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Xnm6RG1lTRFl8C4lU0Ru25tg/z+eFwYbBvt6kf3Jqkw=; b=BthjVa0muG3yXjSU0ZpR3CzXbCwWuZOD4cagqq8MzzM7bi2MZLtSKJDN9S1OrRIv0E Y1+lUJGDoR2Zh9YZUQ3BKGPmNBfLfb8JkoiyBWvLAhLNcjdHNZtsXGjF3/DxD7FNR410 HfP9WNqsQQFF/c97eR8Q1c8Nib54AYBhwrE2+IeL1/dgdej7wgmTAl5xkezn6KMGUoOa T/JrRcBgcpya2Q4vNCzWBUnGDJVQstn7LteWx6AMCmMkA4nRFnNjoo2lpTzAXyKgYQS7 1Aki8r3LhBiADLMTQCya4rJFgjnmerL0boYyshB/RbHZFq7/NbKVctaoATIs/u9iIGnE 5tag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=Xnm6RG1lTRFl8C4lU0Ru25tg/z+eFwYbBvt6kf3Jqkw=; b=hMZ+Fx1vgK+FEhL8jvoVTe0iZ/7eAciWt9hXabqndXsBevplCQXVoZasFx4roEVxb8 wVv3X01HyvYtSbURuQzh3PYOobKgRfIVZL6u6hXnX6gJFIEXToF+a3WB0tzvDomiytjH O8d3mAclBjLInZxnE/CFlicz+YaA3/q6AlQlBlqOAGcbKKIIC6rvf041AfrISFfCcAey E+Q1Eqfqn3MbG/s48m4UtlmWw1YzSLj/zCn0TrraVjKYxOqwTuILNV5bmyH3rgXqILIc W/om/39ENRrDbJ6TKrMZLunptHTPmMsi6HlAO6ohjO1mMBH2Nfgf9Nndj0bDK8layZrf bLcA== X-Gm-Message-State: AOAM530tB+MGMNRNSeFNk9GkIQXTLdbclhx887bAVryiH0JxEAo6/jMI vBsL6Os9Mnirukh3nHJbSX8= X-Google-Smtp-Source: ABdhPJygeSuKWH7scO4PI+yarj+iQ6lcV7GxaVwUN142f5582pj7/VUnBRTXvwRusg7t706HXJocvw== X-Received: by 2002:a1c:143:: with SMTP id 64mr2909215wmb.182.1591364261828; Fri, 05 Jun 2020 06:37:41 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id f9sm11732769wre.65.2020.06.05.06.37.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 06:37:41 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> In-Reply-To: Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 14:37:39 +0100 Message-ID: <002001d63b3e$7c268a40$74739ec0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoACJ30jDAXuEodcCsFgQ5AHivRJwAUZxxQAClbGaTgE+0ENsqNKFMYA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 05 June 2020 14:32 > To: paul@xen.org > Cc: 'Marek Marczykowski-G=C3=B3recki' = ; 'Andrew Cooper' > ; 'xen-devel' = > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On 05.06.2020 13:05, Paul Durrant wrote: > > Sorry, only just catching up with this... > > > >> -----Original Message----- > >> From: Jan Beulich > >> Sent: 05 June 2020 10:09 > >> To: Marek Marczykowski-G=C3=B3recki = > >> Cc: Andrew Cooper ; xen-devel = ; Paul > >> Durrant > >> Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > >> > >> On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > >>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: > >>>> On 04.06.2020 13:13, Andrew Cooper wrote: > >>>>> On 04/06/2020 08:08, Jan Beulich wrote: > >>>>>> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > >>>>>>> Then, we get the main issue: > >>>>>>> > >>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > >>>>>>> (XEN) domain_crash called from io.c:178 > >>>>>>> > >>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor = its stubdom > >>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called = already. > >>>>>> I'd guess an issue with the shutdown deferral logic. Did you / = can > >>>>>> you check whether XEN_DMOP_remote_shutdown managed to pause all > >>>>>> CPUs (I assume it didn't, since once they're paused there = shouldn't > >>>>>> be any I/O there anymore, and hence no I/O emulation)? > >>>>> > >>>>> The vcpu in question is talking to Qemu, so will have = v->defer_shutdown > >>>>> intermittently set, and skip the pause in domain_shutdown() > >>>>> > >>>>> I presume this lack of pause is to allow the vcpu in question to = still > >>>>> be scheduled to consume the IOREQ reply? (Its fairly opaque = logic with > >>>>> 0 clarifying details). > >>>>> > >>>>> What *should* happen is that, after consuming the reply, the = vcpu should > >>>>> notice and pause itself, at which point it would yield to the > >>>>> scheduler. This is the purpose of = vcpu_{start,end}_shutdown_deferral(). > >>>>> > >>>>> Evidentially, this is not happening. > >>>> > >>>> We can't tell yet, until ... > >>>> > >>>>> Marek: can you add a BUG() after the weird PIO printing? That = should > >>>>> confirm whether we're getting into handle_pio() via the > >>>>> handle_hvm_io_completion() path, or via the vmexit path (at = which case, > >>>>> we're fully re-entering the guest). > >>>> > >>>> ... we know this. handle_pio() gets called from = handle_hvm_io_completion() > >>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> > >>>> vcpu_end_shutdown_deferral(), so the issue may be that we = shouldn't call > >>>> handle_pio() (etc) at all anymore in this state. IOW perhaps > >>>> hvm_wait_for_io() should return = "!sv->vcpu->domain->is_shutting_down" > >>>> instead of plain "true"? > >>>> > >>>> Adding Paul to Cc, as being the maintainer here. > >>> > >>> Got it, by sticking BUG() just before that domain_crash() in > >>> handle_pio(). And also vcpu 0 of both HVM domains do have > >>> v->defer_shutdown. > >> > >> As per the log they did get it set. I'd be curious of the flag's > >> value (as well as v->paused_for_shutdown's) at the point of the > >> problematic handle_pio() invocation (see below). It may be > >> worthwhile to instrument vcpu_check_shutdown() (inside its if()) > >> - before exiting to guest context (in order to then come back > >> and call handle_pio()) the vCPU ought to be getting through > >> there. No indication of it doing so would be a sign that there's > >> a code path bypassing the call to vcpu_end_shutdown_deferral(). > >> > >>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > >>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > >>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > >>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > >>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > >>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > >>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > >>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > >>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > >>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags = 0x2 d6 > >>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags = 0x2 d6 > >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >> > >> Perhaps in this message could you also log > >> v->domain->is_shutting_down, v->defer_shutdown, and > >> v->paused_for_shutdown? (Would be nice if, after having made > >> changes to your debugging patch, you could point again at the > >> precise version you've used for the log provided.) > >> > >>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff > >>> (XEN) Xen BUG at io.c:178 > >> > >> Btw, instead of BUG(), WARN() or dump_execution_state() would > >> likely also do, keeping Xen alive. > >> > > > > A shutdown deferral problem would result in X86EMUL_RETRY wouldn't = it? >=20 > Where would this originate? I was referring to the 'if ( = unlikely(!vcpu_start_shutdown_deferral(curr)) )' at the top of = hvm_send_ioreq(). >=20 > > That would mean we wouldn't be seeing the "Unexpected PIO" message. = >From that message this clearly > X86EMUL_UNHANDLEABLE which suggests a race with ioreq server teardown, = possibly due to selecting a > server but then not finding a vcpu match in ioreq_vcpu_list. >=20 > I was suspecting such, but at least the tearing down of all servers > happens only from relinquish-resources, which gets started only > after ->is_shut_down got set (unless the tool stack invoked > XEN_DOMCTL_destroydomain without having observed XEN_DOMINF_shutdown > set for the domain). >=20 > For individually unregistered servers - yes, if qemu did so, this > would be a problem. They need to remain registered until all vCPU-s > in the domain got paused. It shouldn't be a problem should it? Destroying an individual server is = only done with the domain paused, so no vcpus can be running at the = time. Paul >=20 > Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:43:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:43:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCdG-0004ZQ-0X; Fri, 05 Jun 2020 13:43:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCdE-0004ZJ-Tj for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:43:36 +0000 X-Inumbo-ID: 8d6e145c-a732-11ea-9ad7-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8d6e145c-a732-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 13:43:35 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id g10so8487008wmh.4 for ; Fri, 05 Jun 2020 06:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=UNKdzT59ZwmIuf42YyxEz1Rhf/x0wb/a7d/IDbtoyJw=; b=iKSBCDxsnXNxLlHe5fOFjE3rMMhkJgdaxtubeZfpEi9EUUbVSffnFeN0BxkMDqhTB2 k9fdB+QtmiESq3nUZpIO+970XJEU1cCjsx8bl/+56ZED7CnQEehBbS92VPOoG7DzJAyl 36+HvjcadPas1evRsj9Gy2JeLmAIQ/gaX5WR3xdfP2y7cZ777gPXLZWaIif+JoGRPf6u gHa2PpSO532fTiS9Pp5xC6pMlPhb/6AsxrwxgYz6ZKRf1zgjI9z/rgfD+JmLQKyPxl+G osmz4b3RivCl6yGb9bhDmMv941FXyX1OqFLZUFC8sP57tRDFqLBwA6gtZPM3yEcq9E5P CmFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=UNKdzT59ZwmIuf42YyxEz1Rhf/x0wb/a7d/IDbtoyJw=; b=OEkAsZiIsHZC2Y1zpGUy+ZhfIW+fgCfAAAlKDBRzY9B/q3C47qb5vHkKEFb5xnTYsp Ge5pyDFWXJcMBnWiVKOz1KSbU8YQnwVhNE+R5ihX3wKtSE8JuCKjI38pqo6j6IR6ZmVb gMBICITvOSYwHwm4WPP/YnX0FoDcgFN6QYRdOkJdcUTPeQiUhRthzJifp2kVn2sifV6I LHXp7i4ZDIcqRIIRwyXGyorov0US0JyeYzTtLkrerSANoeuEzDequiJnG/g4/07y9vKS X6aLsCqnjqFlBxntjJlQctr3gV3YD/PZApNTJw7hEFXwzPHyMn/1OdaXBb8jFn3gfwt+ l/tQ== X-Gm-Message-State: AOAM533vQZTGJMZ45vCJPPcliE37DNJ8TF9/MQA7GEKKznKjxN8zy6p7 b83X3shFZgeV/CMyEmGMAUw= X-Google-Smtp-Source: ABdhPJyIjVTz21mEg2sUhllWTH5UMvanLjkL/uYR/UglXM36QDxNhtIAIDrZs6ya2+WT36EWX2nGdA== X-Received: by 2002:a1c:28c5:: with SMTP id o188mr2690588wmo.62.1591364614752; Fri, 05 Jun 2020 06:43:34 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id c6sm12425955wro.92.2020.06.05.06.43.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 06:43:34 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <000701d63b2c$10536930$30fa3b90$@xen.org> <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> In-Reply-To: <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 14:43:32 +0100 Message-ID: <002101d63b3f$4e9dc830$ebd95890$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoACJ30jDAXuEodcCsFgQ5AHivRJwAUZxxQAClbGaTgD0KkheAp3cNn+ov+yR0A== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 05 June 2020 14:37 > To: paul@xen.org > Cc: 'Marek Marczykowski-G=C3=B3recki' = ; 'Andrew Cooper' > ; 'xen-devel' = > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On 05.06.2020 13:25, Paul Durrant wrote: > >> -----Original Message----- > >> From: Paul Durrant > >> Sent: 05 June 2020 12:06 > >> To: 'Jan Beulich' ; 'Marek = Marczykowski-G=C3=B3recki' > > >> Cc: 'Andrew Cooper' ; 'xen-devel' = > >> Subject: RE: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > >> > >> Sorry, only just catching up with this... > >> > >>> -----Original Message----- > >>> From: Jan Beulich > >>> Sent: 05 June 2020 10:09 > >>> To: Marek Marczykowski-G=C3=B3recki = > >>> Cc: Andrew Cooper ; xen-devel = ; Paul > >>> Durrant > >>> Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > >>> > >>> On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > >>>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: > >>>>> On 04.06.2020 13:13, Andrew Cooper wrote: > >>>>>> On 04/06/2020 08:08, Jan Beulich wrote: > >>>>>>> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > >>>>>>>> Then, we get the main issue: > >>>>>>>> > >>>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > >>>>>>>> (XEN) domain_crash called from io.c:178 > >>>>>>>> > >>>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor = its stubdom > >>>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called = already. > >>>>>>> I'd guess an issue with the shutdown deferral logic. Did you / = can > >>>>>>> you check whether XEN_DMOP_remote_shutdown managed to pause = all > >>>>>>> CPUs (I assume it didn't, since once they're paused there = shouldn't > >>>>>>> be any I/O there anymore, and hence no I/O emulation)? > >>>>>> > >>>>>> The vcpu in question is talking to Qemu, so will have = v->defer_shutdown > >>>>>> intermittently set, and skip the pause in domain_shutdown() > >>>>>> > >>>>>> I presume this lack of pause is to allow the vcpu in question = to still > >>>>>> be scheduled to consume the IOREQ reply? (Its fairly opaque = logic with > >>>>>> 0 clarifying details). > >>>>>> > >>>>>> What *should* happen is that, after consuming the reply, the = vcpu should > >>>>>> notice and pause itself, at which point it would yield to the > >>>>>> scheduler. This is the purpose of = vcpu_{start,end}_shutdown_deferral(). > >>>>>> > >>>>>> Evidentially, this is not happening. > >>>>> > >>>>> We can't tell yet, until ... > >>>>> > >>>>>> Marek: can you add a BUG() after the weird PIO printing? That = should > >>>>>> confirm whether we're getting into handle_pio() via the > >>>>>> handle_hvm_io_completion() path, or via the vmexit path (at = which case, > >>>>>> we're fully re-entering the guest). > >>>>> > >>>>> ... we know this. handle_pio() gets called from = handle_hvm_io_completion() > >>>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> > >>>>> vcpu_end_shutdown_deferral(), so the issue may be that we = shouldn't call > >>>>> handle_pio() (etc) at all anymore in this state. IOW perhaps > >>>>> hvm_wait_for_io() should return = "!sv->vcpu->domain->is_shutting_down" > >>>>> instead of plain "true"? > >>>>> > >>>>> Adding Paul to Cc, as being the maintainer here. > >>>> > >>>> Got it, by sticking BUG() just before that domain_crash() in > >>>> handle_pio(). And also vcpu 0 of both HVM domains do have > >>>> v->defer_shutdown. > >>> > >>> As per the log they did get it set. I'd be curious of the flag's > >>> value (as well as v->paused_for_shutdown's) at the point of the > >>> problematic handle_pio() invocation (see below). It may be > >>> worthwhile to instrument vcpu_check_shutdown() (inside its if()) > >>> - before exiting to guest context (in order to then come back > >>> and call handle_pio()) the vCPU ought to be getting through > >>> there. No indication of it doing so would be a sign that there's > >>> a code path bypassing the call to vcpu_end_shutdown_deferral(). > >>> > >>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > >>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > >>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > >>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > >>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > >>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > >>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > >>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > >>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > >>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags = 0x2 d6 > >>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags = 0x2 d6 > >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>> > >>> Perhaps in this message could you also log > >>> v->domain->is_shutting_down, v->defer_shutdown, and > >>> v->paused_for_shutdown? (Would be nice if, after having made > >>> changes to your debugging patch, you could point again at the > >>> precise version you've used for the log provided.) > >>> > >>>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff > >>>> (XEN) Xen BUG at io.c:178 > >>> > >>> Btw, instead of BUG(), WARN() or dump_execution_state() would > >>> likely also do, keeping Xen alive. > >>> > >> > >> A shutdown deferral problem would result in X86EMUL_RETRY wouldn't = it? That would mean we wouldn't > be > >> seeing the "Unexpected PIO" message. From that message this clearly = X86EMUL_UNHANDLEABLE which > >> suggests a race with ioreq server teardown, possibly due to = selecting a server but then not finding > a > >> vcpu match in ioreq_vcpu_list. > > > > Actually looking at remote_shutdown... the test of ( reason =3D=3D = SHUTDOWN_crash ) and then clearing > defer_shutdown looks a bit odd... Just because the domain shutdown = code has been set that way doesn't > mean that a vcpu is not deferred in emulation; SCHEDOP_shutdown_code = could easily be called from one > vcpu whilst another has emulation pending. >=20 > I'm confused: The deferral is of shutting down the domain, not of > a specific instance of emulation. Now I'm confused... defer_shutdown is per-vcpu. > When a guest crashed I understand > this code is intended to make sure shutting down because of the > crash won't get deferred because of in-progress emulation anywhere. >=20 OK, I neglected to notice the vcpu_pause_nosync() just below so, yes, = there should be no way we can erroneously try to complete emulation = after this point. Paul > Marek didn't provide any hints so far that the guest may be crashing, > so I think if there is an issue here, it's likely only a tangential > one anyway. >=20 > Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:46:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:46:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCgF-0004iS-Fw; Fri, 05 Jun 2020 13:46:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCgE-0004iM-CE for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:46:42 +0000 X-Inumbo-ID: fb12fdb1-a732-11ea-afc1-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fb12fdb1-a732-11ea-afc1-12813bfff9fa; Fri, 05 Jun 2020 13:46:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4727DAAD0; Fri, 5 Jun 2020 13:46:43 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: paul@xen.org References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <000701d63b2c$10536930$30fa3b90$@xen.org> <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> <002101d63b3f$4e9dc830$ebd95890$@xen.org> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 15:46:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <002101d63b3f$4e9dc830$ebd95890$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 15:43, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 05 June 2020 14:37 >> To: paul@xen.org >> Cc: 'Marek Marczykowski-Górecki' ; 'Andrew Cooper' >> ; 'xen-devel' >> Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom >> >> On 05.06.2020 13:25, Paul Durrant wrote: >>>> -----Original Message----- >>>> From: Paul Durrant >>>> Sent: 05 June 2020 12:06 >>>> To: 'Jan Beulich' ; 'Marek Marczykowski-Górecki' >> >>>> Cc: 'Andrew Cooper' ; 'xen-devel' >>>> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom >>>> >>>> Sorry, only just catching up with this... >>>> >>>>> -----Original Message----- >>>>> From: Jan Beulich >>>>> Sent: 05 June 2020 10:09 >>>>> To: Marek Marczykowski-Górecki >>>>> Cc: Andrew Cooper ; xen-devel ; Paul >>>>> Durrant >>>>> Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom >>>>> >>>>> On 04.06.2020 16:25, Marek Marczykowski-Górecki wrote: >>>>>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: >>>>>>> On 04.06.2020 13:13, Andrew Cooper wrote: >>>>>>>> On 04/06/2020 08:08, Jan Beulich wrote: >>>>>>>>> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: >>>>>>>>>> Then, we get the main issue: >>>>>>>>>> >>>>>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff >>>>>>>>>> (XEN) domain_crash called from io.c:178 >>>>>>>>>> >>>>>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom >>>>>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. >>>>>>>>> I'd guess an issue with the shutdown deferral logic. Did you / can >>>>>>>>> you check whether XEN_DMOP_remote_shutdown managed to pause all >>>>>>>>> CPUs (I assume it didn't, since once they're paused there shouldn't >>>>>>>>> be any I/O there anymore, and hence no I/O emulation)? >>>>>>>> >>>>>>>> The vcpu in question is talking to Qemu, so will have v->defer_shutdown >>>>>>>> intermittently set, and skip the pause in domain_shutdown() >>>>>>>> >>>>>>>> I presume this lack of pause is to allow the vcpu in question to still >>>>>>>> be scheduled to consume the IOREQ reply? (Its fairly opaque logic with >>>>>>>> 0 clarifying details). >>>>>>>> >>>>>>>> What *should* happen is that, after consuming the reply, the vcpu should >>>>>>>> notice and pause itself, at which point it would yield to the >>>>>>>> scheduler. This is the purpose of vcpu_{start,end}_shutdown_deferral(). >>>>>>>> >>>>>>>> Evidentially, this is not happening. >>>>>>> >>>>>>> We can't tell yet, until ... >>>>>>> >>>>>>>> Marek: can you add a BUG() after the weird PIO printing? That should >>>>>>>> confirm whether we're getting into handle_pio() via the >>>>>>>> handle_hvm_io_completion() path, or via the vmexit path (at which case, >>>>>>>> we're fully re-entering the guest). >>>>>>> >>>>>>> ... we know this. handle_pio() gets called from handle_hvm_io_completion() >>>>>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> >>>>>>> vcpu_end_shutdown_deferral(), so the issue may be that we shouldn't call >>>>>>> handle_pio() (etc) at all anymore in this state. IOW perhaps >>>>>>> hvm_wait_for_io() should return "!sv->vcpu->domain->is_shutting_down" >>>>>>> instead of plain "true"? >>>>>>> >>>>>>> Adding Paul to Cc, as being the maintainer here. >>>>>> >>>>>> Got it, by sticking BUG() just before that domain_crash() in >>>>>> handle_pio(). And also vcpu 0 of both HVM domains do have >>>>>> v->defer_shutdown. >>>>> >>>>> As per the log they did get it set. I'd be curious of the flag's >>>>> value (as well as v->paused_for_shutdown's) at the point of the >>>>> problematic handle_pio() invocation (see below). It may be >>>>> worthwhile to instrument vcpu_check_shutdown() (inside its if()) >>>>> - before exiting to guest context (in order to then come back >>>>> and call handle_pio()) the vCPU ought to be getting through >>>>> there. No indication of it doing so would be a sign that there's >>>>> a code path bypassing the call to vcpu_end_shutdown_deferral(). >>>>> >>>>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. >>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 >>>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 >>>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 >>>>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done >>>>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. >>>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 >>>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 >>>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 >>>>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done >>>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 >>>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 >>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>> >>>>> Perhaps in this message could you also log >>>>> v->domain->is_shutting_down, v->defer_shutdown, and >>>>> v->paused_for_shutdown? (Would be nice if, after having made >>>>> changes to your debugging patch, you could point again at the >>>>> precise version you've used for the log provided.) >>>>> >>>>>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff >>>>>> (XEN) Xen BUG at io.c:178 >>>>> >>>>> Btw, instead of BUG(), WARN() or dump_execution_state() would >>>>> likely also do, keeping Xen alive. >>>>> >>>> >>>> A shutdown deferral problem would result in X86EMUL_RETRY wouldn't it? That would mean we wouldn't >> be >>>> seeing the "Unexpected PIO" message. From that message this clearly X86EMUL_UNHANDLEABLE which >>>> suggests a race with ioreq server teardown, possibly due to selecting a server but then not finding >> a >>>> vcpu match in ioreq_vcpu_list. >>> >>> Actually looking at remote_shutdown... the test of ( reason == SHUTDOWN_crash ) and then clearing >> defer_shutdown looks a bit odd... Just because the domain shutdown code has been set that way doesn't >> mean that a vcpu is not deferred in emulation; SCHEDOP_shutdown_code could easily be called from one >> vcpu whilst another has emulation pending. >> >> I'm confused: The deferral is of shutting down the domain, not of >> a specific instance of emulation. > > Now I'm confused... defer_shutdown is per-vcpu. Right - each vCPU can individually defer shutting down of the domain as a whole. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:49:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:49:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCir-0004r8-Ti; Fri, 05 Jun 2020 13:49:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCiq-0004r3-Sy for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:49:24 +0000 X-Inumbo-ID: 5cf790cc-a733-11ea-96fb-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5cf790cc-a733-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 13:49:23 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id l11so9865732wru.0 for ; Fri, 05 Jun 2020 06:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=TZWht2QEs3VHPVD/IrikhqIxLcp+rePXTcEcxVD3Rjo=; b=J+Yk+9uhOQnz7+gJW88Hz41IY8yo6cs66MaGIm0smx+USDD0nWvU9GcbXqV4Gzv9mp CmhAqZYl8NUM1ogMqboL5MAL73xcKGdbBl4Q+8WmLo1/8cw6WTyrmwHM7C/n82gnYglu qXjsDgR7SLqB2Wdqvdskd7J1ELfeKmbmbgfQbHqlNUgcJ+p/E6CJd1NrhBNKEwxTBC9b HZ2WwfX4L+t9E/HCXB+SiSTTydZ0EauifUP7i0Mq3GdTu16CWuTI0aGauvEq2huEHjyK pSz3gbOTmSK2l+f22nuKmCaVXIjrMVN5LMa/DM6bXtpkhhEtkXuJMFKEYBggOEoPhOW4 3IIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=TZWht2QEs3VHPVD/IrikhqIxLcp+rePXTcEcxVD3Rjo=; b=FAeJHQOLHqdZ6K5T8Y7XARlqQSE5VgYNf3RSWXpf1HtvFKVT0V4TkNHWlzRMRdBkYt c1uC48faffiQZuZFtMNLW11X1/E/C8Y1Lmc1YopfrBr/JaNCaegeIPmohH75M7H6XSnp vizRt4WStRuKOhzJjeNZ36x3r+a9UH8DjfnVtdWdAvy4Bs+gnaoywuHFwZTA36P5DeII L9jAkJ2z90AWNcdz+Uk/h8i5uXQL2/SUC2jDPe3ab4EryW+al3Dqg7J5erIXw0bOaaGh 2fGf3CoeDMh8dSUZTI136m/zTTtid6wM7Whp+vcy4SzDJdCvCHoxLif6UamG2gdi3D00 7oHg== X-Gm-Message-State: AOAM532BK+mZ119qgt/qGWiilnIOBX4hnv/S0CLCDS6Vxj0dX4wRcMHg PbAbAtGeTPiRkp5wflNVAwM= X-Google-Smtp-Source: ABdhPJwSngufvIGYI55ZzhY6tDSOCFgCj+SO2trMZP4sB/z5cUDCmgaXDQ+b9h77Q3Rti5wm3bW+jQ== X-Received: by 2002:a5d:6a03:: with SMTP id m3mr9652834wru.293.1591364962881; Fri, 05 Jun 2020 06:49:22 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id s7sm12597826wrr.60.2020.06.05.06.49.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 06:49:22 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <000701d63b2c$10536930$30fa3b90$@xen.org> <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> <002101d63b3f$4e9dc830$ebd95890$@xen.org> In-Reply-To: Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 14:49:21 +0100 Message-ID: <002201d63b40$1e135ee0$5a3a1ca0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoACJ30jDAXuEodcCsFgQ5AHivRJwAUZxxQAClbGaTgD0KkheAp3cNn8CbNqNYgH2h+l1qJzUAlA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 05 June 2020 14:47 > To: paul@xen.org > Cc: 'Marek Marczykowski-G=C3=B3recki' = ; 'Andrew Cooper' > ; 'xen-devel' = > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On 05.06.2020 15:43, Paul Durrant wrote: > >> -----Original Message----- > >> From: Jan Beulich > >> Sent: 05 June 2020 14:37 > >> To: paul@xen.org > >> Cc: 'Marek Marczykowski-G=C3=B3recki' = ; 'Andrew Cooper' > >> ; 'xen-devel' = > >> Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > >> > >> On 05.06.2020 13:25, Paul Durrant wrote: > >>>> -----Original Message----- > >>>> From: Paul Durrant > >>>> Sent: 05 June 2020 12:06 > >>>> To: 'Jan Beulich' ; 'Marek = Marczykowski-G=C3=B3recki' > >> > >>>> Cc: 'Andrew Cooper' ; 'xen-devel' = > >>>> Subject: RE: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > >>>> > >>>> Sorry, only just catching up with this... > >>>> > >>>>> -----Original Message----- > >>>>> From: Jan Beulich > >>>>> Sent: 05 June 2020 10:09 > >>>>> To: Marek Marczykowski-G=C3=B3recki = > >>>>> Cc: Andrew Cooper ; xen-devel = ; Paul > >>>>> Durrant > >>>>> Subject: Re: handle_pio looping during domain shutdown, with = qemu 4.2.0 in stubdom > >>>>> > >>>>> On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > >>>>>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: > >>>>>>> On 04.06.2020 13:13, Andrew Cooper wrote: > >>>>>>>> On 04/06/2020 08:08, Jan Beulich wrote: > >>>>>>>>> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > >>>>>>>>>> Then, we get the main issue: > >>>>>>>>>> > >>>>>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > >>>>>>>>>> (XEN) domain_crash called from io.c:178 > >>>>>>>>>> > >>>>>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 = nor its stubdom > >>>>>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called = already. > >>>>>>>>> I'd guess an issue with the shutdown deferral logic. Did you = / can > >>>>>>>>> you check whether XEN_DMOP_remote_shutdown managed to pause = all > >>>>>>>>> CPUs (I assume it didn't, since once they're paused there = shouldn't > >>>>>>>>> be any I/O there anymore, and hence no I/O emulation)? > >>>>>>>> > >>>>>>>> The vcpu in question is talking to Qemu, so will have = v->defer_shutdown > >>>>>>>> intermittently set, and skip the pause in domain_shutdown() > >>>>>>>> > >>>>>>>> I presume this lack of pause is to allow the vcpu in question = to still > >>>>>>>> be scheduled to consume the IOREQ reply? (Its fairly opaque = logic with > >>>>>>>> 0 clarifying details). > >>>>>>>> > >>>>>>>> What *should* happen is that, after consuming the reply, the = vcpu should > >>>>>>>> notice and pause itself, at which point it would yield to the > >>>>>>>> scheduler. This is the purpose of = vcpu_{start,end}_shutdown_deferral(). > >>>>>>>> > >>>>>>>> Evidentially, this is not happening. > >>>>>>> > >>>>>>> We can't tell yet, until ... > >>>>>>> > >>>>>>>> Marek: can you add a BUG() after the weird PIO printing? = That should > >>>>>>>> confirm whether we're getting into handle_pio() via the > >>>>>>>> handle_hvm_io_completion() path, or via the vmexit path (at = which case, > >>>>>>>> we're fully re-entering the guest). > >>>>>>> > >>>>>>> ... we know this. handle_pio() gets called from = handle_hvm_io_completion() > >>>>>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> > >>>>>>> vcpu_end_shutdown_deferral(), so the issue may be that we = shouldn't call > >>>>>>> handle_pio() (etc) at all anymore in this state. IOW perhaps > >>>>>>> hvm_wait_for_io() should return = "!sv->vcpu->domain->is_shutting_down" > >>>>>>> instead of plain "true"? > >>>>>>> > >>>>>>> Adding Paul to Cc, as being the maintainer here. > >>>>>> > >>>>>> Got it, by sticking BUG() just before that domain_crash() in > >>>>>> handle_pio(). And also vcpu 0 of both HVM domains do have > >>>>>> v->defer_shutdown. > >>>>> > >>>>> As per the log they did get it set. I'd be curious of the flag's > >>>>> value (as well as v->paused_for_shutdown's) at the point of the > >>>>> problematic handle_pio() invocation (see below). It may be > >>>>> worthwhile to instrument vcpu_check_shutdown() (inside its if()) > >>>>> - before exiting to guest context (in order to then come back > >>>>> and call handle_pio()) the vCPU ought to be getting through > >>>>> there. No indication of it doing so would be a sign that there's > >>>>> a code path bypassing the call to vcpu_end_shutdown_deferral(). > >>>>> > >>>>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > >>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > >>>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > >>>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > >>>>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > >>>>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > >>>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >>>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >>>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > >>>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > >>>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > >>>>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > >>>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags = 0x2 d6 > >>>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags = 0x2 d6 > >>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>> > >>>>> Perhaps in this message could you also log > >>>>> v->domain->is_shutting_down, v->defer_shutdown, and > >>>>> v->paused_for_shutdown? (Would be nice if, after having made > >>>>> changes to your debugging patch, you could point again at the > >>>>> precise version you've used for the log provided.) > >>>>> > >>>>>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff > >>>>>> (XEN) Xen BUG at io.c:178 > >>>>> > >>>>> Btw, instead of BUG(), WARN() or dump_execution_state() would > >>>>> likely also do, keeping Xen alive. > >>>>> > >>>> > >>>> A shutdown deferral problem would result in X86EMUL_RETRY = wouldn't it? That would mean we > wouldn't > >> be > >>>> seeing the "Unexpected PIO" message. From that message this = clearly X86EMUL_UNHANDLEABLE which > >>>> suggests a race with ioreq server teardown, possibly due to = selecting a server but then not > finding > >> a > >>>> vcpu match in ioreq_vcpu_list. > >>> > >>> Actually looking at remote_shutdown... the test of ( reason =3D=3D = SHUTDOWN_crash ) and then clearing > >> defer_shutdown looks a bit odd... Just because the domain shutdown = code has been set that way > doesn't > >> mean that a vcpu is not deferred in emulation; = SCHEDOP_shutdown_code could easily be called from > one > >> vcpu whilst another has emulation pending. > >> > >> I'm confused: The deferral is of shutting down the domain, not of > >> a specific instance of emulation. > > > > Now I'm confused... defer_shutdown is per-vcpu. >=20 > Right - each vCPU can individually defer shutting down of the domain > as a whole. >=20 Ok, I think we're only going to make more progress if we know exactly = where the X86EMUL_UNHANDLEABLE is coming from. Paul From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:57:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:57:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCqa-0005rg-RO; Fri, 05 Jun 2020 13:57:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCqZ-0005rb-4k for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:57:23 +0000 X-Inumbo-ID: 79d43866-a734-11ea-9ad7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 79d43866-a734-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 13:57:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 1569CAC51; Fri, 5 Jun 2020 13:57:24 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: paul@xen.org, =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <002001d63b3e$7c268a40$74739ec0$@xen.org> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 15:57:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <002001d63b3e$7c268a40$74739ec0$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 15:37, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 05 June 2020 14:32 >> To: paul@xen.org >> Cc: 'Marek Marczykowski-Górecki' ; 'Andrew Cooper' >> ; 'xen-devel' >> Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom >> >> On 05.06.2020 13:05, Paul Durrant wrote: >>> Sorry, only just catching up with this... >>> >>>> -----Original Message----- >>>> From: Jan Beulich >>>> Sent: 05 June 2020 10:09 >>>> To: Marek Marczykowski-Górecki >>>> Cc: Andrew Cooper ; xen-devel ; Paul >>>> Durrant >>>> Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom >>>> >>>> On 04.06.2020 16:25, Marek Marczykowski-Górecki wrote: >>>>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: >>>>>> On 04.06.2020 13:13, Andrew Cooper wrote: >>>>>>> On 04/06/2020 08:08, Jan Beulich wrote: >>>>>>>> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: >>>>>>>>> Then, we get the main issue: >>>>>>>>> >>>>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff >>>>>>>>> (XEN) domain_crash called from io.c:178 >>>>>>>>> >>>>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor its stubdom >>>>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called already. >>>>>>>> I'd guess an issue with the shutdown deferral logic. Did you / can >>>>>>>> you check whether XEN_DMOP_remote_shutdown managed to pause all >>>>>>>> CPUs (I assume it didn't, since once they're paused there shouldn't >>>>>>>> be any I/O there anymore, and hence no I/O emulation)? >>>>>>> >>>>>>> The vcpu in question is talking to Qemu, so will have v->defer_shutdown >>>>>>> intermittently set, and skip the pause in domain_shutdown() >>>>>>> >>>>>>> I presume this lack of pause is to allow the vcpu in question to still >>>>>>> be scheduled to consume the IOREQ reply? (Its fairly opaque logic with >>>>>>> 0 clarifying details). >>>>>>> >>>>>>> What *should* happen is that, after consuming the reply, the vcpu should >>>>>>> notice and pause itself, at which point it would yield to the >>>>>>> scheduler. This is the purpose of vcpu_{start,end}_shutdown_deferral(). >>>>>>> >>>>>>> Evidentially, this is not happening. >>>>>> >>>>>> We can't tell yet, until ... >>>>>> >>>>>>> Marek: can you add a BUG() after the weird PIO printing? That should >>>>>>> confirm whether we're getting into handle_pio() via the >>>>>>> handle_hvm_io_completion() path, or via the vmexit path (at which case, >>>>>>> we're fully re-entering the guest). >>>>>> >>>>>> ... we know this. handle_pio() gets called from handle_hvm_io_completion() >>>>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> >>>>>> vcpu_end_shutdown_deferral(), so the issue may be that we shouldn't call >>>>>> handle_pio() (etc) at all anymore in this state. IOW perhaps >>>>>> hvm_wait_for_io() should return "!sv->vcpu->domain->is_shutting_down" >>>>>> instead of plain "true"? >>>>>> >>>>>> Adding Paul to Cc, as being the maintainer here. >>>>> >>>>> Got it, by sticking BUG() just before that domain_crash() in >>>>> handle_pio(). And also vcpu 0 of both HVM domains do have >>>>> v->defer_shutdown. >>>> >>>> As per the log they did get it set. I'd be curious of the flag's >>>> value (as well as v->paused_for_shutdown's) at the point of the >>>> problematic handle_pio() invocation (see below). It may be >>>> worthwhile to instrument vcpu_check_shutdown() (inside its if()) >>>> - before exiting to guest context (in order to then come back >>>> and call handle_pio()) the vCPU ought to be getting through >>>> there. No indication of it doing so would be a sign that there's >>>> a code path bypassing the call to vcpu_end_shutdown_deferral(). >>>> >>>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 >>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 >>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 >>>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done >>>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. >>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 >>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 >>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 >>>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done >>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 >>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>> >>>> Perhaps in this message could you also log >>>> v->domain->is_shutting_down, v->defer_shutdown, and >>>> v->paused_for_shutdown? (Would be nice if, after having made >>>> changes to your debugging patch, you could point again at the >>>> precise version you've used for the log provided.) >>>> >>>>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff >>>>> (XEN) Xen BUG at io.c:178 >>>> >>>> Btw, instead of BUG(), WARN() or dump_execution_state() would >>>> likely also do, keeping Xen alive. >>>> >>> >>> A shutdown deferral problem would result in X86EMUL_RETRY wouldn't it? >> >> Where would this originate? > > I was referring to the 'if ( unlikely(!vcpu_start_shutdown_deferral(curr)) )' at the top of hvm_send_ioreq(). Ah yes. But this is just one way of things possibly going wrong. Plus the function will return true when ->defer_shutdown is already or (wrongly) still set. >>> That would mean we wouldn't be seeing the "Unexpected PIO" message. From that message this clearly >> X86EMUL_UNHANDLEABLE which suggests a race with ioreq server teardown, possibly due to selecting a >> server but then not finding a vcpu match in ioreq_vcpu_list. >> >> I was suspecting such, but at least the tearing down of all servers >> happens only from relinquish-resources, which gets started only >> after ->is_shut_down got set (unless the tool stack invoked >> XEN_DOMCTL_destroydomain without having observed XEN_DOMINF_shutdown >> set for the domain). >> >> For individually unregistered servers - yes, if qemu did so, this >> would be a problem. They need to remain registered until all vCPU-s >> in the domain got paused. > > It shouldn't be a problem should it? Destroying an individual server is only done with the domain paused, so no vcpus can be running at the time. Consider the case of one getting destroyed after it has already returned data, but the originating vCPU didn't consume that data yet. Once that vCPU gets unpaused, handle_hvm_io_completion() won't find the matching server anymore, and hence the chain hvm_wait_for_io() -> hvm_io_assist() -> vcpu_end_shutdown_deferral() would be skipped. handle_pio() would then still correctly consume the result. Marek - to verify this doesn't happen (sorry, my qemu knowledge is rather limited, and hence I don't know whether this can happen at all), could you also log hvm_destroy_ioreq_server() invocations? Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:58:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:58:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCrP-0005vr-6i; Fri, 05 Jun 2020 13:58:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCrO-0005vj-6L for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:58:14 +0000 X-Inumbo-ID: 984c2308-a734-11ea-9ad7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 984c2308-a734-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 13:58:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/mnqHqKv+Cftb7THvAAGD2jsO4nJaI/6+JFDknUMtPQ=; b=mEhCOTtEX3igIErTayI1kXZOK cSj91FtfShbOwz0YoPBUsGDvikH+6AW6U0sFHyR9KgOlt0xc5JfVP46dj7yd51b6iRaaQmH99rHzJ 8SWkaoK0TACdCrB8LUnOSu7IKn8mO6O7LgPw//YxunX+yVdCrnD+j8ei10JlCe65Th2f4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCrM-0006RU-3P; Fri, 05 Jun 2020 13:58:12 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhCrL-00066G-Ob; Fri, 05 Jun 2020 13:58:11 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhCrL-00085X-O0; Fri, 05 Jun 2020 13:58:11 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150825: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Fri, 05 Jun 2020 13:58:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150825 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150825/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 7 days Failing since 150465 2020-05-29 09:02:14 Z 7 days 52 attempts Testing same since 150708 2020-06-04 21:07:16 Z 0 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1546 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 05 13:59:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 13:59:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCsx-00064k-J4; Fri, 05 Jun 2020 13:59:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhCsw-00064C-Io for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 13:59:50 +0000 X-Inumbo-ID: d2373990-a734-11ea-9ad7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d2373990-a734-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 13:59:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8FB34AAE8; Fri, 5 Jun 2020 13:59:52 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= References: <20200604014621.GA203658@mail-itl> <20200605111840.GE98582@mail-itl> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 15:59:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200605111840.GE98582@mail-itl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 13:18, Marek Marczykowski-Górecki wrote: > On Fri, Jun 05, 2020 at 11:38:17AM +0200, Jan Beulich wrote: >> On 04.06.2020 03:46, Marek Marczykowski-Górecki wrote: >>> Hi, >>> >>> (continuation of a thread from #xendevel) >>> >>> During system shutdown quite often I hit infinite stream of errors like >>> this: >>> >>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff >>> (XEN) domain_crash called from io.c:178 >>> >>> This is all running on Xen 4.13.0 (I think I've got this with 4.13.1 >>> too), nested within KVM. The KVM part means everything is very slow, so >>> various race conditions are much more likely to happen. >>> >>> It started happening not long ago, and I'm pretty sure it's about >>> updating to qemu 4.2.0 (in linux stubdom), previous one was 3.0.0. >>> >>> Thanks to Andrew and Roger, I've managed to collect more info. >>> >>> Context: >>> dom0: pv >>> dom1: hvm >>> dom2: stubdom for dom1 >>> dom3: hvm >>> dom4: stubdom for dom3 >>> dom5: pvh >>> dom6: pvh >>> >>> It starts I think ok: >>> >>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 >>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 >>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 >> >> I can't seem to be able to spot the call site of this, in any of >> qemu, libxl, or libxc. I'm in particular curious as to the further >> actions taken on the domain after this was invoked: Do any ioreq >> servers get unregistered immediately (which I think would be a >> problem)? > > It is here: > https://github.com/qemu/qemu/blob/master/hw/i386/xen/xen-hvm.c#L1539 > > I think it's called from cpu_handle_ioreq(), and I think the request > state is set to STATE_IORESP_READY before exiting (unless there is some > exit() hidden in another function used there). Thanks. There's nothing in surrounding code there that would unregister an ioreq server. But as said elsewhere, I don't know qemu very well, and hence I may easily overlook how else one may get unregistered prematurely. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:13:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:13:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhD5x-00081G-Pe; Fri, 05 Jun 2020 14:13:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhD5w-00081A-31 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:13:16 +0000 X-Inumbo-ID: b19f33ca-a736-11ea-afc4-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b19f33ca-a736-11ea-afc4-12813bfff9fa; Fri, 05 Jun 2020 14:13:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8B515AE7B; Fri, 5 Jun 2020 14:13:16 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <20200605120137.GF98582@mail-itl> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 16:13:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200605120137.GF98582@mail-itl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , xen-devel , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 14:01, Marek Marczykowski-Górecki wrote: > On Fri, Jun 05, 2020 at 11:22:46AM +0200, Jan Beulich wrote: >> On 05.06.2020 11:09, Jan Beulich wrote: >>> On 04.06.2020 16:25, Marek Marczykowski-Górecki wrote: >>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 >>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 >>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 >>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done >>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. >>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 >>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 >>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 >>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 >>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done >>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 >>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 >>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 >>> >>> Perhaps in this message could you also log >>> v->domain->is_shutting_down, v->defer_shutdown, and >>> v->paused_for_shutdown? >> >> And v->domain->is_shut_down please. > > Here it is: > > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer_shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer_shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer_shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer_shutdown 0 paused_for_shutdown 0 is_shut_down 0 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > (XEN) grant_table.c:3702:d0v1 Grant release 0x3 ref 0x125 flags 0x2 d6 > (XEN) grant_table.c:3702:d0v1 Grant release 0x4 ref 0x126 flags 0x2 d6 > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 1 defer_shutdown 1 paused_for_shutdown 0 is_shut_down 0 To me this is a clear indication that we did exit to guest context with ->defer_shutdown set. What I'm missing from your debugging patch is logging when the default case of the first switch() in hvmemul_do_io() gets hit. I think I said yesterday that I consider this a fair candidate of where the X86EMUL_UNHANDLEABLE is coming from. On top of that, with what we've sort of learned today, could you log (or worse) any instances of handle_pio() getting called with ->defer_shutdown set? Afaict this should never happen, but you may hit this case earlier than for the call out of the VMEXIT handler, which would then move us closer to the root of the issue. With "(or worse)" I mean it could also be as heavy as BUG(), ... > Regarding BUG/WARN - do you think I could get any more info then? I > really don't mind crashing that system, it's a virtual machine > currently used only for debugging this issue. ... and the selection here really depends on what overall impact you expect. I.e. I'm with Andrew that BUG() may be the construct of choice if otherwise you get overly much output. In other cases it may allow you to hit the same case again, with perhaps slightly changed other state, giving further hints on where the issue starts. One thing that's not clear to me here: In the title you say handle_pio() loops, but with the domain getting crashed I can't seem to see that happening. Of course it may be a wrong understanding /interpretation of mine that it is the guest doing repeated I/O from/to port 0xb004. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:16:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:16:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhD9L-0008AG-8q; Fri, 05 Jun 2020 14:16:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhD9J-0008AB-8D for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:16:45 +0000 X-Inumbo-ID: 2ecd3158-a737-11ea-ba62-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2ecd3158-a737-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 14:16:44 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 5aYJuVd0ItXCeekg73oTrKrRbIC2fsTQKbzDPSjUo9qHoUtzPxyMgb0a32zP8Zjh6wg9uAnkJP sqI2qDQNYqB31TOwfFcfLidL/b0mjT4Ke1whiTLD+guSN3T/8hfEYCcQvpaOrPDiMp0QwKVFA8 ogic6dvIYKWb5O9LyX/RBGPbEpm3jiQqaEd2/KtnNTKOvgxH8ZX6CCnqYsV6bqtfbv4mTsBqil a9iwkHjlRr3vxm/P+EzPvmh8W0UNb+pQU78/yVdral8xdtpNfxXkEVZ+A6OLffpAcfQwbdKyde J0Y= X-SBRS: 2.7 X-MesageID: 19577620 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="scan'208";a="19577620" Date: Fri, 5 Jun 2020 16:16:36 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200605141636.GN1195@Air-de-Roger> References: <20200605075006.51238-1-roger.pau@citrix.com> <20200605092035.GL1195@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 12:05:12PM +0200, Jan Beulich wrote: > On 05.06.2020 11:20, Roger Pau Monné wrote: > > On Fri, Jun 05, 2020 at 10:48:48AM +0200, Jan Beulich wrote: > >> On 05.06.2020 09:50, Roger Pau Monne wrote: > >>> This patch provides such mediated access to the > >>> RTC for PVH dom0, just like it's provided for a classic PV dom0. > >>> > >>> Instead of re-using the PV paths implement such handler together with > >>> the vRTC code for HVM, so that calling rtc_init will setup the > >>> appropriate handlers for all HVM based guests. > >> > >> Hooking this into rtc_init() makes sense as long as it's really > >> just the RTC. Looking at the PV code you're cloning from, I > >> wonder though whether pv_pit_handler() should also regain callers > >> for PVH. As it stands the function is called for PV only, yet was > >> deliberately put/kept outside of pv/. > > > > IIRC pv_pit_handler was also used by PVHv1 dom0, but we decided to not > > enable it for PVHv2 because no one really knew why the PIT was > > actually needed for by dom0. > > I think the reason PV Dom0 has it applies to PVH Dom0 as well: > At least back at the time there were video BIOSes needing this. > As it now turns out to have been a mistake to not enable the > RTC handling for v2, I would still think it would be better to > enable the PIT logic as well there, just to be on the safe side. I have to admit I haven't used video output very much with PVH, I've had reports of people having success with it, but I have no idea how many failures there might be. Enabling the PIT for PVH dom0 is mostly a matter of adding XEN_X86_EMU_PIT to the emulation flags, like it's currently done for PV dom0. There's going to be a slight issue though, which is that the PIT will try to inject the interrupts using the PIC IRQ0, and thus would either need to also enable the PIC, or to instead set the timer source to PTSRC_ioapic instead of PTSRC_isa and use GSI 0. I haven't actually tried whether this would work, but seems better than enabling the PIC. Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:20:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:20:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDD1-0000gI-TF; Fri, 05 Jun 2020 14:20:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDD1-0000cI-9V for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:20:35 +0000 X-Inumbo-ID: b7f029e0-a737-11ea-9ad7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b7f029e0-a737-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 14:20:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AEAD6AECE; Fri, 5 Jun 2020 14:20:36 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200605075006.51238-1-roger.pau@citrix.com> <20200605092035.GL1195@Air-de-Roger> <20200605141636.GN1195@Air-de-Roger> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 16:20:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200605141636.GN1195@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 16:16, Roger Pau Monné wrote: > On Fri, Jun 05, 2020 at 12:05:12PM +0200, Jan Beulich wrote: >> On 05.06.2020 11:20, Roger Pau Monné wrote: >>> On Fri, Jun 05, 2020 at 10:48:48AM +0200, Jan Beulich wrote: >>>> On 05.06.2020 09:50, Roger Pau Monne wrote: >>>>> This patch provides such mediated access to the >>>>> RTC for PVH dom0, just like it's provided for a classic PV dom0. >>>>> >>>>> Instead of re-using the PV paths implement such handler together with >>>>> the vRTC code for HVM, so that calling rtc_init will setup the >>>>> appropriate handlers for all HVM based guests. >>>> >>>> Hooking this into rtc_init() makes sense as long as it's really >>>> just the RTC. Looking at the PV code you're cloning from, I >>>> wonder though whether pv_pit_handler() should also regain callers >>>> for PVH. As it stands the function is called for PV only, yet was >>>> deliberately put/kept outside of pv/. >>> >>> IIRC pv_pit_handler was also used by PVHv1 dom0, but we decided to not >>> enable it for PVHv2 because no one really knew why the PIT was >>> actually needed for by dom0. >> >> I think the reason PV Dom0 has it applies to PVH Dom0 as well: >> At least back at the time there were video BIOSes needing this. >> As it now turns out to have been a mistake to not enable the >> RTC handling for v2, I would still think it would be better to >> enable the PIT logic as well there, just to be on the safe side. > > I have to admit I haven't used video output very much with PVH, I've > had reports of people having success with it, but I have no idea how > many failures there might be. > > Enabling the PIT for PVH dom0 is mostly a matter of adding > XEN_X86_EMU_PIT to the emulation flags, like it's currently done for > PV dom0. > > There's going to be a slight issue though, which is that the PIT will > try to inject the interrupts using the PIC IRQ0, and thus would either > need to also enable the PIC, or to instead set the timer source to > PTSRC_ioapic instead of PTSRC_isa and use GSI 0. I haven't actually > tried whether this would work, but seems better than enabling the PIC. But what we do for PV Dom0 doesn't go as far as injecting IRQs (let alone IRQ0). It's just the few port accesses that we allow them to make (successfully, i.e. seeing the relevant bare hardware bits). Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:21:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:21:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDDr-0000kt-7A; Fri, 05 Jun 2020 14:21:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDDq-0000km-KT for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:21:26 +0000 X-Inumbo-ID: d2d8b2a4-a737-11ea-afc6-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d2d8b2a4-a737-11ea-afc6-12813bfff9fa; Fri, 05 Jun 2020 14:21:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AB6P83g3txLIjtOL81/eoLDkk6O0udHgxUD0SErj37Q=; b=MRauW1+IaOm5gbnny84lCa2zl Ibgj5x0yeqXApEbsY2u7kq8m09OwUqGhFVzG99giXRf9AZmgPVZH5LRkyygZPQqI9ntN5i5GEiQHj Zgv6JHaSHjDqyUv/RhXOYpTRgWug78f4pF8DlWztol7Sx9nSyoi5nSSp75VMKbDE+bfj8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDDi-000702-Oy; Fri, 05 Jun 2020 14:21:18 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhDDi-0006p1-HM; Fri, 05 Jun 2020 14:21:18 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhDDi-0005F8-Gn; Fri, 05 Jun 2020 14:21:18 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150814: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=435faf5c218a47fd6258187f62d9bb1009717896 X-Osstest-Versions-That: linux=f6aee505c71bbb035dde146caf5a6abbf3ccbe47 From: osstest service owner Date: Fri, 05 Jun 2020 14:21:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150814 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150814/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 150663 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150663 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150663 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150663 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150663 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150663 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150663 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150663 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150663 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150663 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: linux 435faf5c218a47fd6258187f62d9bb1009717896 baseline version: linux f6aee505c71bbb035dde146caf5a6abbf3ccbe47 Last test of basis 150663 2020-06-03 18:38:46 Z 1 days Failing since 150680 2020-06-04 06:12:40 Z 1 days 5 attempts Testing same since 150721 2020-06-05 04:43:51 Z 0 days 2 attempts ------------------------------------------------------------ 1108 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git f6aee505c71b..435faf5c218a 435faf5c218a47fd6258187f62d9bb1009717896 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:22:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:22:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDFD-0000rr-IQ; Fri, 05 Jun 2020 14:22:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDFC-0000rk-5s for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:22:50 +0000 X-Inumbo-ID: 087f11be-a738-11ea-96fb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 087f11be-a738-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 14:22:49 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C5F8AAB64; Fri, 5 Jun 2020 14:22:51 +0000 (UTC) From: Jan Beulich Subject: [PATCH v2] build: fix dependency tracking for preprocessed files To: "xen-devel@lists.xenproject.org" Message-ID: Date: Fri, 5 Jun 2020 16:22:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , Andrew Cooper , Ian Jackson , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" While the issue is more general, I noticed that asm-macros.i not getting re-generated as needed. This was due to its .*.d file mentioning asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds dependency tracking files. While there, further avoid open-coding $(CPP) and drop the bogus (Arm) / stale (x86) -Ui386. Signed-off-by: Jan Beulich --- v2: Move -MQ ahead on command lines. --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -201,13 +201,13 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) $(call if_changed,obj_init_o) quiet_cmd_cpp_i_c = CPP $@ -cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ +cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -MQ $@ -o $@ $< quiet_cmd_cc_s_c = CC $@ cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@ quiet_cmd_s_S = CPP $@ -cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@ +cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) -MQ $@ -o $@ $< %.i: %.c FORCE $(call if_changed,cpp_i_c) --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -123,9 +123,7 @@ asm-offsets.s: $(TARGET_SUBARCH)/asm-off $(CC) $(filter-out -flto,$(c_flags)) -S -o $@ $< xen.lds: xen.lds.S - $(CC) -P -E -Ui386 $(a_flags) -o $@ $< - sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new - mv -f .xen.lds.d.new .xen.lds.d + $(CPP) -P $(a_flags) -MQ $@ -o $@ $< dtb.o: $(CONFIG_DTB_FILE) --- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -244,9 +244,7 @@ $(BASEDIR)/include/asm-x86/asm-macros.h: efi.lds: AFLAGS-y += -DEFI xen.lds efi.lds: xen.lds.S - $(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $< - sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new - mv -f .$(@F).d.new .$(@F).d + $(CPP) -P $(filter-out -Wa$(comma)%,$(a_flags)) -MQ $@ -o $@ $< boot/mkelf32: boot/mkelf32.c $(HOSTCC) $(HOSTCFLAGS) -o $@ $< From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:24:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:24:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDHD-00010G-V4; Fri, 05 Jun 2020 14:24:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDHC-00010A-9j for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:24:54 +0000 X-Inumbo-ID: 5285b6fa-a738-11ea-afc6-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5285b6fa-a738-11ea-afc6-12813bfff9fa; Fri, 05 Jun 2020 14:24:53 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: RY+uxOVeYebOuMAokqH+tSQYKTML2T/3cbBs7cY3ALr6XzlIrpRV2LGJ/OreCAYExL7TTqrCVD c0PRoqriPfoSDUMFCNo0JY2uL0tmM1YYAFKBFaUWq+VA1kR4yGXMx8b85kcpv7OozUvmW/gAuN vfehKIFMpGWOt1LBL9XF7bCqU/I2YGb1nn7ApuLkHN/ATpYp2OUrnw07/evz326jh+kSlBse6o BM/oLn2KZGCrlCtOZt8SFUi9weZsg8CjPmtDxe1odoDb5d6EaNHRMNK6TCBboc43Sg0UfBYKD9 VVg= X-SBRS: 2.7 X-MesageID: 19680950 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="scan'208";a="19680950" Subject: Re: [PATCH v2] build: fix dependency tracking for preprocessed files To: Jan Beulich , "xen-devel@lists.xenproject.org" References: From: Andrew Cooper Message-ID: Date: Fri, 5 Jun 2020 15:24:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , Ian Jackson , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05/06/2020 15:22, Jan Beulich wrote: > While the issue is more general, I noticed that asm-macros.i not getting > re-generated as needed. This was due to its .*.d file mentioning > asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at > it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds > dependency tracking files. While there, further avoid open-coding $(CPP) > and drop the bogus (Arm) / stale (x86) -Ui386. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:44:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:44:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDaK-0002y9-L0; Fri, 05 Jun 2020 14:44:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDaJ-0002y2-G7 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:44:39 +0000 X-Inumbo-ID: 1485d382-a73b-11ea-ba62-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1485d382-a73b-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 14:44:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8CB4FAD35; Fri, 5 Jun 2020 14:44:40 +0000 (UTC) Subject: Re: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC for PVH dom0 To: Roger Pau Monne References: <20200605110240.52545-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: Date: Fri, 5 Jun 2020 16:44:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200605110240.52545-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 13:02, Roger Pau Monne wrote: > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > code paths (guest_io_{write/read}), but those accesses where never > implemented for PVHv2 dom0. This patch provides such mediated accesses > to the RTC for PVH dom0, just like it's provided for a classic PV > dom0. > > Pull out some of the RTC logic from guest_io_{read/write} into > specific helpers that can be used by both PV and HVM guests. The > setup of the handlers for PVH is done in rtc_init, which is already > used to initialize the fully emulated RTC. > > Without this a Linux PVH dom0 will read garbage when trying to access > the RTC, and one vCPU will be constantly looping in > rtc_timer_do_work. > > Note that such issue doesn't happen on domUs because the ACPI > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > accesses are not emulated but rather forwarded to the physical > hardware. > > No functional change expected for classic PV dom0. But there is, in whether (virtual) port 0x71 can be read/written (even by a DomU). I'm afraid of being called guilty in splitting hair, though. > @@ -808,10 +809,43 @@ void rtc_reset(struct domain *d) > s->pt.source = PTSRC_isa; > } > > +/* RTC mediator for HVM hardware domain. */ > +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, > + uint32_t *val) > +{ > + if ( dir == IOREQ_READ ) > + *val = ~0; > + > + if ( size != 1 ) > + { > + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); > + return X86EMUL_OKAY; > + } > + if ( !ioports_access_permitted(current->domain, port, port) ) This wants to move into the helper, such that the PV side can have it moved too. > void rtc_init(struct domain *d) > { > RTCState *s = domain_vrtc(d); > > + if ( is_hardware_domain(d) ) > + { > + /* Hardware domain gets mediated access to the physical RTC. */ > + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); > + return; Any reason for this explicit return, rather than ... > + } > + > if ( !has_vrtc(d) ) > return; ... making use of this one? In fact wouldn't it be more correct to have if ( !has_vrtc(d) ) { /* Hardware domain gets mediated access to the physical RTC. */ if ( is_hardware_domain(d) ) register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); return; } such that eventual (perhaps optional) enabling of vRTC for hwdom would have it properly work without changing this function again? > --- a/xen/arch/x86/pv/emul-priv-op.c > +++ b/xen/arch/x86/pv/emul-priv-op.c > @@ -280,19 +280,10 @@ static uint32_t guest_io_read(unsigned int port, unsigned int bytes, > { > sub_data = pv_pit_handler(port, 0, 0); > } > - else if ( port == RTC_PORT(0) ) > - { > - sub_data = currd->arch.cmos_idx; Note how there was no permission check here. Having one or more I/O ports that can be used to simply latch a value can, as I've learned, be quite valuable as a debugging vehicle, and there aren't many (if any) ports beyond this one that a PV DomU might use for such a purpose. Arguably the value is somewhat limited here, as the value wouldn't survive a crash, but I'd still prefer if we could retain prior functionality. > @@ -1110,6 +1111,64 @@ static unsigned long get_cmos_time(void) > return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); > } > > +/* Helpers for guest accesses to the physical RTC. */ > +unsigned int rtc_guest_read(unsigned int port) > +{ > + const struct domain *currd = current->domain; > + unsigned long flags; > + unsigned int data = ~0; > + > + ASSERT(port == RTC_PORT(0) || port == RTC_PORT(1)); Instead of this, how about ... > + if ( !ioports_access_permitted(currd, port, port) ) > + { > + ASSERT_UNREACHABLE(); > + return data; > + } > + > + switch ( port ) > + { > + case RTC_PORT(0): > + data = currd->arch.cmos_idx; > + break; > + > + case RTC_PORT(1): > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + data = inb(RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; default: ASSERT_UNREACHABLE(); break; ? Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:45:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:45:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDbI-00032X-VQ; Fri, 05 Jun 2020 14:45:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDbI-00032R-2X for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:45:40 +0000 X-Inumbo-ID: 38a70fec-a73b-11ea-afcd-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 38a70fec-a73b-11ea-afcd-12813bfff9fa; Fri, 05 Jun 2020 14:45:39 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: UgrqgOez7v2EXTEQxy28GZvY9TSuiRmy9Smd+fix2LaU+ZwKYBv6pjGvlcehD/zpDRdOAy5erW /vHFaXAtrHV92LbmJtnRytpaqV9K/Eq5xPnXGwZlN0Vmxgij4zfngZStrK4l8NuicTmea5KmgY d2hZl6LL7iSYAf5SAAID6t14Q4dHH9BXLMqQjQInZ9Bq3VIClayHclRKTG1fYAHGJbiLNSdmKU CmiG9TG2DGaO9Zvlh+FtNmjcAqHG+30l0aGz5+9aAjHAqaHsvZiDBMyjg2zGQgdE1WBHaemFeg z0o= X-SBRS: 2.7 X-MesageID: 19331730 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="scan'208";a="19331730" Date: Fri, 5 Jun 2020 16:45:28 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200605144528.GA660@Air-de-Roger> References: <20200605075006.51238-1-roger.pau@citrix.com> <20200605092035.GL1195@Air-de-Roger> <20200605141636.GN1195@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 04:20:31PM +0200, Jan Beulich wrote: > On 05.06.2020 16:16, Roger Pau Monné wrote: > > On Fri, Jun 05, 2020 at 12:05:12PM +0200, Jan Beulich wrote: > >> On 05.06.2020 11:20, Roger Pau Monné wrote: > >>> On Fri, Jun 05, 2020 at 10:48:48AM +0200, Jan Beulich wrote: > >>>> On 05.06.2020 09:50, Roger Pau Monne wrote: > >>>>> This patch provides such mediated access to the > >>>>> RTC for PVH dom0, just like it's provided for a classic PV dom0. > >>>>> > >>>>> Instead of re-using the PV paths implement such handler together with > >>>>> the vRTC code for HVM, so that calling rtc_init will setup the > >>>>> appropriate handlers for all HVM based guests. > >>>> > >>>> Hooking this into rtc_init() makes sense as long as it's really > >>>> just the RTC. Looking at the PV code you're cloning from, I > >>>> wonder though whether pv_pit_handler() should also regain callers > >>>> for PVH. As it stands the function is called for PV only, yet was > >>>> deliberately put/kept outside of pv/. > >>> > >>> IIRC pv_pit_handler was also used by PVHv1 dom0, but we decided to not > >>> enable it for PVHv2 because no one really knew why the PIT was > >>> actually needed for by dom0. > >> > >> I think the reason PV Dom0 has it applies to PVH Dom0 as well: > >> At least back at the time there were video BIOSes needing this. > >> As it now turns out to have been a mistake to not enable the > >> RTC handling for v2, I would still think it would be better to > >> enable the PIT logic as well there, just to be on the safe side. > > > > I have to admit I haven't used video output very much with PVH, I've > > had reports of people having success with it, but I have no idea how > > many failures there might be. > > > > Enabling the PIT for PVH dom0 is mostly a matter of adding > > XEN_X86_EMU_PIT to the emulation flags, like it's currently done for > > PV dom0. > > > > There's going to be a slight issue though, which is that the PIT will > > try to inject the interrupts using the PIC IRQ0, and thus would either > > need to also enable the PIC, or to instead set the timer source to > > PTSRC_ioapic instead of PTSRC_isa and use GSI 0. I haven't actually > > tried whether this would work, but seems better than enabling the PIC. > > But what we do for PV Dom0 doesn't go as far as injecting IRQs (let > alone IRQ0). It's just the few port accesses that we allow them to > make (successfully, i.e. seeing the relevant bare hardware bits). It seems cleaner to me to just provide the whole thing for PVH, rather than what we do for classic PV, in which we allow some accesses to the real hardware. I understand there's no need to give dom0 access to the real PIC, and that using the emulated one should work just fine. Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:53:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:53:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDil-000449-KR; Fri, 05 Jun 2020 14:53:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDik-000444-Nq for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:53:22 +0000 X-Inumbo-ID: 4cc963ac-a73c-11ea-9b55-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4cc963ac-a73c-11ea-9b55-bc764e2007e4; Fri, 05 Jun 2020 14:53:22 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: eIVApgBF8PgEw2iFJ0D2xauKhB4RMo0z18V+Ix6TYhXHvZCwmT+r4C8OSXIlEW0hWkw7TGMZCw EYtn8axQBI9YO0YviccxhAIKHkK3I98JSp2MsI8iz7e21NiFy65pz2Gd//BDE8dmlB0ela+djT 5C3zvSHLb/Jhb8u75/rxnXxLbVJm61GKBIOpgllBWSGC/EWdZb+jpIDP4xMBGyZUNE1arKse8M TJgJaA1oXY5w+0LNMHJIPPpcY4GVFhnjO4ecF6inzCaLoepJ5cWSQE2kMqbg5x3Xy3ogNd0K/R hCU= X-SBRS: 2.7 X-MesageID: 20088160 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="scan'208";a="20088160" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <24282.23645.278335.309673@mariner.uk.xensource.com> Date: Fri, 5 Jun 2020 15:53:17 +0100 To: "paul@xen.org" Subject: RE: [PATCH for-4.14] libs/hypfs: use correct zlib name in pc file In-Reply-To: <000901d63b30$9ae387c0$d0aa9740$@xen.org> References: <20200605113725.30982-1-wl@xen.org> <034b6887-640e-a051-3821-00ef7615e010@suse.com> <000901d63b30$9ae387c0$d0aa9740$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?iso-8859-1?Q?'J=FCrgen_Gro=DF'?= , 'Xen Development List' , 'Olaf Hering' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: [PATCH for-4.14] libs/hypfs: use correct zlib name in pc file"): > > -----Original Message----- > > From: Jrgen Gro > > Sent: 05 June 2020 12:43 > > To: Wei Liu ; Xen Development List > > Cc: Olaf Hering ; paul@xen.org; Ian Jackson > > Subject: Re: [PATCH for-4.14] libs/hypfs: use correct zlib name in pc file > > > > On 05.06.20 13:37, Wei Liu wrote: > > > Its name is "zlib" not "z". > > > > > > Reported-by: Olaf Hering > > > Fixes: 86234eafb952 ("libs: add libxenhypfs") > > > Signed-off-by: Wei Liu > > > > Reviewed-by: Juergen Gross > > > > Release-acked-by: Paul Durrant Thanks all. Committed. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 14:54:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 14:54:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDkB-00049Z-Vj; Fri, 05 Jun 2020 14:54:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDkA-00049P-LT for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 14:54:50 +0000 X-Inumbo-ID: 80eaccf2-a73c-11ea-9b55-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 80eaccf2-a73c-11ea-9b55-bc764e2007e4; Fri, 05 Jun 2020 14:54:49 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: xMF6ONnsvuGDgfTrGR3onGFb2dEtP6Is4PLLBJDnhH/f21UoVhdi1W1JDiSkoj3IQBDDIYUWFO /4KUqZynHp3pgIcHyEa5G9xa6FeXj28mhGTCcz4ecVjEYeh+PN6KGfqMg10DzeT7aJCSaJUEbm wtzGttxmOdubgkNBi5hqPWTsIdtX1aFfmILqMLrG8r75NGY8FxA+B8pwF9VBSf/tY4AebXNTcl BM/ezMA4OLRTfewpaVtSgFKVprIHPZtbh5JuymP+lQdSPJgYh1ZC/lECyICStw0xC8qlFsCpdz WS0= X-SBRS: 2.7 X-MesageID: 19352124 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="scan'208";a="19352124" Date: Fri, 5 Jun 2020 16:54:42 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200605145442.GB660@Air-de-Roger> References: <20200605075006.51238-1-roger.pau@citrix.com> <20200605092035.GL1195@Air-de-Roger> <20200605141636.GN1195@Air-de-Roger> <20200605144528.GA660@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200605144528.GA660@Air-de-Roger> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, paul@xen.org, Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 04:45:28PM +0200, Roger Pau Monné wrote: > On Fri, Jun 05, 2020 at 04:20:31PM +0200, Jan Beulich wrote: > > On 05.06.2020 16:16, Roger Pau Monné wrote: > > > On Fri, Jun 05, 2020 at 12:05:12PM +0200, Jan Beulich wrote: > > >> On 05.06.2020 11:20, Roger Pau Monné wrote: > > >>> On Fri, Jun 05, 2020 at 10:48:48AM +0200, Jan Beulich wrote: > > >>>> On 05.06.2020 09:50, Roger Pau Monne wrote: > > >>>>> This patch provides such mediated access to the > > >>>>> RTC for PVH dom0, just like it's provided for a classic PV dom0. > > >>>>> > > >>>>> Instead of re-using the PV paths implement such handler together with > > >>>>> the vRTC code for HVM, so that calling rtc_init will setup the > > >>>>> appropriate handlers for all HVM based guests. > > >>>> > > >>>> Hooking this into rtc_init() makes sense as long as it's really > > >>>> just the RTC. Looking at the PV code you're cloning from, I > > >>>> wonder though whether pv_pit_handler() should also regain callers > > >>>> for PVH. As it stands the function is called for PV only, yet was > > >>>> deliberately put/kept outside of pv/. > > >>> > > >>> IIRC pv_pit_handler was also used by PVHv1 dom0, but we decided to not > > >>> enable it for PVHv2 because no one really knew why the PIT was > > >>> actually needed for by dom0. > > >> > > >> I think the reason PV Dom0 has it applies to PVH Dom0 as well: > > >> At least back at the time there were video BIOSes needing this. > > >> As it now turns out to have been a mistake to not enable the > > >> RTC handling for v2, I would still think it would be better to > > >> enable the PIT logic as well there, just to be on the safe side. > > > > > > I have to admit I haven't used video output very much with PVH, I've > > > had reports of people having success with it, but I have no idea how > > > many failures there might be. > > > > > > Enabling the PIT for PVH dom0 is mostly a matter of adding > > > XEN_X86_EMU_PIT to the emulation flags, like it's currently done for > > > PV dom0. > > > > > > There's going to be a slight issue though, which is that the PIT will > > > try to inject the interrupts using the PIC IRQ0, and thus would either > > > need to also enable the PIC, or to instead set the timer source to > > > PTSRC_ioapic instead of PTSRC_isa and use GSI 0. I haven't actually > > > tried whether this would work, but seems better than enabling the PIC. > > > > But what we do for PV Dom0 doesn't go as far as injecting IRQs (let > > alone IRQ0). It's just the few port accesses that we allow them to > > make (successfully, i.e. seeing the relevant bare hardware bits). > > It seems cleaner to me to just provide the whole thing for PVH, rather > than what we do for classic PV, in which we allow some accesses to the > real hardware. > > I understand there's no need to give dom0 access to the real PIC, and ^ PIT. > that using the emulated one should work just fine. > > Roger. > From xen-devel-bounces@lists.xenproject.org Fri Jun 05 15:06:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 15:06:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDv8-0005IZ-2D; Fri, 05 Jun 2020 15:06:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDv6-0005IU-3I for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 15:06:08 +0000 X-Inumbo-ID: 120253bc-a73e-11ea-9ad7-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 120253bc-a73e-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 15:06:02 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id k11so10473640ejr.9 for ; Fri, 05 Jun 2020 08:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JcnrW+4OtBFehwzMUvyDhu5hsC2RiI9k0jFaO/yViHM=; b=m1e3cxZy7634q/AXhXKti6gqoXLr4wS44BoZTvaAp/DdjGxiieEwW6IJZ8mLn5/+dU ZpQ/Fs2rvQ+o5z0vV9TYRrvoF6RUd4886rEVu40sQMtgZohf4OdnXiD35gXz1idzNPLb UqX1LQJE1PCpo4EZ5m1Sl9s7NcJ7qEAAa/Su0TlBCjn842xMwXFpbla5sJ0E6lXfG3en EA0Nz9JMQlJvcvmQzJHphqUZT79rYKVU4cm85C/5/hxIJJf1gewflOSIYNZLKGwgydJd Z8FI9e9nFmJjk51U6E5RTVupTJnfNV1iROUmKCWc5GBIGxYba6XmayTaEKlAbl8yI0yf gcDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JcnrW+4OtBFehwzMUvyDhu5hsC2RiI9k0jFaO/yViHM=; b=LhPQJt8WlJR9GMTTdMptEeW3wXua8V1Hvf9cALWDsVNCoiS588hacXtQGWledx6oyo EnSToWbaER1LWRSG3okPeAsbb/wX5P0zTM95wkNiONNfHqqVTVdDRWOO4D4eotv/7tI5 nSAnVp3WajhHXSqXqNeDSRlXjOCavB0ZoWnIAUgE13nKXjBakFHhOiBUJ3dfGwJEX3Pt eD32iJsank7BG+RwWxXARve4YJOM+WobnnOfNaiLKMtvcGg/N+wvr9kMbyNOOMPGW32S WcLtJwX3r8w7TlM2TjJZCsohxXde5/+vawUdevProLpyKoIUPxqyHiyGlap5feU/YjYN qC8Q== X-Gm-Message-State: AOAM533tAjWYO1LjLbDscLoC/KjiexfscpSlvAnFWe0eUC2R6r0YCDq0 zwqaY0vheLnsJFvy4BnnPtAbn0ZPWltPWBZ8pMk= X-Google-Smtp-Source: ABdhPJxMbXvAclte20t8Ns5/tDNTJ/QX2JoXQ2V0XkqUP8ugA9QCXVPG76LoVxVXBbH/EnzvxRAPP7hSaf+q5O96yPM= X-Received: by 2002:a17:906:4ecf:: with SMTP id i15mr9576364ejv.515.1591369561590; Fri, 05 Jun 2020 08:06:01 -0700 (PDT) MIME-Version: 1.0 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> In-Reply-To: <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> From: CodeWiz2280 Date: Fri, 5 Jun 2020 11:05:49 -0400 Message-ID: Subject: Re: Keystone Issue To: Bertrand Marquis Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 5, 2020 at 8:47 AM Bertrand Marquis wrote: > > > > > On 5 Jun 2020, at 13:42, CodeWiz2280 wrote: > > > > On Fri, Jun 5, 2020 at 8:30 AM Julien Grall wrote: > >> > >> Hi, > >> > >> On 05/06/2020 13:25, CodeWiz2280 wrote: > >>> The Keystone uses the netcp driver, which has interrupts from 40-79 > >>> listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). > >>> I'm using the same device tree between my non-xen standalone kernel > >>> and my dom0 kernel booted by xen. In the standalone (non-xen) kernel > >>> the ethernet works fine, but I don't see any of its interrupts in the > >>> output of /proc/iomem. I'm not seeing them in /proc/iomem when > >>> running dom0 under Xen either. When booting with Xen I get this > >>> behavior where the ifconfig output shows 1 RX message and 1 TX > >>> message, and then nothing else. > >> > >> I am not sure whether this is a typo in the e-mail. /proc/iomem is > >> listing the list of the MMIO regions. You want to use /proc/interrupts. > >> > >> Can you confirm which path you are dumping? > > Yes, that was a typo. Sorry about that. I meant that I am dumping > > /proc/interrupts and do not > > see them under the non-xen kernel or xen booted dom0. > > Could you post both /proc/interrupts content ? Standalone non-xen kernel (Ethernet works) # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 17: 0 0 0 0 GICv2 29 Level arch_timer 18: 9856 1202 457 650 GICv2 30 Level arch_timer 21: 0 0 0 0 GICv2 142 Edge timer-keystone 22: 0 0 0 0 GICv2 52 Edge arm-pmu 23: 0 0 0 0 GICv2 53 Edge arm-pmu 24: 0 0 0 0 GICv2 54 Edge arm-pmu 25: 0 0 0 0 GICv2 55 Edge arm-pmu 26: 0 0 0 0 GICv2 36 Edge 26202a0.keystone_irq 27: 1435 0 0 0 GICv2 309 Edge ttyS0 29: 0 0 0 0 GICv2 315 Edge 2530000.i2c 30: 1 0 0 0 GICv2 318 Edge 2530400.i2c 31: 0 0 0 0 GICv2 321 Edge 2530800.i2c 32: 69 0 0 0 GICv2 324 Edge 21000400.spi 33: 0 0 0 0 GICv2 328 Edge 21000600.spi 34: 0 0 0 0 GICv2 332 Edge 21000800.spi 70: 0 0 0 0 GICv2 417 Edge ks-pcie-error-irq 79: 0 0 0 0 PCI-MSI 0 Edge PCIe PME, aerdrv 88: 57 0 0 0 GICv2 80 Level hwqueue-528 89: 57 0 0 0 GICv2 81 Level hwqueue-529 90: 47 0 0 0 GICv2 82 Level hwqueue-530 91: 41 0 0 0 GICv2 83 Level hwqueue-531 IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 730 988 1058 937 Rescheduling interrupts IPI3: 2 3 4 6 Function call interrupts IPI4: 0 0 0 0 CPU stop interrupts IPI5: 0 0 0 0 IRQ work interrupts IPI6: 0 0 0 0 completion interrupts Xen dom0 (Ethernet stops) # cat /proc/interrupts CPU0 18: 10380 GIC-0 27 Level arch_timer 19: 0 GIC-0 142 Edge timer-keystone 20: 88 GIC-0 16 Level events 21: 0 xen-dyn Edge -event xenbus 22: 0 GIC-0 36 Edge 26202a0.keystone_irq 23: 1 GIC-0 312 Edge ttyS0 25: 1 GIC-0 318 Edge 27: 1 GIC-0 324 Edge 21000400.spi 28: 0 GIC-0 328 Edge 21000600.spi 29: 0 GIC-0 332 Edge 21000800.spi 65: 0 GIC-0 417 Edge ks-pcie-error-irq 74: 0 PCI-MSI 0 Edge PCIe PME, aerdrv 83: 1 GIC-0 80 Level hwqueue-528 84: 1 GIC-0 81 Level hwqueue-529 85: 1 GIC-0 82 Level hwqueue-530 86: 1 GIC-0 83 Level hwqueue-531 115: 87 xen-dyn Edge -virq hvc_console IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 CPU stop interrupts IPI5: 0 IRQ work interrupts IPI6: 0 completion interrupts Err: 0 > > Cheers > Bertrand > From xen-devel-bounces@lists.xenproject.org Fri Jun 05 15:10:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 15:10:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDza-0006FV-P0; Fri, 05 Jun 2020 15:10:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhDzZ-0006FQ-H4 for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 15:10:45 +0000 X-Inumbo-ID: ba5422a2-a73e-11ea-96fb-bc764e2007e4 Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ba5422a2-a73e-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 15:10:44 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id r7so10142980wro.1 for ; Fri, 05 Jun 2020 08:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=IZoRVj27HCkcHvbu9sXMUWc2RYh8crvQ8silDUuIsFY=; b=mI7q6dcgPWRRev5M/MD0eMzY9oVSBgcBJRhrKA8qe3z2k27YfajYQg3wSowLQKJS+I WSy9wOGqUrYnaUZsmwVU5AK8VGMupmoxEd5iHOjiDObvn/BMQPM1SC9cdN4LRNd1Y0xI LifxclxWa/t+vQ2boMPU4kP3/vVY/IfjZ0+4N6lG/IDX2LZGYDFJWTBWShTqnQB9ahXa jAo2B1FBLJnUpszZsr/Ucx2moBxEwxwjl00tsYnYD90oFtpD/1kP9lUbPKoxFjfHo+Tp xBzW5jJ3ni0IOCWCwAjZfZyC2/wrjd2lmXSTNp7sezdnlyqUbcBck1cpuRWvTzgL8JOD K3PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=IZoRVj27HCkcHvbu9sXMUWc2RYh8crvQ8silDUuIsFY=; b=rLMh7ylbBcJoAQxm/yHnF3/Z9bSnP3Y4wfvZOkePtDvDhX5n4D+w04U66fVMLAokwN gFlTvnbF4CusIqgzUofMHFekvY8QL+nXIfGx2FKHdrCCAYHKFk2yqkdetlpgGppQA8uZ 1ZQUaLyOJT8vczlv4kdXD3npTWJH8v+iK532fdy4DfHaYy/vhC6JO7VH3t2BpbB0w2rA 86Enx1/MOYrxyV8yRaoVM7LAQJJ0eAL+U5Q6uxzwpLQK16yni0NJyLkm2VN5g/p3JQJ3 YbILkZpWMwSoS0EKEMfipdVpMN4En3zk1pakfLDK3xf8V0Sb1GpogQsdtwmWKMwALEpA MCUg== X-Gm-Message-State: AOAM531Y5zQpDhSnq478qHRPs7u31pvYliAGg1YfjTryzKsLwn9JKfpM 5vqUih+jVNRi46DAafSdmi8= X-Google-Smtp-Source: ABdhPJzaQbIq1F3YvIx7zjCSB4qpQQbNoYZeIoptz/1WrtaYcz3M5qPjd+Ocif2QG7EdvyuG9mRGPQ== X-Received: by 2002:a5d:440c:: with SMTP id z12mr10357881wrq.241.1591369843967; Fri, 05 Jun 2020 08:10:43 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id z16sm12465472wrm.70.2020.06.05.08.10.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 08:10:43 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= References: <20200604014621.GA203658@mail-itl> <20200605111840.GE98582@mail-itl> In-Reply-To: Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 16:10:42 +0100 Message-ID: <002301d63b4b$7b65bf60$72313e20$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoAIM6jibAY4RUisDBXtFN6j7Nxlw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = Jan Beulich > Sent: 05 June 2020 15:00 > To: Marek Marczykowski-G=C3=B3recki > Cc: xen-devel > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On 05.06.2020 13:18, Marek Marczykowski-G=C3=B3recki wrote: > > On Fri, Jun 05, 2020 at 11:38:17AM +0200, Jan Beulich wrote: > >> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > >>> Hi, > >>> > >>> (continuation of a thread from #xendevel) > >>> > >>> During system shutdown quite often I hit infinite stream of errors = like > >>> this: > >>> > >>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > >>> (XEN) domain_crash called from io.c:178 > >>> > >>> This is all running on Xen 4.13.0 (I think I've got this with = 4.13.1 > >>> too), nested within KVM. The KVM part means everything is very = slow, so > >>> various race conditions are much more likely to happen. > >>> > >>> It started happening not long ago, and I'm pretty sure it's about > >>> updating to qemu 4.2.0 (in linux stubdom), previous one was 3.0.0. > >>> > >>> Thanks to Andrew and Roger, I've managed to collect more info. > >>> > >>> Context: > >>> dom0: pv > >>> dom1: hvm > >>> dom2: stubdom for dom1 > >>> dom3: hvm > >>> dom4: stubdom for dom3 > >>> dom5: pvh > >>> dom6: pvh > >>> > >>> It starts I think ok: > >>> > >>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > >>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > >>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > >> > >> I can't seem to be able to spot the call site of this, in any of > >> qemu, libxl, or libxc. I'm in particular curious as to the further > >> actions taken on the domain after this was invoked: Do any ioreq > >> servers get unregistered immediately (which I think would be a > >> problem)? > > > > It is here: > > https://github.com/qemu/qemu/blob/master/hw/i386/xen/xen-hvm.c#L1539 > > > > I think it's called from cpu_handle_ioreq(), and I think the request > > state is set to STATE_IORESP_READY before exiting (unless there is = some > > exit() hidden in another function used there). >=20 > Thanks. There's nothing in surrounding code there that would = unregister > an ioreq server. But as said elsewhere, I don't know qemu very well, > and hence I may easily overlook how else one may get unregistered > prematurely. >=20 See = https://git.qemu.org/?p=3Dqemu.git;a=3Dcommit;h=3Dba7fdd64b6714af7e42dfbe= 5969caf62c0823f75 This makes sure the server is destroyed in the exit notifier (called = when the QEMU process is killed) Paul > Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 15:18:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 15:18:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhE6Z-0006Rm-IQ; Fri, 05 Jun 2020 15:17:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhE6Y-0006Rh-Qt for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 15:17:58 +0000 X-Inumbo-ID: bc3f2d23-a73f-11ea-afd8-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bc3f2d23-a73f-11ea-afd8-12813bfff9fa; Fri, 05 Jun 2020 15:17:57 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: D0PnSQOv/L+HoZMJ0K5wPBHnoIgB6sl+ZXbvRR+Fg38kWWX/HNk4Q0cgA+7yFRkyFBYsDDWPLw BXwz/PntUvbgkQNzYks57ubLj8+Tg/TUE4It1w6Zr7/t3XO74N8CEhKEOrd58Pt0j2EmKu7qJD Edc3xfhRxTrEGRAbvtN9uLB6eHsMT8XXWj1cd2+pj119uHTFL7UvEgrmeHsxT7P9mZwm2rZvIl usjoI79M38BumwXw0dqlddLKxMAcaAU33mEdIG3SO2yZ7Yqxz+RgXkuizV1bEcnViq0wHCJ4NE RsM= X-SBRS: 2.7 X-MesageID: 19686232 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,476,1583211600"; d="scan'208";a="19686232" Date: Fri, 5 Jun 2020 17:17:48 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200605151748.GC660@Air-de-Roger> References: <20200605110240.52545-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 04:44:32PM +0200, Jan Beulich wrote: > On 05.06.2020 13:02, Roger Pau Monne wrote: > > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > > code paths (guest_io_{write/read}), but those accesses where never > > implemented for PVHv2 dom0. This patch provides such mediated accesses > > to the RTC for PVH dom0, just like it's provided for a classic PV > > dom0. > > > > Pull out some of the RTC logic from guest_io_{read/write} into > > specific helpers that can be used by both PV and HVM guests. The > > setup of the handlers for PVH is done in rtc_init, which is already > > used to initialize the fully emulated RTC. > > > > Without this a Linux PVH dom0 will read garbage when trying to access > > the RTC, and one vCPU will be constantly looping in > > rtc_timer_do_work. > > > > Note that such issue doesn't happen on domUs because the ACPI > > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > > accesses are not emulated but rather forwarded to the physical > > hardware. > > > > No functional change expected for classic PV dom0. > > But there is, in whether (virtual) port 0x71 can be read/written (even > by a DomU). I'm afraid of being called guilty in splitting hair, though. Urg, OK, I realized that but considered it a harmless mistake. > > @@ -808,10 +809,43 @@ void rtc_reset(struct domain *d) > > s->pt.source = PTSRC_isa; > > } > > > > +/* RTC mediator for HVM hardware domain. */ > > +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, > > + uint32_t *val) > > +{ > > + if ( dir == IOREQ_READ ) > > + *val = ~0; > > + > > + if ( size != 1 ) > > + { > > + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); > > + return X86EMUL_OKAY; > > + } > > + if ( !ioports_access_permitted(current->domain, port, port) ) > > This wants to move into the helper, such that the PV side can have > it moved too. > > > void rtc_init(struct domain *d) > > { > > RTCState *s = domain_vrtc(d); > > > > + if ( is_hardware_domain(d) ) > > + { > > + /* Hardware domain gets mediated access to the physical RTC. */ > > + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); > > + return; > > Any reason for this explicit return, rather than ... > > > + } > > + > > if ( !has_vrtc(d) ) > > return; > > ... making use of this one? In fact wouldn't it be more correct > to have > > if ( !has_vrtc(d) ) > { > /* Hardware domain gets mediated access to the physical RTC. */ > if ( is_hardware_domain(d) ) > register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); > return; > } > > such that eventual (perhaps optional) enabling of vRTC for hwdom > would have it properly work without changing this function again? Right, that seems fine to me. > > --- a/xen/arch/x86/pv/emul-priv-op.c > > +++ b/xen/arch/x86/pv/emul-priv-op.c > > @@ -280,19 +280,10 @@ static uint32_t guest_io_read(unsigned int port, unsigned int bytes, > > { > > sub_data = pv_pit_handler(port, 0, 0); > > } > > - else if ( port == RTC_PORT(0) ) > > - { > > - sub_data = currd->arch.cmos_idx; > > Note how there was no permission check here. Having one or more > I/O ports that can be used to simply latch a value can, as I've > learned, be quite valuable as a debugging vehicle, and there > aren't many (if any) ports beyond this one that a PV DomU might > use for such a purpose. Arguably the value is somewhat limited > here, as the value wouldn't survive a crash, but I'd still > prefer if we could retain prior functionality. OK, as said above I considered this a harmless mistake, but seeing as you find it valuable I will make sure to keep the behavior. > > @@ -1110,6 +1111,64 @@ static unsigned long get_cmos_time(void) > > return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); > > } > > > > +/* Helpers for guest accesses to the physical RTC. */ > > +unsigned int rtc_guest_read(unsigned int port) > > +{ > > + const struct domain *currd = current->domain; > > + unsigned long flags; > > + unsigned int data = ~0; > > + > > + ASSERT(port == RTC_PORT(0) || port == RTC_PORT(1)); > > Instead of this, how about ... > > > + if ( !ioports_access_permitted(currd, port, port) ) > > + { > > + ASSERT_UNREACHABLE(); > > + return data; > > + } > > + > > + switch ( port ) > > + { > > + case RTC_PORT(0): > > + data = currd->arch.cmos_idx; > > + break; > > + > > + case RTC_PORT(1): > > + spin_lock_irqsave(&rtc_lock, flags); > > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > > + data = inb(RTC_PORT(1)); > > + spin_unlock_irqrestore(&rtc_lock, flags); > > + break; > > default: > ASSERT_UNREACHABLE(); > break; > > ? Sure. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 15:40:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 15:40:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhERu-00008w-F6; Fri, 05 Jun 2020 15:40:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhERs-0008Ru-Ta for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 15:40:00 +0000 X-Inumbo-ID: d0556cc4-a742-11ea-ba62-bc764e2007e4 Received: from mail-wm1-x32f.google.com (unknown [2a00:1450:4864:20::32f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d0556cc4-a742-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 15:39:59 +0000 (UTC) Received: by mail-wm1-x32f.google.com with SMTP id q25so9590438wmj.0 for ; Fri, 05 Jun 2020 08:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=QdTd6c513UcYEL4WVXLrxeFN0Pzk73GTZalrmJZehd4=; b=K7t83Msrcuk0ihT9RCD/3+GvFY5ZklBhExnrZEuPy8awRrZfjEFbQAWyZtomaJrb1G RJDHAAnXbK9vrpazElZKLA+k7mA9VYHuRxtBIUFIcvbHwiBCLdUE3Dz+hY+M1rL5MVeo dlXiRbO6n75v9KjVfXMGswt6t1N9vLQnsVHG/yafJ3Pe4VNkpFiH6echXTH9BSuwdqWl 6NfaqMFLkkFDuZLevYOJDeWL2uPkQXcfca3A7Jf4CUhphsSBj1MPKSahQVxO8m5GWMfm mU/6f8Tt5kiJtd9vXQPVihjkmvgYlTq3Nml5jYgk9UgAXheHeu0nWMCBSGQEYV6n1OJx rOLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=QdTd6c513UcYEL4WVXLrxeFN0Pzk73GTZalrmJZehd4=; b=rGnUOGgVf8fysP/WuBPbRDxpqbJ6SigC4pOfkZYKLLtNftSY2qm2W5805HYWgyqO8Q z5rWsk7ahbMzbBfP2ju9cJbYJx5sLwMO63biVs4hC035ee9QoEwNMQKu2d5nZIKjNVXk a6JaRqsyhbDBF5BvWivbD89AEijqWu0eVnNsf3kDSU09iaMzw5RZYdax6fHcuE1v9f5W Eqm1Vr/btweV3uYSMm2Ujfu5UD2ufex6hMLtiZUCd+8eLdg0q30OUZyogZiPbYK5+2VK Gh7CJfCpPPbepaPpANbQ5Dyuw3zsKWfHb0iGI53ZpCwjU1iYDswGqeX+wbsXrABcy8nl IV4Q== X-Gm-Message-State: AOAM5305WSrArb4SG9IesX/epq5yFVHRlfGY9222PsY5M+IUfyFs4DWo pHud2oiBwfr+Qv13atHdXQE= X-Google-Smtp-Source: ABdhPJyMNV76jm3YAYjih8cSCKOdpm3pnzdfAHdIzYSd1ZvFRoqrGu3fX3y/+34NkPFE8EDIoJPKig== X-Received: by 2002:a1c:9c49:: with SMTP id f70mr812650wme.74.1591371598881; Fri, 05 Jun 2020 08:39:58 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id t7sm12644290wrq.41.2020.06.05.08.39.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 08:39:58 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <002001d63b3e$7c268a40$74739ec0$@xen.org> In-Reply-To: Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 16:39:56 +0100 Message-ID: <002e01d63b4f$914b3a90$b3e1afb0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoACJ30jDAXuEodcCsFgQ5AHivRJwAUZxxQAClbGaTgE+0ENsAeL9TS8CQ5Vrh6ixcARw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 05 June 2020 14:57 > To: paul@xen.org; 'Marek Marczykowski-G=C3=B3recki' = > Cc: 'Andrew Cooper' ; 'xen-devel' = > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On 05.06.2020 15:37, Paul Durrant wrote: > >> -----Original Message----- > >> From: Jan Beulich > >> Sent: 05 June 2020 14:32 > >> To: paul@xen.org > >> Cc: 'Marek Marczykowski-G=C3=B3recki' = ; 'Andrew Cooper' > >> ; 'xen-devel' = > >> Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > >> > >> On 05.06.2020 13:05, Paul Durrant wrote: > >>> Sorry, only just catching up with this... > >>> > >>>> -----Original Message----- > >>>> From: Jan Beulich > >>>> Sent: 05 June 2020 10:09 > >>>> To: Marek Marczykowski-G=C3=B3recki = > >>>> Cc: Andrew Cooper ; xen-devel = ; Paul > >>>> Durrant > >>>> Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > >>>> > >>>> On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > >>>>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: > >>>>>> On 04.06.2020 13:13, Andrew Cooper wrote: > >>>>>>> On 04/06/2020 08:08, Jan Beulich wrote: > >>>>>>>> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > >>>>>>>>> Then, we get the main issue: > >>>>>>>>> > >>>>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > >>>>>>>>> (XEN) domain_crash called from io.c:178 > >>>>>>>>> > >>>>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor = its stubdom > >>>>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called = already. > >>>>>>>> I'd guess an issue with the shutdown deferral logic. Did you = / can > >>>>>>>> you check whether XEN_DMOP_remote_shutdown managed to pause = all > >>>>>>>> CPUs (I assume it didn't, since once they're paused there = shouldn't > >>>>>>>> be any I/O there anymore, and hence no I/O emulation)? > >>>>>>> > >>>>>>> The vcpu in question is talking to Qemu, so will have = v->defer_shutdown > >>>>>>> intermittently set, and skip the pause in domain_shutdown() > >>>>>>> > >>>>>>> I presume this lack of pause is to allow the vcpu in question = to still > >>>>>>> be scheduled to consume the IOREQ reply? (Its fairly opaque = logic with > >>>>>>> 0 clarifying details). > >>>>>>> > >>>>>>> What *should* happen is that, after consuming the reply, the = vcpu should > >>>>>>> notice and pause itself, at which point it would yield to the > >>>>>>> scheduler. This is the purpose of = vcpu_{start,end}_shutdown_deferral(). > >>>>>>> > >>>>>>> Evidentially, this is not happening. > >>>>>> > >>>>>> We can't tell yet, until ... > >>>>>> > >>>>>>> Marek: can you add a BUG() after the weird PIO printing? That = should > >>>>>>> confirm whether we're getting into handle_pio() via the > >>>>>>> handle_hvm_io_completion() path, or via the vmexit path (at = which case, > >>>>>>> we're fully re-entering the guest). > >>>>>> > >>>>>> ... we know this. handle_pio() gets called from = handle_hvm_io_completion() > >>>>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> > >>>>>> vcpu_end_shutdown_deferral(), so the issue may be that we = shouldn't call > >>>>>> handle_pio() (etc) at all anymore in this state. IOW perhaps > >>>>>> hvm_wait_for_io() should return = "!sv->vcpu->domain->is_shutting_down" > >>>>>> instead of plain "true"? > >>>>>> > >>>>>> Adding Paul to Cc, as being the maintainer here. > >>>>> > >>>>> Got it, by sticking BUG() just before that domain_crash() in > >>>>> handle_pio(). And also vcpu 0 of both HVM domains do have > >>>>> v->defer_shutdown. > >>>> > >>>> As per the log they did get it set. I'd be curious of the flag's > >>>> value (as well as v->paused_for_shutdown's) at the point of the > >>>> problematic handle_pio() invocation (see below). It may be > >>>> worthwhile to instrument vcpu_check_shutdown() (inside its if()) > >>>> - before exiting to guest context (in order to then come back > >>>> and call handle_pio()) the vCPU ought to be getting through > >>>> there. No indication of it doing so would be a sign that there's > >>>> a code path bypassing the call to vcpu_end_shutdown_deferral(). > >>>> > >>>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > >>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > >>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > >>>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > >>>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > >>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > >>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > >>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > >>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > >>>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > >>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags = 0x2 d6 > >>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags = 0x2 d6 > >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > >>>> > >>>> Perhaps in this message could you also log > >>>> v->domain->is_shutting_down, v->defer_shutdown, and > >>>> v->paused_for_shutdown? (Would be nice if, after having made > >>>> changes to your debugging patch, you could point again at the > >>>> precise version you've used for the log provided.) > >>>> > >>>>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff > >>>>> (XEN) Xen BUG at io.c:178 > >>>> > >>>> Btw, instead of BUG(), WARN() or dump_execution_state() would > >>>> likely also do, keeping Xen alive. > >>>> > >>> > >>> A shutdown deferral problem would result in X86EMUL_RETRY wouldn't = it? > >> > >> Where would this originate? > > > > I was referring to the 'if ( = unlikely(!vcpu_start_shutdown_deferral(curr)) )' at the top of > hvm_send_ioreq(). >=20 > Ah yes. But this is just one way of things possibly going wrong. Plus > the function will return true when ->defer_shutdown is already or > (wrongly) still set. >=20 > >>> That would mean we wouldn't be seeing the "Unexpected PIO" = message. From that message this clearly > >> X86EMUL_UNHANDLEABLE which suggests a race with ioreq server = teardown, possibly due to selecting a > >> server but then not finding a vcpu match in ioreq_vcpu_list. > >> > >> I was suspecting such, but at least the tearing down of all servers > >> happens only from relinquish-resources, which gets started only > >> after ->is_shut_down got set (unless the tool stack invoked > >> XEN_DOMCTL_destroydomain without having observed = XEN_DOMINF_shutdown > >> set for the domain). > >> > >> For individually unregistered servers - yes, if qemu did so, this > >> would be a problem. They need to remain registered until all vCPU-s > >> in the domain got paused. > > > > It shouldn't be a problem should it? Destroying an individual server = is only done with the domain > paused, so no vcpus can be running at the time. >=20 > Consider the case of one getting destroyed after it has already > returned data, but the originating vCPU didn't consume that data > yet. Once that vCPU gets unpaused, handle_hvm_io_completion() > won't find the matching server anymore, and hence the chain > hvm_wait_for_io() -> hvm_io_assist() -> > vcpu_end_shutdown_deferral() would be skipped. handle_pio() > would then still correctly consume the result. True, and skipping hvm_io_assist() means the vcpu internal ioreq state = will be left set to IOREQ_READY and *that* explains why we would then = exit hvmemul_do_io() with X86EMUL_UNHANDLEABLE (from the first switch). >=20 > Marek - to verify this doesn't happen (sorry, my qemu knowledge > is rather limited, and hence I don't know whether this can > happen at all), could you also log hvm_destroy_ioreq_server() > invocations? >=20 > Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 05 15:48:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 15:48:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhEaL-00011u-Bh; Fri, 05 Jun 2020 15:48:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhEaJ-00011p-ES for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 15:48:43 +0000 X-Inumbo-ID: 078f5a28-a744-11ea-ba62-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 078f5a28-a744-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 15:48:42 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id q25so9617728wmj.0 for ; Fri, 05 Jun 2020 08:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=L8Qw+PRJTCdL9x9jH8vAP9nCGGtDOEPL4bl7rQFpRTc=; b=LXSgPbq2tcqvBdADznOGc6+/inM2R/QRITPyskJrMB1ZxSwfx6Tz6lFiEFt0B9Wynp JHdQfc6QL4VfKVtZrQmWgwrkGVoTBB7A2iLyISGN5WkXHEhHPws1fy5+CAOfgf+3+bQG EYVxccqZgqTANJRWWY8nBIekgtHrhsEfiGQsdAB23VU4Dn3LXlyFy2qBqzyzE7VkeNDf cVprSBbMvigllKUtxbWU0xIN3sA3/gpfVRBhQgvR5pO32hLacLpYBBZ4zzW3K/OgaxDy p5rZbB1FWTfsk7VLQrxjYWWUE680BBc0OeUli4wnrzZZbqmEb/BDs1tlaAGySu0yckzD V8jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=L8Qw+PRJTCdL9x9jH8vAP9nCGGtDOEPL4bl7rQFpRTc=; b=e3kfovymduLvXhWMknALPQX9D0+fdAvqaoNoQ/GEvzr4UbzwTGOYFbvDZSNf6w35qG 43XVAn6MtDW1p3aT15EPsGkxb5lxSDb3y5/HeZMWGmShTvByBOy1RuwtkDAMLrrA8sEM vbHjDRQt8wLjBrnx4BHiP/AyAwbZ8fmbsoZOc+Ncbxaf1eIkPKSxNE9mcxpKEOdQ45R0 sW1+alYSwTmFaj+VvzpRaTQHS16hg+Ea1KRocbdm+szcJo2IgSlbfGKcU5ogmtgzv4uW SNnUG9u/lzKrSAYqWYCYS5tbAxR4pmE2iOsZ1I/unuauUJct3axFK1z8H99UlP1k6548 8E3g== X-Gm-Message-State: AOAM5318e7CtAh3W3PT6EaiG96cCQSFoQza2oxrNKHrrWIpK5zrFoQ8L 1QzdbAMZXajkNrCy1OHOzhM= X-Google-Smtp-Source: ABdhPJxgfK9s2XYKZJ+qIFOyDQhqzvZNdzXAZFmueEk8RnvmPPFttEEuQfKLB9Rknw+GpLantpgAnw== X-Received: by 2002:a1c:67c3:: with SMTP id b186mr3135654wmc.167.1591372121056; Fri, 05 Jun 2020 08:48:41 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id x18sm11348833wmi.35.2020.06.05.08.48.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 08:48:40 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: , "'Jan Beulich'" References: <20200604014621.GA203658@mail-itl> <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <000701d63b2c$10536930$30fa3b90$@xen.org> <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> <002101d63b3f$4e9dc830$ebd95890$@xen.org> <002201d63b40$1e135ee0$5a3a1ca0$@xen.org> In-Reply-To: <002201d63b40$1e135ee0$5a3a1ca0$@xen.org> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 16:48:39 +0100 Message-ID: <002f01d63b50$c8b49a70$5a1dcf50$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjLdCXHS+ot6864srdbAQDyQsvoACJ30jDAXuEodcCsFgQ5AHivRJwAUZxxQAClbGaTgD0KkheAp3cNn8CbNqNYgH2h+l1AmkAS7Koia0gAA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , =?UTF-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Paul Durrant > Sent: 05 June 2020 14:49 > To: 'Jan Beulich' > Cc: 'Marek Marczykowski-G=C3=B3recki' = ; 'Andrew Cooper' > ; 'xen-devel' = > Subject: RE: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > > -----Original Message----- > > From: Jan Beulich > > Sent: 05 June 2020 14:47 > > To: paul@xen.org > > Cc: 'Marek Marczykowski-G=C3=B3recki' = ; 'Andrew Cooper' > > ; 'xen-devel' = > > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > > > > On 05.06.2020 15:43, Paul Durrant wrote: > > >> -----Original Message----- > > >> From: Jan Beulich > > >> Sent: 05 June 2020 14:37 > > >> To: paul@xen.org > > >> Cc: 'Marek Marczykowski-G=C3=B3recki' = ; 'Andrew Cooper' > > >> ; 'xen-devel' = > > >> Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > > >> > > >> On 05.06.2020 13:25, Paul Durrant wrote: > > >>>> -----Original Message----- > > >>>> From: Paul Durrant > > >>>> Sent: 05 June 2020 12:06 > > >>>> To: 'Jan Beulich' ; 'Marek = Marczykowski-G=C3=B3recki' > > >> > > >>>> Cc: 'Andrew Cooper' ; 'xen-devel' = > > >>>> Subject: RE: handle_pio looping during domain shutdown, with = qemu 4.2.0 in stubdom > > >>>> > > >>>> Sorry, only just catching up with this... > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Jan Beulich > > >>>>> Sent: 05 June 2020 10:09 > > >>>>> To: Marek Marczykowski-G=C3=B3recki = > > >>>>> Cc: Andrew Cooper ; xen-devel = ; > Paul > > >>>>> Durrant > > >>>>> Subject: Re: handle_pio looping during domain shutdown, with = qemu 4.2.0 in stubdom > > >>>>> > > >>>>> On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > > >>>>>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: > > >>>>>>> On 04.06.2020 13:13, Andrew Cooper wrote: > > >>>>>>>> On 04/06/2020 08:08, Jan Beulich wrote: > > >>>>>>>>> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki = wrote: > > >>>>>>>>>> Then, we get the main issue: > > >>>>>>>>>> > > >>>>>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >>>>>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read = 0xffff > > >>>>>>>>>> (XEN) domain_crash called from io.c:178 > > >>>>>>>>>> > > >>>>>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 = nor its stubdom > > >>>>>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called = already. > > >>>>>>>>> I'd guess an issue with the shutdown deferral logic. Did = you / can > > >>>>>>>>> you check whether XEN_DMOP_remote_shutdown managed to = pause all > > >>>>>>>>> CPUs (I assume it didn't, since once they're paused there = shouldn't > > >>>>>>>>> be any I/O there anymore, and hence no I/O emulation)? > > >>>>>>>> > > >>>>>>>> The vcpu in question is talking to Qemu, so will have = v->defer_shutdown > > >>>>>>>> intermittently set, and skip the pause in domain_shutdown() > > >>>>>>>> > > >>>>>>>> I presume this lack of pause is to allow the vcpu in = question to still > > >>>>>>>> be scheduled to consume the IOREQ reply? (Its fairly = opaque logic with > > >>>>>>>> 0 clarifying details). > > >>>>>>>> > > >>>>>>>> What *should* happen is that, after consuming the reply, = the vcpu should > > >>>>>>>> notice and pause itself, at which point it would yield to = the > > >>>>>>>> scheduler. This is the purpose of = vcpu_{start,end}_shutdown_deferral(). > > >>>>>>>> > > >>>>>>>> Evidentially, this is not happening. > > >>>>>>> > > >>>>>>> We can't tell yet, until ... > > >>>>>>> > > >>>>>>>> Marek: can you add a BUG() after the weird PIO printing? = That should > > >>>>>>>> confirm whether we're getting into handle_pio() via the > > >>>>>>>> handle_hvm_io_completion() path, or via the vmexit path (at = which case, > > >>>>>>>> we're fully re-entering the guest). > > >>>>>>> > > >>>>>>> ... we know this. handle_pio() gets called from = handle_hvm_io_completion() > > >>>>>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> > > >>>>>>> vcpu_end_shutdown_deferral(), so the issue may be that we = shouldn't call > > >>>>>>> handle_pio() (etc) at all anymore in this state. IOW perhaps > > >>>>>>> hvm_wait_for_io() should return = "!sv->vcpu->domain->is_shutting_down" > > >>>>>>> instead of plain "true"? > > >>>>>>> > > >>>>>>> Adding Paul to Cc, as being the maintainer here. > > >>>>>> > > >>>>>> Got it, by sticking BUG() just before that domain_crash() in > > >>>>>> handle_pio(). And also vcpu 0 of both HVM domains do have > > >>>>>> v->defer_shutdown. > > >>>>> > > >>>>> As per the log they did get it set. I'd be curious of the = flag's > > >>>>> value (as well as v->paused_for_shutdown's) at the point of = the > > >>>>> problematic handle_pio() invocation (see below). It may be > > >>>>> worthwhile to instrument vcpu_check_shutdown() (inside its = if()) > > >>>>> - before exiting to guest context (in order to then come back > > >>>>> and call handle_pio()) the vCPU ought to be getting through > > >>>>> there. No indication of it doing so would be a sign that = there's > > >>>>> a code path bypassing the call to = vcpu_end_shutdown_deferral(). > > >>>>> > > >>>>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > >>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >>>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > > >>>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > > >>>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > > >>>>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown = 1 > > >>>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > > >>>>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > > >>>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > >>>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > >>>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > > >>>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > > >>>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > >>>>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown = 1 > > >>>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > > >>>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d = flags 0x2 d6 > > >>>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e = flags 0x2 d6 > > >>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >>>>> > > >>>>> Perhaps in this message could you also log > > >>>>> v->domain->is_shutting_down, v->defer_shutdown, and > > >>>>> v->paused_for_shutdown? (Would be nice if, after having made > > >>>>> changes to your debugging patch, you could point again at the > > >>>>> precise version you've used for the log provided.) > > >>>>> > > >>>>>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff > > >>>>>> (XEN) Xen BUG at io.c:178 > > >>>>> > > >>>>> Btw, instead of BUG(), WARN() or dump_execution_state() would > > >>>>> likely also do, keeping Xen alive. > > >>>>> > > >>>> > > >>>> A shutdown deferral problem would result in X86EMUL_RETRY = wouldn't it? That would mean we > > wouldn't > > >> be > > >>>> seeing the "Unexpected PIO" message. From that message this = clearly X86EMUL_UNHANDLEABLE which > > >>>> suggests a race with ioreq server teardown, possibly due to = selecting a server but then not > > finding > > >> a > > >>>> vcpu match in ioreq_vcpu_list. > > >>> > > >>> Actually looking at remote_shutdown... the test of ( reason = =3D=3D SHUTDOWN_crash ) and then > clearing > > >> defer_shutdown looks a bit odd... Just because the domain = shutdown code has been set that way > > doesn't > > >> mean that a vcpu is not deferred in emulation; = SCHEDOP_shutdown_code could easily be called from > > one > > >> vcpu whilst another has emulation pending. > > >> > > >> I'm confused: The deferral is of shutting down the domain, not of > > >> a specific instance of emulation. > > > > > > Now I'm confused... defer_shutdown is per-vcpu. > > > > Right - each vCPU can individually defer shutting down of the domain > > as a whole. > > >=20 > Ok, I think we're only going to make more progress if we know exactly = where the X86EMUL_UNHANDLEABLE > is coming from. >=20 This (untested) patch might help: diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index c55c4bc4bc..8aa8779ba2 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -109,12 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu = *sv, uint64_t data) ioreq_t *ioreq =3D &v->arch.hvm.hvm_io.io_req; if ( hvm_ioreq_needs_completion(ioreq) ) - { - ioreq->state =3D STATE_IORESP_READY; ioreq->data =3D data; - } - else - ioreq->state =3D STATE_IOREQ_NONE; msix_write_completion(v); vcpu_end_shutdown_deferral(v); @@ -209,6 +204,9 @@ bool handle_hvm_io_completion(struct vcpu *v) } } + ioreq->state =3D hvm_ioreq_needs_completion(&vio->ioreq) ? + STATE_IORESP_READY : STATE_IOREQ_NONE; + io_completion =3D vio->io_completion; vio->io_completion =3D HVMIO_no_completion; From xen-devel-bounces@lists.xenproject.org Fri Jun 05 16:08:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 16:08:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhEtV-0003YN-78; Fri, 05 Jun 2020 16:08:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhEtU-0003YI-6l for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 16:08:32 +0000 X-Inumbo-ID: ccb15002-a746-11ea-9ad7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ccb15002-a746-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 16:08:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=So6oCAuCfc+vFVMt7lK66ijFNsg/hE7eVMHMnv94Oxw=; b=NAKdqFTONZ6r6c/iM33QhT5VI 8D8o6jNhWwDzNyPUyJTt0jqBd3OtfeWW7zC/1RIhYWOhcfCrv0DEhKAla+h0bWpUFDrLUvKIH6ohQ QNCClzo/cotY9osR9TF0G4bz+71l/9V0hHBqocUqrosrLsyeYb8yZi3Q1605q7N+XbO0I=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhEtS-0001MD-Kx; Fri, 05 Jun 2020 16:08:30 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhEtS-0003hm-DF; Fri, 05 Jun 2020 16:08:30 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhEtS-0004ln-CF; Fri, 05 Jun 2020 16:08:30 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150848: regressions - FAIL X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:guest-start:fail:regression xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Fri, 05 Jun 2020 16:08:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150848 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150848/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 150438 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 8 days Failing since 150465 2020-05-29 09:02:14 Z 7 days 53 attempts Testing same since 150708 2020-06-04 21:07:16 Z 0 days 6 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1546 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 05 16:18:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 16:18:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhF2r-0004ap-7Y; Fri, 05 Jun 2020 16:18:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhF2q-0004ak-3t for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 16:18:12 +0000 X-Inumbo-ID: 26058546-a748-11ea-9ad7-bc764e2007e4 Received: from wout5-smtp.messagingengine.com (unknown [64.147.123.21]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 26058546-a748-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 16:18:10 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id D23B895A; Fri, 5 Jun 2020 12:18:09 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 05 Jun 2020 12:18:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=cNG2UD 3egwVbo9tTRHAs2iT39yp8Hke/mmbnbboAw/s=; b=HRTPaJSMa1fEBOudko3om1 jBrCdqg8I1xQ4kn1OpdCBqsSbLKmtIADC5zhvsgm7vAU3zfOkGY9zpCPCC3lqwyF x5V8/jG1rfHq8JycOdXbbRRIMYIQ7F3NvVCRhTDRmUPO98WPST4cA/AhV6sZS1MZ enLdq2pPySAAEgzqUpyh2/OINBLBtc3PXBMuHV4KmbOEZ82Mb2fOLaz+aLK1DR8q /5jbTcketQzlmbL2f0di/8xiibVi9fKAZ7AoVZhQDXUnzueTFR5fkDw3BTHPrvG0 x9SBk5abF43MTPIMui5HUimNdrFZ7Z6YEY3mL9ZCJTdAhI5/ne2uD/CUftgWgZrQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpedkofgrrhgv khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhikdcuoehmrghrmhgrrhgvkhesih hnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeu feffgfegheeikeeggefhgeevfefhfedttdduudelgeekvdettdeuuefgleeggfenucfkph epledurdeihedrfeegrdeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrg gsrdgtohhm X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 24CDC30614FA; Fri, 5 Jun 2020 12:18:08 -0400 (EDT) Date: Fri, 5 Jun 2020 18:18:04 +0200 From: 'Marek =?utf-8?Q?Marczykowski-G=C3=B3recki'?= To: paul@xen.org Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Message-ID: <20200605161804.GJ98582@mail-itl> References: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <002001d63b3e$7c268a40$74739ec0$@xen.org> <002e01d63b4f$914b3a90$b3e1afb0$@xen.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LYDt+Tnt2WQ/hIRe" Content-Disposition: inline In-Reply-To: <002e01d63b4f$914b3a90$b3e1afb0$@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , 'Jan Beulich' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --LYDt+Tnt2WQ/hIRe Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom On Fri, Jun 05, 2020 at 04:39:56PM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Jan Beulich > > Sent: 05 June 2020 14:57 > > To: paul@xen.org; 'Marek Marczykowski-G=C3=B3recki' > > Cc: 'Andrew Cooper' ; 'xen-devel' > > Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0= in stubdom > >=20 > > On 05.06.2020 15:37, Paul Durrant wrote: > > >> -----Original Message----- > > >> From: Jan Beulich > > >> Sent: 05 June 2020 14:32 > > >> To: paul@xen.org > > >> Cc: 'Marek Marczykowski-G=C3=B3recki' ; 'Andrew Cooper' > > >> ; 'xen-devel' > > >> Subject: Re: handle_pio looping during domain shutdown, with qemu 4.= 2.0 in stubdom > > >> > > >> On 05.06.2020 13:05, Paul Durrant wrote: > > >>> Sorry, only just catching up with this... > > >>> > > >>>> -----Original Message----- > > >>>> From: Jan Beulich > > >>>> Sent: 05 June 2020 10:09 > > >>>> To: Marek Marczykowski-G=C3=B3recki > > >>>> Cc: Andrew Cooper ; xen-devel ; Paul > > >>>> Durrant > > >>>> Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > > >>>> > > >>>> On 04.06.2020 16:25, Marek Marczykowski-G=C3=B3recki wrote: > > >>>>> On Thu, Jun 04, 2020 at 02:36:26PM +0200, Jan Beulich wrote: > > >>>>>> On 04.06.2020 13:13, Andrew Cooper wrote: > > >>>>>>> On 04/06/2020 08:08, Jan Beulich wrote: > > >>>>>>>> On 04.06.2020 03:46, Marek Marczykowski-G=C3=B3recki wrote: > > >>>>>>>>> Then, we get the main issue: > > >>>>>>>>> > > >>>>>>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >>>>>>>>> (XEN) d3v0 Weird PIO status 1, port 0xb004 read 0xffff > > >>>>>>>>> (XEN) domain_crash called from io.c:178 > > >>>>>>>>> > > >>>>>>>>> Note, there was no XEN_DOMCTL_destroydomain for domain 3 nor = its stubdom > > >>>>>>>>> yet. But XEN_DMOP_remote_shutdown for domain 3 was called alr= eady. > > >>>>>>>> I'd guess an issue with the shutdown deferral logic. Did you /= can > > >>>>>>>> you check whether XEN_DMOP_remote_shutdown managed to pause all > > >>>>>>>> CPUs (I assume it didn't, since once they're paused there shou= ldn't > > >>>>>>>> be any I/O there anymore, and hence no I/O emulation)? > > >>>>>>> > > >>>>>>> The vcpu in question is talking to Qemu, so will have v->defer_= shutdown > > >>>>>>> intermittently set, and skip the pause in domain_shutdown() > > >>>>>>> > > >>>>>>> I presume this lack of pause is to allow the vcpu in question t= o still > > >>>>>>> be scheduled to consume the IOREQ reply? (Its fairly opaque lo= gic with > > >>>>>>> 0 clarifying details). > > >>>>>>> > > >>>>>>> What *should* happen is that, after consuming the reply, the vc= pu should > > >>>>>>> notice and pause itself, at which point it would yield to the > > >>>>>>> scheduler. This is the purpose of vcpu_{start,end}_shutdown_de= ferral(). > > >>>>>>> > > >>>>>>> Evidentially, this is not happening. > > >>>>>> > > >>>>>> We can't tell yet, until ... > > >>>>>> > > >>>>>>> Marek: can you add a BUG() after the weird PIO printing? That = should > > >>>>>>> confirm whether we're getting into handle_pio() via the > > >>>>>>> handle_hvm_io_completion() path, or via the vmexit path (at whi= ch case, > > >>>>>>> we're fully re-entering the guest). > > >>>>>> > > >>>>>> ... we know this. handle_pio() gets called from handle_hvm_io_co= mpletion() > > >>>>>> after having called hvm_wait_for_io() -> hvm_io_assist() -> > > >>>>>> vcpu_end_shutdown_deferral(), so the issue may be that we should= n't call > > >>>>>> handle_pio() (etc) at all anymore in this state. IOW perhaps > > >>>>>> hvm_wait_for_io() should return "!sv->vcpu->domain->is_shutting_= down" > > >>>>>> instead of plain "true"? > > >>>>>> > > >>>>>> Adding Paul to Cc, as being the maintainer here. > > >>>>> > > >>>>> Got it, by sticking BUG() just before that domain_crash() in > > >>>>> handle_pio(). And also vcpu 0 of both HVM domains do have > > >>>>> v->defer_shutdown. > > >>>> > > >>>> As per the log they did get it set. I'd be curious of the flag's > > >>>> value (as well as v->paused_for_shutdown's) at the point of the > > >>>> problematic handle_pio() invocation (see below). It may be > > >>>> worthwhile to instrument vcpu_check_shutdown() (inside its if()) > > >>>> - before exiting to guest context (in order to then come back > > >>>> and call handle_pio()) the vCPU ought to be getting through > > >>>> there. No indication of it doing so would be a sign that there's > > >>>> a code path bypassing the call to vcpu_end_shutdown_deferral(). > > >>>> > > >>>>> (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > > >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x0001 > > >>>>> (XEN) d3v0 handle_pio port 0xb004 write 0x2001 > > >>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > > >>>>> (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > > >>>>> (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > > >>>>> (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > > >>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > >>>>> (XEN) d1v0 handle_pio port 0xb004 read 0x0000 > > >>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x0001 > > >>>>> (XEN) d1v0 handle_pio port 0xb004 write 0x2001 > > >>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > > >>>>> (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > > >>>>> (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > > >>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0= x2 d6 > > >>>>> (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0= x2 d6 > > >>>>> (XEN) d3v0 handle_pio port 0xb004 read 0x0000 > > >>>> > > >>>> Perhaps in this message could you also log > > >>>> v->domain->is_shutting_down, v->defer_shutdown, and > > >>>> v->paused_for_shutdown? (Would be nice if, after having made > > >>>> changes to your debugging patch, you could point again at the > > >>>> precise version you've used for the log provided.) > > >>>> > > >>>>> (XEN) d3v0 Unexpected PIO status 1, port 0xb004 read 0xffff > > >>>>> (XEN) Xen BUG at io.c:178 > > >>>> > > >>>> Btw, instead of BUG(), WARN() or dump_execution_state() would > > >>>> likely also do, keeping Xen alive. > > >>>> > > >>> > > >>> A shutdown deferral problem would result in X86EMUL_RETRY wouldn't = it? > > >> > > >> Where would this originate? > > > > > > I was referring to the 'if ( unlikely(!vcpu_start_shutdown_deferral(c= urr)) )' at the top of > > hvm_send_ioreq(). > >=20 > > Ah yes. But this is just one way of things possibly going wrong. Plus > > the function will return true when ->defer_shutdown is already or > > (wrongly) still set. > >=20 > > >>> That would mean we wouldn't be seeing the "Unexpected PIO" message.= From that message this clearly > > >> X86EMUL_UNHANDLEABLE which suggests a race with ioreq server teardow= n, possibly due to selecting a > > >> server but then not finding a vcpu match in ioreq_vcpu_list. > > >> > > >> I was suspecting such, but at least the tearing down of all servers > > >> happens only from relinquish-resources, which gets started only > > >> after ->is_shut_down got set (unless the tool stack invoked > > >> XEN_DOMCTL_destroydomain without having observed XEN_DOMINF_shutdown > > >> set for the domain). > > >> > > >> For individually unregistered servers - yes, if qemu did so, this > > >> would be a problem. They need to remain registered until all vCPU-s > > >> in the domain got paused. > > > > > > It shouldn't be a problem should it? Destroying an individual server = is only done with the domain > > paused, so no vcpus can be running at the time. > >=20 > > Consider the case of one getting destroyed after it has already > > returned data, but the originating vCPU didn't consume that data > > yet. Once that vCPU gets unpaused, handle_hvm_io_completion() > > won't find the matching server anymore, and hence the chain > > hvm_wait_for_io() -> hvm_io_assist() -> > > vcpu_end_shutdown_deferral() would be skipped. handle_pio() > > would then still correctly consume the result. >=20 > True, and skipping hvm_io_assist() means the vcpu internal ioreq state wi= ll be left set to IOREQ_READY and *that* explains why we would then exit hv= memul_do_io() with X86EMUL_UNHANDLEABLE (from the first switch). I can confirm X86EMUL_UNHANDLEABLE indeed comes from the first switch in hvmemul_do_io(). And it happens shortly after ioreq server is destroyed: (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 reason 0 (XEN) d12v0 domain 11 domain_shutdown vcpu_id 0 defer_shutdown 1 (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 done (XEN) d12v0 hvm_destroy_ioreq_server called for 11, id 0 (XEN) d11v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 1 defer_shu= tdown 1 paused_for_shutdown 0 is_shut_down 0 (XEN) emulate.c:180:d11v0 hvmemul_do_io X86EMUL_UNHANDLEABLE: io_req.state 1 (XEN) d11v0 Unexpected PIO status 1, port 0xb004 read 0xffff I've also made handle_pio message printed on v->defer_shutdown=3D1 regardless of the port, but didn't hit any other case than read from 0xb004. Now, I'm going to try your patch. > > Marek - to verify this doesn't happen (sorry, my qemu knowledge > > is rather limited, and hence I don't know whether this can > > happen at all), could you also log hvm_destroy_ioreq_server() > > invocations? > >=20 > > Jan >=20 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --LYDt+Tnt2WQ/hIRe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7acD0ACgkQ24/THMrX 1yzfpgf/U/bg+CKhU69uCjA8iaE/e8OfywprRPrwhaQCwIL/BhrBagVlPOfWUlu+ tiUJKaEePB6Gpo0T1EnxtjeoX67DaTDKrJ5BLCENKiFrpFalcsvgDzQetJMVh3Id fds2qJDXAYRf9ahjhe8v1kx3qOIBQ+r0BYZ8tqYO8+7kr0InBpAluUEZabdv4Yhp HOAlNFu5f0JOYh7qqWirxaDkE2L6WS3LsBgf7vg6nPFOc4Fw6Qr0KMN+lAHCmBEM eKvcVQqNuxV2cjPSHHvOYGshSonSJ1Gdv+woqV4iU8c0TgfRB7WanePDVKJwaOYc 8E0OTUKkF54I6rIkXT7vf9BiDRRw+g== =rlSs -----END PGP SIGNATURE----- --LYDt+Tnt2WQ/hIRe-- From xen-devel-bounces@lists.xenproject.org Fri Jun 05 17:14:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 17:14:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhFuu-0001uA-HC; Fri, 05 Jun 2020 17:14:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhFus-0001u5-NF for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 17:14:02 +0000 X-Inumbo-ID: f2aff4c6-a74f-11ea-affe-12813bfff9fa Received: from wout5-smtp.messagingengine.com (unknown [64.147.123.21]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f2aff4c6-a74f-11ea-affe-12813bfff9fa; Fri, 05 Jun 2020 17:14:00 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AD5929EB; Fri, 5 Jun 2020 13:13:59 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 05 Jun 2020 13:13:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=EP/+Sz PHO77unTFmopxaGtILBXPwmsHYBesDt1ZC6Xc=; b=BSCxHeLqwlA9jWZz2seMOZ ZzJgHs3sA34Ie4WlZ68Wh6BEhfa3D04x6NmclfOw8HgpRDEFIRS5DY1+L0GUO9Cv DFK6dseHIOsLiMCyFpBGNKfV59ltsAEcdFmYl7T3dUKqT2xXt7W0ctGVH8muArH9 8uyEOYXLhEQmQ7ego8LY//yrcJ5InwxyczYTE4KjmqBcW3+PMbZEmmLWoKzlamlp m+ZhBUXfRf4y3tlw8tjs+IumTcFz5moOO1h2igjo6ObeExZ6Ffe1w55vyupR8YfA HB+99s1fKdXLLkftlE/Ed/nbdxeQbCn+MoHxwz3wMPTPBU2dgvhonNcMKaPSVJEw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpedkofgrrhgv khcuofgrrhgtiiihkhhofihskhhiqdfikphrvggtkhhikdcuoehmrghrmhgrrhgvkhesih hnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeff gfdugeegtdeggeetheefveffteeigeekjedtueelhedtvdeuffejkeelhfekheenucffoh hmrghinhepghhithhhuhgsrdgtohhmnecukfhppeeluddrieehrdefgedrfeefnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvg hksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 32B7330618C1; Fri, 5 Jun 2020 13:13:58 -0400 (EDT) Date: Fri, 5 Jun 2020 19:13:53 +0200 From: 'Marek =?utf-8?Q?Marczykowski-G=C3=B3recki'?= To: paul@xen.org Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Message-ID: <20200605171353.GG6329@mail-itl> References: <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <000701d63b2c$10536930$30fa3b90$@xen.org> <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> <002101d63b3f$4e9dc830$ebd95890$@xen.org> <002201d63b40$1e135ee0$5a3a1ca0$@xen.org> <002f01d63b50$c8b49a70$5a1dcf50$@xen.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KdquIMZPjGJQvRdI" Content-Disposition: inline In-Reply-To: <002f01d63b50$c8b49a70$5a1dcf50$@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , 'Jan Beulich' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --KdquIMZPjGJQvRdI Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom On Fri, Jun 05, 2020 at 04:48:39PM +0100, Paul Durrant wrote: > This (untested) patch might help: It is different now. I don't get domain_crash because of X86EMUL_UNHANDLEABLE anymore, but I still see handle_pio looping for some time. But it eventually ends, not really sure why. I've tried the patch with a modification to make it build: > diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c > index c55c4bc4bc..8aa8779ba2 100644 > --- a/xen/arch/x86/hvm/ioreq.c > +++ b/xen/arch/x86/hvm/ioreq.c > @@ -109,12 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv,= uint64_t data) > ioreq_t *ioreq =3D &v->arch.hvm.hvm_io.io_req; >=20 > if ( hvm_ioreq_needs_completion(ioreq) ) > - { > - ioreq->state =3D STATE_IORESP_READY; > ioreq->data =3D data; > - } > - else > - ioreq->state =3D STATE_IOREQ_NONE; >=20 > msix_write_completion(v); > vcpu_end_shutdown_deferral(v); > @@ -209,6 +204,9 @@ bool handle_hvm_io_completion(struct vcpu *v) > } > } >=20 > + ioreq->state =3D hvm_ioreq_needs_completion(&vio->ioreq) ? vio->io_req->state ... &vio->io_req > + STATE_IORESP_READY : STATE_IOREQ_NONE; > + > io_completion =3D vio->io_completion; > vio->io_completion =3D HVMIO_no_completion; >=20 The full patch (together with my debug prints): https://gist.github.com/marmarek/da37da3722179057a6e7add4fb361e06 Note some of those X86EMUL_UNHANDLEABLE logged below are about an intermediate state, not really hvmemul_do_io return value. And the log: (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shut= down 0 paused_for_shutdown 0 is_shut_down 0 (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from hvm_io= _intercept req state 1 (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shut= down 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d3v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer_shu= tdown 0 paused_for_shutdown 0 is_shut_down 0 (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from hvm_io= _intercept req state 1 (XEN) d3v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer_shu= tdown 0 paused_for_shutdown 0 is_shut_down 0 (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from hvm_io= _intercept req state 1 (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done (XEN) d4v0 hvm_destroy_ioreq_server called for 3, id 0 (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shut= down 0 paused_for_shutdown 0 is_shut_down 0 (XEN) emulate.c:263:d1v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from hvm_io= _intercept req state 1 (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 defer_shut= down 0 paused_for_shutdown 0 is_shut_down 0 (XEN) d1v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 defer_shu= tdown 0 paused_for_shutdown 0 is_shut_down 0 (XEN) emulate.c:263:d1v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from hvm_io= _intercept req state 1 (XEN) d1v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 defer_shu= tdown 0 paused_for_shutdown 0 is_shut_down 0 (XEN) emulate.c:263:d1v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from hvm_io= _intercept req state 1 (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done (XEN) grant_table.c:3702:d0v0 Grant release 0x24 ref 0x199 flags 0x2 d5 (XEN) grant_table.c:3702:d0v0 Grant release 0x25 ref 0x19a flags 0x2 d5 (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 1 defer_shut= down 1 paused_for_shutdown 0 is_shut_down 0 (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from hvm_io= _intercept req state 1 (XEN) d3v0 handle_pio port 0xb004 write 0xe3f8 is_shutting_down 1 defer_shu= tdown 1 paused_for_shutdown 0 is_shut_down 0 (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from hvm_io= _intercept req state 1 (XEN) d3v0 handle_pio port 0xb000 read 0x0000 is_shutting_down 1 defer_shut= down 1 paused_for_shutdown 0 is_shut_down 0 (XEN) d3v0 handle_pio port 0xb000 read 0x0000 is_shutting_down 1 defer_shut= down 1 paused_for_shutdown 0 is_shut_down 0 The last one repeats for some time, like 30s or some more (18425 times). Note the port is different than before. Is it a guest waiting for being destroyed after requesting so? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --KdquIMZPjGJQvRdI Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7afVMACgkQ24/THMrX 1yy11wf+K4pJpbx8IauOhjfXwPJhuxDXEJKgqBnyutENjl9GriEfo+45LDCJRdDj YXX78bYRS7j+eefmzmXKI6zXFVABmFfv99kZCJcfeFJFydAa9TqJDbpsZwchPQgI 0qv1+astDYS3bL1+iADVctbO5trYZC+QKkNkZngOUvV9Mj3nk+45UBt1V1W1cNg1 QeoWokPRphQmtriwq2QQvfNFS6+ntEEiZPsy9KUmv2Gax3W7YoJC2syplK1WUbIJ Pe2HgE1Zwub0jyr/7sFHB10ZKjoC8VByTdqSNAm3spiBKKsk+pbrMyAZUhj6CAd0 X5VE3MvwKGEk6vNA2EQfJwbLoNlBVw== =Fr7J -----END PGP SIGNATURE----- --KdquIMZPjGJQvRdI-- From xen-devel-bounces@lists.xenproject.org Fri Jun 05 17:24:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 17:24:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhG4u-0002wR-LJ; Fri, 05 Jun 2020 17:24:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhG4u-0002wM-5R for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 17:24:24 +0000 X-Inumbo-ID: 6590409e-a751-11ea-9b55-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6590409e-a751-11ea-9b55-bc764e2007e4; Fri, 05 Jun 2020 17:24:23 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id q19so10944790eja.7 for ; Fri, 05 Jun 2020 10:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=8eLGDaE2XLi27z8fzgPAYcToiV0jQlX2Lg21+woM5JA=; b=dzlMCInXR+hsGh/KFpGe8Yj7ALi9nxpEGL/Sc6CGwu2i150JBtYSzJYdpMH2PKTZ86 C9UWEZWflGjZL36e/LdpkGnynMtzvncxsAiCE3RqsFyftSUvmR6NEgFz7eQcAjEa9SHY OiG/NqGlHqSgRQMfYO1KVg3IY/ET7qNtmK6Utxc5SC+Mi2VDvzzUNg3fo3yqCUipeNLd OqCDzjvXrPIFFyAT03SCkgKDllRs5tKZelKztpFMY1NQ+UP0QIKeTxbNebMlgIfX9cGF DBufE/96DlPwgBGEkDhNDKohmAsbuhkwJ+YURcHQjsw95V5w0qp6gdpFtEgKJlkkPjbj OJXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=8eLGDaE2XLi27z8fzgPAYcToiV0jQlX2Lg21+woM5JA=; b=tfVdx+ofYotFKKPmlM/kv+1Vjt0jrCfS5oTA8TyMUqSb/vVuaFHiLsgvKxiqW/UAh7 ez/ky5gOLldSFZq2RdNbqR+g29gYyAv6f/Z+g6/HVNDYlCJZR9L+SomDJgh4W7HLqRvJ 6zVaj4ySWiQLafjJYkoyY/Zc3b6YxrYRcJ5Imjb54Nv+lWis8r28l4Pg0tsiIytX7OZZ lj8Qw03CSMrDl1cq9v+X7y2tfGKO1eEgHUlMZOz0DNRCvFiRntZee7t17o4F87MuD502 qSO86ce6dMpDrnYOn1feverHd7htzXcdu77vhv98CRAurUD9CNVORQV1+teNyYj7RAi1 OX1Q== X-Gm-Message-State: AOAM5317cpL+FegTx9zVboO8IDYEeTI/fY75JaI88ApNXU4nnZyLV2vh 42WOk0mRlHocCwiRYE+DRYE= X-Google-Smtp-Source: ABdhPJwqL3w7eV5o8Ut3HDA7zwzSzA6arN2kJ+b1XSSk4gnWzibiwxng2vQ6DYXuu+edpUEpJsxKTg== X-Received: by 2002:a17:906:aec5:: with SMTP id me5mr10315505ejb.54.1591377862254; Fri, 05 Jun 2020 10:24:22 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id cx13sm5190752edb.20.2020.06.05.10.24.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 10:24:21 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= References: <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <000701d63b2c$10536930$30fa3b90$@xen.org> <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> <002101d63b3f$4e9dc830$ebd95890$@xen.org> <002201d63b40$1e135ee0$5a3a1ca0$@xen.org> <002f01d63b50$c8b49a70$5a1dcf50$@xen.org> <20200605171353.GG6329@mail-itl> In-Reply-To: <20200605171353.GG6329@mail-itl> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Fri, 5 Jun 2020 18:24:20 +0100 Message-ID: <001501d63b5e$26a991a0$73fcb4e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKwWBDknGIax7CaUQXMyxrtt3nV1QHivRJwAUZxxQAClbGaTgD0KkheAp3cNn8CbNqNYgH2h+l1AmkAS7ICMiY5xQHIW8HVpnVMnNA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Jan Beulich' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: 'Marek Marczykowski-G=C3=B3recki' = > Sent: 05 June 2020 18:14 > To: paul@xen.org > Cc: 'Jan Beulich' ; 'Andrew Cooper' = ; 'xen-devel' devel@lists.xenproject.org> > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On Fri, Jun 05, 2020 at 04:48:39PM +0100, Paul Durrant wrote: > > This (untested) patch might help: >=20 > It is different now. I don't get domain_crash because of > X86EMUL_UNHANDLEABLE anymore, but I still see handle_pio looping for > some time. But it eventually ends, not really sure why. That'll be the shutdown deferral, which I realised later that I forgot = about... >=20 > I've tried the patch with a modification to make it build: >=20 > > diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c > > index c55c4bc4bc..8aa8779ba2 100644 > > --- a/xen/arch/x86/hvm/ioreq.c > > +++ b/xen/arch/x86/hvm/ioreq.c > > @@ -109,12 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu = *sv, uint64_t data) > > ioreq_t *ioreq =3D &v->arch.hvm.hvm_io.io_req; > > > > if ( hvm_ioreq_needs_completion(ioreq) ) > > - { > > - ioreq->state =3D STATE_IORESP_READY; > > ioreq->data =3D data; > > - } > > - else > > - ioreq->state =3D STATE_IOREQ_NONE; > > > > msix_write_completion(v); > > vcpu_end_shutdown_deferral(v); In fact, move both of these lines... > > @@ -209,6 +204,9 @@ bool handle_hvm_io_completion(struct vcpu *v) > > } > > } > > > > + ioreq->state =3D hvm_ioreq_needs_completion(&vio->ioreq) ? > vio->io_req->state ... &vio->io_req >=20 > > + STATE_IORESP_READY : STATE_IOREQ_NONE; > > + ... to here too. > > io_completion =3D vio->io_completion; > > vio->io_completion =3D HVMIO_no_completion; > > >=20 > The full patch (together with my debug prints): > https://gist.github.com/marmarek/da37da3722179057a6e7add4fb361e06 >=20 > Note some of those X86EMUL_UNHANDLEABLE logged below are about an > intermediate state, not really hvmemul_do_io return value. >=20 > And the log: > (XEN) hvm.c:1620:d6v0 All CPUs offline -- powering off. > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from = hvm_io_intercept req state 1 > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from = hvm_io_intercept req state 1 > (XEN) d3v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from = hvm_io_intercept req state 1 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 reason 0 > (XEN) d4v0 domain 3 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d4v0 XEN_DMOP_remote_shutdown domain 3 done > (XEN) d4v0 hvm_destroy_ioreq_server called for 3, id 0 > (XEN) hvm.c:1620:d5v0 All CPUs offline -- powering off. > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) emulate.c:263:d1v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from = hvm_io_intercept req state 1 > (XEN) d1v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d1v0 handle_pio port 0xb004 write 0x0001 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) emulate.c:263:d1v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from = hvm_io_intercept req state 1 > (XEN) d1v0 handle_pio port 0xb004 write 0x2001 is_shutting_down 0 = defer_shutdown 0 paused_for_shutdown > 0 is_shut_down 0 > (XEN) emulate.c:263:d1v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from = hvm_io_intercept req state 1 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 reason 0 > (XEN) d2v0 domain 1 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d2v0 XEN_DMOP_remote_shutdown domain 1 done > (XEN) grant_table.c:3702:d0v0 Grant release 0x24 ref 0x199 flags 0x2 = d5 > (XEN) grant_table.c:3702:d0v0 Grant release 0x25 ref 0x19a flags 0x2 = d5 > (XEN) grant_table.c:3702:d0v0 Grant release 0x3 ref 0x11d flags 0x2 d6 > (XEN) grant_table.c:3702:d0v0 Grant release 0x4 ref 0x11e flags 0x2 d6 > (XEN) d3v0 handle_pio port 0xb004 read 0x0000 is_shutting_down 1 = defer_shutdown 1 paused_for_shutdown > 0 is_shut_down 0 > (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from = hvm_io_intercept req state 1 > (XEN) d3v0 handle_pio port 0xb004 write 0xe3f8 is_shutting_down 1 = defer_shutdown 1 paused_for_shutdown > 0 is_shut_down 0 > (XEN) emulate.c:263:d3v0 hvmemul_do_io got X86EMUL_UNHANDLEABLE from = hvm_io_intercept req state 1 > (XEN) d3v0 handle_pio port 0xb000 read 0x0000 is_shutting_down 1 = defer_shutdown 1 paused_for_shutdown > 0 is_shut_down 0 > (XEN) d3v0 handle_pio port 0xb000 read 0x0000 is_shutting_down 1 = defer_shutdown 1 paused_for_shutdown > 0 is_shut_down 0 >=20 > The last one repeats for some time, like 30s or some more (18425 = times). > Note the port is different than before. Is it a guest waiting for = being > destroyed after requesting so? >=20 I guess it is the destroy being held off by the shutdown deferral? = Hopefully the above tweaks should sort that out. Paul > -- > Best Regards, > Marek Marczykowski-G=C3=B3recki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? From xen-devel-bounces@lists.xenproject.org Fri Jun 05 17:37:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 17:37:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhGHm-00041s-US; Fri, 05 Jun 2020 17:37:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhGHm-00041n-3c for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 17:37:42 +0000 X-Inumbo-ID: 410e82ec-a753-11ea-ba62-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 410e82ec-a753-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 17:37:40 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: i2/lbkd5i1GHpoqr0NvG+CJo8t9BYurPS+k7x2p2CC1OC90WyPavfY8MRJFJze5HMYQZz/2UQA 6glpEBx9Add8iwZGcZls8j0MEDE7KiKWT+jPyWAwhSpUlCiaIO9tRM9GEJzi8PjbdzvHHzmEkG rf9w8YdKeU/sgt+5VE8hO89GNGwyHyLlrissls9v0WXex3FoK88loNFlU7QqAOQt8NKTpZKEbl MIAgHzniNyS2Cz2JqueDOGUD9JL6AlEdh0wYx8Og+1yp0ibek119fEYl0lzV8BOIiReLxdDThD u/o= X-SBRS: 2.7 X-MesageID: 19348260 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,477,1583211600"; d="scan'208";a="19348260" Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers To: Jan Beulich , "xen-devel@lists.xenproject.org" References: From: Andrew Cooper Message-ID: Date: Fri, 5 Jun 2020 18:37:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05/06/2020 08:51, Jan Beulich wrote: > Both match prior generation processors as far as LBR and C-state MSRs > go (SDM rev 072) as well as applicability of the if_pschange_mc erratum > (recent spec updates). > > Signed-off-by: Jan Beulich > --- > Such changes having been subject to backporting in the past, this > change may want considering for 4.14. > --- > I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum > for Ice Lake indicating that MDS_NO may wrongly be set. But this is > apparently addressed by ucode update, so we may not need to deal with > it in software. I've enquired about this.  At a guess, there was another hole found, so MDS_NO has been cleared and VERW flushing reinstated. Either way, changes there can wait until we've got confirmation. Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Fri Jun 05 17:47:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 17:47:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhGRH-00054L-TS; Fri, 05 Jun 2020 17:47:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhGRG-00054G-Ro for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 17:47:30 +0000 X-Inumbo-ID: 9feb12b6-a754-11ea-b00e-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9feb12b6-a754-11ea-b00e-12813bfff9fa; Fri, 05 Jun 2020 17:47:29 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: g3bDy7/aKMqYA/nRD5k68luHJp3E/nGih27P7PhJUOpnnhfOGwp0qJFtygVEGhyl+ac10kgls8 XXlxVsWW/EPpoEUtl6USTiJmP8KjyB49IoW6ymWnc/MhSserHnDy3I0ovXdpv4nwt1008sM781 K1kSbgfv3EnIp6x1AWRZB6aSsLGul0thqHGytc4j/MGr3bmXOxwMzRgtu1KgoQomO2uzjJ4TyX PGa7zdE8f5N8vtWM90oSDYtz3OlYnjibcEim0HC6d/wQpe+S8tJM4kPIh64WvM8gvU7qwJEEBz McM= X-SBRS: 2.7 X-MesageID: 19369432 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,477,1583211600"; d="scan'208";a="19369432" Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers To: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200605080216.GI1195@Air-de-Roger> <32c4cdf7-0fdd-8b12-ee42-dfe8fe096935@suse.com> <20200605084644.GJ1195@Air-de-Roger> From: Andrew Cooper Message-ID: <570eee9d-fcf4-be2b-f56e-c739eea9eca7@citrix.com> Date: Fri, 5 Jun 2020 18:47:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05/06/2020 09:54, Jan Beulich wrote: > On 05.06.2020 10:46, Roger Pau Monné wrote: >> On Fri, Jun 05, 2020 at 10:10:01AM +0200, Jan Beulich wrote: >>> On 05.06.2020 10:02, Roger Pau Monné wrote: >>>> On Fri, Jun 05, 2020 at 09:51:09AM +0200, Jan Beulich wrote: >>>>> Both match prior generation processors as far as LBR and C-state MSRs >>>>> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum >>>>> (recent spec updates). >>>>> >>>>> Signed-off-by: Jan Beulich >>>>> --- >>>>> Such changes having been subject to backporting in the past, this >>>>> change may want considering for 4.14. >>>>> --- >>>>> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum >>>>> for Ice Lake indicating that MDS_NO may wrongly be set. But this is >>>>> apparently addressed by ucode update, so we may not need to deal with >>>>> it in software. >>>>> >>>>> --- a/xen/arch/x86/acpi/cpu_idle.c >>>>> +++ b/xen/arch/x86/acpi/cpu_idle.c >>>> What about mwait-idle? I guess we pick that from Linux and no patch >>>> has been added so far? >>> Correct. I've looked at recent history there, and I'm uncertain they'll >>> add further models there. They look to prefer to use ACPI _CST now again >>> with, as it seems, not overly much of a difference to the ACPI driver >>> (which, if we were to follow, I'd rather see us integrate there). >> Urg, OK, that's a shame as using mwait-idle was IMO better from a Xen >> PoV as we didn't rely on dom0 in order to discover C states. I wonder >> if we could continue to update mwait-idle on our own for newer models. > This would be nice indeed, but would require Intel to provide us with > the necessary data. > >> FWIW, wikichip also lists 6c and 6a [0] as Ice Lake Server model versions, >> but I'm not sure if this has been confirmed in any way? > SDM vol 4 confirms this, but mentions the two model numbers exclusively > in the table matching signatures to model names ("Future Intel Xeon > processors based on Ice Lake microarchitecture"). Without there being an > actual table for these I don't think we should "speculatively" add the > numbers anywhere. 0x6a is server, 0x6c is microserver. >From this patch, 0x7d is regular client and 0x7e mobile, but there is also 0x9d which is separate model for inference (I believe its server with extra AVX512). Its high time we borrowed intel-family.h from Linux and used that. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 05 18:02:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 18:02:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhGg6-000715-8N; Fri, 05 Jun 2020 18:02:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhGg4-000710-As for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 18:02:48 +0000 X-Inumbo-ID: c2bb63b6-a756-11ea-ba62-bc764e2007e4 Received: from trent.utfs.org (unknown [2a03:3680:0:3::67]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c2bb63b6-a756-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 18:02:47 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by trent.utfs.org (Postfix) with ESMTPS id 050E75FE75; Fri, 5 Jun 2020 20:02:46 +0200 (CEST) Date: Fri, 5 Jun 2020 11:02:45 -0700 (PDT) From: Christian Kujau To: =?UTF-8?Q?J=C3=BCrgen_Gro=C3=9F?= Subject: Re: 5.7.0 / BUG: kernel NULL pointer dereference / setup_cpu_watcher In-Reply-To: <7e2dec0c-8e27-6454-7793-d1246262283d@suse.com> Message-ID: References: <7e2dec0c-8e27-6454-7793-d1246262283d@suse.com> User-Agent: Alpine 2.22 (DEB 395 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 5 Jun 2020, Jürgen Groß wrote: > Do you happen to start the guest with vcpus < maxvcpus? Indeed, I was booting with vcpus=2, maxvcpus=4. Setting both to the same value made the domU boot. > If yes there is already a patch pending for 5.8: > https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?h=for-linus-5.8&id=c54b071c192dfe8061336f650ceaf358e6386e0b Applied that manually and now the system boots even with vcpus < maxvcpus. So, if this still matters: Tested-by: Christian Kujau Thank you for your response, and the fix! Christian. -- BOFH excuse #146: Communications satellite used by the military for star wars. From xen-devel-bounces@lists.xenproject.org Fri Jun 05 18:10:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 18:10:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhGnQ-0007rG-0g; Fri, 05 Jun 2020 18:10:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhGnP-0007rB-5f for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 18:10:23 +0000 X-Inumbo-ID: d24e93ba-a757-11ea-b016-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d24e93ba-a757-11ea-b016-12813bfff9fa; Fri, 05 Jun 2020 18:10:22 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /D7uevOGb7NUS3jLhu56Icbr/nUD7Qi81n2S5LiPeFIrT8ReeW9XNSW42OEZ0WFDiBKGdrKCfj uv8eVAIzuVxu4PI66k7fgrV13TriETEJNqX+6x2DtP6nVsDNEg85NlOCrAnDIfRbkobyP1HM3t 6+XYZ8lfZTxgKh8idzSCtkPzVXNYBvTzGjMJO8aQWPzbeRQeNVkg1o+MjrMCdCuq2/nd1ecgGl IPiY58EJ5yOUn8NM0FPYRK+gsojASP025eDRmGjiDWLeKDzo/r+hETjg4zsiEMAAyzN9jnp5P9 1Jg= X-SBRS: 2.7 X-MesageID: 19701429 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,477,1583211600"; d="scan'208";a="19701429" Subject: Re: 5.7.0 / BUG: kernel NULL pointer dereference / setup_cpu_watcher To: Christian Kujau , References: From: Andrew Cooper Message-ID: Date: Fri, 5 Jun 2020 19:10:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05/06/2020 09:36, Christian Kujau wrote: > Hi, > > I'm running a small Xen PVH domain and upgrading from vanilla 5.6.0 to > > > Note: that "Xen Platform PCI: unrecognised magic value" on the top appears > in 5.6 kernels as well, but no ill effects so far. > > --------------------------------------------------------------- > Xen Platform PCI: unrecognised magic value PVH domains don't have the emulated platform device, so Linux will be finding ~0 when it goes looking in config space. The diagnostic should be skipped in that case, to avoid giving the false impression that something is wrong. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 05 19:13:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 19:13:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhHln-0005LX-HD; Fri, 05 Jun 2020 19:12:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhHlm-0005LS-6L for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 19:12:46 +0000 X-Inumbo-ID: 89083edc-a760-11ea-96fb-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 89083edc-a760-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 19:12:45 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id mb16so11293657ejb.4 for ; Fri, 05 Jun 2020 12:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/plSRH9c+wV0IQMvke9Kh3M5mB+b2w61NbNsCxNtyKk=; b=Dn30+ZGnxgbJZghXvd7xmj0/d1eRlNXytxxBtQI2GV5OTToUoN/fTM9Z/MOfsAfNT1 pqT9McJwRuLmeBqcfNCN0cp4K9haQEmMlIcVSqml2Q7rvYpTGP1XZvjy3TsqcdJ+M290 WfjMFBg3Ufg8CBYV1LYPn5r3b+V2C73ZwLMoWzXLWXdS8+6qePr55JLOnQdkv7zEKAw8 Y/q52tNDkmnxhSf1iXZ3WqwQubc99Gqfr3uEXagS+rXoltkcFLB14/2+6OI9mBrmKYCn 7BzwZOQ1XiP+GaObQ7FBll9C4FvDpxkkJ0ISQIs/eBs635pHtttziAc64BlMMQzIJYqc PvUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/plSRH9c+wV0IQMvke9Kh3M5mB+b2w61NbNsCxNtyKk=; b=NGR1hukk8JYERJVx6RCqi4SpDAhCEExk6UdKrSW3XeymFxeW65OChclZzHraMTG5eI SIHryISMSlSHAJmfmsgi0lcNQGaSMu5kRF2iE3T1Qnma775USo1Lb3nQi+mSlsayvBL9 tl4Rmt/+2UgyIXoCK8loxnjA8OGhNnpQWeGgHTJj5yJRogfCWDEGmHK0803KRySMulmq fZm8TyQl2w8OorZQsrY9wjxi/63rQvyRuMTn2KLLaCNIH4vSlvQsUVwmqUm4H98JDKo/ XDiKcVp3eCbcek5+KKnReMPJ9zeW+O2fZuueYjfnR0KwPb/ikjeD9cEXtfp+ZNYcGRwD 6R/w== X-Gm-Message-State: AOAM5316cmXHu93Fj9yF6jtk7itRgi0zZf1rAZ9Yl5ZnuG7YV/rLSUFh YU2ruFtmPf0TBHKqRVbjZPhgJUaemgLRiuQ4L4A= X-Google-Smtp-Source: ABdhPJxGiRDuaV7OE+tj8SuBoI9B4o1Ghtvetb6SXqx4dX7jXK/fMiANY7Z+XMawQemuIJcF5c1fseqHby/JBnWY+lc= X-Received: by 2002:a17:906:f745:: with SMTP id jp5mr3015988ejb.440.1591384364175; Fri, 05 Jun 2020 12:12:44 -0700 (PDT) MIME-Version: 1.0 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> In-Reply-To: From: CodeWiz2280 Date: Fri, 5 Jun 2020 15:12:30 -0400 Message-ID: Subject: Re: Keystone Issue To: Bertrand Marquis Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 5, 2020 at 11:05 AM CodeWiz2280 wrote: > > On Fri, Jun 5, 2020 at 8:47 AM Bertrand Marquis > wrote: > > > > > > > > > On 5 Jun 2020, at 13:42, CodeWiz2280 wrote: > > > > > > On Fri, Jun 5, 2020 at 8:30 AM Julien Grall wrote: > > >> > > >> Hi, > > >> > > >> On 05/06/2020 13:25, CodeWiz2280 wrote: > > >>> The Keystone uses the netcp driver, which has interrupts from 40-79 > > >>> listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). > > >>> I'm using the same device tree between my non-xen standalone kernel > > >>> and my dom0 kernel booted by xen. In the standalone (non-xen) kernel > > >>> the ethernet works fine, but I don't see any of its interrupts in the > > >>> output of /proc/iomem. I'm not seeing them in /proc/iomem when > > >>> running dom0 under Xen either. When booting with Xen I get this > > >>> behavior where the ifconfig output shows 1 RX message and 1 TX > > >>> message, and then nothing else. > > >> > > >> I am not sure whether this is a typo in the e-mail. /proc/iomem is > > >> listing the list of the MMIO regions. You want to use /proc/interrupts. > > >> > > >> Can you confirm which path you are dumping? > > > Yes, that was a typo. Sorry about that. I meant that I am dumping > > > /proc/interrupts and do not > > > see them under the non-xen kernel or xen booted dom0. > > > > Could you post both /proc/interrupts content ? > > Standalone non-xen kernel (Ethernet works) > # cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 17: 0 0 0 0 GICv2 29 Level > arch_timer > 18: 9856 1202 457 650 GICv2 30 Level > arch_timer > 21: 0 0 0 0 GICv2 142 Edge > timer-keystone > 22: 0 0 0 0 GICv2 52 Edge arm-pmu > 23: 0 0 0 0 GICv2 53 Edge arm-pmu > 24: 0 0 0 0 GICv2 54 Edge arm-pmu > 25: 0 0 0 0 GICv2 55 Edge arm-pmu > 26: 0 0 0 0 GICv2 36 Edge > 26202a0.keystone_irq > 27: 1435 0 0 0 GICv2 309 Edge ttyS0 > 29: 0 0 0 0 GICv2 315 Edge > 2530000.i2c > 30: 1 0 0 0 GICv2 318 Edge > 2530400.i2c > 31: 0 0 0 0 GICv2 321 Edge > 2530800.i2c > 32: 69 0 0 0 GICv2 324 Edge > 21000400.spi > 33: 0 0 0 0 GICv2 328 Edge > 21000600.spi > 34: 0 0 0 0 GICv2 332 Edge > 21000800.spi > 70: 0 0 0 0 GICv2 417 Edge > ks-pcie-error-irq > 79: 0 0 0 0 PCI-MSI 0 Edge > PCIe PME, aerdrv > 88: 57 0 0 0 GICv2 80 Level > hwqueue-528 > 89: 57 0 0 0 GICv2 81 Level > hwqueue-529 > 90: 47 0 0 0 GICv2 82 Level > hwqueue-530 > 91: 41 0 0 0 GICv2 83 Level > hwqueue-531 > IPI0: 0 0 0 0 CPU wakeup interrupts > IPI1: 0 0 0 0 Timer broadcast interrupts > IPI2: 730 988 1058 937 Rescheduling interrupts > IPI3: 2 3 4 6 Function call interrupts > IPI4: 0 0 0 0 CPU stop interrupts > IPI5: 0 0 0 0 IRQ work interrupts > IPI6: 0 0 0 0 completion interrupts > > Xen dom0 (Ethernet stops) > # cat /proc/interrupts > CPU0 > 18: 10380 GIC-0 27 Level arch_timer > 19: 0 GIC-0 142 Edge timer-keystone > 20: 88 GIC-0 16 Level events > 21: 0 xen-dyn Edge -event xenbus > 22: 0 GIC-0 36 Edge 26202a0.keystone_irq > 23: 1 GIC-0 312 Edge ttyS0 > 25: 1 GIC-0 318 Edge > 27: 1 GIC-0 324 Edge 21000400.spi > 28: 0 GIC-0 328 Edge 21000600.spi > 29: 0 GIC-0 332 Edge 21000800.spi > 65: 0 GIC-0 417 Edge ks-pcie-error-irq > 74: 0 PCI-MSI 0 Edge PCIe PME, aerdrv > 83: 1 GIC-0 80 Level hwqueue-528 > 84: 1 GIC-0 81 Level hwqueue-529 > 85: 1 GIC-0 82 Level hwqueue-530 > 86: 1 GIC-0 83 Level hwqueue-531 > 115: 87 xen-dyn Edge -virq hvc_console > IPI0: 0 CPU wakeup interrupts > IPI1: 0 Timer broadcast interrupts > IPI2: 0 Rescheduling interrupts > IPI3: 0 Function call interrupts > IPI4: 0 CPU stop interrupts > IPI5: 0 IRQ work interrupts > IPI6: 0 completion interrupts > Err: 0 After getting a chance to look at this a little more, I believe the TX/RX interrupts for the ethernets map like this: eth0 Rx - hwqueue-528 eth1 Rx - hwqueue-529 eth0 Tx - hwqueue-530 eth1 Tx - hwqueue-531 > The interrupt counts in the standlone working kernel seem to roughly correspond to the counts of Tx/Rx messages in ifconfig. Going on that, its clear that only 1 interrupt has been received for Tx and 1 for Rx in the Xen Dom0 equivalent. Any thoughts on this? > > > > Cheers > > Bertrand > > From xen-devel-bounces@lists.xenproject.org Fri Jun 05 19:39:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 19:39:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhIBv-0007R2-RL; Fri, 05 Jun 2020 19:39:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhIBu-0007Qx-Dz for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 19:39:46 +0000 X-Inumbo-ID: 4b461a99-a764-11ea-b024-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4b461a99-a764-11ea-b024-12813bfff9fa; Fri, 05 Jun 2020 19:39:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WzGZH0VH/KPsLvt7CdaAfL+UUdYGryQNxVo0PplCx3c=; b=v74QnQR4tH7fQBpPFVEQGpsHI UbVljsFTM0J330pQFTW8+YutahAs20Zpud3qkESkfjG24osyynS+DfilMYxEsU126ePT+i4s6zti+ mkRfYK2yuakysjv8Co3tsHKPN5MWHHPj1Y/ohKhdOWWLTdB/qIGjtSZU5v7Ry0EMuVb1s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhIBn-0005kK-Bi; Fri, 05 Jun 2020 19:39:39 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhIBn-0005WF-3t; Fri, 05 Jun 2020 19:39:39 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhIBn-0002mF-3F; Fri, 05 Jun 2020 19:39:39 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150867: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=51ca66c37371b10b378513af126646de22eddb17 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Fri, 05 Jun 2020 19:39:39 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150867 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150867/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 51ca66c37371b10b378513af126646de22eddb17 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150438 2020-05-28 14:01:19 Z 8 days Failing since 150465 2020-05-29 09:02:14 Z 7 days 54 attempts Testing same since 150867 2020-06-05 17:00:42 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Igor Druzhinin Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 1497e78068..51ca66c373 51ca66c37371b10b378513af126646de22eddb17 -> smoke From xen-devel-bounces@lists.xenproject.org Fri Jun 05 20:43:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 20:43:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhJBQ-0005cN-GM; Fri, 05 Jun 2020 20:43:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhJBP-0005cI-3J for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 20:43:19 +0000 X-Inumbo-ID: 2eecf520-a76d-11ea-9ad7-bc764e2007e4 Received: from wout2-smtp.messagingengine.com (unknown [64.147.123.25]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2eecf520-a76d-11ea-9ad7-bc764e2007e4; Fri, 05 Jun 2020 20:43:17 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 25DF141A; Fri, 5 Jun 2020 16:43:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 05 Jun 2020 16:43:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=d/klCz Dv7E5k4j6UzvEybo7FT4gyETyaRstTK2pm2gI=; b=vBC5RCkv3WuCTKf+SzUH4Q SyZdk2iLiUiLI2pdwV4V0VnhWq5vbNPjXIhqVGpR0y8S3qi/V0cNFtgUIUepT4UK yuPOtjki3GLySZ1SxwiayaQelO6G6244YXQxFsxjFgCihlV6KhvycC3HuT+4BqqI 6qk4oquScwRVzQVymvgmg0AMdmTMaSqg2vAfwZ7Yh2aNcqz6uF8SBVG2g7oa3ccq SZNonDU+VSarZGf2+bUjWOkkVCSLeOjgKUXsbVC4MF2et/VbZHVdbLjHGqL08qn7 2Wo6W9LOVankpewBG+MPULy4/dQJMEYoF9Ymn5h0sOSKhqSO5o61UiSCqcMMbC1A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepkdforghr vghkucforghrtgiihihkohifshhkihdqifpkrhgvtghkihdkuceomhgrrhhmrghrvghkse hinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomheqnecuggftrfgrthhtvghrnhep fffgudeggedtgeegteehfeevffetieegkeejtdeuleehtddvueffjeeklefhkeehnecuff homhgrihhnpehgihhthhhusgdrtghomhenucfkphepledurdeihedrfeegrdeffeenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmrghrmhgrrh gvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrdgtohhm X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id C173C3061CCB; Fri, 5 Jun 2020 16:43:14 -0400 (EDT) Date: Fri, 5 Jun 2020 22:43:10 +0200 From: 'Marek =?utf-8?Q?Marczykowski-G=C3=B3recki'?= To: paul@xen.org Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Message-ID: <20200605204310.GK98582@mail-itl> References: <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <000701d63b2c$10536930$30fa3b90$@xen.org> <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> <002101d63b3f$4e9dc830$ebd95890$@xen.org> <002201d63b40$1e135ee0$5a3a1ca0$@xen.org> <002f01d63b50$c8b49a70$5a1dcf50$@xen.org> <20200605171353.GG6329@mail-itl> <001501d63b5e$26a991a0$73fcb4e0$@xen.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SR0DFWOzPg+ymaCV" Content-Disposition: inline In-Reply-To: <001501d63b5e$26a991a0$73fcb4e0$@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , 'Jan Beulich' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --SR0DFWOzPg+ymaCV Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom On Fri, Jun 05, 2020 at 06:24:20PM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: 'Marek Marczykowski-G=C3=B3recki' > > Sent: 05 June 2020 18:14 > > To: paul@xen.org > > Cc: 'Jan Beulich' ; 'Andrew Cooper' ; 'xen-devel' > devel@lists.xenproject.org> > > Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0= in stubdom > >=20 > > On Fri, Jun 05, 2020 at 04:48:39PM +0100, Paul Durrant wrote: > > > This (untested) patch might help: > >=20 > > It is different now. I don't get domain_crash because of > > X86EMUL_UNHANDLEABLE anymore, but I still see handle_pio looping for > > some time. But it eventually ends, not really sure why. >=20 > That'll be the shutdown deferral, which I realised later that I forgot ab= out... >=20 > >=20 > > I've tried the patch with a modification to make it build: > >=20 > > > diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c > > > index c55c4bc4bc..8aa8779ba2 100644 > > > --- a/xen/arch/x86/hvm/ioreq.c > > > +++ b/xen/arch/x86/hvm/ioreq.c > > > @@ -109,12 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu = *sv, uint64_t data) > > > ioreq_t *ioreq =3D &v->arch.hvm.hvm_io.io_req; > > > > > > if ( hvm_ioreq_needs_completion(ioreq) ) > > > - { > > > - ioreq->state =3D STATE_IORESP_READY; > > > ioreq->data =3D data; > > > - } > > > - else > > > - ioreq->state =3D STATE_IOREQ_NONE; > > > > > > msix_write_completion(v); > > > vcpu_end_shutdown_deferral(v); >=20 > In fact, move both of these lines... >=20 > > > @@ -209,6 +204,9 @@ bool handle_hvm_io_completion(struct vcpu *v) > > > } > > > } > > > > > > + ioreq->state =3D hvm_ioreq_needs_completion(&vio->ioreq) ? > > vio->io_req->state ... &vio->io_req > >=20 > > > + STATE_IORESP_READY : STATE_IOREQ_NONE; > > > + >=20 > ... to here too. >=20 > > > io_completion =3D vio->io_completion; > > > vio->io_completion =3D HVMIO_no_completion; > > > > >=20 > > The full patch (together with my debug prints): > > https://gist.github.com/marmarek/da37da3722179057a6e7add4fb361e06 The current patch: https://gist.github.com/marmarek/5ae795129c1be2dae13bfc517547c0f1 > I guess it is the destroy being held off by the shutdown deferral? Hopefu= lly the above tweaks should sort that out. Yes, now it works (tried 5 times in a row, previously it crashed on the first or the second one). Thanks! --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --SR0DFWOzPg+ymaCV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7arl4ACgkQ24/THMrX 1yyZxgf/fHIMG20frDFWRvxY7zz087+IPvXEVpbSqGygPKYP35Zs4qp9vyY0V+wx Co3y+UGloILRX1/z7+eh2hxDJbXPtMEQGbkF1+SFFDNKhLTX5W0MGmW+ujX37NFP IvPZf6FsHIfA4GNlf+rlCA7YGO4tWGzSD8QEReqBdoLzkdncfJRbSNtPeu4BV31g OAKhsDIipu9NeN7qPBJkw49tocgsQPEvlyy7GG45IrlCdE+dRUW69Ukaf2u83sgI GtJwSNJ0+V/ieFI9pv5cU7mjGgjrhz8s46Tmfq6PUhYJKC4vJ+da1x+LW4NRWkoa k/78vCkZ/EGAalCDCawPI67foVlHCg== =Cnfr -----END PGP SIGNATURE----- --SR0DFWOzPg+ymaCV-- From xen-devel-bounces@lists.xenproject.org Fri Jun 05 21:25:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 21:25:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhJqI-000150-Pn; Fri, 05 Jun 2020 21:25:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhJqH-00014v-Jr for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 21:25:33 +0000 X-Inumbo-ID: 15f4757e-a773-11ea-b038-12813bfff9fa Received: from aserp2120.oracle.com (unknown [141.146.126.78]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 15f4757e-a773-11ea-b038-12813bfff9fa; Fri, 05 Jun 2020 21:25:32 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 055LCfnP068053; Fri, 5 Jun 2020 21:24:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=aV98zPU93QBvNWrzk/ChQ5VDmnpe9w8rIC4yo8Fb6lM=; b=Q1wCXDw9w/bF7V0bkGC6IvL76x/w0WRjHOjcxmnHanLSCPjsBGyoHCWarj+RUh94mOSJ JOw6GQd3a5lw9KYdYwB2p/gU3zJuSBSrGrcp6GYC6IH07y9J6nCZZj+uTRccUfHts6bd MdUyRr//DuAUp9QUBtGFB4+83Cz9gWQPj0pd9i6KcEhicYRbbQUTTrLaGUHKpeehAJCZ 81LgCPL7zl/DqQu7VMtqkC3X4EK4U8vjMA9l5YLArm6psse7CKjV7A9oD3lz3ZtmSrRt ET2Dx60lQiQPN8gE2bl/ckY4w3R5KJWxgT9i2gvTGQxuSupj4SrfzCWHtvZJZpGjkGwB yQ== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 31f91dvsxd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 05 Jun 2020 21:24:53 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 055LEWQ2149042; Fri, 5 Jun 2020 21:24:52 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 31f927qyn8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Jun 2020 21:24:52 +0000 Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 055LOfOR001022; Fri, 5 Jun 2020 21:24:41 GMT Received: from [10.39.238.70] (/10.39.238.70) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Jun 2020 14:24:41 -0700 Subject: Re: [PATCH 04/12] x86/xen: add system core suspend and resume callbacks To: "Agarwal, Anchal" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "hpa@zytor.com" , "x86@kernel.org" , "jgross@suse.com" , "linux-pm@vger.kernel.org" , "linux-mm@kvack.org" , "Kamata, Munehisa" , "sstabellini@kernel.org" , "konrad.wilk@oracle.com" , "roger.pau@citrix.com" , "axboe@kernel.dk" , "davem@davemloft.net" , "rjw@rjwysocki.net" , "len.brown@intel.com" , "pavel@ucw.cz" , "peterz@infradead.org" , "Valentin, Eduardo" , "Singh, Balbir" , "xen-devel@lists.xenproject.org" , "vkuznets@redhat.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Woodhouse, David" , "benh@kernel.crashing.org" References: <79cf02631dc00e62ebf90410bfbbdb52fe7024cb.1589926004.git.anchalag@amazon.com> <4b577564-e4c3-0182-2b9e-5f79004f32a1@oracle.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: Date: Fri, 5 Jun 2020 17:24:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9643 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 adultscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006050158 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9643 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 bulkscore=0 clxscore=1015 cotscore=-2147483648 malwarescore=0 adultscore=0 priorityscore=1501 suspectscore=0 phishscore=0 spamscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006050158 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/3/20 6:40 PM, Agarwal, Anchal wrote: > CAUTION: This email originated from outside of the organization. Do= not click links or open attachments unless you can confirm the sender an= d know the content is safe. > > > > On 5/19/20 7:26 PM, Anchal Agarwal wrote: > > From: Munehisa Kamata > > > > Add Xen PVHVM specific system core callbacks for PM suspend and > > hibernation support. The callbacks suspend and resume Xen > > primitives,like shared_info, pvclock and grant table. Note that > > Xen suspend can handle them in a different manner, but system > > core callbacks are called from the context. > > > I don't think I understand that last sentence. > > Looks like it may have cryptic meaning of stating that xen_suspend call= s syscore_suspend from xen_suspend > So, if these syscore ops gets called during xen_suspend do not do anyt= hing. Check if the mode is in xen suspend=20 > and return from there. These syscore_ops are specifically for domU hibe= rnation. > I must admit, I may have overlooked lack of explanation of some implici= t details in the original commit msg.=20 > > > So if the callbacks > > are called from Xen suspend context, return immediately. > > > > > > + > > +static int xen_syscore_suspend(void) > > +{ > > + struct xen_remove_from_physmap xrfp; > > + int ret; > > + > > + /* Xen suspend does similar stuffs in its own logic */ > > + if (xen_suspend_mode_is_xen_suspend()) > > + return 0; With your explanation now making this clearer, is this check really necessary? From what I see we are in XEN_SUSPEND mode when lock_system_sleep() lock is taken, meaning that we can't initialize hibernation. > > + > > + xrfp.domid =3D DOMID_SELF; > > + xrfp.gpfn =3D __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT; > > + > > + ret =3D HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &x= rfp); > > + if (!ret) > > + HYPERVISOR_shared_info =3D &xen_dummy_shared_info; > > + > > + return ret; > > +} > > + > > +static void xen_syscore_resume(void) > > +{ > > + /* Xen suspend does similar stuffs in its own logic */ > > + if (xen_suspend_mode_is_xen_suspend()) > > + return; > > + > > + /* No need to setup vcpu_info as it's already moved off */ > > + xen_hvm_map_shared_info(); > > + > > + pvclock_resume(); > > + > > + gnttab_resume(); > > > Do you call gnttab_suspend() in pm suspend path? > No, since it does nothing for HVM guests. The unmap_frames is only appl= icable for PV guests right? You should call it nevertheless. It will decide whether or not anything needs to be done. -boris From xen-devel-bounces@lists.xenproject.org Fri Jun 05 21:40:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 21:40:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhK4l-0002oV-45; Fri, 05 Jun 2020 21:40:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhK4j-0002oQ-Tg for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 21:40:29 +0000 X-Inumbo-ID: 2c522c1a-a775-11ea-ba62-bc764e2007e4 Received: from userp2130.oracle.com (unknown [156.151.31.86]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2c522c1a-a775-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 21:40:29 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 055LW58Y017757; Fri, 5 Jun 2020 21:40:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=92xTSdf3wbaz+/R0fTMy2xdg8meNwxO0k6N5Ns/wDW0=; b=I12g0M++UVMsOKnKxZcKguNHd2Ee2K3XHYVMz5W+kwyrJwTgQ+rx/3GAEgJtmYkCQlrv L94Lm2/njmucq9/7aq+y5QU3b9Qg6DBpgFVoo+9c6grxnVxtdg3tZjoXRS/DthdOv0ny k5DEiRJzwz3RGKN0iBfUtzHORGW8u16ZPVGV/4//99bLNnju6Bm8MNM2FbuuABzAyerI Vy5koEnazbwUixVGRRtBnOIYWO+vSMsiIV2NwuutbF2/INXiv19Rsw45WfKln1wi8D3P Q4o+XrAJ7Mf3GusxPtRQLtipZw0ZiMm1nl3ZaNJ90cFuX//h+eQIW40o1j/HVH8jeNS/ HQ== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 31f9244twh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 05 Jun 2020 21:40:02 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 055LYB2I033194; Fri, 5 Jun 2020 21:40:01 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 31f927ra3d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 05 Jun 2020 21:40:01 +0000 Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 055LdwSK029799; Fri, 5 Jun 2020 21:39:58 GMT Received: from [10.39.238.70] (/10.39.238.70) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 05 Jun 2020 14:39:58 -0700 Subject: Re: [PATCH 03/12] x86/xen: Introduce new function to map HYPERVISOR_shared_info on Resume To: Anchal Agarwal References: <529f544a64bb93b920bf86b1d3f86d93b0a4219b.1589926004.git.anchalag@amazon.com> <72989b50-0c13-7a2b-19e2-de4a3646c83f@oracle.com> <20200604230307.GB25251@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <9644a5f1-e1f8-5fe1-3135-cc6b4baf893b@oracle.com> Date: Fri, 5 Jun 2020 17:39:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200604230307.GB25251@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9643 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 adultscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006050159 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9643 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 adultscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 bulkscore=0 lowpriorityscore=0 cotscore=-2147483648 phishscore=0 spamscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006050159 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: eduval@amazon.com, len.brown@intel.com, peterz@infradead.org, benh@kernel.crashing.org, x86@kernel.org, linux-mm@kvack.org, pavel@ucw.cz, hpa@zytor.com, sstabellini@kernel.org, kamatam@amazon.com, mingo@redhat.com, xen-devel@lists.xenproject.org, sblbir@amazon.com, axboe@kernel.dk, konrad.wilk@oracle.com, bp@alien8.de, tglx@linutronix.de, jgross@suse.com, netdev@vger.kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, vkuznets@redhat.com, davem@davemloft.net, dwmw@amazon.co.uk, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/4/20 7:03 PM, Anchal Agarwal wrote: > On Sat, May 30, 2020 at 07:02:01PM -0400, Boris Ostrovsky wrote: >> CAUTION: This email originated from outside of the organization. Do no= t click links or open attachments unless you can confirm the sender and k= now the content is safe. >> >> >> >> On 5/19/20 7:25 PM, Anchal Agarwal wrote: >>> Introduce a small function which re-uses shared page's PA allocated >>> during guest initialization time in reserve_shared_info() and not >>> allocate new page during resume flow. >>> It also does the mapping of shared_info_page by calling >>> xen_hvm_init_shared_info() to use the function. >>> >>> Signed-off-by: Anchal Agarwal >>> --- >>> arch/x86/xen/enlighten_hvm.c | 7 +++++++ >>> arch/x86/xen/xen-ops.h | 1 + >>> 2 files changed, 8 insertions(+) >>> >>> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hv= m.c >>> index e138f7de52d2..75b1ec7a0fcd 100644 >>> --- a/arch/x86/xen/enlighten_hvm.c >>> +++ b/arch/x86/xen/enlighten_hvm.c >>> @@ -27,6 +27,13 @@ >>> >>> static unsigned long shared_info_pfn; >>> >>> +void xen_hvm_map_shared_info(void) >>> +{ >>> + xen_hvm_init_shared_info(); >>> + if (shared_info_pfn) >>> + HYPERVISOR_shared_info =3D __va(PFN_PHYS(shared_info_pf= n)); >>> +} >>> + >> >> AFAICT it is only called once so I don't see a need for new routine. >> >> > HYPERVISOR_shared_info can only be mapped in this scope without refacto= ring > much of the code. Refactoring what? All am suggesting is --- a/arch/x86/xen/suspend.c +++ b/arch/x86/xen/suspend.c @@ -124,7 +124,9 @@ static void xen_syscore_resume(void) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 return; =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* No need to setup vcpu_info = as it's already moved off */ -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xen_hvm_map_shared_info(); +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xen_hvm_init_shared_info(); +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (shared_info_pfn) +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 HYPERVISOR_shared_info =3D __va(PFN_PHYS(shared_info_pfn)); =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pvclock_resume(); >> And is it possible for shared_info_pfn to be NULL in resume path (whic= h >> is where this is called)? >> >> > I don't think it should be, still a sanity check but I don't think its = needed there > because hibernation will fail in any case if thats the case.=20 If shared_info_pfn is NULL you'd have problems long before hibernation started. We set it in xen_hvm_guest_init() and never touch again. In fact, I'd argue that it should be __ro_after_init. > However, HYPERVISOR_shared_info does needs to be re-mapped on resume as= its been > marked to dummy address on suspend. Its also safe in case va changes. > Does the answer your question? I wasn't arguing whether HYPERVISOR_shared_info needs to be set, I was only saying that shared_info_pfn doesn't need to be tested. -boris From xen-devel-bounces@lists.xenproject.org Fri Jun 05 22:29:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 22:29:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhKqM-0006ya-1W; Fri, 05 Jun 2020 22:29:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhKqL-0006yV-4f for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 22:29:41 +0000 X-Inumbo-ID: 0ad498be-a77c-11ea-ba62-bc764e2007e4 Received: from trent.utfs.org (unknown [2a03:3680:0:3::67]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0ad498be-a77c-11ea-ba62-bc764e2007e4; Fri, 05 Jun 2020 22:29:39 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by trent.utfs.org (Postfix) with ESMTPS id 2E6B95FCDB; Sat, 6 Jun 2020 00:21:56 +0200 (CEST) Date: Fri, 5 Jun 2020 15:21:56 -0700 (PDT) From: Christian Kujau To: Andrew Cooper Subject: Re: 5.7.0 / BUG: kernel NULL pointer dereference / setup_cpu_watcher In-Reply-To: Message-ID: References: User-Agent: Alpine 2.22 (DEB 395 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 5 Jun 2020, Andrew Cooper wrote: > PVH domains don't have the emulated platform device, so Linux will be > finding ~0 when it goes looking in config space. > > The diagnostic should be skipped in that case, to avoid giving the false > impression that something is wrong. Understood, thanks for explaining that. I won't be able to edit arch/x86/xen/platform-pci-unplug.c to fix that though :-\ Christian. -- BOFH excuse #134: because of network lag due to too many people playing deathmatch From xen-devel-bounces@lists.xenproject.org Fri Jun 05 22:31:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 22:31:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhKsV-0007sC-G6; Fri, 05 Jun 2020 22:31:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhKsT-0007s6-Uj for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 22:31:54 +0000 X-Inumbo-ID: 56d87582-a77c-11ea-96fb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 56d87582-a77c-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 22:31:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Y88DBPcxMZB+qb/MnqUHcF+BDWadVXhUEaI03dtYtEw=; b=phLbY1Xd5HfJrUWR/wLReMTUu oY2YnlHWliX2tA04oLm52TOCk5bEuI0mS51tTH3ShR9axXgJGIFBaYTqG/gaS9c/49nVW7xGhHjsQ jx854/IE4gAmjJ8YPfAb/GhIILkQOJzfHiw5pT0h3hcI2WoQuoFu9L9TGy3ie9pSo6Ts0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhKsL-00010C-Jx; Fri, 05 Jun 2020 22:31:45 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhKsL-0006gI-13; Fri, 05 Jun 2020 22:31:45 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhKsL-0006Te-01; Fri, 05 Jun 2020 22:31:45 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150831: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-armhf-armhf-xl-arndale:xen-boot:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=b489f015fbe2bd59d409211f79ea0a8ac5d2a66d X-Osstest-Versions-That: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e From: osstest service owner Date: Fri, 05 Jun 2020 22:31:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150831 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150831/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 7 xen-boot fail REGR. vs. 150694 test-armhf-armhf-xl-vhd 11 guest-start fail REGR. vs. 150694 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150694 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150694 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150694 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: qemuu b489f015fbe2bd59d409211f79ea0a8ac5d2a66d baseline version: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e Last test of basis 150694 2020-06-04 11:44:20 Z 1 days Testing same since 150831 2020-06-05 13:06:20 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Bulekov Kevin Wolf Paolo Bonzini Peter Maydell Philippe Mathieu-Daudé Stefan Hajnoczi Stefano Garzarella Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale fail test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit b489f015fbe2bd59d409211f79ea0a8ac5d2a66d Merge: 66234fee9c 7d2410cea1 Author: Peter Maydell Date: Fri Jun 5 11:53:37 2020 +0100 Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into staging Pull request # gpg: Signature made Fri 05 Jun 2020 10:47:27 BST # gpg: using RSA key 8695A8BFD3F97CDAAC35775A9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi " [full] # gpg: aka "Stefan Hajnoczi " [full] # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha/tags/block-pull-request: block: Factor out bdrv_run_co() exec: Rename qemu_ram_writeback() as qemu_ram_msync() hw/block: Let the NVMe emulated device be target-agnostic memory: Extract memory_region_msync() from memory_region_writeback() memory: Rename memory_region_do_writeback -> memory_region_writeback fuzz: run the main-loop in fork-server process fuzz: add mangled object name to linker script fuzz: fix typo in i440fx-qtest-reboot arguments fuzz: add datadir for oss-fuzz compatability io_uring: use io_uring_cq_ready() to check for ready cqes io_uring: retry io_uring_submit() if it fails with errno=EINTR Signed-off-by: Peter Maydell commit 7d2410cea154bf915fb30179ebda3b17ac36e70e Author: Vladimir Sementsov-Ogievskiy Date: Wed May 20 17:49:01 2020 +0300 block: Factor out bdrv_run_co() We have a few bdrv_*() functions that can either spawn a new coroutine and wait for it with BDRV_POLL_WHILE() or use a fastpath if they are alreeady running in a coroutine. All of them duplicate basically the same code. Factor the common code into a new function bdrv_run_co(). Signed-off-by: Kevin Wolf Signed-off-by: Vladimir Sementsov-Ogievskiy Message-id: 20200520144901.16589-1-vsementsov@virtuozzo.com [Factor out bdrv_run_co_entry too] Signed-off-by: Stefan Hajnoczi commit ab7e41e6679224e5ad8da6d70ed7e645a5a482ab Author: Philippe Mathieu-Daudé Date: Fri May 8 08:24:56 2020 +0200 exec: Rename qemu_ram_writeback() as qemu_ram_msync() Rename qemu_ram_writeback() as qemu_ram_msync() to better match what it does. Suggested-by: Stefan Hajnoczi Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Stefan Hajnoczi Reviewed-by: Richard Henderson Acked-by: Paolo Bonzini Message-id: 20200508062456.23344-5-philmd@redhat.com Signed-off-by: Stefan Hajnoczi commit bc2a2364b8050632a3b3de07f30d88b7f0734845 Author: Philippe Mathieu-Daudé Date: Fri May 8 08:24:55 2020 +0200 hw/block: Let the NVMe emulated device be target-agnostic Now than the non-target specific memory_region_msync() function is available, use it to make this device target-agnostic. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Stefan Hajnoczi Reviewed-by: Richard Henderson Acked-by: Paolo Bonzini Message-id: 20200508062456.23344-4-philmd@redhat.com Signed-off-by: Stefan Hajnoczi commit 9ecc996a3d39bdbf64a488936f97a9496b74ebd8 Author: Philippe Mathieu-Daudé Date: Fri May 8 08:24:54 2020 +0200 memory: Extract memory_region_msync() from memory_region_writeback() Suggested-by: Paolo Bonzini Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Stefan Hajnoczi Reviewed-by: Richard Henderson Acked-by: Paolo Bonzini Message-id: 20200508062456.23344-3-philmd@redhat.com Signed-off-by: Stefan Hajnoczi commit 4dfe59d187d9b218efca8d89c0c2fac1298d8712 Author: Philippe Mathieu-Daudé Date: Fri May 8 08:24:53 2020 +0200 memory: Rename memory_region_do_writeback -> memory_region_writeback We usually use '_do_' for internal functions. Rename memory_region_do_writeback() as memory_region_writeback(). Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Stefan Hajnoczi Reviewed-by: Richard Henderson Acked-by: Paolo Bonzini Message-id: 20200508062456.23344-2-philmd@redhat.com Signed-off-by: Stefan Hajnoczi commit dfd5ddb5680511a2aa5576d8ed01ff214cc0fc03 Author: Alexander Bulekov Date: Mon May 11 23:01:33 2020 -0400 fuzz: run the main-loop in fork-server process Without this, the time since the last main-loop keeps increasing, as the fuzzer runs. The forked children need to handle all the "past-due" timers, slowing them down, over time. With this change, the parent/fork-server process runs the main-loop, while waiting on the child, ensuring that the timer events do not pile up, over time. Signed-off-by: Alexander Bulekov Reviewed-by: Darren Kenny Message-id: 20200512030133.29896-5-alxndr@bu.edu Signed-off-by: Stefan Hajnoczi commit 3b113229c5d5477d34f54fce0a3e8781090c93b6 Author: Alexander Bulekov Date: Mon May 11 23:01:32 2020 -0400 fuzz: add mangled object name to linker script Previously, we relied on "FuzzerTracePC*(.bss*)" to place libfuzzer's fuzzer::TPC object into our contiguous shared-memory region. This does not work for some libfuzzer builds, so this addition identifies the region by its mangled name: *(.bss._ZN6fuzzer3TPCE); Signed-off-by: Alexander Bulekov Reviewed-by: Darren Kenny Message-id: 20200512030133.29896-4-alxndr@bu.edu Signed-off-by: Stefan Hajnoczi commit 6851803a467238ed39408e35b5f2063c1370b156 Author: Alexander Bulekov Date: Mon May 11 23:01:31 2020 -0400 fuzz: fix typo in i440fx-qtest-reboot arguments Signed-off-by: Alexander Bulekov Reviewed-by: Darren Kenny Reviewed-by: Philippe Mathieu-Daudé Message-id: 20200512030133.29896-3-alxndr@bu.edu Signed-off-by: Stefan Hajnoczi commit 7a071a96d3ef48095892c1d1075c0181c8940058 Author: Alexander Bulekov Date: Mon May 11 23:01:30 2020 -0400 fuzz: add datadir for oss-fuzz compatability This allows us to keep pc-bios in executable_dir/pc-bios, rather than executable_dir/../pc-bios, which is incompatible with oss-fuzz' file structure. Signed-off-by: Alexander Bulekov Reviewed-by: Darren Kenny Message-id: 20200512030133.29896-2-alxndr@bu.edu Signed-off-by: Stefan Hajnoczi commit 769335ecb1e8fd9c4317bdff7cfd0f84af7ab2f9 Author: Stefano Garzarella Date: Tue May 19 15:49:42 2020 +0200 io_uring: use io_uring_cq_ready() to check for ready cqes In qemu_luring_poll_cb() we are not using the cqe peeked from the CQ ring. We are using io_uring_peek_cqe() only to see if there are cqes ready, so we can replace it with io_uring_cq_ready(). Signed-off-by: Stefano Garzarella Message-id: 20200519134942.118178-1-sgarzare@redhat.com Signed-off-by: Stefan Hajnoczi commit b4e44c9944e19c8bfc7fbf0c4a6a5e48f3ba3dc0 Author: Stefano Garzarella Date: Tue May 19 15:30:41 2020 +0200 io_uring: retry io_uring_submit() if it fails with errno=EINTR As recently documented [1], io_uring_enter(2) syscall can return an error (errno=EINTR) if the operation was interrupted by a delivery of a signal before it could complete. This should happen when IORING_ENTER_GETEVENTS flag is used, for example during io_uring_submit_and_wait() or during io_uring_submit() when IORING_SETUP_IOPOLL is enabled. We shouldn't have this problem for now, but it's better to prevent it. [1] https://github.com/axboe/liburing/commit/344355ec6619de8f4e64584c9736530b5346e4f4 Signed-off-by: Stefano Garzarella Message-id: 20200519133041.112138-1-sgarzare@redhat.com Signed-off-by: Stefan Hajnoczi From xen-devel-bounces@lists.xenproject.org Fri Jun 05 23:43:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 05 Jun 2020 23:43:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhLzi-000699-PJ; Fri, 05 Jun 2020 23:43:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhLzi-000694-1v for xen-devel@lists.xenproject.org; Fri, 05 Jun 2020 23:43:26 +0000 X-Inumbo-ID: 58d78026-a786-11ea-96fb-bc764e2007e4 Received: from mail-qv1-xf43.google.com (unknown [2607:f8b0:4864:20::f43]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 58d78026-a786-11ea-96fb-bc764e2007e4; Fri, 05 Jun 2020 23:43:24 +0000 (UTC) Received: by mail-qv1-xf43.google.com with SMTP id e20so5608312qvu.0 for ; Fri, 05 Jun 2020 16:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4oKka4He3nRW9OgSI9rsgItl0j6AS9IA/l25DC/YHdk=; b=el/2NraBp3xuQ6JOdeJKDO1SKrkNXv03TIU/cHSPGOLcoazpUqpDf/wmVxmhxU0iU2 KZtd97gf7017uBaOEy+xsywUK1vtO3th7PAbITbYnEaXNnORJNgh5KeTUgj/uKhFMhbT wHe+V9zECrLlyet0r0MCfWXvJppdS2S4eKXCACdeKCsPJVSSP8593EQoNBdRqEwDKflV E1s4mk4olJiD4X8oC+ac7yaGxC8p4Z8uieT6zCSiGYU/QY36tPNITGbYIvcCEhHKd/UF ikycvLcUerd/7mc1RrW7dkja8z/+ryV3FDC74+xcv43Ycxvyki6kCSyfnpEwyD9cxlp1 cTSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4oKka4He3nRW9OgSI9rsgItl0j6AS9IA/l25DC/YHdk=; b=YTWoYaQ6AMf7fFJxBN9jRFsI9Z5RZe6Mc4JWYi7oWvI+LIbF0oSQIyTPyhTi+OFt5a 5PaNoKXk3OkH5dw94OpxnABTaNN6qnr/zCn+IJ5M4fGhcf/1exPp5LSrtKJijNoQWRsZ HU8QN2txQ8cNHyqKQCBebsNG9JL22k2wS1jdxcgjOJZD4PTXd1jRU1T+uFvrr4RGyDo/ r7NSU2THO3K66aPU6gxcUBdUyg2W0ikVSkYSzmVVdGZs3RqTaW/nHVFsgc9lYAB+PaII 09LrTZvhTfzSrTqvt2t5SpTfykIAACikRKN6CujYqcr0jUKh29lzNPNWqgsfUn5FtZz6 A9wg== X-Gm-Message-State: AOAM530Xu0jJY4Kp2c6dT8f8Wt4ZFVqhuYSeK3Js2sSsNrELmI4D81/M zg1Qkp5a1g/Mo45cy0gWKPYOdotRh9VfFA8MuQBKLw== X-Google-Smtp-Source: ABdhPJwcniVNNo4EhtxwgacSCSgMm1FVB40bFpT+gHMVg7J78OLLWTQWEeEthzFefXL4v9p7W1l9sY8GMXiVsPFue+A= X-Received: by 2002:a05:6214:1c3:: with SMTP id c3mr12187299qvt.19.1591400604218; Fri, 05 Jun 2020 16:43:24 -0700 (PDT) MIME-Version: 1.0 References: <20200605110240.52545-1-roger.pau@citrix.com> In-Reply-To: <20200605110240.52545-1-roger.pau@citrix.com> From: Roman Shaposhnik Date: Fri, 5 Jun 2020 16:43:12 -0700 Message-ID: Subject: Re: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC for PVH dom0 To: Roger Pau Monne Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Jan Beulich , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 5, 2020 at 4:03 AM Roger Pau Monne wrote= : > > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > code paths (guest_io_{write/read}), but those accesses where never > implemented for PVHv2 dom0. This patch provides such mediated accesses > to the RTC for PVH dom0, just like it's provided for a classic PV > dom0. > > Pull out some of the RTC logic from guest_io_{read/write} into > specific helpers that can be used by both PV and HVM guests. The > setup of the handlers for PVH is done in rtc_init, which is already > used to initialize the fully emulated RTC. > > Without this a Linux PVH dom0 will read garbage when trying to access > the RTC, and one vCPU will be constantly looping in > rtc_timer_do_work. > > Note that such issue doesn't happen on domUs because the ACPI > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > accesses are not emulated but rather forwarded to the physical > hardware. > > No functional change expected for classic PV dom0. For the dense guys like me: what is the user-visible feature that is now be= ing offered with this? Would really appreciate a pointer or two. Thanks, Roman. > > Signed-off-by: Roger Pau Monn=C3=A9 > --- > for-4.14 reasoning: the fix is mostly isolated to PVH dom0, and as > such the risk is very low of causing issues to other guests types, but > without this fix one vCPU when using a Linux dom0 will be constantly > looping over rtc_timer_do_work with 100% CPU usage, at least when > using Linux 4.19 or newer. > --- > Changes since v1: > - Share the code with PV. > - Add access checks to the IO ports. > --- > xen/arch/x86/hvm/rtc.c | 34 ++++++++++++++++++ > xen/arch/x86/pv/emul-priv-op.c | 28 +++------------ > xen/arch/x86/time.c | 59 +++++++++++++++++++++++++++++++ > xen/include/asm-x86/mc146818rtc.h | 3 ++ > 4 files changed, 100 insertions(+), 24 deletions(-) > > diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c > index 5bbbdc0e0f..9f304a0fb4 100644 > --- a/xen/arch/x86/hvm/rtc.c > +++ b/xen/arch/x86/hvm/rtc.c > @@ -22,6 +22,7 @@ > * IN THE SOFTWARE. > */ > > +#include > #include > #include > #include > @@ -808,10 +809,43 @@ void rtc_reset(struct domain *d) > s->pt.source =3D PTSRC_isa; > } > > +/* RTC mediator for HVM hardware domain. */ > +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, > + uint32_t *val) > +{ > + if ( dir =3D=3D IOREQ_READ ) > + *val =3D ~0; > + > + if ( size !=3D 1 ) > + { > + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); > + return X86EMUL_OKAY; > + } > + if ( !ioports_access_permitted(current->domain, port, port) ) > + { > + gdprintk(XENLOG_WARNING, "access to RTC port %x not allowed\n", = port); > + return X86EMUL_OKAY; > + } > + > + if ( dir =3D=3D IOREQ_WRITE ) > + rtc_guest_write(port, *val); > + else > + *val =3D rtc_guest_read(port); > + > + return X86EMUL_OKAY; > +} > + > void rtc_init(struct domain *d) > { > RTCState *s =3D domain_vrtc(d); > > + if ( is_hardware_domain(d) ) > + { > + /* Hardware domain gets mediated access to the physical RTC. */ > + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); > + return; > + } > + > if ( !has_vrtc(d) ) > return; > > diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-o= p.c > index fad6c754ad..1597f27ed9 100644 > --- a/xen/arch/x86/pv/emul-priv-op.c > +++ b/xen/arch/x86/pv/emul-priv-op.c > @@ -280,19 +280,10 @@ static uint32_t guest_io_read(unsigned int port, un= signed int bytes, > { > sub_data =3D pv_pit_handler(port, 0, 0); > } > - else if ( port =3D=3D RTC_PORT(0) ) > - { > - sub_data =3D currd->arch.cmos_idx; > - } > - else if ( (port =3D=3D RTC_PORT(1)) && > + else if ( (port =3D=3D RTC_PORT(0) || port =3D=3D RTC_PORT(1)) &= & > ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(= 1)) ) > { > - unsigned long flags; > - > - spin_lock_irqsave(&rtc_lock, flags); > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > - sub_data =3D inb(RTC_PORT(1)); > - spin_unlock_irqrestore(&rtc_lock, flags); > + sub_data =3D rtc_guest_read(port); > } > else if ( (port =3D=3D 0xcf8) && (bytes =3D=3D 4) ) > { > @@ -413,21 +404,10 @@ static void guest_io_write(unsigned int port, unsig= ned int bytes, > { > pv_pit_handler(port, (uint8_t)data, 1); > } > - else if ( port =3D=3D RTC_PORT(0) ) > - { > - currd->arch.cmos_idx =3D data; > - } > - else if ( (port =3D=3D RTC_PORT(1)) && > + else if ( (port =3D=3D RTC_PORT(0) || port =3D=3D RTC_PORT(1)) &= & > ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(= 1)) ) > { > - unsigned long flags; > - > - if ( pv_rtc_handler ) > - pv_rtc_handler(currd->arch.cmos_idx & 0x7f, data); > - spin_lock_irqsave(&rtc_lock, flags); > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > - outb(data, RTC_PORT(1)); > - spin_unlock_irqrestore(&rtc_lock, flags); > + rtc_guest_write(port, data); > } > else if ( (port =3D=3D 0xcf8) && (bytes =3D=3D 4) ) > { > diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c > index bbaea3aa65..e1c81067ce 100644 > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1110,6 +1111,64 @@ static unsigned long get_cmos_time(void) > return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec= ); > } > > +/* Helpers for guest accesses to the physical RTC. */ > +unsigned int rtc_guest_read(unsigned int port) > +{ > + const struct domain *currd =3D current->domain; > + unsigned long flags; > + unsigned int data =3D ~0; > + > + ASSERT(port =3D=3D RTC_PORT(0) || port =3D=3D RTC_PORT(1)); > + if ( !ioports_access_permitted(currd, port, port) ) > + { > + ASSERT_UNREACHABLE(); > + return data; > + } > + > + switch ( port ) > + { > + case RTC_PORT(0): > + data =3D currd->arch.cmos_idx; > + break; > + > + case RTC_PORT(1): > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + data =3D inb(RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + } > + > + return data; > +} > + > +void rtc_guest_write(unsigned int port, unsigned int data) > +{ > + struct domain *currd =3D current->domain; > + unsigned long flags; > + > + ASSERT(port =3D=3D RTC_PORT(0) || port =3D=3D RTC_PORT(1)); > + if ( !ioports_access_permitted(currd, port, port) ) > + { > + ASSERT_UNREACHABLE(); > + return; > + } > + > + switch ( port ) > + { > + case RTC_PORT(0): > + currd->arch.cmos_idx =3D data; > + break; > + > + case RTC_PORT(1): > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + outb(data, RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + } > +} > + > static unsigned long get_wallclock_time(void) > { > #ifdef CONFIG_XEN_GUEST > diff --git a/xen/include/asm-x86/mc146818rtc.h b/xen/include/asm-x86/mc14= 6818rtc.h > index 8758528f7c..803b236c0a 100644 > --- a/xen/include/asm-x86/mc146818rtc.h > +++ b/xen/include/asm-x86/mc146818rtc.h > @@ -110,4 +110,7 @@ outb_p((val),RTC_PORT(1)); \ > > #define RTC_IRQ 8 > > +unsigned int rtc_guest_read(unsigned int port); > +void rtc_guest_write(unsigned int port, unsigned int data); > + > #endif /* _ASM_MC146818RTC_H */ > -- > 2.26.2 > > From xen-devel-bounces@lists.xenproject.org Sat Jun 06 00:29:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 00:29:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhMi5-0002HK-Av; Sat, 06 Jun 2020 00:29:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhMi3-0002HF-H3 for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 00:29:15 +0000 X-Inumbo-ID: bf8a1a58-a78c-11ea-b05b-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bf8a1a58-a78c-11ea-b05b-12813bfff9fa; Sat, 06 Jun 2020 00:29:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VY/JJisFM4lFaXRgh6pG0wncSS/6tHnjG78GD8joIR4=; b=ufeRPh13P58PO8alXaQ5dK7ge wO//4RlImDmzNBOj81AavxKoZMyTwhgk2aKX25k9CbRrE/4+2O/k2CZ03sy9nyFXpi5wkT6XAU90a 7Nu1WOvJCGMPPWE5VduNPIjVXhrIe4Bgz2EFWP9apaZbNTUGtCROnuEIMx5hTrRRF7KDQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhMi1-0003z5-Fp; Sat, 06 Jun 2020 00:29:13 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhMi1-00062w-5H; Sat, 06 Jun 2020 00:29:13 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhMi1-0003rz-4b; Sat, 06 Jun 2020 00:29:13 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xtf test] 150870: all pass - PUSHED X-Osstest-Versions-This: xtf=2a8859e87761a0efc119778e094f203dc2ea487a X-Osstest-Versions-That: xtf=cce0ffab7cc43c810580889a197662d77f2d8ebd From: osstest service owner Date: Sat, 06 Jun 2020 00:29:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150870 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150870/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 2a8859e87761a0efc119778e094f203dc2ea487a baseline version: xtf cce0ffab7cc43c810580889a197662d77f2d8ebd Last test of basis 150667 2020-06-03 21:09:33 Z 2 days Testing same since 150870 2020-06-05 20:09:44 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Pawel Wieczorkiewicz jobs: build-amd64-xtf pass build-amd64 pass build-amd64-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xtf.git cce0ffa..2a8859e 2a8859e87761a0efc119778e094f203dc2ea487a -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Jun 06 01:57:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 01:57:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhO5c-0003Ra-0x; Sat, 06 Jun 2020 01:57:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhO5a-0003RV-Q0 for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 01:57:38 +0000 X-Inumbo-ID: 18871da2-a799-11ea-9ad7-bc764e2007e4 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (unknown [40.107.94.77]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 18871da2-a799-11ea-9ad7-bc764e2007e4; Sat, 06 Jun 2020 01:57:37 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C5yQDjzeZA2ZW+wNypy1gdacpwbr1reaXhH53PdTTdrlmjH0GN7ZaT86RhEFo6qx34WDjeSuKEpnCe9pNk5zCRH+cNp6Lc0cDBUD40E4OAS1f420j+LwXmDXQb3F7cXNBW7Ry75lHyt181hiJJEv5ZOpRWhKLNcg6JrBArV24WL6jd8rsk4p+rORyfPy32omdaj7EpxSX/M2tXcAZ0bRsx2LjWPuY9dK61adf6ErI5ecY66luXfXtNSL7wAy3pPHJs+PvdLx2DjV70y8ui+65g0YMsdkaVJSgb2EKZVbXJWFlXYMRl1oFJWLUunYq5xXKKChKDTM6yp0qrj2hU9b7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1SWa+4wJIr8PRP73/Tk/e3pk3rHG+XUoUaeUkeyzsHY=; b=EAsUK8fJs+gDYpTBXhaWeb9jxlyw7KFcWXcSIU1ag/WcRYBF11PYHUOh/DelF5VCUGIG1blreFjdLXhOV/pcM9YP1RbeI6wUawkr4agWMnBBqgKFgzH1XyOF4M3tXGp4VPOwuXFq76Cqbl6ul1XB6y5IREgKWY0ogJebMZ8X3hKV/ysQj6OajXjXFcXp+nC3mqJNaCUPrCxM1jmhGLXzGZ0+NAxbuNu7Yz/U48uacLaUPuqPeGABuoCC1Qq4t3RrnSJyMvYBJdojDVr+FG8h4iOzfA0yF7iVQLyWPn+AxPQsdYjLIgKXtqx+WwkgxWJKtWLziM1HrfICn7WqqwxsCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.60.83) smtp.rcpttodomain=tklengyel.com smtp.mailfrom=xilinx.com; dmarc=bestguesspass action=none header.from=xilinx.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1SWa+4wJIr8PRP73/Tk/e3pk3rHG+XUoUaeUkeyzsHY=; b=p2ND2FpwOgqySFy26jzXXrcDXbm7CDu2Fjcoj3yDZkrVGcp7Frm5TaIQS/9jdgFtCoxr65rfO33N7nAam6vBmIeuuLAlJfhsMJHZQ+wuGaGEe85mCi1UCHuUusm/HxhEUf33XTUaN58kv17m39MTs3ksDLQcLH8PSiCGFlICn4w= Received: from MN2PR14CA0005.namprd14.prod.outlook.com (2603:10b6:208:23e::10) by BY5PR02MB6771.namprd02.prod.outlook.com (2603:10b6:a03:200::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Sat, 6 Jun 2020 01:57:35 +0000 Received: from BL2NAM02FT032.eop-nam02.prod.protection.outlook.com (2603:10b6:208:23e:cafe::bc) by MN2PR14CA0005.outlook.office365.com (2603:10b6:208:23e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Sat, 6 Jun 2020 01:57:35 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 149.199.60.83) smtp.mailfrom=xilinx.com; tklengyel.com; dkim=none (message not signed) header.d=none;tklengyel.com; dmarc=bestguesspass action=none header.from=xilinx.com; Received-SPF: Pass (protection.outlook.com: domain of xilinx.com designates 149.199.60.83 as permitted sender) receiver=protection.outlook.com; client-ip=149.199.60.83; helo=xsj-pvapsmtpgw01; Received: from xsj-pvapsmtpgw01 (149.199.60.83) by BL2NAM02FT032.mail.protection.outlook.com (10.152.77.169) with Microsoft SMTP Server id 15.20.3066.18 via Frontend Transport; Sat, 6 Jun 2020 01:57:35 +0000 Received: from [149.199.38.66] (port=48896 helo=xsj-pvapsmtp01) by xsj-pvapsmtpgw01 with esmtp (Exim 4.90) (envelope-from ) id 1jhO4k-0007JX-0W; Fri, 05 Jun 2020 18:56:46 -0700 Received: from [127.0.0.1] (helo=localhost) by xsj-pvapsmtp01 with smtp (Exim 4.63) (envelope-from ) id 1jhO5X-0004eT-5w; Fri, 05 Jun 2020 18:57:35 -0700 Received: from xsj-pvapsmtp01 (xsj-smtp1.xilinx.com [149.199.38.66]) by xsj-smtp-dlp2.xlnx.xilinx.com (8.13.8/8.13.1) with ESMTP id 0561vUWZ013636; Fri, 5 Jun 2020 18:57:30 -0700 Received: from [172.19.2.220] (helo=localhost) by xsj-pvapsmtp01 with esmtp (Exim 4.63) (envelope-from ) id 1jhO5S-0004e6-H9; Fri, 05 Jun 2020 18:57:30 -0700 Date: Fri, 5 Jun 2020 18:57:30 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH] xen/rpi4: implement watchdog-based reset In-Reply-To: Message-ID: References: <20200603223156.12767-1-sstabellini@kernel.org> <3b3fa1cd-e50a-66f7-f5ac-eebc6f1d0953@xen.org> <24026a53-044b-843c-e548-22bb8325e5a7@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1812385704-1591291830=:6774" Content-ID: X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.2.0.1013-23620.005 X-TM-AS-User-Approved-Sender: Yes;Yes X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:149.199.60.83; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:xsj-pvapsmtpgw01; PTR:unknown-60-83.xilinx.com; CAT:NONE; SFTY:; SFS:(7916004)(136003)(346002)(39860400002)(396003)(376002)(46966005)(8676002)(6916009)(4326008)(426003)(478600001)(336012)(9786002)(8936002)(9686003)(70206006)(70586007)(107886003)(966005)(44832011)(33964004)(54906003)(316002)(33716001)(186003)(47076004)(53546011)(356005)(26005)(83380400001)(82310400002)(82740400003)(81166007)(2906002)(5660300002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0fbc4ad1-dfbf-404d-c81c-08d809bcfbc9 X-MS-TrafficTypeDiagnostic: BY5PR02MB6771: X-Microsoft-Antispam-PRVS: X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 04267075BD X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: h8QWAo4jIw2wENYKKfCy2TfV886s4+trn1RbGEsiuWng0CUmpX0v6nCkCner8XUGUGhcJihr95a9AYPvSgUWklqPF1Zjcu04brmwY3kOgtwtCjLERBRqpNPOKV0Mi0fHBmNRdKBrHi8lEQ9j7l30Q2gGvrra5igy2TDhrJ9MmzJxVtMbPVucc2BN43RSxm/9PurZgKhy2ea9ZFYnbIiL4/YJ1DaZDtZz5snkLLiX3xHbL+KW7MciQH5TA3dw2HwtZm3jtkbm6AvRViJwUJTyMbvASr8keCDZ6PaZbsGJet7gKjjRwhOjgz0QXyWAfzQK3qlLX5nwXiCSehj9NIHQ0HQlMdIRU3K3MsxjvB+y4sTm5xH4WM7AVJ0i60c0S+DJ48EYbs/q8DOwBwk9xS2tevlyE73Mr942Zgo1RUsD8k3GGuEryd4PDLstHCX5nmYONdtpkQ2mmvMzxxyTNgP6tTQ4TNsTDX9cYtOTjNmR9aI= X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2020 01:57:35.5622 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0fbc4ad1-dfbf-404d-c81c-08d809bcfbc9 X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.60.83]; Helo=[xsj-pvapsmtpgw01] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR02MB6771 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: cminyard@mvista.com, Stefano Stabellini , =?UTF-8?Q?Andr=C3=A9_Przywara?= , roman@zededa.com, tamas@tklengyel.com, xen-devel@lists.xenproject.org, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1812385704-1591291830=:6774 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Thu, 4 Jun 2020, Julien Grall wrote: > On 04/06/2020 17:46, Stefano Stabellini wrote: > > On Thu, 4 Jun 2020, Andr=C3=A9 Przywara wrote: > > > On 04/06/2020 17:24, Stefano Stabellini wrote: > > > > On Thu, 4 Jun 2020, Andr=C3=A9 Przywara wrote: > > > > > On 04/06/2020 09:48, Julien Grall wrote: > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > > On 03/06/2020 23:31, Stefano Stabellini wrote: > > > > > > > Touching the watchdog is required to be able to reboot the bo= ard. > > > > > >=20 > > > > > > In general the preferred method is PSCI. Does it mean RPI 4 doe= sn't > > > > > > support PSCI at all? > > > > >=20 > > > > > There is mainline Trusted Firmware (TF-A) support for the RPi4 fo= r a > > > > > few > > > > > months now, which includes proper PSCI support (both for SMP brin= gup > > > > > and > > > > > system reset/shutdown). At least that should work, if not, it's a= bug. > > > > > An EDK-2 build for RPi4 bundles TF-A automatically, but you can u= se > > > > > TF-A > > > > > without it, with or without U-Boot: It works as a drop-in replace= ment > > > > > for armstub.bin. Instruction for building it (one line!) are here= : > > > > > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/= docs/plat/rpi4.rst > > > > >=20 > > > > > > >=20 > > > > > > > The implementation is based on > > > > > > > drivers/watchdog/bcm2835_wdt.c:__bcm2835_restart in Linux. > > > > > >=20 > > > > > > Can you give the baseline? This would allow us to track an issu= e and > > > > > > port them. > > > > >=20 > > > > > Given the above I don't think it's a good idea to add extra platf= orm > > > > > specific code to Xen. > > > >=20 > > > > The RPi4, at least the one I have, doesn't come with any TF, and it > > >=20 > > > My RPi4 didn't come with anything, actually ;-) It's just a matter of > > > what you put in the uSD card slot. > > >=20 > > > > doesn't come with PSCI in device tree. > > >=20 > > > TF-A patches the PSCI nodes in: > > > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/pl= at/rpi/rpi4?id=3Df67fa69cb6937a7fc559bbec4a7acce5edefa888 > > >=20 > > > > As a user, I would rather have > > > > this patch (even downstream) than having to introduce TF in my buil= d and > > > > deployment just to be able to reboot. > > >=20 > > > I get your point, but would rather put more pressure on people using > > > TF-A. After all you run without CPU hotplug, A72 errata workarounds a= nd > > > without Spectre/Meltdown fixes. What was the IP address of your board > > > again? ;-) > >=20 > > Please send a pull request to remove __bcm2835_restart from the Linux > > kernel, once it is removed from there I'd be happy to take it away from > > Xen too ;-) >=20 > Xen is not a slave of Linux. We make our own informed decision ;). >=20 > >=20 > > I know I am being cheeky but we have enough battles to fight and enough > > problems with Xen -- I don't think we should use the hypervisor as a > > leverage to get people to use or upgrade TF. We just need to get good > > functionalities to our users with the less amount of friction possible. >=20 > Well it is nice to have functionality but you also need to have Xen runni= ng > reliably and safely. No-one wants to drive in car with no brake on a wind= y > road. Or maybe I am wrong? ;) >=20 > >=20 > > Everything you mentioned are good reason to use TF, and this patch does > > not take anything away from it. My suggestion would be to work with > > raspberrypi.org to have TF installed by default by the =09. >=20 > We actually did use the hypervisor as a leverage in the past. A pretty go= od > example is RPI 3. >=20 > Anyway, the patch is pretty simple and limited to the platform. So I woul= d be > inclined to accept it. OK, thank you, that it also what I think. > Although this is just sweeping stability concern under the carpet and hop= ing > for the best. What are the odds this is going to be used in production li= ke > that? We are writing a wikipage to explain how to boot Xen on RPi4, because of the unique firmware/bootloader and the non-upstream patches. We can add a recommandation to use TF for production to the wikipage. --8323329-1812385704-1591291830=:6774-- From xen-devel-bounces@lists.xenproject.org Sat Jun 06 04:42:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 04:42:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhQeL-0003AG-Q0; Sat, 06 Jun 2020 04:41:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhQeK-0003AB-CM for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 04:41:40 +0000 X-Inumbo-ID: ff3a01b8-a7af-11ea-9b55-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ff3a01b8-a7af-11ea-9b55-bc764e2007e4; Sat, 06 Jun 2020 04:41:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pfcAfW2lOspJvB0U9Q/7cEPDj7Yeu0m41lVxHxoAQEg=; b=Wns9vio9yxgKYORfzAsIEtyIr alVFe2pvLiQhQInIEC0MlPGvuVHiPIq60yrzaohckd/gaLLcaNxqo/Vx9sMtxxfgVumTz0lOJufdL mKn5RaBGCRCeIT2RjebVrpstZUnrtE+1KhrPIObbDYy47n9JsvH/JE0PmfgCRA3Fyp2vg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhQeC-0002f8-9b; Sat, 06 Jun 2020 04:41:32 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhQeB-0005iD-Vp; Sat, 06 Jun 2020 04:41:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhQeB-0001Cl-Uv; Sat, 06 Jun 2020 04:41:31 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150869: regressions - FAIL X-Osstest-Failures: xen-unstable:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=51ca66c37371b10b378513af126646de22eddb17 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Sat, 06 Jun 2020 04:41:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150869 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150869/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 150714 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150551 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150635 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150674 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150674 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150674 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150674 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150714 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150714 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150714 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150714 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150714 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: xen 51ca66c37371b10b378513af126646de22eddb17 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150714 2020-06-05 01:52:44 Z 1 days Testing same since 150869 2020-06-05 20:06:13 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Igor Druzhinin Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1599 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 06 06:50:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 06:50:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhSew-0007I2-EX; Sat, 06 Jun 2020 06:50:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhSev-0007Hx-O4 for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 06:50:25 +0000 X-Inumbo-ID: fbdfefd4-a7c1-11ea-ba62-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fbdfefd4-a7c1-11ea-ba62-bc764e2007e4; Sat, 06 Jun 2020 06:50:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GGOBaF0Y8x9SNiFvFJ726/x1qSYqLbCzWtU2+PZjv/Q=; b=cxUzb8PJuAsGAM5nHHk+RwNPA mw0yNAn/ijE1nLDXS96o0Z1Z9Efk90uuEBTHyJKiYVTvFzFcEOSPrnVa0MntFm3gNhZmtnZlui5Ho 5TTXcSKD1uKrvvKEnboA7x9DHuX+ynLp3iX2MbQ8y2Z6826lGrD4njCnhzwh7RLikbw0E=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhSen-0005fy-ME; Sat, 06 Jun 2020 06:50:17 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhSen-0003G8-Dd; Sat, 06 Jun 2020 06:50:17 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhSen-00032f-Cx; Sat, 06 Jun 2020 06:50:17 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150871: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=7ae77150d94d3b535c7b85e6b3647113095e79bf X-Osstest-Versions-That: linux=435faf5c218a47fd6258187f62d9bb1009717896 From: osstest service owner Date: Sat, 06 Jun 2020 06:50:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150871 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150871/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150814 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150814 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150814 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150814 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150814 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150814 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150814 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150814 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150814 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150814 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: linux 7ae77150d94d3b535c7b85e6b3647113095e79bf baseline version: linux 435faf5c218a47fd6258187f62d9bb1009717896 Last test of basis 150814 2020-06-05 07:08:13 Z 0 days Testing same since 150871 2020-06-05 21:09:12 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alistair Popple Andrew Donnellan Andrey Abramov Andy Lutomirski Aneesh Kumar K.V Arnd Bergmann Borislav Petkov Bulent Abali Chen Zhou Christian Zigotzky Christoph Hellwig Christophe JAILLET Christophe Leroy Christophe Leroy Cédric Le Goater Dmitry Torokhov Emmanuel Nicolet Erhard F. Frederic Barrat Gautham R. Shenoy Geoff Levand Gustavo A. R. Silva Gustavo Walbon Haren Myneni Hari Bathini Herbert Xu huhai Jessica Yu Jordan Niethe Kajol Jain Kees Cook Leonardo Bras Leonardo Bras Linus Torvalds Madhavan Srinivasan Mahesh Salgaonkar Markus Elfring Michael Ellerman Michael Neuling Michal Simek Nathan Chancellor Naveen N. Rao Nicholas Piggin Oliver O'Halloran Peter Zijlstra (Intel) Peter Zijlstra Pingfan Liu Qian Cai Ram Pai Raphael Moreira Zinsly Ravi Bangoria Sam Bobroff Sandipan Das Segher Boessenkool Stephen Rothwell Sukadev Bhattiprolu Sukadev Bhattiprolu Takashi Iwai Thomas Gleixner Wolfram Sang Xiongfeng Wang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 435faf5c218a..7ae77150d94d 7ae77150d94d3b535c7b85e6b3647113095e79bf -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Sat Jun 06 08:53:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 08:53:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhUZv-0002dt-Sg; Sat, 06 Jun 2020 08:53:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhUZv-0002dn-5u for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 08:53:23 +0000 X-Inumbo-ID: 29cf7e6c-a7d3-11ea-b0af-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 29cf7e6c-a7d3-11ea-b0af-12813bfff9fa; Sat, 06 Jun 2020 08:53:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/4ck4OTUxxuvjTJ08tenuLUEpRe7dzKaO410FuImQsU=; b=zMDkopo76Yn+iyethFJu6OEUA 9EoT78JzR/muvHYMFsXwghm29vSPsUIawwNEymaEDfzc7pKYJsDLx/PICBTimcL4NEuySfK3H+955 BQ7y+QcAzUMCeDUSMFEHI/0AWujmycdG8m8HotfCWJ8mjGqya1qJ0A+pp/9+ZdQCZGnTI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhUZo-0000HA-Jw; Sat, 06 Jun 2020 08:53:16 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhUZo-0007rw-8v; Sat, 06 Jun 2020 08:53:16 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhUZo-0002mS-8F; Sat, 06 Jun 2020 08:53:16 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150872: regressions - trouble: broken/fail/pass X-Osstest-Failures: qemu-mainline:test-amd64-i386-xl::broken:regression qemu-mainline:test-amd64-i386-libvirt-xsm::broken:regression qemu-mainline:test-amd64-amd64-xl-rtds::broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64::broken:regression qemu-mainline:test-amd64-amd64-i386-pvgrub::broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm::broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict::broken:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd::broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-i386-pvgrub:syslog-server:broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:host-ping-check-xen:fail:regression qemu-mainline:test-amd64-i386-xl:guest-localmigrate/x10:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:guest-start/redhat.repeat:fail:regression qemu-mainline:test-amd64-amd64-i386-pvgrub:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start/debian.repeat:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:guest-start/debianhvm.repeat:fail:regression qemu-mainline:test-amd64-amd64-xl-rtds:capture-logs(19):broken:allowable qemu-mainline:test-amd64-amd64-i386-pvgrub:capture-logs(11):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:capture-logs(11):broken:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:capture-logs(9):broken:nonblocking qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:capture-logs(13):broken:nonblocking qemu-mainline:test-amd64-i386-xl:capture-logs(19):broken:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:capture-logs(19):broken:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:capture-logs(19):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: qemuu=175198ad91d8bac540159705873b4ffe4fb94eab X-Osstest-Versions-That: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e From: osstest service owner Date: Sat, 06 Jun 2020 08:53:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150872 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150872/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl broken test-amd64-i386-libvirt-xsm broken test-amd64-amd64-xl-rtds broken test-amd64-i386-xl-qemuu-debianhvm-amd64 broken test-amd64-amd64-xl-qemuu-ws16-amd64 broken test-amd64-amd64-i386-pvgrub broken test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-i386-xl-qemuu-debianhvm-amd64 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-i386-pvgrub 3 syslog-server broken REGR. vs. 150694 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 8 host-ping-check-xen fail REGR. vs. 150694 test-amd64-i386-xl 18 guest-localmigrate/x10 fail REGR. vs. 150694 test-amd64-i386-qemuu-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 150694 test-amd64-amd64-i386-pvgrub 10 debian-di-install fail REGR. vs. 150694 test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail REGR. vs. 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 150694 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 18 guest-start/debianhvm.repeat fail REGR. vs. 150694 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 19 capture-logs(19) broken REGR. vs. 150694 Tests which did not succeed, but are not blocking: test-amd64-amd64-i386-pvgrub 11 capture-logs(11) broken blocked in 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 11 capture-logs(11) broken blocked in 150694 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 9 capture-logs(9) broken never pass test-amd64-i386-qemuu-rhel6hvm-amd 13 capture-logs(13) broken never pass test-amd64-i386-xl 19 capture-logs(19) broken never pass test-amd64-i386-libvirt-xsm 19 capture-logs(19) broken never pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 19 capture-logs(19) broken never pass test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150694 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150694 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150694 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuu 175198ad91d8bac540159705873b4ffe4fb94eab baseline version: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e Last test of basis 150694 2020-06-04 11:44:20 Z 1 days Failing since 150831 2020-06-05 13:06:20 Z 0 days 2 attempts Testing same since 150872 2020-06-05 22:39:31 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Bulekov Christian Borntraeger Cornelia Huck Gerd Hoffmann Janosch Frank Jared Rossi Kevin Wolf Paolo Bonzini Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Stefan Hajnoczi Stefano Garzarella Thomas Huth Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl broken test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm broken test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd broken test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 broken test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 broken test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub broken test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds broken test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-i386-xl broken broken-job test-amd64-i386-libvirt-xsm broken broken-job test-amd64-amd64-xl-rtds broken broken-job test-amd64-i386-xl-qemuu-debianhvm-amd64 broken broken-job test-amd64-amd64-xl-qemuu-ws16-amd64 broken broken-job test-amd64-amd64-i386-pvgrub broken broken-job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken broken-job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64 hosts-allocate broken-step test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict capture-logs(9) broken-step test-amd64-i386-qemuu-rhel6hvm-amd capture-logs(13) broken-step test-amd64-i386-xl capture-logs(19) broken-step test-amd64-i386-libvirt-xsm capture-logs(19) broken-step test-amd64-amd64-i386-pvgrub capture-logs(11) broken-step test-amd64-amd64-xl-rtds capture-logs(19) broken-step test-amd64-amd64-xl-qemuu-ws16-amd64 capture-logs(11) broken-step test-amd64-amd64-i386-pvgrub syslog-server broken-step test-amd64-i386-xl-qemuu-debianhvm-i386-xsm capture-logs(19) Not pushing. (No revision log; it would be 447 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 06 12:42:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 12:42:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhY9U-0007h4-C6; Sat, 06 Jun 2020 12:42:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhY9T-0007gz-5S for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 12:42:19 +0000 X-Inumbo-ID: 28001072-a7f3-11ea-96fb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 28001072-a7f3-11ea-96fb-bc764e2007e4; Sat, 06 Jun 2020 12:42:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pO0jUbaA8FYBb9Ng1rSLv/S7LPBnHO9OlYuBB1apSQw=; b=D2ls59CDB3veZKkGXCYcBbq9D THVCmGoE3ShjYIWwFCKT/uMegNW4yB0gAmQqa4UFwR5E9zRswDmQHOUdtCyVac6MfmUzoV7QWUnEJ Bx2ZST/wNVIULZsfnYFeSqad7adg+A4oD2hVAvHUmr2RQZgD0bLN/tGUPSZ6wZQl0f8ug=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhY9R-00050B-Hm; Sat, 06 Jun 2020 12:42:17 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhY9R-0003Ax-9H; Sat, 06 Jun 2020 12:42:17 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhY9R-00071E-8i; Sat, 06 Jun 2020 12:42:17 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150894: all pass - PUSHED X-Osstest-Versions-This: ovmf=037d86dd7a9ef36c85bf416d358f2ef60a4940b3 X-Osstest-Versions-That: ovmf=8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae From: osstest service owner Date: Sat, 06 Jun 2020 12:42:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150894 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150894/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 037d86dd7a9ef36c85bf416d358f2ef60a4940b3 baseline version: ovmf 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae Last test of basis 150819 2020-06-05 08:09:18 Z 1 days Testing same since 150894 2020-06-06 08:09:26 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel Leif Lindholm jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 8035edbe12..037d86dd7a 037d86dd7a9ef36c85bf416d358f2ef60a4940b3 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Jun 06 12:58:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 12:58:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhYOk-0000PT-Qr; Sat, 06 Jun 2020 12:58:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhYOi-0000PM-SX for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 12:58:04 +0000 X-Inumbo-ID: 578ad8a2-a7f5-11ea-b0e0-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 578ad8a2-a7f5-11ea-b0e0-12813bfff9fa; Sat, 06 Jun 2020 12:57:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pqe0TdNrUbVAh/80q4Dgk+MQ8QlJ1NooTj222jvok1k=; b=Ycy4gkvaRuhb7DO20BXyXoRCJ NZpLAmg3y+gvpe+tApv6kxJquyxdb6xHSHcDQtipVdqXBbt9Tqh2HCbBt88YDDa3hDPCqhvXaRFyy BNwrTaEYDjPwmwaO9ThjcOLw9yU1KCZxLkaXlqOYgKTyjmOH2pucQWLEjkTCwej268awc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhYOa-0005J7-Bh; Sat, 06 Jun 2020 12:57:56 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhYOZ-0004AR-6d; Sat, 06 Jun 2020 12:57:55 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhYOZ-0004zt-62; Sat, 06 Jun 2020 12:57:55 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150876: regressions - trouble: blocked/broken/fail/pass X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-multivcpu::broken:regression xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm::broken:regression xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64::broken:regression xen-unstable:test-amd64-coresched-amd64-xl::broken:regression xen-unstable:test-amd64-amd64-migrupgrade::broken:regression xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm::broken:regression xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64::broken:regression xen-unstable:test-amd64-amd64-i386-pvgrub::broken:regression xen-unstable:test-amd64-amd64-libvirt-pair::broken:regression xen-unstable:test-amd64-i386-xl-xsm::broken:regression xen-unstable:test-amd64-amd64-xl-xsm::broken:regression xen-unstable:test-amd64-amd64-xl-pvhv2-intel::broken:regression xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm::broken:regression xen-unstable:test-amd64-amd64-xl-qcow2::broken:regression xen-unstable:test-amd64-amd64-libvirt-vhd::broken:regression xen-unstable:build-arm64-libvirt::broken:regression xen-unstable:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm::broken:regression xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm::broken:regression xen-unstable:test-amd64-amd64-amd64-pvgrub::broken:regression xen-unstable:test-amd64-amd64-xl-rtds::broken:regression xen-unstable:test-amd64-amd64-xl-shadow::broken:regression xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm::broken:regression xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm::broken:regression xen-unstable:test-amd64-amd64-pair::broken:regression xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64::broken:regression xen-unstable:build-arm64-libvirt:host-install(4):broken:regression xen-unstable:build-i386:xen-build:fail:regression xen-unstable:build-arm64-pvops:kernel-build:fail:regression xen-unstable:build-armhf:xen-build:fail:regression xen-unstable:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression xen-unstable:test-arm64-arm64-xl-credit1:build-check(1):running:regression xen-unstable:test-armhf-armhf-xl-credit1:build-check(1):running:regression xen-unstable:test-arm64-arm64-xl-seattle:build-check(1):running:regression xen-unstable:build-armhf-libvirt:build-check(1):running:regression xen-unstable:test-armhf-armhf-xl-credit2:build-check(1):running:regression xen-unstable:test-armhf-armhf-xl-vhd:build-check(1):running:regression xen-unstable:test-arm64-arm64-libvirt-xsm:build-check(1):running:regression xen-unstable:test-armhf-armhf-xl-arndale:build-check(1):running:regression xen-unstable:test-armhf-armhf-xl:build-check(1):running:regression xen-unstable:test-armhf-armhf-xl-multivcpu:build-check(1):running:regression xen-unstable:test-arm64-arm64-xl-credit2:build-check(1):running:regression xen-unstable:test-armhf-armhf-xl-cubietruck:build-check(1):running:regression xen-unstable:test-armhf-armhf-examine:build-check(1):running:regression xen-unstable:test-armhf-armhf-libvirt-raw:build-check(1):running:regression xen-unstable:test-arm64-arm64-xl:build-check(1):running:regression xen-unstable:test-armhf-armhf-xl-rtds:build-check(1):running:regression xen-unstable:test-arm64-arm64-xl-xsm:build-check(1):running:regression xen-unstable:test-armhf-armhf-libvirt:build-check(1):running:regression xen-unstable:test-arm64-arm64-xl-thunderx:build-check(1):running:regression xen-unstable:test-arm64-arm64-examine:build-check(1):running:regression xen-unstable:build-arm64-libvirt:syslog-server:running:regression xen-unstable:build-arm64-pvops:syslog-server:running:regression xen-unstable:build-armhf:syslog-server:running:regression xen-unstable:test-amd64-amd64-pair:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-coresched-amd64-xl:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-libvirt-pair:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-xl-qcow2:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-libvirt-vhd:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-xl-pvhv2-intel:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-i386-xl-xsm:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-migrupgrade:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-xl-multivcpu:hosts-allocate:broken:heisenbug xen-unstable:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:host-install(4):broken:heisenbug xen-unstable:test-amd64-amd64-i386-pvgrub:host-install(4):broken:heisenbug xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:host-install(4):broken:heisenbug xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:host-install(4):broken:heisenbug xen-unstable:test-amd64-amd64-amd64-pvgrub:syslog-server:broken:heisenbug xen-unstable:test-amd64-amd64-i386-pvgrub:syslog-server:broken:heisenbug xen-unstable:test-amd64-amd64-examine:host-install:broken:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:syslog-server:broken:heisenbug xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:syslog-server:broken:heisenbug xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:syslog-server:broken:heisenbug xen-unstable:test-amd64-amd64-examine:capture-logs:broken:heisenbug xen-unstable:test-amd64-amd64-examine:syslog-server:broken:heisenbug xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:syslog-server:broken:heisenbug xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-amd64-amd64-pvgrub:debian-di-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:guest-start/debianhvm.repeat:fail:heisenbug xen-unstable:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-unstable:test-amd64-coresched-i386-xl:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-unstable:build-i386-libvirt:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-examine:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-unstable:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:capture-logs(5):broken:nonblocking xen-unstable:build-arm64-libvirt:capture-logs:broken:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:capture-logs(5):broken:nonblocking xen-unstable:test-amd64-amd64-i386-pvgrub:capture-logs(5):broken:nonblocking xen-unstable:test-amd64-amd64-amd64-pvgrub:capture-logs(11):broken:nonblocking xen-unstable:build-arm64-pvops:capture-logs:broken:nonblocking xen-unstable:build-armhf:capture-logs:broken:nonblocking xen-unstable:test-amd64-amd64-xl-shadow:hosts-allocate:broken:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:hosts-allocate:broken:nonblocking xen-unstable:test-amd64-amd64-xl-xsm:capture-logs(5):broken:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:hosts-allocate:broken:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:capture-logs(5):broken:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:host-install(4):broken:nonblocking xen-unstable:test-amd64-amd64-xl-xsm:host-install(4):broken:nonblocking xen-unstable:test-amd64-amd64-xl-xsm:syslog-server:broken:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:capture-logs(5):broken:nonblocking xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:capture-logs(11):broken:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:capture-logs(19):broken:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=51ca66c37371b10b378513af126646de22eddb17 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Sat, 06 Jun 2020 12:57:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150876 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150876/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-multivcpu broken test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken test-amd64-amd64-xl-qemuu-ws16-amd64 broken test-amd64-coresched-amd64-xl broken test-amd64-amd64-migrupgrade broken test-amd64-i386-xl-qemut-debianhvm-i386-xsm broken test-amd64-amd64-xl-qemut-win7-amd64 broken test-amd64-amd64-i386-pvgrub broken test-amd64-amd64-libvirt-pair broken test-amd64-i386-xl-xsm broken test-amd64-amd64-xl-xsm broken test-amd64-amd64-xl-pvhv2-intel broken test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm broken test-amd64-amd64-xl-qcow2 broken test-amd64-amd64-libvirt-vhd broken build-arm64-libvirt broken test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm broken test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm broken test-amd64-amd64-amd64-pvgrub broken test-amd64-amd64-xl-rtds broken test-amd64-amd64-xl-shadow broken test-amd64-amd64-xl-qemut-debianhvm-i386-xsm broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken test-amd64-amd64-pair broken test-amd64-amd64-xl-qemut-ws16-amd64 broken build-arm64-libvirt 4 host-install(4) broken REGR. vs. 150714 build-i386 6 xen-build fail REGR. vs. 150714 build-arm64-pvops 6 kernel-build fail REGR. vs. 150714 build-armhf 6 xen-build fail REGR. vs. 150714 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail in 150869 REGR. vs. 150714 test-arm64-arm64-xl-credit1 1 build-check(1) running test-armhf-armhf-xl-credit1 1 build-check(1) running test-arm64-arm64-xl-seattle 1 build-check(1) running build-armhf-libvirt 1 build-check(1) running test-armhf-armhf-xl-credit2 1 build-check(1) running test-armhf-armhf-xl-vhd 1 build-check(1) running test-arm64-arm64-libvirt-xsm 1 build-check(1) running test-armhf-armhf-xl-arndale 1 build-check(1) running test-armhf-armhf-xl 1 build-check(1) running test-armhf-armhf-xl-multivcpu 1 build-check(1) running test-arm64-arm64-xl-credit2 1 build-check(1) running test-armhf-armhf-xl-cubietruck 1 build-check(1) running test-armhf-armhf-examine 1 build-check(1) running test-armhf-armhf-libvirt-raw 1 build-check(1) running test-arm64-arm64-xl 1 build-check(1) running test-armhf-armhf-xl-rtds 1 build-check(1) running test-arm64-arm64-xl-xsm 1 build-check(1) running test-armhf-armhf-libvirt 1 build-check(1) running test-arm64-arm64-xl-thunderx 1 build-check(1) running test-arm64-arm64-examine 1 build-check(1) running build-arm64-libvirt 3 syslog-server running build-arm64-pvops 3 syslog-server running build-armhf 3 syslog-server running Tests which are failing intermittently (not blocking): test-amd64-amd64-pair 2 hosts-allocate broken pass in 150869 test-amd64-coresched-amd64-xl 2 hosts-allocate broken pass in 150869 test-amd64-amd64-libvirt-pair 2 hosts-allocate broken pass in 150869 test-amd64-amd64-xl-qcow2 2 hosts-allocate broken pass in 150869 test-amd64-amd64-libvirt-vhd 2 hosts-allocate broken pass in 150869 test-amd64-amd64-xl-qemut-win7-amd64 2 hosts-allocate broken pass in 150869 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 2 hosts-allocate broken pass in 150869 test-amd64-amd64-xl-pvhv2-intel 2 hosts-allocate broken pass in 150869 test-amd64-i386-xl-xsm 2 hosts-allocate broken pass in 150869 test-amd64-amd64-xl-qemut-ws16-amd64 2 hosts-allocate broken pass in 150869 test-amd64-amd64-migrupgrade 2 hosts-allocate broken pass in 150869 test-amd64-amd64-xl-multivcpu 2 hosts-allocate broken pass in 150869 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 4 host-install(4) broken pass in 150869 test-amd64-amd64-i386-pvgrub 4 host-install(4) broken pass in 150869 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 4 host-install(4) broken pass in 150869 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 4 host-install(4) broken pass in 150869 test-amd64-amd64-amd64-pvgrub 3 syslog-server broken pass in 150869 test-amd64-amd64-i386-pvgrub 3 syslog-server broken pass in 150869 test-amd64-amd64-examine 5 host-install broken pass in 150869 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 syslog-server broken pass in 150869 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 3 syslog-server broken pass in 150869 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 3 syslog-server broken pass in 150869 test-amd64-amd64-examine 6 capture-logs broken pass in 150869 test-amd64-amd64-examine 3 syslog-server broken pass in 150869 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 syslog-server broken pass in 150869 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 150869 test-amd64-amd64-amd64-pvgrub 10 debian-di-install fail pass in 150869 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 18 guest-start/debianhvm.repeat fail pass in 150869 Tests which did not succeed, but are not blocking: test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 5 capture-logs(5) broken blocked in 150714 build-arm64-libvirt 5 capture-logs broken blocked in 150714 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 5 capture-logs(5) broken blocked in 150714 test-amd64-amd64-i386-pvgrub 5 capture-logs(5) broken blocked in 150714 test-amd64-amd64-amd64-pvgrub 11 capture-logs(11) broken blocked in 150714 build-arm64-pvops 7 capture-logs broken blocked in 150714 build-armhf 7 capture-logs broken blocked in 150714 test-amd64-amd64-xl-shadow 2 hosts-allocate broken like 150714 test-amd64-amd64-xl-rtds 2 hosts-allocate broken like 150714 test-amd64-amd64-xl-xsm 5 capture-logs(5) broken like 150714 test-amd64-amd64-xl-qemuu-ws16-amd64 2 hosts-allocate broken like 150714 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 5 capture-logs(5) broken like 150714 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 4 host-install(4) broken like 150714 test-amd64-amd64-xl-xsm 4 host-install(4) broken like 150714 test-amd64-amd64-xl-xsm 3 syslog-server broken like 150714 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 5 capture-logs(5) broken never pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm 11 capture-logs(11) broken never pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 19 capture-logs(19) broken never pass test-amd64-amd64-xl-rtds 16 guest-localmigrate fail in 150869 like 150551 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 150869 like 150635 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 150869 like 150674 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 150869 like 150674 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 150869 like 150674 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 150869 like 150714 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 150869 like 150714 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 150869 like 150714 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 150869 like 150714 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 150869 like 150714 test-amd64-i386-xl-pvshim 12 guest-start fail in 150869 never pass test-amd64-i386-libvirt 13 migrate-support-check fail in 150869 never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail in 150869 never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 150869 never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 150869 never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 150869 never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 150869 never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail in 150869 never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail in 150869 never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail in 150869 never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 150869 never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 150869 never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail in 150869 never pass test-arm64-arm64-xl 13 migrate-support-check fail in 150869 never pass test-arm64-arm64-xl 14 saverestore-support-check fail in 150869 never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 150869 never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 150869 never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail in 150869 never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 150869 never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 150869 never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 150869 never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 150869 never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail in 150869 never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail in 150869 never pass test-armhf-armhf-xl 13 migrate-support-check fail in 150869 never pass test-armhf-armhf-xl 14 saverestore-support-check fail in 150869 never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 150869 never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 150869 never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 150869 never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 150869 never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail in 150869 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 150869 never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 150869 never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail in 150869 never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail in 150869 never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 150869 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 150869 never pass test-armhf-armhf-libvirt 13 migrate-support-check fail in 150869 never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 150869 never pass test-amd64-amd64-examine 4 memdisk-try-append fail like 150529 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150674 test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 51ca66c37371b10b378513af126646de22eddb17 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150714 2020-06-05 01:52:44 Z 1 days Testing same since 150869 2020-06-05 20:06:13 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Igor Druzhinin Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf fail build-i386 fail build-amd64-libvirt pass build-arm64-libvirt broken build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops fail build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl broken test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-coresched-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm broken test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm broken test-amd64-amd64-xl-qemut-debianhvm-i386-xsm broken test-amd64-i386-xl-qemut-debianhvm-i386-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm broken test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm broken test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm broken test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 broken test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 broken test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 broken test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-amd64-examine fail test-arm64-arm64-examine blocked test-armhf-armhf-examine blocked test-amd64-i386-examine blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel broken test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch pass test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade broken test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu broken test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair broken test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair broken test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub broken test-amd64-amd64-i386-pvgrub broken test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 broken test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds broken test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow broken test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd broken test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-amd64-xl-multivcpu broken broken-job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken broken-job test-amd64-amd64-xl-qemuu-ws16-amd64 broken broken-job test-amd64-coresched-amd64-xl broken broken-job test-amd64-amd64-migrupgrade broken broken-job test-amd64-i386-xl-qemut-debianhvm-i386-xsm broken broken-job test-amd64-amd64-xl-qemut-win7-amd64 broken broken-job test-amd64-amd64-i386-pvgrub broken broken-job test-amd64-amd64-libvirt-pair broken broken-job test-amd64-i386-xl-xsm broken broken-job test-amd64-amd64-xl-xsm broken broken-job test-amd64-amd64-xl-pvhv2-intel broken broken-job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm broken broken-job test-amd64-amd64-xl-qcow2 broken broken-job test-amd64-amd64-libvirt-vhd broken broken-job build-arm64-libvirt broken broken-job test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm broken broken-job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm broken broken-job test-amd64-amd64-amd64-pvgrub broken broken-job test-amd64-amd64-xl-rtds broken broken-job test-amd64-amd64-xl-shadow broken broken-job test-amd64-amd64-xl-qemut-debianhvm-i386-xsm broken broken-job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken broken-job test-amd64-amd64-pair broken broken-job test-amd64-amd64-xl-qemut-ws16-amd64 broken broken-step test-amd64-amd64-pair hosts-allocate broken-step test-amd64-coresched-amd64-xl hosts-allocate broken-step test-amd64-amd64-libvirt-pair hosts-allocate broken-step test-amd64-amd64-xl-qcow2 hosts-allocate broken-step test-amd64-amd64-libvirt-vhd hosts-allocate broken-step test-amd64-amd64-xl-qemut-win7-amd64 hosts-allocate broken-step test-amd64-amd64-xl-shadow hosts-allocate broken-step test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm hosts-allocate broken-step test-amd64-amd64-xl-pvhv2-intel hosts-allocate broken-step test-amd64-i386-xl-xsm hosts-allocate broken-step test-amd64-i386-xl-qemuu-debianhvm-i386-xsm capture-logs(5) broken-step test-amd64-amd64-xl-qemut-ws16-amd64 hosts-allocate broken-step test-amd64-amd64-migrupgrade hosts-allocate broken-step test-amd64-amd64-xl-multivcpu hosts-allocate broken-step test-amd64-amd64-xl-rtds hosts-allocate broken-step build-arm64-libvirt host-install(4) broken-step test-amd64-amd64-xl-xsm capture-logs(5) broken-step test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm capture-logs(5) broken-step build-arm64-libvirt capture-logs broken-step test-amd64-amd64-xl-qemuu-ws16-amd64 hosts-allocate broken-step test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm capture-logs(5) broken-step test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm capture-logs(5) broken-step test-amd64-amd64-i386-pvgrub capture-logs(5) broken-step test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm host-install(4) broken-step test-amd64-amd64-i386-pvgrub host-install(4) broken-step test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm host-install(4) broken-step test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm host-install(4) broken-step test-amd64-i386-xl-qemuu-debianhvm-i386-xsm host-install(4) broken-step test-amd64-amd64-amd64-pvgrub capture-logs(11) broken-step test-amd64-i386-xl-qemut-debianhvm-i386-xsm capture-logs(11) broken-step test-amd64-amd64-xl-qemut-debianhvm-i386-xsm capture-logs(19) broken-step test-amd64-amd64-xl-xsm host-install(4) broken-step build-arm64-pvops capture-logs broken-step test-amd64-amd64-amd64-pvgrub syslog-server broken-step test-amd64-amd64-i386-pvgrub syslog-server broken-step test-amd64-amd64-examine host-install broken-step test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm syslog-server broken-step test-amd64-i386-xl-qemuu-debianhvm-i386-xsm syslog-server broken-step test-amd64-i386-xl-qemut-debianhvm-i386-xsm syslog-server broken-step test-amd64-amd64-xl-xsm syslog-server broken-step test-amd64-amd64-examine capture-logs broken-step test-amd64-amd64-examine syslog-server broken-step test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm syslog-server broken-step build-armhf capture-logs Not pushing. (No revision log; it would be 1599 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 06 15:19:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 15:19:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhabn-0005ey-Rg; Sat, 06 Jun 2020 15:19:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhabm-0005et-CM for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 15:19:42 +0000 X-Inumbo-ID: 2507c372-a809-11ea-ba62-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2507c372-a809-11ea-ba62-bc764e2007e4; Sat, 06 Jun 2020 15:19:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lBa0dSX3WEWfT4c7XliybFj/QkpuAYvi5id0k/Pzhj8=; b=PRnmrFcJDJ84Q9pZjoFQV78XNw U4iSv7AVZHOp/bHpRJMC/t/vmbatTFVuTNwYsZYO2quT1HYd4FBM+d9S/dsDoC80nsqJbqnaljarb NM0HDRfB2BPajVc9Cuq660TvVoZScvpuk9NNDSjFmvlkhiSI7lglK5LByZpdrxs5LBS8=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhabl-0008G9-ER; Sat, 06 Jun 2020 15:19:41 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jhabl-00044c-7e; Sat, 06 Jun 2020 15:19:41 +0000 Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address To: Volodymyr Babchuk , "sstabellini@kernel.org" , "xen-devel@lists.xenproject.org" , "paul@xen.org" References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> From: Julien Grall Message-ID: <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> Date: Sat, 6 Jun 2020 16:19:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" (+Paul) Hi, On 18/05/2020 02:53, Volodymyr Babchuk wrote: > Trusted Applications use popular approach to determine required size > of buffer: client provides a memory reference with the NULL pointer to > a buffer. This is so called "Null memory reference". TA updates the NIT: You use double space after '.' here but all the others use a single space. > reference with the required size and returns it back to client. Then > client allocates buffer of needed size and repeats the operation. > > This behavior is described in TEE Client API Specification, paragraph > 3.2.5. Memory References. From the spec, it is not a clear cut that NULL will always used as fetching the required size of an output buffer. In particular, they suggest to refer to the protocol. In your commit message you indirectly point to an example where 0/NULL would have a different meaning depending on the flags. This is not explained in the TEE Client API Specification. Do you have some pointer I could use to check the behavior? > > OP-TEE represents this null memory reference as a TMEM parameter with > buf_ptr == NULL. This is the only case when we should allow TMEM > buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer at address 0" but with the flag cleared, it would mean "return the size". Am I correct? > > Signed-off-by: Volodymyr Babchuk The code looks to match your commit message, but I wasn't able to match it with the spec. Do you have other pointer I could use to check the behavior? I assume this wants to be part of Xen 4.14. The change is only for OP-TEE which is a tech preview feature. So the risk is very limited. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Sat Jun 06 15:23:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 15:23:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhafF-0006a5-CT; Sat, 06 Jun 2020 15:23:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhafD-0006Zz-CS for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 15:23:15 +0000 X-Inumbo-ID: 9d645db2-a809-11ea-b0fe-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9d645db2-a809-11ea-b0fe-12813bfff9fa; Sat, 06 Jun 2020 15:23:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yCkmslixqAmIdq4tin0KK7AQuLDGhdvnKgSGQNCmF/E=; b=wqEx7u5j2Dyhp7Tc8LtFWU4u0 9QVHgE/F02o1WimLidd5+sy4six7b2zmHEICmWEIv/QB++R7Hd8j6IqaiHKwdHzKqpyb0y/HvaNjG LXbdpTNy0eif/98yGzauBL6JWKgnVTooMKh1vPJpEXqxRQsEfbXiuMMKbx/OKQcusFDsg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhaf1-0008LB-Go; Sat, 06 Jun 2020 15:23:03 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhaf1-0002Ud-7v; Sat, 06 Jun 2020 15:23:03 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhaf1-0004Ym-7B; Sat, 06 Jun 2020 15:23:03 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150891: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-i386-libvirt:xen-boot:fail:regression linux-linus:test-armhf-armhf-xl-vhd:leak-check/check:fail:regression linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: linux=aaa2faab4ed8e5fe0111e04d6e168c028fe2987f X-Osstest-Versions-That: linux=7ae77150d94d3b535c7b85e6b3647113095e79bf From: osstest service owner Date: Sat, 06 Jun 2020 15:23:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150891 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150891/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 150871 test-armhf-armhf-xl-vhd 18 leak-check/check fail REGR. vs. 150871 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 16 guest-localmigrate fail REGR. vs. 150871 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150871 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150871 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150871 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150871 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150871 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150871 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150871 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150871 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150871 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: linux aaa2faab4ed8e5fe0111e04d6e168c028fe2987f baseline version: linux 7ae77150d94d3b535c7b85e6b3647113095e79bf Last test of basis 150871 2020-06-05 21:09:12 Z 0 days Testing same since 150879 2020-06-06 06:52:55 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Adam Ford Aharon Landau Al Viro (fs/inode.c part) Alex Dewar Alex Williamson André Almeida Andy Shevchenko Anna Pendleton Arnd Bergmann Arun Easi Asmaa Mnebhi Asutosh Das Aurelien Aptel Avri Altman Bart Van Assche Bartosz Golaszewski Bean Huo Benjamin Block Bob Liu Bodo Stroesser Borislav Petkov Brian Masney Can Guo Carlos Guerrero Álvarez Chad Dupuis Chandrakanth Patil Chen Tao ChenTao Christoph Hellwig Christophe JAILLET Chuck Lever Colin Ian King Colin Ian King # fix leak in dmz_insert Corey Minyard Damien Le Moal Dan Carpenter Daniel Wagner Danil Kipnis Danit Goldberg Daria Velikovsky David Howells David Teigland Dejin Zheng Dennis Dalessandro Devesh Sharma Dick Kennedy Dinghao Liu Dmitry Baryshkov Douglas Anderson Douglas Gilbert Eric Biggers Eric Whitney Eugeniu Rosca Feng Tang Gabriel Krisman Bertazi Gal Pressman Gary Leshner Geert Uytterhoeven Geert Uytterhoeven Grzegorz Andrejczuk Gustavo A. R. Silva Gustavo A. R. Silva Hannes Reinecke Hans de Goede Hans Verkuil Harshad Shirwadkar Heinz Mauelshagen Israel Rukshin Jack Wang James Smart Jan Kara Jason Gunthorpe Jason Yan Javed Hasan Jeffle Xu Jeffrey Hugo Jens Axboe Joe Perches Johannes Thumshirn John Garry John Hubbard Jonathan Grant Jules Irenge Ka-Cheong Poon Kai Mäkisara Kaike Wan Kaixu Xia Kamal Heib Kashyap Desai Kees Cook Kenneth D'souza Kent Gibson Khalid Aziz Khazhismel Kumykov Kirti Wankhede Konstantin Khlebnikov Lance Digby Lang Cheng Lee Jones Leon Romanovsky Lijun Ou Linus Torvalds Linus Walleij Luo Jiaxing Manish Rangankar Maor Gottlieb Marcel Gudert Mark Bloch Mark Zhang Martin K. Petersen Martin Wilck Matthew R. Ochs Maulik Shah Maurizio Lombardi Mauro Carvalho Chehab Max Gurtovoy Md Haris Iqbal Mian Yousaf Kaukab Michael Walle Mika Westerberg Mike Christie Mike Marshall Mike Snitzer Mikulas Patocka Ming Lei Nathan Chancellor Nilesh Javali Paul Thomas Paulo Alcantara (SUSE) Paulo Alcantara Petteri Jokinen Piotr Stankiewicz Potnuri Bharat Teja Qian Cai Qiushi Wu Randy Dunlap Randy Dunlap # build-tested Randy Dunlap [Kconfig fixes] Ritesh Harjani Rob Herring Roberto Bergantinos Corpas Rodrigo Alencar <455.rodrigo.alencar@gmail.com> Roman Pen Ronnie Sahlberg Ross Lagerwall Sachin Agarwal Sadanand Warrier Samuel Zou Saurav Kashyap Serge Semin Serge Semin Shay Drory Shengju Zhang Shiraz Saleem Shivasharan S Sreekanth Reddy Stanley Chu Stephen Boyd Steve French Stuart Hayes Subhash Jadavani Sudarsana Reddy Kalluru Sudhakar Panneerselvam Suganath Prabu Suganath Prabu S Sumit Saxena Tang Bin Tejun Heo Theodore Ts'o Tiezhu Yang Ursula Braun Uwe Kleine-König Viacheslav Dubeyko Vignesh Raghavendra Wang Hai Wei Yongjun Weihang Li Wenpeng Liang Wu Bo Xi Wang Xie XiuQi Xin Tan Xiongfeng Wang Xiyu Yang Xu Wang Yamin Friedman Yangyang Li Ye Bin Yishai Hadas Yixian Liu YueHaibing Zheng Bin [static fixes] Zhiqiang Liu Zhu Yanjun Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 14988 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 06 15:28:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 15:28:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhajk-0006m6-3R; Sat, 06 Jun 2020 15:27:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhajj-0006m1-F8 for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 15:27:55 +0000 X-Inumbo-ID: 4abee644-a80a-11ea-b0fe-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4abee644-a80a-11ea-b0fe-12813bfff9fa; Sat, 06 Jun 2020 15:27:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+ebYBvlINelHyj8z6DEYe+Ke7Ci+rMQ52Z/yFUQvXAs=; b=m0Qwpt80LjLdA/pf8SLX5vUN66 QmKhH7rit8OOwNtQ5BBdUKRXAML386P9xfpDmoszGjxYzZunc9cHiSbn0MsbKwQi4grPy51RHScA5 uzJJiRt/qGSuikn5BoCTlIu5fw0nvehVW83x+Heyzw3XQWrqysdBpE169Q9KozzM3yd4=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhajg-0008RC-CO; Sat, 06 Jun 2020 15:27:52 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jhajg-0004nf-5K; Sat, 06 Jun 2020 15:27:52 +0000 Subject: Re: [PATCH v2] build: fix dependency tracking for preprocessed files To: Jan Beulich , "xen-devel@lists.xenproject.org" References: From: Julien Grall Message-ID: <15a34114-0693-4385-62fa-ad34405b9350@xen.org> Date: Sat, 6 Jun 2020 16:27:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Paul Durrant , Andrew Cooper , Ian Jackson , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Jan, On 05/06/2020 15:22, Jan Beulich wrote: > While the issue is more general, I noticed that asm-macros.i not getting > re-generated as needed. This was due to its .*.d file mentioning > asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at > it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds > dependency tracking files. While there, further avoid open-coding $(CPP) > and drop the bogus (Arm) / stale (x86) -Ui386. Good catch! It looks like this was a verbatim copy of the x86 line as I can't see any reason why we would need it on Arm. > > Signed-off-by: Jan Beulich Acked-by: Julien Grall Cheers, > --- > v2: Move -MQ ahead on command lines. > > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -201,13 +201,13 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) > $(call if_changed,obj_init_o) > > quiet_cmd_cpp_i_c = CPP $@ > -cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ > +cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -MQ $@ -o $@ $< > > quiet_cmd_cc_s_c = CC $@ > cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@ > > quiet_cmd_s_S = CPP $@ > -cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@ > +cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) -MQ $@ -o $@ $< > > %.i: %.c FORCE > $(call if_changed,cpp_i_c) > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -123,9 +123,7 @@ asm-offsets.s: $(TARGET_SUBARCH)/asm-off > $(CC) $(filter-out -flto,$(c_flags)) -S -o $@ $< > > xen.lds: xen.lds.S > - $(CC) -P -E -Ui386 $(a_flags) -o $@ $< > - sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new > - mv -f .xen.lds.d.new .xen.lds.d > + $(CPP) -P $(a_flags) -MQ $@ -o $@ $< > > dtb.o: $(CONFIG_DTB_FILE) > > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -244,9 +244,7 @@ $(BASEDIR)/include/asm-x86/asm-macros.h: > > efi.lds: AFLAGS-y += -DEFI > xen.lds efi.lds: xen.lds.S > - $(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $< > - sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new > - mv -f .$(@F).d.new .$(@F).d > + $(CPP) -P $(filter-out -Wa$(comma)%,$(a_flags)) -MQ $@ -o $@ $< > > boot/mkelf32: boot/mkelf32.c > $(HOSTCC) $(HOSTCFLAGS) -o $@ $< > -- Julien Grall From xen-devel-bounces@lists.xenproject.org Sat Jun 06 16:11:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 16:11:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhbPI-0003a2-Bb; Sat, 06 Jun 2020 16:10:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhbPG-0003Zx-TK for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 16:10:51 +0000 X-Inumbo-ID: 3fc2dfb0-a810-11ea-96fb-bc764e2007e4 Received: from mail-qk1-x734.google.com (unknown [2607:f8b0:4864:20::734]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3fc2dfb0-a810-11ea-96fb-bc764e2007e4; Sat, 06 Jun 2020 16:10:33 +0000 (UTC) Received: by mail-qk1-x734.google.com with SMTP id s1so12963591qkf.9 for ; Sat, 06 Jun 2020 09:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=dPEweiPkympPsO79Oa3xwYxa2N+YUuVn26V/j6LHHqs=; b=DpRjWIhIJB1fwmn/mphkwU/crBysymB6v2v3+mmAH77HjvCfRX7/VTecRKmKVtuogy q8BeyjnyiMVRidS36PROL77VePo5WHPYv9/VsX4d9nG2njXYfMqYSNZh+5FDVUz9BMoj LoMkHfgMvx3k1doXySfIg/CV6NZSYhvtoXHcM7d9qKG1v8MUf+jV9gnvtWpx9RaBMZjz Ko/jS683vxUBOj2hQfh91SR3M0qYvoqDc9qc4toXx/+E9iH1LbT3iUHlY12Ppu/Suea+ Gkoj5kn8seDI4NjjcUhyHqorW+iaDFh1gxKdbN4C0tATJfUyH+E9FUcHr2eDw82a/IZS CcyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=dPEweiPkympPsO79Oa3xwYxa2N+YUuVn26V/j6LHHqs=; b=g2k9rO5/BXDsGXR8j4wvb5JMcgci/WouuqWHQuicqTry5ltZMDkOow2vL+UFXIh8pS MESH7a3saH0iZSP/m4+jY5E2gB+hgeKBC/Al7sii3+0/UGfGMI7bAjMur8Xbpq8LzBPK mwZDz/nVnLP/Sc8t9Ug7J75/gkfmKz3zlZVObMmw0+y78k3JTTHfB+uvYuo51dOh6182 bi74T0NlxcN/3vII4U8LnbYvMM3My4a9rw+B0FG5fskqOKVHZRhgxUXVq4aahCYu+JcH MCVtKI7I7XpytPMV9SYNukcoFs/OanX+Pu5a9RATaMz/kALKwafC6QOEjnNyyd0aNcIa Zb9Q== X-Gm-Message-State: AOAM531HKvwZ956wyBuoMrwEU8co4MHW82ZeMI9O0dPJywIJWMyD5n04 MPWAwkFg9e1D9uoBAT69TRhJ9DOqIYI= X-Google-Smtp-Source: ABdhPJwtYSycWgAisAmb+b0i9X1SdEjFYQ9dgPxE+ft0/4RtHhV2izTa9NcDDKQS0IKYDhCVXcujRQ== X-Received: by 2002:a05:620a:49c:: with SMTP id 28mr15397832qkr.168.1591459830227; Sat, 06 Jun 2020 09:10:30 -0700 (PDT) Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252]) by smtp.gmail.com with ESMTPSA id d23sm2823576qtn.38.2020.06.06.09.10.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2020 09:10:28 -0700 (PDT) From: Nick Rosbrook X-Google-Original-From: Nick Rosbrook To: xen-devel@lists.xenproject.org Subject: [PATCH for-4.14] golang/xenlight: remove call to go fmt in gengotypes.py Date: Sat, 6 Jun 2020 12:10:25 -0400 Message-Id: <20200606161025.19057-1-rosbrookn@ainfosec.com> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , Ian Jackson , George Dunlap , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Since the golang bindings are now set to be re-generated whenever a change is made to tools/libxl/libxl_types.idl, the call to go fmt in gengotypes.py results in a dirty git tree for users without go installed. As an immediate fix, just remove the call to go fmt from gengotypes.py. While here, make sure the DO NOT EDIT comment and package declaration remain formatted correctly. All other generated code is left un-formatted for now. Signed-off-by: Nick Rosbrook --- tools/golang/xenlight/gengotypes.py | 22 +- tools/golang/xenlight/helpers.gen.go | 7711 ++++++++++++-------------- tools/golang/xenlight/types.gen.go | 1708 +++--- 3 files changed, 4420 insertions(+), 5021 deletions(-) diff --git a/tools/golang/xenlight/gengotypes.py b/tools/golang/xenlight/gengotypes.py index 2b71aa1ea8..3955f64114 100644 --- a/tools/golang/xenlight/gengotypes.py +++ b/tools/golang/xenlight/gengotypes.py @@ -39,7 +39,7 @@ def xenlight_golang_generate_types(path = None, types = None, comment = None): with open(path, 'w') as f: if comment is not None: f.write(comment) - f.write('package xenlight\n') + f.write('package xenlight\n\n') for ty in types: (tdef, extras) = xenlight_golang_type_define(ty) @@ -52,8 +52,6 @@ def xenlight_golang_generate_types(path = None, types = None, comment = None): f.write(extra) f.write('\n') - go_fmt(path) - def xenlight_golang_type_define(ty = None): """ Generate the Go type definition of ty. @@ -205,7 +203,7 @@ def xenlight_golang_generate_helpers(path = None, types = None, comment = None): with open(path, 'w') as f: if comment is not None: f.write(comment) - f.write('package xenlight\n') + f.write('package xenlight\n\n') f.write('import (\n"unsafe"\n"errors"\n"fmt"\n)\n') # Cgo preamble @@ -240,8 +238,6 @@ def xenlight_golang_generate_helpers(path = None, types = None, comment = None): f.write(xenlight_golang_define_to_C(ty)) f.write('\n') - go_fmt(path) - def xenlight_golang_define_from_C(ty = None): """ Define the fromC marshaling function for the type @@ -719,10 +715,6 @@ def xenlight_golang_fmt_name(name, exported = True): return words[0] + ''.join(x.title() for x in words[1:]) -def go_fmt(path): - """ Call go fmt on the given path. """ - os.system('go fmt {}'.format(path)) - if __name__ == '__main__': idlname = sys.argv[1] @@ -733,12 +725,12 @@ if __name__ == '__main__': builtin_type_names[name] = xenlight_golang_fmt_name(name) header_comment="""// DO NOT EDIT. - // - // This file is generated by: - // {} - // +// +// This file is generated by: +// {} +// - """.format(' '.join(sys.argv)) +""".format(' '.join(sys.argv)) xenlight_golang_generate_types(types=types, comment=header_comment) diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index 1e58ebbab2..5378050dea 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -7,11 +7,10 @@ package xenlight import ( - "errors" - "fmt" - "unsafe" +"unsafe" +"errors" +"fmt" ) - /* #cgo LDFLAGS: -lxenlight #include @@ -30,4710 +29,4154 @@ typedef typeof(((struct libxl_psr_hw_info *)NULL)->u.cat)libxl_psr_hw_info_type_ typedef typeof(((struct libxl_psr_hw_info *)NULL)->u.mba)libxl_psr_hw_info_type_union_mba; */ import "C" - // NewIoportRange returns an instance of IoportRange initialized with defaults. func NewIoportRange() (*IoportRange, error) { - var ( - x IoportRange - xc C.libxl_ioport_range - ) +var ( +x IoportRange +xc C.libxl_ioport_range) - C.libxl_ioport_range_init(&xc) - defer C.libxl_ioport_range_dispose(&xc) +C.libxl_ioport_range_init(&xc) +defer C.libxl_ioport_range_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *IoportRange) fromC(xc *C.libxl_ioport_range) error { - x.First = uint32(xc.first) - x.Number = uint32(xc.number) + x.First = uint32(xc.first) +x.Number = uint32(xc.number) + + return nil} - return nil -} - -func (x *IoportRange) toC(xc *C.libxl_ioport_range) (err error) { - defer func() { - if err != nil { - C.libxl_ioport_range_dispose(xc) - } - }() +func (x *IoportRange) toC(xc *C.libxl_ioport_range) (err error){defer func(){ +if err != nil{ +C.libxl_ioport_range_dispose(xc)} +}() - xc.first = C.uint32_t(x.First) - xc.number = C.uint32_t(x.Number) +xc.first = C.uint32_t(x.First) +xc.number = C.uint32_t(x.Number) - return nil -} + return nil + } // NewIomemRange returns an instance of IomemRange initialized with defaults. func NewIomemRange() (*IomemRange, error) { - var ( - x IomemRange - xc C.libxl_iomem_range - ) +var ( +x IomemRange +xc C.libxl_iomem_range) - C.libxl_iomem_range_init(&xc) - defer C.libxl_iomem_range_dispose(&xc) +C.libxl_iomem_range_init(&xc) +defer C.libxl_iomem_range_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *IomemRange) fromC(xc *C.libxl_iomem_range) error { - x.Start = uint64(xc.start) - x.Number = uint64(xc.number) - x.Gfn = uint64(xc.gfn) - - return nil -} + x.Start = uint64(xc.start) +x.Number = uint64(xc.number) +x.Gfn = uint64(xc.gfn) + + return nil} -func (x *IomemRange) toC(xc *C.libxl_iomem_range) (err error) { - defer func() { - if err != nil { - C.libxl_iomem_range_dispose(xc) - } - }() +func (x *IomemRange) toC(xc *C.libxl_iomem_range) (err error){defer func(){ +if err != nil{ +C.libxl_iomem_range_dispose(xc)} +}() - xc.start = C.uint64_t(x.Start) - xc.number = C.uint64_t(x.Number) - xc.gfn = C.uint64_t(x.Gfn) +xc.start = C.uint64_t(x.Start) +xc.number = C.uint64_t(x.Number) +xc.gfn = C.uint64_t(x.Gfn) - return nil -} + return nil + } // NewVgaInterfaceInfo returns an instance of VgaInterfaceInfo initialized with defaults. func NewVgaInterfaceInfo() (*VgaInterfaceInfo, error) { - var ( - x VgaInterfaceInfo - xc C.libxl_vga_interface_info - ) +var ( +x VgaInterfaceInfo +xc C.libxl_vga_interface_info) - C.libxl_vga_interface_info_init(&xc) - defer C.libxl_vga_interface_info_dispose(&xc) +C.libxl_vga_interface_info_init(&xc) +defer C.libxl_vga_interface_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *VgaInterfaceInfo) fromC(xc *C.libxl_vga_interface_info) error { - x.Kind = VgaInterfaceType(xc.kind) - - return nil -} + x.Kind = VgaInterfaceType(xc.kind) + + return nil} -func (x *VgaInterfaceInfo) toC(xc *C.libxl_vga_interface_info) (err error) { - defer func() { - if err != nil { - C.libxl_vga_interface_info_dispose(xc) - } - }() +func (x *VgaInterfaceInfo) toC(xc *C.libxl_vga_interface_info) (err error){defer func(){ +if err != nil{ +C.libxl_vga_interface_info_dispose(xc)} +}() - xc.kind = C.libxl_vga_interface_type(x.Kind) +xc.kind = C.libxl_vga_interface_type(x.Kind) - return nil -} + return nil + } // NewVncInfo returns an instance of VncInfo initialized with defaults. func NewVncInfo() (*VncInfo, error) { - var ( - x VncInfo - xc C.libxl_vnc_info - ) +var ( +x VncInfo +xc C.libxl_vnc_info) - C.libxl_vnc_info_init(&xc) - defer C.libxl_vnc_info_dispose(&xc) +C.libxl_vnc_info_init(&xc) +defer C.libxl_vnc_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *VncInfo) fromC(xc *C.libxl_vnc_info) error { - if err := x.Enable.fromC(&xc.enable); err != nil { - return fmt.Errorf("converting field Enable: %v", err) - } - x.Listen = C.GoString(xc.listen) - x.Passwd = C.GoString(xc.passwd) - x.Display = int(xc.display) - if err := x.Findunused.fromC(&xc.findunused); err != nil { - return fmt.Errorf("converting field Findunused: %v", err) - } - - return nil -} - -func (x *VncInfo) toC(xc *C.libxl_vnc_info) (err error) { - defer func() { - if err != nil { - C.libxl_vnc_info_dispose(xc) - } - }() - - if err := x.Enable.toC(&xc.enable); err != nil { - return fmt.Errorf("converting field Enable: %v", err) - } - if x.Listen != "" { - xc.listen = C.CString(x.Listen) - } - if x.Passwd != "" { - xc.passwd = C.CString(x.Passwd) - } - xc.display = C.int(x.Display) - if err := x.Findunused.toC(&xc.findunused); err != nil { - return fmt.Errorf("converting field Findunused: %v", err) - } - - return nil + if err := x.Enable.fromC(&xc.enable);err != nil { +return fmt.Errorf("converting field Enable: %v", err) +} +x.Listen = C.GoString(xc.listen) +x.Passwd = C.GoString(xc.passwd) +x.Display = int(xc.display) +if err := x.Findunused.fromC(&xc.findunused);err != nil { +return fmt.Errorf("converting field Findunused: %v", err) +} + + return nil} + +func (x *VncInfo) toC(xc *C.libxl_vnc_info) (err error){defer func(){ +if err != nil{ +C.libxl_vnc_info_dispose(xc)} +}() + +if err := x.Enable.toC(&xc.enable); err != nil { +return fmt.Errorf("converting field Enable: %v", err) +} +if x.Listen != "" { +xc.listen = C.CString(x.Listen)} +if x.Passwd != "" { +xc.passwd = C.CString(x.Passwd)} +xc.display = C.int(x.Display) +if err := x.Findunused.toC(&xc.findunused); err != nil { +return fmt.Errorf("converting field Findunused: %v", err) } + return nil + } + // NewSpiceInfo returns an instance of SpiceInfo initialized with defaults. func NewSpiceInfo() (*SpiceInfo, error) { - var ( - x SpiceInfo - xc C.libxl_spice_info - ) +var ( +x SpiceInfo +xc C.libxl_spice_info) - C.libxl_spice_info_init(&xc) - defer C.libxl_spice_info_dispose(&xc) +C.libxl_spice_info_init(&xc) +defer C.libxl_spice_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *SpiceInfo) fromC(xc *C.libxl_spice_info) error { - if err := x.Enable.fromC(&xc.enable); err != nil { - return fmt.Errorf("converting field Enable: %v", err) - } - x.Port = int(xc.port) - x.TlsPort = int(xc.tls_port) - x.Host = C.GoString(xc.host) - if err := x.DisableTicketing.fromC(&xc.disable_ticketing); err != nil { - return fmt.Errorf("converting field DisableTicketing: %v", err) - } - x.Passwd = C.GoString(xc.passwd) - if err := x.AgentMouse.fromC(&xc.agent_mouse); err != nil { - return fmt.Errorf("converting field AgentMouse: %v", err) - } - if err := x.Vdagent.fromC(&xc.vdagent); err != nil { - return fmt.Errorf("converting field Vdagent: %v", err) - } - if err := x.ClipboardSharing.fromC(&xc.clipboard_sharing); err != nil { - return fmt.Errorf("converting field ClipboardSharing: %v", err) - } - x.Usbredirection = int(xc.usbredirection) - x.ImageCompression = C.GoString(xc.image_compression) - x.StreamingVideo = C.GoString(xc.streaming_video) - - return nil -} - -func (x *SpiceInfo) toC(xc *C.libxl_spice_info) (err error) { - defer func() { - if err != nil { - C.libxl_spice_info_dispose(xc) - } - }() - - if err := x.Enable.toC(&xc.enable); err != nil { - return fmt.Errorf("converting field Enable: %v", err) - } - xc.port = C.int(x.Port) - xc.tls_port = C.int(x.TlsPort) - if x.Host != "" { - xc.host = C.CString(x.Host) - } - if err := x.DisableTicketing.toC(&xc.disable_ticketing); err != nil { - return fmt.Errorf("converting field DisableTicketing: %v", err) - } - if x.Passwd != "" { - xc.passwd = C.CString(x.Passwd) - } - if err := x.AgentMouse.toC(&xc.agent_mouse); err != nil { - return fmt.Errorf("converting field AgentMouse: %v", err) - } - if err := x.Vdagent.toC(&xc.vdagent); err != nil { - return fmt.Errorf("converting field Vdagent: %v", err) - } - if err := x.ClipboardSharing.toC(&xc.clipboard_sharing); err != nil { - return fmt.Errorf("converting field ClipboardSharing: %v", err) - } - xc.usbredirection = C.int(x.Usbredirection) - if x.ImageCompression != "" { - xc.image_compression = C.CString(x.ImageCompression) - } - if x.StreamingVideo != "" { - xc.streaming_video = C.CString(x.StreamingVideo) - } - - return nil -} + if err := x.Enable.fromC(&xc.enable);err != nil { +return fmt.Errorf("converting field Enable: %v", err) +} +x.Port = int(xc.port) +x.TlsPort = int(xc.tls_port) +x.Host = C.GoString(xc.host) +if err := x.DisableTicketing.fromC(&xc.disable_ticketing);err != nil { +return fmt.Errorf("converting field DisableTicketing: %v", err) +} +x.Passwd = C.GoString(xc.passwd) +if err := x.AgentMouse.fromC(&xc.agent_mouse);err != nil { +return fmt.Errorf("converting field AgentMouse: %v", err) +} +if err := x.Vdagent.fromC(&xc.vdagent);err != nil { +return fmt.Errorf("converting field Vdagent: %v", err) +} +if err := x.ClipboardSharing.fromC(&xc.clipboard_sharing);err != nil { +return fmt.Errorf("converting field ClipboardSharing: %v", err) +} +x.Usbredirection = int(xc.usbredirection) +x.ImageCompression = C.GoString(xc.image_compression) +x.StreamingVideo = C.GoString(xc.streaming_video) + + return nil} + +func (x *SpiceInfo) toC(xc *C.libxl_spice_info) (err error){defer func(){ +if err != nil{ +C.libxl_spice_info_dispose(xc)} +}() + +if err := x.Enable.toC(&xc.enable); err != nil { +return fmt.Errorf("converting field Enable: %v", err) +} +xc.port = C.int(x.Port) +xc.tls_port = C.int(x.TlsPort) +if x.Host != "" { +xc.host = C.CString(x.Host)} +if err := x.DisableTicketing.toC(&xc.disable_ticketing); err != nil { +return fmt.Errorf("converting field DisableTicketing: %v", err) +} +if x.Passwd != "" { +xc.passwd = C.CString(x.Passwd)} +if err := x.AgentMouse.toC(&xc.agent_mouse); err != nil { +return fmt.Errorf("converting field AgentMouse: %v", err) +} +if err := x.Vdagent.toC(&xc.vdagent); err != nil { +return fmt.Errorf("converting field Vdagent: %v", err) +} +if err := x.ClipboardSharing.toC(&xc.clipboard_sharing); err != nil { +return fmt.Errorf("converting field ClipboardSharing: %v", err) +} +xc.usbredirection = C.int(x.Usbredirection) +if x.ImageCompression != "" { +xc.image_compression = C.CString(x.ImageCompression)} +if x.StreamingVideo != "" { +xc.streaming_video = C.CString(x.StreamingVideo)} + + return nil + } // NewSdlInfo returns an instance of SdlInfo initialized with defaults. func NewSdlInfo() (*SdlInfo, error) { - var ( - x SdlInfo - xc C.libxl_sdl_info - ) +var ( +x SdlInfo +xc C.libxl_sdl_info) - C.libxl_sdl_info_init(&xc) - defer C.libxl_sdl_info_dispose(&xc) +C.libxl_sdl_info_init(&xc) +defer C.libxl_sdl_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *SdlInfo) fromC(xc *C.libxl_sdl_info) error { - if err := x.Enable.fromC(&xc.enable); err != nil { - return fmt.Errorf("converting field Enable: %v", err) - } - if err := x.Opengl.fromC(&xc.opengl); err != nil { - return fmt.Errorf("converting field Opengl: %v", err) - } - x.Display = C.GoString(xc.display) - x.Xauthority = C.GoString(xc.xauthority) - - return nil -} - -func (x *SdlInfo) toC(xc *C.libxl_sdl_info) (err error) { - defer func() { - if err != nil { - C.libxl_sdl_info_dispose(xc) - } - }() - - if err := x.Enable.toC(&xc.enable); err != nil { - return fmt.Errorf("converting field Enable: %v", err) - } - if err := x.Opengl.toC(&xc.opengl); err != nil { - return fmt.Errorf("converting field Opengl: %v", err) - } - if x.Display != "" { - xc.display = C.CString(x.Display) - } - if x.Xauthority != "" { - xc.xauthority = C.CString(x.Xauthority) - } - - return nil + if err := x.Enable.fromC(&xc.enable);err != nil { +return fmt.Errorf("converting field Enable: %v", err) } +if err := x.Opengl.fromC(&xc.opengl);err != nil { +return fmt.Errorf("converting field Opengl: %v", err) +} +x.Display = C.GoString(xc.display) +x.Xauthority = C.GoString(xc.xauthority) + + return nil} + +func (x *SdlInfo) toC(xc *C.libxl_sdl_info) (err error){defer func(){ +if err != nil{ +C.libxl_sdl_info_dispose(xc)} +}() + +if err := x.Enable.toC(&xc.enable); err != nil { +return fmt.Errorf("converting field Enable: %v", err) +} +if err := x.Opengl.toC(&xc.opengl); err != nil { +return fmt.Errorf("converting field Opengl: %v", err) +} +if x.Display != "" { +xc.display = C.CString(x.Display)} +if x.Xauthority != "" { +xc.xauthority = C.CString(x.Xauthority)} + + return nil + } // NewDominfo returns an instance of Dominfo initialized with defaults. func NewDominfo() (*Dominfo, error) { - var ( - x Dominfo - xc C.libxl_dominfo - ) +var ( +x Dominfo +xc C.libxl_dominfo) - C.libxl_dominfo_init(&xc) - defer C.libxl_dominfo_dispose(&xc) +C.libxl_dominfo_init(&xc) +defer C.libxl_dominfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Dominfo) fromC(xc *C.libxl_dominfo) error { - if err := x.Uuid.fromC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } - x.Domid = Domid(xc.domid) - x.Ssidref = uint32(xc.ssidref) - x.SsidLabel = C.GoString(xc.ssid_label) - x.Running = bool(xc.running) - x.Blocked = bool(xc.blocked) - x.Paused = bool(xc.paused) - x.Shutdown = bool(xc.shutdown) - x.Dying = bool(xc.dying) - x.NeverStop = bool(xc.never_stop) - x.ShutdownReason = ShutdownReason(xc.shutdown_reason) - x.OutstandingMemkb = uint64(xc.outstanding_memkb) - x.CurrentMemkb = uint64(xc.current_memkb) - x.SharedMemkb = uint64(xc.shared_memkb) - x.PagedMemkb = uint64(xc.paged_memkb) - x.MaxMemkb = uint64(xc.max_memkb) - x.CpuTime = uint64(xc.cpu_time) - x.VcpuMaxId = uint32(xc.vcpu_max_id) - x.VcpuOnline = uint32(xc.vcpu_online) - x.Cpupool = uint32(xc.cpupool) - x.DomainType = DomainType(xc.domain_type) - - return nil -} - -func (x *Dominfo) toC(xc *C.libxl_dominfo) (err error) { - defer func() { - if err != nil { - C.libxl_dominfo_dispose(xc) - } - }() - - if err := x.Uuid.toC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } - xc.domid = C.libxl_domid(x.Domid) - xc.ssidref = C.uint32_t(x.Ssidref) - if x.SsidLabel != "" { - xc.ssid_label = C.CString(x.SsidLabel) - } - xc.running = C.bool(x.Running) - xc.blocked = C.bool(x.Blocked) - xc.paused = C.bool(x.Paused) - xc.shutdown = C.bool(x.Shutdown) - xc.dying = C.bool(x.Dying) - xc.never_stop = C.bool(x.NeverStop) - xc.shutdown_reason = C.libxl_shutdown_reason(x.ShutdownReason) - xc.outstanding_memkb = C.uint64_t(x.OutstandingMemkb) - xc.current_memkb = C.uint64_t(x.CurrentMemkb) - xc.shared_memkb = C.uint64_t(x.SharedMemkb) - xc.paged_memkb = C.uint64_t(x.PagedMemkb) - xc.max_memkb = C.uint64_t(x.MaxMemkb) - xc.cpu_time = C.uint64_t(x.CpuTime) - xc.vcpu_max_id = C.uint32_t(x.VcpuMaxId) - xc.vcpu_online = C.uint32_t(x.VcpuOnline) - xc.cpupool = C.uint32_t(x.Cpupool) - xc.domain_type = C.libxl_domain_type(x.DomainType) - - return nil -} + if err := x.Uuid.fromC(&xc.uuid);err != nil { +return fmt.Errorf("converting field Uuid: %v", err) +} +x.Domid = Domid(xc.domid) +x.Ssidref = uint32(xc.ssidref) +x.SsidLabel = C.GoString(xc.ssid_label) +x.Running = bool(xc.running) +x.Blocked = bool(xc.blocked) +x.Paused = bool(xc.paused) +x.Shutdown = bool(xc.shutdown) +x.Dying = bool(xc.dying) +x.NeverStop = bool(xc.never_stop) +x.ShutdownReason = ShutdownReason(xc.shutdown_reason) +x.OutstandingMemkb = uint64(xc.outstanding_memkb) +x.CurrentMemkb = uint64(xc.current_memkb) +x.SharedMemkb = uint64(xc.shared_memkb) +x.PagedMemkb = uint64(xc.paged_memkb) +x.MaxMemkb = uint64(xc.max_memkb) +x.CpuTime = uint64(xc.cpu_time) +x.VcpuMaxId = uint32(xc.vcpu_max_id) +x.VcpuOnline = uint32(xc.vcpu_online) +x.Cpupool = uint32(xc.cpupool) +x.DomainType = DomainType(xc.domain_type) + + return nil} + +func (x *Dominfo) toC(xc *C.libxl_dominfo) (err error){defer func(){ +if err != nil{ +C.libxl_dominfo_dispose(xc)} +}() + +if err := x.Uuid.toC(&xc.uuid); err != nil { +return fmt.Errorf("converting field Uuid: %v", err) +} +xc.domid = C.libxl_domid(x.Domid) +xc.ssidref = C.uint32_t(x.Ssidref) +if x.SsidLabel != "" { +xc.ssid_label = C.CString(x.SsidLabel)} +xc.running = C.bool(x.Running) +xc.blocked = C.bool(x.Blocked) +xc.paused = C.bool(x.Paused) +xc.shutdown = C.bool(x.Shutdown) +xc.dying = C.bool(x.Dying) +xc.never_stop = C.bool(x.NeverStop) +xc.shutdown_reason = C.libxl_shutdown_reason(x.ShutdownReason) +xc.outstanding_memkb = C.uint64_t(x.OutstandingMemkb) +xc.current_memkb = C.uint64_t(x.CurrentMemkb) +xc.shared_memkb = C.uint64_t(x.SharedMemkb) +xc.paged_memkb = C.uint64_t(x.PagedMemkb) +xc.max_memkb = C.uint64_t(x.MaxMemkb) +xc.cpu_time = C.uint64_t(x.CpuTime) +xc.vcpu_max_id = C.uint32_t(x.VcpuMaxId) +xc.vcpu_online = C.uint32_t(x.VcpuOnline) +xc.cpupool = C.uint32_t(x.Cpupool) +xc.domain_type = C.libxl_domain_type(x.DomainType) + + return nil + } // NewCpupoolinfo returns an instance of Cpupoolinfo initialized with defaults. func NewCpupoolinfo() (*Cpupoolinfo, error) { - var ( - x Cpupoolinfo - xc C.libxl_cpupoolinfo - ) +var ( +x Cpupoolinfo +xc C.libxl_cpupoolinfo) - C.libxl_cpupoolinfo_init(&xc) - defer C.libxl_cpupoolinfo_dispose(&xc) +C.libxl_cpupoolinfo_init(&xc) +defer C.libxl_cpupoolinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Cpupoolinfo) fromC(xc *C.libxl_cpupoolinfo) error { - x.Poolid = uint32(xc.poolid) - x.PoolName = C.GoString(xc.pool_name) - x.Sched = Scheduler(xc.sched) - x.NDom = uint32(xc.n_dom) - if err := x.Cpumap.fromC(&xc.cpumap); err != nil { - return fmt.Errorf("converting field Cpumap: %v", err) - } - - return nil + x.Poolid = uint32(xc.poolid) +x.PoolName = C.GoString(xc.pool_name) +x.Sched = Scheduler(xc.sched) +x.NDom = uint32(xc.n_dom) +if err := x.Cpumap.fromC(&xc.cpumap);err != nil { +return fmt.Errorf("converting field Cpumap: %v", err) } + + return nil} -func (x *Cpupoolinfo) toC(xc *C.libxl_cpupoolinfo) (err error) { - defer func() { - if err != nil { - C.libxl_cpupoolinfo_dispose(xc) - } - }() - - xc.poolid = C.uint32_t(x.Poolid) - if x.PoolName != "" { - xc.pool_name = C.CString(x.PoolName) - } - xc.sched = C.libxl_scheduler(x.Sched) - xc.n_dom = C.uint32_t(x.NDom) - if err := x.Cpumap.toC(&xc.cpumap); err != nil { - return fmt.Errorf("converting field Cpumap: %v", err) - } +func (x *Cpupoolinfo) toC(xc *C.libxl_cpupoolinfo) (err error){defer func(){ +if err != nil{ +C.libxl_cpupoolinfo_dispose(xc)} +}() - return nil +xc.poolid = C.uint32_t(x.Poolid) +if x.PoolName != "" { +xc.pool_name = C.CString(x.PoolName)} +xc.sched = C.libxl_scheduler(x.Sched) +xc.n_dom = C.uint32_t(x.NDom) +if err := x.Cpumap.toC(&xc.cpumap); err != nil { +return fmt.Errorf("converting field Cpumap: %v", err) } + return nil + } + // NewChannelinfo returns an instance of Channelinfo initialized with defaults. func NewChannelinfo(connection ChannelConnection) (*Channelinfo, error) { - var ( - x Channelinfo - xc C.libxl_channelinfo - ) +var ( +x Channelinfo +xc C.libxl_channelinfo) - C.libxl_channelinfo_init(&xc) - C.libxl_channelinfo_init_connection(&xc, C.libxl_channel_connection(connection)) - defer C.libxl_channelinfo_dispose(&xc) +C.libxl_channelinfo_init(&xc) +C.libxl_channelinfo_init_connection(&xc, C.libxl_channel_connection(connection)) +defer C.libxl_channelinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Channelinfo) fromC(xc *C.libxl_channelinfo) error { - x.Backend = C.GoString(xc.backend) - x.BackendId = uint32(xc.backend_id) - x.Frontend = C.GoString(xc.frontend) - x.FrontendId = uint32(xc.frontend_id) - x.Devid = Devid(xc.devid) - x.State = int(xc.state) - x.Evtch = int(xc.evtch) - x.Rref = int(xc.rref) - x.Connection = ChannelConnection(xc.connection) - switch x.Connection { - case ChannelConnectionUnknown: - x.ConnectionUnion = nil - case ChannelConnectionPty: - var connectionPty ChannelinfoConnectionUnionPty - if err := connectionPty.fromC(xc); err != nil { - return fmt.Errorf("converting field connectionPty: %v", err) - } - x.ConnectionUnion = connectionPty - case ChannelConnectionSocket: - x.ConnectionUnion = nil - default: - return fmt.Errorf("invalid union key '%v'", x.Connection) - } - - return nil -} + x.Backend = C.GoString(xc.backend) +x.BackendId = uint32(xc.backend_id) +x.Frontend = C.GoString(xc.frontend) +x.FrontendId = uint32(xc.frontend_id) +x.Devid = Devid(xc.devid) +x.State = int(xc.state) +x.Evtch = int(xc.evtch) +x.Rref = int(xc.rref) +x.Connection = ChannelConnection(xc.connection) +switch x.Connection{ +case ChannelConnectionUnknown: +x.ConnectionUnion = nil +case ChannelConnectionPty: +var connectionPty ChannelinfoConnectionUnionPty +if err := connectionPty.fromC(xc);err != nil { + return fmt.Errorf("converting field connectionPty: %v", err) +} +x.ConnectionUnion = connectionPty +case ChannelConnectionSocket: +x.ConnectionUnion = nil +default: +return fmt.Errorf("invalid union key '%v'", x.Connection)} + + return nil} func (x *ChannelinfoConnectionUnionPty) fromC(xc *C.libxl_channelinfo) error { - if ChannelConnection(xc.connection) != ChannelConnectionPty { - return errors.New("expected union key ChannelConnectionPty") - } - - tmp := (*C.libxl_channelinfo_connection_union_pty)(unsafe.Pointer(&xc.u[0])) - x.Path = C.GoString(tmp.path) - return nil -} - -func (x *Channelinfo) toC(xc *C.libxl_channelinfo) (err error) { - defer func() { - if err != nil { - C.libxl_channelinfo_dispose(xc) - } - }() - - if x.Backend != "" { - xc.backend = C.CString(x.Backend) - } - xc.backend_id = C.uint32_t(x.BackendId) - if x.Frontend != "" { - xc.frontend = C.CString(x.Frontend) - } - xc.frontend_id = C.uint32_t(x.FrontendId) - xc.devid = C.libxl_devid(x.Devid) - xc.state = C.int(x.State) - xc.evtch = C.int(x.Evtch) - xc.rref = C.int(x.Rref) - xc.connection = C.libxl_channel_connection(x.Connection) - switch x.Connection { - case ChannelConnectionUnknown: - break - case ChannelConnectionPty: - tmp, ok := x.ConnectionUnion.(ChannelinfoConnectionUnionPty) - if !ok { - return errors.New("wrong type for union key connection") - } - var pty C.libxl_channelinfo_connection_union_pty - if tmp.Path != "" { - pty.path = C.CString(tmp.Path) - } - ptyBytes := C.GoBytes(unsafe.Pointer(&pty), C.sizeof_libxl_channelinfo_connection_union_pty) - copy(xc.u[:], ptyBytes) - case ChannelConnectionSocket: - break - default: - return fmt.Errorf("invalid union key '%v'", x.Connection) - } - - return nil -} +if ChannelConnection(xc.connection) != ChannelConnectionPty { +return errors.New("expected union key ChannelConnectionPty") +} + +tmp := (*C.libxl_channelinfo_connection_union_pty)(unsafe.Pointer(&xc.u[0])) +x.Path = C.GoString(tmp.path) +return nil +} + +func (x *Channelinfo) toC(xc *C.libxl_channelinfo) (err error){defer func(){ +if err != nil{ +C.libxl_channelinfo_dispose(xc)} +}() + +if x.Backend != "" { +xc.backend = C.CString(x.Backend)} +xc.backend_id = C.uint32_t(x.BackendId) +if x.Frontend != "" { +xc.frontend = C.CString(x.Frontend)} +xc.frontend_id = C.uint32_t(x.FrontendId) +xc.devid = C.libxl_devid(x.Devid) +xc.state = C.int(x.State) +xc.evtch = C.int(x.Evtch) +xc.rref = C.int(x.Rref) +xc.connection = C.libxl_channel_connection(x.Connection) +switch x.Connection{ +case ChannelConnectionUnknown: +break +case ChannelConnectionPty: +tmp, ok := x.ConnectionUnion.(ChannelinfoConnectionUnionPty) +if !ok { +return errors.New("wrong type for union key connection") +} +var pty C.libxl_channelinfo_connection_union_pty +if tmp.Path != "" { +pty.path = C.CString(tmp.Path)} +ptyBytes := C.GoBytes(unsafe.Pointer(&pty),C.sizeof_libxl_channelinfo_connection_union_pty) +copy(xc.u[:],ptyBytes) +case ChannelConnectionSocket: +break +default: +return fmt.Errorf("invalid union key '%v'", x.Connection)} + + return nil + } // NewVminfo returns an instance of Vminfo initialized with defaults. func NewVminfo() (*Vminfo, error) { - var ( - x Vminfo - xc C.libxl_vminfo - ) +var ( +x Vminfo +xc C.libxl_vminfo) - C.libxl_vminfo_init(&xc) - defer C.libxl_vminfo_dispose(&xc) +C.libxl_vminfo_init(&xc) +defer C.libxl_vminfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Vminfo) fromC(xc *C.libxl_vminfo) error { - if err := x.Uuid.fromC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } - x.Domid = Domid(xc.domid) - - return nil + if err := x.Uuid.fromC(&xc.uuid);err != nil { +return fmt.Errorf("converting field Uuid: %v", err) } +x.Domid = Domid(xc.domid) + + return nil} -func (x *Vminfo) toC(xc *C.libxl_vminfo) (err error) { - defer func() { - if err != nil { - C.libxl_vminfo_dispose(xc) - } - }() - - if err := x.Uuid.toC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } - xc.domid = C.libxl_domid(x.Domid) +func (x *Vminfo) toC(xc *C.libxl_vminfo) (err error){defer func(){ +if err != nil{ +C.libxl_vminfo_dispose(xc)} +}() - return nil +if err := x.Uuid.toC(&xc.uuid); err != nil { +return fmt.Errorf("converting field Uuid: %v", err) } +xc.domid = C.libxl_domid(x.Domid) + + return nil + } // NewVersionInfo returns an instance of VersionInfo initialized with defaults. func NewVersionInfo() (*VersionInfo, error) { - var ( - x VersionInfo - xc C.libxl_version_info - ) +var ( +x VersionInfo +xc C.libxl_version_info) - C.libxl_version_info_init(&xc) - defer C.libxl_version_info_dispose(&xc) +C.libxl_version_info_init(&xc) +defer C.libxl_version_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *VersionInfo) fromC(xc *C.libxl_version_info) error { - x.XenVersionMajor = int(xc.xen_version_major) - x.XenVersionMinor = int(xc.xen_version_minor) - x.XenVersionExtra = C.GoString(xc.xen_version_extra) - x.Compiler = C.GoString(xc.compiler) - x.CompileBy = C.GoString(xc.compile_by) - x.CompileDomain = C.GoString(xc.compile_domain) - x.CompileDate = C.GoString(xc.compile_date) - x.Capabilities = C.GoString(xc.capabilities) - x.Changeset = C.GoString(xc.changeset) - x.VirtStart = uint64(xc.virt_start) - x.Pagesize = int(xc.pagesize) - x.Commandline = C.GoString(xc.commandline) - x.BuildId = C.GoString(xc.build_id) - - return nil -} - -func (x *VersionInfo) toC(xc *C.libxl_version_info) (err error) { - defer func() { - if err != nil { - C.libxl_version_info_dispose(xc) - } - }() - - xc.xen_version_major = C.int(x.XenVersionMajor) - xc.xen_version_minor = C.int(x.XenVersionMinor) - if x.XenVersionExtra != "" { - xc.xen_version_extra = C.CString(x.XenVersionExtra) - } - if x.Compiler != "" { - xc.compiler = C.CString(x.Compiler) - } - if x.CompileBy != "" { - xc.compile_by = C.CString(x.CompileBy) - } - if x.CompileDomain != "" { - xc.compile_domain = C.CString(x.CompileDomain) - } - if x.CompileDate != "" { - xc.compile_date = C.CString(x.CompileDate) - } - if x.Capabilities != "" { - xc.capabilities = C.CString(x.Capabilities) - } - if x.Changeset != "" { - xc.changeset = C.CString(x.Changeset) - } - xc.virt_start = C.uint64_t(x.VirtStart) - xc.pagesize = C.int(x.Pagesize) - if x.Commandline != "" { - xc.commandline = C.CString(x.Commandline) - } - if x.BuildId != "" { - xc.build_id = C.CString(x.BuildId) - } - - return nil -} + x.XenVersionMajor = int(xc.xen_version_major) +x.XenVersionMinor = int(xc.xen_version_minor) +x.XenVersionExtra = C.GoString(xc.xen_version_extra) +x.Compiler = C.GoString(xc.compiler) +x.CompileBy = C.GoString(xc.compile_by) +x.CompileDomain = C.GoString(xc.compile_domain) +x.CompileDate = C.GoString(xc.compile_date) +x.Capabilities = C.GoString(xc.capabilities) +x.Changeset = C.GoString(xc.changeset) +x.VirtStart = uint64(xc.virt_start) +x.Pagesize = int(xc.pagesize) +x.Commandline = C.GoString(xc.commandline) +x.BuildId = C.GoString(xc.build_id) + + return nil} + +func (x *VersionInfo) toC(xc *C.libxl_version_info) (err error){defer func(){ +if err != nil{ +C.libxl_version_info_dispose(xc)} +}() + +xc.xen_version_major = C.int(x.XenVersionMajor) +xc.xen_version_minor = C.int(x.XenVersionMinor) +if x.XenVersionExtra != "" { +xc.xen_version_extra = C.CString(x.XenVersionExtra)} +if x.Compiler != "" { +xc.compiler = C.CString(x.Compiler)} +if x.CompileBy != "" { +xc.compile_by = C.CString(x.CompileBy)} +if x.CompileDomain != "" { +xc.compile_domain = C.CString(x.CompileDomain)} +if x.CompileDate != "" { +xc.compile_date = C.CString(x.CompileDate)} +if x.Capabilities != "" { +xc.capabilities = C.CString(x.Capabilities)} +if x.Changeset != "" { +xc.changeset = C.CString(x.Changeset)} +xc.virt_start = C.uint64_t(x.VirtStart) +xc.pagesize = C.int(x.Pagesize) +if x.Commandline != "" { +xc.commandline = C.CString(x.Commandline)} +if x.BuildId != "" { +xc.build_id = C.CString(x.BuildId)} + + return nil + } // NewDomainCreateInfo returns an instance of DomainCreateInfo initialized with defaults. func NewDomainCreateInfo() (*DomainCreateInfo, error) { - var ( - x DomainCreateInfo - xc C.libxl_domain_create_info - ) +var ( +x DomainCreateInfo +xc C.libxl_domain_create_info) - C.libxl_domain_create_info_init(&xc) - defer C.libxl_domain_create_info_dispose(&xc) +C.libxl_domain_create_info_init(&xc) +defer C.libxl_domain_create_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DomainCreateInfo) fromC(xc *C.libxl_domain_create_info) error { - x.Type = DomainType(xc._type) - if err := x.Hap.fromC(&xc.hap); err != nil { - return fmt.Errorf("converting field Hap: %v", err) - } - if err := x.Oos.fromC(&xc.oos); err != nil { - return fmt.Errorf("converting field Oos: %v", err) - } - x.Ssidref = uint32(xc.ssidref) - x.SsidLabel = C.GoString(xc.ssid_label) - x.Name = C.GoString(xc.name) - x.Domid = Domid(xc.domid) - if err := x.Uuid.fromC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } - if err := x.Xsdata.fromC(&xc.xsdata); err != nil { - return fmt.Errorf("converting field Xsdata: %v", err) - } - if err := x.Platformdata.fromC(&xc.platformdata); err != nil { - return fmt.Errorf("converting field Platformdata: %v", err) - } - x.Poolid = uint32(xc.poolid) - x.PoolName = C.GoString(xc.pool_name) - if err := x.RunHotplugScripts.fromC(&xc.run_hotplug_scripts); err != nil { - return fmt.Errorf("converting field RunHotplugScripts: %v", err) - } - if err := x.DriverDomain.fromC(&xc.driver_domain); err != nil { - return fmt.Errorf("converting field DriverDomain: %v", err) - } - x.Passthrough = Passthrough(xc.passthrough) - if err := x.XendSuspendEvtchnCompat.fromC(&xc.xend_suspend_evtchn_compat); err != nil { - return fmt.Errorf("converting field XendSuspendEvtchnCompat: %v", err) - } - - return nil -} - -func (x *DomainCreateInfo) toC(xc *C.libxl_domain_create_info) (err error) { - defer func() { - if err != nil { - C.libxl_domain_create_info_dispose(xc) - } - }() - - xc._type = C.libxl_domain_type(x.Type) - if err := x.Hap.toC(&xc.hap); err != nil { - return fmt.Errorf("converting field Hap: %v", err) - } - if err := x.Oos.toC(&xc.oos); err != nil { - return fmt.Errorf("converting field Oos: %v", err) - } - xc.ssidref = C.uint32_t(x.Ssidref) - if x.SsidLabel != "" { - xc.ssid_label = C.CString(x.SsidLabel) - } - if x.Name != "" { - xc.name = C.CString(x.Name) - } - xc.domid = C.libxl_domid(x.Domid) - if err := x.Uuid.toC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } - if err := x.Xsdata.toC(&xc.xsdata); err != nil { - return fmt.Errorf("converting field Xsdata: %v", err) - } - if err := x.Platformdata.toC(&xc.platformdata); err != nil { - return fmt.Errorf("converting field Platformdata: %v", err) - } - xc.poolid = C.uint32_t(x.Poolid) - if x.PoolName != "" { - xc.pool_name = C.CString(x.PoolName) - } - if err := x.RunHotplugScripts.toC(&xc.run_hotplug_scripts); err != nil { - return fmt.Errorf("converting field RunHotplugScripts: %v", err) - } - if err := x.DriverDomain.toC(&xc.driver_domain); err != nil { - return fmt.Errorf("converting field DriverDomain: %v", err) - } - xc.passthrough = C.libxl_passthrough(x.Passthrough) - if err := x.XendSuspendEvtchnCompat.toC(&xc.xend_suspend_evtchn_compat); err != nil { - return fmt.Errorf("converting field XendSuspendEvtchnCompat: %v", err) - } - - return nil + x.Type = DomainType(xc._type) +if err := x.Hap.fromC(&xc.hap);err != nil { +return fmt.Errorf("converting field Hap: %v", err) +} +if err := x.Oos.fromC(&xc.oos);err != nil { +return fmt.Errorf("converting field Oos: %v", err) +} +x.Ssidref = uint32(xc.ssidref) +x.SsidLabel = C.GoString(xc.ssid_label) +x.Name = C.GoString(xc.name) +x.Domid = Domid(xc.domid) +if err := x.Uuid.fromC(&xc.uuid);err != nil { +return fmt.Errorf("converting field Uuid: %v", err) +} +if err := x.Xsdata.fromC(&xc.xsdata);err != nil { +return fmt.Errorf("converting field Xsdata: %v", err) +} +if err := x.Platformdata.fromC(&xc.platformdata);err != nil { +return fmt.Errorf("converting field Platformdata: %v", err) +} +x.Poolid = uint32(xc.poolid) +x.PoolName = C.GoString(xc.pool_name) +if err := x.RunHotplugScripts.fromC(&xc.run_hotplug_scripts);err != nil { +return fmt.Errorf("converting field RunHotplugScripts: %v", err) +} +if err := x.DriverDomain.fromC(&xc.driver_domain);err != nil { +return fmt.Errorf("converting field DriverDomain: %v", err) +} +x.Passthrough = Passthrough(xc.passthrough) +if err := x.XendSuspendEvtchnCompat.fromC(&xc.xend_suspend_evtchn_compat);err != nil { +return fmt.Errorf("converting field XendSuspendEvtchnCompat: %v", err) +} + + return nil} + +func (x *DomainCreateInfo) toC(xc *C.libxl_domain_create_info) (err error){defer func(){ +if err != nil{ +C.libxl_domain_create_info_dispose(xc)} +}() + +xc._type = C.libxl_domain_type(x.Type) +if err := x.Hap.toC(&xc.hap); err != nil { +return fmt.Errorf("converting field Hap: %v", err) +} +if err := x.Oos.toC(&xc.oos); err != nil { +return fmt.Errorf("converting field Oos: %v", err) +} +xc.ssidref = C.uint32_t(x.Ssidref) +if x.SsidLabel != "" { +xc.ssid_label = C.CString(x.SsidLabel)} +if x.Name != "" { +xc.name = C.CString(x.Name)} +xc.domid = C.libxl_domid(x.Domid) +if err := x.Uuid.toC(&xc.uuid); err != nil { +return fmt.Errorf("converting field Uuid: %v", err) +} +if err := x.Xsdata.toC(&xc.xsdata); err != nil { +return fmt.Errorf("converting field Xsdata: %v", err) +} +if err := x.Platformdata.toC(&xc.platformdata); err != nil { +return fmt.Errorf("converting field Platformdata: %v", err) +} +xc.poolid = C.uint32_t(x.Poolid) +if x.PoolName != "" { +xc.pool_name = C.CString(x.PoolName)} +if err := x.RunHotplugScripts.toC(&xc.run_hotplug_scripts); err != nil { +return fmt.Errorf("converting field RunHotplugScripts: %v", err) +} +if err := x.DriverDomain.toC(&xc.driver_domain); err != nil { +return fmt.Errorf("converting field DriverDomain: %v", err) +} +xc.passthrough = C.libxl_passthrough(x.Passthrough) +if err := x.XendSuspendEvtchnCompat.toC(&xc.xend_suspend_evtchn_compat); err != nil { +return fmt.Errorf("converting field XendSuspendEvtchnCompat: %v", err) } + return nil + } + // NewDomainRestoreParams returns an instance of DomainRestoreParams initialized with defaults. func NewDomainRestoreParams() (*DomainRestoreParams, error) { - var ( - x DomainRestoreParams - xc C.libxl_domain_restore_params - ) +var ( +x DomainRestoreParams +xc C.libxl_domain_restore_params) - C.libxl_domain_restore_params_init(&xc) - defer C.libxl_domain_restore_params_dispose(&xc) +C.libxl_domain_restore_params_init(&xc) +defer C.libxl_domain_restore_params_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DomainRestoreParams) fromC(xc *C.libxl_domain_restore_params) error { - x.CheckpointedStream = int(xc.checkpointed_stream) - x.StreamVersion = uint32(xc.stream_version) - x.ColoProxyScript = C.GoString(xc.colo_proxy_script) - if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy); err != nil { - return fmt.Errorf("converting field UserspaceColoProxy: %v", err) - } - - return nil + x.CheckpointedStream = int(xc.checkpointed_stream) +x.StreamVersion = uint32(xc.stream_version) +x.ColoProxyScript = C.GoString(xc.colo_proxy_script) +if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy);err != nil { +return fmt.Errorf("converting field UserspaceColoProxy: %v", err) } + + return nil} -func (x *DomainRestoreParams) toC(xc *C.libxl_domain_restore_params) (err error) { - defer func() { - if err != nil { - C.libxl_domain_restore_params_dispose(xc) - } - }() +func (x *DomainRestoreParams) toC(xc *C.libxl_domain_restore_params) (err error){defer func(){ +if err != nil{ +C.libxl_domain_restore_params_dispose(xc)} +}() - xc.checkpointed_stream = C.int(x.CheckpointedStream) - xc.stream_version = C.uint32_t(x.StreamVersion) - if x.ColoProxyScript != "" { - xc.colo_proxy_script = C.CString(x.ColoProxyScript) - } - if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil { - return fmt.Errorf("converting field UserspaceColoProxy: %v", err) - } - - return nil +xc.checkpointed_stream = C.int(x.CheckpointedStream) +xc.stream_version = C.uint32_t(x.StreamVersion) +if x.ColoProxyScript != "" { +xc.colo_proxy_script = C.CString(x.ColoProxyScript)} +if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil { +return fmt.Errorf("converting field UserspaceColoProxy: %v", err) } + return nil + } + // NewSchedParams returns an instance of SchedParams initialized with defaults. func NewSchedParams() (*SchedParams, error) { - var ( - x SchedParams - xc C.libxl_sched_params - ) +var ( +x SchedParams +xc C.libxl_sched_params) - C.libxl_sched_params_init(&xc) - defer C.libxl_sched_params_dispose(&xc) +C.libxl_sched_params_init(&xc) +defer C.libxl_sched_params_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *SchedParams) fromC(xc *C.libxl_sched_params) error { - x.Vcpuid = int(xc.vcpuid) - x.Weight = int(xc.weight) - x.Cap = int(xc.cap) - x.Period = int(xc.period) - x.Extratime = int(xc.extratime) - x.Budget = int(xc.budget) - - return nil -} - -func (x *SchedParams) toC(xc *C.libxl_sched_params) (err error) { - defer func() { - if err != nil { - C.libxl_sched_params_dispose(xc) - } - }() - - xc.vcpuid = C.int(x.Vcpuid) - xc.weight = C.int(x.Weight) - xc.cap = C.int(x.Cap) - xc.period = C.int(x.Period) - xc.extratime = C.int(x.Extratime) - xc.budget = C.int(x.Budget) - - return nil -} + x.Vcpuid = int(xc.vcpuid) +x.Weight = int(xc.weight) +x.Cap = int(xc.cap) +x.Period = int(xc.period) +x.Extratime = int(xc.extratime) +x.Budget = int(xc.budget) + + return nil} + +func (x *SchedParams) toC(xc *C.libxl_sched_params) (err error){defer func(){ +if err != nil{ +C.libxl_sched_params_dispose(xc)} +}() + +xc.vcpuid = C.int(x.Vcpuid) +xc.weight = C.int(x.Weight) +xc.cap = C.int(x.Cap) +xc.period = C.int(x.Period) +xc.extratime = C.int(x.Extratime) +xc.budget = C.int(x.Budget) + + return nil + } // NewVcpuSchedParams returns an instance of VcpuSchedParams initialized with defaults. func NewVcpuSchedParams() (*VcpuSchedParams, error) { - var ( - x VcpuSchedParams - xc C.libxl_vcpu_sched_params - ) +var ( +x VcpuSchedParams +xc C.libxl_vcpu_sched_params) - C.libxl_vcpu_sched_params_init(&xc) - defer C.libxl_vcpu_sched_params_dispose(&xc) +C.libxl_vcpu_sched_params_init(&xc) +defer C.libxl_vcpu_sched_params_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *VcpuSchedParams) fromC(xc *C.libxl_vcpu_sched_params) error { - x.Sched = Scheduler(xc.sched) - x.Vcpus = nil - if n := int(xc.num_vcpus); n > 0 { - cVcpus := (*[1 << 28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:n:n] - x.Vcpus = make([]SchedParams, n) - for i, v := range cVcpus { - if err := x.Vcpus[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Vcpus: %v", err) - } - } - } - - return nil -} - -func (x *VcpuSchedParams) toC(xc *C.libxl_vcpu_sched_params) (err error) { - defer func() { - if err != nil { - C.libxl_vcpu_sched_params_dispose(xc) - } - }() - - xc.sched = C.libxl_scheduler(x.Sched) - if numVcpus := len(x.Vcpus); numVcpus > 0 { - xc.vcpus = (*C.libxl_sched_params)(C.malloc(C.ulong(numVcpus) * C.sizeof_libxl_sched_params)) - xc.num_vcpus = C.int(numVcpus) - cVcpus := (*[1 << 28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:numVcpus:numVcpus] - for i, v := range x.Vcpus { - if err := v.toC(&cVcpus[i]); err != nil { - return fmt.Errorf("converting field Vcpus: %v", err) - } - } - } - - return nil + x.Sched = Scheduler(xc.sched) +x.Vcpus = nil +if n := int(xc.num_vcpus); n > 0 { +cVcpus := (*[1<<28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:n:n] +x.Vcpus = make([]SchedParams, n) +for i, v := range cVcpus { +if err := x.Vcpus[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Vcpus: %v", err) } } +} + + return nil} -// NewDomainSchedParams returns an instance of DomainSchedParams initialized with defaults. -func NewDomainSchedParams() (*DomainSchedParams, error) { - var ( - x DomainSchedParams - xc C.libxl_domain_sched_params - ) - - C.libxl_domain_sched_params_init(&xc) - defer C.libxl_domain_sched_params_dispose(&xc) - - if err := x.fromC(&xc); err != nil { - return nil, err - } +func (x *VcpuSchedParams) toC(xc *C.libxl_vcpu_sched_params) (err error){defer func(){ +if err != nil{ +C.libxl_vcpu_sched_params_dispose(xc)} +}() - return &x, nil +xc.sched = C.libxl_scheduler(x.Sched) +if numVcpus := len(x.Vcpus); numVcpus > 0 { +xc.vcpus = (*C.libxl_sched_params)(C.malloc(C.ulong(numVcpus)*C.sizeof_libxl_sched_params)) +xc.num_vcpus = C.int(numVcpus) +cVcpus := (*[1<<28]C.libxl_sched_params)(unsafe.Pointer(xc.vcpus))[:numVcpus:numVcpus] +for i,v := range x.Vcpus { +if err := v.toC(&cVcpus[i]); err != nil { +return fmt.Errorf("converting field Vcpus: %v", err) +} +} } -func (x *DomainSchedParams) fromC(xc *C.libxl_domain_sched_params) error { - x.Sched = Scheduler(xc.sched) - x.Weight = int(xc.weight) - x.Cap = int(xc.cap) - x.Period = int(xc.period) - x.Budget = int(xc.budget) - x.Extratime = int(xc.extratime) - x.Slice = int(xc.slice) - x.Latency = int(xc.latency) + return nil + } - return nil -} +// NewDomainSchedParams returns an instance of DomainSchedParams initialized with defaults. +func NewDomainSchedParams() (*DomainSchedParams, error) { +var ( +x DomainSchedParams +xc C.libxl_domain_sched_params) -func (x *DomainSchedParams) toC(xc *C.libxl_domain_sched_params) (err error) { - defer func() { - if err != nil { - C.libxl_domain_sched_params_dispose(xc) - } - }() +C.libxl_domain_sched_params_init(&xc) +defer C.libxl_domain_sched_params_dispose(&xc) - xc.sched = C.libxl_scheduler(x.Sched) - xc.weight = C.int(x.Weight) - xc.cap = C.int(x.Cap) - xc.period = C.int(x.Period) - xc.budget = C.int(x.Budget) - xc.extratime = C.int(x.Extratime) - xc.slice = C.int(x.Slice) - xc.latency = C.int(x.Latency) +if err := x.fromC(&xc); err != nil { +return nil, err } - return nil -} +return &x, nil} + +func (x *DomainSchedParams) fromC(xc *C.libxl_domain_sched_params) error { + x.Sched = Scheduler(xc.sched) +x.Weight = int(xc.weight) +x.Cap = int(xc.cap) +x.Period = int(xc.period) +x.Budget = int(xc.budget) +x.Extratime = int(xc.extratime) +x.Slice = int(xc.slice) +x.Latency = int(xc.latency) + + return nil} + +func (x *DomainSchedParams) toC(xc *C.libxl_domain_sched_params) (err error){defer func(){ +if err != nil{ +C.libxl_domain_sched_params_dispose(xc)} +}() + +xc.sched = C.libxl_scheduler(x.Sched) +xc.weight = C.int(x.Weight) +xc.cap = C.int(x.Cap) +xc.period = C.int(x.Period) +xc.budget = C.int(x.Budget) +xc.extratime = C.int(x.Extratime) +xc.slice = C.int(x.Slice) +xc.latency = C.int(x.Latency) + + return nil + } // NewVnodeInfo returns an instance of VnodeInfo initialized with defaults. func NewVnodeInfo() (*VnodeInfo, error) { - var ( - x VnodeInfo - xc C.libxl_vnode_info - ) +var ( +x VnodeInfo +xc C.libxl_vnode_info) - C.libxl_vnode_info_init(&xc) - defer C.libxl_vnode_info_dispose(&xc) +C.libxl_vnode_info_init(&xc) +defer C.libxl_vnode_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *VnodeInfo) fromC(xc *C.libxl_vnode_info) error { - x.Memkb = uint64(xc.memkb) - x.Distances = nil - if n := int(xc.num_distances); n > 0 { - cDistances := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.distances))[:n:n] - x.Distances = make([]uint32, n) - for i, v := range cDistances { - x.Distances[i] = uint32(v) - } - } - x.Pnode = uint32(xc.pnode) - if err := x.Vcpus.fromC(&xc.vcpus); err != nil { - return fmt.Errorf("converting field Vcpus: %v", err) - } - - return nil -} - -func (x *VnodeInfo) toC(xc *C.libxl_vnode_info) (err error) { - defer func() { - if err != nil { - C.libxl_vnode_info_dispose(xc) - } - }() - - xc.memkb = C.uint64_t(x.Memkb) - if numDistances := len(x.Distances); numDistances > 0 { - xc.distances = (*C.uint32_t)(C.malloc(C.size_t(numDistances * numDistances))) - xc.num_distances = C.int(numDistances) - cDistances := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.distances))[:numDistances:numDistances] - for i, v := range x.Distances { - cDistances[i] = C.uint32_t(v) - } - } - xc.pnode = C.uint32_t(x.Pnode) - if err := x.Vcpus.toC(&xc.vcpus); err != nil { - return fmt.Errorf("converting field Vcpus: %v", err) - } - - return nil + x.Memkb = uint64(xc.memkb) +x.Distances = nil +if n := int(xc.num_distances); n > 0 { +cDistances := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.distances))[:n:n] +x.Distances = make([]uint32, n) +for i, v := range cDistances { +x.Distances[i] = uint32(v) +} +} +x.Pnode = uint32(xc.pnode) +if err := x.Vcpus.fromC(&xc.vcpus);err != nil { +return fmt.Errorf("converting field Vcpus: %v", err) } + + return nil} + +func (x *VnodeInfo) toC(xc *C.libxl_vnode_info) (err error){defer func(){ +if err != nil{ +C.libxl_vnode_info_dispose(xc)} +}() + +xc.memkb = C.uint64_t(x.Memkb) +if numDistances := len(x.Distances); numDistances > 0 { +xc.distances = (*C.uint32_t)(C.malloc(C.size_t(numDistances*numDistances))) +xc.num_distances = C.int(numDistances) +cDistances := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.distances))[:numDistances:numDistances] +for i,v := range x.Distances { +cDistances[i] = C.uint32_t(v) +} +} +xc.pnode = C.uint32_t(x.Pnode) +if err := x.Vcpus.toC(&xc.vcpus); err != nil { +return fmt.Errorf("converting field Vcpus: %v", err) +} + + return nil + } // NewRdmReserve returns an instance of RdmReserve initialized with defaults. func NewRdmReserve() (*RdmReserve, error) { - var ( - x RdmReserve - xc C.libxl_rdm_reserve - ) +var ( +x RdmReserve +xc C.libxl_rdm_reserve) - C.libxl_rdm_reserve_init(&xc) - defer C.libxl_rdm_reserve_dispose(&xc) +C.libxl_rdm_reserve_init(&xc) +defer C.libxl_rdm_reserve_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *RdmReserve) fromC(xc *C.libxl_rdm_reserve) error { - x.Strategy = RdmReserveStrategy(xc.strategy) - x.Policy = RdmReservePolicy(xc.policy) - - return nil -} + x.Strategy = RdmReserveStrategy(xc.strategy) +x.Policy = RdmReservePolicy(xc.policy) + + return nil} -func (x *RdmReserve) toC(xc *C.libxl_rdm_reserve) (err error) { - defer func() { - if err != nil { - C.libxl_rdm_reserve_dispose(xc) - } - }() +func (x *RdmReserve) toC(xc *C.libxl_rdm_reserve) (err error){defer func(){ +if err != nil{ +C.libxl_rdm_reserve_dispose(xc)} +}() - xc.strategy = C.libxl_rdm_reserve_strategy(x.Strategy) - xc.policy = C.libxl_rdm_reserve_policy(x.Policy) +xc.strategy = C.libxl_rdm_reserve_strategy(x.Strategy) +xc.policy = C.libxl_rdm_reserve_policy(x.Policy) - return nil -} + return nil + } // NewDomainBuildInfo returns an instance of DomainBuildInfo initialized with defaults. func NewDomainBuildInfo(dtype DomainType) (*DomainBuildInfo, error) { - var ( - x DomainBuildInfo - xc C.libxl_domain_build_info - ) +var ( +x DomainBuildInfo +xc C.libxl_domain_build_info) - C.libxl_domain_build_info_init(&xc) - C.libxl_domain_build_info_init_type(&xc, C.libxl_domain_type(dtype)) - defer C.libxl_domain_build_info_dispose(&xc) +C.libxl_domain_build_info_init(&xc) +C.libxl_domain_build_info_init_type(&xc, C.libxl_domain_type(dtype)) +defer C.libxl_domain_build_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DomainBuildInfo) fromC(xc *C.libxl_domain_build_info) error { - x.MaxVcpus = int(xc.max_vcpus) - if err := x.AvailVcpus.fromC(&xc.avail_vcpus); err != nil { - return fmt.Errorf("converting field AvailVcpus: %v", err) - } - if err := x.Cpumap.fromC(&xc.cpumap); err != nil { - return fmt.Errorf("converting field Cpumap: %v", err) - } - if err := x.Nodemap.fromC(&xc.nodemap); err != nil { - return fmt.Errorf("converting field Nodemap: %v", err) - } - x.VcpuHardAffinity = nil - if n := int(xc.num_vcpu_hard_affinity); n > 0 { - cVcpuHardAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:n:n] - x.VcpuHardAffinity = make([]Bitmap, n) - for i, v := range cVcpuHardAffinity { - if err := x.VcpuHardAffinity[i].fromC(&v); err != nil { - return fmt.Errorf("converting field VcpuHardAffinity: %v", err) - } - } - } - x.VcpuSoftAffinity = nil - if n := int(xc.num_vcpu_soft_affinity); n > 0 { - cVcpuSoftAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:n:n] - x.VcpuSoftAffinity = make([]Bitmap, n) - for i, v := range cVcpuSoftAffinity { - if err := x.VcpuSoftAffinity[i].fromC(&v); err != nil { - return fmt.Errorf("converting field VcpuSoftAffinity: %v", err) - } - } - } - if err := x.NumaPlacement.fromC(&xc.numa_placement); err != nil { - return fmt.Errorf("converting field NumaPlacement: %v", err) - } - x.TscMode = TscMode(xc.tsc_mode) - x.MaxMemkb = uint64(xc.max_memkb) - x.TargetMemkb = uint64(xc.target_memkb) - x.VideoMemkb = uint64(xc.video_memkb) - x.ShadowMemkb = uint64(xc.shadow_memkb) - x.IommuMemkb = uint64(xc.iommu_memkb) - x.RtcTimeoffset = uint32(xc.rtc_timeoffset) - x.ExecSsidref = uint32(xc.exec_ssidref) - x.ExecSsidLabel = C.GoString(xc.exec_ssid_label) - if err := x.Localtime.fromC(&xc.localtime); err != nil { - return fmt.Errorf("converting field Localtime: %v", err) - } - if err := x.DisableMigrate.fromC(&xc.disable_migrate); err != nil { - return fmt.Errorf("converting field DisableMigrate: %v", err) - } - if err := x.Cpuid.fromC(&xc.cpuid); err != nil { - return fmt.Errorf("converting field Cpuid: %v", err) - } - x.BlkdevStart = C.GoString(xc.blkdev_start) - x.VnumaNodes = nil - if n := int(xc.num_vnuma_nodes); n > 0 { - cVnumaNodes := (*[1 << 28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:n:n] - x.VnumaNodes = make([]VnodeInfo, n) - for i, v := range cVnumaNodes { - if err := x.VnumaNodes[i].fromC(&v); err != nil { - return fmt.Errorf("converting field VnumaNodes: %v", err) - } - } - } - x.MaxGrantFrames = uint32(xc.max_grant_frames) - x.MaxMaptrackFrames = uint32(xc.max_maptrack_frames) - x.DeviceModelVersion = DeviceModelVersion(xc.device_model_version) - if err := x.DeviceModelStubdomain.fromC(&xc.device_model_stubdomain); err != nil { - return fmt.Errorf("converting field DeviceModelStubdomain: %v", err) - } - x.StubdomainMemkb = uint64(xc.stubdomain_memkb) - x.StubdomainKernel = C.GoString(xc.stubdomain_kernel) - x.StubdomainRamdisk = C.GoString(xc.stubdomain_ramdisk) - x.DeviceModel = C.GoString(xc.device_model) - x.DeviceModelSsidref = uint32(xc.device_model_ssidref) - x.DeviceModelSsidLabel = C.GoString(xc.device_model_ssid_label) - x.DeviceModelUser = C.GoString(xc.device_model_user) - if err := x.Extra.fromC(&xc.extra); err != nil { - return fmt.Errorf("converting field Extra: %v", err) - } - if err := x.ExtraPv.fromC(&xc.extra_pv); err != nil { - return fmt.Errorf("converting field ExtraPv: %v", err) - } - if err := x.ExtraHvm.fromC(&xc.extra_hvm); err != nil { - return fmt.Errorf("converting field ExtraHvm: %v", err) - } - if err := x.SchedParams.fromC(&xc.sched_params); err != nil { - return fmt.Errorf("converting field SchedParams: %v", err) - } - x.Ioports = nil - if n := int(xc.num_ioports); n > 0 { - cIoports := (*[1 << 28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:n:n] - x.Ioports = make([]IoportRange, n) - for i, v := range cIoports { - if err := x.Ioports[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Ioports: %v", err) - } - } - } - x.Irqs = nil - if n := int(xc.num_irqs); n > 0 { - cIrqs := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:n:n] - x.Irqs = make([]uint32, n) - for i, v := range cIrqs { - x.Irqs[i] = uint32(v) - } - } - x.Iomem = nil - if n := int(xc.num_iomem); n > 0 { - cIomem := (*[1 << 28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:n:n] - x.Iomem = make([]IomemRange, n) - for i, v := range cIomem { - if err := x.Iomem[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Iomem: %v", err) - } - } - } - if err := x.ClaimMode.fromC(&xc.claim_mode); err != nil { - return fmt.Errorf("converting field ClaimMode: %v", err) - } - x.EventChannels = uint32(xc.event_channels) - x.Kernel = C.GoString(xc.kernel) - x.Cmdline = C.GoString(xc.cmdline) - x.Ramdisk = C.GoString(xc.ramdisk) - x.DeviceTree = C.GoString(xc.device_tree) - if err := x.Acpi.fromC(&xc.acpi); err != nil { - return fmt.Errorf("converting field Acpi: %v", err) - } - x.Bootloader = C.GoString(xc.bootloader) - if err := x.BootloaderArgs.fromC(&xc.bootloader_args); err != nil { - return fmt.Errorf("converting field BootloaderArgs: %v", err) - } - x.TimerMode = TimerMode(xc.timer_mode) - if err := x.NestedHvm.fromC(&xc.nested_hvm); err != nil { - return fmt.Errorf("converting field NestedHvm: %v", err) - } - if err := x.Apic.fromC(&xc.apic); err != nil { - return fmt.Errorf("converting field Apic: %v", err) - } - if err := x.DmRestrict.fromC(&xc.dm_restrict); err != nil { - return fmt.Errorf("converting field DmRestrict: %v", err) - } - x.Tee = TeeType(xc.tee) - x.Type = DomainType(xc._type) - switch x.Type { - case DomainTypeHvm: - var typeHvm DomainBuildInfoTypeUnionHvm - if err := typeHvm.fromC(xc); err != nil { - return fmt.Errorf("converting field typeHvm: %v", err) - } - x.TypeUnion = typeHvm - case DomainTypePv: - var typePv DomainBuildInfoTypeUnionPv - if err := typePv.fromC(xc); err != nil { - return fmt.Errorf("converting field typePv: %v", err) - } - x.TypeUnion = typePv - case DomainTypePvh: - var typePvh DomainBuildInfoTypeUnionPvh - if err := typePvh.fromC(xc); err != nil { - return fmt.Errorf("converting field typePvh: %v", err) - } - x.TypeUnion = typePvh - case DomainTypeInvalid: - x.TypeUnion = nil - default: - return fmt.Errorf("invalid union key '%v'", x.Type) - } - x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version) - x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart) - x.Altp2M = Altp2MMode(xc.altp2m) - - return nil -} + x.MaxVcpus = int(xc.max_vcpus) +if err := x.AvailVcpus.fromC(&xc.avail_vcpus);err != nil { +return fmt.Errorf("converting field AvailVcpus: %v", err) +} +if err := x.Cpumap.fromC(&xc.cpumap);err != nil { +return fmt.Errorf("converting field Cpumap: %v", err) +} +if err := x.Nodemap.fromC(&xc.nodemap);err != nil { +return fmt.Errorf("converting field Nodemap: %v", err) +} +x.VcpuHardAffinity = nil +if n := int(xc.num_vcpu_hard_affinity); n > 0 { +cVcpuHardAffinity := (*[1<<28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:n:n] +x.VcpuHardAffinity = make([]Bitmap, n) +for i, v := range cVcpuHardAffinity { +if err := x.VcpuHardAffinity[i].fromC(&v); err != nil { +return fmt.Errorf("converting field VcpuHardAffinity: %v", err) } +} +} +x.VcpuSoftAffinity = nil +if n := int(xc.num_vcpu_soft_affinity); n > 0 { +cVcpuSoftAffinity := (*[1<<28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:n:n] +x.VcpuSoftAffinity = make([]Bitmap, n) +for i, v := range cVcpuSoftAffinity { +if err := x.VcpuSoftAffinity[i].fromC(&v); err != nil { +return fmt.Errorf("converting field VcpuSoftAffinity: %v", err) } +} +} +if err := x.NumaPlacement.fromC(&xc.numa_placement);err != nil { +return fmt.Errorf("converting field NumaPlacement: %v", err) +} +x.TscMode = TscMode(xc.tsc_mode) +x.MaxMemkb = uint64(xc.max_memkb) +x.TargetMemkb = uint64(xc.target_memkb) +x.VideoMemkb = uint64(xc.video_memkb) +x.ShadowMemkb = uint64(xc.shadow_memkb) +x.IommuMemkb = uint64(xc.iommu_memkb) +x.RtcTimeoffset = uint32(xc.rtc_timeoffset) +x.ExecSsidref = uint32(xc.exec_ssidref) +x.ExecSsidLabel = C.GoString(xc.exec_ssid_label) +if err := x.Localtime.fromC(&xc.localtime);err != nil { +return fmt.Errorf("converting field Localtime: %v", err) +} +if err := x.DisableMigrate.fromC(&xc.disable_migrate);err != nil { +return fmt.Errorf("converting field DisableMigrate: %v", err) +} +if err := x.Cpuid.fromC(&xc.cpuid);err != nil { +return fmt.Errorf("converting field Cpuid: %v", err) +} +x.BlkdevStart = C.GoString(xc.blkdev_start) +x.VnumaNodes = nil +if n := int(xc.num_vnuma_nodes); n > 0 { +cVnumaNodes := (*[1<<28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:n:n] +x.VnumaNodes = make([]VnodeInfo, n) +for i, v := range cVnumaNodes { +if err := x.VnumaNodes[i].fromC(&v); err != nil { +return fmt.Errorf("converting field VnumaNodes: %v", err) } +} +} +x.MaxGrantFrames = uint32(xc.max_grant_frames) +x.MaxMaptrackFrames = uint32(xc.max_maptrack_frames) +x.DeviceModelVersion = DeviceModelVersion(xc.device_model_version) +if err := x.DeviceModelStubdomain.fromC(&xc.device_model_stubdomain);err != nil { +return fmt.Errorf("converting field DeviceModelStubdomain: %v", err) +} +x.StubdomainMemkb = uint64(xc.stubdomain_memkb) +x.StubdomainKernel = C.GoString(xc.stubdomain_kernel) +x.StubdomainRamdisk = C.GoString(xc.stubdomain_ramdisk) +x.DeviceModel = C.GoString(xc.device_model) +x.DeviceModelSsidref = uint32(xc.device_model_ssidref) +x.DeviceModelSsidLabel = C.GoString(xc.device_model_ssid_label) +x.DeviceModelUser = C.GoString(xc.device_model_user) +if err := x.Extra.fromC(&xc.extra);err != nil { +return fmt.Errorf("converting field Extra: %v", err) +} +if err := x.ExtraPv.fromC(&xc.extra_pv);err != nil { +return fmt.Errorf("converting field ExtraPv: %v", err) +} +if err := x.ExtraHvm.fromC(&xc.extra_hvm);err != nil { +return fmt.Errorf("converting field ExtraHvm: %v", err) +} +if err := x.SchedParams.fromC(&xc.sched_params);err != nil { +return fmt.Errorf("converting field SchedParams: %v", err) +} +x.Ioports = nil +if n := int(xc.num_ioports); n > 0 { +cIoports := (*[1<<28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:n:n] +x.Ioports = make([]IoportRange, n) +for i, v := range cIoports { +if err := x.Ioports[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Ioports: %v", err) } +} +} +x.Irqs = nil +if n := int(xc.num_irqs); n > 0 { +cIrqs := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:n:n] +x.Irqs = make([]uint32, n) +for i, v := range cIrqs { +x.Irqs[i] = uint32(v) +} +} +x.Iomem = nil +if n := int(xc.num_iomem); n > 0 { +cIomem := (*[1<<28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:n:n] +x.Iomem = make([]IomemRange, n) +for i, v := range cIomem { +if err := x.Iomem[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Iomem: %v", err) } +} +} +if err := x.ClaimMode.fromC(&xc.claim_mode);err != nil { +return fmt.Errorf("converting field ClaimMode: %v", err) +} +x.EventChannels = uint32(xc.event_channels) +x.Kernel = C.GoString(xc.kernel) +x.Cmdline = C.GoString(xc.cmdline) +x.Ramdisk = C.GoString(xc.ramdisk) +x.DeviceTree = C.GoString(xc.device_tree) +if err := x.Acpi.fromC(&xc.acpi);err != nil { +return fmt.Errorf("converting field Acpi: %v", err) +} +x.Bootloader = C.GoString(xc.bootloader) +if err := x.BootloaderArgs.fromC(&xc.bootloader_args);err != nil { +return fmt.Errorf("converting field BootloaderArgs: %v", err) +} +x.TimerMode = TimerMode(xc.timer_mode) +if err := x.NestedHvm.fromC(&xc.nested_hvm);err != nil { +return fmt.Errorf("converting field NestedHvm: %v", err) +} +if err := x.Apic.fromC(&xc.apic);err != nil { +return fmt.Errorf("converting field Apic: %v", err) +} +if err := x.DmRestrict.fromC(&xc.dm_restrict);err != nil { +return fmt.Errorf("converting field DmRestrict: %v", err) +} +x.Tee = TeeType(xc.tee) +x.Type = DomainType(xc._type) +switch x.Type{ +case DomainTypeHvm: +var typeHvm DomainBuildInfoTypeUnionHvm +if err := typeHvm.fromC(xc);err != nil { + return fmt.Errorf("converting field typeHvm: %v", err) +} +x.TypeUnion = typeHvm +case DomainTypePv: +var typePv DomainBuildInfoTypeUnionPv +if err := typePv.fromC(xc);err != nil { + return fmt.Errorf("converting field typePv: %v", err) +} +x.TypeUnion = typePv +case DomainTypePvh: +var typePvh DomainBuildInfoTypeUnionPvh +if err := typePvh.fromC(xc);err != nil { + return fmt.Errorf("converting field typePvh: %v", err) +} +x.TypeUnion = typePvh +case DomainTypeInvalid: +x.TypeUnion = nil +default: +return fmt.Errorf("invalid union key '%v'", x.Type)} +x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version) +x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart) +x.Altp2M = Altp2MMode(xc.altp2m) + + return nil} func (x *DomainBuildInfoTypeUnionHvm) fromC(xc *C.libxl_domain_build_info) error { - if DomainType(xc._type) != DomainTypeHvm { - return errors.New("expected union key DomainTypeHvm") - } - - tmp := (*C.libxl_domain_build_info_type_union_hvm)(unsafe.Pointer(&xc.u[0])) - x.Firmware = C.GoString(tmp.firmware) - x.Bios = BiosType(tmp.bios) - if err := x.Pae.fromC(&tmp.pae); err != nil { - return fmt.Errorf("converting field Pae: %v", err) - } - if err := x.Apic.fromC(&tmp.apic); err != nil { - return fmt.Errorf("converting field Apic: %v", err) - } - if err := x.Acpi.fromC(&tmp.acpi); err != nil { - return fmt.Errorf("converting field Acpi: %v", err) - } - if err := x.AcpiS3.fromC(&tmp.acpi_s3); err != nil { - return fmt.Errorf("converting field AcpiS3: %v", err) - } - if err := x.AcpiS4.fromC(&tmp.acpi_s4); err != nil { - return fmt.Errorf("converting field AcpiS4: %v", err) - } - if err := x.AcpiLaptopSlate.fromC(&tmp.acpi_laptop_slate); err != nil { - return fmt.Errorf("converting field AcpiLaptopSlate: %v", err) - } - if err := x.Nx.fromC(&tmp.nx); err != nil { - return fmt.Errorf("converting field Nx: %v", err) - } - if err := x.Viridian.fromC(&tmp.viridian); err != nil { - return fmt.Errorf("converting field Viridian: %v", err) - } - if err := x.ViridianEnable.fromC(&tmp.viridian_enable); err != nil { - return fmt.Errorf("converting field ViridianEnable: %v", err) - } - if err := x.ViridianDisable.fromC(&tmp.viridian_disable); err != nil { - return fmt.Errorf("converting field ViridianDisable: %v", err) - } - x.Timeoffset = C.GoString(tmp.timeoffset) - if err := x.Hpet.fromC(&tmp.hpet); err != nil { - return fmt.Errorf("converting field Hpet: %v", err) - } - if err := x.VptAlign.fromC(&tmp.vpt_align); err != nil { - return fmt.Errorf("converting field VptAlign: %v", err) - } - x.MmioHoleMemkb = uint64(tmp.mmio_hole_memkb) - x.TimerMode = TimerMode(tmp.timer_mode) - if err := x.NestedHvm.fromC(&tmp.nested_hvm); err != nil { - return fmt.Errorf("converting field NestedHvm: %v", err) - } - if err := x.Altp2M.fromC(&tmp.altp2m); err != nil { - return fmt.Errorf("converting field Altp2M: %v", err) - } - x.SystemFirmware = C.GoString(tmp.system_firmware) - x.SmbiosFirmware = C.GoString(tmp.smbios_firmware) - x.AcpiFirmware = C.GoString(tmp.acpi_firmware) - x.Hdtype = Hdtype(tmp.hdtype) - if err := x.Nographic.fromC(&tmp.nographic); err != nil { - return fmt.Errorf("converting field Nographic: %v", err) - } - if err := x.Vga.fromC(&tmp.vga); err != nil { - return fmt.Errorf("converting field Vga: %v", err) - } - if err := x.Vnc.fromC(&tmp.vnc); err != nil { - return fmt.Errorf("converting field Vnc: %v", err) - } - x.Keymap = C.GoString(tmp.keymap) - if err := x.Sdl.fromC(&tmp.sdl); err != nil { - return fmt.Errorf("converting field Sdl: %v", err) - } - if err := x.Spice.fromC(&tmp.spice); err != nil { - return fmt.Errorf("converting field Spice: %v", err) - } - if err := x.GfxPassthru.fromC(&tmp.gfx_passthru); err != nil { - return fmt.Errorf("converting field GfxPassthru: %v", err) - } - x.GfxPassthruKind = GfxPassthruKind(tmp.gfx_passthru_kind) - x.Serial = C.GoString(tmp.serial) - x.Boot = C.GoString(tmp.boot) - if err := x.Usb.fromC(&tmp.usb); err != nil { - return fmt.Errorf("converting field Usb: %v", err) - } - x.Usbversion = int(tmp.usbversion) - x.Usbdevice = C.GoString(tmp.usbdevice) - if err := x.VkbDevice.fromC(&tmp.vkb_device); err != nil { - return fmt.Errorf("converting field VkbDevice: %v", err) - } - x.Soundhw = C.GoString(tmp.soundhw) - if err := x.XenPlatformPci.fromC(&tmp.xen_platform_pci); err != nil { - return fmt.Errorf("converting field XenPlatformPci: %v", err) - } - if err := x.UsbdeviceList.fromC(&tmp.usbdevice_list); err != nil { - return fmt.Errorf("converting field UsbdeviceList: %v", err) - } - x.VendorDevice = VendorDevice(tmp.vendor_device) - if err := x.MsVmGenid.fromC(&tmp.ms_vm_genid); err != nil { - return fmt.Errorf("converting field MsVmGenid: %v", err) - } - if err := x.SerialList.fromC(&tmp.serial_list); err != nil { - return fmt.Errorf("converting field SerialList: %v", err) - } - if err := x.Rdm.fromC(&tmp.rdm); err != nil { - return fmt.Errorf("converting field Rdm: %v", err) - } - x.RdmMemBoundaryMemkb = uint64(tmp.rdm_mem_boundary_memkb) - x.McaCaps = uint64(tmp.mca_caps) - return nil +if DomainType(xc._type) != DomainTypeHvm { +return errors.New("expected union key DomainTypeHvm") +} + +tmp := (*C.libxl_domain_build_info_type_union_hvm)(unsafe.Pointer(&xc.u[0])) +x.Firmware = C.GoString(tmp.firmware) +x.Bios = BiosType(tmp.bios) +if err := x.Pae.fromC(&tmp.pae);err != nil { +return fmt.Errorf("converting field Pae: %v", err) +} +if err := x.Apic.fromC(&tmp.apic);err != nil { +return fmt.Errorf("converting field Apic: %v", err) +} +if err := x.Acpi.fromC(&tmp.acpi);err != nil { +return fmt.Errorf("converting field Acpi: %v", err) +} +if err := x.AcpiS3.fromC(&tmp.acpi_s3);err != nil { +return fmt.Errorf("converting field AcpiS3: %v", err) +} +if err := x.AcpiS4.fromC(&tmp.acpi_s4);err != nil { +return fmt.Errorf("converting field AcpiS4: %v", err) +} +if err := x.AcpiLaptopSlate.fromC(&tmp.acpi_laptop_slate);err != nil { +return fmt.Errorf("converting field AcpiLaptopSlate: %v", err) +} +if err := x.Nx.fromC(&tmp.nx);err != nil { +return fmt.Errorf("converting field Nx: %v", err) +} +if err := x.Viridian.fromC(&tmp.viridian);err != nil { +return fmt.Errorf("converting field Viridian: %v", err) +} +if err := x.ViridianEnable.fromC(&tmp.viridian_enable);err != nil { +return fmt.Errorf("converting field ViridianEnable: %v", err) +} +if err := x.ViridianDisable.fromC(&tmp.viridian_disable);err != nil { +return fmt.Errorf("converting field ViridianDisable: %v", err) +} +x.Timeoffset = C.GoString(tmp.timeoffset) +if err := x.Hpet.fromC(&tmp.hpet);err != nil { +return fmt.Errorf("converting field Hpet: %v", err) +} +if err := x.VptAlign.fromC(&tmp.vpt_align);err != nil { +return fmt.Errorf("converting field VptAlign: %v", err) +} +x.MmioHoleMemkb = uint64(tmp.mmio_hole_memkb) +x.TimerMode = TimerMode(tmp.timer_mode) +if err := x.NestedHvm.fromC(&tmp.nested_hvm);err != nil { +return fmt.Errorf("converting field NestedHvm: %v", err) +} +if err := x.Altp2M.fromC(&tmp.altp2m);err != nil { +return fmt.Errorf("converting field Altp2M: %v", err) +} +x.SystemFirmware = C.GoString(tmp.system_firmware) +x.SmbiosFirmware = C.GoString(tmp.smbios_firmware) +x.AcpiFirmware = C.GoString(tmp.acpi_firmware) +x.Hdtype = Hdtype(tmp.hdtype) +if err := x.Nographic.fromC(&tmp.nographic);err != nil { +return fmt.Errorf("converting field Nographic: %v", err) +} +if err := x.Vga.fromC(&tmp.vga);err != nil { +return fmt.Errorf("converting field Vga: %v", err) +} +if err := x.Vnc.fromC(&tmp.vnc);err != nil { +return fmt.Errorf("converting field Vnc: %v", err) +} +x.Keymap = C.GoString(tmp.keymap) +if err := x.Sdl.fromC(&tmp.sdl);err != nil { +return fmt.Errorf("converting field Sdl: %v", err) +} +if err := x.Spice.fromC(&tmp.spice);err != nil { +return fmt.Errorf("converting field Spice: %v", err) +} +if err := x.GfxPassthru.fromC(&tmp.gfx_passthru);err != nil { +return fmt.Errorf("converting field GfxPassthru: %v", err) +} +x.GfxPassthruKind = GfxPassthruKind(tmp.gfx_passthru_kind) +x.Serial = C.GoString(tmp.serial) +x.Boot = C.GoString(tmp.boot) +if err := x.Usb.fromC(&tmp.usb);err != nil { +return fmt.Errorf("converting field Usb: %v", err) +} +x.Usbversion = int(tmp.usbversion) +x.Usbdevice = C.GoString(tmp.usbdevice) +if err := x.VkbDevice.fromC(&tmp.vkb_device);err != nil { +return fmt.Errorf("converting field VkbDevice: %v", err) +} +x.Soundhw = C.GoString(tmp.soundhw) +if err := x.XenPlatformPci.fromC(&tmp.xen_platform_pci);err != nil { +return fmt.Errorf("converting field XenPlatformPci: %v", err) +} +if err := x.UsbdeviceList.fromC(&tmp.usbdevice_list);err != nil { +return fmt.Errorf("converting field UsbdeviceList: %v", err) +} +x.VendorDevice = VendorDevice(tmp.vendor_device) +if err := x.MsVmGenid.fromC(&tmp.ms_vm_genid);err != nil { +return fmt.Errorf("converting field MsVmGenid: %v", err) +} +if err := x.SerialList.fromC(&tmp.serial_list);err != nil { +return fmt.Errorf("converting field SerialList: %v", err) +} +if err := x.Rdm.fromC(&tmp.rdm);err != nil { +return fmt.Errorf("converting field Rdm: %v", err) +} +x.RdmMemBoundaryMemkb = uint64(tmp.rdm_mem_boundary_memkb) +x.McaCaps = uint64(tmp.mca_caps) +return nil } func (x *DomainBuildInfoTypeUnionPv) fromC(xc *C.libxl_domain_build_info) error { - if DomainType(xc._type) != DomainTypePv { - return errors.New("expected union key DomainTypePv") - } - - tmp := (*C.libxl_domain_build_info_type_union_pv)(unsafe.Pointer(&xc.u[0])) - x.Kernel = C.GoString(tmp.kernel) - x.SlackMemkb = uint64(tmp.slack_memkb) - x.Bootloader = C.GoString(tmp.bootloader) - if err := x.BootloaderArgs.fromC(&tmp.bootloader_args); err != nil { - return fmt.Errorf("converting field BootloaderArgs: %v", err) - } - x.Cmdline = C.GoString(tmp.cmdline) - x.Ramdisk = C.GoString(tmp.ramdisk) - x.Features = C.GoString(tmp.features) - if err := x.E820Host.fromC(&tmp.e820_host); err != nil { - return fmt.Errorf("converting field E820Host: %v", err) - } - return nil +if DomainType(xc._type) != DomainTypePv { +return errors.New("expected union key DomainTypePv") +} + +tmp := (*C.libxl_domain_build_info_type_union_pv)(unsafe.Pointer(&xc.u[0])) +x.Kernel = C.GoString(tmp.kernel) +x.SlackMemkb = uint64(tmp.slack_memkb) +x.Bootloader = C.GoString(tmp.bootloader) +if err := x.BootloaderArgs.fromC(&tmp.bootloader_args);err != nil { +return fmt.Errorf("converting field BootloaderArgs: %v", err) +} +x.Cmdline = C.GoString(tmp.cmdline) +x.Ramdisk = C.GoString(tmp.ramdisk) +x.Features = C.GoString(tmp.features) +if err := x.E820Host.fromC(&tmp.e820_host);err != nil { +return fmt.Errorf("converting field E820Host: %v", err) +} +return nil } func (x *DomainBuildInfoTypeUnionPvh) fromC(xc *C.libxl_domain_build_info) error { - if DomainType(xc._type) != DomainTypePvh { - return errors.New("expected union key DomainTypePvh") - } - - tmp := (*C.libxl_domain_build_info_type_union_pvh)(unsafe.Pointer(&xc.u[0])) - if err := x.Pvshim.fromC(&tmp.pvshim); err != nil { - return fmt.Errorf("converting field Pvshim: %v", err) - } - x.PvshimPath = C.GoString(tmp.pvshim_path) - x.PvshimCmdline = C.GoString(tmp.pvshim_cmdline) - x.PvshimExtra = C.GoString(tmp.pvshim_extra) - return nil -} - -func (x *DomainBuildInfo) toC(xc *C.libxl_domain_build_info) (err error) { - defer func() { - if err != nil { - C.libxl_domain_build_info_dispose(xc) - } - }() - - xc.max_vcpus = C.int(x.MaxVcpus) - if err := x.AvailVcpus.toC(&xc.avail_vcpus); err != nil { - return fmt.Errorf("converting field AvailVcpus: %v", err) - } - if err := x.Cpumap.toC(&xc.cpumap); err != nil { - return fmt.Errorf("converting field Cpumap: %v", err) - } - if err := x.Nodemap.toC(&xc.nodemap); err != nil { - return fmt.Errorf("converting field Nodemap: %v", err) - } - if numVcpuHardAffinity := len(x.VcpuHardAffinity); numVcpuHardAffinity > 0 { - xc.vcpu_hard_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuHardAffinity) * C.sizeof_libxl_bitmap)) - xc.num_vcpu_hard_affinity = C.int(numVcpuHardAffinity) - cVcpuHardAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:numVcpuHardAffinity:numVcpuHardAffinity] - for i, v := range x.VcpuHardAffinity { - if err := v.toC(&cVcpuHardAffinity[i]); err != nil { - return fmt.Errorf("converting field VcpuHardAffinity: %v", err) - } - } - } - if numVcpuSoftAffinity := len(x.VcpuSoftAffinity); numVcpuSoftAffinity > 0 { - xc.vcpu_soft_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuSoftAffinity) * C.sizeof_libxl_bitmap)) - xc.num_vcpu_soft_affinity = C.int(numVcpuSoftAffinity) - cVcpuSoftAffinity := (*[1 << 28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:numVcpuSoftAffinity:numVcpuSoftAffinity] - for i, v := range x.VcpuSoftAffinity { - if err := v.toC(&cVcpuSoftAffinity[i]); err != nil { - return fmt.Errorf("converting field VcpuSoftAffinity: %v", err) - } - } - } - if err := x.NumaPlacement.toC(&xc.numa_placement); err != nil { - return fmt.Errorf("converting field NumaPlacement: %v", err) - } - xc.tsc_mode = C.libxl_tsc_mode(x.TscMode) - xc.max_memkb = C.uint64_t(x.MaxMemkb) - xc.target_memkb = C.uint64_t(x.TargetMemkb) - xc.video_memkb = C.uint64_t(x.VideoMemkb) - xc.shadow_memkb = C.uint64_t(x.ShadowMemkb) - xc.iommu_memkb = C.uint64_t(x.IommuMemkb) - xc.rtc_timeoffset = C.uint32_t(x.RtcTimeoffset) - xc.exec_ssidref = C.uint32_t(x.ExecSsidref) - if x.ExecSsidLabel != "" { - xc.exec_ssid_label = C.CString(x.ExecSsidLabel) - } - if err := x.Localtime.toC(&xc.localtime); err != nil { - return fmt.Errorf("converting field Localtime: %v", err) - } - if err := x.DisableMigrate.toC(&xc.disable_migrate); err != nil { - return fmt.Errorf("converting field DisableMigrate: %v", err) - } - if err := x.Cpuid.toC(&xc.cpuid); err != nil { - return fmt.Errorf("converting field Cpuid: %v", err) - } - if x.BlkdevStart != "" { - xc.blkdev_start = C.CString(x.BlkdevStart) - } - if numVnumaNodes := len(x.VnumaNodes); numVnumaNodes > 0 { - xc.vnuma_nodes = (*C.libxl_vnode_info)(C.malloc(C.ulong(numVnumaNodes) * C.sizeof_libxl_vnode_info)) - xc.num_vnuma_nodes = C.int(numVnumaNodes) - cVnumaNodes := (*[1 << 28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:numVnumaNodes:numVnumaNodes] - for i, v := range x.VnumaNodes { - if err := v.toC(&cVnumaNodes[i]); err != nil { - return fmt.Errorf("converting field VnumaNodes: %v", err) - } - } - } - xc.max_grant_frames = C.uint32_t(x.MaxGrantFrames) - xc.max_maptrack_frames = C.uint32_t(x.MaxMaptrackFrames) - xc.device_model_version = C.libxl_device_model_version(x.DeviceModelVersion) - if err := x.DeviceModelStubdomain.toC(&xc.device_model_stubdomain); err != nil { - return fmt.Errorf("converting field DeviceModelStubdomain: %v", err) - } - xc.stubdomain_memkb = C.uint64_t(x.StubdomainMemkb) - if x.StubdomainKernel != "" { - xc.stubdomain_kernel = C.CString(x.StubdomainKernel) - } - if x.StubdomainRamdisk != "" { - xc.stubdomain_ramdisk = C.CString(x.StubdomainRamdisk) - } - if x.DeviceModel != "" { - xc.device_model = C.CString(x.DeviceModel) - } - xc.device_model_ssidref = C.uint32_t(x.DeviceModelSsidref) - if x.DeviceModelSsidLabel != "" { - xc.device_model_ssid_label = C.CString(x.DeviceModelSsidLabel) - } - if x.DeviceModelUser != "" { - xc.device_model_user = C.CString(x.DeviceModelUser) - } - if err := x.Extra.toC(&xc.extra); err != nil { - return fmt.Errorf("converting field Extra: %v", err) - } - if err := x.ExtraPv.toC(&xc.extra_pv); err != nil { - return fmt.Errorf("converting field ExtraPv: %v", err) - } - if err := x.ExtraHvm.toC(&xc.extra_hvm); err != nil { - return fmt.Errorf("converting field ExtraHvm: %v", err) - } - if err := x.SchedParams.toC(&xc.sched_params); err != nil { - return fmt.Errorf("converting field SchedParams: %v", err) - } - if numIoports := len(x.Ioports); numIoports > 0 { - xc.ioports = (*C.libxl_ioport_range)(C.malloc(C.ulong(numIoports) * C.sizeof_libxl_ioport_range)) - xc.num_ioports = C.int(numIoports) - cIoports := (*[1 << 28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:numIoports:numIoports] - for i, v := range x.Ioports { - if err := v.toC(&cIoports[i]); err != nil { - return fmt.Errorf("converting field Ioports: %v", err) - } - } - } - if numIrqs := len(x.Irqs); numIrqs > 0 { - xc.irqs = (*C.uint32_t)(C.malloc(C.size_t(numIrqs * numIrqs))) - xc.num_irqs = C.int(numIrqs) - cIrqs := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:numIrqs:numIrqs] - for i, v := range x.Irqs { - cIrqs[i] = C.uint32_t(v) - } - } - if numIomem := len(x.Iomem); numIomem > 0 { - xc.iomem = (*C.libxl_iomem_range)(C.malloc(C.ulong(numIomem) * C.sizeof_libxl_iomem_range)) - xc.num_iomem = C.int(numIomem) - cIomem := (*[1 << 28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:numIomem:numIomem] - for i, v := range x.Iomem { - if err := v.toC(&cIomem[i]); err != nil { - return fmt.Errorf("converting field Iomem: %v", err) - } - } - } - if err := x.ClaimMode.toC(&xc.claim_mode); err != nil { - return fmt.Errorf("converting field ClaimMode: %v", err) - } - xc.event_channels = C.uint32_t(x.EventChannels) - if x.Kernel != "" { - xc.kernel = C.CString(x.Kernel) - } - if x.Cmdline != "" { - xc.cmdline = C.CString(x.Cmdline) - } - if x.Ramdisk != "" { - xc.ramdisk = C.CString(x.Ramdisk) - } - if x.DeviceTree != "" { - xc.device_tree = C.CString(x.DeviceTree) - } - if err := x.Acpi.toC(&xc.acpi); err != nil { - return fmt.Errorf("converting field Acpi: %v", err) - } - if x.Bootloader != "" { - xc.bootloader = C.CString(x.Bootloader) - } - if err := x.BootloaderArgs.toC(&xc.bootloader_args); err != nil { - return fmt.Errorf("converting field BootloaderArgs: %v", err) - } - xc.timer_mode = C.libxl_timer_mode(x.TimerMode) - if err := x.NestedHvm.toC(&xc.nested_hvm); err != nil { - return fmt.Errorf("converting field NestedHvm: %v", err) - } - if err := x.Apic.toC(&xc.apic); err != nil { - return fmt.Errorf("converting field Apic: %v", err) - } - if err := x.DmRestrict.toC(&xc.dm_restrict); err != nil { - return fmt.Errorf("converting field DmRestrict: %v", err) - } - xc.tee = C.libxl_tee_type(x.Tee) - xc._type = C.libxl_domain_type(x.Type) - switch x.Type { - case DomainTypeHvm: - tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionHvm) - if !ok { - return errors.New("wrong type for union key type") - } - var hvm C.libxl_domain_build_info_type_union_hvm - if tmp.Firmware != "" { - hvm.firmware = C.CString(tmp.Firmware) - } - hvm.bios = C.libxl_bios_type(tmp.Bios) - if err := tmp.Pae.toC(&hvm.pae); err != nil { - return fmt.Errorf("converting field Pae: %v", err) - } - if err := tmp.Apic.toC(&hvm.apic); err != nil { - return fmt.Errorf("converting field Apic: %v", err) - } - if err := tmp.Acpi.toC(&hvm.acpi); err != nil { - return fmt.Errorf("converting field Acpi: %v", err) - } - if err := tmp.AcpiS3.toC(&hvm.acpi_s3); err != nil { - return fmt.Errorf("converting field AcpiS3: %v", err) - } - if err := tmp.AcpiS4.toC(&hvm.acpi_s4); err != nil { - return fmt.Errorf("converting field AcpiS4: %v", err) - } - if err := tmp.AcpiLaptopSlate.toC(&hvm.acpi_laptop_slate); err != nil { - return fmt.Errorf("converting field AcpiLaptopSlate: %v", err) - } - if err := tmp.Nx.toC(&hvm.nx); err != nil { - return fmt.Errorf("converting field Nx: %v", err) - } - if err := tmp.Viridian.toC(&hvm.viridian); err != nil { - return fmt.Errorf("converting field Viridian: %v", err) - } - if err := tmp.ViridianEnable.toC(&hvm.viridian_enable); err != nil { - return fmt.Errorf("converting field ViridianEnable: %v", err) - } - if err := tmp.ViridianDisable.toC(&hvm.viridian_disable); err != nil { - return fmt.Errorf("converting field ViridianDisable: %v", err) - } - if tmp.Timeoffset != "" { - hvm.timeoffset = C.CString(tmp.Timeoffset) - } - if err := tmp.Hpet.toC(&hvm.hpet); err != nil { - return fmt.Errorf("converting field Hpet: %v", err) - } - if err := tmp.VptAlign.toC(&hvm.vpt_align); err != nil { - return fmt.Errorf("converting field VptAlign: %v", err) - } - hvm.mmio_hole_memkb = C.uint64_t(tmp.MmioHoleMemkb) - hvm.timer_mode = C.libxl_timer_mode(tmp.TimerMode) - if err := tmp.NestedHvm.toC(&hvm.nested_hvm); err != nil { - return fmt.Errorf("converting field NestedHvm: %v", err) - } - if err := tmp.Altp2M.toC(&hvm.altp2m); err != nil { - return fmt.Errorf("converting field Altp2M: %v", err) - } - if tmp.SystemFirmware != "" { - hvm.system_firmware = C.CString(tmp.SystemFirmware) - } - if tmp.SmbiosFirmware != "" { - hvm.smbios_firmware = C.CString(tmp.SmbiosFirmware) - } - if tmp.AcpiFirmware != "" { - hvm.acpi_firmware = C.CString(tmp.AcpiFirmware) - } - hvm.hdtype = C.libxl_hdtype(tmp.Hdtype) - if err := tmp.Nographic.toC(&hvm.nographic); err != nil { - return fmt.Errorf("converting field Nographic: %v", err) - } - if err := tmp.Vga.toC(&hvm.vga); err != nil { - return fmt.Errorf("converting field Vga: %v", err) - } - if err := tmp.Vnc.toC(&hvm.vnc); err != nil { - return fmt.Errorf("converting field Vnc: %v", err) - } - if tmp.Keymap != "" { - hvm.keymap = C.CString(tmp.Keymap) - } - if err := tmp.Sdl.toC(&hvm.sdl); err != nil { - return fmt.Errorf("converting field Sdl: %v", err) - } - if err := tmp.Spice.toC(&hvm.spice); err != nil { - return fmt.Errorf("converting field Spice: %v", err) - } - if err := tmp.GfxPassthru.toC(&hvm.gfx_passthru); err != nil { - return fmt.Errorf("converting field GfxPassthru: %v", err) - } - hvm.gfx_passthru_kind = C.libxl_gfx_passthru_kind(tmp.GfxPassthruKind) - if tmp.Serial != "" { - hvm.serial = C.CString(tmp.Serial) - } - if tmp.Boot != "" { - hvm.boot = C.CString(tmp.Boot) - } - if err := tmp.Usb.toC(&hvm.usb); err != nil { - return fmt.Errorf("converting field Usb: %v", err) - } - hvm.usbversion = C.int(tmp.Usbversion) - if tmp.Usbdevice != "" { - hvm.usbdevice = C.CString(tmp.Usbdevice) - } - if err := tmp.VkbDevice.toC(&hvm.vkb_device); err != nil { - return fmt.Errorf("converting field VkbDevice: %v", err) - } - if tmp.Soundhw != "" { - hvm.soundhw = C.CString(tmp.Soundhw) - } - if err := tmp.XenPlatformPci.toC(&hvm.xen_platform_pci); err != nil { - return fmt.Errorf("converting field XenPlatformPci: %v", err) - } - if err := tmp.UsbdeviceList.toC(&hvm.usbdevice_list); err != nil { - return fmt.Errorf("converting field UsbdeviceList: %v", err) - } - hvm.vendor_device = C.libxl_vendor_device(tmp.VendorDevice) - if err := tmp.MsVmGenid.toC(&hvm.ms_vm_genid); err != nil { - return fmt.Errorf("converting field MsVmGenid: %v", err) - } - if err := tmp.SerialList.toC(&hvm.serial_list); err != nil { - return fmt.Errorf("converting field SerialList: %v", err) - } - if err := tmp.Rdm.toC(&hvm.rdm); err != nil { - return fmt.Errorf("converting field Rdm: %v", err) - } - hvm.rdm_mem_boundary_memkb = C.uint64_t(tmp.RdmMemBoundaryMemkb) - hvm.mca_caps = C.uint64_t(tmp.McaCaps) - hvmBytes := C.GoBytes(unsafe.Pointer(&hvm), C.sizeof_libxl_domain_build_info_type_union_hvm) - copy(xc.u[:], hvmBytes) - case DomainTypePv: - tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPv) - if !ok { - return errors.New("wrong type for union key type") - } - var pv C.libxl_domain_build_info_type_union_pv - if tmp.Kernel != "" { - pv.kernel = C.CString(tmp.Kernel) - } - pv.slack_memkb = C.uint64_t(tmp.SlackMemkb) - if tmp.Bootloader != "" { - pv.bootloader = C.CString(tmp.Bootloader) - } - if err := tmp.BootloaderArgs.toC(&pv.bootloader_args); err != nil { - return fmt.Errorf("converting field BootloaderArgs: %v", err) - } - if tmp.Cmdline != "" { - pv.cmdline = C.CString(tmp.Cmdline) - } - if tmp.Ramdisk != "" { - pv.ramdisk = C.CString(tmp.Ramdisk) - } - if tmp.Features != "" { - pv.features = C.CString(tmp.Features) - } - if err := tmp.E820Host.toC(&pv.e820_host); err != nil { - return fmt.Errorf("converting field E820Host: %v", err) - } - pvBytes := C.GoBytes(unsafe.Pointer(&pv), C.sizeof_libxl_domain_build_info_type_union_pv) - copy(xc.u[:], pvBytes) - case DomainTypePvh: - tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPvh) - if !ok { - return errors.New("wrong type for union key type") - } - var pvh C.libxl_domain_build_info_type_union_pvh - if err := tmp.Pvshim.toC(&pvh.pvshim); err != nil { - return fmt.Errorf("converting field Pvshim: %v", err) - } - if tmp.PvshimPath != "" { - pvh.pvshim_path = C.CString(tmp.PvshimPath) - } - if tmp.PvshimCmdline != "" { - pvh.pvshim_cmdline = C.CString(tmp.PvshimCmdline) - } - if tmp.PvshimExtra != "" { - pvh.pvshim_extra = C.CString(tmp.PvshimExtra) - } - pvhBytes := C.GoBytes(unsafe.Pointer(&pvh), C.sizeof_libxl_domain_build_info_type_union_pvh) - copy(xc.u[:], pvhBytes) - case DomainTypeInvalid: - break - default: - return fmt.Errorf("invalid union key '%v'", x.Type) - } - xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion) - xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart) - xc.altp2m = C.libxl_altp2m_mode(x.Altp2M) - - return nil +if DomainType(xc._type) != DomainTypePvh { +return errors.New("expected union key DomainTypePvh") +} + +tmp := (*C.libxl_domain_build_info_type_union_pvh)(unsafe.Pointer(&xc.u[0])) +if err := x.Pvshim.fromC(&tmp.pvshim);err != nil { +return fmt.Errorf("converting field Pvshim: %v", err) +} +x.PvshimPath = C.GoString(tmp.pvshim_path) +x.PvshimCmdline = C.GoString(tmp.pvshim_cmdline) +x.PvshimExtra = C.GoString(tmp.pvshim_extra) +return nil +} + +func (x *DomainBuildInfo) toC(xc *C.libxl_domain_build_info) (err error){defer func(){ +if err != nil{ +C.libxl_domain_build_info_dispose(xc)} +}() + +xc.max_vcpus = C.int(x.MaxVcpus) +if err := x.AvailVcpus.toC(&xc.avail_vcpus); err != nil { +return fmt.Errorf("converting field AvailVcpus: %v", err) +} +if err := x.Cpumap.toC(&xc.cpumap); err != nil { +return fmt.Errorf("converting field Cpumap: %v", err) +} +if err := x.Nodemap.toC(&xc.nodemap); err != nil { +return fmt.Errorf("converting field Nodemap: %v", err) +} +if numVcpuHardAffinity := len(x.VcpuHardAffinity); numVcpuHardAffinity > 0 { +xc.vcpu_hard_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuHardAffinity)*C.sizeof_libxl_bitmap)) +xc.num_vcpu_hard_affinity = C.int(numVcpuHardAffinity) +cVcpuHardAffinity := (*[1<<28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_hard_affinity))[:numVcpuHardAffinity:numVcpuHardAffinity] +for i,v := range x.VcpuHardAffinity { +if err := v.toC(&cVcpuHardAffinity[i]); err != nil { +return fmt.Errorf("converting field VcpuHardAffinity: %v", err) +} +} +} +if numVcpuSoftAffinity := len(x.VcpuSoftAffinity); numVcpuSoftAffinity > 0 { +xc.vcpu_soft_affinity = (*C.libxl_bitmap)(C.malloc(C.ulong(numVcpuSoftAffinity)*C.sizeof_libxl_bitmap)) +xc.num_vcpu_soft_affinity = C.int(numVcpuSoftAffinity) +cVcpuSoftAffinity := (*[1<<28]C.libxl_bitmap)(unsafe.Pointer(xc.vcpu_soft_affinity))[:numVcpuSoftAffinity:numVcpuSoftAffinity] +for i,v := range x.VcpuSoftAffinity { +if err := v.toC(&cVcpuSoftAffinity[i]); err != nil { +return fmt.Errorf("converting field VcpuSoftAffinity: %v", err) } +} +} +if err := x.NumaPlacement.toC(&xc.numa_placement); err != nil { +return fmt.Errorf("converting field NumaPlacement: %v", err) +} +xc.tsc_mode = C.libxl_tsc_mode(x.TscMode) +xc.max_memkb = C.uint64_t(x.MaxMemkb) +xc.target_memkb = C.uint64_t(x.TargetMemkb) +xc.video_memkb = C.uint64_t(x.VideoMemkb) +xc.shadow_memkb = C.uint64_t(x.ShadowMemkb) +xc.iommu_memkb = C.uint64_t(x.IommuMemkb) +xc.rtc_timeoffset = C.uint32_t(x.RtcTimeoffset) +xc.exec_ssidref = C.uint32_t(x.ExecSsidref) +if x.ExecSsidLabel != "" { +xc.exec_ssid_label = C.CString(x.ExecSsidLabel)} +if err := x.Localtime.toC(&xc.localtime); err != nil { +return fmt.Errorf("converting field Localtime: %v", err) +} +if err := x.DisableMigrate.toC(&xc.disable_migrate); err != nil { +return fmt.Errorf("converting field DisableMigrate: %v", err) +} +if err := x.Cpuid.toC(&xc.cpuid); err != nil { +return fmt.Errorf("converting field Cpuid: %v", err) +} +if x.BlkdevStart != "" { +xc.blkdev_start = C.CString(x.BlkdevStart)} +if numVnumaNodes := len(x.VnumaNodes); numVnumaNodes > 0 { +xc.vnuma_nodes = (*C.libxl_vnode_info)(C.malloc(C.ulong(numVnumaNodes)*C.sizeof_libxl_vnode_info)) +xc.num_vnuma_nodes = C.int(numVnumaNodes) +cVnumaNodes := (*[1<<28]C.libxl_vnode_info)(unsafe.Pointer(xc.vnuma_nodes))[:numVnumaNodes:numVnumaNodes] +for i,v := range x.VnumaNodes { +if err := v.toC(&cVnumaNodes[i]); err != nil { +return fmt.Errorf("converting field VnumaNodes: %v", err) +} +} +} +xc.max_grant_frames = C.uint32_t(x.MaxGrantFrames) +xc.max_maptrack_frames = C.uint32_t(x.MaxMaptrackFrames) +xc.device_model_version = C.libxl_device_model_version(x.DeviceModelVersion) +if err := x.DeviceModelStubdomain.toC(&xc.device_model_stubdomain); err != nil { +return fmt.Errorf("converting field DeviceModelStubdomain: %v", err) +} +xc.stubdomain_memkb = C.uint64_t(x.StubdomainMemkb) +if x.StubdomainKernel != "" { +xc.stubdomain_kernel = C.CString(x.StubdomainKernel)} +if x.StubdomainRamdisk != "" { +xc.stubdomain_ramdisk = C.CString(x.StubdomainRamdisk)} +if x.DeviceModel != "" { +xc.device_model = C.CString(x.DeviceModel)} +xc.device_model_ssidref = C.uint32_t(x.DeviceModelSsidref) +if x.DeviceModelSsidLabel != "" { +xc.device_model_ssid_label = C.CString(x.DeviceModelSsidLabel)} +if x.DeviceModelUser != "" { +xc.device_model_user = C.CString(x.DeviceModelUser)} +if err := x.Extra.toC(&xc.extra); err != nil { +return fmt.Errorf("converting field Extra: %v", err) +} +if err := x.ExtraPv.toC(&xc.extra_pv); err != nil { +return fmt.Errorf("converting field ExtraPv: %v", err) +} +if err := x.ExtraHvm.toC(&xc.extra_hvm); err != nil { +return fmt.Errorf("converting field ExtraHvm: %v", err) +} +if err := x.SchedParams.toC(&xc.sched_params); err != nil { +return fmt.Errorf("converting field SchedParams: %v", err) +} +if numIoports := len(x.Ioports); numIoports > 0 { +xc.ioports = (*C.libxl_ioport_range)(C.malloc(C.ulong(numIoports)*C.sizeof_libxl_ioport_range)) +xc.num_ioports = C.int(numIoports) +cIoports := (*[1<<28]C.libxl_ioport_range)(unsafe.Pointer(xc.ioports))[:numIoports:numIoports] +for i,v := range x.Ioports { +if err := v.toC(&cIoports[i]); err != nil { +return fmt.Errorf("converting field Ioports: %v", err) +} +} +} +if numIrqs := len(x.Irqs); numIrqs > 0 { +xc.irqs = (*C.uint32_t)(C.malloc(C.size_t(numIrqs*numIrqs))) +xc.num_irqs = C.int(numIrqs) +cIrqs := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.irqs))[:numIrqs:numIrqs] +for i,v := range x.Irqs { +cIrqs[i] = C.uint32_t(v) +} +} +if numIomem := len(x.Iomem); numIomem > 0 { +xc.iomem = (*C.libxl_iomem_range)(C.malloc(C.ulong(numIomem)*C.sizeof_libxl_iomem_range)) +xc.num_iomem = C.int(numIomem) +cIomem := (*[1<<28]C.libxl_iomem_range)(unsafe.Pointer(xc.iomem))[:numIomem:numIomem] +for i,v := range x.Iomem { +if err := v.toC(&cIomem[i]); err != nil { +return fmt.Errorf("converting field Iomem: %v", err) +} +} +} +if err := x.ClaimMode.toC(&xc.claim_mode); err != nil { +return fmt.Errorf("converting field ClaimMode: %v", err) +} +xc.event_channels = C.uint32_t(x.EventChannels) +if x.Kernel != "" { +xc.kernel = C.CString(x.Kernel)} +if x.Cmdline != "" { +xc.cmdline = C.CString(x.Cmdline)} +if x.Ramdisk != "" { +xc.ramdisk = C.CString(x.Ramdisk)} +if x.DeviceTree != "" { +xc.device_tree = C.CString(x.DeviceTree)} +if err := x.Acpi.toC(&xc.acpi); err != nil { +return fmt.Errorf("converting field Acpi: %v", err) +} +if x.Bootloader != "" { +xc.bootloader = C.CString(x.Bootloader)} +if err := x.BootloaderArgs.toC(&xc.bootloader_args); err != nil { +return fmt.Errorf("converting field BootloaderArgs: %v", err) +} +xc.timer_mode = C.libxl_timer_mode(x.TimerMode) +if err := x.NestedHvm.toC(&xc.nested_hvm); err != nil { +return fmt.Errorf("converting field NestedHvm: %v", err) +} +if err := x.Apic.toC(&xc.apic); err != nil { +return fmt.Errorf("converting field Apic: %v", err) +} +if err := x.DmRestrict.toC(&xc.dm_restrict); err != nil { +return fmt.Errorf("converting field DmRestrict: %v", err) +} +xc.tee = C.libxl_tee_type(x.Tee) +xc._type = C.libxl_domain_type(x.Type) +switch x.Type{ +case DomainTypeHvm: +tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionHvm) +if !ok { +return errors.New("wrong type for union key type") +} +var hvm C.libxl_domain_build_info_type_union_hvm +if tmp.Firmware != "" { +hvm.firmware = C.CString(tmp.Firmware)} +hvm.bios = C.libxl_bios_type(tmp.Bios) +if err := tmp.Pae.toC(&hvm.pae); err != nil { +return fmt.Errorf("converting field Pae: %v", err) +} +if err := tmp.Apic.toC(&hvm.apic); err != nil { +return fmt.Errorf("converting field Apic: %v", err) +} +if err := tmp.Acpi.toC(&hvm.acpi); err != nil { +return fmt.Errorf("converting field Acpi: %v", err) +} +if err := tmp.AcpiS3.toC(&hvm.acpi_s3); err != nil { +return fmt.Errorf("converting field AcpiS3: %v", err) +} +if err := tmp.AcpiS4.toC(&hvm.acpi_s4); err != nil { +return fmt.Errorf("converting field AcpiS4: %v", err) +} +if err := tmp.AcpiLaptopSlate.toC(&hvm.acpi_laptop_slate); err != nil { +return fmt.Errorf("converting field AcpiLaptopSlate: %v", err) +} +if err := tmp.Nx.toC(&hvm.nx); err != nil { +return fmt.Errorf("converting field Nx: %v", err) +} +if err := tmp.Viridian.toC(&hvm.viridian); err != nil { +return fmt.Errorf("converting field Viridian: %v", err) +} +if err := tmp.ViridianEnable.toC(&hvm.viridian_enable); err != nil { +return fmt.Errorf("converting field ViridianEnable: %v", err) +} +if err := tmp.ViridianDisable.toC(&hvm.viridian_disable); err != nil { +return fmt.Errorf("converting field ViridianDisable: %v", err) +} +if tmp.Timeoffset != "" { +hvm.timeoffset = C.CString(tmp.Timeoffset)} +if err := tmp.Hpet.toC(&hvm.hpet); err != nil { +return fmt.Errorf("converting field Hpet: %v", err) +} +if err := tmp.VptAlign.toC(&hvm.vpt_align); err != nil { +return fmt.Errorf("converting field VptAlign: %v", err) +} +hvm.mmio_hole_memkb = C.uint64_t(tmp.MmioHoleMemkb) +hvm.timer_mode = C.libxl_timer_mode(tmp.TimerMode) +if err := tmp.NestedHvm.toC(&hvm.nested_hvm); err != nil { +return fmt.Errorf("converting field NestedHvm: %v", err) +} +if err := tmp.Altp2M.toC(&hvm.altp2m); err != nil { +return fmt.Errorf("converting field Altp2M: %v", err) +} +if tmp.SystemFirmware != "" { +hvm.system_firmware = C.CString(tmp.SystemFirmware)} +if tmp.SmbiosFirmware != "" { +hvm.smbios_firmware = C.CString(tmp.SmbiosFirmware)} +if tmp.AcpiFirmware != "" { +hvm.acpi_firmware = C.CString(tmp.AcpiFirmware)} +hvm.hdtype = C.libxl_hdtype(tmp.Hdtype) +if err := tmp.Nographic.toC(&hvm.nographic); err != nil { +return fmt.Errorf("converting field Nographic: %v", err) +} +if err := tmp.Vga.toC(&hvm.vga); err != nil { +return fmt.Errorf("converting field Vga: %v", err) +} +if err := tmp.Vnc.toC(&hvm.vnc); err != nil { +return fmt.Errorf("converting field Vnc: %v", err) +} +if tmp.Keymap != "" { +hvm.keymap = C.CString(tmp.Keymap)} +if err := tmp.Sdl.toC(&hvm.sdl); err != nil { +return fmt.Errorf("converting field Sdl: %v", err) +} +if err := tmp.Spice.toC(&hvm.spice); err != nil { +return fmt.Errorf("converting field Spice: %v", err) +} +if err := tmp.GfxPassthru.toC(&hvm.gfx_passthru); err != nil { +return fmt.Errorf("converting field GfxPassthru: %v", err) +} +hvm.gfx_passthru_kind = C.libxl_gfx_passthru_kind(tmp.GfxPassthruKind) +if tmp.Serial != "" { +hvm.serial = C.CString(tmp.Serial)} +if tmp.Boot != "" { +hvm.boot = C.CString(tmp.Boot)} +if err := tmp.Usb.toC(&hvm.usb); err != nil { +return fmt.Errorf("converting field Usb: %v", err) +} +hvm.usbversion = C.int(tmp.Usbversion) +if tmp.Usbdevice != "" { +hvm.usbdevice = C.CString(tmp.Usbdevice)} +if err := tmp.VkbDevice.toC(&hvm.vkb_device); err != nil { +return fmt.Errorf("converting field VkbDevice: %v", err) +} +if tmp.Soundhw != "" { +hvm.soundhw = C.CString(tmp.Soundhw)} +if err := tmp.XenPlatformPci.toC(&hvm.xen_platform_pci); err != nil { +return fmt.Errorf("converting field XenPlatformPci: %v", err) +} +if err := tmp.UsbdeviceList.toC(&hvm.usbdevice_list); err != nil { +return fmt.Errorf("converting field UsbdeviceList: %v", err) +} +hvm.vendor_device = C.libxl_vendor_device(tmp.VendorDevice) +if err := tmp.MsVmGenid.toC(&hvm.ms_vm_genid); err != nil { +return fmt.Errorf("converting field MsVmGenid: %v", err) +} +if err := tmp.SerialList.toC(&hvm.serial_list); err != nil { +return fmt.Errorf("converting field SerialList: %v", err) +} +if err := tmp.Rdm.toC(&hvm.rdm); err != nil { +return fmt.Errorf("converting field Rdm: %v", err) +} +hvm.rdm_mem_boundary_memkb = C.uint64_t(tmp.RdmMemBoundaryMemkb) +hvm.mca_caps = C.uint64_t(tmp.McaCaps) +hvmBytes := C.GoBytes(unsafe.Pointer(&hvm),C.sizeof_libxl_domain_build_info_type_union_hvm) +copy(xc.u[:],hvmBytes) +case DomainTypePv: +tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPv) +if !ok { +return errors.New("wrong type for union key type") +} +var pv C.libxl_domain_build_info_type_union_pv +if tmp.Kernel != "" { +pv.kernel = C.CString(tmp.Kernel)} +pv.slack_memkb = C.uint64_t(tmp.SlackMemkb) +if tmp.Bootloader != "" { +pv.bootloader = C.CString(tmp.Bootloader)} +if err := tmp.BootloaderArgs.toC(&pv.bootloader_args); err != nil { +return fmt.Errorf("converting field BootloaderArgs: %v", err) +} +if tmp.Cmdline != "" { +pv.cmdline = C.CString(tmp.Cmdline)} +if tmp.Ramdisk != "" { +pv.ramdisk = C.CString(tmp.Ramdisk)} +if tmp.Features != "" { +pv.features = C.CString(tmp.Features)} +if err := tmp.E820Host.toC(&pv.e820_host); err != nil { +return fmt.Errorf("converting field E820Host: %v", err) +} +pvBytes := C.GoBytes(unsafe.Pointer(&pv),C.sizeof_libxl_domain_build_info_type_union_pv) +copy(xc.u[:],pvBytes) +case DomainTypePvh: +tmp, ok := x.TypeUnion.(DomainBuildInfoTypeUnionPvh) +if !ok { +return errors.New("wrong type for union key type") +} +var pvh C.libxl_domain_build_info_type_union_pvh +if err := tmp.Pvshim.toC(&pvh.pvshim); err != nil { +return fmt.Errorf("converting field Pvshim: %v", err) +} +if tmp.PvshimPath != "" { +pvh.pvshim_path = C.CString(tmp.PvshimPath)} +if tmp.PvshimCmdline != "" { +pvh.pvshim_cmdline = C.CString(tmp.PvshimCmdline)} +if tmp.PvshimExtra != "" { +pvh.pvshim_extra = C.CString(tmp.PvshimExtra)} +pvhBytes := C.GoBytes(unsafe.Pointer(&pvh),C.sizeof_libxl_domain_build_info_type_union_pvh) +copy(xc.u[:],pvhBytes) +case DomainTypeInvalid: +break +default: +return fmt.Errorf("invalid union key '%v'", x.Type)} +xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion) +xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart) +xc.altp2m = C.libxl_altp2m_mode(x.Altp2M) + + return nil + } // NewDeviceVfb returns an instance of DeviceVfb initialized with defaults. func NewDeviceVfb() (*DeviceVfb, error) { - var ( - x DeviceVfb - xc C.libxl_device_vfb - ) +var ( +x DeviceVfb +xc C.libxl_device_vfb) - C.libxl_device_vfb_init(&xc) - defer C.libxl_device_vfb_dispose(&xc) +C.libxl_device_vfb_init(&xc) +defer C.libxl_device_vfb_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceVfb) fromC(xc *C.libxl_device_vfb) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.Devid = Devid(xc.devid) - if err := x.Vnc.fromC(&xc.vnc); err != nil { - return fmt.Errorf("converting field Vnc: %v", err) - } - if err := x.Sdl.fromC(&xc.sdl); err != nil { - return fmt.Errorf("converting field Sdl: %v", err) - } - x.Keymap = C.GoString(xc.keymap) - - return nil -} - -func (x *DeviceVfb) toC(xc *C.libxl_device_vfb) (err error) { - defer func() { - if err != nil { - C.libxl_device_vfb_dispose(xc) - } - }() - - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - xc.devid = C.libxl_devid(x.Devid) - if err := x.Vnc.toC(&xc.vnc); err != nil { - return fmt.Errorf("converting field Vnc: %v", err) - } - if err := x.Sdl.toC(&xc.sdl); err != nil { - return fmt.Errorf("converting field Sdl: %v", err) - } - if x.Keymap != "" { - xc.keymap = C.CString(x.Keymap) - } - - return nil + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.Devid = Devid(xc.devid) +if err := x.Vnc.fromC(&xc.vnc);err != nil { +return fmt.Errorf("converting field Vnc: %v", err) +} +if err := x.Sdl.fromC(&xc.sdl);err != nil { +return fmt.Errorf("converting field Sdl: %v", err) +} +x.Keymap = C.GoString(xc.keymap) + + return nil} + +func (x *DeviceVfb) toC(xc *C.libxl_device_vfb) (err error){defer func(){ +if err != nil{ +C.libxl_device_vfb_dispose(xc)} +}() + +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +xc.devid = C.libxl_devid(x.Devid) +if err := x.Vnc.toC(&xc.vnc); err != nil { +return fmt.Errorf("converting field Vnc: %v", err) +} +if err := x.Sdl.toC(&xc.sdl); err != nil { +return fmt.Errorf("converting field Sdl: %v", err) } +if x.Keymap != "" { +xc.keymap = C.CString(x.Keymap)} + + return nil + } // NewDeviceVkb returns an instance of DeviceVkb initialized with defaults. func NewDeviceVkb() (*DeviceVkb, error) { - var ( - x DeviceVkb - xc C.libxl_device_vkb - ) +var ( +x DeviceVkb +xc C.libxl_device_vkb) - C.libxl_device_vkb_init(&xc) - defer C.libxl_device_vkb_dispose(&xc) +C.libxl_device_vkb_init(&xc) +defer C.libxl_device_vkb_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceVkb) fromC(xc *C.libxl_device_vkb) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.Devid = Devid(xc.devid) - x.BackendType = VkbBackend(xc.backend_type) - x.UniqueId = C.GoString(xc.unique_id) - x.FeatureDisableKeyboard = bool(xc.feature_disable_keyboard) - x.FeatureDisablePointer = bool(xc.feature_disable_pointer) - x.FeatureAbsPointer = bool(xc.feature_abs_pointer) - x.FeatureRawPointer = bool(xc.feature_raw_pointer) - x.FeatureMultiTouch = bool(xc.feature_multi_touch) - x.Width = uint32(xc.width) - x.Height = uint32(xc.height) - x.MultiTouchWidth = uint32(xc.multi_touch_width) - x.MultiTouchHeight = uint32(xc.multi_touch_height) - x.MultiTouchNumContacts = uint32(xc.multi_touch_num_contacts) - - return nil -} - -func (x *DeviceVkb) toC(xc *C.libxl_device_vkb) (err error) { - defer func() { - if err != nil { - C.libxl_device_vkb_dispose(xc) - } - }() - - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - xc.devid = C.libxl_devid(x.Devid) - xc.backend_type = C.libxl_vkb_backend(x.BackendType) - if x.UniqueId != "" { - xc.unique_id = C.CString(x.UniqueId) - } - xc.feature_disable_keyboard = C.bool(x.FeatureDisableKeyboard) - xc.feature_disable_pointer = C.bool(x.FeatureDisablePointer) - xc.feature_abs_pointer = C.bool(x.FeatureAbsPointer) - xc.feature_raw_pointer = C.bool(x.FeatureRawPointer) - xc.feature_multi_touch = C.bool(x.FeatureMultiTouch) - xc.width = C.uint32_t(x.Width) - xc.height = C.uint32_t(x.Height) - xc.multi_touch_width = C.uint32_t(x.MultiTouchWidth) - xc.multi_touch_height = C.uint32_t(x.MultiTouchHeight) - xc.multi_touch_num_contacts = C.uint32_t(x.MultiTouchNumContacts) - - return nil -} + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.Devid = Devid(xc.devid) +x.BackendType = VkbBackend(xc.backend_type) +x.UniqueId = C.GoString(xc.unique_id) +x.FeatureDisableKeyboard = bool(xc.feature_disable_keyboard) +x.FeatureDisablePointer = bool(xc.feature_disable_pointer) +x.FeatureAbsPointer = bool(xc.feature_abs_pointer) +x.FeatureRawPointer = bool(xc.feature_raw_pointer) +x.FeatureMultiTouch = bool(xc.feature_multi_touch) +x.Width = uint32(xc.width) +x.Height = uint32(xc.height) +x.MultiTouchWidth = uint32(xc.multi_touch_width) +x.MultiTouchHeight = uint32(xc.multi_touch_height) +x.MultiTouchNumContacts = uint32(xc.multi_touch_num_contacts) + + return nil} + +func (x *DeviceVkb) toC(xc *C.libxl_device_vkb) (err error){defer func(){ +if err != nil{ +C.libxl_device_vkb_dispose(xc)} +}() + +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +xc.devid = C.libxl_devid(x.Devid) +xc.backend_type = C.libxl_vkb_backend(x.BackendType) +if x.UniqueId != "" { +xc.unique_id = C.CString(x.UniqueId)} +xc.feature_disable_keyboard = C.bool(x.FeatureDisableKeyboard) +xc.feature_disable_pointer = C.bool(x.FeatureDisablePointer) +xc.feature_abs_pointer = C.bool(x.FeatureAbsPointer) +xc.feature_raw_pointer = C.bool(x.FeatureRawPointer) +xc.feature_multi_touch = C.bool(x.FeatureMultiTouch) +xc.width = C.uint32_t(x.Width) +xc.height = C.uint32_t(x.Height) +xc.multi_touch_width = C.uint32_t(x.MultiTouchWidth) +xc.multi_touch_height = C.uint32_t(x.MultiTouchHeight) +xc.multi_touch_num_contacts = C.uint32_t(x.MultiTouchNumContacts) + + return nil + } // NewDeviceDisk returns an instance of DeviceDisk initialized with defaults. func NewDeviceDisk() (*DeviceDisk, error) { - var ( - x DeviceDisk - xc C.libxl_device_disk - ) +var ( +x DeviceDisk +xc C.libxl_device_disk) - C.libxl_device_disk_init(&xc) - defer C.libxl_device_disk_dispose(&xc) +C.libxl_device_disk_init(&xc) +defer C.libxl_device_disk_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceDisk) fromC(xc *C.libxl_device_disk) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.PdevPath = C.GoString(xc.pdev_path) - x.Vdev = C.GoString(xc.vdev) - x.Backend = DiskBackend(xc.backend) - x.Format = DiskFormat(xc.format) - x.Script = C.GoString(xc.script) - x.Removable = int(xc.removable) - x.Readwrite = int(xc.readwrite) - x.IsCdrom = int(xc.is_cdrom) - x.DirectIoSafe = bool(xc.direct_io_safe) - if err := x.DiscardEnable.fromC(&xc.discard_enable); err != nil { - return fmt.Errorf("converting field DiscardEnable: %v", err) - } - if err := x.ColoEnable.fromC(&xc.colo_enable); err != nil { - return fmt.Errorf("converting field ColoEnable: %v", err) - } - if err := x.ColoRestoreEnable.fromC(&xc.colo_restore_enable); err != nil { - return fmt.Errorf("converting field ColoRestoreEnable: %v", err) - } - x.ColoHost = C.GoString(xc.colo_host) - x.ColoPort = int(xc.colo_port) - x.ColoExport = C.GoString(xc.colo_export) - x.ActiveDisk = C.GoString(xc.active_disk) - x.HiddenDisk = C.GoString(xc.hidden_disk) - - return nil -} - -func (x *DeviceDisk) toC(xc *C.libxl_device_disk) (err error) { - defer func() { - if err != nil { - C.libxl_device_disk_dispose(xc) - } - }() - - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - if x.PdevPath != "" { - xc.pdev_path = C.CString(x.PdevPath) - } - if x.Vdev != "" { - xc.vdev = C.CString(x.Vdev) - } - xc.backend = C.libxl_disk_backend(x.Backend) - xc.format = C.libxl_disk_format(x.Format) - if x.Script != "" { - xc.script = C.CString(x.Script) - } - xc.removable = C.int(x.Removable) - xc.readwrite = C.int(x.Readwrite) - xc.is_cdrom = C.int(x.IsCdrom) - xc.direct_io_safe = C.bool(x.DirectIoSafe) - if err := x.DiscardEnable.toC(&xc.discard_enable); err != nil { - return fmt.Errorf("converting field DiscardEnable: %v", err) - } - if err := x.ColoEnable.toC(&xc.colo_enable); err != nil { - return fmt.Errorf("converting field ColoEnable: %v", err) - } - if err := x.ColoRestoreEnable.toC(&xc.colo_restore_enable); err != nil { - return fmt.Errorf("converting field ColoRestoreEnable: %v", err) - } - if x.ColoHost != "" { - xc.colo_host = C.CString(x.ColoHost) - } - xc.colo_port = C.int(x.ColoPort) - if x.ColoExport != "" { - xc.colo_export = C.CString(x.ColoExport) - } - if x.ActiveDisk != "" { - xc.active_disk = C.CString(x.ActiveDisk) - } - if x.HiddenDisk != "" { - xc.hidden_disk = C.CString(x.HiddenDisk) - } - - return nil -} + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.PdevPath = C.GoString(xc.pdev_path) +x.Vdev = C.GoString(xc.vdev) +x.Backend = DiskBackend(xc.backend) +x.Format = DiskFormat(xc.format) +x.Script = C.GoString(xc.script) +x.Removable = int(xc.removable) +x.Readwrite = int(xc.readwrite) +x.IsCdrom = int(xc.is_cdrom) +x.DirectIoSafe = bool(xc.direct_io_safe) +if err := x.DiscardEnable.fromC(&xc.discard_enable);err != nil { +return fmt.Errorf("converting field DiscardEnable: %v", err) +} +if err := x.ColoEnable.fromC(&xc.colo_enable);err != nil { +return fmt.Errorf("converting field ColoEnable: %v", err) +} +if err := x.ColoRestoreEnable.fromC(&xc.colo_restore_enable);err != nil { +return fmt.Errorf("converting field ColoRestoreEnable: %v", err) +} +x.ColoHost = C.GoString(xc.colo_host) +x.ColoPort = int(xc.colo_port) +x.ColoExport = C.GoString(xc.colo_export) +x.ActiveDisk = C.GoString(xc.active_disk) +x.HiddenDisk = C.GoString(xc.hidden_disk) + + return nil} + +func (x *DeviceDisk) toC(xc *C.libxl_device_disk) (err error){defer func(){ +if err != nil{ +C.libxl_device_disk_dispose(xc)} +}() + +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +if x.PdevPath != "" { +xc.pdev_path = C.CString(x.PdevPath)} +if x.Vdev != "" { +xc.vdev = C.CString(x.Vdev)} +xc.backend = C.libxl_disk_backend(x.Backend) +xc.format = C.libxl_disk_format(x.Format) +if x.Script != "" { +xc.script = C.CString(x.Script)} +xc.removable = C.int(x.Removable) +xc.readwrite = C.int(x.Readwrite) +xc.is_cdrom = C.int(x.IsCdrom) +xc.direct_io_safe = C.bool(x.DirectIoSafe) +if err := x.DiscardEnable.toC(&xc.discard_enable); err != nil { +return fmt.Errorf("converting field DiscardEnable: %v", err) +} +if err := x.ColoEnable.toC(&xc.colo_enable); err != nil { +return fmt.Errorf("converting field ColoEnable: %v", err) +} +if err := x.ColoRestoreEnable.toC(&xc.colo_restore_enable); err != nil { +return fmt.Errorf("converting field ColoRestoreEnable: %v", err) +} +if x.ColoHost != "" { +xc.colo_host = C.CString(x.ColoHost)} +xc.colo_port = C.int(x.ColoPort) +if x.ColoExport != "" { +xc.colo_export = C.CString(x.ColoExport)} +if x.ActiveDisk != "" { +xc.active_disk = C.CString(x.ActiveDisk)} +if x.HiddenDisk != "" { +xc.hidden_disk = C.CString(x.HiddenDisk)} + + return nil + } // NewDeviceNic returns an instance of DeviceNic initialized with defaults. func NewDeviceNic() (*DeviceNic, error) { - var ( - x DeviceNic - xc C.libxl_device_nic - ) +var ( +x DeviceNic +xc C.libxl_device_nic) - C.libxl_device_nic_init(&xc) - defer C.libxl_device_nic_dispose(&xc) +C.libxl_device_nic_init(&xc) +defer C.libxl_device_nic_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceNic) fromC(xc *C.libxl_device_nic) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.Devid = Devid(xc.devid) - x.Mtu = int(xc.mtu) - x.Model = C.GoString(xc.model) - if err := x.Mac.fromC(&xc.mac); err != nil { - return fmt.Errorf("converting field Mac: %v", err) - } - x.Ip = C.GoString(xc.ip) - x.Bridge = C.GoString(xc.bridge) - x.Ifname = C.GoString(xc.ifname) - x.Script = C.GoString(xc.script) - x.Nictype = NicType(xc.nictype) - x.RateBytesPerInterval = uint64(xc.rate_bytes_per_interval) - x.RateIntervalUsecs = uint32(xc.rate_interval_usecs) - x.Gatewaydev = C.GoString(xc.gatewaydev) - x.ColoftForwarddev = C.GoString(xc.coloft_forwarddev) - x.ColoSockMirrorId = C.GoString(xc.colo_sock_mirror_id) - x.ColoSockMirrorIp = C.GoString(xc.colo_sock_mirror_ip) - x.ColoSockMirrorPort = C.GoString(xc.colo_sock_mirror_port) - x.ColoSockComparePriInId = C.GoString(xc.colo_sock_compare_pri_in_id) - x.ColoSockComparePriInIp = C.GoString(xc.colo_sock_compare_pri_in_ip) - x.ColoSockComparePriInPort = C.GoString(xc.colo_sock_compare_pri_in_port) - x.ColoSockCompareSecInId = C.GoString(xc.colo_sock_compare_sec_in_id) - x.ColoSockCompareSecInIp = C.GoString(xc.colo_sock_compare_sec_in_ip) - x.ColoSockCompareSecInPort = C.GoString(xc.colo_sock_compare_sec_in_port) - x.ColoSockCompareNotifyId = C.GoString(xc.colo_sock_compare_notify_id) - x.ColoSockCompareNotifyIp = C.GoString(xc.colo_sock_compare_notify_ip) - x.ColoSockCompareNotifyPort = C.GoString(xc.colo_sock_compare_notify_port) - x.ColoSockRedirector0Id = C.GoString(xc.colo_sock_redirector0_id) - x.ColoSockRedirector0Ip = C.GoString(xc.colo_sock_redirector0_ip) - x.ColoSockRedirector0Port = C.GoString(xc.colo_sock_redirector0_port) - x.ColoSockRedirector1Id = C.GoString(xc.colo_sock_redirector1_id) - x.ColoSockRedirector1Ip = C.GoString(xc.colo_sock_redirector1_ip) - x.ColoSockRedirector1Port = C.GoString(xc.colo_sock_redirector1_port) - x.ColoSockRedirector2Id = C.GoString(xc.colo_sock_redirector2_id) - x.ColoSockRedirector2Ip = C.GoString(xc.colo_sock_redirector2_ip) - x.ColoSockRedirector2Port = C.GoString(xc.colo_sock_redirector2_port) - x.ColoFilterMirrorQueue = C.GoString(xc.colo_filter_mirror_queue) - x.ColoFilterMirrorOutdev = C.GoString(xc.colo_filter_mirror_outdev) - x.ColoFilterRedirector0Queue = C.GoString(xc.colo_filter_redirector0_queue) - x.ColoFilterRedirector0Indev = C.GoString(xc.colo_filter_redirector0_indev) - x.ColoFilterRedirector0Outdev = C.GoString(xc.colo_filter_redirector0_outdev) - x.ColoFilterRedirector1Queue = C.GoString(xc.colo_filter_redirector1_queue) - x.ColoFilterRedirector1Indev = C.GoString(xc.colo_filter_redirector1_indev) - x.ColoFilterRedirector1Outdev = C.GoString(xc.colo_filter_redirector1_outdev) - x.ColoComparePriIn = C.GoString(xc.colo_compare_pri_in) - x.ColoCompareSecIn = C.GoString(xc.colo_compare_sec_in) - x.ColoCompareOut = C.GoString(xc.colo_compare_out) - x.ColoCompareNotifyDev = C.GoString(xc.colo_compare_notify_dev) - x.ColoSockSecRedirector0Id = C.GoString(xc.colo_sock_sec_redirector0_id) - x.ColoSockSecRedirector0Ip = C.GoString(xc.colo_sock_sec_redirector0_ip) - x.ColoSockSecRedirector0Port = C.GoString(xc.colo_sock_sec_redirector0_port) - x.ColoSockSecRedirector1Id = C.GoString(xc.colo_sock_sec_redirector1_id) - x.ColoSockSecRedirector1Ip = C.GoString(xc.colo_sock_sec_redirector1_ip) - x.ColoSockSecRedirector1Port = C.GoString(xc.colo_sock_sec_redirector1_port) - x.ColoFilterSecRedirector0Queue = C.GoString(xc.colo_filter_sec_redirector0_queue) - x.ColoFilterSecRedirector0Indev = C.GoString(xc.colo_filter_sec_redirector0_indev) - x.ColoFilterSecRedirector0Outdev = C.GoString(xc.colo_filter_sec_redirector0_outdev) - x.ColoFilterSecRedirector1Queue = C.GoString(xc.colo_filter_sec_redirector1_queue) - x.ColoFilterSecRedirector1Indev = C.GoString(xc.colo_filter_sec_redirector1_indev) - x.ColoFilterSecRedirector1Outdev = C.GoString(xc.colo_filter_sec_redirector1_outdev) - x.ColoFilterSecRewriter0Queue = C.GoString(xc.colo_filter_sec_rewriter0_queue) - x.ColoCheckpointHost = C.GoString(xc.colo_checkpoint_host) - x.ColoCheckpointPort = C.GoString(xc.colo_checkpoint_port) - - return nil -} - -func (x *DeviceNic) toC(xc *C.libxl_device_nic) (err error) { - defer func() { - if err != nil { - C.libxl_device_nic_dispose(xc) - } - }() - - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - xc.devid = C.libxl_devid(x.Devid) - xc.mtu = C.int(x.Mtu) - if x.Model != "" { - xc.model = C.CString(x.Model) - } - if err := x.Mac.toC(&xc.mac); err != nil { - return fmt.Errorf("converting field Mac: %v", err) - } - if x.Ip != "" { - xc.ip = C.CString(x.Ip) - } - if x.Bridge != "" { - xc.bridge = C.CString(x.Bridge) - } - if x.Ifname != "" { - xc.ifname = C.CString(x.Ifname) - } - if x.Script != "" { - xc.script = C.CString(x.Script) - } - xc.nictype = C.libxl_nic_type(x.Nictype) - xc.rate_bytes_per_interval = C.uint64_t(x.RateBytesPerInterval) - xc.rate_interval_usecs = C.uint32_t(x.RateIntervalUsecs) - if x.Gatewaydev != "" { - xc.gatewaydev = C.CString(x.Gatewaydev) - } - if x.ColoftForwarddev != "" { - xc.coloft_forwarddev = C.CString(x.ColoftForwarddev) - } - if x.ColoSockMirrorId != "" { - xc.colo_sock_mirror_id = C.CString(x.ColoSockMirrorId) - } - if x.ColoSockMirrorIp != "" { - xc.colo_sock_mirror_ip = C.CString(x.ColoSockMirrorIp) - } - if x.ColoSockMirrorPort != "" { - xc.colo_sock_mirror_port = C.CString(x.ColoSockMirrorPort) - } - if x.ColoSockComparePriInId != "" { - xc.colo_sock_compare_pri_in_id = C.CString(x.ColoSockComparePriInId) - } - if x.ColoSockComparePriInIp != "" { - xc.colo_sock_compare_pri_in_ip = C.CString(x.ColoSockComparePriInIp) - } - if x.ColoSockComparePriInPort != "" { - xc.colo_sock_compare_pri_in_port = C.CString(x.ColoSockComparePriInPort) - } - if x.ColoSockCompareSecInId != "" { - xc.colo_sock_compare_sec_in_id = C.CString(x.ColoSockCompareSecInId) - } - if x.ColoSockCompareSecInIp != "" { - xc.colo_sock_compare_sec_in_ip = C.CString(x.ColoSockCompareSecInIp) - } - if x.ColoSockCompareSecInPort != "" { - xc.colo_sock_compare_sec_in_port = C.CString(x.ColoSockCompareSecInPort) - } - if x.ColoSockCompareNotifyId != "" { - xc.colo_sock_compare_notify_id = C.CString(x.ColoSockCompareNotifyId) - } - if x.ColoSockCompareNotifyIp != "" { - xc.colo_sock_compare_notify_ip = C.CString(x.ColoSockCompareNotifyIp) - } - if x.ColoSockCompareNotifyPort != "" { - xc.colo_sock_compare_notify_port = C.CString(x.ColoSockCompareNotifyPort) - } - if x.ColoSockRedirector0Id != "" { - xc.colo_sock_redirector0_id = C.CString(x.ColoSockRedirector0Id) - } - if x.ColoSockRedirector0Ip != "" { - xc.colo_sock_redirector0_ip = C.CString(x.ColoSockRedirector0Ip) - } - if x.ColoSockRedirector0Port != "" { - xc.colo_sock_redirector0_port = C.CString(x.ColoSockRedirector0Port) - } - if x.ColoSockRedirector1Id != "" { - xc.colo_sock_redirector1_id = C.CString(x.ColoSockRedirector1Id) - } - if x.ColoSockRedirector1Ip != "" { - xc.colo_sock_redirector1_ip = C.CString(x.ColoSockRedirector1Ip) - } - if x.ColoSockRedirector1Port != "" { - xc.colo_sock_redirector1_port = C.CString(x.ColoSockRedirector1Port) - } - if x.ColoSockRedirector2Id != "" { - xc.colo_sock_redirector2_id = C.CString(x.ColoSockRedirector2Id) - } - if x.ColoSockRedirector2Ip != "" { - xc.colo_sock_redirector2_ip = C.CString(x.ColoSockRedirector2Ip) - } - if x.ColoSockRedirector2Port != "" { - xc.colo_sock_redirector2_port = C.CString(x.ColoSockRedirector2Port) - } - if x.ColoFilterMirrorQueue != "" { - xc.colo_filter_mirror_queue = C.CString(x.ColoFilterMirrorQueue) - } - if x.ColoFilterMirrorOutdev != "" { - xc.colo_filter_mirror_outdev = C.CString(x.ColoFilterMirrorOutdev) - } - if x.ColoFilterRedirector0Queue != "" { - xc.colo_filter_redirector0_queue = C.CString(x.ColoFilterRedirector0Queue) - } - if x.ColoFilterRedirector0Indev != "" { - xc.colo_filter_redirector0_indev = C.CString(x.ColoFilterRedirector0Indev) - } - if x.ColoFilterRedirector0Outdev != "" { - xc.colo_filter_redirector0_outdev = C.CString(x.ColoFilterRedirector0Outdev) - } - if x.ColoFilterRedirector1Queue != "" { - xc.colo_filter_redirector1_queue = C.CString(x.ColoFilterRedirector1Queue) - } - if x.ColoFilterRedirector1Indev != "" { - xc.colo_filter_redirector1_indev = C.CString(x.ColoFilterRedirector1Indev) - } - if x.ColoFilterRedirector1Outdev != "" { - xc.colo_filter_redirector1_outdev = C.CString(x.ColoFilterRedirector1Outdev) - } - if x.ColoComparePriIn != "" { - xc.colo_compare_pri_in = C.CString(x.ColoComparePriIn) - } - if x.ColoCompareSecIn != "" { - xc.colo_compare_sec_in = C.CString(x.ColoCompareSecIn) - } - if x.ColoCompareOut != "" { - xc.colo_compare_out = C.CString(x.ColoCompareOut) - } - if x.ColoCompareNotifyDev != "" { - xc.colo_compare_notify_dev = C.CString(x.ColoCompareNotifyDev) - } - if x.ColoSockSecRedirector0Id != "" { - xc.colo_sock_sec_redirector0_id = C.CString(x.ColoSockSecRedirector0Id) - } - if x.ColoSockSecRedirector0Ip != "" { - xc.colo_sock_sec_redirector0_ip = C.CString(x.ColoSockSecRedirector0Ip) - } - if x.ColoSockSecRedirector0Port != "" { - xc.colo_sock_sec_redirector0_port = C.CString(x.ColoSockSecRedirector0Port) - } - if x.ColoSockSecRedirector1Id != "" { - xc.colo_sock_sec_redirector1_id = C.CString(x.ColoSockSecRedirector1Id) - } - if x.ColoSockSecRedirector1Ip != "" { - xc.colo_sock_sec_redirector1_ip = C.CString(x.ColoSockSecRedirector1Ip) - } - if x.ColoSockSecRedirector1Port != "" { - xc.colo_sock_sec_redirector1_port = C.CString(x.ColoSockSecRedirector1Port) - } - if x.ColoFilterSecRedirector0Queue != "" { - xc.colo_filter_sec_redirector0_queue = C.CString(x.ColoFilterSecRedirector0Queue) - } - if x.ColoFilterSecRedirector0Indev != "" { - xc.colo_filter_sec_redirector0_indev = C.CString(x.ColoFilterSecRedirector0Indev) - } - if x.ColoFilterSecRedirector0Outdev != "" { - xc.colo_filter_sec_redirector0_outdev = C.CString(x.ColoFilterSecRedirector0Outdev) - } - if x.ColoFilterSecRedirector1Queue != "" { - xc.colo_filter_sec_redirector1_queue = C.CString(x.ColoFilterSecRedirector1Queue) - } - if x.ColoFilterSecRedirector1Indev != "" { - xc.colo_filter_sec_redirector1_indev = C.CString(x.ColoFilterSecRedirector1Indev) - } - if x.ColoFilterSecRedirector1Outdev != "" { - xc.colo_filter_sec_redirector1_outdev = C.CString(x.ColoFilterSecRedirector1Outdev) - } - if x.ColoFilterSecRewriter0Queue != "" { - xc.colo_filter_sec_rewriter0_queue = C.CString(x.ColoFilterSecRewriter0Queue) - } - if x.ColoCheckpointHost != "" { - xc.colo_checkpoint_host = C.CString(x.ColoCheckpointHost) - } - if x.ColoCheckpointPort != "" { - xc.colo_checkpoint_port = C.CString(x.ColoCheckpointPort) - } - - return nil -} + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.Devid = Devid(xc.devid) +x.Mtu = int(xc.mtu) +x.Model = C.GoString(xc.model) +if err := x.Mac.fromC(&xc.mac);err != nil { +return fmt.Errorf("converting field Mac: %v", err) +} +x.Ip = C.GoString(xc.ip) +x.Bridge = C.GoString(xc.bridge) +x.Ifname = C.GoString(xc.ifname) +x.Script = C.GoString(xc.script) +x.Nictype = NicType(xc.nictype) +x.RateBytesPerInterval = uint64(xc.rate_bytes_per_interval) +x.RateIntervalUsecs = uint32(xc.rate_interval_usecs) +x.Gatewaydev = C.GoString(xc.gatewaydev) +x.ColoftForwarddev = C.GoString(xc.coloft_forwarddev) +x.ColoSockMirrorId = C.GoString(xc.colo_sock_mirror_id) +x.ColoSockMirrorIp = C.GoString(xc.colo_sock_mirror_ip) +x.ColoSockMirrorPort = C.GoString(xc.colo_sock_mirror_port) +x.ColoSockComparePriInId = C.GoString(xc.colo_sock_compare_pri_in_id) +x.ColoSockComparePriInIp = C.GoString(xc.colo_sock_compare_pri_in_ip) +x.ColoSockComparePriInPort = C.GoString(xc.colo_sock_compare_pri_in_port) +x.ColoSockCompareSecInId = C.GoString(xc.colo_sock_compare_sec_in_id) +x.ColoSockCompareSecInIp = C.GoString(xc.colo_sock_compare_sec_in_ip) +x.ColoSockCompareSecInPort = C.GoString(xc.colo_sock_compare_sec_in_port) +x.ColoSockCompareNotifyId = C.GoString(xc.colo_sock_compare_notify_id) +x.ColoSockCompareNotifyIp = C.GoString(xc.colo_sock_compare_notify_ip) +x.ColoSockCompareNotifyPort = C.GoString(xc.colo_sock_compare_notify_port) +x.ColoSockRedirector0Id = C.GoString(xc.colo_sock_redirector0_id) +x.ColoSockRedirector0Ip = C.GoString(xc.colo_sock_redirector0_ip) +x.ColoSockRedirector0Port = C.GoString(xc.colo_sock_redirector0_port) +x.ColoSockRedirector1Id = C.GoString(xc.colo_sock_redirector1_id) +x.ColoSockRedirector1Ip = C.GoString(xc.colo_sock_redirector1_ip) +x.ColoSockRedirector1Port = C.GoString(xc.colo_sock_redirector1_port) +x.ColoSockRedirector2Id = C.GoString(xc.colo_sock_redirector2_id) +x.ColoSockRedirector2Ip = C.GoString(xc.colo_sock_redirector2_ip) +x.ColoSockRedirector2Port = C.GoString(xc.colo_sock_redirector2_port) +x.ColoFilterMirrorQueue = C.GoString(xc.colo_filter_mirror_queue) +x.ColoFilterMirrorOutdev = C.GoString(xc.colo_filter_mirror_outdev) +x.ColoFilterRedirector0Queue = C.GoString(xc.colo_filter_redirector0_queue) +x.ColoFilterRedirector0Indev = C.GoString(xc.colo_filter_redirector0_indev) +x.ColoFilterRedirector0Outdev = C.GoString(xc.colo_filter_redirector0_outdev) +x.ColoFilterRedirector1Queue = C.GoString(xc.colo_filter_redirector1_queue) +x.ColoFilterRedirector1Indev = C.GoString(xc.colo_filter_redirector1_indev) +x.ColoFilterRedirector1Outdev = C.GoString(xc.colo_filter_redirector1_outdev) +x.ColoComparePriIn = C.GoString(xc.colo_compare_pri_in) +x.ColoCompareSecIn = C.GoString(xc.colo_compare_sec_in) +x.ColoCompareOut = C.GoString(xc.colo_compare_out) +x.ColoCompareNotifyDev = C.GoString(xc.colo_compare_notify_dev) +x.ColoSockSecRedirector0Id = C.GoString(xc.colo_sock_sec_redirector0_id) +x.ColoSockSecRedirector0Ip = C.GoString(xc.colo_sock_sec_redirector0_ip) +x.ColoSockSecRedirector0Port = C.GoString(xc.colo_sock_sec_redirector0_port) +x.ColoSockSecRedirector1Id = C.GoString(xc.colo_sock_sec_redirector1_id) +x.ColoSockSecRedirector1Ip = C.GoString(xc.colo_sock_sec_redirector1_ip) +x.ColoSockSecRedirector1Port = C.GoString(xc.colo_sock_sec_redirector1_port) +x.ColoFilterSecRedirector0Queue = C.GoString(xc.colo_filter_sec_redirector0_queue) +x.ColoFilterSecRedirector0Indev = C.GoString(xc.colo_filter_sec_redirector0_indev) +x.ColoFilterSecRedirector0Outdev = C.GoString(xc.colo_filter_sec_redirector0_outdev) +x.ColoFilterSecRedirector1Queue = C.GoString(xc.colo_filter_sec_redirector1_queue) +x.ColoFilterSecRedirector1Indev = C.GoString(xc.colo_filter_sec_redirector1_indev) +x.ColoFilterSecRedirector1Outdev = C.GoString(xc.colo_filter_sec_redirector1_outdev) +x.ColoFilterSecRewriter0Queue = C.GoString(xc.colo_filter_sec_rewriter0_queue) +x.ColoCheckpointHost = C.GoString(xc.colo_checkpoint_host) +x.ColoCheckpointPort = C.GoString(xc.colo_checkpoint_port) + + return nil} + +func (x *DeviceNic) toC(xc *C.libxl_device_nic) (err error){defer func(){ +if err != nil{ +C.libxl_device_nic_dispose(xc)} +}() + +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +xc.devid = C.libxl_devid(x.Devid) +xc.mtu = C.int(x.Mtu) +if x.Model != "" { +xc.model = C.CString(x.Model)} +if err := x.Mac.toC(&xc.mac); err != nil { +return fmt.Errorf("converting field Mac: %v", err) +} +if x.Ip != "" { +xc.ip = C.CString(x.Ip)} +if x.Bridge != "" { +xc.bridge = C.CString(x.Bridge)} +if x.Ifname != "" { +xc.ifname = C.CString(x.Ifname)} +if x.Script != "" { +xc.script = C.CString(x.Script)} +xc.nictype = C.libxl_nic_type(x.Nictype) +xc.rate_bytes_per_interval = C.uint64_t(x.RateBytesPerInterval) +xc.rate_interval_usecs = C.uint32_t(x.RateIntervalUsecs) +if x.Gatewaydev != "" { +xc.gatewaydev = C.CString(x.Gatewaydev)} +if x.ColoftForwarddev != "" { +xc.coloft_forwarddev = C.CString(x.ColoftForwarddev)} +if x.ColoSockMirrorId != "" { +xc.colo_sock_mirror_id = C.CString(x.ColoSockMirrorId)} +if x.ColoSockMirrorIp != "" { +xc.colo_sock_mirror_ip = C.CString(x.ColoSockMirrorIp)} +if x.ColoSockMirrorPort != "" { +xc.colo_sock_mirror_port = C.CString(x.ColoSockMirrorPort)} +if x.ColoSockComparePriInId != "" { +xc.colo_sock_compare_pri_in_id = C.CString(x.ColoSockComparePriInId)} +if x.ColoSockComparePriInIp != "" { +xc.colo_sock_compare_pri_in_ip = C.CString(x.ColoSockComparePriInIp)} +if x.ColoSockComparePriInPort != "" { +xc.colo_sock_compare_pri_in_port = C.CString(x.ColoSockComparePriInPort)} +if x.ColoSockCompareSecInId != "" { +xc.colo_sock_compare_sec_in_id = C.CString(x.ColoSockCompareSecInId)} +if x.ColoSockCompareSecInIp != "" { +xc.colo_sock_compare_sec_in_ip = C.CString(x.ColoSockCompareSecInIp)} +if x.ColoSockCompareSecInPort != "" { +xc.colo_sock_compare_sec_in_port = C.CString(x.ColoSockCompareSecInPort)} +if x.ColoSockCompareNotifyId != "" { +xc.colo_sock_compare_notify_id = C.CString(x.ColoSockCompareNotifyId)} +if x.ColoSockCompareNotifyIp != "" { +xc.colo_sock_compare_notify_ip = C.CString(x.ColoSockCompareNotifyIp)} +if x.ColoSockCompareNotifyPort != "" { +xc.colo_sock_compare_notify_port = C.CString(x.ColoSockCompareNotifyPort)} +if x.ColoSockRedirector0Id != "" { +xc.colo_sock_redirector0_id = C.CString(x.ColoSockRedirector0Id)} +if x.ColoSockRedirector0Ip != "" { +xc.colo_sock_redirector0_ip = C.CString(x.ColoSockRedirector0Ip)} +if x.ColoSockRedirector0Port != "" { +xc.colo_sock_redirector0_port = C.CString(x.ColoSockRedirector0Port)} +if x.ColoSockRedirector1Id != "" { +xc.colo_sock_redirector1_id = C.CString(x.ColoSockRedirector1Id)} +if x.ColoSockRedirector1Ip != "" { +xc.colo_sock_redirector1_ip = C.CString(x.ColoSockRedirector1Ip)} +if x.ColoSockRedirector1Port != "" { +xc.colo_sock_redirector1_port = C.CString(x.ColoSockRedirector1Port)} +if x.ColoSockRedirector2Id != "" { +xc.colo_sock_redirector2_id = C.CString(x.ColoSockRedirector2Id)} +if x.ColoSockRedirector2Ip != "" { +xc.colo_sock_redirector2_ip = C.CString(x.ColoSockRedirector2Ip)} +if x.ColoSockRedirector2Port != "" { +xc.colo_sock_redirector2_port = C.CString(x.ColoSockRedirector2Port)} +if x.ColoFilterMirrorQueue != "" { +xc.colo_filter_mirror_queue = C.CString(x.ColoFilterMirrorQueue)} +if x.ColoFilterMirrorOutdev != "" { +xc.colo_filter_mirror_outdev = C.CString(x.ColoFilterMirrorOutdev)} +if x.ColoFilterRedirector0Queue != "" { +xc.colo_filter_redirector0_queue = C.CString(x.ColoFilterRedirector0Queue)} +if x.ColoFilterRedirector0Indev != "" { +xc.colo_filter_redirector0_indev = C.CString(x.ColoFilterRedirector0Indev)} +if x.ColoFilterRedirector0Outdev != "" { +xc.colo_filter_redirector0_outdev = C.CString(x.ColoFilterRedirector0Outdev)} +if x.ColoFilterRedirector1Queue != "" { +xc.colo_filter_redirector1_queue = C.CString(x.ColoFilterRedirector1Queue)} +if x.ColoFilterRedirector1Indev != "" { +xc.colo_filter_redirector1_indev = C.CString(x.ColoFilterRedirector1Indev)} +if x.ColoFilterRedirector1Outdev != "" { +xc.colo_filter_redirector1_outdev = C.CString(x.ColoFilterRedirector1Outdev)} +if x.ColoComparePriIn != "" { +xc.colo_compare_pri_in = C.CString(x.ColoComparePriIn)} +if x.ColoCompareSecIn != "" { +xc.colo_compare_sec_in = C.CString(x.ColoCompareSecIn)} +if x.ColoCompareOut != "" { +xc.colo_compare_out = C.CString(x.ColoCompareOut)} +if x.ColoCompareNotifyDev != "" { +xc.colo_compare_notify_dev = C.CString(x.ColoCompareNotifyDev)} +if x.ColoSockSecRedirector0Id != "" { +xc.colo_sock_sec_redirector0_id = C.CString(x.ColoSockSecRedirector0Id)} +if x.ColoSockSecRedirector0Ip != "" { +xc.colo_sock_sec_redirector0_ip = C.CString(x.ColoSockSecRedirector0Ip)} +if x.ColoSockSecRedirector0Port != "" { +xc.colo_sock_sec_redirector0_port = C.CString(x.ColoSockSecRedirector0Port)} +if x.ColoSockSecRedirector1Id != "" { +xc.colo_sock_sec_redirector1_id = C.CString(x.ColoSockSecRedirector1Id)} +if x.ColoSockSecRedirector1Ip != "" { +xc.colo_sock_sec_redirector1_ip = C.CString(x.ColoSockSecRedirector1Ip)} +if x.ColoSockSecRedirector1Port != "" { +xc.colo_sock_sec_redirector1_port = C.CString(x.ColoSockSecRedirector1Port)} +if x.ColoFilterSecRedirector0Queue != "" { +xc.colo_filter_sec_redirector0_queue = C.CString(x.ColoFilterSecRedirector0Queue)} +if x.ColoFilterSecRedirector0Indev != "" { +xc.colo_filter_sec_redirector0_indev = C.CString(x.ColoFilterSecRedirector0Indev)} +if x.ColoFilterSecRedirector0Outdev != "" { +xc.colo_filter_sec_redirector0_outdev = C.CString(x.ColoFilterSecRedirector0Outdev)} +if x.ColoFilterSecRedirector1Queue != "" { +xc.colo_filter_sec_redirector1_queue = C.CString(x.ColoFilterSecRedirector1Queue)} +if x.ColoFilterSecRedirector1Indev != "" { +xc.colo_filter_sec_redirector1_indev = C.CString(x.ColoFilterSecRedirector1Indev)} +if x.ColoFilterSecRedirector1Outdev != "" { +xc.colo_filter_sec_redirector1_outdev = C.CString(x.ColoFilterSecRedirector1Outdev)} +if x.ColoFilterSecRewriter0Queue != "" { +xc.colo_filter_sec_rewriter0_queue = C.CString(x.ColoFilterSecRewriter0Queue)} +if x.ColoCheckpointHost != "" { +xc.colo_checkpoint_host = C.CString(x.ColoCheckpointHost)} +if x.ColoCheckpointPort != "" { +xc.colo_checkpoint_port = C.CString(x.ColoCheckpointPort)} + + return nil + } // NewDevicePci returns an instance of DevicePci initialized with defaults. func NewDevicePci() (*DevicePci, error) { - var ( - x DevicePci - xc C.libxl_device_pci - ) +var ( +x DevicePci +xc C.libxl_device_pci) - C.libxl_device_pci_init(&xc) - defer C.libxl_device_pci_dispose(&xc) +C.libxl_device_pci_init(&xc) +defer C.libxl_device_pci_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DevicePci) fromC(xc *C.libxl_device_pci) error { - x.Func = byte(xc._func) - x.Dev = byte(xc.dev) - x.Bus = byte(xc.bus) - x.Domain = int(xc.domain) - x.Vdevfn = uint32(xc.vdevfn) - x.VfuncMask = uint32(xc.vfunc_mask) - x.Msitranslate = bool(xc.msitranslate) - x.PowerMgmt = bool(xc.power_mgmt) - x.Permissive = bool(xc.permissive) - x.Seize = bool(xc.seize) - x.RdmPolicy = RdmReservePolicy(xc.rdm_policy) - - return nil -} - -func (x *DevicePci) toC(xc *C.libxl_device_pci) (err error) { - defer func() { - if err != nil { - C.libxl_device_pci_dispose(xc) - } - }() - - xc._func = C.uint8_t(x.Func) - xc.dev = C.uint8_t(x.Dev) - xc.bus = C.uint8_t(x.Bus) - xc.domain = C.int(x.Domain) - xc.vdevfn = C.uint32_t(x.Vdevfn) - xc.vfunc_mask = C.uint32_t(x.VfuncMask) - xc.msitranslate = C.bool(x.Msitranslate) - xc.power_mgmt = C.bool(x.PowerMgmt) - xc.permissive = C.bool(x.Permissive) - xc.seize = C.bool(x.Seize) - xc.rdm_policy = C.libxl_rdm_reserve_policy(x.RdmPolicy) - - return nil -} + x.Func = byte(xc._func) +x.Dev = byte(xc.dev) +x.Bus = byte(xc.bus) +x.Domain = int(xc.domain) +x.Vdevfn = uint32(xc.vdevfn) +x.VfuncMask = uint32(xc.vfunc_mask) +x.Msitranslate = bool(xc.msitranslate) +x.PowerMgmt = bool(xc.power_mgmt) +x.Permissive = bool(xc.permissive) +x.Seize = bool(xc.seize) +x.RdmPolicy = RdmReservePolicy(xc.rdm_policy) + + return nil} + +func (x *DevicePci) toC(xc *C.libxl_device_pci) (err error){defer func(){ +if err != nil{ +C.libxl_device_pci_dispose(xc)} +}() + +xc._func = C.uint8_t(x.Func) +xc.dev = C.uint8_t(x.Dev) +xc.bus = C.uint8_t(x.Bus) +xc.domain = C.int(x.Domain) +xc.vdevfn = C.uint32_t(x.Vdevfn) +xc.vfunc_mask = C.uint32_t(x.VfuncMask) +xc.msitranslate = C.bool(x.Msitranslate) +xc.power_mgmt = C.bool(x.PowerMgmt) +xc.permissive = C.bool(x.Permissive) +xc.seize = C.bool(x.Seize) +xc.rdm_policy = C.libxl_rdm_reserve_policy(x.RdmPolicy) + + return nil + } // NewDeviceRdm returns an instance of DeviceRdm initialized with defaults. func NewDeviceRdm() (*DeviceRdm, error) { - var ( - x DeviceRdm - xc C.libxl_device_rdm - ) +var ( +x DeviceRdm +xc C.libxl_device_rdm) - C.libxl_device_rdm_init(&xc) - defer C.libxl_device_rdm_dispose(&xc) +C.libxl_device_rdm_init(&xc) +defer C.libxl_device_rdm_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceRdm) fromC(xc *C.libxl_device_rdm) error { - x.Start = uint64(xc.start) - x.Size = uint64(xc.size) - x.Policy = RdmReservePolicy(xc.policy) - - return nil -} + x.Start = uint64(xc.start) +x.Size = uint64(xc.size) +x.Policy = RdmReservePolicy(xc.policy) + + return nil} -func (x *DeviceRdm) toC(xc *C.libxl_device_rdm) (err error) { - defer func() { - if err != nil { - C.libxl_device_rdm_dispose(xc) - } - }() +func (x *DeviceRdm) toC(xc *C.libxl_device_rdm) (err error){defer func(){ +if err != nil{ +C.libxl_device_rdm_dispose(xc)} +}() - xc.start = C.uint64_t(x.Start) - xc.size = C.uint64_t(x.Size) - xc.policy = C.libxl_rdm_reserve_policy(x.Policy) +xc.start = C.uint64_t(x.Start) +xc.size = C.uint64_t(x.Size) +xc.policy = C.libxl_rdm_reserve_policy(x.Policy) - return nil -} + return nil + } // NewDeviceUsbctrl returns an instance of DeviceUsbctrl initialized with defaults. func NewDeviceUsbctrl() (*DeviceUsbctrl, error) { - var ( - x DeviceUsbctrl - xc C.libxl_device_usbctrl - ) +var ( +x DeviceUsbctrl +xc C.libxl_device_usbctrl) - C.libxl_device_usbctrl_init(&xc) - defer C.libxl_device_usbctrl_dispose(&xc) +C.libxl_device_usbctrl_init(&xc) +defer C.libxl_device_usbctrl_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceUsbctrl) fromC(xc *C.libxl_device_usbctrl) error { - x.Type = UsbctrlType(xc._type) - x.Devid = Devid(xc.devid) - x.Version = int(xc.version) - x.Ports = int(xc.ports) - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - - return nil -} - -func (x *DeviceUsbctrl) toC(xc *C.libxl_device_usbctrl) (err error) { - defer func() { - if err != nil { - C.libxl_device_usbctrl_dispose(xc) - } - }() - - xc._type = C.libxl_usbctrl_type(x.Type) - xc.devid = C.libxl_devid(x.Devid) - xc.version = C.int(x.Version) - xc.ports = C.int(x.Ports) - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - - return nil -} + x.Type = UsbctrlType(xc._type) +x.Devid = Devid(xc.devid) +x.Version = int(xc.version) +x.Ports = int(xc.ports) +x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) + + return nil} + +func (x *DeviceUsbctrl) toC(xc *C.libxl_device_usbctrl) (err error){defer func(){ +if err != nil{ +C.libxl_device_usbctrl_dispose(xc)} +}() + +xc._type = C.libxl_usbctrl_type(x.Type) +xc.devid = C.libxl_devid(x.Devid) +xc.version = C.int(x.Version) +xc.ports = C.int(x.Ports) +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} + + return nil + } // NewDeviceUsbdev returns an instance of DeviceUsbdev initialized with defaults. func NewDeviceUsbdev(utype UsbdevType) (*DeviceUsbdev, error) { - var ( - x DeviceUsbdev - xc C.libxl_device_usbdev - ) +var ( +x DeviceUsbdev +xc C.libxl_device_usbdev) - C.libxl_device_usbdev_init(&xc) - C.libxl_device_usbdev_init_type(&xc, C.libxl_usbdev_type(utype)) - defer C.libxl_device_usbdev_dispose(&xc) +C.libxl_device_usbdev_init(&xc) +C.libxl_device_usbdev_init_type(&xc, C.libxl_usbdev_type(utype)) +defer C.libxl_device_usbdev_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceUsbdev) fromC(xc *C.libxl_device_usbdev) error { - x.Ctrl = Devid(xc.ctrl) - x.Port = int(xc.port) - x.Type = UsbdevType(xc._type) - switch x.Type { - case UsbdevTypeHostdev: - var typeHostdev DeviceUsbdevTypeUnionHostdev - if err := typeHostdev.fromC(xc); err != nil { - return fmt.Errorf("converting field typeHostdev: %v", err) - } - x.TypeUnion = typeHostdev - default: - return fmt.Errorf("invalid union key '%v'", x.Type) - } - - return nil -} + x.Ctrl = Devid(xc.ctrl) +x.Port = int(xc.port) +x.Type = UsbdevType(xc._type) +switch x.Type{ +case UsbdevTypeHostdev: +var typeHostdev DeviceUsbdevTypeUnionHostdev +if err := typeHostdev.fromC(xc);err != nil { + return fmt.Errorf("converting field typeHostdev: %v", err) +} +x.TypeUnion = typeHostdev +default: +return fmt.Errorf("invalid union key '%v'", x.Type)} + + return nil} func (x *DeviceUsbdevTypeUnionHostdev) fromC(xc *C.libxl_device_usbdev) error { - if UsbdevType(xc._type) != UsbdevTypeHostdev { - return errors.New("expected union key UsbdevTypeHostdev") - } - - tmp := (*C.libxl_device_usbdev_type_union_hostdev)(unsafe.Pointer(&xc.u[0])) - x.Hostbus = byte(tmp.hostbus) - x.Hostaddr = byte(tmp.hostaddr) - return nil -} - -func (x *DeviceUsbdev) toC(xc *C.libxl_device_usbdev) (err error) { - defer func() { - if err != nil { - C.libxl_device_usbdev_dispose(xc) - } - }() - - xc.ctrl = C.libxl_devid(x.Ctrl) - xc.port = C.int(x.Port) - xc._type = C.libxl_usbdev_type(x.Type) - switch x.Type { - case UsbdevTypeHostdev: - tmp, ok := x.TypeUnion.(DeviceUsbdevTypeUnionHostdev) - if !ok { - return errors.New("wrong type for union key type") - } - var hostdev C.libxl_device_usbdev_type_union_hostdev - hostdev.hostbus = C.uint8_t(tmp.Hostbus) - hostdev.hostaddr = C.uint8_t(tmp.Hostaddr) - hostdevBytes := C.GoBytes(unsafe.Pointer(&hostdev), C.sizeof_libxl_device_usbdev_type_union_hostdev) - copy(xc.u[:], hostdevBytes) - default: - return fmt.Errorf("invalid union key '%v'", x.Type) - } - - return nil +if UsbdevType(xc._type) != UsbdevTypeHostdev { +return errors.New("expected union key UsbdevTypeHostdev") +} + +tmp := (*C.libxl_device_usbdev_type_union_hostdev)(unsafe.Pointer(&xc.u[0])) +x.Hostbus = byte(tmp.hostbus) +x.Hostaddr = byte(tmp.hostaddr) +return nil +} + +func (x *DeviceUsbdev) toC(xc *C.libxl_device_usbdev) (err error){defer func(){ +if err != nil{ +C.libxl_device_usbdev_dispose(xc)} +}() + +xc.ctrl = C.libxl_devid(x.Ctrl) +xc.port = C.int(x.Port) +xc._type = C.libxl_usbdev_type(x.Type) +switch x.Type{ +case UsbdevTypeHostdev: +tmp, ok := x.TypeUnion.(DeviceUsbdevTypeUnionHostdev) +if !ok { +return errors.New("wrong type for union key type") } +var hostdev C.libxl_device_usbdev_type_union_hostdev +hostdev.hostbus = C.uint8_t(tmp.Hostbus) +hostdev.hostaddr = C.uint8_t(tmp.Hostaddr) +hostdevBytes := C.GoBytes(unsafe.Pointer(&hostdev),C.sizeof_libxl_device_usbdev_type_union_hostdev) +copy(xc.u[:],hostdevBytes) +default: +return fmt.Errorf("invalid union key '%v'", x.Type)} + + return nil + } // NewDeviceDtdev returns an instance of DeviceDtdev initialized with defaults. func NewDeviceDtdev() (*DeviceDtdev, error) { - var ( - x DeviceDtdev - xc C.libxl_device_dtdev - ) +var ( +x DeviceDtdev +xc C.libxl_device_dtdev) - C.libxl_device_dtdev_init(&xc) - defer C.libxl_device_dtdev_dispose(&xc) +C.libxl_device_dtdev_init(&xc) +defer C.libxl_device_dtdev_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceDtdev) fromC(xc *C.libxl_device_dtdev) error { - x.Path = C.GoString(xc.path) - - return nil -} + x.Path = C.GoString(xc.path) + + return nil} -func (x *DeviceDtdev) toC(xc *C.libxl_device_dtdev) (err error) { - defer func() { - if err != nil { - C.libxl_device_dtdev_dispose(xc) - } - }() +func (x *DeviceDtdev) toC(xc *C.libxl_device_dtdev) (err error){defer func(){ +if err != nil{ +C.libxl_device_dtdev_dispose(xc)} +}() - if x.Path != "" { - xc.path = C.CString(x.Path) - } +if x.Path != "" { +xc.path = C.CString(x.Path)} - return nil -} + return nil + } // NewDeviceVtpm returns an instance of DeviceVtpm initialized with defaults. func NewDeviceVtpm() (*DeviceVtpm, error) { - var ( - x DeviceVtpm - xc C.libxl_device_vtpm - ) +var ( +x DeviceVtpm +xc C.libxl_device_vtpm) - C.libxl_device_vtpm_init(&xc) - defer C.libxl_device_vtpm_dispose(&xc) +C.libxl_device_vtpm_init(&xc) +defer C.libxl_device_vtpm_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceVtpm) fromC(xc *C.libxl_device_vtpm) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.Devid = Devid(xc.devid) - if err := x.Uuid.fromC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } - - return nil + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.Devid = Devid(xc.devid) +if err := x.Uuid.fromC(&xc.uuid);err != nil { +return fmt.Errorf("converting field Uuid: %v", err) } + + return nil} -func (x *DeviceVtpm) toC(xc *C.libxl_device_vtpm) (err error) { - defer func() { - if err != nil { - C.libxl_device_vtpm_dispose(xc) - } - }() - - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - xc.devid = C.libxl_devid(x.Devid) - if err := x.Uuid.toC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } +func (x *DeviceVtpm) toC(xc *C.libxl_device_vtpm) (err error){defer func(){ +if err != nil{ +C.libxl_device_vtpm_dispose(xc)} +}() - return nil +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +xc.devid = C.libxl_devid(x.Devid) +if err := x.Uuid.toC(&xc.uuid); err != nil { +return fmt.Errorf("converting field Uuid: %v", err) } + return nil + } + // NewDeviceP9 returns an instance of DeviceP9 initialized with defaults. func NewDeviceP9() (*DeviceP9, error) { - var ( - x DeviceP9 - xc C.libxl_device_p9 - ) +var ( +x DeviceP9 +xc C.libxl_device_p9) - C.libxl_device_p9_init(&xc) - defer C.libxl_device_p9_dispose(&xc) +C.libxl_device_p9_init(&xc) +defer C.libxl_device_p9_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceP9) fromC(xc *C.libxl_device_p9) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.Tag = C.GoString(xc.tag) - x.Path = C.GoString(xc.path) - x.SecurityModel = C.GoString(xc.security_model) - x.Devid = Devid(xc.devid) - - return nil -} - -func (x *DeviceP9) toC(xc *C.libxl_device_p9) (err error) { - defer func() { - if err != nil { - C.libxl_device_p9_dispose(xc) - } - }() - - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - if x.Tag != "" { - xc.tag = C.CString(x.Tag) - } - if x.Path != "" { - xc.path = C.CString(x.Path) - } - if x.SecurityModel != "" { - xc.security_model = C.CString(x.SecurityModel) - } - xc.devid = C.libxl_devid(x.Devid) - - return nil -} + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.Tag = C.GoString(xc.tag) +x.Path = C.GoString(xc.path) +x.SecurityModel = C.GoString(xc.security_model) +x.Devid = Devid(xc.devid) + + return nil} + +func (x *DeviceP9) toC(xc *C.libxl_device_p9) (err error){defer func(){ +if err != nil{ +C.libxl_device_p9_dispose(xc)} +}() + +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +if x.Tag != "" { +xc.tag = C.CString(x.Tag)} +if x.Path != "" { +xc.path = C.CString(x.Path)} +if x.SecurityModel != "" { +xc.security_model = C.CString(x.SecurityModel)} +xc.devid = C.libxl_devid(x.Devid) + + return nil + } // NewDevicePvcallsif returns an instance of DevicePvcallsif initialized with defaults. func NewDevicePvcallsif() (*DevicePvcallsif, error) { - var ( - x DevicePvcallsif - xc C.libxl_device_pvcallsif - ) +var ( +x DevicePvcallsif +xc C.libxl_device_pvcallsif) - C.libxl_device_pvcallsif_init(&xc) - defer C.libxl_device_pvcallsif_dispose(&xc) +C.libxl_device_pvcallsif_init(&xc) +defer C.libxl_device_pvcallsif_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DevicePvcallsif) fromC(xc *C.libxl_device_pvcallsif) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.Devid = Devid(xc.devid) + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.Devid = Devid(xc.devid) + + return nil} - return nil -} - -func (x *DevicePvcallsif) toC(xc *C.libxl_device_pvcallsif) (err error) { - defer func() { - if err != nil { - C.libxl_device_pvcallsif_dispose(xc) - } - }() +func (x *DevicePvcallsif) toC(xc *C.libxl_device_pvcallsif) (err error){defer func(){ +if err != nil{ +C.libxl_device_pvcallsif_dispose(xc)} +}() - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - xc.devid = C.libxl_devid(x.Devid) +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +xc.devid = C.libxl_devid(x.Devid) - return nil -} + return nil + } // NewDeviceChannel returns an instance of DeviceChannel initialized with defaults. func NewDeviceChannel(connection ChannelConnection) (*DeviceChannel, error) { - var ( - x DeviceChannel - xc C.libxl_device_channel - ) +var ( +x DeviceChannel +xc C.libxl_device_channel) - C.libxl_device_channel_init(&xc) - C.libxl_device_channel_init_connection(&xc, C.libxl_channel_connection(connection)) - defer C.libxl_device_channel_dispose(&xc) +C.libxl_device_channel_init(&xc) +C.libxl_device_channel_init_connection(&xc, C.libxl_channel_connection(connection)) +defer C.libxl_device_channel_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceChannel) fromC(xc *C.libxl_device_channel) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.Devid = Devid(xc.devid) - x.Name = C.GoString(xc.name) - x.Connection = ChannelConnection(xc.connection) - switch x.Connection { - case ChannelConnectionUnknown: - x.ConnectionUnion = nil - case ChannelConnectionPty: - x.ConnectionUnion = nil - case ChannelConnectionSocket: - var connectionSocket DeviceChannelConnectionUnionSocket - if err := connectionSocket.fromC(xc); err != nil { - return fmt.Errorf("converting field connectionSocket: %v", err) - } - x.ConnectionUnion = connectionSocket - default: - return fmt.Errorf("invalid union key '%v'", x.Connection) - } - - return nil -} + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.Devid = Devid(xc.devid) +x.Name = C.GoString(xc.name) +x.Connection = ChannelConnection(xc.connection) +switch x.Connection{ +case ChannelConnectionUnknown: +x.ConnectionUnion = nil +case ChannelConnectionPty: +x.ConnectionUnion = nil +case ChannelConnectionSocket: +var connectionSocket DeviceChannelConnectionUnionSocket +if err := connectionSocket.fromC(xc);err != nil { + return fmt.Errorf("converting field connectionSocket: %v", err) +} +x.ConnectionUnion = connectionSocket +default: +return fmt.Errorf("invalid union key '%v'", x.Connection)} + + return nil} func (x *DeviceChannelConnectionUnionSocket) fromC(xc *C.libxl_device_channel) error { - if ChannelConnection(xc.connection) != ChannelConnectionSocket { - return errors.New("expected union key ChannelConnectionSocket") - } - - tmp := (*C.libxl_device_channel_connection_union_socket)(unsafe.Pointer(&xc.u[0])) - x.Path = C.GoString(tmp.path) - return nil -} - -func (x *DeviceChannel) toC(xc *C.libxl_device_channel) (err error) { - defer func() { - if err != nil { - C.libxl_device_channel_dispose(xc) - } - }() - - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - xc.devid = C.libxl_devid(x.Devid) - if x.Name != "" { - xc.name = C.CString(x.Name) - } - xc.connection = C.libxl_channel_connection(x.Connection) - switch x.Connection { - case ChannelConnectionUnknown: - break - case ChannelConnectionPty: - break - case ChannelConnectionSocket: - tmp, ok := x.ConnectionUnion.(DeviceChannelConnectionUnionSocket) - if !ok { - return errors.New("wrong type for union key connection") - } - var socket C.libxl_device_channel_connection_union_socket - if tmp.Path != "" { - socket.path = C.CString(tmp.Path) - } - socketBytes := C.GoBytes(unsafe.Pointer(&socket), C.sizeof_libxl_device_channel_connection_union_socket) - copy(xc.u[:], socketBytes) - default: - return fmt.Errorf("invalid union key '%v'", x.Connection) - } - - return nil -} +if ChannelConnection(xc.connection) != ChannelConnectionSocket { +return errors.New("expected union key ChannelConnectionSocket") +} + +tmp := (*C.libxl_device_channel_connection_union_socket)(unsafe.Pointer(&xc.u[0])) +x.Path = C.GoString(tmp.path) +return nil +} + +func (x *DeviceChannel) toC(xc *C.libxl_device_channel) (err error){defer func(){ +if err != nil{ +C.libxl_device_channel_dispose(xc)} +}() + +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +xc.devid = C.libxl_devid(x.Devid) +if x.Name != "" { +xc.name = C.CString(x.Name)} +xc.connection = C.libxl_channel_connection(x.Connection) +switch x.Connection{ +case ChannelConnectionUnknown: +break +case ChannelConnectionPty: +break +case ChannelConnectionSocket: +tmp, ok := x.ConnectionUnion.(DeviceChannelConnectionUnionSocket) +if !ok { +return errors.New("wrong type for union key connection") +} +var socket C.libxl_device_channel_connection_union_socket +if tmp.Path != "" { +socket.path = C.CString(tmp.Path)} +socketBytes := C.GoBytes(unsafe.Pointer(&socket),C.sizeof_libxl_device_channel_connection_union_socket) +copy(xc.u[:],socketBytes) +default: +return fmt.Errorf("invalid union key '%v'", x.Connection)} + + return nil + } // NewConnectorParam returns an instance of ConnectorParam initialized with defaults. func NewConnectorParam() (*ConnectorParam, error) { - var ( - x ConnectorParam - xc C.libxl_connector_param - ) +var ( +x ConnectorParam +xc C.libxl_connector_param) - C.libxl_connector_param_init(&xc) - defer C.libxl_connector_param_dispose(&xc) +C.libxl_connector_param_init(&xc) +defer C.libxl_connector_param_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *ConnectorParam) fromC(xc *C.libxl_connector_param) error { - x.UniqueId = C.GoString(xc.unique_id) - x.Width = uint32(xc.width) - x.Height = uint32(xc.height) - - return nil -} + x.UniqueId = C.GoString(xc.unique_id) +x.Width = uint32(xc.width) +x.Height = uint32(xc.height) + + return nil} -func (x *ConnectorParam) toC(xc *C.libxl_connector_param) (err error) { - defer func() { - if err != nil { - C.libxl_connector_param_dispose(xc) - } - }() +func (x *ConnectorParam) toC(xc *C.libxl_connector_param) (err error){defer func(){ +if err != nil{ +C.libxl_connector_param_dispose(xc)} +}() - if x.UniqueId != "" { - xc.unique_id = C.CString(x.UniqueId) - } - xc.width = C.uint32_t(x.Width) - xc.height = C.uint32_t(x.Height) +if x.UniqueId != "" { +xc.unique_id = C.CString(x.UniqueId)} +xc.width = C.uint32_t(x.Width) +xc.height = C.uint32_t(x.Height) - return nil -} + return nil + } // NewDeviceVdispl returns an instance of DeviceVdispl initialized with defaults. func NewDeviceVdispl() (*DeviceVdispl, error) { - var ( - x DeviceVdispl - xc C.libxl_device_vdispl - ) +var ( +x DeviceVdispl +xc C.libxl_device_vdispl) - C.libxl_device_vdispl_init(&xc) - defer C.libxl_device_vdispl_dispose(&xc) +C.libxl_device_vdispl_init(&xc) +defer C.libxl_device_vdispl_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceVdispl) fromC(xc *C.libxl_device_vdispl) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.Devid = Devid(xc.devid) - x.BeAlloc = bool(xc.be_alloc) - x.Connectors = nil - if n := int(xc.num_connectors); n > 0 { - cConnectors := (*[1 << 28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:n:n] - x.Connectors = make([]ConnectorParam, n) - for i, v := range cConnectors { - if err := x.Connectors[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Connectors: %v", err) - } - } - } - - return nil -} - -func (x *DeviceVdispl) toC(xc *C.libxl_device_vdispl) (err error) { - defer func() { - if err != nil { - C.libxl_device_vdispl_dispose(xc) - } - }() - - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - xc.devid = C.libxl_devid(x.Devid) - xc.be_alloc = C.bool(x.BeAlloc) - if numConnectors := len(x.Connectors); numConnectors > 0 { - xc.connectors = (*C.libxl_connector_param)(C.malloc(C.ulong(numConnectors) * C.sizeof_libxl_connector_param)) - xc.num_connectors = C.int(numConnectors) - cConnectors := (*[1 << 28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors] - for i, v := range x.Connectors { - if err := v.toC(&cConnectors[i]); err != nil { - return fmt.Errorf("converting field Connectors: %v", err) - } - } - } - - return nil -} + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.Devid = Devid(xc.devid) +x.BeAlloc = bool(xc.be_alloc) +x.Connectors = nil +if n := int(xc.num_connectors); n > 0 { +cConnectors := (*[1<<28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:n:n] +x.Connectors = make([]ConnectorParam, n) +for i, v := range cConnectors { +if err := x.Connectors[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Connectors: %v", err) } +} +} + + return nil} + +func (x *DeviceVdispl) toC(xc *C.libxl_device_vdispl) (err error){defer func(){ +if err != nil{ +C.libxl_device_vdispl_dispose(xc)} +}() + +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +xc.devid = C.libxl_devid(x.Devid) +xc.be_alloc = C.bool(x.BeAlloc) +if numConnectors := len(x.Connectors); numConnectors > 0 { +xc.connectors = (*C.libxl_connector_param)(C.malloc(C.ulong(numConnectors)*C.sizeof_libxl_connector_param)) +xc.num_connectors = C.int(numConnectors) +cConnectors := (*[1<<28]C.libxl_connector_param)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors] +for i,v := range x.Connectors { +if err := v.toC(&cConnectors[i]); err != nil { +return fmt.Errorf("converting field Connectors: %v", err) +} +} +} + + return nil + } // NewVsndParams returns an instance of VsndParams initialized with defaults. func NewVsndParams() (*VsndParams, error) { - var ( - x VsndParams - xc C.libxl_vsnd_params - ) +var ( +x VsndParams +xc C.libxl_vsnd_params) - C.libxl_vsnd_params_init(&xc) - defer C.libxl_vsnd_params_dispose(&xc) +C.libxl_vsnd_params_init(&xc) +defer C.libxl_vsnd_params_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *VsndParams) fromC(xc *C.libxl_vsnd_params) error { - x.SampleRates = nil - if n := int(xc.num_sample_rates); n > 0 { - cSampleRates := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:n:n] - x.SampleRates = make([]uint32, n) - for i, v := range cSampleRates { - x.SampleRates[i] = uint32(v) - } - } - x.SampleFormats = nil - if n := int(xc.num_sample_formats); n > 0 { - cSampleFormats := (*[1 << 28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:n:n] - x.SampleFormats = make([]VsndPcmFormat, n) - for i, v := range cSampleFormats { - x.SampleFormats[i] = VsndPcmFormat(v) - } - } - x.ChannelsMin = uint32(xc.channels_min) - x.ChannelsMax = uint32(xc.channels_max) - x.BufferSize = uint32(xc.buffer_size) - - return nil -} - -func (x *VsndParams) toC(xc *C.libxl_vsnd_params) (err error) { - defer func() { - if err != nil { - C.libxl_vsnd_params_dispose(xc) - } - }() - - if numSampleRates := len(x.SampleRates); numSampleRates > 0 { - xc.sample_rates = (*C.uint32_t)(C.malloc(C.size_t(numSampleRates * numSampleRates))) - xc.num_sample_rates = C.int(numSampleRates) - cSampleRates := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:numSampleRates:numSampleRates] - for i, v := range x.SampleRates { - cSampleRates[i] = C.uint32_t(v) - } - } - if numSampleFormats := len(x.SampleFormats); numSampleFormats > 0 { - xc.sample_formats = (*C.libxl_vsnd_pcm_format)(C.malloc(C.size_t(numSampleFormats * numSampleFormats))) - xc.num_sample_formats = C.int(numSampleFormats) - cSampleFormats := (*[1 << 28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:numSampleFormats:numSampleFormats] - for i, v := range x.SampleFormats { - cSampleFormats[i] = C.libxl_vsnd_pcm_format(v) - } - } - xc.channels_min = C.uint32_t(x.ChannelsMin) - xc.channels_max = C.uint32_t(x.ChannelsMax) - xc.buffer_size = C.uint32_t(x.BufferSize) - - return nil + x.SampleRates = nil +if n := int(xc.num_sample_rates); n > 0 { +cSampleRates := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:n:n] +x.SampleRates = make([]uint32, n) +for i, v := range cSampleRates { +x.SampleRates[i] = uint32(v) +} +} +x.SampleFormats = nil +if n := int(xc.num_sample_formats); n > 0 { +cSampleFormats := (*[1<<28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:n:n] +x.SampleFormats = make([]VsndPcmFormat, n) +for i, v := range cSampleFormats { +x.SampleFormats[i] = VsndPcmFormat(v) +} +} +x.ChannelsMin = uint32(xc.channels_min) +x.ChannelsMax = uint32(xc.channels_max) +x.BufferSize = uint32(xc.buffer_size) + + return nil} + +func (x *VsndParams) toC(xc *C.libxl_vsnd_params) (err error){defer func(){ +if err != nil{ +C.libxl_vsnd_params_dispose(xc)} +}() + +if numSampleRates := len(x.SampleRates); numSampleRates > 0 { +xc.sample_rates = (*C.uint32_t)(C.malloc(C.size_t(numSampleRates*numSampleRates))) +xc.num_sample_rates = C.int(numSampleRates) +cSampleRates := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.sample_rates))[:numSampleRates:numSampleRates] +for i,v := range x.SampleRates { +cSampleRates[i] = C.uint32_t(v) +} } +if numSampleFormats := len(x.SampleFormats); numSampleFormats > 0 { +xc.sample_formats = (*C.libxl_vsnd_pcm_format)(C.malloc(C.size_t(numSampleFormats*numSampleFormats))) +xc.num_sample_formats = C.int(numSampleFormats) +cSampleFormats := (*[1<<28]C.libxl_vsnd_pcm_format)(unsafe.Pointer(xc.sample_formats))[:numSampleFormats:numSampleFormats] +for i,v := range x.SampleFormats { +cSampleFormats[i] = C.libxl_vsnd_pcm_format(v) +} +} +xc.channels_min = C.uint32_t(x.ChannelsMin) +xc.channels_max = C.uint32_t(x.ChannelsMax) +xc.buffer_size = C.uint32_t(x.BufferSize) + + return nil + } // NewVsndStream returns an instance of VsndStream initialized with defaults. func NewVsndStream() (*VsndStream, error) { - var ( - x VsndStream - xc C.libxl_vsnd_stream - ) +var ( +x VsndStream +xc C.libxl_vsnd_stream) - C.libxl_vsnd_stream_init(&xc) - defer C.libxl_vsnd_stream_dispose(&xc) +C.libxl_vsnd_stream_init(&xc) +defer C.libxl_vsnd_stream_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *VsndStream) fromC(xc *C.libxl_vsnd_stream) error { - x.UniqueId = C.GoString(xc.unique_id) - x.Type = VsndStreamType(xc._type) - if err := x.Params.fromC(&xc.params); err != nil { - return fmt.Errorf("converting field Params: %v", err) - } - - return nil + x.UniqueId = C.GoString(xc.unique_id) +x.Type = VsndStreamType(xc._type) +if err := x.Params.fromC(&xc.params);err != nil { +return fmt.Errorf("converting field Params: %v", err) } + + return nil} -func (x *VsndStream) toC(xc *C.libxl_vsnd_stream) (err error) { - defer func() { - if err != nil { - C.libxl_vsnd_stream_dispose(xc) - } - }() - - if x.UniqueId != "" { - xc.unique_id = C.CString(x.UniqueId) - } - xc._type = C.libxl_vsnd_stream_type(x.Type) - if err := x.Params.toC(&xc.params); err != nil { - return fmt.Errorf("converting field Params: %v", err) - } +func (x *VsndStream) toC(xc *C.libxl_vsnd_stream) (err error){defer func(){ +if err != nil{ +C.libxl_vsnd_stream_dispose(xc)} +}() - return nil +if x.UniqueId != "" { +xc.unique_id = C.CString(x.UniqueId)} +xc._type = C.libxl_vsnd_stream_type(x.Type) +if err := x.Params.toC(&xc.params); err != nil { +return fmt.Errorf("converting field Params: %v", err) } + return nil + } + // NewVsndPcm returns an instance of VsndPcm initialized with defaults. func NewVsndPcm() (*VsndPcm, error) { - var ( - x VsndPcm - xc C.libxl_vsnd_pcm - ) +var ( +x VsndPcm +xc C.libxl_vsnd_pcm) - C.libxl_vsnd_pcm_init(&xc) - defer C.libxl_vsnd_pcm_dispose(&xc) +C.libxl_vsnd_pcm_init(&xc) +defer C.libxl_vsnd_pcm_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *VsndPcm) fromC(xc *C.libxl_vsnd_pcm) error { - x.Name = C.GoString(xc.name) - if err := x.Params.fromC(&xc.params); err != nil { - return fmt.Errorf("converting field Params: %v", err) - } - x.Streams = nil - if n := int(xc.num_vsnd_streams); n > 0 { - cStreams := (*[1 << 28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:n:n] - x.Streams = make([]VsndStream, n) - for i, v := range cStreams { - if err := x.Streams[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Streams: %v", err) - } - } - } - - return nil -} - -func (x *VsndPcm) toC(xc *C.libxl_vsnd_pcm) (err error) { - defer func() { - if err != nil { - C.libxl_vsnd_pcm_dispose(xc) - } - }() - - if x.Name != "" { - xc.name = C.CString(x.Name) - } - if err := x.Params.toC(&xc.params); err != nil { - return fmt.Errorf("converting field Params: %v", err) - } - if numVsndStreams := len(x.Streams); numVsndStreams > 0 { - xc.streams = (*C.libxl_vsnd_stream)(C.malloc(C.ulong(numVsndStreams) * C.sizeof_libxl_vsnd_stream)) - xc.num_vsnd_streams = C.int(numVsndStreams) - cStreams := (*[1 << 28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams] - for i, v := range x.Streams { - if err := v.toC(&cStreams[i]); err != nil { - return fmt.Errorf("converting field Streams: %v", err) - } - } - } - - return nil + x.Name = C.GoString(xc.name) +if err := x.Params.fromC(&xc.params);err != nil { +return fmt.Errorf("converting field Params: %v", err) +} +x.Streams = nil +if n := int(xc.num_vsnd_streams); n > 0 { +cStreams := (*[1<<28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:n:n] +x.Streams = make([]VsndStream, n) +for i, v := range cStreams { +if err := x.Streams[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Streams: %v", err) } } +} + + return nil} + +func (x *VsndPcm) toC(xc *C.libxl_vsnd_pcm) (err error){defer func(){ +if err != nil{ +C.libxl_vsnd_pcm_dispose(xc)} +}() + +if x.Name != "" { +xc.name = C.CString(x.Name)} +if err := x.Params.toC(&xc.params); err != nil { +return fmt.Errorf("converting field Params: %v", err) +} +if numVsndStreams := len(x.Streams); numVsndStreams > 0 { +xc.streams = (*C.libxl_vsnd_stream)(C.malloc(C.ulong(numVsndStreams)*C.sizeof_libxl_vsnd_stream)) +xc.num_vsnd_streams = C.int(numVsndStreams) +cStreams := (*[1<<28]C.libxl_vsnd_stream)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams] +for i,v := range x.Streams { +if err := v.toC(&cStreams[i]); err != nil { +return fmt.Errorf("converting field Streams: %v", err) +} +} +} + + return nil + } // NewDeviceVsnd returns an instance of DeviceVsnd initialized with defaults. func NewDeviceVsnd() (*DeviceVsnd, error) { - var ( - x DeviceVsnd - xc C.libxl_device_vsnd - ) +var ( +x DeviceVsnd +xc C.libxl_device_vsnd) - C.libxl_device_vsnd_init(&xc) - defer C.libxl_device_vsnd_dispose(&xc) +C.libxl_device_vsnd_init(&xc) +defer C.libxl_device_vsnd_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DeviceVsnd) fromC(xc *C.libxl_device_vsnd) error { - x.BackendDomid = Domid(xc.backend_domid) - x.BackendDomname = C.GoString(xc.backend_domname) - x.Devid = Devid(xc.devid) - x.ShortName = C.GoString(xc.short_name) - x.LongName = C.GoString(xc.long_name) - if err := x.Params.fromC(&xc.params); err != nil { - return fmt.Errorf("converting field Params: %v", err) - } - x.Pcms = nil - if n := int(xc.num_vsnd_pcms); n > 0 { - cPcms := (*[1 << 28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:n:n] - x.Pcms = make([]VsndPcm, n) - for i, v := range cPcms { - if err := x.Pcms[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Pcms: %v", err) - } - } - } - - return nil -} - -func (x *DeviceVsnd) toC(xc *C.libxl_device_vsnd) (err error) { - defer func() { - if err != nil { - C.libxl_device_vsnd_dispose(xc) - } - }() - - xc.backend_domid = C.libxl_domid(x.BackendDomid) - if x.BackendDomname != "" { - xc.backend_domname = C.CString(x.BackendDomname) - } - xc.devid = C.libxl_devid(x.Devid) - if x.ShortName != "" { - xc.short_name = C.CString(x.ShortName) - } - if x.LongName != "" { - xc.long_name = C.CString(x.LongName) - } - if err := x.Params.toC(&xc.params); err != nil { - return fmt.Errorf("converting field Params: %v", err) - } - if numVsndPcms := len(x.Pcms); numVsndPcms > 0 { - xc.pcms = (*C.libxl_vsnd_pcm)(C.malloc(C.ulong(numVsndPcms) * C.sizeof_libxl_vsnd_pcm)) - xc.num_vsnd_pcms = C.int(numVsndPcms) - cPcms := (*[1 << 28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms] - for i, v := range x.Pcms { - if err := v.toC(&cPcms[i]); err != nil { - return fmt.Errorf("converting field Pcms: %v", err) - } - } - } - - return nil -} + x.BackendDomid = Domid(xc.backend_domid) +x.BackendDomname = C.GoString(xc.backend_domname) +x.Devid = Devid(xc.devid) +x.ShortName = C.GoString(xc.short_name) +x.LongName = C.GoString(xc.long_name) +if err := x.Params.fromC(&xc.params);err != nil { +return fmt.Errorf("converting field Params: %v", err) +} +x.Pcms = nil +if n := int(xc.num_vsnd_pcms); n > 0 { +cPcms := (*[1<<28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:n:n] +x.Pcms = make([]VsndPcm, n) +for i, v := range cPcms { +if err := x.Pcms[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Pcms: %v", err) } +} +} + + return nil} + +func (x *DeviceVsnd) toC(xc *C.libxl_device_vsnd) (err error){defer func(){ +if err != nil{ +C.libxl_device_vsnd_dispose(xc)} +}() + +xc.backend_domid = C.libxl_domid(x.BackendDomid) +if x.BackendDomname != "" { +xc.backend_domname = C.CString(x.BackendDomname)} +xc.devid = C.libxl_devid(x.Devid) +if x.ShortName != "" { +xc.short_name = C.CString(x.ShortName)} +if x.LongName != "" { +xc.long_name = C.CString(x.LongName)} +if err := x.Params.toC(&xc.params); err != nil { +return fmt.Errorf("converting field Params: %v", err) +} +if numVsndPcms := len(x.Pcms); numVsndPcms > 0 { +xc.pcms = (*C.libxl_vsnd_pcm)(C.malloc(C.ulong(numVsndPcms)*C.sizeof_libxl_vsnd_pcm)) +xc.num_vsnd_pcms = C.int(numVsndPcms) +cPcms := (*[1<<28]C.libxl_vsnd_pcm)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms] +for i,v := range x.Pcms { +if err := v.toC(&cPcms[i]); err != nil { +return fmt.Errorf("converting field Pcms: %v", err) +} +} +} + + return nil + } // NewDomainConfig returns an instance of DomainConfig initialized with defaults. func NewDomainConfig() (*DomainConfig, error) { - var ( - x DomainConfig - xc C.libxl_domain_config - ) +var ( +x DomainConfig +xc C.libxl_domain_config) - C.libxl_domain_config_init(&xc) - defer C.libxl_domain_config_dispose(&xc) +C.libxl_domain_config_init(&xc) +defer C.libxl_domain_config_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DomainConfig) fromC(xc *C.libxl_domain_config) error { - if err := x.CInfo.fromC(&xc.c_info); err != nil { - return fmt.Errorf("converting field CInfo: %v", err) - } - if err := x.BInfo.fromC(&xc.b_info); err != nil { - return fmt.Errorf("converting field BInfo: %v", err) - } - x.Disks = nil - if n := int(xc.num_disks); n > 0 { - cDisks := (*[1 << 28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:n:n] - x.Disks = make([]DeviceDisk, n) - for i, v := range cDisks { - if err := x.Disks[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Disks: %v", err) - } - } - } - x.Nics = nil - if n := int(xc.num_nics); n > 0 { - cNics := (*[1 << 28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:n:n] - x.Nics = make([]DeviceNic, n) - for i, v := range cNics { - if err := x.Nics[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Nics: %v", err) - } - } - } - x.Pcidevs = nil - if n := int(xc.num_pcidevs); n > 0 { - cPcidevs := (*[1 << 28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:n:n] - x.Pcidevs = make([]DevicePci, n) - for i, v := range cPcidevs { - if err := x.Pcidevs[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Pcidevs: %v", err) - } - } - } - x.Rdms = nil - if n := int(xc.num_rdms); n > 0 { - cRdms := (*[1 << 28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:n:n] - x.Rdms = make([]DeviceRdm, n) - for i, v := range cRdms { - if err := x.Rdms[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Rdms: %v", err) - } - } - } - x.Dtdevs = nil - if n := int(xc.num_dtdevs); n > 0 { - cDtdevs := (*[1 << 28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:n:n] - x.Dtdevs = make([]DeviceDtdev, n) - for i, v := range cDtdevs { - if err := x.Dtdevs[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Dtdevs: %v", err) - } - } - } - x.Vfbs = nil - if n := int(xc.num_vfbs); n > 0 { - cVfbs := (*[1 << 28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:n:n] - x.Vfbs = make([]DeviceVfb, n) - for i, v := range cVfbs { - if err := x.Vfbs[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Vfbs: %v", err) - } - } - } - x.Vkbs = nil - if n := int(xc.num_vkbs); n > 0 { - cVkbs := (*[1 << 28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:n:n] - x.Vkbs = make([]DeviceVkb, n) - for i, v := range cVkbs { - if err := x.Vkbs[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Vkbs: %v", err) - } - } - } - x.Vtpms = nil - if n := int(xc.num_vtpms); n > 0 { - cVtpms := (*[1 << 28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:n:n] - x.Vtpms = make([]DeviceVtpm, n) - for i, v := range cVtpms { - if err := x.Vtpms[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Vtpms: %v", err) - } - } - } - x.P9S = nil - if n := int(xc.num_p9s); n > 0 { - cP9S := (*[1 << 28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:n:n] - x.P9S = make([]DeviceP9, n) - for i, v := range cP9S { - if err := x.P9S[i].fromC(&v); err != nil { - return fmt.Errorf("converting field P9S: %v", err) - } - } - } - x.Pvcallsifs = nil - if n := int(xc.num_pvcallsifs); n > 0 { - cPvcallsifs := (*[1 << 28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:n:n] - x.Pvcallsifs = make([]DevicePvcallsif, n) - for i, v := range cPvcallsifs { - if err := x.Pvcallsifs[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Pvcallsifs: %v", err) - } - } - } - x.Vdispls = nil - if n := int(xc.num_vdispls); n > 0 { - cVdispls := (*[1 << 28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:n:n] - x.Vdispls = make([]DeviceVdispl, n) - for i, v := range cVdispls { - if err := x.Vdispls[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Vdispls: %v", err) - } - } - } - x.Vsnds = nil - if n := int(xc.num_vsnds); n > 0 { - cVsnds := (*[1 << 28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:n:n] - x.Vsnds = make([]DeviceVsnd, n) - for i, v := range cVsnds { - if err := x.Vsnds[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Vsnds: %v", err) - } - } - } - x.Channels = nil - if n := int(xc.num_channels); n > 0 { - cChannels := (*[1 << 28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:n:n] - x.Channels = make([]DeviceChannel, n) - for i, v := range cChannels { - if err := x.Channels[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Channels: %v", err) - } - } - } - x.Usbctrls = nil - if n := int(xc.num_usbctrls); n > 0 { - cUsbctrls := (*[1 << 28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:n:n] - x.Usbctrls = make([]DeviceUsbctrl, n) - for i, v := range cUsbctrls { - if err := x.Usbctrls[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Usbctrls: %v", err) - } - } - } - x.Usbdevs = nil - if n := int(xc.num_usbdevs); n > 0 { - cUsbdevs := (*[1 << 28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:n:n] - x.Usbdevs = make([]DeviceUsbdev, n) - for i, v := range cUsbdevs { - if err := x.Usbdevs[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Usbdevs: %v", err) - } - } - } - x.OnPoweroff = ActionOnShutdown(xc.on_poweroff) - x.OnReboot = ActionOnShutdown(xc.on_reboot) - x.OnWatchdog = ActionOnShutdown(xc.on_watchdog) - x.OnCrash = ActionOnShutdown(xc.on_crash) - x.OnSoftReset = ActionOnShutdown(xc.on_soft_reset) - - return nil -} - -func (x *DomainConfig) toC(xc *C.libxl_domain_config) (err error) { - defer func() { - if err != nil { - C.libxl_domain_config_dispose(xc) - } - }() - - if err := x.CInfo.toC(&xc.c_info); err != nil { - return fmt.Errorf("converting field CInfo: %v", err) - } - if err := x.BInfo.toC(&xc.b_info); err != nil { - return fmt.Errorf("converting field BInfo: %v", err) - } - if numDisks := len(x.Disks); numDisks > 0 { - xc.disks = (*C.libxl_device_disk)(C.malloc(C.ulong(numDisks) * C.sizeof_libxl_device_disk)) - xc.num_disks = C.int(numDisks) - cDisks := (*[1 << 28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:numDisks:numDisks] - for i, v := range x.Disks { - if err := v.toC(&cDisks[i]); err != nil { - return fmt.Errorf("converting field Disks: %v", err) - } - } - } - if numNics := len(x.Nics); numNics > 0 { - xc.nics = (*C.libxl_device_nic)(C.malloc(C.ulong(numNics) * C.sizeof_libxl_device_nic)) - xc.num_nics = C.int(numNics) - cNics := (*[1 << 28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:numNics:numNics] - for i, v := range x.Nics { - if err := v.toC(&cNics[i]); err != nil { - return fmt.Errorf("converting field Nics: %v", err) - } - } - } - if numPcidevs := len(x.Pcidevs); numPcidevs > 0 { - xc.pcidevs = (*C.libxl_device_pci)(C.malloc(C.ulong(numPcidevs) * C.sizeof_libxl_device_pci)) - xc.num_pcidevs = C.int(numPcidevs) - cPcidevs := (*[1 << 28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:numPcidevs:numPcidevs] - for i, v := range x.Pcidevs { - if err := v.toC(&cPcidevs[i]); err != nil { - return fmt.Errorf("converting field Pcidevs: %v", err) - } - } - } - if numRdms := len(x.Rdms); numRdms > 0 { - xc.rdms = (*C.libxl_device_rdm)(C.malloc(C.ulong(numRdms) * C.sizeof_libxl_device_rdm)) - xc.num_rdms = C.int(numRdms) - cRdms := (*[1 << 28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:numRdms:numRdms] - for i, v := range x.Rdms { - if err := v.toC(&cRdms[i]); err != nil { - return fmt.Errorf("converting field Rdms: %v", err) - } - } - } - if numDtdevs := len(x.Dtdevs); numDtdevs > 0 { - xc.dtdevs = (*C.libxl_device_dtdev)(C.malloc(C.ulong(numDtdevs) * C.sizeof_libxl_device_dtdev)) - xc.num_dtdevs = C.int(numDtdevs) - cDtdevs := (*[1 << 28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:numDtdevs:numDtdevs] - for i, v := range x.Dtdevs { - if err := v.toC(&cDtdevs[i]); err != nil { - return fmt.Errorf("converting field Dtdevs: %v", err) - } - } - } - if numVfbs := len(x.Vfbs); numVfbs > 0 { - xc.vfbs = (*C.libxl_device_vfb)(C.malloc(C.ulong(numVfbs) * C.sizeof_libxl_device_vfb)) - xc.num_vfbs = C.int(numVfbs) - cVfbs := (*[1 << 28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:numVfbs:numVfbs] - for i, v := range x.Vfbs { - if err := v.toC(&cVfbs[i]); err != nil { - return fmt.Errorf("converting field Vfbs: %v", err) - } - } - } - if numVkbs := len(x.Vkbs); numVkbs > 0 { - xc.vkbs = (*C.libxl_device_vkb)(C.malloc(C.ulong(numVkbs) * C.sizeof_libxl_device_vkb)) - xc.num_vkbs = C.int(numVkbs) - cVkbs := (*[1 << 28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:numVkbs:numVkbs] - for i, v := range x.Vkbs { - if err := v.toC(&cVkbs[i]); err != nil { - return fmt.Errorf("converting field Vkbs: %v", err) - } - } - } - if numVtpms := len(x.Vtpms); numVtpms > 0 { - xc.vtpms = (*C.libxl_device_vtpm)(C.malloc(C.ulong(numVtpms) * C.sizeof_libxl_device_vtpm)) - xc.num_vtpms = C.int(numVtpms) - cVtpms := (*[1 << 28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:numVtpms:numVtpms] - for i, v := range x.Vtpms { - if err := v.toC(&cVtpms[i]); err != nil { - return fmt.Errorf("converting field Vtpms: %v", err) - } - } - } - if numP9S := len(x.P9S); numP9S > 0 { - xc.p9s = (*C.libxl_device_p9)(C.malloc(C.ulong(numP9S) * C.sizeof_libxl_device_p9)) - xc.num_p9s = C.int(numP9S) - cP9S := (*[1 << 28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:numP9S:numP9S] - for i, v := range x.P9S { - if err := v.toC(&cP9S[i]); err != nil { - return fmt.Errorf("converting field P9S: %v", err) - } - } - } - if numPvcallsifs := len(x.Pvcallsifs); numPvcallsifs > 0 { - xc.pvcallsifs = (*C.libxl_device_pvcallsif)(C.malloc(C.ulong(numPvcallsifs) * C.sizeof_libxl_device_pvcallsif)) - xc.num_pvcallsifs = C.int(numPvcallsifs) - cPvcallsifs := (*[1 << 28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:numPvcallsifs:numPvcallsifs] - for i, v := range x.Pvcallsifs { - if err := v.toC(&cPvcallsifs[i]); err != nil { - return fmt.Errorf("converting field Pvcallsifs: %v", err) - } - } - } - if numVdispls := len(x.Vdispls); numVdispls > 0 { - xc.vdispls = (*C.libxl_device_vdispl)(C.malloc(C.ulong(numVdispls) * C.sizeof_libxl_device_vdispl)) - xc.num_vdispls = C.int(numVdispls) - cVdispls := (*[1 << 28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:numVdispls:numVdispls] - for i, v := range x.Vdispls { - if err := v.toC(&cVdispls[i]); err != nil { - return fmt.Errorf("converting field Vdispls: %v", err) - } - } - } - if numVsnds := len(x.Vsnds); numVsnds > 0 { - xc.vsnds = (*C.libxl_device_vsnd)(C.malloc(C.ulong(numVsnds) * C.sizeof_libxl_device_vsnd)) - xc.num_vsnds = C.int(numVsnds) - cVsnds := (*[1 << 28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:numVsnds:numVsnds] - for i, v := range x.Vsnds { - if err := v.toC(&cVsnds[i]); err != nil { - return fmt.Errorf("converting field Vsnds: %v", err) - } - } - } - if numChannels := len(x.Channels); numChannels > 0 { - xc.channels = (*C.libxl_device_channel)(C.malloc(C.ulong(numChannels) * C.sizeof_libxl_device_channel)) - xc.num_channels = C.int(numChannels) - cChannels := (*[1 << 28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:numChannels:numChannels] - for i, v := range x.Channels { - if err := v.toC(&cChannels[i]); err != nil { - return fmt.Errorf("converting field Channels: %v", err) - } - } - } - if numUsbctrls := len(x.Usbctrls); numUsbctrls > 0 { - xc.usbctrls = (*C.libxl_device_usbctrl)(C.malloc(C.ulong(numUsbctrls) * C.sizeof_libxl_device_usbctrl)) - xc.num_usbctrls = C.int(numUsbctrls) - cUsbctrls := (*[1 << 28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:numUsbctrls:numUsbctrls] - for i, v := range x.Usbctrls { - if err := v.toC(&cUsbctrls[i]); err != nil { - return fmt.Errorf("converting field Usbctrls: %v", err) - } - } - } - if numUsbdevs := len(x.Usbdevs); numUsbdevs > 0 { - xc.usbdevs = (*C.libxl_device_usbdev)(C.malloc(C.ulong(numUsbdevs) * C.sizeof_libxl_device_usbdev)) - xc.num_usbdevs = C.int(numUsbdevs) - cUsbdevs := (*[1 << 28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:numUsbdevs:numUsbdevs] - for i, v := range x.Usbdevs { - if err := v.toC(&cUsbdevs[i]); err != nil { - return fmt.Errorf("converting field Usbdevs: %v", err) - } - } - } - xc.on_poweroff = C.libxl_action_on_shutdown(x.OnPoweroff) - xc.on_reboot = C.libxl_action_on_shutdown(x.OnReboot) - xc.on_watchdog = C.libxl_action_on_shutdown(x.OnWatchdog) - xc.on_crash = C.libxl_action_on_shutdown(x.OnCrash) - xc.on_soft_reset = C.libxl_action_on_shutdown(x.OnSoftReset) - - return nil + if err := x.CInfo.fromC(&xc.c_info);err != nil { +return fmt.Errorf("converting field CInfo: %v", err) +} +if err := x.BInfo.fromC(&xc.b_info);err != nil { +return fmt.Errorf("converting field BInfo: %v", err) +} +x.Disks = nil +if n := int(xc.num_disks); n > 0 { +cDisks := (*[1<<28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:n:n] +x.Disks = make([]DeviceDisk, n) +for i, v := range cDisks { +if err := x.Disks[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Disks: %v", err) } +} +} +x.Nics = nil +if n := int(xc.num_nics); n > 0 { +cNics := (*[1<<28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:n:n] +x.Nics = make([]DeviceNic, n) +for i, v := range cNics { +if err := x.Nics[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Nics: %v", err) } +} +} +x.Pcidevs = nil +if n := int(xc.num_pcidevs); n > 0 { +cPcidevs := (*[1<<28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:n:n] +x.Pcidevs = make([]DevicePci, n) +for i, v := range cPcidevs { +if err := x.Pcidevs[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Pcidevs: %v", err) } +} +} +x.Rdms = nil +if n := int(xc.num_rdms); n > 0 { +cRdms := (*[1<<28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:n:n] +x.Rdms = make([]DeviceRdm, n) +for i, v := range cRdms { +if err := x.Rdms[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Rdms: %v", err) } +} +} +x.Dtdevs = nil +if n := int(xc.num_dtdevs); n > 0 { +cDtdevs := (*[1<<28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:n:n] +x.Dtdevs = make([]DeviceDtdev, n) +for i, v := range cDtdevs { +if err := x.Dtdevs[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Dtdevs: %v", err) } +} +} +x.Vfbs = nil +if n := int(xc.num_vfbs); n > 0 { +cVfbs := (*[1<<28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:n:n] +x.Vfbs = make([]DeviceVfb, n) +for i, v := range cVfbs { +if err := x.Vfbs[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Vfbs: %v", err) } +} +} +x.Vkbs = nil +if n := int(xc.num_vkbs); n > 0 { +cVkbs := (*[1<<28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:n:n] +x.Vkbs = make([]DeviceVkb, n) +for i, v := range cVkbs { +if err := x.Vkbs[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Vkbs: %v", err) } +} +} +x.Vtpms = nil +if n := int(xc.num_vtpms); n > 0 { +cVtpms := (*[1<<28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:n:n] +x.Vtpms = make([]DeviceVtpm, n) +for i, v := range cVtpms { +if err := x.Vtpms[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Vtpms: %v", err) } +} +} +x.P9S = nil +if n := int(xc.num_p9s); n > 0 { +cP9S := (*[1<<28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:n:n] +x.P9S = make([]DeviceP9, n) +for i, v := range cP9S { +if err := x.P9S[i].fromC(&v); err != nil { +return fmt.Errorf("converting field P9S: %v", err) } +} +} +x.Pvcallsifs = nil +if n := int(xc.num_pvcallsifs); n > 0 { +cPvcallsifs := (*[1<<28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:n:n] +x.Pvcallsifs = make([]DevicePvcallsif, n) +for i, v := range cPvcallsifs { +if err := x.Pvcallsifs[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Pvcallsifs: %v", err) } +} +} +x.Vdispls = nil +if n := int(xc.num_vdispls); n > 0 { +cVdispls := (*[1<<28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:n:n] +x.Vdispls = make([]DeviceVdispl, n) +for i, v := range cVdispls { +if err := x.Vdispls[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Vdispls: %v", err) } +} +} +x.Vsnds = nil +if n := int(xc.num_vsnds); n > 0 { +cVsnds := (*[1<<28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:n:n] +x.Vsnds = make([]DeviceVsnd, n) +for i, v := range cVsnds { +if err := x.Vsnds[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Vsnds: %v", err) } +} +} +x.Channels = nil +if n := int(xc.num_channels); n > 0 { +cChannels := (*[1<<28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:n:n] +x.Channels = make([]DeviceChannel, n) +for i, v := range cChannels { +if err := x.Channels[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Channels: %v", err) } +} +} +x.Usbctrls = nil +if n := int(xc.num_usbctrls); n > 0 { +cUsbctrls := (*[1<<28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:n:n] +x.Usbctrls = make([]DeviceUsbctrl, n) +for i, v := range cUsbctrls { +if err := x.Usbctrls[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Usbctrls: %v", err) } +} +} +x.Usbdevs = nil +if n := int(xc.num_usbdevs); n > 0 { +cUsbdevs := (*[1<<28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:n:n] +x.Usbdevs = make([]DeviceUsbdev, n) +for i, v := range cUsbdevs { +if err := x.Usbdevs[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Usbdevs: %v", err) } +} +} +x.OnPoweroff = ActionOnShutdown(xc.on_poweroff) +x.OnReboot = ActionOnShutdown(xc.on_reboot) +x.OnWatchdog = ActionOnShutdown(xc.on_watchdog) +x.OnCrash = ActionOnShutdown(xc.on_crash) +x.OnSoftReset = ActionOnShutdown(xc.on_soft_reset) + + return nil} + +func (x *DomainConfig) toC(xc *C.libxl_domain_config) (err error){defer func(){ +if err != nil{ +C.libxl_domain_config_dispose(xc)} +}() + +if err := x.CInfo.toC(&xc.c_info); err != nil { +return fmt.Errorf("converting field CInfo: %v", err) +} +if err := x.BInfo.toC(&xc.b_info); err != nil { +return fmt.Errorf("converting field BInfo: %v", err) +} +if numDisks := len(x.Disks); numDisks > 0 { +xc.disks = (*C.libxl_device_disk)(C.malloc(C.ulong(numDisks)*C.sizeof_libxl_device_disk)) +xc.num_disks = C.int(numDisks) +cDisks := (*[1<<28]C.libxl_device_disk)(unsafe.Pointer(xc.disks))[:numDisks:numDisks] +for i,v := range x.Disks { +if err := v.toC(&cDisks[i]); err != nil { +return fmt.Errorf("converting field Disks: %v", err) +} +} } +if numNics := len(x.Nics); numNics > 0 { +xc.nics = (*C.libxl_device_nic)(C.malloc(C.ulong(numNics)*C.sizeof_libxl_device_nic)) +xc.num_nics = C.int(numNics) +cNics := (*[1<<28]C.libxl_device_nic)(unsafe.Pointer(xc.nics))[:numNics:numNics] +for i,v := range x.Nics { +if err := v.toC(&cNics[i]); err != nil { +return fmt.Errorf("converting field Nics: %v", err) +} +} +} +if numPcidevs := len(x.Pcidevs); numPcidevs > 0 { +xc.pcidevs = (*C.libxl_device_pci)(C.malloc(C.ulong(numPcidevs)*C.sizeof_libxl_device_pci)) +xc.num_pcidevs = C.int(numPcidevs) +cPcidevs := (*[1<<28]C.libxl_device_pci)(unsafe.Pointer(xc.pcidevs))[:numPcidevs:numPcidevs] +for i,v := range x.Pcidevs { +if err := v.toC(&cPcidevs[i]); err != nil { +return fmt.Errorf("converting field Pcidevs: %v", err) +} +} +} +if numRdms := len(x.Rdms); numRdms > 0 { +xc.rdms = (*C.libxl_device_rdm)(C.malloc(C.ulong(numRdms)*C.sizeof_libxl_device_rdm)) +xc.num_rdms = C.int(numRdms) +cRdms := (*[1<<28]C.libxl_device_rdm)(unsafe.Pointer(xc.rdms))[:numRdms:numRdms] +for i,v := range x.Rdms { +if err := v.toC(&cRdms[i]); err != nil { +return fmt.Errorf("converting field Rdms: %v", err) +} +} +} +if numDtdevs := len(x.Dtdevs); numDtdevs > 0 { +xc.dtdevs = (*C.libxl_device_dtdev)(C.malloc(C.ulong(numDtdevs)*C.sizeof_libxl_device_dtdev)) +xc.num_dtdevs = C.int(numDtdevs) +cDtdevs := (*[1<<28]C.libxl_device_dtdev)(unsafe.Pointer(xc.dtdevs))[:numDtdevs:numDtdevs] +for i,v := range x.Dtdevs { +if err := v.toC(&cDtdevs[i]); err != nil { +return fmt.Errorf("converting field Dtdevs: %v", err) +} +} +} +if numVfbs := len(x.Vfbs); numVfbs > 0 { +xc.vfbs = (*C.libxl_device_vfb)(C.malloc(C.ulong(numVfbs)*C.sizeof_libxl_device_vfb)) +xc.num_vfbs = C.int(numVfbs) +cVfbs := (*[1<<28]C.libxl_device_vfb)(unsafe.Pointer(xc.vfbs))[:numVfbs:numVfbs] +for i,v := range x.Vfbs { +if err := v.toC(&cVfbs[i]); err != nil { +return fmt.Errorf("converting field Vfbs: %v", err) +} +} +} +if numVkbs := len(x.Vkbs); numVkbs > 0 { +xc.vkbs = (*C.libxl_device_vkb)(C.malloc(C.ulong(numVkbs)*C.sizeof_libxl_device_vkb)) +xc.num_vkbs = C.int(numVkbs) +cVkbs := (*[1<<28]C.libxl_device_vkb)(unsafe.Pointer(xc.vkbs))[:numVkbs:numVkbs] +for i,v := range x.Vkbs { +if err := v.toC(&cVkbs[i]); err != nil { +return fmt.Errorf("converting field Vkbs: %v", err) +} +} +} +if numVtpms := len(x.Vtpms); numVtpms > 0 { +xc.vtpms = (*C.libxl_device_vtpm)(C.malloc(C.ulong(numVtpms)*C.sizeof_libxl_device_vtpm)) +xc.num_vtpms = C.int(numVtpms) +cVtpms := (*[1<<28]C.libxl_device_vtpm)(unsafe.Pointer(xc.vtpms))[:numVtpms:numVtpms] +for i,v := range x.Vtpms { +if err := v.toC(&cVtpms[i]); err != nil { +return fmt.Errorf("converting field Vtpms: %v", err) +} +} +} +if numP9S := len(x.P9S); numP9S > 0 { +xc.p9s = (*C.libxl_device_p9)(C.malloc(C.ulong(numP9S)*C.sizeof_libxl_device_p9)) +xc.num_p9s = C.int(numP9S) +cP9S := (*[1<<28]C.libxl_device_p9)(unsafe.Pointer(xc.p9s))[:numP9S:numP9S] +for i,v := range x.P9S { +if err := v.toC(&cP9S[i]); err != nil { +return fmt.Errorf("converting field P9S: %v", err) +} +} +} +if numPvcallsifs := len(x.Pvcallsifs); numPvcallsifs > 0 { +xc.pvcallsifs = (*C.libxl_device_pvcallsif)(C.malloc(C.ulong(numPvcallsifs)*C.sizeof_libxl_device_pvcallsif)) +xc.num_pvcallsifs = C.int(numPvcallsifs) +cPvcallsifs := (*[1<<28]C.libxl_device_pvcallsif)(unsafe.Pointer(xc.pvcallsifs))[:numPvcallsifs:numPvcallsifs] +for i,v := range x.Pvcallsifs { +if err := v.toC(&cPvcallsifs[i]); err != nil { +return fmt.Errorf("converting field Pvcallsifs: %v", err) +} +} +} +if numVdispls := len(x.Vdispls); numVdispls > 0 { +xc.vdispls = (*C.libxl_device_vdispl)(C.malloc(C.ulong(numVdispls)*C.sizeof_libxl_device_vdispl)) +xc.num_vdispls = C.int(numVdispls) +cVdispls := (*[1<<28]C.libxl_device_vdispl)(unsafe.Pointer(xc.vdispls))[:numVdispls:numVdispls] +for i,v := range x.Vdispls { +if err := v.toC(&cVdispls[i]); err != nil { +return fmt.Errorf("converting field Vdispls: %v", err) +} +} +} +if numVsnds := len(x.Vsnds); numVsnds > 0 { +xc.vsnds = (*C.libxl_device_vsnd)(C.malloc(C.ulong(numVsnds)*C.sizeof_libxl_device_vsnd)) +xc.num_vsnds = C.int(numVsnds) +cVsnds := (*[1<<28]C.libxl_device_vsnd)(unsafe.Pointer(xc.vsnds))[:numVsnds:numVsnds] +for i,v := range x.Vsnds { +if err := v.toC(&cVsnds[i]); err != nil { +return fmt.Errorf("converting field Vsnds: %v", err) +} +} +} +if numChannels := len(x.Channels); numChannels > 0 { +xc.channels = (*C.libxl_device_channel)(C.malloc(C.ulong(numChannels)*C.sizeof_libxl_device_channel)) +xc.num_channels = C.int(numChannels) +cChannels := (*[1<<28]C.libxl_device_channel)(unsafe.Pointer(xc.channels))[:numChannels:numChannels] +for i,v := range x.Channels { +if err := v.toC(&cChannels[i]); err != nil { +return fmt.Errorf("converting field Channels: %v", err) +} +} +} +if numUsbctrls := len(x.Usbctrls); numUsbctrls > 0 { +xc.usbctrls = (*C.libxl_device_usbctrl)(C.malloc(C.ulong(numUsbctrls)*C.sizeof_libxl_device_usbctrl)) +xc.num_usbctrls = C.int(numUsbctrls) +cUsbctrls := (*[1<<28]C.libxl_device_usbctrl)(unsafe.Pointer(xc.usbctrls))[:numUsbctrls:numUsbctrls] +for i,v := range x.Usbctrls { +if err := v.toC(&cUsbctrls[i]); err != nil { +return fmt.Errorf("converting field Usbctrls: %v", err) +} +} +} +if numUsbdevs := len(x.Usbdevs); numUsbdevs > 0 { +xc.usbdevs = (*C.libxl_device_usbdev)(C.malloc(C.ulong(numUsbdevs)*C.sizeof_libxl_device_usbdev)) +xc.num_usbdevs = C.int(numUsbdevs) +cUsbdevs := (*[1<<28]C.libxl_device_usbdev)(unsafe.Pointer(xc.usbdevs))[:numUsbdevs:numUsbdevs] +for i,v := range x.Usbdevs { +if err := v.toC(&cUsbdevs[i]); err != nil { +return fmt.Errorf("converting field Usbdevs: %v", err) +} +} +} +xc.on_poweroff = C.libxl_action_on_shutdown(x.OnPoweroff) +xc.on_reboot = C.libxl_action_on_shutdown(x.OnReboot) +xc.on_watchdog = C.libxl_action_on_shutdown(x.OnWatchdog) +xc.on_crash = C.libxl_action_on_shutdown(x.OnCrash) +xc.on_soft_reset = C.libxl_action_on_shutdown(x.OnSoftReset) + + return nil + } // NewDiskinfo returns an instance of Diskinfo initialized with defaults. func NewDiskinfo() (*Diskinfo, error) { - var ( - x Diskinfo - xc C.libxl_diskinfo - ) +var ( +x Diskinfo +xc C.libxl_diskinfo) - C.libxl_diskinfo_init(&xc) - defer C.libxl_diskinfo_dispose(&xc) +C.libxl_diskinfo_init(&xc) +defer C.libxl_diskinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Diskinfo) fromC(xc *C.libxl_diskinfo) error { - x.Backend = C.GoString(xc.backend) - x.BackendId = uint32(xc.backend_id) - x.Frontend = C.GoString(xc.frontend) - x.FrontendId = uint32(xc.frontend_id) - x.Devid = Devid(xc.devid) - x.State = int(xc.state) - x.Evtch = int(xc.evtch) - x.Rref = int(xc.rref) - - return nil -} - -func (x *Diskinfo) toC(xc *C.libxl_diskinfo) (err error) { - defer func() { - if err != nil { - C.libxl_diskinfo_dispose(xc) - } - }() - - if x.Backend != "" { - xc.backend = C.CString(x.Backend) - } - xc.backend_id = C.uint32_t(x.BackendId) - if x.Frontend != "" { - xc.frontend = C.CString(x.Frontend) - } - xc.frontend_id = C.uint32_t(x.FrontendId) - xc.devid = C.libxl_devid(x.Devid) - xc.state = C.int(x.State) - xc.evtch = C.int(x.Evtch) - xc.rref = C.int(x.Rref) - - return nil -} + x.Backend = C.GoString(xc.backend) +x.BackendId = uint32(xc.backend_id) +x.Frontend = C.GoString(xc.frontend) +x.FrontendId = uint32(xc.frontend_id) +x.Devid = Devid(xc.devid) +x.State = int(xc.state) +x.Evtch = int(xc.evtch) +x.Rref = int(xc.rref) + + return nil} + +func (x *Diskinfo) toC(xc *C.libxl_diskinfo) (err error){defer func(){ +if err != nil{ +C.libxl_diskinfo_dispose(xc)} +}() + +if x.Backend != "" { +xc.backend = C.CString(x.Backend)} +xc.backend_id = C.uint32_t(x.BackendId) +if x.Frontend != "" { +xc.frontend = C.CString(x.Frontend)} +xc.frontend_id = C.uint32_t(x.FrontendId) +xc.devid = C.libxl_devid(x.Devid) +xc.state = C.int(x.State) +xc.evtch = C.int(x.Evtch) +xc.rref = C.int(x.Rref) + + return nil + } // NewNicinfo returns an instance of Nicinfo initialized with defaults. func NewNicinfo() (*Nicinfo, error) { - var ( - x Nicinfo - xc C.libxl_nicinfo - ) +var ( +x Nicinfo +xc C.libxl_nicinfo) - C.libxl_nicinfo_init(&xc) - defer C.libxl_nicinfo_dispose(&xc) +C.libxl_nicinfo_init(&xc) +defer C.libxl_nicinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Nicinfo) fromC(xc *C.libxl_nicinfo) error { - x.Backend = C.GoString(xc.backend) - x.BackendId = uint32(xc.backend_id) - x.Frontend = C.GoString(xc.frontend) - x.FrontendId = uint32(xc.frontend_id) - x.Devid = Devid(xc.devid) - x.State = int(xc.state) - x.Evtch = int(xc.evtch) - x.RrefTx = int(xc.rref_tx) - x.RrefRx = int(xc.rref_rx) - - return nil -} - -func (x *Nicinfo) toC(xc *C.libxl_nicinfo) (err error) { - defer func() { - if err != nil { - C.libxl_nicinfo_dispose(xc) - } - }() - - if x.Backend != "" { - xc.backend = C.CString(x.Backend) - } - xc.backend_id = C.uint32_t(x.BackendId) - if x.Frontend != "" { - xc.frontend = C.CString(x.Frontend) - } - xc.frontend_id = C.uint32_t(x.FrontendId) - xc.devid = C.libxl_devid(x.Devid) - xc.state = C.int(x.State) - xc.evtch = C.int(x.Evtch) - xc.rref_tx = C.int(x.RrefTx) - xc.rref_rx = C.int(x.RrefRx) - - return nil -} + x.Backend = C.GoString(xc.backend) +x.BackendId = uint32(xc.backend_id) +x.Frontend = C.GoString(xc.frontend) +x.FrontendId = uint32(xc.frontend_id) +x.Devid = Devid(xc.devid) +x.State = int(xc.state) +x.Evtch = int(xc.evtch) +x.RrefTx = int(xc.rref_tx) +x.RrefRx = int(xc.rref_rx) + + return nil} + +func (x *Nicinfo) toC(xc *C.libxl_nicinfo) (err error){defer func(){ +if err != nil{ +C.libxl_nicinfo_dispose(xc)} +}() + +if x.Backend != "" { +xc.backend = C.CString(x.Backend)} +xc.backend_id = C.uint32_t(x.BackendId) +if x.Frontend != "" { +xc.frontend = C.CString(x.Frontend)} +xc.frontend_id = C.uint32_t(x.FrontendId) +xc.devid = C.libxl_devid(x.Devid) +xc.state = C.int(x.State) +xc.evtch = C.int(x.Evtch) +xc.rref_tx = C.int(x.RrefTx) +xc.rref_rx = C.int(x.RrefRx) + + return nil + } // NewVtpminfo returns an instance of Vtpminfo initialized with defaults. func NewVtpminfo() (*Vtpminfo, error) { - var ( - x Vtpminfo - xc C.libxl_vtpminfo - ) +var ( +x Vtpminfo +xc C.libxl_vtpminfo) - C.libxl_vtpminfo_init(&xc) - defer C.libxl_vtpminfo_dispose(&xc) +C.libxl_vtpminfo_init(&xc) +defer C.libxl_vtpminfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Vtpminfo) fromC(xc *C.libxl_vtpminfo) error { - x.Backend = C.GoString(xc.backend) - x.BackendId = uint32(xc.backend_id) - x.Frontend = C.GoString(xc.frontend) - x.FrontendId = uint32(xc.frontend_id) - x.Devid = Devid(xc.devid) - x.State = int(xc.state) - x.Evtch = int(xc.evtch) - x.Rref = int(xc.rref) - if err := x.Uuid.fromC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } - - return nil -} - -func (x *Vtpminfo) toC(xc *C.libxl_vtpminfo) (err error) { - defer func() { - if err != nil { - C.libxl_vtpminfo_dispose(xc) - } - }() - - if x.Backend != "" { - xc.backend = C.CString(x.Backend) - } - xc.backend_id = C.uint32_t(x.BackendId) - if x.Frontend != "" { - xc.frontend = C.CString(x.Frontend) - } - xc.frontend_id = C.uint32_t(x.FrontendId) - xc.devid = C.libxl_devid(x.Devid) - xc.state = C.int(x.State) - xc.evtch = C.int(x.Evtch) - xc.rref = C.int(x.Rref) - if err := x.Uuid.toC(&xc.uuid); err != nil { - return fmt.Errorf("converting field Uuid: %v", err) - } - - return nil -} + x.Backend = C.GoString(xc.backend) +x.BackendId = uint32(xc.backend_id) +x.Frontend = C.GoString(xc.frontend) +x.FrontendId = uint32(xc.frontend_id) +x.Devid = Devid(xc.devid) +x.State = int(xc.state) +x.Evtch = int(xc.evtch) +x.Rref = int(xc.rref) +if err := x.Uuid.fromC(&xc.uuid);err != nil { +return fmt.Errorf("converting field Uuid: %v", err) +} + + return nil} + +func (x *Vtpminfo) toC(xc *C.libxl_vtpminfo) (err error){defer func(){ +if err != nil{ +C.libxl_vtpminfo_dispose(xc)} +}() + +if x.Backend != "" { +xc.backend = C.CString(x.Backend)} +xc.backend_id = C.uint32_t(x.BackendId) +if x.Frontend != "" { +xc.frontend = C.CString(x.Frontend)} +xc.frontend_id = C.uint32_t(x.FrontendId) +xc.devid = C.libxl_devid(x.Devid) +xc.state = C.int(x.State) +xc.evtch = C.int(x.Evtch) +xc.rref = C.int(x.Rref) +if err := x.Uuid.toC(&xc.uuid); err != nil { +return fmt.Errorf("converting field Uuid: %v", err) +} + + return nil + } // NewUsbctrlinfo returns an instance of Usbctrlinfo initialized with defaults. func NewUsbctrlinfo() (*Usbctrlinfo, error) { - var ( - x Usbctrlinfo - xc C.libxl_usbctrlinfo - ) +var ( +x Usbctrlinfo +xc C.libxl_usbctrlinfo) - C.libxl_usbctrlinfo_init(&xc) - defer C.libxl_usbctrlinfo_dispose(&xc) +C.libxl_usbctrlinfo_init(&xc) +defer C.libxl_usbctrlinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Usbctrlinfo) fromC(xc *C.libxl_usbctrlinfo) error { - x.Type = UsbctrlType(xc._type) - x.Devid = Devid(xc.devid) - x.Version = int(xc.version) - x.Ports = int(xc.ports) - x.Backend = C.GoString(xc.backend) - x.BackendId = uint32(xc.backend_id) - x.Frontend = C.GoString(xc.frontend) - x.FrontendId = uint32(xc.frontend_id) - x.State = int(xc.state) - x.Evtch = int(xc.evtch) - x.RefUrb = int(xc.ref_urb) - x.RefConn = int(xc.ref_conn) - - return nil -} - -func (x *Usbctrlinfo) toC(xc *C.libxl_usbctrlinfo) (err error) { - defer func() { - if err != nil { - C.libxl_usbctrlinfo_dispose(xc) - } - }() - - xc._type = C.libxl_usbctrl_type(x.Type) - xc.devid = C.libxl_devid(x.Devid) - xc.version = C.int(x.Version) - xc.ports = C.int(x.Ports) - if x.Backend != "" { - xc.backend = C.CString(x.Backend) - } - xc.backend_id = C.uint32_t(x.BackendId) - if x.Frontend != "" { - xc.frontend = C.CString(x.Frontend) - } - xc.frontend_id = C.uint32_t(x.FrontendId) - xc.state = C.int(x.State) - xc.evtch = C.int(x.Evtch) - xc.ref_urb = C.int(x.RefUrb) - xc.ref_conn = C.int(x.RefConn) - - return nil -} + x.Type = UsbctrlType(xc._type) +x.Devid = Devid(xc.devid) +x.Version = int(xc.version) +x.Ports = int(xc.ports) +x.Backend = C.GoString(xc.backend) +x.BackendId = uint32(xc.backend_id) +x.Frontend = C.GoString(xc.frontend) +x.FrontendId = uint32(xc.frontend_id) +x.State = int(xc.state) +x.Evtch = int(xc.evtch) +x.RefUrb = int(xc.ref_urb) +x.RefConn = int(xc.ref_conn) + + return nil} + +func (x *Usbctrlinfo) toC(xc *C.libxl_usbctrlinfo) (err error){defer func(){ +if err != nil{ +C.libxl_usbctrlinfo_dispose(xc)} +}() + +xc._type = C.libxl_usbctrl_type(x.Type) +xc.devid = C.libxl_devid(x.Devid) +xc.version = C.int(x.Version) +xc.ports = C.int(x.Ports) +if x.Backend != "" { +xc.backend = C.CString(x.Backend)} +xc.backend_id = C.uint32_t(x.BackendId) +if x.Frontend != "" { +xc.frontend = C.CString(x.Frontend)} +xc.frontend_id = C.uint32_t(x.FrontendId) +xc.state = C.int(x.State) +xc.evtch = C.int(x.Evtch) +xc.ref_urb = C.int(x.RefUrb) +xc.ref_conn = C.int(x.RefConn) + + return nil + } // NewVcpuinfo returns an instance of Vcpuinfo initialized with defaults. func NewVcpuinfo() (*Vcpuinfo, error) { - var ( - x Vcpuinfo - xc C.libxl_vcpuinfo - ) +var ( +x Vcpuinfo +xc C.libxl_vcpuinfo) - C.libxl_vcpuinfo_init(&xc) - defer C.libxl_vcpuinfo_dispose(&xc) +C.libxl_vcpuinfo_init(&xc) +defer C.libxl_vcpuinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Vcpuinfo) fromC(xc *C.libxl_vcpuinfo) error { - x.Vcpuid = uint32(xc.vcpuid) - x.Cpu = uint32(xc.cpu) - x.Online = bool(xc.online) - x.Blocked = bool(xc.blocked) - x.Running = bool(xc.running) - x.VcpuTime = uint64(xc.vcpu_time) - if err := x.Cpumap.fromC(&xc.cpumap); err != nil { - return fmt.Errorf("converting field Cpumap: %v", err) - } - if err := x.CpumapSoft.fromC(&xc.cpumap_soft); err != nil { - return fmt.Errorf("converting field CpumapSoft: %v", err) - } - - return nil -} - -func (x *Vcpuinfo) toC(xc *C.libxl_vcpuinfo) (err error) { - defer func() { - if err != nil { - C.libxl_vcpuinfo_dispose(xc) - } - }() - - xc.vcpuid = C.uint32_t(x.Vcpuid) - xc.cpu = C.uint32_t(x.Cpu) - xc.online = C.bool(x.Online) - xc.blocked = C.bool(x.Blocked) - xc.running = C.bool(x.Running) - xc.vcpu_time = C.uint64_t(x.VcpuTime) - if err := x.Cpumap.toC(&xc.cpumap); err != nil { - return fmt.Errorf("converting field Cpumap: %v", err) - } - if err := x.CpumapSoft.toC(&xc.cpumap_soft); err != nil { - return fmt.Errorf("converting field CpumapSoft: %v", err) - } - - return nil -} + x.Vcpuid = uint32(xc.vcpuid) +x.Cpu = uint32(xc.cpu) +x.Online = bool(xc.online) +x.Blocked = bool(xc.blocked) +x.Running = bool(xc.running) +x.VcpuTime = uint64(xc.vcpu_time) +if err := x.Cpumap.fromC(&xc.cpumap);err != nil { +return fmt.Errorf("converting field Cpumap: %v", err) +} +if err := x.CpumapSoft.fromC(&xc.cpumap_soft);err != nil { +return fmt.Errorf("converting field CpumapSoft: %v", err) +} + + return nil} + +func (x *Vcpuinfo) toC(xc *C.libxl_vcpuinfo) (err error){defer func(){ +if err != nil{ +C.libxl_vcpuinfo_dispose(xc)} +}() + +xc.vcpuid = C.uint32_t(x.Vcpuid) +xc.cpu = C.uint32_t(x.Cpu) +xc.online = C.bool(x.Online) +xc.blocked = C.bool(x.Blocked) +xc.running = C.bool(x.Running) +xc.vcpu_time = C.uint64_t(x.VcpuTime) +if err := x.Cpumap.toC(&xc.cpumap); err != nil { +return fmt.Errorf("converting field Cpumap: %v", err) +} +if err := x.CpumapSoft.toC(&xc.cpumap_soft); err != nil { +return fmt.Errorf("converting field CpumapSoft: %v", err) +} + + return nil + } // NewPhysinfo returns an instance of Physinfo initialized with defaults. func NewPhysinfo() (*Physinfo, error) { - var ( - x Physinfo - xc C.libxl_physinfo - ) +var ( +x Physinfo +xc C.libxl_physinfo) - C.libxl_physinfo_init(&xc) - defer C.libxl_physinfo_dispose(&xc) +C.libxl_physinfo_init(&xc) +defer C.libxl_physinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Physinfo) fromC(xc *C.libxl_physinfo) error { - x.ThreadsPerCore = uint32(xc.threads_per_core) - x.CoresPerSocket = uint32(xc.cores_per_socket) - x.MaxCpuId = uint32(xc.max_cpu_id) - x.NrCpus = uint32(xc.nr_cpus) - x.CpuKhz = uint32(xc.cpu_khz) - x.TotalPages = uint64(xc.total_pages) - x.FreePages = uint64(xc.free_pages) - x.ScrubPages = uint64(xc.scrub_pages) - x.OutstandingPages = uint64(xc.outstanding_pages) - x.SharingFreedPages = uint64(xc.sharing_freed_pages) - x.SharingUsedFrames = uint64(xc.sharing_used_frames) - x.MaxPossibleMfn = uint64(xc.max_possible_mfn) - x.NrNodes = uint32(xc.nr_nodes) - if err := x.HwCap.fromC(&xc.hw_cap); err != nil { - return fmt.Errorf("converting field HwCap: %v", err) - } - x.CapHvm = bool(xc.cap_hvm) - x.CapPv = bool(xc.cap_pv) - x.CapHvmDirectio = bool(xc.cap_hvm_directio) - x.CapHap = bool(xc.cap_hap) - x.CapShadow = bool(xc.cap_shadow) - x.CapIommuHapPtShare = bool(xc.cap_iommu_hap_pt_share) - - return nil -} - -func (x *Physinfo) toC(xc *C.libxl_physinfo) (err error) { - defer func() { - if err != nil { - C.libxl_physinfo_dispose(xc) - } - }() - - xc.threads_per_core = C.uint32_t(x.ThreadsPerCore) - xc.cores_per_socket = C.uint32_t(x.CoresPerSocket) - xc.max_cpu_id = C.uint32_t(x.MaxCpuId) - xc.nr_cpus = C.uint32_t(x.NrCpus) - xc.cpu_khz = C.uint32_t(x.CpuKhz) - xc.total_pages = C.uint64_t(x.TotalPages) - xc.free_pages = C.uint64_t(x.FreePages) - xc.scrub_pages = C.uint64_t(x.ScrubPages) - xc.outstanding_pages = C.uint64_t(x.OutstandingPages) - xc.sharing_freed_pages = C.uint64_t(x.SharingFreedPages) - xc.sharing_used_frames = C.uint64_t(x.SharingUsedFrames) - xc.max_possible_mfn = C.uint64_t(x.MaxPossibleMfn) - xc.nr_nodes = C.uint32_t(x.NrNodes) - if err := x.HwCap.toC(&xc.hw_cap); err != nil { - return fmt.Errorf("converting field HwCap: %v", err) - } - xc.cap_hvm = C.bool(x.CapHvm) - xc.cap_pv = C.bool(x.CapPv) - xc.cap_hvm_directio = C.bool(x.CapHvmDirectio) - xc.cap_hap = C.bool(x.CapHap) - xc.cap_shadow = C.bool(x.CapShadow) - xc.cap_iommu_hap_pt_share = C.bool(x.CapIommuHapPtShare) - - return nil -} + x.ThreadsPerCore = uint32(xc.threads_per_core) +x.CoresPerSocket = uint32(xc.cores_per_socket) +x.MaxCpuId = uint32(xc.max_cpu_id) +x.NrCpus = uint32(xc.nr_cpus) +x.CpuKhz = uint32(xc.cpu_khz) +x.TotalPages = uint64(xc.total_pages) +x.FreePages = uint64(xc.free_pages) +x.ScrubPages = uint64(xc.scrub_pages) +x.OutstandingPages = uint64(xc.outstanding_pages) +x.SharingFreedPages = uint64(xc.sharing_freed_pages) +x.SharingUsedFrames = uint64(xc.sharing_used_frames) +x.MaxPossibleMfn = uint64(xc.max_possible_mfn) +x.NrNodes = uint32(xc.nr_nodes) +if err := x.HwCap.fromC(&xc.hw_cap);err != nil { +return fmt.Errorf("converting field HwCap: %v", err) +} +x.CapHvm = bool(xc.cap_hvm) +x.CapPv = bool(xc.cap_pv) +x.CapHvmDirectio = bool(xc.cap_hvm_directio) +x.CapHap = bool(xc.cap_hap) +x.CapShadow = bool(xc.cap_shadow) +x.CapIommuHapPtShare = bool(xc.cap_iommu_hap_pt_share) + + return nil} + +func (x *Physinfo) toC(xc *C.libxl_physinfo) (err error){defer func(){ +if err != nil{ +C.libxl_physinfo_dispose(xc)} +}() + +xc.threads_per_core = C.uint32_t(x.ThreadsPerCore) +xc.cores_per_socket = C.uint32_t(x.CoresPerSocket) +xc.max_cpu_id = C.uint32_t(x.MaxCpuId) +xc.nr_cpus = C.uint32_t(x.NrCpus) +xc.cpu_khz = C.uint32_t(x.CpuKhz) +xc.total_pages = C.uint64_t(x.TotalPages) +xc.free_pages = C.uint64_t(x.FreePages) +xc.scrub_pages = C.uint64_t(x.ScrubPages) +xc.outstanding_pages = C.uint64_t(x.OutstandingPages) +xc.sharing_freed_pages = C.uint64_t(x.SharingFreedPages) +xc.sharing_used_frames = C.uint64_t(x.SharingUsedFrames) +xc.max_possible_mfn = C.uint64_t(x.MaxPossibleMfn) +xc.nr_nodes = C.uint32_t(x.NrNodes) +if err := x.HwCap.toC(&xc.hw_cap); err != nil { +return fmt.Errorf("converting field HwCap: %v", err) +} +xc.cap_hvm = C.bool(x.CapHvm) +xc.cap_pv = C.bool(x.CapPv) +xc.cap_hvm_directio = C.bool(x.CapHvmDirectio) +xc.cap_hap = C.bool(x.CapHap) +xc.cap_shadow = C.bool(x.CapShadow) +xc.cap_iommu_hap_pt_share = C.bool(x.CapIommuHapPtShare) + + return nil + } // NewConnectorinfo returns an instance of Connectorinfo initialized with defaults. func NewConnectorinfo() (*Connectorinfo, error) { - var ( - x Connectorinfo - xc C.libxl_connectorinfo - ) +var ( +x Connectorinfo +xc C.libxl_connectorinfo) - C.libxl_connectorinfo_init(&xc) - defer C.libxl_connectorinfo_dispose(&xc) +C.libxl_connectorinfo_init(&xc) +defer C.libxl_connectorinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Connectorinfo) fromC(xc *C.libxl_connectorinfo) error { - x.UniqueId = C.GoString(xc.unique_id) - x.Width = uint32(xc.width) - x.Height = uint32(xc.height) - x.ReqEvtch = int(xc.req_evtch) - x.ReqRref = int(xc.req_rref) - x.EvtEvtch = int(xc.evt_evtch) - x.EvtRref = int(xc.evt_rref) - - return nil -} - -func (x *Connectorinfo) toC(xc *C.libxl_connectorinfo) (err error) { - defer func() { - if err != nil { - C.libxl_connectorinfo_dispose(xc) - } - }() - - if x.UniqueId != "" { - xc.unique_id = C.CString(x.UniqueId) - } - xc.width = C.uint32_t(x.Width) - xc.height = C.uint32_t(x.Height) - xc.req_evtch = C.int(x.ReqEvtch) - xc.req_rref = C.int(x.ReqRref) - xc.evt_evtch = C.int(x.EvtEvtch) - xc.evt_rref = C.int(x.EvtRref) - - return nil -} + x.UniqueId = C.GoString(xc.unique_id) +x.Width = uint32(xc.width) +x.Height = uint32(xc.height) +x.ReqEvtch = int(xc.req_evtch) +x.ReqRref = int(xc.req_rref) +x.EvtEvtch = int(xc.evt_evtch) +x.EvtRref = int(xc.evt_rref) + + return nil} + +func (x *Connectorinfo) toC(xc *C.libxl_connectorinfo) (err error){defer func(){ +if err != nil{ +C.libxl_connectorinfo_dispose(xc)} +}() + +if x.UniqueId != "" { +xc.unique_id = C.CString(x.UniqueId)} +xc.width = C.uint32_t(x.Width) +xc.height = C.uint32_t(x.Height) +xc.req_evtch = C.int(x.ReqEvtch) +xc.req_rref = C.int(x.ReqRref) +xc.evt_evtch = C.int(x.EvtEvtch) +xc.evt_rref = C.int(x.EvtRref) + + return nil + } // NewVdisplinfo returns an instance of Vdisplinfo initialized with defaults. func NewVdisplinfo() (*Vdisplinfo, error) { - var ( - x Vdisplinfo - xc C.libxl_vdisplinfo - ) +var ( +x Vdisplinfo +xc C.libxl_vdisplinfo) - C.libxl_vdisplinfo_init(&xc) - defer C.libxl_vdisplinfo_dispose(&xc) +C.libxl_vdisplinfo_init(&xc) +defer C.libxl_vdisplinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Vdisplinfo) fromC(xc *C.libxl_vdisplinfo) error { - x.Backend = C.GoString(xc.backend) - x.BackendId = uint32(xc.backend_id) - x.Frontend = C.GoString(xc.frontend) - x.FrontendId = uint32(xc.frontend_id) - x.Devid = Devid(xc.devid) - x.State = int(xc.state) - x.BeAlloc = bool(xc.be_alloc) - x.Connectors = nil - if n := int(xc.num_connectors); n > 0 { - cConnectors := (*[1 << 28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:n:n] - x.Connectors = make([]Connectorinfo, n) - for i, v := range cConnectors { - if err := x.Connectors[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Connectors: %v", err) - } - } - } - - return nil -} - -func (x *Vdisplinfo) toC(xc *C.libxl_vdisplinfo) (err error) { - defer func() { - if err != nil { - C.libxl_vdisplinfo_dispose(xc) - } - }() - - if x.Backend != "" { - xc.backend = C.CString(x.Backend) - } - xc.backend_id = C.uint32_t(x.BackendId) - if x.Frontend != "" { - xc.frontend = C.CString(x.Frontend) - } - xc.frontend_id = C.uint32_t(x.FrontendId) - xc.devid = C.libxl_devid(x.Devid) - xc.state = C.int(x.State) - xc.be_alloc = C.bool(x.BeAlloc) - if numConnectors := len(x.Connectors); numConnectors > 0 { - xc.connectors = (*C.libxl_connectorinfo)(C.malloc(C.ulong(numConnectors) * C.sizeof_libxl_connectorinfo)) - xc.num_connectors = C.int(numConnectors) - cConnectors := (*[1 << 28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors] - for i, v := range x.Connectors { - if err := v.toC(&cConnectors[i]); err != nil { - return fmt.Errorf("converting field Connectors: %v", err) - } - } - } - - return nil -} + x.Backend = C.GoString(xc.backend) +x.BackendId = uint32(xc.backend_id) +x.Frontend = C.GoString(xc.frontend) +x.FrontendId = uint32(xc.frontend_id) +x.Devid = Devid(xc.devid) +x.State = int(xc.state) +x.BeAlloc = bool(xc.be_alloc) +x.Connectors = nil +if n := int(xc.num_connectors); n > 0 { +cConnectors := (*[1<<28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:n:n] +x.Connectors = make([]Connectorinfo, n) +for i, v := range cConnectors { +if err := x.Connectors[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Connectors: %v", err) } +} +} + + return nil} + +func (x *Vdisplinfo) toC(xc *C.libxl_vdisplinfo) (err error){defer func(){ +if err != nil{ +C.libxl_vdisplinfo_dispose(xc)} +}() + +if x.Backend != "" { +xc.backend = C.CString(x.Backend)} +xc.backend_id = C.uint32_t(x.BackendId) +if x.Frontend != "" { +xc.frontend = C.CString(x.Frontend)} +xc.frontend_id = C.uint32_t(x.FrontendId) +xc.devid = C.libxl_devid(x.Devid) +xc.state = C.int(x.State) +xc.be_alloc = C.bool(x.BeAlloc) +if numConnectors := len(x.Connectors); numConnectors > 0 { +xc.connectors = (*C.libxl_connectorinfo)(C.malloc(C.ulong(numConnectors)*C.sizeof_libxl_connectorinfo)) +xc.num_connectors = C.int(numConnectors) +cConnectors := (*[1<<28]C.libxl_connectorinfo)(unsafe.Pointer(xc.connectors))[:numConnectors:numConnectors] +for i,v := range x.Connectors { +if err := v.toC(&cConnectors[i]); err != nil { +return fmt.Errorf("converting field Connectors: %v", err) +} +} +} + + return nil + } // NewStreaminfo returns an instance of Streaminfo initialized with defaults. func NewStreaminfo() (*Streaminfo, error) { - var ( - x Streaminfo - xc C.libxl_streaminfo - ) +var ( +x Streaminfo +xc C.libxl_streaminfo) - C.libxl_streaminfo_init(&xc) - defer C.libxl_streaminfo_dispose(&xc) +C.libxl_streaminfo_init(&xc) +defer C.libxl_streaminfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Streaminfo) fromC(xc *C.libxl_streaminfo) error { - x.ReqEvtch = int(xc.req_evtch) - x.ReqRref = int(xc.req_rref) + x.ReqEvtch = int(xc.req_evtch) +x.ReqRref = int(xc.req_rref) + + return nil} - return nil -} - -func (x *Streaminfo) toC(xc *C.libxl_streaminfo) (err error) { - defer func() { - if err != nil { - C.libxl_streaminfo_dispose(xc) - } - }() +func (x *Streaminfo) toC(xc *C.libxl_streaminfo) (err error){defer func(){ +if err != nil{ +C.libxl_streaminfo_dispose(xc)} +}() - xc.req_evtch = C.int(x.ReqEvtch) - xc.req_rref = C.int(x.ReqRref) +xc.req_evtch = C.int(x.ReqEvtch) +xc.req_rref = C.int(x.ReqRref) - return nil -} + return nil + } // NewPcminfo returns an instance of Pcminfo initialized with defaults. func NewPcminfo() (*Pcminfo, error) { - var ( - x Pcminfo - xc C.libxl_pcminfo - ) +var ( +x Pcminfo +xc C.libxl_pcminfo) - C.libxl_pcminfo_init(&xc) - defer C.libxl_pcminfo_dispose(&xc) +C.libxl_pcminfo_init(&xc) +defer C.libxl_pcminfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Pcminfo) fromC(xc *C.libxl_pcminfo) error { - x.Streams = nil - if n := int(xc.num_vsnd_streams); n > 0 { - cStreams := (*[1 << 28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:n:n] - x.Streams = make([]Streaminfo, n) - for i, v := range cStreams { - if err := x.Streams[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Streams: %v", err) - } - } - } - - return nil -} - -func (x *Pcminfo) toC(xc *C.libxl_pcminfo) (err error) { - defer func() { - if err != nil { - C.libxl_pcminfo_dispose(xc) - } - }() - - if numVsndStreams := len(x.Streams); numVsndStreams > 0 { - xc.streams = (*C.libxl_streaminfo)(C.malloc(C.ulong(numVsndStreams) * C.sizeof_libxl_streaminfo)) - xc.num_vsnd_streams = C.int(numVsndStreams) - cStreams := (*[1 << 28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams] - for i, v := range x.Streams { - if err := v.toC(&cStreams[i]); err != nil { - return fmt.Errorf("converting field Streams: %v", err) - } - } - } - - return nil + x.Streams = nil +if n := int(xc.num_vsnd_streams); n > 0 { +cStreams := (*[1<<28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:n:n] +x.Streams = make([]Streaminfo, n) +for i, v := range cStreams { +if err := x.Streams[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Streams: %v", err) } +} } + + return nil} + +func (x *Pcminfo) toC(xc *C.libxl_pcminfo) (err error){defer func(){ +if err != nil{ +C.libxl_pcminfo_dispose(xc)} +}() + +if numVsndStreams := len(x.Streams); numVsndStreams > 0 { +xc.streams = (*C.libxl_streaminfo)(C.malloc(C.ulong(numVsndStreams)*C.sizeof_libxl_streaminfo)) +xc.num_vsnd_streams = C.int(numVsndStreams) +cStreams := (*[1<<28]C.libxl_streaminfo)(unsafe.Pointer(xc.streams))[:numVsndStreams:numVsndStreams] +for i,v := range x.Streams { +if err := v.toC(&cStreams[i]); err != nil { +return fmt.Errorf("converting field Streams: %v", err) +} +} +} + + return nil + } // NewVsndinfo returns an instance of Vsndinfo initialized with defaults. func NewVsndinfo() (*Vsndinfo, error) { - var ( - x Vsndinfo - xc C.libxl_vsndinfo - ) +var ( +x Vsndinfo +xc C.libxl_vsndinfo) - C.libxl_vsndinfo_init(&xc) - defer C.libxl_vsndinfo_dispose(&xc) +C.libxl_vsndinfo_init(&xc) +defer C.libxl_vsndinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Vsndinfo) fromC(xc *C.libxl_vsndinfo) error { - x.Backend = C.GoString(xc.backend) - x.BackendId = uint32(xc.backend_id) - x.Frontend = C.GoString(xc.frontend) - x.FrontendId = uint32(xc.frontend_id) - x.Devid = Devid(xc.devid) - x.State = int(xc.state) - x.Pcms = nil - if n := int(xc.num_vsnd_pcms); n > 0 { - cPcms := (*[1 << 28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:n:n] - x.Pcms = make([]Pcminfo, n) - for i, v := range cPcms { - if err := x.Pcms[i].fromC(&v); err != nil { - return fmt.Errorf("converting field Pcms: %v", err) - } - } - } - - return nil -} - -func (x *Vsndinfo) toC(xc *C.libxl_vsndinfo) (err error) { - defer func() { - if err != nil { - C.libxl_vsndinfo_dispose(xc) - } - }() - - if x.Backend != "" { - xc.backend = C.CString(x.Backend) - } - xc.backend_id = C.uint32_t(x.BackendId) - if x.Frontend != "" { - xc.frontend = C.CString(x.Frontend) - } - xc.frontend_id = C.uint32_t(x.FrontendId) - xc.devid = C.libxl_devid(x.Devid) - xc.state = C.int(x.State) - if numVsndPcms := len(x.Pcms); numVsndPcms > 0 { - xc.pcms = (*C.libxl_pcminfo)(C.malloc(C.ulong(numVsndPcms) * C.sizeof_libxl_pcminfo)) - xc.num_vsnd_pcms = C.int(numVsndPcms) - cPcms := (*[1 << 28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms] - for i, v := range x.Pcms { - if err := v.toC(&cPcms[i]); err != nil { - return fmt.Errorf("converting field Pcms: %v", err) - } - } - } - - return nil -} + x.Backend = C.GoString(xc.backend) +x.BackendId = uint32(xc.backend_id) +x.Frontend = C.GoString(xc.frontend) +x.FrontendId = uint32(xc.frontend_id) +x.Devid = Devid(xc.devid) +x.State = int(xc.state) +x.Pcms = nil +if n := int(xc.num_vsnd_pcms); n > 0 { +cPcms := (*[1<<28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:n:n] +x.Pcms = make([]Pcminfo, n) +for i, v := range cPcms { +if err := x.Pcms[i].fromC(&v); err != nil { +return fmt.Errorf("converting field Pcms: %v", err) } +} +} + + return nil} + +func (x *Vsndinfo) toC(xc *C.libxl_vsndinfo) (err error){defer func(){ +if err != nil{ +C.libxl_vsndinfo_dispose(xc)} +}() + +if x.Backend != "" { +xc.backend = C.CString(x.Backend)} +xc.backend_id = C.uint32_t(x.BackendId) +if x.Frontend != "" { +xc.frontend = C.CString(x.Frontend)} +xc.frontend_id = C.uint32_t(x.FrontendId) +xc.devid = C.libxl_devid(x.Devid) +xc.state = C.int(x.State) +if numVsndPcms := len(x.Pcms); numVsndPcms > 0 { +xc.pcms = (*C.libxl_pcminfo)(C.malloc(C.ulong(numVsndPcms)*C.sizeof_libxl_pcminfo)) +xc.num_vsnd_pcms = C.int(numVsndPcms) +cPcms := (*[1<<28]C.libxl_pcminfo)(unsafe.Pointer(xc.pcms))[:numVsndPcms:numVsndPcms] +for i,v := range x.Pcms { +if err := v.toC(&cPcms[i]); err != nil { +return fmt.Errorf("converting field Pcms: %v", err) +} +} +} + + return nil + } // NewVkbinfo returns an instance of Vkbinfo initialized with defaults. func NewVkbinfo() (*Vkbinfo, error) { - var ( - x Vkbinfo - xc C.libxl_vkbinfo - ) +var ( +x Vkbinfo +xc C.libxl_vkbinfo) - C.libxl_vkbinfo_init(&xc) - defer C.libxl_vkbinfo_dispose(&xc) +C.libxl_vkbinfo_init(&xc) +defer C.libxl_vkbinfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Vkbinfo) fromC(xc *C.libxl_vkbinfo) error { - x.Backend = C.GoString(xc.backend) - x.BackendId = uint32(xc.backend_id) - x.Frontend = C.GoString(xc.frontend) - x.FrontendId = uint32(xc.frontend_id) - x.Devid = Devid(xc.devid) - x.State = int(xc.state) - x.Evtch = int(xc.evtch) - x.Rref = int(xc.rref) - - return nil -} - -func (x *Vkbinfo) toC(xc *C.libxl_vkbinfo) (err error) { - defer func() { - if err != nil { - C.libxl_vkbinfo_dispose(xc) - } - }() - - if x.Backend != "" { - xc.backend = C.CString(x.Backend) - } - xc.backend_id = C.uint32_t(x.BackendId) - if x.Frontend != "" { - xc.frontend = C.CString(x.Frontend) - } - xc.frontend_id = C.uint32_t(x.FrontendId) - xc.devid = C.libxl_devid(x.Devid) - xc.state = C.int(x.State) - xc.evtch = C.int(x.Evtch) - xc.rref = C.int(x.Rref) - - return nil -} + x.Backend = C.GoString(xc.backend) +x.BackendId = uint32(xc.backend_id) +x.Frontend = C.GoString(xc.frontend) +x.FrontendId = uint32(xc.frontend_id) +x.Devid = Devid(xc.devid) +x.State = int(xc.state) +x.Evtch = int(xc.evtch) +x.Rref = int(xc.rref) + + return nil} + +func (x *Vkbinfo) toC(xc *C.libxl_vkbinfo) (err error){defer func(){ +if err != nil{ +C.libxl_vkbinfo_dispose(xc)} +}() + +if x.Backend != "" { +xc.backend = C.CString(x.Backend)} +xc.backend_id = C.uint32_t(x.BackendId) +if x.Frontend != "" { +xc.frontend = C.CString(x.Frontend)} +xc.frontend_id = C.uint32_t(x.FrontendId) +xc.devid = C.libxl_devid(x.Devid) +xc.state = C.int(x.State) +xc.evtch = C.int(x.Evtch) +xc.rref = C.int(x.Rref) + + return nil + } // NewNumainfo returns an instance of Numainfo initialized with defaults. func NewNumainfo() (*Numainfo, error) { - var ( - x Numainfo - xc C.libxl_numainfo - ) +var ( +x Numainfo +xc C.libxl_numainfo) - C.libxl_numainfo_init(&xc) - defer C.libxl_numainfo_dispose(&xc) +C.libxl_numainfo_init(&xc) +defer C.libxl_numainfo_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Numainfo) fromC(xc *C.libxl_numainfo) error { - x.Size = uint64(xc.size) - x.Free = uint64(xc.free) - x.Dists = nil - if n := int(xc.num_dists); n > 0 { - cDists := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.dists))[:n:n] - x.Dists = make([]uint32, n) - for i, v := range cDists { - x.Dists[i] = uint32(v) - } - } - - return nil -} - -func (x *Numainfo) toC(xc *C.libxl_numainfo) (err error) { - defer func() { - if err != nil { - C.libxl_numainfo_dispose(xc) - } - }() - - xc.size = C.uint64_t(x.Size) - xc.free = C.uint64_t(x.Free) - if numDists := len(x.Dists); numDists > 0 { - xc.dists = (*C.uint32_t)(C.malloc(C.size_t(numDists * numDists))) - xc.num_dists = C.int(numDists) - cDists := (*[1 << 28]C.uint32_t)(unsafe.Pointer(xc.dists))[:numDists:numDists] - for i, v := range x.Dists { - cDists[i] = C.uint32_t(v) - } - } - - return nil + x.Size = uint64(xc.size) +x.Free = uint64(xc.free) +x.Dists = nil +if n := int(xc.num_dists); n > 0 { +cDists := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.dists))[:n:n] +x.Dists = make([]uint32, n) +for i, v := range cDists { +x.Dists[i] = uint32(v) +} } + + return nil} + +func (x *Numainfo) toC(xc *C.libxl_numainfo) (err error){defer func(){ +if err != nil{ +C.libxl_numainfo_dispose(xc)} +}() + +xc.size = C.uint64_t(x.Size) +xc.free = C.uint64_t(x.Free) +if numDists := len(x.Dists); numDists > 0 { +xc.dists = (*C.uint32_t)(C.malloc(C.size_t(numDists*numDists))) +xc.num_dists = C.int(numDists) +cDists := (*[1<<28]C.uint32_t)(unsafe.Pointer(xc.dists))[:numDists:numDists] +for i,v := range x.Dists { +cDists[i] = C.uint32_t(v) +} +} + + return nil + } // NewCputopology returns an instance of Cputopology initialized with defaults. func NewCputopology() (*Cputopology, error) { - var ( - x Cputopology - xc C.libxl_cputopology - ) +var ( +x Cputopology +xc C.libxl_cputopology) - C.libxl_cputopology_init(&xc) - defer C.libxl_cputopology_dispose(&xc) +C.libxl_cputopology_init(&xc) +defer C.libxl_cputopology_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Cputopology) fromC(xc *C.libxl_cputopology) error { - x.Core = uint32(xc.core) - x.Socket = uint32(xc.socket) - x.Node = uint32(xc.node) + x.Core = uint32(xc.core) +x.Socket = uint32(xc.socket) +x.Node = uint32(xc.node) + + return nil} - return nil -} +func (x *Cputopology) toC(xc *C.libxl_cputopology) (err error){defer func(){ +if err != nil{ +C.libxl_cputopology_dispose(xc)} +}() -func (x *Cputopology) toC(xc *C.libxl_cputopology) (err error) { - defer func() { - if err != nil { - C.libxl_cputopology_dispose(xc) - } - }() +xc.core = C.uint32_t(x.Core) +xc.socket = C.uint32_t(x.Socket) +xc.node = C.uint32_t(x.Node) - xc.core = C.uint32_t(x.Core) - xc.socket = C.uint32_t(x.Socket) - xc.node = C.uint32_t(x.Node) - - return nil -} + return nil + } // NewPcitopology returns an instance of Pcitopology initialized with defaults. func NewPcitopology() (*Pcitopology, error) { - var ( - x Pcitopology - xc C.libxl_pcitopology - ) +var ( +x Pcitopology +xc C.libxl_pcitopology) - C.libxl_pcitopology_init(&xc) - defer C.libxl_pcitopology_dispose(&xc) +C.libxl_pcitopology_init(&xc) +defer C.libxl_pcitopology_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Pcitopology) fromC(xc *C.libxl_pcitopology) error { - x.Seg = uint16(xc.seg) - x.Bus = byte(xc.bus) - x.Devfn = byte(xc.devfn) - x.Node = uint32(xc.node) - - return nil -} - -func (x *Pcitopology) toC(xc *C.libxl_pcitopology) (err error) { - defer func() { - if err != nil { - C.libxl_pcitopology_dispose(xc) - } - }() - - xc.seg = C.uint16_t(x.Seg) - xc.bus = C.uint8_t(x.Bus) - xc.devfn = C.uint8_t(x.Devfn) - xc.node = C.uint32_t(x.Node) - - return nil -} + x.Seg = uint16(xc.seg) +x.Bus = byte(xc.bus) +x.Devfn = byte(xc.devfn) +x.Node = uint32(xc.node) + + return nil} + +func (x *Pcitopology) toC(xc *C.libxl_pcitopology) (err error){defer func(){ +if err != nil{ +C.libxl_pcitopology_dispose(xc)} +}() + +xc.seg = C.uint16_t(x.Seg) +xc.bus = C.uint8_t(x.Bus) +xc.devfn = C.uint8_t(x.Devfn) +xc.node = C.uint32_t(x.Node) + + return nil + } // NewSchedCreditParams returns an instance of SchedCreditParams initialized with defaults. func NewSchedCreditParams() (*SchedCreditParams, error) { - var ( - x SchedCreditParams - xc C.libxl_sched_credit_params - ) +var ( +x SchedCreditParams +xc C.libxl_sched_credit_params) - C.libxl_sched_credit_params_init(&xc) +C.libxl_sched_credit_params_init(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *SchedCreditParams) fromC(xc *C.libxl_sched_credit_params) error { - x.TsliceMs = int(xc.tslice_ms) - x.RatelimitUs = int(xc.ratelimit_us) - x.VcpuMigrDelayUs = int(xc.vcpu_migr_delay_us) - - return nil -} + x.TsliceMs = int(xc.tslice_ms) +x.RatelimitUs = int(xc.ratelimit_us) +x.VcpuMigrDelayUs = int(xc.vcpu_migr_delay_us) + + return nil} -func (x *SchedCreditParams) toC(xc *C.libxl_sched_credit_params) (err error) { - xc.tslice_ms = C.int(x.TsliceMs) - xc.ratelimit_us = C.int(x.RatelimitUs) - xc.vcpu_migr_delay_us = C.int(x.VcpuMigrDelayUs) +func (x *SchedCreditParams) toC(xc *C.libxl_sched_credit_params) (err error){xc.tslice_ms = C.int(x.TsliceMs) +xc.ratelimit_us = C.int(x.RatelimitUs) +xc.vcpu_migr_delay_us = C.int(x.VcpuMigrDelayUs) - return nil -} + return nil + } // NewSchedCredit2Params returns an instance of SchedCredit2Params initialized with defaults. func NewSchedCredit2Params() (*SchedCredit2Params, error) { - var ( - x SchedCredit2Params - xc C.libxl_sched_credit2_params - ) +var ( +x SchedCredit2Params +xc C.libxl_sched_credit2_params) - C.libxl_sched_credit2_params_init(&xc) +C.libxl_sched_credit2_params_init(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *SchedCredit2Params) fromC(xc *C.libxl_sched_credit2_params) error { - x.RatelimitUs = int(xc.ratelimit_us) + x.RatelimitUs = int(xc.ratelimit_us) + + return nil} - return nil -} - -func (x *SchedCredit2Params) toC(xc *C.libxl_sched_credit2_params) (err error) { - xc.ratelimit_us = C.int(x.RatelimitUs) +func (x *SchedCredit2Params) toC(xc *C.libxl_sched_credit2_params) (err error){xc.ratelimit_us = C.int(x.RatelimitUs) - return nil -} + return nil + } // NewDomainRemusInfo returns an instance of DomainRemusInfo initialized with defaults. func NewDomainRemusInfo() (*DomainRemusInfo, error) { - var ( - x DomainRemusInfo - xc C.libxl_domain_remus_info - ) +var ( +x DomainRemusInfo +xc C.libxl_domain_remus_info) - C.libxl_domain_remus_info_init(&xc) - defer C.libxl_domain_remus_info_dispose(&xc) +C.libxl_domain_remus_info_init(&xc) +defer C.libxl_domain_remus_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *DomainRemusInfo) fromC(xc *C.libxl_domain_remus_info) error { - x.Interval = int(xc.interval) - if err := x.AllowUnsafe.fromC(&xc.allow_unsafe); err != nil { - return fmt.Errorf("converting field AllowUnsafe: %v", err) - } - if err := x.Blackhole.fromC(&xc.blackhole); err != nil { - return fmt.Errorf("converting field Blackhole: %v", err) - } - if err := x.Compression.fromC(&xc.compression); err != nil { - return fmt.Errorf("converting field Compression: %v", err) - } - if err := x.Netbuf.fromC(&xc.netbuf); err != nil { - return fmt.Errorf("converting field Netbuf: %v", err) - } - x.Netbufscript = C.GoString(xc.netbufscript) - if err := x.Diskbuf.fromC(&xc.diskbuf); err != nil { - return fmt.Errorf("converting field Diskbuf: %v", err) - } - if err := x.Colo.fromC(&xc.colo); err != nil { - return fmt.Errorf("converting field Colo: %v", err) - } - if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy); err != nil { - return fmt.Errorf("converting field UserspaceColoProxy: %v", err) - } - - return nil -} - -func (x *DomainRemusInfo) toC(xc *C.libxl_domain_remus_info) (err error) { - defer func() { - if err != nil { - C.libxl_domain_remus_info_dispose(xc) - } - }() - - xc.interval = C.int(x.Interval) - if err := x.AllowUnsafe.toC(&xc.allow_unsafe); err != nil { - return fmt.Errorf("converting field AllowUnsafe: %v", err) - } - if err := x.Blackhole.toC(&xc.blackhole); err != nil { - return fmt.Errorf("converting field Blackhole: %v", err) - } - if err := x.Compression.toC(&xc.compression); err != nil { - return fmt.Errorf("converting field Compression: %v", err) - } - if err := x.Netbuf.toC(&xc.netbuf); err != nil { - return fmt.Errorf("converting field Netbuf: %v", err) - } - if x.Netbufscript != "" { - xc.netbufscript = C.CString(x.Netbufscript) - } - if err := x.Diskbuf.toC(&xc.diskbuf); err != nil { - return fmt.Errorf("converting field Diskbuf: %v", err) - } - if err := x.Colo.toC(&xc.colo); err != nil { - return fmt.Errorf("converting field Colo: %v", err) - } - if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil { - return fmt.Errorf("converting field UserspaceColoProxy: %v", err) - } - - return nil + x.Interval = int(xc.interval) +if err := x.AllowUnsafe.fromC(&xc.allow_unsafe);err != nil { +return fmt.Errorf("converting field AllowUnsafe: %v", err) +} +if err := x.Blackhole.fromC(&xc.blackhole);err != nil { +return fmt.Errorf("converting field Blackhole: %v", err) +} +if err := x.Compression.fromC(&xc.compression);err != nil { +return fmt.Errorf("converting field Compression: %v", err) +} +if err := x.Netbuf.fromC(&xc.netbuf);err != nil { +return fmt.Errorf("converting field Netbuf: %v", err) +} +x.Netbufscript = C.GoString(xc.netbufscript) +if err := x.Diskbuf.fromC(&xc.diskbuf);err != nil { +return fmt.Errorf("converting field Diskbuf: %v", err) +} +if err := x.Colo.fromC(&xc.colo);err != nil { +return fmt.Errorf("converting field Colo: %v", err) } +if err := x.UserspaceColoProxy.fromC(&xc.userspace_colo_proxy);err != nil { +return fmt.Errorf("converting field UserspaceColoProxy: %v", err) +} + + return nil} + +func (x *DomainRemusInfo) toC(xc *C.libxl_domain_remus_info) (err error){defer func(){ +if err != nil{ +C.libxl_domain_remus_info_dispose(xc)} +}() + +xc.interval = C.int(x.Interval) +if err := x.AllowUnsafe.toC(&xc.allow_unsafe); err != nil { +return fmt.Errorf("converting field AllowUnsafe: %v", err) +} +if err := x.Blackhole.toC(&xc.blackhole); err != nil { +return fmt.Errorf("converting field Blackhole: %v", err) +} +if err := x.Compression.toC(&xc.compression); err != nil { +return fmt.Errorf("converting field Compression: %v", err) +} +if err := x.Netbuf.toC(&xc.netbuf); err != nil { +return fmt.Errorf("converting field Netbuf: %v", err) +} +if x.Netbufscript != "" { +xc.netbufscript = C.CString(x.Netbufscript)} +if err := x.Diskbuf.toC(&xc.diskbuf); err != nil { +return fmt.Errorf("converting field Diskbuf: %v", err) +} +if err := x.Colo.toC(&xc.colo); err != nil { +return fmt.Errorf("converting field Colo: %v", err) +} +if err := x.UserspaceColoProxy.toC(&xc.userspace_colo_proxy); err != nil { +return fmt.Errorf("converting field UserspaceColoProxy: %v", err) +} + + return nil + } // NewEvent returns an instance of Event initialized with defaults. func NewEvent(etype EventType) (*Event, error) { - var ( - x Event - xc C.libxl_event - ) +var ( +x Event +xc C.libxl_event) - C.libxl_event_init(&xc) - C.libxl_event_init_type(&xc, C.libxl_event_type(etype)) - defer C.libxl_event_dispose(&xc) +C.libxl_event_init(&xc) +C.libxl_event_init_type(&xc, C.libxl_event_type(etype)) +defer C.libxl_event_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *Event) fromC(xc *C.libxl_event) error { - if err := x.Link.fromC(&xc.link); err != nil { - return fmt.Errorf("converting field Link: %v", err) - } - x.Domid = Domid(xc.domid) - if err := x.Domuuid.fromC(&xc.domuuid); err != nil { - return fmt.Errorf("converting field Domuuid: %v", err) - } - x.ForUser = uint64(xc.for_user) - x.Type = EventType(xc._type) - switch x.Type { - case EventTypeDomainShutdown: - var typeDomainShutdown EventTypeUnionDomainShutdown - if err := typeDomainShutdown.fromC(xc); err != nil { - return fmt.Errorf("converting field typeDomainShutdown: %v", err) - } - x.TypeUnion = typeDomainShutdown - case EventTypeDomainDeath: - x.TypeUnion = nil - case EventTypeDiskEject: - var typeDiskEject EventTypeUnionDiskEject - if err := typeDiskEject.fromC(xc); err != nil { - return fmt.Errorf("converting field typeDiskEject: %v", err) - } - x.TypeUnion = typeDiskEject - case EventTypeOperationComplete: - var typeOperationComplete EventTypeUnionOperationComplete - if err := typeOperationComplete.fromC(xc); err != nil { - return fmt.Errorf("converting field typeOperationComplete: %v", err) - } - x.TypeUnion = typeOperationComplete - case EventTypeDomainCreateConsoleAvailable: - x.TypeUnion = nil - default: - return fmt.Errorf("invalid union key '%v'", x.Type) - } - - return nil -} + if err := x.Link.fromC(&xc.link);err != nil { +return fmt.Errorf("converting field Link: %v", err) +} +x.Domid = Domid(xc.domid) +if err := x.Domuuid.fromC(&xc.domuuid);err != nil { +return fmt.Errorf("converting field Domuuid: %v", err) +} +x.ForUser = uint64(xc.for_user) +x.Type = EventType(xc._type) +switch x.Type{ +case EventTypeDomainShutdown: +var typeDomainShutdown EventTypeUnionDomainShutdown +if err := typeDomainShutdown.fromC(xc);err != nil { + return fmt.Errorf("converting field typeDomainShutdown: %v", err) +} +x.TypeUnion = typeDomainShutdown +case EventTypeDomainDeath: +x.TypeUnion = nil +case EventTypeDiskEject: +var typeDiskEject EventTypeUnionDiskEject +if err := typeDiskEject.fromC(xc);err != nil { + return fmt.Errorf("converting field typeDiskEject: %v", err) +} +x.TypeUnion = typeDiskEject +case EventTypeOperationComplete: +var typeOperationComplete EventTypeUnionOperationComplete +if err := typeOperationComplete.fromC(xc);err != nil { + return fmt.Errorf("converting field typeOperationComplete: %v", err) +} +x.TypeUnion = typeOperationComplete +case EventTypeDomainCreateConsoleAvailable: +x.TypeUnion = nil +default: +return fmt.Errorf("invalid union key '%v'", x.Type)} + + return nil} func (x *EventTypeUnionDomainShutdown) fromC(xc *C.libxl_event) error { - if EventType(xc._type) != EventTypeDomainShutdown { - return errors.New("expected union key EventTypeDomainShutdown") - } +if EventType(xc._type) != EventTypeDomainShutdown { +return errors.New("expected union key EventTypeDomainShutdown") +} - tmp := (*C.libxl_event_type_union_domain_shutdown)(unsafe.Pointer(&xc.u[0])) - x.ShutdownReason = byte(tmp.shutdown_reason) - return nil +tmp := (*C.libxl_event_type_union_domain_shutdown)(unsafe.Pointer(&xc.u[0])) +x.ShutdownReason = byte(tmp.shutdown_reason) +return nil } func (x *EventTypeUnionDiskEject) fromC(xc *C.libxl_event) error { - if EventType(xc._type) != EventTypeDiskEject { - return errors.New("expected union key EventTypeDiskEject") - } +if EventType(xc._type) != EventTypeDiskEject { +return errors.New("expected union key EventTypeDiskEject") +} - tmp := (*C.libxl_event_type_union_disk_eject)(unsafe.Pointer(&xc.u[0])) - x.Vdev = C.GoString(tmp.vdev) - if err := x.Disk.fromC(&tmp.disk); err != nil { - return fmt.Errorf("converting field Disk: %v", err) - } - return nil +tmp := (*C.libxl_event_type_union_disk_eject)(unsafe.Pointer(&xc.u[0])) +x.Vdev = C.GoString(tmp.vdev) +if err := x.Disk.fromC(&tmp.disk);err != nil { +return fmt.Errorf("converting field Disk: %v", err) +} +return nil } func (x *EventTypeUnionOperationComplete) fromC(xc *C.libxl_event) error { - if EventType(xc._type) != EventTypeOperationComplete { - return errors.New("expected union key EventTypeOperationComplete") - } - - tmp := (*C.libxl_event_type_union_operation_complete)(unsafe.Pointer(&xc.u[0])) - x.Rc = int(tmp.rc) - return nil -} - -func (x *Event) toC(xc *C.libxl_event) (err error) { - defer func() { - if err != nil { - C.libxl_event_dispose(xc) - } - }() - - if err := x.Link.toC(&xc.link); err != nil { - return fmt.Errorf("converting field Link: %v", err) - } - xc.domid = C.libxl_domid(x.Domid) - if err := x.Domuuid.toC(&xc.domuuid); err != nil { - return fmt.Errorf("converting field Domuuid: %v", err) - } - xc.for_user = C.uint64_t(x.ForUser) - xc._type = C.libxl_event_type(x.Type) - switch x.Type { - case EventTypeDomainShutdown: - tmp, ok := x.TypeUnion.(EventTypeUnionDomainShutdown) - if !ok { - return errors.New("wrong type for union key type") - } - var domain_shutdown C.libxl_event_type_union_domain_shutdown - domain_shutdown.shutdown_reason = C.uint8_t(tmp.ShutdownReason) - domain_shutdownBytes := C.GoBytes(unsafe.Pointer(&domain_shutdown), C.sizeof_libxl_event_type_union_domain_shutdown) - copy(xc.u[:], domain_shutdownBytes) - case EventTypeDomainDeath: - break - case EventTypeDiskEject: - tmp, ok := x.TypeUnion.(EventTypeUnionDiskEject) - if !ok { - return errors.New("wrong type for union key type") - } - var disk_eject C.libxl_event_type_union_disk_eject - if tmp.Vdev != "" { - disk_eject.vdev = C.CString(tmp.Vdev) - } - if err := tmp.Disk.toC(&disk_eject.disk); err != nil { - return fmt.Errorf("converting field Disk: %v", err) - } - disk_ejectBytes := C.GoBytes(unsafe.Pointer(&disk_eject), C.sizeof_libxl_event_type_union_disk_eject) - copy(xc.u[:], disk_ejectBytes) - case EventTypeOperationComplete: - tmp, ok := x.TypeUnion.(EventTypeUnionOperationComplete) - if !ok { - return errors.New("wrong type for union key type") - } - var operation_complete C.libxl_event_type_union_operation_complete - operation_complete.rc = C.int(tmp.Rc) - operation_completeBytes := C.GoBytes(unsafe.Pointer(&operation_complete), C.sizeof_libxl_event_type_union_operation_complete) - copy(xc.u[:], operation_completeBytes) - case EventTypeDomainCreateConsoleAvailable: - break - default: - return fmt.Errorf("invalid union key '%v'", x.Type) - } - - return nil -} +if EventType(xc._type) != EventTypeOperationComplete { +return errors.New("expected union key EventTypeOperationComplete") +} + +tmp := (*C.libxl_event_type_union_operation_complete)(unsafe.Pointer(&xc.u[0])) +x.Rc = int(tmp.rc) +return nil +} + +func (x *Event) toC(xc *C.libxl_event) (err error){defer func(){ +if err != nil{ +C.libxl_event_dispose(xc)} +}() + +if err := x.Link.toC(&xc.link); err != nil { +return fmt.Errorf("converting field Link: %v", err) +} +xc.domid = C.libxl_domid(x.Domid) +if err := x.Domuuid.toC(&xc.domuuid); err != nil { +return fmt.Errorf("converting field Domuuid: %v", err) +} +xc.for_user = C.uint64_t(x.ForUser) +xc._type = C.libxl_event_type(x.Type) +switch x.Type{ +case EventTypeDomainShutdown: +tmp, ok := x.TypeUnion.(EventTypeUnionDomainShutdown) +if !ok { +return errors.New("wrong type for union key type") +} +var domain_shutdown C.libxl_event_type_union_domain_shutdown +domain_shutdown.shutdown_reason = C.uint8_t(tmp.ShutdownReason) +domain_shutdownBytes := C.GoBytes(unsafe.Pointer(&domain_shutdown),C.sizeof_libxl_event_type_union_domain_shutdown) +copy(xc.u[:],domain_shutdownBytes) +case EventTypeDomainDeath: +break +case EventTypeDiskEject: +tmp, ok := x.TypeUnion.(EventTypeUnionDiskEject) +if !ok { +return errors.New("wrong type for union key type") +} +var disk_eject C.libxl_event_type_union_disk_eject +if tmp.Vdev != "" { +disk_eject.vdev = C.CString(tmp.Vdev)} +if err := tmp.Disk.toC(&disk_eject.disk); err != nil { +return fmt.Errorf("converting field Disk: %v", err) +} +disk_ejectBytes := C.GoBytes(unsafe.Pointer(&disk_eject),C.sizeof_libxl_event_type_union_disk_eject) +copy(xc.u[:],disk_ejectBytes) +case EventTypeOperationComplete: +tmp, ok := x.TypeUnion.(EventTypeUnionOperationComplete) +if !ok { +return errors.New("wrong type for union key type") +} +var operation_complete C.libxl_event_type_union_operation_complete +operation_complete.rc = C.int(tmp.Rc) +operation_completeBytes := C.GoBytes(unsafe.Pointer(&operation_complete),C.sizeof_libxl_event_type_union_operation_complete) +copy(xc.u[:],operation_completeBytes) +case EventTypeDomainCreateConsoleAvailable: +break +default: +return fmt.Errorf("invalid union key '%v'", x.Type)} + + return nil + } // NewPsrCatInfo returns an instance of PsrCatInfo initialized with defaults. func NewPsrCatInfo() (*PsrCatInfo, error) { - var ( - x PsrCatInfo - xc C.libxl_psr_cat_info - ) +var ( +x PsrCatInfo +xc C.libxl_psr_cat_info) - C.libxl_psr_cat_info_init(&xc) - defer C.libxl_psr_cat_info_dispose(&xc) +C.libxl_psr_cat_info_init(&xc) +defer C.libxl_psr_cat_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *PsrCatInfo) fromC(xc *C.libxl_psr_cat_info) error { - x.Id = uint32(xc.id) - x.CosMax = uint32(xc.cos_max) - x.CbmLen = uint32(xc.cbm_len) - x.CdpEnabled = bool(xc.cdp_enabled) - - return nil -} - -func (x *PsrCatInfo) toC(xc *C.libxl_psr_cat_info) (err error) { - defer func() { - if err != nil { - C.libxl_psr_cat_info_dispose(xc) - } - }() - - xc.id = C.uint32_t(x.Id) - xc.cos_max = C.uint32_t(x.CosMax) - xc.cbm_len = C.uint32_t(x.CbmLen) - xc.cdp_enabled = C.bool(x.CdpEnabled) - - return nil -} + x.Id = uint32(xc.id) +x.CosMax = uint32(xc.cos_max) +x.CbmLen = uint32(xc.cbm_len) +x.CdpEnabled = bool(xc.cdp_enabled) + + return nil} + +func (x *PsrCatInfo) toC(xc *C.libxl_psr_cat_info) (err error){defer func(){ +if err != nil{ +C.libxl_psr_cat_info_dispose(xc)} +}() + +xc.id = C.uint32_t(x.Id) +xc.cos_max = C.uint32_t(x.CosMax) +xc.cbm_len = C.uint32_t(x.CbmLen) +xc.cdp_enabled = C.bool(x.CdpEnabled) + + return nil + } // NewPsrHwInfo returns an instance of PsrHwInfo initialized with defaults. func NewPsrHwInfo(ptype PsrFeatType) (*PsrHwInfo, error) { - var ( - x PsrHwInfo - xc C.libxl_psr_hw_info - ) +var ( +x PsrHwInfo +xc C.libxl_psr_hw_info) - C.libxl_psr_hw_info_init(&xc) - C.libxl_psr_hw_info_init_type(&xc, C.libxl_psr_feat_type(ptype)) - defer C.libxl_psr_hw_info_dispose(&xc) +C.libxl_psr_hw_info_init(&xc) +C.libxl_psr_hw_info_init_type(&xc, C.libxl_psr_feat_type(ptype)) +defer C.libxl_psr_hw_info_dispose(&xc) - if err := x.fromC(&xc); err != nil { - return nil, err - } +if err := x.fromC(&xc); err != nil { +return nil, err } - return &x, nil -} +return &x, nil} func (x *PsrHwInfo) fromC(xc *C.libxl_psr_hw_info) error { - x.Id = uint32(xc.id) - x.Type = PsrFeatType(xc._type) - switch x.Type { - case PsrFeatTypeCat: - var typeCat PsrHwInfoTypeUnionCat - if err := typeCat.fromC(xc); err != nil { - return fmt.Errorf("converting field typeCat: %v", err) - } - x.TypeUnion = typeCat - case PsrFeatTypeMba: - var typeMba PsrHwInfoTypeUnionMba - if err := typeMba.fromC(xc); err != nil { - return fmt.Errorf("converting field typeMba: %v", err) - } - x.TypeUnion = typeMba - default: - return fmt.Errorf("invalid union key '%v'", x.Type) - } - - return nil -} + x.Id = uint32(xc.id) +x.Type = PsrFeatType(xc._type) +switch x.Type{ +case PsrFeatTypeCat: +var typeCat PsrHwInfoTypeUnionCat +if err := typeCat.fromC(xc);err != nil { + return fmt.Errorf("converting field typeCat: %v", err) +} +x.TypeUnion = typeCat +case PsrFeatTypeMba: +var typeMba PsrHwInfoTypeUnionMba +if err := typeMba.fromC(xc);err != nil { + return fmt.Errorf("converting field typeMba: %v", err) +} +x.TypeUnion = typeMba +default: +return fmt.Errorf("invalid union key '%v'", x.Type)} + + return nil} func (x *PsrHwInfoTypeUnionCat) fromC(xc *C.libxl_psr_hw_info) error { - if PsrFeatType(xc._type) != PsrFeatTypeCat { - return errors.New("expected union key PsrFeatTypeCat") - } +if PsrFeatType(xc._type) != PsrFeatTypeCat { +return errors.New("expected union key PsrFeatTypeCat") +} - tmp := (*C.libxl_psr_hw_info_type_union_cat)(unsafe.Pointer(&xc.u[0])) - x.CosMax = uint32(tmp.cos_max) - x.CbmLen = uint32(tmp.cbm_len) - x.CdpEnabled = bool(tmp.cdp_enabled) - return nil +tmp := (*C.libxl_psr_hw_info_type_union_cat)(unsafe.Pointer(&xc.u[0])) +x.CosMax = uint32(tmp.cos_max) +x.CbmLen = uint32(tmp.cbm_len) +x.CdpEnabled = bool(tmp.cdp_enabled) +return nil } func (x *PsrHwInfoTypeUnionMba) fromC(xc *C.libxl_psr_hw_info) error { - if PsrFeatType(xc._type) != PsrFeatTypeMba { - return errors.New("expected union key PsrFeatTypeMba") - } - - tmp := (*C.libxl_psr_hw_info_type_union_mba)(unsafe.Pointer(&xc.u[0])) - x.CosMax = uint32(tmp.cos_max) - x.ThrtlMax = uint32(tmp.thrtl_max) - x.Linear = bool(tmp.linear) - return nil -} - -func (x *PsrHwInfo) toC(xc *C.libxl_psr_hw_info) (err error) { - defer func() { - if err != nil { - C.libxl_psr_hw_info_dispose(xc) - } - }() - - xc.id = C.uint32_t(x.Id) - xc._type = C.libxl_psr_feat_type(x.Type) - switch x.Type { - case PsrFeatTypeCat: - tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionCat) - if !ok { - return errors.New("wrong type for union key type") - } - var cat C.libxl_psr_hw_info_type_union_cat - cat.cos_max = C.uint32_t(tmp.CosMax) - cat.cbm_len = C.uint32_t(tmp.CbmLen) - cat.cdp_enabled = C.bool(tmp.CdpEnabled) - catBytes := C.GoBytes(unsafe.Pointer(&cat), C.sizeof_libxl_psr_hw_info_type_union_cat) - copy(xc.u[:], catBytes) - case PsrFeatTypeMba: - tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionMba) - if !ok { - return errors.New("wrong type for union key type") - } - var mba C.libxl_psr_hw_info_type_union_mba - mba.cos_max = C.uint32_t(tmp.CosMax) - mba.thrtl_max = C.uint32_t(tmp.ThrtlMax) - mba.linear = C.bool(tmp.Linear) - mbaBytes := C.GoBytes(unsafe.Pointer(&mba), C.sizeof_libxl_psr_hw_info_type_union_mba) - copy(xc.u[:], mbaBytes) - default: - return fmt.Errorf("invalid union key '%v'", x.Type) - } - - return nil -} +if PsrFeatType(xc._type) != PsrFeatTypeMba { +return errors.New("expected union key PsrFeatTypeMba") +} + +tmp := (*C.libxl_psr_hw_info_type_union_mba)(unsafe.Pointer(&xc.u[0])) +x.CosMax = uint32(tmp.cos_max) +x.ThrtlMax = uint32(tmp.thrtl_max) +x.Linear = bool(tmp.linear) +return nil +} + +func (x *PsrHwInfo) toC(xc *C.libxl_psr_hw_info) (err error){defer func(){ +if err != nil{ +C.libxl_psr_hw_info_dispose(xc)} +}() + +xc.id = C.uint32_t(x.Id) +xc._type = C.libxl_psr_feat_type(x.Type) +switch x.Type{ +case PsrFeatTypeCat: +tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionCat) +if !ok { +return errors.New("wrong type for union key type") +} +var cat C.libxl_psr_hw_info_type_union_cat +cat.cos_max = C.uint32_t(tmp.CosMax) +cat.cbm_len = C.uint32_t(tmp.CbmLen) +cat.cdp_enabled = C.bool(tmp.CdpEnabled) +catBytes := C.GoBytes(unsafe.Pointer(&cat),C.sizeof_libxl_psr_hw_info_type_union_cat) +copy(xc.u[:],catBytes) +case PsrFeatTypeMba: +tmp, ok := x.TypeUnion.(PsrHwInfoTypeUnionMba) +if !ok { +return errors.New("wrong type for union key type") +} +var mba C.libxl_psr_hw_info_type_union_mba +mba.cos_max = C.uint32_t(tmp.CosMax) +mba.thrtl_max = C.uint32_t(tmp.ThrtlMax) +mba.linear = C.bool(tmp.Linear) +mbaBytes := C.GoBytes(unsafe.Pointer(&mba),C.sizeof_libxl_psr_hw_info_type_union_mba) +copy(xc.u[:],mbaBytes) +default: +return fmt.Errorf("invalid union key '%v'", x.Type)} + + return nil + } + diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go index be42f75529..663c1e86b4 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -7,1224 +7,1188 @@ package xenlight type Error int - -const ( - ErrorNonspecific Error = -1 - ErrorVersion Error = -2 - ErrorFail Error = -3 - ErrorNi Error = -4 - ErrorNomem Error = -5 - ErrorInval Error = -6 - ErrorBadfail Error = -7 - ErrorGuestTimedout Error = -8 - ErrorTimedout Error = -9 - ErrorNoparavirt Error = -10 - ErrorNotReady Error = -11 - ErrorOseventRegFail Error = -12 - ErrorBufferfull Error = -13 - ErrorUnknownChild Error = -14 - ErrorLockFail Error = -15 - ErrorJsonConfigEmpty Error = -16 - ErrorDeviceExists Error = -17 - ErrorCheckpointDevopsDoesNotMatch Error = -18 - ErrorCheckpointDeviceNotSupported Error = -19 - ErrorVnumaConfigInvalid Error = -20 - ErrorDomainNotfound Error = -21 - ErrorAborted Error = -22 - ErrorNotfound Error = -23 - ErrorDomainDestroyed Error = -24 - ErrorFeatureRemoved Error = -25 - ErrorProtocolErrorQmp Error = -26 - ErrorUnknownQmpError Error = -27 - ErrorQmpGenericError Error = -28 - ErrorQmpCommandNotFound Error = -29 - ErrorQmpDeviceNotActive Error = -30 - ErrorQmpDeviceNotFound Error = -31 - ErrorQemuApi Error = -32 +const( +ErrorNonspecific Error = -1 +ErrorVersion Error = -2 +ErrorFail Error = -3 +ErrorNi Error = -4 +ErrorNomem Error = -5 +ErrorInval Error = -6 +ErrorBadfail Error = -7 +ErrorGuestTimedout Error = -8 +ErrorTimedout Error = -9 +ErrorNoparavirt Error = -10 +ErrorNotReady Error = -11 +ErrorOseventRegFail Error = -12 +ErrorBufferfull Error = -13 +ErrorUnknownChild Error = -14 +ErrorLockFail Error = -15 +ErrorJsonConfigEmpty Error = -16 +ErrorDeviceExists Error = -17 +ErrorCheckpointDevopsDoesNotMatch Error = -18 +ErrorCheckpointDeviceNotSupported Error = -19 +ErrorVnumaConfigInvalid Error = -20 +ErrorDomainNotfound Error = -21 +ErrorAborted Error = -22 +ErrorNotfound Error = -23 +ErrorDomainDestroyed Error = -24 +ErrorFeatureRemoved Error = -25 +ErrorProtocolErrorQmp Error = -26 +ErrorUnknownQmpError Error = -27 +ErrorQmpGenericError Error = -28 +ErrorQmpCommandNotFound Error = -29 +ErrorQmpDeviceNotActive Error = -30 +ErrorQmpDeviceNotFound Error = -31 +ErrorQemuApi Error = -32 ) type DomainType int - -const ( - DomainTypeInvalid DomainType = -1 - DomainTypeHvm DomainType = 1 - DomainTypePv DomainType = 2 - DomainTypePvh DomainType = 3 +const( +DomainTypeInvalid DomainType = -1 +DomainTypeHvm DomainType = 1 +DomainTypePv DomainType = 2 +DomainTypePvh DomainType = 3 ) type RdmReserveStrategy int - -const ( - RdmReserveStrategyIgnore RdmReserveStrategy = 0 - RdmReserveStrategyHost RdmReserveStrategy = 1 +const( +RdmReserveStrategyIgnore RdmReserveStrategy = 0 +RdmReserveStrategyHost RdmReserveStrategy = 1 ) type RdmReservePolicy int - -const ( - RdmReservePolicyInvalid RdmReservePolicy = -1 - RdmReservePolicyStrict RdmReservePolicy = 0 - RdmReservePolicyRelaxed RdmReservePolicy = 1 +const( +RdmReservePolicyInvalid RdmReservePolicy = -1 +RdmReservePolicyStrict RdmReservePolicy = 0 +RdmReservePolicyRelaxed RdmReservePolicy = 1 ) type ChannelConnection int - -const ( - ChannelConnectionUnknown ChannelConnection = 0 - ChannelConnectionPty ChannelConnection = 1 - ChannelConnectionSocket ChannelConnection = 2 +const( +ChannelConnectionUnknown ChannelConnection = 0 +ChannelConnectionPty ChannelConnection = 1 +ChannelConnectionSocket ChannelConnection = 2 ) type DeviceModelVersion int - -const ( - DeviceModelVersionUnknown DeviceModelVersion = 0 - DeviceModelVersionQemuXenTraditional DeviceModelVersion = 1 - DeviceModelVersionQemuXen DeviceModelVersion = 2 +const( +DeviceModelVersionUnknown DeviceModelVersion = 0 +DeviceModelVersionQemuXenTraditional DeviceModelVersion = 1 +DeviceModelVersionQemuXen DeviceModelVersion = 2 ) type ConsoleType int - -const ( - ConsoleTypeUnknown ConsoleType = 0 - ConsoleTypeSerial ConsoleType = 1 - ConsoleTypePv ConsoleType = 2 - ConsoleTypeVuart ConsoleType = 3 +const( +ConsoleTypeUnknown ConsoleType = 0 +ConsoleTypeSerial ConsoleType = 1 +ConsoleTypePv ConsoleType = 2 +ConsoleTypeVuart ConsoleType = 3 ) type DiskFormat int - -const ( - DiskFormatUnknown DiskFormat = 0 - DiskFormatQcow DiskFormat = 1 - DiskFormatQcow2 DiskFormat = 2 - DiskFormatVhd DiskFormat = 3 - DiskFormatRaw DiskFormat = 4 - DiskFormatEmpty DiskFormat = 5 - DiskFormatQed DiskFormat = 6 +const( +DiskFormatUnknown DiskFormat = 0 +DiskFormatQcow DiskFormat = 1 +DiskFormatQcow2 DiskFormat = 2 +DiskFormatVhd DiskFormat = 3 +DiskFormatRaw DiskFormat = 4 +DiskFormatEmpty DiskFormat = 5 +DiskFormatQed DiskFormat = 6 ) type DiskBackend int - -const ( - DiskBackendUnknown DiskBackend = 0 - DiskBackendPhy DiskBackend = 1 - DiskBackendTap DiskBackend = 2 - DiskBackendQdisk DiskBackend = 3 +const( +DiskBackendUnknown DiskBackend = 0 +DiskBackendPhy DiskBackend = 1 +DiskBackendTap DiskBackend = 2 +DiskBackendQdisk DiskBackend = 3 ) type NicType int - -const ( - NicTypeUnknown NicType = 0 - NicTypeVifIoemu NicType = 1 - NicTypeVif NicType = 2 +const( +NicTypeUnknown NicType = 0 +NicTypeVifIoemu NicType = 1 +NicTypeVif NicType = 2 ) type ActionOnShutdown int - -const ( - ActionOnShutdownDestroy ActionOnShutdown = 1 - ActionOnShutdownRestart ActionOnShutdown = 2 - ActionOnShutdownRestartRename ActionOnShutdown = 3 - ActionOnShutdownPreserve ActionOnShutdown = 4 - ActionOnShutdownCoredumpDestroy ActionOnShutdown = 5 - ActionOnShutdownCoredumpRestart ActionOnShutdown = 6 - ActionOnShutdownSoftReset ActionOnShutdown = 7 +const( +ActionOnShutdownDestroy ActionOnShutdown = 1 +ActionOnShutdownRestart ActionOnShutdown = 2 +ActionOnShutdownRestartRename ActionOnShutdown = 3 +ActionOnShutdownPreserve ActionOnShutdown = 4 +ActionOnShutdownCoredumpDestroy ActionOnShutdown = 5 +ActionOnShutdownCoredumpRestart ActionOnShutdown = 6 +ActionOnShutdownSoftReset ActionOnShutdown = 7 ) type Trigger int - -const ( - TriggerUnknown Trigger = 0 - TriggerPower Trigger = 1 - TriggerSleep Trigger = 2 - TriggerNmi Trigger = 3 - TriggerInit Trigger = 4 - TriggerReset Trigger = 5 - TriggerS3Resume Trigger = 6 +const( +TriggerUnknown Trigger = 0 +TriggerPower Trigger = 1 +TriggerSleep Trigger = 2 +TriggerNmi Trigger = 3 +TriggerInit Trigger = 4 +TriggerReset Trigger = 5 +TriggerS3Resume Trigger = 6 ) type TscMode int - -const ( - TscModeDefault TscMode = 0 - TscModeAlwaysEmulate TscMode = 1 - TscModeNative TscMode = 2 - TscModeNativeParavirt TscMode = 3 +const( +TscModeDefault TscMode = 0 +TscModeAlwaysEmulate TscMode = 1 +TscModeNative TscMode = 2 +TscModeNativeParavirt TscMode = 3 ) type GfxPassthruKind int - -const ( - GfxPassthruKindDefault GfxPassthruKind = 0 - GfxPassthruKindIgd GfxPassthruKind = 1 +const( +GfxPassthruKindDefault GfxPassthruKind = 0 +GfxPassthruKindIgd GfxPassthruKind = 1 ) type TimerMode int - -const ( - TimerModeUnknown TimerMode = -1 - TimerModeDelayForMissedTicks TimerMode = 0 - TimerModeNoDelayForMissedTicks TimerMode = 1 - TimerModeNoMissedTicksPending TimerMode = 2 - TimerModeOneMissedTickPending TimerMode = 3 +const( +TimerModeUnknown TimerMode = -1 +TimerModeDelayForMissedTicks TimerMode = 0 +TimerModeNoDelayForMissedTicks TimerMode = 1 +TimerModeNoMissedTicksPending TimerMode = 2 +TimerModeOneMissedTickPending TimerMode = 3 ) type BiosType int - -const ( - BiosTypeUnknown BiosType = 0 - BiosTypeRombios BiosType = 1 - BiosTypeSeabios BiosType = 2 - BiosTypeOvmf BiosType = 3 +const( +BiosTypeUnknown BiosType = 0 +BiosTypeRombios BiosType = 1 +BiosTypeSeabios BiosType = 2 +BiosTypeOvmf BiosType = 3 ) type Scheduler int - -const ( - SchedulerUnknown Scheduler = 0 - SchedulerSedf Scheduler = 4 - SchedulerCredit Scheduler = 5 - SchedulerCredit2 Scheduler = 6 - SchedulerArinc653 Scheduler = 7 - SchedulerRtds Scheduler = 8 - SchedulerNull Scheduler = 9 +const( +SchedulerUnknown Scheduler = 0 +SchedulerSedf Scheduler = 4 +SchedulerCredit Scheduler = 5 +SchedulerCredit2 Scheduler = 6 +SchedulerArinc653 Scheduler = 7 +SchedulerRtds Scheduler = 8 +SchedulerNull Scheduler = 9 ) type ShutdownReason int - -const ( - ShutdownReasonUnknown ShutdownReason = -1 - ShutdownReasonPoweroff ShutdownReason = 0 - ShutdownReasonReboot ShutdownReason = 1 - ShutdownReasonSuspend ShutdownReason = 2 - ShutdownReasonCrash ShutdownReason = 3 - ShutdownReasonWatchdog ShutdownReason = 4 - ShutdownReasonSoftReset ShutdownReason = 5 +const( +ShutdownReasonUnknown ShutdownReason = -1 +ShutdownReasonPoweroff ShutdownReason = 0 +ShutdownReasonReboot ShutdownReason = 1 +ShutdownReasonSuspend ShutdownReason = 2 +ShutdownReasonCrash ShutdownReason = 3 +ShutdownReasonWatchdog ShutdownReason = 4 +ShutdownReasonSoftReset ShutdownReason = 5 ) type VgaInterfaceType int - -const ( - VgaInterfaceTypeUnknown VgaInterfaceType = 0 - VgaInterfaceTypeCirrus VgaInterfaceType = 1 - VgaInterfaceTypeStd VgaInterfaceType = 2 - VgaInterfaceTypeNone VgaInterfaceType = 3 - VgaInterfaceTypeQxl VgaInterfaceType = 4 +const( +VgaInterfaceTypeUnknown VgaInterfaceType = 0 +VgaInterfaceTypeCirrus VgaInterfaceType = 1 +VgaInterfaceTypeStd VgaInterfaceType = 2 +VgaInterfaceTypeNone VgaInterfaceType = 3 +VgaInterfaceTypeQxl VgaInterfaceType = 4 ) type VendorDevice int - -const ( - VendorDeviceNone VendorDevice = 0 - VendorDeviceXenserver VendorDevice = 1 +const( +VendorDeviceNone VendorDevice = 0 +VendorDeviceXenserver VendorDevice = 1 ) type ViridianEnlightenment int - -const ( - ViridianEnlightenmentBase ViridianEnlightenment = 0 - ViridianEnlightenmentFreq ViridianEnlightenment = 1 - ViridianEnlightenmentTimeRefCount ViridianEnlightenment = 2 - ViridianEnlightenmentReferenceTsc ViridianEnlightenment = 3 - ViridianEnlightenmentHcallRemoteTlbFlush ViridianEnlightenment = 4 - ViridianEnlightenmentApicAssist ViridianEnlightenment = 5 - ViridianEnlightenmentCrashCtl ViridianEnlightenment = 6 - ViridianEnlightenmentSynic ViridianEnlightenment = 7 - ViridianEnlightenmentStimer ViridianEnlightenment = 8 - ViridianEnlightenmentHcallIpi ViridianEnlightenment = 9 +const( +ViridianEnlightenmentBase ViridianEnlightenment = 0 +ViridianEnlightenmentFreq ViridianEnlightenment = 1 +ViridianEnlightenmentTimeRefCount ViridianEnlightenment = 2 +ViridianEnlightenmentReferenceTsc ViridianEnlightenment = 3 +ViridianEnlightenmentHcallRemoteTlbFlush ViridianEnlightenment = 4 +ViridianEnlightenmentApicAssist ViridianEnlightenment = 5 +ViridianEnlightenmentCrashCtl ViridianEnlightenment = 6 +ViridianEnlightenmentSynic ViridianEnlightenment = 7 +ViridianEnlightenmentStimer ViridianEnlightenment = 8 +ViridianEnlightenmentHcallIpi ViridianEnlightenment = 9 ) type Hdtype int - -const ( - HdtypeIde Hdtype = 1 - HdtypeAhci Hdtype = 2 +const( +HdtypeIde Hdtype = 1 +HdtypeAhci Hdtype = 2 ) type CheckpointedStream int - -const ( - CheckpointedStreamNone CheckpointedStream = 0 - CheckpointedStreamRemus CheckpointedStream = 1 - CheckpointedStreamColo CheckpointedStream = 2 +const( +CheckpointedStreamNone CheckpointedStream = 0 +CheckpointedStreamRemus CheckpointedStream = 1 +CheckpointedStreamColo CheckpointedStream = 2 ) type VuartType int - -const ( - VuartTypeUnknown VuartType = 0 - VuartTypeSbsaUart VuartType = 1 +const( +VuartTypeUnknown VuartType = 0 +VuartTypeSbsaUart VuartType = 1 ) type VkbBackend int - -const ( - VkbBackendUnknown VkbBackend = 0 - VkbBackendQemu VkbBackend = 1 - VkbBackendLinux VkbBackend = 2 +const( +VkbBackendUnknown VkbBackend = 0 +VkbBackendQemu VkbBackend = 1 +VkbBackendLinux VkbBackend = 2 ) type Passthrough int - -const ( - PassthroughDefault Passthrough = 0 - PassthroughDisabled Passthrough = 1 - PassthroughEnabled Passthrough = 2 - PassthroughSyncPt Passthrough = 3 - PassthroughSharePt Passthrough = 4 +const( +PassthroughDefault Passthrough = 0 +PassthroughDisabled Passthrough = 1 +PassthroughEnabled Passthrough = 2 +PassthroughSyncPt Passthrough = 3 +PassthroughSharePt Passthrough = 4 ) type IoportRange struct { - First uint32 - Number uint32 +First uint32 +Number uint32 } type IomemRange struct { - Start uint64 - Number uint64 - Gfn uint64 +Start uint64 +Number uint64 +Gfn uint64 } type VgaInterfaceInfo struct { - Kind VgaInterfaceType +Kind VgaInterfaceType } type VncInfo struct { - Enable Defbool - Listen string - Passwd string - Display int - Findunused Defbool +Enable Defbool +Listen string +Passwd string +Display int +Findunused Defbool } type SpiceInfo struct { - Enable Defbool - Port int - TlsPort int - Host string - DisableTicketing Defbool - Passwd string - AgentMouse Defbool - Vdagent Defbool - ClipboardSharing Defbool - Usbredirection int - ImageCompression string - StreamingVideo string +Enable Defbool +Port int +TlsPort int +Host string +DisableTicketing Defbool +Passwd string +AgentMouse Defbool +Vdagent Defbool +ClipboardSharing Defbool +Usbredirection int +ImageCompression string +StreamingVideo string } type SdlInfo struct { - Enable Defbool - Opengl Defbool - Display string - Xauthority string +Enable Defbool +Opengl Defbool +Display string +Xauthority string } type Dominfo struct { - Uuid Uuid - Domid Domid - Ssidref uint32 - SsidLabel string - Running bool - Blocked bool - Paused bool - Shutdown bool - Dying bool - NeverStop bool - ShutdownReason ShutdownReason - OutstandingMemkb uint64 - CurrentMemkb uint64 - SharedMemkb uint64 - PagedMemkb uint64 - MaxMemkb uint64 - CpuTime uint64 - VcpuMaxId uint32 - VcpuOnline uint32 - Cpupool uint32 - DomainType DomainType +Uuid Uuid +Domid Domid +Ssidref uint32 +SsidLabel string +Running bool +Blocked bool +Paused bool +Shutdown bool +Dying bool +NeverStop bool +ShutdownReason ShutdownReason +OutstandingMemkb uint64 +CurrentMemkb uint64 +SharedMemkb uint64 +PagedMemkb uint64 +MaxMemkb uint64 +CpuTime uint64 +VcpuMaxId uint32 +VcpuOnline uint32 +Cpupool uint32 +DomainType DomainType } type Cpupoolinfo struct { - Poolid uint32 - PoolName string - Sched Scheduler - NDom uint32 - Cpumap Bitmap +Poolid uint32 +PoolName string +Sched Scheduler +NDom uint32 +Cpumap Bitmap } type Channelinfo struct { - Backend string - BackendId uint32 - Frontend string - FrontendId uint32 - Devid Devid - State int - Evtch int - Rref int - Connection ChannelConnection - ConnectionUnion channelinfoConnectionUnion +Backend string +BackendId uint32 +Frontend string +FrontendId uint32 +Devid Devid +State int +Evtch int +Rref int +Connection ChannelConnection +ConnectionUnion channelinfoConnectionUnion } type channelinfoConnectionUnion interface { - ischannelinfoConnectionUnion() +ischannelinfoConnectionUnion() } type ChannelinfoConnectionUnionPty struct { - Path string +Path string } -func (x ChannelinfoConnectionUnionPty) ischannelinfoConnectionUnion() {} +func (x ChannelinfoConnectionUnionPty) ischannelinfoConnectionUnion(){} type Vminfo struct { - Uuid Uuid - Domid Domid +Uuid Uuid +Domid Domid } type VersionInfo struct { - XenVersionMajor int - XenVersionMinor int - XenVersionExtra string - Compiler string - CompileBy string - CompileDomain string - CompileDate string - Capabilities string - Changeset string - VirtStart uint64 - Pagesize int - Commandline string - BuildId string +XenVersionMajor int +XenVersionMinor int +XenVersionExtra string +Compiler string +CompileBy string +CompileDomain string +CompileDate string +Capabilities string +Changeset string +VirtStart uint64 +Pagesize int +Commandline string +BuildId string } type DomainCreateInfo struct { - Type DomainType - Hap Defbool - Oos Defbool - Ssidref uint32 - SsidLabel string - Name string - Domid Domid - Uuid Uuid - Xsdata KeyValueList - Platformdata KeyValueList - Poolid uint32 - PoolName string - RunHotplugScripts Defbool - DriverDomain Defbool - Passthrough Passthrough - XendSuspendEvtchnCompat Defbool +Type DomainType +Hap Defbool +Oos Defbool +Ssidref uint32 +SsidLabel string +Name string +Domid Domid +Uuid Uuid +Xsdata KeyValueList +Platformdata KeyValueList +Poolid uint32 +PoolName string +RunHotplugScripts Defbool +DriverDomain Defbool +Passthrough Passthrough +XendSuspendEvtchnCompat Defbool } type DomainRestoreParams struct { - CheckpointedStream int - StreamVersion uint32 - ColoProxyScript string - UserspaceColoProxy Defbool +CheckpointedStream int +StreamVersion uint32 +ColoProxyScript string +UserspaceColoProxy Defbool } type SchedParams struct { - Vcpuid int - Weight int - Cap int - Period int - Extratime int - Budget int +Vcpuid int +Weight int +Cap int +Period int +Extratime int +Budget int } type VcpuSchedParams struct { - Sched Scheduler - Vcpus []SchedParams +Sched Scheduler +Vcpus []SchedParams } type DomainSchedParams struct { - Sched Scheduler - Weight int - Cap int - Period int - Budget int - Extratime int - Slice int - Latency int +Sched Scheduler +Weight int +Cap int +Period int +Budget int +Extratime int +Slice int +Latency int } type VnodeInfo struct { - Memkb uint64 - Distances []uint32 - Pnode uint32 - Vcpus Bitmap +Memkb uint64 +Distances []uint32 +Pnode uint32 +Vcpus Bitmap } type GicVersion int - -const ( - GicVersionDefault GicVersion = 0 - GicVersionV2 GicVersion = 32 - GicVersionV3 GicVersion = 48 +const( +GicVersionDefault GicVersion = 0 +GicVersionV2 GicVersion = 32 +GicVersionV3 GicVersion = 48 ) type TeeType int - -const ( - TeeTypeNone TeeType = 0 - TeeTypeOptee TeeType = 1 +const( +TeeTypeNone TeeType = 0 +TeeTypeOptee TeeType = 1 ) type RdmReserve struct { - Strategy RdmReserveStrategy - Policy RdmReservePolicy +Strategy RdmReserveStrategy +Policy RdmReservePolicy } type Altp2MMode int - -const ( - Altp2MModeDisabled Altp2MMode = 0 - Altp2MModeMixed Altp2MMode = 1 - Altp2MModeExternal Altp2MMode = 2 - Altp2MModeLimited Altp2MMode = 3 +const( +Altp2MModeDisabled Altp2MMode = 0 +Altp2MModeMixed Altp2MMode = 1 +Altp2MModeExternal Altp2MMode = 2 +Altp2MModeLimited Altp2MMode = 3 ) type DomainBuildInfo struct { - MaxVcpus int - AvailVcpus Bitmap - Cpumap Bitmap - Nodemap Bitmap - VcpuHardAffinity []Bitmap - VcpuSoftAffinity []Bitmap - NumaPlacement Defbool - TscMode TscMode - MaxMemkb uint64 - TargetMemkb uint64 - VideoMemkb uint64 - ShadowMemkb uint64 - IommuMemkb uint64 - RtcTimeoffset uint32 - ExecSsidref uint32 - ExecSsidLabel string - Localtime Defbool - DisableMigrate Defbool - Cpuid CpuidPolicyList - BlkdevStart string - VnumaNodes []VnodeInfo - MaxGrantFrames uint32 - MaxMaptrackFrames uint32 - DeviceModelVersion DeviceModelVersion - DeviceModelStubdomain Defbool - StubdomainMemkb uint64 - StubdomainKernel string - StubdomainRamdisk string - DeviceModel string - DeviceModelSsidref uint32 - DeviceModelSsidLabel string - DeviceModelUser string - Extra StringList - ExtraPv StringList - ExtraHvm StringList - SchedParams DomainSchedParams - Ioports []IoportRange - Irqs []uint32 - Iomem []IomemRange - ClaimMode Defbool - EventChannels uint32 - Kernel string - Cmdline string - Ramdisk string - DeviceTree string - Acpi Defbool - Bootloader string - BootloaderArgs StringList - TimerMode TimerMode - NestedHvm Defbool - Apic Defbool - DmRestrict Defbool - Tee TeeType - Type DomainType - TypeUnion domainBuildInfoTypeUnion - ArchArm struct { - GicVersion GicVersion - Vuart VuartType - } - Altp2M Altp2MMode +MaxVcpus int +AvailVcpus Bitmap +Cpumap Bitmap +Nodemap Bitmap +VcpuHardAffinity []Bitmap +VcpuSoftAffinity []Bitmap +NumaPlacement Defbool +TscMode TscMode +MaxMemkb uint64 +TargetMemkb uint64 +VideoMemkb uint64 +ShadowMemkb uint64 +IommuMemkb uint64 +RtcTimeoffset uint32 +ExecSsidref uint32 +ExecSsidLabel string +Localtime Defbool +DisableMigrate Defbool +Cpuid CpuidPolicyList +BlkdevStart string +VnumaNodes []VnodeInfo +MaxGrantFrames uint32 +MaxMaptrackFrames uint32 +DeviceModelVersion DeviceModelVersion +DeviceModelStubdomain Defbool +StubdomainMemkb uint64 +StubdomainKernel string +StubdomainRamdisk string +DeviceModel string +DeviceModelSsidref uint32 +DeviceModelSsidLabel string +DeviceModelUser string +Extra StringList +ExtraPv StringList +ExtraHvm StringList +SchedParams DomainSchedParams +Ioports []IoportRange +Irqs []uint32 +Iomem []IomemRange +ClaimMode Defbool +EventChannels uint32 +Kernel string +Cmdline string +Ramdisk string +DeviceTree string +Acpi Defbool +Bootloader string +BootloaderArgs StringList +TimerMode TimerMode +NestedHvm Defbool +Apic Defbool +DmRestrict Defbool +Tee TeeType +Type DomainType +TypeUnion domainBuildInfoTypeUnion +ArchArm struct { +GicVersion GicVersion +Vuart VuartType +} +Altp2M Altp2MMode } type domainBuildInfoTypeUnion interface { - isdomainBuildInfoTypeUnion() +isdomainBuildInfoTypeUnion() } type DomainBuildInfoTypeUnionHvm struct { - Firmware string - Bios BiosType - Pae Defbool - Apic Defbool - Acpi Defbool - AcpiS3 Defbool - AcpiS4 Defbool - AcpiLaptopSlate Defbool - Nx Defbool - Viridian Defbool - ViridianEnable Bitmap - ViridianDisable Bitmap - Timeoffset string - Hpet Defbool - VptAlign Defbool - MmioHoleMemkb uint64 - TimerMode TimerMode - NestedHvm Defbool - Altp2M Defbool - SystemFirmware string - SmbiosFirmware string - AcpiFirmware string - Hdtype Hdtype - Nographic Defbool - Vga VgaInterfaceInfo - Vnc VncInfo - Keymap string - Sdl SdlInfo - Spice SpiceInfo - GfxPassthru Defbool - GfxPassthruKind GfxPassthruKind - Serial string - Boot string - Usb Defbool - Usbversion int - Usbdevice string - VkbDevice Defbool - Soundhw string - XenPlatformPci Defbool - UsbdeviceList StringList - VendorDevice VendorDevice - MsVmGenid MsVmGenid - SerialList StringList - Rdm RdmReserve - RdmMemBoundaryMemkb uint64 - McaCaps uint64 -} - -func (x DomainBuildInfoTypeUnionHvm) isdomainBuildInfoTypeUnion() {} +Firmware string +Bios BiosType +Pae Defbool +Apic Defbool +Acpi Defbool +AcpiS3 Defbool +AcpiS4 Defbool +AcpiLaptopSlate Defbool +Nx Defbool +Viridian Defbool +ViridianEnable Bitmap +ViridianDisable Bitmap +Timeoffset string +Hpet Defbool +VptAlign Defbool +MmioHoleMemkb uint64 +TimerMode TimerMode +NestedHvm Defbool +Altp2M Defbool +SystemFirmware string +SmbiosFirmware string +AcpiFirmware string +Hdtype Hdtype +Nographic Defbool +Vga VgaInterfaceInfo +Vnc VncInfo +Keymap string +Sdl SdlInfo +Spice SpiceInfo +GfxPassthru Defbool +GfxPassthruKind GfxPassthruKind +Serial string +Boot string +Usb Defbool +Usbversion int +Usbdevice string +VkbDevice Defbool +Soundhw string +XenPlatformPci Defbool +UsbdeviceList StringList +VendorDevice VendorDevice +MsVmGenid MsVmGenid +SerialList StringList +Rdm RdmReserve +RdmMemBoundaryMemkb uint64 +McaCaps uint64 +} + +func (x DomainBuildInfoTypeUnionHvm) isdomainBuildInfoTypeUnion(){} type DomainBuildInfoTypeUnionPv struct { - Kernel string - SlackMemkb uint64 - Bootloader string - BootloaderArgs StringList - Cmdline string - Ramdisk string - Features string - E820Host Defbool +Kernel string +SlackMemkb uint64 +Bootloader string +BootloaderArgs StringList +Cmdline string +Ramdisk string +Features string +E820Host Defbool } -func (x DomainBuildInfoTypeUnionPv) isdomainBuildInfoTypeUnion() {} +func (x DomainBuildInfoTypeUnionPv) isdomainBuildInfoTypeUnion(){} type DomainBuildInfoTypeUnionPvh struct { - Pvshim Defbool - PvshimPath string - PvshimCmdline string - PvshimExtra string +Pvshim Defbool +PvshimPath string +PvshimCmdline string +PvshimExtra string } -func (x DomainBuildInfoTypeUnionPvh) isdomainBuildInfoTypeUnion() {} +func (x DomainBuildInfoTypeUnionPvh) isdomainBuildInfoTypeUnion(){} type DeviceVfb struct { - BackendDomid Domid - BackendDomname string - Devid Devid - Vnc VncInfo - Sdl SdlInfo - Keymap string +BackendDomid Domid +BackendDomname string +Devid Devid +Vnc VncInfo +Sdl SdlInfo +Keymap string } type DeviceVkb struct { - BackendDomid Domid - BackendDomname string - Devid Devid - BackendType VkbBackend - UniqueId string - FeatureDisableKeyboard bool - FeatureDisablePointer bool - FeatureAbsPointer bool - FeatureRawPointer bool - FeatureMultiTouch bool - Width uint32 - Height uint32 - MultiTouchWidth uint32 - MultiTouchHeight uint32 - MultiTouchNumContacts uint32 +BackendDomid Domid +BackendDomname string +Devid Devid +BackendType VkbBackend +UniqueId string +FeatureDisableKeyboard bool +FeatureDisablePointer bool +FeatureAbsPointer bool +FeatureRawPointer bool +FeatureMultiTouch bool +Width uint32 +Height uint32 +MultiTouchWidth uint32 +MultiTouchHeight uint32 +MultiTouchNumContacts uint32 } type DeviceDisk struct { - BackendDomid Domid - BackendDomname string - PdevPath string - Vdev string - Backend DiskBackend - Format DiskFormat - Script string - Removable int - Readwrite int - IsCdrom int - DirectIoSafe bool - DiscardEnable Defbool - ColoEnable Defbool - ColoRestoreEnable Defbool - ColoHost string - ColoPort int - ColoExport string - ActiveDisk string - HiddenDisk string +BackendDomid Domid +BackendDomname string +PdevPath string +Vdev string +Backend DiskBackend +Format DiskFormat +Script string +Removable int +Readwrite int +IsCdrom int +DirectIoSafe bool +DiscardEnable Defbool +ColoEnable Defbool +ColoRestoreEnable Defbool +ColoHost string +ColoPort int +ColoExport string +ActiveDisk string +HiddenDisk string } type DeviceNic struct { - BackendDomid Domid - BackendDomname string - Devid Devid - Mtu int - Model string - Mac Mac - Ip string - Bridge string - Ifname string - Script string - Nictype NicType - RateBytesPerInterval uint64 - RateIntervalUsecs uint32 - Gatewaydev string - ColoftForwarddev string - ColoSockMirrorId string - ColoSockMirrorIp string - ColoSockMirrorPort string - ColoSockComparePriInId string - ColoSockComparePriInIp string - ColoSockComparePriInPort string - ColoSockCompareSecInId string - ColoSockCompareSecInIp string - ColoSockCompareSecInPort string - ColoSockCompareNotifyId string - ColoSockCompareNotifyIp string - ColoSockCompareNotifyPort string - ColoSockRedirector0Id string - ColoSockRedirector0Ip string - ColoSockRedirector0Port string - ColoSockRedirector1Id string - ColoSockRedirector1Ip string - ColoSockRedirector1Port string - ColoSockRedirector2Id string - ColoSockRedirector2Ip string - ColoSockRedirector2Port string - ColoFilterMirrorQueue string - ColoFilterMirrorOutdev string - ColoFilterRedirector0Queue string - ColoFilterRedirector0Indev string - ColoFilterRedirector0Outdev string - ColoFilterRedirector1Queue string - ColoFilterRedirector1Indev string - ColoFilterRedirector1Outdev string - ColoComparePriIn string - ColoCompareSecIn string - ColoCompareOut string - ColoCompareNotifyDev string - ColoSockSecRedirector0Id string - ColoSockSecRedirector0Ip string - ColoSockSecRedirector0Port string - ColoSockSecRedirector1Id string - ColoSockSecRedirector1Ip string - ColoSockSecRedirector1Port string - ColoFilterSecRedirector0Queue string - ColoFilterSecRedirector0Indev string - ColoFilterSecRedirector0Outdev string - ColoFilterSecRedirector1Queue string - ColoFilterSecRedirector1Indev string - ColoFilterSecRedirector1Outdev string - ColoFilterSecRewriter0Queue string - ColoCheckpointHost string - ColoCheckpointPort string +BackendDomid Domid +BackendDomname string +Devid Devid +Mtu int +Model string +Mac Mac +Ip string +Bridge string +Ifname string +Script string +Nictype NicType +RateBytesPerInterval uint64 +RateIntervalUsecs uint32 +Gatewaydev string +ColoftForwarddev string +ColoSockMirrorId string +ColoSockMirrorIp string +ColoSockMirrorPort string +ColoSockComparePriInId string +ColoSockComparePriInIp string +ColoSockComparePriInPort string +ColoSockCompareSecInId string +ColoSockCompareSecInIp string +ColoSockCompareSecInPort string +ColoSockCompareNotifyId string +ColoSockCompareNotifyIp string +ColoSockCompareNotifyPort string +ColoSockRedirector0Id string +ColoSockRedirector0Ip string +ColoSockRedirector0Port string +ColoSockRedirector1Id string +ColoSockRedirector1Ip string +ColoSockRedirector1Port string +ColoSockRedirector2Id string +ColoSockRedirector2Ip string +ColoSockRedirector2Port string +ColoFilterMirrorQueue string +ColoFilterMirrorOutdev string +ColoFilterRedirector0Queue string +ColoFilterRedirector0Indev string +ColoFilterRedirector0Outdev string +ColoFilterRedirector1Queue string +ColoFilterRedirector1Indev string +ColoFilterRedirector1Outdev string +ColoComparePriIn string +ColoCompareSecIn string +ColoCompareOut string +ColoCompareNotifyDev string +ColoSockSecRedirector0Id string +ColoSockSecRedirector0Ip string +ColoSockSecRedirector0Port string +ColoSockSecRedirector1Id string +ColoSockSecRedirector1Ip string +ColoSockSecRedirector1Port string +ColoFilterSecRedirector0Queue string +ColoFilterSecRedirector0Indev string +ColoFilterSecRedirector0Outdev string +ColoFilterSecRedirector1Queue string +ColoFilterSecRedirector1Indev string +ColoFilterSecRedirector1Outdev string +ColoFilterSecRewriter0Queue string +ColoCheckpointHost string +ColoCheckpointPort string } type DevicePci struct { - Func byte - Dev byte - Bus byte - Domain int - Vdevfn uint32 - VfuncMask uint32 - Msitranslate bool - PowerMgmt bool - Permissive bool - Seize bool - RdmPolicy RdmReservePolicy +Func byte +Dev byte +Bus byte +Domain int +Vdevfn uint32 +VfuncMask uint32 +Msitranslate bool +PowerMgmt bool +Permissive bool +Seize bool +RdmPolicy RdmReservePolicy } type DeviceRdm struct { - Start uint64 - Size uint64 - Policy RdmReservePolicy +Start uint64 +Size uint64 +Policy RdmReservePolicy } type UsbctrlType int - -const ( - UsbctrlTypeAuto UsbctrlType = 0 - UsbctrlTypePv UsbctrlType = 1 - UsbctrlTypeDevicemodel UsbctrlType = 2 - UsbctrlTypeQusb UsbctrlType = 3 +const( +UsbctrlTypeAuto UsbctrlType = 0 +UsbctrlTypePv UsbctrlType = 1 +UsbctrlTypeDevicemodel UsbctrlType = 2 +UsbctrlTypeQusb UsbctrlType = 3 ) type UsbdevType int - -const ( - UsbdevTypeHostdev UsbdevType = 1 +const( +UsbdevTypeHostdev UsbdevType = 1 ) type DeviceUsbctrl struct { - Type UsbctrlType - Devid Devid - Version int - Ports int - BackendDomid Domid - BackendDomname string +Type UsbctrlType +Devid Devid +Version int +Ports int +BackendDomid Domid +BackendDomname string } type DeviceUsbdev struct { - Ctrl Devid - Port int - Type UsbdevType - TypeUnion deviceUsbdevTypeUnion +Ctrl Devid +Port int +Type UsbdevType +TypeUnion deviceUsbdevTypeUnion } type deviceUsbdevTypeUnion interface { - isdeviceUsbdevTypeUnion() +isdeviceUsbdevTypeUnion() } type DeviceUsbdevTypeUnionHostdev struct { - Hostbus byte - Hostaddr byte +Hostbus byte +Hostaddr byte } -func (x DeviceUsbdevTypeUnionHostdev) isdeviceUsbdevTypeUnion() {} +func (x DeviceUsbdevTypeUnionHostdev) isdeviceUsbdevTypeUnion(){} type DeviceDtdev struct { - Path string +Path string } type DeviceVtpm struct { - BackendDomid Domid - BackendDomname string - Devid Devid - Uuid Uuid +BackendDomid Domid +BackendDomname string +Devid Devid +Uuid Uuid } type DeviceP9 struct { - BackendDomid Domid - BackendDomname string - Tag string - Path string - SecurityModel string - Devid Devid +BackendDomid Domid +BackendDomname string +Tag string +Path string +SecurityModel string +Devid Devid } type DevicePvcallsif struct { - BackendDomid Domid - BackendDomname string - Devid Devid +BackendDomid Domid +BackendDomname string +Devid Devid } type DeviceChannel struct { - BackendDomid Domid - BackendDomname string - Devid Devid - Name string - Connection ChannelConnection - ConnectionUnion deviceChannelConnectionUnion +BackendDomid Domid +BackendDomname string +Devid Devid +Name string +Connection ChannelConnection +ConnectionUnion deviceChannelConnectionUnion } type deviceChannelConnectionUnion interface { - isdeviceChannelConnectionUnion() +isdeviceChannelConnectionUnion() } type DeviceChannelConnectionUnionSocket struct { - Path string +Path string } -func (x DeviceChannelConnectionUnionSocket) isdeviceChannelConnectionUnion() {} +func (x DeviceChannelConnectionUnionSocket) isdeviceChannelConnectionUnion(){} type ConnectorParam struct { - UniqueId string - Width uint32 - Height uint32 +UniqueId string +Width uint32 +Height uint32 } type DeviceVdispl struct { - BackendDomid Domid - BackendDomname string - Devid Devid - BeAlloc bool - Connectors []ConnectorParam +BackendDomid Domid +BackendDomname string +Devid Devid +BeAlloc bool +Connectors []ConnectorParam } type VsndPcmFormat int - -const ( - VsndPcmFormatS8 VsndPcmFormat = 1 - VsndPcmFormatU8 VsndPcmFormat = 2 - VsndPcmFormatS16Le VsndPcmFormat = 3 - VsndPcmFormatS16Be VsndPcmFormat = 4 - VsndPcmFormatU16Le VsndPcmFormat = 5 - VsndPcmFormatU16Be VsndPcmFormat = 6 - VsndPcmFormatS24Le VsndPcmFormat = 7 - VsndPcmFormatS24Be VsndPcmFormat = 8 - VsndPcmFormatU24Le VsndPcmFormat = 9 - VsndPcmFormatU24Be VsndPcmFormat = 10 - VsndPcmFormatS32Le VsndPcmFormat = 11 - VsndPcmFormatS32Be VsndPcmFormat = 12 - VsndPcmFormatU32Le VsndPcmFormat = 13 - VsndPcmFormatU32Be VsndPcmFormat = 14 - VsndPcmFormatF32Le VsndPcmFormat = 15 - VsndPcmFormatF32Be VsndPcmFormat = 16 - VsndPcmFormatF64Le VsndPcmFormat = 17 - VsndPcmFormatF64Be VsndPcmFormat = 18 - VsndPcmFormatIec958SubframeLe VsndPcmFormat = 19 - VsndPcmFormatIec958SubframeBe VsndPcmFormat = 20 - VsndPcmFormatMuLaw VsndPcmFormat = 21 - VsndPcmFormatALaw VsndPcmFormat = 22 - VsndPcmFormatImaAdpcm VsndPcmFormat = 23 - VsndPcmFormatMpeg VsndPcmFormat = 24 - VsndPcmFormatGsm VsndPcmFormat = 25 +const( +VsndPcmFormatS8 VsndPcmFormat = 1 +VsndPcmFormatU8 VsndPcmFormat = 2 +VsndPcmFormatS16Le VsndPcmFormat = 3 +VsndPcmFormatS16Be VsndPcmFormat = 4 +VsndPcmFormatU16Le VsndPcmFormat = 5 +VsndPcmFormatU16Be VsndPcmFormat = 6 +VsndPcmFormatS24Le VsndPcmFormat = 7 +VsndPcmFormatS24Be VsndPcmFormat = 8 +VsndPcmFormatU24Le VsndPcmFormat = 9 +VsndPcmFormatU24Be VsndPcmFormat = 10 +VsndPcmFormatS32Le VsndPcmFormat = 11 +VsndPcmFormatS32Be VsndPcmFormat = 12 +VsndPcmFormatU32Le VsndPcmFormat = 13 +VsndPcmFormatU32Be VsndPcmFormat = 14 +VsndPcmFormatF32Le VsndPcmFormat = 15 +VsndPcmFormatF32Be VsndPcmFormat = 16 +VsndPcmFormatF64Le VsndPcmFormat = 17 +VsndPcmFormatF64Be VsndPcmFormat = 18 +VsndPcmFormatIec958SubframeLe VsndPcmFormat = 19 +VsndPcmFormatIec958SubframeBe VsndPcmFormat = 20 +VsndPcmFormatMuLaw VsndPcmFormat = 21 +VsndPcmFormatALaw VsndPcmFormat = 22 +VsndPcmFormatImaAdpcm VsndPcmFormat = 23 +VsndPcmFormatMpeg VsndPcmFormat = 24 +VsndPcmFormatGsm VsndPcmFormat = 25 ) type VsndParams struct { - SampleRates []uint32 - SampleFormats []VsndPcmFormat - ChannelsMin uint32 - ChannelsMax uint32 - BufferSize uint32 +SampleRates []uint32 +SampleFormats []VsndPcmFormat +ChannelsMin uint32 +ChannelsMax uint32 +BufferSize uint32 } type VsndStreamType int - -const ( - VsndStreamTypeP VsndStreamType = 1 - VsndStreamTypeC VsndStreamType = 2 +const( +VsndStreamTypeP VsndStreamType = 1 +VsndStreamTypeC VsndStreamType = 2 ) type VsndStream struct { - UniqueId string - Type VsndStreamType - Params VsndParams +UniqueId string +Type VsndStreamType +Params VsndParams } type VsndPcm struct { - Name string - Params VsndParams - Streams []VsndStream +Name string +Params VsndParams +Streams []VsndStream } type DeviceVsnd struct { - BackendDomid Domid - BackendDomname string - Devid Devid - ShortName string - LongName string - Params VsndParams - Pcms []VsndPcm +BackendDomid Domid +BackendDomname string +Devid Devid +ShortName string +LongName string +Params VsndParams +Pcms []VsndPcm } type DomainConfig struct { - CInfo DomainCreateInfo - BInfo DomainBuildInfo - Disks []DeviceDisk - Nics []DeviceNic - Pcidevs []DevicePci - Rdms []DeviceRdm - Dtdevs []DeviceDtdev - Vfbs []DeviceVfb - Vkbs []DeviceVkb - Vtpms []DeviceVtpm - P9S []DeviceP9 - Pvcallsifs []DevicePvcallsif - Vdispls []DeviceVdispl - Vsnds []DeviceVsnd - Channels []DeviceChannel - Usbctrls []DeviceUsbctrl - Usbdevs []DeviceUsbdev - OnPoweroff ActionOnShutdown - OnReboot ActionOnShutdown - OnWatchdog ActionOnShutdown - OnCrash ActionOnShutdown - OnSoftReset ActionOnShutdown +CInfo DomainCreateInfo +BInfo DomainBuildInfo +Disks []DeviceDisk +Nics []DeviceNic +Pcidevs []DevicePci +Rdms []DeviceRdm +Dtdevs []DeviceDtdev +Vfbs []DeviceVfb +Vkbs []DeviceVkb +Vtpms []DeviceVtpm +P9S []DeviceP9 +Pvcallsifs []DevicePvcallsif +Vdispls []DeviceVdispl +Vsnds []DeviceVsnd +Channels []DeviceChannel +Usbctrls []DeviceUsbctrl +Usbdevs []DeviceUsbdev +OnPoweroff ActionOnShutdown +OnReboot ActionOnShutdown +OnWatchdog ActionOnShutdown +OnCrash ActionOnShutdown +OnSoftReset ActionOnShutdown } type Diskinfo struct { - Backend string - BackendId uint32 - Frontend string - FrontendId uint32 - Devid Devid - State int - Evtch int - Rref int +Backend string +BackendId uint32 +Frontend string +FrontendId uint32 +Devid Devid +State int +Evtch int +Rref int } type Nicinfo struct { - Backend string - BackendId uint32 - Frontend string - FrontendId uint32 - Devid Devid - State int - Evtch int - RrefTx int - RrefRx int +Backend string +BackendId uint32 +Frontend string +FrontendId uint32 +Devid Devid +State int +Evtch int +RrefTx int +RrefRx int } type Vtpminfo struct { - Backend string - BackendId uint32 - Frontend string - FrontendId uint32 - Devid Devid - State int - Evtch int - Rref int - Uuid Uuid +Backend string +BackendId uint32 +Frontend string +FrontendId uint32 +Devid Devid +State int +Evtch int +Rref int +Uuid Uuid } type Usbctrlinfo struct { - Type UsbctrlType - Devid Devid - Version int - Ports int - Backend string - BackendId uint32 - Frontend string - FrontendId uint32 - State int - Evtch int - RefUrb int - RefConn int +Type UsbctrlType +Devid Devid +Version int +Ports int +Backend string +BackendId uint32 +Frontend string +FrontendId uint32 +State int +Evtch int +RefUrb int +RefConn int } type Vcpuinfo struct { - Vcpuid uint32 - Cpu uint32 - Online bool - Blocked bool - Running bool - VcpuTime uint64 - Cpumap Bitmap - CpumapSoft Bitmap +Vcpuid uint32 +Cpu uint32 +Online bool +Blocked bool +Running bool +VcpuTime uint64 +Cpumap Bitmap +CpumapSoft Bitmap } type Physinfo struct { - ThreadsPerCore uint32 - CoresPerSocket uint32 - MaxCpuId uint32 - NrCpus uint32 - CpuKhz uint32 - TotalPages uint64 - FreePages uint64 - ScrubPages uint64 - OutstandingPages uint64 - SharingFreedPages uint64 - SharingUsedFrames uint64 - MaxPossibleMfn uint64 - NrNodes uint32 - HwCap Hwcap - CapHvm bool - CapPv bool - CapHvmDirectio bool - CapHap bool - CapShadow bool - CapIommuHapPtShare bool +ThreadsPerCore uint32 +CoresPerSocket uint32 +MaxCpuId uint32 +NrCpus uint32 +CpuKhz uint32 +TotalPages uint64 +FreePages uint64 +ScrubPages uint64 +OutstandingPages uint64 +SharingFreedPages uint64 +SharingUsedFrames uint64 +MaxPossibleMfn uint64 +NrNodes uint32 +HwCap Hwcap +CapHvm bool +CapPv bool +CapHvmDirectio bool +CapHap bool +CapShadow bool +CapIommuHapPtShare bool } type Connectorinfo struct { - UniqueId string - Width uint32 - Height uint32 - ReqEvtch int - ReqRref int - EvtEvtch int - EvtRref int +UniqueId string +Width uint32 +Height uint32 +ReqEvtch int +ReqRref int +EvtEvtch int +EvtRref int } type Vdisplinfo struct { - Backend string - BackendId uint32 - Frontend string - FrontendId uint32 - Devid Devid - State int - BeAlloc bool - Connectors []Connectorinfo +Backend string +BackendId uint32 +Frontend string +FrontendId uint32 +Devid Devid +State int +BeAlloc bool +Connectors []Connectorinfo } type Streaminfo struct { - ReqEvtch int - ReqRref int +ReqEvtch int +ReqRref int } type Pcminfo struct { - Streams []Streaminfo +Streams []Streaminfo } type Vsndinfo struct { - Backend string - BackendId uint32 - Frontend string - FrontendId uint32 - Devid Devid - State int - Pcms []Pcminfo +Backend string +BackendId uint32 +Frontend string +FrontendId uint32 +Devid Devid +State int +Pcms []Pcminfo } type Vkbinfo struct { - Backend string - BackendId uint32 - Frontend string - FrontendId uint32 - Devid Devid - State int - Evtch int - Rref int +Backend string +BackendId uint32 +Frontend string +FrontendId uint32 +Devid Devid +State int +Evtch int +Rref int } type Numainfo struct { - Size uint64 - Free uint64 - Dists []uint32 +Size uint64 +Free uint64 +Dists []uint32 } type Cputopology struct { - Core uint32 - Socket uint32 - Node uint32 +Core uint32 +Socket uint32 +Node uint32 } type Pcitopology struct { - Seg uint16 - Bus byte - Devfn byte - Node uint32 +Seg uint16 +Bus byte +Devfn byte +Node uint32 } type SchedCreditParams struct { - TsliceMs int - RatelimitUs int - VcpuMigrDelayUs int +TsliceMs int +RatelimitUs int +VcpuMigrDelayUs int } type SchedCredit2Params struct { - RatelimitUs int +RatelimitUs int } type DomainRemusInfo struct { - Interval int - AllowUnsafe Defbool - Blackhole Defbool - Compression Defbool - Netbuf Defbool - Netbufscript string - Diskbuf Defbool - Colo Defbool - UserspaceColoProxy Defbool +Interval int +AllowUnsafe Defbool +Blackhole Defbool +Compression Defbool +Netbuf Defbool +Netbufscript string +Diskbuf Defbool +Colo Defbool +UserspaceColoProxy Defbool } type EventType int - -const ( - EventTypeDomainShutdown EventType = 1 - EventTypeDomainDeath EventType = 2 - EventTypeDiskEject EventType = 3 - EventTypeOperationComplete EventType = 4 - EventTypeDomainCreateConsoleAvailable EventType = 5 +const( +EventTypeDomainShutdown EventType = 1 +EventTypeDomainDeath EventType = 2 +EventTypeDiskEject EventType = 3 +EventTypeOperationComplete EventType = 4 +EventTypeDomainCreateConsoleAvailable EventType = 5 ) type Event struct { - Link EvLink - Domid Domid - Domuuid Uuid - ForUser uint64 - Type EventType - TypeUnion eventTypeUnion +Link EvLink +Domid Domid +Domuuid Uuid +ForUser uint64 +Type EventType +TypeUnion eventTypeUnion } type eventTypeUnion interface { - iseventTypeUnion() +iseventTypeUnion() } type EventTypeUnionDomainShutdown struct { - ShutdownReason byte +ShutdownReason byte } -func (x EventTypeUnionDomainShutdown) iseventTypeUnion() {} +func (x EventTypeUnionDomainShutdown) iseventTypeUnion(){} type EventTypeUnionDiskEject struct { - Vdev string - Disk DeviceDisk +Vdev string +Disk DeviceDisk } -func (x EventTypeUnionDiskEject) iseventTypeUnion() {} +func (x EventTypeUnionDiskEject) iseventTypeUnion(){} type EventTypeUnionOperationComplete struct { - Rc int +Rc int } -func (x EventTypeUnionOperationComplete) iseventTypeUnion() {} +func (x EventTypeUnionOperationComplete) iseventTypeUnion(){} type PsrCmtType int - -const ( - PsrCmtTypeCacheOccupancy PsrCmtType = 1 - PsrCmtTypeTotalMemCount PsrCmtType = 2 - PsrCmtTypeLocalMemCount PsrCmtType = 3 +const( +PsrCmtTypeCacheOccupancy PsrCmtType = 1 +PsrCmtTypeTotalMemCount PsrCmtType = 2 +PsrCmtTypeLocalMemCount PsrCmtType = 3 ) type PsrCbmType int - -const ( - PsrCbmTypeUnknown PsrCbmType = 0 - PsrCbmTypeL3Cbm PsrCbmType = 1 - PsrCbmTypeL3CbmCode PsrCbmType = 2 - PsrCbmTypeL3CbmData PsrCbmType = 3 - PsrCbmTypeL2Cbm PsrCbmType = 4 - PsrCbmTypeMbaThrtl PsrCbmType = 5 +const( +PsrCbmTypeUnknown PsrCbmType = 0 +PsrCbmTypeL3Cbm PsrCbmType = 1 +PsrCbmTypeL3CbmCode PsrCbmType = 2 +PsrCbmTypeL3CbmData PsrCbmType = 3 +PsrCbmTypeL2Cbm PsrCbmType = 4 +PsrCbmTypeMbaThrtl PsrCbmType = 5 ) type PsrCatInfo struct { - Id uint32 - CosMax uint32 - CbmLen uint32 - CdpEnabled bool +Id uint32 +CosMax uint32 +CbmLen uint32 +CdpEnabled bool } type PsrFeatType int - -const ( - PsrFeatTypeCat PsrFeatType = 1 - PsrFeatTypeMba PsrFeatType = 2 +const( +PsrFeatTypeCat PsrFeatType = 1 +PsrFeatTypeMba PsrFeatType = 2 ) type PsrHwInfo struct { - Id uint32 - Type PsrFeatType - TypeUnion psrHwInfoTypeUnion +Id uint32 +Type PsrFeatType +TypeUnion psrHwInfoTypeUnion } type psrHwInfoTypeUnion interface { - ispsrHwInfoTypeUnion() +ispsrHwInfoTypeUnion() } type PsrHwInfoTypeUnionCat struct { - CosMax uint32 - CbmLen uint32 - CdpEnabled bool +CosMax uint32 +CbmLen uint32 +CdpEnabled bool } -func (x PsrHwInfoTypeUnionCat) ispsrHwInfoTypeUnion() {} +func (x PsrHwInfoTypeUnionCat) ispsrHwInfoTypeUnion(){} type PsrHwInfoTypeUnionMba struct { - CosMax uint32 - ThrtlMax uint32 - Linear bool +CosMax uint32 +ThrtlMax uint32 +Linear bool } -func (x PsrHwInfoTypeUnionMba) ispsrHwInfoTypeUnion() {} +func (x PsrHwInfoTypeUnionMba) ispsrHwInfoTypeUnion(){} + -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Sat Jun 06 18:19:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 18:19:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhdPw-0006sA-0s; Sat, 06 Jun 2020 18:19:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhdPv-0006s5-F3 for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 18:19:39 +0000 X-Inumbo-ID: 476a2720-a822-11ea-9ad7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 476a2720-a822-11ea-9ad7-bc764e2007e4; Sat, 06 Jun 2020 18:19:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8bhHJ21gDFxjYvRwEuhYiXme4pJuAWPFnJ5SKOD71vc=; b=LbMztMBBMjqAuYI89/FhAEGs1 2p2H4V4DWoA+en19wvDXgZN2+zAl6SxyoLol5xX4ye1y9JUu55qgYjlMvnQ8GOrEvaZoZEInMcBZt QVL+qb3xGHm8B5DSw9pang23hWPMFhj0Mihen834mQhoXlx6FB1Yx5/0sNSrGptLulQ38=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhdPs-00043t-9Q; Sat, 06 Jun 2020 18:19:36 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhdPs-000453-1w; Sat, 06 Jun 2020 18:19:36 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhdPs-0005lG-0x; Sat, 06 Jun 2020 18:19:36 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150895: FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64::broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict::broken:regression qemu-mainline:test-amd64-i386-xl::broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64::broken:regression qemu-mainline:test-amd64-amd64-xl-rtds::broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm::broken:regression qemu-mainline:test-amd64-i386-libvirt-xsm::broken:regression qemu-mainline:test-amd64-amd64-i386-pvgrub::broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-xl-rtds:capture-logs(19):broken:heisenbug qemu-mainline:test-amd64-amd64-i386-pvgrub:syslog-server:broken:heisenbug qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:host-ping-check-xen:fail:heisenbug qemu-mainline:test-amd64-i386-xl:guest-localmigrate/x10:fail:heisenbug qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:guest-start/redhat.repeat:fail:heisenbug qemu-mainline:test-amd64-amd64-i386-pvgrub:debian-di-install:fail:heisenbug qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start/debian.repeat:fail:heisenbug qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:heisenbug qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:guest-start/debianhvm.repeat:fail:heisenbug qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:heisenbug qemu-mainline:test-amd64-amd64-i386-pvgrub:capture-logs(11):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:capture-logs(11):broken:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:capture-logs(9):broken:nonblocking qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:capture-logs(13):broken:nonblocking qemu-mainline:test-amd64-i386-xl:capture-logs(19):broken:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:capture-logs(19):broken:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:capture-logs(19):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: qemuu=175198ad91d8bac540159705873b4ffe4fb94eab X-Osstest-Versions-That: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e From: osstest service owner Date: Sat, 06 Jun 2020 18:19:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150895 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150895/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd broken in 150872 test-amd64-amd64-xl-qemuu-ws16-amd64 broken in 150872 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken in 150872 test-amd64-i386-xl broken in 150872 test-amd64-i386-xl-qemuu-debianhvm-amd64 broken in 150872 test-amd64-amd64-xl-rtds broken in 150872 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken in 150872 test-amd64-i386-libvirt-xsm broken in 150872 test-amd64-amd64-i386-pvgrub broken in 150872 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-qemuu-debianhvm-amd64 2 hosts-allocate broken in 150872 pass in 150895 test-amd64-amd64-xl-rtds 19 capture-logs(19) broken in 150872 pass in 150895 test-amd64-amd64-i386-pvgrub 3 syslog-server broken in 150872 pass in 150895 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 8 host-ping-check-xen fail in 150872 pass in 150895 test-amd64-i386-xl 18 guest-localmigrate/x10 fail in 150872 pass in 150895 test-amd64-i386-qemuu-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 150872 pass in 150895 test-amd64-amd64-i386-pvgrub 10 debian-di-install fail in 150872 pass in 150895 test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail in 150872 pass in 150895 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail in 150872 pass in 150895 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 18 guest-start/debianhvm.repeat fail in 150872 pass in 150895 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail pass in 150872 Tests which did not succeed, but are not blocking: test-amd64-amd64-i386-pvgrub 11 capture-logs(11) broken in 150872 blocked in 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 11 capture-logs(11) broken in 150872 blocked in 150694 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 9 capture-logs(9) broken in 150872 never pass test-amd64-i386-qemuu-rhel6hvm-amd 13 capture-logs(13) broken in 150872 never pass test-amd64-i386-xl 19 capture-logs(19) broken in 150872 never pass test-amd64-i386-libvirt-xsm 19 capture-logs(19) broken in 150872 never pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 19 capture-logs(19) broken in 150872 never pass test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150694 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150694 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150694 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150694 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuu 175198ad91d8bac540159705873b4ffe4fb94eab baseline version: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e Last test of basis 150694 2020-06-04 11:44:20 Z 2 days Failing since 150831 2020-06-05 13:06:20 Z 1 days 3 attempts Testing same since 150872 2020-06-05 22:39:31 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Bulekov Christian Borntraeger Cornelia Huck Gerd Hoffmann Janosch Frank Jared Rossi Kevin Wolf Paolo Bonzini Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Stefan Hajnoczi Stefano Garzarella Thomas Huth Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken broken-job test-amd64-amd64-xl-qemuu-ws16-amd64 broken broken-job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken broken-job test-amd64-i386-xl broken broken-job test-amd64-i386-xl-qemuu-debianhvm-amd64 broken broken-job test-amd64-amd64-xl-rtds broken broken-job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken broken-job test-amd64-i386-libvirt-xsm broken broken-job test-amd64-amd64-i386-pvgrub broken Not pushing. (No revision log; it would be 447 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 06 23:55:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 06 Jun 2020 23:55:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhiet-0005bY-H6; Sat, 06 Jun 2020 23:55:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhies-0005ao-66 for xen-devel@lists.xenproject.org; Sat, 06 Jun 2020 23:55:26 +0000 X-Inumbo-ID: 2d1b363c-a851-11ea-9b55-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2d1b363c-a851-11ea-9b55-bc764e2007e4; Sat, 06 Jun 2020 23:55:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iv8Zlq06doTaW5P582GJ5JEnWMaL98ijCRTxzB6QIoI=; b=1/cnMPOGrNKSG9mE1LfM54yxj oe+9rutxbPkSj1wWXPaqwQMDTrwFY5c7WkISYwMI765FICaHZ+qZefZ7vaRbLyKmJE6E3cWFnTZoy p46xd69F+3QpoJsNiI+o4mW60/uwXLa1wb+9NKSum5/eGJpSW9PDpAYeEfpeAyWDZMg44=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhiek-0002QQ-QD; Sat, 06 Jun 2020 23:55:18 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhiei-0007Pb-WF; Sat, 06 Jun 2020 23:55:17 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhiei-0006Cb-Vh; Sat, 06 Jun 2020 23:55:16 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150897: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=51ca66c37371b10b378513af126646de22eddb17 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Sat, 06 Jun 2020 23:55:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150897 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150897/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150635 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150674 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150674 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150674 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150674 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150674 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150714 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150714 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150714 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150714 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150714 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: xen 51ca66c37371b10b378513af126646de22eddb17 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150714 2020-06-05 01:52:44 Z 1 days Testing same since 150869 2020-06-05 20:06:13 Z 1 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Igor Druzhinin Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 1497e78068..51ca66c373 51ca66c37371b10b378513af126646de22eddb17 -> master From xen-devel-bounces@lists.xenproject.org Sun Jun 07 00:40:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 00:40:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhjMI-0003us-0N; Sun, 07 Jun 2020 00:40:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhjMH-0003un-70 for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 00:40:17 +0000 X-Inumbo-ID: 72a9aa16-a857-11ea-b15b-12813bfff9fa Received: from wout5-smtp.messagingengine.com (unknown [64.147.123.21]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 72a9aa16-a857-11ea-b15b-12813bfff9fa; Sun, 07 Jun 2020 00:40:13 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id D621977B; Sat, 6 Jun 2020 20:40:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 06 Jun 2020 20:40:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=eqSD4o bu7qKvtP6n/EZrCfXrPcI0RDHd2BksWe5YKYg=; b=XDZzzjBXCmMJ04c9d3yiVc KOGdyxQ4rCDnMT1QdyD0XiqEOouOcE3TaNZw+XyfcN/foixooUOYKulnPI+Xk3V+ +AhvqShuBztH64UzEZBFzLRnvOpXOpxtqU5cLJOJIACUkV3PN98NYu1YxUPcDq+W 5HWZd2+qmM2J+sfm1rS4N7MkVJTvlfsVDL60k3OKkF6W+70waNOyozRmpvklhvFX QhSkb0TDQTOXuwputzFLREevcZJVqTcWHDDLBLOUlYxXyf7NWhhxQgwlOPfhw0v9 MvkLjaQeAi7IN4br/Rtz73kqKoQfeE4uCMyI1B4hlFgToeCCyOSR/Vo5m+WKbL8A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegjedgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkffogggtohfgsehtkeertdertdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeeltdef fedtvefhtdetgeetteeuudefjeeijeetkeeiiedvudelueekieelfeehgfenucffohhmrg hinhepphhougdrihhnnecukfhppeeluddrieehrdefgedrfeefnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvghksehinhhvih hsihgslhgvthhhihhnghhslhgrsgdrtghomh X-ME-Proxy: Received: from localhost.localdomain (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 84BA0328005A; Sat, 6 Jun 2020 20:40:10 -0400 (EDT) From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= To: xen-devel@lists.xenproject.org Subject: [PATCH] libxl: automatically enable gfx_passthru if IGD is assigned Date: Sun, 7 Jun 2020 02:39:57 +0200 Message-Id: <20200607003957.443603-1-marmarek@invisiblethingslab.com> X-Mailer: git-send-email 2.25.4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Organization: Invisible Things Lab Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The gfx_passthru option needs to be enabled whenever IGD is assigned, otherwise qemu refuses to start. Similarly, if gfx_passthru is enabled, IGD needs to be assigned, otherwise libxl refuses to start the guest. This means the gfx_passthru is fully redundant to assigning IGD (besides enabling various non-bootable configurations). Change the default value to follow IGD assignment state. For that, use existing libxl__detect_gfx_passthru_kind (move from libxl_dm.c to libxl_create.c). While the option is designed with various GFX in mind, only IGD ever got a special treatment. PCI passthrough of other GFX devices (some AMD and Nvidia at least) works just fine without setting gfx_passthru at all. This change simplifies configuration, but also fixes IGD passthrough when using libvirt (which doesn't expose gfx_passthru option). Signed-off-by: Marek Marczykowski-Górecki --- docs/man/xl.cfg.5.pod.in | 3 +++ tools/libxl/libxl_create.c | 27 ++++++++++++++++++++++++++- tools/libxl/libxl_dm.c | 20 +------------------- 3 files changed, 30 insertions(+), 20 deletions(-) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index 0532739c1f..32228c1361 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -1250,6 +1250,9 @@ Intel Graphics Device. =back +By default, this option is enabled if Intel Graphics Device is assigned to the +VM. + Note that some graphics cards (AMD/ATI cards, for example) do not necessarily require the B option, so you can use the normal Xen PCI passthrough to assign the graphics card as a secondary graphics diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 75862dc6ed..7aca51cb9c 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -72,6 +72,22 @@ void libxl__rdm_setdefault(libxl__gc *gc, libxl_domain_build_info *b_info) LIBXL_RDM_MEM_BOUNDARY_MEMKB_DEFAULT; } +static enum libxl_gfx_passthru_kind +libxl__detect_gfx_passthru_kind(libxl__gc *gc, + const libxl_domain_config *guest_config) +{ + const libxl_domain_build_info *b_info = &guest_config->b_info; + + if (b_info->u.hvm.gfx_passthru_kind != LIBXL_GFX_PASSTHRU_KIND_DEFAULT) + return b_info->u.hvm.gfx_passthru_kind; + + if (libxl__is_igd_vga_passthru(gc, guest_config)) { + return LIBXL_GFX_PASSTHRU_KIND_IGD; + } + + return LIBXL_GFX_PASSTHRU_KIND_DEFAULT; +} + int libxl__domain_build_info_setdefault(libxl__gc *gc, libxl_domain_build_info *b_info) { @@ -411,7 +427,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, libxl_defbool_setdefault(&b_info->u.hvm.nographic, false); - libxl_defbool_setdefault(&b_info->u.hvm.gfx_passthru, false); + libxl_defbool_setdefault(&b_info->u.hvm.gfx_passthru, + b_info->u.hvm.gfx_passthru_kind != LIBXL_GFX_PASSTHRU_KIND_DEFAULT); libxl__rdm_setdefault(gc, b_info); break; @@ -1177,6 +1194,14 @@ int libxl__domain_config_setdefault(libxl__gc *gc, ? libxl__get_required_iommu_memory(d_config->b_info.max_memkb) : 0; + if (d_config->b_info.type == LIBXL_DOMAIN_TYPE_HVM) { + if (d_config->b_info.u.hvm.gfx_passthru_kind == LIBXL_GFX_PASSTHRU_KIND_DEFAULT) { + /* this may also keep LIBXL_GFX_PASSTHRU_KIND_DEFAULT */ + d_config->b_info.u.hvm.gfx_passthru_kind = + libxl__detect_gfx_passthru_kind(gc, d_config); + } + } + ret = libxl__domain_build_info_setdefault(gc, &d_config->b_info); if (ret) { LOGD(ERROR, domid, "Unable to set domain build info defaults"); diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c index f2dc5696b9..381be5e6ed 100644 --- a/tools/libxl/libxl_dm.c +++ b/tools/libxl/libxl_dm.c @@ -981,22 +981,6 @@ static char *dm_spice_options(libxl__gc *gc, return opt; } -static enum libxl_gfx_passthru_kind -libxl__detect_gfx_passthru_kind(libxl__gc *gc, - const libxl_domain_config *guest_config) -{ - const libxl_domain_build_info *b_info = &guest_config->b_info; - - if (b_info->u.hvm.gfx_passthru_kind != LIBXL_GFX_PASSTHRU_KIND_DEFAULT) - return b_info->u.hvm.gfx_passthru_kind; - - if (libxl__is_igd_vga_passthru(gc, guest_config)) { - return LIBXL_GFX_PASSTHRU_KIND_IGD; - } - - return LIBXL_GFX_PASSTHRU_KIND_DEFAULT; -} - /* colo mode */ enum { LIBXL__COLO_NONE = 0, @@ -1798,9 +1782,7 @@ static int libxl__build_device_model_args_new(libxl__gc *gc, } if (libxl_defbool_val(b_info->u.hvm.gfx_passthru)) { - enum libxl_gfx_passthru_kind gfx_passthru_kind = - libxl__detect_gfx_passthru_kind(gc, guest_config); - switch (gfx_passthru_kind) { + switch (b_info->u.hvm.gfx_passthru_kind) { case LIBXL_GFX_PASSTHRU_KIND_IGD: machinearg = GCSPRINTF("%s,igd-passthru=on", machinearg); break; -- 2.25.4 From xen-devel-bounces@lists.xenproject.org Sun Jun 07 02:47:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 02:47:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhlL0-0000F7-Sb; Sun, 07 Jun 2020 02:47:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhlKz-0000F2-7n for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 02:47:05 +0000 X-Inumbo-ID: 2554880a-a869-11ea-b168-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2554880a-a869-11ea-b168-12813bfff9fa; Sun, 07 Jun 2020 02:46:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2AUTJ0eCR4ukBqVsE9XEwOCxkqbdnmBONDxbiRGwx88=; b=WWD+ouAOIa4cghsxJzye6B6YE 5mj6zWvvbb10uHvJ7Cz1wKttCu2OsnfH9V3UoGSHtppq3/1DwuP+6c2wIw61FIEeJrGOWTtbqL7sR 62q0jiZaS9zCV2FndCDwAkwrANN7VofwxthJVHqFxqpr7MtDNvFVaLCFqvGQruYi2a41k=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhlKn-00006V-5B; Sun, 07 Jun 2020 02:46:53 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhlKm-0004cj-Lj; Sun, 07 Jun 2020 02:46:52 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhlKm-0000Mm-JL; Sun, 07 Jun 2020 02:46:52 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150898: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=aaa2faab4ed8e5fe0111e04d6e168c028fe2987f X-Osstest-Versions-That: linux=7ae77150d94d3b535c7b85e6b3647113095e79bf From: osstest service owner Date: Sun, 07 Jun 2020 02:46:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150898 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150898/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150871 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150871 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150871 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150871 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150871 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150871 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150871 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150871 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150871 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150871 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: linux aaa2faab4ed8e5fe0111e04d6e168c028fe2987f baseline version: linux 7ae77150d94d3b535c7b85e6b3647113095e79bf Last test of basis 150871 2020-06-05 21:09:12 Z 1 days Testing same since 150879 2020-06-06 06:52:55 Z 0 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Adam Ford Aharon Landau Al Viro (fs/inode.c part) Alex Dewar Alex Williamson André Almeida Andy Shevchenko Anna Pendleton Arnd Bergmann Arun Easi Asmaa Mnebhi Asutosh Das Aurelien Aptel Avri Altman Bart Van Assche Bartosz Golaszewski Bean Huo Benjamin Block Bob Liu Bodo Stroesser Borislav Petkov Brian Masney Can Guo Carlos Guerrero Álvarez Chad Dupuis Chandrakanth Patil Chen Tao ChenTao Christoph Hellwig Christophe JAILLET Chuck Lever Colin Ian King Colin Ian King # fix leak in dmz_insert Corey Minyard Damien Le Moal Dan Carpenter Daniel Wagner Danil Kipnis Danit Goldberg Daria Velikovsky David Howells David Teigland Dejin Zheng Dennis Dalessandro Devesh Sharma Dick Kennedy Dinghao Liu Dmitry Baryshkov Douglas Anderson Douglas Gilbert Eric Biggers Eric Whitney Eugeniu Rosca Feng Tang Gabriel Krisman Bertazi Gal Pressman Gary Leshner Geert Uytterhoeven Geert Uytterhoeven Grzegorz Andrejczuk Gustavo A. R. Silva Gustavo A. R. Silva Hannes Reinecke Hans de Goede Hans Verkuil Harshad Shirwadkar Heinz Mauelshagen Israel Rukshin Jack Wang James Smart Jan Kara Jason Gunthorpe Jason Yan Javed Hasan Jeffle Xu Jeffrey Hugo Jens Axboe Joe Perches Johannes Thumshirn John Garry John Hubbard Jonathan Grant Jules Irenge Ka-Cheong Poon Kai Mäkisara Kaike Wan Kaixu Xia Kamal Heib Kashyap Desai Kees Cook Kenneth D'souza Kent Gibson Khalid Aziz Khazhismel Kumykov Kirti Wankhede Konstantin Khlebnikov Lance Digby Lang Cheng Lee Jones Leon Romanovsky Lijun Ou Linus Torvalds Linus Walleij Luo Jiaxing Manish Rangankar Maor Gottlieb Marcel Gudert Mark Bloch Mark Zhang Martin K. Petersen Martin Wilck Matthew R. Ochs Maulik Shah Maurizio Lombardi Mauro Carvalho Chehab Max Gurtovoy Md Haris Iqbal Mian Yousaf Kaukab Michael Walle Mika Westerberg Mike Christie Mike Marshall Mike Snitzer Mikulas Patocka Ming Lei Nathan Chancellor Nilesh Javali Paul Thomas Paulo Alcantara (SUSE) Paulo Alcantara Petteri Jokinen Piotr Stankiewicz Potnuri Bharat Teja Qian Cai Qiushi Wu Randy Dunlap Randy Dunlap # build-tested Randy Dunlap [Kconfig fixes] Ritesh Harjani Rob Herring Roberto Bergantinos Corpas Rodrigo Alencar <455.rodrigo.alencar@gmail.com> Roman Pen Ronnie Sahlberg Ross Lagerwall Sachin Agarwal Sadanand Warrier Samuel Zou Saurav Kashyap Serge Semin Serge Semin Shay Drory Shengju Zhang Shiraz Saleem Shivasharan S Sreekanth Reddy Stanley Chu Stephen Boyd Steve French Stuart Hayes Subhash Jadavani Sudarsana Reddy Kalluru Sudhakar Panneerselvam Suganath Prabu Suganath Prabu S Sumit Saxena Tang Bin Tejun Heo Theodore Ts'o Tiezhu Yang Ursula Braun Uwe Kleine-König Viacheslav Dubeyko Vignesh Raghavendra Wang Hai Wei Yongjun Weihang Li Wenpeng Liang Wu Bo Xi Wang Xie XiuQi Xin Tan Xiongfeng Wang Xiyu Yang Xu Wang Yamin Friedman Yangyang Li Ye Bin Yishai Hadas Yixian Liu YueHaibing Zheng Bin [static fixes] Zhiqiang Liu Zhu Yanjun Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 7ae77150d94d..aaa2faab4ed8 aaa2faab4ed8e5fe0111e04d6e168c028fe2987f -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Sun Jun 07 04:15:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 04:15:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhmiN-0000WG-MM; Sun, 07 Jun 2020 04:15:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhmiM-0000WB-W8 for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 04:15:19 +0000 X-Inumbo-ID: 7db9d1d8-a875-11ea-b171-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7db9d1d8-a875-11ea-b171-12813bfff9fa; Sun, 07 Jun 2020 04:15:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Fqe3f8W04aEvFXCZ3QIu77kTP5U4XM92GV6KsFuY8K4=; b=vz5oWFwOPRtIetZiIegYuRsnG rnkms9mQZJpNtFNafEPfCGDO4XFXPayMOIbPstBB9uUXkBd2IYya3ltju19y5AvhvivDUgxJXaUQO 9xmmQ3qKI/KY6lk5o1Jgyb2EkG9bzb/y/YDt659j3Vq4CQZw9EnM8tJo681AZWDTq7mqw=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhmiJ-0002NC-TN; Sun, 07 Jun 2020 04:15:15 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhmiI-0007eG-I5; Sun, 07 Jun 2020 04:15:14 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhmiI-00073b-HH; Sun, 07 Jun 2020 04:15:14 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150899: regressions - FAIL X-Osstest-Failures: qemu-mainline:build-i386-pvops:kernel-build:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:heisenbug qemu-mainline:test-armhf-armhf-xl-vhd:leak-check/check:fail:heisenbug qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-coresched-i386-xl:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-pair:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=175198ad91d8bac540159705873b4ffe4fb94eab X-Osstest-Versions-That: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e From: osstest service owner Date: Sun, 07 Jun 2020 04:15:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150899 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150899/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 6 kernel-build fail REGR. vs. 150694 Tests which are failing intermittently (not blocking): test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail in 150895 pass in 150899 test-armhf-armhf-xl-vhd 18 leak-check/check fail pass in 150895 Tests which did not succeed, but are not blocking: test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 150895 like 150694 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 150895 like 150694 test-amd64-i386-xl-pvshim 12 guest-start fail in 150895 never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail in 150895 never pass test-amd64-i386-libvirt 13 migrate-support-check fail in 150895 never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 150895 never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 150895 never pass test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150694 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150694 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150694 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: qemuu 175198ad91d8bac540159705873b4ffe4fb94eab baseline version: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e Last test of basis 150694 2020-06-04 11:44:20 Z 2 days Failing since 150831 2020-06-05 13:06:20 Z 1 days 4 attempts Testing same since 150872 2020-06-05 22:39:31 Z 1 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Bulekov Christian Borntraeger Cornelia Huck Gerd Hoffmann Janosch Frank Jared Rossi Kevin Wolf Paolo Bonzini Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Stefan Hajnoczi Stefano Garzarella Thomas Huth Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops fail test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl blocked test-amd64-coresched-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 447 lines long.) From xen-devel-bounces@lists.xenproject.org Sun Jun 07 10:20:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 10:20:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhsOz-00029p-MN; Sun, 07 Jun 2020 10:19:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhsOy-00029j-9C for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 10:19:40 +0000 X-Inumbo-ID: 61728a1e-a8a8-11ea-9ad7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 61728a1e-a8a8-11ea-9ad7-bc764e2007e4; Sun, 07 Jun 2020 10:19:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dQdNuQ/G9YGjWwS0HVTRWaQCljVfZrQC8ppIXIlKc8o=; b=ktMU0QSCtRVxis3b7bkt08qqa ddA0AVd/yNoPbaH55AfuumjFNFOil4x6YSVSlqZJQ4GYFgvieHb3TBIQX6/JHTNfJkXapwN+YX1Zn +wyCzb8Jj5kFoJhNAJxiRSUjqxbzq+5tf1AJiN/6g9Gp9uqBhLmj881d/NXsJYSSNF8o0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhsOq-0002Cw-KU; Sun, 07 Jun 2020 10:19:32 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhsOq-0004PN-8l; Sun, 07 Jun 2020 10:19:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhsOq-000430-8E; Sun, 07 Jun 2020 10:19:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150900: tolerable FAIL X-Osstest-Failures: xen-unstable:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=51ca66c37371b10b378513af126646de22eddb17 X-Osstest-Versions-That: xen=51ca66c37371b10b378513af126646de22eddb17 From: osstest service owner Date: Sun, 07 Jun 2020 10:19:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150900 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150900/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail like 150869 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150897 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150897 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150897 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150897 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150897 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150897 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150897 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150897 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150897 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150897 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150897 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: xen 51ca66c37371b10b378513af126646de22eddb17 baseline version: xen 51ca66c37371b10b378513af126646de22eddb17 Last test of basis 150900 2020-06-07 01:56:59 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Sun Jun 07 10:20:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 10:20:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhsPV-0002py-2f; Sun, 07 Jun 2020 10:20:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhsPU-0002ps-4D for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 10:20:12 +0000 X-Inumbo-ID: 783ed3ce-a8a8-11ea-9ad7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 783ed3ce-a8a8-11ea-9ad7-bc764e2007e4; Sun, 07 Jun 2020 10:20:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wQe15+pU7n7PunlfBjesIB5DzyizQ2hxpYBbaL5TVWw=; b=UqaMbItwrYed1RgF6L+Ct0AyN 1y9IC3Bace3zSAoqXhrj1rRrUDAp2gKkAAT55rK1NbOB5mrk4l+OM+n7qZ8JyljSZj8lrbR616D2h 2JNSuFMDmj3p+nNNsHkb0LJWAGSdTfqTnaAK4uuHTN7gb8O/2FAJ7U3upCDukne0MLOwM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhsPS-0002Dn-SV; Sun, 07 Jun 2020 10:20:10 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhsPS-0004Sz-Js; Sun, 07 Jun 2020 10:20:10 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhsPS-0004Ey-JF; Sun, 07 Jun 2020 10:20:10 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-coverity test] 150905: all pass - PUSHED X-Osstest-Versions-This: xen=51ca66c37371b10b378513af126646de22eddb17 X-Osstest-Versions-That: xen=1497e78068421d83956f8e82fb6e1bf1fc3b1199 From: osstest service owner Date: Sun, 07 Jun 2020 10:20:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150905 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/150905/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 51ca66c37371b10b378513af126646de22eddb17 baseline version: xen 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Last test of basis 150564 2020-05-31 09:18:46 Z 7 days Testing same since 150905 2020-06-07 09:19:18 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Andrew Cooper Anthony PERARD Dario Faggioli Ian Jackson Igor Druzhinin Jan Beulich Jason Andryuk Juergen Gross Julien Grall Olaf Hering Paul Durrant Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: coverity-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 1497e78068..51ca66c373 51ca66c37371b10b378513af126646de22eddb17 -> coverity-tested/smoke From xen-devel-bounces@lists.xenproject.org Sun Jun 07 13:18:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 13:18:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhvBZ-0001HL-Ls; Sun, 07 Jun 2020 13:18:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhvBZ-0001HG-34 for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 13:18:01 +0000 X-Inumbo-ID: 4b17525e-a8c1-11ea-96fb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4b17525e-a8c1-11ea-96fb-bc764e2007e4; Sun, 07 Jun 2020 13:17:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uLXpslScYEiKYuRcr31HnqTkI3lqeto6q7Vja8oHUvQ=; b=xyqB9z2ZYmkYM250h1CHyX0+d kCJ+J9cSip2iQ4U81xobsAvFuusqUeHTh5E0CYYCKo3QFitoBFMyP+aS6zj+ekcj4Gh/TIO7N9u+z 1XQKIf4FoT0PdQJ327Ywc8YL46yur43g7fRt7aZ/nieXQyaOi5qykmD9Q6QTd6jJ3fr+Q=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhvBQ-0005oS-Fj; Sun, 07 Jun 2020 13:17:52 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jhvBQ-00021K-66; Sun, 07 Jun 2020 13:17:52 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jhvBQ-0004kr-5R; Sun, 07 Jun 2020 13:17:52 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150902: regressions - trouble: blocked/broken/fail/pass X-Osstest-Failures: qemu-mainline:test-amd64-amd64-libvirt::broken:regression qemu-mainline:test-amd64-amd64-xl-qcow2::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow::broken:regression qemu-mainline:test-amd64-amd64-xl-shadow::broken:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm::broken:regression qemu-mainline:test-amd64-amd64-xl-credit1::broken:regression qemu-mainline:test-amd64-amd64-i386-pvgrub::broken:regression qemu-mainline:test-amd64-amd64-libvirt-vhd::broken:regression qemu-mainline:test-amd64-amd64-xl::broken:regression qemu-mainline:test-amd64-amd64-xl-pvhv2-amd::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64::broken:regression qemu-mainline:test-amd64-amd64-xl-rtds::broken:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd::broken:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64::broken:regression qemu-mainline:test-amd64-amd64-xl-pvshim::broken:regression qemu-mainline:test-amd64-amd64-pygrub::broken:regression qemu-mainline:build-i386:xen-build:fail:regression qemu-mainline:build-i386-pvops:kernel-build:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-xl-shadow:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-libvirt-vhd:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-libvirt:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-xl-qcow2:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-xl-rtds:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-qemuu-nested-amd:hosts-allocate:broken:heisenbug qemu-mainline:test-amd64-amd64-xl-credit1:host-install(4):broken:heisenbug qemu-mainline:test-amd64-amd64-xl:host-install(4):broken:heisenbug qemu-mainline:test-amd64-amd64-xl-credit1:syslog-server:broken:heisenbug qemu-mainline:test-amd64-amd64-xl:syslog-server:broken:heisenbug qemu-mainline:test-amd64-amd64-pygrub:syslog-server:broken:heisenbug qemu-mainline:test-amd64-amd64-i386-pvgrub:syslog-server:broken:heisenbug qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:heisenbug qemu-mainline:test-armhf-armhf-xl-vhd:leak-check/check:fail:heisenbug qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:guest-localmigrate/x10:fail:heisenbug qemu-mainline:test-amd64-amd64-xl-pvhv2-amd:debian-install:fail:heisenbug qemu-mainline:test-amd64-amd64-pygrub:debian-di-install:fail:heisenbug qemu-mainline:test-amd64-amd64-i386-pvgrub:debian-di-install:fail:heisenbug qemu-mainline:test-amd64-amd64-xl-pvshim:guest-start/debian.repeat:fail:heisenbug qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:guest-start.2:fail:heisenbug qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:guest-start/debianhvm.repeat:fail:heisenbug qemu-mainline:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-coresched-i386-xl:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-pair:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking qemu-mainline:build-i386-libvirt:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-amd64-xl-credit1:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-xl:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-pygrub:capture-logs(11):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-pvshim:capture-logs(21):broken:nonblocking qemu-mainline:test-amd64-amd64-i386-pvgrub:capture-logs(11):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:capture-logs(20):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-pvhv2-amd:capture-logs(11):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:capture-logs(19):broken:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:capture-logs(17):broken:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=175198ad91d8bac540159705873b4ffe4fb94eab X-Osstest-Versions-That: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e From: osstest service owner Date: Sun, 07 Jun 2020 13:17:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150902 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150902/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt broken test-amd64-amd64-xl-qcow2 broken test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm broken test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken test-amd64-amd64-xl-shadow broken test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken test-amd64-amd64-xl-credit1 broken test-amd64-amd64-i386-pvgrub broken test-amd64-amd64-libvirt-vhd broken test-amd64-amd64-xl broken test-amd64-amd64-xl-pvhv2-amd broken test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken test-amd64-amd64-xl-rtds broken test-amd64-amd64-qemuu-nested-amd broken test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken test-amd64-amd64-xl-qemuu-ws16-amd64 broken test-amd64-amd64-xl-pvshim broken test-amd64-amd64-pygrub broken build-i386 6 xen-build fail REGR. vs. 150694 build-i386-pvops 6 kernel-build fail in 150899 REGR. vs. 150694 Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 2 hosts-allocate broken pass in 150899 test-amd64-amd64-xl-shadow 2 hosts-allocate broken pass in 150899 test-amd64-amd64-libvirt-vhd 2 hosts-allocate broken pass in 150899 test-amd64-amd64-libvirt 2 hosts-allocate broken pass in 150899 test-amd64-amd64-xl-qemuu-ws16-amd64 2 hosts-allocate broken pass in 150899 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 2 hosts-allocate broken pass in 150899 test-amd64-amd64-xl-qcow2 2 hosts-allocate broken pass in 150899 test-amd64-amd64-xl-qemuu-ovmf-amd64 2 hosts-allocate broken pass in 150899 test-amd64-amd64-xl-rtds 2 hosts-allocate broken pass in 150899 test-amd64-amd64-qemuu-nested-amd 2 hosts-allocate broken pass in 150899 test-amd64-amd64-xl-credit1 4 host-install(4) broken pass in 150899 test-amd64-amd64-xl 4 host-install(4) broken pass in 150899 test-amd64-amd64-xl-credit1 3 syslog-server broken pass in 150899 test-amd64-amd64-xl 3 syslog-server broken pass in 150899 test-amd64-amd64-pygrub 3 syslog-server broken pass in 150899 test-amd64-amd64-i386-pvgrub 3 syslog-server broken pass in 150899 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail in 150895 pass in 150902 test-armhf-armhf-xl-vhd 18 leak-check/check fail in 150899 pass in 150902 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 16 guest-localmigrate/x10 fail pass in 150895 test-amd64-amd64-xl-pvhv2-amd 10 debian-install fail pass in 150899 test-amd64-amd64-pygrub 10 debian-di-install fail pass in 150899 test-amd64-amd64-i386-pvgrub 10 debian-di-install fail pass in 150899 test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail pass in 150899 test-amd64-amd64-xl-qemuu-debianhvm-amd64 19 guest-start.2 fail pass in 150899 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 18 guest-start/debianhvm.repeat fail pass in 150899 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-xsm 1 build-check(1) blocked in 150899 n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked in 150899 n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-xl 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-pygrub 11 capture-logs(11) broken blocked in 150694 test-amd64-amd64-xl-pvshim 21 capture-logs(21) broken blocked in 150694 test-amd64-amd64-i386-pvgrub 11 capture-logs(11) broken blocked in 150694 test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 capture-logs(20) broken blocked in 150694 test-amd64-amd64-xl-pvhv2-amd 11 capture-logs(11) broken never pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 19 capture-logs(19) broken never pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 17 capture-logs(17) broken never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 150895 like 150694 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 150895 like 150694 test-amd64-i386-xl-pvshim 12 guest-start fail in 150895 never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail in 150895 never pass test-amd64-i386-libvirt 13 migrate-support-check fail in 150895 never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 150895 never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 150895 never pass test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 150899 like 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 150899 like 150694 test-amd64-amd64-libvirt 13 migrate-support-check fail in 150899 never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 150899 never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail in 150899 never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail in 150899 never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150694 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150694 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass version targeted for testing: qemuu 175198ad91d8bac540159705873b4ffe4fb94eab baseline version: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e Last test of basis 150694 2020-06-04 11:44:20 Z 3 days Failing since 150831 2020-06-05 13:06:20 Z 2 days 5 attempts Testing same since 150872 2020-06-05 22:39:31 Z 1 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Bulekov Christian Borntraeger Cornelia Huck Gerd Hoffmann Janosch Frank Jared Rossi Kevin Wolf Paolo Bonzini Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Stefan Hajnoczi Stefano Garzarella Thomas Huth Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 fail build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt blocked build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl broken test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl blocked test-amd64-coresched-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm broken test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd broken test-amd64-amd64-xl-pvhv2-amd broken test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 broken test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 broken test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt broken test-armhf-armhf-libvirt pass test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub broken test-amd64-amd64-xl-pvshim broken test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub broken test-amd64-amd64-xl-qcow2 broken test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds broken test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow broken test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd broken test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-amd64-libvirt broken broken-job test-amd64-amd64-xl-qcow2 broken broken-job test-amd64-amd64-xl-qemuu-ovmf-amd64 broken broken-job test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm broken broken-job test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken broken-job test-amd64-amd64-xl-shadow broken broken-job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken broken-job test-amd64-amd64-xl-credit1 broken broken-job test-amd64-amd64-i386-pvgrub broken broken-job test-amd64-amd64-libvirt-vhd broken broken-job test-amd64-amd64-xl broken broken-job test-amd64-amd64-xl-pvhv2-amd broken broken-job test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken broken-job test-amd64-amd64-xl-rtds broken broken-job test-amd64-amd64-qemuu-nested-amd broken broken-job test-amd64-i386-xl-qemuu-debianhvm-i386-xsm broken broken-job test-amd64-amd64-xl-qemuu-ws16-amd64 broken broken-job test-amd64-amd64-xl-pvshim broken broken-job test-amd64-amd64-pygrub broken broken-step test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm hosts-allocate broken-step test-amd64-amd64-xl-shadow hosts-allocate broken-step test-amd64-amd64-libvirt-vhd hosts-allocate broken-step test-amd64-amd64-libvirt hosts-allocate broken-step test-amd64-amd64-xl-qemuu-ws16-amd64 hosts-allocate broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow hosts-allocate broken-step test-amd64-amd64-xl-qcow2 hosts-allocate broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 hosts-allocate broken-step test-amd64-amd64-xl-rtds hosts-allocate broken-step test-amd64-amd64-xl-credit1 capture-logs(5) broken-step test-amd64-amd64-qemuu-nested-amd hosts-allocate broken-step test-amd64-amd64-xl capture-logs(5) broken-step test-amd64-amd64-xl-credit1 host-install(4) broken-step test-amd64-amd64-xl host-install(4) broken-step test-amd64-amd64-xl-pvhv2-amd capture-logs(11) broken-step test-amd64-amd64-pygrub capture-logs(11) broken-step test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm capture-logs(19) broken-step test-amd64-amd64-xl-pvshim capture-logs(21) broken-step test-amd64-amd64-i386-pvgrub capture-logs(11) broken-step test-amd64-i386-xl-qemuu-debianhvm-i386-xsm capture-logs(17) broken-step test-amd64-amd64-xl-credit1 syslog-server broken-step test-amd64-amd64-xl syslog-server broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 capture-logs(20) broken-step test-amd64-amd64-pygrub syslog-server broken-step test-amd64-amd64-i386-pvgrub syslog-server Not pushing. (No revision log; it would be 447 lines long.) From xen-devel-bounces@lists.xenproject.org Sun Jun 07 13:32:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 13:32:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhvPa-000327-3D; Sun, 07 Jun 2020 13:32:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhvPY-000321-EY for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 13:32:28 +0000 X-Inumbo-ID: 541ece20-a8c3-11ea-ba62-bc764e2007e4 Received: from mail-il1-x142.google.com (unknown [2607:f8b0:4864:20::142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 541ece20-a8c3-11ea-ba62-bc764e2007e4; Sun, 07 Jun 2020 13:32:27 +0000 (UTC) Received: by mail-il1-x142.google.com with SMTP id v11so14228129ilh.1 for ; Sun, 07 Jun 2020 06:32:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WY9MvnPJeP94VgXHjtnTqNiyQwhIoobiIF0OrIddSEU=; b=bP88d+f5zV/TUrMXwGmfLOgcY5TtNYpUtCUGlYTZtzaNwG9RCFNUrKuEfYagyi+HL8 SCHEMxw7he7c/jZy9jj6RZGwgZKqk3afILOqkWF4iyUYiWWB2+BWcEF5hi5X+JBEHK/Q 15k0Sn3HMGQ3WX3bzh+rN+rbRTiQ5QtpElobYbl29WSCW+L5Vm6efkEtbNJLYsOZ1TuW BpLews/IGcDQoMVXj0irCN9Jo55eqAUD6nzd33JveRDoARn8CqhIlY30IJRcUHhcAAwG 4ioR5wPakWmQ8Vd0DXx0sU2NDPr4uX1OLwVLWO5QxzJfDN7990Fj+WB8GZZIroL6faLD s9GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WY9MvnPJeP94VgXHjtnTqNiyQwhIoobiIF0OrIddSEU=; b=TnILfyqe8lcmiwDI8zNjjIo/rgqG7STRilDGcRA3b6hDMbFjL8WcKZfHQLJYT0Ps9u ktUFIIEdYO4060ybYVQkFAXMzQ+JnMf89ptedBcJ5nl4ch7kEhY6zpGKLyBiGXe2w4yx sNto0vtKWOqvCdqtySbLge9FRmDeV2xZHNFGJmyomSpRVmQhLtBvciDqlE6D0yY7+HGc o1iLYtJBVZX7PV5B0Qy+r9/Zdm4u0eTgW3s5o+JCqxEYfd5Ny677Me49QEKXdoxNsw4j yMFO+4Yx8ITcd7DfWvd1YMxnfE1VmnZ87l5uy0UTopFB2f0x9bCnX0f+Y86GmVjCQN9e YrRQ== X-Gm-Message-State: AOAM531WebLUlaiIL1qVCwWsyfv2acBtQ2i2B4xK1vkMa8FvvZvS2jJ6 AMhn7V8dv60zl+Zlwsy4uGj8FKlW5dN/YsAt3dg= X-Google-Smtp-Source: ABdhPJwR+SStGDjRo7STvOtanReR5Gci/6gS2rM+7VCXLyBpzmC1+yeTeN23YvCpwMoGPv4/o3jDTawiItnbHryU7G0= X-Received: by 2002:a05:6e02:13a9:: with SMTP id h9mr17369093ilo.20.1591536746888; Sun, 07 Jun 2020 06:32:26 -0700 (PDT) MIME-Version: 1.0 References: <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <000701d63b2c$10536930$30fa3b90$@xen.org> <0296d5d6-cc7f-6e34-2403-acf34b870b5b@suse.com> <002101d63b3f$4e9dc830$ebd95890$@xen.org> <002201d63b40$1e135ee0$5a3a1ca0$@xen.org> <002f01d63b50$c8b49a70$5a1dcf50$@xen.org> <20200605171353.GG6329@mail-itl> <001501d63b5e$26a991a0$73fcb4e0$@xen.org> <20200605204310.GK98582@mail-itl> In-Reply-To: <20200605204310.GK98582@mail-itl> From: Paul Durrant Date: Sun, 7 Jun 2020 14:32:15 +0100 Message-ID: Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Content-Type: multipart/alternative; boundary="0000000000007204a005a77e863d" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , xen-devel , Jan Beulich , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --0000000000007204a005a77e863d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 5 Jun 2020, 21:43 Marek Marczykowski-G=C3=B3recki, < marmarek@invisiblethingslab.com> wrote: > On Fri, Jun 05, 2020 at 06:24:20PM +0100, Paul Durrant wrote: > > > -----Original Message----- > > > From: 'Marek Marczykowski-G=C3=B3recki' > > > Sent: 05 June 2020 18:14 > > > To: paul@xen.org > > > Cc: 'Jan Beulich' ; 'Andrew Cooper' < > andrew.cooper3@citrix.com>; 'xen-devel' > > devel@lists.xenproject.org> > > > Subject: Re: handle_pio looping during domain shutdown, with qemu > 4.2.0 in stubdom > > > > > > On Fri, Jun 05, 2020 at 04:48:39PM +0100, Paul Durrant wrote: > > > > This (untested) patch might help: > > > > > > It is different now. I don't get domain_crash because of > > > X86EMUL_UNHANDLEABLE anymore, but I still see handle_pio looping for > > > some time. But it eventually ends, not really sure why. > > > > That'll be the shutdown deferral, which I realised later that I forgot > about... > > > > > > > > I've tried the patch with a modification to make it build: > > > > > > > diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c > > > > index c55c4bc4bc..8aa8779ba2 100644 > > > > --- a/xen/arch/x86/hvm/ioreq.c > > > > +++ b/xen/arch/x86/hvm/ioreq.c > > > > @@ -109,12 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcp= u > *sv, uint64_t data) > > > > ioreq_t *ioreq =3D &v->arch.hvm.hvm_io.io_req; > > > > > > > > if ( hvm_ioreq_needs_completion(ioreq) ) > > > > - { > > > > - ioreq->state =3D STATE_IORESP_READY; > > > > ioreq->data =3D data; > > > > - } > > > > - else > > > > - ioreq->state =3D STATE_IOREQ_NONE; > > > > > > > > msix_write_completion(v); > > > > vcpu_end_shutdown_deferral(v); > > > > In fact, move both of these lines... > > > > > > @@ -209,6 +204,9 @@ bool handle_hvm_io_completion(struct vcpu *v) > > > > } > > > > } > > > > > > > > + ioreq->state =3D hvm_ioreq_needs_completion(&vio->ioreq) ? > > > vio->io_req->state ... &vio->io_req > > > > > > > + STATE_IORESP_READY : STATE_IOREQ_NONE; > > > > + > > > > ... to here too. > > > > > > io_completion =3D vio->io_completion; > > > > vio->io_completion =3D HVMIO_no_completion; > > > > > > > > > > The full patch (together with my debug prints): > > > https://gist.github.com/marmarek/da37da3722179057a6e7add4fb361e06 > > The current patch: > https://gist.github.com/marmarek/5ae795129c1be2dae13bfc517547c0f1 > > > I guess it is the destroy being held off by the shutdown deferral? > Hopefully the above tweaks should sort that out. > > Yes, now it works (tried 5 times in a row, previously it crashed on > the first or the second one). Thanks! > > -- > Best Regards, > Marek Marczykowski-G=C3=B3recki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > Cool. I will send a proper patch tomorrow. Paul --0000000000007204a005a77e863d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, 5 Jun 2020, 21:43 Marek Marczykowski-G=C3=B3recki,= <marmarek@invisiblet= hingslab.com> wrote:
On Fri,= Jun 05, 2020 at 06:24:20PM +0100, Paul Durrant wrote:
> > -----Original Message-----
> > From: 'Marek Marczykowski-G=C3=B3recki' <= marmarek@invisiblethingslab.com>
> > Sent: 05 June 2020 18:14
> > To: paul@xen.org
> > Cc: 'Jan Beulich' <jbeulich@suse.com>; 'Andr= ew Cooper' <andrew.cooper3@citrix.com>; 'xen-devel= ' <xen-
> > devel@lists.xenproject.org>
> > Subject: Re: handle_pio looping during domain shutdown, with qemu= 4.2.0 in stubdom
> >
> > On Fri, Jun 05, 2020 at 04:48:39PM +0100, Paul Durrant wrote:
> > > This (untested) patch might help:
> >
> > It is different now. I don't get domain_crash because of
> > X86EMUL_UNHANDLEABLE anymore, but I still see handle_pio looping = for
> > some time. But it eventually ends, not really sure why.
>
> That'll be the shutdown deferral, which I realised later that I fo= rgot about...
>
> >
> > I've tried the patch with a modification to make it build: > >
> > > diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ior= eq.c
> > > index c55c4bc4bc..8aa8779ba2 100644
> > > --- a/xen/arch/x86/hvm/ioreq.c
> > > +++ b/xen/arch/x86/hvm/ioreq.c
> > > @@ -109,12 +109,7 @@ static void hvm_io_assist(struct hvm_io= req_vcpu *sv, uint64_t data)
> > >=C2=A0 =C2=A0 =C2=A0 ioreq_t *ioreq =3D &v->arch.hvm.h= vm_io.io_req;
> > >
> > >=C2=A0 =C2=A0 =C2=A0 if ( hvm_ioreq_needs_completion(ioreq) )=
> > > -=C2=A0 =C2=A0 {
> > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 ioreq->state =3D STATE_IORES= P_READY;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ioreq->data =3D data; > > > -=C2=A0 =C2=A0 }
> > > -=C2=A0 =C2=A0 else
> > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 ioreq->state =3D STATE_IOREQ= _NONE;
> > >
> > >=C2=A0 =C2=A0 =C2=A0 msix_write_completion(v);
> > >=C2=A0 =C2=A0 =C2=A0 vcpu_end_shutdown_deferral(v);
>
> In fact, move both of these lines...
>
> > > @@ -209,6 +204,9 @@ bool handle_hvm_io_completion(struct vcp= u *v)
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
> > >=C2=A0 =C2=A0 =C2=A0 }
> > >
> > > +=C2=A0 =C2=A0 ioreq->state =3D hvm_ioreq_needs_completio= n(&vio->ioreq) ?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 vio->io_req->state ... &vio-= >io_req
> >
> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 STATE_IORESP_READY : STATE_IORE= Q_NONE;
> > > +
>
> ... to here too.
>
> > >=C2=A0 =C2=A0 =C2=A0 io_completion =3D vio->io_completion;=
> > >=C2=A0 =C2=A0 =C2=A0 vio->io_completion =3D HVMIO_no_compl= etion;
> > >
> >
> > The full patch (together with my debug prints):
> > https://gist.g= ithub.com/marmarek/da37da3722179057a6e7add4fb361e06

The current patch:
https://gist.github.com/= marmarek/5ae795129c1be2dae13bfc517547c0f1

> I guess it is the destroy being held off by the shutdown deferral? Hop= efully the above tweaks should sort that out.

Yes, now it works (tried 5 times in a row, previously it crashed on
the first or the second one). Thanks!

--
Best Regards,
Marek Marczykowski-G=C3=B3recki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Cool. I will send a proper patch tomorrow.

=C2=A0 Paul=C2=A0

<= /div>
--0000000000007204a005a77e863d-- From xen-devel-bounces@lists.xenproject.org Sun Jun 07 15:52:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 15:52:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhxac-0006v2-9j; Sun, 07 Jun 2020 15:52:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhxaa-0006ux-KR for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 15:52:00 +0000 X-Inumbo-ID: d27eaef8-a8d6-11ea-9b55-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d27eaef8-a8d6-11ea-9b55-bc764e2007e4; Sun, 07 Jun 2020 15:51:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uKm3YtRbAQtnN5YWAy5mDd8vgO/GnIYjYwufp/rjpG0=; b=tT2saj54rf/8UmIrX9QatBUWBt skZs/VAPmV9rhzo3z2/gtUU0WrTfKYEcOzvKUHdcVmg9msMMi/oUyWkfv4HKOuspNg99jwIM8/4og TfaDSd9/pZsAx/bM5q/J5sCBlwSOo11TfNTMVyml0x8fVdz8kDUMDGe4qFD6C8gkqjeg=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jhxaZ-0000Xq-44; Sun, 07 Jun 2020 15:51:59 +0000 Received: from 54-240-197-227.amazon.com ([54.240.197.227] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhxaY-0002SO-Qf; Sun, 07 Jun 2020 15:51:59 +0000 From: Julien Grall To: xen-devel@lists.xenproject.org Subject: [PATCH for-4.14] xen/arm: mm: Access a PT entry before the table is unmapped Date: Sun, 7 Jun 2020 16:51:54 +0100 Message-Id: <20200607155154.15928-1-julien@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Volodymyr Babchuk , Julien Grall , Stefano Stabellini , Julien Grall , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Julien Grall xen_pt_next_level() will retrieve the MFN from the entry right after the page-table has been unmapped. After calling xen_unmap_table(), there is no guarantee the mapping will still be valid. Depending on the implementation, this may result to a data abort in Xen. Re-order the code to retrieve the MFN before the table is unmapped. Fixes: 53abb9a1dcd9 ("xen/arm: mm: Rework Xen page-tables walk during update") Signed-off-by: Julien Grall --- I spotted this issue while reworking how page-tables are mapped on Arm64 during early boot. However the problem should be already there on Arm32. I am actually quite amazed we haven't seen any crash on Arm32 because there is no direct map. So the mapping will not exist after calling xen_unmap_table(). I suspect this works because unmap_domain_page() doesn't flush the TLBs. So the TLB still likely have the entry cached (joy!). This patch is a candidate for Xen 4.14 and should also be backported. --- xen/arch/arm/mm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 1b14f4934570..9e2ff7c8005d 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -1036,6 +1036,7 @@ static int xen_pt_next_level(bool read_only, unsigned int level, { lpae_t *entry; int ret; + mfn_t mfn; entry = *table + offset; @@ -1053,8 +1054,10 @@ static int xen_pt_next_level(bool read_only, unsigned int level, if ( lpae_is_mapping(*entry, level) ) return XEN_TABLE_SUPER_PAGE; + mfn = lpae_get_mfn(*entry); + xen_unmap_table(*table); - *table = xen_map_table(lpae_get_mfn(*entry)); + *table = xen_map_table(mfn); return XEN_TABLE_NORMAL_PAGE; } -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Sun Jun 07 19:38:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 19:38:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji17t-0001VO-SU; Sun, 07 Jun 2020 19:38:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji17s-0001VI-OJ for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 19:38:36 +0000 X-Inumbo-ID: 767c7732-a8f6-11ea-9ad7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 767c7732-a8f6-11ea-9ad7-bc764e2007e4; Sun, 07 Jun 2020 19:38:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QALyNa81wN1+jbk1jaOitCHDLdzVJ6j388dugtZe+10=; b=WV0WD+BJoOsXG8XXEpX9iwxgO o80SEip/NhMVmfx0mhnS8R/2rIpk+DbbjjRKZ3WcwkK4rJfNTXM2KwvTfZwCuZhrASjv1wE4C3Dlw zvPDBoYQ4AWcKZJyps7YSYTv9qg9NU4h3fW4JBWD7na8G505yKnxvZaVlsDYzhV+qSaG0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji17k-0005eY-Nv; Sun, 07 Jun 2020 19:38:28 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1ji17k-0000fV-By; Sun, 07 Jun 2020 19:38:28 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1ji17k-0001vZ-BM; Sun, 07 Jun 2020 19:38:28 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150906: FAIL X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64::broken:regression linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:host-install(4):broken:heisenbug linux-linus:test-armhf-armhf-xl-rtds:guest-start:fail:heisenbug linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:xen-boot:fail:heisenbug linux-linus:test-amd64-amd64-xl-qemut-debianhvm-amd64:xen-boot:fail:heisenbug linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:capture-logs(5):broken:nonblocking linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=3b69e8b4571125bec1f77f886174fe6cab6b9d75 X-Osstest-Versions-That: linux=aaa2faab4ed8e5fe0111e04d6e168c028fe2987f From: osstest service owner Date: Sun, 07 Jun 2020 19:38:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150906 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150906/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 broken in 150901 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-ws16-amd64 4 host-install(4) broken in 150901 pass in 150906 test-armhf-armhf-xl-rtds 12 guest-start fail in 150901 pass in 150906 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail pass in 150901 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-boot fail pass in 150901 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ws16-amd64 5 capture-logs(5) broken in 150901 blocked in 150898 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 150901 like 150898 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail in 150901 never pass test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150891 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150898 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150898 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150898 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150898 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150898 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150898 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150898 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150898 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150898 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: linux 3b69e8b4571125bec1f77f886174fe6cab6b9d75 baseline version: linux aaa2faab4ed8e5fe0111e04d6e168c028fe2987f Last test of basis 150898 2020-06-06 15:40:08 Z 1 days Testing same since 150901 2020-06-07 02:54:09 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Alan Mikhak Alex Deucher Alex Deucher Alexandru Gagniuc Alexei Starovoitov Aman Sharma Anders Roxell Andrew Murray Ani Sinha Ard Biesheuvel Arnd Bergmann ashimida Ashok Raj Bin Meng Bjorn Helgaas Boris Burkov Brian Cain Bryce Willey Catalin Marinas Changbin Du Christian König Christoph Hellwig Christophe JAILLET Colin Ian King Dan Carpenter Darrel Goeddel Dave Jiang David Rientjes David.Laight@aculab.com (big endian system concerns) Denis Efremov Dinghao Liu Dominik Brodowski Erwan Velu Florian Fainelli Gaku Inami Greg Kroah-Hartman Gustavo A. R. Silva Gustavo Pimentel Huang Rui Jason Yan Jay Fang Jean Delvare Jim Quinlan Jingoo Han Jiri Slaby Joerg Roedel Jon Derrick Jonas Zeiger Josh Poimboeuf Kai-Heng Feng Kalle Valo # wireless Kazufumi Ikeda Kevin Buettner Kishon Vijay Abraham I Krzysztof Kozlowski Krzysztof Struczynski Krzysztof Wilczynski Krzysztof Wilczyński Kunihiko Hayashi Kuninori Morimoto Kuppuswamy Sathyanarayanan Lad Prabhakar Lai Jiangshan Li Zefan Linus Torvalds Linus Walleij Lorenzo Pieralisi Lukas Bulwahn Maninder Singh Marc Zyngier Marcos Scriven Marek Behún Marek Szyprowski Marek Vasut Masahiro Yamada Mathias Nyman Miguel Ojeda Mika Westerberg Mika Westerberg # thunderbolt Mikulas Patocka Mimi Zohar Nathan Chancellor Nathan Chancellor [build] Nick Desaulniers Nicolas Saenz Julienne Pali Rohár Peter Collingbourne Rich Felker Rob Herring Roberto Sassu Romain Naour Sam Ravnborg Sean Fu Sebastian Andrzej Siewior Sedat Dilek Siddharth Gupta Stefan Wahren Steven Rostedt (VMware) Tejun Heo Thierry Reding Thomas Petazzoni Tom Joseph Tomasz Maciej Nowak Valdis Kl ē tnieks Valdis Kletnieks Vaneet Narang Vidya Sagar Wei Hu Wei Liu Wei Yongjun Will Deacon Xiaochun Lee Yicong Yang Yoshihiro Shimoda Zefan Li Zhang Qiang Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 fail test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-amd64-xl-qemuu-ws16-amd64 broken Not pushing. (No revision log; it would be 6054 lines long.) From xen-devel-bounces@lists.xenproject.org Sun Jun 07 19:49:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 19:49:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji1I1-0002U3-0Z; Sun, 07 Jun 2020 19:49:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji1I0-0002Ty-Ip for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 19:49:04 +0000 X-Inumbo-ID: ed9a7908-a8f7-11ea-b204-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ed9a7908-a8f7-11ea-b204-12813bfff9fa; Sun, 07 Jun 2020 19:48:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Nbr1aAwuu491XCFK1VtaztZvm3H5LSbWOoswYHROi3c=; b=UAoH5C4EA8CvUIJE2t1Ap940d 0ZWuiZbv0i/ENEbPrXQPgHUIeQfcVk5La6DHwUbSxHBCVRfQRoFiFfHi/Qwx59aSkQo53AUtqE96B alp3rA4R9KmqAn/JVzb+6whjRe8G7f2SELREVBZaQv4MtOeexJWtp93FhoiXJJZnCnwJI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji1Hu-0005r5-2e; Sun, 07 Jun 2020 19:48:58 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1ji1Ht-0000zZ-LY; Sun, 07 Jun 2020 19:48:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1ji1Ht-0006qt-Ku; Sun, 07 Jun 2020 19:48:57 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150908: all pass - PUSHED X-Osstest-Versions-This: ovmf=28dd887d68409c8788c858e29063ee599ebaaa91 X-Osstest-Versions-That: ovmf=037d86dd7a9ef36c85bf416d358f2ef60a4940b3 From: osstest service owner Date: Sun, 07 Jun 2020 19:48:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150908 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150908/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 28dd887d68409c8788c858e29063ee599ebaaa91 baseline version: ovmf 037d86dd7a9ef36c85bf416d358f2ef60a4940b3 Last test of basis 150894 2020-06-06 08:09:26 Z 1 days Testing same since 150908 2020-06-07 13:10:15 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Irene Park jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 037d86dd7a..28dd887d68 28dd887d68409c8788c858e29063ee599ebaaa91 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sun Jun 07 20:28:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 07 Jun 2020 20:28:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji1to-00064C-Vv; Sun, 07 Jun 2020 20:28:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji1to-000647-8P for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 20:28:08 +0000 X-Inumbo-ID: 64dab9ec-a8fd-11ea-9ad7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 64dab9ec-a8fd-11ea-9ad7-bc764e2007e4; Sun, 07 Jun 2020 20:28:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fpJuVIWi2h0CYHQhEfL7+GzrZW8miJ1Xg2vXESAbpe0=; b=yiYRx56mvQwFsFar43rO4x3At /KBiGxpKE1lSqJbxLB/2DqYngx2saZtQB+YuxHNmuAtnJtlg0NAev/ZYDNZ9L0w908P/UXo2GboSi P36hlxWfPXYo3KaO6d7HDNFoAwnRhVuoELPc4vytlvhzVld5DfS+7g6Lfyrr9u74Vryms=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji1tl-0006kg-J4; Sun, 07 Jun 2020 20:28:05 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1ji1tl-0002gd-0u; Sun, 07 Jun 2020 20:28:05 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1ji1tl-0005cD-0H; Sun, 07 Jun 2020 20:28:05 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 150907: regressions - FAIL X-Osstest-Failures: linux-5.4:test-amd64-i386-pair:guest-migrate/dst_host/src_host/debian.repeat:fail:regression linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=3604bc07c035939266d78d65084c6cd54ffc6d56 X-Osstest-Versions-That: linux=55852b3fd146ce90d4d4306b467261f2c4869293 From: osstest service owner Date: Sun, 07 Jun 2020 20:28:05 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150907 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/150907/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 24 guest-migrate/dst_host/src_host/debian.repeat fail REGR. vs. 150661 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150661 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 3604bc07c035939266d78d65084c6cd54ffc6d56 baseline version: linux 55852b3fd146ce90d4d4306b467261f2c4869293 Last test of basis 150661 2020-06-03 17:08:47 Z 4 days Testing same since 150907 2020-06-07 12:09:12 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Amit Cohen Andrew Morton Anju T Sudhakar Ariel Elior Atsushi Nemoto Benjamin Tissoires Bingbu Cao Borislav Petkov Can Guo Chaitanya Kulkarni Christian Lamparter [formatted, reworded] Christopher M. Riedl Dan Carpenter Dan Williams Daniel Axtens Dave Airlie David Rientjes David S. Miller DENG Qingfang Dinghao Liu Eric Biggers Eugeniy Paltsev Fan Yang Felix Fietkau fengsheng Gerald Schaefer Giuseppe Marco Randazzo Greg Kroah-Hartman Ido Schimmel Jan Schmidt Jaroslav Kysela Jason Gunthorpe Jens Axboe Jeremy Kerr Jiri Kosina John Garry Jonathan McDowell Julian Sax Jérôme Pouiller Kai-Heng Feng Kalle Valo Kirill A. Shutemov Linus Torvalds Lucas De Marchi Madhuparna Bhowmik Mark Brown Martin K. Petersen Matteo Ghidoni Matthew Garrett Matthew Garrett Mauro Carvalho Chehab Michael Ellerman Michal Kalderon Mimi Zohar Nageswara R Sastry Nathan Chancellor Paul E. McKenney (RCU viewpoint) Pierre-Louis Bossart Sakari Ailus Sasha Levin Scott Shumate Stan Johnson Steven Rostedt (VMware) Tejun Heo Thor Thayer Ulf Hansson Valentin Longchamp Vasily Gorbik Vineet Gupta Wolfram Sang Xiang Chen Xinwei Kong jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair fail test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1064 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 08 00:39:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 00:39:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji5pE-00034c-AV; Mon, 08 Jun 2020 00:39:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji5pD-00034X-Fn for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 00:39:39 +0000 X-Inumbo-ID: 85f73498-a920-11ea-b225-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 85f73498-a920-11ea-b225-12813bfff9fa; Mon, 08 Jun 2020 00:39:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=S3FDqyznAYC7/GJD9JCNfxCbJPg+ODflj42rTg5+Apw=; b=6vlkOXmbynlkOVL9LfB9m4BMg Dmlzdxgf2KCMt28iVP4S+0ohkE0NCKexqsAOI7NdvN6RFG5Q9oCu0URhx2rIsibAHtsKu5AFk9cum bxgwtXV9CPLPCba8QSQTvCpljHU/vmC9KYHOTkXVjeZeYcXa+k2Yl7nZg+55RM/pOMblY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji5p7-0003yD-8r; Mon, 08 Jun 2020 00:39:33 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1ji5p6-00078H-Rv; Mon, 08 Jun 2020 00:39:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1ji5p6-0002mF-RD; Mon, 08 Jun 2020 00:39:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150909: regressions - FAIL X-Osstest-Failures: qemu-mainline:build-amd64-xsm:xen-build:fail:regression qemu-mainline:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: qemuu=175198ad91d8bac540159705873b4ffe4fb94eab X-Osstest-Versions-That: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e From: osstest service owner Date: Mon, 08 Jun 2020 00:39:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150909 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150909/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-build fail REGR. vs. 150694 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150694 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150694 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150694 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150694 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuu 175198ad91d8bac540159705873b4ffe4fb94eab baseline version: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e Last test of basis 150694 2020-06-04 11:44:20 Z 3 days Failing since 150831 2020-06-05 13:06:20 Z 2 days 6 attempts Testing same since 150872 2020-06-05 22:39:31 Z 2 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Bulekov Christian Borntraeger Cornelia Huck Gerd Hoffmann Janosch Frank Jared Rossi Kevin Wolf Paolo Bonzini Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Stefan Hajnoczi Stefano Garzarella Thomas Huth Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm fail build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 447 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 08 01:26:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 01:26:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji6YN-0008WM-5I; Mon, 08 Jun 2020 01:26:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji6YM-0008WH-3L for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 01:26:18 +0000 X-Inumbo-ID: 07247818-a927-11ea-b22c-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 07247818-a927-11ea-b22c-12813bfff9fa; Mon, 08 Jun 2020 01:26:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EU/Hp1n7VN94C9UWru7ihtoj7OhYsGB4K61DOOd3YR4=; b=btj0bK3UTu2KBL7xqwcUHvSUu g6ypGWHkHzw+Y9o6w+7uoIhSSA69S92KvoZLl+FXF2x9r0QqiZkev4aVktdzTE2ni5vGhALAaA6ot /ESDc3QtkajfMvPDaA3dwl9XhjteZxdAPLxIY/eKtFbBDxeOideWQRG/3AzphaErxDVFw=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji6YA-0006GM-QH; Mon, 08 Jun 2020 01:26:06 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1ji6YA-00024e-Gj; Mon, 08 Jun 2020 01:26:06 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1ji6YA-0008JG-G7; Mon, 08 Jun 2020 01:26:06 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150911: all pass - PUSHED X-Osstest-Versions-This: ovmf=cfd73e0065f523e1d56bb32b5c9d48e162c903f8 X-Osstest-Versions-That: ovmf=28dd887d68409c8788c858e29063ee599ebaaa91 From: osstest service owner Date: Mon, 08 Jun 2020 01:26:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150911 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150911/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf cfd73e0065f523e1d56bb32b5c9d48e162c903f8 baseline version: ovmf 28dd887d68409c8788c858e29063ee599ebaaa91 Last test of basis 150908 2020-06-07 13:10:15 Z 0 days Testing same since 150911 2020-06-07 20:10:10 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Bob Feng Yuwei Chen jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 28dd887d68..cfd73e0065 cfd73e0065f523e1d56bb32b5c9d48e162c903f8 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Mon Jun 08 03:33:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 03:33:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji8X6-0003eO-JL; Mon, 08 Jun 2020 03:33:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji8X5-0003eG-TR for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 03:33:07 +0000 X-Inumbo-ID: c3c80f3c-a938-11ea-ba62-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c3c80f3c-a938-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 03:33:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vhiwmlpfnkGoKSSvrW0xqqEtNW3eNG/4tWt6yRajiWc=; b=xMF4Z9B8WAgP8JWDs3ZA0vCae 08wihZrhouSksv7JXLC7TBRS56j124lw5VUod6qOh9xXpWYVp67WfGKKzEg4G29nAXHCJfKwXuIl0 uO48w00WmBYWK328nip6lCDp4jmnlcEB3+y/JnBuqDvewG7rczNyZOyCxLo+srFgbmNkU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji8X3-0001Tx-0x; Mon, 08 Jun 2020 03:33:05 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1ji8X2-0000v5-Ir; Mon, 08 Jun 2020 03:33:04 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1ji8X2-0002eR-IG; Mon, 08 Jun 2020 03:33:04 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150910: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=9aa900c8094dba7a60dc805ecec1e9f720744ba1 X-Osstest-Versions-That: linux=aaa2faab4ed8e5fe0111e04d6e168c028fe2987f From: osstest service owner Date: Mon, 08 Jun 2020 03:33:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150910 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150910/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150898 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150898 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150898 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150898 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150898 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150898 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150898 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150898 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150898 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150898 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: linux 9aa900c8094dba7a60dc805ecec1e9f720744ba1 baseline version: linux aaa2faab4ed8e5fe0111e04d6e168c028fe2987f Last test of basis 150898 2020-06-06 15:40:08 Z 1 days Failing since 150901 2020-06-07 02:54:09 Z 1 days 3 attempts Testing same since 150910 2020-06-07 20:10:01 Z 0 days 1 attempts ------------------------------------------------------------ 382 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git aaa2faab4ed8..9aa900c8094d 9aa900c8094dba7a60dc805ecec1e9f720744ba1 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Mon Jun 08 04:17:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 04:17:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji9EB-0007Lb-Si; Mon, 08 Jun 2020 04:17:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1ji3e7-0007UL-C4 for xen-devel@lists.xenproject.org; Sun, 07 Jun 2020 22:20:03 +0000 X-Inumbo-ID: 03dfadb8-a90d-11ea-9ad7-bc764e2007e4 Received: from mail-wr1-x42b.google.com (unknown [2a00:1450:4864:20::42b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 03dfadb8-a90d-11ea-9ad7-bc764e2007e4; Sun, 07 Jun 2020 22:19:55 +0000 (UTC) Received: by mail-wr1-x42b.google.com with SMTP id h5so15399800wrc.7 for ; Sun, 07 Jun 2020 15:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kota.moe; s=google; h=mime-version:from:date:message-id:subject:to; bh=hHTcj8gSt6bxo+wzkFqQn+lRFDX6IJOKi1kquEIyOXg=; b=ZQoEra6W7sClkWwJgTCdiRPvR7xafHFijYaK8YZIrEoiA1MKKJhAVmMEF1bRfB6NdK es2dI/jnuzSFWuGHlccnJMHJxC9vwZYw4KS+eXKnNHQR656ujHqVCT8sIdJW/5R105bl O2+ZOMjAVEI2+82yMVmeUCjb0gav34oW9Rf8c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hHTcj8gSt6bxo+wzkFqQn+lRFDX6IJOKi1kquEIyOXg=; b=MlZ6VTfxoyiSLHpgxZ4vXKknMp7WJaD8+hiLQ2WAdtxkohzzD+bhsV2GJRkWRCL/t5 N0dWOclTRt2GquJoEMrPqGgjrewcY64xVXpt5b2rqcMn66hgTGeB8yQF6vGtO1cRtCoJ /f/gCH+jFitevMwDbo3CP7Ff6OcVVy3tkO1Q812ImoLs82k7YLqwbS52AfgGhapmEh2R jtsYwl6mYpl4vILmNSLdToQez87qf4XHz2L68692gSjUH/fof9zE7AHbC15fXA83zcT0 RWD0QK5vhtoirEtLyfgEbHNGGUN6dOKiUyoSX0O5dNLTDq069VqLsy0QkbCwoFp26s/1 B05g== X-Gm-Message-State: AOAM531TIknbQIsqhLz2UTmmx1Z9eG/QSa8jy2LaXjEy19rmWDf6GolN g1NhGwfIUpVUKNrKbtYayc+QkD4J2qIm9e8/eGX9kUOexr8evg== X-Google-Smtp-Source: ABdhPJwkxN2jO1yq14hOBGp80GZBc8UHJepFI0SRm9rQ15NZAFnGvKy/wRqdSIwVRyjwDfFJf4wIs9yXZdygUqRBuB8= X-Received: by 2002:adf:ef83:: with SMTP id d3mr19306229wro.145.1591568394428; Sun, 07 Jun 2020 15:19:54 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?4oCN5bCP5aSq?= Date: Mon, 8 Jun 2020 08:19:18 +1000 Message-ID: Subject: xenforeignmemory fails to map PCI device memory with "Invalid Argument" error To: xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Mon, 08 Jun 2020 04:17:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi xen-devel, I'm trying to read HVM guest PCI memory from Dom0 using the xenforeignmemory library, but it's consistently failing with "Invalid Argument", no matter which PCI device I try. However, if I try to map in regular (non-device) memory, it seems to work fine. Do you know why I can't seem to map in guest PCI memory? Am I meant to be mapping in the memory in some other way instead? (Background: I'm trying to port Looking Glass to Xen: https://forum.level1techs.com/t/looking-glass-on-xen/158089) Some example code to demonstrate the problem: #include #include #include #include #include void map(xenforeignmemory_handle* xfm, uint32_t dom, uintptr_t addr) { xen_pfn_t frame = addr / sysconf(_SC_PAGESIZE); void* out = xenforeignmemory_map(xfm, dom, PROT_READ | PROT_WRITE, 1, &frame, NULL); if (!out) { printf("Failed to map Dom%u's 0x%08lx: %m\n", dom, addr); return; } printf("Dom%u 0x%08lx: 0x%08lx 0x%08lx 0x%08lx 0x%08lx\n", dom, addr, ((unsigned long*)out)[0], ((unsigned long*)out)[1], ((unsigned long*)out)[2], ((unsigned long*)out)[3] ); xenforeignmemory_unmap(xfm, out, 1); } int main(void) { xenforeignmemory_handle* xfm = xenforeignmemory_open(NULL, 0); if (!xfm) { perror("xenforeignmemory_open"); return 1; } // Regular memory - works fine map(xfm, 3, 0x10000000); // PCI device memory - errors with "Invalid Argument" map(xfm, 3, 0xf2311000); xenforeignmemory_close(xfm); return 0; } In this case, Dom 3's 0xf2311000 belongs to the emulated SATA device: $ sudo xl qemu-monitor-command 3 'info pci' ...snip... Bus 0, device 5, function 0: SATA controller: PCI device 8086:2922 PCI subsystem 1af4:1100 IRQ 0. BAR4: I/O at 0xc260 [0xc27f]. BAR5: 32 bit memory at 0xf2311000 [0xf2311fff]. id "ahci0" ...snip... From xen-devel-bounces@lists.xenproject.org Mon Jun 08 06:25:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 06:25:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBDu-0004N4-3G; Mon, 08 Jun 2020 06:25:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBDt-0004Mz-In for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 06:25:29 +0000 X-Inumbo-ID: d7c97116-a950-11ea-96fb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d7c97116-a950-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 06:25:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SLYvIOKXNIKbZ2BiVe5LWjm53cRnUc1N6SovocEjKt4=; b=HDl1hQn+4GG9KzoIxyCVjW3II VSB0IxQu59i2IEi0tOPNNe5ALvCzasatKn0sJj1mRTh/+EqrjYWfEMiWjHwRkKJl47WCatPaGqGGG IbSWtlbeXpToboMSQ5BCYn4ziNIoScoqIHj0m6fxjO+TOFFCSebyWhcNQMXlFqBY9K1X4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBDq-0007n4-E0; Mon, 08 Jun 2020 06:25:26 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiBDq-0001iD-6B; Mon, 08 Jun 2020 06:25:26 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiBDq-0004OX-4z; Mon, 08 Jun 2020 06:25:26 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 150912: tolerable FAIL - PUSHED X-Osstest-Failures: linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=3604bc07c035939266d78d65084c6cd54ffc6d56 X-Osstest-Versions-That: linux=55852b3fd146ce90d4d4306b467261f2c4869293 From: osstest service owner Date: Mon, 08 Jun 2020 06:25:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150912 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/150912/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150661 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 3604bc07c035939266d78d65084c6cd54ffc6d56 baseline version: linux 55852b3fd146ce90d4d4306b467261f2c4869293 Last test of basis 150661 2020-06-03 17:08:47 Z 4 days Testing same since 150907 2020-06-07 12:09:12 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Amit Cohen Andrew Morton Anju T Sudhakar Ariel Elior Atsushi Nemoto Benjamin Tissoires Bingbu Cao Borislav Petkov Can Guo Chaitanya Kulkarni Christian Lamparter [formatted, reworded] Christopher M. Riedl Dan Carpenter Dan Williams Daniel Axtens Dave Airlie David Rientjes David S. Miller DENG Qingfang Dinghao Liu Eric Biggers Eugeniy Paltsev Fan Yang Felix Fietkau fengsheng Gerald Schaefer Giuseppe Marco Randazzo Greg Kroah-Hartman Ido Schimmel Jan Schmidt Jaroslav Kysela Jason Gunthorpe Jens Axboe Jeremy Kerr Jiri Kosina John Garry Jonathan McDowell Julian Sax Jérôme Pouiller Kai-Heng Feng Kalle Valo Kirill A. Shutemov Linus Torvalds Lucas De Marchi Madhuparna Bhowmik Mark Brown Martin K. Petersen Matteo Ghidoni Matthew Garrett Matthew Garrett Mauro Carvalho Chehab Michael Ellerman Michal Kalderon Mimi Zohar Nageswara R Sastry Nathan Chancellor Paul E. McKenney (RCU viewpoint) Pierre-Louis Bossart Sakari Ailus Sasha Levin Scott Shumate Stan Johnson Steven Rostedt (VMware) Tejun Heo Thor Thayer Ulf Hansson Valentin Longchamp Vasily Gorbik Vineet Gupta Wolfram Sang Xiang Chen Xinwei Kong jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 55852b3fd146..3604bc07c035 3604bc07c035939266d78d65084c6cd54ffc6d56 -> tested/linux-5.4 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 06:57:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 06:57:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBiX-00075K-LP; Mon, 08 Jun 2020 06:57:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBiW-00075F-0D for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 06:57:08 +0000 X-Inumbo-ID: 441a3388-a955-11ea-96fb-bc764e2007e4 Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 441a3388-a955-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 06:57:07 +0000 (UTC) Received: by mail-ed1-x541.google.com with SMTP id q13so12484682edi.3 for ; Sun, 07 Jun 2020 23:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=7K9fVA8fnBITxOEn7HyaE9CzhB49ZAxRiYx5HD9McHY=; b=RmkY//izegF54FzYu1u/rApVmEdvNDeh3joGb1JiAWI9IO8lr/R/63wvRYuu13/XNW pmzQtLesVUnb/Vf28wzUlmOvhtWEmQtn/3nJdhhKlTzdlU/yL77B9whRva669G1OUXcZ nM0Zode9onRj/4pFJde6oFf67DNbqu14cGcrW12xuVD0kImKF1s33EMZOZQCbMsrXQ10 wb8NQHiGeR3amTRbsK1iCK2gKtGhAtfMsaNdtBMRan7NeezmV9JuBcSnCupfURCFrJaf WPsO6oVelONM1mssYlXvPO4b+LvhzafM+ohSL0O7Xu3S7AajcsbeZozry/Z5D9OBnNhe xQbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=7K9fVA8fnBITxOEn7HyaE9CzhB49ZAxRiYx5HD9McHY=; b=lc41+F+yn6MxjMGOnctEU4RFEl4qmaCbYQQDOJKjxc8WSh64Qs0BWw42X0O4aZXhy0 gEkpFy5IBuslS8zcdjxZFGrSNRANSkfSK8urThCsvrWaN5hisuVL+Jwg5ugkSLv6Vb0w AAaq6QV8t0LXL2Ws8m81g+XUYmkWQtwc9tpId8WpsPfuCEFM56xEUwdf4fxEo/vYxVnt oEu1Fk7c9XjjeVNFITI5Qy4CRNWmTMhwMDRF/Cim8jjlm4AbObpOzvcW3IEJYnGz+i/K RhxMnIB0kQBnPlnTgCd+sL91SKoARULY263HyCx4G7Sr7X6Ahk7+ONDsI12bplwUrOjC c5mg== X-Gm-Message-State: AOAM532EZEefRVOVXD0yuUqXn/HdQQ2fgakiL7wyxmGySfPfawNjgesi zYtKtYrxGFQoSeyM2CX/Uvw= X-Google-Smtp-Source: ABdhPJxtQA7+v4NGtIDpi6p+3NRJ9oJydGUDfXD3OPH4BSekI6f5bTK6a4mc1BOfVer6wxdwzyyD1g== X-Received: by 2002:a05:6402:1d29:: with SMTP id dh9mr20534849edb.269.1591599426452; Sun, 07 Jun 2020 23:57:06 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id g61sm11601934ede.96.2020.06.07.23.57.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jun 2020 23:57:05 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Julien Grall'" , References: <20200607155154.15928-1-julien@xen.org> In-Reply-To: <20200607155154.15928-1-julien@xen.org> Subject: RE: [PATCH for-4.14] xen/arm: mm: Access a PT entry before the table is unmapped Date: Mon, 8 Jun 2020 07:57:04 +0100 Message-ID: <001801d63d62$053ecf20$0fbc6d60$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHJdNA9DFLPMohWTRTVE9LH4GQ7qKjn2eig X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Julien Grall' , 'Stefano Stabellini' , 'Volodymyr Babchuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Julien Grall > Sent: 07 June 2020 16:52 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Julien Grall ; Stefano Stabellini ; > Julien Grall ; Volodymyr Babchuk > Subject: [PATCH for-4.14] xen/arm: mm: Access a PT entry before the table is unmapped > > From: Julien Grall > > xen_pt_next_level() will retrieve the MFN from the entry right after the > page-table has been unmapped. > > After calling xen_unmap_table(), there is no guarantee the mapping will > still be valid. Depending on the implementation, this may result to a > data abort in Xen. > > Re-order the code to retrieve the MFN before the table is unmapped. > > Fixes: 53abb9a1dcd9 ("xen/arm: mm: Rework Xen page-tables walk during update") > Signed-off-by: Julien Grall > Release-acked-by: Paul Durrant > --- > > I spotted this issue while reworking how page-tables are mapped on Arm64 > during early boot. However the problem should be already there on Arm32. > > I am actually quite amazed we haven't seen any crash on Arm32 because > there is no direct map. So the mapping will not exist after calling > xen_unmap_table(). > > I suspect this works because unmap_domain_page() doesn't flush the > TLBs. So the TLB still likely have the entry cached (joy!). > > This patch is a candidate for Xen 4.14 and should also be backported. > --- > xen/arch/arm/mm.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index 1b14f4934570..9e2ff7c8005d 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -1036,6 +1036,7 @@ static int xen_pt_next_level(bool read_only, unsigned int level, > { > lpae_t *entry; > int ret; > + mfn_t mfn; > > entry = *table + offset; > > @@ -1053,8 +1054,10 @@ static int xen_pt_next_level(bool read_only, unsigned int level, > if ( lpae_is_mapping(*entry, level) ) > return XEN_TABLE_SUPER_PAGE; > > + mfn = lpae_get_mfn(*entry); > + > xen_unmap_table(*table); > - *table = xen_map_table(lpae_get_mfn(*entry)); > + *table = xen_map_table(mfn); > > return XEN_TABLE_NORMAL_PAGE; > } > -- > 2.17.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:04:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:04:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBpg-00083W-E8; Mon, 08 Jun 2020 07:04:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBpf-00082n-2K for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:04:31 +0000 X-Inumbo-ID: 4429b7bc-a956-11ea-96fb-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4429b7bc-a956-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 07:04:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=kOgcUHX0zNsLgrzKIZZVZ5HbxzYUV6u6MWDbb+56ot4=; b=K6P/0nS7ZwAPQ6b6LI1ZuIGzyy ZsIOCpn8sIKiwGcRm/viCmJMlJo1qAUGgZGwQiu6PxEL0xZYhDh1APKzKZmtiFiyds86D/Jy++Q2J obCYjtQP8fFufQa0NW/FUBuBr3eplMnoM1YyDMB+VqppJJ1pxfKZDFUc9V0Ma4EfL2d64Ok5cSzLv ymfhxvD2A20eHhIay4/PnULLqqE3bh19DaICVqjssKuxl4nIN0T2TBnA9p+u+TRd1jQoNtzOmbmOD o2F1k1ZEvu/MlL9t7pjju9m0J/YJoZBe5fIonIAs2eTO+qHFoWilwSzMI/oWm6SCU77ywPLyTbth7 +jNXKQNg==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiBpL-0000kv-Rr; Mon, 08 Jun 2020 07:04:11 +0000 Date: Mon, 8 Jun 2020 00:04:11 -0700 From: Christoph Hellwig To: Stefano Stabellini Subject: Re: [PATCH v2 01/11] swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses Message-ID: <20200608070411.GA15742@infradead.org> References: <20200603222247.11681-1-sstabellini@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603222247.11681-1-sstabellini@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Well, this isn't just RPi4, but basically any ARM or ARM64 system with non-coherent DMA (which is most of them). > + struct page *pg; Please spell out page. > > if (hwdev && hwdev->coherent_dma_mask) > dma_mask = hwdev->coherent_dma_mask; > @@ -346,9 +347,11 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, > /* Convert the size to actually allocated. */ > size = 1UL << (order + XEN_PAGE_SHIFT); > > + pg = is_vmalloc_addr(vaddr) ? vmalloc_to_page(vaddr) : > + virt_to_page(vaddr); Please use plain old if/else to make this more readable. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:05:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:05:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBqP-00087V-Rp; Mon, 08 Jun 2020 07:05:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBqP-00087P-Gj for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:05:17 +0000 X-Inumbo-ID: 646a3fba-a956-11ea-9ad7-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 646a3fba-a956-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 07:05:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=S378zGSpOf2f7Q1RRRkaUsWspkKGCnohH5tp/UAp9n0=; b=V56K/fI9pjhCqJKos2pXtAWzdJ IphlrsZzSU87eJoW4gUlDxlRMK8XKWdF6sWXg+ABe2d8azTKmXcwo3GsLbp9FC9nri4P7rNoQfK2b IHe4yDNGfXzdrzk45+HD73DnopkZDOcgi4mrLQY1pO7RZH5DUj/yPMTXKv+EvylhGDG27C1njPHqC z/ZJOu+NCVJl/u+gi+XqqeZYEVos53iiqpz2zEueMKYMSSLPowiJYMS6PYrgS5f467jzZLajCe5vk daoFPXBmmeck3KP+RwmUjtAP3gBckUQka4/SFJw6CYanCAUFcruaN0XJQlgaQTGlCkAeotzPRHQDa IsErvlQw==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiBqF-0002Ke-SQ; Mon, 08 Jun 2020 07:05:07 +0000 Date: Mon, 8 Jun 2020 00:05:07 -0700 From: Christoph Hellwig To: Stefano Stabellini Subject: Re: [PATCH v2 03/11] swiotlb-xen: add struct device* parameter to xen_phys_to_bus Message-ID: <20200608070507.GB15742@infradead.org> References: <20200603222247.11681-3-sstabellini@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603222247.11681-3-sstabellini@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 03:22:39PM -0700, Stefano Stabellini wrote: > From: Stefano Stabellini > > The parameter is unused in this patch. > No functional changes. This looks weird. I'm pretty sure you are going to use it later, but why not just add the argument when it actually is used? From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:05:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:05:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBqv-0008Bt-57; Mon, 08 Jun 2020 07:05:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBqt-0008Bc-P7 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:05:47 +0000 X-Inumbo-ID: 77b8184e-a956-11ea-9b55-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 77b8184e-a956-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 07:05:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=7U+YuzUXCE0mJTp+dzDjktj85iFXgfVb4+sX78AimxA=; b=t9ZtB8KrPobjfP37mn9PfXTOLL hbJ48V3TGx/y1Ob8pefkO7PtqfJ1GhdVdawR2fBv9Nnt6Ry1l4i7RCTDpanqbn0543t5inWZpSiLJ MBHirWUVu4Bj4gjeitX3d0Xcy0BUMqCIZlJ5TDTPYSTPsW4rD20mPGeOqXhefVsDad/4p/uwXN9ts BFJQazZwUt8iQOhbgVV/u98RhSgAFQz/xYRyVbBHhUWpeupPcuahDUY4dQ/huAv/k521Tu0htnB8W TwuxXAuLOZC3LvaKs7g9iYJQEUwkUH+Xcw1g2E4xW7kCZdhElaGQyarktIVMkReqigHZQuuhY3uZv XaMSveiw==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiBqm-0003E7-8a; Mon, 08 Jun 2020 07:05:40 +0000 Date: Mon, 8 Jun 2020 00:05:40 -0700 From: Christoph Hellwig To: Stefano Stabellini Subject: Re: [PATCH v2 04/11] swiotlb-xen: add struct device* parameter to xen_bus_to_phys Message-ID: <20200608070540.GC15742@infradead.org> References: <20200603222247.11681-4-sstabellini@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603222247.11681-4-sstabellini@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Same comment as for the last one. Also in the subject a whitespace is missing after "device" and before "*". From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:08:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:08:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBtu-0008Pf-N3; Mon, 08 Jun 2020 07:08:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBtt-0008PZ-Rn for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:08:53 +0000 X-Inumbo-ID: e8e10648-a956-11ea-9b55-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e8e10648-a956-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 07:08:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=GNcfAufzhmcZvITdjn5d4FK3irCQ3OWSgr/t5h/uSsM=; b=J02CvmxjrAcCbEc9Whcw7Qcvop VGY6Kx1ZJ43S5swYCuSo6bi3FcOwvKtkrC6CKxzaYQh41SWGb3hv0VaveFZyta/wB/6YAU7BrXBq5 B2egWBkq1tEH2dD7ZEULwRZ1nEDgwLv4tYTcyXuT859vDNGAXGCG3yYzoSGFFgu+bqlCB76t5tGnz BHbVcDrQUYrQ0n7rk2/3eIOzABLOenvBfBj7aKcNyzpfnmKddPQx2KKNEKfeP2zPYJsTuwQNHqAUM PlO8owPfU5BhcG6lNO519+O06CuPdLOAv8AntxWaunTGGsIaewGh3wx7SeMCSuUQjci9l8r5qiOyO Vo8h0lvw==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiBtq-0003QO-AY; Mon, 08 Jun 2020 07:08:50 +0000 Date: Mon, 8 Jun 2020 00:08:50 -0700 From: Christoph Hellwig To: Stefano Stabellini Subject: Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations Message-ID: <20200608070850.GD15742@infradead.org> References: <20200603222247.11681-8-sstabellini@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603222247.11681-8-sstabellini@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 03:22:44PM -0700, Stefano Stabellini wrote: > From: Stefano Stabellini > > With some devices physical addresses are different than dma addresses. > To be able to deal with these cases, we need to call phys_to_dma on > physical addresses (including machine addresses in Xen terminology) > before returning them from xen_swiotlb_alloc_coherent and > xen_swiotlb_map_page. > > We also need to convert dma addresses back to physical addresses using > dma_to_phys in xen_swiotlb_free_coherent and xen_swiotlb_unmap_page if > we want to do any operations on them. > > Call dma_to_phys in is_xen_swiotlb_buffer. > Call phys_to_dma in xen_phys_to_bus. > Call dma_to_phys in xen_bus_to_phys. > > Everything is taken care of by these changes except for > xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a > few explicit phys_to_dma/dma_to_phys calls. > > Signed-off-by: Stefano Stabellini > Tested-by: Corey Minyard > Tested-by: Roman Shaposhnik > --- > Changes in v2: > - improve commit message > --- > drivers/xen/swiotlb-xen.c | 22 ++++++++++++---------- > 1 file changed, 12 insertions(+), 10 deletions(-) > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c > index 0a6cb67f0fc4..60ef07440905 100644 > --- a/drivers/xen/swiotlb-xen.c > +++ b/drivers/xen/swiotlb-xen.c > @@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) > > dma |= paddr & ~XEN_PAGE_MASK; > > - return dma; > + return phys_to_dma(dev, dma); So looking at this function: The dma name for something passed to phys_to_dma is really weird. The fact that the comments says don't use XEN_PFN_PHYS beause of the type mismatch while nothing but swiotlb-xen is the only user of XEN_PFN_PHYS is also weird. I think XEN_PFN_PHYS needs to move to swiotlb-xen first, then use a hardcoded u64 for the size, and the split the function into a phys_to_xen_phys (or so) function where the result gets passed to phys_to_dma. Similar for the reverse direction. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:09:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:09:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBud-0008TH-1K; Mon, 08 Jun 2020 07:09:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBub-0008T4-Ke for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:09:37 +0000 X-Inumbo-ID: 031227cc-a957-11ea-ba62-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 031227cc-a957-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 07:09:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=riTlVvjTBVFVzOBQ14vr3osfjEjXKYJJb4irFAZraug=; b=mrrf00JD+nWPYE2DUp6aInWaGN a0TxqMgzuk/LZrKik9Im/aZcH6eN6HqEQ6SXpJb1qToyKWPK/mAAx6+qceEklRjCStr6sT9NR15iC G7zApsVtqHeNiJLCkNz/l/f3NxMiEJWdWykEdvN17+3WrJmZ37+O4628h8PIkyaTbI6dyc4WpeS7w /CvBKq3CoXFkMGqT8kq6RGDfyyGSqG9B735Rq17SHasqFOmkkWHaOJJgPzhNxGk2HMBsdqDvWOL8X KixbEX6rwCAMRY9fmWt8XRMo5f6s2AsghXmBgqFVATH/dejo6gIXS5Uuonc7MSsGYPgNwsGeoeC2q 1wRSFvkQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiBuY-0003VP-6I; Mon, 08 Jun 2020 07:09:34 +0000 Date: Mon, 8 Jun 2020 00:09:34 -0700 From: Christoph Hellwig To: Stefano Stabellini Subject: Re: [PATCH v2 09/11] swiotlb-xen: rename xen_phys_to_bus to xen_phys_to_dma and xen_bus_to_phys to xen_dma_to_phys Message-ID: <20200608070934.GE15742@infradead.org> References: <20200603222247.11681-9-sstabellini@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603222247.11681-9-sstabellini@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 03:22:45PM -0700, Stefano Stabellini wrote: > so that their names can better describe their behavior. > > No functional changes. I think this should go with the actual change, and adding the parameters. Touching this function piecemail in three patches for what really is a single logical change is rather strange. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:11:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:11:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBvw-0000tH-Eq; Mon, 08 Jun 2020 07:11:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBvw-0000tC-4K for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:11:00 +0000 X-Inumbo-ID: 31622794-a957-11ea-96fb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 31622794-a957-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 07:10:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ro5kyLqKFxon7E+ohRMnBdYEG3ywjT8M+mRM2Z1flRE=; b=PhuBr11iHjwrG/2x5XQRU2k+8 mOTOdEKe89uZU8rtBLdt87cJmqX9FKlAisZ/jRe7py4bTOisqG09vmDCPHVjY9TFOF6l9sMJGR7Td IzNJIY9Z260y3TfUIW3N9p12+muimZvCPll+sYi0AoGrs8vuhv8uMVUEaVm60T3mBqh4I=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBvp-0000NW-Oc; Mon, 08 Jun 2020 07:10:53 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiBvp-0003w7-D2; Mon, 08 Jun 2020 07:10:53 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiBvp-0004pn-CV; Mon, 08 Jun 2020 07:10:53 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150917: all pass - PUSHED X-Osstest-Versions-This: ovmf=6ff7c838d09224dd4e4c9b5b93152d8db1b19740 X-Osstest-Versions-That: ovmf=cfd73e0065f523e1d56bb32b5c9d48e162c903f8 From: osstest service owner Date: Mon, 08 Jun 2020 07:10:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150917 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150917/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 baseline version: ovmf cfd73e0065f523e1d56bb32b5c9d48e162c903f8 Last test of basis 150911 2020-06-07 20:10:10 Z 0 days Testing same since 150917 2020-06-08 01:40:21 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Leif Lindholm jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git cfd73e0065..6ff7c838d0 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:12:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:12:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBxJ-0000zm-S5; Mon, 08 Jun 2020 07:12:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiBxI-0000zf-Qe for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:12:24 +0000 X-Inumbo-ID: 66b40caa-a957-11ea-9ad7-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 66b40caa-a957-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 07:12:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=emLpIRFKODtAY8nraJqoNKwCIZphU+FBPDM0NtY/3Cg=; b=qKLVusHbJYznuKqC4wYTwNYxiq Xb6vUmAIBx0gFjK3PxshUq4aOfkih9+uu++SCVrvyUUF5llRcys6YJGKrp517NSaA1JJZ7bNS+09r tXPPUoOVLkozSIBGBOEzhUFUoCkjs9Hg8EpdQGxOKEi4WxCluYOlXDbEJSOUbc6v0ItEHJ/I3jaBs Dv89DRKpkXZiuuiTOZHep+TxL8cYs4ex18Xqp94Rx+vbQJpwXr/VaHpkErBL23hnksk3bs5mByiAh SgBM5UQujchw6Unrh83lvTzP8E86P7LrQhjrwnpE3ZZd1kHV2+IssHu6Jh2EeGhfooWhxvL/aTlgc WenzY0Ng==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiBxF-0006OS-9X; Mon, 08 Jun 2020 07:12:21 +0000 Date: Mon, 8 Jun 2020 00:12:21 -0700 From: Christoph Hellwig To: Stefano Stabellini Subject: Re: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_* Message-ID: <20200608071221.GF15742@infradead.org> References: <20200603222247.11681-10-sstabellini@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200603222247.11681-10-sstabellini@kernel.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 03, 2020 at 03:22:46PM -0700, Stefano Stabellini wrote: > From: Stefano Stabellini > > xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are > getting called passing dma addresses. On some platforms dma addresses > could be different from physical addresses. Before doing any operations > on these addresses we need to convert them back to physical addresses > using dma_to_phys. > > Add dma_to_phys calls to xen_dma_sync_for_cpu, xen_dma_sync_for_device, > and xen_arch_need_swiotlb. > > dma_cache_maint is fixed by the next patch. The calling conventions because really weird now because xen_dma_sync_for_{device,cpu} already get both a phys_addr_t and a dma_addr_t. > > - if (pfn_valid(PFN_DOWN(handle))) > + if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle)))) But here we translate the dma address to a phys addr > arch_sync_dma_for_cpu(paddr, size, dir); While this still uses the passed in paddr. I think the uses of addresses in this code really needs a major rethink. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:16:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:16:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiC1P-0001BZ-Ei; Mon, 08 Jun 2020 07:16:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiC1N-0001BU-LI for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:16:37 +0000 X-Inumbo-ID: fd31beca-a957-11ea-ba62-bc764e2007e4 Received: from mail-wr1-x436.google.com (unknown [2a00:1450:4864:20::436]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fd31beca-a957-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 07:16:36 +0000 (UTC) Received: by mail-wr1-x436.google.com with SMTP id c3so16137285wru.12 for ; Mon, 08 Jun 2020 00:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Lb5RKUus1nw/vCNQmPl6ydLOwk5yInAAPsiNBgTIcks=; b=UcLYGP+7UQY9J5GHvrXobHNzFqATzO6Y8O5Lxi0WZBiKT7QJ2auIxeFvU0Zwg0Fl5L NyEwf1nz3jOPhvkBztumLEbbTSO5pG3VJVo52AcZk8ik5WVxsOPtF+mkVJJuW5Dtba28 UPPx2jsVQ0wZdX5eoUfLmCTRE/MiuV93o6sYh+iCc/hh5+vhNg81yj2+zM1h4mCnWtcC XhaVErY5GNGjXlcKH0pKFqUKVZvx3dG6Teyqrh6ggBeQ2CiZcEIMaOv/PuFV47L8EXnn Xk+fWL97IosFE7JiKSxMuDiRp8DITQLM0wy6KICRY6PK/ZjWoISc0bh86mBWSkM8qDgN DR4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=Lb5RKUus1nw/vCNQmPl6ydLOwk5yInAAPsiNBgTIcks=; b=GVthxn9NclleSLw0mrHHxnKO67t0+w/wiRvU5wOpvXBwW10BiMNSUjYUXMrnD8D7V/ nSMDAMvVc5xvTKb+DBy+xNHX/ChNVOvYAxtXgLl4dPsGsgN0yIPCTj6VGmO4CVVNLXe7 PR8HSoD/rIXiEmqo6GLjpHO9UMVE4y/FieJAT+9AkZYh7eftwVX6PbTflBAdr3kguezt EGhTHJ0Y/cXI/WhvdJNKsnKJyTKUkf99TMyJrum5JTjQmQ9SFv8y71mq/s5V6FdUzN8o PQn9uXwmsFQttlEYtQqH3LV8qGyy+FlkgIWNhfgBdRS3vjgHqVtCXuF+6Rvd3+vrWsxe NOEg== X-Gm-Message-State: AOAM5323M8t2ftLCSeP3roPYEGiyOmrrAcT8ohBDnH8Kh8TszNNtvrmV 05VAtbOhaKKtVX4969Lc7aA= X-Google-Smtp-Source: ABdhPJz+zJr9dXsemaLNBpxq3KOnuu4rehyDFS8hdMpW0iCYk5UkFQQhctHl0jhaedq2O7KmHf3Uvw== X-Received: by 2002:a5d:628c:: with SMTP id k12mr21865179wru.211.1591600595974; Mon, 08 Jun 2020 00:16:35 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id g19sm1059860wmh.29.2020.06.08.00.16.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 00:16:35 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , References: In-Reply-To: Subject: RE: [PATCH v2] build: fix dependency tracking for preprocessed files Date: Mon, 8 Jun 2020 08:16:33 +0100 Message-ID: <001901d63d64$be475c60$3ad61520$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKkJ/Oy2eqdW+EjW3qdCJH7l2wxc6cyeTUg X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 05 June 2020 15:23 > To: xen-devel@lists.xenproject.org > Cc: Andrew Cooper ; George Dunlap ; Ian Jackson > ; Julien Grall ; Stefano Stabellini > ; Wei Liu ; Paul Durrant > Subject: [PATCH v2] build: fix dependency tracking for preprocessed files > > While the issue is more general, I noticed that asm-macros.i not getting > re-generated as needed. This was due to its .*.d file mentioning > asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at > it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds > dependency tracking files. While there, further avoid open-coding $(CPP) > and drop the bogus (Arm) / stale (x86) -Ui386. > > Signed-off-by: Jan Beulich > --- > v2: Move -MQ ahead on command lines. Looks like this is a fairly low risk fix to pull into 4.14 and it looks like it would be worth it... Release-acked-by: Paul Durrant > > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -201,13 +201,13 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y) > $(call if_changed,obj_init_o) > > quiet_cmd_cpp_i_c = CPP $@ > -cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ > +cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) -MQ $@ -o $@ $< > > quiet_cmd_cc_s_c = CC $@ > cmd_cc_s_c = $(CC) $(filter-out -Wa$(comma)%,$(c_flags)) -S $< -o $@ > > quiet_cmd_s_S = CPP $@ > -cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) $< -o $@ > +cmd_s_S = $(CPP) $(filter-out -Wa$(comma)%,$(a_flags)) -MQ $@ -o $@ $< > > %.i: %.c FORCE > $(call if_changed,cpp_i_c) > --- a/xen/arch/arm/Makefile > +++ b/xen/arch/arm/Makefile > @@ -123,9 +123,7 @@ asm-offsets.s: $(TARGET_SUBARCH)/asm-off > $(CC) $(filter-out -flto,$(c_flags)) -S -o $@ $< > > xen.lds: xen.lds.S > - $(CC) -P -E -Ui386 $(a_flags) -o $@ $< > - sed -e 's/xen\.lds\.o:/xen\.lds:/g' <.xen.lds.d >.xen.lds.d.new > - mv -f .xen.lds.d.new .xen.lds.d > + $(CPP) -P $(a_flags) -MQ $@ -o $@ $< > > dtb.o: $(CONFIG_DTB_FILE) > > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -244,9 +244,7 @@ $(BASEDIR)/include/asm-x86/asm-macros.h: > > efi.lds: AFLAGS-y += -DEFI > xen.lds efi.lds: xen.lds.S > - $(CC) -P -E -Ui386 $(filter-out -Wa$(comma)%,$(a_flags)) -o $@ $< > - sed -e 's/.*\.lds\.o:/$(@F):/g' <.$(@F).d >.$(@F).d.new > - mv -f .$(@F).d.new .$(@F).d > + $(CPP) -P $(filter-out -Wa$(comma)%,$(a_flags)) -MQ $@ -o $@ $< > > boot/mkelf32: boot/mkelf32.c > $(HOSTCC) $(HOSTCFLAGS) -o $@ $< From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:29:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:29:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiCDd-0002Ab-Mn; Mon, 08 Jun 2020 07:29:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiCDa-0002AW-Et for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:29:16 +0000 X-Inumbo-ID: be0f3126-a959-11ea-b24e-12813bfff9fa Received: from mo4-p00-ob.smtp.rzone.de (unknown [81.169.146.217]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id be0f3126-a959-11ea-b24e-12813bfff9fa; Mon, 08 Jun 2020 07:29:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591601349; s=strato-dkim-0002; d=aepfle.de; h=Message-Id:Date:Subject:Cc:To:From:X-RZG-CLASS-ID:X-RZG-AUTH:From: Subject:Sender; bh=UT9GKALVD7ZZpy+lYWU1wdLLFXK8X0l/a8iN3useVsg=; b=eE1VpybZlOKtF/ZL5fxalTwHCzDkVjg8a7/OSzIR83ctEFrjlMawGJg7Faq71E9ZO0 yUbbTuUoaK+zFU3lFKrhjvl+xdWbC0lFLN+5pxmYLDXrHRcMZoUomcnaUb3cc4VmiJ3w Xmh6aSzm13GeUoZ2hx/t5TG4ATI7AOq3De5JzOmkJtm7Fug/jqOIg6IsTdaWTg0nuQSb mS82qhttRrXNAefdMbZ4tsuOiD/dSOr8OalkViBVXdEteoLYbax76hmDcmuYpOZ2KLC6 8QUp2+ENetME2jJqiagCWMUPpNOth3zbd3J9Skv4BfEHlqPIKiEefRfR6GE7EXVKElj5 n2hw== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QXkBR9MXjAuzBW/OdlBZQ4AHSS3GpKjw==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w587SwEk4 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) (Client did not present a certificate); Mon, 8 Jun 2020 09:28:58 +0200 (CEST) From: Olaf Hering To: xen-devel@lists.xenproject.org Subject: [PATCH v1] tools: fix usage of strncpy Date: Mon, 8 Jun 2020 09:28:54 +0200 Message-Id: <20200608072855.26589-1-olaf@aepfle.de> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Olaf Hering , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In case of truncation no trailing zero will be added to the target string. Reduce the amount of bytes to copy by one to make sure a trailing zero always exists. In file included from /usr/include/string.h:495, from libxl_internal.h:38, from libxl_utils.c:20: In function 'strncpy', inlined from 'libxl__prepare_sockaddr_un' at libxl_utils.c:1262:5: /usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Olaf Hering --- gcc may not detect the off-by-one error in libxl__prepare_sockaddr_un, fix the strncpy usage anyway. tools/libvchan/vchan-socket-proxy.c | 8 ++++---- tools/libxl/libxl_utils.c | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index 13700c5d67..b312f05ca7 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -140,7 +140,7 @@ static int set_nonblocking(int fd, int nonblocking) { static int connect_socket(const char *path_or_fd) { int fd; char *endptr; - struct sockaddr_un addr; + struct sockaddr_un addr = {}; fd = strtoll(path_or_fd, &endptr, 0); if (*endptr == '\0') { @@ -153,7 +153,7 @@ static int connect_socket(const char *path_or_fd) { return -1; addr.sun_family = AF_UNIX; - strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path)); + strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path) - 1); if (connect(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) { close(fd); return -1; @@ -167,7 +167,7 @@ static int connect_socket(const char *path_or_fd) { static int listen_socket(const char *path_or_fd) { int fd; char *endptr; - struct sockaddr_un addr; + struct sockaddr_un addr = {}; fd = strtoll(path_or_fd, &endptr, 0); if (*endptr == '\0') { @@ -180,7 +180,7 @@ static int listen_socket(const char *path_or_fd) { return -1; addr.sun_family = AF_UNIX; - strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path)); + strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path) - 1); if (bind(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) { close(fd); return -1; diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index f360f5e228..83592e829d 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -1259,7 +1259,7 @@ int libxl__prepare_sockaddr_un(libxl__gc *gc, } memset(un, 0, sizeof(struct sockaddr_un)); un->sun_family = AF_UNIX; - strncpy(un->sun_path, path, sizeof(un->sun_path)); + strncpy(un->sun_path, path, sizeof(un->sun_path) - 1); return 0; } From xen-devel-bounces@lists.xenproject.org Mon Jun 08 07:29:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 07:29:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiCEC-0002Cb-Vt; Mon, 08 Jun 2020 07:29:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiCEC-0002CW-IU for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 07:29:52 +0000 X-Inumbo-ID: d6e92dd2-a959-11ea-9b55-bc764e2007e4 Received: from mail-wm1-x32b.google.com (unknown [2a00:1450:4864:20::32b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d6e92dd2-a959-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 07:29:51 +0000 (UTC) Received: by mail-wm1-x32b.google.com with SMTP id r15so15416916wmh.5 for ; Mon, 08 Jun 2020 00:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=rXS4JTeUY9K/JTTPim0861F+6JiaK2fAoudEh3BjvDw=; b=V+tlTwY9mGMWHb8OL92aFTV1SdcrVSPEAIRxfxsCZYM7fQJY67nwjopiwnpWrJ+CaV 4g2P4g3D8ysGb0iLmLz5cB5lcyuBQVXtWB99xCHFMiINog0TzL1ldufCd85Ook3MAl5T 2ubAOZk/fPx61z82mQamdsIrfQS1bBAGsWa1KgdW8tgnYQETIhvt/IVW2RKSBZxxahjF TYxeLsfGxcdRHvQYXaZKkXvix4PpVuN2KvUJXrxCbvVNJJwpqlCxC4K0VJHQ42lNuWxl 3TzKOQ4SLE5O7B987JtN3ARZnudRGd36MPxbp9v+x6OsSPnB2m6/pPl25rNGGK/fSF3s dIew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=rXS4JTeUY9K/JTTPim0861F+6JiaK2fAoudEh3BjvDw=; b=aHX8XQW2SfTmy6Ewb/8FKSrBAnRZCYjj5he0M3W6mttdJ05g6dw4V0EMng+i25b6sp IvOnCSHGPiHd8sWeLEtj9a6mOK7koquTrgFMsWOEiCyXitxXpiDNT6xZVqDFKMDwTTvI dwjcW+zIWN8LHz/s/oJZx40BtYIk+TqfedDzTzhNFr46Guv2wjfC16IktUerySw89u87 rPF3WmWn4cwChKC0dGqBnnUscUAmDgjLG0Fazv9sH6EUetX+fLQLQeYAEkMbFYYr0ACK 2Ragf1CR+dUB1n9FwsI57sX6liAaBVA4Tv66OeoTysWc7djt4epwOXmd4f333sPYxjKg u0Aw== X-Gm-Message-State: AOAM533++6hNeVdBmuq4h5D3nUA8ZF88zVQ4lbKZE7mkK5wW9T6gUCF7 Rl/VER67KRi+qHmOUMiFVsR1BE1V8ac= X-Google-Smtp-Source: ABdhPJx9y49rA700HBd9pOOBFPrqL0CbBLpEmA64sue272XbgM1vCelFSbU9I//e0MWCUBCi/YyXSA== X-Received: by 2002:a05:600c:2110:: with SMTP id u16mr14810817wml.26.1591601390723; Mon, 08 Jun 2020 00:29:50 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id b81sm23349934wmc.5.2020.06.08.00.29.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 00:29:49 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?B?J+KAjeWwj+Wkqic=?= , References: In-Reply-To: Subject: RE: xenforeignmemory fails to map PCI device memory with "Invalid Argument" error Date: Mon, 8 Jun 2020 08:29:48 +0100 Message-ID: <001b01d63d66$97f0fd80$c7d2f880$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJMiBb2MW2/R0K83Fy7lBrWOICjaKfhuzVQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = ??? > Sent: 07 June 2020 23:19 > To: xen-devel@lists.xenproject.org > Subject: xenforeignmemory fails to map PCI device memory with "Invalid = Argument" error >=20 > Hi xen-devel, >=20 > I'm trying to read HVM guest PCI memory from Dom0 using the = xenforeignmemory > library, but it's consistently failing with "Invalid Argument", no = matter > which PCI device I try. > However, if I try to map in regular (non-device) memory, it seems to = work fine. >=20 > Do you know why I can't seem to map in guest PCI memory? Am I meant to = be > mapping in the memory in some other way instead? This behaviour is not surprising... >=20 > (Background: I'm trying to port Looking Glass to Xen: > https://forum.level1techs.com/t/looking-glass-on-xen/158089) >=20 > Some example code to demonstrate the problem: >=20 > #include > #include > #include > #include > #include >=20 > void map(xenforeignmemory_handle* xfm, uint32_t dom, uintptr_t = addr) { > xen_pfn_t frame =3D addr / sysconf(_SC_PAGESIZE); > void* out =3D xenforeignmemory_map(xfm, dom, PROT_READ | > PROT_WRITE, 1, &frame, NULL); > if (!out) { > printf("Failed to map Dom%u's 0x%08lx: %m\n", dom, addr); > return; > } >=20 > printf("Dom%u 0x%08lx: 0x%08lx 0x%08lx 0x%08lx 0x%08lx\n", > dom, addr, > ((unsigned long*)out)[0], > ((unsigned long*)out)[1], > ((unsigned long*)out)[2], > ((unsigned long*)out)[3] > ); > xenforeignmemory_unmap(xfm, out, 1); > } >=20 > int main(void) { > xenforeignmemory_handle* xfm =3D xenforeignmemory_open(NULL, = 0); > if (!xfm) { > perror("xenforeignmemory_open"); > return 1; > } >=20 > // Regular memory - works fine > map(xfm, 3, 0x10000000); >=20 > // PCI device memory - errors with "Invalid Argument" > map(xfm, 3, 0xf2311000); >=20 > xenforeignmemory_close(xfm); > return 0; > } >=20 > In this case, Dom 3's 0xf2311000 belongs to the emulated SATA device: ...since, as you say here, the address belongs to an *emulated* device. = To emulate the device, BAR accesses need to be trapped and this is done = by leaving 'holes' in the guest P2M at those addresses such than = accesses cause page faults, at which point the faulting instruction can = be examined to determine the nature of the access. Paul >=20 > $ sudo xl qemu-monitor-command 3 'info pci' > ...snip... > Bus 0, device 5, function 0: > SATA controller: PCI device 8086:2922 > PCI subsystem 1af4:1100 > IRQ 0. > BAR4: I/O at 0xc260 [0xc27f]. > BAR5: 32 bit memory at 0xf2311000 [0xf2311fff]. > id "ahci0" > ...snip... From xen-devel-bounces@lists.xenproject.org Mon Jun 08 08:01:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 08:01:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiCiR-0006Di-Pw; Mon, 08 Jun 2020 08:01:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiCiQ-0006Dd-6s for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 08:01:06 +0000 X-Inumbo-ID: 32719ece-a95e-11ea-b24f-12813bfff9fa Received: from mo4-p01-ob.smtp.rzone.de (unknown [81.169.146.167]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 32719ece-a95e-11ea-b24f-12813bfff9fa; Mon, 08 Jun 2020 08:01:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591603262; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=bSjwCiDwxf/twq5csyarYSAu99LG1JqWBEtyE1q/jkg=; b=owSTsRKFnxw957baNu3iUIgP43KzpC7dq2yiuhowovmJmNhz4NzLPfwwzQl/Vrbtie ueGNp4XasZQYKBmGKPNue8xTIAMcsVaGBzex4O2A1n+gP96WhBN6oaNrbzGhUUasFbT5 C+g8Hy46o0UnndVF9EvUU4zlG69/r9Fpf9LLJAFoYPZPtpvfm1wizGzUtHjNhd3aM8M2 CyAdyaaMXta7viSlnqjrdYEjINQ60Lq5jLkXYp4TjB4ZVPzwt394H1vVnDPBR03rgcuM HeAKA2gI3RQlfAsfMrHaAZ11P86LdS/CGYBnJsRjUzm5q8bMvuXF63UEPLFm5BhT3eS6 rKzA== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w5880qEx6 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 8 Jun 2020 10:00:52 +0200 (CEST) Date: Mon, 8 Jun 2020 10:00:51 +0200 From: Olaf Hering To: xen-devel@lists.xenproject.org Subject: Re: [PATCH v1] tools: fix usage of strncpy Message-ID: <20200608100051.16be834e.olaf@aepfle.de> In-Reply-To: <20200608072855.26589-1-olaf@aepfle.de> References: <20200608072855.26589-1-olaf@aepfle.de> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/h/LRu=eyo==R_G_y0k3hjvf"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/h/LRu=eyo==R_G_y0k3hjvf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 8 Jun 2020 09:28:54 +0200 schrieb Olaf Hering : > off-by-one error in libxl__prepare_sockaddr_un There is none, I had read the code backwards... Olaf --Sig_/h/LRu=eyo==R_G_y0k3hjvf Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7d8DMACgkQ86SN7mm1 DoDIMBAAnNpxWXo20pSSHTEtL98Jc+kysWtGpPZYnRzhNlSfQ4YwXrWR0jQ8GEAM TeHOPEr/Zpcrq3LqCuNWeGN8uvVvXb1LPwo5bq5pyISU2WOuKm78bmdoZAXUzr1I Oy+HhX8XDorHh9ursnweO4/z1o5daNeZYVJSfeuoPNnEgrGULshSX/VVTgZFDfp/ 6rRcqzc8O1mWFWToLdrZ43rMv3c3oSkefaU7E91+CcKcjI7tdtM2lmzigdaOQZQ5 SDhNGOmDIs1XF95Kyt4fjgkKV7wecGOOAwQZZ1MpP+cpRo72oKbq2JHbrUuL3LQ5 CQzIJY+LIe0syo/yA8EyDfYjf0lTNqyo9hY7YOBem5TbKqI/mB38MEel6Ot8nG58 p89iGK4BOGd0cTokeWq+S/ryT4IJEBiVjGBT8sp4n8NGp8sGPdxntFyXMV6b37me I4XQp1jXRl7ZZHIuWe1aFXfI3q26TeBI54Gry4cdHn6MjhPdT/1KIkea9KPTaBlv 8QsSpimlQQVgVJOlKToPkPxmFKvfyxVDJSyT4ORGnpQRyhTovw976OxiW7ylZhc7 JOb/Wat1srIyW1NgC+mK5fNtOYWrKJ3Dt7zbDTEzdOwzAA9P/YcvHShLdX+kyj2n NyGxLDbMW1lbTXeOh88AGTJ1qf9W7aTxBVe56A03k+FIGvjlJXU= =o5jT -----END PGP SIGNATURE----- --Sig_/h/LRu=eyo==R_G_y0k3hjvf-- From xen-devel-bounces@lists.xenproject.org Mon Jun 08 08:14:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 08:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiCuw-0001Id-RK; Mon, 08 Jun 2020 08:14:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiCuw-0001IU-1w for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 08:14:02 +0000 X-Inumbo-ID: 01c2cd78-a960-11ea-9b55-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 01c2cd78-a960-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 08:14:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CCB6AB0BF; Mon, 8 Jun 2020 08:14:02 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= , paul@xen.org References: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <002001d63b3e$7c268a40$74739ec0$@xen.org> <002e01d63b4f$914b3a90$b3e1afb0$@xen.org> <20200605161804.GJ98582@mail-itl> From: Jan Beulich Message-ID: Date: Mon, 8 Jun 2020 10:13:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200605161804.GJ98582@mail-itl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 18:18, 'Marek Marczykowski-Górecki' wrote: > On Fri, Jun 05, 2020 at 04:39:56PM +0100, Paul Durrant wrote: >>> From: Jan Beulich >>> Sent: 05 June 2020 14:57 >>> >>> On 05.06.2020 15:37, Paul Durrant wrote: >>>>> From: Jan Beulich >>>>> Sent: 05 June 2020 14:32 >>>>> >>>>> On 05.06.2020 13:05, Paul Durrant wrote: >>>>>> That would mean we wouldn't be seeing the "Unexpected PIO" message. From that message this clearly >>>>> X86EMUL_UNHANDLEABLE which suggests a race with ioreq server teardown, possibly due to selecting a >>>>> server but then not finding a vcpu match in ioreq_vcpu_list. >>>>> >>>>> I was suspecting such, but at least the tearing down of all servers >>>>> happens only from relinquish-resources, which gets started only >>>>> after ->is_shut_down got set (unless the tool stack invoked >>>>> XEN_DOMCTL_destroydomain without having observed XEN_DOMINF_shutdown >>>>> set for the domain). >>>>> >>>>> For individually unregistered servers - yes, if qemu did so, this >>>>> would be a problem. They need to remain registered until all vCPU-s >>>>> in the domain got paused. >>>> >>>> It shouldn't be a problem should it? Destroying an individual server is only done with the domain >>> paused, so no vcpus can be running at the time. >>> >>> Consider the case of one getting destroyed after it has already >>> returned data, but the originating vCPU didn't consume that data >>> yet. Once that vCPU gets unpaused, handle_hvm_io_completion() >>> won't find the matching server anymore, and hence the chain >>> hvm_wait_for_io() -> hvm_io_assist() -> >>> vcpu_end_shutdown_deferral() would be skipped. handle_pio() >>> would then still correctly consume the result. >> >> True, and skipping hvm_io_assist() means the vcpu internal ioreq state will be left set to IOREQ_READY and *that* explains why we would then exit hvmemul_do_io() with X86EMUL_UNHANDLEABLE (from the first switch). > > I can confirm X86EMUL_UNHANDLEABLE indeed comes from the first switch in > hvmemul_do_io(). And it happens shortly after ioreq server is destroyed: > > (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 reason 0 > (XEN) d12v0 domain 11 domain_shutdown vcpu_id 0 defer_shutdown 1 > (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 done > (XEN) d12v0 hvm_destroy_ioreq_server called for 11, id 0 Can either of you tell why this is? As said before, qemu shouldn't start tearing down ioreq servers until the domain has made it out of all shutdown deferrals, and all its vCPU-s have been paused. For the moment I think the proposed changes, while necessary, will mask another issue elsewhere. The @releaseDomain xenstore watch, being the trigger I would consider relevant here, will trigger only once XEN_DOMINF_shutdown is reported set for a domain, which gets derived from d->is_shut_down (i.e. not mistakenly d->is_shutting_down). Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 08:30:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 08:30:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiDAf-0002wD-5T; Mon, 08 Jun 2020 08:30:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiDAd-0002w8-UY for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 08:30:15 +0000 X-Inumbo-ID: 464f0270-a962-11ea-9b55-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 464f0270-a962-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 08:30:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DE0D7ACED; Mon, 8 Jun 2020 08:30:16 +0000 (UTC) Subject: Re: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC for PVH dom0 To: Roman Shaposhnik References: <20200605110240.52545-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: <971692d4-68ab-215a-0128-72f1f6d4fbc8@suse.com> Date: Mon, 8 Jun 2020 10:30:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Xen-devel , Andrew Cooper , Wei Liu , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 06.06.2020 01:43, Roman Shaposhnik wrote: > On Fri, Jun 5, 2020 at 4:03 AM Roger Pau Monne wrote: >> >> Mediated access to the RTC was provided for PVHv1 dom0 using the PV >> code paths (guest_io_{write/read}), but those accesses where never >> implemented for PVHv2 dom0. This patch provides such mediated accesses >> to the RTC for PVH dom0, just like it's provided for a classic PV >> dom0. >> >> Pull out some of the RTC logic from guest_io_{read/write} into >> specific helpers that can be used by both PV and HVM guests. The >> setup of the handlers for PVH is done in rtc_init, which is already >> used to initialize the fully emulated RTC. >> >> Without this a Linux PVH dom0 will read garbage when trying to access >> the RTC, and one vCPU will be constantly looping in >> rtc_timer_do_work. >> >> Note that such issue doesn't happen on domUs because the ACPI >> NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing >> the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the >> accesses are not emulated but rather forwarded to the physical >> hardware. >> >> No functional change expected for classic PV dom0. > > For the dense guys like me: what is the user-visible feature that is now being > offered with this? Would really appreciate a pointer or two. PV Dom0 has always been permitted direct access to the hardware RTC. This change makes PVH Dom0 follow suit. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 08:40:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 08:40:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiDKa-0003qT-5R; Mon, 08 Jun 2020 08:40:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiDKZ-0003qO-5S for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 08:40:31 +0000 X-Inumbo-ID: b4ffba2e-a963-11ea-9b55-bc764e2007e4 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (unknown [40.107.13.41]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b4ffba2e-a963-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 08:40:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q6oH/QvHYohphmH+LEG8BW35Xiym72qUOfYXpfuc0Sg=; b=id4KVna2WqipGYHNEHuAVIyesFc+idynzKZt66IgiGsiBdYZhD8eVOz0OI6JQCYqHePYth/hjI3F92rHqFk6SVWYSjF5fS01ak1cnolDsuX88ynDmkdxSQIegPL+a6ySUG2w8w2u4ADQV0W2L4MlnGg+uKPtDHeJ2NHYWwNNpsA= Received: from DB6P191CA0010.EURP191.PROD.OUTLOOK.COM (2603:10a6:6:28::20) by HE1PR0802MB2186.eurprd08.prod.outlook.com (2603:10a6:3:c2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Mon, 8 Jun 2020 08:40:27 +0000 Received: from DB5EUR03FT064.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:28:cafe::67) by DB6P191CA0010.outlook.office365.com (2603:10a6:6:28::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 08:40:27 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT064.mail.protection.outlook.com (10.152.21.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 08:40:26 +0000 Received: ("Tessian outbound 8bb15bb571b3:v59"); Mon, 08 Jun 2020 08:40:25 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: eb059dd617992ed6 X-CR-MTA-TID: 64aa7808 Received: from b61c26d23a4b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 26FE9581-A805-4952-AE61-C9F37C883AF5.1; Mon, 08 Jun 2020 08:40:20 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b61c26d23a4b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 08 Jun 2020 08:40:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gNGywbNaYzJNnD9SNEtqugmYZSeFeuWD8A2ypbqzsDwcAxBPFMYIBYw90qxlPaO0RB9ki8WpzbWbpuzvESshzr1/tRA67kru4Url0OdbfCNFGzoK6MioaoRa+RN+AjpobW6XmLEnT8VpdUrA3v7qSwHwlPrXIq3074ZMUmdtmHVsSl8TAW9WykQ0Y/GzHphYGBzJr4P4ehRpsUb0e0ToTccOXebYiBjZXWmw78UZVB8DG0ZkP5RMQI2AJxa5tVbJVUZiVMJPlFgJgjb7rB6n6r8vUIigYNWStmJcMQZWlt2EjPTFCQTPK46UBd+3EdQ2eDc0HZBQJ31uvDC6W2rBzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q6oH/QvHYohphmH+LEG8BW35Xiym72qUOfYXpfuc0Sg=; b=aaZsVxrumIFaKPRkhaREfwrsBnsNjS7p0SlG+bcoqOqx4R9nCuyYeI8/iDj8G6Y8z3F4E/d2b4zPR60m2DwV2qaErRVKWTk1lXDC/BS+4RjsRkouqKiND7+sQdwAQrdZuDsVjQ1MvGHtg4BCjHSlrJTYNefhtIPeU8428V+MwPk4rBoUq4FboZvN0u/OEWpcE2GM0cqVLa51/1VePm/LxWxN5u1Z0LraWY6MJhBzOKWSN1Z0y6xqkOGlae451PiyTLrbXWWRy5EC1cAJfs4+kMUk77+WS1LYsUbh9Qca1BAtA+XSNH7rf8bxssvO0Ncwf13tLD7/uDqZzApozQ1tkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q6oH/QvHYohphmH+LEG8BW35Xiym72qUOfYXpfuc0Sg=; b=id4KVna2WqipGYHNEHuAVIyesFc+idynzKZt66IgiGsiBdYZhD8eVOz0OI6JQCYqHePYth/hjI3F92rHqFk6SVWYSjF5fS01ak1cnolDsuX88ynDmkdxSQIegPL+a6ySUG2w8w2u4ADQV0W2L4MlnGg+uKPtDHeJ2NHYWwNNpsA= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3097.eurprd08.prod.outlook.com (2603:10a6:5:1d::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.19; Mon, 8 Jun 2020 08:40:19 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 08:40:19 +0000 From: Bertrand Marquis To: CodeWiz2280 Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgIAAJpOAgABE7QCABAZcAA== Date: Mon, 8 Jun 2020 08:40:19 +0000 Message-ID: <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 19b34e7a-bfb7-4cd9-109b-08d80b8797c4 x-ms-traffictypediagnostic: DB7PR08MB3097:|HE1PR0802MB2186: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:5236;OLM:5236; x-forefront-prvs: 042857DBB5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: bPGJlO9jCo514WZqlqjKWaQjNc3cj6RidyNOC/DGJdK6xHk/IVAZfoHo7Nu2Yg9fiiqaezCeoOT1eK04AECgPn9HE6KH2QzBrRVGm+Ne+LBSlPbJO0JNgNW1nJCo5rzVXIHFPtviC53uufi14pH6RV/RY33zwpTYNEsdxAhQrXx8G0kcLgxEfVYFA1GWyffPuRQaAoI61UpZVF7Z36XQD+fAr8a7fv62Yc1N2jyWQiTo8AyRg8r0wok68s5ScHIq5Uph9p3rq1EBRv4U1KNqrjJHMjHS4lQKuvWSnaFs/1qK+V7PUIetw/zvglVM+KgeNWOpYak0XDPJhM5lYhJHrg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(39860400002)(346002)(136003)(366004)(478600001)(4326008)(8676002)(91956017)(8936002)(66556008)(66446008)(64756008)(76116006)(6916009)(66476007)(5660300002)(86362001)(7116003)(66946007)(6512007)(36756003)(26005)(316002)(3480700007)(2906002)(83380400001)(2616005)(71200400001)(54906003)(33656002)(186003)(53546011)(6506007)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: T357c1R+W78RDF1lMDYpNrTM4WJmH1JMOvWiYqC9yj12O7y7G9MqnlOfLCPi6ofaoXIDiN45vQwdjRTyklZr4MO9JMwqzl5QZwFHI/plfrbhxtjI5uFgBq/ra/r6XL523g4Zzg0jS9cOxdI6ZtRCpQhfzqXHPSdZx76ae4Fe3U9wywMC9axhbFbd8hicIHA+8NChJWpSXIurq0d6/juotwQ5YLHnWHfEoMZkn+7XqHaDXCzuGb9xRvF0gIvRvGOUiaBG//NPe8GdZWuAe4q4LyJ+GFp33et9MoLNjdD2UFlqfkyBZwwuJPDR7rGd4E2wuyXj8t5vugwPEPC4O5V/Z5Za6k9uxTVUfcQwDe5NNXm/VxYhfqMda0IlXpHIZ9xHP9aZu+9DXkGkyJwSDCh9WHlTlFT0VhCzPZuEfkrTJ/P/0Uaw7ryu2BvD00KD0WS529hodGz3VvYlfR53vEMqB5OjD1ZalvsChg74leEDzOs= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <2EC637D63A78AB4A8797A4F5BE462C08@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3097 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT064.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(136003)(376002)(46966005)(6486002)(2906002)(186003)(26005)(8936002)(86362001)(82310400002)(53546011)(83380400001)(478600001)(82740400003)(3480700007)(6512007)(6506007)(54906003)(81166007)(356005)(4326008)(47076004)(5660300002)(316002)(7116003)(70586007)(36756003)(336012)(33656002)(6862004)(8676002)(70206006)(2616005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 54a4b105-672f-4574-4f8e-08d80b879352 X-Forefront-PRVS: 042857DBB5 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gX0X5YINgY+bNbu+BEPjVe6WBdmuH2MeYT36SBVIYtoOYI4nZkNqtT/oQYe2m9WlAi6rJ92FDIa563bFOFbv7TQYe4KCaDdF7gIHedBuIY8TfkaJoAcctCTxdC+epazboyOtPP+DJBgC0TAAt4VuLV4uVgB/fPnxvVrKKVoR8Z7jR/bnyIEWFg/XSUQ4s/HyD4Uy0DKxUQ7H4DuLuP/6TK+4WUzhBvFVpCxSqxFLQai/KVM1uZLdiyWK7Ptz4T8ISxQkvYHHHdMb3I6JAE4M2/kfHIsUF+ANvRygqm1eJ/SDi/5Cx1Uki3b64WZgdePR3lMvpFm0TVmzrWD3Gf4xKkmZChTyyyLscKCg577ZyPWvBtxT2zY+FFnp0KIKB7UiTQ1iiCbLjnRkdVy/sXOWAg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2020 08:40:26.7554 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 19b34e7a-bfb7-4cd9-109b-08d80b8797c4 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2186 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On 5 Jun 2020, at 20:12, CodeWiz2280 wrote: >=20 > On Fri, Jun 5, 2020 at 11:05 AM CodeWiz2280 wrote= : >>=20 >> On Fri, Jun 5, 2020 at 8:47 AM Bertrand Marquis >> wrote: >>>=20 >>>=20 >>>=20 >>>> On 5 Jun 2020, at 13:42, CodeWiz2280 wrote: >>>>=20 >>>> On Fri, Jun 5, 2020 at 8:30 AM Julien Grall wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> On 05/06/2020 13:25, CodeWiz2280 wrote: >>>>>> The Keystone uses the netcp driver, which has interrupts from 40-79 >>>>>> listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). >>>>>> I'm using the same device tree between my non-xen standalone kernel >>>>>> and my dom0 kernel booted by xen. In the standalone (non-xen) kerne= l >>>>>> the ethernet works fine, but I don't see any of its interrupts in th= e >>>>>> output of /proc/iomem. I'm not seeing them in /proc/iomem when >>>>>> running dom0 under Xen either. When booting with Xen I get this >>>>>> behavior where the ifconfig output shows 1 RX message and 1 TX >>>>>> message, and then nothing else. >>>>>=20 >>>>> I am not sure whether this is a typo in the e-mail. /proc/iomem is >>>>> listing the list of the MMIO regions. You want to use /proc/interrupt= s. >>>>>=20 >>>>> Can you confirm which path you are dumping? >>>> Yes, that was a typo. Sorry about that. I meant that I am dumping >>>> /proc/interrupts and do not >>>> see them under the non-xen kernel or xen booted dom0. >>>=20 >>> Could you post both /proc/interrupts content ? >>=20 >> Standalone non-xen kernel (Ethernet works) >> # cat /proc/interrupts >> CPU0 CPU1 CPU2 CPU3 >> 17: 0 0 0 0 GICv2 29 Level >> arch_timer >> 18: 9856 1202 457 650 GICv2 30 Level >> arch_timer >> 21: 0 0 0 0 GICv2 142 Edge >> timer-keystone >> 22: 0 0 0 0 GICv2 52 Edge = arm-pmu >> 23: 0 0 0 0 GICv2 53 Edge = arm-pmu >> 24: 0 0 0 0 GICv2 54 Edge = arm-pmu >> 25: 0 0 0 0 GICv2 55 Edge = arm-pmu >> 26: 0 0 0 0 GICv2 36 Edge >> 26202a0.keystone_irq >> 27: 1435 0 0 0 GICv2 309 Edge = ttyS0 >> 29: 0 0 0 0 GICv2 315 Edge >> 2530000.i2c >> 30: 1 0 0 0 GICv2 318 Edge >> 2530400.i2c >> 31: 0 0 0 0 GICv2 321 Edge >> 2530800.i2c >> 32: 69 0 0 0 GICv2 324 Edge >> 21000400.spi >> 33: 0 0 0 0 GICv2 328 Edge >> 21000600.spi >> 34: 0 0 0 0 GICv2 332 Edge >> 21000800.spi >> 70: 0 0 0 0 GICv2 417 Edge >> ks-pcie-error-irq >> 79: 0 0 0 0 PCI-MSI 0 Edge >> PCIe PME, aerdrv >> 88: 57 0 0 0 GICv2 80 Level >> hwqueue-528 >> 89: 57 0 0 0 GICv2 81 Level >> hwqueue-529 >> 90: 47 0 0 0 GICv2 82 Level >> hwqueue-530 >> 91: 41 0 0 0 GICv2 83 Level >> hwqueue-531 >> IPI0: 0 0 0 0 CPU wakeup interrupts >> IPI1: 0 0 0 0 Timer broadcast inter= rupts >> IPI2: 730 988 1058 937 Rescheduling interrup= ts >> IPI3: 2 3 4 6 Function call interru= pts >> IPI4: 0 0 0 0 CPU stop interrupts >> IPI5: 0 0 0 0 IRQ work interrupts >> IPI6: 0 0 0 0 completion interrupts >>=20 >> Xen dom0 (Ethernet stops) >> # cat /proc/interrupts >> CPU0 >> 18: 10380 GIC-0 27 Level arch_timer >> 19: 0 GIC-0 142 Edge timer-keystone >> 20: 88 GIC-0 16 Level events >> 21: 0 xen-dyn Edge -event xenbus >> 22: 0 GIC-0 36 Edge 26202a0.keystone_irq >> 23: 1 GIC-0 312 Edge ttyS0 >> 25: 1 GIC-0 318 Edge >> 27: 1 GIC-0 324 Edge 21000400.spi >> 28: 0 GIC-0 328 Edge 21000600.spi >> 29: 0 GIC-0 332 Edge 21000800.spi >> 65: 0 GIC-0 417 Edge ks-pcie-error-irq >> 74: 0 PCI-MSI 0 Edge PCIe PME, aerdrv >> 83: 1 GIC-0 80 Level hwqueue-528 >> 84: 1 GIC-0 81 Level hwqueue-529 >> 85: 1 GIC-0 82 Level hwqueue-530 >> 86: 1 GIC-0 83 Level hwqueue-531 >> 115: 87 xen-dyn Edge -virq hvc_console >> IPI0: 0 CPU wakeup interrupts >> IPI1: 0 Timer broadcast interrupts >> IPI2: 0 Rescheduling interrupts >> IPI3: 0 Function call interrupts >> IPI4: 0 CPU stop interrupts >> IPI5: 0 IRQ work interrupts >> IPI6: 0 completion interrupts >> Err: 0 > After getting a chance to look at this a little more, I believe the > TX/RX interrupts for the ethernets map like this: >=20 > eth0 Rx - hwqueue-528 > eth1 Rx - hwqueue-529 > eth0 Tx - hwqueue-530 > eth1 Tx - hwqueue-531 >>=20 > The interrupt counts in the standlone working kernel seem to roughly > correspond to the counts of Tx/Rx messages in ifconfig. Going on > that, its clear that only 1 interrupt has been received for Tx and 1 > for Rx in the Xen Dom0 equivalent. Any thoughts on this? This definitely look like an interrupt acknowledgement issue. This could be caused by 2 things I remember of: - front vs level interrupts - a problem with forwarded interrupt acknowledgement.=20 I think there was something related to that where the vcpu ack was not prop= erly handled on a keystone and I had to change the way the interrupt was acked f= or forwarded hardware interrupts. I will try to get more info on that one as I have no access to the code any= more. Regards Bertrand From xen-devel-bounces@lists.xenproject.org Mon Jun 08 08:51:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 08:51:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiDV8-0004mp-9B; Mon, 08 Jun 2020 08:51:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiDV6-0004mk-Jj for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 08:51:24 +0000 X-Inumbo-ID: 39420d54-a965-11ea-9b55-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 39420d54-a965-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 08:51:21 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: WkzJplbcHVLuGXCyzD+krEYJAgBiqjevj8lTqBRu6DKpR+wObQr3i/rNtwTi8CJuDtdA0yfGdI SSFxwAVgoXXLMZsuYtoeRaoPwdknN3oVpFNTJTEQaodLlD+SxGt2sbqrAgOHD7RPtg7cbpzmt2 IBDABhFCRMW6SdJyUGMhPHXh93jkAU6qrE8vEruZoBHwWAYy1vTyd+J+P8BYKJtp34ybQnoVyF x2l+wAPiPYrFCYpJp8ZK8MMoJRzU2sjt42TvWbdD2Imdgp33qlB1vKoExhoEOj3EdVjf+AB7k7 71U= X-SBRS: 2.7 X-MesageID: 19697928 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19697928" Date: Mon, 8 Jun 2020 10:51:10 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Roman Shaposhnik Subject: Re: [PATCH for-4.14 v2] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200608085110.GD660@Air-de-Roger> References: <20200605110240.52545-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Jan Beulich , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 04:43:12PM -0700, Roman Shaposhnik wrote: > On Fri, Jun 5, 2020 at 4:03 AM Roger Pau Monne wrote: > > > > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > > code paths (guest_io_{write/read}), but those accesses where never > > implemented for PVHv2 dom0. This patch provides such mediated accesses > > to the RTC for PVH dom0, just like it's provided for a classic PV > > dom0. > > > > Pull out some of the RTC logic from guest_io_{read/write} into > > specific helpers that can be used by both PV and HVM guests. The > > setup of the handlers for PVH is done in rtc_init, which is already > > used to initialize the fully emulated RTC. > > > > Without this a Linux PVH dom0 will read garbage when trying to access > > the RTC, and one vCPU will be constantly looping in > > rtc_timer_do_work. > > > > Note that such issue doesn't happen on domUs because the ACPI > > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > > accesses are not emulated but rather forwarded to the physical > > hardware. > > > > No functional change expected for classic PV dom0. > > For the dense guys like me: what is the user-visible feature that is now being > offered with this? Would really appreciate a pointer or two. Without this dom0 is not able to change the date. Note that XENPF_settime{32/64} doesn't write the changes to the RTC (at least on x86), so dom0 needs to write such changes to the RTC so they can survive a poweroff. However dom0 cannot be given direct access to the registers, since the RTC uses an indirect access interface using two IO registers, so Xen needs to trap such accesses by dom0 in order to serialize them and prevent conflicts with Xen accesses to the RTC. Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 09:16:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 09:16:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiDsi-0006dJ-7q; Mon, 08 Jun 2020 09:15:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiDsh-0006dE-3I for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 09:15:47 +0000 X-Inumbo-ID: a28d304c-a968-11ea-9b55-bc764e2007e4 Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a28d304c-a968-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 09:15:46 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id l11so16561539wru.0 for ; Mon, 08 Jun 2020 02:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=t0yGidRJi7/PMf3lJefQZDlXr8CiQRn2DBjcPbG5Uz8=; b=U64EY8SKDU0M564SnMzFq8+T7uSBdQEMiDHTUxNiFdlfJTQ9aQOL8tFQHtMsALNjsH FuFi/tLQ+j7eGQH1LDSgwe4iVnRbdgXzzhnt8ZdOZ74pZX+IFsrSidAa2nOllXrDULiq OZNtFVjEiQCtBcRD2RhgjgQM5Om6CVQqig2sIfIbJhUqy1Eva/QzCxl+d8PUeGszFg+X rrK/HW5go6yqjSq0qRko9lfxBEU1DHl60x1GQcVs2jobFB5IQ/5Zs/LRHhxrNzCKG9lm uVzMR9/bBzJVh1Lj9gsLcSFUjYM2CFcSpbwVKJsm1sFvc4Wgn/BfBB45UECp73lCcLcL 4lVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=t0yGidRJi7/PMf3lJefQZDlXr8CiQRn2DBjcPbG5Uz8=; b=Z3zBJKcwR3fqjRwVPQ4r/dqH1GDoPHvbF0CCk/p87oHdN9L8oYaGrTNzjYpQKDk5uG UuNY6tzp70r177dzdYwfhWA/zBOdPbtK13ckijLjz2ip0l6lps5qAT7TJevJhrRj1Znh UMc0wrtY63dN73zGtyRKeuGJHvz8TasVy2R42c4pA/U/5riszYq8zpbBnI9uL6kg8NsU oXUfEbLZRZX1GU8LUOg+vmAKkbnFctmvFAQWD4nlIq+TbyNsSpW4p1avljKYaWktsDRk KotKe7dw69IlgCl81llp1Uu0UbyQH32iHm9xk5NvgDeddmnO58rkWbRHwHsDsJ4sDwyQ 33tw== X-Gm-Message-State: AOAM532HtuYddCncstks4ZKfqi2SBacKbLAnTjEYfuFA1YQWZJN6jIVB HGCL31yaO0XlfFgxIhmCPyI= X-Google-Smtp-Source: ABdhPJwJqWLBywfxEES/B2CSTA6qmuaT2CDgLb/Uj11bGStuMlWi2wUvHInWgB7D7rqP2R9CvYD2vw== X-Received: by 2002:a05:6000:100e:: with SMTP id a14mr22184134wrx.349.1591607745252; Mon, 08 Jun 2020 02:15:45 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id p1sm22082382wrx.44.2020.06.08.02.15.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 02:15:44 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , =?utf-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= , "'Ian Jackson'" References: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <002001d63b3e$7c268a40$74739ec0$@xen.org> <002e01d63b4f$914b3a90$b3e1afb0$@xen.org> <20200605161804.GJ98582@mail-itl> In-Reply-To: Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Mon, 8 Jun 2020 10:15:42 +0100 Message-ID: <002701d63d75$6363a130$2a2ae390$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQCJ30jDNcpaWIG0GDXmJ4sF0URUNgF7hKHXArBYEOQB4r0ScAFGccUAApWxmk4BPtBDbAHi/U0vAkOVa4cCoqFkNAIjoGbrAeOG1z+qt1tb0A== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 08 June 2020 09:14 > To: 'Marek Marczykowski-G=C3=B3recki' = ; paul@xen.org > Cc: 'Andrew Cooper' ; 'xen-devel' = > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On 05.06.2020 18:18, 'Marek Marczykowski-G=C3=B3recki' wrote: > > On Fri, Jun 05, 2020 at 04:39:56PM +0100, Paul Durrant wrote: > >>> From: Jan Beulich > >>> Sent: 05 June 2020 14:57 > >>> > >>> On 05.06.2020 15:37, Paul Durrant wrote: > >>>>> From: Jan Beulich > >>>>> Sent: 05 June 2020 14:32 > >>>>> > >>>>> On 05.06.2020 13:05, Paul Durrant wrote: > >>>>>> That would mean we wouldn't be seeing the "Unexpected PIO" = message. From that message this > clearly > >>>>> X86EMUL_UNHANDLEABLE which suggests a race with ioreq server = teardown, possibly due to selecting > a > >>>>> server but then not finding a vcpu match in ioreq_vcpu_list. > >>>>> > >>>>> I was suspecting such, but at least the tearing down of all = servers > >>>>> happens only from relinquish-resources, which gets started only > >>>>> after ->is_shut_down got set (unless the tool stack invoked > >>>>> XEN_DOMCTL_destroydomain without having observed = XEN_DOMINF_shutdown > >>>>> set for the domain). > >>>>> > >>>>> For individually unregistered servers - yes, if qemu did so, = this > >>>>> would be a problem. They need to remain registered until all = vCPU-s > >>>>> in the domain got paused. > >>>> > >>>> It shouldn't be a problem should it? Destroying an individual = server is only done with the domain > >>> paused, so no vcpus can be running at the time. > >>> > >>> Consider the case of one getting destroyed after it has already > >>> returned data, but the originating vCPU didn't consume that data > >>> yet. Once that vCPU gets unpaused, handle_hvm_io_completion() > >>> won't find the matching server anymore, and hence the chain > >>> hvm_wait_for_io() -> hvm_io_assist() -> > >>> vcpu_end_shutdown_deferral() would be skipped. handle_pio() > >>> would then still correctly consume the result. > >> > >> True, and skipping hvm_io_assist() means the vcpu internal ioreq = state will be left set to > IOREQ_READY and *that* explains why we would then exit hvmemul_do_io() = with X86EMUL_UNHANDLEABLE (from > the first switch). > > > > I can confirm X86EMUL_UNHANDLEABLE indeed comes from the first = switch in > > hvmemul_do_io(). And it happens shortly after ioreq server is = destroyed: > > > > (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 reason 0 > > (XEN) d12v0 domain 11 domain_shutdown vcpu_id 0 defer_shutdown 1 > > (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 done > > (XEN) d12v0 hvm_destroy_ioreq_server called for 11, id 0 >=20 > Can either of you tell why this is? As said before, qemu shouldn't > start tearing down ioreq servers until the domain has made it out > of all shutdown deferrals, and all its vCPU-s have been paused. > For the moment I think the proposed changes, while necessary, will > mask another issue elsewhere. The @releaseDomain xenstore watch, > being the trigger I would consider relevant here, will trigger > only once XEN_DOMINF_shutdown is reported set for a domain, which > gets derived from d->is_shut_down (i.e. not mistakenly > d->is_shutting_down). I can't find anything that actually calls xendevicemodel_shutdown(). It = was added by: commit 1462f9ea8f4219d520a530787b80c986e050aa98 Author: Ian Jackson Date: Fri Sep 15 17:21:14 2017 +0100 tools: libxendevicemodel: Provide xendevicemodel_shutdown Signed-off-by: Ian Jackson Acked-by: Wei Liu Perhaps Ian can shed more light on it? Paul >=20 > Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 09:25:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 09:25:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiE1i-0007WI-28; Mon, 08 Jun 2020 09:25:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiE1f-0007WD-Tj for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 09:25:03 +0000 X-Inumbo-ID: edf8ebc4-a969-11ea-96fb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id edf8ebc4-a969-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 09:25:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A1682AE67; Mon, 8 Jun 2020 09:25:04 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: paul@xen.org, 'Jan Beulich' , =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= , 'Ian Jackson' References: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <002001d63b3e$7c268a40$74739ec0$@xen.org> <002e01d63b4f$914b3a90$b3e1afb0$@xen.org> <20200605161804.GJ98582@mail-itl> <002701d63d75$6363a130$2a2ae390$@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <3811b700-7bd7-859a-2c84-a9885acf64a1@suse.com> Date: Mon, 8 Jun 2020 11:24:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <002701d63d75$6363a130$2a2ae390$@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Andrew Cooper' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.20 11:15, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 08 June 2020 09:14 >> To: 'Marek Marczykowski-Górecki' ; paul@xen.org >> Cc: 'Andrew Cooper' ; 'xen-devel' >> Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom >> >> On 05.06.2020 18:18, 'Marek Marczykowski-Górecki' wrote: >>> On Fri, Jun 05, 2020 at 04:39:56PM +0100, Paul Durrant wrote: >>>>> From: Jan Beulich >>>>> Sent: 05 June 2020 14:57 >>>>> >>>>> On 05.06.2020 15:37, Paul Durrant wrote: >>>>>>> From: Jan Beulich >>>>>>> Sent: 05 June 2020 14:32 >>>>>>> >>>>>>> On 05.06.2020 13:05, Paul Durrant wrote: >>>>>>>> That would mean we wouldn't be seeing the "Unexpected PIO" message. From that message this >> clearly >>>>>>> X86EMUL_UNHANDLEABLE which suggests a race with ioreq server teardown, possibly due to selecting >> a >>>>>>> server but then not finding a vcpu match in ioreq_vcpu_list. >>>>>>> >>>>>>> I was suspecting such, but at least the tearing down of all servers >>>>>>> happens only from relinquish-resources, which gets started only >>>>>>> after ->is_shut_down got set (unless the tool stack invoked >>>>>>> XEN_DOMCTL_destroydomain without having observed XEN_DOMINF_shutdown >>>>>>> set for the domain). >>>>>>> >>>>>>> For individually unregistered servers - yes, if qemu did so, this >>>>>>> would be a problem. They need to remain registered until all vCPU-s >>>>>>> in the domain got paused. >>>>>> >>>>>> It shouldn't be a problem should it? Destroying an individual server is only done with the domain >>>>> paused, so no vcpus can be running at the time. >>>>> >>>>> Consider the case of one getting destroyed after it has already >>>>> returned data, but the originating vCPU didn't consume that data >>>>> yet. Once that vCPU gets unpaused, handle_hvm_io_completion() >>>>> won't find the matching server anymore, and hence the chain >>>>> hvm_wait_for_io() -> hvm_io_assist() -> >>>>> vcpu_end_shutdown_deferral() would be skipped. handle_pio() >>>>> would then still correctly consume the result. >>>> >>>> True, and skipping hvm_io_assist() means the vcpu internal ioreq state will be left set to >> IOREQ_READY and *that* explains why we would then exit hvmemul_do_io() with X86EMUL_UNHANDLEABLE (from >> the first switch). >>> >>> I can confirm X86EMUL_UNHANDLEABLE indeed comes from the first switch in >>> hvmemul_do_io(). And it happens shortly after ioreq server is destroyed: >>> >>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 reason 0 >>> (XEN) d12v0 domain 11 domain_shutdown vcpu_id 0 defer_shutdown 1 >>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 done >>> (XEN) d12v0 hvm_destroy_ioreq_server called for 11, id 0 >> >> Can either of you tell why this is? As said before, qemu shouldn't >> start tearing down ioreq servers until the domain has made it out >> of all shutdown deferrals, and all its vCPU-s have been paused. >> For the moment I think the proposed changes, while necessary, will >> mask another issue elsewhere. The @releaseDomain xenstore watch, >> being the trigger I would consider relevant here, will trigger >> only once XEN_DOMINF_shutdown is reported set for a domain, which >> gets derived from d->is_shut_down (i.e. not mistakenly >> d->is_shutting_down). > > I can't find anything that actually calls xendevicemodel_shutdown(). It was added by: destroy_hvm_domain() in qemu does. Juergen From xen-devel-bounces@lists.xenproject.org Mon Jun 08 09:46:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 09:46:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiEML-0000oo-Rq; Mon, 08 Jun 2020 09:46:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiEMK-0000oj-Lr for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 09:46:24 +0000 X-Inumbo-ID: ea075dea-a96c-11ea-ba62-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ea075dea-a96c-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 09:46:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version: Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ld9XxbJQbqjIS+vT5vM4ejftqmMQqf5yzJIBL3/b5XM=; b=Hq6u7DFac5Vhq7LUGGDBfgUhdq q3fTmHw9A2sWQ8bVETriBrjcZ8IR2iGFE4krRF1s3WXkDv0QuL0LdygF3DXbcZHhOfthtcWEF9w5B 4OJAxKgEztpVDrjjslEOcgCYvhq1KqswqdC1+/PGzn3OvJ+P0gqIf18BeRlHPRnidKvo=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiEMJ-0002L8-BL; Mon, 08 Jun 2020 09:46:23 +0000 Received: from 54-240-197-224.amazon.com ([54.240.197.224] helo=u2f063a87eabd5f.cbg10.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jiEMJ-0005vc-29; Mon, 08 Jun 2020 09:46:23 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction Date: Mon, 8 Jun 2020 10:46:19 +0100 Message-Id: <20200608094619.28336-1-paul@xen.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Paul Durrant When an emulation request is initiated in hvm_send_ioreq() the guest vcpu is blocked on an event channel until that request is completed. If, however, the emulator is killed whilst that emulation is pending then the ioreq server may be destroyed. Thus when the vcpu is awoken the code in handle_hvm_io_completion() will find no pending request to wait for, but will leave the internal vcpu io_req.state set to IOREQ_READY and the vcpu shutdown deferall flag in place (because hvm_io_assist() will never be called). The emulation request is then completed anyway. This means that any subsequent call to hvmemul_do_io() will find an unexpected value in io_req.state and will return X86EMUL_UNHANDLEABLE, which in some cases will result in continuous re-tries. This patch fixes the issue by moving the setting of io_req.state and clearing of shutdown deferral (as will as MSI-X write completion) out of hvm_io_assist() and directly into handle_hvm_io_completion(). Reported-by: Marek Marczykowski-Górecki Signed-off-by: Paul Durrant --- This should be incorporated into 4.14 and also be backported to stable releases --- xen/arch/x86/hvm/ioreq.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c index c55c4bc4bc..724007016d 100644 --- a/xen/arch/x86/hvm/ioreq.c +++ b/xen/arch/x86/hvm/ioreq.c @@ -109,15 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data) ioreq_t *ioreq = &v->arch.hvm.hvm_io.io_req; if ( hvm_ioreq_needs_completion(ioreq) ) - { - ioreq->state = STATE_IORESP_READY; ioreq->data = data; - } - else - ioreq->state = STATE_IOREQ_NONE; - - msix_write_completion(v); - vcpu_end_shutdown_deferral(v); sv->pending = false; } @@ -209,6 +201,12 @@ bool handle_hvm_io_completion(struct vcpu *v) } } + vio->io_req.state = hvm_ioreq_needs_completion(&vio->io_req) ? + STATE_IORESP_READY : STATE_IOREQ_NONE; + + msix_write_completion(v); + vcpu_end_shutdown_deferral(v); + io_completion = vio->io_completion; vio->io_completion = HVMIO_no_completion; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 09:54:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 09:54:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiETz-0001ga-LJ; Mon, 08 Jun 2020 09:54:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiETy-0001gV-Br for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 09:54:18 +0000 X-Inumbo-ID: 040945f4-a96e-11ea-b258-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 040945f4-a96e-11ea-b258-12813bfff9fa; Mon, 08 Jun 2020 09:54:17 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: uciO5fGTX5/SSRaOQx6k1Ix5gzIBEzqMApsUZKz8y9iEr8T6UhYnhg6+DiAU9IMdy7irlH3r9R P1AMDtUHe/hs/e0LtOu4c6aUm2RyHHiRAIUg/cOL7WBIrnAU2YMCb0Tgr+jJsXMIpWKV7ZDeR4 TJU+PC0Slo0fqxKSXqTM9ryu+0XGT3TjrNXjzX/xtwFY1x2yLUSPoQJC1cV+X7b6VtK2qnw7+N lrc+0NCN9qmeL5YgIgJ9UKE7B2iuTHbOdKNH8owvLoe8+PlsR6Uh+1V3GhU1ZGQ2OK93RDjBWa llE= X-SBRS: 2.7 X-MesageID: 19456475 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19456475" From: George Dunlap To: Nick Rosbrook Subject: Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile Thread-Topic: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile Thread-Index: AQHWM6tS08XNp9FsPk2dfrAVrD4GiajIlOUAgAAecgCABblSgA== Date: Mon, 8 Jun 2020 09:54:13 +0000 Message-ID: References: <20200526221612.900922-1-george.dunlap@citrix.com> <20200526221612.900922-2-george.dunlap@citrix.com> <5CF4AE1D-C80C-4E4C-B4AA-0779E7DC53E7@citrix.com> <20200604182938.GA10975@six> In-Reply-To: <20200604182938.GA10975@six> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <26E84A4320E9F04FAB830579F9FF7872@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , xen-devel , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gSnVuIDQsIDIwMjAsIGF0IDc6MjkgUE0sIE5pY2sgUm9zYnJvb2sgPHJvc2Jyb29r bkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4+IFRoZSBzaW1wbGVzdCBzaG9ydC10ZXJtIHdheSB0 byBmaXggdGhpcyB3b3VsZCBiZSB0byByZW1vdmUgdGhlIGBnbyBmbXRgIGNhbGwgZnJvbSBgZ2Vu Z290eXBlcy5weWAuICBJdOKAmXMgYWN0dWFsbHkgcmVsYXRpdmVseSB1bnVzdWFsIGZvciBnZW5l cmF0ZWQgY29kZSB0byBsb29rIHByZXR0eSAob3IgZXZlbiBiZSBsb29rZWQgYXQpLiAgV2UgY291 bGQgYWxzbyBjb25zaWRlciBhZGRpbmcgaW4gc29tZSDigJxtYW51YWzigJ0gZm9ybWF0dGluZyBp biBnZW5nb3R5cGVzLnB5LCBsaWtlIGluZGVudGF0aW9uLCBzbyB0aGF0IGl0IGRvZXNu4oCZdCBs b29rIHRvbyB0ZXJyaWJsZS4NCj4+IA0KPj4gTmljaywgZG8geW91IGhhdmUgdGltZSB0byB3b3Jr IG9uIGEgcGF0Y2ggbGlrZSB0aGF0Pw0KPiANCj4gWWVzLCBJIGhhdmUgdGltZSB0byB3b3JrIG9u IGEgcXVpY2sgcGF0Y2ggZm9yIHRoaXMuIEknbGwgc2VlIHdoYXQgaXQNCj4gd291bGQgdGFrZSB0 byBhZGQgYSBiaXQgb2YgYmFzaWMgbWFudWFsIGZvcm1hdHRpbmcsIGJ1dCBvZiBjb3Vyc2UgdGhl DQo+IG9yaWdpbmFsIHB1cnBvc2Ugb2YgdXNpbmcgZ29mbXQgd2FzIHRvIGF2b2lkIHJlLWNyZWF0 aW5nIGZvcm1hdHRpbmcNCj4gbG9naWMuIEknbGwgbGlrZWx5IGp1c3QgcmVtb3ZlIHRoZSBjYWxs IHRvIGdvIGZtdC4NCj4gDQo+IE91dCBvZiBjdXJpb3NpdHksIHdvdWxkIGl0IGJlIHRvdGFsbHkg b3V0IG9mIHRoZSBxdWVzdGlvbiB0byByZXF1aXJlDQo+IGhhdmluZyBnb2ZtdCBpbnN0YWxsZWQg KG5vdCBmb3IgNC4xNCwgYnV0IGluIHRoZSBmdXR1cmUpPyBJIGFzayBiZWNhdXNlDQo+IEkgaGF2 ZW4ndCBzZWVuIGl0IGRpc2N1c3NlZCBvbmUgd2F5IG9yIHRoZSBvdGhlci4NCg0KSSB0aGluayBJ 4oCZZCBsaWtlIHRvIHRyeSB0byBhdm9pZCBpdCwgdW5sZXNzIC8gdW50aWwgd2UgaGF2ZSBhIOKA nGNvcmUgY29tcG9uZW504oCdIHdyaXR0ZW4gaW4gZ29sYW5nLiAgRm9yIG9uZSwgaWYgd2UgYWRk ZWQgaXQgYXMgYSBjb3JlIGRlcGVuZGVuY3ksIHdl4oCZZCBuZWVkIHRvIGJlICBiYWNrd2FyZHMg Y29tcGF0aWJsZSB0byB0aGUgb2xkZXN0IHZlcnNpb24gb2YgZ29sYW5nIG9mIGRpc3Ryb3Mgb24g d2hpY2ggd2Ugd2FudCB0byBidWlsZDsgdGhhdCB3b3VsZCBpbmNsdWRlICBEZWJpYW4gb2xkc3Rh YmxlLCBVYnVudHUgTFRTLCBwcm9iYWJseSBDZW50T1MgNyBhdCBsZWFzdCwgcG9zc2libHkgQ2Vu dE9TIDYsIGFuZCBzbyBvbi4gIElmIGFueSBvZiB0aG9zZSBkaWRu4oCZdCBoYXZlIGdvbGFuZyBh dmFpbGFibGUsIHRoZW4gd2XigJlkIGJhc2ljYWxseSBoYXZlIHRvIGRlY2lkZSBiZXR3ZWVuIGRy b3BwaW5nIHN1cHBvcnQgZm9yIHRob3NlIGRpc3Ryb3MsIGFuZCBtYWtpbmcgZ29sYW5nIG9wdGlv bmFsLg0KDQpJIGRvbuKAmXQgYXQgdGhlIG1vbWVudCBoYXZlIGEgZ29vZCBmZWVsIGZvciB3aGF0 IG90aGVyIHBlb3BsZSBpbiB0aGUgY29tbXVuaXR5IGZlZWwgYWJvdXQgdGhpcywgYnV0IGdlbmVy YWxseSBzcGVha2luZyBiZWluZyBmYW5hdGljYWxseSBiYWNrd2FyZHMgY29tcGF0aWJsZSBpcyBh biBpbnZlc3RtZW50IGluIHRoZSBsb25nLXRlcm0gZWNvc3lzdGVtOyBrZWVwaW5nIFhlbiAqYXMg YSB3aG9sZSogYnVpbGRpbmcgb24gb2xkZXIgZGlzdHJvcyBpcyBhbiBleGFtcGxlIG9mIHRoYXQu ICAoRldJVyBJIGRvbuKAmXQgdGhpbmsgd2UgaGF2ZSBhbiBvZmZpY2lhbCBydWJyaWMsIGJ1dCBt eSBzdGFydGluZyBwb2ludCBpcyB0aGF0IHdlIHNob3VsZCB0cnkgdG8gYnVpbGQgb24gYWxsIHN0 aWxsLXN1cHBvcnRlZCBtYWpvciBkaXN0cm9zOyB0aGF0IHdvdWxkIGluY2x1ZGUgQ2VudE9TIDYg dW50aWwgUTQgb2YgMjAyMCwgaWYgbXkgcXVpY2sgR29vZ2xlIHNlYXJjaCBpcyBjb3JyZWN0LikN Cg0KT25lIGFkdmFudGFnZSBvZiBtYWtpbmcgZ29sYW5nIG9wdGlvbmFsIGlzIHRoYXQgd2UgZG9u 4oCZdCBoYXZlIHRvIGJlIHF1aXRlIHNvIGJhY2t3YXJkcyBjb21wYXRpYmxlIOKAlCB1cCB1bnRp bCB3ZSBkZWNsYXJlIHRoZSBmZWF0dXJlIOKAnGZ1bGx5IHN1cHBvcnRlZOKAnSwgd2UgY2FuIG1v dmUgdGhlIG1pbmltdW0gcmVxdWlyZWQgdmVyc2lvbiBmb3J3YXJkIGF0IHdpbGwgaWYgd2Ugd2Fu dCB0byByZWx5IG9uIG5ldyBmZWF0dXJlcy4NCg0KIC1HZW9yZ2U= From xen-devel-bounces@lists.xenproject.org Mon Jun 08 10:30:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 10:30:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiF2t-0004zk-GG; Mon, 08 Jun 2020 10:30:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiF2s-0004zf-25 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 10:30:22 +0000 X-Inumbo-ID: 0d9f1bc0-a973-11ea-96fb-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0d9f1bc0-a973-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 10:30:20 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: GvIRNCURFQ+phJ0LSwBuruJ0qTKTHTeoKt/3/EVZ/6sSyME3Z1VTOGCPEvGW0NCePate2q5DQN DRCV/+ryv7St/D0CiS15P2rWW59m7puF8lHICMGhbc0Q93DMarukEFfFJzc45Y1ZW68mB+2Yib xEZaO3VANzkT6ySKZSDgwj8Ipnnyyj9/Y60heTJX1uAcg3ojvLafY5R9EGppFMC2ZWpx8bYmEh BG3/V6jAOAc7VSlSR/gSrwVCBVaPl7QTThaA+J98SnAnym/y8unkNzge6gGLvMXqWYebpQJpQz Hvk= X-SBRS: 2.7 X-MesageID: 19809241 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19809241" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v3] x86/rtc: provide mediated access to RTC for PVH dom0 Date: Mon, 8 Jun 2020 12:29:48 +0200 Message-ID: <20200608102948.7327-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Mediated access to the RTC was provided for PVHv1 dom0 using the PV code paths (guest_io_{write/read}), but those accesses where never implemented for PVHv2 dom0. This patch provides such mediated accesses to the RTC for PVH dom0, just like it's provided for a classic PV dom0. Pull out some of the RTC logic from guest_io_{read/write} into specific helpers that can be used by both PV and HVM guests. The setup of the handlers for PVH is done in rtc_init, which is already used to initialize the fully emulated RTC. Without this a Linux PVH dom0 will read garbage when trying to access the RTC, and one vCPU will be constantly looping in rtc_timer_do_work. Note that such issue doesn't happen on domUs because the ACPI NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the accesses are not emulated but rather forwarded to the physical hardware. No functional change expected for classic PV dom0. Signed-off-by: Roger Pau Monné --- for-4.14 reasoning: the fix is mostly isolated to PVH dom0, and as such the risk is very low of causing issues to other guests types, but without this fix one vCPU when using a Linux dom0 will be constantly looping over rtc_timer_do_work with 100% CPU usage, at least when using Linux 4.19 or newer. --- Changes since v2: - Move the access check into the read/write handler. - Allow access to the latched first RTC port by all PV guests. - Register the handlers for HVM native accesses if vRTC is disabled. Changes since v1: - Share the code with PV. - Add access checks to the IO ports. --- xen/arch/x86/hvm/rtc.c | 26 +++++++++++++ xen/arch/x86/pv/emul-priv-op.c | 30 ++------------- xen/arch/x86/time.c | 62 +++++++++++++++++++++++++++++++ xen/include/asm-x86/mc146818rtc.h | 3 ++ 4 files changed, 95 insertions(+), 26 deletions(-) diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c index 5bbbdc0e0f..3150f5f147 100644 --- a/xen/arch/x86/hvm/rtc.c +++ b/xen/arch/x86/hvm/rtc.c @@ -808,12 +808,38 @@ void rtc_reset(struct domain *d) s->pt.source = PTSRC_isa; } +/* RTC mediator for HVM hardware domain. */ +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, + uint32_t *val) +{ + if ( dir == IOREQ_READ ) + *val = ~0; + + if ( size != 1 ) + { + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); + return X86EMUL_OKAY; + } + + if ( dir == IOREQ_WRITE ) + rtc_guest_write(port, *val); + else + *val = rtc_guest_read(port); + + return X86EMUL_OKAY; +} + void rtc_init(struct domain *d) { RTCState *s = domain_vrtc(d); if ( !has_vrtc(d) ) + { + if ( is_hardware_domain(d) ) + /* Hardware domain gets mediated access to the physical RTC. */ + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); return; + } spin_lock_init(&s->lock); diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index fad6c754ad..2cedaab6b9 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -280,19 +280,9 @@ static uint32_t guest_io_read(unsigned int port, unsigned int bytes, { sub_data = pv_pit_handler(port, 0, 0); } - else if ( port == RTC_PORT(0) ) + else if ( (port == RTC_PORT(0) || port == RTC_PORT(1)) ) { - sub_data = currd->arch.cmos_idx; - } - else if ( (port == RTC_PORT(1)) && - ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) - { - unsigned long flags; - - spin_lock_irqsave(&rtc_lock, flags); - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); - sub_data = inb(RTC_PORT(1)); - spin_unlock_irqrestore(&rtc_lock, flags); + sub_data = rtc_guest_read(port); } else if ( (port == 0xcf8) && (bytes == 4) ) { @@ -413,21 +403,9 @@ static void guest_io_write(unsigned int port, unsigned int bytes, { pv_pit_handler(port, (uint8_t)data, 1); } - else if ( port == RTC_PORT(0) ) - { - currd->arch.cmos_idx = data; - } - else if ( (port == RTC_PORT(1)) && - ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) + else if ( (port == RTC_PORT(0) || port == RTC_PORT(1)) ) { - unsigned long flags; - - if ( pv_rtc_handler ) - pv_rtc_handler(currd->arch.cmos_idx & 0x7f, data); - spin_lock_irqsave(&rtc_lock, flags); - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); - outb(data, RTC_PORT(1)); - spin_unlock_irqrestore(&rtc_lock, flags); + rtc_guest_write(port, data); } else if ( (port == 0xcf8) && (bytes == 4) ) { diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c index bbaea3aa65..9863108f41 100644 --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include #include @@ -1110,6 +1111,67 @@ static unsigned long get_cmos_time(void) return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); } +/* Helpers for guest accesses to the physical RTC. */ +unsigned int rtc_guest_read(unsigned int port) +{ + const struct domain *currd = current->domain; + unsigned long flags; + unsigned int data = ~0; + + switch ( port ) + { + case RTC_PORT(0): + /* + * All PV domains are allowed to read the latched value of the first + * RTC port. This is useful in order to store data when debugging. + */ + data = currd->arch.cmos_idx; + break; + + case RTC_PORT(1): + if ( !ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) + break; + spin_lock_irqsave(&rtc_lock, flags); + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); + data = inb(RTC_PORT(1)); + spin_unlock_irqrestore(&rtc_lock, flags); + break; + default: + ASSERT_UNREACHABLE(); + } + + return data; +} + +void rtc_guest_write(unsigned int port, unsigned int data) +{ + struct domain *currd = current->domain; + unsigned long flags; + + switch ( port ) + { + case RTC_PORT(0): + /* + * All PV domains are allowed to write to the latched value of the + * first RTC port. This is useful in order to store data when + * debugging. + */ + currd->arch.cmos_idx = data; + break; + + case RTC_PORT(1): + if ( !ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) + break; + spin_lock_irqsave(&rtc_lock, flags); + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); + outb(data, RTC_PORT(1)); + spin_unlock_irqrestore(&rtc_lock, flags); + break; + default: + ASSERT_UNREACHABLE(); + } +} + static unsigned long get_wallclock_time(void) { #ifdef CONFIG_XEN_GUEST diff --git a/xen/include/asm-x86/mc146818rtc.h b/xen/include/asm-x86/mc146818rtc.h index 8758528f7c..803b236c0a 100644 --- a/xen/include/asm-x86/mc146818rtc.h +++ b/xen/include/asm-x86/mc146818rtc.h @@ -110,4 +110,7 @@ outb_p((val),RTC_PORT(1)); \ #define RTC_IRQ 8 +unsigned int rtc_guest_read(unsigned int port); +void rtc_guest_write(unsigned int port, unsigned int data); + #endif /* _ASM_MC146818RTC_H */ -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 10:58:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 10:58:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFTm-0006pZ-R3; Mon, 08 Jun 2020 10:58:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFTm-0006pU-7d for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 10:58:10 +0000 X-Inumbo-ID: ef497734-a976-11ea-b263-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ef497734-a976-11ea-b263-12813bfff9fa; Mon, 08 Jun 2020 10:58:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6BEFCAAC3; Mon, 8 Jun 2020 10:58:10 +0000 (UTC) Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction To: Paul Durrant References: <20200608094619.28336-1-paul@xen.org> From: Jan Beulich Message-ID: <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> Date: Mon, 8 Jun 2020 12:58:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200608094619.28336-1-paul@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Paul Durrant , =?UTF-8?Q?Marek_Marczykowski-G=c3=b3recki?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 11:46, Paul Durrant wrote: > From: Paul Durrant > > When an emulation request is initiated in hvm_send_ioreq() the guest vcpu is > blocked on an event channel until that request is completed. If, however, > the emulator is killed whilst that emulation is pending then the ioreq > server may be destroyed. Thus when the vcpu is awoken the code in > handle_hvm_io_completion() will find no pending request to wait for, but will > leave the internal vcpu io_req.state set to IOREQ_READY and the vcpu shutdown > deferall flag in place (because hvm_io_assist() will never be called). The > emulation request is then completed anyway. This means that any subsequent call > to hvmemul_do_io() will find an unexpected value in io_req.state and will > return X86EMUL_UNHANDLEABLE, which in some cases will result in continuous > re-tries. > > This patch fixes the issue by moving the setting of io_req.state and clearing > of shutdown deferral (as will as MSI-X write completion) out of hvm_io_assist() > and directly into handle_hvm_io_completion(). > > Reported-by: Marek Marczykowski-Górecki > Signed-off-by: Paul Durrant Reviewed-by: Jan Beulich with a question: > --- a/xen/arch/x86/hvm/ioreq.c > +++ b/xen/arch/x86/hvm/ioreq.c > @@ -109,15 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data) > ioreq_t *ioreq = &v->arch.hvm.hvm_io.io_req; > > if ( hvm_ioreq_needs_completion(ioreq) ) > - { > - ioreq->state = STATE_IORESP_READY; > ioreq->data = data; > - } > - else > - ioreq->state = STATE_IOREQ_NONE; > - > - msix_write_completion(v); > - vcpu_end_shutdown_deferral(v); > > sv->pending = false; > } With this, is the function worth keeping at all? Also I assume the patch has your implied R-a-b? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:01:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:01:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFX5-0007gJ-Me; Mon, 08 Jun 2020 11:01:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFX4-0007gB-G1 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:01:34 +0000 X-Inumbo-ID: 69b973c0-a977-11ea-9b55-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 69b973c0-a977-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 11:01:33 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ifZbNR964yFrd7XAuIQluGtMgKvTWqNSB6993Gum/pgPe7Uqc5oGoLM63y3R2eYbYKREFstAcN s2I80MPcNDuLLq1L/kMn8POoPpZcOGlcMvde1YPmzO6c5WE/c3kqNBKzbxrFdQTJJ07UAx3mAM INOXYv094s+VMqk6Jr6XXxGiYjQ96UcAPBDioLW2Rh+5MEgG3BAPVl8JqOlRTidhH2IwVDovMV 75AadluaD+5MCyPfBB9iUH3IynthP2IPjD1osyCBR8h/ehweAYTZVcocdAXffa4RVUqz30rTn1 Sk4= X-SBRS: 2.7 X-MesageID: 19811329 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19811329" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24286.6790.983312.672969@mariner.uk.xensource.com> Date: Mon, 8 Jun 2020 12:01:26 +0100 To: Olaf Hering Subject: Re: [PATCH v1] tools: fix usage of strncpy In-Reply-To: <20200608100051.16be834e.olaf@aepfle.de> References: <20200608072855.26589-1-olaf@aepfle.de> <20200608100051.16be834e.olaf@aepfle.de> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , xen-devel@lists.xenproject.org, Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Olaf Hering writes ("Re: [PATCH v1] tools: fix usage of strncpy"): > Am Mon, 8 Jun 2020 09:28:54 +0200 > schrieb Olaf Hering : > > off-by-one error in libxl__prepare_sockaddr_un > > There is none, I had read the code backwards... I have just had the same thoughts but in the opposite order. That is at first I thought this was not a problem, but now I think there is. There are some kernel interfaces where a fixed-size buffer is provided, and the kernel will tolerate a null-terminated string, but will in any case not read beyond the end of the buffer. Anything involving IFNAMSIZ comes to mind. But I think sun_path is not one of those. The manpage I have here says that to be portable you must null-terminate sun_path. I know that there are some implementations where it is possible to pass a longer path, effectively treating sun_path as a trailing vla. Looking at your diff, its effect seems to be to ensure null-termination by truncating overlong paths. I think the right approach is to return an error, not to silently truncate. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:04:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:04:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFaA-0007tR-5K; Mon, 08 Jun 2020 11:04:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFa8-0007tF-2O for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:04:44 +0000 X-Inumbo-ID: db054478-a977-11ea-ba62-bc764e2007e4 Received: from mail-ej1-x634.google.com (unknown [2a00:1450:4864:20::634]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id db054478-a977-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 11:04:43 +0000 (UTC) Received: by mail-ej1-x634.google.com with SMTP id o15so17759715ejm.12 for ; Mon, 08 Jun 2020 04:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=oe+Kg0COLUqXFiNWFWGG0EXTH5E4ua+SFmXiIQISts8=; b=JKs5NYY2s+6bFNILOdZ2s3n6SimQB4olCnbElvgHpFHvq+dwHgLZbOADrjyPJV369q cRjlH/djIpNVY3pkuvLC1ihVXBk2YN+wENJa+yLx7zfByByWlojlWus6jqnpv6eGvkKO WX9qu2K6Si4tWIpYeEBWY4aDQHHSDMr0+afrPiO7uyCkxKh8THMFNh20IW5CZaiTUz1L pyTq/sznJK6sEKkOLBArTpKGLDkZKdu69NCxjuabjbbAHl14IvOncN2lxlJY5z9KLgAZ 5Fpt4SnLwKtbWyNj3AcMJGmGNOY3NiVVAs4mNBIj23wr6ms6+h4LEg6mj1Vm4JUyBubp kuNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=oe+Kg0COLUqXFiNWFWGG0EXTH5E4ua+SFmXiIQISts8=; b=IJn/i1jI7RDa0HRWSSdONqdP/D71vTMy9Gb93qV530XP7BEfph0MrDogrw42lHsdxn e7EMrA5A2aj9H+rPZdsvThufh5cEMp3884E+j4uYJonVJulL97Zpj9gX/A03ObfKLv9g p8PC54SzKQMIWLfqkYlhzzBDwf7VLfytgPFD0e1md0tvPJoSC5CrZYebU2Bq5tleBNe+ w46cu8NpqJd8+VRdjp33CUWanZS65/Dcha4f37TDmkUcvvquNqP7AtH37SUmhSJQvoBq 8EbqEypEXbJhZd64sFO0NFGjJp0pUHAFmoQiSJw6wMVnXliDAoEi5wgKtDSaYH1cwUhV FCkg== X-Gm-Message-State: AOAM531+wFTxEpGkLCH81VVuon/OSaqVIczuJY7Io9Kvgsel51ZJiaDn 8eke/yCvaAMtt2+X/aoC3Qk= X-Google-Smtp-Source: ABdhPJyj+owR/BlOqaoUjGJi9cIQfH9TfxaActgh5dD9eKQM4FeyIH0U9SPF7vh756LA21MmuYMIZQ== X-Received: by 2002:a17:906:198d:: with SMTP id g13mr19850681ejd.281.1591614282569; Mon, 08 Jun 2020 04:04:42 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id cx13sm12224104edb.20.2020.06.08.04.04.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 04:04:42 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <20200608094619.28336-1-paul@xen.org> <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> In-Reply-To: <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> Subject: RE: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction Date: Mon, 8 Jun 2020 12:04:40 +0100 Message-ID: <002a01d63d84$9c351430$d49f3c90$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQG4RzFDVM83uzCFIZn1YivdDmazZAHQan7RqPv2BqA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Paul Durrant' , =?utf-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 08 June 2020 11:58 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; Paul Durrant = ; Marek Marczykowski-G=C3=B3recki > > Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing = with ioreq server destruction >=20 > On 08.06.2020 11:46, Paul Durrant wrote: > > From: Paul Durrant > > > > When an emulation request is initiated in hvm_send_ioreq() the guest = vcpu is > > blocked on an event channel until that request is completed. If, = however, > > the emulator is killed whilst that emulation is pending then the = ioreq > > server may be destroyed. Thus when the vcpu is awoken the code in > > handle_hvm_io_completion() will find no pending request to wait for, = but will > > leave the internal vcpu io_req.state set to IOREQ_READY and the vcpu = shutdown > > deferall flag in place (because hvm_io_assist() will never be = called). The > > emulation request is then completed anyway. This means that any = subsequent call > > to hvmemul_do_io() will find an unexpected value in io_req.state and = will > > return X86EMUL_UNHANDLEABLE, which in some cases will result in = continuous > > re-tries. > > > > This patch fixes the issue by moving the setting of io_req.state and = clearing > > of shutdown deferral (as will as MSI-X write completion) out of = hvm_io_assist() > > and directly into handle_hvm_io_completion(). > > > > Reported-by: Marek Marczykowski-G=C3=B3recki = > > Signed-off-by: Paul Durrant >=20 > Reviewed-by: Jan Beulich > with a question: >=20 > > --- a/xen/arch/x86/hvm/ioreq.c > > +++ b/xen/arch/x86/hvm/ioreq.c > > @@ -109,15 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu = *sv, uint64_t data) > > ioreq_t *ioreq =3D &v->arch.hvm.hvm_io.io_req; > > > > if ( hvm_ioreq_needs_completion(ioreq) ) > > - { > > - ioreq->state =3D STATE_IORESP_READY; > > ioreq->data =3D data; > > - } > > - else > > - ioreq->state =3D STATE_IOREQ_NONE; > > - > > - msix_write_completion(v); > > - vcpu_end_shutdown_deferral(v); > > > > sv->pending =3D false; > > } >=20 > With this, is the function worth keeping at all? I did think about that, but it is called in more than one place. So, in = the interest of trying to make back-porting straightforward, I thought = it best to keep it simple. >=20 > Also I assume the patch has your implied R-a-b? >=20 Since it has your R-b now, yes :-) Paul From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:09:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:09:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFf6-00087h-Ox; Mon, 08 Jun 2020 11:09:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFf6-00087c-Cx for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:09:52 +0000 X-Inumbo-ID: 92bda3d0-a978-11ea-9ad7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 92bda3d0-a978-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 11:09:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2C231AC37; Mon, 8 Jun 2020 11:09:54 +0000 (UTC) Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction To: paul@xen.org References: <20200608094619.28336-1-paul@xen.org> <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> <002a01d63d84$9c351430$d49f3c90$@xen.org> From: Jan Beulich Message-ID: Date: Mon, 8 Jun 2020 13:09:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <002a01d63d84$9c351430$d49f3c90$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Paul Durrant' , =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 13:04, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 08 June 2020 11:58 >> To: Paul Durrant >> Cc: xen-devel@lists.xenproject.org; Paul Durrant ; Marek Marczykowski-Górecki >> >> Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction >> >> On 08.06.2020 11:46, Paul Durrant wrote: >>> From: Paul Durrant >>> >>> When an emulation request is initiated in hvm_send_ioreq() the guest vcpu is >>> blocked on an event channel until that request is completed. If, however, >>> the emulator is killed whilst that emulation is pending then the ioreq >>> server may be destroyed. Thus when the vcpu is awoken the code in >>> handle_hvm_io_completion() will find no pending request to wait for, but will >>> leave the internal vcpu io_req.state set to IOREQ_READY and the vcpu shutdown >>> deferall flag in place (because hvm_io_assist() will never be called). The >>> emulation request is then completed anyway. This means that any subsequent call >>> to hvmemul_do_io() will find an unexpected value in io_req.state and will >>> return X86EMUL_UNHANDLEABLE, which in some cases will result in continuous >>> re-tries. >>> >>> This patch fixes the issue by moving the setting of io_req.state and clearing >>> of shutdown deferral (as will as MSI-X write completion) out of hvm_io_assist() >>> and directly into handle_hvm_io_completion(). >>> >>> Reported-by: Marek Marczykowski-Górecki >>> Signed-off-by: Paul Durrant >> >> Reviewed-by: Jan Beulich >> with a question: >> >>> --- a/xen/arch/x86/hvm/ioreq.c >>> +++ b/xen/arch/x86/hvm/ioreq.c >>> @@ -109,15 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data) >>> ioreq_t *ioreq = &v->arch.hvm.hvm_io.io_req; >>> >>> if ( hvm_ioreq_needs_completion(ioreq) ) >>> - { >>> - ioreq->state = STATE_IORESP_READY; >>> ioreq->data = data; >>> - } >>> - else >>> - ioreq->state = STATE_IOREQ_NONE; >>> - >>> - msix_write_completion(v); >>> - vcpu_end_shutdown_deferral(v); >>> >>> sv->pending = false; >>> } >> >> With this, is the function worth keeping at all? > > I did think about that, but it is called in more than one place. So, in the interest of trying to make back-porting straightforward, I thought it best to keep it simple. > >> >> Also I assume the patch has your implied R-a-b? >> > > Since it has your R-b now, yes :-) Thanks. As said in the other thread, I think the change here will mask a problem elsewhere (presumably in qemu). I'm therefore unsure whether we want to apply it right away, rather than first understanding the root cause of Marek's specific problem. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:12:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:12:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFht-0000Ua-4n; Mon, 08 Jun 2020 11:12:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFhs-0000UU-9t for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:12:44 +0000 X-Inumbo-ID: f91b7a94-a978-11ea-ba62-bc764e2007e4 Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f91b7a94-a978-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 11:12:43 +0000 (UTC) Received: by mail-ed1-x541.google.com with SMTP id m21so13050948eds.13 for ; Mon, 08 Jun 2020 04:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=xVNzWPEWtJn48LR3763BNFv9x8q3B7iB/H4BXfv98lk=; b=A2kGQ5V8hrHJtFzz8wgLEZbWB+OtQkHPXW2kvX2+AxzVyfwxI+kiTMNoywi/kEKC1J KvrrJY8xqXNAli7b/fmtbl0MZtzVZfO0ZGugyo8Qxix0UcIOupBA0tjdiuWFktKZWhD6 qcQKRXx29eJOL6l98Lr6HxdyTlWVhRD9HhQvXKh5HxOhFcNjQvOo0JLswADh97HBmFhq dN0+0U5FLTR0+vNm0ZjTAWuBSlpfqPR8QIMDX+fS2mVfzgqocVGASHHIjDr3mNrptT7L l7I5LNMGkIkrlRFQYg/hIRTNcJuNqr63s4+VsFoaYemcSQbpRBDTTMdxEHvV6kPY7Wbo 1ULg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=xVNzWPEWtJn48LR3763BNFv9x8q3B7iB/H4BXfv98lk=; b=fbkUKg25m5PAORDtOJjPW8vaSOwqsvWDKhIyUGhV1hGFQhYLpFhrsT4DL8gIHJsNIQ 3L8c/OdHM6qS4fEg3ITlE0mWrhI5WDgoPMfrtgYufxuE3Cr2Ke0zcOjz5zfXRdOtvmwh TX1XH95mtdQZ9RQGZkbHA/bOt7MhZ8DxiW3xX1/8D3gVmCwQpbrcHXS/rNm1vHWhZXjA rHjezDZDi60Q+UdXQ/hm0V6JO6WTvonAUIRq5wZGNxhvPjPHnPa/gAZGIWL7sofjI7xM c9nU8g8i/BrZ/hSLn/ds8UD4gtvDEhJUye5Q4QcdDn2HOsY3MEhOUcjwrd6fO2uMe7zS G76A== X-Gm-Message-State: AOAM533K4sC6v0AIjSXe98wdIZmtcxPnMLv4FBYpZ5fhvyVU8yHgHAvm ceMy4xMePC00yGpmkNfX6f8= X-Google-Smtp-Source: ABdhPJxpxNoZV56A0JtFGXhjMq2UGuWid1J7T9k2f5HnTjDDGt+MzPfSYe/QbOwmAejxbH/Z46L4aA== X-Received: by 2002:a05:6402:897:: with SMTP id e23mr21799578edy.217.1591614762393; Mon, 08 Jun 2020 04:12:42 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id q3sm6919125eds.0.2020.06.08.04.12.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 04:12:41 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200608102948.7327-1-roger.pau@citrix.com> In-Reply-To: <20200608102948.7327-1-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14 v3] x86/rtc: provide mediated access to RTC for PVH dom0 Date: Mon, 8 Jun 2020 12:12:40 +0100 Message-ID: <002c01d63d85$ba36da30$2ea48e90$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKSbMd9fsAVDk5Ayc3mrBjFSbfGhKdWMD5Q X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 08 June 2020 11:30 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich = ; Andrew > Cooper ; Wei Liu > Subject: [PATCH for-4.14 v3] x86/rtc: provide mediated access to RTC = for PVH dom0 >=20 > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > code paths (guest_io_{write/read}), but those accesses where never > implemented for PVHv2 dom0. This patch provides such mediated accesses > to the RTC for PVH dom0, just like it's provided for a classic PV > dom0. >=20 > Pull out some of the RTC logic from guest_io_{read/write} into > specific helpers that can be used by both PV and HVM guests. The > setup of the handlers for PVH is done in rtc_init, which is already > used to initialize the fully emulated RTC. >=20 > Without this a Linux PVH dom0 will read garbage when trying to access > the RTC, and one vCPU will be constantly looping in > rtc_timer_do_work. >=20 > Note that such issue doesn't happen on domUs because the ACPI > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > accesses are not emulated but rather forwarded to the physical > hardware. >=20 > No functional change expected for classic PV dom0. >=20 > Signed-off-by: Roger Pau Monn=C3=A9 > --- > for-4.14 reasoning: the fix is mostly isolated to PVH dom0, and as > such the risk is very low of causing issues to other guests types, but > without this fix one vCPU when using a Linux dom0 will be constantly > looping over rtc_timer_do_work with 100% CPU usage, at least when > using Linux 4.19 or newer. > --- > Changes since v2: > - Move the access check into the read/write handler. > - Allow access to the latched first RTC port by all PV guests. > - Register the handlers for HVM native accesses if vRTC is disabled. >=20 > Changes since v1: > - Share the code with PV. > - Add access checks to the IO ports. > --- > xen/arch/x86/hvm/rtc.c | 26 +++++++++++++ > xen/arch/x86/pv/emul-priv-op.c | 30 ++------------- > xen/arch/x86/time.c | 62 = +++++++++++++++++++++++++++++++ > xen/include/asm-x86/mc146818rtc.h | 3 ++ > 4 files changed, 95 insertions(+), 26 deletions(-) >=20 > diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c > index 5bbbdc0e0f..3150f5f147 100644 > --- a/xen/arch/x86/hvm/rtc.c > +++ b/xen/arch/x86/hvm/rtc.c > @@ -808,12 +808,38 @@ void rtc_reset(struct domain *d) > s->pt.source =3D PTSRC_isa; > } >=20 > +/* RTC mediator for HVM hardware domain. */ > +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, > + uint32_t *val) > +{ > + if ( dir =3D=3D IOREQ_READ ) > + *val =3D ~0; > + > + if ( size !=3D 1 ) > + { > + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); > + return X86EMUL_OKAY; > + } > + > + if ( dir =3D=3D IOREQ_WRITE ) > + rtc_guest_write(port, *val); > + else > + *val =3D rtc_guest_read(port); > + > + return X86EMUL_OKAY; > +} > + > void rtc_init(struct domain *d) > { > RTCState *s =3D domain_vrtc(d); >=20 > if ( !has_vrtc(d) ) > + { > + if ( is_hardware_domain(d) ) > + /* Hardware domain gets mediated access to the physical = RTC. */ > + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); > return; > + } >=20 > spin_lock_init(&s->lock); >=20 > diff --git a/xen/arch/x86/pv/emul-priv-op.c = b/xen/arch/x86/pv/emul-priv-op.c > index fad6c754ad..2cedaab6b9 100644 > --- a/xen/arch/x86/pv/emul-priv-op.c > +++ b/xen/arch/x86/pv/emul-priv-op.c > @@ -280,19 +280,9 @@ static uint32_t guest_io_read(unsigned int port, = unsigned int bytes, > { > sub_data =3D pv_pit_handler(port, 0, 0); > } > - else if ( port =3D=3D RTC_PORT(0) ) > + else if ( (port =3D=3D RTC_PORT(0) || port =3D=3D = RTC_PORT(1)) ) > { > - sub_data =3D currd->arch.cmos_idx; > - } > - else if ( (port =3D=3D RTC_PORT(1)) && > - ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) > - { > - unsigned long flags; > - > - spin_lock_irqsave(&rtc_lock, flags); > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > - sub_data =3D inb(RTC_PORT(1)); > - spin_unlock_irqrestore(&rtc_lock, flags); > + sub_data =3D rtc_guest_read(port); > } > else if ( (port =3D=3D 0xcf8) && (bytes =3D=3D 4) ) > { > @@ -413,21 +403,9 @@ static void guest_io_write(unsigned int port, = unsigned int bytes, > { > pv_pit_handler(port, (uint8_t)data, 1); > } > - else if ( port =3D=3D RTC_PORT(0) ) > - { > - currd->arch.cmos_idx =3D data; > - } > - else if ( (port =3D=3D RTC_PORT(1)) && > - ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) > + else if ( (port =3D=3D RTC_PORT(0) || port =3D=3D = RTC_PORT(1)) ) > { > - unsigned long flags; > - > - if ( pv_rtc_handler ) > - pv_rtc_handler(currd->arch.cmos_idx & 0x7f, data); > - spin_lock_irqsave(&rtc_lock, flags); > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > - outb(data, RTC_PORT(1)); > - spin_unlock_irqrestore(&rtc_lock, flags); > + rtc_guest_write(port, data); > } > else if ( (port =3D=3D 0xcf8) && (bytes =3D=3D 4) ) > { > diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c > index bbaea3aa65..9863108f41 100644 > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1110,6 +1111,67 @@ static unsigned long get_cmos_time(void) > return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, = rtc.sec); > } >=20 > +/* Helpers for guest accesses to the physical RTC. */ > +unsigned int rtc_guest_read(unsigned int port) > +{ > + const struct domain *currd =3D current->domain; > + unsigned long flags; > + unsigned int data =3D ~0; > + > + switch ( port ) > + { > + case RTC_PORT(0): > + /* > + * All PV domains are allowed to read the latched value of = the first > + * RTC port. This is useful in order to store data when = debugging. > + */ Is this comment correct. AFAICT your call to register_portio_handler() = would allow a PVH dom0 to access this too. > + data =3D currd->arch.cmos_idx; > + break; > + > + case RTC_PORT(1): > + if ( !ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) Why RTC_PORT(0) (and not RC_PORT(1)) as base here? Same queries for the write function. Paul > + break; > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + data =3D inb(RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + default: > + ASSERT_UNREACHABLE(); > + } > + > + return data; > +} > + > +void rtc_guest_write(unsigned int port, unsigned int data) > +{ > + struct domain *currd =3D current->domain; > + unsigned long flags; > + > + switch ( port ) > + { > + case RTC_PORT(0): > + /* > + * All PV domains are allowed to write to the latched value = of the > + * first RTC port. This is useful in order to store data when > + * debugging. > + */ > + currd->arch.cmos_idx =3D data; > + break; > + > + case RTC_PORT(1): > + if ( !ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) > + break; > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + outb(data, RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + default: > + ASSERT_UNREACHABLE(); > + } > +} > + > static unsigned long get_wallclock_time(void) > { > #ifdef CONFIG_XEN_GUEST > diff --git a/xen/include/asm-x86/mc146818rtc.h = b/xen/include/asm-x86/mc146818rtc.h > index 8758528f7c..803b236c0a 100644 > --- a/xen/include/asm-x86/mc146818rtc.h > +++ b/xen/include/asm-x86/mc146818rtc.h > @@ -110,4 +110,7 @@ outb_p((val),RTC_PORT(1)); \ >=20 > #define RTC_IRQ 8 >=20 > +unsigned int rtc_guest_read(unsigned int port); > +void rtc_guest_write(unsigned int port, unsigned int data); > + > #endif /* _ASM_MC146818RTC_H */ > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:16:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:16:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFli-0000gq-O8; Mon, 08 Jun 2020 11:16:42 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFlh-0000gl-UV for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:16:41 +0000 X-Inumbo-ID: 86ce38ae-a979-11ea-b266-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 86ce38ae-a979-11ea-b266-12813bfff9fa; Mon, 08 Jun 2020 11:16:41 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 3MoO6lT8qK+E37b6AUehW/KVTtG5FjljyXCcTFex33Gnu1h6nGl2zJ7xwJjWJZN63PcJLbcd7Z sKorSWfwZ0iUVkwikJSb9NkSjROKzAi93SKEZYCgyFKWwUFXwAE3QrX9CpzwSlQFJc+zMc3wGL Goki9x1iudqrfB7NBZveo4wtk9sgrheIFUzm9hGwvrL6gnP3I1Qv8EqSjwratHUa8Bt7S8Xbzc khi8l2seYZJIf8geQmwFMjZj1NEo23tClI1sk5+vBlZ8BqfjZalqF5D+3cJE7F6H+OttywQlqo 9HE= X-SBRS: 2.7 X-MesageID: 19812439 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19812439" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <24286.7700.36742.982395@mariner.uk.xensource.com> Date: Mon, 8 Jun 2020 12:16:36 +0100 To: George Dunlap Subject: Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile In-Reply-To: <5CF4AE1D-C80C-4E4C-B4AA-0779E7DC53E7@citrix.com> References: <20200526221612.900922-1-george.dunlap@citrix.com> <20200526221612.900922-2-george.dunlap@citrix.com> <5CF4AE1D-C80C-4E4C-B4AA-0779E7DC53E7@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , xen-devel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" George Dunlap writes ("Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile"): > So as written this turns out not to work correctly: `gengotypes.py` spits out syntactically valid but unformatted Go code, and then runs `go fmt` on it to get the right style (including tabs, &c). But the error code of `go fmt` isn’t checked; so on a system without go installed, if the build system decides it needs to re-run `gengotypes.py` for whatever reason, the build succeeds but the tree ends up “dirtied” with an unformatted version fo the generated text. And `go fmt' overwrites its input file ? The lost error is due to using `os.system' which does not raise an exception. The python 3 docs for `os.system' say | The subprocess module provides more powerful facilities for | spawning new processes and retrieving their results; using that | module is preferable to using this function. See the Replacing | Older Functions with the subprocess Module section in the | subprocess documentation for some helpful recipes. And the recipe suggests | sts = os.system("mycmd" + " myarg") | # becomes | sts = call("mycmd" + " myarg", shell=True) | Notes: | * Calling the program through the shell is usually not required. This is not particularly helpful advice because subprocess.call, like os.system, does not raise an exception when things go wrong. But it does have a "more realistic example" immediately afterwards which does actually check the error code. You wanted subprocess.check_call. IDK which Python versions have subprocess.check_call. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:21:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:21:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFqM-0001Un-8s; Mon, 08 Jun 2020 11:21:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiFqK-0001Ui-Gg for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:21:28 +0000 X-Inumbo-ID: 31ad8e14-a97a-11ea-9b55-bc764e2007e4 Received: from mail-ej1-x630.google.com (unknown [2a00:1450:4864:20::630]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 31ad8e14-a97a-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 11:21:27 +0000 (UTC) Received: by mail-ej1-x630.google.com with SMTP id f7so17844828ejq.6 for ; Mon, 08 Jun 2020 04:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=ipvRKQ4Fi0WbyIWCm3U4H8VkCZHz7OATbGhtwXc+yaI=; b=tFkLSDfcwP0q2+wz6LaEXRyu1R4zcIbE8nbRGLbKgUasMWM7Ay+56ZwTCM3ZIgB7T2 CYfVvOf/jhKGHokP+yGIgb0cZgIsGG2n4zZ864CrqsmjQ5/g5gwDHJeZc1/zQn6rnLjQ nKk0nrHDgzMX3RLFfDHryl5Y4gQdM+l6OEQ9FYCJyMu9AVevmnXZZLGiZDFt324WLoGV AXXiquuwrZX8K5AX6evdtcsHVTXgEGMMXJdieRSbQGv94jqI2B6kwuy8fVuo64VIeM6G Jmjf8ErKyldD5IH4zuf4g/E3AqpySBhaEdQiyvI+TJAbXbsFob1OAJkGCB3Hk946kL7Z ysxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=ipvRKQ4Fi0WbyIWCm3U4H8VkCZHz7OATbGhtwXc+yaI=; b=IT+TQK+D8xOD5s7YVP2K0Yisqjy+8c72F8FdQQmf640b464Lj70pYdMbvlhN8GMBA/ CSzTQYi35YCG7pdnrtyWrYuKYn9kLRpfsHZ/1w/90rQkNDAbILL86MSVp5Qfx89qhD9L VK94fIp1/6q0aYBBrs9A6oe6XqSRUbYKOxqXycNW5MrPpMseVzUWf0PEdGeuBq7F2vzq peJihrAa9vNqvZPnOxfSOCifeBY74vuDqa6yeqqOGA1h0NOMdF5t8aOHnrFtGu3KkpEE 4V33u6Ipw2HWlWHptq7SyACuSUp0Lil9RmP6n0AM/n1w2gc/+AV5/3DdmQwcsqUSElg6 aJIg== X-Gm-Message-State: AOAM532janNNKmXZddVTwUM+qmcKxT81qDK92BBlRIQ49PdkXZDBwngR SFkj9b50nxCWzq+ZdqxXIj4= X-Google-Smtp-Source: ABdhPJxzutSEZMTr01UtXUTNBvI0z59RbeQF3qWaOWFpjb/mjSxiUnNhYeUaHmoSVSdoqGJiqc6TCA== X-Received: by 2002:a17:906:76c4:: with SMTP id q4mr21519622ejn.371.1591615286900; Mon, 08 Jun 2020 04:21:26 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id z26sm9130525edm.1.2020.06.08.04.21.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 04:21:26 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <20200608094619.28336-1-paul@xen.org> <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> <002a01d63d84$9c351430$d49f3c90$@xen.org> In-Reply-To: Subject: RE: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction Date: Mon, 8 Jun 2020 12:21:25 +0100 Message-ID: <002d01d63d86$f2c35d50$d84a17f0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQG4RzFDVM83uzCFIZn1YivdDmazZAHQan7RAPjCHYMBYWkEHKjpKGxA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Paul Durrant' , =?utf-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 08 June 2020 12:10 > To: paul@xen.org > Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' = ; 'Marek Marczykowski-G=C3=B3recki' > > Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing = with ioreq server destruction >=20 > On 08.06.2020 13:04, Paul Durrant wrote: > >> -----Original Message----- > >> From: Jan Beulich > >> Sent: 08 June 2020 11:58 > >> To: Paul Durrant > >> Cc: xen-devel@lists.xenproject.org; Paul Durrant = ; Marek Marczykowski-G=C3=B3recki > >> > >> Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation = racing with ioreq server destruction > >> > >> On 08.06.2020 11:46, Paul Durrant wrote: > >>> From: Paul Durrant > >>> > >>> When an emulation request is initiated in hvm_send_ioreq() the = guest vcpu is > >>> blocked on an event channel until that request is completed. If, = however, > >>> the emulator is killed whilst that emulation is pending then the = ioreq > >>> server may be destroyed. Thus when the vcpu is awoken the code in > >>> handle_hvm_io_completion() will find no pending request to wait = for, but will > >>> leave the internal vcpu io_req.state set to IOREQ_READY and the = vcpu shutdown > >>> deferall flag in place (because hvm_io_assist() will never be = called). The > >>> emulation request is then completed anyway. This means that any = subsequent call > >>> to hvmemul_do_io() will find an unexpected value in io_req.state = and will > >>> return X86EMUL_UNHANDLEABLE, which in some cases will result in = continuous > >>> re-tries. > >>> > >>> This patch fixes the issue by moving the setting of io_req.state = and clearing > >>> of shutdown deferral (as will as MSI-X write completion) out of = hvm_io_assist() > >>> and directly into handle_hvm_io_completion(). > >>> > >>> Reported-by: Marek Marczykowski-G=C3=B3recki = > >>> Signed-off-by: Paul Durrant > >> > >> Reviewed-by: Jan Beulich > >> with a question: > >> > >>> --- a/xen/arch/x86/hvm/ioreq.c > >>> +++ b/xen/arch/x86/hvm/ioreq.c > >>> @@ -109,15 +109,7 @@ static void hvm_io_assist(struct = hvm_ioreq_vcpu *sv, uint64_t data) > >>> ioreq_t *ioreq =3D &v->arch.hvm.hvm_io.io_req; > >>> > >>> if ( hvm_ioreq_needs_completion(ioreq) ) > >>> - { > >>> - ioreq->state =3D STATE_IORESP_READY; > >>> ioreq->data =3D data; > >>> - } > >>> - else > >>> - ioreq->state =3D STATE_IOREQ_NONE; > >>> - > >>> - msix_write_completion(v); > >>> - vcpu_end_shutdown_deferral(v); > >>> > >>> sv->pending =3D false; > >>> } > >> > >> With this, is the function worth keeping at all? > > > > I did think about that, but it is called in more than one place. So, = in the interest of trying to > make back-porting straightforward, I thought it best to keep it = simple. > > > >> > >> Also I assume the patch has your implied R-a-b? > >> > > > > Since it has your R-b now, yes :-) >=20 > Thanks. As said in the other thread, I think the change here will mask > a problem elsewhere (presumably in qemu). I'm therefore unsure whether > we want to apply it right away, rather than first understanding the > root cause of Marek's specific problem. >=20 I think it ought to be applied right away since an emulator could die at = any time and we don't really want the vcpu constantly bouncing in this = case. Also, thinking of using emulators other than qemu, it's not = necessarily a bug if they deregister at an arbitrary time... In fact it = takes my mind back to PCMCIA cards, when device drivers had to be robust = to them disappearing during an I/O cycle. Paul > Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:35:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:35:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiG3K-0002SF-Fa; Mon, 08 Jun 2020 11:34:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiG3I-0002SA-Nr for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:34:52 +0000 X-Inumbo-ID: 10cbcaec-a97c-11ea-9b55-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 10cbcaec-a97c-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 11:34:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2BB0BABE4; Mon, 8 Jun 2020 11:34:54 +0000 (UTC) Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction To: paul@xen.org References: <20200608094619.28336-1-paul@xen.org> <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> <002a01d63d84$9c351430$d49f3c90$@xen.org> <002d01d63d86$f2c35d50$d84a17f0$@xen.org> From: Jan Beulich Message-ID: <7912fccb-ca4a-97c5-769d-4559196f3e8a@suse.com> Date: Mon, 8 Jun 2020 13:34:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <002d01d63d86$f2c35d50$d84a17f0$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Paul Durrant' , =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 13:21, Paul Durrant wrote: >> From: Jan Beulich >> Sent: 08 June 2020 12:10 >> >> As said in the other thread, I think the change here will mask >> a problem elsewhere (presumably in qemu). I'm therefore unsure whether >> we want to apply it right away, rather than first understanding the >> root cause of Marek's specific problem. >> > > I think it ought to be applied right away since an emulator could die at any time and we don't really want the vcpu constantly bouncing in this case. Also, thinking of using emulators other than qemu, it's not necessarily a bug if they deregister at an arbitrary time... Oh, sure, I fully agree we need the change regardless of the possible qemu misbehavior. But if we commit this change right away, will there be anyone still caring about / looking into the qemu side issue? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:39:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:39:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiG85-0002dE-2Z; Mon, 08 Jun 2020 11:39:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiG84-0002d9-8Z for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:39:48 +0000 X-Inumbo-ID: c0eaef7a-a97c-11ea-b266-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c0eaef7a-a97c-11ea-b266-12813bfff9fa; Mon, 08 Jun 2020 11:39:47 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: AyeaVFUQ6CfyNQPiZMHUlPt6zuKwSokVMJHFmhlqzLVffoiDp5XdMSrOd1wZcZhNjJZqyiS6K1 lyzmJwJ6mxWSOiWkoUvpE4B0a52XQtSAPrFBeWSfqolCxGDnEk/LI0ZXUgS3C96pheahfZKhEM 5h1sQkLH+wtYocHnJsYHXsbZKbnw6t4mrPEs9Yc+oXAMxUR+xivNmAW7yEUU2eMPeKIYmkLVEU Z3eL5fo2KQK8V/gXnPjrtT5ntt3l0WU1NSzYoNfiiuke8HmBEq9/cBBbvj9z9/8si1iU4aTCSg 1EY= X-SBRS: 2.7 X-MesageID: 19813792 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19813792" From: George Dunlap To: Nick Rosbrook Subject: Re: [PATCH for-4.14] golang/xenlight: remove call to go fmt in gengotypes.py Thread-Topic: [PATCH for-4.14] golang/xenlight: remove call to go fmt in gengotypes.py Thread-Index: AQHWPB0FRC5n06e/7UW7VAlSJqYdHajOeT+A Date: Mon, 8 Jun 2020 11:39:43 +0000 Message-ID: References: <20200606161025.19057-1-rosbrookn@ainfosec.com> In-Reply-To: <20200606161025.19057-1-rosbrookn@ainfosec.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , Xen-devel , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQo+IE9uIEp1biA2LCAyMDIwLCBhdCA1OjEwIFBNLCBOaWNrIFJvc2Jyb29rIDxyb3Nicm9va25A Z21haWwuY29tPiB3cm90ZToNCj4gDQo+IFNpbmNlIHRoZSBnb2xhbmcgYmluZGluZ3MgYXJlIG5v dyBzZXQgdG8gYmUgcmUtZ2VuZXJhdGVkIHdoZW5ldmVyIGENCj4gY2hhbmdlIGlzIG1hZGUgdG8g dG9vbHMvbGlieGwvbGlieGxfdHlwZXMuaWRsLCB0aGUgY2FsbCB0byBnbyBmbXQgaW4NCj4gZ2Vu Z290eXBlcy5weSByZXN1bHRzIGluIGEgZGlydHkgZ2l0IHRyZWUgZm9yIHVzZXJzIHdpdGhvdXQg Z28NCj4gaW5zdGFsbGVkLg0KPiANCj4gQXMgYW4gaW1tZWRpYXRlIGZpeCwganVzdCByZW1vdmUg dGhlIGNhbGwgdG8gZ28gZm10IGZyb20gZ2VuZ290eXBlcy5weS4NCj4gV2hpbGUgaGVyZSwgbWFr ZSBzdXJlIHRoZSBETyBOT1QgRURJVCBjb21tZW50IGFuZCBwYWNrYWdlIGRlY2xhcmF0aW9uDQo+ IHJlbWFpbiBmb3JtYXR0ZWQgY29ycmVjdGx5LiBBbGwgb3RoZXIgZ2VuZXJhdGVkIGNvZGUgaXMg bGVmdA0KPiB1bi1mb3JtYXR0ZWQgZm9yIG5vdy4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IE5pY2sg Um9zYnJvb2sgPHJvc2Jyb29rbkBhaW5mb3NlYy5jb20+DQoNClJldmlld2VkLWJ5OiBHZW9yZ2Ug RHVubGFwIDxnZW9yZ2UuZHVubGFwQGNpdHJpeC5jb20+DQoNCldpdGggb25lIG5vdGU6IGdpdCBj b21wbGFpbnMgdGhhdCB0aGUgcmVzdWx0aW5nIHBhdGNoIGludHJvZHVjZXMgbG9hZHMgb2YgdHJh aWxpbmcgd2hpdGVzcGFjZS4gIEkgd2VudCB0aG91Z2ggZ2VuZ290eXBlcy5weSBhbmQgZXNzZW50 aWFsbHkgZGlkIGBzLyBcbi9cbi9nYC4gIFdpdGggeW91ciBwZXJtaXNzaW9uIEnigJlsbCBmb2xk IHRoYXQgKGFuZCB0aGUgcmVzdWx0aW5nIHBhdGNoZXMpIGludG8gdGhpcyBiZWZvcmUgY2hlY2tp bmcgaXQgaW4uDQoNCiAtR2VvcmdlDQoNCg== From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:46:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:46:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGE8-0003Ru-P4; Mon, 08 Jun 2020 11:46:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGE7-0003Rp-53 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:46:03 +0000 X-Inumbo-ID: a0610478-a97d-11ea-96fb-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a0610478-a97d-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 11:46:01 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: SlCQF7zaoajRaZFx5izKWPMrCbcod7XzR2/jdNmFHN6Y0YYkWphxMDVFA6IbwcLGi7aVvakZZg PRrnNmiJMwHF9c0tA/lA3+jRpF3lU23JWL4lvhHlrfy74/i6gdzFO69Z8kYqMupjWhtntmJe35 OThdpy3+dJ46veB40dM65krPcNxfEmxXatKhg8cNir7pmxrgCMF2wQaKe7kV5QfZELaWMjv+87 Uw+bJ/2qpqAguesfvaVYQW6VpCEJgzG0sgWDkR3G9k9wbXHP9/DTuryeUvnpYrvW/hfTYi8nUS 1Zk= X-SBRS: 2.7 X-MesageID: 19814205 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19814205" Date: Mon, 8 Jun 2020 13:45:52 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Subject: Re: [PATCH for-4.14 v3] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200608114552.GA722@Air-de-Roger> References: <20200608102948.7327-1-roger.pau@citrix.com> <002c01d63d85$ba36da30$2ea48e90$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <002c01d63d85$ba36da30$2ea48e90$@xen.org> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Wei Liu' , 'Jan Beulich' , 'Andrew Cooper' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 08, 2020 at 12:12:40PM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Roger Pau Monne > > Sent: 08 June 2020 11:30 > > To: xen-devel@lists.xenproject.org > > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich ; Andrew > > Cooper ; Wei Liu > > Subject: [PATCH for-4.14 v3] x86/rtc: provide mediated access to RTC for PVH dom0 > > > > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > > code paths (guest_io_{write/read}), but those accesses where never > > implemented for PVHv2 dom0. This patch provides such mediated accesses > > to the RTC for PVH dom0, just like it's provided for a classic PV > > dom0. > > > > Pull out some of the RTC logic from guest_io_{read/write} into > > specific helpers that can be used by both PV and HVM guests. The > > setup of the handlers for PVH is done in rtc_init, which is already > > used to initialize the fully emulated RTC. > > > > Without this a Linux PVH dom0 will read garbage when trying to access > > the RTC, and one vCPU will be constantly looping in > > rtc_timer_do_work. > > > > Note that such issue doesn't happen on domUs because the ACPI > > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > > accesses are not emulated but rather forwarded to the physical > > hardware. > > > > No functional change expected for classic PV dom0. > > > > Signed-off-by: Roger Pau Monné > > --- > > for-4.14 reasoning: the fix is mostly isolated to PVH dom0, and as > > such the risk is very low of causing issues to other guests types, but > > without this fix one vCPU when using a Linux dom0 will be constantly > > looping over rtc_timer_do_work with 100% CPU usage, at least when > > using Linux 4.19 or newer. > > --- > > Changes since v2: > > - Move the access check into the read/write handler. > > - Allow access to the latched first RTC port by all PV guests. > > - Register the handlers for HVM native accesses if vRTC is disabled. > > > > Changes since v1: > > - Share the code with PV. > > - Add access checks to the IO ports. > > --- > > xen/arch/x86/hvm/rtc.c | 26 +++++++++++++ > > xen/arch/x86/pv/emul-priv-op.c | 30 ++------------- > > xen/arch/x86/time.c | 62 +++++++++++++++++++++++++++++++ > > xen/include/asm-x86/mc146818rtc.h | 3 ++ > > 4 files changed, 95 insertions(+), 26 deletions(-) > > > > diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c > > index 5bbbdc0e0f..3150f5f147 100644 > > --- a/xen/arch/x86/hvm/rtc.c > > +++ b/xen/arch/x86/hvm/rtc.c > > @@ -808,12 +808,38 @@ void rtc_reset(struct domain *d) > > s->pt.source = PTSRC_isa; > > } > > > > +/* RTC mediator for HVM hardware domain. */ > > +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, > > + uint32_t *val) > > +{ > > + if ( dir == IOREQ_READ ) > > + *val = ~0; > > + > > + if ( size != 1 ) > > + { > > + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); > > + return X86EMUL_OKAY; > > + } > > + > > + if ( dir == IOREQ_WRITE ) > > + rtc_guest_write(port, *val); > > + else > > + *val = rtc_guest_read(port); > > + > > + return X86EMUL_OKAY; > > +} > > + > > void rtc_init(struct domain *d) > > { > > RTCState *s = domain_vrtc(d); > > > > if ( !has_vrtc(d) ) > > + { > > + if ( is_hardware_domain(d) ) > > + /* Hardware domain gets mediated access to the physical RTC. */ > > + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); > > return; > > + } > > > > spin_lock_init(&s->lock); > > > > diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c > > index fad6c754ad..2cedaab6b9 100644 > > --- a/xen/arch/x86/pv/emul-priv-op.c > > +++ b/xen/arch/x86/pv/emul-priv-op.c > > @@ -280,19 +280,9 @@ static uint32_t guest_io_read(unsigned int port, unsigned int bytes, > > { > > sub_data = pv_pit_handler(port, 0, 0); > > } > > - else if ( port == RTC_PORT(0) ) > > + else if ( (port == RTC_PORT(0) || port == RTC_PORT(1)) ) > > { > > - sub_data = currd->arch.cmos_idx; > > - } > > - else if ( (port == RTC_PORT(1)) && > > - ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) > > - { > > - unsigned long flags; > > - > > - spin_lock_irqsave(&rtc_lock, flags); > > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > > - sub_data = inb(RTC_PORT(1)); > > - spin_unlock_irqrestore(&rtc_lock, flags); > > + sub_data = rtc_guest_read(port); > > } > > else if ( (port == 0xcf8) && (bytes == 4) ) > > { > > @@ -413,21 +403,9 @@ static void guest_io_write(unsigned int port, unsigned int bytes, > > { > > pv_pit_handler(port, (uint8_t)data, 1); > > } > > - else if ( port == RTC_PORT(0) ) > > - { > > - currd->arch.cmos_idx = data; > > - } > > - else if ( (port == RTC_PORT(1)) && > > - ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) > > + else if ( (port == RTC_PORT(0) || port == RTC_PORT(1)) ) > > { > > - unsigned long flags; > > - > > - if ( pv_rtc_handler ) > > - pv_rtc_handler(currd->arch.cmos_idx & 0x7f, data); > > - spin_lock_irqsave(&rtc_lock, flags); > > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > > - outb(data, RTC_PORT(1)); > > - spin_unlock_irqrestore(&rtc_lock, flags); > > + rtc_guest_write(port, data); > > } > > else if ( (port == 0xcf8) && (bytes == 4) ) > > { > > diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c > > index bbaea3aa65..9863108f41 100644 > > --- a/xen/arch/x86/time.c > > +++ b/xen/arch/x86/time.c > > @@ -27,6 +27,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -1110,6 +1111,67 @@ static unsigned long get_cmos_time(void) > > return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); > > } > > > > +/* Helpers for guest accesses to the physical RTC. */ > > +unsigned int rtc_guest_read(unsigned int port) > > +{ > > + const struct domain *currd = current->domain; > > + unsigned long flags; > > + unsigned int data = ~0; > > + > > + switch ( port ) > > + { > > + case RTC_PORT(0): > > + /* > > + * All PV domains are allowed to read the latched value of the first > > + * RTC port. This is useful in order to store data when debugging. > > + */ > > Is this comment correct. AFAICT your call to register_portio_handler() would allow a PVH dom0 to access this too. Oh, maybe this is not clear enough. Yes, PV/PVH dom0 will get access to both ports, but a PV domU will also get read/write access to the latched value in the first RTC port, even when it doesn't have access to the second RTC port. Note that PVH domU however don't get access to such latched value at all. This was requested by Jan in order to keep the previous behavior, that allows a domU to access the latched RTC_PORT(0) value which is helpful for debugging purposes. > > + data = currd->arch.cmos_idx; > > + break; > > + > > + case RTC_PORT(1): > > + if ( !ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) > > Why RTC_PORT(0) (and not RC_PORT(1)) as base here? Guest accesses to RTC_PORT(0) don't really translate into Xen accessing the RTC_PORT(0), they just latch the guest value in d->arch.cmos_idx. OTOH Accesses to RTC_PORT(1) do translate into accesses to the physical ports RTC_PORT(0) and RTC_PORT(1), so hence the check performed here. Just checking for RTC_PORT(1) won't be fully correct, because the code accesses both RTC_PORT(0) and RTC_PORT(1). In practice I don't expect a domain to be given access just to RTC_PORT(1). Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:47:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:47:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGFC-0003X2-2d; Mon, 08 Jun 2020 11:47:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGFA-0003Wm-EH for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:47:08 +0000 X-Inumbo-ID: c7c4851c-a97d-11ea-b267-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c7c4851c-a97d-11ea-b267-12813bfff9fa; Mon, 08 Jun 2020 11:47:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IiPA5ifNKWi7WWEbpu/wWX2iSY4/P0Pnbn9+p2K+u9w=; b=LBKOnWxyRIlLtjezVls+xqO7j 50WyuOvy1cUbWcwIiTmmCveQPA90JPvyXk9pyZCSOr7gZZIdHNvAfjHKeJvzONlCjhek9F2FQKEMi gsGhQIYoAV8XLV9ggD1+SCFUKPPdJMv3m+QKUhSLpWDuKnsBRRfjBBrhIO/mGpE4fgUO0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGF9-0004tW-77; Mon, 08 Jun 2020 11:47:07 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiGF8-0002k6-Pf; Mon, 08 Jun 2020 11:47:06 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiGF8-0004gL-P8; Mon, 08 Jun 2020 11:47:06 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150922: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=75131ad75bb3c91717b5dfda6881e61c52bfd22e X-Osstest-Versions-That: xen=51ca66c37371b10b378513af126646de22eddb17 From: osstest service owner Date: Mon, 08 Jun 2020 11:47:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150922 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150922/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 75131ad75bb3c91717b5dfda6881e61c52bfd22e baseline version: xen 51ca66c37371b10b378513af126646de22eddb17 Last test of basis 150867 2020-06-05 17:00:42 Z 2 days Testing same since 150922 2020-06-08 09:02:44 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Jan Beulich Julien Grall jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 51ca66c373..75131ad75b 75131ad75bb3c91717b5dfda6881e61c52bfd22e -> smoke From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:47:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:47:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGFY-0003bm-F0; Mon, 08 Jun 2020 11:47:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGFW-0003bQ-Ex for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:47:30 +0000 X-Inumbo-ID: d49df4ee-a97d-11ea-ba62-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d49df4ee-a97d-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 11:47:29 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0F67CAB8F; Mon, 8 Jun 2020 11:47:32 +0000 (UTC) Subject: Re: [PATCH for-4.14 v3] x86/rtc: provide mediated access to RTC for PVH dom0 To: Roger Pau Monne References: <20200608102948.7327-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: <71e0d073-165b-8fcc-62b9-3fb028b3c526@suse.com> Date: Mon, 8 Jun 2020 13:47:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200608102948.7327-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 12:29, Roger Pau Monne wrote: > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > code paths (guest_io_{write/read}), but those accesses where never > implemented for PVHv2 dom0. This patch provides such mediated accesses > to the RTC for PVH dom0, just like it's provided for a classic PV > dom0. > > Pull out some of the RTC logic from guest_io_{read/write} into > specific helpers that can be used by both PV and HVM guests. The > setup of the handlers for PVH is done in rtc_init, which is already > used to initialize the fully emulated RTC. > > Without this a Linux PVH dom0 will read garbage when trying to access > the RTC, and one vCPU will be constantly looping in > rtc_timer_do_work. > > Note that such issue doesn't happen on domUs because the ACPI > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > accesses are not emulated but rather forwarded to the physical > hardware. > > No functional change expected for classic PV dom0. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich preferably with ... > @@ -1110,6 +1111,67 @@ static unsigned long get_cmos_time(void) > return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); > } > > +/* Helpers for guest accesses to the physical RTC. */ > +unsigned int rtc_guest_read(unsigned int port) > +{ > + const struct domain *currd = current->domain; > + unsigned long flags; > + unsigned int data = ~0; > + > + switch ( port ) > + { > + case RTC_PORT(0): > + /* > + * All PV domains are allowed to read the latched value of the first > + * RTC port. This is useful in order to store data when debugging. > + */ ... at least the 2nd sentence of this and ... > +void rtc_guest_write(unsigned int port, unsigned int data) > +{ > + struct domain *currd = current->domain; > + unsigned long flags; > + > + switch ( port ) > + { > + case RTC_PORT(0): > + /* > + * All PV domains are allowed to write to the latched value of the > + * first RTC port. This is useful in order to store data when > + * debugging. > + */ ... this comment dropped again. This justification of the possible usefulness is my very private guessing. Just like the original code was, I think we could leave this uncommented altogether. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:49:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:49:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGH0-0003mu-QP; Mon, 08 Jun 2020 11:49:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGH0-0003mo-Cy for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:49:02 +0000 X-Inumbo-ID: 0b59c526-a97e-11ea-b267-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0b59c526-a97e-11ea-b267-12813bfff9fa; Mon, 08 Jun 2020 11:49:01 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: jx8S19pF7gU8RSm153OO0r/y3tfvB6qlydoqpiSNfHBxxKkgIH5Ff1alKlnvKqAYj4JASJUqI8 095jNkh/T8xk5FGgwhRy8Xbag6lx3moPBQO9twauYo1Vcd9Ti6ZH3zWv+sQ6TyA5ck1w4C6hgk W03OesQT+CBzdBCjhYWTracFMP0EIbncUzVm6YAg2pBHfAhMKVaj1eW1wPdWFfkTU8jPSADfS1 1IhI9CbB80lL2cTn9O29Hlu7U90kqgNz59Du4Nt+MQHtkGRHNUDPj4hLKjbxKAMfCFbIuVcAiZ y5g= X-SBRS: 2.7 X-MesageID: 19464245 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19464245" From: George Dunlap To: Ian Jackson Subject: Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile Thread-Topic: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile Thread-Index: AQHWM6tS08XNp9FsPk2dfrAVrD4GiajIlOUAgAXuyACAAAkKgA== Date: Mon, 8 Jun 2020 11:48:57 +0000 Message-ID: <498E613F-D801-497B-BA2C-2F9E52515D02@citrix.com> References: <20200526221612.900922-1-george.dunlap@citrix.com> <20200526221612.900922-2-george.dunlap@citrix.com> <5CF4AE1D-C80C-4E4C-B4AA-0779E7DC53E7@citrix.com> <24286.7700.36742.982395@mariner.uk.xensource.com> In-Reply-To: <24286.7700.36742.982395@mariner.uk.xensource.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <9D09727B326FD44B923C260B1DEC64C1@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , xen-devel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gSnVuIDgsIDIwMjAsIGF0IDEyOjE2IFBNLCBJYW4gSmFja3NvbiA8aWFuLmphY2tz b25AY2l0cml4LmNvbT4gd3JvdGU6DQo+IA0KPiBHZW9yZ2UgRHVubGFwIHdyaXRlcyAoIlJlOiBb UEFUQ0ggdjIgMS81XSBsaWJ4bDogR2VuZXJhdGUgZ29sYW5nIGJpbmRpbmdzIGluIGxpYnhsIE1h a2VmaWxlIik6DQo+PiAQU28gYXMgd3JpdHRlbiB0aGlzIHR1cm5zIG91dCBub3QgdG8gd29yayBj b3JyZWN0bHk6ICBgZ2VuZ290eXBlcy5weWAgc3BpdHMgb3V0IHN5bnRhY3RpY2FsbHkgdmFsaWQg YnV0IHVuZm9ybWF0dGVkIEdvIGNvZGUsIGFuZCB0aGVuIHJ1bnMgYGdvIGZtdGAgb24gaXQgdG8g Z2V0IHRoZSByaWdodCBzdHlsZSAoaW5jbHVkaW5nIHRhYnMsICZjKS4gIEJ1dCB0aGUgZXJyb3Ig Y29kZSBvZiBgZ28gZm10YCBpc27igJl0IGNoZWNrZWQ7IHNvIG9uIGEgc3lzdGVtIHdpdGhvdXQg Z28gaW5zdGFsbGVkLCBpZiB0aGUgYnVpbGQgc3lzdGVtIGRlY2lkZXMgaXQgbmVlZHMgdG8gcmUt cnVuIGBnZW5nb3R5cGVzLnB5YCBmb3Igd2hhdGV2ZXIgcmVhc29uLCB0aGUgYnVpbGQgc3VjY2Vl ZHMgYnV0IHRoZSB0cmVlIGVuZHMgdXAg4oCcZGlydGllZOKAnSB3aXRoIGFuIHVuZm9ybWF0dGVk IHZlcnNpb24gZm8gdGhlIGdlbmVyYXRlZCB0ZXh0Lg0KPiANCj4gQW5kIGBnbyBmbXQnIG92ZXJ3 cml0ZXMgaXRzIGlucHV0IGZpbGUgPw0KDQpZZXMuDQoNCj4gVGhlIGxvc3QgZXJyb3IgaXMgZHVl IHRvIHVzaW5nIGBvcy5zeXN0ZW0nIHdoaWNoIGRvZXMgbm90IHJhaXNlIGFuDQo+IGV4Y2VwdGlv bi4gIFRoZSBweXRob24gMyBkb2NzIGZvciBgb3Muc3lzdGVtJyBzYXkNCj4gIHwgVGhlIHN1YnBy b2Nlc3MgbW9kdWxlIHByb3ZpZGVzIG1vcmUgcG93ZXJmdWwgZmFjaWxpdGllcyBmb3INCj4gIHwg c3Bhd25pbmcgbmV3IHByb2Nlc3NlcyBhbmQgcmV0cmlldmluZyB0aGVpciByZXN1bHRzOyB1c2lu ZyB0aGF0DQo+ICB8IG1vZHVsZSBpcyBwcmVmZXJhYmxlIHRvIHVzaW5nIHRoaXMgZnVuY3Rpb24u IFNlZSB0aGUgUmVwbGFjaW5nDQo+ICB8IE9sZGVyIEZ1bmN0aW9ucyB3aXRoIHRoZSBzdWJwcm9j ZXNzIE1vZHVsZSBzZWN0aW9uIGluIHRoZQ0KPiAgfCBzdWJwcm9jZXNzIGRvY3VtZW50YXRpb24g Zm9yIHNvbWUgaGVscGZ1bCByZWNpcGVzLg0KPiBBbmQgdGhlIHJlY2lwZSBzdWdnZXN0cw0KPiAg fCBzdHMgPSBvcy5zeXN0ZW0oIm15Y21kIiArICIgbXlhcmciKQ0KPiAgfCAjIGJlY29tZXMNCj4g IHwgc3RzID0gY2FsbCgibXljbWQiICsgIiBteWFyZyIsIHNoZWxsPVRydWUpDQo+ICB8IE5vdGVz Og0KPiAgfCAqIENhbGxpbmcgdGhlIHByb2dyYW0gdGhyb3VnaCB0aGUgc2hlbGwgaXMgdXN1YWxs eSBub3QgcmVxdWlyZWQuDQo+IA0KPiBUaGlzIGlzIG5vdCBwYXJ0aWN1bGFybHkgaGVscGZ1bCBh ZHZpY2UgYmVjYXVzZSBzdWJwcm9jZXNzLmNhbGwsIGxpa2UNCj4gb3Muc3lzdGVtLCBkb2VzIG5v dCByYWlzZSBhbiBleGNlcHRpb24gd2hlbiB0aGluZ3MgZ28gd3JvbmcuICBCdXQgaXQNCj4gZG9l cyBoYXZlIGEgIm1vcmUgcmVhbGlzdGljIGV4YW1wbGUiIGltbWVkaWF0ZWx5IGFmdGVyd2FyZHMg d2hpY2ggZG9lcw0KPiBhY3R1YWxseSBjaGVjayB0aGUgZXJyb3IgY29kZS4NCj4gDQo+IFlvdSB3 YW50ZWQgc3VicHJvY2Vzcy5jaGVja19jYWxsLiAgSURLIHdoaWNoIFB5dGhvbiB2ZXJzaW9ucyBo YXZlDQo+IHN1YnByb2Nlc3MuY2hlY2tfY2FsbC4NCg0KU2luY2UgdGhlIGdvbGFuZyBjb2RlIGdl bmVyYXRpb24gcmVjaXBlIGlzIG5vdyBjYWxsZWQgZnJvbSBsaWJ4bC9NYWtlZmlsZSB1bmNvbmRp dGlvbmFsbHksIHRoZSBlZmZlY3Qgb2Yg4oCcZml4aW5n4oCdIHRoZSBgZ28gZm10YCBjYWxsIGlu IGdlbmdvdHlwZXMucHkgdG8gZmFpbCBpZiBgZ28gZm10YCBpcyBub3QgYXZhaWxhYmxlIHdpbGwg YmUgdG8gbWFrZSBnb2xhbmcgYSByZXF1aXJlZCBkZXBlbmRlbmN5IGZvciBidWlsZGluZyB0aGUg dG9vbHMuICBJIHRoaW5rIGl04oCZcyByYXRoZXIgbGF0ZSBpbiB0aGUgZGF5IHRvIGJlIGRpc2N1 c3NpbmcgdGhhdCBmb3IgNC4xNC4NCg0KTmljayBoYXMgYWxyZWFkeSBzdWJtaXR0ZWQgYSBwYXRj aCB3aGljaCBzaW1wbHkgcmVtb3ZlcyB0aGUgYGdvIGZtdGAgY2FsbCwgbGVhdmluZyB0aGUgZ2Vu ZXJhdGVkIGNvZGUgbG9va2luZyB2ZXJ5IOKAnGdlbmVyYXRlZOKAnS4gIFRoYXQgd2lsbCBkbyBm b3IgdGhpcyByZWxlYXNlLg0KDQogLUdlb3JnZQ== From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:50:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:50:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGHy-0003ys-3l; Mon, 08 Jun 2020 11:50:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGHx-0003sa-2F for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:50:01 +0000 X-Inumbo-ID: 2e7d525c-a97e-11ea-96fb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2e7d525c-a97e-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 11:50:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 05BA7AB8F; Mon, 8 Jun 2020 11:50:02 +0000 (UTC) Subject: Re: [PATCH for-4.14 v3] x86/rtc: provide mediated access to RTC for PVH dom0 To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , paul@xen.org References: <20200608102948.7327-1-roger.pau@citrix.com> <002c01d63d85$ba36da30$2ea48e90$@xen.org> <20200608114552.GA722@Air-de-Roger> From: Jan Beulich Message-ID: <92c68cd3-a3c2-f46a-00cd-235b06a62e9b@suse.com> Date: Mon, 8 Jun 2020 13:49:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200608114552.GA722@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Wei Liu' , 'Andrew Cooper' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 13:45, Roger Pau Monné wrote: > On Mon, Jun 08, 2020 at 12:12:40PM +0100, Paul Durrant wrote: >>> From: Roger Pau Monne >>> Sent: 08 June 2020 11:30 >>> >>> @@ -1110,6 +1111,67 @@ static unsigned long get_cmos_time(void) >>> return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); >>> } >>> >>> +/* Helpers for guest accesses to the physical RTC. */ >>> +unsigned int rtc_guest_read(unsigned int port) >>> +{ >>> + const struct domain *currd = current->domain; >>> + unsigned long flags; >>> + unsigned int data = ~0; >>> + >>> + switch ( port ) >>> + { >>> + case RTC_PORT(0): >>> + /* >>> + * All PV domains are allowed to read the latched value of the first >>> + * RTC port. This is useful in order to store data when debugging. >>> + */ >> >> Is this comment correct. AFAICT your call to register_portio_handler() would allow a PVH dom0 to access this too. > > Oh, maybe this is not clear enough. Yes, PV/PVH dom0 will get access > to both ports, but a PV domU will also get read/write access to the > latched value in the first RTC port, even when it doesn't have access > to the second RTC port. I'd word this slightly differently: "..., even when it doesn't have access to either physical RTC port." Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 11:54:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 11:54:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGM9-0004io-M3; Mon, 08 Jun 2020 11:54:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGM8-0004ij-QA for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 11:54:20 +0000 X-Inumbo-ID: c5e500e0-a97e-11ea-9ad7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c5e500e0-a97e-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 11:54:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9dGfcEzVeIDN7fJaEVu11scxEbeKk8m+L5tRxJzNOsY=; b=UUcob+HTDHTjTsihf87bA+5fx OAGlId0DSWi24O7SxWuwP35DjB1Jtl17bJZOIeQjB2R3FMnHH/5s0hO0vzM3lMKzDRC0COLNrSjaB h9nfR9v6ZLHotr/c6KuFKqfHN1D3EqNR1871dZTeNZQVK7eopU8bdUdpbBqURMwRRZxp0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGM1-00052p-7v; Mon, 08 Jun 2020 11:54:13 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiGM0-0003CD-Tn; Mon, 08 Jun 2020 11:54:12 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiGM0-00084k-T6; Mon, 08 Jun 2020 11:54:12 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150916: regressions - FAIL X-Osstest-Failures: qemu-mainline:build-amd64-xsm:xen-build:fail:regression qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate:fail:heisenbug qemu-mainline:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: qemuu=175198ad91d8bac540159705873b4ffe4fb94eab X-Osstest-Versions-That: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e From: osstest service owner Date: Mon, 08 Jun 2020 11:54:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150916 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150916/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-build fail in 150909 REGR. vs. 150694 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 150909 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-xsm 1 build-check(1) blocked in 150909 n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked in 150909 n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 150909 n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked in 150909 n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked in 150909 n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked in 150909 n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 150909 n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked in 150909 n/a test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 150909 like 150694 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150694 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150694 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150694 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuu 175198ad91d8bac540159705873b4ffe4fb94eab baseline version: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e Last test of basis 150694 2020-06-04 11:44:20 Z 4 days Failing since 150831 2020-06-05 13:06:20 Z 2 days 7 attempts Testing same since 150872 2020-06-05 22:39:31 Z 2 days 6 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Bulekov Christian Borntraeger Cornelia Huck Gerd Hoffmann Janosch Frank Jared Rossi Kevin Wolf Paolo Bonzini Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Stefan Hajnoczi Stefano Garzarella Thomas Huth Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 447 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 08 12:33:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 12:33:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGy0-00089Q-61; Mon, 08 Jun 2020 12:33:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiGxz-00089L-16 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 12:33:27 +0000 X-Inumbo-ID: 3f98c2d2-a984-11ea-96fb-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3f98c2d2-a984-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 12:33:26 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id y13so18095614eju.2 for ; Mon, 08 Jun 2020 05:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M70e72UCuxkCW4wbSfecZcBgKmPhNTcBwAXxM5ZKJVw=; b=b1SPYhIWbq6L1x48hOz0xLwx5Ys1QstrHafH2c9TjA1E6s9/RPLagwvArmFyd8osct ZlDAnf7Dj1HNBjtNJMxE3HHRJrbFNZp+W0hqQRs4JnyyL4RCJSxjOuXCpvhjJhl2cL5k eUq0tCRx+uwRSfoINH3chhKeEdErrZKym1OrF5ts73P/w1h8KClh4jYFmUTtlieaAWZu NX5nhpRRK3yy/X8k5Nt24Fms7dOPMLV/4pTGSSeOTki0/BZp4RqvzalnHYhyCM0on+5c /J0M8ixD55kmvtrBttFORkpruNtitme1OGVfBnjZMW3PNZlhzepExSBZ/M1ITonDMRKE wWrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M70e72UCuxkCW4wbSfecZcBgKmPhNTcBwAXxM5ZKJVw=; b=bleyh55dgpRYa+5LS0XN+mtNzyljm1QXRHW/jx6yVYPN/7nIq/p1OeyZNlZq8Op9EF AjC4ZxfHOG4YQ8NVEUZ+mRFMLgbmsnoJ9xuFl6jDe4lmjDT0gmRBFGgIk/weK7+3o+Cg YG1KrNauTgWWp8Kfn2iyWdrxdTWCZtRRf26vmoDImo91yS13a4J81ftHy5V7pHIGuFK9 vfK8T6u6/FB8meHkslLgcJm20iXZR6vHiIrwzB/bgsKDgXTuflx6qGOlkd2MOe5B/y5w wqL51ko7sg+KxQV8AX31EUsJCr5l5wixoZ3EGao2RdP6ItOMSUgqApchXDllmQnLXtl2 u6hA== X-Gm-Message-State: AOAM532gYMQPJ/qDBmopUTj7Gz52s/H34NHlqcFyFJjxoc2tVhnSHJJL bm6s5yZ2B85/5nWdZ4lIY+T2LZXd/aqblF1FrqZ4y9cf X-Google-Smtp-Source: ABdhPJyWvZlyJQravMnlR+nb313WS7nccHlMrboOPQ1e+mgIurZ+Qwescx0YJqjTdkbGXiQKYwA99XGjmNKMVZv8qlg= X-Received: by 2002:a17:906:5785:: with SMTP id k5mr20139782ejq.494.1591619605187; Mon, 08 Jun 2020 05:33:25 -0700 (PDT) MIME-Version: 1.0 References: <25953300-f69d-19a4-9215-49cfedbd16ed@xen.org> <8C39F9D0-8351-4671-9A39-D5D4BFF02BD6@arm.com> <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> In-Reply-To: <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> From: CodeWiz2280 Date: Mon, 8 Jun 2020 08:33:12 -0400 Message-ID: Subject: Re: Keystone Issue To: Bertrand Marquis Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" It actually shows only 1 interrupt for any of the devices in that list (e.g. spi, ttyS0, ethernet) so you're probably right on the money with it being an interrupt acknowledge issue. Any help you can provide is greatly appreciated. On Mon, Jun 8, 2020 at 4:40 AM Bertrand Marquis wrote: > > > > > On 5 Jun 2020, at 20:12, CodeWiz2280 wrote: > > > > On Fri, Jun 5, 2020 at 11:05 AM CodeWiz2280 wrote: > >> > >> On Fri, Jun 5, 2020 at 8:47 AM Bertrand Marquis > >> wrote: > >>> > >>> > >>> > >>>> On 5 Jun 2020, at 13:42, CodeWiz2280 wrote: > >>>> > >>>> On Fri, Jun 5, 2020 at 8:30 AM Julien Grall wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> On 05/06/2020 13:25, CodeWiz2280 wrote: > >>>>>> The Keystone uses the netcp driver, which has interrupts from 40-79 > >>>>>> listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). > >>>>>> I'm using the same device tree between my non-xen standalone kernel > >>>>>> and my dom0 kernel booted by xen. In the standalone (non-xen) kernel > >>>>>> the ethernet works fine, but I don't see any of its interrupts in the > >>>>>> output of /proc/iomem. I'm not seeing them in /proc/iomem when > >>>>>> running dom0 under Xen either. When booting with Xen I get this > >>>>>> behavior where the ifconfig output shows 1 RX message and 1 TX > >>>>>> message, and then nothing else. > >>>>> > >>>>> I am not sure whether this is a typo in the e-mail. /proc/iomem is > >>>>> listing the list of the MMIO regions. You want to use /proc/interrupts. > >>>>> > >>>>> Can you confirm which path you are dumping? > >>>> Yes, that was a typo. Sorry about that. I meant that I am dumping > >>>> /proc/interrupts and do not > >>>> see them under the non-xen kernel or xen booted dom0. > >>> > >>> Could you post both /proc/interrupts content ? > >> > >> Standalone non-xen kernel (Ethernet works) > >> # cat /proc/interrupts > >> CPU0 CPU1 CPU2 CPU3 > >> 17: 0 0 0 0 GICv2 29 Level > >> arch_timer > >> 18: 9856 1202 457 650 GICv2 30 Level > >> arch_timer > >> 21: 0 0 0 0 GICv2 142 Edge > >> timer-keystone > >> 22: 0 0 0 0 GICv2 52 Edge arm-pmu > >> 23: 0 0 0 0 GICv2 53 Edge arm-pmu > >> 24: 0 0 0 0 GICv2 54 Edge arm-pmu > >> 25: 0 0 0 0 GICv2 55 Edge arm-pmu > >> 26: 0 0 0 0 GICv2 36 Edge > >> 26202a0.keystone_irq > >> 27: 1435 0 0 0 GICv2 309 Edge ttyS0 > >> 29: 0 0 0 0 GICv2 315 Edge > >> 2530000.i2c > >> 30: 1 0 0 0 GICv2 318 Edge > >> 2530400.i2c > >> 31: 0 0 0 0 GICv2 321 Edge > >> 2530800.i2c > >> 32: 69 0 0 0 GICv2 324 Edge > >> 21000400.spi > >> 33: 0 0 0 0 GICv2 328 Edge > >> 21000600.spi > >> 34: 0 0 0 0 GICv2 332 Edge > >> 21000800.spi > >> 70: 0 0 0 0 GICv2 417 Edge > >> ks-pcie-error-irq > >> 79: 0 0 0 0 PCI-MSI 0 Edge > >> PCIe PME, aerdrv > >> 88: 57 0 0 0 GICv2 80 Level > >> hwqueue-528 > >> 89: 57 0 0 0 GICv2 81 Level > >> hwqueue-529 > >> 90: 47 0 0 0 GICv2 82 Level > >> hwqueue-530 > >> 91: 41 0 0 0 GICv2 83 Level > >> hwqueue-531 > >> IPI0: 0 0 0 0 CPU wakeup interrupts > >> IPI1: 0 0 0 0 Timer broadcast interrupts > >> IPI2: 730 988 1058 937 Rescheduling interrupts > >> IPI3: 2 3 4 6 Function call interrupts > >> IPI4: 0 0 0 0 CPU stop interrupts > >> IPI5: 0 0 0 0 IRQ work interrupts > >> IPI6: 0 0 0 0 completion interrupts > >> > >> Xen dom0 (Ethernet stops) > >> # cat /proc/interrupts > >> CPU0 > >> 18: 10380 GIC-0 27 Level arch_timer > >> 19: 0 GIC-0 142 Edge timer-keystone > >> 20: 88 GIC-0 16 Level events > >> 21: 0 xen-dyn Edge -event xenbus > >> 22: 0 GIC-0 36 Edge 26202a0.keystone_irq > >> 23: 1 GIC-0 312 Edge ttyS0 > >> 25: 1 GIC-0 318 Edge > >> 27: 1 GIC-0 324 Edge 21000400.spi > >> 28: 0 GIC-0 328 Edge 21000600.spi > >> 29: 0 GIC-0 332 Edge 21000800.spi > >> 65: 0 GIC-0 417 Edge ks-pcie-error-irq > >> 74: 0 PCI-MSI 0 Edge PCIe PME, aerdrv > >> 83: 1 GIC-0 80 Level hwqueue-528 > >> 84: 1 GIC-0 81 Level hwqueue-529 > >> 85: 1 GIC-0 82 Level hwqueue-530 > >> 86: 1 GIC-0 83 Level hwqueue-531 > >> 115: 87 xen-dyn Edge -virq hvc_console > >> IPI0: 0 CPU wakeup interrupts > >> IPI1: 0 Timer broadcast interrupts > >> IPI2: 0 Rescheduling interrupts > >> IPI3: 0 Function call interrupts > >> IPI4: 0 CPU stop interrupts > >> IPI5: 0 IRQ work interrupts > >> IPI6: 0 completion interrupts > >> Err: 0 > > After getting a chance to look at this a little more, I believe the > > TX/RX interrupts for the ethernets map like this: > > > > eth0 Rx - hwqueue-528 > > eth1 Rx - hwqueue-529 > > eth0 Tx - hwqueue-530 > > eth1 Tx - hwqueue-531 > >> > > The interrupt counts in the standlone working kernel seem to roughly > > correspond to the counts of Tx/Rx messages in ifconfig. Going on > > that, its clear that only 1 interrupt has been received for Tx and 1 > > for Rx in the Xen Dom0 equivalent. Any thoughts on this? > > This definitely look like an interrupt acknowledgement issue. > This could be caused by 2 things I remember of: > - front vs level interrupts > - a problem with forwarded interrupt acknowledgement. > I think there was something related to that where the vcpu ack was not properly > handled on a keystone and I had to change the way the interrupt was acked for > forwarded hardware interrupts. > > I will try to get more info on that one as I have no access to the code anymore. > > Regards > Bertrand > > > > > From xen-devel-bounces@lists.xenproject.org Mon Jun 08 12:38:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 12:38:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiH2V-0008K3-N8; Mon, 08 Jun 2020 12:38:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiH2U-0008IR-6U for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 12:38:06 +0000 X-Inumbo-ID: e61c169a-a984-11ea-9b55-bc764e2007e4 Received: from mail-wm1-x329.google.com (unknown [2a00:1450:4864:20::329]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e61c169a-a984-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 12:38:05 +0000 (UTC) Received: by mail-wm1-x329.google.com with SMTP id q25so16371116wmj.0 for ; Mon, 08 Jun 2020 05:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=zCgU3fmaIy0D8xnCIG/NmFK7Ce5D0Tpz/4j3owSjbyk=; b=sIBykx6S4modYxFOsMMKHUIhkpK9rtkZswSa9CBeJslKhK9HhKgzqVtT/s5vJdR/oH JSmANFx/GYFypZVq1aEHkGdLlBMLo322kD2xSwygdm1x6nzjk3W/44fPFmh70Y+hY/U/ SQ65RbfeUFS5DIeWYdaj2o3+fX7ihFnYfgARuTsbHxvepwnYbOU0L8jYgFqjC8ePYoLw kpSb747vR1EJOxqZG0l9N422Ekbk0bR99OhhwEXmcbMuq3cmjtia6da8Wk2sJxWYbRTL 8Mm2hQdFlUpyaW8V9dWRTBp9Q0CPrsTCrp52XQrkZ0Elmak/y9TEzOMdzXhGesfO/bEu 96Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=zCgU3fmaIy0D8xnCIG/NmFK7Ce5D0Tpz/4j3owSjbyk=; b=t2SgLbXun+SGI8o0PF+XcL9HHzaEQdEQqgp+aUF3LHnDbgiXBYrHRB7++ylHa4B5R+ IkNbGayM4EjYRIluU367dN/4SkcvJVQhJiG16FC9CCbAHNmyeg+TjUnFHLo0ebPd+sB/ +Go62ClKnz43oocyuXXPJJAuL9plo35BuUBJF8/DiUjvSew9vnmEM8uCXtSViE2Is5/M WMH1De79VDZQAPdglg1Ce5Bd/xb3DylrcMEIEAVO9Qj/XINdpAp+/6KMnK4z/dM7b7Ay SXTdSEwlb2jT9YjimawQGAOvSJ7Nh++2I9wUEXdxtYRUvlLugYgBR2oQS3s866ldVqIR OAlw== X-Gm-Message-State: AOAM532ne7Vv1evjh4HMikBWWGWhNOR4a9XCLggNTGRbcquwwXDiLqUg RCvAxGSqA55yicEoux28VS8= X-Google-Smtp-Source: ABdhPJx4RCujE+nx9NPL3mVh8+Rz6bRXeyvpYdrwCBWmBlfIjWyXDus+NNULhHvIM6GH8dDEFDNIeQ== X-Received: by 2002:a1c:451:: with SMTP id 78mr17231300wme.83.1591619884563; Mon, 08 Jun 2020 05:38:04 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id o6sm23317896wrp.3.2020.06.08.05.38.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 05:38:03 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= , "'Jan Beulich'" , =?utf-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= , "'Ian Jackson'" References: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <002001d63b3e$7c268a40$74739ec0$@xen.org> <002e01d63b4f$914b3a90$b3e1afb0$@xen.org> <20200605161804.GJ98582@mail-itl> <002701d63d75$6363a130$2a2ae390$@xen.org> <3811b700-7bd7-859a-2c84-a9885acf64a1@suse.com> In-Reply-To: <3811b700-7bd7-859a-2c84-a9885acf64a1@suse.com> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Mon, 8 Jun 2020 13:38:02 +0100 Message-ID: <002e01d63d91$a701e5c0$f505b140$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQCJ30jDNcpaWIG0GDXmJ4sF0URUNgF7hKHXArBYEOQB4r0ScAFGccUAApWxmk4BPtBDbAHi/U0vAkOVa4cCoqFkNAIjoGbrAeOG1z8COvfc/AHOrDeGqpdGj/A= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: J=C3=BCrgen Gro=C3=9F > Sent: 08 June 2020 10:25 > To: paul@xen.org; 'Jan Beulich' ; 'Marek = Marczykowski-G=C3=B3recki' > ; 'Ian Jackson' = > Cc: 'Andrew Cooper' ; 'xen-devel' = > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On 08.06.20 11:15, Paul Durrant wrote: > >> -----Original Message----- > >> From: Jan Beulich > >> Sent: 08 June 2020 09:14 > >> To: 'Marek Marczykowski-G=C3=B3recki' = ; paul@xen.org > >> Cc: 'Andrew Cooper' ; 'xen-devel' = > >> Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom > >> > >> On 05.06.2020 18:18, 'Marek Marczykowski-G=C3=B3recki' wrote: > >>> On Fri, Jun 05, 2020 at 04:39:56PM +0100, Paul Durrant wrote: > >>>>> From: Jan Beulich > >>>>> Sent: 05 June 2020 14:57 > >>>>> > >>>>> On 05.06.2020 15:37, Paul Durrant wrote: > >>>>>>> From: Jan Beulich > >>>>>>> Sent: 05 June 2020 14:32 > >>>>>>> > >>>>>>> On 05.06.2020 13:05, Paul Durrant wrote: > >>>>>>>> That would mean we wouldn't be seeing the "Unexpected PIO" = message. From that message this > >> clearly > >>>>>>> X86EMUL_UNHANDLEABLE which suggests a race with ioreq server = teardown, possibly due to > selecting > >> a > >>>>>>> server but then not finding a vcpu match in ioreq_vcpu_list. > >>>>>>> > >>>>>>> I was suspecting such, but at least the tearing down of all = servers > >>>>>>> happens only from relinquish-resources, which gets started = only > >>>>>>> after ->is_shut_down got set (unless the tool stack invoked > >>>>>>> XEN_DOMCTL_destroydomain without having observed = XEN_DOMINF_shutdown > >>>>>>> set for the domain). > >>>>>>> > >>>>>>> For individually unregistered servers - yes, if qemu did so, = this > >>>>>>> would be a problem. They need to remain registered until all = vCPU-s > >>>>>>> in the domain got paused. > >>>>>> > >>>>>> It shouldn't be a problem should it? Destroying an individual = server is only done with the > domain > >>>>> paused, so no vcpus can be running at the time. > >>>>> > >>>>> Consider the case of one getting destroyed after it has already > >>>>> returned data, but the originating vCPU didn't consume that data > >>>>> yet. Once that vCPU gets unpaused, handle_hvm_io_completion() > >>>>> won't find the matching server anymore, and hence the chain > >>>>> hvm_wait_for_io() -> hvm_io_assist() -> > >>>>> vcpu_end_shutdown_deferral() would be skipped. handle_pio() > >>>>> would then still correctly consume the result. > >>>> > >>>> True, and skipping hvm_io_assist() means the vcpu internal ioreq = state will be left set to > >> IOREQ_READY and *that* explains why we would then exit = hvmemul_do_io() with X86EMUL_UNHANDLEABLE > (from > >> the first switch). > >>> > >>> I can confirm X86EMUL_UNHANDLEABLE indeed comes from the first = switch in > >>> hvmemul_do_io(). And it happens shortly after ioreq server is = destroyed: > >>> > >>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 reason 0 > >>> (XEN) d12v0 domain 11 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 done > >>> (XEN) d12v0 hvm_destroy_ioreq_server called for 11, id 0 > >> > >> Can either of you tell why this is? As said before, qemu shouldn't > >> start tearing down ioreq servers until the domain has made it out > >> of all shutdown deferrals, and all its vCPU-s have been paused. > >> For the moment I think the proposed changes, while necessary, will > >> mask another issue elsewhere. The @releaseDomain xenstore watch, > >> being the trigger I would consider relevant here, will trigger > >> only once XEN_DOMINF_shutdown is reported set for a domain, which > >> gets derived from d->is_shut_down (i.e. not mistakenly > >> d->is_shutting_down). > > > > I can't find anything that actually calls xendevicemodel_shutdown(). = It was added by: >=20 > destroy_hvm_domain() in qemu does. >=20 Ah ok, thanks. So it looks like this should only normally be called when = the guest has written to the PIIX to request shutdown. Presumably the = hvm_destroy_ioreq_server call we see afterwards is QEMU then exiting. There is one other circumstance when destroy_hvmdomain() would be called = and that is if the ioreq state is not STATE_IOREQ_INPROCESS... in which = case there should be an accompanying error message in the qemu log. Paul >=20 > Juergen From xen-devel-bounces@lists.xenproject.org Mon Jun 08 12:44:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 12:44:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiH8H-0000jK-C7; Mon, 08 Jun 2020 12:44:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiH8G-0000jF-0j for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 12:44:04 +0000 X-Inumbo-ID: bb542078-a985-11ea-96fb-bc764e2007e4 Received: from mail-lf1-x141.google.com (unknown [2a00:1450:4864:20::141]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bb542078-a985-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 12:44:03 +0000 (UTC) Received: by mail-lf1-x141.google.com with SMTP id c21so10112791lfb.3 for ; Mon, 08 Jun 2020 05:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K1cmkpiwWtTyJU+MoXtjIgUD1hAfBA2Tmbv3Dr830FI=; b=Q/wiWVXboF5iFyb+I2r2x3x/7CsIPSGJt4tsYiGTvJY4mAV5U/4+B5E7tp/U6zDa8t WoFjcADDb9Jt9CmJt8m+3COVfLAf8nm+88k7rljPWqa9aSt4BSeQ923CMoXvFQfM544b 9gQPJYXlRH51rFYHKsxFXdjJxiH1TNEIusf6EAJfoNqyajlavKc2WuQOge7mbvtH34Ti RPW2aLYWcA5orheBUXUXP7k2for1wzIJWbWhqmV1xMcEbTVvXaABPHTXaQ0AioC5ayLX I5tSBGz7lQHEBrat6e2C3xefvyQMwSeoMR+O0wMdf8C1xV2Mo3LQ60GMWVlqDiE1cKYS XkHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K1cmkpiwWtTyJU+MoXtjIgUD1hAfBA2Tmbv3Dr830FI=; b=COwlxudS+VG2BLSVyKftGjyySUNyFn9haZNesMt3JSbirRJZckIoVzl+zy9xTNVdWc 8rzTSQyEkbLXHaFeayre3/odkDduASkoBjU2H/pCAPk9RVzlKdV06PF4t7hAyXe+qLSB uDgM7CorrIwPHfmVaCOEJm1wVsbmgq/F/IIDzqexOj6OQ42/dojeRSYOA+dcP+vJd+LF GAX/hs/6f+LQSdD117yeQ2ogkDbHhkXltbuBYCj8etbb+yBRX9puV7aR9J+nsCTDmTPO dsa2b4TqIwIK/H90gC8a2hvRFDBm1/JXYkAdUIeSvJXKquFnYJwQxJbkt7IuvC82YapJ Qs8A== X-Gm-Message-State: AOAM530WOwf9CdUpmdxgjwcDGBSaZGhLNCZdr0pvKXCmyr8jlkngObyD PuA9pGC2fHBGeRPAtWVILIbs4YToF4DfCmDtibg= X-Google-Smtp-Source: ABdhPJzGi3lv8F/kbuSYpdXDMrgtdwvxnGSD9UOAJsV3HIgYNqQGQLZXc6pxbkDJgOzERjniz13heoPcsJ8ACMnoy2I= X-Received: by 2002:a05:6512:31d1:: with SMTP id j17mr11798171lfe.148.1591620242241; Mon, 08 Jun 2020 05:44:02 -0700 (PDT) MIME-Version: 1.0 References: <20200608072855.26589-1-olaf@aepfle.de> <20200608100051.16be834e.olaf@aepfle.de> <24286.6790.983312.672969@mariner.uk.xensource.com> In-Reply-To: <24286.6790.983312.672969@mariner.uk.xensource.com> From: Jason Andryuk Date: Mon, 8 Jun 2020 08:43:50 -0400 Message-ID: Subject: Re: [PATCH v1] tools: fix usage of strncpy To: Ian Jackson Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , xen-devel , Olaf Hering , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 8, 2020 at 7:03 AM Ian Jackson wrote: > > Olaf Hering writes ("Re: [PATCH v1] tools: fix usage of strncpy"): > > Am Mon, 8 Jun 2020 09:28:54 +0200 > > schrieb Olaf Hering : > > > off-by-one error in libxl__prepare_sockaddr_un > > > > There is none, I had read the code backwards... > > I have just had the same thoughts but in the opposite order. That is > at first I thought this was not a problem, but now I think there is. > > There are some kernel interfaces where a fixed-size buffer is > provided, and the kernel will tolerate a null-terminated string, but > will in any case not read beyond the end of the buffer. Anything > involving IFNAMSIZ comes to mind. > > But I think sun_path is not one of those. The manpage I have here > says that to be portable you must null-terminate sun_path. I know > that there are some implementations where it is possible to pass a > longer path, effectively treating sun_path as a trailing vla. > > Looking at your diff, its effect seems to be to ensure > null-termination by truncating overlong paths. > > I think the right approach is to return an error, not to silently > truncate. I added a length check in this patch: https://lore.kernel.org/xen-devel/20200525024955.225415-2-jandryuk@gmail.com/ Regards, Jason From xen-devel-bounces@lists.xenproject.org Mon Jun 08 12:46:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 12:46:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHAn-0000rD-P0; Mon, 08 Jun 2020 12:46:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHAm-0000r8-EF for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 12:46:40 +0000 X-Inumbo-ID: 18a67e10-a986-11ea-9b55-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 18a67e10-a986-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 12:46:39 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 33865AB8F; Mon, 8 Jun 2020 12:46:42 +0000 (UTC) Subject: Re: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom To: paul@xen.org References: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <002001d63b3e$7c268a40$74739ec0$@xen.org> <002e01d63b4f$914b3a90$b3e1afb0$@xen.org> <20200605161804.GJ98582@mail-itl> <002701d63d75$6363a130$2a2ae390$@xen.org> <3811b700-7bd7-859a-2c84-a9885acf64a1@suse.com> <002e01d63d91$a701e5c0$f505b140$@xen.org> From: Jan Beulich Message-ID: <49232c15-513b-0ff3-040e-8f5287a84379@suse.com> Date: Mon, 8 Jun 2020 14:46:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <002e01d63d91$a701e5c0$f505b140$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?J0rDvHJnZW4gR3Jvw58n?= , 'Andrew Cooper' , 'Ian Jackson' , =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 14:38, Paul Durrant wrote: >> From: Jürgen Groß >> Sent: 08 June 2020 10:25 >> >> On 08.06.20 11:15, Paul Durrant wrote: >>>> From: Jan Beulich >>>> Sent: 08 June 2020 09:14 >>>> >>>> On 05.06.2020 18:18, 'Marek Marczykowski-Górecki' wrote: >>>>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 reason 0 >>>>> (XEN) d12v0 domain 11 domain_shutdown vcpu_id 0 defer_shutdown 1 >>>>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 done >>>>> (XEN) d12v0 hvm_destroy_ioreq_server called for 11, id 0 >>>> >>>> Can either of you tell why this is? As said before, qemu shouldn't >>>> start tearing down ioreq servers until the domain has made it out >>>> of all shutdown deferrals, and all its vCPU-s have been paused. >>>> For the moment I think the proposed changes, while necessary, will >>>> mask another issue elsewhere. The @releaseDomain xenstore watch, >>>> being the trigger I would consider relevant here, will trigger >>>> only once XEN_DOMINF_shutdown is reported set for a domain, which >>>> gets derived from d->is_shut_down (i.e. not mistakenly >>>> d->is_shutting_down). >>> >>> I can't find anything that actually calls xendevicemodel_shutdown(). It was added by: >> >> destroy_hvm_domain() in qemu does. >> > > Ah ok, thanks. So it looks like this should only normally be called when the guest has written to the PIIX to request shutdown. Presumably the hvm_destroy_ioreq_server call we see afterwards is QEMU then exiting. If a shutdown request was received, qemu should still not exit as long as there's in-flight I/O, or as long as there are CPUs running in the guest. It would seem legitimate to "cancel" in-flight I/O (and perhaps "reject" further requests arriving), but the device model needs to remain there as long as there's at least one running CPU. That's no different on "real" hardware - the machine doesn't "disappear" just because shutdown was requested. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 12:54:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 12:54:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHI4-0001iq-Hm; Mon, 08 Jun 2020 12:54:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHI2-0001il-CT for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 12:54:10 +0000 X-Inumbo-ID: 24d83452-a987-11ea-9ad7-bc764e2007e4 Received: from mail-wr1-x42e.google.com (unknown [2a00:1450:4864:20::42e]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 24d83452-a987-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 12:54:09 +0000 (UTC) Received: by mail-wr1-x42e.google.com with SMTP id j10so17276251wrw.8 for ; Mon, 08 Jun 2020 05:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=+0xqlqXt4RPTjZ0zvstONOq/N0CA6NCxcbWOsPt8x5g=; b=HCd191AV5KaijMF5mroSKr6jvuSoGadgs0bKIDHoLNN+LKrjpzjWhdoMFmXGI5BDMQ 4bHe1F9IYCR0KsXD8Ow3UJX5XSbYqqJAW8JD9rgSFDFOVoxbTasKS5f81AsWRupYfeMe GOza3WG2q51IqG59EBGy5LvkRiRVVtSOY6wYHXQcZ0MSBOZ/pVlQYbLM8Y5hXO128fRi 9PcIhxl3cYNkXLlO0OxKytga/l23VCz26vLwDzNnGJTru3IFcZKrzcivrBBC1hdcRjKY 2QBF5F/yiI1JXRWchoskqXBo1/Mtaez7n+CLgBRMws0SBCCbBScTHbDfIucybS7uOQ1e 7RlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=+0xqlqXt4RPTjZ0zvstONOq/N0CA6NCxcbWOsPt8x5g=; b=Dvu7lbQ1F/swtFNszFwQTdkaxK1fUcTmKTrhx4q1mHb2AFGDvOJXL5Nu+BEuJEZ5TK rcsQYMOL6fIJznCd26zmgemVPzNwQQ8l5d1NbWhy17GLdHZIb0D3qJ+BeJg8vCgFC5A5 pBSNb24X+gamRMau6kX5QUsG0qDoc/kh6IBrSJ1w5K5aYa9qYmqVe7CB5E83hVE7xjUO GOnJ8HdX3+3KEyRjF6D4MNh9BUGyP6v0IcMz95K8Z862vRC3n2SOJLrp9Jd1464zUX7+ fQFQVwSlI1YNMTOSZouGQ9i5iFJxNv+v5s3XyH2UGYvFny5jO0l2pdIpIyiHGRCzRx/1 DaAg== X-Gm-Message-State: AOAM532zC0asmgh+zMUiDwFU2joRMyWyjVzr5mSdfRJnofbSV3Uj2PBN 9icj/jUdZrBJ4E+TeuiUhZA= X-Google-Smtp-Source: ABdhPJz/hYPvQdqrIWfggufEYw1obuZRI/PrCNh02iOqVN4oFUUssbZ2HVsACRHJs8p0BkY2z0vhUA== X-Received: by 2002:a5d:4446:: with SMTP id x6mr22589881wrr.119.1591620848868; Mon, 08 Jun 2020 05:54:08 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id j4sm23413003wma.7.2020.06.08.05.54.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 05:54:08 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <4dcc0092-6f6d-5d63-06cb-15b2fec244db@suse.com> <20200604142542.GC98582@mail-itl> <3b4dbb2f-7a0a-29a8-cca7-0cb641e8338d@suse.com> <000501d63b29$496ce6e0$dc46b4a0$@xen.org> <002001d63b3e$7c268a40$74739ec0$@xen.org> <002e01d63b4f$914b3a90$b3e1afb0$@xen.org> <20200605161804.GJ98582@mail-itl> <002701d63d75$6363a130$2a2ae390$@xen.org> <3811b700-7bd7-859a-2c84-a9885acf64a1@suse.com> <002e01d63d91$a701e5c0$f505b140$@xen.org> <49232c15-513b-0ff3-040e-8f5287a84379@suse.com> In-Reply-To: <49232c15-513b-0ff3-040e-8f5287a84379@suse.com> Subject: RE: handle_pio looping during domain shutdown, with qemu 4.2.0 in stubdom Date: Mon, 8 Jun 2020 13:54:06 +0100 Message-ID: <003101d63d93$e5e64a90$b1b2dfb0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQCJ30jDNcpaWIG0GDXmJ4sF0URUNgF7hKHXArBYEOQB4r0ScAFGccUAApWxmk4BPtBDbAHi/U0vAkOVa4cCoqFkNAIjoGbrAeOG1z8COvfc/AHOrDeGAlXxdEUCXuBn/qpxpdJA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= , 'Andrew Cooper' , 'Ian Jackson' , =?utf-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 08 June 2020 13:47 > To: paul@xen.org > Cc: 'J=C3=BCrgen Gro=C3=9F' ; 'Marek = Marczykowski-G=C3=B3recki' ; > 'Ian Jackson' ; 'Andrew Cooper' = ; 'xen-devel' > > Subject: Re: handle_pio looping during domain shutdown, with qemu = 4.2.0 in stubdom >=20 > On 08.06.2020 14:38, Paul Durrant wrote: > >> From: J=C3=BCrgen Gro=C3=9F > >> Sent: 08 June 2020 10:25 > >> > >> On 08.06.20 11:15, Paul Durrant wrote: > >>>> From: Jan Beulich > >>>> Sent: 08 June 2020 09:14 > >>>> > >>>> On 05.06.2020 18:18, 'Marek Marczykowski-G=C3=B3recki' wrote: > >>>>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 reason 0 > >>>>> (XEN) d12v0 domain 11 domain_shutdown vcpu_id 0 defer_shutdown 1 > >>>>> (XEN) d12v0 XEN_DMOP_remote_shutdown domain 11 done > >>>>> (XEN) d12v0 hvm_destroy_ioreq_server called for 11, id 0 > >>>> > >>>> Can either of you tell why this is? As said before, qemu = shouldn't > >>>> start tearing down ioreq servers until the domain has made it out > >>>> of all shutdown deferrals, and all its vCPU-s have been paused. > >>>> For the moment I think the proposed changes, while necessary, = will > >>>> mask another issue elsewhere. The @releaseDomain xenstore watch, > >>>> being the trigger I would consider relevant here, will trigger > >>>> only once XEN_DOMINF_shutdown is reported set for a domain, which > >>>> gets derived from d->is_shut_down (i.e. not mistakenly > >>>> d->is_shutting_down). > >>> > >>> I can't find anything that actually calls = xendevicemodel_shutdown(). It was added by: > >> > >> destroy_hvm_domain() in qemu does. > >> > > > > Ah ok, thanks. So it looks like this should only normally be called = when the guest has written to > the PIIX to request shutdown. Presumably the hvm_destroy_ioreq_server = call we see afterwards is QEMU > then exiting. >=20 > If a shutdown request was received, qemu should still not exit as long > as there's in-flight I/O, or as long as there are CPUs running in the > guest. It would seem legitimate to "cancel" in-flight I/O (and perhaps > "reject" further requests arriving), but the device model needs to > remain there as long as there's at least one running CPU. That's no > different on "real" hardware - the machine doesn't "disappear" just > because shutdown was requested. Yes, I would not expect QEMU to exit straight away... or at all, until = killed by the toolstack. So that's the next thing to investigate. Paul >=20 > Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 13:25:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 13:25:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHmB-0004JB-R8; Mon, 08 Jun 2020 13:25:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHmA-0004J6-Vp for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 13:25:19 +0000 X-Inumbo-ID: 7e5b4cb8-a98b-11ea-b272-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 7e5b4cb8-a98b-11ea-b272-12813bfff9fa; Mon, 08 Jun 2020 13:25:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591622717; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iunWMdgIpilPK2dxhO36sttTtgukW90nUykrzyVwqng=; b=CSAPApQu2AZYMUdgm0SPEEqdFZHeJ/+GBLro/qdChbcPOz4JnzfkWWMMT+5W3/Y0uVhosI 5oOHbfU1fIE72qh62RHnq1PRB0RRgFkWVZiTWETrAqqVRPxcVVgoUB9nRFG6bpXtZ81ZHk veqa+hi8xnpvRwFKp8yq6OBezfQsdkY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-17-S--JotAmMg2_IzD9mvHcxA-1; Mon, 08 Jun 2020 09:25:15 -0400 X-MC-Unique: S--JotAmMg2_IzD9mvHcxA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 08A73107B267; Mon, 8 Jun 2020 13:25:14 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-113-50.ams2.redhat.com [10.36.113.50]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5F0405C1D6; Mon, 8 Jun 2020 13:25:08 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 1D7A116E16; Mon, 8 Jun 2020 15:25:07 +0200 (CEST) Date: Mon, 8 Jun 2020 15:25:07 +0200 From: Gerd Hoffmann To: qemu-devel@nongnu.org Subject: Re: [PATCH v3 0/4] microvm: memory config tweaks Message-ID: <20200608132507.snzujn4yb37z3xmj@sirius.home.kraxel.org> References: <20200529073957.8018-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: <20200529073957.8018-1-kraxel@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , Paul Durrant , "Michael S. Tsirkin" , imammedo@redhat.com, Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , philmd@redhat.com, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 09:39:53AM +0200, Gerd Hoffmann wrote: > With more microvm memory config tweaks split this into its owns series, > the microvm acpi patch series is already big enough ... > > v2: > - use 3G split. > - add patch to move virtio-mmio region. > - pick up acks & reviews. > v3: > - fix xen build. > - pick up acks & reviews. > > take care, > Gerd Ping. Anyone going to pick this up? MAINTAINERS lists Sergio+Paolo ... Or should I send a pull req myself? take care, Gerd From xen-devel-bounces@lists.xenproject.org Mon Jun 08 13:32:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 13:32:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHsZ-00059Q-IE; Mon, 08 Jun 2020 13:31:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHsY-00059L-OX for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 13:31:54 +0000 X-Inumbo-ID: 6ac71fbe-a98c-11ea-b274-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 6ac71fbe-a98c-11ea-b274-12813bfff9fa; Mon, 08 Jun 2020 13:31:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591623113; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tPVzldjJJNnkRaNdn/VsItofhkeod9E0zRG0RaxQv2M=; b=ZeToD1XSgSNLSaeUE/QKsnNPkDXZUZAhJso1I3cOr1+Ie5UC21xuyvZB5UloD37V1Wtbvd ase5H6QivF85SkcV/1AUZXb8xlEcjLHXoMq5srvUUq0NOLABlZVPvquzsZAsyPZTCQd5Vh khcrCvIlgXicc+D/dxI/ugp4D58YxqE= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-357-_0cL9hfgPG6rX1sBKjiaAg-1; Mon, 08 Jun 2020 09:31:52 -0400 X-MC-Unique: _0cL9hfgPG6rX1sBKjiaAg-1 Received: by mail-wr1-f70.google.com with SMTP id m14so7150475wrj.12 for ; Mon, 08 Jun 2020 06:31:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tPVzldjJJNnkRaNdn/VsItofhkeod9E0zRG0RaxQv2M=; b=l7Yn9fyxZc/ZxKWdh80gTtQVVxaSwYRb6170mPwtn2hZlDK+iSclSLyS3octc28PlZ WEZUZ9+3gmcYLQ4NHwrhYw4QMXfd3nz3hg2J08qXol98G7NIyS/ifYypVrQXp5Px48Ek z0+/pGlQRmOYMIUqKaVlPJs5S5W+vkb5jKbEZQX3SisZ1U50vgJbZoBIMhyCtGzuvK1P oq3IQh5DbUS7sVH8DWqgK7lhKA92zzJ4/WQw6luOxYwgmJmxvyQm+zj/Yr+1dx30Een9 d+i3wUuVH1aly8fjX2/2W9o4LkEJ+wS43PclOVZh1gWnnRN/NhCrk+uaft83E6R60GmI 6a6w== X-Gm-Message-State: AOAM532t52xBJTZlgb+JEAEcC1YAeiWIno1Kqo+B5QfNqzwpujbmFPI1 ZOCFvLttdPi5sAAbrORQJsAp5NDjd0xURHTXEjpsdtPj9EBWaoQxKqAoDJgw0yfui8sab3BJgF4 BNrrtlhClzzI1Wzs1iMPXW+VJvqM= X-Received: by 2002:a1c:66d5:: with SMTP id a204mr16198843wmc.134.1591623111290; Mon, 08 Jun 2020 06:31:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxA2HGg4NasaA8mCwPnDF9hNXQFQyNEekHr1Gs1mIC4JFKlyCAxU1yaGFm2tkHNCg14ZmLU4Q== X-Received: by 2002:a1c:66d5:: with SMTP id a204mr16198827wmc.134.1591623111104; Mon, 08 Jun 2020 06:31:51 -0700 (PDT) Received: from redhat.com (bzq-109-64-41-91.red.bezeqint.net. [109.64.41.91]) by smtp.gmail.com with ESMTPSA id j190sm22821770wmb.33.2020.06.08.06.31.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 06:31:50 -0700 (PDT) Date: Mon, 8 Jun 2020 09:31:47 -0400 From: "Michael S. Tsirkin" To: Gerd Hoffmann Subject: Re: [PATCH v3 0/4] microvm: memory config tweaks Message-ID: <20200608093125-mutt-send-email-mst@kernel.org> References: <20200529073957.8018-1-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: <20200529073957.8018-1-kraxel@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , Paul Durrant , qemu-devel@nongnu.org, imammedo@redhat.com, Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , philmd@redhat.com, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 09:39:53AM +0200, Gerd Hoffmann wrote: > With more microvm memory config tweaks split this into its owns series, > the microvm acpi patch series is already big enough ... Looks sane: Acked-by: Michael S. Tsirkin microvm things so should use that tree ... > v2: > - use 3G split. > - add patch to move virtio-mmio region. > - pick up acks & reviews. > v3: > - fix xen build. > - pick up acks & reviews. > > take care, > Gerd > > Gerd Hoffmann (4): > microvm: use 3G split unconditionally > microvm: drop max-ram-below-4g support > x86: move max-ram-below-4g to pc > microvm: move virtio base to 0xfeb00000 > > include/hw/i386/microvm.h | 2 +- > include/hw/i386/pc.h | 2 ++ > include/hw/i386/x86.h | 4 ---- > hw/i386/microvm.c | 35 +---------------------------- > hw/i386/pc.c | 46 +++++++++++++++++++++++++++++++++++++++ > hw/i386/pc_piix.c | 10 ++++----- > hw/i386/pc_q35.c | 10 ++++----- > hw/i386/x86.c | 46 --------------------------------------- > hw/i386/xen/xen-hvm.c | 2 +- > 9 files changed, 61 insertions(+), 96 deletions(-) > > -- > 2.18.4 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 13:33:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 13:33:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHtt-0005GC-T1; Mon, 08 Jun 2020 13:33:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHts-0005G3-Bh for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 13:33:16 +0000 X-Inumbo-ID: 9b66b9b8-a98c-11ea-9ad7-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 9b66b9b8-a98c-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 13:33:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591623195; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jy3UQ9TwolgMzcs+mF+EHL8I0EaYgGjLeRsKkZIF4Go=; b=N+yLZ3SAEYwHAyJmH0FzT/y2iw9iAWyLs2E+QpZTDMGkZdM1by10kLkWHUUvOx5D6EcbrF 9Z9xevBV+AURdRJlXNqyjv0mNIuqux7rx5wa/QnI1FSAq++Kt7AIt5cMPO+GoyKwGhBEjR 4GfDMNw9h+h0tqvx2POaWYZPvQel5EU= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-183-53gGRSa8PY2WRD-1hdezfQ-1; Mon, 08 Jun 2020 09:33:11 -0400 X-MC-Unique: 53gGRSa8PY2WRD-1hdezfQ-1 Received: by mail-wr1-f72.google.com with SMTP id r5so7176715wrt.9 for ; Mon, 08 Jun 2020 06:33:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jy3UQ9TwolgMzcs+mF+EHL8I0EaYgGjLeRsKkZIF4Go=; b=HB1If90sv/+Hu4urfyULs6KJgkVRQjX/v4riFiwrJt8RYFGB9OdmATTr16+yAPjDMv IxchYWJZUg8atvgphBodCkF5twUaqDotzr6x1LubN0qlaTgSFXcWYA6R+K0+UFd1RKGr 44Ft7RornKcIJV9IZBp98+tD8gZCMrAleQralwSA21Ib/2APtruSAWa1yoNPOEQ191p2 yioOjxqaFO08Y8snCiTmRumKtv83ftcuwFos6q9XRVza+BRs5tENSB0XV8s+3AjNMqp/ d271rtiTx2zmJlyP4GT+uFbzBAv417/lSJerNFAvrwSUuubffbXcXdCaAjJR3fWWRDRF cMGQ== X-Gm-Message-State: AOAM533z/AJPhGle/ZZUeEAaVwL43QPBzttC98GtoJMEzZH8cqhinYVx zo62Eez/gMLQPxl1tiuhkb2kD8dhVq+JBl2hChxj3Z3INtkOQGi2s4zKpCUDGcfHX2f/TvfL7CZ enS3yJm2dGrNrOz3G/AzrFFPF2uQ= X-Received: by 2002:a7b:c18a:: with SMTP id y10mr17443025wmi.73.1591623190857; Mon, 08 Jun 2020 06:33:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9bnbokhnVLN46q9sCb6V6ovAK9n5BS2Myq9eEvkQEpQdDlMBW6QLuyUv0QuXRGF4o3ryjhA== X-Received: by 2002:a7b:c18a:: with SMTP id y10mr17443008wmi.73.1591623190701; Mon, 08 Jun 2020 06:33:10 -0700 (PDT) Received: from redhat.com (bzq-109-64-41-91.red.bezeqint.net. [109.64.41.91]) by smtp.gmail.com with ESMTPSA id 88sm25269941wre.45.2020.06.08.06.33.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 06:33:10 -0700 (PDT) Date: Mon, 8 Jun 2020 09:33:07 -0400 From: "Michael S. Tsirkin" To: Gerd Hoffmann Subject: Re: [PATCH v3 4/4] microvm: move virtio base to 0xfeb00000 Message-ID: <20200608093247-mutt-send-email-mst@kernel.org> References: <20200529073957.8018-1-kraxel@redhat.com> <20200529073957.8018-5-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: <20200529073957.8018-5-kraxel@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , Paul Durrant , qemu-devel@nongnu.org, imammedo@redhat.com, Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , philmd@redhat.com, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 09:39:57AM +0200, Gerd Hoffmann wrote: > Place virtio-mmio devices near the other mmio regions, > next ioapic is at @ 0xfec00000. > > Signed-off-by: Gerd Hoffmann > --- > include/hw/i386/microvm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/hw/i386/microvm.h b/include/hw/i386/microvm.h > index ba68d1f22bb3..fd34b78e0d2a 100644 > --- a/include/hw/i386/microvm.h > +++ b/include/hw/i386/microvm.h > @@ -26,7 +26,7 @@ > #include "hw/i386/x86.h" > > /* Platform virtio definitions */ > -#define VIRTIO_MMIO_BASE 0xc0000000 > +#define VIRTIO_MMIO_BASE 0xfeb00000 > #define VIRTIO_IRQ_BASE 5 > #define VIRTIO_NUM_TRANSPORTS 8 > #define VIRTIO_CMDLINE_MAXLEN 64 OK, and let's hope we don't need to move it again. Reviewed-by: Michael S. Tsirkin > -- > 2.18.4 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 13:35:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 13:35:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHvl-0005Nv-9T; Mon, 08 Jun 2020 13:35:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHvk-0005Nq-5n for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 13:35:12 +0000 X-Inumbo-ID: df08c397-a98c-11ea-b275-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id df08c397-a98c-11ea-b275-12813bfff9fa; Mon, 08 Jun 2020 13:35:10 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: lRPdGcQtw5arndInLSRzK97MBnanXN9L2aS9PQILo1QZZxDJ5pdM1bnMuhPCm7AzaKYCc5zW9m DDbrNOVZuNuGimqqJrqytR3TD6h2GS/i4NFDDXh3Mo0a3ZgGmSWgkq1jCTJYHrXoqQC/QDrEuA GXUueHrWj73DMPTd4UYzsGYaQruE6zbJylFa+i4up1iNYA+rGMM0JYGKci8d8YkqTCJB/z7vuN eCFdyU27aco4mt/KvgcFsl9M9DzaMK5caS1uof8W44nOke/pzLcVTsTD4r6q7rC/pJhb0GUSDD 7ng= X-SBRS: 2.7 X-MesageID: 20232980 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="20232980" From: Andrew Cooper To: Xen-devel Subject: [PATCH v2 for-4.14] docs/support-matrix: unbreak docs rendering Date: Mon, 8 Jun 2020 14:34:33 +0100 Message-ID: <20200608133433.23659-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Paul Durrant , Jan Beulich , Anthony PERARD , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a while. commitish_version() pulls an old version of xen/Makefile out of history, and uses the xenversion rule. Currently, this fails with: tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory which is because the Makefile legitimately references Kbuild.include with a relative rather than absolute path. Rework support-matrix-generate to use sed to extract the major/minor, rather than expecting xen/Makefile to be usable in a different tree. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall CC: Anthony PERARD CC: Paul Durrant v2: * Use sed rather than fixing up the makefile environment This needs backporting to all trees with the support matrix logic, to unbreak docs rendering --- docs/support-matrix-generate | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate index a3d93321f1..b759d0440c 100755 --- a/docs/support-matrix-generate +++ b/docs/support-matrix-generate @@ -26,12 +26,9 @@ # SUPPORT.md into json. # # Then we try to find the next previous revision. This is done by -# extracting the current version number from xen/Makefile. (We make -# some slight assumption about how xen/Makefile's xenversion target -# works, because we want to be able to do this without checking out -# the whole tree for the version in question.) Then we use git log on -# xen/Makefile to try to find a commit where the version changed. -# This gives us the previous version number, NN. +# extracting the current version number from xen/Makefile. Then we +# use git log on xen/Makefile to try to find a commit where the +# version changed. This gives us the previous version number, NN. # # That is substituted into the `refs/remotes/origin/stable-NN' # argument to get the tip of the relevant branch. That in turns @@ -102,12 +99,16 @@ commitish_version () { esac git cat-file blob "$commitish:$versionfile" >"$tmp_versionfile" - version=$(make --no-print-directory -C docs \ - -f "${tmp_versionfile#docs/}" xenversion) - case "$version" in - *.*.*) version="${version%.*}" ;; - esac - printf "%s\n" "${version%%-*}" + + local maj=$(sed -n 's/.*XEN_VERSION.*= \([0-9]\+\)/\1/p' < "$tmp_versionfile") + local min=$(sed -n 's/.*XEN_SUBVERSION.*= \([0-9]\+\)/\1/p' < "$tmp_versionfile") + + if [[ -z $maj || -z $min ]]; + then + fail "Unable to identify Xen version for ${commitish}"; + fi + + printf "%d.%d\n" "${maj}" "${min}" } exec 4>"$tmp_revisions" -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 13:38:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 13:38:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHyn-0005Z3-OG; Mon, 08 Jun 2020 13:38:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiHym-0005YJ-7I for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 13:38:20 +0000 X-Inumbo-ID: 4f7f35ce-a98d-11ea-9ad7-bc764e2007e4 Received: from mail-wm1-x335.google.com (unknown [2a00:1450:4864:20::335]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4f7f35ce-a98d-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 13:38:18 +0000 (UTC) Received: by mail-wm1-x335.google.com with SMTP id u13so15393142wml.1 for ; Mon, 08 Jun 2020 06:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=z2FvhJj0rboD2ZNlDgF/UnMTbEK6UqBAOC4li2lmzI4=; b=ia/Lz60saGcOssbgF1HoIvrU5vjHprdlt+ZJgRr/GrHhJU9ZEDPO0aos0eelP0nB8w 735/VfMRDeX1er3eEKXkJtH7LX3ONqRYFgo+rF0QbrBOFTdRfFxsQHG6n9V07Ld/PRJg eO7rDqpedOJ2rwDpoDoE8N9tskqZ+T3xE9ojUnFjCSc8rfFVYKoN9HARqH860sNuY0QX KoY19YrMGon2PqbeFtBeiP3B8zMz+Z8y7Eqp6UhHELXtzD2OU1DNw75/7YEAMujEKU0S vf1cWAnzoaMGgAknK3RrCN9dkEBOM6/99vIdB02LjDq2uByrxVj999L6+xsww80NDGh9 M7bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=z2FvhJj0rboD2ZNlDgF/UnMTbEK6UqBAOC4li2lmzI4=; b=qgfn/sHP/mANiJrBvP1Qc2VlDxAj7zYpOmg0kSgbKh/xF9WCGoIQebGGS4tQbKBTmP gHb5C0K7aKs9yfsifAZ9TE4UJy9ZLXAjLZfq+yogoXDL7XU3XSZjF7BOagUjwBWTPH7T dcJbWv5TvU0YKzo63gLlZfDSmH2Y+OuyJrr69FzCTO7/g9VyV7Vm1sBteB9IzkbtiVZZ ngi8alEimwt1XP9mnpKicSpDRg2rp2VN1ZqH3s0i6sosG40yKvbTX67cb9izFrwwKxEn PG4ypkpiBHyomBdvA0OQiEd4BRwke70PsMsy/YvMHMxZwO7aUaBlMK/lhT/rppKr87NI +TYw== X-Gm-Message-State: AOAM533i1Ws2TzfpJ/8+OPzg/Cmuy8/6bbZaekSp6AOAp4Z59ozbYgML WXSDNjVZLGsasryH3Tclt+I= X-Google-Smtp-Source: ABdhPJxUCbfA+B1QRkslt9DCIbp/k9qzxUuL5axNYq4GvWO7p09sdGw03Py4/30qq8HbH3hlNfMCNQ== X-Received: by 2002:a7b:c1ce:: with SMTP id a14mr15434623wmj.144.1591623497392; Mon, 08 Jun 2020 06:38:17 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id l17sm21342417wmi.3.2020.06.08.06.38.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 06:38:16 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200608133433.23659-1-andrew.cooper3@citrix.com> In-Reply-To: <20200608133433.23659-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH v2 for-4.14] docs/support-matrix: unbreak docs rendering Date: Mon, 8 Jun 2020 14:38:15 +0100 Message-ID: <003201d63d9a$10a07f20$31e17d60$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQF3f+tZUFdPAi1ShdzcWao/KRWiYamMM+ow X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Konrad Rzeszutek Wilk' , 'George Dunlap' , 'Jan Beulich' , 'Anthony PERARD' , 'Ian Jackson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 08 June 2020 14:35 > To: Xen-devel > Cc: Andrew Cooper ; George Dunlap ; Ian > Jackson ; Jan Beulich ; Konrad Rzeszutek Wilk > ; Stefano Stabellini ; Wei Liu ; Julien > Grall ; Anthony PERARD ; Paul Durrant > Subject: [PATCH v2 for-4.14] docs/support-matrix: unbreak docs rendering > > The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a > while. commitish_version() pulls an old version of xen/Makefile out of > history, and uses the xenversion rule. > > Currently, this fails with: > > tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory > > which is because the Makefile legitimately references Kbuild.include with a > relative rather than absolute path. > > Rework support-matrix-generate to use sed to extract the major/minor, rather > than expecting xen/Makefile to be usable in a different tree. > > Signed-off-by: Andrew Cooper Release-acked-by: Paul Durrant > --- > CC: George Dunlap > CC: Ian Jackson > CC: Jan Beulich > CC: Konrad Rzeszutek Wilk > CC: Stefano Stabellini > CC: Wei Liu > CC: Julien Grall > CC: Anthony PERARD > CC: Paul Durrant > > v2: > * Use sed rather than fixing up the makefile environment > > This needs backporting to all trees with the support matrix logic, to unbreak > docs rendering > --- > docs/support-matrix-generate | 25 +++++++++++++------------ > 1 file changed, 13 insertions(+), 12 deletions(-) > > diff --git a/docs/support-matrix-generate b/docs/support-matrix-generate > index a3d93321f1..b759d0440c 100755 > --- a/docs/support-matrix-generate > +++ b/docs/support-matrix-generate > @@ -26,12 +26,9 @@ > # SUPPORT.md into json. > # > # Then we try to find the next previous revision. This is done by > -# extracting the current version number from xen/Makefile. (We make > -# some slight assumption about how xen/Makefile's xenversion target > -# works, because we want to be able to do this without checking out > -# the whole tree for the version in question.) Then we use git log on > -# xen/Makefile to try to find a commit where the version changed. > -# This gives us the previous version number, NN. > +# extracting the current version number from xen/Makefile. Then we > +# use git log on xen/Makefile to try to find a commit where the > +# version changed. This gives us the previous version number, NN. > # > # That is substituted into the `refs/remotes/origin/stable-NN' > # argument to get the tip of the relevant branch. That in turns > @@ -102,12 +99,16 @@ commitish_version () { > esac > > git cat-file blob "$commitish:$versionfile" >"$tmp_versionfile" > - version=$(make --no-print-directory -C docs \ > - -f "${tmp_versionfile#docs/}" xenversion) > - case "$version" in > - *.*.*) version="${version%.*}" ;; > - esac > - printf "%s\n" "${version%%-*}" > + > + local maj=$(sed -n 's/.*XEN_VERSION.*= \([0-9]\+\)/\1/p' < "$tmp_versionfile") > + local min=$(sed -n 's/.*XEN_SUBVERSION.*= \([0-9]\+\)/\1/p' < "$tmp_versionfile") > + > + if [[ -z $maj || -z $min ]]; > + then > + fail "Unable to identify Xen version for ${commitish}"; > + fi > + > + printf "%d.%d\n" "${maj}" "${min}" > } > > exec 4>"$tmp_revisions" > -- > 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 13:42:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 13:42:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiI2P-0006Jw-8D; Mon, 08 Jun 2020 13:42:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiI2O-0006Jr-MY for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 13:42:04 +0000 X-Inumbo-ID: d4d48562-a98d-11ea-b277-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d4d48562-a98d-11ea-b277-12813bfff9fa; Mon, 08 Jun 2020 13:42:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 16227AC2D; Mon, 8 Jun 2020 13:42:04 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14] docs/support-matrix: unbreak docs rendering To: Andrew Cooper References: <20200608133433.23659-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: Date: Mon, 8 Jun 2020 15:41:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200608133433.23659-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Paul Durrant , Ian Jackson , Anthony PERARD , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 15:34, Andrew Cooper wrote: > The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a > while. commitish_version() pulls an old version of xen/Makefile out of > history, and uses the xenversion rule. > > Currently, this fails with: > > tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory > > which is because the Makefile legitimately references Kbuild.include with a > relative rather than absolute path. > > Rework support-matrix-generate to use sed to extract the major/minor, rather > than expecting xen/Makefile to be usable in a different tree. > > Signed-off-by: Andrew Cooper > --- > CC: George Dunlap > CC: Ian Jackson > CC: Jan Beulich > CC: Konrad Rzeszutek Wilk > CC: Stefano Stabellini > CC: Wei Liu > CC: Julien Grall > CC: Anthony PERARD > CC: Paul Durrant > > v2: > * Use sed rather than fixing up the makefile environment > > This needs backporting to all trees with the support matrix logic, to unbreak > docs rendering Did I understand the earlier discussion wrong then that the breakage was connected to the introduction of xen/scripts/Kbuild.include? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 13:48:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 13:48:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiI8P-0006ZA-2F; Mon, 08 Jun 2020 13:48:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiI8N-0006Z5-Ji for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 13:48:15 +0000 X-Inumbo-ID: b2f34144-a98e-11ea-9b55-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b2f34144-a98e-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 13:48:14 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: xf7Y8GjkauFEV1JKERyWjDzhXxM6gjegyDd5m1Z5TX7oNllGB64KSePD6Ge12US2qdZJBIPmjQ 7FWrhjqKwjDNYXIo5QgMRLj9u4WL+M0grfHGGfwSy18uUPxRALSiHRt4ki2HQ4Stzm6jrf3ccA Vw5mocnd0J/I/p/z544DgGRTIazl5IAL6IsM+XzrnB6XEHnDZTbS+mhLUsANaRg4cUBl08iMbg nEyl3XyhPnWDMPQtfSMZisaUBKHPR/+RL2MR0TYpJCqhDcPQyVh7hN4LG1Du/1DO0FmWuvBdAW SNI= X-SBRS: 2.7 X-MesageID: 20234231 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="20234231" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24286.16793.101133.543735@mariner.uk.xensource.com> Date: Mon, 8 Jun 2020 14:48:09 +0100 To: Andrew Cooper Subject: Re: [PATCH v2 for-4.14] docs/support-matrix: unbreak docs rendering In-Reply-To: <20200608133433.23659-1-andrew.cooper3@citrix.com> References: <20200608133433.23659-1-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , Paul Durrant , George Dunlap , Jan Beulich , Anthony Perard , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("[PATCH v2 for-4.14] docs/support-matrix: unbreak docs rendering"): > The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a > while. commitish_version() pulls an old version of xen/Makefile out of > history, and uses the xenversion rule. > > Currently, this fails with: Thanks for fixing this! > + local maj=$(sed -n 's/.*XEN_VERSION.*= \([0-9]\+\)/\1/p' < "$tmp_versionfile") > + local min=$(sed -n 's/.*XEN_SUBVERSION.*= \([0-9]\+\)/\1/p' < "$tmp_versionfile") > + if [[ -z $maj || -z $min ]]; I would prefer to avoid use of the unusual bash-specific [[ ]] syntax, not because of concerns about portability to other shells (since this is a #!/bin/bash script) but because many programmers won't be familiar with it. Would you mind writing this instead + if test -z "$maj" || test -z "$min"; then ? > + printf "%d.%d\n" "${maj}" "${min}" The { } here are not necessary but I don't kind if you feel they add clarity. You might also want to retain some text in the comment about what assumptions we are making about xen/Makefile. Different assumptions to before, but assumptions nevertheless. In any case, with or without the changes I suggest above: Reviewed-by: Ian Jackson On IRC: 14:35 Diziet: jbeulich: For the docs support-matrix fix, any concerns with me backporting it immediately? Having thought about this properly, I don't think we need to urgently backport this. In our own infrastructure, the one from staging (or maybe it is master) is used. The same script is used to parse all older versions. But I think it is a backport candidate. Maybe add a Backport: tag and my Backport-Requested-By ? Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 13:50:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 13:50:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIA2-0006fP-DE; Mon, 08 Jun 2020 13:49:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIA1-0006fK-01 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 13:49:57 +0000 X-Inumbo-ID: ef9c3a9c-a98e-11ea-b27b-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ef9c3a9c-a98e-11ea-b27b-12813bfff9fa; Mon, 08 Jun 2020 13:49:56 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: FE3uNW5AMbiXUKICNDdUiyoUkrCM+b+NXV6lAAvez7rOMkGIju0X7zh39qiW7FQjIAVfJYbxSW xjx6XSKDbdQ27BiEOub+6Xh8lZMb7bCTV39KUAds5aNdWAGNd99w8ePbho0BeFyZIrOlzCCTbu RzT/EP5aT/QbfBphcLPnU4ltr2xbZ8pNtZGwoBgK6RjS2jt6LVgf3Dz0OoXveI0Ca2J55KiGI5 1ELbq1rKLnOD7OB/2+gqQ+SNNV/1H/sUBnfz/TkKOHDAw4rUMVZlXaVjxCbmp8l0EJf0R0jZNz DgA= X-SBRS: 2.7 X-MesageID: 19827471 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19827471" Subject: Re: [PATCH v2 for-4.14] docs/support-matrix: unbreak docs rendering To: Jan Beulich References: <20200608133433.23659-1-andrew.cooper3@citrix.com> From: Andrew Cooper Message-ID: Date: Mon, 8 Jun 2020 14:49:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Paul Durrant , Ian Jackson , Anthony PERARD , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/2020 14:41, Jan Beulich wrote: > On 08.06.2020 15:34, Andrew Cooper wrote: >> The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a >> while. commitish_version() pulls an old version of xen/Makefile out of >> history, and uses the xenversion rule. >> >> Currently, this fails with: >> >> tmp.support-matrix.xen.make:130: scripts/Kbuild.include: No such file or directory >> >> which is because the Makefile legitimately references Kbuild.include with a >> relative rather than absolute path. >> >> Rework support-matrix-generate to use sed to extract the major/minor, rather >> than expecting xen/Makefile to be usable in a different tree. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: George Dunlap >> CC: Ian Jackson >> CC: Jan Beulich >> CC: Konrad Rzeszutek Wilk >> CC: Stefano Stabellini >> CC: Wei Liu >> CC: Julien Grall >> CC: Anthony PERARD >> CC: Paul Durrant >> >> v2: >> * Use sed rather than fixing up the makefile environment >> >> This needs backporting to all trees with the support matrix logic, to unbreak >> docs rendering > Did I understand the earlier discussion wrong then that the breakage > was connected to the introduction of xen/scripts/Kbuild.include? The xendocs cron email has been broken for an unknown period of time, hence the issue going unnoticed. The first of at least 3 breakages in the current docs rendering manifests like this. It may be that xen/scripts/Kbuild.include was the first thing to actually break this script, but I haven't checked, and its not relevant to the fragility of the old logic. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 08 14:05:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 14:05:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIOU-00006r-3T; Mon, 08 Jun 2020 14:04:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIOT-00006k-6A for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 14:04:53 +0000 X-Inumbo-ID: 05fad58a-a991-11ea-9b55-bc764e2007e4 Received: from mail-qk1-x744.google.com (unknown [2607:f8b0:4864:20::744]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 05fad58a-a991-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 14:04:52 +0000 (UTC) Received: by mail-qk1-x744.google.com with SMTP id n11so17298668qkn.8 for ; Mon, 08 Jun 2020 07:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=WSUcH3AY1CAeUmxIq6nHkTx22mFojaYCOSkSDYmsEzA=; b=tsCm9LBrefOefO6Q46HokVVoPtY0lV6pSgq5fJLoNi1p5M2tW8u0kkcGT6Y2tbYEmd 2nbD2yfeuKd40o8qXFTAl+qO8Sxv+TIhvp5Gon2X8JHsSBSnKUf3nPdLvqB9gJzrmwwh zARTpIEehE9mdolRs8rW3tVegddhdZYFxwJY0NeYw61Hxax0pXhYRso/D4fPFSKJpwQI u0kDjlumTK5F3ay9TEYZvIujP+EFXLksLLoAdsUPg3zzAQeQZjUyq+lEprKmV14ekONn hyYkGiIYBOpUW/N3PCD17rJTyd/L8huAsy3Fkd3KVD2UFTi+/Hmcbo4Czf+c3Ws33mCy +YFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=WSUcH3AY1CAeUmxIq6nHkTx22mFojaYCOSkSDYmsEzA=; b=kPP4SHZ7nXyPa3DKkfP589eiNFdTYaoEWKG7pVLTkx13GGxK7rPOeI9cN1ieXmTVx+ 6130+udlDBD24rVG+4vZaRtHHJ21hjOpT47czZFo1Dh8EJk2BPpz3N/vlNLP5HG6jtUF nQZBYNHCFWIoXNSQa6p6hRwApmZ+PbSRwD1S2oCLt7szPuqJaa+M/trfq0lPmzNECXe4 HO0G3yyWdCjFYgfetSDiI6m8Bu/DhWgOkKKSKqtQ+qQ0nlVk/2ZHGs7KrqF0y0BejIio HkpR26yLsxr+NIvq6/V8lfC/TSsAvw17OfkV3HeDB2D6i1GSRth+O6bJV3r3LT3AVEVd c3bw== X-Gm-Message-State: AOAM531E6ntx86IAhfzpcot7loBJyUuzrQiORDA3O22Fastozuapxd5F XZMbBymW5nX2oOoyQUVDKCljUgUNqPw= X-Google-Smtp-Source: ABdhPJwjY0CDcLq8ZoaRJPr03FOnr1q327zkcmLL9jI1Iz/nrP3IWiuWxnFsFZCN52p/EO5YaSkhtQ== X-Received: by 2002:a37:ec4:: with SMTP id 187mr21274421qko.124.1591625091983; Mon, 08 Jun 2020 07:04:51 -0700 (PDT) Received: from FED-nrosbr-BE.crux.rad.ainfosec.com (209-217-208-226.northland.net. [209.217.208.226]) by smtp.gmail.com with ESMTPSA id i3sm7097770qkf.39.2020.06.08.07.04.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 07:04:51 -0700 (PDT) Date: Mon, 8 Jun 2020 10:04:48 -0400 From: Nick Rosbrook To: George Dunlap Subject: Re: [PATCH for-4.14] golang/xenlight: remove call to go fmt in gengotypes.py Message-ID: <20200608140448.GA420606@FED-nrosbr-BE.crux.rad.ainfosec.com> References: <20200606161025.19057-1-rosbrookn@ainfosec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , Xen-devel , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 08, 2020 at 11:39:43AM +0000, George Dunlap wrote: > > > On Jun 6, 2020, at 5:10 PM, Nick Rosbrook wrote: > > > > Since the golang bindings are now set to be re-generated whenever a > > change is made to tools/libxl/libxl_types.idl, the call to go fmt in > > gengotypes.py results in a dirty git tree for users without go > > installed. > > > > As an immediate fix, just remove the call to go fmt from gengotypes.py. > > While here, make sure the DO NOT EDIT comment and package declaration > > remain formatted correctly. All other generated code is left > > un-formatted for now. > > > > Signed-off-by: Nick Rosbrook > > Reviewed-by: George Dunlap > > With one note: git complains that the resulting patch introduces loads of trailing whitespace. I went though gengotypes.py and essentially did `s/ \n/\n/g`. With your permission I’ll fold that (and the resulting patches) into this before checking it in. Yes, that's fine. Thank you. -NR From xen-devel-bounces@lists.xenproject.org Mon Jun 08 14:11:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 14:11:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIUJ-00011o-QO; Mon, 08 Jun 2020 14:10:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIUH-00011i-VL for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 14:10:54 +0000 X-Inumbo-ID: dd1d1d02-a991-11ea-96fb-bc764e2007e4 Received: from mail-qt1-x844.google.com (unknown [2607:f8b0:4864:20::844]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dd1d1d02-a991-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 14:10:53 +0000 (UTC) Received: by mail-qt1-x844.google.com with SMTP id i16so14703411qtr.7 for ; Mon, 08 Jun 2020 07:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=ZhSWpZickOGx37dZHYvaKvsmkcLpWU6uF6mIRnJsvUs=; b=cFkZefuLmr4hhAosZ5HXQfoP7tlG6hQ9em9AcBHYWmxBpnInLaxO87x9aACJ0Wkm2O p9tDtektESGeBPRXW0Z3QK8YGVqKrfK6vNwrRQfGud8MSTFXhpQbNocDPFqtT7jd97K4 renRGG8iRtGkvG0LgYKZYxOmB+RZP/f72tGfcVTjogjYzClAv6FsMLdxGkZZm/Hcv6pW N2J107lmdKqdJy0FhYvkgF++dsPHITMLr2lzRmBVcXw/2XlLHhCyBQZeAaf1StAKl6hc zfn/c7QemR+u+8CkPBi2XsfvBY0+NHyt40VNklza7lRLxWU3vqfjp3Hx7fsza0Uo42C1 33sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=ZhSWpZickOGx37dZHYvaKvsmkcLpWU6uF6mIRnJsvUs=; b=QV353RtKGEk+yt+AQro4lLOQIxRB3C7H08p7DqJgY3bzRpzafOjha7krqeAJQpDcYQ 9V3qj67etCdVwB2va+Mscvk3/8tDQ4kAgxb7u+7ULADjwt2J/FSEeYUGO5EZodJ+ZGJn IAJ6rJYxuDh7EPx0B5tTEqDoKeBT7sr+p0VEH/X19pmlp/Rn2lKODIiAH+2dWt785YWi C7zFi7jVh54ifFBma0UprJAGm9mxomhbWFA2ivkOK7ab/Hgj5FL8g7d+qBN6d+SYHsZc xWtdl9y3mgXjMdliJ87tDCzJikjKfiuEFabUuKOEb3GSvPTrTMxwr/AIs/E2AaMl75Hk KuGg== X-Gm-Message-State: AOAM530wQccZGPSi0n1zJNeIQpbPELe9BgXPV0+h+FlUQx89X2BDxfrh u7yCHz0eiiygZk14gzdgHYw= X-Google-Smtp-Source: ABdhPJyBoQ2f5n+JRtUWnYFJmaV3YGpWHgZx60/acfiSC6ET/F6OAS1FdQzmmruAybC1WknG/LARog== X-Received: by 2002:aed:2577:: with SMTP id w52mr23454516qtc.252.1591625452938; Mon, 08 Jun 2020 07:10:52 -0700 (PDT) Received: from FED-nrosbr-BE.crux.rad.ainfosec.com (209-217-208-226.northland.net. [209.217.208.226]) by smtp.gmail.com with ESMTPSA id s70sm7160885qke.80.2020.06.08.07.10.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 07:10:52 -0700 (PDT) Date: Mon, 8 Jun 2020 10:10:49 -0400 From: Nick Rosbrook To: George Dunlap Subject: Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile Message-ID: <20200608141049.GB420606@FED-nrosbr-BE.crux.rad.ainfosec.com> References: <20200526221612.900922-1-george.dunlap@citrix.com> <20200526221612.900922-2-george.dunlap@citrix.com> <5CF4AE1D-C80C-4E4C-B4AA-0779E7DC53E7@citrix.com> <20200604182938.GA10975@six> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , xen-devel , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > > Out of curiosity, would it be totally out of the question to require > > having gofmt installed (not for 4.14, but in the future)? I ask because > > I haven't seen it discussed one way or the other. > > I think I’d like to try to avoid it, unless / until we have a “core component” written in golang. For one, if we added it as a core dependency, we’d need to be backwards compatible to the oldest version of golang of distros on which we want to build; that would include Debian oldstable, Ubuntu LTS, probably CentOS 7 at least, possibly CentOS 6, and so on. If any of those didn’t have golang available, then we’d basically have to decide between dropping support for those distros, and making golang optional. > > I don’t at the moment have a good feel for what other people in the community feel about this, but generally speaking being fanatically backwards compatible is an investment in the long-term ecosystem; keeping Xen *as a whole* building on older distros is an example of that. (FWIW I don’t think we have an official rubric, but my starting point is that we should try to build on all still-supported major distros; that would include CentOS 6 until Q4 of 2020, if my quick Google search is correct.) > > One advantage of making golang optional is that we don’t have to be quite so backwards compatible — up until we declare the feature “fully supported”, we can move the minimum required version forward at will if we want to rely on new features. That all makes sense, thanks for explaining. -NR From xen-devel-bounces@lists.xenproject.org Mon Jun 08 14:11:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 14:11:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIUj-00013e-2Q; Mon, 08 Jun 2020 14:11:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIUg-00013N-Hv for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 14:11:19 +0000 X-Inumbo-ID: eac43954-a991-11ea-b27d-12813bfff9fa Received: from mo4-p00-ob.smtp.rzone.de (unknown [81.169.146.217]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id eac43954-a991-11ea-b27d-12813bfff9fa; Mon, 08 Jun 2020 14:11:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591625476; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=CVDd4uHHAw9fgz0xLmk75Ws90S2daYPWZzP5U81wMt4=; b=hxKUaGqlVVCgAgnTelfS1ynhQmwLZ12KT4/dNS16gZV0zFQCwoyUx56re2DTneeNpH DQMs4V47U91ZW+ZBVlEHggOHgGIRMJB+jHJrbKJU0ZFiScehRaxKiVZOSNtLyE/t2hgw cDZn2FREHaX02xFCZ1b0QmFqQ9lUMrxDI7fcy+RTjOkpcTYLno5YJ1dYrfBkVVCGoQSY jLEmTLQlmyCpuuElygXePMW6um4zauSil0h2zw+Dm5VyYjYiP5dEt8kFaIxI2CMBgCEp hV1R5gw4BC3+xXWXjBl+Z7AdHC75wiuWEbawCejYLGFFRtkmtiKo6Ho4J1c/TUnnj+3a hlRg== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w58EBDH0E (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 8 Jun 2020 16:11:13 +0200 (CEST) Date: Mon, 8 Jun 2020 16:11:11 +0200 From: Olaf Hering To: Jason Andryuk Subject: Re: [PATCH v1] tools: fix usage of strncpy Message-ID: <20200608161111.26c2cdd4.olaf@aepfle.de> In-Reply-To: References: <20200608072855.26589-1-olaf@aepfle.de> <20200608100051.16be834e.olaf@aepfle.de> <24286.6790.983312.672969@mariner.uk.xensource.com> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/tHnWh5rOkRJp/RG5rGICI/S"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Wei Liu , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/tHnWh5rOkRJp/RG5rGICI/S Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 8 Jun 2020 08:43:50 -0400 schrieb Jason Andryuk : > I added a length check in this patch: gcc will not recognize such runtime checks and will (most likely) complain = about the strncpy usage anyway, just as it does now in libxl__prepare_socka= ddr_un. While the usage in libxl__prepare_sockaddr_un is fatal due to -Werr= or, libvchan is apparently built without -Werror. Olaf --Sig_/tHnWh5rOkRJp/RG5rGICI/S Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7eRv8ACgkQ86SN7mm1 DoDYKQ//aDUkyNOaXvmB6HqJfnD3qnWNyYFjXjvWcwyLLlk+KbqF3YrAKC7web4D yuoYnZysjoZUCi7dscvfbu3Gbk3FLe2/B0junH4jspf4CY32oD9dZlw5nGXGdTjX N2hzUCyaIZlVcO/3ryJe1/LywXMclW5aKowziHcMO1NhyhE8NwS1jLST+UjrV9/E 4L485sx2OXi6RWalA4l5luGQVp4mi/cSNdUgQb3/yQ2FgUE/2NNBxPQvE0uP3YKw EbFSy0H6iiGNjRL9dCZgJnkI8AK19WMLEsBAEvNyQdJpdeQyG6rKWT8W7LdCeU4l KzSZdgoJneJFJ4Tq5RzTP3P8Z0v3PCXZXCYcyjDjfK9eo4a7TR4QFEyKnlZ9Zuuh Mx2tM1iLWgVUOvRfd9GE3SNEFSlpvEC22ehwTiGwQfEZACWMXeZYse5N0v/btNiy ab+1NpWU0I8n9coo20iM+XK7G5C1b42UvbtQc9XGuuOFRibKMvzW3k7rd+Ydaprg X8PG7hizAFf1gfkHcOIA2Lp7j8K9qvX0a0o2IDqiDCG9sonaNVf1EFua0HCOjQ/c wZTy47FaUd3KAkmeOD/ojMWEd4Krg4Fz7t5gYuUbPqSjFwxJoZXZ1COzX4rp4eHV we7z7m+rFubDYwuC70owZPwI0bnxn4VtXPxOLhOnpqWTif1cyZw= =FK7T -----END PGP SIGNATURE----- --Sig_/tHnWh5rOkRJp/RG5rGICI/S-- From xen-devel-bounces@lists.xenproject.org Mon Jun 08 14:12:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 14:12:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIVS-00019f-Bv; Mon, 08 Jun 2020 14:12:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIVR-00019X-O8 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 14:12:05 +0000 X-Inumbo-ID: 0757c4be-a992-11ea-b27d-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0757c4be-a992-11ea-b27d-12813bfff9fa; Mon, 08 Jun 2020 14:12:04 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: f8S7VtXZwabCNZRu6UnBw+Uk1952FBA2EOrtKHBjqWklmQDIRjKmGVWXxOa9c8mdkEulNtuDjg IINb/25Yc2boFwHpikb6hm3GdGEXVF0AjYGdOHhr6xwPFPzYxMtoTZJG9BHkif29dyLyUojXpe xnujHRv8WarSq4wMGmoHyi7cVLLwUDxAA+tuDEtXOYyEtIcuJeegaQNbELJ+Z5TTFnGUDAWDuX NyrrgFzBiyl9eWzhukFHj6njnDYrnSUHkGvSYkr5ictj8Wjy/bxHaGb3HGmiMFA3VvBpMQTFLd gyU= X-SBRS: 2.7 X-MesageID: 19480105 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19480105" Subject: Re: [PATCH v2 for-4.14] docs/support-matrix: unbreak docs rendering To: Ian Jackson References: <20200608133433.23659-1-andrew.cooper3@citrix.com> <24286.16793.101133.543735@mariner.uk.xensource.com> From: Andrew Cooper Message-ID: <27c8c443-2566-3088-c86b-7177f16a1982@citrix.com> Date: Mon, 8 Jun 2020 15:11:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <24286.16793.101133.543735@mariner.uk.xensource.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , Paul Durrant , George Dunlap , Jan Beulich , Anthony Perard , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/2020 14:48, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH v2 for-4.14] docs/support-matrix: unbreak docs rendering"): >> The cronjob which renders https://xenbits.xen.org/docs/ has been broken for a >> while. commitish_version() pulls an old version of xen/Makefile out of >> history, and uses the xenversion rule. >> >> Currently, this fails with: > Thanks for fixing this! > >> + local maj=$(sed -n 's/.*XEN_VERSION.*= \([0-9]\+\)/\1/p' < "$tmp_versionfile") >> + local min=$(sed -n 's/.*XEN_SUBVERSION.*= \([0-9]\+\)/\1/p' < "$tmp_versionfile") >> + if [[ -z $maj || -z $min ]]; > I would prefer to avoid use of the unusual bash-specific [[ ]] syntax, > not because of concerns about portability to other shells (since this > is a #!/bin/bash script) but because many programmers won't be > familiar with it. > > Would you mind writing this instead > > + if test -z "$maj" || test -z "$min"; then > > ? Single square brackets would be consistent with the rest of the script, if you're happy with that? >> + printf "%d.%d\n" "${maj}" "${min}" > The { } here are not necessary but I don't kind if you feel they add > clarity. > > You might also want to retain some text in the comment about what > assumptions we are making about xen/Makefile. Different assumptions > to before, but assumptions nevertheless. > > In any case, with or without the changes I suggest above: > > Reviewed-by: Ian Jackson > > On IRC: > > 14:35 Diziet: jbeulich: For the docs support-matrix > fix, any concerns with me backporting it immediately? > > Having thought about this properly, I don't think we need to urgently > backport this. In our own infrastructure, the one from staging (or > maybe it is master) is used. The same script is used to parse all > older versions. Ah - I'd not spotted the logic to limit it to staging/master only. In which case it won't block docs generation on older branches. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 08 14:15:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 14:15:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIZ0-0001Nk-Rk; Mon, 08 Jun 2020 14:15:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiIYz-0001Ne-Th for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 14:15:45 +0000 X-Inumbo-ID: 8a6371f0-a992-11ea-ba62-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8a6371f0-a992-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 14:15:44 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: hcNAetMG/KmWblZbLN0Jqp3lG+aPtcynRFpY875hU77cZmwztVpB2xYNV39hT/mBMS5w1CcitI rl7OkATJ/aYF6DQhoQ4VSvho9+gujE+YxyWAUMrPe98GY1LbLc37U0oqUGROfjXhiC0V2DHLAG eSonSxVrxPpEBu5qVCBuaYoPNRfHCc4/dmwVtk3GKtW6l1XTKS8mcyVh8dCW4fENfZLpWHo3WC 3L9KtlSJSObM+nRrU86ln8Z2y5885v2o848f5zfxsEs4j/i+vCwa+8A9G0D9Kt7gTbfjLfruHT Xdc= X-SBRS: 2.7 X-MesageID: 19775556 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19775556" From: George Dunlap To: Nick Rosbrook Subject: Re: [PATCH for-4.14] golang/xenlight: remove call to go fmt in gengotypes.py Thread-Topic: [PATCH for-4.14] golang/xenlight: remove call to go fmt in gengotypes.py Thread-Index: AQHWPB0FRC5n06e/7UW7VAlSJqYdHajOeT+AgAArkwA= Date: Mon, 8 Jun 2020 14:15:40 +0000 Message-ID: <34A9DEE3-7408-4717-853B-43BD5BA7B6C8@citrix.com> References: <20200606161025.19057-1-rosbrookn@ainfosec.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <9DB4B0BDD89EAB459D42FC3153909AF4@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , Xen-devel , Paul Durrant , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Q0PigJlpbmcgcmVsZWFzZSBtYW5hZ2VyDQoNCj4gT24gSnVuIDgsIDIwMjAsIGF0IDEyOjM5IFBN LCBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGNpdHJpeC5jb20+IHdyb3RlOg0KPiANCj4+ IA0KPj4gT24gSnVuIDYsIDIwMjAsIGF0IDU6MTAgUE0sIE5pY2sgUm9zYnJvb2sgPHJvc2Jyb29r bkBnbWFpbC5jb20+IHdyb3RlOg0KPj4gDQo+PiBTaW5jZSB0aGUgZ29sYW5nIGJpbmRpbmdzIGFy ZSBub3cgc2V0IHRvIGJlIHJlLWdlbmVyYXRlZCB3aGVuZXZlciBhDQo+PiBjaGFuZ2UgaXMgbWFk ZSB0byB0b29scy9saWJ4bC9saWJ4bF90eXBlcy5pZGwsIHRoZSBjYWxsIHRvIGdvIGZtdCBpbg0K Pj4gZ2VuZ290eXBlcy5weSByZXN1bHRzIGluIGEgZGlydHkgZ2l0IHRyZWUgZm9yIHVzZXJzIHdp dGhvdXQgZ28NCj4+IGluc3RhbGxlZC4NCj4+IA0KPj4gQXMgYW4gaW1tZWRpYXRlIGZpeCwganVz dCByZW1vdmUgdGhlIGNhbGwgdG8gZ28gZm10IGZyb20gZ2VuZ290eXBlcy5weS4NCj4+IFdoaWxl IGhlcmUsIG1ha2Ugc3VyZSB0aGUgRE8gTk9UIEVESVQgY29tbWVudCBhbmQgcGFja2FnZSBkZWNs YXJhdGlvbg0KPj4gcmVtYWluIGZvcm1hdHRlZCBjb3JyZWN0bHkuIEFsbCBvdGhlciBnZW5lcmF0 ZWQgY29kZSBpcyBsZWZ0DQo+PiB1bi1mb3JtYXR0ZWQgZm9yIG5vdy4NCj4+IA0KPj4gU2lnbmVk LW9mZi1ieTogTmljayBSb3Nicm9vayA8cm9zYnJvb2tuQGFpbmZvc2VjLmNvbT4NCj4gDQo+IFJl dmlld2VkLWJ5OiBHZW9yZ2UgRHVubGFwIDxnZW9yZ2UuZHVubGFwQGNpdHJpeC5jb20+DQoNClBh dWwsIHRoaXMgaXMgYSBmaXggdG8gdGhlIGJ1aWxkIHN5c3RlbSB0aGF0IG9ubHkgYWZmZWN0cyB0 aGUgZm9ybWF0dGluZyBvZiBzb21lIGdlbmVyYXRlZCBjb2RlLiAgKEF0IHRoZSBtb21lbnQsIHRo ZSBnZW5lcmF0ZWQgY29kZSB3aWxsIGxvb2sgZGlmZmVyZW50bHkgZGVwZW5kaW5nIG9uIHdoZXRo ZXIgeW91IGhhdmUgZ29sYW5nIGluc3RhbGxlZCBvciBub3QuKQ== From xen-devel-bounces@lists.xenproject.org Mon Jun 08 14:46:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 14:46:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJ2d-0003zK-Ha; Mon, 08 Jun 2020 14:46:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJ2b-0003yb-OG for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 14:46:21 +0000 X-Inumbo-ID: d11dd5f0-a996-11ea-b289-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d11dd5f0-a996-11ea-b289-12813bfff9fa; Mon, 08 Jun 2020 14:46:21 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: fZE+rIwQViK1TuO9EoTkz06zeHFpoous8ELYsuEqyz35DEgMWd9Kw/yrnzpJ04jED2TmSexEYp 4o+eG4ATa41TJyj9/MrZ1delmlVxO7NxkPc4SQiYwRCv5fT30kNnyuXu6wrhISwuL+biBVaLEr uwPVhu3c/fME+NZRM0bFNCVEepelVPRCNuDDBvDlH8onEYJfpa5ZY6Y2BikMF+Y6Xl64Z70Tcr kI2adPJStvQwhshnhSADt8bvxICL+ybrslK6OdkxkYT0sQ0xIGNV66cimCBvm/oMMu0xBV+Q+q 7L8= X-SBRS: 2.7 X-MesageID: 20240805 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="20240805" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24286.20279.622221.291800@mariner.uk.xensource.com> Date: Mon, 8 Jun 2020 15:46:15 +0100 To: "paul@xen.org" Subject: 4.14.0-rc1 blocked on goland build failure - decision needed In-Reply-To: <003301d63d9e$97de3e60$c79abb20$@xen.org> References: <005201d635a9$2b9bbc20$82d33460$@xen.org> <2C4D8F6A-1498-4F13-923C-AAF2960D531F@citrix.com> <007401d635c2$6b14a150$413de3f0$@xen.org> <001201d63b5b$d8ebe7d0$8ac3b770$@xen.org> <002901d63d7f$2301a6a0$6904f3e0$@xen.org> <24286.12984.247498.799575@mariner.uk.xensource.com> <003001d63d93$9a4bbcf0$cee336d0$@xen.org> <24286.18072.880121.172973@mariner.uk.xensource.com> <003301d63d9e$97de3e60$c79abb20$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , George Dunlap , Wei Liu , Nick Rosbrook Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, Paul. For those on xen-devel: context is that Paul asked me to cut 4.14.0-rc1. The checklist asks me to perform a test build. My 32-bit tools test build failed. I think the problem is probably specific to 32-bit userland on 64-bit Linux kernel. I will send a second followup mail not CC Paul with technical details. Paul: do you want me to abort this RC to to release it anyway ? Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 14:48:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 14:48:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJ4y-00047D-VA; Mon, 08 Jun 2020 14:48:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJ4x-000477-AD for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 14:48:47 +0000 X-Inumbo-ID: 27e9b8c2-a997-11ea-b289-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 27e9b8c2-a997-11ea-b289-12813bfff9fa; Mon, 08 Jun 2020 14:48:46 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 5Vf2vtuwm9AbQkt7ENoccWZJ+KP1LISg1ERtf10ANhs3+mWCBMmQbunPoob5W2V9wknpaI4jbm 1NdZuTSH+ZUnE40VJRKbe+vheCNQuxwrO2TZ+4jbz9HIXgHALvC8354qlHTUivTlsQ8gb+JY46 bQaIy2DscPaDv4zLZ7jyr7W2bfpM5VaCiKVrIkFOIhEunGtccd1lakfGboFOwCv/8hAxmR+MT5 9bY2TeR1CbdiomBnBLvz8nBz/j+eGNfkBuxcasJbNB9u5lr+oyvW9vxTf9iEg3glg/eWoLNFNl hFQ= X-SBRS: 2.7 X-MesageID: 19779146 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19779146" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24286.20424.998938.535648@mariner.uk.xensource.com> Date: Mon, 8 Jun 2020 15:48:40 +0100 To: George Dunlap , Nick Rosbrook Subject: Re: 4.14.0-rc1 blocked on goland build failure - decision needed In-Reply-To: <24286.20279.622221.291800@mariner.uk.xensource.com> References: <005201d635a9$2b9bbc20$82d33460$@xen.org> <2C4D8F6A-1498-4F13-923C-AAF2960D531F@citrix.com> <007401d635c2$6b14a150$413de3f0$@xen.org> <001201d63b5b$d8ebe7d0$8ac3b770$@xen.org> <002901d63d7f$2301a6a0$6904f3e0$@xen.org> <24286.12984.247498.799575@mariner.uk.xensource.com> <003001d63d93$9a4bbcf0$cee336d0$@xen.org> <24286.18072.880121.172973@mariner.uk.xensource.com> <003301d63d9e$97de3e60$c79abb20$@xen.org> <24286.20279.622221.291800@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Ian Jackson writes ("4.14.0-rc1 blocked on goland build failure - decision needed"): > Hi, Paul. For those on xen-devel: context is that Paul asked me to > cut 4.14.0-rc1. The checklist asks me to perform a test build. > > My 32-bit tools test build failed. I think the problem is probably > specific to 32-bit userland on 64-bit Linux kernel. I will send a > second followup mail not CC Paul with technical details. Technical details@: The first error looks like this: ./helpers.gen.go:901[/tmp/go-build643158686/_/u/iwj/work/xen.git/tools/golang/xenlight/_obj/helpers.gen.cgo1.go:1172]: type [268435456]_Ctype_struct_libxl_sched_params larger than address space I suspected that golang was misdetecting my build environment, which was a 32-bit Linux userland on a 64-bit Linux kernel, reporting this $ uname -av Linux mariner 3.16.0-6-amd64 #1 SMP Debian 3.16.57-2 (2018-07-14) x86_64 GNU/Linux $ env | grep XEN XEN_COMPILE_ARCH=x86_32 $ So I tried using `linux32' to change the process personality: $ uname -av + uname -av Linux mariner 3.16.0-6-amd64 #1 SMP Debian 3.16.57-2 (2018-07-14) i686 GNU/Linux $ env | grep XEN + grep XEN + env XEN_COMPILE_ARCH=x86_32 $ I did the build again, from a clean tree, and got the same result. I was building my prospective -rc1 git branch but I am pretty sure the problem exists with master and staging. I have not yet done a formal repro in a 32-bit chroot on another system. I'm going to do that next. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 15:07:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 15:07:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJMd-0005nc-FH; Mon, 08 Jun 2020 15:07:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJMc-0005nW-Lp for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 15:07:02 +0000 X-Inumbo-ID: b4b51e3e-a999-11ea-9b55-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b4b51e3e-a999-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 15:07:02 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id y17so17764577wrn.11 for ; Mon, 08 Jun 2020 08:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=QB5BKohjXJ32ObghKFMDps1tKYPC1acdJx9MCMAOsC0=; b=GqCBO1MsYlAi/jAEUcqsWXRH770V1vlToZ2+rFS14pFsdhBJKHq6itHPaplghJLKHu BN0VfP5nXHP/ihJqZrv6NwbEjtVDPst143ppNVV8cK3yxbE0BaC4nCC2VfWE3Y+EVdeo qD9g+fy/FnRiyOmNtt9uKJK+TGAmxsIyELu3momWxT+OGr4szstDXbCyYXhC1o7Oynt0 jBLUtyzVC/tI4KI8QbxqXfHjBUcpNESJlVF8gK4VYqpZrDrj8YAunxRp+np0Yev7h24/ 8rRxMNPZ25tVd/tCdEkz2Eu2LYXdYWQCBtjAmPUc5ogD4KJAySUxrqjJH6PukCVL0oTa 89NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=QB5BKohjXJ32ObghKFMDps1tKYPC1acdJx9MCMAOsC0=; b=uCGp+PDE2SkSvRz0ADjqNkB+dn+BP3zaM/r4blnX3HbbOhjUsGfRg+CFNj2qSCemcS VVuO+QIZR+C3ornPKiu4Pk95NaMP5jIHE8GP/fFOFeF92ff4ScXjrg8hI7/MqXKAA6mG QSbzWac6+EuEuGffDsUjMJlA9H4YGk6tvdRvm9fHcViOOP/jUW7ORyZZNlhG/CgoyyCE 5wDiCOot113FEVkT7NrCfVESoV5ctEoH1fOoqcEXU/IhPEP+c/PZUHv73dKcAHb9aAbJ 3JLEtTjPXm2YGOPpPJWQDoU1vldE8duHnyiY5z2zky6nyY9Ea56C2acEbRZqWDXoybde LHsw== X-Gm-Message-State: AOAM530rVLirELpqvhAp00IuJrrmTYryBsvfi9/OiftCCLSxfqeMOAO5 GIqo73+zlZYaJIIF13flyio= X-Google-Smtp-Source: ABdhPJzAMXwWHE/RsCcwmdSNbSaJl0ri5Y5vMAp64ThZ2XsYp4AQAslGOX2H7FKuSc+W/z3AE4COCg== X-Received: by 2002:adf:dcc3:: with SMTP id x3mr23255066wrm.93.1591628821191; Mon, 08 Jun 2020 08:07:01 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id p7sm20599wro.26.2020.06.08.08.06.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 08:07:00 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'George Dunlap'" , "'Nick Rosbrook'" References: <20200606161025.19057-1-rosbrookn@ainfosec.com> <34A9DEE3-7408-4717-853B-43BD5BA7B6C8@citrix.com> In-Reply-To: <34A9DEE3-7408-4717-853B-43BD5BA7B6C8@citrix.com> Subject: RE: [PATCH for-4.14] golang/xenlight: remove call to go fmt in gengotypes.py Date: Mon, 8 Jun 2020 16:06:59 +0100 Message-ID: <004501d63da6$75d9ecd0$618dc670$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQMZuxlWX/GkGcJw6dDksLH66QFH1QGz0NGjAkULNCymKA+YwA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Nick Rosbrook' , 'Xen-devel' , 'Wei Liu' , 'Ian Jackson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: George Dunlap > Sent: 08 June 2020 15:16 > To: Nick Rosbrook > Cc: Xen-devel ; Nick Rosbrook = ; Ian Jackson > ; Wei Liu ; Paul Durrant = > Subject: Re: [PATCH for-4.14] golang/xenlight: remove call to go fmt = in gengotypes.py >=20 > CC=E2=80=99ing release manager >=20 > > On Jun 8, 2020, at 12:39 PM, George Dunlap = wrote: > > > >> > >> On Jun 6, 2020, at 5:10 PM, Nick Rosbrook = wrote: > >> > >> Since the golang bindings are now set to be re-generated whenever a > >> change is made to tools/libxl/libxl_types.idl, the call to go fmt = in > >> gengotypes.py results in a dirty git tree for users without go > >> installed. > >> > >> As an immediate fix, just remove the call to go fmt from = gengotypes.py. > >> While here, make sure the DO NOT EDIT comment and package = declaration > >> remain formatted correctly. All other generated code is left > >> un-formatted for now. > >> > >> Signed-off-by: Nick Rosbrook > > > > Reviewed-by: George Dunlap >=20 > Paul, this is a fix to the build system that only affects the = formatting of some generated code. (At > the moment, the generated code will look differently depending on = whether you have golang installed or > not.) Ok, that sounds low risk. Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Mon Jun 08 15:07:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 15:07:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJMo-0005oC-NG; Mon, 08 Jun 2020 15:07:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJMn-0005o4-Ld for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 15:07:13 +0000 X-Inumbo-ID: bad64dce-a999-11ea-b28d-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bad64dce-a999-11ea-b28d-12813bfff9fa; Mon, 08 Jun 2020 15:07:12 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 0TPijvVH2saqwdi8Wesv0zmlAiKq6hvHLneDATXFeNK8+2NIi77IthaCO5OGpS9KBP6UgI1TsH v+Fd6ecEy9joq8vqb6N1Mj1Sbcj5xm095WxdZgr6kB/s+zIiSAJiANd0W+ElLqEF7rxnPy8z2w Dob0ivQcHDPxE0jYZR8ZlYBA5Pj67TaBnvtun8UcBkOrb4KsovcVQzdLyAXh+1ottDq8cf6DJI TQGe/Qga4ZVuet/GLF8Yo/Tbg2xHxk7SRZIp5nYj3oFMhUKxHurIudwWzZaUHg3IwW0RihNDJZ iuA= X-SBRS: 2.7 X-MesageID: 19505789 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19505789" From: George Dunlap To: Ian Jackson Subject: Re: 4.14.0-rc1 blocked on goland build failure - decision needed Thread-Topic: 4.14.0-rc1 blocked on goland build failure - decision needed Thread-Index: AQHWPaORQPtYscwMOUSBGUclg/JjvajOqv0AgAAFKQA= Date: Mon, 8 Jun 2020 15:07:08 +0000 Message-ID: <4DD3680F-7EE6-4C97-B070-DFFE86AE7D4A@citrix.com> References: <005201d635a9$2b9bbc20$82d33460$@xen.org> <2C4D8F6A-1498-4F13-923C-AAF2960D531F@citrix.com> <007401d635c2$6b14a150$413de3f0$@xen.org> <001201d63b5b$d8ebe7d0$8ac3b770$@xen.org> <002901d63d7f$2301a6a0$6904f3e0$@xen.org> <24286.12984.247498.799575@mariner.uk.xensource.com> <003001d63d93$9a4bbcf0$cee336d0$@xen.org> <24286.18072.880121.172973@mariner.uk.xensource.com> <003301d63d9e$97de3e60$c79abb20$@xen.org> <24286.20279.622221.291800@mariner.uk.xensource.com> <24286.20424.998938.535648@mariner.uk.xensource.com> In-Reply-To: <24286.20424.998938.535648@mariner.uk.xensource.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <8867DBA564D79D4A86700B4E0682CBBE@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Nick Rosbrook , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gSnVuIDgsIDIwMjAsIGF0IDM6NDggUE0sIElhbiBKYWNrc29uIDxpYW4uamFja3Nv bkBjaXRyaXguY29tPiB3cm90ZToNCj4gDQo+IElhbiBKYWNrc29uIHdyaXRlcyAoIjQuMTQuMC1y YzEgYmxvY2tlZCBvbiBnb2xhbmQgYnVpbGQgZmFpbHVyZSAtIGRlY2lzaW9uIG5lZWRlZCIpOg0K Pj4gSGksIFBhdWwuICBGb3IgdGhvc2Ugb24geGVuLWRldmVsOiBjb250ZXh0IGlzIHRoYXQgUGF1 bCBhc2tlZCBtZSB0bw0KPj4gY3V0IDQuMTQuMC1yYzEuICBUaGUgY2hlY2tsaXN0IGFza3MgbWUg dG8gcGVyZm9ybSBhIHRlc3QgYnVpbGQuDQo+PiANCj4+IE15IDMyLWJpdCB0b29scyB0ZXN0IGJ1 aWxkIGZhaWxlZC4gIEkgdGhpbmsgdGhlIHByb2JsZW0gaXMgcHJvYmFibHkNCj4+IHNwZWNpZmlj IHRvIDMyLWJpdCB1c2VybGFuZCBvbiA2NC1iaXQgTGludXgga2VybmVsLiAgSSB3aWxsIHNlbmQg YQ0KPj4gc2Vjb25kIGZvbGxvd3VwIG1haWwgbm90IENDIFBhdWwgd2l0aCB0ZWNobmljYWwgZGV0 YWlscy4NCj4gDQo+IFRlY2huaWNhbCBkZXRhaWxzQDoNCj4gDQo+IFRoZSBmaXJzdCBlcnJvciBs b29rcyBsaWtlIHRoaXM6DQo+IA0KPiAuL2hlbHBlcnMuZ2VuLmdvOjkwMVsvdG1wL2dvLWJ1aWxk NjQzMTU4Njg2L18vdS9pd2ovd29yay94ZW4uZ2l0L3Rvb2xzL2dvbGFuZy94ZW5saWdodC9fb2Jq L2hlbHBlcnMuZ2VuLmNnbzEuZ286MTE3Ml06DQo+IHR5cGUgWzI2ODQzNTQ1Nl1fQ3R5cGVfc3Ry dWN0X2xpYnhsX3NjaGVkX3BhcmFtcyBsYXJnZXIgdGhhbiBhZGRyZXNzDQo+IHNwYWNlDQoNCkFj dHVhbGx5LCBJIGRvbuKAmXQgdGhpbmsgdGhpcyBoYXMgYW55dGhpbmcgdG8gZG8gd2l0aCAzMi1i aXQgdXNlcnNwYWNlLCBidXQgaW5zdGVhZCBoYXMgdG8gZG8gd2l0aCB0aGUgdmVyc2lvbiBvZiBn bzogVGhlIHZlcnNpb24gaW4gc3RyZXRjaCBpcyAxLjcgYW5kIGNob2tlcyBvbiB0aGlzIGZvciBz b21lIHJlYXNvbi4gIEkgaGF2ZW7igJl0IGhhZCB0aW1lIHRvIHRyYWNrIGRvd24gd2h5LiAgSXQg ZG9lcyB3b3JrIGZvciBnb2xhbmcgMS4xMS4NCg0KT3B0aW9ucyBhcmU6DQoNCjEuIERvY3VtZW50 IHRoYXQgaWYgeW91IGhhdmUgYSB2ZXJzaW9uIG9mIGdvbGFuZyBvbGRlciB0aGFuIDEuMTEsIHlv dSBuZWVkIHRvIGFkZCBg4oCUZGlzYWJsZS1nb2xhbmdgIA0KDQoyLiBNb2RpZnkgY29uZmlndXJl IHRvIGNoZWNrIGZvciB0aGUgZ28gdmVyc2lvbiwgYW5kIG9ubHkgZW5hYmxlIGlmIHRoZSB2ZXJz aW9uIGlzID4gMS4xMQ0KDQozLiBUcnkgdG8gcm9vdC1jYXVzZSB0aGUgaXNzdWUuDQoNCknigJlt IGluY2xpbmVkIHRvIHNheSB3ZSBzaG91bGQgZ28gd2l0aCAjMSBmb3IgdGhpcyBSQywgdGhlbiBl aXRoZXIgIzIgb3IgIzMuDQoNCiAtR2VvcmdlDQoNCg== From xen-devel-bounces@lists.xenproject.org Mon Jun 08 15:15:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 15:15:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJUj-0006uL-To; Mon, 08 Jun 2020 15:15:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJUi-0006uG-MC for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 15:15:24 +0000 X-Inumbo-ID: dfbad9ec-a99a-11ea-96fb-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dfbad9ec-a99a-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 15:15:23 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: iUCmOXMdZG+HF4p9TX04tVXlCNTQQYV4PuUveK3lr/b7BcmdnOY+lIk2xHnEccd71XpE8PW3ef TOHd2pNaR/x/vUWktFTUH/QWbl8dLzOHmxuoPgXaRQ/6WxSYOReTBWb8hFaiFwTDU+qe+ZXqLt 5CMi7dTza1erwETLhiX0XZ4em21DnUVr4+8sAWv4f+Qvs5rSBDQmnVpkQEwknAigEFa8Jzo7P6 a7heS3orSCzPNTiNO6Niub2of3gnXnCYChdqztNFglCCrUL8SGXvxglkUMGvACGGgmNBihj386 BSA= X-SBRS: 2.7 X-MesageID: 20244468 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="20244468" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <24286.22007.498299.812546@mariner.uk.xensource.com> Date: Mon, 8 Jun 2020 16:15:03 +0100 To: "paul@xen.org" Subject: Re: 4.14.0-rc1 blocked on goland build failure - decision needed [and 1 more messages] In-Reply-To: <24286.20279.622221.291800@mariner.uk.xensource.com>, <4DD3680F-7EE6-4C97-B070-DFFE86AE7D4A@citrix.com> References: <005201d635a9$2b9bbc20$82d33460$@xen.org> <2C4D8F6A-1498-4F13-923C-AAF2960D531F@citrix.com> <007401d635c2$6b14a150$413de3f0$@xen.org> <001201d63b5b$d8ebe7d0$8ac3b770$@xen.org> <002901d63d7f$2301a6a0$6904f3e0$@xen.org> <24286.12984.247498.799575@mariner.uk.xensource.com> <003001d63d93$9a4bbcf0$cee336d0$@xen.org> <24286.18072.880121.172973@mariner.uk.xensource.com> <003301d63d9e$97de3e60$c79abb20$@xen.org> <24286.20279.622221.291800@mariner.uk.xensource.com> <24286.20424.998938.535648@mariner.uk.xensource.com> <4DD3680F-7EE6-4C97-B070-DFFE86AE7D4A@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , George Dunlap , Wei Liu , Nick Rosbrook Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Ian Jackson writes ("4.14.0-rc1 blocked on goland build failure - decision needed"): > Hi, Paul. For those on xen-devel: context is that Paul asked me to > cut 4.14.0-rc1. The checklist asks me to perform a test build. > > My 32-bit tools test build failed. I think the problem is probably > specific to 32-bit userland on 64-bit Linux kernel. I will send a > second followup mail not CC Paul with technical details. George Dunlap writes ("Re: 4.14.0-rc1 blocked on goland build failure - decision needed"): > Actually, I don’t think this has anything to do with 32-bit userspace, but instead has to do with the version of go: The version in stretch is 1.7 and chokes on this for some reason. I haven’t had time to track down why. It does work for golang 1.11. > > Options are: > > 1. Document that if you have a version of golang older than 1.11, you need to add `—disable-golang` I suggest we do this for -rc1 and then consider our options. I have added this option to my pre-release test build and the build works now. > 2. Modify configure to check for the go version, and only enable if the version is > 1.11 > > 3. Try to root-cause the issue. > > I’m inclined to say we should go with #1 for this RC, then either #2 or #3. Also please send a patch to osstest to install the relevant golang packages. Even for stretch where it won't be supported. Currently I would expect that patch to cause tests to regress, so the corresponding xen patch(es) should go in (and be backported) first. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 15:16:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 15:16:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJW0-00070P-8x; Mon, 08 Jun 2020 15:16:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJVz-00070G-8V for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 15:16:43 +0000 X-Inumbo-ID: 0ed74aee-a99b-11ea-96fb-bc764e2007e4 Received: from mail-wm1-x333.google.com (unknown [2a00:1450:4864:20::333]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0ed74aee-a99b-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 15:16:42 +0000 (UTC) Received: by mail-wm1-x333.google.com with SMTP id l17so4514256wmj.0 for ; Mon, 08 Jun 2020 08:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=slAlGXN2lNiv7lzMWzgpBJP4WjraHflYW9VTTNyCRHQ=; b=ueN2qYZXeyEGlQyksjTyX7/GCONr8w8wbX/ZBW9AKCkMQWOOFD6jPPkA1hLySBSzJE Lic5KBnpo+OsDRaKyUKhIL9BRfEYIRMy5pHlUUzaQM3SOv6AoiJ5q3nbsh6BqZulBrI/ gSwu44wBuxdtHX1oc5UmT2CeUznjPsEhwTYrWsYi5zGuhw6gTce+WZ/1nwKrYd0OI939 LCANy5c0n5Uv44SDUWROmzLnMShwAtaXz5GDAuiQULZ5LbdzxgMMAFU1bfzyjeEi/sMU Mun6AdeHGuvV//131MhMalGC5iDhAolFX5R9aGrzvN1zJOzfS9pHAkFUaID6yFU/C/Q5 EaHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=slAlGXN2lNiv7lzMWzgpBJP4WjraHflYW9VTTNyCRHQ=; b=OKlsgcEuEAsayMqDDc/YuAt4raryTE8VUJqqAQx8/tiDoM/rbblrJO0Cwx1B1MfQl6 vmzwrRw5mXzyRMowki6SEACuW4/dBi7oVJBjYZwJy6wusnrFsXeIA4C2qnogCZmSkikh ZvcQva+nMqVfSu6ftwBGBK5loFB8vBz9Xk/IRpNfhgZzTyTJprXUcrkVHiMPPmFBj6lI rv2d2OU33+WTCkI2brD3HfxJRqBokKt7tMZo5xnwtlTxpI9PD8xSJiSNGwl83U9wBwxu eyF9HH1ABmX//iUvEO+Tqj7/k61Gy2Q2kaIvYA7Zhg8u3TZsEEgI1o4E4IyCxELGvEwV 8t+w== X-Gm-Message-State: AOAM531cxmJfDNQ2Grm2C0azkqA0GXM9NTYBe8GkjVh1nbC4ftHTPrtW Sd0X4gZcGwdjrkS1NmP8/5c= X-Google-Smtp-Source: ABdhPJxdsEkaCsA0kvIIMn1GJhnrJ7nbRRF7rhwQ9l/KnH3JVJ67hLZHdBTuATXtGYQCc2lGsNeHEg== X-Received: by 2002:a1c:49c1:: with SMTP id w184mr16465394wma.46.1591629401511; Mon, 08 Jun 2020 08:16:41 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id a1sm22325459wmj.29.2020.06.08.08.16.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 08:16:40 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'George Dunlap'" , "'Ian Jackson'" References: <005201d635a9$2b9bbc20$82d33460$@xen.org> <2C4D8F6A-1498-4F13-923C-AAF2960D531F@citrix.com> <007401d635c2$6b14a150$413de3f0$@xen.org> <001201d63b5b$d8ebe7d0$8ac3b770$@xen.org> <002901d63d7f$2301a6a0$6904f3e0$@xen.org> <24286.12984.247498.799575@mariner.uk.xensource.com> <003001d63d93$9a4bbcf0$cee336d0$@xen.org> <24286.18072.880121.172973@mariner.uk.xensource.com> <003301d63d9e$97de3e60$c79abb20$@xen.org> <24286.20279.622221.291800@mariner.uk.xensource.com> <24286.20424.998938.535648@mariner.uk.xensource.com> <4DD3680F-7EE6-4C97-B070-DFFE86AE7D4A@citrix.com> In-Reply-To: <4DD3680F-7EE6-4C97-B070-DFFE86AE7D4A@citrix.com> Subject: RE: 4.14.0-rc1 blocked on goland build failure - decision needed Date: Mon, 8 Jun 2020 16:16:39 +0100 Message-ID: <004601d63da7$cfb6e130$6f24a390$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIaeB+1Kz8Govl7rZttW9upK8TBlwIZlrSiAxctqLUBbsg43wDSk/u8AT2fc60C5R01eQHMeLN5Agjw9U0CAC8hYQFsnKCQAIbCGoEAzoV5uKek/GVA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Xen-devel' , 'Nick Rosbrook' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = George Dunlap > Sent: 08 June 2020 16:07 > To: Ian Jackson > Cc: Xen-devel ; Nick Rosbrook = ; Wei Liu > > Subject: Re: 4.14.0-rc1 blocked on goland build failure - decision = needed >=20 >=20 >=20 > > On Jun 8, 2020, at 3:48 PM, Ian Jackson = wrote: > > > > Ian Jackson writes ("4.14.0-rc1 blocked on goland build failure - = decision needed"): > >> Hi, Paul. For those on xen-devel: context is that Paul asked me to > >> cut 4.14.0-rc1. The checklist asks me to perform a test build. > >> > >> My 32-bit tools test build failed. I think the problem is probably > >> specific to 32-bit userland on 64-bit Linux kernel. I will send a > >> second followup mail not CC Paul with technical details. > > > > Technical details@: > > > > The first error looks like this: > > > > ./helpers.gen.go:901[/tmp/go- > = build643158686/_/u/iwj/work/xen.git/tools/golang/xenlight/_obj/helpers.ge= n.cgo1.go:1172]: > > type [268435456]_Ctype_struct_libxl_sched_params larger than address > > space >=20 > Actually, I don=E2=80=99t think this has anything to do with 32-bit = userspace, but instead has to do with the > version of go: The version in stretch is 1.7 and chokes on this for = some reason. I haven=E2=80=99t had time > to track down why. It does work for golang 1.11. >=20 > Options are: >=20 > 1. Document that if you have a version of golang older than 1.11, you = need to add `=E2=80=94disable-golang` >=20 > 2. Modify configure to check for the go version, and only enable if = the version is > 1.11 >=20 > 3. Try to root-cause the issue. >=20 > I=E2=80=99m inclined to say we should go with #1 for this RC, then = either #2 or #3. >=20 Agreed. Let's go with #1. Paul From xen-devel-bounces@lists.xenproject.org Mon Jun 08 15:34:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 15:34:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJn9-0000O6-Pe; Mon, 08 Jun 2020 15:34:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJn9-0000O0-0I for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 15:34:27 +0000 X-Inumbo-ID: 88d8ba60-a99d-11ea-ba62-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 88d8ba60-a99d-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 15:34:26 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: OSOzI/S9SdHMMMoYJ/idIib469zGCXmjGriGi37nbNQRB/62RRlc4TwlRUNwS10SEZSre+1XIX 1SEG2YMhpPkz/d8oasXt4EWfZOCjpdieXRXtFNICOnRWR8eP0lu5mJoM6aCTyVeyrJOzoSAqTt PCX9rJo6qzG8RnhP6lMRPAK74Pjqhihq4vYs0ybC1j1u1gcKVz8irWcHykT5ijKymNPF+rJfbG 11X1c1pxDkQUPRq5+n6bHrjmQ1HfCrZDc8a8OIGwLebEwLOmMIxJu7ATAOhxzUHbwEVT1Z0WiB mW4= X-SBRS: 2.7 X-MesageID: 20246350 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="20246350" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24286.23167.134656.772769@mariner.uk.xensource.com> Date: Mon, 8 Jun 2020 16:34:23 +0100 To: "paul@xen.org" Subject: RE: [OSSTEST PATCH v2 00/49] Switch to Debian buster (= Debian stable) In-Reply-To: <24273.3201.443254.296963@mariner.uk.xensource.com> References: <20200529111945.21394-1-ian.jackson@eu.citrix.com> <005401d635ac$90bf9510$b23ebf30$@xen.org> <24273.3201.443254.296963@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "committers@xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Ian Jackson writes ("RE: [OSSTEST PATCH v2 00/49] Switch to Debian buster (= Debian stable)"): > Paul Durrant writes ("RE: [OSSTEST PATCH v2 00/49] Switch to Debian buster (= Debian stable)"): > > I assume we can revert if things go badly wrong and being able to commission more machines would seem to be quite beneficial at this > > stage. > > Thanks for your opinion. > > It would be possible to revert the final switch, yes. Most of the > other changes are supposed to work with stretch too. > > I haven't done a test run with the new code, but the old version of > Debian. I will do that. That will give confidence that we could, in > fact, revert things. I have now done this and it resulted in one bugfix. So if you are still content to go ahead I would like to push this series to osstest's own self-push-gate now. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 15:36:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 15:36:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJow-0000Ud-8w; Mon, 08 Jun 2020 15:36:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiJou-0000UN-FA for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 15:36:16 +0000 X-Inumbo-ID: ca25e8c6-a99d-11ea-9ad7-bc764e2007e4 Received: from mail-wr1-x436.google.com (unknown [2a00:1450:4864:20::436]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ca25e8c6-a99d-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 15:36:15 +0000 (UTC) Received: by mail-wr1-x436.google.com with SMTP id p5so17874573wrw.9 for ; Mon, 08 Jun 2020 08:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=AAdcvwLZEYI8tW/dlfliX8u319uzIusm9C4VQdniWLg=; b=Enqy1cZh2wmktILWp2+F+fSHFRTeMrWYTkRpE25+gqstDsFsQoYN8plq8Wu2xQ2rrY svCf1QXbmKtY4TgzpH30TkmVAh25nB69q9N6JsO+GVpo2NDx5t9MG2GPcq3eSmd3svrr 88X9jCGUX9SlKRY+jrDNOgd5wDf0Nkgb3s1VRHNoihS9rJK5f968yXKzr08w2N3j4or5 b8fV3qbQec6Zu9wUGuGewroJJWFDhut5oG+GcuU04h0WPkkgJ29s4ODXV2H4nqf42Ebu 5eRs5UN+JNL0uj79Bkx+fUWo01JFWYYi1iajU4fQVvUTaVnAdMsvr0Ag8oLWrlzPcfhn pTBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=AAdcvwLZEYI8tW/dlfliX8u319uzIusm9C4VQdniWLg=; b=fkTI0UsW4sCENIRXPUPqjVzDrk4s9Y0dXpZIqx2bnIfhPnZO1RbCnP0Lk6vHuATOHO 7RfMGhxn4qGvO7ycD5iP+QmCQ+uEmaZ/D25B9wyGHdDQhFt8+Vpj+ZgyQrWtdRDsbaBt jnV/oKvqP2t0XcKuSWlppAA8uC+lOsGseDrUCFp53P3VzNVDjdbcCxDVepFXGaG7Hwzd Zp7uVKTht2NAJ8C1db444VlylO9zHgUJ5rGkDDaRmRPg9GNoVO8FSp5f7Ih1wY2rhJ2X G/IxVJOdlEzOA/l19eq0QQZXPCsv0+7nmyEcQ0pFAD5/qqjibYRov5szPJtZLy/Qpj01 6HCA== X-Gm-Message-State: AOAM531qTyLCG0bzwDpz296TmKShymlg2b++Q4s8wsi3fGFzeQDmPyid vwlBco92cIt08mKMqTeNSD4= X-Google-Smtp-Source: ABdhPJz6CXkJXj542mRPT43Ybb+edrNpkeRNN3qtZNX0B2y5pLf6Fg0U57N0sM+FBaIAne0+pfRb0A== X-Received: by 2002:adf:ee47:: with SMTP id w7mr23643932wro.171.1591630575092; Mon, 08 Jun 2020 08:36:15 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id m24sm22418930wmi.14.2020.06.08.08.36.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 08:36:14 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" References: <20200529111945.21394-1-ian.jackson@eu.citrix.com> <005401d635ac$90bf9510$b23ebf30$@xen.org> <24273.3201.443254.296963@mariner.uk.xensource.com> <24286.23167.134656.772769@mariner.uk.xensource.com> In-Reply-To: <24286.23167.134656.772769@mariner.uk.xensource.com> Subject: RE: [OSSTEST PATCH v2 00/49] Switch to Debian buster (= Debian stable) Date: Mon, 8 Jun 2020 16:36:13 +0100 Message-ID: <004701d63daa$8b507990$a1f16cb0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQH6xReBsxPpGuE++Yl5QcE4sAtmFQJToowUAPtJVU4ByVZJkKhdCLKg X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, committers@xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 08 June 2020 16:34 > To: paul@xen.org > Cc: xen-devel@lists.xenproject.org; committers@xenproject.org > Subject: RE: [OSSTEST PATCH v2 00/49] Switch to Debian buster (= Debian stable) > > Ian Jackson writes ("RE: [OSSTEST PATCH v2 00/49] Switch to Debian buster (= Debian stable)"): > > Paul Durrant writes ("RE: [OSSTEST PATCH v2 00/49] Switch to Debian buster (= Debian stable)"): > > > I assume we can revert if things go badly wrong and being able to commission more machines would > seem to be quite beneficial at this > > > stage. > > > > Thanks for your opinion. > > > > It would be possible to revert the final switch, yes. Most of the > > other changes are supposed to work with stretch too. > > > > I haven't done a test run with the new code, but the old version of > > Debian. I will do that. That will give confidence that we could, in > > fact, revert things. > > I have now done this and it resulted in one bugfix. > > So if you are still content to go ahead I would like to push this > series to osstest's own self-push-gate now. > Yes, I am content to go ahead. Paul From xen-devel-bounces@lists.xenproject.org Mon Jun 08 15:55:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 15:55:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiK7W-0002CM-Pm; Mon, 08 Jun 2020 15:55:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiK7V-0002CH-Em for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 15:55:29 +0000 X-Inumbo-ID: 78f65622-a9a0-11ea-b292-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 78f65622-a9a0-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 15:55:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 5A809AAE8; Mon, 8 Jun 2020 15:55:30 +0000 (UTC) Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Alexandru Isaila , Petre Pircalabu References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> From: Jan Beulich Message-ID: Date: Mon, 8 Jun 2020 17:55:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200603150721.GF1195@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Julien Grall , Razvan Cojocaru , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Stefano Stabellini , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03.06.2020 17:07, Roger Pau Monné wrote: > On Wed, Jun 03, 2020 at 06:52:37AM -0600, Tamas K Lengyel wrote: >> For the last couple years we have received numerous reports from users of >> monitor vm_events of spurious guest crashes when using events. In particular, >> it has observed that the problem occurs when vm_events are being disabled. The >> nature of the guest crash varied widely and has only occured occasionally. This >> made debugging the issue particularly hard. We had discussions about this issue >> even here on the xen-devel mailinglist with no luck figuring it out. >> >> The bug has now been identified as a race-condition between register event >> handling and disabling the monitor vm_event interface. The default behavior >> regarding emulation of register write events is changed so that they get >> postponed until the corresponding vm_event handler decides whether to allow such >> write to take place. Unfortunately this can only be implemented by performing the >> deny/allow step when the vCPU gets scheduled. >> >> Due to that postponed emulation of the event if the user decides to pause the >> VM in the vm_event handler and then disable events, the entire emulation step >> is skipped the next time the vCPU is resumed. Even if the user doesn't pause >> during the vm_event handling but exits immediately and disables vm_event, the >> situation becomes racey as disabling vm_event may succeed before the guest's >> vCPUs get scheduled with the pending emulation task. This has been particularly >> the case with VMS that have several vCPUs as after the VM is unpaused it may >> actually take a long time before all vCPUs get scheduled. >> >> In this patch we are reverting the default behavior to always perform emulation >> of register write events when the event occurs. To postpone them can be turned >> on as an option. In that case the user of the interface still has to take care >> of only disabling the interface when its safe as it remains buggy. >> >> Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event >> reply'). >> >> Signed-off-by: Tamas K Lengyel > > Thanks! > > Reviewed-by: Roger Pau Monné > > I would like to get some input from Bitdefender really, and whether > they are fine with this approach. Alexandru, Petre, have the two of you seen this request? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 15:56:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 15:56:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiK8I-0002EV-2j; Mon, 08 Jun 2020 15:56:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiK8H-0002EP-Gr for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 15:56:17 +0000 X-Inumbo-ID: 96097db6-a9a0-11ea-b292-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 96097db6-a9a0-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 15:56:17 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: TdRVyyo1WdLADr7FIMNHOZuR+T+wR9CKWiMtxMpEb3QPJgm/ybSpj2olenmc5Yzzipw/SqPL5E RM3hdg5St3t51PeEqInlFaENnzNAApIPJ51WiQASDUUkcijtq3Im4ibtKYg5wjMx9cHjRAa+F4 XSQO5LyK6YcR0bFzsNZcesRPFrJp/l0E9nwBNVDoLnvTHf7GY4KwiUben+B0SwQM9rU7qyue3Q y9emQU14tSTkQXrkhOOs8dEQd0i/S30ziZwFPVGOux0yAMfnHvUUYMRowm0dcHyG79bpvGfH1l ytk= X-SBRS: 2.7 X-MesageID: 19491858 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19491858" Date: Mon, 8 Jun 2020 17:56:06 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 v3] x86/rtc: provide mediated access to RTC for PVH dom0 Message-ID: <20200608155606.GB722@Air-de-Roger> References: <20200608102948.7327-1-roger.pau@citrix.com> <71e0d073-165b-8fcc-62b9-3fb028b3c526@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <71e0d073-165b-8fcc-62b9-3fb028b3c526@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 08, 2020 at 01:47:26PM +0200, Jan Beulich wrote: > On 08.06.2020 12:29, Roger Pau Monne wrote: > > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > > code paths (guest_io_{write/read}), but those accesses where never > > implemented for PVHv2 dom0. This patch provides such mediated accesses > > to the RTC for PVH dom0, just like it's provided for a classic PV > > dom0. > > > > Pull out some of the RTC logic from guest_io_{read/write} into > > specific helpers that can be used by both PV and HVM guests. The > > setup of the handlers for PVH is done in rtc_init, which is already > > used to initialize the fully emulated RTC. > > > > Without this a Linux PVH dom0 will read garbage when trying to access > > the RTC, and one vCPU will be constantly looping in > > rtc_timer_do_work. > > > > Note that such issue doesn't happen on domUs because the ACPI > > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > > accesses are not emulated but rather forwarded to the physical > > hardware. > > > > No functional change expected for classic PV dom0. > > > > Signed-off-by: Roger Pau Monné > > Reviewed-by: Jan Beulich > preferably with ... > > > @@ -1110,6 +1111,67 @@ static unsigned long get_cmos_time(void) > > return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); > > } > > > > +/* Helpers for guest accesses to the physical RTC. */ > > +unsigned int rtc_guest_read(unsigned int port) > > +{ > > + const struct domain *currd = current->domain; > > + unsigned long flags; > > + unsigned int data = ~0; > > + > > + switch ( port ) > > + { > > + case RTC_PORT(0): > > + /* > > + * All PV domains are allowed to read the latched value of the first > > + * RTC port. This is useful in order to store data when debugging. > > + */ > > ... at least the 2nd sentence of this and ... > > > +void rtc_guest_write(unsigned int port, unsigned int data) > > +{ > > + struct domain *currd = current->domain; > > + unsigned long flags; > > + > > + switch ( port ) > > + { > > + case RTC_PORT(0): > > + /* > > + * All PV domains are allowed to write to the latched value of the > > + * first RTC port. This is useful in order to store data when > > + * debugging. > > + */ > > ... this comment dropped again. This justification of the possible > usefulness is my very private guessing. Just like the original code > was, I think we could leave this uncommented altogether. Hm, as you wish. I would prefer to leave something similar to the first part of the comment, what about: /* * All PV domains (and PVH dom0) are allowed to write/read to the * latched value of the first RTC port, as there's no access to the * physical IO ports. */ I can adjust and then add a newline after the break in the RTC_PORT(0) case which I missed. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKCu-0003dU-Ur; Mon, 08 Jun 2020 16:01:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKCs-0003dE-P0 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:03 +0000 X-Inumbo-ID: 4048688c-a9a1-11ea-96fb-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 4048688c-a9a1-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 16:01:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632062; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=awCHYAXUOGkS+dWmNDQ4SQqbGqK/3LMSf+67fZKCnc0=; b=hGxdcVcsKerpNh8hVCPX8Y1x22DRvRxYIw46laa93thi57uFOujzCSQzFi9PtKIQezKVBo k9BS5sBLplQdy7CefpaEVoIdGL2pyabxn2+RT+UCZ/dPJbinJ4bpKejEcTk3aYhxNaf563 bx1J2Z+T7jhovnySAi5yyjuNkqp3rLQ= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-444-jxBAYABvNP-dfB1xUFNYOQ-1; Mon, 08 Jun 2020 12:00:58 -0400 X-MC-Unique: jxBAYABvNP-dfB1xUFNYOQ-1 Received: by mail-wr1-f72.google.com with SMTP id e1so7365875wrm.3 for ; Mon, 08 Jun 2020 09:00:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=awCHYAXUOGkS+dWmNDQ4SQqbGqK/3LMSf+67fZKCnc0=; b=jaf1vPJvewdOa7scZRM/7jlONt9wuY8S40MAt9jKMvW0+/DTgwZhHmjcW/uCEWOFmP kLKINGyoN5L+Gxd/o5QEeoKTVd/4vQckdOMRwkU8l4gdGTwKA8SCgf3P0uS0LrN/wCAM CUROka6HthXHjjvmlq3adrNSqY2vvobEalioZ9RbhMgrntXcJ+Sm54embelSwSKyb3ki 05GbxMAQ4ZbneFBrJ10BwjzAsLZXPEFuha/JaRf3nDk2wZfQBzx+rL1/APlEnkErEA2b tD8vGCo8Y2g2PShWMQJLyLMq8UteUo8fSIzq6RLF+1IZZ/Hrp+4UY9Kg5vSoL8TrPLz0 jclw== X-Gm-Message-State: AOAM533LstCtlvmY/HyQ4Lh0BRqzq7IOJPhF484RjsppIhNUpVXf5mXN T6zNIi8CWXAmZbJyhspz5OaQND9fATu2/r9o/RaAyqSvcqNqvy7kzT5nuP+Y/Nyiaj+uHNFwiu8 PFS63X/x6uiWFJhKAqxr7B/dUKfM= X-Received: by 2002:a1c:a3c5:: with SMTP id m188mr48570wme.152.1591632053816; Mon, 08 Jun 2020 09:00:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJziyL5raG4PwAXzO4TG14Cp0iz1q12d2PaRjnoEeXVkhA3kNQMidurFs0yP2smspC0uLUhA1g== X-Received: by 2002:a1c:a3c5:: with SMTP id m188mr48526wme.152.1591632053569; Mon, 08 Jun 2020 09:00:53 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id w10sm187197wrp.16.2020.06.08.09.00.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:00:53 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 01/35] qom/object: Update documentation Date: Mon, 8 Jun 2020 18:00:10 +0200 Message-Id: <20200608160044.15531-2-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The documentation was introduced in 2f28d2ff9dc, then 0d09e41a51 and a27bd6c77 moved the headers around. Update the comment. Signed-off-by: Philippe Mathieu-Daudé --- include/qom/object.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/qom/object.h b/include/qom/object.h index fd453dc8d6..eb560bf32f 100644 --- a/include/qom/object.h +++ b/include/qom/object.h @@ -45,7 +45,7 @@ typedef struct InterfaceInfo InterfaceInfo; * * Creating a minimal type * - * #include "qdev.h" + * #include "hw/qdev-core.h" * * #define TYPE_MY_DEVICE "my-device" * @@ -146,7 +146,7 @@ typedef struct InterfaceInfo InterfaceInfo; * * Overriding a virtual function * - * #include "qdev.h" + * #include "hw/qdev-core.h" * * void my_device_class_init(ObjectClass *klass, void *class_data) * { @@ -170,7 +170,7 @@ typedef struct InterfaceInfo InterfaceInfo; * * Defining an abstract class * - * #include "qdev.h" + * #include "hw/qdev-core.h" * * typedef struct MyDeviceClass * { -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKCt-0003dK-LZ; Mon, 08 Jun 2020 16:01:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKCs-0003dF-Pj for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:03 +0000 X-Inumbo-ID: 40430748-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 40430748-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:01:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632062; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5qtqeym41wYPVUNcQP0hBuZd3ZN8CptiJr597zGfRw0=; b=ZJ1bmmLC8MzdFyhdJ/AYRnrDCyOMjqlp8Q3RNPHP7aw673+RFfO7MAjat4egBPWFlRoMh5 KlHhjiLzfymReJojXx53IxMXyUGhDC0Q6sYBvyofF8yCZCYEuoHuDCuVigj6NumCRljMpS QBJbsDReAANM/DWECAyami/OuifkIMs= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-10-C-IMLKm3NzqOEfEVx2yPtQ-1; Mon, 08 Jun 2020 12:01:00 -0400 X-MC-Unique: C-IMLKm3NzqOEfEVx2yPtQ-1 Received: by mail-wm1-f72.google.com with SMTP id u15so5404wmm.5 for ; Mon, 08 Jun 2020 09:01:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=5qtqeym41wYPVUNcQP0hBuZd3ZN8CptiJr597zGfRw0=; b=T/CW8MhPLSTsSekEBE7TOoMqN2r8RLgDznvRKxD5Gn+lBgqSd+7f4s846wxkuScrmH 5ghQoXHzNUtx0t6pAutF8m6ZnKtZlYpnchEBeuXd68H079NZ8tDcZ9L+IINj4qeoqNnH DpR/NW9KKd/8P2kbCbms/IylTTcwD9v2VhlLlE1F565m2z3EJWK5iJVKu1XwgDOQ3lxT OU8IcUxgzHoFSJt2gWSl0NPByO5RoS7/jfx7ZdYQCyvmgSWherHScZjdZhtoQK2JgsBD 1VK10V1OjiTcr0ahfRB4FRNlML4yUwS1MY76dUYDTo0Icfr02wumoS4UFjVDrTSCNGOf NBug== X-Gm-Message-State: AOAM532O2A1NqDkp5rSc6oevguzjV6OtQiTWa6qKFehDQ1KyB4EgU0e0 uLNs8IBUtE7Wq5sKgq7uJAOEQeTlsxC1RFYt2rdrCZ2rZCWNCzze8o6Vs7blkWRubjpzyi61mQA dcEc9NWxaq2r2ZgBNEcBiG08wrxU= X-Received: by 2002:adf:de0b:: with SMTP id b11mr24236310wrm.346.1591632059271; Mon, 08 Jun 2020 09:00:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCLkZjArfyp0BDfLlr7paJJyNdZb8aPEICM5cLMV+w6rNjL53A+D/YIALTIycqApB88KkdKg== X-Received: by 2002:adf:de0b:: with SMTP id b11mr24236267wrm.346.1591632059025; Mon, 08 Jun 2020 09:00:59 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id z12sm227313wrg.9.2020.06.08.09.00.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:00:58 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 02/35] hw/core/qdev: Add qdev_warn_deprecated_function_used() helper Date: Mon, 8 Jun 2020 18:00:11 +0200 Message-Id: <20200608160044.15531-3-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" When built with --enable-qdev-deprecation-warning, calling qdev_warn_deprecated_function_used() will emit a warning such: $ qemu-system-arm -M verdex ... qemu-system-arm: warning: use of deprecated non-qdev/non-qom code in pxa2xx_lcdc_init() qemu-system-arm: warning: use of deprecated non-qdev/non-qom code in pxa2xx_i2s_init() qemu-system-arm: warning: use of deprecated non-qdev/non-qom code in pxa27x_keypad_init() Signed-off-by: Philippe Mathieu-Daudé --- configure | 8 ++++++++ include/hw/qdev-deprecated.h | 26 ++++++++++++++++++++++++++ hw/core/qdev.c | 8 ++++++++ 3 files changed, 42 insertions(+) create mode 100644 include/hw/qdev-deprecated.h diff --git a/configure b/configure index 597e909b53..9b7a8927c6 100755 --- a/configure +++ b/configure @@ -434,6 +434,7 @@ edk2_blobs="no" pkgversion="" pie="" qom_cast_debug="yes" +qdev_deprecation_warning="no" trace_backends="log" trace_file="trace" spice="" @@ -1114,6 +1115,8 @@ for opt do ;; --enable-qom-cast-debug) qom_cast_debug="yes" ;; + --enable-qdev-deprecation-warning) qdev_deprecation_warning="yes" + ;; --disable-virtfs) virtfs="no" ;; --enable-virtfs) virtfs="yes" @@ -1882,6 +1885,7 @@ disabled with --disable-FEATURE, default is enabled if available: virglrenderer virgl rendering support xfsctl xfsctl support qom-cast-debug cast debugging support + qdev-deprecation-warning display qdev deprecation warnings tools build qemu-io, qemu-nbd and qemu-img tools vxhs Veritas HyperScale vDisk backend support bochs bochs image format support @@ -6723,6 +6727,7 @@ echo "gcov enabled $gcov" echo "TPM support $tpm" echo "libssh support $libssh" echo "QOM debugging $qom_cast_debug" +echo "QDEV deprecation warnings $qdev_deprecation_warning" echo "Live block migration $live_block_migration" echo "lzo support $lzo" echo "snappy support $snappy" @@ -7345,6 +7350,9 @@ fi if test "$qom_cast_debug" = "yes" ; then echo "CONFIG_QOM_CAST_DEBUG=y" >> $config_host_mak fi +if test "$qdev_deprecation_warning" = "yes" ; then + echo "CONFIG_QDEV_DEPRECATION_WARNING=y" >> $config_host_mak +fi if test "$rbd" = "yes" ; then echo "CONFIG_RBD=m" >> $config_host_mak echo "RBD_CFLAGS=$rbd_cflags" >> $config_host_mak diff --git a/include/hw/qdev-deprecated.h b/include/hw/qdev-deprecated.h new file mode 100644 index 0000000000..b815f62dae --- /dev/null +++ b/include/hw/qdev-deprecated.h @@ -0,0 +1,26 @@ +/* + * QEMU QOM qdev deprecation helpers + * + * Copyright (c) 2020 Red Hat, Inc. + * + * Author: + * Philippe Mathieu-Daudé + * + * SPDX-License-Identifier: GPL-2.0-or-later + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ +#ifndef HW_QDEV_DEPRECATED_H +#define HW_QDEV_DEPRECATED_H + +/** + * qdev_warn_deprecated_function_used: + * + * Display a warning that deprecated code is used. + */ +#define qdev_warn_deprecated_function_used() \ + qdev_warn_deprecated_function(__func__) +void qdev_warn_deprecated_function(const char *function); + +#endif diff --git a/hw/core/qdev.c b/hw/core/qdev.c index 9e5538aeae..901fa93657 100644 --- a/hw/core/qdev.c +++ b/hw/core/qdev.c @@ -35,6 +35,7 @@ #include "hw/hotplug.h" #include "hw/irq.h" #include "hw/qdev-properties.h" +#include "hw/qdev-deprecated.h" #include "hw/boards.h" #include "hw/sysbus.h" #include "hw/qdev-clock.h" @@ -819,6 +820,13 @@ void qdev_alias_all_properties(DeviceState *target, Object *source) } while (class != object_class_by_name(TYPE_DEVICE)); } +void qdev_warn_deprecated_function(const char *function) +{ +#ifdef CONFIG_QDEV_DEPRECATION_WARNING + warn_report("use of deprecated non-qdev/non-qom code in %s()", function); +#endif +} + static bool device_get_realized(Object *obj, Error **errp) { DeviceState *dev = DEVICE(obj); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKCz-0003em-Bj; Mon, 08 Jun 2020 16:01:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKCx-0003eU-Ns for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:07 +0000 X-Inumbo-ID: 404037ca-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 404037ca-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:01:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632061; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=r7PHbUODraiyYDfGeXtIeVn3Evhw0HgQCb8r2diF6v0=; b=Z6b9xR/6zTQzT8aJLK7HAeUlBDApfrpo4e9rBnTyxltheE/qgHc2cc1v8czIAtMAUDvpNt cQLqFn8LtRuTzC8qR1CYMc7vPEIFpJRW65zEgz5m2avS3yswR9QG7LZkdsmTkUAfRaAzM8 ub5PD25MLbssQokfM8L3IQEpauT4e4o= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-142-TdMg-M7XNCifG-owD_E9lg-1; Mon, 08 Jun 2020 12:00:49 -0400 X-MC-Unique: TdMg-M7XNCifG-owD_E9lg-1 Received: by mail-wr1-f70.google.com with SMTP id p9so7360166wrx.10 for ; Mon, 08 Jun 2020 09:00:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=r7PHbUODraiyYDfGeXtIeVn3Evhw0HgQCb8r2diF6v0=; b=FMiXfFipkQ6PtUynE8RdFDM2abwa8Z6J2ZRk/LCulU8Yoqn1MCXQKS0u0k5GS3UKc8 LnJjEAyLH4FTu2Gu8Z7HnVsCCO+k50e+ukO+E/D1GC1nm7K6HwJwpjddWP91T3nUAIp+ mUb4aSl+L4CI3UyWMkZWYbfa+TudL44iO6Jd3ru+/+HLojtWoH024VxBhrcXKPTvBzGX cyKK0gpaZoK03tw7XIC3a8Rc9PZ7PInnmxjoMIkSc43fsYHuFxP1d2BFj7O0CtdwLhcz yL9yaEhGSQiMmiEnogdGI3NcD53diBqLjDXf1lSE5V/ynh2pDDwgeN1BcCnvVIUWtJdz s4HA== X-Gm-Message-State: AOAM532Rud1XM/nTGMhXzOJzBjsxcpoHOhG35pTKsG0iDdzHKbYCG7Zr XIXHFA0kmedQ1yLCuHC6y6qsvAlBxbUtG9q00W7araFWwHLMintY6ayPafN+KVcwku9pjAzjVjh A5q3fS+puiDGvXPNsVEZdC0elq0U= X-Received: by 2002:a5d:69cb:: with SMTP id s11mr24291797wrw.91.1591632048381; Mon, 08 Jun 2020 09:00:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMtorKuHBb+MRvZ6tBeip6kyiiVi39BDg4R5E8m4jpXwbcp5IXslWyCaizAHQ0jAbG9qrLqg== X-Received: by 2002:a5d:69cb:: with SMTP id s11mr24291746wrw.91.1591632048080; Mon, 08 Jun 2020 09:00:48 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id o15sm175107wrv.48.2020.06.08.09.00.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:00:47 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 00/35] hw/qdev: Warn when using pre-qdev/QOM devices Date: Mon, 8 Jun 2020 18:00:09 +0200 Message-Id: <20200608160044.15531-1-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Based on today's IRC chat, this is a trivial RFC series to anotate pre-qdev/QOM devices so developers using them without knowing they are not QOM'ified yet can realize it and convert them if they have time. qdev/QOM devices are introspectable, so easier to test or even fuzz. Philippe Mathieu-Daudé (35): qom/object: Update documentation hw/core/qdev: Add qdev_warn_deprecated_function_used() helper hw/arm/omap: Emit warning when old code is used hw/arm/pxa2xx: Emit warning when old code is used hw/arm/nseries: Emit warning when old code is used hw/timer/arm_timer: Emit warning when old code is used hw/char/parallel: Emit warning when old code is used hw/display/blizzard: Emit warning when old code is used hw/display/ramfb: Emit warning when old code is used hw/display/tc6393xb: Emit warning when old code is used hw/display/vga-isa-mm: Emit warning when old code is used hw/dma/etraxfs_dma: Emit warning when old code is used hw/dma/soc_dma: Emit warning when old code is used hw/i386/pc: Emit warning when old code is used hw/i386/xen/xen-hvm: Emit warning when old code is used hw/input/lasips2: Emit warning when old code is used hw/input/pckbd: Emit warning when old code is used hw/input/ps2: Emit warning when old code is used hw/input/tsc2005: Emit warning when old code is used hw/intc/i8259: Emit warning when old code is used hw/lm32/lm32_hwsetup: Emit warning when old code is used hw/m68k/mcf520x: Emit warning when old code is used hw/misc/applesmc: Emit warning when old code is used hw/misc/cbus: Emit warning when old code is used hw/nvram/eeprom93xx: Emit warning when old code is used hw/openrisc/cputimer: Emit warning when old code is used hw/ppc/ppc: Emit warning when old code is used hw/ppc/ppc4xx: Emit warning when old code is used hw/ppc/ppc_booke: Emit warning when old code is used hw/ppc/virtex_ml507: Emit warning when old code is used hw/sh4: Emit warning when old code is used hw/riscv: Emit warning when old code is used hw/timer/slavio_timer: Emit warning when old code is used hw/usb/hcd-musb: Emit warning when old code is used hw/xtensa/xtfpga: Emit warning when old code is used configure | 8 ++++++++ hw/lm32/lm32_hwsetup.h | 3 +++ include/hw/qdev-deprecated.h | 26 ++++++++++++++++++++++++++ include/qom/object.h | 6 +++--- hw/arm/nseries.c | 2 ++ hw/arm/omap1.c | 6 ++++++ hw/arm/pxa2xx.c | 3 +++ hw/char/omap_uart.c | 5 +++++ hw/char/parallel.c | 3 +++ hw/char/sh_serial.c | 3 +++ hw/core/qdev.c | 8 ++++++++ hw/display/blizzard.c | 3 +++ hw/display/pxa2xx_lcd.c | 3 +++ hw/display/ramfb.c | 3 +++ hw/display/tc6393xb.c | 3 +++ hw/display/vga-isa-mm.c | 5 +++++ hw/display/vga.c | 3 +++ hw/dma/etraxfs_dma.c | 4 +++- hw/dma/soc_dma.c | 3 +++ hw/i386/pc.c | 3 +++ hw/i386/xen/xen-hvm.c | 4 +++- hw/input/lasips2.c | 4 +++- hw/input/pckbd.c | 4 +++- hw/input/ps2.c | 6 +++++- hw/input/pxa2xx_keypad.c | 3 +++ hw/input/tsc2005.c | 3 +++ hw/intc/i8259.c | 3 +++ hw/intc/sh_intc.c | 3 +++ hw/m68k/mcf5206.c | 5 +++++ hw/m68k/mcf5208.c | 3 +++ hw/misc/applesmc.c | 3 +++ hw/misc/cbus.c | 3 +++ hw/misc/omap_gpmc.c | 3 +++ hw/misc/omap_l4.c | 3 +++ hw/misc/omap_sdrc.c | 3 +++ hw/nvram/eeprom93xx.c | 3 +++ hw/openrisc/cputimer.c | 3 +++ hw/ppc/ppc.c | 3 +++ hw/ppc/ppc405_boards.c | 5 +++++ hw/ppc/ppc405_uc.c | 21 +++++++++++++++++++++ hw/ppc/ppc4xx_devs.c | 7 +++++++ hw/ppc/ppc_booke.c | 4 +++- hw/ppc/virtex_ml507.c | 4 +++- hw/riscv/riscv_htif.c | 4 ++++ hw/riscv/sifive_uart.c | 4 ++++ hw/sd/omap_mmc.c | 5 +++++ hw/sh4/r2d.c | 3 +++ hw/sh4/sh7750.c | 4 ++++ hw/ssi/omap_spi.c | 3 +++ hw/timer/arm_timer.c | 3 +++ hw/timer/omap_synctimer.c | 4 ++++ hw/timer/sh_timer.c | 5 +++++ hw/timer/slavio_timer.c | 3 +++ hw/usb/hcd-musb.c | 3 +++ hw/xtensa/xtfpga.c | 3 +++ 55 files changed, 240 insertions(+), 10 deletions(-) create mode 100644 include/hw/qdev-deprecated.h -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKD3-0003gW-Ld; Mon, 08 Jun 2020 16:01:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKD2-0003gA-OD for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:12 +0000 X-Inumbo-ID: 45b12e76-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 45b12e76-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:01:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632071; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zOI5VHRwzcrGr66pZ7m4z1ZrN3YJ34eLW3YDU+fnGv0=; b=DFM5n/zytoapvV9Ld+QkjOPRkm6cym/Dk94dkgN+QQ4qOeT7vdDb7IcTBH+tkALWM0LVoh rYfQRO5fFr+W/QRUDDaJQ/C9f+rykFLx+q4z6MekwkIx8PCfSldIYga2jxjESp/1I3WNBq Mflj3kUaz8ZzQXjidTj7UNwWb1Rad9o= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-489-1fD6y-RINF-qYnRlHl51Kw-1; Mon, 08 Jun 2020 12:01:06 -0400 X-MC-Unique: 1fD6y-RINF-qYnRlHl51Kw-1 Received: by mail-wr1-f72.google.com with SMTP id o1so7297569wrm.17 for ; Mon, 08 Jun 2020 09:01:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=zOI5VHRwzcrGr66pZ7m4z1ZrN3YJ34eLW3YDU+fnGv0=; b=TaFrHTFkMQWTOBRk+w2KCBinMqddkWUAg9avHTkO+ptzMd+bX3i4DjezF8Acvm4IO/ T40bxDH2e+IVyFZFDI+Ncy88RzyFnO9OvWkAT1ATtN1yjzXWDOZf4ojwdQ6r+lG/qN2m aJq0QKf56hLaTaTLmZXvZ2sHIKUXZ1t5f1gQRkRlfmWlJ+ejL8xAjEAToheibejSp3LA gILSbYQbeckmaGZKf6iaqgMcSpqJEGo8aKgVg/gap4rpVB6NXi+n4K/qPPoS4olU5zUN UNyhdZZD4321dt45N2+muaBA0l1WPW3DOQoZB7ZsmrjXYa5mjA3jl150tenFutaqNNC4 xbBQ== X-Gm-Message-State: AOAM531aTS+13gylr4VzHBdJM3LagyoiSo1MjZq1xTPPPifIyKw+eqUG iCSm8fgQpRv2SYIpZKcRSpa0Y35UpG6Fhauip70iIb+da6jGOy2hZqDtOydvJOEe1WmSesRArt5 iSjUj1qo+0/FGCvP2hWZ+7iXi4Ks= X-Received: by 2002:a1c:c3d7:: with SMTP id t206mr32544wmf.69.1591632065211; Mon, 08 Jun 2020 09:01:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJziXMXpu2PAmMIx7aoFkuYgVgPaKI7cmN6JuMa+/KlQ6vvO4eQND3agEj8WsVM887NYLfsrYQ== X-Received: by 2002:a1c:c3d7:: with SMTP id t206mr32465wmf.69.1591632064493; Mon, 08 Jun 2020 09:01:04 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id y5sm160041wrs.63.2020.06.08.09.01.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:03 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 03/35] hw/arm/omap: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:12 +0200 Message-Id: <20200608160044.15531-4-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/arm/omap1.c | 6 ++++++ hw/char/omap_uart.c | 5 +++++ hw/misc/omap_gpmc.c | 3 +++ hw/misc/omap_l4.c | 3 +++ hw/misc/omap_sdrc.c | 3 +++ hw/sd/omap_mmc.c | 5 +++++ hw/ssi/omap_spi.c | 3 +++ hw/timer/omap_synctimer.c | 4 ++++ 8 files changed, 32 insertions(+) diff --git a/hw/arm/omap1.c b/hw/arm/omap1.c index 761cc17ea9..d7d6253be0 100644 --- a/hw/arm/omap1.c +++ b/hw/arm/omap1.c @@ -40,6 +40,7 @@ #include "hw/sysbus.h" #include "qemu/cutils.h" #include "qemu/bcd.h" +#include "hw/qdev-deprecated.h" static inline void omap_log_badwidth(const char *funcname, hwaddr addr, int sz) { @@ -1451,6 +1452,7 @@ static struct dpll_ctl_s *omap_dpll_init(MemoryRegion *memory, hwaddr base, omap_clk clk) { struct dpll_ctl_s *s = g_malloc0(sizeof(*s)); + qdev_warn_deprecated_function_used(); memory_region_init_io(&s->iomem, NULL, &omap_dpll_ops, s, "omap-dpll", 0x100); s->dpll = clk; @@ -2427,6 +2429,8 @@ static struct omap_pwl_s *omap_pwl_init(MemoryRegion *system_memory, { struct omap_pwl_s *s = g_malloc0(sizeof(*s)); + qdev_warn_deprecated_function_used(); + omap_pwl_reset(s); memory_region_init_io(&s->iomem, NULL, &omap_pwl_ops, s, @@ -2534,6 +2538,8 @@ static struct omap_pwt_s *omap_pwt_init(MemoryRegion *system_memory, omap_clk clk) { struct omap_pwt_s *s = g_malloc0(sizeof(*s)); + + qdev_warn_deprecated_function_used(); s->clk = clk; omap_pwt_reset(s); diff --git a/hw/char/omap_uart.c b/hw/char/omap_uart.c index e8da933378..7e106772ce 100644 --- a/hw/char/omap_uart.c +++ b/hw/char/omap_uart.c @@ -22,6 +22,7 @@ #include "hw/arm/omap.h" #include "hw/char/serial.h" #include "exec/address-spaces.h" +#include "hw/qdev-deprecated.h" /* UARTs */ struct omap_uart_s { @@ -57,6 +58,8 @@ struct omap_uart_s *omap_uart_init(hwaddr base, { struct omap_uart_s *s = g_new0(struct omap_uart_s, 1); + qdev_warn_deprecated_function_used(); + s->base = base; s->fclk = fclk; s->irq = irq; @@ -168,6 +171,8 @@ struct omap_uart_s *omap2_uart_init(MemoryRegion *sysmem, struct omap_uart_s *s = omap_uart_init(base, irq, fclk, iclk, txdma, rxdma, label, chr); + qdev_warn_deprecated_function_used(); + memory_region_init_io(&s->iomem, NULL, &omap_uart_ops, s, "omap.uart", 0x100); s->ta = ta; diff --git a/hw/misc/omap_gpmc.c b/hw/misc/omap_gpmc.c index 10de7a5523..9e29d7a8bd 100644 --- a/hw/misc/omap_gpmc.c +++ b/hw/misc/omap_gpmc.c @@ -25,6 +25,7 @@ #include "hw/arm/omap.h" #include "exec/memory.h" #include "exec/address-spaces.h" +#include "hw/qdev-deprecated.h" /* General-Purpose Memory Controller */ struct omap_gpmc_s { @@ -830,6 +831,8 @@ struct omap_gpmc_s *omap_gpmc_init(struct omap_mpu_state_s *mpu, int cs; struct omap_gpmc_s *s = g_new0(struct omap_gpmc_s, 1); + qdev_warn_deprecated_function_used(); + memory_region_init_io(&s->iomem, NULL, &omap_gpmc_ops, s, "omap-gpmc", 0x1000); memory_region_add_subregion(get_system_memory(), base, &s->iomem); diff --git a/hw/misc/omap_l4.c b/hw/misc/omap_l4.c index 54aeaecd69..b412790c19 100644 --- a/hw/misc/omap_l4.c +++ b/hw/misc/omap_l4.c @@ -19,6 +19,7 @@ */ #include "qemu/osdep.h" #include "hw/arm/omap.h" +#include "hw/qdev-deprecated.h" struct omap_l4_s { MemoryRegion *address_space; @@ -33,6 +34,8 @@ struct omap_l4_s *omap_l4_init(MemoryRegion *address_space, struct omap_l4_s *bus = g_malloc0( sizeof(*bus) + ta_num * sizeof(*bus->ta)); + qdev_warn_deprecated_function_used(); + bus->address_space = address_space; bus->ta_num = ta_num; bus->base = base; diff --git a/hw/misc/omap_sdrc.c b/hw/misc/omap_sdrc.c index f2f72f6810..4f8440ea56 100644 --- a/hw/misc/omap_sdrc.c +++ b/hw/misc/omap_sdrc.c @@ -19,6 +19,7 @@ */ #include "qemu/osdep.h" #include "hw/arm/omap.h" +#include "hw/qdev-deprecated.h" /* SDRAM Controller Subsystem */ struct omap_sdrc_s { @@ -159,6 +160,8 @@ struct omap_sdrc_s *omap_sdrc_init(MemoryRegion *sysmem, { struct omap_sdrc_s *s = g_new0(struct omap_sdrc_s, 1); + qdev_warn_deprecated_function_used(); + omap_sdrc_reset(s); memory_region_init_io(&s->iomem, NULL, &omap_sdrc_ops, s, "omap.sdrc", 0x1000); diff --git a/hw/sd/omap_mmc.c b/hw/sd/omap_mmc.c index 4088a8a80b..88fd20e17a 100644 --- a/hw/sd/omap_mmc.c +++ b/hw/sd/omap_mmc.c @@ -24,6 +24,7 @@ #include "hw/irq.h" #include "hw/arm/omap.h" #include "hw/sd/sd.h" +#include "hw/qdev-deprecated.h" struct omap_mmc_s { qemu_irq irq; @@ -599,6 +600,8 @@ struct omap_mmc_s *omap_mmc_init(hwaddr base, { struct omap_mmc_s *s = g_new0(struct omap_mmc_s, 1); + qdev_warn_deprecated_function_used(); + s->irq = irq; s->dma = dma; s->clk = clk; @@ -625,6 +628,8 @@ struct omap_mmc_s *omap2_mmc_init(struct omap_target_agent_s *ta, { struct omap_mmc_s *s = g_new0(struct omap_mmc_s, 1); + qdev_warn_deprecated_function_used(); + s->irq = irq; s->dma = dma; s->clk = fclk; diff --git a/hw/ssi/omap_spi.c b/hw/ssi/omap_spi.c index 7c7e689707..276f963ae2 100644 --- a/hw/ssi/omap_spi.c +++ b/hw/ssi/omap_spi.c @@ -25,6 +25,7 @@ #include "hw/hw.h" #include "hw/irq.h" #include "hw/arm/omap.h" +#include "hw/qdev-deprecated.h" /* Multichannel SPI */ struct omap_mcspi_s { @@ -353,6 +354,8 @@ struct omap_mcspi_s *omap_mcspi_init(struct omap_target_agent_s *ta, int chnum, struct omap_mcspi_s *s = g_new0(struct omap_mcspi_s, 1); struct omap_mcspi_ch_s *ch = s->ch; + qdev_warn_deprecated_function_used(); + s->irq = irq; s->chnum = chnum; while (chnum --) { diff --git a/hw/timer/omap_synctimer.c b/hw/timer/omap_synctimer.c index 72b997939b..4be24e970e 100644 --- a/hw/timer/omap_synctimer.c +++ b/hw/timer/omap_synctimer.c @@ -20,6 +20,8 @@ #include "qemu/osdep.h" #include "qemu/timer.h" #include "hw/arm/omap.h" +#include "hw/qdev-deprecated.h" + struct omap_synctimer_s { MemoryRegion iomem; uint32_t val; @@ -101,6 +103,8 @@ struct omap_synctimer_s *omap_synctimer_init(struct omap_target_agent_s *ta, { struct omap_synctimer_s *s = g_malloc0(sizeof(*s)); + qdev_warn_deprecated_function_used(); + omap_synctimer_reset(s); memory_region_init_io(&s->iomem, NULL, &omap_synctimer_ops, s, "omap.synctimer", omap_l4_region_size(ta, 0)); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKD4-0003hR-UI; Mon, 08 Jun 2020 16:01:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKD4-0003h2-6w for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:14 +0000 X-Inumbo-ID: 46eafbaa-a9a1-11ea-96fb-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 46eafbaa-a9a1-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 16:01:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632073; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O7Ly94SWL+SMdJ3uuRJWrIP/iOhgME/DwBVu03IUalo=; b=XMVNPDP+pwORdzbIBc7g/MDKo1KzzqHVDxTrWAO/+n/C3cNnvWDiRULUhkcM0RmtWv6/fF aJXJH75uEqSv2idrGZXb4Hx1eB4HRWReQ4Yk45AsZdg9uPUimYivqHzYtcsZVV4wmLDaMX nubEISQNHbruLjAuWhMVsTrilAwVXgM= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-231-vSu2zWhsOSmHhzMJ7I1Hkg-1; Mon, 08 Jun 2020 12:01:11 -0400 X-MC-Unique: vSu2zWhsOSmHhzMJ7I1Hkg-1 Received: by mail-wm1-f69.google.com with SMTP id p24so11166wmc.1 for ; Mon, 08 Jun 2020 09:01:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=O7Ly94SWL+SMdJ3uuRJWrIP/iOhgME/DwBVu03IUalo=; b=fAB/rMZxqiXWk1IisYOMRE21fZKko0S95HVwIS0pCcVAwByXaAp0pSWybgoe5JulbT mFE9oqxCV/MEz9jxMNZUXCItq6/vMs5OkpWQNRRRxdk4ZqmUC4remXNv5cxfy2/eSDdX oMQrQ0dUPwaR/x4PrN8i+VudpFgQR8WGkTbmVNOp/7F7hhKL6Jzo3QMD6gYlPh1uPE65 JYggDG45xg9tuCic72VAbIWnVPNSirucvGVPRJlwuZOyhjPNvz+w2x6YokGrUD7cBCJU iMq5YqiA04ET4pWIJGPpSwI2s98//y2/YVtcY5gxzs1ON0xylg5/GLBsO+LaXFoRjjke imiw== X-Gm-Message-State: AOAM533LbWRu/2p1Z9YW+Ehzzdm2djfznLmdyVz/jdh7kEeCo99TAa+q G/ttdOq8NXlZuJI5jsm6lfFJdzmJ4iQEdasRj5F4YJ48ywh9feWklOOpUP/POpKAcVzKBylzlFd OQ28Lt+R1lFr+WEsx7WKxx4txTVA= X-Received: by 2002:a5d:6acf:: with SMTP id u15mr25749793wrw.277.1591632070227; Mon, 08 Jun 2020 09:01:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzcPzEmUfH07HRp9H1Y3tf4BoKsOaXn7cpLkhpXaJ1S6O0iNu0DeeV5KKJL41RODtirsARieQ== X-Received: by 2002:a5d:6acf:: with SMTP id u15mr25749771wrw.277.1591632069976; Mon, 08 Jun 2020 09:01:09 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id e12sm163622wro.52.2020.06.08.09.01.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:09 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 04/35] hw/arm/pxa2xx: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:13 +0200 Message-Id: <20200608160044.15531-5-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/arm/pxa2xx.c | 3 +++ hw/display/pxa2xx_lcd.c | 3 +++ hw/input/pxa2xx_keypad.c | 3 +++ 3 files changed, 9 insertions(+) diff --git a/hw/arm/pxa2xx.c b/hw/arm/pxa2xx.c index e649f8930c..483003d161 100644 --- a/hw/arm/pxa2xx.c +++ b/hw/arm/pxa2xx.c @@ -27,6 +27,7 @@ #include "sysemu/qtest.h" #include "qemu/cutils.h" #include "qemu/log.h" +#include "hw/qdev-deprecated.h" static struct { hwaddr io_base; @@ -1768,6 +1769,8 @@ static PXA2xxI2SState *pxa2xx_i2s_init(MemoryRegion *sysmem, { PXA2xxI2SState *s = g_new0(PXA2xxI2SState, 1); + qdev_warn_deprecated_function_used(); + s->irq = irq; s->rx_dma = rx_dma; s->tx_dma = tx_dma; diff --git a/hw/display/pxa2xx_lcd.c b/hw/display/pxa2xx_lcd.c index ff90104b80..cf6241ff21 100644 --- a/hw/display/pxa2xx_lcd.c +++ b/hw/display/pxa2xx_lcd.c @@ -20,6 +20,7 @@ /* FIXME: For graphic_rotate. Should probably be done in common code. */ #include "sysemu/sysemu.h" #include "framebuffer.h" +#include "hw/qdev-deprecated.h" struct DMAChannel { uint32_t branch; @@ -1011,6 +1012,8 @@ PXA2xxLCDState *pxa2xx_lcdc_init(MemoryRegion *sysmem, PXA2xxLCDState *s; DisplaySurface *surface; + qdev_warn_deprecated_function_used(); + s = (PXA2xxLCDState *) g_malloc0(sizeof(PXA2xxLCDState)); s->invalidated = 1; s->irq = irq; diff --git a/hw/input/pxa2xx_keypad.c b/hw/input/pxa2xx_keypad.c index 62aa6f6b15..6de1e9e4bb 100644 --- a/hw/input/pxa2xx_keypad.c +++ b/hw/input/pxa2xx_keypad.c @@ -17,6 +17,7 @@ #include "migration/vmstate.h" #include "hw/arm/pxa.h" #include "ui/console.h" +#include "hw/qdev-deprecated.h" /* * Keypad @@ -316,6 +317,8 @@ PXA2xxKeyPadState *pxa27x_keypad_init(MemoryRegion *sysmem, { PXA2xxKeyPadState *s; + qdev_warn_deprecated_function_used(); + s = (PXA2xxKeyPadState *) g_malloc0(sizeof(PXA2xxKeyPadState)); s->irq = irq; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDH-0003n2-8H; Mon, 08 Jun 2020 16:01:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDF-0003mK-Eb for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:25 +0000 X-Inumbo-ID: 4dc9924c-a9a1-11ea-9ad7-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 4dc9924c-a9a1-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 16:01:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632084; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NJCGR9/510Qhv58TRWbd4o5i6q1ayDSJg7ikac3wKxM=; b=UauDAhDGFRgKdqzcEuS6rAFZY9lrbCSzRjw4PexB+cP9ih7n8GAbaUadFdsMJq3+8Z6w3b fnNQxTdpoDdgMXZMq99R7pjhMJsLOOOeMGP6ydRJvYeox26UuoGC/TY5o8uuqEuEQtRCHE zBctfuOHHrY+x0XJF5bv5zXhK5XSqps= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-349-bzvLIic2Om2KwXd9p9KHuA-1; Mon, 08 Jun 2020 12:01:22 -0400 X-MC-Unique: bzvLIic2Om2KwXd9p9KHuA-1 Received: by mail-wr1-f72.google.com with SMTP id h6so7394719wrx.4 for ; Mon, 08 Jun 2020 09:01:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=NJCGR9/510Qhv58TRWbd4o5i6q1ayDSJg7ikac3wKxM=; b=HjpbLh6IeAcJNM8ZNrC7X7L4CHyoiayu3CG3xyKqFLiynjf2Z9Kg7w8HkShaJb16EZ bvuOu/1mT8aXp/wlQHIVSFkA+4ZZQRl/r5sIB6vnE38OYMvBoRpAmvlTCUXpxalfaQR8 E4srEt7wTDzpalLqS4zpOHIQRRBwzwDchh3zzOMadakHfpDHHWAwZiW6uOSQn8PBop9i pOv3IJO8MSisOUw8TLGusOGPckqhmhrszMVliGL6oD9Xs6Yzim+ViDwbKbJMDHkO00m5 Tfz1Rt7+ZHv8MtAzbTrXkgTsQ3m7OgE0Hxy4BMl+znHImOUtQVYLnWH87Bn4HNAOcG9I uyHQ== X-Gm-Message-State: AOAM532d04aQvS1vImD5re0V8NTxg4GudQeXLiylsE0JYPCI994vZ0Sc pOgeDhySwDMFD4Bs0T7mzGVmiziM9zEPP/A+lcTbWQSL1IGMwlgEdCSRLk2/V4WNw9iM9R5SaEX RlzCOMQEm6iMOZPwH8hxEqIdrk68= X-Received: by 2002:a1c:6884:: with SMTP id d126mr21800wmc.121.1591632081531; Mon, 08 Jun 2020 09:01:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOzP/TSo/GdCDA4q3fBC5fMN7fhQwZz7nfPzYVtVlA4zhoIpThGRIoQT2iemjQz07LOwJssw== X-Received: by 2002:a1c:6884:: with SMTP id d126mr21765wmc.121.1591632081336; Mon, 08 Jun 2020 09:01:21 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id g25sm25750wmh.18.2020.06.08.09.01.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:20 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 06/35] hw/timer/arm_timer: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:15 +0200 Message-Id: <20200608160044.15531-7-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/timer/arm_timer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/timer/arm_timer.c b/hw/timer/arm_timer.c index 9607366d78..e23e6b4b31 100644 --- a/hw/timer/arm_timer.c +++ b/hw/timer/arm_timer.c @@ -16,6 +16,7 @@ #include "hw/qdev-properties.h" #include "qemu/module.h" #include "qemu/log.h" +#include "hw/qdev-deprecated.h" /* Common timer implementation. */ @@ -175,6 +176,8 @@ static arm_timer_state *arm_timer_init(uint32_t freq) { arm_timer_state *s; + qdev_warn_deprecated_function_used(); + s = (arm_timer_state *)g_malloc0(sizeof(arm_timer_state)); s->freq = freq; s->control = TIMER_CTRL_IE; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDL-0003pm-NE; Mon, 08 Jun 2020 16:01:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDL-0003pP-3N for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:31 +0000 X-Inumbo-ID: 5127934e-a9a1-11ea-ba62-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 5127934e-a9a1-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 16:01:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632090; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=P++PpnzVmXXtn3Xqf4XIHbmL4uqsh2R3Dd1pfn2k/GY=; b=KuLTfay+BjUA9tm25il0dVm1obY2X+WoFOeRz4dL/tw/N+nLrrfdHiWh0+RHp5r+xgIJIt zdtGAp8UaVSWVevhmHB3N3V21ASJGWIo2xTXpmmGljkthpWIra3S/Wvh34rygklxtq2hS3 MmbgampXCMaaOT/W60SmlaHJTIwg9HY= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-494-evCRsI3pPvyqLkFAVRu_YQ-1; Mon, 08 Jun 2020 12:01:28 -0400 X-MC-Unique: evCRsI3pPvyqLkFAVRu_YQ-1 Received: by mail-wr1-f71.google.com with SMTP id h6so7394885wrx.4 for ; Mon, 08 Jun 2020 09:01:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=P++PpnzVmXXtn3Xqf4XIHbmL4uqsh2R3Dd1pfn2k/GY=; b=kHW7GDKecbSyYwieV/60x4RWj3zY+SPuGeDX3dpi4fnzCdcTqBfMKDfX1ypbSJGkUW nuljNmhOdy4x6gMgCoMgZRSCLWpVLmbKVdW63jgwcYyWG7KCGdhJ35oKLeXVfMwhR17p jg2kt/By4ghqASLJgE44fbtpVOpWqFxkcjuCl3XJFMV9gZan/cdBbSwjLTFdCH2OSEv8 qwU7GFVc6GT6GBBelLY14cslKygia08txEik28crIaBXmIUL9j/UdQX/nG0SIVO4PHcE rL/gtumk+/4qH3fK4+sJVmgNYYTGKeZwVrqTwxdqOOeZWU31IDpF08R+3au3MudbT2Qd QQYQ== X-Gm-Message-State: AOAM531ouEECMb+5win23jRCDaW9UVD2+RTSwTvUoA0FaCpXu4yWrO+5 I/pd4ZadiFpQtQfCuqafDoRUmPw3pWukea6gxnR27prS5G/VoFUcW3Wq4jq8CjqfZlJW1JM6vQh 9Q8HX8RI7B6GovGMptU7LHndCYzY= X-Received: by 2002:a1c:f007:: with SMTP id a7mr27146wmb.103.1591632087261; Mon, 08 Jun 2020 09:01:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzi6QGEqKJNT1xfJrXVN1hFb5ZVsGqmEk2sV/P9tBTDLMUlN7hRgEWpk7m+66ilMFrnYarGkA== X-Received: by 2002:a1c:f007:: with SMTP id a7mr27088wmb.103.1591632086930; Mon, 08 Jun 2020 09:01:26 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id o9sm7066wmh.37.2020.06.08.09.01.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:26 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 07/35] hw/char/parallel: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:16 +0200 Message-Id: <20200608160044.15531-8-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/char/parallel.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/char/parallel.c b/hw/char/parallel.c index 8dd67d1375..0ee577d420 100644 --- a/hw/char/parallel.c +++ b/hw/char/parallel.c @@ -35,6 +35,7 @@ #include "hw/char/parallel.h" #include "sysemu/reset.h" #include "sysemu/sysemu.h" +#include "hw/qdev-deprecated.h" #include "trace.h" //#define DEBUG_PARALLEL @@ -601,6 +602,8 @@ bool parallel_mm_init(MemoryRegion *address_space, { ParallelState *s; + qdev_warn_deprecated_function_used(); + s = g_malloc0(sizeof(ParallelState)); s->irq = irq; qemu_chr_fe_init(&s->chr, chr, &error_abort); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDV-0003uA-18; Mon, 08 Jun 2020 16:01:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDT-0003tZ-Rs for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:39 +0000 X-Inumbo-ID: 56829686-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 56829686-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:01:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632099; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2ORhV1sd4nU6DWHF34s88hmmcxuNYxVDeCG6mbf27fE=; b=Q1JwZVZGzKEAPOC7Sd9FGrVIN4YJJcMxpNnvmirkMoTyjUIUUxlrNLedS/XD34fBWTPCr3 ILftppu9HZSpfuuNpuNHHxGBElgspQXN7CuaqnxPTcCTo1P33heoGQHKJrSFaDn3wAbT8W RlBI3eUyf2aMlGKL4C4j4ZLXzcnDMt0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-220-OTBIR5U5MPCYVDLTTtN25g-1; Mon, 08 Jun 2020 12:01:34 -0400 X-MC-Unique: OTBIR5U5MPCYVDLTTtN25g-1 Received: by mail-wm1-f72.google.com with SMTP id b63so114817wme.1 for ; Mon, 08 Jun 2020 09:01:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2ORhV1sd4nU6DWHF34s88hmmcxuNYxVDeCG6mbf27fE=; b=hp+05fApLNqPLMRGLmXFW5P3MCCXJwqskl+jxtI8Yv6WHfOeTO8KtbqnVe4m7euSpa MFzgZ+5Q7HcDUL/jo4F05AN0S81ilAJd/+I9CZsvTc/wVXeE0ZAI6d5rYff9cDw56bd+ J5ESDrtIuszdOR4Ja1qxQ6a6mKsKLfUGd7kkGVVg9dcVU/JXRgsv5rrMqOJSego0ovxW +oWSPEAU9xdyMi70wobPdoDSHNLsngx2sN26T7iMtYtWZk1nPUF1nMZUP3BKpTPhD02k ZJUE/MujIKsw1lP+QM8UQU2yHl6/xf/h8YPEOSE5xFBE7xe9fDZPxGDfHRdsbvebrBVP GkgQ== X-Gm-Message-State: AOAM530KgS3E3QMqY0N5Z19trP7vLcmInabKHeaxCnnfaMrPpeT8+f/D 485YXte0t44rQ5VVaz+Co6l1owiLlqTvKU/p+WcqxfPQiHD/MfiJcTG0wb+XIG27WNZjBk16Gf2 ec+Vbie4dhaBs7AEtGLRDllvcRos= X-Received: by 2002:a5d:6a4b:: with SMTP id t11mr23943725wrw.404.1591632092862; Mon, 08 Jun 2020 09:01:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzX3WHm4bb0lVL0OqrCVvYAl9aSgd4/p4YzE7wN3r2SHFS1TTcIn2CmgHMd0vmMkRzt+4NE2w== X-Received: by 2002:a5d:6a4b:: with SMTP id t11mr23943661wrw.404.1591632092491; Mon, 08 Jun 2020 09:01:32 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id a3sm122524wrp.91.2020.06.08.09.01.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:31 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 08/35] hw/display/blizzard: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:17 +0200 Message-Id: <20200608160044.15531-9-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/display/blizzard.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/display/blizzard.c b/hw/display/blizzard.c index 105241577d..74557b152b 100644 --- a/hw/display/blizzard.c +++ b/hw/display/blizzard.c @@ -23,6 +23,7 @@ #include "ui/console.h" #include "hw/display/blizzard.h" #include "ui/pixel_ops.h" +#include "hw/qdev-deprecated.h" typedef void (*blizzard_fn_t)(uint8_t *, const uint8_t *, unsigned int); @@ -1010,6 +1011,8 @@ void *s1d13745_init(qemu_irq gpio_int) BlizzardState *s = (BlizzardState *) g_malloc0(sizeof(*s)); DisplaySurface *surface; + qdev_warn_deprecated_function_used(); + s->fb = g_malloc(0x180000); s->con = graphic_console_init(NULL, 0, &blizzard_ops, s); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDX-0003vr-An; Mon, 08 Jun 2020 16:01:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDV-0003ui-K4 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:41 +0000 X-Inumbo-ID: 57832dd4-a9a1-11ea-9ad7-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 57832dd4-a9a1-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 16:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632101; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gxT4B45O1zWyFYki8IWzx+7CIdrw2K/5FRLdU4/GP/s=; b=N2DdErRqsyskEuGnIL6IIOra+szxgFTHezrH3k0nylRDWuV5ophAD6etCKcTawrsz+1NAp GZg3tyFIeLDnBXR5q6xZgD9JXWkA9kASGqE/FAzhtm4i5fxoyVhuZABTJwOglFafAz6Z97 +HVomMRl/DPlD9V7hNYGcjleYUuGI7g= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-461-WAtSPRwdOTqH1Ew_IoSHJA-1; Mon, 08 Jun 2020 12:01:39 -0400 X-MC-Unique: WAtSPRwdOTqH1Ew_IoSHJA-1 Received: by mail-wm1-f71.google.com with SMTP id r1so4998wmh.7 for ; Mon, 08 Jun 2020 09:01:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=gxT4B45O1zWyFYki8IWzx+7CIdrw2K/5FRLdU4/GP/s=; b=eRCJ2v1RMV6FFHCWYo2qljR6RDN9fcwLVPialCVV5XBWN8o+zaAnlYYUEamf6X9S/h 7NMRPq4rfQBHFdD+YMdZHsr9Tu3vo5SGuDwgfo2SHfTwNLWL5cRMTPritTibZH0cDfrW TGS7BoRjOK582k5hhv756GFvpDG1jQSmJ+SfH80qIqooIDhIKGvjuOMi1UumFdQkShHs G1A10drk2Z/P+edqanbCRIQTZtWa3BRWi8cTnr4/ntRsffv8etFiypWyByPv7oaK/xin lq3+MHa1YCUjq53I/RvDBeM7k3WOMmJpOVOEobVVfp8ksvNhOxb/zBurCbuS81wgp3IH hV7g== X-Gm-Message-State: AOAM532R9JVEkTEZhjNuSd+aEJY5KNIZZpfO5LBabH5/UgihPfeA9ouT JEsxQo3Fr3SH7opIfovVH+B00KVjdLYtzxm3siViC0GEo8cu58QezPkVvnvcjhFEzyc6XhGBmxO i0esXEHTux5WIHhOW/en2oVvYeYk= X-Received: by 2002:a05:600c:2215:: with SMTP id z21mr76252wml.48.1591632098182; Mon, 08 Jun 2020 09:01:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxecWPcyOuK8uF9ReCv2dq+PoGEfPzfu+FZfYV8n2WgE2MmJ6zu0OPEpglwHYV7Ppo9rtY/wQ== X-Received: by 2002:a05:600c:2215:: with SMTP id z21mr76223wml.48.1591632098001; Mon, 08 Jun 2020 09:01:38 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id g3sm188327wrb.46.2020.06.08.09.01.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:37 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 09/35] hw/display/ramfb: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:18 +0200 Message-Id: <20200608160044.15531-10-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/display/ramfb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/display/ramfb.c b/hw/display/ramfb.c index 79b9754a58..a4a427e5c7 100644 --- a/hw/display/ramfb.c +++ b/hw/display/ramfb.c @@ -18,6 +18,7 @@ #include "hw/display/bochs-vbe.h" /* for limits */ #include "ui/console.h" #include "sysemu/reset.h" +#include "hw/qdev-deprecated.h" struct QEMU_PACKED RAMFBCfg { uint64_t addr; @@ -120,6 +121,8 @@ RAMFBState *ramfb_setup(Error **errp) FWCfgState *fw_cfg = fw_cfg_find(); RAMFBState *s; + qdev_warn_deprecated_function_used(); + if (!fw_cfg || !fw_cfg->dma_enabled) { error_setg(errp, "ramfb device requires fw_cfg with DMA"); return NULL; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDc-0003zN-Js; Mon, 08 Jun 2020 16:01:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDb-0003yb-A9 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:47 +0000 X-Inumbo-ID: 5ae958d6-a9a1-11ea-ba62-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 5ae958d6-a9a1-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 16:01:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632106; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wevOFGWECaRJOmLpbzON6N0ynWLO2tBiVdtI/WyaADw=; b=NkW3UnwTbxxaLsuKfjS3EBcBjcDhv1go6laBXYOB+rFptyXhwpJ6FoPbvRNNbtIsgYMXwH TwzJxY/H5i3I16+12dNHPkTrk5JxeJrafH6n5rjvaa5YE56oGnF1R97P/MNFJQZ20kw8sX ivtKzD9hc7IWlS6v81sMyb5TvHRDiCs= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-262-BruzOao4MFKnk_HSbyC77A-1; Mon, 08 Jun 2020 12:01:44 -0400 X-MC-Unique: BruzOao4MFKnk_HSbyC77A-1 Received: by mail-wr1-f70.google.com with SMTP id d6so7338878wrn.1 for ; Mon, 08 Jun 2020 09:01:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=wevOFGWECaRJOmLpbzON6N0ynWLO2tBiVdtI/WyaADw=; b=cXt5bWqCE/P4uzZ3JdX5em4FbZCHdooGTYV+QBDv+vngkWaTBIH46VSChJZtEhC8x7 eWHcvAnDQSw7eOmPPDQhN1rmTUNGeOzhBiPaj748YhUJdG56ToInL3nG7jCnvVlRQzqw BpNys2pLBRn806lTzp8qwE2pL8RRVp7zDhSOulAVNSkX7VACtvtKuYkC4FcNz4rwKhvO /M2t3iF0xZeRLkCHE2ImfbDjVIHEft5Y8h1MzUq8WqPRV1U6/Bgl0vTAGjC+U0qj3IqM ykWlK4ATTPfNzXD87hj9wG87ItfKP0+wFmpGyIArQHckOp3t8InLKM5b7z7ph2cmKQvt ekfQ== X-Gm-Message-State: AOAM533sBXYqsClnM1sKqK7ld5Rm4GVDD2W9Q7EUFnrL+lwxrhISaIoh nZ06mUHtlEqgnflD3Nk0fhOagDacGdL8Gmb/TKmF7e2ZOrxOpZk5FeWMZNTqYa9cmdL19Ell+9V m9GXvSNpFCY7zEtg6KhCMRErEE4g= X-Received: by 2002:adf:fd81:: with SMTP id d1mr24815725wrr.96.1591632103558; Mon, 08 Jun 2020 09:01:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzgYI93lvZ2rTNUf8uc34cwDYk4WA9pXLtkl6aiMXyXdGzMVgF1rzOkVGZM3nz7yDUz0VO1vA== X-Received: by 2002:adf:fd81:: with SMTP id d1mr24815694wrr.96.1591632103352; Mon, 08 Jun 2020 09:01:43 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id b185sm342940wmd.3.2020.06.08.09.01.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:42 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 10/35] hw/display/tc6393xb: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:19 +0200 Message-Id: <20200608160044.15531-11-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/display/tc6393xb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/display/tc6393xb.c b/hw/display/tc6393xb.c index 49a676d1b0..e4900e9502 100644 --- a/hw/display/tc6393xb.c +++ b/hw/display/tc6393xb.c @@ -21,6 +21,7 @@ #include "ui/console.h" #include "ui/pixel_ops.h" #include "sysemu/blockdev.h" +#include "hw/qdev-deprecated.h" #define IRQ_TC6393_NAND 0 #define IRQ_TC6393_MMC 1 @@ -556,6 +557,8 @@ TC6393xbState *tc6393xb_init(MemoryRegion *sysmem, uint32_t base, qemu_irq irq) }, }; + qdev_warn_deprecated_function_used(); + s = (TC6393xbState *) g_malloc0(sizeof(TC6393xbState)); s->irq = irq; s->gpio_in = qemu_allocate_irqs(tc6393xb_gpio_set, s, TC6393XB_GPIOS); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDk-00044q-TV; Mon, 08 Jun 2020 16:01:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDk-00044a-Jv for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:56 +0000 X-Inumbo-ID: 5f66f1f2-a9a1-11ea-96fb-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 5f66f1f2-a9a1-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 16:01:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632114; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=faJPKsgnKj1MSj1B3bxzpLa01+W3HhU/7Hynie77jqI=; b=Vk7EC4A/3O2/cwwWEVAqrHluyPPdf7NPqzGdX1AQm83e3FvG/csEVW9zrd09gPsbYc8LuZ 4YE8uaQsGXMsdAEm510pLC7bJf0kjk8RKvwCwVYzgPh3VEa71A4fj3drAaVgeZ2VIcgM99 I9GtVCFrL9PbR4GnrKrlqqNk4EKHyLY= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-121-hCDpPhwJNySWu5jbvoflJA-1; Mon, 08 Jun 2020 12:01:50 -0400 X-MC-Unique: hCDpPhwJNySWu5jbvoflJA-1 Received: by mail-wr1-f69.google.com with SMTP id w4so7364563wrl.13 for ; Mon, 08 Jun 2020 09:01:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=faJPKsgnKj1MSj1B3bxzpLa01+W3HhU/7Hynie77jqI=; b=as4X6sWS5XTQQVRyv/w90tbWPZ21O8rsIygk77b2RWzbArcJKVY762Z5Wc5kflsCOI IkwSzJ58hSciyvlilHFYGEONlyqMWdDo4Dp5fD5NJCOmRTT0QaPo742uCcWW7pr/62Ts TBJW1dEShsWDwtrdqY+ZXNUa0NgsisiwubVBuwXHnrvTxUS1dpewl6VEJtCqBYpkSZOf 4eKS1PGxq7SAALkxVXF7ZunTFrrZSZrYmgh3/Rt73cbt9+D5TAhbzllQ8Fj+ZgHz8UE1 Mc511J+1BL4X3xOFtDPx2D4GLqR/wHBbsJ1ie0qURBPDsc7A8QkGfZuWvIYUS1XLO2/H 3M6g== X-Gm-Message-State: AOAM5331B2UA5/hKZfZzezTcZ31I3VdvUtBKmfPpAgs1hqkMwf1Of03n 45eUM/oJ2c//MvIm6UeFji7JN8QzndyojL6TiZZshnWGBwWj6+N43h8R2JWlIeydYbFIBXnCNb2 3V0xVJE7OPlTRFm/VyyGMV4phE0k= X-Received: by 2002:adf:9304:: with SMTP id 4mr25264189wro.280.1591632109661; Mon, 08 Jun 2020 09:01:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx9mBFO0YH5teWKyWXjB3IP6YUG1XRf7/NfjmoGjY1J2DcXSECmfNz6g9nRc2AB3mdjKgV/Zg== X-Received: by 2002:adf:9304:: with SMTP id 4mr25264164wro.280.1591632109513; Mon, 08 Jun 2020 09:01:49 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id l1sm220993wrb.31.2020.06.08.09.01.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:48 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 11/35] hw/display/vga-isa-mm: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:20 +0200 Message-Id: <20200608160044.15531-12-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/display/vga-isa-mm.c | 5 +++++ hw/display/vga.c | 3 +++ 2 files changed, 8 insertions(+) diff --git a/hw/display/vga-isa-mm.c b/hw/display/vga-isa-mm.c index 7321b7a06d..3e62389b63 100644 --- a/hw/display/vga-isa-mm.c +++ b/hw/display/vga-isa-mm.c @@ -29,6 +29,7 @@ #include "hw/display/vga.h" #include "vga_int.h" #include "ui/pixel_ops.h" +#include "hw/qdev-deprecated.h" #define VGA_RAM_SIZE (8 * MiB) @@ -71,6 +72,8 @@ static void vga_mm_init(ISAVGAMMState *s, hwaddr vram_base, { MemoryRegion *s_ioport_ctrl, *vga_io_memory; + qdev_warn_deprecated_function_used(); + s->it_shift = it_shift; s_ioport_ctrl = g_malloc(sizeof(*s_ioport_ctrl)); memory_region_init_io(s_ioport_ctrl, NULL, &vga_mm_ctrl_ops, s, @@ -99,6 +102,8 @@ int isa_vga_mm_init(hwaddr vram_base, s = g_malloc0(sizeof(*s)); + qdev_warn_deprecated_function_used(); + s->vga.vram_size_mb = VGA_RAM_SIZE / MiB; s->vga.global_vmstate = true; vga_common_init(&s->vga, NULL); diff --git a/hw/display/vga.c b/hw/display/vga.c index 061fd9ab8f..d59a9c896b 100644 --- a/hw/display/vga.c +++ b/hw/display/vga.c @@ -35,6 +35,7 @@ #include "hw/xen/xen.h" #include "migration/vmstate.h" #include "trace.h" +#include "hw/qdev-deprecated.h" //#define DEBUG_VGA_MEM //#define DEBUG_VGA_REG @@ -2262,6 +2263,8 @@ MemoryRegion *vga_init_io(VGACommonState *s, Object *obj, { MemoryRegion *vga_mem; + qdev_warn_deprecated_function_used(); + *vga_ports = vga_portio_list; *vbe_ports = vbe_portio_list; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:01:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:01:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDn-00047C-Au; Mon, 08 Jun 2020 16:01:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDm-00045t-4x for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:01:58 +0000 X-Inumbo-ID: 6176dfe9-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 6176dfe9-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:01:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632117; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uHbfMTMnP0pPoIUOMaNBIF3qcn8JPSW/pdevUa2NjDA=; b=FpF4eDcfAtrF/PCga4L5v4LJ/fkMSyuZchTlSs/sjRwmrIZHt3KruPO4ic/slfdA7ekyOW TM8fg+jamCenJ88JGGsbY4EPbKUd22wgmF1++KUf4LfZjlKIgd65Y9riR2USmHzLPFTDkR 0WrCCxnwwAnU/vRsqjHkN0o/tf2Mzmk= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-438-IyjJ421gM3agjRJtPom0Gg-1; Mon, 08 Jun 2020 12:01:56 -0400 X-MC-Unique: IyjJ421gM3agjRJtPom0Gg-1 Received: by mail-wm1-f72.google.com with SMTP id y15so12425wmi.0 for ; Mon, 08 Jun 2020 09:01:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=uHbfMTMnP0pPoIUOMaNBIF3qcn8JPSW/pdevUa2NjDA=; b=BiIsoqjtuNsJ9Dop55nnUQTKGx+PtGVzPSNrVsJjmML88QdhmotgXhggwhLXqZMn6/ eFsvrM0NXGMXdkgDCN3GUFHnwSbUQBX2OLKTfvcLF5jcR/ettcYwqvql40TI0tDrn8kL Sy2ncXLuNrlXdhx/VRP2L9i/LweT1sp82i5b8uWu0JVfgllDmYsC/zAiJLBJCrvI6gA1 lhA227POOqpukHCVxZZLy/Jmj9qAWk8fkm3uyp/17zeyZo3XmD6btFayp2FPDwB5j1gQ jP0931SVlw6s6dueP+KgwMdiKRfLiuhciFvhCGg2JvH4rGjhJ9kKWuW+4tnioeFc7rYm kYtQ== X-Gm-Message-State: AOAM533fOUy4OtPuQsoI7vA2+Bzc1K1TVegMKLE0s5KguHEM+sBEp8U8 qKduaYZ1FTs3kp2RyToKuJjh8WtSyKhS1KVTk1xMZGqQxJW/uJKS4dHX6RLKviZ7wK6Azn5mN4o rRIpvj24EpKQPZjNTFoDgAlFuuM0= X-Received: by 2002:a05:6000:4c:: with SMTP id k12mr23864566wrx.215.1591632114952; Mon, 08 Jun 2020 09:01:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzjnqOGBWofUhF/g/CPg0SMkJ8njA1iKr2pcTJ7xpwajdAOHpMg7tlHe1H6wlLAySWDO/5VvQ== X-Received: by 2002:a05:6000:4c:: with SMTP id k12mr23864524wrx.215.1591632114766; Mon, 08 Jun 2020 09:01:54 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id y17sm194731wrn.12.2020.06.08.09.01.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:54 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 12/35] hw/dma/etraxfs_dma: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:21 +0200 Message-Id: <20200608160044.15531-13-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/dma/etraxfs_dma.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/dma/etraxfs_dma.c b/hw/dma/etraxfs_dma.c index c4334e87bf..d2f7e7ca9d 100644 --- a/hw/dma/etraxfs_dma.c +++ b/hw/dma/etraxfs_dma.c @@ -28,7 +28,7 @@ #include "qemu/main-loop.h" #include "sysemu/runstate.h" #include "exec/address-spaces.h" - +#include "hw/qdev-deprecated.h" #include "hw/cris/etraxfs_dma.h" #define D(x) @@ -765,6 +765,8 @@ void *etraxfs_dmac_init(hwaddr base, int nr_channels) { struct fs_dma_ctrl *ctrl = NULL; + qdev_warn_deprecated_function_used(); + ctrl = g_malloc0(sizeof *ctrl); ctrl->bh = qemu_bh_new(DMA_run, ctrl); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDs-0004B7-LE; Mon, 08 Jun 2020 16:02:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDr-0004AK-Ku for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:03 +0000 X-Inumbo-ID: 648e11a6-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 648e11a6-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:02:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632122; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JPFQ0bX3Ul9NeHHcjGis7Hob0YUuGxD/aHEXimgfPe0=; b=SNg3Vw1wOv3e531S7bQvEPa0ySxt/QmIxqGPmHm/U1zxU1WjNFWluxou2WsblLYn2lyaBM tWW3Vjg0Ms+1vtmiSD1HfOBfIBEXNjXKjrV04oUxlAqtQaMwUvew9W0ltKOY5mwQYPF0DX w8mMKJPlge1H2E7RMOkn/Rn4IoSse68= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-42-l8Bl9tn2MCqI9ozdZXHAHQ-1; Mon, 08 Jun 2020 12:01:16 -0400 X-MC-Unique: l8Bl9tn2MCqI9ozdZXHAHQ-1 Received: by mail-wr1-f71.google.com with SMTP id c14so7301677wrw.11 for ; Mon, 08 Jun 2020 09:01:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JPFQ0bX3Ul9NeHHcjGis7Hob0YUuGxD/aHEXimgfPe0=; b=JHuZ41yMKsrE7iToceMc9W8Sx1VA4Yhzp7GST67+JuTT8b8fg8j9SQCH5R54zbcgO4 Yi9M9QzQVmMfXkpGK9iJP4I4Hc8u0HgtKRsVJtJN2GjmwTUgpIcug4W8K9srpmwgRBkn LwWvbRnBa5CC/oMxWE2YqjslQTCnLl+p18pP5Fp85kppjVgVf8n1TkR020pfKbLgI/cF RZXNx6T35Uvh8qFSv200cBLYpb/7mnG9Br1jDQy0KqvdO8Ql4P6v9cgCtV0AECdjZVwz 6lvcqKIJRcUxtCxuLZIGVFd35feupXj6/B+SmKjVkeFj8hHACK0GUoackEOjycuip20K 1PWQ== X-Gm-Message-State: AOAM5322JTqBec5Ssuo3B6IIWMS1HWbMWe4JvSYL0N5058hZnPhV8Zju eCh/yXIM0J1WOPkpA3oFd9o6FEnjYLKF3rYVliznpULAPj+hzeh2pza0dhsABPSS6kBYTW+sEpI 9yyKQpB8+itw4giaEg//xfC5l5oQ= X-Received: by 2002:a1c:63c2:: with SMTP id x185mr71332wmb.68.1591632075683; Mon, 08 Jun 2020 09:01:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwHSTbXCqkGc9kOsbxhlXHtghZhPx9xWZVb7ZeU/GWo7Q7cDZTZJUQ93U+AAUtsWNU3dUVBvg== X-Received: by 2002:a1c:63c2:: with SMTP id x185mr71295wmb.68.1591632075484; Mon, 08 Jun 2020 09:01:15 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id h12sm145322wro.80.2020.06.08.09.01.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:14 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 05/35] hw/arm/nseries: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:14 +0200 Message-Id: <20200608160044.15531-6-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/arm/nseries.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/arm/nseries.c b/hw/arm/nseries.c index eae800b5c1..bd0c3f39a9 100644 --- a/hw/arm/nseries.c +++ b/hw/arm/nseries.c @@ -44,6 +44,7 @@ #include "hw/sysbus.h" #include "qemu/log.h" #include "exec/address-spaces.h" +#include "hw/qdev-deprecated.h" /* Nokia N8x0 support */ struct n800_s { @@ -703,6 +704,7 @@ static void *mipid_init(void) { struct mipid_s *s = (struct mipid_s *) g_malloc0(sizeof(*s)); + qdev_warn_deprecated_function_used(); s->id = 0x838f03; mipid_reset(s); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDz-0004GK-UC; Mon, 08 Jun 2020 16:02:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKDy-0004FG-B1 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:10 +0000 X-Inumbo-ID: 68a82808-a9a1-11ea-9b55-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 68a82808-a9a1-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 16:02:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632129; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=swd27F6/1+WGmnfSzwg22l5POZg58LkwHV81fIkNGaQ=; b=FstAH5DzUckULHIdThFTTCVGLMNQq15alAlW3hM6uGHmUhc92odcT1RedTTk4iyV6NYp0X QkdabGfWI4RvkDlSEr8ZMxGGSlqx4xZigzmeBgmfLl2zlHM/u/9LScZSlR7ExlG10K1wTW FHHhPlI2u8Uq1k4txdSaFwsh+1J8w3E= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-376-S4pWr-85NjG2Ds4FfRrF6w-1; Mon, 08 Jun 2020 12:02:08 -0400 X-MC-Unique: S4pWr-85NjG2Ds4FfRrF6w-1 Received: by mail-wm1-f69.google.com with SMTP id j128so6684wmj.6 for ; Mon, 08 Jun 2020 09:02:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=swd27F6/1+WGmnfSzwg22l5POZg58LkwHV81fIkNGaQ=; b=E81JLIStopXH1hzW6Svk99WyAwEp0rs66f7wPoBBJn1p9iThaLK7f2O6UsqbYY/b7u 4pPDlNqCF44MBTKbo8NdLcjuacYsWgwSV/XIV4Wt3OYcRx0fFLhyKl7AaOz6wP6jjEQz 7JdflL52IHEC1YIYF/hEGDEoh+BK8rfG27+ZFVkk3hG1vUIT3qGczoV/sJU0wTPrE1jy 2jhgL6EfnM1os5m2cvMiCTiUP0pU8g9Kzod8ruEJgemmRjwkwMbrc6xdLk/3a3yYNu+S 6UF/uwTydYw8z9u7xdv3hj/+O/PpyUpXe8E85StSNU2meBaV+LjLrRjZZW1lFdtciFKy XRcA== X-Gm-Message-State: AOAM531UFThT6jK5QZFqMPt3mFMtxgAIeSKg8VkxU4VGZQJMKrsfqwvL OoZBjYyYTKBemVS69OmvjWmzJ4ALjo38UtCc79EVi1191de3ygR5OM7pdkY4DMPEd6nkiCkTGOC F983tbwRpBiTj1tL/aPSdhAksOUw= X-Received: by 2002:a1c:cc0d:: with SMTP id h13mr58663wmb.168.1591632126777; Mon, 08 Jun 2020 09:02:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwD9AlGEl1YrzMFzzhVE1vb4kbCf4YFVdSir7m67DLKARx2zMO0OlXdHqSCrgQOgDPIF6US1w== X-Received: by 2002:a1c:cc0d:: with SMTP id h13mr58578wmb.168.1591632126013; Mon, 08 Jun 2020 09:02:06 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id z206sm13115wmg.30.2020.06.08.09.02.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:05 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 14/35] hw/i386/pc: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:23 +0200 Message-Id: <20200608160044.15531-15-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/i386/pc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 2128f3d6fe..c71809fd28 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -94,6 +94,7 @@ #include "vmport.h" #include "fw_cfg.h" #include "trace.h" +#include "hw/qdev-deprecated.h" GlobalProperty pc_compat_5_0[] = {}; const size_t pc_compat_5_0_len = G_N_ELEMENTS(pc_compat_5_0); @@ -348,6 +349,8 @@ GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled) { GSIState *s; + qdev_warn_deprecated_function_used(); + s = g_new0(GSIState, 1); if (kvm_ioapic_in_kernel()) { kvm_pc_setup_irq_routing(pci_enabled); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKE6-0004Kq-6d; Mon, 08 Jun 2020 16:02:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKE5-0004KB-JO for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:17 +0000 X-Inumbo-ID: 6d183054-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 6d183054-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:02:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632137; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jOyQYXnEE/P1L9M062K4OG7LDuRa+UfsKXeI8IczatQ=; b=fefb/B0sEevutDY78MH/2UWOO1i+K3MTugRIojbNgaC0LB3ka6Od5kXlv2cFhVWzBordYC eAm5dOgPRh237pcCnOZMDQeM0dkczuLjQDMKXws10lrLJp31LXmSOhbVNmZM8LSWXBZy7Q ShFTX6ewNBX5+gNJpFhxAGvcnhBJ+Ho= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-180-6JOXoJevN4-h3qAPn3LDWg-1; Mon, 08 Jun 2020 12:02:13 -0400 X-MC-Unique: 6JOXoJevN4-h3qAPn3LDWg-1 Received: by mail-wr1-f71.google.com with SMTP id n6so7362787wrv.6 for ; Mon, 08 Jun 2020 09:02:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=jOyQYXnEE/P1L9M062K4OG7LDuRa+UfsKXeI8IczatQ=; b=qIJSwZq6MaCdtM+OFrVraWnhVmweD5X+nrA/iEDDvIXdlux7CTl3cGZF4EgZXPUMh9 P8J2A2n4G4t37bV1XVZ6kGCZ++C9Ckhp1VXYScm1TZ8UWCOekreNqsoVYg0ja8MG+6L8 vArQhaHThmYT8KNyaaZKeG8sd1S1psZpzHdTJ6wWkNiDmJ0aE1M9xNh84YG5Sfd8MDpB wJJEZtebmHh0ZZtC73+bvoRGaTXAC4XIsPikm0lzWiSgx+fimrFT1dyGqMHNOI+f6H/g 27y9+6Fa9MbD0tE47a3I5W0j+4goTo1b2z3sZR0JEV26MyaR9xV6s4837gnLU579LHZ4 no2w== X-Gm-Message-State: AOAM531EdbJAGjaPcM680mKiddNTuDKWoHuSMNz7SRakz7JgN32w9UN1 xbd8ID2Tvhj4i2ja8vBdBzN+dWqn5Z5UYt1IUeU1qZOcax3GZfZNW4y+KaJ7rFDbv9ZM+HFUcEn SOob3TazSmFzPPuGNlc0FaKjYDwg= X-Received: by 2002:a05:600c:2256:: with SMTP id a22mr82461wmm.18.1591632132280; Mon, 08 Jun 2020 09:02:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwvLE6gRX7XM83bmbZu8lLW6Zr2jKGWG6aII1A2AXMFr5e4D5cYkpsPFEEPHv3ro5n12uF+eA== X-Received: by 2002:a05:600c:2256:: with SMTP id a22mr82438wmm.18.1591632132052; Mon, 08 Jun 2020 09:02:12 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id z25sm31297wmf.10.2020.06.08.09.02.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:11 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 15/35] hw/i386/xen/xen-hvm: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:24 +0200 Message-Id: <20200608160044.15531-16-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/i386/xen/xen-hvm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index 82ece6b9e7..a1163b1529 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -31,7 +31,7 @@ #include "sysemu/xen-mapcache.h" #include "trace.h" #include "exec/address-spaces.h" - +#include "hw/qdev-deprecated.h" #include #include @@ -1401,6 +1401,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory) xen_pfn_t ioreq_pfn; XenIOState *state; + qdev_warn_deprecated_function_used(); + state = g_malloc0(sizeof (XenIOState)); state->xce_handle = xenevtchn_open(NULL, 0); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKE6-0004LE-Fv; Mon, 08 Jun 2020 16:02:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKE5-0004KX-SX for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:17 +0000 X-Inumbo-ID: 6d2883b4-a9a1-11ea-ba62-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 6d2883b4-a9a1-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 16:02:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632137; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=y8wt5v6YHTpbkeCWEGxoSB2Z3fXavqt1TINJtdAbbd4=; b=aak3k5D4JTv8Lv6hKugg4G7t/BpA15BHN2BinvRC/iH0mVeGu1ZejYV9OvQMViWzkKoIJ3 HfPoFl6ZveSFq+xAGA6vxXzpFJslmOeZta8VlT7Hmjm1RAumeMELv+BS+CKemMEGYO1tyH fRF4QSOpl+I874nRGaNmUThWSuFMp4s= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-170-AzA8WRaAPRCQsiKYcq9jsg-1; Mon, 08 Jun 2020 12:02:01 -0400 X-MC-Unique: AzA8WRaAPRCQsiKYcq9jsg-1 Received: by mail-wr1-f72.google.com with SMTP id w4so7364837wrl.13 for ; Mon, 08 Jun 2020 09:02:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=y8wt5v6YHTpbkeCWEGxoSB2Z3fXavqt1TINJtdAbbd4=; b=gL7ulGox1L49gfmfCPlaMDVyVuPBaqt51gZQjs1Ya3sqMNUIp1O5fZEnCssvyev9CZ OgJLUfbIp2dc7geWOr813p1vgF6n6blrw4rEt6UW4i1LnBjMkZS+7wgVrZ6jeLwY5O74 YKMjgjJFnDPrDEFaeMX+92e2nq0JZGH1NSclK64HYP6B5YFxBnFKBxK++bLbbLFfr2Nn MDsNUL3fY7D1MaKKtHvEsJKHwSshVXIajOaEvHij4jZyZpvYGmCpJ1+0g/swgi0av5Mz Jnr6NlXcubLYsCo9BwkYcCXMPLs6qyEo6iBgoenqy+V1fRrHH1vZg4/JmMP8KSdlCLjZ acNg== X-Gm-Message-State: AOAM530M3rKvvOi4W3LtmGP5HUURS3lNaao7L1GiuNKR8vJn59uIImwM H0BEgBBMpka4hGuKPKG6rpAy2N44CwkIjzJbeO3sIfYDmrYw8AyTdNRsac8cUUuxWZDirUTfNlX 4Xag1RSE2ecsplr8ag0FIoS+Sf54= X-Received: by 2002:a1c:49c1:: with SMTP id w184mr73364wma.46.1591632120643; Mon, 08 Jun 2020 09:02:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOUfdYxrvW9CPb/dnvfewyhVs9Qx2I/bhjoR6HiKlxToMKENTue7cOTAycSFeLnlY6TznpXw== X-Received: by 2002:a1c:49c1:: with SMTP id w184mr73337wma.46.1591632120442; Mon, 08 Jun 2020 09:02:00 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id j11sm154169wru.69.2020.06.08.09.01.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:01:59 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 13/35] hw/dma/soc_dma: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:22 +0200 Message-Id: <20200608160044.15531-14-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/dma/soc_dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/dma/soc_dma.c b/hw/dma/soc_dma.c index 3a430057f5..22fd8c38b0 100644 --- a/hw/dma/soc_dma.c +++ b/hw/dma/soc_dma.c @@ -21,6 +21,7 @@ #include "qemu/error-report.h" #include "qemu/timer.h" #include "hw/arm/soc_dma.h" +#include "hw/qdev-deprecated.h" static void transfer_mem2mem(struct soc_dma_ch_s *ch) { @@ -242,6 +243,8 @@ struct soc_dma_s *soc_dma_init(int n) int i; struct dma_s *s = g_malloc0(sizeof(*s) + n * sizeof(*s->ch)); + qdev_warn_deprecated_function_used(); + s->chnum = n; s->soc.ch = s->ch; for (i = 0; i < n; i ++) { -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKED-0004Rx-0o; Mon, 08 Jun 2020 16:02:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEB-0004QC-JK for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:23 +0000 X-Inumbo-ID: 7024f99e-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 7024f99e-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:02:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632142; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g5ly0fcUXOf9qpye/9fR2nyQtN4aqsUxjucs8EhlOCo=; b=KBOaR8c99ngR+4aSR2mkH8Ans4ohxU2RPgBRcCKZTDAYWmyysiiD5hGFI6WmNGjVa7LuhX SrVgOdLxrxmgL0WX53kcWbiK3FSjtv2rI8fb46zRMGrAicZ4rqkdC1J8eqJ1fP6kr5N6tq H02FyPwXqfmkbJ9LKFGWhCNf3AaQeEU= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-428-d3P1SnCsPEq1qVUXQBOo_Q-1; Mon, 08 Jun 2020 12:02:19 -0400 X-MC-Unique: d3P1SnCsPEq1qVUXQBOo_Q-1 Received: by mail-wm1-f70.google.com with SMTP id 11so5433wmj.6 for ; Mon, 08 Jun 2020 09:02:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=g5ly0fcUXOf9qpye/9fR2nyQtN4aqsUxjucs8EhlOCo=; b=g6gVJQKedbDJsMwTsWhKbJp9dBEHDP1/L0uzgklOZUQjRbvRnerwTlDb4AVjD5mpot 1QDY84l0y/T/TAgHTWDXZYYRY6qaIPB3ZpDehaiW67c8VouPySdVYs7etD3n0kUUzAEW SFfDp/1MWO0nEqw66nMzg4rBnGT4ZgfQi1bp9wy7dmWWgyqPEy6qKTBR7Ord30cqlLBt sK7YNdNeUGs6PCr1epeed6AHcATq6NlM62pb2HAuNl92TfiL0xIpRHDEmik2MKi9ZtJR AYrOgRrJTYfkrJh+4sK1EgEzB13oMWD2fXlemFzSSa3WyGX3jNsOPbIc3uUhyGU6cLX7 ZwAA== X-Gm-Message-State: AOAM530i6tVRSAmGVzQ0dU6Eb2IX2t01ACYlQNSd2SQtQDAPYEF19VM0 htFij+yo5AXpxhvVat8FGD3rLyKpxYB3qC/k7gGt7erynmwy7Oxgcow/1soKdn3Gjx2aF9bz/1F p1X7WSm/f2Hvnez/Il8Te9J3a5e4= X-Received: by 2002:a5d:6944:: with SMTP id r4mr23775348wrw.169.1591632138152; Mon, 08 Jun 2020 09:02:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzoiY9HH6DYEAYHN6rucdTjohElJ6XD9T5NIDyn78LYZQIrFIp9Ryvcx8eKgENNoeOnl+u4SA== X-Received: by 2002:a5d:6944:: with SMTP id r4mr23775315wrw.169.1591632137954; Mon, 08 Jun 2020 09:02:17 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id u130sm12527wmg.32.2020.06.08.09.02.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:17 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 16/35] hw/input/lasips2: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:25 +0200 Message-Id: <20200608160044.15531-17-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/input/lasips2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/input/lasips2.c b/hw/input/lasips2.c index 0786e57338..452244f037 100644 --- a/hw/input/lasips2.c +++ b/hw/input/lasips2.c @@ -34,7 +34,7 @@ #include "exec/address-spaces.h" #include "migration/vmstate.h" #include "hw/irq.h" - +#include "hw/qdev-deprecated.h" struct LASIPS2State; typedef struct LASIPS2Port { @@ -269,6 +269,8 @@ void lasips2_init(MemoryRegion *address_space, { LASIPS2State *s; + qdev_warn_deprecated_function_used(); + s = g_malloc0(sizeof(LASIPS2State)); s->irq = irq; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEG-0004Uj-B3; Mon, 08 Jun 2020 16:02:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEF-0004U4-Jb for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:27 +0000 X-Inumbo-ID: 72ea2460-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 72ea2460-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:02:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rWjAvYJiR2Vce0nRqDWV8FQMXBd2aTRIKVfGqqqeffM=; b=Fp3ELPStTjOuCI2wh3Qr1TxUN+zTA1lS6oawlpuxmNGFJPlQRZwuKuXedi5PKnlf/ijE01 RwYWOHNOOW4vESN2GPUueV8V7Ox8+YRINfCOpDu1PedOV7M9UCIC2Zkm/vclokoeIzlOIb JzgEh7DdVApaLHtoL1g1lgUtvtaPjY8= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-368-kdrXROYUNHy98U8QiL-WeQ-1; Mon, 08 Jun 2020 12:02:25 -0400 X-MC-Unique: kdrXROYUNHy98U8QiL-WeQ-1 Received: by mail-wm1-f69.google.com with SMTP id r1so5962wmh.7 for ; Mon, 08 Jun 2020 09:02:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=rWjAvYJiR2Vce0nRqDWV8FQMXBd2aTRIKVfGqqqeffM=; b=BKJzTd6SUBqDrkRvvW8UhZlryW17ahOLVvlLN/oDGddqM7tz9XmLWCncMp4Z7V2XV0 nH9STxTX8x7T+VVpMSdDwTYPyKgErySkvmi5RrddfIoGLVC/W5mQ5DV7glDel8POnz/d LPE2gnQzEDDLXGUCGSw2mIDOcNC8AallSvh2rUCVSzpb68YNosDPj+bgYXEWp8nyIbVU oYfadF+ILtLtj8aEpN8mj91kGrU+RLjmJmpODA7t9ZYkKTb0Qf5Cp69Z0KvZtefUWUgn CRxIeG5d/OzpXpvFCCMeEmJEfpmV3abfgmH+hfa57A6k0slK8lYfADK0Us+IUbJfkLvc 3oCg== X-Gm-Message-State: AOAM530pRpGBJD/eQnGUtfUP8NpHIgBTKN6RrA86DGtZFcHxlf8fgV+f j6qlmnkSSswmE2zSM+uHAtYGtkOUUEW9oVT1e/Cl0O/oxVPLZrTZr0Se7zzvq+FDWIlmecH4BDx AIV70QgW0RYaMwaPjmiidCWE3Vs8= X-Received: by 2002:a5d:4987:: with SMTP id r7mr23761277wrq.316.1591632143873; Mon, 08 Jun 2020 09:02:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy8yfQfybue0LoXzyzfK8+trtOuK8e4qLitwG3WzemMauiha6gB9njX0C0ZNjvkq/B156qsJg== X-Received: by 2002:a5d:4987:: with SMTP id r7mr23761254wrq.316.1591632143730; Mon, 08 Jun 2020 09:02:23 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id s8sm142543wrm.96.2020.06.08.09.02.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:23 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 17/35] hw/input/pckbd: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:26 +0200 Message-Id: <20200608160044.15531-18-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/input/pckbd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c index 60a4130320..c7f42be63b 100644 --- a/hw/input/pckbd.c +++ b/hw/input/pckbd.c @@ -31,7 +31,7 @@ #include "hw/input/i8042.h" #include "sysemu/reset.h" #include "sysemu/runstate.h" - +#include "hw/qdev-deprecated.h" #include "trace.h" /* Keyboard Controller Commands */ @@ -467,6 +467,8 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq, { KBDState *s = g_malloc0(sizeof(KBDState)); + qdev_warn_deprecated_function_used(); + s->irq_kbd = kbd_irq; s->irq_mouse = mouse_irq; s->mask = mask; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEO-0004cB-Le; Mon, 08 Jun 2020 16:02:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEN-0004bV-Q1 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:35 +0000 X-Inumbo-ID: 779caeec-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 779caeec-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:02:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632154; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WCNM8bx54yBBH5o9OGeaVnQ5KO/kQFXlsHgIbovX6w0=; b=OSP+kVLeIhqukfrvtEtsMVywZKXWRhzo95azkYUBDgNofS3KrnVOoAXpLsyuTz8agIcqca tnYw9n8/ecymqMUxmKxAusqsuDLbO48qqHTHv9nKxR24C9fz7kCPl0e2jTufYah1EzE/8d CZ6q7kEbbAuXPx+i6dq1kLaPIOTc94k= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-215-GZscxDwhPtCzJ98VSVFCMA-1; Mon, 08 Jun 2020 12:02:31 -0400 X-MC-Unique: GZscxDwhPtCzJ98VSVFCMA-1 Received: by mail-wr1-f71.google.com with SMTP id s7so7360667wrm.16 for ; Mon, 08 Jun 2020 09:02:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=WCNM8bx54yBBH5o9OGeaVnQ5KO/kQFXlsHgIbovX6w0=; b=hnLe+SOYxOxkTQo0lF9i5hc+8NxIWDUbFPvmYCEo+yWUE9C9Bvvim1dr2XzMXGsS6w IH7wrB2sjvfsnsXjBMqmu2lRb9SNzgP6kvfHCVVfX8EKksJkUUrjh0yLGMmDPZUSEqax YW4f+Y7zErVvKTzGjXAiYuWCyVAR19uzTS5IoStZcu6jD47DHoPmDaBPEBWWI13UtI5r qX1jMAVQWoKXDxHgQNe/6zYlY1bgB7EwyD4PTgsvwr/pJIJSjt2ukK7kPfHL9p7wppml AHt1nnFj2lznfOyb/er63MDDUICxGFoGvvwYYh+ckosPPpy0m0xhoSvRBNNOJuHHBsQP LGcQ== X-Gm-Message-State: AOAM530JkTwFrCHihvtkDTqp74LkzlgtPJkG6sVPpCGZ4U0aIEYe9SEd xpbnArGoFaU0BYDfg0k0imHnoX4NZuU1wYj9A1+BMqRA8eIjn1hBSvCB2VFIiuwKN8TKaxQw5/Z q0ghoWHIbe/85TYfOiO9pQ3pM2q8= X-Received: by 2002:adf:e592:: with SMTP id l18mr25927551wrm.175.1591632150057; Mon, 08 Jun 2020 09:02:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzHbdh31UUEH4xek22DEL2omJfknmcGPt3J3CvVWH4WiiSsovdS3jiUsnUw+9yn+Qkjdrssug== X-Received: by 2002:adf:e592:: with SMTP id l18mr25927507wrm.175.1591632149848; Mon, 08 Jun 2020 09:02:29 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id c6sm144638wro.92.2020.06.08.09.02.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:29 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 18/35] hw/input/ps2: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:27 +0200 Message-Id: <20200608160044.15531-19-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/input/ps2.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/hw/input/ps2.c b/hw/input/ps2.c index f8746d2f52..0d84061cae 100644 --- a/hw/input/ps2.c +++ b/hw/input/ps2.c @@ -30,7 +30,7 @@ #include "ui/input.h" #include "sysemu/reset.h" #include "sysemu/runstate.h" - +#include "hw/qdev-deprecated.h" #include "trace.h" /* debug PC keyboard */ @@ -1136,6 +1136,8 @@ void *ps2_kbd_init(void (*update_irq)(void *, int), void *update_arg) { PS2KbdState *s = (PS2KbdState *)g_malloc0(sizeof(PS2KbdState)); + qdev_warn_deprecated_function_used(); + trace_ps2_kbd_init(s); s->common.update_irq = update_irq; s->common.update_arg = update_arg; @@ -1158,6 +1160,8 @@ void *ps2_mouse_init(void (*update_irq)(void *, int), void *update_arg) { PS2MouseState *s = (PS2MouseState *)g_malloc0(sizeof(PS2MouseState)); + qdev_warn_deprecated_function_used(); + trace_ps2_mouse_init(s); s->common.update_irq = update_irq; s->common.update_arg = update_arg; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKES-0004gF-Vz; Mon, 08 Jun 2020 16:02:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKER-0004ep-G4 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:39 +0000 X-Inumbo-ID: 79b4496b-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 79b4496b-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:02:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632159; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3WzkinKDRWpQmIIO97X+MugaJnDZKw0ffp1ti6/ctwc=; b=LyUR2LmtYlw+ksuhAT1yGgjrce4DSADfuhbGMGOHDtEkdN6UUVnUgtCLGui9aFzIopFHVj 8XSkUEjyqzP+fgdE4g/gh7UFVeBQgX/mMzdgzAdEMqkMkhxw9fKulm4lwWY4bxcqIIgXM7 TVbYv5yctCIpqUWC+n+CayuEhXDhKE4= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-260-4BxmoRxxP92FzDGoP6qjuw-1; Mon, 08 Jun 2020 12:02:37 -0400 X-MC-Unique: 4BxmoRxxP92FzDGoP6qjuw-1 Received: by mail-wr1-f71.google.com with SMTP id s17so7305839wrt.7 for ; Mon, 08 Jun 2020 09:02:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3WzkinKDRWpQmIIO97X+MugaJnDZKw0ffp1ti6/ctwc=; b=S8ZTdyOXVLHsWxdLWAV/Jild1kGQ5ez+HKszzKNTREG5nTJc3bUULgmwRO3j4ISock H3MgV75gYIR4i1ETQlWWqKPaeF4MsxtXHUTH3gQpdAH4bHblyJKz+reNkuNSq7rwUAQz 4JMQFrjZ6aSTmYdFYT62pxiv4m/MSDMkCvRiGEsa9ToHWseD8lhpEONiIy7k7vTedbGj bsQFE2gDmezTVttzEntTnk/9eqPbXgx04qha66A7zr6lHlhXlKM7t3yAPTRcDspjTXSL bWL8bAMGb+d+cQuZ+CFQCxdiSuQ3wT4M6zo8dCy+UhxM6NgIy+7tAYAuhFTDcTsKhP7x hlGg== X-Gm-Message-State: AOAM532MRUKE+OOKf5QztQ4jFMM7fQLVc9ip4zR1tfbOksoEuwpDJ+hO Mr11g2jR5sX1SwBHIxh8B7YaK16J5ssQApuEWpHq7WoGgqn88eL01kPFtV3wkyOcL+5s+X2KTgE Bq/Xc6qeJ1jWiaqqRzlcddzY79CU= X-Received: by 2002:a5d:6391:: with SMTP id p17mr25853421wru.118.1591632155838; Mon, 08 Jun 2020 09:02:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzDmwNfyaecxfbcj81e+/jUBcU6vumJ01a4QLGsVfaCgs3E8cqqhTSmTr88Achkag+c/jFzSw== X-Received: by 2002:a5d:6391:: with SMTP id p17mr25853379wru.118.1591632155624; Mon, 08 Jun 2020 09:02:35 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id o10sm183753wrj.37.2020.06.08.09.02.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:34 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 19/35] hw/input/tsc2005: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:28 +0200 Message-Id: <20200608160044.15531-20-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/input/tsc2005.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/input/tsc2005.c b/hw/input/tsc2005.c index 55d61cc843..1f97b82379 100644 --- a/hw/input/tsc2005.c +++ b/hw/input/tsc2005.c @@ -27,6 +27,7 @@ #include "hw/irq.h" #include "migration/vmstate.h" #include "trace.h" +#include "hw/qdev-deprecated.h" #define TSC_CUT_RESOLUTION(value, p) ((value) >> (16 - (p ? 12 : 10))) @@ -489,6 +490,8 @@ void *tsc2005_init(qemu_irq pintdav) { TSC2005State *s; + qdev_warn_deprecated_function_used(); + s = (TSC2005State *) g_malloc0(sizeof(TSC2005State)); s->x = 400; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEY-0004lQ-AS; Mon, 08 Jun 2020 16:02:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEW-0004k4-Uc for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:44 +0000 X-Inumbo-ID: 7d4f0fb0-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 7d4f0fb0-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:02:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7Lcxf8cj+CxLJSf8aQEjLTWyUhOWt7SwLOi9PO4gCM4=; b=Ws7dibcH76dLE0IMqS9G+8PrYyLzxFdL2Mzcp1ynzfIPrCCD17/vI0ZiXSlye+Fu7X5+s/ vHIAfOR4oZQttPgKRoU5jrIaHrUT5x2AsTSubzvkPxcWvv57+AeOE7/wcx3Aql78BIuH0a G9Rkc28mHLaJIqQ/9FqHVs4eFodQM0o= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-138-yQDt05YoPFm1mWxhzHE84Q-1; Mon, 08 Jun 2020 12:02:42 -0400 X-MC-Unique: yQDt05YoPFm1mWxhzHE84Q-1 Received: by mail-wr1-f70.google.com with SMTP id w4so7365688wrl.13 for ; Mon, 08 Jun 2020 09:02:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7Lcxf8cj+CxLJSf8aQEjLTWyUhOWt7SwLOi9PO4gCM4=; b=ZlwjrFd6WBtEioLlIXCiMa8E8t4grs9ACbMWwj1xUqPQckvMsdB3A1FPoEGmT+qkE3 Y0HQi8L+d1XvvpBVXXbnaOtSAL9k+R3G9Vq0ZandharXTk7V9EstjybEQDt5+3ToBUK3 xd+sVQZPG1iQtQ4AX7q0uPW7QmXF7ciSlbrJzIrKB8cUHrVkoiCHOGgmxgVzhzQstmPJ CAiRNIiurrQ24WBFHgQvWGY8kdsavlw8zw7wylmUnpLGw6rYBLIK48Op1GU9P3zX31yz tLtWfrKs/3ZmaWKFmzdxy3FjN2QgjPSGKMlFX4zGBMJb/rBtRWi68mQxBYVJ+FYav2nI /TqQ== X-Gm-Message-State: AOAM530CyrDZGJI/U59Yjmu2qg1Zcz9G9/0tFL+J/uIHwsERuTeeFFUg LDNNbGoHGLd0TfDqrTPpDWnUv0PKyNZyBXHqCvHpsQAl35Efcqk/rS1wnKRCCngi5ENTfx+DiqM pzJiEo0jj6WjYiChPvTqx+KYglhY= X-Received: by 2002:a1c:6056:: with SMTP id u83mr60177wmb.138.1591632161698; Mon, 08 Jun 2020 09:02:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJztIcOuKmMAnKpEQL/s7NO4XNCQYfWj4X6mQCPh85ejUPn/olQa6U5W1zctaCPlsras+JjNJA== X-Received: by 2002:a1c:6056:: with SMTP id u83mr60154wmb.138.1591632161497; Mon, 08 Jun 2020 09:02:41 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id a81sm19165wmd.25.2020.06.08.09.02.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:40 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 20/35] hw/intc/i8259: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:29 +0200 Message-Id: <20200608160044.15531-21-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/intc/i8259.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c index 51b27f6a34..9d9609cdab 100644 --- a/hw/intc/i8259.c +++ b/hw/intc/i8259.c @@ -30,6 +30,7 @@ #include "qemu/log.h" #include "hw/isa/i8259_internal.h" #include "trace.h" +#include "hw/qdev-deprecated.h" /* debug PIC */ //#define DEBUG_PIC @@ -414,6 +415,8 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq) ISADevice *isadev; int i; + qdev_warn_deprecated_function_used(); + irq_set = g_new0(qemu_irq, ISA_NUM_IRQS); isadev = i8259_init_chip(TYPE_I8259, bus, true); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEf-0004t5-Pg; Mon, 08 Jun 2020 16:02:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEe-0004ro-De for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:52 +0000 X-Inumbo-ID: 7caabcee-a9a1-11ea-96fb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7caabcee-a9a1-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 16:02:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 74D59AEF6; Mon, 8 Jun 2020 16:02:46 +0000 (UTC) Subject: Re: [PATCH for-4.14 v3] x86/rtc: provide mediated access to RTC for PVH dom0 To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200608102948.7327-1-roger.pau@citrix.com> <71e0d073-165b-8fcc-62b9-3fb028b3c526@suse.com> <20200608155606.GB722@Air-de-Roger> From: Jan Beulich Message-ID: <96f7bc9c-23f2-b15a-d80b-77470c715671@suse.com> Date: Mon, 8 Jun 2020 18:02:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200608155606.GB722@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 17:56, Roger Pau Monné wrote: > On Mon, Jun 08, 2020 at 01:47:26PM +0200, Jan Beulich wrote: >> On 08.06.2020 12:29, Roger Pau Monne wrote: >>> Mediated access to the RTC was provided for PVHv1 dom0 using the PV >>> code paths (guest_io_{write/read}), but those accesses where never >>> implemented for PVHv2 dom0. This patch provides such mediated accesses >>> to the RTC for PVH dom0, just like it's provided for a classic PV >>> dom0. >>> >>> Pull out some of the RTC logic from guest_io_{read/write} into >>> specific helpers that can be used by both PV and HVM guests. The >>> setup of the handlers for PVH is done in rtc_init, which is already >>> used to initialize the fully emulated RTC. >>> >>> Without this a Linux PVH dom0 will read garbage when trying to access >>> the RTC, and one vCPU will be constantly looping in >>> rtc_timer_do_work. >>> >>> Note that such issue doesn't happen on domUs because the ACPI >>> NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing >>> the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the >>> accesses are not emulated but rather forwarded to the physical >>> hardware. >>> >>> No functional change expected for classic PV dom0. >>> >>> Signed-off-by: Roger Pau Monné >> >> Reviewed-by: Jan Beulich >> preferably with ... >> >>> @@ -1110,6 +1111,67 @@ static unsigned long get_cmos_time(void) >>> return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); >>> } >>> >>> +/* Helpers for guest accesses to the physical RTC. */ >>> +unsigned int rtc_guest_read(unsigned int port) >>> +{ >>> + const struct domain *currd = current->domain; >>> + unsigned long flags; >>> + unsigned int data = ~0; >>> + >>> + switch ( port ) >>> + { >>> + case RTC_PORT(0): >>> + /* >>> + * All PV domains are allowed to read the latched value of the first >>> + * RTC port. This is useful in order to store data when debugging. >>> + */ >> >> ... at least the 2nd sentence of this and ... >> >>> +void rtc_guest_write(unsigned int port, unsigned int data) >>> +{ >>> + struct domain *currd = current->domain; >>> + unsigned long flags; >>> + >>> + switch ( port ) >>> + { >>> + case RTC_PORT(0): >>> + /* >>> + * All PV domains are allowed to write to the latched value of the >>> + * first RTC port. This is useful in order to store data when >>> + * debugging. >>> + */ >> >> ... this comment dropped again. This justification of the possible >> usefulness is my very private guessing. Just like the original code >> was, I think we could leave this uncommented altogether. > > Hm, as you wish. I would prefer to leave something similar to the > first part of the comment, what about: > > /* > * All PV domains (and PVH dom0) are allowed to write/read to the > * latched value of the first RTC port, as there's no access to the > * physical IO ports. > */ Fine with me. > I can adjust and then add a newline after the break in the RTC_PORT(0) > case which I missed. In this small a switch() I don't view this as mandatory, so I'd be fine to also simply exchange the comments while committing. If there's a new version by then (tomorrow, I guess), I'll use it of course. Oh, wait - you mean after the RTC_PORT(1) cases, don't you? Yes, for consistency having blank lines there would be nice indeed. But still something that could be done while committing, if you like. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEh-0004uc-2g; Mon, 08 Jun 2020 16:02:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEf-0004st-IL for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:53 +0000 X-Inumbo-ID: 81e1445a-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 81e1445a-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:02:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632173; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ERIE6m4jxrzYfG68k2WyVt3M0Z5JMhyFzvtHzf4SuG8=; b=dREsi8+9USoV9mqRVVqwwtnDzTxDqYdeauDbid0PtNqYUm1LW5HjOsYbhcRhq5l9b9QK4k X8yl9Mz00jJhpoBhf3W2lYQsN9IRv3ovhDvRWtueQHfCs1l8vxMna/hOjfrDEbJ5cYjyDF K4E+NkCxazqaS9FMtQLCVrk2unkEEqI= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-240-5bUDAgB7NHK05YOvBySRwA-1; Mon, 08 Jun 2020 12:02:49 -0400 X-MC-Unique: 5bUDAgB7NHK05YOvBySRwA-1 Received: by mail-wr1-f69.google.com with SMTP id a4so7339930wrp.5 for ; Mon, 08 Jun 2020 09:02:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ERIE6m4jxrzYfG68k2WyVt3M0Z5JMhyFzvtHzf4SuG8=; b=nJn+ko453m+tMkHFsstwOX3LAUsWaKIAtQlR6xH19uXM1R+K3EGxjbMiXjkA42ArVr ctOWyKhUIB31wgupDxhF29D+D36+GVnR6J8wB3+6yAlXRtvS4kN/9T739OpGd8RPc9MY wYAku6z5AdUnNVfPfsdcIdv0QRp/NLaYoyZyQNG5z4xjdf77ly83Jr1sHC2FiQnN91Hu wUJpQDPYhaYmsCQG06XSIyCfz5JNExpqYYTVG3ZLKny41X8ykZdhT+TvsPdhk/p7pyHM JP1tahwmXswfEVQzvuuUaQA64sUL8WVGvvouZ/c1b8b0ibS0qF9FMI9KkppEM1VJfXXD J67Q== X-Gm-Message-State: AOAM532Utb7DuQz77kxJsJ0eBxSutV1o03QhyC78iKqtKtteJ/oiY7Bk gM7NVXXU2FOknX8ZnO/Kjxkceun/nCm2Ef0VOyJKPZbzMjjvzhjXpOEDXwSnQVUn9W9ogDpZHkG 02PmkQllLeGAiJtXthEFlv/7BAWA= X-Received: by 2002:adf:cf06:: with SMTP id o6mr23925419wrj.163.1591632168116; Mon, 08 Jun 2020 09:02:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxl0bue+F9URFV2MLoWaC0ni3jZ25V2PPkWtrtnwtHvWPF3nP5GuuAiBdquATZ2VeeHOXjWiw== X-Received: by 2002:adf:cf06:: with SMTP id o6mr23925378wrj.163.1591632167963; Mon, 08 Jun 2020 09:02:47 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id z16sm155794wrm.70.2020.06.08.09.02.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:47 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 21/35] hw/lm32/lm32_hwsetup: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:30 +0200 Message-Id: <20200608160044.15531-22-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/lm32/lm32_hwsetup.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/lm32/lm32_hwsetup.h b/hw/lm32/lm32_hwsetup.h index de94de177a..f4a4d8fe4b 100644 --- a/hw/lm32/lm32_hwsetup.h +++ b/hw/lm32/lm32_hwsetup.h @@ -27,6 +27,7 @@ #include "qemu/cutils.h" #include "hw/loader.h" +#include "hw/qdev-deprecated.h" typedef struct { void *data; @@ -57,6 +58,8 @@ static inline HWSetup *hwsetup_init(void) { HWSetup *hw; + qdev_warn_deprecated_function_used(); + hw = g_malloc(sizeof(HWSetup)); hw->data = g_malloc0(TARGET_PAGE_SIZE); hw->ptr = hw->data; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:02:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:02:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEl-0004zF-DM; Mon, 08 Jun 2020 16:02:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEj-0004xK-Fa for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:02:57 +0000 X-Inumbo-ID: 84dd67cc-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 84dd67cc-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:02:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632177; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L3z7/2H5A05Y0veUntj0sB8fSeRKRdeeSYeKdBwF4Hw=; b=fpmhIKFvXLBpniJCwiDDDhPv207fXRcRPf8Fyzb5skveGIlLOsn5quV6q8sdbFQl24gin0 pn8EXow3zBSue5C8vbvUVw2Mp3zYD3fBOtJEipjW+o09za2eUlMYrD7hIhzVutB/3tAQPA bz1mHO1dTKHznxeOYtNDRhN1EJmjMr0= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-184-7XjA2IgJMUC4pFDJteqlGQ-1; Mon, 08 Jun 2020 12:02:55 -0400 X-MC-Unique: 7XjA2IgJMUC4pFDJteqlGQ-1 Received: by mail-wr1-f69.google.com with SMTP id t5so7327475wro.20 for ; Mon, 08 Jun 2020 09:02:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=L3z7/2H5A05Y0veUntj0sB8fSeRKRdeeSYeKdBwF4Hw=; b=XwQ4gqHPIImJ644DyU7+b98n6CPZSplRgJZAkqXd/bH4qMPsRGu2jra8/JhzP46H1L uMHXlYwB8lFJq2Bm2A6IaP3r+FxIOUPwE+PgUn5UOLf/I8D6q6r2P5V2LF6ixmMGIciY EVsJ3FT3vHPvLZzbBm9Q2NrisnLhRonyn2T56QKC8yMFltfEOizJqsE7en4CHAU4IZ3X xCzZXOcF79vIKu1ARmstd8kdinumyifP/S6IjTskfi+4yrWrlPzXhP/VdSSpF6PvOZhF 1dp8UjPVvyfGjXdeC5A0TZA9fWVOzc56PHybTStSQVEfror9mlNG25CmzcK5q3ST8Vnk b1eQ== X-Gm-Message-State: AOAM533n5E7CIXKUfeS7o08hCVtT/nEPwrosY/10o4b1fDgL9rMcUWHV dr0VRu1gn9Ez0IzTcPjkpmK6mxUJHEmswoOBSak8TCccoFwbuwIvFjSdwMn6MTtsgqSHcvT1O/L 3anfwIPjeuAOY6oHolu+Ju+o1Jvw= X-Received: by 2002:a5d:4841:: with SMTP id n1mr25485583wrs.64.1591632174026; Mon, 08 Jun 2020 09:02:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxxA5a/fZ3ZxfFd0NOMzf3yCM2KT4oTBQZPfei9kF9bupOnm+jcw1E0PX8MzjNlME16qgafXA== X-Received: by 2002:a5d:4841:: with SMTP id n1mr25485541wrs.64.1591632173820; Mon, 08 Jun 2020 09:02:53 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id q8sm49134wmq.1.2020.06.08.09.02.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:53 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 22/35] hw/m68k/mcf520x: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:31 +0200 Message-Id: <20200608160044.15531-23-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/m68k/mcf5206.c | 5 +++++ hw/m68k/mcf5208.c | 3 +++ 2 files changed, 8 insertions(+) diff --git a/hw/m68k/mcf5206.c b/hw/m68k/mcf5206.c index a2fef04f8e..ec0d176674 100644 --- a/hw/m68k/mcf5206.c +++ b/hw/m68k/mcf5206.c @@ -16,6 +16,7 @@ #include "qemu/timer.h" #include "hw/ptimer.h" #include "sysemu/sysemu.h" +#include "hw/qdev-deprecated.h" /* General purpose timer module. */ typedef struct { @@ -144,6 +145,8 @@ static m5206_timer_state *m5206_timer_init(qemu_irq irq) { m5206_timer_state *s; + qdev_warn_deprecated_function_used(); + s = g_new0(m5206_timer_state, 1); s->timer = ptimer_init(m5206_timer_trigger, s, PTIMER_POLICY_DEFAULT); s->irq = irq; @@ -566,6 +569,8 @@ qemu_irq *mcf5206_init(MemoryRegion *sysmem, uint32_t base, M68kCPU *cpu) m5206_mbar_state *s; qemu_irq *pic; + qdev_warn_deprecated_function_used(); + s = g_new0(m5206_mbar_state, 1); memory_region_init_io(&s->iomem, NULL, &m5206_mbar_ops, s, diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c index 2ab9701ad6..72627f6833 100644 --- a/hw/m68k/mcf5208.c +++ b/hw/m68k/mcf5208.c @@ -26,6 +26,7 @@ #include "hw/sysbus.h" #include "elf.h" #include "exec/address-spaces.h" +#include "hw/qdev-deprecated.h" #define SYS_FREQ 166666666 @@ -191,6 +192,8 @@ static void mcf5208_sys_init(MemoryRegion *address_space, qemu_irq *pic) m5208_timer_state *s; int i; + qdev_warn_deprecated_function_used(); + /* SDRAMC. */ memory_region_init_io(iomem, NULL, &m5208_sys_ops, NULL, "m5208-sys", 0x00004000); memory_region_add_subregion(address_space, 0xfc0a8000, iomem); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEy-0005DE-Nc; Mon, 08 Jun 2020 16:03:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKEy-0005Cr-E2 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:12 +0000 X-Inumbo-ID: 8c86487c-a9a1-11ea-9ad7-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 8c86487c-a9a1-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 16:03:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632189; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RKgZ6rumXDcRDPMbmvtvFrKHcFm+r1xyGKVfqjvJc6Q=; b=TGCSDTjSjVESFM0s9RVzGVk/nBmwY3w+YYNoJXfVGVMfhPDDGxFeej0/JMo2m9OXNii0Se 5ohss3AoEbYC/QoJy4IGccOvaXAcun9zOqJUwkVdWdt1iqJ4uHDFtb6GI/BAsLcyfvGkoC 3LKehgJXvpYrVHtx0Rs3Q7sKTOixG8U= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-103-2ic1ciL8M6qX7rYM_hrwlw-1; Mon, 08 Jun 2020 12:03:06 -0400 X-MC-Unique: 2ic1ciL8M6qX7rYM_hrwlw-1 Received: by mail-wr1-f72.google.com with SMTP id m14so7339203wrj.12 for ; Mon, 08 Jun 2020 09:03:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=RKgZ6rumXDcRDPMbmvtvFrKHcFm+r1xyGKVfqjvJc6Q=; b=exPvCKM6LgFWZoRWsyPVJe+KZcFa308yGKEH2nWMb6PQymKNOKVVQOBsMPytjkpdMs GimAVuEHnccJB8dtfSmijNCvZ5ZB3AzWv64yG+tVCk/ck0KRum0eYsFWogExsYpcCcXh 86qjl0/7wLw1uaeI+66O1hqD4IZKR+CQphM5NOKGa8I/d5H2Slg5PS/YiEz06ZKiMqfm 4ZZ1em9pjYGL141w7d+9kB9TW8BUhLtAQiSDeM9ztWUgNBSlAO8+ctgVlYbRCLsx3Jvt OCn9fJigQtgHKNSM59F/A5/VHrrpUI8JILjQOhCY2eHoC9utBNSNr7ovHfaoADfuCLad PRfw== X-Gm-Message-State: AOAM532Adv+fYOUWe0111xzS5bNKfZVKKXvhWhNEygH9X6ALW3rap+IW u/Smfi8PrhtHvAHa6CW6e11j9+xk4UXiRhSzCVZaIGLFzKTIhIrUfsfVMPXUu5m8kEunf5Y3tJC Pg21w6ZnoLZ71X9sW3F/oCJAS/UI= X-Received: by 2002:a1c:a906:: with SMTP id s6mr21527wme.171.1591632185578; Mon, 08 Jun 2020 09:03:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzU3FFzPx8GJONXk2lb2PRS9hlQzh1ioPeLu4txPuU4I7Pa7KejCTY0NavLN6WE+tDOlF/rwQ== X-Received: by 2002:a1c:a906:: with SMTP id s6mr21489wme.171.1591632185399; Mon, 08 Jun 2020 09:03:05 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id g25sm30434wmh.18.2020.06.08.09.03.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:04 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 24/35] hw/misc/cbus: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:33 +0200 Message-Id: <20200608160044.15531-25-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/misc/cbus.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/misc/cbus.c b/hw/misc/cbus.c index 3c3721ad2d..24e197684f 100644 --- a/hw/misc/cbus.c +++ b/hw/misc/cbus.c @@ -25,6 +25,7 @@ #include "hw/irq.h" #include "hw/misc/cbus.h" #include "sysemu/runstate.h" +#include "hw/qdev-deprecated.h" //#define DEBUG @@ -135,6 +136,8 @@ CBus *cbus_init(qemu_irq dat) { CBusPriv *s = (CBusPriv *) g_malloc0(sizeof(*s)); + qdev_warn_deprecated_function_used(); + s->dat_out = dat; s->cbus.clk = qemu_allocate_irq(cbus_clk, s, 0); s->cbus.dat = qemu_allocate_irq(cbus_dat, s, 0); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKF3-0005Hr-1j; Mon, 08 Jun 2020 16:03:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKF2-0005HC-CC for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:16 +0000 X-Inumbo-ID: 8ffd052c-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 8ffd052c-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:03:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632195; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=R7tSIIx0YAEULmCHrXDbhmRzYLD86lXGUTjUWu9J2Gg=; b=VRyUzNKCax0fgLHPHa6Sl8EK0azfGKyeK/3k3ypgafC8JYydnbQGURXZ+NxYZYTfQya6s/ rnFFZwrcD2OPdGVmTQe9mHptycE06lDild6kQyDhGmjfXiPb+03lyEdEJIE+QikKO3xs4N kcEXM1mcDknwPypIReRTuy01412vReQ= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-280-QycDscOCMo2qBiQCyUGsJA-1; Mon, 08 Jun 2020 12:03:14 -0400 X-MC-Unique: QycDscOCMo2qBiQCyUGsJA-1 Received: by mail-wr1-f69.google.com with SMTP id f4so7350465wrp.21 for ; Mon, 08 Jun 2020 09:03:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=R7tSIIx0YAEULmCHrXDbhmRzYLD86lXGUTjUWu9J2Gg=; b=jXl7ai4CZ/JwVk80EK3Nh94bj8X/xhOK67q2lyWXyiAVkMdqtA7EuEvEN4gHEGZT3Q DKgSPm/49WHvpb6oqoGqixMGiZ9z4C/A28N8vbIGLkTXDB5jx6dfBEdw1y25NyoRlmWs zivDtj/HK9p9cgBqAfA9FdRkc5SfSp3+QR0UB8AepSUxssGJD9OInB4tDAHWFWakLPSa LRwUbL9oWDACpnQLb3CHCuDV/TqQBQsP/Sr7zUcCA9lJHFCLb+Bt0kwlVqH+C7qwsHSt FqnhgAjCg9yytH9wBGKG8gYqqlm+4jOacNviOI8R0mlJUhTy+K/vEUlNi2ApyOzimdch ihqw== X-Gm-Message-State: AOAM533zlA/eC66iVf0VAESChl767CBi7Eylf+S1tr/bQhdjSodZN5ar etCxfNFRs7s+QLEuiuEZHqsEMu/zjqCv09C7ADkSVklx0ACHrwqrC4Pznj+yPvFW4bvwBnd2yXj 79vzWl2/xVflUxRjyIkM7R28aZ0M= X-Received: by 2002:a05:6000:10cf:: with SMTP id b15mr23742582wrx.214.1591632191245; Mon, 08 Jun 2020 09:03:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyiLyN7q/sPm3H+0NWOb+JiZp0uyhOR/YmqM2AxV/YlDV1PyuM240OziAWJ+tx+PgKwy933zg== X-Received: by 2002:a05:6000:10cf:: with SMTP id b15mr23742535wrx.214.1591632190993; Mon, 08 Jun 2020 09:03:10 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id e15sm39541wme.9.2020.06.08.09.03.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:10 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 25/35] hw/nvram/eeprom93xx: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:34 +0200 Message-Id: <20200608160044.15531-26-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/nvram/eeprom93xx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/nvram/eeprom93xx.c b/hw/nvram/eeprom93xx.c index ca6f591c84..56603ea42b 100644 --- a/hw/nvram/eeprom93xx.c +++ b/hw/nvram/eeprom93xx.c @@ -39,6 +39,7 @@ #include "hw/nvram/eeprom93xx.h" #include "migration/qemu-file-types.h" #include "migration/vmstate.h" +#include "hw/qdev-deprecated.h" /* Debug EEPROM emulation. */ //~ #define DEBUG_EEPROM @@ -300,6 +301,8 @@ eeprom_t *eeprom93xx_new(DeviceState *dev, uint16_t nwords) eeprom_t *eeprom; uint8_t addrbits; + qdev_warn_deprecated_function_used(); + switch (nwords) { case 16: case 64: -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKF4-0005Jt-FJ; Mon, 08 Jun 2020 16:03:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKF3-0005IM-DX for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:17 +0000 X-Inumbo-ID: 8e7f317a-a9a1-11ea-ba62-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 8e7f317a-a9a1-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 16:03:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632193; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bGDaAMWSjpprqA7Io3dm7QCtlFgafERZCyah8ISMES0=; b=bf5ZFLPDxjE6uiQntaPwYH/JDEJnO2OnpzJmRieVnXA5g817BBjWqKROH+Ubd6CUCgp6eC u3T0y4xfwQmFNhEmDf4Jf0uyNvwIgZEtAMvNzLRfBi5UDLrMJbjmSMsnHUHCdCpI+WzQ/Q nOeO5+ilEZkg0lXck7CJioQbHk450e4= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-120-FNu1G7uOMlustuBoYjh4jw-1; Mon, 08 Jun 2020 12:03:01 -0400 X-MC-Unique: FNu1G7uOMlustuBoYjh4jw-1 Received: by mail-wm1-f72.google.com with SMTP id p24so13297wmc.1 for ; Mon, 08 Jun 2020 09:03:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=bGDaAMWSjpprqA7Io3dm7QCtlFgafERZCyah8ISMES0=; b=WN4tTUjx3+znpykV0GE1TdKbx9Vv8DDNOxFATeiC76gTTHMa04A7vWbDD8z+pIwkKP VeZzgZss1XJe55yCaqtojpIxUHV48+40x+q0r57lIC52B2BGvPYgpClwYh+x8uEi2b31 4LEfA7+yHH+JgH+N2oknKc5zZFJ3ehQbhiH89PH1zaKFi+R8dWVS1DOnGY7RpROPs0mq W6nWhY9doD1MyCsElMZ2H3eeXYWNeoaev0K0we6FOal6Bm/G7tPGLlurH5aQLnb2vzFa V4jQWHKuEYyS7RnmVQ6EjLcXBOwiziKUxhWL/uzGzaSd8AwObwHkW/n0aWXoJfUSUecJ jvLQ== X-Gm-Message-State: AOAM532W2gcluKOrr4i5SktTsJXREo/FfYxpfYzkZdF4NPrRcVKcaFO4 DxXXysy7VrA0w/aL82bN004FcvTFg3XW2bq7TIydy7H7pFHbv6S0+zKO9XezBKwSCd3BNnono8C Cc/g0qxKChT4smewRfD1qsKjFYfo= X-Received: by 2002:a7b:c201:: with SMTP id x1mr78869wmi.58.1591632180064; Mon, 08 Jun 2020 09:03:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyF5+TIjMo5Pv/JZUc9oRpRqa5yr/ufMOXB39AL2QL+RAu+P6Qy6euM0Zs2QNe7FGM5NNcPJw== X-Received: by 2002:a7b:c201:: with SMTP id x1mr78842wmi.58.1591632179907; Mon, 08 Jun 2020 09:02:59 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id q1sm34631wmc.12.2020.06.08.09.02.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:02:59 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 23/35] hw/misc/applesmc: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:32 +0200 Message-Id: <20200608160044.15531-24-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/misc/applesmc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c index 1c4addb201..d63f19038d 100644 --- a/hw/misc/applesmc.c +++ b/hw/misc/applesmc.c @@ -36,6 +36,7 @@ #include "ui/console.h" #include "qemu/module.h" #include "qemu/timer.h" +#include "hw/qdev-deprecated.h" /* #define DEBUG_SMC */ @@ -253,6 +254,8 @@ static void applesmc_add_key(AppleSMCState *s, const char *key, { struct AppleSMCData *def; + qdev_warn_deprecated_function_used(); + def = g_malloc0(sizeof(struct AppleSMCData)); def->key = key; def->len = len; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKF8-0005Om-Pv; Mon, 08 Jun 2020 16:03:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKF6-0005Mf-TZ for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:20 +0000 X-Inumbo-ID: 92650185-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 92650185-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:03:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632199; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J738BQqBvhpMt3eJFPP/lmrii93ELO7mMMfmrV28FMw=; b=Jd0Mgg+ZT6Y8OPN783wC5xi+OI1H3J++7k9ZDAL06Q0UQirlPDkyhB1KGqCWfWttlsPVxZ zKYudmWG5aIkMsrbm0N7Cj2DGJ9TH1Aon+M6ltxG4csce6FYFf3bFMl8JG5r7wpMcnfRVl hWmnZYeBhWehD8VbhLJqFZiw2a5H3qo= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-105-U1L0J_ShPWCUkCO6Wtav9Q-1; Mon, 08 Jun 2020 12:03:18 -0400 X-MC-Unique: U1L0J_ShPWCUkCO6Wtav9Q-1 Received: by mail-wm1-f70.google.com with SMTP id s15so5963wmc.8 for ; Mon, 08 Jun 2020 09:03:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=J738BQqBvhpMt3eJFPP/lmrii93ELO7mMMfmrV28FMw=; b=oPS36daukOFH+ywisHayweVDwAce5z8ayGreJDTIPCymeGx3KVGSeSNj5Mezoww0Yj Gro1PDNDwr+bsAgeXD4KUdJC7cEylWu/1m7RI4cxSdOKwWjyVdxwBCQ8e8yh6ZE1SJ72 y4fc9/IOPiU2uqjdjViROwtJwi9DKe8McH7gAAH56KyicJ8xjZJXwaghdjzocysvdD38 v7Ml2nKKvEyE51Sg/W9L+MM2/CKNLI+4ZPhqr82H2qDp+jiRMPe9aL0+YgUYqbKOD0pS rrf/FBPc+m8clO+01WNvprLLW5VludVn45AX64zp+9D+KC2AU+YQs9R8/MaNJD8SucfY YnCg== X-Gm-Message-State: AOAM530I9un4QwOzhgJwobVM/0QpiExZXGkxAIqT3W24Kg/4jdbaxrng 9RU/4oqECo1vVVN3oy3bkFy5Vau87K/mLl32Dayrx/UV8RG8/aJsq0P4y5aUokXJD+LAgxQsa+f FFCg8cAj6DQTULAy2FMFB15CKGkk= X-Received: by 2002:a05:600c:4410:: with SMTP id u16mr73255wmn.88.1591632196834; Mon, 08 Jun 2020 09:03:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz3xkvh2Vk+4PYCBSKCv2fZwGK7MNY+4FcnyFPW+oUbVotWO8gdASoKL+nfN+0YxJIIGJ7I2g== X-Received: by 2002:a05:600c:4410:: with SMTP id u16mr73234wmn.88.1591632196640; Mon, 08 Jun 2020 09:03:16 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id l17sm32396wmi.16.2020.06.08.09.03.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:16 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 26/35] hw/openrisc/cputimer: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:35 +0200 Message-Id: <20200608160044.15531-27-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/openrisc/cputimer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/openrisc/cputimer.c b/hw/openrisc/cputimer.c index 93268815d8..60f2c9667f 100644 --- a/hw/openrisc/cputimer.c +++ b/hw/openrisc/cputimer.c @@ -22,6 +22,7 @@ #include "cpu.h" #include "migration/vmstate.h" #include "qemu/timer.h" +#include "hw/qdev-deprecated.h" #define TIMER_PERIOD 50 /* 50 ns period for 20 MHz timer */ @@ -135,6 +136,8 @@ static const VMStateDescription vmstate_or1k_timer = { void cpu_openrisc_clock_init(OpenRISCCPU *cpu) { + qdev_warn_deprecated_function_used(); + cpu->env.timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, &openrisc_timer_cb, cpu); cpu->env.ttmr = 0x00000000; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFJ-0005Zk-4s; Mon, 08 Jun 2020 16:03:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFI-0005Ys-FD for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:32 +0000 X-Inumbo-ID: 96decccc-a9a1-11ea-96fb-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 96decccc-a9a1-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 16:03:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6htctWfi0MuFSG0QMH05N/TPpEubln82RtGM2+VRUkY=; b=Ul0cJiIVNQn4mBpQsqELB939niuIBptRc4P0+yZfe5NLoh/q0RBlkA2CiR4p8tlycIa36L eK/ubT+1YDMyFH43qmUAjkFflYGZYgBsdMVgYgZidAU7Nru+AP/J4bDbvyzgRpCt7BIN+8 6xEwdg9BR38CyY1ws+jzlA/cn3umFnE= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-193-cKOrTLa9NsmBOi00y4g5GQ-1; Mon, 08 Jun 2020 12:03:25 -0400 X-MC-Unique: cKOrTLa9NsmBOi00y4g5GQ-1 Received: by mail-wm1-f71.google.com with SMTP id b63so116042wme.1 for ; Mon, 08 Jun 2020 09:03:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=6htctWfi0MuFSG0QMH05N/TPpEubln82RtGM2+VRUkY=; b=SBMtI8HJJ1ONZxzHkXNweac4Li1fDENMLqmN9T2/jUwPS88A8bpWEiuTY/VcPrxLaT v/nCXWrCTUghZSOW0TprQzT1ZFjj0E8GEaKHYtdM72FRVAcmkOcCUlRDk2iosl+RWVVl j5pf2OZDAek4m1kDeXq54q50gpEC4xgl5nSvJ3O43W6cxNgu/rtv9AbHHo+qmaNo1NG8 CesFTqX7lAAAeiiLKB3ZzM7CqIDBy6DjyilD2/e3LWMoOHOaHUm38creOxusAKr6V8lp ovdmhtlqBEvnvh1CdlkFCG3Vg5/y+5WIa/6PcgLhiHmwgnRgnq1uwMLElOAYc4GFHeXj eyqQ== X-Gm-Message-State: AOAM531untfaIRnooh6G6KWtIpqRQRExbl5qcJzYLYbDcuN2qRQZtchw OCj56RMGgowFnYNEZYI5gKoDfDYG+S3oAXqhDOtt3OhFdCoqjKaZpQRAE+IpG57/DstvCpPGLRN ILef1UZvFnkxryhyXHQd5OAbAGGg= X-Received: by 2002:a5d:5585:: with SMTP id i5mr23967103wrv.112.1591632204338; Mon, 08 Jun 2020 09:03:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPoWRkkwB/FnLCAhEPa5I9PvgN5hBH0wEtPqJP6K6G5xK4bW4Hm9SvYdS2VHkDfOIc4QPeAQ== X-Received: by 2002:a5d:5585:: with SMTP id i5mr23967049wrv.112.1591632204161; Mon, 08 Jun 2020 09:03:24 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id f71sm21622wmf.22.2020.06.08.09.03.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:23 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 27/35] hw/ppc/ppc: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:36 +0200 Message-Id: <20200608160044.15531-28-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/ppc/ppc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c index 4a11fb1640..39fcf746c5 100644 --- a/hw/ppc/ppc.c +++ b/hw/ppc/ppc.c @@ -37,6 +37,7 @@ #include "kvm_ppc.h" #include "migration/vmstate.h" #include "trace.h" +#include "hw/qdev-deprecated.h" //#define PPC_DEBUG_IRQ //#define PPC_DEBUG_TB @@ -1114,6 +1115,8 @@ clk_setup_cb cpu_ppc_tb_init (CPUPPCState *env, uint32_t freq) PowerPCCPU *cpu = env_archcpu(env); ppc_tb_t *tb_env; + qdev_warn_deprecated_function_used(); + tb_env = g_malloc0(sizeof(ppc_tb_t)); env->tb_env = tb_env; tb_env->flags = PPC_DECR_UNDERFLOW_TRIGGERED; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFN-0005ei-FD; Mon, 08 Jun 2020 16:03:37 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFL-0005ck-UF for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:35 +0000 X-Inumbo-ID: 9a4e1aca-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 9a4e1aca-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:03:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632213; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nCf98bap8NX9iIcnvvB/aw+3vfPbNUjO6+kAZbeXlU0=; b=d5KjMTUhcHEiL6BJl+25Mv6e0YIgG9agYY3MiFWXb8+5afPATdd25Tmg/F2UKuCQID6WMn bHLpWoi2Ndr4+loI2CvXgsO+s8Pi7SWuTaxET0zxNB22gO41PSjIarJtMzDACCQfhbBONl Hc4gERqvw7xxkpw/yJxj3RBxlbFP0xU= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-56-IO7TwgdLMz-6SSxBpSkpZg-1; Mon, 08 Jun 2020 12:03:31 -0400 X-MC-Unique: IO7TwgdLMz-6SSxBpSkpZg-1 Received: by mail-wm1-f72.google.com with SMTP id k185so4120wme.8 for ; Mon, 08 Jun 2020 09:03:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=nCf98bap8NX9iIcnvvB/aw+3vfPbNUjO6+kAZbeXlU0=; b=heGqT1u2kmdbE0xorftnZS8vk9Qk2urwARD77ZJhO85873rln3h5n8mkIRDznWC0Fn w2lWcL2fVL5clcxwQ7j0VlYWoVdCq8+cYrVKJTsBaOYTymUasSWD7ccf2A3efNKN+fG/ jV5EQIIX7vt8Z+bcugF5DuPPiocbuvC4b4vUay7b0vZgCbueaRMCwOsG3AhXsHV5tvHm 0aMZInB2xY4RDRuVadtcl+AT6ehDIW0U+4/SceKKcEXB6c6d9OsIylko8V6QzS5OXga3 oRvh/tBZm3SgoNe8+fCsFXIJ7oiOrVaVhWw62na1RHYKEqfw7Ou2S+bcYhyHl07DoK/P R8QA== X-Gm-Message-State: AOAM532pUu/Xv//w6p/aFncUnFMLGvpG5ZmhBn9d7WCKpH8IAl2Rpj3e E28stn4mzIrMBXhgxovwiqULiggcIeEUSi0bdWs4pVx0NqR/mucPEXS/zaV9pRIIm8legHbRJWC OVMrt0dBTe5fgvSfVntp9D33bm/s= X-Received: by 2002:adf:a41a:: with SMTP id d26mr25031326wra.324.1591632210360; Mon, 08 Jun 2020 09:03:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnZLr9C0tJY5bkNMLswKxTqLiEkka8PUdpib6I0kPKfuiid5c8nSc5Z6uKzVsdfUes5d8k3w== X-Received: by 2002:adf:a41a:: with SMTP id d26mr25031279wra.324.1591632210107; Mon, 08 Jun 2020 09:03:30 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id n204sm42276wma.5.2020.06.08.09.03.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:29 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 28/35] hw/ppc/ppc4xx: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:37 +0200 Message-Id: <20200608160044.15531-29-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/ppc/ppc405_boards.c | 5 +++++ hw/ppc/ppc405_uc.c | 21 +++++++++++++++++++++ hw/ppc/ppc4xx_devs.c | 7 +++++++ 3 files changed, 33 insertions(+) diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c index 6198ec1035..eb1216b5f0 100644 --- a/hw/ppc/ppc405_boards.c +++ b/hw/ppc/ppc405_boards.c @@ -41,6 +41,7 @@ #include "hw/loader.h" #include "exec/address-spaces.h" #include "qemu/cutils.h" +#include "hw/qdev-deprecated.h" #define BIOS_FILENAME "ppc405_rom.bin" #define BIOS_SIZE (2 * MiB) @@ -129,6 +130,8 @@ static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base) ref405ep_fpga_t *fpga; MemoryRegion *fpga_memory = g_new(MemoryRegion, 1); + qdev_warn_deprecated_function_used(); + fpga = g_malloc0(sizeof(ref405ep_fpga_t)); memory_region_init_io(fpga_memory, NULL, &ref405ep_fpga_ops, fpga, "fpga", 0x00000100); @@ -408,6 +411,8 @@ static void taihu_cpld_init(MemoryRegion *sysmem, uint32_t base) taihu_cpld_t *cpld; MemoryRegion *cpld_memory = g_new(MemoryRegion, 1); + qdev_warn_deprecated_function_used(); + cpld = g_malloc0(sizeof(taihu_cpld_t)); memory_region_init_io(cpld_memory, NULL, &taihu_cpld_ops, cpld, "cpld", 0x100); memory_region_add_subregion(sysmem, base, cpld_memory); diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c index 381720aced..160604c62e 100644 --- a/hw/ppc/ppc405_uc.c +++ b/hw/ppc/ppc405_uc.c @@ -36,6 +36,7 @@ #include "sysemu/sysemu.h" #include "qemu/log.h" #include "exec/address-spaces.h" +#include "hw/qdev-deprecated.h" //#define DEBUG_OPBA //#define DEBUG_SDRAM @@ -182,6 +183,8 @@ void ppc4xx_plb_init(CPUPPCState *env) { ppc4xx_plb_t *plb; + qdev_warn_deprecated_function_used(); + plb = g_malloc0(sizeof(ppc4xx_plb_t)); ppc_dcr_register(env, PLB3A0_ACR, plb, &dcr_read_plb, &dcr_write_plb); ppc_dcr_register(env, PLB4A0_ACR, plb, &dcr_read_plb, &dcr_write_plb); @@ -267,6 +270,8 @@ static void ppc4xx_pob_init(CPUPPCState *env) { ppc4xx_pob_t *pob; + qdev_warn_deprecated_function_used(); + pob = g_malloc0(sizeof(ppc4xx_pob_t)); ppc_dcr_register(env, POB0_BEAR, pob, &dcr_read_pob, &dcr_write_pob); ppc_dcr_register(env, POB0_BESR0, pob, &dcr_read_pob, &dcr_write_pob); @@ -351,6 +356,8 @@ static void ppc4xx_opba_init(hwaddr base) { ppc4xx_opba_t *opba; + qdev_warn_deprecated_function_used(); + opba = g_malloc0(sizeof(ppc4xx_opba_t)); #ifdef DEBUG_OPBA printf("%s: offset " TARGET_FMT_plx "\n", __func__, base); @@ -549,6 +556,8 @@ void ppc405_ebc_init(CPUPPCState *env) { ppc4xx_ebc_t *ebc; + qdev_warn_deprecated_function_used(); + ebc = g_malloc0(sizeof(ppc4xx_ebc_t)); qemu_register_reset(&ebc_reset, ebc); ppc_dcr_register(env, EBC0_CFGADDR, @@ -632,6 +641,8 @@ static void ppc405_dma_init(CPUPPCState *env, qemu_irq irqs[4]) { ppc405_dma_t *dma; + qdev_warn_deprecated_function_used(); + dma = g_malloc0(sizeof(ppc405_dma_t)); memcpy(dma->irqs, irqs, 4 * sizeof(qemu_irq)); qemu_register_reset(&ppc405_dma_reset, dma); @@ -735,6 +746,8 @@ static void ppc405_gpio_init(hwaddr base) { ppc405_gpio_t *gpio; + qdev_warn_deprecated_function_used(); + gpio = g_malloc0(sizeof(ppc405_gpio_t)); #ifdef DEBUG_GPIO printf("%s: offset " TARGET_FMT_plx "\n", __func__, base); @@ -897,6 +910,8 @@ static void ppc405_ocm_init(CPUPPCState *env) { ppc405_ocm_t *ocm; + qdev_warn_deprecated_function_used(); + ocm = g_malloc0(sizeof(ppc405_ocm_t)); /* XXX: Size is 4096 or 0x04000000 */ memory_region_init_ram(&ocm->isarc_ram, NULL, "ppc405.ocm", 4 * KiB, @@ -1142,6 +1157,8 @@ static void ppc4xx_gpt_init(hwaddr base, qemu_irq irqs[5]) ppc4xx_gpt_t *gpt; int i; + qdev_warn_deprecated_function_used(); + gpt = g_malloc0(sizeof(ppc4xx_gpt_t)); for (i = 0; i < 5; i++) { gpt->irqs[i] = irqs[i]; @@ -1410,6 +1427,8 @@ static void ppc405cr_cpc_init (CPUPPCState *env, clk_setup_t clk_setup[7], { ppc405cr_cpc_t *cpc; + qdev_warn_deprecated_function_used(); + cpc = g_malloc0(sizeof(ppc405cr_cpc_t)); memcpy(cpc->clk_setup, clk_setup, PPC405CR_CLK_NB * sizeof(clk_setup_t)); @@ -1755,6 +1774,8 @@ static void ppc405ep_cpc_init (CPUPPCState *env, clk_setup_t clk_setup[8], { ppc405ep_cpc_t *cpc; + qdev_warn_deprecated_function_used(); + cpc = g_malloc0(sizeof(ppc405ep_cpc_t)); memcpy(cpc->clk_setup, clk_setup, PPC405EP_CLK_NB * sizeof(clk_setup_t)); diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c index f1651e04d9..b09d7ab5c6 100644 --- a/hw/ppc/ppc4xx_devs.c +++ b/hw/ppc/ppc4xx_devs.c @@ -33,6 +33,7 @@ #include "qemu/log.h" #include "exec/address-spaces.h" #include "qemu/error-report.h" +#include "hw/qdev-deprecated.h" /*#define DEBUG_UIC*/ @@ -303,6 +304,8 @@ qemu_irq *ppcuic_init (CPUPPCState *env, qemu_irq *irqs, ppcuic_t *uic; int i; + qdev_warn_deprecated_function_used(); + uic = g_malloc0(sizeof(ppcuic_t)); uic->dcr_base = dcr_base; uic->irqs = irqs; @@ -647,6 +650,8 @@ void ppc4xx_sdram_init (CPUPPCState *env, qemu_irq irq, int nbanks, { ppc4xx_sdram_t *sdram; + qdev_warn_deprecated_function_used(); + sdram = g_malloc0(sizeof(ppc4xx_sdram_t)); sdram->irq = irq; sdram->nbanks = nbanks; @@ -908,6 +913,8 @@ void ppc4xx_mal_init(CPUPPCState *env, uint8_t txcnum, uint8_t rxcnum, ppc4xx_mal_t *mal; int i; + qdev_warn_deprecated_function_used(); + assert(txcnum <= 32 && rxcnum <= 32); mal = g_malloc0(sizeof(*mal)); mal->txcnum = txcnum; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFT-0005m6-Qk; Mon, 08 Jun 2020 16:03:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFS-0005kP-Ez for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:42 +0000 X-Inumbo-ID: 9e35e168-a9a1-11ea-ba62-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 9e35e168-a9a1-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 16:03:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632219; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tavsnBMcjbLYqmKTQpJNbu5aW+OtaIuHgP5ZHfhD4y8=; b=V17EZvJ3O7UxkcIA4fwzWYf9sJDK7VD+RfGPMVHLoZ8FSRb3hk03dw3fsGSn43W/OTRdBP ZiiwA8GsXkDXvBMMotZyBfsmui2P8OvpQpGWow4BZiEvIKq0GDMocZU1V6mPlUnEDx6iNS hvt9SekaXRxiQx0KOT9IH53HK1wYCVo= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-338-PlDlpjQIPDGie0lUBoo4gw-1; Mon, 08 Jun 2020 12:03:38 -0400 X-MC-Unique: PlDlpjQIPDGie0lUBoo4gw-1 Received: by mail-wr1-f71.google.com with SMTP id p9so7363845wrx.10 for ; Mon, 08 Jun 2020 09:03:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=tavsnBMcjbLYqmKTQpJNbu5aW+OtaIuHgP5ZHfhD4y8=; b=Jy4Kk8CgNC7mimeVHr/brQUZCAMimXSh1bGYOjBPPsbrT4CpJsyWV4CRB2NPw/L/Jv 0rBb5sVnwWOBEgWoA5W3rTN2oR5C/MhWLsyz/9vTM3px3/RvmTIxpzNzGGNvPzqY/GnH V1hkq7TKLaV7xMMag7YnE9Ij15NR2Gp6ehpdir3UsQhEF4bZyOHbQ3COfjMFjmqyKnGR rm/4l11x9I22IeDJoE0GeF21aQdMVzGyt1z1CtDoYUYRBcV390TQGDWBJz3Wg4ov21KM cFEdonXAhNyjVyDBLcw9Hfkzevz3N2AsJuLUftYgjy6xODchtjlJ7OrJagvR8/JlpxuM A5yA== X-Gm-Message-State: AOAM533tfE4QckauYIjng4q6ibINxet6VNyO820NbOEUeaSU3ougkVWL /8g0ZlgKsBTIcjYMT1+2MOVQPVaIiAfwd6ZwepHX5F5P2pRAgCR8qUCeEpeYO2oK0mupabfoSnu nVZibqDL7/vwQWAUspQBaVPWBNJs= X-Received: by 2002:a7b:cd04:: with SMTP id f4mr73319wmj.118.1591632216884; Mon, 08 Jun 2020 09:03:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy1E2OUT8wjgYne61y8m5ATBeXEAgbFH/vhvj6PwSHzmhBdaDf8vJ9I14Vkb0SP4ZL7hYVwYg== X-Received: by 2002:a7b:cd04:: with SMTP id f4mr73214wmj.118.1591632215737; Mon, 08 Jun 2020 09:03:35 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id l17sm200565wrq.17.2020.06.08.09.03.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:35 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 29/35] hw/ppc/ppc_booke: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:38 +0200 Message-Id: <20200608160044.15531-30-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/ppc/ppc_booke.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/ppc/ppc_booke.c b/hw/ppc/ppc_booke.c index 652a21b806..a9e5e68578 100644 --- a/hw/ppc/ppc_booke.c +++ b/hw/ppc/ppc_booke.c @@ -31,7 +31,7 @@ #include "qemu/log.h" #include "hw/loader.h" #include "kvm_ppc.h" - +#include "hw/qdev-deprecated.h" /* Timer Control Register */ @@ -338,6 +338,8 @@ void ppc_booke_timers_init(PowerPCCPU *cpu, uint32_t freq, uint32_t flags) booke_timer_t *booke_timer; int ret = 0; + qdev_warn_deprecated_function_used(); + tb_env = g_malloc0(sizeof(ppc_tb_t)); booke_timer = g_malloc0(sizeof(booke_timer_t)); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFb-0005uj-CV; Mon, 08 Jun 2020 16:03:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFa-0005tu-IH for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:50 +0000 X-Inumbo-ID: a4570be4-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id a4570be4-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:03:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632229; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+WkHvAzEi0wEkdKvuBuPydWDbkpdF7QxEn1l5oochA0=; b=N4p54fYmCXOpchXnz0ZN1/cwQxg11GtBAtIichPgSaIhepD7fvyuocQ5BEW9A2xBn5qmnR u7q//ZSbVc+0ypI6BlemWubZPd0cg/5D4tktzbM56JpIkJOk3OsNyHV83GqzjL/DjY5Xg/ 9mL5CyiLuPSSk5uZqwujWShVip99JAg= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-29-gHiAprgVOM-9B2uXODz0Lw-1; Mon, 08 Jun 2020 12:03:48 -0400 X-MC-Unique: gHiAprgVOM-9B2uXODz0Lw-1 Received: by mail-wm1-f69.google.com with SMTP id a7so12838wmf.1 for ; Mon, 08 Jun 2020 09:03:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=+WkHvAzEi0wEkdKvuBuPydWDbkpdF7QxEn1l5oochA0=; b=oax5GYL2o9ro/6xAlqGmureExpmqS8MZdSKqExdiPMX+w0L5KvproJJ3Usk0PZgKVc /+fVt5D/DO6Kcet6caDZmieQiA5VK7fGG2yh+ceeP64uUhXR2wvpqkeMmKER1qjMTbSx J0xO/A8zbiAY1nf4t7IOhMfQyPOBmQGxuB0VQFEa7qaWCIb0DAk95ELMlhMTFveo8VI6 gGG953PSz3418aTcWwKmCzkcpjLwIMoVlPQK6Mt/yV82qYc/ZA4ywd0DVDX4wEc1nZRK 9DFsDt/qywC5Op0BlEIa5sejV3eu3o78GmcBLoxmpO/ml+0Jsoqiya7Px261mYRJp0v/ 81cw== X-Gm-Message-State: AOAM530QZLCVh83Iy/2SE05Ykv1w3lhMEZ8dSXFJDlX0FO968GffdLpx eZuL5z50C6H9uLMhO7HrIekGpcjsBcvVi6dTFkxnYN+zis1Aiq+nbRarx0ZxcsTJ29vdgwPE7Me 0LE5/83FqXbslTCgvK2NpYN8rnHE= X-Received: by 2002:a5d:49c5:: with SMTP id t5mr24893755wrs.18.1591632227121; Mon, 08 Jun 2020 09:03:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzrpgU9KBovh6Bb8PslmNvBRv90nOw1Va1g7BnyPuxlNkUnSsxx5Z+mEp10XtU+59c/IEfXNQ== X-Received: by 2002:a5d:49c5:: with SMTP id t5mr24893708wrs.18.1591632226912; Mon, 08 Jun 2020 09:03:46 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id s8sm181183wrg.50.2020.06.08.09.03.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:46 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 31/35] hw/sh4: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:40 +0200 Message-Id: <20200608160044.15531-32-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/char/sh_serial.c | 3 +++ hw/intc/sh_intc.c | 3 +++ hw/sh4/r2d.c | 3 +++ hw/sh4/sh7750.c | 4 ++++ hw/timer/sh_timer.c | 5 +++++ 5 files changed, 18 insertions(+) diff --git a/hw/char/sh_serial.c b/hw/char/sh_serial.c index 167f4d8cb9..9366a23dd2 100644 --- a/hw/char/sh_serial.c +++ b/hw/char/sh_serial.c @@ -31,6 +31,7 @@ #include "chardev/char-fe.h" #include "qapi/error.h" #include "qemu/timer.h" +#include "hw/qdev-deprecated.h" //#define DEBUG_SERIAL @@ -382,6 +383,8 @@ void sh_serial_init(MemoryRegion *sysmem, { sh_serial_state *s; + qdev_warn_deprecated_function_used(); + s = g_malloc0(sizeof(sh_serial_state)); s->feat = feat; diff --git a/hw/intc/sh_intc.c b/hw/intc/sh_intc.c index 72a55e32dd..c90fbf47bb 100644 --- a/hw/intc/sh_intc.c +++ b/hw/intc/sh_intc.c @@ -13,6 +13,7 @@ #include "hw/sh4/sh_intc.h" #include "hw/irq.h" #include "hw/sh4/sh.h" +#include "hw/qdev-deprecated.h" //#define DEBUG_INTC //#define DEBUG_INTC_SOURCES @@ -444,6 +445,8 @@ int sh_intc_init(MemoryRegion *sysmem, { unsigned int i, j; + qdev_warn_deprecated_function_used(); + desc->pending = 0; desc->nr_sources = nr_sources; desc->mask_regs = mask_regs; diff --git a/hw/sh4/r2d.c b/hw/sh4/r2d.c index 72bb5285cc..22bbbe7d3c 100644 --- a/hw/sh4/r2d.c +++ b/hw/sh4/r2d.c @@ -43,6 +43,7 @@ #include "hw/usb.h" #include "hw/block/flash.h" #include "exec/address-spaces.h" +#include "hw/qdev-deprecated.h" #define FLASH_BASE 0x00000000 #define FLASH_SIZE (16 * MiB) @@ -187,6 +188,8 @@ static qemu_irq *r2d_fpga_init(MemoryRegion *sysmem, { r2d_fpga_t *s; + qdev_warn_deprecated_function_used(); + s = g_malloc0(sizeof(r2d_fpga_t)); s->irl = irl; diff --git a/hw/sh4/sh7750.c b/hw/sh4/sh7750.c index d660714443..379822e0c2 100644 --- a/hw/sh4/sh7750.c +++ b/hw/sh4/sh7750.c @@ -32,6 +32,7 @@ #include "hw/sh4/sh_intc.h" #include "cpu.h" #include "exec/exec-all.h" +#include "hw/qdev-deprecated.h" #define NB_DEVICES 4 @@ -756,6 +757,8 @@ SH7750State *sh7750_init(SuperHCPU *cpu, MemoryRegion *sysmem) { SH7750State *s; + qdev_warn_deprecated_function_used(); + s = g_malloc0(sizeof(SH7750State)); s->cpu = cpu; s->periph_freq = 60000000; /* 60MHz */ @@ -866,6 +869,7 @@ SH7750State *sh7750_init(SuperHCPU *cpu, MemoryRegion *sysmem) qemu_irq sh7750_irl(SH7750State *s) { + qdev_warn_deprecated_function_used(); sh_intc_toggle_source(sh_intc_source(&s->intc, IRL), 1, 0); /* enable */ return qemu_allocate_irq(sh_intc_set_irl, sh_intc_source(&s->intc, IRL), 0); } diff --git a/hw/timer/sh_timer.c b/hw/timer/sh_timer.c index 13c4051808..d5e33507b0 100644 --- a/hw/timer/sh_timer.c +++ b/hw/timer/sh_timer.c @@ -14,6 +14,7 @@ #include "hw/sh4/sh.h" #include "qemu/timer.h" #include "hw/ptimer.h" +#include "hw/qdev-deprecated.h" //#define DEBUG_TIMER @@ -199,6 +200,8 @@ static void *sh_timer_init(uint32_t freq, int feat, qemu_irq irq) { sh_timer_state *s; + qdev_warn_deprecated_function_used(); + s = (sh_timer_state *)g_malloc0(sizeof(sh_timer_state)); s->freq = freq; s->feat = feat; @@ -319,6 +322,8 @@ void tmu012_init(MemoryRegion *sysmem, hwaddr base, tmu012_state *s; int timer_feat = (feat & TMU012_FEAT_EXTCLK) ? TIMER_FEAT_EXTCLK : 0; + qdev_warn_deprecated_function_used(); + s = (tmu012_state *)g_malloc0(sizeof(tmu012_state)); s->feat = feat; s->timer[0] = sh_timer_init(freq, timer_feat, ch0_irq); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFd-0005xS-Ns; Mon, 08 Jun 2020 16:03:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFc-0005vx-F5 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:52 +0000 X-Inumbo-ID: a2574c78-a9a1-11ea-96fb-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id a2574c78-a9a1-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 16:03:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632226; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7kyMhVQ9HQhJiyo6QGAHK03lmBlbuIzucxY+SHtzpks=; b=gOYOLjUa3SErlNwXKlU2eDT1PAPgwl56xFbNvTRv1I+orIWRKljvuZIHlyKYUO3X8I+VnW ZH9iIDPjakh67DKxqGNUmOotSSVu2eamUItw4Apf3m72m65Vc7w3Eq2e63AJOejSWJQH8z a4rRuj2/dpj4UfSpz/DQndVeQ3ze48g= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-512-VnuTzJqdMgCI7cGKIB3R5A-1; Mon, 08 Jun 2020 12:03:42 -0400 X-MC-Unique: VnuTzJqdMgCI7cGKIB3R5A-1 Received: by mail-wm1-f71.google.com with SMTP id r1so7252wmh.7 for ; Mon, 08 Jun 2020 09:03:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7kyMhVQ9HQhJiyo6QGAHK03lmBlbuIzucxY+SHtzpks=; b=TkTYh/ov6JLnFrIv4kKTxAjg55WgTvOZR3/o6hBG36P8kT2BrskRYvt14WS3MSdDrO hPGHeXl4X0RSatxDFoax63UvBBhkk2Kw+yHf3dAagWwOI3o3uwj3pdg9L/E981hbnKsC XpAV9uT7UYlQyYrW3Mf8E2zQ1yrCgRVSLDLCiGhcs9f5yj3XnsmMl5sRDONx27YFn4hi cvtEN8R11Lwbzou00/9C61frIUXezVTanV+AN6SWZ+9aHjG6SCmigToG2oNXOlXVdqkI SyHpGk1hNqOPwICsS1z/L0URVXptXZnK2vt04ACjZqVi9ZD0mEIL/SKQere3kD0hQOCh 1I1Q== X-Gm-Message-State: AOAM530ezekEqph+KK957aLtZwbznHL8VNsvBvYdwP7LqzU0y+cRzAsj FD0918qH51tFHGpgqJlaWX97pQsV23S/8EU/yxZIPQS1UHwUaQ6ASMdZ+/YKyhaeAJxkoc4FBeM WpHm4uwcZ9MISeGQFZnqt5NxEQjE= X-Received: by 2002:a5d:6087:: with SMTP id w7mr26621418wrt.158.1591632221506; Mon, 08 Jun 2020 09:03:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyEzYn7IfaprZ27/xV2VCZHXx76WBbSnolmOS6yBDnvZe3b82K5DvPVvnhVs7yLdMTrFxNPeQ== X-Received: by 2002:a5d:6087:: with SMTP id w7mr26621373wrt.158.1591632221329; Mon, 08 Jun 2020 09:03:41 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id o82sm8088wmo.40.2020.06.08.09.03.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:40 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 30/35] hw/ppc/virtex_ml507: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:39 +0200 Message-Id: <20200608160044.15531-31-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/ppc/virtex_ml507.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.c index 0dacfcd236..17b8036c38 100644 --- a/hw/ppc/virtex_ml507.c +++ b/hw/ppc/virtex_ml507.c @@ -40,7 +40,7 @@ #include "qemu/log.h" #include "qemu/option.h" #include "exec/address-spaces.h" - +#include "hw/qdev-deprecated.h" #include "hw/ppc/ppc.h" #include "hw/ppc/ppc4xx.h" #include "hw/qdev-properties.h" @@ -95,6 +95,8 @@ static PowerPCCPU *ppc440_init_xilinx(const char *cpu_type, uint32_t sysclk) CPUPPCState *env; qemu_irq *irqs; + qdev_warn_deprecated_function_used(); + cpu = POWERPC_CPU(cpu_create(cpu_type)); env = &cpu->env; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:03:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:03:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFi-00062l-1o; Mon, 08 Jun 2020 16:03:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFg-00060k-AE for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:03:56 +0000 X-Inumbo-ID: a7c53adb-a9a1-11ea-b292-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id a7c53adb-a9a1-11ea-b292-12813bfff9fa; Mon, 08 Jun 2020 16:03:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632235; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qfeQjgHHg6Ez9waCGJmOrJzAr/zUBGXbuFUiyuF/Rfo=; b=i0gWMupYQnQaFUEqTKaVJBfEe2HNXu7+J/baMmXCmjt4r32d3aYvlLPLRjroSb/5hxImAc uC3PbyJL9Znc/AfU8nlK8C59RGAgTKM1qMcX+L4K9FxhXkQhXrh66avYo1etStY+pgnPup Oq+k1H8cr0en46mXrLNzlbEfZfcry30= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-177-fkrCQdsqMBKNuS5RKU1dOA-1; Mon, 08 Jun 2020 12:03:54 -0400 X-MC-Unique: fkrCQdsqMBKNuS5RKU1dOA-1 Received: by mail-wr1-f70.google.com with SMTP id o1so7301067wrm.17 for ; Mon, 08 Jun 2020 09:03:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=qfeQjgHHg6Ez9waCGJmOrJzAr/zUBGXbuFUiyuF/Rfo=; b=rWixmA5Q8jXZw28KKwt/9OhtlIq9ugTF60XXRG7wSYDZ1vLWtRiSmTvVbcQBxBlxAZ G9aobf6c+tEjBcYVl80sbW6l1PvE5+PbxQge7+aQ1xTIJ4yBNQrsBxdSKLtjTWELXZJp PbrW/PaLPK+WuLcy9Hr/Fm6Li2ubxhjg1ASA1V+gK9Sat2Xb3rVcc0dlmRs3ty8y2sQF DT6PIFvJmdTBkTeB6eyERNM+JYcsLKVmP8u7ePr3hZdfddcFcYJ6C68hILgn+WqueTel 6DWmjyRojgVjCXalDrefm53MFOPWr2KkWRmCF/XldPmLSKOKPzsFnPkmPuWqLj1j26Ia g7RA== X-Gm-Message-State: AOAM533HrBHZO/Jw4mXWXWC3OtUIxIAGS1dC+zASiB0xFik6A9iE7Uu4 hiEdLzlv7UaM8rss6mZs/1p6FGwifUepbRvn881GdseL3L1KHtfYOCFpHKuYJaI/ufv355RfH/z D50ypoDmTORQ4IeHb0tnMef0i8Iw= X-Received: by 2002:a7b:cd04:: with SMTP id f4mr54308wmj.3.1591632232863; Mon, 08 Jun 2020 09:03:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLcq9fw++IqBSfctMa2VnenePzSclzDPUX9srn5OE/PiQtrx427TCsmbU35rGSbrlanE52/A== X-Received: by 2002:a7b:cd04:: with SMTP id f4mr54282wmj.3.1591632232663; Mon, 08 Jun 2020 09:03:52 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id q4sm4466wma.47.2020.06.08.09.03.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:52 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 32/35] hw/riscv: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:41 +0200 Message-Id: <20200608160044.15531-33-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/riscv/riscv_htif.c | 4 ++++ hw/riscv/sifive_uart.c | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/hw/riscv/riscv_htif.c b/hw/riscv/riscv_htif.c index ca87a5cf9f..bd080dbefb 100644 --- a/hw/riscv/riscv_htif.c +++ b/hw/riscv/riscv_htif.c @@ -30,6 +30,7 @@ #include "hw/riscv/riscv_htif.h" #include "qemu/timer.h" #include "qemu/error-report.h" +#include "hw/qdev-deprecated.h" #define RISCV_DEBUG_HTIF 0 #define HTIF_DEBUG(fmt, ...) \ @@ -238,6 +239,9 @@ HTIFState *htif_mm_init(MemoryRegion *address_space, MemoryRegion *main_mem, uint64_t fromhost_offset = fromhost_addr - base; HTIFState *s = g_malloc0(sizeof(HTIFState)); + + qdev_warn_deprecated_function_used(); + s->address_space = address_space; s->main_mem = main_mem; s->main_mem_ram_ptr = memory_region_get_ram_ptr(main_mem); diff --git a/hw/riscv/sifive_uart.c b/hw/riscv/sifive_uart.c index 9350482662..1a5890d5f7 100644 --- a/hw/riscv/sifive_uart.c +++ b/hw/riscv/sifive_uart.c @@ -25,6 +25,7 @@ #include "hw/hw.h" #include "hw/irq.h" #include "hw/riscv/sifive_uart.h" +#include "hw/qdev-deprecated.h" /* * Not yet implemented: @@ -183,6 +184,9 @@ SiFiveUARTState *sifive_uart_create(MemoryRegion *address_space, hwaddr base, Chardev *chr, qemu_irq irq) { SiFiveUARTState *s = g_malloc0(sizeof(SiFiveUARTState)); + + qdev_warn_deprecated_function_used(); + s->irq = irq; qemu_chr_fe_init(&s->chr, chr, &error_abort); qemu_chr_fe_set_handlers(&s->chr, uart_can_rx, uart_rx, uart_event, -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:04:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:04:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFn-00069T-FN; Mon, 08 Jun 2020 16:04:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKFm-00068G-Ev for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:04:02 +0000 X-Inumbo-ID: ab6aabf2-a9a1-11ea-9b55-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id ab6aabf2-a9a1-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 16:04:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632241; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sNDlXKA4V05uqH+zGvitoUZAatp4aCkSuEKALsyTQs8=; b=HeNN6HG5dljzfXf/kdzP3t/U03v9VOeBlblCjxWuB5446GIloDHATjcejtpXQCBF+bDw0T QUMxrCUiGI9Rz4E90V5KsdXtIc4cB8ABIOwpfG1LU/lTjMgMUGn6AsGGwL1KwkgddeEyc/ gsdBDli7PxrmFElX/F0nAsxDF26plaw= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-58-ofcue9yWOEm4LAYDKBOMtg-1; Mon, 08 Jun 2020 12:04:00 -0400 X-MC-Unique: ofcue9yWOEm4LAYDKBOMtg-1 Received: by mail-wm1-f72.google.com with SMTP id b65so9756wmb.5 for ; Mon, 08 Jun 2020 09:03:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=sNDlXKA4V05uqH+zGvitoUZAatp4aCkSuEKALsyTQs8=; b=jT+FjKSGh+q5szLO8epm+D38uY8F5oDJfCyjdLd9nT5Rkh1vNKSQdAZj5UZOieIQkf 4L27qTrkZwTM0GaoKydz3uflvhqNUNzJPfbjHOP+OWecO4AaQlbT3wMMIY1AC66XAznB D+jzNTz5ZAHTK35rPVbaMALLE0JsfbOdWIYpseIapCOzFptk3VAVM4A9WWFjHxWYHI41 eZdWyHcqgEfZXANPWwtxPVRXwvhGSjKSNWAAa5Ypep1cTUFer1iDPFOe8kmN3pEa3T2x e4sC/HgoA4y4/xDLJzeQlkbzvmEoLaqLJ6UnxKh5NYq/9bUgDgFIdxNYN4NcT39Lwpj6 FovQ== X-Gm-Message-State: AOAM532ytmqRfe8xM+pGMfdaKBQsRIhIdq3AUjL9Ng/bt3eVMjPY4kWG o3PtGJixp+w/g9VR+zBtcoDLyKYCMLdcG/tnk/iY5wQnos41YP2ns3yGLMgIQcLbuPqnHgYpnhj nrQZYdRQmo8P+K4Yrb7NpKc4JABk= X-Received: by 2002:a1c:2082:: with SMTP id g124mr55782wmg.21.1591632239007; Mon, 08 Jun 2020 09:03:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz6Ea3200SCtYHheH/UK2Mas0Wr6/SnNtzGrclQZuKXFOcXxL+qpSERI07OhtEH9rZ1aPQhvQ== X-Received: by 2002:a1c:2082:: with SMTP id g124mr55753wmg.21.1591632238819; Mon, 08 Jun 2020 09:03:58 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id h188sm48452wmh.2.2020.06.08.09.03.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:03:58 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 33/35] hw/timer/slavio_timer: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:42 +0200 Message-Id: <20200608160044.15531-34-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/timer/slavio_timer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c index 4c5d65e391..16f21669bf 100644 --- a/hw/timer/slavio_timer.c +++ b/hw/timer/slavio_timer.c @@ -31,6 +31,7 @@ #include "migration/vmstate.h" #include "trace.h" #include "qemu/module.h" +#include "hw/qdev-deprecated.h" /* * Registers of hardware timer in sun4m. @@ -392,6 +393,8 @@ static void slavio_timer_init(Object *obj) unsigned int i; TimerContext *tc; + qdev_warn_deprecated_function_used(); + for (i = 0; i <= MAX_CPUS; i++) { uint64_t size; char timer_name[20]; -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:04:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:04:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKG2-0006OM-RG; Mon, 08 Jun 2020 16:04:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKG1-0006N7-Ff for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:04:17 +0000 X-Inumbo-ID: afc96422-a9a1-11ea-9ad7-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id afc96422-a9a1-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 16:04:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632249; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1YHmjQuhKrVQhVboVAQhCqKWsJQjJvIRsihRuyQB5QA=; b=GufdAzPjl1+jPDg2Qwwmi6ZqFArTju1VskpGgEdBn/cxabWv3adMouQoBGyzqm8c0MFdX2 8IxPJ1zDSYzhYYb/rVsY6wSLh84tCe253izJ6F7LT0bRstmuZKvctLqO8YcCtC/a6BSC6e D2/5uJHM/JCltZKdeJe18EczXbwphYI= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-410-TaZy7WysNWChcoZ0LPW4-Q-1; Mon, 08 Jun 2020 12:04:07 -0400 X-MC-Unique: TaZy7WysNWChcoZ0LPW4-Q-1 Received: by mail-wr1-f69.google.com with SMTP id n6so7364740wrv.6 for ; Mon, 08 Jun 2020 09:04:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1YHmjQuhKrVQhVboVAQhCqKWsJQjJvIRsihRuyQB5QA=; b=ubjnkskv65DHGsfSxAS9wIcVT+u/4wWeCihqkfKpR8JbJinOa4Qzp/GXoBEa622sVP bCHqcWkNXIQzXTBhTmo5RRjdXLlvlzREx8dK2HDBG5c+xzECMFf+Et0ilfUUGKNt1sCf FbCN7NoSyfuJ9BwRLlmzZHC25B4JEyLsaj6Ge1m8bAjYesf4JM5zWIZra4+r/nrEBHLp TmLba4xEgHVVoWeNpNROpR1KECHHrjSm1beRUhH0B+HNETiGDMP2vsn3KBYqZZIhU7w0 sH4vWkdC5zeP+3xjJs9wIT6OhE3Ysa1Spfi0ygcbRnxrZerGUAiX39CMWIqXRgExPlxO Nqvg== X-Gm-Message-State: AOAM531s2dTQRLQ2i9f+MALEnPH5LCtonJgz8LHJYIZdhv2loSyiduwc Rox2k2Up7hG+COdqOIMs+XGktYO336V/NZO4P/XoMarbNtSFTNZmmhnBj7DCGSJ/xbBiKl9nwhw rwf4rZ1Opqb+hIfNmd7AxROAIF8Y= X-Received: by 2002:adf:e68a:: with SMTP id r10mr23902487wrm.384.1591632244555; Mon, 08 Jun 2020 09:04:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyU7/QCokRt2M0EtovQUdkQHNPZYj9jN1RqUTvUD0f6M2vtgvgHtmb2W1P0W/noN9Fx2nTHYQ== X-Received: by 2002:adf:e68a:: with SMTP id r10mr23902460wrm.384.1591632244335; Mon, 08 Jun 2020 09:04:04 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id k17sm177411wrl.54.2020.06.08.09.04.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:04:03 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 34/35] hw/usb/hcd-musb: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:43 +0200 Message-Id: <20200608160044.15531-35-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/usb/hcd-musb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/usb/hcd-musb.c b/hw/usb/hcd-musb.c index c29fbef6fc..9b3cf1ca8f 100644 --- a/hw/usb/hcd-musb.c +++ b/hw/usb/hcd-musb.c @@ -25,6 +25,7 @@ #include "hw/usb.h" #include "hw/irq.h" #include "hw/hw.h" +#include "hw/qdev-deprecated.h" /* Common USB registers */ #define MUSB_HDRC_FADDR 0x00 /* 8-bit */ @@ -377,6 +378,8 @@ struct MUSBState *musb_init(DeviceState *parent_device, int gpio_base) MUSBState *s = g_malloc0(sizeof(*s)); int i; + qdev_warn_deprecated_function_used(); + for (i = 0; i < musb_irq_max; i++) { s->irqs[i] = qdev_get_gpio_in(parent_device, gpio_base + i); } -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:04:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:04:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKGD-0006Yh-8m; Mon, 08 Jun 2020 16:04:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKGB-0006XS-Gq for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:04:27 +0000 X-Inumbo-ID: b225dce6-a9a1-11ea-9ad7-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id b225dce6-a9a1-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 16:04:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591632253; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6eEd/TZ2fHyvBWvIJ4C8+kCwxjhDxL4elOTIEe035mA=; b=hHuCqph27roUMrw8KtTy81Vhjqjimm2gQFdWrtk41rDRuw/AAQL/FGDN+E/vILI+7D7M9l Cf6aI1OpL2Myp5c83nUbd8VUPB9/U+RLB+YwkHjMkYWYG1e2/Ir/E7225JnSAgqNU3nr+Q OzbpBlhXHBMN4jbDT6y74tv+0IPLcZc= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-6-qzWtedKVO1eW0Ed_00J5cg-1; Mon, 08 Jun 2020 12:04:11 -0400 X-MC-Unique: qzWtedKVO1eW0Ed_00J5cg-1 Received: by mail-wr1-f72.google.com with SMTP id s17so7307327wrt.7 for ; Mon, 08 Jun 2020 09:04:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=6eEd/TZ2fHyvBWvIJ4C8+kCwxjhDxL4elOTIEe035mA=; b=gOsNnegEhpTrAEqpo9b+wFaqfwW2py9DSIesFlJ0GUxW9MSZmJ2otxrXiI5ggoQ99D njyzLfJxhiuM8DqvQ0hxDf0QGAO8xc/1msMKoEDuakWzYSIWztMTixkZnd5Po5SF7EXA PMCGW6Wo2yPTbHMZj7/tkTecFGTNrwt2Er1j5P1mBDJDqt2SysuDv4xKZI2194eTyS7K UUqKUnSAPI9OFsCRJXel/ZlOI9+0AoYRawkjuRGQVgWZTthWoGhLLrvjg8PNzosiSw0C 0fcaB5lTr6ByoCh1iDNSq0udZ3V49odal6gr0CEISOTN+RArWcTuKcwPhz9uOf8GJUSt NsHA== X-Gm-Message-State: AOAM533J5y2qHCguCUcRydEQINkrFOorTMuZ3HdcLOhCuTOPjvF08u76 aMX1nm85ua/4dzi897HliYbPFVTuFSHBzYg4DyLud5+j++dPgVx23X+poMytK+WpstqY//bEiLl WBtd4UW9x/+x70gVM31yYI3/3Vfk= X-Received: by 2002:a1c:bb05:: with SMTP id l5mr29005wmf.141.1591632250058; Mon, 08 Jun 2020 09:04:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwleTjEs6m/0F9WTXFTKcyesoS9BhM/fhVRhaP0ZaaZMgPHfTC+huUmGRS6bDSqa1xeeej4Q== X-Received: by 2002:a1c:bb05:: with SMTP id l5mr28952wmf.141.1591632249790; Mon, 08 Jun 2020 09:04:09 -0700 (PDT) Received: from localhost.localdomain (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id j16sm243025wre.21.2020.06.08.09.04.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 09:04:09 -0700 (PDT) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [RFC PATCH 35/35] hw/xtensa/xtfpga: Emit warning when old code is used Date: Mon, 8 Jun 2020 18:00:44 +0200 Message-Id: <20200608160044.15531-36-philmd@redhat.com> X-Mailer: git-send-email 2.21.3 In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8; text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This code hasn't been QOM'ified yet. Warn the user. Signed-off-by: Philippe Mathieu-Daudé --- hw/xtensa/xtfpga.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/xtensa/xtfpga.c b/hw/xtensa/xtfpga.c index 60ccc74f5f..a3c82dc81a 100644 --- a/hw/xtensa/xtfpga.c +++ b/hw/xtensa/xtfpga.c @@ -50,6 +50,7 @@ #include "xtensa_memory.h" #include "hw/xtensa/mx_pic.h" #include "migration/vmstate.h" +#include "hw/qdev-deprecated.h" typedef struct XtfpgaFlashDesc { hwaddr base; @@ -129,6 +130,8 @@ static XtfpgaFpgaState *xtfpga_fpga_init(MemoryRegion *address_space, { XtfpgaFpgaState *s = g_malloc(sizeof(XtfpgaFpgaState)); + qdev_warn_deprecated_function_used(); + memory_region_init_io(&s->iomem, NULL, &xtfpga_fpga_ops, s, "xtfpga.fpga", 0x10000); memory_region_add_subregion(address_space, base, &s->iomem); -- 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:13:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:13:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKPF-0007zQ-6s; Mon, 08 Jun 2020 16:13:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKPE-0007zL-Pq for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:13:48 +0000 X-Inumbo-ID: 08c0ebc6-a9a3-11ea-9ad7-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 08c0ebc6-a9a3-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 16:13:48 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6E19A206D5; Mon, 8 Jun 2020 16:13:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591632827; bh=LOpsTFq0ZkH2cN8y/1ahan3fKry7WioraIBzGJYpYKc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ijKc48iDnvfE6umhezyzgLNp2NmeFP2lfaMZux/yz2F4m8OhpMwcFrUa8I7Yj7jUb Qevc38IayBOhthG+N6Sfq18A7Wuha4JxG2d4D2F9YrJ8R3upwMcCQTQuhIhXoy8q+2 19DFUjHR74KUxwCoS4pWw6FIRyUXAg4Zws9MKJv0= Date: Mon, 8 Jun 2020 09:13:46 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: CodeWiz2280 Subject: Re: Keystone Issue In-Reply-To: Message-ID: References: <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 8 Jun 2020, CodeWiz2280 wrote: > It actually shows only 1 interrupt for any of the devices in that list > (e.g. spi, ttyS0, ethernet) so you're probably right on the money with > it being an interrupt acknowledge issue. Any help you can provide is > greatly appreciated. > > On Mon, Jun 8, 2020 at 4:40 AM Bertrand Marquis > wrote: > > > > > > > > > On 5 Jun 2020, at 20:12, CodeWiz2280 wrote: > > > > > > On Fri, Jun 5, 2020 at 11:05 AM CodeWiz2280 wrote: > > >> > > >> On Fri, Jun 5, 2020 at 8:47 AM Bertrand Marquis > > >> wrote: > > >>> > > >>> > > >>> > > >>>> On 5 Jun 2020, at 13:42, CodeWiz2280 wrote: > > >>>> > > >>>> On Fri, Jun 5, 2020 at 8:30 AM Julien Grall wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> On 05/06/2020 13:25, CodeWiz2280 wrote: > > >>>>>> The Keystone uses the netcp driver, which has interrupts from 40-79 > > >>>>>> listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). > > >>>>>> I'm using the same device tree between my non-xen standalone kernel > > >>>>>> and my dom0 kernel booted by xen. In the standalone (non-xen) kernel > > >>>>>> the ethernet works fine, but I don't see any of its interrupts in the > > >>>>>> output of /proc/iomem. I'm not seeing them in /proc/iomem when > > >>>>>> running dom0 under Xen either. When booting with Xen I get this > > >>>>>> behavior where the ifconfig output shows 1 RX message and 1 TX > > >>>>>> message, and then nothing else. > > >>>>> > > >>>>> I am not sure whether this is a typo in the e-mail. /proc/iomem is > > >>>>> listing the list of the MMIO regions. You want to use /proc/interrupts. > > >>>>> > > >>>>> Can you confirm which path you are dumping? > > >>>> Yes, that was a typo. Sorry about that. I meant that I am dumping > > >>>> /proc/interrupts and do not > > >>>> see them under the non-xen kernel or xen booted dom0. > > >>> > > >>> Could you post both /proc/interrupts content ? > > >> > > >> Standalone non-xen kernel (Ethernet works) > > >> # cat /proc/interrupts > > >> CPU0 CPU1 CPU2 CPU3 > > >> 17: 0 0 0 0 GICv2 29 Level > > >> arch_timer > > >> 18: 9856 1202 457 650 GICv2 30 Level > > >> arch_timer > > >> 21: 0 0 0 0 GICv2 142 Edge > > >> timer-keystone > > >> 22: 0 0 0 0 GICv2 52 Edge arm-pmu > > >> 23: 0 0 0 0 GICv2 53 Edge arm-pmu > > >> 24: 0 0 0 0 GICv2 54 Edge arm-pmu > > >> 25: 0 0 0 0 GICv2 55 Edge arm-pmu > > >> 26: 0 0 0 0 GICv2 36 Edge > > >> 26202a0.keystone_irq > > >> 27: 1435 0 0 0 GICv2 309 Edge ttyS0 > > >> 29: 0 0 0 0 GICv2 315 Edge > > >> 2530000.i2c > > >> 30: 1 0 0 0 GICv2 318 Edge > > >> 2530400.i2c > > >> 31: 0 0 0 0 GICv2 321 Edge > > >> 2530800.i2c > > >> 32: 69 0 0 0 GICv2 324 Edge > > >> 21000400.spi > > >> 33: 0 0 0 0 GICv2 328 Edge > > >> 21000600.spi > > >> 34: 0 0 0 0 GICv2 332 Edge > > >> 21000800.spi > > >> 70: 0 0 0 0 GICv2 417 Edge > > >> ks-pcie-error-irq > > >> 79: 0 0 0 0 PCI-MSI 0 Edge > > >> PCIe PME, aerdrv > > >> 88: 57 0 0 0 GICv2 80 Level > > >> hwqueue-528 > > >> 89: 57 0 0 0 GICv2 81 Level > > >> hwqueue-529 > > >> 90: 47 0 0 0 GICv2 82 Level > > >> hwqueue-530 > > >> 91: 41 0 0 0 GICv2 83 Level > > >> hwqueue-531 > > >> IPI0: 0 0 0 0 CPU wakeup interrupts > > >> IPI1: 0 0 0 0 Timer broadcast interrupts > > >> IPI2: 730 988 1058 937 Rescheduling interrupts > > >> IPI3: 2 3 4 6 Function call interrupts > > >> IPI4: 0 0 0 0 CPU stop interrupts > > >> IPI5: 0 0 0 0 IRQ work interrupts > > >> IPI6: 0 0 0 0 completion interrupts > > >> > > >> Xen dom0 (Ethernet stops) > > >> # cat /proc/interrupts > > >> CPU0 > > >> 18: 10380 GIC-0 27 Level arch_timer > > >> 19: 0 GIC-0 142 Edge timer-keystone > > >> 20: 88 GIC-0 16 Level events > > >> 21: 0 xen-dyn Edge -event xenbus > > >> 22: 0 GIC-0 36 Edge 26202a0.keystone_irq > > >> 23: 1 GIC-0 312 Edge ttyS0 > > >> 25: 1 GIC-0 318 Edge > > >> 27: 1 GIC-0 324 Edge 21000400.spi > > >> 28: 0 GIC-0 328 Edge 21000600.spi > > >> 29: 0 GIC-0 332 Edge 21000800.spi > > >> 65: 0 GIC-0 417 Edge ks-pcie-error-irq > > >> 74: 0 PCI-MSI 0 Edge PCIe PME, aerdrv > > >> 83: 1 GIC-0 80 Level hwqueue-528 > > >> 84: 1 GIC-0 81 Level hwqueue-529 > > >> 85: 1 GIC-0 82 Level hwqueue-530 > > >> 86: 1 GIC-0 83 Level hwqueue-531 > > >> 115: 87 xen-dyn Edge -virq hvc_console > > >> IPI0: 0 CPU wakeup interrupts > > >> IPI1: 0 Timer broadcast interrupts > > >> IPI2: 0 Rescheduling interrupts > > >> IPI3: 0 Function call interrupts > > >> IPI4: 0 CPU stop interrupts > > >> IPI5: 0 IRQ work interrupts > > >> IPI6: 0 completion interrupts > > >> Err: 0 > > > After getting a chance to look at this a little more, I believe the > > > TX/RX interrupts for the ethernets map like this: > > > > > > eth0 Rx - hwqueue-528 > > > eth1 Rx - hwqueue-529 > > > eth0 Tx - hwqueue-530 > > > eth1 Tx - hwqueue-531 > > >> > > > The interrupt counts in the standlone working kernel seem to roughly > > > correspond to the counts of Tx/Rx messages in ifconfig. Going on > > > that, its clear that only 1 interrupt has been received for Tx and 1 > > > for Rx in the Xen Dom0 equivalent. Any thoughts on this? > > > > This definitely look like an interrupt acknowledgement issue. > > This could be caused by 2 things I remember of: > > - front vs level interrupts > > - a problem with forwarded interrupt acknowledgement. > > I think there was something related to that where the vcpu ack was not properly > > handled on a keystone and I had to change the way the interrupt was acked for > > forwarded hardware interrupts. Is there maybe some sort of secondary interrupt controller (secondary in addition to the GIC) or interrupt "concentrator" on KeyStone? Or is it just a small deviation from normal GIC behavior? From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:14:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:14:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKPX-00080T-FV; Mon, 08 Jun 2020 16:14:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKPW-00080L-P7 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:14:06 +0000 X-Inumbo-ID: 12b2e27e-a9a3-11ea-b293-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 12b2e27e-a9a3-11ea-b293-12813bfff9fa; Mon, 08 Jun 2020 16:14:05 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 7RJZYeNK3E7v8cgWj9UwSIhBiCpyfVJYagWfsNQzYZKIU5mHyqkyuZZab33ciGw/GqMoN7HLyL Q1IwWkC9wtOZRw+uISjRjL8pFxr5RJOmWO+yX5jykJSRQS9oxC4GRLbL9tR5IPQk8xIYt47cNL Xoj1JdK7N8PCX79MMyp1dyNnekxDjyoEG/V4cof9B0qD8zo40MEeZLdsWroWasIbXmp0tjG/6s Yp4YHdbtRZsWgsAWyrgC9LFFgRyA15Rq07pippg1t7M0hH6KGSm2mGSSnsnzwq6Mhfz8T6Pqtm nCw= X-SBRS: 2.7 X-MesageID: 19789728 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19789728" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v4] x86/rtc: provide mediated access to RTC for PVH dom0 Date: Mon, 8 Jun 2020 18:13:53 +0200 Message-ID: <20200608161353.2654-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Mediated access to the RTC was provided for PVHv1 dom0 using the PV code paths (guest_io_{write/read}), but those accesses where never implemented for PVHv2 dom0. This patch provides such mediated accesses to the RTC for PVH dom0, just like it's provided for a classic PV dom0. Pull out some of the RTC logic from guest_io_{read/write} into specific helpers that can be used by both PV and HVM guests. The setup of the handlers for PVH is done in rtc_init, which is already used to initialize the fully emulated RTC. Without this a Linux PVH dom0 will read garbage when trying to access the RTC, and one vCPU will be constantly looping in rtc_timer_do_work. Note that such issue doesn't happen on domUs because the ACPI NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the accesses are not emulated but rather forwarded to the physical hardware. No functional change expected for classic PV dom0. Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich --- for-4.14 reasoning: the fix is mostly isolated to PVH dom0, and as such the risk is very low of causing issues to other guests types, but without this fix one vCPU when using a Linux dom0 will be constantly looping over rtc_timer_do_work with 100% CPU usage, at least when using Linux 4.19 or newer. --- Changes since v3: - Reword comment. - Add missing newline after break. - Remove extra parentheses in the RTC ports check in guest_io_{read/write}. Changes since v2: - Move the access check into the read/write handler. - Allow access to the latched first RTC port by all PV guests. - Register the handlers for HVM native accesses if vRTC is disabled. Changes since v1: - Share the code with PV. - Add access checks to the IO ports. --- xen/arch/x86/hvm/rtc.c | 26 +++++++++++++ xen/arch/x86/pv/emul-priv-op.c | 30 ++------------ xen/arch/x86/time.c | 65 +++++++++++++++++++++++++++++++ xen/include/asm-x86/mc146818rtc.h | 3 ++ 4 files changed, 98 insertions(+), 26 deletions(-) diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c index 5bbbdc0e0f..3150f5f147 100644 --- a/xen/arch/x86/hvm/rtc.c +++ b/xen/arch/x86/hvm/rtc.c @@ -808,12 +808,38 @@ void rtc_reset(struct domain *d) s->pt.source = PTSRC_isa; } +/* RTC mediator for HVM hardware domain. */ +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, + uint32_t *val) +{ + if ( dir == IOREQ_READ ) + *val = ~0; + + if ( size != 1 ) + { + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); + return X86EMUL_OKAY; + } + + if ( dir == IOREQ_WRITE ) + rtc_guest_write(port, *val); + else + *val = rtc_guest_read(port); + + return X86EMUL_OKAY; +} + void rtc_init(struct domain *d) { RTCState *s = domain_vrtc(d); if ( !has_vrtc(d) ) + { + if ( is_hardware_domain(d) ) + /* Hardware domain gets mediated access to the physical RTC. */ + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); return; + } spin_lock_init(&s->lock); diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c index fad6c754ad..254da2b849 100644 --- a/xen/arch/x86/pv/emul-priv-op.c +++ b/xen/arch/x86/pv/emul-priv-op.c @@ -280,19 +280,9 @@ static uint32_t guest_io_read(unsigned int port, unsigned int bytes, { sub_data = pv_pit_handler(port, 0, 0); } - else if ( port == RTC_PORT(0) ) + else if ( port == RTC_PORT(0) || port == RTC_PORT(1) ) { - sub_data = currd->arch.cmos_idx; - } - else if ( (port == RTC_PORT(1)) && - ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) - { - unsigned long flags; - - spin_lock_irqsave(&rtc_lock, flags); - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); - sub_data = inb(RTC_PORT(1)); - spin_unlock_irqrestore(&rtc_lock, flags); + sub_data = rtc_guest_read(port); } else if ( (port == 0xcf8) && (bytes == 4) ) { @@ -413,21 +403,9 @@ static void guest_io_write(unsigned int port, unsigned int bytes, { pv_pit_handler(port, (uint8_t)data, 1); } - else if ( port == RTC_PORT(0) ) - { - currd->arch.cmos_idx = data; - } - else if ( (port == RTC_PORT(1)) && - ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) + else if ( port == RTC_PORT(0) || port == RTC_PORT(1) ) { - unsigned long flags; - - if ( pv_rtc_handler ) - pv_rtc_handler(currd->arch.cmos_idx & 0x7f, data); - spin_lock_irqsave(&rtc_lock, flags); - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); - outb(data, RTC_PORT(1)); - spin_unlock_irqrestore(&rtc_lock, flags); + rtc_guest_write(port, data); } else if ( (port == 0xcf8) && (bytes == 4) ) { diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c index bbaea3aa65..d643590c0a 100644 --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include #include @@ -1110,6 +1111,70 @@ static unsigned long get_cmos_time(void) return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, rtc.sec); } +/* Helpers for guest accesses to the physical RTC. */ +unsigned int rtc_guest_read(unsigned int port) +{ + const struct domain *currd = current->domain; + unsigned long flags; + unsigned int data = ~0; + + switch ( port ) + { + case RTC_PORT(0): + /* + * All PV domains (and PVH dom0) are allowed to read the latched value + * of the first RTC port, as there's no access to the physical IO + * ports. + */ + data = currd->arch.cmos_idx; + break; + + case RTC_PORT(1): + if ( !ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) + break; + spin_lock_irqsave(&rtc_lock, flags); + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); + data = inb(RTC_PORT(1)); + spin_unlock_irqrestore(&rtc_lock, flags); + break; + + default: + ASSERT_UNREACHABLE(); + } + + return data; +} + +void rtc_guest_write(unsigned int port, unsigned int data) +{ + struct domain *currd = current->domain; + unsigned long flags; + + switch ( port ) + { + case RTC_PORT(0): + /* + * All PV domains (and PVH dom0) are allowed to write to the latched + * value of the first RTC port, as there's no access to the physical IO + * ports. + */ + currd->arch.cmos_idx = data; + break; + + case RTC_PORT(1): + if ( !ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) ) + break; + spin_lock_irqsave(&rtc_lock, flags); + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); + outb(data, RTC_PORT(1)); + spin_unlock_irqrestore(&rtc_lock, flags); + break; + + default: + ASSERT_UNREACHABLE(); + } +} + static unsigned long get_wallclock_time(void) { #ifdef CONFIG_XEN_GUEST diff --git a/xen/include/asm-x86/mc146818rtc.h b/xen/include/asm-x86/mc146818rtc.h index 8758528f7c..803b236c0a 100644 --- a/xen/include/asm-x86/mc146818rtc.h +++ b/xen/include/asm-x86/mc146818rtc.h @@ -110,4 +110,7 @@ outb_p((val),RTC_PORT(1)); \ #define RTC_IRQ 8 +unsigned int rtc_guest_read(unsigned int port); +void rtc_guest_write(unsigned int port, unsigned int data); + #endif /* _ASM_MC146818RTC_H */ -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:14:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:14:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKPy-00085I-Oq; Mon, 08 Jun 2020 16:14:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKPx-000854-LP for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:14:33 +0000 X-Inumbo-ID: 23a4009a-a9a3-11ea-9b55-bc764e2007e4 Received: from mail-oi1-x241.google.com (unknown [2607:f8b0:4864:20::241]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 23a4009a-a9a3-11ea-9b55-bc764e2007e4; Mon, 08 Jun 2020 16:14:33 +0000 (UTC) Received: by mail-oi1-x241.google.com with SMTP id k4so14255342oik.2 for ; Mon, 08 Jun 2020 09:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/+4QjpT+tPPNmlVcx3DdQ4kyskVFCMtysHbcHTNYe74=; b=kS58IrIM5lez6Lj5rtZnhJPFBV+K9srHQMqeFSm7Z+xDcxy5VB1+sG7mD7OgAU3Xlc pqtBn6vqhsdiy+5UWO9tA5v94lie87F6qtEtU8Oox/I3ezGt7DNwpHBQTSE1GTX+xmXw k3pbE1MrKcyt2zqAeLEsEhQOPlnINXANgWN9+eUAWrJHhjMAubtk/mMoq4Yz4NnaAb+E qok7pIPLclNsBFO2iEIhsEcGPn4rTChUJWZlcplpcZ+BJti3DUIyDl7hvfGaH3LbrDMV sQ7C65a11jICToH03NJRuGZhykKF9IAflFSwaOXhWoK0BC8Ws5uLBhYv++PjUzYGuCna Iofw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/+4QjpT+tPPNmlVcx3DdQ4kyskVFCMtysHbcHTNYe74=; b=YeM5bH5SQAByVK3v0IGEjYPzGQkfaC3P8AZvKPOw4USFcePcOgY12LJO+3/OY/egad o+bERachaVcNoqCa59x2tFnqL5M2KY195E+6CuDgTlrvIVyuzpnXKFhdgy4FGtCNDX20 KbWad/b5JYsnLJz85ynb39i0m9FvwsXdxDEyABXhKbuZSlj2eYFKyGdtzkcKMjioPJae +JGglC6QRsbU0cjyvc2T2P4y0tT94mYi77rlyb0fW83e85eqHtNngGBmIiSo9nCD40Mj OZtjxwI2Ywo7kbJyqCYR7j4Mzflr9JG3hu86dYemyw5V4A3WFK5CvsOQcOZU2Rm+M/Tf Mh4g== X-Gm-Message-State: AOAM532zbHBl+dscrCzAA9WF2E7EXA4aX+IcRWBorgSoCXyYMbri2hXS tpufbKtkUw17tg5n/JhpBV2FisoySQuhquzuGX6Umw== X-Google-Smtp-Source: ABdhPJxY837bRoD3+f6ZcPgGbh8vCM84Cl4LR/XbymbYhKCUqj4k8XH49NE9YAo4JBnuJUGXAVD6K2cFlG42HGdNVeI= X-Received: by 2002:aca:568c:: with SMTP id k134mr107477oib.48.1591632872829; Mon, 08 Jun 2020 09:14:32 -0700 (PDT) MIME-Version: 1.0 References: <20200608160044.15531-1-philmd@redhat.com> In-Reply-To: <20200608160044.15531-1-philmd@redhat.com> From: Peter Maydell Date: Mon, 8 Jun 2020 17:14:21 +0100 Message-ID: Subject: Re: [RFC PATCH 00/35] hw/qdev: Warn when using pre-qdev/QOM devices To: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , QEMU Developers , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm , "open list:X86" , "open list:RISC-V" , Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc , Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 8 Jun 2020 at 17:00, Philippe Mathieu-Daud=C3=A9 wrote: > > Based on today's IRC chat, this is a trivial RFC series > to anotate pre-qdev/QOM devices so developers using them > without knowing they are not QOM'ified yet can realize > it and convert them if they have time. What mechanism did you use for identifying non-QOM devices? thanks -- PMM From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:17:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:17:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKT5-0008MM-BX; Mon, 08 Jun 2020 16:17:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKT3-0008ME-Qs for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:17:45 +0000 X-Inumbo-ID: 961a229e-a9a3-11ea-ba62-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 961a229e-a9a3-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 16:17:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591633065; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=1jLMVbVyOeQVt3DxZyMkiZa3v5bA58Ubvf1vYrVyoKY=; b=JRcWnRERdA858LJdWhdyW/963/iUinf3bTRO/Rw/ewmQTBXoxSYMDveEn8Q6NiiyKseU9Z yNjvWHZMf+Smy3BK2A64FcPnNJhXdFj9N1V9m3qHQGkWtqTHBThgvfE16rBfFNW9A6G/EB MV5mwSMpzwST2Cx6q8tbjSNhNXjtSbo= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-358-JAtTBJX4MlavQJ5uIlP-CA-1; Mon, 08 Jun 2020 12:17:43 -0400 X-MC-Unique: JAtTBJX4MlavQJ5uIlP-CA-1 Received: by mail-wr1-f71.google.com with SMTP id e1so7385435wrm.3 for ; Mon, 08 Jun 2020 09:17:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1jLMVbVyOeQVt3DxZyMkiZa3v5bA58Ubvf1vYrVyoKY=; b=MxZCzGkWgWiyzWGsQ/zK9Bvw5YEqOK6/g5h4sBPIEoT+Hd/8oOPvnLu2B+HKAbe4tr kPICkS9zksLuWfOOa5wkvpgkkIMmZWQwNz72vgJW2zxwTqeS3Z8RZ0y4UucU8+sUMOet 7NnT2uJnBtJtFqM4oZC9JrwInCvVEKZ2YH3JOcu9UP9v4R7iwu/vzY55PnuUG2Yr2GVP jEK5E/yvJa6AJckkK3oRKwDiDjP3PchqiQ4G5+MBaGImuhbbEK1htGIUWjhpjSfx3CpE BoHzox17lYxXdsDYyHwK6BdooSEXdZ4N6Jm9JiLM+jRc2F9C8gTzhH+cW5NPrAARxKnj puYA== X-Gm-Message-State: AOAM530/RvZJfpRhv/4jdjWXzSHnP20Lng0Ksy5bQ1jZFtRryNx9BvDr ZFlc5JC/MhV/zelHUS6wI+iWtULBkI2Hv2h1CwL6gj3EplcXcJZSBuxbVEciqYhvJfvdzkqM86A DnACf+5qtEapCa8+aAZuKcn0z6Ck= X-Received: by 2002:a1c:1f48:: with SMTP id f69mr104660wmf.67.1591633062255; Mon, 08 Jun 2020 09:17:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3YBh9EGdDObAb79iv4SsIf8IFp5HSV9+Z1Ovy3h5MqXgC2dmwC/+3rmg10l/GT0TlOYJvaw== X-Received: by 2002:a1c:1f48:: with SMTP id f69mr104619wmf.67.1591633062031; Mon, 08 Jun 2020 09:17:42 -0700 (PDT) Received: from [192.168.1.38] (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id k21sm247677wrd.24.2020.06.08.09.17.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 09:17:41 -0700 (PDT) Subject: Re: [RFC PATCH 00/35] hw/qdev: Warn when using pre-qdev/QOM devices To: Peter Maydell References: <20200608160044.15531-1-philmd@redhat.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: <81653f82-484b-a04a-7b2c-1362a724d0e8@redhat.com> Date: Mon, 8 Jun 2020 18:17:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , QEMU Developers , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm , "open list:X86" , "open list:RISC-V" , Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc , Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/8/20 6:14 PM, Peter Maydell wrote: > On Mon, 8 Jun 2020 at 17:00, Philippe Mathieu-Daudé wrote: >> >> Based on today's IRC chat, this is a trivial RFC series >> to anotate pre-qdev/QOM devices so developers using them >> without knowing they are not QOM'ified yet can realize >> it and convert them if they have time. > > What mechanism did you use for identifying non-QOM devices? I don't think this is the complete list, this is only all the one I could find with: $ git grep "g_new|g_malloc" hw/ Then on each match I manually reviewed (so I might have incorrectly flagged code too). From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:31:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:31:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKfs-0001Zt-GX; Mon, 08 Jun 2020 16:31:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKfr-0001Zo-JJ for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:30:59 +0000 X-Inumbo-ID: 6e86cf14-a9a5-11ea-96fb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6e86cf14-a9a5-11ea-96fb-bc764e2007e4; Mon, 08 Jun 2020 16:30:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UNZEoxDqD5Gy8/P6JGOrXrr3jGxxiUA0cxcX7A06HpI=; b=IRg2MwgdLgckukm5Rx1L3Ubkh VlwPABBXZA/b38LJOrfrI0ML01ViCKj+FQXfE7AxZb0Ibjm2PEVKWLBYfSz4WPJXJUYSTDFdjyyBc NrCrjQJTJJvTZOGj46L5RBJ6NO2/bLU9Bq6AjrxA2dLU0/+T92Xij5iENNPrxPukcT5GE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKfp-0003LY-HI; Mon, 08 Jun 2020 16:30:57 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiKfp-0001I2-95; Mon, 08 Jun 2020 16:30:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiKfp-0004SA-8U; Mon, 08 Jun 2020 16:30:57 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150918: trouble: broken/fail/pass X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds::broken:regression xen-unstable:test-amd64-amd64-xl-rtds:guest-saverestore.2:fail:heisenbug xen-unstable:test-armhf-armhf-xl-rtds:guest-stop:fail:heisenbug xen-unstable:test-amd64-amd64-xl-rtds:capture-logs(18):broken:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=51ca66c37371b10b378513af126646de22eddb17 X-Osstest-Versions-That: xen=51ca66c37371b10b378513af126646de22eddb17 From: osstest service owner Date: Mon, 08 Jun 2020 16:30:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150918 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150918/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-rtds broken Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 17 guest-saverestore.2 fail pass in 150900 test-armhf-armhf-xl-rtds 15 guest-stop fail pass in 150900 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 capture-logs(18) broken blocked in 150900 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail in 150900 like 150869 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 150900 like 150897 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 150900 like 150897 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150900 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150900 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150900 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150900 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150900 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150900 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150900 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150900 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150900 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: xen 51ca66c37371b10b378513af126646de22eddb17 baseline version: xen 51ca66c37371b10b378513af126646de22eddb17 Last test of basis 150918 2020-06-08 01:51:14 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds broken test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-amd64-xl-rtds broken broken-step test-amd64-amd64-xl-rtds capture-logs(18) Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:34:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:34:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKit-0001kK-3n; Mon, 08 Jun 2020 16:34:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKir-0001kF-IJ for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:34:05 +0000 X-Inumbo-ID: dd7ec782-a9a5-11ea-9ad7-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dd7ec782-a9a5-11ea-9ad7-bc764e2007e4; Mon, 08 Jun 2020 16:34:04 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id l10so18099505wrr.10 for ; Mon, 08 Jun 2020 09:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=AtEnjShvwY/k06VTmB0mLv1uwHmYlMMdW/0/wJZrmIQ=; b=hR17YPlwAqCXqtJJ/AzM+KAb1E9jpXmfd1qDhGyzXcTqDseFZxnXrWY+pL3HtmNarP NGz0L3J7tXVBBOy0EkU59DzV2QM4kArOomoc3UxPJBsD8p7ffLz9j3O1VD9b3qY6szhr vvcO9c2FirLX4d3vsgVI4h/ZfIZlGckvRKcKOh8bmxRJ1BdzJrhcGnJsIrxwq9SXkK5N 9TUs7mp55Hmr0AxnlLRaWaO1Va530LV2PNLC2Efcd/RIescuepm8Iu4vLoyShRvO+2A2 nCVY18huWmIFXI+XdioCwaFcErwg4hW6BtrqbwgWkJNA8IFrM/xztMCYrgtJSHvDOqms ssmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=AtEnjShvwY/k06VTmB0mLv1uwHmYlMMdW/0/wJZrmIQ=; b=Q+8j2V4c8JMybtGRLC1o6HX3dWJLNlTwozGIVN8eHmjyKP5SjvrXbZIiY4ruMy3p4D DYjHsx84A4oQETv7+/rZxHFakiBhswGHmX9dlgZd5D5g3OOeydUeaNMdRFwQvjUZsU7B BVHTMIQHVxsSpMRE/3t3vUguX492tAuAax6zH80Lp8Cx1yIxOyshe0RwdQSkGi8KxL8X WZbta8yh9OirU7ktjrFJ1IcoL/483dpFYI40iiwglDUR1jJrzTilDxMW2scYmEpPSHSF J+gCPnjl9RXx40mNFzi8C9+1GzILEcl4Izt2T/RT4O9qeTQfzrmVpI9PIhQNaorFmjTX BSOQ== X-Gm-Message-State: AOAM532BGMGnxWluQBvUaZqsxoSB/B7FgV32TcepXP5ecJxJq3nCAvkD LMK/PgovxpZjKWU7++OTTXbr8OXx1T0= X-Google-Smtp-Source: ABdhPJwTz5aaN1yHXp9ouooEB0CT7vN9ttKkpxywDxF4/F429xljwLAt/0quhTuty7B1PizGKSU+gQ== X-Received: by 2002:adf:a51a:: with SMTP id i26mr23842353wrb.406.1591634043467; Mon, 08 Jun 2020 09:34:03 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id u7sm276831wrm.23.2020.06.08.09.34.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 09:34:02 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200608161353.2654-1-roger.pau@citrix.com> In-Reply-To: <20200608161353.2654-1-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14 v4] x86/rtc: provide mediated access to RTC for PVH dom0 Date: Mon, 8 Jun 2020 17:34:01 +0100 Message-ID: <004a01d63db2$9ea22db0$dbe68910$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJDDnpi0r6pS+dLTuHWH2aB9skHoKf1SB6g X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Jan Beulich' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = Roger Pau Monne > Sent: 08 June 2020 17:14 > To: xen-devel@lists.xenproject.org > Cc: Andrew Cooper ; Roger Pau Monne = ; Wei Liu > ; Jan Beulich ; paul@xen.org > Subject: [PATCH for-4.14 v4] x86/rtc: provide mediated access to RTC = for PVH dom0 >=20 > Mediated access to the RTC was provided for PVHv1 dom0 using the PV > code paths (guest_io_{write/read}), but those accesses where never > implemented for PVHv2 dom0. This patch provides such mediated accesses > to the RTC for PVH dom0, just like it's provided for a classic PV > dom0. >=20 > Pull out some of the RTC logic from guest_io_{read/write} into > specific helpers that can be used by both PV and HVM guests. The > setup of the handlers for PVH is done in rtc_init, which is already > used to initialize the fully emulated RTC. >=20 > Without this a Linux PVH dom0 will read garbage when trying to access > the RTC, and one vCPU will be constantly looping in > rtc_timer_do_work. >=20 > Note that such issue doesn't happen on domUs because the ACPI > NO_CMOS_RTC flag is set in FADT, which prevents the OS from accessing > the RTC. Also the X86_EMU_RTC flag is not set for PVH dom0, as the > accesses are not emulated but rather forwarded to the physical > hardware. >=20 > No functional change expected for classic PV dom0. >=20 > Signed-off-by: Roger Pau Monn=C3=A9 > Reviewed-by: Jan Beulich Release-acked-by: Paul Durrant > --- > for-4.14 reasoning: the fix is mostly isolated to PVH dom0, and as > such the risk is very low of causing issues to other guests types, but > without this fix one vCPU when using a Linux dom0 will be constantly > looping over rtc_timer_do_work with 100% CPU usage, at least when > using Linux 4.19 or newer. > --- > Changes since v3: > - Reword comment. > - Add missing newline after break. > - Remove extra parentheses in the RTC ports check in > guest_io_{read/write}. >=20 > Changes since v2: > - Move the access check into the read/write handler. > - Allow access to the latched first RTC port by all PV guests. > - Register the handlers for HVM native accesses if vRTC is disabled. >=20 > Changes since v1: > - Share the code with PV. > - Add access checks to the IO ports. > --- > xen/arch/x86/hvm/rtc.c | 26 +++++++++++++ > xen/arch/x86/pv/emul-priv-op.c | 30 ++------------ > xen/arch/x86/time.c | 65 = +++++++++++++++++++++++++++++++ > xen/include/asm-x86/mc146818rtc.h | 3 ++ > 4 files changed, 98 insertions(+), 26 deletions(-) >=20 > diff --git a/xen/arch/x86/hvm/rtc.c b/xen/arch/x86/hvm/rtc.c > index 5bbbdc0e0f..3150f5f147 100644 > --- a/xen/arch/x86/hvm/rtc.c > +++ b/xen/arch/x86/hvm/rtc.c > @@ -808,12 +808,38 @@ void rtc_reset(struct domain *d) > s->pt.source =3D PTSRC_isa; > } >=20 > +/* RTC mediator for HVM hardware domain. */ > +static int hw_rtc_io(int dir, unsigned int port, unsigned int size, > + uint32_t *val) > +{ > + if ( dir =3D=3D IOREQ_READ ) > + *val =3D ~0; > + > + if ( size !=3D 1 ) > + { > + gdprintk(XENLOG_WARNING, "bad RTC access size (%u)\n", size); > + return X86EMUL_OKAY; > + } > + > + if ( dir =3D=3D IOREQ_WRITE ) > + rtc_guest_write(port, *val); > + else > + *val =3D rtc_guest_read(port); > + > + return X86EMUL_OKAY; > +} > + > void rtc_init(struct domain *d) > { > RTCState *s =3D domain_vrtc(d); >=20 > if ( !has_vrtc(d) ) > + { > + if ( is_hardware_domain(d) ) > + /* Hardware domain gets mediated access to the physical = RTC. */ > + register_portio_handler(d, RTC_PORT(0), 2, hw_rtc_io); > return; > + } >=20 > spin_lock_init(&s->lock); >=20 > diff --git a/xen/arch/x86/pv/emul-priv-op.c = b/xen/arch/x86/pv/emul-priv-op.c > index fad6c754ad..254da2b849 100644 > --- a/xen/arch/x86/pv/emul-priv-op.c > +++ b/xen/arch/x86/pv/emul-priv-op.c > @@ -280,19 +280,9 @@ static uint32_t guest_io_read(unsigned int port, = unsigned int bytes, > { > sub_data =3D pv_pit_handler(port, 0, 0); > } > - else if ( port =3D=3D RTC_PORT(0) ) > + else if ( port =3D=3D RTC_PORT(0) || port =3D=3D RTC_PORT(1) = ) > { > - sub_data =3D currd->arch.cmos_idx; > - } > - else if ( (port =3D=3D RTC_PORT(1)) && > - ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) > - { > - unsigned long flags; > - > - spin_lock_irqsave(&rtc_lock, flags); > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > - sub_data =3D inb(RTC_PORT(1)); > - spin_unlock_irqrestore(&rtc_lock, flags); > + sub_data =3D rtc_guest_read(port); > } > else if ( (port =3D=3D 0xcf8) && (bytes =3D=3D 4) ) > { > @@ -413,21 +403,9 @@ static void guest_io_write(unsigned int port, = unsigned int bytes, > { > pv_pit_handler(port, (uint8_t)data, 1); > } > - else if ( port =3D=3D RTC_PORT(0) ) > - { > - currd->arch.cmos_idx =3D data; > - } > - else if ( (port =3D=3D RTC_PORT(1)) && > - ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) > + else if ( port =3D=3D RTC_PORT(0) || port =3D=3D RTC_PORT(1) = ) > { > - unsigned long flags; > - > - if ( pv_rtc_handler ) > - pv_rtc_handler(currd->arch.cmos_idx & 0x7f, data); > - spin_lock_irqsave(&rtc_lock, flags); > - outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > - outb(data, RTC_PORT(1)); > - spin_unlock_irqrestore(&rtc_lock, flags); > + rtc_guest_write(port, data); > } > else if ( (port =3D=3D 0xcf8) && (bytes =3D=3D 4) ) > { > diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c > index bbaea3aa65..d643590c0a 100644 > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -27,6 +27,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1110,6 +1111,70 @@ static unsigned long get_cmos_time(void) > return mktime(rtc.year, rtc.mon, rtc.day, rtc.hour, rtc.min, = rtc.sec); > } >=20 > +/* Helpers for guest accesses to the physical RTC. */ > +unsigned int rtc_guest_read(unsigned int port) > +{ > + const struct domain *currd =3D current->domain; > + unsigned long flags; > + unsigned int data =3D ~0; > + > + switch ( port ) > + { > + case RTC_PORT(0): > + /* > + * All PV domains (and PVH dom0) are allowed to read the = latched value > + * of the first RTC port, as there's no access to the = physical IO > + * ports. > + */ > + data =3D currd->arch.cmos_idx; > + break; > + > + case RTC_PORT(1): > + if ( !ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) > + break; > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + data =3D inb(RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + > + default: > + ASSERT_UNREACHABLE(); > + } > + > + return data; > +} > + > +void rtc_guest_write(unsigned int port, unsigned int data) > +{ > + struct domain *currd =3D current->domain; > + unsigned long flags; > + > + switch ( port ) > + { > + case RTC_PORT(0): > + /* > + * All PV domains (and PVH dom0) are allowed to write to the = latched > + * value of the first RTC port, as there's no access to the = physical IO > + * ports. > + */ > + currd->arch.cmos_idx =3D data; > + break; > + > + case RTC_PORT(1): > + if ( !ioports_access_permitted(currd, RTC_PORT(0), = RTC_PORT(1)) ) > + break; > + spin_lock_irqsave(&rtc_lock, flags); > + outb(currd->arch.cmos_idx & 0x7f, RTC_PORT(0)); > + outb(data, RTC_PORT(1)); > + spin_unlock_irqrestore(&rtc_lock, flags); > + break; > + > + default: > + ASSERT_UNREACHABLE(); > + } > +} > + > static unsigned long get_wallclock_time(void) > { > #ifdef CONFIG_XEN_GUEST > diff --git a/xen/include/asm-x86/mc146818rtc.h = b/xen/include/asm-x86/mc146818rtc.h > index 8758528f7c..803b236c0a 100644 > --- a/xen/include/asm-x86/mc146818rtc.h > +++ b/xen/include/asm-x86/mc146818rtc.h > @@ -110,4 +110,7 @@ outb_p((val),RTC_PORT(1)); \ >=20 > #define RTC_IRQ 8 >=20 > +unsigned int rtc_guest_read(unsigned int port); > +void rtc_guest_write(unsigned int port, unsigned int data); > + > #endif /* _ASM_MC146818RTC_H */ > -- > 2.26.2 >=20 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:39:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:39:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKoE-0001zE-TE; Mon, 08 Jun 2020 16:39:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKoC-0001z9-W5 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:39:37 +0000 X-Inumbo-ID: a3a310f8-a9a6-11ea-b298-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a3a310f8-a9a6-11ea-b298-12813bfff9fa; Mon, 08 Jun 2020 16:39:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Reply-To:Message-Id:Date:Subject:To:From:Sender:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6Kc+B0L0LNrarCLVqtqHFeGwaR1j4Y9ArTtJJdoAKvU=; b=6Zb5AwabTtDWFnPSJg18nGm64Q beT+tLAaEiXNzwioiF5qsVURGj8Pp+Dyl1xRJXhYocfYFkJb0cfns42u3vDMRGRCQiiAQYthFjh6C 90sjAjiMCxCHBWaEsUSpdbwrwc61mMyZbq9vZP0Su65SSVfbvbWAVX3l/YpRQxlno5X4=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiKoC-0003WP-7X; Mon, 08 Jun 2020 16:39:36 +0000 Received: from [54.239.6.186] (helo=CBG-R90WXYV0.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jiKoB-0004WR-UD; Mon, 08 Jun 2020 16:39:36 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Subject: Xen 4.14 RC1 Date: Mon, 8 Jun 2020 17:39:34 +0100 Message-Id: <20200608163934.313-1-paul@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: xen-devel@lists.xenproject.org, paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi all, Xen 4.14 RC1 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.14.0-rc1 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (paul@xen.org). As a reminder, there will be a Xen Test Day. Please see the test day schedule at https://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions. Paul Durrant From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:53:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:53:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiL1G-0003qQ-TJ; Mon, 08 Jun 2020 16:53:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiL1F-0003pX-1c for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:53:05 +0000 X-Inumbo-ID: 848e6030-a9a8-11ea-b299-12813bfff9fa Received: from smtp-fw-9102.amazon.com (unknown [207.171.184.29]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 848e6030-a9a8-11ea-b299-12813bfff9fa; Mon, 08 Jun 2020 16:53:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591635185; x=1623171185; h=date:from:to:cc:message-id:references:mime-version: in-reply-to:subject; bh=rnDp5I6x3A3PSGWGNTcHDsvC0Hxz7VaObBC0sQPmk2o=; b=twU2fmUrnBpP6ZP4ZLcjRhEW4flqq+Xa+NF4TujYu+uonE9q0ekeBra2 dMqLNP5SUmgdXobnJMe+dWlM/HKZ3mGx+c/FNlAIT6kSXXC2tySxi9aez lzU8+To5xiCL7TxyR8yqyxAESiWDSFNbXQe+8ZsibjlBFfeUNyFRbtUUE o=; IronPort-SDR: MSGLE2U6Ywvdm0/7LZ2EFFZLSYATNkPwGtPzXiLLT7V5bdnlx5eTqZ85cjdTzmiDTvSDMabs5n CF2KXs+xJ+3A== X-IronPort-AV: E=Sophos;i="5.73,487,1583193600"; d="scan'208";a="50682291" Subject: Re: [PATCH 03/12] x86/xen: Introduce new function to map HYPERVISOR_shared_info on Resume Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-22cc717f.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 08 Jun 2020 16:53:01 +0000 Received: from EX13MTAUEB002.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2a-22cc717f.us-west-2.amazon.com (Postfix) with ESMTPS id B726EA221B; Mon, 8 Jun 2020 16:52:58 +0000 (UTC) Received: from EX13D08UEB003.ant.amazon.com (10.43.60.11) by EX13MTAUEB002.ant.amazon.com (10.43.60.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 16:52:36 +0000 Received: from EX13MTAUEB002.ant.amazon.com (10.43.60.12) by EX13D08UEB003.ant.amazon.com (10.43.60.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 16:52:36 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.60.234) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 8 Jun 2020 16:52:36 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id C641640832; Mon, 8 Jun 2020 16:52:35 +0000 (UTC) Date: Mon, 8 Jun 2020 16:52:35 +0000 From: Anchal Agarwal To: Boris Ostrovsky Message-ID: <20200608165235.GA1330@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <529f544a64bb93b920bf86b1d3f86d93b0a4219b.1589926004.git.anchalag@amazon.com> <72989b50-0c13-7a2b-19e2-de4a3646c83f@oracle.com> <20200604230307.GB25251@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <9644a5f1-e1f8-5fe1-3135-cc6b4baf893b@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <9644a5f1-e1f8-5fe1-3135-cc6b4baf893b@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: eduval@amazon.com, len.brown@intel.com, peterz@infradead.org, benh@kernel.crashing.org, x86@kernel.org, linux-mm@kvack.org, pavel@ucw.cz, hpa@zytor.com, sstabellini@kernel.org, kamatam@amazon.com, mingo@redhat.com, xen-devel@lists.xenproject.org, sblbir@amazon.com, axboe@kernel.dk, konrad.wilk@oracle.com, bp@alien8.de, tglx@linutronix.de, jgross@suse.com, netdev@vger.kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, vkuznets@redhat.com, davem@davemloft.net, dwmw@amazon.co.uk, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 05:39:54PM -0400, Boris Ostrovsky wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On 6/4/20 7:03 PM, Anchal Agarwal wrote: > > On Sat, May 30, 2020 at 07:02:01PM -0400, Boris Ostrovsky wrote: > >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > >> > >> > >> > >> On 5/19/20 7:25 PM, Anchal Agarwal wrote: > >>> Introduce a small function which re-uses shared page's PA allocated > >>> during guest initialization time in reserve_shared_info() and not > >>> allocate new page during resume flow. > >>> It also does the mapping of shared_info_page by calling > >>> xen_hvm_init_shared_info() to use the function. > >>> > >>> Signed-off-by: Anchal Agarwal > >>> --- > >>> arch/x86/xen/enlighten_hvm.c | 7 +++++++ > >>> arch/x86/xen/xen-ops.h | 1 + > >>> 2 files changed, 8 insertions(+) > >>> > >>> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c > >>> index e138f7de52d2..75b1ec7a0fcd 100644 > >>> --- a/arch/x86/xen/enlighten_hvm.c > >>> +++ b/arch/x86/xen/enlighten_hvm.c > >>> @@ -27,6 +27,13 @@ > >>> > >>> static unsigned long shared_info_pfn; > >>> > >>> +void xen_hvm_map_shared_info(void) > >>> +{ > >>> + xen_hvm_init_shared_info(); > >>> + if (shared_info_pfn) > >>> + HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn)); > >>> +} > >>> + > >> > >> AFAICT it is only called once so I don't see a need for new routine. > >> > >> > > HYPERVISOR_shared_info can only be mapped in this scope without refactoring > > much of the code. > > > Refactoring what? All am suggesting is > shared_info_pfn does not seem to be in scope here, it's scope is limited to enlighten_hvm.c. That's the reason I introduced a new function there. > --- a/arch/x86/xen/suspend.c > +++ b/arch/x86/xen/suspend.c > @@ -124,7 +124,9 @@ static void xen_syscore_resume(void) > return; > > /* No need to setup vcpu_info as it's already moved off */ > - xen_hvm_map_shared_info(); > + xen_hvm_init_shared_info(); > + if (shared_info_pfn) > + HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn)); > > pvclock_resume(); > > >> And is it possible for shared_info_pfn to be NULL in resume path (which > >> is where this is called)? > >> > >> > > I don't think it should be, still a sanity check but I don't think its needed there > > because hibernation will fail in any case if thats the case. > > > If shared_info_pfn is NULL you'd have problems long before hibernation > started. We set it in xen_hvm_guest_init() and never touch again. > > > In fact, I'd argue that it should be __ro_after_init. > > I agree, and I should have mentioned that I will remove that check and its not necessary as this gets mapped way early in the boot process. > > However, HYPERVISOR_shared_info does needs to be re-mapped on resume as its been > > marked to dummy address on suspend. Its also safe in case va changes. > > Does the answer your question? > > > I wasn't arguing whether HYPERVISOR_shared_info needs to be set, I was > only saying that shared_info_pfn doesn't need to be tested. > Got it. :) > > -boris > Thanks, Anchal > From xen-devel-bounces@lists.xenproject.org Mon Jun 08 16:54:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 16:54:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiL32-00041L-8X; Mon, 08 Jun 2020 16:54:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiL31-00041E-5r for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 16:54:55 +0000 X-Inumbo-ID: c699ef4e-a9a8-11ea-ba62-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c699ef4e-a9a8-11ea-ba62-bc764e2007e4; Mon, 08 Jun 2020 16:54:54 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id k26so217798wmi.4 for ; Mon, 08 Jun 2020 09:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=oNB6pAr4fcRFpfN0vgO3R/SPq1U20RR7okPBo0+FgUE=; b=TAfmK0oQkeSGz62TuViy7NuLCNk1BF68l8xbAdU7an1ZC1hVV98IKOoRjmqyaTwVAN +in5sBo54K9vZ+PoT5Dju2DDOh9ml4x74mKWFDeR19EFjNT+Klc17086J5unyRp6crm0 iX59NmiKjPexLajwu2LCbDjom1z4V5Ya7Tr/x9a2tD7WOo4+qq200GMJWH+At1YTWsbM +wJH2TSrIVK7d5tnTy4ZVb1OjT049f7NavDysekPgvsZp+8YL5JJqDIx0twx4zpgFLUZ BUPmA4rk/i0fKuA7MEpGHm8R9boPmkow/IyBFJZL0415yukucMZFCcEQRzyZerGGqu0H ++ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=oNB6pAr4fcRFpfN0vgO3R/SPq1U20RR7okPBo0+FgUE=; b=d2wdiJs9VoXWQtCZPJeTT2OhW7s8qupgdHWMbVzCsi9Le6HMCu6hBiKR63dUIbH/8W vqMV03NQwfcQda/dHvpBWMh8abSdbaUom75Hq7bxiGt/gJqWvTFBeHeqsleUCkg8Ivzf KiUd/d9LJKMwQEmYee6dGaJn26DWZlSpzNZUBs+cxvH5DypYohvLUrcx+4G9hJqVzb1s F7vdykIyJDeDANTUOPjHE7TsKpGjyAsY9pRwqZBwhv0S/yGD2R05vAia6QcR/At1uuDF Dvx+QLW/djVTfCIZIGhePBI6PuE+hXJpjALjDErqQygy4vC9szNyqVX8sShb4dh+OX8z JWuA== X-Gm-Message-State: AOAM530zYpZuhjV5wCCZzZk7loQRbpeEevyducPPbZjKf+MIrb2FNevi hfQJt6nE8ceTZUvNRVbqn5U= X-Google-Smtp-Source: ABdhPJxYf2eoroXcg65HH/FtSRR8gJU7TD34bYCLjdlEtahbcmy4LN05uTpS+ECevCEPvzvZc0skGg== X-Received: by 2002:a1c:4e17:: with SMTP id g23mr274089wmh.38.1591635293576; Mon, 08 Jun 2020 09:54:53 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id s72sm120153wme.35.2020.06.08.09.54.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 09:54:52 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'Philippe_Mathieu-Daud=C3=A9'?= , References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-16-philmd@redhat.com> In-Reply-To: <20200608160044.15531-16-philmd@redhat.com> Subject: RE: [RFC PATCH 15/35] hw/i386/xen/xen-hvm: Emit warning when old code is used Date: Mon, 8 Jun 2020 17:54:49 +0100 Message-ID: <004b01d63db5$87a83110$96f89330$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFYw0U0oKWIX6kmOq5Lq1JhZGgcHAJ29BtBqbYsFpA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Peter Maydell' , 'Sagar Karandikar' , "'Michael S. Tsirkin'" , 'Mark Cave-Ayland' , 'Max Filippov' , 'Alistair Francis' , 'Gerd Hoffmann' , "'Edgar E. Iglesias'" , 'Stefano Stabellini' , 'Magnus Damm' , 'Markus Armbruster' , 'Marcel Apfelbaum' , 'Anthony Perard' , =?utf-8?Q?'Marc-Andr=C3=A9_Lureau'?= , 'David Gibson' , 'Andrzej Zaborowski' , 'Eduardo Habkost' , 'Alistair Francis' , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, 'Stafford Horne' , 'Palmer Dabbelt' , 'Richard Henderson' , "'Daniel P . Berrange'" , 'Thomas Huth' , 'Bastian Koppelmann' , 'Michael Walle' , qemu-ppc@nongnu.org, 'Paolo Bonzini' , 'Aurelien Jarno' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Philippe Mathieu-Daud=C3=A9 > Sent: 08 June 2020 17:00 > To: qemu-devel@nongnu.org > Cc: qemu-arm@nongnu.org; Markus Armbruster ; Max = Filippov ; > Marcel Apfelbaum ; Peter Maydell = ; Michael Walle > ; Edgar E. Iglesias ; = Aurelien Jarno > ; Gerd Hoffmann ; Stafford = Horne ; Andrzej > Zaborowski ; qemu-ppc@nongnu.org; Alistair Francis = ; > Richard Henderson ; Mark Cave-Ayland = ; Marc-Andr=C3=A9 > Lureau ; Daniel P . Berrange = ; qemu- > riscv@nongnu.org; Michael S. Tsirkin ; = xen-devel@lists.xenproject.org; Sagar > Karandikar ; Anthony Perard = ; Palmer Dabbelt > ; Stefano Stabellini ; = Paul Durrant ; Paolo > Bonzini ; Alistair Francis = ; Eduardo Habkost > ; Thomas Huth ; Bastian = Koppelmann paderborn.de>; David Gibson ; Magnus Damm = ; > Philippe Mathieu-Daud=C3=A9 > Subject: [RFC PATCH 15/35] hw/i386/xen/xen-hvm: Emit warning when old = code is used >=20 > This code hasn't been QOM'ified yet. Warn the user. "Based on today's IRC chat, this is a trivial RFC series to anotate pre-qdev/QOM devices so developers using them without knowing they are not QOM'ified yet can realize it and convert them if they have time." So, how should this be coded then? The XenIOState doesn't really qualify = as a 'device', does it? Paul >=20 > Signed-off-by: Philippe Mathieu-Daud=C3=A9 > --- > hw/i386/xen/xen-hvm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) >=20 > diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c > index 82ece6b9e7..a1163b1529 100644 > --- a/hw/i386/xen/xen-hvm.c > +++ b/hw/i386/xen/xen-hvm.c > @@ -31,7 +31,7 @@ > #include "sysemu/xen-mapcache.h" > #include "trace.h" > #include "exec/address-spaces.h" > - > +#include "hw/qdev-deprecated.h" > #include > #include >=20 > @@ -1401,6 +1401,8 @@ void xen_hvm_init(PCMachineState *pcms, = MemoryRegion **ram_memory) > xen_pfn_t ioreq_pfn; > XenIOState *state; >=20 > + qdev_warn_deprecated_function_used(); > + > state =3D g_malloc0(sizeof (XenIOState)); >=20 > state->xce_handle =3D xenevtchn_open(NULL, 0); > -- > 2.21.3 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 17:10:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 17:10:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiLI9-0005pW-Hr; Mon, 08 Jun 2020 17:10:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiLI7-0005pR-FH for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 17:10:31 +0000 X-Inumbo-ID: f25fd204-a9aa-11ea-9282-bc764e2007e4 Received: from smtp-fw-33001.amazon.com (unknown [207.171.190.10]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f25fd204-a9aa-11ea-9282-bc764e2007e4; Mon, 08 Jun 2020 17:10:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591636227; x=1623172227; h=date:from:to:cc:message-id:references:mime-version: in-reply-to:subject; bh=t5Ht9pQ/L15OhRjsj3oBdWbi3godPK4J8lNDSU8Sric=; b=NhgdstKIFBHILGXKhwpX0Ez6RrU+EaB2VpVhkDN/FX0/maWd1ncx1LzJ 8QS/xbluKIHuUth/qcQiO6B1lkL14ifLSAnMOkWyiiXRMCI8xMRtzRSyI Ba5vt/UtG504/9wP466frqPdmRxYSJJ3WyNhBVFGmkINTkr1QyUDN2KBf E=; IronPort-SDR: S8JB7UWD4QsekyIBB/T3lttKcrT1Ne/0DCTZfl8uIv+BINZ1G4WVygkiGFpts8j2A2qHCjsFIu YrHU8J2n5sQQ== X-IronPort-AV: E=Sophos;i="5.73,487,1583193600"; d="scan'208";a="49364832" Subject: Re: [PATCH 04/12] x86/xen: add system core suspend and resume callbacks Received: from sea32-co-svc-lb4-vlan2.sea.corp.amazon.com (HELO email-inbound-relay-1e-57e1d233.us-east-1.amazon.com) ([10.47.23.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 08 Jun 2020 17:10:17 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-57e1d233.us-east-1.amazon.com (Postfix) with ESMTPS id C791814168C; Mon, 8 Jun 2020 17:10:08 +0000 (UTC) Received: from EX13D05UWC001.ant.amazon.com (10.43.162.82) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 17:09:48 +0000 Received: from EX13MTAUWC001.ant.amazon.com (10.43.162.135) by EX13D05UWC001.ant.amazon.com (10.43.162.82) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 17:09:48 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.162.232) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 8 Jun 2020 17:09:47 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id F15BC40832; Mon, 8 Jun 2020 17:09:47 +0000 (UTC) Date: Mon, 8 Jun 2020 17:09:47 +0000 From: Anchal Agarwal To: Boris Ostrovsky Message-ID: <20200608170947.GA4392@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <79cf02631dc00e62ebf90410bfbbdb52fe7024cb.1589926004.git.anchalag@amazon.com> <4b577564-e4c3-0182-2b9e-5f79004f32a1@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , "tglx@linutronix.de" , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 05, 2020 at 05:24:37PM -0400, Boris Ostrovsky wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On 6/3/20 6:40 PM, Agarwal, Anchal wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > On 5/19/20 7:26 PM, Anchal Agarwal wrote: > > > From: Munehisa Kamata > > > > > > Add Xen PVHVM specific system core callbacks for PM suspend and > > > hibernation support. The callbacks suspend and resume Xen > > > primitives,like shared_info, pvclock and grant table. Note that > > > Xen suspend can handle them in a different manner, but system > > > core callbacks are called from the context. > > > > > > I don't think I understand that last sentence. > > > > Looks like it may have cryptic meaning of stating that xen_suspend calls syscore_suspend from xen_suspend > > So, if these syscore ops gets called during xen_suspend do not do anything. Check if the mode is in xen suspend > > and return from there. These syscore_ops are specifically for domU hibernation. > > I must admit, I may have overlooked lack of explanation of some implicit details in the original commit msg. > > > > > So if the callbacks > > > are called from Xen suspend context, return immediately. > > > > > > > > > > + > > > +static int xen_syscore_suspend(void) > > > +{ > > > + struct xen_remove_from_physmap xrfp; > > > + int ret; > > > + > > > + /* Xen suspend does similar stuffs in its own logic */ > > > + if (xen_suspend_mode_is_xen_suspend()) > > > + return 0; > > > With your explanation now making this clearer, is this check really > necessary? From what I see we are in XEN_SUSPEND mode when > lock_system_sleep() lock is taken, meaning that we can't initialize > hibernation. > I see. Sounds plausible. I will fix both the code and commit message for better readability. Thanks for catching this. > > > > + > > > + xrfp.domid = DOMID_SELF; > > > + xrfp.gpfn = __pa(HYPERVISOR_shared_info) >> PAGE_SHIFT; > > > + > > > + ret = HYPERVISOR_memory_op(XENMEM_remove_from_physmap, &xrfp); > > > + if (!ret) > > > + HYPERVISOR_shared_info = &xen_dummy_shared_info; > > > + > > > + return ret; > > > +} > > > + > > > +static void xen_syscore_resume(void) > > > +{ > > > + /* Xen suspend does similar stuffs in its own logic */ > > > + if (xen_suspend_mode_is_xen_suspend()) > > > + return; > > > + > > > + /* No need to setup vcpu_info as it's already moved off */ > > > + xen_hvm_map_shared_info(); > > > + > > > + pvclock_resume(); > > > + > > > + gnttab_resume(); > > > > > > Do you call gnttab_suspend() in pm suspend path? > > No, since it does nothing for HVM guests. The unmap_frames is only applicable for PV guests right? > > > You should call it nevertheless. It will decide whether or not anything > needs to be done. Will fix it in V2. > > > -boris > Thanks, Anchal > From xen-devel-bounces@lists.xenproject.org Mon Jun 08 17:16:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 17:16:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiLNi-000609-70; Mon, 08 Jun 2020 17:16:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiLNh-000603-II for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 17:16:17 +0000 X-Inumbo-ID: c2423e6c-a9ab-11ea-b29c-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c2423e6c-a9ab-11ea-b29c-12813bfff9fa; Mon, 08 Jun 2020 17:16:15 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: DUjRROethOUfUUaLFxYbhoWQr5QhWOnF6kthTxsMOef7AYgEgTbtHAthcUePuDyo0cWtsQ1GVX 7Jpb+fDG/YGSK829BhrRtgm6rdQv/IJNlEKqdX6AdvaRmntP5n5V652uJ8fKfWOcE24kyTh3R6 G+5p02vAcFAoy8sze7Td0KwYgT3aR6Grlq7dPcZM7+rc+FPbna9PqiPAkHMqdPms75Y8xZ3ML9 7MzKz6GdcZMrD5FWBW5GpQ3JsOI5seeYWPjW5gAYGRdynGNvG+iuFR1YjsHBKf8kEq4R8P2+Y6 /Ac= X-SBRS: 2.7 X-MesageID: 19519212 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19519212" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14] docs: Minor build improvements Date: Mon, 8 Jun 2020 18:15:56 +0100 Message-ID: <20200608171556.27847-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Jan Beulich , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Don't use "set -x" for the figs rule. It doesn't take effect in the recursive make environment. Turn the HTML manpage comments into makefile comments, not shell comments. This saves 3x shell invocations per manpage. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall For 4.14. Trivial, and docs related. --- docs/Makefile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/Makefile b/docs/Makefile index 3eae2dae60..8de1efb6f5 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -58,7 +58,7 @@ txt: $(DOC_TXT) .PHONY: figs figs: ifneq ($(FIG2DEV),) - set -x; $(MAKE) -C figs + $(MAKE) -C figs else @echo "fig2dev (transfig) not installed; skipping figs." endif @@ -105,12 +105,12 @@ else endif # HTML manpages +# sed used to fix up links between man-pages +# 1) L -> L +# 2) -> html/man/%.$(1).html: man/%.$(1).pod Makefile ifneq ($(POD2HTML),) @$(INSTALL_DIR) $$(@D) - # Fix up links between man-pages - # 1) L -> L - # 2) -> sed -r -e 's%L<([^>]+)\(([1-9])\)>%L<\1(\2)|relative:\1.\2.html>%g' $$< | \ $(POD2HTML) | \ sed -r -e 's%( href=")relative:%\1%g' > $$@ -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 17:31:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 17:31:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiLbp-0007p3-Ui; Mon, 08 Jun 2020 17:30:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiLbo-0007oy-L9 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 17:30:52 +0000 X-Inumbo-ID: ccbe40e6-a9ad-11ea-b2a0-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ccbe40e6-a9ad-11ea-b2a0-12813bfff9fa; Mon, 08 Jun 2020 17:30:52 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 417F2206A4; Mon, 8 Jun 2020 17:30:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591637451; bh=vlCR5/ExWqtewebKOTcJOXQkQ+zVe/VeVp0XsbZNGWE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WlB9cv5dfhHaUhAt8Kom2paoC803v6q7j/baG6PpnTJYundKfVWZyLVQN+pVceImt pJjOqp9t2aVAjUtuGaZt23LWg3xCf9gmIaJNpQ4vIFuowqy8uKiSQ8jN3MxXW4zlKA hFrgDGFEf1twm2j9xn8BK/GXGQbveJ/8DGTKJCCo= Date: Mon, 8 Jun 2020 10:30:50 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH for-4.14] xen/arm: mm: Access a PT entry before the table is unmapped In-Reply-To: <20200607155154.15928-1-julien@xen.org> Message-ID: References: <20200607155154.15928-1-julien@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Julien Grall , Stefano Stabellini , Volodymyr Babchuk , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sun, 7 Jun 2020, Julien Grall wrote: > From: Julien Grall > > xen_pt_next_level() will retrieve the MFN from the entry right after the > page-table has been unmapped. > > After calling xen_unmap_table(), there is no guarantee the mapping will > still be valid. Depending on the implementation, this may result to a > data abort in Xen. > > Re-order the code to retrieve the MFN before the table is unmapped. > > Fixes: 53abb9a1dcd9 ("xen/arm: mm: Rework Xen page-tables walk during update") > Signed-off-by: Julien Grall > > --- > > I spotted this issue while reworking how page-tables are mapped on Arm64 > during early boot. However the problem should be already there on Arm32. > > I am actually quite amazed we haven't seen any crash on Arm32 because > there is no direct map. So the mapping will not exist after calling > xen_unmap_table(). > > I suspect this works because unmap_domain_page() doesn't flush the > TLBs. So the TLB still likely have the entry cached (joy!). \0/ Damn! Reviewed-by: Stefano Stabellini > This patch is a candidate for Xen 4.14 and should also be backported. > --- > xen/arch/arm/mm.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index 1b14f4934570..9e2ff7c8005d 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -1036,6 +1036,7 @@ static int xen_pt_next_level(bool read_only, unsigned int level, > { > lpae_t *entry; > int ret; > + mfn_t mfn; > > entry = *table + offset; > > @@ -1053,8 +1054,10 @@ static int xen_pt_next_level(bool read_only, unsigned int level, > if ( lpae_is_mapping(*entry, level) ) > return XEN_TABLE_SUPER_PAGE; > > + mfn = lpae_get_mfn(*entry); > + > xen_unmap_table(*table); > - *table = xen_map_table(lpae_get_mfn(*entry)); > + *table = xen_map_table(mfn); > > return XEN_TABLE_NORMAL_PAGE; > } > -- > 2.17.1 > From xen-devel-bounces@lists.xenproject.org Mon Jun 08 17:37:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 17:37:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiLiP-00084z-Le; Mon, 08 Jun 2020 17:37:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiLiN-00084u-Ls for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 17:37:39 +0000 X-Inumbo-ID: bf56c058-a9ae-11ea-b2a1-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id bf56c058-a9ae-11ea-b2a1-12813bfff9fa; Mon, 08 Jun 2020 17:37:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591637858; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=IaI75RxTU9jtVvOtNWo4VByTn1tODzTplByzyDcoNo8=; b=h2VtUen9ONMh1tp6jdeOk6k6SYSZNm6jWNcGkbGPM9EqYbDCkPMxo3BtVXWMI8seFlkpPR hN7daf3I2iofOp7qcKOufOciZNo8x4KCmGDnUotUp93opjH0jkqEj403Ctv2zzuYiVXSga iSPqoOAIJ7NkbF3/K4ckn/MYuL3fRtg= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-23-1jjJnEhSMdOvBQeIovc9Lg-1; Mon, 08 Jun 2020 13:37:36 -0400 X-MC-Unique: 1jjJnEhSMdOvBQeIovc9Lg-1 Received: by mail-wm1-f69.google.com with SMTP id c4so67732wmd.0 for ; Mon, 08 Jun 2020 10:37:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=IaI75RxTU9jtVvOtNWo4VByTn1tODzTplByzyDcoNo8=; b=iEB79jIt1GHMWgFT8NKcMMiy+Xmrk4Xg+ibG8BQngfQ202mMvmPbMZWyALVFoq8LEK lhjaURbF5AZyMdW0RuDn+GSmve0M41T5ZHh4tFVP1cBgza1qwzBEIrQouxvCSFYvv0O+ zSNIyr0yK3+m4/+ebkL2N54PKCPFPvEZa1G8RnprpkdqUeQfVZBLW9MU8ukrpcXNDvDg e2OS1Wpt60aNhQ7xaYghi8SoPg5Jv/7wcHScfLR91Rr2poJoMBnC/PdcFhfzHy4WB7oI uZFSmD5FCTlHy3DzZtIQ15pFbGzu5WfqrbDr5Ln07ic/0vEB+nUI9AY00skQaH+RAH15 wyZA== X-Gm-Message-State: AOAM532e/Dcka7vA9hmA+Sk6DEPZVBgpKoYoD2cS1YJJ4YZIvimnFvnP 4jgbn5Hhpu3nIZ+ixrK8I6d7HYx5sgKpCmIFrGMMn3v28YAHBcv5pFocvBqrsvrP5Shb/b+D/m1 RJXo/JM/x7RcwboC3MlluxJ/wjiw= X-Received: by 2002:a1c:c3d7:: with SMTP id t206mr404314wmf.69.1591637855626; Mon, 08 Jun 2020 10:37:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2PP8Jam0jrAYWvl6HUndlzbkmQydkF0EZCtZp+EtGb77Su/VpiOiSTjN4I5rK9hrbErrKaQ== X-Received: by 2002:a1c:c3d7:: with SMTP id t206mr404296wmf.69.1591637855427; Mon, 08 Jun 2020 10:37:35 -0700 (PDT) Received: from [192.168.1.38] (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id z9sm214694wmi.41.2020.06.08.10.37.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 10:37:34 -0700 (PDT) Subject: Re: [RFC PATCH 15/35] hw/i386/xen/xen-hvm: Emit warning when old code is used To: paul@xen.org, qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-16-philmd@redhat.com> <004b01d63db5$87a83110$96f89330$@xen.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: Date: Mon, 8 Jun 2020 19:37:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <004b01d63db5$87a83110$96f89330$@xen.org> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Peter Maydell' , 'Sagar Karandikar' , "'Michael S. Tsirkin'" , 'Mark Cave-Ayland' , 'Max Filippov' , 'Alistair Francis' , 'Gerd Hoffmann' , "'Edgar E. Iglesias'" , 'Stefano Stabellini' , 'Magnus Damm' , 'Markus Armbruster' , 'Marcel Apfelbaum' , 'Anthony Perard' , =?UTF-8?Q?=27Marc-Andr=c3=a9_Lureau=27?= , 'David Gibson' , 'Andrzej Zaborowski' , 'Eduardo Habkost' , 'Alistair Francis' , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, 'Stafford Horne' , 'Palmer Dabbelt' , 'Richard Henderson' , "'Daniel P . Berrange'" , 'Thomas Huth' , 'Bastian Koppelmann' , 'Michael Walle' , qemu-ppc@nongnu.org, 'Paolo Bonzini' , 'Aurelien Jarno' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/8/20 6:54 PM, Paul Durrant wrote: >> -----Original Message----- >> From: Philippe Mathieu-Daudé >> >> This code hasn't been QOM'ified yet. Warn the user. > > "Based on today's IRC chat, this is a trivial RFC series > to anotate pre-qdev/QOM devices so developers using them > without knowing they are not QOM'ified yet can realize > it and convert them if they have time." > > So, how should this be coded then? The XenIOState doesn't really qualify as a 'device', does it? There is a pending question whether Machines are Devices or not. Xen is a tricky case, it is created as a Q35 machine overloaded with Xen features. >> @@ -1401,6 +1401,8 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory) >> xen_pfn_t ioreq_pfn; >> XenIOState *state; >> >> + qdev_warn_deprecated_function_used(); >> + >> state = g_malloc0(sizeof (XenIOState)); XenIOState is indeed not a device, it is allocated once, we won't gain anything making it a QOM object... so this patch is incorrect. Sorry for the noise :S Regards, Phil. >> >> state->xce_handle = xenevtchn_open(NULL, 0); >> -- >> 2.21.3 > > From xen-devel-bounces@lists.xenproject.org Mon Jun 08 18:26:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 18:26:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiMT8-0003wV-IO; Mon, 08 Jun 2020 18:25:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiMT6-0003wQ-3O for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 18:25:56 +0000 X-Inumbo-ID: 7cc0dec0-a9b5-11ea-b2a6-12813bfff9fa Received: from mo4-p00-ob.smtp.rzone.de (unknown [81.169.146.220]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7cc0dec0-a9b5-11ea-b2a6-12813bfff9fa; Mon, 08 Jun 2020 18:25:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591640753; s=strato-dkim-0002; d=aepfle.de; h=Message-Id:Date:Subject:Cc:To:From:X-RZG-CLASS-ID:X-RZG-AUTH:From: Subject:Sender; bh=uMEUQfI4irOVxh7fDZjh1Ky9H+2S+8wFBN2BwnK7us4=; b=LUFfxR2/XVw9sA0ze0sQMrmuXovLKGDyqdcujlQufmd3ou1bfEfu8LDbkZ0kQJVDWG pFREc4I4XossXGKvWcI7k2IFZSIyL/bECr16TjCELr/Hq6EUBjURhpJpZvAo9pl2V2DW 4e4f8h99ogn+MxcoOto0JXU47baYdmkPZxKL9IpXmDbRUMj06US0qYqjKnruOBhI++bD LGhjY1FF7lsHb+1Lc09C6KyfO9oeFuys73LJuZMlMJWZP8rwftxXPuExQp8RCkqWuD8x A0V6jPj7noFQy7zRy1hR927mzU4s9GbHyhdSFdD8ZPXlnfc46/WxHTdsEyDdJ0lVDApy Z47A== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QXkBR9MXjAuzBW/OdlBZQ4AHSS3GpKjw==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w58IPgHjl (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) (Client did not present a certificate); Mon, 8 Jun 2020 20:25:42 +0200 (CEST) From: Olaf Hering To: xen-devel@lists.xenproject.org Subject: [PATCH v2] libxl__prepare_sockaddr_un Date: Mon, 8 Jun 2020 20:25:38 +0200 Message-Id: <20200608182539.29415-1-olaf@aepfle.de> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Olaf Hering , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" libxl: remove usage of strncpy from libxl__prepare_sockaddr_un The runtime check for the length of path already prevents malfunction. But gcc does not detect this runtime check and reports incorrect usage of strncpy. Remove the usage of strncpy and work directly with the calculated path length. In file included from /usr/include/string.h:495, from libxl_internal.h:38, from libxl_utils.c:20: In function 'strncpy', inlined from 'libxl__prepare_sockaddr_un' at libxl_utils.c:1262:5: /usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Olaf Hering --- tools/libxl/libxl_utils.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c index f360f5e228..40885794c9 100644 --- a/tools/libxl/libxl_utils.c +++ b/tools/libxl/libxl_utils.c @@ -1252,14 +1252,16 @@ int libxl__prepare_sockaddr_un(libxl__gc *gc, struct sockaddr_un *un, const char *path, const char *what) { - if (sizeof(un->sun_path) <= strlen(path)) { + size_t len = strlen(path); + + if (sizeof(un->sun_path) <= len) { LOG(ERROR, "UNIX socket path '%s' is too long for %s", path, what); - LOG(DEBUG, "Path must be less than %zu bytes", sizeof(un->sun_path)); + LOG(DEBUG, "Path of len %zu must be less than %zu bytes", len, sizeof(un->sun_path)); return ERROR_INVAL; } memset(un, 0, sizeof(struct sockaddr_un)); un->sun_family = AF_UNIX; - strncpy(un->sun_path, path, sizeof(un->sun_path)); + memcpy(un->sun_path, path, len); return 0; } From xen-devel-bounces@lists.xenproject.org Mon Jun 08 18:51:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 18:51:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiMrF-0006Pi-Fl; Mon, 08 Jun 2020 18:50:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiMrE-0006Pd-89 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 18:50:52 +0000 X-Inumbo-ID: f9604d78-a9b8-11ea-b2a8-12813bfff9fa Received: from aserp2120.oracle.com (unknown [141.146.126.78]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f9604d78-a9b8-11ea-b2a8-12813bfff9fa; Mon, 08 Jun 2020 18:50:51 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 058IlNaB095795; Mon, 8 Jun 2020 18:50:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=l1nmDwr0dMNjA5gGFxnUo801EQzoxa4EkXtmbjrE/M8=; b=0h60S9doYNYNWbu72+rOca8l4vJx55hsbRpOjoLQHKZmvBMfhVwIB0Fts3XbWutOnnY+ Z7KWWn1rx4zwzdrDflbO3oX0bY07KeVwvG89qvQ8iBmveKXuJqi4KI+Wua/erQOQ7Eox 9ZWb7yajT4gOHRv9xKaV0arXt99f8o4kyEqkCw7W8K6+QtW8gqDdEPbLlQxYN3b9Vgtk zXacB4iySe5omyAlGtCRLbiZ6Y2GHERSu7vHBpYsg3w5LpG65Ikj0shJVikSdFxvH2KJ 2jo+zTs2IRpnfdYKJxfqNeWzP5sKGYyifT1XIWH4qMfAJPdlTMee2110esKW7HiaXfsW vQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 31g33m0f5k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 08 Jun 2020 18:50:03 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 058IleAv088142; Mon, 8 Jun 2020 18:50:02 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 31gn2vkjyg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Jun 2020 18:50:02 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 058InxT0026480; Mon, 8 Jun 2020 18:49:59 GMT Received: from [10.39.231.199] (/10.39.231.199) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2020 11:49:59 -0700 Subject: Re: [PATCH 03/12] x86/xen: Introduce new function to map HYPERVISOR_shared_info on Resume To: Anchal Agarwal References: <529f544a64bb93b920bf86b1d3f86d93b0a4219b.1589926004.git.anchalag@amazon.com> <72989b50-0c13-7a2b-19e2-de4a3646c83f@oracle.com> <20200604230307.GB25251@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <9644a5f1-e1f8-5fe1-3135-cc6b4baf893b@oracle.com> <20200608165235.GA1330@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <311de66b-68fb-f9f3-910e-6fa5eeb648bb@oracle.com> Date: Mon, 8 Jun 2020 14:49:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200608165235.GA1330@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9646 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0 bulkscore=0 adultscore=0 mlxlogscore=999 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006080133 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9646 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 spamscore=0 cotscore=-2147483648 malwarescore=0 phishscore=0 mlxscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006080133 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: eduval@amazon.com, len.brown@intel.com, peterz@infradead.org, benh@kernel.crashing.org, x86@kernel.org, linux-mm@kvack.org, pavel@ucw.cz, hpa@zytor.com, sstabellini@kernel.org, kamatam@amazon.com, mingo@redhat.com, xen-devel@lists.xenproject.org, sblbir@amazon.com, axboe@kernel.dk, konrad.wilk@oracle.com, bp@alien8.de, tglx@linutronix.de, jgross@suse.com, netdev@vger.kernel.org, linux-pm@vger.kernel.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, vkuznets@redhat.com, davem@davemloft.net, dwmw@amazon.co.uk, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/8/20 12:52 PM, Anchal Agarwal wrote: > >>>>> +void xen_hvm_map_shared_info(void) >>>>> +{ >>>>> + xen_hvm_init_shared_info(); >>>>> + if (shared_info_pfn) >>>>> + HYPERVISOR_shared_info = __va(PFN_PHYS(shared_info_pfn)); >>>>> +} >>>>> + >>>> AFAICT it is only called once so I don't see a need for new routine. >>>> >>>> >>> HYPERVISOR_shared_info can only be mapped in this scope without refactoring >>> much of the code. >> >> Refactoring what? All am suggesting is >> > shared_info_pfn does not seem to be in scope here, it's scope is limited > to enlighten_hvm.c. That's the reason I introduced a new function there. OK, that's a good point. -boris From xen-devel-bounces@lists.xenproject.org Mon Jun 08 18:55:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 18:55:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiMvl-0006aW-1i; Mon, 08 Jun 2020 18:55:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiMvj-0006Zl-Ir for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 18:55:31 +0000 X-Inumbo-ID: 9cf7a4fe-a9b9-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9cf7a4fe-a9b9-11ea-b7bb-bc764e2007e4; Mon, 08 Jun 2020 18:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=95Lsi7qQFpchNBAc6gCX8KGBd9LzaLupZzs3pTSiyUI=; b=BPncGJAhKmBYx/zohsRBs1IPH AdVGH+Od7EZ4ZAiKjQkoj4hvl9S8t+IEM/OHOo3Xgp6/5b4nh9M6KXlX+0oe83CgodErTvTTZgBfS h68o5qfQ1vuoEPpMlk/6yLUYmk4RrnHvz5hpvx1VYXyUlceunirodf3qwjpP02xZHhVb0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiMvd-0006MI-B6; Mon, 08 Jun 2020 18:55:25 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiMvc-0008Ez-VP; Mon, 08 Jun 2020 18:55:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiMvc-0004CZ-Uk; Mon, 08 Jun 2020 18:55:24 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150926: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=03dc5f00f66e9c29afdfc9a72e4e6d70ea50b191 X-Osstest-Versions-That: xen=75131ad75bb3c91717b5dfda6881e61c52bfd22e From: osstest service owner Date: Mon, 08 Jun 2020 18:55:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150926 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150926/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 03dc5f00f66e9c29afdfc9a72e4e6d70ea50b191 baseline version: xen 75131ad75bb3c91717b5dfda6881e61c52bfd22e Last test of basis 150922 2020-06-08 09:02:44 Z 0 days Failing since 150924 2020-06-08 15:02:21 Z 0 days 2 attempts Testing same since 150926 2020-06-08 16:00:24 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Ian Jackson jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 75131ad75b..03dc5f00f6 03dc5f00f66e9c29afdfc9a72e4e6d70ea50b191 -> smoke From xen-devel-bounces@lists.xenproject.org Mon Jun 08 19:54:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 19:54:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiNqq-0003NI-QX; Mon, 08 Jun 2020 19:54:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiNqp-0003ND-93 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 19:54:31 +0000 X-Inumbo-ID: dd40cc72-a9c1-11ea-b2b2-12813bfff9fa Received: from mail-ej1-f66.google.com (unknown [209.85.218.66]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dd40cc72-a9c1-11ea-b2b2-12813bfff9fa; Mon, 08 Jun 2020 19:54:30 +0000 (UTC) Received: by mail-ej1-f66.google.com with SMTP id f7so19730182ejq.6 for ; Mon, 08 Jun 2020 12:54:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=+sqv/n+dHdqVQBBv8HoeSPhIX6ntoKrWvEWJ5bo+JBY=; b=tbns1qQ7FlY18q+sWAGMpUedxC32xdLmTjzsHSZuB0KSjDU5VQbzSvfJQgD+G+/vom FjDY/hCvF8RUviUUbVQiv9z3KF8C1cHIHaHcTz4fGNbXA1ZfnY1F6ArheJLyYbbLCKEV AnLd5gVFle2dWlNhIDupusBTdqJA9olySiZykZwQF/Q9/MqWGKUCrXL1Pi9zhOHGXOZA CnN5szYEGpW2Jwz2AQPeeMvRWE8HzCbmcafDMnYAloTKprUuqivtcMMTBnkRX7S5mpI5 P5kMIhOX87tfar6Gbq6URuOSk+jdNYsvg6HUm59ZsMb1D3PcoZ0QSrLUINMNMdpiXcy5 EEkA== X-Gm-Message-State: AOAM532Xh//6c417l0jtEMd9i/8wUjfT1146b9hcgcPi1SvZ5TjXMs77 pPVRi1Gu8KMDF/hnIKKpe1o= X-Google-Smtp-Source: ABdhPJyCrlier8KckyArgpVfsoeX+3W0TZBdF5noENbZMiCB7EHb731EzfTxbYKJrA1Y2+nQa+g7kQ== X-Received: by 2002:a17:906:d9dc:: with SMTP id qk28mr14717135ejb.6.1591646068901; Mon, 08 Jun 2020 12:54:28 -0700 (PDT) Received: from thl530.multi.box (p5791d09b.dip0.t-ipconnect.de. [87.145.208.155]) by smtp.gmail.com with ESMTPSA id bg21sm11672524ejb.90.2020.06.08.12.54.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2020 12:54:28 -0700 (PDT) Date: Mon, 8 Jun 2020 21:54:21 +0200 From: Thomas Huth To: Philippe =?UTF-8?B?TWF0aGlldS1EYXVkw6k=?= Subject: Re: [RFC PATCH 22/35] hw/m68k/mcf520x: Emit warning when old code is used Message-ID: <20200608215421.6322016c@thl530.multi.box> In-Reply-To: <20200608160044.15531-23-philmd@redhat.com> References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-23-philmd@redhat.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , qemu-devel@nongnu.org, Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?B?TWFyYy1BbmRyw6k=?= Lureau , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Paolo Bonzini , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Am Mon, 8 Jun 2020 18:00:31 +0200 schrieb Philippe Mathieu-Daud=C3=A9 : > This code hasn't been QOM'ified yet. Warn the user. >=20 > Signed-off-by: Philippe Mathieu-Daud=C3=A9 > --- > hw/m68k/mcf5206.c | 5 +++++ > hw/m68k/mcf5208.c | 3 +++ > 2 files changed, 8 insertions(+) >=20 > diff --git a/hw/m68k/mcf5206.c b/hw/m68k/mcf5206.c > index a2fef04f8e..ec0d176674 100644 > --- a/hw/m68k/mcf5206.c > +++ b/hw/m68k/mcf5206.c > @@ -16,6 +16,7 @@ > #include "qemu/timer.h" > #include "hw/ptimer.h" > #include "sysemu/sysemu.h" > +#include "hw/qdev-deprecated.h" > =20 > /* General purpose timer module. */ > typedef struct { > @@ -144,6 +145,8 @@ static m5206_timer_state > *m5206_timer_init(qemu_irq irq) { > m5206_timer_state *s; > =20 > + qdev_warn_deprecated_function_used(); > + > s =3D g_new0(m5206_timer_state, 1); > s->timer =3D ptimer_init(m5206_timer_trigger, s, > PTIMER_POLICY_DEFAULT); s->irq =3D irq; > @@ -566,6 +569,8 @@ qemu_irq *mcf5206_init(MemoryRegion *sysmem, > uint32_t base, M68kCPU *cpu) m5206_mbar_state *s; > qemu_irq *pic; > =20 > + qdev_warn_deprecated_function_used(); > + > s =3D g_new0(m5206_mbar_state, 1); Ok, it's quite obvious what you refer to here... > memory_region_init_io(&s->iomem, NULL, &m5206_mbar_ops, s, > diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c > index 2ab9701ad6..72627f6833 100644 > --- a/hw/m68k/mcf5208.c > +++ b/hw/m68k/mcf5208.c > @@ -26,6 +26,7 @@ > #include "hw/sysbus.h" > #include "elf.h" > #include "exec/address-spaces.h" > +#include "hw/qdev-deprecated.h" > =20 > #define SYS_FREQ 166666666 > =20 > @@ -191,6 +192,8 @@ static void mcf5208_sys_init(MemoryRegion > *address_space, qemu_irq *pic) m5208_timer_state *s; > int i; > =20 > + qdev_warn_deprecated_function_used(); > + > /* SDRAMC. */ > memory_region_init_io(iomem, NULL, &m5208_sys_ops, NULL, > "m5208-sys", 0x00004000); memory_region_add_subregion(address_space, > 0xfc0a8000, iomem); ... but it is not so obvious what you refer to here. I think that new function should maybe have a "char *what" parameter that contains the name of the struct you refer to. Or at least add a comment in front of the function with a short description? Thomas From xen-devel-bounces@lists.xenproject.org Mon Jun 08 19:55:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 19:55:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiNrq-0003Q6-4O; Mon, 08 Jun 2020 19:55:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiNro-0003Py-ED for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 19:55:32 +0000 X-Inumbo-ID: 0209e778-a9c2-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0209e778-a9c2-11ea-bb8b-bc764e2007e4; Mon, 08 Jun 2020 19:55:31 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id l12so15938038ejn.10 for ; Mon, 08 Jun 2020 12:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zkqKSfKqHvpsIvDxZ4XjYXdsn1V9rmmhwnv/LiNryco=; b=O85BZLnCglpx57BmQdIiQ7BQU9efA7OfNIqIlK2n9FPnGQk5BGct6VUDCBVwqHepS5 FBCwBr/uHKz192iq0VKegJpkSkNsZP2UWgrLo83llDxLH0KzyUgzDrAkW27JAMM95EGi 9YAoa41+cFPIMq+42TRTRPiLm0weEazeEXUN/j0HxobVrDtmdWJe0AcOw1IrjK0ALYP5 nBklzVFPTKpz9h+F3QmDDszICO8c1NC/nHxHmKta47IPIBenmrM5KqQP8Pth3MOIgtGG uOXAjC/lFO5sUlzLdtD9x//7YhGxODFCm/oX+IYq7JSzCVFVmlj88/3dzcigqZ4XP3sy tKlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zkqKSfKqHvpsIvDxZ4XjYXdsn1V9rmmhwnv/LiNryco=; b=iTB4VIwCa5nsQf9TTLh19+IcWMfs3bpSIZf9WI8sVhiCRLiBhX4hPkP8NVj8qnh2PR FoFhalUfxS7YRgGrpkdkVazZn+JmdQg7RvUTPzsofgbnwPrXL1ijq3Nu8Wgz9mkzBS1/ 7W05l5ICh4sSLtamBq5rgFXkMSmIjIfpHC8quvg2q+OjZgKo/pJhIw87aIc+6iFLkiML Lr+w8faAH21l1EIQKdu6MBdKRCj90ljxaF+cXLt/+fjESy/w9Cs06QUDVU9Kx4aqPhQc HNnqOdbAg8z7Ic+myn07ivC4IWqwV1fmaLnj34TBeCWe0iUTuqj6vZX0e9r26QlpYyWc 5aJw== X-Gm-Message-State: AOAM5337Z+Js2UELTcKDr1pE0tSRQ4eY6ihYPOTyy6nOq5vjCZx2SyWn a6HtMeg92NihUeeyzlY02bszi49S1H0= X-Google-Smtp-Source: ABdhPJwFrul+PRfCCj6Q5AGagEd1GOAdb1vxZrv1JRwwF8IBrdwEzU1eIr0ArQbezcieucel22V/fw== X-Received: by 2002:a17:906:c10f:: with SMTP id do15mr23191835ejc.249.1591646130350; Mon, 08 Jun 2020 12:55:30 -0700 (PDT) Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com. [209.85.128.43]) by smtp.gmail.com with ESMTPSA id m3sm13278756ede.58.2020.06.08.12.55.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 12:55:28 -0700 (PDT) Received: by mail-wm1-f43.google.com with SMTP id d128so837906wmc.1 for ; Mon, 08 Jun 2020 12:55:27 -0700 (PDT) X-Received: by 2002:a7b:c5c7:: with SMTP id n7mr303568wmk.77.1591646127329; Mon, 08 Jun 2020 12:55:27 -0700 (PDT) MIME-Version: 1.0 References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> In-Reply-To: From: Tamas K Lengyel Date: Mon, 8 Jun 2020 13:54:51 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Razvan Cojocaru Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Andrei LUTAS , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?B?TWloYWkgRG9uyJt1?= , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru wrote: > > On 6/8/20 6:55 PM, Jan Beulich wrote: > > On 03.06.2020 17:07, Roger Pau Monn=C3=A9 wrote: > >> On Wed, Jun 03, 2020 at 06:52:37AM -0600, Tamas K Lengyel wrote: > >>> For the last couple years we have received numerous reports from user= s of > >>> monitor vm_events of spurious guest crashes when using events. In par= ticular, > >>> it has observed that the problem occurs when vm_events are being disa= bled. The > >>> nature of the guest crash varied widely and has only occured occasion= ally. This > >>> made debugging the issue particularly hard. We had discussions about = this issue > >>> even here on the xen-devel mailinglist with no luck figuring it out. > >>> > >>> The bug has now been identified as a race-condition between register = event > >>> handling and disabling the monitor vm_event interface. The default be= havior > >>> regarding emulation of register write events is changed so that they = get > >>> postponed until the corresponding vm_event handler decides whether to= allow such > >>> write to take place. Unfortunately this can only be implemented by pe= rforming the > >>> deny/allow step when the vCPU gets scheduled. > >>> > >>> Due to that postponed emulation of the event if the user decides to p= ause the > >>> VM in the vm_event handler and then disable events, the entire emulat= ion step > >>> is skipped the next time the vCPU is resumed. Even if the user doesn'= t pause > >>> during the vm_event handling but exits immediately and disables vm_ev= ent, the > >>> situation becomes racey as disabling vm_event may succeed before the = guest's > >>> vCPUs get scheduled with the pending emulation task. This has been pa= rticularly > >>> the case with VMS that have several vCPUs as after the VM is unpaused= it may > >>> actually take a long time before all vCPUs get scheduled. > >>> > >>> In this patch we are reverting the default behavior to always perform= emulation > >>> of register write events when the event occurs. To postpone them can = be turned > >>> on as an option. In that case the user of the interface still has to = take care > >>> of only disabling the interface when its safe as it remains buggy. > >>> > >>> Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm= _event > >>> reply'). > >>> > >>> Signed-off-by: Tamas K Lengyel > >> > >> Thanks! > >> > >> Reviewed-by: Roger Pau Monn=C3=A9 > >> > >> I would like to get some input from Bitdefender really, and whether > >> they are fine with this approach. > > Hello, > > Not really my call to make anymore, but I do have a few notes. > > First, IIRC the problem stems from the initial choice to have the > vm_event data allocated on-demand when first subscribing to events. The > proper solution (since this patch doesn't actually fix the problem), > IMHO, would be for the vm_event data to _always_ exist, and instead of > relying on the value of its pointer to check if there are event > subscribers, we could just check the emulation flags individually and > never miss a pending emulated something again. I did try to go that way > in the beginning, but it has reasonably been objected that we should cut > back on using hypervisor memory unnecessarily, hence we got at this point= . > > Secondly, I see no reason why we couldn't adapt to the new default > behaviour provided that the old behaviour continues to work _exactly_ as > before. > > And last but not least, the proper sequence is: 1. unsubscribe from > register write events, 2. process all events "still in the chamber" > (keep checking the ring buffer for a while), 3. detach from the guest > (disable the vm_event subsystem). Not ideal perhaps (in that it's not > guaranteed that a VCPU won't resume after a longer period than our > timeout), but if the sequence is followed there should be no guest hangs > or crashes (at least none that we or our clients have observed so far). Incorrect. That's not enough. You also have to wait for all the vCPUs to get scheduled before disabling vm_event or otherwise the emulation is skipped entirely. Please read the patch message. If the user decides to disable vm_event after getting a CR3 event delivered, the CR3 never gets updated and results in the guest crashing in unpredictable ways. Same happens with all the other registers. > > So in short, I think there's a better fix for this by simply not > allocating the vm_event memory on-demand anymore and never having to > deal with lost pending emulations again. It should also decrease code > complexity by a tiny bit. Then again, as stated at the beginning of this > message, that's just a recommendation. Since only you guys use this feature I'm going to wait for a fix. Until then, the default behavior should be restored so this buggy behavior doesn't affect anyone else. You can still turn it on, its just not going to be on for vm_event by default. I don't particularly care what fix is there since only you guys use it. If you don't mind that there is this buggy behavior because you never disable vm_event once you activate it then that's that. Cheers, Tamas From xen-devel-bounces@lists.xenproject.org Mon Jun 08 20:03:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 20:03:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiNzH-0004Qj-Vs; Mon, 08 Jun 2020 20:03:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiNzG-0004QP-JD for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 20:03:14 +0000 X-Inumbo-ID: 1266dad0-a9c3-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1266dad0-a9c3-11ea-bb8b-bc764e2007e4; Mon, 08 Jun 2020 20:03:08 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id l11so18838084wru.0; Mon, 08 Jun 2020 13:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v5NHBLFIrvrnQIUGtRyTRxnMHCx8z8QMwiCN/AFz6Lk=; b=P0Dgxi+IsDRGO+Bk3lyRDQgRKlZp+Ci9Pk6gL3G5cwt53aEKy723gSSrVrEwCk/X2X FAKbF2EZKYpmI6KLabj8CLrpFraCuLEHxjsZiDiozTniNWHZSpV/IisJcPc5OBlGNbqZ YskelP4i5A5wJuI5tJBe+4ZtPfCB1+MPUwU9sR5XMD+LyoymmFHBqPlgN/59KfRhEtvm WOdPrOTgAzEcd/gmrl89wVBozhR6+T5k6yv/2z1SWq95nxq5LHHnR0fL/438q+O/O35s 4bsmMc//JR1VioXooxoKgDNMnDCVa0eZcVBG1OV8jrfb8dIl1g674CT0wf9uQWgTvzQT oZrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v5NHBLFIrvrnQIUGtRyTRxnMHCx8z8QMwiCN/AFz6Lk=; b=e/Hy8QSV/A6z/cyo2cSDMNfTqun7oNG8q/Yk+R08E3l5Bug0A8XmfHLcUaQx3upX2J 2dYdSpFoozSWpxg6xlldeojhoYSZTWuhhJlux50UW/d0xD0N5rzmowpLw4MvchuuEKy3 WdNlbjfkEfXWklidETgGOWP8nmNruiqnalnmMhfWXb4Fwo0uPRC1a8IhNhu8u8JbTx+1 rKjxAiVJXiGDM5YDt4/HVC+zT6EQb4EZfvmKVZkOi9A6SdlwFdrk85B7rEGX5HCd27YD zQ8eFD/kEBzoNc6MNm54QJk0E9DDA1KjFAoXuLvPpAuoSuaQKu+ZaSbNGvp2Cwu02zmh 5FYA== X-Gm-Message-State: AOAM531Ln2kwW/XFgmRZr3ShM0uI56BfGPSJkTgnp6fvZ8CGf3ur4g6I 3kdgbXAXAfwJ0lsLRBnGvWsMHzgyHtV0uZhp+7b6LqIvDLk= X-Google-Smtp-Source: ABdhPJz0bwLjqoGXcyBts+PvnSrh0xcHjW2k0+BL1aQesxbAtiVzH6jUXYxAXq5daPk6KAS3uFOizs4nSPd45UOx93U= X-Received: by 2002:a5d:490f:: with SMTP id x15mr429300wrq.259.1591646587271; Mon, 08 Jun 2020 13:03:07 -0700 (PDT) MIME-Version: 1.0 References: <20200608163934.313-1-paul@xen.org> In-Reply-To: <20200608163934.313-1-paul@xen.org> From: Tamas K Lengyel Date: Mon, 8 Jun 2020 14:02:31 -0600 Message-ID: Subject: Re: Xen 4.14 RC1 To: Xen-devel , Paul Durrant Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-announce@lists.xenproject.org, xen-users@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 8, 2020 at 10:41 AM Paul Durrant wrote: > > Hi all, > > Xen 4.14 RC1 is tagged. You can check that out from xen.git: > > git://xenbits.xen.org/xen.git 4.14.0-rc1 > > For your convenience there is also a tarball at: > https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz > > And the signature is at: > https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz.sig > > Please send bug reports and test reports to xen-devel@lists.xenproject.org. > When sending bug reports, please CC relevant maintainers and me (paul@xen.org). > > As a reminder, there will be a Xen Test Day. Please see the test day schedule at > https://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at > https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions. Hi Paul, I'm sad to see this RC1 still missing patch: https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00179.html The following even have the release-ack and yet are also missing: https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00025.html https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00028.html Without these patches I won't be testing or upgrading to 4.14 at all. Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Mon Jun 08 20:03:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 20:03:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiNzV-0004Rz-7o; Mon, 08 Jun 2020 20:03:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiNzU-0004Ro-1h for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 20:03:28 +0000 X-Inumbo-ID: 1d19e757-a9c3-11ea-b2b4-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1d19e757-a9c3-11ea-b2b4-12813bfff9fa; Mon, 08 Jun 2020 20:03:26 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: vrPx+l5c6c1DQApKmkH6KuR7ukEc+x/2qf/ndpPZ+F0DZF33YblI2d2PGxzfYArUPJGQFvuD/Q V/VH14OawbstzgOp/uX9/W1g1jtmbtW3707NsIgLAPErbOArL6TEP1qjCnRKMLZqNpbDgc2ZRD 3Gn1jka14moTRxDHNUG2Rx/LcVYknILDUun3kYavZhg/SxWkhel9JWDyiZODMPVIo2qVj0M7BQ NrNxucq9e9K6FBchWtHfjUy/16lCdmusdc3wexBnkIbidpeKw89JHBtgPgwnSBw/UFAYO3p/YD JUY= X-SBRS: 2.7 X-MesageID: 19811629 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,487,1583211600"; d="scan'208";a="19811629" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks Date: Mon, 8 Jun 2020 21:02:59 +0100 Message-ID: <20200608200259.17681-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Konrad Rzeszutek Wilk , Andrew Cooper , Pawel Wieczorkiewicz , Paul Durrant , Ross Lagerwall , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Just like the alternatives infrastructure, the livepatch infrastructure disables CR0.WP to perform patching, which is not permitted with CET active. Modify arch_livepatch_{quiesce,revive}() to disable CET before disabling WP, and reset the dirty bits on all virtual regions before re-enabling CET. One complication is that arch_livepatch_revive() has to fix up the top of the shadow stack. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Konrad Rzeszutek Wilk CC: Ross Lagerwall CC: Pawel Wieczorkiewicz CC: Paul Durrant For 4.14. This is a bug in a 4.14 feature, with a very low risk to non-CET usecases. A better longterm plan (but definitely 4.15 material now) would be to create a separate set of writeable mappings to perform the patching on, at which point we don't need to disable CET, play with WP, or retroactively clear dirty bits. Do we ever write into .rodata? AFAICT, we introduce new fuctions for references to new .rodata, rather than modifying existing .rodata. If however we do modify .rodata, then the virtual regions need extending with information about .rodata so we can zap those dirty bits as well. --- xen/arch/x86/livepatch.c | 28 ++++++++++++++++++++++++++++ xen/common/virtual_region.c | 13 +++++++++++++ xen/include/xen/virtual_region.h | 1 + 3 files changed, 42 insertions(+) diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c index 901fad96bf..10231a4e40 100644 --- a/xen/arch/x86/livepatch.c +++ b/xen/arch/x86/livepatch.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include @@ -58,6 +59,10 @@ int arch_livepatch_safety_check(void) int arch_livepatch_quiesce(void) { + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ + if ( cpu_has_xen_shstk ) + write_cr4(read_cr4() & ~X86_CR4_CET); + /* Disable WP to allow changes to read-only pages. */ write_cr0(read_cr0() & ~X86_CR0_WP); @@ -68,6 +73,29 @@ void arch_livepatch_revive(void) { /* Reinstate WP. */ write_cr0(read_cr0() | X86_CR0_WP); + + /* Clobber dirty bits and reinstate CET, if applicable. */ + if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) + { + unsigned long tmp; + + reset_virtual_region_perms(); + + write_cr4(read_cr4() | X86_CR4_CET); + + /* + * Fix up the return address on the shadow stack, which currently + * points at arch_livepatch_quiesce()'s caller. + * + * Note: this is somewhat fragile, and depends on both + * arch_livepatch_{quiesce,revive}() being called from the same + * function, which is currently the case. + */ + asm volatile ("rdsspq %[ssp];" + "wrssq %[addr], (%[ssp]);" + : [ssp] "=&r" (tmp) + : [addr] "r" (__builtin_return_address(0))); + } } int arch_livepatch_verify_func(const struct livepatch_func *func) diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c index aa23918bce..84d993d8f8 100644 --- a/xen/common/virtual_region.c +++ b/xen/common/virtual_region.c @@ -4,6 +4,7 @@ #include #include +#include #include #include #include @@ -91,6 +92,18 @@ void unregister_virtual_region(struct virtual_region *r) remove_virtual_region(r); } +void reset_virtual_region_perms(void) +{ + const struct virtual_region *region; + + rcu_read_lock(&rcu_virtual_region_lock); + list_for_each_entry_rcu( region, &virtual_region_list, list ) + modify_xen_mappings((unsigned long)region->start, + ROUNDUP((unsigned long)region->end, PAGE_SIZE), + PAGE_HYPERVISOR_RX); + rcu_read_unlock(&rcu_virtual_region_lock); +} + void __init unregister_init_virtual_region(void) { BUG_ON(system_state != SYS_STATE_active); diff --git a/xen/include/xen/virtual_region.h b/xen/include/xen/virtual_region.h index e5e58ed96b..ba408eb87a 100644 --- a/xen/include/xen/virtual_region.h +++ b/xen/include/xen/virtual_region.h @@ -33,6 +33,7 @@ void setup_virtual_regions(const struct exception_table_entry *start, void unregister_init_virtual_region(void); void register_virtual_region(struct virtual_region *r); void unregister_virtual_region(struct virtual_region *r); +void reset_virtual_region_perms(void); #endif /* __XEN_VIRTUAL_REGION_H__ */ -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 20:39:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 20:39:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiOXy-00078C-2x; Mon, 08 Jun 2020 20:39:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiOXv-000785-Vh for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 20:39:04 +0000 X-Inumbo-ID: 16507110-a9c8-11ea-b7bb-bc764e2007e4 Received: from mo4-p00-ob.smtp.rzone.de (unknown [85.215.255.25]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 16507110-a9c8-11ea-b7bb-bc764e2007e4; Mon, 08 Jun 2020 20:39:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591648741; s=strato-dkim-0002; d=aepfle.de; h=Message-Id:Date:Subject:Cc:To:From:X-RZG-CLASS-ID:X-RZG-AUTH:From: Subject:Sender; bh=MLeNcQsbr99FDR38AxGkMCSTjv8YFEmQTlDcNz7LdfM=; b=DmH1n52zT2rcMIv0uNwu5RQxcDAb9NordXZGirLGa2fZag3WPkPsubcZYsltck4UeK f1ZZu7v7kmogVQvoJWrqXyG6InjV3pk9PK8lUy4FvR9RyiNM6FaInWCSubMNB0l3aLz/ MnOih2FuiNmIIw0hXO3kH8ZZQsSUFKBxrytyGypOZsCCIvj4yEN3GTYNIZrq8lTV0JbS 0alcnggiS07Bw0+5rGO9PxxqgZFTP3CWUSRap1khpP/FHvOnKaJ8AKiSvwerefkCMwdO tVsz/WRuoz3BNHBM+oFGM6XFQggYabL/QzIV21PI4l24Wu8zO2iLcrAKvF+tVbL7SIml DTKg== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QXkBR9MXjAuzBW/OdlBZQ4AHSS3GpKjw==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w58KcrHyi (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) (Client did not present a certificate); Mon, 8 Jun 2020 22:38:53 +0200 (CEST) From: Olaf Hering To: xen-devel@lists.xenproject.org Subject: [PATCH v1] kdd: remove zero-length arrays Date: Mon, 8 Jun 2020 22:38:48 +0200 Message-Id: <20200608203849.18341-1-olaf@aepfle.de> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Olaf Hering , Tim Deegan , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Struct 'kdd_hdr' already has a member named 'payload[]' to easily refer to the data after the header. Remove the payload member from 'kdd_pkt' and always use 'kdd_hdr' to fix the following compile error: kdd.c: In function 'kdd_tx': kdd.c:746:30: error: array subscript 65534 is outside the bounds of an interior zero-length array 'uint8_t[0]' {aka 'unsigned char[]'} [-Werror=zero-length-bounds] 746 | sum += s->txp.payload[i]; | ~~~~~~~~~~~~~~^~~ In file included from kdd.c:53: kdd.h:326:17: note: while referencing 'payload' 326 | uint8_t payload[0]; | ^~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Olaf Hering --- tools/debugger/kdd/kdd.c | 10 +++++----- tools/debugger/kdd/kdd.h | 3 +-- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c index 3ebda9b12c..4c6b39c22b 100644 --- a/tools/debugger/kdd/kdd.c +++ b/tools/debugger/kdd/kdd.c @@ -249,7 +249,7 @@ static void kdd_log_pkt(kdd_state *s, char *name, kdd_pkt *p) /* Re-check the checksum */ for (i = 0; i < p->h.len; i++) - sum += p->payload[i]; + sum += p->h.payload[i]; fprintf(f, "\n" "%s: %s type 0x%4.4"PRIx16" len 0x%4.4"PRIx16 @@ -267,8 +267,8 @@ static void kdd_log_pkt(kdd_state *s, char *name, kdd_pkt *p) fprintf(f, "%8.8x ", i); } else if (i % 8 == 0) fprintf(f, " "); - fprintf(f, " %2.2x", p->payload[i]); - ascii[i % 16] = (isprint(((int)p->payload[i])) ? p->payload[i] : 0x2e); + fprintf(f, " %2.2x", p->h.payload[i]); + ascii[i % 16] = (isprint(((int)p->h.payload[i])) ? p->h.payload[i] : 0x2e); if (i % 16 == 15) fprintf(f, " |%s|\n", ascii); } @@ -743,7 +743,7 @@ static void kdd_tx(kdd_state *s) /* Fix up the checksum before we send */ for (i = 0; i < s->txp.h.len; i++) - sum += s->txp.payload[i]; + sum += s->txp.h.payload[i]; s->txp.h.sum = sum; kdd_log_pkt(s, "TX", &s->txp); @@ -1127,7 +1127,7 @@ static void kdd_handle_pkt(kdd_state *s, kdd_pkt *p) /* Simple checksum: add all the bytes */ for (i = 0; i < p->h.len; i++) - sum += p->payload[i]; + sum += p->h.payload[i]; if (p->h.sum != sum) { kdd_send_ack(s, p->h.id, KDD_ACK_BAD); return; diff --git a/tools/debugger/kdd/kdd.h b/tools/debugger/kdd/kdd.h index bfb00ba5c5..57525d36c6 100644 --- a/tools/debugger/kdd/kdd.h +++ b/tools/debugger/kdd/kdd.h @@ -68,7 +68,7 @@ typedef struct { uint16_t len; /* Payload length, excl. header and trailing byte */ uint32_t id; /* Echoed in responses */ uint32_t sum; /* Unsigned sum of all payload bytes */ - uint8_t payload[0]; + uint8_t payload[]; } PACKED kdd_hdr; #define KDD_PKT_CMD 0x0002 /* Debugger commands (and replies to them) */ @@ -323,7 +323,6 @@ typedef struct { kdd_msg msg; kdd_reg reg; kdd_stc stc; - uint8_t payload[0]; }; } PACKED kdd_pkt; From xen-devel-bounces@lists.xenproject.org Mon Jun 08 20:45:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 20:45:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiOe5-0007y0-S3; Mon, 08 Jun 2020 20:45:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiOe4-0007xv-TK for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 20:45:24 +0000 X-Inumbo-ID: f9a66226-a9c8-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f9a66226-a9c8-11ea-bb8b-bc764e2007e4; Mon, 08 Jun 2020 20:45:24 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id n24so19893806ejd.0 for ; Mon, 08 Jun 2020 13:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1mgyF3W2Bn3zvxFunIfhU499znjsykqnFMxabpQVkD0=; b=teJ1pwDTr6qUpzo+KAnfp63kUyJYKhMypk5rOcwrJk6Pcm7Yi5tJ3N3z5xqTzoPYx8 m+n2sg2qJm6wh1zS4TLYfYYqGl65dtcx7Vwk3ZlqoRmdmOw4dvMwsvl6IKmFoeRMkiOj VeDE65StvBKMuJPcKeHa33yK4CcVahKXiYXiLyHWaetwXyVWk012Pk77T9R1CW7aOG7J 8aA5SMvGTCgJFNSpLk6aGUIwKrI4hcV2Q94C3Bj4lxBisCjpyMf532xotUJBkjgrCv+L F7kL+LZNi8D4E/rmopRW9umo2Aq2k4B7ZXS1Hz1WFYibXh832F+vFbNGToTXe+hUgGtu 3k7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1mgyF3W2Bn3zvxFunIfhU499znjsykqnFMxabpQVkD0=; b=pF3TcNlhV9NXHsSXwMPPZzJoaIX32ue8B2HzP15n649evIcz0S0o54OgEAi/p+oonN 71X5pRhDVCG3uHW9KqfLgmrFvgB72Zl9cq2THeB7JC8Uf/FA2e11GdmD4onhGU0wbGow yD1INy6dAbzbldx4jrtKuA7I4VCmGCu4NtpzQ7k7kIMgZtUAiAlukhoylHMcLiAD4RzN rBtWibajiRqsgQ8PGzQqzCsXj/BN0fFEsnmF3IujULnstSqJfKyafr9w6XCZ5g5mshsa OwT+180+juG+Z4kArFO9I34Lpf+Z140uFWP4Q7Qz7fUc56+s2FqpA4gunImu4pao8QlE HW2Q== X-Gm-Message-State: AOAM530NN+Jl4SNpow4Em8tdNz+8kKKB4gA3yxojn1OZS7VfNdaeoQYl USjUvWUAngon209NbytLWDyzMrPHOaA= X-Google-Smtp-Source: ABdhPJydpDG9uouXR5NWRfJkOgsI8W7HKsTU9ZmKvnoni98Vc77/bSc9V197y8JlPDz/SqqishyaFg== X-Received: by 2002:a17:906:1e95:: with SMTP id e21mr23033049ejj.240.1591649122507; Mon, 08 Jun 2020 13:45:22 -0700 (PDT) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com. [209.85.128.46]) by smtp.gmail.com with ESMTPSA id m14sm7478517ejr.5.2020.06.08.13.45.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 13:45:21 -0700 (PDT) Received: by mail-wm1-f46.google.com with SMTP id c71so812215wmd.5 for ; Mon, 08 Jun 2020 13:45:21 -0700 (PDT) X-Received: by 2002:a05:600c:2294:: with SMTP id 20mr491865wmf.51.1591649121114; Mon, 08 Jun 2020 13:45:21 -0700 (PDT) MIME-Version: 1.0 References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> In-Reply-To: From: Tamas K Lengyel Date: Mon, 8 Jun 2020 14:44:45 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Razvan Cojocaru Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Andrei LUTAS , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?B?TWloYWkgRG9uyJt1?= , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 8, 2020 at 2:14 PM Razvan Cojocaru wrote: > > On 6/8/20 10:54 PM, Tamas K Lengyel wrote: > > On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru > >> And last but not least, the proper sequence is: 1. unsubscribe from > >> register write events, 2. process all events "still in the chamber" > >> (keep checking the ring buffer for a while), 3. detach from the guest > >> (disable the vm_event subsystem). Not ideal perhaps (in that it's not > >> guaranteed that a VCPU won't resume after a longer period than our > >> timeout), but if the sequence is followed there should be no guest hangs > >> or crashes (at least none that we or our clients have observed so far). > > > > Incorrect. That's not enough. You also have to wait for all the vCPUs > > to get scheduled before disabling vm_event or otherwise the emulation > > is skipped entirely. Please read the patch message. If the user > > decides to disable vm_event after getting a CR3 event delivered, the > > CR3 never gets updated and results in the guest crashing in > > unpredictable ways. Same happens with all the other registers. > > I did read the patch message. As I've previously stated ("it's not > guaranteed that a VCPU won't resume after a longer period than our > timeout"), it's not ideal, and I've made no claim that the problem does > not exist or that it shouldn't be fixed - but really if you've got a > VCPU that will wait more than a couple of seconds to get scheduled then > you've got a bigger problem with the VM. Sorry, missed the part where you say you knew about this issue. We didn't and it was absolutely not documented anywhere and certainly not mentioned in the original patch that added the feature. It literally took us years to figure out what the hell is going on. While as you it can be a couple seconds before its safe to disable it can be a lot longer depending on the system state, how many VMs are running and how many vCPUs are active on the VM. There is absolutely necessary use-cases where you want to keep the VM paused after a CR3 event is received and exit vm_event afterwards. This bug totally blocks those use-cases. Not to mention that it's a total mess having an interface where the user has to guess when its safe to do something. If this was pointed out when the patch was made I would have objected to that being merged. > > >> So in short, I think there's a better fix for this by simply not > >> allocating the vm_event memory on-demand anymore and never having to > >> deal with lost pending emulations again. It should also decrease code > >> complexity by a tiny bit. Then again, as stated at the beginning of this > >> message, that's just a recommendation.is > > > > Since only you guys use this feature I'm going to wait for a fix. > > Until then, the default behavior should be restored so this buggy > > behavior doesn't affect anyone else. You can still turn it on, its > > just not going to be on for vm_event by default. I don't particularly > > care what fix is there since only you guys use it. If you don't mind > > that there is this buggy behavior because you never disable vm_events > > once you activate it then that's that. > > Indeed, our usual scenario is that vm_event is always on on the machine. > It's only rarely being disabled while the guest is running, and when it > is, it's always with waiting sufficiently long that we've not seen any > unexplainable hung VMs. > > Fair enough, as long as the previous behaviour is optionally available I > see no reason why this patch shouldn't make it in - though, of course, > as also previously stated, I'm just trying to shed as much light as > possible on this from what I remember, and what happens next is not my > call. My colleagues should be able to chime in tomorrow. Looking forward to it. Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Mon Jun 08 21:26:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 21:26:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiPHE-0002tc-VB; Mon, 08 Jun 2020 21:25:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiPHD-0002tX-HX for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 21:25:51 +0000 X-Inumbo-ID: 9ee280c6-a9ce-11ea-b2be-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9ee280c6-a9ce-11ea-b2be-12813bfff9fa; Mon, 08 Jun 2020 21:25:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8A7Kl5cxYRFXeXDbNrg8l4Ik4YNFNfUwokBYZVMUKxo=; b=qc6xl4FO4bjm/A8W9gH5Xq5wF deIaK/YNwuJ4MARRvPS1PQtnzOHKMTkToK3ZLHWfnc63yamyTW6pfkr45dztzQFh9BdVN5kMGRIw6 VeS4Cb3zgMf0beXVBLXS25m8a8c5DmA6YZLlmi+mrHBAJhBWBWicNFAb9g9W6h4kZW5xU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiPH9-00018Y-Ow; Mon, 08 Jun 2020 21:25:47 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiPH9-0007jY-FQ; Mon, 08 Jun 2020 21:25:47 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiPH9-0002tL-Ei; Mon, 08 Jun 2020 21:25:47 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150923: regressions - trouble: blocked/broken/fail/pass X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64::broken:regression qemu-mainline:test-amd64-amd64-xl-multivcpu::broken:regression qemu-mainline:test-armhf-armhf-xl-credit2::broken:regression qemu-mainline:test-amd64-amd64-xl::broken:regression qemu-mainline:test-armhf-armhf-xl-credit1::broken:regression qemu-mainline:test-amd64-amd64-xl-pvhv2-amd::broken:regression qemu-mainline:test-amd64-amd64-libvirt::broken:regression qemu-mainline:test-armhf-armhf-xl-multivcpu::broken:regression qemu-mainline:test-amd64-amd64-pygrub::broken:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd::broken:regression qemu-mainline:test-armhf-armhf-xl-rtds::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow::broken:regression qemu-mainline:test-amd64-amd64-xl-credit1::broken:regression qemu-mainline:test-amd64-amd64-xl-shadow::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64::broken:regression qemu-mainline:test-armhf-armhf-xl-arndale::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict::broken:regression qemu-mainline:test-amd64-amd64-xl-pvhv2-intel::broken:regression qemu-mainline:test-amd64-coresched-amd64-xl::broken:regression qemu-mainline:test-amd64-amd64-i386-pvgrub::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64::broken:regression qemu-mainline:test-amd64-amd64-libvirt-pair::broken:regression qemu-mainline:test-amd64-amd64-libvirt-vhd::broken:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel::broken:regression qemu-mainline:build-amd64-xsm::broken:regression qemu-mainline:test-amd64-amd64-xl-pvshim::broken:regression qemu-mainline:test-amd64-amd64-xl-qcow2::broken:regression qemu-mainline:test-amd64-amd64-xl-credit2::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64::broken:regression qemu-mainline:test-amd64-amd64-pair::broken:regression qemu-mainline:test-arm64-arm64-xl-thunderx::broken:regression qemu-mainline:test-amd64-amd64-xl-rtds::broken:regression qemu-mainline:test-armhf-armhf-xl-vhd::broken:regression qemu-mainline:test-amd64-amd64-amd64-pvgrub::broken:regression qemu-mainline:test-amd64-amd64-libvirt-pair:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-amd64-pvgrub:hosts-allocate:broken:regression qemu-mainline:test-armhf-armhf-xl-vhd:hosts-allocate:broken:regression qemu-mainline:test-amd64-coresched-amd64-xl:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-xl-shadow:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-xl-pvhv2-amd:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-i386-pvgrub:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-xl-qcow2:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:hosts-allocate:broken:regression qemu-mainline:test-amd64-amd64-xl-credit1:host-install(4):broken:regression qemu-mainline:test-amd64-amd64-xl-pvshim:host-install(4):broken:regression qemu-mainline:test-amd64-amd64-xl-multivcpu:host-install(4):broken:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:host-install(4):broken:regression qemu-mainline:test-amd64-amd64-pair:host-install/src_host(4):broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:host-install(4):broken:regression qemu-mainline:test-amd64-amd64-libvirt:host-install(4):broken:regression qemu-mainline:test-amd64-amd64-pair:host-install/dst_host(5):broken:regression qemu-mainline:test-arm64-arm64-xl-thunderx:host-install(4):broken:regression qemu-mainline:test-armhf-armhf-xl-arndale:host-install(4):broken:regression qemu-mainline:test-armhf-armhf-xl-credit1:host-install(4):broken:regression qemu-mainline:test-armhf-armhf-xl-credit2:host-install(4):broken:regression qemu-mainline:test-armhf-armhf-xl-multivcpu:host-install(4):broken:regression qemu-mainline:test-amd64-amd64-pair:syslog-server:broken:regression qemu-mainline:test-amd64-amd64-libvirt:syslog-server:broken:regression qemu-mainline:test-amd64-amd64-xl-credit1:syslog-server:broken:regression qemu-mainline:test-amd64-amd64-xl-multivcpu:syslog-server:broken:regression qemu-mainline:test-amd64-amd64-xl-pvshim:syslog-server:broken:regression qemu-mainline:test-arm64-arm64-xl-thunderx:syslog-server:broken:regression qemu-mainline:test-armhf-armhf-xl-arndale:syslog-server:broken:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:syslog-server:broken:regression qemu-mainline:test-armhf-armhf-xl-credit2:syslog-server:broken:regression qemu-mainline:test-armhf-armhf-xl-credit1:syslog-server:broken:regression qemu-mainline:test-armhf-armhf-xl:syslog-server:broken:regression qemu-mainline:test-armhf-armhf-xl-cubietruck:syslog-server:broken:regression qemu-mainline:test-armhf-armhf-xl-multivcpu:syslog-server:broken:regression qemu-mainline:test-amd64-amd64-pygrub:xen-install:fail:regression qemu-mainline:build-amd64-xsm:host-build-prep:fail:regression qemu-mainline:test-amd64-amd64-xl-pvhv2-intel:host-ping-check-xen:fail:regression qemu-mainline:test-amd64-amd64-xl-credit2:debian-fixup:fail:regression qemu-mainline:test-amd64-amd64-xl:guest-start:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:build-i386-pvops:kernel-build:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression qemu-mainline:build-armhf-libvirt:libvirt-build:fail:regression qemu-mainline:build-i386:xen-build:fail:regression qemu-mainline:build-i386-xsm:xen-build:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):running:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):running:regression qemu-mainline:test-armhf-armhf-libvirt-raw:build-check(1):running:regression qemu-mainline:test-armhf-armhf-libvirt:build-check(1):running:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:build-check(1):running:regression qemu-mainline:test-amd64-amd64-xl-xsm:build-check(1):running:regression qemu-mainline:build-amd64-xsm:syslog-server:running:regression qemu-mainline:build-i386-pvops:syslog-server:running:regression qemu-mainline:build-armhf-libvirt:syslog-server:running:regression qemu-mainline:test-armhf-armhf-xl-rtds:hosts-allocate:broken:allowable qemu-mainline:test-amd64-amd64-xl-rtds:hosts-allocate:broken:allowable qemu-mainline:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-pair:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-coresched-i386-xl:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking qemu-mainline:build-i386-libvirt:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking qemu-mainline:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:capture-logs(5):broken:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-pvshim:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-libvirt:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-multivcpu:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-pair:capture-logs/src_host(6):broken:nonblocking qemu-mainline:test-amd64-amd64-pair:capture-logs/dst_host(7):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-credit1:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-pygrub:capture-logs(7):broken:nonblocking qemu-mainline:build-amd64-xsm:capture-logs:broken:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-xl:capture-logs(13):broken:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-intel:capture-logs(11):broken:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-credit2:capture-logs(12):broken:nonblocking qemu-mainline:build-i386-pvops:capture-logs:broken:nonblocking qemu-mainline:build-armhf-libvirt:capture-logs:broken:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:capture-logs(5):broken:nonblocking qemu-mainline:test-amd64-amd64-xl-pvhv2-intel:capture-logs(9):broken:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=5a922419feb980592ef3dc16d74f0d9cf5ca4830 X-Osstest-Versions-That: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e From: osstest service owner Date: Mon, 08 Jun 2020 21:25:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150923 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150923/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-amd64-xl-multivcpu broken test-armhf-armhf-xl-credit2 broken test-amd64-amd64-xl broken test-armhf-armhf-xl-credit1 broken test-amd64-amd64-xl-pvhv2-amd broken test-amd64-amd64-libvirt broken test-armhf-armhf-xl-multivcpu broken test-amd64-amd64-pygrub broken test-amd64-amd64-qemuu-nested-amd broken test-armhf-armhf-xl-rtds broken test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken test-amd64-amd64-xl-credit1 broken test-amd64-amd64-xl-shadow broken test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken test-armhf-armhf-xl-arndale broken test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict broken test-amd64-amd64-xl-pvhv2-intel broken test-amd64-coresched-amd64-xl broken test-amd64-amd64-i386-pvgrub broken test-amd64-amd64-xl-qemuu-win7-amd64 broken test-amd64-amd64-libvirt-pair broken test-amd64-amd64-libvirt-vhd broken test-amd64-amd64-qemuu-nested-intel broken build-amd64-xsm broken test-amd64-amd64-xl-pvshim broken test-amd64-amd64-xl-qcow2 broken test-amd64-amd64-xl-credit2 broken test-amd64-amd64-xl-qemuu-ws16-amd64 broken test-amd64-amd64-pair broken test-arm64-arm64-xl-thunderx broken test-amd64-amd64-xl-rtds broken test-armhf-armhf-xl-vhd broken test-amd64-amd64-amd64-pvgrub broken test-amd64-amd64-libvirt-pair 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-amd64-pvgrub 2 hosts-allocate broken REGR. vs. 150694 test-armhf-armhf-xl-vhd 2 hosts-allocate broken REGR. vs. 150694 test-amd64-coresched-amd64-xl 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-shadow 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-pvhv2-amd 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-qemuu-debianhvm-amd64 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-i386-pvgrub 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-qcow2 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-qemuu-ovmf-amd64 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-qemuu-win7-amd64 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-qemuu-nested-amd 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-credit1 4 host-install(4) broken REGR. vs. 150694 test-amd64-amd64-xl-pvshim 4 host-install(4) broken REGR. vs. 150694 test-amd64-amd64-xl-multivcpu 4 host-install(4) broken REGR. vs. 150694 test-amd64-amd64-libvirt-vhd 4 host-install(4) broken REGR. vs. 150694 test-amd64-amd64-pair 4 host-install/src_host(4) broken REGR. vs. 150694 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 4 host-install(4) broken REGR. vs. 150694 test-amd64-amd64-libvirt 4 host-install(4) broken REGR. vs. 150694 test-amd64-amd64-pair 5 host-install/dst_host(5) broken REGR. vs. 150694 test-arm64-arm64-xl-thunderx 4 host-install(4) broken REGR. vs. 150694 test-armhf-armhf-xl-arndale 4 host-install(4) broken REGR. vs. 150694 test-armhf-armhf-xl-credit1 4 host-install(4) broken REGR. vs. 150694 test-armhf-armhf-xl-credit2 4 host-install(4) broken REGR. vs. 150694 test-armhf-armhf-xl-multivcpu 4 host-install(4) broken REGR. vs. 150694 test-amd64-amd64-pair 3 syslog-server broken REGR. vs. 150694 test-amd64-amd64-libvirt 3 syslog-server broken REGR. vs. 150694 test-amd64-amd64-xl-credit1 3 syslog-server broken REGR. vs. 150694 test-amd64-amd64-xl-multivcpu 3 syslog-server broken REGR. vs. 150694 test-amd64-amd64-xl-pvshim 3 syslog-server broken REGR. vs. 150694 test-arm64-arm64-xl-thunderx 3 syslog-server broken REGR. vs. 150694 test-armhf-armhf-xl-arndale 3 syslog-server broken REGR. vs. 150694 test-amd64-amd64-libvirt-vhd 3 syslog-server broken REGR. vs. 150694 test-armhf-armhf-xl-credit2 3 syslog-server broken REGR. vs. 150694 test-armhf-armhf-xl-credit1 3 syslog-server broken REGR. vs. 150694 test-armhf-armhf-xl 3 syslog-server broken REGR. vs. 150694 test-armhf-armhf-xl-cubietruck 3 syslog-server broken REGR. vs. 150694 test-armhf-armhf-xl-multivcpu 3 syslog-server broken REGR. vs. 150694 test-amd64-amd64-pygrub 6 xen-install fail REGR. vs. 150694 build-amd64-xsm 5 host-build-prep fail REGR. vs. 150694 test-amd64-amd64-xl-pvhv2-intel 8 host-ping-check-xen fail REGR. vs. 150694 test-amd64-amd64-xl-credit2 11 debian-fixup fail REGR. vs. 150694 test-amd64-amd64-xl 12 guest-start fail REGR. vs. 150694 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 150694 build-i386-pvops 6 kernel-build fail REGR. vs. 150694 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 150694 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150694 build-i386 6 xen-build fail REGR. vs. 150694 build-i386-xsm 6 xen-build fail REGR. vs. 150694 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) running test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) running test-armhf-armhf-libvirt-raw 1 build-check(1) running test-armhf-armhf-libvirt 1 build-check(1) running test-amd64-amd64-libvirt-xsm 1 build-check(1) running test-amd64-amd64-xl-xsm 1 build-check(1) running build-amd64-xsm 3 syslog-server running build-i386-pvops 3 syslog-server running build-armhf-libvirt 3 syslog-server running Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 2 hosts-allocate broken REGR. vs. 150694 test-amd64-amd64-xl-rtds 2 hosts-allocate broken REGR. vs. 150694 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-libvirt-vhd 5 capture-logs(5) broken blocked in 150694 test-armhf-armhf-xl-multivcpu 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-xl-pvshim 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-libvirt 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-xl-multivcpu 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-pair 6 capture-logs/src_host(6) broken blocked in 150694 test-amd64-amd64-pair 7 capture-logs/dst_host(7) broken blocked in 150694 test-amd64-amd64-xl-credit1 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-pygrub 7 capture-logs(7) broken blocked in 150694 build-amd64-xsm 6 capture-logs broken blocked in 150694 test-armhf-armhf-xl-arndale 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-xl 13 capture-logs(13) broken blocked in 150694 test-amd64-amd64-qemuu-nested-intel 11 capture-logs(11) broken blocked in 150694 test-armhf-armhf-xl-credit2 5 capture-logs(5) broken blocked in 150694 test-amd64-amd64-xl-credit2 12 capture-logs(12) broken blocked in 150694 build-i386-pvops 7 capture-logs broken blocked in 150694 build-armhf-libvirt 7 capture-logs broken blocked in 150694 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 5 capture-logs(5) broken never pass test-amd64-amd64-xl-pvhv2-intel 9 capture-logs(9) broken never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass version targeted for testing: qemuu 5a922419feb980592ef3dc16d74f0d9cf5ca4830 baseline version: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e Last test of basis 150694 2020-06-04 11:44:20 Z 4 days Failing since 150831 2020-06-05 13:06:20 Z 3 days 8 attempts Testing same since 150923 2020-06-08 11:57:09 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Bulekov Christian Borntraeger Cornelia Huck Cédric Le Goater Eden Mikitas Gerd Hoffmann Janosch Frank Jared Rossi Kevin Wolf Paolo Bonzini Paul Zimmerman Peter Maydell Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard Henderson Stefan Hajnoczi Stefano Garzarella Thomas Huth Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm broken build-arm64-xsm pass build-i386-xsm fail build-amd64 pass build-arm64 pass build-armhf pass build-i386 fail build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt fail build-i386-libvirt blocked build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops fail test-amd64-amd64-xl broken test-amd64-coresched-amd64-xl broken test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl blocked test-amd64-coresched-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd broken test-amd64-amd64-xl-pvhv2-amd broken test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 broken test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 broken test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 broken test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale broken test-amd64-amd64-xl-credit1 broken test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 broken test-amd64-amd64-xl-credit2 broken test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 broken test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict broken test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel broken test-amd64-amd64-xl-pvhv2-intel broken test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt broken test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-xl-multivcpu broken test-armhf-armhf-xl-multivcpu broken test-amd64-amd64-pair broken test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair broken test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub broken test-amd64-amd64-i386-pvgrub broken test-amd64-amd64-xl-pvshim broken test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub broken test-amd64-amd64-xl-qcow2 broken test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds broken test-armhf-armhf-xl-rtds broken test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow broken test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx broken test-amd64-amd64-libvirt-vhd broken test-armhf-armhf-xl-vhd broken ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-amd64-xl-qemuu-ovmf-amd64 broken broken-job test-amd64-amd64-xl-multivcpu broken broken-job test-armhf-armhf-xl-credit2 broken broken-job test-amd64-amd64-xl broken broken-job test-armhf-armhf-xl-credit1 broken broken-job test-amd64-amd64-xl-pvhv2-amd broken broken-job test-amd64-amd64-libvirt broken broken-job test-armhf-armhf-xl-multivcpu broken broken-job test-amd64-amd64-pygrub broken broken-job test-amd64-amd64-qemuu-nested-amd broken broken-job test-armhf-armhf-xl-rtds broken broken-job test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken broken-job test-amd64-amd64-xl-credit1 broken broken-job test-amd64-amd64-xl-shadow broken broken-job test-amd64-amd64-xl-qemuu-debianhvm-amd64 broken broken-job test-armhf-armhf-xl-arndale broken broken-job test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict broken broken-job test-amd64-amd64-xl-pvhv2-intel broken broken-job test-amd64-coresched-amd64-xl broken broken-job test-amd64-amd64-i386-pvgrub broken broken-job test-amd64-amd64-xl-qemuu-win7-amd64 broken broken-job test-amd64-amd64-libvirt-pair broken broken-job test-amd64-amd64-libvirt-vhd broken broken-job test-amd64-amd64-qemuu-nested-intel broken broken-job build-amd64-xsm broken broken-job test-amd64-amd64-xl-pvshim broken broken-job test-amd64-amd64-xl-qcow2 broken broken-job test-amd64-amd64-xl-credit2 broken broken-job test-amd64-amd64-xl-qemuu-ws16-amd64 broken broken-job test-amd64-amd64-pair broken broken-job test-arm64-arm64-xl-thunderx broken broken-job test-amd64-amd64-xl-rtds broken broken-job test-armhf-armhf-xl-vhd broken broken-job test-amd64-amd64-amd64-pvgrub broken broken-step test-amd64-amd64-libvirt-pair hosts-allocate broken-step test-amd64-amd64-amd64-pvgrub hosts-allocate broken-step test-armhf-armhf-xl-vhd hosts-allocate broken-step test-armhf-armhf-xl-rtds hosts-allocate broken-step test-armhf-armhf-xl-credit1 capture-logs(5) broken-step test-amd64-amd64-libvirt-vhd capture-logs(5) broken-step test-amd64-coresched-amd64-xl hosts-allocate broken-step test-amd64-amd64-xl-shadow hosts-allocate broken-step test-armhf-armhf-xl-multivcpu capture-logs(5) broken-step test-amd64-amd64-xl-pvshim capture-logs(5) broken-step test-amd64-amd64-libvirt capture-logs(5) broken-step test-amd64-amd64-xl-multivcpu capture-logs(5) broken-step test-amd64-amd64-pair capture-logs/src_host(6) broken-step test-amd64-amd64-pair capture-logs/dst_host(7) broken-step test-amd64-amd64-xl-qemuu-ws16-amd64 hosts-allocate broken-step test-amd64-amd64-xl-pvhv2-amd hosts-allocate broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64 hosts-allocate broken-step test-amd64-amd64-i386-pvgrub hosts-allocate broken-step test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow hosts-allocate broken-step test-amd64-amd64-xl-qcow2 hosts-allocate broken-step test-amd64-amd64-xl-qemuu-ovmf-amd64 hosts-allocate broken-step test-amd64-amd64-xl-qemuu-win7-amd64 hosts-allocate broken-step test-amd64-amd64-xl-rtds hosts-allocate broken-step test-amd64-amd64-xl-credit1 capture-logs(5) broken-step test-amd64-amd64-qemuu-nested-amd hosts-allocate broken-step test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict capture-logs(5) broken-step test-amd64-amd64-xl-pvhv2-intel capture-logs(9) broken-step test-amd64-amd64-pygrub capture-logs(7) broken-step test-amd64-amd64-xl-credit1 host-install(4) broken-step test-amd64-amd64-xl-pvshim host-install(4) broken-step test-amd64-amd64-xl-multivcpu host-install(4) broken-step test-amd64-amd64-libvirt-vhd host-install(4) broken-step test-amd64-amd64-pair host-install/src_host(4) broken-step test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict host-install(4) broken-step test-amd64-amd64-libvirt host-install(4) broken-step test-amd64-amd64-pair host-install/dst_host(5) broken-step build-amd64-xsm capture-logs broken-step test-armhf-armhf-xl-arndale capture-logs(5) broken-step test-amd64-amd64-xl capture-logs(13) broken-step test-amd64-amd64-qemuu-nested-intel capture-logs(11) broken-step test-armhf-armhf-xl-credit2 capture-logs(5) broken-step test-arm64-arm64-xl-thunderx host-install(4) broken-step test-amd64-amd64-xl-credit2 capture-logs(12) broken-step test-armhf-armhf-xl-arndale host-install(4) broken-step test-armhf-armhf-xl-credit1 host-install(4) broken-step test-armhf-armhf-xl-credit2 host-install(4) broken-step test-armhf-armhf-xl-multivcpu host-install(4) broken-step build-i386-pvops capture-logs broken-step test-amd64-amd64-pair syslog-server broken-step test-amd64-amd64-libvirt syslog-server broken-step test-amd64-amd64-xl-credit1 syslog-server broken-step test-amd64-amd64-xl-multivcpu syslog-server broken-step test-amd64-amd64-xl-pvshim syslog-server broken-step test-arm64-arm64-xl-thunderx syslog-server broken-step test-armhf-armhf-xl-arndale syslog-server broken-step test-amd64-amd64-libvirt-vhd syslog-server broken-step test-armhf-armhf-xl-credit2 syslog-server broken-step test-armhf-armhf-xl-credit1 syslog-server broken-step test-armhf-armhf-xl syslog-server broken-step test-armhf-armhf-xl-cubietruck syslog-server broken-step test-armhf-armhf-xl-multivcpu syslog-server broken-step build-armhf-libvirt capture-logs Not pushing. (No revision log; it would be 973 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 08 22:35:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 22:35:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQMH-0000F4-An; Mon, 08 Jun 2020 22:35:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQMG-0000Ek-8h for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 22:35:08 +0000 X-Inumbo-ID: 4ace67b6-a9d8-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4ace67b6-a9d8-11ea-b7bb-bc764e2007e4; Mon, 08 Jun 2020 22:35:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1MoTeJkR1RcaWAsVN0ozbYfYjIS8VqqSZQNGOcE5naA=; b=kKr54VGvx2qmeMhYFhVGUXG58 URrIIe5YlX1oRDNdrCTrbaxSzAzx2v6YAh5qpKQNVrbjDyR5aHJg07+16KjmD9wDcD7M5ggFi2pIT Owoj0LrBOP16Ul4PP5pzyayNzbmvXVN15D5aT41L5IT6PLAbEycviXNLt89zDnJrVwUqI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQM9-0002Uq-Ir; Mon, 08 Jun 2020 22:35:01 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiQM9-0002xa-6a; Mon, 08 Jun 2020 22:35:01 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiQM9-0005tY-5y; Mon, 08 Jun 2020 22:35:01 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150929: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 X-Osstest-Versions-That: xen=03dc5f00f66e9c29afdfc9a72e4e6d70ea50b191 From: osstest service owner Date: Mon, 08 Jun 2020 22:35:01 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150929 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150929/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 baseline version: xen 03dc5f00f66e9c29afdfc9a72e4e6d70ea50b191 Last test of basis 150926 2020-06-08 16:00:24 Z 0 days Testing same since 150929 2020-06-08 19:02:22 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: George Dunlap Julien Grall Nick Rosbrook Roger Pau Monné jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 03dc5f00f6..835d8d69d9 835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 -> smoke From xen-devel-bounces@lists.xenproject.org Mon Jun 08 22:51:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 22:51:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQbi-0001sG-KQ; Mon, 08 Jun 2020 22:51:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQbg-0001sB-Sd for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 22:51:05 +0000 X-Inumbo-ID: 867a0840-a9da-11ea-8496-bc764e2007e4 Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 867a0840-a9da-11ea-8496-bc764e2007e4; Mon, 08 Jun 2020 22:51:01 +0000 (UTC) Received: by mail-ed1-x541.google.com with SMTP id o26so14812313edq.0 for ; Mon, 08 Jun 2020 15:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k1R/1B5bkxfOlVmZdhzjwaXKKxv9f2jPV/2Mw184/i0=; b=GacaojeZhQpwI2+HDap9MhB0jF0z4P1kIfPZFwxOdU3ygypzbx8sY0YR09AEEC7NkN o2aEiyDCqq1WnGxXggou1reEbXEA+eO4yPraaTwPNgle4DpiCpIpS9ti2s5MxKy7Bhvs NWC8Qg/OkizqzAKx5Mzc8Pq/DZmEFn3Jw3kKuUGdTZUuhT2EeuYlni9sM6s4zAr8XRRv wIbEIWJFBDPQh8NpVcnotkBTvfDn8m2wgpbqmvUzsdh0oZur6bjxBtc8LXemQN5LDKkM OxaHR6MJxvqe9H4ylGNFQH/Gpt0N4a3oX/AX/0pAbC4RLEP63y6mUmJMlhwDLZ9LGE2G opEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k1R/1B5bkxfOlVmZdhzjwaXKKxv9f2jPV/2Mw184/i0=; b=Nt9Wms+gUypw/QWk+mzXlya34isMaPCt2KROVt9AAchiCrnLP/46H3jC7tdJXOUlU6 VelfevE1MVGnLYSiP0FXRlVT6Wart5oQ1BGstwiUdC7fnN0JIDXLh44VTxCU0WLizL7j 2Tqcwd/sBQAkzbv5kCy6HDa4qqx4h+j5ZgS/AiD1HZSVbLLrrCmTBvS9aTNZxlOoqUQP 5VY91XuQ9jkXTfo4ZxP06O5CwRGwrxIQd2Hpaa+FeUwQuFVkugpRK/jCs/te4GmTiXcY SKC9uoGCo7Njc+NFqdeQ1SBkEYPcCNrtj5SlmixEo+rTEu8EpBMYVWHAt365oSsT+2Iw 6AKA== X-Gm-Message-State: AOAM531FVvDVYpJc92ZMqzvXlSbEA9P0YRqM75PUMfp01ntspz7m4gBm ZdfjYWKDbFi6sr2Xfw+mycpuqKZGUJ4= X-Google-Smtp-Source: ABdhPJyQL5r7n/MkcVPZYqW8GPBhcm+/9xnF5y2iumLVmegk9SjnykXKrQcdwB94K9JuNXI1QE8ZKg== X-Received: by 2002:a05:6402:155:: with SMTP id s21mr23533623edu.144.1591656660204; Mon, 08 Jun 2020 15:51:00 -0700 (PDT) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com. [209.85.128.45]) by smtp.gmail.com with ESMTPSA id v5sm11676288ejx.123.2020.06.08.15.50.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 15:50:59 -0700 (PDT) Received: by mail-wm1-f45.google.com with SMTP id l26so1047138wme.3 for ; Mon, 08 Jun 2020 15:50:58 -0700 (PDT) X-Received: by 2002:a1c:acc8:: with SMTP id v191mr932451wme.154.1591656658390; Mon, 08 Jun 2020 15:50:58 -0700 (PDT) MIME-Version: 1.0 References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> In-Reply-To: From: Tamas K Lengyel Date: Mon, 8 Jun 2020 16:50:22 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Razvan Cojocaru Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Andrei LUTAS , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?B?TWloYWkgRG9uyJt1?= , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 8, 2020 at 3:16 PM Razvan Cojocaru wrote: > > On 6/8/20 11:44 PM, Tamas K Lengyel wrote: > > On Mon, Jun 8, 2020 at 2:14 PM Razvan Cojocaru > > wrote: > >> > >> On 6/8/20 10:54 PM, Tamas K Lengyel wrote: > >>> On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru > >>>> And last but not least, the proper sequence is: 1. unsubscribe from > >>>> register write events, 2. process all events "still in the chamber" > >>>> (keep checking the ring buffer for a while), 3. detach from the guest > >>>> (disable the vm_event subsystem). Not ideal perhaps (in that it's not > >>>> guaranteed that a VCPU won't resume after a longer period than our > >>>> timeout), but if the sequence is followed there should be no guest hangs > >>>> or crashes (at least none that we or our clients have observed so far). > >>> > >>> Incorrect. That's not enough. You also have to wait for all the vCPUs > >>> to get scheduled before disabling vm_event or otherwise the emulation > >>> is skipped entirely. Please read the patch message. If the user > >>> decides to disable vm_event after getting a CR3 event delivered, the > >>> CR3 never gets updated and results in the guest crashing in > >>> unpredictable ways. Same happens with all the other registers. > >> > >> I did read the patch message. As I've previously stated ("it's not > >> guaranteed that a VCPU won't resume after a longer period than our > >> timeout"), it's not ideal, and I've made no claim that the problem does > >> not exist or that it shouldn't be fixed - but really if you've got a > >> VCPU that will wait more than a couple of seconds to get scheduled then > >> you've got a bigger problem with the VM. > > > > Sorry, missed the part where you say you knew about this issue. We > > didn't and it was absolutely not documented anywhere and certainly not > > mentioned in the original patch that added the feature. It literally > > took us years to figure out what the hell is going on. While as you it > > can be a couple seconds before its safe to disable it can be a lot > > longer depending on the system state, how many VMs are running and how > > many vCPUs are active on the VM. There is absolutely necessary > > use-cases where you want to keep the VM paused after a CR3 event is > > received and exit vm_event afterwards. This bug totally blocks those > > use-cases. Not to mention that it's a total mess having an interface > > where the user has to guess when its safe to do something. If this was > > pointed out when the patch was made I would have objected to that > > being merged. > > No, we didn't know about the issue. It's apparently not my most eloquent > evening. I was merely saying that I did understand what the issue was > from your description, and offering an explanation on why we've never > seen this in QA or production. Of course the issue would have been > mentioned at least (but ideally not exist to begin with) had it been known. > > We do take several passes through the ring buffer (and as a side-effect > reduce the probability of a race occuring to almost zero), but we do > that to make sure we've cleaned up all EPT vm_events; the fact that it > has helped with _this_ issue is a coincidence. > > IIRC Windows, at least, will be upset if a VCPU is stuck for too long. > > As for how the vm_event system behaves: > > 1. A security application that is unable to _prevent_ things being done > to a system is not doing a very good job, since in that case you can > only collect stats and not veto anything. I would argue that the default > for such a monitoring application should be the current one (all events > should be pre-action). Not all security applications require this though. Malware analysis where stealth is required would absolutely not want this side-effect to be visible to the guest where malware could use it to determine that it's being monitored. So I don't buy into this argument. > > 2. This is further supported by the fact that that's exactly how the EPT > vm_events work: you get a "I want to write to this page" event _before_ > the write occurs. If register writes behave differently, you have _two_ > different models: one where you get an event post-action, and one where > you get one pre-action. Whether you get an event before or after the effects of the event have been applied to the system state shouldn't matter as long as you can revert that action. I wouldn't care either way to be the default. But having a default that breaks other use-cases is unacceptable. Tamas From xen-devel-bounces@lists.xenproject.org Mon Jun 08 22:54:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 22:54:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQeY-000211-11; Mon, 08 Jun 2020 22:54:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQeW-00020t-R3 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 22:54:00 +0000 X-Inumbo-ID: f110ce00-a9da-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f110ce00-a9da-11ea-b7bb-bc764e2007e4; Mon, 08 Jun 2020 22:54:00 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6A0DD2076A; Mon, 8 Jun 2020 22:53:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591656839; bh=aFtqwt+bYOZhJ7U9irm3TzEiOtvg48f3YiInMbcBYs0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sV9brVTS0fbsMYHJ/0OiYUYepwLpKHZZvVEPsCcTclhj201DpvYC6IxwM1XDwdEIe K1aFJ5vaHAov9BwrlY9IHX4mYNHZkTNxt1DgO7EyhoVEcdrayUCUJJ00a6kr5y+QET 7Agxg++7d8MkC5wB88ZPCM3NNvh4ps0v1mIPE2Lo= Date: Mon, 8 Jun 2020 15:53:58 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Christoph Hellwig Subject: Re: [PATCH v2 01/11] swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses In-Reply-To: <20200608070411.GA15742@infradead.org> Message-ID: References: <20200603222247.11681-1-sstabellini@kernel.org> <20200608070411.GA15742@infradead.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Stefano Stabellini , konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Christoph, Thanks you for the review. On Mon, 8 Jun 2020, Christoph Hellwig wrote: > Well, this isn't just RPi4, but basically any ARM or ARM64 system > with non-coherent DMA (which is most of them). Well... yes :-) > > + struct page *pg; > > Please spell out page. OK > > > > if (hwdev && hwdev->coherent_dma_mask) > > dma_mask = hwdev->coherent_dma_mask; > > @@ -346,9 +347,11 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t size, void *vaddr, > > /* Convert the size to actually allocated. */ > > size = 1UL << (order + XEN_PAGE_SHIFT); > > > > + pg = is_vmalloc_addr(vaddr) ? vmalloc_to_page(vaddr) : > > + virt_to_page(vaddr); > > Please use plain old if/else to make this more readable. Sure From xen-devel-bounces@lists.xenproject.org Mon Jun 08 22:55:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 22:55:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQgB-00027c-Ca; Mon, 08 Jun 2020 22:55:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQg9-00027Q-DH for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 22:55:41 +0000 X-Inumbo-ID: 2cf23418-a9db-11ea-b2c4-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2cf23418-a9db-11ea-b2c4-12813bfff9fa; Mon, 08 Jun 2020 22:55:40 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DE7B8206D5; Mon, 8 Jun 2020 22:55:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591656940; bh=lmj78NsywzOH58ADrFq/+/zw3NLJPj16X1Kl9wTzZlA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=vxd2TBISH8H0Cfr4Y2boYussvZELUi1dGQYCN0391gCqf+M+zEHTxMJ3eiBCXwo/m Qcaay/hGXQIgfxgQfJp6K0fsW1H0JquhtId6jMP4h7XA9wKQlvbZd8pIDvL8CaAR+0 VU9uq18isLanuFMVY8NzMiP+1IEas3OaCgSqXiUI= Date: Mon, 8 Jun 2020 15:55:39 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Christoph Hellwig Subject: Re: [PATCH v2 03/11] swiotlb-xen: add struct device* parameter to xen_phys_to_bus In-Reply-To: <20200608070507.GB15742@infradead.org> Message-ID: References: <20200603222247.11681-3-sstabellini@kernel.org> <20200608070507.GB15742@infradead.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Stefano Stabellini , konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 8 Jun 2020, Christoph Hellwig wrote: > On Wed, Jun 03, 2020 at 03:22:39PM -0700, Stefano Stabellini wrote: > > From: Stefano Stabellini > > > > The parameter is unused in this patch. > > No functional changes. > > This looks weird. I'm pretty sure you are going to use it later, but > why not just add the argument when it actually is used? It is just a matter of taste. Xen reviewers tend to ask for splitting patches into small chunks, especially large verbose non-functional changes like renaming or adding parameters. It is supposed to make it easier to review, to make it easier not to get distracted by renaming/non-functional changes while looking at the important changes. As a contributor, I am happy either way. From xen-devel-bounces@lists.xenproject.org Mon Jun 08 23:07:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 23:07:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQr6-00034T-EE; Mon, 08 Jun 2020 23:07:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQr6-00034O-1L for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 23:07:00 +0000 X-Inumbo-ID: c16e39e2-a9dc-11ea-b2c4-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c16e39e2-a9dc-11ea-b2c4-12813bfff9fa; Mon, 08 Jun 2020 23:06:59 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6C48520820; Mon, 8 Jun 2020 23:06:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591657618; bh=9kgiWfc80bQ1pFTP10CoDvlD9i3E2sMoZB2p3Vvgd/g=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=IAKP9+uyhx+Mw+/ttmtWvmUV5DWr7Hx4rynsr/VlhWY7naVEcoN2oD/N3/5SjrSVB EmHPS5CiBaqDmNLIqVqDyRmUgYL0/hy7nAFMhxlSh1iB+5l18sVCmDe/ECVJA17l06 HJUi2skFlwTFsob6tOCCspquwIIueUlnqfhHl8Bo= Date: Mon, 8 Jun 2020 16:06:57 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Christoph Hellwig Subject: Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations In-Reply-To: <20200608070850.GD15742@infradead.org> Message-ID: References: <20200603222247.11681-8-sstabellini@kernel.org> <20200608070850.GD15742@infradead.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Stefano Stabellini , konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 8 Jun 2020, Christoph Hellwig wrote: > On Wed, Jun 03, 2020 at 03:22:44PM -0700, Stefano Stabellini wrote: > > From: Stefano Stabellini > > > > With some devices physical addresses are different than dma addresses. > > To be able to deal with these cases, we need to call phys_to_dma on > > physical addresses (including machine addresses in Xen terminology) > > before returning them from xen_swiotlb_alloc_coherent and > > xen_swiotlb_map_page. > > > > We also need to convert dma addresses back to physical addresses using > > dma_to_phys in xen_swiotlb_free_coherent and xen_swiotlb_unmap_page if > > we want to do any operations on them. > > > > Call dma_to_phys in is_xen_swiotlb_buffer. > > Call phys_to_dma in xen_phys_to_bus. > > Call dma_to_phys in xen_bus_to_phys. > > > > Everything is taken care of by these changes except for > > xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a > > few explicit phys_to_dma/dma_to_phys calls. > > > > Signed-off-by: Stefano Stabellini > > Tested-by: Corey Minyard > > Tested-by: Roman Shaposhnik > > --- > > Changes in v2: > > - improve commit message > > --- > > drivers/xen/swiotlb-xen.c | 22 ++++++++++++---------- > > 1 file changed, 12 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c > > index 0a6cb67f0fc4..60ef07440905 100644 > > --- a/drivers/xen/swiotlb-xen.c > > +++ b/drivers/xen/swiotlb-xen.c > > @@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) > > > > dma |= paddr & ~XEN_PAGE_MASK; > > > > - return dma; > > + return phys_to_dma(dev, dma); > > So looking at this function: > > The dma name for something passed to phys_to_dma is really > weird. Yeah, that is true, I am not sure why I chose that confusing name. I'll rename it. > The fact that the comments says don't use XEN_PFN_PHYS > beause of the type mismatch while nothing but swiotlb-xen is the only > user of XEN_PFN_PHYS is also weird. I think XEN_PFN_PHYS needs to move > to swiotlb-xen first, then use a hardcoded u64 for the size, and the > split the function into a phys_to_xen_phys (or so) function where > the result gets passed to phys_to_dma. I understand what you are suggesting about having something like: xen_phys_to_dma(...) { phys_addr_t phys = xen_phys_to_bus(dev, paddr) return phys_to_dma(phys); } I thought about it myself. I'll do it. But I don't think I understood the comment about XEN_PFN_PHYS. > Similar for the reverse direction. OK From xen-devel-bounces@lists.xenproject.org Mon Jun 08 23:13:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 23:13:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQwy-0003tr-3j; Mon, 08 Jun 2020 23:13:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQww-0003tm-SZ for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 23:13:02 +0000 X-Inumbo-ID: 99b83a32-a9dd-11ea-b2c4-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 99b83a32-a9dd-11ea-b2c4-12813bfff9fa; Mon, 08 Jun 2020 23:13:02 +0000 (UTC) Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D77AF208C7; Mon, 8 Jun 2020 23:13:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591657981; bh=ykA2/1B6WlQZ3TXxlaaNUqKEm5FMxSR7j0S3cwhJ6Vk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ADKYFVZe8XuzibmgVvYqd1ZF5DH2wVEwOI0JxgwuwfXbvwsi9eGV1qS40aH1c7dmM FZd3oAHFc9KjMGAxMooxYYNDrEVa1KZ0sgdG89IcweTqUMpIXcU6mjWOamVrsp2bxc XpaMxvHc6ahoV5zdcWtxb1AG/GEbuczUvr1XaZzM= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH AUTOSEL 5.6 042/606] x86: Fix early boot crash on gcc-10, third try Date: Mon, 8 Jun 2020 19:02:47 -0400 Message-Id: <20200608231211.3363633-42-sashal@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200608231211.3363633-1-sashal@kernel.org> References: <20200608231211.3363633-1-sashal@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Greg Kroah-Hartman , Sergei Trofimovich , linux-sparse@vger.kernel.org, xen-devel@lists.xenproject.org, Borislav Petkov , Kalle Valo Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Borislav Petkov commit a9a3ed1eff3601b63aea4fb462d8b3b92c7c1e7e upstream. ... or the odyssey of trying to disable the stack protector for the function which generates the stack canary value. The whole story started with Sergei reporting a boot crash with a kernel built with gcc-10: Kernel panic — not syncing: stack-protector: Kernel stack is corrupted in: start_secondary CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.6.0-rc5—00235—gfffb08b37df9 #139 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M—D3H, BIOS F12 11/14/2013 Call Trace: dump_stack panic ? start_secondary __stack_chk_fail start_secondary secondary_startup_64 -—-[ end Kernel panic — not syncing: stack—protector: Kernel stack is corrupted in: start_secondary This happens because gcc-10 tail-call optimizes the last function call in start_secondary() - cpu_startup_entry() - and thus emits a stack canary check which fails because the canary value changes after the boot_init_stack_canary() call. To fix that, the initial attempt was to mark the one function which generates the stack canary with: __attribute__((optimize("-fno-stack-protector"))) ... start_secondary(void *unused) however, using the optimize attribute doesn't work cumulatively as the attribute does not add to but rather replaces previously supplied optimization options - roughly all -fxxx options. The key one among them being -fno-omit-frame-pointer and thus leading to not present frame pointer - frame pointer which the kernel needs. The next attempt to prevent compilers from tail-call optimizing the last function call cpu_startup_entry(), shy of carving out start_secondary() into a separate compilation unit and building it with -fno-stack-protector, was to add an empty asm(""). This current solution was short and sweet, and reportedly, is supported by both compilers but we didn't get very far this time: future (LTO?) optimization passes could potentially eliminate this, which leads us to the third attempt: having an actual memory barrier there which the compiler cannot ignore or move around etc. That should hold for a long time, but hey we said that about the other two solutions too so... Reported-by: Sergei Trofimovich Signed-off-by: Borislav Petkov Tested-by: Kalle Valo Cc: Link: https://lkml.kernel.org/r/20200314164451.346497-1-slyfox@gentoo.org Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/stackprotector.h | 7 ++++++- arch/x86/kernel/smpboot.c | 8 ++++++++ arch/x86/xen/smp_pv.c | 1 + include/linux/compiler.h | 6 ++++++ init/main.c | 2 ++ 5 files changed, 23 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/stackprotector.h b/arch/x86/include/asm/stackprotector.h index 91e29b6a86a5..9804a7957f4e 100644 --- a/arch/x86/include/asm/stackprotector.h +++ b/arch/x86/include/asm/stackprotector.h @@ -55,8 +55,13 @@ /* * Initialize the stackprotector canary value. * - * NOTE: this must only be called from functions that never return, + * NOTE: this must only be called from functions that never return * and it must always be inlined. + * + * In addition, it should be called from a compilation unit for which + * stack protector is disabled. Alternatively, the caller should not end + * with a function call which gets tail-call optimized as that would + * lead to checking a modified canary value. */ static __always_inline void boot_init_stack_canary(void) { diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 69881b2d446c..9674321ce3a3 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -262,6 +262,14 @@ static void notrace start_secondary(void *unused) wmb(); cpu_startup_entry(CPUHP_AP_ONLINE_IDLE); + + /* + * Prevent tail call to cpu_startup_entry() because the stack protector + * guard has been changed a couple of function calls up, in + * boot_init_stack_canary() and must not be checked before tail calling + * another function. + */ + prevent_tail_call_optimization(); } /** diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c index 802ee5bba66c..0cebe5db691d 100644 --- a/arch/x86/xen/smp_pv.c +++ b/arch/x86/xen/smp_pv.c @@ -92,6 +92,7 @@ asmlinkage __visible void cpu_bringup_and_idle(void) cpu_bringup(); boot_init_stack_canary(); cpu_startup_entry(CPUHP_AP_ONLINE_IDLE); + prevent_tail_call_optimization(); } void xen_smp_intr_free_pv(unsigned int cpu) diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 034b0a644efc..448c91bf543b 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -356,4 +356,10 @@ static inline void *offset_to_ptr(const int *off) /* &a[0] degrades to a pointer: a different type from an array */ #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0])) +/* + * This is needed in functions which generate the stack canary, see + * arch/x86/kernel/smpboot.c::start_secondary() for an example. + */ +#define prevent_tail_call_optimization() mb() + #endif /* __LINUX_COMPILER_H */ diff --git a/init/main.c b/init/main.c index 8ee04f875b21..6bcad75d60ad 100644 --- a/init/main.c +++ b/init/main.c @@ -1032,6 +1032,8 @@ asmlinkage __visible void __init start_kernel(void) /* Do the rest non-__init'ed, we're now alive */ arch_call_rest_init(); + + prevent_tail_call_optimization(); } /* Call all constructor functions linked into the kernel. */ -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 08 23:42:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 08 Jun 2020 23:42:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiROr-0006Oe-Io; Mon, 08 Jun 2020 23:41:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiROq-0006OZ-Dr for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 23:41:52 +0000 X-Inumbo-ID: a02323c4-a9e1-11ea-8496-bc764e2007e4 Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a02323c4-a9e1-11ea-8496-bc764e2007e4; Mon, 08 Jun 2020 23:41:51 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id e12so14874286eds.2 for ; Mon, 08 Jun 2020 16:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0SGT/xqyswMR4HEMWjxUb0fTo55TAfwIiVwxif8Zu+0=; b=rNA8+WLhOAWTRCMIA0chx5jqMvaWY6W5/4IGUKOTAM8U0sp5eMCvcNnqwsrkwcmBDA fdaetF2roGkSwuKfv1YGXV1mr9pL/15hKuto+wkeJ2Y7e47HOBiXP02VvP+1Utud1FQn Xm3VHlxa5vAjI/nt63grfTfKvStpGY5Xk6/jyDpS31doU4YjcrnMlnBQdtrGviDpEhC5 oFBB0DfdI5Hz1fmOo3q0yup+hTZ05Gzdnl2l/7Q8R2/MFCFKN3d7ydL/Wb18Dz3fXQ+d H/SCC0Uz4Tw6u8DhwWSf8JMoUMiph1lcw0MLDHoSVL39yIA59TUTXPgnCotP3ZDGHfpZ IheA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0SGT/xqyswMR4HEMWjxUb0fTo55TAfwIiVwxif8Zu+0=; b=WYD4v+PVmpaqbAswm6nXpYx39ea6YqfoDCxGjh55i1eMBWZnej/xwEXM3xvj6nIKXY 2m/DSlsSTe5NjpTIu4f7astzQsvuEUM/XsgPpM1cAYJm4cFn8IqZtU0kwODvYMRI/WMB 95b76x7BksRDpor81DpdYYaROHIvyTHV2mmm1Y+KkdWzMJK86MX3yBL04o05vhxLtEJo 4wZ0wtzmQBLT0uyIfg2cl9M0rehZ1jgkIY9KNHwFYAZKYv4jaqd4nZbcZVgTEmM7ZfM0 UbQpr1qw2foqN8QPKJ1GZvUVP5fNZwd/YWyAdzuKwVDhjZNf6cPhK82dGTUtX63lO9Sa kxxg== X-Gm-Message-State: AOAM533mBRaQ2qJJ33eSEEZEKWBCbp6HryZMNRoSs5X+j3fQozploWLT Cxqtm543pPYh1FOu8wRToQC1dXOe7pY= X-Google-Smtp-Source: ABdhPJwqvUYxfCbu/lCjrrmkOCcwPagSyG4Srq6bnZZKR5KLWqjot1/kgDdMRe8fdmCbTgf9c5LxxA== X-Received: by 2002:a50:f106:: with SMTP id w6mr24462675edl.131.1591659710104; Mon, 08 Jun 2020 16:41:50 -0700 (PDT) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com. [209.85.221.46]) by smtp.gmail.com with ESMTPSA id j31sm13668017edb.12.2020.06.08.16.41.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 16:41:49 -0700 (PDT) Received: by mail-wr1-f46.google.com with SMTP id r7so19315714wro.1 for ; Mon, 08 Jun 2020 16:41:49 -0700 (PDT) X-Received: by 2002:a5d:490f:: with SMTP id x15mr1181633wrq.259.1591659708778; Mon, 08 Jun 2020 16:41:48 -0700 (PDT) MIME-Version: 1.0 References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> <4cd66e91-3c7e-6af6-e789-9cca5109dc18@bitdefender.com> In-Reply-To: <4cd66e91-3c7e-6af6-e789-9cca5109dc18@bitdefender.com> From: Tamas K Lengyel Date: Mon, 8 Jun 2020 17:41:12 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Razvan Cojocaru Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Andrei LUTAS , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?B?TWloYWkgRG9uyJt1?= , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 8, 2020 at 5:14 PM Razvan Cojocaru wrote: > > On 6/9/20 1:50 AM, Tamas K Lengyel wrote: > > On Mon, Jun 8, 2020 at 3:16 PM Razvan Cojocaru > > wrote: > >> 1. A security application that is unable to _prevent_ things being done > >> to a system is not doing a very good job, since in that case you can > >> only collect stats and not veto anything. I would argue that the default > >> for such a monitoring application should be the current one (all events > >> should be pre-action). > > > > Not all security applications require this though. Malware analysis > > where stealth is required would absolutely not want this side-effect > > to be visible to the guest where malware could use it to determine > > that it's being monitored. So I don't buy into this argument. > > Fair enough, in that case having both models supported should be fine. > I'll leave the rest of that conversation to my colleagues. > > >> 2. This is further supported by the fact that that's exactly how the EPT > >> vm_events work: you get a "I want to write to this page" event _before_ > >> the write occurs. If register writes behave differently, you have _two_ > >> different models: one where you get an event post-action, and one where > >> you get one pre-action. > > > > Whether you get an event before or after the effects of the event have > > been applied to the system state shouldn't matter as long as you can > > revert that action. I wouldn't care either way to be the default. But > > having a default that breaks other use-cases is unacceptable. > > You keep saying that as if I disagree. :) But we've already established > that the potential for a race condition has been found and needs to be > fixed. > > My only (minor) objection has been that a patch fixing the current model > would have been preferable to one that switches the default as a > workaround. Still, it's understandable that perhaps there's no time or > motivation for that. I've already sent two other patches that make it more manageable to disable the interface when this feature is used. Your colleagues are welcome to pick those up or send other fixes that they prefer. As I don't use this feature I won't be spending more time fixing it then what I've already spent on it. At this point collectively I probably spent weeks trying to just track the issue down as it was such an annoying bug to find. Tamas From xen-devel-bounces@lists.xenproject.org Tue Jun 09 00:10:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 00:10:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiRpz-0000Q4-Qg; Tue, 09 Jun 2020 00:09:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiRpx-0000Pz-NK for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 00:09:53 +0000 X-Inumbo-ID: 8a93e45e-a9e5-11ea-b2cd-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8a93e45e-a9e5-11ea-b2cd-12813bfff9fa; Tue, 09 Jun 2020 00:09:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4K2uYNbN+FbfYF5jz6z/pzbUe526X79AUyxyxFDuXFg=; b=kesLD+Mf1vLpt1h6aawrBE9X4 6HM7L1ACcgNfnDl3UkEOCaww+LJccOwOsRfhpS0YxGlrhs/Y6XSC3wIyJ8hl0budNoyRr2TAUMo+T YuYgpZivpC8vTJ3joHGQCzsKzuzSMdSQfs0A7y80ntfo9YJ8kY+x6leCD/NC/E4vI+mMg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiRpw-000535-CB; Tue, 09 Jun 2020 00:09:52 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiRpw-00089G-4E; Tue, 09 Jun 2020 00:09:52 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiRpw-0004RK-3G; Tue, 09 Jun 2020 00:09:52 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150925: FAIL X-Osstest-Failures: linux-linus:test-amd64-i386-xl::broken:regression linux-linus:test-amd64-i386-xl-qemut-win7-amd64::broken:regression linux-linus:test-amd64-amd64-qemuu-nested-amd::broken:regression linux-linus:test-amd64-i386-xl-raw::broken:regression linux-linus:test-amd64-coresched-i386-xl::broken:regression linux-linus:test-amd64-i386-qemut-rhel6hvm-amd::broken:regression linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict::broken:regression linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm::broken:regression linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd::broken:regression linux-linus:test-amd64-amd64-qemuu-nested-amd:hosts-allocate:broken:heisenbug linux-linus:test-amd64-i386-xl:hosts-allocate:broken:heisenbug linux-linus:test-amd64-i386-xl-raw:host-install(4):broken:heisenbug linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:host-install(4):broken:heisenbug linux-linus:test-amd64-i386-qemuu-rhel6hvm-amd:capture-logs(16):broken:heisenbug linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:syslog-server:broken:heisenbug linux-linus:test-amd64-i386-xl-raw:syslog-server:broken:heisenbug linux-linus:test-amd64-amd64-examine:syslog-server:broken:heisenbug linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:syslog-server:broken:heisenbug linux-linus:test-amd64-i386-xl-qemut-win7-amd64:syslog-server:broken:heisenbug linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:debian-hvm-install:fail:heisenbug linux-linus:test-amd64-coresched-i386-xl:guest-start/debian.repeat:fail:heisenbug linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:guest-start/redhat.repeat:fail:heisenbug linux-linus:test-amd64-i386-xl-qemut-win7-amd64:windows-install:fail:heisenbug linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:heisenbug linux-linus:test-amd64-i386-xl-raw:capture-logs(5):broken:nonblocking linux-linus:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:capture-logs(11):broken:nonblocking linux-linus:test-amd64-i386-qemut-rhel6hvm-amd:capture-logs(13):broken:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:capture-logs(11):broken:nonblocking linux-linus:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:capture-logs(5):broken:nonblocking linux-linus:test-amd64-coresched-i386-xl:capture-logs(21):broken:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=af7b4801030c07637840191c69eb666917e4135d X-Osstest-Versions-That: linux=9aa900c8094dba7a60dc805ecec1e9f720744ba1 From: osstest service owner Date: Tue, 09 Jun 2020 00:09:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150925 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150925/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl broken in 150920 test-amd64-i386-xl-qemut-win7-amd64 broken in 150920 test-amd64-amd64-qemuu-nested-amd broken in 150920 test-amd64-i386-xl-raw broken in 150920 test-amd64-coresched-i386-xl broken in 150920 test-amd64-i386-qemut-rhel6hvm-amd broken in 150920 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken in 150920 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm broken in 150920 test-amd64-i386-qemuu-rhel6hvm-amd broken in 150920 Tests which are failing intermittently (not blocking): test-amd64-amd64-qemuu-nested-amd 2 hosts-allocate broken in 150920 pass in 150925 test-amd64-i386-xl 2 hosts-allocate broken in 150920 pass in 150925 test-amd64-i386-xl-raw 4 host-install(4) broken in 150920 pass in 150925 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 4 host-install(4) broken in 150920 pass in 150925 test-amd64-i386-qemuu-rhel6hvm-amd 16 capture-logs(16) broken in 150920 pass in 150925 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 3 syslog-server broken in 150920 pass in 150925 test-amd64-i386-xl-raw 3 syslog-server broken in 150920 pass in 150925 test-amd64-amd64-examine 3 syslog-server broken in 150920 pass in 150925 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 syslog-server broken in 150920 pass in 150925 test-amd64-i386-xl-qemut-win7-amd64 3 syslog-server broken in 150920 pass in 150925 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install fail in 150920 pass in 150925 test-amd64-coresched-i386-xl 20 guest-start/debian.repeat fail in 150920 pass in 150925 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 150920 pass in 150925 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install fail in 150920 pass in 150925 test-amd64-amd64-examine 4 memdisk-try-append fail in 150920 pass in 150925 test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail pass in 150920 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-raw 5 capture-logs(5) broken in 150920 blocked in 150910 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 11 capture-logs(11) broken in 150920 blocked in 150910 test-amd64-i386-qemut-rhel6hvm-amd 13 capture-logs(13) broken in 150920 blocked in 150910 test-amd64-i386-xl-qemut-win7-amd64 11 capture-logs(11) broken in 150920 blocked in 150910 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 5 capture-logs(5) broken in 150920 never pass test-amd64-coresched-i386-xl 21 capture-logs(21) broken in 150920 never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 150920 never pass test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150910 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150910 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150910 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150910 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150910 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150910 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150910 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150910 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150910 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150910 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: linux af7b4801030c07637840191c69eb666917e4135d baseline version: linux 9aa900c8094dba7a60dc805ecec1e9f720744ba1 Last test of basis 150910 2020-06-07 20:10:01 Z 1 days Testing same since 150920 2020-06-08 03:35:33 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Ahmed Abdelsalam Ahmed S. Darwish Al Viro Alexander Fomichev Alexander Lobakin Alexandre Belloni Allen Hubbe Alok Prasad Amelie Delaunay Amit Sahrawat Andy Shevchenko Anson Huang Antoine Tenart Anupam Aggarwal Arindam Nath Arnd Bergmann Baolin Wang Benjamin Gaignard Bjorn Andersson Bruno Thomsen Chen Zhou Christophe JAILLET Chuhong Yuan Cong Wang Corentin Labbe Dafna Hirschfeld Dan Carpenter Dan Murphy Dave Jiang David S. Miller Dejin Zheng Denis Efremov Ding Xiang Florian Fainelli Fugang Duan Geert Uytterhoeven Grace Kao Guenter Roeck Gustavo A. R. Silva Hauke Mehrtens Heiner Kallweit Herbert Xu Ido Schimmel Igor Russkikh Jacopo Mondi Jakub Kicinski Jason Yan Jesper Dangaard Brouer Jiasen Lin Jiri Benc Johan Jonker John Hubbard John Johansen Jon Hunter Jon Maloy Jon Mason Jonathan Bakker Kees Cook Kevin P. Fleming Krzysztof Kozlowski Lad Prabhakar Lars Povlsen Light Hsieh Linus Torvalds Linus Walleij Logan Gunthorpe Maciej Grochowski Markus Elfring Martin Blumenstingl Mateusz Nosek Mauricio Faria de Oliveira Maxime Ripard Michal Vokáč Mika Westerberg Mike Rapoport Paolo Abeni Paul Cercueil Pavel Machek (CIP) Pavel Machek Qiushi Wu Ran Wang Rikard Falkeborn Rishabh Bhatnagar Rob Herring Robert Jarzmik Roberto Sassu Roelof Berg Rohit Maheshwari Sameeh Jubran Sanjay R Mehta Sean Wang Stefano Garzarella Thierry Reding Tiezhu Yang Tuong Lien Vadim Pasternak Valentin Longchamp Vasyl Gomonovych Venkata Narendra Kumar Gutta Vinay Kumar Yadav Vivek Trivedi Vladimir Zapolskiy Wang Hai Wei Yongjun Wesley Sheng Will Deacon Wolfram Sang yu kuai YueHaibing Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-amd64-i386-xl broken broken-job test-amd64-i386-xl-qemut-win7-amd64 broken broken-job test-amd64-amd64-qemuu-nested-amd broken broken-job test-amd64-i386-xl-raw broken broken-job test-amd64-coresched-i386-xl broken broken-job test-amd64-i386-qemut-rhel6hvm-amd broken broken-job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict broken broken-job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm broken broken-job test-amd64-i386-qemuu-rhel6hvm-amd broken Not pushing. (No revision log; it would be 3957 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 09 00:38:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 00:38:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiSHg-0002ue-82; Tue, 09 Jun 2020 00:38:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiSHe-0002uZ-Tl for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 00:38:30 +0000 X-Inumbo-ID: 8a42888a-a9e9-11ea-b2ce-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8a42888a-a9e9-11ea-b2ce-12813bfff9fa; Tue, 09 Jun 2020 00:38:30 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5DF5F207ED; Tue, 9 Jun 2020 00:38:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591663109; bh=dZEsuHc63lSqJBCxvHs+BfEmnrOBWd5r93zBgTcjIfE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=zmKl2ZEkH3EPkdd/jdWO6poHzl1BGkaJeJqk7D8IWfcwf0Oy+viDzCfDk0hL7we2P ZJgWIIVk9+QTjD+rtMZELhnH2B5Qf0fORt1zwpbXbC6xxcsEeq1IDhEyN/iT784RaK kOjRS48WEd1Wq7jjCOild9hhx4Jod2X0IvbE8uII= Date: Mon, 8 Jun 2020 17:38:28 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Christoph Hellwig Subject: Re: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_* In-Reply-To: <20200608071221.GF15742@infradead.org> Message-ID: References: <20200603222247.11681-10-sstabellini@kernel.org> <20200608071221.GF15742@infradead.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Stefano Stabellini , konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 8 Jun 2020, Christoph Hellwig wrote: > On Wed, Jun 03, 2020 at 03:22:46PM -0700, Stefano Stabellini wrote: > > From: Stefano Stabellini > > > > xen_dma_sync_for_cpu, xen_dma_sync_for_device, xen_arch_need_swiotlb are > > getting called passing dma addresses. On some platforms dma addresses > > could be different from physical addresses. Before doing any operations > > on these addresses we need to convert them back to physical addresses > > using dma_to_phys. > > > > Add dma_to_phys calls to xen_dma_sync_for_cpu, xen_dma_sync_for_device, > > and xen_arch_need_swiotlb. > > > > dma_cache_maint is fixed by the next patch. > > The calling conventions because really weird now because > xen_dma_sync_for_{device,cpu} already get both a phys_addr_t and > a dma_addr_t. > > > > > - if (pfn_valid(PFN_DOWN(handle))) > > + if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle)))) > > But here we translate the dma address to a phys addr > > > arch_sync_dma_for_cpu(paddr, size, dir); > > While this still uses the passed in paddr. I think the uses of > addresses in this code really needs a major rethink. Yeah, the pfn_valid check is a bit weird by definition because we are using it to understand whether the address belong to us or to another VM. To do the pfn_valid check we need to translate the dma address into something the CPU understands, hence, the dma_to_phys call. Why can't we use the already-provided paddr? Because paddr has been translated twice: 1) from dma to maybe-foreign phys address (could be ours, or another VM) 2) from maybe-foreign address to local (using our local mapping of the foreign page) In fact, it would be clearer if we had all three addresses as parameters of xen_dma_sync_for_cpu: the dma address, the maybe-foreign physical address (we tend to call it xenbus address, baddr), the local physical address. Something like: void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, phys_addr_t baddr, phys_addr_t paddr, size_t size, enum dma_data_direction dir) { if (pfn_valid(baddr)) arch_sync_dma_for_cpu(paddr, size, dir); else if (dir != DMA_TO_DEVICE) dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL); } From xen-devel-bounces@lists.xenproject.org Tue Jun 09 03:47:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 03:47:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiVDt-0003M8-Pw; Tue, 09 Jun 2020 03:46:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiVDs-0003M3-8v for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 03:46:48 +0000 X-Inumbo-ID: d7b691b4-aa03-11ea-b2d6-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d7b691b4-aa03-11ea-b2d6-12813bfff9fa; Tue, 09 Jun 2020 03:46:47 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 290FA20775; Tue, 9 Jun 2020 03:46:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591674406; bh=CLVBI8sBETJZRH84szWPKCZET1iujXSN9tbuwfeKbHg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=szvpOm92h48+ZA24If+05vk6Wfwxi/L131yipzhT9g8mQHN4DH0DTIT7B+iggFhDF X57oYj2xWOE309TL6GGGSydM1y7maSWzRK7sQ/B6AMBiK4FDXcucquhA+GlQKDnfXn 8/07/ySp7LJP2CL1E0l3cM4c8dfuklUuSvf8DBRo= Date: Mon, 8 Jun 2020 20:46:45 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Stefano Stabellini Subject: Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations In-Reply-To: Message-ID: References: <20200603222247.11681-8-sstabellini@kernel.org> <20200608070850.GD15742@infradead.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, Christoph Hellwig , xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 8 Jun 2020, Stefano Stabellini wrote: > On Mon, 8 Jun 2020, Christoph Hellwig wrote: > > On Wed, Jun 03, 2020 at 03:22:44PM -0700, Stefano Stabellini wrote: > > > From: Stefano Stabellini > > > > > > With some devices physical addresses are different than dma addresses. > > > To be able to deal with these cases, we need to call phys_to_dma on > > > physical addresses (including machine addresses in Xen terminology) > > > before returning them from xen_swiotlb_alloc_coherent and > > > xen_swiotlb_map_page. > > > > > > We also need to convert dma addresses back to physical addresses using > > > dma_to_phys in xen_swiotlb_free_coherent and xen_swiotlb_unmap_page if > > > we want to do any operations on them. > > > > > > Call dma_to_phys in is_xen_swiotlb_buffer. > > > Call phys_to_dma in xen_phys_to_bus. > > > Call dma_to_phys in xen_bus_to_phys. > > > > > > Everything is taken care of by these changes except for > > > xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a > > > few explicit phys_to_dma/dma_to_phys calls. > > > > > > Signed-off-by: Stefano Stabellini > > > Tested-by: Corey Minyard > > > Tested-by: Roman Shaposhnik > > > --- > > > Changes in v2: > > > - improve commit message > > > --- > > > drivers/xen/swiotlb-xen.c | 22 ++++++++++++---------- > > > 1 file changed, 12 insertions(+), 10 deletions(-) > > > > > > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c > > > index 0a6cb67f0fc4..60ef07440905 100644 > > > --- a/drivers/xen/swiotlb-xen.c > > > +++ b/drivers/xen/swiotlb-xen.c > > > @@ -64,16 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct device *dev, phys_addr_t paddr) > > > > > > dma |= paddr & ~XEN_PAGE_MASK; > > > > > > - return dma; > > > + return phys_to_dma(dev, dma); > > > > So looking at this function: > > > > The dma name for something passed to phys_to_dma is really > > weird. > > Yeah, that is true, I am not sure why I chose that confusing name. I'll > rename it. > > > > The fact that the comments says don't use XEN_PFN_PHYS > > beause of the type mismatch while nothing but swiotlb-xen is the only > > user of XEN_PFN_PHYS is also weird. I think XEN_PFN_PHYS needs to move > > to swiotlb-xen first, then use a hardcoded u64 for the size, and the > > split the function into a phys_to_xen_phys (or so) function where > > the result gets passed to phys_to_dma. > > I understand what you are suggesting about having something like: > > xen_phys_to_dma(...) > { > phys_addr_t phys = xen_phys_to_bus(dev, paddr) > return phys_to_dma(phys); > } > > I thought about it myself. I'll do it. > > But I don't think I understood the comment about XEN_PFN_PHYS. You meant to move the #define from the header to swiotlb-xen.c, didn't you, and to use a cast to u64 instead of phys_addr_t? From xen-devel-bounces@lists.xenproject.org Tue Jun 09 04:17:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 04:17:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiVh4-0005xe-Vg; Tue, 09 Jun 2020 04:16:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiQyH-00041E-D8 for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 23:14:25 +0000 X-Inumbo-ID: ca443da4-a9dd-11ea-8496-bc764e2007e4 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe0d::72c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ca443da4-a9dd-11ea-8496-bc764e2007e4; Mon, 08 Jun 2020 23:14:24 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gC8E0foYlAxg7I3/fz8jUx1isFQyI/uwZ8EZUC/VP7QpOlcEhN+KdWjQ6AFO6/XFbAmIwQa+iRBP5EDF65uzk7wg46VtR0+gYSMPB3PggGrBzVaA2n9KUXefUhETj9jaiprQxmd3/ffyHfGNVFZtDRIMs8bcyw/8Y67VR3FRNn7Kt0RRrFrPcqdWmfDZMKXnqp0iVZzvEbPmuz+EXh9fwqnTDGFnvymuPTkyoImfy4a9zI1TlaW5tFiddUG5AP51M2pZvftJaYrWTMyy8Tw3YWaAaHp6e34Ho29EAzfW9piJOuNKX4gg4wQXHIHGoqkvOzqzVaI+RuC3U3FUVbjGrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0z/blzsh626fEpKcpbfFnHTuK9nMDcgSPsH5WU4t0oQ=; b=X0whqMCJ2wiCgTTw18CBIKWC/lUDjzrc2gpBYkbsTELpFzGPR1N1n0YnIBhjTWIfNJ+61E1RLGjj2Ub0UtuGP2lx/7aNUp2u5ggN0zhM0Sau+XRE6gOGFjvX+26Uy0wpmL4cr15QVqUDhC8xyY62dX/F+QqpTJcLZDVKcRaWHiG3GEWdoXGYj/x6rif8hqhWErWT4RzwgCo2OMcuNdUp3hO5m/RBbPsuWXBIne+eDEd2UY/H8tyhP7+M2CyUqKJBIspuLErOvzH9PVDjKh/nfL8MwkoeamqHxH6WUwzVpoP8UCqcJAu2RJ5f2VgcX4gRvTelQTK7xz4hSI5vcUYqAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bitdefender.com; dmarc=pass action=none header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0z/blzsh626fEpKcpbfFnHTuK9nMDcgSPsH5WU4t0oQ=; b=vhNgBXWk9s3ZZP3INRFDBNOURhg6AefZvI8ZK0hnyLj4CyEKS4oYvUNuXFX/XEKP8fqRqPURUa9TsVpciDIX/KD+LqdtuRrEaxq30otrqOui9NmKmZUPjxAaC6a2i3R7jrM+cJgIZniZirbKalWmCrpgd4bIunnlUED9qe0j65E= Authentication-Results: bitdefender.com; dkim=none (message not signed) header.d=none;bitdefender.com; dmarc=none action=none header.from=bitdefender.com; Received: from DB8PR02MB5434.eurprd02.prod.outlook.com (2603:10a6:10:e5::15) by DB8PR02MB5770.eurprd02.prod.outlook.com (2603:10a6:10:fa::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Mon, 8 Jun 2020 23:14:21 +0000 Received: from DB8PR02MB5434.eurprd02.prod.outlook.com ([fe80::3c22:239a:7f84:7572]) by DB8PR02MB5434.eurprd02.prod.outlook.com ([fe80::3c22:239a:7f84:7572%5]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 23:14:21 +0000 Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Tamas K Lengyel References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> From: Razvan Cojocaru Message-ID: <4cd66e91-3c7e-6af6-e789-9cca5109dc18@bitdefender.com> Date: Tue, 9 Jun 2020 02:14:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VE1PR08CA0007.eurprd08.prod.outlook.com (2603:10a6:803:104::20) To DB8PR02MB5434.eurprd02.prod.outlook.com (2603:10a6:10:e5::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.228.119] (82.137.38.55) by VE1PR08CA0007.eurprd08.prod.outlook.com (2603:10a6:803:104::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 23:14:19 +0000 X-Originating-IP: [82.137.38.55] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c3a6edf3-8919-48c5-586c-08d80c01ace0 X-MS-TrafficTypeDiagnostic: DB8PR02MB5770: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 042857DBB5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Z25PGDveBnUJUljtOl+kahz48XO5wBwinOMHl0J542V8N7vOCqNpRNv0Uw5AOq5Jl0A5foQ3eYJduX7CSNbSs5jHtRM78AkgIaiAfEMnrNxDm3Wep8erTynGgxANNlf+jYq08tLpGEie/lb1Za3qDm8GHNE4dj2ZtK8hAn8tjvTxyV1A09y0Q3Otj4SDJ+1a9BXvRHTOSWH1II9uDe2pN/X+Gl7ZF2mdVND3/yVNipH53oevFe5x9hzZaD/6Bg57TMCibuCYN19JEravMN6H7DgqZkat33hS5XKKJN8AaBbijCE3bNs2sGcabJzj4XPWOMnFPxR5IrbGesmMqfWZgrMGq2AuiKYYF93U1wQBQcZQWKImdWlj+7LDdTMFp3VE X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR02MB5434.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(31686004)(66574014)(8936002)(54906003)(36756003)(6666004)(52116002)(5660300002)(31696002)(83380400001)(2906002)(6916009)(2616005)(107886003)(4326008)(8676002)(956004)(53546011)(86362001)(16526019)(6486002)(186003)(66556008)(26005)(7416002)(66946007)(498600001)(16576012)(66476007)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: 1B2Okm8H2TBrbJ3+AW1LmJVO/WFDtWk5Nsjo3cVEjMC+sg95MieaBBZAYMeK4xrf0pePsJ28T1ddtYUsUJMA25V4v7QXUMJ0WeUXrs4F9DvT+v6li3wgLJIMrQ2yDT3tSqxYqIE/y5gBGc4f79BCm4xjwYc1omVNYSaNAAmbMNLREtWcqerXQ1H6EQJyRzVENwOKGJI0CwLbgs/YwaXhcl+o7kGdynTLiUukNgItDn5D3qjJqw8uqsA6yOQhWz1OdBelJ99YQWvJv2Gd9owQVyOs0oGrmvfKkflN9Wz53snPk8kV0oVGeH8LlI/yr89ssTfRo1XZ/YOUoogX5t16X+p7wc8pIdd5HVtHrEfZGre8gC6na2j/IDo64dVsYX9DcvQn/Qt4dy1pUNXmACeDDAsgWiOjXcnwTVPl2pI7VO6nuPh6gQuBpSqpeyDXZDcc2LZkOn9tsvi0a8SIk56cBernEqGk90LmdUpdVoT5jvE= X-OriginatorOrg: bitdefender.com X-MS-Exchange-CrossTenant-Network-Message-Id: c3a6edf3-8919-48c5-586c-08d80c01ace0 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2020 23:14:20.9518 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Xt3/F897JgkI2y5Ib4y/b2FqPxkcHIPZH43CrvsvScOmG9QEbjP8nyqYmn/UDWNrT/vDysF0S3GddasKVAR3mHYgiJ6SBgcIR/8JbBUoCK0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR02MB5770 X-Mailman-Approved-At: Tue, 09 Jun 2020 04:16:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Andrei LUTAS , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?Q?Mihai_Don=c8=9bu?= , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/9/20 1:50 AM, Tamas K Lengyel wrote: > On Mon, Jun 8, 2020 at 3:16 PM Razvan Cojocaru > wrote: >> 1. A security application that is unable to _prevent_ things being done >> to a system is not doing a very good job, since in that case you can >> only collect stats and not veto anything. I would argue that the default >> for such a monitoring application should be the current one (all events >> should be pre-action). > > Not all security applications require this though. Malware analysis > where stealth is required would absolutely not want this side-effect > to be visible to the guest where malware could use it to determine > that it's being monitored. So I don't buy into this argument. Fair enough, in that case having both models supported should be fine. I'll leave the rest of that conversation to my colleagues. >> 2. This is further supported by the fact that that's exactly how the EPT >> vm_events work: you get a "I want to write to this page" event _before_ >> the write occurs. If register writes behave differently, you have _two_ >> different models: one where you get an event post-action, and one where >> you get one pre-action. > > Whether you get an event before or after the effects of the event have > been applied to the system state shouldn't matter as long as you can > revert that action. I wouldn't care either way to be the default. But > having a default that breaks other use-cases is unacceptable. You keep saying that as if I disagree. :) But we've already established that the potential for a race condition has been found and needs to be fixed. My only (minor) objection has been that a patch fixing the current model would have been preferable to one that switches the default as a workaround. Still, it's understandable that perhaps there's no time or motivation for that. Thanks for the work, Razvan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 04:17:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 04:17:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiVh4-0005xY-Mv; Tue, 09 Jun 2020 04:16:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiP87-00025z-GI for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 21:16:27 +0000 X-Inumbo-ID: 4f31e48c-a9cd-11ea-b7bb-bc764e2007e4 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown [40.107.7.102]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4f31e48c-a9cd-11ea-b7bb-bc764e2007e4; Mon, 08 Jun 2020 21:16:25 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AIgwRbf5VjnUiogij1+0HRFkMm3YCKXScGhMXJgbWmr+CBAUXrH535WM8YVJuwhBi4w1xO3RwAxgNuD91afHQMkuNsf+wpCoC8oAJdgEazlzvVB1i4l5FOVMB7np5iHqwprAGFEtRCpTvJushH2Y8OBuwLNvWd0bXJT7tHbRseDwO9dqRSFbgjVGfIjPmVUFEfKUVc8HLM67tp8Koa6g8yhkDw/SPsZHq0vCJgtWr0XI2BHfu+CoZcfGK3RtKsjFdwe+2Pqvv0NIhbg7xdShmSJ3MColsFcvvIUGB0Wz9Q2gNPXS33x/qUMlwX9MPMycAreVmm+2eH+SOEF9X6Py4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1BMyGPbmxiYGh7C6IwlCMGwsJeFFFqYdhaaLHnlr1MU=; b=HfyPkxwofWW40j8I3a+cT0cf1a3hiBWFtpuJtRK0WNLpEtwcFnHqPOZITDNIuP3XxDkcAltw+M5rP6ViQoaHPUFoVh+RundO7CHZN9/zE0XJQn/BqQqo0OdnxBoCzYsErpTSAOKZYfMWFuaB7cXju6AlYiK5eKgBn1EitqsNNCDqfqZu4O9GLUeb9Xi4IKL0wdMqcnL4uG7qTGmvZ4FWp6pabJfmzVS1c5c7E8aT4L8wSMt+ZHdZIuIHL2dvIRO8CijvK0YjHBnYiFA3tmXnXQrT6/5Gb8heR9Adlul1Cu6XVp0z4IMyFsaBrE1JDq9+5HHmJ8RJn62+CO9Qev39tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bitdefender.com; dmarc=pass action=none header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1BMyGPbmxiYGh7C6IwlCMGwsJeFFFqYdhaaLHnlr1MU=; b=IFje1UGsOi8VNYyQEYF7snF/MYG6vo5mAGfE9aRqLvZqmR5Fslhyuc4cw6q1Xn+27fG4BVIRxVTrVOK5ZekXGaLeqHqgTwr1WKnBtAS5bKoLKLduUtYm0fJWgiVu/nupgHhH5OioOYANmr29XR5GQYHvO13ereMWnBVlsU93css= Authentication-Results: bitdefender.com; dkim=none (message not signed) header.d=none;bitdefender.com; dmarc=none action=none header.from=bitdefender.com; Received: from DB8PR02MB5434.eurprd02.prod.outlook.com (2603:10a6:10:e5::15) by DB8PR02MB5564.eurprd02.prod.outlook.com (2603:10a6:10:e1::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Mon, 8 Jun 2020 21:16:22 +0000 Received: from DB8PR02MB5434.eurprd02.prod.outlook.com ([fe80::3c22:239a:7f84:7572]) by DB8PR02MB5434.eurprd02.prod.outlook.com ([fe80::3c22:239a:7f84:7572%5]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 21:16:22 +0000 Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Tamas K Lengyel References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> From: Razvan Cojocaru Message-ID: Date: Tue, 9 Jun 2020 00:16:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VI1PR06CA0131.eurprd06.prod.outlook.com (2603:10a6:803:a0::24) To DB8PR02MB5434.eurprd02.prod.outlook.com (2603:10a6:10:e5::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.228.119] (82.137.38.55) by VI1PR06CA0131.eurprd06.prod.outlook.com (2603:10a6:803:a0::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 21:16:21 +0000 X-Originating-IP: [82.137.38.55] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c59c2ed7-edc4-4156-c55c-08d80bf131df X-MS-TrafficTypeDiagnostic: DB8PR02MB5564: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 042857DBB5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6egoxf1Qs/itY71To2uEADxLcQ3JFd0DW6zD/eP7LPHqliJT1lCRU+YZg6842awWxTWQUMiTuLZoKENT8e/ru83bPVulrfmDH/DS9bz3kly27Exp8FSmO/jseSVZEwE8H6KRBqdzVLwfFQs0RPD81DagrLaVxuHMEEt+U5F91CmJNNCTYgHfIiqSbIlJ2HDflTbTXXdyjDkDdG6MfRvvjI8YPIrDbGv+/nCcGaSkqhZnmuu1Gwb7CFuUtsDO3yBKmB8CZxbvmWz2DTrDKZ3K/SV37TK1QC1F+gN3Avd4sZaUHrI+EfNhfb50STh3EU3JxvQOhoO3K1fkRDDRBX65spFTFitTqWloaWKIXEXa5o2/kuG7fzdO11z9kP3Ys75c X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR02MB5434.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(136003)(396003)(39860400002)(376002)(366004)(26005)(186003)(83380400001)(16526019)(7416002)(8676002)(8936002)(4326008)(86362001)(31686004)(107886003)(478600001)(6666004)(31696002)(5660300002)(66946007)(66556008)(16576012)(6916009)(316002)(54906003)(6486002)(36756003)(52116002)(2616005)(66476007)(53546011)(956004)(2906002)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: qk5VsOYQzqvkfcccRj+FF+Q9YHRbY2qePXPj9K54Vm0xXranBPuRTca8V/v53SvA3ylke0RcvovVryeRHEqYRAyVTTJhA6CNtBIslMtLePypph3HyVy8WvTMhpmMMoSdOFhWJiK5Q4aExwg/LthSBKHqwpqgfZIaofnzyPOIYSKgviJd8gD+O27pZnhHz6N0EzFQk74+AwWvv/iz+MOJHQt4NnQiz1FtIzNX1kHEgXmKBGpGuwE9TxQJf1ztf3hgEa3POOROZwwvIVw5pmUai2IFWANqd2EuMYFdsAijTG4Pr9tfZWg1hYGgKZJcAo+4h/gkDJWFUUiif0ycAMp0NfyvEXJkkPbSH2JAVUtrhg+jQoRBkYCPhCvEi6whWejUpHNV1WXG4O0SJevxmJcKnZySYJYg5h46SPzTNydltjX8K8mikiFvk+HE4A4onJNkzfiFwwG9y80TUjHl2shss305etPfsppdyee+8Fkv5R4= X-OriginatorOrg: bitdefender.com X-MS-Exchange-CrossTenant-Network-Message-Id: c59c2ed7-edc4-4156-c55c-08d80bf131df X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2020 21:16:22.6496 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FozwZKQmh1Li3QC9Appi7PboI9kP2vP4yl3B+8nzRAHMXhMuX0TA4brOb6eju5X8WBLbUp1TUyC7KMZdKNmsLwvMJofatjz9RvjWv2hgmCM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR02MB5564 X-Mailman-Approved-At: Tue, 09 Jun 2020 04:16:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Andrei LUTAS , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?Q?Mihai_Don=c8=9bu?= , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/8/20 11:44 PM, Tamas K Lengyel wrote: > On Mon, Jun 8, 2020 at 2:14 PM Razvan Cojocaru > wrote: >> >> On 6/8/20 10:54 PM, Tamas K Lengyel wrote: >>> On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru >>>> And last but not least, the proper sequence is: 1. unsubscribe from >>>> register write events, 2. process all events "still in the chamber" >>>> (keep checking the ring buffer for a while), 3. detach from the guest >>>> (disable the vm_event subsystem). Not ideal perhaps (in that it's not >>>> guaranteed that a VCPU won't resume after a longer period than our >>>> timeout), but if the sequence is followed there should be no guest hangs >>>> or crashes (at least none that we or our clients have observed so far). >>> >>> Incorrect. That's not enough. You also have to wait for all the vCPUs >>> to get scheduled before disabling vm_event or otherwise the emulation >>> is skipped entirely. Please read the patch message. If the user >>> decides to disable vm_event after getting a CR3 event delivered, the >>> CR3 never gets updated and results in the guest crashing in >>> unpredictable ways. Same happens with all the other registers. >> >> I did read the patch message. As I've previously stated ("it's not >> guaranteed that a VCPU won't resume after a longer period than our >> timeout"), it's not ideal, and I've made no claim that the problem does >> not exist or that it shouldn't be fixed - but really if you've got a >> VCPU that will wait more than a couple of seconds to get scheduled then >> you've got a bigger problem with the VM. > > Sorry, missed the part where you say you knew about this issue. We > didn't and it was absolutely not documented anywhere and certainly not > mentioned in the original patch that added the feature. It literally > took us years to figure out what the hell is going on. While as you it > can be a couple seconds before its safe to disable it can be a lot > longer depending on the system state, how many VMs are running and how > many vCPUs are active on the VM. There is absolutely necessary > use-cases where you want to keep the VM paused after a CR3 event is > received and exit vm_event afterwards. This bug totally blocks those > use-cases. Not to mention that it's a total mess having an interface > where the user has to guess when its safe to do something. If this was > pointed out when the patch was made I would have objected to that > being merged. No, we didn't know about the issue. It's apparently not my most eloquent evening. I was merely saying that I did understand what the issue was from your description, and offering an explanation on why we've never seen this in QA or production. Of course the issue would have been mentioned at least (but ideally not exist to begin with) had it been known. We do take several passes through the ring buffer (and as a side-effect reduce the probability of a race occuring to almost zero), but we do that to make sure we've cleaned up all EPT vm_events; the fact that it has helped with _this_ issue is a coincidence. IIRC Windows, at least, will be upset if a VCPU is stuck for too long. As for how the vm_event system behaves: 1. A security application that is unable to _prevent_ things being done to a system is not doing a very good job, since in that case you can only collect stats and not veto anything. I would argue that the default for such a monitoring application should be the current one (all events should be pre-action). 2. This is further supported by the fact that that's exactly how the EPT vm_events work: you get a "I want to write to this page" event _before_ the write occurs. If register writes behave differently, you have _two_ different models: one where you get an event post-action, and one where you get one pre-action. Hope that's clearer, Razvan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 04:17:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 04:17:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiVh4-0005xS-Em; Tue, 09 Jun 2020 04:16:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiO9s-0005QW-UY for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 20:14:13 +0000 X-Inumbo-ID: 9d7c8d9e-a9c4-11ea-b7bb-bc764e2007e4 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown [40.107.7.117]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9d7c8d9e-a9c4-11ea-b7bb-bc764e2007e4; Mon, 08 Jun 2020 20:14:11 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y+ZeGgFAtjTDTjWHPkGnWoYGcy9lFbCdSFtCB8bXFRbgdRCEhglhSxAOHY6MFBQCiAwgFvytCRUtIS/OA0Dh7iODG4NV2y52W3b4kA8DihX2OGN21LyMPK64UbAN+Z8ShhdRiBUkHrqqjPTvVEJAmkq61KIWgq3Uo0/oLo14g7bBDKIGDQeCR7S53V58RSaCU/c569XBl/6nCqXbon+1XccvXAHQwdG6lXE2fHvBhYlF2vuRhFfoR0fh5Hzq5Xi/ZB/IQLOqSljOolZhsR4xLM7VIRCRh6cPHot/KmZy7q7fhhR9LHh98bcyhiCJf9P+LlI2m1zfSFiTUvDwG88YFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=abgcg7OQU3BBnpx7ochP8a7Qo0siGKOUYttX8rYHZWA=; b=FXygQ/4cvJ8NI+hOPiaDc7geGapbgxxTBc1GdIxmM1TfkfmkEiKzaETM+rkMa6B2qZa9VE9bVxglQIBE89ay6V4Uo4rOgedbvz+sWP+nY6anpP3cpUDXDP0FiSjyUf/ptUbemVrmbip084I01w1xU22rqymrBwxvPb0RRtyt+SGaJdZ/WtIlQRM1egP7/MonpX6D5WmuSXDrHs8pTg3weE0IydBw9X3K8kLtx9sZXwJOYKxFbNcsf/AeHYGtogqDZei7XQNcz5F5HrEr9/A5L8ddD0NSWHF25uFXnRvVGODjJUC0OgU4+sn0nULTBciTl1hWvsLILbwDW+WEFbfrNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bitdefender.com; dmarc=pass action=none header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=abgcg7OQU3BBnpx7ochP8a7Qo0siGKOUYttX8rYHZWA=; b=rwZuTM7lF3MqKJ2xSgsRUNmsCzZ9uEt+ToX2FgCjMKVbJq8MmPcLzV2NVETbBUxY4zURmTamGO45xHaxhxHzt2GrJXG8ibQtFMdJigitSkppoocJL6nzJuoK/Pqy/YybsQlx14z5OMYhhU1VRU0lLcEwDeRCj6jxiVetBOQjwsc= Authentication-Results: bitdefender.com; dkim=none (message not signed) header.d=none;bitdefender.com; dmarc=none action=none header.from=bitdefender.com; Received: from DB8PR02MB5434.eurprd02.prod.outlook.com (2603:10a6:10:e5::15) by DB8PR02MB5690.eurprd02.prod.outlook.com (2603:10a6:10:e6::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.22; Mon, 8 Jun 2020 20:14:09 +0000 Received: from DB8PR02MB5434.eurprd02.prod.outlook.com ([fe80::3c22:239a:7f84:7572]) by DB8PR02MB5434.eurprd02.prod.outlook.com ([fe80::3c22:239a:7f84:7572%5]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 20:14:09 +0000 Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Tamas K Lengyel References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> From: Razvan Cojocaru Message-ID: Date: Mon, 8 Jun 2020 23:14:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 7bit X-ClientProxiedBy: VI1PR0802CA0008.eurprd08.prod.outlook.com (2603:10a6:800:aa::18) To DB8PR02MB5434.eurprd02.prod.outlook.com (2603:10a6:10:e5::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.228.119] (82.137.38.55) by VI1PR0802CA0008.eurprd08.prod.outlook.com (2603:10a6:800:aa::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 20:14:08 +0000 X-Originating-IP: [82.137.38.55] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cbc46b3d-d831-4e0e-0339-08d80be88081 X-MS-TrafficTypeDiagnostic: DB8PR02MB5690: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 042857DBB5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: J0rG/TK6qoC5lcTaiUdksZfrKwiFz0M3gypvz/HJXzvtPQB8Ehpixphpvxm8M50Bn31mFrC5nMMEcTcc+l6HRPnG8p6mcCpHakiqo8fjsPebzyZPfBvZUa8oXYgtpkl27tTWhLbTf++ZegZJIhYvnp2FSzLKTxMB1tM+0ispp8puTX3Qw8DONk+13n8T270p+LQBQbI11AI2Jo4UoQn7w/VxG8xCjNl0wA59xoAakDuASxL6UMg3WaP06UJ9H+o9i2kEnmbYdamoLroqOKr4JrOhIMonHQS8fZgrt4Dabderd70S3oz4PIeVanjmv9+VGotstbC2URtKbvP/LPW2JIvvgqJzi3Eud3PL0ENMusDjFfDl1ObN6oOfCpKuKp9y X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR02MB5434.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(346002)(366004)(396003)(39860400002)(136003)(52116002)(66476007)(54906003)(66556008)(53546011)(6666004)(2906002)(31686004)(31696002)(107886003)(86362001)(66946007)(2616005)(26005)(5660300002)(186003)(7416002)(4326008)(83380400001)(8936002)(6916009)(6486002)(956004)(8676002)(478600001)(16526019)(316002)(16576012)(36756003)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: oQePTx0aGnwdGkXx/MjkU+aZuUQYma8v/YU3N5/QUf89X6nHPnxsXyVNooc83jUCLFLjfjs4688jc/QUX8ygxro4T9E80+Mq4rSS3WeeNK1TkhgmZdsILpQ5nPK1XjSQHwLCcXFxBxHxMUhN3FsojQrTONzlVic0jIKKJtlNO9SFLO9qDXieXAKOHwU/L3kuCFSP1LwywaJKzIAcbcY+e9r8FN+M0YKo/JiHYIdh9V1J2Cc6HHHoYXycxkcfQkc93xJy83rqWxx2+fjhhXNID2J4HYWgdfi7XDTO/nK4EB+WO0V/Dmdbz4/qr7fuXHnMMw2NVy3dEe6cSnvS+mgh/Kmr006dSapRXm2lSvVxQmyxTYTYlSXS1K1blHFvMx9llLNEBkbBf7qHs9ACZwOIA0FuO6B0PWd6dZwSMLUaJk0Gj3Ne0Xwu+69OU94rkYsWsu6cLBSCbREcN0mQ43hgrtK8V2JnoPjZiK9d8GXdeVk= X-OriginatorOrg: bitdefender.com X-MS-Exchange-CrossTenant-Network-Message-Id: cbc46b3d-d831-4e0e-0339-08d80be88081 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2020 20:14:09.0551 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: It2zEvxQRdy/PNmviiFZu3ckuDzITwQiOHpOqS1wimUoSJVN6f/c8MrVGcN5VEgHua9PzRMJVBXIswH2btOZjPUswabkYwdSKG6JjWbDwU8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR02MB5690 X-Mailman-Approved-At: Tue, 09 Jun 2020 04:16:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Andrei LUTAS , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?Q?Mihai_Don=c8=9bu?= , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/8/20 10:54 PM, Tamas K Lengyel wrote: > On Mon, Jun 8, 2020 at 12:58 PM Razvan Cojocaru >> And last but not least, the proper sequence is: 1. unsubscribe from >> register write events, 2. process all events "still in the chamber" >> (keep checking the ring buffer for a while), 3. detach from the guest >> (disable the vm_event subsystem). Not ideal perhaps (in that it's not >> guaranteed that a VCPU won't resume after a longer period than our >> timeout), but if the sequence is followed there should be no guest hangs >> or crashes (at least none that we or our clients have observed so far). > > Incorrect. That's not enough. You also have to wait for all the vCPUs > to get scheduled before disabling vm_event or otherwise the emulation > is skipped entirely. Please read the patch message. If the user > decides to disable vm_event after getting a CR3 event delivered, the > CR3 never gets updated and results in the guest crashing in > unpredictable ways. Same happens with all the other registers. I did read the patch message. As I've previously stated ("it's not guaranteed that a VCPU won't resume after a longer period than our timeout"), it's not ideal, and I've made no claim that the problem does not exist or that it shouldn't be fixed - but really if you've got a VCPU that will wait more than a couple of seconds to get scheduled then you've got a bigger problem with the VM. >> So in short, I think there's a better fix for this by simply not >> allocating the vm_event memory on-demand anymore and never having to >> deal with lost pending emulations again. It should also decrease code >> complexity by a tiny bit. Then again, as stated at the beginning of this >> message, that's just a recommendation.is > > Since only you guys use this feature I'm going to wait for a fix. > Until then, the default behavior should be restored so this buggy > behavior doesn't affect anyone else. You can still turn it on, its > just not going to be on for vm_event by default. I don't particularly > care what fix is there since only you guys use it. If you don't mind > that there is this buggy behavior because you never disable vm_events > once you activate it then that's that. Indeed, our usual scenario is that vm_event is always on on the machine. It's only rarely being disabled while the guest is running, and when it is, it's always with waiting sufficiently long that we've not seen any unexplainable hung VMs. Fair enough, as long as the previous behaviour is optionally available I see no reason why this patch shouldn't make it in - though, of course, as also previously stated, I'm just trying to shed as much light as possible on this from what I remember, and what happens next is not my call. My colleagues should be able to chime in tomorrow. Cheers, Razvan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 04:17:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 04:17:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiVh4-0005xM-6c; Tue, 09 Jun 2020 04:16:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiMyZ-0006kb-Li for xen-devel@lists.xenproject.org; Mon, 08 Jun 2020 18:58:27 +0000 X-Inumbo-ID: 0862ede8-a9ba-11ea-bca7-bc764e2007e4 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (unknown [40.107.13.109]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0862ede8-a9ba-11ea-bca7-bc764e2007e4; Mon, 08 Jun 2020 18:58:26 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h8MXqTkqnikbHf0FX1cA9r7b0WqohBhhzPtX9E8K66TjybXkbUILfqgV4QtZdltJuy2Fs2JIQMNoB/wb96nCZtpmSr7u9I4+6g0i65TUhyFfh+wYWOpeR+kR79I77wiOabrAx1tkkDapE8eIMQhaPAZZ+5baYwfZT/RsJIaKwttGPcwZxmAiLjfJ81LAk8ZI/6KJJuQr/XRruKd8QH1SqO3s7Gfz3aVwWLAQtQ+PzsRRw3CQuQ8wduEsiodmdQAEobQazuD8lJP0gK4es4aAhb+KBMmXq7Wu4CjwzuhGUp6sYM2st3aHdibidbpoACUh2oG7Y59lK6A282XbSMj1KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qCUYPl0W15gXDPHhXLwNxUU5qzU7SCq5Q486mwyIsNE=; b=KtlVPXHC7mGGIVDA54MLXZl9C60e/HEmKyFNACER4+I1aMziTRrJfsMjZB7ldfwoh4IkIzpFAEppyEsldvdA1acCReQIgMNMlRUolWAgYkKGZawRLuvM2hy1pMugIMEtCsD/Avz6b+D1rG0GhH+nD0a6nEHCeNZeq3TbSr3HzWrfGE4GSRJl8ksCNy9xP8v8Wphr7JGrgIYcAM+35xy0T3m0HPOk9OHpnn0eivmtm6xKjTSZTi5kO+ZCJYteUjDtZLHiFQ9sacnuRnARsqBBsfwYel3j9aeIWfwHVGmQFcczD9QiTHSj8fZSS7s89Aao3eEuYoiCJ/sI39Pt91uklQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bitdefender.com; dmarc=pass action=none header.from=bitdefender.com; dkim=pass header.d=bitdefender.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitdefender.onmicrosoft.com; s=selector2-bitdefender-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qCUYPl0W15gXDPHhXLwNxUU5qzU7SCq5Q486mwyIsNE=; b=TZHdESQVvmM9djmipsAp9zN+dnOIbajCu6f+x4LZkZrwxCeR5xP9wB2xZDBXaj418bnoLKwdggCxnTTzg610moet9qCDMuvgno0A6wUu/Mg9fXQ9tc4rI9n/KBnQqtJ6x95jwmm2ljXKkJw9cmx9BiztBj0dEMZ3slM3hoNlIfc= Authentication-Results: bitdefender.com; dkim=none (message not signed) header.d=none;bitdefender.com; dmarc=none action=none header.from=bitdefender.com; Received: from DB8PR02MB5434.eurprd02.prod.outlook.com (2603:10a6:10:e5::15) by DB8PR02MB5817.eurprd02.prod.outlook.com (2603:10a6:10:111::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Mon, 8 Jun 2020 18:58:24 +0000 Received: from DB8PR02MB5434.eurprd02.prod.outlook.com ([fe80::3c22:239a:7f84:7572]) by DB8PR02MB5434.eurprd02.prod.outlook.com ([fe80::3c22:239a:7f84:7572%5]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 18:58:23 +0000 Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Jan Beulich , Alexandru Isaila , Petre Pircalabu References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> From: Razvan Cojocaru Message-ID: Date: Mon, 8 Jun 2020 21:58:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US-large Content-Transfer-Encoding: 8bit X-ClientProxiedBy: VI1PR0401CA0019.eurprd04.prod.outlook.com (2603:10a6:800:4a::29) To DB8PR02MB5434.eurprd02.prod.outlook.com (2603:10a6:10:e5::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.228.119] (82.137.38.55) by VI1PR0401CA0019.eurprd04.prod.outlook.com (2603:10a6:800:4a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Mon, 8 Jun 2020 18:58:22 +0000 X-Originating-IP: [82.137.38.55] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ef27e105-144d-4f72-a802-08d80bddeb0a X-MS-TrafficTypeDiagnostic: DB8PR02MB5817: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 042857DBB5 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M9wR/yx7wsl6LrMzV7EYCH7rmat3FNjP73vXZbRbu0mLB0p1haRfNisax5R4HELn+caGWB/t3QUPf3qp5NxAy7yqA+CSPT1DB+ytj8WWbADgpESC6F0r/yd7YP2T2P9sWHJ+SGkWB3j6fsp5ngU8f15EglnyONEKr9QOObKxoLgucUlBlRPZREOW6rFDl9n78q0mMiU5n+eW58QxIbmAEmm+ISyO7dBCO8IZ1NpNDLrs1iOwJ1Y3kHxZ5O75TkiLRerg2g4j6ZvhWcxvEsSZcO+eTpgRGAtdFqy2wTOQOAuEszPm3VxE/7nQMxa9uvndIQ0Y4cZRRss4xauLM/Hh8W+lnN3AhCd0QW6UOnxumfQi/aSEJTKoCKA02nmNndtK X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR02MB5434.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(39860400002)(376002)(346002)(366004)(396003)(4326008)(107886003)(31696002)(2906002)(66556008)(6486002)(66946007)(36756003)(66476007)(5660300002)(478600001)(83380400001)(2616005)(956004)(86362001)(316002)(6636002)(31686004)(6666004)(16576012)(26005)(54906003)(53546011)(7416002)(52116002)(16526019)(8936002)(110136005)(186003)(8676002)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: Y2AG7aRT1pE/jIFFTvQsU/CdQey2hKkvayFgzA0rnTAZ9oHkXOdF877nQ7mvMaz3xk0OdGhqxVYtrVryxUBxP0Md7Ntz4vWtCLR9dIzggkC5oABp+kRnyQBxrDReXJCsnf6hrTNtZiLP9KkXsc971/tBuVVbhIDHZ4Xf4NCfCRt5RB+C6WHOzLVzHqzg66VIzOWOB+JKCyXqJeGn8fnIicZFOs6840fhcCoFRZNh2/GCf+HEWI3lx02HFM7iXo8rRgd4BdQm4YMAZT4ypmcDBmYVuFtkZBcyqddQu5T17q1X4hP6uK3yAFyqVrojpF/nDpPPjwmf65kLVHxg5u1WGuYn41qwf3Yua7ctV3ySWMU05l7JlX85+nNz9TJOzSfqADUGIxgY84SiK3kdHm5zB6EUkQXnjtNxez+8DnjknX8ECkw27Kox5qteyOF3oGfnd9yvMVA6ZpgqUHLk6gNVeS3duKEkcKcq/8BRo9oDObA= X-OriginatorOrg: bitdefender.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef27e105-144d-4f72-a802-08d80bddeb0a X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2020 18:58:23.5395 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 487baf29-f1da-469a-9221-243f830c36f3 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EWUR4HCAseTpW7lXNu6W54ihWXOABOgGQpaKNkruGnYi7weTZ9kMxP/do4GX3we2cdw+WWgpvfk2d7Tyx08XV7d0h//spYgsIlh678C6gJE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR02MB5817 X-Mailman-Approved-At: Tue, 09 Jun 2020 04:16:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrei LUTAS , Tamas K Lengyel , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?Q?Mihai_Don=c8=9bu?= , Ian Jackson , George Dunlap , Stefano Stabellini , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/8/20 6:55 PM, Jan Beulich wrote: > On 03.06.2020 17:07, Roger Pau Monné wrote: >> On Wed, Jun 03, 2020 at 06:52:37AM -0600, Tamas K Lengyel wrote: >>> For the last couple years we have received numerous reports from users of >>> monitor vm_events of spurious guest crashes when using events. In particular, >>> it has observed that the problem occurs when vm_events are being disabled. The >>> nature of the guest crash varied widely and has only occured occasionally. This >>> made debugging the issue particularly hard. We had discussions about this issue >>> even here on the xen-devel mailinglist with no luck figuring it out. >>> >>> The bug has now been identified as a race-condition between register event >>> handling and disabling the monitor vm_event interface. The default behavior >>> regarding emulation of register write events is changed so that they get >>> postponed until the corresponding vm_event handler decides whether to allow such >>> write to take place. Unfortunately this can only be implemented by performing the >>> deny/allow step when the vCPU gets scheduled. >>> >>> Due to that postponed emulation of the event if the user decides to pause the >>> VM in the vm_event handler and then disable events, the entire emulation step >>> is skipped the next time the vCPU is resumed. Even if the user doesn't pause >>> during the vm_event handling but exits immediately and disables vm_event, the >>> situation becomes racey as disabling vm_event may succeed before the guest's >>> vCPUs get scheduled with the pending emulation task. This has been particularly >>> the case with VMS that have several vCPUs as after the VM is unpaused it may >>> actually take a long time before all vCPUs get scheduled. >>> >>> In this patch we are reverting the default behavior to always perform emulation >>> of register write events when the event occurs. To postpone them can be turned >>> on as an option. In that case the user of the interface still has to take care >>> of only disabling the interface when its safe as it remains buggy. >>> >>> Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event >>> reply'). >>> >>> Signed-off-by: Tamas K Lengyel >> >> Thanks! >> >> Reviewed-by: Roger Pau Monné >> >> I would like to get some input from Bitdefender really, and whether >> they are fine with this approach. Hello, Not really my call to make anymore, but I do have a few notes. First, IIRC the problem stems from the initial choice to have the vm_event data allocated on-demand when first subscribing to events. The proper solution (since this patch doesn't actually fix the problem), IMHO, would be for the vm_event data to _always_ exist, and instead of relying on the value of its pointer to check if there are event subscribers, we could just check the emulation flags individually and never miss a pending emulated something again. I did try to go that way in the beginning, but it has reasonably been objected that we should cut back on using hypervisor memory unnecessarily, hence we got at this point. Secondly, I see no reason why we couldn't adapt to the new default behaviour provided that the old behaviour continues to work _exactly_ as before. And last but not least, the proper sequence is: 1. unsubscribe from register write events, 2. process all events "still in the chamber" (keep checking the ring buffer for a while), 3. detach from the guest (disable the vm_event subsystem). Not ideal perhaps (in that it's not guaranteed that a VCPU won't resume after a longer period than our timeout), but if the sequence is followed there should be no guest hangs or crashes (at least none that we or our clients have observed so far). So in short, I think there's a better fix for this by simply not allocating the vm_event memory on-demand anymore and never having to deal with lost pending emulations again. It should also decrease code complexity by a tiny bit. Then again, as stated at the beginning of this message, that's just a recommendation. HTH, Razvan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 05:33:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 05:33:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiWsY-0004qF-Et; Tue, 09 Jun 2020 05:32:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiWsX-0004qA-Ay for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 05:32:53 +0000 X-Inumbo-ID: a4e88990-aa12-11ea-b7bb-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a4e88990-aa12-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 05:32:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=FL0M/QWy7eJQyyMOSmjXi3woft307nJ4/y9AHPp9mF4=; b=HP3EJZHs4fnGFlTQdX6LMz/GIa bSfR+JET4LFjuYGuWG9qBSm5opYzFLVYxCRL6EvujYiT9fQwNi5kKC+kle9gcTXgtAGwKtSiU7oTo y7oatcw9RVnoMIZk9Gsia2dCXJnkDuLUghD5k8mi1PYCujFitvknMSBBTJRA6AYfQQoTKtA9vn9Kk hUBdwJs9JLAScnD2/NsMsz54emEsj+DllsCn9H1MprXIHKnmphYIKih3JtNRnP7ZvOsvp5ttJAKUw fcxmZBTL3GYqVCckLgHUFdous+H9PxIHzrbo1stVXGLSmcBzfhlcdf1v2Mfosc3sfJfA+B8k0Ej++ +N7zU+nA==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiWsK-0003vo-EC; Tue, 09 Jun 2020 05:32:40 +0000 Date: Mon, 8 Jun 2020 22:32:40 -0700 From: Christoph Hellwig To: Stefano Stabellini Subject: Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations Message-ID: <20200609053240.GA3015@infradead.org> References: <20200603222247.11681-8-sstabellini@kernel.org> <20200608070850.GD15742@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, Christoph Hellwig , xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 08, 2020 at 04:06:57PM -0700, Stefano Stabellini wrote: > I understand what you are suggesting about having something like: > > xen_phys_to_dma(...) > { > phys_addr_t phys = xen_phys_to_bus(dev, paddr) > return phys_to_dma(phys); > } > > I thought about it myself. I'll do it. "something", yes. Except that I think the bus is a little confusing, isn't it? What is the Xen term for these addresses? Also we probably don't need the extra local variable. > But I don't think I understood the comment about XEN_PFN_PHYS. There is a comment above xen_phys_to_bus that it avoids using XEN_PFN_PHYS because XEN_PFN_PHYS of the phys_addr_t vs dma_addr_t mismatch. But XEN_PFN_PHYS could just use a u64 instead of the phys_addr_t and then we could use it. Especially as XEN_PFN_PHYS isn't actually used anywhere except in swiotlb-xen.c. Or we could remove XEN_PFN_PHYS enirely, as it isn't all that useful to start with. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 05:38:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 05:38:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiWxc-00052k-2B; Tue, 09 Jun 2020 05:38:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiWxb-00051t-46 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 05:38:07 +0000 X-Inumbo-ID: 64cad542-aa13-11ea-b7bb-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 64cad542-aa13-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 05:38:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=TaoLQA/iHofCA82dwdTGmf/d+d6nTw1lk728rMya7LM=; b=TMxv+Qz+Z2VzON5gsdIxcbjqf1 NzglBzFgoUfCgS+BonQq8w8owGelI6UxV7CQd8KKHRH2vrqB4gWNC4xAnUQMZ6Xk0emCuqFDDUZN8 43aesbmuvY5m8XGuGM7eCOdKinI4Oauwq/iRDNua4u1OHm6ytKPBm9xgFYjRKwtgsn52ZTiS4Urt6 qao/+nZoFeC5nk3/TMSQtxcz+4ABzV7wGbpujPWX0CdLINwfPpL3cI7Hjy0butd/0qS2vw4jIWxOq ZQwRIK6GUfhXpHZJOa3gGG/KKm0myQsIimI9mC9XHlENO5KP2QnP88nACyy5We+sRVVCRp9UFJ/zw QWANqufQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiWxW-0006qv-Bf; Tue, 09 Jun 2020 05:38:02 +0000 Date: Mon, 8 Jun 2020 22:38:02 -0700 From: Christoph Hellwig To: Stefano Stabellini Subject: Re: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_* Message-ID: <20200609053802.GB3015@infradead.org> References: <20200603222247.11681-10-sstabellini@kernel.org> <20200608071221.GF15742@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, Christoph Hellwig , xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 08, 2020 at 05:38:28PM -0700, Stefano Stabellini wrote: > Yeah, the pfn_valid check is a bit weird by definition because we are > using it to understand whether the address belong to us or to another > VM. To do the pfn_valid check we need to translate the dma address into > something the CPU understands, hence, the dma_to_phys call. > > Why can't we use the already-provided paddr? Because paddr has been > translated twice: > 1) from dma to maybe-foreign phys address (could be ours, or another VM) > 2) from maybe-foreign address to local (using our local mapping of the foreign page) > > In fact, it would be clearer if we had all three addresses as parameters > of xen_dma_sync_for_cpu: the dma address, the maybe-foreign physical > address (we tend to call it xenbus address, baddr), the local physical > address. Something like: I think instead we should move the arch_sync_dma_for_{device,cpu} calls from xen_dma_sync_for_{device,cpu} into the callers, as they are provided by the generic dma-noncoherent.h and optimized out for coherent architectures like x86. Then the swiotlb-xen.c code only need to call dma_cache_maint as the interface (which would have to grow a better name), which should then only need a single kind of address. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 05:39:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 05:39:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiWzO-000597-E5; Tue, 09 Jun 2020 05:39:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiWzN-000591-Bx for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 05:39:57 +0000 X-Inumbo-ID: a4471d52-aa13-11ea-bca7-bc764e2007e4 Received: from bombadil.infradead.org (unknown [2607:7c80:54:e::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a4471d52-aa13-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 05:39:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=9d5I29beiuD8NWd2IsPtQEkt8LGPlWEkqusG+bWe9Kc=; b=g1VsEAhWGLq6aDTVOGdfeDkonX y1gSr98rgZ2hcxCxV2zauJeM6hdWqvsFQnaSSQijOhtGEoNVA1aa07WMA42IHEOMq/RDPmo8hSeGi pSUOrrie20eynxqznnGZXRmEu1/qMjG58X0vq16YJiVur+7QfzhxYdh5LepnWkJE+y5Q2YhkQtlnN f+kBccJFktcR9xtsq7y6zdcC/88HnUpcCFZZumhRWXz6fTNUYIiGw1gf1PjM+9l6RRrNGSXBRyODQ Sq35sayJTmQD1/WhSvbwCL5ruGavLLTd3hYDtD9ueSN+BLG5UPao6Wl5u0Sf3OSSe+KU5/xRDXFQi YiB520Nw==; Received: from hch by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jiWzF-0006xo-UR; Tue, 09 Jun 2020 05:39:49 +0000 Date: Mon, 8 Jun 2020 22:39:49 -0700 From: Christoph Hellwig To: Stefano Stabellini Subject: Re: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_* Message-ID: <20200609053949.GA26473@infradead.org> References: <20200603222247.11681-10-sstabellini@kernel.org> <20200608071221.GF15742@infradead.org> <20200609053802.GB3015@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200609053802.GB3015@infradead.org> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, tamas@tklengyel.com, konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, Christoph Hellwig , xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 08, 2020 at 10:38:02PM -0700, Christoph Hellwig wrote: > On Mon, Jun 08, 2020 at 05:38:28PM -0700, Stefano Stabellini wrote: > > Yeah, the pfn_valid check is a bit weird by definition because we are > > using it to understand whether the address belong to us or to another > > VM. To do the pfn_valid check we need to translate the dma address into > > something the CPU understands, hence, the dma_to_phys call. > > > > Why can't we use the already-provided paddr? Because paddr has been > > translated twice: > > 1) from dma to maybe-foreign phys address (could be ours, or another VM) > > 2) from maybe-foreign address to local (using our local mapping of the foreign page) > > > > In fact, it would be clearer if we had all three addresses as parameters > > of xen_dma_sync_for_cpu: the dma address, the maybe-foreign physical > > address (we tend to call it xenbus address, baddr), the local physical > > address. Something like: > > I think instead we should move the arch_sync_dma_for_{device,cpu} > calls from xen_dma_sync_for_{device,cpu} into the callers, as they > are provided by the generic dma-noncoherent.h and optimized out for > coherent architectures like x86. Then the swiotlb-xen.c code only > need to call dma_cache_maint as the interface (which would have to > grow a better name), which should then only need a single kind of > address. ... actually I'd keep the xen_dma_sync_for_{device,cpu} names for the low-level interface, just move the arch_sync_dma_for_{device,cpu} calls up. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 06:28:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 06:28:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiXk5-0000yM-EJ; Tue, 09 Jun 2020 06:28:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiXk4-0000yF-8b for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 06:28:12 +0000 X-Inumbo-ID: 639900f2-aa1a-11ea-b2e3-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 639900f2-aa1a-11ea-b2e3-12813bfff9fa; Tue, 09 Jun 2020 06:28:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id BFC82AC7D; Tue, 9 Jun 2020 06:28:12 +0000 (UTC) Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Razvan Cojocaru References: <20200603125237.100041-1-tamas@tklengyel.com> <20200603150721.GF1195@Air-de-Roger> From: Jan Beulich Message-ID: <41623a3b-b959-25ab-9369-e1615f0e779a@suse.com> Date: Tue, 9 Jun 2020 08:28:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Andrei LUTAS , Tamas K Lengyel , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?Q?Mihai_Don=c8=9bu?= , Ian Jackson , George Dunlap , Stefano Stabellini , Alexandru Isaila , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 20:58, Razvan Cojocaru wrote: > On 6/8/20 6:55 PM, Jan Beulich wrote: >> On 03.06.2020 17:07, Roger Pau Monné wrote: >>> On Wed, Jun 03, 2020 at 06:52:37AM -0600, Tamas K Lengyel wrote: >>>> For the last couple years we have received numerous reports from users of >>>> monitor vm_events of spurious guest crashes when using events. In particular, >>>> it has observed that the problem occurs when vm_events are being disabled. The >>>> nature of the guest crash varied widely and has only occured occasionally. This >>>> made debugging the issue particularly hard. We had discussions about this issue >>>> even here on the xen-devel mailinglist with no luck figuring it out. >>>> >>>> The bug has now been identified as a race-condition between register event >>>> handling and disabling the monitor vm_event interface. The default behavior >>>> regarding emulation of register write events is changed so that they get >>>> postponed until the corresponding vm_event handler decides whether to allow such >>>> write to take place. Unfortunately this can only be implemented by performing the >>>> deny/allow step when the vCPU gets scheduled. >>>> >>>> Due to that postponed emulation of the event if the user decides to pause the >>>> VM in the vm_event handler and then disable events, the entire emulation step >>>> is skipped the next time the vCPU is resumed. Even if the user doesn't pause >>>> during the vm_event handling but exits immediately and disables vm_event, the >>>> situation becomes racey as disabling vm_event may succeed before the guest's >>>> vCPUs get scheduled with the pending emulation task. This has been particularly >>>> the case with VMS that have several vCPUs as after the VM is unpaused it may >>>> actually take a long time before all vCPUs get scheduled. >>>> >>>> In this patch we are reverting the default behavior to always perform emulation >>>> of register write events when the event occurs. To postpone them can be turned >>>> on as an option. In that case the user of the interface still has to take care >>>> of only disabling the interface when its safe as it remains buggy. >>>> >>>> Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event >>>> reply'). >>>> >>>> Signed-off-by: Tamas K Lengyel >>> >>> Thanks! >>> >>> Reviewed-by: Roger Pau Monné >>> >>> I would like to get some input from Bitdefender really, and whether >>> they are fine with this approach. > > Hello, > > Not really my call to make anymore, but I do have a few notes. Even more so thanks for replying; I did Cc you merely because of history and because I thought with Alexandru and Petre not replying you might either know someone else who should, or nudge them. > Secondly, I see no reason why we couldn't adapt to the new default > behaviour provided that the old behaviour continues to work _exactly_ as > before. That's my understanding (and nothing to the contrary looks to have surfaced from the other communication between you and Tamas), so with that I guess I'll go and throw in the patch. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 06:46:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 06:46:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiY1i-0002og-QG; Tue, 09 Jun 2020 06:46:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiY1h-0002ob-Rf for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 06:46:25 +0000 X-Inumbo-ID: ef38b51a-aa1c-11ea-b2e7-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ef38b51a-aa1c-11ea-b2e7-12813bfff9fa; Tue, 09 Jun 2020 06:46:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3L7gG57CCFkestKuVTF8pUqnit4YM+UXn5303WKnPB0=; b=WRTEO2MKDvf16mjbdM0yVH4Ld bTWqaA2HyN0UU9dwnHXZhY90MyX2oaqxP8m4F7RMdETuGP0YBUUimMQUDSB8auu6VfZamBqf0wxBs RskJzEaR7+HNKQz3t/1H4xNb4pFCppdckhqThdRhGZaImUUyQ2azVPa9jHQdUBYLj6bCE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiY1e-00075F-Ou; Tue, 09 Jun 2020 06:46:22 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiY1e-0005X4-Fw; Tue, 09 Jun 2020 06:46:22 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiY1e-00017y-Eo; Tue, 09 Jun 2020 06:46:22 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150928: regressions - FAIL X-Osstest-Failures: xen-unstable:build-amd64-prev:xen-build:fail:regression xen-unstable:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-unstable:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: xen=75131ad75bb3c91717b5dfda6881e61c52bfd22e X-Osstest-Versions-That: xen=51ca66c37371b10b378513af126646de22eddb17 From: osstest service owner Date: Tue, 09 Jun 2020 06:46:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150928 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150928/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150918 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150900 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150900 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150918 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150918 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150918 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150918 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150918 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150918 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150918 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150918 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150918 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: xen 75131ad75bb3c91717b5dfda6881e61c52bfd22e baseline version: xen 51ca66c37371b10b378513af126646de22eddb17 Last test of basis 150918 2020-06-08 01:51:14 Z 1 days Testing same since 150928 2020-06-08 16:37:10 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Jan Beulich Julien Grall jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 75131ad75bb3c91717b5dfda6881e61c52bfd22e Author: Jan Beulich Date: Mon Jun 8 10:25:40 2020 +0200 build: fix dependency tracking for preprocessed files While the issue is more general, I noticed that asm-macros.i not getting re-generated as needed. This was due to its .*.d file mentioning asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds dependency tracking files. While there, further avoid open-coding $(CPP) and drop the bogus (Arm) / stale (x86) -Ui386. Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper Acked-by: Julien Grall Release-acked-by: Paul Durrant (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 09 07:15:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 07:15:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiYU4-0005cI-K7; Tue, 09 Jun 2020 07:15:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiYU2-0005cD-Pc for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 07:15:42 +0000 X-Inumbo-ID: 06aab8ac-aa21-11ea-b7bb-bc764e2007e4 Received: from mail-ej1-x630.google.com (unknown [2a00:1450:4864:20::630]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 06aab8ac-aa21-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 07:15:41 +0000 (UTC) Received: by mail-ej1-x630.google.com with SMTP id l12so17354323ejn.10; Tue, 09 Jun 2020 00:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=dR6VSL8FsoZcxWeIb/mhcOUcIF57a7JLajWczF+lmWw=; b=KMvNC5ljqgyLcJ02sqtJZ7QOYqZ2n8sq4ZgeeRqoPyhuQjlwgsVePgfB9/uipY43T+ AXVDYcNzo5b97qrLh3SqWfRbJ7IHB14QAwe0CzJd6YI91anx2wRFuYHdZ7Jsp/lX88tv rdlLLLXNMWAgeCevmCZnX3ATfIYiNnHv+NYAg2C2aEaCKGmurSWlnxXIMQxInoIH3FpS yvAmG+8JFvk6fL0eF6agVtbmzHCbw7JpcGufXSqH8SJHzGdW2ZhP24pO4fidFUyVr7ei wmy9j1EQK9be4aott3bTzPzVkFriV/g7gx8ybVON4/HoZqSCSa8OQtV1zD24mySq084O +a3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=dR6VSL8FsoZcxWeIb/mhcOUcIF57a7JLajWczF+lmWw=; b=b+zODnwSxJLwrv4FokBBeplhszAohKT0ai3RWfc+NUqQeb2WJfTzuePJIb7UTa0uZP pOX2nrt752f4IOVZeBxRswRcdQ8DYPrkkWdo+G+1/D2v1B5Oh7VI7ByFjGx9w4/AcIu+ K/e4ZXrPFaHCfqb/dgfzc5jUp/jwlRIS34sNsmIu59pBRdYMfFMB4VknwqX9Ytw+C/jz vWy5DfXb1j7Dii45A/7HuUIn33SBCQrXJxVwbDvWGo2oTAy29lZVxB9ZQ6YwmeHDq2J/ TMNLeRwMtIECiyXgMnqn+5doJaJFUvA5xW1k73gflHAhsqbJTK3h6Q34FN3cWdqsVHDj FtKQ== X-Gm-Message-State: AOAM533ilDIUAWn88ikdJJgHycIhw3AflWmZGkuXc+FwtFi8O/mAbaTt b2xzUtTBMn1eQ/0VKTTn1FE= X-Google-Smtp-Source: ABdhPJyglyZxvkIgWGYuKDQy1P8CAG+ARnFH4enif1uGe/3Ry7+IqfI0dQW4Pl1cFB2H9MOn6Zr97Q== X-Received: by 2002:a17:906:af4d:: with SMTP id ly13mr23127932ejb.250.1591686940667; Tue, 09 Jun 2020 00:15:40 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id q14sm15043555edj.47.2020.06.09.00.15.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 00:15:40 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Tamas K Lengyel'" , "'Xen-devel'" References: <20200608163934.313-1-paul@xen.org> In-Reply-To: Subject: RE: Xen 4.14 RC1 Date: Tue, 9 Jun 2020 08:15:38 +0100 Message-ID: <004d01d63e2d$c7de8db0$579ba910$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHItTXpd8sx0l1jqMKHNeE0LXFGcwMGQZxRqNK9tZA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-announce@lists.xenproject.org, xen-users@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Tamas K Lengyel > Sent: 08 June 2020 21:03 > To: Xen-devel ; Paul Durrant > Cc: xen-users@lists.xenproject.org; xen-announce@lists.xenproject.org > Subject: Re: Xen 4.14 RC1 > > On Mon, Jun 8, 2020 at 10:41 AM Paul Durrant wrote: > > > > Hi all, > > > > Xen 4.14 RC1 is tagged. You can check that out from xen.git: > > > > git://xenbits.xen.org/xen.git 4.14.0-rc1 > > > > For your convenience there is also a tarball at: > > https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz > > > > And the signature is at: > > https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz.sig > > > > Please send bug reports and test reports to xen-devel@lists.xenproject.org. > > When sending bug reports, please CC relevant maintainers and me (paul@xen.org). > > > > As a reminder, there will be a Xen Test Day. Please see the test day schedule at > > https://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at > > https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions. > > Hi Paul, > I'm sad to see this RC1 still missing patch: > > https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00179.html Hi Tamas, I don't see an ack for that one as yet. I'm happy to check and release-ack once the final patch is agreed. > > The following even have the release-ack and yet are also missing: > > https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00025.html > https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00028.html > These are indeed acked and release-acked and I trust they will make the next RC. Paul > Without these patches I won't be testing or upgrading to 4.14 at all. > From xen-devel-bounces@lists.xenproject.org Tue Jun 09 08:12:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 08:12:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiZMe-0002jZ-Rf; Tue, 09 Jun 2020 08:12:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiZMe-0002jJ-ES for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 08:12:08 +0000 X-Inumbo-ID: e561be0e-aa28-11ea-8496-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e561be0e-aa28-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 08:12:01 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 9o2m9yRlwNErWhobeR4vIO5XV2GkjnT1VHr/Gh0BSZdp8EAKXa9geF5i5Iz+mEMCDbLMd1pwyr eQOBc44qAZ9OviaCLVC5DI0vdu4aChs6dVt9/N1B1OgbcYpU7zhD2JMtVehhe7V/J7AsRQ9jod bhzRnFhhQMxk+TmVGSYxpQqLRG1CL3eR9doASGH62fj6TGN1eeq2GPW3FsrZz4mCGBLRNsslI1 mhoM8O7t3zQjx9juSDtwq6YsnAB/yvsgTZSLC6Ory2FuKYEXsdeOAcH7zQIYfVluCMoM/lFxWi WQA= X-SBRS: 2.7 X-MesageID: 19899490 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,491,1583211600"; d="scan'208";a="19899490" Date: Tue, 9 Jun 2020 10:11:54 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: Xen 4.14 RC1 Message-ID: <20200609081039.GA1635@Air-de-Roger> References: <20200608163934.313-1-paul@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-users@lists.xenproject.org, Xen-devel , xen-announce@lists.xenproject.org, Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 08, 2020 at 02:02:31PM -0600, Tamas K Lengyel wrote: > On Mon, Jun 8, 2020 at 10:41 AM Paul Durrant wrote: > > > > Hi all, > > > > Xen 4.14 RC1 is tagged. You can check that out from xen.git: > > > > git://xenbits.xen.org/xen.git 4.14.0-rc1 > > > > For your convenience there is also a tarball at: > > https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz > > > > And the signature is at: > > https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz.sig > > > > Please send bug reports and test reports to xen-devel@lists.xenproject.org. > > When sending bug reports, please CC relevant maintainers and me (paul@xen.org). > > > > As a reminder, there will be a Xen Test Day. Please see the test day schedule at > > https://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at > > https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions. > > Hi Paul, > I'm sad to see this RC1 still missing patch: > > https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00179.html > > The following even have the release-ack and yet are also missing: > > https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00025.html Ideally this one requires an Ack from the VMX maintainers, which hasn't happened AFAICT. Might be worth trying to ping them on the patch by putting them on the To field. Alternatively we can consider pushing it without such Ack if the x86 maintainers agree. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 08:56:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 08:56:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jia33-0006Ki-8b; Tue, 09 Jun 2020 08:55:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jia32-0006Kd-An for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 08:55:56 +0000 X-Inumbo-ID: 074637d8-aa2f-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x32b.google.com (unknown [2a00:1450:4864:20::32b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 074637d8-aa2f-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 08:55:55 +0000 (UTC) Received: by mail-wm1-x32b.google.com with SMTP id f185so2273414wmf.3 for ; Tue, 09 Jun 2020 01:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=whQbxEjTBAiunFi9+StDN2xzyiDZ/wqXhFY3gV9qfy0=; b=pqlX56SptYsmlclWCiMVUBmlDIV3DqmvaDXZc+3x7VqP4iU55FtrP1uc4pvtYiWRam 8RPdbMM/PzgTEySFeyrsNOz7EWzrymYQOXjZAsURjXJSDQqJB9RQ0dOv0X+Eoensu4CO vg4GpjtMBO1dW1U2fDSPiz6NwLq4zArRbezCTZVVfR9FI+MFex92Uat6DEgHQtYpSqSr myqF5VHNKvJRm33EKYgmEvz9HFsstHTDHziHZFKcipMgC+jlfdZ5iXn3PjWOzCbioG62 tGSMXXawjG4L3nCf1h8bBc44oaNQVooDwyrOxf3Z4pJKu1eXWZ6pZEdh/ZzqOK6O+4BN G+6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=whQbxEjTBAiunFi9+StDN2xzyiDZ/wqXhFY3gV9qfy0=; b=Bk9wfFNb6oS7uiJBUU+gnXe9Mrv3JrPh7+8CnuubLI9mZynKz+djiIp5FLLh3LzN6n 1AUqO26gpx8hRC7tmUo6oPzd3xVJH9K0vJ9IZ45BRArfNNOTv0n5kCIJaVKIk8qCFJJx W9jf1wZfJ5cFHjFb9U6g8DCsiHLXwm0v5hrgU2Er5agEJvX3QWY2mdeuZbMEzP497qeG icGXun69rpb4Nb1P7THCgAMdv4mi/IhUX/V9j+eExUpvLnxmBvDjsk48UZ1jeOS58Ksr sowCEoVq+1OeMcokiG/qYZTVYPagTkqckWk768nPYlQzb/uJgaajamnyU3GTBEYQYWwU KeAA== X-Gm-Message-State: AOAM532tYI9W077GbhxNGJAuNzMUe+G8uwF+J7sp/p4TzYkX1fnlORMx QHXuk18ehepwyCMIuHg78t/TOvKBKLE= X-Google-Smtp-Source: ABdhPJzC0pYW4v46GAmTbkZ880Yqo1H8iKDriXCPKuF9rFuNPN5/FizT67mIkknjATxuHexhPyHIlg== X-Received: by 2002:a1c:dd44:: with SMTP id u65mr3147600wmg.180.1591692954485; Tue, 09 Jun 2020 01:55:54 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id h29sm2661115wrc.78.2020.06.09.01.55.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 01:55:53 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Olaf Hering'" , References: <20200608203849.18341-1-olaf@aepfle.de> In-Reply-To: <20200608203849.18341-1-olaf@aepfle.de> Subject: RE: [PATCH v1] kdd: remove zero-length arrays Date: Tue, 9 Jun 2020 09:55:52 +0100 Message-ID: <005001d63e3b$c85059f0$58f10dd0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIqIZk/Qusa7Qsu5bkjM27jAUAPHqgoM2NA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Tim Deegan' , 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of Olaf Hering > Sent: 08 June 2020 21:39 > To: xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Olaf Hering ; Tim Deegan ; > Wei Liu > Subject: [PATCH v1] kdd: remove zero-length arrays > > Struct 'kdd_hdr' already has a member named 'payload[]' to easily > refer to the data after the header. Remove the payload member from > 'kdd_pkt' and always use 'kdd_hdr' to fix the following compile error: Is it not sufficient to just change the declaration of payload in kdd_pkt from [0] to []? In fact I can't see any use of the payload field in kdd_hdr so it looks like that is the one that ought to be dropped. Paul > > kdd.c: In function 'kdd_tx': > kdd.c:746:30: error: array subscript 65534 is outside the bounds of an interior zero-length array > 'uint8_t[0]' {aka 'unsigned char[]'} [-Werror=zero-length-bounds] > 746 | sum += s->txp.payload[i]; > | ~~~~~~~~~~~~~~^~~ > In file included from kdd.c:53: > kdd.h:326:17: note: while referencing 'payload' > 326 | uint8_t payload[0]; > | ^~~~~~~ > cc1: all warnings being treated as errors > > Signed-off-by: Olaf Hering > --- > tools/debugger/kdd/kdd.c | 10 +++++----- > tools/debugger/kdd/kdd.h | 3 +-- > 2 files changed, 6 insertions(+), 7 deletions(-) > > diff --git a/tools/debugger/kdd/kdd.c b/tools/debugger/kdd/kdd.c > index 3ebda9b12c..4c6b39c22b 100644 > --- a/tools/debugger/kdd/kdd.c > +++ b/tools/debugger/kdd/kdd.c > @@ -249,7 +249,7 @@ static void kdd_log_pkt(kdd_state *s, char *name, kdd_pkt *p) > > /* Re-check the checksum */ > for (i = 0; i < p->h.len; i++) > - sum += p->payload[i]; > + sum += p->h.payload[i]; > > fprintf(f, "\n" > "%s: %s type 0x%4.4"PRIx16" len 0x%4.4"PRIx16 > @@ -267,8 +267,8 @@ static void kdd_log_pkt(kdd_state *s, char *name, kdd_pkt *p) > fprintf(f, "%8.8x ", i); > } else if (i % 8 == 0) > fprintf(f, " "); > - fprintf(f, " %2.2x", p->payload[i]); > - ascii[i % 16] = (isprint(((int)p->payload[i])) ? p->payload[i] : 0x2e); > + fprintf(f, " %2.2x", p->h.payload[i]); > + ascii[i % 16] = (isprint(((int)p->h.payload[i])) ? p->h.payload[i] : 0x2e); > if (i % 16 == 15) > fprintf(f, " |%s|\n", ascii); > } > @@ -743,7 +743,7 @@ static void kdd_tx(kdd_state *s) > > /* Fix up the checksum before we send */ > for (i = 0; i < s->txp.h.len; i++) > - sum += s->txp.payload[i]; > + sum += s->txp.h.payload[i]; > s->txp.h.sum = sum; > > kdd_log_pkt(s, "TX", &s->txp); > @@ -1127,7 +1127,7 @@ static void kdd_handle_pkt(kdd_state *s, kdd_pkt *p) > > /* Simple checksum: add all the bytes */ > for (i = 0; i < p->h.len; i++) > - sum += p->payload[i]; > + sum += p->h.payload[i]; > if (p->h.sum != sum) { > kdd_send_ack(s, p->h.id, KDD_ACK_BAD); > return; > diff --git a/tools/debugger/kdd/kdd.h b/tools/debugger/kdd/kdd.h > index bfb00ba5c5..57525d36c6 100644 > --- a/tools/debugger/kdd/kdd.h > +++ b/tools/debugger/kdd/kdd.h > @@ -68,7 +68,7 @@ typedef struct { > uint16_t len; /* Payload length, excl. header and trailing byte */ > uint32_t id; /* Echoed in responses */ > uint32_t sum; /* Unsigned sum of all payload bytes */ > - uint8_t payload[0]; > + uint8_t payload[]; > } PACKED kdd_hdr; > > #define KDD_PKT_CMD 0x0002 /* Debugger commands (and replies to them) */ > @@ -323,7 +323,6 @@ typedef struct { > kdd_msg msg; > kdd_reg reg; > kdd_stc stc; > - uint8_t payload[0]; > }; > } PACKED kdd_pkt; > From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:01:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:01:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jia83-0007BW-Sj; Tue, 09 Jun 2020 09:01:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jia81-0007BR-H2 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:01:06 +0000 X-Inumbo-ID: bd0deb56-aa2f-11ea-8496-bc764e2007e4 Received: from mo4-p00-ob.smtp.rzone.de (unknown [81.169.146.162]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bd0deb56-aa2f-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 09:01:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591693259; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=RuuZCKgjPIJgtyGzKuYaweVGVX6p/xg0mzFWFdKIUMg=; b=W8rzkQ+/vf+c1oFRILxT+QeoCPeuiSiptpjr4kpiI/XVLyOBWI7zTGsnEyYnUichu5 biPVHwIZ5VHk0SD3qTr9IthgsAvbQcZC35kQePo6iCwWq61tf+Xf9sH/sCCQKb1tdmaP W/iXsBN8agNS9zA4tspIR3tmxqUy9RIeQ3/WK+sHmLhUNLmpwLnUKumOtUx7iavk00kw suzZNcyvgusYTFbMCxGiOAWuJOixsNx6IOhY2gXt8RcBAlAGO5w2WRyKzmk9Ft6QhJU1 akoMyucGoXAeneKQpCkgHuMAf0dn+pvC4ocNQ6eY8EK7X5VjXCEboYq38euH9g0pKgVs Vd1Q== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w5990uJTp (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 9 Jun 2020 11:00:56 +0200 (CEST) Date: Tue, 9 Jun 2020 11:00:16 +0200 From: Olaf Hering To: Paul Durrant Subject: Re: [PATCH v1] kdd: remove zero-length arrays Message-ID: <20200609110016.16a52277.olaf@aepfle.de> In-Reply-To: <005001d63e3b$c85059f0$58f10dd0$@xen.org> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/xLgo8N7WlYzeWYneK6Qtz7v"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Tim Deegan' , 'Ian Jackson' , 'Wei Liu' , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/xLgo8N7WlYzeWYneK6Qtz7v Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 9 Jun 2020 09:55:52 +0100 schrieb Paul Durrant : > Is it not sufficient to just change the declaration of payload in kdd_pkt= from [0] to []? AFAIR this lead to compile errors. Olaf --Sig_/xLgo8N7WlYzeWYneK6Qtz7v Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7fT6AACgkQ86SN7mm1 DoAwCg//fJdmIIqoOS9TdBWweShgRB9K9KXMh//e1H1ZumbV5jP+IkwtmSrrDsTj Q86fqlIgR8HkVlDPwxOjxf/mX7v6NipDsbHRyclaZ1eePhFzrLV8lcmTQhBSZRVj IX0qxtMFHLVHX6xGcI3thISuv2T3viiBchoH4owXxpqD9dIrJ5iXWS1de45Ewgs2 xRGqsnPfCbtLn4XxsjNJ+5RHr3zpdkJEqQ1NXm9m6c4PQuRiRfEoBjHskbDhT8Cw iXHge+aC9IRL/1oMJudyB3g6OpIFad8Ar1h1k1tR/YRAUznThDg+bIE3eU8JgLDg /P8vEffB0EqkE+b1bhHgdlFdfbkud69P87C7sY4bgDkLoXWYRaVOgMUSTzvpb5RE Hkx0jb/4RUJpz+ZWYDZaUKeEKRCoTY51MUCTyHMWInWwX0r5QlYknYrhjJ0BAHma Wf729Mn8pQuFV5PwpFBftcyBBfCAWmebV/EEn/Zyq8wWKCwmmi1CYedHHor4GBdc 2ma5o0nouIv1pnVY33gN5RgFT2oQDprnFcEbKeo/2yBDJAQYcZK5Vi9yjUxNeT5u +kdKcq+jYBnKj0bBaY4m8pu60ZVsPeWfNzJap220oHG656L4USish+NU/Fa5K7Ni jLV3ew2vn8pRSv9Fscz5s2zj3bMQIDoJdbr8cuLvM9aFx61KBCA= =PBl6 -----END PGP SIGNATURE----- --Sig_/xLgo8N7WlYzeWYneK6Qtz7v-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:04:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:04:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiaBQ-0007Kg-Bw; Tue, 09 Jun 2020 09:04:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiaBO-0007Ka-FV for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:04:34 +0000 X-Inumbo-ID: 3bccb06c-aa30-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x433.google.com (unknown [2a00:1450:4864:20::433]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3bccb06c-aa30-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 09:04:34 +0000 (UTC) Received: by mail-wr1-x433.google.com with SMTP id l11so20389774wru.0 for ; Tue, 09 Jun 2020 02:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=EwXjFS4gOJyHR/4Nd3R4W/9hxeU0/owz7YOEd8D3ozM=; b=K8rqDeu7lfQCPMhCRyb1ygtmFaIdFMuxNksjcCLfK5RJmqDWkAzquHXb2vNl89ewC3 EgOTxfGgf1pWOAmf4WAywanWbM4KhRIuyKzMBECXxN4Pg/MEKTumV6ATOW0QHzj32D5C CSuRtb52VBW0oYbrbkk1PfRSIRQFrceiSfC4ump5vz5+bMjrQHSdebZZ+2q8K4vmUZJw YssSxwcxjpdSRkVgh1ViXWX2kLa66yyCSupZPW/N9jguoZxiv4/rMM6JouUiv3TwNjhH Y3+Ma+AjKuH1/MULutOUroEXRBKPB0sY8GqhfLxXbuIrPiq+lxYx2mpWh0UuAyF7zZ0t YRAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=EwXjFS4gOJyHR/4Nd3R4W/9hxeU0/owz7YOEd8D3ozM=; b=b91TTgucigjpm22M5+C+O4Uo1dWMlCmnl6JJFQw4Do8B1t0sTje8bC0UF48BoU/ebN r0PLsjs/LdPPGLSRrpiTvu3TF2c6WUmhJSdPUnD06/8uB9rPiaPPh99BahqVv9TJyg+P 3i1V4YaLKC2MgVsrhb2VjXrT0MJNS9CCvgd4gwHj48HEHph28kvYNeaRuDHI4ROtphk6 h8wpQtnUvenOX3Jp4iL0Njof+jhNpo1EQmaUWFVRW5M7PZicYxuFZmhBa1PZYDEx+5HF kWq9XXXrYmlK+915JSjWyQZ5J4F4pPntP4NCrOA7mi5yK4S7BqH1WBmIYyF1aIrlKs4s AlQw== X-Gm-Message-State: AOAM530k6Wht0UNP/8sbUOT+hwOAP3jDWr4NGNzhLLwpY3ZBlUrFCF4w XsT7P1mpDbu+DxQTc/ESbf8= X-Google-Smtp-Source: ABdhPJzZ1FtJ/MDNDi9PHASPF6lk9ujWFQQn6cTZWaMv/QA2N/7FPBSr+EUb+62nGuRkziMUXhdRDw== X-Received: by 2002:adf:fc4e:: with SMTP id e14mr3250098wrs.348.1591693472336; Tue, 09 Jun 2020 02:04:32 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id 30sm2607068wrd.47.2020.06.09.02.04.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 02:04:31 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Olaf Hering'" , "'Paul Durrant'" References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609110016.16a52277.olaf@aepfle.de> In-Reply-To: <20200609110016.16a52277.olaf@aepfle.de> Subject: RE: [PATCH v1] kdd: remove zero-length arrays Date: Tue, 9 Jun 2020 10:04:30 +0100 Message-ID: <005f01d63e3c$fcf84fe0$f6e8efa0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIqIZk/Qusa7Qsu5bkjM27jAUAPHgHVoA+LAZtbwz6oDK6X0A== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' , 'Wei Liu' , 'Tim Deegan' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Olaf Hering > Sent: 09 June 2020 10:00 > To: Paul Durrant > Cc: paul@xen.org; xen-devel@lists.xenproject.org; 'Ian Jackson' ; 'Tim > Deegan' ; 'Wei Liu' > Subject: Re: [PATCH v1] kdd: remove zero-length arrays > > Am Tue, 9 Jun 2020 09:55:52 +0100 > schrieb Paul Durrant : > > > Is it not sufficient to just change the declaration of payload in kdd_pkt from [0] to []? > > AFAIR this lead to compile errors. > OOI which compiler (might be worth mentioning in the commit comment too, for reference)? I'm not seeing a problem. Paul > Olaf From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:06:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:06:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiaD1-0007Pp-Nn; Tue, 09 Jun 2020 09:06:15 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiaD1-0007Pk-7Q for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:06:15 +0000 X-Inumbo-ID: 77cd66a7-aa30-11ea-b2f6-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 77cd66a7-aa30-11ea-b2f6-12813bfff9fa; Tue, 09 Jun 2020 09:06:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 42A2CAD4A; Tue, 9 Jun 2020 09:06:16 +0000 (UTC) Subject: Re: [PATCH v1] kdd: remove zero-length arrays To: paul@xen.org, 'Olaf Hering' , 'Paul Durrant' References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609110016.16a52277.olaf@aepfle.de> <005f01d63e3c$fcf84fe0$f6e8efa0$@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Tue, 9 Jun 2020 11:06:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <005f01d63e3c$fcf84fe0$f6e8efa0$@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' , 'Wei Liu' , 'Tim Deegan' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 09.06.20 11:04, Paul Durrant wrote: >> -----Original Message----- >> From: Olaf Hering >> Sent: 09 June 2020 10:00 >> To: Paul Durrant >> Cc: paul@xen.org; xen-devel@lists.xenproject.org; 'Ian Jackson' ; 'Tim >> Deegan' ; 'Wei Liu' >> Subject: Re: [PATCH v1] kdd: remove zero-length arrays >> >> Am Tue, 9 Jun 2020 09:55:52 +0100 >> schrieb Paul Durrant : >> >>> Is it not sufficient to just change the declaration of payload in kdd_pkt from [0] to []? >> >> AFAIR this lead to compile errors. >> > > OOI which compiler (might be worth mentioning in the commit comment too, for reference)? I'm not seeing a problem. We don't use array[] in public headers, but AFAIK using them internally is fine. Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:09:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:09:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiaFh-0007bS-6h; Tue, 09 Jun 2020 09:09:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiaFg-0007bN-FP for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:09:00 +0000 X-Inumbo-ID: dad5e14c-aa30-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x436.google.com (unknown [2a00:1450:4864:20::436]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dad5e14c-aa30-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 09:08:59 +0000 (UTC) Received: by mail-wr1-x436.google.com with SMTP id c3so20360682wru.12 for ; Tue, 09 Jun 2020 02:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=e87qbX8taTu/TmxWOZZTUTjhubAMWOgGXPqyXIjZre0=; b=Szl5DFLCV0wa7N1KmocMXcuVbyDZ96YoyMV4oGP4FbmyxZVP72SwbgIxv+pG2Tq9F8 TV+49/UIjbQtYpON2Qcns8xASS3Zwt8rVUzgoYfdl372j3tFusESBVfn5VqxI5Pdvw7I o4O1myzM23i+QCS3I0nqWxGnP2nCW7HSZ2nPIwKfyvKFDdjxHX+pWiegGJDrM3VvJps8 lbmQlOr5QH+v8iXFBKRX8KKKA6t3NoGL87fPeKbqf15e1IW7/j4yhcLgSyeUyRRpczC9 kQHKRTbC3WvteuZ8MQGAIaKTVFvB+9xY9nF5/VLlioLgkMZAyUXkAsbT8TTlJ1PBbiDm Z/hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=e87qbX8taTu/TmxWOZZTUTjhubAMWOgGXPqyXIjZre0=; b=aL0R7TwrnvpTF9x6TEKVRKlWACSemBVELBQgqCok7EmD5JvZpBiML8N93L/V+d16KH ahqT40n8BtFiXw8oXIGuEi91cghhpnztJnxvyRojRxXu1iE73wqu5msTU6D/T36HMz+W htukbRW6rPXGM7wBmlxKxO658gwYyaypiX07HhLdRjan8k/606eMOGx4/RlNWllJZtUv GMymaz3E1Doa5Vmv2RffzhOo2cUj06b13MHFiN4I/7MBLQgbaytRTr7r7jQz5I/XHMFY 4SNVKnyptRs9Zs+5W2ydgO58HvaeWx9orhhQZtvcQcMX0XTnyR28ZnKXsuND9UgWsPA0 w9mQ== X-Gm-Message-State: AOAM533I+ciOdqB/IS6hVZkldT4sUOCGAIBF7evUpS5wWK2BozIMOtE2 03+1T5PMb82fP+SB64EkKdBDQjM/+co= X-Google-Smtp-Source: ABdhPJzE1wIbGcSCkqzYyWl32XvYIdYYc4BXaKKH7g+kVPVNfc7YCwPhwBFFewvnfD4n0cLIm4977w== X-Received: by 2002:a05:6000:10cf:: with SMTP id b15mr3220723wrx.214.1591693739219; Tue, 09 Jun 2020 02:08:59 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id e15sm2351474wme.9.2020.06.09.02.08.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 02:08:58 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= , "'Olaf Hering'" , "'Paul Durrant'" References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609110016.16a52277.olaf@aepfle.de> <005f01d63e3c$fcf84fe0$f6e8efa0$@xen.org> In-Reply-To: Subject: RE: [PATCH v1] kdd: remove zero-length arrays Date: Tue, 9 Jun 2020 10:08:57 +0100 Message-ID: <006301d63e3d$9c141fa0$d43c5ee0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIqIZk/Qusa7Qsu5bkjM27jAUAPHgHVoA+LAZtbwz4ChcRm7gE/+bE7p+6BznA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' , 'Wei Liu' , 'Tim Deegan' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: J=C3=BCrgen Gro=C3=9F > Sent: 09 June 2020 10:06 > To: paul@xen.org; 'Olaf Hering' ; 'Paul Durrant' = > Cc: xen-devel@lists.xenproject.org; 'Ian Jackson' = ; 'Wei Liu' ; > 'Tim Deegan' > Subject: Re: [PATCH v1] kdd: remove zero-length arrays >=20 > On 09.06.20 11:04, Paul Durrant wrote: > >> -----Original Message----- > >> From: Olaf Hering > >> Sent: 09 June 2020 10:00 > >> To: Paul Durrant > >> Cc: paul@xen.org; xen-devel@lists.xenproject.org; 'Ian Jackson' = ; 'Tim > >> Deegan' ; 'Wei Liu' > >> Subject: Re: [PATCH v1] kdd: remove zero-length arrays > >> > >> Am Tue, 9 Jun 2020 09:55:52 +0100 > >> schrieb Paul Durrant : > >> > >>> Is it not sufficient to just change the declaration of payload in = kdd_pkt from [0] to []? > >> > >> AFAIR this lead to compile errors. > >> > > > > OOI which compiler (might be worth mentioning in the commit comment = too, for reference)? I'm not > seeing a problem. >=20 > We don't use array[] in public headers, but AFAIK using them = internally > is fine. >=20 Yeah, we have XEN_FLEX_ARRAY_DIM for public headers. Paul >=20 > Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:36:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:36:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiafk-0001gE-Ee; Tue, 09 Jun 2020 09:35:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiafj-0001fT-5c for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:35:55 +0000 X-Inumbo-ID: 99033a72-aa34-11ea-b2f8-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 99033a72-aa34-11ea-b2f8-12813bfff9fa; Tue, 09 Jun 2020 09:35:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 08C6AAD5D; Tue, 9 Jun 2020 09:35:49 +0000 (UTC) Subject: Re: Xen 4.14 RC1 To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Tamas K Lengyel References: <20200608163934.313-1-paul@xen.org> <20200609081039.GA1635@Air-de-Roger> From: Jan Beulich Message-ID: Date: Tue, 9 Jun 2020 11:35:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200609081039.GA1635@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Xen-devel , xen-announce@lists.xenproject.org, xen-users@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 09.06.2020 10:11, Roger Pau Monné wrote: > On Mon, Jun 08, 2020 at 02:02:31PM -0600, Tamas K Lengyel wrote: >> On Mon, Jun 8, 2020 at 10:41 AM Paul Durrant wrote: >>> >>> Hi all, >>> >>> Xen 4.14 RC1 is tagged. You can check that out from xen.git: >>> >>> git://xenbits.xen.org/xen.git 4.14.0-rc1 >>> >>> For your convenience there is also a tarball at: >>> https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz >>> >>> And the signature is at: >>> https://downloads.xenproject.org/release/xen/4.14.0-rc1/xen-4.14.0-rc1.tar.gz.sig >>> >>> Please send bug reports and test reports to xen-devel@lists.xenproject.org. >>> When sending bug reports, please CC relevant maintainers and me (paul@xen.org). >>> >>> As a reminder, there will be a Xen Test Day. Please see the test day schedule at >>> https://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at >>> https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions. >> >> Hi Paul, >> I'm sad to see this RC1 still missing patch: >> >> https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00179.html >> >> The following even have the release-ack and yet are also missing: >> >> https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00025.html > > Ideally this one requires an Ack from the VMX maintainers, which > hasn't happened AFAICT. Might be worth trying to ping them on the patch > by putting them on the To field. > > Alternatively we can consider pushing it without such Ack if the x86 > maintainers agree. I would likely do so once the time we usually see Kevin reply has expired, but we're not past that point yet. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:37:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:37:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiah3-0001p3-8i; Tue, 09 Jun 2020 09:37:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiah2-0001oq-DR for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:37:16 +0000 X-Inumbo-ID: cdaac33a-aa34-11ea-b2f8-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cdaac33a-aa34-11ea-b2f8-12813bfff9fa; Tue, 09 Jun 2020 09:37:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 16A74AE8C; Tue, 9 Jun 2020 09:37:18 +0000 (UTC) Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Tamas K Lengyel References: <20200603125237.100041-1-tamas@tklengyel.com> From: Jan Beulich Message-ID: <64ea771f-a7c1-cfc1-e135-632ec4c7fc93@suse.com> Date: Tue, 9 Jun 2020 11:37:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200603125237.100041-1-tamas@tklengyel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , Andrew Cooper , Ian Jackson , George Dunlap , Alexandru Isaila , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 03.06.2020 14:52, Tamas K Lengyel wrote: > For the last couple years we have received numerous reports from users of > monitor vm_events of spurious guest crashes when using events. In particular, > it has observed that the problem occurs when vm_events are being disabled. The > nature of the guest crash varied widely and has only occured occasionally. This > made debugging the issue particularly hard. We had discussions about this issue > even here on the xen-devel mailinglist with no luck figuring it out. > > The bug has now been identified as a race-condition between register event > handling and disabling the monitor vm_event interface. The default behavior > regarding emulation of register write events is changed so that they get > postponed until the corresponding vm_event handler decides whether to allow such > write to take place. Unfortunately this can only be implemented by performing the > deny/allow step when the vCPU gets scheduled. > > Due to that postponed emulation of the event if the user decides to pause the > VM in the vm_event handler and then disable events, the entire emulation step > is skipped the next time the vCPU is resumed. Even if the user doesn't pause > during the vm_event handling but exits immediately and disables vm_event, the > situation becomes racey as disabling vm_event may succeed before the guest's > vCPUs get scheduled with the pending emulation task. This has been particularly > the case with VMS that have several vCPUs as after the VM is unpaused it may > actually take a long time before all vCPUs get scheduled. > > In this patch we are reverting the default behavior to always perform emulation > of register write events when the event occurs. To postpone them can be turned > on as an option. In that case the user of the interface still has to take care > of only disabling the interface when its safe as it remains buggy. > > Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm_event > reply'). > > Signed-off-by: Tamas K Lengyel Applicable parts Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:37:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:37:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiahJ-0001s4-GR; Tue, 09 Jun 2020 09:37:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiahG-0001rY-U9 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:37:32 +0000 X-Inumbo-ID: d56c93b4-aa34-11ea-b2f8-12813bfff9fa Received: from mo4-p01-ob.smtp.rzone.de (unknown [81.169.146.165]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d56c93b4-aa34-11ea-b2f8-12813bfff9fa; Tue, 09 Jun 2020 09:37:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591695448; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=Zn/pXRjO5vbTfIwqoQSy1CtR0CnKp80YdW24gR5AxKA=; b=YP+4WqfmsrQ4KcNmpVz0r+HXxgWznN71cpOSP/MNdPAheBii6SkE7UyikPk6uVDdlY 9zDA6EsUtER6BdYKV/hnnUDQpVS0ezfvGR+lzmHxuYOLbSg2uY1KUY2iscrAnCzoqBqe x0c5ouRtSLSVRk4awcFpv8izuR1Y9P9d1cx430p7vJix0KGFxx8oCCuayNTX+IIjx2cD b3PX8D10HFFbgyvf0rCzqk24uuhdyqUg50iGMKKGne9PyJ9JzfgixKxek7xtVcThSxo3 SKf19HkWs44t3OUQaqnW7URifucmCUCW8sc23HKp1DRuHNP2gmrx7HlVzgprZuAnuexh YDCQ== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w599bOJmM (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 9 Jun 2020 11:37:24 +0200 (CEST) Date: Tue, 9 Jun 2020 11:37:08 +0200 From: Olaf Hering To: Paul Durrant Subject: Re: [PATCH v1] kdd: remove zero-length arrays Message-ID: <20200609113708.01d64a93.olaf@aepfle.de> In-Reply-To: <005f01d63e3c$fcf84fe0$f6e8efa0$@xen.org> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609110016.16a52277.olaf@aepfle.de> <005f01d63e3c$fcf84fe0$f6e8efa0$@xen.org> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/gjpsBezG2SDuPjegf_Kv978"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Tim Deegan' , 'Ian Jackson' , 'Wei Liu' , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/gjpsBezG2SDuPjegf_Kv978 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 9 Jun 2020 10:04:30 +0100 schrieb Paul Durrant : > OOI which compiler (might be worth mentioning in the commit comment too, = for reference)? I'm not seeing a problem. This is from gcc10. I think the build automation for Tumbleweed will show t= his error, unless the Tumbleweed image is older than a week. Olaf --Sig_/gjpsBezG2SDuPjegf_Kv978 Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7fWEQACgkQ86SN7mm1 DoCG8RAAggyNYva97bMCqqAbSoLxbLLq2ViptaFg5XjSvc8nI2I64/ifusGRJfM8 91Wz9qUZOg5tGObABRm4VDxtT1F83ReUFgDuIHCulQpI7ljhyXs7njRAiCZpci63 HcOfscyXrq0pd26Nm6gxqjFeKCCXDe/r+JA0gqHk4faI+gY08hP3nmpWyri2Uww0 RQQ8jjDgdV3ZVWQt1MMCmB9TlWn5iH9wh9EKykXvkb93GaawuvQ5rqMn20OC3Uu2 1dDbwt4Sh36PEDRYZ604Hu3k6qEOYYjNG257pIaISbd6Xy+apnP7z7VtAOZMpmmy iiMCvo074RDlu9mzWoyYvDbIeg1kBUbpKugDYx2gFLwzSd5yr+Kx437WbGeGNpX5 rEoOgKI+JltF56SAVH8nz8OGmyFeZTk4DiueH+ZtYXTladQWsq8lVx+G2OUnB57x jo0WwEFah/71WM9Pljl1ZFg2gfE3vVJelnt5HDObrFAj4g9lVDSANTpDbxOtKsSl Rzv3vYSBzKiBabZ+KNmmszi8xK/dOkgoJuctonJ15vOOE3UKaZTOcfZk0Cq9tIwl pX6lwU4bWeIMqu0s5dcsNTTaZYFpY/v0ZdLZRh+9uX7L5dH8MIXCXATAlWie5Gne oJ4ABPabvlb3CsaYiSbToMTrnxVwELyON3zrKIK0q2Uo8iAMo78= =I7e1 -----END PGP SIGNATURE----- --Sig_/gjpsBezG2SDuPjegf_Kv978-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:42:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:42:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiali-0002qq-3O; Tue, 09 Jun 2020 09:42:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jialg-0002qE-0l for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:42:04 +0000 X-Inumbo-ID: 75b8b816-aa35-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 75b8b816-aa35-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 09:41:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UGFSEdSgfT2zyU2i3uF5gBUgf8UYTgSxzqGi7ytrhBE=; b=PfCCZFyJitRrCI1Y6+7utyONt D5s3OvgSMSMaWUL0TmGxM186aLKOKOL4i898SKSW7HgyMq8LBAqEfQT6gdk2oiluvVRPmkFeME2sj GLXDXZZWfy7h238B/1NQazIVGucmBoJe4ConE8lK+FZcb7k1gdeJmeZaUCoKr36wefiBM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jialZ-0002o9-32; Tue, 09 Jun 2020 09:41:57 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jialY-0007WH-Og; Tue, 09 Jun 2020 09:41:56 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jialY-0002Bw-O0; Tue, 09 Jun 2020 09:41:56 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150930: tolerable FAIL - PUSHED X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: qemuu=49ee11555262a256afec592dfed7c5902d5eefd2 X-Osstest-Versions-That: qemuu=66234fee9c2d37bfbc523aa8d0ae5300a14cc10e From: osstest service owner Date: Tue, 09 Jun 2020 09:41:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150930 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150930/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150694 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150694 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150694 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150694 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150694 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150694 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass version targeted for testing: qemuu 49ee11555262a256afec592dfed7c5902d5eefd2 baseline version: qemuu 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e Last test of basis 150694 2020-06-04 11:44:20 Z 4 days Failing since 150831 2020-06-05 13:06:20 Z 3 days 9 attempts Testing same since 150930 2020-06-08 21:37:21 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Bulekov Andreas Schwab Christian Borntraeger Cornelia Huck Cédric Le Goater Dr. David Alan Gilbert Eden Mikitas Gerd Hoffmann Helge Deller Janosch Frank Jared Rossi Jonathan Marler Kevin Wolf Laurent Vivier Paolo Bonzini Paul Zimmerman Peter Maydell Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard Henderson Sergei Trofimovich Stefan Hajnoczi Stefano Garzarella Thomas Huth Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/qemu-xen.git 66234fee9c..49ee115552 49ee11555262a256afec592dfed7c5902d5eefd2 -> upstream-tested From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:44:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:44:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiao0-00030Y-Gc; Tue, 09 Jun 2020 09:44:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jianz-00030N-8K for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:44:27 +0000 X-Inumbo-ID: ce26b49e-aa35-11ea-b7bb-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ce26b49e-aa35-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 09:44:26 +0000 (UTC) Received: from nodbug.lucina.net (78-141-76-187.dynamic.orange.sk [78.141.76.187]) by smtp.lucina.net (Postfix) with ESMTPSA id 612CD122804; Tue, 9 Jun 2020 11:44:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1591695865; bh=6ZX7wnOiDM+mgpph4PTSgUowQ6Md6Yyyyb6vfm3/KaE=; h=Date:From:To:Subject:From; b=C0BeHPU9VVelKUtTN/95M9TAXB8lvMn7eL26Q9sKmjXigiQSnff7PY9PTyUJdYD+9 MEBL8YK+RbyOwA7nwDokKZk2k014DgAO/jiRjInu+4gxcM+R9xaqU+D3HwOXI5I+Gw XDRz64Fbc6cLTJTxRTdYNAHTIXq4uaL22hnnU9YYrmR5bEnqtMw1xCD43ONBq9HNa+ Lw3iPYl9ynHK0JDgHJ/fUWk4Tz2Y8PjS+kKl6kNg6W0fKzfdLWFfkiyO7a2xC5CeI0 lLtAaW+r5lPipTgnRiHy2DUz1d0D9A+ckTtTfSjzxWmsQxUTfYKioBcUyq/3kZ7gzi oThtxeePYKVqw== Received: by nodbug.lucina.net (Postfix, from userid 1000) id 4EB52265E722; Tue, 9 Jun 2020 11:44:25 +0200 (CEST) Date: Tue, 9 Jun 2020 11:44:25 +0200 From: Martin Lucina To: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org Subject: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table Message-ID: <20200609094425.GB9734@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, I've been making progress on bootstrapping a new, PVHv2 only, Xen platform stack for MirageOS [1]. The basics are now functional and I have started to re-implement the grant table code. After studying both the Mini-OS and Linux implementations some, I don't understand the difference between using XENMAPSPACE_grant_table vs. GNTTABOP_setup_table to set up the initial grant table mapping for the guest. Are these calls just newer and older ways of accomplishing the same thing? The Linux driver seems to use both in various conditions, whereas Mini-OS uses the former on ARM and the latter on x86. If these are functionally equivalent, then for my purposes I'd rather use XENMAPSPACE_setup_table, since IIUC this lets me map the grant table at an address of my choosing rather than GNTTABOP_setup_table which at least on x86_64 appears to be returning PFNs at the top of the address space. Any advice much appreciated, -mato [1] https://github.com/mirage/mirage/issues/1159 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 09:48:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 09:48:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jias5-0003Gs-8F; Tue, 09 Jun 2020 09:48:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jias3-0003Gm-I3 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 09:48:39 +0000 X-Inumbo-ID: 64c93976-aa36-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x42c.google.com (unknown [2a00:1450:4864:20::42c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 64c93976-aa36-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 09:48:38 +0000 (UTC) Received: by mail-wr1-x42c.google.com with SMTP id q11so20566612wrp.3 for ; Tue, 09 Jun 2020 02:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=qH71riF6UY44PzwH7v4sc6MNHeLQWvJcZsyR+nDZOO0=; b=a5x7gf+r6s+3csOk/6scB9zRxic1oThNw4BDRZ8xzYvs3JFFO75XfX5WTTe7j12H8e vogh5SetXTULNqVvIMvkmU7V6cp6U0nEfyh3OfwM/mOjaWkXwPujRhD5ZyzjAf5zKKmF GHN4iTjJ0WWSaXVrVhe8ENwoUTQQhiHMiAW1youGEgNYz6F92hnVtFrZ7ddiO2/iv8ln 40PeC9sJOEeqTFLf18DqGiypx9ExL87bNMPDKsV8IziAWhQU9O2kQEXwHY/F3vI5qDex wiNTV/iwJn6oPsPGPWAS0VZOEsrmLGIGEfIJkOKgOVGoowfk6D66P6IjqWvlhMaoOfUr YFPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=qH71riF6UY44PzwH7v4sc6MNHeLQWvJcZsyR+nDZOO0=; b=F7iJr06nnoDXsrHNkmCzsYLEvQovj5nbNFpGG2KGR9+6t3tV56oem4GoxJ/6B625Uc J1GPnUsaE+mziB0rNcCwjTMyFF+xCeWYVdzMveUCF5Ha5D2SzXVGQQ6zWsbU653rgaGB gB4geAnCYH9PQuW0HWCMWlijMNLKfexd8CJzlSx7f4Xtu7ePVVMhUxCDNzJyj7Pad031 v2G+QRw0o+DyXipKG+F3YlEyWjE3ClM9yfSDnNNYcDre/Y7OiyTseQD9VuDDSa1uspsC gyfmR8JpcPNlxkhz5bBgyx0NMcfAq2CzzuNXolE8jQJ+uF7tnPJ/vheerfJB7LW8BQ0p 4qsA== X-Gm-Message-State: AOAM530IAIOva3SFFYJMGhZXru0KW+/rK++YAoI2QsvOnpft+ahY8ttS 9LSqF5WLavpdsXSeG5FFOP0= X-Google-Smtp-Source: ABdhPJyXJwZeBfjygdsVH/to0pOIFKrHh9NSVRlx6z0f+M1rXGqd1/eyI66FcY+SZGtR1p7RxjBnEQ== X-Received: by 2002:adf:91c2:: with SMTP id 60mr3689399wri.41.1591696118013; Tue, 09 Jun 2020 02:48:38 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id 125sm2427590wmc.23.2020.06.09.02.48.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 02:48:37 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , "'Tamas K Lengyel'" References: <20200603125237.100041-1-tamas@tklengyel.com> <64ea771f-a7c1-cfc1-e135-632ec4c7fc93@suse.com> In-Reply-To: <64ea771f-a7c1-cfc1-e135-632ec4c7fc93@suse.com> Subject: RE: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events Date: Tue, 9 Jun 2020 10:48:35 +0100 Message-ID: <006f01d63e43$25e98440$71bc8cc0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHMIvrjc9D1klp/MRCvYm/ZI0jSTQG6VnbhqNZtXKA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Petre Pircalabu' , 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Alexandru Isaila' , xen-devel@lists.xenproject.org, =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 09 June 2020 10:37 > To: Tamas K Lengyel > Cc: xen-devel@lists.xenproject.org; Andrew Cooper = ; Wei Liu ; > Roger Pau Monn=C3=A9 ; George Dunlap = ; Ian Jackson > ; Julien Grall ; Stefano = Stabellini > ; Alexandru Isaila ; = Petre Pircalabu > ; Paul Durrant > Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior = when monitoring register write > events >=20 > On 03.06.2020 14:52, Tamas K Lengyel wrote: > > For the last couple years we have received numerous reports from = users of > > monitor vm_events of spurious guest crashes when using events. In = particular, > > it has observed that the problem occurs when vm_events are being = disabled. The > > nature of the guest crash varied widely and has only occured = occasionally. This > > made debugging the issue particularly hard. We had discussions about = this issue > > even here on the xen-devel mailinglist with no luck figuring it out. > > > > The bug has now been identified as a race-condition between register = event > > handling and disabling the monitor vm_event interface. The default = behavior > > regarding emulation of register write events is changed so that they = get > > postponed until the corresponding vm_event handler decides whether = to allow such > > write to take place. Unfortunately this can only be implemented by = performing the > > deny/allow step when the vCPU gets scheduled. > > > > Due to that postponed emulation of the event if the user decides to = pause the > > VM in the vm_event handler and then disable events, the entire = emulation step > > is skipped the next time the vCPU is resumed. Even if the user = doesn't pause > > during the vm_event handling but exits immediately and disables = vm_event, the > > situation becomes racey as disabling vm_event may succeed before the = guest's > > vCPUs get scheduled with the pending emulation task. This has been = particularly > > the case with VMS that have several vCPUs as after the VM is = unpaused it may > > actually take a long time before all vCPUs get scheduled. > > > > In this patch we are reverting the default behavior to always = perform emulation > > of register write events when the event occurs. To postpone them can = be turned > > on as an option. In that case the user of the interface still has to = take care > > of only disabling the interface when its safe as it remains buggy. > > > > Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by = vm_event > > reply'). > > > > Signed-off-by: Tamas K Lengyel >=20 > Applicable parts > Acked-by: Jan Beulich >=20 Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Tue Jun 09 10:23:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 10:23:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jibPG-0006cd-Rr; Tue, 09 Jun 2020 10:22:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jibPF-0006cX-Ds for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 10:22:57 +0000 X-Inumbo-ID: 2ef3bc18-aa3b-11ea-b301-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2ef3bc18-aa3b-11ea-b301-12813bfff9fa; Tue, 09 Jun 2020 10:22:56 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: EOsWrPTebEbtU0to4SChpf/HjOT3LEn6GUXRBVPWbATRtwthm1Jt+84v/uQlmtmaZHspttUBER x2HfHuNr9hwhzcJ6S4r8BRrVeaUvLp6wnec+vOGcaY4TBSgK3ZfHO7vUEyTILH78v1W3PpAsi8 vEgrf7EcBi0Xz73UzIXX/pEjQYmLRu55vS6Po5Z4diTeeOiaoxjMnxtbxyVHjgGLxurArb6hrG JNTjlhYxWCbIWlpZF6wZb0NSrphk0I/191MJtP65ugcQwOr6BxbAgKSk77/ZxQucDVgQ0/hy6t VQw= X-SBRS: 2.7 X-MesageID: 20318778 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,491,1583211600"; d="scan'208";a="20318778" Subject: Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table To: Martin Lucina , , References: <20200609094425.GB9734@nodbug.lucina.net> From: Andrew Cooper Message-ID: <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> Date: Tue, 9 Jun 2020 11:22:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200609094425.GB9734@nodbug.lucina.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 09/06/2020 10:44, Martin Lucina wrote: > Hi, > > I've been making progress on bootstrapping a new, PVHv2 only, Xen platform > stack for MirageOS [1]. The basics are now functional and I have started to > re-implement the grant table code. > > After studying both the Mini-OS and Linux implementations some, I don't > understand the difference between using XENMAPSPACE_grant_table vs. > GNTTABOP_setup_table to set up the initial grant table mapping for the > guest. > > Are these calls just newer and older ways of accomplishing the same thing? > The Linux driver seems to use both in various conditions, whereas Mini-OS > uses the former on ARM and the latter on x86. > > If these are functionally equivalent, then for my purposes I'd rather use > XENMAPSPACE_setup_table, since IIUC this lets me map the grant table at an > address of my choosing rather than GNTTABOP_setup_table which at least on > x86_64 appears to be returning PFNs at the top of the address space. > > Any advice much appreciated, There is a little bit of history here... GNTTABOP_setup_table was the original PV way of doing things (specify size as an input, get a list of frames as an output to map), and XENMAPSPACE_grant_table was the original HVM way of doing things (as mapping is the other way around - I specify a GFN which I'd like to turn into a grant table mapping). When grant v2 came along, it was only XENMAPSPACE_grant_table updated to be compatible.  i.e. you have to use XENMAPSPACE_grant_table to map the status frames even if you used GNTTABOP_setup_table previously. It is a mistake that GNTTABOP_setup_table was usable in HVM guests to being with.  Returning -1 is necessary to avoid an information leak (the physical address of the frames making up the grant table) which an HVM guest shouldn't, and has no use knowing. An with that note, ARM is extra special because the grant API is specified to use host physical addresses rather than guest physical (at least for dom0, for reasons of there generally not being an IOMMU), which is why it does use the old PV way. It is all a bit of a mess. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 09 10:32:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 10:32:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jibYY-0007aD-UQ; Tue, 09 Jun 2020 10:32:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jibYY-0007a8-Iy for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 10:32:34 +0000 X-Inumbo-ID: 87594868-aa3c-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 87594868-aa3c-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 10:32:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6C004ABCF; Tue, 9 Jun 2020 10:32:36 +0000 (UTC) Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers To: Paul Durrant References: From: Jan Beulich Message-ID: <0d16dda5-298d-248c-7b9e-f27d74ca1b7c@suse.com> Date: Tue, 9 Jun 2020 12:32:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 05.06.2020 19:37, Andrew Cooper wrote: > On 05/06/2020 08:51, Jan Beulich wrote: >> Both match prior generation processors as far as LBR and C-state MSRs >> go (SDM rev 072) as well as applicability of the if_pschange_mc erratum >> (recent spec updates). >> >> Signed-off-by: Jan Beulich >> --- >> Such changes having been subject to backporting in the past, this >> change may want considering for 4.14. >> --- >> I'm leaving alone spec_ctrl.c, albeit there's a scary looking erratum >> for Ice Lake indicating that MDS_NO may wrongly be set. But this is >> apparently addressed by ucode update, so we may not need to deal with >> it in software. > > I've enquired about this.  At a guess, there was another hole found, so > MDS_NO has been cleared and VERW flushing reinstated. > > Either way, changes there can wait until we've got confirmation. > > Acked-by: Andrew Cooper Paul - any thoughts about this one either way for 4.14? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 10:37:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 10:37:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jibcl-0007m8-Gr; Tue, 09 Jun 2020 10:36:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jibck-0007m3-Jc for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 10:36:54 +0000 X-Inumbo-ID: 22379f88-aa3d-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x62d.google.com (unknown [2a00:1450:4864:20::62d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 22379f88-aa3d-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 10:36:53 +0000 (UTC) Received: by mail-ej1-x62d.google.com with SMTP id q19so21784051eja.7 for ; Tue, 09 Jun 2020 03:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=xDrG0IBGL3d1f09YwyXG+nOe4RkWdBkRplunH4cdBYk=; b=uDJ/6nH5cIpXGK5BeroZuPvvTZ1ynvw3whpU48hS4YkrMcfHr093yozc/p7n06vUbK KVzuqeZHRy++yZJm9njgwUtR6p9vFeg84BjwlgeoPpHAjVoBRpDnITxsLNJrRNPmqz8w s4G19J9rygsEqiEXwTxkxQW6cBCSXd7wHbnOyMdsU9v+TWwyJqLGiLGqpVHeW0K1c/qk 2PfCGHkTGV/jAXxpEggBFGvjSlNRbv6TcFB/BSkaYIvXSXn8Cpx1a9yUmcDnwbYFArIS te5lgJHyxdQ/9VQj3mKrnivKCGBrg+APvJs/wRD+9urODPbZjvteIZF7EJSUCsIPNkPj Hl5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=xDrG0IBGL3d1f09YwyXG+nOe4RkWdBkRplunH4cdBYk=; b=IX0N1VFFcD244lqhlFI7Ks3EbJE7m1bgqiTwQ3GIIS9QF51NUM11s2VfxRqWCw57kH kk0T4ajEc3No+9ehk0jbeMU/oriiU5rT+3nCjT/TRcvwraW06O45X5GgE7cBRBtNn83j 4vu52Nl7nigByQuCIFZ/iy6mLyFa2ekLkYZn4Ieyt7tiwh72JWe0D85NP6t6z0PspwnN CuF2+5RNRFhtnQtyjMmxTaapvnupVDjmVGyV0TDLlrVIAAQnRNhibUJOITrH6/0h6hU+ ndlI9PEEaYDtVSL1EJuF2ld+SJ/eKZgrS1Bm4BNeTpJ/LkpcJoyiHmYciG8+H4G0MraJ JPRg== X-Gm-Message-State: AOAM531qlw0PSQE5iGs1k7glhGDpbD0mpAtzAQCl/3ooZCWOEI6Wc/7d +dnMZ7wr4KMHYVLY8DirYIE= X-Google-Smtp-Source: ABdhPJyHbbWaQS4m7C0LHQk17XJzqVW0H2QpBO5GWuDWt3RyaGLuOOUpb9rfsyQwwcS943/xeVDLVw== X-Received: by 2002:a17:907:9486:: with SMTP id dm6mr25817567ejc.248.1591699012841; Tue, 09 Jun 2020 03:36:52 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id b26sm1200494eju.6.2020.06.09.03.36.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 03:36:52 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <0d16dda5-298d-248c-7b9e-f27d74ca1b7c@suse.com> In-Reply-To: <0d16dda5-298d-248c-7b9e-f27d74ca1b7c@suse.com> Subject: RE: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model numbers Date: Tue, 9 Jun 2020 11:36:50 +0100 Message-ID: <007901d63e49$e3420de0$a9c629a0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHNuGDW4G6EWwQ8Lw5IwByx9xcfDQHRd/baAjaUi1CowOJpgA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= , 'Wei Liu' , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 09 June 2020 11:33 > To: Paul Durrant > Cc: Andrew Cooper ; = xen-devel@lists.xenproject.org; Roger Pau Monn=C3=A9 > ; Wei Liu > Subject: Re: [PATCH] x86/Intel: insert Ice Lake and Comet Lake model = numbers >=20 > On 05.06.2020 19:37, Andrew Cooper wrote: > > On 05/06/2020 08:51, Jan Beulich wrote: > >> Both match prior generation processors as far as LBR and C-state = MSRs > >> go (SDM rev 072) as well as applicability of the if_pschange_mc = erratum > >> (recent spec updates). > >> > >> Signed-off-by: Jan Beulich > >> --- > >> Such changes having been subject to backporting in the past, this > >> change may want considering for 4.14. > >> --- > >> I'm leaving alone spec_ctrl.c, albeit there's a scary looking = erratum > >> for Ice Lake indicating that MDS_NO may wrongly be set. But this is > >> apparently addressed by ucode update, so we may not need to deal = with > >> it in software. > > > > I've enquired about this. At a guess, there was another hole found, = so > > MDS_NO has been cleared and VERW flushing reinstated. > > > > Either way, changes there can wait until we've got confirmation. > > > > Acked-by: Andrew Cooper >=20 > Paul - any thoughts about this one either way for 4.14? >=20 I don't see any harm in it going in at this stage. Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Tue Jun 09 10:42:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 10:42:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jibhe-00009b-3j; Tue, 09 Jun 2020 10:41:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jibhc-00009V-FV for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 10:41:56 +0000 X-Inumbo-ID: d66ab7f6-aa3d-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d66ab7f6-aa3d-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 10:41:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 653B6AAC6; Tue, 9 Jun 2020 10:41:58 +0000 (UTC) Subject: Re: [PATCH for-4.14] docs: Minor build improvements To: Andrew Cooper References: <20200608171556.27847-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <75b41942-3281-39ba-fa46-4a55667989f8@suse.com> Date: Tue, 9 Jun 2020 12:41:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200608171556.27847-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Ian Jackson , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 19:15, Andrew Cooper wrote: > Don't use "set -x" for the figs rule. It doesn't take effect in the recursive > make environment. I'd rather view this as an unintended debugging leftover. > Turn the HTML manpage comments into makefile comments, not shell comments. > This saves 3x shell invocations per manpage. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:03:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:03:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic2P-00021u-0k; Tue, 09 Jun 2020 11:03:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic2M-00021p-MC for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:03:23 +0000 X-Inumbo-ID: d4a80a7e-aa40-11ea-b305-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id d4a80a7e-aa40-11ea-b305-12813bfff9fa; Tue, 09 Jun 2020 11:03:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591700600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AGuN3wM4I0BralfErs2ulp7k2NU1Mw2uS1iHN1MhyPM=; b=Hjw0DGqkKb/riXWMqn+f9iplwRDu8qEiXr7tpDYWrz02YwUD/zijRZCAqP1N92rrJUB+kl jn8Wtq6GG7URPz7yUT6gXDc8W5qSrIgBM2cSnJ0GY1dkng60ODEfUZ004HlPKCnOQFhyDy ZNG8Ih1pRxY1PZVTRR/xYk7/HNB6jyU= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-21-Nfe3kRG0MHirhwfX67968A-1; Tue, 09 Jun 2020 07:03:18 -0400 X-MC-Unique: Nfe3kRG0MHirhwfX67968A-1 Received: by mail-wm1-f69.google.com with SMTP id a7so524313wmf.1 for ; Tue, 09 Jun 2020 04:03:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AGuN3wM4I0BralfErs2ulp7k2NU1Mw2uS1iHN1MhyPM=; b=DPMWdvI0C4RrtafYTgijSlJxCflB+AbVfAfW4jQpkrMvoVh1RWLLm9g5WvGsXUy4wU H++7ALuoMgGw6pcbR2ovQGm/jfgkCv7lLIruVMSmR9epNjoMFwAhmRCkS1qOyg5mjQjl QG0kJvO/F176cp6rUXR4u0S6lhyUkvIbksF7Dxgz1ebBw34mwy9E4tYdyKUxf5AsVlV2 C01dhP+dZiEP3Xuc2oGszETeC3eSXoq9PpqRtPW4eSFrxYZDd4G2An5QZMvU1i6riINb hn6IavbTwhupCoo2DuzJ7sdXO06wvj3yzHduDS/HG1YiTG6vr53MIMeA0C8svO26Pjee QqMg== X-Gm-Message-State: AOAM530GpsZZasY63vrKK75gahrbDyw1rC9FLyIavBuEnA1cniYXQXH4 jKDiNmSiWz33drUBle7xaAZRCO18g+xSVPqRhZFm2Betc+Wz7HYh1uNfrBdXyAlvLDULo+ABkf2 DgdAYyaOPncMbtfa39azXKa6adgY= X-Received: by 2002:adf:fdcd:: with SMTP id i13mr3615806wrs.190.1591700597529; Tue, 09 Jun 2020 04:03:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxDvLBQJgRiWZcWe2u7EwQcm+tdrRwDV7JS7cSYFfquo5pnCwJjyQFwLMFNNTExDMlkFTA1qg== X-Received: by 2002:adf:fdcd:: with SMTP id i13mr3615759wrs.190.1591700597265; Tue, 09 Jun 2020 04:03:17 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id u3sm2969549wrw.89.2020.06.09.04.03.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:03:16 -0700 (PDT) Subject: Re: [RFC PATCH 33/35] hw/timer/slavio_timer: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-34-philmd@redhat.com> From: Paolo Bonzini Message-ID: <0bc0385a-9738-a9ea-d3c9-115955d5e8e6@redhat.com> Date: Tue, 9 Jun 2020 13:03:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-34-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/timer/slavio_timer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/timer/slavio_timer.c b/hw/timer/slavio_timer.c > index 4c5d65e391..16f21669bf 100644 > --- a/hw/timer/slavio_timer.c > +++ b/hw/timer/slavio_timer.c > @@ -31,6 +31,7 @@ > #include "migration/vmstate.h" > #include "trace.h" > #include "qemu/module.h" > +#include "hw/qdev-deprecated.h" > > /* > * Registers of hardware timer in sun4m. > @@ -392,6 +393,8 @@ static void slavio_timer_init(Object *obj) > unsigned int i; > TimerContext *tc; > > + qdev_warn_deprecated_function_used(); > + > for (i = 0; i <= MAX_CPUS; i++) { > uint64_t size; > char timer_name[20]; > This one is okay. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:05:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:05:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic3x-00027Q-CM; Tue, 09 Jun 2020 11:05:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic3w-00027J-Oh for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:05:00 +0000 X-Inumbo-ID: 0f84a1d5-aa41-11ea-b305-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 0f84a1d5-aa41-11ea-b305-12813bfff9fa; Tue, 09 Jun 2020 11:04:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591700699; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ki/NH7KwE2iZfzrfj27y3fd4qwWI07EUloemfjIHR0Y=; b=YpcW/NI6BuJRAiQE3YdAwK0K0BJglNs9ZTkBK1WZEMzaGiRTyd1CoB8cLzpFwf+y3e5zh6 6pf0sZS9cjwVPH2cpzfvpTW/DS7XB+j2viyPnZfqAF9tvTUl2L9WP3fnUgMycO03uepikz OJpqcY4MFkfN0OPYlepXtqT1nzc7PJg= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-197-PJyobAoeOaqYeLc6h7MXaQ-1; Tue, 09 Jun 2020 07:04:53 -0400 X-MC-Unique: PJyobAoeOaqYeLc6h7MXaQ-1 Received: by mail-wm1-f70.google.com with SMTP id y15so526895wmi.0 for ; Tue, 09 Jun 2020 04:04:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ki/NH7KwE2iZfzrfj27y3fd4qwWI07EUloemfjIHR0Y=; b=bLOzVv3Q/La/6oeGHBOIaWO7NRgjOqFPCLILoWAQk6VoVNDjX9pWyk6jOhzvceF/80 /SMQa6x8b+0kmMkZfPSSyvjwtDNiIZODQr9PIRsYXdMTZOSC153QFrpqOC9CGcjC8azn QzWnKLA4jiKld0uMuQW+nEB1hZkBnCC3png0aTi1N0f4adBnZ3bj5OlmBDsxlH72STA9 naomzTJwSrQu6K2ZTC+SpPsfsGHW+96WI8SwgYxuSnlTQbU3j07eFLYP6EqjNQpeKlfI XcOrUAeukc+/DFCyJSD5U3t7O+LdqnNZpoBPv1fjlQNnG+sn93uIe/YS+C3Oj6nWR9FC Axyg== X-Gm-Message-State: AOAM530feVUeSFXOFwO6A1vA2mbeqrsNUJ640tuyVWqLPLXPDfe/mgR+ AIQwlx1RDarV4yzR6LWU+Vl9Kfpr46FAyh8/Y0SP2M7qMqtV0u24QD1VA8h79FWT3GQxceHizpu Jd61ABzHLDH0e3M1fQyL2MoNpQXA= X-Received: by 2002:a5d:4e87:: with SMTP id e7mr3608995wru.427.1591700691534; Tue, 09 Jun 2020 04:04:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw61DF3zQg2Ykdl+eVskia6XAOI0NHB76zgWVAci3VuUK5xBuVU12NxurjEhvkEdodKHniwzg== X-Received: by 2002:a5d:4e87:: with SMTP id e7mr3608951wru.427.1591700691283; Tue, 09 Jun 2020 04:04:51 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id e5sm3132662wrw.19.2020.06.09.04.04.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:04:50 -0700 (PDT) Subject: Re: [RFC PATCH 32/35] hw/riscv: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-33-philmd@redhat.com> From: Paolo Bonzini Message-ID: <78a05ce1-ce9a-431a-69df-77b0a8fcfce9@redhat.com> Date: Tue, 9 Jun 2020 13:04:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-33-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/riscv/riscv_htif.c | 4 ++++ > hw/riscv/sifive_uart.c | 4 ++++ > 2 files changed, 8 insertions(+) > > diff --git a/hw/riscv/riscv_htif.c b/hw/riscv/riscv_htif.c > index ca87a5cf9f..bd080dbefb 100644 > --- a/hw/riscv/riscv_htif.c > +++ b/hw/riscv/riscv_htif.c > @@ -30,6 +30,7 @@ > #include "hw/riscv/riscv_htif.h" > #include "qemu/timer.h" > #include "qemu/error-report.h" > +#include "hw/qdev-deprecated.h" > > #define RISCV_DEBUG_HTIF 0 > #define HTIF_DEBUG(fmt, ...) \ > @@ -238,6 +239,9 @@ HTIFState *htif_mm_init(MemoryRegion *address_space, MemoryRegion *main_mem, > uint64_t fromhost_offset = fromhost_addr - base; > > HTIFState *s = g_malloc0(sizeof(HTIFState)); > + > + qdev_warn_deprecated_function_used(); > + > s->address_space = address_space; > s->main_mem = main_mem; > s->main_mem_ram_ptr = memory_region_get_ram_ptr(main_mem); > diff --git a/hw/riscv/sifive_uart.c b/hw/riscv/sifive_uart.c > index 9350482662..1a5890d5f7 100644 > --- a/hw/riscv/sifive_uart.c > +++ b/hw/riscv/sifive_uart.c > @@ -25,6 +25,7 @@ > #include "hw/hw.h" > #include "hw/irq.h" > #include "hw/riscv/sifive_uart.h" > +#include "hw/qdev-deprecated.h" > > /* > * Not yet implemented: > @@ -183,6 +184,9 @@ SiFiveUARTState *sifive_uart_create(MemoryRegion *address_space, hwaddr base, > Chardev *chr, qemu_irq irq) > { > SiFiveUARTState *s = g_malloc0(sizeof(SiFiveUARTState)); > + > + qdev_warn_deprecated_function_used(); > + > s->irq = irq; > qemu_chr_fe_init(&s->chr, chr, &error_abort); > qemu_chr_fe_set_handlers(&s->chr, uart_can_rx, uart_rx, uart_event, > Reviewed-by: Paolo Bonzini Not sure why this code was accepted, furthermore it should have been in hw/char. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:05:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:05:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic4J-0002Aj-Q2; Tue, 09 Jun 2020 11:05:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic4I-0002Aa-Tb for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:05:22 +0000 X-Inumbo-ID: 1c93a154-aa41-11ea-b7bb-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 1c93a154-aa41-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 11:05:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591700721; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S4OQhSEiQViO6+Bf5ntoxU/3fnBLGSIOBfTZnNbLbrw=; b=X75r9BtyBLTrJpkTe713Vj9hTVP42JGGOewHFSP0/1SD9gU9BCJvvGSTAVOx7oqmD0zzhh qkGtr5AjR7TCxx0MtNNOh4v0nKqitBYtmaIQDNUA0UiG3fvQgEu0it8NWGMvTeZ79H2qwv 5gz2qTAqr1APjvAqD2BoOghsl5czW3g= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-215-ylBPv5FRN6SvS2fsOLlZGQ-1; Tue, 09 Jun 2020 07:05:14 -0400 X-MC-Unique: ylBPv5FRN6SvS2fsOLlZGQ-1 Received: by mail-wr1-f72.google.com with SMTP id f4so8472803wrp.21 for ; Tue, 09 Jun 2020 04:05:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=S4OQhSEiQViO6+Bf5ntoxU/3fnBLGSIOBfTZnNbLbrw=; b=dEPpbVaJQ6lDaVEbrWSwXpa4FV8mdf7gGKG0dewH39VyXNEGzUtZJpd5J4hVMnd+vY EIr0L9Ek/LzQygPusJdlNLjteNLeEDvtUJbTrQnXrysH4GetZW7pOoBV0mN44jEylCTD gifEQfUfbGViMRwFDKTDkzwjERoWmEICPWKtgAUwjN7CMhgH6n+dJym7B9aS3dgFrAUv dr0CBhRDNmwK82hCmW9ndZj70iCh2ErN0PGLzf66o7Ges5j+eCAJnA0thzbPrCacvaMY tNOOdcR+1ECjdG0XMqU2ygcqmSRRNQngFWrruROMCQdoKamQ7D27H9oFhazJJra+LtIx dIUg== X-Gm-Message-State: AOAM531qvF5PMn4b772Kxfb3MEXJxbtvp/7ICGvHmO2bAGs/bf4/Blwx Y5S0bcZ6o5ezJVOHCCQ+h0ZHRk91lqg6ljFtE/H55sxRKJZX7w1znSmRU4VpS+6Z3AZiTslRNGP 73AJggU+SBscfDWr7+VemvMrW/cg= X-Received: by 2002:adf:ef83:: with SMTP id d3mr3590968wro.145.1591700713618; Tue, 09 Jun 2020 04:05:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJypMcVAQwaW/I6vICjH3pnYoVeg7kiHWBRxB9LtVfTU1+Z7wL7jJgUZk4SDqi6hRzq7g/7iig== X-Received: by 2002:adf:ef83:: with SMTP id d3mr3590931wro.145.1591700713378; Tue, 09 Jun 2020 04:05:13 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id u7sm2957241wrm.23.2020.06.09.04.05.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:05:12 -0700 (PDT) Subject: Re: [RFC PATCH 23/35] hw/misc/applesmc: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-24-philmd@redhat.com> From: Paolo Bonzini Message-ID: Date: Tue, 9 Jun 2020 13:05:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-24-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/misc/applesmc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c > index 1c4addb201..d63f19038d 100644 > --- a/hw/misc/applesmc.c > +++ b/hw/misc/applesmc.c > @@ -36,6 +36,7 @@ > #include "ui/console.h" > #include "qemu/module.h" > #include "qemu/timer.h" > +#include "hw/qdev-deprecated.h" > > /* #define DEBUG_SMC */ > > @@ -253,6 +254,8 @@ static void applesmc_add_key(AppleSMCState *s, const char *key, > { > struct AppleSMCData *def; > > + qdev_warn_deprecated_function_used(); > + > def = g_malloc0(sizeof(struct AppleSMCData)); > def->key = key; > def->len = len; > This one is okay. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:07:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:07:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic5u-0002Mq-5o; Tue, 09 Jun 2020 11:07:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic5s-0002Mk-96 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:07:00 +0000 X-Inumbo-ID: 56d326dc-aa41-11ea-b7bb-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 56d326dc-aa41-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 11:06:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591700819; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HLtEn6u9uzHwCvd1JnB+QPNLdle/XjOro9YfrFmD+kg=; b=JtxmvSONAsm6XhHv31D6eIqHUVVF/KPH3pV0JakH8lAi3REA4U6NlrDxsYz59Y5f+zRRTv Qrg2mehFAk5eLmR6koKhkSmbpwFkKm+Q7rzBzTtnwWKzZlFGLlqiZNCM9IgRP22c4MnyS8 c4XHCKSWTokWVBtBjMPj4lQm/tBGsS4= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-490-RAyjCSOpPuqjbUVWrJr-vQ-1; Tue, 09 Jun 2020 07:06:57 -0400 X-MC-Unique: RAyjCSOpPuqjbUVWrJr-vQ-1 Received: by mail-wm1-f70.google.com with SMTP id k185so518376wme.8 for ; Tue, 09 Jun 2020 04:06:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HLtEn6u9uzHwCvd1JnB+QPNLdle/XjOro9YfrFmD+kg=; b=Mm2cKBhrlcU8mm78hMzZ/e1o/Vc/ZDV2nZryE9rfVfSfsNG8ACPTq979jJBvoEn0+x uYP3kyk+DzpClOvmzPALRz9dKyCmE06VDyc10b6FZH+P0y9va0c5ghuCmV4fUQjd7/hY Ea3WrVs//6dYBY9W8/CsoQYan+qASilsoZfKNcG4CnBaHZmwUAEkU2TDSONNBmzIJ/uB qo+Wd5jRhcTo38VkVKw3WaWsWdw1VplMDkW6hDH1gi2CgAA4302mjI16Zj3YcemdT3rz Rd5Jul2OaMc9Brzv4WVyWobjghnCEGAU8/9q+oWeOP/iizI5uEpyEcKFZSD5VymX/7VK XX8w== X-Gm-Message-State: AOAM533MVB8b+Db8xHsmPKzHLpqXnva4czBqFmNiBv4YPr3S+yyHJlvL s8ceN8YX1fKj5ElfG5kkeBZxKB2xJuBWp+xh606dFDV+K/gu0fcQRR9kHAcopqU0gaBtoFjaSZr 0ZrXjEyqk1m74GuquWOxo7EOrSZs= X-Received: by 2002:adf:e648:: with SMTP id b8mr3979236wrn.386.1591700816417; Tue, 09 Jun 2020 04:06:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwoEAqomO/pDUWsIe68Vfly9NVZSlhu3lj0ZH+nYvBwJM+baKNFuGqYNGT83VHTTt9pGx/hA== X-Received: by 2002:adf:e648:: with SMTP id b8mr3979198wrn.386.1591700816219; Tue, 09 Jun 2020 04:06:56 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id q5sm2976228wrm.62.2020.06.09.04.06.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:06:55 -0700 (PDT) Subject: Re: [RFC PATCH 18/35] hw/input/ps2: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-19-philmd@redhat.com> From: Paolo Bonzini Message-ID: Date: Tue, 9 Jun 2020 13:06:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-19-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/input/ps2.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/hw/input/ps2.c b/hw/input/ps2.c > index f8746d2f52..0d84061cae 100644 > --- a/hw/input/ps2.c > +++ b/hw/input/ps2.c > @@ -30,7 +30,7 @@ > #include "ui/input.h" > #include "sysemu/reset.h" > #include "sysemu/runstate.h" > - > +#include "hw/qdev-deprecated.h" > #include "trace.h" > > /* debug PC keyboard */ > @@ -1136,6 +1136,8 @@ void *ps2_kbd_init(void (*update_irq)(void *, int), void *update_arg) > { > PS2KbdState *s = (PS2KbdState *)g_malloc0(sizeof(PS2KbdState)); > > + qdev_warn_deprecated_function_used(); > + > trace_ps2_kbd_init(s); > s->common.update_irq = update_irq; > s->common.update_arg = update_arg; > @@ -1158,6 +1160,8 @@ void *ps2_mouse_init(void (*update_irq)(void *, int), void *update_arg) > { > PS2MouseState *s = (PS2MouseState *)g_malloc0(sizeof(PS2MouseState)); > > + qdev_warn_deprecated_function_used(); > + > trace_ps2_mouse_init(s); > s->common.update_irq = update_irq; > s->common.update_arg = update_arg; > While the keyboard and mouse are not QOM-ified, of the controllers (i8042, lasips2, pl050) only lasips2 is not. I would warn there. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:07:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:07:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic6b-0002RA-F3; Tue, 09 Jun 2020 11:07:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic6a-0002R1-4h for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:07:44 +0000 X-Inumbo-ID: 711889d8-aa41-11ea-8496-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 711889d8-aa41-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 11:07:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591700863; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9N2hQA54vscW2wYRbiWR3tdH19bd/eus87N3YlhQewI=; b=LZYIz9njjiwDr//wgh+lsHkMPxbP8zd7foyie9O1J2Oq7FmPPg0pBRE2Nr8xqqJLPTMFYv M6wbLteHP9f/EWVRY3RJaBFjDW5v0UIQFf5wAEeBLHX7dBbEK5OrDzZucYShB4YwQCAjAw tHMWv7f+QlJ4lYKnwWFh/osJIhNanB0= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-464-tpVjFtxgPfaFp_985NkvEg-1; Tue, 09 Jun 2020 07:07:39 -0400 X-MC-Unique: tpVjFtxgPfaFp_985NkvEg-1 Received: by mail-wm1-f69.google.com with SMTP id g84so603692wmf.4 for ; Tue, 09 Jun 2020 04:07:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9N2hQA54vscW2wYRbiWR3tdH19bd/eus87N3YlhQewI=; b=NISxwASh/2ajCNX5mM6UhUyH6YgvLZgLx3CMVAwoSPxIh0UXfIlUuwVMXCaKgKcVkb dFo2xZ4GZlDQcCOcUnKv2TJB/R8SHTZMtly+OOTUPY4cBatQH2TC4dyteheTPqj45WL8 4pE03xH5MOyJFVkbLPbxecehn5PoZVguB60sKqbuHdcG7rk8V1k0Q2Fr1OsHzJYW7sCi eH6BrDTEo7lOJFWKTJlZ22ifxa5cazVGMAVtodjuR2KVdTug6phyh5CZtVb0EjDdFQiE j1pp3D//EcYK9g+hT4aT9FSXvdXUP8GhPTCI7I5llO8pcQEqcnMpl1Wm7zzON3mSUctI GJ0A== X-Gm-Message-State: AOAM532879POp5ybhgha3ceeGZpwjyEtA0FyPRfkKczKmJ2Efx7JWM/C Z1alTFhpvA348DP3pk8E/izmFgHGHhmYfpSRY9unKzOclA4Jnp8gHpvVUZvxoIjJgcGo2w5IzT/ 2vwAnvKKuybQpEDEnvgFhyOKLA+U= X-Received: by 2002:a1c:bad7:: with SMTP id k206mr3381152wmf.11.1591700858709; Tue, 09 Jun 2020 04:07:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxmmnUl8eLPhmEPFuKu6sJiacZuSMv+9NuEpBWzXhQnd/T9N7bfObZmAohH0mdSOoMNNOmGLw== X-Received: by 2002:a1c:bad7:: with SMTP id k206mr3381101wmf.11.1591700858431; Tue, 09 Jun 2020 04:07:38 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id s8sm3061694wrm.96.2020.06.09.04.07.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:07:37 -0700 (PDT) Subject: Re: [RFC PATCH 17/35] hw/input/pckbd: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-18-philmd@redhat.com> From: Paolo Bonzini Message-ID: Date: Tue, 9 Jun 2020 13:07:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-18-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/input/pckbd.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c > index 60a4130320..c7f42be63b 100644 > --- a/hw/input/pckbd.c > +++ b/hw/input/pckbd.c > @@ -31,7 +31,7 @@ > #include "hw/input/i8042.h" > #include "sysemu/reset.h" > #include "sysemu/runstate.h" > - > +#include "hw/qdev-deprecated.h" > #include "trace.h" > > /* Keyboard Controller Commands */ > @@ -467,6 +467,8 @@ void i8042_mm_init(qemu_irq kbd_irq, qemu_irq mouse_irq, > { > KBDState *s = g_malloc0(sizeof(KBDState)); > > + qdev_warn_deprecated_function_used(); > + > s->irq_kbd = kbd_irq; > s->irq_mouse = mouse_irq; > s->mask = mask; > Reviewed-by: Paolo Bonzini The ISA variant is QOM-ified, but you placed the warning in the right place. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:08:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:08:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic77-0002Xk-O3; Tue, 09 Jun 2020 11:08:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic76-0002Xa-II for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:08:16 +0000 X-Inumbo-ID: 843c4c99-aa41-11ea-b307-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 843c4c99-aa41-11ea-b307-12813bfff9fa; Tue, 09 Jun 2020 11:08:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591700896; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nzIR+3VysZFR+NGFD1AmGomUUyfUE6amVvn/ew5M7nY=; b=OyHpAaQJdsGL8vfGCHtmjpueoLbhAJK2sr1+kK/qmR8exBExbEjBspXsgRjSYSLIGCKRzv 8JcSlpEse1zqhRa28Qc43TYvUVRHWmIy+wm59j6iebdRutiB0BfK1AZT9VXK8cI5CvlV1x DsQhHEX+8evJFuqO9aKNehlc2vTn2UE= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-105-Vjc0wUdtOwKepODSgrmW6g-1; Tue, 09 Jun 2020 07:08:14 -0400 X-MC-Unique: Vjc0wUdtOwKepODSgrmW6g-1 Received: by mail-wm1-f69.google.com with SMTP id c4so607326wmd.0 for ; Tue, 09 Jun 2020 04:08:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nzIR+3VysZFR+NGFD1AmGomUUyfUE6amVvn/ew5M7nY=; b=DKphJ5RTo6NrnFV4rKiAziPF19gEa0AjeEr9gWGcO8w2+mcg2IT8i8ye5NXA65C5gv CgPJDtpVxJ2lSbdBI3/LXCC++yP19q5daddOnn9ofESaTCFh52V8350CLOo7nEzGMndD e+JwQZCozowT6klPFen31rghpnMybQf+PK2eLA5WEy1U64rDKpUKKHktXHGICW/QLj7E FdT+hPRnZykafXz3J6S3x2ncJGNUcQBWsedfS+gO+GyYCNhEKdIxpqyXEOR8ByDdLEJt OFH/LWeiI1fMlPR8A6dwBQ26RY2OswEKY5JvNf1/ZRDgvzHLJUcHMR4QPtwerH1k7hbp tRig== X-Gm-Message-State: AOAM531vTwiHr1JqzHk2ooAKQLCYpePWVX8VYOCqgPckK15RoTZc3Hff 8UsP6F4vwFGvgs741fSSC/TKdY0ZqDX3VaKr4A9iK+EnCnyAaBjhKvdgfa5UFp+RZ0BSLCvolAw yEJ2EKUEXahyORVwIz4JXvbpoft0= X-Received: by 2002:a1c:7215:: with SMTP id n21mr3428435wmc.10.1591700893213; Tue, 09 Jun 2020 04:08:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxdC3784/XM7YgW9UJ09UlWBbxHKdjVmbxcRKY6OuIHXNLH2XpKSYf455WgqT5IWKVna7+8aw== X-Received: by 2002:a1c:7215:: with SMTP id n21mr3428413wmc.10.1591700892989; Tue, 09 Jun 2020 04:08:12 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id r11sm3060354wre.25.2020.06.09.04.08.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:08:12 -0700 (PDT) Subject: Re: [RFC PATCH 14/35] hw/i386/pc: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-15-philmd@redhat.com> From: Paolo Bonzini Message-ID: <99a85bad-3197-6a74-5218-86f2326cd381@redhat.com> Date: Tue, 9 Jun 2020 13:08:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-15-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/i386/pc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > index 2128f3d6fe..c71809fd28 100644 > --- a/hw/i386/pc.c > +++ b/hw/i386/pc.c > @@ -94,6 +94,7 @@ > #include "vmport.h" > #include "fw_cfg.h" > #include "trace.h" > +#include "hw/qdev-deprecated.h" > > GlobalProperty pc_compat_5_0[] = {}; > const size_t pc_compat_5_0_len = G_N_ELEMENTS(pc_compat_5_0); > @@ -348,6 +349,8 @@ GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled) > { > GSIState *s; > > + qdev_warn_deprecated_function_used(); > + > s = g_new0(GSIState, 1); > if (kvm_ioapic_in_kernel()) { > kvm_pc_setup_irq_routing(pci_enabled); > This one is okay, GSIState is just an array of qemu_irqs. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:10:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:10:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic94-0003Lg-7v; Tue, 09 Jun 2020 11:10:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic92-0003Ky-Tv for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:10:16 +0000 X-Inumbo-ID: c7e79196-aa41-11ea-bb8b-bc764e2007e4 Received: from honk.recoil.org (unknown [2604:1380:2001:1300::3]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c7e79196-aa41-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 11:10:09 +0000 (UTC) Received: from [IPv6:2a02:390:81d4::e5a2:aa13:2826:18e8] (unknown [IPv6:2a02:390:81d4:0:e5a2:aa13:2826:18e8]) by honk.recoil.org (Postfix) with ESMTPSA id A86393C0189; Tue, 9 Jun 2020 10:50:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=recoil.org; s=selector1; t=1591699841; bh=TR8w4REWHYr5hfE0wj/02gw9m0ryu0Z1r9I3BSO9ZMs=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=f6lSShSP3s+IZmHoHFm+A2Z12+X+dqbZxtCVZFbjWX44UG8qdagW4B6D6RfqKiOAa kX3qcyNmMRnyvLF75X8ifsOpUpKKq04gmy2LEt01ER/Oj9lRyBVmZx4EwNRWY95uI+ cKqr/ixcJGyZZHFzU2vRHFHUtZXijXrRarx8HAbI= From: Anil Madhavapeddy Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A71BAFB1-63AF-4E1D-953C-5E8D0B4A25A2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table Date: Tue, 9 Jun 2020 11:50:39 +0100 In-Reply-To: <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> To: Andrew Cooper References: <20200609094425.GB9734@nodbug.lucina.net> <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> X-Mailer: Apple Mail (2.3445.104.11) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Martin Lucina , mirageos-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Apple-Mail=_A71BAFB1-63AF-4E1D-953C-5E8D0B4A25A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Jun 2020, at 11:22, Andrew Cooper = wrote: >=20 > On 09/06/2020 10:44, Martin Lucina wrote: >> Hi, >>=20 >> I've been making progress on bootstrapping a new, PVHv2 only, Xen = platform >> stack for MirageOS [1]. The basics are now functional and I have = started to >> re-implement the grant table code. >>=20 >> After studying both the Mini-OS and Linux implementations some, I = don't >> understand the difference between using XENMAPSPACE_grant_table vs. >> GNTTABOP_setup_table to set up the initial grant table mapping for = the >> guest. >>=20 >> Are these calls just newer and older ways of accomplishing the same = thing? >> The Linux driver seems to use both in various conditions, whereas = Mini-OS >> uses the former on ARM and the latter on x86. >>=20 >> If these are functionally equivalent, then for my purposes I'd rather = use >> XENMAPSPACE_setup_table, since IIUC this lets me map the grant table = at an >> address of my choosing rather than GNTTABOP_setup_table which at = least on >> x86_64 appears to be returning PFNs at the top of the address space. >>=20 >> Any advice much appreciated, >=20 > There is a little bit of history here... >=20 > GNTTABOP_setup_table was the original PV way of doing things (specify > size as an input, get a list of frames as an output to map), and > XENMAPSPACE_grant_table was the original HVM way of doing things (as > mapping is the other way around - I specify a GFN which I'd like to = turn > into a grant table mapping). >=20 > When grant v2 came along, it was only XENMAPSPACE_grant_table updated = to > be compatible. i.e. you have to use XENMAPSPACE_grant_table to map = the > status frames even if you used GNTTABOP_setup_table previously. >=20 > It is a mistake that GNTTABOP_setup_table was usable in HVM guests to > being with. Returning -1 is necessary to avoid an information leak = (the > physical address of the frames making up the grant table) which an HVM > guest shouldn't, and has no use knowing. >=20 > An with that note, ARM is extra special because the grant API is > specified to use host physical addresses rather than guest physical = (at > least for dom0, for reasons of there generally not being an IOMMU), > which is why it does use the old PV way. Thanks, that makes sense. It doesn't seem too much of a mess from the = guest perspective to use just XENMAPSPACE_grant_table exclusively then. With Martin's work, the MirageOS Xen backend should just use the latest and = greatest APIs, with no backwards compatibility to older Xen versions required. I'm still a little confused about ARM though -- is there an equivalent = of XENMAPSPACE_grant_table there? It sounds like we can't leave the GNTTABOP macros behind entirely... regards, Anil= --Apple-Mail=_A71BAFB1-63AF-4E1D-953C-5E8D0B4A25A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 9 Jun 2020, at 11:22, Andrew Cooper <andrew.cooper3@citrix.com> wrote:

On 09/06/2020 = 10:44, Martin Lucina wrote:
Hi,

I've = been making progress on bootstrapping a new, PVHv2 only, Xen platform
stack for MirageOS [1]. The basics are now functional and I = have started to
re-implement the grant table code.

After studying both the Mini-OS and Linux = implementations some, I don't
understand the difference = between using XENMAPSPACE_grant_table vs.
GNTTABOP_setup_table to set up the initial grant table = mapping for the
guest.

Are = these calls just newer and older ways of accomplishing the same = thing?
The Linux driver seems to use both in various = conditions, whereas Mini-OS
uses the former on ARM and the = latter on x86.

If these are functionally = equivalent, then for my purposes I'd rather use
XENMAPSPACE_setup_table, since IIUC this lets me map the = grant table at an
address of my choosing rather than = GNTTABOP_setup_table which at least on
x86_64 appears to = be returning PFNs at the top of the address space.

Any advice much appreciated,

There is a = little bit of history here...

GNTTABOP_setup_table was the original PV way of doing things = (specify
size as an = input, get a list of frames as an output to map), and
XENMAPSPACE_grant_table was the original HVM way of doing = things (as
mapping is = the other way around - I specify a GFN which I'd like to turn
into a grant = table mapping).

When grant v2 came along, it was only XENMAPSPACE_grant_table = updated to
be = compatible.  i.e. you have to use XENMAPSPACE_grant_table to map = the
status frames = even if you used GNTTABOP_setup_table previously.

It is a = mistake that GNTTABOP_setup_table was usable in HVM guests to
being = with.  Returning -1 is necessary to avoid an information leak = (the
physical = address of the frames making up the grant table) which an HVM
guest = shouldn't, and has no use knowing.

An with that note, ARM is extra special because the grant API = is
specified to = use host physical addresses rather than guest physical (at
least for = dom0, for reasons of there generally not being an IOMMU),
which is why = it does use the old PV way.

Thanks, that makes sense. It doesn't seem too much of a = mess from the guest
perspective to use just = XENMAPSPACE_grant_table exclusively then.  With
Martin's work, the MirageOS Xen backend should just use the = latest and greatest
APIs, with no backwards = compatibility to older Xen versions required.

I'm still a little confused about ARM = though -- is there an equivalent of
XENMAPSPACE_grant_table there? It sounds like we can't leave = the
GNTTABOP macros behind entirely...

regards,
Anil
= --Apple-Mail=_A71BAFB1-63AF-4E1D-953C-5E8D0B4A25A2-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:10:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:10:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic99-0003N5-LA; Tue, 09 Jun 2020 11:10:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic97-0003Ky-Tw for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:10:21 +0000 X-Inumbo-ID: cd73d46c-aa41-11ea-bca7-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id cd73d46c-aa41-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 11:10:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591701018; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tZftxcB2LQwq4WRu0Cjx9f/yr0m/a27AoJYbbnSzCMU=; b=Kwefb0LRlbEQcRj2IBWLkd9O79JWoTrISYk5e8bUuhm5j4IQ4KzSkhymJzkZzHE0jH/p13 hwfUavdw4IRe4iwMQzW4a62oV56OXGAQXpUMxxlwelO/sQgPq0uU1MuBncE9GUqbFUPkBA QmgzrzEgH+1XMTgEXhXwMckjn8Rvlx0= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-218-6wpZAdFrOHe73l81htPEog-1; Tue, 09 Jun 2020 07:10:14 -0400 X-MC-Unique: 6wpZAdFrOHe73l81htPEog-1 Received: by mail-wm1-f70.google.com with SMTP id k185so521717wme.8 for ; Tue, 09 Jun 2020 04:10:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tZftxcB2LQwq4WRu0Cjx9f/yr0m/a27AoJYbbnSzCMU=; b=jViJiRhK/DMIihBnQJZINF97kqPLkWXOKFKlTqyjRjzIhXuvJZn5YoyvvsDPZYhxrk eOeFAkU9M1IT7QzrFpHovhzot8wZXVNL5iGmDkfUXLoEDZ/YI11b12GbBBshWLe2MXhp qXS504avDy32fyqX8i9PVJw+9RP06ba8GuMY/wpfkA3SZoCXoiJNlxLEpXIel8L8pHsk YqXFubBNYRx0BQZ11P2IzlFzNc7+CeA7GoVRAa39seibJywkgJQkaS0+EsQxTYTdw0J4 BIU69+futwS9VHioZiKFGmOqozf/Z+U0cqddUMMEnCDbZQKcgW5mtVyqAJzkkCYO7JxU nLhg== X-Gm-Message-State: AOAM531xo+1V1oHCFrHajcLap5pCLuQZMJog8FrJamkx//Gi5gzoYUCP Uns6ZtxdQIUvMSc50anZQuFuPk00qQJc8bYtLhcBN2lLMfIw3uCsoRbk+dmxR9PXHJTg/I2ssJ3 Mp7ryN22cy3E27L3YbVe0F1Nko5E= X-Received: by 2002:a1c:4e17:: with SMTP id g23mr3355931wmh.38.1591701013436; Tue, 09 Jun 2020 04:10:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJZned0l+0SRbEeJRfGrfGSK0dv05DsTiejFW4ozxbhJOZqse/JM2i7IzQrf8+3BqinX/VGQ== X-Received: by 2002:a1c:4e17:: with SMTP id g23mr3355899wmh.38.1591701013164; Tue, 09 Jun 2020 04:10:13 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id b8sm2981236wrm.35.2020.06.09.04.10.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:10:12 -0700 (PDT) Subject: Re: [RFC PATCH 06/35] hw/timer/arm_timer: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-7-philmd@redhat.com> From: Paolo Bonzini Message-ID: <57ccbbbb-2462-7ae3-52f4-c209a21795cd@redhat.com> Date: Tue, 9 Jun 2020 13:10:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-7-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/timer/arm_timer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/timer/arm_timer.c b/hw/timer/arm_timer.c > index 9607366d78..e23e6b4b31 100644 > --- a/hw/timer/arm_timer.c > +++ b/hw/timer/arm_timer.c > @@ -16,6 +16,7 @@ > #include "hw/qdev-properties.h" > #include "qemu/module.h" > #include "qemu/log.h" > +#include "hw/qdev-deprecated.h" > > /* Common timer implementation. */ > > @@ -175,6 +176,8 @@ static arm_timer_state *arm_timer_init(uint32_t freq) > { > arm_timer_state *s; > > + qdev_warn_deprecated_function_used(); > + > s = (arm_timer_state *)g_malloc0(sizeof(arm_timer_state)); > s->freq = freq; > s->control = TIMER_CTRL_IE; > This one is okay, the devices that use arm_timer_init are all QOM. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:10:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:10:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic9W-0003SG-W2; Tue, 09 Jun 2020 11:10:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic9W-0003Rx-BQ for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:10:46 +0000 X-Inumbo-ID: dd633b2e-aa41-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x633.google.com (unknown [2a00:1450:4864:20::633]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dd633b2e-aa41-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 11:10:45 +0000 (UTC) Received: by mail-ej1-x633.google.com with SMTP id p20so1908203ejd.13 for ; Tue, 09 Jun 2020 04:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=zx5AoOosdYlTaKv0p9tnq8rrFBNsFIGLT11EWzMH0hs=; b=In07grGzbm2tPRPQC0ggbJijnmPBoC3gseWy1O4SLsFP67kMXzjKZtcGxKXldlVrIY X5t2Cdjfw9IhkCSWVzbmNOFwOwj11dIzYiK8IaLQFRCVGF5TdKd6pTCii8nTzze1z+Ov DcF2p67nql3jsubUv0sEjRD2g37JWkvwITaayrO7YkeIt0bENkkLWbmSaquGUladq21F 0LwW5cpfCYjwn1qMEs6OAgfOipjVAFdtP4aoSyG6DU/1YXpYQKT78IIoDkPPUeQBpS3M AX/7ugXvrb3LphlvGWSOYMPIW4jcS0+Gs6hJ/ImYV/UAiv4zXPtRSgeF7AGmeW6hqy4c GtvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=zx5AoOosdYlTaKv0p9tnq8rrFBNsFIGLT11EWzMH0hs=; b=dSCtDUR+g6x19b2u3jEXXqaX0nWeBqqDt6S5oe1MIADOYcGV+kRIvXx+F9sUMWxn8Y c828jiEMlU0YKvIP5/rP20ndLKIiLXyw6z9KkkCuheP3IUUo9ja7WHgD4K/sHdJi2u9P 9alNqg87NIlpqNcY3xwAmWFaKW5WfM//dWy1AispKdg6UGoqhF/8LdZHzkfkbyOo9IWC I6IbRqBTze21jcxPwClSTmMkbIoOInQo5YfAVqFr3cWzbjO+nHjfZbUUAnz7LXTtebDO sLuVeod3oiFUWr/LLmkinY8rGQYdR02X0U9Ifx9EsukuONIM3cATIW0SwKCBQdB+nSGS ut/A== X-Gm-Message-State: AOAM532qw8x7fx2coQPOVr2eWx9uzjaH5MTwNFj4g943EUncjcf+07gh eO4Mo6kyAxsP62193JJ4CtI= X-Google-Smtp-Source: ABdhPJzAHpkfbVB+lonYQyWOAoyZX7OhmsN7nZ8PtPKcAyhhLkvDUvqQxa8LnHLziiMJlKSKmswyog== X-Received: by 2002:a17:906:d111:: with SMTP id b17mr24709296ejz.267.1591701044854; Tue, 09 Jun 2020 04:10:44 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id o8sm12776936ejx.84.2020.06.09.04.10.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 04:10:44 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , "'Andrew Cooper'" References: <20200608171556.27847-1-andrew.cooper3@citrix.com> <75b41942-3281-39ba-fa46-4a55667989f8@suse.com> In-Reply-To: <75b41942-3281-39ba-fa46-4a55667989f8@suse.com> Subject: RE: [PATCH for-4.14] docs: Minor build improvements Date: Tue, 9 Jun 2020 12:10:42 +0100 Message-ID: <007a01d63e4e$9e85d330$db917990$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJEU+WnBi/4ky7HWNu3kNbmli1y/gFex+JAp+j/FHA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Konrad Rzeszutek Wilk' , 'George Dunlap' , 'Xen-devel' , 'Ian Jackson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of Jan Beulich > Sent: 09 June 2020 11:42 > To: Andrew Cooper > Cc: Stefano Stabellini ; Julien Grall ; Wei Liu ; > Konrad Rzeszutek Wilk ; George Dunlap ; Ian > Jackson ; Xen-devel > Subject: Re: [PATCH for-4.14] docs: Minor build improvements > > On 08.06.2020 19:15, Andrew Cooper wrote: > > Don't use "set -x" for the figs rule. It doesn't take effect in the recursive > > make environment. > > I'd rather view this as an unintended debugging leftover. > > > Turn the HTML manpage comments into makefile comments, not shell comments. > > This saves 3x shell invocations per manpage. > > > > Signed-off-by: Andrew Cooper > > Acked-by: Jan Beulich Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:10:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:10:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic9Y-0003Sx-8L; Tue, 09 Jun 2020 11:10:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic9X-0003SF-1d for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:10:47 +0000 X-Inumbo-ID: de26ac94-aa41-11ea-b30b-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id de26ac94-aa41-11ea-b30b-12813bfff9fa; Tue, 09 Jun 2020 11:10:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591701046; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TysuOc5GXylf1UUaen/G81fkeOnuEfcp2+jvnmZ+bCw=; b=GaEw5OKblin3Wfa203BH+/tlsxjxq/fqyNohbanzKGVp1hrWOCvG5Lfp30KG+rIPuKwC9R wkCzWoR/zk9nTeAbRNakJ3xgpwEqtai9jxFkaC4DljG79wI4wySR9HpwT5+wMlxumwm7Xp jpeaXaXcdJ9lPJhRt6Ujse0i2f00/As= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-151-CeCzEunOOqqNq2mTzVpXkQ-1; Tue, 09 Jun 2020 07:10:43 -0400 X-MC-Unique: CeCzEunOOqqNq2mTzVpXkQ-1 Received: by mail-wm1-f69.google.com with SMTP id p24so608557wmc.1 for ; Tue, 09 Jun 2020 04:10:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TysuOc5GXylf1UUaen/G81fkeOnuEfcp2+jvnmZ+bCw=; b=LFi3p2ytY3rxNMkSJOD4XqQTSIdOpdoIKS3baFZdoL+HF2zz8lIrV9gSFSE+5ovqqV lUejEZlYQ/2eKahcue031pwCY067k/xIel9f8CtSzARoxafxuKRmGsHYiaU901Zwiux8 Ye0hmRvbVupy7SsC9lzKAdk1QWTxAUtKcHFFvgpIGe6CVdBHi8HWPj5Pc5V2qQXAQxBl 5AZncOI0xaZXqbpTZ86LRYz32350Ve3XgAr0v4bsKAn7SIiBq2GYt3hooPrKRgOANqsV oN7gVW07PeVVDiYnJm7EonRIqO60/l8Z+bm/rB75uFLUB2/hwBquOsGgWXd0s5wOGuEf p9EA== X-Gm-Message-State: AOAM531MovhQ/viLbilx3Jqs914394ieQlA3KtyOHSvG+gwo1BgmrpTo x/Q02QSdfblhh99gX+ALwDps8/Bi+1wobxiM8du7dwVi523Uohn35RHK2gUCKjyyyFdDWZiy4Mj vHQjaCOrS2cn48OWVFoaeUGIqss4= X-Received: by 2002:a7b:cb91:: with SMTP id m17mr3627182wmi.126.1591701042664; Tue, 09 Jun 2020 04:10:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzYXhhkklLh5/jP4wI4AWv8kJypOFv0T2ku7XSwlUIkFk2HE1PSObyt3ACvqwUvh1wPJYEGWA== X-Received: by 2002:a7b:cb91:: with SMTP id m17mr3627155wmi.126.1591701042347; Tue, 09 Jun 2020 04:10:42 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id q1sm2521908wmc.15.2020.06.09.04.10.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:10:41 -0700 (PDT) Subject: Re: [RFC PATCH 20/35] hw/intc/i8259: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-21-philmd@redhat.com> From: Paolo Bonzini Message-ID: <71b5e461-88f6-eab2-f46a-e8aa4783debd@redhat.com> Date: Tue, 9 Jun 2020 13:10:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-21-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/intc/i8259.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/intc/i8259.c b/hw/intc/i8259.c > index 51b27f6a34..9d9609cdab 100644 > --- a/hw/intc/i8259.c > +++ b/hw/intc/i8259.c > @@ -30,6 +30,7 @@ > #include "qemu/log.h" > #include "hw/isa/i8259_internal.h" > #include "trace.h" > +#include "hw/qdev-deprecated.h" > > /* debug PIC */ > //#define DEBUG_PIC > @@ -414,6 +415,8 @@ qemu_irq *i8259_init(ISABus *bus, qemu_irq parent_irq) > ISADevice *isadev; > int i; > > + qdev_warn_deprecated_function_used(); > + > irq_set = g_new0(qemu_irq, ISA_NUM_IRQS); > > isadev = i8259_init_chip(TYPE_I8259, bus, true); > This one is okay too. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:11:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:11:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic9v-0003aY-IK; Tue, 09 Jun 2020 11:11:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jic9u-0003aD-Bz for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:11:10 +0000 X-Inumbo-ID: eba243f6-aa41-11ea-bb8b-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id eba243f6-aa41-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 11:11:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591701069; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gC6WEmr69REgLn2lsRvv9NiGoR/bD5T6HVmJ4ITPF7o=; b=MKUqEEYxr+tXS/WnVImsNVkESZCN52rzgnGVVqCOo47TU9mBwPU7xgPtfJqSU2yicTt/c0 kqm3UXwsk6R1nlldv+2Yuc8xZHoR2WQvCO8yBXP2Xfa60juhVkINNCJTJM+V+9qUIcS1bM ejboYQ2UZdp6GUZ9WV8DPfS1HSPgFR8= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-215-6MuKb7McOoqNWT9cb6qmdQ-1; Tue, 09 Jun 2020 07:11:07 -0400 X-MC-Unique: 6MuKb7McOoqNWT9cb6qmdQ-1 Received: by mail-wr1-f72.google.com with SMTP id h6so8531339wrx.4 for ; Tue, 09 Jun 2020 04:11:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gC6WEmr69REgLn2lsRvv9NiGoR/bD5T6HVmJ4ITPF7o=; b=pS+EKW5D/HmT4rMBx+JPap0FbXZ+BcNkIqjnie/B9RMx2PzBDgdKA27T+bAy2CIGcI 32PNwHlSZQQQj+bZjEDj5eleXlQMu75FUwxym500jjiVvqAcgmNM82NWBlv/FKTbR77h qiGZaTzJ4OwcOaikU3reeDebJWwNsjHIn5ntjqaskCjFrvAD5hSjj/f6V8J4F8r4MR12 jtDVlERx8ylXI15cllHXLfn12kxFy+lAAZZR7Xe1ZgXObbv9hkSb7rHUTuDAp6ikx6ct vOi2/hYYnGWZcAZdkjPfkqYrzZsKvjPAuRj5wkJtq52xPwjTq0g8RJGV2ylsLgepoQ5M tvkg== X-Gm-Message-State: AOAM533bTs7/gDaugS7o3idVJ599Zgj9TLk6zb9RmVROdMgm7OTDPlRf lvPuA3VwI1YjDO/xE6dC2vrJu/5TXk/e2HIkE6qalw2Vm9DvLu53HF0N23nZ4K+h5a0BfYQKe3Z /L91+WI+T9kpDxrl2bLt+19GOb6A= X-Received: by 2002:a5d:628c:: with SMTP id k12mr3812471wru.211.1591701066333; Tue, 09 Jun 2020 04:11:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyY3Up1ym4TzRU1NS9l49R/XWUODvDMW5M2cEwgU3BofYT4BEs0ckiayOWBTvyLMfPr7vv94w== X-Received: by 2002:a5d:628c:: with SMTP id k12mr3812427wru.211.1591701066086; Tue, 09 Jun 2020 04:11:06 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id r12sm3176227wrc.22.2020.06.09.04.11.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:11:05 -0700 (PDT) Subject: Re: [RFC PATCH 21/35] hw/lm32/lm32_hwsetup: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-22-philmd@redhat.com> From: Paolo Bonzini Message-ID: <3e036ca7-753b-55fb-3a19-7d50f5b6fd19@redhat.com> Date: Tue, 9 Jun 2020 13:11:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-22-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/lm32/lm32_hwsetup.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/lm32/lm32_hwsetup.h b/hw/lm32/lm32_hwsetup.h > index de94de177a..f4a4d8fe4b 100644 > --- a/hw/lm32/lm32_hwsetup.h > +++ b/hw/lm32/lm32_hwsetup.h > @@ -27,6 +27,7 @@ > > #include "qemu/cutils.h" > #include "hw/loader.h" > +#include "hw/qdev-deprecated.h" > > typedef struct { > void *data; > @@ -57,6 +58,8 @@ static inline HWSetup *hwsetup_init(void) > { > HWSetup *hw; > > + qdev_warn_deprecated_function_used(); > + > hw = g_malloc(sizeof(HWSetup)); > hw->data = g_malloc0(TARGET_PAGE_SIZE); > hw->ptr = hw->data; > This one is okay. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:12:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:12:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicB4-0003pF-TK; Tue, 09 Jun 2020 11:12:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicB3-0003p7-Hu for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:12:21 +0000 X-Inumbo-ID: 1692cdba-aa42-11ea-bca7-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 1692cdba-aa42-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 11:12:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591701141; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l4X2TCEtUozOLaXo/L8sScbontTQvUPvWMYmEeL8dy0=; b=ae0TnIQG62Gq7LjIYeArcLFlWzm75OBJp88b7BHEWevKk7EGRO1LbTnWnl+SH8hPSJVX8H YkEeMhYn9NEdSJHZdXFatlIRERQOwPUqApONZXJLR+2oiA/f4Vs5iHPxYCwOsvJ2Jf1jMs n3JloEgmlmeCiwf6MER7AXTQUjehbOs= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-482-Tc3IAPUlPgqnLlGtU6hkGA-1; Tue, 09 Jun 2020 07:12:19 -0400 X-MC-Unique: Tc3IAPUlPgqnLlGtU6hkGA-1 Received: by mail-wm1-f70.google.com with SMTP id a7so532523wmf.1 for ; Tue, 09 Jun 2020 04:12:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=l4X2TCEtUozOLaXo/L8sScbontTQvUPvWMYmEeL8dy0=; b=P1RRfwKlrp5QRNfFszMsFydq4dSnUZYdyoouZZr0bzr3p1caNK1dtwUeSCv7dwKNRJ vRC7bVEsH5ezXtFvTvYGEZiZnEYIK4LXHVGpacQrv+Y61myyLETlxGe327W4GZgbasGT N5zI+ISQ2kFNTgMTU+96OKgxn2TF1nQf2ItNaaHQJQxtbQfoqUiHkTrBQU0E7ZXN0CYE GvnHt+ATS/EcKeDYXREp9V8ABMxTlzI9q1eEcJd4sswgaZLVfMuKbi+DdOk8upLalDbe Uk3uAhf0oQSiqwKOfW0xnahlbgBwBGRvTmukVst132YwPAE+pU5Ci6G47zR/RnsXBq0V E+2g== X-Gm-Message-State: AOAM532OfAfvqHfRL2qHtbRVGAbIrLemrekc+pO/8vKbbmpjZAjUqAyk vF3f2SgAZu9zfYP1A+qxFOYDRLa8QM03WGoYKFSt/uyNXY15K0RJdO8ILlMBJM17+OV598O37Cl dKzJ6/YIyhqzKJY/iCoGiERkjF+s= X-Received: by 2002:a05:600c:4102:: with SMTP id j2mr3433716wmi.48.1591701138459; Tue, 09 Jun 2020 04:12:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy0awk5HkX0L04n6QbPdprXKsckBJOO0WwKyuM0S0l/M/wQqyP9e9ViVkr5nd7Ja+7n12153w== X-Received: by 2002:a05:600c:4102:: with SMTP id j2mr3433671wmi.48.1591701138230; Tue, 09 Jun 2020 04:12:18 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id o18sm2614689wme.19.2020.06.09.04.12.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:12:17 -0700 (PDT) Subject: Re: [RFC PATCH 30/35] hw/ppc/virtex_ml507: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-31-philmd@redhat.com> From: Paolo Bonzini Message-ID: <85d75dcd-f08c-0506-46ee-97e2b5869e0b@redhat.com> Date: Tue, 9 Jun 2020 13:12:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-31-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/ppc/virtex_ml507.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/hw/ppc/virtex_ml507.c b/hw/ppc/virtex_ml507.c > index 0dacfcd236..17b8036c38 100644 > --- a/hw/ppc/virtex_ml507.c > +++ b/hw/ppc/virtex_ml507.c > @@ -40,7 +40,7 @@ > #include "qemu/log.h" > #include "qemu/option.h" > #include "exec/address-spaces.h" > - > +#include "hw/qdev-deprecated.h" > #include "hw/ppc/ppc.h" > #include "hw/ppc/ppc4xx.h" > #include "hw/qdev-properties.h" > @@ -95,6 +95,8 @@ static PowerPCCPU *ppc440_init_xilinx(const char *cpu_type, uint32_t sysclk) > CPUPPCState *env; > qemu_irq *irqs; > > + qdev_warn_deprecated_function_used(); > + > cpu = POWERPC_CPU(cpu_create(cpu_type)); > env = &cpu->env; > > This one is okay. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:12:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:12:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicBJ-0003rt-8t; Tue, 09 Jun 2020 11:12:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicBI-0003rl-E5 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:12:36 +0000 X-Inumbo-ID: 1f6a1be6-aa42-11ea-bb8b-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 1f6a1be6-aa42-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 11:12:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591701155; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6lAgcTDN/dV/f7SK/NrjUs5/i9Qjg44Eo04qPw3cNtk=; b=ZX4ibfDnvSzi4fjxCeQlgN3ekJMGzJzBstjLOJgCpe0BF+qU7vGA5dh9RhIVKHVPPbpEWN 9nD8eW1RXx4O0oTeqLeO1UrYOVLaVL5bmxV7xDm9ZFT8qghdvr10cxire9hJNwGaFed7mo 6FbTUg1Cq4SE7fOcUiZ0eFURHLJHndE= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-108-ztb1v3rkMAa-kLAdiJ1xKw-1; Tue, 09 Jun 2020 07:12:32 -0400 X-MC-Unique: ztb1v3rkMAa-kLAdiJ1xKw-1 Received: by mail-wr1-f71.google.com with SMTP id l18so8531488wrm.0 for ; Tue, 09 Jun 2020 04:12:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6lAgcTDN/dV/f7SK/NrjUs5/i9Qjg44Eo04qPw3cNtk=; b=fGEw/pDz+d6nXmzCFjsHaNdv+Ed3p5EMwdmBYAWgSfPuE4fI0WAqt4h9tufdLCd7uo qxkcGZRm+r+o4N1+A5xjCDZEzhlJr9bIAZ7QLZk+rkxOqQDs1BeRzYjC3cuP9f3UXnBX DcTGuoXg+2+k0hGrb93dXv78Ip24UobjQl8kGdcc+dPi/iZ9/qaP/Em/TyYi65RDEqfq I9v7Ywt19A4thxa/wO2CtmU6yDnvc9Ve0UlbcXPCkMhUWn708H8NPYM9sohDYpjMfe3p fP3zof80+sdiDshkxO0rf4CMH8apOV/TafGzkGOLX/0bpocBnIGlbgzIKmNc0gl7zjnC M6yA== X-Gm-Message-State: AOAM533eujPEOlT6luWExuqTmBSek/7Dg8WPsgw8lfAwgTBcY98HmfWe NUb35zFyCAwIng4F1MAlwpHJVUBUJLZ+3u9ITawz4Lu97YGgXUId158TR5D/vIViaFfS0xRojhc XgsK/Iu6bSXKHmKRFJmTPcce2SiU= X-Received: by 2002:a1c:a7c3:: with SMTP id q186mr3257031wme.141.1591701150721; Tue, 09 Jun 2020 04:12:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwew58hVelVmOrF+efwHZuIRFPhx2tAfnSXNsxzJkV6M1Bdv9a4oEF967FsVILY6ztkPcXqaQ== X-Received: by 2002:a1c:a7c3:: with SMTP id q186mr3256994wme.141.1591701150493; Tue, 09 Jun 2020 04:12:30 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id u130sm2587221wmg.32.2020.06.09.04.12.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:12:29 -0700 (PDT) Subject: Re: [RFC PATCH 29/35] hw/ppc/ppc_booke: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-30-philmd@redhat.com> From: Paolo Bonzini Message-ID: Date: Tue, 9 Jun 2020 13:12:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-30-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/ppc/ppc_booke.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/hw/ppc/ppc_booke.c b/hw/ppc/ppc_booke.c > index 652a21b806..a9e5e68578 100644 > --- a/hw/ppc/ppc_booke.c > +++ b/hw/ppc/ppc_booke.c > @@ -31,7 +31,7 @@ > #include "qemu/log.h" > #include "hw/loader.h" > #include "kvm_ppc.h" > - > +#include "hw/qdev-deprecated.h" > > /* Timer Control Register */ > > @@ -338,6 +338,8 @@ void ppc_booke_timers_init(PowerPCCPU *cpu, uint32_t freq, uint32_t flags) > booke_timer_t *booke_timer; > int ret = 0; > > + qdev_warn_deprecated_function_used(); > + > tb_env = g_malloc0(sizeof(ppc_tb_t)); > booke_timer = g_malloc0(sizeof(booke_timer_t)); > > This one is okay. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:13:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:13:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicBf-0003wP-Hl; Tue, 09 Jun 2020 11:12:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicBe-0003wF-QD for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:12:58 +0000 X-Inumbo-ID: 2cc26ee2-aa42-11ea-b30b-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 2cc26ee2-aa42-11ea-b30b-12813bfff9fa; Tue, 09 Jun 2020 11:12:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591701178; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dy54HX3yjH25i0N8iq/ISO1rX+f/prrBggOwYYHoeGM=; b=PHJe75H4dCzz4x3hKaQ7xz17pPv4BxaTaDKpik7d/80S93P8SU7+97Rbz+nYte2uiZco60 fJYMLk5ArwB6oyIcybV1sJ3YNCFUEIUu2yPP3iIdgJ3h+aSLM3H5SFvAAbDj2xdIChJGHS 4z9wLbyEDx+N/TWYESDb0woMcbQTuC0= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-23-JEOFzc9ZMvKlqEs4UYo5-Q-1; Tue, 09 Jun 2020 07:12:52 -0400 X-MC-Unique: JEOFzc9ZMvKlqEs4UYo5-Q-1 Received: by mail-wm1-f69.google.com with SMTP id c4so610307wmd.0 for ; Tue, 09 Jun 2020 04:12:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dy54HX3yjH25i0N8iq/ISO1rX+f/prrBggOwYYHoeGM=; b=WUZ093wZlTDkEgY4UfZn4IvAWe+jt/ARe3qK06FAMGhN9XLZRqb/kruglu7BSgoa0I IZB4JYGFYJeqTyFvHRKebILbgLc4AL2+sYJq+FnqX6nDCGoj0wdJ5UgtiiW0FUvFP+Z+ OrY015seZK+uNJTyK3RKPtw5KdK6pK1qWsHLLmXKcBZjqASXCAZ6h5APIByu0vlvSxha kh5FQ1TOs/cFbkTgZONRbrgKb259dglUZVXjXbT5mzPHyuBK8GqpgaGylxxBVtQ6kpw2 Jf1nJUNwOrGetud6OkKuCDcnmneBRxfat0UCDS9F33Xy9jA+6KRyHZlumzlUoZb5MKy0 Hp7w== X-Gm-Message-State: AOAM531wCZJ2mZT+YvfLo8o8wtfzMH6CGE70h5HYBy6ragHGFOI7FrxF SquP9LF6jNu/+A+i3yMkRcNOlWmTfC7Ta5LO5W+gnHhpdJG3aLn9Dqa+BiGXMQGfef2/EwAWX/P z68vKYRDyhCMg8XjZH1Vd7A9GfSQ= X-Received: by 2002:a5d:6944:: with SMTP id r4mr3767000wrw.169.1591701170930; Tue, 09 Jun 2020 04:12:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy1H01HZsnF0pwx9oeoL9yjnBGXgYxEXfgTncokwamlfkzpTt0NHDCpjwEqldpHwJp0uf5vaQ== X-Received: by 2002:a5d:6944:: with SMTP id r4mr3766967wrw.169.1591701170664; Tue, 09 Jun 2020 04:12:50 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id u130sm2588369wmg.32.2020.06.09.04.12.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:12:50 -0700 (PDT) Subject: Re: [RFC PATCH 27/35] hw/ppc/ppc: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-28-philmd@redhat.com> From: Paolo Bonzini Message-ID: <135e04f9-a2f4-b4d4-6689-83ae1f36d81c@redhat.com> Date: Tue, 9 Jun 2020 13:12:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-28-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/ppc/ppc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c > index 4a11fb1640..39fcf746c5 100644 > --- a/hw/ppc/ppc.c > +++ b/hw/ppc/ppc.c > @@ -37,6 +37,7 @@ > #include "kvm_ppc.h" > #include "migration/vmstate.h" > #include "trace.h" > +#include "hw/qdev-deprecated.h" > > //#define PPC_DEBUG_IRQ > //#define PPC_DEBUG_TB > @@ -1114,6 +1115,8 @@ clk_setup_cb cpu_ppc_tb_init (CPUPPCState *env, uint32_t freq) > PowerPCCPU *cpu = env_archcpu(env); > ppc_tb_t *tb_env; > > + qdev_warn_deprecated_function_used(); > + > tb_env = g_malloc0(sizeof(ppc_tb_t)); > env->tb_env = tb_env; > tb_env->flags = PPC_DECR_UNDERFLOW_TRIGGERED; > This one is okay. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:14:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:14:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicCd-00049l-Sn; Tue, 09 Jun 2020 11:13:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicCc-00049J-M5 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:13:58 +0000 X-Inumbo-ID: 50657326-aa42-11ea-b30b-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 50657326-aa42-11ea-b30b-12813bfff9fa; Tue, 09 Jun 2020 11:13:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591701238; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O3lzSLGxJ8WgRzoyp9NolnrgEUC6tjBqCyG0KDbIHi0=; b=Rg2sDSqNz6mSUZRA+rtHXrL0X8hkZG8/Yib8T5MElWpJrvDYFLsgJmBy9lW2UeYM51StFY UkcWSQS/PloyuYYy/Xpjjf5hprG+cxGSoyrT/2VOiHzaJ/R70EN8uIjbVsKR845DSwfMV9 5lYphO8PLBcT7vqcyC+3RT0K3+anc6o= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-166-zMugz2zhMSWNRX53jY4VjQ-1; Tue, 09 Jun 2020 07:13:56 -0400 X-MC-Unique: zMugz2zhMSWNRX53jY4VjQ-1 Received: by mail-wm1-f72.google.com with SMTP id k185so524767wme.8 for ; Tue, 09 Jun 2020 04:13:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=O3lzSLGxJ8WgRzoyp9NolnrgEUC6tjBqCyG0KDbIHi0=; b=kvpDfD/AiTP2ng+c7/YTvJgeSqlZgwmkYecGHOHnFRkPmWlXGDUs6yuFt+lvyh9yy+ Wl9/2jjIdrS70mut3haJxnbQCevCxbukhH9TLgHWhskfaKe6OKN9LtHk0pRv4fIqoPwN hFmQ0DeyAi8TVyWliCNGK6QUEhwl/HfECAyKYChV218GHjFDP/9qM/NoDyJzqWRbMjDg h3efb6vkzqAji+eAEjSPEFrosEIiiwFru2vyVPRVPK9ofgdHkb0LtZYoWmWB8mm8lq2g H0Bj86u8v5CWNxVrOzUH8GYTMkcg2Y3E0ehPhM8XE6zxmStLB4Dr2JfABuM3UgSXS/Ei wqig== X-Gm-Message-State: AOAM530CyIgYOwhwW4J7QHEcX1p6EhrJdMoHbl8BpPTSVdD7RcGn3/we UVPuGc0IHUz763GuLjENzgdfQvGLkmpcOyWqET4d41NJl8FrU8M11nLDSwzhnYxYZ18wZf5AGEo wq2Cmun8mkmcuWRDkOvV+AejnTOs= X-Received: by 2002:adf:f582:: with SMTP id f2mr4186320wro.204.1591701235064; Tue, 09 Jun 2020 04:13:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy7CEeV1+7lXiLRFYok5rBbukk8N3FMNoofh40xzDiHh3/3TzmlrCYg3pn55HLPW4csjHJ2JQ== X-Received: by 2002:adf:f582:: with SMTP id f2mr4186295wro.204.1591701234805; Tue, 09 Jun 2020 04:13:54 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id 50sm3179768wra.1.2020.06.09.04.13.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:13:54 -0700 (PDT) Subject: Re: [RFC PATCH 26/35] hw/openrisc/cputimer: Emit warning when old code is used To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200608160044.15531-1-philmd@redhat.com> <20200608160044.15531-27-philmd@redhat.com> From: Paolo Bonzini Message-ID: <4cdb0948-56b8-6d72-2030-ea00186c47bc@redhat.com> Date: Tue, 9 Jun 2020 13:13:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200608160044.15531-27-philmd@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm@nongnu.org, xen-devel@lists.xenproject.org, qemu-riscv@nongnu.org, Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc@nongnu.org, Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:00, Philippe Mathieu-Daudé wrote: > This code hasn't been QOM'ified yet. Warn the user. > > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/openrisc/cputimer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/openrisc/cputimer.c b/hw/openrisc/cputimer.c > index 93268815d8..60f2c9667f 100644 > --- a/hw/openrisc/cputimer.c > +++ b/hw/openrisc/cputimer.c > @@ -22,6 +22,7 @@ > #include "cpu.h" > #include "migration/vmstate.h" > #include "qemu/timer.h" > +#include "hw/qdev-deprecated.h" > > #define TIMER_PERIOD 50 /* 50 ns period for 20 MHz timer */ > > @@ -135,6 +136,8 @@ static const VMStateDescription vmstate_or1k_timer = { > > void cpu_openrisc_clock_init(OpenRISCCPU *cpu) > { > + qdev_warn_deprecated_function_used(); > + > cpu->env.timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, &openrisc_timer_cb, cpu); > cpu->env.ttmr = 0x00000000; > > I was about to give this a pass, but if we did so it should be the CPU itself that calls cpu_openrisc_clock_init (not openrisc_sim_init). Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:15:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:15:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicEQ-0004Id-8m; Tue, 09 Jun 2020 11:15:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicEP-0004IW-B1 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:15:49 +0000 X-Inumbo-ID: 92214dfa-aa42-11ea-b30b-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 92214dfa-aa42-11ea-b30b-12813bfff9fa; Tue, 09 Jun 2020 11:15:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591701348; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pM1sXV/7eH//dmNxCu9L646uRo7LpSiWcH+A4/9rq/Y=; b=JJB858Ex+ar4t6OYqUOG8dIuN/ryP69vCitFuSaHmsc/c+VA2x6Dz7JTGS3yb5lnkQMX71 ueeHq4bVDa0ZUNu8n4wV6aLFy+iH3zATFVd6ln+FA9/jPEqq6PIfCgcsO3pxBcotBBttIW vLWMvlPI4VSoymLsrpgaOpmSfRWsX3M= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-12-pYM4QUlQM9O0vSyXGqVRwQ-1; Tue, 09 Jun 2020 07:15:47 -0400 X-MC-Unique: pYM4QUlQM9O0vSyXGqVRwQ-1 Received: by mail-wr1-f70.google.com with SMTP id p9so8495810wrx.10 for ; Tue, 09 Jun 2020 04:15:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pM1sXV/7eH//dmNxCu9L646uRo7LpSiWcH+A4/9rq/Y=; b=r/TWXHcdSqutNO8HYJz+vYviZ6K5cT1tvYnYxBOr7md52fVaxps0DstvUEYa5VVm28 4xkIXmJNdA4Ir0HC/fbuFBuedQg+ixXZ3ivl0CVT/B/2wdwW90iY/DLCLWKsY/nB5nZ0 JCEE1YXBQ7yndK2WjA7RvRbEEg4FtTHqVxl86bxgk7Z97YvwbBh7EO4UMWfe+DAzN8lg NqaJ94Y9DjzHmTC5L7Upyfpd6ULxCojHzxK91CKexqd33VWIrck5+QLekjFxKe+4NWGc sb4PGHB1kSaWfuH3pirKL9aTi3S5NdY2ivmNq47q0pDD0aUx6lrBuBHH5e+krTdzIGBV GBMQ== X-Gm-Message-State: AOAM53121SrqlJLJSPvU3OBu+tS7zvDDgqGlDMMnafR4lXajkvKcFPyV 5fRedNAtk0ruunEDH4/jQuR/VrrjBUjJsaOQpP/jtO6ZvFxY/ylJ7tE1HaeBTYgk1W5BCTWWMcP SOgoi3mA7xLyiIgdFzboO/GE7XeA= X-Received: by 2002:a5d:4e87:: with SMTP id e7mr3651924wru.427.1591701286135; Tue, 09 Jun 2020 04:14:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzuPbVlBDSLtlTXx3ZWJ2E6euzR9/JzXQUGOR/hYo9mA/3HQUZQnicNKOucsXO2NrypVrU/9w== X-Received: by 2002:a5d:4e87:: with SMTP id e7mr3651896wru.427.1591701285907; Tue, 09 Jun 2020 04:14:45 -0700 (PDT) Received: from [192.168.178.58] ([151.21.172.168]) by smtp.gmail.com with ESMTPSA id f9sm3121051wrf.74.2020.06.09.04.14.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 04:14:45 -0700 (PDT) Subject: Re: [RFC PATCH 00/35] hw/qdev: Warn when using pre-qdev/QOM devices To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Peter Maydell References: <20200608160044.15531-1-philmd@redhat.com> <81653f82-484b-a04a-7b2c-1362a724d0e8@redhat.com> From: Paolo Bonzini Message-ID: Date: Tue, 9 Jun 2020 13:14:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <81653f82-484b-a04a-7b2c-1362a724d0e8@redhat.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Sagar Karandikar , "Michael S. Tsirkin" , Mark Cave-Ayland , QEMU Developers , Max Filippov , Alistair Francis , Gerd Hoffmann , "Edgar E. Iglesias" , Stefano Stabellini , Paul Durrant , Magnus Damm , Markus Armbruster , Marcel Apfelbaum , Anthony Perard , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , David Gibson , Andrzej Zaborowski , Eduardo Habkost , Alistair Francis , qemu-arm , "open list:X86" , "open list:RISC-V" , Stafford Horne , Palmer Dabbelt , Richard Henderson , "Daniel P . Berrange" , Thomas Huth , Bastian Koppelmann , Michael Walle , qemu-ppc , Aurelien Jarno Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08/06/20 18:17, Philippe Mathieu-Daudé wrote: > On 6/8/20 6:14 PM, Peter Maydell wrote: >> On Mon, 8 Jun 2020 at 17:00, Philippe Mathieu-Daudé wrote: >>> >>> Based on today's IRC chat, this is a trivial RFC series >>> to anotate pre-qdev/QOM devices so developers using them >>> without knowing they are not QOM'ified yet can realize >>> it and convert them if they have time. >> >> What mechanism did you use for identifying non-QOM devices? > > I don't think this is the complete list, this is only all the one I > could find with: > > $ git grep "g_new|g_malloc" hw/ > > Then on each match I manually reviewed (so I might have incorrectly > flagged code too). Yes, you did, but I guess for an RFC it was a good bang for the buck. I went through the patch and noticed both a few false positives and a couple blatant violations in recent code. Paolo From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:22:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:22:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicKx-0005CK-1a; Tue, 09 Jun 2020 11:22:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicKv-0005Bu-DQ for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:22:33 +0000 X-Inumbo-ID: 7fbee3fe-aa43-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7fbee3fe-aa43-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 11:22:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=V5ZhW7+bte0y7uuzhMDJ4QymV22Bst8n+dodwxtl8fk=; b=XDyxdt/9UZrFBQ75no/5d9h8S m0JQPGkw/3og8M4t6dX5ea9/TcfMrK2dWdcJSCUxunWBRL+UU0MAhONvcfbOhEpWulZUXP42XRvXT vWzLNsdD0PRmmoZO25dEId6yhySysOObPpKuwxpZ96p8V+IegVALHHJRjDB64VpIlY7G0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicKo-000502-OD; Tue, 09 Jun 2020 11:22:26 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jicKo-0004cg-DT; Tue, 09 Jun 2020 11:22:26 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jicKo-00043Y-Cy; Tue, 09 Jun 2020 11:22:26 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 150932: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=2f82fe467f7a67d11500a566054b403e9d6d0a9c X-Osstest-Versions-That: libvirt=a1cd25b919509be2645dbe6f952d5263e0d4e4e5 From: osstest service owner Date: Tue, 09 Jun 2020 11:22:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150932 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/150932/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 146182 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 146182 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 2f82fe467f7a67d11500a566054b403e9d6d0a9c baseline version: libvirt a1cd25b919509be2645dbe6f952d5263e0d4e4e5 Last test of basis 146182 2020-01-17 06:00:23 Z 144 days Failing since 146211 2020-01-18 04:18:52 Z 143 days 134 attempts Testing same since 150932 2020-06-09 04:20:38 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Arnaud Patard Artur Puzio Bjoern Walk Boris Fiuczynski Chen Hanxiao Chris Jester-Young Christian Borntraeger Christian Ehrhardt Christian Schoenebeck Collin Walling Cornelia Huck Daniel Henrique Barboza Daniel P. Berrangé Daniel Veillard Dario Faggioli Erik Skultety Fedora Weblate Translation Gaurav Agrawal Han Han Ian Jackson Jaak Ristioja Jamie Strandboge Jim Fehlig Jiri Denemark Jonathon Jongsma Julio Faracco Ján Tomko Laine Stump Leonid Bloch Liao Pingfang Lin Ma Marc-André Lureau Marek Marczykowski-Górecki Mark Asselstine Mauro S. M. Rodrigues Michal Privoznik Nikolay Shirokovskiy Paolo Bonzini Pavel Hrdina Pavel Mores Peter Krempa Philipp Hahn Pino Toscano Prathamesh Chavan Rafael Fonseca Richard W.M. Jones Rikard Falkeborn Ryan Moeller Sahid Orentino Ferdjaoui Sebastian Mitterle Seeteena Thoufeek Stefan Berger Stefan Berger Stefan Hajnoczi Thomas Huth Tobin Feldman-Fitzthum Tomáš Golembiovský Weblate Wu Qingliang Xu Yandong Yan Wang Yi Li Your Name Yuri Chornoivan Zhang Bo zhenwei pi Zhenyu Zheng Zhimin Feng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git a1cd25b919..2f82fe467f 2f82fe467f7a67d11500a566054b403e9d6d0a9c -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:29:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:29:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicRu-0005Uv-Vu; Tue, 09 Jun 2020 11:29:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicRt-0005UR-HQ for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:29:45 +0000 X-Inumbo-ID: 814f3254-aa44-11ea-b30e-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 814f3254-aa44-11ea-b30e-12813bfff9fa; Tue, 09 Jun 2020 11:29:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HPqLLjE8XMoM4zusJM9774uLnLFPvCnw9hYmCxWWvdU=; b=soD3VkevoW8DLGwC97kzc6AfMv 8KQdLcLKGi1pwG3lQTkBBalS/HVDfUlyt16a34O95a11K/KbvtXAyJKXSPMdYRzWRti8Gev9/iZWE U5Gr/J9LsnGalN7ClFmKoEhRB3Jx0CUOBtzx54wugEN04IlzoMyz2AKKMHNfiTGj2z0Q=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicRm-000587-7d; Tue, 09 Jun 2020 11:29:38 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jicRm-0006k7-0k; Tue, 09 Jun 2020 11:29:38 +0000 Subject: Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table To: Anil Madhavapeddy , Andrew Cooper References: <20200609094425.GB9734@nodbug.lucina.net> <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> From: Julien Grall Message-ID: <314dd258-14de-2d70-eec4-8cbc0a62e75a@xen.org> Date: Tue, 9 Jun 2020 12:29:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Martin Lucina , mirageos-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 09/06/2020 11:50, Anil Madhavapeddy wrote: > On 9 Jun 2020, at 11:22, Andrew Cooper > wrote: >> >> On 09/06/2020 10:44, Martin Lucina wrote: >>> Hi, >>> >>> I've been making progress on bootstrapping a new, PVHv2 only, Xen >>> platform >>> stack for MirageOS [1]. The basics are now functional and I have >>> started to >>> re-implement the grant table code. >>> >>> After studying both the Mini-OS and Linux implementations some, I don't >>> understand the difference between using XENMAPSPACE_grant_table vs. >>> GNTTABOP_setup_table to set up the initial grant table mapping for the >>> guest. >>> >>> Are these calls just newer and older ways of accomplishing the same >>> thing? >>> The Linux driver seems to use both in various conditions, whereas Mini-OS >>> uses the former on ARM and the latter on x86. >>> >>> If these are functionally equivalent, then for my purposes I'd rather use >>> XENMAPSPACE_setup_table, since IIUC this lets me map the grant table >>> at an >>> address of my choosing rather than GNTTABOP_setup_table which at least on >>> x86_64 appears to be returning PFNs at the top of the address space. >>> >>> Any advice much appreciated, >> >> There is a little bit of history here... >> >> GNTTABOP_setup_table was the original PV way of doing things (specify >> size as an input, get a list of frames as an output to map), and >> XENMAPSPACE_grant_table was the original HVM way of doing things (as >> mapping is the other way around - I specify a GFN which I'd like to turn >> into a grant table mapping). >> >> When grant v2 came along, it was only XENMAPSPACE_grant_table updated to >> be compatible. i.e. you have to use XENMAPSPACE_grant_table to map the >> status frames even if you used GNTTABOP_setup_table previously. >> >> It is a mistake that GNTTABOP_setup_table was usable in HVM guests to >> being with. Returning -1 is necessary to avoid an information leak (the >> physical address of the frames making up the grant table) which an HVM >> guest shouldn't, and has no use knowing. >> >> An with that note, ARM is extra special because the grant API is >> specified to use host physical addresses rather than guest physical (at >> least for dom0, for reasons of there generally not being an IOMMU), >> which is why it does use the old PV way. > > Thanks, that makes sense. It doesn't seem too much of a mess from the guest > perspective to use just XENMAPSPACE_grant_table exclusively then. With > Martin's work, the MirageOS Xen backend should just use the latest and > greatest > APIs, with no backwards compatibility to older Xen versions required. > > I'm still a little confused about ARM though -- is there an equivalent of > XENMAPSPACE_grant_table there? It sounds like we can't leave the > GNTTABOP macros behind entirely... XENMAPSPACE_grant_table exists and works perfectly fine on Arm. It is using guest physical address as it should. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:33:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:33:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicVb-0006K0-FZ; Tue, 09 Jun 2020 11:33:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicVa-0006Ju-8o for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:33:34 +0000 X-Inumbo-ID: 0cb2043e-aa45-11ea-bb8b-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0cb2043e-aa45-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 11:33:33 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jicVY-00079I-Kg; Tue, 09 Jun 2020 12:33:32 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions Date: Tue, 9 Jun 2020 12:33:22 +0100 Message-Id: <20200609113323.32731-1-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Ian Jackson , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Different pandoc versions generate, and expect, a different toplevel structure for their json output and inpout. Newer pandoc's toplevel is a hash. We are going to want to support this. We can tell what kind of output we should produce by looking at the input we got (which itself came from pandoc). So: * Make space for code to read toplevel objects which are not arrays. Currently this code is absent and we just die explicitly (rather than dying because we tried to use a hashref as an array ref). * Move generation of the toplevel json structure out of pandoc2html_inline, and abstract it away through a subref which is set up when we read the input file. This is just prep work. No functional change other than a change to an error message. Signed-off-by: Ian Jackson --- docs/parse-support-md | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/docs/parse-support-md b/docs/parse-support-md index 84f0a96a0f..b9978bfb4d 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -232,6 +232,8 @@ sub r_content ($) { } } +our $pandoc_toplevel_constructor; + sub r_toplevel ($) { my ($i) = @_; @@ -241,9 +243,21 @@ sub r_toplevel ($) { $had_unknown = undef; $had_feature = undef; - foreach my $e (@$i) { - next unless ref $e eq 'ARRAY'; - r_content $e; + my $blocks; + if (ref $i eq 'ARRAY') { + $pandoc_toplevel_constructor = sub { + my ($blocks) = @_; + return [ + { unMeta => { } }, + $blocks, + ]; + }; + foreach my $e (@$i) { + next unless ref $e eq 'ARRAY'; + r_content $e; + } + } else { + die; } } @@ -274,10 +288,10 @@ sub pandoc2html_inline ($) { my ($content) = @_; my $json_fh = IO::File::new_tmpfile or die $!; - my $j = to_json([ - { unMeta => { } }, - [{ t => 'Para', c => $content }], - ]) or die $!; + + my $blocks = [{ t => 'Para', c => $content }]; + my $data = $pandoc_toplevel_constructor->($blocks); + my $j = to_json($data) or die $!; print $json_fh $j; flush $json_fh or die $!; seek $json_fh,0,0 or die $!; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:33:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:33:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicVg-0006Kc-NS; Tue, 09 Jun 2020 11:33:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicVf-0006Ju-7V for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:33:39 +0000 X-Inumbo-ID: 0dacc248-aa45-11ea-8496-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0dacc248-aa45-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 11:33:35 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jicVa-00079I-CU; Tue, 09 Jun 2020 12:33:34 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [XEN PATCH for-4.14 2/2] docs-parse-support-md: Cope with buster's pandoc Date: Tue, 9 Jun 2020 12:33:23 +0100 Message-Id: <20200609113323.32731-2-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200609113323.32731-1-ian.jackson@eu.citrix.com> References: <20200609113323.32731-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Ian Jackson , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Provide the implementation for newer pandoc json. I have done an adhoc test and this now works on both buster and stretch and seems to produce the expected support matrix when run using the example rune (which processes unstable and 4.11). Signed-off-by: Ian Jackson --- docs/parse-support-md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/parse-support-md b/docs/parse-support-md index b9978bfb4d..a397637639 100755 --- a/docs/parse-support-md +++ b/docs/parse-support-md @@ -243,6 +243,15 @@ sub r_toplevel ($) { $had_unknown = undef; $had_feature = undef; + # Pandoc's JSON output changed some time between 1.17.2 (stretch) + # and 2.2.1 (buster). I can find no documentation about this + # change or about the compatibility rules. (It seems that + # processing the parse tree *is* supported upstream: they offer + # many libraries to do this inside the pandoc process.) + # Empirically, what has changed is just the top level structure. + # Also pandoc wants the same structure back that it spat out, + # when we ask it to format snippets. + my $blocks; if (ref $i eq 'ARRAY') { $pandoc_toplevel_constructor = sub { @@ -256,6 +265,17 @@ sub r_toplevel ($) { next unless ref $e eq 'ARRAY'; r_content $e; } + } elsif (ref $i eq 'HASH') { + my $api_version = $i->{'pandoc-api-version'}; + $pandoc_toplevel_constructor = sub { + my ($blocks) = @_; + return { + blocks => $blocks, + meta => { }, + 'pandoc-api-version' => $api_version, + }; + }; + r_content $i->{blocks}; } else { die; } -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:34:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:34:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicWX-0006SK-Vk; Tue, 09 Jun 2020 11:34:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicWW-0006S1-2a for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:34:32 +0000 X-Inumbo-ID: 2f0fb436-aa45-11ea-b30e-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2f0fb436-aa45-11ea-b30e-12813bfff9fa; Tue, 09 Jun 2020 11:34:31 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: uU8fzKDEmRGwFRaowHYIdxPN7Ludf2nBcFJnyNRERHhzkQMPLyb9JUzNdGu1qhFr8cxQjuud4b YuNgUeWg7+diyJPMZCfS9ke33t6yJM3IO4L4RWvyw+1ZZEQc94poDT/94Pru/0MbxVKTv4J0f7 +ehR3t7EDMfh0hpkeSrX0DdonelYEeH9GGuMMh1DF5dR5fSJYk1G6X/VGiVhyGW+Ppfsgdve5t caCHoqT4kOzo0sZaquI2asc0zY4SEGakZ++q0+pzxnYAa6BlMQtPfvZUDD4mX09+MCJD1bAnhK apU= X-SBRS: 2.7 X-MesageID: 19861618 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,491,1583211600"; d="scan'208";a="19861618" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24287.29623.551154.322547@mariner.uk.xensource.com> Date: Tue, 9 Jun 2020 12:34:15 +0100 To: "xen-devel@lists.xenproject.org" , "Andrew Cooper" , Paul Durrant Subject: Re: [XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions In-Reply-To: <20200609113323.32731-1-ian.jackson@eu.citrix.com> References: <20200609113323.32731-1-ian.jackson@eu.citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Ian Jackson writes ("[XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions"): > Different pandoc versions generate, and expect, a different toplevel > structure for their json output and inpout. Newer pandoc's toplevel > is a hash. We are going to want to support this. We can tell what > kind of output we should produce by looking at the input we got (which > itself came from pandoc). So: Having just sent this I see the typo `copying' in the title... I have fixed that in my tree. Ian. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 11:45:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 11:45:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicgj-0007TE-Ve; Tue, 09 Jun 2020 11:45:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jicgj-0007T9-DH for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 11:45:05 +0000 X-Inumbo-ID: a8757ab2-aa46-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x42d.google.com (unknown [2a00:1450:4864:20::42d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a8757ab2-aa46-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 11:45:04 +0000 (UTC) Received: by mail-wr1-x42d.google.com with SMTP id j10so20934189wrw.8 for ; Tue, 09 Jun 2020 04:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=t0l++NQysrwgMC8g2kOgfNjJNkMP5TFOkmTk0rF8x1c=; b=exsB9kfWCCWPysLpCyX/uz24o96gkcZzlimsCrlf1fkJ4pO0QwF7obUx+UetvmlSbb HW4J/DvORuWmTY+05vwtrGY6heKd65smuh3Cwf22eUUJbHvm8p/V6NeQGUsXTm+Du2O+ fnMrnEJdGtIwyS/G6a95xoVzlf/YobOZG3vTUSm6mnWpiI1U0BIk/duG2CxFClWRZAEw TDdcY8L0YOWVfPu4ke3AUtIhj5BFrCSx/hN1E2gsZjoLMwPQVkKa4hlNcnFNxzG0Bddc odjt/v7s6yb1DsRLsnL4FeyjrlvwzvX0NArJllTq3uCoJj/5mKnUQVNO2twzLFWebRIO HU/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=t0l++NQysrwgMC8g2kOgfNjJNkMP5TFOkmTk0rF8x1c=; b=el8xOwYArMICJFiz2gry1UKcvdMisa5P5+al0tWdQTRBiZXYdsYA5Zlpx1++GQjjy3 JI8g57QehMJiTcKKIDwr8e70ObsiksyBNkcpeJ7gKkgvONlQ5KRGz4lFxR8/MAyWEBI5 JtP1zg7TY4pukFP/QWzV1gAUqESa/9bQnNYlHJaHbUe7ZmzfSoygR44MqTefYU0+tpEB CryLwszAlNTai6yUrQK9i/pv+TB3jzVpCV4twdKKti1Lo0r9nZddwzWMtC2bhdnHUttL 0FjBOkoeFaPYQyS7E1ZoJcJac9AjfOTci0ej2trJRicL+rS4r7DwgqTsMJEoPCwrQhva ItWQ== X-Gm-Message-State: AOAM530YODdeLrrvXq4/hHHKlJgo0UYDCGQPuX6qA8Y9P49Exq2wheJH IFm6by2i5W/Rr0yW5mKb9D4= X-Google-Smtp-Source: ABdhPJyVsUivLxzZquvC4LvnEk7IcSJrRNjVfVaFIoe1eYfScekSa/VdZgNEawYOoCjXaTgpBMjVjw== X-Received: by 2002:adf:e90b:: with SMTP id f11mr3943346wrm.248.1591703103573; Tue, 09 Jun 2020 04:45:03 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id s132sm2807729wmf.12.2020.06.09.04.45.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 04:45:02 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , , "'Andrew Cooper'" , "'Paul Durrant'" References: <20200609113323.32731-1-ian.jackson@eu.citrix.com> <24287.29623.551154.322547@mariner.uk.xensource.com> In-Reply-To: <24287.29623.551154.322547@mariner.uk.xensource.com> Subject: RE: [XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions Date: Tue, 9 Jun 2020 12:45:01 +0100 Message-ID: <007f01d63e53$69983a00$3cc8ae00$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFPMD46xN1NN75ENWA5oEEghpKwNAG13mqLqdCXQNA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 09 June 2020 12:34 > To: xen-devel@lists.xenproject.org; Andrew Cooper ; Paul Durrant > > Subject: Re: [XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc versions > > Ian Jackson writes ("[XEN PATCH for-4.14 1/2] docs-parse-support-md: Prepare for copying with pandoc > versions"): > > Different pandoc versions generate, and expect, a different toplevel > > structure for their json output and inpout. Newer pandoc's toplevel > > is a hash. We are going to want to support this. We can tell what > > kind of output we should produce by looking at the input we got (which > > itself came from pandoc). So: > > Having just sent this I see the typo `copying' in the title... > I have fixed that in my tree. > With the typo fixed... Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Tue Jun 09 12:06:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 12:06:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jid1D-00011M-6t; Tue, 09 Jun 2020 12:06:15 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jid1B-00011H-9w for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 12:06:13 +0000 X-Inumbo-ID: 9979c043-aa49-11ea-b314-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9979c043-aa49-11ea-b314-12813bfff9fa; Tue, 09 Jun 2020 12:06:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uGDCH4ibAOaHLpT9vIFDI4jH+KUgqA+j6v79uOlZbT4=; b=5JdwLHTBawE7/auqzwZmNH7Jj i5lUfxhGVNjqQtq9vQ/G4aQzSnKmzADgVsmGBtSLjWN+Ioh0DzP+VIKwQSTdCvar900+ZLvraNsr0 hjKpilQ37rihL3FrKTXPvjfikhg0adT4E2B9lSv5qKaNiR/5ye2wx+OLE0lgHOWRlbH5s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jid16-0005v3-8j; Tue, 09 Jun 2020 12:06:08 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jid16-0007Lw-08; Tue, 09 Jun 2020 12:06:08 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jid15-0004Tu-Vq; Tue, 09 Jun 2020 12:06:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150931: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=abfbb29297c27e3f101f348dc9e467b0fe70f919 X-Osstest-Versions-That: linux=9aa900c8094dba7a60dc805ecec1e9f720744ba1 From: osstest service owner Date: Tue, 09 Jun 2020 12:06:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150931 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150931/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150910 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150910 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150910 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150910 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150910 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150910 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150910 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150910 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150910 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150910 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: linux abfbb29297c27e3f101f348dc9e467b0fe70f919 baseline version: linux 9aa900c8094dba7a60dc805ecec1e9f720744ba1 Last test of basis 150910 2020-06-07 20:10:01 Z 1 days Failing since 150920 2020-06-08 03:35:33 Z 1 days 3 attempts Testing same since 150931 2020-06-09 00:40:27 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: "Yan, Zheng" Ahmed Abdelsalam Ahmed S. Darwish Aishwarya Ramakrishnan Al Viro Alex Deucher Alex Deucher Alex Elder Alexander Fomichev Alexander Lobakin Alexander Schmidt Alexandra Winter Alexandre Belloni Allen Hubbe Alok Prasad Amelie Delaunay Amir Goldstein Amit Sahrawat Andre Przywara Andreas Gruenbacher Andrew Morton Andy Shevchenko Anson Huang Antoine Tenart Anupam Aggarwal Arindam Nath Arnaud Pouliquen Arnd Bergmann Baolin Wang Bas Nieuwenhuizen Ben Skeggs Ben Skeggs Benjamin Gaignard Bjorn Andersson Bjorn Helgaas Bob Peterson Brian Cain Bruno Thomsen Catalin Marinas Chen Zhou Chris Lew Chris Wilson Christian Borntraeger Christoph Hellwig Christophe JAILLET Chuhong Yuan Clement Leger Cong Wang Corentin Labbe Cornelia Huck Dafna Hirschfeld Dan Carpenter Dan Murphy Daniel Drake Dave Airlie Dave Jiang David Hildenbrand David S. Miller Dejin Zheng Denis Efremov Ding Xiang Eric Farman Evan Green Evan Quan Farhan Ali Florian Fainelli Fritz Koenig Fugang Duan Geert Uytterhoeven Geert Uytterhoeven Gerald Schaefer Giuseppe Scrivano Grace Kao Greg Kroah-Hartman Greg Ungerer Guenter Roeck Guilherme G. Piccoli Gustavo A. R. Silva Harald Freudenberger Harry Wentland Hauke Mehrtens Heiner Kallweit Herbert Xu Hongbo Yao Ido Schimmel Igor Russkikh Ilya Dryomov Jacob Pan Jacopo Mondi Jakub Kicinski Jani Nikula Jared Rossi Jason J. Herne Jason Yan Jean-Philippe Brucker Jeff Layton Jerry Snitselaar Jesper Dangaard Brouer Jessica Yu Jiasen Lin Jiri Benc Joerg Roedel Johan Jonker John Hubbard John Johansen Jon Derrick Jon Hunter Jon Maloy Jon Mason Jonathan Bakker Jonathan Marek Joonas Lahtinen Jordan Crouse Jules Irenge Julian Wiedmann Kalyan Thota kbuild test robot Kees Cook Kevin P. Fleming Konrad Dybcio Konstantin Khlebnikov Krishna Manikandan Krzysztof Kozlowski Lad Prabhakar Lars Povlsen Light Hsieh Linus Torvalds Linus Walleij Liu Yi L Liu, Yi L Logan Gunthorpe Loic Pallardy Lu Baolu Luis Chamberlain Luis Henriques Maciej Grochowski Manfred Spraul Marek Szyprowski Mark Salter Markus Elfring Martin Blumenstingl Masahiro Yamada Mateusz Nosek Mathieu Poirier Mauricio Faria de Oliveira Mauro Carvalho Chehab Max Filippov Maxime Ripard Maxime Ripard Michael S. Tsirkin Michal Hocko Michal Vokáč Mika Westerberg Mike Rapoport Nathan Chancellor Nicholas Kazlauskas Niklas Schnelle Nirmoy Das Orson Zhai Palmer Dabbelt Pankaj Gupta Paolo Abeni Paul Cercueil Pavel Machek (CIP) Pavel Machek Petr Mladek Petr Tesarik Pierre Morel Qian Cai Qiushi Wu Rafael Aquini Ran Wang Rikard Falkeborn Rishabh Bhatnagar Rob Clark Rob Clark Rob Herring Robert Jarzmik Roberto Sassu Robin Murphy Roelof Berg Rohit Maheshwari Roy Spliet Sai Prakash Ranjan Sai Praneeth Prakhya Sameeh Jubran Samuel Zou Sanjay R Mehta Sean Wang SeongJae Park Shawn Guo Sibi Sankar Siddharth Gupta Sivaprakash Murugesan Souptick Joarder Stefano Garzarella Suman Anna Sven Schnelle Tero Kristo Tero Kristo via iommu Thierry Reding Tiezhu Yang Tom Murphy Tuong Lien Vadim Pasternak Valentin Longchamp Vasily Gorbik Vasyl Gomonovych Venkata Narendra Kumar Gutta Ville Syrjälä Vinay Kumar Yadav Vineeth Vijayan Vivek Trivedi Vladimir Zapolskiy Vlastimil Babka Wang Hai WANG Wenhu Wei Liu Wei Yongjun Wesley Sheng Will Deacon Wolfram Sang Xiubo Li Yan, Zheng Yangtao Li Yong Wu yu kuai YueHaibing Zhangfei Gao Zhenyu Wang Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 9aa900c8094d..abfbb29297c2 abfbb29297c27e3f101f348dc9e467b0fe70f919 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Tue Jun 09 12:15:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 12:15:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jidAX-0001wG-6I; Tue, 09 Jun 2020 12:15:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jidAW-0001wB-TH for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 12:15:52 +0000 X-Inumbo-ID: f5dec7e6-aa4a-11ea-bb8b-bc764e2007e4 Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f5dec7e6-aa4a-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 12:15:52 +0000 (UTC) Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1jidAT-000Mji-8w; Tue, 09 Jun 2020 12:15:49 +0000 Date: Tue, 9 Jun 2020 13:15:49 +0100 From: Tim Deegan To: paul@xen.org Subject: Re: [PATCH v1] kdd: remove zero-length arrays Message-ID: <20200609121549.GA90841@deinos.phlegethon.org> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <005001d63e3b$c85059f0$58f10dd0$@xen.org> User-Agent: Mutt/1.11.1 (2018-12-01) X-SA-Known-Good: Yes X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tim@xen.org X-SA-Exim-Scanned: No (on deinos.phlegethon.org); SAEximRunCond expanded to false X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Olaf Hering' , 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, At 09:55 +0100 on 09 Jun (1591696552), Paul Durrant wrote: > > -----Original Message----- > > From: Xen-devel On Behalf Of Olaf Hering > > Sent: 08 June 2020 21:39 > > To: xen-devel@lists.xenproject.org > > Cc: Ian Jackson ; Olaf Hering ; Tim Deegan ; > > Wei Liu > > Subject: [PATCH v1] kdd: remove zero-length arrays > > > > Struct 'kdd_hdr' already has a member named 'payload[]' to easily > > refer to the data after the header. Remove the payload member from > > 'kdd_pkt' and always use 'kdd_hdr' to fix the following compile error: > > Is it not sufficient to just change the declaration of payload in kdd_pkt from [0] to []? In fact I can't see any use of the payload > field in kdd_hdr so it looks like that is the one that ought to be dropped. Yes, if one of these has to go, it should be the one in the header, since it's not used and the one in the packet is neatly in the union with the other decriptions of the packet payload. I'm not currently in a position to test patches, but might be later in the week. Olaf, can you try dropping the 'payload' field from the header and replacing the payload[0] in pkt with payload[] ? Cheers, Tim. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 12:33:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 12:33:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jidRW-0003gT-Qu; Tue, 09 Jun 2020 12:33:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jidRV-0003gO-Sj for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 12:33:25 +0000 X-Inumbo-ID: 6977fb30-aa4d-11ea-8496-bc764e2007e4 Received: from mail-lj1-x241.google.com (unknown [2a00:1450:4864:20::241]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6977fb30-aa4d-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 12:33:25 +0000 (UTC) Received: by mail-lj1-x241.google.com with SMTP id i27so13860923ljb.12 for ; Tue, 09 Jun 2020 05:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=U8Eb2mLb5U/+FkB5qnpVGhGGBV1jxFTMfBhLagA3qt4=; b=FQcHlHxxW4ElxyJlfW3MDGdOjSJQMW5MAnSgYAxLksRJTiN4o44cSDc3i0OGM9xE9u 0k6MvhSZq/RSEAHralDqMToAMSewtFq2/nPysTMazkjdgqJw3ajFnEnPiNze9+aHWke3 opPyap3mAis/QMs2IkYi3X3DI94I79mqBHGAp9p6uc84zbPWpCbKiSkLA0UFIUk2kfib 1eWQwuwD4ek3Pk37DeqAicrsInJhO4wqCJZVSE7IYt33lqnphZu4czCbKLjBIKqt9BbA s0ZXtkgMcdxlCwztitCOgV4EOCKvLApmGC82ztq4TDc80QtYWkIhotxQZWYUyaWdV8I7 5GhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=U8Eb2mLb5U/+FkB5qnpVGhGGBV1jxFTMfBhLagA3qt4=; b=PJOeN+ss/4NYqyFgnOrQ8IPAiEsGZeNnL38AuG5wOmAsU0jvvVQdBj9PrN5he5LLGb YyvxdlAxfXjKMzMXxNyaTJJQzAsIEqBSanPA/Wl/azQgFRDngnXHmDC7o876rvJyR/vM IMUgTcazUBFT1Iw9BmyKP/s2rMMXHNw0wAvh80DaMVzPet/3uevdzrixOY6edDd2exyy 9laC31LEmQ+Ve2WpgFPiaq8HYeTDB8AWOjrrW8xZqyoYVmE2WVhG+B4FoYZdl5UAlinY CyO4VDm3SARH9hd3K0tCki8etgMrs6qrWYGZgm0i4bdK/vlPHYtQcEAGMnqlJF4FPkUm i05g== X-Gm-Message-State: AOAM532e7hp7YK8SnaWge9wwP7/8mwB/ybHfx0cbco9VEWLPuo8f+YrZ 2NvF5yG8fuoXTPAAOCcZtOeNqDELydtMmXzs8aNkNw== X-Google-Smtp-Source: ABdhPJwzzj6KxQ7V7tvAausIZrT3l6YmTBYOldxoNicSCnwD56SOpdxC3+ErMoiDp00xoaMWYeDj7Oi4ioeIR4b4W5Y= X-Received: by 2002:a2e:9a59:: with SMTP id k25mr578947ljj.114.1591706004138; Tue, 09 Jun 2020 05:33:24 -0700 (PDT) MIME-Version: 1.0 References: <20200608072855.26589-1-olaf@aepfle.de> <20200608100051.16be834e.olaf@aepfle.de> <24286.6790.983312.672969@mariner.uk.xensource.com> <20200608161111.26c2cdd4.olaf@aepfle.de> In-Reply-To: <20200608161111.26c2cdd4.olaf@aepfle.de> From: Jason Andryuk Date: Tue, 9 Jun 2020 08:33:12 -0400 Message-ID: Subject: Re: [PATCH v1] tools: fix usage of strncpy To: Olaf Hering Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Wei Liu , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 8, 2020 at 10:11 AM Olaf Hering wrote: > > Am Mon, 8 Jun 2020 08:43:50 -0400 > schrieb Jason Andryuk : > > > I added a length check in this patch: > > gcc will not recognize such runtime checks and will (most likely) complai= n about the strncpy usage anyway, just as it does now in libxl__prepare_soc= kaddr_un. While the usage in libxl__prepare_sockaddr_un is fatal due to -We= rror, libvchan is apparently built without -Werror. gcc complaining about strncpy after the length check is unfortunate. Do you know if gcc would complain if strcpy is used? It would be okay since we just checked the length. What version of gcc are you using? I was using 9.x and it didn't warn from what I can remember. Regards, Jason From xen-devel-bounces@lists.xenproject.org Tue Jun 09 13:00:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 13:00:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jidrs-0006Ej-1F; Tue, 09 Jun 2020 13:00:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jidrq-0006Ee-97 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 13:00:38 +0000 X-Inumbo-ID: 362cc180-aa51-11ea-b7bb-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 362cc180-aa51-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 13:00:37 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: FLHfnbZ19HU5+V4aYCNCFuh8XHpbMIyH5L+DLjdAW7PjoV8RS19U2IBMAAKShMUBg+4qCn4V4F a5MlxdWNfXkhNW7hnE2n7g6wqjRdORcpcdeObt0XlzBNSC9W94nAhroxXgEMpYmycKeSj1+L+2 ZnXsVYbx8GDlhZ81qVyYqRUoN+8Rh7UqDQ3AaqLClW5EEfUV8bpmY1sMI4hIt7pf4MU1AGk+C7 OMJeSCwudICq9jAnDct0hOUtidcMdWSdRPfk4jPTOpfiZMP/Om3IsYn2mM4M5n5xSXkusPem1R tVM= X-SBRS: 2.7 X-MesageID: 19868725 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,492,1583211600"; d="scan'208";a="19868725" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24287.34799.645497.809135@mariner.uk.xensource.com> Date: Tue, 9 Jun 2020 14:00:31 +0100 To: Olaf Hering Subject: Re: [PATCH v2] libxl__prepare_sockaddr_un In-Reply-To: <20200608182539.29415-1-olaf@aepfle.de> References: <20200608182539.29415-1-olaf@aepfle.de> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , "xen-devel@lists.xenproject.org" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Olaf Hering writes ("[PATCH v2] libxl__prepare_sockaddr_un"): > libxl: remove usage of strncpy from libxl__prepare_sockaddr_un > > The runtime check for the length of path already prevents malfunction. > But gcc does not detect this runtime check and reports incorrect > usage of strncpy. Remove the usage of strncpy and work directly with > the calculated path length. > > In file included from /usr/include/string.h:495, > from libxl_internal.h:38, > from libxl_utils.c:20: > In function 'strncpy', > inlined from 'libxl__prepare_sockaddr_un' at libxl_utils.c:1262:5: > /usr/include/bits/string_fortified.h:106:10: error: '__builtin_strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] > 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > cc1: all warnings being treated as errors Thanks for working on this. I found this code a bit confusing: > - if (sizeof(un->sun_path) <= strlen(path)) { > + size_t len = strlen(path); > + > + if (sizeof(un->sun_path) <= len) { > LOG(ERROR, "UNIX socket path '%s' is too long for %s", path, what); > - LOG(DEBUG, "Path must be less than %zu bytes", sizeof(un->sun_path)); > + LOG(DEBUG, "Path of len %zu must be less than %zu bytes", len, sizeof(un->sun_path)); > return ERROR_INVAL; > } > memset(un, 0, sizeof(struct sockaddr_un)); > un->sun_family = AF_UNIX; > - strncpy(un->sun_path, path, sizeof(un->sun_path)); > + memcpy(un->sun_path, path, len); This does not copy the trailing nul. The reader must read up to see the call to memset. Why do you not use strcpy here ? Nevertheless, as this is a minor point of style, Reviewed-by: Ian Jackson Ian. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 13:02:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 13:02:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jidte-0006Jk-EP; Tue, 09 Jun 2020 13:02:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jidte-0006JM-80 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 13:02:30 +0000 X-Inumbo-ID: 7850d934-aa51-11ea-b31d-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7850d934-aa51-11ea-b31d-12813bfff9fa; Tue, 09 Jun 2020 13:02:28 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: QMnnjO82Sgz+YGGsqW1/Z9FNwjoMnnb9o8mOC1EawNIvUt1mHmJkfSqrO05GwrBz6P+Ly9rlZj eNgm7iKtczApjreXoDbClsqccK0MKfRm36ilkRCxlmHzlEcsG6QJ//0R4699rA2gSBcD9/7sNh ppjekLES7VLsabBNvsyHVOipUPA+8sqlaqBD2h9BmjG5Onqu/7bgB7W0a0MAGND09vWhAcVr3g 3BKP9+5D/6ZK+4VzXe+GZO0K8jn9AcgD+gfydN4nAuJobaybMtY9XC9eA9aKPqL2NVZOEdgdcY isw= X-SBRS: 2.7 X-MesageID: 19919981 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,492,1583211600"; d="scan'208";a="19919981" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24287.34907.515781.156617@mariner.uk.xensource.com> Date: Tue, 9 Jun 2020 14:02:19 +0100 To: "xen-devel@lists.xenproject.org" Subject: Re: [xen-unstable test] 150928: regressions - FAIL In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" osstest service owner writes ("[xen-unstable test] 150928: regressions - FAIL"): > flight 150928 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/150928/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-amd64-prev 6 xen-build fail REGR. vs. 150918 This seems to have been a transient network failure between the test colo and xenbits. Ian. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 13:16:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 13:16:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jie7S-0007Ov-Ot; Tue, 09 Jun 2020 13:16:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jie7Q-0007Oq-QR for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 13:16:45 +0000 X-Inumbo-ID: 75eec348-aa53-11ea-bb8b-bc764e2007e4 Received: from mo4-p00-ob.smtp.rzone.de (unknown [81.169.146.160]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 75eec348-aa53-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 13:16:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591708602; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=oPJSOALdwkaDDWPOwJBGFgVmYK2D83SYyOKMMIxz3As=; b=cfy1Je8+jqA442LLpKCTw9FbcaLBMUWITZjWBiF2i2xdPdLBoM1sYTRoXEkmqElzA6 GkRaFDN1VJ5uXwmGlM8duYu3gtE7cbzcjqlf1tQTaljtsp+QDare/WqGwyuEt1P3uh+N 2SWdQHbt3q7rmjgZ8wocBJDnNKOKEhde4dtxv+6nQrkOt8C4XYugXZdPynNiy5DJNeQ1 nq3FsU0gZ1sM4w3wHTIubc556H8yuiN0TyDglLoB4tgE4D3IAYZ1NfsiIYg1caGVKd8Z LNmBZoYs8y1sGqMGrfxoZcKF7ajrpCnnOYnnAIFwvPX7jQdg4zg36j6hKPX1yFMLPSQr H9ZQ== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w59DGcKtw (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 9 Jun 2020 15:16:38 +0200 (CEST) Date: Tue, 9 Jun 2020 15:16:36 +0200 From: Olaf Hering To: Jason Andryuk Subject: Re: [PATCH v1] tools: fix usage of strncpy Message-ID: <20200609151636.57c98545.olaf@aepfle.de> In-Reply-To: References: <20200608072855.26589-1-olaf@aepfle.de> <20200608100051.16be834e.olaf@aepfle.de> <24286.6790.983312.672969@mariner.uk.xensource.com> <20200608161111.26c2cdd4.olaf@aepfle.de> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/_kVOEFAmLuUnK68C/YJsd./"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Wei Liu , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/_kVOEFAmLuUnK68C/YJsd./ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 9 Jun 2020 08:33:12 -0400 schrieb Jason Andryuk : > What version of gcc are you using? I was using 9.x and it didn't warn fr= om what I can remember. This is gcc10 from current Tumbleweed. For libxl strcpy will certainly work= because the length check is done prior the copying of data. Olaf --Sig_/_kVOEFAmLuUnK68C/YJsd./ Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7fi7QACgkQ86SN7mm1 DoB+ZQ//atBDH2NRPMw0r7kqih1NGwaP/84F/nTlaSlyOQycM6krw/m62f7NnaTh i1HD58081UWXxH3MgkzVc1Cvr/ByJGIGyiSvZwemnaEr21OeIIODxspJvdx7N6e0 /6U26GCRnqNuff87TzCcWLyr1tlpyXjPiGLPyAxzYTgfkMfzkV3MVhcECWWvw4nt I9IyXkz7S8788/I33tnxaoZzii0P+NHNhZPNzQU/11TXkHiUShzKSVrWfsqriTI9 6uWfV7k7aHHpoLwnN2MOR0SPV1uzWM8RJdTVemOJMttHC4OMMe4VQ/pOzyrflB2j 3u+pJ3x08/4r3ePIUEhS0zP0QUh7RTxuqJ5VYLhvpw9W1vCPq0PpHmRkcsknn5rN lOGRA4WnaH8poWjUooKYf3S+MDPmt7w81ScweRLe5iM0+bViGGhQRUaOVt8rYeWQ wulZZ7qsUQaN8TWmSCOPHNybX9e+qq2afQeUeHB0pXichyKLxZeYD/Yn6G8Y9eJ6 TmCsKUvAzkEXl/eEVa4OXg8xerN7l7vaQabsIrifUhRj2+luQa9kBGmI2Qn+ZXKA jS/pP3HwI/h73POsp3ycz/qOfI3mLv85oo38SXccLnqDNLr7tAJnU3PJw5dSi7Op FJZuTNJCbl+0QNXEYon/+cDtA1WtNWK2j0VQ6X2UwjdHguEZLeo= =lGly -----END PGP SIGNATURE----- --Sig_/_kVOEFAmLuUnK68C/YJsd./-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 13:18:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 13:18:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jie9A-0007WK-3q; Tue, 09 Jun 2020 13:18:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jie98-0007WB-PZ for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 13:18:30 +0000 X-Inumbo-ID: b45af7f0-aa53-11ea-b31f-12813bfff9fa Received: from mo4-p01-ob.smtp.rzone.de (unknown [85.215.255.53]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b45af7f0-aa53-11ea-b31f-12813bfff9fa; Tue, 09 Jun 2020 13:18:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591708707; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=eJHGV41BtyQAam0J+s+OBHJIJPEiips8Xw6SXLrX+m8=; b=Jy39DC25024pGAf5JKSoOptlS29yd6F0vKvEdZv0n0ADeet1IE5RJs0tv3YEwpZbCl P9PHJMbLGsXPcS6aMqSvUa7PR/UNkbkTAxGYyPmWZOfUnZFGUQRmzBkwNRcK9Aq+2SW8 zZYa69FhzYqtpY9u960l5uAgBSsFgMzoeDu5snx0DXKIXLsq1tyvBUiif05m0/mJkWGa JMqYO4LtGj0B79a0oAoMIx8ncMo+UYTLCXUaW2TqyQEKfdlgsQbYfaQAMonxL6icdSfZ jsI3ZIZ6+2q6lTJQmwttuPcE/g1l4zHAKar2Tey3804PEhpJ4VUtgA0Kl0mCJmmCzS7H f4Xg== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w59DIPKuM (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 9 Jun 2020 15:18:25 +0200 (CEST) Date: Tue, 9 Jun 2020 15:18:23 +0200 From: Olaf Hering To: Ian Jackson Subject: Re: [PATCH v2] libxl__prepare_sockaddr_un Message-ID: <20200609151823.509cf395.olaf@aepfle.de> In-Reply-To: <24287.34799.645497.809135@mariner.uk.xensource.com> References: <20200608182539.29415-1-olaf@aepfle.de> <24287.34799.645497.809135@mariner.uk.xensource.com> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/VRTLKantihJdDl/E83V_LxT"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , "xen-devel@lists.xenproject.org" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/VRTLKantihJdDl/E83V_LxT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 9 Jun 2020 14:00:31 +0100 schrieb Ian Jackson : > Why do you not use strcpy here ? Either variant of 'cpy' will work in this context. I decided to use memcpy = for no specific reason. Olaf --Sig_/VRTLKantihJdDl/E83V_LxT Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7fjB8ACgkQ86SN7mm1 DoBlrRAAgTAjXaiah0MWz+1pV4TK+CAEvd5YM3sEnQagOnQnbO/QCuNn+irVUbjX E5TFUWWKt1DPoyQrfrTGOpaKn2XrvjnBkrNQmprBcEVzg4LancCPiGcy1xZeS6Xy weDRKuEdauZifb4lNqQFj4zHYzH4ibPdkBamfANQKahQ+PVHlbgpqfUIp8oEt8kd fHWl3MY4S/hzM4t3xl73fto8T7gBTTk6Bv5lhMgti4NbLDJS3Egkvgbvd5dzy5BT Hr21aZILHVpqnWCNjBb21Nzu464hgv/pi9phWqeN+zDgiQ5sxIacCtU2hWSnFyGT GntcVfwi5yJLC7ftOHPRLy6TroEKpDylrQzSkcK1LOvumOTjJy6rOxVLIrC9SwRw VYa1Hl27k3VFseTEGNDaefJybu9yVnuDy5y1vJfX8m1B8dtpWmrJe7pzxSApat2G 4aTmdSRkwPheJMVS8/xOPXTr2H6zAY0hrdg6RmgZknBy7Ke7gwl0GuuF5CgEMtpH YfPa5514seRUXan51aWgeg3OmDBhl3xyv3U96/kNR7/rB02XL1r05iegNIFkWfzE HnYJqsItO2wuVOTnTZcHoNJqU6757yfMAVsbkH8CWsbn34y7gTe37agn9fEzlFET zDLmCf1yjebZzbtN2fIaRqSCqUvTkcsg5R7DrZUzU3w3RiF8XwY= =4WIx -----END PGP SIGNATURE----- --Sig_/VRTLKantihJdDl/E83V_LxT-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 13:22:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 13:22:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jieDD-0008KI-Kc; Tue, 09 Jun 2020 13:22:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jieD9-0008KD-Jt for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 13:22:42 +0000 X-Inumbo-ID: 49abebe8-aa54-11ea-b31f-12813bfff9fa Received: from mo4-p01-ob.smtp.rzone.de (unknown [81.169.146.165]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 49abebe8-aa54-11ea-b31f-12813bfff9fa; Tue, 09 Jun 2020 13:22:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591708957; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=TJ+n7JQJ9orNHoKmwICi073w1Uz7eo0ncOIFOz2e6GM=; b=sGAgKhYg2tY004+3X36fJ/2Bntpp93Yu6Vh7hK/SVQeau/OfT/vYo93k84gsoijinD FycRzloM9GDm/ecmcgkQlb64Hgq7zgGXf4cyTt6xNkXK29RFDTtHNiHj/D3BrZWArkCm LUtlo0R/5eceYE7ApUo2iEPM3uLUUt26O/tW1jIOWh9PSrZ86NLo2Xwdct/zH4E5Zrij g5D52jBcT7uXpAJWciMVNU6hT0kfYTTC2VkJwfsFmEHoo4TEhd9COTndI4lMQCdHYFIR GczzjW+BBbMdhdiVMN+1VziyV5XaZubWTixfJ5Os4ISPbuEorR9MqYIfQvZLUydn6vAy 01uA== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w59DMXKvW (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 9 Jun 2020 15:22:33 +0200 (CEST) Date: Tue, 9 Jun 2020 15:22:33 +0200 From: Olaf Hering To: Tim Deegan Subject: Re: [PATCH v1] kdd: remove zero-length arrays Message-ID: <20200609152233.039cfc86.olaf@aepfle.de> In-Reply-To: <20200609121549.GA90841@deinos.phlegethon.org> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/VuIC4TD1X18_ExiDyAMRCB3"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' , 'Wei Liu' , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/VuIC4TD1X18_ExiDyAMRCB3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 9 Jun 2020 13:15:49 +0100 schrieb Tim Deegan : > Olaf, can you try dropping the 'payload' field from the header and replac= ing the payload[0] in pkt with payload[] ? In file included from kdd.c:53: kdd.h:325:17: error: flexible array member in union 325 | uint8_t payload[]; --- orig/kdd.h 2020-06-08 17:40:05.000000000 +0000 +++ kdd.h 2020-06-09 13:20:36.724887538 +0000 @@ -68,7 +68,6 @@ uint16_t len; /* Payload length, excl. header and trailing byte */ uint32_t id; /* Echoed in responses */ uint32_t sum; /* Unsigned sum of all payload bytes */ - uint8_t payload[0]; } PACKED kdd_hdr; =20 #define KDD_PKT_CMD 0x0002 /* Debugger commands (and replies to them)= */ @@ -323,7 +322,7 @@ kdd_msg msg; kdd_reg reg; kdd_stc stc; - uint8_t payload[0]; + uint8_t payload[]; }; } PACKED kdd_pkt; =20 Olaf --Sig_/VuIC4TD1X18_ExiDyAMRCB3 Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7fjRkACgkQ86SN7mm1 DoANUg/9Er0atjG/tO+ONwROD47A34d/ennh7n/+dTflSnfRuFBSPcLEYM/+76of E473c9Vr14SumtcjXxRCOiLeMROhd00pyA6LomLYxIWypY/nrypvLp7GPHH2yABZ xR/j40ybYlLYy8IBAXCHjFAnEwhxvbTbAriwTsLIkBOsJ6Y06UMa/Ma6CQdzfXYo CIhVPoX+wgVMaUKfqie9UE1V0pCCHADSJWCt5oSXpEISkW+Sg5W/jQris+6aVHJj hQ22UFphfqwBTQEAhxwyFab8aiWQBeohGURJqBGLrq3LlFDNNBmWcw1JO0snYjL4 pwdwCy/anun1r/dQsLP//Geh9zwMDVBKZu+zU3Mw3YHLLn5T+9uZp9JIZBIlHFNr x7ScCMEo76QemkJW0Hd/FiMK2DiOaxTdoc737ql4g9phleIx7AaEeO0G1amoM1Ss ffqbQupNqlUuA6fKCkGAcvliqWQyezcOAWVYDwBPSKRouzR/KC1vKZbGvNO1ynLh aqF/wtUz3HuLtNiVpzUxg9Cg4E8KiVtKMfP3j22VzqvTpdH98aE6DSnJyCwC1mr3 F9OgmL+ItAwT7I1Hp8FXr4lWE7uRaJ+J585OhgAMs1uzQekyVynmFnTpNJTXJnrf Ryfj2AgdIX9wggo4Ca6yALK2MAoUxqHCbtAzkpQwx7RfHpkXrFk= =NWDg -----END PGP SIGNATURE----- --Sig_/VuIC4TD1X18_ExiDyAMRCB3-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 13:26:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 13:26:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jieHH-0008WE-5O; Tue, 09 Jun 2020 13:26:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jieHF-0008W9-9Q for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 13:26:53 +0000 X-Inumbo-ID: e136ae30-aa54-11ea-b31f-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e136ae30-aa54-11ea-b31f-12813bfff9fa; Tue, 09 Jun 2020 13:26:52 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: LCT9xGyJWNUMkOsK8scVAC77zhZRyjblAyL9jMY2o4zI81gawD1L3V8kTms5PFmbSoN/SsSdFv 96jyIzKnoMJEhHaPebl5vxcOgN2TDgW+jP9tIFBwmYpS35s81jnLMFWOi1oGl/NePHdD8VMjbi 40KhR7dCPaILve+pVezZpIIGckKIcTaBd2VxJB5GraGllQ0DPFv9moWmdstYmb8PwgmgTqFJCx roHV+Huc0lI9zDLT+A0nIJ0nLNrGOTtinCTPSNsexzBW0KihuOT+o8+bnRy6shJ07KJMudWBEX 5Fg= X-SBRS: 2.7 X-MesageID: 19573899 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,492,1583211600"; d="scan'208";a="19573899" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24287.36374.917457.787627@mariner.uk.xensource.com> Date: Tue, 9 Jun 2020 14:26:46 +0100 To: Olaf Hering Subject: Re: [PATCH v1] kdd: remove zero-length arrays In-Reply-To: <20200609152233.039cfc86.olaf@aepfle.de> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> <20200609152233.039cfc86.olaf@aepfle.de> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Tim Deegan , 'Ian Jackson' , 'Wei Liu' , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Olaf Hering writes ("Re: [PATCH v1] kdd: remove zero-length arrays"): > Am Tue, 9 Jun 2020 13:15:49 +0100 > schrieb Tim Deegan : > > > Olaf, can you try dropping the 'payload' field from the header and replacing the payload[0] in pkt with payload[] ? > > In file included from kdd.c:53: > kdd.h:325:17: error: flexible array member in union > 325 | uint8_t payload[]; ... > kdd_stc stc; > - uint8_t payload[0]; > + uint8_t payload[]; > }; > } PACKED kdd_pkt; Try > kdd_stc stc; > - uint8_t payload[0]; > }; + uint8_t payload[]; > } PACKED kdd_pkt; ? (I haven't read the surrounding code...) Ian. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 13:32:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 13:32:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jieMY-0000uU-Ph; Tue, 09 Jun 2020 13:32:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jieMX-0000uP-03 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 13:32:21 +0000 X-Inumbo-ID: a3ba859f-aa55-11ea-b321-12813bfff9fa Received: from mo4-p01-ob.smtp.rzone.de (unknown [81.169.146.167]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a3ba859f-aa55-11ea-b321-12813bfff9fa; Tue, 09 Jun 2020 13:32:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591709538; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=EIPVp1UjZQBZIv2MTxF6ag3w3xk7J65OYCsPIblT4P4=; b=cKJZST/SpHH64GtfeXX3JGC8IitV2OEbSJPlBCJF+4+CSsDtQGff3TRfinORaqDOUI PwOl6G1epfMeRjGKNLwDIc+X0Wio9kIbUuF08l57QWsRYPvDmX0NHQgChRFdTjk2qmfK do09JbyepYESPye1RLbpK+qXtp19rDBhyUOEBKzLLsISiRXsjoXfBBfYt/+AfD8x0Dyc a91fhffkKH3dLpfZ8Q45OnTH5rqcIfIOiXp5+mA+wzls9NJMVleVf83+oPtIRMndZQ6r bFFAXqcCwrlYdAqY2t8VbzYXzA/7P6A0cbvHapOp/Pn98Jhq0IUFfTr9Pi67Yau+lR99 cWKQ== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w59DWEKyU (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 9 Jun 2020 15:32:14 +0200 (CEST) Date: Tue, 9 Jun 2020 15:32:12 +0200 From: Olaf Hering To: Ian Jackson Subject: Re: [PATCH v1] kdd: remove zero-length arrays Message-ID: <20200609153212.3b6d7e3d.olaf@aepfle.de> In-Reply-To: <24287.36374.917457.787627@mariner.uk.xensource.com> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> <20200609152233.039cfc86.olaf@aepfle.de> <24287.36374.917457.787627@mariner.uk.xensource.com> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/T7jqiNx=3yOVd/E7gFPf/w8"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Tim Deegan , 'Ian Jackson' , 'Wei Liu' , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/T7jqiNx=3yOVd/E7gFPf/w8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 9 Jun 2020 14:26:46 +0100 schrieb Ian Jackson : > + uint8_t payload[]; This compiles, but will access memory behind the union{};, which is most li= kely not what the intention is. Olaf --Sig_/T7jqiNx=3yOVd/E7gFPf/w8 Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7fj1wACgkQ86SN7mm1 DoBMbg/+Kl51VOKYH+iub+INbzuCr55LUTKr6mZitlfHqVfaMhdSORpio3pwFLrN kD/a70taF9it2Y3C2RBOZzz58Idx3cpKfY8cff2ZdPkHztymG/U7Ax3e2zgzidjg 5gtfqF1MaOkCjmTKcAwtj3d2fdv0+wJ/jfLPXkYH50mu3hRZNayNeeOmmAELmH0L vo3OfQIxPR1o/z8528PuvcqGm+xVesyVwvpJow4zKuxAD0PJJkq+dPFj779dPXrF e99U6AYny2s25T2+LfW8Wo8c4QQj4xfLpMHfxgC7J4Rtmso+0y/zNyce1WPaJDa9 zY7M+dToEJJMEEZHl8KZEqULsqD4Mgi7aMyuts05QOcpmqQgA7v589qUJ5ie/Anm jPUCyDocI5hiWiOcz85YVqfgD1ARkSBcMXDQiGyS70zjClbQbFh/aqYWqwN0JHWL yG1cOOiWSsF7uxu77H3lVoSjIgkE+7GLF67HE7De5wI2OC3kv/hiqyXIpJy3nUnT xrNMxCFKl6JtGzLKC2owHdP27PM1FN+7Yu8ovKEBRdschknFhvr91mJFqJNUWsVN XylFm4vG3HHDAJpMF9yxBg1laxmsjt4DBm2XzMwOWtLQ9rnqEJWKgtSbnunrFpCw vrYeWkw2Jerd5C1RCIlnvRUIM2Gq8MQpV84Da8mm0effz33qLKY= =whqZ -----END PGP SIGNATURE----- --Sig_/T7jqiNx=3yOVd/E7gFPf/w8-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 13:41:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 13:41:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jieVE-0001pr-Pn; Tue, 09 Jun 2020 13:41:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jieVD-0001pm-WC for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 13:41:20 +0000 X-Inumbo-ID: e5b16c14-aa56-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e5b16c14-aa56-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 13:41:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 71235B1E7; Tue, 9 Jun 2020 13:41:21 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Andrew Cooper References: <20200608200259.17681-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <620e5f66-2802-24e7-bb6e-285e99f12975@suse.com> Date: Tue, 9 Jun 2020 15:41:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200608200259.17681-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Konrad Rzeszutek Wilk , Ross Lagerwall , Paul Durrant , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 22:02, Andrew Cooper wrote: > Do we ever write into .rodata? AFAICT, we introduce new fuctions for > references to new .rodata, rather than modifying existing .rodata. If however > we do modify .rodata, then the virtual regions need extending with information > about .rodata so we can zap those dirty bits as well. Inspired by looking at setup_virtual_regions(), do exception fixup or bug frame tables possibly get patched? > @@ -58,6 +59,10 @@ int arch_livepatch_safety_check(void) > > int arch_livepatch_quiesce(void) > { > + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ > + if ( cpu_has_xen_shstk ) > + write_cr4(read_cr4() & ~X86_CR4_CET); > + > /* Disable WP to allow changes to read-only pages. */ > write_cr0(read_cr0() & ~X86_CR0_WP); > > @@ -68,6 +73,29 @@ void arch_livepatch_revive(void) > { > /* Reinstate WP. */ > write_cr0(read_cr0() | X86_CR0_WP); > + > + /* Clobber dirty bits and reinstate CET, if applicable. */ > + if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) > + { > + unsigned long tmp; > + > + reset_virtual_region_perms(); > + > + write_cr4(read_cr4() | X86_CR4_CET); > + > + /* > + * Fix up the return address on the shadow stack, which currently > + * points at arch_livepatch_quiesce()'s caller. > + * > + * Note: this is somewhat fragile, and depends on both > + * arch_livepatch_{quiesce,revive}() being called from the same > + * function, which is currently the case. > + */ > + asm volatile ("rdsspq %[ssp];" > + "wrssq %[addr], (%[ssp]);" > + : [ssp] "=&r" (tmp) > + : [addr] "r" (__builtin_return_address(0))); > + } To be safe against LTO I think this wants accompanying with making both functions noinline. As to the fragility - how about arch_livepatch_quiesce() returning __builtin_return_address(0) to its caller, for passing into here for verification? This would also make more noticeable that the two should be be called from the same function (or else the "token" would need passing further around). > @@ -91,6 +92,18 @@ void unregister_virtual_region(struct virtual_region *r) > remove_virtual_region(r); > } > > +void reset_virtual_region_perms(void) > +{ > + const struct virtual_region *region; > + > + rcu_read_lock(&rcu_virtual_region_lock); > + list_for_each_entry_rcu( region, &virtual_region_list, list ) > + modify_xen_mappings((unsigned long)region->start, > + ROUNDUP((unsigned long)region->end, PAGE_SIZE), > + PAGE_HYPERVISOR_RX); > + rcu_read_unlock(&rcu_virtual_region_lock); > +} Doesn't this result in shattering the trailing (and currently still only) 2Mb page mapping .text in the xen.efi case? With the expectation of the approach changing in 4.15 this may not need addressing, but should imo be mentioned as a shortcoming in the description then. Also - how about "restore" instead of "reset"? Finally, while indeed not a lot of code, should it nevertheless go inside #ifdef CONFIG_LIVEPATCH? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 13:59:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 13:59:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiemQ-0002w0-Bu; Tue, 09 Jun 2020 13:59:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiemP-0002vZ-D1 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 13:59:05 +0000 X-Inumbo-ID: 5cf40690-aa59-11ea-b322-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5cf40690-aa59-11ea-b322-12813bfff9fa; Tue, 09 Jun 2020 13:58:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Fple00WsmllUlUW002L0IWhC44DQclgR4RyRS4JLyMU=; b=qZdKQKJfWkJW0p4KZpb373hFN O52ZhmgLN3oty1OHZAOo5x3H9DrGfXTfrFgn21nB3Z/XbKovVlEUhUp69yC1enAYIu8lwsVKp0m7k wOu3b5l7Lwe/4TfKzvNvmRedzA8qfAaUDEKsk1oR83U7dccrmj7gShAmrIlTZqfbFHhiA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiemH-0008C8-CB; Tue, 09 Jun 2020 13:58:57 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiemG-0003yk-Ra; Tue, 09 Jun 2020 13:58:56 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiemG-0004bg-Qy; Tue, 09 Jun 2020 13:58:56 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150935: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=f7039ee41b3d3448775a1623f230037fd0455104 X-Osstest-Versions-That: xen=835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 From: osstest service owner Date: Tue, 09 Jun 2020 13:58:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150935 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150935/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen f7039ee41b3d3448775a1623f230037fd0455104 baseline version: xen 835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 Last test of basis 150929 2020-06-08 19:02:22 Z 0 days Testing same since 150935 2020-06-09 11:02:19 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Jan Beulich Paul Durrant Tamas K Lengyel jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 835d8d69d9..f7039ee41b f7039ee41b3d3448775a1623f230037fd0455104 -> smoke From xen-devel-bounces@lists.xenproject.org Tue Jun 09 14:26:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 14:26:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifCo-0005Xv-Jb; Tue, 09 Jun 2020 14:26:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifCm-0005Xo-Na for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 14:26:20 +0000 X-Inumbo-ID: 2f4278a4-aa5d-11ea-b7bb-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2f4278a4-aa5d-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 14:26:19 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: rt+6U3WZm4rtikJxcqUk0gEVNQADr72s+8TPUpC4uPUOA/SdTsOQBTumWjWF2qTdOcRHLtJ9a+ HKmfljcPtAc/dYb20p3dX6DfDLQI6NzT9hAOsFhWfhN44mX++mN2KiSBGWhaVaVHRuiaKdJY0z yuewOiFsMymrtNQbL5c4pS0TvcZh41cazMWz49X2AdmOsNW1l4xg14tKhL2azAHwqK+Zn4qBYA 7SuKZG5JpTwWE9Okk236kuHtC1jnRAEKsiXbVJT1m49XNbOwRPASJsawmibZajjkynOB4ldMeV agQ= X-SBRS: 2.7 X-MesageID: 19600043 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,492,1583211600"; d="scan'208";a="19600043" From: George Dunlap To: Xen-devel Subject: TESTDAY Report: Unexpected results for xenhyps Thread-Topic: TESTDAY Report: Unexpected results for xenhyps Thread-Index: AQHWPmnv/u+9i0TYCEuGnSB4UmFapQ== Date: Tue, 9 Jun 2020 14:26:15 +0000 Message-ID: <062D5150-C24E-4A81-834C-9794510F0229@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Playing around with the new `xenhypfs` binary, got some unexpected results: * Unexpected error message for non-existent nodes Command executed: # xenhypfs cat /params/loglvlx could not read: Operation not permitted Expected behavior: -ENOENT-style message Actual behavior: -EACCESS-style message * Truncated output from /params/loglvl root@immortal:~# xenhypfs write /params/loglvl none root@immortal:~# xenhypfs cat /params/loglvl none/non root@immortal:~# xenhypfs write /params/loglvl error root@immortal:~# xenhypfs cat /params/loglvl error/er root@immortal:~# xenhypfs write /params/loglvl warning root@immortal:~# xenhypfs cat /params/loglvl warning/ Expected behavior: Full new string printed (`none/none`, `error/error`, `wa= rning/warning` respectively) Actual behavior: Only 8 characters ever printed * Same as above for /params/guest_loglvl Everything else looks OK. # xl info xl info host : immortal release : 5.2.0-2-amd64 version : #1 SMP Debian 5.2.9-2 (2019-08-21) machine : x86_64 nr_cpus : 8 max_cpu_id : 31 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 2 cpu_mhz : 2533.431 hw_caps : bfebfbff:029ee3ff:2c100800:00000001:00000000:00000= 000:00000000:00000100 virt_caps : pv hvm hvm_directio pv_directio hap shadow total_memory : 6141 free_memory : 5028 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 14 xen_extra : .0-rc xen_version : 4.14.0-rc xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-= 3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit2 xen_pagesize : 4096 platform_params : virt_start=3D0xffff800000000000 xen_changeset : xen_commandline : placeholder dom0_mem=3D1024M,max:1024M cpuinfo com= 1=3D115200,8n1 console=3Dcom1,tty loglvl=3Dall guest_loglvl=3Dall acpi_slee= p=3Ds3_fake debug_synthetic_preemption=3D1024 cc_compiler : gcc (Debian 9.2.1-30) 9.2.1 20200224 cc_compile_by : root cc_compile_domain : cc_compile_date : Tue Jun 9 13:32:54 UTC 2020 build_id : da97d170bfab3ccce05773f63cffdce3e3cc52ba xend_config_format : 4 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 14:33:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 14:33:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifJU-0006P4-BT; Tue, 09 Jun 2020 14:33:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifJT-0006Oz-OG for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 14:33:15 +0000 X-Inumbo-ID: 26c0d832-aa5e-11ea-8496-bc764e2007e4 Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 26c0d832-aa5e-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 14:33:14 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id g1so16546509edv.6 for ; Tue, 09 Jun 2020 07:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GhFdTY087BssM0LHrrXn5Gs8DdReJyWC1sjLIGZq3vs=; b=s1g4iZ++6YO96Ozj+KcN70U7zSSJHxijWXfmKe/JSYYvlp7slAg08YOStY9ZsVLv50 1lDKSfghsJ1ZyYzqT5hgceHVU8LDEaoOqvY70XvBW7L5vaEiC2P7A4FcpMwGaY27izAc u5AUTclqWZTM3xX5TlDmFy51riHmzGpRcpG5x05Ejys9cwIneLdhqB8++gDrrh39iulC CAm0uXd24rs1iwPYEMbrXc73udIKcz0pBRqqcR2/WhVrg27/aEUAAA2nKgfIC1s0oKN+ DLzZ1NqbHyz1C5Fn1ep+SqSSqyZDbzpB8UgrYp9bJARTzOKBAOBVBVKzc4PVufmcP6et 8VvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GhFdTY087BssM0LHrrXn5Gs8DdReJyWC1sjLIGZq3vs=; b=oOdACNKM9XlHbONL8UBoT3I8w6Zp43iHrjw4rNAmLSHdmG5rkWbeUfy5Z8gd7vh0qI hZeigyPXl4oWVVDUXU6ppGMFAiWzfebKcrB/ZigVpUySIKpfCWrIO3/443bczjdt3gTA cJADDPRqg6AIiQKLxA2bg0mqa3IjifguNdn7abW9cMrss1BhPV/KllB27zqS2Z3nme0m 8lb0E6s3c6TlY8bRu5ft+0RzcZiauNrj1xpO4cxJqZ6oTx+29G+plglFXFkWkOZes78A V4sj0ASUERUGKkEl064eb/lvSD/6LtZmQTT+QhiZPxXSWda6EN8VcJ8SBj+O0ltmo+tr jMHQ== X-Gm-Message-State: AOAM531UjK7eofJtMZnznYpd7x1ZSrRIJIOrilGw0i6Cp7fGQNN1odHs xWCujCMntsdUyYZbtxYfeDtuGFM2YhUfS/vQowWDNvGk X-Google-Smtp-Source: ABdhPJzr7xCCxok/50s3Tfchst0CvihW4+SHAkGVpYPBt5PJC4kzJCMkXGpdSLr7coNvzdl7KFgy4x5DKKPqWgMGr78= X-Received: by 2002:a50:b2e1:: with SMTP id p88mr27363767edd.198.1591713193842; Tue, 09 Jun 2020 07:33:13 -0700 (PDT) MIME-Version: 1.0 References: <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> In-Reply-To: From: CodeWiz2280 Date: Tue, 9 Jun 2020 10:33:00 -0400 Message-ID: Subject: Re: Keystone Issue To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Julien Grall , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" There does appear to be a secondary (CIC) controller that can forward events to the GIC-400 and EDMA controllers for the keystone 2 family. Admittedly, i'm not sure how it is being used with regards to the peripherals. I only see mention of the GIC-400 parent for the devices in the device tree. Maybe Bertrand has a better idea on whether any peripherals go through the CIC first? I see that gic_interrupt () fires once in Xen, which calls doIRQ to push out the virtual interrupt to the dom0 kernel. The dom0 kernel then handles the interrupt and returns, but gic_interrupt() never fires again in Xen. On Mon, Jun 8, 2020 at 12:13 PM Stefano Stabellini wrote: > > > > On Mon, 8 Jun 2020, CodeWiz2280 wrote: > > It actually shows only 1 interrupt for any of the devices in that list > > (e.g. spi, ttyS0, ethernet) so you're probably right on the money with > > it being an interrupt acknowledge issue. Any help you can provide is > > greatly appreciated. > > > > On Mon, Jun 8, 2020 at 4:40 AM Bertrand Marquis > > wrote: > > > > > > > > > > > > > On 5 Jun 2020, at 20:12, CodeWiz2280 wrote: > > > > > > > > On Fri, Jun 5, 2020 at 11:05 AM CodeWiz2280 wrote: > > > >> > > > >> On Fri, Jun 5, 2020 at 8:47 AM Bertrand Marquis > > > >> wrote: > > > >>> > > > >>> > > > >>> > > > >>>> On 5 Jun 2020, at 13:42, CodeWiz2280 wrote: > > > >>>> > > > >>>> On Fri, Jun 5, 2020 at 8:30 AM Julien Grall wrote: > > > >>>>> > > > >>>>> Hi, > > > >>>>> > > > >>>>> On 05/06/2020 13:25, CodeWiz2280 wrote: > > > >>>>>> The Keystone uses the netcp driver, which has interrupts from 40-79 > > > >>>>>> listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi). > > > >>>>>> I'm using the same device tree between my non-xen standalone kernel > > > >>>>>> and my dom0 kernel booted by xen. In the standalone (non-xen) kernel > > > >>>>>> the ethernet works fine, but I don't see any of its interrupts in the > > > >>>>>> output of /proc/iomem. I'm not seeing them in /proc/iomem when > > > >>>>>> running dom0 under Xen either. When booting with Xen I get this > > > >>>>>> behavior where the ifconfig output shows 1 RX message and 1 TX > > > >>>>>> message, and then nothing else. > > > >>>>> > > > >>>>> I am not sure whether this is a typo in the e-mail. /proc/iomem is > > > >>>>> listing the list of the MMIO regions. You want to use /proc/interrupts. > > > >>>>> > > > >>>>> Can you confirm which path you are dumping? > > > >>>> Yes, that was a typo. Sorry about that. I meant that I am dumping > > > >>>> /proc/interrupts and do not > > > >>>> see them under the non-xen kernel or xen booted dom0. > > > >>> > > > >>> Could you post both /proc/interrupts content ? > > > >> > > > >> Standalone non-xen kernel (Ethernet works) > > > >> # cat /proc/interrupts > > > >> CPU0 CPU1 CPU2 CPU3 > > > >> 17: 0 0 0 0 GICv2 29 Level > > > >> arch_timer > > > >> 18: 9856 1202 457 650 GICv2 30 Level > > > >> arch_timer > > > >> 21: 0 0 0 0 GICv2 142 Edge > > > >> timer-keystone > > > >> 22: 0 0 0 0 GICv2 52 Edge arm-pmu > > > >> 23: 0 0 0 0 GICv2 53 Edge arm-pmu > > > >> 24: 0 0 0 0 GICv2 54 Edge arm-pmu > > > >> 25: 0 0 0 0 GICv2 55 Edge arm-pmu > > > >> 26: 0 0 0 0 GICv2 36 Edge > > > >> 26202a0.keystone_irq > > > >> 27: 1435 0 0 0 GICv2 309 Edge ttyS0 > > > >> 29: 0 0 0 0 GICv2 315 Edge > > > >> 2530000.i2c > > > >> 30: 1 0 0 0 GICv2 318 Edge > > > >> 2530400.i2c > > > >> 31: 0 0 0 0 GICv2 321 Edge > > > >> 2530800.i2c > > > >> 32: 69 0 0 0 GICv2 324 Edge > > > >> 21000400.spi > > > >> 33: 0 0 0 0 GICv2 328 Edge > > > >> 21000600.spi > > > >> 34: 0 0 0 0 GICv2 332 Edge > > > >> 21000800.spi > > > >> 70: 0 0 0 0 GICv2 417 Edge > > > >> ks-pcie-error-irq > > > >> 79: 0 0 0 0 PCI-MSI 0 Edge > > > >> PCIe PME, aerdrv > > > >> 88: 57 0 0 0 GICv2 80 Level > > > >> hwqueue-528 > > > >> 89: 57 0 0 0 GICv2 81 Level > > > >> hwqueue-529 > > > >> 90: 47 0 0 0 GICv2 82 Level > > > >> hwqueue-530 > > > >> 91: 41 0 0 0 GICv2 83 Level > > > >> hwqueue-531 > > > >> IPI0: 0 0 0 0 CPU wakeup interrupts > > > >> IPI1: 0 0 0 0 Timer broadcast interrupts > > > >> IPI2: 730 988 1058 937 Rescheduling interrupts > > > >> IPI3: 2 3 4 6 Function call interrupts > > > >> IPI4: 0 0 0 0 CPU stop interrupts > > > >> IPI5: 0 0 0 0 IRQ work interrupts > > > >> IPI6: 0 0 0 0 completion interrupts > > > >> > > > >> Xen dom0 (Ethernet stops) > > > >> # cat /proc/interrupts > > > >> CPU0 > > > >> 18: 10380 GIC-0 27 Level arch_timer > > > >> 19: 0 GIC-0 142 Edge timer-keystone > > > >> 20: 88 GIC-0 16 Level events > > > >> 21: 0 xen-dyn Edge -event xenbus > > > >> 22: 0 GIC-0 36 Edge 26202a0.keystone_irq > > > >> 23: 1 GIC-0 312 Edge ttyS0 > > > >> 25: 1 GIC-0 318 Edge > > > >> 27: 1 GIC-0 324 Edge 21000400.spi > > > >> 28: 0 GIC-0 328 Edge 21000600.spi > > > >> 29: 0 GIC-0 332 Edge 21000800.spi > > > >> 65: 0 GIC-0 417 Edge ks-pcie-error-irq > > > >> 74: 0 PCI-MSI 0 Edge PCIe PME, aerdrv > > > >> 83: 1 GIC-0 80 Level hwqueue-528 > > > >> 84: 1 GIC-0 81 Level hwqueue-529 > > > >> 85: 1 GIC-0 82 Level hwqueue-530 > > > >> 86: 1 GIC-0 83 Level hwqueue-531 > > > >> 115: 87 xen-dyn Edge -virq hvc_console > > > >> IPI0: 0 CPU wakeup interrupts > > > >> IPI1: 0 Timer broadcast interrupts > > > >> IPI2: 0 Rescheduling interrupts > > > >> IPI3: 0 Function call interrupts > > > >> IPI4: 0 CPU stop interrupts > > > >> IPI5: 0 IRQ work interrupts > > > >> IPI6: 0 completion interrupts > > > >> Err: 0 > > > > After getting a chance to look at this a little more, I believe the > > > > TX/RX interrupts for the ethernets map like this: > > > > > > > > eth0 Rx - hwqueue-528 > > > > eth1 Rx - hwqueue-529 > > > > eth0 Tx - hwqueue-530 > > > > eth1 Tx - hwqueue-531 > > > >> > > > > The interrupt counts in the standlone working kernel seem to roughly > > > > correspond to the counts of Tx/Rx messages in ifconfig. Going on > > > > that, its clear that only 1 interrupt has been received for Tx and 1 > > > > for Rx in the Xen Dom0 equivalent. Any thoughts on this? > > > > > > This definitely look like an interrupt acknowledgement issue. > > > This could be caused by 2 things I remember of: > > > - front vs level interrupts > > > - a problem with forwarded interrupt acknowledgement. > > > I think there was something related to that where the vcpu ack was not properly > > > handled on a keystone and I had to change the way the interrupt was acked for > > > forwarded hardware interrupts. > > Is there maybe some sort of secondary interrupt controller (secondary in > addition to the GIC) or interrupt "concentrator" on KeyStone? > > Or is it just a small deviation from normal GIC behavior? From xen-devel-bounces@lists.xenproject.org Tue Jun 09 14:42:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 14:42:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifSH-0007I9-6s; Tue, 09 Jun 2020 14:42:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifSG-0007I4-AO for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 14:42:20 +0000 X-Inumbo-ID: 6b7fdada-aa5f-11ea-8496-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6b7fdada-aa5f-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 14:42:19 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id mb16so22676827ejb.4 for ; Tue, 09 Jun 2020 07:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ki+xtFzrVQ5beBnZloSaLFJth1P9xZ3c7hTehpR30zI=; b=aXzAnSPrw3hH829dvi2JYMl9VAwnMDzkS9G3iYxLBRo0ll+c0HdgbhotibPEIsMRDS kF3n2++F6m8NiOkBnW2pOsht9vbiLIp6twY8dZ6uUqDb45OV/O/3whCD9K+pKi8v2gwf HteJln8RP8YZi8NOcWzzem4OQeqSSqyOc65qL23he3yD9O+kcQD8aMmiNoM5kCmU8Gq2 TTOIeTZWCMuaGtfGY7x6yyH83QXMZ7bQGdJqBpRPRdT9ZQQmjAqzW6lIOTfRpv7vKFfU nw/v3XwYy+G5GVMwb/y85T6HUyPWCny3gb6K6WkIJbXsciotOitfYwMy+L/LM0AjlbfI BvhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ki+xtFzrVQ5beBnZloSaLFJth1P9xZ3c7hTehpR30zI=; b=SmXmmhFlaGatsUpdPTvPOruXIxFdjwySvgLYBGu4iAD41O5VWdMKBHizePn2bXRACf 9TFRiM+1nxqe6/jgKXwKJE0Glr+ox85V6uzKyVVbtKVWpm7j4zWs4ots2USbtMaPfLKK lz6yXLpYyLcZEPF/eOGE/SG6a7NWKWgzQ7qLEHovGN2RFGvV9oAOKPH8BDP72ZW8n76/ y9N2xhdLcjvK+X7nAqjLeZL/wMV1xDN2vkfO4bKivupJRrECmG0S/apa0FuJ8JIjlw71 g7pL0DMQwC7PXIi9vt+UB8jV3hA45SSMiHDIsXSpdZvtt+b9jADqdR4vGbGxYbtZtbLX YNyw== X-Gm-Message-State: AOAM532MSGDVSAAvfiOsllcTdqrtU5vF5u8+nheU8vMzp+qT4qSiMwS/ Y/cm39xG3FVb1EU+XtZKzb3YrGmDhvPySXVNX60= X-Google-Smtp-Source: ABdhPJzOmZo/yNpZsRiQLsQ/s2UhYQo8JdBADxgQtgGm7kiGusFc3m963OrV5Pl75e4gJ42yEy7SJmRLyjaugEDwqWI= X-Received: by 2002:a17:906:5203:: with SMTP id g3mr25058979ejm.58.1591713738725; Tue, 09 Jun 2020 07:42:18 -0700 (PDT) MIME-Version: 1.0 References: <20191114045543.6759-1-julian.tuminaro@gmail.com> In-Reply-To: From: George Dunlap Date: Tue, 9 Jun 2020 15:42:07 +0100 Message-ID: Subject: Re: [Xen-devel] [PATCH V2] kdd.c: Add support for initial handshake in KD protocol for Win 7, 8 and 10 (64 bit) To: Paul Durrant Content-Type: multipart/alternative; boundary="000000000000fb1f0005a7a7bb78" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Tim Deegan , Jenish Rakholiya , Ian Jackson , Julian Tuminaro , George Dunlap , xen-devel , Julian Tuminaro Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --000000000000fb1f0005a7a7bb78 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 15, 2019 at 1:31 PM Paul Durrant wrote: > On Thu, 14 Nov 2019 at 04:57, Julian Tuminaro > wrote: > > > > From: Julian Tuminaro and Jenish Rakholiya and rakholiyajenish.07@gmail.com> > > > > Current implementation of find_os is based on the hard-coded values for > > different Windows version. It uses the value for get the address to > > start looking for DOS header in the given specified range. However, this > > is not scalable to all version of Windows as it will require us to keep > > adding new entries and also due to KASLR, chances of not hitting the PE > > header is significant. We implement a way for 64-bit systems to use IDT > > entry to get a valid exception/interrupt handler and then move back into > > the memory to find the valid DOS header. Since IDT entries are protected > > by PatchGuard, we think our assumption that IDT entries will not be > > corrupted is valid for our purpose. Once we have the image base, we > > search for the DBGKD_GET_VERSION64 structure type in .data section to > > get information required for handshake. > > > > Currently, this is a work in progress feature and current patch only > > supports the handshake and memory read/write on 64-bit systems. > > > > NOTE: This is the Updated version of the previous patch submitted > > NOTE: This has currently been only tested when debugging was not enabled > > on the guest Windows. > > > > Signed-off-by: Jenish Rakholiya > > Signed-off-by: Julian Tuminaro > > LGTM. > > Reviewed-by: Paul Durrant > Paul, is this something worth adding a line to CHANGELOG about? -George --000000000000fb1f0005a7a7bb78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Nov 15, 2019 at 1:31 PM Paul = Durrant <pdurrant@gmail.com>= ; wrote:
On Thu,= 14 Nov 2019 at 04:57, Julian Tuminaro <julian.tuminaro@gmail.com> wrote:
>
> From: Julian Tuminaro and Jenish Rakholiya <julian.tuminaro@gmail.com and <= a href=3D"mailto:rakholiyajenish.07@gmail.com" target=3D"_blank">rakholiyaj= enish.07@gmail.com>
>
> Current implementation of find_os is based on the hard-coded values fo= r
> different Windows version. It uses the value for get the address to > start looking for DOS header in the given specified range. However, th= is
> is not scalable to all version of Windows as it will require us to kee= p
> adding new entries and also due to KASLR, chances of not hitting the P= E
> header is significant. We implement a way for 64-bit systems to use ID= T
> entry to get a valid exception/interrupt handler and then move back in= to
> the memory to find the valid DOS header. Since IDT entries are protect= ed
> by PatchGuard, we think our assumption that IDT entries will not be > corrupted is valid for our purpose. Once we have the image base, we > search for the DBGKD_GET_VERSION64 structure type in .data section to<= br> > get information required for handshake.
>
> Currently, this is a work in progress feature and current patch only > supports the handshake and memory read/write on 64-bit systems.
>
> NOTE: This is the Updated version of the previous patch submitted
> NOTE: This has currently been only tested when debugging was not enabl= ed
> on the guest Windows.
>
> Signed-off-by: Jenish Rakholiya <rjenish@cmu.edu>
> Signed-off-by: Julian Tuminaro <jtuminar@andrew.cmu.edu>

LGTM.

Reviewed-by: Paul Durrant <paul@xen.org>
=
Paul, is this something worth adding a= line to CHANGELOG about?

=C2=A0-George
--000000000000fb1f0005a7a7bb78-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 14:49:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 14:49:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifYf-0007Yi-97; Tue, 09 Jun 2020 14:48:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifYd-0007YS-B2 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 14:48:55 +0000 X-Inumbo-ID: 56e693a6-aa60-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 56e693a6-aa60-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 14:48:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 17553ADD3; Tue, 9 Jun 2020 14:48:57 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH for-4.14 2/2] tools: fix setting of errno in xenhypfs_read_raw() Date: Tue, 9 Jun 2020 16:48:50 +0200 Message-Id: <20200609144850.28619-3-jgross@suse.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200609144850.28619-1-jgross@suse.com> References: <20200609144850.28619-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Ian Jackson , George Dunlap , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Setting of errno is wrong in xenhypfs_read_raw(), fix it. Reported-by: George Dunlap Signed-off-by: Juergen Gross --- tools/libs/hypfs/core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tools/libs/hypfs/core.c b/tools/libs/hypfs/core.c index fc23b02586..f94c5ea1e2 100644 --- a/tools/libs/hypfs/core.c +++ b/tools/libs/hypfs/core.c @@ -241,10 +241,8 @@ void *xenhypfs_read_raw(xenhypfs_handle *fshdl, const char *path, if (!ret) break; - if (ret != ENOBUFS) { - errno = -ret; + if (errno != ENOBUFS) goto out; - } } content = malloc(entry->content_len); -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 14:49:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 14:49:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifYe-0007Yb-1W; Tue, 09 Jun 2020 14:48:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifYd-0007YR-3M for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 14:48:55 +0000 X-Inumbo-ID: 56d7a418-aa60-11ea-b32b-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 56d7a418-aa60-11ea-b32b-12813bfff9fa; Tue, 09 Jun 2020 14:48:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CFEC0AD75; Tue, 9 Jun 2020 14:48:56 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH for-4.14 0/2] tools: two minor fixes for libxenhypfs Date: Tue, 9 Jun 2020 16:48:48 +0200 Message-Id: <20200609144850.28619-1-jgross@suse.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Ian Jackson , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Two fixes for libxenhypfs: - xenhypfs terminating with segfault when hypervisor doesn't have hypfs support - wrong error reporting in case for access errors with xenhypfs Juergen Gross (2): tools: fix error path of xenhypfs_open() tools: fix setting of errno in xenhypfs_read_raw() tools/libs/hypfs/core.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 14:49:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 14:49:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifYi-0007aF-HM; Tue, 09 Jun 2020 14:49:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifYi-0007YS-5U for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 14:49:00 +0000 X-Inumbo-ID: 56d787b2-aa60-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 56d787b2-aa60-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 14:48:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DD42FAD85; Tue, 9 Jun 2020 14:48:56 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH for-4.14 1/2] tools: fix error path of xenhypfs_open() Date: Tue, 9 Jun 2020 16:48:49 +0200 Message-Id: <20200609144850.28619-2-jgross@suse.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200609144850.28619-1-jgross@suse.com> References: <20200609144850.28619-1-jgross@suse.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Andrew Cooper , Ian Jackson , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In case of an error in xenhypfs_open() the error path will cause a segmentation fault due to a wrong sequence of closing calls. Reported-by: Andrew Cooper Signed-off-by: Juergen Gross --- tools/libs/hypfs/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libs/hypfs/core.c b/tools/libs/hypfs/core.c index c91e165705..fc23b02586 100644 --- a/tools/libs/hypfs/core.c +++ b/tools/libs/hypfs/core.c @@ -74,8 +74,8 @@ xenhypfs_handle *xenhypfs_open(xentoollog_logger *logger, return fshdl; err: - xtl_logger_destroy(fshdl->logger_tofree); xencall_close(fshdl->xcall); + xtl_logger_destroy(fshdl->logger_tofree); free(fshdl); return NULL; } -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 14:56:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 14:56:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifgI-0000Bx-Ae; Tue, 09 Jun 2020 14:56:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifgH-0000Bs-4A for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 14:56:49 +0000 X-Inumbo-ID: 7175b7aa-aa61-11ea-8496-bc764e2007e4 Received: from mail-wr1-x435.google.com (unknown [2a00:1450:4864:20::435]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7175b7aa-aa61-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 14:56:48 +0000 (UTC) Received: by mail-wr1-x435.google.com with SMTP id x6so21615235wrm.13 for ; Tue, 09 Jun 2020 07:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=X/gum8gMNp9JDKAbvHKr2DOxNKPyYrM3RL4ioVlLV20=; b=RLLxMtZ+ow6+2/HgvtjAytqDw3j+cm+1qxHqbDBrtzQdcHimBkLRvMKZ7d5JGiFLMU pjJZLNTco3bsU4AAnWCJiST+TUR8jAz7IcHBY9rp1aFWYy8dPRUKZ5NzAgYhgyImwghL KD6xF3muiBDOiWxe5lT7ZL7vUqKLRRYZZ8z2mEXIXMljC5UxTHyaPVvLZ7btAXvWYSOO lmy/LHE0rA7OkBwarB0KH4MGdYUfCqMZUm9E+ZhWGKd48zzJtjPRF2nh94iTDMsaPYTU nqXvNzIH/3Mc1SCsq3t3W2W11pHcM/w7FJxnMByaP4+sfALuG0PnFdmup2xt2kogghXs S1gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=X/gum8gMNp9JDKAbvHKr2DOxNKPyYrM3RL4ioVlLV20=; b=Am98jQMMhI5JmupyC/XJolh7hG/eAhmfsg2P5MYkZoSleS/WAlez4RztBDdHbQE96u rj4gvW8JvtXtpyJrMjft30NEnU7NOZpGZ9Faf3mSAO4E1+eHvXZQsFopnzasBeW5vDBX 0j5fC08KhtUteuCDCUjPQt/oTRDzNRVUakL9MEjhHhXyGJXq87QxFdx+WWdnyVUaexOw IgHQAysfFETmFVqZ6jiCLn5zwEeQIyHIj3zLXQW5HdmRf0RGF1Uh134Se6xe6THuZDEh 6QUiZ1yYZDLTPMbfg6F9W9azGoEXsCq+GOOb4p2w+86yNh+IZERjo3XnQpKDtuPPfWSY a4yA== X-Gm-Message-State: AOAM531Emgq6TlS7Vl+Lg5tr6Y9WaF/3VB0i/BPC4okiQqt1oMZJ5cva 8gjnbtPppCQeAtBhppLYYqY= X-Google-Smtp-Source: ABdhPJyrpJz1eGm+5fBHyIZzo8cBU9ql/vBGQQtHJYkLJ9kLQeHfUPs2oIAt6Ig5EJOUYdQzXGVzgg== X-Received: by 2002:a5d:628c:: with SMTP id k12mr4916547wru.211.1591714607688; Tue, 09 Jun 2020 07:56:47 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id q4sm3184818wma.47.2020.06.09.07.56.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 07:56:47 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Juergen Gross'" , References: <20200609144850.28619-1-jgross@suse.com> <20200609144850.28619-2-jgross@suse.com> In-Reply-To: <20200609144850.28619-2-jgross@suse.com> Subject: RE: [PATCH for-4.14 1/2] tools: fix error path of xenhypfs_open() Date: Tue, 9 Jun 2020 15:56:45 +0100 Message-ID: <00ab01d63e6e$32a5ce20$97f16a60$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJImk/I1P2ywCrTN6Alqf97EMn8vwLv1NDIp9Qo41A= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Juergen Gross > Sent: 09 June 2020 15:49 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Juergen Gross ; Ian Jackson ; Wei Liu > ; Andrew Cooper > Subject: [PATCH for-4.14 1/2] tools: fix error path of xenhypfs_open() > > In case of an error in xenhypfs_open() the error path will cause a > segmentation fault due to a wrong sequence of closing calls. > > Reported-by: Andrew Cooper > Signed-off-by: Juergen Gross Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant > --- > tools/libs/hypfs/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/libs/hypfs/core.c b/tools/libs/hypfs/core.c > index c91e165705..fc23b02586 100644 > --- a/tools/libs/hypfs/core.c > +++ b/tools/libs/hypfs/core.c > @@ -74,8 +74,8 @@ xenhypfs_handle *xenhypfs_open(xentoollog_logger *logger, > return fshdl; > > err: > - xtl_logger_destroy(fshdl->logger_tofree); > xencall_close(fshdl->xcall); > + xtl_logger_destroy(fshdl->logger_tofree); > free(fshdl); > return NULL; > } > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:01:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:01:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifl6-00012c-UG; Tue, 09 Jun 2020 15:01:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifl5-00012X-Gj for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:01:47 +0000 X-Inumbo-ID: 22d4423d-aa62-11ea-b32e-12813bfff9fa Received: from mail-ej1-f65.google.com (unknown [209.85.218.65]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 22d4423d-aa62-11ea-b32e-12813bfff9fa; Tue, 09 Jun 2020 15:01:46 +0000 (UTC) Received: by mail-ej1-f65.google.com with SMTP id gl26so22729214ejb.11 for ; Tue, 09 Jun 2020 08:01:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H1GRCEhZWUgNlyiOMzBrIEcR3CXcGbq7KIzI/v/uBOQ=; b=C6GNhES5NV0zFGVgWwfDb7p6GDlwdCeNjTGQzzLEE9DFo7rAn9wc36YJutvCa7X8lM b3G5S4/KJZiqvENdUQ+0ya7P9YSbOUuJvIZISIaTrGWH6+nY3HXl+zcF3XauaJ5zTahp eEWH/ZNNcnYNbudIBxcCl9FoGkHHgaoMXi0E1OOuJAARVqUusHJpg3QCHb47CqRLvAmH sK5Iamei0AFdPZFGNOC683S9GCRcPSsDeXdKRxrXlOeEc54Poi0CNPHZhGn2mxMOsFJE p94Exf35f3z0/1kxNkhnIJJkCEzCEDOZHYmDIjUmIBqyEmn2S3hZlA1BLAQzd11udDa7 y0sw== X-Gm-Message-State: AOAM533u+F5ipSzeR3+Wd7p0ow3p29sIow02GbCyXwnNhvDBNbfwb0QF aoRggNePYkGeSUlAc04rRkSRW6z7n4WSaa9i3fji4A== X-Google-Smtp-Source: ABdhPJxHCvIkzcjNbDPwNTb1ahzE/eL1CckOGMKHTHgZUYDEKgnrODP9yh5lqy0Uwsh+wBoSCQ03VsR7MnWK5ENWy1w= X-Received: by 2002:a17:906:1e52:: with SMTP id i18mr26907519ejj.335.1591714905958; Tue, 09 Jun 2020 08:01:45 -0700 (PDT) MIME-Version: 1.0 References: <20191126100801.124844-1-wipawel@amazon.de> In-Reply-To: <20191126100801.124844-1-wipawel@amazon.de> From: George Dunlap Date: Tue, 9 Jun 2020 16:01:34 +0100 Message-ID: Subject: Re: [Xen-devel] [PATCH v6 00/12] livepatch: new features and fixes To: Pawel Wieczorkiewicz Content-Type: multipart/alternative; boundary="0000000000008dad5e05a7a80173" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , George Dunlap , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --0000000000008dad5e05a7a80173 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 26, 2019 at 10:14 AM Pawel Wieczorkiewicz wrote: > This series introduces new features to the livepatch functionality as > briefly discussed during Xen Developer Summit 2019: [a] and [b]. > It also provides a few fixes and some small improvements. > > Main changes in v6: > - Added missing action pad field zeroing > > Main changes in v4: > - Fix various typos and minor issues > - Simplify arch_livepatch_{apply,revert} by using > common_livepatch_{apply,revert} > - Improve python bindings and fix few issues > > Main changes in v3: > - Fix expectation test to work on Arm > - Add test for metadata (Konrad) > - Minor fixes to documentation > > Main changes in v2: > - added new features to livepatch documentation > - added livepatch tests > - enabled Arm support for [5] > - make .modinfo optional for [11] > - fixed typos > > FEATURES: > > 1. independent modules (patches: [1], [2]) > > * livepatch-build-tools repo dependency [A] > > Livepatch enforces the following buildid-based dependency chain > between hotpatch modules: > 1) first module depends on given hypervisor buildid > 2) every consecutive module depends on previous module's buildid > This way proper hotpatch stack order is maintained and enforced. > While it is important for production hotpatches it limits agility and > blocks usage of testing or debug hotpatches. These kinds of hotpatch > modules are typically expected to be loaded at any time irrespective > of current state of the modules stack. > > [A] livepatch-build: Embed hypervisor build id into every hotpatch > > 2. pre- and post- apply|revert actions hooks (patches: [3], [4]) > > * livepatch-build-tools repo dependency [B] > > This is an implementation of 4 new livepatch module vetoing hooks, > that can be optionally supplied along with modules. > Hooks that currently exists in the livepatch mechanism aren't agile > enough and have various limitations: > * run only from within a quiescing zone > * cannot conditionally prevent applying or reverting > * do not have access to the module context > To address these limitations the following has been implemented: > 1) pre-apply hook > 2) post-apply hook > 3) pre-revert hook > 4) post-revert hook > > [B] create-diff-object: Handle extra pre-|post- hooks > > 3. apply|revert actions replacement hooks (patches: [5], [6], [7]) > > * livepatch-build-tools repo dependency: [C], [D], [E] > > To increase hotpatching system's agility and provide more flexiable > long-term hotpatch solution, allow to overwrite the default apply > and revert action functions with hook-like supplied alternatives. > The alternative functions are optional and the default functions are > used by default. > > [C] create-diff-object: Do not create empty .livepatch.funcs section > [D] create-diff-object: Handle optional apply|revert hooks > [E] create-diff-object: Add support for applied/reverted marker > > 4. inline asm hotpatching expectations (patches: [8]) > > * livepatch-build-tools repo dependency: [F] > > Expectations are designed as optional feature, since the main use of > them is planned for inline asm hotpatching. > The payload structure is modified as each expectation structure is > part of the livepatch_func structure and hence extends the payload. > The payload version is bumped to 3 with this change to highlight the > ABI modification and enforce proper support. > The expectation is manually enabled during inline asm module > construction. If enabled, expectation ensures that the expected > content of memory is to be found at a given patching (old_addr) > location. > > [F] create-diff-object: Add support for expectations > > 5. runtime hotpatch metadata support (patches: [9], [10], [11]) > > Having detailed hotpatch metadata helps to properly identify module's > origin and version. It also allows to keep track of the history of > hotpatch loads in the system (at least within dmesg buffer size > limits). > Extend the livepatch list operation to fetch also payloads' metadata. > This is achieved by extending the sysctl list interface with 2 extra > guest handles: > * metadata - an array of arbitrary size strings > * metadata_len - an array of metadata strings' lengths (uin32_t each) > To unify and simplify the interface, handle the modules' name strings > of arbitrary size by copying them in adhering chunks to the userland. > > 6. python bindings for livepatch operations (patches: [12]) > > Extend the XC python bindings library to support all common livepatch > operations and actions: > - status (pyxc_livepatch_status): > - action (pyxc_livepatch_action): > - upload (pyxc_livepatch_upload): > - list (pyxc_livepatch_list): > This series looks like it would be a good candidate for a CHANGELOG.md line. What about something like this: - Livepatch improvements: Buildid / hotpatch "stack" restrictions, Additional {pre,post}-{apply,revert} hooks, inline hotpatching expectations, runtime hotpatch metdata, python bindings for livepatch operations -George --0000000000008dad5e05a7a80173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 26, 2019 at 10:14 AM Pawe= l Wieczorkiewicz <wipawel@amazon.de= > wrote:
= This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes and some small improvements.

Main changes in v6:
- Added missing action pad field zeroing

Main changes in v4:
- Fix various typos and minor issues
- Simplify arch_livepatch_{apply,revert} by using
=C2=A0 common_livepatch_{apply,revert}
- Improve python bindings and fix few issues

Main changes in v3:
- Fix expectation test to work on Arm
- Add test for metadata (Konrad)
- Minor fixes to documentation

Main changes in v2:
- added new features to livepatch documentation
- added livepatch tests
- enabled Arm support for [5]
- make .modinfo optional for [11]
- fixed typos

FEATURES:

1. independent modules (patches: [1], [2])

=C2=A0 * livepatch-build-tools repo dependency [A]

=C2=A0 Livepatch enforces the following buildid-based dependency chain
=C2=A0 between hotpatch modules:
=C2=A0 =C2=A0 1) first module depends on given hypervisor buildid
=C2=A0 =C2=A0 2) every consecutive module depends on previous module's = buildid
=C2=A0 This way proper hotpatch stack order is maintained and enforced.
=C2=A0 While it is important for production hotpatches it limits agility an= d
=C2=A0 blocks usage of testing or debug hotpatches. These kinds of hotpatch=
=C2=A0 modules are typically expected to be loaded at any time irrespective=
=C2=A0 of current state of the modules stack.

=C2=A0 [A] livepatch-build: Embed hypervisor build id into every hotpatch
2. pre- and post- apply|revert actions hooks (patches: [3], [4])

=C2=A0 * livepatch-build-tools repo dependency [B]

=C2=A0 This is an implementation of 4 new livepatch module vetoing hooks, =C2=A0 that can be optionally supplied along with modules.
=C2=A0 Hooks that currently exists in the livepatch mechanism aren't ag= ile
=C2=A0 enough and have various limitations:
=C2=A0 * run only from within a quiescing zone
=C2=A0 * cannot conditionally prevent applying or reverting
=C2=A0 * do not have access to the module context
=C2=A0 To address these limitations the following has been implemented:
=C2=A0 1) pre-apply hook
=C2=A0 2) post-apply hook
=C2=A0 3) pre-revert hook
=C2=A0 4) post-revert hook

=C2=A0 [B] create-diff-object: Handle extra pre-|post- hooks

3. apply|revert actions replacement hooks (patches: [5], [6], [7])

=C2=A0 * livepatch-build-tools repo dependency: [C], [D], [E]

=C2=A0 To increase hotpatching system's agility and provide more flexia= ble
=C2=A0 long-term hotpatch solution, allow to overwrite the default apply =C2=A0 and revert action functions with hook-like supplied alternatives. =C2=A0 The alternative functions are optional and the default functions are=
=C2=A0 used by default.

=C2=A0 [C] create-diff-object: Do not create empty .livepatch.funcs section=
=C2=A0 [D] create-diff-object: Handle optional apply|revert hooks
=C2=A0 [E] create-diff-object: Add support for applied/reverted marker

4. inline asm hotpatching expectations (patches: [8])

=C2=A0 * livepatch-build-tools repo dependency: [F]

=C2=A0 Expectations are designed as optional feature, since the main use of=
=C2=A0 them is planned for inline asm hotpatching.
=C2=A0 The payload structure is modified as each expectation structure is =C2=A0 part of the livepatch_func structure and hence extends the payload.<= br> =C2=A0 The payload version is bumped to 3 with this change to highlight the=
=C2=A0 ABI modification and enforce proper support.
=C2=A0 The expectation is manually enabled during inline asm module
=C2=A0 construction. If enabled, expectation ensures that the expected
=C2=A0 content of memory is to be found at a given patching (old_addr)
=C2=A0 location.

=C2=A0 [F] create-diff-object: Add support for expectations

5. runtime hotpatch metadata support (patches: [9], [10], [11])

=C2=A0 Having detailed hotpatch metadata helps to properly identify module&= #39;s
=C2=A0 origin and version. It also allows to keep track of the history of =C2=A0 hotpatch loads in the system (at least within dmesg buffer size
=C2=A0 limits).
=C2=A0 Extend the livepatch list operation to fetch also payloads' meta= data.
=C2=A0 This is achieved by extending the sysctl list interface with 2 extra=
=C2=A0 guest handles:
=C2=A0 * metadata=C2=A0 =C2=A0 =C2=A0- an array of arbitrary size strings =C2=A0 * metadata_len - an array of metadata strings' lengths (uin32_t = each)
=C2=A0 To unify and simplify the interface, handle the modules' name st= rings
=C2=A0 of arbitrary size by copying them in adhering chunks to the userland= .

6. python bindings for livepatch operations (patches: [12])

=C2=A0 Extend the XC python bindings library to support all common livepatc= h
=C2=A0 operations and actions:
=C2=A0 - status (pyxc_livepatch_status):
=C2=A0 - action (pyxc_livepatch_action):
=C2=A0 - upload (pyxc_livepatch_upload):
=C2=A0 - list (pyxc_livepatch_list):

Th= is series looks like it would be a good candidate for a CHANGELOG.md line.<= /div>

What about something like this:

- Livepatch improvements: Buildid / hotpatch "stack" restr= ictions, Additional {pre,post}-{apply,revert} hooks, inline hotpatching exp= ectations, runtime hotpatch metdata, python bindings for livepatch operatio= ns

=C2=A0-George
--0000000000008dad5e05a7a80173-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:02:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:02:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiflZ-00014v-6p; Tue, 09 Jun 2020 15:02:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiflX-00014l-V0 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:02:16 +0000 X-Inumbo-ID: 344bf460-aa62-11ea-8496-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 344bf460-aa62-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 15:02:15 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id u26so2520638wmn.1 for ; Tue, 09 Jun 2020 08:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=s3CKbZ4cdGeIagoNQQCQIiVIGsrlCr7cr1u8QUoLxt4=; b=dYMP99xQYZ61axkZ1aiRmqNAUE8DZx7v5lRs/urVZwpSVvKmCqz3ZtnbHPbl7I25u3 iZnSP8YAkW5+9TZFEhQeBfiZh0uPDlwN05g9AK2TlfnHYfylcJwGZj69acNd8S+5nysr gz+t3sjRQuco3w5sjMmR9oWA9F9oxwhRjg93Xm1W0t8d+ML67+mdve5Gg4ws5mC8R7Zg wqBDohnvJEm3tN/iCbKvx1VshJ3G3cK+mR/BbNlMh4sP6H1SJfaku++3X0rGFEfafiZ5 EKepd3uLYNo4kXQHxOGlLvutE7mpdudhkmLK6TPJihdPGCCCJj5PgpsvSZTMgTGWlrvU DifA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=s3CKbZ4cdGeIagoNQQCQIiVIGsrlCr7cr1u8QUoLxt4=; b=kV0beImUvwq65cUSg2epOiKnxj9in8Z4imsDxxSxuZo4maqNfR7LP5N4QafmZ7O3hI n0/EDSkHG14yvdc49q6sZRWIBQ8QBGWOv02HmBchUQdwI/uOfl2HUt+m5IkPVKRGKg11 XhmMMF1FubQAVW13XXOqqHS2UHCIggOmF61kgvzObKt7etIip9JhPZFnZgGalA0Mz1eI iD/7ZOK81dm0R3Q0vOg/qcKU3boJHWZca/tkgw8nWZX+iHUv0fVL7N92fuB4EPCHXpzt vFxL5EhTWDT0+Aktkcg5PNBQzp3H3t4ZbFCjB8wIg1DQOIq1kkZXWHa24MSOhIm++Ci5 XK8w== X-Gm-Message-State: AOAM530A+ON/bBBxVDq2jK6WWfyrDQ9mjNNFRBShB9RxSoJja3sq/r2L qb6dsvTMb96z5ys94f2LRaQ= X-Google-Smtp-Source: ABdhPJyJSwCN73oqHMgDEMu3k6AQHAjeKG8Ru1IXuvtymI0h65sLL7HTsSpxUkutxF6Tqn3Z9hwfUA== X-Received: by 2002:a1c:6509:: with SMTP id z9mr4754852wmb.144.1591714934559; Tue, 09 Jun 2020 08:02:14 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id 50sm3961168wra.1.2020.06.09.08.02.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 08:02:14 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Juergen Gross'" , References: <20200609144850.28619-1-jgross@suse.com> <20200609144850.28619-3-jgross@suse.com> In-Reply-To: <20200609144850.28619-3-jgross@suse.com> Subject: RE: [PATCH for-4.14 2/2] tools: fix setting of errno in xenhypfs_read_raw() Date: Tue, 9 Jun 2020 16:02:12 +0100 Message-ID: <00ac01d63e6e$f58224c0$e0866e40$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJImk/I1P2ywCrTN6Alqf97EMn8vwHT/j8hp90JTqA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Ian Jackson' , 'George Dunlap' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Juergen Gross > Sent: 09 June 2020 15:49 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Juergen Gross ; Ian Jackson ; Wei Liu > ; George Dunlap > Subject: [PATCH for-4.14 2/2] tools: fix setting of errno in xenhypfs_read_raw() > > Setting of errno is wrong in xenhypfs_read_raw(), fix it. > > Reported-by: George Dunlap > Signed-off-by: Juergen Gross Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant > --- > tools/libs/hypfs/core.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/tools/libs/hypfs/core.c b/tools/libs/hypfs/core.c > index fc23b02586..f94c5ea1e2 100644 > --- a/tools/libs/hypfs/core.c > +++ b/tools/libs/hypfs/core.c > @@ -241,10 +241,8 @@ void *xenhypfs_read_raw(xenhypfs_handle *fshdl, const char *path, > if (!ret) > break; > > - if (ret != ENOBUFS) { > - errno = -ret; > + if (errno != ENOBUFS) > goto out; > - } > } > > content = malloc(entry->content_len); > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:06:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:06:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifpN-0001JS-Pv; Tue, 09 Jun 2020 15:06:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifpN-0001JN-2z for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:06:13 +0000 X-Inumbo-ID: c19c5c56-aa62-11ea-8496-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c19c5c56-aa62-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 15:06:12 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id d128so3511814wmc.1 for ; Tue, 09 Jun 2020 08:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=DdBtwbu2BJNWL4QdNq8ZrBY16h2s9I7g5sLWO2vuH7I=; b=K7xiXG1I1R+TfuNGTFk/1lO/8Foi533aV926mY7KejIJZePCnSgLoJjXW4tJDKN5ar ZdF+Zg/Ql8C+oXIFTCmLH43I2B1RCY5YZTnWFsHx9wBDpG+H8iEjecSTiZp3eCrN+cqH LGZV8BUdYQEuNTJw8Dbhh1VaG97PfWgZmGimLXVHFNRkn2WY7Ne4Yz3dDZAO21ClkVwe 2+j1Js5cWRlZteM/7iW5yQ19X7ykkEAlqxfixJ1E+6EwQ/F/DsE63C6A7P3urXL6dubB nokIiuN9QDeTDQMPpZJT3dxWZR/y/zFRJWMmDm5XiTAuoZ0yjlyMviC9PpjmsYdhntIF 5/TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=DdBtwbu2BJNWL4QdNq8ZrBY16h2s9I7g5sLWO2vuH7I=; b=EAd8iTRDwaDhQMzTJhJR138Shb17+ARJ0iS+hH7QgByB1gJcbDXC+7YLkBc8cOQKY6 eNvy8xlEhoIfE7m1wAINXimbOh5nwpNKx8zgEsnaEmZ5AElnuuHkdjcKNG8OTS1vGa65 06gzUno+uYu2Qnu8gQZqWT0UxEtHOOqXYH//LI+v62WUMCIBmMyml2jsJ4Ngt49/deAP 7K8L2TJRGlDLDvPTO6e3fz5NxExJuN/BpIgOEmE1KyyT9+8j4nDfwM13dVK4hIzThgVP R3NCO44pm8200KN0t3ie8zgNVl6LEpKPnPnFnEsPKrZJkTf9nrA1K0xRfS1HI4jJunD4 F2nw== X-Gm-Message-State: AOAM5327BSpPX2hfRzMTgyL/n9RBrxwupD8ocNOu+YsQRRT3tzhpX5z1 Y3MGulVjMT3P4f9trsFaDcc= X-Google-Smtp-Source: ABdhPJwmPs4aMUM5Fx4h1ednyZmCnSyx7O8xq7WVTqhDX/yC+Infed4u5loTsYbSZmzXxiLI4WzynA== X-Received: by 2002:a1c:bd84:: with SMTP id n126mr4218437wmf.149.1591715171628; Tue, 09 Jun 2020 08:06:11 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id z25sm3235604wmf.10.2020.06.09.08.06.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 08:06:11 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'George Dunlap'" , "'Paul Durrant'" References: <20191114045543.6759-1-julian.tuminaro@gmail.com> In-Reply-To: Subject: RE: [Xen-devel] [PATCH V2] kdd.c: Add support for initial handshake in KD protocol for Win 7, 8 and 10 (64 bit) Date: Tue, 9 Jun 2020 16:06:09 +0100 Message-ID: <00b101d63e6f$82ce52e0$886af8a0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQEJ8ObCoXVZNyLYJBq22fcF/ZBpPgHyoU36Aj5tdimqR3RjoA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Wei Liu' , 'Ian Jackson' , 'Jenish Rakholiya' , 'Tim Deegan' , 'George Dunlap' , 'Julian Tuminaro' , 'xen-devel' , 'Julian Tuminaro' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" De-htmling... ----- From: Xen-devel On Behalf Of = George Dunlap Sent: 09 June 2020 15:42 To: Paul Durrant Cc: Wei Liu ; Tim Deegan ; Jenish = Rakholiya ; Ian Jackson ; = Julian Tuminaro ; George Dunlap = ; xen-devel ; = Julian Tuminaro Subject: Re: [Xen-devel] [PATCH V2] kdd.c: Add support for initial = handshake in KD protocol for Win 7, 8 and 10 (64 bit) On Fri, Nov 15, 2019 at 1:31 PM Paul Durrant = wrote: On Thu, 14 Nov 2019 at 04:57, Julian Tuminaro = wrote: > > From: Julian Tuminaro and Jenish Rakholiya = > > Current implementation of find_os is based on the hard-coded values = for > different Windows version. It uses the value for get the address to > start looking for DOS header in the given specified range. However, = this > is not scalable to all version of Windows as it will require us to = keep > adding new entries and also due to KASLR, chances of not hitting the = PE > header is significant. We implement a way for 64-bit systems to use = IDT > entry to get a valid exception/interrupt handler and then move back = into > the memory to find the valid DOS header. Since IDT entries are = protected > by PatchGuard, we think our assumption that IDT entries will not be > corrupted is valid for our purpose. Once we have the image base, we > search for the DBGKD_GET_VERSION64 structure type in .data section to > get information required for handshake. > > Currently, this is a work in progress feature and current patch only > supports the handshake and memory read/write on 64-bit systems. > > NOTE: This is the Updated version of the previous patch submitted > NOTE: This has currently been only tested when debugging was not = enabled > on the guest Windows. > > Signed-off-by: Jenish Rakholiya > Signed-off-by: Julian Tuminaro LGTM. Reviewed-by: Paul Durrant Paul, is this something worth adding a line to CHANGELOG about? -George ----- Yes, I'd completely forgotten this had fallen in the 4.14 timeline. I'll = send a patch. Paul From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:07:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:07:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifqz-0001S3-4z; Tue, 09 Jun 2020 15:07:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jifqx-0001Rv-Qs for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:07:51 +0000 X-Inumbo-ID: fc6bb7f0-aa62-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fc6bb7f0-aa62-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 15:07:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C39DBACC3; Tue, 9 Jun 2020 15:07:53 +0000 (UTC) Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction To: paul@xen.org References: <20200608094619.28336-1-paul@xen.org> <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> <002a01d63d84$9c351430$d49f3c90$@xen.org> From: Jan Beulich Message-ID: <86e29001-4b33-de46-0675-0107a2e2b386@suse.com> Date: Tue, 9 Jun 2020 17:07:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <002a01d63d84$9c351430$d49f3c90$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Paul Durrant' , =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 08.06.2020 13:04, Paul Durrant wrote: >> From: Jan Beulich >> Sent: 08 June 2020 11:58 >> >> On 08.06.2020 11:46, Paul Durrant wrote: >>> --- a/xen/arch/x86/hvm/ioreq.c >>> +++ b/xen/arch/x86/hvm/ioreq.c >>> @@ -109,15 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data) >>> ioreq_t *ioreq = &v->arch.hvm.hvm_io.io_req; >>> >>> if ( hvm_ioreq_needs_completion(ioreq) ) >>> - { >>> - ioreq->state = STATE_IORESP_READY; >>> ioreq->data = data; >>> - } >>> - else >>> - ioreq->state = STATE_IOREQ_NONE; >>> - >>> - msix_write_completion(v); >>> - vcpu_end_shutdown_deferral(v); >>> >>> sv->pending = false; >>> } >> >> With this, is the function worth keeping at all? > > I did think about that, but it is called in more than one place. So, > in the interest of trying to make back-porting straightforward, I > thought it best to keep it simple. Fair enough, but going forward I still think it would be nice to get rid of the function. To do this sufficiently cleanly, the main question I have is: Why is hvm_wait_for_io() implemented as a loop? Hasn't this become pointless with the XSA-262 fix? Switching this to a do {} while(false) construct (seeing that the only caller has already checked sv->pending) would look to allow moving what is now in hvm_io_assist() immediately past this construct, at the expense of a local variable holding ~0ul initially and then in the common case p->data. Thoughts? (I'll be happy to make such a patch, I'm just checking whether I'm overlooking something crucial.) Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:28:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:28:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigB3-0003Gf-RQ; Tue, 09 Jun 2020 15:28:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigB2-0003Ga-1n for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:28:36 +0000 X-Inumbo-ID: e1432528-aa65-11ea-8496-bc764e2007e4 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe07::62c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e1432528-aa65-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 15:28:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rwg75vUC0/I6nbKYzO5i8itbwS3p9Nh1ik91B+RMI8M=; b=NYAoMP7Wm6OrGah1BQ4w3KkX2emVojUruxL+X/aGFRO384f8HsP6v658o3BNH1GKueZGTjnECTb9L3qn7HbqxdIO899l8eMzckFeNT66E70z/H6RhKViufwxYKIQEyfboLBPnkXE8Kx29hx/ltuZp/qrdEGSSd6++qGjvEf3Rr0= Received: from AM6PR08CA0021.eurprd08.prod.outlook.com (2603:10a6:20b:b2::33) by VI1PR0802MB2143.eurprd08.prod.outlook.com (2603:10a6:800:9a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Tue, 9 Jun 2020 15:28:32 +0000 Received: from VE1EUR03FT007.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:b2:cafe::b7) by AM6PR08CA0021.outlook.office365.com (2603:10a6:20b:b2::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Tue, 9 Jun 2020 15:28:32 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT007.mail.protection.outlook.com (10.152.18.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Tue, 9 Jun 2020 15:28:31 +0000 Received: ("Tessian outbound fb809da9b456:v59"); Tue, 09 Jun 2020 15:28:31 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 1c4c5c455c9f8000 X-CR-MTA-TID: 64aa7808 Received: from 616bde8469d5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D4C091B4-5752-4DB6-9002-37CCDA29871D.1; Tue, 09 Jun 2020 15:28:26 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 616bde8469d5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 09 Jun 2020 15:28:26 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FCo3ymVjfOF2d0pByAIQLYYsXfs0gYpARM2sSSD4b5/mYH2t4Y6jiBra1pZxeN2mqX2Fws8ggQnWgyKOWuVqEjakWl1CjZLyCnKjXjznsY2m6C8ftqfZIMWW1t37pWOcA0r2UcMkdtEmwZAfx2pZw854+vL0WtE5ughbP2rXJBvdB7vgmzgL0NdaUJCNyxNiRDUjdmGX5PUoNzz4gfu7fZnTitVxZaSzneUpNL7uXC5N+3dcNLJCDLyPTPb4pz9zunndulpYAHkLTdWaaLiRN7UekIfU7mspZDqCxKIhWyZnQuyXQn/P1r4KMbM1RvJc/v9z4h5J3gKeaEH3CLD8vQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rwg75vUC0/I6nbKYzO5i8itbwS3p9Nh1ik91B+RMI8M=; b=YTzcIxNMgpj9ZMTS5DnXsmPd+bl05jq9Q7eK4lwsilsD+MelJE6fN13iwjkEZUHha5Rpk8CQJJaWytBCJY4fLXYSRroaeMi1FNObRvecw5brLfD+gCmLGdr6gQKOE+8npCwutrFI2iPFiZ/12LKaBluqgBNQM1SFqASZu/InUU1JfVpDrR7wk40zL6Ix+oIhRcjJcsUq7araguoP5gHLMShC81ph1wQr8hD+QXK/AmNRY1ZiBbhMPByRlAej9Akmk++nJ922S6IyIpjwXn+dReyKmdntIUCmnZ60DY5ZHxnpy8RLn5Vl11nVZaR3IfEFcJnvVQ2XrtK/FL/+m4gKbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rwg75vUC0/I6nbKYzO5i8itbwS3p9Nh1ik91B+RMI8M=; b=NYAoMP7Wm6OrGah1BQ4w3KkX2emVojUruxL+X/aGFRO384f8HsP6v658o3BNH1GKueZGTjnECTb9L3qn7HbqxdIO899l8eMzckFeNT66E70z/H6RhKViufwxYKIQEyfboLBPnkXE8Kx29hx/ltuZp/qrdEGSSd6++qGjvEf3Rr0= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3163.eurprd08.prod.outlook.com (2603:10a6:5:1e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.19; Tue, 9 Jun 2020 15:28:25 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3066.023; Tue, 9 Jun 2020 15:28:25 +0000 From: Bertrand Marquis To: CodeWiz2280 Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgIAAJpOAgABE7QCABAZcAIAAQRIAgAA9oACAAXYtAIAAD3sA Date: Tue, 9 Jun 2020 15:28:24 +0000 Message-ID: <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> References: <3ff17aa9-0aae-d598-40ce-4e90d4e50cc7@xen.org> <00E14EAD-BD23-4A3A-872E-0C47C26B7B41@arm.com> <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: de72ca91-debd-4022-09d6-08d80c89c47f x-ms-traffictypediagnostic: DB7PR08MB3163:|VI1PR0802MB2143: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:7691;OLM:7691; x-forefront-prvs: 042957ACD7 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: HYDB47nZf4vO3b4lhbzLz3L6xSRAYS/B6A1v7+gVX1WqCBXggbienBpCTzky9KOZJ0KKS/K6ILloMjacFHyTFeQv9mQN7mF2SGJ9LEUSK6yUBdRR9CAmlW89w3vpTT5FxZLoD+DyitK1/oTf96dO47niJ6p3Ny/JjIHep6IXGz2pWrnAHkSUZ+Zr24FFSLvuZ9F8AOydQK/x7E2HKffdIpAC+yp1JhmJmrX65RplASsGsAMP/aLFFaMqWBDqEn8+Khjr1vIwPc1GksUzAt5agBwvi4hZVgxZK15058NDkxNaVHyqKwJSkTf94sEf5DGnqs35K/R+9kW2//s6p+3tbA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(136003)(396003)(366004)(5660300002)(2616005)(8676002)(71200400001)(66946007)(8936002)(76116006)(2906002)(64756008)(36756003)(91956017)(66476007)(53546011)(66556008)(6512007)(66446008)(4326008)(54906003)(478600001)(6506007)(6916009)(6486002)(7116003)(3480700007)(83380400001)(316002)(26005)(86362001)(33656002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Q60wZDVrI5JpFEK8WCG3BCQY6Ke17dO0/qiS6y39KcQinygZlSUxGRlqbASS36NZwts2ULkiWh5SufHaOKGiG1cotrL/clVDPLK76EzALnnmz3uQCXuO9jsHx2oXj9+mmluTJji3L9k/G4btFz7FGQ0SLHWHvM9QnaCBVSzzHOFGrpl2U5fd4TiH0fL9A0nKfbm7I6xC/SEvFJvQEvbeJehPBCc2ra98zotUN83p7/MZ/BesL1MpA9daid6QTzS6hsKu7ClwSzQT12hS2grRTqVbJoMBu5BfoN/CBa9B6zwhHOR3UHv+ICdxLhEUZnkZIW4ZxsHH6bOvebfnaubYH0HE3COO5ViKo5AzarYoQ/7ctC3yhLaBvlNuQdHZrkpuePcdfifQVxLORPxnUcEuTVlIJo9aWeU5J6/ucGEoe7r8Nn+tl47Hf+y4wuq/Cg6EW4tLDHyHcdS4r0Db9poI+iKcKv9NunVsHhttzWIUwJE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3163 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT007.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(39860400002)(396003)(46966005)(4326008)(70586007)(6486002)(83380400001)(70206006)(47076004)(36906005)(82310400002)(8936002)(54906003)(316002)(86362001)(82740400003)(5660300002)(3480700007)(81166007)(36756003)(356005)(478600001)(2616005)(7116003)(26005)(186003)(53546011)(6506007)(8676002)(336012)(6512007)(6862004)(2906002)(33656002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 169dd153-347d-4c5c-4479-08d80c89c068 X-Forefront-PRVS: 042957ACD7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8P4NEfwCm1tW0kiXEOJ6MtRhOm5HHkavz5DclxfuQvixxjM9qTwnAKNKWU6pl/6hag767X0meNcRD6k/ejM5U4h3k8mYBjV2eDBDTfer0Fz7NLh3+Q9wRqF4EBHxZNfZt1a0UpqeAcnVv8Q1e4pWzpxhkZqtrOe4PZ1s7dcJaObo0ge/RFpvZ/nQXQ/YccY8YTDlzOv0cBcyZ83qw+zznQgY22xghTAPThf418tAmTHGrWKM8Y9orGkpzkFcV+KCjt3toHGwKcq5evxq/TlOLjQYMHz9XymdRwxaLLwjlV7ufAgdB1WN669imm4qMRHFzXuCVLWfz+4Q59irDD8sAaOn0c8ZrdwiennFFVmDDZMNULz9DXXhehBFMpDK4vfhwkWLT6BgAeR/R8YiSh9oqA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2020 15:28:31.8178 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: de72ca91-debd-4022-09d6-08d80c89c47f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2143 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, > On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >=20 > There does appear to be a secondary (CIC) controller that can forward > events to the GIC-400 and EDMA controllers for the keystone 2 family. > Admittedly, i'm not sure how it is being used with regards to the > peripherals. I only see mention of the GIC-400 parent for the devices > in the device tree. Maybe Bertrand has a better idea on whether any > peripherals go through the CIC first? I see that gic_interrupt () > fires once in Xen, which calls doIRQ to push out the virtual interrupt > to the dom0 kernel. The dom0 kernel then handles the interrupt and > returns, but gic_interrupt() never fires again in Xen. I do not remember of any CIC but the behaviour definitely look like an inte= rrupt acknowledge problem. Could you try the following: --- a/xen/arch/arm/gic-v2.c +++ b/xen/arch/arm/gic-v2.c @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc *desc) /* Lower the priority of the IRQ */ gicv2_eoi_irq(desc); /* Deactivation happens in maintenance interrupt / via GICV */ + + /* Test for Keystone2 */ + gicv2_dir_irq(desc); } I think the problem I had was related to the vgic not deactivating properly= the interrupt. This might make the interrupt fire indefinitely !! Regards Bertrand >=20 > On Mon, Jun 8, 2020 at 12:13 PM Stefano Stabellini > wrote: >>=20 >>=20 >>=20 >> On Mon, 8 Jun 2020, CodeWiz2280 wrote: >>> It actually shows only 1 interrupt for any of the devices in that list >>> (e.g. spi, ttyS0, ethernet) so you're probably right on the money with >>> it being an interrupt acknowledge issue. Any help you can provide is >>> greatly appreciated. >>>=20 >>> On Mon, Jun 8, 2020 at 4:40 AM Bertrand Marquis >>> wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On 5 Jun 2020, at 20:12, CodeWiz2280 wrote: >>>>>=20 >>>>> On Fri, Jun 5, 2020 at 11:05 AM CodeWiz2280 w= rote: >>>>>>=20 >>>>>> On Fri, Jun 5, 2020 at 8:47 AM Bertrand Marquis >>>>>> wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 5 Jun 2020, at 13:42, CodeWiz2280 wrote= : >>>>>>>>=20 >>>>>>>> On Fri, Jun 5, 2020 at 8:30 AM Julien Grall wrote= : >>>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> On 05/06/2020 13:25, CodeWiz2280 wrote: >>>>>>>>>> The Keystone uses the netcp driver, which has interrupts from 40= -79 >>>>>>>>>> listed in the device tree (arch/arm/boot/keystone-k2e-netcp.dtsi= ). >>>>>>>>>> I'm using the same device tree between my non-xen standalone ker= nel >>>>>>>>>> and my dom0 kernel booted by xen. In the standalone (non-xen) k= ernel >>>>>>>>>> the ethernet works fine, but I don't see any of its interrupts i= n the >>>>>>>>>> output of /proc/iomem. I'm not seeing them in /proc/iomem when >>>>>>>>>> running dom0 under Xen either. When booting with Xen I get this >>>>>>>>>> behavior where the ifconfig output shows 1 RX message and 1 TX >>>>>>>>>> message, and then nothing else. >>>>>>>>>=20 >>>>>>>>> I am not sure whether this is a typo in the e-mail. /proc/iomem i= s >>>>>>>>> listing the list of the MMIO regions. You want to use /proc/inter= rupts. >>>>>>>>>=20 >>>>>>>>> Can you confirm which path you are dumping? >>>>>>>> Yes, that was a typo. Sorry about that. I meant that I am dumpin= g >>>>>>>> /proc/interrupts and do not >>>>>>>> see them under the non-xen kernel or xen booted dom0. >>>>>>>=20 >>>>>>> Could you post both /proc/interrupts content ? >>>>>>=20 >>>>>> Standalone non-xen kernel (Ethernet works) >>>>>> # cat /proc/interrupts >>>>>> CPU0 CPU1 CPU2 CPU3 >>>>>> 17: 0 0 0 0 GICv2 29 Level >>>>>> arch_timer >>>>>> 18: 9856 1202 457 650 GICv2 30 Level >>>>>> arch_timer >>>>>> 21: 0 0 0 0 GICv2 142 Edge >>>>>> timer-keystone >>>>>> 22: 0 0 0 0 GICv2 52 Edge = arm-pmu >>>>>> 23: 0 0 0 0 GICv2 53 Edge = arm-pmu >>>>>> 24: 0 0 0 0 GICv2 54 Edge = arm-pmu >>>>>> 25: 0 0 0 0 GICv2 55 Edge = arm-pmu >>>>>> 26: 0 0 0 0 GICv2 36 Edge >>>>>> 26202a0.keystone_irq >>>>>> 27: 1435 0 0 0 GICv2 309 Edge = ttyS0 >>>>>> 29: 0 0 0 0 GICv2 315 Edge >>>>>> 2530000.i2c >>>>>> 30: 1 0 0 0 GICv2 318 Edge >>>>>> 2530400.i2c >>>>>> 31: 0 0 0 0 GICv2 321 Edge >>>>>> 2530800.i2c >>>>>> 32: 69 0 0 0 GICv2 324 Edge >>>>>> 21000400.spi >>>>>> 33: 0 0 0 0 GICv2 328 Edge >>>>>> 21000600.spi >>>>>> 34: 0 0 0 0 GICv2 332 Edge >>>>>> 21000800.spi >>>>>> 70: 0 0 0 0 GICv2 417 Edge >>>>>> ks-pcie-error-irq >>>>>> 79: 0 0 0 0 PCI-MSI 0 Edge >>>>>> PCIe PME, aerdrv >>>>>> 88: 57 0 0 0 GICv2 80 Level >>>>>> hwqueue-528 >>>>>> 89: 57 0 0 0 GICv2 81 Level >>>>>> hwqueue-529 >>>>>> 90: 47 0 0 0 GICv2 82 Level >>>>>> hwqueue-530 >>>>>> 91: 41 0 0 0 GICv2 83 Level >>>>>> hwqueue-531 >>>>>> IPI0: 0 0 0 0 CPU wakeup interr= upts >>>>>> IPI1: 0 0 0 0 Timer broadcast i= nterrupts >>>>>> IPI2: 730 988 1058 937 Rescheduling inte= rrupts >>>>>> IPI3: 2 3 4 6 Function call int= errupts >>>>>> IPI4: 0 0 0 0 CPU stop interrup= ts >>>>>> IPI5: 0 0 0 0 IRQ work interrup= ts >>>>>> IPI6: 0 0 0 0 completion interr= upts >>>>>>=20 >>>>>> Xen dom0 (Ethernet stops) >>>>>> # cat /proc/interrupts >>>>>> CPU0 >>>>>> 18: 10380 GIC-0 27 Level arch_timer >>>>>> 19: 0 GIC-0 142 Edge timer-keystone >>>>>> 20: 88 GIC-0 16 Level events >>>>>> 21: 0 xen-dyn Edge -event xenbus >>>>>> 22: 0 GIC-0 36 Edge 26202a0.keystone_irq >>>>>> 23: 1 GIC-0 312 Edge ttyS0 >>>>>> 25: 1 GIC-0 318 Edge >>>>>> 27: 1 GIC-0 324 Edge 21000400.spi >>>>>> 28: 0 GIC-0 328 Edge 21000600.spi >>>>>> 29: 0 GIC-0 332 Edge 21000800.spi >>>>>> 65: 0 GIC-0 417 Edge ks-pcie-error-irq >>>>>> 74: 0 PCI-MSI 0 Edge PCIe PME, aerdrv >>>>>> 83: 1 GIC-0 80 Level hwqueue-528 >>>>>> 84: 1 GIC-0 81 Level hwqueue-529 >>>>>> 85: 1 GIC-0 82 Level hwqueue-530 >>>>>> 86: 1 GIC-0 83 Level hwqueue-531 >>>>>> 115: 87 xen-dyn Edge -virq hvc_console >>>>>> IPI0: 0 CPU wakeup interrupts >>>>>> IPI1: 0 Timer broadcast interrupts >>>>>> IPI2: 0 Rescheduling interrupts >>>>>> IPI3: 0 Function call interrupts >>>>>> IPI4: 0 CPU stop interrupts >>>>>> IPI5: 0 IRQ work interrupts >>>>>> IPI6: 0 completion interrupts >>>>>> Err: 0 >>>>> After getting a chance to look at this a little more, I believe the >>>>> TX/RX interrupts for the ethernets map like this: >>>>>=20 >>>>> eth0 Rx - hwqueue-528 >>>>> eth1 Rx - hwqueue-529 >>>>> eth0 Tx - hwqueue-530 >>>>> eth1 Tx - hwqueue-531 >>>>>>=20 >>>>> The interrupt counts in the standlone working kernel seem to roughly >>>>> correspond to the counts of Tx/Rx messages in ifconfig. Going on >>>>> that, its clear that only 1 interrupt has been received for Tx and 1 >>>>> for Rx in the Xen Dom0 equivalent. Any thoughts on this? >>>>=20 >>>> This definitely look like an interrupt acknowledgement issue. >>>> This could be caused by 2 things I remember of: >>>> - front vs level interrupts >>>> - a problem with forwarded interrupt acknowledgement. >>>> I think there was something related to that where the vcpu ack was not= properly >>>> handled on a keystone and I had to change the way the interrupt was ac= ked for >>>> forwarded hardware interrupts. >>=20 >> Is there maybe some sort of secondary interrupt controller (secondary in >> addition to the GIC) or interrupt "concentrator" on KeyStone? >>=20 >> Or is it just a small deviation from normal GIC behavior? From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:28:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:28:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigBE-0003HO-6z; Tue, 09 Jun 2020 15:28:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigBD-0003HH-2l for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:28:47 +0000 X-Inumbo-ID: e8a401d4-aa65-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x32a.google.com (unknown [2a00:1450:4864:20::32a]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e8a401d4-aa65-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 15:28:46 +0000 (UTC) Received: by mail-wm1-x32a.google.com with SMTP id l17so3252882wmj.0 for ; Tue, 09 Jun 2020 08:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=ZN+XytTMQNoilwIrkXqaYTN41eYENGKQWZOzk7IbbiE=; b=J12yODvUoWb2IfQVBIE8gWEsVUMKEQTbkr2NJJN97Zx1k/yLtc1lOFZKKiUMV1rHPN X7pqsVjcmNfJEhstDi2gzkikDRV3cTwOQhnFSmvP56z0FZd2dsHpBNCxp1UZ9GDpNXSy bLMDVoz26kPVHLyfzMhDUniDvYIoh0L+yz0eZm+HjUW88B/AaPHKOS34ppfKL13kNjMr x1X79yBf9XsMM/l/gAnqDJx4xUTBCGmIFSU+U0+Mpnqpw/14R68c9YcfUZ476CqkRUWZ vdILMmRAemXhDSPkz6r9TVG9L8U4WunT6LlT7MgP7l+lQacWekLoYk3Btj0qwm8lnx4N rM+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=ZN+XytTMQNoilwIrkXqaYTN41eYENGKQWZOzk7IbbiE=; b=bkURgdM2boqn8WXbWv6MMKX0/JDrieUwlbg/Yu5/4EKQMn2BaqeyT3hEnGgSJUMpzI VAnJ3jd+dQG/OkUmaEPjyK7zenq64OB9lrMFWHxddxCjFQT9PSydLlDf8vswe8METdzk KiFpHPhxeiC6FAtHyze8bKCuVA9IuGTKXWMmlWIoufjMBOtCp4QRB23vHxKUP7oF8VGZ XMxByAKci+FSQI7PT8e1LM7RuUAmNDCgqvkhlaT5O95ixnH4brWMkorUvEKNjv+zCKsd lWIQQHZNyb6K81wLZ/5TRhMN6ta3gzeq3Mi8TQRFT2W2CD1N+nCwH0IaZHQASFmUHNgx qjyQ== X-Gm-Message-State: AOAM531Mac9LlFCduWYaOMth7xwXZc4LSdjmDvuPG36IKKwlrc6I960x nPGkjqrGz48VU2/ovKjQkNk= X-Google-Smtp-Source: ABdhPJyTr4VWZpTkym6uhNxctOGlBxAwi4HUbv43y4tyldbdTmCWc76tAvS6v6mgKMbau4n6XsiJLg== X-Received: by 2002:a1c:5541:: with SMTP id j62mr4360417wmb.64.1591716525612; Tue, 09 Jun 2020 08:28:45 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id o6sm3205771wmc.39.2020.06.09.08.28.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 08:28:45 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <20200608094619.28336-1-paul@xen.org> <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> <002a01d63d84$9c351430$d49f3c90$@xen.org> <86e29001-4b33-de46-0675-0107a2e2b386@suse.com> In-Reply-To: <86e29001-4b33-de46-0675-0107a2e2b386@suse.com> Subject: RE: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction Date: Tue, 9 Jun 2020 16:28:43 +0100 Message-ID: <00c201d63e72$a9d28bb0$fd77a310$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQG4RzFDVM83uzCFIZn1YivdDmazZAHQan7RAPjCHYMCxrTPqKjf1PGw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Paul Durrant' , =?utf-8?Q?'Marek_Marczykowski-G=C3=B3recki'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 09 June 2020 16:08 > To: paul@xen.org > Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' = ; 'Marek Marczykowski-G=C3=B3recki' > > Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing = with ioreq server destruction >=20 > On 08.06.2020 13:04, Paul Durrant wrote: > >> From: Jan Beulich > >> Sent: 08 June 2020 11:58 > >> > >> On 08.06.2020 11:46, Paul Durrant wrote: > >>> --- a/xen/arch/x86/hvm/ioreq.c > >>> +++ b/xen/arch/x86/hvm/ioreq.c > >>> @@ -109,15 +109,7 @@ static void hvm_io_assist(struct = hvm_ioreq_vcpu *sv, uint64_t data) > >>> ioreq_t *ioreq =3D &v->arch.hvm.hvm_io.io_req; > >>> > >>> if ( hvm_ioreq_needs_completion(ioreq) ) > >>> - { > >>> - ioreq->state =3D STATE_IORESP_READY; > >>> ioreq->data =3D data; > >>> - } > >>> - else > >>> - ioreq->state =3D STATE_IOREQ_NONE; > >>> - > >>> - msix_write_completion(v); > >>> - vcpu_end_shutdown_deferral(v); > >>> > >>> sv->pending =3D false; > >>> } > >> > >> With this, is the function worth keeping at all? > > > > I did think about that, but it is called in more than one place. So, > > in the interest of trying to make back-porting straightforward, I > > thought it best to keep it simple. >=20 > Fair enough, but going forward I still think it would be nice to get > rid of the function. To do this sufficiently cleanly, the main > question I have is: Why is hvm_wait_for_io() implemented as a loop? I guess the idea is that it should tolerate the emulator kicking the = event channel spuriously. I don't know whether this was the case at one = time, but it seems reasonable to be robust against waking up from = wait_on_xen_event_channel() before state has made it to IORESP_READY. > Hasn't this become pointless with the XSA-262 fix? Switching this to > a do {} while(false) construct (seeing that the only caller has > already checked sv->pending) would look to allow moving what is now > in hvm_io_assist() immediately past this construct, at the expense > of a local variable holding ~0ul initially and then in the common > case p->data. That sounds ok. We can do that even with the current while loop by just = setting sv->pending to false when we see state =3D=3D IORESP_READY. = After the loop terminates then we can grab the result and set state back = to IOREQ_NONE. >=20 > Thoughts? (I'll be happy to make such a patch, I'm just checking > whether I'm overlooking something crucial.) >=20 Only that I don't think we should use do {} while(false) just in case of = early wakeup. Paul > Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:33:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:33:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigFZ-0004B7-PJ; Tue, 09 Jun 2020 15:33:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigFZ-0004B2-3h for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:33:17 +0000 X-Inumbo-ID: 8876a5b8-aa66-11ea-b335-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8876a5b8-aa66-11ea-b335-12813bfff9fa; Tue, 09 Jun 2020 15:33:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3529DAE35; Tue, 9 Jun 2020 15:33:17 +0000 (UTC) Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction To: paul@xen.org References: <20200608094619.28336-1-paul@xen.org> <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> <002a01d63d84$9c351430$d49f3c90$@xen.org> <86e29001-4b33-de46-0675-0107a2e2b386@suse.com> <00c201d63e72$a9d28bb0$fd77a310$@xen.org> From: Jan Beulich Message-ID: Date: Tue, 9 Jun 2020 17:33:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <00c201d63e72$a9d28bb0$fd77a310$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Paul Durrant' , =?UTF-8?Q?=27Marek_Marczykowski-G=c3=b3recki=27?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 09.06.2020 17:28, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 09 June 2020 16:08 >> To: paul@xen.org >> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ; 'Marek Marczykowski-Górecki' >> >> Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction >> >> On 08.06.2020 13:04, Paul Durrant wrote: >>>> From: Jan Beulich >>>> Sent: 08 June 2020 11:58 >>>> >>>> On 08.06.2020 11:46, Paul Durrant wrote: >>>>> --- a/xen/arch/x86/hvm/ioreq.c >>>>> +++ b/xen/arch/x86/hvm/ioreq.c >>>>> @@ -109,15 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data) >>>>> ioreq_t *ioreq = &v->arch.hvm.hvm_io.io_req; >>>>> >>>>> if ( hvm_ioreq_needs_completion(ioreq) ) >>>>> - { >>>>> - ioreq->state = STATE_IORESP_READY; >>>>> ioreq->data = data; >>>>> - } >>>>> - else >>>>> - ioreq->state = STATE_IOREQ_NONE; >>>>> - >>>>> - msix_write_completion(v); >>>>> - vcpu_end_shutdown_deferral(v); >>>>> >>>>> sv->pending = false; >>>>> } >>>> >>>> With this, is the function worth keeping at all? >>> >>> I did think about that, but it is called in more than one place. So, >>> in the interest of trying to make back-porting straightforward, I >>> thought it best to keep it simple. >> >> Fair enough, but going forward I still think it would be nice to get >> rid of the function. To do this sufficiently cleanly, the main >> question I have is: Why is hvm_wait_for_io() implemented as a loop? > > I guess the idea is that it should tolerate the emulator kicking the > event channel spuriously. I don't know whether this was the case at > one time, but it seems reasonable to be robust against waking up > from wait_on_xen_event_channel() before state has made it to > IORESP_READY. But such wakeup is taken care of by "goto recheck", not by the main loop in the function. Jan >> Hasn't this become pointless with the XSA-262 fix? Switching this to >> a do {} while(false) construct (seeing that the only caller has >> already checked sv->pending) would look to allow moving what is now >> in hvm_io_assist() immediately past this construct, at the expense >> of a local variable holding ~0ul initially and then in the common >> case p->data. > > That sounds ok. We can do that even with the current while loop by just setting sv->pending to false when we see state == IORESP_READY. After the loop terminates then we can grab the result and set state back to IOREQ_NONE. > >> >> Thoughts? (I'll be happy to make such a patch, I'm just checking >> whether I'm overlooking something crucial.) >> > > Only that I don't think we should use do {} while(false) just in case of early wakeup. > > Paul > >> Jan > From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:38:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:38:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigKq-0004OR-Dl; Tue, 09 Jun 2020 15:38:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigKp-0004OM-6d for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:38:43 +0000 X-Inumbo-ID: 4c0cb4c2-aa67-11ea-bca7-bc764e2007e4 Received: from mail-wm1-f67.google.com (unknown [209.85.128.67]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4c0cb4c2-aa67-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 15:38:42 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id d128so3632429wmc.1 for ; Tue, 09 Jun 2020 08:38:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ucWmNLkNFPUVczPToRcxFSCi5MdBM/Nvj/6rGX8RCBY=; b=mcxSYc3Wk3bZVYJUc/cT5GO/8PyyoT28fL2xxuXduz2GFFb7Qmsr2ySrnRxHcvi30i aOFdnZlaTDQawIhu33lf22C/fcIbOPcwDE0oMsoRXA3UF5W4GYDVZe5+Pa1EJVjMfiOe J9jQTmj9hwj/5cTFVR/PZUkhKKiCFFPkn565+3P57ZyLWEsQKWdT+UC+ZK8Fgpuj6gfR rksyw4Lvj/clxg6y+GMFS9hkoEjkVCXHRgBBxlmpJk/uaQ9Rg/GzS1cRq9SueDzSg9xI +0xNUtFYy7/ZY7VT04kyHlusHHjt6aFYvblKcQuRggeIBubMp1xtD3jQ+1q1HUFIbhvF ZMmw== X-Gm-Message-State: AOAM530MviglN62D2vkw6fwPb6PzyAv2gTQu2zYWigB6SewvNAthIUo+ C+Ag/sGz6ZAcMmxZe9gPIrM= X-Google-Smtp-Source: ABdhPJz/HlOOdmjVI4U4/A2Va2+pJ3mjkVlJ9ANwsBeF91ZZlFya6wut+JqkSIPlG0S8iyDk4nm5Sg== X-Received: by 2002:a1c:67c3:: with SMTP id b186mr4397783wmc.167.1591717121844; Tue, 09 Jun 2020 08:38:41 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id s72sm3165939wme.35.2020.06.09.08.38.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jun 2020 08:38:40 -0700 (PDT) Date: Tue, 9 Jun 2020 15:38:39 +0000 From: Wei Liu To: Juergen Gross Subject: Re: [PATCH for-4.14 0/2] tools: two minor fixes for libxenhypfs Message-ID: <20200609153839.wjqpremfgirxdoj3@liuwe-devbox-debian-v2> References: <20200609144850.28619-1-jgross@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200609144850.28619-1-jgross@suse.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Ian Jackson , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 09, 2020 at 04:48:48PM +0200, Juergen Gross wrote: > Two fixes for libxenhypfs: > > - xenhypfs terminating with segfault when hypervisor doesn't have > hypfs support > - wrong error reporting in case for access errors with xenhypfs > > Juergen Gross (2): > tools: fix error path of xenhypfs_open() > tools: fix setting of errno in xenhypfs_read_raw() Applied. I also added Fixes tags to them. Wei. > > tools/libs/hypfs/core.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > -- > 2.26.2 > From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:46:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:46:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigRk-0005GT-8C; Tue, 09 Jun 2020 15:45:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigRi-0005GO-Uk for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:45:50 +0000 X-Inumbo-ID: 4add515a-aa68-11ea-b339-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4add515a-aa68-11ea-b339-12813bfff9fa; Tue, 09 Jun 2020 15:45:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 83301AC5B; Tue, 9 Jun 2020 15:45:52 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org Subject: [PATCH for-4.14] xen/hypfs: fix loglvl parameter setting Date: Tue, 9 Jun 2020 17:45:46 +0200 Message-Id: <20200609154546.4531-1-jgross@suse.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Writing the runtime parameters loglvl or guest_loglvl omits setting the new length of the resulting parameter value. Reported-by: George Dunlap Signed-off-by: Juergen Gross --- xen/drivers/char/console.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c index 56e24821b2..861ad53a8f 100644 --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -241,14 +241,25 @@ static int _parse_loglvl(const char *s, int *lower, int *upper, char *val) static int parse_loglvl(const char *s) { - return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh, - xenlog_val); + int ret; + + ret = _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh, + xenlog_val); + custom_runtime_set_var(param_2_parfs(parse_loglvl), xenlog_val); + + return ret; } static int parse_guest_loglvl(const char *s) { - return _parse_loglvl(s, &xenlog_guest_lower_thresh, - &xenlog_guest_upper_thresh, xenlog_guest_val); + int ret; + + ret = _parse_loglvl(s, &xenlog_guest_lower_thresh, + &xenlog_guest_upper_thresh, xenlog_guest_val); + custom_runtime_set_var(param_2_parfs(parse_guest_loglvl), + xenlog_guest_val); + + return ret; } static char *loglvl_str(int lvl) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:47:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:47:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigTg-0005Ot-KO; Tue, 09 Jun 2020 15:47:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigTe-0005Om-Nm for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:47:50 +0000 X-Inumbo-ID: 9231ae3e-aa68-11ea-b339-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9231ae3e-aa68-11ea-b339-12813bfff9fa; Tue, 09 Jun 2020 15:47:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=knUPWeEHpKkGT/n+B/uvklakdHQkghzNXzeHLXijbDg=; b=sjfp+Wi90YW819JgWkcmBk/neQ 2Pwm8+K5NehwqXWprRAd8/9vISzCU0IEgV2RYAc7qBVkAewoe42RlE4rjZFE2yEmmXUUTEghRWoUO e6Bvv3lIBXuCgSjzPrRoWTkVrf9dFAhIHu8V+WB9SqLGvzxOzmI62YUU5SStk3mkdnF0=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jigTd-00028Q-5C; Tue, 09 Jun 2020 15:47:49 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jigTc-0005sM-Us; Tue, 09 Jun 2020 15:47:49 +0000 Subject: Re: Keystone Issue To: Bertrand Marquis , CodeWiz2280 References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> From: Julien Grall Message-ID: Date: Tue, 9 Jun 2020 16:47:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 09/06/2020 16:28, Bertrand Marquis wrote: > Hi, > >> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >> >> There does appear to be a secondary (CIC) controller that can forward >> events to the GIC-400 and EDMA controllers for the keystone 2 family. >> Admittedly, i'm not sure how it is being used with regards to the >> peripherals. I only see mention of the GIC-400 parent for the devices >> in the device tree. Maybe Bertrand has a better idea on whether any >> peripherals go through the CIC first? I see that gic_interrupt () >> fires once in Xen, which calls doIRQ to push out the virtual interrupt >> to the dom0 kernel. The dom0 kernel then handles the interrupt and >> returns, but gic_interrupt() never fires again in Xen. > > I do not remember of any CIC but the behaviour definitely look like an interrupt acknowledge problem. > > Could you try the following: > --- a/xen/arch/arm/gic-v2.c > +++ b/xen/arch/arm/gic-v2.c > @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc *desc) > /* Lower the priority of the IRQ */ > gicv2_eoi_irq(desc); > /* Deactivation happens in maintenance interrupt / via GICV */ > + > + /* Test for Keystone2 */ > + gicv2_dir_irq(desc); > } > > I think the problem I had was related to the vgic not deactivating properly the interrupt. Are you suggesting the guest EOI is not properly forwarded to the hardware when LR.HW is set? If so, this could possibly be workaround in Xen by raising a maintenance interrupt every time a guest EOI an interrupt. > This might make the interrupt fire indefinitely !! Most likely with level interrupt ;). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 09 15:58:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 15:58:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jige5-0006OD-Jm; Tue, 09 Jun 2020 15:58:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jige4-0006O8-71 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 15:58:36 +0000 X-Inumbo-ID: 12fbacda-aa6a-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 12fbacda-aa6a-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 15:58:35 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id n24so22972182ejd.0 for ; Tue, 09 Jun 2020 08:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zbJp1IWgUH+VQ3z/5e5brV6qZNHhJIyjJ89HzS4+g2c=; b=ljK+SUc4DoMD1Sc6xR8WXmbSK25X6EQPiWkzE1LoCnWsqaooFV7Ue/wQwvI2IisTjp +Mrf0amFwoCYRhyxjNwEcMVAyzXI9LsMQ3h/9Nl28uKo48ov5+PBpBEEDPpTkthw00Ql wihMWMClTQgGCvnkZHCQg5gZ71MtL2TlVJe77vAxh8zCCmqf7Mq/BS0mzBex9X4TIoJ9 buRhVZhFWb9T5cSt7MC/Z+B4kb+8B4gAlDLE7QrY/kqj7uI3AfjGNlaYYatpGe+7T389 hJItrysX0+MvYkQEVz9QtUP3yWZEs7WnZmkaPZdb6D1CJa9Yzwr9lZqqJyQE5zw/pnoI w4UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zbJp1IWgUH+VQ3z/5e5brV6qZNHhJIyjJ89HzS4+g2c=; b=VqBCpWkENu19id+C2C5Rb8GssW2JsmkCKPyJcCfzeA52tQ5AtLJh/GPaUCLkaKXcco 0GlL+2fKxS/6cPWzsTOrMbP0Wzs/uw8WxRoewwuTnU8RSYFurdDShqJlZbhsfMDAvLU4 NWcOzTjy9ZwLGFEv6F4pwYRk4YzaRY1d9Rp7S6CM7RQQnUvKkD9J2jADMon7EPlDlc3B b6KxQZcUz15HCVRdfANCPgeK6dBQbVNXh1Ml+vu5XlxUjxw4ANDnuj1N8BOim4DPxe6h /6EP6PW36cbtuOMFI/ozxO3wz+SdbPUg8shXLNztluQqQdjr9hNelS90c9WcGmYC2K2x dBpA== X-Gm-Message-State: AOAM530m0s3aI1WwR21CoAMPqkC2SNTp7Gyac64fFddz2DtVlQ+CvrTs 62ON9rzNxXTXG7bXZMsgoiMbK39b+FuS42vfXmA= X-Google-Smtp-Source: ABdhPJzAMb5BIQMYiTuFT/I3iN4kafpFGOxbbPoBWi2FsA2/oP3wEvVKLacbG9TuC/7JkJEZexCs1GAn8HFunOsfw3A= X-Received: by 2002:a17:906:5785:: with SMTP id k5mr25551813ejq.494.1591718314562; Tue, 09 Jun 2020 08:58:34 -0700 (PDT) MIME-Version: 1.0 References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> In-Reply-To: From: CodeWiz2280 Date: Tue, 9 Jun 2020 11:58:21 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 9, 2020 at 11:47 AM Julien Grall wrote: > > > > On 09/06/2020 16:28, Bertrand Marquis wrote: > > Hi, > > > >> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: > >> > >> There does appear to be a secondary (CIC) controller that can forward > >> events to the GIC-400 and EDMA controllers for the keystone 2 family. > >> Admittedly, i'm not sure how it is being used with regards to the > >> peripherals. I only see mention of the GIC-400 parent for the devices > >> in the device tree. Maybe Bertrand has a better idea on whether any > >> peripherals go through the CIC first? I see that gic_interrupt () > >> fires once in Xen, which calls doIRQ to push out the virtual interrupt > >> to the dom0 kernel. The dom0 kernel then handles the interrupt and > >> returns, but gic_interrupt() never fires again in Xen. > > > > I do not remember of any CIC but the behaviour definitely look like an interrupt acknowledge problem. > > > > Could you try the following: > > --- a/xen/arch/arm/gic-v2.c > > +++ b/xen/arch/arm/gic-v2.c > > @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc *desc) > > /* Lower the priority of the IRQ */ > > gicv2_eoi_irq(desc); > > /* Deactivation happens in maintenance interrupt / via GICV */ > > + > > + /* Test for Keystone2 */ > > + gicv2_dir_irq(desc); > > } > > > > I think the problem I had was related to the vgic not deactivating properly the interrupt. > This seemed to help with the edge triggered interrupts, e.g. UART > Are you suggesting the guest EOI is not properly forwarded to the > hardware when LR.HW is set? If so, this could possibly be workaround in > Xen by raising a maintenance interrupt every time a guest EOI an interrupt. > > > This might make the interrupt fire indefinitely !! > > Most likely with level interrupt ;). > This is what's happening with the Ethernet driver which is level triggered. I had to temporarily disable it to check the patch with the UART driver, otherwise the system would hang processing the interrupt repeatedly. > Cheers, > > -- > Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 09 16:29:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 16:29:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jih7x-0001AA-5o; Tue, 09 Jun 2020 16:29:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jih7v-00019z-R6 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 16:29:27 +0000 X-Inumbo-ID: 62d5c4da-aa6e-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 62d5c4da-aa6e-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 16:29:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=FxzKaqjwqHv+BWtl18dHoTgwvh6fvBsKBrSkPMFtPTU=; b=x5heI+/OXIZeaoQjNx9ahJVdA7 kKedph6R+iOhV4bySY2aL2hCMIOktUmG4n5YhKjkwb1to5P/oQHdWQfiH5t0A0PILk5pA/0ar3l8C Xh4Xkrd96aOI6wBFd3nC7sYjPJjtTvJnvAeGuiFj+fuuYDDXOfE9JCqcjp7QWrBznQIY=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jih7u-0003Vt-O1; Tue, 09 Jun 2020 16:29:26 +0000 Received: from [54.239.6.185] (helo=CBG-R90WXYV0.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jih7u-0003N4-Dx; Tue, 09 Jun 2020 16:29:26 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 0/2] CHANGELOG additions Date: Tue, 9 Jun 2020 17:29:20 +0100 Message-Id: <20200609162922.14679-1-paul@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Paul Durrant Paul Durrant (2): CHANGELOG: add 'domid_policy' and domid preservation on migrate CHANGELOG: add revised kdd handshake (supporting Windows 7, 8, and 10) CHANGELOG.md | 3 +++ 1 file changed, 3 insertions(+) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 16:29:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 16:29:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jih81-0001Af-LE; Tue, 09 Jun 2020 16:29:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jih80-00019z-Ke for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 16:29:32 +0000 X-Inumbo-ID: 64b1e3b0-aa6e-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 64b1e3b0-aa6e-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 16:29:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CFfR8OPlKnnlTFL8namRQAlsqp9E0KgFPJ1Ttff1kYg=; b=Y7AjTfYl+205kCb99lwmI4Xsl8 uWp62PQZ2antftiVrdy37WpIvELgo5pE/YXhKxcDTGfTsx75hLIwraA+v6f5ARJnOnSqitkWBzOf4 O0h2ykRrfquM6Yol5LmiOmIT5uWwlm2NhxNAdV8xOZcZ67ExyMGw9pvuM2zgV2U3h9+Y=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jih7w-0003W1-MX; Tue, 09 Jun 2020 16:29:28 +0000 Received: from [54.239.6.185] (helo=CBG-R90WXYV0.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jih7w-0003N4-Bh; Tue, 09 Jun 2020 16:29:28 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 2/2] CHANGELOG: add revised kdd handshake (supporting Windows 7, 8, and 10) Date: Tue, 9 Jun 2020 17:29:22 +0100 Message-Id: <20200609162922.14679-3-paul@xen.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200609162922.14679-1-paul@xen.org> References: <20200609162922.14679-1-paul@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Community Manager , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Paul Durrant Signed-off-by: Paul Durrant -- Cc: Community Manager --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index cb1566ea5b..43fd260156 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -20,6 +20,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - libxl support for running qemu-xen device model in a linux stubdomain. - New 'domid_policy', allowing domain-ids to be randomly chosen. - Option to preserve domain-id across migrate or save+restore. + - Support in kdd for initial KD protocol handshake for Win 7, 8 and 10 (64 bit). ## [4.13.0](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.13.0) - 2019-12-17 -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 16:29:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 16:29:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jih80-0001AN-DN; Tue, 09 Jun 2020 16:29:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jih7y-0001AG-NQ for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 16:29:30 +0000 X-Inumbo-ID: 63a4ea08-aa6e-11ea-b33d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 63a4ea08-aa6e-11ea-b33d-12813bfff9fa; Tue, 09 Jun 2020 16:29:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=StNDX8utJEcCGoq3Fv0On8l7NyjDJ1rRRdFjlc8H5Oo=; b=0C7PLJdUmzmJaKbfJwcqULq5hN zJqDO23MbXjEblVW024d5sOB3JvqaECqi/c6lwv/fZmHELhhWqdMu5C/EEBmeCnlsQAQuBLlkk4UW NKTUCUAfs/vvbwE3MGYgP7+jtZmKJ8NHdv1Uk4RdQzQwRppelxyHeoW7dxS0M6Bzx43M=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jih7v-0003Vx-M7; Tue, 09 Jun 2020 16:29:27 +0000 Received: from [54.239.6.185] (helo=CBG-R90WXYV0.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jih7v-0003N4-Bj; Tue, 09 Jun 2020 16:29:27 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org Subject: [PATCH-for-4.14 1/2] CHANGELOG: add 'domid_policy' and domid preservation on migrate Date: Tue, 9 Jun 2020 17:29:21 +0100 Message-Id: <20200609162922.14679-2-paul@xen.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200609162922.14679-1-paul@xen.org> References: <20200609162922.14679-1-paul@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Community Manager , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Paul Durrant Signed-off-by: Paul Durrant --- Cc: Community Manager --- CHANGELOG.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 8786c51cb4..cb1566ea5b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -18,6 +18,8 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - Initial support to run on Hyper-V. - Initial hypervisor file system (hypfs) support. - libxl support for running qemu-xen device model in a linux stubdomain. + - New 'domid_policy', allowing domain-ids to be randomly chosen. + - Option to preserve domain-id across migrate or save+restore. ## [4.13.0](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.13.0) - 2019-12-17 -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 16:36:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 16:36:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihEC-00029w-Bb; Tue, 09 Jun 2020 16:35:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihEA-00029r-Q3 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 16:35:54 +0000 X-Inumbo-ID: 49a3489c-aa6f-11ea-8496-bc764e2007e4 Received: from mail-io1-xd43.google.com (unknown [2607:f8b0:4864:20::d43]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 49a3489c-aa6f-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 16:35:54 +0000 (UTC) Received: by mail-io1-xd43.google.com with SMTP id q8so23459326iow.7 for ; Tue, 09 Jun 2020 09:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=dDmpwfxSB7xq+nl+xf69iWKoal8j+zfpCNakAwwcUgc=; b=sNZwBXv00cxskE5SIHqXQw6g4j1XBMeSJQsN28+4r7vzGHcc9X+/tJQwB7dLM7cmK7 uHA+Qy9pghOn+pZYfrVcimJJCUKaM/Ti2tSTsB4iwq4otl9ibsq0ckrapQFIeFnM9Qao uf/2YZ6M9Qy6P7lhM7XvdmQGTGOEPV3wtjnOuyEiyrERMmp9NbaKyDlIr+LCqJvbETDH JzWsfYESprzGB1D95Z5/M1IK+tDqPlNL6GiRJKEp8CcysxAg6TOGqj2uUf7sTg9EIs4o 7NWTb3vbsUifOw62UgJcZ2iXsIlsOLunmjuW4zTFK7TbiwtQ6VxugsEdT5UFP8yfT7d5 R5qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=dDmpwfxSB7xq+nl+xf69iWKoal8j+zfpCNakAwwcUgc=; b=Dsl+/kxaYGRR3U8YUa1k36D3EialiPtypnjE0POc3XE5PL0zXPo1GwAnqr6cfHRcV6 BVRxKzE6Hb5nW+KWP/ui25DpcWqZ65ssr9TiRQo6QFu5obkxj2a3x7s6PoyirPaPigKr VqtJODBFCnWMf7A5mwjG1ddXZYxDpb/2oSmeEfTIugpEmIlqA92fo1jLTa6HwnqS8qGP EJRT4emgqI8aiPrwyDueeWHhM/WcOMjgJtaU/yPUBZjCUTZGQDEmCHMVFL51dIFhPplc 2FtYXHUJKzTWRfjWpzwn5GBgBns5FIc9Stlb6dQeHaKm+HFzd1ePY8kwcIfS3k0es446 jhyg== X-Gm-Message-State: AOAM533jop3MpUVhi7A4uSjscN+fN6FTHV8Eb1O/6VqsC25Px4uMfK/0 D1iFy8+QT6FpDQwfdVVrRtQ= X-Google-Smtp-Source: ABdhPJyKCI/p/AACig2mOdVXBRSKvBBIJOzuzKETn/UHazI9mMMgjgd+Q6oKsPXCKqLOwX0qtZaj8A== X-Received: by 2002:a6b:e714:: with SMTP id b20mr28249467ioh.195.1591720553712; Tue, 09 Jun 2020 09:35:53 -0700 (PDT) Received: from [100.64.72.28] ([173.245.215.240]) by smtp.gmail.com with ESMTPSA id a10sm9617754ilb.31.2020.06.09.09.35.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 09:35:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Rich Persaud Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v1] tools: fix usage of strncpy Date: Tue, 9 Jun 2020 12:35:51 -0400 Message-Id: References: <20200608161111.26c2cdd4.olaf@aepfle.de> In-Reply-To: <20200608161111.26c2cdd4.olaf@aepfle.de> To: Olaf Hering X-Mailer: iPhone Mail (17F75) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jason Andryuk , =?utf-8?Q?Marek_Marczykowski-G=C3=B3recki?= , xen-devel , Anthony PERARD , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Jun 8, 2020, at 10:12, Olaf Hering wrote: >=20 > =EF=BB=BFAm Mon, 8 Jun 2020 08:43:50 -0400 > schrieb Jason Andryuk : >=20 >> I added a length check in this patch: >=20 > gcc will not recognize such runtime checks and will (most likely) complain= about the strncpy usage anyway, just as it does now in libxl__prepare_socka= ddr_un. While the usage in libxl__prepare_sockaddr_un is fatal due to -Werro= r, libvchan is apparently built without -Werror. >=20 > Olaf Is there any reason not to take a patch that builds libvchan with -Werror? Rich= From xen-devel-bounces@lists.xenproject.org Tue Jun 09 16:41:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 16:41:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihJP-00031g-Vj; Tue, 09 Jun 2020 16:41:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihJO-00031b-O9 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 16:41:19 +0000 X-Inumbo-ID: 05e61e59-aa70-11ea-b33f-12813bfff9fa Received: from mo4-p01-ob.smtp.rzone.de (unknown [81.169.146.165]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 05e61e59-aa70-11ea-b33f-12813bfff9fa; Tue, 09 Jun 2020 16:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591720871; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=rCph44Qv+8B3A8r8KBGK8gj6BdfkmD4uvC3nxBG6swg=; b=ijRTWbUCaTdWdwNqSR6p5xDZk0TPx1w4VsDfUz/e8Nw7C2T1NIsaPWlulYaoHbH2rF 8Tb1FqFJFvfZyZcqnjgtrPIcZeFiTqBR51oBfT/gSRHWLLfgeKbqwujrG1w1gxtokPiE zrziWMZplAhreOZm15nUvoG7qowHXdXs1wU3/d1vSaqkUUWMh7XR8jW3+3x4YOcmkGba P8uArZfoF1N1QK5Ts5UNLzOr01sTr+AQRfpBknKHrpnvqTOH2MWN/eKtY6cDeBYi8WtZ M8yA7Xy8In8z9MpotmqUOcK35pc0LQTkW6Xt5YJKWKJvrSVH035BSsOnLVLsO0SG1kSY WQYQ== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.9.2 DYNA|AUTH) with ESMTPSA id I09bd2w59Gf7Lds (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 9 Jun 2020 18:41:07 +0200 (CEST) Date: Tue, 9 Jun 2020 18:41:05 +0200 From: Olaf Hering To: Rich Persaud Subject: Re: [PATCH v1] tools: fix usage of strncpy Message-ID: <20200609184105.01ea9b12.olaf@aepfle.de> In-Reply-To: References: <20200608161111.26c2cdd4.olaf@aepfle.de> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/6RsHom6v_0zYFSK4tN5xo/J"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jason Andryuk , Marek =?UTF-8?B?TWFyY3p5a293c2tpLUfDs3JlY2tp?= , xen-devel , Anthony PERARD , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/6RsHom6v_0zYFSK4tN5xo/J Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Tue, 9 Jun 2020 12:35:51 -0400 schrieb Rich Persaud : > Is there any reason not to take a patch that builds libvchan with -Werror? The per-subdirectory settings of -Werror should probably become a global -W= error. Someone has to step up and explore that path. Bonus points if -Werror could be disabled via configure. Olaf --Sig_/6RsHom6v_0zYFSK4tN5xo/J Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7fu6EACgkQ86SN7mm1 DoBoXA/+LSYk2/sq2Mhh07orSQKklACKgKhFlIQSXWr+ZkNKXZ0WqgBr1bP6VkL9 FEAW9rfP+WSD0KhnsOAX6XA2R1Ox51Y/HutjQcu4eIAaVLXP0N3rknb2ECaOXdIk V1kJ0fLjEOuhlur9GifLaqUv9W+k0Ifi9+bUcSQAahtvl2fSEAqW1ckazGA8kWFm BtivVoeH7HKjaR3ay3bVveWQkF/kz3osC332/oDRfbcGDaVn+1bTgqa/lDbt5qZF iyqRkJsu9jglPV9YcNwfhoFOSe9WhObngELYy6Xx9e+vrYj7y3MlmQjW3l6yzGqe XkAj+kllSH2m22FLDvqoSWHJGY/3RDX6aE6QhANjYk5m/UWmMiFUVJqfVQmGnmMu Q4SKsIGco+hJOXTNBd2Mpz2THnxcDUYQdamP2vwWkBC3mBcEafiFa5gqv/ckgoj9 HMK5ZZCTj3QhJn/JYsnO8cGsuvMHfYcl8suHMmg2ft6XFiAvvMuMwRLTElHar8zy eF1Y0T+AjD0DCwJadfUFQxn8wiUFX/cp+IpPeZw5vdMTytBvj4DGHYFbagfacxaN Itq052x0Co4tgVflHcaLiniBZvK8iHWiHUOup/KO6gL/fHQvs2btBKfLeepzZh8k tg88gDp9cptA4xA5BPUse06jN/HPxBdRsbQOvzUVGn+WBRF7QC4= =qzZI -----END PGP SIGNATURE----- --Sig_/6RsHom6v_0zYFSK4tN5xo/J-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 16:44:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 16:44:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihMh-0003Au-Fb; Tue, 09 Jun 2020 16:44:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihMg-0003Ao-Ho for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 16:44:42 +0000 X-Inumbo-ID: 83e09a7c-aa70-11ea-bca7-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 83e09a7c-aa70-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 16:44:41 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 7uBIuLbKvPFUYQnstSiXxU9/CdaBgJodt5M046qoF1Hxy0lIfXcl2In3N/uYHWyIBel+mAc6bF 2CRmHj0Z/j+5ClvvDp3H2dMx0iCxgmDPXROpQMP0OUczyzbD9p9kKKOAVi8WPKvBaxEpw11xam GiaYDeWJNkgfEc/Rl8LpiTvVYz5yfIZcF3yeTD0DMi5jyqKyhoIwW3JNfWGghmohTKEtHacgm6 SJHsFmjwQ+835iWWWpbTed937G0/IA7pr2eCA0aB7Kyc+N+FdBZojbQFKVLRlVZCmllOxXokZp AiM= X-SBRS: 2.7 X-MesageID: 19599142 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,492,1583211600"; d="scan'208";a="19599142" From: George Dunlap To: Xen-devel Subject: [TESTDAY] xl restore gives an error too soon after xl save Thread-Topic: [TESTDAY] xl restore gives an error too soon after xl save Thread-Index: AQHWPn1DWNbZ6w270UycYgt4Xt7XxQ== Date: Tue, 9 Jun 2020 16:44:37 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , Ian Jackson , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Somewhat surprising that if you save with -D, you get mysterious error mess= ages for the next so-many seconds: root@immortal:/images# xl save -D c6-01 /images/tmp/c6-01.save Saving to /images/tmp/c6-01.save new xl format (info 0x3/0x0/950) xc: info: Saving domain 19505, type x86 PV xc: Frames: 524288/524288 100% xc: End of stream: 0/0 0% root@immortal:/images# xl restore tmp/c6-01.save Loading new save file tmp/c6-01.save (new xl fmt info 0x3/0x0/950) Savefile contains xl domain config in JSON format Parsing config from libxl: error: libxl_create.c:692:libxl__domain_make: Domain 19505:domain id= recently used: No such file or directory libxl: error: libxl_create.c:1233:initiate_domain_create: Domain 19505:cann= ot make domain: -3 libxl: error: libxl_domain.c:1182:libxl__destroy_domid: Domain 19505:Non-ex= istant domain libxl: error: libxl_domain.c:1136:domain_destroy_callback: Domain 19505:Una= ble to destroy guest libxl: error: libxl_domain.c:1063:domain_destroy_cb: Domain 19505:Destructi= on of domain failed root@immortal:/images# xl restore tmp/c6-01.save Loading new save file tmp/c6-01.save (new xl fmt info 0x3/0x0/950) Savefile contains xl domain config in JSON format Parsing config from libxl: error: libxl_create.c:692:libxl__domain_make: Domain 19505:domain id= recently used: No such file or directory libxl: error: libxl_create.c:1233:initiate_domain_create: Domain 19505:cann= ot make domain: -3 libxl: error: libxl_domain.c:1182:libxl__destroy_domid: Domain 19505:Non-ex= istant domain libxl: error: libxl_domain.c:1136:domain_destroy_callback: Domain 19505:Una= ble to destroy guest libxl: error: libxl_domain.c:1063:domain_destroy_cb: Domain 19505:Destructi= on of domain failed [A few minutes pass] root@immortal:/images# xl restore tmp/c6-01.save Loading new save file tmp/c6-01.save (new xl fmt info 0x3/0x0/950) Savefile contains xl domain config in JSON format Parsing config from xc: info: Found x86 PV domain from Xen 4.14 xc: info: Restoring domain xc: info: Restore successful xc: info: XenStore: mfn 0xbe8d2, dom 0, evt 1 xc: info: Console: mfn 0xbe8d1, dom 0, evt 2= From xen-devel-bounces@lists.xenproject.org Tue Jun 09 16:45:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 16:45:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihNj-0003Fs-QX; Tue, 09 Jun 2020 16:45:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihNi-0003Fk-FX for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 16:45:46 +0000 X-Inumbo-ID: a9fd6ec4-aa70-11ea-8496-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a9fd6ec4-aa70-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 16:45:45 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: QKamtPoNHOhBhJ7Xo2Nx/xIPBY9nfLZqxVb32amsg7DUOtIdBBMlUJqfqge9tUs8P4OxVrhnmL EOCt3wKO6cLzuiTDe7CJkg6pVa5Ptn03Wo/T5fliWsNuRdotNZY1iQQ0o1OgKME2Vpx7S5BjT+ JI2qfZpS8N7WbyK1ndMDToa9Q04TtpeMDV5XQIqY9FacbfblgiKDi9rK4A9TG+HSYFYoExvUk2 VsD+0OOE3F1dB+bp7TEHcZ4pQ3zGsqXEpoJvMHe7b52IMPgFE/KIDS9V3XyCpTM2FGKbD0nzxm eY8= X-SBRS: 2.7 X-MesageID: 19841376 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,492,1583211600"; d="scan'208";a="19841376" From: George Dunlap To: Paul Durrant Subject: Re: [PATCH-for-4.14 1/2] CHANGELOG: add 'domid_policy' and domid preservation on migrate Thread-Topic: [PATCH-for-4.14 1/2] CHANGELOG: add 'domid_policy' and domid preservation on migrate Thread-Index: AQHWPnsm5KVtEHlQbU2q3x4wLSCVdqjQXFYA Date: Tue, 9 Jun 2020 16:45:41 +0000 Message-ID: <12AA7966-F395-4624-85DA-9D443B1269FC@citrix.com> References: <20200609162922.14679-1-paul@xen.org> <20200609162922.14679-2-paul@xen.org> In-Reply-To: <20200609162922.14679-2-paul@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-ID: <76998D5DEB5D544C91A3BEE14BA7A508@citrix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Community Manager , Xen-devel , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On Jun 9, 2020, at 5:29 PM, Paul Durrant wrote: >=20 > From: Paul Durrant >=20 > Signed-off-by: Paul Durrant Both patches: Acked-by: George Dunlap From xen-devel-bounces@lists.xenproject.org Tue Jun 09 16:56:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 16:56:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihXn-0004Ew-6F; Tue, 09 Jun 2020 16:56:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihXm-0004Ep-Ht for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 16:56:10 +0000 X-Inumbo-ID: 1dfe69d0-aa72-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x42a.google.com (unknown [2a00:1450:4864:20::42a]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1dfe69d0-aa72-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 16:56:09 +0000 (UTC) Received: by mail-wr1-x42a.google.com with SMTP id p5so22099945wrw.9 for ; Tue, 09 Jun 2020 09:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=+jVS7nVhGMmjR2wZd6JnAyCPYfj4Qx6JkWv06lXyIXU=; b=SAqnV5iZiBHXALRNyS2MYrJxxysK7xa+3roh7XPXvDQZ2dYxbkOw9q5Px07Wou2ne5 5gg/AANUVLKTx7eG0qqR4AEm/GzrCnzSQExXKv1EhARIs4hvK1NhFxwGRxJU3Ien8Wld BzlXMo0GVL4uRCV+xgcNS0BQFJ5ZEt1UmzJ9JzPb/9Z2g13kuilfnOKWo25EuytQXejS 0Kq9cLXX08hNDUb7iQ1Saabj2CZZLCiaodfJhYx4/ISLMJN7B6Yz1T3+AW6hWjhwyGHm Ipnr7p1ipLtiGUPBBMXabJASIZPROsrZLXYw0egN0GA1NDUMVZvjBuq7BYI9snNAW70o ESXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=+jVS7nVhGMmjR2wZd6JnAyCPYfj4Qx6JkWv06lXyIXU=; b=jioy0ri3VaohMk9cHaEsX10RWvoo3Zb/lEz3rU7mzXpQnxUbqlT6eVxZ4wcwlxkNUs ABvmULsIjLmguCLZdgqwy+XAzqrMdAVO7mDZDsUkRjRzlbSxCvUuRhGlZ21wZDWWhkTP xjiN5Aa81olSAScnsd5G3Eenn02/PULbqE/h5Y3QHk4uQI9YP4EK0fh/b2rSNbI3Up+L yycylq+EnGMpB6M7HwL4PlSFvo2UniYlwyXG5jQ7TITO5gL+c+jdPHSqj+2xY3pzBYUM vQwAiAOMQ90oGa79bAg9jpKJy91L+e7Zy8ZB/406RxgcI0lgcTOyqHkB2aoHAUadcHc2 XAWw== X-Gm-Message-State: AOAM5331wKNQAzZE+b4XpweRSjjSX2DKPSo6cgfcrqUZIuwf39LRJtr7 /7R3+Yv1N8JUu+a5oKjCf54= X-Google-Smtp-Source: ABdhPJw6q+vyrWjd1QpjmsIjW8fT1b4UmM2He3Oq8ali+vtJ9/uAng0/xGkJliIz2BVoXMZkL2vC9A== X-Received: by 2002:adf:b348:: with SMTP id k8mr6033250wrd.157.1591721769098; Tue, 09 Jun 2020 09:56:09 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id r5sm4234675wrq.0.2020.06.09.09.56.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 09:56:08 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'George Dunlap'" , "'Xen-devel'" References: In-Reply-To: Subject: RE: [TESTDAY] xl restore gives an error too soon after xl save Date: Tue, 9 Jun 2020 17:56:06 +0100 Message-ID: <00d601d63e7e$df2eb570$9d8c2050$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLRonHjt2w8GfsetSvzpyHiuZLogqbZtxow X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Anthony Perard' , 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: George Dunlap > Sent: 09 June 2020 17:45 > To: Xen-devel > Cc: Paul Durrant ; Ian Jackson ; Wei Liu ; Anthony > Perard > Subject: [TESTDAY] xl restore gives an error too soon after xl save > > Somewhat surprising that if you save with -D, you get mysterious error messages for the next so-many > seconds: > > root@immortal:/images# xl save -D c6-01 /images/tmp/c6-01.save > Saving to /images/tmp/c6-01.save new xl format (info 0x3/0x0/950) > xc: info: Saving domain 19505, type x86 PV > xc: Frames: 524288/524288 100% > xc: End of stream: 0/0 0% > root@immortal:/images# xl restore tmp/c6-01.save > Loading new save file tmp/c6-01.save (new xl fmt info 0x3/0x0/950) > Savefile contains xl domain config in JSON format > Parsing config from > libxl: error: libxl_create.c:692:libxl__domain_make: Domain 19505:domain id recently used: No such > file or directory > libxl: error: libxl_create.c:1233:initiate_domain_create: Domain 19505:cannot make domain: -3 > libxl: error: libxl_domain.c:1182:libxl__destroy_domid: Domain 19505:Non-existant domain > libxl: error: libxl_domain.c:1136:domain_destroy_callback: Domain 19505:Unable to destroy guest > libxl: error: libxl_domain.c:1063:domain_destroy_cb: Domain 19505:Destruction of domain failed > root@immortal:/images# xl restore tmp/c6-01.save > Loading new save file tmp/c6-01.save (new xl fmt info 0x3/0x0/950) > Savefile contains xl domain config in JSON format > Parsing config from > libxl: error: libxl_create.c:692:libxl__domain_make: Domain 19505:domain id recently used: No such > file or directory > libxl: error: libxl_create.c:1233:initiate_domain_create: Domain 19505:cannot make domain: -3 > libxl: error: libxl_domain.c:1182:libxl__destroy_domid: Domain 19505:Non-existant domain > libxl: error: libxl_domain.c:1136:domain_destroy_callback: Domain 19505:Unable to destroy guest > libxl: error: libxl_domain.c:1063:domain_destroy_cb: Domain 19505:Destruction of domain failed > > [A few minutes pass] > Yes, this is because it is not 'safe' to re-create the domain with the same domid until it is deemed not 'recently used'. This should indeed be documented. Paul > root@immortal:/images# xl restore tmp/c6-01.save > Loading new save file tmp/c6-01.save (new xl fmt info 0x3/0x0/950) > Savefile contains xl domain config in JSON format > Parsing config from > xc: info: Found x86 PV domain from Xen 4.14 > xc: info: Restoring domain > xc: info: Restore successful > xc: info: XenStore: mfn 0xbe8d2, dom 0, evt 1 > xc: info: Console: mfn 0xbe8d1, dom 0, evt 2 From xen-devel-bounces@lists.xenproject.org Tue Jun 09 16:56:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 16:56:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihXg-0004E1-Qg; Tue, 09 Jun 2020 16:56:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihXf-0004Dw-BN for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 16:56:03 +0000 X-Inumbo-ID: 18b5ed5e-aa72-11ea-b342-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 18b5ed5e-aa72-11ea-b342-12813bfff9fa; Tue, 09 Jun 2020 16:56:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=skEmVPrqnATXDNRB4cQSV6GMqJriM83wOcjDfWn7juw=; b=y92xDu0d2FIGu3sDkCXxg7b4c lNY5XS+mIfhlTStsf/kzriDibHLEOmnMb9DpgqrHcygOlrHRliLww8hqmIB4j3KlQP5wqnBEmhz06 xUKfBf0SSfH4GPg6+ojQQe//t7IIwkDpOOtn1XNv2dY+JWLNYlkaDWGqLmeq4jCsPXzO8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihXc-00044q-Aj; Tue, 09 Jun 2020 16:56:00 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jihXc-00039q-1D; Tue, 09 Jun 2020 16:56:00 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jihXc-0000im-0a; Tue, 09 Jun 2020 16:56:00 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150936: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=1a58d8dab52f241d52fec1d992d859b9632c4739 X-Osstest-Versions-That: xen=f7039ee41b3d3448775a1623f230037fd0455104 From: osstest service owner Date: Tue, 09 Jun 2020 16:56:00 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150936 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150936/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 1a58d8dab52f241d52fec1d992d859b9632c4739 baseline version: xen f7039ee41b3d3448775a1623f230037fd0455104 Last test of basis 150935 2020-06-09 11:02:19 Z 0 days Testing same since 150936 2020-06-09 14:01:56 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Ian Jackson jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f7039ee41b..1a58d8dab5 1a58d8dab52f241d52fec1d992d859b9632c4739 -> smoke From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:00:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:00:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihcJ-0005Fb-Ux; Tue, 09 Jun 2020 17:00:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihcI-0005Dl-Rg for xen-devel@lists.xen.org; Tue, 09 Jun 2020 17:00:50 +0000 X-Inumbo-ID: bb47a184-aa72-11ea-b343-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bb47a184-aa72-11ea-b343-12813bfff9fa; Tue, 09 Jun 2020 17:00:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version: Content-Transfer-Encoding:Content-Type:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ibrw2dMw1jlbrjnlYVNU0hHtjOZsr2v2S82Tbvvu8G0=; b=V+zw+wubzFhbqVzyZJ2jWp1Li/ ZrQwbJkmu+d1jHIKFtoYLHVi70YprffYUzZtZN91jf+34IBKELLxVsg91DY0kE8t1v46XyFg039IX ooaAICh83D2LsQ5q55X5GvIQxPmlJeNzsN82slx2RSJLOpSgOitP7PgVP8q1WTg4GZQw=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihbt-0004Bc-3n; Tue, 09 Jun 2020 17:00:25 +0000 Received: from iwj by xenbits.xenproject.org with local (Exim 4.92) (envelope-from ) id 1jihbt-0000Ja-1n; Tue, 09 Jun 2020 17:00:25 +0000 Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Subject: Xen Security Advisory 320 v1 (CVE-2020-0543) - Special Register Buffer speculative side channel Message-Id: Date: Tue, 09 Jun 2020 17:00:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Xen.org security team" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2020-0543 / XSA-320 Special Register Buffer speculative side channel ISSUE DESCRIPTION ================= This issue is related to the MDS and TAA vulnerabilities. Please see https://xenbits.xen.org/xsa/advisory-297.html (MDS) and https://xenbits.xen.org/xsa/advisory-305.html (TAA) for details. Certain processor operations microarchitecturally need to read data from outside the physical core (e.g. to communicate with the random number generator). In some implementations, this operation is called a Special Register Read. In some implementations, data are staged in a single shared buffer, and a full cache line at a time is returned to the core which made the Special Register Read. On parts vulnerable to MFBDS or TAA, an attacker may be able to access stale data requested by other cores in the system. For more details, see: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00320.html IMPACT ====== An attacker, which could include a malicious untrusted user process on a trusted guest, or an untrusted guest, can sample the contents of certain off-core accesses by other cores in the system. This can include data whose use may depend on the secrecy of the value, such as data from the Random Number Generator (e.g. RDRAND/RDSEED instructions). VULNERABLE SYSTEMS ================== Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not believed to be vulnerable. Only Intel based processors are affected. Processors from other manufacturers (e.g. AMD) are not believed to be vulnerable. Please consult the Intel Security Advisory for details on the affected processors. MITIGATION ========== There is no mitigation available. RESOLUTION ========== New microcode is being released on affected parts to work around the vulnerability. It may be available via a firmware update (consult your hardware vendor), or available for OS loading (consult your dom0 OS vendor). On Xen 4.13 and later, OS microcode can be loaded at runtime. See https://xenbits.xen.org/docs/latest/admin-guide/microcode-loading.html#runtime-microcode-loading for details on the xen-ucode utility. Loading the microcode, either at boot or at runtime, suffices to mitigate the issue, as protections are active by default. The mitigations do have an impact on latency of individual RDRAND/RDSEED instructions. The patches below are for Xen, and offer boot time information, defaults selection, and opt-out controls. They are recommended to take, but not absolutely necessary for protection. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa320/xsa320-?.patch xen-unstable xsa320/xsa320-4.13-?.patch Xen 4.13.x xsa320/xsa320-4.12-?.patch Xen 4.12.x xsa320/xsa320-4.11-?.patch Xen 4.11.x xsa320/xsa320-4.10-?.patch Xen 4.10.x xsa320/xsa320-4.9-?.patch Xen 4.9.x $ sha256sum xsa320*/* 84e4f66492042b08e69b0894ea7feb20c17c89a696cf95f05a8826fba4f26355 xsa320/xsa320-1.patch 5a3a06c72d0281fa1191ba18e39b836d2748400d9bf6a59dd45447850530c88b xsa320/xsa320-2.patch 759259ef88c980363d44e11d9c272f6a4a15918e5e6bcdfe971b1ce7ea160cd9 xsa320/xsa320-4.9-1.patch ebac2c011841c55c3c1e99d9e8afc53e56e54268d379ec8b904f6bfe6a1a5045 xsa320/xsa320-4.9-2.patch 5c622c74358ab21cbd27484c649f26df0f08e89ec333c346415bc51e35ba26c1 xsa320/xsa320-4.10-1.patch f112e34a6a4564a043926fc255a15c7e319001bd023a97ae2947228024e1c306 xsa320/xsa320-4.10-2.patch f24b51292be0cb5de80c6eff0b26983629dd48cc39ae5a331e2e38e15a6cf712 xsa320/xsa320-4.11-1.patch 03579810eaf2e9eeb1a82de4b50ff5c4b01e60b30ccf7609c9e3378ef576d81e xsa320/xsa320-4.11-2.patch 282537ffe2fd4332c0e061ddc537bea3e135a7bbd9253ec298becb49047323cf xsa320/xsa320-4.12-1.patch e4417429297354c233e8f5c261aff4888aae602f8c68897c09b16ea1aa44b1ca xsa320/xsa320-4.12-2.patch 611f2ab1a1c67e04767188d9803b6afd7d304e81a5b4f1eb1744d3e8a68ced66 xsa320/xsa320-4.13-1.patch cd1bc0071e72e2342ff4508ea3d937988694f4c03506b3afb3184f7d81aa1c86 xsa320/xsa320-4.13-2.patch $ NOTE REGARDING LACK OF EMBARGO ============================== Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl7fufEMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZCNgIALz6dLCvvznL7n3HFzYgKcelmOySjoZ52hJhg6ki N4C1AaPQmo1QPprycmuJ4uQIcLUP55Nh+h19V5PnRqSX1+7Qa8TXnv2TTpVK58fC JBfWBZ3xiXYdmaQOWYlJtD1Nq3vywA0LII9TZ7JdCUxjmPxn2y5ZOv6lRG6P9CVJ U+w3py0Zt32ZwYvVCbBPP49SdQmArH2BItEbGSQR5xeKnD/8Bx2/9odN0Mrnq5RQ euJxRled3nCGw6tWZJj3uYOy+dWWfmFwPFoFvI++zhrcwWGprcgjFuSGFbsGttMD ZB9+CZIJAHvgU4wu/B4SflHDgsmJS+iCmDR6e/NUlLohej0= =w+E7 -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyBi L2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYwppbmRleCAyZDRk OTYzOWQ2Li5iN2MyYjk5Mjk4IDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVu LWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21t YW5kLWxpbmUucGFuZG9jCkBAIC01MDQsMTAgKzUwNCwxMCBAQCBhY2NvdW50 aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXMgZW51bWVyYXRlZCB2 aWEgQ1BVSUQuCiAKIEN1cnJlbnRseSBhY2NlcHRlZDoKIAotVGhlIFNwZWN1 bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVhdHVyZXMgYG1kLWNsZWFyYCwg YGlicnNiYCwgYHN0aWJwYCwgYGlicGJgLAotYGwxZC1mbHVzaGAgYW5kIGBz c2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0IGlmIGF2YWlsYWJsZSBhbmQgYXBw bGljYWJsZS4gIFRoZXkgY2FuCi1iZSBpZ25vcmVkLCBlLmcuIGBuby1pYnJz YmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3b24ndCB1c2UgdGhlbSBpdHNlbGYs IGFuZAotd29uJ3Qgb2ZmZXIgdGhlbSB0byBndWVzdHMuCitUaGUgU3BlY3Vs YXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgc3JiZHMtY3RybGAs IGBtZC1jbGVhcmAsIGBpYnJzYmAsCitgc3RpYnBgLCBgaWJwYmAsIGBsMWQt Zmx1c2hgIGFuZCBgc3NiZGAgYXJlIHVzZWQgYnkgZGVmYXVsdCBpZiBhdmFp bGFibGUgYW5kCithcHBsaWNhYmxlLiAgVGhleSBjYW4gYmUgaWdub3JlZCwg ZS5nLiBgbm8taWJyc2JgLCBhdCB3aGljaCBwb2ludCBYZW4gd29uJ3QKK3Vz ZSB0aGVtIGl0c2VsZiwgYW5kIHdvbid0IG9mZmVyIHRoZW0gdG8gZ3Vlc3Rz LgogCiBgcmRyYW5kYCBjYW4gYmUgdXNlZCB0byBvdmVycmlkZSB0aGUgZGVm YXVsdCBkaXNhYmxpbmcgb2YgdGhlIGZlYXR1cmUgb24gY2VydGFpbgogQU1E IHN5c3RlbXMuICBJdHMgbmVnYXRpdmUgZm9ybSBjYW4gb2YgY291cnNlIGFs c28gYmUgdXNlZCB0byBzdXBwcmVzcyB1c2UgYW5kCmRpZmYgLS1naXQgYS90 b29scy9saWJ4bC9saWJ4bF9jcHVpZC5jIGIvdG9vbHMvbGlieGwvbGlieGxf Y3B1aWQuYwppbmRleCBjMzFkZDFmMzA0Li40ZTQ4NTJkZGViIDEwMDY0NAot LS0gYS90b29scy9saWJ4bC9saWJ4bF9jcHVpZC5jCisrKyBiL3Rvb2xzL2xp YnhsL2xpYnhsX2NwdWlkLmMKQEAgLTIxNCw2ICsyMTQsNyBAQCBpbnQgbGli eGxfY3B1aWRfcGFyc2VfY29uZmlnKGxpYnhsX2NwdWlkX3BvbGljeV9saXN0 ICpjcHVpZCwgY29uc3QgY2hhciogc3RyKQogCiAgICAgICAgIHsiYXZ4NTEy LTR2bm5pdyIsMHgwMDAwMDAwNywgIDAsIENQVUlEX1JFR19FRFgsICAyLCAg MX0sCiAgICAgICAgIHsiYXZ4NTEyLTRmbWFwcyIsMHgwMDAwMDAwNywgIDAs IENQVUlEX1JFR19FRFgsICAzLCAgMX0sCisgICAgICAgIHsic3JiZHMtY3Ry bCIsICAgMHgwMDAwMDAwNywgIDAsIENQVUlEX1JFR19FRFgsICA5LCAgMX0s CiAgICAgICAgIHsibWQtY2xlYXIiLCAgICAgMHgwMDAwMDAwNywgIDAsIENQ VUlEX1JFR19FRFgsIDEwLCAgMX0sCiAgICAgICAgIHsic2VyaWFsaXplIiwg ICAgMHgwMDAwMDAwNywgIDAsIENQVUlEX1JFR19FRFgsIDE0LCAgMX0sCiAg ICAgICAgIHsiY2V0LWlidCIsICAgICAgMHgwMDAwMDAwNywgIDAsIENQVUlE X1JFR19FRFgsIDIwLCAgMX0sCmRpZmYgLS1naXQgYS90b29scy9taXNjL3hl bi1jcHVpZC5jIGIvdG9vbHMvbWlzYy94ZW4tY3B1aWQuYwppbmRleCA4NTc4 MDc3NTQ1Li44ZDhmMzUzMmEyIDEwMDY0NAotLS0gYS90b29scy9taXNjL3hl bi1jcHVpZC5jCisrKyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKQEAgLTE2 MCw2ICsxNjAsNyBAQCBzdGF0aWMgY29uc3QgY2hhciAqY29uc3Qgc3RyXzdk MFszMl0gPQogICAgIFsgMl0gPSAiYXZ4NTEyXzR2bm5pdyIsIFsgM10gPSAi YXZ4NTEyXzRmbWFwcyIsCiAgICAgWyA0XSA9ICJmc3JtIiwKIAorICAgIC8q ICA4ICovICAgICAgICAgICAgICAgIFsgOV0gPSAic3JiZHMtY3RybCIsCiAg ICAgWzEwXSA9ICJtZC1jbGVhciIsCiAgICAgLyogMTIgKi8gICAgICAgICAg ICAgICAgWzEzXSA9ICJ0c3gtZm9yY2UtYWJvcnQiLAogICAgIFsxNF0gPSAi c2VyaWFsaXplIiwKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tc3IuYyBi L3hlbi9hcmNoL3g4Ni9tc3IuYwppbmRleCBkY2FjYWU1OGRlLi4wYmZiNTgz OWIyIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvbXNyLmMKKysrIGIveGVu L2FyY2gveDg2L21zci5jCkBAIC0xNjcsNiArMTY3LDcgQEAgaW50IGd1ZXN0 X3JkbXNyKHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90 ICp2YWwpCiAgICAgY2FzZSBNU1JfQ09SRV9DQVBBQklMSVRJRVM6CiAgICAg Y2FzZSBNU1JfVFNYX0ZPUkNFX0FCT1JUOgogICAgIGNhc2UgTVNSX1RTWF9D VFJMOgorICAgIGNhc2UgTVNSX01DVV9PUFRfQ1RSTDoKICAgICBjYXNlIE1T Ul9VX0NFVDoKICAgICBjYXNlIE1TUl9TX0NFVDoKICAgICBjYXNlIE1TUl9Q TDBfU1NQIC4uLiBNU1JfSU5URVJSVVBUX1NTUF9UQUJMRToKQEAgLTMyNyw2 ICszMjgsNyBAQCBpbnQgZ3Vlc3Rfd3Jtc3Ioc3RydWN0IHZjcHUgKnYsIHVp bnQzMl90IG1zciwgdWludDY0X3QgdmFsKQogICAgIGNhc2UgTVNSX1RFU1Rf Q1RSTDoKICAgICBjYXNlIE1TUl9UU1hfRk9SQ0VfQUJPUlQ6CiAgICAgY2Fz ZSBNU1JfVFNYX0NUUkw6CisgICAgY2FzZSBNU1JfTUNVX09QVF9DVFJMOgog ICAgIGNhc2UgTVNSX1VfQ0VUOgogICAgIGNhc2UgTVNSX1NfQ0VUOgogICAg IGNhc2UgTVNSX1BMMF9TU1AgLi4uIE1TUl9JTlRFUlJVUFRfU1NQX1RBQkxF OgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jIGIveGVu L2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IGE5NGJlMmQ1OTQuLmE1ZGZm ZjgwYzUgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwor KysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTMxMiwxMiArMzEy LDEzIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0g aW5kX3RodW5rIHRodW5rLCB1aW50NjRfdCBjYXBzKQogICAgIHByaW50aygi U3BlY3VsYXRpdmUgbWl0aWdhdGlvbiBmYWNpbGl0aWVzOlxuIik7CiAKICAg ICAvKiBIYXJkd2FyZSBmZWF0dXJlcyB3aGljaCBwZXJ0YWluIHRvIHNwZWN1 bGF0aXZlIG1pdGlnYXRpb25zLiAqLwotICAgIHByaW50aygiICBIYXJkd2Fy ZSBmZWF0dXJlczolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAor ICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMl cyVzJXMlcyVzJXMlcyVzJXNcbiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1 ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNCKSkgPyAiIElCUlMvSUJQQiIg OiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZF QVRVUkVfU1RJQlApKSA/ICIgU1RJQlAiICAgICA6ICIiLAogICAgICAgICAg ICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9MMURfRkxVU0gp KSA/ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICAoXzdkMCAmIGNw dWZlYXRfbWFzayhYODZfRkVBVFVSRV9TU0JEKSkgID8gIiBTU0JEIiAgICAg IDogIiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1ZmVhdF9tYXNrKFg4Nl9G RUFUVVJFX01EX0NMRUFSKSkgPyAiIE1EX0NMRUFSIiA6ICIiLAorICAgICAg ICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TUkJEU19D VFJMKSkgPyAiIFNSQkRTX0NUUkwiIDogIiIsCiAgICAgICAgICAgIChlOGIg ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUEIpKSAgPyAiIElCUEIi ICAgICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfSUJS U19BTEwpICAgICAgICAgICAgICA/ICIgSUJSU19BTEwiICA6ICIiLAogICAg ICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19SRENMX05PKSAgICAgICAgICAg ICAgID8gIiBSRENMX05PIiAgIDogIiIsCmRpZmYgLS1naXQgYS94ZW4vaW5j bHVkZS9hc20teDg2L21zci1pbmRleC5oIGIveGVuL2luY2x1ZGUvYXNtLXg4 Ni9tc3ItaW5kZXguaAppbmRleCBhNGRjNDhmNTFmLi5iMzI4YTQ3ZWQ4IDEw MDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRleC5oCisr KyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4LmgKQEAgLTY2LDYg KzY2LDkgQEAKICNkZWZpbmUgIFRTWF9DVFJMX1JUTV9ESVNBQkxFICAgICAg ICAgICAgICAgKF9BQygxLCBVTEwpIDw8ICAwKQogI2RlZmluZSAgVFNYX0NU UkxfQ1BVSURfQ0xFQVIgICAgICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwg IDEpCiAKKyNkZWZpbmUgTVNSX01DVV9PUFRfQ1RSTCAgICAgICAgICAgICAg ICAgICAgMHgwMDAwMDEyMworI2RlZmluZSAgTUNVX09QVF9DVFJMX1JOR0RT X01JVEdfRElTICAgICAgICAoX0FDKDEsIFVMTCkgPDwgIDApCisKICNkZWZp bmUgTVNSX1VfQ0VUICAgICAgICAgICAgICAgICAgICAgICAgICAgMHgwMDAw MDZhMAogI2RlZmluZSBNU1JfU19DRVQgICAgICAgICAgICAgICAgICAgICAg ICAgICAweDAwMDAwNmEyCiAjZGVmaW5lICBDRVRfU0hTVEtfRU4gICAgICAg ICAgICAgICAgICAgICAgIChfQUMoMSwgVUxMKSA8PCAgMCkKZGlmZiAtLWdp dCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0 LmggYi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNl dC5oCmluZGV4IDgzNDdhNDA1YWMuLjVjYTM1ZDlkOTcgMTAwNjQ0Ci0tLSBh L3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgK KysrIGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVz ZXQuaApAQCAtMjU5LDYgKzI1OSw3IEBAIFhFTl9DUFVGRUFUVVJFKEFNRF9Q UElOLCAgICAgIDgqMzIrMjMpIC8qICAgUHJvdGVjdGVkIFByb2Nlc3NvciBJ bnZlbnRvcnkgTnVtYmVyCiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl cywgQ1BVSUQgbGV2ZWwgMHgwMDAwMDAwNzowLmVkeCwgd29yZCA5ICovCiBY RU5fQ1BVRkVBVFVSRShBVlg1MTJfNFZOTklXLCA5KjMyKyAyKSAvKkEgIEFW WDUxMiBOZXVyYWwgTmV0d29yayBJbnN0cnVjdGlvbnMgKi8KIFhFTl9DUFVG RUFUVVJFKEFWWDUxMl80Rk1BUFMsIDkqMzIrIDMpIC8qQSAgQVZYNTEyIE11 bHRpcGx5IEFjY3VtdWxhdGlvbiBTaW5nbGUgUHJlY2lzaW9uICovCitYRU5f Q1BVRkVBVFVSRShTUkJEU19DVFJMLCAgICA5KjMyKyA5KSAvKiAgIE1TUl9N Q1VfT1BUX0NUUkwgYW5kIFJOR0RTX01JVEdfRElTLiAqLwogWEVOX0NQVUZF QVRVUkUoTURfQ0xFQVIsICAgICAgOSozMisxMCkgLypBICBWRVJXIGNsZWFy cyBtaWNyb2FyY2hpdGVjdHVyYWwgYnVmZmVycyAqLwogWEVOX0NQVUZFQVRV UkUoVFNYX0ZPUkNFX0FCT1JULCA5KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNF X0FCT1JULlJUTV9BQk9SVCAqLwogWEVOX0NQVUZFQVRVUkUoU0VSSUFMSVpF LCAgICAgOSozMisxNCkgLyphICBTRVJJQUxJWkUgaW5zbiAqLwo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5w YW5kb2MgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKaW5k ZXggYjdjMmI5OTI5OC4uMWE2OWM2MDEzOSAxMDA2NDQKLS0tIGEvZG9jcy9t aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCisrKyBiL2RvY3MvbWlzYy94 ZW4tY29tbWFuZC1saW5lLnBhbmRvYwpAQCAtMjA0OCw3ICsyMDQ4LDcgQEAg QnkgZGVmYXVsdCBTU0JEIHdpbGwgYmUgbWl0aWdhdGVkIGF0IHJ1bnRpbWUg KGkuZSBgc3NiZD1ydW50aW1lYCkuCiAjIyMgc3BlYy1jdHJsICh4ODYpCiA+ IGA9IExpc3Qgb2YgWyA8Ym9vbD4sIHhlbj08Ym9vbD4sIHtwdixodm0sbXNy LXNjLHJzYixtZC1jbGVhcn09PGJvb2w+LAogPiAgICAgICAgICAgICAgYnRp LXRodW5rPXJldHBvbGluZXxsZmVuY2V8am1wLCB7aWJycyxpYnBiLHNzYmQs ZWFnZXItZnB1LAotPiAgICAgICAgICAgICAgbDFkLWZsdXNoLGJyYW5jaC1o YXJkZW59PTxib29sPiBdYAorPiAgICAgICAgICAgICAgbDFkLWZsdXNoLGJy YW5jaC1oYXJkZW4sc3JiLWxvY2t9PTxib29sPiBdYAogCiBDb250cm9scyBm b3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9uIHNpZGVjaGFubmVsIG1pdGlnYXRp b25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3aWxsIHBpY2sgdGhlIG1vc3QgYXBw cm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFzZWQgb24gY29tcGlsZWQgaW4gc3Vw cG9ydCwKQEAgLTIxMjUsNiArMjEyNSwxMiBAQCBJZiBYZW4gaXMgY29tcGls ZWQgd2l0aCBgQ09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9CUkFOQ0hgLCB0 aGUKIHNwZWN1bGF0aW9uIGJhcnJpZXJzIHRvIHByb3RlY3Qgc2VsZWN0ZWQg Y29uZGl0aW9uYWwgYnJhbmNoZXMuICBCeSBkZWZhdWx0LAogWGVuIHdpbGwg ZW5hYmxlIHRoaXMgbWl0aWdhdGlvbi4KIAorT24gaGFyZHdhcmUgc3VwcG9y dGluZyBTUkJEU19DVFJMLCB0aGUgYHNyYi1sb2NrPWAgb3B0aW9uIGNhbiBi ZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2ZW50IFhlbiBmcm9tIHByb3RlY3Qg dGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVmZmVyIGZyb20gbGVha2luZyBzdGFs ZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVuIHdpbGwgZW5hYmxlIHRoaXMgbWl0 aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRzIHdoZXJlIE1EUworaXMgZml4ZWQg YW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0ZWQgKGluIHdoaWNoIGNhc2UsIHRo ZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5vCit3YXkgZm9yIGFuIGF0dGFja2Vy IHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0YSkuCisKICMjIyBzeW5jX2NvbnNv bGUKID4gYD0gPGJvb2xlYW4+YAogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94 ODYvYWNwaS9wb3dlci5jIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpp bmRleCAwY2RhMzYyMDQ1Li44ZjljZmU5ZjMyIDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvYWNwaS9wb3dlci5jCisrKyBiL3hlbi9hcmNoL3g4Ni9hY3Bp L3Bvd2VyLmMKQEAgLTI5Niw2ICsyOTYsOSBAQCBzdGF0aWMgaW50IGVudGVy X3N0YXRlKHUzMiBzdGF0ZSkKICAgICBjaS0+c3BlY19jdHJsX2ZsYWdzIHw9 IChkZWZhdWx0X3NwZWNfY3RybF9mbGFncyAmIFNDRl9pc3Rfd3Jtc3IpOwog ICAgIHNwZWNfY3RybF9leGl0X2lkbGUoY2kpOwogCisgICAgaWYgKCBib290 X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgICAgICB3 cm1zcmwoTVNSX01DVV9PUFRfQ1RSTCwgZGVmYXVsdF94ZW5fbWN1X29wdF9j dHJsKTsKKwogICAgIC8qIChyZSlpbml0aWFsaXNlIFNZU0NBTEwvU1lTRU5U RVIgc3RhdGUsIGFtb25nc3Qgb3RoZXIgdGhpbmdzLiAqLwogICAgIHBlcmNw dV90cmFwc19pbml0KCk7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9z bXBib290LmMgYi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCmluZGV4IDEzYjNk YWRlOWMuLmJhOGJjOTRjZjUgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9z bXBib290LmMKKysrIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwpAQCAtMzcy LDEyICszNzIsMTQgQEAgdm9pZCBzdGFydF9zZWNvbmRhcnkodm9pZCAqdW51 c2VkKQogICAgIG1pY3JvY29kZV91cGRhdGVfb25lKGZhbHNlKTsKIAogICAg IC8qCi0gICAgICogSWYgTVNSX1NQRUNfQ1RSTCBpcyBhdmFpbGFibGUsIGFw cGx5IFhlbidzIGRlZmF1bHQgc2V0dGluZyBhbmQgZGlzY2FyZAotICAgICAq IGFueSBmaXJtd2FyZSBzZXR0aW5ncy4gIE5vdGU6IE1TUl9TUEVDX0NUUkwg bWF5IG9ubHkgYmVjb21lIGF2YWlsYWJsZQotICAgICAqIGFmdGVyIGxvYWRp bmcgbWljcm9jb2RlLgorICAgICAqIElmIGFueSBzcGVjdWxhdGl2ZSBjb250 cm9sIE1TUnMgYXJlIGF2YWlsYWJsZSwgYXBwbHkgWGVuJ3MgZGVmYXVsdAor ICAgICAqIHNldHRpbmdzLiAgTm90ZTogVGhlc2UgTVNScyBtYXkgb25seSBi ZWNvbWUgYXZhaWxhYmxlIGFmdGVyIGxvYWRpbmcKKyAgICAgKiBtaWNyb2Nv ZGUuCiAgICAgICovCiAgICAgaWYgKCBib290X2NwdV9oYXMoWDg2X0ZFQVRV UkVfSUJSU0IpICkKICAgICAgICAgd3Jtc3JsKE1TUl9TUEVDX0NUUkwsIGRl ZmF1bHRfeGVuX3NwZWNfY3RybCk7CisgICAgaWYgKCBib290X2NwdV9oYXMo WDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgICAgICB3cm1zcmwoTVNS X01DVV9PUFRfQ1RSTCwgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsKTsKIAog ICAgIHRzeF9pbml0KCk7IC8qIE5lZWRzIG1pY3JvY29kZS4gIE1heSBjaGFu Z2UgSExFL1JUTSBmZWF0dXJlIGJpdHMuICovCiAKZGlmZiAtLWdpdCBhL3hl bi9hcmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0 cmwuYwppbmRleCBhNWRmZmY4MGM1Li5jOWY3OGVhZDYyIDEwMDY0NAotLS0g YS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2 L3NwZWNfY3RybC5jCkBAIC02NSw2ICs2NSw5IEBAIHN0YXRpYyB1bnNpZ25l ZCBpbnQgX19pbml0ZGF0YSBsMWRfbWF4cGh5c2FkZHI7CiBzdGF0aWMgYm9v bCBfX2luaXRkYXRhIGNwdV9oYXNfYnVnX21zYmRzX29ubHk7IC8qID0+IG1p bmltYWwgSFQgaW1wYWN0LiAqLwogc3RhdGljIGJvb2wgX19pbml0ZGF0YSBj cHVfaGFzX2J1Z19tZHM7IC8qIEFueSBvdGhlciBNe0xQLFNCLEZCfURTIGNv bWJpbmF0aW9uLiAqLwogCitzdGF0aWMgaW50OF90IF9faW5pdGRhdGEgb3B0 X3NyYl9sb2NrID0gLTE7Cit1aW50NjRfdCBfX3JlYWRfbW9zdGx5IGRlZmF1 bHRfeGVuX21jdV9vcHRfY3RybDsKKwogc3RhdGljIGludCBfX2luaXQgcGFy c2Vfc3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiB7CiAgICAgY29uc3QgY2hh ciAqc3M7CkBAIC0xMTIsNiArMTE1LDcgQEAgc3RhdGljIGludCBfX2luaXQg cGFyc2Vfc3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBv cHRfc3NiZCA9IGZhbHNlOwogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9 IDA7CiAgICAgICAgICAgICBvcHRfYnJhbmNoX2hhcmRlbiA9IGZhbHNlOwor ICAgICAgICAgICAgb3B0X3NyYl9sb2NrID0gMDsKICAgICAgICAgfQogICAg ICAgICBlbHNlIGlmICggdmFsID4gMCApCiAgICAgICAgICAgICByYyA9IC1F SU5WQUw7CkBAIC0xNzgsNiArMTgyLDggQEAgc3RhdGljIGludCBfX2luaXQg cGFyc2Vfc3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBv cHRfbDFkX2ZsdXNoID0gdmFsOwogICAgICAgICBlbHNlIGlmICggKHZhbCA9 IHBhcnNlX2Jvb2xlYW4oImJyYW5jaC1oYXJkZW4iLCBzLCBzcykpID49IDAg KQogICAgICAgICAgICAgb3B0X2JyYW5jaF9oYXJkZW4gPSB2YWw7CisgICAg ICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigic3JiLWxvY2si LCBzLCBzcykpID49IDAgKQorICAgICAgICAgICAgb3B0X3NyYl9sb2NrID0g dmFsOwogICAgICAgICBlbHNlCiAgICAgICAgICAgICByYyA9IC1FSU5WQUw7 CiAKQEAgLTM0MSw3ICszNDcsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJp bnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0X3QgY2Fw cykKICAgICAgICAgICAgICAgICJcbiIpOwogCiAgICAgLyogU2V0dGluZ3Mg Zm9yIFhlbidzIHByb3RlY3Rpb24sIGlycmVzcGVjdGl2ZSBvZiBndWVzdHMu ICovCi0gICAgcHJpbnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVz LCBTUEVDX0NUUkw6ICVzJXMlcywgT3RoZXI6JXMlcyVzJXNcbiIsCisgICAg cHJpbnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVzLCBTUEVDX0NU Ukw6ICVzJXMlcywgT3RoZXI6JXMlcyVzJXMlc1xuIiwKICAgICAgICAgICAg dGh1bmsgPT0gVEhVTktfTk9ORSAgICAgID8gIk4vQSIgOgogICAgICAgICAg ICB0aHVuayA9PSBUSFVOS19SRVRQT0xJTkUgPyAiUkVUUE9MSU5FIiA6CiAg ICAgICAgICAgIHRodW5rID09IFRIVU5LX0xGRU5DRSAgICA/ICJMRkVOQ0Ui IDoKQEAgLTM1Miw2ICszNTgsOCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJp bnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0X3QgY2Fw cykKICAgICAgICAgICAgKGRlZmF1bHRfeGVuX3NwZWNfY3RybCAmIFNQRUNf Q1RSTF9TU0JEKSAgPyAiIFNTQkQrIiA6ICIgU1NCRC0iLAogICAgICAgICAg ICAhKGNhcHMgJiBBUkNIX0NBUFNfVFNYX0NUUkwpICAgICAgICAgICAgICA/ ICIiIDoKICAgICAgICAgICAgKG9wdF90c3ggJiAxKSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPyAiIFRTWCsiIDogIiBUU1gtIiwKKyAgICAgICAg ICAgIWJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSAgICAg PyAiIiA6CisgICAgICAgICAgIG9wdF9zcmJfbG9jayAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgID8gIiBTUkJfTE9DSysiIDogIiBTUkJfTE9DSy0i LAogICAgICAgICAgICBvcHRfaWJwYiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA/ICIgSUJQQiIgIDogIiIsCiAgICAgICAgICAgIG9wdF9s MWRfZmx1c2ggICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBMMURf RkxVU0giIDogIiIsCiAgICAgICAgICAgIG9wdF9tZF9jbGVhcl9wdiB8fCBv cHRfbWRfY2xlYXJfaHZtICAgICAgID8gIiBWRVJXIiAgOiAiIiwKQEAgLTEx NTcsNiArMTE2NSwzNCBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9u X21pdGlnYXRpb25zKHZvaWQpCiAgICAgICAgIHRzeF9pbml0KCk7CiAgICAg fQogCisgICAgLyogQ2FsY3VsYXRlIHN1aXRhYmxlIGRlZmF1bHRzIGZvciBN U1JfTUNVX09QVF9DVFJMICovCisgICAgaWYgKCBib290X2NwdV9oYXMoWDg2 X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgIHsKKyAgICAgICAgdWludDY0 X3QgdmFsOworCisgICAgICAgIHJkbXNybChNU1JfTUNVX09QVF9DVFJMLCB2 YWwpOworCisgICAgICAgIC8qCisgICAgICAgICAqIE9uIHNvbWUgU1JCRFMt YWZmZWN0ZWQgaGFyZHdhcmUsIGl0IG1heSBiZSBzYWZlIHRvIHJlbGF4IHNy Yi1sb2NrCisgICAgICAgICAqIGJ5IGRlZmF1bHQuCisgICAgICAgICAqCisg ICAgICAgICAqIE9uIHBhcnRzIHdoaWNoIGVudW1lcmF0ZSBNRFNfTk8gYW5k IG5vdCBUQUFfTk8sIFRTWCBpcyB0aGUgb25seSB3YXkKKyAgICAgICAgICog dG8gYWNjZXNzIHRoZSBGaWxsIEJ1ZmZlci4gIElmIFRTWCBpc24ndCBhdmFp bGFibGUgKGluYy4gU0tVCisgICAgICAgICAqIHJlYXNvbnMgb24gc29tZSBt b2RlbHMpLCBvciBUU1ggaXMgZXhwbGljaXRseSBkaXNhYmxlZCwgdGhlbiB0 aGVyZQorICAgICAgICAgKiBpcyBubyBuZWVkIGZvciB0aGUgZXh0cmEgb3Zl cmhlYWQgdG8gcHJvdGVjdCBSRFJBTkQvUkRTRUVELgorICAgICAgICAgKi8K KyAgICAgICAgaWYgKCBvcHRfc3JiX2xvY2sgPT0gLTEgJiYKKyAgICAgICAg ICAgICAoY2FwcyAmIChBUkNIX0NBUFNfTURTX05PfEFSQ0hfQ0FQU19UQUFf Tk8pKSA9PSBBUkNIX0NBUFNfTURTX05PICYmCisgICAgICAgICAgICAgKCFj cHVfaGFzX2hsZSB8fCAoKGNhcHMgJiBBUkNIX0NBUFNfVFNYX0NUUkwpICYm IG9wdF90c3ggPT0gMCkpICkKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9 IDA7CisKKyAgICAgICAgdmFsICY9IH5NQ1VfT1BUX0NUUkxfUk5HRFNfTUlU R19ESVM7CisgICAgICAgIGlmICggIW9wdF9zcmJfbG9jayApCisgICAgICAg ICAgICB2YWwgfD0gTUNVX09QVF9DVFJMX1JOR0RTX01JVEdfRElTOworCisg ICAgICAgIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCA9IHZhbDsKKyAgICB9 CisKICAgICBwcmludF9kZXRhaWxzKHRodW5rLCBjYXBzKTsKIAogICAgIC8q CkBAIC0xMTg4LDYgKzEyMjQsOSBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1 bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAKICAgICAgICAgd3Jtc3JsKE1T Ul9TUEVDX0NUUkwsIGJzcF9kZWxheV9zcGVjX2N0cmwgPyAwIDogZGVmYXVs dF94ZW5fc3BlY19jdHJsKTsKICAgICB9CisKKyAgICBpZiAoIGJvb3RfY3B1 X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSApCisgICAgICAgIHdybXNy bChNU1JfTUNVX09QVF9DVFJMLCBkZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmwp OwogfQogCiBzdGF0aWMgdm9pZCBfX2luaXQgX19tYXliZV91bnVzZWQgYnVp bGRfYXNzZXJ0aW9ucyh2b2lkKQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv YXNtLXg4Ni9zcGVjX2N0cmwuaCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvc3Bl Y19jdHJsLmgKaW5kZXggOWNhZWNkZGZlYy4uYjI1MmJiODYzMSAxMDA2NDQK LS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmwuaAorKysgYi94 ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oCkBAIC01NCw2ICs1NCw4 IEBAIGV4dGVybiBpbnQ4X3Qgb3B0X3B2X2wxdGZfaHdkb20sIG9wdF9wdl9s MXRmX2RvbXU7CiAgKi8KIGV4dGVybiBwYWRkcl90IGwxdGZfYWRkcl9tYXNr LCBsMXRmX3NhZmVfbWFkZHI7CiAKK2V4dGVybiB1aW50NjRfdCBkZWZhdWx0 X3hlbl9tY3Vfb3B0X2N0cmw7CisKIHN0YXRpYyBpbmxpbmUgdm9pZCBpbml0 X3NoYWRvd19zcGVjX2N0cmxfc3RhdGUodm9pZCkKIHsKICAgICBzdHJ1Y3Qg Y3B1X2luZm8gKmluZm8gPSBnZXRfY3B1X2luZm8oKTsK --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.9-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.9-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du IGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KaW5kZXgg ODAwNDhkNDIzMC4uMTc3ZGVjYWVjZSAxMDA2NDQKLS0tIGEvZG9jcy9taXNj L3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KKysrIGIvZG9jcy9taXNjL3hl bi1jb21tYW5kLWxpbmUubWFya2Rvd24KQEAgLTQ1NiwxMCArNDU2LDEwIEBA IGFjY291bnRpbmcgZm9yIGhhcmR3YXJlIGNhcGFiaWxpdGllcyBhcyBlbnVt ZXJhdGVkIHZpYSBDUFVJRC4KIAogQ3VycmVudGx5IGFjY2VwdGVkOgogCi1U aGUgU3BlY3VsYXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgbWQt Y2xlYXJgLCBgaWJyc2JgLCBgc3RpYnBgLCBgaWJwYmAsCi1gbDFkLWZsdXNo YCBhbmQgYHNzYmRgIGFyZSB1c2VkIGJ5IGRlZmF1bHQgaWYgYXZhaWxhYmxl IGFuZCBhcHBsaWNhYmxlLiAgVGhleSBjYW4KLWJlIGlnbm9yZWQsIGUuZy4g YG5vLWlicnNiYCwgYXQgd2hpY2ggcG9pbnQgWGVuIHdvbid0IHVzZSB0aGVt IGl0c2VsZiwgYW5kCi13b24ndCBvZmZlciB0aGVtIHRvIGd1ZXN0cy4KK1Ro ZSBTcGVjdWxhdGlvbiBDb250cm9sIGhhcmR3YXJlIGZlYXR1cmVzIGBzcmJk cy1jdHJsYCwgYG1kLWNsZWFyYCwgYGlicnNiYCwKK2BzdGlicGAsIGBpYnBi YCwgYGwxZC1mbHVzaGAgYW5kIGBzc2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0 IGlmIGF2YWlsYWJsZSBhbmQKK2FwcGxpY2FibGUuICBUaGV5IGNhbiBiZSBp Z25vcmVkLCBlLmcuIGBuby1pYnJzYmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3 b24ndAordXNlIHRoZW0gaXRzZWxmLCBhbmQgd29uJ3Qgb2ZmZXIgdGhlbSB0 byBndWVzdHMuCiAKICMjIyBjcHVpZFxfbWFza1xfY3B1IChBTUQgb25seSkK ID4gYD0gZmFtXzBmX3Jldl9jIHwgZmFtXzBmX3Jldl9kIHwgZmFtXzBmX3Jl dl9lIHwgZmFtXzBmX3Jldl9mIHwgZmFtXzBmX3Jldl9nIHwgZmFtXzEwX3Jl dl9iIHwgZmFtXzEwX3Jldl9jIHwgZmFtXzExX3Jldl9iYApkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhsL2xp YnhsX2NwdWlkLmMKaW5kZXggMjBkMDYwMjUxYS4uNWEyYzY3ZmNhYyAxMDA2 NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90b29s cy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0xNTgsNiArMTU4LDcgQEAgaW50 IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xpY3lf bGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKICAgICAgICAgeyJkZSIs ICAgICAgICAgICAweDAwMDAwMDAxLCBOQSwgQ1BVSURfUkVHX0VEWCwgIDIs ICAxfSwKICAgICAgICAgeyJ2bWUiLCAgICAgICAgICAweDAwMDAwMDAxLCBO QSwgQ1BVSURfUkVHX0VEWCwgIDEsICAxfSwKICAgICAgICAgeyJmcHUiLCAg ICAgICAgICAweDAwMDAwMDAxLCBOQSwgQ1BVSURfUkVHX0VEWCwgIDAsICAx fSwKKyAgICAgICAgeyJzcmJkcy1jdHJsIiwgICAweDAwMDAwMDA3LCAgMCwg Q1BVSURfUkVHX0VEWCwgIDksICAxfSwKICAgICAgICAgeyJtZC1jbGVhciIs ICAgICAweDAwMDAwMDA3LCAgMCwgQ1BVSURfUkVHX0VEWCwgMTAsICAxfSwK ICAgICAgICAgeyJpYnJzYiIsICAgICAgICAweDAwMDAwMDA3LCAgMCwgQ1BV SURfUkVHX0VEWCwgMjYsICAxfSwKICAgICAgICAgeyJzdGlicCIsICAgICAg ICAweDAwMDAwMDA3LCAgMCwgQ1BVSURfUkVHX0VEWCwgMjcsICAxfSwKZGlm ZiAtLWdpdCBhL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMgYi90b29scy9taXNj L3hlbi1jcHVpZC5jCmluZGV4IDcyYzY3ZDBlNzcuLmI4NTM2NTY0MDQgMTAw NjQ0Ci0tLSBhL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKKysrIGIvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYwpAQCAtMTU3LDggKzE1Nyw5IEBAIHN0YXRpYyBj b25zdCBjaGFyICpzdHJfN2QwWzMyXSA9CiAKICAgICBbIDJdID0gImF2eDUx Ml80dm5uaXciLCBbIDNdID0gImF2eDUxMl80Zm1hcHMiLAogCi0gICAgWzQg Li4uIDldID0gIlJFWiIsCisgICAgWzQgLi4uIDddID0gIlJFWiIsCiAKKyAg ICBbIDhdID0gIlJFWiIsICAgICAgICAgICBbIDldID0gInNyYmRzLWN0cmwi LAogICAgIFsxMF0gPSAibWQtY2xlYXIiLCAgICAgIFsxMV0gPSAiUkVaIiwK ICAgICBbMTJdID0gIlJFWiIsICAgICAgICAgICBbMTNdID0gInRzeC1mb3Jj ZS1hYm9ydCIsCiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jcHVpZC5j IGIveGVuL2FyY2gveDg2L2NwdWlkLmMKaW5kZXggOWFhZjhiODI4My4uYjQ5 ODhiYTUyNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NwdWlkLmMKKysr IGIveGVuL2FyY2gveDg2L2NwdWlkLmMKQEAgLTU4LDYgKzU4LDExIEBAIHN0 YXRpYyBpbnQgX19pbml0IHBhcnNlX3hlbl9jcHVpZChjb25zdCBjaGFyICpz KQogICAgICAgICAgICAgaWYgKCAhdmFsICkKICAgICAgICAgICAgICAgICBz ZXR1cF9jbGVhcl9jcHVfY2FwKFg4Nl9GRUFUVVJFX1NTQkQpOwogICAgICAg ICB9CisgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigi c3JiZHMtY3RybCIsIHMsIHNzKSkgPj0gMCApCisgICAgICAgIHsKKyAgICAg ICAgICAgIGlmICggIXZhbCApCisgICAgICAgICAgICAgICAgc2V0dXBfY2xl YXJfY3B1X2NhcChYODZfRkVBVFVSRV9TUkJEU19DVFJMKTsKKyAgICAgICAg fQogICAgICAgICBlbHNlCiAgICAgICAgICAgICByYyA9IC1FSU5WQUw7CiAK ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0vaHZtLmMgYi94ZW4vYXJj aC94ODYvaHZtL2h2bS5jCmluZGV4IDJhYTlhYzA2YTQuLmUwM2MyMjFmNTQg MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vaHZtLmMKKysrIGIveGVu L2FyY2gveDg2L2h2bS9odm0uYwpAQCAtMzQ0NSw2ICszNDQ1LDcgQEAgaW50 IGh2bV9tc3JfcmVhZF9pbnRlcmNlcHQodW5zaWduZWQgaW50IG1zciwgdWlu dDY0X3QgKm1zcl9jb250ZW50KQogICAgICAgICAvKiBXcml0ZS1vbmx5ICov CiAgICAgY2FzZSBNU1JfVFNYX0ZPUkNFX0FCT1JUOgogICAgIGNhc2UgTVNS X1RTWF9DVFJMOgorICAgIGNhc2UgTVNSX01DVV9PUFRfQ1RSTDoKICAgICAg ICAgLyogTm90IG9mZmVyZWQgdG8gZ3Vlc3RzLiAqLwogICAgICAgICBnb3Rv IGdwX2ZhdWx0OwogCkBAIC0zNjcxLDYgKzM2NzIsNyBAQCBpbnQgaHZtX21z cl93cml0ZV9pbnRlcmNlcHQodW5zaWduZWQgaW50IG1zciwgdWludDY0X3Qg bXNyX2NvbnRlbnQsCiAgICAgICAgIC8qIFJlYWQtb25seSAqLwogICAgIGNh c2UgTVNSX1RTWF9GT1JDRV9BQk9SVDoKICAgICBjYXNlIE1TUl9UU1hfQ1RS TDoKKyAgICBjYXNlIE1TUl9NQ1VfT1BUX0NUUkw6CiAgICAgICAgIC8qIE5v dCBvZmZlcmVkIHRvIGd1ZXN0cy4gKi8KICAgICAgICAgZ290byBncF9mYXVs dDsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jIGIv eGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IGY0NGRmNmZmNDMuLmUy MTJhMjAxMjcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu YworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTM0OCwxMiAr MzQ4LDEzIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVu dW0gaW5kX3RodW5rIHRodW5rLCB1aW50NjRfdCBjYXBzKQogICAgIHByaW50 aygiU3BlY3VsYXRpdmUgbWl0aWdhdGlvbiBmYWNpbGl0aWVzOlxuIik7CiAK ICAgICAvKiBIYXJkd2FyZSBmZWF0dXJlcyB3aGljaCBwZXJ0YWluIHRvIHNw ZWN1bGF0aXZlIG1pdGlnYXRpb25zLiAqLwotICAgIHByaW50aygiICBIYXJk d2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4i LAorICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVz JXMlcyVzJXMlcyVzJXMlcyVzJXNcbiIsCiAgICAgICAgICAgIChfN2QwICYg Y3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNCKSkgPyAiIElCUlMvSUJQ QiIgOiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2 X0ZFQVRVUkVfU1RJQlApKSA/ICIgU1RJQlAiICAgICA6ICIiLAogICAgICAg ICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9MMURfRkxV U0gpKSA/ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICAoXzdkMCAm IGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TU0JEKSkgID8gIiBTU0JEIiAg ICAgIDogIiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1ZmVhdF9tYXNrKFg4 Nl9GRUFUVVJFX01EX0NMRUFSKSkgPyAiIE1EX0NMRUFSIiA6ICIiLAorICAg ICAgICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TUkJE U19DVFJMKSkgPyAiIFNSQkRTX0NUUkwiIDogIiIsCiAgICAgICAgICAgIChl OGIgICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUEIpKSAgPyAiIElC UEIiICAgICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUEFC SUxJVElFU19JQlJTX0FMTCkgICAgICA/ICIgSUJSU19BTEwiICA6ICIiLAog ICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQQUJJTElUSUVTX1JEQ0xfTk8p ICAgICAgID8gIiBSRENMX05PIiAgIDogIiIsCmRpZmYgLS1naXQgYS94ZW4v YXJjaC94ODYvdHJhcHMuYyBiL3hlbi9hcmNoL3g4Ni90cmFwcy5jCmluZGV4 IDliNGJiNmEwMDkuLjZlYTU4MmMzOTMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNo L3g4Ni90cmFwcy5jCisrKyBiL3hlbi9hcmNoL3g4Ni90cmFwcy5jCkBAIC0y NjU1LDYgKzI2NTUsNyBAQCBzdGF0aWMgaW50IHByaXZfb3BfcmVhZF9tc3Io dW5zaWduZWQgaW50IHJlZywgdWludDY0X3QgKnZhbCwKICAgICAgICAgLyog V3JpdGUtb25seSAqLwogICAgIGNhc2UgTVNSX1RTWF9GT1JDRV9BQk9SVDoK ICAgICBjYXNlIE1TUl9UU1hfQ1RSTDoKKyAgICBjYXNlIE1TUl9NQ1VfT1BU X0NUUkw6CiAgICAgICAgIC8qIE5vdCBvZmZlcmVkIHRvIGd1ZXN0cy4gKi8K ICAgICAgICAgYnJlYWs7CiAKQEAgLTI4ODAsNiArMjg4MSw3IEBAIHN0YXRp YyBpbnQgcHJpdl9vcF93cml0ZV9tc3IodW5zaWduZWQgaW50IHJlZywgdWlu dDY0X3QgdmFsLAogICAgICAgICAvKiBUaGUgTVNSIGlzIHJlYWQtb25seS4g Ki8KICAgICBjYXNlIE1TUl9UU1hfRk9SQ0VfQUJPUlQ6CiAgICAgY2FzZSBN U1JfVFNYX0NUUkw6CisgICAgY2FzZSBNU1JfTUNVX09QVF9DVFJMOgogICAg ICAgICAvKiBOb3Qgb2ZmZXJlZCB0byBndWVzdHMuICovCiAgICAgICAgIGJy ZWFrOwogCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9hc20teDg2L21zci1p bmRleC5oIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3ItaW5kZXguaAppbmRl eCA1ZDYzNmNjMjUwLi5kNzdhZWI5YWZhIDEwMDY0NAotLS0gYS94ZW4vaW5j bHVkZS9hc20teDg2L21zci1pbmRleC5oCisrKyBiL3hlbi9pbmNsdWRlL2Fz bS14ODYvbXNyLWluZGV4LmgKQEAgLTE3Niw2ICsxNzYsOSBAQAogI2RlZmlu ZSBNU1JfSUEzMl9WTVhfVFJVRV9FTlRSWV9DVExTICAgICAgICAgICAgMHg0 OTAKICNkZWZpbmUgTVNSX0lBMzJfVk1YX1ZNRlVOQyAgICAgICAgICAgICAg ICAgICAgIDB4NDkxCiAKKyNkZWZpbmUgTVNSX01DVV9PUFRfQ1RSTCAgICAg ICAgICAgICAgICAgICAgMHgwMDAwMDEyMworI2RlZmluZSAgTUNVX09QVF9D VFJMX1JOR0RTX01JVEdfRElTICAgICAgICAoX0FDKDEsIFVMTCkgPDwgIDAp CisKIC8qIEs3L0s4IE1TUnMuIE5vdCBjb21wbGV0ZS4gU2VlIHRoZSBhcmNo aXRlY3R1cmUgbWFudWFsIGZvciBhIG1vcmUKICAgIGNvbXBsZXRlIGxpc3Qu ICovCiAjZGVmaW5lIE1TUl9LN19FVk5UU0VMMAkJCTB4YzAwMTAwMDAKZGlm ZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0 dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVh dHVyZXNldC5oCmluZGV4IDAwMGE5NDFlNTAuLmM3NTAxNGY0ZTMgMTAwNjQ0 Ci0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJl c2V0LmgKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZl YXR1cmVzZXQuaApAQCAtMjQxLDYgKzI0MSw3IEBAIFhFTl9DUFVGRUFUVVJF KElCUEIsICAgICAgICAgIDgqMzIrMTIpIC8qQSAgSUJQQiBzdXBwb3J0IG9u bHkgKG5vIElCUlMsIHVzZWQgYnkKIC8qIEludGVsLWRlZmluZWQgQ1BVIGZl YXR1cmVzLCBDUFVJRCBsZXZlbCAweDAwMDAwMDA3OjAuZWR4LCB3b3JkIDkg Ki8KIFhFTl9DUFVGRUFUVVJFKEFWWDUxMl80Vk5OSVcsIDkqMzIrIDIpIC8q QSAgQVZYNTEyIE5ldXJhbCBOZXR3b3JrIEluc3RydWN0aW9ucyAqLwogWEVO X0NQVUZFQVRVUkUoQVZYNTEyXzRGTUFQUywgOSozMisgMykgLypBICBBVlg1 MTIgTXVsdGlwbHkgQWNjdW11bGF0aW9uIFNpbmdsZSBQcmVjaXNpb24gKi8K K1hFTl9DUFVGRUFUVVJFKFNSQkRTX0NUUkwsICAgIDkqMzIrIDkpIC8qICAg TVNSX01DVV9PUFRfQ1RSTCBhbmQgUk5HRFNfTUlUR19ESVMuICovCiBYRU5f Q1BVRkVBVFVSRShNRF9DTEVBUiwgICAgICA5KjMyKzEwKSAvKkEgIFZFUlcg Y2xlYXJzIG1pY3JvYXJjaGl0ZWN0dXJhbCBidWZmZXJzICovCiBYRU5fQ1BV RkVBVFVSRShUU1hfRk9SQ0VfQUJPUlQsIDkqMzIrMTMpIC8qIE1TUl9UU1hf Rk9SQ0VfQUJPUlQuUlRNX0FCT1JUICovCiBYRU5fQ1BVRkVBVFVSRShJQlJT QiwgICAgICAgICA5KjMyKzI2KSAvKkEgIElCUlMgYW5kIElCUEIgc3VwcG9y dCAodXNlZCBieSBJbnRlbCkgKi8K --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.9-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.9-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5t YXJrZG93biBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du CmluZGV4IDE3N2RlY2FlY2UuLjRiMzRlZWZlYjUgMTAwNjQ0Ci0tLSBhL2Rv Y3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBiL2RvY3Mv bWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCkBAIC0xNzA0LDcgKzE3 MDQsNyBAQCBmYWxzZSBkaXNhYmxlIHRoZSBxdWlyayB3b3JrYXJvdW5kLCB3 aGljaCBpcyBhbHNvIHRoZSBkZWZhdWx0LgogIyMjIHNwZWMtY3RybCAoeDg2 KQogPiBgPSBMaXN0IG9mIFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZt LG1zci1zYyxyc2IsbWQtY2xlYXJ9PTxib29sPiwKID4gICAgICAgICAgICAg IGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZlbmNlfGptcCwge2licnMsaWJwYixz c2JkLGVhZ2VyLWZwdSwKLT4gICAgICAgICAgICAgIGwxZC1mbHVzaH09PGJv b2w+IF1gCis+ICAgICAgICAgICAgICBsMWQtZmx1c2gsc3JiLWxvY2t9PTxi b29sPiBdYAogCiBDb250cm9scyBmb3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9u IHNpZGVjaGFubmVsIG1pdGlnYXRpb25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3 aWxsIHBpY2sgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFz ZWQgb24gY29tcGlsZWQgaW4gc3VwcG9ydCwKQEAgLTE3NzYsNiArMTc3Niwx MiBAQCBJcnJlc3BlY3RpdmUgb2YgWGVuJ3Mgc2V0dGluZywgdGhlIGZlYXR1 cmUgaXMgdmlydHVhbGlzZWQgZm9yIEhWTSBndWVzdHMgdG8KIHVzZS4gIEJ5 IGRlZmF1bHQsIFhlbiB3aWxsIGVuYWJsZSB0aGlzIG1pdGlnYXRpb24gb24g aGFyZHdhcmUgYmVsaWV2ZWQgdG8gYmUKIHZ1bG5lcmFibGUgdG8gTDFURi4K IAorT24gaGFyZHdhcmUgc3VwcG9ydGluZyBTUkJEU19DVFJMLCB0aGUgYHNy Yi1sb2NrPWAgb3B0aW9uIGNhbiBiZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2 ZW50IFhlbiBmcm9tIHByb3RlY3QgdGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVm ZmVyIGZyb20gbGVha2luZyBzdGFsZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVu IHdpbGwgZW5hYmxlIHRoaXMgbWl0aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRz IHdoZXJlIE1EUworaXMgZml4ZWQgYW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0 ZWQgKGluIHdoaWNoIGNhc2UsIHRoZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5v Cit3YXkgZm9yIGFuIGF0dGFja2VyIHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0 YSkuCisKICMjIyBzeW5jXF9jb25zb2xlCiA+IGA9IDxib29sZWFuPmAKIApk aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYyBiL3hlbi9h cmNoL3g4Ni9hY3BpL3Bvd2VyLmMKaW5kZXggZjM0ODBhYTgwMC4uNGQ3MmI2 Y2U5NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwor KysgYi94ZW4vYXJjaC94ODYvYWNwaS9wb3dlci5jCkBAIC0yNTksNiArMjU5 LDkgQEAgc3RhdGljIGludCBlbnRlcl9zdGF0ZSh1MzIgc3RhdGUpCiAgICAg Y2ktPnNwZWNfY3RybF9mbGFncyB8PSAoZGVmYXVsdF9zcGVjX2N0cmxfZmxh Z3MgJiBTQ0ZfaXN0X3dybXNyKTsKICAgICBzcGVjX2N0cmxfZXhpdF9pZGxl KGNpKTsKIAorICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NS QkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkws IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CisKICBkb25lOgogICAgIHNw aW5fZGVidWdfZW5hYmxlKCk7CiAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh Z3MpOwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYyBiL3hl bi9hcmNoL3g4Ni9zbXBib290LmMKaW5kZXggNjQxZjgzMGNkMS4uOWRiOGVm MDkyNiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYworKysg Yi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCkBAIC0zNTYsMTIgKzM1NiwxNCBA QCB2b2lkIHN0YXJ0X3NlY29uZGFyeSh2b2lkICp1bnVzZWQpCiAgICAgICAg IG1pY3JvY29kZV9yZXN1bWVfY3B1KGNwdSk7CiAKICAgICAvKgotICAgICAq IElmIE1TUl9TUEVDX0NUUkwgaXMgYXZhaWxhYmxlLCBhcHBseSBYZW4ncyBk ZWZhdWx0IHNldHRpbmcgYW5kIGRpc2NhcmQKLSAgICAgKiBhbnkgZmlybXdh cmUgc2V0dGluZ3MuICBOb3RlOiBNU1JfU1BFQ19DVFJMIG1heSBvbmx5IGJl Y29tZSBhdmFpbGFibGUKLSAgICAgKiBhZnRlciBsb2FkaW5nIG1pY3JvY29k ZS4KKyAgICAgKiBJZiBhbnkgc3BlY3VsYXRpdmUgY29udHJvbCBNU1JzIGFy ZSBhdmFpbGFibGUsIGFwcGx5IFhlbidzIGRlZmF1bHQKKyAgICAgKiBzZXR0 aW5ncy4gIE5vdGU6IFRoZXNlIE1TUnMgbWF5IG9ubHkgYmVjb21lIGF2YWls YWJsZSBhZnRlciBsb2FkaW5nCisgICAgICogbWljcm9jb2RlLgogICAgICAq LwogICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0lCUlNCKSAp CiAgICAgICAgIHdybXNybChNU1JfU1BFQ19DVFJMLCBkZWZhdWx0X3hlbl9z cGVjX2N0cmwpOworICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF X1NSQkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NU UkwsIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CiAKICAgICB0c3hfaW5p dCgpOyAvKiBOZWVkcyBtaWNyb2NvZGUuICBNYXkgY2hhbmdlIEhMRS9SVE0g ZmVhdHVyZSBiaXRzLiAqLwogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg ZTIxMmEyMDEyNy4uMjg5ZTkxZmIwNCAxMDA2NDQKLS0tIGEveGVuL2FyY2gv eDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu YwpAQCAtNjIsNiArNjIsOSBAQCBzdGF0aWMgdW5zaWduZWQgaW50IF9faW5p dGRhdGEgbDFkX21heHBoeXNhZGRyOwogc3RhdGljIGJvb2wgX19pbml0ZGF0 YSBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5OyAvKiA9PiBtaW5pbWFsIEhUIGlt cGFjdC4gKi8KIHN0YXRpYyBib29sIF9faW5pdGRhdGEgY3B1X2hhc19idWdf bWRzOyAvKiBBbnkgb3RoZXIgTXtMUCxTQixGQn1EUyBjb21iaW5hdGlvbi4g Ki8KIAorc3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9zcmJfbG9jayA9 IC0xOwordWludDY0X3QgX19yZWFkX21vc3RseSBkZWZhdWx0X3hlbl9tY3Vf b3B0X2N0cmw7CisKIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2J0aShjb25z dCBjaGFyICpzKQogewogICAgIGNvbnN0IGNoYXIgKnNzOwpAQCAtMTQ5LDYg KzE1Miw3IEBAIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChj aGFyICpzKQogICAgICAgICAgICAgb3B0X2licGIgPSBmYWxzZTsKICAgICAg ICAgICAgIG9wdF9zc2JkID0gZmFsc2U7CiAgICAgICAgICAgICBvcHRfbDFk X2ZsdXNoID0gMDsKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9IDA7CiAg ICAgICAgIH0KICAgICAgICAgZWxzZSBpZiAoIHZhbCA+IDAgKQogICAgICAg ICAgICAgcmMgPSAtRUlOVkFMOwpAQCAtMjE0LDYgKzIxOCw4IEBAIHN0YXRp YyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjaGFyICpzKQogICAgICAg ICAgICAgb3B0X2VhZ2VyX2ZwdSA9IHZhbDsKICAgICAgICAgZWxzZSBpZiAo ICh2YWwgPSBwYXJzZV9ib29sZWFuKCJsMWQtZmx1c2giLCBzLCBzcykpID49 IDAgKQogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9IHZhbDsKKyAgICAg ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJzcmItbG9jayIs IHMsIHNzKSkgPj0gMCApCisgICAgICAgICAgICBvcHRfc3JiX2xvY2sgPSB2 YWw7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJjID0gLUVJTlZBTDsK IApAQCAtMzc3LDcgKzM4Myw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmlu dF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rLCB1aW50NjRfdCBjYXBz KQogICAgICAgICAgICAgICAgIlxuIik7CiAKICAgICAvKiBTZXR0aW5ncyBm b3IgWGVuJ3MgcHJvdGVjdGlvbiwgaXJyZXNwZWN0aXZlIG9mIGd1ZXN0cy4g Ki8KLSAgICBwcmludGsoIiAgWGVuIHNldHRpbmdzOiBCVEktVGh1bmsgJXMs IFNQRUNfQ1RSTDogJXMlcyVzLCBPdGhlcjolcyVzJXNcbiIsCisgICAgcHJp bnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVzLCBTUEVDX0NUUkw6 ICVzJXMlcywgT3RoZXI6JXMlcyVzJXNcbiIsCiAgICAgICAgICAgIHRodW5r ID09IFRIVU5LX05PTkUgICAgICA/ICJOL0EiIDoKICAgICAgICAgICAgdGh1 bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBPTElORSIgOgogICAgICAg ICAgICB0aHVuayA9PSBUSFVOS19MRkVOQ0UgICAgPyAiTEZFTkNFIiA6CkBA IC0zODgsNiArMzk0LDggQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2Rl dGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVpbnQ2NF90IGNhcHMpCiAg ICAgICAgICAgIChkZWZhdWx0X3hlbl9zcGVjX2N0cmwgJiBTUEVDX0NUUkxf U1NCRCkgID8gIiBTU0JEKyIgOiAiIFNTQkQtIiwKICAgICAgICAgICAgIShj YXBzICYgQVJDSF9DQVBTX1RTWF9DVFJMKSAgICAgICAgICAgICAgPyAiIiA6 CiAgICAgICAgICAgIChvcHRfdHN4ICYgMSkgICAgICAgICAgICAgICAgICAg ICAgICAgICAgID8gIiBUU1grIiA6ICIgVFNYLSIsCisgICAgICAgICAgICFi b290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgICAgID8gIiIg OgorICAgICAgICAgICBvcHRfc3JiX2xvY2sgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA/ICIgU1JCX0xPQ0srIiA6ICIgU1JCX0xPQ0stIiwKICAg ICAgICAgICAgb3B0X2licGIgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPyAiIElCUEIiICA6ICIiLAogICAgICAgICAgICBvcHRfbDFkX2Zs dXNoICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgTDFEX0ZMVVNI IiA6ICIiLAogICAgICAgICAgICBvcHRfbWRfY2xlYXJfcHYgfHwgb3B0X21k X2NsZWFyX2h2bSAgICAgICA/ICIgVkVSVyIgIDogIiIpOwpAQCAtMTE1Miw2 ICsxMTYwLDM0IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0 aWdhdGlvbnModm9pZCkKICAgICAgICAgdHN4X2luaXQoKTsKICAgICB9CiAK KyAgICAvKiBDYWxjdWxhdGUgc3VpdGFibGUgZGVmYXVsdHMgZm9yIE1TUl9N Q1VfT1BUX0NUUkwgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2hhcyhYODZfRkVB VFVSRV9TUkJEU19DVFJMKSApCisgICAgeworICAgICAgICB1aW50NjRfdCB2 YWw7CisKKyAgICAgICAgcmRtc3JsKE1TUl9NQ1VfT1BUX0NUUkwsIHZhbCk7 CisKKyAgICAgICAgLyoKKyAgICAgICAgICogT24gc29tZSBTUkJEUy1hZmZl Y3RlZCBoYXJkd2FyZSwgaXQgbWF5IGJlIHNhZmUgdG8gcmVsYXggc3JiLWxv Y2sKKyAgICAgICAgICogYnkgZGVmYXVsdC4KKyAgICAgICAgICoKKyAgICAg ICAgICogT24gcGFydHMgd2hpY2ggZW51bWVyYXRlIE1EU19OTyBhbmQgbm90 IFRBQV9OTywgVFNYIGlzIHRoZSBvbmx5IHdheQorICAgICAgICAgKiB0byBh Y2Nlc3MgdGhlIEZpbGwgQnVmZmVyLiAgSWYgVFNYIGlzbid0IGF2YWlsYWJs ZSAoaW5jLiBTS1UKKyAgICAgICAgICogcmVhc29ucyBvbiBzb21lIG1vZGVs cyksIG9yIFRTWCBpcyBleHBsaWNpdGx5IGRpc2FibGVkLCB0aGVuIHRoZXJl CisgICAgICAgICAqIGlzIG5vIG5lZWQgZm9yIHRoZSBleHRyYSBvdmVyaGVh ZCB0byBwcm90ZWN0IFJEUkFORC9SRFNFRUQuCisgICAgICAgICAqLworICAg ICAgICBpZiAoIG9wdF9zcmJfbG9jayA9PSAtMSAmJgorICAgICAgICAgICAg IChjYXBzICYgKEFSQ0hfQ0FQU19NRFNfTk98QVJDSF9DQVBTX1RBQV9OTykp ID09IEFSQ0hfQ0FQU19NRFNfTk8gJiYKKyAgICAgICAgICAgICAoIWNwdV9o YXNfaGxlIHx8ICgoY2FwcyAmIEFSQ0hfQ0FQU19UU1hfQ1RSTCkgJiYgb3B0 X3RzeCA9PSAwKSkgKQorICAgICAgICAgICAgb3B0X3NyYl9sb2NrID0gMDsK KworICAgICAgICB2YWwgJj0gfk1DVV9PUFRfQ1RSTF9STkdEU19NSVRHX0RJ UzsKKyAgICAgICAgaWYgKCAhb3B0X3NyYl9sb2NrICkKKyAgICAgICAgICAg IHZhbCB8PSBNQ1VfT1BUX0NUUkxfUk5HRFNfTUlUR19ESVM7CisKKyAgICAg ICAgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsID0gdmFsOworICAgIH0KKwog ICAgIHByaW50X2RldGFpbHModGh1bmssIGNhcHMpOwogCiAgICAgLyoKQEAg LTExODMsNiArMTIxOSw5IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRp b25fbWl0aWdhdGlvbnModm9pZCkKIAogICAgICAgICB3cm1zcmwoTVNSX1NQ RUNfQ1RSTCwgYnNwX2RlbGF5X3NwZWNfY3RybCA/IDAgOiBkZWZhdWx0X3hl bl9zcGVjX2N0cmwpOwogICAgIH0KKworICAgIGlmICggYm9vdF9jcHVfaGFz KFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1T Ul9NQ1VfT1BUX0NUUkwsIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CiB9 CiAKIHN0YXRpYyB2b2lkIF9faW5pdCBfX21heWJlX3VudXNlZCBidWlsZF9h c3NlcnRpb25zKHZvaWQpCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9hc20t eDg2L3NwZWNfY3RybC5oIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0 cmwuaAppbmRleCA5OGEwYTUwNGY2Li5kZjg2MmVjNGQwIDEwMDY0NAotLS0g YS94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oCisrKyBiL3hlbi9p bmNsdWRlL2FzbS14ODYvc3BlY19jdHJsLmgKQEAgLTQ2LDYgKzQ2LDggQEAg ZXh0ZXJuIGludDhfdCBvcHRfcHZfbDF0Zl9od2RvbSwgb3B0X3B2X2wxdGZf ZG9tdTsKICAqLwogZXh0ZXJuIHBhZGRyX3QgbDF0Zl9hZGRyX21hc2ssIGwx dGZfc2FmZV9tYWRkcjsKIAorZXh0ZXJuIHVpbnQ2NF90IGRlZmF1bHRfeGVu X21jdV9vcHRfY3RybDsKKwogc3RhdGljIGlubGluZSB2b2lkIGluaXRfc2hh ZG93X3NwZWNfY3RybF9zdGF0ZSh2b2lkKQogewogICAgIHN0cnVjdCBjcHVf aW5mbyAqaW5mbyA9IGdldF9jcHVfaW5mbygpOwo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.10-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.10-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du IGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KaW5kZXgg MWYwOGRkZTE4Ni4uYWIyNmEyNjM4MSAxMDA2NDQKLS0tIGEvZG9jcy9taXNj L3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KKysrIGIvZG9jcy9taXNjL3hl bi1jb21tYW5kLWxpbmUubWFya2Rvd24KQEAgLTQ5NiwxMCArNDk2LDEwIEBA IGFjY291bnRpbmcgZm9yIGhhcmR3YXJlIGNhcGFiaWxpdGllcyBhcyBlbnVt ZXJhdGVkIHZpYSBDUFVJRC4KIAogQ3VycmVudGx5IGFjY2VwdGVkOgogCi1U aGUgU3BlY3VsYXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgbWQt Y2xlYXJgLCBgaWJyc2JgLCBgc3RpYnBgLCBgaWJwYmAsCi1gbDFkLWZsdXNo YCBhbmQgYHNzYmRgIGFyZSB1c2VkIGJ5IGRlZmF1bHQgaWYgYXZhaWxhYmxl IGFuZCBhcHBsaWNhYmxlLiAgVGhleSBjYW4KLWJlIGlnbm9yZWQsIGUuZy4g YG5vLWlicnNiYCwgYXQgd2hpY2ggcG9pbnQgWGVuIHdvbid0IHVzZSB0aGVt IGl0c2VsZiwgYW5kCi13b24ndCBvZmZlciB0aGVtIHRvIGd1ZXN0cy4KK1Ro ZSBTcGVjdWxhdGlvbiBDb250cm9sIGhhcmR3YXJlIGZlYXR1cmVzIGBzcmJk cy1jdHJsYCwgYG1kLWNsZWFyYCwgYGlicnNiYCwKK2BzdGlicGAsIGBpYnBi YCwgYGwxZC1mbHVzaGAgYW5kIGBzc2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0 IGlmIGF2YWlsYWJsZSBhbmQKK2FwcGxpY2FibGUuICBUaGV5IGNhbiBiZSBp Z25vcmVkLCBlLmcuIGBuby1pYnJzYmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3 b24ndAordXNlIHRoZW0gaXRzZWxmLCBhbmQgd29uJ3Qgb2ZmZXIgdGhlbSB0 byBndWVzdHMuCiAKICMjIyBjcHVpZFxfbWFza1xfY3B1IChBTUQgb25seSkK ID4gYD0gZmFtXzBmX3Jldl9jIHwgZmFtXzBmX3Jldl9kIHwgZmFtXzBmX3Jl dl9lIHwgZmFtXzBmX3Jldl9mIHwgZmFtXzBmX3Jldl9nIHwgZmFtXzEwX3Jl dl9iIHwgZmFtXzEwX3Jldl9jIHwgZmFtXzExX3Jldl9iYApkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhsL2xp YnhsX2NwdWlkLmMKaW5kZXggNWExNzAyZDcwMy4uMTIzNWM4YjkxZSAxMDA2 NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90b29s cy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0yMDIsNiArMjAyLDcgQEAgaW50 IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xpY3lf bGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKIAogICAgICAgICB7ImF2 eDUxMi00dm5uaXciLDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAg MiwgIDF9LAogICAgICAgICB7ImF2eDUxMi00Zm1hcHMiLDB4MDAwMDAwMDcs ICAwLCBDUFVJRF9SRUdfRURYLCAgMywgIDF9LAorICAgICAgICB7InNyYmRz LWN0cmwiLCAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAgOSwg IDF9LAogICAgICAgICB7Im1kLWNsZWFyIiwgICAgIDB4MDAwMDAwMDcsICAw LCBDUFVJRF9SRUdfRURYLCAxMCwgIDF9LAogICAgICAgICB7ImlicnNiIiwg ICAgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyNiwgIDF9 LAogICAgICAgICB7InN0aWJwIiwgICAgICAgIDB4MDAwMDAwMDcsICAwLCBD UFVJRF9SRUdfRURYLCAyNywgIDF9LApkaWZmIC0tZ2l0IGEvdG9vbHMvbWlz Yy94ZW4tY3B1aWQuYyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKaW5kZXgg ODlkNTBlMDQ4Yy4uN2Y5NjEyZjBhOSAxMDA2NDQKLS0tIGEvdG9vbHMvbWlz Yy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNjL3hlbi1jcHVpZC5jCkBA IC0xNjIsOCArMTYyLDkgQEAgc3RhdGljIGNvbnN0IGNoYXIgKnN0cl83ZDBb MzJdID0KIAogICAgIFsgMl0gPSAiYXZ4NTEyXzR2bm5pdyIsIFsgM10gPSAi YXZ4NTEyXzRmbWFwcyIsCiAKLSAgICBbNCAuLi4gOV0gPSAiUkVaIiwKKyAg ICBbNCAuLi4gN10gPSAiUkVaIiwKIAorICAgIFsgOF0gPSAiUkVaIiwgICAg ICAgICAgIFsgOV0gPSAic3JiZHMtY3RybCIsCiAgICAgWzEwXSA9ICJtZC1j bGVhciIsICAgICAgWzExXSA9ICJSRVoiLAogICAgIFsxMl0gPSAiUkVaIiwg ICAgICAgICAgIFsxM10gPSAidHN4LWZvcmNlLWFib3J0IiwKIApkaWZmIC0t Z2l0IGEveGVuL2FyY2gveDg2L2NwdWlkLmMgYi94ZW4vYXJjaC94ODYvY3B1 aWQuYwppbmRleCBlOTQzZDcwYmNhLi42N2EyYTJlNmEwIDEwMDY0NAotLS0g YS94ZW4vYXJjaC94ODYvY3B1aWQuYworKysgYi94ZW4vYXJjaC94ODYvY3B1 aWQuYwpAQCAtNTgsNiArNTgsMTEgQEAgc3RhdGljIGludCBfX2luaXQgcGFy c2VfeGVuX2NwdWlkKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBpZiAo ICF2YWwgKQogICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2NwdV9jYXAo WDg2X0ZFQVRVUkVfU1NCRCk7CiAgICAgICAgIH0KKyAgICAgICAgZWxzZSBp ZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJzcmJkcy1jdHJsIiwgcywgc3Mp KSA+PSAwICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCAhdmFsICkK KyAgICAgICAgICAgICAgICBzZXR1cF9jbGVhcl9jcHVfY2FwKFg4Nl9GRUFU VVJFX1NSQkRTX0NUUkwpOworICAgICAgICB9CiAgICAgICAgIGVsc2UKICAg ICAgICAgICAgIHJjID0gLUVJTlZBTDsKIApkaWZmIC0tZ2l0IGEveGVuL2Fy Y2gveDg2L21zci5jIGIveGVuL2FyY2gveDg2L21zci5jCmluZGV4IDZjZWVh OTEzZmIuLjkwNTYxYTUzOTIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9t c3IuYworKysgYi94ZW4vYXJjaC94ODYvbXNyLmMKQEAgLTEzNSw2ICsxMzUs NyBAQCBpbnQgZ3Vlc3RfcmRtc3IoY29uc3Qgc3RydWN0IHZjcHUgKnYsIHVp bnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKICAgICAgICAgLyogV3JpdGUt b25seSAqLwogICAgIGNhc2UgTVNSX1RTWF9GT1JDRV9BQk9SVDoKICAgICBj YXNlIE1TUl9UU1hfQ1RSTDoKKyAgICBjYXNlIE1TUl9NQ1VfT1BUX0NUUkw6 CiAgICAgICAgIC8qIE5vdCBvZmZlcmVkIHRvIGd1ZXN0cy4gKi8KICAgICAg ICAgZ290byBncF9mYXVsdDsKIApAQCAtMTk0LDYgKzE5NSw3IEBAIGludCBn dWVzdF93cm1zcihzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyLCB1aW50 NjRfdCB2YWwpCiAgICAgICAgIC8qIFJlYWQtb25seSAqLwogICAgIGNhc2Ug TVNSX1RTWF9GT1JDRV9BQk9SVDoKICAgICBjYXNlIE1TUl9UU1hfQ1RSTDoK KyAgICBjYXNlIE1TUl9NQ1VfT1BUX0NUUkw6CiAgICAgICAgIC8qIE5vdCBv ZmZlcmVkIHRvIGd1ZXN0cy4gKi8KICAgICAgICAgZ290byBncF9mYXVsdDsK IApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jIGIveGVu L2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDBmMzAzNjIxMTEuLmI3NzMz YjM0ZjYgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwor KysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTM0OSwxMiArMzQ5 LDEzIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0g aW5kX3RodW5rIHRodW5rLCB1aW50NjRfdCBjYXBzKQogICAgIHByaW50aygi U3BlY3VsYXRpdmUgbWl0aWdhdGlvbiBmYWNpbGl0aWVzOlxuIik7CiAKICAg ICAvKiBIYXJkd2FyZSBmZWF0dXJlcyB3aGljaCBwZXJ0YWluIHRvIHNwZWN1 bGF0aXZlIG1pdGlnYXRpb25zLiAqLwotICAgIHByaW50aygiICBIYXJkd2Fy ZSBmZWF0dXJlczolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAor ICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMl cyVzJXMlcyVzJXMlcyVzJXNcbiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1 ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNCKSkgPyAiIElCUlMvSUJQQiIg OiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZF QVRVUkVfU1RJQlApKSA/ICIgU1RJQlAiICAgICA6ICIiLAogICAgICAgICAg ICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9MMURfRkxVU0gp KSA/ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICAoXzdkMCAmIGNw dWZlYXRfbWFzayhYODZfRkVBVFVSRV9TU0JEKSkgID8gIiBTU0JEIiAgICAg IDogIiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1ZmVhdF9tYXNrKFg4Nl9G RUFUVVJFX01EX0NMRUFSKSkgPyAiIE1EX0NMRUFSIiA6ICIiLAorICAgICAg ICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TUkJEU19D VFJMKSkgPyAiIFNSQkRTX0NUUkwiIDogIiIsCiAgICAgICAgICAgIChlOGIg ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUEIpKSAgPyAiIElCUEIi ICAgICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfSUJS U19BTEwpICAgICAgICAgICAgICA/ICIgSUJSU19BTEwiICA6ICIiLAogICAg ICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19SRENMX05PKSAgICAgICAgICAg ICAgID8gIiBSRENMX05PIiAgIDogIiIsCmRpZmYgLS1naXQgYS94ZW4vaW5j bHVkZS9hc20teDg2L21zci1pbmRleC5oIGIveGVuL2luY2x1ZGUvYXNtLXg4 Ni9tc3ItaW5kZXguaAppbmRleCA1ZWY4MDczNWIyLi5kMTQzNWRiNmEzIDEw MDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRleC5oCisr KyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4LmgKQEAgLTE3Nyw2 ICsxNzcsOSBAQAogI2RlZmluZSBNU1JfSUEzMl9WTVhfVFJVRV9FTlRSWV9D VExTICAgICAgICAgICAgMHg0OTAKICNkZWZpbmUgTVNSX0lBMzJfVk1YX1ZN RlVOQyAgICAgICAgICAgICAgICAgICAgIDB4NDkxCiAKKyNkZWZpbmUgTVNS X01DVV9PUFRfQ1RSTCAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDEyMwor I2RlZmluZSAgTUNVX09QVF9DVFJMX1JOR0RTX01JVEdfRElTICAgICAgICAo X0FDKDEsIFVMTCkgPDwgIDApCisKIC8qIEs3L0s4IE1TUnMuIE5vdCBjb21w bGV0ZS4gU2VlIHRoZSBhcmNoaXRlY3R1cmUgbWFudWFsIGZvciBhIG1vcmUK ICAgIGNvbXBsZXRlIGxpc3QuICovCiAjZGVmaW5lIE1TUl9LN19FVk5UU0VM MAkJCTB4YzAwMTAwMDAKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1Ymxp Yy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9wdWJs aWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IGExNGQ4YTcwMTMu LjlkMjEwZTc0YTAgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9h cmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKKysrIGIveGVuL2luY2x1ZGUvcHVi bGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaApAQCAtMjQyLDYgKzI0Miw3 IEBAIFhFTl9DUFVGRUFUVVJFKElCUEIsICAgICAgICAgIDgqMzIrMTIpIC8q QSAgSUJQQiBzdXBwb3J0IG9ubHkgKG5vIElCUlMsIHVzZWQgYnkKIC8qIElu dGVsLWRlZmluZWQgQ1BVIGZlYXR1cmVzLCBDUFVJRCBsZXZlbCAweDAwMDAw MDA3OjAuZWR4LCB3b3JkIDkgKi8KIFhFTl9DUFVGRUFUVVJFKEFWWDUxMl80 Vk5OSVcsIDkqMzIrIDIpIC8qQSAgQVZYNTEyIE5ldXJhbCBOZXR3b3JrIElu c3RydWN0aW9ucyAqLwogWEVOX0NQVUZFQVRVUkUoQVZYNTEyXzRGTUFQUywg OSozMisgMykgLypBICBBVlg1MTIgTXVsdGlwbHkgQWNjdW11bGF0aW9uIFNp bmdsZSBQcmVjaXNpb24gKi8KK1hFTl9DUFVGRUFUVVJFKFNSQkRTX0NUUkws ICAgIDkqMzIrIDkpIC8qICAgTVNSX01DVV9PUFRfQ1RSTCBhbmQgUk5HRFNf TUlUR19ESVMuICovCiBYRU5fQ1BVRkVBVFVSRShNRF9DTEVBUiwgICAgICA5 KjMyKzEwKSAvKkEgIFZFUlcgY2xlYXJzIG1pY3JvYXJjaGl0ZWN0dXJhbCBi dWZmZXJzICovCiBYRU5fQ1BVRkVBVFVSRShUU1hfRk9SQ0VfQUJPUlQsIDkq MzIrMTMpIC8qIE1TUl9UU1hfRk9SQ0VfQUJPUlQuUlRNX0FCT1JUICovCiBY RU5fQ1BVRkVBVFVSRShJQlJTQiwgICAgICAgICA5KjMyKzI2KSAvKkEgIElC UlMgYW5kIElCUEIgc3VwcG9ydCAodXNlZCBieSBJbnRlbCkgKi8K --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.10-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.10-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5t YXJrZG93biBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du CmluZGV4IGFiMjZhMjYzODEuLmI5NmY5M2M5NWUgMTAwNjQ0Ci0tLSBhL2Rv Y3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBiL2RvY3Mv bWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCkBAIC0xODA5LDcgKzE4 MDksNyBAQCBmYWxzZSBkaXNhYmxlIHRoZSBxdWlyayB3b3JrYXJvdW5kLCB3 aGljaCBpcyBhbHNvIHRoZSBkZWZhdWx0LgogIyMjIHNwZWMtY3RybCAoeDg2 KQogPiBgPSBMaXN0IG9mIFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZt LG1zci1zYyxyc2IsbWQtY2xlYXJ9PTxib29sPiwKID4gICAgICAgICAgICAg IGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZlbmNlfGptcCwge2licnMsaWJwYixz c2JkLGVhZ2VyLWZwdSwKLT4gICAgICAgICAgICAgIGwxZC1mbHVzaH09PGJv b2w+IF1gCis+ICAgICAgICAgICAgICBsMWQtZmx1c2gsc3JiLWxvY2t9PTxi b29sPiBdYAogCiBDb250cm9scyBmb3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9u IHNpZGVjaGFubmVsIG1pdGlnYXRpb25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3 aWxsIHBpY2sgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFz ZWQgb24gY29tcGlsZWQgaW4gc3VwcG9ydCwKQEAgLTE4ODEsNiArMTg4MSwx MiBAQCBJcnJlc3BlY3RpdmUgb2YgWGVuJ3Mgc2V0dGluZywgdGhlIGZlYXR1 cmUgaXMgdmlydHVhbGlzZWQgZm9yIEhWTSBndWVzdHMgdG8KIHVzZS4gIEJ5 IGRlZmF1bHQsIFhlbiB3aWxsIGVuYWJsZSB0aGlzIG1pdGlnYXRpb24gb24g aGFyZHdhcmUgYmVsaWV2ZWQgdG8gYmUKIHZ1bG5lcmFibGUgdG8gTDFURi4K IAorT24gaGFyZHdhcmUgc3VwcG9ydGluZyBTUkJEU19DVFJMLCB0aGUgYHNy Yi1sb2NrPWAgb3B0aW9uIGNhbiBiZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2 ZW50IFhlbiBmcm9tIHByb3RlY3QgdGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVm ZmVyIGZyb20gbGVha2luZyBzdGFsZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVu IHdpbGwgZW5hYmxlIHRoaXMgbWl0aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRz IHdoZXJlIE1EUworaXMgZml4ZWQgYW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0 ZWQgKGluIHdoaWNoIGNhc2UsIHRoZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5v Cit3YXkgZm9yIGFuIGF0dGFja2VyIHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0 YSkuCisKICMjIyBzeW5jXF9jb25zb2xlCiA+IGA9IDxib29sZWFuPmAKIApk aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYyBiL3hlbi9h cmNoL3g4Ni9hY3BpL3Bvd2VyLmMKaW5kZXggZjM0ODBhYTgwMC4uNGQ3MmI2 Y2U5NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwor KysgYi94ZW4vYXJjaC94ODYvYWNwaS9wb3dlci5jCkBAIC0yNTksNiArMjU5 LDkgQEAgc3RhdGljIGludCBlbnRlcl9zdGF0ZSh1MzIgc3RhdGUpCiAgICAg Y2ktPnNwZWNfY3RybF9mbGFncyB8PSAoZGVmYXVsdF9zcGVjX2N0cmxfZmxh Z3MgJiBTQ0ZfaXN0X3dybXNyKTsKICAgICBzcGVjX2N0cmxfZXhpdF9pZGxl KGNpKTsKIAorICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NS QkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkws IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CisKICBkb25lOgogICAgIHNw aW5fZGVidWdfZW5hYmxlKCk7CiAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh Z3MpOwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYyBiL3hl bi9hcmNoL3g4Ni9zbXBib290LmMKaW5kZXggY2RmNTNhZmMxZS4uYjRhMDlm MmRjMiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYworKysg Yi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCkBAIC0zNjMsMTIgKzM2MywxNCBA QCB2b2lkIHN0YXJ0X3NlY29uZGFyeSh2b2lkICp1bnVzZWQpCiAgICAgICAg IG1pY3JvY29kZV9yZXN1bWVfY3B1KGNwdSk7CiAKICAgICAvKgotICAgICAq IElmIE1TUl9TUEVDX0NUUkwgaXMgYXZhaWxhYmxlLCBhcHBseSBYZW4ncyBk ZWZhdWx0IHNldHRpbmcgYW5kIGRpc2NhcmQKLSAgICAgKiBhbnkgZmlybXdh cmUgc2V0dGluZ3MuICBOb3RlOiBNU1JfU1BFQ19DVFJMIG1heSBvbmx5IGJl Y29tZSBhdmFpbGFibGUKLSAgICAgKiBhZnRlciBsb2FkaW5nIG1pY3JvY29k ZS4KKyAgICAgKiBJZiBhbnkgc3BlY3VsYXRpdmUgY29udHJvbCBNU1JzIGFy ZSBhdmFpbGFibGUsIGFwcGx5IFhlbidzIGRlZmF1bHQKKyAgICAgKiBzZXR0 aW5ncy4gIE5vdGU6IFRoZXNlIE1TUnMgbWF5IG9ubHkgYmVjb21lIGF2YWls YWJsZSBhZnRlciBsb2FkaW5nCisgICAgICogbWljcm9jb2RlLgogICAgICAq LwogICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0lCUlNCKSAp CiAgICAgICAgIHdybXNybChNU1JfU1BFQ19DVFJMLCBkZWZhdWx0X3hlbl9z cGVjX2N0cmwpOworICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF X1NSQkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NU UkwsIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CiAKICAgICB0c3hfaW5p dCgpOyAvKiBOZWVkcyBtaWNyb2NvZGUuICBNYXkgY2hhbmdlIEhMRS9SVE0g ZmVhdHVyZSBiaXRzLiAqLwogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg Yjc3MzNiMzRmNi4uY2MwOTQ2Yjk2MyAxMDA2NDQKLS0tIGEveGVuL2FyY2gv eDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu YwpAQCAtNjMsNiArNjMsOSBAQCBzdGF0aWMgdW5zaWduZWQgaW50IF9faW5p dGRhdGEgbDFkX21heHBoeXNhZGRyOwogc3RhdGljIGJvb2wgX19pbml0ZGF0 YSBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5OyAvKiA9PiBtaW5pbWFsIEhUIGlt cGFjdC4gKi8KIHN0YXRpYyBib29sIF9faW5pdGRhdGEgY3B1X2hhc19idWdf bWRzOyAvKiBBbnkgb3RoZXIgTXtMUCxTQixGQn1EUyBjb21iaW5hdGlvbi4g Ki8KIAorc3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9zcmJfbG9jayA9 IC0xOwordWludDY0X3QgX19yZWFkX21vc3RseSBkZWZhdWx0X3hlbl9tY3Vf b3B0X2N0cmw7CisKIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2J0aShjb25z dCBjaGFyICpzKQogewogICAgIGNvbnN0IGNoYXIgKnNzOwpAQCAtMTUwLDYg KzE1Myw3IEBAIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChj b25zdCBjaGFyICpzKQogICAgICAgICAgICAgb3B0X2licGIgPSBmYWxzZTsK ICAgICAgICAgICAgIG9wdF9zc2JkID0gZmFsc2U7CiAgICAgICAgICAgICBv cHRfbDFkX2ZsdXNoID0gMDsKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9 IDA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZSBpZiAoIHZhbCA+IDAgKQog ICAgICAgICAgICAgcmMgPSAtRUlOVkFMOwpAQCAtMjE1LDYgKzIxOSw4IEBA IHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFy ICpzKQogICAgICAgICAgICAgb3B0X2VhZ2VyX2ZwdSA9IHZhbDsKICAgICAg ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJsMWQtZmx1c2gi LCBzLCBzcykpID49IDAgKQogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9 IHZhbDsKKyAgICAgICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFu KCJzcmItbG9jayIsIHMsIHNzKSkgPj0gMCApCisgICAgICAgICAgICBvcHRf c3JiX2xvY2sgPSB2YWw7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJj ID0gLUVJTlZBTDsKIApAQCAtMzc4LDcgKzM4NCw3IEBAIHN0YXRpYyB2b2lk IF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rLCB1 aW50NjRfdCBjYXBzKQogICAgICAgICAgICAgICAgIlxuIik7CiAKICAgICAv KiBTZXR0aW5ncyBmb3IgWGVuJ3MgcHJvdGVjdGlvbiwgaXJyZXNwZWN0aXZl IG9mIGd1ZXN0cy4gKi8KLSAgICBwcmludGsoIiAgWGVuIHNldHRpbmdzOiBC VEktVGh1bmsgJXMsIFNQRUNfQ1RSTDogJXMlcyVzLCBPdGhlcjolcyVzJXNc biIsCisgICAgcHJpbnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVz LCBTUEVDX0NUUkw6ICVzJXMlcywgT3RoZXI6JXMlcyVzJXNcbiIsCiAgICAg ICAgICAgIHRodW5rID09IFRIVU5LX05PTkUgICAgICA/ICJOL0EiIDoKICAg ICAgICAgICAgdGh1bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBPTElO RSIgOgogICAgICAgICAgICB0aHVuayA9PSBUSFVOS19MRkVOQ0UgICAgPyAi TEZFTkNFIiA6CkBAIC0zODksNiArMzk1LDggQEAgc3RhdGljIHZvaWQgX19p bml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVpbnQ2 NF90IGNhcHMpCiAgICAgICAgICAgIChkZWZhdWx0X3hlbl9zcGVjX2N0cmwg JiBTUEVDX0NUUkxfU1NCRCkgID8gIiBTU0JEKyIgOiAiIFNTQkQtIiwKICAg ICAgICAgICAgIShjYXBzICYgQVJDSF9DQVBTX1RTWF9DVFJMKSAgICAgICAg ICAgICAgPyAiIiA6CiAgICAgICAgICAgIChvcHRfdHN4ICYgMSkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID8gIiBUU1grIiA6ICIgVFNYLSIsCisg ICAgICAgICAgICFib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RS TCkgICAgID8gIiIgOgorICAgICAgICAgICBvcHRfc3JiX2xvY2sgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA/ICIgU1JCX0xPQ0srIiA6ICIgU1JC X0xPQ0stIiwKICAgICAgICAgICAgb3B0X2licGIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPyAiIElCUEIiICA6ICIiLAogICAgICAgICAg ICBvcHRfbDFkX2ZsdXNoICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICBvcHRfbWRfY2xlYXJf cHYgfHwgb3B0X21kX2NsZWFyX2h2bSAgICAgICA/ICIgVkVSVyIgIDogIiIp OwpAQCAtMTE3Niw2ICsxMTg0LDM0IEBAIHZvaWQgX19pbml0IGluaXRfc3Bl Y3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKICAgICAgICAgdHN4X2luaXQo KTsKICAgICB9CiAKKyAgICAvKiBDYWxjdWxhdGUgc3VpdGFibGUgZGVmYXVs dHMgZm9yIE1TUl9NQ1VfT1BUX0NUUkwgKi8KKyAgICBpZiAoIGJvb3RfY3B1 X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSApCisgICAgeworICAgICAg ICB1aW50NjRfdCB2YWw7CisKKyAgICAgICAgcmRtc3JsKE1TUl9NQ1VfT1BU X0NUUkwsIHZhbCk7CisKKyAgICAgICAgLyoKKyAgICAgICAgICogT24gc29t ZSBTUkJEUy1hZmZlY3RlZCBoYXJkd2FyZSwgaXQgbWF5IGJlIHNhZmUgdG8g cmVsYXggc3JiLWxvY2sKKyAgICAgICAgICogYnkgZGVmYXVsdC4KKyAgICAg ICAgICoKKyAgICAgICAgICogT24gcGFydHMgd2hpY2ggZW51bWVyYXRlIE1E U19OTyBhbmQgbm90IFRBQV9OTywgVFNYIGlzIHRoZSBvbmx5IHdheQorICAg ICAgICAgKiB0byBhY2Nlc3MgdGhlIEZpbGwgQnVmZmVyLiAgSWYgVFNYIGlz bid0IGF2YWlsYWJsZSAoaW5jLiBTS1UKKyAgICAgICAgICogcmVhc29ucyBv biBzb21lIG1vZGVscyksIG9yIFRTWCBpcyBleHBsaWNpdGx5IGRpc2FibGVk LCB0aGVuIHRoZXJlCisgICAgICAgICAqIGlzIG5vIG5lZWQgZm9yIHRoZSBl eHRyYSBvdmVyaGVhZCB0byBwcm90ZWN0IFJEUkFORC9SRFNFRUQuCisgICAg ICAgICAqLworICAgICAgICBpZiAoIG9wdF9zcmJfbG9jayA9PSAtMSAmJgor ICAgICAgICAgICAgIChjYXBzICYgKEFSQ0hfQ0FQU19NRFNfTk98QVJDSF9D QVBTX1RBQV9OTykpID09IEFSQ0hfQ0FQU19NRFNfTk8gJiYKKyAgICAgICAg ICAgICAoIWNwdV9oYXNfaGxlIHx8ICgoY2FwcyAmIEFSQ0hfQ0FQU19UU1hf Q1RSTCkgJiYgb3B0X3RzeCA9PSAwKSkgKQorICAgICAgICAgICAgb3B0X3Ny Yl9sb2NrID0gMDsKKworICAgICAgICB2YWwgJj0gfk1DVV9PUFRfQ1RSTF9S TkdEU19NSVRHX0RJUzsKKyAgICAgICAgaWYgKCAhb3B0X3NyYl9sb2NrICkK KyAgICAgICAgICAgIHZhbCB8PSBNQ1VfT1BUX0NUUkxfUk5HRFNfTUlUR19E SVM7CisKKyAgICAgICAgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsID0gdmFs OworICAgIH0KKwogICAgIHByaW50X2RldGFpbHModGh1bmssIGNhcHMpOwog CiAgICAgLyoKQEAgLTEyMDcsNiArMTI0Myw5IEBAIHZvaWQgX19pbml0IGlu aXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKIAogICAgICAgICB3 cm1zcmwoTVNSX1NQRUNfQ1RSTCwgYnNwX2RlbGF5X3NwZWNfY3RybCA/IDAg OiBkZWZhdWx0X3hlbl9zcGVjX2N0cmwpOwogICAgIH0KKworICAgIGlmICgg Ym9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICAg ICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkwsIGRlZmF1bHRfeGVuX21jdV9v cHRfY3RybCk7CiB9CiAKIHN0YXRpYyB2b2lkIF9faW5pdCBfX21heWJlX3Vu dXNlZCBidWlsZF9hc3NlcnRpb25zKHZvaWQpCmRpZmYgLS1naXQgYS94ZW4v aW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oIGIveGVuL2luY2x1ZGUvYXNt LXg4Ni9zcGVjX2N0cmwuaAppbmRleCA5OGEwYTUwNGY2Li5kZjg2MmVjNGQw IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5o CisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvc3BlY19jdHJsLmgKQEAgLTQ2 LDYgKzQ2LDggQEAgZXh0ZXJuIGludDhfdCBvcHRfcHZfbDF0Zl9od2RvbSwg b3B0X3B2X2wxdGZfZG9tdTsKICAqLwogZXh0ZXJuIHBhZGRyX3QgbDF0Zl9h ZGRyX21hc2ssIGwxdGZfc2FmZV9tYWRkcjsKIAorZXh0ZXJuIHVpbnQ2NF90 IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybDsKKwogc3RhdGljIGlubGluZSB2 b2lkIGluaXRfc2hhZG93X3NwZWNfY3RybF9zdGF0ZSh2b2lkKQogewogICAg IHN0cnVjdCBjcHVfaW5mbyAqaW5mbyA9IGdldF9jcHVfaW5mbygpOwo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.11-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.11-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du IGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KaW5kZXgg MTk0NjE1YmZjNS4uOWJlMThhYzk5ZiAxMDA2NDQKLS0tIGEvZG9jcy9taXNj L3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KKysrIGIvZG9jcy9taXNjL3hl bi1jb21tYW5kLWxpbmUubWFya2Rvd24KQEAgLTQ4OSwxMCArNDg5LDEwIEBA IGFjY291bnRpbmcgZm9yIGhhcmR3YXJlIGNhcGFiaWxpdGllcyBhcyBlbnVt ZXJhdGVkIHZpYSBDUFVJRC4KIAogQ3VycmVudGx5IGFjY2VwdGVkOgogCi1U aGUgU3BlY3VsYXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgbWQt Y2xlYXJgLCBgaWJyc2JgLCBgc3RpYnBgLCBgaWJwYmAsCi1gbDFkLWZsdXNo YCBhbmQgYHNzYmRgIGFyZSB1c2VkIGJ5IGRlZmF1bHQgaWYgYXZhaWxhYmxl IGFuZCBhcHBsaWNhYmxlLiAgVGhleSBjYW4KLWJlIGlnbm9yZWQsIGUuZy4g YG5vLWlicnNiYCwgYXQgd2hpY2ggcG9pbnQgWGVuIHdvbid0IHVzZSB0aGVt IGl0c2VsZiwgYW5kCi13b24ndCBvZmZlciB0aGVtIHRvIGd1ZXN0cy4KK1Ro ZSBTcGVjdWxhdGlvbiBDb250cm9sIGhhcmR3YXJlIGZlYXR1cmVzIGBzcmJk cy1jdHJsYCwgYG1kLWNsZWFyYCwgYGlicnNiYCwKK2BzdGlicGAsIGBpYnBi YCwgYGwxZC1mbHVzaGAgYW5kIGBzc2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0 IGlmIGF2YWlsYWJsZSBhbmQKK2FwcGxpY2FibGUuICBUaGV5IGNhbiBiZSBp Z25vcmVkLCBlLmcuIGBuby1pYnJzYmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3 b24ndAordXNlIHRoZW0gaXRzZWxmLCBhbmQgd29uJ3Qgb2ZmZXIgdGhlbSB0 byBndWVzdHMuCiAKICMjIyBjcHVpZFxfbWFza1xfY3B1IChBTUQgb25seSkK ID4gYD0gZmFtXzBmX3Jldl9jIHwgZmFtXzBmX3Jldl9kIHwgZmFtXzBmX3Jl dl9lIHwgZmFtXzBmX3Jldl9mIHwgZmFtXzBmX3Jldl9nIHwgZmFtXzEwX3Jl dl9iIHwgZmFtXzEwX3Jldl9jIHwgZmFtXzExX3Jldl9iYApkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhsL2xp YnhsX2NwdWlkLmMKaW5kZXggNWExNzAyZDcwMy4uMTIzNWM4YjkxZSAxMDA2 NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90b29s cy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0yMDIsNiArMjAyLDcgQEAgaW50 IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xpY3lf bGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKIAogICAgICAgICB7ImF2 eDUxMi00dm5uaXciLDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAg MiwgIDF9LAogICAgICAgICB7ImF2eDUxMi00Zm1hcHMiLDB4MDAwMDAwMDcs ICAwLCBDUFVJRF9SRUdfRURYLCAgMywgIDF9LAorICAgICAgICB7InNyYmRz LWN0cmwiLCAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAgOSwg IDF9LAogICAgICAgICB7Im1kLWNsZWFyIiwgICAgIDB4MDAwMDAwMDcsICAw LCBDUFVJRF9SRUdfRURYLCAxMCwgIDF9LAogICAgICAgICB7ImlicnNiIiwg ICAgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyNiwgIDF9 LAogICAgICAgICB7InN0aWJwIiwgICAgICAgIDB4MDAwMDAwMDcsICAwLCBD UFVJRF9SRUdfRURYLCAyNywgIDF9LApkaWZmIC0tZ2l0IGEvdG9vbHMvbWlz Yy94ZW4tY3B1aWQuYyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKaW5kZXgg NGM5YWY2YjdmMC4uOGZiNTRjMzAwMSAxMDA2NDQKLS0tIGEvdG9vbHMvbWlz Yy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNjL3hlbi1jcHVpZC5jCkBA IC0xNDIsNiArMTQyLDcgQEAgc3RhdGljIGNvbnN0IGNoYXIgKnN0cl83ZDBb MzJdID0KIHsKICAgICBbIDJdID0gImF2eDUxMl80dm5uaXciLCBbIDNdID0g ImF2eDUxMl80Zm1hcHMiLAogCisgICAgLyogIDggKi8gICAgICAgICAgICAg ICAgWyA5XSA9ICJzcmJkcy1jdHJsIiwKICAgICBbMTBdID0gIm1kLWNsZWFy IiwKICAgICAvKiAxMiAqLyAgICAgICAgICAgICAgICBbMTNdID0gInRzeC1m b3JjZS1hYm9ydCIsCiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jcHVp ZC5jIGIveGVuL2FyY2gveDg2L2NwdWlkLmMKaW5kZXggMDRhZWZhNTU1ZC4u YjhlNWI2ZmU2NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NwdWlkLmMK KysrIGIveGVuL2FyY2gveDg2L2NwdWlkLmMKQEAgLTU4LDYgKzU4LDExIEBA IHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3hlbl9jcHVpZChjb25zdCBjaGFy ICpzKQogICAgICAgICAgICAgaWYgKCAhdmFsICkKICAgICAgICAgICAgICAg ICBzZXR1cF9jbGVhcl9jcHVfY2FwKFg4Nl9GRUFUVVJFX1NTQkQpOwogICAg ICAgICB9CisgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVh bigic3JiZHMtY3RybCIsIHMsIHNzKSkgPj0gMCApCisgICAgICAgIHsKKyAg ICAgICAgICAgIGlmICggIXZhbCApCisgICAgICAgICAgICAgICAgc2V0dXBf Y2xlYXJfY3B1X2NhcChYODZfRkVBVFVSRV9TUkJEU19DVFJMKTsKKyAgICAg ICAgfQogICAgICAgICBlbHNlCiAgICAgICAgICAgICByYyA9IC1FSU5WQUw7 CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tc3IuYyBiL3hlbi9hcmNo L3g4Ni9tc3IuYwppbmRleCBjY2IzMTZjNTQ3Li4yNTZlNThkODJiIDEwMDY0 NAotLS0gYS94ZW4vYXJjaC94ODYvbXNyLmMKKysrIGIveGVuL2FyY2gveDg2 L21zci5jCkBAIC0xNTQsNiArMTU0LDcgQEAgaW50IGd1ZXN0X3JkbXNyKGNv bnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2 YWwpCiAgICAgICAgIC8qIFdyaXRlLW9ubHkgKi8KICAgICBjYXNlIE1TUl9U U1hfRk9SQ0VfQUJPUlQ6CiAgICAgY2FzZSBNU1JfVFNYX0NUUkw6CisgICAg Y2FzZSBNU1JfTUNVX09QVF9DVFJMOgogICAgICAgICAvKiBOb3Qgb2ZmZXJl ZCB0byBndWVzdHMuICovCiAgICAgICAgIGdvdG8gZ3BfZmF1bHQ7CiAKQEAg LTI0Myw2ICsyNDQsNyBAQCBpbnQgZ3Vlc3Rfd3Jtc3Ioc3RydWN0IHZjcHUg KnYsIHVpbnQzMl90IG1zciwgdWludDY0X3QgdmFsKQogICAgICAgICAvKiBS ZWFkLW9ubHkgKi8KICAgICBjYXNlIE1TUl9UU1hfRk9SQ0VfQUJPUlQ6CiAg ICAgY2FzZSBNU1JfVFNYX0NUUkw6CisgICAgY2FzZSBNU1JfTUNVX09QVF9D VFJMOgogICAgICAgICAvKiBOb3Qgb2ZmZXJlZCB0byBndWVzdHMuICovCiAg ICAgICAgIGdvdG8gZ3BfZmF1bHQ7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNo L3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpp bmRleCBhYjE5NmIxNTZkLi45NGFiOGRkNzg2IDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNf Y3RybC5jCkBAIC0zNjUsMTIgKzM2NSwxMyBAQCBzdGF0aWMgdm9pZCBfX2lu aXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0 X3QgY2FwcykKICAgICBwcmludGsoIlNwZWN1bGF0aXZlIG1pdGlnYXRpb24g ZmFjaWxpdGllczpcbiIpOwogCiAgICAgLyogSGFyZHdhcmUgZmVhdHVyZXMg d2hpY2ggcGVydGFpbiB0byBzcGVjdWxhdGl2ZSBtaXRpZ2F0aW9ucy4gKi8K LSAgICBwcmludGsoIiAgSGFyZHdhcmUgZmVhdHVyZXM6JXMlcyVzJXMlcyVz JXMlcyVzJXMlcyVzJXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUg ZmVhdHVyZXM6JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAog ICAgICAgICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9J QlJTQikpID8gIiBJQlJTL0lCUEIiIDogIiIsCiAgICAgICAgICAgIChfN2Qw ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX1NUSUJQKSkgPyAiIFNUSUJQ IiAgICAgOiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2so WDg2X0ZFQVRVUkVfTDFEX0ZMVVNIKSkgPyAiIEwxRF9GTFVTSCIgOiAiIiwK ICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVf U1NCRCkpICA/ICIgU1NCRCIgICAgICA6ICIiLAogICAgICAgICAgICAoXzdk MCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9NRF9DTEVBUikpID8gIiBN RF9DTEVBUiIgOiAiIiwKKyAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21h c2soWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkpID8gIiBTUkJEU19DVFJMIiA6 ICIiLAogICAgICAgICAgICAoZThiICAmIGNwdWZlYXRfbWFzayhYODZfRkVB VFVSRV9JQlBCKSkgID8gIiBJQlBCIiAgICAgIDogIiIsCiAgICAgICAgICAg IChjYXBzICYgQVJDSF9DQVBTX0lCUlNfQUxMKSAgICAgICAgICAgICAgPyAi IElCUlNfQUxMIiAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NB UFNfUkRDTF9OTykgICAgICAgICAgICAgICA/ICIgUkRDTF9OTyIgICA6ICIi LApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3ItaW5kZXgu aCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4LmgKaW5kZXggMTc2 MWEwMWYxZi4uNDgwZDFkODEwMiAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUv YXNtLXg4Ni9tc3ItaW5kZXguaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2 L21zci1pbmRleC5oCkBAIC0xNzcsNiArMTc3LDkgQEAKICNkZWZpbmUgTVNS X0lBMzJfVk1YX1RSVUVfRU5UUllfQ1RMUyAgICAgICAgICAgIDB4NDkwCiAj ZGVmaW5lIE1TUl9JQTMyX1ZNWF9WTUZVTkMgICAgICAgICAgICAgICAgICAg ICAweDQ5MQogCisjZGVmaW5lIE1TUl9NQ1VfT1BUX0NUUkwgICAgICAgICAg ICAgICAgICAgIDB4MDAwMDAxMjMKKyNkZWZpbmUgIE1DVV9PUFRfQ1RSTF9S TkdEU19NSVRHX0RJUyAgICAgICAgKF9BQygxLCBVTEwpIDw8ICAwKQorCiAv KiBLNy9LOCBNU1JzLiBOb3QgY29tcGxldGUuIFNlZSB0aGUgYXJjaGl0ZWN0 dXJlIG1hbnVhbCBmb3IgYSBtb3JlCiAgICBjb21wbGV0ZSBsaXN0LiAqLwog I2RlZmluZSBNU1JfSzdfRVZOVFNFTDAJCQkweGMwMDEwMDAwCmRpZmYgLS1n aXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNl dC5oIGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVz ZXQuaAppbmRleCBhMTRkOGE3MDEzLi45ZDIxMGU3NGEwIDEwMDY0NAotLS0g YS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5o CisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJl c2V0LmgKQEAgLTI0Miw2ICsyNDIsNyBAQCBYRU5fQ1BVRkVBVFVSRShJQlBC LCAgICAgICAgICA4KjMyKzEyKSAvKkEgIElCUEIgc3VwcG9ydCBvbmx5IChu byBJQlJTLCB1c2VkIGJ5CiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl cywgQ1BVSUQgbGV2ZWwgMHgwMDAwMDAwNzowLmVkeCwgd29yZCA5ICovCiBY RU5fQ1BVRkVBVFVSRShBVlg1MTJfNFZOTklXLCA5KjMyKyAyKSAvKkEgIEFW WDUxMiBOZXVyYWwgTmV0d29yayBJbnN0cnVjdGlvbnMgKi8KIFhFTl9DUFVG RUFUVVJFKEFWWDUxMl80Rk1BUFMsIDkqMzIrIDMpIC8qQSAgQVZYNTEyIE11 bHRpcGx5IEFjY3VtdWxhdGlvbiBTaW5nbGUgUHJlY2lzaW9uICovCitYRU5f Q1BVRkVBVFVSRShTUkJEU19DVFJMLCAgICA5KjMyKyA5KSAvKiAgIE1TUl9N Q1VfT1BUX0NUUkwgYW5kIFJOR0RTX01JVEdfRElTLiAqLwogWEVOX0NQVUZF QVRVUkUoTURfQ0xFQVIsICAgICAgOSozMisxMCkgLypBICBWRVJXIGNsZWFy cyBtaWNyb2FyY2hpdGVjdHVyYWwgYnVmZmVycyAqLwogWEVOX0NQVUZFQVRV UkUoVFNYX0ZPUkNFX0FCT1JULCA5KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNF X0FCT1JULlJUTV9BQk9SVCAqLwogWEVOX0NQVUZFQVRVUkUoSUJSU0IsICAg ICAgICAgOSozMisyNikgLypBICBJQlJTIGFuZCBJQlBCIHN1cHBvcnQgKHVz ZWQgYnkgSW50ZWwpICovCg== --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.11-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.11-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5t YXJrZG93biBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du CmluZGV4IDliZTE4YWM5OWYuLjMzNTZlNTlmZWUgMTAwNjQ0Ci0tLSBhL2Rv Y3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBiL2RvY3Mv bWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCkBAIC0xODU4LDcgKzE4 NTgsNyBAQCBmYWxzZSBkaXNhYmxlIHRoZSBxdWlyayB3b3JrYXJvdW5kLCB3 aGljaCBpcyBhbHNvIHRoZSBkZWZhdWx0LgogIyMjIHNwZWMtY3RybCAoeDg2 KQogPiBgPSBMaXN0IG9mIFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZt LG1zci1zYyxyc2IsbWQtY2xlYXJ9PTxib29sPiwKID4gICAgICAgICAgICAg IGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZlbmNlfGptcCwge2licnMsaWJwYixz c2JkLGVhZ2VyLWZwdSwKLT4gICAgICAgICAgICAgIGwxZC1mbHVzaH09PGJv b2w+IF1gCis+ICAgICAgICAgICAgICBsMWQtZmx1c2gsc3JiLWxvY2t9PTxi b29sPiBdYAogCiBDb250cm9scyBmb3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9u IHNpZGVjaGFubmVsIG1pdGlnYXRpb25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3 aWxsIHBpY2sgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFz ZWQgb24gY29tcGlsZWQgaW4gc3VwcG9ydCwKQEAgLTE5MzAsNiArMTkzMCwx MiBAQCBJcnJlc3BlY3RpdmUgb2YgWGVuJ3Mgc2V0dGluZywgdGhlIGZlYXR1 cmUgaXMgdmlydHVhbGlzZWQgZm9yIEhWTSBndWVzdHMgdG8KIHVzZS4gIEJ5 IGRlZmF1bHQsIFhlbiB3aWxsIGVuYWJsZSB0aGlzIG1pdGlnYXRpb24gb24g aGFyZHdhcmUgYmVsaWV2ZWQgdG8gYmUKIHZ1bG5lcmFibGUgdG8gTDFURi4K IAorT24gaGFyZHdhcmUgc3VwcG9ydGluZyBTUkJEU19DVFJMLCB0aGUgYHNy Yi1sb2NrPWAgb3B0aW9uIGNhbiBiZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2 ZW50IFhlbiBmcm9tIHByb3RlY3QgdGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVm ZmVyIGZyb20gbGVha2luZyBzdGFsZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVu IHdpbGwgZW5hYmxlIHRoaXMgbWl0aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRz IHdoZXJlIE1EUworaXMgZml4ZWQgYW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0 ZWQgKGluIHdoaWNoIGNhc2UsIHRoZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5v Cit3YXkgZm9yIGFuIGF0dGFja2VyIHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0 YSkuCisKICMjIyBzeW5jXF9jb25zb2xlCiA+IGA9IDxib29sZWFuPmAKIApk aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYyBiL3hlbi9h cmNoL3g4Ni9hY3BpL3Bvd2VyLmMKaW5kZXggNGMxMjc5NDgwOS4uMzBlMWJk NWNkMyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwor KysgYi94ZW4vYXJjaC94ODYvYWNwaS9wb3dlci5jCkBAIC0yNjYsNiArMjY2 LDkgQEAgc3RhdGljIGludCBlbnRlcl9zdGF0ZSh1MzIgc3RhdGUpCiAgICAg Y2ktPnNwZWNfY3RybF9mbGFncyB8PSAoZGVmYXVsdF9zcGVjX2N0cmxfZmxh Z3MgJiBTQ0ZfaXN0X3dybXNyKTsKICAgICBzcGVjX2N0cmxfZXhpdF9pZGxl KGNpKTsKIAorICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NS QkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkws IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CisKICBkb25lOgogICAgIHNw aW5fZGVidWdfZW5hYmxlKCk7CiAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh Z3MpOwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYyBiL3hl bi9hcmNoL3g4Ni9zbXBib290LmMKaW5kZXggMDg4NzgwNmU4NS4uZDI0ZDIx NTk0NiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYworKysg Yi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCkBAIC0zNjksMTIgKzM2OSwxNCBA QCB2b2lkIHN0YXJ0X3NlY29uZGFyeSh2b2lkICp1bnVzZWQpCiAgICAgICAg IG1pY3JvY29kZV9yZXN1bWVfY3B1KGNwdSk7CiAKICAgICAvKgotICAgICAq IElmIE1TUl9TUEVDX0NUUkwgaXMgYXZhaWxhYmxlLCBhcHBseSBYZW4ncyBk ZWZhdWx0IHNldHRpbmcgYW5kIGRpc2NhcmQKLSAgICAgKiBhbnkgZmlybXdh cmUgc2V0dGluZ3MuICBOb3RlOiBNU1JfU1BFQ19DVFJMIG1heSBvbmx5IGJl Y29tZSBhdmFpbGFibGUKLSAgICAgKiBhZnRlciBsb2FkaW5nIG1pY3JvY29k ZS4KKyAgICAgKiBJZiBhbnkgc3BlY3VsYXRpdmUgY29udHJvbCBNU1JzIGFy ZSBhdmFpbGFibGUsIGFwcGx5IFhlbidzIGRlZmF1bHQKKyAgICAgKiBzZXR0 aW5ncy4gIE5vdGU6IFRoZXNlIE1TUnMgbWF5IG9ubHkgYmVjb21lIGF2YWls YWJsZSBhZnRlciBsb2FkaW5nCisgICAgICogbWljcm9jb2RlLgogICAgICAq LwogICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0lCUlNCKSAp CiAgICAgICAgIHdybXNybChNU1JfU1BFQ19DVFJMLCBkZWZhdWx0X3hlbl9z cGVjX2N0cmwpOworICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF X1NSQkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NU UkwsIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CiAKICAgICB0c3hfaW5p dCgpOyAvKiBOZWVkcyBtaWNyb2NvZGUuICBNYXkgY2hhbmdlIEhMRS9SVE0g ZmVhdHVyZSBiaXRzLiAqLwogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg OTRhYjhkZDc4Ni4uYTMwNmQxMGMzNCAxMDA2NDQKLS0tIGEveGVuL2FyY2gv eDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu YwpAQCAtNjMsNiArNjMsOSBAQCBzdGF0aWMgdW5zaWduZWQgaW50IF9faW5p dGRhdGEgbDFkX21heHBoeXNhZGRyOwogc3RhdGljIGJvb2wgX19pbml0ZGF0 YSBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5OyAvKiA9PiBtaW5pbWFsIEhUIGlt cGFjdC4gKi8KIHN0YXRpYyBib29sIF9faW5pdGRhdGEgY3B1X2hhc19idWdf bWRzOyAvKiBBbnkgb3RoZXIgTXtMUCxTQixGQn1EUyBjb21iaW5hdGlvbi4g Ki8KIAorc3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9zcmJfbG9jayA9 IC0xOwordWludDY0X3QgX19yZWFkX21vc3RseSBkZWZhdWx0X3hlbl9tY3Vf b3B0X2N0cmw7CisKIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2J0aShjb25z dCBjaGFyICpzKQogewogICAgIGNvbnN0IGNoYXIgKnNzOwpAQCAtMTY2LDYg KzE2OSw3IEBAIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChj b25zdCBjaGFyICpzKQogICAgICAgICAgICAgb3B0X2licGIgPSBmYWxzZTsK ICAgICAgICAgICAgIG9wdF9zc2JkID0gZmFsc2U7CiAgICAgICAgICAgICBv cHRfbDFkX2ZsdXNoID0gMDsKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9 IDA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZSBpZiAoIHZhbCA+IDAgKQog ICAgICAgICAgICAgcmMgPSAtRUlOVkFMOwpAQCAtMjMxLDYgKzIzNSw4IEBA IHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFy ICpzKQogICAgICAgICAgICAgb3B0X2VhZ2VyX2ZwdSA9IHZhbDsKICAgICAg ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJsMWQtZmx1c2gi LCBzLCBzcykpID49IDAgKQogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9 IHZhbDsKKyAgICAgICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFu KCJzcmItbG9jayIsIHMsIHNzKSkgPj0gMCApCisgICAgICAgICAgICBvcHRf c3JiX2xvY2sgPSB2YWw7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJj ID0gLUVJTlZBTDsKIApAQCAtMzk0LDcgKzQwMCw3IEBAIHN0YXRpYyB2b2lk IF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rLCB1 aW50NjRfdCBjYXBzKQogICAgICAgICAgICAgICAgIlxuIik7CiAKICAgICAv KiBTZXR0aW5ncyBmb3IgWGVuJ3MgcHJvdGVjdGlvbiwgaXJyZXNwZWN0aXZl IG9mIGd1ZXN0cy4gKi8KLSAgICBwcmludGsoIiAgWGVuIHNldHRpbmdzOiBC VEktVGh1bmsgJXMsIFNQRUNfQ1RSTDogJXMlcyVzLCBPdGhlcjolcyVzJXNc biIsCisgICAgcHJpbnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVz LCBTUEVDX0NUUkw6ICVzJXMlcywgT3RoZXI6JXMlcyVzJXNcbiIsCiAgICAg ICAgICAgIHRodW5rID09IFRIVU5LX05PTkUgICAgICA/ICJOL0EiIDoKICAg ICAgICAgICAgdGh1bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBPTElO RSIgOgogICAgICAgICAgICB0aHVuayA9PSBUSFVOS19MRkVOQ0UgICAgPyAi TEZFTkNFIiA6CkBAIC00MDUsNiArNDExLDggQEAgc3RhdGljIHZvaWQgX19p bml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVpbnQ2 NF90IGNhcHMpCiAgICAgICAgICAgIChkZWZhdWx0X3hlbl9zcGVjX2N0cmwg JiBTUEVDX0NUUkxfU1NCRCkgID8gIiBTU0JEKyIgOiAiIFNTQkQtIiwKICAg ICAgICAgICAgIShjYXBzICYgQVJDSF9DQVBTX1RTWF9DVFJMKSAgICAgICAg ICAgICAgPyAiIiA6CiAgICAgICAgICAgIChvcHRfdHN4ICYgMSkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID8gIiBUU1grIiA6ICIgVFNYLSIsCisg ICAgICAgICAgICFib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RS TCkgICAgID8gIiIgOgorICAgICAgICAgICBvcHRfc3JiX2xvY2sgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA/ICIgU1JCX0xPQ0srIiA6ICIgU1JC X0xPQ0stIiwKICAgICAgICAgICAgb3B0X2licGIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPyAiIElCUEIiICA6ICIiLAogICAgICAgICAg ICBvcHRfbDFkX2ZsdXNoICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICBvcHRfbWRfY2xlYXJf cHYgfHwgb3B0X21kX2NsZWFyX2h2bSAgICAgICA/ICIgVkVSVyIgIDogIiIp OwpAQCAtMTE5Niw2ICsxMjA0LDM0IEBAIHZvaWQgX19pbml0IGluaXRfc3Bl Y3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKICAgICAgICAgdHN4X2luaXQo KTsKICAgICB9CiAKKyAgICAvKiBDYWxjdWxhdGUgc3VpdGFibGUgZGVmYXVs dHMgZm9yIE1TUl9NQ1VfT1BUX0NUUkwgKi8KKyAgICBpZiAoIGJvb3RfY3B1 X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSApCisgICAgeworICAgICAg ICB1aW50NjRfdCB2YWw7CisKKyAgICAgICAgcmRtc3JsKE1TUl9NQ1VfT1BU X0NUUkwsIHZhbCk7CisKKyAgICAgICAgLyoKKyAgICAgICAgICogT24gc29t ZSBTUkJEUy1hZmZlY3RlZCBoYXJkd2FyZSwgaXQgbWF5IGJlIHNhZmUgdG8g cmVsYXggc3JiLWxvY2sKKyAgICAgICAgICogYnkgZGVmYXVsdC4KKyAgICAg ICAgICoKKyAgICAgICAgICogT24gcGFydHMgd2hpY2ggZW51bWVyYXRlIE1E U19OTyBhbmQgbm90IFRBQV9OTywgVFNYIGlzIHRoZSBvbmx5IHdheQorICAg ICAgICAgKiB0byBhY2Nlc3MgdGhlIEZpbGwgQnVmZmVyLiAgSWYgVFNYIGlz bid0IGF2YWlsYWJsZSAoaW5jLiBTS1UKKyAgICAgICAgICogcmVhc29ucyBv biBzb21lIG1vZGVscyksIG9yIFRTWCBpcyBleHBsaWNpdGx5IGRpc2FibGVk LCB0aGVuIHRoZXJlCisgICAgICAgICAqIGlzIG5vIG5lZWQgZm9yIHRoZSBl eHRyYSBvdmVyaGVhZCB0byBwcm90ZWN0IFJEUkFORC9SRFNFRUQuCisgICAg ICAgICAqLworICAgICAgICBpZiAoIG9wdF9zcmJfbG9jayA9PSAtMSAmJgor ICAgICAgICAgICAgIChjYXBzICYgKEFSQ0hfQ0FQU19NRFNfTk98QVJDSF9D QVBTX1RBQV9OTykpID09IEFSQ0hfQ0FQU19NRFNfTk8gJiYKKyAgICAgICAg ICAgICAoIWNwdV9oYXNfaGxlIHx8ICgoY2FwcyAmIEFSQ0hfQ0FQU19UU1hf Q1RSTCkgJiYgb3B0X3RzeCA9PSAwKSkgKQorICAgICAgICAgICAgb3B0X3Ny Yl9sb2NrID0gMDsKKworICAgICAgICB2YWwgJj0gfk1DVV9PUFRfQ1RSTF9S TkdEU19NSVRHX0RJUzsKKyAgICAgICAgaWYgKCAhb3B0X3NyYl9sb2NrICkK KyAgICAgICAgICAgIHZhbCB8PSBNQ1VfT1BUX0NUUkxfUk5HRFNfTUlUR19E SVM7CisKKyAgICAgICAgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsID0gdmFs OworICAgIH0KKwogICAgIHByaW50X2RldGFpbHModGh1bmssIGNhcHMpOwog CiAgICAgLyoKQEAgLTEyMjcsNiArMTI2Myw5IEBAIHZvaWQgX19pbml0IGlu aXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKIAogICAgICAgICB3 cm1zcmwoTVNSX1NQRUNfQ1RSTCwgYnNwX2RlbGF5X3NwZWNfY3RybCA/IDAg OiBkZWZhdWx0X3hlbl9zcGVjX2N0cmwpOwogICAgIH0KKworICAgIGlmICgg Ym9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICAg ICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkwsIGRlZmF1bHRfeGVuX21jdV9v cHRfY3RybCk7CiB9CiAKIHN0YXRpYyB2b2lkIF9faW5pdCBfX21heWJlX3Vu dXNlZCBidWlsZF9hc3NlcnRpb25zKHZvaWQpCmRpZmYgLS1naXQgYS94ZW4v aW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oIGIveGVuL2luY2x1ZGUvYXNt LXg4Ni9zcGVjX2N0cmwuaAppbmRleCAzMzNkMTgwYjdlLi5iZjEwZDJjZTVj IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5o CisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvc3BlY19jdHJsLmgKQEAgLTQ2 LDYgKzQ2LDggQEAgZXh0ZXJuIGludDhfdCBvcHRfcHZfbDF0Zl9od2RvbSwg b3B0X3B2X2wxdGZfZG9tdTsKICAqLwogZXh0ZXJuIHBhZGRyX3QgbDF0Zl9h ZGRyX21hc2ssIGwxdGZfc2FmZV9tYWRkcjsKIAorZXh0ZXJuIHVpbnQ2NF90 IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybDsKKwogc3RhdGljIGlubGluZSB2 b2lkIGluaXRfc2hhZG93X3NwZWNfY3RybF9zdGF0ZSh2b2lkKQogewogICAg IHN0cnVjdCBjcHVfaW5mbyAqaW5mbyA9IGdldF9jcHVfaW5mbygpOwo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.12-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.12-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyBi L2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYwppbmRleCAzNTYx ZDg4YjU5Li5kYmRhZWU5MmRjIDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVu LWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21t YW5kLWxpbmUucGFuZG9jCkBAIC00ODMsMTAgKzQ4MywxMCBAQCBhY2NvdW50 aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXMgZW51bWVyYXRlZCB2 aWEgQ1BVSUQuCiAKIEN1cnJlbnRseSBhY2NlcHRlZDoKIAotVGhlIFNwZWN1 bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVhdHVyZXMgYG1kLWNsZWFyYCwg YGlicnNiYCwgYHN0aWJwYCwgYGlicGJgLAotYGwxZC1mbHVzaGAgYW5kIGBz c2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0IGlmIGF2YWlsYWJsZSBhbmQgYXBw bGljYWJsZS4gIFRoZXkgY2FuCi1iZSBpZ25vcmVkLCBlLmcuIGBuby1pYnJz YmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3b24ndCB1c2UgdGhlbSBpdHNlbGYs IGFuZAotd29uJ3Qgb2ZmZXIgdGhlbSB0byBndWVzdHMuCitUaGUgU3BlY3Vs YXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgc3JiZHMtY3RybGAs IGBtZC1jbGVhcmAsIGBpYnJzYmAsCitgc3RpYnBgLCBgaWJwYmAsIGBsMWQt Zmx1c2hgIGFuZCBgc3NiZGAgYXJlIHVzZWQgYnkgZGVmYXVsdCBpZiBhdmFp bGFibGUgYW5kCithcHBsaWNhYmxlLiAgVGhleSBjYW4gYmUgaWdub3JlZCwg ZS5nLiBgbm8taWJyc2JgLCBhdCB3aGljaCBwb2ludCBYZW4gd29uJ3QKK3Vz ZSB0aGVtIGl0c2VsZiwgYW5kIHdvbid0IG9mZmVyIHRoZW0gdG8gZ3Vlc3Rz LgogCiAjIyMgY3B1aWRfbWFza19jcHUKID4gYD0gZmFtXzBmX3Jldl9bY2Rl ZmddIHwgZmFtXzEwX3Jldl9bYmNdIHwgZmFtXzExX3Jldl9iYApkaWZmIC0t Z2l0IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhs L2xpYnhsX2NwdWlkLmMKaW5kZXggNGNmMGYwNzM4ZC4uODhiNTc2MGM4NSAx MDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90 b29scy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0yMDMsNiArMjAzLDcgQEAg aW50IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xp Y3lfbGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKIAogICAgICAgICB7 ImF2eDUxMi00dm5uaXciLDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURY LCAgMiwgIDF9LAogICAgICAgICB7ImF2eDUxMi00Zm1hcHMiLDB4MDAwMDAw MDcsICAwLCBDUFVJRF9SRUdfRURYLCAgMywgIDF9LAorICAgICAgICB7InNy YmRzLWN0cmwiLCAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAg OSwgIDF9LAogICAgICAgICB7Im1kLWNsZWFyIiwgICAgIDB4MDAwMDAwMDcs ICAwLCBDUFVJRF9SRUdfRURYLCAxMCwgIDF9LAogICAgICAgICB7ImNldC1p YnQiLCAgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyMCwg IDF9LAogICAgICAgICB7ImlicnNiIiwgICAgICAgIDB4MDAwMDAwMDcsICAw LCBDUFVJRF9SRUdfRURYLCAyNiwgIDF9LApkaWZmIC0tZ2l0IGEvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKaW5k ZXggMmEwMDY5NzY0My4uYjRjNGRmY2YxOSAxMDA2NDQKLS0tIGEvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNjL3hlbi1jcHVpZC5j CkBAIC0xNTQsNiArMTU0LDcgQEAgc3RhdGljIGNvbnN0IGNoYXIgKnN0cl83 ZDBbMzJdID0KICAgICBbIDJdID0gImF2eDUxMl80dm5uaXciLCBbIDNdID0g ImF2eDUxMl80Zm1hcHMiLAogICAgIFsgNF0gPSAiZnNybSIsCiAKKyAgICAv KiAgOCAqLyAgICAgICAgICAgICAgICBbIDldID0gInNyYmRzLWN0cmwiLAog ICAgIFsxMF0gPSAibWQtY2xlYXIiLAogICAgIC8qIDEyICovICAgICAgICAg ICAgICAgIFsxM10gPSAidHN4LWZvcmNlLWFib3J0IiwKIApkaWZmIC0tZ2l0 IGEveGVuL2FyY2gveDg2L2NwdWlkLmMgYi94ZW4vYXJjaC94ODYvY3B1aWQu YwppbmRleCAxNzI3NDk3NDU5Li4yMmQ4YzcxYTk1IDEwMDY0NAotLS0gYS94 ZW4vYXJjaC94ODYvY3B1aWQuYworKysgYi94ZW4vYXJjaC94ODYvY3B1aWQu YwpAQCAtNTksNiArNTksMTEgQEAgc3RhdGljIGludCBfX2luaXQgcGFyc2Vf eGVuX2NwdWlkKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBpZiAoICF2 YWwgKQogICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2NwdV9jYXAoWDg2 X0ZFQVRVUkVfU1NCRCk7CiAgICAgICAgIH0KKyAgICAgICAgZWxzZSBpZiAo ICh2YWwgPSBwYXJzZV9ib29sZWFuKCJzcmJkcy1jdHJsIiwgcywgc3MpKSA+ PSAwICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCAhdmFsICkKKyAg ICAgICAgICAgICAgICBzZXR1cF9jbGVhcl9jcHVfY2FwKFg4Nl9GRUFUVVJF X1NSQkRTX0NUUkwpOworICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAg ICAgICAgIHJjID0gLUVJTlZBTDsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gv eDg2L21zci5jIGIveGVuL2FyY2gveDg2L21zci5jCmluZGV4IDQ4ODhmZmYx NmMuLjlmZjI3YjcwMDcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tc3Iu YworKysgYi94ZW4vYXJjaC94ODYvbXNyLmMKQEAgLTEzMyw2ICsxMzMsNyBA QCBpbnQgZ3Vlc3RfcmRtc3IoY29uc3Qgc3RydWN0IHZjcHUgKnYsIHVpbnQz Ml90IG1zciwgdWludDY0X3QgKnZhbCkKICAgICAgICAgLyogV3JpdGUtb25s eSAqLwogICAgIGNhc2UgTVNSX1RTWF9GT1JDRV9BQk9SVDoKICAgICBjYXNl IE1TUl9UU1hfQ1RSTDoKKyAgICBjYXNlIE1TUl9NQ1VfT1BUX0NUUkw6CiAg ICAgY2FzZSBNU1JfVV9DRVQ6CiAgICAgY2FzZSBNU1JfU19DRVQ6CiAgICAg Y2FzZSBNU1JfUEwwX1NTUCAuLi4gTVNSX0lOVEVSUlVQVF9TU1BfVEFCTEU6 CkBAIC0yNzMsNiArMjc0LDcgQEAgaW50IGd1ZXN0X3dybXNyKHN0cnVjdCB2 Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90IHZhbCkKICAgICAgICAg LyogUmVhZC1vbmx5ICovCiAgICAgY2FzZSBNU1JfVFNYX0ZPUkNFX0FCT1JU OgogICAgIGNhc2UgTVNSX1RTWF9DVFJMOgorICAgIGNhc2UgTVNSX01DVV9P UFRfQ1RSTDoKICAgICBjYXNlIE1TUl9VX0NFVDoKICAgICBjYXNlIE1TUl9T X0NFVDoKICAgICBjYXNlIE1TUl9QTDBfU1NQIC4uLiBNU1JfSU5URVJSVVBU X1NTUF9UQUJMRToKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0 cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwppbmRleCA4MDAxMzlk NzljLi41MTU4ZTAxMmNhIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvc3Bl Y19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCkBAIC0z MDksMTIgKzMwOSwxMyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRfZGV0 YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0X3QgY2FwcykKICAg ICBwcmludGsoIlNwZWN1bGF0aXZlIG1pdGlnYXRpb24gZmFjaWxpdGllczpc biIpOwogCiAgICAgLyogSGFyZHdhcmUgZmVhdHVyZXMgd2hpY2ggcGVydGFp biB0byBzcGVjdWxhdGl2ZSBtaXRpZ2F0aW9ucy4gKi8KLSAgICBwcmludGso IiAgSGFyZHdhcmUgZmVhdHVyZXM6JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVz JXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUgZmVhdHVyZXM6JXMl cyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAogICAgICAgICAgICAo XzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9JQlJTQikpID8gIiBJ QlJTL0lCUEIiIDogIiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1ZmVhdF9t YXNrKFg4Nl9GRUFUVVJFX1NUSUJQKSkgPyAiIFNUSUJQIiAgICAgOiAiIiwK ICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVf TDFEX0ZMVVNIKSkgPyAiIEwxRF9GTFVTSCIgOiAiIiwKICAgICAgICAgICAg KF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfU1NCRCkpICA/ICIg U1NCRCIgICAgICA6ICIiLAogICAgICAgICAgICAoXzdkMCAmIGNwdWZlYXRf bWFzayhYODZfRkVBVFVSRV9NRF9DTEVBUikpID8gIiBNRF9DTEVBUiIgOiAi IiwKKyAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRV UkVfU1JCRFNfQ1RSTCkpID8gIiBTUkJEU19DVFJMIiA6ICIiLAogICAgICAg ICAgICAoZThiICAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9JQlBCKSkg ID8gIiBJQlBCIiAgICAgIDogIiIsCiAgICAgICAgICAgIChjYXBzICYgQVJD SF9DQVBTX0lCUlNfQUxMKSAgICAgICAgICAgICAgPyAiIElCUlNfQUxMIiAg OiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfUkRDTF9OTykg ICAgICAgICAgICAgICA/ICIgUkRDTF9OTyIgICA6ICIiLApkaWZmIC0tZ2l0 IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3ItaW5kZXguaCBiL3hlbi9pbmNs dWRlL2FzbS14ODYvbXNyLWluZGV4LmgKaW5kZXggNzY5M2M0YTcxYS4uOTE5 OTQ2NjllMSAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3It aW5kZXguaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRleC5o CkBAIC0xNzksNiArMTc5LDkgQEAKICNkZWZpbmUgTVNSX0lBMzJfVk1YX1RS VUVfRU5UUllfQ1RMUyAgICAgICAgICAgIDB4NDkwCiAjZGVmaW5lIE1TUl9J QTMyX1ZNWF9WTUZVTkMgICAgICAgICAgICAgICAgICAgICAweDQ5MQogCisj ZGVmaW5lIE1TUl9NQ1VfT1BUX0NUUkwgICAgICAgICAgICAgICAgICAgIDB4 MDAwMDAxMjMKKyNkZWZpbmUgIE1DVV9PUFRfQ1RSTF9STkdEU19NSVRHX0RJ UyAgICAgICAgKF9BQygxLCBVTEwpIDw8ICAwKQorCiAjZGVmaW5lIE1TUl9V X0NFVCAgICAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAwMDA2YTAKICNk ZWZpbmUgTVNSX1NfQ0VUICAgICAgICAgICAgICAgICAgICAgICAgICAgMHgw MDAwMDZhMgogI2RlZmluZSBNU1JfUEwwX1NTUCAgICAgICAgICAgICAgICAg ICAgICAgICAweDAwMDAwNmE0CmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9w dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oIGIveGVuL2luY2x1ZGUv cHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaAppbmRleCA4NjVhNDM1 ZDJjLi4zMTQ5MGE3YzEwIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9wdWJs aWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNsdWRl L3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTI0Myw2ICsy NDMsNyBAQCBYRU5fQ1BVRkVBVFVSRShJQlBCLCAgICAgICAgICA4KjMyKzEy KSAvKkEgIElCUEIgc3VwcG9ydCBvbmx5IChubyBJQlJTLCB1c2VkIGJ5CiAv KiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJlcywgQ1BVSUQgbGV2ZWwgMHgw MDAwMDAwNzowLmVkeCwgd29yZCA5ICovCiBYRU5fQ1BVRkVBVFVSRShBVlg1 MTJfNFZOTklXLCA5KjMyKyAyKSAvKkEgIEFWWDUxMiBOZXVyYWwgTmV0d29y ayBJbnN0cnVjdGlvbnMgKi8KIFhFTl9DUFVGRUFUVVJFKEFWWDUxMl80Rk1B UFMsIDkqMzIrIDMpIC8qQSAgQVZYNTEyIE11bHRpcGx5IEFjY3VtdWxhdGlv biBTaW5nbGUgUHJlY2lzaW9uICovCitYRU5fQ1BVRkVBVFVSRShTUkJEU19D VFJMLCAgICA5KjMyKyA5KSAvKiAgIE1TUl9NQ1VfT1BUX0NUUkwgYW5kIFJO R0RTX01JVEdfRElTLiAqLwogWEVOX0NQVUZFQVRVUkUoTURfQ0xFQVIsICAg ICAgOSozMisxMCkgLypBICBWRVJXIGNsZWFycyBtaWNyb2FyY2hpdGVjdHVy YWwgYnVmZmVycyAqLwogWEVOX0NQVUZFQVRVUkUoVFNYX0ZPUkNFX0FCT1JU LCA5KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNFX0FCT1JULlJUTV9BQk9SVCAq LwogWEVOX0NQVUZFQVRVUkUoQ0VUX0lCVCwgICAgICAgOSozMisyMCkgLyog ICBDRVQgLSBJbmRpcmVjdCBCcmFuY2ggVHJhY2tpbmcgKi8K --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.12-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.12-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5w YW5kb2MgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKaW5k ZXggZGJkYWVlOTJkYy4uMzM3ZmJmMDQ5MiAxMDA2NDQKLS0tIGEvZG9jcy9t aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCisrKyBiL2RvY3MvbWlzYy94 ZW4tY29tbWFuZC1saW5lLnBhbmRvYwpAQCAtMTkwOSw3ICsxOTA5LDcgQEAg QnkgZGVmYXVsdCBTU0JEIHdpbGwgYmUgbWl0aWdhdGVkIGF0IHJ1bnRpbWUg KGkuZSBgc3NiZD1ydW50aW1lYCkuCiAjIyMgc3BlYy1jdHJsICh4ODYpCiA+ IGA9IExpc3Qgb2YgWyA8Ym9vbD4sIHhlbj08Ym9vbD4sIHtwdixodm0sbXNy LXNjLHJzYixtZC1jbGVhcn09PGJvb2w+LAogPiAgICAgICAgICAgICAgYnRp LXRodW5rPXJldHBvbGluZXxsZmVuY2V8am1wLCB7aWJycyxpYnBiLHNzYmQs ZWFnZXItZnB1LAotPiAgICAgICAgICAgICAgbDFkLWZsdXNofT08Ym9vbD4g XWAKKz4gICAgICAgICAgICAgIGwxZC1mbHVzaCxzcmItbG9ja309PGJvb2w+ IF1gCiAKIENvbnRyb2xzIGZvciBzcGVjdWxhdGl2ZSBleGVjdXRpb24gc2lk ZWNoYW5uZWwgbWl0aWdhdGlvbnMuICBCeSBkZWZhdWx0LCBYZW4KIHdpbGwg cGljayB0aGUgbW9zdCBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9ucyBiYXNlZCBv biBjb21waWxlZCBpbiBzdXBwb3J0LApAQCAtMTk4MSw2ICsxOTgxLDEyIEBA IElycmVzcGVjdGl2ZSBvZiBYZW4ncyBzZXR0aW5nLCB0aGUgZmVhdHVyZSBp cyB2aXJ0dWFsaXNlZCBmb3IgSFZNIGd1ZXN0cyB0bwogdXNlLiAgQnkgZGVm YXVsdCwgWGVuIHdpbGwgZW5hYmxlIHRoaXMgbWl0aWdhdGlvbiBvbiBoYXJk d2FyZSBiZWxpZXZlZCB0byBiZQogdnVsbmVyYWJsZSB0byBMMVRGLgogCitP biBoYXJkd2FyZSBzdXBwb3J0aW5nIFNSQkRTX0NUUkwsIHRoZSBgc3JiLWxv Y2s9YCBvcHRpb24gY2FuIGJlIHVzZWQgdG8gZm9yY2UKK29yIHByZXZlbnQg WGVuIGZyb20gcHJvdGVjdCB0aGUgU3BlY2lhbCBSZWdpc3RlciBCdWZmZXIg ZnJvbSBsZWFraW5nIHN0YWxlCitkYXRhLiBCeSBkZWZhdWx0LCBYZW4gd2ls bCBlbmFibGUgdGhpcyBtaXRpZ2F0aW9uLCBleGNlcHQgb24gcGFydHMgd2hl cmUgTURTCitpcyBmaXhlZCBhbmQgVEFBIGlzIGZpeGVkL21pdGlnYXRlZCAo aW4gd2hpY2ggY2FzZSwgdGhlcmUgaXMgYmVsaWV2ZWQgdG8gYmUgbm8KK3dh eSBmb3IgYW4gYXR0YWNrZXIgdG8gb2J0YWluIHRoZSBzdGFsZSBkYXRhKS4K KwogIyMjIHN5bmNfY29uc29sZQogPiBgPSA8Ym9vbGVhbj5gCiAKZGlmZiAt LWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94 ODYvYWNwaS9wb3dlci5jCmluZGV4IGMxZDc3MmY2M2YuLmEwN2FhM2I5ZWQg MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMKKysrIGIv eGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMjY2LDYgKzI2Niw5IEBA IHN0YXRpYyBpbnQgZW50ZXJfc3RhdGUodTMyIHN0YXRlKQogICAgIGNpLT5z cGVjX2N0cmxfZmxhZ3MgfD0gKGRlZmF1bHRfc3BlY19jdHJsX2ZsYWdzICYg U0NGX2lzdF93cm1zcik7CiAgICAgc3BlY19jdHJsX2V4aXRfaWRsZShjaSk7 CiAKKyAgICBpZiAoIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJEU19D VFJMKSApCisgICAgICAgIHdybXNybChNU1JfTUNVX09QVF9DVFJMLCBkZWZh dWx0X3hlbl9tY3Vfb3B0X2N0cmwpOworCiAgZG9uZToKICAgICBzcGluX2Rl YnVnX2VuYWJsZSgpOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsK ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9zbXBib290LmMgYi94ZW4vYXJj aC94ODYvc21wYm9vdC5jCmluZGV4IDY5OWUyMWJmYjcuLmI3NDFkMTM1NGEg MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zbXBib290LmMKKysrIGIveGVu L2FyY2gveDg2L3NtcGJvb3QuYwpAQCAtMzY5LDEyICszNjksMTQgQEAgdm9p ZCBzdGFydF9zZWNvbmRhcnkodm9pZCAqdW51c2VkKQogICAgICAgICBtaWNy b2NvZGVfcmVzdW1lX2NwdShjcHUpOwogCiAgICAgLyoKLSAgICAgKiBJZiBN U1JfU1BFQ19DVFJMIGlzIGF2YWlsYWJsZSwgYXBwbHkgWGVuJ3MgZGVmYXVs dCBzZXR0aW5nIGFuZCBkaXNjYXJkCi0gICAgICogYW55IGZpcm13YXJlIHNl dHRpbmdzLiAgTm90ZTogTVNSX1NQRUNfQ1RSTCBtYXkgb25seSBiZWNvbWUg YXZhaWxhYmxlCi0gICAgICogYWZ0ZXIgbG9hZGluZyBtaWNyb2NvZGUuCisg ICAgICogSWYgYW55IHNwZWN1bGF0aXZlIGNvbnRyb2wgTVNScyBhcmUgYXZh aWxhYmxlLCBhcHBseSBYZW4ncyBkZWZhdWx0CisgICAgICogc2V0dGluZ3Mu ICBOb3RlOiBUaGVzZSBNU1JzIG1heSBvbmx5IGJlY29tZSBhdmFpbGFibGUg YWZ0ZXIgbG9hZGluZworICAgICAqIG1pY3JvY29kZS4KICAgICAgKi8KICAg ICBpZiAoIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9JQlJTQikgKQogICAg ICAgICB3cm1zcmwoTVNSX1NQRUNfQ1RSTCwgZGVmYXVsdF94ZW5fc3BlY19j dHJsKTsKKyAgICBpZiAoIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJE U19DVFJMKSApCisgICAgICAgIHdybXNybChNU1JfTUNVX09QVF9DVFJMLCBk ZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmwpOwogCiAgICAgdHN4X2luaXQoKTsg LyogTmVlZHMgbWljcm9jb2RlLiAgTWF5IGNoYW5nZSBITEUvUlRNIGZlYXR1 cmUgYml0cy4gKi8KIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNf Y3RybC5jIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDUxNThl MDEyY2EuLmUyZmNlZmM4NmEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9z cGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAg LTY0LDYgKzY0LDkgQEAgc3RhdGljIHVuc2lnbmVkIGludCBfX2luaXRkYXRh IGwxZF9tYXhwaHlzYWRkcjsKIHN0YXRpYyBib29sIF9faW5pdGRhdGEgY3B1 X2hhc19idWdfbXNiZHNfb25seTsgLyogPT4gbWluaW1hbCBIVCBpbXBhY3Qu ICovCiBzdGF0aWMgYm9vbCBfX2luaXRkYXRhIGNwdV9oYXNfYnVnX21kczsg LyogQW55IG90aGVyIE17TFAsU0IsRkJ9RFMgY29tYmluYXRpb24uICovCiAK K3N0YXRpYyBpbnQ4X3QgX19pbml0ZGF0YSBvcHRfc3JiX2xvY2sgPSAtMTsK K3VpbnQ2NF90IF9fcmVhZF9tb3N0bHkgZGVmYXVsdF94ZW5fbWN1X29wdF9j dHJsOworCiBzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9zcGVjX2N0cmwoY29u c3QgY2hhciAqcykKIHsKICAgICBjb25zdCBjaGFyICpzczsKQEAgLTExMCw2 ICsxMTMsNyBAQCBzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9zcGVjX2N0cmwo Y29uc3QgY2hhciAqcykKICAgICAgICAgICAgIG9wdF9pYnBiID0gZmFsc2U7 CiAgICAgICAgICAgICBvcHRfc3NiZCA9IGZhbHNlOwogICAgICAgICAgICAg b3B0X2wxZF9mbHVzaCA9IDA7CisgICAgICAgICAgICBvcHRfc3JiX2xvY2sg PSAwOwogICAgICAgICB9CiAgICAgICAgIGVsc2UgaWYgKCB2YWwgPiAwICkK ICAgICAgICAgICAgIHJjID0gLUVJTlZBTDsKQEAgLTE3NSw2ICsxNzksOCBA QCBzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9zcGVjX2N0cmwoY29uc3QgY2hh ciAqcykKICAgICAgICAgICAgIG9wdF9lYWdlcl9mcHUgPSB2YWw7CiAgICAg ICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigibDFkLWZsdXNo Iiwgcywgc3MpKSA+PSAwICkKICAgICAgICAgICAgIG9wdF9sMWRfZmx1c2gg PSB2YWw7CisgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVh bigic3JiLWxvY2siLCBzLCBzcykpID49IDAgKQorICAgICAgICAgICAgb3B0 X3NyYl9sb2NrID0gdmFsOwogICAgICAgICBlbHNlCiAgICAgICAgICAgICBy YyA9IC1FSU5WQUw7CiAKQEAgLTMzOCw3ICszNDQsNyBAQCBzdGF0aWMgdm9p ZCBfX2luaXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywg dWludDY0X3QgY2FwcykKICAgICAgICAgICAgICAgICJcbiIpOwogCiAgICAg LyogU2V0dGluZ3MgZm9yIFhlbidzIHByb3RlY3Rpb24sIGlycmVzcGVjdGl2 ZSBvZiBndWVzdHMuICovCi0gICAgcHJpbnRrKCIgIFhlbiBzZXR0aW5nczog QlRJLVRodW5rICVzLCBTUEVDX0NUUkw6ICVzJXMlcywgT3RoZXI6JXMlcyVz XG4iLAorICAgIHByaW50aygiICBYZW4gc2V0dGluZ3M6IEJUSS1UaHVuayAl cywgU1BFQ19DVFJMOiAlcyVzJXMsIE90aGVyOiVzJXMlcyVzXG4iLAogICAg ICAgICAgICB0aHVuayA9PSBUSFVOS19OT05FICAgICAgPyAiTi9BIiA6CiAg ICAgICAgICAgIHRodW5rID09IFRIVU5LX1JFVFBPTElORSA/ICJSRVRQT0xJ TkUiIDoKICAgICAgICAgICAgdGh1bmsgPT0gVEhVTktfTEZFTkNFICAgID8g IkxGRU5DRSIgOgpAQCAtMzQ5LDYgKzM1NSw4IEBAIHN0YXRpYyB2b2lkIF9f aW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rLCB1aW50 NjRfdCBjYXBzKQogICAgICAgICAgICAoZGVmYXVsdF94ZW5fc3BlY19jdHJs ICYgU1BFQ19DVFJMX1NTQkQpICA/ICIgU1NCRCsiIDogIiBTU0JELSIsCiAg ICAgICAgICAgICEoY2FwcyAmIEFSQ0hfQ0FQU19UU1hfQ1RSTCkgICAgICAg ICAgICAgID8gIiIgOgogICAgICAgICAgICAob3B0X3RzeCAmIDEpICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA/ICIgVFNYKyIgOiAiIFRTWC0iLAor ICAgICAgICAgICAhYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NU UkwpICAgICA/ICIiIDoKKyAgICAgICAgICAgb3B0X3NyYl9sb2NrICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPyAiIFNSQl9MT0NLKyIgOiAiIFNS Ql9MT0NLLSIsCiAgICAgICAgICAgIG9wdF9pYnBiICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgID8gIiBJQlBCIiAgOiAiIiwKICAgICAgICAg ICAgb3B0X2wxZF9mbHVzaCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PyAiIEwxRF9GTFVTSCIgOiAiIiwKICAgICAgICAgICAgb3B0X21kX2NsZWFy X3B2IHx8IG9wdF9tZF9jbGVhcl9odm0gICAgICAgPyAiIFZFUlciICA6ICIi KTsKQEAgLTExNDIsNiArMTE1MCwzNCBAQCB2b2lkIF9faW5pdCBpbml0X3Nw ZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAgICAgICAgIHRzeF9pbml0 KCk7CiAgICAgfQogCisgICAgLyogQ2FsY3VsYXRlIHN1aXRhYmxlIGRlZmF1 bHRzIGZvciBNU1JfTUNVX09QVF9DVFJMICovCisgICAgaWYgKCBib290X2Nw dV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgIHsKKyAgICAg ICAgdWludDY0X3QgdmFsOworCisgICAgICAgIHJkbXNybChNU1JfTUNVX09Q VF9DVFJMLCB2YWwpOworCisgICAgICAgIC8qCisgICAgICAgICAqIE9uIHNv bWUgU1JCRFMtYWZmZWN0ZWQgaGFyZHdhcmUsIGl0IG1heSBiZSBzYWZlIHRv IHJlbGF4IHNyYi1sb2NrCisgICAgICAgICAqIGJ5IGRlZmF1bHQuCisgICAg ICAgICAqCisgICAgICAgICAqIE9uIHBhcnRzIHdoaWNoIGVudW1lcmF0ZSBN RFNfTk8gYW5kIG5vdCBUQUFfTk8sIFRTWCBpcyB0aGUgb25seSB3YXkKKyAg ICAgICAgICogdG8gYWNjZXNzIHRoZSBGaWxsIEJ1ZmZlci4gIElmIFRTWCBp c24ndCBhdmFpbGFibGUgKGluYy4gU0tVCisgICAgICAgICAqIHJlYXNvbnMg b24gc29tZSBtb2RlbHMpLCBvciBUU1ggaXMgZXhwbGljaXRseSBkaXNhYmxl ZCwgdGhlbiB0aGVyZQorICAgICAgICAgKiBpcyBubyBuZWVkIGZvciB0aGUg ZXh0cmEgb3ZlcmhlYWQgdG8gcHJvdGVjdCBSRFJBTkQvUkRTRUVELgorICAg ICAgICAgKi8KKyAgICAgICAgaWYgKCBvcHRfc3JiX2xvY2sgPT0gLTEgJiYK KyAgICAgICAgICAgICAoY2FwcyAmIChBUkNIX0NBUFNfTURTX05PfEFSQ0hf Q0FQU19UQUFfTk8pKSA9PSBBUkNIX0NBUFNfTURTX05PICYmCisgICAgICAg ICAgICAgKCFjcHVfaGFzX2hsZSB8fCAoKGNhcHMgJiBBUkNIX0NBUFNfVFNY X0NUUkwpICYmIG9wdF90c3ggPT0gMCkpICkKKyAgICAgICAgICAgIG9wdF9z cmJfbG9jayA9IDA7CisKKyAgICAgICAgdmFsICY9IH5NQ1VfT1BUX0NUUkxf Uk5HRFNfTUlUR19ESVM7CisgICAgICAgIGlmICggIW9wdF9zcmJfbG9jayAp CisgICAgICAgICAgICB2YWwgfD0gTUNVX09QVF9DVFJMX1JOR0RTX01JVEdf RElTOworCisgICAgICAgIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCA9IHZh bDsKKyAgICB9CisKICAgICBwcmludF9kZXRhaWxzKHRodW5rLCBjYXBzKTsK IAogICAgIC8qCkBAIC0xMTczLDYgKzEyMDksOSBAQCB2b2lkIF9faW5pdCBp bml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAKICAgICAgICAg d3Jtc3JsKE1TUl9TUEVDX0NUUkwsIGJzcF9kZWxheV9zcGVjX2N0cmwgPyAw IDogZGVmYXVsdF94ZW5fc3BlY19jdHJsKTsKICAgICB9CisKKyAgICBpZiAo IGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSApCisgICAg ICAgIHdybXNybChNU1JfTUNVX09QVF9DVFJMLCBkZWZhdWx0X3hlbl9tY3Vf b3B0X2N0cmwpOwogfQogCiBzdGF0aWMgdm9pZCBfX2luaXQgX19tYXliZV91 bnVzZWQgYnVpbGRfYXNzZXJ0aW9ucyh2b2lkKQpkaWZmIC0tZ2l0IGEveGVu L2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmwuaCBiL3hlbi9pbmNsdWRlL2Fz bS14ODYvc3BlY19jdHJsLmgKaW5kZXggYmEwM2JiNDJlNS4uNTliYWIxYTQx YiAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmwu aAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oCkBAIC01 Myw2ICs1Myw4IEBAIGV4dGVybiBpbnQ4X3Qgb3B0X3B2X2wxdGZfaHdkb20s IG9wdF9wdl9sMXRmX2RvbXU7CiAgKi8KIGV4dGVybiBwYWRkcl90IGwxdGZf YWRkcl9tYXNrLCBsMXRmX3NhZmVfbWFkZHI7CiAKK2V4dGVybiB1aW50NjRf dCBkZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmw7CisKIHN0YXRpYyBpbmxpbmUg dm9pZCBpbml0X3NoYWRvd19zcGVjX2N0cmxfc3RhdGUodm9pZCkKIHsKICAg ICBzdHJ1Y3QgY3B1X2luZm8gKmluZm8gPSBnZXRfY3B1X2luZm8oKTsK --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.13-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.13-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyBi L2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYwppbmRleCAxZDlk ODE2NjIyLi45MjY4NDU0Mjk3IDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVu LWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21t YW5kLWxpbmUucGFuZG9jCkBAIC00ODMsMTAgKzQ4MywxMCBAQCBhY2NvdW50 aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXMgZW51bWVyYXRlZCB2 aWEgQ1BVSUQuCiAKIEN1cnJlbnRseSBhY2NlcHRlZDoKIAotVGhlIFNwZWN1 bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVhdHVyZXMgYG1kLWNsZWFyYCwg YGlicnNiYCwgYHN0aWJwYCwgYGlicGJgLAotYGwxZC1mbHVzaGAgYW5kIGBz c2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0IGlmIGF2YWlsYWJsZSBhbmQgYXBw bGljYWJsZS4gIFRoZXkgY2FuCi1iZSBpZ25vcmVkLCBlLmcuIGBuby1pYnJz YmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3b24ndCB1c2UgdGhlbSBpdHNlbGYs IGFuZAotd29uJ3Qgb2ZmZXIgdGhlbSB0byBndWVzdHMuCitUaGUgU3BlY3Vs YXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgc3JiZHMtY3RybGAs IGBtZC1jbGVhcmAsIGBpYnJzYmAsCitgc3RpYnBgLCBgaWJwYmAsIGBsMWQt Zmx1c2hgIGFuZCBgc3NiZGAgYXJlIHVzZWQgYnkgZGVmYXVsdCBpZiBhdmFp bGFibGUgYW5kCithcHBsaWNhYmxlLiAgVGhleSBjYW4gYmUgaWdub3JlZCwg ZS5nLiBgbm8taWJyc2JgLCBhdCB3aGljaCBwb2ludCBYZW4gd29uJ3QKK3Vz ZSB0aGVtIGl0c2VsZiwgYW5kIHdvbid0IG9mZmVyIHRoZW0gdG8gZ3Vlc3Rz LgogCiAjIyMgY3B1aWRfbWFza19jcHUKID4gYD0gZmFtXzBmX3Jldl9bY2Rl ZmddIHwgZmFtXzEwX3Jldl9bYmNdIHwgZmFtXzExX3Jldl9iYApkaWZmIC0t Z2l0IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhs L2xpYnhsX2NwdWlkLmMKaW5kZXggNmNlYTQyMjdiYS4uYTc4ZjA4YjkyNyAx MDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90 b29scy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0yMTMsNiArMjEzLDcgQEAg aW50IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xp Y3lfbGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKIAogICAgICAgICB7 ImF2eDUxMi00dm5uaXciLDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURY LCAgMiwgIDF9LAogICAgICAgICB7ImF2eDUxMi00Zm1hcHMiLDB4MDAwMDAw MDcsICAwLCBDUFVJRF9SRUdfRURYLCAgMywgIDF9LAorICAgICAgICB7InNy YmRzLWN0cmwiLCAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAg OSwgIDF9LAogICAgICAgICB7Im1kLWNsZWFyIiwgICAgIDB4MDAwMDAwMDcs ICAwLCBDUFVJRF9SRUdfRURYLCAxMCwgIDF9LAogICAgICAgICB7ImNldC1p YnQiLCAgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyMCwg IDF9LAogICAgICAgICB7ImlicnNiIiwgICAgICAgIDB4MDAwMDAwMDcsICAw LCBDUFVJRF9SRUdfRURYLCAyNiwgIDF9LApkaWZmIC0tZ2l0IGEvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKaW5k ZXggNjAzZTFkNjVmZC4uYTA5NDQwODEzYiAxMDA2NDQKLS0tIGEvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNjL3hlbi1jcHVpZC5j CkBAIC0xNTcsNiArMTU3LDcgQEAgc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0 IHN0cl83ZDBbMzJdID0KICAgICBbIDJdID0gImF2eDUxMl80dm5uaXciLCBb IDNdID0gImF2eDUxMl80Zm1hcHMiLAogICAgIFsgNF0gPSAiZnNybSIsCiAK KyAgICAvKiAgOCAqLyAgICAgICAgICAgICAgICBbIDldID0gInNyYmRzLWN0 cmwiLAogICAgIFsxMF0gPSAibWQtY2xlYXIiLAogICAgIC8qIDEyICovICAg ICAgICAgICAgICAgIFsxM10gPSAidHN4LWZvcmNlLWFib3J0IiwKIApkaWZm IC0tZ2l0IGEveGVuL2FyY2gveDg2L21zci5jIGIveGVuL2FyY2gveDg2L21z ci5jCmluZGV4IDRiMTIxMDM0ODIuLjBjZGVkM2MwYWQgMTAwNjQ0Ci0tLSBh L3hlbi9hcmNoL3g4Ni9tc3IuYworKysgYi94ZW4vYXJjaC94ODYvbXNyLmMK QEAgLTEzNCw2ICsxMzQsNyBAQCBpbnQgZ3Vlc3RfcmRtc3Ioc3RydWN0IHZj cHUgKnYsIHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKICAgICAgICAg LyogV3JpdGUtb25seSAqLwogICAgIGNhc2UgTVNSX1RTWF9GT1JDRV9BQk9S VDoKICAgICBjYXNlIE1TUl9UU1hfQ1RSTDoKKyAgICBjYXNlIE1TUl9NQ1Vf T1BUX0NUUkw6CiAgICAgY2FzZSBNU1JfVV9DRVQ6CiAgICAgY2FzZSBNU1Jf U19DRVQ6CiAgICAgY2FzZSBNU1JfUEwwX1NTUCAuLi4gTVNSX0lOVEVSUlVQ VF9TU1BfVEFCTEU6CkBAIC0yODgsNiArMjg5LDcgQEAgaW50IGd1ZXN0X3dy bXNyKHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90IHZh bCkKICAgICAgICAgLyogUmVhZC1vbmx5ICovCiAgICAgY2FzZSBNU1JfVFNY X0ZPUkNFX0FCT1JUOgogICAgIGNhc2UgTVNSX1RTWF9DVFJMOgorICAgIGNh c2UgTVNSX01DVV9PUFRfQ1RSTDoKICAgICBjYXNlIE1TUl9VX0NFVDoKICAg ICBjYXNlIE1TUl9TX0NFVDoKICAgICBjYXNlIE1TUl9QTDBfU1NQIC4uLiBN U1JfSU5URVJSVVBUX1NTUF9UQUJMRToKZGlmZiAtLWdpdCBhL3hlbi9hcmNo L3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpp bmRleCA2NjU2YzQ0YWVjLi41ZmMxYzY4MjdlIDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNf Y3RybC5jCkBAIC0zMTIsMTIgKzMxMiwxMyBAQCBzdGF0aWMgdm9pZCBfX2lu aXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0 X3QgY2FwcykKICAgICBwcmludGsoIlNwZWN1bGF0aXZlIG1pdGlnYXRpb24g ZmFjaWxpdGllczpcbiIpOwogCiAgICAgLyogSGFyZHdhcmUgZmVhdHVyZXMg d2hpY2ggcGVydGFpbiB0byBzcGVjdWxhdGl2ZSBtaXRpZ2F0aW9ucy4gKi8K LSAgICBwcmludGsoIiAgSGFyZHdhcmUgZmVhdHVyZXM6JXMlcyVzJXMlcyVz JXMlcyVzJXMlcyVzJXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUg ZmVhdHVyZXM6JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAog ICAgICAgICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9J QlJTQikpID8gIiBJQlJTL0lCUEIiIDogIiIsCiAgICAgICAgICAgIChfN2Qw ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX1NUSUJQKSkgPyAiIFNUSUJQ IiAgICAgOiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2so WDg2X0ZFQVRVUkVfTDFEX0ZMVVNIKSkgPyAiIEwxRF9GTFVTSCIgOiAiIiwK ICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVf U1NCRCkpICA/ICIgU1NCRCIgICAgICA6ICIiLAogICAgICAgICAgICAoXzdk MCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9NRF9DTEVBUikpID8gIiBN RF9DTEVBUiIgOiAiIiwKKyAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21h c2soWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkpID8gIiBTUkJEU19DVFJMIiA6 ICIiLAogICAgICAgICAgICAoZThiICAmIGNwdWZlYXRfbWFzayhYODZfRkVB VFVSRV9JQlBCKSkgID8gIiBJQlBCIiAgICAgIDogIiIsCiAgICAgICAgICAg IChjYXBzICYgQVJDSF9DQVBTX0lCUlNfQUxMKSAgICAgICAgICAgICAgPyAi IElCUlNfQUxMIiAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NB UFNfUkRDTF9OTykgICAgICAgICAgICAgICA/ICIgUkRDTF9OTyIgICA6ICIi LApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3ItaW5kZXgu aCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4LmgKaW5kZXggNzY5 M2M0YTcxYS4uOTE5OTQ2NjllMSAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUv YXNtLXg4Ni9tc3ItaW5kZXguaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2 L21zci1pbmRleC5oCkBAIC0xNzksNiArMTc5LDkgQEAKICNkZWZpbmUgTVNS X0lBMzJfVk1YX1RSVUVfRU5UUllfQ1RMUyAgICAgICAgICAgIDB4NDkwCiAj ZGVmaW5lIE1TUl9JQTMyX1ZNWF9WTUZVTkMgICAgICAgICAgICAgICAgICAg ICAweDQ5MQogCisjZGVmaW5lIE1TUl9NQ1VfT1BUX0NUUkwgICAgICAgICAg ICAgICAgICAgIDB4MDAwMDAxMjMKKyNkZWZpbmUgIE1DVV9PUFRfQ1RSTF9S TkdEU19NSVRHX0RJUyAgICAgICAgKF9BQygxLCBVTEwpIDw8ICAwKQorCiAj ZGVmaW5lIE1TUl9VX0NFVCAgICAgICAgICAgICAgICAgICAgICAgICAgIDB4 MDAwMDA2YTAKICNkZWZpbmUgTVNSX1NfQ0VUICAgICAgICAgICAgICAgICAg ICAgICAgICAgMHgwMDAwMDZhMgogI2RlZmluZSBNU1JfUEwwX1NTUCAgICAg ICAgICAgICAgICAgICAgICAgICAweDAwMDAwNmE0CmRpZmYgLS1naXQgYS94 ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oIGIv eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaApp bmRleCAyODM1Njg4ZjFjLi5hMjQ4MmMzNjI3IDEwMDY0NAotLS0gYS94ZW4v aW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBi L3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgK QEAgLTI1Miw2ICsyNTIsNyBAQCBYRU5fQ1BVRkVBVFVSRShJQlBCLCAgICAg ICAgICA4KjMyKzEyKSAvKkEgIElCUEIgc3VwcG9ydCBvbmx5IChubyBJQlJT LCB1c2VkIGJ5CiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJlcywgQ1BV SUQgbGV2ZWwgMHgwMDAwMDAwNzowLmVkeCwgd29yZCA5ICovCiBYRU5fQ1BV RkVBVFVSRShBVlg1MTJfNFZOTklXLCA5KjMyKyAyKSAvKkEgIEFWWDUxMiBO ZXVyYWwgTmV0d29yayBJbnN0cnVjdGlvbnMgKi8KIFhFTl9DUFVGRUFUVVJF KEFWWDUxMl80Rk1BUFMsIDkqMzIrIDMpIC8qQSAgQVZYNTEyIE11bHRpcGx5 IEFjY3VtdWxhdGlvbiBTaW5nbGUgUHJlY2lzaW9uICovCitYRU5fQ1BVRkVB VFVSRShTUkJEU19DVFJMLCAgICA5KjMyKyA5KSAvKiAgIE1TUl9NQ1VfT1BU X0NUUkwgYW5kIFJOR0RTX01JVEdfRElTLiAqLwogWEVOX0NQVUZFQVRVUkUo TURfQ0xFQVIsICAgICAgOSozMisxMCkgLypBICBWRVJXIGNsZWFycyBtaWNy b2FyY2hpdGVjdHVyYWwgYnVmZmVycyAqLwogWEVOX0NQVUZFQVRVUkUoVFNY X0ZPUkNFX0FCT1JULCA5KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNFX0FCT1JU LlJUTV9BQk9SVCAqLwogWEVOX0NQVUZFQVRVUkUoQ0VUX0lCVCwgICAgICAg OSozMisyMCkgLyogICBDRVQgLSBJbmRpcmVjdCBCcmFuY2ggVHJhY2tpbmcg Ki8K --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.13-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.13-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5w YW5kb2MgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKaW5k ZXggOTI2ODQ1NDI5Ny4uYzc4MDMxMjUzMSAxMDA2NDQKLS0tIGEvZG9jcy9t aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCisrKyBiL2RvY3MvbWlzYy94 ZW4tY29tbWFuZC1saW5lLnBhbmRvYwpAQCAtMTk5MSw3ICsxOTkxLDcgQEAg QnkgZGVmYXVsdCBTU0JEIHdpbGwgYmUgbWl0aWdhdGVkIGF0IHJ1bnRpbWUg KGkuZSBgc3NiZD1ydW50aW1lYCkuCiAjIyMgc3BlYy1jdHJsICh4ODYpCiA+ IGA9IExpc3Qgb2YgWyA8Ym9vbD4sIHhlbj08Ym9vbD4sIHtwdixodm0sbXNy LXNjLHJzYixtZC1jbGVhcn09PGJvb2w+LAogPiAgICAgICAgICAgICAgYnRp LXRodW5rPXJldHBvbGluZXxsZmVuY2V8am1wLCB7aWJycyxpYnBiLHNzYmQs ZWFnZXItZnB1LAotPiAgICAgICAgICAgICAgbDFkLWZsdXNoLGJyYW5jaC1o YXJkZW59PTxib29sPiBdYAorPiAgICAgICAgICAgICAgbDFkLWZsdXNoLGJy YW5jaC1oYXJkZW4sc3JiLWxvY2t9PTxib29sPiBdYAogCiBDb250cm9scyBm b3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9uIHNpZGVjaGFubmVsIG1pdGlnYXRp b25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3aWxsIHBpY2sgdGhlIG1vc3QgYXBw cm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFzZWQgb24gY29tcGlsZWQgaW4gc3Vw cG9ydCwKQEAgLTIwNjgsNiArMjA2OCwxMiBAQCBJZiBYZW4gaXMgY29tcGls ZWQgd2l0aCBgQ09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9CUkFOQ0hgLCB0 aGUKIHNwZWN1bGF0aW9uIGJhcnJpZXJzIHRvIHByb3RlY3Qgc2VsZWN0ZWQg Y29uZGl0aW9uYWwgYnJhbmNoZXMuICBCeSBkZWZhdWx0LAogWGVuIHdpbGwg ZW5hYmxlIHRoaXMgbWl0aWdhdGlvbi4KIAorT24gaGFyZHdhcmUgc3VwcG9y dGluZyBTUkJEU19DVFJMLCB0aGUgYHNyYi1sb2NrPWAgb3B0aW9uIGNhbiBi ZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2ZW50IFhlbiBmcm9tIHByb3RlY3Qg dGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVmZmVyIGZyb20gbGVha2luZyBzdGFs ZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVuIHdpbGwgZW5hYmxlIHRoaXMgbWl0 aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRzIHdoZXJlIE1EUworaXMgZml4ZWQg YW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0ZWQgKGluIHdoaWNoIGNhc2UsIHRo ZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5vCit3YXkgZm9yIGFuIGF0dGFja2Vy IHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0YSkuCisKICMjIyBzeW5jX2NvbnNv bGUKID4gYD0gPGJvb2xlYW4+YAogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94 ODYvYWNwaS9wb3dlci5jIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpp bmRleCBmZWIwZjZjZTIwLi43NWM2ZTM0MTY0IDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvYWNwaS9wb3dlci5jCisrKyBiL3hlbi9hcmNoL3g4Ni9hY3Bp L3Bvd2VyLmMKQEAgLTI5NSw2ICsyOTUsOSBAQCBzdGF0aWMgaW50IGVudGVy X3N0YXRlKHUzMiBzdGF0ZSkKICAgICBjaS0+c3BlY19jdHJsX2ZsYWdzIHw9 IChkZWZhdWx0X3NwZWNfY3RybF9mbGFncyAmIFNDRl9pc3Rfd3Jtc3IpOwog ICAgIHNwZWNfY3RybF9leGl0X2lkbGUoY2kpOwogCisgICAgaWYgKCBib290 X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgICAgICB3 cm1zcmwoTVNSX01DVV9PUFRfQ1RSTCwgZGVmYXVsdF94ZW5fbWN1X29wdF9j dHJsKTsKKwogIGRvbmU6CiAgICAgc3Bpbl9kZWJ1Z19lbmFibGUoKTsKICAg ICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7CmRpZmYgLS1naXQgYS94ZW4v YXJjaC94ODYvc21wYm9vdC5jIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwpp bmRleCBkYzhmZGFjMWExLi5iMWU1MWIzYWZmIDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvc21wYm9vdC5jCisrKyBiL3hlbi9hcmNoL3g4Ni9zbXBib290 LmMKQEAgLTM2MSwxMiArMzYxLDE0IEBAIHZvaWQgc3RhcnRfc2Vjb25kYXJ5 KHZvaWQgKnVudXNlZCkKICAgICBtaWNyb2NvZGVfdXBkYXRlX29uZShmYWxz ZSk7CiAKICAgICAvKgotICAgICAqIElmIE1TUl9TUEVDX0NUUkwgaXMgYXZh aWxhYmxlLCBhcHBseSBYZW4ncyBkZWZhdWx0IHNldHRpbmcgYW5kIGRpc2Nh cmQKLSAgICAgKiBhbnkgZmlybXdhcmUgc2V0dGluZ3MuICBOb3RlOiBNU1Jf U1BFQ19DVFJMIG1heSBvbmx5IGJlY29tZSBhdmFpbGFibGUKLSAgICAgKiBh ZnRlciBsb2FkaW5nIG1pY3JvY29kZS4KKyAgICAgKiBJZiBhbnkgc3BlY3Vs YXRpdmUgY29udHJvbCBNU1JzIGFyZSBhdmFpbGFibGUsIGFwcGx5IFhlbidz IGRlZmF1bHQKKyAgICAgKiBzZXR0aW5ncy4gIE5vdGU6IFRoZXNlIE1TUnMg bWF5IG9ubHkgYmVjb21lIGF2YWlsYWJsZSBhZnRlciBsb2FkaW5nCisgICAg ICogbWljcm9jb2RlLgogICAgICAqLwogICAgIGlmICggYm9vdF9jcHVfaGFz KFg4Nl9GRUFUVVJFX0lCUlNCKSApCiAgICAgICAgIHdybXNybChNU1JfU1BF Q19DVFJMLCBkZWZhdWx0X3hlbl9zcGVjX2N0cmwpOworICAgIGlmICggYm9v dF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICAgICAg d3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkwsIGRlZmF1bHRfeGVuX21jdV9vcHRf Y3RybCk7CiAKICAgICB0c3hfaW5pdCgpOyAvKiBOZWVkcyBtaWNyb2NvZGUu ICBNYXkgY2hhbmdlIEhMRS9SVE0gZmVhdHVyZSBiaXRzLiAqLwogCmRpZmYg LS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMgYi94ZW4vYXJjaC94 ODYvc3BlY19jdHJsLmMKaW5kZXggNWZjMWM2ODI3ZS4uMzMzNDMwNjJhNyAx MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisrKyBiL3hl bi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpAQCAtNjUsNiArNjUsOSBAQCBzdGF0 aWMgdW5zaWduZWQgaW50IF9faW5pdGRhdGEgbDFkX21heHBoeXNhZGRyOwog c3RhdGljIGJvb2wgX19pbml0ZGF0YSBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5 OyAvKiA9PiBtaW5pbWFsIEhUIGltcGFjdC4gKi8KIHN0YXRpYyBib29sIF9f aW5pdGRhdGEgY3B1X2hhc19idWdfbWRzOyAvKiBBbnkgb3RoZXIgTXtMUCxT QixGQn1EUyBjb21iaW5hdGlvbi4gKi8KIAorc3RhdGljIGludDhfdCBfX2lu aXRkYXRhIG9wdF9zcmJfbG9jayA9IC0xOwordWludDY0X3QgX19yZWFkX21v c3RseSBkZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmw7CisKIHN0YXRpYyBpbnQg X19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogewogICAg IGNvbnN0IGNoYXIgKnNzOwpAQCAtMTEyLDYgKzExNSw3IEBAIHN0YXRpYyBp bnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogICAg ICAgICAgICAgb3B0X3NzYmQgPSBmYWxzZTsKICAgICAgICAgICAgIG9wdF9s MWRfZmx1c2ggPSAwOwogICAgICAgICAgICAgb3B0X2JyYW5jaF9oYXJkZW4g PSBmYWxzZTsKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9IDA7CiAgICAg ICAgIH0KICAgICAgICAgZWxzZSBpZiAoIHZhbCA+IDAgKQogICAgICAgICAg ICAgcmMgPSAtRUlOVkFMOwpAQCAtMTc4LDYgKzE4Miw4IEBAIHN0YXRpYyBp bnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogICAg ICAgICAgICAgb3B0X2wxZF9mbHVzaCA9IHZhbDsKICAgICAgICAgZWxzZSBp ZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJicmFuY2gtaGFyZGVuIiwgcywg c3MpKSA+PSAwICkKICAgICAgICAgICAgIG9wdF9icmFuY2hfaGFyZGVuID0g dmFsOworICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4o InNyYi1sb2NrIiwgcywgc3MpKSA+PSAwICkKKyAgICAgICAgICAgIG9wdF9z cmJfbG9jayA9IHZhbDsKICAgICAgICAgZWxzZQogICAgICAgICAgICAgcmMg PSAtRUlOVkFMOwogCkBAIC0zNDEsNyArMzQ3LDcgQEAgc3RhdGljIHZvaWQg X19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVp bnQ2NF90IGNhcHMpCiAgICAgICAgICAgICAgICAiXG4iKTsKIAogICAgIC8q IFNldHRpbmdzIGZvciBYZW4ncyBwcm90ZWN0aW9uLCBpcnJlc3BlY3RpdmUg b2YgZ3Vlc3RzLiAqLwotICAgIHByaW50aygiICBYZW4gc2V0dGluZ3M6IEJU SS1UaHVuayAlcywgU1BFQ19DVFJMOiAlcyVzJXMsIE90aGVyOiVzJXMlcyVz XG4iLAorICAgIHByaW50aygiICBYZW4gc2V0dGluZ3M6IEJUSS1UaHVuayAl cywgU1BFQ19DVFJMOiAlcyVzJXMsIE90aGVyOiVzJXMlcyVzJXNcbiIsCiAg ICAgICAgICAgIHRodW5rID09IFRIVU5LX05PTkUgICAgICA/ICJOL0EiIDoK ICAgICAgICAgICAgdGh1bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBP TElORSIgOgogICAgICAgICAgICB0aHVuayA9PSBUSFVOS19MRkVOQ0UgICAg PyAiTEZFTkNFIiA6CkBAIC0zNTIsNiArMzU4LDggQEAgc3RhdGljIHZvaWQg X19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVp bnQ2NF90IGNhcHMpCiAgICAgICAgICAgIChkZWZhdWx0X3hlbl9zcGVjX2N0 cmwgJiBTUEVDX0NUUkxfU1NCRCkgID8gIiBTU0JEKyIgOiAiIFNTQkQtIiwK ICAgICAgICAgICAgIShjYXBzICYgQVJDSF9DQVBTX1RTWF9DVFJMKSAgICAg ICAgICAgICAgPyAiIiA6CiAgICAgICAgICAgIChvcHRfdHN4ICYgMSkgICAg ICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBUU1grIiA6ICIgVFNYLSIs CisgICAgICAgICAgICFib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNf Q1RSTCkgICAgID8gIiIgOgorICAgICAgICAgICBvcHRfc3JiX2xvY2sgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgU1JCX0xPQ0srIiA6ICIg U1JCX0xPQ0stIiwKICAgICAgICAgICAgb3B0X2licGIgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPyAiIElCUEIiICA6ICIiLAogICAgICAg ICAgICBvcHRfbDFkX2ZsdXNoICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA/ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICBvcHRfbWRfY2xl YXJfcHYgfHwgb3B0X21kX2NsZWFyX2h2bSAgICAgICA/ICIgVkVSVyIgIDog IiIsCkBAIC0xMTQ5LDYgKzExNTcsMzQgQEAgdm9pZCBfX2luaXQgaW5pdF9z cGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQogICAgICAgICB0c3hfaW5p dCgpOwogICAgIH0KIAorICAgIC8qIENhbGN1bGF0ZSBzdWl0YWJsZSBkZWZh dWx0cyBmb3IgTVNSX01DVV9PUFRfQ1RSTCAqLworICAgIGlmICggYm9vdF9j cHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICB7CisgICAg ICAgIHVpbnQ2NF90IHZhbDsKKworICAgICAgICByZG1zcmwoTVNSX01DVV9P UFRfQ1RSTCwgdmFsKTsKKworICAgICAgICAvKgorICAgICAgICAgKiBPbiBz b21lIFNSQkRTLWFmZmVjdGVkIGhhcmR3YXJlLCBpdCBtYXkgYmUgc2FmZSB0 byByZWxheCBzcmItbG9jaworICAgICAgICAgKiBieSBkZWZhdWx0LgorICAg ICAgICAgKgorICAgICAgICAgKiBPbiBwYXJ0cyB3aGljaCBlbnVtZXJhdGUg TURTX05PIGFuZCBub3QgVEFBX05PLCBUU1ggaXMgdGhlIG9ubHkgd2F5Cisg ICAgICAgICAqIHRvIGFjY2VzcyB0aGUgRmlsbCBCdWZmZXIuICBJZiBUU1gg aXNuJ3QgYXZhaWxhYmxlIChpbmMuIFNLVQorICAgICAgICAgKiByZWFzb25z IG9uIHNvbWUgbW9kZWxzKSwgb3IgVFNYIGlzIGV4cGxpY2l0bHkgZGlzYWJs ZWQsIHRoZW4gdGhlcmUKKyAgICAgICAgICogaXMgbm8gbmVlZCBmb3IgdGhl IGV4dHJhIG92ZXJoZWFkIHRvIHByb3RlY3QgUkRSQU5EL1JEU0VFRC4KKyAg ICAgICAgICovCisgICAgICAgIGlmICggb3B0X3NyYl9sb2NrID09IC0xICYm CisgICAgICAgICAgICAgKGNhcHMgJiAoQVJDSF9DQVBTX01EU19OT3xBUkNI X0NBUFNfVEFBX05PKSkgPT0gQVJDSF9DQVBTX01EU19OTyAmJgorICAgICAg ICAgICAgICghY3B1X2hhc19obGUgfHwgKChjYXBzICYgQVJDSF9DQVBTX1RT WF9DVFJMKSAmJiBvcHRfdHN4ID09IDApKSApCisgICAgICAgICAgICBvcHRf c3JiX2xvY2sgPSAwOworCisgICAgICAgIHZhbCAmPSB+TUNVX09QVF9DVFJM X1JOR0RTX01JVEdfRElTOworICAgICAgICBpZiAoICFvcHRfc3JiX2xvY2sg KQorICAgICAgICAgICAgdmFsIHw9IE1DVV9PUFRfQ1RSTF9STkdEU19NSVRH X0RJUzsKKworICAgICAgICBkZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmwgPSB2 YWw7CisgICAgfQorCiAgICAgcHJpbnRfZGV0YWlscyh0aHVuaywgY2Fwcyk7 CiAKICAgICAvKgpAQCAtMTE4MCw2ICsxMjE2LDkgQEAgdm9pZCBfX2luaXQg aW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQogCiAgICAgICAg IHdybXNybChNU1JfU1BFQ19DVFJMLCBic3BfZGVsYXlfc3BlY19jdHJsID8g MCA6IGRlZmF1bHRfeGVuX3NwZWNfY3RybCk7CiAgICAgfQorCisgICAgaWYg KCBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAg ICAgICB3cm1zcmwoTVNSX01DVV9PUFRfQ1RSTCwgZGVmYXVsdF94ZW5fbWN1 X29wdF9jdHJsKTsKIH0KIAogc3RhdGljIHZvaWQgX19pbml0IF9fbWF5YmVf dW51c2VkIGJ1aWxkX2Fzc2VydGlvbnModm9pZCkKZGlmZiAtLWdpdCBhL3hl bi9pbmNsdWRlL2FzbS14ODYvc3BlY19jdHJsLmggYi94ZW4vaW5jbHVkZS9h c20teDg2L3NwZWNfY3RybC5oCmluZGV4IDljYWVjZGRmZWMuLmIyNTJiYjg2 MzEgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvc3BlY19jdHJs LmgKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmwuaApAQCAt NTQsNiArNTQsOCBAQCBleHRlcm4gaW50OF90IG9wdF9wdl9sMXRmX2h3ZG9t LCBvcHRfcHZfbDF0Zl9kb211OwogICovCiBleHRlcm4gcGFkZHJfdCBsMXRm X2FkZHJfbWFzaywgbDF0Zl9zYWZlX21hZGRyOwogCitleHRlcm4gdWludDY0 X3QgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsOworCiBzdGF0aWMgaW5saW5l IHZvaWQgaW5pdF9zaGFkb3dfc3BlY19jdHJsX3N0YXRlKHZvaWQpCiB7CiAg ICAgc3RydWN0IGNwdV9pbmZvICppbmZvID0gZ2V0X2NwdV9pbmZvKCk7Cg== --=separator-- From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:04:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:04:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihfK-0005fL-TT; Tue, 09 Jun 2020 17:03:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihfK-0005fE-8O for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:03:58 +0000 X-Inumbo-ID: 348258dc-aa73-11ea-b343-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 348258dc-aa73-11ea-b343-12813bfff9fa; Tue, 09 Jun 2020 17:03:57 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 92YMmYdspaKsWWzegUN3uFD6ESQEIgFua+4qZ0ywgpc64TVLM0al/RlOZl3l2teMO31/lNXJk7 1vfNOu84G62JnaOpJxooihgzYRedx7++mtvtG0E29DvblK+esMHkk/VIUM8gx49pyaiDgfvsCf gYYJALZUIiBdXKBHY912AMtzhJz/kvkASlyC3ozN2LVERfjwYiBrYEq4YiBaPozMphty+4p1hX NTBVO5sJhR7prrkdWlKZJjYHtOw/srvh/s7j1aRPvFyP85ultgB9N721bCdCXD+23UBJ86yniP XxQ= X-SBRS: 2.7 X-MesageID: 19950564 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,492,1583211600"; d="scan'208";a="19950564" From: George Dunlap To: Paul Durrant Subject: Re: [TESTDAY] xl restore gives an error too soon after xl save Thread-Topic: [TESTDAY] xl restore gives an error too soon after xl save Thread-Index: AQHWPn1DuBRhzpMk9UKX8zBgGqSl9KjQXzkAgAACKIA= Date: Tue, 9 Jun 2020 17:03:49 +0000 Message-ID: <5B09A89E-1321-4DC0-8830-396F4239058B@citrix.com> References: <00d601d63e7e$df2eb570$9d8c2050$@xen.org> In-Reply-To: <00d601d63e7e$df2eb570$9d8c2050$@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , Xen-devel , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gSnVuIDksIDIwMjAsIGF0IDU6NTYgUE0sIFBhdWwgRHVycmFudCA8eGFkaW1nbmlr QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IEdlb3JnZSBEdW5sYXAgPEdlb3JnZS5EdW5sYXBAY2l0cml4LmNvbT4NCj4+IFNlbnQ6 IDA5IEp1bmUgMjAyMCAxNzo0NQ0KPj4gVG86IFhlbi1kZXZlbCA8eGVuLWRldmVsQGxpc3RzLnhl bnByb2plY3Qub3JnPg0KPj4gQ2M6IFBhdWwgRHVycmFudCA8cGF1bEB4ZW4ub3JnPjsgSWFuIEph Y2tzb24gPElhbi5KYWNrc29uQGNpdHJpeC5jb20+OyBXZWkgTGl1IDx3bEB4ZW4ub3JnPjsgQW50 aG9ueQ0KPj4gUGVyYXJkIDxhbnRob255LnBlcmFyZEBjaXRyaXguY29tPg0KPj4gU3ViamVjdDog W1RFU1REQVldIHhsIHJlc3RvcmUgZ2l2ZXMgYW4gZXJyb3IgdG9vIHNvb24gYWZ0ZXIgeGwgc2F2 ZQ0KPj4gDQo+PiBTb21ld2hhdCBzdXJwcmlzaW5nIHRoYXQgaWYgeW91IHNhdmUgd2l0aCAtRCwg eW91IGdldCBteXN0ZXJpb3VzIGVycm9yIG1lc3NhZ2VzIGZvciB0aGUgbmV4dCBzby1tYW55DQo+ PiBzZWNvbmRzOg0KPj4gDQo+PiByb290QGltbW9ydGFsOi9pbWFnZXMjIHhsIHNhdmUgLUQgYzYt MDEgL2ltYWdlcy90bXAvYzYtMDEuc2F2ZQ0KPj4gU2F2aW5nIHRvIC9pbWFnZXMvdG1wL2M2LTAx LnNhdmUgbmV3IHhsIGZvcm1hdCAoaW5mbyAweDMvMHgwLzk1MCkNCj4+IHhjOiBpbmZvOiBTYXZp bmcgZG9tYWluIDE5NTA1LCB0eXBlIHg4NiBQVg0KPj4geGM6IEZyYW1lczogNTI0Mjg4LzUyNDI4 OCAgMTAwJQ0KPj4geGM6IEVuZCBvZiBzdHJlYW06IDAvMCAgICAwJQ0KPj4gcm9vdEBpbW1vcnRh bDovaW1hZ2VzIyB4bCByZXN0b3JlIHRtcC9jNi0wMS5zYXZlDQo+PiBMb2FkaW5nIG5ldyBzYXZl IGZpbGUgdG1wL2M2LTAxLnNhdmUgKG5ldyB4bCBmbXQgaW5mbyAweDMvMHgwLzk1MCkNCj4+IFNh dmVmaWxlIGNvbnRhaW5zIHhsIGRvbWFpbiBjb25maWcgaW4gSlNPTiBmb3JtYXQNCj4+IFBhcnNp bmcgY29uZmlnIGZyb20gPHNhdmVkPg0KPj4gbGlieGw6IGVycm9yOiBsaWJ4bF9jcmVhdGUuYzo2 OTI6bGlieGxfX2RvbWFpbl9tYWtlOiBEb21haW4gMTk1MDU6ZG9tYWluIGlkIHJlY2VudGx5IHVz ZWQ6IE5vIHN1Y2gNCj4+IGZpbGUgb3IgZGlyZWN0b3J5DQo+PiBsaWJ4bDogZXJyb3I6IGxpYnhs X2NyZWF0ZS5jOjEyMzM6aW5pdGlhdGVfZG9tYWluX2NyZWF0ZTogRG9tYWluIDE5NTA1OmNhbm5v dCBtYWtlIGRvbWFpbjogLTMNCj4+IGxpYnhsOiBlcnJvcjogbGlieGxfZG9tYWluLmM6MTE4Mjps aWJ4bF9fZGVzdHJveV9kb21pZDogRG9tYWluIDE5NTA1Ok5vbi1leGlzdGFudCBkb21haW4NCj4+ IGxpYnhsOiBlcnJvcjogbGlieGxfZG9tYWluLmM6MTEzNjpkb21haW5fZGVzdHJveV9jYWxsYmFj azogRG9tYWluIDE5NTA1OlVuYWJsZSB0byBkZXN0cm95IGd1ZXN0DQo+PiBsaWJ4bDogZXJyb3I6 IGxpYnhsX2RvbWFpbi5jOjEwNjM6ZG9tYWluX2Rlc3Ryb3lfY2I6IERvbWFpbiAxOTUwNTpEZXN0 cnVjdGlvbiBvZiBkb21haW4gZmFpbGVkDQo+PiByb290QGltbW9ydGFsOi9pbWFnZXMjIHhsIHJl c3RvcmUgdG1wL2M2LTAxLnNhdmUNCj4+IExvYWRpbmcgbmV3IHNhdmUgZmlsZSB0bXAvYzYtMDEu c2F2ZSAobmV3IHhsIGZtdCBpbmZvIDB4My8weDAvOTUwKQ0KPj4gU2F2ZWZpbGUgY29udGFpbnMg eGwgZG9tYWluIGNvbmZpZyBpbiBKU09OIGZvcm1hdA0KPj4gUGFyc2luZyBjb25maWcgZnJvbSA8 c2F2ZWQ+DQo+PiBsaWJ4bDogZXJyb3I6IGxpYnhsX2NyZWF0ZS5jOjY5MjpsaWJ4bF9fZG9tYWlu X21ha2U6IERvbWFpbiAxOTUwNTpkb21haW4gaWQgcmVjZW50bHkgdXNlZDogTm8gc3VjaA0KPj4g ZmlsZSBvciBkaXJlY3RvcnkNCj4+IGxpYnhsOiBlcnJvcjogbGlieGxfY3JlYXRlLmM6MTIzMzpp bml0aWF0ZV9kb21haW5fY3JlYXRlOiBEb21haW4gMTk1MDU6Y2Fubm90IG1ha2UgZG9tYWluOiAt Mw0KPj4gbGlieGw6IGVycm9yOiBsaWJ4bF9kb21haW4uYzoxMTgyOmxpYnhsX19kZXN0cm95X2Rv bWlkOiBEb21haW4gMTk1MDU6Tm9uLWV4aXN0YW50IGRvbWFpbg0KPj4gbGlieGw6IGVycm9yOiBs aWJ4bF9kb21haW4uYzoxMTM2OmRvbWFpbl9kZXN0cm95X2NhbGxiYWNrOiBEb21haW4gMTk1MDU6 VW5hYmxlIHRvIGRlc3Ryb3kgZ3Vlc3QNCj4+IGxpYnhsOiBlcnJvcjogbGlieGxfZG9tYWluLmM6 MTA2Mzpkb21haW5fZGVzdHJveV9jYjogRG9tYWluIDE5NTA1OkRlc3RydWN0aW9uIG9mIGRvbWFp biBmYWlsZWQNCj4+IA0KPj4gW0EgZmV3IG1pbnV0ZXMgcGFzc10NCj4+IA0KPiANCj4gWWVzLCB0 aGlzIGlzIGJlY2F1c2UgaXQgaXMgbm90ICdzYWZlJyB0byByZS1jcmVhdGUgdGhlIGRvbWFpbiB3 aXRoIHRoZSBzYW1lIGRvbWlkIHVudGlsIGl0IGlzIGRlZW1lZCBub3QgJ3JlY2VudGx5IHVzZWQn LiBUaGlzDQo+IHNob3VsZCBpbmRlZWQgYmUgZG9jdW1lbnRlZC4NCg0K4oCmYW5kIHByb2JhYmx5 IGhhdmUgYSBtb3JlIGluZm9ybWF0aXZlIGVycm9yIG1lc3NhZ2UuIDotKQ0KDQpJIGNhbiBzZWUg d2h5IHlvdSB3b3VsZG7igJl0IHdhbnQgdG8gc3RhcnQgYSAqbmV3KiBkb21haW4gd2l0aCBhIHBy ZXZpb3VzIGRvbWFpbiwgYnV0IHN1cmVseSBpZiB5b3XigJlyZSByZXN0b3JpbmcgdGhlICpzYW1l KiBkb21haW4sIHRoYXQgY2hlY2sgc2hvdWxkIGJlIHNraXBwZWQ/DQoNCiAtR2Vvcmdl From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:04:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:04:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihfE-0005ep-Ko; Tue, 09 Jun 2020 17:03:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihfC-0005ed-UG for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:03:51 +0000 X-Inumbo-ID: 2fd32ea6-aa73-11ea-8496-bc764e2007e4 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe09::607]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2fd32ea6-aa73-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 17:03:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sXFHzux9Awfg8hGSv9+j78Q4hPhDdAfRz9cmsvB78sw=; b=W6pQfS26H2Xwn+kgb1+GFjHnzg6w4hx38U7pnBNxtx77DkR1X22i8VrmQzzTGygZZpHDA7A4XHpdFDbQwhMatzMU2JWG9pb3u5aF2Zbrn9Mj7TKipSeXOFDfrzgwXudrCxzHXJsgHuvCCqy6WAGevmDKDgXII+aDVcR9DXWY03g= Received: from DB6PR1001CA0003.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:4:b7::13) by DB6PR08MB2904.eurprd08.prod.outlook.com (2603:10a6:6:1e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Tue, 9 Jun 2020 17:03:47 +0000 Received: from DB5EUR03FT017.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:b7:cafe::72) by DB6PR1001CA0003.outlook.office365.com (2603:10a6:4:b7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Tue, 9 Jun 2020 17:03:47 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT017.mail.protection.outlook.com (10.152.20.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Tue, 9 Jun 2020 17:03:47 +0000 Received: ("Tessian outbound fb809da9b456:v59"); Tue, 09 Jun 2020 17:03:47 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 2486b1c76cfea7e3 X-CR-MTA-TID: 64aa7808 Received: from 9b1ca0b6f4d0.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A1A40352-AC7A-4E17-AAAA-721B081F421D.1; Tue, 09 Jun 2020 17:03:41 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9b1ca0b6f4d0.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 09 Jun 2020 17:03:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SF9yxkNVObhmCiwG+uWxL5q17TtT6n17GDZf1Vl36+fwygJvO3fay/q/fjV3jJRbM8YunvmD1TSvoxcs71O0VCUJjeOTIaDmehaLfF5aSK4flkbbAugOnk9OxNCEGvd+ZqpDJCi1NvZkWZsoTeY7UC4lY3CTPrMf4E/sUeAIse/GKREkTqAXDOFx6RB3W5cm6m9MYDgu8Dx9hMdAZAP8EuSueBYqmsfZ8KhcYsbOWJfIohUh3gsa39LppMvIRRhljEsYQHdCFMx4nnsSrKTHJyoYACX3IKUGz5f1GgRRHdNweu64haS3VrzVccmCPaFeweDa0MnnjFeMfjxiUMHqzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sXFHzux9Awfg8hGSv9+j78Q4hPhDdAfRz9cmsvB78sw=; b=LZsuWVQ03MRvqlr7zrdT71emkJJ7i0hDhC5SFXMOud4yp/xMtB9Dba3CHAI/iikNLpl9pm2wee0G+F7YIH2VLS9qxN7oksmRNPbGMhtA+NKfggxIX4N/UR1b4AUFHzzNr50i1i9gBCpc3HQn2pkvZrtZvO08b07pnG7ZjgKCtdcvSUMOXzFuqdXoEOteUoi5Psv/GFZVvqoHHP1kP5J2kinL+tS8wKPwHtGiP8a7j5nPv0GSKuk1kE25g6odXLeI58LZhBvLP13IO0Ak3DS+6JG/RQuW+zNQRcS8lx2KkiB1Ko/6D5XD/nAsGdCSRMPWpUf0p0991tV5NX0kKcOGuw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sXFHzux9Awfg8hGSv9+j78Q4hPhDdAfRz9cmsvB78sw=; b=W6pQfS26H2Xwn+kgb1+GFjHnzg6w4hx38U7pnBNxtx77DkR1X22i8VrmQzzTGygZZpHDA7A4XHpdFDbQwhMatzMU2JWG9pb3u5aF2Zbrn9Mj7TKipSeXOFDfrzgwXudrCxzHXJsgHuvCCqy6WAGevmDKDgXII+aDVcR9DXWY03g= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3594.eurprd08.prod.outlook.com (2603:10a6:10:4e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.23; Tue, 9 Jun 2020 17:03:40 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3066.023; Tue, 9 Jun 2020 17:03:39 +0000 From: Bertrand Marquis To: Julien Grall Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgIAAJpOAgABE7QCABAZcAIAAQRIAgAA9oACAAXYtAIAAD3sAgAAFaoCAABUzgA== Date: Tue, 9 Jun 2020 17:03:39 +0000 Message-ID: <03607739-A4FF-486A-899A-F5F36870225A@arm.com> References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 9da956f3-d651-4860-6b0e-08d80c971301 x-ms-traffictypediagnostic: DB7PR08MB3594:|DB6PR08MB2904: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 042957ACD7 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 4mS57uuErEPkt8CM13w99NPbHixJjbEdJgaEriAVO2Kr2cUBwrYw5HKPRkHCErpUm3gKzV2x6hUg8flesBrBfDV7KqKbqLNLWOLqK2asqUxB6ymxM9YaHdmFOWnTCBUlnBKtIQN/pXe7TDyDMKnPghs3GEYC3UyMLQA7qo7j3MQS/Jp/My6zP42vNW0O0TLpTt9Rahi6p8Zzf0RpJIHl9AxCp6BQPk4MVvkVX9hyDNY5XnJoj45SojUu8YitQaDykR4Y/T8/50oybJ7AAfamVYBfIU9a5ioOQwkESxhCIfgkI0BJ3BBFfgQs4/yPY58z+OS7as+U9sb/wUgzex7TVQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(136003)(366004)(39850400004)(316002)(91956017)(76116006)(66556008)(71200400001)(53546011)(66946007)(66476007)(5660300002)(54906003)(66446008)(6506007)(3480700007)(4326008)(83380400001)(33656002)(2616005)(186003)(26005)(64756008)(8936002)(2906002)(36756003)(8676002)(6512007)(7116003)(6916009)(478600001)(6486002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: p2PxH3B2U4M+cbusz+U/I3h/kohlY8RaHP6xKxKL5mgy/IjkH4RIzaE77cXytsRpalmx8Z3Apv+UfLEftipBF2qgzdoD4NJF4BQd9yCxNyo56qEQtGVytA//nr9yVyaUTfNmKLBZcL0PRnYVm6u5fjbZ9KNSPwnyC+ZtsDFy0EH67OLjQKGY96+X4sFtv74Zhi/sKkqjh8p9cfnW32v1K7JXELmI3NkvYHbAchh9VLplucGkbel0p3+Pbj18pIwjs3zY2S4beUYaY3E3cBxiQI0d294upPsYcJlx16fm0wAq8h+R81XR8REgrmCjIu1tTgdg4REp+acn1OAytWCPn7HnOE8A0VrT158INjrybVq7GZNEhklj58PN31bnV8YXWcu0o9vK0fYGhLUcBYFUmCA19aHSZNIxYwXAYA04nTgT3H4WXuc5eUgRVAAr16ReOEC4fgnTbPejCxhz7Wv1Pypx08+32G7OHJItfaDJC7w= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <6154957B7A54454FA686953AE76779FD@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3594 Original-Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT017.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39850400004)(376002)(346002)(46966005)(7116003)(8936002)(356005)(47076004)(8676002)(70206006)(33656002)(83380400001)(4326008)(6862004)(316002)(6512007)(82310400002)(70586007)(82740400003)(54906003)(186003)(36756003)(81166007)(86362001)(336012)(6486002)(2616005)(2906002)(26005)(6506007)(3480700007)(53546011)(478600001)(5660300002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: f00d81f3-88cb-48b8-4824-08d80c970ebf X-Forefront-PRVS: 042957ACD7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oXTi/LJF9EaGZwGbu1jP5ce/AODVOejxc2Kp7FIx5/7QZmhGnJuFrqj+2XrpqVmOer+CbYwXZlyCqFYwexKzScQGeW/qCX7Wz6pvg3W1qwJHVJmORigP4tJC29m83+f4C6w5962k0iacqDQNCvz0KI4FL+v3iB/tbS54zS8vTfGP5U6bPa/HGWfe1GHeUKaSrXC6INlOYl39eI/vF0oO8Tk7CenDFAbCsUMrRXZmIJxXrQSggs88ON97tetuuvLYzw1XixmN5bZTSbakY+WwmZDS2sEetqIEHoGh1iUnMCMcWqVcJ3ExdWCou+JAKijnaSqJEqKSR0lEGoV4o44iFtl9sZbI9kdK0mtyw9/4F0Buj93y53siGG3ajPB3TpdkFGVzfNXGBYH2cWP/jfAINg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2020 17:03:47.1310 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9da956f3-d651-4860-6b0e-08d80c971301 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR08MB2904 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , CodeWiz2280 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi > On 9 Jun 2020, at 16:47, Julien Grall wrote: >=20 >=20 >=20 > On 09/06/2020 16:28, Bertrand Marquis wrote: >> Hi, >>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >>>=20 >>> There does appear to be a secondary (CIC) controller that can forward >>> events to the GIC-400 and EDMA controllers for the keystone 2 family. >>> Admittedly, i'm not sure how it is being used with regards to the >>> peripherals. I only see mention of the GIC-400 parent for the devices >>> in the device tree. Maybe Bertrand has a better idea on whether any >>> peripherals go through the CIC first? I see that gic_interrupt () >>> fires once in Xen, which calls doIRQ to push out the virtual interrupt >>> to the dom0 kernel. The dom0 kernel then handles the interrupt and >>> returns, but gic_interrupt() never fires again in Xen. >> I do not remember of any CIC but the behaviour definitely look like an i= nterrupt acknowledge problem. >> Could you try the following: >> --- a/xen/arch/arm/gic-v2.c >> +++ b/xen/arch/arm/gic-v2.c >> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc *des= c) >> /* Lower the priority of the IRQ */ >> gicv2_eoi_irq(desc); >> /* Deactivation happens in maintenance interrupt / via GICV */ >> + >> + /* Test for Keystone2 */ >> + gicv2_dir_irq(desc); >> } >> I think the problem I had was related to the vgic not deactivating prope= rly the interrupt. >=20 > Are you suggesting the guest EOI is not properly forwarded to the hardwar= e when LR.HW is set? If so, this could possibly be workaround in Xen by rai= sing a maintenance interrupt every time a guest EOI an interrupt. Agree the maintenance interrupt would definitely be the right solution. This was an easy ack to check if that was the source of the problem. >=20 >> This might make the interrupt fire indefinitely !! >=20 > Most likely with level interrupt ;). Yes but this is just to confirm ;-) >=20 > Cheers, >=20 > --=20 > Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:06:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:06:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihhV-0005x1-AK; Tue, 09 Jun 2020 17:06:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jihhU-0005wY-By for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:06:12 +0000 X-Inumbo-ID: 816c8cee-aa73-11ea-b343-12813bfff9fa Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.64]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 816c8cee-aa73-11ea-b343-12813bfff9fa; Tue, 09 Jun 2020 17:06:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ROTFjDWmhBnCCOeV+iChPmj7xKuwbzclHrRQGgb0oYw=; b=eLADmza/xm1LTqcx0kXCqSVpAzsNFtMkdXlIGDbb4mDJ5tKfjJuFN8iCuB+gwTZRkQ8fkyyCbcbe6aEZxxyLAiTeh/6cCnSa46DQEJnn8WGfnWYIRw9whWk0VGaTL/koF58bQVFGmzEkwbeNew/lKo+ocMfkqvA6Nys0AR00zBc= Received: from AM5PR0201CA0008.eurprd02.prod.outlook.com (2603:10a6:203:3d::18) by AM0PR08MB4594.eurprd08.prod.outlook.com (2603:10a6:208:104::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Tue, 9 Jun 2020 17:06:04 +0000 Received: from AM5EUR03FT007.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:3d:cafe::cd) by AM5PR0201CA0008.outlook.office365.com (2603:10a6:203:3d::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Tue, 9 Jun 2020 17:06:04 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT007.mail.protection.outlook.com (10.152.16.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18 via Frontend Transport; Tue, 9 Jun 2020 17:06:04 +0000 Received: ("Tessian outbound 56dbe829191e:v59"); Tue, 09 Jun 2020 17:06:04 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 9faed8c8a8867f4d X-CR-MTA-TID: 64aa7808 Received: from c5cd79efab43.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A514B9B1-D4F9-4203-BA81-20C74E043B22.1; Tue, 09 Jun 2020 17:05:58 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c5cd79efab43.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 09 Jun 2020 17:05:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jrtuHnSH4c3Lar1juExLlnQovkdFhuu57nSWqb5g2W3W5W6o/6k/MujHIA5g1Ce1i1Y1j2JBXBzhMBOuVKL2g04a3O9AAit1I4uCXsDbDgXtVkEwZeBqNgxzx/vdFXXiHv6BlurUXPVtHqhmyyMlRzcZ2vE3ywVliFfeVgs/0cNnt4X5waZCueXlQISgtvUDloA2iyu7pKW3Sx/+fhMECE4xSWspd8PWhW9lCTLEtN1Cpb0J3D/duUiGkV6iqJxwMlManyN8qADY1u1ldzJI8A6QUjynEoMwo8h6Q5sgqBtBig8oJLz/xfYRhlWyU8Y82jx8j1Xrdae1NT03VXp6Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ROTFjDWmhBnCCOeV+iChPmj7xKuwbzclHrRQGgb0oYw=; b=eofFkdSiCdL+HVMwQ9RJAwA7QQSUYJ9X+5iAsldDd8r0/2aDAHMjSmqz1OL8rHKErNVIjUKioY6n5VNsdYtz9fTAtPpC7gFXDWQgnMY7oQ6iVCn9GCyyqspaaGAWYmok9QfVojv30mHet4nhF8qmbzbxGKNzdusb9CQbsiwhbKjGLyTRzimQLzZzkkbjFWdFw1L4bAECNLZIqy8QUDHTSVA0qzEpStNMTr4vvTklL+ZKpOS7KFIrkgjDqBkCrpmga5tZlIR1YvEfPCif2TUuCXVNu9T+2XGzFMPcufjS3cErCVKFUygT3yqhnbgAE2Mv7hXEHyuk+Yf6pdlNvlCPxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ROTFjDWmhBnCCOeV+iChPmj7xKuwbzclHrRQGgb0oYw=; b=eLADmza/xm1LTqcx0kXCqSVpAzsNFtMkdXlIGDbb4mDJ5tKfjJuFN8iCuB+gwTZRkQ8fkyyCbcbe6aEZxxyLAiTeh/6cCnSa46DQEJnn8WGfnWYIRw9whWk0VGaTL/koF58bQVFGmzEkwbeNew/lKo+ocMfkqvA6Nys0AR00zBc= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3594.eurprd08.prod.outlook.com (2603:10a6:10:4e::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.23; Tue, 9 Jun 2020 17:05:57 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3066.023; Tue, 9 Jun 2020 17:05:57 +0000 From: Bertrand Marquis To: CodeWiz2280 Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgIAAJpOAgABE7QCABAZcAIAAQRIAgAA9oACAAXYtAIAAD3sAgAAFaoCAAAL0gIAAEuIA Date: Tue, 9 Jun 2020 17:05:56 +0000 Message-ID: <06E3B839-BF8B-432D-89F7-3BBD464E4701@arm.com> References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 6d2364ef-0fcb-4bc2-ba29-08d80c9764c3 x-ms-traffictypediagnostic: DB7PR08MB3594:|AM0PR08MB4594: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 042957ACD7 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: I7SLrvIoixpSJUmPXpyk7V9G2MElHIVY92BZRbsYTJszXchgbT+StglzPoG5Gibz7hrrdQfG4nHn2PE25qaTsHOrsmkPRoMPAa6fw4bqj+VlgByHKkmln31u+A1ulISkLOJKRlXH101OI9HzGCu8oXRZz4tzm+t4fu+pJ2OHmC5K5daO6HFM5YJGL+vr4vylZnerWa+VmAP7dX8FpttzqZ1rpw/QwQl4SKqgkJ7lf5KzQIs2nl6yaBU/9qig+WXcAhCfN/89ob/nsFD3UssT/T3ePkJWhJtAcE+ZNYN06TFph+KWEzsqjlC15pRk8v6TucOQuYU2DRMxWFX3lRn76Q== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(136003)(366004)(39850400004)(316002)(91956017)(76116006)(66556008)(71200400001)(53546011)(66946007)(66476007)(5660300002)(54906003)(66446008)(6506007)(3480700007)(4326008)(83380400001)(33656002)(2616005)(186003)(26005)(64756008)(8936002)(2906002)(36756003)(8676002)(6512007)(7116003)(6916009)(478600001)(6486002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: roolbyQNigRBYKpMjcadps/zOg3Af8B+1BdG1HxZZrAQzWKmYCkrZUxuVC29Ceac0030JG6p/V9OqlERBHNGTo8PFJIqzXAc70ftXJE6fFMtencuUyufEKKYIxM64bEHnlGsSU8tgAXUIcRupw2PpI1uPa8IAusUUfJm9e8N8m68ATCw/K3hrqmdRmmuL7vyaMGP6kuWCjf/7RU+shJQNUKKCrUFw5iehd6E7YpN9fm4N+DZYWR84hAEV4ZWTpr3ZOzsABfaJNvsL+5CWY34vFl73M5ojkS7vLJ+vopbG3t4H9WSeCEdX8uc+LDiHbQRwsQVlbI77TjabsRmuked1FfL/kTVIch6Y57/imWxHEAcdVYx7EmQoHStHn0AaH9w0Q9afiq9PpxGJVQ3ZgTKCPDzzckP63KBoabZEXM9qtEgIyCbBBlAvPDab4ScE2o/yA5BfcZf44PlWBfHuRv6jxAbV5qajO4MmbWpLqxDkNE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3594 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT007.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(39860400002)(396003)(46966005)(5660300002)(7116003)(6512007)(4326008)(33656002)(6486002)(2906002)(86362001)(6862004)(70586007)(36756003)(70206006)(478600001)(336012)(47076004)(36906005)(316002)(8676002)(83380400001)(82310400002)(6506007)(8936002)(81166007)(186003)(3480700007)(356005)(26005)(54906003)(82740400003)(53546011)(2616005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: cf06f19a-0b8d-477e-3a75-08d80c976078 X-Forefront-PRVS: 042957ACD7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lJMdgxD10C0b2yxVs3Q0V0n5XFt5Z7oL+jVVIsG02FZI2rkCNPwfTVYO2VWwBT6YO1xqPo6S8PeyL8xZ+tNXdjFhM3hCgwjy2k4aPhwHeEmkBGnW7240Z5y9lbF4vNpUZdpGmjyae8sOkdGmC8vxMwReCybXqHoERU98jTQWyNIJIbG0lDNHdIpntrGZtOMXgya7n0IeoXlVP5hBli67bvmxsxHB9OxIFjDc6skoVp+6trReRCm3PAWWuaexXmOgaiDCYMnPGAPL3qbXt5IUtcpjjw4s8Cpf2hTvdiQBaW69vcV5YpD8hdtmJI344cFUnXGpgnbAgcyCXmEOFeWIFhZR3+nEgaSvBGtboB9K1KXEhPaeRPHqzqCPQIjl3N/dO8JV/UZ6zHb85byqp4HbTg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2020 17:06:04.2429 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6d2364ef-0fcb-4bc2-ba29-08d80c9764c3 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4594 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On 9 Jun 2020, at 16:58, CodeWiz2280 wrote: >=20 > On Tue, Jun 9, 2020 at 11:47 AM Julien Grall wrote: >>=20 >>=20 >>=20 >> On 09/06/2020 16:28, Bertrand Marquis wrote: >>> Hi, >>>=20 >>>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >>>>=20 >>>> There does appear to be a secondary (CIC) controller that can forward >>>> events to the GIC-400 and EDMA controllers for the keystone 2 family. >>>> Admittedly, i'm not sure how it is being used with regards to the >>>> peripherals. I only see mention of the GIC-400 parent for the devices >>>> in the device tree. Maybe Bertrand has a better idea on whether any >>>> peripherals go through the CIC first? I see that gic_interrupt () >>>> fires once in Xen, which calls doIRQ to push out the virtual interrupt >>>> to the dom0 kernel. The dom0 kernel then handles the interrupt and >>>> returns, but gic_interrupt() never fires again in Xen. >>>=20 >>> I do not remember of any CIC but the behaviour definitely look like an = interrupt acknowledge problem. >>>=20 >>> Could you try the following: >>> --- a/xen/arch/arm/gic-v2.c >>> +++ b/xen/arch/arm/gic-v2.c >>> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc *de= sc) >>> /* Lower the priority of the IRQ */ >>> gicv2_eoi_irq(desc); >>> /* Deactivation happens in maintenance interrupt / via GICV */ >>> + >>> + /* Test for Keystone2 */ >>> + gicv2_dir_irq(desc); >>> } >>>=20 >>> I think the problem I had was related to the vgic not deactivating prop= erly the interrupt. >>=20 > This seemed to help with the edge triggered interrupts, e.g. UART So the missing ack is definitely the issue. >=20 >> Are you suggesting the guest EOI is not properly forwarded to the >> hardware when LR.HW is set? If so, this could possibly be workaround in >> Xen by raising a maintenance interrupt every time a guest EOI an interru= pt. >>=20 >>> This might make the interrupt fire indefinitely !! >>=20 >> Most likely with level interrupt ;). >>=20 > This is what's happening with the Ethernet driver which is level > triggered. I had to temporarily disable it > to check the patch with the UART driver, otherwise the system would > hang processing the interrupt > repeatedly. This is quite logic yes. The way forward, as mentioned by Julien, will be to use a maintenance inter= rupt when the interrupt has been handled by the guest so that Xen can do th= e deactivation of the corresponding interrupt. This will add some overhead but there is probably no other solution. Cheers Bertrand From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:29:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:29:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii3q-0008Nf-R8; Tue, 09 Jun 2020 17:29:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii3p-0008Na-IR for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:29:17 +0000 X-Inumbo-ID: bda3882c-aa76-11ea-b34d-12813bfff9fa Received: from mout.kundenserver.de (unknown [212.227.126.134]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bda3882c-aa76-11ea-b34d-12813bfff9fa; Tue, 09 Jun 2020 17:29:15 +0000 (UTC) Received: from [192.168.100.1] ([82.252.135.106]) by mrelayeu.kundenserver.de (mreue010 [213.165.67.103]) with ESMTPSA (Nemesis) id 1MCsgS-1jrXkK0xc0-008tas; Tue, 09 Jun 2020 19:29:08 +0200 Subject: Re: [PATCH v2 1/8] hw/arm/aspeed: Correct DRAM container region size To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-2-f4bug@amsat.org> From: Laurent Vivier Autocrypt: addr=laurent@vivier.eu; prefer-encrypt=mutual; keydata= mQINBFYFJhkBEAC2me7w2+RizYOKZM+vZCx69GTewOwqzHrrHSG07MUAxJ6AY29/+HYf6EY2 WoeuLWDmXE7A3oJoIsRecD6BXHTb0OYS20lS608anr3B0xn5g0BX7es9Mw+hV/pL+63EOCVm SUVTEQwbGQN62guOKnJJJfphbbv82glIC/Ei4Ky8BwZkUuXd7d5NFJKC9/GDrbWdj75cDNQx UZ9XXbXEKY9MHX83Uy7JFoiFDMOVHn55HnncflUncO0zDzY7CxFeQFwYRbsCXOUL9yBtqLer Ky8/yjBskIlNrp0uQSt9LMoMsdSjYLYhvk1StsNPg74+s4u0Q6z45+l8RAsgLw5OLtTa+ePM JyS7OIGNYxAX6eZk1+91a6tnqfyPcMbduxyBaYXn94HUG162BeuyBkbNoIDkB7pCByed1A7q q9/FbuTDwgVGVLYthYSfTtN0Y60OgNkWCMtFwKxRaXt1WFA5ceqinN/XkgA+vf2Ch72zBkJL RBIhfOPFv5f2Hkkj0MvsUXpOWaOjatiu0fpPo6Hw14UEpywke1zN4NKubApQOlNKZZC4hu6/ 8pv2t4HRi7s0K88jQYBRPObjrN5+owtI51xMaYzvPitHQ2053LmgsOdN9EKOqZeHAYG2SmRW LOxYWKX14YkZI5j/TXfKlTpwSMvXho+efN4kgFvFmP6WT+tPnwARAQABtCJMYXVyZW50IFZp dmllciA8bGF1cmVudEB2aXZpZXIuZXU+iQI4BBMBAgAiBQJWBTDeAhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgAAKCRDzDDi9Py++PCEdD/oD8LD5UWxhQrMQCsUgLlXCSM7sxGLkwmmF ozqSSljEGRhffxZvO35wMFcdX9Z0QOabVoFTKrT04YmvbjsErh/dP5zeM/4EhUByeOS7s6Yl HubMXVQTkak9Wa9Eq6irYC6L41QNzz/oTwNEqL1weV1+XC3TNnht9B76lIaELyrJvRfgsp9M rE+PzGPo5h7QHWdL/Cmu8yOtPLa8Y6l/ywEJ040IoiAUfzRoaJs2csMXf0eU6gVBhCJ4bs91 jtWTXhkzdl4tdV+NOwj3j0ukPy+RjqeL2Ej+bomnPTOW8nAZ32dapmu7Fj7VApuQO/BSIHyO NkowMMjB46yohEepJaJZkcgseaus0x960c4ua/SUm/Nm6vioRsxyUmWd2nG0m089pp8LPopq WfAk1l4GciiMepp1Cxn7cnn1kmG6fhzedXZ/8FzsKjvx/aVeZwoEmucA42uGJ3Vk9TiVdZes lqMITkHqDIpHjC79xzlWkXOsDbA2UY/P18AtgJEZQPXbcrRBtdSifCuXdDfHvI+3exIdTpvj BfbgZAar8x+lcsQBugvktlQWPfAXZu4Shobi3/mDYMEDOE92dnNRD2ChNXg2IuvAL4OW40wh gXlkHC1ZgToNGoYVvGcZFug1NI+vCeCFchX+L3bXyLMg3rAfWMFPAZLzn42plIDMsBs+x2yP +bkCDQRWBSYZARAAvFJBFuX9A6eayxUPFaEczlMbGXugs0mazbOYGlyaWsiyfyc3PStHLFPj rSTaeJpPCjBJErwpZUN4BbpkBpaJiMuVO6egrC8Xy8/cnJakHPR2JPEvmj7Gm/L9DphTcE15 92rxXLesWzGBbuYxKsj8LEnrrvLyi3kNW6B5LY3Id+ZmU8YTQ2zLuGV5tLiWKKxc6s3eMXNq wrJTCzdVd6ThXrmUfAHbcFXOycUyf9vD+s+WKpcZzCXwKgm7x1LKsJx3UhuzT8ier1L363RW ZaJBZ9CTPiu8R5NCSn9V+BnrP3wlFbtLqXp6imGhazT9nJF86b5BVKpF8Vl3F0/Y+UZ4gUwL d9cmDKBcmQU/JaRUSWvvolNu1IewZZu3rFSVgcpdaj7F/1aC0t5vLdx9KQRyEAKvEOtCmP4m 38kU/6r33t3JuTJnkigda4+Sfu5kYGsogeYG6dNyjX5wpK5GJIJikEhdkwcLM+BUOOTi+I9u tX03BGSZo7FW/J7S9y0l5a8nooDs2gBRGmUgYKqQJHCDQyYut+hmcr+BGpUn9/pp2FTWijrP inb/Pc96YDQLQA1q2AeAFv3Rx3XoBTGl0RCY4KZ02c0kX/dm3eKfMX40XMegzlXCrqtzUk+N 8LeipEsnOoAQcEONAWWo1HcgUIgCjhJhBEF0AcELOQzitbJGG5UAEQEAAYkCHwQYAQIACQUC VgUmGQIbDAAKCRDzDDi9Py++PCD3D/9VCtydWDdOyMTJvEMRQGbx0GacqpydMEWbE3kUW0ha US5jz5gyJZHKR3wuf1En/3z+CEAEfP1M3xNGjZvpaKZXrgWaVWfXtGLoWAVTfE231NMQKGoB w2Dzx5ivIqxikXB6AanBSVpRpoaHWb06tPNxDL6SVV9lZpUn03DSR6gZEZvyPheNWkvz7bE6 FcqszV/PNvwm0C5Ju7NlJA8PBAQjkIorGnvN/vonbVh5GsRbhYPOc/JVwNNr63P76rZL8Gk/ hb3xtcIEi5CCzab45+URG/lzc6OV2nTj9Lg0SNcRhFZ2ILE3txrmI+aXmAu26+EkxLLfqCVT ohb2SffQha5KgGlOSBXustQSGH0yzzZVZb+HZPEvx6d/HjQ+t9sO1bCpEgPdZjyMuuMp9N1H ctbwGdQM2Qb5zgXO+8ZSzwC+6rHHIdtcB8PH2j+Nd88dVGYlWFKZ36ELeZxD7iJflsE8E8yg OpKgu3nD0ahBDqANU/ZmNNarBJEwvM2vfusmNnWm3QMIwxNuJghRyuFfx694Im1js0ZY3LEU JGSHFG4ZynA+ZFUPA6Xf0wHeJOxGKCGIyeKORsteIqgnkINW9fnKJw2pgk8qHkwVc3Vu+wGS ZiJK0xFusPQehjWTHn9WjMG1zvQ5TQQHxau/2FkP45+nRPco6vVFQe8JmgtRF8WFJA== Message-ID: <7a9dae30-bb50-f3cc-3806-eaa98d6ec866@vivier.eu> Date: Tue, 9 Jun 2020 19:29:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-2-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:IQ1R2+W1xcofpjLKnHoQc1zpzlvROpmk9GiFBZ16z8fVF2OKjf5 yYih0NjA8uDqyiWcn06cOU3bQ7PIjPUT7Dz+NDsnGMn4H6NBc713S2MO3vvOZcqtKkNXCUW 1zwwuGkXTzMtsuPmxZqOBIPqP+cCgcNbq1OudAa+xfTiOvMSsWTIWF5VqFVauFuct+6R8Vd hxf7zpZhU7hZ+pOgiSnrQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:CJwt+zB6upI=:26cXy6uCAs2DDGt8+kZhBS hkMO3KuFvCWlTqllFDZl4GcdoZr2/9H1PaZ17wsNzTJzyf36CLBL7dgzkLfFvW6uO7aRj+V2z RjAqOZs4D1LIQZdng9CwVgFMz9qPEmBh8LHEDqokteWQ6Rl0TIscpXlIwDROxt/FuuDqvz3hL EDLfaw02eyuq0BQ+yFbxE3+MCcJC/HhIB86kg7hmH1F6J4rRv5ao7xGPwyrhmeNaLE5b6xVqf Un+kRoRxWXpN/OPZjRTKzf1W6ZcZWXU+uyYlcXJ78W770wrl/Ak0A0p8rQFNNQRoDb3eI8MVI uVy0wTdyuqMj1Oh7VVW8AFVDJ5qHt3zVPuvNU9jdo8RPueDg/+f0uDYOCHInNq6QKNHRJLjvf MaAkV0kdizygMwBpYfJYD8gRR4jS+AYCBkqnlPBsCWYcfaIefLvSYJkngvJmD8/TRbU8p1bTS YvRdqpJjUc7Bdj+KPqfOUTuvwvZ9mSsv87LtcEg4o2M39NQHgWo3XmUgOHKdx2+ZrUvuGUw8F KWeWMAVh9NkJemrN8VUxzn+2pPX+BAStwtsz3tHBw//KJrOcG8BK1WtBkYp0CP+5jvjCJLRDw TThQt0VcSu32RTqJ08K2ucL6RuXg7oyj26IMc6nS/mCbawD8SMpHa2+TEOuxX/BOhe0HMMknH ZqIhO7xtA/+aa7cjhF4otYFC4b/wHJ5Hs+K5E+4QACd7xNJA6R0DJpbPSyaWCnEuWLpVIDtWF hYWA4Boa5PVDKh3MG5rqCdG5FglfPL7JVBDmgZF9I89GmQCihVHO+JQ/6lL36HzTU4vNwbLNm T/hesKtFX2HuKbPeAiyyyn+sEHy2MDzW9RIo1GdJBc8af56Z8t4dxZkmxhYa2w3rRCld97F X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Le 01/06/2020 à 16:29, Philippe Mathieu-Daudé a écrit : > memory_region_set_size() handle the 16 Exabytes limit by > special-casing the UINT64_MAX value. This is not a problem > for the 32-bit maximum, 4 GiB. > By using the UINT32_MAX value, the aspeed-ram-container > MemoryRegion ends up missing 1 byte: > > $ qemu-system-arm -M ast2600-evb -S -monitor stdio > (qemu) info mtree > > address-space: aspeed.fmc-ast2600-dma-dram > 0000000080000000-000000017ffffffe (prio 0, i/o): aspeed-ram-container > 0000000080000000-00000000bfffffff (prio 0, ram): ram > 00000000c0000000-ffffffffffffffff (prio 0, i/o): max_ram > > Fix by using the correct value. We now have: > > address-space: aspeed.fmc-ast2600-dma-dram > 0000000080000000-000000017fffffff (prio 0, i/o): aspeed-ram-container > 0000000080000000-00000000bfffffff (prio 0, ram): ram > 00000000c0000000-ffffffffffffffff (prio 0, i/o): max_ram > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/arm/aspeed.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c > index 2c23297edf..62344ac6a3 100644 > --- a/hw/arm/aspeed.c > +++ b/hw/arm/aspeed.c > @@ -262,7 +262,7 @@ static void aspeed_machine_init(MachineState *machine) > bmc = g_new0(AspeedBoardState, 1); > > memory_region_init(&bmc->ram_container, NULL, "aspeed-ram-container", > - UINT32_MAX); > + 4 * GiB); > memory_region_add_subregion(&bmc->ram_container, 0, machine->ram); > > object_initialize_child(OBJECT(machine), "soc", &bmc->soc, > Applied to my trivial-patches branch. Thanks, Laurent From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:30:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:30:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii50-0000f7-5t; Tue, 09 Jun 2020 17:30:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii4y-0000f0-Un for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:30:28 +0000 X-Inumbo-ID: e8969c5e-aa76-11ea-b34d-12813bfff9fa Received: from mout.kundenserver.de (unknown [212.227.126.130]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e8969c5e-aa76-11ea-b34d-12813bfff9fa; Tue, 09 Jun 2020 17:30:28 +0000 (UTC) Received: from [192.168.100.1] ([82.252.135.106]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.103]) with ESMTPSA (Nemesis) id 1MidPj-1j33nt0xi3-00fjqy; Tue, 09 Jun 2020 19:30:22 +0200 Subject: Re: [PATCH v2 6/8] hw/hppa/dino: Use the IEC binary prefix definitions To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-7-f4bug@amsat.org> From: Laurent Vivier Autocrypt: addr=laurent@vivier.eu; prefer-encrypt=mutual; keydata= mQINBFYFJhkBEAC2me7w2+RizYOKZM+vZCx69GTewOwqzHrrHSG07MUAxJ6AY29/+HYf6EY2 WoeuLWDmXE7A3oJoIsRecD6BXHTb0OYS20lS608anr3B0xn5g0BX7es9Mw+hV/pL+63EOCVm SUVTEQwbGQN62guOKnJJJfphbbv82glIC/Ei4Ky8BwZkUuXd7d5NFJKC9/GDrbWdj75cDNQx UZ9XXbXEKY9MHX83Uy7JFoiFDMOVHn55HnncflUncO0zDzY7CxFeQFwYRbsCXOUL9yBtqLer Ky8/yjBskIlNrp0uQSt9LMoMsdSjYLYhvk1StsNPg74+s4u0Q6z45+l8RAsgLw5OLtTa+ePM JyS7OIGNYxAX6eZk1+91a6tnqfyPcMbduxyBaYXn94HUG162BeuyBkbNoIDkB7pCByed1A7q q9/FbuTDwgVGVLYthYSfTtN0Y60OgNkWCMtFwKxRaXt1WFA5ceqinN/XkgA+vf2Ch72zBkJL RBIhfOPFv5f2Hkkj0MvsUXpOWaOjatiu0fpPo6Hw14UEpywke1zN4NKubApQOlNKZZC4hu6/ 8pv2t4HRi7s0K88jQYBRPObjrN5+owtI51xMaYzvPitHQ2053LmgsOdN9EKOqZeHAYG2SmRW LOxYWKX14YkZI5j/TXfKlTpwSMvXho+efN4kgFvFmP6WT+tPnwARAQABtCJMYXVyZW50IFZp dmllciA8bGF1cmVudEB2aXZpZXIuZXU+iQI4BBMBAgAiBQJWBTDeAhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgAAKCRDzDDi9Py++PCEdD/oD8LD5UWxhQrMQCsUgLlXCSM7sxGLkwmmF ozqSSljEGRhffxZvO35wMFcdX9Z0QOabVoFTKrT04YmvbjsErh/dP5zeM/4EhUByeOS7s6Yl HubMXVQTkak9Wa9Eq6irYC6L41QNzz/oTwNEqL1weV1+XC3TNnht9B76lIaELyrJvRfgsp9M rE+PzGPo5h7QHWdL/Cmu8yOtPLa8Y6l/ywEJ040IoiAUfzRoaJs2csMXf0eU6gVBhCJ4bs91 jtWTXhkzdl4tdV+NOwj3j0ukPy+RjqeL2Ej+bomnPTOW8nAZ32dapmu7Fj7VApuQO/BSIHyO NkowMMjB46yohEepJaJZkcgseaus0x960c4ua/SUm/Nm6vioRsxyUmWd2nG0m089pp8LPopq WfAk1l4GciiMepp1Cxn7cnn1kmG6fhzedXZ/8FzsKjvx/aVeZwoEmucA42uGJ3Vk9TiVdZes lqMITkHqDIpHjC79xzlWkXOsDbA2UY/P18AtgJEZQPXbcrRBtdSifCuXdDfHvI+3exIdTpvj BfbgZAar8x+lcsQBugvktlQWPfAXZu4Shobi3/mDYMEDOE92dnNRD2ChNXg2IuvAL4OW40wh gXlkHC1ZgToNGoYVvGcZFug1NI+vCeCFchX+L3bXyLMg3rAfWMFPAZLzn42plIDMsBs+x2yP +bkCDQRWBSYZARAAvFJBFuX9A6eayxUPFaEczlMbGXugs0mazbOYGlyaWsiyfyc3PStHLFPj rSTaeJpPCjBJErwpZUN4BbpkBpaJiMuVO6egrC8Xy8/cnJakHPR2JPEvmj7Gm/L9DphTcE15 92rxXLesWzGBbuYxKsj8LEnrrvLyi3kNW6B5LY3Id+ZmU8YTQ2zLuGV5tLiWKKxc6s3eMXNq wrJTCzdVd6ThXrmUfAHbcFXOycUyf9vD+s+WKpcZzCXwKgm7x1LKsJx3UhuzT8ier1L363RW ZaJBZ9CTPiu8R5NCSn9V+BnrP3wlFbtLqXp6imGhazT9nJF86b5BVKpF8Vl3F0/Y+UZ4gUwL d9cmDKBcmQU/JaRUSWvvolNu1IewZZu3rFSVgcpdaj7F/1aC0t5vLdx9KQRyEAKvEOtCmP4m 38kU/6r33t3JuTJnkigda4+Sfu5kYGsogeYG6dNyjX5wpK5GJIJikEhdkwcLM+BUOOTi+I9u tX03BGSZo7FW/J7S9y0l5a8nooDs2gBRGmUgYKqQJHCDQyYut+hmcr+BGpUn9/pp2FTWijrP inb/Pc96YDQLQA1q2AeAFv3Rx3XoBTGl0RCY4KZ02c0kX/dm3eKfMX40XMegzlXCrqtzUk+N 8LeipEsnOoAQcEONAWWo1HcgUIgCjhJhBEF0AcELOQzitbJGG5UAEQEAAYkCHwQYAQIACQUC VgUmGQIbDAAKCRDzDDi9Py++PCD3D/9VCtydWDdOyMTJvEMRQGbx0GacqpydMEWbE3kUW0ha US5jz5gyJZHKR3wuf1En/3z+CEAEfP1M3xNGjZvpaKZXrgWaVWfXtGLoWAVTfE231NMQKGoB w2Dzx5ivIqxikXB6AanBSVpRpoaHWb06tPNxDL6SVV9lZpUn03DSR6gZEZvyPheNWkvz7bE6 FcqszV/PNvwm0C5Ju7NlJA8PBAQjkIorGnvN/vonbVh5GsRbhYPOc/JVwNNr63P76rZL8Gk/ hb3xtcIEi5CCzab45+URG/lzc6OV2nTj9Lg0SNcRhFZ2ILE3txrmI+aXmAu26+EkxLLfqCVT ohb2SffQha5KgGlOSBXustQSGH0yzzZVZb+HZPEvx6d/HjQ+t9sO1bCpEgPdZjyMuuMp9N1H ctbwGdQM2Qb5zgXO+8ZSzwC+6rHHIdtcB8PH2j+Nd88dVGYlWFKZ36ELeZxD7iJflsE8E8yg OpKgu3nD0ahBDqANU/ZmNNarBJEwvM2vfusmNnWm3QMIwxNuJghRyuFfx694Im1js0ZY3LEU JGSHFG4ZynA+ZFUPA6Xf0wHeJOxGKCGIyeKORsteIqgnkINW9fnKJw2pgk8qHkwVc3Vu+wGS ZiJK0xFusPQehjWTHn9WjMG1zvQ5TQQHxau/2FkP45+nRPco6vVFQe8JmgtRF8WFJA== Message-ID: <8fc68c5f-2e62-9466-a6d9-873d6e101286@vivier.eu> Date: Tue, 9 Jun 2020 19:30:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-7-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:kWoyWcZqYkxB7s/T0deiqxYb0mV6anwnErhNnJw54CTKcrEExq5 Wy7WbIuWz8UHJEoQTXCFHlpBnHOFM1pW0qoRKo0dS9cHB/MtZOzHlLpUvQIDIHSNGyWE2lG we8YyRESfkZx/Jy8EBR+N9LwZ5nCp2PPkkTYLXv3W+lHEgcvQlg/mVZPbbMEkrwPpAxHYdA K+JIWSB51e8+BYwIJ1t+Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:LPtC63l6hr4=:5ncwvCU6J8Ds3BACsbmPUi jd7q7Ndin7jNNOluNsWo953J7uIhze2CX7FfiWSJ6rcUDUcMfEklKnN2LXhVTaALMLkaUk6am WaEKH7IayQPQTQrYNupFvtvKCebjhWgzaEBEHxMybSwEqA0v2Lxs92xDJLIjsKWSHi8p3P58M JZHaXForg7YWC3CbXOKarbV8qBwTgc+qTGZMoA9V4enq5BQGXPea0t4+/6hojLAGjgLs1WPaH ce8eobiQ6J3YyxG5Y1MJVl1HMTw7Fx1v2jPYoplGQYd/y281p8OZIC0JMB9v7JptZFKyEtoFK J8va5k11jdtHNrgB+tp/RqUqCYxMgoubhY50SWB/ibSc+OEh/iVNMAkP0ReXnOFPGhwMfD9sO E4/rf3Swmb/v5UGdIl0CkksjUg9XNzwdjzyBBTCr5AklKO92SuXyL/cbZdJP4p0EEbFI5SjoE E/zKXf/h8CbYhBcY8sl67Ld9y892W6KbUMHIJyOmWVQJxFHdUByQ6Z4Dwbl+dm9aPuCMmoJJc clt9wyg/n7nyn6C+VcoBnRpReZlqcNqalvAbmCsOeLekOZi05ZtWNKcrrfuPHq91XRdsc6CLV PrwwAsIgkzVCcIInV/BZMPZ0j4BXzWorzG50OYK2bf6NOd3eO5xswqND8tGX+lyATyRWus6u7 t3VLSRllDFhfVfm0a/XyKDJ9hibl+maQb8q3ldn3PUlcAyK7s7Lr7JP5o0wnhJtwJ9UoDHIWJ iZwFbDefDxfCDLWaGEyDhfzE2mBt+Ww9wPNESIj7wjxtMDoANjRYR1pwHeWUJVNaTw7NYL5aZ dfDPp5T6SuLp7QZsjam16lPuAe/f9bd+Q2vY8CVzsskNOBzpVI= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Le 01/06/2020 à 16:29, Philippe Mathieu-Daudé a écrit : > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/hppa/dino.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/hppa/dino.c b/hw/hppa/dino.c > index 2b1b38c58a..7290f23962 100644 > --- a/hw/hppa/dino.c > +++ b/hw/hppa/dino.c > @@ -542,7 +542,7 @@ PCIBus *dino_init(MemoryRegion *addr_space, > &s->parent_obj.data_mem); > > /* Dino PCI bus memory. */ > - memory_region_init(&s->pci_mem, OBJECT(s), "pci-memory", 1ull << 32); > + memory_region_init(&s->pci_mem, OBJECT(s), "pci-memory", 4 * GiB); > > b = pci_register_root_bus(dev, "pci", dino_set_irq, dino_pci_map_irq, s, > &s->pci_mem, get_system_io(), > @@ -561,7 +561,7 @@ PCIBus *dino_init(MemoryRegion *addr_space, > } > > /* Set up PCI view of memory: Bus master address space. */ > - memory_region_init(&s->bm, OBJECT(s), "bm-dino", 1ull << 32); > + memory_region_init(&s->bm, OBJECT(s), "bm-dino", 4 * GiB); > memory_region_init_alias(&s->bm_ram_alias, OBJECT(s), > "bm-system", addr_space, 0, > 0xf0000000 + DINO_MEM_CHUNK_SIZE); > Applied to my trivial-patches branch. Thanks, Laurent From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:32:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:32:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii6b-0000mO-I5; Tue, 09 Jun 2020 17:32:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii6a-0000mI-Gc for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:32:08 +0000 X-Inumbo-ID: 241daad8-aa77-11ea-bca7-bc764e2007e4 Received: from mout.kundenserver.de (unknown [212.227.126.133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 241daad8-aa77-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 17:32:07 +0000 (UTC) Received: from [192.168.100.1] ([82.252.135.106]) by mrelayeu.kundenserver.de (mreue009 [213.165.67.103]) with ESMTPSA (Nemesis) id 1N5VPe-1itPo10Xxi-016yew; Tue, 09 Jun 2020 19:32:03 +0200 Subject: Re: [PATCH v2 7/8] hw/i386/xen/xen-hvm: Use the IEC binary prefix definitions To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-8-f4bug@amsat.org> From: Laurent Vivier Autocrypt: addr=laurent@vivier.eu; prefer-encrypt=mutual; keydata= mQINBFYFJhkBEAC2me7w2+RizYOKZM+vZCx69GTewOwqzHrrHSG07MUAxJ6AY29/+HYf6EY2 WoeuLWDmXE7A3oJoIsRecD6BXHTb0OYS20lS608anr3B0xn5g0BX7es9Mw+hV/pL+63EOCVm SUVTEQwbGQN62guOKnJJJfphbbv82glIC/Ei4Ky8BwZkUuXd7d5NFJKC9/GDrbWdj75cDNQx UZ9XXbXEKY9MHX83Uy7JFoiFDMOVHn55HnncflUncO0zDzY7CxFeQFwYRbsCXOUL9yBtqLer Ky8/yjBskIlNrp0uQSt9LMoMsdSjYLYhvk1StsNPg74+s4u0Q6z45+l8RAsgLw5OLtTa+ePM JyS7OIGNYxAX6eZk1+91a6tnqfyPcMbduxyBaYXn94HUG162BeuyBkbNoIDkB7pCByed1A7q q9/FbuTDwgVGVLYthYSfTtN0Y60OgNkWCMtFwKxRaXt1WFA5ceqinN/XkgA+vf2Ch72zBkJL RBIhfOPFv5f2Hkkj0MvsUXpOWaOjatiu0fpPo6Hw14UEpywke1zN4NKubApQOlNKZZC4hu6/ 8pv2t4HRi7s0K88jQYBRPObjrN5+owtI51xMaYzvPitHQ2053LmgsOdN9EKOqZeHAYG2SmRW LOxYWKX14YkZI5j/TXfKlTpwSMvXho+efN4kgFvFmP6WT+tPnwARAQABtCJMYXVyZW50IFZp dmllciA8bGF1cmVudEB2aXZpZXIuZXU+iQI4BBMBAgAiBQJWBTDeAhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgAAKCRDzDDi9Py++PCEdD/oD8LD5UWxhQrMQCsUgLlXCSM7sxGLkwmmF ozqSSljEGRhffxZvO35wMFcdX9Z0QOabVoFTKrT04YmvbjsErh/dP5zeM/4EhUByeOS7s6Yl HubMXVQTkak9Wa9Eq6irYC6L41QNzz/oTwNEqL1weV1+XC3TNnht9B76lIaELyrJvRfgsp9M rE+PzGPo5h7QHWdL/Cmu8yOtPLa8Y6l/ywEJ040IoiAUfzRoaJs2csMXf0eU6gVBhCJ4bs91 jtWTXhkzdl4tdV+NOwj3j0ukPy+RjqeL2Ej+bomnPTOW8nAZ32dapmu7Fj7VApuQO/BSIHyO NkowMMjB46yohEepJaJZkcgseaus0x960c4ua/SUm/Nm6vioRsxyUmWd2nG0m089pp8LPopq WfAk1l4GciiMepp1Cxn7cnn1kmG6fhzedXZ/8FzsKjvx/aVeZwoEmucA42uGJ3Vk9TiVdZes lqMITkHqDIpHjC79xzlWkXOsDbA2UY/P18AtgJEZQPXbcrRBtdSifCuXdDfHvI+3exIdTpvj BfbgZAar8x+lcsQBugvktlQWPfAXZu4Shobi3/mDYMEDOE92dnNRD2ChNXg2IuvAL4OW40wh gXlkHC1ZgToNGoYVvGcZFug1NI+vCeCFchX+L3bXyLMg3rAfWMFPAZLzn42plIDMsBs+x2yP +bkCDQRWBSYZARAAvFJBFuX9A6eayxUPFaEczlMbGXugs0mazbOYGlyaWsiyfyc3PStHLFPj rSTaeJpPCjBJErwpZUN4BbpkBpaJiMuVO6egrC8Xy8/cnJakHPR2JPEvmj7Gm/L9DphTcE15 92rxXLesWzGBbuYxKsj8LEnrrvLyi3kNW6B5LY3Id+ZmU8YTQ2zLuGV5tLiWKKxc6s3eMXNq wrJTCzdVd6ThXrmUfAHbcFXOycUyf9vD+s+WKpcZzCXwKgm7x1LKsJx3UhuzT8ier1L363RW ZaJBZ9CTPiu8R5NCSn9V+BnrP3wlFbtLqXp6imGhazT9nJF86b5BVKpF8Vl3F0/Y+UZ4gUwL d9cmDKBcmQU/JaRUSWvvolNu1IewZZu3rFSVgcpdaj7F/1aC0t5vLdx9KQRyEAKvEOtCmP4m 38kU/6r33t3JuTJnkigda4+Sfu5kYGsogeYG6dNyjX5wpK5GJIJikEhdkwcLM+BUOOTi+I9u tX03BGSZo7FW/J7S9y0l5a8nooDs2gBRGmUgYKqQJHCDQyYut+hmcr+BGpUn9/pp2FTWijrP inb/Pc96YDQLQA1q2AeAFv3Rx3XoBTGl0RCY4KZ02c0kX/dm3eKfMX40XMegzlXCrqtzUk+N 8LeipEsnOoAQcEONAWWo1HcgUIgCjhJhBEF0AcELOQzitbJGG5UAEQEAAYkCHwQYAQIACQUC VgUmGQIbDAAKCRDzDDi9Py++PCD3D/9VCtydWDdOyMTJvEMRQGbx0GacqpydMEWbE3kUW0ha US5jz5gyJZHKR3wuf1En/3z+CEAEfP1M3xNGjZvpaKZXrgWaVWfXtGLoWAVTfE231NMQKGoB w2Dzx5ivIqxikXB6AanBSVpRpoaHWb06tPNxDL6SVV9lZpUn03DSR6gZEZvyPheNWkvz7bE6 FcqszV/PNvwm0C5Ju7NlJA8PBAQjkIorGnvN/vonbVh5GsRbhYPOc/JVwNNr63P76rZL8Gk/ hb3xtcIEi5CCzab45+URG/lzc6OV2nTj9Lg0SNcRhFZ2ILE3txrmI+aXmAu26+EkxLLfqCVT ohb2SffQha5KgGlOSBXustQSGH0yzzZVZb+HZPEvx6d/HjQ+t9sO1bCpEgPdZjyMuuMp9N1H ctbwGdQM2Qb5zgXO+8ZSzwC+6rHHIdtcB8PH2j+Nd88dVGYlWFKZ36ELeZxD7iJflsE8E8yg OpKgu3nD0ahBDqANU/ZmNNarBJEwvM2vfusmNnWm3QMIwxNuJghRyuFfx694Im1js0ZY3LEU JGSHFG4ZynA+ZFUPA6Xf0wHeJOxGKCGIyeKORsteIqgnkINW9fnKJw2pgk8qHkwVc3Vu+wGS ZiJK0xFusPQehjWTHn9WjMG1zvQ5TQQHxau/2FkP45+nRPco6vVFQe8JmgtRF8WFJA== Message-ID: <2f517282-a950-7bb0-219b-87c843ba1aa9@vivier.eu> Date: Tue, 9 Jun 2020 19:31:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-8-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:iBNPhQQcrpUp/3RAl90FPZv091PWu/WsnYMgxRBZUgS/NpN9E+C hZxv9XQwD3pvXNRszVBmOuyML7xIzkfIjDmnCak7jtmyRhsn3dZ+FABeocxGO22XD30Iug2 2KpzFLsqT51SmDQGOSSyQL3TFg5cjFVrvR2uJ3OvVHP6vvsbqoH3O26u1u96CFJv2nlHiiZ 8JJJhKp1SM7+GZbjvz0wA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:f0xq687f0Ww=:rmoSs+agvYGUQxwmVwBlzG uJ00JCPeTiKSB6VJe8aFIHvejjF1nLIDFIhOy8/BxgRn4tcmimaGGWYuVSsLGimS1zZEYqH7a hS/1q1JknS0LDzIXPDeciGCodKdrcKdkrOlr0Wj0N5jZe0CxFkIoxhEB31xhFd4RF4HBPGnj/ K8UCu/c/GcDdAY3iDVi00f8othPJcXVUIMGNX+GMbSGpSFSkhxcDtjtvuanRRS7xTXMsvKPzS EFEeIobGXGwS5glc06/bSZuS480NTXr3coFiJzl3zRlcqTJvoMYkng/VYn3vrHdwnhouzXYxj istZ7dmJpA4v/C7qd1CHIkz4G8+nyTsC+SA+HAhan0L1e4spAw7eOPpWnEumjILHnw9cb/8lH /F3XGTbspZ7C/QtdKiZNRWQJZzu60q3i6oLOvMGKb/X0efRhylsZA5bY4f2PBvde0beFJX715 FyhSyZAtMZ3bSCr87PH1vdnB6uS8zBHHx+LVW2vFJjCVHwpIrc1fekNVy1+ydLDOilKQlZInS wWgdSw+9HhAB88V+ZT0ItK/tRG9PiJBkEKoOQciDMFXp+yf0jk6BD8fCsuR7mh/kpNeDuISpl S1v69XMQWtzBhHpJuRHfGYED1mPk/dvosk92PG3yZ7P/+/F5Y/5Hc94J8hly7PjfkqMslaqhW tgIzGvwiMDajz22JOFSR+OafakXMheXLvwbmv9fy2XLkqnBN0uic57Po59R/Ef82WywX85Ift WZ9EcE8/wLb4eOS83UeJS2ZywR5vjabl8J4pt2e8MAX6mQwtJnxpWuzHp053i1phlEMGvjSPv IlkY22vAcvv6v51cXSZcAIYFfEAeBXpnNkpNz1n94K66tKGTvqIBx3+kdVByp/RAREhhqac X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Le 01/06/2020 à 16:29, Philippe Mathieu-Daudé a écrit : > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > hw/i386/xen/xen-hvm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c > index 82ece6b9e7..94fe5d65e9 100644 > --- a/hw/i386/xen/xen-hvm.c > +++ b/hw/i386/xen/xen-hvm.c > @@ -9,6 +9,7 @@ > */ > > #include "qemu/osdep.h" > +#include "qemu/units.h" > > #include "cpu.h" > #include "hw/pci/pci.h" > @@ -230,7 +231,7 @@ static void xen_ram_init(PCMachineState *pcms, > * Xen does not allocate the memory continuously, it keeps a > * hole of the size computed above or passed in. > */ > - block_len = (1ULL << 32) + x86ms->above_4g_mem_size; > + block_len = (4 * GiB) + x86ms->above_4g_mem_size; > } > memory_region_init_ram(&ram_memory, NULL, "xen.ram", block_len, > &error_fatal); > Applied to my trivial-patches branch. Thanks, Laurent From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:32:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:32:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii6j-0000nc-QP; Tue, 09 Jun 2020 17:32:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii6i-0000nI-6s for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:32:16 +0000 X-Inumbo-ID: 291f5d42-aa77-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 291f5d42-aa77-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 17:32:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=or7xH7kh2yfQPa/jYQWdeRk3Yu1/zsUtXp6HurErW+M=; b=JwB2765ve7D+usfw5Y3gTg5v5C xXLhftFnJubgxQSUk2LMW9tPbxTv+UfR/RXj0qGzEX2fk4Y7bYmI9zUlK/B8Z4TZsWj8Eqk/NZuE2 EYRVfTAvwBtQtFIDOmtW5NZOJBdJdI+jOxnJcVeBxeBVNJZzkixa+xj8Ha6FVStSDo1U=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii6h-0004tR-AV; Tue, 09 Jun 2020 17:32:15 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jii6h-0003uM-35; Tue, 09 Jun 2020 17:32:15 +0000 Subject: Re: Keystone Issue To: Bertrand Marquis References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> From: Julien Grall Message-ID: <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> Date: Tue, 9 Jun 2020 18:32:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <03607739-A4FF-486A-899A-F5F36870225A@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , CodeWiz2280 , Marc Zyngier Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" (+ Marc) On 09/06/2020 18:03, Bertrand Marquis wrote: > Hi > >> On 9 Jun 2020, at 16:47, Julien Grall wrote: >> >> >> >> On 09/06/2020 16:28, Bertrand Marquis wrote: >>> Hi, >>>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >>>> >>>> There does appear to be a secondary (CIC) controller that can forward >>>> events to the GIC-400 and EDMA controllers for the keystone 2 family. >>>> Admittedly, i'm not sure how it is being used with regards to the >>>> peripherals. I only see mention of the GIC-400 parent for the devices >>>> in the device tree. Maybe Bertrand has a better idea on whether any >>>> peripherals go through the CIC first? I see that gic_interrupt () >>>> fires once in Xen, which calls doIRQ to push out the virtual interrupt >>>> to the dom0 kernel. The dom0 kernel then handles the interrupt and >>>> returns, but gic_interrupt() never fires again in Xen. >>> I do not remember of any CIC but the behaviour definitely look like an interrupt acknowledge problem. >>> Could you try the following: >>> --- a/xen/arch/arm/gic-v2.c >>> +++ b/xen/arch/arm/gic-v2.c >>> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc *desc) >>> /* Lower the priority of the IRQ */ >>> gicv2_eoi_irq(desc); >>> /* Deactivation happens in maintenance interrupt / via GICV */ >>> + >>> + /* Test for Keystone2 */ >>> + gicv2_dir_irq(desc); >>> } >>> I think the problem I had was related to the vgic not deactivating properly the interrupt. >> >> Are you suggesting the guest EOI is not properly forwarded to the hardware when LR.HW is set? If so, this could possibly be workaround in Xen by raising a maintenance interrupt every time a guest EOI an interrupt. > > Agree the maintenance interrupt would definitely be the right solution I would like to make sure we aren't missing anything in Xen first. From what you said, you have encountered this issue in the past with a different hypervisor. So it doesn't look like to be Xen related. Was there any official statement from TI? If not, can we try to get some input from them first? @Marc, I know you dropped 32-bit support in KVM recently :). Although, I was wondering if you heard about any potential issue with guest EOI not forwarded to the host. This is on TI Keystone (Cortex A-15). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:33:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:33:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii7c-0000yD-7k; Tue, 09 Jun 2020 17:33:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jii7b-0000y1-OQ for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:33:11 +0000 X-Inumbo-ID: 49d07bb6-aa77-11ea-bca7-bc764e2007e4 Received: from mout.kundenserver.de (unknown [212.227.126.134]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 49d07bb6-aa77-11ea-bca7-bc764e2007e4; Tue, 09 Jun 2020 17:33:11 +0000 (UTC) Received: from [192.168.100.1] ([82.252.135.106]) by mrelayeu.kundenserver.de (mreue011 [213.165.67.103]) with ESMTPSA (Nemesis) id 1MA7b8-1jonjk3nZ4-00BdwY; Tue, 09 Jun 2020 19:33:07 +0200 Subject: Re: [PATCH v2 8/8] target/i386/cpu: Use the IEC binary prefix definitions To: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-devel@nongnu.org References: <20200601142930.29408-1-f4bug@amsat.org> <20200601142930.29408-9-f4bug@amsat.org> From: Laurent Vivier Autocrypt: addr=laurent@vivier.eu; prefer-encrypt=mutual; keydata= mQINBFYFJhkBEAC2me7w2+RizYOKZM+vZCx69GTewOwqzHrrHSG07MUAxJ6AY29/+HYf6EY2 WoeuLWDmXE7A3oJoIsRecD6BXHTb0OYS20lS608anr3B0xn5g0BX7es9Mw+hV/pL+63EOCVm SUVTEQwbGQN62guOKnJJJfphbbv82glIC/Ei4Ky8BwZkUuXd7d5NFJKC9/GDrbWdj75cDNQx UZ9XXbXEKY9MHX83Uy7JFoiFDMOVHn55HnncflUncO0zDzY7CxFeQFwYRbsCXOUL9yBtqLer Ky8/yjBskIlNrp0uQSt9LMoMsdSjYLYhvk1StsNPg74+s4u0Q6z45+l8RAsgLw5OLtTa+ePM JyS7OIGNYxAX6eZk1+91a6tnqfyPcMbduxyBaYXn94HUG162BeuyBkbNoIDkB7pCByed1A7q q9/FbuTDwgVGVLYthYSfTtN0Y60OgNkWCMtFwKxRaXt1WFA5ceqinN/XkgA+vf2Ch72zBkJL RBIhfOPFv5f2Hkkj0MvsUXpOWaOjatiu0fpPo6Hw14UEpywke1zN4NKubApQOlNKZZC4hu6/ 8pv2t4HRi7s0K88jQYBRPObjrN5+owtI51xMaYzvPitHQ2053LmgsOdN9EKOqZeHAYG2SmRW LOxYWKX14YkZI5j/TXfKlTpwSMvXho+efN4kgFvFmP6WT+tPnwARAQABtCJMYXVyZW50IFZp dmllciA8bGF1cmVudEB2aXZpZXIuZXU+iQI4BBMBAgAiBQJWBTDeAhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgAAKCRDzDDi9Py++PCEdD/oD8LD5UWxhQrMQCsUgLlXCSM7sxGLkwmmF ozqSSljEGRhffxZvO35wMFcdX9Z0QOabVoFTKrT04YmvbjsErh/dP5zeM/4EhUByeOS7s6Yl HubMXVQTkak9Wa9Eq6irYC6L41QNzz/oTwNEqL1weV1+XC3TNnht9B76lIaELyrJvRfgsp9M rE+PzGPo5h7QHWdL/Cmu8yOtPLa8Y6l/ywEJ040IoiAUfzRoaJs2csMXf0eU6gVBhCJ4bs91 jtWTXhkzdl4tdV+NOwj3j0ukPy+RjqeL2Ej+bomnPTOW8nAZ32dapmu7Fj7VApuQO/BSIHyO NkowMMjB46yohEepJaJZkcgseaus0x960c4ua/SUm/Nm6vioRsxyUmWd2nG0m089pp8LPopq WfAk1l4GciiMepp1Cxn7cnn1kmG6fhzedXZ/8FzsKjvx/aVeZwoEmucA42uGJ3Vk9TiVdZes lqMITkHqDIpHjC79xzlWkXOsDbA2UY/P18AtgJEZQPXbcrRBtdSifCuXdDfHvI+3exIdTpvj BfbgZAar8x+lcsQBugvktlQWPfAXZu4Shobi3/mDYMEDOE92dnNRD2ChNXg2IuvAL4OW40wh gXlkHC1ZgToNGoYVvGcZFug1NI+vCeCFchX+L3bXyLMg3rAfWMFPAZLzn42plIDMsBs+x2yP +bkCDQRWBSYZARAAvFJBFuX9A6eayxUPFaEczlMbGXugs0mazbOYGlyaWsiyfyc3PStHLFPj rSTaeJpPCjBJErwpZUN4BbpkBpaJiMuVO6egrC8Xy8/cnJakHPR2JPEvmj7Gm/L9DphTcE15 92rxXLesWzGBbuYxKsj8LEnrrvLyi3kNW6B5LY3Id+ZmU8YTQ2zLuGV5tLiWKKxc6s3eMXNq wrJTCzdVd6ThXrmUfAHbcFXOycUyf9vD+s+WKpcZzCXwKgm7x1LKsJx3UhuzT8ier1L363RW ZaJBZ9CTPiu8R5NCSn9V+BnrP3wlFbtLqXp6imGhazT9nJF86b5BVKpF8Vl3F0/Y+UZ4gUwL d9cmDKBcmQU/JaRUSWvvolNu1IewZZu3rFSVgcpdaj7F/1aC0t5vLdx9KQRyEAKvEOtCmP4m 38kU/6r33t3JuTJnkigda4+Sfu5kYGsogeYG6dNyjX5wpK5GJIJikEhdkwcLM+BUOOTi+I9u tX03BGSZo7FW/J7S9y0l5a8nooDs2gBRGmUgYKqQJHCDQyYut+hmcr+BGpUn9/pp2FTWijrP inb/Pc96YDQLQA1q2AeAFv3Rx3XoBTGl0RCY4KZ02c0kX/dm3eKfMX40XMegzlXCrqtzUk+N 8LeipEsnOoAQcEONAWWo1HcgUIgCjhJhBEF0AcELOQzitbJGG5UAEQEAAYkCHwQYAQIACQUC VgUmGQIbDAAKCRDzDDi9Py++PCD3D/9VCtydWDdOyMTJvEMRQGbx0GacqpydMEWbE3kUW0ha US5jz5gyJZHKR3wuf1En/3z+CEAEfP1M3xNGjZvpaKZXrgWaVWfXtGLoWAVTfE231NMQKGoB w2Dzx5ivIqxikXB6AanBSVpRpoaHWb06tPNxDL6SVV9lZpUn03DSR6gZEZvyPheNWkvz7bE6 FcqszV/PNvwm0C5Ju7NlJA8PBAQjkIorGnvN/vonbVh5GsRbhYPOc/JVwNNr63P76rZL8Gk/ hb3xtcIEi5CCzab45+URG/lzc6OV2nTj9Lg0SNcRhFZ2ILE3txrmI+aXmAu26+EkxLLfqCVT ohb2SffQha5KgGlOSBXustQSGH0yzzZVZb+HZPEvx6d/HjQ+t9sO1bCpEgPdZjyMuuMp9N1H ctbwGdQM2Qb5zgXO+8ZSzwC+6rHHIdtcB8PH2j+Nd88dVGYlWFKZ36ELeZxD7iJflsE8E8yg OpKgu3nD0ahBDqANU/ZmNNarBJEwvM2vfusmNnWm3QMIwxNuJghRyuFfx694Im1js0ZY3LEU JGSHFG4ZynA+ZFUPA6Xf0wHeJOxGKCGIyeKORsteIqgnkINW9fnKJw2pgk8qHkwVc3Vu+wGS ZiJK0xFusPQehjWTHn9WjMG1zvQ5TQQHxau/2FkP45+nRPco6vVFQe8JmgtRF8WFJA== Message-ID: <2b0e3a42-8167-4bf1-e156-7ece995eadd1@vivier.eu> Date: Tue, 9 Jun 2020 19:33:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601142930.29408-9-f4bug@amsat.org> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:y5VXJjJwhO8x7pSGDWsZy8gcjHdYEnKZquWZijuffclBFrdo4XZ puUh84K7zYsWj5zQw/yv7B/PXfxDJQM5LTja3NuU9wcbrL4f6Oa677YIxcaTpW/KadfYuw+ 3OM8ibj8lpdi0aCTw9GBcl7MtO7kMjUv3VFGKLDWL0O1gT6btx94tyVAJqJYYX4VduvwGkX 4kQaav99W8L5SviuftgcQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:lf2pKGcVZ8U=:bu1VLSJxeAU2lEdo6YlK/N e1X4WmlUVQ1oUuLUSHSy6rwrMIsf3iOwvwBBnuQvRdCqoc6geVBzbDmnghygsAlYKZXNjLAIn 2vvQjrF9KkK5R0dxeoiKZ+SJ8VJclZrO93XbgLWhWThZJuF5DFj9tCwFG+f0rT7uv1ILgx9/8 BFbv7sk3Sq4I8GsVOeAk/k8ulN2W+ObkngnO5AN5vJRwe0Le5Hj94xnOY4Xrb9aQE3D6giDNP 9DGh62GRTEJRL373SoLzdbyAt5NWjzuiCSqUf9InwVRJ+SSac75uYb83LM81SmU461+z6E+5p Ff+pqoRphZqfrJkQNTSVGgVsduXCsr66D+IlB2bY4vavDYjN3638ARfH6HunJsmjyDOEV9QLc sYFD3njIOzcPBcz11NGbnj1xNJGfzfUwmOT1iWNDkBGkBJ52hZ6tOALw32ow6WrjnxN30GF8R Cd6xcE/MV00gXVqCm4j1W3RgG0t7nFPkV1LdpC7220G5zj+rXuj/TOriUveT0lBYS++v6/BBB f4N079AXVWy4ZfGiRlQpFRHwecf43mQivCvwhTZK8p9Uq+JH5/kSknk/1ajvYCS7QS5vMx6wU a/WgkatWWsRKPSnvAWLySLJ7ApUnV74nr87NdO05OazQ5n8eRmIIlFDMfQeAPsrrMmVQBBf5+ OGgyTq6VoFePjhe6uM29F2lxIvGYQBn05pC5Y11YQANaI5ZYdoHGdsH4E9q6qS+OG8VKnXR7o xPJqat9EHeWXx/im1Df0bsYluOyileGYATJnJvSy6Sublxcd0CJWlweLnaYVTqrs4gp+ASMBX 5JjN9Dvw1T4Do82cFTFhHxcMCoF3lGXEheoB1HdwuQeNHFWhT++f0x9700H8gCiVYbo1v4n X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Stefano Stabellini , Eduardo Habkost , "Michael S. Tsirkin" , Andrew Jeffery , Helge Deller , Paul Durrant , qemu-trivial@nongnu.org, =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , qemu-arm@nongnu.org, =?UTF-8?Q?Herv=c3=a9_Poussineau?= , Joel Stanley , Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , qemu-ppc@nongnu.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Le 01/06/2020 à 16:29, Philippe Mathieu-Daudé a écrit : > IEC binary prefixes ease code review: the unit is explicit. > > Reviewed-by: Peter Maydell > Signed-off-by: Philippe Mathieu-Daudé > --- > target/i386/cpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/i386/cpu.c b/target/i386/cpu.c > index 3733d9a279..33ce4861fb 100644 > --- a/target/i386/cpu.c > +++ b/target/i386/cpu.c > @@ -6159,7 +6159,7 @@ static void x86_cpu_machine_done(Notifier *n, void *unused) > if (smram) { > cpu->smram = g_new(MemoryRegion, 1); > memory_region_init_alias(cpu->smram, OBJECT(cpu), "smram", > - smram, 0, 1ull << 32); > + smram, 0, 4 * GiB); > memory_region_set_enabled(cpu->smram, true); > memory_region_add_subregion_overlap(cpu->cpu_as_root, 0, cpu->smram, 1); > } > Applied to my trivial-patches branch. Thanks, Laurent From xen-devel-bounces@lists.xenproject.org Tue Jun 09 17:46:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 17:46:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiiJz-0001yu-Eb; Tue, 09 Jun 2020 17:45:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiiJy-0001yp-23 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 17:45:58 +0000 X-Inumbo-ID: 12cf4636-aa79-11ea-8496-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 12cf4636-aa79-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 17:45:57 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BFA39207ED; Tue, 9 Jun 2020 17:45:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591724756; bh=wlYabBiJGc7VSyncs6OWlQqlLE2Ut4rsDNdk6MY5J9I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Rg8qy68Q9gMeVk5CtcZkF45VwE3MzspL/JUpzmRz3skLNCh6eGTwMSQTVdmOg8MrW Jy1B90gcDxJOdkh94D9fHreCd4KfvEFTY8AbjQFQzOz4h7475vC7kz53ORShzVpraG aIZNqVNIqJAHYxMDteRJUyt+BVwU88IF59uzCQHA= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jiiJv-001WTZ-At; Tue, 09 Jun 2020 18:45:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 09 Jun 2020 18:45:55 +0100 From: Marc Zyngier To: Julien Grall Subject: Re: Keystone Issue In-Reply-To: <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <6033f9cecbf10f50f4a713ce52105426@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: julien@xen.org, Bertrand.Marquis@arm.com, codewiz2280@gmail.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , CodeWiz2280 , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Julien, On 2020-06-09 18:32, Julien Grall wrote: > (+ Marc) > > On 09/06/2020 18:03, Bertrand Marquis wrote: >> Hi >> >>> On 9 Jun 2020, at 16:47, Julien Grall wrote: >>> >>> >>> >>> On 09/06/2020 16:28, Bertrand Marquis wrote: >>>> Hi, >>>>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >>>>> >>>>> There does appear to be a secondary (CIC) controller that can >>>>> forward >>>>> events to the GIC-400 and EDMA controllers for the keystone 2 >>>>> family. >>>>> Admittedly, i'm not sure how it is being used with regards to the >>>>> peripherals. I only see mention of the GIC-400 parent for the >>>>> devices >>>>> in the device tree. Maybe Bertrand has a better idea on whether >>>>> any >>>>> peripherals go through the CIC first? I see that gic_interrupt () >>>>> fires once in Xen, which calls doIRQ to push out the virtual >>>>> interrupt >>>>> to the dom0 kernel. The dom0 kernel then handles the interrupt and >>>>> returns, but gic_interrupt() never fires again in Xen. >>>> I do not remember of any CIC but the behaviour definitely look like >>>> an interrupt acknowledge problem. >>>> Could you try the following: >>>> --- a/xen/arch/arm/gic-v2.c >>>> +++ b/xen/arch/arm/gic-v2.c >>>> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc >>>> *desc) >>>> /* Lower the priority of the IRQ */ >>>> gicv2_eoi_irq(desc); >>>> /* Deactivation happens in maintenance interrupt / via GICV */ >>>> + >>>> + /* Test for Keystone2 */ >>>> + gicv2_dir_irq(desc); >>>> } >>>> I think the problem I had was related to the vgic not deactivating >>>> properly the interrupt. >>> >>> Are you suggesting the guest EOI is not properly forwarded to the >>> hardware when LR.HW is set? If so, this could possibly be workaround >>> in Xen by raising a maintenance interrupt every time a guest EOI an >>> interrupt. >> >> Agree the maintenance interrupt would definitely be the right solution > I would like to make sure we aren't missing anything in Xen first. > From what you said, you have encountered this issue in the past with a > different hypervisor. So it doesn't look like to be Xen related. > > Was there any official statement from TI? If not, can we try to get > some input from them first? > > @Marc, I know you dropped 32-bit support in KVM recently :). Although, Yes! Victory is mine! Freedom from the shackles of 32bit, at last! :D > I was wondering if you heard about any potential issue with guest EOI > not forwarded to the host. This is on TI Keystone (Cortex A-15). Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway all run just fine with guest EOI), and GIC-400 is a pretty solid piece of kit (it is just sloooooow...). Thinking of it, you would see something like that if the GIC was seeing the writes coming from the guest as secure instead of NS (cue the early firmware on XGene that exposed the wrong side of GIC-400). Is there some kind of funky bridge between the CPU and the GIC? M. -- Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Tue Jun 09 18:39:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 18:39:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jij9V-0006NK-JZ; Tue, 09 Jun 2020 18:39:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jij9U-0006Mu-At for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 18:39:12 +0000 X-Inumbo-ID: 7ec7d00e-aa80-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7ec7d00e-aa80-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 18:39:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RfW4Om0O1yIKd2c2i1VRaRAwFoNIP8Y+ckBU5BhNm4Q=; b=PVvTD/7lx/UcRrh5/bHsbg6+i f5WYZr5frov5fw7U4uOwi2eDQB8a3RJzTS55rdSRr3TnjCfLSfOBxHPNh3ZnQ27lRUcCg1Mh0sp+7 MNyiRNMpzeoxEAECVwU9kEV6x0KoG00rmljFLov0guUlE3ue9SAFJwUTvHX3jgDVmrTko=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jij9M-0006KV-LU; Tue, 09 Jun 2020 18:39:04 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jij9M-0006Ai-5s; Tue, 09 Jun 2020 18:39:04 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jij9M-0000iv-54; Tue, 09 Jun 2020 18:39:04 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 150941: regressions - FAIL X-Osstest-Failures: xen-4.10-testing:build-arm64:xen-build:fail:regression xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386:xen-build:fail:regression xen-4.10-testing:build-i386-xsm:xen-build:fail:regression xen-4.10-testing:build-arm64-xsm:xen-build:fail:regression xen-4.10-testing:build-amd64:xen-build:fail:regression xen-4.10-testing:build-amd64-xsm:xen-build:fail:regression xen-4.10-testing:build-armhf:xen-build:fail:regression xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-pvhv2-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-pvhv2-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.10-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.10-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=a1a9b055a349748083665e42843f75d6db2c6a7b X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Tue, 09 Jun 2020 18:39:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150941 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150941/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-build fail REGR. vs. 150039 build-i386-prev 6 xen-build fail REGR. vs. 150039 build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386 6 xen-build fail REGR. vs. 150039 build-i386-xsm 6 xen-build fail REGR. vs. 150039 build-arm64-xsm 6 xen-build fail REGR. vs. 150039 build-amd64 6 xen-build fail REGR. vs. 150039 build-amd64-xsm 6 xen-build fail REGR. vs. 150039 build-armhf 6 xen-build fail REGR. vs. 150039 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a version targeted for testing: xen a1a9b055a349748083665e42843f75d6db2c6a7b baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 35 days Testing same since 150941 2020-06-09 17:05:34 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit a1a9b055a349748083665e42843f75d6db2c6a7b Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit afca67fafde22033b9a967ae197a10af5c654f02 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 09 18:43:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 18:43:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jijD9-000793-8r; Tue, 09 Jun 2020 18:42:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jijD8-00078h-GK for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 18:42:58 +0000 X-Inumbo-ID: 05d64ab2-aa81-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 05d64ab2-aa81-11ea-8496-bc764e2007e4; Tue, 09 Jun 2020 18:42:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6NvnPvBctqD/At0VIcPCmO7TylZtHCYyW44eFgXA42g=; b=nDjnXShqVPxEfcqUmPqzLApce w8VPRm7DiTME2mXFA1mSHbNyYW8mj42KTtt2ildkQwv5sZ8/WWz2TyB15AzUIlay9pGkdSw7urgUJ 2ffua+oyJyjsCHlYuQyqYBHcYzVIU7S1yuvawprLiVu1SNzu7xD3nLBwwZGxMmILLztwU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jijD1-0006Pc-0V; Tue, 09 Jun 2020 18:42:51 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jijD0-0006Hp-Gr; Tue, 09 Jun 2020 18:42:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jijD0-0003g7-GI; Tue, 09 Jun 2020 18:42:50 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 150942: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-arm64:xen-build:fail:regression xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-armhf:xen-build:fail:regression xen-4.11-testing:build-i386-xsm:xen-build:fail:regression xen-4.11-testing:build-i386:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:build-amd64-xsm:xen-build:fail:regression xen-4.11-testing:build-arm64-xsm:xen-build:fail:regression xen-4.11-testing:build-amd64:xen-build:fail:regression xen-4.11-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvhv2-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.11-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvshim:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvhv2-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.11-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Tue, 09 Jun 2020 18:42:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150942 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150942/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-build fail REGR. vs. 150040 build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-armhf 6 xen-build fail REGR. vs. 150040 build-i386-xsm 6 xen-build fail REGR. vs. 150040 build-i386 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 build-amd64-xsm 6 xen-build fail REGR. vs. 150040 build-arm64-xsm 6 xen-build fail REGR. vs. 150040 build-amd64 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a version targeted for testing: xen b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 35 days Testing same since 150942 2020-06-09 17:05:43 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-xl-pvshim blocked test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 09 18:45:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 18:45:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jijFW-0007Id-MU; Tue, 09 Jun 2020 18:45:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jijFV-0007IY-SE for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 18:45:25 +0000 X-Inumbo-ID: 609c401e-aa81-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 609c401e-aa81-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 18:45:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aAQAF6I+PfMoIG/TDTJ94ttXKZJBiYztJ2fBxUQsV+E=; b=SVQfxhpajjpSMouH+LPc9cII0 gmllqqIdqnxHY0QxhgZTeut2rl1IoPP45OF82T4eYUofV7e2sPLsOMFbLTit57gvFY3IOFUeDdE76 hOkzHxryCFLRrle6dNI/JGaoV8ERMo4Fpd9oxVc0bPmNT6nIceIB5Zo9uLEtOw0DTNo8Y=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jijFT-0006So-2E; Tue, 09 Jun 2020 18:45:23 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jijFS-0006Nu-ND; Tue, 09 Jun 2020 18:45:22 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jijFS-0004QX-MY; Tue, 09 Jun 2020 18:45:22 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 150940: regressions - FAIL X-Osstest-Failures: xen-4.9-testing:build-arm64:xen-build:fail:regression xen-4.9-testing:build-arm64-xsm:xen-build:fail:regression xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-armhf:xen-build:fail:regression xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=ad0c1a0023077ee03d325a6f84bb654150539f49 X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Tue, 09 Jun 2020 18:45:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150940 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150940/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-build fail REGR. vs. 150120 build-arm64-xsm 6 xen-build fail REGR. vs. 150120 build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-armhf 6 xen-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a version targeted for testing: xen ad0c1a0023077ee03d325a6f84bb654150539f49 baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 30 days Testing same since 150940 2020-06-09 17:05:20 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 09 18:58:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 18:58:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jijS3-0008LA-2C; Tue, 09 Jun 2020 18:58:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jijS1-0008L5-Vu for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 18:58:22 +0000 X-Inumbo-ID: 2ff843ca-aa83-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2ff843ca-aa83-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 18:58:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=B47nYpNcMzCRhxK+KqnKoMl6IrdhC+vlqJV5qKOsg60=; b=S9T6CDWXY3yVZxuvWBwrnFeyo k2nnSEINF87UGkC/S/XK4uJPUyK3KIGj8iEWtMW9VFBcxa4H+Ekw1FzFqufxXvWmp2EnLHja5yZEf ZhQsA6WyLg8BSNudKKIfFmnbRb2CVPUuSfBm2S0R6iXsOtggTH/Ll+zaWeWUJw++gxFrs=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jijS0-0006iu-Ua; Tue, 09 Jun 2020 18:58:20 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jijS0-0006qI-I1; Tue, 09 Jun 2020 18:58:20 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jijS0-0003Vj-HP; Tue, 09 Jun 2020 18:58:20 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150939: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=058023b343d4e366864831db46e9b438e9e3a178 X-Osstest-Versions-That: xen=1a58d8dab52f241d52fec1d992d859b9632c4739 From: osstest service owner Date: Tue, 09 Jun 2020 18:58:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150939 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150939/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 058023b343d4e366864831db46e9b438e9e3a178 baseline version: xen 1a58d8dab52f241d52fec1d992d859b9632c4739 Last test of basis 150936 2020-06-09 14:01:56 Z 0 days Testing same since 150939 2020-06-09 17:00:49 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Juergen Gross Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 1a58d8dab5..058023b343 058023b343d4e366864831db46e9b438e9e3a178 -> smoke From xen-devel-bounces@lists.xenproject.org Tue Jun 09 19:41:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 19:41:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jik7i-00042F-IQ; Tue, 09 Jun 2020 19:41:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jik7i-00041r-5f for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 19:41:26 +0000 X-Inumbo-ID: 2ce8f232-aa89-11ea-b366-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2ce8f232-aa89-11ea-b366-12813bfff9fa; Tue, 09 Jun 2020 19:41:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=H2EWSeUVtYpD7rnuRsqv9rPD5FV+7PI9JUOzQdcODTI=; b=0pz+LyDWJx+HrcZCRtI4zsNFf GM2r5NaHwI01g5q2EhbSMb4NtQXuHkS+dCWttitsXvweGxZ0bQ+k7XLciWTJmUpT0q3sxKfk8ezRh o9COqSzbFPCZt176cG2P5JsVY8RYnQkxXc5/7e5NBgfMUOkanFoaCaBwYRH2EVCX6EEmc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jik7U-0007bl-9j; Tue, 09 Jun 2020 19:41:12 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jik7T-0008Mz-ML; Tue, 09 Jun 2020 19:41:11 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jik7T-0002fQ-Lc; Tue, 09 Jun 2020 19:41:11 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150933: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-rtds:guest-start:fail:allowable xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 X-Osstest-Versions-That: xen=51ca66c37371b10b378513af126646de22eddb17 From: osstest service owner Date: Tue, 09 Jun 2020 19:41:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150933 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150933/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 150918 Tests which did not succeed, but are not blocking: test-amd64-amd64-examine 4 memdisk-try-append fail like 150876 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150900 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150918 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150918 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150918 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150918 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150918 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150918 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150918 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150918 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150918 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 baseline version: xen 51ca66c37371b10b378513af126646de22eddb17 Last test of basis 150918 2020-06-08 01:51:14 Z 1 days Failing since 150928 2020-06-08 16:37:10 Z 1 days 2 attempts Testing same since 150933 2020-06-09 06:48:33 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper George Dunlap Ian Jackson Jan Beulich Julien Grall Nick Rosbrook Roger Pau Monné jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 51ca66c373..835d8d69d9 835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 -> master From xen-devel-bounces@lists.xenproject.org Tue Jun 09 20:07:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 20:07:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jikXG-00069T-Au; Tue, 09 Jun 2020 20:07:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jikXF-00069O-0q for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 20:07:49 +0000 X-Inumbo-ID: e3801d56-aa8c-11ea-b7bb-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e3801d56-aa8c-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 20:07:48 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id o15so23776404ejm.12 for ; Tue, 09 Jun 2020 13:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pVS7CJZdrzKQpjKHvnhdrW3lpWKuWLbs7rJKMQLQFRQ=; b=OUdtlwDyE0cfNAIl0rDUkNvytJg/OQrKdLLD7Z2jWymOUSk0i4qsBtlBhnZ71NGirF giH3plDhqPChm7JCoW8oSrwm5ED9WmOtmztjyztwwxYveXPyvOoDfhmvKvs4zI8NdsDQ +4qBtA3ZRtUp/qCl9LVj2mDk/lwEuZZhAOMREMWreQT0112b7XMMnWFcT+tXF75SF9SN KGOJmSFNT1PyqhGonBlQiaLkP+qqZVXe1TMY/3/fiqm+FYHhhalF8fLGW/8eNNzGz1y9 mnBs7OwbkLLWo1zpYuyYFqSEA+AXTGeQWU/j++U1fsTYc1S0WUUxMXux22PbXcqqQsHF xc0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pVS7CJZdrzKQpjKHvnhdrW3lpWKuWLbs7rJKMQLQFRQ=; b=ii6rkKSXGn2SZ2Le96ARkJE39BCv8HPM9I7bp4rUM0iV85bMtaMOpb540AVtloFUrE HE5O0CV+yvTzUB+8M652H29thwCTMZx/CuTcdDdo56pjHnztQm+g3igrgeGKmx06pk6/ jYrO0uEczt4mKUQFiCQ3pxBBOPA9lY5BDjXxHKuNyHIsFsEep0sSKuHopR7caQpgO2jJ Z9h3mX62A0FCaS+ttWEr6sGMTdnZLLde5HF0bWeceTz4msaFxIBkQHQG4U3p3bFaqV2w K4V/aAN7R7KXNS2ODxWRuzL7CLOqcnaar7lEjYUp8k6BimfrRmvSn7+PVZsJZJ6BE78e E/gg== X-Gm-Message-State: AOAM531sRreyYGFAonz6a7YzSPtch07DUc+bJg2Aa9obij073cQpDOaR YTRUzF9z32Kihxjo9rr7q4MaTRZXhGjO8gDL2f4= X-Google-Smtp-Source: ABdhPJwH9uZq6vL6HezbBh1qqaSTqsqpAL7lVzwPfgHt7nHynJ5DNE70GoEi9w/t31df1C0PlKtpaLHnawrWnDDc548= X-Received: by 2002:a17:906:5f93:: with SMTP id a19mr111426eju.10.1591733267244; Tue, 09 Jun 2020 13:07:47 -0700 (PDT) MIME-Version: 1.0 References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> In-Reply-To: <6033f9cecbf10f50f4a713ce52105426@kernel.org> From: CodeWiz2280 Date: Tue, 9 Jun 2020 16:07:33 -0400 Message-ID: Subject: Re: Keystone Issue To: Marc Zyngier Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 9, 2020 at 1:45 PM Marc Zyngier wrote: > > Hi Julien, > > On 2020-06-09 18:32, Julien Grall wrote: > > (+ Marc) > > > > On 09/06/2020 18:03, Bertrand Marquis wrote: > >> Hi > >> > >>> On 9 Jun 2020, at 16:47, Julien Grall wrote: > >>> > >>> > >>> > >>> On 09/06/2020 16:28, Bertrand Marquis wrote: > >>>> Hi, > >>>>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: > >>>>> > >>>>> There does appear to be a secondary (CIC) controller that can > >>>>> forward > >>>>> events to the GIC-400 and EDMA controllers for the keystone 2 > >>>>> family. > >>>>> Admittedly, i'm not sure how it is being used with regards to the > >>>>> peripherals. I only see mention of the GIC-400 parent for the > >>>>> devices > >>>>> in the device tree. Maybe Bertrand has a better idea on whether > >>>>> any > >>>>> peripherals go through the CIC first? I see that gic_interrupt () > >>>>> fires once in Xen, which calls doIRQ to push out the virtual > >>>>> interrupt > >>>>> to the dom0 kernel. The dom0 kernel then handles the interrupt and > >>>>> returns, but gic_interrupt() never fires again in Xen. > >>>> I do not remember of any CIC but the behaviour definitely look like > >>>> an interrupt acknowledge problem. > >>>> Could you try the following: > >>>> --- a/xen/arch/arm/gic-v2.c > >>>> +++ b/xen/arch/arm/gic-v2.c > >>>> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc > >>>> *desc) > >>>> /* Lower the priority of the IRQ */ > >>>> gicv2_eoi_irq(desc); > >>>> /* Deactivation happens in maintenance interrupt / via GICV */ > >>>> + > >>>> + /* Test for Keystone2 */ > >>>> + gicv2_dir_irq(desc); > >>>> } > >>>> I think the problem I had was related to the vgic not deactivating > >>>> properly the interrupt. > >>> > >>> Are you suggesting the guest EOI is not properly forwarded to the > >>> hardware when LR.HW is set? If so, this could possibly be workaround > >>> in Xen by raising a maintenance interrupt every time a guest EOI an > >>> interrupt. > >> > >> Agree the maintenance interrupt would definitely be the right solution > > I would like to make sure we aren't missing anything in Xen first. > > From what you said, you have encountered this issue in the past with a > > different hypervisor. So it doesn't look like to be Xen related. > > > > Was there any official statement from TI? If not, can we try to get > > some input from them first? Thank you all for your support so far, its really appreciated. Is there a quick patch that I can try with this maintenance interrupt to get the level interrupts working as well? I can pose the question to TI but would like to close the loop and make sure there are no other issues that pop out first. > > > > @Marc, I know you dropped 32-bit support in KVM recently :). Although, > > Yes! Victory is mine! Freedom from the shackles of 32bit, at last! :D > > > I was wondering if you heard about any potential issue with guest EOI > > not forwarded to the host. This is on TI Keystone (Cortex A-15). > > Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway > all run just fine with guest EOI), and GIC-400 is a pretty solid piece > of kit (it is just sloooooow...). > > Thinking of it, you would see something like that if the GIC was seeing > the writes coming from the guest as secure instead of NS (cue the early > firmware on XGene that exposed the wrong side of GIC-400). > > Is there some kind of funky bridge between the CPU and the GIC? > > M. > -- > Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Tue Jun 09 20:58:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 20:58:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilKN-00024v-MV; Tue, 09 Jun 2020 20:58:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilKN-00024q-3u for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 20:58:35 +0000 X-Inumbo-ID: fa2050e2-aa93-11ea-b370-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fa2050e2-aa93-11ea-b370-12813bfff9fa; Tue, 09 Jun 2020 20:58:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=II2opKNz0Fytzq3lAc9ZssxrJiG/3ls6B/0SRHjMZE4=; b=OuzQtZRxy4n6VhRD3F+atiEnb ZfgXiq4mK/zRg+dQFYgz5dFg/x+wVs2r70z4mEoiKMVHlHsTYMaw2i0xByfuv3CIkUBOxHMbiGGLe 2JPUD46RVj7MgMG+nJI7u+r5UEp5fq2SBQk4+bO0Jlyj1YswIprfq9bL+kF3MSiy98zPg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilKJ-0000r6-Py; Tue, 09 Jun 2020 20:58:31 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jilKJ-0002Es-7P; Tue, 09 Jun 2020 20:58:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jilKJ-0006CX-6k; Tue, 09 Jun 2020 20:58:31 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 150951: regressions - FAIL X-Osstest-Failures: xen-4.9-testing:build-arm64:xen-build:fail:regression xen-4.9-testing:build-arm64-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-armhf:xen-build:fail:regression xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.9-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=ad0c1a0023077ee03d325a6f84bb654150539f49 X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Tue, 09 Jun 2020 20:58:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150951 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150951/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-build fail REGR. vs. 150120 build-arm64-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-armhf 6 xen-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a version targeted for testing: xen ad0c1a0023077ee03d325a6f84bb654150539f49 baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 30 days Testing same since 150940 2020-06-09 17:05:20 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 09 21:14:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 21:14:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilZP-0003kJ-43; Tue, 09 Jun 2020 21:14:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilZO-0003kE-Cs for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 21:14:06 +0000 X-Inumbo-ID: 24cb3a94-aa96-11ea-b377-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 24cb3a94-aa96-11ea-b377-12813bfff9fa; Tue, 09 Jun 2020 21:14:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oPX3B9xdO/A6WaLag/FBzBXPXSnUwGHc7x+YQXUJ/xo=; b=NECbwOeFBq9zqUk+oDfbQRxCX 7BXRPJzyN4vWgDTBRNNBguQ0EEAG5rZg7D/3smGMjyc6NxTE1Lg137s1EAXAisINvAoAyZUcC2gNW NfnHdp9Dbw45MdPVCpogjJ1sh0kFfGVGyjtmepp2jhrzIbNlOk5DHj+jnQrlvWPMPVPjo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilZK-0001C0-I3; Tue, 09 Jun 2020 21:14:02 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jilZK-0002ir-2D; Tue, 09 Jun 2020 21:14:02 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jilZK-0001e2-1O; Tue, 09 Jun 2020 21:14:02 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 150952: regressions - FAIL X-Osstest-Failures: xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386:xen-build:fail:regression xen-4.10-testing:build-arm64-xsm:xen-build:fail:regression xen-4.10-testing:build-arm64:xen-build:fail:regression xen-4.10-testing:build-amd64:xen-build:fail:regression xen-4.10-testing:build-amd64-xsm:xen-build:fail:regression xen-4.10-testing:build-i386-xsm:xen-build:fail:regression xen-4.10-testing:build-armhf:xen-build:fail:regression xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.10-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.10-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-pvhv2-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-pvhv2-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.10-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=a1a9b055a349748083665e42843f75d6db2c6a7b X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Tue, 09 Jun 2020 21:14:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150952 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150952/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150039 build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386 6 xen-build fail REGR. vs. 150039 build-arm64-xsm 6 xen-build fail REGR. vs. 150039 build-arm64 6 xen-build fail REGR. vs. 150039 build-amd64 6 xen-build fail REGR. vs. 150039 build-amd64-xsm 6 xen-build fail REGR. vs. 150039 build-i386-xsm 6 xen-build fail REGR. vs. 150039 build-armhf 6 xen-build fail REGR. vs. 150039 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a version targeted for testing: xen a1a9b055a349748083665e42843f75d6db2c6a7b baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 35 days Testing same since 150941 2020-06-09 17:05:34 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit a1a9b055a349748083665e42843f75d6db2c6a7b Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit afca67fafde22033b9a967ae197a10af5c654f02 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 09 21:22:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 21:22:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilh5-0004eA-4i; Tue, 09 Jun 2020 21:22:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilh3-0004dg-Lo for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 21:22:01 +0000 X-Inumbo-ID: 3d28f78a-aa97-11ea-b377-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3d28f78a-aa97-11ea-b377-12813bfff9fa; Tue, 09 Jun 2020 21:21:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=q0Bi1JONkNjSmwbKRyn6adAYheRY3RT3g9svKAcdL78=; b=FMDsX8dnpXsvYZzf4H0ssrDa4 AQc8rOON/fJl4b52+Oz5r323K/SS3oYglxEVcd59iC9NH/jrjkue/PGXvquFBQ14nUe67ynZ1w9y7 sT+XarCcWmehcITC7M8ipkZHHfU799BiaeE9bpK3/aRUlAwDYQroGlTPlYRmz5giXb7f4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilgw-0001MV-FF; Tue, 09 Jun 2020 21:21:54 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jilgv-00031c-OJ; Tue, 09 Jun 2020 21:21:53 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jilgv-0004JU-Nf; Tue, 09 Jun 2020 21:21:53 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 150953: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-arm64:xen-build:fail:regression xen-4.11-testing:build-armhf:xen-build:fail:regression xen-4.11-testing:build-i386:xen-build:fail:regression xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:build-amd64-xsm:xen-build:fail:regression xen-4.11-testing:build-arm64-xsm:xen-build:fail:regression xen-4.11-testing:build-i386-xsm:xen-build:fail:regression xen-4.11-testing:build-amd64:xen-build:fail:regression xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvshim:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.11-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.11-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvhv2-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvhv2-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.11-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Tue, 09 Jun 2020 21:21:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150953 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150953/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-build fail REGR. vs. 150040 build-armhf 6 xen-build fail REGR. vs. 150040 build-i386 6 xen-build fail REGR. vs. 150040 build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 build-amd64-xsm 6 xen-build fail REGR. vs. 150040 build-arm64-xsm 6 xen-build fail REGR. vs. 150040 build-i386-xsm 6 xen-build fail REGR. vs. 150040 build-amd64 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a version targeted for testing: xen b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 35 days Testing same since 150942 2020-06-09 17:05:43 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-xl-pvshim blocked test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 09 21:24:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 21:24:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiljL-0004nk-IW; Tue, 09 Jun 2020 21:24:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiljK-0004nO-H0 for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 21:24:22 +0000 X-Inumbo-ID: 92d11e4a-aa97-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 92d11e4a-aa97-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 21:24:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3JymUrzmX4cRoutP1yS1bTp7c5z2hLlkHLTJntb9do8=; b=ghk1yL+gIDfOhhZzzm2YLXFUP AjQ7e5ZzZuIJk0/fEDioBs7wLfPXVr9TfvKG69ox76cCvwCwNdXNpgRLI1EpC4rHEU0VrYSDs8hZt kt/Cyy8UMk3p55szxn7RbSiLslXNPdwuxpj6/orSAzlxTu1Gl9Eijz52UUh01LQlsBG7Q=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiljE-0001Os-F5; Tue, 09 Jun 2020 21:24:16 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiljD-00037R-SW; Tue, 09 Jun 2020 21:24:16 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiljD-0006DS-Rq; Tue, 09 Jun 2020 21:24:15 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150946: tolerable trouble: pass/starved - PUSHED X-Osstest-Failures: ovmf:test-amd64-amd64-xl-qemuu-ovmf-amd64:hosts-allocate:starved:nonblocking ovmf:test-amd64-i386-xl-qemuu-ovmf-amd64:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: ovmf=6aa48ab791ecc4fe22d110222bd7b566bc8a2274 X-Osstest-Versions-That: ovmf=6ff7c838d09224dd4e4c9b5b93152d8db1b19740 From: osstest service owner Date: Tue, 09 Jun 2020 21:24:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150946 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150946/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 2 hosts-allocate starved n/a test-amd64-i386-xl-qemuu-ovmf-amd64 2 hosts-allocate starved n/a version targeted for testing: ovmf 6aa48ab791ecc4fe22d110222bd7b566bc8a2274 baseline version: ovmf 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 Last test of basis 150917 2020-06-08 01:40:21 Z 1 days Testing same since 150946 2020-06-09 18:43:44 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel Laszlo Ersek jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 starved test-amd64-i386-xl-qemuu-ovmf-amd64 starved ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 6ff7c838d0..6aa48ab791 6aa48ab791ecc4fe22d110222bd7b566bc8a2274 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Tue Jun 09 21:28:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 21:28:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilnQ-00050c-7Q; Tue, 09 Jun 2020 21:28:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilnO-00050X-PG for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 21:28:34 +0000 X-Inumbo-ID: 2afb8e4e-aa98-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2afb8e4e-aa98-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 21:28:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=c0QE2h7otWjbjfSGz51mFLitMlrPmgCmo2cMZwties4=; b=M8zYli4xqpmA4hQlZYb3odQh9 t9+1AD61l6ikGFDA11g8DV+zCUrdzbIPhpPeUTCtbtSTRg92Z4dTDQrzGN/KKn0StgdE8LNVbMQWb 9VJ41XE4xiLJZVROfx95tK/MveGur4m7SWc3dR/jGfRZFevSwY9NFf3jy6CTVyqFgaQMI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jilnL-0001Uf-SL; Tue, 09 Jun 2020 21:28:31 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jilnL-0003It-KG; Tue, 09 Jun 2020 21:28:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jilnL-0000OM-Jg; Tue, 09 Jun 2020 21:28:31 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 150950: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=6a49b9a7920c82015381740905582b666160d955 X-Osstest-Versions-That: xen=058023b343d4e366864831db46e9b438e9e3a178 From: osstest service owner Date: Tue, 09 Jun 2020 21:28:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150950 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/150950/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 6a49b9a7920c82015381740905582b666160d955 baseline version: xen 058023b343d4e366864831db46e9b438e9e3a178 Last test of basis 150939 2020-06-09 17:00:49 Z 0 days Testing same since 150950 2020-06-09 19:00:58 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 058023b343..6a49b9a792 6a49b9a7920c82015381740905582b666160d955 -> smoke From xen-devel-bounces@lists.xenproject.org Tue Jun 09 21:50:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 21:50:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jim8w-0007Sg-7n; Tue, 09 Jun 2020 21:50:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jim8v-0007Sb-6n for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 21:50:49 +0000 X-Inumbo-ID: 4774ddd4-aa9b-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4774ddd4-aa9b-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 21:50:48 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AA98B206D5; Tue, 9 Jun 2020 21:50:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591739448; bh=n8q6RBqf99l7e7L1EOCdjDHHs3POGMUOsceVpb6TqsY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lVBxOO94oJCocVzgGYmxBV/gu6l2FaYei13cIzYMryQHWhbZi9YaLr7cUz1MLaG/w 0bRbjImP1w5xBQtTIIuvOMS2PPZMzHArb4ACkNEFsb07qxEhJdHgvYjszfQY3Gfyp9 iAYY4qIeIYOHSZ7he94+zdY72e7wCdtwCk17qwBM= Date: Tue, 9 Jun 2020 14:50:46 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Christoph Hellwig Subject: Re: [PATCH v2 08/11] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations In-Reply-To: <20200609053240.GA3015@infradead.org> Message-ID: References: <20200603222247.11681-8-sstabellini@kernel.org> <20200608070850.GD15742@infradead.org> <20200609053240.GA3015@infradead.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Stefano Stabellini , konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 8 Jun 2020, Christoph Hellwig wrote: > On Mon, Jun 08, 2020 at 04:06:57PM -0700, Stefano Stabellini wrote: > > I understand what you are suggesting about having something like: > > > > xen_phys_to_dma(...) > > { > > phys_addr_t phys = xen_phys_to_bus(dev, paddr) > > return phys_to_dma(phys); > > } > > > > I thought about it myself. I'll do it. > > "something", yes. Except that I think the bus is a little confusing, > isn't it? What is the Xen term for these addresses? Xen reasons in terms of frame numbers. Xen calls them "dfn" for device frame number. They were supposed to be called "bfn" but eventually they settled for a different name when the series was committed. I could s/bfn/dfn/g to match the terminology, if that helps. > Also we probably don't need the extra local variable. Sure > > But I don't think I understood the comment about XEN_PFN_PHYS. > > There is a comment above xen_phys_to_bus that it avoids using > XEN_PFN_PHYS because XEN_PFN_PHYS of the phys_addr_t vs dma_addr_t > mismatch. But XEN_PFN_PHYS could just use a u64 instead of the > phys_addr_t and then we could use it. Especially as XEN_PFN_PHYS > isn't actually used anywhere except in swiotlb-xen.c. Or we could > remove XEN_PFN_PHYS enirely, as it isn't all that useful to start > with. I'll remove it. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 21:50:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 21:50:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jim94-0007T0-Fu; Tue, 09 Jun 2020 21:50:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jim93-0007Sv-2D for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 21:50:57 +0000 X-Inumbo-ID: 4c410ebe-aa9b-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4c410ebe-aa9b-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 21:50:56 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CA7DA206D5; Tue, 9 Jun 2020 21:50:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591739456; bh=XTv0AfIhSGBAVmR///EPvXgZuQrSzUx+9M9fNndpuWk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FYWiwtT8vtIEdZWsACy6EuABQDJ0EERJh8aI4qNJOssQy+ay6qAz2Fpj54hAfTRYk Pqi/iPfoRC8DmBrdNc7Q9R2XGnptCIOoQyHTgvCUxRcDfsz2ZOHMHOmtRMmZehUJLU tRk1KzKwczMBaTpRMv5gKpCGKc9zkgacd3vmwPxo= Date: Tue, 9 Jun 2020 14:50:55 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Christoph Hellwig Subject: Re: [PATCH v2 10/11] xen/arm: introduce phys/dma translations in xen_dma_sync_for_* In-Reply-To: <20200609053949.GA26473@infradead.org> Message-ID: References: <20200603222247.11681-10-sstabellini@kernel.org> <20200608071221.GF15742@infradead.org> <20200609053802.GB3015@infradead.org> <20200609053949.GA26473@infradead.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Stefano Stabellini , konrad.wilk@oracle.com, roman@zededa.com, linux-kernel@vger.kernel.org, tamas@tklengyel.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 8 Jun 2020, Christoph Hellwig wrote: > On Mon, Jun 08, 2020 at 10:38:02PM -0700, Christoph Hellwig wrote: > > On Mon, Jun 08, 2020 at 05:38:28PM -0700, Stefano Stabellini wrote: > > > Yeah, the pfn_valid check is a bit weird by definition because we are > > > using it to understand whether the address belong to us or to another > > > VM. To do the pfn_valid check we need to translate the dma address into > > > something the CPU understands, hence, the dma_to_phys call. > > > > > > Why can't we use the already-provided paddr? Because paddr has been > > > translated twice: > > > 1) from dma to maybe-foreign phys address (could be ours, or another VM) > > > 2) from maybe-foreign address to local (using our local mapping of the foreign page) > > > > > > In fact, it would be clearer if we had all three addresses as parameters > > > of xen_dma_sync_for_cpu: the dma address, the maybe-foreign physical > > > address (we tend to call it xenbus address, baddr), the local physical > > > address. Something like: > > > > I think instead we should move the arch_sync_dma_for_{device,cpu} > > calls from xen_dma_sync_for_{device,cpu} into the callers, as they > > are provided by the generic dma-noncoherent.h and optimized out for > > coherent architectures like x86. Then the swiotlb-xen.c code only > > need to call dma_cache_maint as the interface (which would have to > > grow a better name), which should then only need a single kind of > > address. > > ... actually I'd keep the xen_dma_sync_for_{device,cpu} names for the > low-level interface, just move the arch_sync_dma_for_{device,cpu} > calls up. I can do that. From xen-devel-bounces@lists.xenproject.org Tue Jun 09 23:44:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 23:44:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jinum-00006I-Vc; Tue, 09 Jun 2020 23:44:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jinum-00006D-3G for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 23:44:20 +0000 X-Inumbo-ID: 21cb70e2-aaab-11ea-b38e-12813bfff9fa Received: from mga06.intel.com (unknown [134.134.136.31]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 21cb70e2-aaab-11ea-b38e-12813bfff9fa; Tue, 09 Jun 2020 23:44:17 +0000 (UTC) IronPort-SDR: LpJ7hP/xoCKV2NGAge4asPl9UQOTEwnU9b9Pn8wJ8/LYddkEjrdEdBy7wHCq6B29wgCcXvzCqI 9Mb3NSfWAAjQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2020 16:44:16 -0700 IronPort-SDR: NAqZMuAphuXrPphGqtZtzlmnn1jZmDvqPFbKeFVogm84whrmnM6/zZLIfiEnIcRWEiY6j4RXyM ob8lEvPg0TjA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,493,1583222400"; d="scan'208";a="379893976" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga001.fm.intel.com with ESMTP; 09 Jun 2020 16:44:15 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 9 Jun 2020 16:44:15 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 9 Jun 2020 16:44:15 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 9 Jun 2020 16:44:15 -0700 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.177) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 9 Jun 2020 16:44:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KkCvmGe8EmONwuk4VxoN/0NEd9YhUPwZoKye7LWardL9RVJEufJoRGqxFrUhI0vaIrz0PvuH/ZZNZSqHlCGtO/iYmdMYFPwOM7FkjQIX81NqMjQehTPkrMbtSUc6/1k38K2deMR0SrpD/TfxV0RH/NteDKPghGUyu8pnwA5uWBk1RhhVsdZY3egpitKEkfB6tklAS/Gko1TzK51g9xKskUxr8V8ZbJv1iAbFwo+gk8RyudaQCF8v2sHP1j+Bnmb0VjV2WIfhiSI0Sp0nULs95ZV0VkkmAZuTqx7tFYIaGjeKu6R8DLxQIE6hUngmJ752JsvtYymQxAaWdREHP9pFig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fCMqnr7vTPBQE6HhvnPxSab0RucED1HLkIWc5y3pDhc=; b=IIk2qHmyOJzf8c3L5UFNHZ1DH+9eprkL6P9kyhtdxQmzR68bmnZTfWL6Bhm159DOKYOU5nrfGHhZn/dle9GGIWIxFenYPeL6XbeV/Z8aYx3Ocosx4lrL0oWOG6rjTxzZmzI+iLVx22iGSokn1nAaHxfblExumVJCt7HSTGwjXMadRSlNwja+Az8j13WKE65+1O64NOf2OINduAYKDfKSWQLAvbzCF3l1vWNZ8CQf2SYe9fnFHIkA6KTHeHAevABz9rLhR1tqxsKuqI0TC8epT2lzpHmGV2Zn1GwuqrGAIBdz1+xzIEpXjUlkYv3F6BiCHavmIR1aEkK1X8nqJ1P1Fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fCMqnr7vTPBQE6HhvnPxSab0RucED1HLkIWc5y3pDhc=; b=RthxdP2yijL1osXhyHpq/PrpBWHc0kmQkxuufRd8lEaXx5BhVZ8Cbyf7XbBw8uxf54HYTFiG0Lt/bTDc14c9ONVz3ma5swXUKtQWCUEicJnQSRWpwewfOjhBZ/1uYWux90+wJb3UWHC3YnijMC7jd7RCQAAqZCaEW/URZUxYQf8= Received: from MWHPR11MB1645.namprd11.prod.outlook.com (2603:10b6:301:b::12) by MWHPR11MB1774.namprd11.prod.outlook.com (2603:10b6:300:10a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.22; Tue, 9 Jun 2020 23:44:14 +0000 Received: from MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb]) by MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb%5]) with mapi id 15.20.3066.023; Tue, 9 Jun 2020 23:44:14 +0000 From: "Tian, Kevin" To: "Lengyel, Tamas" , "xen-devel@lists.xenproject.org" Subject: RE: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks Thread-Topic: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks Thread-Index: AQHWOBerUwuHg20nGUicDfuX+ypR+ajQ/TJw Date: Tue, 9 Jun 2020 23:44:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.55.52.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5d44fe2-c39a-4272-acd9-08d80ccf0422 x-ms-traffictypediagnostic: MWHPR11MB1774: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 042957ACD7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7osdBp6JkRa9iE3N46OA/qGUjzCdUZgrLikmGNRGX/e8wtQBAHWARzC3Fi7VF6lfsrv1vSbdly3HbG23AX9vRcAsR7VnEulBeGFUSFZSEPh8t5eKnrxFWwzqGVdgSLXMRo4RtdArkYI0C2Fd3LutSjfR4zd/1cuFa5r22a/J4pXBnVQAMJA4o799Pu9jDo+jMG3Ve5afox8m/PE+PA5mqaUs3QsZMXwLWyHqcyUr3RDp1jrUnzHcVvWiYEV/wDYm+4SDdx8sBk10tQK78kWYCyHN6oANS/PndsyOHUBm7cRGEJrdTRQFVszODqABiKtvNeMZwiR46JrKRb10BP6CKA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1645.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(366004)(346002)(39860400002)(136003)(396003)(8936002)(66556008)(26005)(64756008)(76116006)(55016002)(9686003)(4326008)(7696005)(86362001)(52536014)(66446008)(66946007)(186003)(33656002)(6506007)(8676002)(5660300002)(2906002)(66476007)(83380400001)(7416002)(110136005)(54906003)(316002)(478600001)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: LXrQonLWRzS5NbWUbLDZ3hoUbYwdIk6Al5k5MDSd2S8NwJry+h57G5diEXGZ8243f+jycNKzW24XyyVGveY3LLCm4VFZaQx3r+mIV3+Nyr8VwLi3jKWYlMXj4kzXs/0SxhH7CvrLz4PW0LXG7uC66mjqrm6b9uxMQ+CMZk1ktx7kSUVa55JJ0WdpFZk8QZEYuTZgXDGlyDNaR07F49xtoD8t2+J+D2X8EcZJxMEEW0pKkx6ZQn4ERDM37ZtrRsoJQTY3H+Qz83tdg55+KM6WUuuSFrbzZ8H3jpK1VGJtbCQVf4DQUw73/3GgryHY14AMpO69C5M2+cIw8b8Nvy5cKUaGspQD9j4X2rAJA7lk1pd1Wv4O8MfCHj2AnJfCcvsFsjWFbFSKXyR4eG+OW+hRaNiSpQFUfEsibWrmdhV9e9c+KIud3cJk0ldcETLkwgURm2sG89B8nTCQfpwOJcHgIon2HGPrAQMnFiVu6YFU24U= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c5d44fe2-c39a-4272-acd9-08d80ccf0422 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 23:44:13.8545 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vz7crzeNVH68wNuVr2sJkw5dN6h+fgrcOp5LeTyaU7stG/yscRRqOnZD1bmfmrfQgA1IvE61bQQNxXkqdUfczA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1774 X-OriginatorOrg: intel.com X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , "Nakajima, Jun" , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Tamas K Lengyel , Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiBGcm9tOiBMZW5neWVsLCBUYW1hcyA8dGFtYXMubGVuZ3llbEBpbnRlbC5jb20+DQo+IFNlbnQ6 IE1vbmRheSwgSnVuZSAxLCAyMDIwIDk6MjIgUE0NCj4gDQo+IFdoZW4gcnVubmluZyBWTSBmb3Jr cyB3aXRob3V0IGRldmljZSBtb2RlbHMgKFFFTVUpLCBpdCBtYXkNCj4gYmUgdW5kZXNpcmFibGUg Zm9yIFhlbiB0byBpbmplY3QgaW50ZXJydXB0cy4gV2hlbiBjcmVhdGluZyBzdWNoIGZvcmtzIGZy b20NCj4gV2luZG93cyBWTXMgd2UgaGF2ZSBvYnNlcnZlZCB0aGUga2VybmVsIHRyeWluZyB0byBw cm9jZXNzIGludGVycnVwdHMNCj4gaW1tZWRpYXRlbHkgYWZ0ZXIgdGhlIGZvcmsgaXMgZXhlY3V0 ZWQuIEhvd2V2ZXIgd2l0aG91dCBRRU1VIHJ1bm5pbmcgc3VjaA0KPiBpbnRlcnJ1cHQgaGFuZGxp bmcgbWF5IG5vdCBiZSBwb3NzaWJsZSBiZWNhdXNlIGl0IG1heSBhdHRlbXB0IHRvIGludGVyYWN0 DQo+IHdpdGgNCj4gZGV2aWNlcyB0aGF0IGFyZSBub3QgZW11bGF0ZWQgYnkgYSBiYWNrZW5kLiBJ biB0aGUgYmVzdCBjYXNlIHNjZW5hcmlvIHN1Y2gNCg0KSSBhc2tlZCB0aGlzIHF1ZXN0aW9uIGJl Zm9yZS4gdGhlIGludGVycnVwdHMgY291bGQgY29tZSBmcm9tIFhlbiBpdHNlbGYsIGUuZy4NCmR1 ZSB0byB0aW1lciB2aXJ0dWFsaXphdGlvbi4gU28gSSBkaWRuJ3QgZ2V0IHdoeSBpdCdzIGRlc2ly ZWQgdG8gYmxvY2sgYWxsIGludGVycnVwdHMNCmp1c3QgYmVjYXVzZSBubyBRRU1VIGlzIHJ1bm5p bmcuIEFsc28gaXQncyB3ZWlyZCB3aHkgV2luZG93cyBWTXMgYXJlDQpvYnNlcnZlZCB0byBwcm9j ZXNzIGludGVycnVwdHMgdGhhdCBhcmUgZ2VuZXJhdGVkIGJ5IFFFTVUgd2hlbiBubyBzdWNoDQpi YWNrZW5kIGVtdWxhdGlvbiBleGlzdHMgYXQgYWxsLiBJdCBzb3VuZHMgbGlrZSBhIHdvcmthcm91 bmQgaW5zdGVhZCBvZiBhIHJlYWwNCmZpeC4uLg0KDQoNCj4gaW50ZXJydXB0IGhhbmRsaW5nIHdv dWxkIG9ubHkgcHJlc2VudCBhIGRldG91ciBpbiB0aGUgVk0gZm9ya3MnIGV4ZWN1dGlvbg0KPiBm bG93LCBidXQgaW4gdGhlIHdvcnN0IGNhc2UgYXMgd2UgYWN0dWFsbHkgb2JzZXJ2ZWQgY2FuIGNv bXBsZXRlbHkgc3RhbGwgaXQuDQo+IEJ5IGRpc2FibGluZyBpbnRlcnJ1cHQgaW5qZWN0aW9uIGEg ZnV6emVyIGNhbiBleGVyY2lzZSB0aGUgdGFyZ2V0IGNvZGUgd2l0aG91dA0KPiBpbnRlcmZlcmVu Y2UuIEZvciBvdGhlciB1c2UtY2FzZXMgdGhpcyBvcHRpb24gcHJvYmFibHkgZG9lc24ndCBtYWtl IHNlbnNlLA0KPiB0aGF0J3Mgd2h5IHRoaXMgaXMgbm90IGVuYWJsZWQgYnkgZGVmYXVsdC4NCj4g DQo+IEZvcmtzICYgbWVtb3J5IHNoYXJpbmcgYXJlIG9ubHkgYXZhaWxhYmxlIG9uIEludGVsIENQ VXMgc28gdGhpcyBvbmx5IGFwcGxpZXMNCj4gdG8gdm14LiBOb3RlIHRoYXQgdGhpcyBpcyBwYXJ0 IG9mIHRoZSBleHBlcmltZW50YWwgVk0gZm9ya2luZyBmZWF0dXJlIHRoYXQncw0KPiBjb21wbGV0 ZWx5IGRpc2FibGVkIGJ5IGRlZmF1bHQgYW5kIGNhbiBvbmx5IGJlIGVuYWJsZWQgYnkgdXNpbmcN Cj4gWEVOX0NPTkZJR19FWFBFUlQgZHVyaW5nIGNvbXBpbGUgdGltZS4NCj4gDQo+IFNpZ25lZC1v ZmYtYnk6IFRhbWFzIEsgTGVuZ3llbCA8dGFtYXMubGVuZ3llbEBpbnRlbC5jb20+DQo+IFJldmll d2VkLWJ5OiBSb2dlciBQYXUgTW9ubsOpIDxyb2dlci5wYXVAY2l0cml4LmNvbT4NCj4gLS0tDQo+ ICB4ZW4vYXJjaC94ODYvaHZtL3ZteC9pbnRyLmMgICAgICB8IDYgKysrKysrDQo+ICB4ZW4vYXJj aC94ODYvbW0vbWVtX3NoYXJpbmcuYyAgICB8IDYgKysrKystDQo+ICB4ZW4vaW5jbHVkZS9hc20t eDg2L2h2bS9kb21haW4uaCB8IDIgKy0NCj4gIHhlbi9pbmNsdWRlL3B1YmxpYy9tZW1vcnkuaCAg ICAgIHwgMyArKysNCj4gIDQgZmlsZXMgY2hhbmdlZCwgMTUgaW5zZXJ0aW9ucygrKSwgMiBkZWxl dGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvaHZtL3ZteC9pbnRyLmMg Yi94ZW4vYXJjaC94ODYvaHZtL3ZteC9pbnRyLmMNCj4gaW5kZXggMDAwZTE0YWY0OS4uODBiZmJi NDc4NyAxMDA2NDQNCj4gLS0tIGEveGVuL2FyY2gveDg2L2h2bS92bXgvaW50ci5jDQo+ICsrKyBi L3hlbi9hcmNoL3g4Ni9odm0vdm14L2ludHIuYw0KPiBAQCAtMjU2LDYgKzI1NiwxMiBAQCB2b2lk IHZteF9pbnRyX2Fzc2lzdCh2b2lkKQ0KPiAgICAgIGlmICggdW5saWtlbHkodi0+YXJjaC52bV9l dmVudCkgJiYgdi0+YXJjaC52bV9ldmVudC0+c3luY19ldmVudCApDQo+ICAgICAgICAgIHJldHVy bjsNCj4gDQo+ICsjaWZkZWYgQ09ORklHX01FTV9TSEFSSU5HDQo+ICsgICAgLyogQmxvY2sgZXZl bnQgaW5qZWN0aW9uIGZvciBWTSBmb3JrIGlmIHJlcXVlc3RlZCAqLw0KPiArICAgIGlmICggdW5s aWtlbHkodi0+ZG9tYWluLT5hcmNoLmh2bS5tZW1fc2hhcmluZy5ibG9ja19pbnRlcnJ1cHRzKSAp DQo+ICsgICAgICAgIHJldHVybjsNCj4gKyNlbmRpZg0KPiArDQo+ICAgICAgLyogQ3JhbmsgdGhl IGhhbmRsZSBvbiBpbnRlcnJ1cHQgc3RhdGUuICovDQo+ICAgICAgcHRfdmVjdG9yID0gcHRfdXBk YXRlX2lycSh2KTsNCj4gDQo+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvbW0vbWVtX3NoYXJp bmcuYw0KPiBiL3hlbi9hcmNoL3g4Ni9tbS9tZW1fc2hhcmluZy5jDQo+IGluZGV4IDE5OTIyYWI1 ZDEuLmM0MjhmZDE2Y2UgMTAwNjQ0DQo+IC0tLSBhL3hlbi9hcmNoL3g4Ni9tbS9tZW1fc2hhcmlu Zy5jDQo+ICsrKyBiL3hlbi9hcmNoL3g4Ni9tbS9tZW1fc2hhcmluZy5jDQo+IEBAIC0yMTA2LDcg KzIxMDYsOCBAQCBpbnQNCj4gbWVtX3NoYXJpbmdfbWVtb3AoWEVOX0dVRVNUX0hBTkRMRV9QQVJB TSh4ZW5fbWVtX3NoYXJpbmdfb3ANCj4gX3QpIGFyZykNCj4gICAgICAgICAgcmMgPSAtRUlOVkFM Ow0KPiAgICAgICAgICBpZiAoIG1zby51LmZvcmsucGFkICkNCj4gICAgICAgICAgICAgIGdvdG8g b3V0Ow0KPiAtICAgICAgICBpZiAoIG1zby51LmZvcmsuZmxhZ3MgJiB+WEVOTUVNX0ZPUktfV0lU SF9JT01NVV9BTExPV0VEICkNCj4gKyAgICAgICAgaWYgKCBtc28udS5mb3JrLmZsYWdzICYNCj4g KyAgICAgICAgICAgICB+KFhFTk1FTV9GT1JLX1dJVEhfSU9NTVVfQUxMT1dFRCB8DQo+IFhFTk1F TV9GT1JLX0JMT0NLX0lOVEVSUlVQVFMpICkNCj4gICAgICAgICAgICAgIGdvdG8gb3V0Ow0KPiAN Cj4gICAgICAgICAgcmMgPSByY3VfbG9ja19saXZlX3JlbW90ZV9kb21haW5fYnlfaWQobXNvLnUu Zm9yay5wYXJlbnRfZG9tYWluLA0KPiBAQCAtMjEzNCw2ICsyMTM1LDkgQEAgaW50DQo+IG1lbV9z aGFyaW5nX21lbW9wKFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0oeGVuX21lbV9zaGFyaW5nX29wDQo+ IF90KSBhcmcpDQo+ICAgICAgICAgICAgICByYyA9IGh5cGVyY2FsbF9jcmVhdGVfY29udGludWF0 aW9uKF9fSFlQRVJWSVNPUl9tZW1vcnlfb3AsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICJsaCIsIFhFTk1FTV9zaGFyaW5nX29wLA0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhcmcpOw0KPiArICAgICAg ICBlbHNlIGlmICggIXJjICYmIChtc28udS5mb3JrLmZsYWdzICYNCj4gWEVOTUVNX0ZPUktfQkxP Q0tfSU5URVJSVVBUUykgKQ0KPiArICAgICAgICAgICAgZC0+YXJjaC5odm0ubWVtX3NoYXJpbmcu YmxvY2tfaW50ZXJydXB0cyA9IHRydWU7DQo+ICsNCj4gICAgICAgICAgcmN1X3VubG9ja19kb21h aW4ocGQpOw0KPiAgICAgICAgICBicmVhazsNCj4gICAgICB9DQo+IGRpZmYgLS1naXQgYS94ZW4v aW5jbHVkZS9hc20teDg2L2h2bS9kb21haW4uaCBiL3hlbi9pbmNsdWRlL2FzbS0NCj4geDg2L2h2 bS9kb21haW4uaA0KPiBpbmRleCA5NWZlMThjZGRjLi45ZDI0N2JhZjRkIDEwMDY0NA0KPiAtLS0g YS94ZW4vaW5jbHVkZS9hc20teDg2L2h2bS9kb21haW4uaA0KPiArKysgYi94ZW4vaW5jbHVkZS9h c20teDg2L2h2bS9kb21haW4uaA0KPiBAQCAtNjcsNyArNjcsNyBAQCBzdHJ1Y3QgaHZtX2lvcmVx X3NlcnZlciB7DQo+ICAjaWZkZWYgQ09ORklHX01FTV9TSEFSSU5HDQo+ICBzdHJ1Y3QgbWVtX3No YXJpbmdfZG9tYWluDQo+ICB7DQo+IC0gICAgYm9vbCBlbmFibGVkOw0KPiArICAgIGJvb2wgZW5h YmxlZCwgYmxvY2tfaW50ZXJydXB0czsNCj4gDQo+ICAgICAgLyoNCj4gICAgICAgKiBXaGVuIHJl bGVhc2luZyBzaGFyZWQgZ2ZuJ3MgaW4gYSBwcmVlbXB0aWJsZSBtYW5uZXIsIHJlY2FsbCB3aGVy ZQ0KPiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvcHVibGljL21lbW9yeS5oIGIveGVuL2luY2x1 ZGUvcHVibGljL21lbW9yeS5oDQo+IGluZGV4IGRiZDM1MzA1ZGYuLjg1MGJkNzJjNTIgMTAwNjQ0 DQo+IC0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9tZW1vcnkuaA0KPiArKysgYi94ZW4vaW5jbHVk ZS9wdWJsaWMvbWVtb3J5LmgNCj4gQEAgLTUzNiw3ICs1MzYsMTAgQEAgc3RydWN0IHhlbl9tZW1f c2hhcmluZ19vcCB7DQo+ICAgICAgICAgIH0gZGVidWc7DQo+ICAgICAgICAgIHN0cnVjdCBtZW1f c2hhcmluZ19vcF9mb3JrIHsgICAgICAvKiBPUF9GT1JLICovDQo+ICAgICAgICAgICAgICBkb21p ZF90IHBhcmVudF9kb21haW47ICAgICAgICAvKiBJTjogcGFyZW50J3MgZG9tYWluIGlkICovDQo+ ICsvKiBPbmx5IG1ha2VzIHNlbnNlIGZvciBzaG9ydC1saXZlZCBmb3JrcyAqLw0KPiAgI2RlZmlu ZSBYRU5NRU1fRk9SS19XSVRIX0lPTU1VX0FMTE9XRUQgKDF1IDw8IDApDQo+ICsvKiBPbmx5IG1h a2VzIHNlbnNlIGZvciBzaG9ydC1saXZlZCBmb3JrcyAqLw0KPiArI2RlZmluZSBYRU5NRU1fRk9S S19CTE9DS19JTlRFUlJVUFRTICAgKDF1IDw8IDEpDQo+ICAgICAgICAgICAgICB1aW50MTZfdCBm bGFnczsgICAgICAgICAgICAgICAvKiBJTjogb3B0aW9uYWwgc2V0dGluZ3MgKi8NCj4gICAgICAg ICAgICAgIHVpbnQzMl90IHBhZDsgICAgICAgICAgICAgICAgIC8qIE11c3QgYmUgc2V0IHRvIDAg Ki8NCj4gICAgICAgICAgfSBmb3JrOw0KPiAtLQ0KPiAyLjI1LjENCg0K From xen-devel-bounces@lists.xenproject.org Tue Jun 09 23:53:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 23:53:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jio3T-00012V-SH; Tue, 09 Jun 2020 23:53:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jio3S-00012Q-PY for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 23:53:18 +0000 X-Inumbo-ID: 62ae44e4-aaac-11ea-bb8b-bc764e2007e4 Received: from mga05.intel.com (unknown [192.55.52.43]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 62ae44e4-aaac-11ea-bb8b-bc764e2007e4; Tue, 09 Jun 2020 23:53:16 +0000 (UTC) IronPort-SDR: BcHilgKA5Uhn85YuR4C9YpzHmsoIFlAvK/LyJu5E2qESxT0zyDS1fwfGgIWoatufkogmkXAX14 qSA3pW+MY1LA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2020 16:53:13 -0700 IronPort-SDR: AYOQbkY+EpXjge3byPdsUher9dE5q+vgpvJmG+7Q91/JKgSSNbvAHs2DcC/nJBxWTcRGSD0IAg 61k47Suxfp0Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,493,1583222400"; d="scan'208";a="260235733" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga008.fm.intel.com with ESMTP; 09 Jun 2020 16:53:13 -0700 Received: from fmsmsx162.amr.corp.intel.com (10.18.125.71) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 9 Jun 2020 16:53:13 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx162.amr.corp.intel.com (10.18.125.71) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 9 Jun 2020 16:53:12 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.101) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 9 Jun 2020 16:53:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mg8eTHDps640Q1dfC+N2TgQKbuiFaorcABOBHCEKBbDEyKp1IsoBnzk+ien/nbGhXN7kAAIvvxhngPZiT1GORw1eEOjcUFNpYDHQeAAcOyUMkKlGEEdjWnShdLmzjCLc8mDltKyDMo+HKtMhQ6xsL6YyoUPX113Ef+KPnDlIOX/NlQa2hkvXA6kkn6TEcmbY8/8JCNUrQqrHXwblkY/HVVg1aBP/syiFnSxVqOa+rJZGXtfuOhHHYd5H6Le4NLS4xLD7eLQH//wdKdh7h7iMANh2oIj+3FRdqqMeWFcMGFUWXOuJytqdBGewf3l9X0MKBWqGK8l81SMfYPQS9uEP0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Idu8MoGDiheqPhqpXQ5cBxu78CtPxyFHMKB4nyBFHuA=; b=JWzdl5JUTgorhFy91x1GWtGEGVGG8PBolzf95/abjbePYX757qCI0ooAcIv6ItUXVVqxK0Pycks/9r0lEaVureo8B31xXvNxZvpO9UWAw4bXu5ocPMSUPUpb36sn9CgTZ5BMg9agp5c49AtXe+Rw7okxEmycT4HNVIjxn7lSZ33ioVtULn3pR+Tp+BOlTrcBt9On/1qJfyzGHFMD+weeom09YGBBwyyaiB+BUcKzNidVTZ1Iw+U7tQ3ymXhAnqZwzEQzsgNO9kJ0ydaJzLGhf4Qxpo/DXv+6sCt76pHqsusX/ZG7NfMWIA+WpeoheeUp7YLOOvjnRTYve40tuFPxDg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Idu8MoGDiheqPhqpXQ5cBxu78CtPxyFHMKB4nyBFHuA=; b=Bk7mPTQaLpBJBVzu+vfWX9QX8qeB4ibYtfvUulEt59TRncI2wkruuyIXdpm17WLpbCUnAx2oETR2z6ErlmrgmYDjv/LyhYwhnfCmKxyi7uOvWvh5+vV9eWuRNe2NWuEjB4buQUJg1mRCnNlX5YDIeNnyc8/b978+flcTkmudEsU= Received: from MWHPR11MB1645.namprd11.prod.outlook.com (2603:10b6:301:b::12) by MWHPR11MB1405.namprd11.prod.outlook.com (2603:10b6:300:21::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Tue, 9 Jun 2020 23:53:11 +0000 Received: from MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb]) by MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb%5]) with mapi id 15.20.3066.023; Tue, 9 Jun 2020 23:53:11 +0000 From: "Tian, Kevin" To: "Lengyel, Tamas" , "xen-devel@lists.xenproject.org" Subject: RE: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks Thread-Topic: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks Thread-Index: AQHWOBerUwuHg20nGUicDfuX+ypR+ajQ/TJwgAADv5A= Date: Tue, 9 Jun 2020 23:53:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.55.52.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f9fb07d8-c426-4a0a-2f65-08d80cd04480 x-ms-traffictypediagnostic: MWHPR11MB1405: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 042957ACD7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XYkwyI4/YfykewoKpZ/HsBjE/zZkR+OrNGD2pR6MYkmDG6VWkgqFY9HKRYKxKttvkI7pHsRFpGtG+LMyOWepyUwtY6mY96wQCU7UeP9FIscRR9QNuucCjzj8T7LoXUwt0guttTlzOyED2P2MRiQdJLu4X9MeeMISRyHMGg4SQ/b6qhK7L3UH3DhKZzh8D6p3EnVLnoivoCSZsrzUWlO4haIZoAlOmBS6HJXp2v+SJxI6e+fOj1F2qgKcJwrz+LuRbfbyvvFK/KCZHDpMF/fuDKhCxqKy1Ophqz611un0JLK91R3ubkWv4vau1Vnl+Z+ihnWMvN5e2GuBYpDU2sZOIQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1645.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(376002)(346002)(396003)(39860400002)(366004)(5660300002)(8676002)(86362001)(7696005)(8936002)(54906003)(4326008)(83380400001)(52536014)(33656002)(2906002)(71200400001)(110136005)(6506007)(186003)(76116006)(478600001)(64756008)(66476007)(66446008)(26005)(316002)(66556008)(9686003)(66946007)(55016002)(2940100002)(7416002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: IX6lhPQs0yQG39kjaQEG9JSXbuIA5gS05E4aANRi0XmtOF17bTIPt9SfvqpHsCVzp/m52upvkG6faLY4afKappnq1nM/CYtJl/KveOcsYbMficgBaD+Ic63q0Nysd7ODwUTHWSl2ESzHExGwRSJEltxNiJw57hFSuIY4yjDPZ8jQ+wFziImFPBjPfDJRQ4xM2WU3ek9Mcc2smYDa+19WDGLgfAT5qNbOXOO/j2qVysNqSGxcCAH9CPe/TYe/j1o+4+ktDKMFrMu5wArcKQ6JMtkCpCOcoIGTd3Ldk4eQ7uBYosMJcXJU4luLj0kmtB7b1Bp/4wwHSPkOVZ3uIhVOIgsC+yioxzXiJ0PVFkJwwMOQ3MVT3cZDZxE3KK8OTQV3p/jJMuBFLQ3Ut6nct+dalNq9RvIenWr7bWh4+zEMnP/IVop4nGk0EN0WWQL9y4iFWVL9ev92Yejq5aN2ejJ/uEIB1JMZZ+ew2xi1BgmRfNGS5D837AU7h0njeRNrBYzC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f9fb07d8-c426-4a0a-2f65-08d80cd04480 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 23:53:11.2913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XZiyAoZHaZ7EsBRI7+bGiedZH7A08XxlnLTu0b4GtO1vPdy0FCqv+3bAwarwSlIOIh8mCDXj2fOqbDrgoITSSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1405 X-OriginatorOrg: intel.com X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , "Nakajima, Jun" , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Tamas K Lengyel , Jan Beulich , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiBGcm9tOiBUaWFuLCBLZXZpbg0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMTAsIDIwMjAgNzo0 NCBBTQ0KPiANCj4gPiBGcm9tOiBMZW5neWVsLCBUYW1hcyA8dGFtYXMubGVuZ3llbEBpbnRlbC5j b20+DQo+ID4gU2VudDogTW9uZGF5LCBKdW5lIDEsIDIwMjAgOToyMiBQTQ0KPiA+DQo+ID4gV2hl biBydW5uaW5nIFZNIGZvcmtzIHdpdGhvdXQgZGV2aWNlIG1vZGVscyAoUUVNVSksIGl0IG1heQ0K PiA+IGJlIHVuZGVzaXJhYmxlIGZvciBYZW4gdG8gaW5qZWN0IGludGVycnVwdHMuIFdoZW4gY3Jl YXRpbmcgc3VjaCBmb3JrcyBmcm9tDQo+ID4gV2luZG93cyBWTXMgd2UgaGF2ZSBvYnNlcnZlZCB0 aGUga2VybmVsIHRyeWluZyB0byBwcm9jZXNzIGludGVycnVwdHMNCj4gPiBpbW1lZGlhdGVseSBh ZnRlciB0aGUgZm9yayBpcyBleGVjdXRlZC4gSG93ZXZlciB3aXRob3V0IFFFTVUgcnVubmluZw0K PiBzdWNoDQo+ID4gaW50ZXJydXB0IGhhbmRsaW5nIG1heSBub3QgYmUgcG9zc2libGUgYmVjYXVz ZSBpdCBtYXkgYXR0ZW1wdCB0byBpbnRlcmFjdA0KPiA+IHdpdGgNCj4gPiBkZXZpY2VzIHRoYXQg YXJlIG5vdCBlbXVsYXRlZCBieSBhIGJhY2tlbmQuIEluIHRoZSBiZXN0IGNhc2Ugc2NlbmFyaW8g c3VjaA0KPiANCj4gSSBhc2tlZCB0aGlzIHF1ZXN0aW9uIGJlZm9yZS4gdGhlIGludGVycnVwdHMg Y291bGQgY29tZSBmcm9tIFhlbiBpdHNlbGYsIGUuZy4NCj4gZHVlIHRvIHRpbWVyIHZpcnR1YWxp emF0aW9uLiBTbyBJIGRpZG4ndCBnZXQgd2h5IGl0J3MgZGVzaXJlZCB0byBibG9jayBhbGwNCj4g aW50ZXJydXB0cw0KPiBqdXN0IGJlY2F1c2Ugbm8gUUVNVSBpcyBydW5uaW5nLiBBbHNvIGl0J3Mg d2VpcmQgd2h5IFdpbmRvd3MgVk1zIGFyZQ0KPiBvYnNlcnZlZCB0byBwcm9jZXNzIGludGVycnVw dHMgdGhhdCBhcmUgZ2VuZXJhdGVkIGJ5IFFFTVUgd2hlbiBubyBzdWNoDQo+IGJhY2tlbmQgZW11 bGF0aW9uIGV4aXN0cyBhdCBhbGwuIEl0IHNvdW5kcyBsaWtlIGEgd29ya2Fyb3VuZCBpbnN0ZWFk IG9mIGEgcmVhbA0KPiBmaXguLi4NCg0Kb2ssIEkgcmVjaGVja2VkIHlvdXIgcmVwbHkuIExvb2tz IGl0J3MgYWJvdXQgdGhlIGNhc2UgdGhhdCBwYXJlbnQgVk0gaGFzIFFFTVUNCmFuZCBwZW5kaW5n IGludGVycnVwdHMgd2hpbGUgeW91IGZvcmsgaXQgaW50byBjaGlsZCBWTXMgd2l0aG91dCBRRU1V IHNvIHRob3NlDQpwZW5kaW5nIGludGVycnVwdHMgYmVjb21lIHByb2JsZW1hdGljLg0KDQpSZXZp ZXdlZC1ieTogS2V2aW4gVGlhbiA8a2V2aW4udGlhbkBpbnRlbC5jb20+DQoNCj4gDQo+IA0KPiA+ IGludGVycnVwdCBoYW5kbGluZyB3b3VsZCBvbmx5IHByZXNlbnQgYSBkZXRvdXIgaW4gdGhlIFZN IGZvcmtzJyBleGVjdXRpb24NCj4gPiBmbG93LCBidXQgaW4gdGhlIHdvcnN0IGNhc2UgYXMgd2Ug YWN0dWFsbHkgb2JzZXJ2ZWQgY2FuIGNvbXBsZXRlbHkgc3RhbGwgaXQuDQo+ID4gQnkgZGlzYWJs aW5nIGludGVycnVwdCBpbmplY3Rpb24gYSBmdXp6ZXIgY2FuIGV4ZXJjaXNlIHRoZSB0YXJnZXQg Y29kZQ0KPiB3aXRob3V0DQo+ID4gaW50ZXJmZXJlbmNlLiBGb3Igb3RoZXIgdXNlLWNhc2VzIHRo aXMgb3B0aW9uIHByb2JhYmx5IGRvZXNuJ3QgbWFrZSBzZW5zZSwNCj4gPiB0aGF0J3Mgd2h5IHRo aXMgaXMgbm90IGVuYWJsZWQgYnkgZGVmYXVsdC4NCj4gPg0KPiA+IEZvcmtzICYgbWVtb3J5IHNo YXJpbmcgYXJlIG9ubHkgYXZhaWxhYmxlIG9uIEludGVsIENQVXMgc28gdGhpcyBvbmx5DQo+IGFw cGxpZXMNCj4gPiB0byB2bXguIE5vdGUgdGhhdCB0aGlzIGlzIHBhcnQgb2YgdGhlIGV4cGVyaW1l bnRhbCBWTSBmb3JraW5nIGZlYXR1cmUgdGhhdCdzDQo+ID4gY29tcGxldGVseSBkaXNhYmxlZCBi eSBkZWZhdWx0IGFuZCBjYW4gb25seSBiZSBlbmFibGVkIGJ5IHVzaW5nDQo+ID4gWEVOX0NPTkZJ R19FWFBFUlQgZHVyaW5nIGNvbXBpbGUgdGltZS4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFRh bWFzIEsgTGVuZ3llbCA8dGFtYXMubGVuZ3llbEBpbnRlbC5jb20+DQo+ID4gUmV2aWV3ZWQtYnk6 IFJvZ2VyIFBhdSBNb25uw6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPg0KPiA+IC0tLQ0KPiA+ICB4 ZW4vYXJjaC94ODYvaHZtL3ZteC9pbnRyLmMgICAgICB8IDYgKysrKysrDQo+ID4gIHhlbi9hcmNo L3g4Ni9tbS9tZW1fc2hhcmluZy5jICAgIHwgNiArKysrKy0NCj4gPiAgeGVuL2luY2x1ZGUvYXNt LXg4Ni9odm0vZG9tYWluLmggfCAyICstDQo+ID4gIHhlbi9pbmNsdWRlL3B1YmxpYy9tZW1vcnku aCAgICAgIHwgMyArKysNCj4gPiAgNCBmaWxlcyBjaGFuZ2VkLCAxNSBpbnNlcnRpb25zKCspLCAy IGRlbGV0aW9ucygtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0vdm14 L2ludHIuYyBiL3hlbi9hcmNoL3g4Ni9odm0vdm14L2ludHIuYw0KPiA+IGluZGV4IDAwMGUxNGFm NDkuLjgwYmZiYjQ3ODcgMTAwNjQ0DQo+ID4gLS0tIGEveGVuL2FyY2gveDg2L2h2bS92bXgvaW50 ci5jDQo+ID4gKysrIGIveGVuL2FyY2gveDg2L2h2bS92bXgvaW50ci5jDQo+ID4gQEAgLTI1Niw2 ICsyNTYsMTIgQEAgdm9pZCB2bXhfaW50cl9hc3Npc3Qodm9pZCkNCj4gPiAgICAgIGlmICggdW5s aWtlbHkodi0+YXJjaC52bV9ldmVudCkgJiYgdi0+YXJjaC52bV9ldmVudC0+c3luY19ldmVudCAp DQo+ID4gICAgICAgICAgcmV0dXJuOw0KPiA+DQo+ID4gKyNpZmRlZiBDT05GSUdfTUVNX1NIQVJJ TkcNCj4gPiArICAgIC8qIEJsb2NrIGV2ZW50IGluamVjdGlvbiBmb3IgVk0gZm9yayBpZiByZXF1 ZXN0ZWQgKi8NCj4gPiArICAgIGlmICggdW5saWtlbHkodi0+ZG9tYWluLT5hcmNoLmh2bS5tZW1f c2hhcmluZy5ibG9ja19pbnRlcnJ1cHRzKSApDQo+ID4gKyAgICAgICAgcmV0dXJuOw0KPiA+ICsj ZW5kaWYNCj4gPiArDQo+ID4gICAgICAvKiBDcmFuayB0aGUgaGFuZGxlIG9uIGludGVycnVwdCBz dGF0ZS4gKi8NCj4gPiAgICAgIHB0X3ZlY3RvciA9IHB0X3VwZGF0ZV9pcnEodik7DQo+ID4NCj4g PiBkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L21tL21lbV9zaGFyaW5nLmMNCj4gPiBiL3hlbi9h cmNoL3g4Ni9tbS9tZW1fc2hhcmluZy5jDQo+ID4gaW5kZXggMTk5MjJhYjVkMS4uYzQyOGZkMTZj ZSAxMDA2NDQNCj4gPiAtLS0gYS94ZW4vYXJjaC94ODYvbW0vbWVtX3NoYXJpbmcuYw0KPiA+ICsr KyBiL3hlbi9hcmNoL3g4Ni9tbS9tZW1fc2hhcmluZy5jDQo+ID4gQEAgLTIxMDYsNyArMjEwNiw4 IEBAIGludA0KPiA+DQo+IG1lbV9zaGFyaW5nX21lbW9wKFhFTl9HVUVTVF9IQU5ETEVfUEFSQU0o eGVuX21lbV9zaGFyaW5nX29wDQo+ID4gX3QpIGFyZykNCj4gPiAgICAgICAgICByYyA9IC1FSU5W QUw7DQo+ID4gICAgICAgICAgaWYgKCBtc28udS5mb3JrLnBhZCApDQo+ID4gICAgICAgICAgICAg IGdvdG8gb3V0Ow0KPiA+IC0gICAgICAgIGlmICggbXNvLnUuZm9yay5mbGFncyAmIH5YRU5NRU1f Rk9SS19XSVRIX0lPTU1VX0FMTE9XRUQgKQ0KPiA+ICsgICAgICAgIGlmICggbXNvLnUuZm9yay5m bGFncyAmDQo+ID4gKyAgICAgICAgICAgICB+KFhFTk1FTV9GT1JLX1dJVEhfSU9NTVVfQUxMT1dF RCB8DQo+ID4gWEVOTUVNX0ZPUktfQkxPQ0tfSU5URVJSVVBUUykgKQ0KPiA+ICAgICAgICAgICAg ICBnb3RvIG91dDsNCj4gPg0KPiA+ICAgICAgICAgIHJjID0gcmN1X2xvY2tfbGl2ZV9yZW1vdGVf ZG9tYWluX2J5X2lkKG1zby51LmZvcmsucGFyZW50X2RvbWFpbiwNCj4gPiBAQCAtMjEzNCw2ICsy MTM1LDkgQEAgaW50DQo+ID4NCj4gbWVtX3NoYXJpbmdfbWVtb3AoWEVOX0dVRVNUX0hBTkRMRV9Q QVJBTSh4ZW5fbWVtX3NoYXJpbmdfb3ANCj4gPiBfdCkgYXJnKQ0KPiA+ICAgICAgICAgICAgICBy YyA9IGh5cGVyY2FsbF9jcmVhdGVfY29udGludWF0aW9uKF9fSFlQRVJWSVNPUl9tZW1vcnlfb3As DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImxo IiwgWEVOTUVNX3NoYXJpbmdfb3AsDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYXJnKTsNCj4gPiArICAgICAgICBlbHNlIGlmICggIXJjICYmICht c28udS5mb3JrLmZsYWdzICYNCj4gPiBYRU5NRU1fRk9SS19CTE9DS19JTlRFUlJVUFRTKSApDQo+ ID4gKyAgICAgICAgICAgIGQtPmFyY2guaHZtLm1lbV9zaGFyaW5nLmJsb2NrX2ludGVycnVwdHMg PSB0cnVlOw0KPiA+ICsNCj4gPiAgICAgICAgICByY3VfdW5sb2NrX2RvbWFpbihwZCk7DQo+ID4g ICAgICAgICAgYnJlYWs7DQo+ID4gICAgICB9DQo+ID4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRl L2FzbS14ODYvaHZtL2RvbWFpbi5oIGIveGVuL2luY2x1ZGUvYXNtLQ0KPiA+IHg4Ni9odm0vZG9t YWluLmgNCj4gPiBpbmRleCA5NWZlMThjZGRjLi45ZDI0N2JhZjRkIDEwMDY0NA0KPiA+IC0tLSBh L3hlbi9pbmNsdWRlL2FzbS14ODYvaHZtL2RvbWFpbi5oDQo+ID4gKysrIGIveGVuL2luY2x1ZGUv YXNtLXg4Ni9odm0vZG9tYWluLmgNCj4gPiBAQCAtNjcsNyArNjcsNyBAQCBzdHJ1Y3QgaHZtX2lv cmVxX3NlcnZlciB7DQo+ID4gICNpZmRlZiBDT05GSUdfTUVNX1NIQVJJTkcNCj4gPiAgc3RydWN0 IG1lbV9zaGFyaW5nX2RvbWFpbg0KPiA+ICB7DQo+ID4gLSAgICBib29sIGVuYWJsZWQ7DQo+ID4g KyAgICBib29sIGVuYWJsZWQsIGJsb2NrX2ludGVycnVwdHM7DQo+ID4NCj4gPiAgICAgIC8qDQo+ ID4gICAgICAgKiBXaGVuIHJlbGVhc2luZyBzaGFyZWQgZ2ZuJ3MgaW4gYSBwcmVlbXB0aWJsZSBt YW5uZXIsIHJlY2FsbCB3aGVyZQ0KPiA+IGRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMv bWVtb3J5LmggYi94ZW4vaW5jbHVkZS9wdWJsaWMvbWVtb3J5LmgNCj4gPiBpbmRleCBkYmQzNTMw NWRmLi44NTBiZDcyYzUyIDEwMDY0NA0KPiA+IC0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9tZW1v cnkuaA0KPiA+ICsrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9tZW1vcnkuaA0KPiA+IEBAIC01MzYs NyArNTM2LDEwIEBAIHN0cnVjdCB4ZW5fbWVtX3NoYXJpbmdfb3Agew0KPiA+ICAgICAgICAgIH0g ZGVidWc7DQo+ID4gICAgICAgICAgc3RydWN0IG1lbV9zaGFyaW5nX29wX2ZvcmsgeyAgICAgIC8q IE9QX0ZPUksgKi8NCj4gPiAgICAgICAgICAgICAgZG9taWRfdCBwYXJlbnRfZG9tYWluOyAgICAg ICAgLyogSU46IHBhcmVudCdzIGRvbWFpbiBpZCAqLw0KPiA+ICsvKiBPbmx5IG1ha2VzIHNlbnNl IGZvciBzaG9ydC1saXZlZCBmb3JrcyAqLw0KPiA+ICAjZGVmaW5lIFhFTk1FTV9GT1JLX1dJVEhf SU9NTVVfQUxMT1dFRCAoMXUgPDwgMCkNCj4gPiArLyogT25seSBtYWtlcyBzZW5zZSBmb3Igc2hv cnQtbGl2ZWQgZm9ya3MgKi8NCj4gPiArI2RlZmluZSBYRU5NRU1fRk9SS19CTE9DS19JTlRFUlJV UFRTICAgKDF1IDw8IDEpDQo+ID4gICAgICAgICAgICAgIHVpbnQxNl90IGZsYWdzOyAgICAgICAg ICAgICAgIC8qIElOOiBvcHRpb25hbCBzZXR0aW5ncyAqLw0KPiA+ICAgICAgICAgICAgICB1aW50 MzJfdCBwYWQ7ICAgICAgICAgICAgICAgICAvKiBNdXN0IGJlIHNldCB0byAwICovDQo+ID4gICAg ICAgICAgfSBmb3JrOw0KPiA+IC0tDQo+ID4gMi4yNS4xDQoNCg== From xen-devel-bounces@lists.xenproject.org Tue Jun 09 23:55:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 09 Jun 2020 23:55:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jio5g-0001AL-CU; Tue, 09 Jun 2020 23:55:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jio5e-0001AF-Tb for xen-devel@lists.xenproject.org; Tue, 09 Jun 2020 23:55:35 +0000 X-Inumbo-ID: b528404e-aaac-11ea-b7bb-bc764e2007e4 Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b528404e-aaac-11ea-b7bb-bc764e2007e4; Tue, 09 Jun 2020 23:55:34 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id o26so105247edq.0 for ; Tue, 09 Jun 2020 16:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GV/A4Kh8sVQ2w1SEO1QkQrrDgKaqgB1xllhmlI0qHTg=; b=vTyhtxW+0A8Wk5HyQj2FuhuLr6h1tNuBVWhi3IuMikW/3jRpbWjePVyRyojdzPHAFI G6lhh36ugDN57tHgPSr6YX1RHoPMNAgeHDm366KrZiZ/+8uToeMUORc2/PsWPxiyfmD0 Az5ijpkiIVTAbSYazoi4vNxMcMB440cD/EiqOH11h5TPjdRukQzSicYjG/fKUSKj3L1v opmrUXP3PBV9NCIxHAGB7mYq7a7xhJk8IHNvk3qPWUD2uUElrqCjGW+HXxU8cuOYAVFG 6kY3IymVxz50TX6E2rpiFa+FFFlcU8QApy4hAgFHKdQvLt4kH3lGKSJtSfA60jq0Knc0 vLHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GV/A4Kh8sVQ2w1SEO1QkQrrDgKaqgB1xllhmlI0qHTg=; b=mH/nfZTCMwP4IBW5Kyl5O+KmBxJaUqZLjx+aTYM4GOXXV6UF8hr+bVzuqwxVbx8hxO MLJS1x25uio9S1Y90bzXXAficuPO759E9KhXYEcWEdU5YZERIHauLO546gUxsmmKZ0rF eyi7osJOEmkUUNnfyp28/l2mPOpMo9TIV6wbM9EyMb8DQ14L4cw/n2B1d784RVGjx4nF o4YNbmTE+Tzf1pVMUvs5UhigRSpVedfI6me/XvciM39XPjWLOok1hdjI48ujBXPlcRu3 Di9WGIb11R4+LpjX8kF/96yMe64QExT6nC/3d8PGxrpE5vHL15RzzXPqSYXoti8Mkqj2 0rSA== X-Gm-Message-State: AOAM532WlHXT4pcBge3/lQdIYcDOfB+48kgsAaiIvjWSew/XUD9j9yjT 2yH0hNn3AUseu+hN34xSiJ67XbFCPA4= X-Google-Smtp-Source: ABdhPJySyz80np8dmlbvxoeVeaqk6d9QP2lR8f8yW5dYONC+BFLgxvuJ9/7n2maaqtxTTO21TeiYqg== X-Received: by 2002:a50:bf0e:: with SMTP id f14mr213117edk.37.1591746932556; Tue, 09 Jun 2020 16:55:32 -0700 (PDT) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com. [209.85.221.50]) by smtp.gmail.com with ESMTPSA id f19sm15796272edq.14.2020.06.09.16.55.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 16:55:31 -0700 (PDT) Received: by mail-wr1-f50.google.com with SMTP id j10so212435wrw.8 for ; Tue, 09 Jun 2020 16:55:31 -0700 (PDT) X-Received: by 2002:adf:f0c6:: with SMTP id x6mr371356wro.301.1591746931082; Tue, 09 Jun 2020 16:55:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tamas K Lengyel Date: Tue, 9 Jun 2020 17:54:50 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v19 for-4.14 01/13] x86/mem_sharing: block interrupt injection for forks To: "Tian, Kevin" Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Stefano Stabellini , "Lengyel, Tamas" , "Nakajima, Jun" , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , "xen-devel@lists.xenproject.org" , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 9, 2020 at 5:53 PM Tian, Kevin wrote: > > > From: Tian, Kevin > > Sent: Wednesday, June 10, 2020 7:44 AM > > > > > From: Lengyel, Tamas > > > Sent: Monday, June 1, 2020 9:22 PM > > > > > > When running VM forks without device models (QEMU), it may > > > be undesirable for Xen to inject interrupts. When creating such forks from > > > Windows VMs we have observed the kernel trying to process interrupts > > > immediately after the fork is executed. However without QEMU running > > such > > > interrupt handling may not be possible because it may attempt to interact > > > with > > > devices that are not emulated by a backend. In the best case scenario such > > > > I asked this question before. the interrupts could come from Xen itself, e.g. > > due to timer virtualization. So I didn't get why it's desired to block all > > interrupts > > just because no QEMU is running. Also it's weird why Windows VMs are > > observed to process interrupts that are generated by QEMU when no such > > backend emulation exists at all. It sounds like a workaround instead of a real > > fix... > > ok, I rechecked your reply. Looks it's about the case that parent VM has QEMU > and pending interrupts while you fork it into child VMs without QEMU so those > pending interrupts become problematic. > > Reviewed-by: Kevin Tian HI Kevin, thanks! That's the case but really we just want to block all interrupts irrespective of where the are coming from. The fork VMs are being reset hundreds or thousands of times per second during fuzzing, so there is no point in injecting any interrupt at all in that particular use-case. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 10 02:01:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 02:01:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiq3B-0005qk-1X; Wed, 10 Jun 2020 02:01:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiq39-0005qf-R9 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 02:01:07 +0000 X-Inumbo-ID: 3dae4920-aabe-11ea-b3a3-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3dae4920-aabe-11ea-b3a3-12813bfff9fa; Wed, 10 Jun 2020 02:01:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PSXbGG734ssfsrUwyatVl0my8/Wb/+8RcHJegMkvNok=; b=PisaiV9zcqxuFytc3rvEav4a9 7hodYGIug3aOjo9hP/Zw6CgbRkRr6lPt0B4nNeh054YTEAujDUjAn39YALpZXP6X6ExWRMMZvu6u6 7KoNn/Gx/zK3sUsRRB66CEK8msyvfwjnqh7/cKGzdHZ/FnVHPOObyP7C1bQZurxlYIAhA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiq36-00012s-38; Wed, 10 Jun 2020 02:01:04 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiq35-0003RK-ST; Wed, 10 Jun 2020 02:01:03 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiq35-00027x-Rt; Wed, 10 Jun 2020 02:01:03 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 150943: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=199ae1f15894bd1bdefdf7c3e44688127be3ba19 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Wed, 10 Jun 2020 02:01:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150943 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150943/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 199ae1f15894bd1bdefdf7c3e44688127be3ba19 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 26 days Testing same since 150943 2020-06-09 17:06:00 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Wed Jun 10 05:29:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 05:29:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jitIr-0007Wv-9b; Wed, 10 Jun 2020 05:29:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jitIq-0007Wq-Gn for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 05:29:32 +0000 X-Inumbo-ID: 5bfefe3e-aadb-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5bfefe3e-aadb-11ea-bb8b-bc764e2007e4; Wed, 10 Jun 2020 05:29:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DwrQJ72ufntcBM75vWm9PtYzIFMEp1rmRG/fDhi6Vbs=; b=J8AWqhOlNp6bAcVlBAU1jCYUr 8v7OqpAgHF/5JwsTrmX1eBdJYD11idBXCRPMuIn9WfTzAI7BcgiFQOLOhTmz8H+QTS3UqsfgZZ46o tOWFADzTBlS+4RmxXVYFz5vigIEfhqPOw4VSnjm+d992jCHqhA3vs88bgwu/jlfAIvUOs=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jitIn-0006nM-Ns; Wed, 10 Jun 2020 05:29:29 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jitIn-0004Gk-Fy; Wed, 10 Jun 2020 05:29:29 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jitIn-0007aV-EB; Wed, 10 Jun 2020 05:29:29 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.13-testing test] 150944: tolerable FAIL - PUSHED X-Osstest-Failures: xen-4.13-testing:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=67958a166f6b019e5ad8dcd60a96dcd262669092 X-Osstest-Versions-That: xen=6278553325a9f76d37811923221b21db3882e017 From: osstest service owner Date: Wed, 10 Jun 2020 05:29:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150944 xen-4.13-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150944/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150177 test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 67958a166f6b019e5ad8dcd60a96dcd262669092 baseline version: xen 6278553325a9f76d37811923221b21db3882e017 Last test of basis 150177 2020-05-14 12:36:34 Z 26 days Testing same since 150944 2020-06-09 17:06:08 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 6278553325..67958a166f 67958a166f6b019e5ad8dcd60a96dcd262669092 -> stable-4.13 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 08:07:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 08:07:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jivlG-0004ke-N6; Wed, 10 Jun 2020 08:07:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jivlF-0004kZ-Rs for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 08:07:02 +0000 X-Inumbo-ID: 5c089cee-aaf1-11ea-bca7-bc764e2007e4 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.81]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5c089cee-aaf1-11ea-bca7-bc764e2007e4; Wed, 10 Jun 2020 08:07:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8kIm7OYgJZVD9wHJTyYfatv91ze+TX+8dUe5pnyCAn8=; b=Uji7wSiq4/pXBNBPUdN4xxSfcM1K9t0zA0rmkvSGh5fy/A6r2GW+BS4mSjjzbfzSman5jFzvXi39LO0IjebxbnTe/gww5/e7HY+5fkoHfnYbnSZZGFJaBNc0eNVLsSjbAQBOQTtFu2Y4bqvV7BmQQx35O0Ij4HmfO0fwNzxEoVY= Received: from AM5PR0402CA0001.eurprd04.prod.outlook.com (2603:10a6:203:90::11) by DB6PR0801MB1768.eurprd08.prod.outlook.com (2603:10a6:4:3b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Wed, 10 Jun 2020 08:06:58 +0000 Received: from AM5EUR03FT018.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:90:cafe::46) by AM5PR0402CA0001.outlook.office365.com (2603:10a6:203:90::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Wed, 10 Jun 2020 08:06:58 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT018.mail.protection.outlook.com (10.152.16.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Wed, 10 Jun 2020 08:06:58 +0000 Received: ("Tessian outbound fb809da9b456:v59"); Wed, 10 Jun 2020 08:06:58 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 0250bfaa650948a8 X-CR-MTA-TID: 64aa7808 Received: from 08c4edaddc9d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8751D276-0F09-44D5-8DF4-141C2C8DF1EB.1; Wed, 10 Jun 2020 08:06:53 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 08c4edaddc9d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 10 Jun 2020 08:06:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fc1QfHCwuGjdKKmrfeVyiAX6lp5RP5M7ZpkOeZXmXHR7/fn0OwrPNY5Jj2yBzpbw0CioyC1+I5RDe0d+KZrop8+isS6WmRGKQslUAdSNcraoD+vkfdOID0gawG4oR7qhL95U3aRZYtGJIO4K4uquVdGSCPK3JRAF3SzGimapt36xyQr1eE/xIUtkhhtYH9FQHUSSbiRWScVZWZHEo+2g8XyzTm28Az70/SSCRTR7OdDT3rNE1JqnjxvZlMPLVbp5ZiiZiw+h6Gf0/yBi4FYf0T8QbJgu2oFvKivG6piBFqCkQCNl66Q1kYcJag4sIv06eKmM48h5B43FUAK8eDC92g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8kIm7OYgJZVD9wHJTyYfatv91ze+TX+8dUe5pnyCAn8=; b=H8KybL/GuIY2FEHwTs79I+V7LDfSz1qmqWtHdNJ5d7tq83xocU4H+9inrzwMKTirFQZ29Kx+OC64XUPbUR3KADAp+RoLACkd4DYyXb44bXMF2JkOIZ+He5CkCTGmKL3PjUiHUktB2nNhQE1E2NhbYD6b37BHPHxkh32oGPmB6jukIPrgJ6+ttxIMQrvobZr9h0uCOpPRwjwtpX39zl6lWZpFMmo5riszhwNk8Gv054bGm8seGRp8tAI8KK2+C2b92UpjWDCycmzeHpu2YePXhMSQ7+ixAvbHYweBgZAqrcbzuwu+9rFNSXref2vwFBFUlLAIOdNZzn6OH7OEGyXztg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8kIm7OYgJZVD9wHJTyYfatv91ze+TX+8dUe5pnyCAn8=; b=Uji7wSiq4/pXBNBPUdN4xxSfcM1K9t0zA0rmkvSGh5fy/A6r2GW+BS4mSjjzbfzSman5jFzvXi39LO0IjebxbnTe/gww5/e7HY+5fkoHfnYbnSZZGFJaBNc0eNVLsSjbAQBOQTtFu2Y4bqvV7BmQQx35O0Ij4HmfO0fwNzxEoVY= Received: from AM0PR08MB3682.eurprd08.prod.outlook.com (2603:10a6:208:fb::27) by AM0PR08MB5009.eurprd08.prod.outlook.com (2603:10a6:208:160::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Wed, 10 Jun 2020 08:06:51 +0000 Received: from AM0PR08MB3682.eurprd08.prod.outlook.com ([fe80::b572:771:2750:14ed]) by AM0PR08MB3682.eurprd08.prod.outlook.com ([fe80::b572:771:2750:14ed%5]) with mapi id 15.20.3088.019; Wed, 10 Jun 2020 08:06:50 +0000 From: Bertrand Marquis To: Marc Zyngier Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgIAAJpOAgABE7QCABAZcAIAAQRIAgAA9oACAAXYtAIAAD3sAgAAFaoCAABUzgIAAB/uAgAAD1ICAAPCKAA== Date: Wed, 10 Jun 2020 08:06:50 +0000 Message-ID: <32FA85C2-7685-49D2-875B-9FA1C138C92A@arm.com> References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> In-Reply-To: <6033f9cecbf10f50f4a713ce52105426@kernel.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 7ddc80b5-908b-420b-d251-08d80d153f8f x-ms-traffictypediagnostic: AM0PR08MB5009:|DB6PR0801MB1768: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0430FA5CB7 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: gWlZJ9omZsA06eJrPHezk8+ptFZ7w+4FQocg8lA1YIOlCIKOjvlwH4p/LDmsviQn4QWDlvZkks/OiRLkEnF3EG7Hz8up67App+0se4ECnufEcKwD4pXyQUXZuL9hqBCJb88qrTBo981YyDNeI9Ts9YtpIRB9a9Pua1qCQ/Ztkex9o/kqBN7iEo/LsLeIBhQUYZDCplp8xT3I5B0O6PwgyrADNnF8JVwUM+gVBhIyjluipDMjM4g7XKNWi3eBGWMsu6ONU4hHdJnRtEQRkRSVHGhOAwox0Dz50W7M2SPbZFd57y9p2gUFreev/41WbyurEoEHtpHWWYLYSWWjp39Rjg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3682.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(39860400002)(136003)(376002)(366004)(6486002)(5660300002)(64756008)(66556008)(66446008)(2906002)(53546011)(6506007)(76116006)(33656002)(478600001)(36756003)(4326008)(66946007)(66476007)(186003)(6916009)(3480700007)(91956017)(26005)(8936002)(316002)(86362001)(6512007)(8676002)(54906003)(7116003)(2616005)(83380400001)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 4xC9Y96g9FM1gjIUvpiXSi5yDxsCKO8WKvAmrsLyKenEUCtbafcVUknQ/vMRIFeDqNCP4qlNQhjvCwEppiO9SeEVgOyVk9J8ZsiNKog+E+bmI9iRHr4H9zbrRuI0mIkuVrAOnSsm8RVVp18WZN2PJnwNeq1LvCqf5qIwmFZUE/DWiL1q7db0sHvUMwXs7HNU1zJwpiSkTnw1xx0WD8++0c+L1w9NX9/FXDL9Bhoe20KwqiOGFyvoQHkK5KWrT5KHxneSkIPqdLOOL7S4l2Q9KzDbqzM3KgkT5fO68+h+TJtYLRETCFqNNIFT/g/IZiHXrZiWCAxJNsWdhFSjfCs4DQQ2GfRkneVhKX7zx5f6g5ezH05uZu+nqqS/TX6e3P3vrx/R5niufYHh7vUr63OgvDSB1mJcumI1ppPKViG5dxRSkPHK7FRatFdpyiOVn7PeYwXDdEO5BiBoc8e4Q5cyjKxQjl2j/B/5Goem0N4kUhE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5009 Original-Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT018.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(136003)(396003)(376002)(46966005)(26005)(186003)(82740400003)(3480700007)(81166007)(8676002)(47076004)(4326008)(356005)(7116003)(8936002)(478600001)(86362001)(83380400001)(2906002)(36906005)(316002)(82310400002)(6506007)(6862004)(70206006)(5660300002)(336012)(70586007)(6512007)(54906003)(2616005)(6486002)(33656002)(53546011)(36756003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 7b025cdf-801b-4b4b-cd6c-08d80d153b17 X-Forefront-PRVS: 0430FA5CB7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: m/s24uxI07p4jZdewxC5+2HyLKAdQezj1KYOI3GI4/1OQRt5lRVuQ5f7gbSY5fy/XVfSg7YNgqz3/8WExgl/FGcn0nKr743yyiSINSGG6xgIjxOaKDP1FkDjvGA1vY5BobQYBPNPG0coSV15lnGBS+PatzWslLClTV8G2rmrMMjjiTESptYmuhw3O/5dk/5iIyWR0TiwU91kPk1tXsseQC504YQuiiYzuQf9NTvSzhgTqTTZ1XyRUQkGc6k2ziVpXyYbo7Xurd4jTmr99xgCklRIbktFsXEk/HrkhmVGdm70cLnCs4PJkzRA1Kmiy/LDJDWLhB6wd5zcLF9TzLcj/Bj25UQP+hSI5gj6LTywdVuamVw9BNxZrrkSxvq+xgqVdo8op3OOW6i7c++Sw6/QZw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2020 08:06:58.4239 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7ddc80b5-908b-420b-d251-08d80d153f8f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1768 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall , CodeWiz2280 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, > On 9 Jun 2020, at 18:45, Marc Zyngier wrote: >=20 > Hi Julien, >=20 > On 2020-06-09 18:32, Julien Grall wrote: >> (+ Marc) >> On 09/06/2020 18:03, Bertrand Marquis wrote: >>> Hi >>>> On 9 Jun 2020, at 16:47, Julien Grall wrote: >>>> On 09/06/2020 16:28, Bertrand Marquis wrote: >>>>> Hi, >>>>>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >>>>>> There does appear to be a secondary (CIC) controller that can forwar= d >>>>>> events to the GIC-400 and EDMA controllers for the keystone 2 family= . >>>>>> Admittedly, i'm not sure how it is being used with regards to the >>>>>> peripherals. I only see mention of the GIC-400 parent for the devic= es >>>>>> in the device tree. Maybe Bertrand has a better idea on whether any >>>>>> peripherals go through the CIC first? I see that gic_interrupt () >>>>>> fires once in Xen, which calls doIRQ to push out the virtual interru= pt >>>>>> to the dom0 kernel. The dom0 kernel then handles the interrupt and >>>>>> returns, but gic_interrupt() never fires again in Xen. >>>>> I do not remember of any CIC but the behaviour definitely look like a= n interrupt acknowledge problem. >>>>> Could you try the following: >>>>> --- a/xen/arch/arm/gic-v2.c >>>>> +++ b/xen/arch/arm/gic-v2.c >>>>> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc *= desc) >>>>> /* Lower the priority of the IRQ */ >>>>> gicv2_eoi_irq(desc); >>>>> /* Deactivation happens in maintenance interrupt / via GICV */ >>>>> + >>>>> + /* Test for Keystone2 */ >>>>> + gicv2_dir_irq(desc); >>>>> } >>>>> I think the problem I had was related to the vgic not deactivating pr= operly the interrupt. >>>> Are you suggesting the guest EOI is not properly forwarded to the hard= ware when LR.HW is set? If so, this could possibly be workaround in Xen by = raising a maintenance interrupt every time a guest EOI an interrupt. >>> Agree the maintenance interrupt would definitely be the right solution >> I would like to make sure we aren't missing anything in Xen first. >> From what you said, you have encountered this issue in the past with a >> different hypervisor. So it doesn't look like to be Xen related. >> Was there any official statement from TI? If not, can we try to get >> some input from them first? >> @Marc, I know you dropped 32-bit support in KVM recently :). Although, >=20 > Yes! Victory is mine! Freedom from the shackles of 32bit, at last! :D >=20 >> I was wondering if you heard about any potential issue with guest EOI >> not forwarded to the host. This is on TI Keystone (Cortex A-15). >=20 > Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway = all run just fine with guest EOI), and GIC-400 is a pretty solid piece of k= it (it is just sloooooow...). >=20 > Thinking of it, you would see something like that if the GIC was seeing t= he writes coming from the guest as secure instead of NS (cue the early firm= ware on XGene that exposed the wrong side of GIC-400). >=20 > Is there some kind of funky bridge between the CPU and the GIC? Yes the behaviour I had was coherent with the GIC seeing the processor in s= ecure mode and not in non secure hence making the VGIC ack non functional. So the only way to solve this is actually to do the interrupt deactivate in= side Xen (using a maintenance interrupt). I remember that I also had to do something specific for the configuration o= f edge/level and priorities to have an almost proper behaviour. Sadly I have no access to the code anymore, so I would need to guess back w= hat that was.. Bertrand >=20 > M. > --=20 > Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Wed Jun 10 08:13:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 08:13:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jivrv-0005aY-Ag; Wed, 10 Jun 2020 08:13:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jivru-0005aT-2h for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 08:13:54 +0000 X-Inumbo-ID: 5220ed66-aaf2-11ea-bb8b-bc764e2007e4 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (unknown [40.107.14.70]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5220ed66-aaf2-11ea-bb8b-bc764e2007e4; Wed, 10 Jun 2020 08:13:53 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J1lUd0mBH8NH2GMK08sYwVZHSjihZl4gaqzUJnbKQGq+C7HUYNCssoiS9xDb4iJjw10VZTTapwnbNDVdwS0NPDicpXAlbzmZ5xhDIhHy7EsRrJy6cN12GY1kMs/Llyif1iyaf6rgoZgDuV1myrvInAX2XDU3L670PpHmoEwreT4mCYijE8WEczLHjuh0zTfw+ldiEDIYds1LeJmE6M7HGsRNRT7FfCaZYGwYI9CCXcWBGA01k4OLq2YLrbdcwbR5mlCyUJyQFQ9PV8//Ptucs55XHg+mEDLUb+yFoQOA6oETWaX8kxnasaKD/uNyxlkTU+F0INkgA+nSU18DEqvexA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3TwK/ut+YbiyazEYFH6b+5m1I4PttqHJCwvPUKUZFFY=; b=Fbkpc8rsfSzjhUlQwVim3XdQ6wjdNhVpd484DpsFWZAXEkT2K3IJOtEBwANUnUORfRDnQWqmiEbqRkowTaF8InaL5/I7dp/OOrBWUEuZ45mFhyWCV80zuvsJJqaGGBIaJY5XgE7JhLYr7gFcegM1BAK2MNjbFGxzo218u1r1An5cKFLe8ZobMHIXPkC63V12cK+6EnuV5+8kA6mem3BNaCQqeUFttp0C2a1I5uqsSdak5xmt8/fcUyk3JHRLHOZQX5V2qKXbezxP0dwuKSFUIKQ9aV3nAxPpqwcbmrUPQ1YAN3jriWdO4/I3tG6afX1ik/ybt52f8MDjNcnwR3zPyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3TwK/ut+YbiyazEYFH6b+5m1I4PttqHJCwvPUKUZFFY=; b=fr3A2qU++Ki22WD8FNIsqEKd7Zxba6VZrOr8KxuyoR7zKnXS5vn2+z/ah1PAdrO9zqVI+5WDMnAWg0n2tRrivzypNkMoyt/RIzo51BRGBMEqYDEOG51Wi6cGUWrCcl1GzVYvj5xBTg+g4ImaCVrElI9e/FY9tQqsYBB4kTfwN8Nwhsqpp6Ep4T1Mzy++bCUiT23EoL0eQZInTtfWNHWVVNoLsWOC92lf/cd60qhE+e/QS0qHEEx+eSPiKlT/spdLv4CutYmIc+WHoWooP2R4rFSV4r+TeqDlF0+193h3gBXTyJDZD8EDHxduMkRwOQgHtzRMX0UwMae1rP5u6/w1vA== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB6384.eurprd03.prod.outlook.com (2603:10a6:800:193::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Wed, 10 Jun 2020 08:13:51 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3066.023; Wed, 10 Jun 2020 08:13:51 +0000 From: Oleksandr Andrushchenko To: "xen-devel@lists.xenproject.org" Subject: HYPERVISOR_console_io + CONSOLEIO_write needs COPY_flush_dcache Thread-Topic: HYPERVISOR_console_io + CONSOLEIO_write needs COPY_flush_dcache Thread-Index: AQHWPv8SOx/IaSMb+EOuO5msEU03SQ== Date: Wed, 10 Jun 2020 08:13:50 +0000 Message-ID: <912a84d1-ca47-9c37-06e7-28bebe696b4d@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d43f555-cda5-4cd9-0c0c-08d80d163580 x-ms-traffictypediagnostic: VI1PR03MB6384: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0430FA5CB7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w7Y+df7maVGUnXcje2hdrMjYYjdJRpBK1WKbwrSGNDLvkrmF1ewrcc0hcysew8MXkf1TqA+fftwxiuuz+lM5n0Nhoo2+QDaUO3yYFygv3tupItoOK9Yq7g43695ZnP6b7It8883oALgmQkkp/BRIsbCmDi7n0jew4MTHMwlZV+Fw6d5IoUnme/iKi/+/yIoQwNryjpHbVfx7Z47KxyjVGp10MObiIS+lf9FbZRPU7aCnV2NC1YWrL30/3ecngSUl6djegKjOsLi1loUDbAYkXj4NNxxQ3Zge0VllfQBZ+AF8HTZu/tTDtVT8UocZmft7A0tstGnAosMXFAXmyCzHpQ23sMdtc3J1FyTa9vtDSnA/t/83y6VVqpF7o+OvxFaJtQo1ANRpqANgpl09NCDOLg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(186003)(76116006)(6486002)(6512007)(66946007)(66446008)(66476007)(64756008)(5660300002)(66556008)(2906002)(86362001)(31696002)(91956017)(31686004)(36756003)(316002)(6916009)(71200400001)(6506007)(2616005)(4744005)(8936002)(83380400001)(478600001)(966005)(8676002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tJIjFpBr5P7shyLHanPGPYWU7WUAtelOwgrHfs12/y70PrDtT7pXA3/BzEkU1T10tI0Rz6XrxfRISWszeZ9w3ZpGcu0BtmuUHu1BgnNpsqY0GzoPdXWAGM0taa5byBS/zkc67jETlbwpVWg+aly/r+P2D+gfLWQI7fyhKZBuweKGbHexht9waEHJt+enHiLVGHhEqKnuYQ2LeeNvUUpdgwIR3BCnSWg9H2A2ggYv9I9UUuRoBLY+ZC8k+uHQV580Ue/qbkvJUFxpwD8fR3v+ij2G5uuhK6FSxemTaUPKGqt0qmwr8qNB4ke9B0twOEx/HAOj1B04ALLPW402UWEGaF3lmPyA22zo/i2bh7zprfunC2I52zQsdO2VBqdiXZE8tKZmoaD+/3M2IjX7TY7GjHwdFh/kdXsRg5Zak63oPKTXxf57dpl4fHfq4PEm0ASYCyq6oS+ydxPykSmPc9FSZ3qM6cugkfnn/8o3/kohDOk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <43305C13D7EF0B45B1D39B593EE930A4@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d43f555-cda5-4cd9-0c0c-08d80d163580 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2020 08:13:50.9032 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EEwnQW5Q89iS2fWhhYzicFfRacQIaD9s+sLICqw6i+ex9Ck29RpLiJgdkSAhyJ7gXblS9mTnUWJB1FGufCNLHjEDWYAY4c7dJ5xZzx+L9mwIZTkIr+YcNWsjmHQnah2O X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6384 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGVsbG8sDQoNCldoaWxlIGFkZGluZyBzdXBwb3J0IGZvciBwYXJhLXZpcnR1YWxpemVkIGJsb2Nr IGRldmljZSBpbiB1LWJvb3QNCg0KSSBmYWNlZCBhbiBpc3N1ZSB3aXRoIEhZUEVSVklTT1JfY29u c29sZV9pbyArIENPTlNPTEVJT193cml0ZS4NCg0KSSB0cmllZCB0byB1c2UgdGhlIGh5cGVyY2Fs bCBkdXJpbmcgTU1VIHNldHVwIHN0YWdlIHdoaWxlIGVuYWJsaW5nIGRhdGEgY2FjaGUNCg0Kb24g YXJtNjQgcGxhdGZvcm0gKGUuZy4gZGF0YSBjYWNoZSBpcyBub3QgeWV0IGVuYWJsZWQpIGFuZCBz YXcgaW4gZ3Vlc3QncyBjb25zb2xlDQoNCmVpdGhlciBvbGQgZGF0YSBvciBzb21lIHNvcnQgb2Yg Z2FyYmFnZS4gUHJpbnRpbmcgY29uc3RhbnQgc3RyaW5ncywganVzdCBsaWtlIG1pbmktb3MNCg0K ZG9lcyBvbiBib290LCB3b3JrcyBhcyBleHBlY3RlZC4gU28sIGxvb2tpbmcgYXQgdGhlIFhlbiBj b2RlIFsxXSBpdCBzZWVtcw0KDQp0aGF0IHdlIHNob3VsZCBjb3B5IGd1ZXN0J3MgYnVmZmVyIHdp dGggQ09QWV9mbHVzaF9kY2FjaGUgc2V0IGluIHRoaXMgY2FzZQ0KDQphcyAodXN1YWxseT8pIHRo aXMgaHlwZXJjYWxsIGlzIHVzZWQgaW4gZ3Vlc3QncyBjb2RlIHdoaWNoIGRvZXNuJ3QgaGF2ZSBh bnkNCg0Kb3RoZXIgbWVhbnMgdG8gcHJpbnQgeWV0LCBlLmcuIGVhcmx5IHByaW50ayBjYXNlLg0K DQpJZiBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBpc3N1ZSBjb3JyZWN0IHRoZW4gSSBjYW4gcHJv YmFibHkgcHJlcGFyZSBhIHBhdGNoLg0KDQpUaGFuayB5b3UsDQoNCk9sZWtzYW5kcg0KDQpbMV0g aHR0cHM6Ly94ZW5iaXRzLnhlbi5vcmcvZ2l0d2ViLz9wPXhlbi5naXQ7YT1ibG9iO2Y9eGVuL2Ry aXZlcnMvY2hhci9jb25zb2xlLmM7aD01NmUyNDgyMWIyZjhkMmI5YmZiOTlkMmFjYjcyMWIwNjI3 NzgzNGNlO2hiPXJlZnMvaGVhZHMvbWFzdGVyI2w1OTcNCg0K From xen-devel-bounces@lists.xenproject.org Wed Jun 10 08:14:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 08:14:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jivs2-0005bE-It; Wed, 10 Jun 2020 08:14:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jivs1-0005b3-Fj for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 08:14:01 +0000 X-Inumbo-ID: 56e14a1c-aaf2-11ea-b3eb-12813bfff9fa Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.77]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 56e14a1c-aaf2-11ea-b3eb-12813bfff9fa; Wed, 10 Jun 2020 08:14:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vzIcmhenhRSN4zxT1i+VqFR3Lcopy3/vdFMgYVbXbVI=; b=jmXwZQM+SFVdxsFzYXX4xawWLPG9slOH+v9Q1twR8BZ1sRu2D7GnH8pb6+Qu+SNCzFFCHI8tenLsT5rDmBcbxq9B4jfHmXpFfddcyJD3ZdTKPda1oFWIVh4TycsR8A5I1a4omEMi0FnzRviYKHnZ7qcWX/BfQU/jBVsd6HU80K4= Received: from AM6P192CA0008.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:83::21) by AM6PR08MB4102.eurprd08.prod.outlook.com (2603:10a6:20b:ab::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Wed, 10 Jun 2020 08:13:59 +0000 Received: from AM5EUR03FT059.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:83:cafe::f) by AM6P192CA0008.outlook.office365.com (2603:10a6:209:83::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Wed, 10 Jun 2020 08:13:59 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT059.mail.protection.outlook.com (10.152.17.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Wed, 10 Jun 2020 08:13:58 +0000 Received: ("Tessian outbound 56dbe829191e:v59"); Wed, 10 Jun 2020 08:13:58 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 13f49898e248673b X-CR-MTA-TID: 64aa7808 Received: from 19e0cbef05e9.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 984AA417-89DE-422D-8740-4BFB35305A90.1; Wed, 10 Jun 2020 08:13:53 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 19e0cbef05e9.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 10 Jun 2020 08:13:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K1APJhB3lZOgxK/tZlmhOCWI8ntrc9cVlP7OYgIf6fO7BkwlYGfgmV0LRawBPf4Rj/ftNtHdSmVa9ShyF/RDA/CZaVFcl88T2k5X3MTk8Nl8PB6/yNEF2Qb83cgKzH1NdqLqqp1S3kaCbVLyeaGWz09t9BPsCy9cIPI9BEDlsdy7VYYEPCm0R15eniLiSJ4lCcb3tbGO3uSnvzpN3h5s+YNXp4pZH6K6iUzJ8MAEXDwvtLVoQKP1yH7Cz8L5SJQZAYHW5pJkLXRY6Exal9SmfA2qNBv6lCyXvzl+6xi/GKkD4jOP226Gm3uxdgP2eB1vWTP/aWkKMFjSvEWlTUGvUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vzIcmhenhRSN4zxT1i+VqFR3Lcopy3/vdFMgYVbXbVI=; b=h8vhlpSgqwVBXj0HuPeJa8EchqHT8WmDL+dJfFThUt2vYu77KxF7JU0Qai5CsSUd37zOiqx2aXbIFAc05y86glrwMbSaBhfNrnkyR+V0RXlpvXeno4Uch/RVspLAyX5Tr+bNac0wu6Nc4faZuiKYI38muYJRLt4tfwTB2C77eFRsINyuO/IrZWjqDHg3q0pA+p4gRh9Q3gKXUw4Hc2GrHl5b2s6EspJsz+iu00MfqMV2JReFTX96nCf8Ga/+rRB4zuTHWhMfahVz9c/+qNgWIVD2U2IqcXPLrotI1PhoCVr/G0OEMFdIROtJjJtQYlUUzJWoY3AK1PMECvOFe1L8Kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vzIcmhenhRSN4zxT1i+VqFR3Lcopy3/vdFMgYVbXbVI=; b=jmXwZQM+SFVdxsFzYXX4xawWLPG9slOH+v9Q1twR8BZ1sRu2D7GnH8pb6+Qu+SNCzFFCHI8tenLsT5rDmBcbxq9B4jfHmXpFfddcyJD3ZdTKPda1oFWIVh4TycsR8A5I1a4omEMi0FnzRviYKHnZ7qcWX/BfQU/jBVsd6HU80K4= Received: from AM0PR08MB3682.eurprd08.prod.outlook.com (2603:10a6:208:fb::27) by AM0PR08MB5027.eurprd08.prod.outlook.com (2603:10a6:208:15c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.23; Wed, 10 Jun 2020 08:13:50 +0000 Received: from AM0PR08MB3682.eurprd08.prod.outlook.com ([fe80::b572:771:2750:14ed]) by AM0PR08MB3682.eurprd08.prod.outlook.com ([fe80::b572:771:2750:14ed%5]) with mapi id 15.20.3088.019; Wed, 10 Jun 2020 08:13:50 +0000 From: Bertrand Marquis To: CodeWiz2280 Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgIAAJpOAgABE7QCABAZcAIAAQRIAgAA9oACAAXYtAIAAD3sAgAAFaoCAABUzgIAAB/uAgAAD1ICAACeSgIAAyuwA Date: Wed, 10 Jun 2020 08:13:50 +0000 Message-ID: References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a2315132-de59-4645-491f-08d80d163a1c x-ms-traffictypediagnostic: AM0PR08MB5027:|AM6PR08MB4102: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0430FA5CB7 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: AnMjGlN7hkkol54XoUjVY/U4WP+pEsbEbeui3DKRzD3ROQVSy86X8BJBDAto4erK9M+0r/T/eFeZeUlCj3KL3Us0h+fKj6UhS1Zq08nXcZ7HjYRIfQtWy+unGtK3a4ucUSWJ2Wf6HYUqEkxLtWa+S+cG62OORxi7iHgttIV0SZkK9cr+7ksLYvIx6amwnxnW2kssFRPjE6cvpS08l4NxGWB/R+9c7tdTY5lLM7HhQBhIIIejj+uksPZzv7ySDOCxFqdDGobGf04SY7+tH7f641lekkEFLNJJozw4h+jNepExCujOdu+R//AnSZyZHgl9RQLfZcAHU2fRUDC84GunFQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3682.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(376002)(136003)(346002)(366004)(33656002)(3480700007)(26005)(36756003)(91956017)(6512007)(316002)(54906003)(6506007)(6486002)(2616005)(478600001)(83380400001)(5660300002)(8676002)(66946007)(2906002)(66556008)(6916009)(8936002)(76116006)(64756008)(186003)(66446008)(66476007)(53546011)(7116003)(86362001)(71200400001)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: iyH+ecw6QfdKJL1LjhT2F3tpVzsixgsllWaHjYMWEXTuHXApM8UwldZE8CNImclzUElJJIhRmkCE2FpqXSu6rODjCvzYFVGvb2O0LNtOPMMc6pbAtS5RZ3ACS9VOFZ4DEqlLWrW4HIWgb490oJj4ou3tot51SZz0Bw7dqgLcj0XOW9U791D2EQZ1oU8kEwtFLhqG2UbFR98xNXzti/q37+brZgNImKlhxo7tpVcHxGIAqsNDmdmftMNrJN/QMSyTurpVpzObLBWv6Y4ezyEoQQ+fUd6wpZYp8eqIVd/NvA3Aj0Td2IJ1hLqCV5RYe3kho7TdPoLCMY954qnBTMBX80z4LW7zYgqdVI2qHQRfYsUhf27zW3jnrB+heqW87xcunQJ0WE8Luroix5SdlPtQB+azA8seKmCVrnbJrENgVYt+NiuIeeel0fbhamQH4eRCqyX4mYOoyTkx5EOFwCq2My7QpwIOCWXWdT2lf8GsyyA= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <6DE6681C948CAC4EBC5804755209258D@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5027 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT059.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(396003)(39860400002)(136003)(46966005)(186003)(26005)(53546011)(336012)(6486002)(2906002)(6506007)(82310400002)(8676002)(6862004)(86362001)(3480700007)(7116003)(8936002)(4326008)(2616005)(83380400001)(6512007)(36906005)(81166007)(356005)(82740400003)(5660300002)(478600001)(54906003)(33656002)(70586007)(316002)(70206006)(36756003)(47076004); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 0ca646ed-ee15-4dda-bcb4-08d80d16355f X-Forefront-PRVS: 0430FA5CB7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YZRKJG8NlyDTUCJz/lDpLOV4d9Z/kisLx5Gbwwp31MLprYm5K7wVS2NPZxIQT/S5T5tcsJlTvh7/Ri9sJLRD1B/orcJ2YPLL6k3RAZyYE0j2SDsjvhzs7fuTboj9F/bK8vg0UGPHbXcpN1F7Dkm5JfKHiGV5w9xCWziturTUNws3XGeLsPOQiNFpYY/ywXn1DrLhZ7htOkDLnPVhrPimbKcXghE9sInZagDjM+Tg8XffOnP/WCvBEK1rigwin6h/NoQXg7WR1rXqcyoLj+zDy6ciFW0wfIpc9JXdQ+2Uwo5aFNf+oKzSQvOP1kHnauv8wBw/DvfQHw6gAOvmIda9uo9sUFG0N0K6i3khoSm+2X8yVj/s24orBs9UhZ4xfoCAOtjDjuh+Xl5c8Y8SA0H1qA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2020 08:13:58.7526 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a2315132-de59-4645-491f-08d80d163a1c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4102 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , nd , Stefano Stabellini , Julien Grall , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, > On 9 Jun 2020, at 21:07, CodeWiz2280 wrote: >=20 > On Tue, Jun 9, 2020 at 1:45 PM Marc Zyngier wrote: >>=20 >> Hi Julien, >>=20 >> On 2020-06-09 18:32, Julien Grall wrote: >>> (+ Marc) >>>=20 >>> On 09/06/2020 18:03, Bertrand Marquis wrote: >>>> Hi >>>>=20 >>>>> On 9 Jun 2020, at 16:47, Julien Grall wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 09/06/2020 16:28, Bertrand Marquis wrote: >>>>>> Hi, >>>>>>> On 9 Jun 2020, at 15:33, CodeWiz2280 wrote: >>>>>>>=20 >>>>>>> There does appear to be a secondary (CIC) controller that can >>>>>>> forward >>>>>>> events to the GIC-400 and EDMA controllers for the keystone 2 >>>>>>> family. >>>>>>> Admittedly, i'm not sure how it is being used with regards to the >>>>>>> peripherals. I only see mention of the GIC-400 parent for the >>>>>>> devices >>>>>>> in the device tree. Maybe Bertrand has a better idea on whether >>>>>>> any >>>>>>> peripherals go through the CIC first? I see that gic_interrupt () >>>>>>> fires once in Xen, which calls doIRQ to push out the virtual >>>>>>> interrupt >>>>>>> to the dom0 kernel. The dom0 kernel then handles the interrupt and >>>>>>> returns, but gic_interrupt() never fires again in Xen. >>>>>> I do not remember of any CIC but the behaviour definitely look like >>>>>> an interrupt acknowledge problem. >>>>>> Could you try the following: >>>>>> --- a/xen/arch/arm/gic-v2.c >>>>>> +++ b/xen/arch/arm/gic-v2.c >>>>>> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc >>>>>> *desc) >>>>>> /* Lower the priority of the IRQ */ >>>>>> gicv2_eoi_irq(desc); >>>>>> /* Deactivation happens in maintenance interrupt / via GICV */ >>>>>> + >>>>>> + /* Test for Keystone2 */ >>>>>> + gicv2_dir_irq(desc); >>>>>> } >>>>>> I think the problem I had was related to the vgic not deactivating >>>>>> properly the interrupt. >>>>>=20 >>>>> Are you suggesting the guest EOI is not properly forwarded to the >>>>> hardware when LR.HW is set? If so, this could possibly be workaround >>>>> in Xen by raising a maintenance interrupt every time a guest EOI an >>>>> interrupt. >>>>=20 >>>> Agree the maintenance interrupt would definitely be the right solution >>> I would like to make sure we aren't missing anything in Xen first. >>> From what you said, you have encountered this issue in the past with a >>> different hypervisor. So it doesn't look like to be Xen related. >>>=20 >>> Was there any official statement from TI? If not, can we try to get >>> some input from them first? > Thank you all for your support so far, its really appreciated. Is > there a quick patch that I can try with this maintenance interrupt to > get the level interrupts working as well? I can pose the question to > TI but would like to close the loop and make sure there are no other > issues that pop out first. If you can that would be good to ask TI because I did work on the Keystone2= a while ago and they might have a firmware solution for that. Bertrand >>>=20 >>> @Marc, I know you dropped 32-bit support in KVM recently :). Although, >>=20 >> Yes! Victory is mine! Freedom from the shackles of 32bit, at last! :D >>=20 >>> I was wondering if you heard about any potential issue with guest EOI >>> not forwarded to the host. This is on TI Keystone (Cortex A-15). >>=20 >> Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway >> all run just fine with guest EOI), and GIC-400 is a pretty solid piece >> of kit (it is just sloooooow...). >>=20 >> Thinking of it, you would see something like that if the GIC was seeing >> the writes coming from the guest as secure instead of NS (cue the early >> firmware on XGene that exposed the wrong side of GIC-400). >>=20 >> Is there some kind of funky bridge between the CPU and the GIC? >>=20 >> M. >> -- >> Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Wed Jun 10 08:20:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 08:20:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jivyf-0006Xq-Dx; Wed, 10 Jun 2020 08:20:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jivye-0006Xl-6E for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 08:20:52 +0000 X-Inumbo-ID: 4b8887c4-aaf3-11ea-b3ed-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4b8887c4-aaf3-11ea-b3ed-12813bfff9fa; Wed, 10 Jun 2020 08:20:51 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 74F1F2064C; Wed, 10 Jun 2020 08:20:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591777250; bh=hafAu8H+bcdMTAQQWhBcjfra9YfKGmt8aDKcWr+EsFw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ZPRoPWXu9DMS6DbQyZi+VvFTQvVEB/1Uyci2Cx53X5f63RfOeYxpnSRVgiVXIdVIh DBcQdPmUeCc8vjzVThMPf72CJayCxxJ0uNkR/rx1vw7GfOC7GpPwomf1DkjWmAt3u9 2sLVZeU5htJ2U/idKW9QuXXdWf3EIRId4l0wPaUg= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jivyb-001ieD-0Y; Wed, 10 Jun 2020 09:20:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 10 Jun 2020 09:20:48 +0100 From: Marc Zyngier To: Bertrand Marquis Subject: Re: Keystone Issue In-Reply-To: <32FA85C2-7685-49D2-875B-9FA1C138C92A@arm.com> References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <32FA85C2-7685-49D2-875B-9FA1C138C92A@arm.com> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: Bertrand.Marquis@arm.com, julien@xen.org, codewiz2280@gmail.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall , CodeWiz2280 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-10 09:06, Bertrand Marquis wrote: > Hi, > >> On 9 Jun 2020, at 18:45, Marc Zyngier wrote: >> >> Hi Julien, >> >> On 2020-06-09 18:32, Julien Grall wrote: >>> (+ Marc) >>> On 09/06/2020 18:03, Bertrand Marquis wrote: >>>> Hi >>>>> On 9 Jun 2020, at 16:47, Julien Grall wrote: >>>>> On 09/06/2020 16:28, Bertrand Marquis wrote: >>>>>> Hi, >>>>>>> On 9 Jun 2020, at 15:33, CodeWiz2280 >>>>>>> wrote: >>>>>>> There does appear to be a secondary (CIC) controller that can >>>>>>> forward >>>>>>> events to the GIC-400 and EDMA controllers for the keystone 2 >>>>>>> family. >>>>>>> Admittedly, i'm not sure how it is being used with regards to the >>>>>>> peripherals. I only see mention of the GIC-400 parent for the >>>>>>> devices >>>>>>> in the device tree. Maybe Bertrand has a better idea on whether >>>>>>> any >>>>>>> peripherals go through the CIC first? I see that gic_interrupt >>>>>>> () >>>>>>> fires once in Xen, which calls doIRQ to push out the virtual >>>>>>> interrupt >>>>>>> to the dom0 kernel. The dom0 kernel then handles the interrupt >>>>>>> and >>>>>>> returns, but gic_interrupt() never fires again in Xen. >>>>>> I do not remember of any CIC but the behaviour definitely look >>>>>> like an interrupt acknowledge problem. >>>>>> Could you try the following: >>>>>> --- a/xen/arch/arm/gic-v2.c >>>>>> +++ b/xen/arch/arm/gic-v2.c >>>>>> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct >>>>>> irq_desc *desc) >>>>>> /* Lower the priority of the IRQ */ >>>>>> gicv2_eoi_irq(desc); >>>>>> /* Deactivation happens in maintenance interrupt / via GICV >>>>>> */ >>>>>> + >>>>>> + /* Test for Keystone2 */ >>>>>> + gicv2_dir_irq(desc); >>>>>> } >>>>>> I think the problem I had was related to the vgic not deactivating >>>>>> properly the interrupt. >>>>> Are you suggesting the guest EOI is not properly forwarded to the >>>>> hardware when LR.HW is set? If so, this could possibly be >>>>> workaround in Xen by raising a maintenance interrupt every time a >>>>> guest EOI an interrupt. >>>> Agree the maintenance interrupt would definitely be the right >>>> solution >>> I would like to make sure we aren't missing anything in Xen first. >>> From what you said, you have encountered this issue in the past with >>> a >>> different hypervisor. So it doesn't look like to be Xen related. >>> Was there any official statement from TI? If not, can we try to get >>> some input from them first? >>> @Marc, I know you dropped 32-bit support in KVM recently :). >>> Although, >> >> Yes! Victory is mine! Freedom from the shackles of 32bit, at last! :D >> >>> I was wondering if you heard about any potential issue with guest EOI >>> not forwarded to the host. This is on TI Keystone (Cortex A-15). >> >> Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda >> Midway all run just fine with guest EOI), and GIC-400 is a pretty >> solid piece of kit (it is just sloooooow...). >> >> Thinking of it, you would see something like that if the GIC was >> seeing the writes coming from the guest as secure instead of NS (cue >> the early firmware on XGene that exposed the wrong side of GIC-400). >> >> Is there some kind of funky bridge between the CPU and the GIC? > > Yes the behaviour I had was coherent with the GIC seeing the processor > in secure mode and not in non secure hence making the VGIC ack non > functional. Can you please check this with the TI folks? It may be fixable if the bridge is SW configurable. > So the only way to solve this is actually to do the interrupt > deactivate inside Xen (using a maintenance interrupt). That's a terrible hack, and one that would encourage badly integrated HW. I appreciate the need to "make things work", but I'd be wary of putting this in released SW. Broken HW must die. I have written more than my share of these terrible hacks (see TX1 support), and I deeply regret it, as it has only given Si vendors an excuse not to fix things. > I remember that I also had to do something specific for the > configuration of edge/level and priorities to have an almost proper > behaviour. Well, the moment the GIC observes secure accesses when they should be non-secure, all bets are off and you have to resort to the above hacks. The fun part is that if you have secure SW running on this platform, you can probably DoS it from non-secure. It's good, isn't it? > Sadly I have no access to the code anymore, so I would need to guess > back what that was.. I'd say this *is* a good thing. M. -- Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Wed Jun 10 08:39:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 08:39:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiwGb-0007bp-3W; Wed, 10 Jun 2020 08:39:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiwGa-0007bk-25 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 08:39:24 +0000 X-Inumbo-ID: e1c353de-aaf5-11ea-8496-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.80]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e1c353de-aaf5-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 08:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lO3CRl9PscQGePv4XrnVBZIHt7KDUHval1jiEEtxImg=; b=nsUMF9GeD0RXMn94FtUI2kc3Zu1zbCVvxXYBzcCRC19bB+bBHfNB7BErhzU5S7tp/q0xVo4Ue++T3yreqyr6tTpQcLW9w8tHq37mE3bWp5sV9XmIXUJ+U+PM6o+sbaOAX9wlHVEIUQoE4C8ddcH77ORitW3M8EiKdOQVETBVsbE= Received: from AM6P191CA0042.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:7f::19) by AM6PR08MB4326.eurprd08.prod.outlook.com (2603:10a6:20b:b9::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Wed, 10 Jun 2020 08:39:20 +0000 Received: from AM5EUR03FT028.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:7f:cafe::ad) by AM6P191CA0042.outlook.office365.com (2603:10a6:209:7f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Wed, 10 Jun 2020 08:39:20 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT028.mail.protection.outlook.com (10.152.16.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Wed, 10 Jun 2020 08:39:19 +0000 Received: ("Tessian outbound 3e82c366635e:v59"); Wed, 10 Jun 2020 08:39:19 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: a6c3d5cb7fb34371 X-CR-MTA-TID: 64aa7808 Received: from c7125f9e284b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id EB231C3E-F32E-4F01-88E9-9721C13F0107.1; Wed, 10 Jun 2020 08:39:14 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c7125f9e284b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 10 Jun 2020 08:39:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lx8L9kjPjLXRmFDQS1qOlhcNWW40BARXstmIkU8VBi8UL2T/1Xj3FPpghDDOwEhqLUiCt1hiG+1leCByBAXr8IDa8OjwPciO8Pq96IXggOM87148VA7pkLIgU4u2oHjl9+KCyzB9YRp8A3e0auJTBzRXaQx94qJ3vnOJ1S0h6tEO/y6JNYCqOKiicRa86MbAWsC/ebiEuJR8eKvamixs+eu6imGH2l5WqD5EByQIpgxt44avRAPH5vQTpBhmRS/2cEL3Ki/34nYChL5Qh/G8I4/abBQFP20DFUKd8UoZWJiFEy6P1Out66vohC9kPo/V/18/GFcOBUH1qdvgQP+d9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lO3CRl9PscQGePv4XrnVBZIHt7KDUHval1jiEEtxImg=; b=a5DGwZ/KHqNE2yGPnRWGCnLqi+BOxOJYcO3lJPBsbFzulFMItZNTbjMwGwrCC+F0d1/1x9ub2HK6RL4wnqCM4+JFrR0EH0zOm8CKiReGjVx+ExH2e+/J9q5HMYyUPSajgi7nO105Y8Gmx9+5hrbG8SIIfokHOXcSL8/K+pGN5H+3FJWO0Fe82JFDzrMYVSHYm7c4yHZ0JtaW1qdH6014G/TP44OaqlTVtOXE7HVU89ey26tYo4wXjwoSDl564JSgPyM6v1cn9NgqI91zi+MU82SnScNQgEVHY9qK17H9KDjgM+D6v+63VANMOeiJ1+ygCjDwcKYxoQfqhZtYL6yP6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lO3CRl9PscQGePv4XrnVBZIHt7KDUHval1jiEEtxImg=; b=nsUMF9GeD0RXMn94FtUI2kc3Zu1zbCVvxXYBzcCRC19bB+bBHfNB7BErhzU5S7tp/q0xVo4Ue++T3yreqyr6tTpQcLW9w8tHq37mE3bWp5sV9XmIXUJ+U+PM6o+sbaOAX9wlHVEIUQoE4C8ddcH77ORitW3M8EiKdOQVETBVsbE= Received: from AM0PR08MB3682.eurprd08.prod.outlook.com (2603:10a6:208:fb::27) by AM0PR08MB4546.eurprd08.prod.outlook.com (2603:10a6:208:148::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Wed, 10 Jun 2020 08:39:11 +0000 Received: from AM0PR08MB3682.eurprd08.prod.outlook.com ([fe80::b572:771:2750:14ed]) by AM0PR08MB3682.eurprd08.prod.outlook.com ([fe80::b572:771:2750:14ed%5]) with mapi id 15.20.3088.019; Wed, 10 Jun 2020 08:39:11 +0000 From: Bertrand Marquis To: Marc Zyngier Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgIAAJpOAgABE7QCABAZcAIAAQRIAgAA9oACAAXYtAIAAD3sAgAAFaoCAABUzgIAAB/uAgAAD1ICAAPCKAIAAA+YAgAAFIgA= Date: Wed, 10 Jun 2020 08:39:11 +0000 Message-ID: <5C2DB5F7-832E-4B02-A99A-8B5C7CEC7645@arm.com> References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <32FA85C2-7685-49D2-875B-9FA1C138C92A@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 98b54938-3f7c-4f8f-69c9-08d80d19c4bb x-ms-traffictypediagnostic: AM0PR08MB4546:|AM6PR08MB4326: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:8273; x-forefront-prvs: 0430FA5CB7 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 7LrZXBgRvhpi00uGTIL1kwf7eYANSke0aKjOmGH7sVUBvxRT0Idjf34stSf/K/cZGfYmFRQAcALPupA/i2569j8/MYmVO2b3zIPlIoBRhJf/pmKoPcgRacZirnFhLhElLf8qwggyC98Az6sWO4OLmeVkieYsxTdAj+rYuWzYICt/hJmegxOVCw+2Vf2DfpC+38I6GtbNWuNbxtVV/Jq4X0qzXlI4e7ml5oSu5ggFjzV/aHI9v1WyvXAaTn2q8qDyfhY8QIYo4X8VmqqNsIwaPWT8dSv2SWP9MDj2E93b5eefT7vOK3mZlIPTxFIByQs4zPXRQnBQNAxezRyTMnKgwQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3682.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(396003)(366004)(39860400002)(6916009)(8936002)(66446008)(64756008)(66556008)(66946007)(6486002)(76116006)(91956017)(71200400001)(66476007)(478600001)(53546011)(5660300002)(4326008)(186003)(86362001)(33656002)(26005)(6506007)(8676002)(7116003)(3480700007)(316002)(83380400001)(36756003)(6512007)(2616005)(2906002)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: IBI+AlGLNh4/uyzo2RGSQcBUVhutyPjXWoylPiV3ChA1l9/8RAyYNsTiHwEJyVMvxSqC4E7QtwAD1LAU9biCw/8lxfZRyFmAy9fBf3CTBoYotKiIPXMnTaNSwD9kfPoFm/4aUPQnMqy/19MXnD8+isv0BLtb3RszDy1GX9TbViYVoTvfkCR/YERPUA6t1A4r0Xz9oZ00USTmNzfwIVoMk2Fx/Gr7U5+AETVxjHYrXMRE1DH75/1KQKs1HauKEi0/ZVXhzGDa1QU97tR6AH/dL1/h4EH2y7a9el9BziZsIhTZKIFNTFq8cVyDrm34AuLQCYr8fBNK6YGcFjiudJueJPzYGjd+zNDhrL2quLc2spjYtxGBxxK3bdODEgwGXQH7RcoOeP7T40wT+//dWI6pVggIv96qQIfO3+QeeV71ymDQi6X/YhAagc11gKzXICqbr13zgfOi4K6/AWhTdzp7w+N5oKOC3Rpa9HwhWx6o9V8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <703A9DB4D97A464CA57DB67DE4131224@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4546 Original-Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT028.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(396003)(39860400002)(46966005)(70586007)(81166007)(70206006)(2906002)(6506007)(6862004)(316002)(6512007)(26005)(54906003)(3480700007)(186003)(53546011)(6486002)(478600001)(4326008)(7116003)(47076004)(83380400001)(336012)(36756003)(33656002)(82740400003)(356005)(82310400002)(2616005)(8676002)(8936002)(36906005)(86362001)(5660300002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: f74b02dd-d0c9-4b46-d345-08d80d19bfd6 X-Forefront-PRVS: 0430FA5CB7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vbpbCYCe70u7y15zYKjjB8jjhIMxdG5G5jaM4C/2nmOP8ve0JGim47z8hGbmyM89elPwqGGt+MBvMIE6dtB4xUTjU142giCtizPVR2ID50Y3lfNWdnKYWOJlQbPxCFa/+29MvR7B5zKaJ3fP3DeikNOIC28WW8TJFLSeJNhHKoIQgClHg5lUKoSV2stn4ujdtGtEayTsoihlYjlOwk2d30XEpl5AbB81HI4/k5hlmAvHO0y4RVeGZEi0F1SvbRWSTJjzYhqSWh9c0rsandPHjc6genIGdOazjZoHEDSgC5M4eSa9eS9XIi+AdMvgx8UnA/kwVsSzyJ7z7Axvwv3IbuCAS/ybs+l7k+99wOJxsVFelD3Wd0uG6s6mtMPgoWIzpBnOgtp3fQpDEtyHEgj14Q== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2020 08:39:19.8135 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 98b54938-3f7c-4f8f-69c9-08d80d19c4bb X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4326 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall , CodeWiz2280 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gMTAgSnVuIDIwMjAsIGF0IDA5OjIwLCBNYXJjIFp5bmdpZXIgPG1hekBrZXJuZWwu b3JnPiB3cm90ZToNCj4gDQo+IE9uIDIwMjAtMDYtMTAgMDk6MDYsIEJlcnRyYW5kIE1hcnF1aXMg d3JvdGU6DQo+PiBIaSwNCj4+PiBPbiA5IEp1biAyMDIwLCBhdCAxODo0NSwgTWFyYyBaeW5naWVy IDxtYXpAa2VybmVsLm9yZz4gd3JvdGU6DQo+Pj4gSGkgSnVsaWVuLA0KPj4+IE9uIDIwMjAtMDYt MDkgMTg6MzIsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+Pj4gKCsgTWFyYykNCj4+Pj4gT24gMDkv MDYvMjAyMCAxODowMywgQmVydHJhbmQgTWFycXVpcyB3cm90ZToNCj4+Pj4+IEhpDQo+Pj4+Pj4g T24gOSBKdW4gMjAyMCwgYXQgMTY6NDcsIEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+IHdy b3RlOg0KPj4+Pj4+IE9uIDA5LzA2LzIwMjAgMTY6MjgsIEJlcnRyYW5kIE1hcnF1aXMgd3JvdGU6 DQo+Pj4+Pj4+IEhpLA0KPj4+Pj4+Pj4gT24gOSBKdW4gMjAyMCwgYXQgMTU6MzMsIENvZGVXaXoy MjgwIDxjb2Rld2l6MjI4MEBnbWFpbC5jb20+IHdyb3RlOg0KPj4+Pj4+Pj4gVGhlcmUgZG9lcyBh cHBlYXIgdG8gYmUgYSBzZWNvbmRhcnkgKENJQykgY29udHJvbGxlciB0aGF0IGNhbiBmb3J3YXJk DQo+Pj4+Pj4+PiBldmVudHMgdG8gdGhlIEdJQy00MDAgYW5kIEVETUEgY29udHJvbGxlcnMgZm9y IHRoZSBrZXlzdG9uZSAyIGZhbWlseS4NCj4+Pj4+Pj4+IEFkbWl0dGVkbHksIGknbSBub3Qgc3Vy ZSBob3cgaXQgaXMgYmVpbmcgdXNlZCB3aXRoIHJlZ2FyZHMgdG8gdGhlDQo+Pj4+Pj4+PiBwZXJp cGhlcmFscy4gIEkgb25seSBzZWUgbWVudGlvbiBvZiB0aGUgR0lDLTQwMCBwYXJlbnQgZm9yIHRo ZSBkZXZpY2VzDQo+Pj4+Pj4+PiBpbiB0aGUgZGV2aWNlIHRyZWUuICBNYXliZSBCZXJ0cmFuZCBo YXMgYSBiZXR0ZXIgaWRlYSBvbiB3aGV0aGVyIGFueQ0KPj4+Pj4+Pj4gcGVyaXBoZXJhbHMgZ28g dGhyb3VnaCB0aGUgQ0lDIGZpcnN0PyAgSSBzZWUgdGhhdCBnaWNfaW50ZXJydXB0ICgpDQo+Pj4+ Pj4+PiBmaXJlcyBvbmNlIGluIFhlbiwgd2hpY2ggY2FsbHMgZG9JUlEgdG8gcHVzaCBvdXQgdGhl IHZpcnR1YWwgaW50ZXJydXB0DQo+Pj4+Pj4+PiB0byB0aGUgZG9tMCBrZXJuZWwuICBUaGUgZG9t MCBrZXJuZWwgdGhlbiBoYW5kbGVzIHRoZSBpbnRlcnJ1cHQgYW5kDQo+Pj4+Pj4+PiByZXR1cm5z LCBidXQgZ2ljX2ludGVycnVwdCgpIG5ldmVyIGZpcmVzIGFnYWluIGluIFhlbi4NCj4+Pj4+Pj4g SSBkbyBub3QgcmVtZW1iZXIgb2YgYW55IENJQyBidXQgdGhlIGJlaGF2aW91ciBkZWZpbml0ZWx5 IGxvb2sgbGlrZSBhbiBpbnRlcnJ1cHQgYWNrbm93bGVkZ2UgcHJvYmxlbS4NCj4+Pj4+Pj4gQ291 bGQgeW91IHRyeSB0aGUgZm9sbG93aW5nOg0KPj4+Pj4+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZ2lj LXYyLmMNCj4+Pj4+Pj4gKysrIGIveGVuL2FyY2gvYXJtL2dpYy12Mi5jDQo+Pj4+Pj4+IEBAIC02 NjcsNiArNjY3LDkgQEAgc3RhdGljIHZvaWQgZ2ljdjJfZ3Vlc3RfaXJxX2VuZChzdHJ1Y3QgaXJx X2Rlc2MgKmRlc2MpDQo+Pj4+Pj4+ICAgICAvKiBMb3dlciB0aGUgcHJpb3JpdHkgb2YgdGhlIElS USAqLw0KPj4+Pj4+PiAgICAgZ2ljdjJfZW9pX2lycShkZXNjKTsNCj4+Pj4+Pj4gICAgIC8qIERl YWN0aXZhdGlvbiBoYXBwZW5zIGluIG1haW50ZW5hbmNlIGludGVycnVwdCAvIHZpYSBHSUNWICov DQo+Pj4+Pj4+ICsNCj4+Pj4+Pj4gKyAgICAvKiBUZXN0IGZvciBLZXlzdG9uZTIgKi8NCj4+Pj4+ Pj4gKyAgICBnaWN2Ml9kaXJfaXJxKGRlc2MpOw0KPj4+Pj4+PiB9DQo+Pj4+Pj4+IEkgdGhpbmsg dGhlIHByb2JsZW0gSSBoYWQgd2FzIHJlbGF0ZWQgdG8gdGhlIHZnaWMgbm90IGRlYWN0aXZhdGlu ZyBwcm9wZXJseSB0aGUgaW50ZXJydXB0Lg0KPj4+Pj4+IEFyZSB5b3Ugc3VnZ2VzdGluZyB0aGUg Z3Vlc3QgRU9JIGlzIG5vdCBwcm9wZXJseSBmb3J3YXJkZWQgdG8gdGhlIGhhcmR3YXJlIHdoZW4g TFIuSFcgaXMgc2V0PyBJZiBzbywgdGhpcyBjb3VsZCBwb3NzaWJseSBiZSB3b3JrYXJvdW5kIGlu IFhlbiBieSByYWlzaW5nIGEgbWFpbnRlbmFuY2UgaW50ZXJydXB0IGV2ZXJ5IHRpbWUgYSBndWVz dCBFT0kgYW4gaW50ZXJydXB0Lg0KPj4+Pj4gQWdyZWUgdGhlIG1haW50ZW5hbmNlIGludGVycnVw dCB3b3VsZCBkZWZpbml0ZWx5IGJlIHRoZSByaWdodCBzb2x1dGlvbg0KPj4+PiBJIHdvdWxkIGxp a2UgdG8gbWFrZSBzdXJlIHdlIGFyZW4ndCBtaXNzaW5nIGFueXRoaW5nIGluIFhlbiBmaXJzdC4N Cj4+Pj4gRnJvbSB3aGF0IHlvdSBzYWlkLCB5b3UgaGF2ZSBlbmNvdW50ZXJlZCB0aGlzIGlzc3Vl IGluIHRoZSBwYXN0IHdpdGggYQ0KPj4+PiBkaWZmZXJlbnQgaHlwZXJ2aXNvci4gU28gaXQgZG9l c24ndCBsb29rIGxpa2UgdG8gYmUgWGVuIHJlbGF0ZWQuDQo+Pj4+IFdhcyB0aGVyZSBhbnkgb2Zm aWNpYWwgc3RhdGVtZW50IGZyb20gVEk/IElmIG5vdCwgY2FuIHdlIHRyeSB0byBnZXQNCj4+Pj4g c29tZSBpbnB1dCBmcm9tIHRoZW0gZmlyc3Q/DQo+Pj4+IEBNYXJjLCBJIGtub3cgeW91IGRyb3Bw ZWQgMzItYml0IHN1cHBvcnQgaW4gS1ZNIHJlY2VudGx5IDopLiBBbHRob3VnaCwNCj4+PiBZZXMh IFZpY3RvcnkgaXMgbWluZSEgRnJlZWRvbSBmcm9tIHRoZSBzaGFja2xlcyBvZiAzMmJpdCwgYXQg bGFzdCEgOkQNCj4+Pj4gSSB3YXMgd29uZGVyaW5nIGlmIHlvdSBoZWFyZCBhYm91dCBhbnkgcG90 ZW50aWFsIGlzc3VlIHdpdGggZ3Vlc3QgRU9JDQo+Pj4+IG5vdCBmb3J3YXJkZWQgdG8gdGhlIGhv c3QuIFRoaXMgaXMgb24gVEkgS2V5c3RvbmUgKENvcnRleCBBLTE1KS4NCj4+PiBOb3QgdGhhdCBJ IGtub3cgb2YuIEEtMTUgZGVmaW5pdGVseSB3b3JrcyAoVEMyLCBUZWdyYS1LMSwgQ2FseGVkYSBN aWR3YXkgYWxsIHJ1biBqdXN0IGZpbmUgd2l0aCBndWVzdCBFT0kpLCBhbmQgR0lDLTQwMCBpcyBh IHByZXR0eSBzb2xpZCBwaWVjZSBvZiBraXQgKGl0IGlzIGp1c3Qgc2xvb29vb293Li4uKS4NCj4+ PiBUaGlua2luZyBvZiBpdCwgeW91IHdvdWxkIHNlZSBzb21ldGhpbmcgbGlrZSB0aGF0IGlmIHRo ZSBHSUMgd2FzIHNlZWluZyB0aGUgd3JpdGVzIGNvbWluZyBmcm9tIHRoZSBndWVzdCBhcyBzZWN1 cmUgaW5zdGVhZCBvZiBOUyAoY3VlIHRoZSBlYXJseSBmaXJtd2FyZSBvbiBYR2VuZSB0aGF0IGV4 cG9zZWQgdGhlIHdyb25nIHNpZGUgb2YgR0lDLTQwMCkuDQo+Pj4gSXMgdGhlcmUgc29tZSBraW5k IG9mIGZ1bmt5IGJyaWRnZSBiZXR3ZWVuIHRoZSBDUFUgYW5kIHRoZSBHSUM/DQo+PiBZZXMgdGhl IGJlaGF2aW91ciBJIGhhZCB3YXMgY29oZXJlbnQgd2l0aCB0aGUgR0lDIHNlZWluZyB0aGUgcHJv Y2Vzc29yDQo+PiBpbiBzZWN1cmUgbW9kZSBhbmQgbm90IGluIG5vbiBzZWN1cmUgaGVuY2UgbWFr aW5nIHRoZSBWR0lDIGFjayBub24NCj4+IGZ1bmN0aW9uYWwuDQo+IA0KPiBDYW4geW91IHBsZWFz ZSBjaGVjayB0aGlzIHdpdGggdGhlIFRJIGZvbGtzPyBJdCBtYXkgYmUgZml4YWJsZSBpZg0KPiB0 aGUgYnJpZGdlIGlzIFNXIGNvbmZpZ3VyYWJsZS4NCg0KQXQgdGhhdCB0aW1lIHRoZXkgZGlkIG5v dCDigJxvZmZlcuKAnSB0aGF0IHNvbHV0aW9uIGJ1dCBkb2VzIG5vdCBtZWFuIGl0IGlzIG5vdCBw b3NzaWJsZS4NCg0KPiANCj4+IFNvIHRoZSBvbmx5IHdheSB0byBzb2x2ZSB0aGlzIGlzIGFjdHVh bGx5IHRvIGRvIHRoZSBpbnRlcnJ1cHQNCj4+IGRlYWN0aXZhdGUgaW5zaWRlIFhlbiAodXNpbmcg YSBtYWludGVuYW5jZSBpbnRlcnJ1cHQpLg0KPiANCj4gVGhhdCdzIGEgdGVycmlibGUgaGFjaywg YW5kIG9uZSB0aGF0IHdvdWxkIGVuY291cmFnZSBiYWRseSBpbnRlZ3JhdGVkIEhXLg0KPiBJIGFw cHJlY2lhdGUgdGhlIG5lZWQgdG8gIm1ha2UgdGhpbmdzIHdvcmsiLCBidXQgSSdkIGJlIHdhcnkg b2YgcHV0dGluZw0KPiB0aGlzIGluIHJlbGVhc2VkIFNXLiBCcm9rZW4gSFcgbXVzdCBkaWUuIEkg aGF2ZSB3cml0dGVuIG1vcmUgdGhhbiBteSBzaGFyZQ0KPiBvZiB0aGVzZSB0ZXJyaWJsZSBoYWNr cyAoc2VlIFRYMSBzdXBwb3J0KSwgYW5kIEkgZGVlcGx5IHJlZ3JldCBpdCwgYXMNCj4gaXQgaGFz IG9ubHkgZ2l2ZW4gU2kgdmVuZG9ycyBhbiBleGN1c2Ugbm90IHRvIGZpeCB0aGluZ3MuDQoNCkZ1 bGx5IGFncmVlIGFuZCBJIGFsc28gaGFkIHRvIGRvIHNvbWUgaGFja3MgZm9yIHRoZSBUWDEgOy0p DQoNCj4gDQo+PiBJIHJlbWVtYmVyIHRoYXQgSSBhbHNvIGhhZCB0byBkbyBzb21ldGhpbmcgc3Bl Y2lmaWMgZm9yIHRoZQ0KPj4gY29uZmlndXJhdGlvbiBvZiBlZGdlL2xldmVsIGFuZCBwcmlvcml0 aWVzIHRvIGhhdmUgYW4gYWxtb3N0IHByb3Blcg0KPj4gYmVoYXZpb3VyLg0KPiANCj4gV2VsbCwg dGhlIG1vbWVudCB0aGUgR0lDIG9ic2VydmVzIHNlY3VyZSBhY2Nlc3NlcyB3aGVuIHRoZXkgc2hv dWxkIGJlDQo+IG5vbi1zZWN1cmUsIGFsbCBiZXRzIGFyZSBvZmYgYW5kIHlvdSBoYXZlIHRvIHJl c29ydCB0byB0aGUgYWJvdmUgaGFja3MuDQo+IFRoZSBmdW4gcGFydCBpcyB0aGF0IGlmIHlvdSBo YXZlIHNlY3VyZSBTVyBydW5uaW5nIG9uIHRoaXMgcGxhdGZvcm0sDQo+IHlvdSBjYW4gcHJvYmFi bHkgRG9TIGl0IGZyb20gbm9uLXNlY3VyZS4gSXQncyBnb29kLCBpc24ndCBpdD8NCg0KRGVmaW5p dGVseSBpcyBidXQgaWYgSSByZW1lbWJlciBjb3JyZWN0bHkgdGhleSBoYXZlIDIga2luZCBvZiBT b0M6IG9uZSB0aGF0IGNhbiBiZSBvbmx5IHVzZWQgaW4gbm9uLXNlY3VyZSBhbmQgYW4gb3RoZXIg d2hpY2ggaXMgbWVhbnQgdG8gYmUgdXNlIHdpdGggc2VjdXJlIGFuZCBub24gc2VjdXJlLg0KDQpC ZXJ0cmFuZA0KDQo+IA0KPj4gU2FkbHkgSSBoYXZlIG5vIGFjY2VzcyB0byB0aGUgY29kZSBhbnlt b3JlLCBzbyBJIHdvdWxkIG5lZWQgdG8gZ3Vlc3MNCj4+IGJhY2sgd2hhdCB0aGF0IHdhcy4uDQo+ IA0KPiBJJ2Qgc2F5IHRoaXMgKmlzKiBhIGdvb2QgdGhpbmcuDQo+IA0KPiAgICAgICAgTS4NCj4g LS0gDQo+IEphenogaXMgbm90IGRlYWQuIEl0IGp1c3Qgc21lbGxzIGZ1bm55Li4uDQoNCg== From xen-devel-bounces@lists.xenproject.org Wed Jun 10 09:28:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 09:28:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jix1z-0003N4-Se; Wed, 10 Jun 2020 09:28:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jix1y-0003Mz-Tr for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 09:28:22 +0000 X-Inumbo-ID: ba0b3904-aafc-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ba0b3904-aafc-11ea-bb8b-bc764e2007e4; Wed, 10 Jun 2020 09:28:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sPo/Lu4Il1ktHJc3YZJrOCNCKAa/fijs1T2Pb5LLMPI=; b=ieh+TsWm1gR5J8D6kPCbVdNmT 7fuOrQ/+vvF5O2nPAC2+sjIyBFGsB6n7b1zLgEDfHBNC7TKAB2ZgYVc/uvzan3vpflb+nCLeGWgWv 6mG64rYjDFZy9IcweoQa/RSzX+yqYOVlb3qFfdZE8ypftQarKKzYX+8kxG7X2cX34gE3w=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jix1x-0003IZ-Ek; Wed, 10 Jun 2020 09:28:21 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jix1x-0006ze-1j; Wed, 10 Jun 2020 09:28:21 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jix1x-0003qV-1C; Wed, 10 Jun 2020 09:28:21 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-coverity test] 151009: regressions - ALL FAIL X-Osstest-Failures: xen-unstable-coverity:coverity-amd64:coverity-build:fail:regression X-Osstest-Versions-This: xen=6a49b9a7920c82015381740905582b666160d955 X-Osstest-Versions-That: xen=51ca66c37371b10b378513af126646de22eddb17 From: osstest service owner Date: Wed, 10 Jun 2020 09:28:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151009 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/151009/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: coverity-amd64 6 coverity-build fail REGR. vs. 150905 version targeted for testing: xen 6a49b9a7920c82015381740905582b666160d955 baseline version: xen 51ca66c37371b10b378513af126646de22eddb17 Last test of basis 150905 2020-06-07 09:19:18 Z 3 days Testing same since 151009 2020-06-10 09:20:09 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper George Dunlap Ian Jackson Jan Beulich Juergen Gross Julien Grall Nick Rosbrook Paul Durrant Roger Pau Monné Tamas K Lengyel Wei Liu jobs: coverity-amd64 fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 329 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 10 10:23:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 10:23:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jixtW-0008Jy-5z; Wed, 10 Jun 2020 10:23:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jixtV-0008Jt-Lb for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 10:23:41 +0000 X-Inumbo-ID: 7428d560-ab04-11ea-8496-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7428d560-ab04-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 10:23:41 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: sfIz4vgJgpxoxsGeTJbhYQ9KwNqkxMh9V3IgGwxb5liHXUI3yUuqmZrEB4vnxxJB6hXbcqSTxO Uphcri6XSB1vQcmwIooOwmFO55DSKITLiuoD5Aou+l8ItsEvhqKUkfLvhU7Py5wB62zp4xmnBv 5aFdPRHyvL09O2yqzg2JejmOQvkDxvkcLKFTpuGxLptUrWcU6fsjfSkAa/cMWFM9VZ/Y1Sh+Pl sJ1Vmp0SVvhn2xKInMf4VR8OuuR/XeSLCoBiKSC7PzjJxb7zsUCA9b6yjnyihnUcTYE8UHwIPc v2U= X-SBRS: 2.7 X-MesageID: 19668192 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,495,1583211600"; d="scan'208";a="19668192" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24288.46238.722388.438970@mariner.uk.xensource.com> Date: Wed, 10 Jun 2020 11:23:26 +0100 To: Paul Durrant Subject: Re: [PATCH-for-4.14 1/2] CHANGELOG: add 'domid_policy' and domid preservation on migrate [and 1 more messages] In-Reply-To: <20200609162922.14679-2-paul@xen.org>, <20200609162922.14679-3-paul@xen.org> References: <20200609162922.14679-1-paul@xen.org> <20200609162922.14679-3-paul@xen.org> <20200609162922.14679-2-paul@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Community Manager , "xen-devel@lists.xenproject.org" , Paul Durrant , security@xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > + - New 'domid_policy', allowing domain-ids to be randomly chosen. > + - Option to preserve domain-id across migrate or save+restore. > + - Support in kdd for initial KD protocol handshake for Win 7, 8 and 10 (64 bit). These aren't mentioned in SUPPORT.md so their support status (including security support status) is not defined. I think this should be fixed. CC the security team who may have an opinion about their security support status. Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 10 10:35:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 10:35:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiy4Z-0000nr-8x; Wed, 10 Jun 2020 10:35:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiy4Y-0000nR-CM for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 10:35:06 +0000 X-Inumbo-ID: 0879b2ec-ab06-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0879b2ec-ab06-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 10:34:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=K4Ti53v6u7L54xjKC6CzyVjC/NQEtZP6ghZV5rBURDc=; b=F3VMdre/ygSCi6ZTHvQCBB4NP aTvDFIqIJSZZ4kMSmetxAtxGgScku0ZwGLvL9TBzgYf3FHVSqg/R4XvqMyyCcVRHPxzC7AbA7rEQE /DBLFfkQCeBJzGaqWu2sIxmL9MctBpjwyEDNaN0Fizov1uD6MbJarheRoomKm1FhwUDPo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiy4P-0004Ya-V9; Wed, 10 Jun 2020 10:34:58 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiy4P-00010A-I4; Wed, 10 Jun 2020 10:34:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiy4P-0003ei-HO; Wed, 10 Jun 2020 10:34:57 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 150976: regressions - FAIL X-Osstest-Failures: xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386:xen-build:fail:regression xen-4.10-testing:build-arm64-xsm:xen-build:fail:regression xen-4.10-testing:build-arm64:xen-build:fail:regression xen-4.10-testing:build-amd64:xen-build:fail:regression xen-4.10-testing:build-amd64-xsm:xen-build:fail:regression xen-4.10-testing:build-i386-xsm:xen-build:fail:regression xen-4.10-testing:build-armhf:xen-build:fail:regression xen-4.10-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-pvhv2-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-pvhv2-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.10-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.10-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=a1a9b055a349748083665e42843f75d6db2c6a7b X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Wed, 10 Jun 2020 10:34:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150976 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150976/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150039 build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386 6 xen-build fail REGR. vs. 150039 build-arm64-xsm 6 xen-build fail REGR. vs. 150039 build-arm64 6 xen-build fail REGR. vs. 150039 build-amd64 6 xen-build fail REGR. vs. 150039 build-amd64-xsm 6 xen-build fail REGR. vs. 150039 build-i386-xsm 6 xen-build fail REGR. vs. 150039 build-armhf 6 xen-build fail REGR. vs. 150039 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a version targeted for testing: xen a1a9b055a349748083665e42843f75d6db2c6a7b baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 35 days Testing same since 150941 2020-06-09 17:05:34 Z 0 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit a1a9b055a349748083665e42843f75d6db2c6a7b Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit afca67fafde22033b9a967ae197a10af5c654f02 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Wed Jun 10 10:49:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 10:49:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiyHz-0001oM-Kc; Wed, 10 Jun 2020 10:48:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiyHx-0001nv-LJ for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 10:48:57 +0000 X-Inumbo-ID: f7f6a0ea-ab07-11ea-b40d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f7f6a0ea-ab07-11ea-b40d-12813bfff9fa; Wed, 10 Jun 2020 10:48:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WlW+9KNGUuL6huZQ/w3xxAxxxQubaq2QOONvDd+97DE=; b=m1WE2FI7sAiW82kOSIgi1E9N3 gl15qhzx60K1rOJDLinjUZ2mXlhh4Cutn0zmdElEkEagOadJr2dfr+aIzMB/1YqUjsuqvrj2PSFIG z1knHG2t/5+H40dsOnKIBYVGxiB/8vCicYMpjy3G7Y6K5GTVDuLMYlYIwfK4cwdPMSBnE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiyHp-0004pS-Om; Wed, 10 Jun 2020 10:48:49 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiyHp-0001cD-Cp; Wed, 10 Jun 2020 10:48:49 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiyHp-0005AY-CG; Wed, 10 Jun 2020 10:48:49 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 150977: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-arm64:xen-build:fail:regression xen-4.11-testing:build-armhf:xen-build:fail:regression xen-4.11-testing:build-i386:xen-build:fail:regression xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:build-amd64-xsm:xen-build:fail:regression xen-4.11-testing:build-arm64-xsm:xen-build:fail:regression xen-4.11-testing:build-i386-xsm:xen-build:fail:regression xen-4.11-testing:build-amd64:xen-build:fail:regression xen-4.11-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvhv2-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.11-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvhv2-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvshim:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.11-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Wed, 10 Jun 2020 10:48:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150977 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150977/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-build fail REGR. vs. 150040 build-armhf 6 xen-build fail REGR. vs. 150040 build-i386 6 xen-build fail REGR. vs. 150040 build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 build-amd64-xsm 6 xen-build fail REGR. vs. 150040 build-arm64-xsm 6 xen-build fail REGR. vs. 150040 build-i386-xsm 6 xen-build fail REGR. vs. 150040 build-amd64 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a version targeted for testing: xen b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 35 days Testing same since 150942 2020-06-09 17:05:43 Z 0 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-xl-pvshim blocked test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Wed Jun 10 11:07:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 11:07:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiya2-0003XD-69; Wed, 10 Jun 2020 11:07:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiya0-0003X8-Cw for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 11:07:36 +0000 X-Inumbo-ID: 95e57590-ab0a-11ea-b412-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 95e57590-ab0a-11ea-b412-12813bfff9fa; Wed, 10 Jun 2020 11:07:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=w1ekVWfUnzFl6rk2w7c/tMkNS1YFJUzypCO7XzaCR48=; b=WsbR7wAiWy62n9Sbm06U8XmP/ S6eYFjqe4ZZcn4uqmnVTf3PVfne2oq21+3sE203sBS80i8GHxACrSd+pybNZnUABiN3W4P88SExAu I9CWFaboFEgV42rhqqC9hGNAhaDr2CDVdHeqNC8KmYkkPwu1SyqpCf6gHAIv82UftLLVM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiyZx-0005C7-Mx; Wed, 10 Jun 2020 11:07:33 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jiyZx-0002nt-CZ; Wed, 10 Jun 2020 11:07:33 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jiyZx-0000VM-Bv; Wed, 10 Jun 2020 11:07:33 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 150975: regressions - FAIL X-Osstest-Failures: xen-4.9-testing:build-arm64-xsm:xen-build:fail:regression xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-arm64:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-armhf:xen-build:fail:regression xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=ad0c1a0023077ee03d325a6f84bb654150539f49 X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Wed, 10 Jun 2020 11:07:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150975 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150975/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-xsm 6 xen-build fail REGR. vs. 150120 build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-arm64 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-armhf 6 xen-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a version targeted for testing: xen ad0c1a0023077ee03d325a6f84bb654150539f49 baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 31 days Testing same since 150940 2020-06-09 17:05:20 Z 0 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Wed Jun 10 11:11:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 11:11:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiyeE-0004L4-SS; Wed, 10 Jun 2020 11:11:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiyeD-0004Kx-J9 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 11:11:57 +0000 X-Inumbo-ID: 321c1ef0-ab0b-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 321c1ef0-ab0b-11ea-bca7-bc764e2007e4; Wed, 10 Jun 2020 11:11:56 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Y/sdrW+C4pt8uxofcg0lqf+kqugqEFJeK56hf4nK3LQEui7kApEcBFShHj6XNSWQVVKg+r61bl e8ckbHqc5soMLJxWnhpB56419X2hecWPgPTyottKv+E9eH2y/3nkU4JdiSJPMqVZKQ8uIfv85u ckWtCosEHT+mZ1RMcqIuwPVSw8fnzMGtRBK82N3SAaemdRUVneiTUOfp12FfHKVlKIWCGWbt3h K6q5pDlQzfKX1bPgSg9tcP01E86/hll7UU/RV/YxOrXYiukCSJirMI88NLTeghChEhZkU9T7dl +F4= X-SBRS: 2.7 X-MesageID: 20020166 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,495,1583211600"; d="scan'208";a="20020166" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <24288.49140.163747.998808@mariner.uk.xensource.com> Date: Wed, 10 Jun 2020 12:11:48 +0100 To: Jan Beulich Subject: Build fix backports for 4.9 - 4.11 inclusive X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, committers@xenproject.org, Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" 4.9 to 4.11 don't build on Debian stable, which we are now using in osstest. This is because they are missing a number of compile fixes. Where things are straightforward I intend to backport these and push them to the relevant Xen stable branches without formally posting about them each here. I hope that is OK. So far I have identified: For 4.11: 2b50cdbc444c637575580dcfa6c9525a84d5cc62 tools/xentop : replace use of deprecated vwprintw That makes it build. I will push it shortly. For 4.10: That and a large number of fixes from Marek Marczykowski-Grecki and one from John Thomson. Additionaly there is a problem with seabios, which is missing: 8c3f57ea1217ea0c80a72898bc35baa0e14af0e0 ssdt: Fix building of legacy acpi tables on current iasl compiler I think this can probably just be cherry-picked onto upstream seabios 10.2. Wei, should we do that, or should we try to persuade upstream to make a 10.4 containing this fix, or what ? I don't yet know if this is a complete list. For 4.9 I think probably all of the above. There is also a build failure I don't yet understand: ld: /home/osstest/build.150951.build-amd64/xen/stubdom/mini-os-x86_64-vtpmmgr/mini-os.o: in function `TPM_TakeOwnership': gdtoa-hexnan.c:(.text+0x829a): undefined reference to `unpack3_TPM_RSA_KEY_PARMS' Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 10 11:30:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 11:30:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiyvw-00062m-7u; Wed, 10 Jun 2020 11:30:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiyvv-00062h-HB for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 11:30:15 +0000 X-Inumbo-ID: c07828b8-ab0d-11ea-8496-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c07828b8-ab0d-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 11:30:14 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id o15so2114828ejm.12 for ; Wed, 10 Jun 2020 04:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=8HzsMIiKuP2G/hGQcApryDlLyVRbXcUAjhYoJ5bAwlM=; b=XZxAaySneL/Ab4rOquIdrLw2MoBYIXgYwEifXn9L/6zD/fN2YDpLrJKAc6d/A6y2dQ 8+E8HQa5gEe/8mbpUuBHRxHCTjqXfHSWvROlFsUPY/aN4uOHCKdQ00sQBDrXXyWVo4xn WAJNpCNCLbTZg51etPyv/Go28PHy2evq54o7OPIUT4vsV7svXaE84yQHeqm/xSYEAypx 3Ma2Bc0SsgL8T7OoyymizKjvYd/knZDFw/dLNt9OBMcSu4CLvi0AEhX8gVNGKKYVe94G iA8ujLHm16wa0YU+2AHlTRout10Mfqf+dZlbcWkjsRGbKqbv/ny4+tORmtA9hhLl0C2S cgjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=8HzsMIiKuP2G/hGQcApryDlLyVRbXcUAjhYoJ5bAwlM=; b=MBzGfbEcdeGBE0B9/O0cy8r3mt6J2kX3cWxpNY1h2JEnjLAPLcdL1YxmvUMQGMwcrS Ola4qjo0L5EnbvDhA1YZfPKLlVgVa/5xYwidJiUVGiASwaqssb1+bpF256Kb8QmLWblJ UGy2SsMhPqe/gcfbZbRBMapWk+vdgMkdm7muOS9otrep5z8WsTRIPPzIgzq1SmYa6kWu H/aN1HNvAESNULkR1zHj1RugqnmnyMa8Xil8zzImK6sJn1goCF22z8vk4uV77iFARKqn zLoOAvoGDtnoYlJSKFAaPSfkkBhDmhIYZ13bEAfY/04zvXiVGnGG5awC6/8imeXIqaC4 iLUg== X-Gm-Message-State: AOAM531LvK+J55MhfZP5YrOzjjVQKToiU3m2mbHr3aQw2O5mhGlKy3BB zBqbS6ZpWJXOk8B5JiUBzsY= X-Google-Smtp-Source: ABdhPJzCldndimsop3VFc/On+vU9yOEcHGDvMel0MZOU+iDsRvCnwQiyHZ7xez7nLmVOhYgRLuIElg== X-Received: by 2002:a17:906:2c44:: with SMTP id f4mr2988490ejh.183.1591788613706; Wed, 10 Jun 2020 04:30:13 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id o7sm12973718edj.52.2020.06.10.04.30.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2020 04:30:13 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Jan Beulich'" References: <24288.49140.163747.998808@mariner.uk.xensource.com> In-Reply-To: <24288.49140.163747.998808@mariner.uk.xensource.com> Subject: RE: Build fix backports for 4.9 - 4.11 inclusive Date: Wed, 10 Jun 2020 12:30:11 +0100 Message-ID: <00e201d63f1a$81a74150$84f5c3f0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIXAb/N9ElW9Z2nLy7CtXFSbxUYoahQLn+w X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, committers@xenproject.org, 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = Ian Jackson > Sent: 10 June 2020 12:12 > To: Jan Beulich > Cc: xen-devel@lists.xenproject.org; committers@xenproject.org; Wei Liu = > Subject: Build fix backports for 4.9 - 4.11 inclusive >=20 > 4.9 to 4.11 don't build on Debian stable, which we are now using in > osstest. This is because they are missing a number of compile fixes. >=20 > Where things are straightforward I intend to backport these and push > them to the relevant Xen stable branches without formally posting > about them each here. I hope that is OK. >=20 >=20 > So far I have identified: >=20 > For 4.11: >=20 > 2b50cdbc444c637575580dcfa6c9525a84d5cc62 > tools/xentop : replace use of deprecated vwprintw >=20 > That makes it build. I will push it shortly. >=20 >=20 > For 4.10: >=20 > That and a large number of fixes from Marek Marczykowski-G=F3recki and > one from John Thomson. Additionaly there is a problem with seabios, > which is missing: >=20 > 8c3f57ea1217ea0c80a72898bc35baa0e14af0e0 > ssdt: Fix building of legacy acpi tables on current iasl compiler >=20 Something like this is hitting me building 4.11 too. Weirdly it does not = hit if I do a clean build... only incremental: make -C seabios-dir all make[3]: Entering directory = '/local/scratch/pdurrant/xen/tools/firmware/seabios-dir-remote' Compiling IASL src/fw/ssdt-misc.hex out/src/fw/ssdt-misc.dsl.i 4: DefinitionBlock ("ssdt-misc.aml", = "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1) Error 6155 - = Invalid OEM Table ID ^ (Length cannot exceed 8 characters) ASL Input: out/src/fw/ssdt-misc.dsl.i - 102 lines, 2567 bytes, 35 = keywords Listing File: out/src/fw/ssdt-misc.lst - 8393 bytes Hex Dump: out/src/fw/ssdt-misc.hex - 4096 bytes Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 2 Optimizations > I think this can probably just be cherry-picked onto upstream seabios > 10.2. >=20 > Wei, should we do that, or should we try to persuade upstream to make > a 10.4 containing this fix, or what ? >=20 > I don't yet know if this is a complete list. >=20 >=20 > For 4.9 I think probably all of the above. There is also a build > failure I don't yet understand: >=20 > ld: = /home/osstest/build.150951.build-amd64/xen/stubdom/mini-os-x86_64-vtpmmgr= /mini-os.o: > in function `TPM_TakeOwnership': gdtoa-hexnan.c:(.text+0x829a): = undefined reference to > `unpack3_TPM_RSA_KEY_PARMS' >=20 >=20 > Thanks, > Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 10 11:36:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 11:36:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiz1q-0006F9-RE; Wed, 10 Jun 2020 11:36:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiz1p-0006F4-Lh for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 11:36:21 +0000 X-Inumbo-ID: 9aba0992-ab0e-11ea-b41d-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9aba0992-ab0e-11ea-b41d-12813bfff9fa; Wed, 10 Jun 2020 11:36:20 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: zGm1M8xzTxUjXKVxjS+NZJj3MwKhV5on1JRQnmqhzVmGMk3I28LEq8V2E+Mfrv1qRmjr+1aKBq 843Iz1q2hZ4B9ibGY9jXtetgPl/7iRt/xB6/wQuqFDIWBlkQ+d46OakybaQwDybhI1e+IIWATS 3icVX9RTt6EQ55NXirxmcImINaZT2GJUFrPQZaYEVXyft9TQkzXas4CTMo/cTgsVDDRS7c1nCy niZGkWOtzuuzXhNRj/W8+gJ6kJ71B8AUVqrZE2zYmxqLd7MDbqmyHfvuy5MUMteu8eO8Dq/Hu9 hBA= X-SBRS: 2.7 X-MesageID: 19689660 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,495,1583211600"; d="scan'208";a="19689660" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24288.50608.805045.90130@mariner.uk.xensource.com> Date: Wed, 10 Jun 2020 12:36:16 +0100 To: "paul@xen.org" Subject: RE: Build fix backports for 4.9 - 4.11 inclusive In-Reply-To: <00e201d63f1a$81a74150$84f5c3f0$@xen.org> References: <24288.49140.163747.998808@mariner.uk.xensource.com> <00e201d63f1a$81a74150$84f5c3f0$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "committers@xenproject.org" , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: Build fix backports for 4.9 - 4.11 inclusive"): > Something like this is hitting me building 4.11 too. Weirdly it does not hit if I do a clean build... only incremental: Wow. Yes. Same here. With the other stuff I mentioned my 4.10 builds, but only if I start from a clean tree. > make -C seabios-dir all > make[3]: Entering directory '/local/scratch/pdurrant/xen/tools/firmware/seabios-dir-remote' > Compiling IASL src/fw/ssdt-misc.hex > out/src/fw/ssdt-misc.dsl.i 4: DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1) > Error 6155 - Invalid OEM Table ID ^ (Length cannot exceed 8 > characters) > > ASL Input: out/src/fw/ssdt-misc.dsl.i - 102 lines, 2567 bytes, 35 keywords > Listing File: out/src/fw/ssdt-misc.lst - 8393 bytes > Hex Dump: out/src/fw/ssdt-misc.hex - 4096 bytes > > Compilation complete. 1 Errors, 0 Warnings, 0 Remarks, 2 Optimizations Maybe the generated output file is committed in tree and the build system is also a bit shonky ? I'll push my now-building 4.10 branch to xen.git#staging-4.10, anyway. Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 10 11:40:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 11:40:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiz60-00072R-Bj; Wed, 10 Jun 2020 11:40:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jiz5z-00072M-0B for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 11:40:39 +0000 X-Inumbo-ID: 3430a6b2-ab0f-11ea-b41d-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3430a6b2-ab0f-11ea-b41d-12813bfff9fa; Wed, 10 Jun 2020 11:40:38 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: t9rVQnIHDd6yrsoHZWvM0TI2z14Ed1Vt5XVEPjdstZiajg6cBUftHMPaD/I16IjqFhSuweDzdL laGEO4lCD5q9lrz4PDPZi9dxBAy234cb4hm1aqyPMmVANykIkoY55/sawbain79LMmx/hbN88d Cf1FCBpLGl6iopnwtqRvROkWv8xLMis7Mi1dnFI6z60y3FCMYL7BrbGgFJvWQxUia+b+wMrQUj FYOu+/eQFC6kuKoa2OEDBmzqMWJfG0Qh9Y+P4A+Ptou71iqH9AHthZhgQBvi713LSKZudVsO6F VTc= X-SBRS: 2.7 X-MesageID: 19914725 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,495,1583211600"; d="scan'208";a="19914725" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() Date: Wed, 10 Jun 2020 12:40:04 +0100 Message-ID: <20200610114004.30023-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Andrew Cooper , Paul Durrant , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" c/s 6902cb00e03 "tools/libxendevicemodel: extract functions and add a compat layer" introduced calls to both xencall_open() and osdep_xendevicemodel_open() but failed to fix up the error path. c/s f68c7c618a3 "libs/devicemodel: free xencall handle in error path in _open()" fixed up the xencall_open() aspect of the error path (missing the osdep_xendevicemodel_open() aspect), but positioned the xencall_close() incorrectly, creating the same pattern proved to be problematic by c/s 30a72f02870 "tools: fix error path of xenhypfs_open()". Reposition xtl_logger_destroy(), and introduce the missing osdep_xendevicemodel_close(). Fixes: 6902cb00e03 ("tools/libxendevicemodel: extract functions and add a compat layer") Fixes: f68c7c618a3 ("libs/devicemodel: free xencall handle in error path in _open()") Backport: 4.9+ Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Juergen Gross CC: Paul Durrant RFC - this is still broken. Failure to create the logger will still hit the NULL deference, in all of the stable libs, not just devicemodel. Also, unless I'd triple checked the history, I was about to reintroduce the deadlock from c/s 9976f3874d4, because it totally counterintuitive wrong to expect setup and teardown in opposite orders. --- tools/libs/devicemodel/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c index db501d9e80..4d4063956d 100644 --- a/tools/libs/devicemodel/core.c +++ b/tools/libs/devicemodel/core.c @@ -67,9 +67,10 @@ xendevicemodel_handle *xendevicemodel_open(xentoollog_logger *logger, return dmod; err: - xtl_logger_destroy(dmod->logger_tofree); + osdep_xendevicemodel_close(dmod); xentoolcore__deregister_active_handle(&dmod->tc_ah); xencall_close(dmod->xcall); + xtl_logger_destroy(dmod->logger_tofree); free(dmod); return NULL; } -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 11:47:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 11:47:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizCO-0007MN-CC; Wed, 10 Jun 2020 11:47:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizCN-0007MI-C7 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 11:47:15 +0000 X-Inumbo-ID: 207010f8-ab10-11ea-8496-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 207010f8-ab10-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 11:47:14 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jizCL-0003LT-Jq; Wed, 10 Jun 2020 12:47:13 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH] production-config: Update to current coverity tools Date: Wed, 10 Jun 2020 12:47:06 +0100 Message-Id: <20200610114706.27514-1-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Matthew Krasnick , Andrew Cooper , Ian Jackson , Paul Durrant , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The 2017.07 tarball had a leading "./" but the 2019.03 one doesn't, so we must change CoverityToolsStripComponents. The old tools we are currently using do not work any more - they are rejected by Coverity Scan. Signed-off-by: Ian Jackson Reported-by: Matthew Krasnick CC: Jan Beulich CC: Andrew Cooper CC: Paul Durrant --- production-config | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/production-config b/production-config index 7a8c0fd3..b7b9a062 100644 --- a/production-config +++ b/production-config @@ -123,8 +123,8 @@ CoverityEmail security@xen.org # This is only read from daily-cron-settings-real, everything else # gets the default/dummy path CoverityUploadUrl https://scan.coverity.com/builds?project=XenProject -CoverityTools cov-analysis-linux64-2017.07.tar.gz -CoverityToolsStripComponents 2 +CoverityTools cov-analysis-linux64-2019.03.tar.gz +CoverityToolsStripComponents 1 # We use the IP address because Citrix can't manage reliable nameservice #DebianMirrorHost debian.uk.xensource.com -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 11:51:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 11:51:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizGV-000899-TQ; Wed, 10 Jun 2020 11:51:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizGV-000894-6y for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 11:51:31 +0000 X-Inumbo-ID: b9087e7c-ab10-11ea-bb8b-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b9087e7c-ab10-11ea-bb8b-bc764e2007e4; Wed, 10 Jun 2020 11:51:30 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: zyLzOg9ydrdn0dJqs8dyKEpfPc+S21qCZ+0o6D50510o/5EcECpCCGeXcha8dPI4Y3E+hpBWHK jBGoC+3wrl7kFcWmdRSICWTgQGEEsbMYXgvIqVnpa+gRRJ4XZVf0Ip+ag+l/MH4r70+QtUIcAM fhpmP67Xr6NjOovJgPv2aa95VyOxlwRzJ34JGPxBzTDNvtz+weOb/GXSzQCmH1D1wPXfe3TOM8 CSWWP448HRBWbfVtk3dBlBRbP9XMjwkwk1pWl8K/qP3piyqvKVtT/5Xbc668tQc7JzDuoK9Sh1 z6I= X-SBRS: 2.7 X-MesageID: 19915504 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,495,1583211600"; d="scan'208";a="19915504" From: Roger Pau Monne To: Subject: [PATCH for-4.14 0/2] x86/passthrough: fixes for PVH dom0 edge triggered interrupts Date: Wed, 10 Jun 2020 13:51:01 +0200 Message-ID: <20200610115103.7592-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, Small series with two bugfixes to correctly handle edge triggered interrupts on PVH dom0. for-4.14 reasoning: fixes are isolated to PVH dom0 specific passthrough code (IDENTITY_GSI kind of bindings), and hence shouldn't affect passthrough to HVM domUs. Without these fixes the RTC timer won't work correctly on a PVH dom0 because it's edge triggered (GSI 8). Roger Pau Monne (2): x86/passthrough: do not assert edge triggered GSIs for PVH dom0 x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask xen/arch/x86/hvm/irq.c | 13 ++++++++----- xen/drivers/passthrough/io.c | 14 +++++++++++++- xen/include/asm-x86/hvm/irq.h | 2 ++ 3 files changed, 23 insertions(+), 6 deletions(-) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 11:51:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 11:51:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizGb-0008AH-4j; Wed, 10 Jun 2020 11:51:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizGa-000894-5Q for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 11:51:36 +0000 X-Inumbo-ID: bb02dff6-ab10-11ea-8496-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bb02dff6-ab10-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 11:51:33 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: SIf3w8dtwNB7iDK3eBGtb9BdQAGPSIashFWNXnaUw2TDk1TmjHPbOeVM7+NVKHoHbhckS6siWf 6DQBTE932NsEiTRnfDxM4biet1nlEzA+lkdbhU8tvCMcnD7DZ4gc1neCIXs5d8186X6VhOjkkR bLnHul6iDqDgaL0aD0eYdMfM0JhEQIE4xhnrF2XZ5suM9XgAFSBdXQNmln1esi5091r3z5zcdq 4SnYj9bUz1VARA5tVyhKVlmLARENH+kYflbM9r0PF2ZPDR4xfz1Geh0vuJDa7wnunSsNYbv9/s tUQ= X-SBRS: 2.7 X-MesageID: 19673839 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,495,1583211600"; d="scan'208";a="19673839" From: Roger Pau Monne To: Subject: [PATCH for-4.14 1/2] x86/passthrough: do not assert edge triggered GSIs for PVH dom0 Date: Wed, 10 Jun 2020 13:51:02 +0200 Message-ID: <20200610115103.7592-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200610115103.7592-1-roger.pau@citrix.com> References: <20200610115103.7592-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Edge triggered interrupts do not assert the line, so the handling done in Xen should also avoid asserting it. Asserting the line prevents further edge triggered interrupts on the same vIO-APIC pin from being delivered, since the line is not de-asserted. One case of such kind of interrupt is the RTC timer, which is edge triggered and available to a PVH dom0. Note this should not affect domUs, as it only modifies the behavior of IDENTITY_GSI kind of passed through interrupts. Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/irq.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c index 9c8adbc495..9a56543c1b 100644 --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -169,9 +169,10 @@ void hvm_pci_intx_deassert( void hvm_gsi_assert(struct domain *d, unsigned int gsi) { + int level = vioapic_get_trigger_mode(d, gsi); struct hvm_irq *hvm_irq = hvm_domain_irq(d); - if ( gsi >= hvm_irq->nr_gsis ) + if ( gsi >= hvm_irq->nr_gsis || level < 0 ) { ASSERT_UNREACHABLE(); return; @@ -186,9 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) * to know if the GSI is pending or not. */ spin_lock(&d->arch.hvm.irq_lock); - if ( !hvm_irq->gsi_assert_count[gsi] ) + if ( !level || !hvm_irq->gsi_assert_count[gsi] ) { - hvm_irq->gsi_assert_count[gsi] = 1; + if ( !level ) + hvm_irq->gsi_assert_count[gsi] = 1; assert_gsi(d, gsi); } spin_unlock(&d->arch.hvm.irq_lock); @@ -196,11 +198,12 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) void hvm_gsi_deassert(struct domain *d, unsigned int gsi) { + int level = vioapic_get_trigger_mode(d, gsi); struct hvm_irq *hvm_irq = hvm_domain_irq(d); - if ( gsi >= hvm_irq->nr_gsis ) + if ( level <= 0 || gsi >= hvm_irq->nr_gsis ) { - ASSERT_UNREACHABLE(); + ASSERT(level == 0 && gsi < hvm_irq->nr_gsis); return; } -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 11:51:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 11:51:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizGg-0008BO-Ch; Wed, 10 Jun 2020 11:51:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizGf-000894-5e for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 11:51:41 +0000 X-Inumbo-ID: bc778184-ab10-11ea-bb8b-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bc778184-ab10-11ea-bb8b-bc764e2007e4; Wed, 10 Jun 2020 11:51:36 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: c+5iYyULtN6MmJAxB9TxPcrmkNfHgal4+8BuiEm2tC/wgr23aYplq31C8WJQeoJGHLZ79omQiN 4c93Rc4dAIIFaFZI5z033JpEuZYVvJqTPBCWCpqo3Y8LLdAdnIfHNo8raGIH3UP37MyHfgMsyP /W1Qxzl7m2NDU+4OWCLrKacObIhQzktx3CP5RoPZObW3YMNftQXuDQqmpIVoZMH+ZCl0++NLgF gdgm048dekes7sP8cnvKn9Q3AKo6PPVjSZ+LZDgYc36gWERsfy87X/EAIqa1CCBdB+8vntcn/c rjI= X-SBRS: 2.7 X-MesageID: 19690637 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,495,1583211600"; d="scan'208";a="19690637" From: Roger Pau Monne To: Subject: [PATCH for-4.14 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask Date: Wed, 10 Jun 2020 13:51:03 +0200 Message-ID: <20200610115103.7592-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200610115103.7592-1-roger.pau@citrix.com> References: <20200610115103.7592-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" There's no need to setup a timer for GSIs that are edge triggered, since those don't require any EIO or unmask, and hence couldn't block other interrupts. Note this is only used by PVH dom0, that can setup the passthrough of edge triggered interrupts from the vIO-APIC. One example of such kind of interrupt that can be used by a PVH dom0 would be the RTC timer. Signed-off-by: Roger Pau Monné --- xen/drivers/passthrough/io.c | 14 +++++++++++++- xen/include/asm-x86/hvm/irq.h | 2 ++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c index b292e79382..be1d5b1434 100644 --- a/xen/drivers/passthrough/io.c +++ b/xen/drivers/passthrough/io.c @@ -138,7 +138,8 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci) bool pt_irq_need_timer(uint32_t flags) { - return !(flags & (HVM_IRQ_DPCI_GUEST_MSI | HVM_IRQ_DPCI_TRANSLATE)); + return !(flags & (HVM_IRQ_DPCI_GUEST_MSI | HVM_IRQ_DPCI_TRANSLATE | + HVM_IRQ_DPCI_NO_EOI)); } static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci, @@ -558,6 +559,12 @@ int pt_irq_create_bind( */ ASSERT(!mask); share = trigger_mode; + if ( !trigger_mode ) + /* + * Edge IO-APIC interrupt, no EOI or unmask to perform + * and hence no timer needed. + */ + pirq_dpci->flags |= HVM_IRQ_DPCI_NO_EOI; } } @@ -920,6 +927,11 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI ) { hvm_gsi_assert(d, pirq->pirq); + if ( pirq_dpci->flags & HVM_IRQ_DPCI_NO_EOI ) + { + spin_unlock(&d->event_lock); + return; + } pirq_dpci->pending++; } diff --git a/xen/include/asm-x86/hvm/irq.h b/xen/include/asm-x86/hvm/irq.h index d306cfeade..532880d497 100644 --- a/xen/include/asm-x86/hvm/irq.h +++ b/xen/include/asm-x86/hvm/irq.h @@ -121,6 +121,7 @@ struct dev_intx_gsi_link { #define _HVM_IRQ_DPCI_GUEST_PCI_SHIFT 4 #define _HVM_IRQ_DPCI_GUEST_MSI_SHIFT 5 #define _HVM_IRQ_DPCI_IDENTITY_GSI_SHIFT 6 +#define _HVM_IRQ_DPCI_NO_EOI_SHIFT 7 #define _HVM_IRQ_DPCI_TRANSLATE_SHIFT 15 #define HVM_IRQ_DPCI_MACH_PCI (1u << _HVM_IRQ_DPCI_MACH_PCI_SHIFT) #define HVM_IRQ_DPCI_MACH_MSI (1u << _HVM_IRQ_DPCI_MACH_MSI_SHIFT) @@ -129,6 +130,7 @@ struct dev_intx_gsi_link { #define HVM_IRQ_DPCI_GUEST_PCI (1u << _HVM_IRQ_DPCI_GUEST_PCI_SHIFT) #define HVM_IRQ_DPCI_GUEST_MSI (1u << _HVM_IRQ_DPCI_GUEST_MSI_SHIFT) #define HVM_IRQ_DPCI_IDENTITY_GSI (1u << _HVM_IRQ_DPCI_IDENTITY_GSI_SHIFT) +#define HVM_IRQ_DPCI_NO_EOI (1u << _HVM_IRQ_DPCI_NO_EOI_SHIFT) #define HVM_IRQ_DPCI_TRANSLATE (1u << _HVM_IRQ_DPCI_TRANSLATE_SHIFT) struct hvm_gmsi_info { -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:29:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:29:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizrW-0002ih-Hk; Wed, 10 Jun 2020 12:29:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizrV-0002ic-JY for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:29:45 +0000 X-Inumbo-ID: 10915074-ab16-11ea-bb8b-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 10915074-ab16-11ea-bb8b-bc764e2007e4; Wed, 10 Jun 2020 12:29:44 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: zNvT3uzA0kVAVLBEeY34utxRwCnHLzNGmo4G0li/n0u+d7uCwIo7F2Q638txAkGXMpRDYaRs9+ 3rQiHFLzvSr1YkkKnxCSriPiyTkTZ4G/Al9+pbtIeLo/YWrURnavp9pNHnQv8zjYKb5Ewhm6Kl grJUW8HuGDTtu6Vv57VajCapwgO5e/G/rOZlq9i9LjTnpxL+A13eXSvvw7/Z5CEp58Tr/ULcBK X/Z1FqeJO1mWX1XNxP+ssRU/ZCtkDDsccuZ5eqUhDKS5Fa95tcq+LCzu6HXvemMxnc+gPLcGqH TLk= X-SBRS: 2.7 X-MesageID: 19918615 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="19918615" Subject: Re: [PATCH for-4.14 1/2] x86/passthrough: do not assert edge triggered GSIs for PVH dom0 To: Roger Pau Monne , References: <20200610115103.7592-1-roger.pau@citrix.com> <20200610115103.7592-2-roger.pau@citrix.com> From: Andrew Cooper Message-ID: Date: Wed, 10 Jun 2020 13:29:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200610115103.7592-2-roger.pau@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10/06/2020 12:51, Roger Pau Monne wrote: > Edge triggered interrupts do not assert the line, so the handling done > in Xen should also avoid asserting it. Asserting the line prevents > further edge triggered interrupts on the same vIO-APIC pin from being > delivered, since the line is not de-asserted. > > One case of such kind of interrupt is the RTC timer, which is edge > triggered and available to a PVH dom0. Note this should not affect > domUs, as it only modifies the behavior of IDENTITY_GSI kind of passed > through interrupts. > > Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:33:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:33:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizvU-0003VL-1h; Wed, 10 Jun 2020 12:33:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizvS-0003VF-Le for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:33:50 +0000 X-Inumbo-ID: a2b54ae6-ab16-11ea-8496-bc764e2007e4 Received: from mail-ed1-x541.google.com (unknown [2a00:1450:4864:20::541]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a2b54ae6-ab16-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 12:33:50 +0000 (UTC) Received: by mail-ed1-x541.google.com with SMTP id w7so1264516edt.1 for ; Wed, 10 Jun 2020 05:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=6duC29xjD4uFOGGkP0FGAO4O4N4hAPvDiy7sVwN0h7k=; b=TG8/dFYafdcgRIN00CG5pRWjopf2a6te+TDR0L2N1Dqs5AzOGgok74H6GcBbUBB34Q C7uYbFjdziOodmtO/0j0fx8Nhfmq841mFtlFEIuQ7640SnxZSrEcwJ4SfIRqIII47Mhd ejAxJChaRNAO7qFwzqzq5B+Qnpq8JkXqAVkxcOVhMlv4Rt3j9As6lbPR/Atf52ff/hbB Bktld/z2RQPmXndQqAttTJV0Z1R6TOWAATBrbjQ7XHL/bkebYWo772VYXjjjA3WD9UyJ uApbOKbyHSFloHyc6Gjp0jA9O5kS7oslnuvRo6VS+FDdXMqC6TlXsXt4AuvhVqxjCg3+ 3Z9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=6duC29xjD4uFOGGkP0FGAO4O4N4hAPvDiy7sVwN0h7k=; b=QgCqcFZEwneVdjuxT4IcrRpQmIKdwLqAQLNAnfVK9RTmActxZiE7iy0kTX8FNt8MQ1 lwsftCQUXNcwchhvZZklY8UfKM1ROhEpHhojtBpTrSyjSoAkBfccPNNc/M9hKsB1/jDK vgBrzebhbCOUIuTx3OVVnDkU8KgIKrk51hDHE9IKWiywXopgI1iToqvGb1vRkg7JNhV7 epOqMy0ZtWv3OczdEC/WMbPS3j47Re+5Y6SG670n/bJXleGmS2BApWwkBsIy4uxDjHoo XK/Qo3gZ41e+5A11DWCpX2ah+cLL9rNtcjQK5uuLBUqdGFvt7mcpO5KW+7Im166eIZC4 sHkw== X-Gm-Message-State: AOAM532F16c3U9l2wNnu8YbqnksB86/MhDqVWKXYc2kQxN8ehzETD7N2 YUGNF98IK3wOHDsVm2rk+QM= X-Google-Smtp-Source: ABdhPJzaLiYrG35h0C27DpTxD926lo1oB+/asTx3gRA3qId6AFZvftazzdbQotXgP21oVsl9zvDVZg== X-Received: by 2002:a50:afa5:: with SMTP id h34mr2332023edd.34.1591792429226; Wed, 10 Jun 2020 05:33:49 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id m91sm3676447ede.96.2020.06.10.05.33.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2020 05:33:48 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200610115103.7592-1-roger.pau@citrix.com> <20200610115103.7592-2-roger.pau@citrix.com> In-Reply-To: <20200610115103.7592-2-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14 1/2] x86/passthrough: do not assert edge triggered GSIs for PVH dom0 Date: Wed, 10 Jun 2020 13:33:46 +0100 Message-ID: <00e301d63f23$63c83a00$2b58ae00$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJ/+0U2guq5J+wcejb54ge6+rzRyAJA9sgcp2xHeiA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 10 June 2020 12:51 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich = ; Andrew > Cooper ; Wei Liu > Subject: [PATCH for-4.14 1/2] x86/passthrough: do not assert edge = triggered GSIs for PVH dom0 >=20 > Edge triggered interrupts do not assert the line, so the handling done > in Xen should also avoid asserting it. Asserting the line prevents > further edge triggered interrupts on the same vIO-APIC pin from being > delivered, since the line is not de-asserted. >=20 > One case of such kind of interrupt is the RTC timer, which is edge > triggered and available to a PVH dom0. Note this should not affect > domUs, as it only modifies the behavior of IDENTITY_GSI kind of passed > through interrupts. >=20 > Signed-off-by: Roger Pau Monn=C3=A9 > --- > xen/arch/x86/hvm/irq.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) >=20 > diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c > index 9c8adbc495..9a56543c1b 100644 > --- a/xen/arch/x86/hvm/irq.c > +++ b/xen/arch/x86/hvm/irq.c > @@ -169,9 +169,10 @@ void hvm_pci_intx_deassert( >=20 > void hvm_gsi_assert(struct domain *d, unsigned int gsi) > { > + int level =3D vioapic_get_trigger_mode(d, gsi); > struct hvm_irq *hvm_irq =3D hvm_domain_irq(d); >=20 > - if ( gsi >=3D hvm_irq->nr_gsis ) > + if ( gsi >=3D hvm_irq->nr_gsis || level < 0 ) > { > ASSERT_UNREACHABLE(); > return; > @@ -186,9 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned = int gsi) > * to know if the GSI is pending or not. > */ > spin_lock(&d->arch.hvm.irq_lock); > - if ( !hvm_irq->gsi_assert_count[gsi] ) > + if ( !level || !hvm_irq->gsi_assert_count[gsi] ) We have definitions of VIOAPIC_EDGE_TRIG and VIOAPIC_LEVEL_TRIG. It = seems odd not to use them here. Paul > { > - hvm_irq->gsi_assert_count[gsi] =3D 1; > + if ( !level ) > + hvm_irq->gsi_assert_count[gsi] =3D 1; > assert_gsi(d, gsi); > } > spin_unlock(&d->arch.hvm.irq_lock); > @@ -196,11 +198,12 @@ void hvm_gsi_assert(struct domain *d, unsigned = int gsi) >=20 > void hvm_gsi_deassert(struct domain *d, unsigned int gsi) > { > + int level =3D vioapic_get_trigger_mode(d, gsi); > struct hvm_irq *hvm_irq =3D hvm_domain_irq(d); >=20 > - if ( gsi >=3D hvm_irq->nr_gsis ) > + if ( level <=3D 0 || gsi >=3D hvm_irq->nr_gsis ) > { > - ASSERT_UNREACHABLE(); > + ASSERT(level =3D=3D 0 && gsi < hvm_irq->nr_gsis); > return; > } >=20 > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:37:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:37:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizys-0003ez-H7; Wed, 10 Jun 2020 12:37:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jizyq-0003eu-L9 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:37:20 +0000 X-Inumbo-ID: 1f646d88-ab17-11ea-b42b-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1f646d88-ab17-11ea-b42b-12813bfff9fa; Wed, 10 Jun 2020 12:37:19 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: g8wAK7A0sl8aOHTGZITnPC8/NtfSJXfBK+PTIi2S3+cxJ58PJirh0F4mIAUQqOZoRTPzwcnFkV Mi5YPSOk/WGsZ0VK7wS1ZrogzNCYHJA4xOPpwH/8tOexwgPze4kFEiIjsFuSa5eath6dDhm+kz MP5LZpib0QiqrCORSMJ+qjg2fTu6b3SHTA39v+2z6UddXDrGvzHpFd+eRZJII7iehgb07PXXYw YMddoKVBvlYoZTkvsIKEOhyBHQ6a+7H/lbCm9qmz1UDUurRclVFJ0Ywg7sUwLO9ixiS2OanIM/ eH0= X-SBRS: 2.7 X-MesageID: 19919216 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="19919216" Subject: Re: [PATCH for-4.14 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask To: Roger Pau Monne , References: <20200610115103.7592-1-roger.pau@citrix.com> <20200610115103.7592-3-roger.pau@citrix.com> From: Andrew Cooper Message-ID: Date: Wed, 10 Jun 2020 13:37:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200610115103.7592-3-roger.pau@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10/06/2020 12:51, Roger Pau Monne wrote: > @@ -920,6 +927,11 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) > if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI ) > { > hvm_gsi_assert(d, pirq->pirq); > + if ( pirq_dpci->flags & HVM_IRQ_DPCI_NO_EOI ) > + { > + spin_unlock(&d->event_lock); > + return; > + } Urgh.  Could I possibly talk you into fixing hvm_dirq_assist() to have a "goto out;" and a single unlock path ?  (How far are you expecting this to be backported?) I'm also totally unconvinced that the atomic test_and_clear() needs to be done with the event lock held (it should either be non-atomic, or the locking should be inside the if() condition), but that is probably not a can of worms wanting opening right now... ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:39:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:39:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj01F-0003nA-UI; Wed, 10 Jun 2020 12:39:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj01E-0003n4-S8 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:39:48 +0000 X-Inumbo-ID: 78085896-ab17-11ea-bca7-bc764e2007e4 Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 78085896-ab17-11ea-bca7-bc764e2007e4; Wed, 10 Jun 2020 12:39:47 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id q13so1282428edi.3 for ; Wed, 10 Jun 2020 05:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bxIGmdzYVGd7dALOtkxKZRmhaWRNMYNPEXZoVOpm8eA=; b=tKtVujid9299bW8kmqqlLGT3xAYxnApuvY147znhv03a6AN1xNmLzM4lxwwCIBYCyG mlNtYI1Xrmdsxo6OGEevEEHVmYqY0R4SsNQ89KQvpfSC/NV2o7rz4jOn3azY5RBseMKo w6DzCB1NZpGx3uQu/iSZ50cPHPkUrokmMW22TnQI/BEyHYJvaHuQPxxbiRQCz5scXyD/ V22btFn7Xac+fLPGWGl7HSOG+vTWZUZZUN3PqEImM/3gRWYw5vOyBbIATdP9PvITE6vU XjjkdcX1FtTfIziaGVVSNdo3DFIgQVN/voJTYdnj2CBJspyQZu39qcTfLGskvA4JA+A1 yRxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bxIGmdzYVGd7dALOtkxKZRmhaWRNMYNPEXZoVOpm8eA=; b=NK8Onpm9tKvgR4Plk49E8iyN6DCNlzvQ5xqaqnjVPpDZTQg5reftEXiRRFYMUtPbpu d6QA5+KcFk3goRUS/It5M2NvuChwDiCrO90Ony85ZCiAVqPUf73qtL4x6QW8oG1Ue6JB kOQ7sGrdhC94epAm4ryLjgakBUPdTK8PbK4nHmLvytPVJcOD9FvsSeJNXw2Vz1svfyey i8hMoJD3g2Y7eABcLsWIZMc6MsLm/+TbYNQiYeHdAb0Ym1x5Vnt/mVaWiq9LUafmz6+N P8a/f2PgJ9coMlTfyABei0eN51APoW82ruBzeoQoxd80ltXohA3mCM0Lsrp8xmpF2Bw6 kzCQ== X-Gm-Message-State: AOAM532UqR20pjHmREm4fG416I4PWd1Ud1yNenN6ZqG6tn5X0qTUIo2m i6TJYdzae20TInrdBA9fwnz/MuxcPnpEYsADJQF2qmT4 X-Google-Smtp-Source: ABdhPJwSvOvWp/DpJOg4Kql1d4SF9CUGu8L/oHAY6qntzPsy6/xPArOj4lP0SL/DC2tw/SGOCGRdg2RoLMDKvKMoFlI= X-Received: by 2002:a05:6402:1d96:: with SMTP id dk22mr2344148edb.258.1591792787038; Wed, 10 Jun 2020 05:39:47 -0700 (PDT) MIME-Version: 1.0 References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <32FA85C2-7685-49D2-875B-9FA1C138C92A@arm.com> <5C2DB5F7-832E-4B02-A99A-8B5C7CEC7645@arm.com> In-Reply-To: <5C2DB5F7-832E-4B02-A99A-8B5C7CEC7645@arm.com> From: CodeWiz2280 Date: Wed, 10 Jun 2020 08:39:33 -0400 Message-ID: Subject: Re: Keystone Issue To: Bertrand Marquis Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , nd , Stefano Stabellini , Julien Grall , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 10, 2020 at 4:39 AM Bertrand Marquis wrote: > > > > > On 10 Jun 2020, at 09:20, Marc Zyngier wrote: > > > > On 2020-06-10 09:06, Bertrand Marquis wrote: > >> Hi, > >>> On 9 Jun 2020, at 18:45, Marc Zyngier wrote: > >>> Hi Julien, > >>> On 2020-06-09 18:32, Julien Grall wrote: > >>>> (+ Marc) > >>>> On 09/06/2020 18:03, Bertrand Marquis wrote: > >>>>> Hi > >>>>>> On 9 Jun 2020, at 16:47, Julien Grall wrote: > >>>>>> On 09/06/2020 16:28, Bertrand Marquis wrote: > >>>>>>> Hi, > >>>>>>>> On 9 Jun 2020, at 15:33, CodeWiz2280 wro= te: > >>>>>>>> There does appear to be a secondary (CIC) controller that can fo= rward > >>>>>>>> events to the GIC-400 and EDMA controllers for the keystone 2 fa= mily. > >>>>>>>> Admittedly, i'm not sure how it is being used with regards to th= e > >>>>>>>> peripherals. I only see mention of the GIC-400 parent for the d= evices > >>>>>>>> in the device tree. Maybe Bertrand has a better idea on whether= any > >>>>>>>> peripherals go through the CIC first? I see that gic_interrupt = () > >>>>>>>> fires once in Xen, which calls doIRQ to push out the virtual int= errupt > >>>>>>>> to the dom0 kernel. The dom0 kernel then handles the interrupt = and > >>>>>>>> returns, but gic_interrupt() never fires again in Xen. > >>>>>>> I do not remember of any CIC but the behaviour definitely look li= ke an interrupt acknowledge problem. > >>>>>>> Could you try the following: > >>>>>>> --- a/xen/arch/arm/gic-v2.c > >>>>>>> +++ b/xen/arch/arm/gic-v2.c > >>>>>>> @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_de= sc *desc) > >>>>>>> /* Lower the priority of the IRQ */ > >>>>>>> gicv2_eoi_irq(desc); > >>>>>>> /* Deactivation happens in maintenance interrupt / via GICV *= / > >>>>>>> + > >>>>>>> + /* Test for Keystone2 */ > >>>>>>> + gicv2_dir_irq(desc); > >>>>>>> } > >>>>>>> I think the problem I had was related to the vgic not deactivatin= g properly the interrupt. > >>>>>> Are you suggesting the guest EOI is not properly forwarded to the = hardware when LR.HW is set? If so, this could possibly be workaround in Xen= by raising a maintenance interrupt every time a guest EOI an interrupt. > >>>>> Agree the maintenance interrupt would definitely be the right solut= ion > >>>> I would like to make sure we aren't missing anything in Xen first. > >>>> From what you said, you have encountered this issue in the past with= a > >>>> different hypervisor. So it doesn't look like to be Xen related. > >>>> Was there any official statement from TI? If not, can we try to get > >>>> some input from them first? > >>>> @Marc, I know you dropped 32-bit support in KVM recently :). Althoug= h, > >>> Yes! Victory is mine! Freedom from the shackles of 32bit, at last! :D > >>>> I was wondering if you heard about any potential issue with guest EO= I > >>>> not forwarded to the host. This is on TI Keystone (Cortex A-15). > >>> Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Mid= way all run just fine with guest EOI), and GIC-400 is a pretty solid piece = of kit (it is just sloooooow...). > >>> Thinking of it, you would see something like that if the GIC was seei= ng the writes coming from the guest as secure instead of NS (cue the early = firmware on XGene that exposed the wrong side of GIC-400). > >>> Is there some kind of funky bridge between the CPU and the GIC? > >> Yes the behaviour I had was coherent with the GIC seeing the processor > >> in secure mode and not in non secure hence making the VGIC ack non > >> functional. > > > > Can you please check this with the TI folks? It may be fixable if > > the bridge is SW configurable. > > At that time they did not =E2=80=9Coffer=E2=80=9D that solution but does = not mean it is not possible. > > > > >> So the only way to solve this is actually to do the interrupt > >> deactivate inside Xen (using a maintenance interrupt). > > > > That's a terrible hack, and one that would encourage badly integrated H= W. > > I appreciate the need to "make things work", but I'd be wary of putting > > this in released SW. Broken HW must die. I have written more than my sh= are > > of these terrible hacks (see TX1 support), and I deeply regret it, as > > it has only given Si vendors an excuse not to fix things. > > Fully agree and I also had to do some hacks for the TX1 ;-) > > > > >> I remember that I also had to do something specific for the > >> configuration of edge/level and priorities to have an almost proper > >> behaviour. > > > > Well, the moment the GIC observes secure accesses when they should be > > non-secure, all bets are off and you have to resort to the above hacks. > > The fun part is that if you have secure SW running on this platform, > > you can probably DoS it from non-secure. It's good, isn't it? > > Definitely is but if I remember correctly they have 2 kind of SoC: one th= at can be only used in non-secure and an other which is meant to be use wit= h secure and non secure. > > Bertrand > > > > >> Sadly I have no access to the code anymore, so I would need to guess > >> back what that was.. > > > > I'd say this *is* a good thing. The problem is that a hack may be my only solution to getting this working on this platform. If TI says that they don't support it then i'm stuck. Just to summarize the problem, we believe that the GIC is seeing secure accesses from dom0 when they should be non-secure. This is causing the VGIC ack to be non-functional from dom0. We would need a firmware that supports both secure and non-secure accesses. The Xen code gets to "gicv2_guest_irq_end()" where it executes "gicv2_eoi_irq()", but then we had to add the deactivate "gicv2_dir_irq" to clear the virtual interrupt manually to get things going again. > > > > M. > > -- > > Jazz is not dead. It just smells funny... > From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:40:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:40:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj02J-0004Wo-7r; Wed, 10 Jun 2020 12:40:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj02I-0004We-8f for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:40:54 +0000 X-Inumbo-ID: 9f2abe1e-ab17-11ea-8496-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9f2abe1e-ab17-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 12:40:53 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: nNU+aj6yplQrqlTAqeK4CfMv+rI/KyzFg+pXfgzkQnX5EWIp934YHUa4GCOE003PI7fC5sz7dx Fe+eHPRYZd7cTGWfITkTezmZf67kvYbCl24OzIKFYI324xS3lIshY/m3FpjQ7axbalgFGbvcCi khmYnTYAAWOx/T910Fnfmcx0D9OPpX1Y6bOCqxmkivZy9KuCFuvItBb2DETWE0yb9DrG1nkQvG eA3Yva/xaoPSOy5Ha+tkCAcp4CR6OJnTRWIFPcxmb0DiPl5AEFLGvORS+OREGzMTBmT2JJ+x8n pQU= X-SBRS: 2.7 X-MesageID: 19695224 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="19695224" Date: Wed, 10 Jun 2020 14:40:43 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Subject: Re: [PATCH for-4.14 1/2] x86/passthrough: do not assert edge triggered GSIs for PVH dom0 Message-ID: <20200610124043.GA4920@Air-de-Roger> References: <20200610115103.7592-1-roger.pau@citrix.com> <20200610115103.7592-2-roger.pau@citrix.com> <00e301d63f23$63c83a00$2b58ae00$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <00e301d63f23$63c83a00$2b58ae00$@xen.org> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Wei Liu' , 'Jan Beulich' , 'Andrew Cooper' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 10, 2020 at 01:33:46PM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Roger Pau Monne > > Sent: 10 June 2020 12:51 > > To: xen-devel@lists.xenproject.org > > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich ; Andrew > > Cooper ; Wei Liu > > Subject: [PATCH for-4.14 1/2] x86/passthrough: do not assert edge triggered GSIs for PVH dom0 > > > > Edge triggered interrupts do not assert the line, so the handling done > > in Xen should also avoid asserting it. Asserting the line prevents > > further edge triggered interrupts on the same vIO-APIC pin from being > > delivered, since the line is not de-asserted. > > > > One case of such kind of interrupt is the RTC timer, which is edge > > triggered and available to a PVH dom0. Note this should not affect > > domUs, as it only modifies the behavior of IDENTITY_GSI kind of passed > > through interrupts. > > > > Signed-off-by: Roger Pau Monné > > --- > > xen/arch/x86/hvm/irq.c | 13 ++++++++----- > > 1 file changed, 8 insertions(+), 5 deletions(-) > > > > diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c > > index 9c8adbc495..9a56543c1b 100644 > > --- a/xen/arch/x86/hvm/irq.c > > +++ b/xen/arch/x86/hvm/irq.c > > @@ -169,9 +169,10 @@ void hvm_pci_intx_deassert( > > > > void hvm_gsi_assert(struct domain *d, unsigned int gsi) > > { > > + int level = vioapic_get_trigger_mode(d, gsi); > > struct hvm_irq *hvm_irq = hvm_domain_irq(d); > > > > - if ( gsi >= hvm_irq->nr_gsis ) > > + if ( gsi >= hvm_irq->nr_gsis || level < 0 ) > > { > > ASSERT_UNREACHABLE(); > > return; > > @@ -186,9 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) > > * to know if the GSI is pending or not. > > */ > > spin_lock(&d->arch.hvm.irq_lock); > > - if ( !hvm_irq->gsi_assert_count[gsi] ) > > + if ( !level || !hvm_irq->gsi_assert_count[gsi] ) > > We have definitions of VIOAPIC_EDGE_TRIG and VIOAPIC_LEVEL_TRIG. It seems odd not to use them here. Urg, completely forgot about those. I think there are many places where the triggering is treated as a boolean. I will rename the local variable to 'trig' and compare against VIOAPIC_EDGE_TRIG. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:47:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:47:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj088-0004lR-Td; Wed, 10 Jun 2020 12:46:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj087-0004lM-CJ for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:46:55 +0000 X-Inumbo-ID: 7525f4b6-ab18-11ea-bca7-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7525f4b6-ab18-11ea-bca7-bc764e2007e4; Wed, 10 Jun 2020 12:46:52 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: IOxINSA+UxuA5GreV127XwoCoD48f/pHDw4nhs5FlCzjJN+fnZRg3DoGI9fIinbZ0GU26qw81a C7mvgSlkpKBHHA5o0UQ4SsJlTFNDAj1PLegxtAZURnbW7jPVRWhf/Xs9y0sPQzEgybBfPP3FGP 98vHRjvsXTcqm+Ii6stmcB6WMRK/sSatu9+5An6pxvLipjD845Sf18LS4e2TUJq21jaUUvURIY AbMAmMEmDU9w2geST+3rETiXtX9JBmUPrYWbxrRBBbtSPgKWET8+4n2A1B6F0h7UIxEN9/XZro 2bs= X-SBRS: 2.7 X-MesageID: 19976294 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="19976294" Date: Wed, 10 Jun 2020 14:46:45 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Subject: Re: [PATCH for-4.14 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask Message-ID: <20200610124645.GB4920@Air-de-Roger> References: <20200610115103.7592-1-roger.pau@citrix.com> <20200610115103.7592-3-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 10, 2020 at 01:37:15PM +0100, Andrew Cooper wrote: > On 10/06/2020 12:51, Roger Pau Monne wrote: > > @@ -920,6 +927,11 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) > > if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI ) > > { > > hvm_gsi_assert(d, pirq->pirq); > > + if ( pirq_dpci->flags & HVM_IRQ_DPCI_NO_EOI ) > > + { > > + spin_unlock(&d->event_lock); > > + return; > > + } > > Urgh.  Could I possibly talk you into fixing hvm_dirq_assist() to have a > "goto out;" and a single unlock path ?  (How far are you expecting this > to be backported?) I was very tempted to go that way but didn't want to introduce more churn. Since you agree I will do so. > I'm also totally unconvinced that the atomic test_and_clear() needs to > be done with the event lock held (it should either be non-atomic, or the > locking should be inside the if() condition), but that is probably not a > can of worms wanting opening right now... There's some reasoning about all this in 104072fc1c7e6ed. I also think naming it masked is confusing, since the underlying interrupt might not be masked. Anyway, this seems like something I don't really want to get into now, as it seems quite fragile. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:50:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:50:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0BG-0005ZC-Gw; Wed, 10 Jun 2020 12:50:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0BF-0005Z4-Hq for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:50:09 +0000 X-Inumbo-ID: ea420244-ab18-11ea-b42d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ea420244-ab18-11ea-b42d-12813bfff9fa; Wed, 10 Jun 2020 12:50:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Cc:From:References:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5UGUjExY2Iorx7M3D3aSu3DlN+LUzWRroe7JhKgakNY=; b=fAml6FEpnEo4UPXZjF6d672FqJ Z8AHmCsYLCtpov/2QEjOjsF2/+JcJmNz5/9joyMwzCN3ceKCLGsgVe4v7T7l1aoKwrcpEcHZBMIhi XW1hPMSv8MGNK910ZEnW69e+PklRSe1gmovO+xxBEShzIS927YPo3trvQ0LQ41WTKjts=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0BD-00078A-H7; Wed, 10 Jun 2020 12:50:07 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jj0BD-0006Lx-Au; Wed, 10 Jun 2020 12:50:07 +0000 Subject: Re: HYPERVISOR_console_io + CONSOLEIO_write needs COPY_flush_dcache To: Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" References: <912a84d1-ca47-9c37-06e7-28bebe696b4d@epam.com> From: Julien Grall Message-ID: Date: Wed, 10 Jun 2020 13:50:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <912a84d1-ca47-9c37-06e7-28bebe696b4d@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10/06/2020 09:13, Oleksandr Andrushchenko wrote: > Hello, Hi, > While adding support for para-virtualized block device in u-boot > > I faced an issue with HYPERVISOR_console_io + CONSOLEIO_write. > > I tried to use the hypercall during MMU setup stage while enabling data cache > > on arm64 platform (e.g. data cache is not yet enabled) and saw in guest's console > > either old data or some sort of garbage. Printing constant strings, just like mini-os > > does on boot, works as expected. Per the hypercall ABI (see include/public/arch-arm.h) all the buffers must reside in memory which is mapped as Normal Inner Write-Back Inner-Shareable. You are passing non-cacheable memory, so the behavior you see is expected. > So, looking at the Xen code [1] it seems > > that we should copy guest's buffer with COPY_flush_dcache set in this case COPY_flush_dcache is only meant to be used when copy to guest memory to make sure the data reached the point of coherency in your system. It is not meant to be used when copying from guest. > as (usually?) this hypercall is used in guest's code which doesn't have any > other means to print yet, e.g. early printk case. I have been using it after the MMU is setup but before the console is properly setup by the guest (there is a lot that can happen in Linux between the two). In my case, the flush is not necessary and would be wrong. In general, the cache is never off on Arm64 because you may have system cache or, in the cache of virtualization, cacheable mapping in the hypervisor (all the memory is mapped). When updating data with MMU/D-cache off the normal approach is: 1) Remove any dirty lines from the cache, otherwise they may get evicted while updating the memory and override any value written with MMU off. 2) Update the memory 3) Remove any lines that may have been speculated so when you turn onthe MMU and D-cache, U-boot can obverse the correct data. Step 1 is only necessary if you are going to write outside of the loaded Image (BSS is not part of it). You most likely already have similar steps in U-boot for other part of the memory access with MMU/D-Cache off. So I think U-boot is the best place to invalidate the cache before issuing the hypercall. Cheers, -- Julien Grall, From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:53:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:53:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0EL-0005hL-UP; Wed, 10 Jun 2020 12:53:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0EK-0005hF-B1 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:53:20 +0000 X-Inumbo-ID: 5b01c907-ab19-11ea-b42d-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5b01c907-ab19-11ea-b42d-12813bfff9fa; Wed, 10 Jun 2020 12:53:18 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9E4A720734; Wed, 10 Jun 2020 12:53:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591793597; bh=fhb/IE+L+6oFamjPqDHVhaK35ERv6i0wGNU4Jy9uwFk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=zMnTDiyVaZJX4RuGFKnokSZmemtzflLkxH8CTOZN2A19y+hR4IpivNMIh5mqm0Opl DtjyhkFiASBibYqh4Pp7oky8yxjcJWQWxmFlmBMvinCkxVBLktcsoYN75eFAeqn9zk aSKe+D96bmnfldl06TgmpvMjA6gDfusNOktXwSwQ= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jj0EF-001n7x-Rw; Wed, 10 Jun 2020 13:53:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 10 Jun 2020 13:53:15 +0100 From: Marc Zyngier To: CodeWiz2280 Subject: Re: Keystone Issue In-Reply-To: References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <32FA85C2-7685-49D2-875B-9FA1C138C92A@arm.com> <5C2DB5F7-832E-4B02-A99A-8B5C7CEC7645@arm.com> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: codewiz2280@gmail.com, Bertrand.Marquis@arm.com, julien@xen.org, sstabellini@kernel.org, xen-devel@lists.xenproject.org, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-10 13:39, CodeWiz2280 wrote: [...] > The problem is that a hack may be my only solution to getting this > working on this platform. If TI says that they don't support it then > i'm stuck. Just to summarize the problem, we believe that the GIC is > seeing secure accesses from dom0 when they should be non-secure. This Not necessarily just dom0. The hypothesis is that accesses to the GICV and/or GICD regions from a non-secure guest are treated as secure. My hunch is that it is only GICV that gets messed with, as you seem to solve it by writing to GICC. > is causing the VGIC ack to be non-functional from dom0. We would > need a firmware that supports both secure and non-secure accesses. Not exactly. You'd need the bridge between the CPU and the GIC to honor NS bit passed on the bus (AXI or otherwise). That is assuming that: - the NS attribute is actually present on the interconnect - the HW is configurable - our "finger in the air" analysis is actually correct As for the last point, only someone with access to the RTL could tell you... > The Xen code gets to "gicv2_guest_irq_end()" where it executes > "gicv2_eoi_irq()", but then we had to add the deactivate > "gicv2_dir_irq" to clear the virtual interrupt manually to get things > going again. Also known as "priority drop" and "deactivation". You may want to use architectural terms when explaining this to HW people. M. -- Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:55:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:55:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0Gq-0005p3-Bf; Wed, 10 Jun 2020 12:55:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0Gp-0005ox-Mi for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:55:55 +0000 X-Inumbo-ID: b8086826-ab19-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b8086826-ab19-11ea-bca7-bc764e2007e4; Wed, 10 Jun 2020 12:55:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BaUf52Xf60Lt9YRFxQGC4duA7YE8PGRatMmjk/Ba2Uw=; b=gXzpxVnJgS1mz1SarfSkkDSS7 qLx36yC+3xj/7Du3k0UHGWXXS8XNa0VAXD0o35j6zeU3Fgua8quYXo2C587Bke1vsIuTHqFHOLKCj 4ILN+llXtcVAhrGl/XG1JYigZMwZ4K35E9sRp+iytjbg7Xu7n26tukQLnMfqFbRE/hu1A=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0Gn-0007FX-Cj; Wed, 10 Jun 2020 12:55:53 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jj0Gn-0001hH-1J; Wed, 10 Jun 2020 12:55:53 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jj0Gn-0007ZY-0Y; Wed, 10 Jun 2020 12:55:53 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 150945: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:regression linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=a5ad5742f671de906adbf29fbedf0a04705cebad X-Osstest-Versions-That: linux=abfbb29297c27e3f101f348dc9e467b0fe70f919 From: osstest service owner Date: Wed, 10 Jun 2020 12:55:53 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150945 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/150945/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 150931 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150931 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150931 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150931 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150931 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150931 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150931 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150931 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150931 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux a5ad5742f671de906adbf29fbedf0a04705cebad baseline version: linux abfbb29297c27e3f101f348dc9e467b0fe70f919 Last test of basis 150931 2020-06-09 00:40:27 Z 1 days Testing same since 150945 2020-06-09 17:08:56 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Morton Borislav Petkov Brian Cain Christian Borntraeger Christoph Hellwig Christoph Lameter Daniel Thompson David S. Miller Dmitry Safonov Greg Ungerer Josh Poimboeuf Linus Torvalds Luis Chamberlain Mark Gross Michael Ellerman (powerpc) Michel Lespinasse Mike Rapoport Neelima Krishnan Oleg Nesterov Rafael Aquini Rafael J. Wysocki Stephen Rothwell Steven Rostedt (VMware) Sven Schnelle Thomas Gleixner jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 3289 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 10 12:58:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 12:58:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0JZ-00060a-TU; Wed, 10 Jun 2020 12:58:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0JZ-00060V-31 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 12:58:45 +0000 X-Inumbo-ID: 1db3337c-ab1a-11ea-b42f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1db3337c-ab1a-11ea-b42f-12813bfff9fa; Wed, 10 Jun 2020 12:58:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ypaabz3MyQhwB1jtzoYnE928VskRiyBmbBymtak8xno=; b=3buah2BdDn2fczthROP/3iblx0 zH+5dGqhhZroS+J9n/P89MqS/M4M/TFwK3+CAIUL3Armx17g6rykWY+II7TOL1w11FLsUio9nzbEK m7RIeS8etkjBkgjHYcUwekIpl/XMbJGnFCKjCgry1/00T4LoEs04Wk1SCcXN1Ema2d3k=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0JY-0007Hx-4Y; Wed, 10 Jun 2020 12:58:44 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jj0JX-0006iQ-UO; Wed, 10 Jun 2020 12:58:44 +0000 Subject: Re: Keystone Issue To: CodeWiz2280 , Bertrand Marquis References: <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <32FA85C2-7685-49D2-875B-9FA1C138C92A@arm.com> <5C2DB5F7-832E-4B02-A99A-8B5C7CEC7645@arm.com> From: Julien Grall Message-ID: <8afa2936-69c7-c481-fdf5-e578582c15e2@xen.org> Date: Wed, 10 Jun 2020 13:58:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , nd , Stefano Stabellini , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10/06/2020 13:39, CodeWiz2280 wrote: >>>> So the only way to solve this is actually to do the interrupt >>>> deactivate inside Xen (using a maintenance interrupt). >>> >>> That's a terrible hack, and one that would encourage badly integrated HW. >>> I appreciate the need to "make things work", but I'd be wary of putting >>> this in released SW. Broken HW must die. I have written more than my share >>> of these terrible hacks (see TX1 support), and I deeply regret it, as >>> it has only given Si vendors an excuse not to fix things. >> >> Fully agree and I also had to do some hacks for the TX1 ;-) >> >>> >>>> I remember that I also had to do something specific for the >>>> configuration of edge/level and priorities to have an almost proper >>>> behaviour. >>> >>> Well, the moment the GIC observes secure accesses when they should be >>> non-secure, all bets are off and you have to resort to the above hacks. >>> The fun part is that if you have secure SW running on this platform, >>> you can probably DoS it from non-secure. It's good, isn't it? >> >> Definitely is but if I remember correctly they have 2 kind of SoC: one that can be only used in non-secure and an other which is meant to be use with secure and non secure. >> >> Bertrand >> >>> >>>> Sadly I have no access to the code anymore, so I would need to guess >>>> back what that was.. >>> >>> I'd say this *is* a good thing. > The problem is that a hack may be my only solution to getting this > working on this platform. If TI says that they don't support it then > i'm stuck. OOI, what's your end goal for Xen on Keystone? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 10 13:22:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 13:22:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0gW-0008Rs-Rn; Wed, 10 Jun 2020 13:22:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0gV-0008Rn-JV for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 13:22:27 +0000 X-Inumbo-ID: 6cf64318-ab1d-11ea-bb8b-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6cf64318-ab1d-11ea-bb8b-bc764e2007e4; Wed, 10 Jun 2020 13:22:26 +0000 (UTC) Received: from nodbug.lucina.net (78-141-76-187.dynamic.orange.sk [78.141.76.187]) by smtp.lucina.net (Postfix) with ESMTPSA id 7200E122804; Wed, 10 Jun 2020 15:22:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1591795345; bh=ISrEXEgbgbprbZHOuCt2lv8qBuL8OIAh7TmyZYfsp4E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SBYEk0tOaEovxg2jVWoFcdA2JbV9kzKhP9Yv+UHaHyrIk7BSXikshszZb2dXxL+7p qy8BGQVlQav5uenaL9yoB/QpwTCr4Z1JHf7mFu0063f4BbjI/ldZ99qpY9GL+/q65Q xrZo33tDK9W4qsnlB3uoRAilgZqShGQylxXyopJv0byelFzim2phGLDRp/K9rhZ3Fv bGiQH+oWGOQ6Fv4Ot29GTc5x7fizb3eQQAeRfBbo+n7BRwM2MXKlXiKhcJX3FpUwIK dE14rwd8+oOZCbqGhlU3HmGkXHZ+mdNK1go65DDxx5psyxz3CSS45ZqZpEIsFDPlKF la5U3NdQ83jEg== Received: by nodbug.lucina.net (Postfix, from userid 1000) id 2D052265E722; Wed, 10 Jun 2020 15:22:25 +0200 (CEST) Date: Wed, 10 Jun 2020 15:22:25 +0200 From: Martin Lucina To: Andrew Cooper Subject: Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table Message-ID: <20200610132225.GA16839@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , Andrew Cooper , xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org References: <20200609094425.GB9734@nodbug.lucina.net> <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tuesday, 09.06.2020 at11:22, Andrew Cooper wrote: > There is a little bit of history here... > > GNTTABOP_setup_table was the original PV way of doing things (specify > size as an input, get a list of frames as an output to map), and > XENMAPSPACE_grant_table was the original HVM way of doing things (as > mapping is the other way around - I specify a GFN which I'd like to turn > into a grant table mapping). > > When grant v2 came along, it was only XENMAPSPACE_grant_table updated to > be compatible. i.e. you have to use XENMAPSPACE_grant_table to map the > status frames even if you used GNTTABOP_setup_table previously. > > It is a mistake that GNTTABOP_setup_table was usable in HVM guests to > being with. Returning -1 is necessary to avoid an information leak (the > physical address of the frames making up the grant table) which an HVM > guest shouldn't, and has no use knowing. > > An with that note, ARM is extra special because the grant API is > specified to use host physical addresses rather than guest physical (at > least for dom0, for reasons of there generally not being an IOMMU), > which is why it does use the old PV way. > > It is all a bit of a mess. Thanks for explaining, this is helpful. So, going with the grant v2 ABI, is there a modern equivalent of GNTTABOP_get_status_frames? Reading memory.h I'm guessing that it might be XENMEM_add_to_physmap with space=XENMAPSPACE_grant_table and idx=(XENMAPIDX_grant_table_status + N) where N is the frame I want, but this is not explicitly mentioned anywhere and Linux uses the GNTTABOP mechanism. Further to that, what is the format of the grant status frames? grant_table.h doesn't have much to say about it. And lastly, given that I want the v2 grant ABI exclusively, I presume it's sufficient to call GNTTABOP_set_version (version=2) first thing and abort if it failed? Presumably the default is always v1 at start of day? Thanks, -mato From xen-devel-bounces@lists.xenproject.org Wed Jun 10 13:41:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 13:41:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0yS-0001lk-JN; Wed, 10 Jun 2020 13:41:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj0yQ-0001lQ-FT for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 13:40:58 +0000 X-Inumbo-ID: 005fcfe6-ab20-11ea-b441-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 005fcfe6-ab20-11ea-b441-12813bfff9fa; Wed, 10 Jun 2020 13:40:52 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: mcqXY4eDf3smpv7yilUtFR0V6rTDEP04Yid3QsdysGtdhas2vtoHzBJDiSHuQ3AlLRYLyZaW6F huATiSVfbjCIo/vvGpQ9eXOd+aobzD4S3d77Dtw2ff06wHDrxp8kZOaVhFBhh8b0Zn3ONYoxH1 LGs1LH7qrFCD46St7bdcnLhHYG4Y23vfCc8q3vJWCQp8vAqqKpFWvUErWQCNNqVl++Ra5EZdf+ SgfsanppFI0KrhqNSdFyr78za3OOBPcsEgncD03ROPay9UdlWzzU7nk6Jcyinug8uog47I7TQF EbI= X-SBRS: 2.7 X-MesageID: 19684861 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="19684861" Subject: Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table To: Martin Lucina , , References: <20200609094425.GB9734@nodbug.lucina.net> <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> <20200610132225.GA16839@nodbug.lucina.net> From: Andrew Cooper Message-ID: <46e87834-bf47-4003-1f32-89a47255155d@citrix.com> Date: Wed, 10 Jun 2020 14:40:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200610132225.GA16839@nodbug.lucina.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10/06/2020 14:22, Martin Lucina wrote: > On Tuesday, 09.06.2020 at 11:22, Andrew Cooper wrote: >> There is a little bit of history here... >> >> GNTTABOP_setup_table was the original PV way of doing things (specify >> size as an input, get a list of frames as an output to map), and >> XENMAPSPACE_grant_table was the original HVM way of doing things (as >> mapping is the other way around - I specify a GFN which I'd like to turn >> into a grant table mapping). >> >> When grant v2 came along, it was only XENMAPSPACE_grant_table updated to >> be compatible.  i.e. you have to use XENMAPSPACE_grant_table to map the >> status frames even if you used GNTTABOP_setup_table previously. >> >> It is a mistake that GNTTABOP_setup_table was usable in HVM guests to >> being with.  Returning -1 is necessary to avoid an information leak (the >> physical address of the frames making up the grant table) which an HVM >> guest shouldn't, and has no use knowing. >> >> An with that note, ARM is extra special because the grant API is >> specified to use host physical addresses rather than guest physical (at >> least for dom0, for reasons of there generally not being an IOMMU), >> which is why it does use the old PV way. >> >> It is all a bit of a mess. > Thanks for explaining, this is helpful. > > So, going with the grant v2 ABI, is there a modern equivalent of > GNTTABOP_get_status_frames? Reading memory.h I'm guessing that it might be > XENMEM_add_to_physmap with space=XENMAPSPACE_grant_table and > idx=(XENMAPIDX_grant_table_status + N) where N is the frame I want, but > this is not explicitly mentioned anywhere and Linux uses the GNTTABOP > mechanism. > > Further to that, what is the format of the grant status frames? > grant_table.h doesn't have much to say about it. > > And lastly, given that I want the v2 grant ABI exclusively, I presume it's > sufficient to call GNTTABOP_set_version (version=2) first thing and abort > if it failed? Presumably the default is always v1 at start of day? What kind of guests are you trying to target here? Since my reply, I tried to experiment, and I think you're forced to use GNTTABOP_setup_table/GNTTABOP_get_status_frames for x86 PV guests, and XENMEM_add_to_physmap for x86 HVM/PVH guests. You can't depend on version 2 being available.  Its not available for ARM at all, and may be disabled for security reasons on x86 (there was some extended fun with transitive grants in the past, and we offered "totally disable grant v2" as one mitigation). Use v1 unless you have a specific need to use v2 (transitive grants or subpage copies, or support for >16TB VMs (HVM) or hosts (PV)).  Amongst other things, its far more simple to use correctly.  (v2 devolves to infinite loops to use correctly, because there is no way to do an atomic option covering both the flags and status entries at the same time.) If you need to use v2, you must cleanly cope with it not being available, and fall back to v1. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 10 13:56:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 13:56:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1D4-0002nc-0a; Wed, 10 Jun 2020 13:56:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1D2-0002nO-Ua for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 13:56:04 +0000 X-Inumbo-ID: 1ef3cee2-ab22-11ea-b449-12813bfff9fa Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1ef3cee2-ab22-11ea-b449-12813bfff9fa; Wed, 10 Jun 2020 13:56:03 +0000 (UTC) Received: from nodbug.lucina.net (78-141-76-187.dynamic.orange.sk [78.141.76.187]) by smtp.lucina.net (Postfix) with ESMTPSA id 0C91D122804; Wed, 10 Jun 2020 15:56:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1591797362; bh=dQM1v/InNxn2/aJ4PouUn9hXkCZr2u+Zl52zCY32cuY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pOuQUOvlnw+gpAgMWeGC/cj0tznQq9o3pPrIxd3B4J7/JX2aWxbL0AZqiB1ZdSJt9 3RVDVR0TDb4w9urLfnKqXfdg+aXnRdxJtw4XGtwmDWymfBWzDcqs7udJUK3h+KTgiK tDSHbpddSAffTw6mnd6/rUc/+bWrD3JYCTSVG8xXH/n7Biuz/WAfBuH/U8Jw5mSY/s niJ1uTvx69XmjqzxM0jpAuEGSmVXDeVLZRPzTN3N6rlUSBDOJoguHNs7I1nnONmSfK X22uPtqLB+ko3j9zG9yWXixpih7FSIlOLo3hhSlA/qCzXss9CuxbBND8Wcmj1uUvcz dDlr5ajmoPeLw== Received: by nodbug.lucina.net (Postfix, from userid 1000) id E448D265E722; Wed, 10 Jun 2020 15:56:01 +0200 (CEST) Date: Wed, 10 Jun 2020 15:56:01 +0200 From: Martin Lucina To: Andrew Cooper Subject: Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table Message-ID: <20200610135601.GB16839@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , Andrew Cooper , xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org References: <20200609094425.GB9734@nodbug.lucina.net> <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> <20200610132225.GA16839@nodbug.lucina.net> <46e87834-bf47-4003-1f32-89a47255155d@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <46e87834-bf47-4003-1f32-89a47255155d@citrix.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wednesday, 10.06.2020 at14:40, Andrew Cooper wrote: > > So, going with the grant v2 ABI, is there a modern equivalent of > > GNTTABOP_get_status_frames? Reading memory.h I'm guessing that it might be > > XENMEM_add_to_physmap with space=XENMAPSPACE_grant_table and > > idx=(XENMAPIDX_grant_table_status + N) where N is the frame I want, but > > this is not explicitly mentioned anywhere and Linux uses the GNTTABOP > > mechanism. > > > > Further to that, what is the format of the grant status frames? > > grant_table.h doesn't have much to say about it. > > > > And lastly, given that I want the v2 grant ABI exclusively, I presume it's > > sufficient to call GNTTABOP_set_version (version=2) first thing and abort > > if it failed? Presumably the default is always v1 at start of day? > > What kind of guests are you trying to target here? PVHv2 only. x86_64 only for now, though the code should remain easily portable to at least ARM64, should someone decide they need that. > Since my reply, I tried to experiment, and I think you're forced to use > GNTTABOP_setup_table/GNTTABOP_get_status_frames for x86 PV guests, and > XENMEM_add_to_physmap for x86 HVM/PVH guests. > > You can't depend on version 2 being available. Its not available for > ARM at all, and may be disabled for security reasons on x86 (there was > some extended fun with transitive grants in the past, and we offered > "totally disable grant v2" as one mitigation). I don't need v2 at all, I was just going by the comments in grant_table.h, which read: "Version 1 of the grant table entry structure is maintained purely for backwards compatibility. New guests should use version 2." Grant status frames are a v2-only thing, right? Or can I use v1 and ask for grant status frames? -mato From xen-devel-bounces@lists.xenproject.org Wed Jun 10 14:11:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 14:11:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1RR-0004ZQ-AY; Wed, 10 Jun 2020 14:10:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1RQ-0004ZL-KU for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 14:10:56 +0000 X-Inumbo-ID: 333a76e2-ab24-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 333a76e2-ab24-11ea-bb8b-bc764e2007e4; Wed, 10 Jun 2020 14:10:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 36262ABC7; Wed, 10 Jun 2020 14:10:58 +0000 (UTC) From: Juergen Gross To: xen-devel@lists.xenproject.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH] efi: avoid error message when booting under Xen Date: Wed, 10 Jun 2020 16:10:52 +0200 Message-Id: <20200610141052.13258-1-jgross@suse.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Peter Jones , Bartlomiej Zolnierkiewicz Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" efifb_probe() will issue an error message in case the kernel is booted as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT isn't set. Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB") Signed-off-by: Juergen Gross --- drivers/video/fbdev/efifb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index 65491ae74808..f5eccd1373e9 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -453,7 +453,7 @@ static int efifb_probe(struct platform_device *dev) info->apertures->ranges[0].base = efifb_fix.smem_start; info->apertures->ranges[0].size = size_remap; - if (efi_enabled(EFI_BOOT) && + if (efi_enabled(EFI_BOOT) && !efi_enabled(EFI_PARAVIRT) && !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) { if ((efifb_fix.smem_start + efifb_fix.smem_len) > (md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) { -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 14:21:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 14:21:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1bm-0005US-9J; Wed, 10 Jun 2020 14:21:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1bk-0005UN-Rf for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 14:21:36 +0000 X-Inumbo-ID: b08605f2-ab25-11ea-bca7-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b08605f2-ab25-11ea-bca7-bc764e2007e4; Wed, 10 Jun 2020 14:21:35 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: H9Vs+9QD9Q/3txKlxrcRmQxt3YsaVlpyjmrZS71lHV1YxX7WY6mOU8l2kM7OCFYhNaSq5cfzBA zF1aCXxsEt2aILvDo6BVUuNSMZv+m4qPt2vBhD6qe7Ns5Z42qy7PInzqz/89x1JvOxeW6U8ERS Y5zGM77UmNrtKovNiZjwgAlMwS9Fn3UZy8WFuyOkQaKvmtag3/BGUiNjiIA4Ce8OJo7b69eeL2 HpW3UCMRl6vmVcKwXMQv87EiN259sIGJM1AmBoYvQAKzbYhJVp+bAWdlvjihJVkOB/PceohnUi itI= X-SBRS: 2.7 X-MesageID: 20451479 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="20451479" Subject: Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table To: Martin Lucina , , References: <20200609094425.GB9734@nodbug.lucina.net> <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> <20200610132225.GA16839@nodbug.lucina.net> <46e87834-bf47-4003-1f32-89a47255155d@citrix.com> <20200610135601.GB16839@nodbug.lucina.net> From: Andrew Cooper Message-ID: <6b2a0091-2c56-895c-762d-719e5796985d@citrix.com> Date: Wed, 10 Jun 2020 15:21:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200610135601.GB16839@nodbug.lucina.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10/06/2020 14:56, Martin Lucina wrote: > On Wednesday, 10.06.2020 at 14:40, Andrew Cooper wrote: >>> So, going with the grant v2 ABI, is there a modern equivalent of >>> GNTTABOP_get_status_frames? Reading memory.h I'm guessing that it might be >>> XENMEM_add_to_physmap with space=XENMAPSPACE_grant_table and >>> idx=(XENMAPIDX_grant_table_status + N) where N is the frame I want, but >>> this is not explicitly mentioned anywhere and Linux uses the GNTTABOP >>> mechanism. >>> >>> Further to that, what is the format of the grant status frames? >>> grant_table.h doesn't have much to say about it. >>> >>> And lastly, given that I want the v2 grant ABI exclusively, I presume it's >>> sufficient to call GNTTABOP_set_version (version=2) first thing and abort >>> if it failed? Presumably the default is always v1 at start of day? >> What kind of guests are you trying to target here? > PVHv2 only. x86_64 only for now, though the code should remain easily > portable to at least ARM64, should someone decide they need that. > >> Since my reply, I tried to experiment, and I think you're forced to use >> GNTTABOP_setup_table/GNTTABOP_get_status_frames for x86 PV guests, and >> XENMEM_add_to_physmap for x86 HVM/PVH guests. >> >> You can't depend on version 2 being available.  Its not available for >> ARM at all, and may be disabled for security reasons on x86 (there was >> some extended fun with transitive grants in the past, and we offered >> "totally disable grant v2" as one mitigation). > I don't need v2 at all, I was just going by the comments in grant_table.h, > which read: "Version 1 of the grant table entry structure is maintained > purely for backwards compatibility. New guests should use version 2." Ha... That comment wasn't written with the benefit of hindsight. IMO, grant v2 is not worth the astounding quantity of XSAs its implementation actually gave us, or the complexity of the resulting code. > Grant status frames are a v2-only thing, right? Correct. The split status frames was new in v2, in an attempt to reduce cacheline ping-pong. The downside is that the guest needs an unbounded loop trying to make a change to the grant table while ensuring that the flags in the status frame don't change asynchronously. ~Andrew P.S. In some theoretical world, I was hoping to have something to live in https://xenbits.xen.org/docs/latest/guest-guide/index.html on this subject.  Do you mind if I use you as a retroactive guineapig if/when some documentation were to appear? From xen-devel-bounces@lists.xenproject.org Wed Jun 10 14:29:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 14:29:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1jZ-0005mH-6B; Wed, 10 Jun 2020 14:29:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1jX-0005mB-7c for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 14:29:39 +0000 X-Inumbo-ID: d051aeda-ab26-11ea-b44c-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d051aeda-ab26-11ea-b44c-12813bfff9fa; Wed, 10 Jun 2020 14:29:38 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 28LQ6243xPtLOg9Tx0FeyTmA79gAsNnUIEDAkrnnC4DYHNuij2MohtLdD0CRCEcQBSktJNWbKf K/kJvMbUKD7cqhg884NMWgxThL4qb/qWh5fRCWj1BFbxsttg4lTKv4bmNMDDKgujjHP3KSQ555 Ddcvatd/MbQGt7DD18P5PJMJcbOl8jYflwyjoAzMtvATiKyUu7BwIEBFe7H98noHtkMpI7YyCz FcFfpzd5yHwANiQPyA7iHXscGBRqE+mYaZ8LB6ioXYKHbYu3/grxfm+G9JouOMhLnKORr7b1fQ 3Oo= X-SBRS: 2.7 X-MesageID: 20039436 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="20039436" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v2 0/2] x86/passthrough: fixes for PVH dom0 edge triggered interrupts Date: Wed, 10 Jun 2020 16:29:21 +0200 Message-ID: <20200610142923.9074-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, Small series with two bugfixes to correctly handle edge triggered interrupts on PVH dom0. for-4.14 reasoning: fixes are isolated to PVH dom0 specific passthrough code (IDENTITY_GSI kind of bindings), and hence shouldn't affect passthrough to HVM domUs. Without these fixes the RTC timer won't work correctly on a PVH dom0 because it's edge triggered (GSI 8). Roger Pau Monne (2): x86/passthrough: do not assert edge triggered GSIs for PVH dom0 x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask xen/arch/x86/hvm/irq.c | 13 ++++++++----- xen/drivers/passthrough/io.c | 24 +++++++++++++++--------- xen/include/asm-x86/hvm/irq.h | 2 ++ 3 files changed, 25 insertions(+), 14 deletions(-) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 14:29:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 14:29:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1jd-0005mq-HO; Wed, 10 Jun 2020 14:29:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1jc-0005mB-3K for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 14:29:44 +0000 X-Inumbo-ID: d1b5259a-ab26-11ea-b44c-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d1b5259a-ab26-11ea-b44c-12813bfff9fa; Wed, 10 Jun 2020 14:29:40 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: GJLjP7ff4EuEieDZJLxNjrBIVSzjkb8E/aRLYSRCwvDs0aQ7cM9xfIB3V0T1kwJ4mVLMqOkCzU gG/ukGGjgU8EjEsZVF9MUSyk1jlH8GjxzlRynFmce1eHmkCMkj1ceVoOZlKgylG417kKDMUXX8 vdhb24ldULRaHlusPRMqB4pVOKOTkOSL3ixZS0vcYddO3CGOTHVbZ/nsWxUPHpuaTX8BHk2iLC f6CollDsE8BWm131ni9qc6LS+xPOzrodg6rYbXVHr3YC71daGG5uIs57HB2iRmRo9YAiuxZKvH kIA= X-SBRS: 2.7 X-MesageID: 20039447 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="20039447" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v2 1/2] x86/passthrough: do not assert edge triggered GSIs for PVH dom0 Date: Wed, 10 Jun 2020 16:29:22 +0200 Message-ID: <20200610142923.9074-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200610142923.9074-1-roger.pau@citrix.com> References: <20200610142923.9074-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Edge triggered interrupts do not assert the line, so the handling done in Xen should also avoid asserting it. Asserting the line prevents further edge triggered interrupts on the same vIO-APIC pin from being delivered, since the line is not de-asserted. One case of such kind of interrupt is the RTC timer, which is edge triggered and available to a PVH dom0. Note this should not affect domUs, as it only modifies the behavior of IDENTITY_GSI kind of passed through interrupts. Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper --- Changes since v1: - Compare the triggering against VIOAPIC_{EDGE/LEVEL}_TRIG. --- xen/arch/x86/hvm/irq.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c index 9c8adbc495..fd02cf2e8d 100644 --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -169,9 +169,10 @@ void hvm_pci_intx_deassert( void hvm_gsi_assert(struct domain *d, unsigned int gsi) { + int trig = vioapic_get_trigger_mode(d, gsi); struct hvm_irq *hvm_irq = hvm_domain_irq(d); - if ( gsi >= hvm_irq->nr_gsis ) + if ( gsi >= hvm_irq->nr_gsis || trig < 0 ) { ASSERT_UNREACHABLE(); return; @@ -186,9 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) * to know if the GSI is pending or not. */ spin_lock(&d->arch.hvm.irq_lock); - if ( !hvm_irq->gsi_assert_count[gsi] ) + if ( trig == VIOAPIC_EDGE_TRIG || !hvm_irq->gsi_assert_count[gsi] ) { - hvm_irq->gsi_assert_count[gsi] = 1; + if ( trig == VIOAPIC_LEVEL_TRIG ) + hvm_irq->gsi_assert_count[gsi] = 1; assert_gsi(d, gsi); } spin_unlock(&d->arch.hvm.irq_lock); @@ -196,11 +198,12 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) void hvm_gsi_deassert(struct domain *d, unsigned int gsi) { + int trig = vioapic_get_trigger_mode(d, gsi); struct hvm_irq *hvm_irq = hvm_domain_irq(d); - if ( gsi >= hvm_irq->nr_gsis ) + if ( trig <= VIOAPIC_EDGE_TRIG || gsi >= hvm_irq->nr_gsis ) { - ASSERT_UNREACHABLE(); + ASSERT(trig == VIOAPIC_EDGE_TRIG && gsi < hvm_irq->nr_gsis); return; } -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 14:29:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 14:29:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1jh-0005oD-Pd; Wed, 10 Jun 2020 14:29:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1jh-0005mB-3K for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 14:29:49 +0000 X-Inumbo-ID: d394e594-ab26-11ea-b44c-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d394e594-ab26-11ea-b44c-12813bfff9fa; Wed, 10 Jun 2020 14:29:44 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: D4DDbPAQIkhAcN7IgbISu0+cSqAjP8J12kawIFw0UslmU2T6Hr2bFH4GfAn/AuDorrBMJkuqfP /UobpnxSz8qST9WKNbI17BIQ+66CEt7DAujFAHd1bDfU+t4ixyDItt12OPWL9aJCqsPkGi3Bvq w4EMNlJv0XFwoMsKgYEphIGL9oZn0gRTeUhdwFfSp7BJADP6Y/SlDsRyeKI0uRqA+X4UJjjMai vnvB2ymqUGFbhI8M+QY2Wi+nvdW1g28uJR9Yti/WMVRf4uNPfDDDXBTMJxLD1P9NzrN07koVBg vQo= X-SBRS: 2.7 X-MesageID: 19690573 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="19690573" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask Date: Wed, 10 Jun 2020 16:29:23 +0200 Message-ID: <20200610142923.9074-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200610142923.9074-1-roger.pau@citrix.com> References: <20200610142923.9074-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" There's no need to setup a timer for GSIs that are edge triggered, since those don't require any EIO or unmask, and hence couldn't block other interrupts. Note this is only used by PVH dom0, that can setup the passthrough of edge triggered interrupts from the vIO-APIC. One example of such kind of interrupt that can be used by a PVH dom0 would be the RTC timer. While there introduce an out label to do the unlock and reduce code duplication. Signed-off-by: Roger Pau Monné --- Changes since v1: - Introduce an out label that does the unlock. --- xen/drivers/passthrough/io.c | 24 +++++++++++++++--------- xen/include/asm-x86/hvm/irq.h | 2 ++ 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c index b292e79382..6b1305a3e5 100644 --- a/xen/drivers/passthrough/io.c +++ b/xen/drivers/passthrough/io.c @@ -138,7 +138,8 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci *pirq_dpci) bool pt_irq_need_timer(uint32_t flags) { - return !(flags & (HVM_IRQ_DPCI_GUEST_MSI | HVM_IRQ_DPCI_TRANSLATE)); + return !(flags & (HVM_IRQ_DPCI_GUEST_MSI | HVM_IRQ_DPCI_TRANSLATE | + HVM_IRQ_DPCI_NO_EOI)); } static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci, @@ -558,6 +559,12 @@ int pt_irq_create_bind( */ ASSERT(!mask); share = trigger_mode; + if ( trigger_mode == VIOAPIC_EDGE_TRIG ) + /* + * Edge IO-APIC interrupt, no EOI or unmask to perform + * and hence no timer needed. + */ + pirq_dpci->flags |= HVM_IRQ_DPCI_NO_EOI; } } @@ -897,17 +904,13 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) send_guest_pirq(d, pirq); if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI ) - { - spin_unlock(&d->event_lock); - return; - } + goto out; } if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI ) { vmsi_deliver_pirq(d, pirq_dpci); - spin_unlock(&d->event_lock); - return; + goto out; } list_for_each_entry ( digl, &pirq_dpci->digl_list, list ) @@ -920,6 +923,8 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI ) { hvm_gsi_assert(d, pirq->pirq); + if ( pirq_dpci->flags & HVM_IRQ_DPCI_NO_EOI ) + goto out; pirq_dpci->pending++; } @@ -927,8 +932,7 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) { /* for translated MSI to INTx interrupt, eoi as early as possible */ __msi_pirq_eoi(pirq_dpci); - spin_unlock(&d->event_lock); - return; + goto out; } /* @@ -941,6 +945,8 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) ASSERT(pt_irq_need_timer(pirq_dpci->flags)); set_timer(&pirq_dpci->timer, NOW() + PT_IRQ_TIME_OUT); } + + out: spin_unlock(&d->event_lock); } diff --git a/xen/include/asm-x86/hvm/irq.h b/xen/include/asm-x86/hvm/irq.h index d306cfeade..532880d497 100644 --- a/xen/include/asm-x86/hvm/irq.h +++ b/xen/include/asm-x86/hvm/irq.h @@ -121,6 +121,7 @@ struct dev_intx_gsi_link { #define _HVM_IRQ_DPCI_GUEST_PCI_SHIFT 4 #define _HVM_IRQ_DPCI_GUEST_MSI_SHIFT 5 #define _HVM_IRQ_DPCI_IDENTITY_GSI_SHIFT 6 +#define _HVM_IRQ_DPCI_NO_EOI_SHIFT 7 #define _HVM_IRQ_DPCI_TRANSLATE_SHIFT 15 #define HVM_IRQ_DPCI_MACH_PCI (1u << _HVM_IRQ_DPCI_MACH_PCI_SHIFT) #define HVM_IRQ_DPCI_MACH_MSI (1u << _HVM_IRQ_DPCI_MACH_MSI_SHIFT) @@ -129,6 +130,7 @@ struct dev_intx_gsi_link { #define HVM_IRQ_DPCI_GUEST_PCI (1u << _HVM_IRQ_DPCI_GUEST_PCI_SHIFT) #define HVM_IRQ_DPCI_GUEST_MSI (1u << _HVM_IRQ_DPCI_GUEST_MSI_SHIFT) #define HVM_IRQ_DPCI_IDENTITY_GSI (1u << _HVM_IRQ_DPCI_IDENTITY_GSI_SHIFT) +#define HVM_IRQ_DPCI_NO_EOI (1u << _HVM_IRQ_DPCI_NO_EOI_SHIFT) #define HVM_IRQ_DPCI_TRANSLATE (1u << _HVM_IRQ_DPCI_TRANSLATE_SHIFT) struct hvm_gmsi_info { -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 14:39:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 14:39:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1tK-0006t3-Pz; Wed, 10 Jun 2020 14:39:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1tJ-0006sy-BM for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 14:39:45 +0000 X-Inumbo-ID: 38c5919c-ab28-11ea-b452-12813bfff9fa Received: from 9.mo7.mail-out.ovh.net (unknown [46.105.60.248]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 38c5919c-ab28-11ea-b452-12813bfff9fa; Wed, 10 Jun 2020 14:39:43 +0000 (UTC) Received: from player159.ha.ovh.net (unknown [10.108.35.110]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 45EC916B3C3 for ; Wed, 10 Jun 2020 16:39:42 +0200 (CEST) Received: from kaod.org (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player159.ha.ovh.net (Postfix) with ESMTPSA id 2FAE61338D640; Wed, 10 Jun 2020 14:39:22 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-103G00574e510ee-3009-4990-8158-7d496a54c194,22147FB2222D4A9FBAB43F4367B50A808946A5A0) smtp.auth=groug@kaod.org Date: Wed, 10 Jun 2020 16:39:21 +0200 From: Greg Kurz To: Vladimir Sementsov-Ogievskiy Subject: Re: [PATCH v10 1/9] error: auto propagated local_err Message-ID: <20200610163921.28d824aa@bahia.lan> In-Reply-To: <20200317151625.20797-2-vsementsov@virtuozzo.com> References: <20200317151625.20797-1-vsementsov@virtuozzo.com> <20200317151625.20797-2-vsementsov@virtuozzo.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Ovh-Tracer-Id: 17342517742431344979 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgkedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfgjfhfogggtgfesthhqredtredtjeenucfhrhhomhepifhrvghgucfmuhhriicuoehgrhhouhhgsehkrghougdrohhrgheqnecuggftrfgrthhtvghrnhepueekjeekiefffedtveeukedvteejgeeivefhgfejgfdtleduvdfgfeelkeeuveeunecukfhppedtrddtrddtrddtpdekvddrvdehfedrvddtkedrvdegkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhduheelrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepghhrohhugheskhgrohgurdhorhhgpdhrtghpthhtohepgigvnhdquggvvhgvlheslhhishhtshdrgigvnhhprhhojhgvtghtrdhorhhg X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Stefano Stabellini , Laszlo Ersek , qemu-block@nongnu.org, Paul Durrant , armbru@redhat.com, Philippe =?UTF-8?B?TWF0aGlldS1EYXVkw6k=?= , Christian Schoenebeck , qemu-devel@nongnu.org, Max Reitz , Gerd Hoffmann , Stefan Hajnoczi , Anthony Perard , xen-devel@lists.xenproject.org, Eric Blake , Michael Roth , Stefan Berger Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 17 Mar 2020 18:16:17 +0300 Vladimir Sementsov-Ogievskiy wrote: > Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of > functions with an errp OUT parameter. >=20 > It has three goals: >=20 > 1. Fix issue with error_fatal and error_prepend/error_append_hint: user > can't see this additional information, because exit() happens in > error_setg earlier than information is added. [Reported by Greg Kurz] >=20 I have more of these coming and I'd really like to use ERRP_AUTO_PROPAGATE. It seems we have a consensus on the macro itself but this series is gated by the conversion of the existing code base. What about merging this patch separately so that people can start using it at least ? > 2. Fix issue with error_abort and error_propagate: when we wrap > error_abort by local_err+error_propagate, the resulting coredump will > refer to error_propagate and not to the place where error happened. > (the macro itself doesn't fix the issue, but it allows us to [3.] drop > the local_err+error_propagate pattern, which will definitely fix the > issue) [Reported by Kevin Wolf] >=20 > 3. Drop local_err+error_propagate pattern, which is used to workaround > void functions with errp parameter, when caller wants to know resulting > status. (Note: actually these functions could be merely updated to > return int error code). >=20 > To achieve these goals, later patches will add invocations > of this macro at the start of functions with either use > error_prepend/error_append_hint (solving 1) or which use > local_err+error_propagate to check errors, switching those > functions to use *errp instead (solving 2 and 3). >=20 > Signed-off-by: Vladimir Sementsov-Ogievskiy > Reviewed-by: Paul Durrant > Reviewed-by: Greg Kurz > Reviewed-by: Eric Blake > --- >=20 > Cc: Eric Blake > Cc: Kevin Wolf > Cc: Max Reitz > Cc: Greg Kurz > Cc: Christian Schoenebeck > Cc: Stefan Hajnoczi > Cc: Stefano Stabellini > Cc: Anthony Perard > Cc: Paul Durrant > Cc: "Philippe Mathieu-Daud=C3=A9" > Cc: Laszlo Ersek > Cc: Gerd Hoffmann > Cc: Stefan Berger > Cc: Markus Armbruster > Cc: Michael Roth > Cc: qemu-devel@nongnu.org > Cc: qemu-block@nongnu.org > Cc: xen-devel@lists.xenproject.org >=20 > include/qapi/error.h | 205 ++++++++++++++++++++++++++++++++++++------- > 1 file changed, 173 insertions(+), 32 deletions(-) >=20 > diff --git a/include/qapi/error.h b/include/qapi/error.h > index ad5b6e896d..30140d9bfe 100644 > --- a/include/qapi/error.h > +++ b/include/qapi/error.h > @@ -15,6 +15,8 @@ > /* > * Error reporting system loosely patterned after Glib's GError. > * > + * =3D Deal with Error object =3D > + * > * Create an error: > * error_setg(&err, "situation normal, all fouled up"); > * > @@ -47,28 +49,91 @@ > * reporting it (primarily useful in testsuites): > * error_free_or_abort(&err); > * > - * Pass an existing error to the caller: > - * error_propagate(errp, err); > - * where Error **errp is a parameter, by convention the last one. > + * =3D Deal with Error ** function parameter =3D > * > - * Pass an existing error to the caller with the message modified: > - * error_propagate_prepend(errp, err); > + * A function may use the error system to return errors. In this case, t= he > + * function defines an Error **errp parameter, by convention the last on= e (with > + * exceptions for functions using ... or va_list). > * > - * Avoid > - * error_propagate(errp, err); > - * error_prepend(errp, "Could not frobnicate '%s': ", name); > - * because this fails to prepend when @errp is &error_fatal. > + * The caller may then pass in the following errp values: > * > - * Create a new error and pass it to the caller: > + * 1. &error_abort > + * Any error will result in abort(). > + * 2. &error_fatal > + * Any error will result in exit() with a non-zero status. > + * 3. NULL > + * No error reporting through errp parameter. > + * 4. The address of a NULL-initialized Error *err > + * Any error will populate errp with an error object. > + * > + * The following rules then implement the correct semantics desired by t= he > + * caller. > + * > + * Create a new error to pass to the caller: > * error_setg(errp, "situation normal, all fouled up"); > * > - * Call a function and receive an error from it: > + * Calling another errp-based function: > + * f(..., errp); > + * > + * =3D=3D Checking success of subcall =3D=3D > + * > + * If a function returns a value indicating an error in addition to sett= ing > + * errp (which is recommended), then you don't need any additional code,= just > + * do: > + * > + * int ret =3D f(..., errp); > + * if (ret < 0) { > + * ... handle error ... > + * return ret; > + * } > + * > + * If a function returns nothing (not recommended for new code), the onl= y way > + * to check success is by consulting errp; doing this safely requires th= e use > + * of the ERRP_AUTO_PROPAGATE macro, like this: > + * > + * int our_func(..., Error **errp) { > + * ERRP_AUTO_PROPAGATE(); > + * ... > + * subcall(..., errp); > + * if (*errp) { > + * ... > + * return -EINVAL; > + * } > + * ... > + * } > + * > + * ERRP_AUTO_PROPAGATE takes care of wrapping the original errp as neede= d, so > + * that the rest of the function can directly use errp (including > + * dereferencing), where any errors will then be propagated on to the or= iginal > + * errp when leaving the function. > + * > + * In some cases, we need to check result of subcall, but do not want to > + * propagate the Error object to our caller. In such cases we don't need > + * ERRP_AUTO_PROPAGATE, but just a local Error object: > + * > + * Receive an error and not pass it: > * Error *err =3D NULL; > - * foo(arg, &err); > + * subcall(arg, &err); > * if (err) { > * handle the error... > + * error_free(err); > * } > * > + * Note that older code that did not use ERRP_AUTO_PROPAGATE would inste= ad need > + * a local Error * variable and the use of error_propagate() to properly= handle > + * all possible caller values of errp. Now this is DEPRECATED* (see belo= w). > + * > + * Note that any function that wants to modify an error object, such as = by > + * calling error_append_hint or error_prepend, must use ERRP_AUTO_PROPAG= ATE, in > + * order for a caller's use of &error_fatal to see the additional inform= ation. > + * > + * In rare cases, we need to pass existing Error object to the caller by= hand: > + * error_propagate(errp, err); > + * > + * Pass an existing error to the caller with the message modified: > + * error_propagate_prepend(errp, err); > + * > + * > * Call a function ignoring errors: > * foo(arg, NULL); > * > @@ -78,26 +143,6 @@ > * Call a function treating errors as fatal: > * foo(arg, &error_fatal); > * > - * Receive an error and pass it on to the caller: > - * Error *err =3D NULL; > - * foo(arg, &err); > - * if (err) { > - * handle the error... > - * error_propagate(errp, err); > - * } > - * where Error **errp is a parameter, by convention the last one. > - * > - * Do *not* "optimize" this to > - * foo(arg, errp); > - * if (*errp) { // WRONG! > - * handle the error... > - * } > - * because errp may be NULL! > - * > - * But when all you do with the error is pass it on, please use > - * foo(arg, errp); > - * for readability. > - * > * Receive and accumulate multiple errors (first one wins): > * Error *err =3D NULL, *local_err =3D NULL; > * foo(arg, &err); > @@ -114,6 +159,61 @@ > * handle the error... > * } > * because this may pass a non-null err to bar(). > + * > + * DEPRECATED* > + * > + * The following pattern of receiving, checking, and then forwarding an = error > + * to the caller by hand is now deprecated: > + * > + * Error *err =3D NULL; > + * foo(arg, &err); > + * if (err) { > + * handle the error... > + * error_propagate(errp, err); > + * } > + * > + * Instead, use ERRP_AUTO_PROPAGATE macro. > + * > + * The old pattern is deprecated because of two things: > + * > + * 1. Issue with error_abort and error_propagate: when we wrap error_abo= rt by > + * local_err+error_propagate, the resulting coredump will refer to > + * error_propagate and not to the place where error happened. > + * > + * 2. A lot of extra code of the same pattern > + * > + * How to update old code to use ERRP_AUTO_PROPAGATE? > + * > + * All you need is to add ERRP_AUTO_PROPAGATE() invocation at function s= tart, > + * than you may safely dereference errp to check errors and do not need = any > + * additional local Error variables or calls to error_propagate(). > + * > + * Example: > + * > + * old code > + * > + * void fn(..., Error **errp) { > + * Error *err =3D NULL; > + * foo(arg, &err); > + * if (err) { > + * handle the error... > + * error_propagate(errp, err); > + * return; > + * } > + * ... > + * } > + * > + * updated code > + * > + * void fn(..., Error **errp) { > + * ERRP_AUTO_PROPAGATE(); > + * foo(arg, errp); > + * if (*errp) { > + * handle the error... > + * return; > + * } > + * ... > + * } > */ > =20 > #ifndef ERROR_H > @@ -322,6 +422,47 @@ void error_set_internal(Error **errp, > ErrorClass err_class, const char *fmt, ...) > GCC_FMT_ATTR(6, 7); > =20 > +typedef struct ErrorPropagator { > + Error *local_err; > + Error **errp; > +} ErrorPropagator; > + > +static inline void error_propagator_cleanup(ErrorPropagator *prop) > +{ > + error_propagate(prop->errp, prop->local_err); > +} > + > +G_DEFINE_AUTO_CLEANUP_CLEAR_FUNC(ErrorPropagator, error_propagator_clean= up); > + > +/* > + * ERRP_AUTO_PROPAGATE > + * > + * This macro exists to assist with proper error handling in a function = which > + * uses an Error **errp parameter. It must be used as the first line of= a > + * function which modifies an error (with error_prepend, error_append_hi= nt, or > + * similar) or which wants to dereference *errp. It is still safe (but > + * useless) to use in other functions. > + * > + * If errp is NULL or points to error_fatal, it is rewritten to point to= a > + * local Error object, which will be automatically propagated to the ori= ginal > + * errp on function exit (see error_propagator_cleanup). > + * > + * After invocation of this macro it is always safe to dereference errp > + * (as it's not NULL anymore) and to add information by error_prepend or > + * error_append_hint (as, if it was error_fatal, we swapped it with a > + * local_error to be propagated on cleanup). > + * > + * Note: we don't wrap the error_abort case, as we want resulting coredu= mp > + * to point to the place where the error happened, not to error_propagat= e. > + */ > +#define ERRP_AUTO_PROPAGATE() \ > + g_auto(ErrorPropagator) _auto_errp_prop =3D {.errp =3D errp}; \ > + do { \ > + if (!errp || errp =3D=3D &error_fatal) { \ > + errp =3D &_auto_errp_prop.local_err; \ > + } \ > + } while (0) > + > /* > * Special error destination to abort on error. > * See error_setg() and error_propagate() for details. From xen-devel-bounces@lists.xenproject.org Wed Jun 10 14:40:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 14:40:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1tu-0007YP-2r; Wed, 10 Jun 2020 14:40:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj1ts-0007YJ-Eu for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 14:40:20 +0000 X-Inumbo-ID: 4e3a459a-ab28-11ea-b457-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4e3a459a-ab28-11ea-b457-12813bfff9fa; Wed, 10 Jun 2020 14:40:19 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: LXLyQSAYIV3y4elC6AA7h3YJiThMVot3oc3SYtuLk3HYYJJ7a0Yr/OsDhz5EWyoYs/V/0b8Vws cEK1vtkKrsGECudqwcXkZq8O73X0LtQ2MRIEDeDk68pkPFXh8HBYvfESkmxzag6L/0EQYHnLJO qViXQ1OHf5A+6/xostZ5AC7mtsTNaoIDwuG77dD4vS4Yuj0V4Yo9v/RPrhMk/VyM2IvIkGpoly lpAJhE290AuhxcuRwcXn9SbfYKcIn8aH1c4FzHO9i2KBeOaWjM9/3D0fx7T8S64fhc8nUNaCNT Nzs= X-SBRS: 2.7 X-MesageID: 20453573 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,496,1583211600"; d="scan'208";a="20453573" Subject: Re: [PATCH for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Jan Beulich References: <20200608200259.17681-1-andrew.cooper3@citrix.com> <620e5f66-2802-24e7-bb6e-285e99f12975@suse.com> From: Andrew Cooper Message-ID: <6e353c85-b957-bdbe-6428-737b5bc8e801@citrix.com> Date: Wed, 10 Jun 2020 15:39:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <620e5f66-2802-24e7-bb6e-285e99f12975@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Konrad Rzeszutek Wilk , Ross Lagerwall , Paul Durrant , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 09/06/2020 14:41, Jan Beulich wrote: > On 08.06.2020 22:02, Andrew Cooper wrote: >> Do we ever write into .rodata? AFAICT, we introduce new fuctions for >> references to new .rodata, rather than modifying existing .rodata. If however >> we do modify .rodata, then the virtual regions need extending with information >> about .rodata so we can zap those dirty bits as well. > Inspired by looking at setup_virtual_regions(), do exception fixup > or bug frame tables possibly get patched? If they're not in .rodata, they really ought to be. That said, neither of those tables should get touched - we add new subset tables in the livepatch, which covers anything arising from modified code.  This means we don't merge/resort the table on load, or edit the table at all on unload. > >> @@ -58,6 +59,10 @@ int arch_livepatch_safety_check(void) >> >> int arch_livepatch_quiesce(void) >> { >> + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ >> + if ( cpu_has_xen_shstk ) >> + write_cr4(read_cr4() & ~X86_CR4_CET); >> + >> /* Disable WP to allow changes to read-only pages. */ >> write_cr0(read_cr0() & ~X86_CR0_WP); >> >> @@ -68,6 +73,29 @@ void arch_livepatch_revive(void) >> { >> /* Reinstate WP. */ >> write_cr0(read_cr0() | X86_CR0_WP); >> + >> + /* Clobber dirty bits and reinstate CET, if applicable. */ >> + if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) >> + { >> + unsigned long tmp; >> + >> + reset_virtual_region_perms(); >> + >> + write_cr4(read_cr4() | X86_CR4_CET); >> + >> + /* >> + * Fix up the return address on the shadow stack, which currently >> + * points at arch_livepatch_quiesce()'s caller. >> + * >> + * Note: this is somewhat fragile, and depends on both >> + * arch_livepatch_{quiesce,revive}() being called from the same >> + * function, which is currently the case. >> + */ >> + asm volatile ("rdsspq %[ssp];" >> + "wrssq %[addr], (%[ssp]);" >> + : [ssp] "=&r" (tmp) >> + : [addr] "r" (__builtin_return_address(0))); >> + } > To be safe against LTO I think this wants accompanying with making > both functions noinline. Hmm true. > As to the fragility - how about arch_livepatch_quiesce() returning > __builtin_return_address(0) to its caller, for passing into here > for verification? This would also make more noticeable that the > two should be be called from the same function (or else the "token" > would need passing further around). This I'm less certain about, as its fairly invasive to common code, just to bodge around something I don't expect to last very long into the 4.15 timeframe. > >> @@ -91,6 +92,18 @@ void unregister_virtual_region(struct virtual_region *r) >> remove_virtual_region(r); >> } >> >> +void reset_virtual_region_perms(void) >> +{ >> + const struct virtual_region *region; >> + >> + rcu_read_lock(&rcu_virtual_region_lock); >> + list_for_each_entry_rcu( region, &virtual_region_list, list ) >> + modify_xen_mappings((unsigned long)region->start, >> + ROUNDUP((unsigned long)region->end, PAGE_SIZE), >> + PAGE_HYPERVISOR_RX); >> + rcu_read_unlock(&rcu_virtual_region_lock); >> +} > Doesn't this result in shattering the trailing (and currently still > only) 2Mb page mapping .text in the xen.efi case? Not any more or less than its already clobbered by this logic in the alternatives path, I think? > With the > expectation of the approach changing in 4.15 this may not need > addressing, but should imo be mentioned as a shortcoming in the > description then. > > Also - how about "restore" instead of "reset"? Why?  We're not passing some state sideways into the new mappings - we're resetting them to their expected values. > > Finally, while indeed not a lot of code, should it nevertheless go > inside #ifdef CONFIG_LIVEPATCH? Tbh, it could be CONFIG_XEN_SHSTK if we decide to go down that route. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 10 14:49:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 14:49:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj22c-0007tT-30; Wed, 10 Jun 2020 14:49:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj22a-0007tO-W4 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 14:49:21 +0000 X-Inumbo-ID: 90ae434e-ab29-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 90ae434e-ab29-11ea-b7bb-bc764e2007e4; Wed, 10 Jun 2020 14:49:20 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id q25so2110277wmj.0 for ; Wed, 10 Jun 2020 07:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=aqKoAe5R3mErpPsGTBAYqJ8FZo4mhjQdiT2UrROsrh0=; b=syfU4IM9oGZ5ygoWgQxEuETrY5yi9RmR2pxf9ls9u3BYF/whrXpPw+aOGscUAuL9mg rOrmb9WfwSYEZaV0/6WeSM64IweBC+h5wmJTqd2mgpsC+Dg1YLjnfCsZ2ji3hFPZ6lfn L5dyDmN++y1+43Rhi+32lhuuKb34C6FNwpNGW+e3ZLk+9GRDbuYzozFGeKceFnQrZjHu +a9vrw6L2Ip/KiPoKi3NarqqitpXC5AEFM/AltXnT9riUW24M6jyzpod2OHNM2r2Da4K dqlaGdRY33jIBqyqGS9OJGLrGi3kjk1EMsL/is+QI2A222lYR2eqsJwj+juP2Yu2jy7h f2DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=aqKoAe5R3mErpPsGTBAYqJ8FZo4mhjQdiT2UrROsrh0=; b=hDIEYWBbGnKdpRZXOFHac7r6HyxDKNScGEhzGx6En0/bIgkbo0btWz8B8vVnkMVqxy 8hsxD2HcncqtKebmrONZnf7PtkabkR4ulI6lrH4psyuHNFgriTShg++HY3ReOT2r1LV6 X+I/a7Gpk5K65vzru22hTaR7f+d7FgRoZsQ49FtHTXOnEI8t7/PotL1OidYE+S7lNw44 y7ObhyKg5V2cGs539TWpind8hfnt5jYe1uYNmhCtOzIEOHVKF11HM1jCJmEtsHcfJuox hRf8kveFWgHWTEhT5snBbTjVg/+g0iVh7DcdKubLcmEz5TURr1/+DVZWYWRksz3ZTme2 xcAQ== X-Gm-Message-State: AOAM530511jgwqXQ86axYeyHQtb9qKa06b34ofpWY/nWWKXLEJNDB2Pf DoSIcXHj7R1c29o8c9DTFgI= X-Google-Smtp-Source: ABdhPJwJiyLiGYOvu36CWHNE4eGRaZVP4SM1gWlHKmEfL1AN0qiiDj4VxZf0AxEAGIQPIeugikA/dg== X-Received: by 2002:a7b:cbce:: with SMTP id n14mr3734907wmi.66.1591800559284; Wed, 10 Jun 2020 07:49:19 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id d16sm7087862wmd.42.2020.06.10.07.49.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2020 07:49:18 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-2-roger.pau@citrix.com> In-Reply-To: <20200610142923.9074-2-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14 v2 1/2] x86/passthrough: do not assert edge triggered GSIs for PVH dom0 Date: Wed, 10 Jun 2020 15:49:17 +0100 Message-ID: <00e401d63f36$51cd4800$f567d800$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHx2+DDRjLQssRal4XfU2f+2Pe7FQGgF1ZFqI2zmqA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 10 June 2020 15:29 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich = ; Andrew > Cooper ; Wei Liu > Subject: [PATCH for-4.14 v2 1/2] x86/passthrough: do not assert edge = triggered GSIs for PVH dom0 >=20 > Edge triggered interrupts do not assert the line, so the handling done > in Xen should also avoid asserting it. Asserting the line prevents > further edge triggered interrupts on the same vIO-APIC pin from being > delivered, since the line is not de-asserted. >=20 > One case of such kind of interrupt is the RTC timer, which is edge > triggered and available to a PVH dom0. Note this should not affect > domUs, as it only modifies the behavior of IDENTITY_GSI kind of passed > through interrupts. >=20 > Signed-off-by: Roger Pau Monn=C3=A9 > Acked-by: Andrew Cooper Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant > --- > Changes since v1: > - Compare the triggering against VIOAPIC_{EDGE/LEVEL}_TRIG. > --- > xen/arch/x86/hvm/irq.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) >=20 > diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c > index 9c8adbc495..fd02cf2e8d 100644 > --- a/xen/arch/x86/hvm/irq.c > +++ b/xen/arch/x86/hvm/irq.c > @@ -169,9 +169,10 @@ void hvm_pci_intx_deassert( >=20 > void hvm_gsi_assert(struct domain *d, unsigned int gsi) > { > + int trig =3D vioapic_get_trigger_mode(d, gsi); > struct hvm_irq *hvm_irq =3D hvm_domain_irq(d); >=20 > - if ( gsi >=3D hvm_irq->nr_gsis ) > + if ( gsi >=3D hvm_irq->nr_gsis || trig < 0 ) > { > ASSERT_UNREACHABLE(); > return; > @@ -186,9 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned = int gsi) > * to know if the GSI is pending or not. > */ > spin_lock(&d->arch.hvm.irq_lock); > - if ( !hvm_irq->gsi_assert_count[gsi] ) > + if ( trig =3D=3D VIOAPIC_EDGE_TRIG || = !hvm_irq->gsi_assert_count[gsi] ) > { > - hvm_irq->gsi_assert_count[gsi] =3D 1; > + if ( trig =3D=3D VIOAPIC_LEVEL_TRIG ) > + hvm_irq->gsi_assert_count[gsi] =3D 1; > assert_gsi(d, gsi); > } > spin_unlock(&d->arch.hvm.irq_lock); > @@ -196,11 +198,12 @@ void hvm_gsi_assert(struct domain *d, unsigned = int gsi) >=20 > void hvm_gsi_deassert(struct domain *d, unsigned int gsi) > { > + int trig =3D vioapic_get_trigger_mode(d, gsi); > struct hvm_irq *hvm_irq =3D hvm_domain_irq(d); >=20 > - if ( gsi >=3D hvm_irq->nr_gsis ) > + if ( trig <=3D VIOAPIC_EDGE_TRIG || gsi >=3D hvm_irq->nr_gsis ) > { > - ASSERT_UNREACHABLE(); > + ASSERT(trig =3D=3D VIOAPIC_EDGE_TRIG && gsi < = hvm_irq->nr_gsis); > return; > } >=20 > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 15:07:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 15:07:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj2KC-0001D8-MS; Wed, 10 Jun 2020 15:07:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj2KB-0001Cp-IV for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 15:07:31 +0000 X-Inumbo-ID: 17b3199e-ab2c-11ea-8496-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 17b3199e-ab2c-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 15:07:25 +0000 (UTC) Received: from nodbug.lucina.net (78-141-76-187.dynamic.orange.sk [78.141.76.187]) by smtp.lucina.net (Postfix) with ESMTPSA id CF65B122804; Wed, 10 Jun 2020 17:07:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1591801644; bh=brXaipuMVaItSAA9lBzHtWeUBGANdyih+K9IC1ATdDs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aDBHv/lnU3FUIX/xeH+d8DqZSMpA8Tuo1pH7FxD7yNBYPDqAL1GtTYHSk/sccOQoO ddW0tqXnir1v93kE5+8Fcazxckas96m1g6uZ/FCXkqPJDUwWMHBMCHZQEuexFBIaZe 95eST6L+95KBJcgbLzJoJq6+OfbpGR2EnGdFQS+tb+bjd5AYQcVmQKrz0M8wzhQW3n 8c3/DWrV6Rn2S/h7Q+ORDlgXF1ja/zbnC0GI7VPC5b7eWibVw2yw++9bJ6JlVXcoWT WSg4xmCc2Lb77M0KGmW4/m1zXiNk55vT6K09AuSVwi3WNrCZu7wsDYexP/ToKNoOIV UuWjXeiSX2zjQ== Received: by nodbug.lucina.net (Postfix, from userid 1000) id B6720265E722; Wed, 10 Jun 2020 17:07:24 +0200 (CEST) Date: Wed, 10 Jun 2020 17:07:24 +0200 From: Martin Lucina To: Andrew Cooper Subject: Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table Message-ID: <20200610150724.GC16839@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , Andrew Cooper , xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org References: <20200609094425.GB9734@nodbug.lucina.net> <3c7269b9-bf3f-5359-6ce2-049f935c8e84@citrix.com> <20200610132225.GA16839@nodbug.lucina.net> <46e87834-bf47-4003-1f32-89a47255155d@citrix.com> <20200610135601.GB16839@nodbug.lucina.net> <6b2a0091-2c56-895c-762d-719e5796985d@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6b2a0091-2c56-895c-762d-719e5796985d@citrix.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wednesday, 10.06.2020 at15:21, Andrew Cooper wrote: > > I don't need v2 at all, I was just going by the comments in grant_table.h, > > which read: "Version 1 of the grant table entry structure is maintained > > purely for backwards compatibility. New guests should use version 2." > > Ha... > > That comment wasn't written with the benefit of hindsight. > > IMO, grant v2 is not worth the astounding quantity of XSAs its > implementation actually gave us, or the complexity of the resulting code. > > > Grant status frames are a v2-only thing, right? > > Correct. > > The split status frames was new in v2, in an attempt to reduce cacheline > ping-pong. > > The downside is that the guest needs an unbounded loop trying to make a > change to the grant table while ensuring that the flags in the status > frame don't change asynchronously. > > ~Andrew > > P.S. In some theoretical world, I was hoping to have something to live > in https://xenbits.xen.org/docs/latest/guest-guide/index.html on this > subject. Do you mind if I use you as a retroactive guineapig if/when > some documentation were to appear? No problem, sure, go for it. -mato From xen-devel-bounces@lists.xenproject.org Wed Jun 10 16:36:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 16:36:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj3hr-0000p4-5R; Wed, 10 Jun 2020 16:36:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj3hp-0000oz-Rs for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 16:36:02 +0000 X-Inumbo-ID: 77ca8cca-ab38-11ea-bca7-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 77ca8cca-ab38-11ea-bca7-bc764e2007e4; Wed, 10 Jun 2020 16:36:00 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id gl26so3274526ejb.11 for ; Wed, 10 Jun 2020 09:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Q8zLjXo5Gf3PWy97Koz6jOMttnRr4rpiOEISH2O21iY=; b=N8P+t8mnku4PIgSW/grhFHrDedILVk4V6E/21KSjo2R8GM+as0NXP2KNhgtC0zSgGi 2NgKpgfYGTnmMHZYu/S+IlhKZpRulhFf5hF8Fd+5QikvdksXDSu/EVPjtaGxNY7CMbHJ xASKI4JyId+/xFjMluyV8er8k9CbX3obyXXxQkI9d7tFbGoZcD9L6lryfiLLaKeaGadf nyou5HkcPI3qT4+pn4tqPbSjrx6K+ztaJTFV2dimpA61wrWT7rrcd39GFCMpSTaHmW9B XsAB8GcSl9ieeeucpgklo4eB9SU9EONycxB6XVRTO1hzluObFDJRUCRNcqADCze+mov2 5wGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Q8zLjXo5Gf3PWy97Koz6jOMttnRr4rpiOEISH2O21iY=; b=oJ/8NVGuxbWI/VnwdXBo6Db14LtXENQMcVvnPi5jZbZnl8/5urxfDYHiXbG3V63k2y rzv2hyzltbDrvlbPxZn1F4MoFYAFL7W22a/HC+SlDnfHt/HFLuS/NTUZc+ElYhB6qRdQ IuWm4c++4WdwK+hyB0xp0cZwlhDbXOQjKyOcbtt+NDGQliWlnFWNKWN2UYt6kbYGCrC6 2sVxAZ0bENxra7+EFqenjdH+MsoEGT7kl0ucxGR7NECfnLjNjgWYAb89NImJmkBuDcoU huECBjS06H1g5k2dxA78dlOvx5J7rNE9yTwS/KEcvayO4sXTOAXbdGlXumDMc7kjFIae xAPw== X-Gm-Message-State: AOAM5308CUhdLsX8r56KYjLqprIDn+hp1Bfx9eO2afabLaO7zZj1XQ3T dIvw1zm1u1BWaNaLRKjgqh2gxSj5CjA= X-Google-Smtp-Source: ABdhPJwakgrhpQFNUFc0WPbG2cfg7fsz91PfCHC9SbUuUtz7kasiUuCe+ycc5qLZepfW+GM/gfIRzw== X-Received: by 2002:a17:907:4030:: with SMTP id nr24mr4074179ejb.247.1591806959200; Wed, 10 Jun 2020 09:35:59 -0700 (PDT) Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com. [209.85.128.53]) by smtp.gmail.com with ESMTPSA id oq28sm211777ejb.12.2020.06.10.09.35.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Jun 2020 09:35:57 -0700 (PDT) Received: by mail-wm1-f53.google.com with SMTP id r15so2418921wmh.5 for ; Wed, 10 Jun 2020 09:35:57 -0700 (PDT) X-Received: by 2002:a05:600c:2294:: with SMTP id 20mr4197977wmf.51.1591806956973; Wed, 10 Jun 2020 09:35:56 -0700 (PDT) MIME-Version: 1.0 References: <20200603125237.100041-1-tamas@tklengyel.com> <64ea771f-a7c1-cfc1-e135-632ec4c7fc93@suse.com> <006f01d63e43$25e98440$71bc8cc0$@xen.org> In-Reply-To: <006f01d63e43$25e98440$71bc8cc0$@xen.org> From: Tamas K Lengyel Date: Wed, 10 Jun 2020 10:35:16 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior when monitoring register write events To: Paul Durrant Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Petre Pircalabu , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Alexandru Isaila , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 9, 2020 at 3:48 AM Paul Durrant wrote: > > > -----Original Message----- > > From: Jan Beulich > > Sent: 09 June 2020 10:37 > > To: Tamas K Lengyel > > Cc: xen-devel@lists.xenproject.org; Andrew Cooper ; Wei Liu ; > > Roger Pau Monn=C3=A9 ; George Dunlap ; Ian Jackson > > ; Julien Grall ; Stefano Sta= bellini > > ; Alexandru Isaila ; P= etre Pircalabu > > ; Paul Durrant > > Subject: Re: [PATCH v4 for-4.14] x86/monitor: revert default behavior w= hen monitoring register write > > events > > > > On 03.06.2020 14:52, Tamas K Lengyel wrote: > > > For the last couple years we have received numerous reports from user= s of > > > monitor vm_events of spurious guest crashes when using events. In par= ticular, > > > it has observed that the problem occurs when vm_events are being disa= bled. The > > > nature of the guest crash varied widely and has only occured occasion= ally. This > > > made debugging the issue particularly hard. We had discussions about = this issue > > > even here on the xen-devel mailinglist with no luck figuring it out. > > > > > > The bug has now been identified as a race-condition between register = event > > > handling and disabling the monitor vm_event interface. The default be= havior > > > regarding emulation of register write events is changed so that they = get > > > postponed until the corresponding vm_event handler decides whether to= allow such > > > write to take place. Unfortunately this can only be implemented by pe= rforming the > > > deny/allow step when the vCPU gets scheduled. > > > > > > Due to that postponed emulation of the event if the user decides to p= ause the > > > VM in the vm_event handler and then disable events, the entire emulat= ion step > > > is skipped the next time the vCPU is resumed. Even if the user doesn'= t pause > > > during the vm_event handling but exits immediately and disables vm_ev= ent, the > > > situation becomes racey as disabling vm_event may succeed before the = guest's > > > vCPUs get scheduled with the pending emulation task. This has been pa= rticularly > > > the case with VMS that have several vCPUs as after the VM is unpaused= it may > > > actually take a long time before all vCPUs get scheduled. > > > > > > In this patch we are reverting the default behavior to always perform= emulation > > > of register write events when the event occurs. To postpone them can = be turned > > > on as an option. In that case the user of the interface still has to = take care > > > of only disabling the interface when its safe as it remains buggy. > > > > > > Fixes: 96760e2fba10 ('vm_event: deny register writes if refused by vm= _event > > > reply'). > > > > > > Signed-off-by: Tamas K Lengyel > > > > Applicable parts > > Acked-by: Jan Beulich > > > > Release-acked-by: Paul Durrant Thanks guys! Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 10 17:55:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 17:55:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj4wd-00089g-45; Wed, 10 Jun 2020 17:55:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj4wb-00089b-QN for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 17:55:21 +0000 X-Inumbo-ID: 8cab3e37-ab43-11ea-b489-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8cab3e37-ab43-11ea-b489-12813bfff9fa; Wed, 10 Jun 2020 17:55:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=UIlZ2rCWAh8yT4IfFSBZfAoUNNIXV8ICfJlH0tseq+I=; b=Yk0n0AJhh2jjqQGcSWwZqOvMZk cCctRMKChqnov/0W8dAPAvmmAu7EskQnKFklHhd5aVU3yxp6v19HIR5sm4+RTz6/HPg61r3RRnJ3Y ajIFzODDZT0hfgnlPNZ8cUo0gKiTx2/Qazs0eyKOOnU9Up3wyiE4RKFHedQ1JMQOfvZY=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj4wY-0004ri-BV; Wed, 10 Jun 2020 17:55:18 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jj4wY-00005u-4I; Wed, 10 Jun 2020 17:55:18 +0000 Subject: Re: [PATCH for-4.14] xen/hypfs: fix loglvl parameter setting To: Juergen Gross , xen-devel@lists.xenproject.org References: <20200609154546.4531-1-jgross@suse.com> From: Julien Grall Message-ID: <4a3c4e5e-1fbd-5017-1e3e-64052ae2410a@xen.org> Date: Wed, 10 Jun 2020 18:55:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200609154546.4531-1-jgross@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Juergen, On 09/06/2020 16:45, Juergen Gross wrote: > Writing the runtime parameters loglvl or guest_loglvl omits setting the > new length of the resulting parameter value. > > Reported-by: George Dunlap > Signed-off-by: Juergen Gross Reviewed-by: Julien Grall Although one unrelated comment below. > --- > xen/drivers/char/console.c | 19 +++++++++++++++---- > 1 file changed, 15 insertions(+), 4 deletions(-) > > diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c > index 56e24821b2..861ad53a8f 100644 > --- a/xen/drivers/char/console.c > +++ b/xen/drivers/char/console.c > @@ -241,14 +241,25 @@ static int _parse_loglvl(const char *s, int *lower, int *upper, char *val) > > static int parse_loglvl(const char *s) > { > - return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh, > - xenlog_val); > + int ret; > + > + ret = _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh, > + xenlog_val); > + custom_runtime_set_var(param_2_parfs(parse_loglvl), xenlog_val); Mixing function and variable name is pretty confusing. It took me sometimes to go through the macro maze to figure out what's happening. It might be worth thinking to document more the custom_runtime_* interface. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 10 18:22:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 18:22:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj5Md-0002Mu-BK; Wed, 10 Jun 2020 18:22:15 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj5Mb-0002LY-LD for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 18:22:13 +0000 X-Inumbo-ID: 4a8c0608-ab47-11ea-b48f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4a8c0608-ab47-11ea-b48f-12813bfff9fa; Wed, 10 Jun 2020 18:22:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cHyPynlrBHVNHpGUq5QR13xbwLkaF7rCChfTLzPW73w=; b=LPNvAv1ecfJu0s1OJdqpOMXKN ZUXcGnSnBIvGdIYa7MOckmcAn8fvzHs6vBNlGTjMVmNjupcgRyITyhOG73KO7C2GyHEJzf+Avph2q GOChZgKA+f5XziVkBOGbh8wlBUDvdFbts4YVcpRhqLKVUf+2ONv296rP0JynYspEhGIK0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj5MU-0005SP-Mu; Wed, 10 Jun 2020 18:22:06 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jj5MU-0000y4-7p; Wed, 10 Jun 2020 18:22:06 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jj5MU-000798-7A; Wed, 10 Jun 2020 18:22:06 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 150963: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=058023b343d4e366864831db46e9b438e9e3a178 X-Osstest-Versions-That: xen=835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 From: osstest service owner Date: Wed, 10 Jun 2020 18:22:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150963 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/150963/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail blocked in 150933 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150933 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150933 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150933 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150933 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150933 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150933 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150933 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150933 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150933 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150933 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 058023b343d4e366864831db46e9b438e9e3a178 baseline version: xen 835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 Last test of basis 150933 2020-06-09 06:48:33 Z 1 days Testing same since 150963 2020-06-09 20:06:30 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Ian Jackson Jan Beulich Juergen Gross Paul Durrant Tamas K Lengyel Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 835d8d69d9..058023b343 058023b343d4e366864831db46e9b438e9e3a178 -> master From xen-devel-bounces@lists.xenproject.org Wed Jun 10 18:38:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 18:38:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj5br-0003Sb-UW; Wed, 10 Jun 2020 18:37:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj5br-0003SW-FM for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 18:37:59 +0000 X-Inumbo-ID: 81c05a8c-ab49-11ea-8496-bc764e2007e4 Received: from mail-qk1-x730.google.com (unknown [2607:f8b0:4864:20::730]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 81c05a8c-ab49-11ea-8496-bc764e2007e4; Wed, 10 Jun 2020 18:37:58 +0000 (UTC) Received: by mail-qk1-x730.google.com with SMTP id v79so3050674qkb.10 for ; Wed, 10 Jun 2020 11:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=bYonscorY+I+rpVIRHqicEvlg4i+HTCU1d5REzvyhPg=; b=Ox4YW6AdLDWuknd+YobLJlyTOUciPKzYNi2fhf5MimP8oXOSnSWhzGaRlXoCQdIp9Y yD8ZY6rSurSVu4OVmlRHgnDDMI08G2VpRVQpwutL2ANV/6b7ALqxgJLgYijUnqPsESyq 9M0P1AscDHkzPTaToAcQw35PDQBEjRHCcReCO+so35bS3Jctw6OWntshW7cqhSxOd/Lk Lj0xuw6retEhNWeshilljrJMHViqiKl/vZDzlHd7DeA/PTHm/0MdDKIoe7AsmJVN63IY EQg1WbnWieb5r3U2CWIpOu8jm4V2jv4cbpB1A493QcM7brJRzqkcIbVCZBhH63OUDCdG 8vEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:user-agent; bh=bYonscorY+I+rpVIRHqicEvlg4i+HTCU1d5REzvyhPg=; b=iYUQ72wdpOWr5EW+NfS8iA2Lv2b/jaABpgalDr94acjStoBH2D4fdLhBmR9wlwu490 lKY8OGBYWRAL+wYU9G0sj0sy1CrkCbkibRBWg78dt5IX/nt79By+UPCDpoUhZZwe6d4e IMGg17a/Gf/mWRh+jXpHu2IqcOEydlgsDTX4g4OUNOzD6dPmZ1iZzcP/4RWVzKGtW9vf LWcGoFAMBiCr9A3Y5xnaXHRPGiiHGhraP2I/3hEhnT02RxxJNVmRQRcsgP6lNJJ26oxb f0NWt823HddyVVChPMnhZCXiDnzOuwKoZB3xgiXrZ7TPWvnDEo/m9VzZjFjfXlJtcbze nraw== X-Gm-Message-State: AOAM532MHX8+vFvtzsR9KtRFnz7CeUMf/yErPGm15vDvURR2iEOHf93z OOlWimIWEMx9aJD+RlGV3NlT4ojKc7g= X-Google-Smtp-Source: ABdhPJyW9aO4zn1aadDv9ercXUAwi3JS9up8D7nnwPhLV9iAHAuY7QTscC3tCAOCYDfncqiA+JRyCQ== X-Received: by 2002:a37:65cf:: with SMTP id z198mr4269751qkb.133.1591814277868; Wed, 10 Jun 2020 11:37:57 -0700 (PDT) Received: from six (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252]) by smtp.gmail.com with ESMTPSA id t43sm586208qtj.85.2020.06.10.11.37.56 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Jun 2020 11:37:57 -0700 (PDT) Date: Wed, 10 Jun 2020 14:37:54 -0400 From: Nick Rosbrook To: xen-devel@lists.xenproject.org Subject: Unexpected diff after autogen.sh Message-ID: <20200610183754.GA3113@six> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: ian.jackson@citrix.com, wl@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, When writing a patch to tools/configure.ac, re-running autogen.sh resulted in a diff with unexpected changes. Specifically, these additions: diff --git a/configure b/configure index 8af54e8a5a..9da3970cef 100755 --- a/configure +++ b/configure @@ -644,6 +644,7 @@ infodir docdir oldincludedir includedir +runstatedir localstatedir sharedstatedir sysconfdir @@ -722,6 +723,7 @@ datadir='${datarootdir}' sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' +runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -974,6 +976,15 @@ do | -silent | --silent | --silen | --sile | --sil) silent=yes ;; + -runstatedir | --runstatedir | --runstatedi | --runstated \ + | --runstate | --runstat | --runsta | --runst | --runs \ + | --run | --ru | --r) + ac_prev=runstatedir ;; + -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ + | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ + | --run=* | --ru=* | --r=*) + runstatedir=$ac_optarg ;; + -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ [...] ...and similar for {docs,tools,stubdom}/configure. These lines were originally removed in 83c845033d. It seems that the 'runstatedir' changes in the configure scripts were unintentional and should be added back. Thanks, -NR From xen-devel-bounces@lists.xenproject.org Wed Jun 10 18:49:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 18:49:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj5ma-0004Ot-07; Wed, 10 Jun 2020 18:49:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj5mY-0004Oo-G6 for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 18:49:02 +0000 X-Inumbo-ID: 0c779c02-ab4b-11ea-b494-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0c779c02-ab4b-11ea-b494-12813bfff9fa; Wed, 10 Jun 2020 18:49:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id ACF2DAC24; Wed, 10 Jun 2020 18:49:03 +0000 (UTC) Subject: Re: [PATCH for-4.14] xen/hypfs: fix loglvl parameter setting To: Julien Grall , xen-devel@lists.xenproject.org References: <20200609154546.4531-1-jgross@suse.com> <4a3c4e5e-1fbd-5017-1e3e-64052ae2410a@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Wed, 10 Jun 2020 20:48:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <4a3c4e5e-1fbd-5017-1e3e-64052ae2410a@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10.06.20 19:55, Julien Grall wrote: > Hi Juergen, > > On 09/06/2020 16:45, Juergen Gross wrote: >> Writing the runtime parameters loglvl or guest_loglvl omits setting the >> new length of the resulting parameter value. >> >> Reported-by: George Dunlap >> Signed-off-by: Juergen Gross > > Reviewed-by: Julien Grall > > Although one unrelated comment below. > >> --- >>   xen/drivers/char/console.c | 19 +++++++++++++++---- >>   1 file changed, 15 insertions(+), 4 deletions(-) >> >> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c >> index 56e24821b2..861ad53a8f 100644 >> --- a/xen/drivers/char/console.c >> +++ b/xen/drivers/char/console.c >> @@ -241,14 +241,25 @@ static int _parse_loglvl(const char *s, int >> *lower, int *upper, char *val) >>   static int parse_loglvl(const char *s) >>   { >> -    return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh, >> -                         xenlog_val); >> +    int ret; >> + >> +    ret = _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh, >> +                        xenlog_val); >> +    custom_runtime_set_var(param_2_parfs(parse_loglvl), xenlog_val); > > Mixing function and variable name is pretty confusing. It took me > sometimes to go through the macro maze to figure out what's happening. > > It might be worth thinking to document more the custom_runtime_* interface. I have already some streamlining ideas for 4.15. Juergen From xen-devel-bounces@lists.xenproject.org Wed Jun 10 18:54:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 18:54:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj5rh-0005CQ-KH; Wed, 10 Jun 2020 18:54:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj5rg-0005CL-Lj for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 18:54:20 +0000 X-Inumbo-ID: c94f6594-ab4b-11ea-bca7-bc764e2007e4 Received: from mail-oi1-x233.google.com (unknown [2607:f8b0:4864:20::233]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c94f6594-ab4b-11ea-bca7-bc764e2007e4; Wed, 10 Jun 2020 18:54:17 +0000 (UTC) Received: by mail-oi1-x233.google.com with SMTP id j189so3027689oih.10 for ; Wed, 10 Jun 2020 11:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:reply-to:mime-version :content-disposition:user-agent; bh=qc/OfoZtFHoHNSDxvAltCZBY+UjDohB6V1B587JdG9E=; b=dNY/KSzWhUA+L5A0lpkFrWfQgn5TgKCWn897IvR/DN2+KgWJakgZTDcsJdbsu0x5gR /HFO/QqbZtzhtk+gv3Ev4QOiB4/E0NUP/Utz2JbD2ODYby5P+edvEu8FmVjrSe/Ruk1S 6EOfHxL2sp3lVoYmMsEJRDb0JWthOvlpWpyDzu2JGwmB+/n9K3pEWNQW8hkwT9wblO9g PxG4p9sCYqQzYOp2u0IegfL/x8TE046mS+44dbn5GURf7h0+FCOS4+AL9RaSbClf1j2m ACmJ8TBScXLEueF7sfhGT3cBW3Yj1Eazq0dBXWK+EtyNXMhTyOneSDYWoAl+QxO0MlSo 21aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :mime-version:content-disposition:user-agent; bh=qc/OfoZtFHoHNSDxvAltCZBY+UjDohB6V1B587JdG9E=; b=hX0HyccUigjyk8wqWXk2YYfP7XpyltBdcZ9OnbUl0JzqP9C8MtVYM2l9C+htAYSM82 waLqGQDTbynVU7NdjlD8f+GNhEBuWLfVah1CGyK4YrCpZuHS0j+5wjhpsCeU79wIKjz4 SeCZ4lUXzmEziauDhaFyF391gNjjRv7rANT/4PpI1KZnF49YcrsAgkz9ZUXcuNI1cHwZ V2gH9LsBbsgj8b9CQdkKzWqS9kW0Hf/oX9t21a9s2KyqjlLbAbTtKEwAop1BjHd70XCh PjGWKrH0tEBBhGNF+ZX4tdcdwMNcdkuFo/yfyh4I8SZuBlcEO+uzu1fuyTopy0r8Wphf M0QQ== X-Gm-Message-State: AOAM530mcrYYJXQpKqctikRKE1l8Txq9PaTPsTzZ9BtEnr4FbM7PQwd9 lCmC41hY/NsoVUobxCySGkVjXWrH0tE= X-Google-Smtp-Source: ABdhPJwm+YuITJ95oR873g1fKYSwIDC8Ew2zEHXEAreCkghF6CrJPc7rj1fL+Y1Hm4mY39/hhSMymA== X-Received: by 2002:aca:5395:: with SMTP id h143mr3710599oib.126.1591815257173; Wed, 10 Jun 2020 11:54:17 -0700 (PDT) Received: from minyard.net ([2001:470:b8f6:1b:814:e40e:3b2b:9d19]) by smtp.gmail.com with ESMTPSA id s69sm177967otb.4.2020.06.10.11.54.16 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Jun 2020 11:54:16 -0700 (PDT) Date: Wed, 10 Jun 2020 13:54:15 -0500 From: Corey Minyard To: xen-devel@lists.xenproject.org, Julien Grall , Stefano Stabellini , roman@zededa.com, tamas@tklengyel.com Subject: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel Message-ID: <20200610185415.GG7231@minyard.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: cminyard@mvista.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" I had been working on Xen on the Pi4 by throwing kernels I compiled onto existing sd cards, and this was working fine. I finally got to a full yocto build of the system, and it didn't boot. In fact, Xen didn't print anything at all, and nothing happens that might suggest it's booting without any console output. I traced the issue down to the vc4-fkms-v3d dtoverly. With everything else the same, the 4.19 version of that overlay works, and the 5.4 version does not work. It also didn't work if I completely removed the overlay. The base device trees are the same between the two kernels. Looking at the overlay changes between the versions and Xen source, I can't trace down anything that would cause an issue. Has anyone seen this issue of have any ideas? -corey From xen-devel-bounces@lists.xenproject.org Wed Jun 10 19:17:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 19:17:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj6De-0006wx-FW; Wed, 10 Jun 2020 19:17:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj6Dc-0006ws-VL for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 19:17:00 +0000 X-Inumbo-ID: f50f06be-ab4e-11ea-bb8b-bc764e2007e4 Received: from deinos.phlegethon.org (unknown [2001:41d0:8:b1d7::1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f50f06be-ab4e-11ea-bb8b-bc764e2007e4; Wed, 10 Jun 2020 19:17:00 +0000 (UTC) Received: from tjd by deinos.phlegethon.org with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1jj6DZ-000I6A-Uq; Wed, 10 Jun 2020 19:16:57 +0000 Date: Wed, 10 Jun 2020 20:16:57 +0100 From: Tim Deegan To: Olaf Hering Subject: Re: [PATCH v1] kdd: remove zero-length arrays Message-ID: <20200610191657.GA69414@deinos.phlegethon.org> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> <20200609152233.039cfc86.olaf@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20200609152233.039cfc86.olaf@aepfle.de> User-Agent: Mutt/1.11.1 (2018-12-01) X-SA-Known-Good: Yes X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tim@xen.org X-SA-Exim-Scanned: No (on deinos.phlegethon.org); SAEximRunCond expanded to false X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' , 'Wei Liu' , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" At 15:22 +0200 on 09 Jun (1591716153), Olaf Hering wrote: > Am Tue, 9 Jun 2020 13:15:49 +0100 > schrieb Tim Deegan : > > > Olaf, can you try dropping the 'payload' field from the header and replacing the payload[0] in pkt with payload[] ? > > In file included from kdd.c:53: > kdd.h:325:17: error: flexible array member in union > 325 | uint8_t payload[]; How tedious. Well, the only place we actually allocate one of these we already leave enough space for a max-size packet, so how about this? kdd: stop using [0] arrays to access packet contents. GCC 10 is unhappy about this, and we already use 64k buffers in the only places where packets are allocated, so move the 64k size into the packet definition. Reported-by: Olaf Hering Signed-off-by: Tim Deegan --- tools/debugger/kdd/kdd.c | 4 ++-- tools/debugger/kdd/kdd.h | 3 +-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git tools/debugger/kdd/kdd.c tools/debugger/kdd/kdd.c index 3ebda9b12c..a7d0976ea4 100644 --- tools/debugger/kdd/kdd.c +++ tools/debugger/kdd/kdd.c @@ -79,11 +79,11 @@ typedef struct { /* State of the debugger stub */ typedef struct { union { - uint8_t txb[sizeof (kdd_hdr) + 65536]; /* Marshalling area for tx */ + uint8_t txb[sizeof (kdd_pkt)]; /* Marshalling area for tx */ kdd_pkt txp; /* Also readable as a packet structure */ }; union { - uint8_t rxb[sizeof (kdd_hdr) + 65536]; /* Marshalling area for rx */ + uint8_t rxb[sizeof (kdd_pkt)]; /* Marshalling area for rx */ kdd_pkt rxp; /* Also readable as a packet structure */ }; unsigned int cur; /* Offset into rx where we'll put the next byte */ diff --git tools/debugger/kdd/kdd.h tools/debugger/kdd/kdd.h index bfb00ba5c5..b9a17440df 100644 --- tools/debugger/kdd/kdd.h +++ tools/debugger/kdd/kdd.h @@ -68,7 +68,6 @@ typedef struct { uint16_t len; /* Payload length, excl. header and trailing byte */ uint32_t id; /* Echoed in responses */ uint32_t sum; /* Unsigned sum of all payload bytes */ - uint8_t payload[0]; } PACKED kdd_hdr; #define KDD_PKT_CMD 0x0002 /* Debugger commands (and replies to them) */ @@ -323,7 +322,7 @@ typedef struct { kdd_msg msg; kdd_reg reg; kdd_stc stc; - uint8_t payload[0]; + uint8_t payload[65536]; }; } PACKED kdd_pkt; -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 19:56:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 19:56:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj6pT-0001om-Kk; Wed, 10 Jun 2020 19:56:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj6pS-0001oh-8R for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 19:56:06 +0000 X-Inumbo-ID: 6a37180a-ab54-11ea-b4a8-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6a37180a-ab54-11ea-b4a8-12813bfff9fa; Wed, 10 Jun 2020 19:56:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0tjmPKkIinswwSiJsFzu0PLksl7ct3O9ts70t4oRmfc=; b=JUefQqT1LCFwt8C6DK4+QkFCp 7kOP0dglggL4la+JIrb4pYbgq3Y+dJiqWjNNzXh1rC7TMLw0f6e/DDotgFDZps0+HQZAgRLX/YMIY D0MbyxU4SVPfXtQQXVpt0Cyes2/aBxv6oe9Ad6oVXlTS0Hwm9U5rw9Vp/iw+wuh1owi1I=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj6pP-0007AP-8X; Wed, 10 Jun 2020 19:56:03 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jj6pO-0004W6-V7; Wed, 10 Jun 2020 19:56:03 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jj6pO-0002MX-UO; Wed, 10 Jun 2020 19:56:02 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 150978: all pass - PUSHED X-Osstest-Versions-This: ovmf=dafce295e6f447ed8905db4e29241e2c6c2a4389 X-Osstest-Versions-That: ovmf=6aa48ab791ecc4fe22d110222bd7b566bc8a2274 From: osstest service owner Date: Wed, 10 Jun 2020 19:56:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150978 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/150978/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf dafce295e6f447ed8905db4e29241e2c6c2a4389 baseline version: ovmf 6aa48ab791ecc4fe22d110222bd7b566bc8a2274 Last test of basis 150946 2020-06-09 18:43:44 Z 1 days Testing same since 150978 2020-06-09 21:39:29 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Laszlo Ersek jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 6aa48ab791..dafce295e6 dafce295e6f447ed8905db4e29241e2c6c2a4389 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Wed Jun 10 21:47:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 21:47:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj8Yb-0002NT-3D; Wed, 10 Jun 2020 21:46:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj8Ya-0002NO-1Z for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 21:46:48 +0000 X-Inumbo-ID: e20bf666-ab63-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x429.google.com (unknown [2a00:1450:4864:20::429]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e20bf666-ab63-11ea-b7bb-bc764e2007e4; Wed, 10 Jun 2020 21:46:47 +0000 (UTC) Received: by mail-wr1-x429.google.com with SMTP id x6so3957558wrm.13 for ; Wed, 10 Jun 2020 14:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4LvjtnXYz/vAAHcoM1v81G9wuMx8OKexAw8K4dEHhjI=; b=N89ITOlfSoqB52s+j1djJcFwDByZlBDCrELEP448Ymu2k1ZMDyJtRjZ/vnYdUUYBBA pARqKNUCrj9ZBFHoW1CtEW6cA60w0Ss8O19NgeGjVRarNuVBmEkLnKl62ApI0KUAGuPB 1xEwtZ4gJWUGvczOWSVgUZxt2EcsKMI1T4wu2+4hr00mMqMpblhnHcXWfruY+NBjnox3 DiChTjoOsbf1urdhqlI8oJA/I46s1Z57c3FkqybJTeAwlVDKZ5b+6NMIIMXeLz/6N8/v +2+2pfCWqtf4XcYZAednJFZvSjEzbJnc0yTg4d+kB66QxAS39sNJMobTFiCeLDWGbYHs LY0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4LvjtnXYz/vAAHcoM1v81G9wuMx8OKexAw8K4dEHhjI=; b=JxyH63McU3xxIFM3wrJJ/SkfMxqrF8pwLAXwnn6GBKktBVpZRBZZDSBdBBVqT1CJh9 5qHHmnpm0nZ7FSVKKcBwYYk1GRrEsIcvkvckLB6rLJ2kCP1haaxBMoejCBHbQ9blSf8x gBq2XqMpanLlkP6mcL6yXbCdBheX4tRjYqepjT6DPFNPohKvTvyYwFmP/+zAlzBKhI5E de0Bp980FOg0WnTekAwpL6vQJO9fHyrgRYpmHImfTl8+HQmWzUPssQR4sV64ZFkM0Y6i aFf61I01kPaIYAkU9S6S+QNZQ9xo0sdbsz9qlz9UYogU0+xEXuJjkm/+7pqZ+EqjPx4V Flgw== X-Gm-Message-State: AOAM5330GF3HHB1QOe6X33Z425+Qr9G8PJYjpdPZdq/enFD2yH5MGVKO qgvg1BdUrXdCoGdO+p7RtFO7FmjZN9u5JDQAqvk= X-Google-Smtp-Source: ABdhPJwRBuI2fBGS49fA55Sc1KYBPPCO+mTLNqCjm6VdOL4S+K5cLgU6W63pthyHuqb3zLDS7/fP1Cc+yPCfn4b/Vxg= X-Received: by 2002:adf:f64e:: with SMTP id x14mr6084618wrp.426.1591825606742; Wed, 10 Jun 2020 14:46:46 -0700 (PDT) MIME-Version: 1.0 References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> In-Reply-To: <6033f9cecbf10f50f4a713ce52105426@kernel.org> From: Julien Grall Date: Wed, 10 Jun 2020 22:46:35 +0100 Message-ID: Subject: Re: Keystone Issue To: Marc Zyngier Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , CodeWiz2280 , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Marc, On Tue, 9 Jun 2020 at 18:45, Marc Zyngier wrote: > > I was wondering if you heard about any potential issue with guest EOI > > not forwarded to the host. This is on TI Keystone (Cortex A-15). > > Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway > all run just fine with guest EOI), and GIC-400 is a pretty solid piece > of kit (it is just sloooooow...). > > Thinking of it, you would see something like that if the GIC was seeing > the writes coming from the guest as secure instead of NS (cue the early > firmware on XGene that exposed the wrong side of GIC-400). Ah, I remember that one. We used to carry an hack in Xen [1] for X-Gene. Thankfully they fixed the firmware! If it is a similar issue, then the firmware path would definitely be my preference. Thank you for the input! Cheers, [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=50dcb3de603927db2fd87ba09e29c817415aaa44 From xen-devel-bounces@lists.xenproject.org Wed Jun 10 21:47:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 21:47:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj8ZT-0002Py-DC; Wed, 10 Jun 2020 21:47:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj8ZS-0002Ps-SL for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 21:47:42 +0000 X-Inumbo-ID: 02b03896-ab64-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 02b03896-ab64-11ea-b7bb-bc764e2007e4; Wed, 10 Jun 2020 21:47:42 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id p5so3975876wrw.9 for ; Wed, 10 Jun 2020 14:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CAp2rjehIvYjAHsjdSiddbXOkmRYOn32bN6XG12cOEs=; b=CXz9RFxjHFeAwkwkxSyWrq2kjUQAOxDaf+duRQvCuKmwljg9aKSqkeWeoiskENBSv7 uK9Bg2cGI0n6MjwRLkR/MtLhMhBc97ANN8Wz9QA5pZfdJVbB946r3YD929n4ffTi3qKq noAXnE+g5/GuDHSyPw47yZgBiCjW818WcCnxaOwecpA4eZKGwL4ZYUzI/ktYGTPiLs1u 5xPtUa6Eq4aUmHnWylWzHHWWXIDaeUcAa5lqLnPCMhRK9563rRcL6I1oy6wDzforcXKC MpCOhlrUWUA82dukpjzlOIUyBysBEFd1mzQXyTKs+TM4VCbWqaCfRuuGEYiQezyB4qK0 Yh/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CAp2rjehIvYjAHsjdSiddbXOkmRYOn32bN6XG12cOEs=; b=RDoi3QvOQF7PsfUQqiG8AioyPCJdfnGyL9cYsOKG4v/auX5lo1iUBaEm/B3mdLRvAT bi7Ee0ON3ORW2s99IxUoc4NhY9bDTUa64pHtVCgD6zURLJ/9TS2s1NmQHAT6hPZ243rV PhPOIsvsFeu3kUVFeLu9jn+m8gxFapaLUD1hzM1UzuufIdfunZydnn+oaBusNYCXRgA0 pGsRfRBCBDTTcpGAuT4OI1nm0fDg5jua0DPStoFNUgHSycIzSMGVq31swwj/CteCEs5u EHP+FEBk+nJ/2NAhpdod6DKJCyz/6uLWH+1ZphbGmd8jKiZLQL3VX2GvAI4ALo+ZajD9 azEA== X-Gm-Message-State: AOAM531ktob3gxYl87YRsOlYiEIJ+AWcr4a2YH/Rh+Xeh2sU8xIjMH/n NO9yRXx6zJKcGXqqltEMuvKF9qydYCrvC3nYyLs= X-Google-Smtp-Source: ABdhPJwOSYlSMcq2o/Cr7knWtshZaThoL7Hap9VXOIR/ZPH2fgi6Uj4Ht3F+xs6gTR30J2Z+rWBZ1GZ1ZdkH+LbXuuI= X-Received: by 2002:a5d:4ec3:: with SMTP id s3mr6258092wrv.103.1591825661480; Wed, 10 Jun 2020 14:47:41 -0700 (PDT) MIME-Version: 1.0 References: <20200609154546.4531-1-jgross@suse.com> <4a3c4e5e-1fbd-5017-1e3e-64052ae2410a@xen.org> In-Reply-To: From: Julien Grall Date: Wed, 10 Jun 2020 22:47:30 +0100 Message-ID: Subject: Re: [PATCH for-4.14] xen/hypfs: fix loglvl parameter setting To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Paul Durrant , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 10 Jun 2020 at 19:49, J=C3=BCrgen Gro=C3=9F wrote= : > > On 10.06.20 19:55, Julien Grall wrote: > > Hi Juergen, > > > > On 09/06/2020 16:45, Juergen Gross wrote: > >> Writing the runtime parameters loglvl or guest_loglvl omits setting th= e > >> new length of the resulting parameter value. > >> > >> Reported-by: George Dunlap > >> Signed-off-by: Juergen Gross > > > > Reviewed-by: Julien Grall > > > > Although one unrelated comment below. > > > >> --- > >> xen/drivers/char/console.c | 19 +++++++++++++++---- > >> 1 file changed, 15 insertions(+), 4 deletions(-) > >> > >> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c > >> index 56e24821b2..861ad53a8f 100644 > >> --- a/xen/drivers/char/console.c > >> +++ b/xen/drivers/char/console.c > >> @@ -241,14 +241,25 @@ static int _parse_loglvl(const char *s, int > >> *lower, int *upper, char *val) > >> static int parse_loglvl(const char *s) > >> { > >> - return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thres= h, > >> - xenlog_val); > >> + int ret; > >> + > >> + ret =3D _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thre= sh, > >> + xenlog_val); > >> + custom_runtime_set_var(param_2_parfs(parse_loglvl), xenlog_val); > > > > Mixing function and variable name is pretty confusing. It took me > > sometimes to go through the macro maze to figure out what's happening. > > > > It might be worth thinking to document more the custom_runtime_* interf= ace. > > I have already some streamlining ideas for 4.15. Cool! I will commit it tomorrow morning. Cheers, From xen-devel-bounces@lists.xenproject.org Wed Jun 10 21:56:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 10 Jun 2020 21:56:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj8ha-0003LY-Dp; Wed, 10 Jun 2020 21:56:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj8hZ-0003L8-BH for xen-devel@lists.xenproject.org; Wed, 10 Jun 2020 21:56:05 +0000 X-Inumbo-ID: 2a718852-ab65-11ea-b4bc-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2a718852-ab65-11ea-b4bc-12813bfff9fa; Wed, 10 Jun 2020 21:55:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SpFxnaSFfDYs4DSZZiKDf7aZGdRGE7hkeJYzx0/bkUI=; b=hXF2dr8H/4I6Al6BhfI4EI8Lt /pEtCxZMU1sQfvYwgiaXXQ2HxyqLJrPWs0PkM9vBlgeSBJ013fzyrTsqK//fkijDrBOnpfHjQ/osS xz9QamViU9wDJN2kReZMgSRlB0wIRLl+QSitHAGAGhmivYorTGL9rLbdU6RCYoS1AE+Bw=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jj8hR-0000zD-Ns; Wed, 10 Jun 2020 21:55:57 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jj8hR-0002Y5-De; Wed, 10 Jun 2020 21:55:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jj8hR-0001UT-D3; Wed, 10 Jun 2020 21:55:57 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 150970: tolerable FAIL - PUSHED X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: qemuu=31d321c2b3574dcc74e9f6411af06bca6b5d10f4 X-Osstest-Versions-That: qemuu=49ee11555262a256afec592dfed7c5902d5eefd2 From: osstest service owner Date: Wed, 10 Jun 2020 21:55:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150970 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/150970/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150930 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150930 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150930 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150930 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150930 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150930 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150930 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: qemuu 31d321c2b3574dcc74e9f6411af06bca6b5d10f4 baseline version: qemuu 49ee11555262a256afec592dfed7c5902d5eefd2 Last test of basis 150930 2020-06-08 21:37:21 Z 2 days Testing same since 150970 2020-06-09 20:36:22 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Artyom Tarasenko Peter Maydell Philippe Mathieu-Daudé jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/qemu-xen.git 49ee115552..31d321c2b3 31d321c2b3574dcc74e9f6411af06bca6b5d10f4 -> upstream-tested From xen-devel-bounces@lists.xenproject.org Thu Jun 11 01:17:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 01:17:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjBpq-0004Jm-3f; Thu, 11 Jun 2020 01:16:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjBpp-0004JM-OK for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 01:16:49 +0000 X-Inumbo-ID: 35bb0b40-ab81-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 35bb0b40-ab81-11ea-8496-bc764e2007e4; Thu, 11 Jun 2020 01:16:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=B5AbnI/lrX+lFVnbN5DLKFblirE2SZ3crJuS8xEO+Wc=; b=VQkrwg55tL9/C8hcgwFlDY+U6 pbQua8pTEG2cpIpIN5I2cw0VaZZMwS9XWbf2Mxs6CGQSwy0Yyyv1bop1GHd5hiGP1W/XeaUv9hs6N xlpSTzueeDUgbF8iKEGi+YnrU2Vf5M4wJ/2BBwenzAv+2heNTiVBhDPRs6txUWVMIN44s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjBpi-0006dD-5d; Thu, 11 Jun 2020 01:16:42 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjBph-0004nD-T0; Thu, 11 Jun 2020 01:16:41 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjBph-0002CX-R7; Thu, 11 Jun 2020 01:16:41 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 150991: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=199ae1f15894bd1bdefdf7c3e44688127be3ba19 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Thu, 11 Jun 2020 01:16:41 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150991 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/150991/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150176 build-i386-prev 6 xen-build fail REGR. vs. 150176 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 199ae1f15894bd1bdefdf7c3e44688127be3ba19 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 27 days Testing same since 150943 2020-06-09 17:06:00 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Thu Jun 11 01:36:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 01:36:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjC8Z-00060X-TR; Thu, 11 Jun 2020 01:36:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjC8Y-00060C-Ck for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 01:36:10 +0000 X-Inumbo-ID: e7d1dbc2-ab83-11ea-b4cf-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e7d1dbc2-ab83-11ea-b4cf-12813bfff9fa; Thu, 11 Jun 2020 01:36:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ecIqeEYUKKYkGLQfViY3ZZ8exwlNlYXWvbNbDg4crNo=; b=fEIQNQ9NGu0Z6F2i+H6K/JKFL Ajp3luBL7tdChsDqSV+g27HS7boIdaVktCyQ54Wq0Eg3bb/XRGgkdm1aHDFG+5NcjoCLRl37jovOW Evmp2mMgxfe2DGY6ol8LvOTRGrR6LLWQR0K78dBVQEu9Af1FN9FdkUHYqQyIYf/N97Vyg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjC8O-0006yE-3v; Thu, 11 Jun 2020 01:36:00 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjC8N-0005E0-IM; Thu, 11 Jun 2020 01:35:59 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjC8N-0002nm-GP; Thu, 11 Jun 2020 01:35:59 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 150997: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=cfdceb9754bde5d161c21a65e621ef20c47f1eaf X-Osstest-Versions-That: libvirt=2f82fe467f7a67d11500a566054b403e9d6d0a9c From: osstest service owner Date: Thu, 11 Jun 2020 01:35:59 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 150997 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/150997/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150932 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150932 test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt cfdceb9754bde5d161c21a65e621ef20c47f1eaf baseline version: libvirt 2f82fe467f7a67d11500a566054b403e9d6d0a9c Last test of basis 150932 2020-06-09 04:20:38 Z 1 days Testing same since 150997 2020-06-10 04:19:42 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Bihong Yu Jiri Denemark Michal Privoznik Peter Krempa jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 2f82fe467f..cfdceb9754 cfdceb9754bde5d161c21a65e621ef20c47f1eaf -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Thu Jun 11 01:40:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 01:40:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCCM-0006pI-Fv; Thu, 11 Jun 2020 01:40:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCCK-0006Al-Pa for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 01:40:04 +0000 X-Inumbo-ID: 75094426-ab84-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 75094426-ab84-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 01:39:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YYVbmNhT5nIck4JfD9g8FwWXh2GYy8d6LrrjWGQgg/U=; b=gbNA+D1wZ8QRSdJ/jEo6UpBmH 8H6VnyvlDZtvnWK4vJVDU2TmydP2Gwt8IeF0N0FXCwO0O4X/KeDFnJdXUgte+8N0UheWZi/J/ay5m 7mlQ2vutrCGWGkFOsiva0UQWJY5w5oroQFcTvKD3bsijgO5yBviOM+KhZTy9iS8b5RmBs=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCCD-000725-2P; Thu, 11 Jun 2020 01:39:57 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjCCC-0005Ip-MI; Thu, 11 Jun 2020 01:39:56 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjCCC-0007x5-Lb; Thu, 11 Jun 2020 01:39:56 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 151011: regressions - FAIL X-Osstest-Failures: xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-i386:xen-build:fail:regression xen-4.10-testing:build-arm64-xsm:xen-build:fail:regression xen-4.10-testing:build-arm64:xen-build:fail:regression xen-4.10-testing:build-amd64:xen-build:fail:regression xen-4.10-testing:build-amd64-xsm:xen-build:fail:regression xen-4.10-testing:build-i386-xsm:xen-build:fail:regression xen-4.10-testing:build-armhf:xen-build:fail:regression xen-4.10-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-pvhv2-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.10-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-pvhv2-amd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=a1a9b055a349748083665e42843f75d6db2c6a7b X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Thu, 11 Jun 2020 01:39:56 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151011 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151011/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386-prev 6 xen-build fail REGR. vs. 150039 build-i386 6 xen-build fail REGR. vs. 150039 build-arm64-xsm 6 xen-build fail REGR. vs. 150039 build-arm64 6 xen-build fail REGR. vs. 150039 build-amd64 6 xen-build fail REGR. vs. 150039 build-amd64-xsm 6 xen-build fail REGR. vs. 150039 build-i386-xsm 6 xen-build fail REGR. vs. 150039 build-armhf 6 xen-build fail REGR. vs. 150039 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a version targeted for testing: xen a1a9b055a349748083665e42843f75d6db2c6a7b baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 36 days Testing same since 150941 2020-06-09 17:05:34 Z 1 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit a1a9b055a349748083665e42843f75d6db2c6a7b Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit afca67fafde22033b9a967ae197a10af5c654f02 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Thu Jun 11 02:20:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 02:20:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCow-0001Ps-OZ; Thu, 11 Jun 2020 02:19:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCov-0001Pn-QY for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 02:19:57 +0000 X-Inumbo-ID: 0b68be7e-ab8a-11ea-bca7-bc764e2007e4 Received: from mail-qt1-x841.google.com (unknown [2607:f8b0:4864:20::841]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0b68be7e-ab8a-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 02:19:57 +0000 (UTC) Received: by mail-qt1-x841.google.com with SMTP id g62so3522782qtd.5 for ; Wed, 10 Jun 2020 19:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HZna+dvbx6XbLhq6c1A4NTyxG9xhwm8M/vKDqUdnlKM=; b=G4zcufPWuKf8GJhsLpA5hHr7cfQXQOD86Nuk29yETP0LaD5RtcnGr5Z5jWI8gU4/c/ ZfSX3V8RmfTa7e6Apr/5IFA7gdx96oDjynEeYKEAT01EkWImYrWWmZ4cyiYQ7s32hNBX u/sXVhb+yLrjAZoi+B/o0zTE3JUWePA45v5MIHhuF0eSjQecnx9sMKp9/NFLI2VDlLR+ ZkyESiBJ2cJw1vssPbxw8EmaMSMeAzDURcHmg8ZVO7hvjSa4vdjr6RX5xaH6YxxkQN/Z 8EDpecwFF42giWDAq6o5QiZLcy/q4xw+4rHxZt3AjJ+BNFQEAQVQz4ZePvGgd64P1V7G dCRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HZna+dvbx6XbLhq6c1A4NTyxG9xhwm8M/vKDqUdnlKM=; b=cXEiuzM3DeRv+zPwsLQrFemz29atlGmAuiuRsIgg0zH+G23QKr6+wxu/czLF4oF0Mi EmRBdl+GMq3MJCQk3mu1w0LEa7PGJXdaSxwThbskTw1UCW0n6dJzNv+fxt70zeXDSTJ2 MmtOL6xIVNET0pbDQPd3WjXaEJ/3dswZff6kM6+ODuT5ozFIb2IyxE+PykMlV95XMbO5 9TE/SoGSieeIpHZGFkJpiQEYtFTY2u0aQnoeJZaSZGE7on/D8fZ9rAWEGQFE4AVRDcgY NjIfz31OG0thD2CUydQXYzNFGol994sc8N1z//CkDWi+Ftxg0X2di6DwR7h0eAl4d70F BBOQ== X-Gm-Message-State: AOAM533bZZ+yjpEVVVlbkLtqCXbrseRlAbGKVU6MhDFPq4pLogyaOezo 6HZVVBjmPFiT7S5nz5BNaRO07fAMSsCQ1NgPH/ixQw== X-Google-Smtp-Source: ABdhPJxc5PRydCAbLvgTyZYGhh1SRbhlxTpM9Xh/WhWqqhZYJMw4hKBofLcsc83+OnJT+O4FBu7v3Aq3Q6Bs7ateOfM= X-Received: by 2002:ac8:40dc:: with SMTP id f28mr4113698qtm.63.1591841997045; Wed, 10 Jun 2020 19:19:57 -0700 (PDT) MIME-Version: 1.0 References: <20200610185415.GG7231@minyard.net> In-Reply-To: <20200610185415.GG7231@minyard.net> From: Roman Shaposhnik Date: Wed, 10 Jun 2020 19:19:45 -0700 Message-ID: Subject: Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel To: Corey Minyard Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Stefano Stabellini , Julien Grall , tamas@tklengyel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote: > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > existing sd cards, and this was working fine. I finally got to a full > yocto build of the system, and it didn't boot. > > In fact, Xen didn't print anything at all, and nothing happens that > might suggest it's booting without any console output. > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > else the same, the 4.19 version of that overlay works, and the 5.4 > version does not work. It also didn't work if I completely removed the > overlay. The base device trees are the same between the two kernels. > > Looking at the overlay changes between the versions and Xen source, I > can't trace down anything that would cause an issue. Has anyone seen > this issue of have any ideas? FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to 5.6.x: https://github.com/raspberrypi/linux/tree/rpi-5.6.y The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Thu Jun 11 02:22:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 02:22:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCrM-00029X-5D; Thu, 11 Jun 2020 02:22:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCrL-00029R-G2 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 02:22:27 +0000 X-Inumbo-ID: 637a9560-ab8a-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 637a9560-ab8a-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 02:22:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hYclezj2Kpldzd4SGyA7dtoo+G0gYp5mtmFPLuFrLyA=; b=KJtHL8qKtW0PfAjCPnX+DWtk4 ccgauqP0TizPKOWPdB5YMfczd/XM4OpDnK58jQCqHjESsyJq+G0JqVoslNlS6B9P3owS1v7bIb4pD DDoHRuQkP6tPZ06oa+4slgaW3efmWIfxglNeUhqvlOHoh4v5k5VqvtYsXFXzCDelZRkWg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCrI-0008Fo-Ns; Thu, 11 Jun 2020 02:22:24 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjCrI-0006Ku-A3; Thu, 11 Jun 2020 02:22:24 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjCrI-0001Pa-9L; Thu, 11 Jun 2020 02:22:24 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151012: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-arm64:xen-build:fail:regression xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:build-amd64-xsm:xen-build:fail:regression xen-4.11-testing:build-arm64-xsm:xen-build:fail:regression xen-4.11-testing:build-i386:xen-build:fail:regression xen-4.11-testing:build-i386-xsm:xen-build:fail:regression xen-4.11-testing:build-amd64:xen-build:fail:regression xen-4.11-testing:build-armhf:xen-build:fail:regression xen-4.11-testing:test-amd64-amd64-xl-pvhv2-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvhv2-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:build-check(1):blocked:nonblocking xen-4.11-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.11-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.11-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-pvshim:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Thu, 11 Jun 2020 02:22:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151012 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151012/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64 6 xen-build fail REGR. vs. 150040 build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 build-amd64-xsm 6 xen-build fail REGR. vs. 150040 build-arm64-xsm 6 xen-build fail REGR. vs. 150040 build-i386 6 xen-build fail REGR. vs. 150040 build-i386-xsm 6 xen-build fail REGR. vs. 150040 build-amd64 6 xen-build fail REGR. vs. 150040 build-armhf 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a version targeted for testing: xen b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 36 days Testing same since 150942 2020-06-09 17:05:43 Z 1 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-amd64-xl-pvhv2-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-amd64-xl-pvhv2-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-xl-pvshim blocked test-amd64-i386-xl-pvshim blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Thu Jun 11 02:25:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 02:25:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCuS-0002Jw-Pg; Thu, 11 Jun 2020 02:25:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCuR-0002Jq-Fy for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 02:25:39 +0000 X-Inumbo-ID: d423a72a-ab8a-11ea-b4d3-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d423a72a-ab8a-11ea-b4d3-12813bfff9fa; Thu, 11 Jun 2020 02:25:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DL5F43nTTwd6mbbR9U1fqCVGQuZUTn4xlpe2exY9GzU=; b=yC9Cf7eFcRvgcP0BHgfL2gQ4W cphXMpo6UgzTAcGTct1kWk00KiKBOb7wBcFnhhWP1yNPyqVEM3V2jv7FUJQtuosFKr8bSHT/0r4+X lKuA7m3G+Gum5ZRUCG/VLW9GQYMlO0Kwy0BTTz3k2Pv/5fW8qOmO4XqEMUlcfjz4suDMQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjCuL-0008Ik-TS; Thu, 11 Jun 2020 02:25:33 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjCuL-0006Ou-Ju; Thu, 11 Jun 2020 02:25:33 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjCuL-00047Y-IA; Thu, 11 Jun 2020 02:25:33 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 151013: regressions - FAIL X-Osstest-Failures: xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-arm64-xsm:xen-build:fail:regression xen-4.9-testing:build-arm64:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-armhf:xen-build:fail:regression xen-4.9-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=ad0c1a0023077ee03d325a6f84bb654150539f49 X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Thu, 11 Jun 2020 02:25:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151013 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151013/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-arm64-xsm 6 xen-build fail REGR. vs. 150120 build-arm64 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-armhf 6 xen-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a version targeted for testing: xen ad0c1a0023077ee03d325a6f84bb654150539f49 baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 32 days Testing same since 150940 2020-06-09 17:05:20 Z 1 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:30:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:30:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDv1-0007xi-M9; Thu, 11 Jun 2020 03:30:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDuz-0007xd-VV for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:30:18 +0000 X-Inumbo-ID: deb0e65e-ab93-11ea-b7bb-bc764e2007e4 Received: from mail-qt1-x842.google.com (unknown [2607:f8b0:4864:20::842]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id deb0e65e-ab93-11ea-b7bb-bc764e2007e4; Thu, 11 Jun 2020 03:30:17 +0000 (UTC) Received: by mail-qt1-x842.google.com with SMTP id j32so3581374qte.10 for ; Wed, 10 Jun 2020 20:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Q8ajjPfNfXlfaUIObFCSSsRlFcGxHZregYc1KnoZkdc=; b=i+VgovDkfnd3LziCf0T4rcJ1hWApwbSLh0MfmvJcOzLB4Bgdcb+uPGtT0Eg/pnizet 7AJcwyHds+zaVoARrwjx5aG2szCcid542NLO+g5jM6P+bTgHavq5LzmXN+z8uX1tNs43 +YM3DFDWocC1subzOxgnD6h+GN8Ryboqp8KKacly1lMaYoVuySVmaAVepvS3hwGBgMG2 kOVHh68jNx3iS3OTKuDhESHsz1B2Jovfk2SEtzRXsD2PpBVq22+9mqAbuaLrHMDeSGSZ SJV2keiUoo+la+xwFGP4dLudBNSctcJP4aGPXegNWCJyzi2b4LkwrK4sVC7gWEmWzFgu URNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Q8ajjPfNfXlfaUIObFCSSsRlFcGxHZregYc1KnoZkdc=; b=RWIf3dpajvHOVZol8JqibrRyVGKp/hRAVIXfdGvGCBVj2fYzh1BSsGItyn0pVE/sq5 QY6/j+gg+dVLSRrnpW9L+hgXokyzydtu/Bm2TVAKdzfhJ7HEPyfMbM+dMx0OOS3mOUhB gdE2gjDq0x9tUfBepvelagqCY2IkZedNh6qkSQ1v66GX3RlifvUeouWr7baH8A3HXKKu nwcBKk4IBHvrT+hW3U2veiTYI9cl4BbB6Cg2GLB6lHL+PeL8n1C5A0fz5O4eW1yA5HkC yw/qBd6LlsdSyszP6c5qGJMxQj0yk96z/yFy4XyMtd+/4/6MnoAmwprmlcb35xpPDxAL Vg7A== X-Gm-Message-State: AOAM530S4Y4baurwDOrRXYEoBprDCRvAv4LujxaBISgC+qGFEw0YzHyE uFvtjrMnFrktwrSEwnZj2aLLbyu0 X-Google-Smtp-Source: ABdhPJwNq26gIu0+54W7Z2GYJT9hIjdtpKfesEulzEowTtm7uhlhG/NQWxK07dRBg7/YOJIYEgIraQ== X-Received: by 2002:aed:35fa:: with SMTP id d55mr6440367qte.385.1591846216558; Wed, 10 Jun 2020 20:30:16 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:15 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 00/10] Coverity fixes for vchan-socket-proxy Date: Wed, 10 Jun 2020 23:29:26 -0400 Message-Id: <20200611032936.350657-1-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This series addresses some Coverity reports. To handle closing FDs, a state struct is introduced to track FDs closed in both main() and data_loop(). v2 changes "Ensure UNIX path NUL terminated" to avoid a warning with gcc-10. Also, "Move perror() into listen_socket" and "Move perror() into connect_socket" are new. Jason Andryuk (10): vchan-socket-proxy: Ensure UNIX path NUL terminated vchan-socket-proxy: Move perror() into listen_socket vchan-socket-proxy: Move perror() into connect_socket vchan-socket-proxy: Check xs_watch return value vchan-socket-proxy: Unify main return value vchan-socket-proxy: Use a struct to store state vchan-socket-proxy: Switch data_loop() to take state vchan-socket-proxy: Set closed FDs to -1 vchan-socket-proxy: Cleanup resources on exit vchan-socket-proxy: Handle closing shared input/output_fd tools/libvchan/vchan-socket-proxy.c | 183 ++++++++++++++++++---------- 1 file changed, 119 insertions(+), 64 deletions(-) -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:30:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:30:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDv6-0007yC-1k; Thu, 11 Jun 2020 03:30:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDv4-0007xd-RF for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:30:22 +0000 X-Inumbo-ID: e18f3772-ab93-11ea-bca7-bc764e2007e4 Received: from mail-qt1-x841.google.com (unknown [2607:f8b0:4864:20::841]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e18f3772-ab93-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 03:30:22 +0000 (UTC) Received: by mail-qt1-x841.google.com with SMTP id e16so3632004qtg.0 for ; Wed, 10 Jun 2020 20:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HolYNn/5i3ZSFaAEzaxuKG/DWch8bwIGH3CfAGoU3Ss=; b=VVgNS8ITlTpaK8/lkmhim3IFmgZNw7DKAngtT00fCiDnKhyi/PhQ9DLcn2HoOkYlqF /jUWIOX4w26jasKRH8z1urMQ62Y+h5G/tS+xXwDopCSQkqlZo3r62ZeSCKSW+70TUlRZ jn6wZvU8Ca7/MGytIpdvxlvPZv61D88F0Dl4veVoFJ2TlE1bBjRGym1E8DMjskwxmHXS i35LUFJMZ1Cia6HnoLB/Q2WI3i2TMlazb5Cy1fy/bE2+vCyJfQiYayRR2dwQbF8KNKaM YUQJt2l0VGouCXlxveFZ8+GsUM+a8RkhW0JKT8u2GAsG60M11s6Ox3Sp3WUixnrUWFDG y02Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HolYNn/5i3ZSFaAEzaxuKG/DWch8bwIGH3CfAGoU3Ss=; b=ZBl35zuI+i0kF/ffzM+AdfsKf6vW0IazoQ6fyWHtMUTazDc3rbiCty8/g53hDyOMxd vEVXKYvjJZgclgyb4I+tp5gfU8c3tmiR3JFT2bogwD4i/2HcuN8DSXfSVYZt8mqsZQki cD3isk5kAL2NdzQu3L9l6MoqHFhCABo0MfI0FOAd27GWe87b+iOMef9Ma6YlfVTk8k6J KOwgLgrgBfFBHWSR7yx+G+5WIRDvkNXqXUgH65wgJpWRhHwckynA5d2HQPlmOPDWcxQj WCsdQc6t2x/NZCm/isoA28BSfIqwv56D07Npo+zocIOdZK0S7WnZky4TNYu5afCGZmXR pwqw== X-Gm-Message-State: AOAM531utmIPX4vy0hwlQWnUYDsHzx6Rs/ddGq+AJw/naGtl9HTa1Xfl fORPx9mIPlEpjf04qfjhK3TygvP2 X-Google-Smtp-Source: ABdhPJzlKG0E5XXLkreHbFwls+ALN2FyZ0CJj4vDAVLPJ/jsigbpwvPqDo+0W20M3K/N2KbwUEREbw== X-Received: by 2002:ac8:23e3:: with SMTP id r32mr6698656qtr.268.1591846221569; Wed, 10 Jun 2020 20:30:21 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:20 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 01/10] vchan-socket-proxy: Ensure UNIX path NUL terminated Date: Wed, 10 Jun 2020 23:29:27 -0400 Message-Id: <20200611032936.350657-2-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Olaf Hering , Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Check the socket path length to ensure sun_path is NUL terminated. This was spotted by Citrix's Coverity. Also use strcpy to avoid a warning "'__builtin_strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation]" flagged by gcc 10. Signed-off-by: Jason Andryuk --- CC: Olaf Hering With Ubuntu's gcc-10, which is a pre-release "gcc-10 (Ubuntu 10-20200411-0ubuntu1) 10.0.1 20200411 (experimental)", I couldn't actualy generate the strncpy warning. tools/libvchan/vchan-socket-proxy.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index 13700c5d67..6ae1d84143 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -148,12 +148,18 @@ static int connect_socket(const char *path_or_fd) { return fd; } + if (strlen(path_or_fd) >= sizeof(addr.sun_path)) { + fprintf(stderr, "UNIX socket path \"%s\" too long (%zd >= %zd)\n", + path_or_fd, strlen(path_or_fd), sizeof(addr.sun_path)); + return -1; + } + fd = socket(AF_UNIX, SOCK_STREAM, 0); if (fd == -1) return -1; addr.sun_family = AF_UNIX; - strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path)); + strcpy(addr.sun_path, path_or_fd); if (connect(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) { close(fd); return -1; @@ -174,13 +180,19 @@ static int listen_socket(const char *path_or_fd) { return fd; } + if (strlen(path_or_fd) >= sizeof(addr.sun_path)) { + fprintf(stderr, "UNIX socket path \"%s\" too long (%zd >= %zd)\n", + path_or_fd, strlen(path_or_fd), sizeof(addr.sun_path)); + return -1; + } + /* if not a number, assume a socket path */ fd = socket(AF_UNIX, SOCK_STREAM, 0); if (fd == -1) return -1; addr.sun_family = AF_UNIX; - strncpy(addr.sun_path, path_or_fd, sizeof(addr.sun_path)); + strcpy(addr.sun_path, path_or_fd); if (bind(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) { close(fd); return -1; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:30:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:30:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvB-0007yd-AA; Thu, 11 Jun 2020 03:30:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDv9-0007xd-RQ for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:30:27 +0000 X-Inumbo-ID: e335d77a-ab93-11ea-8496-bc764e2007e4 Received: from mail-qt1-x844.google.com (unknown [2607:f8b0:4864:20::844]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e335d77a-ab93-11ea-8496-bc764e2007e4; Thu, 11 Jun 2020 03:30:24 +0000 (UTC) Received: by mail-qt1-x844.google.com with SMTP id i16so3600419qtr.7 for ; Wed, 10 Jun 2020 20:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Xuj1oyeuSUlKPQJS2nl7hDTURFrye9RvexdzOTb7cJ0=; b=f1IGQWYC+vrigx8yJ2oxfZQUfd/70HCG0opTR9Qbko8LYtBPE3qe73aJ3ukY3/+3fG DYUS2JEoIEQErVe2yUc3Jjj21GRTeOLSB7FIViB46I8bnKGImeSrIJjat9Jpk9N6piue 1KVClOUQpySylxyMPEMfEfC0fiHRNb6SXhgK17a//Dy96tdgKphWyIkLzrCuV62eD/V6 Qt3Xqell8qsazRLSJinS29uOw3vHXMvbn59s+BBI/xppkkn6KkjTPuurf6EBTctdPa+n bqvX7vmONfTndckCrJV2dhHM2+ppGkZtWVoJJU+VNXSShsHv/ND55G0LLA+OJsOuH49C Gmyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Xuj1oyeuSUlKPQJS2nl7hDTURFrye9RvexdzOTb7cJ0=; b=qN3z3vTEiFiTQ394YlKfFc+HRac1/qe/JukOrQmOUQho5fsZtrp/4t+HdPVZfPfaqc BAKYdey98UWSO8WByFxZKJFI1fubXVwXPmtHZipSq1txtGPLylTsM/ha3nbdQ51CQYTK RqESlDpjBLL78Ix3Nw8MLxMU36DHR+B6E8e4SKMLefJMyYHRskPCezYIdDNce6uv/vYy B5cYfsHGiOo/cZSQQ8XJkhsNq37vU7VTbbyCfG4SuqaNoeiSwPfVXjX97BTLhpv5Cdcm PEsf7jUI/xexO7pYXTHc3hhH5RF+BIuTTwv2prApL7yWsMEnVeSkn9oiW8CnzBSuKnMb D8gg== X-Gm-Message-State: AOAM530Qeo0P0P/CtdbsVL1+sN5oZmhvmObXUnGNKdKKVB3lFIk59eSb S59jWdufPADOhEj7DL6k43nj6elz X-Google-Smtp-Source: ABdhPJwO3IQ1jhD/t3O/3FRk4P3EWIPbIG10rbuhK9cU3ErZSxtylF1zUqqetUppzSAXRBSUKv+EtA== X-Received: by 2002:ac8:22e5:: with SMTP id g34mr6742379qta.227.1591846224351; Wed, 10 Jun 2020 20:30:24 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:23 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 02/10] vchan-socket-proxy: Move perror() into listen_socket Date: Wed, 10 Jun 2020 23:29:28 -0400 Message-Id: <20200611032936.350657-3-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The use of perror on the return from listen_socket can produce misleading results like: UNIX socket path "/tmp/aa....aa" too long (156 >= 108) listen socket: Success errno is reset by subsequent system & library calls, so it may be inaccurate by the time listen_socket returns. Call perror immediately after failing system calls to print the proper message. Signed-off-by: Jason Andryuk --- tools/libvchan/vchan-socket-proxy.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index 6ae1d84143..4edc3a44f5 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -188,16 +188,20 @@ static int listen_socket(const char *path_or_fd) { /* if not a number, assume a socket path */ fd = socket(AF_UNIX, SOCK_STREAM, 0); - if (fd == -1) + if (fd == -1) { + perror("socket"); return -1; + } addr.sun_family = AF_UNIX; strcpy(addr.sun_path, path_or_fd); if (bind(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) { + perror("bind"); close(fd); return -1; } if (listen(fd, 5) != 0) { + perror("listen"); close(fd); return -1; } @@ -419,7 +423,7 @@ int main(int argc, char **argv) } else { socket_fd = listen_socket(socket_path); if (socket_fd == -1) { - perror("listen socket"); + fprintf(stderr, "listen socket failed\n"); return 1; } } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:30:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:30:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvF-000805-I2; Thu, 11 Jun 2020 03:30:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvE-0007xd-Rk for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:30:32 +0000 X-Inumbo-ID: e450c340-ab93-11ea-bca7-bc764e2007e4 Received: from mail-qt1-x842.google.com (unknown [2607:f8b0:4864:20::842]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e450c340-ab93-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 03:30:26 +0000 (UTC) Received: by mail-qt1-x842.google.com with SMTP id w9so3618204qtv.3 for ; Wed, 10 Jun 2020 20:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=s1VW2Vbm9sbX6brqSfDiW+eia7lSqgNEJbMvS1O/20A=; b=EPUSz/BRdjcU7hP3v7u/F8J+qfjEClfVqyZBfTFDr6ebh4j18yhW1QVN03jn/cdCHS rOtnhrFDrDbA7d3NHy4LhhCd3err3yQSKlritxvGKydhtRXXCpqd619CxZsFQS8fv2Rj Yil8DnifXsTnpGhbgepEMi4sozVhkbJZTCW/nZiX98SqfR2t5NfaLX+ChMJa/lbPoSs6 Jp99HPqryyKMKfbGGHG4SRBM1PUiMZWQ34z0SpHoNSn9TO/Oq/9eOHBSuE6OSf6G9pAK 98XxOJ7noVUvVp9n2ZZAptDkCt+nlRXZg6jH+AF83C7Nch/jae2679cnXj+DTAyhRDoH uGfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=s1VW2Vbm9sbX6brqSfDiW+eia7lSqgNEJbMvS1O/20A=; b=lsauzh7vzFnmqLzLeOp5ICTpiglMSHhKq3dz33upJoWNOC3kuxXgCwrZQHe0NOQNYr O9/9SccQVd0spcPeTrA8HpCptg5b+f5YAP87TBzEpefqgilsd+uQfTGlnDmWE74L9ZKx L8JuSUiQGshIaCPbqOvk2XLwxiR+Tp6WomOhAqKo7Cx1mPJAeMfFpeWU9El+uquDoJm2 +pVG5v2Ncp6Z0K/sIf1mNdRa/mO3zS4jFtgH8b6xaz8Gg6KQfmelbHE49p7dJ4Bd9OV3 TM3S25UfzSD3ZBZDrlK5bQYgg+Iltes1pSC7nKW5i6T17fnFAR0SC47vA5Oj52fkRZ3s n01w== X-Gm-Message-State: AOAM533w1dyAKNVpzkGoSE76VuUcCq6WiAxhK9o9HrrhKI5sDUPt+POB lo4RAJZF/WeRUBtVQrHrINVtD54D X-Google-Smtp-Source: ABdhPJwThClwsV971Q6HYvvQGLd5cWakFsLrNXUri9Wvl5vA+lhutV/8hPOFwNn7czZX+S7kCd+0VA== X-Received: by 2002:ac8:6f79:: with SMTP id u25mr6687555qtv.183.1591846226187; Wed, 10 Jun 2020 20:30:26 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:25 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 03/10] vchan-socket-proxy: Move perror() into connect_socket Date: Wed, 10 Jun 2020 23:29:29 -0400 Message-Id: <20200611032936.350657-4-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" errno is reset by subsequent system & library calls, so it may be inaccurate by the time connect_socket returns. Call perror immediately after failing system calls to print the proper message. Signed-off-by: Jason Andryuk --- tools/libvchan/vchan-socket-proxy.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index 4edc3a44f5..c6a83e4712 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -155,12 +155,15 @@ static int connect_socket(const char *path_or_fd) { } fd = socket(AF_UNIX, SOCK_STREAM, 0); - if (fd == -1) + if (fd == -1) { + perror("socket"); return -1; + } addr.sun_family = AF_UNIX; strcpy(addr.sun_path, path_or_fd); if (connect(fd, (const struct sockaddr *)&addr, sizeof(addr)) == -1) { + perror("connect"); close(fd); return -1; } @@ -457,7 +460,7 @@ int main(int argc, char **argv) input_fd = output_fd = connect_socket(socket_path); } if (input_fd == -1) { - perror("connect socket"); + fprintf(stderr, "connect_socket failed\n"); return 1; } if (data_loop(ctrl, input_fd, output_fd) != 0) -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:30:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:30:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvK-00081y-RQ; Thu, 11 Jun 2020 03:30:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvJ-0007xd-Rk for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:30:37 +0000 X-Inumbo-ID: e561a434-ab93-11ea-bca7-bc764e2007e4 Received: from mail-qt1-x843.google.com (unknown [2607:f8b0:4864:20::843]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e561a434-ab93-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 03:30:28 +0000 (UTC) Received: by mail-qt1-x843.google.com with SMTP id y1so3581221qtv.12 for ; Wed, 10 Jun 2020 20:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=laRg1K8C6uMRUlZmD1dge7J/mbvALpacyvB5fuXQU54=; b=a7/hb9vsaW1Ysq7scxsVtU9RpygQmV9LYFn3t6AYoy45E8nA12+ux2ri78VaijfjiN G/Xu+wdZACU2soQYveVkUYkGsaoekaFhZehPn1ZV0zRnIqPeRvOLlchcns07ABG+NVmI NCqY/Yr2cYTUFccsQfhiIfuetj3sGLZ238U6qn/EmvWCw1c7uU7a6Eq8cn5d5WwZVq1X 5wRRyfEJbsS+qnP17JfPU4OkP/hmvMZ/IRtFXzcNTF2/OK0Ho+p9T43QxYETOAKCR12S eGbud4eknYVdJ2nk9DEH6X3LZfSkiJ0Dni1kjRrzk3jycwPRlVhxjjWtGNgICp7WGhJF K51A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=laRg1K8C6uMRUlZmD1dge7J/mbvALpacyvB5fuXQU54=; b=kG51DbajZyGt/tPLz7tGkwXdsuw+BVQ3+YtPiJk24aw4xjvejYiLu/ZlxauePJHvsY DOrGfY27IUl23EZoW0545rcPqamnz94mH4gUsafn9tKXDf+sjrbIzcHqliuE7E/G6fYd mFtMM54MWAo1z8GxqeotjHBIzs4ygn8iTxkaruloDsSwdCp/01tmmYSbsfV8NOS/sHDi aqHKskFQGjkiHoy6/YDLOFd3TYOFXuVq8r5sMw93B6MpXEjWUyzTx1+kUe2tSjgejUEw noYD93qEWos8tjANsL1DgVZ3Y66c9WqXZT9ueodVUxSdli80GqhR4WuEZLI05cu1dcZ0 Ewfg== X-Gm-Message-State: AOAM533PwucgxmwJLW9nh890GRUzQ4Aw767zf5FSMnKTFKZvopnQIucD tiARKG7muCW3Zc0075DvG3klAoXb X-Google-Smtp-Source: ABdhPJx1Kszbf/65QiiO87mphpbrCYAKOz1s5J+KcxRZftbQxetEHhaR2JYIUroKxCwaaZF2CojUFQ== X-Received: by 2002:ac8:3529:: with SMTP id y38mr6314203qtb.315.1591846228003; Wed, 10 Jun 2020 20:30:28 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:27 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 04/10] vchan-socket-proxy: Check xs_watch return value Date: Wed, 10 Jun 2020 23:29:30 -0400 Message-Id: <20200611032936.350657-5-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Check the return value of xs_watch and error out on failure. This was found by Citrix's Coverity. Signed-off-by: Jason Andryuk --- tools/libvchan/vchan-socket-proxy.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index c6a83e4712..196f6016b9 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -232,8 +232,15 @@ static struct libxenvchan *connect_vchan(int domid, const char *path) { goto out; } /* wait for vchan server to create *path* */ - xs_watch(xs, path, "path"); - xs_watch(xs, "@releaseDomain", "release"); + if (!xs_watch(xs, path, "path")) { + fprintf(stderr, "xs_watch(%s) failed.\n", path); + goto out; + } + if (!xs_watch(xs, "@releaseDomain", "release")) { + fprintf(stderr, "xs_watch(@releaseDomain failed.\n"); + goto out; + } + while ((watch_ret = xs_read_watch(xs, &watch_num))) { /* don't care about exact which fired the watch */ free(watch_ret); -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:30:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:30:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvP-00083s-4J; Thu, 11 Jun 2020 03:30:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvO-0007xd-Rq for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:30:42 +0000 X-Inumbo-ID: e641f156-ab93-11ea-bca7-bc764e2007e4 Received: from mail-qt1-x844.google.com (unknown [2607:f8b0:4864:20::844]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e641f156-ab93-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 03:30:30 +0000 (UTC) Received: by mail-qt1-x844.google.com with SMTP id e16so3632185qtg.0 for ; Wed, 10 Jun 2020 20:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=OV7hLic7QdG3BUdt8KJifuAGbNbuFpzMSDCmTGtRTHI=; b=FBXUPHhodN+sKzb9ZEnacuQ+nWFTGfIuss7ws1Hoiz8fCT9W223Py3wYhhm218fYrs hmWfdw5lEdK11CiWNA0E2QeTsoGzq99SC3OeQpUUerJqzzrxsd0DPuBE3WV0C0qPDQY8 D/iZCSEtyU1Oa7XaCRgPPNUTiWghAWVqys8WiIMhH9lpKLuAkf0s1uCiy1wrDu2jye31 xiGN2whoMy5wVaGjXCRF++zxJ0FLMHBLB1tMF+oLG8b52zxmRJ+14lJEeFqc+m8Fl+3e 1u2gS3w0rgaOsVNe6YKfb0VIYqdl88YFZRS5cuaniyNg6mU5DBR+5tuN2SVUW5s2bKMY eI5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=OV7hLic7QdG3BUdt8KJifuAGbNbuFpzMSDCmTGtRTHI=; b=FYtcPugEgKPlofIRWvgzRzd94CkpdFegkOuwNiqGHhj0oySQoyaTYvaZwBqEHHqC0c xtMsfuFlb6Qz25Mf5VOk9WUolxgnN6jTPwwbWSKOI7C12N2vT+oYbCiBwlcBBgngHg/u fFEzISx6ABDTbFVMZbSHySTPyZ0MC4kYOfff+Zi45zDeRUkirDC37DSSQ5akGYzOIYhT LB047+lKNTxfeDjnE7TYpujAJh0HZkwj4orDYF8gDqyyXLWsXOz26SYY3DXQtrKL9uW2 sDfEVc9y9dwQTIJBm0t95tf/oyly9UqunDwG9+Xxx4tAsVi2RzyIVIO+J9vMtPg/sFt7 6tUw== X-Gm-Message-State: AOAM532M2mQijyRdgj3okx4APx52kB8w4t2OFWStVRs+/I9YxIoHkMYl CppkBk6SLCB2Kzj025oHocPX6cdC X-Google-Smtp-Source: ABdhPJwJQtwUYbCgitLnSAMDSRlFD+GH7f+0kPhX2hfvFDCiPwSn2oJd1pKiZ9lOLpYWgP6NCVYZrA== X-Received: by 2002:ac8:341a:: with SMTP id u26mr6550830qtb.36.1591846229462; Wed, 10 Jun 2020 20:30:29 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:28 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 05/10] vchan-socket-proxy: Unify main return value Date: Wed, 10 Jun 2020 23:29:31 -0400 Message-Id: <20200611032936.350657-6-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Introduce 'ret' for main's return value and remove direct returns. This is in preparation for a unified exit path with resource cleanup. Signed-off-by: Jason Andryuk --- tools/libvchan/vchan-socket-proxy.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index 196f6016b9..36a2fe2cb8 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -388,6 +388,7 @@ int main(int argc, char **argv) const char *vchan_path; const char *state_path = NULL; int opt; + int ret; while ((opt = getopt_long(argc, argv, "m:vs:", options, NULL)) != -1) { switch (opt) { @@ -454,6 +455,8 @@ int main(int argc, char **argv) xs_close(xs); } + ret = 0; + for (;;) { if (is_server) { /* wait for vchan connection */ @@ -468,7 +471,8 @@ int main(int argc, char **argv) } if (input_fd == -1) { fprintf(stderr, "connect_socket failed\n"); - return 1; + ret = 1; + break; } if (data_loop(ctrl, input_fd, output_fd) != 0) break; @@ -481,14 +485,16 @@ int main(int argc, char **argv) input_fd = output_fd = accept(socket_fd, NULL, NULL); if (input_fd == -1) { perror("accept"); - return 1; + ret = 1; + break; } set_nonblocking(input_fd, 1); set_nonblocking(output_fd, 1); ctrl = connect_vchan(domid, vchan_path); if (!ctrl) { perror("vchan client init"); - return 1; + ret = 1; + break; } if (data_loop(ctrl, input_fd, output_fd) != 0) break; @@ -500,5 +506,6 @@ int main(int argc, char **argv) ctrl = NULL; } } - return 0; + + return ret; } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:30:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:30:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvU-00086a-Ek; Thu, 11 Jun 2020 03:30:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvT-0007xd-S4 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:30:47 +0000 X-Inumbo-ID: e7aaa2cc-ab93-11ea-bb8b-bc764e2007e4 Received: from mail-qk1-x742.google.com (unknown [2607:f8b0:4864:20::742]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e7aaa2cc-ab93-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 03:30:32 +0000 (UTC) Received: by mail-qk1-x742.google.com with SMTP id c185so4357305qke.7 for ; Wed, 10 Jun 2020 20:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=0QHpnXfDLIU42Ajcn7oe5u4g/H2EWJ6mBd+W546xwxc=; b=NYja3UulW133MDWz7THaPy5RuR9uRLPFZCcavpEeBICBdVNluA3ZqxpDPSIliOyRd5 DNKunBo1ICSU7dvWYlQIK8GVeYywImCazfZOIIsPyUiJajpMj8+6SmV7UHHwnmHARr8j l0rmbWl/rz7QfzSo+l+MSkQQxIH7r6CtEq/ximG7YGnGkLtARyqdx30cnhYK8UtyZTgR /EwEFHWc4Wt4uAF9+VYOCiY/Gmu166QHSuwqeo9WSNDdjmsOs5cRcShgU8wFmYeVnHOA 4OTs9lZ+GnbDX9b9Dis6xbIvvH43vBJb6Z0G8sjGSTmjap5ulZhq1nyu8uwWsu5Uofhg DOfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=0QHpnXfDLIU42Ajcn7oe5u4g/H2EWJ6mBd+W546xwxc=; b=miuW/iMVzxqVEYsS2dSLiKoW5nRL8qg1FKaUFtI3ZK7+kZZGxFnHi+/hjLb9jTaJpx jFlhAdJn0PEMpiCWkDi21Rol6sKe8fQerXadTKSPnAFWLCK1u1yEhqalIgjTBwC6LMQS pl6hu+TVZYjQRr5K+5/z9XyMnWBB4Tyyz7OWOPeG4k1vGjrwo+UbrwPrDy54a9bp/wHa toVhRd+yUCFMzqeVdqeupwdr9RaoBaxA75S3Jvspl2scyJ7SN5nc1QJIxxB9ecEZ9Qe0 QYDxRz7YQuJ3qHOJz0C9xlZ10jHjtfEwVOODqCVRnfDS2idAVwEdcLNBTYeOY07krYq2 pG9g== X-Gm-Message-State: AOAM533HucrZdPVvupr+mECX5vxEoPonpNC3PsCSnKMT+xfEgUDT7gvO sR03iPIidoQoHA8FhLlscVRm7EGV X-Google-Smtp-Source: ABdhPJwdhVkHS2DNi9/Nuua9kYv3yXSI9U6EZrJZD0L9oLp14VJMoLqPgvUyonhT8Gg2MqBfLOmlcA== X-Received: by 2002:a37:a64c:: with SMTP id p73mr6240900qke.273.1591846231748; Wed, 10 Jun 2020 20:30:31 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:31 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 06/10] vchan-socket-proxy: Use a struct to store state Date: Wed, 10 Jun 2020 23:29:32 -0400 Message-Id: <20200611032936.350657-7-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Use a struct to group the vchan ctrl and FDs. This will facilite tracking the state of open and closed FDs and ctrl in data_loop(). Signed-off-by: Jason Andryuk --- tools/libvchan/vchan-socket-proxy.c | 52 +++++++++++++++++------------ 1 file changed, 30 insertions(+), 22 deletions(-) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index 36a2fe2cb8..a932c94c97 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -89,6 +89,12 @@ int insiz = 0; int outsiz = 0; int verbose = 0; +struct vchan_proxy_state { + struct libxenvchan *ctrl; + int output_fd; + int input_fd; +}; + static void vchan_wr(struct libxenvchan *ctrl) { int ret; @@ -381,8 +387,9 @@ int main(int argc, char **argv) { int is_server = 0; int socket_fd = -1; - int input_fd, output_fd; - struct libxenvchan *ctrl = NULL; + struct vchan_proxy_state state = { .ctrl = NULL, + .input_fd = -1, + .output_fd = -1 }; const char *socket_path; int domid; const char *vchan_path; @@ -422,15 +429,15 @@ int main(int argc, char **argv) socket_path = argv[optind+2]; if (is_server) { - ctrl = libxenvchan_server_init(NULL, domid, vchan_path, 0, 0); - if (!ctrl) { + state.ctrl = libxenvchan_server_init(NULL, domid, vchan_path, 0, 0); + if (!state.ctrl) { perror("libxenvchan_server_init"); exit(1); } } else { if (strcmp(socket_path, "-") == 0) { - input_fd = 0; - output_fd = 1; + state.input_fd = 0; + state.output_fd = 1; } else { socket_fd = listen_socket(socket_path); if (socket_fd == -1) { @@ -460,21 +467,21 @@ int main(int argc, char **argv) for (;;) { if (is_server) { /* wait for vchan connection */ - while (libxenvchan_is_open(ctrl) != 1) - libxenvchan_wait(ctrl); + while (libxenvchan_is_open(state.ctrl) != 1) + libxenvchan_wait(state.ctrl); /* vchan client connected, setup local FD if needed */ if (strcmp(socket_path, "-") == 0) { - input_fd = 0; - output_fd = 1; + state.input_fd = 0; + state.output_fd = 1; } else { - input_fd = output_fd = connect_socket(socket_path); + state.input_fd = state.output_fd = connect_socket(socket_path); } - if (input_fd == -1) { + if (state.input_fd == -1) { fprintf(stderr, "connect_socket failed\n"); ret = 1; break; } - if (data_loop(ctrl, input_fd, output_fd) != 0) + if (data_loop(state.ctrl, state.input_fd, state.output_fd) != 0) break; /* keep it running only when get UNIX socket path */ if (socket_path[0] != '/') @@ -482,28 +489,29 @@ int main(int argc, char **argv) } else { /* wait for local socket connection */ if (strcmp(socket_path, "-") != 0) - input_fd = output_fd = accept(socket_fd, NULL, NULL); - if (input_fd == -1) { + state.input_fd = state.output_fd = accept(socket_fd, + NULL, NULL); + if (state.input_fd == -1) { perror("accept"); ret = 1; break; } - set_nonblocking(input_fd, 1); - set_nonblocking(output_fd, 1); - ctrl = connect_vchan(domid, vchan_path); - if (!ctrl) { + set_nonblocking(state.input_fd, 1); + set_nonblocking(state.output_fd, 1); + state.ctrl = connect_vchan(domid, vchan_path); + if (!state.ctrl) { perror("vchan client init"); ret = 1; break; } - if (data_loop(ctrl, input_fd, output_fd) != 0) + if (data_loop(state.ctrl, state.input_fd, state.output_fd) != 0) break; /* don't reconnect if output was stdout */ if (strcmp(socket_path, "-") == 0) break; - libxenvchan_close(ctrl); - ctrl = NULL; + libxenvchan_close(state.ctrl); + state.ctrl = NULL; } } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:30:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:30:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvZ-0008A2-TT; Thu, 11 Jun 2020 03:30:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvY-0007xd-SQ for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:30:52 +0000 X-Inumbo-ID: e8951ee2-ab93-11ea-bca7-bc764e2007e4 Received: from mail-qk1-x744.google.com (unknown [2607:f8b0:4864:20::744]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e8951ee2-ab93-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 03:30:33 +0000 (UTC) Received: by mail-qk1-x744.google.com with SMTP id q8so4321085qkm.12 for ; Wed, 10 Jun 2020 20:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=acDEo8MXiNoRRWQ/LKc41cpCF79OTRwWmw6nG02XKJE=; b=sRbm1ow6OMy4RlPfEgTljW9izUWN0W3hAaRtX7YSpSJRbcPKUyJM977UrI/CqjreUt JRFwICjEeLa3I4zG7Y/PH9PcqVpW7tW6/Os4BzeHGJkZZiSV2seuia9LAo7FQ1m6oqPa vvIsj8YShjmxi/nWzcdRAhCKOMJjpXlhKmjcfYNsRMclOHXFtRulwfJgNDZnk813xPg5 Zp/no8di6X9tDIZwJiNN2SlooqJgkZa3jRrpn0cuX1yzIx7n05+8F16TEUG5Xc415Q6E cFKmY6WAp45aSIpL1/i6XFGF14Kp79ZrUFVuttwaLJ8svEs/YS3AcnEcTOGHfzVvB0Ra czNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=acDEo8MXiNoRRWQ/LKc41cpCF79OTRwWmw6nG02XKJE=; b=cv17oiOiJZzA1YMmQwbDkmZz5/KTkSUeY10QZ3Eju9ah9mFnWiFyOtXXEL2O6B8EcT mt+5kHEiY2oyXCoqrVdmQESBWSI+t4cgTJnoTf4Gxhz473P4qvXwyysRvkMsUKpTUUBw PmDZKKoCqDHskDrjOJ9vzFfYYtH9w+oAlOTnfNY3L3p7GdXv6FJwIFbYUyH6PfGDjS43 BRx7/tT0bj6ZJcKYS49Cjde/IRdizvtdYtKvbgA+3cLLDzlMPNLX6BexDnpk5KEmVDll vdZqBdUixL9/ZRhV2VvKdr6Jr2jv1T/59CKyHvX9NqXjHYSxh95vf8t6LaDkqkKXx+kj Wj7A== X-Gm-Message-State: AOAM532LJQ6buj7YIc6AlaPAohSCGbQKe8evCTD40s0ZJYuJG15qMLoi LGthS+zhjBfSOLSlJSX0UNM82ba8 X-Google-Smtp-Source: ABdhPJxCYNtb5p4oYxf9KdVt/5taYFzlGn+/XLgqcMPRp/Tup+mWZ10k/7oJPMPupNmwbz2Vz0r50A== X-Received: by 2002:a37:a416:: with SMTP id n22mr6190740qke.49.1591846233327; Wed, 10 Jun 2020 20:30:33 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:32 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 07/10] vchan-socket-proxy: Switch data_loop() to take state Date: Wed, 10 Jun 2020 23:29:33 -0400 Message-Id: <20200611032936.350657-8-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Switch data_loop to take a pointer to vchan_proxy_state. No functional change. This removes a dead store to input_fd identified by Coverity. Signed-off-by: Jason Andryuk --- tools/libvchan/vchan-socket-proxy.c | 65 +++++++++++++++-------------- 1 file changed, 33 insertions(+), 32 deletions(-) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index a932c94c97..29a12260ed 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -286,13 +286,13 @@ static void discard_buffers(struct libxenvchan *ctrl) { } } -int data_loop(struct libxenvchan *ctrl, int input_fd, int output_fd) +int data_loop(struct vchan_proxy_state *state) { int ret; int libxenvchan_fd; int max_fd; - libxenvchan_fd = libxenvchan_fd_for_select(ctrl); + libxenvchan_fd = libxenvchan_fd_for_select(state->ctrl); for (;;) { fd_set rfds; fd_set wfds; @@ -300,15 +300,15 @@ int data_loop(struct libxenvchan *ctrl, int input_fd, int output_fd) FD_ZERO(&wfds); max_fd = -1; - if (input_fd != -1 && insiz != BUFSIZE) { - FD_SET(input_fd, &rfds); - if (input_fd > max_fd) - max_fd = input_fd; + if (state->input_fd != -1 && insiz != BUFSIZE) { + FD_SET(state->input_fd, &rfds); + if (state->input_fd > max_fd) + max_fd = state->input_fd; } - if (output_fd != -1 && outsiz) { - FD_SET(output_fd, &wfds); - if (output_fd > max_fd) - max_fd = output_fd; + if (state->output_fd != -1 && outsiz) { + FD_SET(state->output_fd, &wfds); + if (state->output_fd > max_fd) + max_fd = state->output_fd; } FD_SET(libxenvchan_fd, &rfds); if (libxenvchan_fd > max_fd) @@ -319,52 +319,53 @@ int data_loop(struct libxenvchan *ctrl, int input_fd, int output_fd) exit(1); } if (FD_ISSET(libxenvchan_fd, &rfds)) { - libxenvchan_wait(ctrl); - if (!libxenvchan_is_open(ctrl)) { + libxenvchan_wait(state->ctrl); + if (!libxenvchan_is_open(state->ctrl)) { if (verbose) fprintf(stderr, "vchan client disconnected\n"); while (outsiz) - socket_wr(output_fd); - close(output_fd); - close(input_fd); - discard_buffers(ctrl); + socket_wr(state->output_fd); + close(state->output_fd); + close(state->input_fd); + discard_buffers(state->ctrl); break; } - vchan_wr(ctrl); + vchan_wr(state->ctrl); } - if (FD_ISSET(input_fd, &rfds)) { - ret = read(input_fd, inbuf + insiz, BUFSIZE - insiz); + if (FD_ISSET(state->input_fd, &rfds)) { + ret = read(state->input_fd, inbuf + insiz, BUFSIZE - insiz); if (ret < 0 && errno != EAGAIN) exit(1); if (verbose) fprintf(stderr, "from-unix: %.*s\n", ret, inbuf + insiz); if (ret == 0) { /* EOF on socket, write everything in the buffer and close the - * input_fd socket */ + * state->input_fd socket */ while (insiz) { - vchan_wr(ctrl); - libxenvchan_wait(ctrl); + vchan_wr(state->ctrl); + libxenvchan_wait(state->ctrl); } - close(input_fd); - input_fd = -1; + close(state->input_fd); + state->input_fd = -1; /* TODO: maybe signal the vchan client somehow? */ break; } if (ret) insiz += ret; - vchan_wr(ctrl); + vchan_wr(state->ctrl); } - if (FD_ISSET(output_fd, &wfds)) - socket_wr(output_fd); - while (libxenvchan_data_ready(ctrl) && outsiz < BUFSIZE) { - ret = libxenvchan_read(ctrl, outbuf + outsiz, BUFSIZE - outsiz); + if (FD_ISSET(state->output_fd, &wfds)) + socket_wr(state->output_fd); + while (libxenvchan_data_ready(state->ctrl) && outsiz < BUFSIZE) { + ret = libxenvchan_read(state->ctrl, outbuf + outsiz, + BUFSIZE - outsiz); if (ret < 0) exit(1); if (verbose) fprintf(stderr, "from-vchan: %.*s\n", ret, outbuf + outsiz); outsiz += ret; - socket_wr(output_fd); + socket_wr(state->output_fd); } } return 0; @@ -481,7 +482,7 @@ int main(int argc, char **argv) ret = 1; break; } - if (data_loop(state.ctrl, state.input_fd, state.output_fd) != 0) + if (data_loop(&state) != 0) break; /* keep it running only when get UNIX socket path */ if (socket_path[0] != '/') @@ -504,7 +505,7 @@ int main(int argc, char **argv) ret = 1; break; } - if (data_loop(state.ctrl, state.input_fd, state.output_fd) != 0) + if (data_loop(&state) != 0) break; /* don't reconnect if output was stdout */ if (strcmp(socket_path, "-") == 0) -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:30:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:30:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvf-0008Dw-5z; Thu, 11 Jun 2020 03:30:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvd-0007xd-Sc for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:30:57 +0000 X-Inumbo-ID: e98808b4-ab93-11ea-bb8b-bc764e2007e4 Received: from mail-qk1-x743.google.com (unknown [2607:f8b0:4864:20::743]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e98808b4-ab93-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 03:30:35 +0000 (UTC) Received: by mail-qk1-x743.google.com with SMTP id l17so4334414qki.9 for ; Wed, 10 Jun 2020 20:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=jBbbs2empnWr4OrIOc7w1Xk6T14OGQN0B87vFfy4hdE=; b=eUweJLbDTdnBpX5SsoXJM2K72GHviq9XjGrlOwvQdhlGZgtM7K6IU/8iFa31ui8Uku R8vJOtPfanGzGUKPQeP3uBP2uQAFdwa4qLqRATFfQfiCpBuCvtTH2sYVrc9C2Ibx6xo8 fxaB+NQMiBkskXxATPZMz0bVZj/7G2nIIeRZnNvgQxG/2GYaZRe8SGCxLY5ne7E42iqN J5alV1dzQQeAge8bVtBdmBw5KVYIfgXZiCF87dKkOxUPQOTFXPLc79SI7pAFRhgEqtm2 2UYqHkgyRtp9TMuEnIAElZK2pkoyvWrhv4ZJJXXrF80PCYehydckhABoe/6LJMI/58dI /9wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=jBbbs2empnWr4OrIOc7w1Xk6T14OGQN0B87vFfy4hdE=; b=aIX0VGeh/2xY+KHIFGKD0zzRibkv91NFoZ1oafy3t/9ESYx9O6VSgPlC260Blyq5mX yeJ1Sn5W8R3MoaWXqpb2QhKv+hXQDyRX53BrzzONOzX69dDY9HAsBMgPieP3cTlxI1ae wA6XrVFdVTx8xTwW6GI0Mt0Tk3DHnqhHm5MvTSaDpN4h2OPO0DHg3/5Vn60Spoz/uszD BYzccuM3NEsTwQ92a0+7TA4QOsQ565R7z0kb2xymKRH8tKTQd56FmBk5rX44XCY+7EI2 bY9cZEZL5Vavx3Uuwq9BEDAEtSK2zhdxo0kRlmd6ye4GupwZXMuWj2Q+bVNKs50MT47t aSkw== X-Gm-Message-State: AOAM5307KM25A1ur7TZ0+bSIM8/wvtC7hw9NGqnc2hQ2+wDnIzHPHJR2 Bn+Zby0Wke0Bc09IlGHafiwK7m/D X-Google-Smtp-Source: ABdhPJyUgzppKig/FkUgRMJXAOFXdwdkz9Bo8jHpQNMRLt+rs6RiduerxyRzPMSEA+M3JN5rCx1C0g== X-Received: by 2002:ae9:e10f:: with SMTP id g15mr6616600qkm.285.1591846234982; Wed, 10 Jun 2020 20:30:34 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:34 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 08/10] vchan-socket-proxy: Set closed FDs to -1 Date: Wed, 10 Jun 2020 23:29:34 -0400 Message-Id: <20200611032936.350657-9-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" These FDs are closed, so set them to -1 so they are no longer valid. Signed-off-by: Jason Andryuk --- tools/libvchan/vchan-socket-proxy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index 29a12260ed..cd7629bc4e 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -326,7 +326,9 @@ int data_loop(struct vchan_proxy_state *state) while (outsiz) socket_wr(state->output_fd); close(state->output_fd); + state->output_fd = -1; close(state->input_fd); + state->input_fd = -1; discard_buffers(state->ctrl); break; } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:31:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:31:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvj-0008Hz-G7; Thu, 11 Jun 2020 03:31:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvi-0007xd-Sw for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:31:02 +0000 X-Inumbo-ID: eab8e834-ab93-11ea-bca7-bc764e2007e4 Received: from mail-qt1-x841.google.com (unknown [2607:f8b0:4864:20::841]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eab8e834-ab93-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 03:30:37 +0000 (UTC) Received: by mail-qt1-x841.google.com with SMTP id g18so3576001qtu.13 for ; Wed, 10 Jun 2020 20:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=tzm6Mh214muY5lx/rQlFhXvADj4YlPdVI5v2o4d8yuk=; b=f37z0AnH7+bYS0HKpYVntf0Qni0Aax6duvGiA3QSII8dzY4/Y72MpGqWpFnuFiS8gf vgtf+XD0TsYKzn4HeCrQVZet9wK5nHD98GARtJiz/irbBvdJsoAdDD3yx2uy45wqmS1O PHcZq5j8+xFBlp6Qkt/LgeoEoxJZvVbbKAKTCh+j6qr69rsY7zHvFT6PeBkq4JTJS7a1 j2ocbNDwhPGvqBSL1aRrdvXXH22qvWpSIF97vZOzHl6bCUDqqQ17V3VufgHItwBs2lQS Lx46+um3MJmmemuAifhN+PyjJHBFDBZ5WvT45MVle0ffY0gGwNpRuie8HhJkq3irStIZ LnZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=tzm6Mh214muY5lx/rQlFhXvADj4YlPdVI5v2o4d8yuk=; b=hZ2bLqrwSFihmh/Np2/D6+5QHto4+BIrIzOrzbRDfxkN+S2TbO2R3JtygRnS5W1JGx jG5ZV4/7QKJ5QT+UXS0jVh7SEjHYahxppIaYF9JjdYhLKsHvam9cAD1CYPmTD6inueCT zm6U26h1SK4jr+b3G+DVBt3WZCQ4KJMfFeF33P1AosHwgeWbMm3Xec62BCVwZ4skaYZY g40X41Bc9PXvKUHRk3cBpZOO2AXVFHWv9T03yfnmGmIbr3AvCEhHWD+7BbjezN2skhkK 5WfvKnOpvAgrDKSX+nvX8NVP4fMWKWVnZTGmD5E+6VkNpATaA3XnblisD8x55OK61mgE 85YA== X-Gm-Message-State: AOAM5304A45kITz6hvRl/u3R8fnY8zZV9JX6JIE8h0y6PQv1iqZUl8Yb yCDjNUV5NSrbpQJY1CJKq83Clb/X X-Google-Smtp-Source: ABdhPJxmdePJkrVa2BdhDezcmAvxku0TI6Mdn10/VkgQUT3queN0E8kb8S6GrS020z7e8W5WLa0n8w== X-Received: by 2002:ac8:7cd:: with SMTP id m13mr6539169qth.332.1591846236971; Wed, 10 Jun 2020 20:30:36 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:36 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 09/10] vchan-socket-proxy: Cleanup resources on exit Date: Wed, 10 Jun 2020 23:29:35 -0400 Message-Id: <20200611032936.350657-10-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Close open FDs and close th vchan connection when exiting the program. This addresses some Coverity findings about leaking file descriptors. Signed-off-by: Jason Andryuk --- tools/libvchan/vchan-socket-proxy.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index cd7629bc4e..3552783ec2 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -518,5 +518,14 @@ int main(int argc, char **argv) } } + if (state.output_fd >= 0) + close(state.output_fd); + if (state.input_fd >= 0) + close(state.input_fd); + if (state.ctrl) + libxenvchan_close(state.ctrl); + if (socket_fd >= 0) + close(socket_fd); + return ret; } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:36:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:36:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjE1E-0000Ys-5z; Thu, 11 Jun 2020 03:36:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjDvn-0007xd-T0 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:31:07 +0000 X-Inumbo-ID: ebcd4792-ab93-11ea-bca7-bc764e2007e4 Received: from mail-qt1-x843.google.com (unknown [2607:f8b0:4864:20::843]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ebcd4792-ab93-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 03:30:39 +0000 (UTC) Received: by mail-qt1-x843.google.com with SMTP id g62so3610368qtd.5 for ; Wed, 10 Jun 2020 20:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=khKs/ueL3SKxrTYIvshrhZXLqxoI5KFK9g9nhuvMTiw=; b=M48EJOMIzperQGLcjFAMzo6UJzx6vE/5utVAUhmsnb5gX/0yhT9UkQIc/2ewu5q7vu qG1JtDY8t4coEvAkbyiMff2EyUOd/qsb6bXPz1cDbtbzJRZ0woc0FxjunV3XgUdYMLp5 byeQw4/DhQrQKgOQ1sWB7kEmNQwacDmy7x6c5VCanLS9bjhcd9msTUilIWIf2vnlMJha uoAx7ggRaq4iPdA9wXn3d+JMh8OZzSqJKMvqamstebItR5lrKQaKQZ1LqgLajPbVrWh5 MqP9Y0NtPT+MLnqlMNbOrwVsNHM6MhnSauSruqBPvKnrbEbCEWXFCGh7WR0y0hykLn+T Q7gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=khKs/ueL3SKxrTYIvshrhZXLqxoI5KFK9g9nhuvMTiw=; b=mKi4c3LrZmw7jHAVRpQVfNdiAl5CghU6BJFtbG+89rIEN5hoYn4APSgG1vS9jdjL9F zgE3oT3n9nisOQJQ2F16AwNJF4Dt/By9cVv3Y+MPXmL4LAGADNuj0u4fsviwrDMz73YX x1DDdbPrY82TuSFq732OWJ2+RFVwgE4fVOPpEfPGWNjgY1IDc5B0uKHrC2aEtka2eKO5 KAgbNVWYxtuBWTiCOsoSj81zwO8MCIw4cqXwvwmbByzJsxWQavM4ey8D98LfxDQH9AtP t8rPZHQb3zw8i6erGGMkZX4TgZy03GaBZ39HTM5QL6HS0RWcE47nF6cZoMpFJmbnEY+d UT0A== X-Gm-Message-State: AOAM531ZWG6nJJAEur1KaXRZNgKhUauaDYfH7jzNx2YyMdUgqj9HPoBi RsK0P/zUg988PylZLvm4M24VfVLo X-Google-Smtp-Source: ABdhPJw8KtmXLensobiDVVb6TjPFlvpUQ+j3O+FqXc7Hj+hM6FWMuk/H1OsnljFEAFJkGcJ/Ig7d9w== X-Received: by 2002:ac8:7b4d:: with SMTP id m13mr6922467qtu.165.1591846238793; Wed, 10 Jun 2020 20:30:38 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id v3sm1164078qkh.130.2020.06.10.20.30.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:30:38 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH v2 10/10] vchan-socket-proxy: Handle closing shared input/output_fd Date: Wed, 10 Jun 2020 23:29:36 -0400 Message-Id: <20200611032936.350657-11-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" input_fd & output_fd may be the same FD. In that case, mark both as -1 when closing one. That avoids a dangling FD reference. Signed-off-by: Jason Andryuk --- tools/libvchan/vchan-socket-proxy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-socket-proxy.c index 3552783ec2..e1d959c6d1 100644 --- a/tools/libvchan/vchan-socket-proxy.c +++ b/tools/libvchan/vchan-socket-proxy.c @@ -349,6 +349,8 @@ int data_loop(struct vchan_proxy_state *state) libxenvchan_wait(state->ctrl); } close(state->input_fd); + if (state->input_fd == state->output_fd) + state->output_fd = -1; state->input_fd = -1; /* TODO: maybe signal the vchan client somehow? */ break; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 03:56:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 03:56:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjEKS-0002Qt-7V; Thu, 11 Jun 2020 03:56:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjEKQ-0002Ql-1N for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 03:56:34 +0000 X-Inumbo-ID: 8a34553a-ab97-11ea-bca7-bc764e2007e4 Received: from mail-qt1-x843.google.com (unknown [2607:f8b0:4864:20::843]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8a34553a-ab97-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 03:56:33 +0000 (UTC) Received: by mail-qt1-x843.google.com with SMTP id g18so3604126qtu.13 for ; Wed, 10 Jun 2020 20:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=OU+nObQIvnt6s+yMYrarv+yXbrDKSv9hdHPFd/1lbK0=; b=samdq/KNhZ5i1J43ZZi7oKVjiOkQmBKpTdoAvI2HjMqAJ7JWBanrjmbzwYvvGJbtY1 2fOqudRCcB0NLEPnXTXgYNekmI5WLkX3xO/tQDkEI5XUd4IaGooD42XslZgCj8H0grnD 7Jzcn8NG7R93cot7pmJ+TdMO5dEXXOMgvX9r5+1sxasO1TkMMjyeRVNx65hS4eAq/26x RLSzcgRTVgjKytWyGZ2P1y4e/1jJEErimzdI7G/L+mdiafImruaat3qgRZqIQOqaaIA3 htTP+Sz8iTSgoKSMQRyS807T78lR08ZS8UN7GS0EdPagwuZtlk1eEAE8+QMWQC9wj95r BRfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=OU+nObQIvnt6s+yMYrarv+yXbrDKSv9hdHPFd/1lbK0=; b=DwuV2asfdVrXPD8qZh5obfILFLCGuAZhKru2VNWE+FDjgpGHp3kdGYIsH0ByQQMblX 0ddItiXq5EfBtxnBpyEGO6QPzZyXwiOMPOzexyr6pEozItaO28KiNtM8zYDdtK6F69kj wkN45FIXl4FkEm8VkDSphX/g2ZkNCWr62BhvNNQerF25KCePRvwFloq5J37fVlqSRQvo EiHbFKBoZoP1ZsQh/W7v0qlKDK2P3yp2D4/rJecsN9a/fgSc1APLGr3bNDqlKcXKhbah wKlsdl1t9i+D+pG18HQcFIb1yBYl1KDaOj/6R22Uvvwxvp5ppRZEh9W/8086TV9cxqUa embQ== X-Gm-Message-State: AOAM5311yjwhFBx9SxKrAOfypdBQlpSzqWo2T7eu4zUEkKBWRDSWsTms iZ9Zl68VJusnGD1sRui9CpLujRk/ X-Google-Smtp-Source: ABdhPJz9OjgoZ50jbFCdOhp5uZWr2reTHpFlhMgYHG0o4i85ef6y14huRzVCWDDmdjoxIabDP0R6cA== X-Received: by 2002:ac8:3808:: with SMTP id q8mr7041438qtb.297.1591847792945; Wed, 10 Jun 2020 20:56:32 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:dd4d:2b5c:f471:f332]) by smtp.gmail.com with ESMTPSA id r77sm1281886qke.6.2020.06.10.20.56.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2020 20:56:32 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH] libacpi: Widen TPM detection Date: Wed, 10 Jun 2020 23:55:18 -0400 Message-Id: <20200611035518.379297-1-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Jan Beulich , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The hardcoded tpm_signature is too restrictive to detect many TPMs. For instance, it doesn't accept a QEMU emulated TPM (VID 0x1014 DID 0x0001). Make the TPM detection match that in rombios which accepts a wider range. With this change, the TPM's TCPA ACPI table is generated and the guest OS can automatically load the tpm_tis driver. It also allows seabios to detect and use the TPM. However, seabios skips some TPM initialization when running under Xen, so it will not populate any PCRs unless modified to run the initialization under Xen. Signed-off-by: Jason Andryuk --- tools/libacpi/build.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c index fa7d14e090..a61dd5583a 100644 --- a/tools/libacpi/build.c +++ b/tools/libacpi/build.c @@ -351,7 +351,6 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt, struct acpi_20_waet *waet; struct acpi_20_tcpa *tcpa; unsigned char *ssdt; - static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001}; void *lasa; /* MADT. */ @@ -413,9 +412,8 @@ static int construct_secondary_tables(struct acpi_ctxt *ctxt, /* TPM TCPA and SSDT. */ if ( (config->table_flags & ACPI_HAS_TCPA) && - (config->tis_hdr[0] == tis_signature[0]) && - (config->tis_hdr[1] == tis_signature[1]) && - (config->tis_hdr[2] == tis_signature[2]) ) + (config->tis_hdr[0] != 0 && config->tis_hdr[0] != 0xffff) && + (config->tis_hdr[1] != 0 && config->tis_hdr[1] != 0xffff) ) { ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_tpm), 16); if (!ssdt) return -1; -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 09:20:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 09:20:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjJNM-00043M-CS; Thu, 11 Jun 2020 09:19:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjJNL-00043H-6j for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 09:19:55 +0000 X-Inumbo-ID: b58da844-abc4-11ea-b4ee-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b58da844-abc4-11ea-b4ee-12813bfff9fa; Thu, 11 Jun 2020 09:19:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nJz1VcdGLh2g8j0Q+bDNeZ+f0arqBtAntt7a08ETv5k=; b=khQRHkvVbYXhhov6mkWuvCPHdN vxNiU1spb+QfFesVFguQLoB0IXwsS0KAANP86/xXGDAtrMhf7Dtvw7L5ouj3pMlh641j6qOl/RY19 LJnwmdv6i8y+/NT92gDF04mUH/WzGvvCJUXgaPkaPUI47ysrpUr/ZbKrihVLAwouUQvM=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjJNH-0008Rb-8Z; Thu, 11 Jun 2020 09:19:51 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjJNH-0002j4-1P; Thu, 11 Jun 2020 09:19:51 +0000 Subject: Re: [PATCH for-4.14] xen/hypfs: fix loglvl parameter setting To: Julien Grall , =?UTF-8?B?SsO8cmdlbiBHcm8=?= =?UTF-8?B?w58=?= , Paul Durrant References: <20200609154546.4531-1-jgross@suse.com> <4a3c4e5e-1fbd-5017-1e3e-64052ae2410a@xen.org> From: Julien Grall Message-ID: <1da8a9bd-b77a-86c0-5b6a-638ea94b2cbc@xen.org> Date: Thu, 11 Jun 2020 10:19:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10/06/2020 22:47, Julien Grall wrote: > On Wed, 10 Jun 2020 at 19:49, Jürgen Groß wrote: >> >> On 10.06.20 19:55, Julien Grall wrote: >>> Hi Juergen, >>> >>> On 09/06/2020 16:45, Juergen Gross wrote: >>>> Writing the runtime parameters loglvl or guest_loglvl omits setting the >>>> new length of the resulting parameter value. >>>> >>>> Reported-by: George Dunlap >>>> Signed-off-by: Juergen Gross >>> >>> Reviewed-by: Julien Grall >>> >>> Although one unrelated comment below. >>> >>>> --- >>>> xen/drivers/char/console.c | 19 +++++++++++++++---- >>>> 1 file changed, 15 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c >>>> index 56e24821b2..861ad53a8f 100644 >>>> --- a/xen/drivers/char/console.c >>>> +++ b/xen/drivers/char/console.c >>>> @@ -241,14 +241,25 @@ static int _parse_loglvl(const char *s, int >>>> *lower, int *upper, char *val) >>>> static int parse_loglvl(const char *s) >>>> { >>>> - return _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh, >>>> - xenlog_val); >>>> + int ret; >>>> + >>>> + ret = _parse_loglvl(s, &xenlog_lower_thresh, &xenlog_upper_thresh, >>>> + xenlog_val); >>>> + custom_runtime_set_var(param_2_parfs(parse_loglvl), xenlog_val); >>> >>> Mixing function and variable name is pretty confusing. It took me >>> sometimes to go through the macro maze to figure out what's happening. >>> >>> It might be worth thinking to document more the custom_runtime_* interface. >> >> I have already some streamlining ideas for 4.15. > > Cool! I will commit it tomorrow morning. Actually I am missing a Released-acked-by from Paul on this patch. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 11 10:26:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 10:26:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjKPb-0001LC-Gf; Thu, 11 Jun 2020 10:26:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjKPa-0001L6-2P for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 10:26:18 +0000 X-Inumbo-ID: faedf7dc-abcd-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id faedf7dc-abcd-11ea-8496-bc764e2007e4; Thu, 11 Jun 2020 10:26:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bZ7KtcUyBOXrIN/lwCD1Hm5rtkceEVRs9em+CjngUjU=; b=yXpEwa8igH6DXsQY9yGaOcYSb 9ojKgQ6aaRCDjiw8pTl3LC4LUpPaZ3RNx7xw2XPQDamJb4ZU3HmUY6LzRvx7BygXo7A+TfqJ6yizr 8ZdUHdr/aHuHQmiaSalec+J4VflM8TQwRBlnwasdIne71fOrJkshBH6pBwRo47iKgIEuA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjKPX-0001HK-9c; Thu, 11 Jun 2020 10:26:15 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjKPX-00070Z-1y; Thu, 11 Jun 2020 10:26:15 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjKPW-0003Xm-VV; Thu, 11 Jun 2020 10:26:14 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151016: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-armhf-armhf-xl-rtds:guest-start:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 X-Osstest-Versions-That: linux=abfbb29297c27e3f101f348dc9e467b0fe70f919 From: osstest service owner Date: Thu, 11 Jun 2020 10:26:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151016 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151016/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 150931 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150931 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150931 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150931 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150931 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150931 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150931 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150931 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150931 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 baseline version: linux abfbb29297c27e3f101f348dc9e467b0fe70f919 Last test of basis 150931 2020-06-09 00:40:27 Z 2 days Failing since 150945 2020-06-09 17:08:56 Z 1 days 2 attempts Testing same since 151016 2020-06-10 12:58:42 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Al Viro Alexander Potapenko Amir Goldstein Anders Roxell Andrei Vagin Andrew Morton Borislav Petkov Brian Cain Chao Yu Cheng Jian Chengguang Xu Christian Borntraeger Christoph Hellwig Christoph Lameter Colin Ian King Daeho Jeong Dan Carpenter Daniel Thompson Dave Botsch David Gow David Howells David S. Miller Dmitry Safonov Eric Biggers Eryu Guan Geert Uytterhoeven Greg Ungerer hyeongseok.kim Jaegeuk Kim Jason Yan Jeffle Xu Joe Perches John Johansen Josh Poimboeuf Julia Lawall Kees Cook Kirill Tkhai Konstantin Khlebnikov Linus Torvalds Lothar Rubusch Lubos Dolezel Luis Chamberlain Ma Feng Mark Brown Mark Gross Masami Hiramatsu Masayoshi Mizuma Maxim Patlasov Mel Gorman Michael Ellerman (powerpc) Michel Lespinasse Mike Rapoport Miklos Szeredi Namjae Jeon Neelima Krishnan Nikita Sobolev Nishad Kamdar Oleg Nesterov Pali Rohár Peter Zijlstra (Intel) Peter Zijlstra Rafael Aquini Rafael J. Wysocki Randy Dunlap Sahitya Tummala Sayali Lokhande Shuah Khan Stephen Rothwell Steven Rostedt (VMware) Steven Rostedt (VMware) Sungjong Seo Sven Schnelle Tetsuhiro Kohada Tetsuhiro Kohada Thomas Gleixner Tom Zanussi Vasily Averin Veronika Kabatova Vincenzo Frascino Vitor Massaru Iha Vivek Goyal youngjun YueHaibing Yuxuan Shui Zhihao Cheng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git abfbb29297c2..5b14671be58d 5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Thu Jun 11 11:52:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 11:52:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLkf-0000Cu-Rl; Thu, 11 Jun 2020 11:52:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLkd-0000CB-S6 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 11:52:07 +0000 X-Inumbo-ID: f9261914-abd9-11ea-b509-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f9261914-abd9-11ea-b509-12813bfff9fa; Thu, 11 Jun 2020 11:52:07 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: dDEC1pmsvKf7uyrBf7jK0HYgkq9fr62btkvQ1EKAdtjvXO20kvRD4/wEfjqGoECBjHg11vLwem v7te6OCNgczEwj6F/4TSbaEKgeebUlRpzIxUguWD2Np5o6J4pNe63CTyyIZNqGyWMSS7OyTWt4 egysWBFwbs9/dVJKi+yIHcr426rL+fZ3HycKMkItWO1DaLOeaXjjvTV+CAcAm6xh4FF7PORiUg 6oKWt0eTfa23Z4dlISJeHZxg6slMD+eHUaiortTdgyWyOShnD4TZvs8/i04mv5tZaU7SB4o7qU RdE= X-SBRS: 2.7 X-MesageID: 20124596 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,499,1583211600"; d="scan'208";a="20124596" Subject: Re: [PATCH] libacpi: Widen TPM detection To: Jason Andryuk , References: <20200611035518.379297-1-jandryuk@gmail.com> From: Andrew Cooper Message-ID: Date: Thu, 11 Jun 2020 12:52:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200611035518.379297-1-jandryuk@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Jan Beulich , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 11/06/2020 04:55, Jason Andryuk wrote: > The hardcoded tpm_signature is too restrictive to detect many TPMs. For > instance, it doesn't accept a QEMU emulated TPM (VID 0x1014 DID 0x0001). > Make the TPM detection match that in rombios which accepts a wider > range. > > With this change, the TPM's TCPA ACPI table is generated and the guest > OS can automatically load the tpm_tis driver. It also allows seabios to > detect and use the TPM. However, seabios skips some TPM initialization > when running under Xen, so it will not populate any PCRs unless modified > to run the initialization under Xen. > > Signed-off-by: Jason Andryuk Reviewed-by: Andrew Cooper This looks like it wants backporting, so CC'ing Paul for a 4.14 release ack. From xen-devel-bounces@lists.xenproject.org Thu Jun 11 11:54:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 11:54:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLnC-0000L8-9m; Thu, 11 Jun 2020 11:54:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLnB-0000L2-M3 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 11:54:45 +0000 X-Inumbo-ID: 574b3416-abda-11ea-b509-12813bfff9fa Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.76]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 574b3416-abda-11ea-b509-12813bfff9fa; Thu, 11 Jun 2020 11:54:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TZ2ChDTNRET6s9KJ+UND5sMicc5rHbMBhQiA5d/sSak=; b=4DRD2HNnIvku7agDZuF/A1VzStnirN5IxuHR6OUa9i08MdBZHTh2X/3fTzpOexhDHDTc0dze5X4p1SC9tEl/y4FazrREKUO8a8mPz4XbUoZ8VAGr3L1s0df8rwbNpMrQAUIXLWFq0XhCEUF+UmtdzLKI/0/cen8uBnzpnduEOAk= Received: from AM6P194CA0095.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:8f::36) by DB6PR0802MB2215.eurprd08.prod.outlook.com (2603:10a6:4:86::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Thu, 11 Jun 2020 11:54:43 +0000 Received: from VE1EUR03FT040.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8f:cafe::5a) by AM6P194CA0095.outlook.office365.com (2603:10a6:209:8f::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 11:54:42 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT040.mail.protection.outlook.com (10.152.18.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 11:54:42 +0000 Received: ("Tessian outbound 56dbe829191e:v59"); Thu, 11 Jun 2020 11:54:42 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: a1c8ba8c26184782 X-CR-MTA-TID: 64aa7808 Received: from 948674cc2d29.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 812D42BC-0F96-44E7-8A5F-4BA69DBA2F56.1; Thu, 11 Jun 2020 11:54:36 +0000 Received: from EUR02-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 948674cc2d29.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 11 Jun 2020 11:54:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZQMYAGiyMHhW8SK1wBZYxHqt5qsvcZftngtz7doD3GWJubVXbqr3pqK198VfzeU8lY52MTC011rlqDu/LKDIzNhsZHU2jTL23gu+T+zVWMnycPZ4FuDHz34nIbzGaZ4F68HkTNek4d3OlUKSDHk0qAyo/oUZ17zPCz45HTvYZPFv7NFzAgyFmU9jXuC7SXpW3FUT3vAdow2HDZ2j/b91zbwO+b0+Sibr+AzaJXP0B6UfkscMnBkjOLZVONCjDU2qQF/ZXQ3HfAP6C3d1H+To8v31lSuYaY1idBuKqUO3qc/SJKUz93s6VVk2lbf8ovV06n8t9o7Iu5Bdghv1aYHzMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TZ2ChDTNRET6s9KJ+UND5sMicc5rHbMBhQiA5d/sSak=; b=dWDT/rIkSaC4YAuGezi8qy2hFMF0I2TbSrI0NxCM0jGr1M2PDvZ+hUxn+kOzLHukQzj0OJ291VWk7KdU1SLi0Bz+BaBErNbL+/UIhdTS/N8CRDxlFEHpj/dAF2qg+3Kater/mDXAaH1G7DCxW4M03PN14CKL4LmIcmo3P/MgoXTo4K/CmKhQT4NsK3rHwq+PY68T2OblB8Ya5Zsv5NhnnIKZBfRnP91TanngOkkY5V5rmJehI3keHTqpLjDyf82L2z+ApTtaJknvJM6eUUyqjdHsWfGbm102Kf1G8HRlzkZt1/OxwDrJD5V9PQwCrV0H7o83UC4eTWmA6YHu+Nxl+g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TZ2ChDTNRET6s9KJ+UND5sMicc5rHbMBhQiA5d/sSak=; b=4DRD2HNnIvku7agDZuF/A1VzStnirN5IxuHR6OUa9i08MdBZHTh2X/3fTzpOexhDHDTc0dze5X4p1SC9tEl/y4FazrREKUO8a8mPz4XbUoZ8VAGr3L1s0df8rwbNpMrQAUIXLWFq0XhCEUF+UmtdzLKI/0/cen8uBnzpnduEOAk= Authentication-Results-Original: lists.xenproject.org; dkim=none (message not signed) header.d=none; lists.xenproject.org; dmarc=none action=none header.from=arm.com; Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7SPR01MB5.eurprd08.prod.outlook.com (2603:10a6:5:12::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Thu, 11 Jun 2020 11:54:34 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Thu, 11 Jun 2020 11:54:34 +0000 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Subject: [PATCH] x86/boot: use BASEDIR for include path Date: Thu, 11 Jun 2020 12:54:14 +0100 Message-Id: X-Mailer: git-send-email 2.17.1 Content-Type: text/plain X-ClientProxiedBy: SN6PR08CA0019.namprd08.prod.outlook.com (2603:10b6:805:66::32) To DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from e109506-lin.cambridge.arm.com (217.140.106.51) by SN6PR08CA0019.namprd08.prod.outlook.com (2603:10b6:805:66::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21 via Frontend Transport; Thu, 11 Jun 2020 11:54:32 +0000 X-Mailer: git-send-email 2.17.1 X-Originating-IP: [217.140.106.51] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 7a8c6960-879b-4583-35c2-08d80dfe3a82 X-MS-TrafficTypeDiagnostic: DB7SPR01MB5:|DB6PR0802MB2215: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:2201;OLM:2201; X-Forefront-PRVS: 0431F981D8 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: EnlSHrmHudPfgmsk2qQVjFmnYYpYbTDi2kCZcbU6yAMAjAlqJpECRYrL1W3QRUfdrHCg/BZ73V54lVN1pdJTyU66cLNSX+w3yFz7CuznlarVwujhFGvA5W9k/n36W0eiBEx0iZj2ZGsOMXuy2STu28iwSmlBmgwfom6nVpxtD1JPe0nOh3hh8JO2jEINi/2nJCwwcS1YKMq0zSyO3qxeMEKo75EPFYz/gHLnE5eMZB5dVDqIUzDSV9x28CDcm3fnJyjAyuf8ryWmqnI8o2MWchL8hSAZY4vtACFWlDNbHcxKwN1oFeXKq3AJ+iStVGKcb7uvt1SjxBvZ50qu1WOiPsNOIOJUR1QyM8aFfTNc2OyHENZK6BjNRybXxwzsm+JH X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(346002)(39860400002)(136003)(396003)(83380400001)(4744005)(6486002)(36756003)(8676002)(5660300002)(8936002)(44832011)(4326008)(2616005)(186003)(54906003)(6666004)(2906002)(316002)(478600001)(956004)(66946007)(16526019)(86362001)(66556008)(6916009)(26005)(66476007)(7696005)(52116002)(136400200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: cZD1cuUdd9EaQmRe9kKiuWa9GdeOcq4aBEMm/SvLbavtaXEX969XInr3K7WLAnknohkDyVrSm2TI1r7zNdm+KX4NjI1eD7Jrl3Tl4L7nv32TxLr4ECt0BPmZzxt7vrqfEqCUOlrQD0pO9x+hiaO4rwV34vEbi9nmycery/m+z6S3caa35qHyg37yb9Gib4k5b5ZOC4nduPnek+jklpHsskTPitgd6b+bFGEYZD/jPUUkdxJDarkCg3z7k0tkvuAQwssZ8fYoYtf2RbMvkWOBnX7ityZUMbjWxJx6L1YhOUEgjmtI5u0IUXT85S4fq2xqWDWeyz89OCUN7MBYXMVaZsU1Ssg4HJydncy2RcjubTqX7IpkSHDEV4EtDabZS3M8zZV8s1hVH5RZ2cI1GpypegUgs/I8YhH9M0ZIGP2ZgaDmrQCYsM306ZDMmDSgsYqzvYzDfuD/8fDXJbPd7FkGrJun5cMV4RRcTEv/DZhZum2VpZCUECMNNfA7588VSCEs X-MS-Exchange-Transport-Forked: True X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7SPR01MB5 Original-Authentication-Results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT040.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(136003)(39860400002)(376002)(46966005)(82740400003)(316002)(4326008)(82310400002)(47076004)(6486002)(4744005)(8936002)(2616005)(44832011)(956004)(336012)(86362001)(54906003)(26005)(6666004)(186003)(5660300002)(81166007)(8676002)(70206006)(36906005)(356005)(16526019)(2906002)(107886003)(36756003)(83380400001)(6916009)(478600001)(7696005)(70586007)(136400200001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 9de26957-d966-4a92-f91a-08d80dfe3594 X-Forefront-PRVS: 0431F981D8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: gFO35f5Zc02mgGaI4gpVMkXAoECClB2HghzfTZw/xs0uuaA2lg4chIpqOplvYVCQ/sPpqrqKQi9qS6HfjkzpAt9qwrU78vi9x3h+md4PJw4PhfT53ZOp7X67+Rt521lEtk6lk9eh3FNVME/Z4kaBCjT4qPNzDc3dmrPzjiH15ANXhGaQn6PmcHOxoaQ1l6qYRF2iS2nqyrd0SPv/X2fKeDfwrG075FXnINWPsTyonqvyETHONoqNEiE2SGXDhnB3v6y2R/85Gh/LZUI+k95Ye+C+Trpr6XjDoY1PJU/EeA51YVV1773D0XSzRaf36CadVG0C715nGTCdV4mVgMRfNV7Afa6eygsQoEp3Kjj51yKj9qo4CaZGFc5hVfX9NPwgvOf1i36rl8Sb8QNaxh/4CQ0iidgpYX4DwKF4s5K7hY8VIIsngSoMYeKUM/V+BxYM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2020 11:54:42.6178 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7a8c6960-879b-4583-35c2-08d80dfe3a82 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2215 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , nd@arm.com, Wei Liu , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Use $(BASEDIR)/include instead of $(XEN_ROOT)/xen/include for the include path to be coherent with the rest of the Makefiles. Signed-off-by: Bertrand Marquis --- xen/arch/x86/boot/build32.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk index 5851ebff5f..8cd5403926 100644 --- a/xen/arch/x86/boot/build32.mk +++ b/xen/arch/x86/boot/build32.mk @@ -5,7 +5,7 @@ include $(XEN_ROOT)/Config.mk $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) CFLAGS += -Werror -fno-builtin -g0 -msoft-float -CFLAGS += -I$(XEN_ROOT)/xen/include +CFLAGS += -I$(BASEDIR)/include CFLAGS := $(filter-out -flto,$(CFLAGS)) # NB. awk invocation is a portable alternative to 'head -n -1' -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 11:55:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 11:55:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLnh-0000Os-Nb; Thu, 11 Jun 2020 11:55:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLng-0000Oh-Lp for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 11:55:16 +0000 X-Inumbo-ID: 69f0bd8e-abda-11ea-b50b-12813bfff9fa Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.46]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 69f0bd8e-abda-11ea-b50b-12813bfff9fa; Thu, 11 Jun 2020 11:55:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mN0ESUHA9bGBuQJ/n5WIUk8FCzXe8w4C0qhno0Uz0bs=; b=BwDoWKZxyY7nwbKxJKhXoWJJrrSPXTqWPDDsbMlFVRUSqTebn5AEdtCU93zlt1v6X4qqLXSFV+swo5QMqLEXlJqLGN3RT6sRatBjAbhi+kccf6CPhVFo5w9z3QAL967YGvh7BsOrq/d7ZvC/V1iuceaFaj+IvRVxkjJ8KwwSoPQ= Received: from DB6PR07CA0001.eurprd07.prod.outlook.com (2603:10a6:6:2d::11) by AM0PR08MB4114.eurprd08.prod.outlook.com (2603:10a6:208:132::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 11 Jun 2020 11:55:14 +0000 Received: from DB5EUR03FT030.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:2d:cafe::2d) by DB6PR07CA0001.outlook.office365.com (2603:10a6:6:2d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10 via Frontend Transport; Thu, 11 Jun 2020 11:55:14 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT030.mail.protection.outlook.com (10.152.20.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 11:55:14 +0000 Received: ("Tessian outbound 39cdd740f5cb:v59"); Thu, 11 Jun 2020 11:55:14 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: b7cc936da58a66bb X-CR-MTA-TID: 64aa7808 Received: from be19d5ddf299.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7275799E-FBB8-4101-B1EB-CB4F30CECDCE.1; Thu, 11 Jun 2020 11:55:08 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id be19d5ddf299.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 11 Jun 2020 11:55:08 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N6oAAnQWbPAq0XVtE9SEnTPo5iLIIHDw9ehFawy0eEn/CKYs2rLq8zfaKz68QsekAJlTo3TotpyieS1HYI2aEVpFFgCmWVsQxhGKV4HjbXUwaCHnWxn9CMnft6p5BfRp6qv6ddly53VT4AcqQwzMsOp8i1/dZlufISd1WsrUmGCOfySuGX+sMYZFtB9aDw6jUDXssLH7pvCz30Ozw3fBZaxSjB/h5iTwdWu+q/8KlO1yO0vLXFg1y9g0nB8omX/VBPZnpI/UGCvDc4Dy0sGY8nESSpMpV22+A0FjI27RoJjwBwtwUyNiaDMRyN8yvzvk5n15tvLwr+KAio8srhvXug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mN0ESUHA9bGBuQJ/n5WIUk8FCzXe8w4C0qhno0Uz0bs=; b=QGiLlwP8gtli+RcFB3sAfaZWyUqJu/f25LlfK998CTEz7iJj6EWu3t3edn+1cqENRa83g7HlcojPCrS92+moLPE2J9YYQwi2tWqoU+g3MqzaprLjoaakksoigaZFsl5tlGwAm/WiaUtS4QcNqSjW4McIYRxF5ANYN/YKuiA7CQx0xUVbJCmCGZzI63AfXmK3dMEi9HDAgtGvEaS4AbisyyWGJ2B6WOFi/zLlwECr25CdtksMpKpTHokKErqi+UCt2LxXsaDWCJsMJSdvDQ09YGsrZfVRAcRSD7OCjL+BDWXZQZwy8MeCWUaYCdaqW89D55pzTDllxz0VPw0KCEWrsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mN0ESUHA9bGBuQJ/n5WIUk8FCzXe8w4C0qhno0Uz0bs=; b=BwDoWKZxyY7nwbKxJKhXoWJJrrSPXTqWPDDsbMlFVRUSqTebn5AEdtCU93zlt1v6X4qqLXSFV+swo5QMqLEXlJqLGN3RT6sRatBjAbhi+kccf6CPhVFo5w9z3QAL967YGvh7BsOrq/d7ZvC/V1iuceaFaj+IvRVxkjJ8KwwSoPQ= Authentication-Results-Original: lists.xenproject.org; dkim=none (message not signed) header.d=none; lists.xenproject.org; dmarc=none action=none header.from=arm.com; Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3707.eurprd08.prod.outlook.com (2603:10a6:10:76::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Thu, 11 Jun 2020 11:55:07 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Thu, 11 Jun 2020 11:55:07 +0000 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Subject: [PATCH] xen/arm: Add arm Neoverse N1 processor Date: Thu, 11 Jun 2020 12:54:51 +0100 Message-Id: <5d99ae7a1432152e25d063c634e1e7292ab988aa.1591806668.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.17.1 Content-Type: text/plain X-ClientProxiedBy: DM5PR21CA0053.namprd21.prod.outlook.com (2603:10b6:3:129::15) To DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from e109506-lin.cambridge.arm.com (217.140.106.54) by DM5PR21CA0053.namprd21.prod.outlook.com (2603:10b6:3:129::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.0 via Frontend Transport; Thu, 11 Jun 2020 11:55:05 +0000 X-Mailer: git-send-email 2.17.1 X-Originating-IP: [217.140.106.54] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e7f51b4b-81b1-4bbf-d411-08d80dfe4d30 X-MS-TrafficTypeDiagnostic: DB7PR08MB3707:|AM0PR08MB4114: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:439;OLM:439; X-Forefront-PRVS: 0431F981D8 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 4Ll7mpJmZQ/3bCsTGpjqwASC4dFhgsiPiPyGwZhEcC79YJJe4qSbhsWF5nruN1oW0GEdSGAQ6QEKLHnudA0nRwYaZqtsXYhTEBYNMkLYB/d9gprJ8sF0OnjKD/pDQD5Y0+uyv1jpwv7V+5fxjUJgpHLi44f0rt5jb+KjELB5uuBisUl4DL7G10UxXhyqKFR1azMb39OxAHdaX6bn5j7PMYTqYHZkWX8cwWvW+Pwu+81/ukvMktDJn7XjycciheDRqKxa177q4Cf7CELJ0tExGu3sKnoMNvTRM5jLAj6/Sy2WGuBHntx3PsHlYPse7ig1NVRVM3jaMKrXS/vecwJ59nOJpmBnDT3qrElajRqVnNXqo9VUaQGgNGFqlEhUD2SZ X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(396003)(39860400002)(366004)(346002)(6916009)(54906003)(4326008)(86362001)(44832011)(26005)(8936002)(316002)(6666004)(36756003)(5660300002)(6486002)(7696005)(8676002)(2616005)(66556008)(16526019)(186003)(52116002)(66476007)(478600001)(956004)(66946007)(2906002)(136400200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: l2EN3hr87/H8kI2pNxaV2ZbB4fYmzgxFNsCezSEHM4LnXqsHbDqm4WsLAb4LCvKVsI0GxXY9v1EnR5HaiJXzm1gfNSLpCVwCWUbVq0VvRmoByc+oAGYJyr3pzZFtCVj3tVXXeuUeVp0MKES+MVmRF/xRvl2BFoEiP7Vqylj1epmVZ0zzCG0YQkMpRZCH6w8B1nv1kFjYLotZJoWbVT7M1rOJVu+jRp2yp14ykTaTw2YKuz4xVa3ahEtxm+8ihs3dy0qXI7BJPYEdDlnmcSTtI935THbBS51onyXo5gFw8BJ0TG44OAYcyJZZCFwQmeJP+fOxq19kGD6xkAwF8z8V+DgRYhfMX/OL+BkSn97Ht3e5L+tRMlog6089poElS0GhKqgIfDYtENvsnvpqa5QjAVRfWeSzXTiN7naiMGERq/TqLdgyiq3vk04IpxP49BzxOTlIg3ehFSmAqbKCgWREB0hz8XZr8r4SYztg/w9Yx2EEgQDroWepHRoxXaAnzanc X-MS-Exchange-Transport-Forked: True X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3707 Original-Authentication-Results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT030.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(39860400002)(396003)(346002)(46966005)(8936002)(36756003)(82310400002)(336012)(7696005)(16526019)(356005)(6666004)(316002)(70206006)(4326008)(2906002)(44832011)(54906003)(5660300002)(186003)(81166007)(70586007)(86362001)(6916009)(8676002)(956004)(82740400003)(26005)(478600001)(6486002)(2616005)(47076004)(107886003)(136400200001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 5c1c2266-bf6f-45ea-7e71-08d80dfe48e9 X-Forefront-PRVS: 0431F981D8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YiQoCXNLYZGstEZ9SmgHuKRidtsogRD8BZwCV3zGqQQ/EqfdrI4BZv9rogyVEg9l1Fs73n/UEXJjv9qmRYeGWm79zUmVuaa8iGWmAh1NX4P0QCt/qWL36l+dQxz9qffAQjpgGZYRHIFDYAEW+6BwNbpcZkk9T0QsPG5z6O5ua2aLBEeWTgFDy1CwRmraEU2fWY+uXIAYiWxVZuh+E2i7eqmtbv7snd7Yvo/Ws2Pxhfbolr6ZusvzKd3b1WR+t8JJvXa7l+0caSrLgFBNoRYC4BLgXOuGBpeM7lzOfBrvy7tzjXlplFg+UMgW+gpZTQnnmQx+98DQE+71zrzfPBc3AML2eR6V1h26AALY9mmth05WwfszCTmbId7EqYHzm/bGTnUS2nDzXcP/s8auE1vS4F11f6RUcUMbbh0yQNdJ7SAGzUqj63vFroW+oRj+n4sh X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2020 11:55:14.0755 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e7f51b4b-81b1-4bbf-d411-08d80dfe4d30 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4114 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Volodymyr Babchuk , nd@arm.com, Julien Grall , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add MIDR and CPU part numbers for Arm Neoverse N1 processor Signed-off-by: Bertrand Marquis --- xen/include/asm-arm/processor.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h index aa642e3ab2..3ca67f8157 100644 --- a/xen/include/asm-arm/processor.h +++ b/xen/include/asm-arm/processor.h @@ -58,6 +58,7 @@ #define ARM_CPU_PART_CORTEX_A73 0xD09 #define ARM_CPU_PART_CORTEX_A75 0xD0A #define ARM_CPU_PART_CORTEX_A76 0xD0B +#define ARM_CPU_PART_NEOVERSE_N1 0xD0C #define MIDR_CORTEX_A12 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A12) #define MIDR_CORTEX_A17 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A17) @@ -68,6 +69,7 @@ #define MIDR_CORTEX_A73 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A73) #define MIDR_CORTEX_A75 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A75) #define MIDR_CORTEX_A76 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A76) +#define MIDR_NEOVERSE_N1 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N1) /* MPIDR Multiprocessor Affinity Register */ #define _MPIDR_UP (30) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 11:59:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 11:59:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLrR-0000eH-8o; Thu, 11 Jun 2020 11:59:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLrP-0000dl-PK for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 11:59:07 +0000 X-Inumbo-ID: f335c8aa-abda-11ea-bb8b-bc764e2007e4 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (unknown [40.107.1.53]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f335c8aa-abda-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 11:59:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D71s0T/Tl8igW2rP4gqzsvEUPhyc07Mh5DOpvYbwWYM=; b=AA0/jo6dVDqbcXZ6Zgb6kLHov3EJZuY1JTC27ww8iLov4YDBJ405941Lp+PifS3ncLf7gBzHUHn2lgi7vC7Dj6OniM5p0Zow1fsACoEr92tZlodcWQzw+25k6UMo8lWSY3Mg107z7aEEBkUlQtROYroTIXszqTxU1UctV86Lr4A= Received: from AM5P194CA0003.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::13) by VI1PR08MB3023.eurprd08.prod.outlook.com (2603:10a6:803:4e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.19; Thu, 11 Jun 2020 11:59:04 +0000 Received: from VE1EUR03FT009.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:8f:cafe::2d) by AM5P194CA0003.outlook.office365.com (2603:10a6:203:8f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 11:59:04 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT009.mail.protection.outlook.com (10.152.18.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 11:59:04 +0000 Received: ("Tessian outbound 3e82c366635e:v59"); Thu, 11 Jun 2020 11:59:03 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d1ef58a267a01458 X-CR-MTA-TID: 64aa7808 Received: from 423a97113ec8.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 85CF8D81-6F59-4500-9932-2BC025A901A9.1; Thu, 11 Jun 2020 11:58:57 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 423a97113ec8.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 11 Jun 2020 11:58:57 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AksEIz08AH8H2w9lq8/zfMdyWEZoetnhhLYXvEtSCPedqxA3UZctTQwz1v5n7/EpcSnS4huOL5gzUEwYDXc9YJHQiXZVlMhtRuVbBok9x1uYVfWwttO1gTvDJgxUlFLRZdXnRmonlN+FWVYtIKeTAii3u0eTazK3ohfTFqFefkNgOHWp6D/Yc6MhjgCHeVaM0ztPA4BRxHzHpQqxVkMbJWrIZ1aKT+J1qfjAxk9srI+c7P/9P/D18TodDjFreTP3yQ6OBXnljhbxkuzazt5qGiWO9H1TVNJ//Z83gghaf56ehqU+6a/cGmquKY4f48UUInc3JEzSiL76xr6r9+ZmFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D71s0T/Tl8igW2rP4gqzsvEUPhyc07Mh5DOpvYbwWYM=; b=Cgm/d4FAxgkIK6FO30elEz2p/FfRQbAwzscoh8sp+svJXF3bM0G7S377yg51rtjFn2Mc5vsE5x8Q823lvi2sVT3BnqBrnj2m4vZla/q5CYWqfZHHXExxDctDrJ7kyPniNOL9iHhWYZxDs3lf315uphsc/l6zo8E2MKx55hWOm7LeYY6hHM8x0c9pCYQH+TKPJJAxkk2L9oV1qKciDlQRgZyOlxOnmLr8Nqh8WQIHZlrMtTjs6vJ1CI5I36XrbflpSAErHDuD/ENFPNJCOpcfgYwQs3e5gEsQEbafEXM5LKiAFfDTFyJvLDc+QRSM22+jgYTdPjhgndpkQjzLPt99rg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D71s0T/Tl8igW2rP4gqzsvEUPhyc07Mh5DOpvYbwWYM=; b=AA0/jo6dVDqbcXZ6Zgb6kLHov3EJZuY1JTC27ww8iLov4YDBJ405941Lp+PifS3ncLf7gBzHUHn2lgi7vC7Dj6OniM5p0Zow1fsACoEr92tZlodcWQzw+25k6UMo8lWSY3Mg107z7aEEBkUlQtROYroTIXszqTxU1UctV86Lr4A= Authentication-Results-Original: lists.xenproject.org; dkim=none (message not signed) header.d=none; lists.xenproject.org; dmarc=none action=none header.from=arm.com; Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3387.eurprd08.prod.outlook.com (2603:10a6:10:45::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 11 Jun 2020 11:58:56 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Thu, 11 Jun 2020 11:58:56 +0000 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Subject: [PATCH 0/2] xen/arm: Convert runstate address during hypcall Date: Thu, 11 Jun 2020 12:58:19 +0100 Message-Id: X-Mailer: git-send-email 2.17.1 Content-Type: text/plain X-ClientProxiedBy: SN6PR2101CA0008.namprd21.prod.outlook.com (2603:10b6:805:106::18) To DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from e109506-lin.cambridge.arm.com (217.140.106.51) by SN6PR2101CA0008.namprd21.prod.outlook.com (2603:10b6:805:106::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.0 via Frontend Transport; Thu, 11 Jun 2020 11:58:53 +0000 X-Mailer: git-send-email 2.17.1 X-Originating-IP: [217.140.106.51] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 394d73d0-a7a7-43b5-fa28-08d80dfed652 X-MS-TrafficTypeDiagnostic: DB7PR08MB3387:|VI1PR08MB3023: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:7219;OLM:7219; X-Forefront-PRVS: 0431F981D8 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: BaUlJctEk8+HTyGSZ6CaZ0AlwSmUclD92s9kqlpTDqSavLrl9JtPXy5x62OSCroHQip/l+4BmNe7EoMIVvDbb+oYVIOhGuvXiKVsHpkUzH8Q2UP5iB2OjOyQO3mXzdxcWP2LukyQ3nV5V/qJFnvTYN4/OoDotvZir9M/ox+MQSG3H5xYZlQ7nJTOXjhWfiNqSIBuQgvQ8hzO9HBQxnRsoXLmXxGv60QV/MversBtdguX4jEV6lxhHcA9mfsp4D7avfC0AuucKEjsqpO9kqHTJYXBwJ/VEa2qNxqHHJW4JU94t0q3Op6aJvZV+QenjbiANCJh+uDe6Yfq64lgej0tFmMU81FR/sgg96VgLZs67FwR6viTIWXuMMX1XNEHCWqH X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(136003)(376002)(346002)(66476007)(6486002)(66946007)(86362001)(5660300002)(16526019)(36756003)(6666004)(7416002)(186003)(4326008)(2906002)(4744005)(26005)(83380400001)(66556008)(8676002)(956004)(6916009)(54906003)(8936002)(52116002)(2616005)(7696005)(316002)(44832011)(478600001)(136400200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: oCgdadJncviDXfQKWhWu8uh9aBHbhf0Ub/MnIO4dEuaPQixjdW1veMyUvJfrAu+6VZy4/K0QC/M5nXCmicN2khxDkCbzOh95mu7jHm1gAIffCsLAqx8iX0I5J5HkJOkgZAYV4rjLhe0GhcsnahF1sb6mZD5bIW9kEE7xgIdHvx6VmGo5bJ2Zj61gI6pOrcCn1e8huJyH5de60PrmOHIPfwc2zYxryxJQcyfJl9F5lD4T156ic8vM1sRFI4JzoTNKpsG8YjQi5PjJxgSwLqQxayezJOGU71d8rZsq1EN7KRYu+JZ5fQUc6n0CLl6ToRMA9DIb+NTeGGYxAaG6kd5082WR5GH1s0xZsrA+zjgOI5XXTDKCHAV5KwDH2qiL/eqPiE/KSPCJCFgR3Exm60AVYPQTqKX87HNEyDRTbKb2ZF2DSO5erk0EXmEjvvludkH/OflgOAM/+JfzP8PEwUXNdGjEnysUZ0sGG1QZD7OmlM3iFgxdwJBon1OOlC0UJIHM X-MS-Exchange-Transport-Forked: True X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3387 Original-Authentication-Results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT009.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(136003)(376002)(46966005)(336012)(54906003)(478600001)(316002)(356005)(107886003)(83380400001)(956004)(82310400002)(7696005)(6486002)(44832011)(2616005)(36906005)(81166007)(4744005)(8936002)(4326008)(8676002)(36756003)(2906002)(86362001)(5660300002)(70206006)(6916009)(70586007)(16526019)(186003)(26005)(6666004)(47076004)(82740400003)(136400200001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: c61e6fd4-a110-4a54-8b66-08d80dfed16b X-Forefront-PRVS: 0431F981D8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hT9kP9j/YFLEm8ospivXTM/ORYE6MhnbUG33O759teeM6nCv3yIyhXK3+fESOrpteumcmbrfmz0tesqvQkqBnGpcgyW+z85LaatPdAOoDeXOkxocO53PWQc/tcooqQL+7MT3/rYXH9nJ4oytZ+mE7RZfnXlYPh22nYABfh2oFJIoBieWqUNJcXF1hR+dSSZwftmEQoqZ7kOJsyMDVgO2Z1EbSQGbEN/9Yb49yEWrWPpGWAcjdJZOwmKeV+2wAcFVT+b8TUhYHKhlL0cLVCX4dVeceSuDzhbu4EUNAB1NIFyEsAT4bsUrHp6HVCTEAQSfiqG/a0Xo8jO2I9FQN4WyFzK+cFxj1l8sTxGx/NBDx4GXiSZcoFgZMbBh3j+jxGxkEMuxSVv4FoH1gSVNCs23GL+zh450EYRz8hrlrLOHqCJYHNAlRhVqIKB+7/UWuq/Y X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2020 11:59:04.0402 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 394d73d0-a7a7-43b5-fa28-08d80dfed652 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3023 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , nd@arm.com, Volodymyr Babchuk , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This serie is introducing changes to convert runstate address virtual address provided by a guest during the hypercall on Arm. It keeps the current strategy on x86 but moves some of the common code inside the architecture code. The serie is divided in 2 patches to allow an easier review of the specific code to handle the use case where the guest area is actually crossing 2 pages. Bertrand Marquis (2): xen/arm: Convert runstate address during hypcall xen/arm: Support runstate crossing pages xen/arch/arm/domain.c | 154 ++++++++++++++++++++++++++++++----- xen/arch/x86/domain.c | 30 ++++++- xen/arch/x86/x86_64/domain.c | 4 +- xen/common/domain.c | 19 ++--- xen/include/asm-arm/domain.h | 9 ++ xen/include/asm-x86/domain.h | 16 ++++ xen/include/xen/domain.h | 4 + xen/include/xen/sched.h | 16 +--- 8 files changed, 199 insertions(+), 53 deletions(-) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 11:59:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 11:59:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLrb-0000f9-H0; Thu, 11 Jun 2020 11:59:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLrZ-0000ev-I5 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 11:59:17 +0000 X-Inumbo-ID: f914cde8-abda-11ea-bb8b-bc764e2007e4 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe05::600]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f914cde8-abda-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 11:59:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q9LeQAfhC/BKsL2smIOUvgONsIexEg/IAzNAQ+yxpOo=; b=Gc1RME7v0RCufZPS0A2ygCI9rPimBD1BkZnpFTHg9cfPPo8eGSFM36U6Bx5CoY7aJIr/eUYQaYpV7i/ZOa+xunsE2RRfwT3EhIWqysVg8FOHBLZv1Hc6dGbmOn/XDZOJ2en4n92k1OWlJ9X7NeO+xNd+cdZv7xFw5M+yhaJIE34= Received: from AM6P195CA0071.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::48) by AM6PR08MB2966.eurprd08.prod.outlook.com (2603:10a6:209:4e::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19; Thu, 11 Jun 2020 11:59:13 +0000 Received: from AM5EUR03FT023.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::50) by AM6P195CA0071.outlook.office365.com (2603:10a6:209:87::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Thu, 11 Jun 2020 11:59:13 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT023.mail.protection.outlook.com (10.152.16.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 11:59:13 +0000 Received: ("Tessian outbound 39cdd740f5cb:v59"); Thu, 11 Jun 2020 11:59:13 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d6929578770bac2f X-CR-MTA-TID: 64aa7808 Received: from 58f8df83267e.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id BF4A3B3B-644E-4C1A-8E7B-D325FDD950B6.1; Thu, 11 Jun 2020 11:59:07 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 58f8df83267e.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 11 Jun 2020 11:59:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PGHQ0jEwQLNPfQ9tSLfo6AIM81aGLaqAwR6g8zPZjIHcqqZMYkEgAkx55KzOSI/uX3Y/qRYk/Xr16TKAu78lkW3NUpqLPNUUh+D9UGs+iZf7vl0z8ISzEtFBV0SH+GdSDekZMp8dGwOP7kJs0WSkcU0B2BoszqwzDXPOYvClbGH+AvobzkspHkxs/QboOUOTeqKnPRRsemUbcoxyce+enA8lVfu89WaNiysiDayO2PHbOrZRm63/4dGVeBPxwksapviKfAa34Clo0qCRdJL2MKDX2MimbAte/e3HVbPbJbI8ILfYzMAiIuUNPBhlfXJ9JEnPWEU3T0pZSYv6euHgbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q9LeQAfhC/BKsL2smIOUvgONsIexEg/IAzNAQ+yxpOo=; b=leJoQCK2E0kMGqpJvuSxQisz7ezE9Z+lmrDZs6yqT2B1AuyB9jEoqoVDOKydwgoAHuFNwsRf3RmevsMC3TJWzgW0ZzwHwCZr3fFr0HpH+4OoPcgO4GlzjDCdf1VhhJiQizcRq+gIfB7H06zr6rqjpFZsLzg8m1M5/HyyUOk3+xXJSJ8iY/TLB5PVxVFTXssxTYCNV8YHXUCSwiCbwmeGRvjfSVR8/29iv5PmfFDINjXO8C0GRUvxH3YraCBLzy0CufLj794CerJ4XSjnb23t0VzGoY9kMKt04Vz7jua7WBOYfuNB+LzAy5eff4Cw29oYESU7eAgyyutWI3QMf36CbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q9LeQAfhC/BKsL2smIOUvgONsIexEg/IAzNAQ+yxpOo=; b=Gc1RME7v0RCufZPS0A2ygCI9rPimBD1BkZnpFTHg9cfPPo8eGSFM36U6Bx5CoY7aJIr/eUYQaYpV7i/ZOa+xunsE2RRfwT3EhIWqysVg8FOHBLZv1Hc6dGbmOn/XDZOJ2en4n92k1OWlJ9X7NeO+xNd+cdZv7xFw5M+yhaJIE34= Authentication-Results-Original: lists.xenproject.org; dkim=none (message not signed) header.d=none; lists.xenproject.org; dmarc=none action=none header.from=arm.com; Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3387.eurprd08.prod.outlook.com (2603:10a6:10:45::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 11 Jun 2020 11:59:05 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Thu, 11 Jun 2020 11:59:05 +0000 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Subject: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Date: Thu, 11 Jun 2020 12:58:20 +0100 Message-Id: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: Content-Type: text/plain X-ClientProxiedBy: SN6PR2101CA0008.namprd21.prod.outlook.com (2603:10b6:805:106::18) To DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from e109506-lin.cambridge.arm.com (217.140.106.51) by SN6PR2101CA0008.namprd21.prod.outlook.com (2603:10b6:805:106::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.0 via Frontend Transport; Thu, 11 Jun 2020 11:59:02 +0000 X-Mailer: git-send-email 2.17.1 X-Originating-IP: [217.140.106.51] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 15f000e1-ac0b-4795-ecdc-08d80dfedbe2 X-MS-TrafficTypeDiagnostic: DB7PR08MB3387:|AM6PR08MB2966: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:8273;OLM:8273; X-Forefront-PRVS: 0431F981D8 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: D9wQPT1Vw+v6KQltmu09NTYPOCY1mhLdUwZv6Nr81EbAR8WId5a9zjhmw20V0Nw5iO7rWZrQxy1v+EcjFjdfdFXrFr/qd9dN5XFGnd7tFIuZ8ztVQWYjBvp8eWAkhoveIsIGRW7PsNKz4FRHZu92tNvubeizWom6wRgHLxve3enxaLMZJTh/aT16Chb7m65DsdyRl8Occhcb4h9KarGcEBfiCV39udQL8U4wGxylpSlgJ9nYoiQk5bnFbx55YYiAPD4eBk2eSYNLj04ChdHecnpjEmq7hnljD56pVaJSfeP3P31bMdrYCtL39pzs9o8K4TYmbYPDq6rKhrSyZraUbZXKULTI+ulbNhQktGnsWX4HLuX+3q6vWY6vfVrM8LdP X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(136003)(376002)(346002)(66476007)(6486002)(66946007)(86362001)(5660300002)(16526019)(36756003)(6666004)(7416002)(30864003)(186003)(4326008)(2906002)(26005)(83380400001)(66556008)(8676002)(956004)(6916009)(54906003)(8936002)(52116002)(2616005)(7696005)(316002)(44832011)(478600001)(136400200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: aWzEyJRdq1pGHFE09K6PK0lNXln1VWPBzowpXAHu45UPwD6QW2OaVxe858DapuHxIE6EhotLpYpKDirq1gkRstkuO5rxyvnPfUmlznyBif11hebgfPbpaEl4wP9WS5gEnp0iVMCKwWRBtq/sI8alh/hNyyfDuskme9/HG3Gn331qSyDiHFw3Sv9PlM3f3lvUIb7YSmKDjHUGd4obBz/1r0gZi6YwxnexKvSyA+27xXTf1/1PuMLryTWLXRuI1yRGX2hJtYHl9sWX0hVbyCQjNGD7KwJkmTvJSdt5JdxdPnlq6ovMkOc4eE4S6HVsY9iX7O503cjniyvbrO8jvK7sVANJHFbvlN0p4d2j+6IrNjxFPhANuKLjTEYJM30DgyT2jmGLAKbG7fl/m1nMztMoJ3HEdiDIXgLrIilfgNWIvrM1NAkCG2pxP0OHmAhds9tYdeLrrW0SPS5nMmAWibJGc0xbzDDOcwhoWRKwPjWoXYkiA+gjLU9D6BXb3vs+o2u+ X-MS-Exchange-Transport-Forked: True X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3387 Original-Authentication-Results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT023.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(46966005)(30864003)(83380400001)(2906002)(6666004)(8676002)(478600001)(70206006)(70586007)(86362001)(47076004)(336012)(81166007)(8936002)(54906003)(36906005)(2616005)(7696005)(44832011)(6486002)(5660300002)(6916009)(36756003)(107886003)(186003)(16526019)(82740400003)(356005)(316002)(26005)(82310400002)(956004)(4326008)(136400200001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 74ba31bf-030a-4c6e-b19c-08d80dfed6b9 X-Forefront-PRVS: 0431F981D8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2IE9rJbXiEm3dfCTxaPiMqIM+6vBgg/80cARySSrPk6UKwglI40xTiOrRg4bki1XF2u9DprIOww8IOQ7wcwUhCrsVhQyuBP9TrRVNMr7Fk7DnTP6sOOsJdmQ0BlkKqWr6Ko0MTOXHFG7xArEkE6TDPhAOx98BL2A/FsoFDpjfcOEA4X4ABxzdroxuCfML1Mqp9stjJ57cdOFjyd8xwlc3cqAAIsBVe7M64fHcKT8A+ip8aIdC8DwJEZJ/FiFADrcbs90t3cHGcZL0xSP13Q8XMsix8b8sjxZRZiPFHBFVf3TEY+mos0FZSXyIqKr8mWYgEkW6IoOwEeG4PdBUqC3wx+UPKStcfTpdXwYU9mHXGH+mKuCC4pmDVhdGaxo3L10IEEygm1pkfSzrDP5h0UQb8oOcH28arHTTjcbo7LGI62tXc9fLOuultRqZquZn+0q X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2020 11:59:13.4137 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 15f000e1-ac0b-4795-ecdc-08d80dfedbe2 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB2966 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , nd@arm.com, Volodymyr Babchuk , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" At the moment on Arm, a Linux guest running with KTPI enabled will cause the following error when a context switch happens in user mode: (XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xffffff837ebe0cd0 This patch is modifying the register runstate area handling on arm to convert the guest address during the hypercall. During runtime context switches the area is mapped to update the guest runstate copy. The patch is also removing the initial copy which was done during the hypercall handling as this is done on the current core when the context is restore to go back to guest execution on arm. As a consequence if the register runstate hypercall is called on one vcpu for an other vcpu, the area will not be updated until the vcpu will be executed (on arm only). On x86, the behaviour is not modified, the address conversion is done during the context switch and the area is updated fully during the hypercall. inline functions in headers could not be used as the architecture domain.h is included before the global domain.h making it impossible to use the struct vcpu inside the architecture header. This should not have any performance impact as the hypercall is only called once per vcpu usually. Signed-off-by: Bertrand Marquis --- xen/arch/arm/domain.c | 109 +++++++++++++++++++++++++++++------ xen/arch/x86/domain.c | 30 +++++++++- xen/arch/x86/x86_64/domain.c | 4 +- xen/common/domain.c | 19 ++---- xen/include/asm-arm/domain.h | 8 +++ xen/include/asm-x86/domain.h | 16 +++++ xen/include/xen/domain.h | 4 ++ xen/include/xen/sched.h | 16 +---- 8 files changed, 153 insertions(+), 53 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 31169326b2..739059234f 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include @@ -275,36 +276,104 @@ static void ctxt_switch_to(struct vcpu *n) virt_timer_restore(n); } -/* Update per-VCPU guest runstate shared memory area (if registered). */ -static void update_runstate_area(struct vcpu *v) +void arch_cleanup_runstate_guest(struct vcpu *v) { - void __user *guest_handle = NULL; - struct vcpu_runstate_info runstate; + spin_lock(&v->arch.runstate_guest.lock); - if ( guest_handle_is_null(runstate_guest(v)) ) - return; + /* cleanup previous page if any */ + if ( v->arch.runstate_guest.page ) + { + put_page_and_type(v->arch.runstate_guest.page); + v->arch.runstate_guest.page = NULL; + v->arch.runstate_guest.offset = 0; + } - memcpy(&runstate, &v->runstate, sizeof(runstate)); + spin_unlock(&v->arch.runstate_guest.lock); +} - if ( VM_ASSIST(v->domain, runstate_update_flag) ) +int arch_setup_runstate_guest(struct vcpu *v, + struct vcpu_register_runstate_memory_area area) +{ + struct page_info *page; + unsigned offset; + + spin_lock(&v->arch.runstate_guest.lock); + + /* cleanup previous page if any */ + if ( v->arch.runstate_guest.page ) { - guest_handle = &v->runstate_guest.p->state_entry_time + 1; - guest_handle--; - runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; - __raw_copy_to_guest(guest_handle, - (void *)(&runstate.state_entry_time + 1) - 1, 1); - smp_wmb(); + put_page_and_type(v->arch.runstate_guest.page); + v->arch.runstate_guest.page = NULL; + v->arch.runstate_guest.offset = 0; + } + + offset = ((vaddr_t)area.addr.v) & ~PAGE_MASK; + if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) + { + spin_unlock(&v->arch.runstate_guest.lock); + gprintk(XENLOG_DEBUG, "Runstate is crossing pages\n"); + return -EINVAL; + } + + /* provided address must be aligned to a 64bit */ + if ( offset % alignof(struct vcpu_runstate_info) ) + { + spin_unlock(&v->arch.runstate_guest.lock); + gprintk(XENLOG_DEBUG, "Runstate pointer is not aligned\n"); + return -EINVAL; + } + + page = get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); + if ( !page ) + { + spin_unlock(&v->arch.runstate_guest.lock); + gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); + return -EINVAL; } - __copy_to_guest(runstate_guest(v), &runstate, 1); + v->arch.runstate_guest.page = page; + v->arch.runstate_guest.offset = offset; + + spin_unlock(&v->arch.runstate_guest.lock); + + return 0; +} + + +/* Update per-VCPU guest runstate shared memory area (if registered). */ +static void update_runstate_area(struct vcpu *v) +{ + struct vcpu_runstate_info *guest_runstate; + void *p; + + spin_lock(&v->arch.runstate_guest.lock); - if ( guest_handle ) + if ( v->arch.runstate_guest.page ) { - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; + p = __map_domain_page(v->arch.runstate_guest.page); + guest_runstate = p + v->arch.runstate_guest.offset; + + if ( VM_ASSIST(v->domain, runstate_update_flag) ) + { + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; + smp_wmb(); + } + + memcpy(guest_runstate, &v->runstate, sizeof(v->runstate)); smp_wmb(); - __raw_copy_to_guest(guest_handle, - (void *)(&runstate.state_entry_time + 1) - 1, 1); + + if ( VM_ASSIST(v->domain, runstate_update_flag) ) + { + v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; + guest_runstate->state_entry_time &= ~XEN_RUNSTATE_UPDATE; + smp_wmb(); + } + + unmap_domain_page(p); } + + spin_unlock(&v->arch.runstate_guest.lock); } static void schedule_tail(struct vcpu *prev) @@ -560,6 +629,8 @@ int arch_vcpu_create(struct vcpu *v) v->arch.saved_context.sp = (register_t)v->arch.cpu_info; v->arch.saved_context.pc = (register_t)continue_new_vcpu; + spin_lock_init(&v->arch.runstate_guest.lock); + /* Idle VCPUs don't need the rest of this setup */ if ( is_idle_vcpu(v) ) return rc; diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index fee6c3931a..32bbed87d5 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1642,6 +1642,30 @@ void paravirt_ctxt_switch_to(struct vcpu *v) wrmsr_tsc_aux(v->arch.msrs->tsc_aux); } +int arch_setup_runstate_guest(struct vcpu *v, + struct vcpu_register_runstate_memory_area area) +{ + struct vcpu_runstate_info runstate; + + runstate_guest(v) = area.addr.h; + + if ( v == current ) + { + __copy_to_guest(runstate_guest(v), &v->runstate, 1); + } + else + { + vcpu_runstate_get(v, &runstate); + __copy_to_guest(runstate_guest(v), &runstate, 1); + } + return 0; +} + +void arch_cleanup_runstate_guest(struct vcpu *v) +{ + set_xen_guest_handle(runstate_guest(v), NULL); +} + /* Update per-VCPU guest runstate shared memory area (if registered). */ bool update_runstate_area(struct vcpu *v) { @@ -1660,8 +1684,8 @@ bool update_runstate_area(struct vcpu *v) if ( VM_ASSIST(v->domain, runstate_update_flag) ) { guest_handle = has_32bit_shinfo(v->domain) - ? &v->runstate_guest.compat.p->state_entry_time + 1 - : &v->runstate_guest.native.p->state_entry_time + 1; + ? &v->arch.runstate_guest.compat.p->state_entry_time + 1 + : &v->arch.runstate_guest.native.p->state_entry_time + 1; guest_handle--; runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; __raw_copy_to_guest(guest_handle, @@ -1674,7 +1698,7 @@ bool update_runstate_area(struct vcpu *v) struct compat_vcpu_runstate_info info; XLAT_vcpu_runstate_info(&info, &runstate); - __copy_to_guest(v->runstate_guest.compat, &info, 1); + __copy_to_guest(v->arch.runstate_guest.compat, &info, 1); rc = true; } else diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c index c46dccc25a..b879e8dd2c 100644 --- a/xen/arch/x86/x86_64/domain.c +++ b/xen/arch/x86/x86_64/domain.c @@ -36,7 +36,7 @@ arch_compat_vcpu_op( break; rc = 0; - guest_from_compat_handle(v->runstate_guest.compat, area.addr.h); + guest_from_compat_handle(v->arch.runstate_guest.compat, area.addr.h); if ( v == current ) { @@ -49,7 +49,7 @@ arch_compat_vcpu_op( vcpu_runstate_get(v, &runstate); XLAT_vcpu_runstate_info(&info, &runstate); } - __copy_to_guest(v->runstate_guest.compat, &info, 1); + __copy_to_guest(v->arch.runstate_guest.compat, &info, 1); break; } diff --git a/xen/common/domain.c b/xen/common/domain.c index 7cc9526139..0ca6bf4dbc 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -727,7 +727,10 @@ int domain_kill(struct domain *d) if ( cpupool_move_domain(d, cpupool0) ) return -ERESTART; for_each_vcpu ( d, v ) + { + arch_cleanup_runstate_guest(v); unmap_vcpu_info(v); + } d->is_dying = DOMDYING_dead; /* Mem event cleanup has to go here because the rings * have to be put before we call put_domain. */ @@ -1167,7 +1170,7 @@ int domain_soft_reset(struct domain *d) for_each_vcpu ( d, v ) { - set_xen_guest_handle(runstate_guest(v), NULL); + arch_cleanup_runstate_guest(v); unmap_vcpu_info(v); } @@ -1484,7 +1487,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) case VCPUOP_register_runstate_memory_area: { struct vcpu_register_runstate_memory_area area; - struct vcpu_runstate_info runstate; rc = -EFAULT; if ( copy_from_guest(&area, arg, 1) ) @@ -1493,18 +1495,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) if ( !guest_handle_okay(area.addr.h, 1) ) break; - rc = 0; - runstate_guest(v) = area.addr.h; - - if ( v == current ) - { - __copy_to_guest(runstate_guest(v), &v->runstate, 1); - } - else - { - vcpu_runstate_get(v, &runstate); - __copy_to_guest(runstate_guest(v), &runstate, 1); - } + rc = arch_setup_runstate_guest(v, area); break; } diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h index 4e2f582006..3a7f53e13d 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -11,6 +11,7 @@ #include #include #include +#include #include #include @@ -206,6 +207,13 @@ struct arch_vcpu */ bool need_flush_to_ram; + /* runstate guest info */ + struct { + struct page_info *page; /* guest page */ + unsigned offset; /* offset in page */ + spinlock_t lock; /* lock to access page */ + } runstate_guest; + } __cacheline_aligned; void vcpu_show_execution_state(struct vcpu *); diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h index e8cee3d5e5..f917b48cb8 100644 --- a/xen/include/asm-x86/domain.h +++ b/xen/include/asm-x86/domain.h @@ -11,6 +11,11 @@ #include #include #include +#ifdef CONFIG_COMPAT +#include +DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t); +#endif + #define has_32bit_shinfo(d) ((d)->arch.has_32bit_shinfo) @@ -626,6 +631,17 @@ struct arch_vcpu struct { bool next_interrupt_enabled; } monitor; + +#ifndef CONFIG_COMPAT +# define runstate_guest(v) ((v)->arch.runstate_guest) + XEN_GUEST_HANDLE(vcpu_runstate_info_t) runstate_guest; /* guest address */ +#else +# define runstate_guest(v) ((v)->arch.runstate_guest.native) + union { + XEN_GUEST_HANDLE(vcpu_runstate_info_t) native; + XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t) compat; + } runstate_guest; +#endif }; struct guest_memory_policy diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index 7e51d361de..d5d73ce997 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -63,6 +63,10 @@ void arch_vcpu_destroy(struct vcpu *v); int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset); void unmap_vcpu_info(struct vcpu *v); +int arch_setup_runstate_guest(struct vcpu *v, + struct vcpu_register_runstate_memory_area area); +void arch_cleanup_runstate_guest(struct vcpu *v); + int arch_domain_create(struct domain *d, struct xen_domctl_createdomain *config); diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index ac53519d7f..fac030fb83 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -29,11 +29,6 @@ #include #include -#ifdef CONFIG_COMPAT -#include -DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t); -#endif - /* * Stats * @@ -166,16 +161,7 @@ struct vcpu struct sched_unit *sched_unit; struct vcpu_runstate_info runstate; -#ifndef CONFIG_COMPAT -# define runstate_guest(v) ((v)->runstate_guest) - XEN_GUEST_HANDLE(vcpu_runstate_info_t) runstate_guest; /* guest address */ -#else -# define runstate_guest(v) ((v)->runstate_guest.native) - union { - XEN_GUEST_HANDLE(vcpu_runstate_info_t) native; - XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t) compat; - } runstate_guest; /* guest address */ -#endif + unsigned int new_state; /* Has the FPU been initialised? */ -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 11:59:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 11:59:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLrm-0000iH-Ur; Thu, 11 Jun 2020 11:59:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLrl-0000i2-Sl for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 11:59:29 +0000 X-Inumbo-ID: 00d024b0-abdb-11ea-b50b-12813bfff9fa Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [40.107.6.76]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 00d024b0-abdb-11ea-b50b-12813bfff9fa; Thu, 11 Jun 2020 11:59:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NoAS9Dfi5sevNBmACNeNCJiBuMEo0Y1qOGnIY23Styk=; b=F84VXtaHUrId5N+9NDk9WqqLTS5f3J92YhF9dgEJrYOHzO3ZV98srgmrK5wnBJdzuHuwI9i8Wrup32hOf55OHjv38cR4S9NEg6IRmklJP9PYZ9pvPWC7/E0sKXfMLhpy/vHoDG2XHSwAlLl1E+6P+FILulh/BLdfwFBziv3oGvs= Received: from AM5PR0101CA0020.eurprd01.prod.exchangelabs.com (2603:10a6:206:16::33) by AM0PR08MB3122.eurprd08.prod.outlook.com (2603:10a6:208:5d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.22; Thu, 11 Jun 2020 11:59:26 +0000 Received: from AM5EUR03FT039.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:16:cafe::ca) by AM5PR0101CA0020.outlook.office365.com (2603:10a6:206:16::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.20 via Frontend Transport; Thu, 11 Jun 2020 11:59:26 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT039.mail.protection.outlook.com (10.152.17.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 11:59:25 +0000 Received: ("Tessian outbound 4f5776643448:v59"); Thu, 11 Jun 2020 11:59:25 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: afd211188bb5d748 X-CR-MTA-TID: 64aa7808 Received: from 2789c5b74de9.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6AC60FA3-C563-4599-9E17-FCF50E9B6D31.1; Thu, 11 Jun 2020 11:59:20 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2789c5b74de9.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 11 Jun 2020 11:59:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qsq89Fm1tFfAruQKlsAJrncXOFNuIlKuMzKxlDRCTYY0LR3Ma9nDnc130RZV3kVAj5SDy/V9A2obkKigxwzIQ8Vi4y4lwVNTI2HWl7zCHev5uscTuyU/qnIxh1R7N0S1sKEsAwT0JHIx22fOsH5YFtgILf+2n6K7qg8uWigbGNZygT+YynLx2Koizd685SUGxcf63pvUH206raid6j1B+V7Il6AoNG1hrgDjQtx7PPZWAXDKT/nrDSmhjGvvPaJIJTZT7xkOMsWdp453K9OR/EclNyLMkCWHX8si2hW3m8mtkTijDIm2ZY//sGC0e2nG29bx6w0c45aotr3Gxdp+NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NoAS9Dfi5sevNBmACNeNCJiBuMEo0Y1qOGnIY23Styk=; b=j55kCcTP4X4yspKYhWduN4UnjTzebVvceWO2tCS15ug1RHw+BNMBEshtWhZw0e0EyfiNN+7Wgu/ff3yEGpkycuba7yAcmIOrO/EKb0/a6AoQ6VqpbmFzTSJ5HEs/+l+laV/EC/80Mhz9Z4gD1ncQH07NBo4Wk1V+pQ8P04YFO3y1SK/vSQb7tBrPCNiPy2Wp1Q2OSqCTyKM6id4o1lBTjypc+KUYYKseKLgmlEPOssL3V9Sp2v7FyFrFJ2G1EYtocGwsrFrJKwOdAUXat2JpsngM6uHdDC18PjQJog/jOzpS698AbKCvJq2tTDfDf8DhyIHx1NP9DTPKvz/PgmYUdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NoAS9Dfi5sevNBmACNeNCJiBuMEo0Y1qOGnIY23Styk=; b=F84VXtaHUrId5N+9NDk9WqqLTS5f3J92YhF9dgEJrYOHzO3ZV98srgmrK5wnBJdzuHuwI9i8Wrup32hOf55OHjv38cR4S9NEg6IRmklJP9PYZ9pvPWC7/E0sKXfMLhpy/vHoDG2XHSwAlLl1E+6P+FILulh/BLdfwFBziv3oGvs= Authentication-Results-Original: lists.xenproject.org; dkim=none (message not signed) header.d=none; lists.xenproject.org; dmarc=none action=none header.from=arm.com; Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3387.eurprd08.prod.outlook.com (2603:10a6:10:45::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 11 Jun 2020 11:59:18 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Thu, 11 Jun 2020 11:59:18 +0000 From: Bertrand Marquis To: xen-devel@lists.xenproject.org Subject: [PATCH 2/2] xen/arm: Support runstate crossing pages Date: Thu, 11 Jun 2020 12:58:21 +0100 Message-Id: X-Mailer: git-send-email 2.17.1 In-Reply-To: References: Content-Type: text/plain X-ClientProxiedBy: SN6PR2101CA0008.namprd21.prod.outlook.com (2603:10b6:805:106::18) To DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from e109506-lin.cambridge.arm.com (217.140.106.51) by SN6PR2101CA0008.namprd21.prod.outlook.com (2603:10b6:805:106::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.0 via Frontend Transport; Thu, 11 Jun 2020 11:59:17 +0000 X-Mailer: git-send-email 2.17.1 X-Originating-IP: [217.140.106.51] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a11b1002-dc99-4ac2-15ee-08d80dfee345 X-MS-TrafficTypeDiagnostic: DB7PR08MB3387:|AM0PR08MB3122: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:8882;OLM:8882; X-Forefront-PRVS: 0431F981D8 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: lnDWdIFSvikpOOtPSK/bn5iC2aT6G8reEAcseoCLs0PczU0o/b4U8/zZdeGUD+7J5Y3g194Uh1x5iJcj7ub1RjwKOIK3eRkd42NBvFK3wKc+eKXc6unJ1SDNCPCjw2gj370lV+NzKdhzAMH827DtRtSoj6V+7YrLj7fLi8zbOLvxRsg1R4BryApNnHQDMbUGBcWYMJX/7UZbDCy3r21P1oHl6ngv14dfHz4Fgxd/O2zpOSMN5FKu9FkKcqIuuGgPyQvyx4H08OtDYFk3pM/XFCu+QwHZ/NLZ5usbjYGbQMDZITrK7tPkTHiDGGLKgwPLZVCOWDj1j0rPSy/AsVpwkC8cTN8/B2PnhiA0hPXA3u4/z/iIPpEzKjDNDvkQL2ll X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(136003)(376002)(346002)(66476007)(6486002)(66946007)(86362001)(5660300002)(16526019)(36756003)(6666004)(186003)(4326008)(2906002)(26005)(83380400001)(66556008)(8676002)(956004)(6916009)(54906003)(8936002)(52116002)(2616005)(7696005)(316002)(44832011)(478600001)(136400200001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: BHS72odaQD/wSjd8dvGeF2rTCCwLsNcXNhCgk6GzzTSN1QmEfID0U6eLJ+fJfznSEovaf+8poWRlmgV5lNnjuAqxneR4Iq+KKej/31tGNM6yLwsEbzGw5mcNMDmB4BdoyY7emJwkxFT9VhtyIql4flIhINdvuD6FJIyY+Dnajngz3YvmtSzh4UatkhSIEjo2/8yj4BKR+ihvjo40yjFhR+/7TyOZddZtKAyZCORGtLJ0Z8A3t2g3VuOO8LEP26amGsz8tSF9rrHf1wO+pWlAT2UNJDuUE4B97yAKXk15yHYV7Y6hcpDHJeIvuv4vu1/42su4aa2OaSjN8fzlrBlReXwhShrbezXhPkfy0UPzrPAiVXflPqiFoEc0XT11VjkhNY0OGLmXlsf4oHUbs86L9TB8ZPuwXCqcCDdhMntVdYjVt8N1FTHFlv0aU1FyWeIQKXAjTgWjxg32hKlGMSuWfryBOl5oTD/jFLWPPSeHfn8= X-MS-Exchange-Transport-Forked: True X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3387 Original-Authentication-Results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT039.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39860400002)(396003)(136003)(46966005)(86362001)(8936002)(8676002)(107886003)(4326008)(16526019)(7696005)(6666004)(70586007)(70206006)(82310400002)(6916009)(26005)(356005)(44832011)(81166007)(36906005)(36756003)(2906002)(5660300002)(186003)(316002)(54906003)(336012)(82740400003)(6486002)(83380400001)(47076004)(2616005)(478600001)(956004)(136400200001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 096f14cb-9a56-4cf8-c7f2-08d80dfedef2 X-Forefront-PRVS: 0431F981D8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Dw8L6Vvn7MfpYSlC4kqS4V5LcwFM5s7Z65Vo2BZhH/dREhwLPHW7HNWo4jobTI+YEd4wtjBrRATp9d1gnvXzhGUpY9DAQZViR+2llfm8HHzsEeQaPoeuNJYfoRxYFTp2udyaW/0leu7woQgQ22KWne6escuvxhxteNhFdwxJL0C7lH74oDz6/w81/hZkRtm0FfXFSJGiCs4buIgKVSpvhzE+swxTnz24tT7MCNV6NKgxPB9qUuY2EJ3p6X4MuQxEhoJ/usO8ObKIYWHRoOs0PGklGGBCcgN7mzaM9FTOwmorLX3JTMw1Ug22dMmD33TTUWvD38venqI9TKCGySDImyJqDfJgyAhqW29N/4vd+tpYij8vC9xe83n/QzOQ9gjgR0OBtbx5ykjTChpiLdxV5OCI/QB9HwmNOsAHBspXl/0= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2020 11:59:25.8165 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a11b1002-dc99-4ac2-15ee-08d80dfee345 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3122 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Volodymyr Babchuk , nd@arm.com, Julien Grall , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add support for runstate area register with the structure crossing pages The code is storing up to 2 pages reference during the hypercall. During a context switch, the code is computing where the state_entry_time is and is breaking the memcpy in 2 parts when it is required. Signed-off-by: Bertrand Marquis --- xen/arch/arm/domain.c | 101 +++++++++++++++++++++++++---------- xen/include/asm-arm/domain.h | 5 +- 2 files changed, 76 insertions(+), 30 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 739059234f..d847cb00f2 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@ -280,11 +280,16 @@ void arch_cleanup_runstate_guest(struct vcpu *v) { spin_lock(&v->arch.runstate_guest.lock); - /* cleanup previous page if any */ - if ( v->arch.runstate_guest.page ) + /* cleanup previous pages if any */ + if ( v->arch.runstate_guest.page[0] ) { - put_page_and_type(v->arch.runstate_guest.page); - v->arch.runstate_guest.page = NULL; + put_page_and_type(v->arch.runstate_guest.page[0]); + v->arch.runstate_guest.page[0] = NULL; + if ( v->arch.runstate_guest.page[1] ) + { + put_page_and_type(v->arch.runstate_guest.page[1]); + v->arch.runstate_guest.page[1] = NULL; + } v->arch.runstate_guest.offset = 0; } @@ -294,26 +299,25 @@ void arch_cleanup_runstate_guest(struct vcpu *v) int arch_setup_runstate_guest(struct vcpu *v, struct vcpu_register_runstate_memory_area area) { - struct page_info *page; + struct page_info *page[2] = {NULL,NULL}; unsigned offset; spin_lock(&v->arch.runstate_guest.lock); - /* cleanup previous page if any */ - if ( v->arch.runstate_guest.page ) + /* cleanup previous pages if any */ + if ( v->arch.runstate_guest.page[0] ) { - put_page_and_type(v->arch.runstate_guest.page); - v->arch.runstate_guest.page = NULL; + put_page_and_type(v->arch.runstate_guest.page[0]); + v->arch.runstate_guest.page[0] = NULL; + if ( v->arch.runstate_guest.page[1] ) + { + put_page_and_type(v->arch.runstate_guest.page[1]); + v->arch.runstate_guest.page[1] = NULL; + } v->arch.runstate_guest.offset = 0; } offset = ((vaddr_t)area.addr.v) & ~PAGE_MASK; - if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) - { - spin_unlock(&v->arch.runstate_guest.lock); - gprintk(XENLOG_DEBUG, "Runstate is crossing pages\n"); - return -EINVAL; - } /* provided address must be aligned to a 64bit */ if ( offset % alignof(struct vcpu_runstate_info) ) @@ -323,15 +327,30 @@ int arch_setup_runstate_guest(struct vcpu *v, return -EINVAL; } - page = get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); - if ( !page ) + page[0] = get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); + if ( !page[0] ) { spin_unlock(&v->arch.runstate_guest.lock); gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); return -EINVAL; } - v->arch.runstate_guest.page = page; + if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) + { + /* guest area is crossing pages */ + page[1] = get_page_from_gva(v, (vaddr_t)area.addr.v + PAGE_SIZE, + GV2M_WRITE); + if ( !page[1] ) + { + put_page_and_type(v->arch.runstate_guest.page[0]); + spin_unlock(&v->arch.runstate_guest.lock); + gprintk(XENLOG_DEBUG, "Runstate pointer is not fully mapped\n"); + return -EINVAL; + } + } + + v->arch.runstate_guest.page[0] = page[0]; + v->arch.runstate_guest.page[1] = page[1]; v->arch.runstate_guest.offset = offset; spin_unlock(&v->arch.runstate_guest.lock); @@ -343,34 +362,60 @@ int arch_setup_runstate_guest(struct vcpu *v, /* Update per-VCPU guest runstate shared memory area (if registered). */ static void update_runstate_area(struct vcpu *v) { - struct vcpu_runstate_info *guest_runstate; - void *p; + void *p[2]; + unsigned offset, time_offset; + uint64_t *state_entry_time; spin_lock(&v->arch.runstate_guest.lock); - if ( v->arch.runstate_guest.page ) + if ( v->arch.runstate_guest.page[0] ) { - p = __map_domain_page(v->arch.runstate_guest.page); - guest_runstate = p + v->arch.runstate_guest.offset; + p[0] = __map_domain_page(v->arch.runstate_guest.page[0]); + if ( v->arch.runstate_guest.page[1] ) + p[1] = __map_domain_page(v->arch.runstate_guest.page[1]); + else + p[1] = NULL; + offset = v->arch.runstate_guest.offset; if ( VM_ASSIST(v->domain, runstate_update_flag) ) { + time_offset = offset + + offsetof(struct vcpu_runstate_info, state_entry_time); + + if ( time_offset < PAGE_SIZE ) + state_entry_time = p[0] + time_offset; + else + state_entry_time = p[1] + (time_offset - PAGE_SIZE); + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; - guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; + *state_entry_time |= XEN_RUNSTATE_UPDATE; smp_wmb(); } + else + state_entry_time = NULL; + + if ( p[1] ) + { + memcpy(p[0] + offset, &v->runstate, PAGE_SIZE - offset); + memcpy(p[1], &v->runstate + (PAGE_SIZE - offset), + sizeof(v->runstate) - (PAGE_SIZE - offset)); + } + else + memcpy(p[0] + offset, &v->runstate, sizeof(v->runstate)); - memcpy(guest_runstate, &v->runstate, sizeof(v->runstate)); + /* copy must be done before switching the bit */ smp_wmb(); - if ( VM_ASSIST(v->domain, runstate_update_flag) ) + if ( state_entry_time ) { v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; - guest_runstate->state_entry_time &= ~XEN_RUNSTATE_UPDATE; + *state_entry_time &= ~XEN_RUNSTATE_UPDATE; smp_wmb(); } - unmap_domain_page(p); + unmap_domain_page(p[0]); + if ( p[1] ) + unmap_domain_page(p[1]); } spin_unlock(&v->arch.runstate_guest.lock); diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h index 3a7f53e13d..61e32f1ed5 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -209,8 +209,9 @@ struct arch_vcpu /* runstate guest info */ struct { - struct page_info *page; /* guest page */ - unsigned offset; /* offset in page */ + /* we need 2 pages in case the guest area is crossing pages */ + struct page_info *page[2]; /* guest pages */ + unsigned offset; /* offset in first page */ spinlock_t lock; /* lock to access page */ } runstate_guest; -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 12:08:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 12:08:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLzy-0001nH-AU; Thu, 11 Jun 2020 12:07:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjLzx-0001nC-QL for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 12:07:57 +0000 X-Inumbo-ID: 2f649fa8-abdc-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x333.google.com (unknown [2a00:1450:4864:20::333]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2f649fa8-abdc-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 12:07:57 +0000 (UTC) Received: by mail-wm1-x333.google.com with SMTP id r9so4750629wmh.2 for ; Thu, 11 Jun 2020 05:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=SQjfCLhpn1aUhJIKbYJH4jjv4xfDX96+6/uKPZYtr+o=; b=sAwGtmfq85dRn88LA//XkcFUWnRvB/6KSXq2BHr1bQa6dj/RETp6lJtKWsSP+J5U2t TEenVL4nt8npCpzDwYBAdVL2hGGjAvkiFz0zuFtNaELEIsnpH4i9PiPl2fSHzzVw17xv J8OUNZFKoeXrYdIuZ2X409oZ4ieMYRwPPRKvpsnvxU/zwnjqPvIKiDcBpP6zrddJqjk2 j5EvC03XyL29sTQiNExsjD5DnlJ0cysFLj+jpJ4umQYNosYvUVazLoKUgcwZhf5ezYkZ HdlRo7MpDobI1XTVlRiLDe8tyAnD1nwfXEs9B0LIQURP1MHj1ukco7JiqioPwHlVLbOy vdvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=SQjfCLhpn1aUhJIKbYJH4jjv4xfDX96+6/uKPZYtr+o=; b=Q8SbaL1wso5yQvnb+/FthndjK0lnXgikXUtdJpIoIv+SN/9Kq2ww2pzxdP70lMvjlA 8BKbffVVwdTHR4Dr97rbQMTfkQNo1TA+Ryz9kQFVkApV2it+BzkST6yIu6DRIfBH9dmi 3EgcPLsqK3kr9D9JzxtMKT4o9m1F5c/na67rYhZ5X0cePbEc6cmLajjlO3rCsGfn4Q3t QY4sMwi4OILLddgAtmS6jOAb5YIMYgXmxSKOO3U+yhQHIWQii4L3J4zafxzuZ/uN6g64 gBJEF9QVK5alAiGOY6MpRaLR+831deQf5XE0mzAQ/JRmmVB9dnZpM545vcEVaW6RRok/ wFqg== X-Gm-Message-State: AOAM530f1rYpqXhbNaIzfzBd+xeu7sDeMh5McLcb4KgqGp2H3E4XdJ0y QEHvmfraNyOtAWhD/uST1XM= X-Google-Smtp-Source: ABdhPJwXLXJ1OV07e/4hbQ1MSCcH+zpoui0yVnQ3aKm4JrukvxzwuI2aJkl5xHTJ5TuNZFDspVglMw== X-Received: by 2002:a1c:6244:: with SMTP id w65mr7857843wmb.82.1591877276115; Thu, 11 Jun 2020 05:07:56 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.177]) by smtp.gmail.com with ESMTPSA id q1sm3751244wmc.15.2020.06.11.05.07.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 05:07:55 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Jason Andryuk'" , References: <20200611035518.379297-1-jandryuk@gmail.com> In-Reply-To: Subject: RE: [PATCH] libacpi: Widen TPM detection Date: Thu, 11 Jun 2020 13:07:50 +0100 Message-ID: <00e801d63fe8$f0682d10$d1388730$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQD+75p+LtrZduM9I2CZ2QpfMgSpTQIvmX2vqnB1jmA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Ian Jackson' , 'Jan Beulich' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 11 June 2020 12:52 > To: Jason Andryuk ; xen-devel@lists.xenproject.org > Cc: Ian Jackson ; Wei Liu ; Jan Beulich ; > Paul Durrant > Subject: Re: [PATCH] libacpi: Widen TPM detection > > On 11/06/2020 04:55, Jason Andryuk wrote: > > The hardcoded tpm_signature is too restrictive to detect many TPMs. For > > instance, it doesn't accept a QEMU emulated TPM (VID 0x1014 DID 0x0001). > > Make the TPM detection match that in rombios which accepts a wider > > range. > > > > With this change, the TPM's TCPA ACPI table is generated and the guest > > OS can automatically load the tpm_tis driver. It also allows seabios to > > detect and use the TPM. However, seabios skips some TPM initialization > > when running under Xen, so it will not populate any PCRs unless modified > > to run the initialization under Xen. > > > > Signed-off-by: Jason Andryuk > > Reviewed-by: Andrew Cooper > > This looks like it wants backporting, so CC'ing Paul for a 4.14 release ack. Agreed. Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Thu Jun 11 12:18:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 12:18:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMA3-0002jq-HJ; Thu, 11 Jun 2020 12:18:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMA2-0002jk-DT for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 12:18:22 +0000 X-Inumbo-ID: a3848f0a-abdd-11ea-b511-12813bfff9fa Received: from EUR03-VE1-obe.outbound.protection.outlook.com (unknown [40.107.5.84]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a3848f0a-abdd-11ea-b511-12813bfff9fa; Thu, 11 Jun 2020 12:18:21 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HuV4oV0s5UHwF3XyaDbe5Pnaqv+vZxYkRgYxP653ZK47YUgHSObMBIkB4EbbHP9nyECIZUu4zazOfRDVvNx1f2NNlMT8/CPCOU7dwejVHUXbJXQxODSVR+kU3zQ/lNTOg0iTFDtpCZvSYleyKgPTgmezgRbywmFeSshZTdtQEW8JQdE+EvnjbtYlDmXaDxQ0ffzUKxrh/Pc3AUCIOg4XXrtceVPA+ynsXgJvJ9O/GMKQr69N+XcmXbcZfMKTvAslPQx7SiLcP1xveHf6H6VWj/W2LLJQdecCWARFEwiebYK42UqtgypFtAYnk6nREcAnKlFx96OJ6eGpV9V4jTr4Lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xxjhrZ/jHmB4WOxIajiLtMregBOwhoysRuaJ/WsOvHo=; b=HEBGw3upNb9k0YcR3KOKLFnzUh9xvcp8yHPtzvfF687UYqnPCghdIBKcPqoU4z+0M1ZaJG6h5e5cpiQi7bkVhgceGkrVPAU2DKEjgjW0qGscK6BZNmyk2CZrmS61tZSFrkCzpfEL+QRIDCLyPDse5y178vVRhF8AEyo7CUaiDo0YeePx/bSV/vkFauCsGxorj70kw94YTaiBpXWJrW0g7bCPp0DVUxoNUjadJ4hDsn86uy8vgGaN3GwEWE/WEJSG6oN861PD/gFUcYAafGyOalTtsAutCXS5kDAT5ZtCDtOsDPL1jJawrTwCQ8xEtEF3Pmjr3LOCAFHaO4SxvqEgAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xxjhrZ/jHmB4WOxIajiLtMregBOwhoysRuaJ/WsOvHo=; b=C23HER/UCaRGJMWQZPrMkpUTuTRCfEurulJCCPDurTvGFFAUuswO9wUhByFON1B7BomMwO0GqlvTEdTXiWg1XD/3n6FgHNqk7dhQfkdVeMUgQ4f72Q0JmLgj6a/vSbXJtPdioz2a24AuEZ/yf2WkGHRZf9ALmVXDLKzEsDVpELmNRDshgfqm7zerra4gfQlpbE9WHkJUfKtp//5n5LOJVKGVg6el/0sbgkC1hPebp7UKMeqVgVq0dtDawxnNj7fIbDzzMutcg1/2rxXMnXB0215Oz933sM6wo5MFzl+1DESGArYGU630k1uA0JbqFZ7Bmn96Fr3c7RL6bN/5qyfhkg== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB4895.eurprd03.prod.outlook.com (2603:10a6:803:bb::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Thu, 11 Jun 2020 12:18:18 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3066.023; Thu, 11 Jun 2020 12:18:18 +0000 From: Oleksandr Andrushchenko To: Julien Grall , "xen-devel@lists.xenproject.org" Subject: Re: HYPERVISOR_console_io + CONSOLEIO_write needs COPY_flush_dcache Thread-Topic: HYPERVISOR_console_io + CONSOLEIO_write needs COPY_flush_dcache Thread-Index: AQHWPv8SOx/IaSMb+EOuO5msEU03SajRzVWAgAGJcoA= Date: Thu, 11 Jun 2020 12:18:18 +0000 Message-ID: References: <912a84d1-ca47-9c37-06e7-28bebe696b4d@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f34def31-8923-441b-dfb2-08d80e01866f x-ms-traffictypediagnostic: VI1PR03MB4895: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0431F981D8 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gZU04yykYlTxPqW5/7UleOkmEIfg+f/033AZMU4QzaeV8IVgXfueOEdtrrPiOP5pJBiszGjBeC/ZFPb1HBjFfoYqp76TaNsfcsmnzdmDHuIf/xiOD5yC4CmQl+/vy5tO4p3lzZ4ara8tP7AUc09+CRWUN19BMGecuR6ujOQ2jVU/Sx14/xuLSK9YQbL0/c4t9xJveOJvJEtWKeyW1ONFYaVb7OnexMF0bskgpXR77343/QPsRHe1Wyi4Bpc5My5ZJySiVWLMoN5ImbIA3RspRuny7ODmyhCnwHOdxenBYVB90HqJbsB8RMZHcgoJpFArdvVtKrLEJu69TfkJQ6l7aw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(136003)(39860400002)(376002)(366004)(6512007)(316002)(110136005)(8936002)(6486002)(31696002)(86362001)(2616005)(31686004)(71200400001)(4326008)(54906003)(36756003)(64756008)(26005)(5660300002)(66476007)(6506007)(53546011)(8676002)(76116006)(66556008)(478600001)(83380400001)(66946007)(2906002)(91956017)(66446008)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: vxZHB/wBG1gFg1OqkakdfQ0NkqRfKIFwDA90Bg+/LNWZK4F0U659VjatxbYo4jNLbsJmJv5lCDZfvn0uztWOX5FSXKIIwUd8E135VmHiV08YMx7Vymr+z7q8QNTeu1cCl8bcBKj9NRSe+o5FyVFBqfCrsOmdM37UU3Csu8uGZuJyUYDxRzCIiw4JaC7EMEVFHrQobKOOPNW0i+9PrPkfJfhgDZ6fsrFvrF4rIM687HzH9hnSDZj6TOJHvUNImuCwbr/8wP470P5h83Ah/fnaIfp9fWJxeW8/E/Kva5REPdlAAQSJzKU7CwW/Hk81g3WyKlYgENHU8Tb6/F+vTaXMdfzdaxP0Q9GUtrCw4opAFF/4MKLf1/GejV2UOiz3d8ngldlvwXT5jkQ3Y5RVgspRvAAxJQS+8ZLnOur7kxS0RX1WBOHMPYwJaZ8KQsX+EwAHS0WbmOvmdl7ZLTTvvMocsgu0heWWOfl19+iDKKlgcIQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7B04FA7229C6084FBA0DA0B81AA9EF54@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: f34def31-8923-441b-dfb2-08d80e01866f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2020 12:18:18.4810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: b5iBTFMmhxw3D3iz3eb601DJH1LMjrbXLgJ1ZL2Fu4U9mtAz0slQIqnSLtR26gp+x97WHc3zg8nU6uZCZRKgvJhcWB28ly4Dg7khbt7LieSbNQsgYtMfM3SrPcadrMgZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4895 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzEwLzIwIDM6NTAgUE0sIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gT24gMTAvMDYvMjAy MCAwOToxMywgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gd3JvdGU6DQo+PiBIZWxsbywNCj4NCj4g SGksDQo+DQo+PiBXaGlsZSBhZGRpbmcgc3VwcG9ydCBmb3IgcGFyYS12aXJ0dWFsaXplZCBibG9j ayBkZXZpY2UgaW4gdS1ib290DQo+Pg0KPj4gSSBmYWNlZCBhbiBpc3N1ZSB3aXRoIEhZUEVSVklT T1JfY29uc29sZV9pbyArIENPTlNPTEVJT193cml0ZS4NCj4+DQo+PiBJIHRyaWVkIHRvIHVzZSB0 aGUgaHlwZXJjYWxsIGR1cmluZyBNTVUgc2V0dXAgc3RhZ2Ugd2hpbGUgZW5hYmxpbmcgZGF0YSBj YWNoZQ0KPj4NCj4+IG9uIGFybTY0IHBsYXRmb3JtIChlLmcuIGRhdGEgY2FjaGUgaXMgbm90IHll dCBlbmFibGVkKSBhbmQgc2F3IGluIGd1ZXN0J3MgY29uc29sZQ0KPj4NCj4+IGVpdGhlciBvbGQg ZGF0YSBvciBzb21lIHNvcnQgb2YgZ2FyYmFnZS4gUHJpbnRpbmcgY29uc3RhbnQgc3RyaW5ncywg anVzdCBsaWtlIG1pbmktb3MNCj4+DQo+PiBkb2VzIG9uIGJvb3QsIHdvcmtzIGFzIGV4cGVjdGVk LiANCj4NCj4gUGVyIHRoZSBoeXBlcmNhbGwgQUJJIChzZWUgaW5jbHVkZS9wdWJsaWMvYXJjaC1h cm0uaCkgYWxsIHRoZSBidWZmZXJzIG11c3QgcmVzaWRlIGluIG1lbW9yeSB3aGljaCBpcyBtYXBw ZWQgYXMgTm9ybWFsIElubmVyIFdyaXRlLUJhY2sgSW5uZXItU2hhcmVhYmxlLg0KPg0KPiBZb3Ug YXJlIHBhc3Npbmcgbm9uLWNhY2hlYWJsZSBtZW1vcnksIHNvIHRoZSBiZWhhdmlvciB5b3Ugc2Vl IGlzIGV4cGVjdGVkLg0KVGhpcyBpcyB3aGF0IHdlIGNvbWUgdXAgd2l0aCBhcyB3ZWxsDQo+DQo+ PiBTbywgbG9va2luZyBhdCB0aGUgWGVuIGNvZGUgWzFdIGl0IHNlZW1zDQo+Pg0KPj4gdGhhdCB3 ZSBzaG91bGQgY29weSBndWVzdCdzIGJ1ZmZlciB3aXRoIENPUFlfZmx1c2hfZGNhY2hlIHNldCBp biB0aGlzIGNhc2UNCj4NCj4gQ09QWV9mbHVzaF9kY2FjaGUgaXMgb25seSBtZWFudCB0byBiZSB1 c2VkIHdoZW4gY29weSB0byBndWVzdCBtZW1vcnkgdG8gbWFrZSBzdXJlIHRoZSBkYXRhIHJlYWNo ZWQgdGhlIHBvaW50IG9mIGNvaGVyZW5jeSBpbiB5b3VyIHN5c3RlbS4gSXQgaXMgbm90IG1lYW50 IHRvIGJlIHVzZWQgd2hlbiBjb3B5aW5nIGZyb20gZ3Vlc3QuDQpVbmRlcnN0b29kIGFuZCBhZ3Jl ZQ0KPg0KPj4gYXMgKHVzdWFsbHk/KSB0aGlzIGh5cGVyY2FsbCBpcyB1c2VkIGluIGd1ZXN0J3Mg Y29kZSB3aGljaCBkb2Vzbid0IGhhdmUgYW55DQo+PiBvdGhlciBtZWFucyB0byBwcmludCB5ZXQs IGUuZy4gZWFybHkgcHJpbnRrIGNhc2UuDQo+DQo+IEkgaGF2ZSBiZWVuIHVzaW5nIGl0IGFmdGVy IHRoZSBNTVUgaXMgc2V0dXAgDQpUaGUgdGhpbmcgaXMgdGhhdCBpbiB1LWJvb3QgYSBsb3Qgb2Yg dGhpbmdzIGhhcHBlbiBiZWZvcmUgdGhlIE1NVSBzZXR1cC4uLg0KPiBidXQgYmVmb3JlIHRoZSBj b25zb2xlIGlzIHByb3Blcmx5IHNldHVwIGJ5IHRoZSBndWVzdCAodGhlcmUgaXMgYSBsb3QgdGhh dCBjYW4gaGFwcGVuIGluIExpbnV4IGJldHdlZW4gdGhlIHR3bykuIEluIG15IGNhc2UsIHRoZSBm bHVzaCBpcyBub3QgbmVjZXNzYXJ5IGFuZCB3b3VsZCBiZSB3cm9uZy4NCi4uLiBhbmQgd2l0aG91 dCB0aGUgZmx1c2ggeW91IGxvc2UgdGhlIGFiaWxpdHkgdG8gZGVidWcgdGhhdCBjb2RlLg0KPg0K PiBJbiBnZW5lcmFsLCB0aGUgY2FjaGUgaXMgbmV2ZXIgb2ZmIG9uIEFybTY0IGJlY2F1c2UgeW91 IG1heSBoYXZlIHN5c3RlbSBjYWNoZSBvciwgaW4gdGhlIGNhY2hlIG9mIHZpcnR1YWxpemF0aW9u LCBjYWNoZWFibGUgbWFwcGluZyBpbiB0aGUgaHlwZXJ2aXNvciAoYWxsIHRoZSBtZW1vcnkgaXMg bWFwcGVkKS4NCj4NCj4gV2hlbiB1cGRhdGluZyBkYXRhIHdpdGggTU1VL0QtY2FjaGUgb2ZmIHRo ZSBub3JtYWwgYXBwcm9hY2ggaXM6DQo+IMKgwqAgMSkgUmVtb3ZlIGFueSBkaXJ0eSBsaW5lcyBm cm9tIHRoZSBjYWNoZSwgb3RoZXJ3aXNlIHRoZXkgbWF5IGdldCBldmljdGVkIHdoaWxlIHVwZGF0 aW5nIHRoZSBtZW1vcnkgYW5kIG92ZXJyaWRlIGFueSB2YWx1ZSB3cml0dGVuIHdpdGggTU1VIG9m Zi4NCj4gwqDCoCAyKSBVcGRhdGUgdGhlIG1lbW9yeQ0KPiDCoMKgIDMpIFJlbW92ZSBhbnkgbGlu ZXMgdGhhdCBtYXkgaGF2ZSBiZWVuIHNwZWN1bGF0ZWQgc28gd2hlbiB5b3UgdHVybiBvbnRoZSBN TVUgYW5kIEQtY2FjaGUsIFUtYm9vdCBjYW4gb2J2ZXJzZSB0aGUgY29ycmVjdCBkYXRhLg0KPg0K PiBTdGVwIDEgaXMgb25seSBuZWNlc3NhcnkgaWYgeW91IGFyZSBnb2luZyB0byB3cml0ZSBvdXRz aWRlIG9mIHRoZSBsb2FkZWQgSW1hZ2UgKEJTUyBpcyBub3QgcGFydCBvZiBpdCkuDQo+DQo+IFlv dSBtb3N0IGxpa2VseSBhbHJlYWR5IGhhdmUgc2ltaWxhciBzdGVwcyBpbiBVLWJvb3QgZm9yIG90 aGVyIHBhcnQgb2YgdGhlIG1lbW9yeSBhY2Nlc3Mgd2l0aCBNTVUvRC1DYWNoZSBvZmYuIFNvIEkg dGhpbmsgVS1ib290IGlzIHRoZSBiZXN0IHBsYWNlIHRvIGludmFsaWRhdGUgdGhlIGNhY2hlIGJl Zm9yZSBpc3N1aW5nIHRoZSBoeXBlcmNhbGwuDQoNClllcywgSSBoYXZlIGludmFsaWRhdGVkIHRo ZSBidWZmZXJzIGFuZCBldmVyeXRoaW5nIHdvcmtzIGxpa2UgYSBjaGFybSBub3csIHRoYW5rcw0K DQpQcm9iYWJseSBteSB1c2UtY2FzZSBzaG91bGQgYmUgc29tZXdoZXJlIGRvY3VtZW50ZWQsIHNv IGFub3RoZXIgdGltZSBzb21lb25lIHN0ZXBzIGludG8gc2ltaWxhciBpc3N1ZXMgaXQgaXMgZXhw bGFpbmVkLg0KDQo+DQo+IENoZWVycywNCj4NClRoYW5rIHlvdSBmb3IgaGVscGluZywNCg0KT2xl a3NhbmRyDQo= From xen-devel-bounces@lists.xenproject.org Thu Jun 11 12:31:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 12:31:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMN0-0004JB-N5; Thu, 11 Jun 2020 12:31:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMMz-0004J6-DO for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 12:31:45 +0000 X-Inumbo-ID: 8254edb4-abdf-11ea-b516-12813bfff9fa Received: from youngberry.canonical.com (unknown [91.189.89.112]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8254edb4-abdf-11ea-b516-12813bfff9fa; Thu, 11 Jun 2020 12:31:44 +0000 (UTC) Received: from 1.general.cking.uk.vpn ([10.172.193.212] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jjMMo-0005qP-MA; Thu, 11 Jun 2020 12:31:34 +0000 From: Colin King To: Konrad Rzeszutek Wilk , Bjorn Helgaas , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , xen-devel@lists.xenproject.org, linux-pci@vger.kernel.org Subject: [PATCH] xen: remove redundant initialization of variable irq Date: Thu, 11 Jun 2020 13:31:34 +0100 Message-Id: <20200611123134.922395-1-colin.king@canonical.com> X-Mailer: git-send-email 2.27.0.rc0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Colin Ian King The variable irq is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King --- arch/x86/pci/xen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c index e3f1ca316068..9f9aad42ccff 100644 --- a/arch/x86/pci/xen.c +++ b/arch/x86/pci/xen.c @@ -62,7 +62,7 @@ static int xen_pcifront_enable_irq(struct pci_dev *dev) #ifdef CONFIG_ACPI static int xen_register_pirq(u32 gsi, int triggering, bool set_pirq) { - int rc, pirq = -1, irq = -1; + int rc, pirq = -1, irq; struct physdev_map_pirq map_irq; int shareable = 0; char *name; -- 2.27.0.rc0 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 12:36:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 12:36:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMRo-0004Tt-99; Thu, 11 Jun 2020 12:36:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMRm-0004Tn-O8 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 12:36:42 +0000 X-Inumbo-ID: 339b8696-abe0-11ea-bb8b-bc764e2007e4 Received: from mail-lf1-x141.google.com (unknown [2a00:1450:4864:20::141]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 339b8696-abe0-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 12:36:42 +0000 (UTC) Received: by mail-lf1-x141.google.com with SMTP id h188so3416893lfd.7 for ; Thu, 11 Jun 2020 05:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=f9lcP7INmNDNWV+9/EdFziyLoY0jERPcqBsPG2jPz4k=; b=mTrFArQgTEK5TxijkWGetMewTWdUyWeluJseQAcwBmtVxnl+mNYMbfuWll6Cov6Gi5 Ei1my7QqaQkbHT7+Y0If0S5Ij27srhh5ZZoI5ttRjc6i9H3H0F5TYKB2OW/30cPsmpGG glmEds4AgUilSW5OD8CLJfRnpJEiRPjuHiqsxOrXppKgz+d8e4MnqBX8mOD1HCRIptQ0 092c9LgDmbV0hgyPHHwxhRosSLfuu+4LDIs9tbZHJFxbD6T+IHzIaQfWP72aopqaiii1 anWJGDLe3VmSiO0cHBHbbdU6+5GhFrwUVzXcsO84gV17hiL0SbYSe6CVsqGbo0P87IsK q5TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=f9lcP7INmNDNWV+9/EdFziyLoY0jERPcqBsPG2jPz4k=; b=D8uFS0j+sMuz2X+NtrVr9/ER3VoHEb6hpyJTUkmFvsfJZcXL1EPPNtkh56aF2D1zUi xTeV1LvqvPGoKku9xhCPO0BA/Czsy7XDDuQm9WVekt5BnFKCQwEU5c6hmzknL0FLYI0r hWQnVvuSHE0WhRqTZq9oqZGNrrqdXdvygoDl8KhsJmY2/sQPAoX3gW6eLQGC28+jb8ss GkwQlTZgVku3tpdETpmgIFGENSLhXPWERHP5u4FBTzwLvXetaOdsvEB1PoVfDU7K3qNY wbIpbdDl2IHv3TNAnazfde2RbeQgxxuSbYWpnQ1axZ7qbq1zjJeWK5WvBZAtKYEcOqKH jD8g== X-Gm-Message-State: AOAM5312WIXetpqbi5ySiD2b51idQO8UL+rqgjQTE/s3UbZ5so210bzD IeMDqklvQJJuNeeXlogzbqUkpIHrK6TiBT0lfdA= X-Google-Smtp-Source: ABdhPJxicqV7kqXyXip+N1tdyoE/Q0gwZiwZ/cAEedHNLI18xbdZTUosbdm8Gzpp7sEXBzCFSH+boSZmWd6i7Vt1b40= X-Received: by 2002:a05:6512:31d1:: with SMTP id j17mr3967177lfe.148.1591879001060; Thu, 11 Jun 2020 05:36:41 -0700 (PDT) MIME-Version: 1.0 From: Jason Andryuk Date: Thu, 11 Jun 2020 08:36:29 -0400 Message-ID: Subject: Seabios Xen TPM check To: seabios@seabios.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Quan Xu , Stefan Berger Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, SeaBIOS commit 67643955c746 (make SeaBios compatible with Xen vTPM.) made tpm_start() exit before calling tpm_startup(). The commit message has no explanation why this change was made. Does anyone remember why it was made? The code today means SeaBIOS will not populate PCRs when running on Xen. If I revert the patch, SeaBIOS populates PCRs as one would expect. This is with a QEMU-emulated TPM backed by swtpm in TPM 1.2 mode (qemu & swtpm running in a linux stubdom). Any insight is appreciated. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Thu Jun 11 13:06:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 13:06:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMuF-00070s-K7; Thu, 11 Jun 2020 13:06:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMuE-00070n-FP for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 13:06:06 +0000 X-Inumbo-ID: 4f0db6f2-abe4-11ea-b51a-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4f0db6f2-abe4-11ea-b51a-12813bfff9fa; Thu, 11 Jun 2020 13:06:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=AV9tQ1bDV001zmsJa2JdJ89QPTOdYVa5XHEsaRAsYhw=; b=EP157dByfpSeQLb0PjLinARZBs Top/53I+9SnnFMPsHjZDr/pMXUFAxh/EYnKkWkq6FSuoXVo7TBvGvXwdvpxEJzLXjcpXtimMcFKLB Mup84u5D9W+xVmUoFZ3w2qMtQZXqYsr3EhQuHHg+rIAeioeXYl57edM2ymH3iSEZyHMk=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMuC-0004FU-CR; Thu, 11 Jun 2020 13:06:04 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjMuC-00065w-5p; Thu, 11 Jun 2020 13:06:04 +0000 Subject: Re: HYPERVISOR_console_io + CONSOLEIO_write needs COPY_flush_dcache To: Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" References: <912a84d1-ca47-9c37-06e7-28bebe696b4d@epam.com> From: Julien Grall Message-ID: Date: Thu, 11 Jun 2020 14:06:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 11/06/2020 13:18, Oleksandr Andrushchenko wrote: > > On 6/10/20 3:50 PM, Julien Grall wrote: >> On 10/06/2020 09:13, Oleksandr Andrushchenko wrote: >>> Hello, >> >> Hi, >> >>> While adding support for para-virtualized block device in u-boot >>> >>> I faced an issue with HYPERVISOR_console_io + CONSOLEIO_write. >>> >>> I tried to use the hypercall during MMU setup stage while enabling data cache >>> >>> on arm64 platform (e.g. data cache is not yet enabled) and saw in guest's console >>> >>> either old data or some sort of garbage. Printing constant strings, just like mini-os >>> >>> does on boot, works as expected. >> >> Per the hypercall ABI (see include/public/arch-arm.h) all the buffers must reside in memory which is mapped as Normal Inner Write-Back Inner-Shareable. >> >> You are passing non-cacheable memory, so the behavior you see is expected. > This is what we come up with as well >> >>> So, looking at the Xen code [1] it seems >>> >>> that we should copy guest's buffer with COPY_flush_dcache set in this case >> >> COPY_flush_dcache is only meant to be used when copy to guest memory to make sure the data reached the point of coherency in your system. It is not meant to be used when copying from guest. > Understood and agree >> >>> as (usually?) this hypercall is used in guest's code which doesn't have any >>> other means to print yet, e.g. early printk case. >> >> I have been using it after the MMU is setup > The thing is that in u-boot a lot of things happen before the MMU setup... >> but before the console is properly setup by the guest (there is a lot that can happen in Linux between the two). In my case, the flush is not necessary and would be wrong. > ... and without the flush you lose the ability to debug that code. This is not entirely correct... You have other facility in Xen to debug early code (i.e pl011, hvc 0xffxx) and doesn't require any flush. >> >> In general, the cache is never off on Arm64 because you may have system cache or, in the cache of virtualization, cacheable mapping in the hypervisor (all the memory is mapped). >> >> When updating data with MMU/D-cache off the normal approach is: >>    1) Remove any dirty lines from the cache, otherwise they may get evicted while updating the memory and override any value written with MMU off. >>    2) Update the memory >>    3) Remove any lines that may have been speculated so when you turn onthe MMU and D-cache, U-boot can obverse the correct data. >> >> Step 1 is only necessary if you are going to write outside of the loaded Image (BSS is not part of it). >> >> You most likely already have similar steps in U-boot for other part of the memory access with MMU/D-Cache off. So I think U-boot is the best place to invalidate the cache before issuing the hypercall. > > Yes, I have invalidated the buffers and everything works like a charm now, thanks > > Probably my use-case should be somewhere documented, so another time someone steps into similar issues it is explained. You would have the exact same issue if you don't use hypercalls but modify a buffer with MMU off and then expect it to read the content correctly after turning on the MMU. That's even on baremetal! (see [1]) I am afraid you have to know how the cache works when writing code that will run with MMU off. Therefore I don't think it is Xen Project to document how an architecture works. Instead this should be a tutorial for anyone wanting to write its own OS. Cheers, [1] https://www.youtube.com/watch?v=A_zCxzpxzmE -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 11 13:10:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 13:10:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMy3-0007Nh-4d; Thu, 11 Jun 2020 13:10:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMy2-0007Cv-0s for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 13:10:02 +0000 X-Inumbo-ID: db1dfb5c-abe4-11ea-b51a-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id db1dfb5c-abe4-11ea-b51a-12813bfff9fa; Thu, 11 Jun 2020 13:10:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eUvN62msFzpWs4pcQby/UhCeLE3bCKiq8E3ve1RA/VA=; b=RhsZZbZbJERinJksFOhy4m4Ozx Ljl/BkgJuZmjcnZ4sD8RSBQ7LlLDFW+SmxDgnO1FkcNSVg6t+GFhIT+w7kM0Im+TZ2Hm2r4gMVrVn MdjMuqFEPiDg72UOnkBAmc8yr+Q6+DyhpTkDBRGW1mH2UfjF9OlDN55toGfMhAosXGp4=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMxz-0004K8-Jq; Thu, 11 Jun 2020 13:09:59 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjMxz-0006KP-DH; Thu, 11 Jun 2020 13:09:59 +0000 Subject: Re: [PATCH] xen/arm: Add arm Neoverse N1 processor To: Bertrand Marquis , xen-devel@lists.xenproject.org References: <5d99ae7a1432152e25d063c634e1e7292ab988aa.1591806668.git.bertrand.marquis@arm.com> From: Julien Grall Message-ID: <6f4cf5ec-8a7e-ca82-d305-d57a083af915@xen.org> Date: Thu, 11 Jun 2020 14:09:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <5d99ae7a1432152e25d063c634e1e7292ab988aa.1591806668.git.bertrand.marquis@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: nd@arm.com, Volodymyr Babchuk , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Bertrand, On 11/06/2020 12:54, Bertrand Marquis wrote: > Add MIDR and CPU part numbers for Arm Neoverse N1 processor The MIDR and CPU part listed are only there because we need to use them for errata. This is not the list of processors we support :). So I would prefer to introduce the new macro when there is an actual use of it. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 11 13:10:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 13:10:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMyZ-0007uS-ST; Thu, 11 Jun 2020 13:10:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMyY-0007rD-2U for xen-devel@lists.xen.org; Thu, 11 Jun 2020 13:10:34 +0000 X-Inumbo-ID: e5c86fce-abe4-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e5c86fce-abe4-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 13:10:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Date:Message-Id:Subject:CC:From:To:MIME-Version: Content-Transfer-Encoding:Content-Type:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GegubXLG2U0OI3eFY7woUsGzjD01OabFpSKvvDGr0Vc=; b=LYFtHidVzd2CTp9PLHaYKZbTF4 ft4C61994eJwJQG7BG0qlQ0326TKZ1VVapaI1qt1I46OhqTKBcargZKJDvnpW4QEdN2uZ7b9FfP5s nMtrIkja7MZfHASMC6E+awd/qcjLz5R81skQWIWvopV385w5n/hPwiUxgINWSJ1EN31g=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjMyB-0004KW-4S; Thu, 11 Jun 2020 13:10:11 +0000 Received: from iwj by xenbits.xenproject.org with local (Exim 4.92) (envelope-from ) id 1jjMyB-0006OG-37; Thu, 11 Jun 2020 13:10:11 +0000 Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Subject: Xen Security Advisory 320 v2 (CVE-2020-0543) - Special Register Buffer speculative side channel Message-Id: Date: Thu, 11 Jun 2020 13:10:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Xen.org security team" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2020-0543 / XSA-320 version 2 Special Register Buffer speculative side channel UPDATES IN VERSION 2 ==================== Add a link to Intel's cross reference of affected hardware. Provide a suggested workaround for Ivy Bridge hardware, which is not receiving a microcode update. This includes a 3rd patch for each release. ISSUE DESCRIPTION ================= This issue is related to the MDS and TAA vulnerabilities. Please see https://xenbits.xen.org/xsa/advisory-297.html (MDS) and https://xenbits.xen.org/xsa/advisory-305.html (TAA) for details. Certain processor operations microarchitecturally need to read data from outside the physical core (e.g. to communicate with the random number generator). In some implementations, this operation is called a Special Register Read. In some implementations, data are staged in a single shared buffer, and a full cache line at a time is returned to the core which made the Special Register Read. On parts vulnerable to MFBDS or TAA, an attacker may be able to access stale data requested by other cores in the system. For more details, see: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00320.html https://software.intel.com/security-software-guidance/processors-affected-transient-execution-attack-mitigation-product-cpu-model IMPACT ====== An attacker, which could include a malicious untrusted user process on a trusted guest, or an untrusted guest, can sample the contents of certain off-core accesses by other cores in the system. This can include data whose use may depend on the secrecy of the value, such as data from the Random Number Generator (e.g. RDRAND/RDSEED instructions). VULNERABLE SYSTEMS ================== Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not believed to be vulnerable. Only Intel based processors are affected. Processors from other manufacturers (e.g. AMD) are not believed to be vulnerable. Please consult the Intel Security Advisory for details on the affected processors. MITIGATION ========== Disabling RDRAND (and, where applicable, RDSEED) will avoid the vulnerability. It may have other adverse consequences, such as guests generating keys with weak random numbers, or guests hanging during boot waiting for entropy. A domain (guest, dom0, or service domain) which is runs with RDRAND disabled in CPUID, and whose software conforms to normal feature detection as specified in the Intel/AMD manuals, will not be vulnerable to snooping by other domains. But such a domain *can* still potentially snoop on any domains which are still using RDRAND. This mitigation is recommended to be applied globally, due to the practical complexity of auditing all software in a VM to confirm that there are no vulnerable uses of the RDRAND/RDSEED instructions. RDRAND and RDSEED can be disabled at the host level by booting Xen with `cpuid=no-rdrand,no-rdseed`, which will hide the feature from all domains including guests and dom0. Xen 4.12 and earlier require the appropriate patch 3 below for this mechanism to work. RDRAND and RDSEED can be disabled for guests with the following setting in the VM configuration file (xl.cfg): cpuid=["host:rdrand=0,rdseed=0]" (NB it would have to be merged into any existing cpuid= setting). Xen 4.9 and earlier require the appropriate patch 3 below for this mechanism to work. RESOLUTION ========== New microcode is being released on some affected parts to work around the vulnerability. It may be available via a firmware update (consult your hardware vendor), or available for OS loading (consult your dom0 OS vendor). For Ivy Bridge hardware, which is not receiving a microcode update, see MITIGATION, above. On Xen 4.13 and later, OS microcode can be loaded at runtime. See https://xenbits.xen.org/docs/latest/admin-guide/microcode-loading.html#runtime-microcode-loading for details on the xen-ucode utility. Loading the microcode, either at boot or at runtime, suffices to mitigate the issue, as protections are active by default. The mitigations do have an impact on latency of individual RDRAND/RDSEED instructions. The patches below are for Xen, and offer boot time information, defaults selection, opt-out controls, and uniform controls for hiding the RDRAND/RDSEED instructions. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa320/xsa320-?.patch xen-unstable xsa320/xsa320-4.13-?.patch Xen 4.13.x xsa320/xsa320-4.12-?.patch Xen 4.12.x xsa320/xsa320-4.11-?.patch Xen 4.11.x xsa320/xsa320-4.10-?.patch Xen 4.10.x xsa320/xsa320-4.9-?.patch Xen 4.9.x $ sha256sum xsa320*/* 84e4f66492042b08e69b0894ea7feb20c17c89a696cf95f05a8826fba4f26355 xsa320/xsa320-1.patch 5a3a06c72d0281fa1191ba18e39b836d2748400d9bf6a59dd45447850530c88b xsa320/xsa320-2.patch fd15c8a5098ce70af85c6cf1f69f1e6b51eabfda0a0bb780b27f47a8ae44e3a2 xsa320/xsa320-3.patch 759259ef88c980363d44e11d9c272f6a4a15918e5e6bcdfe971b1ce7ea160cd9 xsa320/xsa320-4.9-1.patch ebac2c011841c55c3c1e99d9e8afc53e56e54268d379ec8b904f6bfe6a1a5045 xsa320/xsa320-4.9-2.patch 3aeade2c9bb1fe77f6c076d531378d3971aa44cdb87996bda27565fa6e707bd2 xsa320/xsa320-4.9-3.patch 5c622c74358ab21cbd27484c649f26df0f08e89ec333c346415bc51e35ba26c1 xsa320/xsa320-4.10-1.patch f112e34a6a4564a043926fc255a15c7e319001bd023a97ae2947228024e1c306 xsa320/xsa320-4.10-2.patch 1ff6f34840ddb23b7f9bad5e2a1a5cf5246a55219ce7f686f2d80b3dc55e2960 xsa320/xsa320-4.10-3.patch f24b51292be0cb5de80c6eff0b26983629dd48cc39ae5a331e2e38e15a6cf712 xsa320/xsa320-4.11-1.patch 03579810eaf2e9eeb1a82de4b50ff5c4b01e60b30ccf7609c9e3378ef576d81e xsa320/xsa320-4.11-2.patch fa4bcb5422a43395bfe57b8e324b80e447b004eb24360b78343577de0f247067 xsa320/xsa320-4.11-3.patch 282537ffe2fd4332c0e061ddc537bea3e135a7bbd9253ec298becb49047323cf xsa320/xsa320-4.12-1.patch e4417429297354c233e8f5c261aff4888aae602f8c68897c09b16ea1aa44b1ca xsa320/xsa320-4.12-2.patch dd374e6c11c54c4077895132b8cc5771d3193df2febde643fcef94f973ee409e xsa320/xsa320-4.12-3.patch 611f2ab1a1c67e04767188d9803b6afd7d304e81a5b4f1eb1744d3e8a68ced66 xsa320/xsa320-4.13-1.patch cd1bc0071e72e2342ff4508ea3d937988694f4c03506b3afb3184f7d81aa1c86 xsa320/xsa320-4.13-2.patch 1fe0437059bac1fcc4be44ec3c9f9b53f4c5568c8f02c3f2aa2e452febe39cd1 xsa320/xsa320-4.13-3.patch $ NOTE REGARDING LACK OF EMBARGO ============================== Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAl7iLP8MHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZYSMIAISQRxbfSDYpTKAObAGn7Jhv4rGM4C0gYagFWKxb eLuhvWZN49uPuyIfsO8WfZxAQJTP2hEDNd4ncFYwS7JbD/F/RCsYFgiasw/aqCUX 9vEkRtrvD7XvIe0DWAjHUrvaFvnjI/vl03D3kxQw15eDPXU8pQMPrfva6W1PrQfv +b+aQHiawR6MPawCraK3kfCs1dTEnrkH+vL5h+nnEyB34ciTG+Z1g3Rhx7GMh6+7 tb9VLOPZMRvvCRii3pRBolcT0MmZAcakbBxCixMDo7bSEaw3G7Zro2RO9MvvsoFF r1Pa8IC8kVTWQTi8CYS46E1TvQ7yr86ERejaFQs0fk6vxhI= =N8eC -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyBi L2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYwppbmRleCAyZDRk OTYzOWQ2Li5iN2MyYjk5Mjk4IDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVu LWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21t YW5kLWxpbmUucGFuZG9jCkBAIC01MDQsMTAgKzUwNCwxMCBAQCBhY2NvdW50 aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXMgZW51bWVyYXRlZCB2 aWEgQ1BVSUQuCiAKIEN1cnJlbnRseSBhY2NlcHRlZDoKIAotVGhlIFNwZWN1 bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVhdHVyZXMgYG1kLWNsZWFyYCwg YGlicnNiYCwgYHN0aWJwYCwgYGlicGJgLAotYGwxZC1mbHVzaGAgYW5kIGBz c2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0IGlmIGF2YWlsYWJsZSBhbmQgYXBw bGljYWJsZS4gIFRoZXkgY2FuCi1iZSBpZ25vcmVkLCBlLmcuIGBuby1pYnJz YmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3b24ndCB1c2UgdGhlbSBpdHNlbGYs IGFuZAotd29uJ3Qgb2ZmZXIgdGhlbSB0byBndWVzdHMuCitUaGUgU3BlY3Vs YXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgc3JiZHMtY3RybGAs IGBtZC1jbGVhcmAsIGBpYnJzYmAsCitgc3RpYnBgLCBgaWJwYmAsIGBsMWQt Zmx1c2hgIGFuZCBgc3NiZGAgYXJlIHVzZWQgYnkgZGVmYXVsdCBpZiBhdmFp bGFibGUgYW5kCithcHBsaWNhYmxlLiAgVGhleSBjYW4gYmUgaWdub3JlZCwg ZS5nLiBgbm8taWJyc2JgLCBhdCB3aGljaCBwb2ludCBYZW4gd29uJ3QKK3Vz ZSB0aGVtIGl0c2VsZiwgYW5kIHdvbid0IG9mZmVyIHRoZW0gdG8gZ3Vlc3Rz LgogCiBgcmRyYW5kYCBjYW4gYmUgdXNlZCB0byBvdmVycmlkZSB0aGUgZGVm YXVsdCBkaXNhYmxpbmcgb2YgdGhlIGZlYXR1cmUgb24gY2VydGFpbgogQU1E IHN5c3RlbXMuICBJdHMgbmVnYXRpdmUgZm9ybSBjYW4gb2YgY291cnNlIGFs c28gYmUgdXNlZCB0byBzdXBwcmVzcyB1c2UgYW5kCmRpZmYgLS1naXQgYS90 b29scy9saWJ4bC9saWJ4bF9jcHVpZC5jIGIvdG9vbHMvbGlieGwvbGlieGxf Y3B1aWQuYwppbmRleCBjMzFkZDFmMzA0Li40ZTQ4NTJkZGViIDEwMDY0NAot LS0gYS90b29scy9saWJ4bC9saWJ4bF9jcHVpZC5jCisrKyBiL3Rvb2xzL2xp YnhsL2xpYnhsX2NwdWlkLmMKQEAgLTIxNCw2ICsyMTQsNyBAQCBpbnQgbGli eGxfY3B1aWRfcGFyc2VfY29uZmlnKGxpYnhsX2NwdWlkX3BvbGljeV9saXN0 ICpjcHVpZCwgY29uc3QgY2hhciogc3RyKQogCiAgICAgICAgIHsiYXZ4NTEy LTR2bm5pdyIsMHgwMDAwMDAwNywgIDAsIENQVUlEX1JFR19FRFgsICAyLCAg MX0sCiAgICAgICAgIHsiYXZ4NTEyLTRmbWFwcyIsMHgwMDAwMDAwNywgIDAs IENQVUlEX1JFR19FRFgsICAzLCAgMX0sCisgICAgICAgIHsic3JiZHMtY3Ry bCIsICAgMHgwMDAwMDAwNywgIDAsIENQVUlEX1JFR19FRFgsICA5LCAgMX0s CiAgICAgICAgIHsibWQtY2xlYXIiLCAgICAgMHgwMDAwMDAwNywgIDAsIENQ VUlEX1JFR19FRFgsIDEwLCAgMX0sCiAgICAgICAgIHsic2VyaWFsaXplIiwg ICAgMHgwMDAwMDAwNywgIDAsIENQVUlEX1JFR19FRFgsIDE0LCAgMX0sCiAg ICAgICAgIHsiY2V0LWlidCIsICAgICAgMHgwMDAwMDAwNywgIDAsIENQVUlE X1JFR19FRFgsIDIwLCAgMX0sCmRpZmYgLS1naXQgYS90b29scy9taXNjL3hl bi1jcHVpZC5jIGIvdG9vbHMvbWlzYy94ZW4tY3B1aWQuYwppbmRleCA4NTc4 MDc3NTQ1Li44ZDhmMzUzMmEyIDEwMDY0NAotLS0gYS90b29scy9taXNjL3hl bi1jcHVpZC5jCisrKyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKQEAgLTE2 MCw2ICsxNjAsNyBAQCBzdGF0aWMgY29uc3QgY2hhciAqY29uc3Qgc3RyXzdk MFszMl0gPQogICAgIFsgMl0gPSAiYXZ4NTEyXzR2bm5pdyIsIFsgM10gPSAi YXZ4NTEyXzRmbWFwcyIsCiAgICAgWyA0XSA9ICJmc3JtIiwKIAorICAgIC8q ICA4ICovICAgICAgICAgICAgICAgIFsgOV0gPSAic3JiZHMtY3RybCIsCiAg ICAgWzEwXSA9ICJtZC1jbGVhciIsCiAgICAgLyogMTIgKi8gICAgICAgICAg ICAgICAgWzEzXSA9ICJ0c3gtZm9yY2UtYWJvcnQiLAogICAgIFsxNF0gPSAi c2VyaWFsaXplIiwKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tc3IuYyBi L3hlbi9hcmNoL3g4Ni9tc3IuYwppbmRleCBkY2FjYWU1OGRlLi4wYmZiNTgz OWIyIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvbXNyLmMKKysrIGIveGVu L2FyY2gveDg2L21zci5jCkBAIC0xNjcsNiArMTY3LDcgQEAgaW50IGd1ZXN0 X3JkbXNyKHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90 ICp2YWwpCiAgICAgY2FzZSBNU1JfQ09SRV9DQVBBQklMSVRJRVM6CiAgICAg Y2FzZSBNU1JfVFNYX0ZPUkNFX0FCT1JUOgogICAgIGNhc2UgTVNSX1RTWF9D VFJMOgorICAgIGNhc2UgTVNSX01DVV9PUFRfQ1RSTDoKICAgICBjYXNlIE1T Ul9VX0NFVDoKICAgICBjYXNlIE1TUl9TX0NFVDoKICAgICBjYXNlIE1TUl9Q TDBfU1NQIC4uLiBNU1JfSU5URVJSVVBUX1NTUF9UQUJMRToKQEAgLTMyNyw2 ICszMjgsNyBAQCBpbnQgZ3Vlc3Rfd3Jtc3Ioc3RydWN0IHZjcHUgKnYsIHVp bnQzMl90IG1zciwgdWludDY0X3QgdmFsKQogICAgIGNhc2UgTVNSX1RFU1Rf Q1RSTDoKICAgICBjYXNlIE1TUl9UU1hfRk9SQ0VfQUJPUlQ6CiAgICAgY2Fz ZSBNU1JfVFNYX0NUUkw6CisgICAgY2FzZSBNU1JfTUNVX09QVF9DVFJMOgog ICAgIGNhc2UgTVNSX1VfQ0VUOgogICAgIGNhc2UgTVNSX1NfQ0VUOgogICAg IGNhc2UgTVNSX1BMMF9TU1AgLi4uIE1TUl9JTlRFUlJVUFRfU1NQX1RBQkxF OgpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jIGIveGVu L2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IGE5NGJlMmQ1OTQuLmE1ZGZm ZjgwYzUgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwor KysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTMxMiwxMiArMzEy LDEzIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0g aW5kX3RodW5rIHRodW5rLCB1aW50NjRfdCBjYXBzKQogICAgIHByaW50aygi U3BlY3VsYXRpdmUgbWl0aWdhdGlvbiBmYWNpbGl0aWVzOlxuIik7CiAKICAg ICAvKiBIYXJkd2FyZSBmZWF0dXJlcyB3aGljaCBwZXJ0YWluIHRvIHNwZWN1 bGF0aXZlIG1pdGlnYXRpb25zLiAqLwotICAgIHByaW50aygiICBIYXJkd2Fy ZSBmZWF0dXJlczolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAor ICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMl cyVzJXMlcyVzJXMlcyVzJXNcbiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1 ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNCKSkgPyAiIElCUlMvSUJQQiIg OiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZF QVRVUkVfU1RJQlApKSA/ICIgU1RJQlAiICAgICA6ICIiLAogICAgICAgICAg ICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9MMURfRkxVU0gp KSA/ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICAoXzdkMCAmIGNw dWZlYXRfbWFzayhYODZfRkVBVFVSRV9TU0JEKSkgID8gIiBTU0JEIiAgICAg IDogIiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1ZmVhdF9tYXNrKFg4Nl9G RUFUVVJFX01EX0NMRUFSKSkgPyAiIE1EX0NMRUFSIiA6ICIiLAorICAgICAg ICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TUkJEU19D VFJMKSkgPyAiIFNSQkRTX0NUUkwiIDogIiIsCiAgICAgICAgICAgIChlOGIg ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUEIpKSAgPyAiIElCUEIi ICAgICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfSUJS U19BTEwpICAgICAgICAgICAgICA/ICIgSUJSU19BTEwiICA6ICIiLAogICAg ICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19SRENMX05PKSAgICAgICAgICAg ICAgID8gIiBSRENMX05PIiAgIDogIiIsCmRpZmYgLS1naXQgYS94ZW4vaW5j bHVkZS9hc20teDg2L21zci1pbmRleC5oIGIveGVuL2luY2x1ZGUvYXNtLXg4 Ni9tc3ItaW5kZXguaAppbmRleCBhNGRjNDhmNTFmLi5iMzI4YTQ3ZWQ4IDEw MDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRleC5oCisr KyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4LmgKQEAgLTY2LDYg KzY2LDkgQEAKICNkZWZpbmUgIFRTWF9DVFJMX1JUTV9ESVNBQkxFICAgICAg ICAgICAgICAgKF9BQygxLCBVTEwpIDw8ICAwKQogI2RlZmluZSAgVFNYX0NU UkxfQ1BVSURfQ0xFQVIgICAgICAgICAgICAgICAoX0FDKDEsIFVMTCkgPDwg IDEpCiAKKyNkZWZpbmUgTVNSX01DVV9PUFRfQ1RSTCAgICAgICAgICAgICAg ICAgICAgMHgwMDAwMDEyMworI2RlZmluZSAgTUNVX09QVF9DVFJMX1JOR0RT X01JVEdfRElTICAgICAgICAoX0FDKDEsIFVMTCkgPDwgIDApCisKICNkZWZp bmUgTVNSX1VfQ0VUICAgICAgICAgICAgICAgICAgICAgICAgICAgMHgwMDAw MDZhMAogI2RlZmluZSBNU1JfU19DRVQgICAgICAgICAgICAgICAgICAgICAg ICAgICAweDAwMDAwNmEyCiAjZGVmaW5lICBDRVRfU0hTVEtfRU4gICAgICAg ICAgICAgICAgICAgICAgIChfQUMoMSwgVUxMKSA8PCAgMCkKZGlmZiAtLWdp dCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0 LmggYi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNl dC5oCmluZGV4IDgzNDdhNDA1YWMuLjVjYTM1ZDlkOTcgMTAwNjQ0Ci0tLSBh L3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgK KysrIGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVz ZXQuaApAQCAtMjU5LDYgKzI1OSw3IEBAIFhFTl9DUFVGRUFUVVJFKEFNRF9Q UElOLCAgICAgIDgqMzIrMjMpIC8qICAgUHJvdGVjdGVkIFByb2Nlc3NvciBJ bnZlbnRvcnkgTnVtYmVyCiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl cywgQ1BVSUQgbGV2ZWwgMHgwMDAwMDAwNzowLmVkeCwgd29yZCA5ICovCiBY RU5fQ1BVRkVBVFVSRShBVlg1MTJfNFZOTklXLCA5KjMyKyAyKSAvKkEgIEFW WDUxMiBOZXVyYWwgTmV0d29yayBJbnN0cnVjdGlvbnMgKi8KIFhFTl9DUFVG RUFUVVJFKEFWWDUxMl80Rk1BUFMsIDkqMzIrIDMpIC8qQSAgQVZYNTEyIE11 bHRpcGx5IEFjY3VtdWxhdGlvbiBTaW5nbGUgUHJlY2lzaW9uICovCitYRU5f Q1BVRkVBVFVSRShTUkJEU19DVFJMLCAgICA5KjMyKyA5KSAvKiAgIE1TUl9N Q1VfT1BUX0NUUkwgYW5kIFJOR0RTX01JVEdfRElTLiAqLwogWEVOX0NQVUZF QVRVUkUoTURfQ0xFQVIsICAgICAgOSozMisxMCkgLypBICBWRVJXIGNsZWFy cyBtaWNyb2FyY2hpdGVjdHVyYWwgYnVmZmVycyAqLwogWEVOX0NQVUZFQVRV UkUoVFNYX0ZPUkNFX0FCT1JULCA5KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNF X0FCT1JULlJUTV9BQk9SVCAqLwogWEVOX0NQVUZFQVRVUkUoU0VSSUFMSVpF LCAgICAgOSozMisxNCkgLyphICBTRVJJQUxJWkUgaW5zbiAqLwo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5w YW5kb2MgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKaW5k ZXggYjdjMmI5OTI5OC4uMWE2OWM2MDEzOSAxMDA2NDQKLS0tIGEvZG9jcy9t aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCisrKyBiL2RvY3MvbWlzYy94 ZW4tY29tbWFuZC1saW5lLnBhbmRvYwpAQCAtMjA0OCw3ICsyMDQ4LDcgQEAg QnkgZGVmYXVsdCBTU0JEIHdpbGwgYmUgbWl0aWdhdGVkIGF0IHJ1bnRpbWUg KGkuZSBgc3NiZD1ydW50aW1lYCkuCiAjIyMgc3BlYy1jdHJsICh4ODYpCiA+ IGA9IExpc3Qgb2YgWyA8Ym9vbD4sIHhlbj08Ym9vbD4sIHtwdixodm0sbXNy LXNjLHJzYixtZC1jbGVhcn09PGJvb2w+LAogPiAgICAgICAgICAgICAgYnRp LXRodW5rPXJldHBvbGluZXxsZmVuY2V8am1wLCB7aWJycyxpYnBiLHNzYmQs ZWFnZXItZnB1LAotPiAgICAgICAgICAgICAgbDFkLWZsdXNoLGJyYW5jaC1o YXJkZW59PTxib29sPiBdYAorPiAgICAgICAgICAgICAgbDFkLWZsdXNoLGJy YW5jaC1oYXJkZW4sc3JiLWxvY2t9PTxib29sPiBdYAogCiBDb250cm9scyBm b3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9uIHNpZGVjaGFubmVsIG1pdGlnYXRp b25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3aWxsIHBpY2sgdGhlIG1vc3QgYXBw cm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFzZWQgb24gY29tcGlsZWQgaW4gc3Vw cG9ydCwKQEAgLTIxMjUsNiArMjEyNSwxMiBAQCBJZiBYZW4gaXMgY29tcGls ZWQgd2l0aCBgQ09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9CUkFOQ0hgLCB0 aGUKIHNwZWN1bGF0aW9uIGJhcnJpZXJzIHRvIHByb3RlY3Qgc2VsZWN0ZWQg Y29uZGl0aW9uYWwgYnJhbmNoZXMuICBCeSBkZWZhdWx0LAogWGVuIHdpbGwg ZW5hYmxlIHRoaXMgbWl0aWdhdGlvbi4KIAorT24gaGFyZHdhcmUgc3VwcG9y dGluZyBTUkJEU19DVFJMLCB0aGUgYHNyYi1sb2NrPWAgb3B0aW9uIGNhbiBi ZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2ZW50IFhlbiBmcm9tIHByb3RlY3Qg dGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVmZmVyIGZyb20gbGVha2luZyBzdGFs ZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVuIHdpbGwgZW5hYmxlIHRoaXMgbWl0 aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRzIHdoZXJlIE1EUworaXMgZml4ZWQg YW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0ZWQgKGluIHdoaWNoIGNhc2UsIHRo ZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5vCit3YXkgZm9yIGFuIGF0dGFja2Vy IHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0YSkuCisKICMjIyBzeW5jX2NvbnNv bGUKID4gYD0gPGJvb2xlYW4+YAogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94 ODYvYWNwaS9wb3dlci5jIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpp bmRleCAwY2RhMzYyMDQ1Li44ZjljZmU5ZjMyIDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvYWNwaS9wb3dlci5jCisrKyBiL3hlbi9hcmNoL3g4Ni9hY3Bp L3Bvd2VyLmMKQEAgLTI5Niw2ICsyOTYsOSBAQCBzdGF0aWMgaW50IGVudGVy X3N0YXRlKHUzMiBzdGF0ZSkKICAgICBjaS0+c3BlY19jdHJsX2ZsYWdzIHw9 IChkZWZhdWx0X3NwZWNfY3RybF9mbGFncyAmIFNDRl9pc3Rfd3Jtc3IpOwog ICAgIHNwZWNfY3RybF9leGl0X2lkbGUoY2kpOwogCisgICAgaWYgKCBib290 X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgICAgICB3 cm1zcmwoTVNSX01DVV9PUFRfQ1RSTCwgZGVmYXVsdF94ZW5fbWN1X29wdF9j dHJsKTsKKwogICAgIC8qIChyZSlpbml0aWFsaXNlIFNZU0NBTEwvU1lTRU5U RVIgc3RhdGUsIGFtb25nc3Qgb3RoZXIgdGhpbmdzLiAqLwogICAgIHBlcmNw dV90cmFwc19pbml0KCk7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9z bXBib290LmMgYi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCmluZGV4IDEzYjNk YWRlOWMuLmJhOGJjOTRjZjUgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9z bXBib290LmMKKysrIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwpAQCAtMzcy LDEyICszNzIsMTQgQEAgdm9pZCBzdGFydF9zZWNvbmRhcnkodm9pZCAqdW51 c2VkKQogICAgIG1pY3JvY29kZV91cGRhdGVfb25lKGZhbHNlKTsKIAogICAg IC8qCi0gICAgICogSWYgTVNSX1NQRUNfQ1RSTCBpcyBhdmFpbGFibGUsIGFw cGx5IFhlbidzIGRlZmF1bHQgc2V0dGluZyBhbmQgZGlzY2FyZAotICAgICAq IGFueSBmaXJtd2FyZSBzZXR0aW5ncy4gIE5vdGU6IE1TUl9TUEVDX0NUUkwg bWF5IG9ubHkgYmVjb21lIGF2YWlsYWJsZQotICAgICAqIGFmdGVyIGxvYWRp bmcgbWljcm9jb2RlLgorICAgICAqIElmIGFueSBzcGVjdWxhdGl2ZSBjb250 cm9sIE1TUnMgYXJlIGF2YWlsYWJsZSwgYXBwbHkgWGVuJ3MgZGVmYXVsdAor ICAgICAqIHNldHRpbmdzLiAgTm90ZTogVGhlc2UgTVNScyBtYXkgb25seSBi ZWNvbWUgYXZhaWxhYmxlIGFmdGVyIGxvYWRpbmcKKyAgICAgKiBtaWNyb2Nv ZGUuCiAgICAgICovCiAgICAgaWYgKCBib290X2NwdV9oYXMoWDg2X0ZFQVRV UkVfSUJSU0IpICkKICAgICAgICAgd3Jtc3JsKE1TUl9TUEVDX0NUUkwsIGRl ZmF1bHRfeGVuX3NwZWNfY3RybCk7CisgICAgaWYgKCBib290X2NwdV9oYXMo WDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgICAgICB3cm1zcmwoTVNS X01DVV9PUFRfQ1RSTCwgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsKTsKIAog ICAgIHRzeF9pbml0KCk7IC8qIE5lZWRzIG1pY3JvY29kZS4gIE1heSBjaGFu Z2UgSExFL1JUTSBmZWF0dXJlIGJpdHMuICovCiAKZGlmZiAtLWdpdCBhL3hl bi9hcmNoL3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0 cmwuYwppbmRleCBhNWRmZmY4MGM1Li5jOWY3OGVhZDYyIDEwMDY0NAotLS0g YS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2 L3NwZWNfY3RybC5jCkBAIC02NSw2ICs2NSw5IEBAIHN0YXRpYyB1bnNpZ25l ZCBpbnQgX19pbml0ZGF0YSBsMWRfbWF4cGh5c2FkZHI7CiBzdGF0aWMgYm9v bCBfX2luaXRkYXRhIGNwdV9oYXNfYnVnX21zYmRzX29ubHk7IC8qID0+IG1p bmltYWwgSFQgaW1wYWN0LiAqLwogc3RhdGljIGJvb2wgX19pbml0ZGF0YSBj cHVfaGFzX2J1Z19tZHM7IC8qIEFueSBvdGhlciBNe0xQLFNCLEZCfURTIGNv bWJpbmF0aW9uLiAqLwogCitzdGF0aWMgaW50OF90IF9faW5pdGRhdGEgb3B0 X3NyYl9sb2NrID0gLTE7Cit1aW50NjRfdCBfX3JlYWRfbW9zdGx5IGRlZmF1 bHRfeGVuX21jdV9vcHRfY3RybDsKKwogc3RhdGljIGludCBfX2luaXQgcGFy c2Vfc3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiB7CiAgICAgY29uc3QgY2hh ciAqc3M7CkBAIC0xMTIsNiArMTE1LDcgQEAgc3RhdGljIGludCBfX2luaXQg cGFyc2Vfc3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBv cHRfc3NiZCA9IGZhbHNlOwogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9 IDA7CiAgICAgICAgICAgICBvcHRfYnJhbmNoX2hhcmRlbiA9IGZhbHNlOwor ICAgICAgICAgICAgb3B0X3NyYl9sb2NrID0gMDsKICAgICAgICAgfQogICAg ICAgICBlbHNlIGlmICggdmFsID4gMCApCiAgICAgICAgICAgICByYyA9IC1F SU5WQUw7CkBAIC0xNzgsNiArMTgyLDggQEAgc3RhdGljIGludCBfX2luaXQg cGFyc2Vfc3BlY19jdHJsKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBv cHRfbDFkX2ZsdXNoID0gdmFsOwogICAgICAgICBlbHNlIGlmICggKHZhbCA9 IHBhcnNlX2Jvb2xlYW4oImJyYW5jaC1oYXJkZW4iLCBzLCBzcykpID49IDAg KQogICAgICAgICAgICAgb3B0X2JyYW5jaF9oYXJkZW4gPSB2YWw7CisgICAg ICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigic3JiLWxvY2si LCBzLCBzcykpID49IDAgKQorICAgICAgICAgICAgb3B0X3NyYl9sb2NrID0g dmFsOwogICAgICAgICBlbHNlCiAgICAgICAgICAgICByYyA9IC1FSU5WQUw7 CiAKQEAgLTM0MSw3ICszNDcsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJp bnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0X3QgY2Fw cykKICAgICAgICAgICAgICAgICJcbiIpOwogCiAgICAgLyogU2V0dGluZ3Mg Zm9yIFhlbidzIHByb3RlY3Rpb24sIGlycmVzcGVjdGl2ZSBvZiBndWVzdHMu ICovCi0gICAgcHJpbnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVz LCBTUEVDX0NUUkw6ICVzJXMlcywgT3RoZXI6JXMlcyVzJXNcbiIsCisgICAg cHJpbnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVzLCBTUEVDX0NU Ukw6ICVzJXMlcywgT3RoZXI6JXMlcyVzJXMlc1xuIiwKICAgICAgICAgICAg dGh1bmsgPT0gVEhVTktfTk9ORSAgICAgID8gIk4vQSIgOgogICAgICAgICAg ICB0aHVuayA9PSBUSFVOS19SRVRQT0xJTkUgPyAiUkVUUE9MSU5FIiA6CiAg ICAgICAgICAgIHRodW5rID09IFRIVU5LX0xGRU5DRSAgICA/ICJMRkVOQ0Ui IDoKQEAgLTM1Miw2ICszNTgsOCBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJp bnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0X3QgY2Fw cykKICAgICAgICAgICAgKGRlZmF1bHRfeGVuX3NwZWNfY3RybCAmIFNQRUNf Q1RSTF9TU0JEKSAgPyAiIFNTQkQrIiA6ICIgU1NCRC0iLAogICAgICAgICAg ICAhKGNhcHMgJiBBUkNIX0NBUFNfVFNYX0NUUkwpICAgICAgICAgICAgICA/ ICIiIDoKICAgICAgICAgICAgKG9wdF90c3ggJiAxKSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPyAiIFRTWCsiIDogIiBUU1gtIiwKKyAgICAgICAg ICAgIWJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSAgICAg PyAiIiA6CisgICAgICAgICAgIG9wdF9zcmJfbG9jayAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgID8gIiBTUkJfTE9DSysiIDogIiBTUkJfTE9DSy0i LAogICAgICAgICAgICBvcHRfaWJwYiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA/ICIgSUJQQiIgIDogIiIsCiAgICAgICAgICAgIG9wdF9s MWRfZmx1c2ggICAgICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBMMURf RkxVU0giIDogIiIsCiAgICAgICAgICAgIG9wdF9tZF9jbGVhcl9wdiB8fCBv cHRfbWRfY2xlYXJfaHZtICAgICAgID8gIiBWRVJXIiAgOiAiIiwKQEAgLTEx NTcsNiArMTE2NSwzNCBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1bGF0aW9u X21pdGlnYXRpb25zKHZvaWQpCiAgICAgICAgIHRzeF9pbml0KCk7CiAgICAg fQogCisgICAgLyogQ2FsY3VsYXRlIHN1aXRhYmxlIGRlZmF1bHRzIGZvciBN U1JfTUNVX09QVF9DVFJMICovCisgICAgaWYgKCBib290X2NwdV9oYXMoWDg2 X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgIHsKKyAgICAgICAgdWludDY0 X3QgdmFsOworCisgICAgICAgIHJkbXNybChNU1JfTUNVX09QVF9DVFJMLCB2 YWwpOworCisgICAgICAgIC8qCisgICAgICAgICAqIE9uIHNvbWUgU1JCRFMt YWZmZWN0ZWQgaGFyZHdhcmUsIGl0IG1heSBiZSBzYWZlIHRvIHJlbGF4IHNy Yi1sb2NrCisgICAgICAgICAqIGJ5IGRlZmF1bHQuCisgICAgICAgICAqCisg ICAgICAgICAqIE9uIHBhcnRzIHdoaWNoIGVudW1lcmF0ZSBNRFNfTk8gYW5k IG5vdCBUQUFfTk8sIFRTWCBpcyB0aGUgb25seSB3YXkKKyAgICAgICAgICog dG8gYWNjZXNzIHRoZSBGaWxsIEJ1ZmZlci4gIElmIFRTWCBpc24ndCBhdmFp bGFibGUgKGluYy4gU0tVCisgICAgICAgICAqIHJlYXNvbnMgb24gc29tZSBt b2RlbHMpLCBvciBUU1ggaXMgZXhwbGljaXRseSBkaXNhYmxlZCwgdGhlbiB0 aGVyZQorICAgICAgICAgKiBpcyBubyBuZWVkIGZvciB0aGUgZXh0cmEgb3Zl cmhlYWQgdG8gcHJvdGVjdCBSRFJBTkQvUkRTRUVELgorICAgICAgICAgKi8K KyAgICAgICAgaWYgKCBvcHRfc3JiX2xvY2sgPT0gLTEgJiYKKyAgICAgICAg ICAgICAoY2FwcyAmIChBUkNIX0NBUFNfTURTX05PfEFSQ0hfQ0FQU19UQUFf Tk8pKSA9PSBBUkNIX0NBUFNfTURTX05PICYmCisgICAgICAgICAgICAgKCFj cHVfaGFzX2hsZSB8fCAoKGNhcHMgJiBBUkNIX0NBUFNfVFNYX0NUUkwpICYm IG9wdF90c3ggPT0gMCkpICkKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9 IDA7CisKKyAgICAgICAgdmFsICY9IH5NQ1VfT1BUX0NUUkxfUk5HRFNfTUlU R19ESVM7CisgICAgICAgIGlmICggIW9wdF9zcmJfbG9jayApCisgICAgICAg ICAgICB2YWwgfD0gTUNVX09QVF9DVFJMX1JOR0RTX01JVEdfRElTOworCisg ICAgICAgIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCA9IHZhbDsKKyAgICB9 CisKICAgICBwcmludF9kZXRhaWxzKHRodW5rLCBjYXBzKTsKIAogICAgIC8q CkBAIC0xMTg4LDYgKzEyMjQsOSBAQCB2b2lkIF9faW5pdCBpbml0X3NwZWN1 bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAKICAgICAgICAgd3Jtc3JsKE1T Ul9TUEVDX0NUUkwsIGJzcF9kZWxheV9zcGVjX2N0cmwgPyAwIDogZGVmYXVs dF94ZW5fc3BlY19jdHJsKTsKICAgICB9CisKKyAgICBpZiAoIGJvb3RfY3B1 X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSApCisgICAgICAgIHdybXNy bChNU1JfTUNVX09QVF9DVFJMLCBkZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmwp OwogfQogCiBzdGF0aWMgdm9pZCBfX2luaXQgX19tYXliZV91bnVzZWQgYnVp bGRfYXNzZXJ0aW9ucyh2b2lkKQpkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUv YXNtLXg4Ni9zcGVjX2N0cmwuaCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvc3Bl Y19jdHJsLmgKaW5kZXggOWNhZWNkZGZlYy4uYjI1MmJiODYzMSAxMDA2NDQK LS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmwuaAorKysgYi94 ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oCkBAIC01NCw2ICs1NCw4 IEBAIGV4dGVybiBpbnQ4X3Qgb3B0X3B2X2wxdGZfaHdkb20sIG9wdF9wdl9s MXRmX2RvbXU7CiAgKi8KIGV4dGVybiBwYWRkcl90IGwxdGZfYWRkcl9tYXNr LCBsMXRmX3NhZmVfbWFkZHI7CiAKK2V4dGVybiB1aW50NjRfdCBkZWZhdWx0 X3hlbl9tY3Vfb3B0X2N0cmw7CisKIHN0YXRpYyBpbmxpbmUgdm9pZCBpbml0 X3NoYWRvd19zcGVjX2N0cmxfc3RhdGUodm9pZCkKIHsKICAgICBzdHJ1Y3Qg Y3B1X2luZm8gKmluZm8gPSBnZXRfY3B1X2luZm8oKTsK --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-3.patch" Content-Disposition: attachment; filename="xsa320/xsa320-3.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogVXBkYXRlIGRvY3Mgd2l0aCBT UkJEUyB3b3JrYXJvdW5kCgpSRFJBTkQvUkRTRUVEIGNhbiBiZSBoaWRkZW4g dXNpbmcgY3B1aWQ9IHRvIG1pdGlnYXRlIFNSQkRTIGlmIG1pY3JvY29kZQpp c24ndCBhdmFpbGFibGUuCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENW RS0yMDIwLTA1NDMuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxh bmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpBY2tlZC1ieTogSnVsaWVuIEdy YWxsIDxqZ3JhbGxAYW1hem9uLmNvbT4KCmRpZmYgLS1naXQgYS9kb2NzL21p c2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MgYi9kb2NzL21pc2MveGVuLWNv bW1hbmQtbGluZS5wYW5kb2MKaW5kZXggMWE2OWM2MDEzOS4uZmRlNzQ5YzY2 OSAxMDA2NDQKLS0tIGEvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFu ZG9jCisrKyBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYwpA QCAtNTAyLDE2ICs1MDIsMjEgQEAgY2hvaWNlIG9mIGBkb20wLWtlcm5lbGAg aXMgZGVwcmVjYXRlZCBhbmQgbm90IHN1cHBvcnRlZCBieSBhbGwgRG9tMCBr ZXJuZWxzLgogVGhpcyBvcHRpb24gYWxsb3dzIGZvciBmaW5lIHR1bmluZyBv ZiB0aGUgZmFjaWxpdGllcyBYZW4gd2lsbCB1c2UsIGFmdGVyCiBhY2NvdW50 aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXMgZW51bWVyYXRlZCB2 aWEgQ1BVSUQuCiAKK1VubGVzcyBvdGhlcndpc2Ugbm90ZWQsIG9wdGlvbnMg b25seSBoYXZlIGFueSBlZmZlY3QgaW4gdGhlaXIgbmVnYXRpdmUgZm9ybSwK K3RvIGhpZGUgdGhlIG5hbWVkIGZlYXR1cmUocykuICBJZ25vcmluZyBhIGZl YXR1cmUgdXNpbmcgdGhpcyBtZWNoYW5pc20gd2lsbAorY2F1c2UgWGVuIG5v dCB0byB1c2UgdGhlIGZlYXR1cmUsIG5vciBvZmZlciB0aGVtIGFzIHVzYWJs ZSB0byBndWVzdHMuCisKIEN1cnJlbnRseSBhY2NlcHRlZDoKIAogVGhlIFNw ZWN1bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVhdHVyZXMgYHNyYmRzLWN0 cmxgLCBgbWQtY2xlYXJgLCBgaWJyc2JgLAogYHN0aWJwYCwgYGlicGJgLCBg bDFkLWZsdXNoYCBhbmQgYHNzYmRgIGFyZSB1c2VkIGJ5IGRlZmF1bHQgaWYg YXZhaWxhYmxlIGFuZAotYXBwbGljYWJsZS4gIFRoZXkgY2FuIGJlIGlnbm9y ZWQsIGUuZy4gYG5vLWlicnNiYCwgYXQgd2hpY2ggcG9pbnQgWGVuIHdvbid0 Ci11c2UgdGhlbSBpdHNlbGYsIGFuZCB3b24ndCBvZmZlciB0aGVtIHRvIGd1 ZXN0cy4KK2FwcGxpY2FibGUuICBUaGV5IGNhbiBhbGwgYmUgaWdub3JlZC4K IAotYHJkcmFuZGAgY2FuIGJlIHVzZWQgdG8gb3ZlcnJpZGUgdGhlIGRlZmF1 bHQgZGlzYWJsaW5nIG9mIHRoZSBmZWF0dXJlIG9uIGNlcnRhaW4KLUFNRCBz eXN0ZW1zLiAgSXRzIG5lZ2F0aXZlIGZvcm0gY2FuIG9mIGNvdXJzZSBhbHNv IGJlIHVzZWQgdG8gc3VwcHJlc3MgdXNlIGFuZAotZXhwb3N1cmUgb2YgdGhl IGZlYXR1cmUuCitgcmRyYW5kYCBhbmQgYHJkc2VlZGAgY2FuIGJlIGlnbm9y ZWQsIGFzIGEgbWl0aWdhdGlvbiB0byBYU0EtMzIwIC8KK0NWRS0yMDIwLTA1 NDMuICBUaGUgUkRSQU5EIGZlYXR1cmUgaXMgZGlzYWJsZWQgYnkgZGVmYXVs dCBvbiBjZXJ0YWluIEFNRAorc3lzdGVtcywgZHVlIHRvIHBvc3NpYmxlIG1h bGZ1bmN0aW9ucyBhZnRlciBBQ1BJIFMzIHN1c3BlbmQvcmVzdW1lLiAgYHJk cmFuZGAKK21heSBiZSB1c2VkIGluIGl0cyBwb3NpdGl2ZSBmb3JtIHRvIG92 ZXJyaWRlIFhlbidzIGRlZmF1bHQgYmVoYXZpb3VyIG9uIHRoZXNlCitzeXN0 ZW1zLCBhbmQgbWFrZSB0aGUgZmVhdHVyZSBmdWxseSB1c2FibGUuCiAKICMj IyBjcHVpZF9tYXNrX2NwdQogPiBgPSBmYW1fMGZfcmV2X1tjZGVmZ10gfCBm YW1fMTBfcmV2X1tiY10gfCBmYW1fMTFfcmV2X2JgCg== --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.9-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.9-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du IGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KaW5kZXgg ODAwNDhkNDIzMC4uMTc3ZGVjYWVjZSAxMDA2NDQKLS0tIGEvZG9jcy9taXNj L3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KKysrIGIvZG9jcy9taXNjL3hl bi1jb21tYW5kLWxpbmUubWFya2Rvd24KQEAgLTQ1NiwxMCArNDU2LDEwIEBA IGFjY291bnRpbmcgZm9yIGhhcmR3YXJlIGNhcGFiaWxpdGllcyBhcyBlbnVt ZXJhdGVkIHZpYSBDUFVJRC4KIAogQ3VycmVudGx5IGFjY2VwdGVkOgogCi1U aGUgU3BlY3VsYXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgbWQt Y2xlYXJgLCBgaWJyc2JgLCBgc3RpYnBgLCBgaWJwYmAsCi1gbDFkLWZsdXNo YCBhbmQgYHNzYmRgIGFyZSB1c2VkIGJ5IGRlZmF1bHQgaWYgYXZhaWxhYmxl IGFuZCBhcHBsaWNhYmxlLiAgVGhleSBjYW4KLWJlIGlnbm9yZWQsIGUuZy4g YG5vLWlicnNiYCwgYXQgd2hpY2ggcG9pbnQgWGVuIHdvbid0IHVzZSB0aGVt IGl0c2VsZiwgYW5kCi13b24ndCBvZmZlciB0aGVtIHRvIGd1ZXN0cy4KK1Ro ZSBTcGVjdWxhdGlvbiBDb250cm9sIGhhcmR3YXJlIGZlYXR1cmVzIGBzcmJk cy1jdHJsYCwgYG1kLWNsZWFyYCwgYGlicnNiYCwKK2BzdGlicGAsIGBpYnBi YCwgYGwxZC1mbHVzaGAgYW5kIGBzc2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0 IGlmIGF2YWlsYWJsZSBhbmQKK2FwcGxpY2FibGUuICBUaGV5IGNhbiBiZSBp Z25vcmVkLCBlLmcuIGBuby1pYnJzYmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3 b24ndAordXNlIHRoZW0gaXRzZWxmLCBhbmQgd29uJ3Qgb2ZmZXIgdGhlbSB0 byBndWVzdHMuCiAKICMjIyBjcHVpZFxfbWFza1xfY3B1IChBTUQgb25seSkK ID4gYD0gZmFtXzBmX3Jldl9jIHwgZmFtXzBmX3Jldl9kIHwgZmFtXzBmX3Jl dl9lIHwgZmFtXzBmX3Jldl9mIHwgZmFtXzBmX3Jldl9nIHwgZmFtXzEwX3Jl dl9iIHwgZmFtXzEwX3Jldl9jIHwgZmFtXzExX3Jldl9iYApkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhsL2xp YnhsX2NwdWlkLmMKaW5kZXggMjBkMDYwMjUxYS4uNWEyYzY3ZmNhYyAxMDA2 NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90b29s cy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0xNTgsNiArMTU4LDcgQEAgaW50 IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xpY3lf bGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKICAgICAgICAgeyJkZSIs ICAgICAgICAgICAweDAwMDAwMDAxLCBOQSwgQ1BVSURfUkVHX0VEWCwgIDIs ICAxfSwKICAgICAgICAgeyJ2bWUiLCAgICAgICAgICAweDAwMDAwMDAxLCBO QSwgQ1BVSURfUkVHX0VEWCwgIDEsICAxfSwKICAgICAgICAgeyJmcHUiLCAg ICAgICAgICAweDAwMDAwMDAxLCBOQSwgQ1BVSURfUkVHX0VEWCwgIDAsICAx fSwKKyAgICAgICAgeyJzcmJkcy1jdHJsIiwgICAweDAwMDAwMDA3LCAgMCwg Q1BVSURfUkVHX0VEWCwgIDksICAxfSwKICAgICAgICAgeyJtZC1jbGVhciIs ICAgICAweDAwMDAwMDA3LCAgMCwgQ1BVSURfUkVHX0VEWCwgMTAsICAxfSwK ICAgICAgICAgeyJpYnJzYiIsICAgICAgICAweDAwMDAwMDA3LCAgMCwgQ1BV SURfUkVHX0VEWCwgMjYsICAxfSwKICAgICAgICAgeyJzdGlicCIsICAgICAg ICAweDAwMDAwMDA3LCAgMCwgQ1BVSURfUkVHX0VEWCwgMjcsICAxfSwKZGlm ZiAtLWdpdCBhL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMgYi90b29scy9taXNj L3hlbi1jcHVpZC5jCmluZGV4IDcyYzY3ZDBlNzcuLmI4NTM2NTY0MDQgMTAw NjQ0Ci0tLSBhL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKKysrIGIvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYwpAQCAtMTU3LDggKzE1Nyw5IEBAIHN0YXRpYyBj b25zdCBjaGFyICpzdHJfN2QwWzMyXSA9CiAKICAgICBbIDJdID0gImF2eDUx Ml80dm5uaXciLCBbIDNdID0gImF2eDUxMl80Zm1hcHMiLAogCi0gICAgWzQg Li4uIDldID0gIlJFWiIsCisgICAgWzQgLi4uIDddID0gIlJFWiIsCiAKKyAg ICBbIDhdID0gIlJFWiIsICAgICAgICAgICBbIDldID0gInNyYmRzLWN0cmwi LAogICAgIFsxMF0gPSAibWQtY2xlYXIiLCAgICAgIFsxMV0gPSAiUkVaIiwK ICAgICBbMTJdID0gIlJFWiIsICAgICAgICAgICBbMTNdID0gInRzeC1mb3Jj ZS1hYm9ydCIsCiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jcHVpZC5j IGIveGVuL2FyY2gveDg2L2NwdWlkLmMKaW5kZXggOWFhZjhiODI4My4uYjQ5 ODhiYTUyNyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NwdWlkLmMKKysr IGIveGVuL2FyY2gveDg2L2NwdWlkLmMKQEAgLTU4LDYgKzU4LDExIEBAIHN0 YXRpYyBpbnQgX19pbml0IHBhcnNlX3hlbl9jcHVpZChjb25zdCBjaGFyICpz KQogICAgICAgICAgICAgaWYgKCAhdmFsICkKICAgICAgICAgICAgICAgICBz ZXR1cF9jbGVhcl9jcHVfY2FwKFg4Nl9GRUFUVVJFX1NTQkQpOwogICAgICAg ICB9CisgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigi c3JiZHMtY3RybCIsIHMsIHNzKSkgPj0gMCApCisgICAgICAgIHsKKyAgICAg ICAgICAgIGlmICggIXZhbCApCisgICAgICAgICAgICAgICAgc2V0dXBfY2xl YXJfY3B1X2NhcChYODZfRkVBVFVSRV9TUkJEU19DVFJMKTsKKyAgICAgICAg fQogICAgICAgICBlbHNlCiAgICAgICAgICAgICByYyA9IC1FSU5WQUw7CiAK ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9odm0vaHZtLmMgYi94ZW4vYXJj aC94ODYvaHZtL2h2bS5jCmluZGV4IDJhYTlhYzA2YTQuLmUwM2MyMjFmNTQg MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9odm0vaHZtLmMKKysrIGIveGVu L2FyY2gveDg2L2h2bS9odm0uYwpAQCAtMzQ0NSw2ICszNDQ1LDcgQEAgaW50 IGh2bV9tc3JfcmVhZF9pbnRlcmNlcHQodW5zaWduZWQgaW50IG1zciwgdWlu dDY0X3QgKm1zcl9jb250ZW50KQogICAgICAgICAvKiBXcml0ZS1vbmx5ICov CiAgICAgY2FzZSBNU1JfVFNYX0ZPUkNFX0FCT1JUOgogICAgIGNhc2UgTVNS X1RTWF9DVFJMOgorICAgIGNhc2UgTVNSX01DVV9PUFRfQ1RSTDoKICAgICAg ICAgLyogTm90IG9mZmVyZWQgdG8gZ3Vlc3RzLiAqLwogICAgICAgICBnb3Rv IGdwX2ZhdWx0OwogCkBAIC0zNjcxLDYgKzM2NzIsNyBAQCBpbnQgaHZtX21z cl93cml0ZV9pbnRlcmNlcHQodW5zaWduZWQgaW50IG1zciwgdWludDY0X3Qg bXNyX2NvbnRlbnQsCiAgICAgICAgIC8qIFJlYWQtb25seSAqLwogICAgIGNh c2UgTVNSX1RTWF9GT1JDRV9BQk9SVDoKICAgICBjYXNlIE1TUl9UU1hfQ1RS TDoKKyAgICBjYXNlIE1TUl9NQ1VfT1BUX0NUUkw6CiAgICAgICAgIC8qIE5v dCBvZmZlcmVkIHRvIGd1ZXN0cy4gKi8KICAgICAgICAgZ290byBncF9mYXVs dDsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jIGIv eGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IGY0NGRmNmZmNDMuLmUy MTJhMjAxMjcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu YworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTM0OCwxMiAr MzQ4LDEzIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVu dW0gaW5kX3RodW5rIHRodW5rLCB1aW50NjRfdCBjYXBzKQogICAgIHByaW50 aygiU3BlY3VsYXRpdmUgbWl0aWdhdGlvbiBmYWNpbGl0aWVzOlxuIik7CiAK ICAgICAvKiBIYXJkd2FyZSBmZWF0dXJlcyB3aGljaCBwZXJ0YWluIHRvIHNw ZWN1bGF0aXZlIG1pdGlnYXRpb25zLiAqLwotICAgIHByaW50aygiICBIYXJk d2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4i LAorICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVz JXMlcyVzJXMlcyVzJXMlcyVzJXNcbiIsCiAgICAgICAgICAgIChfN2QwICYg Y3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNCKSkgPyAiIElCUlMvSUJQ QiIgOiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2 X0ZFQVRVUkVfU1RJQlApKSA/ICIgU1RJQlAiICAgICA6ICIiLAogICAgICAg ICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9MMURfRkxV U0gpKSA/ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICAoXzdkMCAm IGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TU0JEKSkgID8gIiBTU0JEIiAg ICAgIDogIiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1ZmVhdF9tYXNrKFg4 Nl9GRUFUVVJFX01EX0NMRUFSKSkgPyAiIE1EX0NMRUFSIiA6ICIiLAorICAg ICAgICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TUkJE U19DVFJMKSkgPyAiIFNSQkRTX0NUUkwiIDogIiIsCiAgICAgICAgICAgIChl OGIgICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUEIpKSAgPyAiIElC UEIiICAgICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUEFC SUxJVElFU19JQlJTX0FMTCkgICAgICA/ICIgSUJSU19BTEwiICA6ICIiLAog ICAgICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQQUJJTElUSUVTX1JEQ0xfTk8p ICAgICAgID8gIiBSRENMX05PIiAgIDogIiIsCmRpZmYgLS1naXQgYS94ZW4v YXJjaC94ODYvdHJhcHMuYyBiL3hlbi9hcmNoL3g4Ni90cmFwcy5jCmluZGV4 IDliNGJiNmEwMDkuLjZlYTU4MmMzOTMgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNo L3g4Ni90cmFwcy5jCisrKyBiL3hlbi9hcmNoL3g4Ni90cmFwcy5jCkBAIC0y NjU1LDYgKzI2NTUsNyBAQCBzdGF0aWMgaW50IHByaXZfb3BfcmVhZF9tc3Io dW5zaWduZWQgaW50IHJlZywgdWludDY0X3QgKnZhbCwKICAgICAgICAgLyog V3JpdGUtb25seSAqLwogICAgIGNhc2UgTVNSX1RTWF9GT1JDRV9BQk9SVDoK ICAgICBjYXNlIE1TUl9UU1hfQ1RSTDoKKyAgICBjYXNlIE1TUl9NQ1VfT1BU X0NUUkw6CiAgICAgICAgIC8qIE5vdCBvZmZlcmVkIHRvIGd1ZXN0cy4gKi8K ICAgICAgICAgYnJlYWs7CiAKQEAgLTI4ODAsNiArMjg4MSw3IEBAIHN0YXRp YyBpbnQgcHJpdl9vcF93cml0ZV9tc3IodW5zaWduZWQgaW50IHJlZywgdWlu dDY0X3QgdmFsLAogICAgICAgICAvKiBUaGUgTVNSIGlzIHJlYWQtb25seS4g Ki8KICAgICBjYXNlIE1TUl9UU1hfRk9SQ0VfQUJPUlQ6CiAgICAgY2FzZSBN U1JfVFNYX0NUUkw6CisgICAgY2FzZSBNU1JfTUNVX09QVF9DVFJMOgogICAg ICAgICAvKiBOb3Qgb2ZmZXJlZCB0byBndWVzdHMuICovCiAgICAgICAgIGJy ZWFrOwogCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9hc20teDg2L21zci1p bmRleC5oIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3ItaW5kZXguaAppbmRl eCA1ZDYzNmNjMjUwLi5kNzdhZWI5YWZhIDEwMDY0NAotLS0gYS94ZW4vaW5j bHVkZS9hc20teDg2L21zci1pbmRleC5oCisrKyBiL3hlbi9pbmNsdWRlL2Fz bS14ODYvbXNyLWluZGV4LmgKQEAgLTE3Niw2ICsxNzYsOSBAQAogI2RlZmlu ZSBNU1JfSUEzMl9WTVhfVFJVRV9FTlRSWV9DVExTICAgICAgICAgICAgMHg0 OTAKICNkZWZpbmUgTVNSX0lBMzJfVk1YX1ZNRlVOQyAgICAgICAgICAgICAg ICAgICAgIDB4NDkxCiAKKyNkZWZpbmUgTVNSX01DVV9PUFRfQ1RSTCAgICAg ICAgICAgICAgICAgICAgMHgwMDAwMDEyMworI2RlZmluZSAgTUNVX09QVF9D VFJMX1JOR0RTX01JVEdfRElTICAgICAgICAoX0FDKDEsIFVMTCkgPDwgIDAp CisKIC8qIEs3L0s4IE1TUnMuIE5vdCBjb21wbGV0ZS4gU2VlIHRoZSBhcmNo aXRlY3R1cmUgbWFudWFsIGZvciBhIG1vcmUKICAgIGNvbXBsZXRlIGxpc3Qu ICovCiAjZGVmaW5lIE1TUl9LN19FVk5UU0VMMAkJCTB4YzAwMTAwMDAKZGlm ZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0 dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVh dHVyZXNldC5oCmluZGV4IDAwMGE5NDFlNTAuLmM3NTAxNGY0ZTMgMTAwNjQ0 Ci0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJl c2V0LmgKKysrIGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZl YXR1cmVzZXQuaApAQCAtMjQxLDYgKzI0MSw3IEBAIFhFTl9DUFVGRUFUVVJF KElCUEIsICAgICAgICAgIDgqMzIrMTIpIC8qQSAgSUJQQiBzdXBwb3J0IG9u bHkgKG5vIElCUlMsIHVzZWQgYnkKIC8qIEludGVsLWRlZmluZWQgQ1BVIGZl YXR1cmVzLCBDUFVJRCBsZXZlbCAweDAwMDAwMDA3OjAuZWR4LCB3b3JkIDkg Ki8KIFhFTl9DUFVGRUFUVVJFKEFWWDUxMl80Vk5OSVcsIDkqMzIrIDIpIC8q QSAgQVZYNTEyIE5ldXJhbCBOZXR3b3JrIEluc3RydWN0aW9ucyAqLwogWEVO X0NQVUZFQVRVUkUoQVZYNTEyXzRGTUFQUywgOSozMisgMykgLypBICBBVlg1 MTIgTXVsdGlwbHkgQWNjdW11bGF0aW9uIFNpbmdsZSBQcmVjaXNpb24gKi8K K1hFTl9DUFVGRUFUVVJFKFNSQkRTX0NUUkwsICAgIDkqMzIrIDkpIC8qICAg TVNSX01DVV9PUFRfQ1RSTCBhbmQgUk5HRFNfTUlUR19ESVMuICovCiBYRU5f Q1BVRkVBVFVSRShNRF9DTEVBUiwgICAgICA5KjMyKzEwKSAvKkEgIFZFUlcg Y2xlYXJzIG1pY3JvYXJjaGl0ZWN0dXJhbCBidWZmZXJzICovCiBYRU5fQ1BV RkVBVFVSRShUU1hfRk9SQ0VfQUJPUlQsIDkqMzIrMTMpIC8qIE1TUl9UU1hf Rk9SQ0VfQUJPUlQuUlRNX0FCT1JUICovCiBYRU5fQ1BVRkVBVFVSRShJQlJT QiwgICAgICAgICA5KjMyKzI2KSAvKkEgIElCUlMgYW5kIElCUEIgc3VwcG9y dCAodXNlZCBieSBJbnRlbCkgKi8K --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.9-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.9-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5t YXJrZG93biBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du CmluZGV4IDE3N2RlY2FlY2UuLjRiMzRlZWZlYjUgMTAwNjQ0Ci0tLSBhL2Rv Y3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBiL2RvY3Mv bWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCkBAIC0xNzA0LDcgKzE3 MDQsNyBAQCBmYWxzZSBkaXNhYmxlIHRoZSBxdWlyayB3b3JrYXJvdW5kLCB3 aGljaCBpcyBhbHNvIHRoZSBkZWZhdWx0LgogIyMjIHNwZWMtY3RybCAoeDg2 KQogPiBgPSBMaXN0IG9mIFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZt LG1zci1zYyxyc2IsbWQtY2xlYXJ9PTxib29sPiwKID4gICAgICAgICAgICAg IGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZlbmNlfGptcCwge2licnMsaWJwYixz c2JkLGVhZ2VyLWZwdSwKLT4gICAgICAgICAgICAgIGwxZC1mbHVzaH09PGJv b2w+IF1gCis+ICAgICAgICAgICAgICBsMWQtZmx1c2gsc3JiLWxvY2t9PTxi b29sPiBdYAogCiBDb250cm9scyBmb3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9u IHNpZGVjaGFubmVsIG1pdGlnYXRpb25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3 aWxsIHBpY2sgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFz ZWQgb24gY29tcGlsZWQgaW4gc3VwcG9ydCwKQEAgLTE3NzYsNiArMTc3Niwx MiBAQCBJcnJlc3BlY3RpdmUgb2YgWGVuJ3Mgc2V0dGluZywgdGhlIGZlYXR1 cmUgaXMgdmlydHVhbGlzZWQgZm9yIEhWTSBndWVzdHMgdG8KIHVzZS4gIEJ5 IGRlZmF1bHQsIFhlbiB3aWxsIGVuYWJsZSB0aGlzIG1pdGlnYXRpb24gb24g aGFyZHdhcmUgYmVsaWV2ZWQgdG8gYmUKIHZ1bG5lcmFibGUgdG8gTDFURi4K IAorT24gaGFyZHdhcmUgc3VwcG9ydGluZyBTUkJEU19DVFJMLCB0aGUgYHNy Yi1sb2NrPWAgb3B0aW9uIGNhbiBiZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2 ZW50IFhlbiBmcm9tIHByb3RlY3QgdGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVm ZmVyIGZyb20gbGVha2luZyBzdGFsZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVu IHdpbGwgZW5hYmxlIHRoaXMgbWl0aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRz IHdoZXJlIE1EUworaXMgZml4ZWQgYW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0 ZWQgKGluIHdoaWNoIGNhc2UsIHRoZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5v Cit3YXkgZm9yIGFuIGF0dGFja2VyIHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0 YSkuCisKICMjIyBzeW5jXF9jb25zb2xlCiA+IGA9IDxib29sZWFuPmAKIApk aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYyBiL3hlbi9h cmNoL3g4Ni9hY3BpL3Bvd2VyLmMKaW5kZXggZjM0ODBhYTgwMC4uNGQ3MmI2 Y2U5NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwor KysgYi94ZW4vYXJjaC94ODYvYWNwaS9wb3dlci5jCkBAIC0yNTksNiArMjU5 LDkgQEAgc3RhdGljIGludCBlbnRlcl9zdGF0ZSh1MzIgc3RhdGUpCiAgICAg Y2ktPnNwZWNfY3RybF9mbGFncyB8PSAoZGVmYXVsdF9zcGVjX2N0cmxfZmxh Z3MgJiBTQ0ZfaXN0X3dybXNyKTsKICAgICBzcGVjX2N0cmxfZXhpdF9pZGxl KGNpKTsKIAorICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NS QkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkws IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CisKICBkb25lOgogICAgIHNw aW5fZGVidWdfZW5hYmxlKCk7CiAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh Z3MpOwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYyBiL3hl bi9hcmNoL3g4Ni9zbXBib290LmMKaW5kZXggNjQxZjgzMGNkMS4uOWRiOGVm MDkyNiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYworKysg Yi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCkBAIC0zNTYsMTIgKzM1NiwxNCBA QCB2b2lkIHN0YXJ0X3NlY29uZGFyeSh2b2lkICp1bnVzZWQpCiAgICAgICAg IG1pY3JvY29kZV9yZXN1bWVfY3B1KGNwdSk7CiAKICAgICAvKgotICAgICAq IElmIE1TUl9TUEVDX0NUUkwgaXMgYXZhaWxhYmxlLCBhcHBseSBYZW4ncyBk ZWZhdWx0IHNldHRpbmcgYW5kIGRpc2NhcmQKLSAgICAgKiBhbnkgZmlybXdh cmUgc2V0dGluZ3MuICBOb3RlOiBNU1JfU1BFQ19DVFJMIG1heSBvbmx5IGJl Y29tZSBhdmFpbGFibGUKLSAgICAgKiBhZnRlciBsb2FkaW5nIG1pY3JvY29k ZS4KKyAgICAgKiBJZiBhbnkgc3BlY3VsYXRpdmUgY29udHJvbCBNU1JzIGFy ZSBhdmFpbGFibGUsIGFwcGx5IFhlbidzIGRlZmF1bHQKKyAgICAgKiBzZXR0 aW5ncy4gIE5vdGU6IFRoZXNlIE1TUnMgbWF5IG9ubHkgYmVjb21lIGF2YWls YWJsZSBhZnRlciBsb2FkaW5nCisgICAgICogbWljcm9jb2RlLgogICAgICAq LwogICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0lCUlNCKSAp CiAgICAgICAgIHdybXNybChNU1JfU1BFQ19DVFJMLCBkZWZhdWx0X3hlbl9z cGVjX2N0cmwpOworICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF X1NSQkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NU UkwsIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CiAKICAgICB0c3hfaW5p dCgpOyAvKiBOZWVkcyBtaWNyb2NvZGUuICBNYXkgY2hhbmdlIEhMRS9SVE0g ZmVhdHVyZSBiaXRzLiAqLwogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg ZTIxMmEyMDEyNy4uMjg5ZTkxZmIwNCAxMDA2NDQKLS0tIGEveGVuL2FyY2gv eDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu YwpAQCAtNjIsNiArNjIsOSBAQCBzdGF0aWMgdW5zaWduZWQgaW50IF9faW5p dGRhdGEgbDFkX21heHBoeXNhZGRyOwogc3RhdGljIGJvb2wgX19pbml0ZGF0 YSBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5OyAvKiA9PiBtaW5pbWFsIEhUIGlt cGFjdC4gKi8KIHN0YXRpYyBib29sIF9faW5pdGRhdGEgY3B1X2hhc19idWdf bWRzOyAvKiBBbnkgb3RoZXIgTXtMUCxTQixGQn1EUyBjb21iaW5hdGlvbi4g Ki8KIAorc3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9zcmJfbG9jayA9 IC0xOwordWludDY0X3QgX19yZWFkX21vc3RseSBkZWZhdWx0X3hlbl9tY3Vf b3B0X2N0cmw7CisKIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2J0aShjb25z dCBjaGFyICpzKQogewogICAgIGNvbnN0IGNoYXIgKnNzOwpAQCAtMTQ5LDYg KzE1Miw3IEBAIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChj aGFyICpzKQogICAgICAgICAgICAgb3B0X2licGIgPSBmYWxzZTsKICAgICAg ICAgICAgIG9wdF9zc2JkID0gZmFsc2U7CiAgICAgICAgICAgICBvcHRfbDFk X2ZsdXNoID0gMDsKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9IDA7CiAg ICAgICAgIH0KICAgICAgICAgZWxzZSBpZiAoIHZhbCA+IDAgKQogICAgICAg ICAgICAgcmMgPSAtRUlOVkFMOwpAQCAtMjE0LDYgKzIxOCw4IEBAIHN0YXRp YyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjaGFyICpzKQogICAgICAg ICAgICAgb3B0X2VhZ2VyX2ZwdSA9IHZhbDsKICAgICAgICAgZWxzZSBpZiAo ICh2YWwgPSBwYXJzZV9ib29sZWFuKCJsMWQtZmx1c2giLCBzLCBzcykpID49 IDAgKQogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9IHZhbDsKKyAgICAg ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJzcmItbG9jayIs IHMsIHNzKSkgPj0gMCApCisgICAgICAgICAgICBvcHRfc3JiX2xvY2sgPSB2 YWw7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJjID0gLUVJTlZBTDsK IApAQCAtMzc3LDcgKzM4Myw3IEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmlu dF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rLCB1aW50NjRfdCBjYXBz KQogICAgICAgICAgICAgICAgIlxuIik7CiAKICAgICAvKiBTZXR0aW5ncyBm b3IgWGVuJ3MgcHJvdGVjdGlvbiwgaXJyZXNwZWN0aXZlIG9mIGd1ZXN0cy4g Ki8KLSAgICBwcmludGsoIiAgWGVuIHNldHRpbmdzOiBCVEktVGh1bmsgJXMs IFNQRUNfQ1RSTDogJXMlcyVzLCBPdGhlcjolcyVzJXNcbiIsCisgICAgcHJp bnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVzLCBTUEVDX0NUUkw6 ICVzJXMlcywgT3RoZXI6JXMlcyVzJXNcbiIsCiAgICAgICAgICAgIHRodW5r ID09IFRIVU5LX05PTkUgICAgICA/ICJOL0EiIDoKICAgICAgICAgICAgdGh1 bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBPTElORSIgOgogICAgICAg ICAgICB0aHVuayA9PSBUSFVOS19MRkVOQ0UgICAgPyAiTEZFTkNFIiA6CkBA IC0zODgsNiArMzk0LDggQEAgc3RhdGljIHZvaWQgX19pbml0IHByaW50X2Rl dGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVpbnQ2NF90IGNhcHMpCiAg ICAgICAgICAgIChkZWZhdWx0X3hlbl9zcGVjX2N0cmwgJiBTUEVDX0NUUkxf U1NCRCkgID8gIiBTU0JEKyIgOiAiIFNTQkQtIiwKICAgICAgICAgICAgIShj YXBzICYgQVJDSF9DQVBTX1RTWF9DVFJMKSAgICAgICAgICAgICAgPyAiIiA6 CiAgICAgICAgICAgIChvcHRfdHN4ICYgMSkgICAgICAgICAgICAgICAgICAg ICAgICAgICAgID8gIiBUU1grIiA6ICIgVFNYLSIsCisgICAgICAgICAgICFi b290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgICAgID8gIiIg OgorICAgICAgICAgICBvcHRfc3JiX2xvY2sgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA/ICIgU1JCX0xPQ0srIiA6ICIgU1JCX0xPQ0stIiwKICAg ICAgICAgICAgb3B0X2licGIgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPyAiIElCUEIiICA6ICIiLAogICAgICAgICAgICBvcHRfbDFkX2Zs dXNoICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgTDFEX0ZMVVNI IiA6ICIiLAogICAgICAgICAgICBvcHRfbWRfY2xlYXJfcHYgfHwgb3B0X21k X2NsZWFyX2h2bSAgICAgICA/ICIgVkVSVyIgIDogIiIpOwpAQCAtMTE1Miw2 ICsxMTYwLDM0IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRpb25fbWl0 aWdhdGlvbnModm9pZCkKICAgICAgICAgdHN4X2luaXQoKTsKICAgICB9CiAK KyAgICAvKiBDYWxjdWxhdGUgc3VpdGFibGUgZGVmYXVsdHMgZm9yIE1TUl9N Q1VfT1BUX0NUUkwgKi8KKyAgICBpZiAoIGJvb3RfY3B1X2hhcyhYODZfRkVB VFVSRV9TUkJEU19DVFJMKSApCisgICAgeworICAgICAgICB1aW50NjRfdCB2 YWw7CisKKyAgICAgICAgcmRtc3JsKE1TUl9NQ1VfT1BUX0NUUkwsIHZhbCk7 CisKKyAgICAgICAgLyoKKyAgICAgICAgICogT24gc29tZSBTUkJEUy1hZmZl Y3RlZCBoYXJkd2FyZSwgaXQgbWF5IGJlIHNhZmUgdG8gcmVsYXggc3JiLWxv Y2sKKyAgICAgICAgICogYnkgZGVmYXVsdC4KKyAgICAgICAgICoKKyAgICAg ICAgICogT24gcGFydHMgd2hpY2ggZW51bWVyYXRlIE1EU19OTyBhbmQgbm90 IFRBQV9OTywgVFNYIGlzIHRoZSBvbmx5IHdheQorICAgICAgICAgKiB0byBh Y2Nlc3MgdGhlIEZpbGwgQnVmZmVyLiAgSWYgVFNYIGlzbid0IGF2YWlsYWJs ZSAoaW5jLiBTS1UKKyAgICAgICAgICogcmVhc29ucyBvbiBzb21lIG1vZGVs cyksIG9yIFRTWCBpcyBleHBsaWNpdGx5IGRpc2FibGVkLCB0aGVuIHRoZXJl CisgICAgICAgICAqIGlzIG5vIG5lZWQgZm9yIHRoZSBleHRyYSBvdmVyaGVh ZCB0byBwcm90ZWN0IFJEUkFORC9SRFNFRUQuCisgICAgICAgICAqLworICAg ICAgICBpZiAoIG9wdF9zcmJfbG9jayA9PSAtMSAmJgorICAgICAgICAgICAg IChjYXBzICYgKEFSQ0hfQ0FQU19NRFNfTk98QVJDSF9DQVBTX1RBQV9OTykp ID09IEFSQ0hfQ0FQU19NRFNfTk8gJiYKKyAgICAgICAgICAgICAoIWNwdV9o YXNfaGxlIHx8ICgoY2FwcyAmIEFSQ0hfQ0FQU19UU1hfQ1RSTCkgJiYgb3B0 X3RzeCA9PSAwKSkgKQorICAgICAgICAgICAgb3B0X3NyYl9sb2NrID0gMDsK KworICAgICAgICB2YWwgJj0gfk1DVV9PUFRfQ1RSTF9STkdEU19NSVRHX0RJ UzsKKyAgICAgICAgaWYgKCAhb3B0X3NyYl9sb2NrICkKKyAgICAgICAgICAg IHZhbCB8PSBNQ1VfT1BUX0NUUkxfUk5HRFNfTUlUR19ESVM7CisKKyAgICAg ICAgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsID0gdmFsOworICAgIH0KKwog ICAgIHByaW50X2RldGFpbHModGh1bmssIGNhcHMpOwogCiAgICAgLyoKQEAg LTExODMsNiArMTIxOSw5IEBAIHZvaWQgX19pbml0IGluaXRfc3BlY3VsYXRp b25fbWl0aWdhdGlvbnModm9pZCkKIAogICAgICAgICB3cm1zcmwoTVNSX1NQ RUNfQ1RSTCwgYnNwX2RlbGF5X3NwZWNfY3RybCA/IDAgOiBkZWZhdWx0X3hl bl9zcGVjX2N0cmwpOwogICAgIH0KKworICAgIGlmICggYm9vdF9jcHVfaGFz KFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1T Ul9NQ1VfT1BUX0NUUkwsIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CiB9 CiAKIHN0YXRpYyB2b2lkIF9faW5pdCBfX21heWJlX3VudXNlZCBidWlsZF9h c3NlcnRpb25zKHZvaWQpCmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9hc20t eDg2L3NwZWNfY3RybC5oIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0 cmwuaAppbmRleCA5OGEwYTUwNGY2Li5kZjg2MmVjNGQwIDEwMDY0NAotLS0g YS94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oCisrKyBiL3hlbi9p bmNsdWRlL2FzbS14ODYvc3BlY19jdHJsLmgKQEAgLTQ2LDYgKzQ2LDggQEAg ZXh0ZXJuIGludDhfdCBvcHRfcHZfbDF0Zl9od2RvbSwgb3B0X3B2X2wxdGZf ZG9tdTsKICAqLwogZXh0ZXJuIHBhZGRyX3QgbDF0Zl9hZGRyX21hc2ssIGwx dGZfc2FmZV9tYWRkcjsKIAorZXh0ZXJuIHVpbnQ2NF90IGRlZmF1bHRfeGVu X21jdV9vcHRfY3RybDsKKwogc3RhdGljIGlubGluZSB2b2lkIGluaXRfc2hh ZG93X3NwZWNfY3RybF9zdGF0ZSh2b2lkKQogewogICAgIHN0cnVjdCBjcHVf aW5mbyAqaW5mbyA9IGdldF9jcHVfaW5mbygpOwo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.9-3.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.9-3.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQWxsb3cgdGhlIFJEUkFORC9S RFNFRUQgZmVhdHVyZXMgdG8gYmUgaGlkZGVuCgpSRFJBTkQvUkRTRUVEIGNh biBiZSBoaWRkZW4gdXNpbmcgY3B1aWQ9IHRvIG1pdGlnYXRlIFNSQkRTIGlm IG1pY3JvY29kZQppc24ndCBhdmFpbGFibGUuCgpFeHRlbmQgbGlieGwncyB0 YWJsZSBvZiBuYW1lZCBwYXJhbWV0ZXJzIHRvIGluY2x1ZGUgUkRSQU5EL1JE U0VFRCwgYW5kCmhhdmUgdGhlIGNvbXBpbGVyIGNvbnN0cnVjdCBpdCBpbiAu cm9kYXRhLCByYXRoZXIgdGhhbiBvbiB0aGUgc3RhY2sgYXQgcnVudGltZQpl YWNoIHRpbWUgaXQgaXMgY2FsbGVkLgoKVGhpcyBpcyBwYXJ0IG9mIFhTQS0z MjAgLyBDVkUtMjAyMC0wNTQzLgoKU2lnbmVkLW9mZi1ieTogQW5kcmV3IENv b3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNvbT4KQWNrZWQtYnk6IEp1 bGllbiBHcmFsbCA8amdyYWxsQGFtYXpvbi5jb20+CgpkaWZmIC0tZ2l0IGEv ZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24gYi9kb2NzL21p c2MveGVuLWNvbW1hbmQtbGluZS5tYXJrZG93bgppbmRleCA0YjM0ZWVmZWI1 Li40NGE1YTkxMWMwIDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVuLWNvbW1h bmQtbGluZS5tYXJrZG93bgorKysgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQt bGluZS5tYXJrZG93bgpAQCAtNDU0LDEyICs0NTQsMTggQEAgY2hvaWNlIG9m IGBkb20wLWtlcm5lbGAgaXMgZGVwcmVjYXRlZCBhbmQgbm90IHN1cHBvcnRl ZCBieSBhbGwgRG9tMCBrZXJuZWxzLgogVGhpcyBvcHRpb24gYWxsb3dzIGZv ciBmaW5lIHR1bmluZyBvZiB0aGUgZmFjaWxpdGllcyBYZW4gd2lsbCB1c2Us IGFmdGVyCiBhY2NvdW50aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMg YXMgZW51bWVyYXRlZCB2aWEgQ1BVSUQuCiAKK1VubGVzcyBvdGhlcndpc2Ug bm90ZWQsIG9wdGlvbnMgb25seSBoYXZlIGFueSBlZmZlY3QgaW4gdGhlaXIg bmVnYXRpdmUgZm9ybSwKK3RvIGhpZGUgdGhlIG5hbWVkIGZlYXR1cmUocyku ICBJZ25vcmluZyBhIGZlYXR1cmUgdXNpbmcgdGhpcyBtZWNoYW5pc20gd2ls bAorY2F1c2UgWGVuIG5vdCB0byB1c2UgdGhlIGZlYXR1cmUsIG5vciBvZmZl ciB0aGVtIGFzIHVzYWJsZSB0byBndWVzdHMuCisKIEN1cnJlbnRseSBhY2Nl cHRlZDoKIAogVGhlIFNwZWN1bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVh dHVyZXMgYHNyYmRzLWN0cmxgLCBgbWQtY2xlYXJgLCBgaWJyc2JgLAogYHN0 aWJwYCwgYGlicGJgLCBgbDFkLWZsdXNoYCBhbmQgYHNzYmRgIGFyZSB1c2Vk IGJ5IGRlZmF1bHQgaWYgYXZhaWxhYmxlIGFuZAotYXBwbGljYWJsZS4gIFRo ZXkgY2FuIGJlIGlnbm9yZWQsIGUuZy4gYG5vLWlicnNiYCwgYXQgd2hpY2gg cG9pbnQgWGVuIHdvbid0Ci11c2UgdGhlbSBpdHNlbGYsIGFuZCB3b24ndCBv ZmZlciB0aGVtIHRvIGd1ZXN0cy4KK2FwcGxpY2FibGUuICBUaGV5IGNhbiBh bGwgYmUgaWdub3JlZC4KKworYHJkcmFuZGAgYW5kIGByZHNlZWRgIGNhbiBi ZSBpZ25vcmVkLCBhcyBhIG1pdGlnYXRpb24gdG8gWFNBLTMyMCAvCitDVkUt MjAyMC0wNTQzLgogCiAjIyMgY3B1aWRcX21hc2tcX2NwdSAoQU1EIG9ubHkp CiA+IGA9IGZhbV8wZl9yZXZfYyB8IGZhbV8wZl9yZXZfZCB8IGZhbV8wZl9y ZXZfZSB8IGZhbV8wZl9yZXZfZiB8IGZhbV8wZl9yZXZfZyB8IGZhbV8xMF9y ZXZfYiB8IGZhbV8xMF9yZXZfYyB8IGZhbV8xMV9yZXZfYmAKZGlmZiAtLWdp dCBhL3Rvb2xzL2xpYnhsL2xpYnhsX2NwdWlkLmMgYi90b29scy9saWJ4bC9s aWJ4bF9jcHVpZC5jCmluZGV4IDVhMmM2N2ZjYWMuLmVhMmU3MDhjNDcgMTAw NjQ0Ci0tLSBhL3Rvb2xzL2xpYnhsL2xpYnhsX2NwdWlkLmMKKysrIGIvdG9v bHMvbGlieGwvbGlieGxfY3B1aWQuYwpAQCAtODksNyArODksNyBAQCBzdGF0 aWMgbGlieGxfY3B1aWRfcG9saWN5X2xpc3QgY3B1aWRfZmluZF9tYXRjaChs aWJ4bF9jcHVpZF9wb2xpY3lfbGlzdCAqbGlzdCwKIGludCBsaWJ4bF9jcHVp ZF9wYXJzZV9jb25maWcobGlieGxfY3B1aWRfcG9saWN5X2xpc3QgKmNwdWlk LCBjb25zdCBjaGFyKiBzdHIpCiB7CiAjZGVmaW5lIE5BIFhFTl9DUFVJRF9J TlBVVF9VTlVTRUQKLSAgICBzdHJ1Y3QgY3B1aWRfZmxhZ3MgY3B1aWRfZmxh Z3NbXSA9IHsKKyAgICBzdGF0aWMgY29uc3Qgc3RydWN0IGNwdWlkX2ZsYWdz IGNwdWlkX2ZsYWdzW10gPSB7CiAgICAgICAgIHsibWF4bGVhZiIsICAgICAg MHgwMDAwMDAwMCwgTkEsIENQVUlEX1JFR19FQVgsICAwLCAzMn0sCiAgICAg ICAvKiB0aGUgZm9sbG93aW5nIHR3byBlbnRyaWVzIGFyZSBzdWJqZWN0IHRv IHR3ZWFraW5nIGxhdGVyIGluIHRoZSBjb2RlICovCiAgICAgICAgIHsiZmFt aWx5IiwgICAgICAgMHgwMDAwMDAwMSwgTkEsIENQVUlEX1JFR19FQVgsICA4 LCAgOH0sCkBAIC0xMDAsNiArMTAwLDcgQEAgaW50IGxpYnhsX2NwdWlkX3Bh cnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xpY3lfbGlzdCAqY3B1aWQsIGNv bnN0IGNoYXIqIHN0cikKICAgICAgICAgeyJjbGZsdXNoIiwgICAgICAweDAw MDAwMDAxLCBOQSwgQ1BVSURfUkVHX0VCWCwgIDgsICA4fSwKICAgICAgICAg eyJicmFuZGlkIiwgICAgICAweDAwMDAwMDAxLCBOQSwgQ1BVSURfUkVHX0VC WCwgIDAsICA4fSwKICAgICAgICAgeyJoeXBlcnZpc29yIiwgICAweDAwMDAw MDAxLCBOQSwgQ1BVSURfUkVHX0VDWCwgMzEsICAxfSwKKyAgICAgICAgeyJy ZHJhbmQiLCAgICAgICAweDAwMDAwMDAxLCBOQSwgQ1BVSURfUkVHX0VDWCwg MzAsICAxfSwKICAgICAgICAgeyJmMTZjIiwgICAgICAgICAweDAwMDAwMDAx LCBOQSwgQ1BVSURfUkVHX0VDWCwgMjksICAxfSwKICAgICAgICAgeyJhdngi LCAgICAgICAgICAweDAwMDAwMDAxLCBOQSwgQ1BVSURfUkVHX0VDWCwgMjgs ICAxfSwKICAgICAgICAgeyJvc3hzYXZlIiwgICAgICAweDAwMDAwMDAxLCBO QSwgQ1BVSURfUkVHX0VDWCwgMjcsICAxfSwKQEAgLTE2MCw2ICsxNjEsNyBA QCBpbnQgbGlieGxfY3B1aWRfcGFyc2VfY29uZmlnKGxpYnhsX2NwdWlkX3Bv bGljeV9saXN0ICpjcHVpZCwgY29uc3QgY2hhciogc3RyKQogICAgICAgICB7 ImZwdSIsICAgICAgICAgIDB4MDAwMDAwMDEsIE5BLCBDUFVJRF9SRUdfRURY LCAgMCwgIDF9LAogICAgICAgICB7InNyYmRzLWN0cmwiLCAgIDB4MDAwMDAw MDcsICAwLCBDUFVJRF9SRUdfRURYLCAgOSwgIDF9LAogICAgICAgICB7Im1k LWNsZWFyIiwgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAx MCwgIDF9LAorICAgICAgICB7InJkc2VlZCIsICAgICAgIDB4MDAwMDAwMDcs ICAwLCBDUFVJRF9SRUdfRUJYLCAxOCwgIDF9LAogICAgICAgICB7ImlicnNi IiwgICAgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyNiwg IDF9LAogICAgICAgICB7InN0aWJwIiwgICAgICAgIDB4MDAwMDAwMDcsICAw LCBDUFVJRF9SRUdfRURYLCAyNywgIDF9LAogICAgICAgICB7ImwxZC1mbHVz aCIsICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyOCwgIDF9 LApAQCAtMjExLDcgKzIxMyw3IEBAIGludCBsaWJ4bF9jcHVpZF9wYXJzZV9j b25maWcobGlieGxfY3B1aWRfcG9saWN5X2xpc3QgKmNwdWlkLCBjb25zdCBj aGFyKiBzdHIpCiAjdW5kZWYgTkEKICAgICBjaGFyICpzZXAsICp2YWwsICpl bmRwdHI7CiAgICAgaW50IGk7Ci0gICAgc3RydWN0IGNwdWlkX2ZsYWdzICpm bGFnOworICAgIGNvbnN0IHN0cnVjdCBjcHVpZF9mbGFncyAqZmxhZzsKICAg ICBzdHJ1Y3QgbGlieGxfX2NwdWlkX3BvbGljeSAqZW50cnk7CiAgICAgdW5z aWduZWQgbG9uZyBudW07CiAgICAgY2hhciBmbGFnc1szM10sICpyZXNzdHI7 CmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYvY3B1aWQuYyBiL3hlbi9hcmNo L3g4Ni9jcHVpZC5jCmluZGV4IGI0OTg4YmE1MjcuLjhmYjk4YzFkYWQgMTAw NjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9jcHVpZC5jCisrKyBiL3hlbi9hcmNo L3g4Ni9jcHVpZC5jCkBAIC02Myw2ICs2MywxNiBAQCBzdGF0aWMgaW50IF9f aW5pdCBwYXJzZV94ZW5fY3B1aWQoY29uc3QgY2hhciAqcykKICAgICAgICAg ICAgIGlmICggIXZhbCApCiAgICAgICAgICAgICAgICAgc2V0dXBfY2xlYXJf Y3B1X2NhcChYODZfRkVBVFVSRV9TUkJEU19DVFJMKTsKICAgICAgICAgfQor ICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oInJkcmFu ZCIsIHMsIHNzKSkgPj0gMCApCisgICAgICAgIHsKKyAgICAgICAgICAgIGlm ICggIXZhbCApCisgICAgICAgICAgICAgICAgc2V0dXBfY2xlYXJfY3B1X2Nh cChYODZfRkVBVFVSRV9SRFJBTkQpOworICAgICAgICB9CisgICAgICAgIGVs c2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigicmRzZWVkIiwgcywgc3Mp KSA+PSAwICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCAhdmFsICkK KyAgICAgICAgICAgICAgICBzZXR1cF9jbGVhcl9jcHVfY2FwKFg4Nl9GRUFU VVJFX1JEU0VFRCk7CisgICAgICAgIH0KICAgICAgICAgZWxzZQogICAgICAg ICAgICAgcmMgPSAtRUlOVkFMOwogCg== --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.10-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.10-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du IGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KaW5kZXgg MWYwOGRkZTE4Ni4uYWIyNmEyNjM4MSAxMDA2NDQKLS0tIGEvZG9jcy9taXNj L3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KKysrIGIvZG9jcy9taXNjL3hl bi1jb21tYW5kLWxpbmUubWFya2Rvd24KQEAgLTQ5NiwxMCArNDk2LDEwIEBA IGFjY291bnRpbmcgZm9yIGhhcmR3YXJlIGNhcGFiaWxpdGllcyBhcyBlbnVt ZXJhdGVkIHZpYSBDUFVJRC4KIAogQ3VycmVudGx5IGFjY2VwdGVkOgogCi1U aGUgU3BlY3VsYXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgbWQt Y2xlYXJgLCBgaWJyc2JgLCBgc3RpYnBgLCBgaWJwYmAsCi1gbDFkLWZsdXNo YCBhbmQgYHNzYmRgIGFyZSB1c2VkIGJ5IGRlZmF1bHQgaWYgYXZhaWxhYmxl IGFuZCBhcHBsaWNhYmxlLiAgVGhleSBjYW4KLWJlIGlnbm9yZWQsIGUuZy4g YG5vLWlicnNiYCwgYXQgd2hpY2ggcG9pbnQgWGVuIHdvbid0IHVzZSB0aGVt IGl0c2VsZiwgYW5kCi13b24ndCBvZmZlciB0aGVtIHRvIGd1ZXN0cy4KK1Ro ZSBTcGVjdWxhdGlvbiBDb250cm9sIGhhcmR3YXJlIGZlYXR1cmVzIGBzcmJk cy1jdHJsYCwgYG1kLWNsZWFyYCwgYGlicnNiYCwKK2BzdGlicGAsIGBpYnBi YCwgYGwxZC1mbHVzaGAgYW5kIGBzc2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0 IGlmIGF2YWlsYWJsZSBhbmQKK2FwcGxpY2FibGUuICBUaGV5IGNhbiBiZSBp Z25vcmVkLCBlLmcuIGBuby1pYnJzYmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3 b24ndAordXNlIHRoZW0gaXRzZWxmLCBhbmQgd29uJ3Qgb2ZmZXIgdGhlbSB0 byBndWVzdHMuCiAKICMjIyBjcHVpZFxfbWFza1xfY3B1IChBTUQgb25seSkK ID4gYD0gZmFtXzBmX3Jldl9jIHwgZmFtXzBmX3Jldl9kIHwgZmFtXzBmX3Jl dl9lIHwgZmFtXzBmX3Jldl9mIHwgZmFtXzBmX3Jldl9nIHwgZmFtXzEwX3Jl dl9iIHwgZmFtXzEwX3Jldl9jIHwgZmFtXzExX3Jldl9iYApkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhsL2xp YnhsX2NwdWlkLmMKaW5kZXggNWExNzAyZDcwMy4uMTIzNWM4YjkxZSAxMDA2 NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90b29s cy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0yMDIsNiArMjAyLDcgQEAgaW50 IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xpY3lf bGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKIAogICAgICAgICB7ImF2 eDUxMi00dm5uaXciLDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAg MiwgIDF9LAogICAgICAgICB7ImF2eDUxMi00Zm1hcHMiLDB4MDAwMDAwMDcs ICAwLCBDUFVJRF9SRUdfRURYLCAgMywgIDF9LAorICAgICAgICB7InNyYmRz LWN0cmwiLCAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAgOSwg IDF9LAogICAgICAgICB7Im1kLWNsZWFyIiwgICAgIDB4MDAwMDAwMDcsICAw LCBDUFVJRF9SRUdfRURYLCAxMCwgIDF9LAogICAgICAgICB7ImlicnNiIiwg ICAgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyNiwgIDF9 LAogICAgICAgICB7InN0aWJwIiwgICAgICAgIDB4MDAwMDAwMDcsICAwLCBD UFVJRF9SRUdfRURYLCAyNywgIDF9LApkaWZmIC0tZ2l0IGEvdG9vbHMvbWlz Yy94ZW4tY3B1aWQuYyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKaW5kZXgg ODlkNTBlMDQ4Yy4uN2Y5NjEyZjBhOSAxMDA2NDQKLS0tIGEvdG9vbHMvbWlz Yy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNjL3hlbi1jcHVpZC5jCkBA IC0xNjIsOCArMTYyLDkgQEAgc3RhdGljIGNvbnN0IGNoYXIgKnN0cl83ZDBb MzJdID0KIAogICAgIFsgMl0gPSAiYXZ4NTEyXzR2bm5pdyIsIFsgM10gPSAi YXZ4NTEyXzRmbWFwcyIsCiAKLSAgICBbNCAuLi4gOV0gPSAiUkVaIiwKKyAg ICBbNCAuLi4gN10gPSAiUkVaIiwKIAorICAgIFsgOF0gPSAiUkVaIiwgICAg ICAgICAgIFsgOV0gPSAic3JiZHMtY3RybCIsCiAgICAgWzEwXSA9ICJtZC1j bGVhciIsICAgICAgWzExXSA9ICJSRVoiLAogICAgIFsxMl0gPSAiUkVaIiwg ICAgICAgICAgIFsxM10gPSAidHN4LWZvcmNlLWFib3J0IiwKIApkaWZmIC0t Z2l0IGEveGVuL2FyY2gveDg2L2NwdWlkLmMgYi94ZW4vYXJjaC94ODYvY3B1 aWQuYwppbmRleCBlOTQzZDcwYmNhLi42N2EyYTJlNmEwIDEwMDY0NAotLS0g YS94ZW4vYXJjaC94ODYvY3B1aWQuYworKysgYi94ZW4vYXJjaC94ODYvY3B1 aWQuYwpAQCAtNTgsNiArNTgsMTEgQEAgc3RhdGljIGludCBfX2luaXQgcGFy c2VfeGVuX2NwdWlkKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBpZiAo ICF2YWwgKQogICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2NwdV9jYXAo WDg2X0ZFQVRVUkVfU1NCRCk7CiAgICAgICAgIH0KKyAgICAgICAgZWxzZSBp ZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJzcmJkcy1jdHJsIiwgcywgc3Mp KSA+PSAwICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCAhdmFsICkK KyAgICAgICAgICAgICAgICBzZXR1cF9jbGVhcl9jcHVfY2FwKFg4Nl9GRUFU VVJFX1NSQkRTX0NUUkwpOworICAgICAgICB9CiAgICAgICAgIGVsc2UKICAg ICAgICAgICAgIHJjID0gLUVJTlZBTDsKIApkaWZmIC0tZ2l0IGEveGVuL2Fy Y2gveDg2L21zci5jIGIveGVuL2FyY2gveDg2L21zci5jCmluZGV4IDZjZWVh OTEzZmIuLjkwNTYxYTUzOTIgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9t c3IuYworKysgYi94ZW4vYXJjaC94ODYvbXNyLmMKQEAgLTEzNSw2ICsxMzUs NyBAQCBpbnQgZ3Vlc3RfcmRtc3IoY29uc3Qgc3RydWN0IHZjcHUgKnYsIHVp bnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKICAgICAgICAgLyogV3JpdGUt b25seSAqLwogICAgIGNhc2UgTVNSX1RTWF9GT1JDRV9BQk9SVDoKICAgICBj YXNlIE1TUl9UU1hfQ1RSTDoKKyAgICBjYXNlIE1TUl9NQ1VfT1BUX0NUUkw6 CiAgICAgICAgIC8qIE5vdCBvZmZlcmVkIHRvIGd1ZXN0cy4gKi8KICAgICAg ICAgZ290byBncF9mYXVsdDsKIApAQCAtMTk0LDYgKzE5NSw3IEBAIGludCBn dWVzdF93cm1zcihzdHJ1Y3QgdmNwdSAqdiwgdWludDMyX3QgbXNyLCB1aW50 NjRfdCB2YWwpCiAgICAgICAgIC8qIFJlYWQtb25seSAqLwogICAgIGNhc2Ug TVNSX1RTWF9GT1JDRV9BQk9SVDoKICAgICBjYXNlIE1TUl9UU1hfQ1RSTDoK KyAgICBjYXNlIE1TUl9NQ1VfT1BUX0NUUkw6CiAgICAgICAgIC8qIE5vdCBv ZmZlcmVkIHRvIGd1ZXN0cy4gKi8KICAgICAgICAgZ290byBncF9mYXVsdDsK IApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jIGIveGVu L2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDBmMzAzNjIxMTEuLmI3NzMz YjM0ZjYgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwor KysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAgLTM0OSwxMiArMzQ5 LDEzIEBAIHN0YXRpYyB2b2lkIF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0g aW5kX3RodW5rIHRodW5rLCB1aW50NjRfdCBjYXBzKQogICAgIHByaW50aygi U3BlY3VsYXRpdmUgbWl0aWdhdGlvbiBmYWNpbGl0aWVzOlxuIik7CiAKICAg ICAvKiBIYXJkd2FyZSBmZWF0dXJlcyB3aGljaCBwZXJ0YWluIHRvIHNwZWN1 bGF0aXZlIG1pdGlnYXRpb25zLiAqLwotICAgIHByaW50aygiICBIYXJkd2Fy ZSBmZWF0dXJlczolcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAor ICAgIHByaW50aygiICBIYXJkd2FyZSBmZWF0dXJlczolcyVzJXMlcyVzJXMl cyVzJXMlcyVzJXMlcyVzJXNcbiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1 ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUlNCKSkgPyAiIElCUlMvSUJQQiIg OiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZF QVRVUkVfU1RJQlApKSA/ICIgU1RJQlAiICAgICA6ICIiLAogICAgICAgICAg ICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9MMURfRkxVU0gp KSA/ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICAoXzdkMCAmIGNw dWZlYXRfbWFzayhYODZfRkVBVFVSRV9TU0JEKSkgID8gIiBTU0JEIiAgICAg IDogIiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1ZmVhdF9tYXNrKFg4Nl9G RUFUVVJFX01EX0NMRUFSKSkgPyAiIE1EX0NMRUFSIiA6ICIiLAorICAgICAg ICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9TUkJEU19D VFJMKSkgPyAiIFNSQkRTX0NUUkwiIDogIiIsCiAgICAgICAgICAgIChlOGIg ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX0lCUEIpKSAgPyAiIElCUEIi ICAgICAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfSUJS U19BTEwpICAgICAgICAgICAgICA/ICIgSUJSU19BTEwiICA6ICIiLAogICAg ICAgICAgICAoY2FwcyAmIEFSQ0hfQ0FQU19SRENMX05PKSAgICAgICAgICAg ICAgID8gIiBSRENMX05PIiAgIDogIiIsCmRpZmYgLS1naXQgYS94ZW4vaW5j bHVkZS9hc20teDg2L21zci1pbmRleC5oIGIveGVuL2luY2x1ZGUvYXNtLXg4 Ni9tc3ItaW5kZXguaAppbmRleCA1ZWY4MDczNWIyLi5kMTQzNWRiNmEzIDEw MDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRleC5oCisr KyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4LmgKQEAgLTE3Nyw2 ICsxNzcsOSBAQAogI2RlZmluZSBNU1JfSUEzMl9WTVhfVFJVRV9FTlRSWV9D VExTICAgICAgICAgICAgMHg0OTAKICNkZWZpbmUgTVNSX0lBMzJfVk1YX1ZN RlVOQyAgICAgICAgICAgICAgICAgICAgIDB4NDkxCiAKKyNkZWZpbmUgTVNS X01DVV9PUFRfQ1RSTCAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDEyMwor I2RlZmluZSAgTUNVX09QVF9DVFJMX1JOR0RTX01JVEdfRElTICAgICAgICAo X0FDKDEsIFVMTCkgPDwgIDApCisKIC8qIEs3L0s4IE1TUnMuIE5vdCBjb21w bGV0ZS4gU2VlIHRoZSBhcmNoaXRlY3R1cmUgbWFudWFsIGZvciBhIG1vcmUK ICAgIGNvbXBsZXRlIGxpc3QuICovCiAjZGVmaW5lIE1TUl9LN19FVk5UU0VM MAkJCTB4YzAwMTAwMDAKZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1Ymxp Yy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmggYi94ZW4vaW5jbHVkZS9wdWJs aWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCmluZGV4IGExNGQ4YTcwMTMu LjlkMjEwZTc0YTAgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL3B1YmxpYy9h cmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKKysrIGIveGVuL2luY2x1ZGUvcHVi bGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaApAQCAtMjQyLDYgKzI0Miw3 IEBAIFhFTl9DUFVGRUFUVVJFKElCUEIsICAgICAgICAgIDgqMzIrMTIpIC8q QSAgSUJQQiBzdXBwb3J0IG9ubHkgKG5vIElCUlMsIHVzZWQgYnkKIC8qIElu dGVsLWRlZmluZWQgQ1BVIGZlYXR1cmVzLCBDUFVJRCBsZXZlbCAweDAwMDAw MDA3OjAuZWR4LCB3b3JkIDkgKi8KIFhFTl9DUFVGRUFUVVJFKEFWWDUxMl80 Vk5OSVcsIDkqMzIrIDIpIC8qQSAgQVZYNTEyIE5ldXJhbCBOZXR3b3JrIElu c3RydWN0aW9ucyAqLwogWEVOX0NQVUZFQVRVUkUoQVZYNTEyXzRGTUFQUywg OSozMisgMykgLypBICBBVlg1MTIgTXVsdGlwbHkgQWNjdW11bGF0aW9uIFNp bmdsZSBQcmVjaXNpb24gKi8KK1hFTl9DUFVGRUFUVVJFKFNSQkRTX0NUUkws ICAgIDkqMzIrIDkpIC8qICAgTVNSX01DVV9PUFRfQ1RSTCBhbmQgUk5HRFNf TUlUR19ESVMuICovCiBYRU5fQ1BVRkVBVFVSRShNRF9DTEVBUiwgICAgICA5 KjMyKzEwKSAvKkEgIFZFUlcgY2xlYXJzIG1pY3JvYXJjaGl0ZWN0dXJhbCBi dWZmZXJzICovCiBYRU5fQ1BVRkVBVFVSRShUU1hfRk9SQ0VfQUJPUlQsIDkq MzIrMTMpIC8qIE1TUl9UU1hfRk9SQ0VfQUJPUlQuUlRNX0FCT1JUICovCiBY RU5fQ1BVRkVBVFVSRShJQlJTQiwgICAgICAgICA5KjMyKzI2KSAvKkEgIElC UlMgYW5kIElCUEIgc3VwcG9ydCAodXNlZCBieSBJbnRlbCkgKi8K --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.10-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.10-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5t YXJrZG93biBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du CmluZGV4IGFiMjZhMjYzODEuLmI5NmY5M2M5NWUgMTAwNjQ0Ci0tLSBhL2Rv Y3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBiL2RvY3Mv bWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCkBAIC0xODA5LDcgKzE4 MDksNyBAQCBmYWxzZSBkaXNhYmxlIHRoZSBxdWlyayB3b3JrYXJvdW5kLCB3 aGljaCBpcyBhbHNvIHRoZSBkZWZhdWx0LgogIyMjIHNwZWMtY3RybCAoeDg2 KQogPiBgPSBMaXN0IG9mIFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZt LG1zci1zYyxyc2IsbWQtY2xlYXJ9PTxib29sPiwKID4gICAgICAgICAgICAg IGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZlbmNlfGptcCwge2licnMsaWJwYixz c2JkLGVhZ2VyLWZwdSwKLT4gICAgICAgICAgICAgIGwxZC1mbHVzaH09PGJv b2w+IF1gCis+ICAgICAgICAgICAgICBsMWQtZmx1c2gsc3JiLWxvY2t9PTxi b29sPiBdYAogCiBDb250cm9scyBmb3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9u IHNpZGVjaGFubmVsIG1pdGlnYXRpb25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3 aWxsIHBpY2sgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFz ZWQgb24gY29tcGlsZWQgaW4gc3VwcG9ydCwKQEAgLTE4ODEsNiArMTg4MSwx MiBAQCBJcnJlc3BlY3RpdmUgb2YgWGVuJ3Mgc2V0dGluZywgdGhlIGZlYXR1 cmUgaXMgdmlydHVhbGlzZWQgZm9yIEhWTSBndWVzdHMgdG8KIHVzZS4gIEJ5 IGRlZmF1bHQsIFhlbiB3aWxsIGVuYWJsZSB0aGlzIG1pdGlnYXRpb24gb24g aGFyZHdhcmUgYmVsaWV2ZWQgdG8gYmUKIHZ1bG5lcmFibGUgdG8gTDFURi4K IAorT24gaGFyZHdhcmUgc3VwcG9ydGluZyBTUkJEU19DVFJMLCB0aGUgYHNy Yi1sb2NrPWAgb3B0aW9uIGNhbiBiZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2 ZW50IFhlbiBmcm9tIHByb3RlY3QgdGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVm ZmVyIGZyb20gbGVha2luZyBzdGFsZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVu IHdpbGwgZW5hYmxlIHRoaXMgbWl0aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRz IHdoZXJlIE1EUworaXMgZml4ZWQgYW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0 ZWQgKGluIHdoaWNoIGNhc2UsIHRoZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5v Cit3YXkgZm9yIGFuIGF0dGFja2VyIHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0 YSkuCisKICMjIyBzeW5jXF9jb25zb2xlCiA+IGA9IDxib29sZWFuPmAKIApk aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYyBiL3hlbi9h cmNoL3g4Ni9hY3BpL3Bvd2VyLmMKaW5kZXggZjM0ODBhYTgwMC4uNGQ3MmI2 Y2U5NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwor KysgYi94ZW4vYXJjaC94ODYvYWNwaS9wb3dlci5jCkBAIC0yNTksNiArMjU5 LDkgQEAgc3RhdGljIGludCBlbnRlcl9zdGF0ZSh1MzIgc3RhdGUpCiAgICAg Y2ktPnNwZWNfY3RybF9mbGFncyB8PSAoZGVmYXVsdF9zcGVjX2N0cmxfZmxh Z3MgJiBTQ0ZfaXN0X3dybXNyKTsKICAgICBzcGVjX2N0cmxfZXhpdF9pZGxl KGNpKTsKIAorICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NS QkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkws IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CisKICBkb25lOgogICAgIHNw aW5fZGVidWdfZW5hYmxlKCk7CiAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh Z3MpOwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYyBiL3hl bi9hcmNoL3g4Ni9zbXBib290LmMKaW5kZXggY2RmNTNhZmMxZS4uYjRhMDlm MmRjMiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYworKysg Yi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCkBAIC0zNjMsMTIgKzM2MywxNCBA QCB2b2lkIHN0YXJ0X3NlY29uZGFyeSh2b2lkICp1bnVzZWQpCiAgICAgICAg IG1pY3JvY29kZV9yZXN1bWVfY3B1KGNwdSk7CiAKICAgICAvKgotICAgICAq IElmIE1TUl9TUEVDX0NUUkwgaXMgYXZhaWxhYmxlLCBhcHBseSBYZW4ncyBk ZWZhdWx0IHNldHRpbmcgYW5kIGRpc2NhcmQKLSAgICAgKiBhbnkgZmlybXdh cmUgc2V0dGluZ3MuICBOb3RlOiBNU1JfU1BFQ19DVFJMIG1heSBvbmx5IGJl Y29tZSBhdmFpbGFibGUKLSAgICAgKiBhZnRlciBsb2FkaW5nIG1pY3JvY29k ZS4KKyAgICAgKiBJZiBhbnkgc3BlY3VsYXRpdmUgY29udHJvbCBNU1JzIGFy ZSBhdmFpbGFibGUsIGFwcGx5IFhlbidzIGRlZmF1bHQKKyAgICAgKiBzZXR0 aW5ncy4gIE5vdGU6IFRoZXNlIE1TUnMgbWF5IG9ubHkgYmVjb21lIGF2YWls YWJsZSBhZnRlciBsb2FkaW5nCisgICAgICogbWljcm9jb2RlLgogICAgICAq LwogICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0lCUlNCKSAp CiAgICAgICAgIHdybXNybChNU1JfU1BFQ19DVFJMLCBkZWZhdWx0X3hlbl9z cGVjX2N0cmwpOworICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF X1NSQkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NU UkwsIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CiAKICAgICB0c3hfaW5p dCgpOyAvKiBOZWVkcyBtaWNyb2NvZGUuICBNYXkgY2hhbmdlIEhMRS9SVE0g ZmVhdHVyZSBiaXRzLiAqLwogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg Yjc3MzNiMzRmNi4uY2MwOTQ2Yjk2MyAxMDA2NDQKLS0tIGEveGVuL2FyY2gv eDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu YwpAQCAtNjMsNiArNjMsOSBAQCBzdGF0aWMgdW5zaWduZWQgaW50IF9faW5p dGRhdGEgbDFkX21heHBoeXNhZGRyOwogc3RhdGljIGJvb2wgX19pbml0ZGF0 YSBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5OyAvKiA9PiBtaW5pbWFsIEhUIGlt cGFjdC4gKi8KIHN0YXRpYyBib29sIF9faW5pdGRhdGEgY3B1X2hhc19idWdf bWRzOyAvKiBBbnkgb3RoZXIgTXtMUCxTQixGQn1EUyBjb21iaW5hdGlvbi4g Ki8KIAorc3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9zcmJfbG9jayA9 IC0xOwordWludDY0X3QgX19yZWFkX21vc3RseSBkZWZhdWx0X3hlbl9tY3Vf b3B0X2N0cmw7CisKIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2J0aShjb25z dCBjaGFyICpzKQogewogICAgIGNvbnN0IGNoYXIgKnNzOwpAQCAtMTUwLDYg KzE1Myw3IEBAIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChj b25zdCBjaGFyICpzKQogICAgICAgICAgICAgb3B0X2licGIgPSBmYWxzZTsK ICAgICAgICAgICAgIG9wdF9zc2JkID0gZmFsc2U7CiAgICAgICAgICAgICBv cHRfbDFkX2ZsdXNoID0gMDsKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9 IDA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZSBpZiAoIHZhbCA+IDAgKQog ICAgICAgICAgICAgcmMgPSAtRUlOVkFMOwpAQCAtMjE1LDYgKzIxOSw4IEBA IHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFy ICpzKQogICAgICAgICAgICAgb3B0X2VhZ2VyX2ZwdSA9IHZhbDsKICAgICAg ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJsMWQtZmx1c2gi LCBzLCBzcykpID49IDAgKQogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9 IHZhbDsKKyAgICAgICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFu KCJzcmItbG9jayIsIHMsIHNzKSkgPj0gMCApCisgICAgICAgICAgICBvcHRf c3JiX2xvY2sgPSB2YWw7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJj ID0gLUVJTlZBTDsKIApAQCAtMzc4LDcgKzM4NCw3IEBAIHN0YXRpYyB2b2lk IF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rLCB1 aW50NjRfdCBjYXBzKQogICAgICAgICAgICAgICAgIlxuIik7CiAKICAgICAv KiBTZXR0aW5ncyBmb3IgWGVuJ3MgcHJvdGVjdGlvbiwgaXJyZXNwZWN0aXZl IG9mIGd1ZXN0cy4gKi8KLSAgICBwcmludGsoIiAgWGVuIHNldHRpbmdzOiBC VEktVGh1bmsgJXMsIFNQRUNfQ1RSTDogJXMlcyVzLCBPdGhlcjolcyVzJXNc biIsCisgICAgcHJpbnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVz LCBTUEVDX0NUUkw6ICVzJXMlcywgT3RoZXI6JXMlcyVzJXNcbiIsCiAgICAg ICAgICAgIHRodW5rID09IFRIVU5LX05PTkUgICAgICA/ICJOL0EiIDoKICAg ICAgICAgICAgdGh1bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBPTElO RSIgOgogICAgICAgICAgICB0aHVuayA9PSBUSFVOS19MRkVOQ0UgICAgPyAi TEZFTkNFIiA6CkBAIC0zODksNiArMzk1LDggQEAgc3RhdGljIHZvaWQgX19p bml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVpbnQ2 NF90IGNhcHMpCiAgICAgICAgICAgIChkZWZhdWx0X3hlbl9zcGVjX2N0cmwg JiBTUEVDX0NUUkxfU1NCRCkgID8gIiBTU0JEKyIgOiAiIFNTQkQtIiwKICAg ICAgICAgICAgIShjYXBzICYgQVJDSF9DQVBTX1RTWF9DVFJMKSAgICAgICAg ICAgICAgPyAiIiA6CiAgICAgICAgICAgIChvcHRfdHN4ICYgMSkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID8gIiBUU1grIiA6ICIgVFNYLSIsCisg ICAgICAgICAgICFib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RS TCkgICAgID8gIiIgOgorICAgICAgICAgICBvcHRfc3JiX2xvY2sgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA/ICIgU1JCX0xPQ0srIiA6ICIgU1JC X0xPQ0stIiwKICAgICAgICAgICAgb3B0X2licGIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPyAiIElCUEIiICA6ICIiLAogICAgICAgICAg ICBvcHRfbDFkX2ZsdXNoICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICBvcHRfbWRfY2xlYXJf cHYgfHwgb3B0X21kX2NsZWFyX2h2bSAgICAgICA/ICIgVkVSVyIgIDogIiIp OwpAQCAtMTE3Niw2ICsxMTg0LDM0IEBAIHZvaWQgX19pbml0IGluaXRfc3Bl Y3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKICAgICAgICAgdHN4X2luaXQo KTsKICAgICB9CiAKKyAgICAvKiBDYWxjdWxhdGUgc3VpdGFibGUgZGVmYXVs dHMgZm9yIE1TUl9NQ1VfT1BUX0NUUkwgKi8KKyAgICBpZiAoIGJvb3RfY3B1 X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSApCisgICAgeworICAgICAg ICB1aW50NjRfdCB2YWw7CisKKyAgICAgICAgcmRtc3JsKE1TUl9NQ1VfT1BU X0NUUkwsIHZhbCk7CisKKyAgICAgICAgLyoKKyAgICAgICAgICogT24gc29t ZSBTUkJEUy1hZmZlY3RlZCBoYXJkd2FyZSwgaXQgbWF5IGJlIHNhZmUgdG8g cmVsYXggc3JiLWxvY2sKKyAgICAgICAgICogYnkgZGVmYXVsdC4KKyAgICAg ICAgICoKKyAgICAgICAgICogT24gcGFydHMgd2hpY2ggZW51bWVyYXRlIE1E U19OTyBhbmQgbm90IFRBQV9OTywgVFNYIGlzIHRoZSBvbmx5IHdheQorICAg ICAgICAgKiB0byBhY2Nlc3MgdGhlIEZpbGwgQnVmZmVyLiAgSWYgVFNYIGlz bid0IGF2YWlsYWJsZSAoaW5jLiBTS1UKKyAgICAgICAgICogcmVhc29ucyBv biBzb21lIG1vZGVscyksIG9yIFRTWCBpcyBleHBsaWNpdGx5IGRpc2FibGVk LCB0aGVuIHRoZXJlCisgICAgICAgICAqIGlzIG5vIG5lZWQgZm9yIHRoZSBl eHRyYSBvdmVyaGVhZCB0byBwcm90ZWN0IFJEUkFORC9SRFNFRUQuCisgICAg ICAgICAqLworICAgICAgICBpZiAoIG9wdF9zcmJfbG9jayA9PSAtMSAmJgor ICAgICAgICAgICAgIChjYXBzICYgKEFSQ0hfQ0FQU19NRFNfTk98QVJDSF9D QVBTX1RBQV9OTykpID09IEFSQ0hfQ0FQU19NRFNfTk8gJiYKKyAgICAgICAg ICAgICAoIWNwdV9oYXNfaGxlIHx8ICgoY2FwcyAmIEFSQ0hfQ0FQU19UU1hf Q1RSTCkgJiYgb3B0X3RzeCA9PSAwKSkgKQorICAgICAgICAgICAgb3B0X3Ny Yl9sb2NrID0gMDsKKworICAgICAgICB2YWwgJj0gfk1DVV9PUFRfQ1RSTF9S TkdEU19NSVRHX0RJUzsKKyAgICAgICAgaWYgKCAhb3B0X3NyYl9sb2NrICkK KyAgICAgICAgICAgIHZhbCB8PSBNQ1VfT1BUX0NUUkxfUk5HRFNfTUlUR19E SVM7CisKKyAgICAgICAgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsID0gdmFs OworICAgIH0KKwogICAgIHByaW50X2RldGFpbHModGh1bmssIGNhcHMpOwog CiAgICAgLyoKQEAgLTEyMDcsNiArMTI0Myw5IEBAIHZvaWQgX19pbml0IGlu aXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKIAogICAgICAgICB3 cm1zcmwoTVNSX1NQRUNfQ1RSTCwgYnNwX2RlbGF5X3NwZWNfY3RybCA/IDAg OiBkZWZhdWx0X3hlbl9zcGVjX2N0cmwpOwogICAgIH0KKworICAgIGlmICgg Ym9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICAg ICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkwsIGRlZmF1bHRfeGVuX21jdV9v cHRfY3RybCk7CiB9CiAKIHN0YXRpYyB2b2lkIF9faW5pdCBfX21heWJlX3Vu dXNlZCBidWlsZF9hc3NlcnRpb25zKHZvaWQpCmRpZmYgLS1naXQgYS94ZW4v aW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oIGIveGVuL2luY2x1ZGUvYXNt LXg4Ni9zcGVjX2N0cmwuaAppbmRleCA5OGEwYTUwNGY2Li5kZjg2MmVjNGQw IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5o CisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvc3BlY19jdHJsLmgKQEAgLTQ2 LDYgKzQ2LDggQEAgZXh0ZXJuIGludDhfdCBvcHRfcHZfbDF0Zl9od2RvbSwg b3B0X3B2X2wxdGZfZG9tdTsKICAqLwogZXh0ZXJuIHBhZGRyX3QgbDF0Zl9h ZGRyX21hc2ssIGwxdGZfc2FmZV9tYWRkcjsKIAorZXh0ZXJuIHVpbnQ2NF90 IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybDsKKwogc3RhdGljIGlubGluZSB2 b2lkIGluaXRfc2hhZG93X3NwZWNfY3RybF9zdGF0ZSh2b2lkKQogewogICAg IHN0cnVjdCBjcHVfaW5mbyAqaW5mbyA9IGdldF9jcHVfaW5mbygpOwo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.10-3.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.10-3.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQWxsb3cgdGhlIFJEUkFORC9S RFNFRUQgZmVhdHVyZXMgdG8gYmUgaGlkZGVuCgpSRFJBTkQvUkRTRUVEIGNh biBiZSBoaWRkZW4gdXNpbmcgY3B1aWQ9IHRvIG1pdGlnYXRlIFNSQkRTIGlm IG1pY3JvY29kZQppc24ndCBhdmFpbGFibGUuCgpUaGlzIGlzIHBhcnQgb2Yg WFNBLTMyMCAvIENWRS0yMDIwLTA1NDMuCgpTaWduZWQtb2ZmLWJ5OiBBbmRy ZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpBY2tlZC1i eTogSnVsaWVuIEdyYWxsIDxqZ3JhbGxAYW1hem9uLmNvbT4KCmRpZmYgLS1n aXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5tYXJrZG93biBiL2Rv Y3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCmluZGV4IGI5NmY5 M2M5NWUuLmFhZTgwZTgyYjYgMTAwNjQ0Ci0tLSBhL2RvY3MvbWlzYy94ZW4t Y29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBiL2RvY3MvbWlzYy94ZW4tY29t bWFuZC1saW5lLm1hcmtkb3duCkBAIC00OTQsMTIgKzQ5NCwxOCBAQCBjaG9p Y2Ugb2YgYGRvbTAta2VybmVsYCBpcyBkZXByZWNhdGVkIGFuZCBub3Qgc3Vw cG9ydGVkIGJ5IGFsbCBEb20wIGtlcm5lbHMuCiBUaGlzIG9wdGlvbiBhbGxv d3MgZm9yIGZpbmUgdHVuaW5nIG9mIHRoZSBmYWNpbGl0aWVzIFhlbiB3aWxs IHVzZSwgYWZ0ZXIKIGFjY291bnRpbmcgZm9yIGhhcmR3YXJlIGNhcGFiaWxp dGllcyBhcyBlbnVtZXJhdGVkIHZpYSBDUFVJRC4KIAorVW5sZXNzIG90aGVy d2lzZSBub3RlZCwgb3B0aW9ucyBvbmx5IGhhdmUgYW55IGVmZmVjdCBpbiB0 aGVpciBuZWdhdGl2ZSBmb3JtLAordG8gaGlkZSB0aGUgbmFtZWQgZmVhdHVy ZShzKS4gIElnbm9yaW5nIGEgZmVhdHVyZSB1c2luZyB0aGlzIG1lY2hhbmlz bSB3aWxsCitjYXVzZSBYZW4gbm90IHRvIHVzZSB0aGUgZmVhdHVyZSwgbm9y IG9mZmVyIHRoZW0gYXMgdXNhYmxlIHRvIGd1ZXN0cy4KKwogQ3VycmVudGx5 IGFjY2VwdGVkOgogCiBUaGUgU3BlY3VsYXRpb24gQ29udHJvbCBoYXJkd2Fy ZSBmZWF0dXJlcyBgc3JiZHMtY3RybGAsIGBtZC1jbGVhcmAsIGBpYnJzYmAs CiBgc3RpYnBgLCBgaWJwYmAsIGBsMWQtZmx1c2hgIGFuZCBgc3NiZGAgYXJl IHVzZWQgYnkgZGVmYXVsdCBpZiBhdmFpbGFibGUgYW5kCi1hcHBsaWNhYmxl LiAgVGhleSBjYW4gYmUgaWdub3JlZCwgZS5nLiBgbm8taWJyc2JgLCBhdCB3 aGljaCBwb2ludCBYZW4gd29uJ3QKLXVzZSB0aGVtIGl0c2VsZiwgYW5kIHdv bid0IG9mZmVyIHRoZW0gdG8gZ3Vlc3RzLgorYXBwbGljYWJsZS4gIFRoZXkg Y2FuIGFsbCBiZSBpZ25vcmVkLgorCitgcmRyYW5kYCBhbmQgYHJkc2VlZGAg Y2FuIGJlIGlnbm9yZWQsIGFzIGEgbWl0aWdhdGlvbiB0byBYU0EtMzIwIC8K K0NWRS0yMDIwLTA1NDMuCiAKICMjIyBjcHVpZFxfbWFza1xfY3B1IChBTUQg b25seSkKID4gYD0gZmFtXzBmX3Jldl9jIHwgZmFtXzBmX3Jldl9kIHwgZmFt XzBmX3Jldl9lIHwgZmFtXzBmX3Jldl9mIHwgZmFtXzBmX3Jldl9nIHwgZmFt XzEwX3Jldl9iIHwgZmFtXzEwX3Jldl9jIHwgZmFtXzExX3Jldl9iYApkaWZm IC0tZ2l0IGEveGVuL2FyY2gveDg2L2NwdWlkLmMgYi94ZW4vYXJjaC94ODYv Y3B1aWQuYwppbmRleCA2N2EyYTJlNmEwLi5iNWJlZjgzZDcwIDEwMDY0NAot LS0gYS94ZW4vYXJjaC94ODYvY3B1aWQuYworKysgYi94ZW4vYXJjaC94ODYv Y3B1aWQuYwpAQCAtNjMsNiArNjMsMTYgQEAgc3RhdGljIGludCBfX2luaXQg cGFyc2VfeGVuX2NwdWlkKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBp ZiAoICF2YWwgKQogICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2NwdV9j YXAoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCk7CiAgICAgICAgIH0KKyAgICAg ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJyZHJhbmQiLCBz LCBzcykpID49IDAgKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoICF2 YWwgKQorICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2NwdV9jYXAoWDg2 X0ZFQVRVUkVfUkRSQU5EKTsKKyAgICAgICAgfQorICAgICAgICBlbHNlIGlm ICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oInJkc2VlZCIsIHMsIHNzKSkgPj0g MCApCisgICAgICAgIHsKKyAgICAgICAgICAgIGlmICggIXZhbCApCisgICAg ICAgICAgICAgICAgc2V0dXBfY2xlYXJfY3B1X2NhcChYODZfRkVBVFVSRV9S RFNFRUQpOworICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgICAg IHJjID0gLUVJTlZBTDsKIAo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.11-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.11-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du IGIvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KaW5kZXgg MTk0NjE1YmZjNS4uOWJlMThhYzk5ZiAxMDA2NDQKLS0tIGEvZG9jcy9taXNj L3hlbi1jb21tYW5kLWxpbmUubWFya2Rvd24KKysrIGIvZG9jcy9taXNjL3hl bi1jb21tYW5kLWxpbmUubWFya2Rvd24KQEAgLTQ4OSwxMCArNDg5LDEwIEBA IGFjY291bnRpbmcgZm9yIGhhcmR3YXJlIGNhcGFiaWxpdGllcyBhcyBlbnVt ZXJhdGVkIHZpYSBDUFVJRC4KIAogQ3VycmVudGx5IGFjY2VwdGVkOgogCi1U aGUgU3BlY3VsYXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgbWQt Y2xlYXJgLCBgaWJyc2JgLCBgc3RpYnBgLCBgaWJwYmAsCi1gbDFkLWZsdXNo YCBhbmQgYHNzYmRgIGFyZSB1c2VkIGJ5IGRlZmF1bHQgaWYgYXZhaWxhYmxl IGFuZCBhcHBsaWNhYmxlLiAgVGhleSBjYW4KLWJlIGlnbm9yZWQsIGUuZy4g YG5vLWlicnNiYCwgYXQgd2hpY2ggcG9pbnQgWGVuIHdvbid0IHVzZSB0aGVt IGl0c2VsZiwgYW5kCi13b24ndCBvZmZlciB0aGVtIHRvIGd1ZXN0cy4KK1Ro ZSBTcGVjdWxhdGlvbiBDb250cm9sIGhhcmR3YXJlIGZlYXR1cmVzIGBzcmJk cy1jdHJsYCwgYG1kLWNsZWFyYCwgYGlicnNiYCwKK2BzdGlicGAsIGBpYnBi YCwgYGwxZC1mbHVzaGAgYW5kIGBzc2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0 IGlmIGF2YWlsYWJsZSBhbmQKK2FwcGxpY2FibGUuICBUaGV5IGNhbiBiZSBp Z25vcmVkLCBlLmcuIGBuby1pYnJzYmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3 b24ndAordXNlIHRoZW0gaXRzZWxmLCBhbmQgd29uJ3Qgb2ZmZXIgdGhlbSB0 byBndWVzdHMuCiAKICMjIyBjcHVpZFxfbWFza1xfY3B1IChBTUQgb25seSkK ID4gYD0gZmFtXzBmX3Jldl9jIHwgZmFtXzBmX3Jldl9kIHwgZmFtXzBmX3Jl dl9lIHwgZmFtXzBmX3Jldl9mIHwgZmFtXzBmX3Jldl9nIHwgZmFtXzEwX3Jl dl9iIHwgZmFtXzEwX3Jldl9jIHwgZmFtXzExX3Jldl9iYApkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhsL2xp YnhsX2NwdWlkLmMKaW5kZXggNWExNzAyZDcwMy4uMTIzNWM4YjkxZSAxMDA2 NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90b29s cy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0yMDIsNiArMjAyLDcgQEAgaW50 IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xpY3lf bGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKIAogICAgICAgICB7ImF2 eDUxMi00dm5uaXciLDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAg MiwgIDF9LAogICAgICAgICB7ImF2eDUxMi00Zm1hcHMiLDB4MDAwMDAwMDcs ICAwLCBDUFVJRF9SRUdfRURYLCAgMywgIDF9LAorICAgICAgICB7InNyYmRz LWN0cmwiLCAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAgOSwg IDF9LAogICAgICAgICB7Im1kLWNsZWFyIiwgICAgIDB4MDAwMDAwMDcsICAw LCBDUFVJRF9SRUdfRURYLCAxMCwgIDF9LAogICAgICAgICB7ImlicnNiIiwg ICAgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyNiwgIDF9 LAogICAgICAgICB7InN0aWJwIiwgICAgICAgIDB4MDAwMDAwMDcsICAwLCBD UFVJRF9SRUdfRURYLCAyNywgIDF9LApkaWZmIC0tZ2l0IGEvdG9vbHMvbWlz Yy94ZW4tY3B1aWQuYyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKaW5kZXgg NGM5YWY2YjdmMC4uOGZiNTRjMzAwMSAxMDA2NDQKLS0tIGEvdG9vbHMvbWlz Yy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNjL3hlbi1jcHVpZC5jCkBA IC0xNDIsNiArMTQyLDcgQEAgc3RhdGljIGNvbnN0IGNoYXIgKnN0cl83ZDBb MzJdID0KIHsKICAgICBbIDJdID0gImF2eDUxMl80dm5uaXciLCBbIDNdID0g ImF2eDUxMl80Zm1hcHMiLAogCisgICAgLyogIDggKi8gICAgICAgICAgICAg ICAgWyA5XSA9ICJzcmJkcy1jdHJsIiwKICAgICBbMTBdID0gIm1kLWNsZWFy IiwKICAgICAvKiAxMiAqLyAgICAgICAgICAgICAgICBbMTNdID0gInRzeC1m b3JjZS1hYm9ydCIsCiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9jcHVp ZC5jIGIveGVuL2FyY2gveDg2L2NwdWlkLmMKaW5kZXggMDRhZWZhNTU1ZC4u YjhlNWI2ZmU2NyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2NwdWlkLmMK KysrIGIveGVuL2FyY2gveDg2L2NwdWlkLmMKQEAgLTU4LDYgKzU4LDExIEBA IHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3hlbl9jcHVpZChjb25zdCBjaGFy ICpzKQogICAgICAgICAgICAgaWYgKCAhdmFsICkKICAgICAgICAgICAgICAg ICBzZXR1cF9jbGVhcl9jcHVfY2FwKFg4Nl9GRUFUVVJFX1NTQkQpOwogICAg ICAgICB9CisgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVh bigic3JiZHMtY3RybCIsIHMsIHNzKSkgPj0gMCApCisgICAgICAgIHsKKyAg ICAgICAgICAgIGlmICggIXZhbCApCisgICAgICAgICAgICAgICAgc2V0dXBf Y2xlYXJfY3B1X2NhcChYODZfRkVBVFVSRV9TUkJEU19DVFJMKTsKKyAgICAg ICAgfQogICAgICAgICBlbHNlCiAgICAgICAgICAgICByYyA9IC1FSU5WQUw7 CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9tc3IuYyBiL3hlbi9hcmNo L3g4Ni9tc3IuYwppbmRleCBjY2IzMTZjNTQ3Li4yNTZlNThkODJiIDEwMDY0 NAotLS0gYS94ZW4vYXJjaC94ODYvbXNyLmMKKysrIGIveGVuL2FyY2gveDg2 L21zci5jCkBAIC0xNTQsNiArMTU0LDcgQEAgaW50IGd1ZXN0X3JkbXNyKGNv bnN0IHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90ICp2 YWwpCiAgICAgICAgIC8qIFdyaXRlLW9ubHkgKi8KICAgICBjYXNlIE1TUl9U U1hfRk9SQ0VfQUJPUlQ6CiAgICAgY2FzZSBNU1JfVFNYX0NUUkw6CisgICAg Y2FzZSBNU1JfTUNVX09QVF9DVFJMOgogICAgICAgICAvKiBOb3Qgb2ZmZXJl ZCB0byBndWVzdHMuICovCiAgICAgICAgIGdvdG8gZ3BfZmF1bHQ7CiAKQEAg LTI0Myw2ICsyNDQsNyBAQCBpbnQgZ3Vlc3Rfd3Jtc3Ioc3RydWN0IHZjcHUg KnYsIHVpbnQzMl90IG1zciwgdWludDY0X3QgdmFsKQogICAgICAgICAvKiBS ZWFkLW9ubHkgKi8KICAgICBjYXNlIE1TUl9UU1hfRk9SQ0VfQUJPUlQ6CiAg ICAgY2FzZSBNU1JfVFNYX0NUUkw6CisgICAgY2FzZSBNU1JfTUNVX09QVF9D VFJMOgogICAgICAgICAvKiBOb3Qgb2ZmZXJlZCB0byBndWVzdHMuICovCiAg ICAgICAgIGdvdG8gZ3BfZmF1bHQ7CiAKZGlmZiAtLWdpdCBhL3hlbi9hcmNo L3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpp bmRleCBhYjE5NmIxNTZkLi45NGFiOGRkNzg2IDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNf Y3RybC5jCkBAIC0zNjUsMTIgKzM2NSwxMyBAQCBzdGF0aWMgdm9pZCBfX2lu aXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0 X3QgY2FwcykKICAgICBwcmludGsoIlNwZWN1bGF0aXZlIG1pdGlnYXRpb24g ZmFjaWxpdGllczpcbiIpOwogCiAgICAgLyogSGFyZHdhcmUgZmVhdHVyZXMg d2hpY2ggcGVydGFpbiB0byBzcGVjdWxhdGl2ZSBtaXRpZ2F0aW9ucy4gKi8K LSAgICBwcmludGsoIiAgSGFyZHdhcmUgZmVhdHVyZXM6JXMlcyVzJXMlcyVz JXMlcyVzJXMlcyVzJXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUg ZmVhdHVyZXM6JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAog ICAgICAgICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9J QlJTQikpID8gIiBJQlJTL0lCUEIiIDogIiIsCiAgICAgICAgICAgIChfN2Qw ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX1NUSUJQKSkgPyAiIFNUSUJQ IiAgICAgOiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2so WDg2X0ZFQVRVUkVfTDFEX0ZMVVNIKSkgPyAiIEwxRF9GTFVTSCIgOiAiIiwK ICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVf U1NCRCkpICA/ICIgU1NCRCIgICAgICA6ICIiLAogICAgICAgICAgICAoXzdk MCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9NRF9DTEVBUikpID8gIiBN RF9DTEVBUiIgOiAiIiwKKyAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21h c2soWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkpID8gIiBTUkJEU19DVFJMIiA6 ICIiLAogICAgICAgICAgICAoZThiICAmIGNwdWZlYXRfbWFzayhYODZfRkVB VFVSRV9JQlBCKSkgID8gIiBJQlBCIiAgICAgIDogIiIsCiAgICAgICAgICAg IChjYXBzICYgQVJDSF9DQVBTX0lCUlNfQUxMKSAgICAgICAgICAgICAgPyAi IElCUlNfQUxMIiAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NB UFNfUkRDTF9OTykgICAgICAgICAgICAgICA/ICIgUkRDTF9OTyIgICA6ICIi LApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3ItaW5kZXgu aCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4LmgKaW5kZXggMTc2 MWEwMWYxZi4uNDgwZDFkODEwMiAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUv YXNtLXg4Ni9tc3ItaW5kZXguaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2 L21zci1pbmRleC5oCkBAIC0xNzcsNiArMTc3LDkgQEAKICNkZWZpbmUgTVNS X0lBMzJfVk1YX1RSVUVfRU5UUllfQ1RMUyAgICAgICAgICAgIDB4NDkwCiAj ZGVmaW5lIE1TUl9JQTMyX1ZNWF9WTUZVTkMgICAgICAgICAgICAgICAgICAg ICAweDQ5MQogCisjZGVmaW5lIE1TUl9NQ1VfT1BUX0NUUkwgICAgICAgICAg ICAgICAgICAgIDB4MDAwMDAxMjMKKyNkZWZpbmUgIE1DVV9PUFRfQ1RSTF9S TkdEU19NSVRHX0RJUyAgICAgICAgKF9BQygxLCBVTEwpIDw8ICAwKQorCiAv KiBLNy9LOCBNU1JzLiBOb3QgY29tcGxldGUuIFNlZSB0aGUgYXJjaGl0ZWN0 dXJlIG1hbnVhbCBmb3IgYSBtb3JlCiAgICBjb21wbGV0ZSBsaXN0LiAqLwog I2RlZmluZSBNU1JfSzdfRVZOVFNFTDAJCQkweGMwMDEwMDAwCmRpZmYgLS1n aXQgYS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNl dC5oIGIveGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVz ZXQuaAppbmRleCBhMTRkOGE3MDEzLi45ZDIxMGU3NGEwIDEwMDY0NAotLS0g YS94ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5o CisrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJl c2V0LmgKQEAgLTI0Miw2ICsyNDIsNyBAQCBYRU5fQ1BVRkVBVFVSRShJQlBC LCAgICAgICAgICA4KjMyKzEyKSAvKkEgIElCUEIgc3VwcG9ydCBvbmx5IChu byBJQlJTLCB1c2VkIGJ5CiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJl cywgQ1BVSUQgbGV2ZWwgMHgwMDAwMDAwNzowLmVkeCwgd29yZCA5ICovCiBY RU5fQ1BVRkVBVFVSRShBVlg1MTJfNFZOTklXLCA5KjMyKyAyKSAvKkEgIEFW WDUxMiBOZXVyYWwgTmV0d29yayBJbnN0cnVjdGlvbnMgKi8KIFhFTl9DUFVG RUFUVVJFKEFWWDUxMl80Rk1BUFMsIDkqMzIrIDMpIC8qQSAgQVZYNTEyIE11 bHRpcGx5IEFjY3VtdWxhdGlvbiBTaW5nbGUgUHJlY2lzaW9uICovCitYRU5f Q1BVRkVBVFVSRShTUkJEU19DVFJMLCAgICA5KjMyKyA5KSAvKiAgIE1TUl9N Q1VfT1BUX0NUUkwgYW5kIFJOR0RTX01JVEdfRElTLiAqLwogWEVOX0NQVUZF QVRVUkUoTURfQ0xFQVIsICAgICAgOSozMisxMCkgLypBICBWRVJXIGNsZWFy cyBtaWNyb2FyY2hpdGVjdHVyYWwgYnVmZmVycyAqLwogWEVOX0NQVUZFQVRV UkUoVFNYX0ZPUkNFX0FCT1JULCA5KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNF X0FCT1JULlJUTV9BQk9SVCAqLwogWEVOX0NQVUZFQVRVUkUoSUJSU0IsICAg ICAgICAgOSozMisyNikgLypBICBJQlJTIGFuZCBJQlBCIHN1cHBvcnQgKHVz ZWQgYnkgSW50ZWwpICovCg== --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.11-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.11-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5t YXJrZG93biBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3du CmluZGV4IDliZTE4YWM5OWYuLjMzNTZlNTlmZWUgMTAwNjQ0Ci0tLSBhL2Rv Y3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBiL2RvY3Mv bWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCkBAIC0xODU4LDcgKzE4 NTgsNyBAQCBmYWxzZSBkaXNhYmxlIHRoZSBxdWlyayB3b3JrYXJvdW5kLCB3 aGljaCBpcyBhbHNvIHRoZSBkZWZhdWx0LgogIyMjIHNwZWMtY3RybCAoeDg2 KQogPiBgPSBMaXN0IG9mIFsgPGJvb2w+LCB4ZW49PGJvb2w+LCB7cHYsaHZt LG1zci1zYyxyc2IsbWQtY2xlYXJ9PTxib29sPiwKID4gICAgICAgICAgICAg IGJ0aS10aHVuaz1yZXRwb2xpbmV8bGZlbmNlfGptcCwge2licnMsaWJwYixz c2JkLGVhZ2VyLWZwdSwKLT4gICAgICAgICAgICAgIGwxZC1mbHVzaH09PGJv b2w+IF1gCis+ICAgICAgICAgICAgICBsMWQtZmx1c2gsc3JiLWxvY2t9PTxi b29sPiBdYAogCiBDb250cm9scyBmb3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9u IHNpZGVjaGFubmVsIG1pdGlnYXRpb25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3 aWxsIHBpY2sgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFz ZWQgb24gY29tcGlsZWQgaW4gc3VwcG9ydCwKQEAgLTE5MzAsNiArMTkzMCwx MiBAQCBJcnJlc3BlY3RpdmUgb2YgWGVuJ3Mgc2V0dGluZywgdGhlIGZlYXR1 cmUgaXMgdmlydHVhbGlzZWQgZm9yIEhWTSBndWVzdHMgdG8KIHVzZS4gIEJ5 IGRlZmF1bHQsIFhlbiB3aWxsIGVuYWJsZSB0aGlzIG1pdGlnYXRpb24gb24g aGFyZHdhcmUgYmVsaWV2ZWQgdG8gYmUKIHZ1bG5lcmFibGUgdG8gTDFURi4K IAorT24gaGFyZHdhcmUgc3VwcG9ydGluZyBTUkJEU19DVFJMLCB0aGUgYHNy Yi1sb2NrPWAgb3B0aW9uIGNhbiBiZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2 ZW50IFhlbiBmcm9tIHByb3RlY3QgdGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVm ZmVyIGZyb20gbGVha2luZyBzdGFsZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVu IHdpbGwgZW5hYmxlIHRoaXMgbWl0aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRz IHdoZXJlIE1EUworaXMgZml4ZWQgYW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0 ZWQgKGluIHdoaWNoIGNhc2UsIHRoZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5v Cit3YXkgZm9yIGFuIGF0dGFja2VyIHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0 YSkuCisKICMjIyBzeW5jXF9jb25zb2xlCiA+IGA9IDxib29sZWFuPmAKIApk aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYyBiL3hlbi9h cmNoL3g4Ni9hY3BpL3Bvd2VyLmMKaW5kZXggNGMxMjc5NDgwOS4uMzBlMWJk NWNkMyAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwor KysgYi94ZW4vYXJjaC94ODYvYWNwaS9wb3dlci5jCkBAIC0yNjYsNiArMjY2 LDkgQEAgc3RhdGljIGludCBlbnRlcl9zdGF0ZSh1MzIgc3RhdGUpCiAgICAg Y2ktPnNwZWNfY3RybF9mbGFncyB8PSAoZGVmYXVsdF9zcGVjX2N0cmxfZmxh Z3MgJiBTQ0ZfaXN0X3dybXNyKTsKICAgICBzcGVjX2N0cmxfZXhpdF9pZGxl KGNpKTsKIAorICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NS QkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkws IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CisKICBkb25lOgogICAgIHNw aW5fZGVidWdfZW5hYmxlKCk7CiAgICAgbG9jYWxfaXJxX3Jlc3RvcmUoZmxh Z3MpOwpkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYyBiL3hl bi9hcmNoL3g4Ni9zbXBib290LmMKaW5kZXggMDg4NzgwNmU4NS4uZDI0ZDIx NTk0NiAxMDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NtcGJvb3QuYworKysg Yi94ZW4vYXJjaC94ODYvc21wYm9vdC5jCkBAIC0zNjksMTIgKzM2OSwxNCBA QCB2b2lkIHN0YXJ0X3NlY29uZGFyeSh2b2lkICp1bnVzZWQpCiAgICAgICAg IG1pY3JvY29kZV9yZXN1bWVfY3B1KGNwdSk7CiAKICAgICAvKgotICAgICAq IElmIE1TUl9TUEVDX0NUUkwgaXMgYXZhaWxhYmxlLCBhcHBseSBYZW4ncyBk ZWZhdWx0IHNldHRpbmcgYW5kIGRpc2NhcmQKLSAgICAgKiBhbnkgZmlybXdh cmUgc2V0dGluZ3MuICBOb3RlOiBNU1JfU1BFQ19DVFJMIG1heSBvbmx5IGJl Y29tZSBhdmFpbGFibGUKLSAgICAgKiBhZnRlciBsb2FkaW5nIG1pY3JvY29k ZS4KKyAgICAgKiBJZiBhbnkgc3BlY3VsYXRpdmUgY29udHJvbCBNU1JzIGFy ZSBhdmFpbGFibGUsIGFwcGx5IFhlbidzIGRlZmF1bHQKKyAgICAgKiBzZXR0 aW5ncy4gIE5vdGU6IFRoZXNlIE1TUnMgbWF5IG9ubHkgYmVjb21lIGF2YWls YWJsZSBhZnRlciBsb2FkaW5nCisgICAgICogbWljcm9jb2RlLgogICAgICAq LwogICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX0lCUlNCKSAp CiAgICAgICAgIHdybXNybChNU1JfU1BFQ19DVFJMLCBkZWZhdWx0X3hlbl9z cGVjX2N0cmwpOworICAgIGlmICggYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJF X1NSQkRTX0NUUkwpICkKKyAgICAgICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NU UkwsIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCk7CiAKICAgICB0c3hfaW5p dCgpOyAvKiBOZWVkcyBtaWNyb2NvZGUuICBNYXkgY2hhbmdlIEhMRS9SVE0g ZmVhdHVyZSBiaXRzLiAqLwogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94ODYv c3BlY19jdHJsLmMgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKaW5kZXgg OTRhYjhkZDc4Ni4uYTMwNmQxMGMzNCAxMDA2NDQKLS0tIGEveGVuL2FyY2gv eDg2L3NwZWNfY3RybC5jCisrKyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwu YwpAQCAtNjMsNiArNjMsOSBAQCBzdGF0aWMgdW5zaWduZWQgaW50IF9faW5p dGRhdGEgbDFkX21heHBoeXNhZGRyOwogc3RhdGljIGJvb2wgX19pbml0ZGF0 YSBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5OyAvKiA9PiBtaW5pbWFsIEhUIGlt cGFjdC4gKi8KIHN0YXRpYyBib29sIF9faW5pdGRhdGEgY3B1X2hhc19idWdf bWRzOyAvKiBBbnkgb3RoZXIgTXtMUCxTQixGQn1EUyBjb21iaW5hdGlvbi4g Ki8KIAorc3RhdGljIGludDhfdCBfX2luaXRkYXRhIG9wdF9zcmJfbG9jayA9 IC0xOwordWludDY0X3QgX19yZWFkX21vc3RseSBkZWZhdWx0X3hlbl9tY3Vf b3B0X2N0cmw7CisKIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX2J0aShjb25z dCBjaGFyICpzKQogewogICAgIGNvbnN0IGNoYXIgKnNzOwpAQCAtMTY2LDYg KzE2OSw3IEBAIHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChj b25zdCBjaGFyICpzKQogICAgICAgICAgICAgb3B0X2licGIgPSBmYWxzZTsK ICAgICAgICAgICAgIG9wdF9zc2JkID0gZmFsc2U7CiAgICAgICAgICAgICBv cHRfbDFkX2ZsdXNoID0gMDsKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9 IDA7CiAgICAgICAgIH0KICAgICAgICAgZWxzZSBpZiAoIHZhbCA+IDAgKQog ICAgICAgICAgICAgcmMgPSAtRUlOVkFMOwpAQCAtMjMxLDYgKzIzNSw4IEBA IHN0YXRpYyBpbnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFy ICpzKQogICAgICAgICAgICAgb3B0X2VhZ2VyX2ZwdSA9IHZhbDsKICAgICAg ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJsMWQtZmx1c2gi LCBzLCBzcykpID49IDAgKQogICAgICAgICAgICAgb3B0X2wxZF9mbHVzaCA9 IHZhbDsKKyAgICAgICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFu KCJzcmItbG9jayIsIHMsIHNzKSkgPj0gMCApCisgICAgICAgICAgICBvcHRf c3JiX2xvY2sgPSB2YWw7CiAgICAgICAgIGVsc2UKICAgICAgICAgICAgIHJj ID0gLUVJTlZBTDsKIApAQCAtMzk0LDcgKzQwMCw3IEBAIHN0YXRpYyB2b2lk IF9faW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rLCB1 aW50NjRfdCBjYXBzKQogICAgICAgICAgICAgICAgIlxuIik7CiAKICAgICAv KiBTZXR0aW5ncyBmb3IgWGVuJ3MgcHJvdGVjdGlvbiwgaXJyZXNwZWN0aXZl IG9mIGd1ZXN0cy4gKi8KLSAgICBwcmludGsoIiAgWGVuIHNldHRpbmdzOiBC VEktVGh1bmsgJXMsIFNQRUNfQ1RSTDogJXMlcyVzLCBPdGhlcjolcyVzJXNc biIsCisgICAgcHJpbnRrKCIgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rICVz LCBTUEVDX0NUUkw6ICVzJXMlcywgT3RoZXI6JXMlcyVzJXNcbiIsCiAgICAg ICAgICAgIHRodW5rID09IFRIVU5LX05PTkUgICAgICA/ICJOL0EiIDoKICAg ICAgICAgICAgdGh1bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBPTElO RSIgOgogICAgICAgICAgICB0aHVuayA9PSBUSFVOS19MRkVOQ0UgICAgPyAi TEZFTkNFIiA6CkBAIC00MDUsNiArNDExLDggQEAgc3RhdGljIHZvaWQgX19p bml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVpbnQ2 NF90IGNhcHMpCiAgICAgICAgICAgIChkZWZhdWx0X3hlbl9zcGVjX2N0cmwg JiBTUEVDX0NUUkxfU1NCRCkgID8gIiBTU0JEKyIgOiAiIFNTQkQtIiwKICAg ICAgICAgICAgIShjYXBzICYgQVJDSF9DQVBTX1RTWF9DVFJMKSAgICAgICAg ICAgICAgPyAiIiA6CiAgICAgICAgICAgIChvcHRfdHN4ICYgMSkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID8gIiBUU1grIiA6ICIgVFNYLSIsCisg ICAgICAgICAgICFib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RS TCkgICAgID8gIiIgOgorICAgICAgICAgICBvcHRfc3JiX2xvY2sgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA/ICIgU1JCX0xPQ0srIiA6ICIgU1JC X0xPQ0stIiwKICAgICAgICAgICAgb3B0X2licGIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPyAiIElCUEIiICA6ICIiLAogICAgICAgICAg ICBvcHRfbDFkX2ZsdXNoICAgICAgICAgICAgICAgICAgICAgICAgICAgICA/ ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICBvcHRfbWRfY2xlYXJf cHYgfHwgb3B0X21kX2NsZWFyX2h2bSAgICAgICA/ICIgVkVSVyIgIDogIiIp OwpAQCAtMTE5Niw2ICsxMjA0LDM0IEBAIHZvaWQgX19pbml0IGluaXRfc3Bl Y3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKICAgICAgICAgdHN4X2luaXQo KTsKICAgICB9CiAKKyAgICAvKiBDYWxjdWxhdGUgc3VpdGFibGUgZGVmYXVs dHMgZm9yIE1TUl9NQ1VfT1BUX0NUUkwgKi8KKyAgICBpZiAoIGJvb3RfY3B1 X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSApCisgICAgeworICAgICAg ICB1aW50NjRfdCB2YWw7CisKKyAgICAgICAgcmRtc3JsKE1TUl9NQ1VfT1BU X0NUUkwsIHZhbCk7CisKKyAgICAgICAgLyoKKyAgICAgICAgICogT24gc29t ZSBTUkJEUy1hZmZlY3RlZCBoYXJkd2FyZSwgaXQgbWF5IGJlIHNhZmUgdG8g cmVsYXggc3JiLWxvY2sKKyAgICAgICAgICogYnkgZGVmYXVsdC4KKyAgICAg ICAgICoKKyAgICAgICAgICogT24gcGFydHMgd2hpY2ggZW51bWVyYXRlIE1E U19OTyBhbmQgbm90IFRBQV9OTywgVFNYIGlzIHRoZSBvbmx5IHdheQorICAg ICAgICAgKiB0byBhY2Nlc3MgdGhlIEZpbGwgQnVmZmVyLiAgSWYgVFNYIGlz bid0IGF2YWlsYWJsZSAoaW5jLiBTS1UKKyAgICAgICAgICogcmVhc29ucyBv biBzb21lIG1vZGVscyksIG9yIFRTWCBpcyBleHBsaWNpdGx5IGRpc2FibGVk LCB0aGVuIHRoZXJlCisgICAgICAgICAqIGlzIG5vIG5lZWQgZm9yIHRoZSBl eHRyYSBvdmVyaGVhZCB0byBwcm90ZWN0IFJEUkFORC9SRFNFRUQuCisgICAg ICAgICAqLworICAgICAgICBpZiAoIG9wdF9zcmJfbG9jayA9PSAtMSAmJgor ICAgICAgICAgICAgIChjYXBzICYgKEFSQ0hfQ0FQU19NRFNfTk98QVJDSF9D QVBTX1RBQV9OTykpID09IEFSQ0hfQ0FQU19NRFNfTk8gJiYKKyAgICAgICAg ICAgICAoIWNwdV9oYXNfaGxlIHx8ICgoY2FwcyAmIEFSQ0hfQ0FQU19UU1hf Q1RSTCkgJiYgb3B0X3RzeCA9PSAwKSkgKQorICAgICAgICAgICAgb3B0X3Ny Yl9sb2NrID0gMDsKKworICAgICAgICB2YWwgJj0gfk1DVV9PUFRfQ1RSTF9S TkdEU19NSVRHX0RJUzsKKyAgICAgICAgaWYgKCAhb3B0X3NyYl9sb2NrICkK KyAgICAgICAgICAgIHZhbCB8PSBNQ1VfT1BUX0NUUkxfUk5HRFNfTUlUR19E SVM7CisKKyAgICAgICAgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsID0gdmFs OworICAgIH0KKwogICAgIHByaW50X2RldGFpbHModGh1bmssIGNhcHMpOwog CiAgICAgLyoKQEAgLTEyMjcsNiArMTI2Myw5IEBAIHZvaWQgX19pbml0IGlu aXRfc3BlY3VsYXRpb25fbWl0aWdhdGlvbnModm9pZCkKIAogICAgICAgICB3 cm1zcmwoTVNSX1NQRUNfQ1RSTCwgYnNwX2RlbGF5X3NwZWNfY3RybCA/IDAg OiBkZWZhdWx0X3hlbl9zcGVjX2N0cmwpOwogICAgIH0KKworICAgIGlmICgg Ym9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICAg ICAgd3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkwsIGRlZmF1bHRfeGVuX21jdV9v cHRfY3RybCk7CiB9CiAKIHN0YXRpYyB2b2lkIF9faW5pdCBfX21heWJlX3Vu dXNlZCBidWlsZF9hc3NlcnRpb25zKHZvaWQpCmRpZmYgLS1naXQgYS94ZW4v aW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oIGIveGVuL2luY2x1ZGUvYXNt LXg4Ni9zcGVjX2N0cmwuaAppbmRleCAzMzNkMTgwYjdlLi5iZjEwZDJjZTVj IDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5o CisrKyBiL3hlbi9pbmNsdWRlL2FzbS14ODYvc3BlY19jdHJsLmgKQEAgLTQ2 LDYgKzQ2LDggQEAgZXh0ZXJuIGludDhfdCBvcHRfcHZfbDF0Zl9od2RvbSwg b3B0X3B2X2wxdGZfZG9tdTsKICAqLwogZXh0ZXJuIHBhZGRyX3QgbDF0Zl9h ZGRyX21hc2ssIGwxdGZfc2FmZV9tYWRkcjsKIAorZXh0ZXJuIHVpbnQ2NF90 IGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybDsKKwogc3RhdGljIGlubGluZSB2 b2lkIGluaXRfc2hhZG93X3NwZWNfY3RybF9zdGF0ZSh2b2lkKQogewogICAg IHN0cnVjdCBjcHVfaW5mbyAqaW5mbyA9IGdldF9jcHVfaW5mbygpOwo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.11-3.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.11-3.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQWxsb3cgdGhlIFJEUkFORC9S RFNFRUQgZmVhdHVyZXMgdG8gYmUgaGlkZGVuCgpSRFJBTkQvUkRTRUVEIGNh biBiZSBoaWRkZW4gdXNpbmcgY3B1aWQ9IHRvIG1pdGlnYXRlIFNSQkRTIGlm IG1pY3JvY29kZQppc24ndCBhdmFpbGFibGUuCgpUaGlzIGlzIHBhcnQgb2Yg WFNBLTMyMCAvIENWRS0yMDIwLTA1NDMuCgpTaWduZWQtb2ZmLWJ5OiBBbmRy ZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpBY2tlZC1i eTogSnVsaWVuIEdyYWxsIDxqZ3JhbGxAYW1hem9uLmNvbT4KCmRpZmYgLS1n aXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5tYXJrZG93biBiL2Rv Y3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLm1hcmtkb3duCmluZGV4IDMzNTZl NTlmZWUuLmFjMzk3ZTdkZTAgMTAwNjQ0Ci0tLSBhL2RvY3MvbWlzYy94ZW4t Y29tbWFuZC1saW5lLm1hcmtkb3duCisrKyBiL2RvY3MvbWlzYy94ZW4tY29t bWFuZC1saW5lLm1hcmtkb3duCkBAIC00ODcsMTIgKzQ4NywxOCBAQCBjaG9p Y2Ugb2YgYGRvbTAta2VybmVsYCBpcyBkZXByZWNhdGVkIGFuZCBub3Qgc3Vw cG9ydGVkIGJ5IGFsbCBEb20wIGtlcm5lbHMuCiBUaGlzIG9wdGlvbiBhbGxv d3MgZm9yIGZpbmUgdHVuaW5nIG9mIHRoZSBmYWNpbGl0aWVzIFhlbiB3aWxs IHVzZSwgYWZ0ZXIKIGFjY291bnRpbmcgZm9yIGhhcmR3YXJlIGNhcGFiaWxp dGllcyBhcyBlbnVtZXJhdGVkIHZpYSBDUFVJRC4KIAorVW5sZXNzIG90aGVy d2lzZSBub3RlZCwgb3B0aW9ucyBvbmx5IGhhdmUgYW55IGVmZmVjdCBpbiB0 aGVpciBuZWdhdGl2ZSBmb3JtLAordG8gaGlkZSB0aGUgbmFtZWQgZmVhdHVy ZShzKS4gIElnbm9yaW5nIGEgZmVhdHVyZSB1c2luZyB0aGlzIG1lY2hhbmlz bSB3aWxsCitjYXVzZSBYZW4gbm90IHRvIHVzZSB0aGUgZmVhdHVyZSwgbm9y IG9mZmVyIHRoZW0gYXMgdXNhYmxlIHRvIGd1ZXN0cy4KKwogQ3VycmVudGx5 IGFjY2VwdGVkOgogCiBUaGUgU3BlY3VsYXRpb24gQ29udHJvbCBoYXJkd2Fy ZSBmZWF0dXJlcyBgc3JiZHMtY3RybGAsIGBtZC1jbGVhcmAsIGBpYnJzYmAs CiBgc3RpYnBgLCBgaWJwYmAsIGBsMWQtZmx1c2hgIGFuZCBgc3NiZGAgYXJl IHVzZWQgYnkgZGVmYXVsdCBpZiBhdmFpbGFibGUgYW5kCi1hcHBsaWNhYmxl LiAgVGhleSBjYW4gYmUgaWdub3JlZCwgZS5nLiBgbm8taWJyc2JgLCBhdCB3 aGljaCBwb2ludCBYZW4gd29uJ3QKLXVzZSB0aGVtIGl0c2VsZiwgYW5kIHdv bid0IG9mZmVyIHRoZW0gdG8gZ3Vlc3RzLgorYXBwbGljYWJsZS4gIFRoZXkg Y2FuIGFsbCBiZSBpZ25vcmVkLgorCitgcmRyYW5kYCBhbmQgYHJkc2VlZGAg Y2FuIGJlIGlnbm9yZWQsIGFzIGEgbWl0aWdhdGlvbiB0byBYU0EtMzIwIC8K K0NWRS0yMDIwLTA1NDMuCiAKICMjIyBjcHVpZFxfbWFza1xfY3B1IChBTUQg b25seSkKID4gYD0gZmFtXzBmX3Jldl9jIHwgZmFtXzBmX3Jldl9kIHwgZmFt XzBmX3Jldl9lIHwgZmFtXzBmX3Jldl9mIHwgZmFtXzBmX3Jldl9nIHwgZmFt XzEwX3Jldl9iIHwgZmFtXzEwX3Jldl9jIHwgZmFtXzExX3Jldl9iYApkaWZm IC0tZ2l0IGEveGVuL2FyY2gveDg2L2NwdWlkLmMgYi94ZW4vYXJjaC94ODYv Y3B1aWQuYwppbmRleCBiOGU1YjZmZTY3Li43OGQwOGRiYjMyIDEwMDY0NAot LS0gYS94ZW4vYXJjaC94ODYvY3B1aWQuYworKysgYi94ZW4vYXJjaC94ODYv Y3B1aWQuYwpAQCAtNjMsNiArNjMsMTYgQEAgc3RhdGljIGludCBfX2luaXQg cGFyc2VfeGVuX2NwdWlkKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBp ZiAoICF2YWwgKQogICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2NwdV9j YXAoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCk7CiAgICAgICAgIH0KKyAgICAg ICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJyZHJhbmQiLCBz LCBzcykpID49IDAgKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAoICF2 YWwgKQorICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2NwdV9jYXAoWDg2 X0ZFQVRVUkVfUkRSQU5EKTsKKyAgICAgICAgfQorICAgICAgICBlbHNlIGlm ICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oInJkc2VlZCIsIHMsIHNzKSkgPj0g MCApCisgICAgICAgIHsKKyAgICAgICAgICAgIGlmICggIXZhbCApCisgICAg ICAgICAgICAgICAgc2V0dXBfY2xlYXJfY3B1X2NhcChYODZfRkVBVFVSRV9S RFNFRUQpOworICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAgICAg IHJjID0gLUVJTlZBTDsKIAo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.12-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.12-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyBi L2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYwppbmRleCAzNTYx ZDg4YjU5Li5kYmRhZWU5MmRjIDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVu LWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21t YW5kLWxpbmUucGFuZG9jCkBAIC00ODMsMTAgKzQ4MywxMCBAQCBhY2NvdW50 aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXMgZW51bWVyYXRlZCB2 aWEgQ1BVSUQuCiAKIEN1cnJlbnRseSBhY2NlcHRlZDoKIAotVGhlIFNwZWN1 bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVhdHVyZXMgYG1kLWNsZWFyYCwg YGlicnNiYCwgYHN0aWJwYCwgYGlicGJgLAotYGwxZC1mbHVzaGAgYW5kIGBz c2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0IGlmIGF2YWlsYWJsZSBhbmQgYXBw bGljYWJsZS4gIFRoZXkgY2FuCi1iZSBpZ25vcmVkLCBlLmcuIGBuby1pYnJz YmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3b24ndCB1c2UgdGhlbSBpdHNlbGYs IGFuZAotd29uJ3Qgb2ZmZXIgdGhlbSB0byBndWVzdHMuCitUaGUgU3BlY3Vs YXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgc3JiZHMtY3RybGAs IGBtZC1jbGVhcmAsIGBpYnJzYmAsCitgc3RpYnBgLCBgaWJwYmAsIGBsMWQt Zmx1c2hgIGFuZCBgc3NiZGAgYXJlIHVzZWQgYnkgZGVmYXVsdCBpZiBhdmFp bGFibGUgYW5kCithcHBsaWNhYmxlLiAgVGhleSBjYW4gYmUgaWdub3JlZCwg ZS5nLiBgbm8taWJyc2JgLCBhdCB3aGljaCBwb2ludCBYZW4gd29uJ3QKK3Vz ZSB0aGVtIGl0c2VsZiwgYW5kIHdvbid0IG9mZmVyIHRoZW0gdG8gZ3Vlc3Rz LgogCiAjIyMgY3B1aWRfbWFza19jcHUKID4gYD0gZmFtXzBmX3Jldl9bY2Rl ZmddIHwgZmFtXzEwX3Jldl9bYmNdIHwgZmFtXzExX3Jldl9iYApkaWZmIC0t Z2l0IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhs L2xpYnhsX2NwdWlkLmMKaW5kZXggNGNmMGYwNzM4ZC4uODhiNTc2MGM4NSAx MDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90 b29scy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0yMDMsNiArMjAzLDcgQEAg aW50IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xp Y3lfbGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKIAogICAgICAgICB7 ImF2eDUxMi00dm5uaXciLDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURY LCAgMiwgIDF9LAogICAgICAgICB7ImF2eDUxMi00Zm1hcHMiLDB4MDAwMDAw MDcsICAwLCBDUFVJRF9SRUdfRURYLCAgMywgIDF9LAorICAgICAgICB7InNy YmRzLWN0cmwiLCAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAg OSwgIDF9LAogICAgICAgICB7Im1kLWNsZWFyIiwgICAgIDB4MDAwMDAwMDcs ICAwLCBDUFVJRF9SRUdfRURYLCAxMCwgIDF9LAogICAgICAgICB7ImNldC1p YnQiLCAgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyMCwg IDF9LAogICAgICAgICB7ImlicnNiIiwgICAgICAgIDB4MDAwMDAwMDcsICAw LCBDUFVJRF9SRUdfRURYLCAyNiwgIDF9LApkaWZmIC0tZ2l0IGEvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKaW5k ZXggMmEwMDY5NzY0My4uYjRjNGRmY2YxOSAxMDA2NDQKLS0tIGEvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNjL3hlbi1jcHVpZC5j CkBAIC0xNTQsNiArMTU0LDcgQEAgc3RhdGljIGNvbnN0IGNoYXIgKnN0cl83 ZDBbMzJdID0KICAgICBbIDJdID0gImF2eDUxMl80dm5uaXciLCBbIDNdID0g ImF2eDUxMl80Zm1hcHMiLAogICAgIFsgNF0gPSAiZnNybSIsCiAKKyAgICAv KiAgOCAqLyAgICAgICAgICAgICAgICBbIDldID0gInNyYmRzLWN0cmwiLAog ICAgIFsxMF0gPSAibWQtY2xlYXIiLAogICAgIC8qIDEyICovICAgICAgICAg ICAgICAgIFsxM10gPSAidHN4LWZvcmNlLWFib3J0IiwKIApkaWZmIC0tZ2l0 IGEveGVuL2FyY2gveDg2L2NwdWlkLmMgYi94ZW4vYXJjaC94ODYvY3B1aWQu YwppbmRleCAxNzI3NDk3NDU5Li4yMmQ4YzcxYTk1IDEwMDY0NAotLS0gYS94 ZW4vYXJjaC94ODYvY3B1aWQuYworKysgYi94ZW4vYXJjaC94ODYvY3B1aWQu YwpAQCAtNTksNiArNTksMTEgQEAgc3RhdGljIGludCBfX2luaXQgcGFyc2Vf eGVuX2NwdWlkKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAgICBpZiAoICF2 YWwgKQogICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2NwdV9jYXAoWDg2 X0ZFQVRVUkVfU1NCRCk7CiAgICAgICAgIH0KKyAgICAgICAgZWxzZSBpZiAo ICh2YWwgPSBwYXJzZV9ib29sZWFuKCJzcmJkcy1jdHJsIiwgcywgc3MpKSA+ PSAwICkKKyAgICAgICAgeworICAgICAgICAgICAgaWYgKCAhdmFsICkKKyAg ICAgICAgICAgICAgICBzZXR1cF9jbGVhcl9jcHVfY2FwKFg4Nl9GRUFUVVJF X1NSQkRTX0NUUkwpOworICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAg ICAgICAgIHJjID0gLUVJTlZBTDsKIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gv eDg2L21zci5jIGIveGVuL2FyY2gveDg2L21zci5jCmluZGV4IDQ4ODhmZmYx NmMuLjlmZjI3YjcwMDcgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9tc3Iu YworKysgYi94ZW4vYXJjaC94ODYvbXNyLmMKQEAgLTEzMyw2ICsxMzMsNyBA QCBpbnQgZ3Vlc3RfcmRtc3IoY29uc3Qgc3RydWN0IHZjcHUgKnYsIHVpbnQz Ml90IG1zciwgdWludDY0X3QgKnZhbCkKICAgICAgICAgLyogV3JpdGUtb25s eSAqLwogICAgIGNhc2UgTVNSX1RTWF9GT1JDRV9BQk9SVDoKICAgICBjYXNl IE1TUl9UU1hfQ1RSTDoKKyAgICBjYXNlIE1TUl9NQ1VfT1BUX0NUUkw6CiAg ICAgY2FzZSBNU1JfVV9DRVQ6CiAgICAgY2FzZSBNU1JfU19DRVQ6CiAgICAg Y2FzZSBNU1JfUEwwX1NTUCAuLi4gTVNSX0lOVEVSUlVQVF9TU1BfVEFCTEU6 CkBAIC0yNzMsNiArMjc0LDcgQEAgaW50IGd1ZXN0X3dybXNyKHN0cnVjdCB2 Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90IHZhbCkKICAgICAgICAg LyogUmVhZC1vbmx5ICovCiAgICAgY2FzZSBNU1JfVFNYX0ZPUkNFX0FCT1JU OgogICAgIGNhc2UgTVNSX1RTWF9DVFJMOgorICAgIGNhc2UgTVNSX01DVV9P UFRfQ1RSTDoKICAgICBjYXNlIE1TUl9VX0NFVDoKICAgICBjYXNlIE1TUl9T X0NFVDoKICAgICBjYXNlIE1TUl9QTDBfU1NQIC4uLiBNU1JfSU5URVJSVVBU X1NTUF9UQUJMRToKZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9zcGVjX2N0 cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwppbmRleCA4MDAxMzlk NzljLi41MTU4ZTAxMmNhIDEwMDY0NAotLS0gYS94ZW4vYXJjaC94ODYvc3Bl Y19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCkBAIC0z MDksMTIgKzMwOSwxMyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgcHJpbnRfZGV0 YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0X3QgY2FwcykKICAg ICBwcmludGsoIlNwZWN1bGF0aXZlIG1pdGlnYXRpb24gZmFjaWxpdGllczpc biIpOwogCiAgICAgLyogSGFyZHdhcmUgZmVhdHVyZXMgd2hpY2ggcGVydGFp biB0byBzcGVjdWxhdGl2ZSBtaXRpZ2F0aW9ucy4gKi8KLSAgICBwcmludGso IiAgSGFyZHdhcmUgZmVhdHVyZXM6JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVz JXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUgZmVhdHVyZXM6JXMl cyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAogICAgICAgICAgICAo XzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9JQlJTQikpID8gIiBJ QlJTL0lCUEIiIDogIiIsCiAgICAgICAgICAgIChfN2QwICYgY3B1ZmVhdF9t YXNrKFg4Nl9GRUFUVVJFX1NUSUJQKSkgPyAiIFNUSUJQIiAgICAgOiAiIiwK ICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVf TDFEX0ZMVVNIKSkgPyAiIEwxRF9GTFVTSCIgOiAiIiwKICAgICAgICAgICAg KF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVfU1NCRCkpICA/ICIg U1NCRCIgICAgICA6ICIiLAogICAgICAgICAgICAoXzdkMCAmIGNwdWZlYXRf bWFzayhYODZfRkVBVFVSRV9NRF9DTEVBUikpID8gIiBNRF9DTEVBUiIgOiAi IiwKKyAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRV UkVfU1JCRFNfQ1RSTCkpID8gIiBTUkJEU19DVFJMIiA6ICIiLAogICAgICAg ICAgICAoZThiICAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9JQlBCKSkg ID8gIiBJQlBCIiAgICAgIDogIiIsCiAgICAgICAgICAgIChjYXBzICYgQVJD SF9DQVBTX0lCUlNfQUxMKSAgICAgICAgICAgICAgPyAiIElCUlNfQUxMIiAg OiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NBUFNfUkRDTF9OTykg ICAgICAgICAgICAgICA/ICIgUkRDTF9OTyIgICA6ICIiLApkaWZmIC0tZ2l0 IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3ItaW5kZXguaCBiL3hlbi9pbmNs dWRlL2FzbS14ODYvbXNyLWluZGV4LmgKaW5kZXggNzY5M2M0YTcxYS4uOTE5 OTQ2NjllMSAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3It aW5kZXguaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L21zci1pbmRleC5o CkBAIC0xNzksNiArMTc5LDkgQEAKICNkZWZpbmUgTVNSX0lBMzJfVk1YX1RS VUVfRU5UUllfQ1RMUyAgICAgICAgICAgIDB4NDkwCiAjZGVmaW5lIE1TUl9J QTMyX1ZNWF9WTUZVTkMgICAgICAgICAgICAgICAgICAgICAweDQ5MQogCisj ZGVmaW5lIE1TUl9NQ1VfT1BUX0NUUkwgICAgICAgICAgICAgICAgICAgIDB4 MDAwMDAxMjMKKyNkZWZpbmUgIE1DVV9PUFRfQ1RSTF9STkdEU19NSVRHX0RJ UyAgICAgICAgKF9BQygxLCBVTEwpIDw8ICAwKQorCiAjZGVmaW5lIE1TUl9V X0NFVCAgICAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAwMDA2YTAKICNk ZWZpbmUgTVNSX1NfQ0VUICAgICAgICAgICAgICAgICAgICAgICAgICAgMHgw MDAwMDZhMgogI2RlZmluZSBNU1JfUEwwX1NTUCAgICAgICAgICAgICAgICAg ICAgICAgICAweDAwMDAwNmE0CmRpZmYgLS1naXQgYS94ZW4vaW5jbHVkZS9w dWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oIGIveGVuL2luY2x1ZGUv cHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaAppbmRleCA4NjVhNDM1 ZDJjLi4zMTQ5MGE3YzEwIDEwMDY0NAotLS0gYS94ZW4vaW5jbHVkZS9wdWJs aWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBiL3hlbi9pbmNsdWRl L3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgKQEAgLTI0Myw2ICsy NDMsNyBAQCBYRU5fQ1BVRkVBVFVSRShJQlBCLCAgICAgICAgICA4KjMyKzEy KSAvKkEgIElCUEIgc3VwcG9ydCBvbmx5IChubyBJQlJTLCB1c2VkIGJ5CiAv KiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJlcywgQ1BVSUQgbGV2ZWwgMHgw MDAwMDAwNzowLmVkeCwgd29yZCA5ICovCiBYRU5fQ1BVRkVBVFVSRShBVlg1 MTJfNFZOTklXLCA5KjMyKyAyKSAvKkEgIEFWWDUxMiBOZXVyYWwgTmV0d29y ayBJbnN0cnVjdGlvbnMgKi8KIFhFTl9DUFVGRUFUVVJFKEFWWDUxMl80Rk1B UFMsIDkqMzIrIDMpIC8qQSAgQVZYNTEyIE11bHRpcGx5IEFjY3VtdWxhdGlv biBTaW5nbGUgUHJlY2lzaW9uICovCitYRU5fQ1BVRkVBVFVSRShTUkJEU19D VFJMLCAgICA5KjMyKyA5KSAvKiAgIE1TUl9NQ1VfT1BUX0NUUkwgYW5kIFJO R0RTX01JVEdfRElTLiAqLwogWEVOX0NQVUZFQVRVUkUoTURfQ0xFQVIsICAg ICAgOSozMisxMCkgLypBICBWRVJXIGNsZWFycyBtaWNyb2FyY2hpdGVjdHVy YWwgYnVmZmVycyAqLwogWEVOX0NQVUZFQVRVUkUoVFNYX0ZPUkNFX0FCT1JU LCA5KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNFX0FCT1JULlJUTV9BQk9SVCAq LwogWEVOX0NQVUZFQVRVUkUoQ0VUX0lCVCwgICAgICAgOSozMisyMCkgLyog ICBDRVQgLSBJbmRpcmVjdCBCcmFuY2ggVHJhY2tpbmcgKi8K --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.12-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.12-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5w YW5kb2MgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKaW5k ZXggZGJkYWVlOTJkYy4uMzM3ZmJmMDQ5MiAxMDA2NDQKLS0tIGEvZG9jcy9t aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCisrKyBiL2RvY3MvbWlzYy94 ZW4tY29tbWFuZC1saW5lLnBhbmRvYwpAQCAtMTkwOSw3ICsxOTA5LDcgQEAg QnkgZGVmYXVsdCBTU0JEIHdpbGwgYmUgbWl0aWdhdGVkIGF0IHJ1bnRpbWUg KGkuZSBgc3NiZD1ydW50aW1lYCkuCiAjIyMgc3BlYy1jdHJsICh4ODYpCiA+ IGA9IExpc3Qgb2YgWyA8Ym9vbD4sIHhlbj08Ym9vbD4sIHtwdixodm0sbXNy LXNjLHJzYixtZC1jbGVhcn09PGJvb2w+LAogPiAgICAgICAgICAgICAgYnRp LXRodW5rPXJldHBvbGluZXxsZmVuY2V8am1wLCB7aWJycyxpYnBiLHNzYmQs ZWFnZXItZnB1LAotPiAgICAgICAgICAgICAgbDFkLWZsdXNofT08Ym9vbD4g XWAKKz4gICAgICAgICAgICAgIGwxZC1mbHVzaCxzcmItbG9ja309PGJvb2w+ IF1gCiAKIENvbnRyb2xzIGZvciBzcGVjdWxhdGl2ZSBleGVjdXRpb24gc2lk ZWNoYW5uZWwgbWl0aWdhdGlvbnMuICBCeSBkZWZhdWx0LCBYZW4KIHdpbGwg cGljayB0aGUgbW9zdCBhcHByb3ByaWF0ZSBtaXRpZ2F0aW9ucyBiYXNlZCBv biBjb21waWxlZCBpbiBzdXBwb3J0LApAQCAtMTk4MSw2ICsxOTgxLDEyIEBA IElycmVzcGVjdGl2ZSBvZiBYZW4ncyBzZXR0aW5nLCB0aGUgZmVhdHVyZSBp cyB2aXJ0dWFsaXNlZCBmb3IgSFZNIGd1ZXN0cyB0bwogdXNlLiAgQnkgZGVm YXVsdCwgWGVuIHdpbGwgZW5hYmxlIHRoaXMgbWl0aWdhdGlvbiBvbiBoYXJk d2FyZSBiZWxpZXZlZCB0byBiZQogdnVsbmVyYWJsZSB0byBMMVRGLgogCitP biBoYXJkd2FyZSBzdXBwb3J0aW5nIFNSQkRTX0NUUkwsIHRoZSBgc3JiLWxv Y2s9YCBvcHRpb24gY2FuIGJlIHVzZWQgdG8gZm9yY2UKK29yIHByZXZlbnQg WGVuIGZyb20gcHJvdGVjdCB0aGUgU3BlY2lhbCBSZWdpc3RlciBCdWZmZXIg ZnJvbSBsZWFraW5nIHN0YWxlCitkYXRhLiBCeSBkZWZhdWx0LCBYZW4gd2ls bCBlbmFibGUgdGhpcyBtaXRpZ2F0aW9uLCBleGNlcHQgb24gcGFydHMgd2hl cmUgTURTCitpcyBmaXhlZCBhbmQgVEFBIGlzIGZpeGVkL21pdGlnYXRlZCAo aW4gd2hpY2ggY2FzZSwgdGhlcmUgaXMgYmVsaWV2ZWQgdG8gYmUgbm8KK3dh eSBmb3IgYW4gYXR0YWNrZXIgdG8gb2J0YWluIHRoZSBzdGFsZSBkYXRhKS4K KwogIyMjIHN5bmNfY29uc29sZQogPiBgPSA8Ym9vbGVhbj5gCiAKZGlmZiAt LWdpdCBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMgYi94ZW4vYXJjaC94 ODYvYWNwaS9wb3dlci5jCmluZGV4IGMxZDc3MmY2M2YuLmEwN2FhM2I5ZWQg MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9hY3BpL3Bvd2VyLmMKKysrIGIv eGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpAQCAtMjY2LDYgKzI2Niw5IEBA IHN0YXRpYyBpbnQgZW50ZXJfc3RhdGUodTMyIHN0YXRlKQogICAgIGNpLT5z cGVjX2N0cmxfZmxhZ3MgfD0gKGRlZmF1bHRfc3BlY19jdHJsX2ZsYWdzICYg U0NGX2lzdF93cm1zcik7CiAgICAgc3BlY19jdHJsX2V4aXRfaWRsZShjaSk7 CiAKKyAgICBpZiAoIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJEU19D VFJMKSApCisgICAgICAgIHdybXNybChNU1JfTUNVX09QVF9DVFJMLCBkZWZh dWx0X3hlbl9tY3Vfb3B0X2N0cmwpOworCiAgZG9uZToKICAgICBzcGluX2Rl YnVnX2VuYWJsZSgpOwogICAgIGxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsK ZGlmZiAtLWdpdCBhL3hlbi9hcmNoL3g4Ni9zbXBib290LmMgYi94ZW4vYXJj aC94ODYvc21wYm9vdC5jCmluZGV4IDY5OWUyMWJmYjcuLmI3NDFkMTM1NGEg MTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9zbXBib290LmMKKysrIGIveGVu L2FyY2gveDg2L3NtcGJvb3QuYwpAQCAtMzY5LDEyICszNjksMTQgQEAgdm9p ZCBzdGFydF9zZWNvbmRhcnkodm9pZCAqdW51c2VkKQogICAgICAgICBtaWNy b2NvZGVfcmVzdW1lX2NwdShjcHUpOwogCiAgICAgLyoKLSAgICAgKiBJZiBN U1JfU1BFQ19DVFJMIGlzIGF2YWlsYWJsZSwgYXBwbHkgWGVuJ3MgZGVmYXVs dCBzZXR0aW5nIGFuZCBkaXNjYXJkCi0gICAgICogYW55IGZpcm13YXJlIHNl dHRpbmdzLiAgTm90ZTogTVNSX1NQRUNfQ1RSTCBtYXkgb25seSBiZWNvbWUg YXZhaWxhYmxlCi0gICAgICogYWZ0ZXIgbG9hZGluZyBtaWNyb2NvZGUuCisg ICAgICogSWYgYW55IHNwZWN1bGF0aXZlIGNvbnRyb2wgTVNScyBhcmUgYXZh aWxhYmxlLCBhcHBseSBYZW4ncyBkZWZhdWx0CisgICAgICogc2V0dGluZ3Mu ICBOb3RlOiBUaGVzZSBNU1JzIG1heSBvbmx5IGJlY29tZSBhdmFpbGFibGUg YWZ0ZXIgbG9hZGluZworICAgICAqIG1pY3JvY29kZS4KICAgICAgKi8KICAg ICBpZiAoIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9JQlJTQikgKQogICAg ICAgICB3cm1zcmwoTVNSX1NQRUNfQ1RSTCwgZGVmYXVsdF94ZW5fc3BlY19j dHJsKTsKKyAgICBpZiAoIGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJE U19DVFJMKSApCisgICAgICAgIHdybXNybChNU1JfTUNVX09QVF9DVFJMLCBk ZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmwpOwogCiAgICAgdHN4X2luaXQoKTsg LyogTmVlZHMgbWljcm9jb2RlLiAgTWF5IGNoYW5nZSBITEUvUlRNIGZlYXR1 cmUgYml0cy4gKi8KIApkaWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L3NwZWNf Y3RybC5jIGIveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCmluZGV4IDUxNThl MDEyY2EuLmUyZmNlZmM4NmEgMTAwNjQ0Ci0tLSBhL3hlbi9hcmNoL3g4Ni9z cGVjX2N0cmwuYworKysgYi94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMKQEAg LTY0LDYgKzY0LDkgQEAgc3RhdGljIHVuc2lnbmVkIGludCBfX2luaXRkYXRh IGwxZF9tYXhwaHlzYWRkcjsKIHN0YXRpYyBib29sIF9faW5pdGRhdGEgY3B1 X2hhc19idWdfbXNiZHNfb25seTsgLyogPT4gbWluaW1hbCBIVCBpbXBhY3Qu ICovCiBzdGF0aWMgYm9vbCBfX2luaXRkYXRhIGNwdV9oYXNfYnVnX21kczsg LyogQW55IG90aGVyIE17TFAsU0IsRkJ9RFMgY29tYmluYXRpb24uICovCiAK K3N0YXRpYyBpbnQ4X3QgX19pbml0ZGF0YSBvcHRfc3JiX2xvY2sgPSAtMTsK K3VpbnQ2NF90IF9fcmVhZF9tb3N0bHkgZGVmYXVsdF94ZW5fbWN1X29wdF9j dHJsOworCiBzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9zcGVjX2N0cmwoY29u c3QgY2hhciAqcykKIHsKICAgICBjb25zdCBjaGFyICpzczsKQEAgLTExMCw2 ICsxMTMsNyBAQCBzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9zcGVjX2N0cmwo Y29uc3QgY2hhciAqcykKICAgICAgICAgICAgIG9wdF9pYnBiID0gZmFsc2U7 CiAgICAgICAgICAgICBvcHRfc3NiZCA9IGZhbHNlOwogICAgICAgICAgICAg b3B0X2wxZF9mbHVzaCA9IDA7CisgICAgICAgICAgICBvcHRfc3JiX2xvY2sg PSAwOwogICAgICAgICB9CiAgICAgICAgIGVsc2UgaWYgKCB2YWwgPiAwICkK ICAgICAgICAgICAgIHJjID0gLUVJTlZBTDsKQEAgLTE3NSw2ICsxNzksOCBA QCBzdGF0aWMgaW50IF9faW5pdCBwYXJzZV9zcGVjX2N0cmwoY29uc3QgY2hh ciAqcykKICAgICAgICAgICAgIG9wdF9lYWdlcl9mcHUgPSB2YWw7CiAgICAg ICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVhbigibDFkLWZsdXNo Iiwgcywgc3MpKSA+PSAwICkKICAgICAgICAgICAgIG9wdF9sMWRfZmx1c2gg PSB2YWw7CisgICAgICAgIGVsc2UgaWYgKCAodmFsID0gcGFyc2VfYm9vbGVh bigic3JiLWxvY2siLCBzLCBzcykpID49IDAgKQorICAgICAgICAgICAgb3B0 X3NyYl9sb2NrID0gdmFsOwogICAgICAgICBlbHNlCiAgICAgICAgICAgICBy YyA9IC1FSU5WQUw7CiAKQEAgLTMzOCw3ICszNDQsNyBAQCBzdGF0aWMgdm9p ZCBfX2luaXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywg dWludDY0X3QgY2FwcykKICAgICAgICAgICAgICAgICJcbiIpOwogCiAgICAg LyogU2V0dGluZ3MgZm9yIFhlbidzIHByb3RlY3Rpb24sIGlycmVzcGVjdGl2 ZSBvZiBndWVzdHMuICovCi0gICAgcHJpbnRrKCIgIFhlbiBzZXR0aW5nczog QlRJLVRodW5rICVzLCBTUEVDX0NUUkw6ICVzJXMlcywgT3RoZXI6JXMlcyVz XG4iLAorICAgIHByaW50aygiICBYZW4gc2V0dGluZ3M6IEJUSS1UaHVuayAl cywgU1BFQ19DVFJMOiAlcyVzJXMsIE90aGVyOiVzJXMlcyVzXG4iLAogICAg ICAgICAgICB0aHVuayA9PSBUSFVOS19OT05FICAgICAgPyAiTi9BIiA6CiAg ICAgICAgICAgIHRodW5rID09IFRIVU5LX1JFVFBPTElORSA/ICJSRVRQT0xJ TkUiIDoKICAgICAgICAgICAgdGh1bmsgPT0gVEhVTktfTEZFTkNFICAgID8g IkxGRU5DRSIgOgpAQCAtMzQ5LDYgKzM1NSw4IEBAIHN0YXRpYyB2b2lkIF9f aW5pdCBwcmludF9kZXRhaWxzKGVudW0gaW5kX3RodW5rIHRodW5rLCB1aW50 NjRfdCBjYXBzKQogICAgICAgICAgICAoZGVmYXVsdF94ZW5fc3BlY19jdHJs ICYgU1BFQ19DVFJMX1NTQkQpICA/ICIgU1NCRCsiIDogIiBTU0JELSIsCiAg ICAgICAgICAgICEoY2FwcyAmIEFSQ0hfQ0FQU19UU1hfQ1RSTCkgICAgICAg ICAgICAgID8gIiIgOgogICAgICAgICAgICAob3B0X3RzeCAmIDEpICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA/ICIgVFNYKyIgOiAiIFRTWC0iLAor ICAgICAgICAgICAhYm9vdF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NU UkwpICAgICA/ICIiIDoKKyAgICAgICAgICAgb3B0X3NyYl9sb2NrICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPyAiIFNSQl9MT0NLKyIgOiAiIFNS Ql9MT0NLLSIsCiAgICAgICAgICAgIG9wdF9pYnBiICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgID8gIiBJQlBCIiAgOiAiIiwKICAgICAgICAg ICAgb3B0X2wxZF9mbHVzaCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PyAiIEwxRF9GTFVTSCIgOiAiIiwKICAgICAgICAgICAgb3B0X21kX2NsZWFy X3B2IHx8IG9wdF9tZF9jbGVhcl9odm0gICAgICAgPyAiIFZFUlciICA6ICIi KTsKQEAgLTExNDIsNiArMTE1MCwzNCBAQCB2b2lkIF9faW5pdCBpbml0X3Nw ZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAgICAgICAgIHRzeF9pbml0 KCk7CiAgICAgfQogCisgICAgLyogQ2FsY3VsYXRlIHN1aXRhYmxlIGRlZmF1 bHRzIGZvciBNU1JfTUNVX09QVF9DVFJMICovCisgICAgaWYgKCBib290X2Nw dV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgIHsKKyAgICAg ICAgdWludDY0X3QgdmFsOworCisgICAgICAgIHJkbXNybChNU1JfTUNVX09Q VF9DVFJMLCB2YWwpOworCisgICAgICAgIC8qCisgICAgICAgICAqIE9uIHNv bWUgU1JCRFMtYWZmZWN0ZWQgaGFyZHdhcmUsIGl0IG1heSBiZSBzYWZlIHRv IHJlbGF4IHNyYi1sb2NrCisgICAgICAgICAqIGJ5IGRlZmF1bHQuCisgICAg ICAgICAqCisgICAgICAgICAqIE9uIHBhcnRzIHdoaWNoIGVudW1lcmF0ZSBN RFNfTk8gYW5kIG5vdCBUQUFfTk8sIFRTWCBpcyB0aGUgb25seSB3YXkKKyAg ICAgICAgICogdG8gYWNjZXNzIHRoZSBGaWxsIEJ1ZmZlci4gIElmIFRTWCBp c24ndCBhdmFpbGFibGUgKGluYy4gU0tVCisgICAgICAgICAqIHJlYXNvbnMg b24gc29tZSBtb2RlbHMpLCBvciBUU1ggaXMgZXhwbGljaXRseSBkaXNhYmxl ZCwgdGhlbiB0aGVyZQorICAgICAgICAgKiBpcyBubyBuZWVkIGZvciB0aGUg ZXh0cmEgb3ZlcmhlYWQgdG8gcHJvdGVjdCBSRFJBTkQvUkRTRUVELgorICAg ICAgICAgKi8KKyAgICAgICAgaWYgKCBvcHRfc3JiX2xvY2sgPT0gLTEgJiYK KyAgICAgICAgICAgICAoY2FwcyAmIChBUkNIX0NBUFNfTURTX05PfEFSQ0hf Q0FQU19UQUFfTk8pKSA9PSBBUkNIX0NBUFNfTURTX05PICYmCisgICAgICAg ICAgICAgKCFjcHVfaGFzX2hsZSB8fCAoKGNhcHMgJiBBUkNIX0NBUFNfVFNY X0NUUkwpICYmIG9wdF90c3ggPT0gMCkpICkKKyAgICAgICAgICAgIG9wdF9z cmJfbG9jayA9IDA7CisKKyAgICAgICAgdmFsICY9IH5NQ1VfT1BUX0NUUkxf Uk5HRFNfTUlUR19ESVM7CisgICAgICAgIGlmICggIW9wdF9zcmJfbG9jayAp CisgICAgICAgICAgICB2YWwgfD0gTUNVX09QVF9DVFJMX1JOR0RTX01JVEdf RElTOworCisgICAgICAgIGRlZmF1bHRfeGVuX21jdV9vcHRfY3RybCA9IHZh bDsKKyAgICB9CisKICAgICBwcmludF9kZXRhaWxzKHRodW5rLCBjYXBzKTsK IAogICAgIC8qCkBAIC0xMTczLDYgKzEyMDksOSBAQCB2b2lkIF9faW5pdCBp bml0X3NwZWN1bGF0aW9uX21pdGlnYXRpb25zKHZvaWQpCiAKICAgICAgICAg d3Jtc3JsKE1TUl9TUEVDX0NUUkwsIGJzcF9kZWxheV9zcGVjX2N0cmwgPyAw IDogZGVmYXVsdF94ZW5fc3BlY19jdHJsKTsKICAgICB9CisKKyAgICBpZiAo IGJvb3RfY3B1X2hhcyhYODZfRkVBVFVSRV9TUkJEU19DVFJMKSApCisgICAg ICAgIHdybXNybChNU1JfTUNVX09QVF9DVFJMLCBkZWZhdWx0X3hlbl9tY3Vf b3B0X2N0cmwpOwogfQogCiBzdGF0aWMgdm9pZCBfX2luaXQgX19tYXliZV91 bnVzZWQgYnVpbGRfYXNzZXJ0aW9ucyh2b2lkKQpkaWZmIC0tZ2l0IGEveGVu L2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmwuaCBiL3hlbi9pbmNsdWRlL2Fz bS14ODYvc3BlY19jdHJsLmgKaW5kZXggYmEwM2JiNDJlNS4uNTliYWIxYTQx YiAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmwu aAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2L3NwZWNfY3RybC5oCkBAIC01 Myw2ICs1Myw4IEBAIGV4dGVybiBpbnQ4X3Qgb3B0X3B2X2wxdGZfaHdkb20s IG9wdF9wdl9sMXRmX2RvbXU7CiAgKi8KIGV4dGVybiBwYWRkcl90IGwxdGZf YWRkcl9tYXNrLCBsMXRmX3NhZmVfbWFkZHI7CiAKK2V4dGVybiB1aW50NjRf dCBkZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmw7CisKIHN0YXRpYyBpbmxpbmUg dm9pZCBpbml0X3NoYWRvd19zcGVjX2N0cmxfc3RhdGUodm9pZCkKIHsKICAg ICBzdHJ1Y3QgY3B1X2luZm8gKmluZm8gPSBnZXRfY3B1X2luZm8oKTsK --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.12-3.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.12-3.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQWxsb3cgdGhlIFJEUkFORC9S RFNFRUQgZmVhdHVyZXMgdG8gYmUgaGlkZGVuCgpSRFJBTkQvUkRTRUVEIGNh biBiZSBoaWRkZW4gdXNpbmcgY3B1aWQ9IHRvIG1pdGlnYXRlIFNSQkRTIGlm IG1pY3JvY29kZQppc24ndCBhdmFpbGFibGUuCgpUaGlzIGlzIHBhcnQgb2Yg WFNBLTMyMCAvIENWRS0yMDIwLTA1NDMuCgpTaWduZWQtb2ZmLWJ5OiBBbmRy ZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpBY2tlZC1i eTogSnVsaWVuIEdyYWxsIDxqZ3JhbGxAYW1hem9uLmNvbT4KCmRpZmYgLS1n aXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MgYi9kb2Nz L21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKaW5kZXggMzM3ZmJmMDQ5 Mi4uNzg5N2RhNTVjYSAxMDA2NDQKLS0tIGEvZG9jcy9taXNjL3hlbi1jb21t YW5kLWxpbmUucGFuZG9jCisrKyBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1s aW5lLnBhbmRvYwpAQCAtNDgxLDEyICs0ODEsMTggQEAgY2hvaWNlIG9mIGBk b20wLWtlcm5lbGAgaXMgZGVwcmVjYXRlZCBhbmQgbm90IHN1cHBvcnRlZCBi eSBhbGwgRG9tMCBrZXJuZWxzLgogVGhpcyBvcHRpb24gYWxsb3dzIGZvciBm aW5lIHR1bmluZyBvZiB0aGUgZmFjaWxpdGllcyBYZW4gd2lsbCB1c2UsIGFm dGVyCiBhY2NvdW50aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXMg ZW51bWVyYXRlZCB2aWEgQ1BVSUQuCiAKK1VubGVzcyBvdGhlcndpc2Ugbm90 ZWQsIG9wdGlvbnMgb25seSBoYXZlIGFueSBlZmZlY3QgaW4gdGhlaXIgbmVn YXRpdmUgZm9ybSwKK3RvIGhpZGUgdGhlIG5hbWVkIGZlYXR1cmUocykuICBJ Z25vcmluZyBhIGZlYXR1cmUgdXNpbmcgdGhpcyBtZWNoYW5pc20gd2lsbAor Y2F1c2UgWGVuIG5vdCB0byB1c2UgdGhlIGZlYXR1cmUsIG5vciBvZmZlciB0 aGVtIGFzIHVzYWJsZSB0byBndWVzdHMuCisKIEN1cnJlbnRseSBhY2NlcHRl ZDoKIAogVGhlIFNwZWN1bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVhdHVy ZXMgYHNyYmRzLWN0cmxgLCBgbWQtY2xlYXJgLCBgaWJyc2JgLAogYHN0aWJw YCwgYGlicGJgLCBgbDFkLWZsdXNoYCBhbmQgYHNzYmRgIGFyZSB1c2VkIGJ5 IGRlZmF1bHQgaWYgYXZhaWxhYmxlIGFuZAotYXBwbGljYWJsZS4gIFRoZXkg Y2FuIGJlIGlnbm9yZWQsIGUuZy4gYG5vLWlicnNiYCwgYXQgd2hpY2ggcG9p bnQgWGVuIHdvbid0Ci11c2UgdGhlbSBpdHNlbGYsIGFuZCB3b24ndCBvZmZl ciB0aGVtIHRvIGd1ZXN0cy4KK2FwcGxpY2FibGUuICBUaGV5IGNhbiBhbGwg YmUgaWdub3JlZC4KKworYHJkcmFuZGAgYW5kIGByZHNlZWRgIGNhbiBiZSBp Z25vcmVkLCBhcyBhIG1pdGlnYXRpb24gdG8gWFNBLTMyMCAvCitDVkUtMjAy MC0wNTQzLgogCiAjIyMgY3B1aWRfbWFza19jcHUKID4gYD0gZmFtXzBmX3Jl dl9bY2RlZmddIHwgZmFtXzEwX3Jldl9bYmNdIHwgZmFtXzExX3Jldl9iYApk aWZmIC0tZ2l0IGEveGVuL2FyY2gveDg2L2NwdWlkLmMgYi94ZW4vYXJjaC94 ODYvY3B1aWQuYwppbmRleCAyMmQ4YzcxYTk1Li5kMDc1NjdjOTAxIDEwMDY0 NAotLS0gYS94ZW4vYXJjaC94ODYvY3B1aWQuYworKysgYi94ZW4vYXJjaC94 ODYvY3B1aWQuYwpAQCAtNjQsNiArNjQsMTYgQEAgc3RhdGljIGludCBfX2lu aXQgcGFyc2VfeGVuX2NwdWlkKGNvbnN0IGNoYXIgKnMpCiAgICAgICAgICAg ICBpZiAoICF2YWwgKQogICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2Nw dV9jYXAoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCk7CiAgICAgICAgIH0KKyAg ICAgICAgZWxzZSBpZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJyZHJhbmQi LCBzLCBzcykpID49IDAgKQorICAgICAgICB7CisgICAgICAgICAgICBpZiAo ICF2YWwgKQorICAgICAgICAgICAgICAgIHNldHVwX2NsZWFyX2NwdV9jYXAo WDg2X0ZFQVRVUkVfUkRSQU5EKTsKKyAgICAgICAgfQorICAgICAgICBlbHNl IGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4oInJkc2VlZCIsIHMsIHNzKSkg Pj0gMCApCisgICAgICAgIHsKKyAgICAgICAgICAgIGlmICggIXZhbCApCisg ICAgICAgICAgICAgICAgc2V0dXBfY2xlYXJfY3B1X2NhcChYODZfRkVBVFVS RV9SRFNFRUQpOworICAgICAgICB9CiAgICAgICAgIGVsc2UKICAgICAgICAg ICAgIHJjID0gLUVJTlZBTDsKIAo= --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.13-1.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.13-1.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogQ1BVSUQvTVNSIGRlZmluaXRp b25zIGZvciBTcGVjaWFsIFJlZ2lzdGVyIEJ1ZmZlciBEYXRhIFNhbXBsaW5n CgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENWRS0yMDIwLTA1NDMKClNp Z25lZC1vZmYtYnk6IEFuZHJldyBDb29wZXIgPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+ClJldmlld2VkLWJ5OiBKYW4gQmV1bGljaCA8amJldWxpY2hA c3VzZS5jb20+CkFja2VkLWJ5OiBXZWkgTGl1IDx3bEB4ZW4ub3JnPgoKZGlm ZiAtLWdpdCBhL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYyBi L2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYwppbmRleCAxZDlk ODE2NjIyLi45MjY4NDU0Mjk3IDEwMDY0NAotLS0gYS9kb2NzL21pc2MveGVu LWNvbW1hbmQtbGluZS5wYW5kb2MKKysrIGIvZG9jcy9taXNjL3hlbi1jb21t YW5kLWxpbmUucGFuZG9jCkBAIC00ODMsMTAgKzQ4MywxMCBAQCBhY2NvdW50 aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXMgZW51bWVyYXRlZCB2 aWEgQ1BVSUQuCiAKIEN1cnJlbnRseSBhY2NlcHRlZDoKIAotVGhlIFNwZWN1 bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVhdHVyZXMgYG1kLWNsZWFyYCwg YGlicnNiYCwgYHN0aWJwYCwgYGlicGJgLAotYGwxZC1mbHVzaGAgYW5kIGBz c2JkYCBhcmUgdXNlZCBieSBkZWZhdWx0IGlmIGF2YWlsYWJsZSBhbmQgYXBw bGljYWJsZS4gIFRoZXkgY2FuCi1iZSBpZ25vcmVkLCBlLmcuIGBuby1pYnJz YmAsIGF0IHdoaWNoIHBvaW50IFhlbiB3b24ndCB1c2UgdGhlbSBpdHNlbGYs IGFuZAotd29uJ3Qgb2ZmZXIgdGhlbSB0byBndWVzdHMuCitUaGUgU3BlY3Vs YXRpb24gQ29udHJvbCBoYXJkd2FyZSBmZWF0dXJlcyBgc3JiZHMtY3RybGAs IGBtZC1jbGVhcmAsIGBpYnJzYmAsCitgc3RpYnBgLCBgaWJwYmAsIGBsMWQt Zmx1c2hgIGFuZCBgc3NiZGAgYXJlIHVzZWQgYnkgZGVmYXVsdCBpZiBhdmFp bGFibGUgYW5kCithcHBsaWNhYmxlLiAgVGhleSBjYW4gYmUgaWdub3JlZCwg ZS5nLiBgbm8taWJyc2JgLCBhdCB3aGljaCBwb2ludCBYZW4gd29uJ3QKK3Vz ZSB0aGVtIGl0c2VsZiwgYW5kIHdvbid0IG9mZmVyIHRoZW0gdG8gZ3Vlc3Rz LgogCiAjIyMgY3B1aWRfbWFza19jcHUKID4gYD0gZmFtXzBmX3Jldl9bY2Rl ZmddIHwgZmFtXzEwX3Jldl9bYmNdIHwgZmFtXzExX3Jldl9iYApkaWZmIC0t Z2l0IGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYyBiL3Rvb2xzL2xpYnhs L2xpYnhsX2NwdWlkLmMKaW5kZXggNmNlYTQyMjdiYS4uYTc4ZjA4YjkyNyAx MDA2NDQKLS0tIGEvdG9vbHMvbGlieGwvbGlieGxfY3B1aWQuYworKysgYi90 b29scy9saWJ4bC9saWJ4bF9jcHVpZC5jCkBAIC0yMTMsNiArMjEzLDcgQEAg aW50IGxpYnhsX2NwdWlkX3BhcnNlX2NvbmZpZyhsaWJ4bF9jcHVpZF9wb2xp Y3lfbGlzdCAqY3B1aWQsIGNvbnN0IGNoYXIqIHN0cikKIAogICAgICAgICB7 ImF2eDUxMi00dm5uaXciLDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURY LCAgMiwgIDF9LAogICAgICAgICB7ImF2eDUxMi00Zm1hcHMiLDB4MDAwMDAw MDcsICAwLCBDUFVJRF9SRUdfRURYLCAgMywgIDF9LAorICAgICAgICB7InNy YmRzLWN0cmwiLCAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAg OSwgIDF9LAogICAgICAgICB7Im1kLWNsZWFyIiwgICAgIDB4MDAwMDAwMDcs ICAwLCBDUFVJRF9SRUdfRURYLCAxMCwgIDF9LAogICAgICAgICB7ImNldC1p YnQiLCAgICAgIDB4MDAwMDAwMDcsICAwLCBDUFVJRF9SRUdfRURYLCAyMCwg IDF9LAogICAgICAgICB7ImlicnNiIiwgICAgICAgIDB4MDAwMDAwMDcsICAw LCBDUFVJRF9SRUdfRURYLCAyNiwgIDF9LApkaWZmIC0tZ2l0IGEvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYyBiL3Rvb2xzL21pc2MveGVuLWNwdWlkLmMKaW5k ZXggNjAzZTFkNjVmZC4uYTA5NDQwODEzYiAxMDA2NDQKLS0tIGEvdG9vbHMv bWlzYy94ZW4tY3B1aWQuYworKysgYi90b29scy9taXNjL3hlbi1jcHVpZC5j CkBAIC0xNTcsNiArMTU3LDcgQEAgc3RhdGljIGNvbnN0IGNoYXIgKmNvbnN0 IHN0cl83ZDBbMzJdID0KICAgICBbIDJdID0gImF2eDUxMl80dm5uaXciLCBb IDNdID0gImF2eDUxMl80Zm1hcHMiLAogICAgIFsgNF0gPSAiZnNybSIsCiAK KyAgICAvKiAgOCAqLyAgICAgICAgICAgICAgICBbIDldID0gInNyYmRzLWN0 cmwiLAogICAgIFsxMF0gPSAibWQtY2xlYXIiLAogICAgIC8qIDEyICovICAg ICAgICAgICAgICAgIFsxM10gPSAidHN4LWZvcmNlLWFib3J0IiwKIApkaWZm IC0tZ2l0IGEveGVuL2FyY2gveDg2L21zci5jIGIveGVuL2FyY2gveDg2L21z ci5jCmluZGV4IDRiMTIxMDM0ODIuLjBjZGVkM2MwYWQgMTAwNjQ0Ci0tLSBh L3hlbi9hcmNoL3g4Ni9tc3IuYworKysgYi94ZW4vYXJjaC94ODYvbXNyLmMK QEAgLTEzNCw2ICsxMzQsNyBAQCBpbnQgZ3Vlc3RfcmRtc3Ioc3RydWN0IHZj cHUgKnYsIHVpbnQzMl90IG1zciwgdWludDY0X3QgKnZhbCkKICAgICAgICAg LyogV3JpdGUtb25seSAqLwogICAgIGNhc2UgTVNSX1RTWF9GT1JDRV9BQk9S VDoKICAgICBjYXNlIE1TUl9UU1hfQ1RSTDoKKyAgICBjYXNlIE1TUl9NQ1Vf T1BUX0NUUkw6CiAgICAgY2FzZSBNU1JfVV9DRVQ6CiAgICAgY2FzZSBNU1Jf U19DRVQ6CiAgICAgY2FzZSBNU1JfUEwwX1NTUCAuLi4gTVNSX0lOVEVSUlVQ VF9TU1BfVEFCTEU6CkBAIC0yODgsNiArMjg5LDcgQEAgaW50IGd1ZXN0X3dy bXNyKHN0cnVjdCB2Y3B1ICp2LCB1aW50MzJfdCBtc3IsIHVpbnQ2NF90IHZh bCkKICAgICAgICAgLyogUmVhZC1vbmx5ICovCiAgICAgY2FzZSBNU1JfVFNY X0ZPUkNFX0FCT1JUOgogICAgIGNhc2UgTVNSX1RTWF9DVFJMOgorICAgIGNh c2UgTVNSX01DVV9PUFRfQ1RSTDoKICAgICBjYXNlIE1TUl9VX0NFVDoKICAg ICBjYXNlIE1TUl9TX0NFVDoKICAgICBjYXNlIE1TUl9QTDBfU1NQIC4uLiBN U1JfSU5URVJSVVBUX1NTUF9UQUJMRToKZGlmZiAtLWdpdCBhL3hlbi9hcmNo L3g4Ni9zcGVjX2N0cmwuYyBiL3hlbi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpp bmRleCA2NjU2YzQ0YWVjLi41ZmMxYzY4MjdlIDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvc3BlY19jdHJsLmMKKysrIGIveGVuL2FyY2gveDg2L3NwZWNf Y3RybC5jCkBAIC0zMTIsMTIgKzMxMiwxMyBAQCBzdGF0aWMgdm9pZCBfX2lu aXQgcHJpbnRfZGV0YWlscyhlbnVtIGluZF90aHVuayB0aHVuaywgdWludDY0 X3QgY2FwcykKICAgICBwcmludGsoIlNwZWN1bGF0aXZlIG1pdGlnYXRpb24g ZmFjaWxpdGllczpcbiIpOwogCiAgICAgLyogSGFyZHdhcmUgZmVhdHVyZXMg d2hpY2ggcGVydGFpbiB0byBzcGVjdWxhdGl2ZSBtaXRpZ2F0aW9ucy4gKi8K LSAgICBwcmludGsoIiAgSGFyZHdhcmUgZmVhdHVyZXM6JXMlcyVzJXMlcyVz JXMlcyVzJXMlcyVzJXMlc1xuIiwKKyAgICBwcmludGsoIiAgSGFyZHdhcmUg ZmVhdHVyZXM6JXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzJXMlcyVzXG4iLAog ICAgICAgICAgICAoXzdkMCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9J QlJTQikpID8gIiBJQlJTL0lCUEIiIDogIiIsCiAgICAgICAgICAgIChfN2Qw ICYgY3B1ZmVhdF9tYXNrKFg4Nl9GRUFUVVJFX1NUSUJQKSkgPyAiIFNUSUJQ IiAgICAgOiAiIiwKICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2so WDg2X0ZFQVRVUkVfTDFEX0ZMVVNIKSkgPyAiIEwxRF9GTFVTSCIgOiAiIiwK ICAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21hc2soWDg2X0ZFQVRVUkVf U1NCRCkpICA/ICIgU1NCRCIgICAgICA6ICIiLAogICAgICAgICAgICAoXzdk MCAmIGNwdWZlYXRfbWFzayhYODZfRkVBVFVSRV9NRF9DTEVBUikpID8gIiBN RF9DTEVBUiIgOiAiIiwKKyAgICAgICAgICAgKF83ZDAgJiBjcHVmZWF0X21h c2soWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkpID8gIiBTUkJEU19DVFJMIiA6 ICIiLAogICAgICAgICAgICAoZThiICAmIGNwdWZlYXRfbWFzayhYODZfRkVB VFVSRV9JQlBCKSkgID8gIiBJQlBCIiAgICAgIDogIiIsCiAgICAgICAgICAg IChjYXBzICYgQVJDSF9DQVBTX0lCUlNfQUxMKSAgICAgICAgICAgICAgPyAi IElCUlNfQUxMIiAgOiAiIiwKICAgICAgICAgICAgKGNhcHMgJiBBUkNIX0NB UFNfUkRDTF9OTykgICAgICAgICAgICAgICA/ICIgUkRDTF9OTyIgICA6ICIi LApkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLXg4Ni9tc3ItaW5kZXgu aCBiL3hlbi9pbmNsdWRlL2FzbS14ODYvbXNyLWluZGV4LmgKaW5kZXggNzY5 M2M0YTcxYS4uOTE5OTQ2NjllMSAxMDA2NDQKLS0tIGEveGVuL2luY2x1ZGUv YXNtLXg4Ni9tc3ItaW5kZXguaAorKysgYi94ZW4vaW5jbHVkZS9hc20teDg2 L21zci1pbmRleC5oCkBAIC0xNzksNiArMTc5LDkgQEAKICNkZWZpbmUgTVNS X0lBMzJfVk1YX1RSVUVfRU5UUllfQ1RMUyAgICAgICAgICAgIDB4NDkwCiAj ZGVmaW5lIE1TUl9JQTMyX1ZNWF9WTUZVTkMgICAgICAgICAgICAgICAgICAg ICAweDQ5MQogCisjZGVmaW5lIE1TUl9NQ1VfT1BUX0NUUkwgICAgICAgICAg ICAgICAgICAgIDB4MDAwMDAxMjMKKyNkZWZpbmUgIE1DVV9PUFRfQ1RSTF9S TkdEU19NSVRHX0RJUyAgICAgICAgKF9BQygxLCBVTEwpIDw8ICAwKQorCiAj ZGVmaW5lIE1TUl9VX0NFVCAgICAgICAgICAgICAgICAgICAgICAgICAgIDB4 MDAwMDA2YTAKICNkZWZpbmUgTVNSX1NfQ0VUICAgICAgICAgICAgICAgICAg ICAgICAgICAgMHgwMDAwMDZhMgogI2RlZmluZSBNU1JfUEwwX1NTUCAgICAg ICAgICAgICAgICAgICAgICAgICAweDAwMDAwNmE0CmRpZmYgLS1naXQgYS94 ZW4vaW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oIGIv eGVuL2luY2x1ZGUvcHVibGljL2FyY2gteDg2L2NwdWZlYXR1cmVzZXQuaApp bmRleCAyODM1Njg4ZjFjLi5hMjQ4MmMzNjI3IDEwMDY0NAotLS0gYS94ZW4v aW5jbHVkZS9wdWJsaWMvYXJjaC14ODYvY3B1ZmVhdHVyZXNldC5oCisrKyBi L3hlbi9pbmNsdWRlL3B1YmxpYy9hcmNoLXg4Ni9jcHVmZWF0dXJlc2V0LmgK QEAgLTI1Miw2ICsyNTIsNyBAQCBYRU5fQ1BVRkVBVFVSRShJQlBCLCAgICAg ICAgICA4KjMyKzEyKSAvKkEgIElCUEIgc3VwcG9ydCBvbmx5IChubyBJQlJT LCB1c2VkIGJ5CiAvKiBJbnRlbC1kZWZpbmVkIENQVSBmZWF0dXJlcywgQ1BV SUQgbGV2ZWwgMHgwMDAwMDAwNzowLmVkeCwgd29yZCA5ICovCiBYRU5fQ1BV RkVBVFVSRShBVlg1MTJfNFZOTklXLCA5KjMyKyAyKSAvKkEgIEFWWDUxMiBO ZXVyYWwgTmV0d29yayBJbnN0cnVjdGlvbnMgKi8KIFhFTl9DUFVGRUFUVVJF KEFWWDUxMl80Rk1BUFMsIDkqMzIrIDMpIC8qQSAgQVZYNTEyIE11bHRpcGx5 IEFjY3VtdWxhdGlvbiBTaW5nbGUgUHJlY2lzaW9uICovCitYRU5fQ1BVRkVB VFVSRShTUkJEU19DVFJMLCAgICA5KjMyKyA5KSAvKiAgIE1TUl9NQ1VfT1BU X0NUUkwgYW5kIFJOR0RTX01JVEdfRElTLiAqLwogWEVOX0NQVUZFQVRVUkUo TURfQ0xFQVIsICAgICAgOSozMisxMCkgLypBICBWRVJXIGNsZWFycyBtaWNy b2FyY2hpdGVjdHVyYWwgYnVmZmVycyAqLwogWEVOX0NQVUZFQVRVUkUoVFNY X0ZPUkNFX0FCT1JULCA5KjMyKzEzKSAvKiBNU1JfVFNYX0ZPUkNFX0FCT1JU LlJUTV9BQk9SVCAqLwogWEVOX0NQVUZFQVRVUkUoQ0VUX0lCVCwgICAgICAg OSozMisyMCkgLyogICBDRVQgLSBJbmRpcmVjdCBCcmFuY2ggVHJhY2tpbmcg Ki8K --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.13-2.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.13-2.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogTWl0aWdhdGUgdGhlIFNwZWNp YWwgUmVnaXN0ZXIgQnVmZmVyIERhdGEgU2FtcGxpbmcgc2lkZWNoYW5uZWwK ClNlZSBwYXRjaCBkb2N1bWVudGF0aW9uIGFuZCBjb21tZW50cy4KClRoaXMg aXMgcGFydCBvZiBYU0EtMzIwIC8gQ1ZFLTIwMjAtMDU0MwoKU2lnbmVkLW9m Zi1ieTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KUmV2aWV3ZWQtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNv bT4KCmRpZmYgLS1naXQgYS9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5w YW5kb2MgYi9kb2NzL21pc2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MKaW5k ZXggOTI2ODQ1NDI5Ny4uYzc4MDMxMjUzMSAxMDA2NDQKLS0tIGEvZG9jcy9t aXNjL3hlbi1jb21tYW5kLWxpbmUucGFuZG9jCisrKyBiL2RvY3MvbWlzYy94 ZW4tY29tbWFuZC1saW5lLnBhbmRvYwpAQCAtMTk5MSw3ICsxOTkxLDcgQEAg QnkgZGVmYXVsdCBTU0JEIHdpbGwgYmUgbWl0aWdhdGVkIGF0IHJ1bnRpbWUg KGkuZSBgc3NiZD1ydW50aW1lYCkuCiAjIyMgc3BlYy1jdHJsICh4ODYpCiA+ IGA9IExpc3Qgb2YgWyA8Ym9vbD4sIHhlbj08Ym9vbD4sIHtwdixodm0sbXNy LXNjLHJzYixtZC1jbGVhcn09PGJvb2w+LAogPiAgICAgICAgICAgICAgYnRp LXRodW5rPXJldHBvbGluZXxsZmVuY2V8am1wLCB7aWJycyxpYnBiLHNzYmQs ZWFnZXItZnB1LAotPiAgICAgICAgICAgICAgbDFkLWZsdXNoLGJyYW5jaC1o YXJkZW59PTxib29sPiBdYAorPiAgICAgICAgICAgICAgbDFkLWZsdXNoLGJy YW5jaC1oYXJkZW4sc3JiLWxvY2t9PTxib29sPiBdYAogCiBDb250cm9scyBm b3Igc3BlY3VsYXRpdmUgZXhlY3V0aW9uIHNpZGVjaGFubmVsIG1pdGlnYXRp b25zLiAgQnkgZGVmYXVsdCwgWGVuCiB3aWxsIHBpY2sgdGhlIG1vc3QgYXBw cm9wcmlhdGUgbWl0aWdhdGlvbnMgYmFzZWQgb24gY29tcGlsZWQgaW4gc3Vw cG9ydCwKQEAgLTIwNjgsNiArMjA2OCwxMiBAQCBJZiBYZW4gaXMgY29tcGls ZWQgd2l0aCBgQ09ORklHX1NQRUNVTEFUSVZFX0hBUkRFTl9CUkFOQ0hgLCB0 aGUKIHNwZWN1bGF0aW9uIGJhcnJpZXJzIHRvIHByb3RlY3Qgc2VsZWN0ZWQg Y29uZGl0aW9uYWwgYnJhbmNoZXMuICBCeSBkZWZhdWx0LAogWGVuIHdpbGwg ZW5hYmxlIHRoaXMgbWl0aWdhdGlvbi4KIAorT24gaGFyZHdhcmUgc3VwcG9y dGluZyBTUkJEU19DVFJMLCB0aGUgYHNyYi1sb2NrPWAgb3B0aW9uIGNhbiBi ZSB1c2VkIHRvIGZvcmNlCitvciBwcmV2ZW50IFhlbiBmcm9tIHByb3RlY3Qg dGhlIFNwZWNpYWwgUmVnaXN0ZXIgQnVmZmVyIGZyb20gbGVha2luZyBzdGFs ZQorZGF0YS4gQnkgZGVmYXVsdCwgWGVuIHdpbGwgZW5hYmxlIHRoaXMgbWl0 aWdhdGlvbiwgZXhjZXB0IG9uIHBhcnRzIHdoZXJlIE1EUworaXMgZml4ZWQg YW5kIFRBQSBpcyBmaXhlZC9taXRpZ2F0ZWQgKGluIHdoaWNoIGNhc2UsIHRo ZXJlIGlzIGJlbGlldmVkIHRvIGJlIG5vCit3YXkgZm9yIGFuIGF0dGFja2Vy IHRvIG9idGFpbiB0aGUgc3RhbGUgZGF0YSkuCisKICMjIyBzeW5jX2NvbnNv bGUKID4gYD0gPGJvb2xlYW4+YAogCmRpZmYgLS1naXQgYS94ZW4vYXJjaC94 ODYvYWNwaS9wb3dlci5jIGIveGVuL2FyY2gveDg2L2FjcGkvcG93ZXIuYwpp bmRleCBmZWIwZjZjZTIwLi43NWM2ZTM0MTY0IDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvYWNwaS9wb3dlci5jCisrKyBiL3hlbi9hcmNoL3g4Ni9hY3Bp L3Bvd2VyLmMKQEAgLTI5NSw2ICsyOTUsOSBAQCBzdGF0aWMgaW50IGVudGVy X3N0YXRlKHUzMiBzdGF0ZSkKICAgICBjaS0+c3BlY19jdHJsX2ZsYWdzIHw9 IChkZWZhdWx0X3NwZWNfY3RybF9mbGFncyAmIFNDRl9pc3Rfd3Jtc3IpOwog ICAgIHNwZWNfY3RybF9leGl0X2lkbGUoY2kpOwogCisgICAgaWYgKCBib290 X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAgICAgICB3 cm1zcmwoTVNSX01DVV9PUFRfQ1RSTCwgZGVmYXVsdF94ZW5fbWN1X29wdF9j dHJsKTsKKwogIGRvbmU6CiAgICAgc3Bpbl9kZWJ1Z19lbmFibGUoKTsKICAg ICBsb2NhbF9pcnFfcmVzdG9yZShmbGFncyk7CmRpZmYgLS1naXQgYS94ZW4v YXJjaC94ODYvc21wYm9vdC5jIGIveGVuL2FyY2gveDg2L3NtcGJvb3QuYwpp bmRleCBkYzhmZGFjMWExLi5iMWU1MWIzYWZmIDEwMDY0NAotLS0gYS94ZW4v YXJjaC94ODYvc21wYm9vdC5jCisrKyBiL3hlbi9hcmNoL3g4Ni9zbXBib290 LmMKQEAgLTM2MSwxMiArMzYxLDE0IEBAIHZvaWQgc3RhcnRfc2Vjb25kYXJ5 KHZvaWQgKnVudXNlZCkKICAgICBtaWNyb2NvZGVfdXBkYXRlX29uZShmYWxz ZSk7CiAKICAgICAvKgotICAgICAqIElmIE1TUl9TUEVDX0NUUkwgaXMgYXZh aWxhYmxlLCBhcHBseSBYZW4ncyBkZWZhdWx0IHNldHRpbmcgYW5kIGRpc2Nh cmQKLSAgICAgKiBhbnkgZmlybXdhcmUgc2V0dGluZ3MuICBOb3RlOiBNU1Jf U1BFQ19DVFJMIG1heSBvbmx5IGJlY29tZSBhdmFpbGFibGUKLSAgICAgKiBh ZnRlciBsb2FkaW5nIG1pY3JvY29kZS4KKyAgICAgKiBJZiBhbnkgc3BlY3Vs YXRpdmUgY29udHJvbCBNU1JzIGFyZSBhdmFpbGFibGUsIGFwcGx5IFhlbidz IGRlZmF1bHQKKyAgICAgKiBzZXR0aW5ncy4gIE5vdGU6IFRoZXNlIE1TUnMg bWF5IG9ubHkgYmVjb21lIGF2YWlsYWJsZSBhZnRlciBsb2FkaW5nCisgICAg ICogbWljcm9jb2RlLgogICAgICAqLwogICAgIGlmICggYm9vdF9jcHVfaGFz KFg4Nl9GRUFUVVJFX0lCUlNCKSApCiAgICAgICAgIHdybXNybChNU1JfU1BF Q19DVFJMLCBkZWZhdWx0X3hlbl9zcGVjX2N0cmwpOworICAgIGlmICggYm9v dF9jcHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICAgICAg d3Jtc3JsKE1TUl9NQ1VfT1BUX0NUUkwsIGRlZmF1bHRfeGVuX21jdV9vcHRf Y3RybCk7CiAKICAgICB0c3hfaW5pdCgpOyAvKiBOZWVkcyBtaWNyb2NvZGUu ICBNYXkgY2hhbmdlIEhMRS9SVE0gZmVhdHVyZSBiaXRzLiAqLwogCmRpZmYg LS1naXQgYS94ZW4vYXJjaC94ODYvc3BlY19jdHJsLmMgYi94ZW4vYXJjaC94 ODYvc3BlY19jdHJsLmMKaW5kZXggNWZjMWM2ODI3ZS4uMzMzNDMwNjJhNyAx MDA2NDQKLS0tIGEveGVuL2FyY2gveDg2L3NwZWNfY3RybC5jCisrKyBiL3hl bi9hcmNoL3g4Ni9zcGVjX2N0cmwuYwpAQCAtNjUsNiArNjUsOSBAQCBzdGF0 aWMgdW5zaWduZWQgaW50IF9faW5pdGRhdGEgbDFkX21heHBoeXNhZGRyOwog c3RhdGljIGJvb2wgX19pbml0ZGF0YSBjcHVfaGFzX2J1Z19tc2Jkc19vbmx5 OyAvKiA9PiBtaW5pbWFsIEhUIGltcGFjdC4gKi8KIHN0YXRpYyBib29sIF9f aW5pdGRhdGEgY3B1X2hhc19idWdfbWRzOyAvKiBBbnkgb3RoZXIgTXtMUCxT QixGQn1EUyBjb21iaW5hdGlvbi4gKi8KIAorc3RhdGljIGludDhfdCBfX2lu aXRkYXRhIG9wdF9zcmJfbG9jayA9IC0xOwordWludDY0X3QgX19yZWFkX21v c3RseSBkZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmw7CisKIHN0YXRpYyBpbnQg X19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogewogICAg IGNvbnN0IGNoYXIgKnNzOwpAQCAtMTEyLDYgKzExNSw3IEBAIHN0YXRpYyBp bnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogICAg ICAgICAgICAgb3B0X3NzYmQgPSBmYWxzZTsKICAgICAgICAgICAgIG9wdF9s MWRfZmx1c2ggPSAwOwogICAgICAgICAgICAgb3B0X2JyYW5jaF9oYXJkZW4g PSBmYWxzZTsKKyAgICAgICAgICAgIG9wdF9zcmJfbG9jayA9IDA7CiAgICAg ICAgIH0KICAgICAgICAgZWxzZSBpZiAoIHZhbCA+IDAgKQogICAgICAgICAg ICAgcmMgPSAtRUlOVkFMOwpAQCAtMTc4LDYgKzE4Miw4IEBAIHN0YXRpYyBp bnQgX19pbml0IHBhcnNlX3NwZWNfY3RybChjb25zdCBjaGFyICpzKQogICAg ICAgICAgICAgb3B0X2wxZF9mbHVzaCA9IHZhbDsKICAgICAgICAgZWxzZSBp ZiAoICh2YWwgPSBwYXJzZV9ib29sZWFuKCJicmFuY2gtaGFyZGVuIiwgcywg c3MpKSA+PSAwICkKICAgICAgICAgICAgIG9wdF9icmFuY2hfaGFyZGVuID0g dmFsOworICAgICAgICBlbHNlIGlmICggKHZhbCA9IHBhcnNlX2Jvb2xlYW4o InNyYi1sb2NrIiwgcywgc3MpKSA+PSAwICkKKyAgICAgICAgICAgIG9wdF9z cmJfbG9jayA9IHZhbDsKICAgICAgICAgZWxzZQogICAgICAgICAgICAgcmMg PSAtRUlOVkFMOwogCkBAIC0zNDEsNyArMzQ3LDcgQEAgc3RhdGljIHZvaWQg X19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVp bnQ2NF90IGNhcHMpCiAgICAgICAgICAgICAgICAiXG4iKTsKIAogICAgIC8q IFNldHRpbmdzIGZvciBYZW4ncyBwcm90ZWN0aW9uLCBpcnJlc3BlY3RpdmUg b2YgZ3Vlc3RzLiAqLwotICAgIHByaW50aygiICBYZW4gc2V0dGluZ3M6IEJU SS1UaHVuayAlcywgU1BFQ19DVFJMOiAlcyVzJXMsIE90aGVyOiVzJXMlcyVz XG4iLAorICAgIHByaW50aygiICBYZW4gc2V0dGluZ3M6IEJUSS1UaHVuayAl cywgU1BFQ19DVFJMOiAlcyVzJXMsIE90aGVyOiVzJXMlcyVzJXNcbiIsCiAg ICAgICAgICAgIHRodW5rID09IFRIVU5LX05PTkUgICAgICA/ICJOL0EiIDoK ICAgICAgICAgICAgdGh1bmsgPT0gVEhVTktfUkVUUE9MSU5FID8gIlJFVFBP TElORSIgOgogICAgICAgICAgICB0aHVuayA9PSBUSFVOS19MRkVOQ0UgICAg PyAiTEZFTkNFIiA6CkBAIC0zNTIsNiArMzU4LDggQEAgc3RhdGljIHZvaWQg X19pbml0IHByaW50X2RldGFpbHMoZW51bSBpbmRfdGh1bmsgdGh1bmssIHVp bnQ2NF90IGNhcHMpCiAgICAgICAgICAgIChkZWZhdWx0X3hlbl9zcGVjX2N0 cmwgJiBTUEVDX0NUUkxfU1NCRCkgID8gIiBTU0JEKyIgOiAiIFNTQkQtIiwK ICAgICAgICAgICAgIShjYXBzICYgQVJDSF9DQVBTX1RTWF9DVFJMKSAgICAg ICAgICAgICAgPyAiIiA6CiAgICAgICAgICAgIChvcHRfdHN4ICYgMSkgICAg ICAgICAgICAgICAgICAgICAgICAgICAgID8gIiBUU1grIiA6ICIgVFNYLSIs CisgICAgICAgICAgICFib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNf Q1RSTCkgICAgID8gIiIgOgorICAgICAgICAgICBvcHRfc3JiX2xvY2sgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA/ICIgU1JCX0xPQ0srIiA6ICIg U1JCX0xPQ0stIiwKICAgICAgICAgICAgb3B0X2licGIgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPyAiIElCUEIiICA6ICIiLAogICAgICAg ICAgICBvcHRfbDFkX2ZsdXNoICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA/ICIgTDFEX0ZMVVNIIiA6ICIiLAogICAgICAgICAgICBvcHRfbWRfY2xl YXJfcHYgfHwgb3B0X21kX2NsZWFyX2h2bSAgICAgICA/ICIgVkVSVyIgIDog IiIsCkBAIC0xMTQ5LDYgKzExNTcsMzQgQEAgdm9pZCBfX2luaXQgaW5pdF9z cGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQogICAgICAgICB0c3hfaW5p dCgpOwogICAgIH0KIAorICAgIC8qIENhbGN1bGF0ZSBzdWl0YWJsZSBkZWZh dWx0cyBmb3IgTVNSX01DVV9PUFRfQ1RSTCAqLworICAgIGlmICggYm9vdF9j cHVfaGFzKFg4Nl9GRUFUVVJFX1NSQkRTX0NUUkwpICkKKyAgICB7CisgICAg ICAgIHVpbnQ2NF90IHZhbDsKKworICAgICAgICByZG1zcmwoTVNSX01DVV9P UFRfQ1RSTCwgdmFsKTsKKworICAgICAgICAvKgorICAgICAgICAgKiBPbiBz b21lIFNSQkRTLWFmZmVjdGVkIGhhcmR3YXJlLCBpdCBtYXkgYmUgc2FmZSB0 byByZWxheCBzcmItbG9jaworICAgICAgICAgKiBieSBkZWZhdWx0LgorICAg ICAgICAgKgorICAgICAgICAgKiBPbiBwYXJ0cyB3aGljaCBlbnVtZXJhdGUg TURTX05PIGFuZCBub3QgVEFBX05PLCBUU1ggaXMgdGhlIG9ubHkgd2F5Cisg ICAgICAgICAqIHRvIGFjY2VzcyB0aGUgRmlsbCBCdWZmZXIuICBJZiBUU1gg aXNuJ3QgYXZhaWxhYmxlIChpbmMuIFNLVQorICAgICAgICAgKiByZWFzb25z IG9uIHNvbWUgbW9kZWxzKSwgb3IgVFNYIGlzIGV4cGxpY2l0bHkgZGlzYWJs ZWQsIHRoZW4gdGhlcmUKKyAgICAgICAgICogaXMgbm8gbmVlZCBmb3IgdGhl IGV4dHJhIG92ZXJoZWFkIHRvIHByb3RlY3QgUkRSQU5EL1JEU0VFRC4KKyAg ICAgICAgICovCisgICAgICAgIGlmICggb3B0X3NyYl9sb2NrID09IC0xICYm CisgICAgICAgICAgICAgKGNhcHMgJiAoQVJDSF9DQVBTX01EU19OT3xBUkNI X0NBUFNfVEFBX05PKSkgPT0gQVJDSF9DQVBTX01EU19OTyAmJgorICAgICAg ICAgICAgICghY3B1X2hhc19obGUgfHwgKChjYXBzICYgQVJDSF9DQVBTX1RT WF9DVFJMKSAmJiBvcHRfdHN4ID09IDApKSApCisgICAgICAgICAgICBvcHRf c3JiX2xvY2sgPSAwOworCisgICAgICAgIHZhbCAmPSB+TUNVX09QVF9DVFJM X1JOR0RTX01JVEdfRElTOworICAgICAgICBpZiAoICFvcHRfc3JiX2xvY2sg KQorICAgICAgICAgICAgdmFsIHw9IE1DVV9PUFRfQ1RSTF9STkdEU19NSVRH X0RJUzsKKworICAgICAgICBkZWZhdWx0X3hlbl9tY3Vfb3B0X2N0cmwgPSB2 YWw7CisgICAgfQorCiAgICAgcHJpbnRfZGV0YWlscyh0aHVuaywgY2Fwcyk7 CiAKICAgICAvKgpAQCAtMTE4MCw2ICsxMjE2LDkgQEAgdm9pZCBfX2luaXQg aW5pdF9zcGVjdWxhdGlvbl9taXRpZ2F0aW9ucyh2b2lkKQogCiAgICAgICAg IHdybXNybChNU1JfU1BFQ19DVFJMLCBic3BfZGVsYXlfc3BlY19jdHJsID8g MCA6IGRlZmF1bHRfeGVuX3NwZWNfY3RybCk7CiAgICAgfQorCisgICAgaWYg KCBib290X2NwdV9oYXMoWDg2X0ZFQVRVUkVfU1JCRFNfQ1RSTCkgKQorICAg ICAgICB3cm1zcmwoTVNSX01DVV9PUFRfQ1RSTCwgZGVmYXVsdF94ZW5fbWN1 X29wdF9jdHJsKTsKIH0KIAogc3RhdGljIHZvaWQgX19pbml0IF9fbWF5YmVf dW51c2VkIGJ1aWxkX2Fzc2VydGlvbnModm9pZCkKZGlmZiAtLWdpdCBhL3hl bi9pbmNsdWRlL2FzbS14ODYvc3BlY19jdHJsLmggYi94ZW4vaW5jbHVkZS9h c20teDg2L3NwZWNfY3RybC5oCmluZGV4IDljYWVjZGRmZWMuLmIyNTJiYjg2 MzEgMTAwNjQ0Ci0tLSBhL3hlbi9pbmNsdWRlL2FzbS14ODYvc3BlY19jdHJs LmgKKysrIGIveGVuL2luY2x1ZGUvYXNtLXg4Ni9zcGVjX2N0cmwuaApAQCAt NTQsNiArNTQsOCBAQCBleHRlcm4gaW50OF90IG9wdF9wdl9sMXRmX2h3ZG9t LCBvcHRfcHZfbDF0Zl9kb211OwogICovCiBleHRlcm4gcGFkZHJfdCBsMXRm X2FkZHJfbWFzaywgbDF0Zl9zYWZlX21hZGRyOwogCitleHRlcm4gdWludDY0 X3QgZGVmYXVsdF94ZW5fbWN1X29wdF9jdHJsOworCiBzdGF0aWMgaW5saW5l IHZvaWQgaW5pdF9zaGFkb3dfc3BlY19jdHJsX3N0YXRlKHZvaWQpCiB7CiAg ICAgc3RydWN0IGNwdV9pbmZvICppbmZvID0gZ2V0X2NwdV9pbmZvKCk7Cg== --=separator Content-Type: application/octet-stream; name="xsa320/xsa320-4.13-3.patch" Content-Disposition: attachment; filename="xsa320/xsa320-4.13-3.patch" Content-Transfer-Encoding: base64 RnJvbTogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4KU3ViamVjdDogeDg2L3NwZWMtY3RybDogVXBkYXRlIGRvY3Mgd2l0aCBT UkJEUyB3b3JrYXJvdW5kCgpSRFJBTkQvUkRTRUVEIGNhbiBiZSBoaWRkZW4g dXNpbmcgY3B1aWQ9IHRvIG1pdGlnYXRlIFNSQkRTIGlmIG1pY3JvY29kZQpp c24ndCBhdmFpbGFibGUuCgpUaGlzIGlzIHBhcnQgb2YgWFNBLTMyMCAvIENW RS0yMDIwLTA1NDMuCgpTaWduZWQtb2ZmLWJ5OiBBbmRyZXcgQ29vcGVyIDxh bmRyZXcuY29vcGVyM0BjaXRyaXguY29tPgpBY2tlZC1ieTogSnVsaWVuIEdy YWxsIDxqZ3JhbGxAYW1hem9uLmNvbT4KCmRpZmYgLS1naXQgYS9kb2NzL21p c2MveGVuLWNvbW1hbmQtbGluZS5wYW5kb2MgYi9kb2NzL21pc2MveGVuLWNv bW1hbmQtbGluZS5wYW5kb2MKaW5kZXggYzc4MDMxMjUzMS4uODFlMTJkMDUz YyAxMDA2NDQKLS0tIGEvZG9jcy9taXNjL3hlbi1jb21tYW5kLWxpbmUucGFu ZG9jCisrKyBiL2RvY3MvbWlzYy94ZW4tY29tbWFuZC1saW5lLnBhbmRvYwpA QCAtNDgxLDEyICs0ODEsMTggQEAgY2hvaWNlIG9mIGBkb20wLWtlcm5lbGAg aXMgZGVwcmVjYXRlZCBhbmQgbm90IHN1cHBvcnRlZCBieSBhbGwgRG9tMCBr ZXJuZWxzLgogVGhpcyBvcHRpb24gYWxsb3dzIGZvciBmaW5lIHR1bmluZyBv ZiB0aGUgZmFjaWxpdGllcyBYZW4gd2lsbCB1c2UsIGFmdGVyCiBhY2NvdW50 aW5nIGZvciBoYXJkd2FyZSBjYXBhYmlsaXRpZXMgYXMgZW51bWVyYXRlZCB2 aWEgQ1BVSUQuCiAKK1VubGVzcyBvdGhlcndpc2Ugbm90ZWQsIG9wdGlvbnMg b25seSBoYXZlIGFueSBlZmZlY3QgaW4gdGhlaXIgbmVnYXRpdmUgZm9ybSwK K3RvIGhpZGUgdGhlIG5hbWVkIGZlYXR1cmUocykuICBJZ25vcmluZyBhIGZl YXR1cmUgdXNpbmcgdGhpcyBtZWNoYW5pc20gd2lsbAorY2F1c2UgWGVuIG5v dCB0byB1c2UgdGhlIGZlYXR1cmUsIG5vciBvZmZlciB0aGVtIGFzIHVzYWJs ZSB0byBndWVzdHMuCisKIEN1cnJlbnRseSBhY2NlcHRlZDoKIAogVGhlIFNw ZWN1bGF0aW9uIENvbnRyb2wgaGFyZHdhcmUgZmVhdHVyZXMgYHNyYmRzLWN0 cmxgLCBgbWQtY2xlYXJgLCBgaWJyc2JgLAogYHN0aWJwYCwgYGlicGJgLCBg bDFkLWZsdXNoYCBhbmQgYHNzYmRgIGFyZSB1c2VkIGJ5IGRlZmF1bHQgaWYg YXZhaWxhYmxlIGFuZAotYXBwbGljYWJsZS4gIFRoZXkgY2FuIGJlIGlnbm9y ZWQsIGUuZy4gYG5vLWlicnNiYCwgYXQgd2hpY2ggcG9pbnQgWGVuIHdvbid0 Ci11c2UgdGhlbSBpdHNlbGYsIGFuZCB3b24ndCBvZmZlciB0aGVtIHRvIGd1 ZXN0cy4KK2FwcGxpY2FibGUuICBUaGV5IGNhbiBhbGwgYmUgaWdub3JlZC4K KworYHJkcmFuZGAgYW5kIGByZHNlZWRgIGNhbiBiZSBpZ25vcmVkLCBhcyBh IG1pdGlnYXRpb24gdG8gWFNBLTMyMCAvCitDVkUtMjAyMC0wNTQzLgogCiAj IyMgY3B1aWRfbWFza19jcHUKID4gYD0gZmFtXzBmX3Jldl9bY2RlZmddIHwg ZmFtXzEwX3Jldl9bYmNdIHwgZmFtXzExX3Jldl9iYAo= --=separator-- From xen-devel-bounces@lists.xenproject.org Thu Jun 11 13:34:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 13:34:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjNL1-0001pB-Un; Thu, 11 Jun 2020 13:33:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjNL1-0001p6-75 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 13:33:47 +0000 X-Inumbo-ID: 2cc04b06-abe8-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2cc04b06-abe8-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 13:33:46 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id l10so6167462wrr.10 for ; Thu, 11 Jun 2020 06:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=V4u0XW0sq3+1Rb7aA4YKUdRc9wue2mtPLEIIwicVyT4=; b=Oi3qpGCCxNG/Vn82vElw9RuzyJfYi9g9QX1oicQ8GyuhXRR7ha1Q95mNU2PFLJaP51 Whxd9DY04DbNbr24DbyeXFoZVPRJGGgvImX6u1E3KzcKGoa+mr24y3TDUq5efD2RyyDI yvXPJDPAJcChKfemXr50tMVXfgxV7EI+qQFSwTcBma1Gor/joeSxQrxrDXv9IihQoq5e jeaIyKScnrkRDR9xKG9GVE07HKjImqsBauLqwdSxFpV3QrJ2xpzxb2lPC55PEsFCqdlB SGk3RdMMeEj1w2geq4bsUwwDD2lhBFX7Bz7otL7QWKP96VMbrVmZ9jk5kKcy2iR6hj5r r5+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=V4u0XW0sq3+1Rb7aA4YKUdRc9wue2mtPLEIIwicVyT4=; b=Vbn2MZEqBBZAQhUuoV3tbHPU4cFuSb4lSG2k838fL1xpYd+KiTUg+pKxIjENCeg11O zcr7kIw7hTGN1l9DBQ8UeYtaV0t0SasGH9RIptgKPd3El3WQPvBfW4JXiSni0zZl6YS3 q4DRzoA/0nN6LOfHTLZUviTc/G0Y3Mh1HX/4icj3lp8aWnGcayARWrV34b07/08y2sQd 0XQ5smXEHIHoAhBzUwOK5y3JE8F3qgj+v3mvFxX+EhZaXCk12MizIcM8UEr5J06RJe5z jJ/WeOECJjmbzRctCRGed3AmI6r/qDhwoivpRVkShsoPey2DGjlesKlbHrDUjVzng9VT LEng== X-Gm-Message-State: AOAM533GwOthy8F/YFNy+K7BHWCdAzMqXNc2a/EO3ArjsDZrWvLZQVmb KYAr3UUYfK3MJu89/22O4JE= X-Google-Smtp-Source: ABdhPJzb0+9WinKjDHVX4R9JUn2+3N0/77C5hH2WeLcJxGXErHJIQr/usA8diMmm38OjWa7j2FrlCA== X-Received: by 2002:adf:c6c5:: with SMTP id c5mr9188797wrh.13.1591882425568; Thu, 11 Jun 2020 06:33:45 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.177]) by smtp.gmail.com with ESMTPSA id z8sm4988629wru.33.2020.06.11.06.33.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 06:33:45 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Julien Grall'" , "'Julien Grall'" , =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= References: <20200609154546.4531-1-jgross@suse.com> <4a3c4e5e-1fbd-5017-1e3e-64052ae2410a@xen.org> <1da8a9bd-b77a-86c0-5b6a-638ea94b2cbc@xen.org> In-Reply-To: <1da8a9bd-b77a-86c0-5b6a-638ea94b2cbc@xen.org> Subject: RE: [PATCH for-4.14] xen/hypfs: fix loglvl parameter setting Date: Thu, 11 Jun 2020 14:33:43 +0100 Message-ID: <00ec01d63ff4$ede7f460$c9b7dd20$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHwbJlqkk7O35noToy96/KV5kSeeQKFTsPRAb1oUx0DSQa4gwGSMGxrqFYhDdA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Julien Grall > Sent: 11 June 2020 10:20 > To: Julien Grall ; J=C3=BCrgen Gro=C3=9F = ; Paul Durrant > > Cc: xen-devel ; Andrew Cooper = ; George > Dunlap ; Ian Jackson = ; Jan Beulich > ; Stefano Stabellini ; Wei = Liu > Subject: Re: [PATCH for-4.14] xen/hypfs: fix loglvl parameter setting >=20 >=20 >=20 > On 10/06/2020 22:47, Julien Grall wrote: > > On Wed, 10 Jun 2020 at 19:49, J=C3=BCrgen Gro=C3=9F = wrote: > >> > >> On 10.06.20 19:55, Julien Grall wrote: > >>> Hi Juergen, > >>> > >>> On 09/06/2020 16:45, Juergen Gross wrote: > >>>> Writing the runtime parameters loglvl or guest_loglvl omits = setting the > >>>> new length of the resulting parameter value. > >>>> > >>>> Reported-by: George Dunlap > >>>> Signed-off-by: Juergen Gross > >>> > >>> Reviewed-by: Julien Grall > >>> > >>> Although one unrelated comment below. > >>> > >>>> --- > >>>> xen/drivers/char/console.c | 19 +++++++++++++++---- > >>>> 1 file changed, 15 insertions(+), 4 deletions(-) > >>>> > >>>> diff --git a/xen/drivers/char/console.c = b/xen/drivers/char/console.c > >>>> index 56e24821b2..861ad53a8f 100644 > >>>> --- a/xen/drivers/char/console.c > >>>> +++ b/xen/drivers/char/console.c > >>>> @@ -241,14 +241,25 @@ static int _parse_loglvl(const char *s, int > >>>> *lower, int *upper, char *val) > >>>> static int parse_loglvl(const char *s) > >>>> { > >>>> - return _parse_loglvl(s, &xenlog_lower_thresh, = &xenlog_upper_thresh, > >>>> - xenlog_val); > >>>> + int ret; > >>>> + > >>>> + ret =3D _parse_loglvl(s, &xenlog_lower_thresh, = &xenlog_upper_thresh, > >>>> + xenlog_val); > >>>> + custom_runtime_set_var(param_2_parfs(parse_loglvl), = xenlog_val); > >>> > >>> Mixing function and variable name is pretty confusing. It took me > >>> sometimes to go through the macro maze to figure out what's = happening. > >>> > >>> It might be worth thinking to document more the custom_runtime_* = interface. > >> > >> I have already some streamlining ideas for 4.15. > > > > Cool! I will commit it tomorrow morning. >=20 > Actually I am missing a Released-acked-by from Paul on this patch. >=20 Release-acked-by: Paul Durrant > Cheers, >=20 > -- > Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 11 13:48:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 13:48:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjNZa-0002nX-7s; Thu, 11 Jun 2020 13:48:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjNZY-0002nR-MP for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 13:48:48 +0000 X-Inumbo-ID: 45b2e982-abea-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 45b2e982-abea-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 13:48:47 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id w16so5975216ejj.5 for ; Thu, 11 Jun 2020 06:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HsnFYtbzFzP/QoDBhCqgQNFkyNpcu1IJ8yezc2HzJrM=; b=JYi/oG/akEXJDuehVyYk+KdQGA/7lF7FXLEYVxgffmjNMUGHXMKwa9xd5hJQeEv/oj EF0QHTESTpGnZZ2DrqJeRnnSBUTe9MyDpuWOEEthjKl4B0KbJEOKHuGMRxOoPW7M9fRi bnkUu2AERA2SKYTYbaKYDy8Dh7UQq4m/RHrSc6wJYnY8AgnInAPIjh2Gkcd1gCKnI411 n0YHsGMQPER/YbExnr7zZwM7POqT7KClKDQV+c35SSJZyTY/QfOsNEw/jc1kORytzS5g JtNrGJadzY2ZaTARj4Tb5+WplMFFGPkPfn94MkYj8txbebCDWsIbvAicPxBIrkyd0moZ OLMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HsnFYtbzFzP/QoDBhCqgQNFkyNpcu1IJ8yezc2HzJrM=; b=SM7pqbMf2A5Q4fpIL6Ebmv1CWCZ2lMCCEdhdiO2663B6ixQvOecb6CUF2kqASRVpCP UHFKjMKR2xnL7woJMUO+VOCIlCBbYow/U+dU0k+HkcoQgu9V0uvyC/f5yp5BG/uUmv3r cHtF/UclWf71VofpfdqLYiyvcZQ/xI0nHi73SKGfkm3kVXkCpc9Wa5MgfCiv95fquKOv 47duXd0H4uJU6o/ny6LubI3FxuzdAu179YLwwqvnv4c8keaPySBXh8kul2UC6CjoRwc1 zhNdHtpYpMQE5e0vl4NKe5o39wobaLe6Qybi8VO60OOLpVAcKwg7nICjPyh4B8QtGkyv jsCg== X-Gm-Message-State: AOAM532v3g4UoF84eWkBAknCJ4ppNTTiJ3J5fnLrsH7we+IrqPTVfrQr 98GoiSAZAT3o5+XsjM1ZPquGm3QlmJm0P7Z2GII= X-Google-Smtp-Source: ABdhPJzGxJ70Aw8WdRrM3Da4wfXhE9wkU3d/nLwCc6rV0q1ru62dD/XpCJq8bRKvhrMS6cvJQhAEHY8zH44DkI9EYh0= X-Received: by 2002:a17:906:cd05:: with SMTP id oz5mr9015280ejb.335.1591883326500; Thu, 11 Jun 2020 06:48:46 -0700 (PDT) MIME-Version: 1.0 References: <20191126100801.124844-1-wipawel@amazon.de> In-Reply-To: <20191126100801.124844-1-wipawel@amazon.de> From: George Dunlap Date: Thu, 11 Jun 2020 14:48:35 +0100 Message-ID: Subject: Re: [Xen-devel] [PATCH v6 00/12] livepatch: new features and fixes To: Pawel Wieczorkiewicz Content-Type: multipart/alternative; boundary="00000000000033327705a7cf38b0" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , George Dunlap , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --00000000000033327705a7cf38b0 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 26, 2019 at 10:14 AM Pawel Wieczorkiewicz wrote: > This series introduces new features to the livepatch functionality as > briefly discussed during Xen Developer Summit 2019: [a] and [b]. > It also provides a few fixes and some small improvements. > > Main changes in v6: > - Added missing action pad field zeroing > > Main changes in v4: > - Fix various typos and minor issues > - Simplify arch_livepatch_{apply,revert} by using > common_livepatch_{apply,revert} > - Improve python bindings and fix few issues > > Main changes in v3: > - Fix expectation test to work on Arm > - Add test for metadata (Konrad) > - Minor fixes to documentation > > Main changes in v2: > - added new features to livepatch documentation > - added livepatch tests > - enabled Arm support for [5] > - make .modinfo optional for [11] > - fixed typos > > FEATURES: > > 1. independent modules (patches: [1], [2]) > > * livepatch-build-tools repo dependency [A] > > Livepatch enforces the following buildid-based dependency chain > between hotpatch modules: > 1) first module depends on given hypervisor buildid > 2) every consecutive module depends on previous module's buildid > This way proper hotpatch stack order is maintained and enforced. > While it is important for production hotpatches it limits agility and > blocks usage of testing or debug hotpatches. These kinds of hotpatch > modules are typically expected to be loaded at any time irrespective > of current state of the modules stack. > > [A] livepatch-build: Embed hypervisor build id into every hotpatch > > 2. pre- and post- apply|revert actions hooks (patches: [3], [4]) > > * livepatch-build-tools repo dependency [B] > > This is an implementation of 4 new livepatch module vetoing hooks, > that can be optionally supplied along with modules. > Hooks that currently exists in the livepatch mechanism aren't agile > enough and have various limitations: > * run only from within a quiescing zone > * cannot conditionally prevent applying or reverting > * do not have access to the module context > To address these limitations the following has been implemented: > 1) pre-apply hook > 2) post-apply hook > 3) pre-revert hook > 4) post-revert hook > > [B] create-diff-object: Handle extra pre-|post- hooks > > 3. apply|revert actions replacement hooks (patches: [5], [6], [7]) > > * livepatch-build-tools repo dependency: [C], [D], [E] > > To increase hotpatching system's agility and provide more flexiable > long-term hotpatch solution, allow to overwrite the default apply > and revert action functions with hook-like supplied alternatives. > The alternative functions are optional and the default functions are > used by default. > > [C] create-diff-object: Do not create empty .livepatch.funcs section > [D] create-diff-object: Handle optional apply|revert hooks > [E] create-diff-object: Add support for applied/reverted marker > > 4. inline asm hotpatching expectations (patches: [8]) > > * livepatch-build-tools repo dependency: [F] > > Expectations are designed as optional feature, since the main use of > them is planned for inline asm hotpatching. > The payload structure is modified as each expectation structure is > part of the livepatch_func structure and hence extends the payload. > The payload version is bumped to 3 with this change to highlight the > ABI modification and enforce proper support. > The expectation is manually enabled during inline asm module > construction. If enabled, expectation ensures that the expected > content of memory is to be found at a given patching (old_addr) > location. > > [F] create-diff-object: Add support for expectations > > 5. runtime hotpatch metadata support (patches: [9], [10], [11]) > > Having detailed hotpatch metadata helps to properly identify module's > origin and version. It also allows to keep track of the history of > hotpatch loads in the system (at least within dmesg buffer size > limits). > Extend the livepatch list operation to fetch also payloads' metadata. > This is achieved by extending the sysctl list interface with 2 extra > guest handles: > * metadata - an array of arbitrary size strings > * metadata_len - an array of metadata strings' lengths (uin32_t each) > To unify and simplify the interface, handle the modules' name strings > of arbitrary size by copying them in adhering chunks to the userland. > > 6. python bindings for livepatch operations (patches: [12]) > > Extend the XC python bindings library to support all common livepatch > operations and actions: > - status (pyxc_livepatch_status): > - action (pyxc_livepatch_action): > - upload (pyxc_livepatch_upload): > - list (pyxc_livepatch_list): > This series looks like it would be a good candidate for a CHANGELOG.md line. What about something like this: - Livepatch improvements: Buildid / hotpatch "stack" restrictions, Additional {pre,post}-{apply,revert} hooks, inline hotpatching expectations, runtime hotpatch metdata, python bindings for livepatch operations --00000000000033327705a7cf38b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 26, 2019 at 10:14 AM Pawe= l Wieczorkiewicz <wipawel@amazon.de= > wrote:
= This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes and some small improvements.

Main changes in v6:
- Added missing action pad field zeroing

Main changes in v4:
- Fix various typos and minor issues
- Simplify arch_livepatch_{apply,revert} by using
=C2=A0 common_livepatch_{apply,revert}
- Improve python bindings and fix few issues

Main changes in v3:
- Fix expectation test to work on Arm
- Add test for metadata (Konrad)
- Minor fixes to documentation

Main changes in v2:
- added new features to livepatch documentation
- added livepatch tests
- enabled Arm support for [5]
- make .modinfo optional for [11]
- fixed typos

FEATURES:

1. independent modules (patches: [1], [2])

=C2=A0 * livepatch-build-tools repo dependency [A]

=C2=A0 Livepatch enforces the following buildid-based dependency chain
=C2=A0 between hotpatch modules:
=C2=A0 =C2=A0 1) first module depends on given hypervisor buildid
=C2=A0 =C2=A0 2) every consecutive module depends on previous module's = buildid
=C2=A0 This way proper hotpatch stack order is maintained and enforced.
=C2=A0 While it is important for production hotpatches it limits agility an= d
=C2=A0 blocks usage of testing or debug hotpatches. These kinds of hotpatch=
=C2=A0 modules are typically expected to be loaded at any time irrespective=
=C2=A0 of current state of the modules stack.

=C2=A0 [A] livepatch-build: Embed hypervisor build id into every hotpatch
2. pre- and post- apply|revert actions hooks (patches: [3], [4])

=C2=A0 * livepatch-build-tools repo dependency [B]

=C2=A0 This is an implementation of 4 new livepatch module vetoing hooks, =C2=A0 that can be optionally supplied along with modules.
=C2=A0 Hooks that currently exists in the livepatch mechanism aren't ag= ile
=C2=A0 enough and have various limitations:
=C2=A0 * run only from within a quiescing zone
=C2=A0 * cannot conditionally prevent applying or reverting
=C2=A0 * do not have access to the module context
=C2=A0 To address these limitations the following has been implemented:
=C2=A0 1) pre-apply hook
=C2=A0 2) post-apply hook
=C2=A0 3) pre-revert hook
=C2=A0 4) post-revert hook

=C2=A0 [B] create-diff-object: Handle extra pre-|post- hooks

3. apply|revert actions replacement hooks (patches: [5], [6], [7])

=C2=A0 * livepatch-build-tools repo dependency: [C], [D], [E]

=C2=A0 To increase hotpatching system's agility and provide more flexia= ble
=C2=A0 long-term hotpatch solution, allow to overwrite the default apply =C2=A0 and revert action functions with hook-like supplied alternatives. =C2=A0 The alternative functions are optional and the default functions are=
=C2=A0 used by default.

=C2=A0 [C] create-diff-object: Do not create empty .livepatch.funcs section=
=C2=A0 [D] create-diff-object: Handle optional apply|revert hooks
=C2=A0 [E] create-diff-object: Add support for applied/reverted marker

4. inline asm hotpatching expectations (patches: [8])

=C2=A0 * livepatch-build-tools repo dependency: [F]

=C2=A0 Expectations are designed as optional feature, since the main use of=
=C2=A0 them is planned for inline asm hotpatching.
=C2=A0 The payload structure is modified as each expectation structure is =C2=A0 part of the livepatch_func structure and hence extends the payload.<= br> =C2=A0 The payload version is bumped to 3 with this change to highlight the=
=C2=A0 ABI modification and enforce proper support.
=C2=A0 The expectation is manually enabled during inline asm module
=C2=A0 construction. If enabled, expectation ensures that the expected
=C2=A0 content of memory is to be found at a given patching (old_addr)
=C2=A0 location.

=C2=A0 [F] create-diff-object: Add support for expectations

5. runtime hotpatch metadata support (patches: [9], [10], [11])

=C2=A0 Having detailed hotpatch metadata helps to properly identify module&= #39;s
=C2=A0 origin and version. It also allows to keep track of the history of =C2=A0 hotpatch loads in the system (at least within dmesg buffer size
=C2=A0 limits).
=C2=A0 Extend the livepatch list operation to fetch also payloads' meta= data.
=C2=A0 This is achieved by extending the sysctl list interface with 2 extra=
=C2=A0 guest handles:
=C2=A0 * metadata=C2=A0 =C2=A0 =C2=A0- an array of arbitrary size strings =C2=A0 * metadata_len - an array of metadata strings' lengths (uin32_t = each)
=C2=A0 To unify and simplify the interface, handle the modules' name st= rings
=C2=A0 of arbitrary size by copying them in adhering chunks to the userland= .

6. python bindings for livepatch operations (patches: [12])

=C2=A0 Extend the XC python bindings library to support all common livepatc= h
=C2=A0 operations and actions:
=C2=A0 - status (pyxc_livepatch_status):
=C2=A0 - action (pyxc_livepatch_action):
=C2=A0 - upload (pyxc_livepatch_upload):
=C2=A0 - list (pyxc_livepatch_list):

This series looks like it would be a good candidate for a CHANGELOG.md l= ine.

What about something like this:
- Livepatch improvements: Buildid / hotpatch "stack" restrictions,= =20 Additional {pre,post}-{apply,revert} hooks, inline hotpatching=20 expectations, runtime hotpatch metdata, python bindings for livepatch=20 operations

<= /div> --00000000000033327705a7cf38b0-- From xen-devel-bounces@lists.xenproject.org Thu Jun 11 14:36:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 14:36:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjOIw-0006tQ-0p; Thu, 11 Jun 2020 14:35:42 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjOGG-0006qG-7c for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 14:32:56 +0000 X-Inumbo-ID: 6f9390de-abf0-11ea-b53b-12813bfff9fa Received: from mx0a-001b2d01.pphosted.com (unknown [148.163.156.1]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6f9390de-abf0-11ea-b53b-12813bfff9fa; Thu, 11 Jun 2020 14:32:54 +0000 (UTC) Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05BE67Wv130396; Thu, 11 Jun 2020 10:32:52 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 31kp0y8xqm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jun 2020 10:32:52 -0400 Received: from m0098393.ppops.net (m0098393.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 05BE66eV130207; Thu, 11 Jun 2020 10:32:52 -0400 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 31kp0y8xpt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jun 2020 10:32:52 -0400 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 05BELHWV003046; Thu, 11 Jun 2020 14:32:50 GMT Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by ppma03dal.us.ibm.com with ESMTP id 31hw1c7gg0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jun 2020 14:32:50 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 05BEWoVu20971782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Jun 2020 14:32:50 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DDCA9112075; Thu, 11 Jun 2020 14:32:49 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA126112074; Thu, 11 Jun 2020 14:32:49 +0000 (GMT) Received: from sbct-3.pok.ibm.com (unknown [9.47.158.153]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 11 Jun 2020 14:32:49 +0000 (GMT) Subject: Re: Seabios Xen TPM check To: Jason Andryuk , seabios@seabios.org References: From: Stefan Berger Message-ID: Date: Thu, 11 Jun 2020 10:32:49 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-11_14:2020-06-11, 2020-06-11 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 adultscore=0 mlxscore=0 cotscore=-2147483648 lowpriorityscore=0 malwarescore=0 suspectscore=0 spamscore=0 impostorscore=0 priorityscore=1501 phishscore=0 mlxlogscore=999 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006110110 X-Mailman-Approved-At: Thu, 11 Jun 2020 14:35:41 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Quan Xu , Stefan Berger Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/11/20 8:36 AM, Jason Andryuk wrote: > Hi, > > SeaBIOS commit 67643955c746 (make SeaBios compatible with Xen vTPM.) > made tpm_start() exit before calling tpm_startup(). The commit > message has no explanation why this change was made. Does anyone > remember why it was made? > > The code today means SeaBIOS will not populate PCRs when running on > Xen. If I revert the patch, SeaBIOS populates PCRs as one would > expect. This is with a QEMU-emulated TPM backed by swtpm in TPM 1.2 > mode (qemu & swtpm running in a linux stubdom). > > Any insight is appreciated. My guess would be that for some reason the TPM 1.2 was already started up through other means and didn't need the SeaBIOS tpm_startup() to run. > > Thanks, > Jason From xen-devel-bounces@lists.xenproject.org Thu Jun 11 14:57:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 14:57:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjOdw-0000B4-NA; Thu, 11 Jun 2020 14:57:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjOdv-0000Az-Qq for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 14:57:24 +0000 X-Inumbo-ID: da0f706a-abf3-11ea-b7bb-bc764e2007e4 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [40.107.6.65]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id da0f706a-abf3-11ea-b7bb-bc764e2007e4; Thu, 11 Jun 2020 14:57:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o21j4grUq0CEt7eJMFmJH+mE6EuCug1cz5ERDZSRn9k=; b=wFOlqBRuBOSMSEkB68yVCR8kUdlws5gmrPLMHK3Mi59ziMhwE4n7SxlOVsQhE85So3J9/884WVMy7rnCOCw1WNYNiF6Ao+2ilQ6SZA8fqOyGGrVOOqpEkoLHCoz9WeDXrhaUbf1ix96qmYp10tihKdCtqwnf6VQwm72jIBVY8+s= Received: from AM6PR08CA0047.eurprd08.prod.outlook.com (2603:10a6:20b:c0::35) by AM0PR08MB3281.eurprd08.prod.outlook.com (2603:10a6:208:5f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Thu, 11 Jun 2020 14:57:19 +0000 Received: from AM5EUR03FT041.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:c0:cafe::84) by AM6PR08CA0047.outlook.office365.com (2603:10a6:20b:c0::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Thu, 11 Jun 2020 14:57:19 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT041.mail.protection.outlook.com (10.152.17.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 14:57:19 +0000 Received: ("Tessian outbound 8bb15bb571b3:v59"); Thu, 11 Jun 2020 14:57:19 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 4736139319df25ef X-CR-MTA-TID: 64aa7808 Received: from f2cfa4f47421.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id BA2A719C-2408-45DC-818B-B18181D31712.1; Thu, 11 Jun 2020 14:57:14 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f2cfa4f47421.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 11 Jun 2020 14:57:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=et+/+Iy5/c0pmw5FynFzcT8JDnrGYEAYHrqkyFd+kTG6ITB6Z/OqjYoRgovkwu3r+5g16dfCMtRjK7XkmaB50i83MrnFllcv6PSMbmeUU0tPASgC3zX2+B0QFrK0Qo2Oz+hT2b7y1giM7pZX6vhnaZL74MBrIMNdBHvVJkwlt0tIzwXGV2l7PEdwrcAliFezxK24yyu55iKd/84AzLOsPiqbzTFXLjuNFWV6J0OEopWvGxqqExJqsy4GodvNprnJQVRwpajLs3TDfic00nSF8kgElAeyWLeMGi8DXjtgjKZa7PyQHJFSiwmklVhkWOqNTyVjktmIMGW5B3Fhs9d+mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o21j4grUq0CEt7eJMFmJH+mE6EuCug1cz5ERDZSRn9k=; b=cNmlACgFSgPt+s+g1z14RTTq9RhCxTUeWfx+6131poL9XiN9dzj4PU0n8p6p6XLhtzsGaPCTtwbksERZ5S8eK90Skqb4QFtfkS5ogpRVTJw7DReCiVvrV0n7fzRQ49RP2pRrl1cJrX3926/BoLPOY8One1Nw3hbmy1SiiugirAhdpRsbQnUkF54RN7c5pI+FFdCsyt1uJN95RzhAO6UPBOUJbTKNg/BfsEdvGMOYfcCKqNf4MFdwe+EG2jwjrsBOq/eNZ5yWb8kt5fg9w/1epd2wtWSi6jn3WDwbjrWpL0LrnoV6/q+Fm2YQ/QR4iHrJI/hOKOpubD3WZwVkgPkVkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o21j4grUq0CEt7eJMFmJH+mE6EuCug1cz5ERDZSRn9k=; b=wFOlqBRuBOSMSEkB68yVCR8kUdlws5gmrPLMHK3Mi59ziMhwE4n7SxlOVsQhE85So3J9/884WVMy7rnCOCw1WNYNiF6Ao+2ilQ6SZA8fqOyGGrVOOqpEkoLHCoz9WeDXrhaUbf1ix96qmYp10tihKdCtqwnf6VQwm72jIBVY8+s= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3308.eurprd08.prod.outlook.com (2603:10a6:5:20::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Thu, 11 Jun 2020 14:57:13 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Thu, 11 Jun 2020 14:57:13 +0000 From: Bertrand Marquis To: Julien Grall Subject: Re: [PATCH] xen/arm: Add arm Neoverse N1 processor Thread-Topic: [PATCH] xen/arm: Add arm Neoverse N1 processor Thread-Index: AQHWP+cmqt4USPzdykyBGMvq9NIs/ajTY2eAgAAd9wA= Date: Thu, 11 Jun 2020 14:57:13 +0000 Message-ID: References: <5d99ae7a1432152e25d063c634e1e7292ab988aa.1591806668.git.bertrand.marquis@arm.com> <6f4cf5ec-8a7e-ca82-d305-d57a083af915@xen.org> In-Reply-To: <6f4cf5ec-8a7e-ca82-d305-d57a083af915@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 44a0f428-1b40-4f69-6e25-08d80e17bd4c x-ms-traffictypediagnostic: DB7PR08MB3308:|AM0PR08MB3281: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882; x-forefront-prvs: 0431F981D8 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: mElVo6FKM1PphUOxAFJVslhfrX4YvcUHbKVlH9y6npOJM6Phlv0lo3jGMpeBt1U5UGceIoD/+ey+zkDdQksi1NsxPvB/0dfey8iKuU3tRwlLm8xaozCHn4qRNqWaRM3CgYL85oNqMQNQsD1NcPfcJiGanddUGttXfEzUbM3RNJSiSOYZbTD3ot74ZTrupnTRqALFzwq6+PZy3PyvEB4eTT4UdBQBA3nMe26qjZAawT/IKqDcSTx/BGWVpXJ9Q5VFSOt6maA4RMApyDzQkBpzRe64beoTA08zX11SH8IrnxEqIR5INzOXgzHHzifAZBJVreNJKNVfn2CbPGNhwjAldQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(376002)(39860400002)(366004)(396003)(8676002)(2906002)(8936002)(5660300002)(4744005)(86362001)(71200400001)(36756003)(33656002)(2616005)(91956017)(6916009)(316002)(66476007)(4326008)(54906003)(64756008)(66556008)(66446008)(66946007)(186003)(478600001)(26005)(6512007)(53546011)(76116006)(6486002)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: liTQGoTccC3w0303FBl6zWjo+Lf5SCbrocfOKrscDR5HwsCJR/+jDXkSb7VkF67ZbaVbKxJ3MqEeReVlnzm0HDQed7eSC7URqRa8Y6nJMJdPEl778aiWWL/UPaGQqsKW+ucRpp0twjBw32S/myVa0eVfkc5QtEfVJ+u0yN2EpfuE8WqT8fgJsDRLK0cI7RmgNYYWSUnm0FaPGF+EbHs9tb0zOHaBOPlICriKmGiiy/EXHR+8rSlgr1bfraqUxi4KEjVsHgGLcYUa/Nl425Zxt/DqB9jv7guX2y22eJn2NAl6x3UkO/PtI4mi8YszSy7xS+/NYY72L5vbArocvxNi02rQz6zL0qPEosyLgX5td7KJYhJzbv36QJ9LF+B+BU9LzdJOBQkZmsJVyJ5H0uoDRQBStr9n6yK436rwCGlD5wv6CIKHOt12SJ/17tIqj/iaa8c7aGiaP8aXT4mIwZXX4iA8xkQjC6fu26XOvMHW/L9KSLJ/cX/EfVHftvLHYZj6 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3308 Original-Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT041.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(346002)(376002)(46966005)(82740400003)(54906003)(186003)(6862004)(36906005)(336012)(316002)(6486002)(4326008)(8936002)(107886003)(6512007)(478600001)(2906002)(2616005)(8676002)(356005)(82310400002)(26005)(81166007)(36756003)(47076004)(5660300002)(86362001)(53546011)(6506007)(70206006)(70586007)(33656002)(4744005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 40884ec9-ebf1-4da2-acd9-08d80e17b98f X-Forefront-PRVS: 0431F981D8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BG9LJL+Cl1aRy3tu0uTMSrcr/hzKtA2swsgHbm8aK/whqF9wWz0UySi3hOsMKtivbLdFk6+UTbil0YnQ4KWKtr2gJW7lmCMxcLzh9wOTH2bEl85M/GSvIxzLam0cZlcJsieuMdoVrkvuCQh6EjO4ENSBTBIaDQUaQjHliFXDjdh2Qr3p5P1PaVdSbNFsroL9vNbacl4ZKCNfWxxZPuGItFTOo/D6gQXHVnyQFBYjjX+SZHM2GkSkXlElY8uCgAa0Afc0Y3bzvUUH2yotrTNC8KOaXlsuFk55k/oIyCYdMgk/ivIgMaxcZNxcoTWDy7kIWHyItPNbrTKSH373a5ZFAlj6svK4i/Z/0uihl/NbHDwAR0ucYUQIHYpgCa6kY7MHu73UcTZKBqoKg/n41dZyww== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2020 14:57:19.5214 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 44a0f428-1b40-4f69-6e25-08d80e17bd4c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3281 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , nd , Volodymyr Babchuk , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On 11 Jun 2020, at 14:09, Julien Grall wrote: >=20 > Hi Bertrand, >=20 > On 11/06/2020 12:54, Bertrand Marquis wrote: >> Add MIDR and CPU part numbers for Arm Neoverse N1 processor >=20 > The MIDR and CPU part listed are only there because we need to use them f= or errata. This is not the list of processors we support :). >=20 > So I would prefer to introduce the new macro when there is an actual use = of it. Understood. Cheers Bertrand From xen-devel-bounces@lists.xenproject.org Thu Jun 11 14:57:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 14:57:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjOeG-0000Cp-4G; Thu, 11 Jun 2020 14:57:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjOeE-0000Cf-Ua for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 14:57:42 +0000 X-Inumbo-ID: e6df4784-abf3-11ea-b7bb-bc764e2007e4 Received: from smtp-fw-2101.amazon.com (unknown [72.21.196.25]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e6df4784-abf3-11ea-b7bb-bc764e2007e4; Thu, 11 Jun 2020 14:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1591887462; x=1623423462; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=rGHndJ5TnBycZlshvSY/khuChftuh2/1N3IgO4PWHFg=; b=WLvIc9OFPRZvsvvZDb0P5ep9xbdcxm5d4gVxvjxJyKtQe2DUKD+1DAVV pTQ5zqJygncTOykflDdm3yRyaSEO+WXkBixjPXltndMuMNOa6U1+I+QnY KtHcYyLxm/BkW9U6GDgG3AgQ/ueKEplhvKLGqjdlhAJaMJjHY5gCYOerf 4=; IronPort-SDR: GRmXaCttvJEdsG5nIvlyR1964aQbx3lr3upMB2EUSEUj7YyNGURpnaLsAJ8HjAMuuF88d5229f 4TIkVYexEiow== X-IronPort-AV: E=Sophos;i="5.73,499,1583193600"; d="scan'208";a="35758432" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-1e-c7c08562.us-east-1.amazon.com) ([10.43.8.2]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP; 11 Jun 2020 14:57:41 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-c7c08562.us-east-1.amazon.com (Postfix) with ESMTPS id E903224432A; Thu, 11 Jun 2020 14:57:39 +0000 (UTC) Received: from EX13D21UEA004.ant.amazon.com (10.43.61.209) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Jun 2020 14:57:39 +0000 Received: from EX13MTAUEA001.ant.amazon.com (10.43.61.82) by EX13D21UEA004.ant.amazon.com (10.43.61.209) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Jun 2020 14:57:39 +0000 Received: from a483e7b01a66.ant.amazon.com (10.1.213.18) by mail-relay.amazon.com (10.43.61.243) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 11 Jun 2020 14:57:38 +0000 To: "xen-devel@lists.xenproject.org" , "Anthony Perard" , "wl@xen.org" , From: Julien Grall Subject: Kexec and libxenctlr.so Message-ID: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> Date: Thu, 11 Jun 2020 15:57:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi all, kexec-tools has an option to load dynamically libxenctlr.so (not .so.4.x) (see [1]). Given that the library has never been considered stable, it is probably a disaster that is waiting to happen. Looking at the tree kexec is using the follow libxc functions: - xc_kexec_get_range() - xc_kexec_load() - xc_kexec_unload() - xc_kexec_status() - xc_kexec_exec() - xc_version() - xc_interface_open() - xc_interface_close() - xc_get_max_cpus() - xc_get_machine_memory_map() I think it is uncontroversial that we want a new stable library for all the xc_kexec_* functions (maybe libxenexec)? However I am not entirely sure where to put the others. I am thinking to introduce libxensysctl for xc_get_max_cpus() as it is a XEN_SYSCTL. We could possibly include xc_get_machine_memory_map() (despite it is a XENMEM_). For xc_version(), I am thinking to extend libxentoolcore to also include "stable xen API". Any opinion on the approach? Cheers, [1] https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=894bea9335f57b62cbded7b02ab7d58308b647d8 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 15:21:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 15:21:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjP0r-0002hD-W4; Thu, 11 Jun 2020 15:21:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjP0q-0002h8-Ma for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 15:21:04 +0000 X-Inumbo-ID: 293e9168-abf7-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 293e9168-abf7-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 15:21:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4E92AB0BA; Thu, 11 Jun 2020 15:21:05 +0000 (UTC) Subject: Re: Kexec and libxenctlr.so To: Julien Grall , "xen-devel@lists.xenproject.org" , Anthony Perard , "wl@xen.org" , daniel.kiper@oracle.com References: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <261293b1-f4c9-e41d-0c76-cd47fe5c0dc2@suse.com> Date: Thu, 11 Jun 2020 17:21:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 11.06.20 16:57, Julien Grall wrote: > Hi all, > > kexec-tools has an option to load dynamically libxenctlr.so (not > .so.4.x) (see [1]). > > Given that the library has never been considered stable, it is probably > a disaster that is waiting to happen. > > Looking at the tree kexec is using the follow libxc functions: >    - xc_kexec_get_range() >    - xc_kexec_load() >    - xc_kexec_unload() >    - xc_kexec_status() >    - xc_kexec_exec() >    - xc_version() >    - xc_interface_open() >    - xc_interface_close() >    - xc_get_max_cpus() >    - xc_get_machine_memory_map() > > I think it is uncontroversial that we want a new stable library for all > the xc_kexec_* functions (maybe libxenexec)? > > However I am not entirely sure where to put the others. > > I am thinking to introduce libxensysctl for xc_get_max_cpus() as it is a > XEN_SYSCTL. We could possibly include xc_get_machine_memory_map() > (despite it is a XENMEM_). > > For xc_version(), I am thinking to extend libxentoolcore to also include > "stable xen API". > > Any opinion on the approach? You could consider hypfs (at least for some of the functionality). xc_version() and xc_get_max_cpus() would be rather easy. xc_get_machine_memory_map() is using a stable hypercall used by the kernel, too. Juergen From xen-devel-bounces@lists.xenproject.org Thu Jun 11 15:25:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 15:25:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjP5Q-0002s2-Iy; Thu, 11 Jun 2020 15:25:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjP5P-0002rx-ES for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 15:25:47 +0000 X-Inumbo-ID: d28468c4-abf7-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d28468c4-abf7-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 15:25:47 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D528EAD78; Thu, 11 Jun 2020 15:25:49 +0000 (UTC) Subject: Re: [PATCH] tools/libxengnttab: correct size of allocated memory To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Ian Jackson References: <20200520083501.31704-1-jgross@suse.com> <24261.17303.413916.29534@mariner.uk.xensource.com> <20200520155621.GN54375@Air-de-Roger> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <05eac1e1-63a3-1d03-9f91-d0ffdcc44f23@suse.com> Date: Thu, 11 Jun 2020 17:25:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200520155621.GN54375@Air-de-Roger> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 20.05.20 17:56, Roger Pau Monné wrote: > On Wed, May 20, 2020 at 03:49:59PM +0100, Ian Jackson wrote: >> Juergen Gross writes ("[PATCH] tools/libxengnttab: correct size of allocated memory"): >>> The size of the memory allocated for the IOCTL_GNTDEV_MAP_GRANT_REF >>> ioctl() parameters is calculated wrong, which results in too much >>> memory allocated. >> >> Added Roger to CC. >> >> Firstly, >> >> Reviewed-by: Ian Jackson > > For the FreeBSD bits: > > Reviewed-by: Roger Pau Monné Any reason the patch didn't go in yet? Juergen From xen-devel-bounces@lists.xenproject.org Thu Jun 11 15:27:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 15:27:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjP7J-0002zW-VA; Thu, 11 Jun 2020 15:27:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjP7J-0002zR-1a for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 15:27:45 +0000 X-Inumbo-ID: 187d73fc-abf8-11ea-b542-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 187d73fc-abf8-11ea-b542-12813bfff9fa; Thu, 11 Jun 2020 15:27:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=v3o0fdGPjH5JumEICjeM0imsdOhAX0jac0IKcKYHn0k=; b=bU83A8XsYPRiUMsENfRBDRJX4H 0xMCFChUa/pKoXUausFNEX9SZwcj/SXE4EF8k3fC3csVkime3xkmvyJmRiIfUM4lUT+fryiJoAvsl wLBBlYO2iiHrin5Vk4Tpz69bdbF7+pvXBHdAvqAqHqBVWZ3853RLAOg7BLh8fRtvF4cU=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjP7F-00078C-Dc; Thu, 11 Jun 2020 15:27:41 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjP7F-0000Jf-62; Thu, 11 Jun 2020 15:27:41 +0000 Subject: Re: Kexec and libxenctlr.so To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Julien Grall , "xen-devel@lists.xenproject.org" , Anthony Perard , "wl@xen.org" , daniel.kiper@oracle.com References: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> <261293b1-f4c9-e41d-0c76-cd47fe5c0dc2@suse.com> From: Julien Grall Message-ID: <5602eebf-c149-17f7-37c9-b263ff290509@xen.org> Date: Thu, 11 Jun 2020 16:27:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <261293b1-f4c9-e41d-0c76-cd47fe5c0dc2@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 11/06/2020 16:21, Jürgen Groß wrote: > On 11.06.20 16:57, Julien Grall wrote: >> Hi all, >> >> kexec-tools has an option to load dynamically libxenctlr.so (not >> .so.4.x) (see [1]). >> >> Given that the library has never been considered stable, it is >> probably a disaster that is waiting to happen. >> >> Looking at the tree kexec is using the follow libxc functions: >>     - xc_kexec_get_range() >>     - xc_kexec_load() >>     - xc_kexec_unload() >>     - xc_kexec_status() >>     - xc_kexec_exec() >>     - xc_version() >>     - xc_interface_open() >>     - xc_interface_close() >>     - xc_get_max_cpus() >>     - xc_get_machine_memory_map() >> >> I think it is uncontroversial that we want a new stable library for >> all the xc_kexec_* functions (maybe libxenexec)? >> >> However I am not entirely sure where to put the others. >> >> I am thinking to introduce libxensysctl for xc_get_max_cpus() as it is >> a XEN_SYSCTL. We could possibly include xc_get_machine_memory_map() >> (despite it is a XENMEM_). >> >> For xc_version(), I am thinking to extend libxentoolcore to also >> include "stable xen API". >> >> Any opinion on the approach? > > You could consider hypfs (at least for some of the functionality). That would work! > > xc_version() and xc_get_max_cpus() would be rather easy. I am guessing we will need a fallback to the normal hypercalls if hypfs is not present. > xc_get_machine_memory_map() is using a stable hypercall used by > the kernel, too. IIUC, you are suggesting to put this one in hypfs library as well. Is that correct? Thank you for the input! Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 11 15:36:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 15:36:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjPFH-0003wc-2j; Thu, 11 Jun 2020 15:35:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjPFF-0003wX-Bq for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 15:35:57 +0000 X-Inumbo-ID: 3de50618-abf9-11ea-b543-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3de50618-abf9-11ea-b543-12813bfff9fa; Thu, 11 Jun 2020 15:35:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 1C2AAADE8; Thu, 11 Jun 2020 15:35:59 +0000 (UTC) Subject: Re: Kexec and libxenctlr.so To: Julien Grall , Julien Grall , "xen-devel@lists.xenproject.org" , Anthony Perard , "wl@xen.org" , daniel.kiper@oracle.com References: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> <261293b1-f4c9-e41d-0c76-cd47fe5c0dc2@suse.com> <5602eebf-c149-17f7-37c9-b263ff290509@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Thu, 11 Jun 2020 17:35:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <5602eebf-c149-17f7-37c9-b263ff290509@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 11.06.20 17:27, Julien Grall wrote: > Hi, > > On 11/06/2020 16:21, Jürgen Groß wrote: >> On 11.06.20 16:57, Julien Grall wrote: >>> Hi all, >>> >>> kexec-tools has an option to load dynamically libxenctlr.so (not >>> .so.4.x) (see [1]). >>> >>> Given that the library has never been considered stable, it is >>> probably a disaster that is waiting to happen. >>> >>> Looking at the tree kexec is using the follow libxc functions: >>>     - xc_kexec_get_range() >>>     - xc_kexec_load() >>>     - xc_kexec_unload() >>>     - xc_kexec_status() >>>     - xc_kexec_exec() >>>     - xc_version() >>>     - xc_interface_open() >>>     - xc_interface_close() >>>     - xc_get_max_cpus() >>>     - xc_get_machine_memory_map() >>> >>> I think it is uncontroversial that we want a new stable library for >>> all the xc_kexec_* functions (maybe libxenexec)? >>> >>> However I am not entirely sure where to put the others. >>> >>> I am thinking to introduce libxensysctl for xc_get_max_cpus() as it >>> is a XEN_SYSCTL. We could possibly include >>> xc_get_machine_memory_map() (despite it is a XENMEM_). >>> >>> For xc_version(), I am thinking to extend libxentoolcore to also >>> include "stable xen API". >>> >>> Any opinion on the approach? >> >> You could consider hypfs (at least for some of the functionality). > > That would work! > >> >> xc_version() and xc_get_max_cpus() would be rather easy. > > I am guessing we will need a fallback to the normal hypercalls if hypfs > is not present. Or we don't support kexec-tools running on a system without hypfs (or the related functions would return an error on those systems). > >> xc_get_machine_memory_map() is using a stable hypercall used by >> the kernel, too. > > IIUC, you are suggesting to put this one in hypfs library as well. Is > that correct? Not really. I wanted to point out that this call would be a good candidate for another stable library, maybe part of libxenexec? In theory the memory map could be dumped via a hypfs node, either as a string (not nice for working with it) or as binary blob, of course. Juergen From xen-devel-bounces@lists.xenproject.org Thu Jun 11 16:00:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 16:00:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjPdA-0006uU-3P; Thu, 11 Jun 2020 16:00:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjPd8-0006uP-6q for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 16:00:38 +0000 X-Inumbo-ID: b0bdee9a-abfc-11ea-b546-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b0bdee9a-abfc-11ea-b546-12813bfff9fa; Thu, 11 Jun 2020 16:00:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Qgt/OlqG3i6mOaCMtJT58zik+YXK2HMOThtAuwaUZp4=; b=XVsMsV/nzsh/SIE88qdWNc92jc iuQZ1JE7mhFgjjlEgaQMTLQ6iyl3ojJsTnbX5XrSOOzZzZmjcXC5luyL6iI5nevO8iRQWsNbDweAn TsXu8WuGfBBAj9jkvt6MxoHXxklr0OlpRfwZ3FS/4Ml++k6JOM/9wbRo3l7h7phaqCpw=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjPd4-0008Hp-RH; Thu, 11 Jun 2020 16:00:34 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjPd4-0002oU-K7; Thu, 11 Jun 2020 16:00:34 +0000 Subject: Re: Kexec and libxenctlr.so To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Julien Grall , "xen-devel@lists.xenproject.org" , Anthony Perard , "wl@xen.org" , daniel.kiper@oracle.com References: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> <261293b1-f4c9-e41d-0c76-cd47fe5c0dc2@suse.com> <5602eebf-c149-17f7-37c9-b263ff290509@xen.org> From: Julien Grall Message-ID: <6fa3067c-2c71-bb8e-eab8-30f44782d002@xen.org> Date: Thu, 11 Jun 2020 17:00:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 11/06/2020 16:35, Jürgen Groß wrote: > On 11.06.20 17:27, Julien Grall wrote: >> Hi, >> >> On 11/06/2020 16:21, Jürgen Groß wrote: >>> On 11.06.20 16:57, Julien Grall wrote: >>>> Hi all, >>>> >>>> kexec-tools has an option to load dynamically libxenctlr.so (not >>>> .so.4.x) (see [1]). >>>> >>>> Given that the library has never been considered stable, it is >>>> probably a disaster that is waiting to happen. >>>> >>>> Looking at the tree kexec is using the follow libxc functions: >>>>     - xc_kexec_get_range() >>>>     - xc_kexec_load() >>>>     - xc_kexec_unload() >>>>     - xc_kexec_status() >>>>     - xc_kexec_exec() >>>>     - xc_version() >>>>     - xc_interface_open() >>>>     - xc_interface_close() >>>>     - xc_get_max_cpus() >>>>     - xc_get_machine_memory_map() >>>> >>>> I think it is uncontroversial that we want a new stable library for >>>> all the xc_kexec_* functions (maybe libxenexec)? >>>> >>>> However I am not entirely sure where to put the others. >>>> >>>> I am thinking to introduce libxensysctl for xc_get_max_cpus() as it >>>> is a XEN_SYSCTL. We could possibly include >>>> xc_get_machine_memory_map() (despite it is a XENMEM_). >>>> >>>> For xc_version(), I am thinking to extend libxentoolcore to also >>>> include "stable xen API". >>>> >>>> Any opinion on the approach? >>> >>> You could consider hypfs (at least for some of the functionality). >> >> That would work! >> >>> >>> xc_version() and xc_get_max_cpus() would be rather easy. >> >> I am guessing we will need a fallback to the normal hypercalls if >> hypfs is not present. > > Or we don't support kexec-tools running on a system without hypfs > (or the related functions would return an error on those systems). AFAICT, hypfs allows you to modify runtime parameters which is not required for kexec. Such feature could be undesirable in some setup and therefore I don't think this is acceptable to impose that for kexec. > >> >>> xc_get_machine_memory_map() is using a stable hypercall used by >>> the kernel, too. >> >> IIUC, you are suggesting to put this one in hypfs library as well. Is >> that correct? > > Not really. I wanted to point out that this call would be a good > candidate for another stable library, maybe part of libxenexec? > > In theory the memory map could be dumped via a hypfs node, either > as a string (not nice for working with it) or as binary blob, of > course. > > > Juergen -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 11 16:02:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 16:02:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjPfM-00070O-HG; Thu, 11 Jun 2020 16:02:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjPfK-00070F-H5 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 16:02:54 +0000 X-Inumbo-ID: 01aea7d6-abfd-11ea-8496-bc764e2007e4 Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 01aea7d6-abfd-11ea-8496-bc764e2007e4; Thu, 11 Jun 2020 16:02:53 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id e12so4317445eds.2 for ; Thu, 11 Jun 2020 09:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=fieSuTKybFsX234xt5yqCEbzbTy1MXTi84Hn9pJEors=; b=Uiuf3tZN4skgKQB1nX/HFdSPYYIFdFv6wD7IrueQt2ZTqHWEk6lis7HWv55IMX4tui kXYNIjUGfwwQ42xCMwRGjDEa7ZnuKsGZPuVfVl2Pp6Cdxr37ko7f5opuT3HG9iYRjtgJ TatyXIMDvW/9qNhmu+nnrL2HbsQWGw5YZm8PLXLjr/wtc+8ATpZrJuT9JWuWYzXPIjZg l6qwtzl/5/WInHYeNbSEZEQGjI5uJWgKauty0IZ6iSBOa0g3EtqHOu9Rczr/0/f1Co1R hVVRHaVGzg1DwRXGj55qfn2+YZu2EJWVpQuiX/DMoT4d+SN8ycPbS9FD3fz0iAAAKcYP lwTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=fieSuTKybFsX234xt5yqCEbzbTy1MXTi84Hn9pJEors=; b=rrsj1RN7uBEzBjAQhcj3LzqChKpKAcl2L621uUBdgwNK+HNnMRLKKx1Wm48fiwGGTe s4ewjatbRDDk0GJCrZT6Ho+DNdR22CECv8wQ8Bl56iLm+lPnuGxedaDd/IUL1PxCJeHM vPiX7JYEpVOgA8yKeRad0ZHNjpR9q5IECCtrhOROuc7gdepMyu/YmzKaEbLiJT4eo44B d+qUBEg6anfRUjgXn5HoG/RDWovY/nqb3tdTphy6DTnuMVgY5A3sI6Ph0C9YcUd6tN0o hYIfJ8crcbIdQUYdKffihFpoZJu4d2MNqN2s+ZFoT00+FLOBjqDuDeC4hHWvduMRe1Ha q/qw== X-Gm-Message-State: AOAM532bvfqXWr822feSqibVF0/0v/NwNqlFvEIhVbYRM9IqXA1c3Itx RBBKVUjtuG/lTzwgxTdnSgdBRCSu2as= X-Google-Smtp-Source: ABdhPJx+9edIOgqhkS/lV90/2BfA6PZasUQjZkl/M17rcSXIHLOplT7XtZgfcxF4+eSmG3GvAxPbXg== X-Received: by 2002:aa7:da42:: with SMTP id w2mr7438090eds.176.1591891372778; Thu, 11 Jun 2020 09:02:52 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.177]) by smtp.gmail.com with ESMTPSA id r6sm1745935edq.44.2020.06.11.09.02.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 09:02:52 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= , "'Ian Jackson'" References: <20200520083501.31704-1-jgross@suse.com> <24261.17303.413916.29534@mariner.uk.xensource.com> <20200520155621.GN54375@Air-de-Roger> <05eac1e1-63a3-1d03-9f91-d0ffdcc44f23@suse.com> In-Reply-To: <05eac1e1-63a3-1d03-9f91-d0ffdcc44f23@suse.com> Subject: RE: [PATCH] tools/libxengnttab: correct size of allocated memory Date: Thu, 11 Jun 2020 17:02:50 +0100 Message-ID: <00f701d64009$c2c10000$48430000$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIVhxV/SuXpRtXvUPa7QsiXjxPi4QIA6nlWAgDMDjIBt3lgyKgnO6jA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = J=C3=BCrgen Gro=C3=9F > Sent: 11 June 2020 16:26 > To: Roger Pau Monn=C3=A9 ; Ian Jackson = > Cc: xen-devel@lists.xenproject.org; Wei Liu > Subject: Re: [PATCH] tools/libxengnttab: correct size of allocated = memory >=20 > On 20.05.20 17:56, Roger Pau Monn=C3=A9 wrote: > > On Wed, May 20, 2020 at 03:49:59PM +0100, Ian Jackson wrote: > >> Juergen Gross writes ("[PATCH] tools/libxengnttab: correct size of = allocated memory"): > >>> The size of the memory allocated for the = IOCTL_GNTDEV_MAP_GRANT_REF > >>> ioctl() parameters is calculated wrong, which results in too much > >>> memory allocated. > >> > >> Added Roger to CC. > >> > >> Firstly, > >> > >> Reviewed-by: Ian Jackson > > > > For the FreeBSD bits: > > > > Reviewed-by: Roger Pau Monn=C3=A9 >=20 > Any reason the patch didn't go in yet? >=20 I'd be quite happy for this to go in now, consider it Release-acked-by: Paul Durrant >=20 > Juergen From xen-devel-bounces@lists.xenproject.org Thu Jun 11 16:24:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 16:24:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQ0V-0000KL-AI; Thu, 11 Jun 2020 16:24:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQ0U-0000KG-Lz for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 16:24:46 +0000 X-Inumbo-ID: 0f700ae2-ac00-11ea-b547-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0f700ae2-ac00-11ea-b547-12813bfff9fa; Thu, 11 Jun 2020 16:24:45 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: tovZV+l39RiBDrBJJGwxu3BCEAirlTXlvnO4jTfDXJ9Qy+ln2QMsm74hjZ6sNd9yR3jlpJMQBO pJsMH9jMauN0kxNZp9eQhiWtAeqLxdwnX3uC9NudbPklAtW18ZS3xTr4FYD6Nu5Mc7oWwuIBGK jLHnrVN8jcIjt0/pVZR0c1XYAB/VPSG0Eka5E1HttgDvnVTdIXJq+KB1ZyF/GFe7fpSZxpYb+D odKapN6xmU9acSKDSXbMGJeUhRLzn2ROjZaZkFl4fPQH0MFYnHAujKvJfhcFETfp2dCB6/Epge inU= X-SBRS: 2.7 X-MesageID: 19824800 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,499,1583211600"; d="scan'208";a="19824800" Subject: Re: [PATCH] x86/boot: use BASEDIR for include path To: Bertrand Marquis , References: From: Andrew Cooper Message-ID: <5cf46b52-6a57-3e11-67a0-28f841865c1e@citrix.com> Date: Thu, 11 Jun 2020 17:24:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: nd@arm.com, Wei Liu , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 11/06/2020 12:54, Bertrand Marquis wrote: > Use $(BASEDIR)/include instead of $(XEN_ROOT)/xen/include for the > include path to be coherent with the rest of the Makefiles. > > Signed-off-by: Bertrand Marquis Does something subtle break before this change? ~Andrew > --- > xen/arch/x86/boot/build32.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk > index 5851ebff5f..8cd5403926 100644 > --- a/xen/arch/x86/boot/build32.mk > +++ b/xen/arch/x86/boot/build32.mk > @@ -5,7 +5,7 @@ include $(XEN_ROOT)/Config.mk > $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) > > CFLAGS += -Werror -fno-builtin -g0 -msoft-float > -CFLAGS += -I$(XEN_ROOT)/xen/include > +CFLAGS += -I$(BASEDIR)/include > CFLAGS := $(filter-out -flto,$(CFLAGS)) > > # NB. awk invocation is a portable alternative to 'head -n -1' From xen-devel-bounces@lists.xenproject.org Thu Jun 11 16:26:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 16:26:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQ1u-0000P8-Lb; Thu, 11 Jun 2020 16:26:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQ1t-0000P2-Si for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 16:26:13 +0000 X-Inumbo-ID: 43c8faf6-ac00-11ea-b547-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 43c8faf6-ac00-11ea-b547-12813bfff9fa; Thu, 11 Jun 2020 16:26:13 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: PfrY6UUWB2zpZ7pWpiIXITDAEtG5X0DCX++wVZwHhfRIphXv8tqKbSQ0y07jiHpgLp4qNdHGFY BY4bBzm4iKOlZ7VjmTxdxL5Wvmc1w6415atAMYoam+Vkx00u0rY2QdiRgds/i+Ek94Evq/KL4G BxShepJnsI1rZrskZq29KdnIAh81fOdIpJj1rreRvjPeQhv4mQRe4VPZBrWFXHwvTr7Ob71T9N hMaCF+jo6Nvfac9hAuLcodTNttB1gg73yykcnrZDOZPJ1qQ7Uxi7J2hZIyvcJqOWTxk8+bNw9Q 1ts= X-SBRS: 2.7 X-MesageID: 20156416 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,499,1583211600"; d="scan'208";a="20156416" Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask To: Roger Pau Monne , References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> From: Andrew Cooper Message-ID: <6de3a582-d9a8-60b5-9525-c9223932e4ed@citrix.com> Date: Thu, 11 Jun 2020 17:26:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200610142923.9074-3-roger.pau@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10/06/2020 15:29, Roger Pau Monne wrote: > There's no need to setup a timer for GSIs that are edge triggered, > since those don't require any EIO or unmask, and hence couldn't block > other interrupts. > > Note this is only used by PVH dom0, that can setup the passthrough of > edge triggered interrupts from the vIO-APIC. One example of such kind > of interrupt that can be used by a PVH dom0 would be the RTC timer. > > While there introduce an out label to do the unlock and reduce code > duplication. > > Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper From xen-devel-bounces@lists.xenproject.org Thu Jun 11 16:51:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 16:51:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQQ1-0002pM-Jx; Thu, 11 Jun 2020 16:51:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQQ0-0002pH-LG for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 16:51:08 +0000 X-Inumbo-ID: be5cf595-ac03-11ea-b54b-12813bfff9fa Received: from EUR01-VE1-obe.outbound.protection.outlook.com (unknown [40.107.14.51]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id be5cf595-ac03-11ea-b54b-12813bfff9fa; Thu, 11 Jun 2020 16:51:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=az1n7mvnDXCinM24Yx3x0/8T7adMMETwnUXKvJX82MM=; b=iOf5o/CiSnL7g3dnWCd6ekxDKeOBJZQ9w26eKfOp6BfZi8+5Zfy6KvfcHmoKsSYVjK9yw70LkWKPkIYycSAAtf3YE0o4h5f9msECout8caQoEeWp4ikBXBvPy/8NDGGzPTjE5//QlsQn1Jp7sohVR/n4oU7iecAsvZbdM+gla0Q= Received: from AM6P195CA0041.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::18) by AM5PR0801MB1714.eurprd08.prod.outlook.com (2603:10a6:203:3a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Thu, 11 Jun 2020 16:51:04 +0000 Received: from VE1EUR03FT061.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::e) by AM6P195CA0041.outlook.office365.com (2603:10a6:209:87::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 16:51:04 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT061.mail.protection.outlook.com (10.152.19.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Thu, 11 Jun 2020 16:51:04 +0000 Received: ("Tessian outbound 39cdd740f5cb:v59"); Thu, 11 Jun 2020 16:51:03 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 2122cdd2f3920ca3 X-CR-MTA-TID: 64aa7808 Received: from b07708474948.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 07BE943F-F829-4F1B-9E94-39857731CCEC.1; Thu, 11 Jun 2020 16:50:58 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b07708474948.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 11 Jun 2020 16:50:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oe5eY4DO9y7hqa7SkkVX2M4mC0qYQ+LbeL9XphH9Rly3Rha2rc3Z2POP8Rz2/Ei1sT1xpber5y/PAI8g+p574NavEen46iYLZDW3fejcFgOThokOVGmZjiybSbahmxoBrDWP3SyXrq86CVkzt80UHwbZ23XNRIDsP53ZOE3EDfplznGhTs+0fesd9CeommKyR2U5BxDZ9SkkpZYRMMsYfu1a0LXH5nPGFGR0I1OEbQa7D8D+v4yNPeLCWdxdUuVYmLYtNRobMjnal5NQhSfl46ZrhSajaBOzzmZkMumGQSd2f4TxJ0MokcJ9yFQD6hljsd1l7+Gr5Qx1uFYcMfXd/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=az1n7mvnDXCinM24Yx3x0/8T7adMMETwnUXKvJX82MM=; b=fCzLYMyPpo7xKX0Aawca+N15ywBiIKeYsrQtghCY7FDw0buPKfmRdiwbMv4bT+xyXzWLyIE9P8yv8uMg/O884b2aH5hYfvMQQY+hA0Sv9QrrU+zmPeMhfXZJ/ff8EhaoDBISFMPvgS/+GqWpICIsB3Hv3q3qg62kV8SadgkSWUeydTD5UXVGUqYlOZY4WcPQ18ecFXY07eumCErHKgnMJHP8K209S3jeuCTADCSFHhiY/zmEWVQ3TUH9qfaFsfTicRvjsjETobPcEo+cms3gN2S575Mg8ZWYpwtH+Xpn0pRj56CAp7nNm2nop7pDu37vASLoR/CoEDSmVKnKj68MdA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=az1n7mvnDXCinM24Yx3x0/8T7adMMETwnUXKvJX82MM=; b=iOf5o/CiSnL7g3dnWCd6ekxDKeOBJZQ9w26eKfOp6BfZi8+5Zfy6KvfcHmoKsSYVjK9yw70LkWKPkIYycSAAtf3YE0o4h5f9msECout8caQoEeWp4ikBXBvPy/8NDGGzPTjE5//QlsQn1Jp7sohVR/n4oU7iecAsvZbdM+gla0Q= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB4586.eurprd08.prod.outlook.com (2603:10a6:10:34::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Thu, 11 Jun 2020 16:50:56 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Thu, 11 Jun 2020 16:50:56 +0000 From: Bertrand Marquis To: Andrew Cooper Subject: Re: [PATCH] x86/boot: use BASEDIR for include path Thread-Topic: [PATCH] x86/boot: use BASEDIR for include path Thread-Index: AQHWP+cTsx4T9bxcEUCqkorIalLVuajTmc4AgAAHVoA= Date: Thu, 11 Jun 2020 16:50:56 +0000 Message-ID: <7DA75B75-725F-40CC-9DDE-5727452309A0@arm.com> References: <5cf46b52-6a57-3e11-67a0-28f841865c1e@citrix.com> In-Reply-To: <5cf46b52-6a57-3e11-67a0-28f841865c1e@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: c4cb0ff4-783a-49ae-c692-08d80e27a134 x-ms-traffictypediagnostic: DB7PR08MB4586:|AM5PR0801MB1714: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0431F981D8 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: OJXV2un/kFD3RMyOo9H7WaIk68IrLSKnllvcPQCPBQgUgHDOAp0v3Gz0UNz0q1nYVS9nH85rjLsOjxK2ao/1D0/2tL9Zmys4GOErm0SUXESZ/wpyAtWCmlFRTEVb7SEQpqbyFrnT8+3gZ5l+k9b5a+t2w2H+2L8f6YpO+9xXa48gBbRbmyT+BkgomsW08HZSc1DMBzz+gfeacLKbVpCSPYPgqjpxXQe1LrJnbUt5BU68J3nWjC+VJM/TTqvtMqg4XLvfyLxHFd71Do4dNRgJNNGOIGkzJAPAjXpmPoW5kr4784DGuSzcD8M2Pj8X2WQxv0HFBLmmTs2lYvIzYn74fA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(39860400002)(346002)(396003)(136003)(54906003)(6506007)(6916009)(86362001)(66446008)(66946007)(76116006)(66476007)(2616005)(26005)(186003)(91956017)(66556008)(71200400001)(53546011)(64756008)(33656002)(478600001)(8936002)(6512007)(4326008)(83380400001)(316002)(36756003)(2906002)(6486002)(8676002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: I5feY7RpKFu6GQ+Lv3cmjqjpbtWKmTkljlDNJVptSYZvNlaJ0ejOAhZfsYf7uCVosduFKRQrzC9luLAJdKFknfe3pLs+ZLJAAE7mdDpkkJJx+2A6GjhiTd8QZjxCau/wxHCkkYnQf3sJ2QUK9eKoiBvYvOY81NCMqs8ieesKMtyyIM0Bxd26Ccb4Et+tUJs3X9Kfh328/oJU6OLEzK9w9STjRioxt691LoP773xrZTWeZ6BPq+iO0wdNV38bU/3pneQumqddV36mUosHE3qxvLPfGqkm2/YIOadiO2UZGylVtWbAwoelKecJ/GrJRytKdpYMU+Th574556MIscmguXSBdeyqkV2Yl215lkJV6zg9eB9F/caGwrzwE60SZz04TfcmVlT+gOEvwqJGjMhdxf1Ibptz76vFjBI8P4c1O+5vq687hSkjsguH/188k1LD3Tf87IxjEutw3ucoKGxmSKmZ1Tyo7wF1y0G55YV/iI66IF2ELMwol6ss+rLSl8Nt x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB4586 Original-Authentication-Results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT061.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(136003)(396003)(346002)(46966005)(356005)(2616005)(86362001)(82310400002)(81166007)(6512007)(83380400001)(8936002)(4326008)(336012)(6486002)(26005)(478600001)(33656002)(82740400003)(186003)(36906005)(36756003)(107886003)(316002)(70586007)(70206006)(8676002)(47076004)(6862004)(6506007)(53546011)(2906002)(5660300002)(54906003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 6496b91c-467d-4a72-79a7-08d80e279cad X-Forefront-PRVS: 0431F981D8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3X115Ox7aUTem2j9kZJKUVRBGtUI0VzdXtAR0X3V39kPpmQO1OsoBz06cPWDxNLCbIBcpODFUr0VDPrzEWwlpE9JFiVwJfX0dM1vBvho06IvsREBcg2ABN30D9sze5PdN66QfHSmfWe8oor7sBpmF8ucGREKl3qzMdA9JGosmWn9Jvt9EspQZYMRpRrWaKIcvZ4kYLloFjU1L31HBHgKRiuBH3HyoV4b/1jhEcJdnb28chp1teyTeHhXl9RMuS1i9fPJ/Rz4M8WNNBIDgsL04kPJYn8FP96gvGz8UMG8BwrKv5TanOsJuYMBK1mUBwwtb785OJRLdHYFEJZDHQiIlf5uVgZXux+lq6zJrAoCtcCzavLPRy0kcizXZkvyZQEoJwSi7XX1RrjtocVkuMgSyA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2020 16:51:04.2919 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c4cb0ff4-783a-49ae-c692-08d80e27a134 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1714 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Wei Liu , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Andrew, > On 11 Jun 2020, at 17:24, Andrew Cooper wrote= : >=20 > On 11/06/2020 12:54, Bertrand Marquis wrote: >> Use $(BASEDIR)/include instead of $(XEN_ROOT)/xen/include for the >> include path to be coherent with the rest of the Makefiles. >>=20 >> Signed-off-by: Bertrand Marquis >=20 > Does something subtle break before this change? Without changing anything no. But if xen sub-directory is renamed yes. As there is no easy way to build xen hypervisor out of tree (I might be wro= ng here !) I found a solution using cp -rs from xen subdir in a xen-build1 = xen-build2 etc this way I can check build for x86 and arm without cleaning. Without the patch, the sources are actually compiles with an include path c= ontaining xen/../xen as a result of using XEN_ROOT which does not allow to = rename xen subdirectory. As it was the only place in which XEN_ROOT was used for include paths, this= is normalising the paths. Bertrand >=20 > ~Andrew >=20 >> --- >> xen/arch/x86/boot/build32.mk | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >>=20 >> diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk >> index 5851ebff5f..8cd5403926 100644 >> --- a/xen/arch/x86/boot/build32.mk >> +++ b/xen/arch/x86/boot/build32.mk >> @@ -5,7 +5,7 @@ include $(XEN_ROOT)/Config.mk >> $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) >>=20 >> CFLAGS +=3D -Werror -fno-builtin -g0 -msoft-float >> -CFLAGS +=3D -I$(XEN_ROOT)/xen/include >> +CFLAGS +=3D -I$(BASEDIR)/include >> CFLAGS :=3D $(filter-out -flto,$(CFLAGS))=20 >>=20 >> # NB. awk invocation is a portable alternative to 'head -n -1' >=20 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 17:12:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 17:12:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQk7-0004Zi-AR; Thu, 11 Jun 2020 17:11:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQk5-0004Zd-Kv for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 17:11:53 +0000 X-Inumbo-ID: a4e279ec-ac06-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x32b.google.com (unknown [2a00:1450:4864:20::32b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a4e279ec-ac06-11ea-b7bb-bc764e2007e4; Thu, 11 Jun 2020 17:11:52 +0000 (UTC) Received: by mail-wm1-x32b.google.com with SMTP id y20so5773958wmi.2 for ; Thu, 11 Jun 2020 10:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=l+S8SsSfyLQKzrOFZh3L67P54q5wd2LgM9TcQbt4WrI=; b=D5DhT082LXak95d2gNck/lMXd515iInIDpgR6QTetwgXPc3l559U3ytQHKxzgWqJYD MgLeWQxBrurf9vL9lJW0v16CG6ziZ/4+JJekTsnDGMcI4QJINNRrr5V5UfmFQ/4gd64t AMTuBgcioXInjscZVkgFG34rSF9HcFE/fMOsTem8lylkdFsgfcrVcPmIoh54dUErcXLd zoWAmA/S6sp17YX30G1+lVYPsqGrKcy9ZxpDDwSAn6OvIGdqUDah1qYPugYgufm6QmAP pa6nCBQtwUvY570NR+Qn5pBTaL4QgEIzCzxk1gDnaa+rw4zyR6lKBJbVCxuTfnvTvp8o +EHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=l+S8SsSfyLQKzrOFZh3L67P54q5wd2LgM9TcQbt4WrI=; b=fmbXgQKXKoRAz9C7mGXFwiKR72EduyVu1fZQ84FNXmArASLi/KCbUv0qFAcKWYCBm/ Z4XB40Iaki2F20tJGNiypSISeYG3zUq1vcBIdvAv/hI2+PXfbYRVm9gQkfeBslecCiXV sL/tnLBWXHiHISPw0D0nTaMvB/lpMcO4IEzurtxgLcrA2gh6ueW/Mq/hg9rl0qtXfyQq lBmw8jYDjscWaqJv9lIbap6hNkNho65n15ppWu1W4UxSU2fu2S/WX6+j8I0uVSFXl/Ba GvnS+t7ydxZSnE69hvabjk5P+bBVk4k1qTWK+j5vWw0DJ46hf9ycGEpnpkxm0BHf4o5r zOCg== X-Gm-Message-State: AOAM531Vc2QiBSPN08F6aiWA44bSJGjDuOFW9iEGPiamF7po4M3PL8AT f6ZnitVgLMlEOzV3C/UD4ek= X-Google-Smtp-Source: ABdhPJzTCb4AeYzQtdi+MVerwrADdF9H+g2u5zJujVuDoV7iGyvLipWZk4N1AAfNxc4rMdMnHIGIpQ== X-Received: by 2002:a1c:ddc1:: with SMTP id u184mr8633774wmg.115.1591895512066; Thu, 11 Jun 2020 10:11:52 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.177]) by smtp.gmail.com with ESMTPSA id u7sm6020345wrm.23.2020.06.11.10.11.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 10:11:51 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Roger Pau Monne'" , References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> <6de3a582-d9a8-60b5-9525-c9223932e4ed@citrix.com> In-Reply-To: <6de3a582-d9a8-60b5-9525-c9223932e4ed@citrix.com> Subject: RE: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask Date: Thu, 11 Jun 2020 18:11:50 +0100 Message-ID: <00f901d64013$6615a860$3240f920$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHx2+DDRjLQssRal4XfU2f+2Pe7FQIj4hRNAekcXgOofAaiQA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 11 June 2020 17:26 > To: Roger Pau Monne ; = xen-devel@lists.xenproject.org > Cc: paul@xen.org; Jan Beulich ; Wei Liu = > Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag = for GSIs not requiring an EOI > or unmask >=20 > On 10/06/2020 15:29, Roger Pau Monne wrote: > > There's no need to setup a timer for GSIs that are edge triggered, > > since those don't require any EIO or unmask, and hence couldn't = block > > other interrupts. > > > > Note this is only used by PVH dom0, that can setup the passthrough = of > > edge triggered interrupts from the vIO-APIC. One example of such = kind > > of interrupt that can be used by a PVH dom0 would be the RTC timer. > > > > While there introduce an out label to do the unlock and reduce code > > duplication. > > > > Signed-off-by: Roger Pau Monn=C3=A9 >=20 > Acked-by: Andrew Cooper Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Thu Jun 11 17:28:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 17:28:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQzw-0005cV-Q3; Thu, 11 Jun 2020 17:28:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjQzv-0005cO-Fz for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 17:28:15 +0000 X-Inumbo-ID: edb3b788-ac08-11ea-b54e-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id edb3b788-ac08-11ea-b54e-12813bfff9fa; Thu, 11 Jun 2020 17:28:14 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /ad5LL+eBFp6H+kNJxSE/Y4SNNLPRCeR2jm+rwjQP467+S5e/XFL3mY5Oo+fY9LHkBVK+W15an uuHjAmsLkEvvifUH8UZKTVZFxRpkUlB6PecUyWIPWj0MKjsO1j2fdMRKyJuuy1IFnvo24xbpwT kVSNiu9XQRiE+qOj8gge8gKktpq/WKxFZpdw6P0PQQVCCgjCxUFFQ22whHDYUDd9pr00hkkl0Q a3JYvWewOLKffoCnoZWuDudFmY2Xz2fCtj5r/laZ0SuXbdWIV16r8d4luXlkxJcKcdu3iCQgcX shs= X-SBRS: 2.7 X-MesageID: 20111936 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,500,1583211600"; d="scan'208";a="20111936" Subject: Re: [PATCH] x86/boot: use BASEDIR for include path To: Bertrand Marquis References: <5cf46b52-6a57-3e11-67a0-28f841865c1e@citrix.com> <7DA75B75-725F-40CC-9DDE-5727452309A0@arm.com> From: Andrew Cooper Message-ID: Date: Thu, 11 Jun 2020 18:28:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <7DA75B75-725F-40CC-9DDE-5727452309A0@arm.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Jan Beulich , xen-devel , nd , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 11/06/2020 17:50, Bertrand Marquis wrote: > Hi Andrew, > >> On 11 Jun 2020, at 17:24, Andrew Cooper wrote: >> >> On 11/06/2020 12:54, Bertrand Marquis wrote: >>> Use $(BASEDIR)/include instead of $(XEN_ROOT)/xen/include for the >>> include path to be coherent with the rest of the Makefiles. >>> >>> Signed-off-by: Bertrand Marquis >> Does something subtle break before this change? > Without changing anything no. > But if xen sub-directory is renamed yes. > > As there is no easy way to build xen hypervisor out of tree (I might be wrong here !) I found a solution using cp -rs from xen subdir in a xen-build1 xen-build2 etc this way I can check build for x86 and arm without cleaning. > > Without the patch, the sources are actually compiles with an include path containing xen/../xen as a result of using XEN_ROOT which does not allow to rename xen subdirectory. > As it was the only place in which XEN_ROOT was used for include paths, this is normalising the paths. Ok.  Acked-by: Andrew Cooper CC Paul for 4.14. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 11 18:17:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 18:17:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjRkv-0001L1-HK; Thu, 11 Jun 2020 18:16:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjRku-0001Kw-I8 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 18:16:48 +0000 X-Inumbo-ID: b64dc00d-ac0f-11ea-b55f-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b64dc00d-ac0f-11ea-b55f-12813bfff9fa; Thu, 11 Jun 2020 18:16:47 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 43F23206DC; Thu, 11 Jun 2020 18:16:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591899406; bh=Gdz6NiXCInYBJDguiN2rRw76D0sx81XLpjELCwiZGFo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=OwT+uJLSBw3vb6HSZLIazuyTT2ue7QAN2a5oPXuFk9HmxA8J10xcrDLNOlwZq07bb cdAK/cEgLI03USuBi4zaQw6YtE8MLcikh2ScGnpKoRQ/nsddQqs5ag7sZuU+YsW3Gb e8n92kfzV0H2yRkwAmr160N6DC625gRLCW7gT4Us= Date: Thu, 11 Jun 2020 11:16:45 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Bertrand Marquis Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall In-Reply-To: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> Message-ID: References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org, nd@arm.com, Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 11 Jun 2020, Bertrand Marquis wrote: > At the moment on Arm, a Linux guest running with KTPI enabled will > cause the following error when a context switch happens in user mode: > (XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xffffff837ebe0cd0 > > This patch is modifying the register runstate area handling on arm to > convert the guest address during the hypercall. During runtime context > switches the area is mapped to update the guest runstate copy. > The patch is also removing the initial copy which was done during the > hypercall handling as this is done on the current core when the context > is restore to go back to guest execution on arm. > > As a consequence if the register runstate hypercall is called on one > vcpu for an other vcpu, the area will not be updated until the vcpu > will be executed (on arm only). > > On x86, the behaviour is not modified, the address conversion is done > during the context switch and the area is updated fully during the > hypercall. > inline functions in headers could not be used as the architecture > domain.h is included before the global domain.h making it impossible > to use the struct vcpu inside the architecture header. > This should not have any performance impact as the hypercall is only > called once per vcpu usually. > > Signed-off-by: Bertrand Marquis > --- > xen/arch/arm/domain.c | 109 +++++++++++++++++++++++++++++------ > xen/arch/x86/domain.c | 30 +++++++++- > xen/arch/x86/x86_64/domain.c | 4 +- > xen/common/domain.c | 19 ++---- > xen/include/asm-arm/domain.h | 8 +++ > xen/include/asm-x86/domain.h | 16 +++++ > xen/include/xen/domain.h | 4 ++ > xen/include/xen/sched.h | 16 +---- > 8 files changed, 153 insertions(+), 53 deletions(-) > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 31169326b2..739059234f 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -275,36 +276,104 @@ static void ctxt_switch_to(struct vcpu *n) > virt_timer_restore(n); > } > > -/* Update per-VCPU guest runstate shared memory area (if registered). */ > -static void update_runstate_area(struct vcpu *v) > +void arch_cleanup_runstate_guest(struct vcpu *v) > { > - void __user *guest_handle = NULL; > - struct vcpu_runstate_info runstate; > + spin_lock(&v->arch.runstate_guest.lock); > > - if ( guest_handle_is_null(runstate_guest(v)) ) > - return; > + /* cleanup previous page if any */ > + if ( v->arch.runstate_guest.page ) > + { > + put_page_and_type(v->arch.runstate_guest.page); > + v->arch.runstate_guest.page = NULL; > + v->arch.runstate_guest.offset = 0; > + } > > - memcpy(&runstate, &v->runstate, sizeof(runstate)); > + spin_unlock(&v->arch.runstate_guest.lock); > +} > > - if ( VM_ASSIST(v->domain, runstate_update_flag) ) > +int arch_setup_runstate_guest(struct vcpu *v, > + struct vcpu_register_runstate_memory_area area) > +{ > + struct page_info *page; > + unsigned offset; > + > + spin_lock(&v->arch.runstate_guest.lock); > + > + /* cleanup previous page if any */ > + if ( v->arch.runstate_guest.page ) > { > - guest_handle = &v->runstate_guest.p->state_entry_time + 1; > - guest_handle--; > - runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > - __raw_copy_to_guest(guest_handle, > - (void *)(&runstate.state_entry_time + 1) - 1, 1); > - smp_wmb(); > + put_page_and_type(v->arch.runstate_guest.page); > + v->arch.runstate_guest.page = NULL; > + v->arch.runstate_guest.offset = 0; > + } > + > + offset = ((vaddr_t)area.addr.v) & ~PAGE_MASK; > + if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) > + { > + spin_unlock(&v->arch.runstate_guest.lock); > + gprintk(XENLOG_DEBUG, "Runstate is crossing pages\n"); > + return -EINVAL; > + } > + > + /* provided address must be aligned to a 64bit */ > + if ( offset % alignof(struct vcpu_runstate_info) ) > + { > + spin_unlock(&v->arch.runstate_guest.lock); > + gprintk(XENLOG_DEBUG, "Runstate pointer is not aligned\n"); > + return -EINVAL; > + } > + > + page = get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); > + if ( !page ) > + { > + spin_unlock(&v->arch.runstate_guest.lock); > + gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); I would make all these XENLOG_WARNING or XENLOG_ERR, they are errors after all. This last one I'd say "Could not map runstate point" and also print the address. > + return -EINVAL; > } > > - __copy_to_guest(runstate_guest(v), &runstate, 1); > + v->arch.runstate_guest.page = page; > + v->arch.runstate_guest.offset = offset; > + > + spin_unlock(&v->arch.runstate_guest.lock); > + > + return 0; > +} > + > + > +/* Update per-VCPU guest runstate shared memory area (if registered). */ > +static void update_runstate_area(struct vcpu *v) > +{ > + struct vcpu_runstate_info *guest_runstate; > + void *p; > + > + spin_lock(&v->arch.runstate_guest.lock); > > - if ( guest_handle ) > + if ( v->arch.runstate_guest.page ) > { > - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > + p = __map_domain_page(v->arch.runstate_guest.page); > + guest_runstate = p + v->arch.runstate_guest.offset; > + > + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > + { > + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; I think that this write to guest_runstate should use write_atomic or another atomic write operation. > + smp_wmb(); > + } > + > + memcpy(guest_runstate, &v->runstate, sizeof(v->runstate)); > smp_wmb(); > - __raw_copy_to_guest(guest_handle, > - (void *)(&runstate.state_entry_time + 1) - 1, 1); > + > + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > + { > + v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > + guest_runstate->state_entry_time &= ~XEN_RUNSTATE_UPDATE; same here > + smp_wmb(); > + } > + > + unmap_domain_page(p); > } > + > + spin_unlock(&v->arch.runstate_guest.lock); > } > > static void schedule_tail(struct vcpu *prev) > @@ -560,6 +629,8 @@ int arch_vcpu_create(struct vcpu *v) > v->arch.saved_context.sp = (register_t)v->arch.cpu_info; > v->arch.saved_context.pc = (register_t)continue_new_vcpu; > > + spin_lock_init(&v->arch.runstate_guest.lock); > + > /* Idle VCPUs don't need the rest of this setup */ > if ( is_idle_vcpu(v) ) > return rc; > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > index fee6c3931a..32bbed87d5 100644 > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1642,6 +1642,30 @@ void paravirt_ctxt_switch_to(struct vcpu *v) > wrmsr_tsc_aux(v->arch.msrs->tsc_aux); > } > > +int arch_setup_runstate_guest(struct vcpu *v, > + struct vcpu_register_runstate_memory_area area) > +{ > + struct vcpu_runstate_info runstate; > + > + runstate_guest(v) = area.addr.h; > + > + if ( v == current ) > + { > + __copy_to_guest(runstate_guest(v), &v->runstate, 1); > + } > + else > + { > + vcpu_runstate_get(v, &runstate); > + __copy_to_guest(runstate_guest(v), &runstate, 1); > + } > + return 0; > +} > + > +void arch_cleanup_runstate_guest(struct vcpu *v) > +{ > + set_xen_guest_handle(runstate_guest(v), NULL); > +} > + > /* Update per-VCPU guest runstate shared memory area (if registered). */ > bool update_runstate_area(struct vcpu *v) > { > @@ -1660,8 +1684,8 @@ bool update_runstate_area(struct vcpu *v) > if ( VM_ASSIST(v->domain, runstate_update_flag) ) > { > guest_handle = has_32bit_shinfo(v->domain) > - ? &v->runstate_guest.compat.p->state_entry_time + 1 > - : &v->runstate_guest.native.p->state_entry_time + 1; > + ? &v->arch.runstate_guest.compat.p->state_entry_time + 1 > + : &v->arch.runstate_guest.native.p->state_entry_time + 1; > guest_handle--; > runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > __raw_copy_to_guest(guest_handle, > @@ -1674,7 +1698,7 @@ bool update_runstate_area(struct vcpu *v) > struct compat_vcpu_runstate_info info; > > XLAT_vcpu_runstate_info(&info, &runstate); > - __copy_to_guest(v->runstate_guest.compat, &info, 1); > + __copy_to_guest(v->arch.runstate_guest.compat, &info, 1); > rc = true; > } > else > diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c > index c46dccc25a..b879e8dd2c 100644 > --- a/xen/arch/x86/x86_64/domain.c > +++ b/xen/arch/x86/x86_64/domain.c > @@ -36,7 +36,7 @@ arch_compat_vcpu_op( > break; > > rc = 0; > - guest_from_compat_handle(v->runstate_guest.compat, area.addr.h); > + guest_from_compat_handle(v->arch.runstate_guest.compat, area.addr.h); > > if ( v == current ) > { > @@ -49,7 +49,7 @@ arch_compat_vcpu_op( > vcpu_runstate_get(v, &runstate); > XLAT_vcpu_runstate_info(&info, &runstate); > } > - __copy_to_guest(v->runstate_guest.compat, &info, 1); > + __copy_to_guest(v->arch.runstate_guest.compat, &info, 1); > > break; > } > diff --git a/xen/common/domain.c b/xen/common/domain.c > index 7cc9526139..0ca6bf4dbc 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -727,7 +727,10 @@ int domain_kill(struct domain *d) > if ( cpupool_move_domain(d, cpupool0) ) > return -ERESTART; > for_each_vcpu ( d, v ) > + { > + arch_cleanup_runstate_guest(v); > unmap_vcpu_info(v); > + } > d->is_dying = DOMDYING_dead; > /* Mem event cleanup has to go here because the rings > * have to be put before we call put_domain. */ > @@ -1167,7 +1170,7 @@ int domain_soft_reset(struct domain *d) > > for_each_vcpu ( d, v ) > { > - set_xen_guest_handle(runstate_guest(v), NULL); > + arch_cleanup_runstate_guest(v); > unmap_vcpu_info(v); > } > > @@ -1484,7 +1487,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) > case VCPUOP_register_runstate_memory_area: > { > struct vcpu_register_runstate_memory_area area; > - struct vcpu_runstate_info runstate; > > rc = -EFAULT; > if ( copy_from_guest(&area, arg, 1) ) > @@ -1493,18 +1495,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg) > if ( !guest_handle_okay(area.addr.h, 1) ) > break; > > - rc = 0; > - runstate_guest(v) = area.addr.h; > - > - if ( v == current ) > - { > - __copy_to_guest(runstate_guest(v), &v->runstate, 1); > - } > - else > - { > - vcpu_runstate_get(v, &runstate); > - __copy_to_guest(runstate_guest(v), &runstate, 1); > - } > + rc = arch_setup_runstate_guest(v, area); > > break; > } > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h > index 4e2f582006..3a7f53e13d 100644 > --- a/xen/include/asm-arm/domain.h > +++ b/xen/include/asm-arm/domain.h > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include > #include > #include > > @@ -206,6 +207,13 @@ struct arch_vcpu > */ > bool need_flush_to_ram; > > + /* runstate guest info */ > + struct { > + struct page_info *page; /* guest page */ > + unsigned offset; /* offset in page */ > + spinlock_t lock; /* lock to access page */ > + } runstate_guest; > + > } __cacheline_aligned; > > void vcpu_show_execution_state(struct vcpu *); > diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h > index e8cee3d5e5..f917b48cb8 100644 > --- a/xen/include/asm-x86/domain.h > +++ b/xen/include/asm-x86/domain.h > @@ -11,6 +11,11 @@ > #include > #include > #include > +#ifdef CONFIG_COMPAT > +#include > +DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t); > +#endif > + > > #define has_32bit_shinfo(d) ((d)->arch.has_32bit_shinfo) > > @@ -626,6 +631,17 @@ struct arch_vcpu > struct { > bool next_interrupt_enabled; > } monitor; > + > +#ifndef CONFIG_COMPAT > +# define runstate_guest(v) ((v)->arch.runstate_guest) > + XEN_GUEST_HANDLE(vcpu_runstate_info_t) runstate_guest; /* guest address */ > +#else > +# define runstate_guest(v) ((v)->arch.runstate_guest.native) > + union { > + XEN_GUEST_HANDLE(vcpu_runstate_info_t) native; > + XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t) compat; > + } runstate_guest; > +#endif > }; > > struct guest_memory_policy > diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h > index 7e51d361de..d5d73ce997 100644 > --- a/xen/include/xen/domain.h > +++ b/xen/include/xen/domain.h > @@ -63,6 +63,10 @@ void arch_vcpu_destroy(struct vcpu *v); > int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset); > void unmap_vcpu_info(struct vcpu *v); > > +int arch_setup_runstate_guest(struct vcpu *v, > + struct vcpu_register_runstate_memory_area area); NIT: code style, the indentation is off > +void arch_cleanup_runstate_guest(struct vcpu *v); > + > int arch_domain_create(struct domain *d, > struct xen_domctl_createdomain *config); > > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h > index ac53519d7f..fac030fb83 100644 > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -29,11 +29,6 @@ > #include > #include > > -#ifdef CONFIG_COMPAT > -#include > -DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t); > -#endif > - > /* > * Stats > * > @@ -166,16 +161,7 @@ struct vcpu > struct sched_unit *sched_unit; > > struct vcpu_runstate_info runstate; > -#ifndef CONFIG_COMPAT > -# define runstate_guest(v) ((v)->runstate_guest) > - XEN_GUEST_HANDLE(vcpu_runstate_info_t) runstate_guest; /* guest address */ > -#else > -# define runstate_guest(v) ((v)->runstate_guest.native) > - union { > - XEN_GUEST_HANDLE(vcpu_runstate_info_t) native; > - XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t) compat; > - } runstate_guest; /* guest address */ > -#endif > + > unsigned int new_state; > > /* Has the FPU been initialised? */ > -- > 2.17.1 > From xen-devel-bounces@lists.xenproject.org Thu Jun 11 18:24:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 18:24:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjRse-0002Ce-Fu; Thu, 11 Jun 2020 18:24:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjRsd-0002CZ-Kw for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 18:24:47 +0000 X-Inumbo-ID: d4009100-ac10-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d4009100-ac10-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 18:24:46 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id f185so5963794wmf.3 for ; Thu, 11 Jun 2020 11:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c2qGo9t77ouQchLBlfa/rn2IqTIiNd/YvmN7vFJyU1Y=; b=JfOvwrnXDI4hOvsd8hYk3MOTRQiTjJatmlpz6NxuUen1f7tAfakfLiuR3gojxJ8AH7 qOP+mZKze6IWzR1Y01bHKBYVJL2CLkfhzmVq9SVYcIPU/C9ULooCCp9gV95LV1DEuSuR EfOqfqoMybRT9oIDpYf6qEGX2aollxhLtfkqQOmkJk9WaeLO3xBBwylcDey4LZZ04q68 C6eKG3o4ng0G5bYa9e/5is+Qzd8TPFDIX23II8WqVQXdw4Uysk0YXPrmdkKT7x7ivkd0 /NoWcNGP34UKy/XwJ+Zyp4TTbNORrj7q6o8lVZfRTckDn3BRazbEyY+FZ7TaZDIaHcw1 Z27w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c2qGo9t77ouQchLBlfa/rn2IqTIiNd/YvmN7vFJyU1Y=; b=W0dHLyyg5fJIsl2WL6/H+4WAANtvgdsCKY7odrCigLoKAZWUHnoWKWkSi8gzl6gd7t SR0nPs165z1j9ZhzxoHduCIaPljay0a8rpGDIGGZ8vf1xGHRelUCEQAdHJiVgjpNg9KQ hpFA0KEkKPHsupqEAxWeyZjAC7IcexosQbCwxQcNBM7YuQ7kBjCBPipQ4PfKgCbRwJUv 8C6r9WpJWrOPaFO2apoR1H/q0wrqjKEJcE17CUPSVKGGaaFysfbg+zgGnkyI6Zc8CS4p HrHB0htE/sPCHKl42kQ1uotFIo0NgO4LiE7ODhpbejcm8aOtdYDUfsI0Ko4CxujUkSVb wzEA== X-Gm-Message-State: AOAM532Q7QBp/jKIU2J3J+hCY7w6pSdKqKi+Hn0iAV6qSMhhygR0wjZx dI+3d988q+mTBfz4y4e6klujgPExnAzTQfB4zDg= X-Google-Smtp-Source: ABdhPJwY7rzVvYgJZrhhb4DKGrSFt7lC9LfZ5UVrebPneotJPlJE32fRQBZyWHCjJNsmajZxbgeFfnVrtdZNWKiwwuY= X-Received: by 2002:a1c:38c2:: with SMTP id f185mr9728298wma.79.1591899886108; Thu, 11 Jun 2020 11:24:46 -0700 (PDT) MIME-Version: 1.0 References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> In-Reply-To: From: Julien Grall Date: Thu, 11 Jun 2020 19:24:35 +0100 Message-ID: Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Bertrand Marquis , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > > + return -EINVAL; > > } > > > > - __copy_to_guest(runstate_guest(v), &runstate, 1); > > + v->arch.runstate_guest.page = page; > > + v->arch.runstate_guest.offset = offset; > > + > > + spin_unlock(&v->arch.runstate_guest.lock); > > + > > + return 0; > > +} > > + > > + > > +/* Update per-VCPU guest runstate shared memory area (if registered). */ > > +static void update_runstate_area(struct vcpu *v) > > +{ > > + struct vcpu_runstate_info *guest_runstate; > > + void *p; > > + > > + spin_lock(&v->arch.runstate_guest.lock); > > > > - if ( guest_handle ) > > + if ( v->arch.runstate_guest.page ) > > { > > - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > > + p = __map_domain_page(v->arch.runstate_guest.page); > > + guest_runstate = p + v->arch.runstate_guest.offset; > > + > > + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > > + { > > + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > > + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; > > I think that this write to guest_runstate should use write_atomic or > another atomic write operation. I thought about suggesting the same, but guest_copy_* helpers may not do a single memory write to state_entry_time. What are you trying to prevent with the write_atomic()? Cheers, From xen-devel-bounces@lists.xenproject.org Thu Jun 11 18:50:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 18:50:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjSHL-0004cm-KA; Thu, 11 Jun 2020 18:50:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjSHK-0004ch-01 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 18:50:18 +0000 X-Inumbo-ID: 6460bd08-ac14-11ea-b563-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6460bd08-ac14-11ea-b563-12813bfff9fa; Thu, 11 Jun 2020 18:50:17 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 712CE206DC; Thu, 11 Jun 2020 18:50:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591901416; bh=uDvsfQxTchtiWuXxTrpFglDfyW0ucaFH3zwefEaGOCU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ID9oGR3To+f3esIgWD6KOPOgYomj9Ga1r9j5EN0P1td5ztwGbE3uHM66cFQ+lq/Xs 6WvKpdW0qTaQVXNixLVCCN3dTiIq7ahBoLN17mJuhc57gp0v3ZZibk+ve47jVyBCYr iC9ztC7suIaJLl1kvADTFp/NO3/HrOFBQkBiJlbo= Date: Thu, 11 Jun 2020 11:50:16 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall In-Reply-To: Message-ID: References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Bertrand Marquis , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 11 Jun 2020, Julien Grall wrote: > > > + return -EINVAL; > > > } > > > > > > - __copy_to_guest(runstate_guest(v), &runstate, 1); > > > + v->arch.runstate_guest.page = page; > > > + v->arch.runstate_guest.offset = offset; > > > + > > > + spin_unlock(&v->arch.runstate_guest.lock); > > > + > > > + return 0; > > > +} > > > + > > > + > > > +/* Update per-VCPU guest runstate shared memory area (if registered). */ > > > +static void update_runstate_area(struct vcpu *v) > > > +{ > > > + struct vcpu_runstate_info *guest_runstate; > > > + void *p; > > > + > > > + spin_lock(&v->arch.runstate_guest.lock); > > > > > > - if ( guest_handle ) > > > + if ( v->arch.runstate_guest.page ) > > > { > > > - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > > > + p = __map_domain_page(v->arch.runstate_guest.page); > > > + guest_runstate = p + v->arch.runstate_guest.offset; > > > + > > > + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > > > + { > > > + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > > > + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; > > > > I think that this write to guest_runstate should use write_atomic or > > another atomic write operation. > > I thought about suggesting the same, but guest_copy_* helpers may not > do a single memory write to state_entry_time. > What are you trying to prevent with the write_atomic()? I am thinking that without using an atomic write, it would be (at least theoretically) possible for a guest to see a partial write to state_entry_time, which is not good. In theory, the set of assembly instructions generated by the compiler could go through an intermediate state that we don't want the guest to see. In practice, I doubt that any possible combination of assembly instructions generated by the compiler could lead to something harmful. From xen-devel-bounces@lists.xenproject.org Thu Jun 11 18:58:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 18:58:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjSP2-0004qm-F6; Thu, 11 Jun 2020 18:58:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjSP1-0004qS-O5 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 18:58:15 +0000 X-Inumbo-ID: 7e2ad8c6-ac15-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7e2ad8c6-ac15-11ea-bca7-bc764e2007e4; Thu, 11 Jun 2020 18:58:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ciqaPBb/87mxWVVBFtWyrqhRjdOZMedTm8sno2/P17E=; b=N9kBbefHCFgbFL7z3V9QRpmGT TJKeTrT6KMoS9V09TTqEDb9FBpMAEpmum85b8GIf+m75URd/HcWPJkkH9T3UcXaMZvHJUs37y9IV0 G0YMbhoa8N1ae06R81sAM2vDmp8gqzIrNsHoY17255VRZMMB9RIUkffStHk9VaQqzI8zs=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjSOv-00038D-Ol; Thu, 11 Jun 2020 18:58:09 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjSOv-0007jk-Ep; Thu, 11 Jun 2020 18:58:09 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjSOv-0004n4-EE; Thu, 11 Jun 2020 18:58:09 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151049: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=7028534d8482d25860c4d1aa8e45f0b911abfc5a X-Osstest-Versions-That: xen=6a49b9a7920c82015381740905582b666160d955 From: osstest service owner Date: Thu, 11 Jun 2020 18:58:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151049 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151049/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 7028534d8482d25860c4d1aa8e45f0b911abfc5a baseline version: xen 6a49b9a7920c82015381740905582b666160d955 Last test of basis 150950 2020-06-09 19:00:58 Z 1 days Testing same since 151049 2020-06-11 16:00:27 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Juergen Gross Julien Grall jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 6a49b9a792..7028534d84 7028534d8482d25860c4d1aa8e45f0b911abfc5a -> smoke From xen-devel-bounces@lists.xenproject.org Thu Jun 11 19:10:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 19:10:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjSaj-0006Ro-KF; Thu, 11 Jun 2020 19:10:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjSag-0006R5-8J for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 19:10:20 +0000 X-Inumbo-ID: 2ead46b0-ac17-11ea-b568-12813bfff9fa Received: from mo4-p00-ob.smtp.rzone.de (unknown [81.169.146.160]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2ead46b0-ac17-11ea-b568-12813bfff9fa; Thu, 11 Jun 2020 19:10:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591902615; s=strato-dkim-0002; d=aepfle.de; h=References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=c/YyX5dxTABHxkDhF1RlHPlerlbc2wZsuCS0Fyi+oFQ=; b=stAu9TixQCDdsYDP5iG5Jz2jxlgryKLQheKeECxzo+LKBTUPdAt99WhTERIZ/4xNLq VS4ZYnh63AlSbqp58/lKVOXTo00Nse85J8pnisYVew+D+wOnZZ57Lkt8xr8DjFCfyQpa 4qFrgILaNdnvtSl81wSq1VVXYLLSH+JW85BxYq/vO4StMkkVQ9T1raLqVbBYsPlqENCw 8Eb7QfbtZ1QwF8NE6KIiMvtPEkGUMXt0na42Umez8SxRgwNqGyGIsFNjX8VVig58CCCL kbKB8b9KsaI4mfIrICG4Fdf/+Ejp51vdhpm/0ULm6ATNXA0vRdAXuwz6scsp6B67/ctZ Rq9A== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QED/SSGq+wjGiUC4AUztn93FPS2dyuYMxg4g==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.10.4 DYNA|AUTH) with ESMTPSA id 0013a0w5BJAB0XP (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 11 Jun 2020 21:10:11 +0200 (CEST) Date: Thu, 11 Jun 2020 21:10:04 +0200 From: Olaf Hering To: Tim Deegan Subject: Re: [PATCH v1] kdd: remove zero-length arrays Message-ID: <20200611211004.11e38f8f.olaf@aepfle.de> In-Reply-To: <20200610191657.GA69414@deinos.phlegethon.org> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> <20200609152233.039cfc86.olaf@aepfle.de> <20200610191657.GA69414@deinos.phlegethon.org> X-Mailer: Claws Mail 2020.06.03 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/IQe_EQz7_eTqPFTXG09yN=2"; protocol="application/pgp-signature" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' , 'Wei Liu' , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Sig_/IQe_EQz7_eTqPFTXG09yN=2 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 10 Jun 2020 20:16:57 +0100 schrieb Tim Deegan : > How tedious. Indeed. This compiles for me as well: --- orig/kdd.h 2020-06-08 17:40:05.000000000 +0000 +++ kdd.h 2020-06-11 19:00:44.234364040 +0000 @@ -68,7 +68,6 @@ uint16_t len; /* Payload length, excl. header and trailing byte */ uint32_t id; /* Echoed in responses */ uint32_t sum; /* Unsigned sum of all payload bytes */ - uint8_t payload[0]; } PACKED kdd_hdr; =20 #define KDD_PKT_CMD 0x0002 /* Debugger commands (and replies to them)= */ @@ -323,7 +322,7 @@ kdd_msg msg; kdd_reg reg; kdd_stc stc; - uint8_t payload[0]; + uint8_t payload[65536]; }; } PACKED kdd_pkt; =20 --- orig/kdd.c 2020-06-08 17:40:05.000000000 +0000 +++ kdd.c 2020-06-11 19:08:36.775724640 +0000 @@ -79,11 +79,11 @@ /* State of the debugger stub */ typedef struct { union { - uint8_t txb[sizeof (kdd_hdr) + 65536]; /* Marshalling area for t= x */ + uint8_t txb[sizeof (kdd_hdr) + 0xffff]; /* Marshalling area for = tx */ kdd_pkt txp; /* Also readable as a packet structur= e */ }; union { - uint8_t rxb[sizeof (kdd_hdr) + 65536]; /* Marshalling area for r= x */ + uint8_t rxb[sizeof (kdd_hdr)]; /* Marshalling area for rx */ kdd_pkt rxp; /* Also readable as a packet structur= e */ }; unsigned int cur; /* Offset into rx where we'll put the next byt= e */ Olaf --Sig_/IQe_EQz7_eTqPFTXG09yN=2 Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iQIyBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7igYwACgkQ86SN7mm1 DoD4KA/4vENTigbsP76xRkx5K0yvtfscs3zvqtKTn6AcADsLsgNQC1r1HXpnrka1 EXt3CCz6C7GV1KvvaCA1x+6z2xtKv2VL40mNiamAD97HcWE6bdqLWms7N2AGda4Z PNMP3jab7L5vwLJ92JktOjnDBRoutgPNI0nbp/tdOAUIVDxGOSTEseWnB81AeWrg ld++KVRRC8kuYSHBThvUFNZOkej/bym22T+C9UIdWGs/FaR9G5fQ3cLOh13EY21J Ff3GAIJCIVg1OtUOJ1wHWKINri4p16BWtW25CxmrPtGcqOiC2HL5wPwkmbFBC2ap Hv1Fc5A99v32ZZGUFN4zuj4N+Gkc8x0+RIuoDa9M2d7QByGmCHI+pjKvRcjcmpqA zseNlV9MdpRJzEWm7x6tAh5/TH2KjIyHo4v1xAkFKBC72vik9cz8lZjLGT55ZcZw GC95dpCGYlDY2qU9iUx/K39fjXiJOH+8IwVS65o+Uz/FfNaNBC3MHvoKx7OyUK7X YvwlpWz6NhvezruMNSNg2GHNFW56Ucu24/yD5xloagA1dKLbHCm7E/QGt8SsdnRy egAm3p3rxuc1SE+NvNqdk3jCCiRGboZq+jmp2EO33+ll6vGxb1mo8+3GvLOP5vbb LEH1ezbWacRaL+IDzqtAVZDhlCky0ZGcQDkMgtMdR4IJaSMyMA== =MsgC -----END PGP SIGNATURE----- --Sig_/IQe_EQz7_eTqPFTXG09yN=2-- From xen-devel-bounces@lists.xenproject.org Thu Jun 11 19:38:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 19:38:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjT1v-0008I8-Vi; Thu, 11 Jun 2020 19:38:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjT1u-0008I3-R8 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 19:38:26 +0000 X-Inumbo-ID: 1dcd6e70-ac1b-11ea-b570-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1dcd6e70-ac1b-11ea-b570-12813bfff9fa; Thu, 11 Jun 2020 19:38:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=q6cqqMdgtTXIpIzrKG4x/y7h7KqE1tyD+pSV9cB939s=; b=bvuut4iGxFjNfH+HSEpPLUeHOa sRDzMz5xULNUVUqFXYCmeUJ8VX0HH0keqTLd1bZ/tJWkVfXi9GS6ysHT182gadRJF9nx1bMSRF0Us +7GEs7uEiOkSmDO5F6lOW3sZeA+NJOKdSyFLKAOVnNz4vJd7UvaYPdkmC7aZUIXs92rk=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjT1p-0003t9-1x; Thu, 11 Jun 2020 19:38:21 +0000 Received: from cpc91200-cmbg18-2-0-cust94.5-4.cable.virginm.net ([81.100.41.95] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjT1o-0006Nm-Rh; Thu, 11 Jun 2020 19:38:20 +0000 Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall To: Stefano Stabellini , Julien Grall References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> From: Julien Grall Message-ID: <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> Date: Thu, 11 Jun 2020 20:38:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Bertrand Marquis , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Stefano, On 11/06/2020 19:50, Stefano Stabellini wrote: > On Thu, 11 Jun 2020, Julien Grall wrote: >>>> + return -EINVAL; >>>> } >>>> >>>> - __copy_to_guest(runstate_guest(v), &runstate, 1); >>>> + v->arch.runstate_guest.page = page; >>>> + v->arch.runstate_guest.offset = offset; >>>> + >>>> + spin_unlock(&v->arch.runstate_guest.lock); >>>> + >>>> + return 0; >>>> +} >>>> + >>>> + >>>> +/* Update per-VCPU guest runstate shared memory area (if registered). */ >>>> +static void update_runstate_area(struct vcpu *v) >>>> +{ >>>> + struct vcpu_runstate_info *guest_runstate; >>>> + void *p; >>>> + >>>> + spin_lock(&v->arch.runstate_guest.lock); >>>> >>>> - if ( guest_handle ) >>>> + if ( v->arch.runstate_guest.page ) >>>> { >>>> - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; >>>> + p = __map_domain_page(v->arch.runstate_guest.page); >>>> + guest_runstate = p + v->arch.runstate_guest.offset; >>>> + >>>> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) >>>> + { >>>> + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; >>>> + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; >>> >>> I think that this write to guest_runstate should use write_atomic or >>> another atomic write operation. >> >> I thought about suggesting the same, but guest_copy_* helpers may not >> do a single memory write to state_entry_time. >> What are you trying to prevent with the write_atomic()? > > I am thinking that without using an atomic write, it would be (at least > theoretically) possible for a guest to see a partial write to > state_entry_time, which is not good. It is already the case with existing implementation as Xen may write byte by byte. So are you suggesting the existing code is also buggy? > In theory, the set of assembly > instructions generated by the compiler could go through an intermediate > state that we don't want the guest to see. In practice, I doubt that any > possible combination of assembly instructions generated by the compiler > could lead to something harmful. Well, I think you first need to define the theoritical state you are worried about. Then we can discuss whether they can happen in practice and how we can prevent them in the existing and new code. So what sort of state your are concerned? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 11 21:17:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 21:17:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjUZt-0007yo-Bu; Thu, 11 Jun 2020 21:17:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjUZs-0007yj-6Q for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 21:17:36 +0000 X-Inumbo-ID: f779c904-ac28-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f779c904-ac28-11ea-b7bb-bc764e2007e4; Thu, 11 Jun 2020 21:17:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ITNrAqUNceKo68+Ct9Q57TmRrnWcbeYokry4OLvHfUY=; b=WenbSWG88EMy5lhXB3b6NZou2 QlAQoB9puV5CxbkdVKOLRboEuTzf76eL6mdZ789mvfYq0nb3A2kUPv/p1gYl+KAUzJXIG8vf6N+XZ Fdflzi5TFcs9MsTVdq1yIewMytXaju1H2I4oepNZM5Fwso2j1vocAsPYveJt5WIIb7lJ0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjUZp-0005lR-Ge; Thu, 11 Jun 2020 21:17:33 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjUZo-0007va-2q; Thu, 11 Jun 2020 21:17:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjUZo-00035F-2A; Thu, 11 Jun 2020 21:17:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151021: regressions - FAIL X-Osstest-Failures: xen-unstable:build-arm64-libvirt:libvirt-build:fail:regression xen-unstable:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=6a49b9a7920c82015381740905582b666160d955 X-Osstest-Versions-That: xen=058023b343d4e366864831db46e9b438e9e3a178 From: osstest service owner Date: Thu, 11 Jun 2020 21:17:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151021 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151021/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150963 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150963 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150963 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150963 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150963 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150963 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150963 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150963 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150963 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150963 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 6a49b9a7920c82015381740905582b666160d955 baseline version: xen 058023b343d4e366864831db46e9b438e9e3a178 Last test of basis 150963 2020-06-09 20:06:30 Z 2 days Testing same since 151021 2020-06-10 18:24:20 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt fail build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 6a49b9a7920c82015381740905582b666160d955 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Thu Jun 11 22:03:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 22:03:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjVHb-0003cd-AV; Thu, 11 Jun 2020 22:02:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjVHa-0003cY-P6 for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 22:02:46 +0000 X-Inumbo-ID: 47d2da7a-ac2f-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 47d2da7a-ac2f-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 22:02:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/E0spSjCLOHE48ORa40MAJ7vvbBd/BeQ1Xov1vsaeu0=; b=pkWfhaTAxX6NRbYVIN4MKSlnu C78Wmd3NWcVTfI6OyBmFpK0T5xS5qdgrkjaNxMDKrjVCwFhR/OhLUDabPS8idw0zrFVlLpIYe3PWF RkIwcUmeQe2fw5m9aUaMjXsPj9ilBoe1RzXcv+l926ODa7qqcAV8cJbUocyL+ICk1ecI8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjVHZ-0006ay-En; Thu, 11 Jun 2020 22:02:45 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjVHZ-0001QB-7K; Thu, 11 Jun 2020 22:02:45 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjVHZ-0003QR-6f; Thu, 11 Jun 2020 22:02:45 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151050: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=3664f7b7788b66bb802432e6748be0fb57993581 X-Osstest-Versions-That: xen=7028534d8482d25860c4d1aa8e45f0b911abfc5a From: osstest service owner Date: Thu, 11 Jun 2020 22:02:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151050 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151050/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 3664f7b7788b66bb802432e6748be0fb57993581 baseline version: xen 7028534d8482d25860c4d1aa8e45f0b911abfc5a Last test of basis 151049 2020-06-11 16:00:27 Z 0 days Testing same since 151050 2020-06-11 19:01:32 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper George Dunlap Jan Beulich Juergen Gross Paul Durrant jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 7028534d84..3664f7b778 3664f7b7788b66bb802432e6748be0fb57993581 -> smoke From xen-devel-bounces@lists.xenproject.org Thu Jun 11 23:02:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 23:02:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjWDL-00005N-PX; Thu, 11 Jun 2020 23:02:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjWDK-00005I-SM for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 23:02:26 +0000 X-Inumbo-ID: 9d277dd4-ac37-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9d277dd4-ac37-11ea-bb8b-bc764e2007e4; Thu, 11 Jun 2020 23:02:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=S02b3gnOZY8utZsUIWA4HO9ZLITpsXR2fWdpdlYqrNc=; b=26cw5PYM3P4Zgs19VcYr5md02 nJBKZgZE516z6l2yKEch8GJRtIBdp3YHjlYBi/yMpxDF0+uuOcmfSbdSjelF4FdB/5At/jSe2MP5F 6QyHv3Ac3RwtAkZJJgxbPiTC2pAHDFrOPzao506UaTh1JaDRRLWgctFoH4/9AAnnJLHVY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjWDI-0007f1-JS; Thu, 11 Jun 2020 23:02:24 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjWDI-0003yS-5d; Thu, 11 Jun 2020 23:02:24 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjWDI-0007QG-4t; Thu, 11 Jun 2020 23:02:24 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151024: regressions - FAIL X-Osstest-Failures: ovmf:build-i386-xsm:xen-build:fail:regression X-Osstest-Versions-This: ovmf=e1d24410da356731da70b3334f86343e11e207d2 X-Osstest-Versions-That: ovmf=dafce295e6f447ed8905db4e29241e2c6c2a4389 From: osstest service owner Date: Thu, 11 Jun 2020 23:02:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151024 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151024/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm 6 xen-build fail REGR. vs. 150978 version targeted for testing: ovmf e1d24410da356731da70b3334f86343e11e207d2 baseline version: ovmf dafce295e6f447ed8905db4e29241e2c6c2a4389 Last test of basis 150978 2020-06-09 21:39:29 Z 2 days Testing same since 151024 2020-06-10 19:57:12 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Abdul Lateef Attar Ard Biesheuvel Dong, Eric Eric Dong Heyi Guo Laszlo Ersek Walon Li jobs: build-amd64-xsm pass build-i386-xsm fail build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit e1d24410da356731da70b3334f86343e11e207d2 Author: Heyi Guo Date: Tue Jun 9 09:26:30 2020 +0800 ArmPkg/ArmExceptionLib: use static buffer for sp_el0 The exception library is also used in DxeMain before memory services are available, and AllocatePages() will fail in this case and cause sp_el0 remains 0. Then if any exception occurs before CpuDxe driver is loaded, a recursive exception will be trigged by page translation fault for sp = 0 - 0x130. Use static buffer instead to fix this issue. Signed-off-by: Heyi Guo Reviewed-by: Ard Biesheuvel commit 14c7ed8b51f60097ad771277da69f74b22a7a759 Author: Laszlo Ersek Date: Tue Jun 9 12:54:14 2020 +0200 OvmfPkg/GenericQemuLoadImageLib: log "Not Found" at INFO level gBS->LoadImage() returning EFI_NOT_FOUND is an expected condition; it means that QEMU wasn't started with "-kernel". Log this status code as INFO rather than ERROR. Cc: Ard Biesheuvel Cc: Jordan Justen Cc: Philippe Mathieu-Daudé Signed-off-by: Laszlo Ersek Message-Id: <20200609105414.12474-1-lersek@redhat.com> Acked-by: Ard Biesheuvel commit 365fdb0f939cf00b26d37f27adbf579aa984221b Author: Walon Li Date: Wed May 20 12:24:47 2020 +0800 MdeModulePkg/SetupBrowserDxe: Do not reconnect driver with form-update REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2701 Recording to the spec, the reconnect is activated upon exiting of the formset or the browser. Exiting is by user but form-browser internal logic. That means the reconnection is only happened when user press ESC or _EXIT action to exit form. Driver callback may update HII form dynamically so form-browser needs to refresh its internal data. It's not exiting formset for user exactly and they didn't know what happened. So use a flag to record that and do not reconnect driver if updated by callback. Signed-off-by: Walon Li Reviewed-by: Dandan Bi commit 8c91934019a7c10811d274d65210e9fdf36400cc Author: Eric Dong Date: Wed Jun 10 11:38:26 2020 +0800 Maintainers.txt: Add reviewer for Pei Core. Signed-off-by: Eric Dong Cc: Hao A Wu Cc: Debkumar De Cc: Harry Han Cc: Catharine West Acked-by: Laszlo Ersek Reviewed-by: Ray Ni commit b7b3a5f99b1fe10d392e962424a2b488b1ff0804 Author: Dong, Eric Date: Wed Jun 3 11:18:05 2020 +0800 Maintainers.txt: Add reviewer for SEC related modules. Signed-off-by: Eric Dong Cc: Debkumar De Cc: Harry Han Cc: Catharine West Acked-by: Laszlo Ersek Reviewed-by: Ray Ni commit 5ebec96f282d30e0d225ece376f0060fd9a1c039 Author: Dong, Eric Date: Wed Jun 3 11:18:04 2020 +0800 Maintainers.txt: Add reviewer for UefiCpuPkg. Signed-off-by: Eric Dong Reviewed-by: Ray Ni Cc: Laszlo Ersek Cc: Rahul Kumar commit 4e3600b0388f6d4cce4dca544ac8226340836c23 Author: Eric Dong Date: Wed Jun 10 11:41:01 2020 +0800 Maintainers.txt: Add reviewer for security boot modules. Cc: Jiewen Yao Cc: Jian J Wang Cc: Chao Zhang Cc: Min Xu Signed-off-by: Eric Dong Reviewed-by: Jian J Wang commit 3b18b80aff3db6c1775059183009427b73d52cea Author: Dong, Eric Date: Wed Jun 3 11:18:02 2020 +0800 Maintainers.txt: Add reviewers for Tcg related modules. Cc: Chao Zhang Cc: Qi Zhang Cc: Rahul Kumar Cc: Jiewen Yao Signed-off-by: Eric Dong Reviewed-by: Jian J Wang Acked-by: Laszlo Ersek commit 9b52b06f964226780b7047e10be0c1a65e223eb1 Author: Abdul Lateef Attar Date: Mon Apr 20 15:05:55 2020 +0800 MdeModulePkg: Sets the Cursor to selected BootOption. Its been observed that in MenuManagerMenuApp when user selects a different BootOption using Up/Down key, the current Cursor position is not chaning. Still points to the old BootOption. This changes first dispalys/redraws the old BootOption followed by new BootOption. Doing so will make current cursor pointing to the user selected BootOption. Signed-off-by: Abdul Lateef Attar Reviewed-by: Dandan Bi From xen-devel-bounces@lists.xenproject.org Thu Jun 11 23:24:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 23:24:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjWYT-0001oN-HK; Thu, 11 Jun 2020 23:24:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjWYS-0001oI-Ms for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 23:24:16 +0000 X-Inumbo-ID: a94dded4-ac3a-11ea-b58d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a94dded4-ac3a-11ea-b58d-12813bfff9fa; Thu, 11 Jun 2020 23:24:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sIDmwUfWzEhI3ZZYnYG2sNUCH5MKQUlXS4I7m1L/k3A=; b=NxxCgCDpXy4kdJuweBO450m7h cctIv2ArLeBSZ9eyRDZ/vRhcCpdKtCQBDpJkzxAPgF5qP2QPcNB75mqs4z5C9vr8unaRoETB04qif x9YufYZ07ErapLBzOZYSzsaDADzHRLYl05zLgSF8P4G2beyCsEF1fFLA1jcinuah+z+ps=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjWYP-00082f-FX; Thu, 11 Jun 2020 23:24:13 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjWYP-0004gi-3m; Thu, 11 Jun 2020 23:24:13 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjWYP-0006x7-2J; Thu, 11 Jun 2020 23:24:13 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 151022: tolerable FAIL - PUSHED X-Osstest-Failures: linux-5.4:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=5e3c511539228fa03c8d00d61b5b5f32333ed0b0 X-Osstest-Versions-That: linux=3604bc07c035939266d78d65084c6cd54ffc6d56 From: osstest service owner Date: Thu, 11 Jun 2020 23:24:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151022 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/151022/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 150912 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 5e3c511539228fa03c8d00d61b5b5f32333ed0b0 baseline version: linux 3604bc07c035939266d78d65084c6cd54ffc6d56 Last test of basis 150912 2020-06-07 20:39:55 Z 4 days Testing same since 151022 2020-06-10 18:39:22 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Bin Liu Bjørn Mork Borislav Petkov Christian Borntraeger Chuhong Yuan Cong Wang Daniele Palmas David S. Miller Dexuan Cui Dinghao Liu Dmitry Torokhov Eric Dumazet Fabrice Gasnier Fugang Duan Greg Kroah-Hartman Guillaume Nault Heinrich Kuhn Jiri Slaby Johan Hovold Jonathan Cameron Josh Poimboeuf Linus Torvalds Mark Bloch Mark Gross Mathieu Othacehe Matt Jolly Michael Hanselmann Neelima Krishnan Oleg Nesterov Oliver Neukum Pascal Terjan Saeed Mahameed Simon Horman Srinivas Kandagatla Stefano Garzarella Sven Schnelle Thomas Gleixner Tomasz Duszynski Tony W Wang-oc Willem de Bruijn Yang Yingliang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 3604bc07c035..5e3c51153922 5e3c511539228fa03c8d00d61b5b5f32333ed0b0 -> tested/linux-5.4 From xen-devel-bounces@lists.xenproject.org Thu Jun 11 23:38:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 11 Jun 2020 23:38:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjWmF-0002no-Vm; Thu, 11 Jun 2020 23:38:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjWmE-0002mg-2Y for xen-devel@lists.xenproject.org; Thu, 11 Jun 2020 23:38:30 +0000 X-Inumbo-ID: a3a08f98-ac3c-11ea-b58d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a3a08f98-ac3c-11ea-b58d-12813bfff9fa; Thu, 11 Jun 2020 23:38:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zlHd4hYa9k5hybVp61KKqZHphYwP6WFtuVFSalB/fZ4=; b=jN8DZoQuUQe8nND6cRhNJihLL fohvhb/2oqJPcw93Ug/Tdp0Ak978MWs1sLWQhXxaFVYtWJCe3Ug1jUri1MaAvaKpwn3KgdVad6aT2 tklJc0cuI2SqifW7Kad3d3OJFBhMshrhffzo6OJB//wEwKRBZx03Du4qaVox1UHMTYRDo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjWm6-0008IG-M5; Thu, 11 Jun 2020 23:38:22 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjWm6-0005CW-CZ; Thu, 11 Jun 2020 23:38:22 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjWm6-00016e-Bu; Thu, 11 Jun 2020 23:38:22 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 151036: regressions - FAIL X-Osstest-Failures: xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-arm64-xsm:xen-build:fail:regression xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-arm64:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-armhf:xen-build:fail:regression xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=ad0c1a0023077ee03d325a6f84bb654150539f49 X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Thu, 11 Jun 2020 23:38:22 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151036 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151036/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-arm64-xsm 6 xen-build fail REGR. vs. 150120 build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-arm64 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-armhf 6 xen-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a version targeted for testing: xen ad0c1a0023077ee03d325a6f84bb654150539f49 baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 32 days Testing same since 150940 2020-06-09 17:05:20 Z 2 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Fri Jun 12 00:23:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 00:23:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXTA-0007NN-DT; Fri, 12 Jun 2020 00:22:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXT9-0007MF-76 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 00:22:51 +0000 X-Inumbo-ID: d38d35c0-ac42-11ea-b594-12813bfff9fa Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.49]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d38d35c0-ac42-11ea-b594-12813bfff9fa; Fri, 12 Jun 2020 00:22:41 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mcP4sA+hEQVJF1W6Y9DzG8r+tQez69RJY1B1fyJTUs1IR9R2OfAYVgzYUypwYlA0WXhY3ki533i7dVFvQ90dXMaI80uXA4iqxcffQjqyIx3SXgifMdK3g8XuZYY52ysdd7dqNYLzEebBIJFdjO5YBAyOQxG7ClFDs542XaglFfB4GA5Q7hE2r8VNgB8thitHmGBWgIyifPKt3HviXB9WbJwxvhwuS3j4vM+74eXlR1xTlxUEX1lnxFbeXz9OOrqysrA3FrvgVTRxBVSuqLaKi6Xmga8++eXhGI1Xw9rg3IlFFpMwcP/P1KUHTLDdU9hwrrBBLxhoRFZAeL7kr7gFnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8n6iL6VdFsc8wy50qekTiQl7oB+xdogsCttW9HtWe3c=; b=hRYEygeO19t/RydII5dQd+S0i0PuJpDBo14j8oy6PcG7Du4EgmTEiaa4TiW6iv0JIF5A5stYPsrhVFiA1cl0XBIkm9Ji9+7YvHzmAUBURu9d1uWgqOPuY/U6/Rl9wLPSUhwNT7OBiExEcvm0/DJNG5a1aKNWvnNPjP24U3iaGXt2Hs74Hrnv5teGDW9CWve4S5I3YC/SWqx3hZUXU3oSZr6+C174kPkdMN1qHPsSPDImeiw+f5FTHhCxuxMd1vgQigNg0WLeI2SBHIvCZN/aIWKZO4VEshx5AtKKxwCmTc5TyZ82vrCjBGX1XoK23AxZ24prkaqODbICHKQJWvWL5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8n6iL6VdFsc8wy50qekTiQl7oB+xdogsCttW9HtWe3c=; b=xjEHcBSjLKdQGJ45QJ4OUNfVtLN+yE1e1FP+/fZadJc0msL9J+csATfp++5vWmFyfpuEXiK8jfGOxx1/Iki9lNDw9ox7owlOosy3HJLrCyoi5uDRTvEMwYVb823RZpewYSXHU1m5UBBmZpEOnuFNPlNQPOUWNR0TmVuDHS2QrIVMvgScIRTpsw8/tZjk+5Q2HdDK/rd1lXlQk0ljb58ant3aXTtXxsHtBjyiv1pAtaMGsTZoyKo5Mhg9twgBKJkpkbHOn8nXzy/iUcBRkMlaR7sHM3lk7kYhxCKtNf0R05hEthxf+u+GmKM3F6HjS9RBEVpwN2tc5UEI9sTp1gOw+w== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB2654.eurprd03.prod.outlook.com (2603:10a6:800:e0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 00:22:36 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.018; Fri, 12 Jun 2020 00:22:36 +0000 From: Volodymyr Babchuk To: "xen-devel@lists.xenproject.org" Subject: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler Thread-Topic: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler Thread-Index: AQHWQE+STyWApsQdk0CG54zgwiPygA== Date: Fri, 12 Jun 2020 00:22:36 +0000 Message-ID: <20200612002205.174295-2-volodymyr_babchuk@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> In-Reply-To: <20200612002205.174295-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d142841-7f32-43ca-1742-08d80e66b585 x-ms-traffictypediagnostic: VI1PR0302MB2654: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: A3DHQlteC/uRdv11c01jNEar4XsYAKwmOfpvHOPK2ntTM4kd6C8WD67kIQATvoBx9L2LWqa7SIc3PxwJIYftMuSja+IskTrPzBtrL610WK1UyK3+pZTYyAJ6SbOAEI+kfptfw2u4PG+XLDMIRZJMMDQfXEkuPa3Vcsipw4ptdvBhXlMYPIwSZJ7P3AyEzvreHxWajKwGYEVIkx7sFTnZTIG22x1ZQcH6ZobiWvNteBlr9yiTOIox6aHYAVwN2MDQGS+pz/hZbNTEiZ0X3hfh5rUoOstFT3YHClw3Mf2AO3rYOKqalIylQErnKCdbrflyTPcaUMUxILTgGKMa8M3gSDE1kqvhBdczvTjVgMndQ4oXJAg7CE2qlC78UcIT9MjH x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(136003)(346002)(66446008)(64756008)(478600001)(66946007)(66556008)(76116006)(66476007)(26005)(91956017)(36756003)(8676002)(86362001)(55236004)(186003)(8936002)(4326008)(6506007)(7416002)(54906003)(6512007)(2906002)(6486002)(316002)(5660300002)(83380400001)(6916009)(71200400001)(1076003)(2616005)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: moyzJTyMdelEEhrkI8khnrHuQvBY3ENfYyyw2lctvcOpCNPjPehzM0cstOKmAyOycpxvDut0/jJjQvx51DOh5PMFOcrJI4JLb3J5p1dxogGKHfScfDkA5fXANDIKa9bEsJqhIBtY8nq3aw0Cx4PLjPLKTRVvA++3UeCcs6j8FhMlAdJQH+TvDVF57sm1s4XTsUZoB2NgO6Z0OIFTZXppsxcVbNg2dRNhbrL+7I0zBCaYJadSN2Tp50ChC/78LCNJShrUwVjmTMDK8rxLcpu7rZydfF4i/wKX6Mc+zQong7MykOO81TI5XIPxEOUFtaWSgJmpFwZ4jWkkUwrUCwioqPR9dAKuEuWBsEktpo9FL4NRM+DMOOM1XnIdvNb0Nic8ZXaSkhTl4xAdIiZ6ZEJo61JGRK2hTagacS7MeaqmeTk/85qjBkzW0yYLwdMX5C0K5m4YlL3clH1DhcNr+mefjgexuIqSdqErB8iBd9QfNrA= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d142841-7f32-43ca-1742-08d80e66b585 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 00:22:36.3359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BYPRm6ZMprkAWgcLBms6TtzX9LlRvESjFYyChLURXmpabqyq5woLdP1h2tGSVp2ih7mSTYD3VjEyl3V2GfveVg/nzkwHoRu9YNUGInmdDJE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB2654 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich , Volodymyr Babchuk , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add code that saves time spent in IRQ handler, so later we can make adjustments to schedule unit run time. This and following changes are called upon to provide fair scheduling. Problem is that any running vCPU can be interrupted by to handle IRQ which is bound to some other vCPU. Thus, current vCPU can be charged for a time, it actually didn't used. TODO: move vcpu_{begin|end}_irq_handler() calls to entry.S for even more fair time tracking. Signed-off-by: Volodymyr Babchuk --- xen/arch/arm/irq.c | 2 ++ xen/arch/x86/irq.c | 2 ++ xen/common/sched/core.c | 29 +++++++++++++++++++++++++++++ xen/include/xen/sched.h | 13 +++++++++++++ 4 files changed, 46 insertions(+) diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c index 3877657a52..51b517c0cd 100644 --- a/xen/arch/arm/irq.c +++ b/xen/arch/arm/irq.c @@ -201,6 +201,7 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int ir= q, int is_fiq) struct irq_desc *desc =3D irq_to_desc(irq); struct irqaction *action; =20 + vcpu_begin_irq_handler(); perfc_incr(irqs); =20 ASSERT(irq >=3D 16); /* SGIs do not come down this path */ @@ -267,6 +268,7 @@ out: out_no_end: spin_unlock(&desc->lock); irq_exit(); + vcpu_end_irq_handler(); } =20 void release_irq(unsigned int irq, const void *dev_id) diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c index a69937c840..3ef4221b64 100644 --- a/xen/arch/x86/irq.c +++ b/xen/arch/x86/irq.c @@ -1895,6 +1895,7 @@ void do_IRQ(struct cpu_user_regs *regs) int irq =3D this_cpu(vector_irq)[vector]; struct cpu_user_regs *old_regs =3D set_irq_regs(regs); =20 + vcpu_begin_irq_handler(); perfc_incr(irqs); this_cpu(irq_count)++; irq_enter(); @@ -2024,6 +2025,7 @@ void do_IRQ(struct cpu_user_regs *regs) out_no_unlock: irq_exit(); set_irq_regs(old_regs); + vcpu_end_irq_handler(); } =20 static inline bool is_free_pirq(const struct domain *d, diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c index cb49a8bc02..8f642ada05 100644 --- a/xen/common/sched/core.c +++ b/xen/common/sched/core.c @@ -916,6 +916,35 @@ void vcpu_unblock(struct vcpu *v) vcpu_wake(v); } =20 +void vcpu_begin_irq_handler(void) +{ + if (is_idle_vcpu(current)) + return; + + /* XXX: Looks like ASSERT_INTERRUPTS_DISABLED() is available only for = x86 */ + if ( current->irq_nesting++ ) + return; + + current->irq_entry_time =3D NOW(); +} + +void vcpu_end_irq_handler(void) +{ + int delta; + + if (is_idle_vcpu(current)) + return; + + ASSERT(current->irq_nesting); + + if ( --current->irq_nesting ) + return; + + /* We assume that irq handling time will not overflow int */ + delta =3D NOW() - current->irq_entry_time; + atomic_add(delta, ¤t->sched_unit->irq_time); +} + /* * Do the actual movement of an unit from old to new CPU. Locks for *both* * CPUs needs to have been taken already when calling this! diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index ac53519d7f..ceed53364b 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -237,6 +237,9 @@ struct vcpu evtchn_port_t virq_to_evtchn[NR_VIRQS]; spinlock_t virq_lock; =20 + /* Fair scheduling state */ + uint64_t irq_entry_time; + unsigned int irq_nesting; /* Tasklet for continue_hypercall_on_cpu(). */ struct tasklet continue_hypercall_tasklet; =20 @@ -276,6 +279,9 @@ struct sched_unit { /* Vcpu state summary. */ unsigned int runstate_cnt[4]; =20 + /* Fair scheduling correction value */ + atomic_t irq_time; + /* Bitmask of CPUs on which this VCPU may run. */ cpumask_var_t cpu_hard_affinity; /* Used to save affinity during temporary pinning. */ @@ -690,6 +696,13 @@ long vcpu_yield(void); void vcpu_sleep_nosync(struct vcpu *v); void vcpu_sleep_sync(struct vcpu *v); =20 +/* + * Report IRQ handling time to scheduler. As IRQs can be nested, + * next two functions are re-enterable. + */ +void vcpu_begin_irq_handler(void); +void vcpu_end_irq_handler(void); + /* * Force synchronisation of given VCPU's state. If it is currently desched= uled, * this call will ensure that all its state is committed to memory and tha= t --=20 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 00:23:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 00:23:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXT0-0007MK-PB; Fri, 12 Jun 2020 00:22:42 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXSz-0007MF-B7 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 00:22:41 +0000 X-Inumbo-ID: d1dd3dc4-ac42-11ea-b594-12813bfff9fa Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.89]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d1dd3dc4-ac42-11ea-b594-12813bfff9fa; Fri, 12 Jun 2020 00:22:39 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P2oScPt5XwaGY8m7MiYF+9LVJjQiFNMBR0Zy3DwC7SRdQD2t31fbrjjp5kevnCONTZnzA7laXtUHJtqSE1OrlOOG7J8oODaCrA0y1wV/d2g74R6NV2H7ie2NuSfPiwmySo92HOxvq1pMPuoUv36OJn9hZeKkFZIt6qbXuk21RJyH4ez8q2y0ehaxIszumz20Vw1GiyCSY9cOvzSfCP+tfgeqJ15hqcqM0pvwHBo1qx8C8qWoFEshVCMLLaqpX33d74O7jDa82KvCj5BnfcN6DQ+2kD/Eljza52HBKIt3kR5K29ahjnUJIgVN+j6Zj/6nWgB3Xz2TLmzsv2vL151IQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mrWui09u+5cIgvpHZOOFv3CDq05Q0coOiwBD2KZRCAg=; b=N3iAARi5JebKkoJfrDmi2uNgsj1IrRE1dmZOmekiqPb+z1ZEyqbwlCOBrPzHRN/Ti91SXUwHq+EFID9S/ziO3HwxooJq1HtGnFTAHyVwDr+HZJZ/jLEogKQ19qV4CTJyHbpWXImTP9jGgyPsSAa2o0Pt/zuw57Jw05cpH0chIMMSo/oKgERlmUD2TpBV+CeX3BA+kYvO2+wImqC/nS/zDfQPJFnJTuvmqrEsLE0ZvPEEofCM+ITQLpiir6SpoRn7F8z63vx4/qqeBaLCiBFHx4zuFbmf4Qaj5XfwrUec+c26Nl4kJg2IwMbFhWHQeQEIR+4zDFrk+nRDFfchGqJRyw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mrWui09u+5cIgvpHZOOFv3CDq05Q0coOiwBD2KZRCAg=; b=pJVt1+Bg8+yp6+cmDu0pvx40pqo13/6R4KSINhXgHgpTfabRTXgaj24TA7MHHB/KvsUNW9SQSe3WuuXa6rMGFLq54xk15PU87jSDvu0P37XqUlebVuSqzPVWpDCI1bl20w7iIXa9AThn0XY0aM6FEEWRb1Tr+XALp5OW94NvOhNR1BGpcsHnYSLKu73SqJnn5x97b8rNF3oBnB5ijr6oXPdPaFl22dE+1+O9I8XnmigHzI3RQDc5KkMHaYYcPDQpsKMWELBbURgmMAbnqF4RdgOGe1V75ynFhimJPzoaGFtz/0ge3Aeb8vKtXzPbnYX5gcHjMfaxPs21ie7Q2/yLUw== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB2654.eurprd03.prod.outlook.com (2603:10a6:800:e0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 00:22:36 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.018; Fri, 12 Jun 2020 00:22:36 +0000 From: Volodymyr Babchuk To: "xen-devel@lists.xenproject.org" Subject: [RFC PATCH v1 0/6] Fair scheduling Thread-Topic: [RFC PATCH v1 0/6] Fair scheduling Thread-Index: AQHWQE+S5leDZ35sk0y6s2xYl7vsow== Date: Fri, 12 Jun 2020 00:22:35 +0000 Message-ID: <20200612002205.174295-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a6a8effd-d698-4e8e-51e5-08d80e66b525 x-ms-traffictypediagnostic: VI1PR0302MB2654: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sdsyCNTH72n9uR9BtfcdpARXH2HVEBGjaVgMHoq+j8FgitrYyTP94IHS/DNnYaq0f6iHVB1f4ec2yHqyVPP3XO4gsUA5ePO4smDFtCd8ORwXK2I7CMWzUGBls+ZFMwlRtBsfWHpCq4pkualS89ZDF8VOOO6Sk2SpZqnHcyYYAqxRgeZZ7LYktSj6Kel4WivDliGED2pluVSDS9NK3ciScLTs9wufZS7cy7S5X/dWvZsS4skclVeh8pRZa5uVqjkDg/C3q36lSBA1D0L7sfskDcEWpM3/g1eoH2bhLeTCjtPvE4YEgUA3iVKgg+GL6BwdvHr+E4eDFr4jQOE+pTj4yoUI0ZlPPAC0Yku6fZ5RNNS5ho3uCPX91MDgI2R2qXH9w6ahNB0lkxW3wPumPTx3KQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(136003)(346002)(66446008)(966005)(64756008)(478600001)(66946007)(66556008)(76116006)(66476007)(26005)(91956017)(36756003)(8676002)(86362001)(55236004)(186003)(8936002)(4326008)(6506007)(7416002)(54906003)(6512007)(2906002)(6486002)(316002)(5660300002)(83380400001)(6916009)(71200400001)(1076003)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: nMrvNiwBMYFs+Yra8qvuEnvpQFNwUTqUMB5yIADK7DlJs6Jc5DyDf/J3j8B/jgMB0oTIytyO41THHHVjDKWc8Sl7Do7V47LeIrrH7Kc5sN0q+ASTsvQEOx3my/3j8cR2mtOTby9CBR5FNBU+XQNdSVpRhdRVmexGp9yJYqCnEvtg5C32BOhSIhVuN6HW8sEivq5OLL539+803OP/AI8fJChNhn/rJAOiI/ZgEfzASZNFb2Vm6ijnVm4uhx94UCmM82OHQ7iNLPQwa8XHNm7PvSMac2uGKQ+TE6WHPlhVkMV+zUBCcamTvovHeRUXyMvZu9/tYqDt9SVRq9lmBlbFVm+i6gNRYC3e5bk6qcIcA4b84ZfW3BxSIgW8Jhou59aGhd2NcRvLn/3L6YCJ9/6+GzIrNDCNZdwoyLPjrBw9Y0It4RpywaSPMLLsbRCI0KXnvv773smjmCSm4yNyO5vxwMmcDbKqGwvczToVPgSPnWI= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6a8effd-d698-4e8e-51e5-08d80e66b525 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 00:22:36.0100 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2bgeTHoKzXiG9OEvH2xASuSqbtxwdOapmy6UaZ+5tQuL118Nr4Dt5xMw+6fSi9O8qjKupn7DPWKEP6vfD752yHUz/ewN/kAxKgVg4Bj2L2w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB2654 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich , Volodymyr Babchuk , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" There was number of discussions about fair scheduling, including latest one at [1]. In a nutshell, schedulers don't know when pCPU is doing guest-related work or when it is busy with something else, like running tasklets. All time spent between two calls to schedule() is being charged to active vCPU, which can be unfair in some cases. Andrii Anisov tried to overcome this by counting time spent in different "modes". But his approach was "entry.S-centric". He tried to guess correct trap reason as early as possible. This was arm-specific and quite intrusive. On other hand, it theoretically provided more precise results. As a result of that discussion with Dario at [1], we came to conclusion that for in the first approximation we should not charge guests for time spent in do_IRQ() and in do_softirq(). This patch series does exactly this. It separately collects time for IRQ handling and for internal hypervisor tasks. Actually, this separation is not needed for making scheduling decisions, but it can prove more information to system administrators. This is minimal implementation, so it supports only x86 and credit2 scheduler. I chose x86 over ARM because more people can try this patches. This series provide tracing and xentop support as well, to ease up experimenting. I'm open to all suggestions, especially for naming things :) Those patches also can be pulled from my GH account at [2] [1] https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00092.h= tml [2] https://github.com/lorc/xen/tree/fair_sched_rfc_v1 Volodymyr Babchuk (6): sched: track time spent in IRQ handler sched: track time spent in hypervisor tasks sched, credit2: improve scheduler fairness xentop: collect IRQ and HYP time statistics. tools: xentop: show time spent in IRQ and HYP states. trace: add fair scheduling trace events tools/xenstat/libxenstat/src/xenstat.c | 12 +++ tools/xenstat/libxenstat/src/xenstat.h | 6 ++ tools/xenstat/libxenstat/src/xenstat_priv.h | 2 + tools/xenstat/xentop/xentop.c | 54 ++++++++-- tools/xentrace/xenalyze.c | 37 +++++++ xen/arch/arm/irq.c | 2 + xen/arch/x86/irq.c | 2 + xen/common/sched/core.c | 110 ++++++++++++++++++++ xen/common/sched/credit2.c | 2 +- xen/common/sched/private.h | 10 ++ xen/common/softirq.c | 2 + xen/common/sysctl.c | 1 + xen/include/public/sysctl.h | 4 +- xen/include/public/trace.h | 5 + xen/include/xen/sched.h | 29 ++++++ 15 files changed, 265 insertions(+), 13 deletions(-) --=20 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 00:23:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 00:23:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXT5-0007Mu-4m; Fri, 12 Jun 2020 00:22:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXT4-0007MF-6t for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 00:22:46 +0000 X-Inumbo-ID: d401da06-ac42-11ea-b594-12813bfff9fa Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.89]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d401da06-ac42-11ea-b594-12813bfff9fa; Fri, 12 Jun 2020 00:22:41 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jo9NyPPpKEn+J8Voeiv3iGJVohkKdj4IWKAB+DnRIkFLM0GTps00q98t8AbRURO1mbF77azVaagcAoklvK1sSy5VuGl4X8qO7nju8QHFRqpxMLgLymcIZGLmCntv9oU5aj94EXaNniT296MpT5eFK0T1A8xVkwKjtRvqhMBgJWdaZwmP0HgMh+6iePT1e/tdim0ESe3D3bu4qIRdx/7xEzM+YL516PDMds3mI/fuX4PyXi8fdjqKdnldzTsWIlAPLbGX4pPAu4meZYTTF3hobGtOlXjYVak7puwtRGLiLHBF6nRcr4hMZNYxRmNCR361efJkqqVJmQ4ZuJcz/ZLn+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5kLqXND8iIZTqE5y3gEpFrrEeZngnuQJdxwT84/FVNk=; b=hYtBRad60UC73911tFjnOdEa+2150Fg3x9OMkfBzc3IV7D0WcGNSYraIHbYQCnMLW04Cnt+2kx62ibjurpFL2v9KtuZnDkCHkruS1mQ6E0KZAmAbH/Gr5neKRlpiO7YqYd1JI2wX5kzuUMQVnEd9o/8xOLCtCao6CqcxsKpGwOowNlu2vHlwcgUZkj6UfjlAWTu4mitAFPp5Y3YgE9dTVBh+Z4GEi4PyYRYkR7Z4uC+NOKEWLaKnPoEEN2IZZsJZhZKSxTxEMAEv8d9WvzR7GvQYKH9f+z0N92cuO2dLp2NNLWmy9zyuNToZFa9wCe4FHU3dlOPnCfT8nHkX4RUS2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5kLqXND8iIZTqE5y3gEpFrrEeZngnuQJdxwT84/FVNk=; b=3aroGyhRoiUXnrA8zoEiBjScWWCWvDFx7r+MhI1yPCFfzTgZ4zKc1bSEEaW5nZMYwLvFx9vCvz7TXBDokwai/xwQBPB0zp+I5ZI2lOsF2VcJrRqvTqUty5+yNe8hr06tFHOuhzjxS5v26m7bhQiTCWML6A2JF8x0PfCWLTJt5/bGKivAixFzj0Mx5VYMKHkGU7bblgZYcRgwbLrHus2h0vdbl3xVcAf0W6a4B8z4b6mfRvSuq72b1AUcS2e1O0hktYaTl1sAdRbkVBrhmzsL1TrjQEgSnOovbQe72h7uSZ/9Ss2PkDYvYzj0WyKFmwgoL5PP6I/lMfmP66JRTRk3wA== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB2654.eurprd03.prod.outlook.com (2603:10a6:800:e0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 00:22:37 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.018; Fri, 12 Jun 2020 00:22:37 +0000 From: Volodymyr Babchuk To: "xen-devel@lists.xenproject.org" Subject: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks Thread-Topic: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks Thread-Index: AQHWQE+SUtF98x/3akmRxwBff1s+mw== Date: Fri, 12 Jun 2020 00:22:36 +0000 Message-ID: <20200612002205.174295-3-volodymyr_babchuk@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> In-Reply-To: <20200612002205.174295-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6defc929-7bcc-49ef-5dcb-08d80e66b5b4 x-ms-traffictypediagnostic: VI1PR0302MB2654: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: x1+xAcMfAXSvFiQX8tqHfR67YXzSp0qQY+JrI8vrE1QDS8ZmLsi+zvyOY4QuEqWslt3TbnoI74whZN7vZsoM3SCQWnKauFoIs6q5VB1Ob2Z1DyXhb/Ivi2nPR+9pEiOADj1FUULp/g1XZEgAgkd8ME9f8ZGeYEIgYjmF9wcGqyTqtDeOghHA4RuOyh73HW4j/4rVNRe/swfpAUhyrIsaBHvSBp4OBGDt4hvNsOmCU7ItIQYMu+ly6MUezan6JAgvp8APxk+isDAlfd5dw4PkMIJ/o6KB4h+xFbRr8psuvr49sFL3uG8MWY1jol/3ocdXb952rWTYdBOFyLMnZkJT6Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(136003)(346002)(66446008)(64756008)(478600001)(66946007)(66556008)(76116006)(66476007)(26005)(91956017)(36756003)(8676002)(86362001)(55236004)(186003)(8936002)(4326008)(6506007)(54906003)(6512007)(2906002)(6486002)(316002)(5660300002)(83380400001)(6916009)(71200400001)(1076003)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fazK2nhL2+zYI8zNGHh+oRHoCK01Nb1SRwRu6hAp1gbhcvKwv6DvzmKuuEY29l70yE/jwh6j4NmuomG8mpwX0oH+5fMWMj5PKyi/K7pawWmOmpiE0173QUkPuYAyWrK4+FoG8pxTCu2tSrIFqDn5h75WcZyHdHT+BmHklivHKvQkNMKWwEJVQ4249MPGoqZYjPEBXolnOAi6f8t5feCUctNiamkV8sqRaTTX9VQPCAwyAjtxeRmmTAIWGrYXP3+dIRFLEsgpYMSzll4WTcBm7eeUfHhbSc0M5pzk7fNUAiunCnCItaTqNjvp4O8qJnvwcarbd3e8ol4ZqUmpSg7PkGL8duw+6sZZZCp8mKeLV9GTosbXQqwZ0Obsvwp63RS9/8hYVArm3hcq4qAgLNqFnXyrFYiLJOV5wzPVrj5YHArf8OZ/C6/E+yN6Iv+OOW1ngBiqAKGE0DSHXWAsfp8mkwdSNYu47illWy6PxrWxUZ0= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6defc929-7bcc-49ef-5dcb-08d80e66b5b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 00:22:36.6637 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oF7wcJr5jLlKnmkhhLRDCZY73ubGoERNa5aD1tl/ppUX00kRfiFW8opx13jBOm8zZBmGlDIIzIZQD6vv31vkLy0JxW8us1g56LZZa037mS8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB2654 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In most cases hypervisor code performs guest-related jobs. Tasks like hypercall handling or MMIO access emulation are done for calling vCPU so it is okay to charge time spent in hypervisor to the current vCPU. But, there are also tasks that are not originated from guests. This includes things like TLB flushing or running tasklets. We don't want to track time spent in this tasks to a total scheduling unit run time. So we need to track time spent in such housekeeping tasks separately. Those hypervisor tasks are run in do_softirq() function, so we'll install our hooks there. TODO: This change is not tested on ARM, and probably we'll get a failing assertion there. This is because ARM code exits from schedule() and have chance to get to end of do_softirq(). Signed-off-by: Volodymyr Babchuk --- xen/common/sched/core.c | 32 ++++++++++++++++++++++++++++++++ xen/common/softirq.c | 2 ++ xen/include/xen/sched.h | 16 +++++++++++++++- 3 files changed, 49 insertions(+), 1 deletion(-) diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c index 8f642ada05..d597811fef 100644 --- a/xen/common/sched/core.c +++ b/xen/common/sched/core.c @@ -945,6 +945,37 @@ void vcpu_end_irq_handler(void) atomic_add(delta, ¤t->sched_unit->irq_time); } =20 +void vcpu_begin_hyp_task(struct vcpu *v) +{ + if ( is_idle_vcpu(v) ) + return; + + ASSERT(!v->in_hyp_task); + + v->hyp_entry_time =3D NOW(); +#ifndef NDEBUG + v->in_hyp_task =3D true; +#endif +} + +void vcpu_end_hyp_task(struct vcpu *v) +{ + int delta; + + if ( is_idle_vcpu(v) ) + return; + + ASSERT(v->in_hyp_task); + + /* We assume that hypervisor task time will not overflow int */ + delta =3D NOW() - v->hyp_entry_time; + atomic_add(delta, &v->sched_unit->hyp_time); + +#ifndef NDEBUG + v->in_hyp_task =3D false; +#endif +} + /* * Do the actual movement of an unit from old to new CPU. Locks for *both* * CPUs needs to have been taken already when calling this! @@ -2615,6 +2646,7 @@ static void schedule(void) =20 SCHED_STAT_CRANK(sched_run); =20 + vcpu_end_hyp_task(current); rcu_read_lock(&sched_res_rculock); =20 lock =3D pcpu_schedule_lock_irq(cpu); diff --git a/xen/common/softirq.c b/xen/common/softirq.c index 063e93cbe3..03a29384d1 100644 --- a/xen/common/softirq.c +++ b/xen/common/softirq.c @@ -71,7 +71,9 @@ void process_pending_softirqs(void) void do_softirq(void) { ASSERT_NOT_IN_ATOMIC(); + vcpu_begin_hyp_task(current); __do_softirq(0); + vcpu_end_hyp_task(current); } =20 void open_softirq(int nr, softirq_handler handler) diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index ceed53364b..51dc7c4551 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -239,7 +239,12 @@ struct vcpu =20 /* Fair scheduling state */ uint64_t irq_entry_time; + uint64_t hyp_entry_time; unsigned int irq_nesting; +#ifndef NDEBUG + bool in_hyp_task; +#endif + /* Tasklet for continue_hypercall_on_cpu(). */ struct tasklet continue_hypercall_tasklet; =20 @@ -279,8 +284,9 @@ struct sched_unit { /* Vcpu state summary. */ unsigned int runstate_cnt[4]; =20 - /* Fair scheduling correction value */ + /* Fair scheduling correction values */ atomic_t irq_time; + atomic_t hyp_time; =20 /* Bitmask of CPUs on which this VCPU may run. */ cpumask_var_t cpu_hard_affinity; @@ -703,6 +709,14 @@ void vcpu_sleep_sync(struct vcpu *v); void vcpu_begin_irq_handler(void); void vcpu_end_irq_handler(void); =20 +/* + * Report to scheduler when we are doing housekeeping tasks on the + * current vcpu. This is called during do_softirq() but can be called + * anywhere else. + */ +void vcpu_begin_hyp_task(struct vcpu *v); +void vcpu_end_hyp_task(struct vcpu *v); + /* * Force synchronisation of given VCPU's state. If it is currently desched= uled, * this call will ensure that all its state is committed to memory and tha= t --=20 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 00:23:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 00:23:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXTF-0007ON-ML; Fri, 12 Jun 2020 00:22:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXTE-0007MF-7D for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 00:22:56 +0000 X-Inumbo-ID: d401da07-ac42-11ea-b594-12813bfff9fa Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.89]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d401da07-ac42-11ea-b594-12813bfff9fa; Fri, 12 Jun 2020 00:22:42 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RpWMGfCCZSJVSokHiAz8NWVDcBgkjz0dIICBn7VgaTItnZcYdpCeYii+awqDg+i5lDsMNCTIxtULcbjNNVsheQ1n6+besrDP3IkrJu4pbYGEWmA6MCxn9Citd4Uq1nGv5TfnhD+YlshYKtJeOP2rk/quiNo/7uHaXAtz4xLQ7SKFJSCnRJT89y9LdO1XGx8hqUiJg65PEQCb0JhBI/KuB9GBLStcZErKQH5HgRMJxyplJHAxnfuvyQYejWtGpx70XGMM8SjKWhLwzeVTkYBxyEFy6ys1Pe2ZNokHr2yzEQb9205vcqPc8rI7j2n3H/p5LABA+GKm66o/aF9W/za0eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/q3vwR74SO4t+n7E/mQzwfg4LX6JiGo9tkrL9EGFJ4=; b=Fqy3ZLqxZ/pm1El9ahfddqktqa46HX0Ywo3QBPVIU94yllz/Y9YOiLIulPUdTRUzkBOP7kmV64dhz3slmYTQuG+6JASpXHG00hUzidQYhKZt/VglXVB/y2dgWPmlcKjyAYQtoUTZKrkO6SUpP1PNzeFXzlgbwpA2DcSqnopooHI3sbQgYZoYzQ6laaHqvKAMAGC+PyxHCFckXAnBHsSonS78CjkUf5LTy24ifzzByXr6gYwk9RjYvpF/bx47n6nEyVwC2VM4U2IqZDcQFFUPC4S6nP4mJPy8lIFRK9NW6jDCCJyYh7Ln9sXJsOUOMcbYE51Xv6/KE0gx4ai5dYmoxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/q3vwR74SO4t+n7E/mQzwfg4LX6JiGo9tkrL9EGFJ4=; b=GaFBPZzhl2MwDnOsG9G+k9TNiApNWnl65zjLNOlneqtv6icQ16qMaHibdtxMhaWnTwyup7L5FVmtsBELux5/fiQz2aaPJK+0a16o8Fghw82ufZFaoRayTjREdwgZlCaMnD/OiPcx2vpsgFpyWnS+vWX+3rG+Svsj5/jhNiJKj60Ho1H7zFsjXZ86V2kC6AzKLkJ+/CnGcjzZuSTvvjMEY8cZGOoQg0YmHb0OlTwyrOH/mZxS9VIyM5rzXiMFAgpP8XZTxO76AepBychP5abbDhqeW638QGhxIy7LdFF2AYpO+4S9veGYV6TAWkCQUY89h5oDYgnlXxFCil8meKtpEA== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB2654.eurprd03.prod.outlook.com (2603:10a6:800:e0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 00:22:37 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.018; Fri, 12 Jun 2020 00:22:37 +0000 From: Volodymyr Babchuk To: "xen-devel@lists.xenproject.org" Subject: [RFC PATCH v1 3/6] sched, credit2: improve scheduler fairness Thread-Topic: [RFC PATCH v1 3/6] sched, credit2: improve scheduler fairness Thread-Index: AQHWQE+TBfX1MPdkGkC6vJ7ur/uY5A== Date: Fri, 12 Jun 2020 00:22:36 +0000 Message-ID: <20200612002205.174295-4-volodymyr_babchuk@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> In-Reply-To: <20200612002205.174295-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: de4db258-52dd-4a6d-14f8-08d80e66b5e6 x-ms-traffictypediagnostic: VI1PR0302MB2654: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:249; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MST4SVLzE67xLf4DmB6pbDIntKiMPc29u+C5QgOqr/3L8YM2uwcxfj8HwSM1RrwWwmeybo+xty+KUU8vW4QBthBV8u6HRwTiEm5eDaKNzP58RpGIg9a5oxvLZJWs44G8NcTlMFo1GdEOT8KgzexWzxAfKi1v74UT9uQ/WNRDlIzVJsEL44xDXGQlR5xP1wH/JMpSTp6urY1qLew3HT23+Zsl4lhoPj1XqOAGtjXVyFKvaSOdfAb85i1pAAry9/X78FYqTJ1Ao53BCZAUJCkatRHPUA1K5+JvCnoIIoSJ5aAP5G/hqsiezNrrpq9hmAnu x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(136003)(346002)(66446008)(64756008)(478600001)(66946007)(66556008)(76116006)(66476007)(26005)(91956017)(36756003)(8676002)(86362001)(55236004)(186003)(8936002)(4326008)(6506007)(54906003)(6512007)(2906002)(6486002)(316002)(5660300002)(83380400001)(6916009)(71200400001)(1076003)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 8RLhe3RMRbjQT8lwxVw2mQ4vDohuoTAqS9JK4p2KTlYWKGYRZlfougZneij4TSNmVjZ/zb0ccbJjmVVcnYeqUqtLCxc8OKhI0GnOGzzm2qF0F5MOiI0uXErNIegCADFdTl7OW31RfaDt3N5ya46Gz2NGazabwC3TfU6b57/tlRczk7Xh1r/N8db76bCdRVseoWy94m9xnxG4dxCCwEWv4nABVWlwR9hTwJRWSYODMZkDjvL0+ks0Aiwa6R9sHvfRF2Dq2xiYGIahoToTjFca0lwhu1BUAHvYhigpmZ/9DK/NgrkgXPE9yestkqq/jPS5GXC9h+KWy4VrjTL3S1XUUnavzwQYYWJSshMZCkdyMuOmksfa6PVykG5v2y5u7+xnAZtzlDPIrFjwGAxDEBIpXe7Ui4az3jCc1kdlPV8+qXsT/LEXNjqGIgzRnGvZeuxjGiwhfG1btjuk17X902GLynVsi+tB3pmdJPtZQdTQUKs= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: de4db258-52dd-4a6d-14f8-08d80e66b5e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 00:22:36.9255 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GA0TCH7Ztw0IguOTKlSCcOSNU3bchUtqDPJEDwkZedpLtOh/BDZlWtFmD6uF3QJrq+Dw7I5O9/SDdZgIxeKg0t75I5qvP2A58UeyLYNPkg0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB2654 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Volodymyr Babchuk , George Dunlap , Dario Faggioli Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Now we can make corrections for scheduling unit run time, based on data gathered in previous patches. This includes time spent in IRQ handlers and time spent for hypervisor housekeeping tasks. Those time spans needs to be deduced from a total run time. This patch adds sched_get_time_correction() function which returns time correction value. This value should be subtracted by a scheduler implementation from a total vCPU/shced_unit run time. TODO: Make the corresponding changes to all other schedulers. Signed-off-by: Volodymyr Babchuk --- xen/common/sched/core.c | 23 +++++++++++++++++++++++ xen/common/sched/credit2.c | 2 +- xen/common/sched/private.h | 10 ++++++++++ 3 files changed, 34 insertions(+), 1 deletion(-) diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c index d597811fef..a7294ff5c3 100644 --- a/xen/common/sched/core.c +++ b/xen/common/sched/core.c @@ -974,6 +974,29 @@ void vcpu_end_hyp_task(struct vcpu *v) #ifndef NDEBUG v->in_hyp_task =3D false; #endif + +s_time_t sched_get_time_correction(struct sched_unit *u) +{ + unsigned long flags; + int irq, hyp; + + while ( true ) + { + irq =3D atomic_read(&u->irq_time); + if ( likely( irq =3D=3D atomic_cmpxchg(&u->irq_time, irq, 0)) ) + break; + } + + while ( true ) + { + hyp =3D atomic_read(&u->hyp_time); + if ( likely( hyp =3D=3D atomic_cmpxchg(&u->hyp_time, hyp, 0)) ) + break; + } + + return irq + hyp; +} + } =20 /* diff --git a/xen/common/sched/credit2.c b/xen/common/sched/credit2.c index 34f05c3e2a..7a0aca078b 100644 --- a/xen/common/sched/credit2.c +++ b/xen/common/sched/credit2.c @@ -1722,7 +1722,7 @@ void burn_credits(struct csched2_runqueue_data *rqd, return; } =20 - delta =3D now - svc->start_time; + delta =3D now - svc->start_time - sched_get_time_correction(svc->unit)= ; =20 if ( unlikely(delta <=3D 0) ) { diff --git a/xen/common/sched/private.h b/xen/common/sched/private.h index b9a5b4c01c..3f4859ce23 100644 --- a/xen/common/sched/private.h +++ b/xen/common/sched/private.h @@ -604,4 +604,14 @@ void cpupool_put(struct cpupool *pool); int cpupool_add_domain(struct domain *d, int poolid); void cpupool_rm_domain(struct domain *d); =20 +/* + * Get amount of time spent doing non-guest related work on + * current scheduling unit. This includes time spent in soft IRQs + * and in hardware interrupt handlers. + * + * Call to this function resets the counters, so it is supposed to + * be called when scheduler calculates time used by the scheduling + * unit. + */ +s_time_t sched_get_time_correction(struct sched_unit *u); #endif /* __XEN_SCHED_IF_H__ */ --=20 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 00:23:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 00:23:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXTK-0007QC-3c; Fri, 12 Jun 2020 00:23:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXTJ-0007MF-7C for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 00:23:01 +0000 X-Inumbo-ID: d4c65386-ac42-11ea-b594-12813bfff9fa Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.49]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d4c65386-ac42-11ea-b594-12813bfff9fa; Fri, 12 Jun 2020 00:22:42 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vnqa+hG5vBpP5PV2b7uIX+OWR91yp8O1vutZIGwzUvcUs722S8ipAWzMIpFsJmotvH+VFtOPsUmoFf8Xqndg7H8DHVLphgcWtrBSKfk0w9KLiLC25TxfWJ+drA6xbTcFev06X7LY3OjYvxQz7ht3FdfbcU5W7DJP9Cj6sV6jlsUncLVCZ2W9WriY5ny65zoMW1rSxOZwaKWKUL7yAm2E5o7WvXq+Eh+f/eaSo0h/ZM/NFTQ1zjSYdMKh+VdW0mYunXOAsUJhgbesV5UYk/S1u9Pu9H2OJ1VoQ+XEz6yb/ghAIsqsYjreJm5qH3iR82LCFWYfz/jaLCBW5v8CcroKZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rPxSP0GQhjiILc2BkcY4EKDjsGfYhx91tgpTPBpzd0E=; b=f3HvGdIATHStrX5gc1XIHNo09QVKiguk+5YXsR0WR2do7f8MP2HrbpeoKTb59yZ8JFIFJUO423CvOGX9/k4wB7P9jR6bS4Y09tNw/5ZAr0bV4BGVWfJzSFj/zbGjNvjHqiclsZ+zju5USHPmpR0uzvHgqHAt7HYlTie/Fbg/JrnVq6iTz79y8rZI7rB/UqbR0Fdw5gHUbLXlcdYew+H5Sp3tOBJGwVwsMApAXwjYNsPYfwy8sCQym67y9qoBias/UOntIqaD7J8gTUMZ79w14ABHV4BF2z2hAZFJIM8U0pTdt1IbTZr0hk3Numd7uz8Mknv96SQtdY7bKqgaCFc+0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rPxSP0GQhjiILc2BkcY4EKDjsGfYhx91tgpTPBpzd0E=; b=CJZu8c2VGLi4KiNmikSF9I77XgmqSKXjcnOFNqsk+6NWA1oYdyULczjbrNgIX62/fx5VXiWuY6BYj3sOim7sf4g8do1JYvmUl1/cf0R39aU4GUnTHCTkhzhJ/rz/xgiCJshxBWzPYzHooWXPv70PQLBR64Pg+p/80omFWn6ooY++vMFXAS362wODCKTKd0fB0LO/dNWIjKAdJeDMJN3gF0Wx68qk08Yao1tByz6DNvPe3mysp2qgyb6ADLVvct8jyqFV+ZXpe6FAsX7m9iZ8m5HzD8Gzf35qgxLXJHddbRfphpVWv9Y8kTn0Sj2oycJSmIT7gOT4npdApJG0tEkrwA== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB2654.eurprd03.prod.outlook.com (2603:10a6:800:e0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 00:22:37 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.018; Fri, 12 Jun 2020 00:22:37 +0000 From: Volodymyr Babchuk To: "xen-devel@lists.xenproject.org" Subject: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Topic: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Index: AQHWQE+Tib/gTK49mk6bUudd1VvXZg== Date: Fri, 12 Jun 2020 00:22:37 +0000 Message-ID: <20200612002205.174295-5-volodymyr_babchuk@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> In-Reply-To: <20200612002205.174295-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 23a7788d-bd81-4360-1a38-08d80e66b618 x-ms-traffictypediagnostic: VI1PR0302MB2654: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:185; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +WG4zCDKubqHVW8Wsa/b4Nt1wx9y59jcWALTg2ZV2P3zyhTI9J3GWnPGbDsCXruFJ50Sb9VsowieBaQdC7AKQEfGgyINj2aAUmpo3Pjs//BoB1UWKfmVOcDBOT7l/6gPhkyV/MKKkM6COFnuv/Xyj2rAwJJGn4yNA/P1vHsBr7q4UBj3zPLWJFAypWpQQWTrmiFxz1V1Ze2XiLeRIxZ8Zq+t57GNe7FphI7zB6mrV6D6470uLI81u5ArfEa3ZzAl4vSgMRvwTPHOAtGytJuKbjnq6ZP+UPtac1hzF1SPNvvi0Ew3gYfPZJcSbYiF8Hpe5TDZPO6ORkI3IDJoftW96A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(136003)(346002)(66446008)(64756008)(478600001)(66946007)(66556008)(76116006)(66476007)(26005)(91956017)(36756003)(8676002)(86362001)(55236004)(186003)(8936002)(4326008)(6506007)(54906003)(6512007)(2906002)(6486002)(316002)(5660300002)(83380400001)(6916009)(71200400001)(1076003)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0QYbbdXA4WK1wngTahjcoICVN1QSbFF3wx/kayfpEoemoIHHwaHVfVcDez3KBF/XxTOhCJFEtmK8N3IdQ5D0h+I24NIyV9BRMsnPD7QxhlYfOCdOvAuL9HZRCh8tvFM6PhVF5Y0iih2HLOD56GzMaUYzaWBDY6/q9WBlL7+xb5IORnGWb8PC8OV+tP1aZBGRTxsMVNoi2TUh8mnGG4zuzpnh5KvbTAFsFzbhXAyq/CPMbTkhYE4g47//gs2mjChYUurusFmXO0+pf4n/lEqVwRe36NEwgqbfKYvZzO4b3s8KuwHJUGcSeBWQS8yXalKrAC8V4jXoDZLJrxiEnJnUkWOaEAMzDlPzKjUuXQgqBRfpwgV4gg/9mA74CtvLWesmKv0P/hG9DUVtIBXKY27m5+F8hfK/A1us2bhKUTM6Una2yIBdgr/cYE6zCUYlerpOHXQy8fW+Cvr1j1A/+7Yjhn8T78ghHAUZt5P4siIZ2xk= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 23a7788d-bd81-4360-1a38-08d80e66b618 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 00:22:37.2004 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oUl+MaUevMcx4U4o4FvHJXKlzBRK1w6bNGAYD9sp1vGyIupugNLr2PZ6qmJk6wLxf2bTn4MjtG6wDs+fg6i0ZQCf4QYOv4InTbK9VnQ5iKM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB2654 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" As scheduler code now collects time spent in IRQ handlers and in do_softirq(), we can present those values to userspace tools like xentop, so system administrator can see how system behaves. We are updating counters only in sched_get_time_correction() function to minimize number of taken spinlocks. As atomic_t is 32 bit wide, it is not enough to store time with nanosecond precision. So we need to use 64 bit variables and protect them with spinlock. Signed-off-by: Volodymyr Babchuk --- xen/common/sched/core.c | 17 +++++++++++++++++ xen/common/sysctl.c | 1 + xen/include/public/sysctl.h | 4 +++- xen/include/xen/sched.h | 2 ++ 4 files changed, 23 insertions(+), 1 deletion(-) diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c index a7294ff5c3..ee6b1d9161 100644 --- a/xen/common/sched/core.c +++ b/xen/common/sched/core.c @@ -95,6 +95,10 @@ static struct scheduler __read_mostly ops; =20 static bool scheduler_active; =20 +static DEFINE_SPINLOCK(sched_stat_lock); +s_time_t sched_stat_irq_time; +s_time_t sched_stat_hyp_time; + static void sched_set_affinity( struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft)= ; =20 @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct sched_unit *= u) break; } =20 + spin_lock_irqsave(&sched_stat_lock, flags); + sched_stat_irq_time +=3D irq; + sched_stat_hyp_time +=3D hyp; + spin_unlock_irqrestore(&sched_stat_lock, flags); + return irq + hyp; } =20 +void sched_get_time_stats(uint64_t *irq_time, uint64_t *hyp_time) +{ + unsigned long flags; + + spin_lock_irqsave(&sched_stat_lock, flags); + *irq_time =3D sched_stat_irq_time; + *hyp_time =3D sched_stat_hyp_time; + spin_unlock_irqrestore(&sched_stat_lock, flags); } =20 /* diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index 1c6a817476..00683bc93f 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -270,6 +270,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_s= ysctl) pi->scrub_pages =3D 0; pi->cpu_khz =3D cpu_khz; pi->max_mfn =3D get_upper_mfn_bound(); + sched_get_time_stats(&pi->irq_time, &pi->hyp_time); arch_do_physinfo(pi); if ( iommu_enabled ) { diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h index 3a08c512e8..f320144d40 100644 --- a/xen/include/public/sysctl.h +++ b/xen/include/public/sysctl.h @@ -35,7 +35,7 @@ #include "domctl.h" #include "physdev.h" =20 -#define XEN_SYSCTL_INTERFACE_VERSION 0x00000013 +#define XEN_SYSCTL_INTERFACE_VERSION 0x00000014 =20 /* * Read console content from Xen buffer ring. @@ -118,6 +118,8 @@ struct xen_sysctl_physinfo { uint64_aligned_t scrub_pages; uint64_aligned_t outstanding_pages; uint64_aligned_t max_mfn; /* Largest possible MFN on this host */ + uint64_aligned_t irq_time; + uint64_aligned_t hyp_time; uint32_t hw_cap[8]; }; =20 diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 51dc7c4551..869d4efbd6 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -717,6 +717,8 @@ void vcpu_end_irq_handler(void); void vcpu_begin_hyp_task(struct vcpu *v); void vcpu_end_hyp_task(struct vcpu *v); =20 +void sched_get_time_stats(uint64_t *irq_time, uint64_t *hyp_time); + /* * Force synchronisation of given VCPU's state. If it is currently desched= uled, * this call will ensure that all its state is committed to memory and tha= t --=20 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 00:23:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 00:23:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXTU-0007VO-LX; Fri, 12 Jun 2020 00:23:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXTT-0007MF-7V for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 00:23:11 +0000 X-Inumbo-ID: d4c65387-ac42-11ea-b594-12813bfff9fa Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.49]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d4c65387-ac42-11ea-b594-12813bfff9fa; Fri, 12 Jun 2020 00:22:43 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S1FRzIwqi8MaiPpQT0ukz+r83Mutf9qp8uoEL+e+gOb8FaYY5jZIsqJ1hyPwyNwn0mQCfz7AV8cCKNrg/tQ3lavNSYPbgn0g/yw0aG6Ww8CBY2Il6KU82KvDMwSemkPBqlWgLVOQotkjqNT7t2+m/nqwt0W5rCPwdv2JyEqeii4thZOW6D/iTJrQto2KSWCK4n06IzMNgFY+6NykQOeI54QWWU83EV6QqzFZAJGPM40N+lnHKofjrAwJrqRSoJrPSka/g/Von1fzZjuwIR6HKPMDmRaDCuZ50s34WbkDDlxps40x2TtLUvzBVwOxQOhVibXvrsS4H08LkzKD0Ydpfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JFyM2tlxS7owCAmfGeZffNBhcSzmXAb+/nDqdHLXNkk=; b=oaNEtKE5HJNls9cu54vmsDZRK7MKwPdSlk80tAUbUxgHF6wLbf+flJ98CICp34Web5aYB5C9WP49JLtiP8EFJmtrA5qvCyx2GhwSQRjYLhfUSvya1BrZVmFMvdJ/+nmcsdcn8DzRLm3O9rstH6xa2FmGaLwE5l/EQBCgUdqNSwxg7HRJuUkt6AxkbfOMHoPVIh6vnTbjEQw1Cmfg4FrifBKIIv3nBZqUf5fyRtIrR04NeENHhdCriL+gReDVOR7ghJRQl7oNeDK8kyw4S3NWaJf4wgskorzoHFz2jwT1jN4gjNfKqojt145PDjwgM4ramDfAsccFghSm64dmq48f4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JFyM2tlxS7owCAmfGeZffNBhcSzmXAb+/nDqdHLXNkk=; b=WzoUUqUw+unQHvd2hdNvqdrgF/zIn4qwUTzJ57vReEYJNnijL1FgGRQp29JYmD/MKcbS4x106pzbxQc+I6kN3rADJ73uP6LMns1PDKnBeNQA+lBc5HJuzdRdvD6M6KzrioCjTXAPXTQIvaT4E6cLffq0p+hZy6NDeawSA8JBg0CMcuP5dij8dBm0LlrJrwrgtwINi75bm0+nAfAFBTfhb8keo9fnmNuDZ33xYBCOVQddrmhWeGBu/i9TZcGRZlFwEgWK2dpMlb6OjeluoGFsGR2Y1DV6lQwZlWeCXJyZiH9YnDCSjWsDmYUYtv6079Ejul3Pga3CIphWa4yFmelbAw== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB2654.eurprd03.prod.outlook.com (2603:10a6:800:e0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 00:22:38 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.018; Fri, 12 Jun 2020 00:22:38 +0000 From: Volodymyr Babchuk To: "xen-devel@lists.xenproject.org" Subject: [RFC PATCH v1 5/6] tools: xentop: show time spent in IRQ and HYP states. Thread-Topic: [RFC PATCH v1 5/6] tools: xentop: show time spent in IRQ and HYP states. Thread-Index: AQHWQE+TFzeBItaOmEyTKqcXTMXcTQ== Date: Fri, 12 Jun 2020 00:22:37 +0000 Message-ID: <20200612002205.174295-6-volodymyr_babchuk@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> In-Reply-To: <20200612002205.174295-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 26c3444d-dc48-4175-4685-08d80e66b64a x-ms-traffictypediagnostic: VI1PR0302MB2654: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1284; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3dkx/YE7+OM4uMShWEMttf7KIAQGyTBPVYXYEeHruipcrBRvHQf9VqETR4nJBEaLvfkAvY2s7kzfc8qqQO5Bhv1J7h63hmeW3G5phOZQtLpnnYSffGyFgj9iWXcdsMyGk5Ulio6xVmVfvcXGgjFPbIi/EaQu1o/9SHwedL0DJ44sEfxP4YNiCjIH5ynU8RhPO9HEmsjCPfYDo5UXFtUkpQe/m+WK4mIlGlsyabk90lxsNgA9C0CQfivWaNvfbkgi1QpUiqyyicPKm1cKZ8vEJClhgwXx/6Q6k0DXFZbqoPAy4kJGB2OpvNne4sX5oaevqPt/FNmCIcCLQoSVArCwcw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(136003)(346002)(66446008)(64756008)(478600001)(66946007)(66556008)(76116006)(66476007)(26005)(91956017)(36756003)(8676002)(86362001)(55236004)(186003)(8936002)(4326008)(6506007)(54906003)(6512007)(2906002)(6486002)(316002)(5660300002)(83380400001)(6916009)(71200400001)(1076003)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: bi3L2Rd+Ypak3jw+nmFG5AZ45lMFpRn25AIGmlURXqVTKRIDpoP6nRhkIdXhMmGQnsfJhTQiS4vcH90gi7FBNng302CVEE9rkrPgGVhL0b/4d8nXOF5tor+YPsKaYNROyH5PslvM6parVWwFZwFUSgx/e7Fnu3ufkR7aUeMeNsMrfaiEluTpPW1YW/J0zO0HyBX2nNiJPvL8DoaqgyNalu5stGP7FrAF1Iq1hl0MLcoRP2venprQ/FkOo4q6d9yLBelV2zUeDa07Zb3dX8dSjMqtv9S5RwKZkVPXnD5IiN6fBCeCGrbaUylBZcT+4ky9TmtGNN9+aetnyVoeyxnS8osndmelFwbeYeq/dc1JSU5ufVrv3P2UiuiuMfnwLRR8RS92F6tojcju+/EF4yLc0h46/yUJsfHa7OMq0vwHeehaSSWU3PcKIqTr+e4eRzqcnVUG2SVi+yS3KBtrr5dk31Qz5f2kjh4/kHqsJoPrqB8= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26c3444d-dc48-4175-4685-08d80e66b64a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 00:22:37.5722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kWMZzAL8vjfN53DwivgmgDStxodDGbD9NN3vgiL0qtApBd5BRL1V5okhZx7HL9H0BU4SO8MS/1XiL95tHACPk9He7KDZEjgst3kgkwausnU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB2654 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Volodymyr Babchuk , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" xentop show the values in the header like this: IRQ Time 0.2s 0.0% HYP Time 1.3s 0.1% The first value is the total time spent in corresponding mode, the second value is the instant load percentage, similar to vCPU load value. "IRQ" corresponds to time spent in IRQ handler. "HYP" is the time used by hypervisor for own tasks. Signed-off-by: Volodymyr Babchuk --- tools/xenstat/libxenstat/src/xenstat.c | 12 +++++ tools/xenstat/libxenstat/src/xenstat.h | 6 +++ tools/xenstat/libxenstat/src/xenstat_priv.h | 2 + tools/xenstat/xentop/xentop.c | 54 ++++++++++++++++----- 4 files changed, 63 insertions(+), 11 deletions(-) diff --git a/tools/xenstat/libxenstat/src/xenstat.c b/tools/xenstat/libxens= tat/src/xenstat.c index 6f93d4e982..30c9d3d2cc 100644 --- a/tools/xenstat/libxenstat/src/xenstat.c +++ b/tools/xenstat/libxenstat/src/xenstat.c @@ -162,6 +162,8 @@ xenstat_node *xenstat_get_node(xenstat_handle * handle,= unsigned int flags) node->free_mem =3D ((unsigned long long)physinfo.free_pages) * handle->page_size; =20 + node->irq_time =3D physinfo.irq_time; + node->hyp_time =3D physinfo.hyp_time; node->freeable_mb =3D 0; /* malloc(0) is not portable, so allocate a single domain. This will * be resized below. */ @@ -332,6 +334,16 @@ unsigned long long xenstat_node_cpu_hz(xenstat_node * = node) return node->cpu_hz; } =20 +unsigned long long xenstat_node_irq_time(xenstat_node * node) +{ + return node->irq_time; +} + +unsigned long long xenstat_node_hyp_time(xenstat_node * node) +{ + return node->hyp_time; +} + /* Get the domain ID for this domain */ unsigned xenstat_domain_id(xenstat_domain * domain) { diff --git a/tools/xenstat/libxenstat/src/xenstat.h b/tools/xenstat/libxens= tat/src/xenstat.h index 76a660f321..8d2e561008 100644 --- a/tools/xenstat/libxenstat/src/xenstat.h +++ b/tools/xenstat/libxenstat/src/xenstat.h @@ -80,6 +80,12 @@ unsigned int xenstat_node_num_cpus(xenstat_node * node); /* Get information about the CPU speed */ unsigned long long xenstat_node_cpu_hz(xenstat_node * node); =20 +/* Get information about time spent in IRQ handlers */ +unsigned long long xenstat_node_irq_time(xenstat_node * node); + +/* Get information about time spent doing hypervisor work */ +unsigned long long xenstat_node_hyp_time(xenstat_node * node); + /* * Domain functions - extract information from a xenstat_domain */ diff --git a/tools/xenstat/libxenstat/src/xenstat_priv.h b/tools/xenstat/li= bxenstat/src/xenstat_priv.h index 4eb44a8ebb..d259765593 100644 --- a/tools/xenstat/libxenstat/src/xenstat_priv.h +++ b/tools/xenstat/libxenstat/src/xenstat_priv.h @@ -48,6 +48,8 @@ struct xenstat_node { unsigned long long tot_mem; unsigned long long free_mem; unsigned int num_domains; + unsigned long long irq_time; + unsigned long long hyp_time; xenstat_domain *domains; /* Array of length num_domains */ long freeable_mb; }; diff --git a/tools/xenstat/xentop/xentop.c b/tools/xenstat/xentop/xentop.c index ebed070c0f..aaeba81cd9 100644 --- a/tools/xenstat/xentop/xentop.c +++ b/tools/xenstat/xentop/xentop.c @@ -496,11 +496,25 @@ static void print_cpu(xenstat_domain *domain) print("%10llu", xenstat_domain_cpu_ns(domain)/1000000000); } =20 +/* Helper to calculate CPU load percentage */ +static double calc_time_pct(uint64_t cur_time_ns, uint64_t prev_time_ns) +{ + double us_elapsed; + + /* Calculate the time elapsed in microseconds */ + us_elapsed =3D ((curtime.tv_sec-oldtime.tv_sec)*1000000.0 + +(curtime.tv_usec - oldtime.tv_usec)); + + /* In the following, nanoseconds must be multiplied by 1000.0 to + * convert to microseconds, then divided by 100.0 to get a percentage, + * resulting in a multiplication by 10.0 */ + return ((cur_time_ns - prev_time_ns) / 10.0) / us_elapsed; +} + /* Computes the CPU percentage used for a specified domain */ static double get_cpu_pct(xenstat_domain *domain) { xenstat_domain *old_domain; - double us_elapsed; =20 /* Can't calculate CPU percentage without a previous sample. */ if(prev_node =3D=3D NULL) @@ -510,15 +524,8 @@ static double get_cpu_pct(xenstat_domain *domain) if(old_domain =3D=3D NULL) return 0.0; =20 - /* Calculate the time elapsed in microseconds */ - us_elapsed =3D ((curtime.tv_sec-oldtime.tv_sec)*1000000.0 - +(curtime.tv_usec - oldtime.tv_usec)); - - /* In the following, nanoseconds must be multiplied by 1000.0 to - * convert to microseconds, then divided by 100.0 to get a percentage, - * resulting in a multiplication by 10.0 */ - return ((xenstat_domain_cpu_ns(domain) - -xenstat_domain_cpu_ns(old_domain))/10.0)/us_elapsed; + return calc_time_pct(xenstat_domain_cpu_ns(domain), + xenstat_domain_cpu_ns(old_domain)); } =20 static int compare_cpu_pct(xenstat_domain *domain1, xenstat_domain *domain= 2) @@ -878,6 +885,23 @@ static void print_ssid(xenstat_domain *domain) print("%4u", xenstat_domain_ssid(domain)); } =20 +/* Computes the Xen time stats in percents */ +static void get_xen_time_stats(double *irq_pct, double *hyp_pct) +{ + /* Can't calculate CPU percentage without a previous sample. */ + if(prev_node =3D=3D NULL) + { + *irq_pct =3D 0.0; + *hyp_pct =3D 0.0; + return; + } + + *irq_pct =3D calc_time_pct(xenstat_node_irq_time(cur_node), + xenstat_node_irq_time(prev_node)); + *hyp_pct =3D calc_time_pct(xenstat_node_hyp_time(cur_node), + xenstat_node_hyp_time(prev_node)); +} + /* Resets default_width for fields with potentially large numbers */ void reset_field_widths(void) { @@ -943,6 +967,7 @@ void do_summary(void) crash =3D 0, dying =3D 0, shutdown =3D 0; unsigned i, num_domains =3D 0; unsigned long long used =3D 0; + double irq_pct, hyp_pct; xenstat_domain *domain; time_t curt; =20 @@ -975,9 +1000,16 @@ void do_summary(void) xenstat_node_tot_mem(cur_node)/1024, used/1024, xenstat_node_free_mem(cur_node)/1024); =20 - print("CPUs: %u @ %lluMHz\n", + print("CPUs: %u @ %lluMHz ", xenstat_node_num_cpus(cur_node), xenstat_node_cpu_hz(cur_node)/1000000); + + get_xen_time_stats(&irq_pct, &hyp_pct); + print("IRQ Time %.1fs %6.1f%% HYP Time %.1fs %6.1f%%\n", + xenstat_node_irq_time(cur_node) / 1000000000.0, + irq_pct, + xenstat_node_hyp_time(cur_node) / 1000000000.0, + hyp_pct); } =20 /* Display the top header for the domain table */ --=20 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 00:23:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 00:23:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXTP-0007TI-C5; Fri, 12 Jun 2020 00:23:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjXTO-0007MF-7K for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 00:23:06 +0000 X-Inumbo-ID: d526ac36-ac42-11ea-b594-12813bfff9fa Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.89]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d526ac36-ac42-11ea-b594-12813bfff9fa; Fri, 12 Jun 2020 00:22:43 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TpU3T1x/ikoK34ceEilCbGfH4gsXlZpp6QNPIV3SE9eWByAb1I34vf17B/AhSFSSXA5OM0tBb+vReMd+zQh8tPPsugyXfHljQM7CIpm5RCBXMcRRyRSBTq+ret28CB8NdaJaNgu28ebTkBs3kNHSkQUlH2S5cKLfAK+AUZuiDpuibBwRGhADHf4gFmNcJKaNcNt5whe4Ah1L3CRWbEy5yvcoELkmFOt7MTiLyNd1qb/yoLyDG4D2TA3mZD0c1bx6z1rmm8upnoLKt2xQlcGk7WrgYaSFzfKjY5bkCziRA8lr6XrhuG4d0QXAh+I7MaTuxt7oNmsUXJUAfIOhP80nMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OhQNqLAduYZF/1BUXnFYEz+JT7fMJefrT4kFPEI56d4=; b=E07xBZTxSZ/4SLqRSjiFYywimdCXBo/5kXME1UiL1cBfF/ah3uwYwdCjQRJg4a8nk86va1bfG6SFE9W6DjRey7Np2EiZgzv84iKgfCziPpGFhZzxTufnBXU/5wb+Twd6FYaN5laYc7/ONF9e29PYRTawfdkiTGcJGEZVdS61kduD/a45aeV0PFL0uxb8K0fi6tzbLIlBExTocrIUbgqMjAALxBCQ24gEEO3bPay1C21EajCMkYznTL/QRTCdshkoaNytKYGbPL90pciEF3vtZuqtUf7iplmVcX0KO0CkAkUrzfwnkGuVZm6mv9z24R6lPvPznk5Uf3x3lXFphJ+03w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OhQNqLAduYZF/1BUXnFYEz+JT7fMJefrT4kFPEI56d4=; b=TjkF86XsEXus/Da+pkq5ScryeKBHnJrCS0a+tTYn9iU139MnP6k68xDpJKjoNQR9YhiGSKEPUJzrvTvLsnHjVVdVp9jAKsCZKuYYMBSqQdDGJRVa3ZyYyW2jiRcKFrz4EQounuEpWSNK3ofelas07HyWcDz3dTHw5AhgtOr0SoLw3ER9kJY0w5TMWUxHV8fR9KK9SeDRB7i8znvLw2Eui6aXb5DxH/oHfVMrWIoqPm0UHsXynstBr9xWvvk/kp2LTgiFVwP5Vigvoz/5yMB5Js9LxUkGSr14s6iUH9Rkqo7tlm1OCFoxoffQYBnoJVvBlDyl3zEgdalX0xRm/M5QCg== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB2654.eurprd03.prod.outlook.com (2603:10a6:800:e0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 00:22:38 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.018; Fri, 12 Jun 2020 00:22:38 +0000 From: Volodymyr Babchuk To: "xen-devel@lists.xenproject.org" Subject: [RFC PATCH v1 6/6] trace: add fair scheduling trace events Thread-Topic: [RFC PATCH v1 6/6] trace: add fair scheduling trace events Thread-Index: AQHWQE+TrxaSoGuic062xf5W0YJ0vg== Date: Fri, 12 Jun 2020 00:22:37 +0000 Message-ID: <20200612002205.174295-7-volodymyr_babchuk@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> In-Reply-To: <20200612002205.174295-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7643c403-423d-4a9a-72d3-08d80e66b67c x-ms-traffictypediagnostic: VI1PR0302MB2654: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:50; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X2SG3eldEkEDFpLCJXcdAFMMjpk8lZHC+Za0YD37Wt+ErFwmTpX9pLIAKh/KsLfW0woEFoFlTFltG+deHmOGVhvr0LAuvzv0ILCxksln0Kt76E1auC4iJHoYewnK5+l8DaIka9r/rIyo1xgjBoHPsYf56mrPK5c2Eo9phAuGtYQYyakJGLlDIkmnD/6dJGV9bnH0m/PboLRmZa6sJgDjbVpLPy09Xe+7cZ8L+Yc9mKoeaLWfBV14Uv11dkrLlDMug1ZZmUKhTgWhyJp/fDSlnq2QoskJWZlW1yTwFdIxiCYMqXoCXE2Zr7iTH1s5IMOnuvmmyDQ1/vj49DRglUU0cslJbiEmLAV9MoeOAqMSE4o4WGGOg8+owic2u8fWJ3UU x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(136003)(346002)(66446008)(64756008)(478600001)(66946007)(66556008)(76116006)(66476007)(26005)(91956017)(36756003)(8676002)(86362001)(55236004)(186003)(8936002)(4326008)(6506007)(54906003)(6512007)(2906002)(6486002)(316002)(5660300002)(83380400001)(6916009)(71200400001)(1076003)(2616005)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: X276hooWpkKRPXUz48Ksn0UX+Cch9MGZxn89XRWtxFloRBUQKzrKJKgCnj/+TXfvs2c2SoklIrCrDeZE6RZ763ngaHZRPCIa6xeKVFftM8SmnY5CwOGJ6jpLLmhLHId0zrWad4arUmSgurvZg+evmdF8XspqgYWyaLeJByPGD2wV1c2RsHk0g27m/6N56rmRq3NmIGT5g2UmEAEnFtInZVGS9RgjblugkoRFGoDxriAAr/t2BB7/oEG6gkvPL5qZ7b+UBDUSvO7c/cne00Ah248ZSeyj+3YAgfyICAlUwMpSLXUl++XYqfDHXLuapJ8HWtd4KOz9mujkjSRyBnaM0AvECTmF95KGBNO+b+pKK8LIquh2pRekVvjkD1lWn5b2KnK1zHo8Dv7DNtBAFnRYoo/IXMWERA6tZBgsh0M9kIYWL7cKkPeiMpfj33dwuTdC9HfFQxOP+W/kMZk5nrWWvhF6ESYynPpHsT0tCp3d0GY= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7643c403-423d-4a9a-72d3-08d80e66b67c X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 00:22:37.9310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: urOv9Ezf93ttC7W+llqH8ci9+LtMuiO/8/StYjUvaPWgPcHbA7HVp2tsU+5CqLjNzh+FcPI91eYfTgwDUe8v1GLH5amJpkloQcTV3mIZIgc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB2654 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" We are tracing each IRQ or HYP mode change and the calculated time adjustment values. Signed-off-by: Volodymyr Babchuk --- tools/xentrace/xenalyze.c | 37 +++++++++++++++++++++++++++++++++++++ xen/common/sched/core.c | 9 +++++++++ xen/include/public/trace.h | 5 +++++ 3 files changed, 51 insertions(+) diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c index b7f4e2bea8..bcde830f0e 100644 --- a/tools/xentrace/xenalyze.c +++ b/tools/xentrace/xenalyze.c @@ -7546,6 +7546,43 @@ void sched_process(struct pcpu_info *p) printf("\n"); } break; + case TRC_SCHED_IRQ_ENTRY: + case TRC_SCHED_IRQ_LEAVE: + if(opt.dump_all) + { + struct { + unsigned int nesting; + } *r =3D (typeof(r))ri->d; + + printf(" %s sched_irq_%s nesting =3D %u\n", ri->dump_heade= r, + ri->event =3D=3D TRC_SCHED_IRQ_ENTRY ? "entry":"lea= ve", + r->nesting); + } + break; + case TRC_SCHED_HYP_ENTRY: + case TRC_SCHED_HYP_LEAVE: + if(opt.dump_all) + { + struct { + unsigned int domid, vcpuid; + } *r =3D (typeof(r))ri->d; + + printf(" %s sched_hyp_%s d%uv%u\n", ri->dump_header, + ri->event =3D=3D TRC_SCHED_HYP_ENTRY ? "entry":"lea= ve", + r->domid, r->vcpuid); + } + break; + case TRC_SCHED_TIME_ADJ: + if(opt.dump_all) + { + struct { + unsigned int irq, hyp; + } *r =3D (typeof(r))ri->d; + + printf(" %s sched time adjust IRQ %uns HYP %uns Total %uns= \n", ri->dump_header, + r->irq, r->hyp, r->irq + r->hyp); + } + break; case TRC_SCHED_CTL: case TRC_SCHED_S_TIMER_FN: case TRC_SCHED_T_TIMER_FN: diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c index ee6b1d9161..9e82a6a22b 100644 --- a/xen/common/sched/core.c +++ b/xen/common/sched/core.c @@ -925,6 +925,8 @@ void vcpu_begin_irq_handler(void) if (is_idle_vcpu(current)) return; =20 + TRACE_1D(TRC_SCHED_IRQ_ENTRY, current->irq_nesting); + /* XXX: Looks like ASSERT_INTERRUPTS_DISABLED() is available only for = x86 */ if ( current->irq_nesting++ ) return; @@ -941,6 +943,8 @@ void vcpu_end_irq_handler(void) =20 ASSERT(current->irq_nesting); =20 + TRACE_1D(TRC_SCHED_IRQ_LEAVE, current->irq_nesting - 1); + if ( --current->irq_nesting ) return; =20 @@ -960,6 +964,7 @@ void vcpu_begin_hyp_task(struct vcpu *v) #ifndef NDEBUG v->in_hyp_task =3D true; #endif + TRACE_2D(TRC_SCHED_HYP_ENTRY, v->domain->domain_id, v->vcpu_id); } =20 void vcpu_end_hyp_task(struct vcpu *v) @@ -978,6 +983,8 @@ void vcpu_end_hyp_task(struct vcpu *v) #ifndef NDEBUG v->in_hyp_task =3D false; #endif + TRACE_2D(TRC_SCHED_HYP_LEAVE, v->domain->domain_id, v->vcpu_id); +} =20 s_time_t sched_get_time_correction(struct sched_unit *u) { @@ -1003,6 +1010,8 @@ s_time_t sched_get_time_correction(struct sched_unit = *u) sched_stat_hyp_time +=3D hyp; spin_unlock_irqrestore(&sched_stat_lock, flags); =20 + TRACE_2D(TRC_SCHED_TIME_ADJ, irq, hyp); + return irq + hyp; } =20 diff --git a/xen/include/public/trace.h b/xen/include/public/trace.h index d5fa4aea8d..6161980095 100644 --- a/xen/include/public/trace.h +++ b/xen/include/public/trace.h @@ -117,6 +117,11 @@ #define TRC_SCHED_SWITCH_INFNEXT (TRC_SCHED_VERBOSE + 15) #define TRC_SCHED_SHUTDOWN_CODE (TRC_SCHED_VERBOSE + 16) #define TRC_SCHED_SWITCH_INFCONT (TRC_SCHED_VERBOSE + 17) +#define TRC_SCHED_IRQ_ENTRY (TRC_SCHED_VERBOSE + 18) +#define TRC_SCHED_IRQ_LEAVE (TRC_SCHED_VERBOSE + 19) +#define TRC_SCHED_HYP_ENTRY (TRC_SCHED_VERBOSE + 20) +#define TRC_SCHED_HYP_LEAVE (TRC_SCHED_VERBOSE + 21) +#define TRC_SCHED_TIME_ADJ (TRC_SCHED_VERBOSE + 22) =20 #define TRC_DOM0_DOM_ADD (TRC_DOM0_DOMOPS + 1) #define TRC_DOM0_DOM_REM (TRC_DOM0_DOMOPS + 2) --=20 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 01:09:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 01:09:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjYCB-0003zY-C1; Fri, 12 Jun 2020 01:09:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjYCA-0003zT-I7 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 01:09:22 +0000 X-Inumbo-ID: 592958c0-ac49-11ea-8496-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 592958c0-ac49-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 01:09:22 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DF12120878; Fri, 12 Jun 2020 01:09:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591924161; bh=ZFPRQ8xNw0/VOBd25JGbtR6KBrp91C0nmDUDG2Ufln4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=1v0f8GACW0fvlQwzdzKM1qEDRDklbwON9JH1pl1FMM6mEpMZB32sxKeknRBQ0ySYX f9HuYKjg8tShpXU/Zi7ped0Oj41v7mqOYX0xj2u0JWSTgLDuX1GOs0rCyOANi/hHfd SmqYeT6E/3NyGciATEFtoXXtH7ENHjxJGJJ2s8Qw= Date: Thu, 11 Jun 2020 18:09:20 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall In-Reply-To: <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> Message-ID: References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Bertrand Marquis , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 11 Jun 2020, Julien Grall wrote: > Hi Stefano, > > On 11/06/2020 19:50, Stefano Stabellini wrote: > > On Thu, 11 Jun 2020, Julien Grall wrote: > > > > > + return -EINVAL; > > > > > } > > > > > > > > > > - __copy_to_guest(runstate_guest(v), &runstate, 1); > > > > > + v->arch.runstate_guest.page = page; > > > > > + v->arch.runstate_guest.offset = offset; > > > > > + > > > > > + spin_unlock(&v->arch.runstate_guest.lock); > > > > > + > > > > > + return 0; > > > > > +} > > > > > + > > > > > + > > > > > +/* Update per-VCPU guest runstate shared memory area (if registered). > > > > > */ > > > > > +static void update_runstate_area(struct vcpu *v) > > > > > +{ > > > > > + struct vcpu_runstate_info *guest_runstate; > > > > > + void *p; > > > > > + > > > > > + spin_lock(&v->arch.runstate_guest.lock); > > > > > > > > > > - if ( guest_handle ) > > > > > + if ( v->arch.runstate_guest.page ) > > > > > { > > > > > - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > > > > > + p = __map_domain_page(v->arch.runstate_guest.page); > > > > > + guest_runstate = p + v->arch.runstate_guest.offset; > > > > > + > > > > > + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > > > > > + { > > > > > + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > > > > > + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; > > > > > > > > I think that this write to guest_runstate should use write_atomic or > > > > another atomic write operation. > > > > > > I thought about suggesting the same, but guest_copy_* helpers may not > > > do a single memory write to state_entry_time. > > > What are you trying to prevent with the write_atomic()? > > > > I am thinking that without using an atomic write, it would be (at least > > theoretically) possible for a guest to see a partial write to > > state_entry_time, which is not good. > > It is already the case with existing implementation as Xen may write byte by > byte. So are you suggesting the existing code is also buggy? Writing byte by byte is a different case. That is OK. In that case, the guest could see the state after 3 bytes written and it would be fine and consistent. If this hadn't been the case, then yes, the existing code would also be buggy. So if we did the write with a memcpy, it would be fine, no need for atomics: memcpy(&guest_runstate->state_entry_time, &v->runstate.state_entry_time, XXX); The |= case is different: GCC could implement it in any way it likes, including going through a zero-write to any of the bytes in the word, or doing an addition then a subtraction. GCC doesn't make any guarantees. If we want guarantees we need to use atomics. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 01:10:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 01:10:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjYDP-0004i6-Me; Fri, 12 Jun 2020 01:10:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjYDO-0004i0-DH for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 01:10:38 +0000 X-Inumbo-ID: 8676779a-ac49-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8676779a-ac49-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 01:10:38 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3ACA020878; Fri, 12 Jun 2020 01:10:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591924237; bh=n6hU2K/5uQFfgCcm/g3/2mm3MX9HhuqIPRYefrZl9iE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=n1PlB6+Sm9020NaQduzsMRwQpF2TZTclba8m6SVB416ThkMTg1Z63wgrjZ6XotJvU i2draRe4vSL7hHi26rJFwax0JCGeiLv5uUBSE0A7G132aNb52IOzdKmVHdHNiRvhpP hi0m/TWGLnj/WWDcmn6ANffHbeya0aftF+k1scdU= Date: Thu, 11 Jun 2020 18:10:36 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Bertrand Marquis Subject: Re: [PATCH 2/2] xen/arm: Support runstate crossing pages In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Volodymyr Babchuk , xen-devel@lists.xenproject.org, nd@arm.com, Julien Grall , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 11 Jun 2020, Bertrand Marquis wrote: > Add support for runstate area register with the structure crossing pages > The code is storing up to 2 pages reference during the hypercall. > During a context switch, the code is computing where the > state_entry_time is and is breaking the memcpy in 2 parts when it is > required. > > Signed-off-by: Bertrand Marquis Clearly a lot of efforts went into this patch, thanks you Bertrand. The change is complex for the feature it adds. I wonder if we could use ioremap (or maybe something similar but using a different virtual space) to simplify it. Julien, do you have good ideas? Otherwise I don't think there is much we can do to make this patch simpler. As ugly as it is (sorry Bertrand, it is not your fault!) the patch looks correct. > --- > xen/arch/arm/domain.c | 101 +++++++++++++++++++++++++---------- > xen/include/asm-arm/domain.h | 5 +- > 2 files changed, 76 insertions(+), 30 deletions(-) > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 739059234f..d847cb00f2 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -280,11 +280,16 @@ void arch_cleanup_runstate_guest(struct vcpu *v) > { > spin_lock(&v->arch.runstate_guest.lock); > > - /* cleanup previous page if any */ > - if ( v->arch.runstate_guest.page ) > + /* cleanup previous pages if any */ > + if ( v->arch.runstate_guest.page[0] ) > { > - put_page_and_type(v->arch.runstate_guest.page); > - v->arch.runstate_guest.page = NULL; > + put_page_and_type(v->arch.runstate_guest.page[0]); > + v->arch.runstate_guest.page[0] = NULL; > + if ( v->arch.runstate_guest.page[1] ) > + { > + put_page_and_type(v->arch.runstate_guest.page[1]); > + v->arch.runstate_guest.page[1] = NULL; > + } > v->arch.runstate_guest.offset = 0; > } > > @@ -294,26 +299,25 @@ void arch_cleanup_runstate_guest(struct vcpu *v) > int arch_setup_runstate_guest(struct vcpu *v, > struct vcpu_register_runstate_memory_area area) > { > - struct page_info *page; > + struct page_info *page[2] = {NULL,NULL}; > unsigned offset; > > spin_lock(&v->arch.runstate_guest.lock); > > - /* cleanup previous page if any */ > - if ( v->arch.runstate_guest.page ) > + /* cleanup previous pages if any */ > + if ( v->arch.runstate_guest.page[0] ) > { > - put_page_and_type(v->arch.runstate_guest.page); > - v->arch.runstate_guest.page = NULL; > + put_page_and_type(v->arch.runstate_guest.page[0]); > + v->arch.runstate_guest.page[0] = NULL; > + if ( v->arch.runstate_guest.page[1] ) > + { > + put_page_and_type(v->arch.runstate_guest.page[1]); > + v->arch.runstate_guest.page[1] = NULL; > + } > v->arch.runstate_guest.offset = 0; > } > > offset = ((vaddr_t)area.addr.v) & ~PAGE_MASK; > - if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) > - { > - spin_unlock(&v->arch.runstate_guest.lock); > - gprintk(XENLOG_DEBUG, "Runstate is crossing pages\n"); > - return -EINVAL; > - } > > /* provided address must be aligned to a 64bit */ > if ( offset % alignof(struct vcpu_runstate_info) ) > @@ -323,15 +327,30 @@ int arch_setup_runstate_guest(struct vcpu *v, > return -EINVAL; > } > > - page = get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); > - if ( !page ) > + page[0] = get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); > + if ( !page[0] ) > { > spin_unlock(&v->arch.runstate_guest.lock); > gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); > return -EINVAL; > } > > - v->arch.runstate_guest.page = page; > + if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) > + { > + /* guest area is crossing pages */ > + page[1] = get_page_from_gva(v, (vaddr_t)area.addr.v + PAGE_SIZE, > + GV2M_WRITE); > + if ( !page[1] ) > + { > + put_page_and_type(v->arch.runstate_guest.page[0]); > + spin_unlock(&v->arch.runstate_guest.lock); > + gprintk(XENLOG_DEBUG, "Runstate pointer is not fully mapped\n"); > + return -EINVAL; > + } > + } > + > + v->arch.runstate_guest.page[0] = page[0]; > + v->arch.runstate_guest.page[1] = page[1]; > v->arch.runstate_guest.offset = offset; > > spin_unlock(&v->arch.runstate_guest.lock); > @@ -343,34 +362,60 @@ int arch_setup_runstate_guest(struct vcpu *v, > /* Update per-VCPU guest runstate shared memory area (if registered). */ > static void update_runstate_area(struct vcpu *v) > { > - struct vcpu_runstate_info *guest_runstate; > - void *p; > + void *p[2]; > + unsigned offset, time_offset; > + uint64_t *state_entry_time; > > spin_lock(&v->arch.runstate_guest.lock); > > - if ( v->arch.runstate_guest.page ) > + if ( v->arch.runstate_guest.page[0] ) > { > - p = __map_domain_page(v->arch.runstate_guest.page); > - guest_runstate = p + v->arch.runstate_guest.offset; > + p[0] = __map_domain_page(v->arch.runstate_guest.page[0]); > + if ( v->arch.runstate_guest.page[1] ) > + p[1] = __map_domain_page(v->arch.runstate_guest.page[1]); > + else > + p[1] = NULL; > + offset = v->arch.runstate_guest.offset; > > if ( VM_ASSIST(v->domain, runstate_update_flag) ) > { > + time_offset = offset + > + offsetof(struct vcpu_runstate_info, state_entry_time); > + > + if ( time_offset < PAGE_SIZE ) > + state_entry_time = p[0] + time_offset; > + else > + state_entry_time = p[1] + (time_offset - PAGE_SIZE); > + > v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > - guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; > + *state_entry_time |= XEN_RUNSTATE_UPDATE; > smp_wmb(); > } > + else > + state_entry_time = NULL; > + > + if ( p[1] ) > + { > + memcpy(p[0] + offset, &v->runstate, PAGE_SIZE - offset); > + memcpy(p[1], &v->runstate + (PAGE_SIZE - offset), > + sizeof(v->runstate) - (PAGE_SIZE - offset)); > + } > + else > + memcpy(p[0] + offset, &v->runstate, sizeof(v->runstate)); > > - memcpy(guest_runstate, &v->runstate, sizeof(v->runstate)); > + /* copy must be done before switching the bit */ > smp_wmb(); > > - if ( VM_ASSIST(v->domain, runstate_update_flag) ) > + if ( state_entry_time ) > { > v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > - guest_runstate->state_entry_time &= ~XEN_RUNSTATE_UPDATE; > + *state_entry_time &= ~XEN_RUNSTATE_UPDATE; > smp_wmb(); > } > > - unmap_domain_page(p); > + unmap_domain_page(p[0]); > + if ( p[1] ) > + unmap_domain_page(p[1]); > } > > spin_unlock(&v->arch.runstate_guest.lock); > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h > index 3a7f53e13d..61e32f1ed5 100644 > --- a/xen/include/asm-arm/domain.h > +++ b/xen/include/asm-arm/domain.h > @@ -209,8 +209,9 @@ struct arch_vcpu > > /* runstate guest info */ > struct { > - struct page_info *page; /* guest page */ > - unsigned offset; /* offset in page */ > + /* we need 2 pages in case the guest area is crossing pages */ > + struct page_info *page[2]; /* guest pages */ > + unsigned offset; /* offset in first page */ > spinlock_t lock; /* lock to access page */ > } runstate_guest; From xen-devel-bounces@lists.xenproject.org Fri Jun 12 01:15:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 01:15:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjYI0-0004u9-8p; Fri, 12 Jun 2020 01:15:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjYHz-0004u2-7i for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 01:15:23 +0000 X-Inumbo-ID: 3035231c-ac4a-11ea-b59a-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3035231c-ac4a-11ea-b59a-12813bfff9fa; Fri, 12 Jun 2020 01:15:22 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DE59C206D7; Fri, 12 Jun 2020 01:15:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591924522; bh=wWen0H0+sBJ2dtHmvERsN63/B/oQ2CPJMCa9HkKOyxg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=G6rhnB1Yc6PDMlutIOfQdGycCu7iQNS98ml0F6COb6U7CgpKGnw+HdJpFdQJkSUso AHcew4RTa/22MfVuzGJKcKiQlVlHtLx/YM5smXj+kkgKZDUfD6yqUl+HJifSKUzSTH G41jYb7qLWxq7N3Sso6v+BFeWVzwE8aAVcRY/txs= Date: Thu, 11 Jun 2020 18:15:21 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: HYPERVISOR_console_io + CONSOLEIO_write needs COPY_flush_dcache In-Reply-To: Message-ID: References: <912a84d1-ca47-9c37-06e7-28bebe696b4d@epam.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , George.Dunlap@citrix.com, Bertrand Marquis , Stefano Stabellini , Oleksandr Andrushchenko Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 11 Jun 2020, Julien Grall wrote: > > Probably my use-case should be somewhere documented, so another time someone > > steps into similar issues it is explained. > > You would have the exact same issue if you don't use hypercalls but modify a > buffer with MMU off and then expect it to read the content correctly after > turning on the MMU. That's even on baremetal! (see [1]) > > I am afraid you have to know how the cache works when writing code that will > run with MMU off. > > Therefore I don't think it is Xen Project to document how an architecture > works. Instead this should be a tutorial for anyone wanting to write its own > OS. We could have a page on wiki.xenproject.org on the topic if Oleksandr wants to write it. (Adding George in case Oleksandr wants to write the and he doesn't have access to the wiki yet.) From xen-devel-bounces@lists.xenproject.org Fri Jun 12 01:57:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 01:57:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjYwB-0008CL-CZ; Fri, 12 Jun 2020 01:56:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjYwA-0008CG-54 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 01:56:54 +0000 X-Inumbo-ID: fc87e6d4-ac4f-11ea-bb8b-bc764e2007e4 Received: from mail-lj1-x243.google.com (unknown [2a00:1450:4864:20::243]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fc87e6d4-ac4f-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 01:56:53 +0000 (UTC) Received: by mail-lj1-x243.google.com with SMTP id 9so9266977ljv.5 for ; Thu, 11 Jun 2020 18:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FBDI/B5IB0vJjCABbmkQCbB6328dkyQOgPMlgLV2if8=; b=HByEA72btsocDdS7+l7sAReQrchL5YHwOhpdg3Nn2IBiL7J26LM9GsQoQTycLW0hbc 5hW7+7pDBacPR086QIYo54pjWv6OOTQ6tOzHRkUeUfMfNhS6tWXvIlV0NgzMKO0i0XDG WgTe6CA7zUi1Ky0Wg5H0wwlAsxFLytSDAKXq2/M+57BASjqR6TlWSmsvmu9aZaxpAQW2 FA+ZQqywt0itYlt45GfNWViQXPpH9aCxYzWP3ROg+LudC4NDMjOc6mclQxSc0Lsx92iC sf8VNhsMSKqYXHf1tjTCVfm/opS5Q2CUVUTZcVAa3yBJ7MyzDH2FOLxoGdBx7sT831GY P5fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FBDI/B5IB0vJjCABbmkQCbB6328dkyQOgPMlgLV2if8=; b=lAGL15R3VmXAbklAUYM2yeHEPbH+ONh3yJAPJQ5QVTPnZLMs8YKNN2arfww9jEJXGe WWLcg2nfxMRg+Ug935heE5VZ3OH2uqvrPZByb7N0Pm+tAzpX0EPJTgFRj1m1qgEV6kRT sIU7wz2PNwxyn8rvk7SxaNEzPfGmeyoU+C/cVQZeXQ/lcPedQHfk5GS8wn3P1G9xeYcd hbWIBSDvX59Qyau2lDUbtTyJJy0iq901vtLdI/prvKGcfkTkPjylCZjACkfv7YPTjHtG Stw49iDfZLXtLIiHSsAW3SIWngTG37hGLOimQ/4Yb3GsICfZpENf4KiuBj0/CCr6WuKf v0ug== X-Gm-Message-State: AOAM533ZN2wKlyQ2QpHlK8xr2U3E6xpJs9WB1Gca5mKVbhWYeVWHNIXS YNEEPoZim38Q4jRQWzzmDLLEhr0yisX7q8QTYrY= X-Google-Smtp-Source: ABdhPJwD2LCbadd+slSnQ4kdRR5uQAa3UebuN48BTBToDhoYhS7i9ROTG0ZtFDGKGwVRx01GS3ZmkGTYsauRh9QFhzo= X-Received: by 2002:a2e:b88c:: with SMTP id r12mr5609398ljp.266.1591927012154; Thu, 11 Jun 2020 18:56:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jason Andryuk Date: Thu, 11 Jun 2020 21:56:40 -0400 Message-ID: Subject: Re: Seabios Xen TPM check To: Stefan Berger Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Quan Xu , seabios@seabios.org, Emil Condrea , Stefan Berger Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 11, 2020 at 10:32 AM Stefan Berger wrote: > > On 6/11/20 8:36 AM, Jason Andryuk wrote: > > Hi, > > > > SeaBIOS commit 67643955c746 (make SeaBios compatible with Xen vTPM.) > > made tpm_start() exit before calling tpm_startup(). The commit > > message has no explanation why this change was made. Does anyone > > remember why it was made? > > > > The code today means SeaBIOS will not populate PCRs when running on > > Xen. If I revert the patch, SeaBIOS populates PCRs as one would > > expect. This is with a QEMU-emulated TPM backed by swtpm in TPM 1.2 > > mode (qemu & swtpm running in a linux stubdom). > > > > Any insight is appreciated. > > My guess would be that for some reason the TPM 1.2 was already started > up through other means and didn't need the SeaBIOS tpm_startup() to run. Hmmm, yes. Thanks, Stefan. The mini-os vtpm stubdom calls TPM_Startup and it looks like the Berlios tpm_emulator returns an error when called twice. >From a little bit of googling, Quan and Emil (added to CC) were working on an interface from QEMU to the vtpm stubdom, but it looks like it didn't get merged into upstream QEMU? It doesn't seem to be there now. Anyway, the mini-os vtpm stubdom calls TPM_Startup since a PV guest doesn't have firmware to make the call. SeaBIOS could make a tpm_startup error non-fatal for Xen. Or better - detect a vtpm stubdom and only then skip initialization. vtpm stubdom could also be changed to skip TPM_Startup for HVM - not sure if that would be problematic. That would let SeaBIOS drop the Xen condition. Regards, Jason From xen-devel-bounces@lists.xenproject.org Fri Jun 12 02:32:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 02:32:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjZUR-0003JP-8U; Fri, 12 Jun 2020 02:32:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjZUP-0003J0-Mb for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 02:32:17 +0000 X-Inumbo-ID: eb7cd638-ac54-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eb7cd638-ac54-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 02:32:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PQIQOC4KKQdLQfxHXdetTQbW95MjQi3m0+wAEUueQeE=; b=HvgJAiVio8bNuvKppohD4UsIM KEVJb2vRuDte18zTS3JUYXoC9StfUNh+50h8tSn7s3jvAP9YJBmqSzNV93QY9ObOJoLVmunia68hb Ra/u3Rm5J5M5thsNVF21TaQSk4qL8PEibRdgF/YcgDKKGxOqvM8msmE8WTsz21BcPi6Lo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjZUI-0005UY-VA; Fri, 12 Jun 2020 02:32:10 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjZUI-0006CN-MW; Fri, 12 Jun 2020 02:32:10 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjZUI-00074N-Lw; Fri, 12 Jun 2020 02:32:10 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151053: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=2995d0afdf2d3fb44d07eada088db3613741db1e X-Osstest-Versions-That: xen=3664f7b7788b66bb802432e6748be0fb57993581 From: osstest service owner Date: Fri, 12 Jun 2020 02:32:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151053 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151053/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 2995d0afdf2d3fb44d07eada088db3613741db1e baseline version: xen 3664f7b7788b66bb802432e6748be0fb57993581 Last test of basis 151050 2020-06-11 19:01:32 Z 0 days Testing same since 151053 2020-06-11 23:03:20 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Roger Pau Monne Roger Pau Monné jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 3664f7b778..2995d0afdf 2995d0afdf2d3fb44d07eada088db3613741db1e -> smoke From xen-devel-bounces@lists.xenproject.org Fri Jun 12 04:26:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 04:26:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbGK-0003tM-Rn; Fri, 12 Jun 2020 04:25:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbGJ-0003tG-Nf for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 04:25:51 +0000 X-Inumbo-ID: c9412c80-ac64-11ea-b5a2-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c9412c80-ac64-11ea-b5a2-12813bfff9fa; Fri, 12 Jun 2020 04:25:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E8AA1ADBB; Fri, 12 Jun 2020 04:25:48 +0000 (UTC) Subject: Re: Kexec and libxenctlr.so To: Julien Grall , Julien Grall , "xen-devel@lists.xenproject.org" , Anthony Perard , "wl@xen.org" , daniel.kiper@oracle.com References: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> <261293b1-f4c9-e41d-0c76-cd47fe5c0dc2@suse.com> <5602eebf-c149-17f7-37c9-b263ff290509@xen.org> <6fa3067c-2c71-bb8e-eab8-30f44782d002@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <6c662ac7-ee10-1ac1-5b9f-df9a02d00d5c@suse.com> Date: Fri, 12 Jun 2020 06:25:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <6fa3067c-2c71-bb8e-eab8-30f44782d002@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 11.06.20 18:00, Julien Grall wrote: > > > On 11/06/2020 16:35, Jürgen Groß wrote: >> On 11.06.20 17:27, Julien Grall wrote: >>> Hi, >>> >>> On 11/06/2020 16:21, Jürgen Groß wrote: >>>> On 11.06.20 16:57, Julien Grall wrote: >>>>> Hi all, >>>>> >>>>> kexec-tools has an option to load dynamically libxenctlr.so (not >>>>> .so.4.x) (see [1]). >>>>> >>>>> Given that the library has never been considered stable, it is >>>>> probably a disaster that is waiting to happen. >>>>> >>>>> Looking at the tree kexec is using the follow libxc functions: >>>>>     - xc_kexec_get_range() >>>>>     - xc_kexec_load() >>>>>     - xc_kexec_unload() >>>>>     - xc_kexec_status() >>>>>     - xc_kexec_exec() >>>>>     - xc_version() >>>>>     - xc_interface_open() >>>>>     - xc_interface_close() >>>>>     - xc_get_max_cpus() >>>>>     - xc_get_machine_memory_map() >>>>> >>>>> I think it is uncontroversial that we want a new stable library for >>>>> all the xc_kexec_* functions (maybe libxenexec)? >>>>> >>>>> However I am not entirely sure where to put the others. >>>>> >>>>> I am thinking to introduce libxensysctl for xc_get_max_cpus() as it >>>>> is a XEN_SYSCTL. We could possibly include >>>>> xc_get_machine_memory_map() (despite it is a XENMEM_). >>>>> >>>>> For xc_version(), I am thinking to extend libxentoolcore to also >>>>> include "stable xen API". >>>>> >>>>> Any opinion on the approach? >>>> >>>> You could consider hypfs (at least for some of the functionality). >>> >>> That would work! >>> >>>> >>>> xc_version() and xc_get_max_cpus() would be rather easy. >>> >>> I am guessing we will need a fallback to the normal hypercalls if >>> hypfs is not present. >> >> Or we don't support kexec-tools running on a system without hypfs >> (or the related functions would return an error on those systems). > > AFAICT, hypfs allows you to modify runtime parameters which is not > required for kexec. Well, and? kexec won't use this functionality. libxenctrl allows to create domains, which isn't required for kexec. And kexec doesn't do it. We could still have the entry points for that functionality in libxenexec, which could use libxenhypfs (and maybe others). > Such feature could be undesirable in some setup and therefore I don't > think this is acceptable to impose that for kexec. If we really have setups where this would be an issue we'd need to modify the flask integration of hypfs to be able to disallow write access to hypfs. Or we could even add per-node access rights. Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 12 04:29:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 04:29:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbJj-00042C-BS; Fri, 12 Jun 2020 04:29:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbJh-000426-T3 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 04:29:21 +0000 X-Inumbo-ID: 49887088-ac65-11ea-b5a2-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 49887088-ac65-11ea-b5a2-12813bfff9fa; Fri, 12 Jun 2020 04:29:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a0r3id7e4eoKi5gY23vINKMEtnwPKKwzGCFgyrQhu18=; b=V+ou4ViwLuQxHxN1fzZ5a/13U IY9kxT5TQuXELjkLHMMLNfNNaHnyRTDxKf+ecZQ17xRl4FlmoqpGIqWkT3mWu0Mm7fB+4Z1s8+u4M 85/ePZ/dvCtNEDeEIrXrNSUZao8gXEvvVzCk2NQOriFYwlmK2UctiNzqzYVtgD/gRVVts=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbJg-0007fk-Sb; Fri, 12 Jun 2020 04:29:20 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjbJg-0004B0-Jm; Fri, 12 Jun 2020 04:29:20 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjbJg-0006yv-J5; Fri, 12 Jun 2020 04:29:20 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151032: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-saverestore.2:fail:heisenbug xen-4.12-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=199ae1f15894bd1bdefdf7c3e44688127be3ba19 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Fri, 12 Jun 2020 04:29:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151032 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151032/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qcow2 16 guest-saverestore.2 fail pass in 150991 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 150991 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail in 150991 like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 199ae1f15894bd1bdefdf7c3e44688127be3ba19 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 28 days Testing same since 150943 2020-06-09 17:06:00 Z 2 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Fri Jun 12 04:36:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 04:36:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbQM-0004sX-4S; Fri, 12 Jun 2020 04:36:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbQK-0004sS-Th for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 04:36:12 +0000 X-Inumbo-ID: 3dd9ba02-ac66-11ea-b5a2-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3dd9ba02-ac66-11ea-b5a2-12813bfff9fa; Fri, 12 Jun 2020 04:36:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0266FAD60; Fri, 12 Jun 2020 04:36:13 +0000 (UTC) Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler To: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> Date: Fri, 12 Jun 2020 06:36:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200612002205.174295-2-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.20 02:22, Volodymyr Babchuk wrote: > Add code that saves time spent in IRQ handler, so later we can make > adjustments to schedule unit run time. > > This and following changes are called upon to provide fair > scheduling. Problem is that any running vCPU can be interrupted by to > handle IRQ which is bound to some other vCPU. Thus, current vCPU can > be charged for a time, it actually didn't used. > > TODO: move vcpu_{begin|end}_irq_handler() calls to entry.S for even > more fair time tracking. > > Signed-off-by: Volodymyr Babchuk > --- > xen/arch/arm/irq.c | 2 ++ > xen/arch/x86/irq.c | 2 ++ > xen/common/sched/core.c | 29 +++++++++++++++++++++++++++++ > xen/include/xen/sched.h | 13 +++++++++++++ > 4 files changed, 46 insertions(+) > > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c > index 3877657a52..51b517c0cd 100644 > --- a/xen/arch/arm/irq.c > +++ b/xen/arch/arm/irq.c > @@ -201,6 +201,7 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq) > struct irq_desc *desc = irq_to_desc(irq); > struct irqaction *action; > > + vcpu_begin_irq_handler(); > perfc_incr(irqs); > > ASSERT(irq >= 16); /* SGIs do not come down this path */ > @@ -267,6 +268,7 @@ out: > out_no_end: > spin_unlock(&desc->lock); > irq_exit(); > + vcpu_end_irq_handler(); > } > > void release_irq(unsigned int irq, const void *dev_id) > diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c > index a69937c840..3ef4221b64 100644 > --- a/xen/arch/x86/irq.c > +++ b/xen/arch/x86/irq.c > @@ -1895,6 +1895,7 @@ void do_IRQ(struct cpu_user_regs *regs) > int irq = this_cpu(vector_irq)[vector]; > struct cpu_user_regs *old_regs = set_irq_regs(regs); > > + vcpu_begin_irq_handler(); > perfc_incr(irqs); > this_cpu(irq_count)++; > irq_enter(); > @@ -2024,6 +2025,7 @@ void do_IRQ(struct cpu_user_regs *regs) > out_no_unlock: > irq_exit(); > set_irq_regs(old_regs); > + vcpu_end_irq_handler(); > } > > static inline bool is_free_pirq(const struct domain *d, > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c > index cb49a8bc02..8f642ada05 100644 > --- a/xen/common/sched/core.c > +++ b/xen/common/sched/core.c > @@ -916,6 +916,35 @@ void vcpu_unblock(struct vcpu *v) > vcpu_wake(v); > } > > +void vcpu_begin_irq_handler(void) > +{ > + if (is_idle_vcpu(current)) > + return; > + > + /* XXX: Looks like ASSERT_INTERRUPTS_DISABLED() is available only for x86 */ > + if ( current->irq_nesting++ ) > + return; > + > + current->irq_entry_time = NOW(); > +} > + > +void vcpu_end_irq_handler(void) > +{ > + int delta; > + > + if (is_idle_vcpu(current)) > + return; > + > + ASSERT(current->irq_nesting); > + > + if ( --current->irq_nesting ) > + return; > + > + /* We assume that irq handling time will not overflow int */ This assumption might not hold for long running VMs. Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 12 04:43:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 04:43:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbX0-0005tg-Va; Fri, 12 Jun 2020 04:43:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbWz-0005sq-Do for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 04:43:05 +0000 X-Inumbo-ID: 336012fa-ac67-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 336012fa-ac67-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 04:43:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id F4048AD60; Fri, 12 Jun 2020 04:43:05 +0000 (UTC) Subject: Re: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks To: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-3-volodymyr_babchuk@epam.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Fri, 12 Jun 2020 06:43:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200612002205.174295-3-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.20 02:22, Volodymyr Babchuk wrote: > In most cases hypervisor code performs guest-related jobs. Tasks like > hypercall handling or MMIO access emulation are done for calling vCPU > so it is okay to charge time spent in hypervisor to the current vCPU. > > But, there are also tasks that are not originated from guests. This > includes things like TLB flushing or running tasklets. We don't want > to track time spent in this tasks to a total scheduling unit run > time. So we need to track time spent in such housekeeping tasks > separately. > > Those hypervisor tasks are run in do_softirq() function, so we'll > install our hooks there. > > TODO: This change is not tested on ARM, and probably we'll get a > failing assertion there. This is because ARM code exits from > schedule() and have chance to get to end of do_softirq(). > > Signed-off-by: Volodymyr Babchuk > --- > xen/common/sched/core.c | 32 ++++++++++++++++++++++++++++++++ > xen/common/softirq.c | 2 ++ > xen/include/xen/sched.h | 16 +++++++++++++++- > 3 files changed, 49 insertions(+), 1 deletion(-) > > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c > index 8f642ada05..d597811fef 100644 > --- a/xen/common/sched/core.c > +++ b/xen/common/sched/core.c > @@ -945,6 +945,37 @@ void vcpu_end_irq_handler(void) > atomic_add(delta, ¤t->sched_unit->irq_time); > } > > +void vcpu_begin_hyp_task(struct vcpu *v) > +{ > + if ( is_idle_vcpu(v) ) > + return; > + > + ASSERT(!v->in_hyp_task); > + > + v->hyp_entry_time = NOW(); > +#ifndef NDEBUG > + v->in_hyp_task = true; > +#endif > +} > + > +void vcpu_end_hyp_task(struct vcpu *v) > +{ > + int delta; > + > + if ( is_idle_vcpu(v) ) > + return; > + > + ASSERT(v->in_hyp_task); > + > + /* We assume that hypervisor task time will not overflow int */ This will definitely happen for long running VMs. Please use a 64-bit variable. > + delta = NOW() - v->hyp_entry_time; > + atomic_add(delta, &v->sched_unit->hyp_time); > + > +#ifndef NDEBUG > + v->in_hyp_task = false; > +#endif > +} > + > /* > * Do the actual movement of an unit from old to new CPU. Locks for *both* > * CPUs needs to have been taken already when calling this! > @@ -2615,6 +2646,7 @@ static void schedule(void) > > SCHED_STAT_CRANK(sched_run); > > + vcpu_end_hyp_task(current); > rcu_read_lock(&sched_res_rculock); > > lock = pcpu_schedule_lock_irq(cpu); > diff --git a/xen/common/softirq.c b/xen/common/softirq.c > index 063e93cbe3..03a29384d1 100644 > --- a/xen/common/softirq.c > +++ b/xen/common/softirq.c > @@ -71,7 +71,9 @@ void process_pending_softirqs(void) > void do_softirq(void) > { > ASSERT_NOT_IN_ATOMIC(); > + vcpu_begin_hyp_task(current); > __do_softirq(0); > + vcpu_end_hyp_task(current); This won't work for scheduling. current will either have changed, or in x86 case __do_softirq() might just not return. You need to handle that case explicitly in schedule() (you did that for the old vcpu, but for the case schedule() is returning you need to call vcpu_begin_hyp_task(current) there). Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 12 04:51:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 04:51:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbfA-0006jj-R1; Fri, 12 Jun 2020 04:51:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbf9-0006jd-SU for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 04:51:31 +0000 X-Inumbo-ID: 62026562-ac68-11ea-b5a2-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 62026562-ac68-11ea-b5a2-12813bfff9fa; Fri, 12 Jun 2020 04:51:31 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 02E51AE07; Fri, 12 Jun 2020 04:51:33 +0000 (UTC) Subject: Re: [RFC PATCH v1 3/6] sched, credit2: improve scheduler fairness To: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-4-volodymyr_babchuk@epam.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Fri, 12 Jun 2020 06:51:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200612002205.174295-4-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: George Dunlap , Dario Faggioli Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.20 02:22, Volodymyr Babchuk wrote: > Now we can make corrections for scheduling unit run time, based on > data gathered in previous patches. This includes time spent in IRQ > handlers and time spent for hypervisor housekeeping tasks. Those time > spans needs to be deduced from a total run time. > > This patch adds sched_get_time_correction() function which returns > time correction value. This value should be subtracted by a scheduler > implementation from a total vCPU/shced_unit run time. > > TODO: Make the corresponding changes to all other schedulers. > > Signed-off-by: Volodymyr Babchuk > --- > xen/common/sched/core.c | 23 +++++++++++++++++++++++ > xen/common/sched/credit2.c | 2 +- > xen/common/sched/private.h | 10 ++++++++++ > 3 files changed, 34 insertions(+), 1 deletion(-) > > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c > index d597811fef..a7294ff5c3 100644 > --- a/xen/common/sched/core.c > +++ b/xen/common/sched/core.c > @@ -974,6 +974,29 @@ void vcpu_end_hyp_task(struct vcpu *v) > #ifndef NDEBUG > v->in_hyp_task = false; > #endif > + > +s_time_t sched_get_time_correction(struct sched_unit *u) > +{ > + unsigned long flags; > + int irq, hyp; Using "irq" for a time value is misleading IMO. > + > + while ( true ) > + { > + irq = atomic_read(&u->irq_time); > + if ( likely( irq == atomic_cmpxchg(&u->irq_time, irq, 0)) ) > + break; > + } Just use atomic_xchg()? > + > + while ( true ) > + { > + hyp = atomic_read(&u->hyp_time); > + if ( likely( hyp == atomic_cmpxchg(&u->hyp_time, hyp, 0)) ) > + break; > + } > + > + return irq + hyp; Ah, I didn't look into this patch until now. You can replace my comments about overflow of an int for patches 1 and 2 with: Please modify the comment about not overflowing hinting to the value being reset when making scheduling decisions. And this (of course) needs to be handled in all other schedulers, too. Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 12 04:57:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 04:57:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbkj-0006us-Fi; Fri, 12 Jun 2020 04:57:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjbki-0006uk-0q for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 04:57:16 +0000 X-Inumbo-ID: 2ef83aa6-ac69-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2ef83aa6-ac69-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 04:57:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 859EFAC61; Fri, 12 Jun 2020 04:57:17 +0000 (UTC) Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> Date: Fri, 12 Jun 2020 06:57:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200612002205.174295-5-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.20 02:22, Volodymyr Babchuk wrote: > As scheduler code now collects time spent in IRQ handlers and in > do_softirq(), we can present those values to userspace tools like > xentop, so system administrator can see how system behaves. > > We are updating counters only in sched_get_time_correction() function > to minimize number of taken spinlocks. As atomic_t is 32 bit wide, it > is not enough to store time with nanosecond precision. So we need to > use 64 bit variables and protect them with spinlock. > > Signed-off-by: Volodymyr Babchuk > --- > xen/common/sched/core.c | 17 +++++++++++++++++ > xen/common/sysctl.c | 1 + > xen/include/public/sysctl.h | 4 +++- > xen/include/xen/sched.h | 2 ++ > 4 files changed, 23 insertions(+), 1 deletion(-) > > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c > index a7294ff5c3..ee6b1d9161 100644 > --- a/xen/common/sched/core.c > +++ b/xen/common/sched/core.c > @@ -95,6 +95,10 @@ static struct scheduler __read_mostly ops; > > static bool scheduler_active; > > +static DEFINE_SPINLOCK(sched_stat_lock); > +s_time_t sched_stat_irq_time; > +s_time_t sched_stat_hyp_time; > + > static void sched_set_affinity( > struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft); > > @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct sched_unit *u) > break; > } > > + spin_lock_irqsave(&sched_stat_lock, flags); > + sched_stat_irq_time += irq; > + sched_stat_hyp_time += hyp; > + spin_unlock_irqrestore(&sched_stat_lock, flags); Please don't use a lock. Just use add_sized() instead which will add atomically. > + > return irq + hyp; > } > > +void sched_get_time_stats(uint64_t *irq_time, uint64_t *hyp_time) > +{ > + unsigned long flags; > + > + spin_lock_irqsave(&sched_stat_lock, flags); > + *irq_time = sched_stat_irq_time; > + *hyp_time = sched_stat_hyp_time; > + spin_unlock_irqrestore(&sched_stat_lock, flags); read_atomic() will do the job without lock. > } > > /* > diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c > index 1c6a817476..00683bc93f 100644 > --- a/xen/common/sysctl.c > +++ b/xen/common/sysctl.c > @@ -270,6 +270,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) > pi->scrub_pages = 0; > pi->cpu_khz = cpu_khz; > pi->max_mfn = get_upper_mfn_bound(); > + sched_get_time_stats(&pi->irq_time, &pi->hyp_time); > arch_do_physinfo(pi); > if ( iommu_enabled ) > { > diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h > index 3a08c512e8..f320144d40 100644 > --- a/xen/include/public/sysctl.h > +++ b/xen/include/public/sysctl.h > @@ -35,7 +35,7 @@ > #include "domctl.h" > #include "physdev.h" > > -#define XEN_SYSCTL_INTERFACE_VERSION 0x00000013 > +#define XEN_SYSCTL_INTERFACE_VERSION 0x00000014 > > /* > * Read console content from Xen buffer ring. > @@ -118,6 +118,8 @@ struct xen_sysctl_physinfo { > uint64_aligned_t scrub_pages; > uint64_aligned_t outstanding_pages; > uint64_aligned_t max_mfn; /* Largest possible MFN on this host */ > + uint64_aligned_t irq_time; > + uint64_aligned_t hyp_time; Would hypfs work, too? This would avoid the need for extending another hypercall. Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 12 05:38:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 05:38:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjcO0-00023m-Ad; Fri, 12 Jun 2020 05:37:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjcNy-00023h-Vl for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 05:37:51 +0000 X-Inumbo-ID: da172b18-ac6e-11ea-b5a2-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id da172b18-ac6e-11ea-b5a2-12813bfff9fa; Fri, 12 Jun 2020 05:37:49 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6BA98AF19; Fri, 12 Jun 2020 05:37:52 +0000 (UTC) From: Juergen Gross To: torvalds@linux-foundation.org Subject: [GIT PULL] xen: branch for v5.8-rc1 Date: Fri, 12 Jun 2020 07:37:47 +0200 Message-Id: <20200612053747.13750-1-jgross@suse.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-kernel@vger.kernel.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.8b-rc1-tag xen: branch for v5.8-rc1 It contains the following patches: - several smaller cleanups - a fix for a Xen guest regression with CPU offlining - a small fix in the xen pvcalls backend driver - an update of MAINTAINERS Thanks. Juergen MAINTAINERS | 4 +-- drivers/pci/xen-pcifront.c | 27 ++++++-------- drivers/xen/Kconfig | 4 +++ drivers/xen/cpu_hotplug.c | 8 ++--- drivers/xen/platform-pci.c | 2 +- drivers/xen/pvcalls-back.c | 5 +-- drivers/xen/xen-pciback/conf_space.c | 16 ++++----- drivers/xen/xen-pciback/conf_space_header.c | 44 ++++++++--------------- drivers/xen/xen-pciback/conf_space_quirks.c | 6 ++-- drivers/xen/xen-pciback/pci_stub.c | 38 +++++++++----------- drivers/xen/xen-pciback/pciback.h | 2 -- drivers/xen/xen-pciback/pciback_ops.c | 55 +++++++++-------------------- drivers/xen/xen-pciback/vpci.c | 10 +++--- drivers/xen/xenbus/xenbus_probe.c | 11 +++--- 14 files changed, 90 insertions(+), 142 deletions(-) Bjorn Helgaas (2): xen-pciback: Use dev_printk() when possible xenbus: Use dev_printk() when possible Boris Ostrovsky (2): xen/cpuhotplug: Fix initial CPU offlining for PV(H) guests xen/pci: Get rid of verbose_request and use dev_dbg() instead Deep Shah (1): MAINTAINERS: Update PARAVIRT_OPS_INTERFACE and VMWARE_HYPERVISOR_INTERFACE Juergen Gross (1): xen/pvcalls-back: test for errors when calling backend_connect() Rikard Falkeborn (1): xen-platform: Constify dev_pm_ops Roger Pau Monne (2): xen: expand BALLOON_MEMORY_HOTPLUG description xen: enable BALLOON_MEMORY_HOTPLUG by default YueHaibing (1): xen/pvcalls: Make pvcalls_back_global static From xen-devel-bounces@lists.xenproject.org Fri Jun 12 07:04:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 07:04:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjdjD-0000ug-DW; Fri, 12 Jun 2020 07:03:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjdjC-0000ub-Ga for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 07:03:50 +0000 X-Inumbo-ID: dcb3ac3c-ac7a-11ea-b5a8-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dcb3ac3c-ac7a-11ea-b5a8-12813bfff9fa; Fri, 12 Jun 2020 07:03:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CD914AB76; Fri, 12 Jun 2020 07:03:50 +0000 (UTC) Subject: Re: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() To: Andrew Cooper , Xen-devel References: <20200610114004.30023-1-andrew.cooper3@citrix.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <4a5edcf7-06b3-55d9-3ae1-5165ca63faa9@suse.com> Date: Fri, 12 Jun 2020 09:03:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200610114004.30023-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10.06.20 13:40, Andrew Cooper wrote: > c/s 6902cb00e03 "tools/libxendevicemodel: extract functions and add a compat > layer" introduced calls to both xencall_open() and osdep_xendevicemodel_open() > but failed to fix up the error path. > > c/s f68c7c618a3 "libs/devicemodel: free xencall handle in error path in > _open()" fixed up the xencall_open() aspect of the error path (missing the > osdep_xendevicemodel_open() aspect), but positioned the xencall_close() > incorrectly, creating the same pattern proved to be problematic by c/s > 30a72f02870 "tools: fix error path of xenhypfs_open()". > > Reposition xtl_logger_destroy(), and introduce the missing > osdep_xendevicemodel_close(). > > Fixes: 6902cb00e03 ("tools/libxendevicemodel: extract functions and add a compat layer") > Fixes: f68c7c618a3 ("libs/devicemodel: free xencall handle in error path in _open()") > Backport: 4.9+ > Signed-off-by: Andrew Cooper Reviewed-by: Juergen Gross Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 12 07:22:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 07:22:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jje0u-0002YE-Tu; Fri, 12 Jun 2020 07:22:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jje0s-0002Y9-Ts for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 07:22:07 +0000 X-Inumbo-ID: 6b087506-ac7d-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6b087506-ac7d-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 07:22:06 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id u26so8511966wmn.1 for ; Fri, 12 Jun 2020 00:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=QX2hYMcq8KtNejbzc9d9v51YQ40OXVASPsQvLnJH96s=; b=oKwBvXhx/Wuy2jnsNtK61cawaTAnoU1rJn5g7y5FReTlL1Rph/WtFa6hZuM9g7YXFv ZOsHdbDmQ6ent057T2/Mxr6RGNn9+TTG7hBbBJpSjQB99x/eK948G5TWFK6kBbB4yPTe z9nHEYFF+ZodIXGJJ+ASlml8RQ6kXBtOmwc47D0Hlq1ZP4emsuztAiB3CpqJ4iKCO23V goOsOElOqSSZUEnf0A7IGdkQjpqrJGSlue88KcVnZ6Aj4+Mz5OEjrffFfFfTjqk9UOT3 woI0G7Y78LQU6R6/HGnlXP6WG/cSpFNvmo+XxqSb5V4h90pXoJJ5V9Dc33S2e59H0yOV JPIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=QX2hYMcq8KtNejbzc9d9v51YQ40OXVASPsQvLnJH96s=; b=CV3+8Ttu8cWwExuK57AbdjSlSPUzkP0XbqDGH1cEJrKzWqM+UjmrxT2yZIBEGJnBWi jvzApcKZdR+AKEMAOjzufXhDarEep8cCX/HFo+xr/mWIC21qmCbAebGsWx6hkidxGo6A rOfffWv2WNg8pVsI8XzLDU2Zsxxd24Hi+5lx0LXKNGC05qigNOROn9pgZiZub8MiUlDu uIYNOXsZyEZpWErnCqN4niltJgaMNYN3pDxcEaOxYuUKgsGVb6nTv1SizKQYntFszSTG p2btEY8OcJ4UpDoiMrlphpFurGBXjOVd8AmEFYlM401Adb5mXxgAqXNxiJG/gIilwXG0 0cuw== X-Gm-Message-State: AOAM531ySFCizBK8Nostst9vyETmRfn8c4r6fSQhEpaB2hQJPM7O+Co5 CqS3p3mT8jSTDWWiYIHfq0k= X-Google-Smtp-Source: ABdhPJxCljITKr7EqcB/OdCl9+q4VixzvbFNlcOFBcHOMPB3XebDxolzsfgQeTEtDfftNWD8YByFLw== X-Received: by 2002:a1c:408:: with SMTP id 8mr11681540wme.15.1591946525171; Fri, 12 Jun 2020 00:22:05 -0700 (PDT) Received: from CBGR90WXYV0 ([2a00:23c5:5782:7500:500b:ebd:ed78:4380]) by smtp.gmail.com with ESMTPSA id b14sm7429409wmj.47.2020.06.12.00.22.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 00:22:04 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200610114004.30023-1-andrew.cooper3@citrix.com> In-Reply-To: <20200610114004.30023-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() Date: Fri, 12 Jun 2020 08:22:04 +0100 Message-ID: <010401d6408a$2c57bba0$850732e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJVAhO9pRR+GTACAAMIE1rLmlKQ5KfXD/qg X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Juergen Gross' , 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 10 June 2020 12:40 > To: Xen-devel > Cc: Andrew Cooper ; Ian Jackson ; Wei Liu > ; Juergen Gross ; Paul Durrant > Subject: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() > > c/s 6902cb00e03 "tools/libxendevicemodel: extract functions and add a compat > layer" introduced calls to both xencall_open() and osdep_xendevicemodel_open() > but failed to fix up the error path. > > c/s f68c7c618a3 "libs/devicemodel: free xencall handle in error path in > _open()" fixed up the xencall_open() aspect of the error path (missing the > osdep_xendevicemodel_open() aspect), but positioned the xencall_close() > incorrectly, creating the same pattern proved to be problematic by c/s > 30a72f02870 "tools: fix error path of xenhypfs_open()". > > Reposition xtl_logger_destroy(), and introduce the missing > osdep_xendevicemodel_close(). > > Fixes: 6902cb00e03 ("tools/libxendevicemodel: extract functions and add a compat layer") > Fixes: f68c7c618a3 ("libs/devicemodel: free xencall handle in error path in _open()") > Backport: 4.9+ > Signed-off-by: Andrew Cooper > --- > CC: Ian Jackson > CC: Wei Liu > CC: Juergen Gross > CC: Paul Durrant > > RFC - this is still broken. > I'm slightly confused. Do you want this in 4.14 in this form or are you expecting to update it? Paul > Failure to create the logger will still hit the NULL deference, in all of the > stable libs, not just devicemodel. > > Also, unless I'd triple checked the history, I was about to reintroduce the > deadlock from c/s 9976f3874d4, because it totally counterintuitive wrong to > expect setup and teardown in opposite orders. > --- > tools/libs/devicemodel/core.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c > index db501d9e80..4d4063956d 100644 > --- a/tools/libs/devicemodel/core.c > +++ b/tools/libs/devicemodel/core.c > @@ -67,9 +67,10 @@ xendevicemodel_handle *xendevicemodel_open(xentoollog_logger *logger, > return dmod; > > err: > - xtl_logger_destroy(dmod->logger_tofree); > + osdep_xendevicemodel_close(dmod); > xentoolcore__deregister_active_handle(&dmod->tc_ah); > xencall_close(dmod->xcall); > + xtl_logger_destroy(dmod->logger_tofree); > free(dmod); > return NULL; > } > -- > 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 07:26:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 07:26:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jje5Q-0002in-Gs; Fri, 12 Jun 2020 07:26:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jje5P-0002ii-HN for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 07:26:47 +0000 X-Inumbo-ID: 12a92c24-ac7e-11ea-b5a9-12813bfff9fa Received: from smtp-fw-4101.amazon.com (unknown [72.21.198.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 12a92c24-ac7e-11ea-b5a9-12813bfff9fa; Fri, 12 Jun 2020 07:26:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1591946807; x=1623482807; h=from:to:cc:date:message-id:references:in-reply-to: subject; bh=Gv7WpITLdtg6iAX5fZwcKGidq7U8WRL1dUAGgivqaZk=; b=Fq4JWvKmfU5qJkzA+QXhyv+fFGsxbdBj6DU4jTl1UNA5XP/nB+iCowHU BJBE6vYAY1dDyRU7Iog1jjaTgKPLTrFnrv8WZkKe6PB1h8OzU4YkZ1+fr wyIoggol2s4UH72IfiAe0NAFxXAH1lfmOpxX8C0QJYTUsHA/iuoXnBua+ Q=; IronPort-SDR: TcehYbUbmq6pbDx/b/6wUmkyMFYAM4Lp61bp/D7Rcr3nbd7TvTPP6W5ZQxs7UwGEQfpxDtnQjx y/AKg9xAxiVg== X-Amazon-filename: signature.asc X-IronPort-AV: E=Sophos;i="5.73,502,1583193600"; d="asc'?scan'208";a="35886219" Subject: Re: [Xen-devel] [PATCH v6 00/12] livepatch: new features and fixes Thread-Topic: [Xen-devel] [PATCH v6 00/12] livepatch: new features and fixes Content-Type: multipart/mixed; boundary="===============2077416797144381260==" MIME-Version: 1.0 Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-97fdccfd.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 12 Jun 2020 07:26:46 +0000 Received: from EX13MTAUEA002.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-97fdccfd.us-east-1.amazon.com (Postfix) with ESMTPS id 26B30A239D; Fri, 12 Jun 2020 07:26:45 +0000 (UTC) Received: from EX13D05EUB004.ant.amazon.com (10.43.166.115) by EX13MTAUEA002.ant.amazon.com (10.43.61.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 07:26:44 +0000 Received: from EX13D05EUB004.ant.amazon.com (10.43.166.115) by EX13D05EUB004.ant.amazon.com (10.43.166.115) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 07:26:43 +0000 Received: from EX13D05EUB004.ant.amazon.com ([10.43.166.115]) by EX13D05EUB004.ant.amazon.com ([10.43.166.115]) with mapi id 15.00.1497.006; Fri, 12 Jun 2020 07:26:43 +0000 From: "Wieczorkiewicz, Pawel" To: George Dunlap Thread-Index: AQHVpEFsXeSzz5AaaUmaNlPNC592QqjUpX2AgAEnowA= Date: Fri, 12 Jun 2020 07:26:43 +0000 Message-ID: <132B69F5-3456-4F92-9FBD-83CAE3E0F3FB@amazon.com> References: <20191126100801.124844-1-wipawel@amazon.de> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.164.88] MIME-Version: 1.0 Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Wieczorkiewicz, Pawel" , Paul Durrant , George Dunlap , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --===============2077416797144381260== Content-Language: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_7E65F1F9-B422-4937-B48E-C252D1B939B3"; protocol="application/pgp-signature"; micalg=pgp-sha256 --Apple-Mail=_7E65F1F9-B422-4937-B48E-C252D1B939B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 11. Jun 2020, at 15:48, George Dunlap wrote: >=20 > CAUTION: This email originated from outside of the organization. Do = not click links or open attachments unless you can confirm the sender = and know the content is safe. >=20 >=20 >=20 >=20 > On Tue, Nov 26, 2019 at 10:14 AM Pawel Wieczorkiewicz = wrote: > This series introduces new features to the livepatch functionality as > briefly discussed during Xen Developer Summit 2019: [a] and [b]. > It also provides a few fixes and some small improvements. >=20 > Main changes in v6: > - Added missing action pad field zeroing >=20 > Main changes in v4: > - Fix various typos and minor issues > - Simplify arch_livepatch_{apply,revert} by using > common_livepatch_{apply,revert} > - Improve python bindings and fix few issues >=20 > Main changes in v3: > - Fix expectation test to work on Arm > - Add test for metadata (Konrad) > - Minor fixes to documentation >=20 > Main changes in v2: > - added new features to livepatch documentation > - added livepatch tests > - enabled Arm support for [5] > - make .modinfo optional for [11] > - fixed typos >=20 > FEATURES: >=20 > 1. independent modules (patches: [1], [2]) >=20 > * livepatch-build-tools repo dependency [A] >=20 > Livepatch enforces the following buildid-based dependency chain > between hotpatch modules: > 1) first module depends on given hypervisor buildid > 2) every consecutive module depends on previous module's buildid > This way proper hotpatch stack order is maintained and enforced. > While it is important for production hotpatches it limits agility = and > blocks usage of testing or debug hotpatches. These kinds of hotpatch > modules are typically expected to be loaded at any time irrespective > of current state of the modules stack. >=20 > [A] livepatch-build: Embed hypervisor build id into every hotpatch >=20 > 2. pre- and post- apply|revert actions hooks (patches: [3], [4]) >=20 > * livepatch-build-tools repo dependency [B] >=20 > This is an implementation of 4 new livepatch module vetoing hooks, > that can be optionally supplied along with modules. > Hooks that currently exists in the livepatch mechanism aren't agile > enough and have various limitations: > * run only from within a quiescing zone > * cannot conditionally prevent applying or reverting > * do not have access to the module context > To address these limitations the following has been implemented: > 1) pre-apply hook > 2) post-apply hook > 3) pre-revert hook > 4) post-revert hook >=20 > [B] create-diff-object: Handle extra pre-|post- hooks >=20 > 3. apply|revert actions replacement hooks (patches: [5], [6], [7]) >=20 > * livepatch-build-tools repo dependency: [C], [D], [E] >=20 > To increase hotpatching system's agility and provide more flexiable > long-term hotpatch solution, allow to overwrite the default apply > and revert action functions with hook-like supplied alternatives. > The alternative functions are optional and the default functions are > used by default. >=20 > [C] create-diff-object: Do not create empty .livepatch.funcs section > [D] create-diff-object: Handle optional apply|revert hooks > [E] create-diff-object: Add support for applied/reverted marker >=20 > 4. inline asm hotpatching expectations (patches: [8]) >=20 > * livepatch-build-tools repo dependency: [F] >=20 > Expectations are designed as optional feature, since the main use of > them is planned for inline asm hotpatching. > The payload structure is modified as each expectation structure is > part of the livepatch_func structure and hence extends the payload. > The payload version is bumped to 3 with this change to highlight the > ABI modification and enforce proper support. > The expectation is manually enabled during inline asm module > construction. If enabled, expectation ensures that the expected > content of memory is to be found at a given patching (old_addr) > location. >=20 > [F] create-diff-object: Add support for expectations >=20 > 5. runtime hotpatch metadata support (patches: [9], [10], [11]) >=20 > Having detailed hotpatch metadata helps to properly identify = module's > origin and version. It also allows to keep track of the history of > hotpatch loads in the system (at least within dmesg buffer size > limits). > Extend the livepatch list operation to fetch also payloads' = metadata. > This is achieved by extending the sysctl list interface with 2 extra > guest handles: > * metadata - an array of arbitrary size strings > * metadata_len - an array of metadata strings' lengths (uin32_t = each) > To unify and simplify the interface, handle the modules' name = strings > of arbitrary size by copying them in adhering chunks to the = userland. >=20 > 6. python bindings for livepatch operations (patches: [12]) >=20 > Extend the XC python bindings library to support all common = livepatch > operations and actions: > - status (pyxc_livepatch_status): > - action (pyxc_livepatch_action): > - upload (pyxc_livepatch_upload): > - list (pyxc_livepatch_list): >=20 > This series looks like it would be a good candidate for a CHANGELOG.md = line. >=20 > What about something like this: >=20 > - Livepatch improvements: Buildid / hotpatch "stack" restrictions, = Additional {pre,post}-{apply,revert} hooks, inline hotpatching = expectations, runtime hotpatch metdata, python bindings for livepatch = operations >=20 LGTM, thanks! Is there anything I have to do? Best, Pawel Wieczorkiewicz --Apple-Mail=_7E65F1F9-B422-4937-B48E-C252D1B939B3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEMfesMdpdS8dLoCFipZXgubqFgvsFAl7jLjIACgkQpZXgubqF gvs/BxAAgHdy3Vy+RRShrUKQX8dvK/5w3A8MNTAzsVnxL7sShQlotSMImMXAa0+z IJE0TYV5eg81t2g/dWIkPYnIjiNpWpDiCpyUtG0DzvUDIjE3afBzvetHEFdb4ifV 9DTds9lB9rEJeh+kwXeqADPl2CwCWqTJgrK6E94OLJgy3snf0V6C14YcYZCZQlBs NnqSuAweQSVM+LDLzZJyqGSkZnXityH6XbQF3RWjDKfUYyVobZELgmlhvgoYOcJg HETAct229wNR166npsdVdP1m4X1t1QRjOsoSXmF42NzsJ7cSyohP83Jb0cPJZ+BB ojnC2q4H1CG5kTUOaUutxuf4PHIklPga0pBivwqSWYDlMinhLid4mS7jTJiqlIpL /V8XkHKvi9/wm7ZxApZjBDPP41EHnah9sfV1BULSPMgxxpltXTE7WlvRCVTAMUyW Lm0sEgEL7aNr3yoEQs9V+kIyUR+KHeJmLfw18orePoFcBitSPWt3d9S8YiwUyxPl ZCDTDmQF7LaXaRWXC3YqEbriCfph62r/I9t4JiYc+0lWcPAF0o4mENN+WDJJv1dc Y34HNDh/N+LtOdLp6i0faUmQpsJZqY3PTrjL49Hd/8gpfsnHXXQWFj6teZPJJEsS QAGGJNXx6fAyTxxXzTZPcZzI4MESIg2pTvQK7ciyk8o55uGZP4s= =Uqv6 -----END PGP SIGNATURE----- --Apple-Mail=_7E65F1F9-B422-4937-B48E-C252D1B939B3-- --===============2077416797144381260== Content-Type: multipart/alternative; boundary="===============4914724027337992393==" MIME-Version: 1.0 Content-Disposition: inline --===============4914724027337992393== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 --===============4914724027337992393== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable


Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


--===============4914724027337992393==-- --===============2077416797144381260==-- From xen-devel-bounces@lists.xenproject.org Fri Jun 12 08:08:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 08:08:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjejQ-0006m9-Bx; Fri, 12 Jun 2020 08:08:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjejO-0006lC-7k for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 08:08:06 +0000 X-Inumbo-ID: d73eec72-ac83-11ea-b5ab-12813bfff9fa Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.88]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d73eec72-ac83-11ea-b5ab-12813bfff9fa; Fri, 12 Jun 2020 08:08:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wI0D4WK3ZZoPQKZo56XN11J757dcoA2QPzgTlbGiM4I=; b=6F3s6Zz7HjHJ6IfIFnGl0qV3YTHm8Ypu6IGcF1VACdRlqVZUOPdvh+0bNBSMrSCQQc21s16UWk32AOruMm3Gk//oagIjChsCZ/Eke6Brc4hh6dpSjSX0f90wQw9fEQ5EM8OSiwOltr/DLHcAHpkCY//UWxgQtfUqW4YlPrW3Nl8= Received: from AM6P194CA0066.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::43) by VI1PR08MB3503.eurprd08.prod.outlook.com (2603:10a6:803:7a::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 08:08:01 +0000 Received: from AM5EUR03FT032.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:84:cafe::53) by AM6P194CA0066.outlook.office365.com (2603:10a6:209:84::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.20 via Frontend Transport; Fri, 12 Jun 2020 08:08:01 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT032.mail.protection.outlook.com (10.152.16.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 08:08:01 +0000 Received: ("Tessian outbound 3e82c366635e:v59"); Fri, 12 Jun 2020 08:08:01 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 69a1fdb861356eb9 X-CR-MTA-TID: 64aa7808 Received: from dbca1b61fe23.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 941DC016-8AE6-4ED5-AE95-3DCFD275119C.1; Fri, 12 Jun 2020 08:07:55 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id dbca1b61fe23.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Jun 2020 08:07:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gHq31x/AHsnB9MQl3pU/APQGBtQjltM2zlgIR9rDUGgcWyTG/GMxjOR/82R7eVOASxDTujhjFOpux9+94vt0+MAFwJt3Kg2GX6zkrL02jU9ALML2vxgV5FxHxAlVhjBO2MfjRHivvvJc7SFppRvbmPrFnK1/pMAaDzDeJ8ffzgLgrzrM8pM6gMr6zVOxjYgQ8ni+ALwmhYx8Efu5Z6NxfcHnGcKfiWduvHLi1DALKSQVXfQ6BiuVMOGOQmE0vhJ2OQSKNYNTWAZKdLuX/OR5LjahhFRUIKedzBmkbaJtxK1+aUqIQZq/rUI3k8uW7z+bNwLbMD/t5p8yhqAm1NNPSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wI0D4WK3ZZoPQKZo56XN11J757dcoA2QPzgTlbGiM4I=; b=EtIx+pEcfvuz3moyfe4vIfpMMvj/OKlPSqZX4t81vYuuZkBzhJkHVZXlHNa8usJmxKdzuNcL9MSU5VRFzE/x/cgEsIQCIdZem9QCDUk+1WsqMR1NFYgQ1i6DWUMeo9TArJ2KXzxrNeQS910oTlQFwppfLp0Rp6u3NC3db+YqsuO8C+10Uj8brRfGinNCUCBlY8yIeotF8/9beHOGzCT1qnqhfTFkGiyGA6n28ZJzPxMxxi7inRPPRvz555PxrGaSOVa8ysyDM5AdObt7WUQ7gghlOXIPFgbCVrVuxlWObrlJy5QncrPwHdJOVNDIeBq6GQaqIzxxzxzSt1iCvQrQSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wI0D4WK3ZZoPQKZo56XN11J757dcoA2QPzgTlbGiM4I=; b=6F3s6Zz7HjHJ6IfIFnGl0qV3YTHm8Ypu6IGcF1VACdRlqVZUOPdvh+0bNBSMrSCQQc21s16UWk32AOruMm3Gk//oagIjChsCZ/Eke6Brc4hh6dpSjSX0f90wQw9fEQ5EM8OSiwOltr/DLHcAHpkCY//UWxgQtfUqW4YlPrW3Nl8= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3147.eurprd08.prod.outlook.com (2603:10a6:5:1d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Fri, 12 Jun 2020 08:07:54 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Fri, 12 Jun 2020 08:07:54 +0000 From: Bertrand Marquis To: Stefano Stabellini Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Topic: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Index: AQHWP+e0l1aGgjLKI0+XFOOVnv/iZKjTuR6AgADoN4A= Date: Fri, 12 Jun 2020 08:07:54 +0000 Message-ID: <50E28FC8-23BD-4821-8C90-99D99F5B9C30@arm.com> References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0e45e2bd-62e0-4d2b-56ae-08d80ea7b9b7 x-ms-traffictypediagnostic: DB7PR08MB3147:|VI1PR08MB3503: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882; x-forefront-prvs: 0432A04947 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: h8JqfCfwOksZU3nfJxjcbA11PToyK5Q6KKYUzEzz9szP/6W4gnkRTLHqnNSDrbZWZ6LJgHA/vpYHdaqJwMFSmDaEoTheKaudv5A5yYgPSE83CABDW8/GLA5eCIXzWQKYts3jQTmzkxM7/uUjBlPr2obGjteqLU8X70E7UXnvhx44is23xIgX/hlxlyKl2wzanLg7fXjb85rrEEjbMmj8CTj31XjoznpsVCruQKyiHkiaKHqLlxf6szph+MYcYBRR55jJDH/DfbhsLvOtrI/ofx3V+BPoh/CL+U4mDqTkEw/GElBigepcGzDb0aITGme526EjUihacWZ3qfzzg2Ja8Q== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(39860400002)(396003)(376002)(346002)(7416002)(86362001)(8936002)(83380400001)(30864003)(33656002)(54906003)(316002)(4326008)(6486002)(6512007)(6916009)(64756008)(26005)(478600001)(66556008)(76116006)(6506007)(8676002)(186003)(53546011)(5660300002)(66476007)(2616005)(66446008)(91956017)(66946007)(36756003)(2906002)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9olJMDahjEQnJ88KLdTMW9kXHH6wYkDHJX21b5pFs5baensdjxS5mtcKWzbTWJTKMdc8zXSI3oS8OIph8CWgRuPIQxpPMH6YNMIn5i3Fa9e6oBtpD95RHyS7D34k+SPwumpVqtoD56stkZQo3DfOWsxFN/HismuVKJQeuqdl+dKpGPsJYXZp2JM8f6LRLZPvnqAWGzUfQmwW8Sio8oLZPkW8/638F+Z2BhXANM+v0bWAyplg2H+pBJGJ/6EuXt+NijZNCiRpD5sdjLnf9NFAGUsoQBu3yn/Hm/QaZ4b0GaJhikvkfaZkfQJ7YaiRZXqb/ouEeBWeo+CAxmaZtIKqnDxKkWNs/GY1bpTT2/lG0Byzuqf/iSeTLDdJVp5eIC/r7gexcDITCDlpoCp/0KSb3pi4Z+kkkQxWQ7bFJT+D92Xs9ED2JSUskIG8CCcDa+KOqywnx47Yn265dhl8ieYZp14cPpOwWHIduSalibfRdo0GPipshGl500C27C3Mrvuo x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: <66DDD5A14A7D654DBB32604D7FE99C19@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3147 Original-Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT032.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(39860400002)(376002)(396003)(46966005)(356005)(83380400001)(478600001)(30864003)(33656002)(47076004)(26005)(86362001)(82310400002)(2616005)(336012)(70586007)(36756003)(70206006)(186003)(53546011)(6506007)(81166007)(82740400003)(5660300002)(6512007)(8676002)(316002)(8936002)(4326008)(36906005)(6486002)(54906003)(107886003)(2906002)(6862004); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 08da0780-1984-4cbf-2349-08d80ea7b5c0 X-Forefront-PRVS: 0432A04947 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lcmPGlNMESZleIJs6FOpav4gmF5n48iAIum2uouxzKdoUTFigdZBKNQ+7Y7YA4hMk7NvL8TEcXjWYYvpIP/maGR8A5arvBlvlT4dNDKolrMj6DSzX9fKHQf3MsJijhdyqhZHdtXyVMcMeymRvQeIzqQ51jNzBwc9hQkzvsAAV61626koYpRzLr4qAFePkKaCtrGpB58yA45qwaYD8AAod4cdOrQfknvLTgiFWwm4UaD0o5MhmrAGnZBrn9/jkgTc2c/zrTB46lJH9RCt0z3WIn40MqS1ze2kyeMi5C8KPJOd6DhNWEUcx7ecozbIKNuA+HL6hbPzPDN2vuiOicJRMVY715c9GTgfmJn4yiJOz8L/6G8r83gmlP6lJX/yDk4Sv3wsXp1QZqMWqHNufFQ/9A== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2020 08:08:01.0333 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0e45e2bd-62e0-4d2b-56ae-08d80ea7b9b7 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3503 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On 11 Jun 2020, at 19:16, Stefano Stabellini wro= te: >=20 > On Thu, 11 Jun 2020, Bertrand Marquis wrote: >> At the moment on Arm, a Linux guest running with KTPI enabled will >> cause the following error when a context switch happens in user mode: >> (XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xffffff837ebe0cd0 >>=20 >> This patch is modifying the register runstate area handling on arm to >> convert the guest address during the hypercall. During runtime context >> switches the area is mapped to update the guest runstate copy. >> The patch is also removing the initial copy which was done during the >> hypercall handling as this is done on the current core when the context >> is restore to go back to guest execution on arm. >>=20 >> As a consequence if the register runstate hypercall is called on one >> vcpu for an other vcpu, the area will not be updated until the vcpu >> will be executed (on arm only). >>=20 >> On x86, the behaviour is not modified, the address conversion is done >> during the context switch and the area is updated fully during the >> hypercall. >> inline functions in headers could not be used as the architecture >> domain.h is included before the global domain.h making it impossible >> to use the struct vcpu inside the architecture header. >> This should not have any performance impact as the hypercall is only >> called once per vcpu usually. >>=20 >> Signed-off-by: Bertrand Marquis >> --- >> xen/arch/arm/domain.c | 109 +++++++++++++++++++++++++++++------ >> xen/arch/x86/domain.c | 30 +++++++++- >> xen/arch/x86/x86_64/domain.c | 4 +- >> xen/common/domain.c | 19 ++---- >> xen/include/asm-arm/domain.h | 8 +++ >> xen/include/asm-x86/domain.h | 16 +++++ >> xen/include/xen/domain.h | 4 ++ >> xen/include/xen/sched.h | 16 +---- >> 8 files changed, 153 insertions(+), 53 deletions(-) >>=20 >> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c >> index 31169326b2..739059234f 100644 >> --- a/xen/arch/arm/domain.c >> +++ b/xen/arch/arm/domain.c >> @@ -19,6 +19,7 @@ >> #include >> #include >> #include >> +#include >>=20 >> #include >> #include >> @@ -275,36 +276,104 @@ static void ctxt_switch_to(struct vcpu *n) >> virt_timer_restore(n); >> } >>=20 >> -/* Update per-VCPU guest runstate shared memory area (if registered). *= / >> -static void update_runstate_area(struct vcpu *v) >> +void arch_cleanup_runstate_guest(struct vcpu *v) >> { >> - void __user *guest_handle =3D NULL; >> - struct vcpu_runstate_info runstate; >> + spin_lock(&v->arch.runstate_guest.lock); >>=20 >> - if ( guest_handle_is_null(runstate_guest(v)) ) >> - return; >> + /* cleanup previous page if any */ >> + if ( v->arch.runstate_guest.page ) >> + { >> + put_page_and_type(v->arch.runstate_guest.page); >> + v->arch.runstate_guest.page =3D NULL; >> + v->arch.runstate_guest.offset =3D 0; >> + } >>=20 >> - memcpy(&runstate, &v->runstate, sizeof(runstate)); >> + spin_unlock(&v->arch.runstate_guest.lock); >> +} >>=20 >> - if ( VM_ASSIST(v->domain, runstate_update_flag) ) >> +int arch_setup_runstate_guest(struct vcpu *v, >> + struct vcpu_register_runstate_memory_area a= rea) >> +{ >> + struct page_info *page; >> + unsigned offset; >> + >> + spin_lock(&v->arch.runstate_guest.lock); >> + >> + /* cleanup previous page if any */ >> + if ( v->arch.runstate_guest.page ) >> { >> - guest_handle =3D &v->runstate_guest.p->state_entry_time + 1; >> - guest_handle--; >> - runstate.state_entry_time |=3D XEN_RUNSTATE_UPDATE; >> - __raw_copy_to_guest(guest_handle, >> - (void *)(&runstate.state_entry_time + 1) - = 1, 1); >> - smp_wmb(); >> + put_page_and_type(v->arch.runstate_guest.page); >> + v->arch.runstate_guest.page =3D NULL; >> + v->arch.runstate_guest.offset =3D 0; >> + } >> + >> + offset =3D ((vaddr_t)area.addr.v) & ~PAGE_MASK; >> + if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) >> + { >> + spin_unlock(&v->arch.runstate_guest.lock); >> + gprintk(XENLOG_DEBUG, "Runstate is crossing pages\n"); >> + return -EINVAL; >> + } >> + >> + /* provided address must be aligned to a 64bit */ >> + if ( offset % alignof(struct vcpu_runstate_info) ) >> + { >> + spin_unlock(&v->arch.runstate_guest.lock); >> + gprintk(XENLOG_DEBUG, "Runstate pointer is not aligned\n"); >> + return -EINVAL; >> + } >> + >> + page =3D get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); >> + if ( !page ) >> + { >> + spin_unlock(&v->arch.runstate_guest.lock); >> + gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); >=20 > I would make all these XENLOG_WARNING or XENLOG_ERR, they are errors > after all. This last one I'd say "Could not map runstate point" and also > print the address. Ok I will fix it to Warning and change the message like this. >=20 >=20 >> + return -EINVAL; >> } >>=20 >> - __copy_to_guest(runstate_guest(v), &runstate, 1); >> + v->arch.runstate_guest.page =3D page; >> + v->arch.runstate_guest.offset =3D offset; >> + >> + spin_unlock(&v->arch.runstate_guest.lock); >> + >> + return 0; >> +} >> + >> + >> +/* Update per-VCPU guest runstate shared memory area (if registered). *= / >> +static void update_runstate_area(struct vcpu *v) >> +{ >> + struct vcpu_runstate_info *guest_runstate; >> + void *p; >> + >> + spin_lock(&v->arch.runstate_guest.lock); >>=20 >> - if ( guest_handle ) >> + if ( v->arch.runstate_guest.page ) >> { >> - runstate.state_entry_time &=3D ~XEN_RUNSTATE_UPDATE; >> + p =3D __map_domain_page(v->arch.runstate_guest.page); >> + guest_runstate =3D p + v->arch.runstate_guest.offset; >> + >> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) >> + { >> + v->runstate.state_entry_time |=3D XEN_RUNSTATE_UPDATE; >> + guest_runstate->state_entry_time |=3D XEN_RUNSTATE_UPDATE; >=20 > I think that this write to guest_runstate should use write_atomic or > another atomic write operation. I will answer at the end of the discussion on the subject. >=20 >=20 >> + smp_wmb(); >> + } >> + >> + memcpy(guest_runstate, &v->runstate, sizeof(v->runstate)); >> smp_wmb(); >> - __raw_copy_to_guest(guest_handle, >> - (void *)(&runstate.state_entry_time + 1) - = 1, 1); >> + >> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) >> + { >> + v->runstate.state_entry_time &=3D ~XEN_RUNSTATE_UPDATE; >> + guest_runstate->state_entry_time &=3D ~XEN_RUNSTATE_UPDATE; >=20 > same here >=20 >=20 >> + smp_wmb(); >> + } >> + >> + unmap_domain_page(p); >> } >> + >> + spin_unlock(&v->arch.runstate_guest.lock); >> } >>=20 >> static void schedule_tail(struct vcpu *prev) >> @@ -560,6 +629,8 @@ int arch_vcpu_create(struct vcpu *v) >> v->arch.saved_context.sp =3D (register_t)v->arch.cpu_info; >> v->arch.saved_context.pc =3D (register_t)continue_new_vcpu; >>=20 >> + spin_lock_init(&v->arch.runstate_guest.lock); >> + >> /* Idle VCPUs don't need the rest of this setup */ >> if ( is_idle_vcpu(v) ) >> return rc; >> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c >> index fee6c3931a..32bbed87d5 100644 >> --- a/xen/arch/x86/domain.c >> +++ b/xen/arch/x86/domain.c >> @@ -1642,6 +1642,30 @@ void paravirt_ctxt_switch_to(struct vcpu *v) >> wrmsr_tsc_aux(v->arch.msrs->tsc_aux); >> } >>=20 >> +int arch_setup_runstate_guest(struct vcpu *v, >> + struct vcpu_register_runstate_memory_area = area) >> +{ >> + struct vcpu_runstate_info runstate; >> + >> + runstate_guest(v) =3D area.addr.h; >> + >> + if ( v =3D=3D current ) >> + { >> + __copy_to_guest(runstate_guest(v), &v->runstate, 1); >> + } >> + else >> + { >> + vcpu_runstate_get(v, &runstate); >> + __copy_to_guest(runstate_guest(v), &runstate, 1); >> + } >> + return 0; >> +} >> + >> +void arch_cleanup_runstate_guest(struct vcpu *v) >> +{ >> + set_xen_guest_handle(runstate_guest(v), NULL); >> +} >> + >> /* Update per-VCPU guest runstate shared memory area (if registered). */ >> bool update_runstate_area(struct vcpu *v) >> { >> @@ -1660,8 +1684,8 @@ bool update_runstate_area(struct vcpu *v) >> if ( VM_ASSIST(v->domain, runstate_update_flag) ) >> { >> guest_handle =3D has_32bit_shinfo(v->domain) >> - ? &v->runstate_guest.compat.p->state_entry_time + 1 >> - : &v->runstate_guest.native.p->state_entry_time + 1; >> + ? &v->arch.runstate_guest.compat.p->state_entry_time + 1 >> + : &v->arch.runstate_guest.native.p->state_entry_time + 1; >> guest_handle--; >> runstate.state_entry_time |=3D XEN_RUNSTATE_UPDATE; >> __raw_copy_to_guest(guest_handle, >> @@ -1674,7 +1698,7 @@ bool update_runstate_area(struct vcpu *v) >> struct compat_vcpu_runstate_info info; >>=20 >> XLAT_vcpu_runstate_info(&info, &runstate); >> - __copy_to_guest(v->runstate_guest.compat, &info, 1); >> + __copy_to_guest(v->arch.runstate_guest.compat, &info, 1); >> rc =3D true; >> } >> else >> diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c >> index c46dccc25a..b879e8dd2c 100644 >> --- a/xen/arch/x86/x86_64/domain.c >> +++ b/xen/arch/x86/x86_64/domain.c >> @@ -36,7 +36,7 @@ arch_compat_vcpu_op( >> break; >>=20 >> rc =3D 0; >> - guest_from_compat_handle(v->runstate_guest.compat, area.addr.h)= ; >> + guest_from_compat_handle(v->arch.runstate_guest.compat, area.ad= dr.h); >>=20 >> if ( v =3D=3D current ) >> { >> @@ -49,7 +49,7 @@ arch_compat_vcpu_op( >> vcpu_runstate_get(v, &runstate); >> XLAT_vcpu_runstate_info(&info, &runstate); >> } >> - __copy_to_guest(v->runstate_guest.compat, &info, 1); >> + __copy_to_guest(v->arch.runstate_guest.compat, &info, 1); >>=20 >> break; >> } >> diff --git a/xen/common/domain.c b/xen/common/domain.c >> index 7cc9526139..0ca6bf4dbc 100644 >> --- a/xen/common/domain.c >> +++ b/xen/common/domain.c >> @@ -727,7 +727,10 @@ int domain_kill(struct domain *d) >> if ( cpupool_move_domain(d, cpupool0) ) >> return -ERESTART; >> for_each_vcpu ( d, v ) >> + { >> + arch_cleanup_runstate_guest(v); >> unmap_vcpu_info(v); >> + } >> d->is_dying =3D DOMDYING_dead; >> /* Mem event cleanup has to go here because the rings=20 >> * have to be put before we call put_domain. */ >> @@ -1167,7 +1170,7 @@ int domain_soft_reset(struct domain *d) >>=20 >> for_each_vcpu ( d, v ) >> { >> - set_xen_guest_handle(runstate_guest(v), NULL); >> + arch_cleanup_runstate_guest(v); >> unmap_vcpu_info(v); >> } >>=20 >> @@ -1484,7 +1487,6 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_= GUEST_HANDLE_PARAM(void) arg) >> case VCPUOP_register_runstate_memory_area: >> { >> struct vcpu_register_runstate_memory_area area; >> - struct vcpu_runstate_info runstate; >>=20 >> rc =3D -EFAULT; >> if ( copy_from_guest(&area, arg, 1) ) >> @@ -1493,18 +1495,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN= _GUEST_HANDLE_PARAM(void) arg) >> if ( !guest_handle_okay(area.addr.h, 1) ) >> break; >>=20 >> - rc =3D 0; >> - runstate_guest(v) =3D area.addr.h; >> - >> - if ( v =3D=3D current ) >> - { >> - __copy_to_guest(runstate_guest(v), &v->runstate, 1); >> - } >> - else >> - { >> - vcpu_runstate_get(v, &runstate); >> - __copy_to_guest(runstate_guest(v), &runstate, 1); >> - } >> + rc =3D arch_setup_runstate_guest(v, area); >>=20 >> break; >> } >> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h >> index 4e2f582006..3a7f53e13d 100644 >> --- a/xen/include/asm-arm/domain.h >> +++ b/xen/include/asm-arm/domain.h >> @@ -11,6 +11,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >>=20 >> @@ -206,6 +207,13 @@ struct arch_vcpu >> */ >> bool need_flush_to_ram; >>=20 >> + /* runstate guest info */ >> + struct { >> + struct page_info *page; /* guest page */ >> + unsigned offset; /* offset in page */ >> + spinlock_t lock; /* lock to access page */ >> + } runstate_guest; >> + >> } __cacheline_aligned; >>=20 >> void vcpu_show_execution_state(struct vcpu *); >> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h >> index e8cee3d5e5..f917b48cb8 100644 >> --- a/xen/include/asm-x86/domain.h >> +++ b/xen/include/asm-x86/domain.h >> @@ -11,6 +11,11 @@ >> #include >> #include >> #include >> +#ifdef CONFIG_COMPAT >> +#include >> +DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t); >> +#endif >> + >>=20 >> #define has_32bit_shinfo(d) ((d)->arch.has_32bit_shinfo) >>=20 >> @@ -626,6 +631,17 @@ struct arch_vcpu >> struct { >> bool next_interrupt_enabled; >> } monitor; >> + >> +#ifndef CONFIG_COMPAT >> +# define runstate_guest(v) ((v)->arch.runstate_guest) >> + XEN_GUEST_HANDLE(vcpu_runstate_info_t) runstate_guest; /* guest add= ress */ >> +#else >> +# define runstate_guest(v) ((v)->arch.runstate_guest.native) >> + union { >> + XEN_GUEST_HANDLE(vcpu_runstate_info_t) native; >> + XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t) compat; >> + } runstate_guest; >> +#endif >> }; >>=20 >> struct guest_memory_policy >> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h >> index 7e51d361de..d5d73ce997 100644 >> --- a/xen/include/xen/domain.h >> +++ b/xen/include/xen/domain.h >> @@ -63,6 +63,10 @@ void arch_vcpu_destroy(struct vcpu *v); >> int map_vcpu_info(struct vcpu *v, unsigned long gfn, unsigned offset); >> void unmap_vcpu_info(struct vcpu *v); >>=20 >> +int arch_setup_runstate_guest(struct vcpu *v, >> + struct vcpu_register_runstate_memory_area a= rea); >=20 > NIT: code style, the indentation is off Ok >=20 >=20 >> +void arch_cleanup_runstate_guest(struct vcpu *v); >> + >> int arch_domain_create(struct domain *d, >> struct xen_domctl_createdomain *config); >>=20 >> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h >> index ac53519d7f..fac030fb83 100644 >> --- a/xen/include/xen/sched.h >> +++ b/xen/include/xen/sched.h >> @@ -29,11 +29,6 @@ >> #include >> #include >>=20 >> -#ifdef CONFIG_COMPAT >> -#include >> -DEFINE_XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t); >> -#endif >> - >> /* >> * Stats >> * >> @@ -166,16 +161,7 @@ struct vcpu >> struct sched_unit *sched_unit; >>=20 >> struct vcpu_runstate_info runstate; >> -#ifndef CONFIG_COMPAT >> -# define runstate_guest(v) ((v)->runstate_guest) >> - XEN_GUEST_HANDLE(vcpu_runstate_info_t) runstate_guest; /* guest add= ress */ >> -#else >> -# define runstate_guest(v) ((v)->runstate_guest.native) >> - union { >> - XEN_GUEST_HANDLE(vcpu_runstate_info_t) native; >> - XEN_GUEST_HANDLE(vcpu_runstate_info_compat_t) compat; >> - } runstate_guest; /* guest address */ >> -#endif >> + >> unsigned int new_state; >>=20 >> /* Has the FPU been initialised? */ >> --=20 >> 2.17.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 08:12:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 08:12:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjenn-0007Xf-VJ; Fri, 12 Jun 2020 08:12:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjenn-0007Xa-EG for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 08:12:39 +0000 X-Inumbo-ID: 79a923a6-ac84-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 79a923a6-ac84-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 08:12:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LfUKUSXyDV4zoJoy+Chv4saQZfCYo9fuLXCiEK7gQFI=; b=ZBgyKgHegTza2wc3AfSZW3HTT o7yVneAwDULBVUaW47ygp/nqkNbJ5sobopUEWgZq4JUYce6Y0mk8zts6KgyoCo2Cpdw7Y9GDGiEr9 omq27yBxTdAXWUW+WjVxtc8iEPAr8bcmYP5Ub3tvkvD2ppW4jZupFYZaalC+ygS1ef4xQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjenk-0004N3-9m; Fri, 12 Jun 2020 08:12:36 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjenk-0008F3-2p; Fri, 12 Jun 2020 08:12:36 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjenk-0004P0-26; Fri, 12 Jun 2020 08:12:36 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.10-testing:build-amd64-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-arm64-libvirt:libvirt-build:fail:regression xen-4.10-testing:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression xen-4.10-testing:test-amd64-amd64-pygrub:debian-di-install:fail:regression xen-4.10-testing:test-amd64-i386-xl-raw:debian-di-install:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-armhf-libvirt:libvirt-build:fail:regression xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=934d6e1a77947662504cf4d5e36c9520e03aa731 X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Fri, 12 Jun 2020 08:12:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151033 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151033/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039 build-i386-prev 6 xen-build fail REGR. vs. 150039 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 150039 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 150039 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen 934d6e1a77947662504cf4d5e36c9520e03aa731 baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 37 days Failing since 150941 2020-06-09 17:05:34 Z 2 days 5 attempts Testing same since 151033 2020-06-11 01:50:35 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark John Thomson Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub fail test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw fail test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 934d6e1a77947662504cf4d5e36c9520e03aa731 Author: John Thomson Date: Tue May 15 11:48:43 2018 +1000 tools/ocaml/libs/xc fix gcc-8 format-truncation warning CC xenctrl_stubs.o xenctrl_stubs.c: In function 'failwith_xc': xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "%d: %s: %s", error->code, ^ xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028 snprintf(error_str, sizeof(error_str), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%d: %s: %s", error->code, ~~~~~~~~~~~~~~~~~~~~~~~~~~ xc_error_code_to_desc(error->code), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error->message); ~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1 m Signed-off-by: John Thomson Acked-by: Christian Lindig Release-acked-by: Juergen Gross (cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795) commit 6e636f297f12a52ce12db11ea0787dd541937ed6 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:50 2018 +0200 tools/misc: fix hypothetical buffer overflow in xen-lowmemd gcc-8 complains: xen-lowmemd.c: In function 'handle_low_mem': xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=] snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~ ~~~~ xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In practice it wouldn't happen, because 'data' contains string representation of 64-bit unsigned number (20 characters at most). But place a limit to mute gcc warning. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080) commit dfc0b23403a2f0069bc7b9c0c20dfe5513eb8fb5 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:52 2018 +0200 tools/blktap2: fix possible '\0' truncation gcc-8 complains: tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring': tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^ tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255 snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "- 1" in buffer size should be actually applied to message, to leave place for terminating '\0', not the other way around (truncate '\0' even if it would fit). In function 'tapdisk_control_open_image', inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10: tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'tapdisk_control_create_socket', inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9: tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block-qcow.c: In function 'qcow_create': block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(backing_filename, backing_file, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(backing_filename)); ~~~~~~~~~~~~~~~~~~~~~~~~~ I those cases, reduce size of copied string and make sure final '\0' is added. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a) commit 2f83654fa3331d1ec79275072f8742f175f82bc5 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:54 2018 +0200 tools/gdbsx: fix -Wstringop-truncation warning gcc-8 complains: gx_main.c: In function 'prepare_stop_reply': gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(buf, "watch:", 6); ^~~~~~~~~~~~~~~~~~~~~~~~~ Since terminating '\0' isn't needed here at all, switch to memcpy. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f) commit bf467cc828bde380e9201d8b49c7866a5b92d719 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:53 2018 +0200 tools/xenpmd: fix possible '\0' truncation gcc-8 complains: xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->oem_info, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->battery_type, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->serial_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->model_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy 31 chars, then make sure terminating '\0' is present. Those fields are passed to strlen and as '%s' for snprintf later. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b) commit 6df4d40d846eb5151a89d26d1a63d632c6b9eb55 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:49 2018 +0200 tools/libxc: fix strncpy size gcc-8 warns about possible truncation of trailing '\0'. Final character is overridden by '\0' anyway, so don't bother to copy it. This fixes compile failure: xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159) commit e20bb5818174e9d09389776cb14781b9c6436554 Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit a1a9b055a349748083665e42843f75d6db2c6a7b Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit afca67fafde22033b9a967ae197a10af5c654f02 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Fri Jun 12 08:13:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 08:13:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjeor-0007f9-Fd; Fri, 12 Jun 2020 08:13:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjeoq-0007f0-JV for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 08:13:44 +0000 X-Inumbo-ID: a14b3e94-ac84-11ea-bca7-bc764e2007e4 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (unknown [40.107.3.40]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a14b3e94-ac84-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 08:13:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jmuVIUdtNApXqzcE2Mpd2ddkUfC/c6IBk8nU/VC/09k=; b=fjQs/QBCTgxsSoQhErPq8ZNkVAT6dnJpE8YpIlaNZ4tauahccKwVz8edtIXDi9j4X81TiJ6jy0T7Lhdwv2nOdXdrFHwweF5zQ+jR/jl8IJ3MfyzbWtHW188mvy6HsaLdX44nJtoc8q3Ig9+/Z00qmke+VdHjCaYFbNhu15P5gCM= Received: from AM6P195CA0048.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:87::25) by DB8PR08MB5196.eurprd08.prod.outlook.com (2603:10a6:10:ee::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 08:13:40 +0000 Received: from VE1EUR03FT027.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:87:cafe::e7) by AM6P195CA0048.outlook.office365.com (2603:10a6:209:87::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Fri, 12 Jun 2020 08:13:40 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT027.mail.protection.outlook.com (10.152.18.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 08:13:40 +0000 Received: ("Tessian outbound fb809da9b456:v59"); Fri, 12 Jun 2020 08:13:39 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 2f419176ede4c70c X-CR-MTA-TID: 64aa7808 Received: from e213b64003be.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id DFB9E382-A45C-4AB8-B40C-B15C1C2FB1ED.1; Fri, 12 Jun 2020 08:13:34 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e213b64003be.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Jun 2020 08:13:34 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CADSmU/zxgAyW9gxqbMoiQueWxWm0pPp6FRx+uO3eX586YniTh1HoN1b36U2j7ioYUT1/6/j2Ckx2eSp8HUAusdyFe70yqAFbGOiGPPhOG5vsU6fbtYHcsbutIYOjlFFISVNilEWsSPZyEqS2998VwPuf7woL4OA7hVGVuxhm/BN+2SArqvhQITtFtO8FLBOsDxhwiGlOZ0qbLWxnRaCZt+xykhademe1w/O4hVtlay0R3zAnzONcJlVPKWDnyQz+eJ+4yZQAYTLD4Z6+94BOnOICOWMJnIdcZA1u65jiVJIspSzKevOwNoR7Fy4vR1O1gx06g4HxxD3biCFO/T2vQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jmuVIUdtNApXqzcE2Mpd2ddkUfC/c6IBk8nU/VC/09k=; b=iYJN72fX3EoC8w6+kvcHcvTG15pNG/xcdxV1es7GhbFvlUn8bSW/vN5XZSkpatO2kgpW9DpBh2KvWK0HGXFycvL07pknVCqekdq2wcfG/q7PLl3NkSKwDT2liOBUFKzH52gzlvMO9VQr4K8wmspwky34Y39FjREYZXEqTMjaXt1bIwq2bdTuPtXXVB57B3xRz+DJFE7+jLLL+NPEtSV5iL3TEeMaWQYNdRbZYqBkC4Ct2scbhKhC+V2KMYC+KCS2yI54v0n/TN/+I3AKnKQODCEThrnA3FQm90cFX2M8HPKFnbo2Lzy09C9OEcm0mEJlzwE5RwdDWM1fMWsGuQzFiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jmuVIUdtNApXqzcE2Mpd2ddkUfC/c6IBk8nU/VC/09k=; b=fjQs/QBCTgxsSoQhErPq8ZNkVAT6dnJpE8YpIlaNZ4tauahccKwVz8edtIXDi9j4X81TiJ6jy0T7Lhdwv2nOdXdrFHwweF5zQ+jR/jl8IJ3MfyzbWtHW188mvy6HsaLdX44nJtoc8q3Ig9+/Z00qmke+VdHjCaYFbNhu15P5gCM= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3418.eurprd08.prod.outlook.com (2603:10a6:10:27::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Fri, 12 Jun 2020 08:13:33 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Fri, 12 Jun 2020 08:13:33 +0000 From: Bertrand Marquis To: Stefano Stabellini Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Topic: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Index: AQHWP+e0l1aGgjLKI0+XFOOVnv/iZKjTuR6AgAACMICAAActAIAADWwAgABcfQCAAHaFAA== Date: Fri, 12 Jun 2020 08:13:33 +0000 Message-ID: <48F66B8F-3AEF-4E54-A572-C246F5A7C117@arm.com> References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [217.140.99.251] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: f5081cb1-9407-4240-d5b3-08d80ea883e9 x-ms-traffictypediagnostic: DB7PR08MB3418:|DB8PR08MB5196: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0432A04947 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: YjSLTgcPzmOdYf3Zh9arqmz4iL72ByhTrb2wfgjlyrLMFSEbS8plaUvGa9OndKHDbrBMakIk2A4zd6MfUad3fo/0lX6v57dH5L5OrVCsHKFEIVCZb9awPGaScxAI0/EsO6CmHbv3yz+g8RMf7P2Zd1K45sUXdPChoqrROgL7DSa2/sNujSHdDCYveF1z7eRmJrFOI1m5+yHViYp87ESZCv1UM9m9I4gpIJDcKJctzZN1HSMFgeNJ8dpVgzMNrL7kSpjqqv3/KHr0FH+NPinaaKZC8D1AfE6EX3NlO8iMS4HlVKveo7m3ugxKujMd4PVlhpOGBfqzHwHbNmOkJmal4R2kbOa99qZNRG58QkNF8vOSXX0E/2x+dJhaUWb6mLR9 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(136003)(346002)(396003)(366004)(5660300002)(186003)(71200400001)(4326008)(83380400001)(86362001)(26005)(2906002)(66476007)(66446008)(53546011)(36756003)(76116006)(316002)(91956017)(6512007)(478600001)(64756008)(66556008)(33656002)(6506007)(66946007)(8936002)(2616005)(6916009)(54906003)(7416002)(8676002)(6486002)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9zELu9p5KsBeNZSX4kcVt+U2Xlte2qjP6x8NEuqrRIK3P/HkRuyEvJrT5Yivc9RiGCmTeZG3Jl4+XRshAVo7IHL6Ls33AVBdwqIrnqjb43ScjNJS5mD5zXAVCZvzfKYNhQzRefv1PsKPcfVH4F9QSdID5LiRtpgMTkxcedQLyBdxMUm0vC1z3M6HIjM1aEpW5kx8qRsSsxRr06hO3U26oRyj3YsPEWCaIGOxigPxESAZxzXx8YJPisUyLWKxY7LVxQqlNyW2gquUE+0id9vqjwmZsfMx2+S42fH3qJED3ODi1Lcdg0amKEc4C6u389GBY2yf0TERjXfJ0B5+fUKzLjw/hwkLmLMZP44ZFTqIYEfI0m3rOd1G6+TvpMMPLoer4IT7WvQUVAcO6P/S7Vrpk+WsnsUZ5CWwmStb8kq/e0Zdr3hYpQvOZ3PNH0Z3co6vPTii/oE3dJh8h7nfRL2nA6TCNCm+7i3mQJJ6ZORDK/du7QMlyEeBdCkI9/Zv9Bil x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <63BE20181203A642A97560CE24E25108@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3418 Original-Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT027.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(136003)(39860400002)(346002)(46966005)(8936002)(8676002)(316002)(4326008)(6512007)(5660300002)(2906002)(6862004)(107886003)(36906005)(54906003)(6486002)(82740400003)(47076004)(86362001)(82310400002)(2616005)(83380400001)(478600001)(356005)(81166007)(53546011)(26005)(36756003)(6506007)(336012)(70206006)(33656002)(186003)(70586007)(21314003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 8edfc835-6c0e-45b7-f078-08d80ea87fea X-Forefront-PRVS: 0432A04947 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mZU6CA3bHtw5HAtNtl7u4fwMTrb5rdGOQ79PFyHQbBmpThX2mfTABs7XQAtul8MyjArwDh7AkxPZcNAgJ4/SVVFUczZaF6y9LZ1+X0ZdNlElZ0jnygmdHTtMuk8mpLT3wwoVQpleFrbJdOEbuFWDiTAS132IOiFV2sm+b4dzpJAKMcV0/zZdTFLLMaZZlPUFc3yx2DVE5koitn9uvFR5+cV3YRDuFoPVANodKYMKlAbAKtv67pvl8cO68rMPhxyuvcJErLHkXbJQqJWR6/M0dS7xXzkzk5YhzOVoXd2uIFA8NVRWeYU0ilpYA/7Pi2bNS5691tnw7Ajr7QOQJZ1U2KL/2TfLxf4EsBY1hY7AyJRxvGqes4JbLKivMlcBqEDshqlxUJpsEZrmkJp4Vm4zlFKMGs4o7ysjKyRc3Zhmtkw= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2020 08:13:40.2220 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f5081cb1-9407-4240-d5b3-08d80ea883e9 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB5196 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gMTIgSnVuIDIwMjAsIGF0IDAyOjA5LCBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFi ZWxsaW5pQGtlcm5lbC5vcmc+IHdyb3RlOg0KPiANCj4gT24gVGh1LCAxMSBKdW4gMjAyMCwgSnVs aWVuIEdyYWxsIHdyb3RlOg0KPj4gSGkgU3RlZmFubywNCj4+IA0KPj4gT24gMTEvMDYvMjAyMCAx OTo1MCwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOg0KPj4+IE9uIFRodSwgMTEgSnVuIDIwMjAs IEp1bGllbiBHcmFsbCB3cm90ZToNCj4+Pj4+PiArICAgICAgICByZXR1cm4gLUVJTlZBTDsNCj4+ Pj4+PiAgICAgIH0NCj4+Pj4+PiANCj4+Pj4+PiAtICAgIF9fY29weV90b19ndWVzdChydW5zdGF0 ZV9ndWVzdCh2KSwgJnJ1bnN0YXRlLCAxKTsNCj4+Pj4+PiArICAgIHYtPmFyY2gucnVuc3RhdGVf Z3Vlc3QucGFnZSA9IHBhZ2U7DQo+Pj4+Pj4gKyAgICB2LT5hcmNoLnJ1bnN0YXRlX2d1ZXN0Lm9m ZnNldCA9IG9mZnNldDsNCj4+Pj4+PiArDQo+Pj4+Pj4gKyAgICBzcGluX3VubG9jaygmdi0+YXJj aC5ydW5zdGF0ZV9ndWVzdC5sb2NrKTsNCj4+Pj4+PiArDQo+Pj4+Pj4gKyAgICByZXR1cm4gMDsN Cj4+Pj4+PiArfQ0KPj4+Pj4+ICsNCj4+Pj4+PiArDQo+Pj4+Pj4gKy8qIFVwZGF0ZSBwZXItVkNQ VSBndWVzdCBydW5zdGF0ZSBzaGFyZWQgbWVtb3J5IGFyZWEgKGlmIHJlZ2lzdGVyZWQpLg0KPj4+ Pj4+ICovDQo+Pj4+Pj4gK3N0YXRpYyB2b2lkIHVwZGF0ZV9ydW5zdGF0ZV9hcmVhKHN0cnVjdCB2 Y3B1ICp2KQ0KPj4+Pj4+ICt7DQo+Pj4+Pj4gKyAgICBzdHJ1Y3QgdmNwdV9ydW5zdGF0ZV9pbmZv ICpndWVzdF9ydW5zdGF0ZTsNCj4+Pj4+PiArICAgIHZvaWQgKnA7DQo+Pj4+Pj4gKw0KPj4+Pj4+ ICsgICAgc3Bpbl9sb2NrKCZ2LT5hcmNoLnJ1bnN0YXRlX2d1ZXN0LmxvY2spOw0KPj4+Pj4+IA0K Pj4+Pj4+IC0gICAgaWYgKCBndWVzdF9oYW5kbGUgKQ0KPj4+Pj4+ICsgICAgaWYgKCB2LT5hcmNo LnJ1bnN0YXRlX2d1ZXN0LnBhZ2UgKQ0KPj4+Pj4+ICAgICAgew0KPj4+Pj4+IC0gICAgICAgIHJ1 bnN0YXRlLnN0YXRlX2VudHJ5X3RpbWUgJj0gflhFTl9SVU5TVEFURV9VUERBVEU7DQo+Pj4+Pj4g KyAgICAgICAgcCA9IF9fbWFwX2RvbWFpbl9wYWdlKHYtPmFyY2gucnVuc3RhdGVfZ3Vlc3QucGFn ZSk7DQo+Pj4+Pj4gKyAgICAgICAgZ3Vlc3RfcnVuc3RhdGUgPSBwICsgdi0+YXJjaC5ydW5zdGF0 ZV9ndWVzdC5vZmZzZXQ7DQo+Pj4+Pj4gKw0KPj4+Pj4+ICsgICAgICAgIGlmICggVk1fQVNTSVNU KHYtPmRvbWFpbiwgcnVuc3RhdGVfdXBkYXRlX2ZsYWcpICkNCj4+Pj4+PiArICAgICAgICB7DQo+ Pj4+Pj4gKyAgICAgICAgICAgIHYtPnJ1bnN0YXRlLnN0YXRlX2VudHJ5X3RpbWUgfD0gWEVOX1JV TlNUQVRFX1VQREFURTsNCj4+Pj4+PiArICAgICAgICAgICAgZ3Vlc3RfcnVuc3RhdGUtPnN0YXRl X2VudHJ5X3RpbWUgfD0gWEVOX1JVTlNUQVRFX1VQREFURTsNCj4+Pj4+IA0KPj4+Pj4gSSB0aGlu ayB0aGF0IHRoaXMgd3JpdGUgdG8gZ3Vlc3RfcnVuc3RhdGUgc2hvdWxkIHVzZSB3cml0ZV9hdG9t aWMgb3INCj4+Pj4+IGFub3RoZXIgYXRvbWljIHdyaXRlIG9wZXJhdGlvbi4NCj4+Pj4gDQo+Pj4+ IEkgdGhvdWdodCBhYm91dCBzdWdnZXN0aW5nIHRoZSBzYW1lLCBidXQgIGd1ZXN0X2NvcHlfKiBo ZWxwZXJzIG1heSBub3QNCj4+Pj4gZG8gYSBzaW5nbGUgbWVtb3J5IHdyaXRlIHRvIHN0YXRlX2Vu dHJ5X3RpbWUuDQo+Pj4+IFdoYXQgYXJlIHlvdSB0cnlpbmcgdG8gcHJldmVudCB3aXRoIHRoZSB3 cml0ZV9hdG9taWMoKT8NCj4+PiANCj4+PiBJIGFtIHRoaW5raW5nIHRoYXQgd2l0aG91dCB1c2lu ZyBhbiBhdG9taWMgd3JpdGUsIGl0IHdvdWxkIGJlIChhdCBsZWFzdA0KPj4+IHRoZW9yZXRpY2Fs bHkpIHBvc3NpYmxlIGZvciBhIGd1ZXN0IHRvIHNlZSBhIHBhcnRpYWwgd3JpdGUgdG8NCj4+PiBz dGF0ZV9lbnRyeV90aW1lLCB3aGljaCBpcyBub3QgZ29vZC4gDQo+PiANCj4+IEl0IGlzIGFscmVh ZHkgdGhlIGNhc2Ugd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbiBhcyBYZW4gbWF5IHdyaXRl IGJ5dGUgYnkNCj4+IGJ5dGUuIFNvIGFyZSB5b3Ugc3VnZ2VzdGluZyB0aGUgZXhpc3RpbmcgY29k ZSBpcyBhbHNvIGJ1Z2d5Pw0KPiANCj4gV3JpdGluZyBieXRlIGJ5IGJ5dGUgaXMgYSBkaWZmZXJl bnQgY2FzZS4gVGhhdCBpcyBPSy4gSW4gdGhhdCBjYXNlLCB0aGUNCj4gZ3Vlc3QgY291bGQgc2Vl IHRoZSBzdGF0ZSBhZnRlciAzIGJ5dGVzIHdyaXR0ZW4gYW5kIGl0IHdvdWxkIGJlIGZpbmUgYW5k DQo+IGNvbnNpc3RlbnQuIElmIHRoaXMgaGFkbid0IGJlZW4gdGhlIGNhc2UsIHRoZW4geWVzLCB0 aGUgZXhpc3RpbmcgY29kZQ0KPiB3b3VsZCBhbHNvIGJlIGJ1Z2d5Lg0KPiANCj4gU28gaWYgd2Ug ZGlkIHRoZSB3cml0ZSB3aXRoIGEgbWVtY3B5LCBpdCB3b3VsZCBiZSBmaW5lLCBubyBuZWVkIGZv cg0KPiBhdG9taWNzOg0KPiANCj4gIG1lbWNweSgmZ3Vlc3RfcnVuc3RhdGUtPnN0YXRlX2VudHJ5 X3RpbWUsDQo+ICAgICAgICAgJnYtPnJ1bnN0YXRlLnN0YXRlX2VudHJ5X3RpbWUsDQo+ICAgICAg ICAgWFhYKTsNCj4gDQo+IA0KPiBUaGUgfD0gY2FzZSBpcyBkaWZmZXJlbnQ6IEdDQyBjb3VsZCBp bXBsZW1lbnQgaXQgaW4gYW55IHdheSBpdCBsaWtlcywNCj4gaW5jbHVkaW5nIGdvaW5nIHRocm91 Z2ggYSB6ZXJvLXdyaXRlIHRvIGFueSBvZiB0aGUgYnl0ZXMgaW4gdGhlIHdvcmQsIG9yDQo+IGRv aW5nIGFuIGFkZGl0aW9uIHRoZW4gYSBzdWJ0cmFjdGlvbi4gR0NDIGRvZXNuJ3QgbWFrZSBhbnkg Z3VhcmFudGVlcy4NCj4gSWYgd2Ugd2FudCBndWFyYW50ZWVzIHdlIG5lZWQgdG8gdXNlIGF0b21p Y3MuDQoNCldvdWxkbuKAmXQgdGhhdCByZXF1aXJlIGFsbCBhY2Nlc3NlcyB0byBzdGF0ZV9lbnRy eV90aW1lIHRvIHVzZSBhbHNvIGF0b21pYyBvcGVyYXRpb25zID8NCkluIHRoaXMgY2FzZSB3ZSBj b3VsZCBub3QgcHJvcGFnYXRlIHRoZSBjaGFuZ2VzIHRvIGEgZ3Vlc3Qgd2l0aG91dCBjaGFuZ2lu ZyB0aGUgaW50ZXJmYWNlIGl0c2VsZi4NCg0KQXMgdGhlIGNvcHkgdGltZSBuZWVkcyB0byBiZSBw cm90ZWN0ZWQsIHRoZSB3cml0ZSBiYXJyaWVycyBhcmUgdGhlcmUgdG8gbWFrZSBzdXJlIHRoYXQg ZHVyaW5nIHRoZSBjb3B5IHRoZSBiaXQgaXMgc2V0IGFuZCB0aGF0IHdoZW4gd2UgdW5zZXQgaXQs IHRoZSBjb3B5IGlzIGRvbmUuDQpJIGFkZGVkIGZvciB0aGlzIHB1cnBvc2UgYSBiYXJyaWVyIGFm dGVyIHRoZSBtZW1jcHkgdG8gbWFrZSBzdXJlIHRoYXQgd2hlbi9pZiB3ZSB1bnNldCB0aGUgYml0 IHRoZSBjb3B5IGhhcyBhbHJlYWR5IGJlZW4gZG9uZS4NCg0KQ2hlZXJzDQoNCkJlcnRyYW5kDQoN Cg0K From xen-devel-bounces@lists.xenproject.org Fri Jun 12 08:25:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 08:25:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjezx-00009B-GX; Fri, 12 Jun 2020 08:25:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjezw-000096-6s for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 08:25:12 +0000 X-Inumbo-ID: 3b748498-ac86-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3b748498-ac86-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 08:25:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=txcUfoiGspimgOYYu/8rbE+C3QgTxC7VpbR3EUnp4jo=; b=LlzB0EyU0y0pfxErrBlQuAT/As B8DaxKqyR2nBYVDiRUqE9DurDjYQX6Y3QTZ1jkmGttcjusDYqtV2A6uxaUVd3n/nJYKXQzUW5QgyP Tt2ig3yGBsxix6qDrsdrmgMNVq4sVN8/DTcx6IqHRynXQ7RhGmTt/yPSaMLp3/tZclW4=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjezs-0004bJ-3x; Fri, 12 Jun 2020 08:25:08 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjezr-00085Y-SU; Fri, 12 Jun 2020 08:25:08 +0000 Subject: Re: Kexec and libxenctlr.so To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Julien Grall , "xen-devel@lists.xenproject.org" , Anthony Perard , "wl@xen.org" , daniel.kiper@oracle.com References: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> <261293b1-f4c9-e41d-0c76-cd47fe5c0dc2@suse.com> <5602eebf-c149-17f7-37c9-b263ff290509@xen.org> <6fa3067c-2c71-bb8e-eab8-30f44782d002@xen.org> <6c662ac7-ee10-1ac1-5b9f-df9a02d00d5c@suse.com> From: Julien Grall Message-ID: Date: Fri, 12 Jun 2020 09:25:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <6c662ac7-ee10-1ac1-5b9f-df9a02d00d5c@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Juergen, On 12/06/2020 05:25, Jürgen Groß wrote: > On 11.06.20 18:00, Julien Grall wrote: >> >> >> On 11/06/2020 16:35, Jürgen Groß wrote: >>> On 11.06.20 17:27, Julien Grall wrote: >>>> Hi, >>>> >>>> On 11/06/2020 16:21, Jürgen Groß wrote: >>>>> On 11.06.20 16:57, Julien Grall wrote: >>>>>> Hi all, >>>>>> >>>>>> kexec-tools has an option to load dynamically libxenctlr.so (not >>>>>> .so.4.x) (see [1]). >>>>>> >>>>>> Given that the library has never been considered stable, it is >>>>>> probably a disaster that is waiting to happen. >>>>>> >>>>>> Looking at the tree kexec is using the follow libxc functions: >>>>>>     - xc_kexec_get_range() >>>>>>     - xc_kexec_load() >>>>>>     - xc_kexec_unload() >>>>>>     - xc_kexec_status() >>>>>>     - xc_kexec_exec() >>>>>>     - xc_version() >>>>>>     - xc_interface_open() >>>>>>     - xc_interface_close() >>>>>>     - xc_get_max_cpus() >>>>>>     - xc_get_machine_memory_map() >>>>>> >>>>>> I think it is uncontroversial that we want a new stable library >>>>>> for all the xc_kexec_* functions (maybe libxenexec)? >>>>>> >>>>>> However I am not entirely sure where to put the others. >>>>>> >>>>>> I am thinking to introduce libxensysctl for xc_get_max_cpus() as >>>>>> it is a XEN_SYSCTL. We could possibly include >>>>>> xc_get_machine_memory_map() (despite it is a XENMEM_). >>>>>> >>>>>> For xc_version(), I am thinking to extend libxentoolcore to also >>>>>> include "stable xen API". >>>>>> >>>>>> Any opinion on the approach? >>>>> >>>>> You could consider hypfs (at least for some of the functionality). >>>> >>>> That would work! >>>> >>>>> >>>>> xc_version() and xc_get_max_cpus() would be rather easy. >>>> >>>> I am guessing we will need a fallback to the normal hypercalls if >>>> hypfs is not present. >>> >>> Or we don't support kexec-tools running on a system without hypfs >>> (or the related functions would return an error on those systems). >> >> AFAICT, hypfs allows you to modify runtime parameters which is not >> required for kexec. > > Well, and? kexec won't use this functionality. > > libxenctrl allows to create domains, which isn't required for kexec. > And kexec doesn't do it. And so does libc... so that was clear not my point... > > We could still have the entry points for that functionality in > libxenexec, which could use libxenhypfs (and maybe others). > >> Such feature could be undesirable in some setup and therefore I don't >> think this is acceptable to impose that for kexec. > > If we really have setups where this would be an issue we'd need > to modify the flask integration of hypfs to be able to disallow > write access to hypfs. Or we could even add per-node access rights. ... Not everyone wants to use flask and I don't think this should be a condition to forbid runtime configuration change for all the system. You may want to set a minimal Xen with no runtime configuration support and no flask. Yet you may want to kexec for updating your Xen. Even with the runtime bits removed, I still don't think we should impose to build hypfs in the hypervisor given there are already always built hypercalls. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 09:19:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 09:19:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjfq0-0004Il-IH; Fri, 12 Jun 2020 09:19:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjfpz-0004If-Cw for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 09:18:59 +0000 X-Inumbo-ID: be3d291e-ac8d-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id be3d291e-ac8d-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 09:18:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DF29AADC5; Fri, 12 Jun 2020 09:18:59 +0000 (UTC) Subject: Re: Kexec and libxenctlr.so To: Julien Grall , Julien Grall , "xen-devel@lists.xenproject.org" , Anthony Perard , "wl@xen.org" , daniel.kiper@oracle.com References: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> <261293b1-f4c9-e41d-0c76-cd47fe5c0dc2@suse.com> <5602eebf-c149-17f7-37c9-b263ff290509@xen.org> <6fa3067c-2c71-bb8e-eab8-30f44782d002@xen.org> <6c662ac7-ee10-1ac1-5b9f-df9a02d00d5c@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Fri, 12 Jun 2020 11:18:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.20 10:25, Julien Grall wrote: > Hi Juergen, > > On 12/06/2020 05:25, Jürgen Groß wrote: >> On 11.06.20 18:00, Julien Grall wrote: >>> >>> >>> On 11/06/2020 16:35, Jürgen Groß wrote: >>>> On 11.06.20 17:27, Julien Grall wrote: >>>>> Hi, >>>>> >>>>> On 11/06/2020 16:21, Jürgen Groß wrote: >>>>>> On 11.06.20 16:57, Julien Grall wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> kexec-tools has an option to load dynamically libxenctlr.so (not >>>>>>> .so.4.x) (see [1]). >>>>>>> >>>>>>> Given that the library has never been considered stable, it is >>>>>>> probably a disaster that is waiting to happen. >>>>>>> >>>>>>> Looking at the tree kexec is using the follow libxc functions: >>>>>>>     - xc_kexec_get_range() >>>>>>>     - xc_kexec_load() >>>>>>>     - xc_kexec_unload() >>>>>>>     - xc_kexec_status() >>>>>>>     - xc_kexec_exec() >>>>>>>     - xc_version() >>>>>>>     - xc_interface_open() >>>>>>>     - xc_interface_close() >>>>>>>     - xc_get_max_cpus() >>>>>>>     - xc_get_machine_memory_map() >>>>>>> >>>>>>> I think it is uncontroversial that we want a new stable library >>>>>>> for all the xc_kexec_* functions (maybe libxenexec)? >>>>>>> >>>>>>> However I am not entirely sure where to put the others. >>>>>>> >>>>>>> I am thinking to introduce libxensysctl for xc_get_max_cpus() as >>>>>>> it is a XEN_SYSCTL. We could possibly include >>>>>>> xc_get_machine_memory_map() (despite it is a XENMEM_). >>>>>>> >>>>>>> For xc_version(), I am thinking to extend libxentoolcore to also >>>>>>> include "stable xen API". >>>>>>> >>>>>>> Any opinion on the approach? >>>>>> >>>>>> You could consider hypfs (at least for some of the functionality). >>>>> >>>>> That would work! >>>>> >>>>>> >>>>>> xc_version() and xc_get_max_cpus() would be rather easy. >>>>> >>>>> I am guessing we will need a fallback to the normal hypercalls if >>>>> hypfs is not present. >>>> >>>> Or we don't support kexec-tools running on a system without hypfs >>>> (or the related functions would return an error on those systems). >>> >>> AFAICT, hypfs allows you to modify runtime parameters which is not >>> required for kexec. >> >> Well, and? kexec won't use this functionality. >> >> libxenctrl allows to create domains, which isn't required for kexec. >> And kexec doesn't do it. > > And so does libc... so that was clear not my point... > >> >> We could still have the entry points for that functionality in >> libxenexec, which could use libxenhypfs (and maybe others). >> >>> Such feature could be undesirable in some setup and therefore I don't >>> think this is acceptable to impose that for kexec. >> >> If we really have setups where this would be an issue we'd need >> to modify the flask integration of hypfs to be able to disallow >> write access to hypfs. Or we could even add per-node access rights. > > ... Not everyone wants to use flask and I don't think this should be a > condition to forbid runtime configuration change for all the system. > > You may want to set a minimal Xen with no runtime configuration support > and no flask. Yet you may want to kexec for updating your Xen. > > Even with the runtime bits removed, I still don't think we should impose > to build hypfs in the hypervisor given there are already always built > hypercalls. There might be a misunderstanding here. I just wanted to point out that in case you need a new stable interface between kexec and the hypervisor you could consider using hypfs for that purpose instead of introducing a new hypercall. In case all hypercalls are already present, then fine. If not I don't see why introducing a new hypercall should be preferred over using an existing mechanism. Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 12 09:23:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 09:23:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjfub-00056q-5U; Fri, 12 Jun 2020 09:23:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjfua-00056l-Ep for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 09:23:44 +0000 X-Inumbo-ID: 694c4bc8-ac8e-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 694c4bc8-ac8e-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 09:23:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uvZCzwaqZgPntnmUnlhdv8YsVulwsIzCx9fgPNtiPZc=; b=BsjCPgKsurIfejLFhqsGviNsvN h9waYojxxCmbRhYANy4yYq9SafXa6HZVoYoL3vzNGv2RGYYLi555F5ZTfQrINaYHBb6dIbkhyPYdf 1ZNL78bYZHXni7XAyLevvamfNVfKr2KeVoFVtA+K5X8p8fXHsmc9elbo5rVX5k4XEWO4=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjfuY-0005fH-8A; Fri, 12 Jun 2020 09:23:42 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjfuY-0003Kv-0Y; Fri, 12 Jun 2020 09:23:42 +0000 Subject: Re: Kexec and libxenctlr.so To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Julien Grall , "xen-devel@lists.xenproject.org" , Anthony Perard , "wl@xen.org" , daniel.kiper@oracle.com References: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> <261293b1-f4c9-e41d-0c76-cd47fe5c0dc2@suse.com> <5602eebf-c149-17f7-37c9-b263ff290509@xen.org> <6fa3067c-2c71-bb8e-eab8-30f44782d002@xen.org> <6c662ac7-ee10-1ac1-5b9f-df9a02d00d5c@suse.com> From: Julien Grall Message-ID: <659d1348-56d9-0de7-960f-212a39596302@xen.org> Date: Fri, 12 Jun 2020 10:23:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 10:18, Jürgen Groß wrote: > I just wanted to point out that in case you need a new stable interface > between kexec and the hypervisor you could consider using hypfs for that > purpose instead of introducing a new hypercall. I am not looking to introduce a new interface with the hypervisor. Instead I am looking to have a stable library that can be used by Kexec. The underlying communication with the hypervisor doesn't need to be stable. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 09:53:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 09:53:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjgNc-0007aw-Uw; Fri, 12 Jun 2020 09:53:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjgNb-0007aA-9l for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 09:53:43 +0000 X-Inumbo-ID: 98b3d8be-ac92-11ea-b5b0-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 98b3d8be-ac92-11ea-b5b0-12813bfff9fa; Fri, 12 Jun 2020 09:53:42 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: VA5PqxmCpZsnA/rl8fUrRRvX420SqoeFC2oU1F/cBAy8d1F+lNya0RWBjF85hpF9JAU1J8d79O cqtYtRFM9MazDYRncU3JFBupSUlAMuGZkn/B7aboA88dL6r0XiG7oNJ9ZU5/eSIyzkaQH3sLMo 64gJlZtjXuikbs05MWYRkvAOKDgxTu98PRbPjgY3mXHf4UgQvhnVUmfpX9ehhsSvodw1VOAGWr yfFbWPDogms/AE0wZSWJMwzY9b6LbDkLEb8vpEbvHNCTXcroQ00CJfkA5TX1nBD3U+uFqtnYQ0 /AE= X-SBRS: 2.7 X-MesageID: 20656360 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,502,1583211600"; d="scan'208";a="20656360" Subject: Re: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() To: , 'Xen-devel' References: <20200610114004.30023-1-andrew.cooper3@citrix.com> <010401d6408a$2c57bba0$850732e0$@xen.org> From: Andrew Cooper Message-ID: <765b4fed-60d3-9c4a-d6b7-bcd9893c525b@citrix.com> Date: Fri, 12 Jun 2020 10:53:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <010401d6408a$2c57bba0$850732e0$@xen.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Juergen Gross' , 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 08:22, Paul Durrant wrote: >> -----Original Message----- >> From: Andrew Cooper >> Sent: 10 June 2020 12:40 >> To: Xen-devel >> Cc: Andrew Cooper ; Ian Jackson ; Wei Liu >> ; Juergen Gross ; Paul Durrant >> Subject: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() >> >> c/s 6902cb00e03 "tools/libxendevicemodel: extract functions and add a compat >> layer" introduced calls to both xencall_open() and osdep_xendevicemodel_open() >> but failed to fix up the error path. >> >> c/s f68c7c618a3 "libs/devicemodel: free xencall handle in error path in >> _open()" fixed up the xencall_open() aspect of the error path (missing the >> osdep_xendevicemodel_open() aspect), but positioned the xencall_close() >> incorrectly, creating the same pattern proved to be problematic by c/s >> 30a72f02870 "tools: fix error path of xenhypfs_open()". >> >> Reposition xtl_logger_destroy(), and introduce the missing >> osdep_xendevicemodel_close(). >> >> Fixes: 6902cb00e03 ("tools/libxendevicemodel: extract functions and add a compat layer") >> Fixes: f68c7c618a3 ("libs/devicemodel: free xencall handle in error path in _open()") >> Backport: 4.9+ >> Signed-off-by: Andrew Cooper >> --- >> CC: Ian Jackson >> CC: Wei Liu >> CC: Juergen Gross >> CC: Paul Durrant >> >> RFC - this is still broken. >> > I'm slightly confused. Do you want this in 4.14 in this form or are you expecting to update it? In this form, it is an improvement over before. There is still the crash described below which needs some form of figuring out and fixing. ~Andrew > > Paul > >> Failure to create the logger will still hit the NULL deference, in all of the >> stable libs, not just devicemodel. >> >> Also, unless I'd triple checked the history, I was about to reintroduce the >> deadlock from c/s 9976f3874d4, because it totally counterintuitive wrong to >> expect setup and teardown in opposite orders. >> --- >> tools/libs/devicemodel/core.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c >> index db501d9e80..4d4063956d 100644 >> --- a/tools/libs/devicemodel/core.c >> +++ b/tools/libs/devicemodel/core.c >> @@ -67,9 +67,10 @@ xendevicemodel_handle *xendevicemodel_open(xentoollog_logger *logger, >> return dmod; >> >> err: >> - xtl_logger_destroy(dmod->logger_tofree); >> + osdep_xendevicemodel_close(dmod); >> xentoolcore__deregister_active_handle(&dmod->tc_ah); >> xencall_close(dmod->xcall); >> + xtl_logger_destroy(dmod->logger_tofree); >> free(dmod); >> return NULL; >> } >> -- >> 2.11.0 > From xen-devel-bounces@lists.xenproject.org Fri Jun 12 09:53:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 09:53:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjgNX-0007aF-Ml; Fri, 12 Jun 2020 09:53:39 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjgNW-0007aA-Jj for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 09:53:38 +0000 X-Inumbo-ID: 958c32da-ac92-11ea-b5b0-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 958c32da-ac92-11ea-b5b0-12813bfff9fa; Fri, 12 Jun 2020 09:53:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SEIVc/Yz1hxdlqGX/ofEjIrjNOz6KZqGqNDqbSOUunk=; b=zCkbxHUVaW1J8DmMpSO/EdA5VZ NYwEoAys5Mc/pXFhBOFJB4m5NWnCtWyNa/3XX8RJXGw0Fm76oKHhqdSEIAIcSo1ib1/+I4goIBrHj aKCOy8ZcYQYmiK79HFBHgaqDiA/tNHx/TjcSpKZbPDaccez/APoQo26pSCcYWVu5IB9U=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjgNQ-0006CL-9P; Fri, 12 Jun 2020 09:53:32 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjgNQ-0005HV-2F; Fri, 12 Jun 2020 09:53:32 +0000 Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall To: Stefano Stabellini References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> From: Julien Grall Message-ID: Date: Fri, 12 Jun 2020 10:53:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Bertrand Marquis , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 02:09, Stefano Stabellini wrote: > On Thu, 11 Jun 2020, Julien Grall wrote: >> Hi Stefano, >> >> On 11/06/2020 19:50, Stefano Stabellini wrote: >>> On Thu, 11 Jun 2020, Julien Grall wrote: >>>>>> + return -EINVAL; >>>>>> } >>>>>> >>>>>> - __copy_to_guest(runstate_guest(v), &runstate, 1); >>>>>> + v->arch.runstate_guest.page = page; >>>>>> + v->arch.runstate_guest.offset = offset; >>>>>> + >>>>>> + spin_unlock(&v->arch.runstate_guest.lock); >>>>>> + >>>>>> + return 0; >>>>>> +} >>>>>> + >>>>>> + >>>>>> +/* Update per-VCPU guest runstate shared memory area (if registered). >>>>>> */ >>>>>> +static void update_runstate_area(struct vcpu *v) >>>>>> +{ >>>>>> + struct vcpu_runstate_info *guest_runstate; >>>>>> + void *p; >>>>>> + >>>>>> + spin_lock(&v->arch.runstate_guest.lock); >>>>>> >>>>>> - if ( guest_handle ) >>>>>> + if ( v->arch.runstate_guest.page ) >>>>>> { >>>>>> - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; >>>>>> + p = __map_domain_page(v->arch.runstate_guest.page); >>>>>> + guest_runstate = p + v->arch.runstate_guest.offset; >>>>>> + >>>>>> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) >>>>>> + { >>>>>> + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; >>>>>> + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; >>>>> >>>>> I think that this write to guest_runstate should use write_atomic or >>>>> another atomic write operation. >>>> >>>> I thought about suggesting the same, but guest_copy_* helpers may not >>>> do a single memory write to state_entry_time. >>>> What are you trying to prevent with the write_atomic()? >>> >>> I am thinking that without using an atomic write, it would be (at least >>> theoretically) possible for a guest to see a partial write to >>> state_entry_time, which is not good. >> >> It is already the case with existing implementation as Xen may write byte by >> byte. So are you suggesting the existing code is also buggy? It looks like I may have misread the code as we only copy one byte. But I still think this is fragile. For this context, I agree that a write_atomic() should do the job. However, I still want to answer to your comments below. > > Writing byte by byte is a different case. That is OK. In that case, the > guest could see the state after 3 bytes written and it would be fine and > consistent. Why? What does actually prevent a guest to see an in-between value? To give a concrete example, if the original value is 0xabc and you want to write 0xdef. Why would the guest never see 0xabf or 0xaec? > If this hadn't been the case, then yes, the existing code > would also be buggy. > > So if we did the write with a memcpy, it would be fine, no need for > atomics: > > memcpy(&guest_runstate->state_entry_time, > &v->runstate.state_entry_time, > XXX); > > > The |= case is different: GCC could implement it in any way it likes, > including going through a zero-write to any of the bytes in the word, or > doing an addition then a subtraction. GCC doesn't make any guarantees. > If we want guarantees we need to use atomics. Yes GCC can generate assembly for |= in any way it likes. But so does for memcpy(). So I still don't understand why one would be fine for you and not the other... Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 10:09:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 10:09:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjgcx-0000IX-Bm; Fri, 12 Jun 2020 10:09:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjgcw-0000IS-4e for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 10:09:34 +0000 X-Inumbo-ID: cfb4e4dc-ac94-11ea-bb8b-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cfb4e4dc-ac94-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 10:09:33 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id c71so7561469wmd.5 for ; Fri, 12 Jun 2020 03:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=MxgozEb2i3R/ZypnNmn6ONFzbH7k/LVj1DaDP20JXYk=; b=rdDSD0Sqo7CoUWmQBgYbwJxhEuZ8n+t1g8ucShTt9XiCODFpu4ZeiFwYitT9h/yXG8 LO8lHQ99ZCKBgLrB2S40fHfipwAFdKMml6SqL6MsIPxie+CMlClDBsH3y4i3t6+8zu7l LVShV3udvNKxq2BwYNxhjix1VL3B4FsC3OCub2I+yT7/zI8X6fGKYTTk9w0MRSa3TGwX caMXqWsZYrJ7CkXRNMIbTgAYbezfdgddk/xDHkUdLgX7rt57GWGcOGA7k2mUByUeAA1Q YqCCGDIfSBiiu3sBeNMwGMghrxCnGBCxLy56vyya3wwWgpUNGpRUCUQSoxgTFDIhHG/u hbrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=MxgozEb2i3R/ZypnNmn6ONFzbH7k/LVj1DaDP20JXYk=; b=ECen1mNFmRF/3q4zdK+8AFVJk10i/McCl+25GqhmAhLh3TTB1X5R6PVvEbfT7v0bgP tBSn4YQK0rdxcMssaAy8q6oGGrQxkzeIFZc/RUdcoMgsn1tDpLcEcVopzHrZOghEvn16 xcazEoSY2TuQqgJ2szOYWWJZGdiBnET5MJEILFWNAY9hT6tnI7ESmSHuT/qIIHED+igC j3AleklnQSNX0t7F04dHsYbTz9aPHKHGEjlrFwjmWlwqaSZ+M19DQoCaEubwFN3A+erG +Om/DwZZWFqa8YJavtkN/8E6Y+SnGSHuhfcnTVXiNVqFWJ59IXGFRYSueC4h6HJvcdRU 18+g== X-Gm-Message-State: AOAM532Fe0adSwZ1UPApg0gXuuJiqjLB1JmfTOQINixBEFaDw7bVZtWw D9KCwdf7ucOcn+bjBzvMZII= X-Google-Smtp-Source: ABdhPJzudNR6VzVn46ftmM/IMMdNpZ79rD4rj8q6PMRLHjPkHaRRaZzxDCakkjNGeujEfpWCNjzaQg== X-Received: by 2002:a1c:de46:: with SMTP id v67mr12480072wmg.146.1591956572339; Fri, 12 Jun 2020 03:09:32 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-226.amazon.com. [54.240.197.226]) by smtp.gmail.com with ESMTPSA id o10sm9317514wrq.40.2020.06.12.03.09.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 03:09:31 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200610114004.30023-1-andrew.cooper3@citrix.com> <010401d6408a$2c57bba0$850732e0$@xen.org> <765b4fed-60d3-9c4a-d6b7-bcd9893c525b@citrix.com> In-Reply-To: <765b4fed-60d3-9c4a-d6b7-bcd9893c525b@citrix.com> Subject: RE: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() Date: Fri, 12 Jun 2020 11:09:30 +0100 Message-ID: <000101d640a1$90d46800$b27d3800$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJVAhO9pRR+GTACAAMIE1rLmlKQ5AG8VqlrAqKoKA6ntEbMEA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Juergen Gross' , 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 12 June 2020 10:54 > To: paul@xen.org; 'Xen-devel' > Cc: 'Ian Jackson' ; 'Wei Liu' ; 'Juergen Gross' > Subject: Re: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() > > On 12/06/2020 08:22, Paul Durrant wrote: > >> -----Original Message----- > >> From: Andrew Cooper > >> Sent: 10 June 2020 12:40 > >> To: Xen-devel > >> Cc: Andrew Cooper ; Ian Jackson ; Wei Liu > >> ; Juergen Gross ; Paul Durrant > >> Subject: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() > >> > >> c/s 6902cb00e03 "tools/libxendevicemodel: extract functions and add a compat > >> layer" introduced calls to both xencall_open() and osdep_xendevicemodel_open() > >> but failed to fix up the error path. > >> > >> c/s f68c7c618a3 "libs/devicemodel: free xencall handle in error path in > >> _open()" fixed up the xencall_open() aspect of the error path (missing the > >> osdep_xendevicemodel_open() aspect), but positioned the xencall_close() > >> incorrectly, creating the same pattern proved to be problematic by c/s > >> 30a72f02870 "tools: fix error path of xenhypfs_open()". > >> > >> Reposition xtl_logger_destroy(), and introduce the missing > >> osdep_xendevicemodel_close(). > >> > >> Fixes: 6902cb00e03 ("tools/libxendevicemodel: extract functions and add a compat layer") > >> Fixes: f68c7c618a3 ("libs/devicemodel: free xencall handle in error path in _open()") > >> Backport: 4.9+ > >> Signed-off-by: Andrew Cooper > >> --- > >> CC: Ian Jackson > >> CC: Wei Liu > >> CC: Juergen Gross > >> CC: Paul Durrant > >> > >> RFC - this is still broken. > >> > > I'm slightly confused. Do you want this in 4.14 in this form or are you expecting to update it? > > In this form, it is an improvement over before. > > There is still the crash described below which needs some form of > figuring out and fixing. > Ok, in which case consider it... Release-acked-by: Paul Durrant > ~Andrew > > > > > Paul > > > >> Failure to create the logger will still hit the NULL deference, in all of the > >> stable libs, not just devicemodel. > >> > >> Also, unless I'd triple checked the history, I was about to reintroduce the > >> deadlock from c/s 9976f3874d4, because it totally counterintuitive wrong to > >> expect setup and teardown in opposite orders. > >> --- > >> tools/libs/devicemodel/core.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c > >> index db501d9e80..4d4063956d 100644 > >> --- a/tools/libs/devicemodel/core.c > >> +++ b/tools/libs/devicemodel/core.c > >> @@ -67,9 +67,10 @@ xendevicemodel_handle *xendevicemodel_open(xentoollog_logger *logger, > >> return dmod; > >> > >> err: > >> - xtl_logger_destroy(dmod->logger_tofree); > >> + osdep_xendevicemodel_close(dmod); > >> xentoolcore__deregister_active_handle(&dmod->tc_ah); > >> xencall_close(dmod->xcall); > >> + xtl_logger_destroy(dmod->logger_tofree); > >> free(dmod); > >> return NULL; > >> } > >> -- > >> 2.11.0 > > From xen-devel-bounces@lists.xenproject.org Fri Jun 12 10:10:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 10:10:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjgdz-00010D-NO; Fri, 12 Jun 2020 10:10:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjgdy-000104-OV for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 10:10:38 +0000 X-Inumbo-ID: f664d1b4-ac94-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f664d1b4-ac94-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 10:10:38 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id r9so7578482wmh.2 for ; Fri, 12 Jun 2020 03:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=t3lcbxAFLUSZI9BwS8SsjPDTYt7d8BC6LqD5PrNEVso=; b=rHYFFfX59ZTaT3UEnFV8TzuaU6du9pRXlvRvHJ0VYHZ93T+6RH1PF3izA7/Kx+iQL9 X0Se9dDRa5qC1UKObsXKRg+0l0tSST0wjd3KbZ0OjuBva3mHPD95RRNE+3jYwpudfAdB jBfxfT3fc2vt3T7ZalwGEz5b0rmB57zLYP+FLoS35rWMRY3imrHBzYEktzv+wJIAi+r1 Acn1E1oryRvdNalEw0fitfUiOZLvHj8xeKvM9SInbtXaK19eici2Nr72cmfmKeCC4kVo /ms9TEOVsRrvhd2WEgkY329O6Cfcop/gTB4w499t1/MFN/7AsyRWAMwpBea2Y96/bqMZ 0v8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=t3lcbxAFLUSZI9BwS8SsjPDTYt7d8BC6LqD5PrNEVso=; b=K6S13t0hoFRD1SSg9Krc52biA95dbAYGQt2Am4LN8c68sRhaTbqRE0I8a5Yo9BRA9e c0ztV0iXdHOnwOpSG2JlkncFUuXitP0pO32Sf67hKmeaLtVlnEs3Y14jTW0YWxo06jf6 MDgYce58xDsn5I4DGhHV3d9vkvxnp68X24g5JeSD5oa5yKT+y1jznbtBP9L14rW8Onv4 vsfObJZfRTdml9k8d31/ApO6yM8wRIK+09akZsgbpJEbHzlVG1XlkEunvKfD5jQg3Pkc 6QqZBGR1SP3ANkC6D83oNzH769v/UAppasT8kM+06TIwT9qbM00maZVBmxr8i0KqL5NE KNjw== X-Gm-Message-State: AOAM5328rDMZqk+lplxtHJxXYUBHe1FHLoS7dqOEd+BexGqfhEHo1YPZ aFfDT25XYJKv/e8QrSyL9Ig= X-Google-Smtp-Source: ABdhPJxZ3WuvGOa1DT4kCElPLbF+A+CUaIqC8Nj/2wvnDcFwiPKHqqNwmTcOT/5RYJvg9Xf4OVE+Ig== X-Received: by 2002:a1c:66d5:: with SMTP id a204mr12358608wmc.134.1591956637415; Fri, 12 Jun 2020 03:10:37 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id j4sm8975895wma.7.2020.06.12.03.10.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 03:10:36 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Bertrand Marquis'" References: <5cf46b52-6a57-3e11-67a0-28f841865c1e@citrix.com> <7DA75B75-725F-40CC-9DDE-5727452309A0@arm.com> In-Reply-To: Subject: RE: [PATCH] x86/boot: use BASEDIR for include path Date: Fri, 12 Jun 2020 11:10:35 +0100 Message-ID: <000201d640a1$b7a2cb20$26e86160$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGjyn0thtHg83Swx4SMZrQD/sC/UQMS4ommAZ2dNBwCLHawgKkCxolQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'xen-devel' , 'nd' , 'Wei Liu' , 'Jan Beulich' , =?UTF-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 11 June 2020 18:28 > To: Bertrand Marquis > Cc: xen-devel ; nd ; Jan = Beulich ; Wei > Liu ; Roger Pau Monn=C3=A9 ; Paul = Durrant > Subject: Re: [PATCH] x86/boot: use BASEDIR for include path >=20 > On 11/06/2020 17:50, Bertrand Marquis wrote: > > Hi Andrew, > > > >> On 11 Jun 2020, at 17:24, Andrew Cooper = wrote: > >> > >> On 11/06/2020 12:54, Bertrand Marquis wrote: > >>> Use $(BASEDIR)/include instead of $(XEN_ROOT)/xen/include for the > >>> include path to be coherent with the rest of the Makefiles. > >>> > >>> Signed-off-by: Bertrand Marquis > >> Does something subtle break before this change? > > Without changing anything no. > > But if xen sub-directory is renamed yes. > > > > As there is no easy way to build xen hypervisor out of tree (I might = be wrong here !) I found a > solution using cp -rs from xen subdir in a xen-build1 xen-build2 etc = this way I can check build for > x86 and arm without cleaning. > > > > Without the patch, the sources are actually compiles with an include = path containing xen/../xen as a > result of using XEN_ROOT which does not allow to rename xen = subdirectory. > > As it was the only place in which XEN_ROOT was used for include = paths, this is normalising the > paths. >=20 > Ok. Acked-by: Andrew Cooper >=20 > CC Paul for 4.14. Release-acked-by: Paul Durrant >=20 > ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 12 10:54:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 10:54:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhJn-0004Kr-6V; Fri, 12 Jun 2020 10:53:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhJm-0004Km-3E for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 10:53:50 +0000 X-Inumbo-ID: fef32cbc-ac9a-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fef32cbc-ac9a-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 10:53:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=KGjSSLk5xxy0yFM4r8xdlW1IaCb/+o4gHuOlupnMnu0=; b=PDrIdHz/Xxw3aWki97B82HtAcb uHhBnuJe3O+auAoaNj2ZhYKwurCbTLZESH1de4MAAsVHz8ql2FhxQCOpgnHaBhIMk12M0Ez10zWsa R3yGMZYlBHovqk9qYczmFqaksiLeq4pZlnX3COK386wFEGjvEI7Vjv/psvR8vl8KW5z4=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhJg-0007M2-MJ; Fri, 12 Jun 2020 10:53:44 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjhJg-0000E8-9s; Fri, 12 Jun 2020 10:53:44 +0000 Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall To: Bertrand Marquis , xen-devel@lists.xenproject.org References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> From: Julien Grall Message-ID: <974bf796-d410-9dd7-9e60-873987cd8434@xen.org> Date: Fri, 12 Jun 2020 11:53:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , nd@arm.com, Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Bertrand, On 11/06/2020 12:58, Bertrand Marquis wrote: > At the moment on Arm, a Linux guest running with KTPI enabled will > cause the following error when a context switch happens in user mode: > (XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xffffff837ebe0cd0 I think you want to add a bit more context explaining the reason on the failure. I.e. this is because the virtual address used by the runstate is only accessible when running in kernel space. > > This patch is modifying the register runstate area handling on arm to > convert the guest address during the hypercall. During runtime context > switches the area is mapped to update the guest runstate copy. > The patch is also removing the initial copy which was done during the > hypercall handling as this is done on the current core when the context > is restore to go back to guest execution on arm. This is explaining what the commit does but not why we want to translate the virtual address at hypercall time. More importantly, this doesn't explain the restrictions added on the hypercall and why they are fine. Note that they also should be documented in the public header. > > As a consequence if the register runstate hypercall is called on one > vcpu for an other vcpu, the area will not be updated until the vcpu > will be executed (on arm only). The code below suggests the hypercall will just fail if you call it from a different vCPU. Is that correct? > > On x86, the behaviour is not modified, the address conversion is done > during the context switch and the area is updated fully during the > hypercall. > inline functions in headers could not be used as the architecture > domain.h is included before the global domain.h making it impossible > to use the struct vcpu inside the architecture header. > This should not have any performance impact as the hypercall is only > called once per vcpu usually. > > Signed-off-by: Bertrand Marquis > --- > xen/arch/arm/domain.c | 109 +++++++++++++++++++++++++++++------ > xen/arch/x86/domain.c | 30 +++++++++- > xen/arch/x86/x86_64/domain.c | 4 +- > xen/common/domain.c | 19 ++---- > xen/include/asm-arm/domain.h | 8 +++ > xen/include/asm-x86/domain.h | 16 +++++ > xen/include/xen/domain.h | 4 ++ > xen/include/xen/sched.h | 16 +---- > 8 files changed, 153 insertions(+), 53 deletions(-) > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 31169326b2..739059234f 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -275,36 +276,104 @@ static void ctxt_switch_to(struct vcpu *n) > virt_timer_restore(n); > } > > -/* Update per-VCPU guest runstate shared memory area (if registered). */ > -static void update_runstate_area(struct vcpu *v) > +void arch_cleanup_runstate_guest(struct vcpu *v) I would prefer if this is name arch_vcpu_cleanup_runstate() as this is per-vCPU and not per-domain information. > { > - void __user *guest_handle = NULL; > - struct vcpu_runstate_info runstate; > + spin_lock(&v->arch.runstate_guest.lock); > > - if ( guest_handle_is_null(runstate_guest(v)) ) > - return; > + /* cleanup previous page if any */ > + if ( v->arch.runstate_guest.page ) > + { > + put_page_and_type(v->arch.runstate_guest.page); get_page_from_gva() is only grabbing a reference on the page. So you want to use put_page() here. Note that we don't have type reference on Arm, so it equivalent to put_page(). But this wouldn't be technically correct :). > + v->arch.runstate_guest.page = NULL; > + v->arch.runstate_guest.offset = 0; > + } > > - memcpy(&runstate, &v->runstate, sizeof(runstate)); > + spin_unlock(&v->arch.runstate_guest.lock); > +} > > - if ( VM_ASSIST(v->domain, runstate_update_flag) ) > +int arch_setup_runstate_guest(struct vcpu *v, > + struct vcpu_register_runstate_memory_area area) The indentation looks off here. Also, same remark for the naming. > +{ > + struct page_info *page; > + unsigned offset; > + > + spin_lock(&v->arch.runstate_guest.lock); > + > + /* cleanup previous page if any */ > + if ( v->arch.runstate_guest.page ) > { > - guest_handle = &v->runstate_guest.p->state_entry_time + 1; > - guest_handle--; > - runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > - __raw_copy_to_guest(guest_handle, > - (void *)(&runstate.state_entry_time + 1) - 1, 1); > - smp_wmb(); > + put_page_and_type(v->arch.runstate_guest.page); Same remark here. Although I would prefer if we try to have a common helper to cleaning up the runstate. Maybe cleanup_runstate_vcpu_locked()? > + v->arch.runstate_guest.page = NULL; > + v->arch.runstate_guest.offset = 0; > + } > + > + offset = ((vaddr_t)area.addr.v) & ~PAGE_MASK; > + if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) > + { > + spin_unlock(&v->arch.runstate_guest.lock); > + gprintk(XENLOG_DEBUG, "Runstate is crossing pages\n"); > + return -EINVAL; > + } > + > + /* provided address must be aligned to a 64bit */ > + if ( offset % alignof(struct vcpu_runstate_info) ) > + { > + spin_unlock(&v->arch.runstate_guest.lock); > + gprintk(XENLOG_DEBUG, "Runstate pointer is not aligned\n"); > + return -EINVAL; > + } > + > + page = get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); In the current implementation, 0 was used to unregister the runstate area. I think we want to keep that feature and not throw an error. > + if ( !page ) > + { > + spin_unlock(&v->arch.runstate_guest.lock); > + gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); > + return -EINVAL; > } > > - __copy_to_guest(runstate_guest(v), &runstate, 1); > + v->arch.runstate_guest.page = page; > + v->arch.runstate_guest.offset = offset; > + In the current implementation, the runstate area was update with the latest information during the hypercall. This doesn't seem to happen anymore. Is there any specific reason? > + spin_unlock(&v->arch.runstate_guest.lock); > + > + return 0; > +} > + > + > +/* Update per-VCPU guest runstate shared memory area (if registered). */ > +static void update_runstate_area(struct vcpu *v) > +{ > + struct vcpu_runstate_info *guest_runstate; > + void *p; > + > + spin_lock(&v->arch.runstate_guest.lock); > > - if ( guest_handle ) > + if ( v->arch.runstate_guest.page ) > { > - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > + p = __map_domain_page(v->arch.runstate_guest.page); > + guest_runstate = p + v->arch.runstate_guest.offset; > + > + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > + { > + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; > + smp_wmb(); > + } > + > + memcpy(guest_runstate, &v->runstate, sizeof(v->runstate)); > smp_wmb(); > - __raw_copy_to_guest(guest_handle, > - (void *)(&runstate.state_entry_time + 1) - 1, 1); > + > + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > + { > + v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > + guest_runstate->state_entry_time &= ~XEN_RUNSTATE_UPDATE; > + smp_wmb(); Why do you need this barrier? [...] > diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h > index 4e2f582006..3a7f53e13d 100644 > --- a/xen/include/asm-arm/domain.h > +++ b/xen/include/asm-arm/domain.h > @@ -11,6 +11,7 @@ > #include > #include > #include > +#include Why do you need to add this new include? > #include > #include > > @@ -206,6 +207,13 @@ struct arch_vcpu > */ > bool need_flush_to_ram; > > + /* runstate guest info */ > + struct { > + struct page_info *page; /* guest page */ > + unsigned offset; /* offset in page */ Please use unsigned int. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 10:55:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 10:55:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhLh-0004RF-Ms; Fri, 12 Jun 2020 10:55:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhLg-0004R8-Tc for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 10:55:48 +0000 X-Inumbo-ID: 44e14b14-ac9b-11ea-8496-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 44e14b14-ac9b-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 10:55:46 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: oyqfG7pWJjfrdc3HHfqcE7uu2ZRzS4OEvBC5OiKvK+DKMxFY8l9GwV3BnR4jtkWkwQAbnGKrdD Vxz+ZLh1eiMCaFV/6m/DjR2MCX9s7aVEVHPOCz9BQOP2+uzO5t161H2eSoUZ7JrDzbSQHWoVH8 FQ/Re/9wsbw40qWLCKITEw0sGC4TSD0ZqfDon0NBS5gA0P9UzRK/mWc10ZhIrMlnK8V2MLHiUU z140UHgUbTAAZOoG7lkI74MLsn755D14X/leGplUymLH9IEhHE5qsi7QyXi88mhCBv+6wWzu7/ aN8= X-SBRS: 2.7 X-MesageID: 20186911 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20186911" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14] tools/libxc: Drop config_transformed parameter from xc_cpuid_set() Date: Fri, 12 Jun 2020 11:55:19 +0100 Message-ID: <20200612105519.18728-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Paul Durrant , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" libxl is now the sole caller of xc_cpuid_set(). The config_transformed output is ignored, and this patch trivially highlights the resulting memory leak. "transformed" config is now properly forwarded on migrate as part of the general VM state, so delete the transformation logic completely, rather than trying to adjust just libxl to avoid leaking memory. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Paul Durrant For 4.14 for hopefully obvious reasons. Ian: for backport to 4.13 and earlier, there are a number of options. The reasoning we used to delete the other callers of xc_cpuid_set() is still valid, but probably not backport material. OTOH, moding libxl_cpuid_set() (as it was back then) to loop over cpuid_res[] and free them all should work. --- tools/libxc/include/xenctrl.h | 3 +-- tools/libxc/xc_cpuid_x86.c | 25 +------------------------ tools/libxl/libxl_cpuid.c | 3 +-- 3 files changed, 3 insertions(+), 28 deletions(-) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index f9e17ae424..113ddd935d 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -1795,8 +1795,7 @@ int xc_domain_debug_control(xc_interface *xch, int xc_cpuid_set(xc_interface *xch, uint32_t domid, const unsigned int *input, - const char **config, - char **config_transformed); + const char **config); /* * Make adjustments to the CPUID settings for a domain. diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index 89d2ecdad2..b42edd6457 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -279,7 +279,7 @@ int xc_set_domain_cpu_policy(xc_interface *xch, uint32_t domid, */ int xc_cpuid_set( xc_interface *xch, uint32_t domid, const unsigned int *input, - const char **config, char **config_transformed) + const char **config) { int rc; unsigned int i, j, regs[4] = {}, polregs[4] = {}; @@ -288,9 +288,6 @@ int xc_cpuid_set( unsigned int nr_leaves, policy_leaves, nr_msrs; uint32_t err_leaf = -1, err_subleaf = -1, err_msr = -1; - for ( i = 0; i < 4; ++i ) - config_transformed[i] = NULL; - if ( xc_domain_getinfo(xch, domid, 1, &di) != 1 || di.domid != domid ) { @@ -365,13 +362,6 @@ int xc_cpuid_set( continue; } - config_transformed[i] = calloc(33, 1); /* 32 bits, NUL terminator. */ - if ( config_transformed[i] == NULL ) - { - rc = -ENOMEM; - goto fail; - } - /* * Notes for following this algorithm: * @@ -399,11 +389,6 @@ int xc_cpuid_set( set_feature(31 - j, regs[i]); else clear_feature(31 - j, regs[i]); - - config_transformed[i][j] = config[i][j]; - /* All non 0/1 values get overwritten. */ - if ( (config[i][j] & ~1) != '0' ) - config_transformed[i][j] = '0' + val; } } @@ -421,16 +406,8 @@ int xc_cpuid_set( } /* Success! */ - goto out; fail: - for ( i = 0; i < 4; i++ ) - { - free(config_transformed[i]); - config_transformed[i] = NULL; - } - - out: free(leaves); return rc; diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c index 4e4852ddeb..796ec4f2d9 100644 --- a/tools/libxl/libxl_cpuid.c +++ b/tools/libxl/libxl_cpuid.c @@ -421,7 +421,6 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, { libxl_cpuid_policy_list cpuid = info->cpuid; int i; - char *cpuid_res[4]; bool pae = true; /* @@ -444,7 +443,7 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) xc_cpuid_set(ctx->xch, domid, cpuid[i].input, - (const char**)(cpuid[i].policy), cpuid_res); + (const char**)cpuid[i].policy); } static const char *input_names[2] = { "leaf", "subleaf" }; -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:00:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:00:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhQW-0005Jm-AW; Fri, 12 Jun 2020 11:00:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhQV-0005Jh-GL for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:00:47 +0000 X-Inumbo-ID: f778eae8-ac9b-11ea-b5ba-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f778eae8-ac9b-11ea-b5ba-12813bfff9fa; Fri, 12 Jun 2020 11:00:46 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: vR9NiALn/RFNcbxQ7REIJJ82GE238rLWs2R/k1YrGceQnb7KWLosRPitTpd+2lEC483fq04PAS XxXyX9838Be2vllZq9TLC+IGzULzUQRPBuI+7I8JP6J/qFnPVENSDO56HcU5FEXxhxvQZEVnUC znYRKR8U41k98YlKMfDaHW6QEXN8jWl3+wqZPXPEaj3MlUw3H7OBs2kyFRVs3+eUS69a3eSzsx opMJWlTRbuOrYJH17LI4ALGlOR9kRuVBGAjck7KwcZuS1MCn8CYvaAovQwMIFsTxETp/Ld5vpb c/s= X-SBRS: 2.7 X-MesageID: 20239235 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20239235" To: xen-devel , George Dunlap , From: Andrew Cooper Subject: golang bindings dirty in tree after libxl build Message-ID: Date: Fri, 12 Jun 2020 12:00:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, I've just done a libxl build and got things such as: --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -431,14 +431,14 @@ x.Evtch = int(xc.evtch)  x.Rref = int(xc.rref)  x.Connection = ChannelConnection(xc.connection)  switch x.Connection{ -case ChannelConnectionUnknown: -x.ConnectionUnion = nil  case ChannelConnectionPty:  var connectionPty ChannelinfoConnectionUnionPty  if err := connectionPty.fromC(xc);err != nil {   return fmt.Errorf("converting field connectionPty: %v", err)  }  x.ConnectionUnion = connectionPty +case ChannelConnectionUnknown: +x.ConnectionUnion = nil  case ChannelConnectionSocket:  x.ConnectionUnion = nil  default: dirty in tree.  They are all case labels, and only their order in the switch has changed. Does the current binding generation rely on the order of entries in a python dictionary by any chance? ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:05:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:05:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhVE-0005T3-TO; Fri, 12 Jun 2020 11:05:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhVD-0005Sy-Ta for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:05:39 +0000 X-Inumbo-ID: a5e57af6-ac9c-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a5e57af6-ac9c-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 11:05:39 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ciLDfLLVW4KC2YidnuKDXb5ozQH/geSuIQfi+ZmYjF7OmZ2dEr39mQFqLnzAJ4F+MLM2vORDuu p6c8I7Ud/8QIRQLED6ecRK/zhgrZ13bF2kPrY6MRmHkXatl4gthAulEQKX0dNp9vF/TrulqTsj SCNpK4zoFfUQU/pm1/ylwANu++dXgorHKGZ0V1svQDvwEUffpMO04A7TS8mVX/SUfTJYqiB4Il Yo+27VaXjgl4q53ykBoTm8Vyl3LyoI65fLmYaibDtK8YnWe7kfDsnuDijmxfomiHxcqbxLCREP NJw= X-SBRS: 2.7 X-MesageID: 20239744 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20239744" To: xen-devel , Ian Jackson , Wei Liu From: Andrew Cooper Subject: libxl dirty in tree after libxl build Message-ID: <439f3d92-2e18-1868-2b4b-2747973fbe3b@citrix.com> Date: Fri, 12 Jun 2020 12:05:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, A build of libxl has just dirtied the tree with: index 05f7ac74a0..94a4438666 100644 --- a/tools/libxl/libxlu_disk_l.c +++ b/tools/libxl/libxlu_disk_l.c @@ -10,221 +10,11 @@  #define FLEX_SCANNER  #define YY_FLEX_MAJOR_VERSION 2  #define YY_FLEX_MINOR_VERSION 6 -#define YY_FLEX_SUBMINOR_VERSION 4 +#define YY_FLEX_SUBMINOR_VERSION 1  #if YY_FLEX_SUBMINOR_VERSION > 0  #define FLEX_BETA  #endif and a whole slew of other changes in the generated code.  It looks like the version of Flex has just been updated in Jessie. Given the flex and bison are strictly required for the libxl build, why is this temporary file checked in? ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:06:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:06:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhVc-0005VP-5T; Fri, 12 Jun 2020 11:06:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhVa-0005VA-8E for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:06:02 +0000 X-Inumbo-ID: b32a9052-ac9c-11ea-8496-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b32a9052-ac9c-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 11:06:01 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id x1so9670451ejd.8 for ; Fri, 12 Jun 2020 04:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=snziYwGaN8wiceNBMz7wJmdc/YjHgkwqTeoUraCt86Y=; b=oerEcU3yIuYxIwD3mDvcsL+KzrT7sai0TC54j6IenSO7z24f/et2ajSqYMgRo8PNTh 3EwLPdQL3gVYxmGo8McAsdglsNBWOT9LPraPoxzmtBsi71GR3QWACry25rBQj9kC5Djr mFNf1ODpb+ktsTVVH0mt6RqT4gRnmeWvqQefi3el73nhsU5hR72SfWCRMx2+vGHb3w08 961JfOKYQE8HI3bOaP2m4y59zX1Bir69Cqb6rZwhUkUssiHzTGKx6cNNA513g6aEZKDB woaNRBv3tJ3gxqXBcjlLIjSdxkSO52iaQs/TVzoHp3R4o+8uN6f9TPKMEBGToxJRDzcG Zyjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=snziYwGaN8wiceNBMz7wJmdc/YjHgkwqTeoUraCt86Y=; b=axtW277DoWoNgJXZ3fmIQ5hGLmRb9y8Xtn2LZKe7U1q6sCKASs07y0Vn6wRM2vy54N EljfxQOmaDv4rsG9FzCCnMiidQP80ORqnWdm1VOI5RuUE4xF2vIhMh/NjWEkO8yiGtfh N/ncp+q7koeF6qVkjmskpdPyMTnvmQUdTe1V9KhZbsaFjMTb5mlfFg6BJsEYhwVYiapi o+UPxmWQ8iejsRL7gH3hT9DbRmhlVCXWBGQ6uQqJjOWhI0xFdgI9a7Ah68SlpRZHFYr4 0Jd2ij65AGNr10Wm9bLLpDzvyjrx0GbBVWapQZ9+UY1c+oIMA6CUv+KaqfQKMAwQQCG7 mzuQ== X-Gm-Message-State: AOAM5333C3gejb7F4dPRday6gnlRtH7mgZpXe4vAVR5qHo4Qi+Fv5TKb WJauzhdgLuObqu88DZ9ABNM= X-Google-Smtp-Source: ABdhPJybbeO4l3wHoQuTbi/8+MIE0sXGFTBJDCFA3Ubvml6WIbpH4sbPOJVTjtgCjnNaiMbzbEVw3w== X-Received: by 2002:a17:906:470a:: with SMTP id y10mr13267678ejq.535.1591959960552; Fri, 12 Jun 2020 04:06:00 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-226.amazon.com. [54.240.197.226]) by smtp.gmail.com with ESMTPSA id u13sm3416468ejf.60.2020.06.12.04.05.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 04:05:59 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200612105519.18728-1-andrew.cooper3@citrix.com> In-Reply-To: <20200612105519.18728-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH for-4.14] tools/libxc: Drop config_transformed parameter from xc_cpuid_set() Date: Fri, 12 Jun 2020 12:05:58 +0100 Message-ID: <000301d640a9$743c5510$5cb4ff30$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJxpHaew1P/sNsDF5l3fu7RdB3IxKeeCdQQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 12 June 2020 11:55 > To: Xen-devel > Cc: Andrew Cooper ; Ian Jackson ; Wei Liu > ; Paul Durrant > Subject: [PATCH for-4.14] tools/libxc: Drop config_transformed parameter from xc_cpuid_set() > > libxl is now the sole caller of xc_cpuid_set(). The config_transformed output > is ignored, and this patch trivially highlights the resulting memory leak. > > "transformed" config is now properly forwarded on migrate as part of the > general VM state, so delete the transformation logic completely, rather than > trying to adjust just libxl to avoid leaking memory. > > Signed-off-by: Andrew Cooper Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant > --- > CC: Ian Jackson > CC: Wei Liu > CC: Paul Durrant > > For 4.14 for hopefully obvious reasons. > > Ian: for backport to 4.13 and earlier, there are a number of options. The > reasoning we used to delete the other callers of xc_cpuid_set() is still > valid, but probably not backport material. > > OTOH, moding libxl_cpuid_set() (as it was back then) to loop over cpuid_res[] > and free them all should work. > --- > tools/libxc/include/xenctrl.h | 3 +-- > tools/libxc/xc_cpuid_x86.c | 25 +------------------------ > tools/libxl/libxl_cpuid.c | 3 +-- > 3 files changed, 3 insertions(+), 28 deletions(-) > > diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h > index f9e17ae424..113ddd935d 100644 > --- a/tools/libxc/include/xenctrl.h > +++ b/tools/libxc/include/xenctrl.h > @@ -1795,8 +1795,7 @@ int xc_domain_debug_control(xc_interface *xch, > int xc_cpuid_set(xc_interface *xch, > uint32_t domid, > const unsigned int *input, > - const char **config, > - char **config_transformed); > + const char **config); > > /* > * Make adjustments to the CPUID settings for a domain. > diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c > index 89d2ecdad2..b42edd6457 100644 > --- a/tools/libxc/xc_cpuid_x86.c > +++ b/tools/libxc/xc_cpuid_x86.c > @@ -279,7 +279,7 @@ int xc_set_domain_cpu_policy(xc_interface *xch, uint32_t domid, > */ > int xc_cpuid_set( > xc_interface *xch, uint32_t domid, const unsigned int *input, > - const char **config, char **config_transformed) > + const char **config) > { > int rc; > unsigned int i, j, regs[4] = {}, polregs[4] = {}; > @@ -288,9 +288,6 @@ int xc_cpuid_set( > unsigned int nr_leaves, policy_leaves, nr_msrs; > uint32_t err_leaf = -1, err_subleaf = -1, err_msr = -1; > > - for ( i = 0; i < 4; ++i ) > - config_transformed[i] = NULL; > - > if ( xc_domain_getinfo(xch, domid, 1, &di) != 1 || > di.domid != domid ) > { > @@ -365,13 +362,6 @@ int xc_cpuid_set( > continue; > } > > - config_transformed[i] = calloc(33, 1); /* 32 bits, NUL terminator. */ > - if ( config_transformed[i] == NULL ) > - { > - rc = -ENOMEM; > - goto fail; > - } > - > /* > * Notes for following this algorithm: > * > @@ -399,11 +389,6 @@ int xc_cpuid_set( > set_feature(31 - j, regs[i]); > else > clear_feature(31 - j, regs[i]); > - > - config_transformed[i][j] = config[i][j]; > - /* All non 0/1 values get overwritten. */ > - if ( (config[i][j] & ~1) != '0' ) > - config_transformed[i][j] = '0' + val; > } > } > > @@ -421,16 +406,8 @@ int xc_cpuid_set( > } > > /* Success! */ > - goto out; > > fail: > - for ( i = 0; i < 4; i++ ) > - { > - free(config_transformed[i]); > - config_transformed[i] = NULL; > - } > - > - out: > free(leaves); > > return rc; > diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c > index 4e4852ddeb..796ec4f2d9 100644 > --- a/tools/libxl/libxl_cpuid.c > +++ b/tools/libxl/libxl_cpuid.c > @@ -421,7 +421,6 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, > { > libxl_cpuid_policy_list cpuid = info->cpuid; > int i; > - char *cpuid_res[4]; > bool pae = true; > > /* > @@ -444,7 +443,7 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, > > for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) > xc_cpuid_set(ctx->xch, domid, cpuid[i].input, > - (const char**)(cpuid[i].policy), cpuid_res); > + (const char**)cpuid[i].policy); > } > > static const char *input_names[2] = { "leaf", "subleaf" }; > -- > 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:27:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:27:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhpt-0007Fg-Si; Fri, 12 Jun 2020 11:27:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhpr-0007Fb-SH for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:27:00 +0000 X-Inumbo-ID: a0898c98-ac9f-11ea-b5bd-12813bfff9fa Received: from EUR01-VE1-obe.outbound.protection.outlook.com (unknown [40.107.14.45]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a0898c98-ac9f-11ea-b5bd-12813bfff9fa; Fri, 12 Jun 2020 11:26:59 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fAHOoK/6mc6X5BxqU38WwPZ3QlHgLsgvEQ4mRh5C5KJlYXXOMiY8J8ukUfioHrUb3EcJM5L2/WmppyXJhSnZXJdyDE/Oon68Epgkz4r4oYVEYokzKSlJ+zn5J9xo8Wk0kB5EHUyN/l7sAmSFd9W1bzPerNUy6DqFGk28pRusoLgp9Ow8ki7fX+GatVZy7QbL5O1MFY4n//uf4IuHN0lPImBfsbOj2s0SmbHhhBiDDu/qTb1TpbZJdai6yk7JWDxWEj3+ZxY/8pp9mWP2+Z8zw7S2M4dFrn9h0YI5qzc3rWeGG8HgqIdLzCUOaWy6ZLn1NgPTnT56vaL2uMAihvSmvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cFfnlUpI8o5/vSbuI2ryo6sev5aXsq0V8sy+/YxNbao=; b=OECxCewL1DKGuf1++LFcaV8RoqmRWahaMgcFxHk81U38cUK3lrS+ZEXlOVjp1/cCigvy5Gb65ja6BdUwL/kDDuQ/hTb07d7f4gRRII1JbK7WU1K6ZOnGQFcH4zsXDFedjuXBWjeiObjSQG+4HZYfyKwcgrl8PZUOI+nf2AXophSdJykszVNUkRbZlVTGA6PT1nS8HaRtr/iNCmHNrpbDJ8vbit/NmWrepPfT1lGKU8f5w1CqJmFs0bvQ5ZkOAJvzRPjT0ome67g+V1Eo0KJ6rD07cfFQ+v0uh706gYJN2U60g4cmgs21g7AGzyihkGPR03Wy9KtUKdu+C9mB1u84/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cFfnlUpI8o5/vSbuI2ryo6sev5aXsq0V8sy+/YxNbao=; b=alTkLReREzBKw+qBOcEXHX8Sff+GnXrDUwpyqckqeL8vDqZ4OhJErtYTT5gE41wcx1qLYtqvb4qikCqe88edrEq7whVGx8ME4wlLK/6hU2anoR87KbwRy/kvuXKCgrkPW3M9+udVTU0bJ5HyAnrD0EnC9ACp/3bnhQpOqcBpebCYh9fu3WEatHiUoflju4UIgQvbsOMYs4B+7y/U039kbM1xMPwwHe80Gz9d5ga7sEITR9GW5982R3DMphEBbFAAOd/AWRzmgwLUp4DtjiPSVablTjbpcAKds+l68jQIsYxXrtQ2jHt/YrQg/brK5LVL6dgKJyOQawJSZbgPU3UvDA== Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com (2603:10a6:8:c::18) by DB3PR0302MB3323.eurprd03.prod.outlook.com (2603:10a6:8:a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.23; Fri, 12 Jun 2020 11:26:57 +0000 Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290]) by DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290%2]) with mapi id 15.20.3088.023; Fri, 12 Jun 2020 11:26:57 +0000 From: Volodymyr Babchuk To: "jgross@suse.com" , "xen-devel@lists.xenproject.org" Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler Thread-Topic: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler Thread-Index: AQHWQE+STyWApsQdk0CG54zgwiPygKjUZV2AgAByxQA= Date: Fri, 12 Jun 2020 11:26:56 +0000 Message-ID: <7ec7b6568afb3df41f8407015c198b1ccb341c5b.camel@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> In-Reply-To: <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9727df84-5de2-4af7-9ced-08d80ec38413 x-ms-traffictypediagnostic: DB3PR0302MB3323: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 565+wiXbg7AU50in0QQhTbioD0j6G312moWlbHUfp92RFK1D712fZuixZdz3Y2VA64F9v8aH2iy215s/bcGViDm2YSSphq3e3v2kiezVgdTh6GgIF5p5LjcpqFe+WsRKa3qILuCzH2BrAXR33S78jLP1amw+JXVgq0Vc4XJjsRn/m64OGJx7xTMH95er5sXZsh/n8qumvKLDWrda/rG8DkVRi2jieiAWzJNHFVTkZdkY1gCvIrgf3+LcMWaxD28P0rIPRxWZb3/dNSLWXmnrjatPaQfMD9zozfRj6K123MJ5Y0oFv+fzmi8J89iBU7ftss9QGjviVsRdavbehp4XRQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB3PR0302MB3401.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(366004)(346002)(136003)(396003)(8936002)(76116006)(186003)(83380400001)(36756003)(66446008)(86362001)(2906002)(66946007)(64756008)(26005)(66476007)(5660300002)(66556008)(4744005)(91956017)(53546011)(2616005)(4326008)(316002)(54906003)(7416002)(6512007)(55236004)(71200400001)(6506007)(8676002)(6486002)(478600001)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: NR0Nda5tT98d7tqfnGjtUtR9Zq1NzQLG2uW/6dJtKMOvJO5FqHNaBXPM+PUiJDKOIGMtT3uCA5p032e1JtUlSFlo+0K8Rj/Ql5wbDO0z/O9dDvWVEB7hd6rGFnCU0+xzNPldf3bvMeApTpv+L9oytptY4zENaXzFgZiFIHmPbnKsj/NsJApzJqurv34RCDVCHg+332MyiY84GMxIjJB9PgWazSEBTNejdADput/efxPUJ2p5UpC0Kpim0b/Ls3SMpvDcLFxDXbMeGsR7vntVZ63ZNhVTQQGhpjvMiyyuuoI/GCpDExPlkrsRcmvlmJgsbCgZ1jbysdR08mvDcvvuLHby7vHoS/bykc8eZxAKvROu55tx9hK6NFhDaWiwGAv6qMJZdmwrQLHaTtSdYz3j9WLGs9vJ3SRHFGUaMxDgeoaHZwplbuAQfbnhmBqvQ10fkegVqWciSkTrd/Rq+pKdDL9f88XyFhG1Y5DKB3ThwK8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9727df84-5de2-4af7-9ced-08d80ec38413 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 11:26:56.9055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4uXbUY1uE34enZN8SzsRiVsVmjq1Rf7xVlXrMFg0oxGS6kgl7LVbeuuQXoQGKPuwGbGsDnL5p3eAD6oyNJv4zgcN21gyrymc6ch25UJ/eBA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0302MB3323 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "julien@xen.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGkgSnVyZ2VuLA0KDQp0aGFua3MgZm9yIHRoZSByZXZpZXcNCg0KT24gRnJpLCAyMDIwLTA2LTEy IGF0IDA2OjM2ICswMjAwLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KDQo+IE9uIDEyLjA2LjIwIDAy OjIyLCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCg0KWy4uLl0NCg0KPiA+ICt2b2lkIHZjcHVf ZW5kX2lycV9oYW5kbGVyKHZvaWQpDQo+ID4gK3sNCj4gPiArICAgIGludCBkZWx0YTsNCj4gPiAr DQo+ID4gKyAgICBpZiAoaXNfaWRsZV92Y3B1KGN1cnJlbnQpKQ0KPiA+ICsgICAgICAgIHJldHVy bjsNCj4gPiArDQo+ID4gKyAgICBBU1NFUlQoY3VycmVudC0+aXJxX25lc3RpbmcpOw0KPiA+ICsN Cj4gPiArICAgIGlmICggLS1jdXJyZW50LT5pcnFfbmVzdGluZyApDQo+ID4gKyAgICAgICAgcmV0 dXJuOw0KPiA+ICsNCj4gPiArICAgIC8qIFdlIGFzc3VtZSB0aGF0IGlycSBoYW5kbGluZyB0aW1l IHdpbGwgbm90IG92ZXJmbG93IGludCAqLw0KPiANCj4gVGhpcyBhc3N1bXB0aW9uIG1pZ2h0IG5v dCBob2xkIGZvciBsb25nIHJ1bm5pbmcgVk1zLg0KDQpCYXNpY2FsbHksIHRoaXMgdmFsdWUgaG9s ZHMgdGltZSBzcGFuIGJldHdlZW4gY2FsbHMgdG8gc2NoZWR1bGUoKS4gVGhpcw0KdmFyaWFibGUg Z2V0cyB6ZXJvZWQgb3V0IGV2ZXJ5IHRpbWUgc2NoZWR1bGVyIHJlcXVlc3RzIGZvciB0aW1lDQph ZGp1c3RtZW50IHZhbHVlLiBTbywgaXQgc2hvdWxkIG5vdCBkZXBlbmQgb24gdG90YWwgVk0gcnVu IHRpbWUuIA0KDQo= From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:30:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:30:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhso-0007WB-CW; Fri, 12 Jun 2020 11:30:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhsn-0007S1-Pr for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:30:01 +0000 X-Inumbo-ID: 0db0f338-aca0-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0db0f338-aca0-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 11:30:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9s6nLu83a31Mn24k92CziNOGaf3LXQklsTVVFdKHZDo=; b=lIJwbc2ijq/xHr8E33YHPL1nb2 LXUX22UJlWY1kqT4qp4Go3UzG+A+MLUZni8E5ciSjK0t+9D2AMlSSoBByTjrlPbPh0eSIA5OkjL9s vKmKznCRcy9bRHHEQcWGEVi7lfi7z9/HJzyS5TkxTq6Sb2gsVXqug8ATQ4yBvi0Pu+DQ=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhsk-00081m-Qf; Fri, 12 Jun 2020 11:29:58 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjhsk-0002Pl-Jf; Fri, 12 Jun 2020 11:29:58 +0000 Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler To: Volodymyr Babchuk , "jgross@suse.com" , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> <7ec7b6568afb3df41f8407015c198b1ccb341c5b.camel@epam.com> From: Julien Grall Message-ID: Date: Fri, 12 Jun 2020 12:29:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <7ec7b6568afb3df41f8407015c198b1ccb341c5b.camel@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 12:26, Volodymyr Babchuk wrote: > Hi Jurgen, > > thanks for the review > > On Fri, 2020-06-12 at 06:36 +0200, Jürgen Groß wrote: > >> On 12.06.20 02:22, Volodymyr Babchuk wrote: > > [...] > >>> +void vcpu_end_irq_handler(void) >>> +{ >>> + int delta; >>> + >>> + if (is_idle_vcpu(current)) >>> + return; >>> + >>> + ASSERT(current->irq_nesting); >>> + >>> + if ( --current->irq_nesting ) >>> + return; >>> + >>> + /* We assume that irq handling time will not overflow int */ >> >> This assumption might not hold for long running VMs. > > Basically, this value holds time span between calls to schedule(). This > variable gets zeroed out every time scheduler requests for time > adjustment value. So, it should not depend on total VM run time. This is assuming that the scheduler will be called. With the NULL scheduler in place, there is a fair chance this may never be called. So I think using a 64-bit value is likely safer. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:30:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:30:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhtZ-00086G-QN; Fri, 12 Jun 2020 11:30:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhtY-000857-Ik for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:30:48 +0000 X-Inumbo-ID: 279f0230-aca0-11ea-bb8b-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.49]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 279f0230-aca0-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 11:30:45 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gtMhAL8pw8bcVYheruZOFjZc9EAsG6mA48ETm+00qG75RO/G6PhaUjZav6nkdWIiYhy7UceWiRRvZ5FBgH3zzPFrq19sMbBdHqbD1giHgc4KVkdjDV5prXwPe/pdaaAkZBgYaHby7+E+bo3l2TdDoMbQAHpjnQJDaONs3oESDOR+u4hDCGB8GTJBw6zY2d/8EgAyCYe4hVTJLiJwIOIgryS5oQwpV7wgDx6fscxSJNDy+w4OGFLX0gkSQ6Y57yAQWIDT6Y+DLPGPu5/qqrhlJRzAm9QfLX+LHr1KeKswHYVN6uI7Uhb3UZS8imcKGVsLvbY0jX1fcvBQyQGENTe6Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1iB5UzSHH1KgP6PRHIhObGC20xwVLHX64wBQq/sIm64=; b=c9Q9l+4QvbkXsHC6wKl9pZsQAb34dBW4ZLwNcV1wGSep9UW4evcNRSJc697fi/AlygJuZf8gopvo9HTWlJ1FRIIjtjK+Nq1S8j96o4Rr70vE1ILBRuDsy35KJJV6+u0Q/r7sNGaXSKhSeKBjI8E7RxJKpqpDa5mWbyLi3GJAuRbDVleB0tC5k2+BhNJ82BiHts+ib8lZFB/BrHexIH7Q7CC+aQWQ7dpwvv2fvJ4QhIjb1IiVeecEcleggfKiFEAUhsGM1zvzGnR1FswtK1x7gtrgwhNSC/TaWKa8lcMqBX29o73reINKHlkYFRWWZ2K/Yv7hKNj8pVpGJ26BP3udqA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1iB5UzSHH1KgP6PRHIhObGC20xwVLHX64wBQq/sIm64=; b=eK6bGRnKpZ+AD6Q7uJekBASZttAMTUFdIGPULLkYrCXp6BCQH0jlatcj6GnQZKKPzTPG7eS1HVqB17CBaV2x9i8FbREr/pDHeP3xdJBaP3/AcBPlPCp/N3SqFS8zJ8j1rAarwDgBHcAve8w0zRBsBzofobNoKjoNHFpubcSQVktAxDt28oOWB4Iraa9W5uratleLOt62NJOy5ia4G3d/H5YlNfqJ3A39oEcfoeeUaJZkt6JC3j78Jq91aoDISl1nSwAYl0tSLVnFrgqOuVqdN4j/YFaEcug7vqJntSFAB4QuKgSufuRiyIZq3D2eMck+xSuurNPiEj4psZjTW8XcLg== Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com (2603:10a6:8:c::18) by DB3PR0302MB3340.eurprd03.prod.outlook.com (2603:10a6:8:a::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Fri, 12 Jun 2020 11:30:43 +0000 Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290]) by DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290%2]) with mapi id 15.20.3088.023; Fri, 12 Jun 2020 11:30:43 +0000 From: Volodymyr Babchuk To: "jgross@suse.com" , "xen-devel@lists.xenproject.org" Subject: Re: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks Thread-Topic: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks Thread-Index: AQHWQE+SUtF98x/3akmRxwBff1s+m6jUZ0iAgABx6YA= Date: Fri, 12 Jun 2020 11:30:43 +0000 Message-ID: References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-3-volodymyr_babchuk@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2339c945-0e71-4dd0-02a1-08d80ec40b39 x-ms-traffictypediagnostic: DB3PR0302MB3340: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oHULeZ5t4MkjP07ntMTMXjVsH7zKCzW1/DR+z3kWgONAPThf2VFEpSYRnA3G9WpFbySVXmYYWf/h50WLl5hJ/f6KBtTKfNRySZrI6GlZdXLQQAg/n3HB4PDuCWJQWMEiCyB/jiUSTLHmddVDbYkNp7CF2l94ns8VJN1mUJ1SMAK7ZYkgmhjC/DCuzkW/tjmMtd1Gd5CeBKATiQcgHSUgCYOk4s1/DiNdpkpOJQFGFS+2UnWIZp5h7ZhI9Y9JBXle6G8tIwhgbZ90AEnr/4gpG77NmoEhkmM+3Tnh56POxt2CEeLf3IAoBzv+/8+guEs3 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB3PR0302MB3401.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(346002)(396003)(376002)(7416002)(110136005)(86362001)(66574014)(8936002)(83380400001)(54906003)(4326008)(316002)(66556008)(91956017)(55236004)(66476007)(64756008)(6486002)(478600001)(186003)(76116006)(6512007)(26005)(6506007)(66446008)(53546011)(5660300002)(8676002)(2616005)(66946007)(36756003)(2906002)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HGnGGEZ+7w+QizcvsXFnMRFoisWKog8YUAPN0GxydwzoPiXtKffKcw2SyExz3Mg7esVYGUmJK6hR/Lkj5i2R3dNkWJS7/QzDbLJ2kcN7qtB2tUAaMpkmUEbTgVq5v5iI+DR71GS0IEuV4+MKWQVFqjIj0AG2ViApDJtgWD1lXG1rH1GZFO73FsW7MBi4o8OMG7WBaj9GfGYpxwZh85BT9zHxXUsEt+0ManxKvabt1EjV7PrjCND7RZIq7pA+q/fhpYgxv8M81Y/J8ZG+hXncHCooYLdCzXiXlwTNCwXnetagpC72NMnjFaj75QVXWUAABf6V1kADjgwVYa4SnxHe+VCy41ql2BMorjy/uDk9kHswlT9FO0SAWPE8kTqEsnYnsSlxmrkYbnYhnyO1zmgdQJpPxDmO0u9LOnQU0yqCoTR0WUIgDpBYzqRPkmCpIV7Pm72oqA+n5IJuq/W8+F2VNNyjYx4zse41AyajJvPt+OQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6C61D6B8CB185B4984FBA165D3861FF6@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2339c945-0e71-4dd0-02a1-08d80ec40b39 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 11:30:43.6740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PAqnVCJyfuR49pAiQh+r8U+lnpwHVRFa9r+TZcIG9xbVly8PTQR+M9aqrkTYCDeBBmghQbt29rzCI2RrLf7NScdTQwcKVKmRgJrat4uYKU0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0302MB3340 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "julien@xen.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gRnJpLCAyMDIwLTA2LTEyIGF0IDA2OjQzICswMjAwLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0K PiBPbiAxMi4wNi4yMCAwMjoyMiwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+ID4gK3ZvaWQg dmNwdV9lbmRfaHlwX3Rhc2soc3RydWN0IHZjcHUgKnYpDQo+ID4gK3sNCj4gPiArICAgIGludCBk ZWx0YTsNCj4gPiArDQo+ID4gKyAgICBpZiAoIGlzX2lkbGVfdmNwdSh2KSApDQo+ID4gKyAgICAg ICAgcmV0dXJuOw0KPiA+ICsNCj4gPiArICAgIEFTU0VSVCh2LT5pbl9oeXBfdGFzayk7DQo+ID4g Kw0KPiA+ICsgICAgLyogV2UgYXNzdW1lIHRoYXQgaHlwZXJ2aXNvciB0YXNrIHRpbWUgd2lsbCBu b3Qgb3ZlcmZsb3cgaW50ICovDQo+IA0KPiBUaGlzIHdpbGwgZGVmaW5pdGVseSBoYXBwZW4gZm9y IGxvbmcgcnVubmluZyBWTXMuIFBsZWFzZSB1c2UgYSA2NC1iaXQNCj4gdmFyaWFibGUuDQo+IA0K DQpJdCBpcyBub3Qgc3Vwb3NlZCB0byBob2xkIGxvbmcgdGltZSBzcGFucywgYXMgSSBkZXNjcmli ZWQgaW4gdGhlIHJlcGx5DQp0byBwcmV2aW91cyBlbWFpbC4NCg0KPiA+ICsgICAgZGVsdGEgPSBO T1coKSAtIHYtPmh5cF9lbnRyeV90aW1lOw0KPiA+ICsgICAgYXRvbWljX2FkZChkZWx0YSwgJnYt PnNjaGVkX3VuaXQtPmh5cF90aW1lKTsNCj4gPiArDQo+ID4gKyNpZm5kZWYgTkRFQlVHDQo+ID4g KyAgICB2LT5pbl9oeXBfdGFzayA9IGZhbHNlOw0KPiA+ICsjZW5kaWYNCj4gPiArfQ0KPiA+ICsN Cj4gPiAgIC8qDQo+ID4gICAgKiBEbyB0aGUgYWN0dWFsIG1vdmVtZW50IG9mIGFuIHVuaXQgZnJv bSBvbGQgdG8gbmV3IENQVS4gTG9ja3MgZm9yICpib3RoKg0KPiA+ICAgICogQ1BVcyBuZWVkcyB0 byBoYXZlIGJlZW4gdGFrZW4gYWxyZWFkeSB3aGVuIGNhbGxpbmcgdGhpcyENCj4gPiBAQCAtMjYx NSw2ICsyNjQ2LDcgQEAgc3RhdGljIHZvaWQgc2NoZWR1bGUodm9pZCkNCj4gPiAgIA0KPiA+ICAg ICAgIFNDSEVEX1NUQVRfQ1JBTksoc2NoZWRfcnVuKTsNCj4gPiAgIA0KPiA+ICsgICAgdmNwdV9l bmRfaHlwX3Rhc2soY3VycmVudCk7DQo+ID4gICAgICAgcmN1X3JlYWRfbG9jaygmc2NoZWRfcmVz X3JjdWxvY2spOw0KPiA+ICAgDQo+ID4gICAgICAgbG9jayA9IHBjcHVfc2NoZWR1bGVfbG9ja19p cnEoY3B1KTsNCj4gPiBkaWZmIC0tZ2l0IGEveGVuL2NvbW1vbi9zb2Z0aXJxLmMgYi94ZW4vY29t bW9uL3NvZnRpcnEuYw0KPiA+IGluZGV4IDA2M2U5M2NiZTMuLjAzYTI5Mzg0ZDEgMTAwNjQ0DQo+ ID4gLS0tIGEveGVuL2NvbW1vbi9zb2Z0aXJxLmMNCj4gPiArKysgYi94ZW4vY29tbW9uL3NvZnRp cnEuYw0KPiA+IEBAIC03MSw3ICs3MSw5IEBAIHZvaWQgcHJvY2Vzc19wZW5kaW5nX3NvZnRpcnFz KHZvaWQpDQo+ID4gICB2b2lkIGRvX3NvZnRpcnEodm9pZCkNCj4gPiAgIHsNCj4gPiAgICAgICBB U1NFUlRfTk9UX0lOX0FUT01JQygpOw0KPiA+ICsgICAgdmNwdV9iZWdpbl9oeXBfdGFzayhjdXJy ZW50KTsNCj4gPiAgICAgICBfX2RvX3NvZnRpcnEoMCk7DQo+ID4gKyAgICB2Y3B1X2VuZF9oeXBf dGFzayhjdXJyZW50KTsNCj4gDQo+IFRoaXMgd29uJ3Qgd29yayBmb3Igc2NoZWR1bGluZy4gY3Vy cmVudCB3aWxsIGVpdGhlciBoYXZlIGNoYW5nZWQsDQo+IG9yIGluIHg4NiBjYXNlIF9fZG9fc29m dGlycSgpIG1pZ2h0IGp1c3Qgbm90IHJldHVybi4gWW91IG5lZWQgdG8NCj4gaGFuZGxlIHRoYXQg Y2FzZSBleHBsaWNpdGx5IGluIHNjaGVkdWxlKCkgKHlvdSBkaWQgdGhhdCBmb3IgdGhlDQo+IG9s ZCB2Y3B1LCBidXQgZm9yIHRoZSBjYXNlIHNjaGVkdWxlKCkgaXMgcmV0dXJuaW5nIHlvdSBuZWVk IHRvDQo+IGNhbGwgdmNwdV9iZWdpbl9oeXBfdGFzayhjdXJyZW50KSB0aGVyZSkuDQo+IA0KDQpX ZWxsLCB0aGlzIGlzIG9uZSBvZiBxdWVzdGlvbnMsIEkgd2FudGVkIHRvIGRpc2N1c3MuIEkgY2Vy dGFpbmx5IG5lZWQNCnRvIGNhbGwgdmNwdV9iZWdpbl9oeXBfdGFzayhjdXJyZW50KSBhZnRlciBj b250ZXh0IHN3aXRjaC4gQnV0IHdoYXQgaXQNCmlzIHRoZSByaWdodCBwbGFjZT8gSWYgbXkgdW5k ZXJzdGFuaW5nIGlzIHJpZ2h0LCBjb2RlIG9uIHg4NiBwbGF0Zm9ybQ0Kd2lsbCBuZXZlciByZWFj aCB0aGlzIHBvaW50LiBPciBJJ20gd3JvbmcgdGhlcmU/DQoNCg0K From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:33:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:33:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhwS-0008HE-8w; Fri, 12 Jun 2020 11:33:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhwQ-0008H9-H1 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:33:46 +0000 X-Inumbo-ID: 930c4096-aca0-11ea-bca7-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.59]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 930c4096-aca0-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 11:33:45 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jaTlyD4RZQVmVKuY3oMe7yOeHt3eKTqbkHswK9tqzS1d4n3IWOFdZsLRlFwujMvZNkz2gz+q+cD3yM1ILnPa/Mw8jEVFO+fGfWP3ddbWqADLf9+DJbOB2PQrxBwv5l1y3/CqWjcVALqe7+ioCmomrY7qQRz7V6xiYDZPa+CWwtqEKGdIvSe7M4Sq41SbrX7Pi1RMXt0PuvKjVy+jATMSxAWtDIoIR0qQIyGdnyELBKxNPpItlILtZpPtyU1EHcYCIK/ScQGz4MSBovljM1bQ5+NR/0RtZOBeC1L/T9rt0ujcCmEHneEecpRyRQ4HFiPB+zNNp/BPKUFm59t0YXcAww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9LvR7rgrlC19l7lRbfXikcp4dB6ECnlEC1sPyXN88I8=; b=dpYKBTdfxPQdC6lY/A5hFmFLIJiNvZ4vTMUyUEM+xUn59rygIileZIepSzUHKfZPFec5WbRz1jDdAC8U60w3ls1M/R1LV6ZNVovO5plJRpdg6hXeuS4o1xzGYEIFR+DrXn8H1hEP+8oE0QPeLOsMPiBFBqJzTKxgVyWhn3/ocWoo76P6oLO8cNJ6AMg4IikwNTBg0i/113J3QL3qA5HdOYouflIDFnbEREK/PmoTtRKt2i8bXIAKUqLd40r0E+OmPQWwqofslga5Yv8+lVLRsdXep3PVmIpGxatfI727o25v5xb4DtY4C1OOoyyaS+lNmEm5FAUuiH+AqzHSfCAy7g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9LvR7rgrlC19l7lRbfXikcp4dB6ECnlEC1sPyXN88I8=; b=prbI9bACCP0+YmaI/bX5WpQ1UKo/Jx4clqaUyf92DyLFJs3RVjBaIPfh1EgqJui6dDl68Mg915etmZ5GuBDwieveHssNEBDzOCNFRA4k8EvCO0rpSbOKHNCultrMIAsFbX87JHj6AOAoj048AqboNn7ptAq+yfhSi4hN1JE9E+hfTGmXokPc7BPJvvgbXTJucKbLkjrN5RBg9VVJ0liA18+lr3CXDQ3N8D1IkxOjPzns59uBocwo00KzDRm/5+PUJ24iZT8B+h4snC6QqRr9EqgOYil5taPexjBABV3gOzahkD4Ltwux8dh0MUdZYY+mwsVTOfhaEQBm0DXIBuoXfA== Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com (2603:10a6:8:c::18) by DB3PR0302MB3340.eurprd03.prod.outlook.com (2603:10a6:8:a::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Fri, 12 Jun 2020 11:33:44 +0000 Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290]) by DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290%2]) with mapi id 15.20.3088.023; Fri, 12 Jun 2020 11:33:44 +0000 From: Volodymyr Babchuk To: "jgross@suse.com" , "julien@xen.org" , "xen-devel@lists.xenproject.org" Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler Thread-Topic: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler Thread-Index: AQHWQE+STyWApsQdk0CG54zgwiPygKjUZV2AgAByxQCAAADXAIAAAQ+A Date: Fri, 12 Jun 2020 11:33:44 +0000 Message-ID: <5bd54018f5e045816d25f686124395a1f27a2122.camel@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> <7ec7b6568afb3df41f8407015c198b1ccb341c5b.camel@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1636f430-5880-41c8-a416-08d80ec476e4 x-ms-traffictypediagnostic: DB3PR0302MB3340: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7/2R1LjC0qPTxIkXO2YH8EW8ajEVv4UayKII4t/XhgYmjoyIfgN90V0OzMUThDJazofMaBPY49hUzBObC2DqknOhFO/2nu13AvhykVag8QJIM0U0rMUXS38vl3FufGRQgZU8FxSZ43MiaWc+6ux14dA82migMQIqS93X6HbJVJ70jZVUtQBIXgWYwDh1q2gR5vIWylxzjuOLbN+5o6tlVVqGsGLJ0SrXiCT6vGdA34Ij55vOc0QOT2LGCvXtA0+60Fp+KB1gP1CdBQ9Vf14em496TZc3AP1JUOKlZt/cGgrZrYnS0ck8nxAykAucH8F5QT4S351qs1VQnSgBZvBm6A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB3PR0302MB3401.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(346002)(396003)(376002)(7416002)(110136005)(86362001)(66574014)(8936002)(83380400001)(54906003)(4326008)(316002)(66556008)(91956017)(55236004)(66476007)(64756008)(6486002)(478600001)(186003)(76116006)(6512007)(26005)(6506007)(66446008)(53546011)(5660300002)(8676002)(2616005)(66946007)(36756003)(2906002)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HjoO+YKOCUzZ5rFeZ1PuRrD2UuyxFJvx45lPy/F/L7ZYzTxqLU+spSorsSqfridYu1gkyhYbu3Kkhd89gKsUUDZhd7Eajbgx89r2f3U/ywLEy13BnGUbSNdYMGGjsYhgaWulWJyxN1BCeUeuh5XmBMun2flh77ApOvuOYNA/fEpCRneD574ynHgVE6LntNhaQdSN+I49be3NAFjFaVKt6JhJD/mBPkxEzDpT2zbAVZjSGJHNi7taJXsHvQcTvUHKi57TWlagrGkBFiPyHifN7updeZQfiUFDtkwJ3yTTmwmbJW9o9A23KaP5DksHYF0zGQ7r2K2SskspD6YCSN9GpySsemlQIhgULIFzVVjYgcwCBDKVLbhd0tPNdDcrarREN3qPTRZFAYIDFGgTOdf5FfUKO1/pzyYsOZ8BeKEr2ru8Pcjo4i8ua3njpet3U/nUFeIhnI0IPQqDrqVDB1RMzFd02bfibeTXQXx0YdSVPM7iJ+yKZcAPnV8LHiqSbkjl x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1636f430-5880-41c8-a416-08d80ec476e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 11:33:44.2850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GOZaBEBWVBvTy3q20WXybW3MNuOTfZsMhlPpwdPg74nlaIXa/2j9eC+OKQpgtCMJOFWfxjhDhd6gzq/69JMyZA7tqMvBvrMk2dTqRQrCx8o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0302MB3340 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiBGcmksIDIwMjAtMDYtMTIgYXQgMTI6MjkgKzAxMDAsIEp1bGllbiBHcmFsbCB3cm90ZToN Cj4gDQo+IE9uIDEyLzA2LzIwMjAgMTI6MjYsIFZvbG9keW15ciBCYWJjaHVrIHdyb3RlOg0KPiA+ IEhpIEp1cmdlbiwNCj4gPiANCj4gPiB0aGFua3MgZm9yIHRoZSByZXZpZXcNCj4gPiANCj4gPiBP biBGcmksIDIwMjAtMDYtMTIgYXQgMDY6MzYgKzAyMDAsIErDvHJnZW4gR3Jvw58gd3JvdGU6DQo+ ID4gDQo+ID4gPiBPbiAxMi4wNi4yMCAwMjoyMiwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+ ID4gDQo+ID4gWy4uLl0NCj4gPiANCj4gPiA+ID4gK3ZvaWQgdmNwdV9lbmRfaXJxX2hhbmRsZXIo dm9pZCkNCj4gPiA+ID4gK3sNCj4gPiA+ID4gKyAgICBpbnQgZGVsdGE7DQo+ID4gPiA+ICsNCj4g PiA+ID4gKyAgICBpZiAoaXNfaWRsZV92Y3B1KGN1cnJlbnQpKQ0KPiA+ID4gPiArICAgICAgICBy ZXR1cm47DQo+ID4gPiA+ICsNCj4gPiA+ID4gKyAgICBBU1NFUlQoY3VycmVudC0+aXJxX25lc3Rp bmcpOw0KPiA+ID4gPiArDQo+ID4gPiA+ICsgICAgaWYgKCAtLWN1cnJlbnQtPmlycV9uZXN0aW5n ICkNCj4gPiA+ID4gKyAgICAgICAgcmV0dXJuOw0KPiA+ID4gPiArDQo+ID4gPiA+ICsgICAgLyog V2UgYXNzdW1lIHRoYXQgaXJxIGhhbmRsaW5nIHRpbWUgd2lsbCBub3Qgb3ZlcmZsb3cgaW50ICov DQo+ID4gPiANCj4gPiA+IFRoaXMgYXNzdW1wdGlvbiBtaWdodCBub3QgaG9sZCBmb3IgbG9uZyBy dW5uaW5nIFZNcy4NCj4gPiANCj4gPiBCYXNpY2FsbHksIHRoaXMgdmFsdWUgaG9sZHMgdGltZSBz cGFuIGJldHdlZW4gY2FsbHMgdG8gc2NoZWR1bGUoKS4gVGhpcw0KPiA+IHZhcmlhYmxlIGdldHMg emVyb2VkIG91dCBldmVyeSB0aW1lIHNjaGVkdWxlciByZXF1ZXN0cyBmb3IgdGltZQ0KPiA+IGFk anVzdG1lbnQgdmFsdWUuIFNvLCBpdCBzaG91bGQgbm90IGRlcGVuZCBvbiB0b3RhbCBWTSBydW4g dGltZS4NCj4gVGhpcyBpcyBhc3N1bWluZyB0aGF0IHRoZSBzY2hlZHVsZXIgd2lsbCBiZSBjYWxs ZWQuIFdpdGggdGhlIE5VTEwgDQo+IHNjaGVkdWxlciBpbiBwbGFjZSwgdGhlcmUgaXMgYSBmYWly IGNoYW5jZSB0aGlzIG1heSBuZXZlciBiZSBjYWxsZWQuDQo+IA0KPiBTbyBJIHRoaW5rIHVzaW5n IGEgNjQtYml0IHZhbHVlIGlzIGxpa2VseSBzYWZlci4NCg0KV2VsbCwgSSB3YW50ZWQgdG8gdXNl IDY0LWJpdCB2YWx1ZSBpbiB0aGUgZmlyc3QgcGxhY2UuIEJ1dCBJIGdvdCB0aGUNCmltcHJlc3Np b24gdGhhdCBhdG9taWNfdCBzdXBwb3J0cyBvbmx5IDMyLWJpdCB2YWx1ZXMuIEF0IGxlYXN0LCB0 aGlzIGlzDQp3aGF0IEknbSBzZWVpbmcgaW4gYXRvbWljLmgNCg0KQW0gSSB3cm9uZz8NCg0KPiBD aGVlcnMsDQo+IA0K From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:37:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:37:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhzo-0008Po-PI; Fri, 12 Jun 2020 11:37:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhzn-0008Pg-R2 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:37:15 +0000 X-Inumbo-ID: 10636d08-aca1-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 10636d08-aca1-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 11:37:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=MLb24URko1JnPiR3wZfJipAfelkD9ExiUL5o+KFNzUg=; b=aXwFpbFnGIKHecrJKzzEdyZPv/ sCuXuqLK3W4jUzafQ/xi3O1Y54aZ41cEY87kzpOu9mNIHnHmuATVq59dhL2P105azbJcPkcOBlN/z 9+g5yFUMKxEU/VBhi22YMcVU0f8Lb8aWd09hEJkaEYtZzlMryV3+MGGm3NAAH7kTJkHg=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjhzm-0008CM-Ua; Fri, 12 Jun 2020 11:37:14 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjhzm-0002tq-O5; Fri, 12 Jun 2020 11:37:14 +0000 Subject: Re: [PATCH 2/2] xen/arm: Support runstate crossing pages To: Stefano Stabellini , Bertrand Marquis References: From: Julien Grall Message-ID: <9379a633-e63a-bf7a-6e2a-67a338737a81@xen.org> Date: Fri, 12 Jun 2020 12:37:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, nd@arm.com, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 12/06/2020 02:10, Stefano Stabellini wrote: > On Thu, 11 Jun 2020, Bertrand Marquis wrote: >> Add support for runstate area register with the structure crossing pages >> The code is storing up to 2 pages reference during the hypercall. >> During a context switch, the code is computing where the >> state_entry_time is and is breaking the memcpy in 2 parts when it is >> required. >> >> Signed-off-by: Bertrand Marquis > > Clearly a lot of efforts went into this patch, thanks you Bertrand. > > The change is complex for the feature it adds. I wonder if we could use > ioremap (or maybe something similar but using a different virtual space) > to simplify it. Julien, do you have good ideas? ioremap() is for MMIO region, so you would want to use vmap(). Note that former is just a wrapper of the latter. vmap() is probably a good start for now, but not ideal for long term because the vmap() area is fairly small (768MB) and if we want to go towards a secret-free hypervisor on Arm, we would want to restrict the visibility of the mapping to the other CPUs. I think it would be good to have some per-CPU/per-domain mapping to limit the waste of the address space. But this will require to deduplicate page-tables for arm64 (I was actually looking at it over the past few week-ends). For the time-being, I would suggest to use vmap(). The memory is always direct mapped on arm64, so it should make no different for security concern. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:38:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:38:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jji10-0008Vr-3U; Fri, 12 Jun 2020 11:38:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jji0y-0008Vi-PB for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:38:28 +0000 X-Inumbo-ID: 3b22919a-aca1-11ea-bb8b-bc764e2007e4 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.74]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3b22919a-aca1-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 11:38:27 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ahvu33HQTfnRNpCyULoCeK1K10X5cHGey7EzQpPvIlA0iQ7Law5+Ud9IfBreBRq6j8r/vBKmiviF/lU0Ow1nIG7yQ3LMlL2+ZTBSye+pc4xu5WBVCL7M1Da7ewjf56Vl7gm06LkRiSliPRF0KCHP6jcbZA19GxT1qm2tk7otwWHGQk//VQjh0Akt1GoSVurcZQlMxm74iguMMXr55skb/3p1MCZtuJdMcMwQpTBE0DPEBbEozhov0+95qo7nkfa8gT40iqbhNL4I0qVJNjG8V4Z/ucHF9mHyBQ8jvpRLCdSRUEdSIarjGv7U+CsWnFvIsCQywsM7WT9djk2v+Hz3Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nKr01J6bycECPR64sbz8JtTVBqlGyFTxjcHpxmtJoH8=; b=DxlFi2xzPeCDA44Czx2OkpTPvqlaVoXUtcHp45jmlEuN6Q7aH8aWKVCsvjCJbgBC4OHAOyn3k0f1NUl5xM9IyB1X/JsU7NGfYhKHZ8RmXytz2raGmB5vJ7aRE8ceSeZrkcUX71z2I7mHMuIiWCmPKTkKl1jeAl0JatTiQKxN0pONSizgKqXAWYE/pXrfjtqJ5ezyd9YKyVfGipBKxBWgYRZCW2urYL0NwzVTvIClNahQiK0yN8hzKSfJKsogRVVty2PocmhpGcrEGV1I3V0zpzfnxts7M+qyAVpU7FTX39gZMtJo6v82y9z1FEoshj5iIqGvLKIsC29FeGxsTayiNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nKr01J6bycECPR64sbz8JtTVBqlGyFTxjcHpxmtJoH8=; b=yx61UnoKBvxdRnPj0acob6NLKWna2DCMFVP9htm25dGtNLS6rzJ9KhUGT0oh5usXAn8f+HY5g6YfCfui2rPM1U9GzziKsJm1CBYiLNAq5CR2lLYMB/9ouesu6rtBpIHe0tXfs+yHNPjRLRrf2cnKROO84SzL5XhmTxXnz25RrKDf+1qdjZEuvRC6rNL1FEjPX4xWzFvX2YgsN8UbTrJib2eDm9RGMLbxVZnma7CF/mLxx49EZtZX0BXBNjKJJUwvqPehO09Ntj3raH5qiaSEhcV1xhy+ugQKHQr2csGUHDcgITqiDcJWgmh/tdQbIZ6XSYRtD+ZmKW+gU7sq+reyNA== Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com (2603:10a6:8:c::18) by DB3PR0302MB3179.eurprd03.prod.outlook.com (2603:10a6:8:8::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Fri, 12 Jun 2020 11:38:26 +0000 Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290]) by DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290%2]) with mapi id 15.20.3088.023; Fri, 12 Jun 2020 11:38:26 +0000 From: Volodymyr Babchuk To: "jgross@suse.com" , "xen-devel@lists.xenproject.org" Subject: Re: [RFC PATCH v1 3/6] sched, credit2: improve scheduler fairness Thread-Topic: [RFC PATCH v1 3/6] sched, credit2: improve scheduler fairness Thread-Index: AQHWQE+TBfX1MPdkGkC6vJ7ur/uY5KjUaaaAgABxsoA= Date: Fri, 12 Jun 2020 11:38:25 +0000 Message-ID: <33db319c8a533fc08b168d24c329533516d14f8b.camel@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-4-volodymyr_babchuk@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 650e596b-7086-4b28-2358-08d80ec51ebf x-ms-traffictypediagnostic: DB3PR0302MB3179: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rSxtq09RgQX/TpnoejsGXugjREM30U8k6PVO6/IJpZc9KV29/QBmLgCegpxUFtcwEfb3ZADtruVkzc9ZSeGqKLUlKWoNVS5e+jo4bFiTs1fpiNtWaQg/OhY7UwRHDGHdqUvIHD1vADhzAfrwhnDniYnM6RisNV5ZqjfdM84f1A1O5LasQM2UI2JF+TdM9Po02inXQLZq7ZLnkh1OLbVngnZZAhjANKEzeOkLFSeK1PqICZ0/hk5D0uipWPQqTP2VAg4dObZ5No/sP5HmXgiucu1a5/+QZwb9A4F8SCZlPStiAHtsaYcFdBXmQTmp1g2xiY0QgSO1ljNLsdcUSunL1A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB3PR0302MB3401.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(39860400002)(136003)(346002)(376002)(66476007)(64756008)(186003)(66446008)(66556008)(66946007)(6506007)(53546011)(76116006)(2906002)(36756003)(55236004)(2616005)(6486002)(478600001)(5660300002)(91956017)(4326008)(8936002)(83380400001)(66574014)(6512007)(110136005)(316002)(54906003)(71200400001)(8676002)(26005)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: vgTqayEqzPRk8/ORF52czRcd+qc8LFbkygctvCjYbodEiKgXbh8xKrOCV6g5FkDGXfv6eXoWGoWbgYuxUYGZNZc+kSR0032rMYIHV5aIObLUUJctNlqX4DczCjJWU4mOy8L3QKLjrEpDz90nQhysAOeKJSZgibVx+GjvWMbNC35f62+uxHJwWhr9xelSsU3xJbUvY3N/uRpDIoEFm/aqUXSzanuuKw2Zs1xWpVsPbCIgvxP0M7emjNWE7xIUO03s7fC3pg/V5aRnjz8yulPC6br7ZmLsryLFDO/sb9g3YC8aCfSnYfgnFUcjdAECTax1x1j+CvRsOzE2tTuj8coNdkE1IJcQbEnIcMHYQtOjY7NjlpamguU3fCaKqXk+jrj58cWxL6K3C+le4sjpVDjI3qBVsHvgPfShzKgM0ALrdw0p8hXHsiyX0wQvre7kL3Nq+Vo9KUDNjW8LWPy+vtZWCN5Gj743OBG6ZXwXPWZB1yTry1ePP+se4oUB7aEXaOcn x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <67629A311D269745AF796C203D32BDC8@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 650e596b-7086-4b28-2358-08d80ec51ebf X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 11:38:25.9654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FOm/2U+pBr5r+s8igHAasxjU8Cc0Qd6cFuJJ0f+OzeANAeRDxvFgebUVp2LeRuuevS1y2wkXWBLpJJwbnAGwr+enso/i+t1G6xQhz5HsEMY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0302MB3179 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "george.dunlap@citrix.com" , "dfaggioli@suse.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gRnJpLCAyMDIwLTA2LTEyIGF0IDA2OjUxICswMjAwLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0K PiBPbiAxMi4wNi4yMCAwMjoyMiwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+ID4gTm93IHdl IGNhbiBtYWtlIGNvcnJlY3Rpb25zIGZvciBzY2hlZHVsaW5nIHVuaXQgcnVuIHRpbWUsIGJhc2Vk IG9uDQo+ID4gZGF0YSBnYXRoZXJlZCBpbiBwcmV2aW91cyBwYXRjaGVzLiBUaGlzIGluY2x1ZGVz IHRpbWUgc3BlbnQgaW4gSVJRDQo+ID4gaGFuZGxlcnMgYW5kIHRpbWUgc3BlbnQgZm9yIGh5cGVy dmlzb3IgaG91c2VrZWVwaW5nIHRhc2tzLiBUaG9zZSB0aW1lDQo+ID4gc3BhbnMgbmVlZHMgdG8g YmUgZGVkdWNlZCBmcm9tIGEgdG90YWwgcnVuIHRpbWUuDQo+ID4gDQo+ID4gVGhpcyBwYXRjaCBh ZGRzIHNjaGVkX2dldF90aW1lX2NvcnJlY3Rpb24oKSBmdW5jdGlvbiB3aGljaCByZXR1cm5zDQo+ ID4gdGltZSBjb3JyZWN0aW9uIHZhbHVlLiBUaGlzIHZhbHVlIHNob3VsZCBiZSBzdWJ0cmFjdGVk IGJ5IGEgc2NoZWR1bGVyDQo+ID4gaW1wbGVtZW50YXRpb24gZnJvbSBhIHRvdGFsIHZDUFUvc2hj ZWRfdW5pdCBydW4gdGltZS4NCj4gPiANCj4gPiBUT0RPOiBNYWtlIHRoZSBjb3JyZXNwb25kaW5n IGNoYW5nZXMgdG8gYWxsIG90aGVyIHNjaGVkdWxlcnMuDQo+ID4gDQo+ID4gU2lnbmVkLW9mZi1i eTogVm9sb2R5bXlyIEJhYmNodWsgPHZvbG9keW15cl9iYWJjaHVrQGVwYW0uY29tPg0KPiA+IC0t LQ0KPiA+ICAgeGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMgICAgfCAyMyArKysrKysrKysrKysrKysr KysrKysrKw0KPiA+ICAgeGVuL2NvbW1vbi9zY2hlZC9jcmVkaXQyLmMgfCAgMiArLQ0KPiA+ICAg eGVuL2NvbW1vbi9zY2hlZC9wcml2YXRlLmggfCAxMCArKysrKysrKysrDQo+ID4gICAzIGZpbGVz IGNoYW5nZWQsIDM0IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gPiANCj4gPiBkaWZm IC0tZ2l0IGEveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMgYi94ZW4vY29tbW9uL3NjaGVkL2NvcmUu Yw0KPiA+IGluZGV4IGQ1OTc4MTFmZWYuLmE3Mjk0ZmY1YzMgMTAwNjQ0DQo+ID4gLS0tIGEveGVu L2NvbW1vbi9zY2hlZC9jb3JlLmMNCj4gPiArKysgYi94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYw0K PiA+IEBAIC05NzQsNiArOTc0LDI5IEBAIHZvaWQgdmNwdV9lbmRfaHlwX3Rhc2soc3RydWN0IHZj cHUgKnYpDQo+ID4gICAjaWZuZGVmIE5ERUJVRw0KPiA+ICAgICAgIHYtPmluX2h5cF90YXNrID0g ZmFsc2U7DQo+ID4gICAjZW5kaWYNCj4gPiArDQo+ID4gK3NfdGltZV90IHNjaGVkX2dldF90aW1l X2NvcnJlY3Rpb24oc3RydWN0IHNjaGVkX3VuaXQgKnUpDQo+ID4gK3sNCj4gPiArICAgIHVuc2ln bmVkIGxvbmcgZmxhZ3M7DQo+ID4gKyAgICBpbnQgaXJxLCBoeXA7DQo+IA0KPiBVc2luZyAiaXJx IiBmb3IgYSB0aW1lIHZhbHVlIGlzIG1pc2xlYWRpbmcgSU1PLg0KDQpZZXMsIHlvdSBhcmUgcmln aHQuIEknbGwgcmVuYW1lIHRoaXMgdmFyaWFibGVzIHRvIGlycV90aW1lIGFuZA0KaHlwX3RpbWUu IA0KDQo+ID4gKw0KPiA+ICsgICAgd2hpbGUgKCB0cnVlICkNCj4gPiArICAgIHsNCj4gPiArICAg ICAgICBpcnEgPSBhdG9taWNfcmVhZCgmdS0+aXJxX3RpbWUpOw0KPiA+ICsgICAgICAgIGlmICgg bGlrZWx5KCBpcnEgPT0gYXRvbWljX2NtcHhjaGcoJnUtPmlycV90aW1lLCBpcnEsIDApKSApDQo+ ID4gKyAgICAgICAgICAgIGJyZWFrOw0KPiA+ICsgICAgfQ0KPiANCj4gSnVzdCB1c2UgYXRvbWlj X3hjaGcoKT8NCg0KVGhhbmtzLiBJIHNvbWVob3cgbWlzc2VkIHRoaXMgbWFjcm8uDQoNCj4gPiAr DQo+ID4gKyAgICB3aGlsZSAoIHRydWUgKQ0KPiA+ICsgICAgew0KPiA+ICsgICAgICAgIGh5cCA9 IGF0b21pY19yZWFkKCZ1LT5oeXBfdGltZSk7DQo+ID4gKyAgICAgICAgaWYgKCBsaWtlbHkoIGh5 cCA9PSBhdG9taWNfY21weGNoZygmdS0+aHlwX3RpbWUsIGh5cCwgMCkpICkNCj4gPiArICAgICAg ICAgICAgYnJlYWs7DQo+ID4gKyAgICB9DQo+ID4gKw0KPiA+ICsgICAgcmV0dXJuIGlycSArIGh5 cDsNCj4gDQo+IEFoLCBJIGRpZG4ndCBsb29rIGludG8gdGhpcyBwYXRjaCB1bnRpbCBub3cuDQo+ IA0KPiBZb3UgY2FuIHJlcGxhY2UgbXkgY29tbWVudHMgYWJvdXQgb3ZlcmZsb3cgb2YgYW4gaW50 IGZvciBwYXRjaGVzIDEgYW5kIDINCj4gd2l0aDoNCj4gDQo+ICAgIFBsZWFzZSBtb2RpZnkgdGhl IGNvbW1lbnQgYWJvdXQgbm90IG92ZXJmbG93aW5nIGhpbnRpbmcgdG8gdGhlIHZhbHVlDQo+ICAg IGJlaW5nIHJlc2V0IHdoZW4gbWFraW5nIHNjaGVkdWxpbmcgZGVjaXNpb25zLg0KDQpXaWxsIGRv Lg0KDQo+IEFuZCB0aGlzIChvZiBjb3Vyc2UpIG5lZWRzIHRvIGJlIGhhbmRsZWQgaW4gYWxsIG90 aGVyIHNjaGVkdWxlcnMsIHRvby4NCj4gDQoNClllcywgdGhlIHBsYW4gaXMgdG8gY2FsbCB0aGlz IGZ1bmN0aW9uIGluIGFsbCBzY2hlZHVsZXJzLiBJIHNraXBwZWQNCnRoaXMgaW4gUkZDLCBiZWNh dXNlIEkgd2FudGVkIHRvIGRpc2N1c3MgdGhlIGdlbmVyYWwgYXBwcm9jaC4gSSdsbCBhZGQNCnN1 cHBvcnQgZm9yIGFsbCBvdGhlciBzY2hlZHVsZXJzIGluIHRoZSBuZXh0IHZlcnNpb24uDQo= From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:41:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:41:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jji3L-0000s9-Ko; Fri, 12 Jun 2020 11:40:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jji3K-0000s4-OX for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:40:54 +0000 X-Inumbo-ID: 9274a550-aca1-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9274a550-aca1-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 11:40:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 330B3AD75; Fri, 12 Jun 2020 11:40:56 +0000 (UTC) Subject: Re: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks To: Volodymyr Babchuk , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-3-volodymyr_babchuk@epam.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <918fa2e1-232c-a3ff-d0a9-776b470ee5db@suse.com> Date: Fri, 12 Jun 2020 13:40:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "julien@xen.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.20 13:30, Volodymyr Babchuk wrote: > On Fri, 2020-06-12 at 06:43 +0200, Jürgen Groß wrote: >> On 12.06.20 02:22, Volodymyr Babchuk wrote: >>> +void vcpu_end_hyp_task(struct vcpu *v) >>> +{ >>> + int delta; >>> + >>> + if ( is_idle_vcpu(v) ) >>> + return; >>> + >>> + ASSERT(v->in_hyp_task); >>> + >>> + /* We assume that hypervisor task time will not overflow int */ >> >> This will definitely happen for long running VMs. Please use a 64-bit >> variable. >> > > It is not suposed to hold long time spans, as I described in the reply > to previous email. > >>> + delta = NOW() - v->hyp_entry_time; >>> + atomic_add(delta, &v->sched_unit->hyp_time); >>> + >>> +#ifndef NDEBUG >>> + v->in_hyp_task = false; >>> +#endif >>> +} >>> + >>> /* >>> * Do the actual movement of an unit from old to new CPU. Locks for *both* >>> * CPUs needs to have been taken already when calling this! >>> @@ -2615,6 +2646,7 @@ static void schedule(void) >>> >>> SCHED_STAT_CRANK(sched_run); >>> >>> + vcpu_end_hyp_task(current); >>> rcu_read_lock(&sched_res_rculock); >>> >>> lock = pcpu_schedule_lock_irq(cpu); >>> diff --git a/xen/common/softirq.c b/xen/common/softirq.c >>> index 063e93cbe3..03a29384d1 100644 >>> --- a/xen/common/softirq.c >>> +++ b/xen/common/softirq.c >>> @@ -71,7 +71,9 @@ void process_pending_softirqs(void) >>> void do_softirq(void) >>> { >>> ASSERT_NOT_IN_ATOMIC(); >>> + vcpu_begin_hyp_task(current); >>> __do_softirq(0); >>> + vcpu_end_hyp_task(current); >> >> This won't work for scheduling. current will either have changed, >> or in x86 case __do_softirq() might just not return. You need to >> handle that case explicitly in schedule() (you did that for the >> old vcpu, but for the case schedule() is returning you need to >> call vcpu_begin_hyp_task(current) there). >> > > Well, this is one of questions, I wanted to discuss. I certainly need > to call vcpu_begin_hyp_task(current) after context switch. But what it > is the right place? If my understaning is right, code on x86 platform > will never reach this point. Or I'm wrong there? No, this is correct. You can add the call to context_switch() just after set_current() has been called. Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:44:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:44:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jji78-00011m-58; Fri, 12 Jun 2020 11:44:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jji76-00011h-As for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:44:48 +0000 X-Inumbo-ID: 1d1e0fd4-aca2-11ea-bb8b-bc764e2007e4 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (unknown [40.107.3.79]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1d1e0fd4-aca2-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 11:44:46 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZVWvr94iECSrBgP1XKVDtfN2VXY5QNtKHl6HqO6QYn0sYsaMjR7LUx0daRhJZbHLvX3xTJebWAfb2VbRtakhlA1+VlHaFmL5rPgT2KqQz7onL0vpb5EMaEEY6U9y7LE58YZrm+yBHeSVJk2TaR8serWm4Pz0brT9j4eMJPZ4BM8+6uOmxCWmfjgPITwVAdDfLmQpxyfOBTFODiVeXM8klTWxnerv99x5FQF4ir9g/SkXjEvPZk9/FqtqVTWFvX73eDVUTPzssodXznTDKsC0SxrRQB21SeM8n16quqkzGWkkYRBdEkItwXQHrHBgxPSjDJqIOQgdQW9orVpWCLhkvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=02Gz/xmHoxfc8PueJfWRwnOwqibZCGk9Z1rCGf5aDaM=; b=cd1MSWtPT76R9MZFtWV4xEwXDzaPUQclJn2WnB5QakpEVfaGTZyoOKbQpYdEhhnb8OzG724UMkiZ+flt5Rry5LxN8N+F/zQRL3VaCFkFdHtrkdaddHYaddcxpN9bW2pLntezrDLY8IKckdHxL97DmvDZUyV/BrfLzSeSLN1tie8vSSrceQRkkWLIjc6zAgfJo3A2teL7NSHT//dMMSOZ/hXhQssXTX+B6Pr5nQ74tq7HHbSekcFqYiMfe82B/CLtUjQb7AyPTxgsZW3vlEmrYyXxMA7/dEUV3Xi6KSrOOmn4weiOJodpQf1xnDsFZfRUSWqeUxc0jxHzdyV7CgTWiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=02Gz/xmHoxfc8PueJfWRwnOwqibZCGk9Z1rCGf5aDaM=; b=BKztKpjOi6JTEr22+eNYHFoI65CAFg3tew9Tlgopj4FmXEY92j5GoHa+3SIMLcpcFCMmUa51U3SiNbEUHTgaXp7R0jXL+dwBrV+1ZzDZwlX1WH4Iwps7z4sAhGum4q7jueSVXylTz6YA32OJcmjIggD/5Q/AZwdle3+EaqdrjRxrgZpesWqVBQbbtg3bM3VPChEf1PsU7xVK2Dqcqj5J0Fi1FbkNMSXJPWuzULy48oUgi4eXVTWGax6ZITCfkq030Kz96M3NQgF+ULroFVsaI0BQZvYvEM/Y0pL/NM9jhNW7P80Fp56vR+Otm0Tkhx4uw7QqOBuO6J1QHqhQzxLLzA== Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com (2603:10a6:8:c::18) by DB3PR0302MB3179.eurprd03.prod.outlook.com (2603:10a6:8:8::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Fri, 12 Jun 2020 11:44:44 +0000 Received: from DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290]) by DB3PR0302MB3401.eurprd03.prod.outlook.com ([fe80::8de:8e70:b9fe:f290%2]) with mapi id 15.20.3088.023; Fri, 12 Jun 2020 11:44:44 +0000 From: Volodymyr Babchuk To: "jgross@suse.com" , "julien@xen.org" , "xen-devel@lists.xenproject.org" Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Topic: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Index: AQHWQE+Tib/gTK49mk6bUudd1VvXZqjUa0CAgABx3AA= Date: Fri, 12 Jun 2020 11:44:44 +0000 Message-ID: <1fcd5d89691b775d1230bf3405e29893107edcb3.camel@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> In-Reply-To: <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ca7f2f8-2fa0-4ad1-a373-08d80ec60082 x-ms-traffictypediagnostic: DB3PR0302MB3179: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2958; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DHtvXvXOcyppYTxjz+kE3eSivme1ZyCqDgLnEg86EaUUcoqHj6yzPjw2hV5s5d4PW1Nox2Ren+KsA2JjnHbAAz3hOP4U2efNXbiCnkNUJZcf91plEXHoZCNiz3b+jFVCBjemcguh0pwC8nmk7+7VpYnla2eQ/l41vfxHvqkEoSl+1c2vKX68OGI7iFS9L1KWEKZFZc41zK2LmnRj845qEGxOYAKY2UCDm6fILivlvYzAzzY+VSlagQTSAL518C9bgMj5R5RW754WTA7gSHvOm0u9T4t+7/y/YbQmyJn4p+yzaMEWvmQ78Gr19mO8S33aYlbcdNcKdFmf1NlQN8jqmQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB3PR0302MB3401.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(136003)(396003)(366004)(316002)(7416002)(54906003)(71200400001)(8936002)(110136005)(83380400001)(66574014)(6512007)(86362001)(8676002)(26005)(66446008)(186003)(66556008)(66946007)(64756008)(66476007)(5660300002)(478600001)(4326008)(91956017)(6486002)(76116006)(6506007)(53546011)(55236004)(2616005)(36756003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6oixNbLxf2+nEDdE85A8qxJpzXPDsjLg/lGNQJ4voK6zLE1sHDrDJoN37VVQyFU/mm2mWxvN4u+eM70SRPtREjCnHhiZmF1eBzX6pSP3zV6WXW0ox6eSo6opVWC3swyQPqFsZT83WdyAhAHXJAIBESgY9f/Y6xZysLy0WiqPw4p1cEL8wI2fjCYofk2NN+dtbb4TBdpLtkUHktD4bgmnx1DfU5wDi+QoFIjKc0bV3fy1RE92MlnYx+ymoFQlbSqm8rf/OARFSF3kRHlTTySUk+qLSmRjQcig/hCEUE1MvwUKV/xd4ZfzCesKjTvoVjtidyl7/hGlJyKdmdOUJ0946SaY1vQU9NAgxGAsNq2xReIPCIAkfK+cyzNZX8oX0PiEc1gxW8Vui5Jdon354oi9eO42q3go1vTdypd6Dfh/8JPXpfsydZeBvqkxw5ZIfdsvcNc65QCBLQed2b5n+pt3lHIxFhFAnCRXbjWmlnV+FNPnc1O8u2jbydcISfKHAxEJ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ca7f2f8-2fa0-4ad1-a373-08d80ec60082 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 11:44:44.6720 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f6LYWMv1K13oqrIUfQxjxU1/3vnzmxicCDc+0HLb7dsFK7avOvG3CR/I4vDq8bcf4xMVkJTq95tKLxtgKw4mqhjG8PstBDo7taFqgolTJUk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0302MB3179 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiBGcmksIDIwMjAtMDYtMTIgYXQgMDY6NTcgKzAyMDAsIErDvHJnZW4gR3Jvw58gd3JvdGU6 DQo+IE9uIDEyLjA2LjIwIDAyOjIyLCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4gPiBBcyBz Y2hlZHVsZXIgY29kZSBub3cgY29sbGVjdHMgdGltZSBzcGVudCBpbiBJUlEgaGFuZGxlcnMgYW5k IGluDQo+ID4gZG9fc29mdGlycSgpLCB3ZSBjYW4gcHJlc2VudCB0aG9zZSB2YWx1ZXMgdG8gdXNl cnNwYWNlIHRvb2xzIGxpa2UNCj4gPiB4ZW50b3AsIHNvIHN5c3RlbSBhZG1pbmlzdHJhdG9yIGNh biBzZWUgaG93IHN5c3RlbSBiZWhhdmVzLg0KPiA+IA0KPiA+IFdlIGFyZSB1cGRhdGluZyBjb3Vu dGVycyBvbmx5IGluIHNjaGVkX2dldF90aW1lX2NvcnJlY3Rpb24oKSBmdW5jdGlvbg0KPiA+IHRv IG1pbmltaXplIG51bWJlciBvZiB0YWtlbiBzcGlubG9ja3MuIEFzIGF0b21pY190IGlzIDMyIGJp dCB3aWRlLCBpdA0KPiA+IGlzIG5vdCBlbm91Z2ggdG8gc3RvcmUgdGltZSB3aXRoIG5hbm9zZWNv bmQgcHJlY2lzaW9uLiBTbyB3ZSBuZWVkIHRvDQo+ID4gdXNlIDY0IGJpdCB2YXJpYWJsZXMgYW5k IHByb3RlY3QgdGhlbSB3aXRoIHNwaW5sb2NrLg0KPiA+IA0KPiA+IFNpZ25lZC1vZmYtYnk6IFZv bG9keW15ciBCYWJjaHVrIDx2b2xvZHlteXJfYmFiY2h1a0BlcGFtLmNvbT4NCj4gPiAtLS0NCj4g PiAgIHhlbi9jb21tb24vc2NoZWQvY29yZS5jICAgICB8IDE3ICsrKysrKysrKysrKysrKysrDQo+ ID4gICB4ZW4vY29tbW9uL3N5c2N0bC5jICAgICAgICAgfCAgMSArDQo+ID4gICB4ZW4vaW5jbHVk ZS9wdWJsaWMvc3lzY3RsLmggfCAgNCArKystDQo+ID4gICB4ZW4vaW5jbHVkZS94ZW4vc2NoZWQu aCAgICAgfCAgMiArKw0KPiA+ICAgNCBmaWxlcyBjaGFuZ2VkLCAyMyBpbnNlcnRpb25zKCspLCAx IGRlbGV0aW9uKC0pDQo+ID4gDQo+ID4gZGlmZiAtLWdpdCBhL3hlbi9jb21tb24vc2NoZWQvY29y ZS5jIGIveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMNCj4gPiBpbmRleCBhNzI5NGZmNWMzLi5lZTZi MWQ5MTYxIDEwMDY0NA0KPiA+IC0tLSBhL3hlbi9jb21tb24vc2NoZWQvY29yZS5jDQo+ID4gKysr IGIveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMNCj4gPiBAQCAtOTUsNiArOTUsMTAgQEAgc3RhdGlj IHN0cnVjdCBzY2hlZHVsZXIgX19yZWFkX21vc3RseSBvcHM7DQo+ID4gICANCj4gPiAgIHN0YXRp YyBib29sIHNjaGVkdWxlcl9hY3RpdmU7DQo+ID4gICANCj4gPiArc3RhdGljIERFRklORV9TUElO TE9DSyhzY2hlZF9zdGF0X2xvY2spOw0KPiA+ICtzX3RpbWVfdCBzY2hlZF9zdGF0X2lycV90aW1l Ow0KPiA+ICtzX3RpbWVfdCBzY2hlZF9zdGF0X2h5cF90aW1lOw0KPiA+ICsNCj4gPiAgIHN0YXRp YyB2b2lkIHNjaGVkX3NldF9hZmZpbml0eSgNCj4gPiAgICAgICBzdHJ1Y3Qgc2NoZWRfdW5pdCAq dW5pdCwgY29uc3QgY3B1bWFza190ICpoYXJkLCBjb25zdCBjcHVtYXNrX3QgKnNvZnQpOw0KPiA+ ICAgDQo+ID4gQEAgLTk5NCw5ICs5OTgsMjIgQEAgc190aW1lX3Qgc2NoZWRfZ2V0X3RpbWVfY29y cmVjdGlvbihzdHJ1Y3Qgc2NoZWRfdW5pdCAqdSkNCj4gPiAgICAgICAgICAgICAgIGJyZWFrOw0K PiA+ICAgICAgIH0NCj4gPiAgIA0KPiA+ICsgICAgc3Bpbl9sb2NrX2lycXNhdmUoJnNjaGVkX3N0 YXRfbG9jaywgZmxhZ3MpOw0KPiA+ICsgICAgc2NoZWRfc3RhdF9pcnFfdGltZSArPSBpcnE7DQo+ ID4gKyAgICBzY2hlZF9zdGF0X2h5cF90aW1lICs9IGh5cDsNCj4gPiArICAgIHNwaW5fdW5sb2Nr X2lycXJlc3RvcmUoJnNjaGVkX3N0YXRfbG9jaywgZmxhZ3MpOw0KPiANCj4gUGxlYXNlIGRvbid0 IHVzZSBhIGxvY2suIEp1c3QgdXNlIGFkZF9zaXplZCgpIGluc3RlYWQgd2hpY2ggd2lsbCBhZGQN Cj4gYXRvbWljYWxseS4NCg0KTG9va3MgbGlrZSBhcm0gZG9lcyBub3Qgc3VwcG9ydCA2NCBiaXQg dmFyaWFibGVzLg0KDQpKdWxpZW4sIEkgYmVsaWV2ZSwgdGhpcyBpcyBhcm12NyBsaW1pdGF0aW9u PyBTaG91bGQgYXJtdjggd29yayB3aXRoIDY0LQ0KYml0IGF0b21pY3M/DQoNCj4gPiArDQo+ID4g ICAgICAgcmV0dXJuIGlycSArIGh5cDsNCj4gPiAgIH0NCj4gPiAgIA0KPiA+ICt2b2lkIHNjaGVk X2dldF90aW1lX3N0YXRzKHVpbnQ2NF90ICppcnFfdGltZSwgdWludDY0X3QgKmh5cF90aW1lKQ0K PiA+ICt7DQo+ID4gKyAgICB1bnNpZ25lZCBsb25nIGZsYWdzOw0KPiA+ICsNCj4gPiArICAgIHNw aW5fbG9ja19pcnFzYXZlKCZzY2hlZF9zdGF0X2xvY2ssIGZsYWdzKTsNCj4gPiArICAgICppcnFf dGltZSA9IHNjaGVkX3N0YXRfaXJxX3RpbWU7DQo+ID4gKyAgICAqaHlwX3RpbWUgPSBzY2hlZF9z dGF0X2h5cF90aW1lOw0KPiA+ICsgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmc2NoZWRfc3Rh dF9sb2NrLCBmbGFncyk7DQo+IA0KPiByZWFkX2F0b21pYygpIHdpbGwgZG8gdGhlIGpvYiB3aXRo b3V0IGxvY2suDQoNClllcywgSSByZWFsbHkgd2FudCB0byB1c2UgYXRvbWljcyB0aGVyZS4gSnVz dCBuZWVkIHRvIGNsYXJpZnkgNjQgYml0DQpzdXBwb3J0IG9uIEFSTS4NCg0KPiA+ICAgfQ0KPiA+ ICAgDQo+ID4gICAvKg0KPiA+IGRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3N5c2N0bC5jIGIveGVu L2NvbW1vbi9zeXNjdGwuYw0KPiA+IGluZGV4IDFjNmE4MTc0NzYuLjAwNjgzYmM5M2YgMTAwNjQ0 DQo+ID4gLS0tIGEveGVuL2NvbW1vbi9zeXNjdGwuYw0KPiA+ICsrKyBiL3hlbi9jb21tb24vc3lz Y3RsLmMNCj4gPiBAQCAtMjcwLDYgKzI3MCw3IEBAIGxvbmcgZG9fc3lzY3RsKFhFTl9HVUVTVF9I QU5ETEVfUEFSQU0oeGVuX3N5c2N0bF90KSB1X3N5c2N0bCkNCj4gPiAgICAgICAgICAgcGktPnNj cnViX3BhZ2VzID0gMDsNCj4gPiAgICAgICAgICAgcGktPmNwdV9raHogPSBjcHVfa2h6Ow0KPiA+ ICAgICAgICAgICBwaS0+bWF4X21mbiA9IGdldF91cHBlcl9tZm5fYm91bmQoKTsNCj4gPiArICAg ICAgICBzY2hlZF9nZXRfdGltZV9zdGF0cygmcGktPmlycV90aW1lLCAmcGktPmh5cF90aW1lKTsN Cj4gPiAgICAgICAgICAgYXJjaF9kb19waHlzaW5mbyhwaSk7DQo+ID4gICAgICAgICAgIGlmICgg aW9tbXVfZW5hYmxlZCApDQo+ID4gICAgICAgICAgIHsNCj4gPiBkaWZmIC0tZ2l0IGEveGVuL2lu Y2x1ZGUvcHVibGljL3N5c2N0bC5oIGIveGVuL2luY2x1ZGUvcHVibGljL3N5c2N0bC5oDQo+ID4g aW5kZXggM2EwOGM1MTJlOC4uZjMyMDE0NGQ0MCAxMDA2NDQNCj4gPiAtLS0gYS94ZW4vaW5jbHVk ZS9wdWJsaWMvc3lzY3RsLmgNCj4gPiArKysgYi94ZW4vaW5jbHVkZS9wdWJsaWMvc3lzY3RsLmgN Cj4gPiBAQCAtMzUsNyArMzUsNyBAQA0KPiA+ICAgI2luY2x1ZGUgImRvbWN0bC5oIg0KPiA+ICAg I2luY2x1ZGUgInBoeXNkZXYuaCINCj4gPiAgIA0KPiA+IC0jZGVmaW5lIFhFTl9TWVNDVExfSU5U RVJGQUNFX1ZFUlNJT04gMHgwMDAwMDAxMw0KPiA+ICsjZGVmaW5lIFhFTl9TWVNDVExfSU5URVJG QUNFX1ZFUlNJT04gMHgwMDAwMDAxNA0KPiA+ICAgDQo+ID4gICAvKg0KPiA+ICAgICogUmVhZCBj b25zb2xlIGNvbnRlbnQgZnJvbSBYZW4gYnVmZmVyIHJpbmcuDQo+ID4gQEAgLTExOCw2ICsxMTgs OCBAQCBzdHJ1Y3QgeGVuX3N5c2N0bF9waHlzaW5mbyB7DQo+ID4gICAgICAgdWludDY0X2FsaWdu ZWRfdCBzY3J1Yl9wYWdlczsNCj4gPiAgICAgICB1aW50NjRfYWxpZ25lZF90IG91dHN0YW5kaW5n X3BhZ2VzOw0KPiA+ICAgICAgIHVpbnQ2NF9hbGlnbmVkX3QgbWF4X21mbjsgLyogTGFyZ2VzdCBw b3NzaWJsZSBNRk4gb24gdGhpcyBob3N0ICovDQo+ID4gKyAgICB1aW50NjRfYWxpZ25lZF90IGly cV90aW1lOw0KPiA+ICsgICAgdWludDY0X2FsaWduZWRfdCBoeXBfdGltZTsNCj4gDQo+IFdvdWxk IGh5cGZzIHdvcmssIHRvbz8gVGhpcyB3b3VsZCBhdm9pZCB0aGUgbmVlZCBmb3IgZXh0ZW5kaW5n IGFub3RoZXINCj4gaHlwZXJjYWxsLg0KDQpHb29kIHBvaW50LiBJJ2xsIHRha2UgYSBsb29rIGF0 IHRoaXMgZnJvbSB0b29sc3RhY2sgc2lkZS4gSSBkaWRuJ3Qgc2VlDQphbnkgaHlwZnMgY2FsbHMg aW4gdGhlIHhlbnRvcC4gQnV0IHRoaXMgaXMgYSBnb29kIHRpbWUgdG8gYmVnaW4gdXNpbmcNCml0 Lg0K From xen-devel-bounces@lists.xenproject.org Fri Jun 12 11:59:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 11:59:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiKx-0001yJ-Cz; Fri, 12 Jun 2020 11:59:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiKv-0001yE-Tk for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 11:59:05 +0000 X-Inumbo-ID: 1cdf0c9c-aca4-11ea-b7bb-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1cdf0c9c-aca4-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 11:59:05 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: zidYHVXBfNDD4xFyXnV9hDXUTyeqAFkTwjc4nqf3H8qd+GvAa1eLSm+BOPcLfRMrK0rBN/zOQy 4NESGKO2UfRla7ORtdJ/1VCl4ul3UGL3/lYt3es2oqDzolv7W3YMdOro/Xmjs9vYH4m5fwtUxG zg729RRLXHek+zsM3FpCjCWtGG5SjC3chFh70XU+qDVqQ92y9UTvJdz67LZhdR+xgiOi/N0W8p qggoE6morBeehuvrkiXZaGh6OyVEQY2iuA5k1S+BinyQcjkTiJaU8LQlB6PALj9bGo/oBz+5WF mQw= X-SBRS: 2.7 X-MesageID: 19911771 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="19911771" From: George Dunlap To: Andrew Cooper Subject: Re: golang bindings dirty in tree after libxl build Thread-Topic: golang bindings dirty in tree after libxl build Thread-Index: AQHWQKioQYeQbI0+WE2BPJ46VizvQajUvuCA Date: Fri, 12 Jun 2020 11:59:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , "rosbrookn@gmail.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gSnVuIDEyLCAyMDIwLCBhdCAxMjowMCBQTSwgQW5kcmV3IENvb3BlciA8QW5kcmV3 LkNvb3BlcjNAY2l0cml4LmNvbT4gd3JvdGU6DQo+IA0KPiBIZWxsbywNCj4gDQo+IEkndmUganVz dCBkb25lIGEgbGlieGwgYnVpbGQgYW5kIGdvdCB0aGluZ3Mgc3VjaCBhczoNCj4gDQo+IC0tLSBh L3Rvb2xzL2dvbGFuZy94ZW5saWdodC9oZWxwZXJzLmdlbi5nbw0KPiArKysgYi90b29scy9nb2xh bmcveGVubGlnaHQvaGVscGVycy5nZW4uZ28NCj4gQEAgLTQzMSwxNCArNDMxLDE0IEBAIHguRXZ0 Y2ggPSBpbnQoeGMuZXZ0Y2gpDQo+ICB4LlJyZWYgPSBpbnQoeGMucnJlZikNCj4gIHguQ29ubmVj dGlvbiA9IENoYW5uZWxDb25uZWN0aW9uKHhjLmNvbm5lY3Rpb24pDQo+ICBzd2l0Y2ggeC5Db25u ZWN0aW9uew0KPiAtY2FzZSBDaGFubmVsQ29ubmVjdGlvblVua25vd246DQo+IC14LkNvbm5lY3Rp b25VbmlvbiA9IG5pbA0KPiAgY2FzZSBDaGFubmVsQ29ubmVjdGlvblB0eToNCj4gIHZhciBjb25u ZWN0aW9uUHR5IENoYW5uZWxpbmZvQ29ubmVjdGlvblVuaW9uUHR5DQo+ICBpZiBlcnIgOj0gY29u bmVjdGlvblB0eS5mcm9tQyh4Yyk7ZXJyICE9IG5pbCB7DQo+ICAgcmV0dXJuIGZtdC5FcnJvcmYo ImNvbnZlcnRpbmcgZmllbGQgY29ubmVjdGlvblB0eTogJXYiLCBlcnIpDQo+ICB9DQo+ICB4LkNv bm5lY3Rpb25VbmlvbiA9IGNvbm5lY3Rpb25QdHkNCj4gK2Nhc2UgQ2hhbm5lbENvbm5lY3Rpb25V bmtub3duOg0KPiAreC5Db25uZWN0aW9uVW5pb24gPSBuaWwNCj4gIGNhc2UgQ2hhbm5lbENvbm5l Y3Rpb25Tb2NrZXQ6DQo+ICB4LkNvbm5lY3Rpb25VbmlvbiA9IG5pbA0KPiAgZGVmYXVsdDoNCj4g DQo+IGRpcnR5IGluIHRyZWUuICBUaGV5IGFyZSBhbGwgY2FzZSBsYWJlbHMsIGFuZCBvbmx5IHRo ZWlyIG9yZGVyIGluIHRoZQ0KPiBzd2l0Y2ggaGFzIGNoYW5nZWQuDQo+IA0KPiBEb2VzIHRoZSBj dXJyZW50IGJpbmRpbmcgZ2VuZXJhdGlvbiByZWx5IG9uIHRoZSBvcmRlciBvZiBlbnRyaWVzIGlu IGENCj4gcHl0aG9uIGRpY3Rpb25hcnkgYnkgYW55IGNoYW5jZT8NCg0KTm90IGV4cGxpY2l0bHks IGJ1dCBvYnZpb3VzbHkgc29tZXdoYXQgaW1wbGljaXRseS4NCg0KSXMgdGhpcyBhIHB5dGhvbjIv MyBpc3N1ZSwgb3Igd291bGQgZGlmZmVyZW50IHZlcnNpb25zIG9mIHB5dGhvbiB3aXRoaW4gMi8z IGVuZCB1cCB3aXRoIGRpZmZlcmVudCBzb3J0IG9yZGVycz8NCg0KSWYgcHl0aG9uMyB3aWxsIGFs d2F5cyBwdXQgdGhlbSBpbiB0aGUgc2FtZSBvcmRlciwgdGhlbiB3ZSBtaWdodCBjb25zaWRlciBq dXN0IHN3aXRjaGluZyB0aGUgc2NyaXB0IHRvIGJlaW5nIGV4cGxpY2l0bHkgcHl0aG9uMy4gIE90 aGVyd2lzZSwgd2XigJlsbCBwcm9iYWJseSBoYXZlIHRvIGFkZCBzb3J0cy4NCg0KIC1HZW9yZ2UN Cg0K From xen-devel-bounces@lists.xenproject.org Fri Jun 12 12:15:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 12:15:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiaM-0003fQ-5B; Fri, 12 Jun 2020 12:15:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiaK-0003fL-Gy for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 12:15:00 +0000 X-Inumbo-ID: 5639caca-aca6-11ea-b5be-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5639caca-aca6-11ea-b5be-12813bfff9fa; Fri, 12 Jun 2020 12:15:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=JsXxqUF/QPhgsow/SIQLFdeZsE3FOY3Yzo/7lnvuEK0=; b=D6+AG0ZkAIQIsSa1haHkoRclBE sIAMifvbOsCG+LITssSJo17m1G9X9FQTBFSa7aWJqM6OKFahzrxAlIJe0FbiwJ96T0HubVKJgeGvX MYPMOZejc7YtbJIp7Q7wUGP4twAUFd2qOSP1K5dgBM+6oL4LTnoOiMoY6M6SpbkKpQhU=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiaI-0000SV-Oh; Fri, 12 Jun 2020 12:14:58 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjiaI-00051v-DY; Fri, 12 Jun 2020 12:14:58 +0000 Subject: Re: [PATCH 2/2] xen/arm: Support runstate crossing pages To: Bertrand Marquis , xen-devel@lists.xenproject.org References: From: Julien Grall Message-ID: <0ea51410-050b-58a6-806a-b175f534852f@xen.org> Date: Fri, 12 Jun 2020 13:14:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: nd@arm.com, Volodymyr Babchuk , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 11/06/2020 12:58, Bertrand Marquis wrote: > Add support for runstate area register with the structure crossing pages Well, this has always been supported until your previous patch. In general, we try to not break thing in a middle of the series so we can still bisect it. I think this patch can be simplified a lot by mapping the two page contiguously (see my previous answer). With that it would be feasible to fold this patch in #1. > The code is storing up to 2 pages reference during the hypercall. > During a context switch, the code is computing where the > state_entry_time is and is breaking the memcpy in 2 parts when it is > required. > > Signed-off-by: Bertrand Marquis > --- > xen/arch/arm/domain.c | 101 +++++++++++++++++++++++++---------- > xen/include/asm-arm/domain.h | 5 +- > 2 files changed, 76 insertions(+), 30 deletions(-) > > diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c > index 739059234f..d847cb00f2 100644 > --- a/xen/arch/arm/domain.c > +++ b/xen/arch/arm/domain.c > @@ -280,11 +280,16 @@ void arch_cleanup_runstate_guest(struct vcpu *v) > { > spin_lock(&v->arch.runstate_guest.lock); > > - /* cleanup previous page if any */ > - if ( v->arch.runstate_guest.page ) > + /* cleanup previous pages if any */ > + if ( v->arch.runstate_guest.page[0] ) > { > - put_page_and_type(v->arch.runstate_guest.page); > - v->arch.runstate_guest.page = NULL; > + put_page_and_type(v->arch.runstate_guest.page[0]); > + v->arch.runstate_guest.page[0] = NULL; > + if ( v->arch.runstate_guest.page[1] ) > + { > + put_page_and_type(v->arch.runstate_guest.page[1]); > + v->arch.runstate_guest.page[1] = NULL; > + } I think this can be moved outside of the first if. > v->arch.runstate_guest.offset = 0; > } > > @@ -294,26 +299,25 @@ void arch_cleanup_runstate_guest(struct vcpu *v) > int arch_setup_runstate_guest(struct vcpu *v, > struct vcpu_register_runstate_memory_area area) > { > - struct page_info *page; > + struct page_info *page[2] = {NULL,NULL}; I don't think you need the temporary variable. You can directly update page[0] as it is protected by the lock. The nice benefits is you could take advantage of a common helper to cleanup and reduce the complexity of the code. > unsigned offset; > > spin_lock(&v->arch.runstate_guest.lock); > > - /* cleanup previous page if any */ > - if ( v->arch.runstate_guest.page ) > + /* cleanup previous pages if any */ > + if ( v->arch.runstate_guest.page[0] ) > { > - put_page_and_type(v->arch.runstate_guest.page); > - v->arch.runstate_guest.page = NULL; > + put_page_and_type(v->arch.runstate_guest.page[0]); > + v->arch.runstate_guest.page[0] = NULL; > + if ( v->arch.runstate_guest.page[1] ) > + { > + put_page_and_type(v->arch.runstate_guest.page[1]); > + v->arch.runstate_guest.page[1] = NULL; > + } > v->arch.runstate_guest.offset = 0; > } > > offset = ((vaddr_t)area.addr.v) & ~PAGE_MASK; > - if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) > - { > - spin_unlock(&v->arch.runstate_guest.lock); > - gprintk(XENLOG_DEBUG, "Runstate is crossing pages\n"); > - return -EINVAL; > - } > > /* provided address must be aligned to a 64bit */ > if ( offset % alignof(struct vcpu_runstate_info) ) > @@ -323,15 +327,30 @@ int arch_setup_runstate_guest(struct vcpu *v, > return -EINVAL; > } > > - page = get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); > - if ( !page ) > + page[0] = get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); > + if ( !page[0] ) > { > spin_unlock(&v->arch.runstate_guest.lock); > gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); > return -EINVAL; > } > > - v->arch.runstate_guest.page = page; > + if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) > + { > + /* guest area is crossing pages */ > + page[1] = get_page_from_gva(v, (vaddr_t)area.addr.v + PAGE_SIZE, > + GV2M_WRITE); > + if ( !page[1] ) > + { > + put_page_and_type(v->arch.runstate_guest.page[0]); v->arch.runstate_guest.page[0] would be NULL as you set it afterwards. So you want to set v->arch.runstate_guest.page[0] beforehand. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 12:16:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 12:16:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjibJ-0003j5-Fu; Fri, 12 Jun 2020 12:16:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjibJ-0003if-2T for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 12:16:01 +0000 X-Inumbo-ID: 78881cda-aca6-11ea-bca7-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 78881cda-aca6-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 12:15:58 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: NKcKlwxWljgx+R7dtt4YKZaLPoc8WwgO0grQBfms08EHwOvRVo/Re1r/aeWKE1Lp6SMmGWjTsk rz3i0PvaauRETPH7fV/gT2gmP90EqzVIJtJ6MJP+rQbw1SwTuNdOXW0wgHdEPD2fpgJLG7tcxX asq7VXhpNxaN4OT/6wZa/bcTob/zvf+amuLYBWKNrpfHVS0ffQk2Dap7dWznIwQyyztKzwQFY+ 8jL8sQYvLK9yam0gNtfNpx9Y7ul/aJX/rIt0/0TiP5EIqr6RcBEszuwnFYry8Kc53ht9sSdPkK yqU= X-SBRS: 2.7 X-MesageID: 19898299 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="19898299" Subject: Re: golang bindings dirty in tree after libxl build To: George Dunlap References: From: Andrew Cooper Message-ID: <1b412370-3a8f-59af-f7cf-042ae45ea802@citrix.com> Date: Fri, 12 Jun 2020 13:15:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , "rosbrookn@gmail.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 12:59, George Dunlap wrote: > >> On Jun 12, 2020, at 12:00 PM, Andrew Cooper wrote: >> >> Hello, >> >> I've just done a libxl build and got things such as: >> >> --- a/tools/golang/xenlight/helpers.gen.go >> +++ b/tools/golang/xenlight/helpers.gen.go >> @@ -431,14 +431,14 @@ x.Evtch = int(xc.evtch) >> x.Rref = int(xc.rref) >> x.Connection = ChannelConnection(xc.connection) >> switch x.Connection{ >> -case ChannelConnectionUnknown: >> -x.ConnectionUnion = nil >> case ChannelConnectionPty: >> var connectionPty ChannelinfoConnectionUnionPty >> if err := connectionPty.fromC(xc);err != nil { >> return fmt.Errorf("converting field connectionPty: %v", err) >> } >> x.ConnectionUnion = connectionPty >> +case ChannelConnectionUnknown: >> +x.ConnectionUnion = nil >> case ChannelConnectionSocket: >> x.ConnectionUnion = nil >> default: >> >> dirty in tree. They are all case labels, and only their order in the >> switch has changed. >> >> Does the current binding generation rely on the order of entries in a >> python dictionary by any chance? > Not explicitly, but obviously somewhat implicitly. > > Is this a python2/3 issue, or would different versions of python within 2/3 end up with different sort orders? > > If python3 will always put them in the same order, then we might consider just switching the script to being explicitly python3. Otherwise, we’ll probably have to add sorts. Python 3.6 now guarantees that the insert order of elements will be preserved.  Before that, there are no guarantees at all. It sounds like some sprinkling of sorted() will be needed. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 12 12:21:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 12:21:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjigr-0004Zh-51; Fri, 12 Jun 2020 12:21:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjigq-0004Zc-59 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 12:21:44 +0000 X-Inumbo-ID: 46854587-aca7-11ea-b5be-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 46854587-aca7-11ea-b5be-12813bfff9fa; Fri, 12 Jun 2020 12:21:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=toQe+tuZIiIC8FXgujSBHCJULHVlIGSzmBSHZPnrO88=; b=W62slnpG9vX/LSPkZu1EU8AgNn VUCTelz+sjWjMP2uKx3AKi9z8pZtqm4tUQTdYZee/SbnX5mPm+BUyHnn3MKNh0efr8YKNYJRMH+zD eMojKEO5ayLyFsLg4wQ3H/0ngRJgHNfo7VaLwY/0REuCQNWvFtR8rAFfGX0urCE0tYCc=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjign-0000b7-Al; Fri, 12 Jun 2020 12:21:41 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjign-0005Hw-0L; Fri, 12 Jun 2020 12:21:41 +0000 Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler To: Volodymyr Babchuk , "jgross@suse.com" , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> <7ec7b6568afb3df41f8407015c198b1ccb341c5b.camel@epam.com> <5bd54018f5e045816d25f686124395a1f27a2122.camel@epam.com> From: Julien Grall Message-ID: <51fce146-f2bd-6098-bef9-2fd925ec7f96@xen.org> Date: Fri, 12 Jun 2020 13:21:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <5bd54018f5e045816d25f686124395a1f27a2122.camel@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 12:33, Volodymyr Babchuk wrote: > > On Fri, 2020-06-12 at 12:29 +0100, Julien Grall wrote: >> >> On 12/06/2020 12:26, Volodymyr Babchuk wrote: >>> Hi Jurgen, >>> >>> thanks for the review >>> >>> On Fri, 2020-06-12 at 06:36 +0200, Jürgen Groß wrote: >>> >>>> On 12.06.20 02:22, Volodymyr Babchuk wrote: >>> >>> [...] >>> >>>>> +void vcpu_end_irq_handler(void) >>>>> +{ >>>>> + int delta; >>>>> + >>>>> + if (is_idle_vcpu(current)) >>>>> + return; >>>>> + >>>>> + ASSERT(current->irq_nesting); >>>>> + >>>>> + if ( --current->irq_nesting ) >>>>> + return; >>>>> + >>>>> + /* We assume that irq handling time will not overflow int */ >>>> >>>> This assumption might not hold for long running VMs. >>> >>> Basically, this value holds time span between calls to schedule(). This >>> variable gets zeroed out every time scheduler requests for time >>> adjustment value. So, it should not depend on total VM run time. >> This is assuming that the scheduler will be called. With the NULL >> scheduler in place, there is a fair chance this may never be called. >> >> So I think using a 64-bit value is likely safer. > > Well, I wanted to use 64-bit value in the first place. But I got the > impression that atomic_t supports only 32-bit values. At least, this is > what I'm seeing in atomic.h > > Am I wrong? There is no atomic64_t support in Xen yet. It shouldn't be very difficult to add support for it if you require them. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 12:23:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 12:23:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiic-0004gs-Gr; Fri, 12 Jun 2020 12:23:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiia-0004gl-Uw for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 12:23:33 +0000 X-Inumbo-ID: 84c6e82c-aca7-11ea-b5be-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 84c6e82c-aca7-11ea-b5be-12813bfff9fa; Fri, 12 Jun 2020 12:23:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pgTz27+m3bB5CHzQvEtnNVwOgUo6MtqkT4fEkHeHSiM=; b=Ofk1fWBQ90B74mzmuk6yobFKr NuAxTA5FN+TJDxUWXZiB/pBxp6Oa1MUxiQIyWuBhkLul88I8OiToCweTJpGpqGcriE7Abl1JbBrZE LobtiMsmgKD8/8p9XoOaOfvy7ScneU1wc2AmGezSlNje5VSZGczYMN7ZSm/PoPqOFgTcE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiiU-0000dL-V1; Fri, 12 Jun 2020 12:23:27 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjiiU-00049I-MD; Fri, 12 Jun 2020 12:23:26 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjiiU-0006Nd-LV; Fri, 12 Jun 2020 12:23:26 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151035: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=9be79927a6395f12c9e24afaccf6acbaf81d402e X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Fri, 12 Jun 2020 12:23:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151035 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151035/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 9be79927a6395f12c9e24afaccf6acbaf81d402e baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 37 days Failing since 150942 2020-06-09 17:05:43 Z 2 days 5 attempts Testing same since 151035 2020-06-11 02:26:19 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Fri Jun 12 12:30:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 12:30:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiov-0005KX-Ba; Fri, 12 Jun 2020 12:30:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiot-000543-8O for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 12:30:03 +0000 X-Inumbo-ID: 6fb24d5e-aca8-11ea-b5be-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6fb24d5e-aca8-11ea-b5be-12813bfff9fa; Fri, 12 Jun 2020 12:30:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/fyXVoVU+GEeVQXGvIUqOi7Pax1xh9GFWo+hCIkKMCQ=; b=KkdgTzOZDUpXvz0rJa0zzmXkfs sBuoe35EWPeR/jxviAWo1XqZHSnREAGKuhI5ntqUPO4Z2BmVAXX206l2xKF2zbYfqbr4dLw1RQAtC XCKF8W+8i60Ft9JTRodwNY7vcOAOBW/EebL08MGkAyh2LQAxbDCsae7cJwsGRqYC/ow4=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjiop-0000kd-C0; Fri, 12 Jun 2020 12:29:59 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjiop-0005iG-4V; Fri, 12 Jun 2020 12:29:59 +0000 Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> From: Julien Grall Message-ID: <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> Date: Fri, 12 Jun 2020 13:29:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Juergen, On 12/06/2020 05:57, Jürgen Groß wrote: > On 12.06.20 02:22, Volodymyr Babchuk wrote: >> As scheduler code now collects time spent in IRQ handlers and in >> do_softirq(), we can present those values to userspace tools like >> xentop, so system administrator can see how system behaves. >> >> We are updating counters only in sched_get_time_correction() function >> to minimize number of taken spinlocks. As atomic_t is 32 bit wide, it >> is not enough to store time with nanosecond precision. So we need to >> use 64 bit variables and protect them with spinlock. >> >> Signed-off-by: Volodymyr Babchuk >> --- >>   xen/common/sched/core.c     | 17 +++++++++++++++++ >>   xen/common/sysctl.c         |  1 + >>   xen/include/public/sysctl.h |  4 +++- >>   xen/include/xen/sched.h     |  2 ++ >>   4 files changed, 23 insertions(+), 1 deletion(-) >> >> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c >> index a7294ff5c3..ee6b1d9161 100644 >> --- a/xen/common/sched/core.c >> +++ b/xen/common/sched/core.c >> @@ -95,6 +95,10 @@ static struct scheduler __read_mostly ops; >>   static bool scheduler_active; >> +static DEFINE_SPINLOCK(sched_stat_lock); >> +s_time_t sched_stat_irq_time; >> +s_time_t sched_stat_hyp_time; >> + >>   static void sched_set_affinity( >>       struct sched_unit *unit, const cpumask_t *hard, const cpumask_t >> *soft); >> @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct >> sched_unit *u) >>               break; >>       } >> +    spin_lock_irqsave(&sched_stat_lock, flags); >> +    sched_stat_irq_time += irq; >> +    sched_stat_hyp_time += hyp; >> +    spin_unlock_irqrestore(&sched_stat_lock, flags); > > Please don't use a lock. Just use add_sized() instead which will add > atomically. add_sized() is definitely not atomic. It will only prevent the compiler to read/write multiple time the variable. If we expect sched_get_time_correction to be called concurrently then we would need to introduce atomic64_t or a spin lock. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 12:41:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 12:41:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjj0B-0006RP-Ci; Fri, 12 Jun 2020 12:41:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjj0A-0006RK-Ar for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 12:41:42 +0000 X-Inumbo-ID: 107212dc-acaa-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 107212dc-acaa-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 12:41:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AB4F2AC91; Fri, 12 Jun 2020 12:41:43 +0000 (UTC) Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: Julien Grall , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Fri, 12 Jun 2020 14:41:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.20 14:29, Julien Grall wrote: > Hi Juergen, > > On 12/06/2020 05:57, Jürgen Groß wrote: >> On 12.06.20 02:22, Volodymyr Babchuk wrote: >>> As scheduler code now collects time spent in IRQ handlers and in >>> do_softirq(), we can present those values to userspace tools like >>> xentop, so system administrator can see how system behaves. >>> >>> We are updating counters only in sched_get_time_correction() function >>> to minimize number of taken spinlocks. As atomic_t is 32 bit wide, it >>> is not enough to store time with nanosecond precision. So we need to >>> use 64 bit variables and protect them with spinlock. >>> >>> Signed-off-by: Volodymyr Babchuk >>> --- >>>   xen/common/sched/core.c     | 17 +++++++++++++++++ >>>   xen/common/sysctl.c         |  1 + >>>   xen/include/public/sysctl.h |  4 +++- >>>   xen/include/xen/sched.h     |  2 ++ >>>   4 files changed, 23 insertions(+), 1 deletion(-) >>> >>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c >>> index a7294ff5c3..ee6b1d9161 100644 >>> --- a/xen/common/sched/core.c >>> +++ b/xen/common/sched/core.c >>> @@ -95,6 +95,10 @@ static struct scheduler __read_mostly ops; >>>   static bool scheduler_active; >>> +static DEFINE_SPINLOCK(sched_stat_lock); >>> +s_time_t sched_stat_irq_time; >>> +s_time_t sched_stat_hyp_time; >>> + >>>   static void sched_set_affinity( >>>       struct sched_unit *unit, const cpumask_t *hard, const cpumask_t >>> *soft); >>> @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct >>> sched_unit *u) >>>               break; >>>       } >>> +    spin_lock_irqsave(&sched_stat_lock, flags); >>> +    sched_stat_irq_time += irq; >>> +    sched_stat_hyp_time += hyp; >>> +    spin_unlock_irqrestore(&sched_stat_lock, flags); >> >> Please don't use a lock. Just use add_sized() instead which will add >> atomically. > > add_sized() is definitely not atomic. It will only prevent the compiler > to read/write multiple time the variable. Oh, my bad, I let myself fool by it being defined in atomic.h. > > If we expect sched_get_time_correction to be called concurrently then we > would need to introduce atomic64_t or a spin lock. Or we could use percpu variables and add the cpu values up when fetching the values. Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 12 12:45:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 12:45:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjj3g-0006ad-Sm; Fri, 12 Jun 2020 12:45:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjj3f-0006aY-Bq for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 12:45:19 +0000 X-Inumbo-ID: 920bf240-acaa-11ea-b5c2-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 920bf240-acaa-11ea-b5c2-12813bfff9fa; Fri, 12 Jun 2020 12:45:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Vf6RO9DnxhGqSJUdZRusZQultkSQT/emTqL8Ehivgso=; b=UtQyt1++BjOY+3/pDvIKGTF+W8 kX2qlHavYCgIZkpUOgg4tDhXQ+ZhInR40YyZ3oGCJm0C6eQFq3+m9tcI9qz9oGAdeOuhOPyOpNDLi AQFrSLqIC0s6UYuRcLL6S9+Yv4T/yDaq6rWBBnk5zSoeBsc+1+fk91rNke88mTlHJZmU=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjj3b-00012X-WD; Fri, 12 Jun 2020 12:45:16 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjj3b-0006dJ-PR; Fri, 12 Jun 2020 12:45:15 +0000 Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: Volodymyr Babchuk , "jgross@suse.com" , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <1fcd5d89691b775d1230bf3405e29893107edcb3.camel@epam.com> From: Julien Grall Message-ID: <92d81acb-fd78-3483-68fb-f52c7bfb3d65@xen.org> Date: Fri, 12 Jun 2020 13:45:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1fcd5d89691b775d1230bf3405e29893107edcb3.camel@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Volodymyr, On 12/06/2020 12:44, Volodymyr Babchuk wrote: > > On Fri, 2020-06-12 at 06:57 +0200, Jürgen Groß wrote: >> On 12.06.20 02:22, Volodymyr Babchuk wrote: >>> As scheduler code now collects time spent in IRQ handlers and in >>> do_softirq(), we can present those values to userspace tools like >>> xentop, so system administrator can see how system behaves. >>> >>> We are updating counters only in sched_get_time_correction() function >>> to minimize number of taken spinlocks. As atomic_t is 32 bit wide, it >>> is not enough to store time with nanosecond precision. So we need to >>> use 64 bit variables and protect them with spinlock. >>> >>> Signed-off-by: Volodymyr Babchuk >>> --- >>> xen/common/sched/core.c | 17 +++++++++++++++++ >>> xen/common/sysctl.c | 1 + >>> xen/include/public/sysctl.h | 4 +++- >>> xen/include/xen/sched.h | 2 ++ >>> 4 files changed, 23 insertions(+), 1 deletion(-) >>> >>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c >>> index a7294ff5c3..ee6b1d9161 100644 >>> --- a/xen/common/sched/core.c >>> +++ b/xen/common/sched/core.c >>> @@ -95,6 +95,10 @@ static struct scheduler __read_mostly ops; >>> >>> static bool scheduler_active; >>> >>> +static DEFINE_SPINLOCK(sched_stat_lock); >>> +s_time_t sched_stat_irq_time; >>> +s_time_t sched_stat_hyp_time; >>> + >>> static void sched_set_affinity( >>> struct sched_unit *unit, const cpumask_t *hard, const cpumask_t *soft); >>> >>> @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct sched_unit *u) >>> break; >>> } >>> >>> + spin_lock_irqsave(&sched_stat_lock, flags); >>> + sched_stat_irq_time += irq; >>> + sched_stat_hyp_time += hyp; >>> + spin_unlock_irqrestore(&sched_stat_lock, flags); >> >> Please don't use a lock. Just use add_sized() instead which will add >> atomically. > > Looks like arm does not support 64 bit variables. > > Julien, I believe, this is armv7 limitation? Should armv8 work with 64- > bit atomics? 64-bit atomics can work on both Armv7 and Armv8 :). It just haven't been plumbed yet. I am happy to write a patch if you need atomic64_t or even a 64-bit add_sized(). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 12:48:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 12:48:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjj6w-0006jd-C9; Fri, 12 Jun 2020 12:48:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjj6v-0006jY-LN for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 12:48:41 +0000 X-Inumbo-ID: 0a9723e2-acab-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0a9723e2-acab-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 12:48:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=O6mxjme0RNWx0mNqF93mxzxEYdSjZk5aflawx67TyFA=; b=sfrTCgj+EgzpP6HXGBMF+HC1J yFcCCFZSUv5U54oqv6V3550axEfR+sJTE3OCDICEoSARdw5rNnZWwMXRM3NEDgiN8GfsWR+Gc4Qte L5l7/NPNisvSrYEbNmai1K7bMnEMBNzDjsE5NuC2lJLQ+53rN2SH6DU2n0CMpHPQe66V4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjj6u-00016P-9S; Fri, 12 Jun 2020 12:48:40 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjj6t-0005CG-Q5; Fri, 12 Jun 2020 12:48:40 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjj6t-0006Td-PV; Fri, 12 Jun 2020 12:48:39 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151040: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=0d009ca646a4e7438952f6d2739ab7f48ef533ab X-Osstest-Versions-That: libvirt=cfdceb9754bde5d161c21a65e621ef20c47f1eaf From: osstest service owner Date: Fri, 12 Jun 2020 12:48:39 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151040 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151040/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150997 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150997 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 0d009ca646a4e7438952f6d2739ab7f48ef533ab baseline version: libvirt cfdceb9754bde5d161c21a65e621ef20c47f1eaf Last test of basis 150997 2020-06-10 04:19:42 Z 2 days Testing same since 151040 2020-06-11 04:19:36 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Michal Privoznik jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git cfdceb9754..0d009ca646 0d009ca646a4e7438952f6d2739ab7f48ef533ab -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Fri Jun 12 13:38:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 13:38:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjjtC-0002N3-9X; Fri, 12 Jun 2020 13:38:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjjtA-0002My-G9 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 13:38:32 +0000 X-Inumbo-ID: 011ad50a-acb2-11ea-bb8b-bc764e2007e4 Received: from mail-lf1-x133.google.com (unknown [2a00:1450:4864:20::133]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 011ad50a-acb2-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 13:38:31 +0000 (UTC) Received: by mail-lf1-x133.google.com with SMTP id z206so5501479lfc.6 for ; Fri, 12 Jun 2020 06:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r2efMH73jQtkX8/ee00G2Vfh+yT5y4lHRLBewPYzKcA=; b=FzbknQUscr1Fie0172QOMeFZofGDSzabpi1X2vGSCJQACjc3KSrlySrBMJYjmdyIYS 5af/uNBRPt/KX8NSHMqaHBIfvoks6wECrSs7FGzNDXSCpwc43OMzcXWS8609rFaUXprP KY5bLaPq6hc5oinj3RB2vZx70zH1EaMsvq39B8NJ9vyrIUwWPUfNtBhZBx9L7mhyRuv7 fMvHNjDjGI4bILvvFHJ8N3OCRi03kf41mBYT1nXPSgqq7J6g5O2t/zfc2DosW/NTH+rt /6qipFQUEYVamTxNc327Dq8v0CHtx9JrIV9cpTsPXKp/RGJi1qId0jWSUDJgHFkYYDkG /qSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=r2efMH73jQtkX8/ee00G2Vfh+yT5y4lHRLBewPYzKcA=; b=KJIRdnLS8UKHx3zypdv7DnJ1yQuapEXGdAgnPQ4qjARGJKz3oSuBbXtNti5H7UTqxl cGef9i9J454GT/Qc28t4dLk5n3h8W7PykVnUjKXUzLyrfTV7NH9yDr4zyMifk81/2Lzq qYhvxRvMJVrZIqNQBaQlZuSE42pBgzsNeQKT6GBbLNhPFWmhJDo8mjqR4lGftoWIINpy BDXW7iHklhUfnnz5yZRc9mN6iHDAt6VFn9gsb9JEMDFk2oNPd6bi9gWRWJpnPXW7Wd5F 0899kn6FN7Zm4BjZBK7gS5M769dDreHvJ5YnFDII0vmGeSKpQaBmjjGxsl2Lh/bjXfYA gnlA== X-Gm-Message-State: AOAM5322SVGRJ1TQ6ps2s+ypvgHBRrVMGNGfuEPLPAvi9k5WjW1CrTq+ AILhMu0CYKPnJqrGCfvqIpOiZDMSni2jduLWbgXugjeH X-Google-Smtp-Source: ABdhPJw3OreDDptJODf2oFgkx9Q0yHNSKaNPoKU72I0QThneXvrmNOGTh3k5tQCVqFqSxHU7G0LH116RMaZCMbfHWSk= X-Received: by 2002:a05:6512:62:: with SMTP id i2mr6846563lfo.152.1591969110569; Fri, 12 Jun 2020 06:38:30 -0700 (PDT) MIME-Version: 1.0 References: <1b412370-3a8f-59af-f7cf-042ae45ea802@citrix.com> In-Reply-To: <1b412370-3a8f-59af-f7cf-042ae45ea802@citrix.com> From: Nick Rosbrook Date: Fri, 12 Jun 2020 09:38:18 -0400 Message-ID: Subject: Re: golang bindings dirty in tree after libxl build To: Andrew Cooper Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 12, 2020 at 8:15 AM Andrew Cooper w= rote: > > On 12/06/2020 12:59, George Dunlap wrote: > > > >> On Jun 12, 2020, at 12:00 PM, Andrew Cooper wrote: > >> > >> Hello, > >> > >> I've just done a libxl build and got things such as: > >> > >> --- a/tools/golang/xenlight/helpers.gen.go > >> +++ b/tools/golang/xenlight/helpers.gen.go > >> @@ -431,14 +431,14 @@ x.Evtch =3D int(xc.evtch) > >> x.Rref =3D int(xc.rref) > >> x.Connection =3D ChannelConnection(xc.connection) > >> switch x.Connection{ > >> -case ChannelConnectionUnknown: > >> -x.ConnectionUnion =3D nil > >> case ChannelConnectionPty: > >> var connectionPty ChannelinfoConnectionUnionPty > >> if err :=3D connectionPty.fromC(xc);err !=3D nil { > >> return fmt.Errorf("converting field connectionPty: %v", err) > >> } > >> x.ConnectionUnion =3D connectionPty > >> +case ChannelConnectionUnknown: > >> +x.ConnectionUnion =3D nil > >> case ChannelConnectionSocket: > >> x.ConnectionUnion =3D nil > >> default: > >> > >> dirty in tree. They are all case labels, and only their order in the > >> switch has changed. > >> > >> Does the current binding generation rely on the order of entries in a > >> python dictionary by any chance? > > Not explicitly, but obviously somewhat implicitly. > > > > Is this a python2/3 issue, or would different versions of python within= 2/3 end up with different sort orders? > > > > If python3 will always put them in the same order, then we might consid= er just switching the script to being explicitly python3. Otherwise, we=E2= =80=99ll probably have to add sorts. > > Python 3.6 now guarantees that the insert order of elements will be > preserved. Before that, there are no guarantees at all. > > It sounds like some sprinkling of sorted() will be needed. George, Unless you have a burning desire, I can take care of this patch today or tomorrow. -NR From xen-devel-bounces@lists.xenproject.org Fri Jun 12 14:12:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 14:12:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjkPs-0005dx-5Y; Fri, 12 Jun 2020 14:12:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjkPq-0005ds-UE for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 14:12:18 +0000 X-Inumbo-ID: b90e57b4-acb6-11ea-b5d4-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b90e57b4-acb6-11ea-b5d4-12813bfff9fa; Fri, 12 Jun 2020 14:12:18 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: HuiODcQvIs84RzWq+XzbI4P0f9gcZjjP2aOhlN4/CUkS4m5l0uJvjxbB2WW6YMhFTlcrDltPMQ zwwmg7/PbAACcr1PvqzBdBynTmC68BdJIoeDsiMaw+kKlg3F1Uycsk31H0HxZKwqMGFaFOUXrq gCJX8poqBk94G0PA5oHi0SF6f0bTyCtIUz8OlY4PHxOJqQiX39TAAfvmKUF9301UTcMsfbaX/5 MwBjgD/LnyOvOXiKeXIw9zW7gQ4+hhPdr8zcpLxoUBoMGsWDqzXKTIWytrCVZgUj3bYQs6XT5Q iAc= X-SBRS: 2.7 X-MesageID: 20147663 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20147663" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <24291.36156.961284.809662@mariner.uk.xensource.com> Date: Fri, 12 Jun 2020 15:12:12 +0100 To: Andrew Cooper Subject: Re: libxl dirty in tree after libxl build In-Reply-To: <439f3d92-2e18-1868-2b4b-2747973fbe3b@citrix.com> References: <439f3d92-2e18-1868-2b4b-2747973fbe3b@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("libxl dirty in tree after libxl build"): > A build of libxl has just dirtied the tree with: > > index 05f7ac74a0..94a4438666 100644 > --- a/tools/libxl/libxlu_disk_l.c > +++ b/tools/libxl/libxlu_disk_l.c > @@ -10,221 +10,11 @@ > #define FLEX_SCANNER > #define YY_FLEX_MAJOR_VERSION 2 > #define YY_FLEX_MINOR_VERSION 6 > -#define YY_FLEX_SUBMINOR_VERSION 4 > +#define YY_FLEX_SUBMINOR_VERSION 1 > #if YY_FLEX_SUBMINOR_VERSION > 0 > #define FLEX_BETA > #endif > > and a whole slew of other changes in the generated code. It looks like > the version of Flex has just been updated in Jessie. > > Given the flex and bison are strictly required for the libxl build, why > is this temporary file checked in? The point of the exercise is to *not* require them. The reason is that some of our developers have very old development systems which do not support essential flex/bison features. How about we update them to the version from buster ? Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 14:13:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 14:13:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjkR7-0005jD-Gp; Fri, 12 Jun 2020 14:13:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjkR6-0005j7-8h for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 14:13:36 +0000 X-Inumbo-ID: e6b0c968-acb6-11ea-bb8b-bc764e2007e4 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe05::61e]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e6b0c968-acb6-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 14:13:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UvA2vYDVQ5KMS1BQJ+/F12lF7TBR7At6rvaxQ6p5PS4=; b=8agTz/xi8mL64fdo5g6LlkqjVqOIq/WX/FMA4hKO3s0ohc3bQq4eI/cXCjKkefYyYLElKsEGAP5auCKnSnl9j7mIVmlZNnZaa291yrhBmbDcGD+JMy1Kv4yDam1WqGRVnZaCD8ijbbeIzJsBMRUmNJfBnqtCi0eVKK+jMkU0ut8= Received: from AM6PR04CA0008.eurprd04.prod.outlook.com (2603:10a6:20b:92::21) by DB7PR08MB3674.eurprd08.prod.outlook.com (2603:10a6:10:4a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Fri, 12 Jun 2020 14:13:31 +0000 Received: from AM5EUR03FT053.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:92:cafe::c3) by AM6PR04CA0008.outlook.office365.com (2603:10a6:20b:92::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 14:13:31 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT053.mail.protection.outlook.com (10.152.16.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 14:13:31 +0000 Received: ("Tessian outbound d3ae83885012:v59"); Fri, 12 Jun 2020 14:13:31 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 5aa0fb2343596bca X-CR-MTA-TID: 64aa7808 Received: from b3fbadfbe527.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F6C5EA5C-9309-4AF8-B1AA-BCDF6E1F49B4.1; Fri, 12 Jun 2020 14:13:25 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b3fbadfbe527.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Jun 2020 14:13:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ippoWR5jN+HxJNmbEQDADPkjbATNm1DcfzO3YLU+TVTEhr5J/hPzJWTZEmmJ9N3Bk/t3viacW9xNwqhcThAdpxeVjpW+cPz25nWQuI0UgVT5BBKIVmBIXtev/rlvdi+6nlYQyw9yKb/ZEnuLsg/zpIctboBL+wS42wd30K1Pnk7/0Q55TZGudnguTP+rbllqEgbenX0GaXAKCJF7WlN+HUpHuMvPvi6dhzb6LLBA9qpCnaCAs4/AHN9v6bNRm/V/aphD2UYoE7G7ZXce8H2Gj68zwAKCJMOXZD2jrKcDvhcNacTH0WzQKFkw+kZbZMwYYdWBTz7HFUGogqNFGyj3EQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UvA2vYDVQ5KMS1BQJ+/F12lF7TBR7At6rvaxQ6p5PS4=; b=aMuSG6GA4vaXX1AjAKFCJbImBqYi6xgJLx5KXAQ0AlVIoUjO2Bu9XWalCZ0rS2i3KfothhwjaEzMAeAKZolyzg+97XmSPYRwTei0J6EwiqPnO+rufyvimgNP6OkcHB1VghdQNprBUWYaJdizUoFjD3ibVKQHpZ923nONTCgiziUni0fozrk8tL7cIjBoNqJ1K3UgRLRv5HhY+7DPaD6l1NmeWq7SLbFO/JXTJxcZ6EfT3rtqATSutnZZeeBpJ65P4V3U0yjy3dvKIPxT95WMkwV1FFRKXs2k8cy0C+miZeRo96dGAj2H9Pk/8OVXk13kFcz7BQxyWzPbB0q/fMlgcg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UvA2vYDVQ5KMS1BQJ+/F12lF7TBR7At6rvaxQ6p5PS4=; b=8agTz/xi8mL64fdo5g6LlkqjVqOIq/WX/FMA4hKO3s0ohc3bQq4eI/cXCjKkefYyYLElKsEGAP5auCKnSnl9j7mIVmlZNnZaa291yrhBmbDcGD+JMy1Kv4yDam1WqGRVnZaCD8ijbbeIzJsBMRUmNJfBnqtCi0eVKK+jMkU0ut8= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3804.eurprd08.prod.outlook.com (2603:10a6:10:7b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 14:13:23 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Fri, 12 Jun 2020 14:13:23 +0000 From: Bertrand Marquis To: Julien Grall Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Topic: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Index: AQHWP+e0l1aGgjLKI0+XFOOVnv/iZKjUz6iAgAA3ygA= Date: Fri, 12 Jun 2020 14:13:23 +0000 Message-ID: <131FB1AE-656D-45E7-9019-FC50F9D5CF0B@arm.com> References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <974bf796-d410-9dd7-9e60-873987cd8434@xen.org> In-Reply-To: <974bf796-d410-9dd7-9e60-873987cd8434@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1c0bae8c-8a1f-4680-ba42-08d80edac955 x-ms-traffictypediagnostic: DB7PR08MB3804:|DB7PR08MB3674: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0432A04947 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 4Y6DbAV9pxfOIQzHPvqMFhKZZUpw0LGxA/S5fOX7qbfnFs9rYvHvfwY+h4+yJb7UcnTjgEQFGPQuC2jfU7cjGKjyTwbblRqlcLluViJkena7wO3KTMR1iDxDRBUrIa1uFLPV86LIjIN/BNAtDEB1VhtCHwcysE5n69zxtXwwk3qb0u4nxvMVVUgmI0sq+PazK4yUuolfrah1LDSDm+AgMua6sjhvMmRV47/PMc70+mU3kgO2QnthdpURlFvK7EKQ8tW2kllQxC+2gMTh53EJOyE+z6jFQvU51cDwHxrpaRLoTxaxfjXs3/93JNc+9lRyxy/qpbf6xalV3snR3gA+eQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(39860400002)(366004)(186003)(6512007)(26005)(7416002)(6486002)(4326008)(8676002)(33656002)(6916009)(2616005)(86362001)(478600001)(2906002)(316002)(36756003)(6506007)(5660300002)(8936002)(66446008)(53546011)(64756008)(76116006)(91956017)(71200400001)(66476007)(54906003)(83380400001)(66556008)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: pzRQWpgHsHURQw29KqfAIMjTDmvWdQGpECPS7xKhK34xlxRB709WgcZ5viYsaFdj5/BzpSWXBOo4n0dnb6cAv0dg1P2ikkmby7SpwYTM5I/2mQZGEOkPxJM0sOCkZ1NZwzS0P+d/+51WtmE2OvQrThKid4u5is6yonrFsYcNhsjcP4Ur1KTnD1Rpq2v4I3M7t/Wor1fbdrFEe/TEnE4Hb7e4QMAEd3MWi+Lie/k9OpmKyHnyYfEbO6vcIA5UAYMtnLcLHDRYQuIXv4zbsvxBCGfgL6jBBKhilrMrs+opZw9TrT5UpOPucT55GlZXBE/7HeLl0hIm/LznfwsYoaq2ChukRpKaCvaeUxEmn2PrmZZ4vZiyp5nJMIq+NQ7RKGz/VY8Rms/C65Hft8o/UybMOxPmrKiQ2xts/34WbLMwmmwmwXEdW15yfPonUGfzA3XqmeGJa4wEjOp2u4wwJMX0nhepdhaYfduP0uMf5/EakuM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5DDC737301447947825BBDBE037893D3@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3804 Original-Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT053.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(376002)(136003)(346002)(46966005)(54906003)(36906005)(6486002)(8676002)(336012)(316002)(4326008)(478600001)(6862004)(2906002)(186003)(6512007)(107886003)(2616005)(8936002)(86362001)(26005)(5660300002)(47076004)(83380400001)(6506007)(53546011)(81166007)(70206006)(36756003)(82310400002)(70586007)(33656002)(356005)(82740400003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 1fa695de-6b0d-4dfe-dbb9-08d80edac465 X-Forefront-PRVS: 0432A04947 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Djz4yCjKNgjlXBxz05S0CQ229uu/88HUhZZDut0zMy1R2uhhmBvr7UTJaUcdf9gRkljSxBuWNb18RUupvdCH+y3ZLNJvw61ZmVkjyPw62LOSdNiN0ygzyk+c2q22v0261Vz0lwhSghBfakqkOka/YpV2nUbpN5Zkvr6o5CpSbrXjHfRW7VQmXZi7EPCfcJs0auGTvrgV/0MnOfosGWB/ly2e6NNbpTcHCzyvvqs1TpA4DlkUeb07bFU8OcrphW8ZWOtZbD9VXiFwpuYB/DUe60PGkG9XZnO7lkJz5sUjP3Bdh+sQy/JrqhWEexUSdbiA9DVOX6x3AcJuzQ+wU0SODxMzlYZI9iGHVDO4S1Jflt0c4e+FMyNwlQ+WbpDQfn/Fnjk150Z3Lla5lToAsovvmA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2020 14:13:31.5673 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1c0bae8c-8a1f-4680-ba42-08d80edac955 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3674 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGkgSnVsaWVuLA0KDQo+IE9uIDEyIEp1biAyMDIwLCBhdCAxMTo1MywgSnVsaWVuIEdyYWxsIDxq dWxpZW5AeGVuLm9yZz4gd3JvdGU6DQo+IA0KPiBIaSBCZXJ0cmFuZCwNCj4gDQo+IE9uIDExLzA2 LzIwMjAgMTI6NTgsIEJlcnRyYW5kIE1hcnF1aXMgd3JvdGU6DQo+PiBBdCB0aGUgbW9tZW50IG9u IEFybSwgYSBMaW51eCBndWVzdCBydW5uaW5nIHdpdGggS1RQSSBlbmFibGVkIHdpbGwNCj4+IGNh dXNlIHRoZSBmb2xsb3dpbmcgZXJyb3Igd2hlbiBhIGNvbnRleHQgc3dpdGNoIGhhcHBlbnMgaW4g dXNlciBtb2RlOg0KPj4gKFhFTikgcDJtLmM6MTg5MDogZDF2MDogRmFpbGVkIHRvIHdhbGsgcGFn ZS10YWJsZSB2YSAweGZmZmZmZjgzN2ViZTBjZDANCj4gDQo+IEkgdGhpbmsgeW91IHdhbnQgdG8g YWRkIGEgYml0IG1vcmUgY29udGV4dCBleHBsYWluaW5nIHRoZSByZWFzb24gb24gdGhlIGZhaWx1 cmUuIEkuZS4gdGhpcyBpcyBiZWNhdXNlIHRoZSB2aXJ0dWFsIGFkZHJlc3MgdXNlZCBieSB0aGUg cnVuc3RhdGUgaXMgb25seSBhY2Nlc3NpYmxlIHdoZW4gcnVubmluZyBpbiBrZXJuZWwgc3BhY2Uu DQoNCk9rDQoNCj4gDQo+PiBUaGlzIHBhdGNoIGlzIG1vZGlmeWluZyB0aGUgcmVnaXN0ZXIgcnVu c3RhdGUgYXJlYSBoYW5kbGluZyBvbiBhcm0gdG8NCj4+IGNvbnZlcnQgdGhlIGd1ZXN0IGFkZHJl c3MgZHVyaW5nIHRoZSBoeXBlcmNhbGwuIER1cmluZyBydW50aW1lIGNvbnRleHQNCj4+IHN3aXRj aGVzIHRoZSBhcmVhIGlzIG1hcHBlZCB0byB1cGRhdGUgdGhlIGd1ZXN0IHJ1bnN0YXRlIGNvcHku DQo+PiBUaGUgcGF0Y2ggaXMgYWxzbyByZW1vdmluZyB0aGUgaW5pdGlhbCBjb3B5IHdoaWNoIHdh cyBkb25lIGR1cmluZyB0aGUNCj4+IGh5cGVyY2FsbCBoYW5kbGluZyBhcyB0aGlzIGlzIGRvbmUg b24gdGhlIGN1cnJlbnQgY29yZSB3aGVuIHRoZSBjb250ZXh0DQo+PiBpcyByZXN0b3JlIHRvIGdv IGJhY2sgdG8gZ3Vlc3QgZXhlY3V0aW9uIG9uIGFybS4NCj4gDQo+IFRoaXMgaXMgZXhwbGFpbmlu ZyB3aGF0IHRoZSBjb21taXQgZG9lcyBidXQgbm90IHdoeSB3ZSB3YW50IHRvIHRyYW5zbGF0ZSB0 aGUgdmlydHVhbCBhZGRyZXNzIGF0IGh5cGVyY2FsbCB0aW1lLiBNb3JlIGltcG9ydGFudGx5LCB0 aGlzIGRvZXNuJ3QgZXhwbGFpbiB0aGUgcmVzdHJpY3Rpb25zIGFkZGVkIG9uIHRoZSBoeXBlcmNh bGwgYW5kIHdoeSB0aGV5IGFyZSBmaW5lLg0KPiANCj4gTm90ZSB0aGF0IHRoZXkgYWxzbyBzaG91 bGQgYmUgZG9jdW1lbnRlZCBpbiB0aGUgcHVibGljIGhlYWRlci4NCg0KT2sNCg0KPiANCj4+IEFz IGEgY29uc2VxdWVuY2UgaWYgdGhlIHJlZ2lzdGVyIHJ1bnN0YXRlIGh5cGVyY2FsbCBpcyBjYWxs ZWQgb24gb25lDQo+PiB2Y3B1IGZvciBhbiBvdGhlciB2Y3B1LCB0aGUgYXJlYSB3aWxsIG5vdCBi ZSB1cGRhdGVkIHVudGlsIHRoZSB2Y3B1DQo+PiB3aWxsIGJlIGV4ZWN1dGVkIChvbiBhcm0gb25s eSkuDQo+IA0KPiBUaGUgY29kZSBiZWxvdyBzdWdnZXN0cyB0aGUgaHlwZXJjYWxsIHdpbGwganVz dCBmYWlsIGlmIHlvdSBjYWxsIGl0IGZyb20gYSBkaWZmZXJlbnQgdkNQVS4gSXMgdGhhdCBjb3Jy ZWN0Pw0KDQpObyB0aGUgaHlwZXJjYWxsIHdpbGwgd29yaywgYnV0IHRoZSBhcmVhIGluIHRoaXMg Y2FzZSB3b27igJl0IGJlIHVwZGF0ZWQuDQpXaGVuIHRoZSBoeXBlcmNhbGwgaXMgY2FsbGVkIG9u IHRoZSBjdXJyZW50IHZjcHUsIHRoZSBhcmVhIHdpbGwgYmUgdXBkYXRlZCB3aGVuIHRoZSBjb250 ZXh0IHdpbGwgYmUgcmVzdG9yZWQgYmVmb3JlIHJldHVybmluZyB0byB0aGUgZ3Vlc3Qgc28gdGhl cmUgaXMgbm8gbmVlZCB0byBkbyBpdCBhbiBleHRyYSB0aW1lIGluIHRoZSBoeXBlcmNhbGwgaXRz ZWxmLg0KV2hlbiB0aGlzIGlzIGRvbmUgZm9yIGEgZGlmZmVyZW50IHZjcHUgdGhlIGN1cnJlbnQg Y29kZSBpcyBub3QgdXBkYXRpbmcgdGhlIGFyZWEgYW55bW9yZS4NCg0KSSBkaWQgdGhpbmsgYXQg Zmlyc3QgdG8gZG8gaXQgYnV0IHRoZSBjb21wbGV4aXR5IGl0IHdhcyBhZGRpbmcgKG1haW5seSBk dWUgdG8gdGhlIGR1YWwgcGFnZSBjYXNlKSB3YXMgdmVyeSBoaWdoIGFuZCBJIGNvdWxkIG5vdCBy ZWFsbHkgdGhpbmsgb2YgYSB1c2UgY2FzZSBvciBmaW5kIG9uZSBpbiBMaW51eC4NCkJ1dCBub3cg dGhhdCBJIHRoaW5rIG9mIGl0IEkgY291bGQsIGluIHRoYXQgc3BlY2lmaWMgY2FzZSwgdXNlIGEg Y29weV90b19ndWVzdC4NCg0KRG8geW91IHRoaW5rIHRoaXMgaXMgc29tZXRoaW5nIHdoaWNoIHdv dWxkIG1ha2Ugc2Vuc2UgdG8gcmVzdG9yZSA/DQoNCkFueXdheSBJIHdpbGwgZml4IHRoZSBjb21t aXQgbWVzc2FnZSB0byBiZSBjbGVhcmVyIG9uIHRoYXQgcGFydC4NCg0KPiANCj4+IE9uIHg4Niwg dGhlIGJlaGF2aW91ciBpcyBub3QgbW9kaWZpZWQsIHRoZSBhZGRyZXNzIGNvbnZlcnNpb24gaXMg ZG9uZQ0KPj4gZHVyaW5nIHRoZSBjb250ZXh0IHN3aXRjaCBhbmQgdGhlIGFyZWEgaXMgdXBkYXRl ZCBmdWxseSBkdXJpbmcgdGhlDQo+PiBoeXBlcmNhbGwuDQo+PiBpbmxpbmUgZnVuY3Rpb25zIGlu IGhlYWRlcnMgY291bGQgbm90IGJlIHVzZWQgYXMgdGhlIGFyY2hpdGVjdHVyZQ0KPj4gZG9tYWlu LmggaXMgaW5jbHVkZWQgYmVmb3JlIHRoZSBnbG9iYWwgZG9tYWluLmggbWFraW5nIGl0IGltcG9z c2libGUNCj4+IHRvIHVzZSB0aGUgc3RydWN0IHZjcHUgaW5zaWRlIHRoZSBhcmNoaXRlY3R1cmUg aGVhZGVyLg0KPj4gVGhpcyBzaG91bGQgbm90IGhhdmUgYW55IHBlcmZvcm1hbmNlIGltcGFjdCBh cyB0aGUgaHlwZXJjYWxsIGlzIG9ubHkNCj4+IGNhbGxlZCBvbmNlIHBlciB2Y3B1IHVzdWFsbHku DQo+PiBTaWduZWQtb2ZmLWJ5OiBCZXJ0cmFuZCBNYXJxdWlzIDxiZXJ0cmFuZC5tYXJxdWlzQGFy bS5jb20+DQo+PiAtLS0NCj4+ICB4ZW4vYXJjaC9hcm0vZG9tYWluLmMgICAgICAgIHwgMTA5ICsr KysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tDQo+PiAgeGVuL2FyY2gveDg2L2RvbWFp bi5jICAgICAgICB8ICAzMCArKysrKysrKystDQo+PiAgeGVuL2FyY2gveDg2L3g4Nl82NC9kb21h aW4uYyB8ICAgNCArLQ0KPj4gIHhlbi9jb21tb24vZG9tYWluLmMgICAgICAgICAgfCAgMTkgKyst LS0tDQo+PiAgeGVuL2luY2x1ZGUvYXNtLWFybS9kb21haW4uaCB8ICAgOCArKysNCj4+ICB4ZW4v aW5jbHVkZS9hc20teDg2L2RvbWFpbi5oIHwgIDE2ICsrKysrDQo+PiAgeGVuL2luY2x1ZGUveGVu L2RvbWFpbi5oICAgICB8ICAgNCArKw0KPj4gIHhlbi9pbmNsdWRlL3hlbi9zY2hlZC5oICAgICAg fCAgMTYgKy0tLS0NCj4+ICA4IGZpbGVzIGNoYW5nZWQsIDE1MyBpbnNlcnRpb25zKCspLCA1MyBk ZWxldGlvbnMoLSkNCj4+IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vZG9tYWluLmMgYi94ZW4v YXJjaC9hcm0vZG9tYWluLmMNCj4+IGluZGV4IDMxMTY5MzI2YjIuLjczOTA1OTIzNGYgMTAwNjQ0 DQo+PiAtLS0gYS94ZW4vYXJjaC9hcm0vZG9tYWluLmMNCj4+ICsrKyBiL3hlbi9hcmNoL2FybS9k b21haW4uYw0KPj4gQEAgLTE5LDYgKzE5LDcgQEANCj4+ICAjaW5jbHVkZSA8eGVuL3NjaGVkLmg+ DQo+PiAgI2luY2x1ZGUgPHhlbi9zb2Z0aXJxLmg+DQo+PiAgI2luY2x1ZGUgPHhlbi93YWl0Lmg+ DQo+PiArI2luY2x1ZGUgPHhlbi9kb21haW5fcGFnZS5oPg0KPj4gICAgI2luY2x1ZGUgPGFzbS9h bHRlcm5hdGl2ZS5oPg0KPj4gICNpbmNsdWRlIDxhc20vY3B1ZXJyYXRhLmg+DQo+PiBAQCAtMjc1 LDM2ICsyNzYsMTA0IEBAIHN0YXRpYyB2b2lkIGN0eHRfc3dpdGNoX3RvKHN0cnVjdCB2Y3B1ICpu KQ0KPj4gICAgICB2aXJ0X3RpbWVyX3Jlc3RvcmUobik7DQo+PiAgfQ0KPj4gIC0vKiBVcGRhdGUg cGVyLVZDUFUgZ3Vlc3QgcnVuc3RhdGUgc2hhcmVkIG1lbW9yeSBhcmVhIChpZiByZWdpc3RlcmVk KS4gKi8NCj4+IC1zdGF0aWMgdm9pZCB1cGRhdGVfcnVuc3RhdGVfYXJlYShzdHJ1Y3QgdmNwdSAq dikNCj4+ICt2b2lkIGFyY2hfY2xlYW51cF9ydW5zdGF0ZV9ndWVzdChzdHJ1Y3QgdmNwdSAqdikN Cj4gDQo+IEkgd291bGQgcHJlZmVyIGlmIHRoaXMgaXMgbmFtZSBhcmNoX3ZjcHVfY2xlYW51cF9y dW5zdGF0ZSgpIGFzIHRoaXMgaXMgcGVyLXZDUFUgYW5kIG5vdCBwZXItZG9tYWluIGluZm9ybWF0 aW9uLg0KDQpPaw0KDQo+IA0KPj4gIHsNCj4+IC0gICAgdm9pZCBfX3VzZXIgKmd1ZXN0X2hhbmRs ZSA9IE5VTEw7DQo+PiAtICAgIHN0cnVjdCB2Y3B1X3J1bnN0YXRlX2luZm8gcnVuc3RhdGU7DQo+ PiArICAgIHNwaW5fbG9jaygmdi0+YXJjaC5ydW5zdGF0ZV9ndWVzdC5sb2NrKTsNCj4+ICAtICAg IGlmICggZ3Vlc3RfaGFuZGxlX2lzX251bGwocnVuc3RhdGVfZ3Vlc3QodikpICkNCj4+IC0gICAg ICAgIHJldHVybjsNCj4+ICsgICAgLyogY2xlYW51cCBwcmV2aW91cyBwYWdlIGlmIGFueSAqLw0K Pj4gKyAgICBpZiAoIHYtPmFyY2gucnVuc3RhdGVfZ3Vlc3QucGFnZSApDQo+PiArICAgIHsNCj4+ ICsgICAgICAgIHB1dF9wYWdlX2FuZF90eXBlKHYtPmFyY2gucnVuc3RhdGVfZ3Vlc3QucGFnZSk7 DQo+IA0KPiBnZXRfcGFnZV9mcm9tX2d2YSgpIGlzIG9ubHkgZ3JhYmJpbmcgYSByZWZlcmVuY2Ug b24gdGhlIHBhZ2UuIFNvIHlvdSB3YW50IHRvIHVzZSBwdXRfcGFnZSgpIGhlcmUuDQo+IA0KPiBO b3RlIHRoYXQgd2UgZG9uJ3QgaGF2ZSB0eXBlIHJlZmVyZW5jZSBvbiBBcm0sIHNvIGl0IGVxdWl2 YWxlbnQgdG8gcHV0X3BhZ2UoKS4gQnV0IHRoaXMgd291bGRuJ3QgYmUgdGVjaG5pY2FsbHkgY29y cmVjdCA6KS4NCg0KT2ssIHRoYW5rcyBmb3IgdGhlIGV4cGxhbmF0aW9uLg0KDQo+IA0KPj4gKyAg ICAgICAgdi0+YXJjaC5ydW5zdGF0ZV9ndWVzdC5wYWdlID0gTlVMTDsNCj4+ICsgICAgICAgIHYt PmFyY2gucnVuc3RhdGVfZ3Vlc3Qub2Zmc2V0ID0gMDsNCj4+ICsgICAgfQ0KPj4gIC0gICAgbWVt Y3B5KCZydW5zdGF0ZSwgJnYtPnJ1bnN0YXRlLCBzaXplb2YocnVuc3RhdGUpKTsNCj4+ICsgICAg c3Bpbl91bmxvY2soJnYtPmFyY2gucnVuc3RhdGVfZ3Vlc3QubG9jayk7DQo+PiArfQ0KPj4gIC0g ICAgaWYgKCBWTV9BU1NJU1Qodi0+ZG9tYWluLCBydW5zdGF0ZV91cGRhdGVfZmxhZykgKQ0KPj4g K2ludCBhcmNoX3NldHVwX3J1bnN0YXRlX2d1ZXN0KHN0cnVjdCB2Y3B1ICp2LA0KPj4gKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzdHJ1Y3QgdmNwdV9yZWdpc3Rlcl9ydW5zdGF0ZV9tZW1v cnlfYXJlYSBhcmVhKQ0KPiANCj4gVGhlIGluZGVudGF0aW9uIGxvb2tzIG9mZiBoZXJlLg0KPiAN Cj4gQWxzbywgc2FtZSByZW1hcmsgZm9yIHRoZSBuYW1pbmcuDQoNCk9rDQoNCj4gDQo+IA0KPj4g K3sNCj4+ICsgICAgc3RydWN0IHBhZ2VfaW5mbyAqcGFnZTsNCj4+ICsgICAgdW5zaWduZWQgb2Zm c2V0Ow0KPj4gKw0KPj4gKyAgICBzcGluX2xvY2soJnYtPmFyY2gucnVuc3RhdGVfZ3Vlc3QubG9j ayk7DQo+PiArDQo+PiArICAgIC8qIGNsZWFudXAgcHJldmlvdXMgcGFnZSBpZiBhbnkgKi8NCj4+ ICsgICAgaWYgKCB2LT5hcmNoLnJ1bnN0YXRlX2d1ZXN0LnBhZ2UgKQ0KPj4gICAgICB7DQo+PiAt ICAgICAgICBndWVzdF9oYW5kbGUgPSAmdi0+cnVuc3RhdGVfZ3Vlc3QucC0+c3RhdGVfZW50cnlf dGltZSArIDE7DQo+PiAtICAgICAgICBndWVzdF9oYW5kbGUtLTsNCj4+IC0gICAgICAgIHJ1bnN0 YXRlLnN0YXRlX2VudHJ5X3RpbWUgfD0gWEVOX1JVTlNUQVRFX1VQREFURTsNCj4+IC0gICAgICAg IF9fcmF3X2NvcHlfdG9fZ3Vlc3QoZ3Vlc3RfaGFuZGxlLA0KPj4gLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAodm9pZCAqKSgmcnVuc3RhdGUuc3RhdGVfZW50cnlfdGltZSArIDEpIC0gMSwg MSk7DQo+PiAtICAgICAgICBzbXBfd21iKCk7DQo+PiArICAgICAgICBwdXRfcGFnZV9hbmRfdHlw ZSh2LT5hcmNoLnJ1bnN0YXRlX2d1ZXN0LnBhZ2UpOw0KPiANCj4gU2FtZSByZW1hcmsgaGVyZS4g QWx0aG91Z2ggSSB3b3VsZCBwcmVmZXIgaWYgd2UgdHJ5IHRvIGhhdmUgYSBjb21tb24gaGVscGVy IHRvIGNsZWFuaW5nIHVwIHRoZSBydW5zdGF0ZS4gTWF5YmUgY2xlYW51cF9ydW5zdGF0ZV92Y3B1 X2xvY2tlZCgpPw0KDQpBZ3JlZSBJIHdpbGwgYWRkIGEgc3RhdGljIGZ1bmN0aW9uIGFuZCB1c2Ug aXQgb24gdGhvc2UgMiBsb2NhdGlvbnMuDQoNCj4gDQo+PiArICAgICAgICB2LT5hcmNoLnJ1bnN0 YXRlX2d1ZXN0LnBhZ2UgPSBOVUxMOw0KPj4gKyAgICAgICAgdi0+YXJjaC5ydW5zdGF0ZV9ndWVz dC5vZmZzZXQgPSAwOw0KPj4gKyAgICB9DQo+PiArDQo+PiArICAgIG9mZnNldCA9ICgodmFkZHJf dClhcmVhLmFkZHIudikgJiB+UEFHRV9NQVNLOw0KPj4gKyAgICBpZiAoIG9mZnNldCA+IChQQUdF X1NJWkUgLSBzaXplb2Yoc3RydWN0IHZjcHVfcnVuc3RhdGVfaW5mbykpICkNCj4+ICsgICAgew0K Pj4gKyAgICAgICAgc3Bpbl91bmxvY2soJnYtPmFyY2gucnVuc3RhdGVfZ3Vlc3QubG9jayk7DQo+ PiArICAgICAgICBncHJpbnRrKFhFTkxPR19ERUJVRywgIlJ1bnN0YXRlIGlzIGNyb3NzaW5nIHBh Z2VzXG4iKTsNCj4+ICsgICAgICAgIHJldHVybiAtRUlOVkFMOw0KPj4gKyAgICB9DQo+PiArDQo+ PiArICAgIC8qIHByb3ZpZGVkIGFkZHJlc3MgbXVzdCBiZSBhbGlnbmVkIHRvIGEgNjRiaXQgKi8N Cj4+ICsgICAgaWYgKCBvZmZzZXQgJSBhbGlnbm9mKHN0cnVjdCB2Y3B1X3J1bnN0YXRlX2luZm8p ICkNCj4+ICsgICAgew0KPj4gKyAgICAgICAgc3Bpbl91bmxvY2soJnYtPmFyY2gucnVuc3RhdGVf Z3Vlc3QubG9jayk7DQo+PiArICAgICAgICBncHJpbnRrKFhFTkxPR19ERUJVRywgIlJ1bnN0YXRl IHBvaW50ZXIgaXMgbm90IGFsaWduZWRcbiIpOw0KPj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7 DQo+PiArICAgIH0NCj4+ICsNCj4+ICsgICAgcGFnZSA9IGdldF9wYWdlX2Zyb21fZ3ZhKHYsICh2 YWRkcl90KWFyZWEuYWRkci52LCBHVjJNX1dSSVRFKTsNCj4gDQo+IEluIHRoZSBjdXJyZW50IGlt cGxlbWVudGF0aW9uLCAwIHdhcyB1c2VkIHRvIHVucmVnaXN0ZXIgdGhlIHJ1bnN0YXRlIGFyZWEu IEkgdGhpbmsgd2Ugd2FudCB0byBrZWVwIHRoYXQgZmVhdHVyZSBhbmQgbm90IHRocm93IGFuIGVy cm9yLg0KDQpJIHdpbGwgYWRkIHRoaXMgdXNlIGNhc2UgKEkgbWlzc2VkIGl0KS4NCg0KPiANCj4+ ICsgICAgaWYgKCAhcGFnZSApDQo+PiArICAgIHsNCj4+ICsgICAgICAgIHNwaW5fdW5sb2NrKCZ2 LT5hcmNoLnJ1bnN0YXRlX2d1ZXN0LmxvY2spOw0KPj4gKyAgICAgICAgZ3ByaW50ayhYRU5MT0df REVCVUcsICJSdW5zdGF0ZSBwb2ludGVyIGlzIG5vdCBtYXBwZWRcbiIpOw0KPj4gKyAgICAgICAg cmV0dXJuIC1FSU5WQUw7DQo+PiAgICAgIH0NCj4+ICAtICAgIF9fY29weV90b19ndWVzdChydW5z dGF0ZV9ndWVzdCh2KSwgJnJ1bnN0YXRlLCAxKTsNCj4+ICsgICAgdi0+YXJjaC5ydW5zdGF0ZV9n dWVzdC5wYWdlID0gcGFnZTsNCj4+ICsgICAgdi0+YXJjaC5ydW5zdGF0ZV9ndWVzdC5vZmZzZXQg PSBvZmZzZXQ7DQo+PiArDQo+IA0KPiBJbiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiwgdGhl IHJ1bnN0YXRlIGFyZWEgd2FzIHVwZGF0ZSB3aXRoIHRoZSBsYXRlc3QgaW5mb3JtYXRpb24gZHVy aW5nIHRoZSBoeXBlcmNhbGwuIFRoaXMgZG9lc24ndCBzZWVtIHRvIGhhcHBlbiBhbnltb3JlLiBJ cyB0aGVyZSBhbnkgc3BlY2lmaWMgcmVhc29uPw0KDQpBcyBleHBsYWluZWQgYmVmb3JlLCB0aGlz IGlzIHN0aWxsIGhhcHBlbmluZyBvbiB0aGUgY3VycmVudCB2Y3B1IGFzIGEgcmVzdWx0IG9mIHRo ZSBjb250ZXh0IHN3aXRjaCBiYWNrIHRvIHRoZSBndWVzdCBhdCB0aGUgZW5kIG9mIHRoZSBoeXBl cmNhbGwuDQpUaGlzIGlzIG5vdCBkb25lIGlmIGNhbGxlZCBmb3IgYSBkaWZmZXJlbnQgdmNwdSBh bnltb3JlLCBidXQgSSBjb3VsZCBhZGQgaXQgYmFjayB1c2luZyBjb3B5X3RvX2d1ZXN0DQoNCj4g DQo+PiArICAgIHNwaW5fdW5sb2NrKCZ2LT5hcmNoLnJ1bnN0YXRlX2d1ZXN0LmxvY2spOw0KPj4g Kw0KPj4gKyAgICByZXR1cm4gMDsNCj4+ICt9DQo+PiArDQo+PiArDQo+PiArLyogVXBkYXRlIHBl ci1WQ1BVIGd1ZXN0IHJ1bnN0YXRlIHNoYXJlZCBtZW1vcnkgYXJlYSAoaWYgcmVnaXN0ZXJlZCku ICovDQo+PiArc3RhdGljIHZvaWQgdXBkYXRlX3J1bnN0YXRlX2FyZWEoc3RydWN0IHZjcHUgKnYp DQo+PiArew0KPj4gKyAgICBzdHJ1Y3QgdmNwdV9ydW5zdGF0ZV9pbmZvICpndWVzdF9ydW5zdGF0 ZTsNCj4+ICsgICAgdm9pZCAqcDsNCj4+ICsNCj4+ICsgICAgc3Bpbl9sb2NrKCZ2LT5hcmNoLnJ1 bnN0YXRlX2d1ZXN0LmxvY2spOw0KPj4gIC0gICAgaWYgKCBndWVzdF9oYW5kbGUgKQ0KPj4gKyAg ICBpZiAoIHYtPmFyY2gucnVuc3RhdGVfZ3Vlc3QucGFnZSApDQo+PiAgICAgIHsNCj4+IC0gICAg ICAgIHJ1bnN0YXRlLnN0YXRlX2VudHJ5X3RpbWUgJj0gflhFTl9SVU5TVEFURV9VUERBVEU7DQo+ PiArICAgICAgICBwID0gX19tYXBfZG9tYWluX3BhZ2Uodi0+YXJjaC5ydW5zdGF0ZV9ndWVzdC5w YWdlKTsNCj4+ICsgICAgICAgIGd1ZXN0X3J1bnN0YXRlID0gcCArIHYtPmFyY2gucnVuc3RhdGVf Z3Vlc3Qub2Zmc2V0Ow0KPj4gKw0KPj4gKyAgICAgICAgaWYgKCBWTV9BU1NJU1Qodi0+ZG9tYWlu LCBydW5zdGF0ZV91cGRhdGVfZmxhZykgKQ0KPj4gKyAgICAgICAgew0KPj4gKyAgICAgICAgICAg IHYtPnJ1bnN0YXRlLnN0YXRlX2VudHJ5X3RpbWUgfD0gWEVOX1JVTlNUQVRFX1VQREFURTsNCj4+ ICsgICAgICAgICAgICBndWVzdF9ydW5zdGF0ZS0+c3RhdGVfZW50cnlfdGltZSB8PSBYRU5fUlVO U1RBVEVfVVBEQVRFOw0KPj4gKyAgICAgICAgICAgIHNtcF93bWIoKTsNCj4+ICsgICAgICAgIH0N Cj4+ICsNCj4+ICsgICAgICAgIG1lbWNweShndWVzdF9ydW5zdGF0ZSwgJnYtPnJ1bnN0YXRlLCBz aXplb2Yodi0+cnVuc3RhdGUpKTsNCj4+ICAgICAgICAgIHNtcF93bWIoKTsNCj4+IC0gICAgICAg IF9fcmF3X2NvcHlfdG9fZ3Vlc3QoZ3Vlc3RfaGFuZGxlLA0KPj4gLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAodm9pZCAqKSgmcnVuc3RhdGUuc3RhdGVfZW50cnlfdGltZSArIDEpIC0gMSwg MSk7DQo+PiArDQo+PiArICAgICAgICBpZiAoIFZNX0FTU0lTVCh2LT5kb21haW4sIHJ1bnN0YXRl X3VwZGF0ZV9mbGFnKSApDQo+PiArICAgICAgICB7DQo+PiArICAgICAgICAgICAgdi0+cnVuc3Rh dGUuc3RhdGVfZW50cnlfdGltZSAmPSB+WEVOX1JVTlNUQVRFX1VQREFURTsNCj4+ICsgICAgICAg ICAgICBndWVzdF9ydW5zdGF0ZS0+c3RhdGVfZW50cnlfdGltZSAmPSB+WEVOX1JVTlNUQVRFX1VQ REFURTsNCj4+ICsgICAgICAgICAgICBzbXBfd21iKCk7DQo+IA0KPiBXaHkgZG8geW91IG5lZWQg dGhpcyBiYXJyaWVyPw0KDQpBcyB0aGUgYml0IGlzIHN1cHBvc2VkIHRvIGJlIHVzZWQgdG8gd2Fp dCBmb3IgYW4gdXBkYXRlIHRvIGJlIGRvbmUsIEkgZmVsdCBpdCB3YXMgYmV0dGVyIHRvIHB1c2gg dGhpcyBvdXQgYXMgc29vbiBhcyBwb3NzaWJsZS4NCkFzIHRoZXJlIGlzIGFscmVhZHkgb25lIGFm dGVyIHRoZSBtZW1jcHksIHRoZSBjb3N0IHNob3VsZCBiZSBmYWlybHkgbGltaXRlZCBoZXJlLg0K DQo+IA0KPiANCj4gWy4uLl0NCj4gDQo+PiBkaWZmIC0tZ2l0IGEveGVuL2luY2x1ZGUvYXNtLWFy bS9kb21haW4uaCBiL3hlbi9pbmNsdWRlL2FzbS1hcm0vZG9tYWluLmgNCj4+IGluZGV4IDRlMmY1 ODIwMDYuLjNhN2Y1M2UxM2QgMTAwNjQ0DQo+PiAtLS0gYS94ZW4vaW5jbHVkZS9hc20tYXJtL2Rv bWFpbi5oDQo+PiArKysgYi94ZW4vaW5jbHVkZS9hc20tYXJtL2RvbWFpbi5oDQo+PiBAQCAtMTEs NiArMTEsNyBAQA0KPj4gICNpbmNsdWRlIDxhc20vdmdpYy5oPg0KPj4gICNpbmNsdWRlIDxhc20v dnBsMDExLmg+DQo+PiAgI2luY2x1ZGUgPHB1YmxpYy9odm0vcGFyYW1zLmg+DQo+PiArI2luY2x1 ZGUgPHB1YmxpYy92Y3B1Lmg+DQo+IA0KPiBXaHkgZG8geW91IG5lZWQgdG8gYWRkIHRoaXMgbmV3 IGluY2x1ZGU/DQo+IA0KPj4gICNpbmNsdWRlIDx4ZW4vc2VyaWFsLmg+DQo+PiAgI2luY2x1ZGUg PHhlbi9yYnRyZWUuaD4NCj4+ICBAQCAtMjA2LDYgKzIwNywxMyBAQCBzdHJ1Y3QgYXJjaF92Y3B1 DQo+PiAgICAgICAqLw0KPj4gICAgICBib29sIG5lZWRfZmx1c2hfdG9fcmFtOw0KPj4gICsgICAg LyogcnVuc3RhdGUgZ3Vlc3QgaW5mbyAqLw0KPj4gKyAgICBzdHJ1Y3Qgew0KPj4gKyAgICAgICAg c3RydWN0IHBhZ2VfaW5mbyAqcGFnZTsgIC8qIGd1ZXN0IHBhZ2UgKi8NCj4+ICsgICAgICAgIHVu c2lnbmVkICAgICAgICAgb2Zmc2V0OyAvKiBvZmZzZXQgaW4gcGFnZSAqLw0KPiANCj4gUGxlYXNl IHVzZSB1bnNpZ25lZCBpbnQuDQpPaw0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQpCZXJ0 cmFuZA0KDQo= From xen-devel-bounces@lists.xenproject.org Fri Jun 12 14:31:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 14:31:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjki7-0007Nj-1u; Fri, 12 Jun 2020 14:31:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjki5-0007Ne-DO for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 14:31:09 +0000 X-Inumbo-ID: 5b38281a-acb9-11ea-8496-bc764e2007e4 Received: from mail-qv1-xf2f.google.com (unknown [2607:f8b0:4864:20::f2f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5b38281a-acb9-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 14:31:08 +0000 (UTC) Received: by mail-qv1-xf2f.google.com with SMTP id dp10so4411323qvb.10 for ; Fri, 12 Jun 2020 07:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=Hg+W0zABmF6n2uWPQyG+mVbjLgEVs3exLfQq39XfqCc=; b=aVU1EtfbcL/PrI273a78owxE7T+MlqcWBgaY2TuZ2QDlBKrU9zGG1+Kegg+R+MQwaY J3Ef7OEndUj+pLmQ7GR4LrOZcbn/s8sOvgpja1qYmMvCBXSR7y4opUIephUSsgrc7IRK JMY0GlJd4fZrz8fjpt5TH6s+r1qSer022DIgJy0fAbnTFxiSFYU0lI3u5MSuRZV6m1f3 b2M370ntLdUECVC+ZDCi0ctNdmv0UqB/Ap5dVocQNaJy8iJPkQAW6StG1NjLhtYhNDnj J1t3Bm6IO+mrDyvd77pOipF5kHfOKyON4rbEsBcKENaS6DFuWYEFGxk/v0f4YM5VBGgo PBaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Hg+W0zABmF6n2uWPQyG+mVbjLgEVs3exLfQq39XfqCc=; b=O1mOs7SkMCGseEF4pw7sP0Z5fySoH4PLI8e1NsQDOwZdx44+InDtej9kkVfko4iXQT pzBwzW8fUQScMcWOUcAx2RBIGVcbxbwlb+mJ+GthjpJSGAyhltA7fRNV8EhEBdG1grfU 2o3UVsC5h2aJzn45q2TatiUMnPVtyQL4NsWUkSXMt9wMJzfYFgH6HbuRgFbpV1lcRCWK PVLdHTugxGHBEWPPhVFobUcHuEuFDVuKFKiqWm2BI6ZcPKZpH8wW3yoL+L+/C1GfcLXy RrZBhpQ/QQOtNLDfa4SN0SHd+xFGB95Fh6spS9LtxXxfWZONrzjnhPoImgUeCKG0zOSX D7xg== X-Gm-Message-State: AOAM531MQkkveR5n0IumPc5tO/2hH3kDV6MMzDCt5FIL9oKfstF2DjJV KkLexFsggT9RQTD4LfZQRcLba+jUIx8= X-Google-Smtp-Source: ABdhPJyLqsqqxD8piMwE043nxlG7ig/iNnvJP8Th+Odt2Lc/2o0zN95bWz7gJ39xLuUBNUTvrHXoMQ== X-Received: by 2002:a0c:f84c:: with SMTP id g12mr12736822qvo.31.1591972267782; Fri, 12 Jun 2020 07:31:07 -0700 (PDT) Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252]) by smtp.gmail.com with ESMTPSA id h77sm4738729qke.37.2020.06.12.07.31.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2020 07:31:06 -0700 (PDT) From: Nick Rosbrook X-Google-Original-From: Nick Rosbrook To: xen-devel@lists.xenproject.org Subject: [PATCH for-4.14] tools: check go compiler version if present Date: Fri, 12 Jun 2020 10:31:02 -0400 Message-Id: X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , Ian Jackson , george.dunlap@citrix.com, Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Currently, no minimum go compiler version is required by the configure scripts. However, the go bindings actually will not build with some older versions of go. Add a check for a minimum go version of 1.11.1 in accordance with tools/golang/xenlight/go.mod. Signed-off-by: Nick Rosbrook --- m4/golang.m4 | 4 ++++ tools/configure | 49 ++++++++++++++++++++++++++++++++++++++++++++++ tools/configure.ac | 7 +++++++ 3 files changed, 60 insertions(+) diff --git a/m4/golang.m4 b/m4/golang.m4 index 0b4bd54ce0..9cfd7e00a5 100644 --- a/m4/golang.m4 +++ b/m4/golang.m4 @@ -1,4 +1,8 @@ AC_DEFUN([AC_PROG_GO], [ dnl Check for the go compiler AC_CHECK_TOOL([GO],[go],[no]) + + if test "$GO" != "no"; then + GOVERSION=`$GO version | cut -d " " -f 3 | sed "s/go//"` + fi ]) diff --git a/tools/configure b/tools/configure index b3668ec98d..f3f19c1a90 100755 --- a/tools/configure +++ b/tools/configure @@ -6845,6 +6845,10 @@ else fi + if test "$GO" != "no"; then + GOVERSION=`$GO version | cut -d " " -f 3 | sed "s/go//"` + fi + if test "x$GO" = "xno"; then : if test "x$enable_golang" = "xyes"; then : @@ -6854,6 +6858,51 @@ fi fi golang="n" +else + + + + + # Used to indicate true or false condition + ax_compare_version=false + + # Convert the two version strings to be compared into a format that + # allows a simple string comparison. The end result is that a version + # string of the form 1.12.5-r617 will be converted to the form + # 0001001200050617. In other words, each number is zero padded to four + # digits, and non digits are removed. + + ax_compare_version_A=`echo "$GOVERSION" | sed -e 's/\([0-9]*\)/Z\1Z/g' \ + -e 's/Z\([0-9]\)Z/Z0\1Z/g' \ + -e 's/Z\([0-9][0-9]\)Z/Z0\1Z/g' \ + -e 's/Z\([0-9][0-9][0-9]\)Z/Z0\1Z/g' \ + -e 's/[^0-9]//g'` + + + ax_compare_version_B=`echo "1.11.1" | sed -e 's/\([0-9]*\)/Z\1Z/g' \ + -e 's/Z\([0-9]\)Z/Z0\1Z/g' \ + -e 's/Z\([0-9][0-9]\)Z/Z0\1Z/g' \ + -e 's/Z\([0-9][0-9][0-9]\)Z/Z0\1Z/g' \ + -e 's/[^0-9]//g'` + + + ax_compare_version=`echo "x$ax_compare_version_A +x$ax_compare_version_B" | sed 's/^ *//' | sort -r | sed "s/x${ax_compare_version_A}/false/;s/x${ax_compare_version_B}/true/;1q"` + + + + if test "$ax_compare_version" = "true" ; then + + if test "x$enable_golang" = "xyes"; then : + + as_fn_error $? "\"Your version of go: $GOVERSION is not supported\"" "$LINENO" 5 + +fi + golang="n" + + fi + + fi fi diff --git a/tools/configure.ac b/tools/configure.ac index a9af0a21c6..9d126b7a14 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -338,6 +338,13 @@ AS_IF([test "x$golang" = "xy"], [ AC_MSG_ERROR([Go tools enabled, but missing go compiler]) ]) golang="n" + ], [ + AX_COMPARE_VERSION([$GOVERSION], [lt], [1.11.1], [ + AS_IF([test "x$enable_golang" = "xyes"], [ + AC_MSG_ERROR(["Your version of go: $GOVERSION is not supported"]) + ]) + golang="n" + ]) ]) ]) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 14:55:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 14:55:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjl5V-0000gi-5n; Fri, 12 Jun 2020 14:55:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjl5U-0000gd-Hr for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 14:55:20 +0000 X-Inumbo-ID: bb3c78d0-acbc-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x42b.google.com (unknown [2a00:1450:4864:20::42b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bb3c78d0-acbc-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 14:55:18 +0000 (UTC) Received: by mail-wr1-x42b.google.com with SMTP id h5so10061599wrc.7 for ; Fri, 12 Jun 2020 07:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=IAlgWmMpNXud4HHQ6/Kga7WExUXf5qDyf7r//9MvSHc=; b=ebzvonPQqEhiaQP1INPnJTEXwUAbfWP+9Lr1wBQEhqcGN39odqjyBN+lRANuOTgKhy QWDSHRojoYn/JbwEO5Zor9v5ej+PNcslWKFhb6n6RV9dZ0qYjYPY1UYzIZXUfz7v0RH8 GrMcFoobx4aGPCWNrUrwlZT7OuNEo4R89IZRB7W2aGTsOq5h0eugEaewb9pUhg5iHihx MhWzHVuZ6cK3srowMpl0u9tilY7QR6G9fHt82Uly9M8ULdkJ8PQwdrOaBlLykuOhGt1k QFHlx+xLvGfDJxlIrUBUlcBkqrvctbLrz2RxmCkGoUUsfIKa1NmsHWDHz7IDC4C/yEnj eJDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=IAlgWmMpNXud4HHQ6/Kga7WExUXf5qDyf7r//9MvSHc=; b=aM00inPlGRSivW8bFmQReY7YfQzLt9F5bFSZIo7S6/yoMEvaw+lmgZOzp7dwN5eHVX fvKHwNZTk5qGbmWBMJJwtjcpakjgRFLfpi0KxwpmJMBByr4TmgsMyxw2Jj9dOg1fJC95 PlqjN++oFM2O0MNEcNuvBDau9WGkmwhwyzYaFvZ6bLbpiUJ0sRgnaf0UmK2ewAxUi6K/ yjIfAca+q10HiVzE2UnjT5Q5CH1cWZrrQR+lAmpV0g+HwMrPHQ3vz65Qe+vTQZyPLgxO xtOepQ25G87CalQeqD6qb3mO4McM+61wMCdQKsyTsqiQV5ME/szCuqhNb76wovDmm4vz N+kg== X-Gm-Message-State: AOAM533m6R5stAnJQcAFa3WS2DpO6ZFvxtvun/jzaBuaBZeBRshlvM6Q zFcCCsQlrH2hZJkKsblVNDQ= X-Google-Smtp-Source: ABdhPJyDk6bMq/MuXhq3ecOuPdA9Lb8vK9TOU4qU74M9lRSFrMR2AsZQyp4EBNirwwOs9t6u8Sh1kQ== X-Received: by 2002:a5d:4f0d:: with SMTP id c13mr16311216wru.357.1591973718015; Fri, 12 Jun 2020 07:55:18 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id g82sm9393597wmf.1.2020.06.12.07.55.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 07:55:15 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Andrew Cooper'" References: <439f3d92-2e18-1868-2b4b-2747973fbe3b@citrix.com> <24291.36156.961284.809662@mariner.uk.xensource.com> In-Reply-To: <24291.36156.961284.809662@mariner.uk.xensource.com> Subject: RE: libxl dirty in tree after libxl build Date: Fri, 12 Jun 2020 15:55:14 +0100 Message-ID: <000401d640c9$7b14e760$713eb620$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLZtzJZYIE21Pzr7nw56XGkYRVH5gJkCQYOprsDwnA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'xen-devel' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = Ian Jackson > Sent: 12 June 2020 15:12 > To: Andrew Cooper > Cc: xen-devel ; Wei Liu > Subject: Re: libxl dirty in tree after libxl build >=20 > Andrew Cooper writes ("libxl dirty in tree after libxl build"): > > A build of libxl has just dirtied the tree with: > > > > index 05f7ac74a0..94a4438666 100644 > > --- a/tools/libxl/libxlu_disk_l.c > > +++ b/tools/libxl/libxlu_disk_l.c > > @@ -10,221 +10,11 @@ > > =A0#define FLEX_SCANNER > > =A0#define YY_FLEX_MAJOR_VERSION 2 > > =A0#define YY_FLEX_MINOR_VERSION 6 > > -#define YY_FLEX_SUBMINOR_VERSION 4 > > +#define YY_FLEX_SUBMINOR_VERSION 1 > > =A0#if YY_FLEX_SUBMINOR_VERSION > 0 > > =A0#define FLEX_BETA > > =A0#endif > > > > and a whole slew of other changes in the generated code.=A0 It looks = like > > the version of Flex has just been updated in Jessie. > > > > Given the flex and bison are strictly required for the libxl build, = why > > is this temporary file checked in? >=20 > The point of the exercise is to *not* require them. The reason is > that some of our developers have very old development systems which do > not support essential flex/bison features. Can't we check in a file with a different name 'e.g.' with something = like '.tmpl' on the end, which we copy into place in case the flex/bison don't generate such a file? That way the checked in file = never gets dirtied. Paul >=20 > How about we update them to the version from buster ? >=20 > Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:13:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:13:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlNA-0002MD-OT; Fri, 12 Jun 2020 15:13:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlN9-0002M8-Qi for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:13:35 +0000 X-Inumbo-ID: 487f571a-acbf-11ea-b5de-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 487f571a-acbf-11ea-b5de-12813bfff9fa; Fri, 12 Jun 2020 15:13:34 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: hg0iaBBxuQ4i8AxbsjU5IFy1cI7sh2Kv4FRJgEUOcw+gJ2VtQQNAHVcgIFiSg/aXsSmaAc+j+F 1eeGOxW7Kax9panAOEqii458R1+vajk49OXdzG3IbGm7o7xWF9QU3cTGbggc+2gBKZcU9hnbB7 518l4/ZYnyrUpwSSuMIeX/seegu9myAKGlKlqHlzyVbbzm0mCPVl5Oya99tU9WLU70XNmWkUvq cTXo7kybf7Tppw71Qv2GVgzJH2snohYc6LqssEJvGzzHO54NMDgSsCEtXXdMBxy6+IsqsvLd+G lZk= X-SBRS: 2.7 X-MesageID: 19930688 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="19930688" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24291.39821.243999.847153@mariner.uk.xensource.com> Date: Fri, 12 Jun 2020 16:13:17 +0100 To: "paul@xen.org" Subject: RE: libxl dirty in tree after libxl build In-Reply-To: <000401d640c9$7b14e760$713eb620$@xen.org> References: <439f3d92-2e18-1868-2b4b-2747973fbe3b@citrix.com> <24291.36156.961284.809662@mariner.uk.xensource.com> <000401d640c9$7b14e760$713eb620$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , 'Wei Liu' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: libxl dirty in tree after libxl build"): > Can't we check in a file with a different name 'e.g.' with something > like '.tmpl' on the end, which we copy into place in case the > flex/bison don't generate such a file? That way the checked in file > never gets dirtied. That would be possible in principle. It would be necessary to do something fiddly in the Makefile runes to make sure that the build failed if you updated the input files but didn't have flex/bison. Another alterntaive, of course, would be to say that we don't support such ancient versions of flex/bison, or systems without those tools at all, and simply delete the generated files. I forget the details but the relevant changes were released upstream at least a decade ago. But I think that at this stage of the release it would be best to update the files as has been our practice hitherto. I am not keen on the idea of inventing new weird Makefile wrinkles during the freeze, unless we have no reasonable alternative. Patches will follow in a moment. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:19:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:19:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlT4-0002Xh-LT; Fri, 12 Jun 2020 15:19:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlT3-0002XL-Ms for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:19:41 +0000 X-Inumbo-ID: 20de7280-acc0-11ea-bb8b-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 20de7280-acc0-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 15:19:37 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jjlSy-0005QE-Um; Fri, 12 Jun 2020 16:19:37 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [XEN PATCH for-4.14 1/2] tools: Commit autoconf (2.69) output from Debian buster Date: Fri, 12 Jun 2020 16:19:30 +0100 Message-Id: <20200612151931.1083-2-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <000401d640c9$7b14e760$713eb620$@xen.org> References: <000401d640c9$7b14e760$713eb620$@xen.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Samuel Thibault , ian.jackson@eu.citrix.com, Nick Rosbrook , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" These files are in tree so that people can build (including from git) without needing recent autotools. We should update them periodically. Debian buster has been Debian stable fopr a while. Our CI is running buster. There should be no significant functional change; it's possible that there are bugfixes to the configure scripts but I have not reviewed them. These files were last changed in 83c845033dc8bb3a35ae245effb7832b6823174a libxl: use vchan for QMP access with Linux stubdomain where a new feature was added. However, that commit contains a lot of extraneous noise in configure compared to its parent. Compared to 83c845033dc8bb3a35ae245effb7832b6823174a~, this commit restores those extraneous changes, leaving precisely the correct changes. So one way of looking at the changes we are making now, is that we are undoing accidental changes to the autoconf output. CC: Wei Liu CC: Nick Rosbrook Reported-by: Nick Rosbrook CC: Paul Durrant Signed-off-by: Ian Jackson --- configure | 14 +++++++++++++- docs/configure | 14 +++++++++++++- stubdom/configure | 14 +++++++++++++- tools/configure | 24 ++++++++++++++++++------ 4 files changed, 57 insertions(+), 9 deletions(-) diff --git a/configure b/configure index 8af54e8a5a..9da3970cef 100755 --- a/configure +++ b/configure @@ -644,6 +644,7 @@ infodir docdir oldincludedir includedir +runstatedir localstatedir sharedstatedir sysconfdir @@ -722,6 +723,7 @@ datadir='${datarootdir}' sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' +runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -974,6 +976,15 @@ do | -silent | --silent | --silen | --sile | --sil) silent=yes ;; + -runstatedir | --runstatedir | --runstatedi | --runstated \ + | --runstate | --runstat | --runsta | --runst | --runs \ + | --run | --ru | --r) + ac_prev=runstatedir ;; + -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ + | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ + | --run=* | --ru=* | --r=*) + runstatedir=$ac_optarg ;; + -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ @@ -1111,7 +1122,7 @@ fi for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \ datadir sysconfdir sharedstatedir localstatedir includedir \ oldincludedir docdir infodir htmldir dvidir pdfdir psdir \ - libdir localedir mandir + libdir localedir mandir runstatedir do eval ac_val=\$$ac_var # Remove trailing slashes. @@ -1264,6 +1275,7 @@ Fine tuning of the installation directories: --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] + --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] diff --git a/docs/configure b/docs/configure index 93e9dcf404..9e3ed60462 100755 --- a/docs/configure +++ b/docs/configure @@ -634,6 +634,7 @@ infodir docdir oldincludedir includedir +runstatedir localstatedir sharedstatedir sysconfdir @@ -710,6 +711,7 @@ datadir='${datarootdir}' sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' +runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -962,6 +964,15 @@ do | -silent | --silent | --silen | --sile | --sil) silent=yes ;; + -runstatedir | --runstatedir | --runstatedi | --runstated \ + | --runstate | --runstat | --runsta | --runst | --runs \ + | --run | --ru | --r) + ac_prev=runstatedir ;; + -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ + | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ + | --run=* | --ru=* | --r=*) + runstatedir=$ac_optarg ;; + -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ @@ -1099,7 +1110,7 @@ fi for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \ datadir sysconfdir sharedstatedir localstatedir includedir \ oldincludedir docdir infodir htmldir dvidir pdfdir psdir \ - libdir localedir mandir + libdir localedir mandir runstatedir do eval ac_val=\$$ac_var # Remove trailing slashes. @@ -1252,6 +1263,7 @@ Fine tuning of the installation directories: --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] + --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] diff --git a/stubdom/configure b/stubdom/configure index f7604a37f7..da03da535a 100755 --- a/stubdom/configure +++ b/stubdom/configure @@ -661,6 +661,7 @@ infodir docdir oldincludedir includedir +runstatedir localstatedir sharedstatedir sysconfdir @@ -750,6 +751,7 @@ datadir='${datarootdir}' sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' +runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -1002,6 +1004,15 @@ do | -silent | --silent | --silen | --sile | --sil) silent=yes ;; + -runstatedir | --runstatedir | --runstatedi | --runstated \ + | --runstate | --runstat | --runsta | --runst | --runs \ + | --run | --ru | --r) + ac_prev=runstatedir ;; + -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ + | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ + | --run=* | --ru=* | --r=*) + runstatedir=$ac_optarg ;; + -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ @@ -1139,7 +1150,7 @@ fi for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \ datadir sysconfdir sharedstatedir localstatedir includedir \ oldincludedir docdir infodir htmldir dvidir pdfdir psdir \ - libdir localedir mandir + libdir localedir mandir runstatedir do eval ac_val=\$$ac_var # Remove trailing slashes. @@ -1292,6 +1303,7 @@ Fine tuning of the installation directories: --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] + --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] diff --git a/tools/configure b/tools/configure index 3df1a01ff9..b3668ec98d 100755 --- a/tools/configure +++ b/tools/configure @@ -772,6 +772,7 @@ infodir docdir oldincludedir includedir +runstatedir localstatedir sharedstatedir sysconfdir @@ -899,6 +900,7 @@ datadir='${datarootdir}' sysconfdir='${prefix}/etc' sharedstatedir='${prefix}/com' localstatedir='${prefix}/var' +runstatedir='${localstatedir}/run' includedir='${prefix}/include' oldincludedir='/usr/include' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' @@ -1151,6 +1153,15 @@ do | -silent | --silent | --silen | --sile | --sil) silent=yes ;; + -runstatedir | --runstatedir | --runstatedi | --runstated \ + | --runstate | --runstat | --runsta | --runst | --runs \ + | --run | --ru | --r) + ac_prev=runstatedir ;; + -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \ + | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \ + | --run=* | --ru=* | --r=*) + runstatedir=$ac_optarg ;; + -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb) ac_prev=sbindir ;; -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \ @@ -1288,7 +1299,7 @@ fi for ac_var in exec_prefix prefix bindir sbindir libexecdir datarootdir \ datadir sysconfdir sharedstatedir localstatedir includedir \ oldincludedir docdir infodir htmldir dvidir pdfdir psdir \ - libdir localedir mandir + libdir localedir mandir runstatedir do eval ac_val=\$$ac_var # Remove trailing slashes. @@ -1441,6 +1452,7 @@ Fine tuning of the installation directories: --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] + --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] @@ -3374,7 +3386,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -3420,7 +3432,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -3444,7 +3456,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -3489,7 +3501,7 @@ else We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; @@ -3513,7 +3525,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext We can't simply define LARGE_OFF_T to be 9223372036854775807, since some C++ compilers masquerading as C compilers incorrectly reject 9223372036854775807. */ -#define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) +#define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) << 31)) int off_t_is_large[(LARGE_OFF_T % 2147483629 == 721 && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:19:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:19:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlT0-0002XQ-Dy; Fri, 12 Jun 2020 15:19:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlSy-0002XL-Sp for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:19:36 +0000 X-Inumbo-ID: 1fe53b70-acc0-11ea-bb8b-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1fe53b70-acc0-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 15:19:36 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jjlSx-0005QE-9W; Fri, 12 Jun 2020 16:19:35 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [XEN PATCH for-4.14 0/2] tools: Update/reset autogenerated files Date: Fri, 12 Jun 2020 16:19:29 +0100 Message-Id: <20200612151931.1083-1-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <000401d640c9$7b14e760$713eb620$@xen.org> References: <000401d640c9$7b14e760$713eb620$@xen.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , ian.jackson@eu.citrix.com, Nick Rosbrook , Anthony PERARD , Samuel Thibault Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" We commit the output of autogen.sh, and the outputs of flex and bison, to help people without recent versions of the corresponding tools. Our usual practice hitherto has been to declare a version of Debian that we are tracking, and have committers run autogen.sh, or make -C tools/libxl clean && make -C tools/libxl all, on that version of Debian. Patches to osstest to detect violations of this rule would be welcome. After 4.14 we can perhaps revisit which of these files should be committed and how they should be managed. Ian Jackson (2): tools: Commit autoconf (2.69) output from Debian buster tools: Commit flex (2.6.4) & bison (3.3.2) output from Debian buster configure | 14 +- docs/configure | 14 +- stubdom/configure | 14 +- tools/configure | 24 +- tools/libxl/libxlu_cfg_l.c | 676 +++++++++++++++++++++++++------------ tools/libxl/libxlu_cfg_l.h | 471 +++++++++++++++++++++++--- tools/libxl/libxlu_cfg_y.c | 285 ++++++++-------- tools/libxl/libxlu_cfg_y.h | 12 +- 8 files changed, 1090 insertions(+), 420 deletions(-) -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:19:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:19:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlT9-0002Yv-Ti; Fri, 12 Jun 2020 15:19:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlT8-0002XL-Mx for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:19:46 +0000 X-Inumbo-ID: 22bc6026-acc0-11ea-8496-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 22bc6026-acc0-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 15:19:40 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jjlT1-0005QE-VF; Fri, 12 Jun 2020 16:19:40 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [XEN PATCH for-4.14 2/2] tools: Commit flex (2.6.4) & bison (3.3.2) output from Debian buster Date: Fri, 12 Jun 2020 16:19:31 +0100 Message-Id: <20200612151931.1083-3-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <000401d640c9$7b14e760$713eb620$@xen.org> References: <000401d640c9$7b14e760$713eb620$@xen.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Andrew Cooper , ian.jackson@eu.citrix.com, Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" These files are in tree so that people can build (including from git) without needing less-than-a-decade-old flex and bison. We should update them periodically. Debian buster has been Debian stable for a while. Our CI is running buster. There should be no significant functional change; it's possible that there are bugfixes but I have not reviewed the changes. I *have* checked that the flex I am using has the fix for CVE-2016-6354. CC: Paul Durrant CC: Andrew Cooper Signed-off-by: Ian Jackson --- tools/libxl/libxlu_cfg_l.c | 676 +++++++++++++++++++++++++------------ tools/libxl/libxlu_cfg_l.h | 471 +++++++++++++++++++++++--- tools/libxl/libxlu_cfg_y.c | 285 ++++++++-------- tools/libxl/libxlu_cfg_y.h | 12 +- 4 files changed, 1033 insertions(+), 411 deletions(-) diff --git a/tools/libxl/libxlu_cfg_l.c b/tools/libxl/libxlu_cfg_l.c index b82df00b4e..406b50a037 100644 --- a/tools/libxl/libxlu_cfg_l.c +++ b/tools/libxl/libxlu_cfg_l.c @@ -9,11 +9,245 @@ #define FLEX_SCANNER #define YY_FLEX_MAJOR_VERSION 2 #define YY_FLEX_MINOR_VERSION 6 -#define YY_FLEX_SUBMINOR_VERSION 1 +#define YY_FLEX_SUBMINOR_VERSION 4 #if YY_FLEX_SUBMINOR_VERSION > 0 #define FLEX_BETA #endif +#ifdef yy_create_buffer +#define xlu__cfg_yy_create_buffer_ALREADY_DEFINED +#else +#define yy_create_buffer xlu__cfg_yy_create_buffer +#endif + +#ifdef yy_delete_buffer +#define xlu__cfg_yy_delete_buffer_ALREADY_DEFINED +#else +#define yy_delete_buffer xlu__cfg_yy_delete_buffer +#endif + +#ifdef yy_scan_buffer +#define xlu__cfg_yy_scan_buffer_ALREADY_DEFINED +#else +#define yy_scan_buffer xlu__cfg_yy_scan_buffer +#endif + +#ifdef yy_scan_string +#define xlu__cfg_yy_scan_string_ALREADY_DEFINED +#else +#define yy_scan_string xlu__cfg_yy_scan_string +#endif + +#ifdef yy_scan_bytes +#define xlu__cfg_yy_scan_bytes_ALREADY_DEFINED +#else +#define yy_scan_bytes xlu__cfg_yy_scan_bytes +#endif + +#ifdef yy_init_buffer +#define xlu__cfg_yy_init_buffer_ALREADY_DEFINED +#else +#define yy_init_buffer xlu__cfg_yy_init_buffer +#endif + +#ifdef yy_flush_buffer +#define xlu__cfg_yy_flush_buffer_ALREADY_DEFINED +#else +#define yy_flush_buffer xlu__cfg_yy_flush_buffer +#endif + +#ifdef yy_load_buffer_state +#define xlu__cfg_yy_load_buffer_state_ALREADY_DEFINED +#else +#define yy_load_buffer_state xlu__cfg_yy_load_buffer_state +#endif + +#ifdef yy_switch_to_buffer +#define xlu__cfg_yy_switch_to_buffer_ALREADY_DEFINED +#else +#define yy_switch_to_buffer xlu__cfg_yy_switch_to_buffer +#endif + +#ifdef yypush_buffer_state +#define xlu__cfg_yypush_buffer_state_ALREADY_DEFINED +#else +#define yypush_buffer_state xlu__cfg_yypush_buffer_state +#endif + +#ifdef yypop_buffer_state +#define xlu__cfg_yypop_buffer_state_ALREADY_DEFINED +#else +#define yypop_buffer_state xlu__cfg_yypop_buffer_state +#endif + +#ifdef yyensure_buffer_stack +#define xlu__cfg_yyensure_buffer_stack_ALREADY_DEFINED +#else +#define yyensure_buffer_stack xlu__cfg_yyensure_buffer_stack +#endif + +#ifdef yylex +#define xlu__cfg_yylex_ALREADY_DEFINED +#else +#define yylex xlu__cfg_yylex +#endif + +#ifdef yyrestart +#define xlu__cfg_yyrestart_ALREADY_DEFINED +#else +#define yyrestart xlu__cfg_yyrestart +#endif + +#ifdef yylex_init +#define xlu__cfg_yylex_init_ALREADY_DEFINED +#else +#define yylex_init xlu__cfg_yylex_init +#endif + +#ifdef yylex_init_extra +#define xlu__cfg_yylex_init_extra_ALREADY_DEFINED +#else +#define yylex_init_extra xlu__cfg_yylex_init_extra +#endif + +#ifdef yylex_destroy +#define xlu__cfg_yylex_destroy_ALREADY_DEFINED +#else +#define yylex_destroy xlu__cfg_yylex_destroy +#endif + +#ifdef yyget_debug +#define xlu__cfg_yyget_debug_ALREADY_DEFINED +#else +#define yyget_debug xlu__cfg_yyget_debug +#endif + +#ifdef yyset_debug +#define xlu__cfg_yyset_debug_ALREADY_DEFINED +#else +#define yyset_debug xlu__cfg_yyset_debug +#endif + +#ifdef yyget_extra +#define xlu__cfg_yyget_extra_ALREADY_DEFINED +#else +#define yyget_extra xlu__cfg_yyget_extra +#endif + +#ifdef yyset_extra +#define xlu__cfg_yyset_extra_ALREADY_DEFINED +#else +#define yyset_extra xlu__cfg_yyset_extra +#endif + +#ifdef yyget_in +#define xlu__cfg_yyget_in_ALREADY_DEFINED +#else +#define yyget_in xlu__cfg_yyget_in +#endif + +#ifdef yyset_in +#define xlu__cfg_yyset_in_ALREADY_DEFINED +#else +#define yyset_in xlu__cfg_yyset_in +#endif + +#ifdef yyget_out +#define xlu__cfg_yyget_out_ALREADY_DEFINED +#else +#define yyget_out xlu__cfg_yyget_out +#endif + +#ifdef yyset_out +#define xlu__cfg_yyset_out_ALREADY_DEFINED +#else +#define yyset_out xlu__cfg_yyset_out +#endif + +#ifdef yyget_leng +#define xlu__cfg_yyget_leng_ALREADY_DEFINED +#else +#define yyget_leng xlu__cfg_yyget_leng +#endif + +#ifdef yyget_text +#define xlu__cfg_yyget_text_ALREADY_DEFINED +#else +#define yyget_text xlu__cfg_yyget_text +#endif + +#ifdef yyget_lineno +#define xlu__cfg_yyget_lineno_ALREADY_DEFINED +#else +#define yyget_lineno xlu__cfg_yyget_lineno +#endif + +#ifdef yyset_lineno +#define xlu__cfg_yyset_lineno_ALREADY_DEFINED +#else +#define yyset_lineno xlu__cfg_yyset_lineno +#endif + +#ifdef yyget_column +#define xlu__cfg_yyget_column_ALREADY_DEFINED +#else +#define yyget_column xlu__cfg_yyget_column +#endif + +#ifdef yyset_column +#define xlu__cfg_yyset_column_ALREADY_DEFINED +#else +#define yyset_column xlu__cfg_yyset_column +#endif + +#ifdef yywrap +#define xlu__cfg_yywrap_ALREADY_DEFINED +#else +#define yywrap xlu__cfg_yywrap +#endif + +#ifdef yyget_lval +#define xlu__cfg_yyget_lval_ALREADY_DEFINED +#else +#define yyget_lval xlu__cfg_yyget_lval +#endif + +#ifdef yyset_lval +#define xlu__cfg_yyset_lval_ALREADY_DEFINED +#else +#define yyset_lval xlu__cfg_yyset_lval +#endif + +#ifdef yyget_lloc +#define xlu__cfg_yyget_lloc_ALREADY_DEFINED +#else +#define yyget_lloc xlu__cfg_yyget_lloc +#endif + +#ifdef yyset_lloc +#define xlu__cfg_yyset_lloc_ALREADY_DEFINED +#else +#define yyset_lloc xlu__cfg_yyset_lloc +#endif + +#ifdef yyalloc +#define xlu__cfg_yyalloc_ALREADY_DEFINED +#else +#define yyalloc xlu__cfg_yyalloc +#endif + +#ifdef yyrealloc +#define xlu__cfg_yyrealloc_ALREADY_DEFINED +#else +#define yyrealloc xlu__cfg_yyrealloc +#endif + +#ifdef yyfree +#define xlu__cfg_yyfree_ALREADY_DEFINED +#else +#define yyfree xlu__cfg_yyfree +#endif + /* First, we deal with platform-specific or compiler-specific issues. */ /* begin standard C headers. */ @@ -84,10 +318,16 @@ typedef unsigned int flex_uint32_t; #define UINT32_MAX (4294967295U) #endif +#ifndef SIZE_MAX +#define SIZE_MAX (~(size_t)0) +#endif + #endif /* ! C99 */ #endif /* ! FLEXINT_H */ +/* begin standard C++ headers. */ + /* TODO: this is always defined, so inline it */ #define yyconst const @@ -100,12 +340,10 @@ typedef unsigned int flex_uint32_t; /* Returned upon end-of-file. */ #define YY_NULL 0 -/* Promotes a possibly negative, possibly signed char to an unsigned - * integer for use as an array index. If the signed char is negative, - * we want to instead treat it as an 8-bit unsigned char, hence the - * double cast. +/* Promotes a possibly negative, possibly signed char to an + * integer in range [0..255] for use as an array index. */ -#define YY_SC_TO_UI(c) ((unsigned int) (unsigned char) c) +#define YY_SC_TO_UI(c) ((YY_CHAR) (c)) /* An opaque pointer. */ #ifndef YY_TYPEDEF_YY_SCANNER_T @@ -129,20 +367,16 @@ typedef void* yyscan_t; * definition of BEGIN. */ #define BEGIN yyg->yy_start = 1 + 2 * - /* Translate the current start state into a value that can be later handed * to BEGIN to return to the state. The YYSTATE alias is for lex * compatibility. */ #define YY_START ((yyg->yy_start - 1) / 2) #define YYSTATE YY_START - /* Action number for EOF rule of a given start state. */ #define YY_STATE_EOF(state) (YY_END_OF_BUFFER + state + 1) - /* Special action meaning "start processing a new file". */ -#define YY_NEW_FILE xlu__cfg_yyrestart(yyin ,yyscanner ) - +#define YY_NEW_FILE yyrestart( yyin , yyscanner ) #define YY_END_OF_BUFFER_CHAR 0 /* Size of default input buffer. */ @@ -175,10 +409,10 @@ typedef size_t yy_size_t; #define EOB_ACT_CONTINUE_SCAN 0 #define EOB_ACT_END_OF_FILE 1 #define EOB_ACT_LAST_MATCH 2 - + /* Note: We specifically omit the test for yy_rule_can_match_eol because it requires * access to the local variable yy_act. Since yyless() is a macro, it would break - * existing scanners that call yyless() from OUTSIDE xlu__cfg_yylex. + * existing scanners that call yyless() from OUTSIDE yylex. * One obvious solution it to make yy_act a global. I tried that, and saw * a 5% performance hit in a non-yylineno scanner, because yy_act is * normally declared as a register variable-- so it is not worth it. @@ -211,7 +445,6 @@ typedef size_t yy_size_t; YY_DO_BEFORE_ACTION; /* set up yytext again */ \ } \ while ( 0 ) - #define unput(c) yyunput( c, yyg->yytext_ptr , yyscanner ) #ifndef YY_STRUCT_YY_BUFFER_STATE @@ -271,7 +504,7 @@ struct yy_buffer_state * possible backing-up. * * When we actually see the EOF, we change the status to "new" - * (via xlu__cfg_yyrestart()), so that the user can continue scanning by + * (via yyrestart()), so that the user can continue scanning by * just pointing yyin at a new input file. */ #define YY_BUFFER_EOF_PENDING 2 @@ -288,71 +521,65 @@ struct yy_buffer_state #define YY_CURRENT_BUFFER ( yyg->yy_buffer_stack \ ? yyg->yy_buffer_stack[yyg->yy_buffer_stack_top] \ : NULL) - /* Same as previous macro, but useful when we know that the buffer stack is not * NULL or when we need an lvalue. For internal use only. */ #define YY_CURRENT_BUFFER_LVALUE yyg->yy_buffer_stack[yyg->yy_buffer_stack_top] -void xlu__cfg_yyrestart (FILE *input_file ,yyscan_t yyscanner ); -void xlu__cfg_yy_switch_to_buffer (YY_BUFFER_STATE new_buffer ,yyscan_t yyscanner ); -YY_BUFFER_STATE xlu__cfg_yy_create_buffer (FILE *file,int size ,yyscan_t yyscanner ); -void xlu__cfg_yy_delete_buffer (YY_BUFFER_STATE b ,yyscan_t yyscanner ); -void xlu__cfg_yy_flush_buffer (YY_BUFFER_STATE b ,yyscan_t yyscanner ); -void xlu__cfg_yypush_buffer_state (YY_BUFFER_STATE new_buffer ,yyscan_t yyscanner ); -void xlu__cfg_yypop_buffer_state (yyscan_t yyscanner ); - -static void xlu__cfg_yyensure_buffer_stack (yyscan_t yyscanner ); -static void xlu__cfg_yy_load_buffer_state (yyscan_t yyscanner ); -static void xlu__cfg_yy_init_buffer (YY_BUFFER_STATE b,FILE *file ,yyscan_t yyscanner ); +void yyrestart ( FILE *input_file , yyscan_t yyscanner ); +void yy_switch_to_buffer ( YY_BUFFER_STATE new_buffer , yyscan_t yyscanner ); +YY_BUFFER_STATE yy_create_buffer ( FILE *file, int size , yyscan_t yyscanner ); +void yy_delete_buffer ( YY_BUFFER_STATE b , yyscan_t yyscanner ); +void yy_flush_buffer ( YY_BUFFER_STATE b , yyscan_t yyscanner ); +void yypush_buffer_state ( YY_BUFFER_STATE new_buffer , yyscan_t yyscanner ); +void yypop_buffer_state ( yyscan_t yyscanner ); -#define YY_FLUSH_BUFFER xlu__cfg_yy_flush_buffer(YY_CURRENT_BUFFER ,yyscanner) +static void yyensure_buffer_stack ( yyscan_t yyscanner ); +static void yy_load_buffer_state ( yyscan_t yyscanner ); +static void yy_init_buffer ( YY_BUFFER_STATE b, FILE *file , yyscan_t yyscanner ); +#define YY_FLUSH_BUFFER yy_flush_buffer( YY_CURRENT_BUFFER , yyscanner) -YY_BUFFER_STATE xlu__cfg_yy_scan_buffer (char *base,yy_size_t size ,yyscan_t yyscanner ); -YY_BUFFER_STATE xlu__cfg_yy_scan_string (yyconst char *yy_str ,yyscan_t yyscanner ); -YY_BUFFER_STATE xlu__cfg_yy_scan_bytes (yyconst char *bytes,int len ,yyscan_t yyscanner ); +YY_BUFFER_STATE yy_scan_buffer ( char *base, yy_size_t size , yyscan_t yyscanner ); +YY_BUFFER_STATE yy_scan_string ( const char *yy_str , yyscan_t yyscanner ); +YY_BUFFER_STATE yy_scan_bytes ( const char *bytes, int len , yyscan_t yyscanner ); -void *xlu__cfg_yyalloc (yy_size_t ,yyscan_t yyscanner ); -void *xlu__cfg_yyrealloc (void *,yy_size_t ,yyscan_t yyscanner ); -void xlu__cfg_yyfree (void * ,yyscan_t yyscanner ); - -#define yy_new_buffer xlu__cfg_yy_create_buffer +void *yyalloc ( yy_size_t , yyscan_t yyscanner ); +void *yyrealloc ( void *, yy_size_t , yyscan_t yyscanner ); +void yyfree ( void * , yyscan_t yyscanner ); +#define yy_new_buffer yy_create_buffer #define yy_set_interactive(is_interactive) \ { \ if ( ! YY_CURRENT_BUFFER ){ \ - xlu__cfg_yyensure_buffer_stack (yyscanner); \ + yyensure_buffer_stack (yyscanner); \ YY_CURRENT_BUFFER_LVALUE = \ - xlu__cfg_yy_create_buffer(yyin,YY_BUF_SIZE ,yyscanner); \ + yy_create_buffer( yyin, YY_BUF_SIZE , yyscanner); \ } \ YY_CURRENT_BUFFER_LVALUE->yy_is_interactive = is_interactive; \ } - #define yy_set_bol(at_bol) \ { \ if ( ! YY_CURRENT_BUFFER ){\ - xlu__cfg_yyensure_buffer_stack (yyscanner); \ + yyensure_buffer_stack (yyscanner); \ YY_CURRENT_BUFFER_LVALUE = \ - xlu__cfg_yy_create_buffer(yyin,YY_BUF_SIZE ,yyscanner); \ + yy_create_buffer( yyin, YY_BUF_SIZE , yyscanner); \ } \ YY_CURRENT_BUFFER_LVALUE->yy_at_bol = at_bol; \ } - #define YY_AT_BOL() (YY_CURRENT_BUFFER_LVALUE->yy_at_bol) #define xlu__cfg_yywrap(yyscanner) (/*CONSTCOND*/1) #define YY_SKIP_YYWRAP - -typedef unsigned char YY_CHAR; +typedef flex_uint8_t YY_CHAR; typedef int yy_state_type; #define yytext_ptr yytext_r -static yy_state_type yy_get_previous_state (yyscan_t yyscanner ); -static yy_state_type yy_try_NUL_trans (yy_state_type current_state ,yyscan_t yyscanner); -static int yy_get_next_buffer (yyscan_t yyscanner ); -static void yynoreturn yy_fatal_error (yyconst char* msg ,yyscan_t yyscanner ); +static yy_state_type yy_get_previous_state ( yyscan_t yyscanner ); +static yy_state_type yy_try_NUL_trans ( yy_state_type current_state , yyscan_t yyscanner); +static int yy_get_next_buffer ( yyscan_t yyscanner ); +static void yynoreturn yy_fatal_error ( const char* msg , yyscan_t yyscanner ); /* Done after the current pattern has been matched and before the * corresponding action - sets up yytext. @@ -364,7 +591,6 @@ static void yynoreturn yy_fatal_error (yyconst char* msg ,yyscan_t yyscanner ); yyg->yy_hold_char = *yy_cp; \ *yy_cp = '\0'; \ yyg->yy_c_buf_p = yy_cp; - #define YY_NUM_RULES 17 #define YY_END_OF_BUFFER 18 /* This struct is not used in this scanner, @@ -374,7 +600,7 @@ struct yy_trans_info flex_int32_t yy_verify; flex_int32_t yy_nxt; }; -static yyconst flex_int16_t yy_accept[37] = +static const flex_int16_t yy_accept[37] = { 0, 0, 0, 15, 15, 18, 14, 3, 10, 14, 14, 14, 13, 13, 4, 2, 9, 8, 5, 6, 1, @@ -382,7 +608,7 @@ static yyconst flex_int16_t yy_accept[37] = 0, 7, 2, 1, 15, 0 } ; -static yyconst YY_CHAR yy_ec[256] = +static const YY_CHAR yy_ec[256] = { 0, 1, 1, 1, 1, 1, 1, 1, 1, 2, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, @@ -414,13 +640,13 @@ static yyconst YY_CHAR yy_ec[256] = 1, 1, 1, 1, 1 } ; -static yyconst YY_CHAR yy_meta[20] = +static const YY_CHAR yy_meta[20] = { 0, 1, 2, 3, 1, 1, 1, 1, 1, 1, 4, 4, 1, 1, 1, 1, 1, 4, 4, 4 } ; -static yyconst flex_uint16_t yy_base[43] = +static const flex_int16_t yy_base[43] = { 0, 0, 0, 18, 20, 53, 59, 59, 59, 20, 42, 19, 59, 19, 59, 15, 59, 59, 59, 59, 0, @@ -429,7 +655,7 @@ static yyconst flex_uint16_t yy_base[43] = 26, 54 } ; -static yyconst flex_int16_t yy_def[43] = +static const flex_int16_t yy_def[43] = { 0, 36, 1, 37, 37, 36, 36, 36, 36, 38, 39, 40, 36, 36, 36, 36, 36, 36, 36, 36, 41, @@ -438,7 +664,7 @@ static yyconst flex_int16_t yy_def[43] = 36, 36 } ; -static yyconst flex_uint16_t yy_nxt[79] = +static const flex_int16_t yy_nxt[79] = { 0, 6, 7, 8, 9, 10, 11, 12, 13, 14, 12, 15, 16, 17, 18, 6, 19, 6, 20, 20, 22, @@ -450,7 +676,7 @@ static yyconst flex_uint16_t yy_nxt[79] = 36, 36, 36, 36, 36, 36, 36, 36 } ; -static yyconst flex_int16_t yy_chk[79] = +static const flex_int16_t yy_chk[79] = { 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, @@ -463,7 +689,7 @@ static yyconst flex_int16_t yy_chk[79] = } ; /* Table of booleans, true if rule could match eol. */ -static yyconst flex_int32_t yy_rule_can_match_eol[18] = +static const flex_int32_t yy_rule_can_match_eol[18] = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 0, }; @@ -510,8 +736,9 @@ static yyconst flex_int32_t yy_rule_can_match_eol[18] = int xlu__cfg_yyget_column(yyscan_t yyscanner); void xlu__cfg_yyset_column(int column_no, yyscan_t yyscanner); +#line 740 "libxlu_cfg_l.c" -#line 515 "libxlu_cfg_l.c" +#line 742 "libxlu_cfg_l.c" #define INITIAL 0 #define lexerr 1 @@ -566,7 +793,7 @@ struct yyguts_t }; /* end struct yyguts_t */ -static int yy_init_globals (yyscan_t yyscanner ); +static int yy_init_globals ( yyscan_t yyscanner ); /* This must go here because YYSTYPE and YYLTYPE are included * from bison output in section 1.*/ @@ -574,50 +801,50 @@ static int yy_init_globals (yyscan_t yyscanner ); # define yylloc yyg->yylloc_r -int xlu__cfg_yylex_init (yyscan_t* scanner); +int yylex_init (yyscan_t* scanner); -int xlu__cfg_yylex_init_extra (YY_EXTRA_TYPE user_defined,yyscan_t* scanner); +int yylex_init_extra ( YY_EXTRA_TYPE user_defined, yyscan_t* scanner); /* Accessor methods to globals. These are made visible to non-reentrant scanners for convenience. */ -int xlu__cfg_yylex_destroy (yyscan_t yyscanner ); +int yylex_destroy ( yyscan_t yyscanner ); -int xlu__cfg_yyget_debug (yyscan_t yyscanner ); +int yyget_debug ( yyscan_t yyscanner ); -void xlu__cfg_yyset_debug (int debug_flag ,yyscan_t yyscanner ); +void yyset_debug ( int debug_flag , yyscan_t yyscanner ); -YY_EXTRA_TYPE xlu__cfg_yyget_extra (yyscan_t yyscanner ); +YY_EXTRA_TYPE yyget_extra ( yyscan_t yyscanner ); -void xlu__cfg_yyset_extra (YY_EXTRA_TYPE user_defined ,yyscan_t yyscanner ); +void yyset_extra ( YY_EXTRA_TYPE user_defined , yyscan_t yyscanner ); -FILE *xlu__cfg_yyget_in (yyscan_t yyscanner ); +FILE *yyget_in ( yyscan_t yyscanner ); -void xlu__cfg_yyset_in (FILE * _in_str ,yyscan_t yyscanner ); +void yyset_in ( FILE * _in_str , yyscan_t yyscanner ); -FILE *xlu__cfg_yyget_out (yyscan_t yyscanner ); +FILE *yyget_out ( yyscan_t yyscanner ); -void xlu__cfg_yyset_out (FILE * _out_str ,yyscan_t yyscanner ); +void yyset_out ( FILE * _out_str , yyscan_t yyscanner ); - int xlu__cfg_yyget_leng (yyscan_t yyscanner ); + int yyget_leng ( yyscan_t yyscanner ); -char *xlu__cfg_yyget_text (yyscan_t yyscanner ); +char *yyget_text ( yyscan_t yyscanner ); -int xlu__cfg_yyget_lineno (yyscan_t yyscanner ); +int yyget_lineno ( yyscan_t yyscanner ); -void xlu__cfg_yyset_lineno (int _line_number ,yyscan_t yyscanner ); +void yyset_lineno ( int _line_number , yyscan_t yyscanner ); -int xlu__cfg_yyget_column (yyscan_t yyscanner ); +int yyget_column ( yyscan_t yyscanner ); -void xlu__cfg_yyset_column (int _column_no ,yyscan_t yyscanner ); +void yyset_column ( int _column_no , yyscan_t yyscanner ); -YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner ); +YYSTYPE * yyget_lval ( yyscan_t yyscanner ); -void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner ); +void yyset_lval ( YYSTYPE * yylval_param , yyscan_t yyscanner ); - YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner ); + YYLTYPE *yyget_lloc ( yyscan_t yyscanner ); - void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param ,yyscan_t yyscanner ); + void yyset_lloc ( YYLTYPE * yylloc_param , yyscan_t yyscanner ); /* Macros after this point can all be overridden by user definitions in * section 1. @@ -625,9 +852,9 @@ void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner ); #ifndef YY_SKIP_YYWRAP #ifdef __cplusplus -extern "C" int xlu__cfg_yywrap (yyscan_t yyscanner ); +extern "C" int yywrap ( yyscan_t yyscanner ); #else -extern int xlu__cfg_yywrap (yyscan_t yyscanner ); +extern int yywrap ( yyscan_t yyscanner ); #endif #endif @@ -636,19 +863,18 @@ extern int xlu__cfg_yywrap (yyscan_t yyscanner ); #endif #ifndef yytext_ptr -static void yy_flex_strncpy (char *,yyconst char *,int ,yyscan_t yyscanner); +static void yy_flex_strncpy ( char *, const char *, int , yyscan_t yyscanner); #endif #ifdef YY_NEED_STRLEN -static int yy_flex_strlen (yyconst char * ,yyscan_t yyscanner); +static int yy_flex_strlen ( const char * , yyscan_t yyscanner); #endif #ifndef YY_NO_INPUT - #ifdef __cplusplus -static int yyinput (yyscan_t yyscanner ); +static int yyinput ( yyscan_t yyscanner ); #else -static int input (yyscan_t yyscanner ); +static int input ( yyscan_t yyscanner ); #endif #endif @@ -679,7 +905,7 @@ static int input (yyscan_t yyscanner ); if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \ { \ int c = '*'; \ - size_t n; \ + int n; \ for ( n = 0; n < max_size && \ (c = getc( yyin )) != EOF && c != '\n'; ++n ) \ buf[n] = (char) c; \ @@ -692,7 +918,7 @@ static int input (yyscan_t yyscanner ); else \ { \ errno=0; \ - while ( (result = (int) fread(buf, 1, max_size, yyin))==0 && ferror(yyin)) \ + while ( (result = (int) fread(buf, 1, (yy_size_t) max_size, yyin)) == 0 && ferror(yyin)) \ { \ if( errno != EINTR) \ { \ @@ -733,10 +959,10 @@ static int input (yyscan_t yyscanner ); #ifndef YY_DECL #define YY_DECL_IS_OURS 1 -extern int xlu__cfg_yylex \ - (YYSTYPE * yylval_param,YYLTYPE * yylloc_param ,yyscan_t yyscanner); +extern int yylex \ + (YYSTYPE * yylval_param, YYLTYPE * yylloc_param , yyscan_t yyscanner); -#define YY_DECL int xlu__cfg_yylex \ +#define YY_DECL int yylex \ (YYSTYPE * yylval_param, YYLTYPE * yylloc_param , yyscan_t yyscanner) #endif /* !YY_DECL */ @@ -786,26 +1012,26 @@ YY_DECL yyout = stdout; if ( ! YY_CURRENT_BUFFER ) { - xlu__cfg_yyensure_buffer_stack (yyscanner); + yyensure_buffer_stack (yyscanner); YY_CURRENT_BUFFER_LVALUE = - xlu__cfg_yy_create_buffer(yyin,YY_BUF_SIZE ,yyscanner); + yy_create_buffer( yyin, YY_BUF_SIZE , yyscanner); } - xlu__cfg_yy_load_buffer_state(yyscanner ); + yy_load_buffer_state( yyscanner ); } { #line 53 "libxlu_cfg_l.l" -#line 802 "libxlu_cfg_l.c" +#line 1028 "libxlu_cfg_l.c" while ( /*CONSTCOND*/1 ) /* loops until end-of-file is reached */ { yyg->yy_more_len = 0; if ( yyg->yy_more_flag ) { - yyg->yy_more_len = yyg->yy_c_buf_p - yyg->yytext_ptr; + yyg->yy_more_len = (int) (yyg->yy_c_buf_p - yyg->yytext_ptr); yyg->yy_more_flag = 0; } yy_cp = yyg->yy_c_buf_p; @@ -832,9 +1058,9 @@ yy_match: { yy_current_state = (int) yy_def[yy_current_state]; if ( yy_current_state >= 37 ) - yy_c = yy_meta[(unsigned int) yy_c]; + yy_c = yy_meta[yy_c]; } - yy_current_state = yy_nxt[yy_base[yy_current_state] + (flex_int16_t) yy_c]; + yy_current_state = yy_nxt[yy_base[yy_current_state] + yy_c]; ++yy_cp; } while ( yy_current_state != 36 ); @@ -982,7 +1208,7 @@ YY_RULE_SETUP #line 105 "libxlu_cfg_l.l" YY_FATAL_ERROR( "flex scanner jammed" ); YY_BREAK -#line 986 "libxlu_cfg_l.c" +#line 1212 "libxlu_cfg_l.c" case YY_STATE_EOF(INITIAL): case YY_STATE_EOF(lexerr): yyterminate(); @@ -1001,7 +1227,7 @@ case YY_STATE_EOF(lexerr): /* We're scanning a new file or input source. It's * possible that this happened because the user * just pointed yyin at a new source and called - * xlu__cfg_yylex(). If so, then we have to assure + * yylex(). If so, then we have to assure * consistency between YY_CURRENT_BUFFER and our * globals. Here is the right place to do so, because * this is the first action (other than possibly a @@ -1062,7 +1288,7 @@ case YY_STATE_EOF(lexerr): { yyg->yy_did_buffer_switch_on_eof = 0; - if ( xlu__cfg_yywrap(yyscanner ) ) + if ( yywrap( yyscanner ) ) { /* Note: because we've taken care in * yy_get_next_buffer() to have set up @@ -1116,7 +1342,7 @@ case YY_STATE_EOF(lexerr): } /* end of action switch */ } /* end of scanning one token */ } /* end of user's declarations */ -} /* end of xlu__cfg_yylex */ +} /* end of yylex */ /* yy_get_next_buffer - try to read in a new buffer * @@ -1195,7 +1421,8 @@ static int yy_get_next_buffer (yyscan_t yyscanner) b->yy_ch_buf = (char *) /* Include room in for 2 EOB chars. */ - xlu__cfg_yyrealloc((void *) b->yy_ch_buf,b->yy_buf_size + 2 ,yyscanner ); + yyrealloc( (void *) b->yy_ch_buf, + (yy_size_t) (b->yy_buf_size + 2) , yyscanner ); } else /* Can't grow it, we don't own it. */ @@ -1227,7 +1454,7 @@ static int yy_get_next_buffer (yyscan_t yyscanner) if ( number_to_move == YY_MORE_ADJ ) { ret_val = EOB_ACT_END_OF_FILE; - xlu__cfg_yyrestart(yyin ,yyscanner); + yyrestart( yyin , yyscanner); } else @@ -1244,9 +1471,12 @@ static int yy_get_next_buffer (yyscan_t yyscanner) if ((yyg->yy_n_chars + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) { /* Extend the array by 50%, plus the number we really need. */ int new_size = yyg->yy_n_chars + number_to_move + (yyg->yy_n_chars >> 1); - YY_CURRENT_BUFFER_LVALUE->yy_ch_buf = (char *) xlu__cfg_yyrealloc((void *) YY_CURRENT_BUFFER_LVALUE->yy_ch_buf,new_size ,yyscanner ); + YY_CURRENT_BUFFER_LVALUE->yy_ch_buf = (char *) yyrealloc( + (void *) YY_CURRENT_BUFFER_LVALUE->yy_ch_buf, (yy_size_t) new_size , yyscanner ); if ( ! YY_CURRENT_BUFFER_LVALUE->yy_ch_buf ) YY_FATAL_ERROR( "out of dynamic memory in yy_get_next_buffer()" ); + /* "- 2" to take care of EOB's */ + YY_CURRENT_BUFFER_LVALUE->yy_buf_size = (int) (new_size - 2); } yyg->yy_n_chars += number_to_move; @@ -1280,9 +1510,9 @@ static int yy_get_next_buffer (yyscan_t yyscanner) { yy_current_state = (int) yy_def[yy_current_state]; if ( yy_current_state >= 37 ) - yy_c = yy_meta[(unsigned int) yy_c]; + yy_c = yy_meta[yy_c]; } - yy_current_state = yy_nxt[yy_base[yy_current_state] + (flex_int16_t) yy_c]; + yy_current_state = yy_nxt[yy_base[yy_current_state] + yy_c]; } return yy_current_state; @@ -1309,9 +1539,9 @@ static int yy_get_next_buffer (yyscan_t yyscanner) { yy_current_state = (int) yy_def[yy_current_state]; if ( yy_current_state >= 37 ) - yy_c = yy_meta[(unsigned int) yy_c]; + yy_c = yy_meta[yy_c]; } - yy_current_state = yy_nxt[yy_base[yy_current_state] + (flex_int16_t) yy_c]; + yy_current_state = yy_nxt[yy_base[yy_current_state] + yy_c]; yy_is_jam = (yy_current_state == 36); (void)yyg; @@ -1347,7 +1577,7 @@ static int yy_get_next_buffer (yyscan_t yyscanner) else { /* need more input */ - int offset = yyg->yy_c_buf_p - yyg->yytext_ptr; + int offset = (int) (yyg->yy_c_buf_p - yyg->yytext_ptr); ++yyg->yy_c_buf_p; switch ( yy_get_next_buffer( yyscanner ) ) @@ -1364,13 +1594,13 @@ static int yy_get_next_buffer (yyscan_t yyscanner) */ /* Reset buffer status. */ - xlu__cfg_yyrestart(yyin ,yyscanner); + yyrestart( yyin , yyscanner); /*FALLTHROUGH*/ case EOB_ACT_END_OF_FILE: { - if ( xlu__cfg_yywrap(yyscanner ) ) + if ( yywrap( yyscanner ) ) return 0; if ( ! yyg->yy_did_buffer_switch_on_eof ) @@ -1409,34 +1639,34 @@ static int yy_get_next_buffer (yyscan_t yyscanner) * @param yyscanner The scanner object. * @note This function does not reset the start condition to @c INITIAL . */ - void xlu__cfg_yyrestart (FILE * input_file , yyscan_t yyscanner) + void yyrestart (FILE * input_file , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; if ( ! YY_CURRENT_BUFFER ){ - xlu__cfg_yyensure_buffer_stack (yyscanner); + yyensure_buffer_stack (yyscanner); YY_CURRENT_BUFFER_LVALUE = - xlu__cfg_yy_create_buffer(yyin,YY_BUF_SIZE ,yyscanner); + yy_create_buffer( yyin, YY_BUF_SIZE , yyscanner); } - xlu__cfg_yy_init_buffer(YY_CURRENT_BUFFER,input_file ,yyscanner); - xlu__cfg_yy_load_buffer_state(yyscanner ); + yy_init_buffer( YY_CURRENT_BUFFER, input_file , yyscanner); + yy_load_buffer_state( yyscanner ); } /** Switch to a different input buffer. * @param new_buffer The new input buffer. * @param yyscanner The scanner object. */ - void xlu__cfg_yy_switch_to_buffer (YY_BUFFER_STATE new_buffer , yyscan_t yyscanner) + void yy_switch_to_buffer (YY_BUFFER_STATE new_buffer , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* TODO. We should be able to replace this entire function body * with - * xlu__cfg_yypop_buffer_state(); - * xlu__cfg_yypush_buffer_state(new_buffer); + * yypop_buffer_state(); + * yypush_buffer_state(new_buffer); */ - xlu__cfg_yyensure_buffer_stack (yyscanner); + yyensure_buffer_stack (yyscanner); if ( YY_CURRENT_BUFFER == new_buffer ) return; @@ -1449,17 +1679,17 @@ static int yy_get_next_buffer (yyscan_t yyscanner) } YY_CURRENT_BUFFER_LVALUE = new_buffer; - xlu__cfg_yy_load_buffer_state(yyscanner ); + yy_load_buffer_state( yyscanner ); /* We don't actually know whether we did this switch during - * EOF (xlu__cfg_yywrap()) processing, but the only time this flag - * is looked at is after xlu__cfg_yywrap() is called, so it's safe + * EOF (yywrap()) processing, but the only time this flag + * is looked at is after yywrap() is called, so it's safe * to go ahead and always set it. */ yyg->yy_did_buffer_switch_on_eof = 1; } -static void xlu__cfg_yy_load_buffer_state (yyscan_t yyscanner) +static void yy_load_buffer_state (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; yyg->yy_n_chars = YY_CURRENT_BUFFER_LVALUE->yy_n_chars; @@ -1474,35 +1704,35 @@ static void xlu__cfg_yy_load_buffer_state (yyscan_t yyscanner) * @param yyscanner The scanner object. * @return the allocated buffer state. */ - YY_BUFFER_STATE xlu__cfg_yy_create_buffer (FILE * file, int size , yyscan_t yyscanner) + YY_BUFFER_STATE yy_create_buffer (FILE * file, int size , yyscan_t yyscanner) { YY_BUFFER_STATE b; - b = (YY_BUFFER_STATE) xlu__cfg_yyalloc(sizeof( struct yy_buffer_state ) ,yyscanner ); + b = (YY_BUFFER_STATE) yyalloc( sizeof( struct yy_buffer_state ) , yyscanner ); if ( ! b ) - YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yy_create_buffer()" ); + YY_FATAL_ERROR( "out of dynamic memory in yy_create_buffer()" ); - b->yy_buf_size = (yy_size_t)size; + b->yy_buf_size = size; /* yy_ch_buf has to be 2 characters longer than the size given because * we need to put in 2 end-of-buffer characters. */ - b->yy_ch_buf = (char *) xlu__cfg_yyalloc(b->yy_buf_size + 2 ,yyscanner ); + b->yy_ch_buf = (char *) yyalloc( (yy_size_t) (b->yy_buf_size + 2) , yyscanner ); if ( ! b->yy_ch_buf ) - YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yy_create_buffer()" ); + YY_FATAL_ERROR( "out of dynamic memory in yy_create_buffer()" ); b->yy_is_our_buffer = 1; - xlu__cfg_yy_init_buffer(b,file ,yyscanner); + yy_init_buffer( b, file , yyscanner); return b; } /** Destroy the buffer. - * @param b a buffer created with xlu__cfg_yy_create_buffer() + * @param b a buffer created with yy_create_buffer() * @param yyscanner The scanner object. */ - void xlu__cfg_yy_delete_buffer (YY_BUFFER_STATE b , yyscan_t yyscanner) + void yy_delete_buffer (YY_BUFFER_STATE b , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; @@ -1513,28 +1743,28 @@ static void xlu__cfg_yy_load_buffer_state (yyscan_t yyscanner) YY_CURRENT_BUFFER_LVALUE = (YY_BUFFER_STATE) 0; if ( b->yy_is_our_buffer ) - xlu__cfg_yyfree((void *) b->yy_ch_buf ,yyscanner ); + yyfree( (void *) b->yy_ch_buf , yyscanner ); - xlu__cfg_yyfree((void *) b ,yyscanner ); + yyfree( (void *) b , yyscanner ); } /* Initializes or reinitializes a buffer. * This function is sometimes called more than once on the same buffer, - * such as during a xlu__cfg_yyrestart() or at EOF. + * such as during a yyrestart() or at EOF. */ - static void xlu__cfg_yy_init_buffer (YY_BUFFER_STATE b, FILE * file , yyscan_t yyscanner) + static void yy_init_buffer (YY_BUFFER_STATE b, FILE * file , yyscan_t yyscanner) { int oerrno = errno; struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; - xlu__cfg_yy_flush_buffer(b ,yyscanner); + yy_flush_buffer( b , yyscanner); b->yy_input_file = file; b->yy_fill_buffer = 1; - /* If b is the current buffer, then xlu__cfg_yy_init_buffer was _probably_ - * called from xlu__cfg_yyrestart() or through yy_get_next_buffer. + /* If b is the current buffer, then yy_init_buffer was _probably_ + * called from yyrestart() or through yy_get_next_buffer. * In that case, we don't want to reset the lineno or column. */ if (b != YY_CURRENT_BUFFER){ @@ -1551,7 +1781,7 @@ static void xlu__cfg_yy_load_buffer_state (yyscan_t yyscanner) * @param b the buffer state to be flushed, usually @c YY_CURRENT_BUFFER. * @param yyscanner The scanner object. */ - void xlu__cfg_yy_flush_buffer (YY_BUFFER_STATE b , yyscan_t yyscanner) + void yy_flush_buffer (YY_BUFFER_STATE b , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; if ( ! b ) @@ -1572,7 +1802,7 @@ static void xlu__cfg_yy_load_buffer_state (yyscan_t yyscanner) b->yy_buffer_status = YY_BUFFER_NEW; if ( b == YY_CURRENT_BUFFER ) - xlu__cfg_yy_load_buffer_state(yyscanner ); + yy_load_buffer_state( yyscanner ); } /** Pushes the new state onto the stack. The new state becomes @@ -1581,15 +1811,15 @@ static void xlu__cfg_yy_load_buffer_state (yyscan_t yyscanner) * @param new_buffer The new state. * @param yyscanner The scanner object. */ -void xlu__cfg_yypush_buffer_state (YY_BUFFER_STATE new_buffer , yyscan_t yyscanner) +void yypush_buffer_state (YY_BUFFER_STATE new_buffer , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; if (new_buffer == NULL) return; - xlu__cfg_yyensure_buffer_stack(yyscanner); + yyensure_buffer_stack(yyscanner); - /* This block is copied from xlu__cfg_yy_switch_to_buffer. */ + /* This block is copied from yy_switch_to_buffer. */ if ( YY_CURRENT_BUFFER ) { /* Flush out information for old buffer. */ @@ -1603,8 +1833,8 @@ void xlu__cfg_yypush_buffer_state (YY_BUFFER_STATE new_buffer , yyscan_t yyscann yyg->yy_buffer_stack_top++; YY_CURRENT_BUFFER_LVALUE = new_buffer; - /* copied from xlu__cfg_yy_switch_to_buffer. */ - xlu__cfg_yy_load_buffer_state(yyscanner ); + /* copied from yy_switch_to_buffer. */ + yy_load_buffer_state( yyscanner ); yyg->yy_did_buffer_switch_on_eof = 1; } @@ -1612,19 +1842,19 @@ void xlu__cfg_yypush_buffer_state (YY_BUFFER_STATE new_buffer , yyscan_t yyscann * The next element becomes the new top. * @param yyscanner The scanner object. */ -void xlu__cfg_yypop_buffer_state (yyscan_t yyscanner) +void yypop_buffer_state (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; if (!YY_CURRENT_BUFFER) return; - xlu__cfg_yy_delete_buffer(YY_CURRENT_BUFFER ,yyscanner); + yy_delete_buffer(YY_CURRENT_BUFFER , yyscanner); YY_CURRENT_BUFFER_LVALUE = NULL; if (yyg->yy_buffer_stack_top > 0) --yyg->yy_buffer_stack_top; if (YY_CURRENT_BUFFER) { - xlu__cfg_yy_load_buffer_state(yyscanner ); + yy_load_buffer_state( yyscanner ); yyg->yy_did_buffer_switch_on_eof = 1; } } @@ -1632,9 +1862,9 @@ void xlu__cfg_yypop_buffer_state (yyscan_t yyscanner) /* Allocates the stack if it does not exist. * Guarantees space for at least one push. */ -static void xlu__cfg_yyensure_buffer_stack (yyscan_t yyscanner) +static void yyensure_buffer_stack (yyscan_t yyscanner) { - int num_to_alloc; + yy_size_t num_to_alloc; struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; if (!yyg->yy_buffer_stack) { @@ -1644,11 +1874,11 @@ static void xlu__cfg_yyensure_buffer_stack (yyscan_t yyscanner) * immediate realloc on the next call. */ num_to_alloc = 1; /* After all that talk, this was set to 1 anyways... */ - yyg->yy_buffer_stack = (struct yy_buffer_state**)xlu__cfg_yyalloc + yyg->yy_buffer_stack = (struct yy_buffer_state**)yyalloc (num_to_alloc * sizeof(struct yy_buffer_state*) , yyscanner); if ( ! yyg->yy_buffer_stack ) - YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yyensure_buffer_stack()" ); + YY_FATAL_ERROR( "out of dynamic memory in yyensure_buffer_stack()" ); memset(yyg->yy_buffer_stack, 0, num_to_alloc * sizeof(struct yy_buffer_state*)); @@ -1663,12 +1893,12 @@ static void xlu__cfg_yyensure_buffer_stack (yyscan_t yyscanner) yy_size_t grow_size = 8 /* arbitrary grow size */; num_to_alloc = yyg->yy_buffer_stack_max + grow_size; - yyg->yy_buffer_stack = (struct yy_buffer_state**)xlu__cfg_yyrealloc + yyg->yy_buffer_stack = (struct yy_buffer_state**)yyrealloc (yyg->yy_buffer_stack, num_to_alloc * sizeof(struct yy_buffer_state*) , yyscanner); if ( ! yyg->yy_buffer_stack ) - YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yyensure_buffer_stack()" ); + YY_FATAL_ERROR( "out of dynamic memory in yyensure_buffer_stack()" ); /* zero only the new slots.*/ memset(yyg->yy_buffer_stack + yyg->yy_buffer_stack_max, 0, grow_size * sizeof(struct yy_buffer_state*)); @@ -1682,7 +1912,7 @@ static void xlu__cfg_yyensure_buffer_stack (yyscan_t yyscanner) * @param yyscanner The scanner object. * @return the newly allocated buffer state object. */ -YY_BUFFER_STATE xlu__cfg_yy_scan_buffer (char * base, yy_size_t size , yyscan_t yyscanner) +YY_BUFFER_STATE yy_scan_buffer (char * base, yy_size_t size , yyscan_t yyscanner) { YY_BUFFER_STATE b; @@ -1692,11 +1922,11 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_buffer (char * base, yy_size_t size , yyscan_ /* They forgot to leave room for the EOB's. */ return NULL; - b = (YY_BUFFER_STATE) xlu__cfg_yyalloc(sizeof( struct yy_buffer_state ) ,yyscanner ); + b = (YY_BUFFER_STATE) yyalloc( sizeof( struct yy_buffer_state ) , yyscanner ); if ( ! b ) - YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yy_scan_buffer()" ); + YY_FATAL_ERROR( "out of dynamic memory in yy_scan_buffer()" ); - b->yy_buf_size = size - 2; /* "- 2" to take care of EOB's */ + b->yy_buf_size = (int) (size - 2); /* "- 2" to take care of EOB's */ b->yy_buf_pos = b->yy_ch_buf = base; b->yy_is_our_buffer = 0; b->yy_input_file = NULL; @@ -1706,33 +1936,33 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_buffer (char * base, yy_size_t size , yyscan_ b->yy_fill_buffer = 0; b->yy_buffer_status = YY_BUFFER_NEW; - xlu__cfg_yy_switch_to_buffer(b ,yyscanner ); + yy_switch_to_buffer( b , yyscanner ); return b; } -/** Setup the input buffer state to scan a string. The next call to xlu__cfg_yylex() will +/** Setup the input buffer state to scan a string. The next call to yylex() will * scan from a @e copy of @a str. * @param yystr a NUL-terminated string to scan * @param yyscanner The scanner object. * @return the newly allocated buffer state object. * @note If you want to scan bytes that may contain NUL values, then use - * xlu__cfg_yy_scan_bytes() instead. + * yy_scan_bytes() instead. */ -YY_BUFFER_STATE xlu__cfg_yy_scan_string (yyconst char * yystr , yyscan_t yyscanner) +YY_BUFFER_STATE yy_scan_string (const char * yystr , yyscan_t yyscanner) { - return xlu__cfg_yy_scan_bytes(yystr,(int) strlen(yystr) ,yyscanner); + return yy_scan_bytes( yystr, (int) strlen(yystr) , yyscanner); } -/** Setup the input buffer state to scan the given bytes. The next call to xlu__cfg_yylex() will +/** Setup the input buffer state to scan the given bytes. The next call to yylex() will * scan from a @e copy of @a bytes. * @param yybytes the byte buffer to scan * @param _yybytes_len the number of bytes in the buffer pointed to by @a bytes. * @param yyscanner The scanner object. * @return the newly allocated buffer state object. */ -YY_BUFFER_STATE xlu__cfg_yy_scan_bytes (yyconst char * yybytes, int _yybytes_len , yyscan_t yyscanner) +YY_BUFFER_STATE yy_scan_bytes (const char * yybytes, int _yybytes_len , yyscan_t yyscanner) { YY_BUFFER_STATE b; char *buf; @@ -1741,18 +1971,18 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_bytes (yyconst char * yybytes, int _yybytes_l /* Get memory for full buffer, including space for trailing EOB's. */ n = (yy_size_t) (_yybytes_len + 2); - buf = (char *) xlu__cfg_yyalloc(n ,yyscanner ); + buf = (char *) yyalloc( n , yyscanner ); if ( ! buf ) - YY_FATAL_ERROR( "out of dynamic memory in xlu__cfg_yy_scan_bytes()" ); + YY_FATAL_ERROR( "out of dynamic memory in yy_scan_bytes()" ); for ( i = 0; i < _yybytes_len; ++i ) buf[i] = yybytes[i]; buf[_yybytes_len] = buf[_yybytes_len+1] = YY_END_OF_BUFFER_CHAR; - b = xlu__cfg_yy_scan_buffer(buf,n ,yyscanner); + b = yy_scan_buffer( buf, n , yyscanner); if ( ! b ) - YY_FATAL_ERROR( "bad buffer in xlu__cfg_yy_scan_bytes()" ); + YY_FATAL_ERROR( "bad buffer in yy_scan_bytes()" ); /* It's okay to grow etc. this buffer, and we should throw it * away when we're done. @@ -1766,11 +1996,11 @@ YY_BUFFER_STATE xlu__cfg_yy_scan_bytes (yyconst char * yybytes, int _yybytes_l #define YY_EXIT_FAILURE 2 #endif -static void yynoreturn yy_fatal_error (yyconst char* msg , yyscan_t yyscanner) +static void yynoreturn yy_fatal_error (const char* msg , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; (void)yyg; - (void) fprintf( stderr, "%s\n", msg ); + fprintf( stderr, "%s\n", msg ); exit( YY_EXIT_FAILURE ); } @@ -1796,7 +2026,7 @@ static void yynoreturn yy_fatal_error (yyconst char* msg , yyscan_t yyscanner) /** Get the user-defined data for this scanner. * @param yyscanner The scanner object. */ -YY_EXTRA_TYPE xlu__cfg_yyget_extra (yyscan_t yyscanner) +YY_EXTRA_TYPE yyget_extra (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; return yyextra; @@ -1805,7 +2035,7 @@ YY_EXTRA_TYPE xlu__cfg_yyget_extra (yyscan_t yyscanner) /** Get the current line number. * @param yyscanner The scanner object. */ -int xlu__cfg_yyget_lineno (yyscan_t yyscanner) +int yyget_lineno (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; @@ -1818,7 +2048,7 @@ int xlu__cfg_yyget_lineno (yyscan_t yyscanner) /** Get the current column number. * @param yyscanner The scanner object. */ -int xlu__cfg_yyget_column (yyscan_t yyscanner) +int yyget_column (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; @@ -1831,7 +2061,7 @@ int xlu__cfg_yyget_column (yyscan_t yyscanner) /** Get the input stream. * @param yyscanner The scanner object. */ -FILE *xlu__cfg_yyget_in (yyscan_t yyscanner) +FILE *yyget_in (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; return yyin; @@ -1840,7 +2070,7 @@ FILE *xlu__cfg_yyget_in (yyscan_t yyscanner) /** Get the output stream. * @param yyscanner The scanner object. */ -FILE *xlu__cfg_yyget_out (yyscan_t yyscanner) +FILE *yyget_out (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; return yyout; @@ -1849,7 +2079,7 @@ FILE *xlu__cfg_yyget_out (yyscan_t yyscanner) /** Get the length of the current token. * @param yyscanner The scanner object. */ -int xlu__cfg_yyget_leng (yyscan_t yyscanner) +int yyget_leng (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; return yyleng; @@ -1859,7 +2089,7 @@ int xlu__cfg_yyget_leng (yyscan_t yyscanner) * @param yyscanner The scanner object. */ -char *xlu__cfg_yyget_text (yyscan_t yyscanner) +char *yyget_text (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; return yytext; @@ -1869,7 +2099,7 @@ char *xlu__cfg_yyget_text (yyscan_t yyscanner) * @param user_defined The data to be associated with this scanner. * @param yyscanner The scanner object. */ -void xlu__cfg_yyset_extra (YY_EXTRA_TYPE user_defined , yyscan_t yyscanner) +void yyset_extra (YY_EXTRA_TYPE user_defined , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; yyextra = user_defined ; @@ -1879,13 +2109,13 @@ void xlu__cfg_yyset_extra (YY_EXTRA_TYPE user_defined , yyscan_t yyscanner) * @param _line_number line number * @param yyscanner The scanner object. */ -void xlu__cfg_yyset_lineno (int _line_number , yyscan_t yyscanner) +void yyset_lineno (int _line_number , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* lineno is only valid if an input buffer exists. */ if (! YY_CURRENT_BUFFER ) - YY_FATAL_ERROR( "xlu__cfg_yyset_lineno called with no buffer" ); + YY_FATAL_ERROR( "yyset_lineno called with no buffer" ); yylineno = _line_number; } @@ -1894,13 +2124,13 @@ void xlu__cfg_yyset_lineno (int _line_number , yyscan_t yyscanner) * @param _column_no column number * @param yyscanner The scanner object. */ -void xlu__cfg_yyset_column (int _column_no , yyscan_t yyscanner) +void yyset_column (int _column_no , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* column is only valid if an input buffer exists. */ if (! YY_CURRENT_BUFFER ) - YY_FATAL_ERROR( "xlu__cfg_yyset_column called with no buffer" ); + YY_FATAL_ERROR( "yyset_column called with no buffer" ); yycolumn = _column_no; } @@ -1909,27 +2139,27 @@ void xlu__cfg_yyset_column (int _column_no , yyscan_t yyscanner) * input buffer. * @param _in_str A readable stream. * @param yyscanner The scanner object. - * @see xlu__cfg_yy_switch_to_buffer + * @see yy_switch_to_buffer */ -void xlu__cfg_yyset_in (FILE * _in_str , yyscan_t yyscanner) +void yyset_in (FILE * _in_str , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; yyin = _in_str ; } -void xlu__cfg_yyset_out (FILE * _out_str , yyscan_t yyscanner) +void yyset_out (FILE * _out_str , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; yyout = _out_str ; } -int xlu__cfg_yyget_debug (yyscan_t yyscanner) +int yyget_debug (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; return yy_flex_debug; } -void xlu__cfg_yyset_debug (int _bdebug , yyscan_t yyscanner) +void yyset_debug (int _bdebug , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; yy_flex_debug = _bdebug ; @@ -1937,25 +2167,25 @@ void xlu__cfg_yyset_debug (int _bdebug , yyscan_t yyscanner) /* Accessor methods for yylval and yylloc */ -YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner) +YYSTYPE * yyget_lval (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; return yylval; } -void xlu__cfg_yyset_lval (YYSTYPE * yylval_param , yyscan_t yyscanner) +void yyset_lval (YYSTYPE * yylval_param , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; yylval = yylval_param; } -YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner) +YYLTYPE *yyget_lloc (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; return yylloc; } -void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param , yyscan_t yyscanner) +void yyset_lloc (YYLTYPE * yylloc_param , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; yylloc = yylloc_param; @@ -1963,20 +2193,18 @@ void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param , yyscan_t yyscanner) /* User-visible API */ -/* xlu__cfg_yylex_init is special because it creates the scanner itself, so it is +/* yylex_init is special because it creates the scanner itself, so it is * the ONLY reentrant function that doesn't take the scanner as the last argument. * That's why we explicitly handle the declaration, instead of using our macros. */ - -int xlu__cfg_yylex_init(yyscan_t* ptr_yy_globals) - +int yylex_init(yyscan_t* ptr_yy_globals) { if (ptr_yy_globals == NULL){ errno = EINVAL; return 1; } - *ptr_yy_globals = (yyscan_t) xlu__cfg_yyalloc ( sizeof( struct yyguts_t ), NULL ); + *ptr_yy_globals = (yyscan_t) yyalloc ( sizeof( struct yyguts_t ), NULL ); if (*ptr_yy_globals == NULL){ errno = ENOMEM; @@ -1989,27 +2217,25 @@ int xlu__cfg_yylex_init(yyscan_t* ptr_yy_globals) return yy_init_globals ( *ptr_yy_globals ); } -/* xlu__cfg_yylex_init_extra has the same functionality as xlu__cfg_yylex_init, but follows the +/* yylex_init_extra has the same functionality as yylex_init, but follows the * convention of taking the scanner as the last argument. Note however, that * this is a *pointer* to a scanner, as it will be allocated by this call (and * is the reason, too, why this function also must handle its own declaration). - * The user defined value in the first argument will be available to xlu__cfg_yyalloc in + * The user defined value in the first argument will be available to yyalloc in * the yyextra field. */ - -int xlu__cfg_yylex_init_extra(YY_EXTRA_TYPE yy_user_defined,yyscan_t* ptr_yy_globals ) - +int yylex_init_extra( YY_EXTRA_TYPE yy_user_defined, yyscan_t* ptr_yy_globals ) { struct yyguts_t dummy_yyguts; - xlu__cfg_yyset_extra (yy_user_defined, &dummy_yyguts); + yyset_extra (yy_user_defined, &dummy_yyguts); if (ptr_yy_globals == NULL){ errno = EINVAL; return 1; } - *ptr_yy_globals = (yyscan_t) xlu__cfg_yyalloc ( sizeof( struct yyguts_t ), &dummy_yyguts ); + *ptr_yy_globals = (yyscan_t) yyalloc ( sizeof( struct yyguts_t ), &dummy_yyguts ); if (*ptr_yy_globals == NULL){ errno = ENOMEM; @@ -2020,7 +2246,7 @@ int xlu__cfg_yylex_init_extra(YY_EXTRA_TYPE yy_user_defined,yyscan_t* ptr_yy_glo yy_init_globals. Leave at 0x00 for releases. */ memset(*ptr_yy_globals,0x00,sizeof(struct yyguts_t)); - xlu__cfg_yyset_extra (yy_user_defined, *ptr_yy_globals); + yyset_extra (yy_user_defined, *ptr_yy_globals); return yy_init_globals ( *ptr_yy_globals ); } @@ -2029,7 +2255,7 @@ static int yy_init_globals (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* Initialization is the same as for the non-reentrant scanner. - * This function is called from xlu__cfg_yylex_destroy(), so don't allocate here. + * This function is called from yylex_destroy(), so don't allocate here. */ yyg->yy_buffer_stack = NULL; @@ -2053,37 +2279,37 @@ static int yy_init_globals (yyscan_t yyscanner) #endif /* For future reference: Set errno on error, since we are called by - * xlu__cfg_yylex_init() + * yylex_init() */ return 0; } -/* xlu__cfg_yylex_destroy is for both reentrant and non-reentrant scanners. */ -int xlu__cfg_yylex_destroy (yyscan_t yyscanner) +/* yylex_destroy is for both reentrant and non-reentrant scanners. */ +int yylex_destroy (yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* Pop the buffer stack, destroying each element. */ while(YY_CURRENT_BUFFER){ - xlu__cfg_yy_delete_buffer(YY_CURRENT_BUFFER ,yyscanner ); + yy_delete_buffer( YY_CURRENT_BUFFER , yyscanner ); YY_CURRENT_BUFFER_LVALUE = NULL; - xlu__cfg_yypop_buffer_state(yyscanner); + yypop_buffer_state(yyscanner); } /* Destroy the stack itself. */ - xlu__cfg_yyfree(yyg->yy_buffer_stack ,yyscanner); + yyfree(yyg->yy_buffer_stack , yyscanner); yyg->yy_buffer_stack = NULL; /* Destroy the start condition stack. */ - xlu__cfg_yyfree(yyg->yy_start_stack ,yyscanner ); + yyfree( yyg->yy_start_stack , yyscanner ); yyg->yy_start_stack = NULL; /* Reset the globals. This is important in a non-reentrant scanner so the next time - * xlu__cfg_yylex() is called, initialization will occur. */ + * yylex() is called, initialization will occur. */ yy_init_globals( yyscanner); /* Destroy the main struct (reentrant only). */ - xlu__cfg_yyfree ( yyscanner , yyscanner ); + yyfree ( yyscanner , yyscanner ); yyscanner = NULL; return 0; } @@ -2093,7 +2319,7 @@ int xlu__cfg_yylex_destroy (yyscan_t yyscanner) */ #ifndef yytext_ptr -static void yy_flex_strncpy (char* s1, yyconst char * s2, int n , yyscan_t yyscanner) +static void yy_flex_strncpy (char* s1, const char * s2, int n , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; (void)yyg; @@ -2105,7 +2331,7 @@ static void yy_flex_strncpy (char* s1, yyconst char * s2, int n , yyscan_t yysca #endif #ifdef YY_NEED_STRLEN -static int yy_flex_strlen (yyconst char * s , yyscan_t yyscanner) +static int yy_flex_strlen (const char * s , yyscan_t yyscanner) { int n; for ( n = 0; s[n]; ++n ) @@ -2115,14 +2341,14 @@ static int yy_flex_strlen (yyconst char * s , yyscan_t yyscanner) } #endif -void *xlu__cfg_yyalloc (yy_size_t size , yyscan_t yyscanner) +void *yyalloc (yy_size_t size , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; (void)yyg; return malloc(size); } -void *xlu__cfg_yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner) +void *yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; (void)yyg; @@ -2137,11 +2363,11 @@ void *xlu__cfg_yyrealloc (void * ptr, yy_size_t size , yyscan_t yyscanner) return realloc(ptr, size); } -void xlu__cfg_yyfree (void * ptr , yyscan_t yyscanner) +void yyfree (void * ptr , yyscan_t yyscanner) { struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; (void)yyg; - free( (char *) ptr ); /* see xlu__cfg_yyrealloc() for (char *) cast */ + free( (char *) ptr ); /* see yyrealloc() for (char *) cast */ } #define YYTABLES_NAME "yytables" diff --git a/tools/libxl/libxlu_cfg_l.h b/tools/libxl/libxlu_cfg_l.h index 415c3ce089..213ba18b86 100644 --- a/tools/libxl/libxlu_cfg_l.h +++ b/tools/libxl/libxlu_cfg_l.h @@ -13,11 +13,245 @@ #define FLEX_SCANNER #define YY_FLEX_MAJOR_VERSION 2 #define YY_FLEX_MINOR_VERSION 6 -#define YY_FLEX_SUBMINOR_VERSION 1 +#define YY_FLEX_SUBMINOR_VERSION 4 #if YY_FLEX_SUBMINOR_VERSION > 0 #define FLEX_BETA #endif +#ifdef yy_create_buffer +#define xlu__cfg_yy_create_buffer_ALREADY_DEFINED +#else +#define yy_create_buffer xlu__cfg_yy_create_buffer +#endif + +#ifdef yy_delete_buffer +#define xlu__cfg_yy_delete_buffer_ALREADY_DEFINED +#else +#define yy_delete_buffer xlu__cfg_yy_delete_buffer +#endif + +#ifdef yy_scan_buffer +#define xlu__cfg_yy_scan_buffer_ALREADY_DEFINED +#else +#define yy_scan_buffer xlu__cfg_yy_scan_buffer +#endif + +#ifdef yy_scan_string +#define xlu__cfg_yy_scan_string_ALREADY_DEFINED +#else +#define yy_scan_string xlu__cfg_yy_scan_string +#endif + +#ifdef yy_scan_bytes +#define xlu__cfg_yy_scan_bytes_ALREADY_DEFINED +#else +#define yy_scan_bytes xlu__cfg_yy_scan_bytes +#endif + +#ifdef yy_init_buffer +#define xlu__cfg_yy_init_buffer_ALREADY_DEFINED +#else +#define yy_init_buffer xlu__cfg_yy_init_buffer +#endif + +#ifdef yy_flush_buffer +#define xlu__cfg_yy_flush_buffer_ALREADY_DEFINED +#else +#define yy_flush_buffer xlu__cfg_yy_flush_buffer +#endif + +#ifdef yy_load_buffer_state +#define xlu__cfg_yy_load_buffer_state_ALREADY_DEFINED +#else +#define yy_load_buffer_state xlu__cfg_yy_load_buffer_state +#endif + +#ifdef yy_switch_to_buffer +#define xlu__cfg_yy_switch_to_buffer_ALREADY_DEFINED +#else +#define yy_switch_to_buffer xlu__cfg_yy_switch_to_buffer +#endif + +#ifdef yypush_buffer_state +#define xlu__cfg_yypush_buffer_state_ALREADY_DEFINED +#else +#define yypush_buffer_state xlu__cfg_yypush_buffer_state +#endif + +#ifdef yypop_buffer_state +#define xlu__cfg_yypop_buffer_state_ALREADY_DEFINED +#else +#define yypop_buffer_state xlu__cfg_yypop_buffer_state +#endif + +#ifdef yyensure_buffer_stack +#define xlu__cfg_yyensure_buffer_stack_ALREADY_DEFINED +#else +#define yyensure_buffer_stack xlu__cfg_yyensure_buffer_stack +#endif + +#ifdef yylex +#define xlu__cfg_yylex_ALREADY_DEFINED +#else +#define yylex xlu__cfg_yylex +#endif + +#ifdef yyrestart +#define xlu__cfg_yyrestart_ALREADY_DEFINED +#else +#define yyrestart xlu__cfg_yyrestart +#endif + +#ifdef yylex_init +#define xlu__cfg_yylex_init_ALREADY_DEFINED +#else +#define yylex_init xlu__cfg_yylex_init +#endif + +#ifdef yylex_init_extra +#define xlu__cfg_yylex_init_extra_ALREADY_DEFINED +#else +#define yylex_init_extra xlu__cfg_yylex_init_extra +#endif + +#ifdef yylex_destroy +#define xlu__cfg_yylex_destroy_ALREADY_DEFINED +#else +#define yylex_destroy xlu__cfg_yylex_destroy +#endif + +#ifdef yyget_debug +#define xlu__cfg_yyget_debug_ALREADY_DEFINED +#else +#define yyget_debug xlu__cfg_yyget_debug +#endif + +#ifdef yyset_debug +#define xlu__cfg_yyset_debug_ALREADY_DEFINED +#else +#define yyset_debug xlu__cfg_yyset_debug +#endif + +#ifdef yyget_extra +#define xlu__cfg_yyget_extra_ALREADY_DEFINED +#else +#define yyget_extra xlu__cfg_yyget_extra +#endif + +#ifdef yyset_extra +#define xlu__cfg_yyset_extra_ALREADY_DEFINED +#else +#define yyset_extra xlu__cfg_yyset_extra +#endif + +#ifdef yyget_in +#define xlu__cfg_yyget_in_ALREADY_DEFINED +#else +#define yyget_in xlu__cfg_yyget_in +#endif + +#ifdef yyset_in +#define xlu__cfg_yyset_in_ALREADY_DEFINED +#else +#define yyset_in xlu__cfg_yyset_in +#endif + +#ifdef yyget_out +#define xlu__cfg_yyget_out_ALREADY_DEFINED +#else +#define yyget_out xlu__cfg_yyget_out +#endif + +#ifdef yyset_out +#define xlu__cfg_yyset_out_ALREADY_DEFINED +#else +#define yyset_out xlu__cfg_yyset_out +#endif + +#ifdef yyget_leng +#define xlu__cfg_yyget_leng_ALREADY_DEFINED +#else +#define yyget_leng xlu__cfg_yyget_leng +#endif + +#ifdef yyget_text +#define xlu__cfg_yyget_text_ALREADY_DEFINED +#else +#define yyget_text xlu__cfg_yyget_text +#endif + +#ifdef yyget_lineno +#define xlu__cfg_yyget_lineno_ALREADY_DEFINED +#else +#define yyget_lineno xlu__cfg_yyget_lineno +#endif + +#ifdef yyset_lineno +#define xlu__cfg_yyset_lineno_ALREADY_DEFINED +#else +#define yyset_lineno xlu__cfg_yyset_lineno +#endif + +#ifdef yyget_column +#define xlu__cfg_yyget_column_ALREADY_DEFINED +#else +#define yyget_column xlu__cfg_yyget_column +#endif + +#ifdef yyset_column +#define xlu__cfg_yyset_column_ALREADY_DEFINED +#else +#define yyset_column xlu__cfg_yyset_column +#endif + +#ifdef yywrap +#define xlu__cfg_yywrap_ALREADY_DEFINED +#else +#define yywrap xlu__cfg_yywrap +#endif + +#ifdef yyget_lval +#define xlu__cfg_yyget_lval_ALREADY_DEFINED +#else +#define yyget_lval xlu__cfg_yyget_lval +#endif + +#ifdef yyset_lval +#define xlu__cfg_yyset_lval_ALREADY_DEFINED +#else +#define yyset_lval xlu__cfg_yyset_lval +#endif + +#ifdef yyget_lloc +#define xlu__cfg_yyget_lloc_ALREADY_DEFINED +#else +#define yyget_lloc xlu__cfg_yyget_lloc +#endif + +#ifdef yyset_lloc +#define xlu__cfg_yyset_lloc_ALREADY_DEFINED +#else +#define yyset_lloc xlu__cfg_yyset_lloc +#endif + +#ifdef yyalloc +#define xlu__cfg_yyalloc_ALREADY_DEFINED +#else +#define yyalloc xlu__cfg_yyalloc +#endif + +#ifdef yyrealloc +#define xlu__cfg_yyrealloc_ALREADY_DEFINED +#else +#define yyrealloc xlu__cfg_yyrealloc +#endif + +#ifdef yyfree +#define xlu__cfg_yyfree_ALREADY_DEFINED +#else +#define yyfree xlu__cfg_yyfree +#endif + /* First, we deal with platform-specific or compiler-specific issues. */ /* begin standard C headers. */ @@ -88,10 +322,16 @@ typedef unsigned int flex_uint32_t; #define UINT32_MAX (4294967295U) #endif +#ifndef SIZE_MAX +#define SIZE_MAX (~(size_t)0) +#endif + #endif /* ! C99 */ #endif /* ! FLEXINT_H */ +/* begin standard C++ headers. */ + /* TODO: this is always defined, so inline it */ #define yyconst const @@ -192,21 +432,21 @@ struct yy_buffer_state }; #endif /* !YY_STRUCT_YY_BUFFER_STATE */ -void xlu__cfg_yyrestart (FILE *input_file ,yyscan_t yyscanner ); -void xlu__cfg_yy_switch_to_buffer (YY_BUFFER_STATE new_buffer ,yyscan_t yyscanner ); -YY_BUFFER_STATE xlu__cfg_yy_create_buffer (FILE *file,int size ,yyscan_t yyscanner ); -void xlu__cfg_yy_delete_buffer (YY_BUFFER_STATE b ,yyscan_t yyscanner ); -void xlu__cfg_yy_flush_buffer (YY_BUFFER_STATE b ,yyscan_t yyscanner ); -void xlu__cfg_yypush_buffer_state (YY_BUFFER_STATE new_buffer ,yyscan_t yyscanner ); -void xlu__cfg_yypop_buffer_state (yyscan_t yyscanner ); +void yyrestart ( FILE *input_file , yyscan_t yyscanner ); +void yy_switch_to_buffer ( YY_BUFFER_STATE new_buffer , yyscan_t yyscanner ); +YY_BUFFER_STATE yy_create_buffer ( FILE *file, int size , yyscan_t yyscanner ); +void yy_delete_buffer ( YY_BUFFER_STATE b , yyscan_t yyscanner ); +void yy_flush_buffer ( YY_BUFFER_STATE b , yyscan_t yyscanner ); +void yypush_buffer_state ( YY_BUFFER_STATE new_buffer , yyscan_t yyscanner ); +void yypop_buffer_state ( yyscan_t yyscanner ); -YY_BUFFER_STATE xlu__cfg_yy_scan_buffer (char *base,yy_size_t size ,yyscan_t yyscanner ); -YY_BUFFER_STATE xlu__cfg_yy_scan_string (yyconst char *yy_str ,yyscan_t yyscanner ); -YY_BUFFER_STATE xlu__cfg_yy_scan_bytes (yyconst char *bytes,int len ,yyscan_t yyscanner ); +YY_BUFFER_STATE yy_scan_buffer ( char *base, yy_size_t size , yyscan_t yyscanner ); +YY_BUFFER_STATE yy_scan_string ( const char *yy_str , yyscan_t yyscanner ); +YY_BUFFER_STATE yy_scan_bytes ( const char *bytes, int len , yyscan_t yyscanner ); -void *xlu__cfg_yyalloc (yy_size_t ,yyscan_t yyscanner ); -void *xlu__cfg_yyrealloc (void *,yy_size_t ,yyscan_t yyscanner ); -void xlu__cfg_yyfree (void * ,yyscan_t yyscanner ); +void *yyalloc ( yy_size_t , yyscan_t yyscanner ); +void *yyrealloc ( void *, yy_size_t , yyscan_t yyscanner ); +void yyfree ( void * , yyscan_t yyscanner ); #define xlu__cfg_yywrap(yyscanner) (/*CONSTCOND*/1) #define YY_SKIP_YYWRAP @@ -231,50 +471,50 @@ void xlu__cfg_yyfree (void * ,yyscan_t yyscanner ); #define YY_EXTRA_TYPE void * #endif -int xlu__cfg_yylex_init (yyscan_t* scanner); +int yylex_init (yyscan_t* scanner); -int xlu__cfg_yylex_init_extra (YY_EXTRA_TYPE user_defined,yyscan_t* scanner); +int yylex_init_extra ( YY_EXTRA_TYPE user_defined, yyscan_t* scanner); /* Accessor methods to globals. These are made visible to non-reentrant scanners for convenience. */ -int xlu__cfg_yylex_destroy (yyscan_t yyscanner ); +int yylex_destroy ( yyscan_t yyscanner ); -int xlu__cfg_yyget_debug (yyscan_t yyscanner ); +int yyget_debug ( yyscan_t yyscanner ); -void xlu__cfg_yyset_debug (int debug_flag ,yyscan_t yyscanner ); +void yyset_debug ( int debug_flag , yyscan_t yyscanner ); -YY_EXTRA_TYPE xlu__cfg_yyget_extra (yyscan_t yyscanner ); +YY_EXTRA_TYPE yyget_extra ( yyscan_t yyscanner ); -void xlu__cfg_yyset_extra (YY_EXTRA_TYPE user_defined ,yyscan_t yyscanner ); +void yyset_extra ( YY_EXTRA_TYPE user_defined , yyscan_t yyscanner ); -FILE *xlu__cfg_yyget_in (yyscan_t yyscanner ); +FILE *yyget_in ( yyscan_t yyscanner ); -void xlu__cfg_yyset_in (FILE * _in_str ,yyscan_t yyscanner ); +void yyset_in ( FILE * _in_str , yyscan_t yyscanner ); -FILE *xlu__cfg_yyget_out (yyscan_t yyscanner ); +FILE *yyget_out ( yyscan_t yyscanner ); -void xlu__cfg_yyset_out (FILE * _out_str ,yyscan_t yyscanner ); +void yyset_out ( FILE * _out_str , yyscan_t yyscanner ); - int xlu__cfg_yyget_leng (yyscan_t yyscanner ); + int yyget_leng ( yyscan_t yyscanner ); -char *xlu__cfg_yyget_text (yyscan_t yyscanner ); +char *yyget_text ( yyscan_t yyscanner ); -int xlu__cfg_yyget_lineno (yyscan_t yyscanner ); +int yyget_lineno ( yyscan_t yyscanner ); -void xlu__cfg_yyset_lineno (int _line_number ,yyscan_t yyscanner ); +void yyset_lineno ( int _line_number , yyscan_t yyscanner ); -int xlu__cfg_yyget_column (yyscan_t yyscanner ); +int yyget_column ( yyscan_t yyscanner ); -void xlu__cfg_yyset_column (int _column_no ,yyscan_t yyscanner ); +void yyset_column ( int _column_no , yyscan_t yyscanner ); -YYSTYPE * xlu__cfg_yyget_lval (yyscan_t yyscanner ); +YYSTYPE * yyget_lval ( yyscan_t yyscanner ); -void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner ); +void yyset_lval ( YYSTYPE * yylval_param , yyscan_t yyscanner ); - YYLTYPE *xlu__cfg_yyget_lloc (yyscan_t yyscanner ); + YYLTYPE *yyget_lloc ( yyscan_t yyscanner ); - void xlu__cfg_yyset_lloc (YYLTYPE * yylloc_param ,yyscan_t yyscanner ); + void yyset_lloc ( YYLTYPE * yylloc_param , yyscan_t yyscanner ); /* Macros after this point can all be overridden by user definitions in * section 1. @@ -282,18 +522,18 @@ void xlu__cfg_yyset_lval (YYSTYPE * yylval_param ,yyscan_t yyscanner ); #ifndef YY_SKIP_YYWRAP #ifdef __cplusplus -extern "C" int xlu__cfg_yywrap (yyscan_t yyscanner ); +extern "C" int yywrap ( yyscan_t yyscanner ); #else -extern int xlu__cfg_yywrap (yyscan_t yyscanner ); +extern int yywrap ( yyscan_t yyscanner ); #endif #endif #ifndef yytext_ptr -static void yy_flex_strncpy (char *,yyconst char *,int ,yyscan_t yyscanner); +static void yy_flex_strncpy ( char *, const char *, int , yyscan_t yyscanner); #endif #ifdef YY_NEED_STRLEN -static int yy_flex_strlen (yyconst char * ,yyscan_t yyscanner); +static int yy_flex_strlen ( const char * , yyscan_t yyscanner); #endif #ifndef YY_NO_INPUT @@ -321,10 +561,10 @@ static int yy_flex_strlen (yyconst char * ,yyscan_t yyscanner); #ifndef YY_DECL #define YY_DECL_IS_OURS 1 -extern int xlu__cfg_yylex \ - (YYSTYPE * yylval_param,YYLTYPE * yylloc_param ,yyscan_t yyscanner); +extern int yylex \ + (YYSTYPE * yylval_param, YYLTYPE * yylloc_param , yyscan_t yyscanner); -#define YY_DECL int xlu__cfg_yylex \ +#define YY_DECL int yylex \ (YYSTYPE * yylval_param, YYLTYPE * yylloc_param , yyscan_t yyscanner) #endif /* !YY_DECL */ @@ -342,8 +582,153 @@ extern int xlu__cfg_yylex \ #undef YY_DECL #endif +#ifndef xlu__cfg_yy_create_buffer_ALREADY_DEFINED +#undef yy_create_buffer +#endif +#ifndef xlu__cfg_yy_delete_buffer_ALREADY_DEFINED +#undef yy_delete_buffer +#endif +#ifndef xlu__cfg_yy_scan_buffer_ALREADY_DEFINED +#undef yy_scan_buffer +#endif +#ifndef xlu__cfg_yy_scan_string_ALREADY_DEFINED +#undef yy_scan_string +#endif +#ifndef xlu__cfg_yy_scan_bytes_ALREADY_DEFINED +#undef yy_scan_bytes +#endif +#ifndef xlu__cfg_yy_init_buffer_ALREADY_DEFINED +#undef yy_init_buffer +#endif +#ifndef xlu__cfg_yy_flush_buffer_ALREADY_DEFINED +#undef yy_flush_buffer +#endif +#ifndef xlu__cfg_yy_load_buffer_state_ALREADY_DEFINED +#undef yy_load_buffer_state +#endif +#ifndef xlu__cfg_yy_switch_to_buffer_ALREADY_DEFINED +#undef yy_switch_to_buffer +#endif +#ifndef xlu__cfg_yypush_buffer_state_ALREADY_DEFINED +#undef yypush_buffer_state +#endif +#ifndef xlu__cfg_yypop_buffer_state_ALREADY_DEFINED +#undef yypop_buffer_state +#endif +#ifndef xlu__cfg_yyensure_buffer_stack_ALREADY_DEFINED +#undef yyensure_buffer_stack +#endif +#ifndef xlu__cfg_yylex_ALREADY_DEFINED +#undef yylex +#endif +#ifndef xlu__cfg_yyrestart_ALREADY_DEFINED +#undef yyrestart +#endif +#ifndef xlu__cfg_yylex_init_ALREADY_DEFINED +#undef yylex_init +#endif +#ifndef xlu__cfg_yylex_init_extra_ALREADY_DEFINED +#undef yylex_init_extra +#endif +#ifndef xlu__cfg_yylex_destroy_ALREADY_DEFINED +#undef yylex_destroy +#endif +#ifndef xlu__cfg_yyget_debug_ALREADY_DEFINED +#undef yyget_debug +#endif +#ifndef xlu__cfg_yyset_debug_ALREADY_DEFINED +#undef yyset_debug +#endif +#ifndef xlu__cfg_yyget_extra_ALREADY_DEFINED +#undef yyget_extra +#endif +#ifndef xlu__cfg_yyset_extra_ALREADY_DEFINED +#undef yyset_extra +#endif +#ifndef xlu__cfg_yyget_in_ALREADY_DEFINED +#undef yyget_in +#endif +#ifndef xlu__cfg_yyset_in_ALREADY_DEFINED +#undef yyset_in +#endif +#ifndef xlu__cfg_yyget_out_ALREADY_DEFINED +#undef yyget_out +#endif +#ifndef xlu__cfg_yyset_out_ALREADY_DEFINED +#undef yyset_out +#endif +#ifndef xlu__cfg_yyget_leng_ALREADY_DEFINED +#undef yyget_leng +#endif +#ifndef xlu__cfg_yyget_text_ALREADY_DEFINED +#undef yyget_text +#endif +#ifndef xlu__cfg_yyget_lineno_ALREADY_DEFINED +#undef yyget_lineno +#endif +#ifndef xlu__cfg_yyset_lineno_ALREADY_DEFINED +#undef yyset_lineno +#endif +#ifndef xlu__cfg_yyget_column_ALREADY_DEFINED +#undef yyget_column +#endif +#ifndef xlu__cfg_yyset_column_ALREADY_DEFINED +#undef yyset_column +#endif +#ifndef xlu__cfg_yywrap_ALREADY_DEFINED +#undef yywrap +#endif +#ifndef xlu__cfg_yyget_lval_ALREADY_DEFINED +#undef yyget_lval +#endif +#ifndef xlu__cfg_yyset_lval_ALREADY_DEFINED +#undef yyset_lval +#endif +#ifndef xlu__cfg_yyget_lloc_ALREADY_DEFINED +#undef yyget_lloc +#endif +#ifndef xlu__cfg_yyset_lloc_ALREADY_DEFINED +#undef yyset_lloc +#endif +#ifndef xlu__cfg_yyalloc_ALREADY_DEFINED +#undef yyalloc +#endif +#ifndef xlu__cfg_yyrealloc_ALREADY_DEFINED +#undef yyrealloc +#endif +#ifndef xlu__cfg_yyfree_ALREADY_DEFINED +#undef yyfree +#endif +#ifndef xlu__cfg_yytext_ALREADY_DEFINED +#undef yytext +#endif +#ifndef xlu__cfg_yyleng_ALREADY_DEFINED +#undef yyleng +#endif +#ifndef xlu__cfg_yyin_ALREADY_DEFINED +#undef yyin +#endif +#ifndef xlu__cfg_yyout_ALREADY_DEFINED +#undef yyout +#endif +#ifndef xlu__cfg_yy_flex_debug_ALREADY_DEFINED +#undef yy_flex_debug +#endif +#ifndef xlu__cfg_yylineno_ALREADY_DEFINED +#undef yylineno +#endif +#ifndef xlu__cfg_yytables_fload_ALREADY_DEFINED +#undef yytables_fload +#endif +#ifndef xlu__cfg_yytables_destroy_ALREADY_DEFINED +#undef yytables_destroy +#endif +#ifndef xlu__cfg_yyTABLES_NAME_ALREADY_DEFINED +#undef yyTABLES_NAME +#endif + #line 105 "libxlu_cfg_l.l" -#line 348 "libxlu_cfg_l.h" +#line 733 "libxlu_cfg_l.h" #undef xlu__cfg_yyIN_HEADER #endif /* xlu__cfg_yyHEADER_H */ diff --git a/tools/libxl/libxlu_cfg_y.c b/tools/libxl/libxlu_cfg_y.c index 751daa3842..6d4638afc9 100644 --- a/tools/libxl/libxlu_cfg_y.c +++ b/tools/libxl/libxlu_cfg_y.c @@ -1,8 +1,9 @@ -/* A Bison parser, made by GNU Bison 3.0.4. */ +/* A Bison parser, made by GNU Bison 3.3.2. */ /* Bison implementation for Yacc-like parsers in C - Copyright (C) 1984, 1989-1990, 2000-2015 Free Software Foundation, Inc. + Copyright (C) 1984, 1989-1990, 2000-2015, 2018-2019 Free Software Foundation, + Inc. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -40,11 +41,14 @@ define necessary library symbols; they are noted "INFRINGES ON USER NAME SPACE" below. */ +/* Undocumented macros, especially those whose name start with YY_, + are private implementation details. Do not rely on them. */ + /* Identify Bison output. */ #define YYBISON 1 /* Bison version. */ -#define YYBISON_VERSION "3.0.4" +#define YYBISON_VERSION "3.3.2" /* Skeleton name. */ #define YYSKELETON_NAME "yacc.c" @@ -67,20 +71,23 @@ #define yynerrs xlu__cfg_yynerrs -/* Copy the first part of user declarations. */ -#line 19 "libxlu_cfg_y.y" /* yacc.c:339 */ +/* First part of user prologue. */ +#line 19 "libxlu_cfg_y.y" /* yacc.c:337 */ #define ctx_scanner ctx->scanner #include "libxlu_cfg_i.h" #include "libxlu_cfg_l.h" -#line 78 "libxlu_cfg_y.c" /* yacc.c:339 */ - +#line 82 "libxlu_cfg_y.c" /* yacc.c:337 */ # ifndef YY_NULLPTR -# if defined __cplusplus && 201103L <= __cplusplus -# define YY_NULLPTR nullptr +# if defined __cplusplus +# if 201103L <= __cplusplus +# define YY_NULLPTR nullptr +# else +# define YY_NULLPTR 0 +# endif # else -# define YY_NULLPTR 0 +# define YY_NULLPTR ((void*)0) # endif # endif @@ -122,12 +129,12 @@ extern int xlu__cfg_yydebug; union YYSTYPE { -#line 25 "libxlu_cfg_y.y" /* yacc.c:355 */ +#line 25 "libxlu_cfg_y.y" /* yacc.c:352 */ char *string; XLU_ConfigValue *value; -#line 131 "libxlu_cfg_y.c" /* yacc.c:355 */ +#line 138 "libxlu_cfg_y.c" /* yacc.c:352 */ }; typedef union YYSTYPE YYSTYPE; @@ -155,9 +162,7 @@ int xlu__cfg_yyparse (CfgParseContext *ctx); #endif /* !YY_XLU_CFG_YY_LIBXLU_CFG_Y_H_INCLUDED */ -/* Copy the second part of user declarations. */ -#line 161 "libxlu_cfg_y.c" /* yacc.c:358 */ #ifdef short # undef short @@ -178,13 +183,13 @@ typedef signed char yytype_int8; #ifdef YYTYPE_UINT16 typedef YYTYPE_UINT16 yytype_uint16; #else -typedef unsigned short int yytype_uint16; +typedef unsigned short yytype_uint16; #endif #ifdef YYTYPE_INT16 typedef YYTYPE_INT16 yytype_int16; #else -typedef short int yytype_int16; +typedef short yytype_int16; #endif #ifndef YYSIZE_T @@ -196,7 +201,7 @@ typedef short int yytype_int16; # include /* INFRINGES ON USER NAME SPACE */ # define YYSIZE_T size_t # else -# define YYSIZE_T unsigned int +# define YYSIZE_T unsigned # endif #endif @@ -232,15 +237,6 @@ typedef short int yytype_int16; # define YY_ATTRIBUTE_UNUSED YY_ATTRIBUTE ((__unused__)) #endif -#if !defined _Noreturn \ - && (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112) -# if defined _MSC_VER && 1200 <= _MSC_VER -# define _Noreturn __declspec (noreturn) -# else -# define _Noreturn YY_ATTRIBUTE ((__noreturn__)) -# endif -#endif - /* Suppress unused-variable warnings by "using" E. */ #if ! defined lint || defined __GNUC__ # define YYUSE(E) ((void) (E)) @@ -248,7 +244,7 @@ typedef short int yytype_int16; # define YYUSE(E) /* empty */ #endif -#if defined __GNUC__ && 407 <= __GNUC__ * 100 + __GNUC_MINOR__ +#if defined __GNUC__ && ! defined __ICC && 407 <= __GNUC__ * 100 + __GNUC_MINOR__ /* Suppress an incorrect diagnostic about yylval being uninitialized. */ # define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN \ _Pragma ("GCC diagnostic push") \ @@ -412,16 +408,16 @@ union yyalloc /* YYNSTATES -- Number of states. */ #define YYNSTATES 32 -/* YYTRANSLATE[YYX] -- Symbol number corresponding to YYX as returned - by yylex, with out-of-bounds checking. */ #define YYUNDEFTOK 2 #define YYMAXUTOK 262 +/* YYTRANSLATE(TOKEN-NUM) -- Symbol number corresponding to TOKEN-NUM + as returned by yylex, with out-of-bounds checking. */ #define YYTRANSLATE(YYX) \ - ((unsigned int) (YYX) <= YYMAXUTOK ? yytranslate[YYX] : YYUNDEFTOK) + ((unsigned) (YYX) <= YYMAXUTOK ? yytranslate[YYX] : YYUNDEFTOK) /* YYTRANSLATE[TOKEN-NUM] -- Symbol number corresponding to TOKEN-NUM - as returned by yylex, without out-of-bounds checking. */ + as returned by yylex. */ static const yytype_uint8 yytranslate[] = { 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, @@ -586,22 +582,22 @@ static const yytype_uint8 yyr2[] = #define YYRECOVERING() (!!yyerrstatus) -#define YYBACKUP(Token, Value) \ -do \ - if (yychar == YYEMPTY) \ - { \ - yychar = (Token); \ - yylval = (Value); \ - YYPOPSTACK (yylen); \ - yystate = *yyssp; \ - goto yybackup; \ - } \ - else \ - { \ - yyerror (&yylloc, ctx, YY_("syntax error: cannot back up")); \ - YYERROR; \ - } \ -while (0) +#define YYBACKUP(Token, Value) \ + do \ + if (yychar == YYEMPTY) \ + { \ + yychar = (Token); \ + yylval = (Value); \ + YYPOPSTACK (yylen); \ + yystate = *yyssp; \ + goto yybackup; \ + } \ + else \ + { \ + yyerror (&yylloc, ctx, YY_("syntax error: cannot back up")); \ + YYERROR; \ + } \ + while (0) /* Error token number */ #define YYTERROR 1 @@ -660,10 +656,10 @@ do { \ /* Print *YYLOCP on YYO. Private, do not rely on its existence. */ YY_ATTRIBUTE_UNUSED -static unsigned +static int yy_location_print_ (FILE *yyo, YYLTYPE const * const yylocp) { - unsigned res = 0; + int res = 0; int end_col = 0 != yylocp->last_column ? yylocp->last_column - 1 : 0; if (0 <= yylocp->first_line) { @@ -706,41 +702,41 @@ do { \ } while (0) -/*----------------------------------------. -| Print this symbol's value on YYOUTPUT. | -`----------------------------------------*/ +/*-----------------------------------. +| Print this symbol's value on YYO. | +`-----------------------------------*/ static void -yy_symbol_value_print (FILE *yyoutput, int yytype, YYSTYPE const * const yyvaluep, YYLTYPE const * const yylocationp, CfgParseContext *ctx) +yy_symbol_value_print (FILE *yyo, int yytype, YYSTYPE const * const yyvaluep, YYLTYPE const * const yylocationp, CfgParseContext *ctx) { - FILE *yyo = yyoutput; - YYUSE (yyo); + FILE *yyoutput = yyo; + YYUSE (yyoutput); YYUSE (yylocationp); YYUSE (ctx); if (!yyvaluep) return; # ifdef YYPRINT if (yytype < YYNTOKENS) - YYPRINT (yyoutput, yytoknum[yytype], *yyvaluep); + YYPRINT (yyo, yytoknum[yytype], *yyvaluep); # endif YYUSE (yytype); } -/*--------------------------------. -| Print this symbol on YYOUTPUT. | -`--------------------------------*/ +/*---------------------------. +| Print this symbol on YYO. | +`---------------------------*/ static void -yy_symbol_print (FILE *yyoutput, int yytype, YYSTYPE const * const yyvaluep, YYLTYPE const * const yylocationp, CfgParseContext *ctx) +yy_symbol_print (FILE *yyo, int yytype, YYSTYPE const * const yyvaluep, YYLTYPE const * const yylocationp, CfgParseContext *ctx) { - YYFPRINTF (yyoutput, "%s %s (", + YYFPRINTF (yyo, "%s %s (", yytype < YYNTOKENS ? "token" : "nterm", yytname[yytype]); - YY_LOCATION_PRINT (yyoutput, *yylocationp); - YYFPRINTF (yyoutput, ": "); - yy_symbol_value_print (yyoutput, yytype, yyvaluep, yylocationp, ctx); - YYFPRINTF (yyoutput, ")"); + YY_LOCATION_PRINT (yyo, *yylocationp); + YYFPRINTF (yyo, ": "); + yy_symbol_value_print (yyo, yytype, yyvaluep, yylocationp, ctx); + YYFPRINTF (yyo, ")"); } /*------------------------------------------------------------------. @@ -774,7 +770,7 @@ do { \ static void yy_reduce_print (yytype_int16 *yyssp, YYSTYPE *yyvsp, YYLTYPE *yylsp, int yyrule, CfgParseContext *ctx) { - unsigned long int yylno = yyrline[yyrule]; + unsigned long yylno = yyrline[yyrule]; int yynrhs = yyr2[yyrule]; int yyi; YYFPRINTF (stderr, "Reducing stack by rule %d (line %lu):\n", @@ -785,7 +781,7 @@ yy_reduce_print (yytype_int16 *yyssp, YYSTYPE *yyvsp, YYLTYPE *yylsp, int yyrule YYFPRINTF (stderr, " $%d = ", yyi + 1); yy_symbol_print (stderr, yystos[yyssp[yyi + 1 - yynrhs]], - &(yyvsp[(yyi + 1) - (yynrhs)]) + &yyvsp[(yyi + 1) - (yynrhs)] , &(yylsp[(yyi + 1) - (yynrhs)]) , ctx); YYFPRINTF (stderr, "\n"); } @@ -889,7 +885,10 @@ yytnamerr (char *yyres, const char *yystr) case '\\': if (*++yyp != '\\') goto do_not_strip_quotes; - /* Fall through. */ + else + goto append; + + append: default: if (yyres) yyres[yyn] = *yyp; @@ -907,7 +906,7 @@ yytnamerr (char *yyres, const char *yystr) if (! yyres) return yystrlen (yystr); - return yystpcpy (yyres, yystr) - yyres; + return (YYSIZE_T) (yystpcpy (yyres, yystr) - yyres); } # endif @@ -985,10 +984,10 @@ yysyntax_error (YYSIZE_T *yymsg_alloc, char **yymsg, yyarg[yycount++] = yytname[yyx]; { YYSIZE_T yysize1 = yysize + yytnamerr (YY_NULLPTR, yytname[yyx]); - if (! (yysize <= yysize1 - && yysize1 <= YYSTACK_ALLOC_MAXIMUM)) + if (yysize <= yysize1 && yysize1 <= YYSTACK_ALLOC_MAXIMUM) + yysize = yysize1; + else return 2; - yysize = yysize1; } } } @@ -1000,6 +999,7 @@ yysyntax_error (YYSIZE_T *yymsg_alloc, char **yymsg, case N: \ yyformat = S; \ break + default: /* Avoid compiler warnings. */ YYCASE_(0, YY_("syntax error")); YYCASE_(1, YY_("syntax error, unexpected %s")); YYCASE_(2, YY_("syntax error, unexpected %s, expecting %s")); @@ -1011,9 +1011,10 @@ yysyntax_error (YYSIZE_T *yymsg_alloc, char **yymsg, { YYSIZE_T yysize1 = yysize + yystrlen (yyformat); - if (! (yysize <= yysize1 && yysize1 <= YYSTACK_ALLOC_MAXIMUM)) + if (yysize <= yysize1 && yysize1 <= YYSTACK_ALLOC_MAXIMUM) + yysize = yysize1; + else return 2; - yysize = yysize1; } if (*yymsg_alloc < yysize) @@ -1064,49 +1065,48 @@ yydestruct (const char *yymsg, int yytype, YYSTYPE *yyvaluep, YYLTYPE *yylocatio YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN switch (yytype) { - case 3: /* IDENT */ + case 3: /* IDENT */ #line 40 "libxlu_cfg_y.y" /* yacc.c:1257 */ { free(((*yyvaluep).string)); } -#line 1071 "libxlu_cfg_y.c" /* yacc.c:1257 */ +#line 1072 "libxlu_cfg_y.c" /* yacc.c:1257 */ break; case 4: /* STRING */ #line 40 "libxlu_cfg_y.y" /* yacc.c:1257 */ { free(((*yyvaluep).string)); } -#line 1077 "libxlu_cfg_y.c" /* yacc.c:1257 */ +#line 1078 "libxlu_cfg_y.c" /* yacc.c:1257 */ break; case 5: /* NUMBER */ #line 40 "libxlu_cfg_y.y" /* yacc.c:1257 */ { free(((*yyvaluep).string)); } -#line 1083 "libxlu_cfg_y.c" /* yacc.c:1257 */ +#line 1084 "libxlu_cfg_y.c" /* yacc.c:1257 */ break; case 19: /* value */ #line 44 "libxlu_cfg_y.y" /* yacc.c:1257 */ { xlu__cfg_value_free(((*yyvaluep).value)); } -#line 1089 "libxlu_cfg_y.c" /* yacc.c:1257 */ +#line 1090 "libxlu_cfg_y.c" /* yacc.c:1257 */ break; case 20: /* atom */ #line 40 "libxlu_cfg_y.y" /* yacc.c:1257 */ { free(((*yyvaluep).string)); } -#line 1095 "libxlu_cfg_y.c" /* yacc.c:1257 */ +#line 1096 "libxlu_cfg_y.c" /* yacc.c:1257 */ break; case 21: /* valuelist */ #line 44 "libxlu_cfg_y.y" /* yacc.c:1257 */ { xlu__cfg_value_free(((*yyvaluep).value)); } -#line 1101 "libxlu_cfg_y.c" /* yacc.c:1257 */ +#line 1102 "libxlu_cfg_y.c" /* yacc.c:1257 */ break; case 22: /* values */ #line 44 "libxlu_cfg_y.y" /* yacc.c:1257 */ { xlu__cfg_value_free(((*yyvaluep).value)); } -#line 1107 "libxlu_cfg_y.c" /* yacc.c:1257 */ +#line 1108 "libxlu_cfg_y.c" /* yacc.c:1257 */ break; - default: break; } @@ -1212,23 +1212,31 @@ YYLTYPE yylloc = yyloc_default; yylsp[0] = yylloc; goto yysetstate; + /*------------------------------------------------------------. -| yynewstate -- Push a new state, which is found in yystate. | +| yynewstate -- push a new state, which is found in yystate. | `------------------------------------------------------------*/ - yynewstate: +yynewstate: /* In all cases, when you get here, the value and location stacks have just been pushed. So pushing a state here evens the stacks. */ yyssp++; - yysetstate: - *yyssp = yystate; + +/*--------------------------------------------------------------------. +| yynewstate -- set current state (the top of the stack) to yystate. | +`--------------------------------------------------------------------*/ +yysetstate: + *yyssp = (yytype_int16) yystate; if (yyss + yystacksize - 1 <= yyssp) +#if !defined yyoverflow && !defined YYSTACK_RELOCATE + goto yyexhaustedlab; +#else { /* Get the current used size of the three stacks, in elements. */ - YYSIZE_T yysize = yyssp - yyss + 1; + YYSIZE_T yysize = (YYSIZE_T) (yyssp - yyss + 1); -#ifdef yyoverflow +# if defined yyoverflow { /* Give user a chance to reallocate the stack. Use copies of these so that the &'s don't force the real ones into @@ -1246,15 +1254,11 @@ YYLTYPE yylloc = yyloc_default; &yyvs1, yysize * sizeof (*yyvsp), &yyls1, yysize * sizeof (*yylsp), &yystacksize); - - yyls = yyls1; yyss = yyss1; yyvs = yyvs1; + yyls = yyls1; } -#else /* no yyoverflow */ -# ifndef YYSTACK_RELOCATE - goto yyexhaustedlab; -# else +# else /* defined YYSTACK_RELOCATE */ /* Extend the stack our own way. */ if (YYMAXDEPTH <= yystacksize) goto yyexhaustedlab; @@ -1271,23 +1275,23 @@ YYLTYPE yylloc = yyloc_default; YYSTACK_RELOCATE (yyss_alloc, yyss); YYSTACK_RELOCATE (yyvs_alloc, yyvs); YYSTACK_RELOCATE (yyls_alloc, yyls); -# undef YYSTACK_RELOCATE +# undef YYSTACK_RELOCATE if (yyss1 != yyssa) YYSTACK_FREE (yyss1); } # endif -#endif /* no yyoverflow */ yyssp = yyss + yysize - 1; yyvsp = yyvs + yysize - 1; yylsp = yyls + yysize - 1; YYDPRINTF ((stderr, "Stack size increased to %lu\n", - (unsigned long int) yystacksize)); + (unsigned long) yystacksize)); if (yyss + yystacksize - 1 <= yyssp) YYABORT; } +#endif /* !defined yyoverflow && !defined YYSTACK_RELOCATE */ YYDPRINTF ((stderr, "Entering state %d\n", yystate)); @@ -1296,11 +1300,11 @@ YYLTYPE yylloc = yyloc_default; goto yybackup; + /*-----------. | yybackup. | `-----------*/ yybackup: - /* Do appropriate processing given the current state. Read a lookahead token if we need one and don't already have one. */ @@ -1373,7 +1377,7 @@ yydefault: /*-----------------------------. -| yyreduce -- Do a reduction. | +| yyreduce -- do a reduction. | `-----------------------------*/ yyreduce: /* yyn is the number of a rule to reduce with. */ @@ -1389,79 +1393,80 @@ yyreduce: GCC warning that YYVAL may be used uninitialized. */ yyval = yyvsp[1-yylen]; - /* Default location. */ + /* Default location. */ YYLLOC_DEFAULT (yyloc, (yylsp - yylen), yylen); + yyerror_range[1] = yyloc; YY_REDUCE_PRINT (yyn); switch (yyn) { case 9: -#line 58 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 58 "libxlu_cfg_y.y" /* yacc.c:1652 */ { xlu__cfg_set_store(ctx,(yyvsp[-2].string),XLU_OP_ASSIGNMENT,(yyvsp[0].value),(yylsp[0]).first_line); } -#line 1401 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1406 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 10: -#line 59 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 59 "libxlu_cfg_y.y" /* yacc.c:1652 */ { xlu__cfg_set_store(ctx,(yyvsp[-2].string),XLU_OP_ADDITION,(yyvsp[0].value),(yylsp[0]).first_line); } -#line 1407 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1412 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 13: -#line 64 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 64 "libxlu_cfg_y.y" /* yacc.c:1652 */ { (yyval.value)= xlu__cfg_string_mk(ctx,(yyvsp[0].string),&(yylsp[0])); } -#line 1413 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1418 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 14: -#line 65 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 65 "libxlu_cfg_y.y" /* yacc.c:1652 */ { (yyval.value)= (yyvsp[-1].value); } -#line 1419 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1424 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 15: -#line 67 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 67 "libxlu_cfg_y.y" /* yacc.c:1652 */ { (yyval.string)= (yyvsp[0].string); } -#line 1425 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1430 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 16: -#line 68 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 68 "libxlu_cfg_y.y" /* yacc.c:1652 */ { (yyval.string)= (yyvsp[0].string); } -#line 1431 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1436 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 17: -#line 70 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 70 "libxlu_cfg_y.y" /* yacc.c:1652 */ { (yyval.value)= xlu__cfg_list_mk(ctx,NULL,&yylloc); } -#line 1437 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1442 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 18: -#line 71 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 71 "libxlu_cfg_y.y" /* yacc.c:1652 */ { (yyval.value)= (yyvsp[0].value); } -#line 1443 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1448 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 19: -#line 72 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 72 "libxlu_cfg_y.y" /* yacc.c:1652 */ { (yyval.value)= (yyvsp[-2].value); } -#line 1449 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1454 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 20: -#line 74 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 74 "libxlu_cfg_y.y" /* yacc.c:1652 */ { (yyval.value)= xlu__cfg_list_mk(ctx,(yyvsp[-1].value),&(yylsp[-1])); } -#line 1455 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1460 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; case 21: -#line 75 "libxlu_cfg_y.y" /* yacc.c:1646 */ +#line 75 "libxlu_cfg_y.y" /* yacc.c:1652 */ { xlu__cfg_list_append(ctx,(yyvsp[-4].value),(yyvsp[-1].value)); (yyval.value)= (yyvsp[-4].value); } -#line 1461 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1466 "libxlu_cfg_y.c" /* yacc.c:1652 */ break; -#line 1465 "libxlu_cfg_y.c" /* yacc.c:1646 */ +#line 1470 "libxlu_cfg_y.c" /* yacc.c:1652 */ default: break; } /* User semantic actions sometimes alter yychar, and that requires @@ -1487,14 +1492,13 @@ yyreduce: /* Now 'shift' the result of the reduction. Determine what state that goes to, based on the state we popped back to and the rule number reduced by. */ - - yyn = yyr1[yyn]; - - yystate = yypgoto[yyn - YYNTOKENS] + *yyssp; - if (0 <= yystate && yystate <= YYLAST && yycheck[yystate] == *yyssp) - yystate = yytable[yystate]; - else - yystate = yydefgoto[yyn - YYNTOKENS]; + { + const int yylhs = yyr1[yyn] - YYNTOKENS; + const int yyi = yypgoto[yylhs] + *yyssp; + yystate = (0 <= yyi && yyi <= YYLAST && yycheck[yyi] == *yyssp + ? yytable[yyi] + : yydefgoto[yylhs]); + } goto yynewstate; @@ -1577,14 +1581,11 @@ yyerrlab: | yyerrorlab -- error raised explicitly by YYERROR. | `---------------------------------------------------*/ yyerrorlab: + /* Pacify compilers when the user code never invokes YYERROR and the + label yyerrorlab therefore never appears in user code. */ + if (0) + YYERROR; - /* Pacify compilers like GCC when the user code never invokes - YYERROR and the label yyerrorlab therefore never appears in user - code. */ - if (/*CONSTCOND*/ 0) - goto yyerrorlab; - - yyerror_range[1] = yylsp[1-yylen]; /* Do not reclaim the symbols of the rule whose action triggered this YYERROR. */ YYPOPSTACK (yylen); @@ -1650,6 +1651,7 @@ yyacceptlab: yyresult = 0; goto yyreturn; + /*-----------------------------------. | yyabortlab -- YYABORT comes here. | `-----------------------------------*/ @@ -1657,6 +1659,7 @@ yyabortlab: yyresult = 1; goto yyreturn; + #if !defined yyoverflow || YYERROR_VERBOSE /*-------------------------------------------------. | yyexhaustedlab -- memory exhaustion comes here. | @@ -1667,6 +1670,10 @@ yyexhaustedlab: /* Fall through. */ #endif + +/*-----------------------------------------------------. +| yyreturn -- parsing is finished, return the result. | +`-----------------------------------------------------*/ yyreturn: if (yychar != YYEMPTY) { diff --git a/tools/libxl/libxlu_cfg_y.h b/tools/libxl/libxlu_cfg_y.h index 9691bf1350..1233cb94fc 100644 --- a/tools/libxl/libxlu_cfg_y.h +++ b/tools/libxl/libxlu_cfg_y.h @@ -1,8 +1,9 @@ -/* A Bison parser, made by GNU Bison 3.0.4. */ +/* A Bison parser, made by GNU Bison 3.3.2. */ /* Bison interface for Yacc-like parsers in C - Copyright (C) 1984, 1989-1990, 2000-2015 Free Software Foundation, Inc. + Copyright (C) 1984, 1989-1990, 2000-2015, 2018-2019 Free Software Foundation, + Inc. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by @@ -30,6 +31,9 @@ This special exception was added by the Free Software Foundation in version 2.2 of Bison. */ +/* Undocumented macros, especially those whose name start with YY_, + are private implementation details. Do not rely on them. */ + #ifndef YY_XLU_CFG_YY_LIBXLU_CFG_Y_H_INCLUDED # define YY_XLU_CFG_YY_LIBXLU_CFG_Y_H_INCLUDED /* Debug traces. */ @@ -58,12 +62,12 @@ extern int xlu__cfg_yydebug; union YYSTYPE { -#line 25 "libxlu_cfg_y.y" /* yacc.c:1909 */ +#line 25 "libxlu_cfg_y.y" /* yacc.c:1921 */ char *string; XLU_ConfigValue *value; -#line 67 "libxlu_cfg_y.h" /* yacc.c:1909 */ +#line 71 "libxlu_cfg_y.h" /* yacc.c:1921 */ }; typedef union YYSTYPE YYSTYPE; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:26:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:26:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjla1-0003Zl-T9; Fri, 12 Jun 2020 15:26:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjla1-0003Zg-AA for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:26:53 +0000 X-Inumbo-ID: 23c4b710-acc1-11ea-b5e1-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 23c4b710-acc1-11ea-b5e1-12813bfff9fa; Fri, 12 Jun 2020 15:26:52 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: DI+pjL4dvpHEJgezwSfZX9iLTzdW2HCD4Sdh/UvCMgrnmIxNbmKyCLP+qYrOLAZHAPkx148IEa +sMK2qCoonwF4s8KfIKsbmRHx/IY6CIDo7zvPc66V+OLGPVtIybqCBd1rSalgm3M2L43HufPd4 NJAj6voEeLUOAsZZ2UFJHIzfcLR0+XAazZEyqVcxi8JsJ5ix1no8wr/40Bu7nYBpuihx/XWFrM gqDtVsyWkhIpVZeZiMgjh0vD1PhWhIgjmMpaWcph01wDgAZfDhvc3atfasD+8qlAD+TA+yS/N1 rqs= X-SBRS: 2.7 X-MesageID: 19931883 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="19931883" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24291.40630.574838.139876@mariner.uk.xensource.com> Date: Fri, 12 Jun 2020 16:26:46 +0100 To: Andrew Cooper Subject: Re: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() In-Reply-To: <20200610114004.30023-1-andrew.cooper3@citrix.com> References: <20200610114004.30023-1-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Xen-devel , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("[PATCH for-4.14] tools: fix error path of xendevicemodel_open()"): > c/s 6902cb00e03 "tools/libxendevicemodel: extract functions and add a compat > layer" introduced calls to both xencall_open() and osdep_xendevicemodel_open() > but failed to fix up the error path. > > c/s f68c7c618a3 "libs/devicemodel: free xencall handle in error path in > _open()" fixed up the xencall_open() aspect of the error path (missing the > osdep_xendevicemodel_open() aspect), but positioned the xencall_close() > incorrectly, creating the same pattern proved to be problematic by c/s > 30a72f02870 "tools: fix error path of xenhypfs_open()". > > Reposition xtl_logger_destroy(), and introduce the missing > osdep_xendevicemodel_close(). Reviewed-by: Ian Jackson I notice that the tail of xendevicemodel_open is now identical to xendevicemodel_close. I think this is expected, and that it would be better to combine the two sets of code. If they hadn't been separate then we might have avoided this bug... Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:29:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:29:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlco-0003hc-Aq; Fri, 12 Jun 2020 15:29:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlcn-0003hV-36 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:29:45 +0000 X-Inumbo-ID: 8a4354ed-acc1-11ea-b5e1-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8a4354ed-acc1-11ea-b5e1-12813bfff9fa; Fri, 12 Jun 2020 15:29:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4A74CACA7; Fri, 12 Jun 2020 15:29:46 +0000 (UTC) Message-ID: <78910b5c27a3711726d53e931feb075c5cc4a64c.camel@suse.com> Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. From: Dario Faggioli To: =?ISO-8859-1?Q?J=FCrgen_Gro=DF?= , Julien Grall , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" Date: Fri, 12 Jun 2020 17:29:40 +0200 In-Reply-To: References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> Organization: SUSE Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-E3CEUp2PggUbrhDrBR5L" User-Agent: Evolution 3.36.3 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --=-E3CEUp2PggUbrhDrBR5L Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2020-06-12 at 14:41 +0200, J=C3=BCrgen Gro=C3=9F wrote: > On 12.06.20 14:29, Julien Grall wrote: > > On 12/06/2020 05:57, J=C3=BCrgen Gro=C3=9F wrote: > > > On 12.06.20 02:22, Volodymyr Babchuk wrote: > > > >=20 > > > > @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct=20 > > > > sched_unit *u) > > > > break; > > > > } > > > > + spin_lock_irqsave(&sched_stat_lock, flags); > > > > + sched_stat_irq_time +=3D irq; > > > > + sched_stat_hyp_time +=3D hyp; > > > > + spin_unlock_irqrestore(&sched_stat_lock, flags); > > >=20 > > > Please don't use a lock. Just use add_sized() instead which will > > > add > > > atomically. > >=20 > > If we expect sched_get_time_correction to be called concurrently > > then we=20 > > would need to introduce atomic64_t or a spin lock. >=20 > Or we could use percpu variables and add the cpu values up when > fetching the values. >=20 Yes, either percpu or atomic looks much better than locking, to me, for this. Regards --=20 Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <> (Raistlin Majere) --=-E3CEUp2PggUbrhDrBR5L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl7jn2QACgkQFkJ4iaW4 c+6gQg//QBMNiOfvDBk7sLcjbKTTV5c/G+t1XZj9uy3Y0DHcgOpqwOkdXiNJ2ONm ld+HkHGsNRkglocNFKCx8ZfLVvQX++KR/ou8BhvBItsqtB9frECppX2X6/ejbnu0 OLHuQzfzM4qR2FEOwqvETq/l531NIqro81N4a4Qf4AGTcFDZsD3kv7s4HBUXoVvv Ahnt3MYP+ZwO1giV31Vw4XS8Vo89iHsvTV+K7eIhZOu/THa3yO0T8F1znGJ5lE8+ JIR+mX22570m79SDsZui6YISixLStbh0UFizPvbp7OLAPH1C9vew/17JHYN11vEo lx2rlQ0g7rrf7Fifj4ilRFMTTGsQnR3bRstCqKcw98DvKwhUfkJEMF0AkH0IZXsP P1NDAvWYa4d1LqwnNC+qzVY7ScOgGzykSIAyrkvnaPX+QBvmjbRhZgZgwOB4lGMq PJV9HMbPnkMdJIpRfOtTZZlBtJwws78vxKQLow6wOWvKlbZj9qHna6imauN7vh78 G+lurZyPJFCq3iJTP1twddhW8xtOEm/2oPQSWT0PibBjMDKI7+Lv/i/5dIe1PIwC WYW92qSZkdDIX0gIcauBMOgm7CcAe1vaol9SK9MFEKmwXQI3+oL1VMC4TQeVxYsw Uke5k8a5vfvHjG8nTPBaReZBlHHM26MOBskszhIFSWu1658tPO4= =YBDq -----END PGP SIGNATURE----- --=-E3CEUp2PggUbrhDrBR5L-- From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:44:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:44:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlqh-0005Ii-JL; Fri, 12 Jun 2020 15:44:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjlqg-0005Ib-5G for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:44:06 +0000 X-Inumbo-ID: 8b9e425a-acc3-11ea-bb8b-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8b9e425a-acc3-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 15:44:05 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /4zzphKVAOE+c6m0SyfnltFuDjtRwyrGfrggpTZUCt3W+rhsIH/D7qh35/WSGbC0uht8mHSlLx ks8y3BIk33r1Mz23qv+Lcm+CLYAn10xNSTzNlK1094HeNBpsos+Q+0KJaVoT+fm27byRoGnVUU N7j9uC1PeMMp8f4Td9Bu/d7sWvioVeS/qbS7D2qrT/ci+5o39V2amLM5NH2kNwzIUdwBbDksWr Z7qjXhVtXMOJhpu7VWanifY+QLMFbVslM8qcNJFsfNpAeac3/xEZ3QfwN8BPWxTe9Y4HKKcNj8 HwQ= X-SBRS: 2.7 X-MesageID: 20687027 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20687027" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24291.41663.838349.127061@mariner.uk.xensource.com> Date: Fri, 12 Jun 2020 16:43:59 +0100 To: Andrew Cooper Subject: Re: [PATCH for-4.14] tools: fix error path of xendevicemodel_open() In-Reply-To: <765b4fed-60d3-9c4a-d6b7-bcd9893c525b@citrix.com> References: <20200610114004.30023-1-andrew.cooper3@citrix.com> <010401d6408a$2c57bba0$850732e0$@xen.org> <765b4fed-60d3-9c4a-d6b7-bcd9893c525b@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Juergen Gross' , 'Xen-devel' , 'Wei Liu' , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("Re: [PATCH for-4.14] tools: fix error path of xendevicemodel_open()"): > There is still the crash described below which needs some form of > figuring out and fixing. ... > >> Failure to create the logger will still hit the NULL deference, in all of the > >> stable libs, not just devicemodel. Are you sure ? I think you mean this sequence of events: xencall_open(logger=NULL, open_flags=0) xcall->logger = NULL; /* from logger */ xcall->logger_tofree = NULL; if (1) { xtl_createlogger_stdiostream => NULL /* so */ goto err; } err: xentoolcore__deregister_active_handle(&xcall->tc_ah); /* " */ osdep_xencall_close(xcall); xencall_close(dmod->xcall); xtl_logger_destroy(xcall->logger_tofree /* NULL */); // <- crash? free(xcall); But xtl_logger_destroy(NULL) is a safe no-op. However, > >> Also, unless I'd triple checked the history, I was about to reintroduce the > >> deadlock from c/s 9976f3874d4 These comments made me look again at 9976f3874d4 "tools: xentoolcore_restrict_all: Do deregistration before close". Just now I wrote: I notice that the tail of xendevicemodel_open is now identical to xendevicemodel_close. I think this is expected, and that it would be better to combine the two sets of code. If they hadn't been separate then we might have avoided this bug... But in fact this is not true. xendevicemodel_close has them in the right order, but xendevicemodel_open's err block has them in the wrong order. Now that I look at xencall, I discover tht xencall_open's err block is not identical to xencall_close. xencall close calls buffer_release_cache and xencall_open's err block does not. Looking more closely I think this happens not to be a memory leak because xcall->buffer* don't contain any malloc'd stuff until they are used. But I think this is poor practice and another example of teardown code duplication being a bad idea. > >> because it totally counterintuitive wrong to > >> expect setup and teardown in opposite orders. Are you sure you wrote what you meant ? To my mind it is usual for setup and teardown to proceed in precisely the opposite order. The need to call xentoolcore__deregister_active_handle before closing the fd is to my mind unusual and counterintuitive. The reasons are explained in the commit message for 9976f3874d4cca82. Does that all make sense ? Perhaps we should at least delete the wrong err path of xendevicemodel_open with a call to xendevicemodel_close ? Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:54:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:54:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm0V-0006B3-I6; Fri, 12 Jun 2020 15:54:15 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm0U-0006Ay-E7 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:54:14 +0000 X-Inumbo-ID: f5bc216a-acc4-11ea-b5e3-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f5bc216a-acc4-11ea-b5e3-12813bfff9fa; Fri, 12 Jun 2020 15:54:13 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: YXrMwguBL+IgQnqDk0+ehaEcLNp0LZ5jt6xVp6hqo/xaZkWeBYdSSRXt/sg9Cj5K2Ld/6dJBR5 bMJeVWmatGTDj1Z46cEchT8IgwEQ2WR5MRCBckvvzN9B1LJRNdabRNQf+vrO4ry3ukIkfZV5HN ENcKRN/ELT1HOmWZc+GC0i0SOKDMegIY+iGW4DI/Ri04AsUaGGWnwyGXGzClpsTt3RuaQmf0nz zJCPkdLTex5/1QDAheQMzcdgiZw1GTtnx7zYXsDG3Me2tKVmZ2DFxEqAmtNg65P4VRnOk3g7Zy aO4= X-SBRS: 2.7 X-MesageID: 20213136 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20213136" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24291.42247.159206.867256@mariner.uk.xensource.com> Date: Fri, 12 Jun 2020 16:53:43 +0100 To: "paul@xen.org" Subject: RE: [PATCH for-4.14] tools/libxc: Drop config_transformed parameter from xc_cpuid_set() In-Reply-To: <000301d640a9$743c5510$5cb4ff30$@xen.org> References: <20200612105519.18728-1-andrew.cooper3@citrix.com> <000301d640a9$743c5510$5cb4ff30$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , 'Wei Liu' , 'Xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: [PATCH for-4.14] tools/libxc: Drop config_transformed parameter from xc_cpuid_set()"): > > -----Original Message----- > > From: Andrew Cooper > > Sent: 12 June 2020 11:55 > > To: Xen-devel > > Cc: Andrew Cooper ; Ian Jackson ; Wei Liu > > ; Paul Durrant > > Subject: [PATCH for-4.14] tools/libxc: Drop config_transformed parameter from xc_cpuid_set() > > > > libxl is now the sole caller of xc_cpuid_set(). The config_transformed output > > is ignored, and this patch trivially highlights the resulting memory leak. > > > > "transformed" config is now properly forwarded on migrate as part of the > > general VM state, so delete the transformation logic completely, rather than > > trying to adjust just libxl to avoid leaking memory. > > > > Signed-off-by: Andrew Cooper > > Reviewed-by: Paul Durrant > Release-acked-by: Paul Durrant Reviewed-by: Ian Jackson I will commit this in a moment. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:57:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:57:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3T-0006KW-Hc; Fri, 12 Jun 2020 15:57:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3S-0006K0-3P for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:57:18 +0000 X-Inumbo-ID: 61d895d8-acc5-11ea-b5e3-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 61d895d8-acc5-11ea-b5e3-12813bfff9fa; Fri, 12 Jun 2020 15:57:14 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: K6m2NGmVcam+h7MTcp4Z4ANjw6IUgDn+vvI1B0j51XUYS3mmrM7fV9TTaqqfE+23htLnVcwEwU Ma81K7w7rsxqyOQ4bzlJq4jzSwX8tHTz3mNH8atqZV01hDCaiEwvM2r0R7jPAMvbI6i9m9xkbF vz89E0ANtkjP0NuY6ND9GVMjEqygCHPUfObjN3vBPVcnD8KN8SEPaVyusYUT1VDaQVPD8vyA/D 7B+9qsMe7KfEJYlrIkBZ+jHmnjvuByNSZLK15zbcAb+ajOMpWCn7ZmMU5SbwNhGA8HaZNBt0xN A9s= X-SBRS: 2.7 X-MesageID: 20213495 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20213495" From: Roger Pau Monne To: Subject: [PATCH for-4.14 2/8] x86/hvm: don't force vCPU 0 for IRQ 0 when using fixed destination mode Date: Fri, 12 Jun 2020 17:56:34 +0200 Message-ID: <20200612155640.4101-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200612155640.4101-1-roger.pau@citrix.com> References: <20200612155640.4101-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" When the IO APIC pin mapped to the ISA IRQ 0 has been configured to use fixed delivery mode do not forcefully route interrupts to vCPU 0, as the OS might have setup those interrupts to be injected to a different vCPU, and injecting to vCPU 0 can cause the OS to miss such interrupts or errors to happen due to unexpected vectors being injected on vCPU 0. In order to fix remove such handling altogether for fixed destination mode pins and just inject them according to the data setup in the IO-APIC entry. Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/vioapic.c | 23 ++++------------------- 1 file changed, 4 insertions(+), 19 deletions(-) diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c index bd41036137..67472e5934 100644 --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -445,26 +445,11 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin) } case dest_Fixed: - { -#ifdef IRQ0_SPECIAL_ROUTING - /* Do not deliver timer interrupts to VCPU != 0 */ - if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() ) - { - if ( (v = d->vcpu ? d->vcpu[0] : NULL) != NULL ) - ioapic_inj_irq(vioapic, vcpu_vlapic(v), vector, - trig_mode, delivery_mode); - } - else -#endif - { - for_each_vcpu ( d, v ) - if ( vlapic_match_dest(vcpu_vlapic(v), NULL, - 0, dest, dest_mode) ) - ioapic_inj_irq(vioapic, vcpu_vlapic(v), vector, - trig_mode, delivery_mode); - } + for_each_vcpu ( d, v ) + if ( vlapic_match_dest(vcpu_vlapic(v), NULL, 0, dest, dest_mode) ) + ioapic_inj_irq(vioapic, vcpu_vlapic(v), vector, trig_mode, + delivery_mode); break; - } case dest_NMI: { -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:57:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:57:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3M-0006Jq-1N; Fri, 12 Jun 2020 15:57:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3K-0006Jl-So for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:57:10 +0000 X-Inumbo-ID: 5f263faa-acc5-11ea-8496-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5f263faa-acc5-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 15:57:09 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 58hdpE5aYZQjUD+5z9VoYZhC8pEqoSGKdGRLfyrT+78DJpdDA/b5egTOJABc0bvneZ0ZAXaD1B nBi9vti3dzA3uLu2Q7Sl4AS7dUkyGZrH2dZ5pcT3O+pikLuC3MUauY9cX/nijCB+EzUPztOnRh X9ZbAOt9p8vgwEaUUO1W0iUpTb5yHMPUorHMwZzOxgKNoBNbm//G9N6s8HMItz/j2ZFKrJQida 2aVgKonMUkjI1PxQ2WuJgpepOn+8II5MA+Buy8tX69titjRi4ZcyVGmy1fYGkLR8VAIMfO/kIB NBI= X-SBRS: 2.7 X-MesageID: 20265876 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20265876" From: Roger Pau Monne To: Subject: [PATCH for-4.14 0/8] x86/vpt: fixes for vpt and enable vPIT for PVH dom0 Date: Fri, 12 Jun 2020 17:56:32 +0200 Message-ID: <20200612155640.4101-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, The first 6 patches on this series are fixes for HVM virtual timers or for the handling of the emulated PIT. I think they are all candidates for 4.14 since without those PIT is not usable (and likely other emulated timers will also experience issues) unless the OS happens to make a very specific use of it, ie: timers must be configured from vCPU 0 and the destination must also be set to vCPU 0. FreeBSD for example doesn't follow such rules, as it will usually configure PIT timers from vCPU 0 and the destination will be set to a random vCPU in the system, and as a result gets a non functional PIT. Patches 7 and 8 enable the usage of the emulated vPIT for PVH dom0, which is said to be required for certain video BIOS. As I mostly test PVH dom0 on headless systems I'm not able to assert how common this is, but given that it's already enabled for a classic PV dom0 let's try to not regress and also provide a working PIT for PVH dom0. I think the whole batch is also a candidate for backporting. Thanks, Roger. Roger Pau Monne (8): x86/hvm: fix vIO-APIC build without IRQ0_SPECIAL_ROUTING x86/hvm: don't force vCPU 0 for IRQ 0 when using fixed destination mode x86/hvm: fix ISA IRQ 0 handling when set as lowest priority mode in IO APIC x86/vpt: only try to resume timers belonging to enabled devices x86/hvm: only translate ISA interrupts to GSIs in virtual timers x86/vpt: fix injection to remote vCPU x86/hvm: add hardware domain support to hvm_isa_irq_to_gsi x86/hvm: enable emulated PIT for PVH dom0 xen/arch/x86/domain.c | 5 +- xen/arch/x86/emul-i8254.c | 12 +++- xen/arch/x86/hvm/irq.c | 20 ++++++- xen/arch/x86/hvm/vioapic.c | 47 +++++++--------- xen/arch/x86/hvm/vpic.c | 7 ++- xen/arch/x86/hvm/vpt.c | 102 ++++++++++++++++++---------------- xen/arch/x86/io_apic.c | 16 +++--- xen/include/asm-x86/hvm/irq.h | 2 +- xen/include/asm-x86/io_apic.h | 3 + 9 files changed, 121 insertions(+), 93 deletions(-) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:57:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:57:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3O-0006K5-96; Fri, 12 Jun 2020 15:57:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3N-0006K0-4q for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:57:13 +0000 X-Inumbo-ID: 60389534-acc5-11ea-b5e3-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 60389534-acc5-11ea-b5e3-12813bfff9fa; Fri, 12 Jun 2020 15:57:12 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: tJYIR2S3Ocd5uXt8pWAoShrj2UMDT+WR9oxPAsF9CJqVNZYh0HUpjT7joDzDm7OYui4jLzBkIr 5i/INQSZZUgypeKxultSdhU11yxeTufQkknSiDM8gRz0szZ4pLgdA/v1SqCCgOwEer3uslnldD cKbpI2joK5PNzfo2XsCh1ndozWh2TtA+sa6dVcqVkaMxrMQYCAWrOQntbkwGoEOe1goRKcu19Z YCT6b2yJtr/jCEUIBEK3H+yQZ3+X/1Xoe31c6xUGRIeUZkrxQPXyqESLrG6ywIwmQEuCOhjz4W Cis= X-SBRS: 2.7 X-MesageID: 20213493 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20213493" From: Roger Pau Monne To: Subject: [PATCH for-4.14 1/8] x86/hvm: fix vIO-APIC build without IRQ0_SPECIAL_ROUTING Date: Fri, 12 Jun 2020 17:56:33 +0200 Message-ID: <20200612155640.4101-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200612155640.4101-1-roger.pau@citrix.com> References: <20200612155640.4101-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" pit_channel0_enabled needs to be guarded with IRQ0_SPECIAL_ROUTING since it's only used when the special handling of ISA IRQ 0 is enabled. No functional change. Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/vioapic.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c index b87facb0e0..bd41036137 100644 --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -391,10 +391,12 @@ static void ioapic_inj_irq( vlapic_set_irq(target, vector, trig_mode); } +#ifdef IRQ0_SPECIAL_ROUTING static inline int pit_channel0_enabled(void) { return pt_active(¤t->domain->arch.vpit.pt0); } +#endif static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin) { -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:57:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:57:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3X-0006ML-QN; Fri, 12 Jun 2020 15:57:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3W-0006Lr-4d for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:57:22 +0000 X-Inumbo-ID: 6624bcfa-acc5-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6624bcfa-acc5-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 15:57:21 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: rVAZ4lcV09ivW5keN6zjsXLA88pLfNsACRUUlIrMjY0Np5SExn6kfS/MQ39zwDOZc/r4NY9NQi oa+niKpIOqTzC7qZN+SdHYA8agDCLiZZGPM6p/clhXW7jR/ogaTT4LeqZL6jwMN6f0X9egi3xX EBrvU2B3oUdCMR+ayxGN9l0tO26jz9tz/Try8F0FaOeVOaVrv7OmH0/pQoCeuh0iUT458ogL35 vmqnKSRxO9V4I1UAIuY/JInBXcH6MKNCARP07by0SEtbDOK+xK6iubEoG8YEGOX4DDj2OV53qW Hts= X-SBRS: 2.7 X-MesageID: 19919135 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="19919135" From: Roger Pau Monne To: Subject: [PATCH for-4.14 5/8] x86/hvm: only translate ISA interrupts to GSIs in virtual timers Date: Fri, 12 Jun 2020 17:56:37 +0200 Message-ID: <20200612155640.4101-6-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200612155640.4101-1-roger.pau@citrix.com> References: <20200612155640.4101-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Only call hvm_isa_irq_to_gsi for ISA interrupts, interrupts originating from an IO APIC pin already use a GSI and don't need to be translated. I haven't observed any issues from this, but I think it's better to use it correctly. Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/vpt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c index 62c87867c5..6a975fc668 100644 --- a/xen/arch/x86/hvm/vpt.c +++ b/xen/arch/x86/hvm/vpt.c @@ -86,7 +86,7 @@ static int pt_irq_vector(struct periodic_time *pt, enum hvm_intsrc src) return pt->irq; isa_irq = pt->irq; - gsi = hvm_isa_irq_to_gsi(isa_irq); + gsi = pt->source == PTSRC_isa ? hvm_isa_irq_to_gsi(isa_irq) : pt->irq; if ( src == hvm_intsrc_pic ) return (v->domain->arch.hvm.vpic[isa_irq >> 3].irq_base -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:57:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:57:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3Y-0006Mu-89; Fri, 12 Jun 2020 15:57:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3X-0006K0-3T for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:57:23 +0000 X-Inumbo-ID: 634bb10a-acc5-11ea-b5e3-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 634bb10a-acc5-11ea-b5e3-12813bfff9fa; Fri, 12 Jun 2020 15:57:16 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: T+j6pxRDudaou500LkfMDI+m1tD8yDtRWmcbpWv2muc/5y6LqO1oKjg10JVhhI+nWh1siuqw4T SkEu5nTveJxFL0LQE5TiK/L0AKvsm3fxWay0VHapaf71VXLThYEO2erGauASxXHkv/dm6CCVBy YjCb0+A77cIpUK/kc8/ROnp39OVyOsiYIISZrfaiqIl9gWfN/z7xVk6svDjAk0/vkuUtJP/V6Q 6VJkn5THB2g2ghE5d1w9tRnGCl8ud+iYEFA5xnD3/lQFo8s2SvQ4/x699FkOYEbhCo0VIAYQiY eIw= X-SBRS: 2.7 X-MesageID: 20265891 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20265891" From: Roger Pau Monne To: Subject: [PATCH for-4.14 3/8] x86/hvm: fix ISA IRQ 0 handling when set as lowest priority mode in IO APIC Date: Fri, 12 Jun 2020 17:56:35 +0200 Message-ID: <20200612155640.4101-4-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200612155640.4101-1-roger.pau@citrix.com> References: <20200612155640.4101-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Lowest priority destination mode does allow the vIO APIC code to select a vCPU to inject the interrupt to, but the selected vCPU must be part of the possible destinations configured for such IO APIC pin. Fix the code in order to only force vCPU 0 if it's part of the listed destinations. Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/vioapic.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c index 67472e5934..e1417cc6a7 100644 --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -422,12 +422,13 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin) case dest_LowestPrio: { #ifdef IRQ0_SPECIAL_ROUTING - /* Force round-robin to pick VCPU 0 */ - if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() ) - { - v = d->vcpu ? d->vcpu[0] : NULL; - target = v ? vcpu_vlapic(v) : NULL; - } + struct vlapic *lapic0 = vcpu_vlapic(d->vcpu[0]); + + /* Force to pick vCPU 0 if part of the destination list */ + if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() && + vlapic_match_dest(lapic0, NULL, 0, dest, dest_mode) && + vlapic_enabled(lapic0) ) + target = lapic0; else #endif target = vlapic_lowest_prio(d, NULL, 0, dest, dest_mode); -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:57:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:57:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3Z-0006O6-IE; Fri, 12 Jun 2020 15:57:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3Y-0006Lr-Ea for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:57:24 +0000 X-Inumbo-ID: 677d62be-acc5-11ea-bca7-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 677d62be-acc5-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 15:57:23 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: TVD0ttfOnIiXGEtsNobNcfdCmiF8/oXhdeOHH8SAseli8/+/JIfIRE4czWVeWo0K2B3KqhvRSo f6gs7CY0ghaN+EPFqfJSpQm1t8OU5V9/eseebNUQUKH+jGKUsm8H59xaX4Wn7T/PXub7KCWClY XGCyFgzWysjFbkfGj8zG+GZiC8XnUl1rX5omH4G86iYV7MVzw5B4Qd4f/oKo/Xg1iYnXslYzt9 BIBRtMeZN3jbT5j8GFW/C/luI3bYbhy4pZ2BAfTfy9OOA7tVP+DVV4PwjDNOp48ZENHtepvKJm ODw= X-SBRS: 2.7 X-MesageID: 20157334 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20157334" From: Roger Pau Monne To: Subject: [PATCH for-4.14 6/8] x86/vpt: fix injection to remote vCPU Date: Fri, 12 Jun 2020 17:56:38 +0200 Message-ID: <20200612155640.4101-7-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200612155640.4101-1-roger.pau@citrix.com> References: <20200612155640.4101-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" vpt timers are usually added to the per-vCPU list of the vCPU where they get setup, but depending on the timer source type that vCPU might be different than the one where the interrupt vector gets injected. For example the PIT timer use a PIC or IO-APIC pin in order to select the destination vCPU and vector, which might not match the vCPU they are configured from. If such a situation happens pt_intr_post won't be called, and thus the vpt will be left in a limbo where the next interrupt won't be scheduled. Fix this by generalizing the special handling done to IO-APIC level interrupts to be applied always when the destination vCPU of the injected vector is different from the vCPU where the vpt belongs to (ie: usually the one it's been configured from). A further improvement as noted in a comment added to the code might be to move the vpt so it's handled by the same vCPU where the vector gets injected. Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/vpt.c | 80 +++++++++++++++++++++--------------------- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c index 6a975fc668..52ad5b90a7 100644 --- a/xen/arch/x86/hvm/vpt.c +++ b/xen/arch/x86/hvm/vpt.c @@ -358,59 +358,59 @@ int pt_update_irq(struct vcpu *v) * interrupt delivery case. Otherwise return -1 to do nothing. */ vlapic_set_irq(vcpu_vlapic(v), irq, 0); - pt_vector = irq; - break; + return irq; case PTSRC_isa: hvm_isa_irq_deassert(v->domain, irq); if ( platform_legacy_irq(irq) && vlapic_accept_pic_intr(v) && v->domain->arch.hvm.vpic[irq >> 3].int_output ) - hvm_isa_irq_assert(v->domain, irq, NULL); + pt_vector = hvm_isa_irq_assert(v->domain, irq, NULL); else - { pt_vector = hvm_isa_irq_assert(v->domain, irq, vioapic_get_vector); - /* - * hvm_isa_irq_assert may not set the corresponding bit in vIRR - * when mask field of IOAPIC RTE is set. Check it again. - */ - if ( pt_vector < 0 || !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) - pt_vector = -1; - } + + if ( pt_vector < 0 ) + return pt_vector; + break; case PTSRC_ioapic: pt_vector = hvm_ioapic_assert(v->domain, irq, level); - if ( pt_vector < 0 || !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) - { - pt_vector = -1; - if ( level ) + if ( pt_vector < 0 ) + return pt_vector; + + break; + } + + ASSERT(pt_vector >= 0); + if ( !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) + { + time_cb *cb = NULL; + void *cb_priv; + + /* + * Vector has been injected to a different vCPU, call pt_irq_fired and + * execute the callback, since the destination vCPU(s) won't call + * pt_intr_post for it. + * + * TODO: move this vpt to one of the vCPUs where the vector gets + * injected. + */ + spin_lock(&v->arch.hvm.tm_lock); + /* Make sure the timer is still on the list. */ + list_for_each_entry ( pt, &v->arch.hvm.tm_list, list ) + if ( pt == earliest_pt ) { - /* - * Level interrupts are always asserted because the pin assert - * count is incremented regardless of whether the pin is masked - * or the vector latched in IRR, so also execute the callback - * associated with the timer. - */ - time_cb *cb = NULL; - void *cb_priv; - - spin_lock(&v->arch.hvm.tm_lock); - /* Make sure the timer is still on the list. */ - list_for_each_entry ( pt, &v->arch.hvm.tm_list, list ) - if ( pt == earliest_pt ) - { - pt_irq_fired(v, pt); - cb = pt->cb; - cb_priv = pt->priv; - break; - } - spin_unlock(&v->arch.hvm.tm_lock); - - if ( cb != NULL ) - cb(v, cb_priv); + pt_irq_fired(v, pt); + cb = pt->cb; + cb_priv = pt->priv; + break; } - } - break; + spin_unlock(&v->arch.hvm.tm_lock); + + if ( cb != NULL ) + cb(v, cb_priv); + + pt_vector = -1; } return pt_vector; -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:57:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:57:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3c-0006QK-T6; Fri, 12 Jun 2020 15:57:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3b-0006Lr-7v for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:57:27 +0000 X-Inumbo-ID: 68f94766-acc5-11ea-bb8b-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 68f94766-acc5-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 15:57:26 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: e9FMHbQmSlccb0Jggp39FUntV+V/2kY/Ao2hQtNDe/d3ibdKdm+2PCrv+MVa30FpSoq8nCZeyF utxdsI6K51kThM8vjkvV9DuV4cRHN2qFugt9dKv+i0FpLJYEfZ7zCp4wlF1dtLzC1zo0MtASSa RWHL67SkdL4x4mgB/KYbiuNcmyKc1MRIdiIBk4W29SjBYsyLQS/Ci4IGO58uHHHB+9fzAgnTee vbj5DA3vBx8KjhQ109vzwa1cptO6srROKY5cduAcAJGlkmRWtq1nwsJvU56XKVLWtQ4SgfT0GX 2Yc= X-SBRS: 2.7 X-MesageID: 20688217 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20688217" From: Roger Pau Monne To: Subject: [PATCH for-4.14 7/8] x86/hvm: add hardware domain support to hvm_isa_irq_to_gsi Date: Fri, 12 Jun 2020 17:56:39 +0200 Message-ID: <20200612155640.4101-8-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200612155640.4101-1-roger.pau@citrix.com> References: <20200612155640.4101-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The current function has the ISA IRQ 0 hardcoded to GSI 2 for HVM domUs. Allow such function to also be used by the hardware domain by taking into account the ACPI interrupt overwrites in order to get the correct ISA to GSI mappings. This requires passing a domain parameter to the helper, since it's not guaranteed to always be called with current being the destination vCPU. No functional change intended. Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/irq.c | 20 +++++++++++++++++--- xen/arch/x86/hvm/vioapic.c | 2 +- xen/arch/x86/hvm/vpic.c | 7 +++++-- xen/arch/x86/hvm/vpt.c | 5 +++-- xen/arch/x86/io_apic.c | 16 ++++++++-------- xen/include/asm-x86/hvm/irq.h | 2 +- xen/include/asm-x86/io_apic.h | 3 +++ 7 files changed, 38 insertions(+), 17 deletions(-) diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c index fd02cf2e8d..6cbea63f4c 100644 --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include #include @@ -212,12 +213,25 @@ void hvm_gsi_deassert(struct domain *d, unsigned int gsi) spin_unlock(&d->arch.hvm.irq_lock); } +unsigned int hvm_isa_irq_to_gsi(const struct domain *d, unsigned int irq) +{ + int pin, apic; + + if ( !is_hardware_domain(d) ) + return irq ?: 2; + + pin = io_apic_find_isa_irq_pin(irq, mp_INT); + apic = io_apic_find_isa_irq_apic(irq, mp_INT); + + return (pin < 0 || apic < 0) ? irq : (io_apic_gsi_base(apic) + pin); +} + int hvm_isa_irq_assert(struct domain *d, unsigned int isa_irq, int (*get_vector)(const struct domain *d, unsigned int gsi)) { struct hvm_irq *hvm_irq = hvm_domain_irq(d); - unsigned int gsi = hvm_isa_irq_to_gsi(isa_irq); + unsigned int gsi = hvm_isa_irq_to_gsi(d, isa_irq); int vector = -1; ASSERT(isa_irq <= 15); @@ -240,7 +254,7 @@ void hvm_isa_irq_deassert( struct domain *d, unsigned int isa_irq) { struct hvm_irq *hvm_irq = hvm_domain_irq(d); - unsigned int gsi = hvm_isa_irq_to_gsi(isa_irq); + unsigned int gsi = hvm_isa_irq_to_gsi(d, isa_irq); ASSERT(isa_irq <= 15); @@ -754,7 +768,7 @@ static int irq_load_isa(struct domain *d, hvm_domain_context_t *h) * This relies on the PCI IRQ state being loaded first. */ for ( irq = 0; platform_legacy_irq(irq); irq++ ) if ( test_bit(irq, &hvm_irq->isa_irq.i) ) - hvm_irq->gsi_assert_count[hvm_isa_irq_to_gsi(irq)]++; + hvm_irq->gsi_assert_count[hvm_isa_irq_to_gsi(d, irq)]++; return 0; } diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c index e1417cc6a7..34bec715b7 100644 --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -425,7 +425,7 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin) struct vlapic *lapic0 = vcpu_vlapic(d->vcpu[0]); /* Force to pick vCPU 0 if part of the destination list */ - if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() && + if ( (irq == hvm_isa_irq_to_gsi(d, 0)) && pit_channel0_enabled() && vlapic_match_dest(lapic0, NULL, 0, dest, dest_mode) && vlapic_enabled(lapic0) ) target = lapic0; diff --git a/xen/arch/x86/hvm/vpic.c b/xen/arch/x86/hvm/vpic.c index 61f4b6784c..0ce3371a80 100644 --- a/xen/arch/x86/hvm/vpic.c +++ b/xen/arch/x86/hvm/vpic.c @@ -230,6 +230,8 @@ static void vpic_ioport_write( } else { + struct domain *currd = current->domain; + /* OCW2 */ cmd = val >> 5; switch ( cmd ) @@ -260,8 +262,9 @@ static void vpic_ioport_write( /* Release lock and EOI the physical interrupt (if any). */ vpic_update_int_output(vpic); vpic_unlock(vpic); - hvm_dpci_eoi(current->domain, - hvm_isa_irq_to_gsi((addr >> 7) ? (irq|8) : irq), + hvm_dpci_eoi(currd, + hvm_isa_irq_to_gsi(currd, (addr >> 7) ? (irq | 8) + : irq), NULL); return; /* bail immediately */ case 6: /* Set Priority */ diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c index 52ad5b90a7..1b3f902106 100644 --- a/xen/arch/x86/hvm/vpt.c +++ b/xen/arch/x86/hvm/vpt.c @@ -86,7 +86,8 @@ static int pt_irq_vector(struct periodic_time *pt, enum hvm_intsrc src) return pt->irq; isa_irq = pt->irq; - gsi = pt->source == PTSRC_isa ? hvm_isa_irq_to_gsi(isa_irq) : pt->irq; + gsi = pt->source == PTSRC_isa ? hvm_isa_irq_to_gsi(v->domain, isa_irq) + : pt->irq; if ( src == hvm_intsrc_pic ) return (v->domain->arch.hvm.vpic[isa_irq >> 3].irq_base @@ -128,7 +129,7 @@ static int pt_irq_masked(struct periodic_time *pt) if ( !(pic_imr & (1 << (pt->irq & 7))) && vlapic_accept_pic_intr(v) ) return 0; - gsi = hvm_isa_irq_to_gsi(pt->irq); + gsi = hvm_isa_irq_to_gsi(v->domain, pt->irq); } /* Fallthrough to check if the interrupt is masked on the IO APIC. */ diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c index 878ee5192d..1c000e8f76 100644 --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -608,7 +608,7 @@ static int find_irq_entry(int apic, int pin, int type) /* * Find the pin to which IRQ[irq] (ISA) is connected */ -static int __init find_isa_irq_pin(int irq, int type) +int io_apic_find_isa_irq_pin(int irq, int type) { int i; @@ -628,7 +628,7 @@ static int __init find_isa_irq_pin(int irq, int type) return -1; } -static int __init find_isa_irq_apic(int irq, int type) +int io_apic_find_isa_irq_apic(int irq, int type) { int i; @@ -1306,8 +1306,8 @@ static void __init enable_IO_APIC(void) * the i8259 probably is not connected the ioapic but give the * mptable a chance anyway. */ - i8259_pin = find_isa_irq_pin(0, mp_ExtINT); - i8259_apic = find_isa_irq_apic(0, mp_ExtINT); + i8259_pin = io_apic_find_isa_irq_pin(0, mp_ExtINT); + i8259_apic = io_apic_find_isa_irq_apic(0, mp_ExtINT); /* Trust the MP table if nothing is setup in the hardware */ if ((ioapic_i8259.pin == -1) && (i8259_pin >= 0)) { printk(KERN_WARNING "ExtINT not setup in hardware but reported by MP table\n"); @@ -1834,8 +1834,8 @@ static void __init unlock_ExtINT_logic(void) struct IO_APIC_route_entry entry0, entry1; unsigned char save_control, save_freq_select; - pin = find_isa_irq_pin(8, mp_INT); - apic = find_isa_irq_apic(8, mp_INT); + pin = io_apic_find_isa_irq_pin(8, mp_INT); + apic = io_apic_find_isa_irq_apic(8, mp_INT); if ( pin == -1 || apic == -1 ) return; @@ -1913,8 +1913,8 @@ static void __init check_timer(void) /*timer_ack = 1;*/ /*enable_8259A_irq(irq_to_desc(0));*/ - pin1 = find_isa_irq_pin(0, mp_INT); - apic1 = find_isa_irq_apic(0, mp_INT); + pin1 = io_apic_find_isa_irq_pin(0, mp_INT); + apic1 = io_apic_find_isa_irq_apic(0, mp_INT); pin2 = ioapic_i8259.pin; apic2 = ioapic_i8259.apic; diff --git a/xen/include/asm-x86/hvm/irq.h b/xen/include/asm-x86/hvm/irq.h index 532880d497..aa034bc73c 100644 --- a/xen/include/asm-x86/hvm/irq.h +++ b/xen/include/asm-x86/hvm/irq.h @@ -100,7 +100,7 @@ struct hvm_irq { #define hvm_domain_irq(d) ((d)->arch.hvm.irq) #define hvm_irq_size(cnt) offsetof(struct hvm_irq, gsi_assert_count[cnt]) -#define hvm_isa_irq_to_gsi(isa_irq) ((isa_irq) ? : 2) +unsigned int hvm_isa_irq_to_gsi(const struct domain *d, unsigned int irq); /* Check/Acknowledge next pending interrupt. */ struct hvm_intack hvm_vcpu_has_pending_irq(struct vcpu *v); diff --git a/xen/include/asm-x86/io_apic.h b/xen/include/asm-x86/io_apic.h index e006b2b8dd..1c63d1df56 100644 --- a/xen/include/asm-x86/io_apic.h +++ b/xen/include/asm-x86/io_apic.h @@ -205,4 +205,7 @@ unsigned highest_gsi(void); int ioapic_guest_read( unsigned long physbase, unsigned int reg, u32 *pval); int ioapic_guest_write(unsigned long physbase, unsigned int reg, u32 pval); +int io_apic_find_isa_irq_pin(int irq, int type); +int io_apic_find_isa_irq_apic(int irq, int type); + #endif -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:57:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:57:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3e-0006RM-5z; Fri, 12 Jun 2020 15:57:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3c-0006K0-3i for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:57:28 +0000 X-Inumbo-ID: 64878f00-acc5-11ea-b5e3-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 64878f00-acc5-11ea-b5e3-12813bfff9fa; Fri, 12 Jun 2020 15:57:18 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: eRFtV+V4WhEVoVjHDyCMwnWyvoCyKAzxQJKaFS42Ybaa5AaK/TbaSitMe4MGEUWWVFlyq8X3S2 f3+EWI/Ns2FNkYx30rBE4krpVQyHehlYT6KJQKkGHr+4PVrfFz8oyU+OUlDW60iE2BLyBDcfSE B+L2Qe935SRk+mUjCIp9SCOOZIHERNKdjx+g32oADaAl4TqkDG+68q6P6SJxyWUdn7BW3xHCZ8 4yH5ysQPR3jylPczxBDa0cNVkMigf/nMSpg5E3cG3Kw+3C37tcK2PE52UEHn1QyOFSHBc8t/5l XZM= X-SBRS: 2.7 X-MesageID: 20213502 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20213502" From: Roger Pau Monne To: Subject: [PATCH for-4.14 4/8] x86/vpt: only try to resume timers belonging to enabled devices Date: Fri, 12 Jun 2020 17:56:36 +0200 Message-ID: <20200612155640.4101-5-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200612155640.4101-1-roger.pau@citrix.com> References: <20200612155640.4101-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Check whether the emulated device is actually enabled before trying to resume the associated timers. Thankfully all those structures are zeroed at initialization, and since the devices are not enabled they are never populated, which triggers the pt->vcpu check at the beginning of pt_resume forcing an exit from the function. While there limit the scope of i and make it unsigned. Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/vpt.c | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c index 47f2c2aa64..62c87867c5 100644 --- a/xen/arch/x86/hvm/vpt.c +++ b/xen/arch/x86/hvm/vpt.c @@ -636,14 +636,19 @@ static void pt_resume(struct periodic_time *pt) void pt_may_unmask_irq(struct domain *d, struct periodic_time *vlapic_pt) { - int i; - if ( d ) { - pt_resume(&d->arch.vpit.pt0); - pt_resume(&d->arch.hvm.pl_time->vrtc.pt); - for ( i = 0; i < HPET_TIMER_NUM; i++ ) - pt_resume(&d->arch.hvm.pl_time->vhpet.pt[i]); + if ( has_vpit(d) ) + pt_resume(&d->arch.vpit.pt0); + if ( has_vrtc(d) ) + pt_resume(&d->arch.hvm.pl_time->vrtc.pt); + if ( has_vhpet(d) ) + { + unsigned int i; + + for ( i = 0; i < HPET_TIMER_NUM; i++ ) + pt_resume(&d->arch.hvm.pl_time->vhpet.pt[i]); + } } if ( vlapic_pt ) -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 15:57:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 15:57:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3h-0006Tn-Fb; Fri, 12 Jun 2020 15:57:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjm3g-0006Lr-3G for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 15:57:32 +0000 X-Inumbo-ID: 6a382f84-acc5-11ea-bb8b-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6a382f84-acc5-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 15:57:28 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: nk10nRa/UyvEBV7y95MSrL+xvq0BM4oOMyFXxhDkS9COEmbBEEVgBpmDzpoDGprQ6qVnQJMxYY cdUWfwWeyEOknClS0zJXDeJAzX56V9SNb1bAzIY5rfyY9cQPkTd2aCcG5iXeR3h4MGJKkDX/RZ 0oaEMHruPAp2CU86Sx0lGU+UmTq18Z7ngvJzl6ZVwphRqHagPxu6Y0tjkAK+t0ErfuBFmZvxX8 fPjqdMhEY53CPyxatGglmG0Owi38yqd5+pIyGEiCb78J5koTs2qVW8lL1K3u3uexy8P/X3YCkK lpA= X-SBRS: 2.7 X-MesageID: 20688223 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20688223" From: Roger Pau Monne To: Subject: [PATCH for-4.14 8/8] x86/hvm: enable emulated PIT for PVH dom0 Date: Fri, 12 Jun 2020 17:56:40 +0200 Message-ID: <20200612155640.4101-9-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200612155640.4101-1-roger.pau@citrix.com> References: <20200612155640.4101-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Roger Pau Monne , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Some video BIOS require a PIT in order to work properly, hence classic PV dom0 gets partial access to the physical PIT as long as it's not in use by Xen. Since PVH dom0 is built on top of HVM support, there's already an emulated PIT implementation available for use. Tweak the emulated PIT code so it injects interrupts directly into the vIO-APIC if the legacy PIC (i8259) is disabled. Make sure the GSI used matches the ISA IRQ 0 in the likely case there's an interrupt overwrite in the MADT ACPI table. Finally prevent the passthrough of the GSI that belongs to the PIT, since interrupts will be generated by the emulated PIT instead of the physical one. Signed-off-by: Roger Pau Monné --- xen/arch/x86/domain.c | 5 +++-- xen/arch/x86/emul-i8254.c | 12 +++++++++--- xen/arch/x86/hvm/vioapic.c | 9 ++++++++- 3 files changed, 20 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index fee6c3931a..dc0b4c2284 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -512,7 +512,8 @@ static bool emulation_flags_ok(const struct domain *d, uint32_t emflags) if ( is_hvm_domain(d) ) { if ( is_hardware_domain(d) && - emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC) ) + emflags != (X86_EMU_VPCI | X86_EMU_LAPIC | X86_EMU_IOAPIC | + X86_EMU_PIT) ) return false; if ( !is_hardware_domain(d) && emflags != (X86_EMU_ALL & ~X86_EMU_VPCI) && @@ -578,7 +579,7 @@ int arch_domain_create(struct domain *d, emflags = config->arch.emulation_flags; - if ( is_hardware_domain(d) && is_pv_domain(d) ) + if ( is_hardware_domain(d) ) emflags |= XEN_X86_EMU_PIT; if ( emflags & ~XEN_X86_EMU_ALL ) diff --git a/xen/arch/x86/emul-i8254.c b/xen/arch/x86/emul-i8254.c index 73be4188ad..5aef0fe852 100644 --- a/xen/arch/x86/emul-i8254.c +++ b/xen/arch/x86/emul-i8254.c @@ -168,6 +168,7 @@ static void pit_load_count(PITState *pit, int channel, int val) u32 period; struct hvm_hw_pit_channel *s = &pit->hw.channels[channel]; struct vcpu *v = vpit_vcpu(pit); + const struct domain *d = v ? v->domain : NULL; ASSERT(spin_is_locked(&pit->lock)); @@ -190,14 +191,18 @@ static void pit_load_count(PITState *pit, int channel, int val) case 3: /* Periodic timer. */ TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, period); - create_periodic_time(v, &pit->pt0, period, period, 0, pit_time_fired, + create_periodic_time(v, &pit->pt0, period, period, + has_vpic(d) ? 0 : hvm_isa_irq_to_gsi(d, 0), + pit_time_fired, &pit->count_load_time[channel], false); break; case 1: case 4: /* One-shot timer. */ TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, 0); - create_periodic_time(v, &pit->pt0, period, 0, 0, pit_time_fired, + create_periodic_time(v, &pit->pt0, period, 0, + has_vpic(d) ? 0 : hvm_isa_irq_to_gsi(d, 0), + pit_time_fired, &pit->count_load_time[channel], false); break; default: @@ -455,7 +460,8 @@ void pit_reset(struct domain *d) { TRACE_0D(TRC_HVM_EMUL_PIT_STOP_TIMER); destroy_periodic_time(&pit->pt0); - pit->pt0.source = PTSRC_isa; + ASSERT(has_vpic(d) || has_vioapic(d)); + pit->pt0.source = has_vpic(d) ? PTSRC_isa : PTSRC_ioapic; } spin_lock(&pit->lock); diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c index 34bec715b7..8b95e4412f 100644 --- a/xen/arch/x86/hvm/vioapic.c +++ b/xen/arch/x86/hvm/vioapic.c @@ -268,7 +268,14 @@ static void vioapic_write_redirent( spin_unlock(&d->arch.hvm.irq_lock); - if ( is_hardware_domain(d) && unmasked ) + if ( is_hardware_domain(d) && unmasked && + /* + * A PVH dom0 can have an emulated PIT that should respect any + * interrupt overwrites found in the ACPI MADT table, so we need to + * check to which GSI the ISA IRQ 0 is mapped in order to prevent + * identity mapping it. + */ + (!has_vpit(d) || gsi != hvm_isa_irq_to_gsi(d, 0)) ) { /* * NB: don't call vioapic_hwdom_map_gsi while holding hvm.irq_lock -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 16:13:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 16:13:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmJ7-0000vF-9X; Fri, 12 Jun 2020 16:13:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmJ5-0000vA-VG for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 16:13:28 +0000 X-Inumbo-ID: a580d1fc-acc7-11ea-b5eb-12813bfff9fa Received: from EUR01-HE1-obe.outbound.protection.outlook.com (unknown [40.107.13.75]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a580d1fc-acc7-11ea-b5eb-12813bfff9fa; Fri, 12 Jun 2020 16:13:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UwZR5HWYlrQS5AoCP0jInGfvYtHZZIHY5G9rqQDiJoo=; b=D77zEp25ecVdIsoidThdER72i9dQGPoK09HgeHD97I/5WhTbSLyMcnBuIfy1dmTx5qYfODPIVk5Z+4A4AMFA8qAXR5ZKerQZX9NxzA6nfKthvq+Urii5JA27nCwyYLzvriR1LnwNLADq3QX2MT7XfSpypeX+oRkwaLC7crPWLSI= Received: from AM7PR02CA0021.eurprd02.prod.outlook.com (2603:10a6:20b:100::31) by AM0PR08MB3571.eurprd08.prod.outlook.com (2603:10a6:208:d8::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Fri, 12 Jun 2020 16:13:24 +0000 Received: from AM5EUR03FT034.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:100:cafe::2c) by AM7PR02CA0021.outlook.office365.com (2603:10a6:20b:100::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 16:13:24 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT034.mail.protection.outlook.com (10.152.16.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 16:13:24 +0000 Received: ("Tessian outbound fb809da9b456:v59"); Fri, 12 Jun 2020 16:13:24 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 79f39dd9b55dbf46 X-CR-MTA-TID: 64aa7808 Received: from c69eb8c054b9.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3B1CB4AD-52DC-4CCA-AEC4-2712EB389F0D.1; Fri, 12 Jun 2020 16:13:19 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c69eb8c054b9.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Jun 2020 16:13:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cu+ZHR/ZkOG8SqIfbKANV12ClOZWgo8R78f/t7gzfiXLoFVBBVvtm+zZwLyHLLDC3+REP8rrWLumP04jZWxMf/xl+rHYdNUAR2U2Pj9CYQBYU1Tiwg7XhyE+TSyAMc7CrdAGr3986qwSPXa5r6eRR7BYGw3HBxdB/95h75wM0GG/Wn52f6oTptECeiHHiSYH6vTWGcTSAXP9eJAt3VLatzCx5eZCdPZYhD7x8gxMfTAxW04VkJQji+AvWWsRB/JVzRvRo1ovalB/NKIP3qSNDRvDvMa5mMDGef1yP4coQyqkJrDdG2qfiXqRqvkqg9fpisfgEYTEehWt8vn5f/lGAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UwZR5HWYlrQS5AoCP0jInGfvYtHZZIHY5G9rqQDiJoo=; b=ch2w250esYbr5wkL8W/mldslOYh8D2VG+BtYuCe11uvm1oO/t83sruWUt5m8RJIjwz3ls1FMD1xneruQmTERRDKYWS1uKepSlvygHrIWRrcZp/DoJS2QQZpMgDAJELnRFOkt4MAB5OqQ+8ucEhqjjxXnfodzwYFqsk0X6S+HXw6QNNlSNNaeWVj3SL7S/63yzi3vrEB2Kz9piyltAtaMj7YZq7Q73XPxGyTpuQxtDp63nf9ZEMLF8xa0mq/0DqzVsS9+43PlWFqIMiuNzsngaYpzvQBHlvxu52SgC4TRm7oSR8qjlWG8RJgYBxYBdtqkKhdROJFd3OQ0f5ynq2CqBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UwZR5HWYlrQS5AoCP0jInGfvYtHZZIHY5G9rqQDiJoo=; b=D77zEp25ecVdIsoidThdER72i9dQGPoK09HgeHD97I/5WhTbSLyMcnBuIfy1dmTx5qYfODPIVk5Z+4A4AMFA8qAXR5ZKerQZX9NxzA6nfKthvq+Urii5JA27nCwyYLzvriR1LnwNLADq3QX2MT7XfSpypeX+oRkwaLC7crPWLSI= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3307.eurprd08.prod.outlook.com (2603:10a6:5:1b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.23; Fri, 12 Jun 2020 16:13:17 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Fri, 12 Jun 2020 16:13:17 +0000 From: Bertrand Marquis To: Julien Grall Subject: Re: [PATCH 2/2] xen/arm: Support runstate crossing pages Thread-Topic: [PATCH 2/2] xen/arm: Support runstate crossing pages Thread-Index: AQHWP+e8ujbYpkw47EG7vPpL5OIUa6jU5lsAgABClwA= Date: Fri, 12 Jun 2020 16:13:17 +0000 Message-ID: <6FC8B7BD-8CCF-4CC6-8761-0062BC67DAE7@arm.com> References: <0ea51410-050b-58a6-806a-b175f534852f@xen.org> In-Reply-To: <0ea51410-050b-58a6-806a-b175f534852f@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 899ffed3-3180-4f5b-a1c6-08d80eeb88c2 x-ms-traffictypediagnostic: DB7PR08MB3307:|AM0PR08MB3571: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0432A04947 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: gU0rsRz63l7+g9b7SK5Udm3vjMzGsuTSAlU69y5iQsTE3oQlA/EqCDfv5PXSth/E430E4DGjyeXzNzuxuiQ+w/IbQFro1oFB68ZgK/+3os1GEIhLARDEUUxlfyMh7ZeirCv+K3TDDTSPv3gdYV3mdIZCy9uPC7GHwa1r6TTrjlqK62YGr1hAkLVeVlVz/C03SmY9VRA7rLMawvSAUO0Ysdm0QQ2Qo0UysnzQuNxn4DuY9+Y8IOgYm+4RQVyZ77u9x+TAvKsELRXP2Nd21hTNosVLKX76sCFVMQMG1vwlvVIKNbq4N3LzZZTVS9lIUGK1 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(366004)(136003)(376002)(39860400002)(64756008)(66476007)(66556008)(8676002)(316002)(6916009)(8936002)(4326008)(71200400001)(6506007)(76116006)(186003)(66946007)(26005)(478600001)(91956017)(2906002)(53546011)(86362001)(66446008)(54906003)(36756003)(33656002)(2616005)(83380400001)(6512007)(6486002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xDy0tcfl9PUMs8tuIg/AOGCJWHkNNCbcPIPVPAma4nc58OW+0WaQgpP8GV3up6qTzmfh2Z0HREo6rDFC7acjFn7i5ax0N04Vgxy2qhM/hUbDkvF3ZW4g1Bp+LoCimmxGyr12xRaDqg8YhP1VpFHUlxQRijM7R9BYjJ9LZff0ozMGB+gDuxHag/aGBEBLWNYOzmy1HDxQImC4dRd9hJnqK1IqHLQqxvemA1vyfhBomNexuydjt0040Yn2ylVhziVS0/kHyjGBYI4lb3o3wICQA7/PyUaamu3KFsuEEW6xDI/b8cVXniO2mD5UUoxEWGoQLCm6dEWKHdCmzXqE8YBjE3VQhF/9+BXdDR8d7ys3cgc1XWviWHYWGpq5SigcmDoUkDUddJQA1PhHmrCkcxsrHPKX9l7pqnVYWoVYWPKGdLvhuwIf+ud7EqDdbLjnhVspmPE3JjfaiDlhtSHnswzazvg1pzk9oncbg72A56QvZpuFUiX8LPJrdTijcfVVJn08 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <3FAA6B0D7E0DBC4FB4695CB3D1AE8009@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3307 Original-Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT034.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(346002)(396003)(39860400002)(46966005)(86362001)(2906002)(6512007)(6486002)(478600001)(356005)(53546011)(33656002)(70206006)(83380400001)(70586007)(6862004)(6506007)(316002)(8676002)(36906005)(47076004)(82310400002)(2616005)(107886003)(26005)(336012)(4326008)(186003)(5660300002)(54906003)(81166007)(36756003)(8936002)(82740400003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: dd5d3ef1-aaad-4553-a4f8-08d80eeb8471 X-Forefront-PRVS: 0432A04947 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nhExfqhnBuga+NL/QEkCmyRyp4E2dVA2sHEWWTY9DG3Hs8DVUhWAS0mZpM2v6KE2xYQ1OMHpcqRz/Cq6TVd2o4RIny9ucPhD1RP9sJgCSYsDQedk1mmdXB9ADuHn69U1XgnTrfLkR4YhwX3pUOeYyhrdatuvEggFnnxlL1InjOKjfwqIJiXJvgKI3VbS7bmR56NuubwYzFDKUcz7oaCaGzxF8eyFlgrJpg0pMCaegyHByW7ls6h1P4IVQ781uczzy1zqiCptkM07XT9fT0LYmnf62BkshLIH91Wp0InR0F2Uqb5c2upxVenhArdFTsEIOKyVckL1TNvdWzEAleeMbJxrxGq70hV3nZyP9qNNaADTerMFgmnNKH8p7FGbMexN7F1dSTDXeNeqlbWsj283mg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2020 16:13:24.6905 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 899ffed3-3180-4f5b-a1c6-08d80eeb88c2 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3571 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Volodymyr Babchuk , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, > On 12 Jun 2020, at 13:14, Julien Grall wrote: >=20 > Hi, >=20 > On 11/06/2020 12:58, Bertrand Marquis wrote: >> Add support for runstate area register with the structure crossing pages >=20 > Well, this has always been supported until your previous patch. In genera= l, we try to not break thing in a middle of the series so we can still bise= ct it. >=20 > I think this patch can be simplified a lot by mapping the two page contig= uously (see my previous answer). With that it would be feasible to fold thi= s patch in #1. I will dig into switching to something using vmap. Worst case scenario we would consume 8k * 128 vCPU which is still 1M but sh= ould be acceptable as it could simplify greatly the code. >=20 >> The code is storing up to 2 pages reference during the hypercall. >> During a context switch, the code is computing where the >> state_entry_time is and is breaking the memcpy in 2 parts when it is >> required. >> Signed-off-by: Bertrand Marquis >> --- >> xen/arch/arm/domain.c | 101 +++++++++++++++++++++++++---------- >> xen/include/asm-arm/domain.h | 5 +- >> 2 files changed, 76 insertions(+), 30 deletions(-) >> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c >> index 739059234f..d847cb00f2 100644 >> --- a/xen/arch/arm/domain.c >> +++ b/xen/arch/arm/domain.c >> @@ -280,11 +280,16 @@ void arch_cleanup_runstate_guest(struct vcpu *v) >> { >> spin_lock(&v->arch.runstate_guest.lock); >> - /* cleanup previous page if any */ >> - if ( v->arch.runstate_guest.page ) >> + /* cleanup previous pages if any */ >> + if ( v->arch.runstate_guest.page[0] ) >> { >> - put_page_and_type(v->arch.runstate_guest.page); >> - v->arch.runstate_guest.page =3D NULL; >> + put_page_and_type(v->arch.runstate_guest.page[0]); >> + v->arch.runstate_guest.page[0] =3D NULL; >> + if ( v->arch.runstate_guest.page[1] ) >> + { >> + put_page_and_type(v->arch.runstate_guest.page[1]); >> + v->arch.runstate_guest.page[1] =3D NULL; >> + } >=20 > I think this can be moved outside of the first if. Agree >=20 >> v->arch.runstate_guest.offset =3D 0; >> } >> @@ -294,26 +299,25 @@ void arch_cleanup_runstate_guest(struct vcpu *v) >> int arch_setup_runstate_guest(struct vcpu *v, >> struct vcpu_register_runstate_memory_area a= rea) >> { >> - struct page_info *page; >> + struct page_info *page[2] =3D {NULL,NULL}; >=20 > I don't think you need the temporary variable. You can directly update pa= ge[0] as it is protected by the lock. The nice benefits is you could take a= dvantage of a common helper to cleanup and reduce the complexity of the cod= e. Would make sense yes (and remove the unlock everywhere). I will try that, thanks for the hint. >=20 >> unsigned offset; >> spin_lock(&v->arch.runstate_guest.lock); >> - /* cleanup previous page if any */ >> - if ( v->arch.runstate_guest.page ) >> + /* cleanup previous pages if any */ >> + if ( v->arch.runstate_guest.page[0] ) >> { >> - put_page_and_type(v->arch.runstate_guest.page); >> - v->arch.runstate_guest.page =3D NULL; >> + put_page_and_type(v->arch.runstate_guest.page[0]); >> + v->arch.runstate_guest.page[0] =3D NULL; >> + if ( v->arch.runstate_guest.page[1] ) >> + { >> + put_page_and_type(v->arch.runstate_guest.page[1]); >> + v->arch.runstate_guest.page[1] =3D NULL; >> + } >> v->arch.runstate_guest.offset =3D 0; >> } >> offset =3D ((vaddr_t)area.addr.v) & ~PAGE_MASK; >> - if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) >> - { >> - spin_unlock(&v->arch.runstate_guest.lock); >> - gprintk(XENLOG_DEBUG, "Runstate is crossing pages\n"); >> - return -EINVAL; >> - } >> /* provided address must be aligned to a 64bit */ >> if ( offset % alignof(struct vcpu_runstate_info) ) >> @@ -323,15 +327,30 @@ int arch_setup_runstate_guest(struct vcpu *v, >> return -EINVAL; >> } >> - page =3D get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); >> - if ( !page ) >> + page[0] =3D get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); >> + if ( !page[0] ) >> { >> spin_unlock(&v->arch.runstate_guest.lock); >> gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); >> return -EINVAL; >> } >> - v->arch.runstate_guest.page =3D page; >> + if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) >> + { >> + /* guest area is crossing pages */ >> + page[1] =3D get_page_from_gva(v, (vaddr_t)area.addr.v + PAGE_SI= ZE, >> + GV2M_WRITE); >> + if ( !page[1] ) >> + { >> + put_page_and_type(v->arch.runstate_guest.page[0]); > v->arch.runstate_guest.page[0] would be NULL as you set it afterwards. So= you want to set v->arch.runstate_guest.page[0] beforehand. Nice catch, should have been page[0] alone. Thanks Bertrand From xen-devel-bounces@lists.xenproject.org Fri Jun 12 16:17:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 16:17:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmN6-00014Y-QO; Fri, 12 Jun 2020 16:17:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmN5-00014T-Al for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 16:17:35 +0000 X-Inumbo-ID: 39378760-acc8-11ea-b5ee-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 39378760-acc8-11ea-b5ee-12813bfff9fa; Fri, 12 Jun 2020 16:17:34 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 0ptANPNdamrB2YqqU3B9qUCxi2hPq/pKSD1d4fb7k5D24/x1cEw516lweQnGA2sRHVLymi8Vza JQMGRk4o5cjnzUr+gHOx5ulfWEEfoTw/p0Pw1mRD7DvujqqAZzrcT8hnWwuUQM5jdWZKyoTQ9F lUkQfUpsL/ybS3xgzVoI4BQHRMZo+dpbhB5tvUUql/UXd8iWDW0PQ2ZHsgSyPePQDo+zVKMPio TJ4iz6fJvvYfTYX3F4cWKCICJh4lXURy3ZsusLbGyBBLmuRGJBREzXDavQ3HWl45VK+we8uk20 14o= X-SBRS: 2.7 X-MesageID: 20267819 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,503,1583211600"; d="scan'208";a="20267819" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24291.43673.301735.439410@mariner.uk.xensource.com> Date: Fri, 12 Jun 2020 17:17:29 +0100 To: Jan Beulich Subject: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , George Dunlap , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" osstest service owner writes ("[xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved"): > flight 151033 xen-4.10-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/151033/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039 > build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039 > build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039 > build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039 ../../../gnulib/lib/fseeko.c: In function 'rpl_fseeko': ../../../gnulib/lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib." #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib." ^~~~~ make[3]: *** [Makefile:2473: fseeko.lo] Error 1 http://logs.test-lab.xenproject.org/osstest/logs/151033/build-amd64-libvirt/6.ts-libvirt-build.log In principle maybe we could fix this by generating a private libvirt branch with the build fixes ? Or maybe we should simply try plucking a new version of libvirt ? We could update the pinned version in Xen 4.10 to the one from 4.11 ? We might have to do the same for 4.9 then. > test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 > test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 > test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... domainbuilder: detail: XZ: Saw data stream end domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 0x1a7779c domainbuilder: detail: loader probe OK ... domainbuilder: detail: xc_dom_alloc_segment: module0 : 0xffffffff82c00000 -> 0xffffffff82c02000 (pfn 0x2c00 + 0x2 pages) xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed (rc=-5): Internal error libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: No such file or directory http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log ???? Anyone have any ideas ? I would have guessed that this was an incompatibility between pygrub and the boot config made by the new pygrub but git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/ suggests not. As an alternative to trying to fix these, I could arrange for Xen 4.10 and earlier to use stretch rather than buster. 4.10 is end of security support in December and probably stretch will not break too badly for us before then. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 16:40:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 16:40:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmjN-0003Qi-Ma; Fri, 12 Jun 2020 16:40:37 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmjM-0003Qd-MA for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 16:40:36 +0000 X-Inumbo-ID: 6b56c6b8-accb-11ea-b5f2-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6b56c6b8-accb-11ea-b5f2-12813bfff9fa; Fri, 12 Jun 2020 16:40:27 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: gZoIN09Vz+IXXufYqWHQtjrhp2XgWt0qAXqDketWTyqVHlzRn/VDiO5yqmD6rcGabUIEZmg0WY Nq8wycBuRA9bmGo5ovFp0yrjXfucQ4W6Se/LJCFfAQVN1X8bL/X2DaTChhbVDEBk8O7MOPPtMm TwpTEa5z6IthnvZJd4Jx1aPrRtEy7xWZjRroFzbFW4vU7OVYWy4ZWOs5pXUdxTLxAn/hV20BnU Tnzu1990lxZNYHn3j5bT2MSIs+a/JQxl4f3putSTH+dbe1BdGpqED1/I5NYka9OpLsP/T+NlU5 PWc= X-SBRS: 2.7 X-MesageID: 19922826 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,504,1583211600"; d="scan'208";a="19922826" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24291.45045.185355.587474@mariner.uk.xensource.com> Date: Fri, 12 Jun 2020 17:40:21 +0100 To: Nick Rosbrook Subject: Re: [PATCH for-4.14] tools: check go compiler version if present In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , "xen-devel@lists.xenproject.org" , George Dunlap , Wei Liu , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Nick Rosbrook writes ("[PATCH for-4.14] tools: check go compiler version if present"): > Currently, no minimum go compiler version is required by the configure > scripts. However, the go bindings actually will not build with some > older versions of go. Add a check for a minimum go version of 1.11.1 in > accordance with tools/golang/xenlight/go.mod. > diff --git a/tools/configure.ac b/tools/configure.ac > index a9af0a21c6..9d126b7a14 100644 > --- a/tools/configure.ac > +++ b/tools/configure.ac > @@ -338,6 +338,13 @@ AS_IF([test "x$golang" = "xy"], [ > AC_MSG_ERROR([Go tools enabled, but missing go compiler]) > ]) > golang="n" > + ], [ > + AX_COMPARE_VERSION([$GOVERSION], [lt], [1.11.1], [ > + AS_IF([test "x$enable_golang" = "xyes"], [ > + AC_MSG_ERROR(["Your version of go: $GOVERSION is not supported"]) > + ]) > + golang="n" > + ]) > ]) > ]) I don't understand this code. Why are you checking $enable_golang in your new code whereas the old code checks $golang ? I actually read the generated code trying to see where $golang is set and AFAICT it is only ever set to n ? This is all very weird. Surely golang should be enabled by default when the proper compiler is present, and disabled by default otherwise. I think this effect will be quite hard to achieve with AX_ARG_DEFAULT_ENABLE. Probably you should be using AC_ARG_ENABLE and doing the defaulting yourself so that you can use a computed default etc. The docs are not clear but reading the code, AC_ARG_ENABLE sets the variable enable_foo to "no" if --disable-foo is given, to "" if --enable-foo is given, or to the value given to --enable-foo=VALUE. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 16:44:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 16:44:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmnM-0003Zr-8D; Fri, 12 Jun 2020 16:44:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmnL-0003Zl-40 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 16:44:43 +0000 X-Inumbo-ID: 0365ac9e-accc-11ea-bb8b-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0365ac9e-accc-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 16:44:42 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: IjLRnD1CjhquFjV5pHyTMPb8LFKYcG/tJyvf5x9B/YHjixQABN2MIllxhs/IWFsX2JtafQ/AU3 x3sCl6FU5DgkHJlisoZoCy5Rc/vkP58tllufSlu1jQY5XxZxqTiKKn54yGMADxptbIiiIKv/K0 Xr1y1ZZHVNOUHwRbqFQaqwfU4RQMaP2mpac9bVZwAMm62AQx576qhVvRDA/cfCzSMfjUdygOqd zTeJ73HpKaclaTzDh4N+YgCSUdIj1SA5kyFkjCsUKX80fyjnftS0n7T1+21z+32gXfYMElKu0n bqU= X-SBRS: 2.7 X-MesageID: 19938843 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,504,1583211600"; d="scan'208";a="19938843" From: Igor Druzhinin To: Subject: [PATCH] tools/xen-ucode: fix error code propagation of microcode load operation Date: Fri, 12 Jun 2020 17:44:15 +0100 Message-ID: <1591980255-18811-1-git-send-email-igor.druzhinin@citrix.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, wl@xen.org, Igor Druzhinin Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Otherwise it's impossible to know the reason for a fault or blob rejection inside the automation. Signed-off-by: Igor Druzhinin --- tools/misc/xen-ucode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c index 0c257f4..2c907e1 100644 --- a/tools/misc/xen-ucode.c +++ b/tools/misc/xen-ucode.c @@ -62,8 +62,11 @@ int main(int argc, char *argv[]) ret = xc_microcode_update(xch, buf, len); if ( ret ) + { + ret = errno; fprintf(stderr, "Failed to update microcode. (err: %s)\n", strerror(errno)); + } xc_interface_close(xch); @@ -74,5 +77,5 @@ int main(int argc, char *argv[]) } close(fd); - return 0; + return ret; } -- 2.7.4 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 16:47:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 16:47:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmqN-0003iA-NR; Fri, 12 Jun 2020 16:47:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmqM-0003i4-5J for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 16:47:50 +0000 X-Inumbo-ID: 72f935ee-accc-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 72f935ee-accc-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 16:47:49 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: t5u17d6LZp9nU5NWS2xrf7Cyy+4Yk7VwsNEkuMIasjliIsMw/kBwlseXJzvRAMvCPAZnYsCTGP hGcpuzXoU4evL5kqaYyReEaZcYLcmVfMXLoIVbiu2d5JNZYXzJVwsionONrN5gT4LlX73ku33K tvZPF4PBU3OZkCvRXpdljnwCKrflQUieOpe1y7OEt1wVdloDOd6IQn7COtqSNVCjp4TcjvCT9h s319Dr+pKU5Nr9GEGLU8ho87hlmAyAlUNQgEnq1JtRbnwRDSdDPjp/S/Fx11QBtKe3H4/hy7DM n6M= X-SBRS: 2.7 X-MesageID: 20270291 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,504,1583211600"; d="scan'208";a="20270291" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24291.45488.423085.940252@mariner.uk.xensource.com> Date: Fri, 12 Jun 2020 17:47:44 +0100 To: Jan Beulich , "xen-devel@lists.xenproject.org" , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu Subject: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) In-Reply-To: <24291.43673.301735.439410@mariner.uk.xensource.com> References: <24291.43673.301735.439410@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"): > > test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 > > test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 > > test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 > > domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... > domainbuilder: detail: XZ: Saw data stream end > domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 0x1a7779c > domainbuilder: detail: loader probe OK > ... > domainbuilder: detail: xc_dom_alloc_segment: module0 : 0xffffffff82c00000 -> 0xffffffff82c02000 (pfn 0x2c00 + 0x2 pages) > xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed (rc=-5): Internal error > libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: No such file or directory > > http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log > > ???? Anyone have any ideas ? I would have guessed that this was an > incompatibility between pygrub and the boot config made by the new > pygrub but > git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/ > suggests not. Andy suggested on IRC that there were some compression fixes which had perhaps not been backported far enough. I think that's lz4: fix system halt at boot kernel on x86_64 14b62ab3e5a79816edfc6dd3afce1bb68c106ac5 master commit: 5d90ff79542ab9c6eebe5c315c68c196bcf353b9 lz4: refine commit 9143a6c55ef7 for the 64-bit case 6561994b87af3e9cd28ee99c42e8b2697621687d master commit: 2d7572cdfa4d481c1ca246aa1ce5239ccae7eb59 Anyone have any objection to me sending those to 4.10 and maybe 4.9 ? They apply cleanly in both cases. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 16:52:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 16:52:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmuW-0004WA-Df; Fri, 12 Jun 2020 16:52:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmuU-0004W5-Jr for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 16:52:06 +0000 X-Inumbo-ID: 0bb2d45c-accd-11ea-b5f2-12813bfff9fa Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [40.107.6.89]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0bb2d45c-accd-11ea-b5f2-12813bfff9fa; Fri, 12 Jun 2020 16:52:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BPewpLDBkXyUSU8g+/jsWn8aWCQ+Lv8yHI+l5mVWrjc=; b=fL5oEOSUgA1tF+blub+wLIituONe8gtJm0Q05cL8xsMv0YCNVRsHTpBXfITlSVU6X8XevuhTTD4jnRbIiK5C94VwM9qv3GfvlFXozk7tcszZL4n6Fu4s7tldjKBHnfb0NhcefrEDOV4XvNk04xbut31+hrxmwaW5cvQMrlxXk38= Received: from AM6PR0202CA0061.eurprd02.prod.outlook.com (2603:10a6:20b:3a::38) by VI1PR0801MB2096.eurprd08.prod.outlook.com (2603:10a6:800:8b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.20; Fri, 12 Jun 2020 16:52:04 +0000 Received: from AM5EUR03FT009.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:3a:cafe::b4) by AM6PR0202CA0061.outlook.office365.com (2603:10a6:20b:3a::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Fri, 12 Jun 2020 16:52:04 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT009.mail.protection.outlook.com (10.152.16.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Fri, 12 Jun 2020 16:52:03 +0000 Received: ("Tessian outbound 4f5776643448:v59"); Fri, 12 Jun 2020 16:52:03 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 65e3b85bbf713158 X-CR-MTA-TID: 64aa7808 Received: from d28af9e08478.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 716D0625-D6BF-4518-B8E3-FDD8ABB97328.1; Fri, 12 Jun 2020 16:51:58 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d28af9e08478.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 12 Jun 2020 16:51:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gQ1e1HNesZ9xs6Efw7b+b/+Bgk4EwUrRXQIMzh7VZtBFWvlhXKDTieNyHme4iQxfMn+csJPIQ/nWeqsiU0/qNRm5RrYJgzvN7PEyRBlltWiMueuyDORVfrg/cAY8uKjUPT7INM2MSKsxJSq4abdd5Im9mxpnjsFZ4CvMG+/4z2EteZs0kecHI3exMqi4RUEgKPM+LgY8SXBPwF5PlAB2M82OMcG4ifWqDQXtDNgc4TskBsbjaDlRXT/INj40RLR9XC5eX8byF2wHLk5Sjt70wT8AdITshYHpMmGLw/lMwk4vQxDnKZmIwFZ0fA0Wqz4qx34qc1MfOv140xWabTArrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BPewpLDBkXyUSU8g+/jsWn8aWCQ+Lv8yHI+l5mVWrjc=; b=UypFposC7dCEfm/d2umWjZoXqCyOzdTSDBdr9vU4V65pFbay/U8JNDCv223oTXRZhY33fnb/UWSeXxTjyCMBEcvNDkP3W4wmt5Ljnti3rh57kz7h/PYhpSpMgsmhrNvM2rvZlXyYiWNklXwHGcMYhdaOw8/+x37QGhAaXrIYH2CCLzJ/iZo6QYhohj2OcQJXxutkbQWvR2vCFkRI75ZXBmjWqBh7oofE0XpIBHL7wugrMkaz0TTPB/EKI2GYsFcoGVgBhxylTS4c8bErk7xhBh3OOZRvwjSYpCJangjZeWYiiw3mG5DJKDDttL1bM9eil08tbRuf1HwQf0gh+yO14A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BPewpLDBkXyUSU8g+/jsWn8aWCQ+Lv8yHI+l5mVWrjc=; b=fL5oEOSUgA1tF+blub+wLIituONe8gtJm0Q05cL8xsMv0YCNVRsHTpBXfITlSVU6X8XevuhTTD4jnRbIiK5C94VwM9qv3GfvlFXozk7tcszZL4n6Fu4s7tldjKBHnfb0NhcefrEDOV4XvNk04xbut31+hrxmwaW5cvQMrlxXk38= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3018.eurprd08.prod.outlook.com (2603:10a6:5:20::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Fri, 12 Jun 2020 16:51:56 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.021; Fri, 12 Jun 2020 16:51:56 +0000 From: Bertrand Marquis To: Julien Grall Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Topic: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Index: AQHWP+e0l1aGgjLKI0+XFOOVnv/iZKjUz6iAgABkF4A= Date: Fri, 12 Jun 2020 16:51:56 +0000 Message-ID: <71F7AE7B-BB12-4D3B-8337-3FA6040CA632@arm.com> References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <974bf796-d410-9dd7-9e60-873987cd8434@xen.org> In-Reply-To: <974bf796-d410-9dd7-9e60-873987cd8434@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 6b7e4d39-5556-458a-0ffd-08d80ef0ef0d x-ms-traffictypediagnostic: DB7PR08MB3018:|VI1PR0801MB2096: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0432A04947 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: W5IgFPoQfh03WcTuA6laODJ/0slOEirTmPZELOdU2wW3OyxOEZZwOleN79cFPULtym8WVuzE/UprotDiCAMrv1lFUBZwRBtl3fcizdOS0v6wZ/PWrhjX7Y4Qo7pABrAwKGK1VoKqofpqqi0fRRIotjZv7UKbLH6Mkhw7OlXGFSghzChbFC54llD2eRIxQeFtljgcCN9VtZCivxRMZGO0uRydMjms9tBRTSqfAwBWtpTHS1BgySbKcwYA1TXq+cHxNfOlbkzBGtpqOKXD1u/SIo7LS/5XxQhvck9irqjK9gRlM9zYgRMDTYs5W+JaBvK+iRHaWr8uh7u9926e8OA/xQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(346002)(376002)(39860400002)(5660300002)(66556008)(66446008)(33656002)(64756008)(66476007)(86362001)(91956017)(76116006)(2906002)(66946007)(6486002)(7416002)(478600001)(6512007)(316002)(8676002)(36756003)(71200400001)(4326008)(186003)(83380400001)(8936002)(54906003)(6506007)(6916009)(53546011)(2616005)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: nsV+5X/X4wv0qc6dDplK7F0DwwVkzcQ9Oog0jbFXHScDdtnTXdP8CrLf0Zkspi5Gx4ijigAHYbl2aaU5Zn4Qy4zTtJDRZukFbZnuURBbfBvzldKaTumu178v+YjH3sgvNPo0JPFBIn+QU3Sh1nPyBTCJBe14ji3X0VI0DHYdpJgbNuU5GgIS7Ap3jBfApkVplYwhHVsmN+jIJqBT7EzXHH+F0DKFHneEsKCTu1ebFgkkenM06AQ17aoFEfVt9uBOgedNOiFKqBO+KBTAqPwS27N96Z4sdonH6gkEvgJRM+9uJRQTdAhYH+I9YnAkmgdfbLdHlc/bLsYqAcRP2FEgdqh7tjN2X+fiFZfJN3CC1FqwezWht23hdZw1CXj+rewPDKzC9YOghYs+IyLTdQl+HpVmXvIdSXBGz/5EC02qKBHHwLL71Jogqc8FVgfI9iUSaAnH1IY8UPV+3hzym3SBtvVdj6zHRGK683jV/59VlXVu4IdP2T3I6if/Ycs3HK2B x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3DFB93478A72BA41BCC96EDDA6C52830@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3018 Original-Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT009.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(346002)(39860400002)(136003)(46966005)(81166007)(83380400001)(36756003)(82310400002)(356005)(8676002)(6512007)(107886003)(6862004)(8936002)(6486002)(5660300002)(2616005)(33656002)(336012)(478600001)(4326008)(36906005)(2906002)(54906003)(316002)(70206006)(186003)(86362001)(26005)(70586007)(53546011)(82740400003)(47076004)(6506007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: c4753ced-f649-4b6f-6dc7-08d80ef0ead3 X-Forefront-PRVS: 0432A04947 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6osSh7LsY2UgnvEm/dc7KfNVg/WDKXTC/Vjg3bpXIp5cAXW2jtg8lKSoO7cwGWhy3GNz3oe3Kbg4coB1gg9CMc+hYputE0r/BXWKrRrdauIpLQbqJGUEFq9OPMeL5mB3k6z/Acu5sJp0Q+/jm8BBJ377kjf3vlGdL6i3DHGb/sLlbJA9wqG3+Q3tYNlPiJ+N6tpnl9z6C8aFlcowOX9FNJkDFtWl3wzftwXksnHyPSVlWNHFwDR2DuIzIXWZl0OTxnPCjer39P/JBNp2b+GPtRXxuShdYtL55uTwROjbMuLiEMW7o9rmSC+wltxCA7wkykNVQu+y73x3ceHaDXZhgHDJeBhCh0c7sr7eQFgGEoDQnqOCo0I2pq06+slFnKfLDMQljlN9asnp7O9x8Qv9fg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Jun 2020 16:52:03.7297 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6b7e4d39-5556-458a-0ffd-08d80ef0ef0d X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2096 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, > On 12 Jun 2020, at 11:53, Julien Grall wrote: >=20 > Hi Bertrand, >=20 > On 11/06/2020 12:58, Bertrand Marquis wrote: >> At the moment on Arm, a Linux guest running with KTPI enabled will >> cause the following error when a context switch happens in user mode: >> (XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xffffff837ebe0cd0 >=20 > I think you want to add a bit more context explaining the reason on the f= ailure. I.e. this is because the virtual address used by the runstate is on= ly accessible when running in kernel space. >=20 >> This patch is modifying the register runstate area handling on arm to >> convert the guest address during the hypercall. During runtime context >> switches the area is mapped to update the guest runstate copy. >> The patch is also removing the initial copy which was done during the >> hypercall handling as this is done on the current core when the context >> is restore to go back to guest execution on arm. >=20 > This is explaining what the commit does but not why we want to translate = the virtual address at hypercall time. More importantly, this doesn't expla= in the restrictions added on the hypercall and why they are fine. >=20 > Note that they also should be documented in the public header. >=20 >> As a consequence if the register runstate hypercall is called on one >> vcpu for an other vcpu, the area will not be updated until the vcpu >> will be executed (on arm only). >=20 > The code below suggests the hypercall will just fail if you call it from = a different vCPU. Is that correct? >=20 >> On x86, the behaviour is not modified, the address conversion is done >> during the context switch and the area is updated fully during the >> hypercall. >> inline functions in headers could not be used as the architecture >> domain.h is included before the global domain.h making it impossible >> to use the struct vcpu inside the architecture header. >> This should not have any performance impact as the hypercall is only >> called once per vcpu usually. >> Signed-off-by: Bertrand Marquis >> --- >> xen/arch/arm/domain.c | 109 +++++++++++++++++++++++++++++------ >> xen/arch/x86/domain.c | 30 +++++++++- >> xen/arch/x86/x86_64/domain.c | 4 +- >> xen/common/domain.c | 19 ++---- >> xen/include/asm-arm/domain.h | 8 +++ >> xen/include/asm-x86/domain.h | 16 +++++ >> xen/include/xen/domain.h | 4 ++ >> xen/include/xen/sched.h | 16 +---- >> 8 files changed, 153 insertions(+), 53 deletions(-) >> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c >> index 31169326b2..739059234f 100644 >> --- a/xen/arch/arm/domain.c >> +++ b/xen/arch/arm/domain.c >> @@ -19,6 +19,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> @@ -275,36 +276,104 @@ static void ctxt_switch_to(struct vcpu *n) >> virt_timer_restore(n); >> } >> -/* Update per-VCPU guest runstate shared memory area (if registered). = */ >> -static void update_runstate_area(struct vcpu *v) >> +void arch_cleanup_runstate_guest(struct vcpu *v) >=20 > I would prefer if this is name arch_vcpu_cleanup_runstate() as this is pe= r-vCPU and not per-domain information. >=20 >> { >> - void __user *guest_handle =3D NULL; >> - struct vcpu_runstate_info runstate; >> + spin_lock(&v->arch.runstate_guest.lock); >> - if ( guest_handle_is_null(runstate_guest(v)) ) >> - return; >> + /* cleanup previous page if any */ >> + if ( v->arch.runstate_guest.page ) >> + { >> + put_page_and_type(v->arch.runstate_guest.page); >=20 > get_page_from_gva() is only grabbing a reference on the page. So you want= to use put_page() here. >=20 > Note that we don't have type reference on Arm, so it equivalent to put_pa= ge(). But this wouldn't be technically correct :). >=20 >> + v->arch.runstate_guest.page =3D NULL; >> + v->arch.runstate_guest.offset =3D 0; >> + } >> - memcpy(&runstate, &v->runstate, sizeof(runstate)); >> + spin_unlock(&v->arch.runstate_guest.lock); >> +} >> - if ( VM_ASSIST(v->domain, runstate_update_flag) ) >> +int arch_setup_runstate_guest(struct vcpu *v, >> + struct vcpu_register_runstate_memory_area a= rea) >=20 > The indentation looks off here. >=20 > Also, same remark for the naming. >=20 >=20 >> +{ >> + struct page_info *page; >> + unsigned offset; >> + >> + spin_lock(&v->arch.runstate_guest.lock); >> + >> + /* cleanup previous page if any */ >> + if ( v->arch.runstate_guest.page ) >> { >> - guest_handle =3D &v->runstate_guest.p->state_entry_time + 1; >> - guest_handle--; >> - runstate.state_entry_time |=3D XEN_RUNSTATE_UPDATE; >> - __raw_copy_to_guest(guest_handle, >> - (void *)(&runstate.state_entry_time + 1) - = 1, 1); >> - smp_wmb(); >> + put_page_and_type(v->arch.runstate_guest.page); >=20 > Same remark here. Although I would prefer if we try to have a common help= er to cleaning up the runstate. Maybe cleanup_runstate_vcpu_locked()? >=20 >> + v->arch.runstate_guest.page =3D NULL; >> + v->arch.runstate_guest.offset =3D 0; >> + } >> + >> + offset =3D ((vaddr_t)area.addr.v) & ~PAGE_MASK; >> + if ( offset > (PAGE_SIZE - sizeof(struct vcpu_runstate_info)) ) >> + { >> + spin_unlock(&v->arch.runstate_guest.lock); >> + gprintk(XENLOG_DEBUG, "Runstate is crossing pages\n"); >> + return -EINVAL; >> + } >> + >> + /* provided address must be aligned to a 64bit */ >> + if ( offset % alignof(struct vcpu_runstate_info) ) >> + { >> + spin_unlock(&v->arch.runstate_guest.lock); >> + gprintk(XENLOG_DEBUG, "Runstate pointer is not aligned\n"); >> + return -EINVAL; >> + } >> + >> + page =3D get_page_from_gva(v, (vaddr_t)area.addr.v, GV2M_WRITE); >=20 > In the current implementation, 0 was used to unregister the runstate area= . I think we want to keep that feature and not throw an error. >=20 >> + if ( !page ) >> + { >> + spin_unlock(&v->arch.runstate_guest.lock); >> + gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); >> + return -EINVAL; >> } >> - __copy_to_guest(runstate_guest(v), &runstate, 1); >> + v->arch.runstate_guest.page =3D page; >> + v->arch.runstate_guest.offset =3D offset; >> + >=20 > In the current implementation, the runstate area was update with the late= st information during the hypercall. This doesn't seem to happen anymore. I= s there any specific reason? >=20 >> + spin_unlock(&v->arch.runstate_guest.lock); >> + >> + return 0; >> +} >> + >> + >> +/* Update per-VCPU guest runstate shared memory area (if registered). *= / >> +static void update_runstate_area(struct vcpu *v) >> +{ >> + struct vcpu_runstate_info *guest_runstate; >> + void *p; >> + >> + spin_lock(&v->arch.runstate_guest.lock); >> - if ( guest_handle ) >> + if ( v->arch.runstate_guest.page ) >> { >> - runstate.state_entry_time &=3D ~XEN_RUNSTATE_UPDATE; >> + p =3D __map_domain_page(v->arch.runstate_guest.page); >> + guest_runstate =3D p + v->arch.runstate_guest.offset; >> + >> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) >> + { >> + v->runstate.state_entry_time |=3D XEN_RUNSTATE_UPDATE; >> + guest_runstate->state_entry_time |=3D XEN_RUNSTATE_UPDATE; >> + smp_wmb(); >> + } >> + >> + memcpy(guest_runstate, &v->runstate, sizeof(v->runstate)); >> smp_wmb(); >> - __raw_copy_to_guest(guest_handle, >> - (void *)(&runstate.state_entry_time + 1) - = 1, 1); >> + >> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) >> + { >> + v->runstate.state_entry_time &=3D ~XEN_RUNSTATE_UPDATE; >> + guest_runstate->state_entry_time &=3D ~XEN_RUNSTATE_UPDATE; >> + smp_wmb(); >=20 > Why do you need this barrier? >=20 >=20 > [...] >=20 >> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h >> index 4e2f582006..3a7f53e13d 100644 >> --- a/xen/include/asm-arm/domain.h >> +++ b/xen/include/asm-arm/domain.h >> @@ -11,6 +11,7 @@ >> #include >> #include >> #include >> +#include >=20 > Why do you need to add this new include? Sorry I forgot to answer to this one. This is needed to have the definition of vcpu_register_runstate_memory_area= . Bertrand From xen-devel-bounces@lists.xenproject.org Fri Jun 12 16:53:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 16:53:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmw9-0004cg-PZ; Fri, 12 Jun 2020 16:53:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjmw8-0004cY-NW for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 16:53:48 +0000 X-Inumbo-ID: 48853082-accd-11ea-b5f2-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 48853082-accd-11ea-b5f2-12813bfff9fa; Fri, 12 Jun 2020 16:53:47 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: pxFI2Da+eeTPtFqwFes9rTX92L1uHDhEzTJhKZUPNOFGvUW44xplGVm3YoYIW88itrNhiwgrAY ORcduGCSEIWR9SWG/WBujgFl0Zoi/7p3eeYPePM2nPsQNFBTMvY1XDi/WnapFfoFwM+nIA+kKS BIq4K8V8wZHQGrY3dhPx389YHu6ugsaDl9w/hHr22hYTiJcM/frYmv7uoHIOiJ1xax+SaWSsRM p73HGeynEYCjgUxepli+t6JbTGowjtW53a3OFBQtOXzIPYxZjhCcWjlMXJXvy82h86AfihBQ9E jos= X-SBRS: 2.7 X-MesageID: 19939533 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,504,1583211600"; d="scan'208";a="19939533" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24291.45845.782250.165305@mariner.uk.xensource.com> Date: Fri, 12 Jun 2020 17:53:41 +0100 To: Igor Druzhinin Subject: Re: [XEN PATCH for-4.14] tools/xen-ucode: fix error code propagation of microcode load operation In-Reply-To: <1591980255-18811-1-git-send-email-igor.druzhinin@citrix.com> References: <1591980255-18811-1-git-send-email-igor.druzhinin@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , "wl@xen.org" , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Igor Druzhinin writes ("[PATCH] tools/xen-ucode: fix error code propagation of microcode load operation"): > Otherwise it's impossible to know the reason for a fault or blob rejection > inside the automation. ... > fprintf(stderr, "Failed to update microcode. (err: %s)\n", > strerror(errno)); This part is fine. > + ret = errno; > xc_interface_close(xch); ... > } > close(fd); > > - return 0; > + return ret; Unfortunately I don't think this is right. errno might not fit into a return value. Returning nonzero on microcode loading error would definitely be right, but ... ... oh I have just read the rest of this file. I think what is missing here is simply `return errno' (and the braces) There is no need to call xc_interface_close, or munmap, if we are about to exit. I think fixing the lost error return is 4.14 material, so I have added that to the subject line. Paul, would you Release-ack a patch that replaced every `return errno' with (say) exit(12) ? Otherwise, fixing this program not to try to fit errno into an exit status is future work. Also I notice that the program exits 0 if invoked wrongly. Unhelpful! I would want to fix that too. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 17:14:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 17:14:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjnFg-0006Lb-GP; Fri, 12 Jun 2020 17:14:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjnFf-0006LW-P5 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 17:13:59 +0000 X-Inumbo-ID: 1a545758-acd0-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1a545758-acd0-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 17:13:58 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id r7so10510883wro.1 for ; Fri, 12 Jun 2020 10:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=y8Dar2G/LSH5ykpeI+KYX7dYa1DvwTbGtEFoooB9eCU=; b=b8AHygjvK8u5WFrWN1NnCF/M2uzPN7kDgiDojV0WFUuLvfxk6Zv7TTTqpGlJDJxHYR d/Pom8yVYS0pUemlDrJsS6aEgsjhu25MNqiAxqKX9zgJ/bJWt1cPqyIxY/+hq6/nk+cl rzH/tAzBpvlVqKNJjunvHGQCPJor/K2Vhzu8VloG3RXcr8FzwUoNYqePoewQXMGr5bgn GqQy8GAoTEGHZIsZ63XfFjO4qcwJQRRKwiNvLq550zHM3iDqPcdiuzYm3HnsXVyn+Dwl Li1lq3cIS0LchMZopmqIEnWSS4i7+gF8sfpo1TLaHfB7r2C73kAkja6+P9Fyql+wR2/J onfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=y8Dar2G/LSH5ykpeI+KYX7dYa1DvwTbGtEFoooB9eCU=; b=N4W49Sjhh96BB3vH5aVDpZEQzjFiKxkNPNY3jkNWBrVOqBqQ9c19av25lI4QA2Ve/o DCwqYKu1fNPLCRf9szHjObyz8m3XpV1cknvvRbllXjx1jgq9d50Ge9AMcyffdXgYeFjz eaO2Pa+6krvogbL5/D58I5/06s4QTideNOFSbYfkhtD09kZDDt7uRA7D2dN3XSYsaP/K xmkiTybilO5URwAUeAfLYPAWf9WTAt9DSP5okyLeksP9s+mgyoGKSswOiugElg7zwkrF MO7xOXFVScJ2sI1K0YHQ2klVI+JlFl5m343oML2F57G2Oqg0+GE9nU+9ZJ7BQpBZATCg Cerg== X-Gm-Message-State: AOAM532gjJRDXu+6UKrDIpx7N1I1FiQnHsWJHRo0TW0qI2/A1wgNXiPL 4QCMHvem8jJHlH4WdJhVr60= X-Google-Smtp-Source: ABdhPJzW2VniIlb4uF+Oca6CLspz0t1eiC7rqwDxT16+O3r86gOe6EbQ9EkaARkhdaes3TAx6taRTg== X-Received: by 2002:adf:a1d3:: with SMTP id v19mr15824086wrv.245.1591982037976; Fri, 12 Jun 2020 10:13:57 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-226.amazon.com. [54.240.197.226]) by smtp.gmail.com with ESMTPSA id i15sm4071381wre.93.2020.06.12.10.13.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 10:13:57 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Igor Druzhinin'" References: <1591980255-18811-1-git-send-email-igor.druzhinin@citrix.com> <24291.45845.782250.165305@mariner.uk.xensource.com> In-Reply-To: <24291.45845.782250.165305@mariner.uk.xensource.com> Subject: RE: [XEN PATCH for-4.14] tools/xen-ucode: fix error code propagation of microcode load operation Date: Fri, 12 Jun 2020 18:13:56 +0100 Message-ID: <001001d640dc$db8704d0$92950e70$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQH7H4mqvQMhnY7UKzse1ry3GwMkWwKOiXlJqHcE95A= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Paul Durrant' , wl@xen.org, 'Andrew Cooper' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 12 June 2020 17:54 > To: Igor Druzhinin > Cc: xen-devel@lists.xenproject.org; Andrew Cooper ; wl@xen.org; Paul > Durrant > Subject: Re: [XEN PATCH for-4.14] tools/xen-ucode: fix error code propagation of microcode load > operation > > Igor Druzhinin writes ("[PATCH] tools/xen-ucode: fix error code propagation of microcode load > operation"): > > Otherwise it's impossible to know the reason for a fault or blob rejection > > inside the automation. > ... > > fprintf(stderr, "Failed to update microcode. (err: %s)\n", > > strerror(errno)); > > This part is fine. > > > + ret = errno; > > xc_interface_close(xch); > ... > > } > > close(fd); > > > > - return 0; > > + return ret; > > Unfortunately I don't think this is right. errno might not fit into a > return value. I don't understand this part. Why would errno not fit? > Returning nonzero on microcode loading error would > definitely be right, but ... > > ... oh I have just read the rest of this file. > > I think what is missing here is simply `return errno' (and the braces) > There is no need to call xc_interface_close, or munmap, if we are > about to exit. > > I think fixing the lost error return is 4.14 material, so I have > added that to the subject line. > > Paul, would you Release-ack a patch that replaced every `return errno' > with (say) exit(12) ? Why 12? > Otherwise, fixing this program not to try to > fit errno into an exit status is future work. Also I notice that the > program exits 0 if invoked wrongly. Unhelpful! I would want to fix > that too. Agreed that is unhelpful. I'm happy in principle to release-ack something replacing the returns with exits. Paul > > Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 12 17:16:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 17:16:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjnHk-0006RU-TA; Fri, 12 Jun 2020 17:16:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjnHj-0006RO-SY for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 17:16:07 +0000 X-Inumbo-ID: 669f4442-acd0-11ea-bca7-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 669f4442-acd0-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 17:16:06 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: iqxVyR9EOYYFT21DnuJVlUWciVkeM5Z58f1TjKPndd02Sq6Dl6ViiDO0KBpQoiokfaewEbQsxr 5prBjsSJZ4un1gVmaY5yoKhMcX13xfwW27WUbDpLYjZNQqLrR/hbvJ1N3gH0Lip2VM0yaRurHs SZ15ygy7NJKEalSTHOPNZzKMSw1UDHBzDOzNcSHUxRZfmbQ84gramepvz/WN0QkZlbQYRl4QiQ 9SJUYb8d0ANpNpZkNKtaVD02Ex1FODPgKOO1vdiSkIReJvgbdnlIJDCYlkRuHXGdFbnlYFD/k1 JyA= X-SBRS: 2.7 X-MesageID: 20220997 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,504,1583211600"; d="scan'208";a="20220997" Subject: Re: [XEN PATCH for-4.14] tools/xen-ucode: fix error code propagation of microcode load operation To: Ian Jackson References: <1591980255-18811-1-git-send-email-igor.druzhinin@citrix.com> <24291.45845.782250.165305@mariner.uk.xensource.com> From: Igor Druzhinin Message-ID: <2d885485-c00f-9938-33fc-1f20d084b259@citrix.com> Date: Fri, 12 Jun 2020 18:16:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <24291.45845.782250.165305@mariner.uk.xensource.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , "wl@xen.org" , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 17:53, Ian Jackson wrote: > Igor Druzhinin writes ("[PATCH] tools/xen-ucode: fix error code propagation of microcode load operation"): >> Otherwise it's impossible to know the reason for a fault or blob rejection >> inside the automation. > ... >> fprintf(stderr, "Failed to update microcode. (err: %s)\n", >> strerror(errno)); > > This part is fine. > >> + ret = errno; >> xc_interface_close(xch); > ... >> } >> close(fd); >> >> - return 0; >> + return ret; > > Unfortunately I don't think this is right. errno might not fit into a > return value. errno codes that Xen return are all lower than 127. It fits perfectly fine. > Returning nonzero on microcode loading error would > definitely be right, but ... > > ... oh I have just read the rest of this file. > > I think what is missing here is simply `return errno' (and the braces) > There is no need to call xc_interface_close, or munmap, if we are > about to exit. Probably but that is identical to what was suggested. Cleaning resource is just a nice thing to do although unnecessary. Can change to just "return errno" if that's what you'd prefer. > I think fixing the lost error return is 4.14 material, so I have > added that to the subject line. > > Paul, would you Release-ack a patch that replaced every `return errno' > with (say) exit(12) ? That would again conceal real return code from automation. Igor From xen-devel-bounces@lists.xenproject.org Fri Jun 12 17:20:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 17:20:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjnLQ-0006dL-HQ; Fri, 12 Jun 2020 17:19:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjnLP-0006dG-7W for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 17:19:55 +0000 X-Inumbo-ID: ee39802a-acd0-11ea-8496-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ee39802a-acd0-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 17:19:54 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /nQooLJvH6IZHgxgGvmOgqMAoDqd5ohFLsielr+JMRI+KQVnyfVbZT3Ou5TV3HVh9yOg9AdrSZ 3Vq8MMMmscqe1kixsOzAhSwceAt7K1/wNtw0dxYorqHMSkUvcvg1WJ7hcD60keE7PdfUPfvzcA WAVqvIXKaHiFeaVyPEBLOEfTbrjdh835lpYc9KCuxuBsZOQjl120EMrY+VNFjx4kumUcx/Xwzd rTh4jDTJwEt6H5qg9yBjrf7ynLrnFMXMnD+5ZCKQq0zwJJR7j49Wd6FG3Rs1nkI1FK9DFEIlvf IeY= X-SBRS: 2.7 X-MesageID: 20273413 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,504,1583211600"; d="scan'208";a="20273413" Subject: Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) To: Ian Jackson , Jan Beulich , "xen-devel@lists.xenproject.org" , "George Dunlap" , Julien Grall , "Stefano Stabellini" , Wei Liu References: <24291.43673.301735.439410@mariner.uk.xensource.com> <24291.45488.423085.940252@mariner.uk.xensource.com> From: Andrew Cooper Message-ID: Date: Fri, 12 Jun 2020 18:19:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <24291.45488.423085.940252@mariner.uk.xensource.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 17:47, Ian Jackson wrote: > Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"): >>> test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 >>> test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 >>> test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 >> domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... >> domainbuilder: detail: XZ: Saw data stream end >> domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 0x1a7779c >> domainbuilder: detail: loader probe OK >> ... >> domainbuilder: detail: xc_dom_alloc_segment: module0 : 0xffffffff82c00000 -> 0xffffffff82c02000 (pfn 0x2c00 + 0x2 pages) >> xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed (rc=-5): Internal error >> libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: No such file or directory >> >> http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log >> >> ???? Anyone have any ideas ? I would have guessed that this was an >> incompatibility between pygrub and the boot config made by the new >> pygrub but >> git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/ >> suggests not. > Andy suggested on IRC that there were some compression fixes which had > perhaps not been backported far enough. > > I think that's > > lz4: fix system halt at boot kernel on x86_64 > 14b62ab3e5a79816edfc6dd3afce1bb68c106ac5 > master commit: 5d90ff79542ab9c6eebe5c315c68c196bcf353b9 > > lz4: refine commit 9143a6c55ef7 for the 64-bit case > 6561994b87af3e9cd28ee99c42e8b2697621687d > master commit: 2d7572cdfa4d481c1ca246aa1ce5239ccae7eb59 > > Anyone have any objection to me sending those to 4.10 and maybe 4.9 ? > They apply cleanly in both cases. Ah - you found them faster than I did.  Yes - these were the ones I was thinking of. No objections. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 12 17:33:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 17:33:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjnY2-0008Bm-Q4; Fri, 12 Jun 2020 17:32:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjnY1-0008Bh-Ra for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 17:32:57 +0000 X-Inumbo-ID: c047611d-acd2-11ea-b5f7-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c047611d-acd2-11ea-b5f7-12813bfff9fa; Fri, 12 Jun 2020 17:32:56 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: nMAyqSWmwSEvqO3XGye95m8HDLt9j7syn51Sm9Qxz5iTSSZ7CG9xbzTOUl2OihtrLlC7JtOOW0 aWdMGvJmTkRECfAbP3njl75jjtNexLEZ7obYJWEBAmGHuziKG0H0fHNChYHhJamjBwCaFrr45G i+qhypjFqmrEx/biepor8hPgFdSrOmKuuEmPYrA/XJsP/9kAnUUAxhUhRZVx32d8/1hZeuyRiT L1/ztmosGCrAO3A3FiIqpqoHC1HXIKQrBLZeSLN6F0M9bSw1L5nCuA2qWHDm5HKR51/ONLMTzw lTo= X-SBRS: 2.7 X-MesageID: 19927827 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,504,1583211600"; d="scan'208";a="19927827" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.13] tools/libxl: Fix memory leak in libxl_cpuid_set() Date: Fri, 12 Jun 2020 18:32:27 +0100 Message-ID: <20200612173227.4103-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to free() seeing as it discards the results. This is logically a backport of c/s b91825f628 "tools/libxc: Drop config_transformed parameter from xc_cpuid_set()" but rewritten as one caller of xc_cpuid_set() does use returned values. Signed-off-by: Andrew Cooper --- CC: Ian Jackson Applicable for 4.13 and older. I'm not going to touch the Ocaml bindings - they're wrong in multiple ways including this memory leak, and we deleted them in 4.14 because they were totally unused. --- tools/libxl/libxl_cpuid.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c index a78f08b927..083869dcf4 100644 --- a/tools/libxl/libxl_cpuid.c +++ b/tools/libxl/libxl_cpuid.c @@ -420,12 +420,17 @@ void libxl_cpuid_apply_policy(libxl_ctx *ctx, uint32_t domid) void libxl_cpuid_set(libxl_ctx *ctx, uint32_t domid, libxl_cpuid_policy_list cpuid) { - int i; + int i, j; char *cpuid_res[4]; for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) + { xc_cpuid_set(ctx->xch, domid, cpuid[i].input, (const char**)(cpuid[i].policy), cpuid_res); + + for (j = 0; j < ARRAY_SIZE(cpuid_res); ++j) + free(cpuid_res[j]); + } } static const char *input_names[2] = { "leaf", "subleaf" }; -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 12 18:59:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 18:59:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjotA-0006KA-Uw; Fri, 12 Jun 2020 18:58:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjot9-0006K5-VQ for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 18:58:52 +0000 X-Inumbo-ID: c10b2500-acde-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c10b2500-acde-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 18:58:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ezL7bp/xzwP/mka1RJ0ffKGh/yn60yn6ixZjIhZPsbY=; b=2H7Hz0wXgbr2s7IwmMl4Ca4C6 nYsvpwbMp0JL9fC0WxB1g+zHi+Tz8BplVW2oAR1JgAuYlSoXDQlt5mb67i4XQf6mr4MTX55A6q1mz hEzhQknzYv3l8Y0hSGaF9y1P94KjJ0M4ab4i0YaNAe6ggvN/adOcVvnsc8U66lmxoRJCI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjot8-0000Bm-Kb; Fri, 12 Jun 2020 18:58:50 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjot8-0006di-AR; Fri, 12 Jun 2020 18:58:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjot8-0005kI-9l; Fri, 12 Jun 2020 18:58:50 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151063: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=b91825f628c9a62cf2a3a0d972ea81484a8b7fce X-Osstest-Versions-That: xen=2995d0afdf2d3fb44d07eada088db3613741db1e From: osstest service owner Date: Fri, 12 Jun 2020 18:58:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151063 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151063/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce baseline version: xen 2995d0afdf2d3fb44d07eada088db3613741db1e Last test of basis 151053 2020-06-11 23:03:20 Z 0 days Testing same since 151063 2020-06-12 16:00:34 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 2995d0afdf..b91825f628 b91825f628c9a62cf2a3a0d972ea81484a8b7fce -> smoke From xen-devel-bounces@lists.xenproject.org Fri Jun 12 19:25:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 19:25:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjpIw-0000Ji-1L; Fri, 12 Jun 2020 19:25:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjpIv-0000Jd-00 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 19:25:29 +0000 X-Inumbo-ID: 7910b5ea-ace2-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7910b5ea-ace2-11ea-bb8b-bc764e2007e4; Fri, 12 Jun 2020 19:25:28 +0000 (UTC) Subject: Re: [GIT PULL] xen: branch for v5.8-rc1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591989927; bh=9q/une9GhfDWGBwqN44FN6ZXiUpeqgY8P7Aw4ywlCLk=; h=From:In-Reply-To:References:Date:To:Cc:From; b=OT/zUEBtmlewIZxiIRqXsIJKlJcbjk1ofiB89Q0qTMR/T9oyWu5Ia200ifvU+E3yb mRvRVeW4IZV0jqIYlYWx+fwMpj/tWgUCYVNyJDm+Vji5nyWRCobywtenz7SFhso86a R3OSF35VvmWMcuud3GNK2Nxt9qm8o0w+0uF+dSoA= From: pr-tracker-bot@kernel.org In-Reply-To: <20200612053747.13750-1-jgross@suse.com> References: <20200612053747.13750-1-jgross@suse.com> X-PR-Tracked-List-Id: X-PR-Tracked-Message-Id: <20200612053747.13750-1-jgross@suse.com> X-PR-Tracked-Remote: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.8b-rc1-tag X-PR-Tracked-Commit-Id: a952f64d14e5f8461f04cd9d729037db9099ddb0 X-PR-Merge-Tree: torvalds/linux.git X-PR-Merge-Refname: refs/heads/master X-PR-Merge-Commit-Id: d2d5439df22f3c2a07c5db582d4ef1b2b587ca27 Message-Id: <159198992784.4050.12743890623621670472.pr-tracker-bot@kernel.org> Date: Fri, 12 Jun 2020 19:25:27 +0000 To: Juergen Gross X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The pull request you sent on Fri, 12 Jun 2020 07:37:47 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.8b-rc1-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d2d5439df22f3c2a07c5db582d4ef1b2b587ca27 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker From xen-devel-bounces@lists.xenproject.org Fri Jun 12 19:56:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 19:56:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjpmd-0002m1-Ew; Fri, 12 Jun 2020 19:56:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjpmc-0002lw-Hd for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 19:56:10 +0000 X-Inumbo-ID: c2cffe76-ace6-11ea-b60f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c2cffe76-ace6-11ea-b60f-12813bfff9fa; Fri, 12 Jun 2020 19:56:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VBtpWRc8jlMgL2vN/H+qq/4isF6/W9eOPtGCm879mSo=; b=7INsPKZj118d5gcpb90Iuymgkj ZQvB+JYQNr4gIMPvN7B6b51Jm7cMv1TkbMlr3cJcKpkC50A38ZIKu7a3aEtXQLAavjM/cPcFiCgsl VFOUV4BtFcSUK1z/0Y3IZ3BYGxnJrAFQrcTZj78KhsCm60T2ljHmn64XTbvjqvLqA6O0=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjpmX-0001Fe-7e; Fri, 12 Jun 2020 19:56:05 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjpmW-00084s-W0; Fri, 12 Jun 2020 19:56:05 +0000 Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall To: Bertrand Marquis References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <974bf796-d410-9dd7-9e60-873987cd8434@xen.org> <131FB1AE-656D-45E7-9019-FC50F9D5CF0B@arm.com> From: Julien Grall Message-ID: <68f7349e-c773-f0ef-bc77-cbf459796604@xen.org> Date: Fri, 12 Jun 2020 20:56:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <131FB1AE-656D-45E7-9019-FC50F9D5CF0B@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 15:13, Bertrand Marquis wrote: > Hi Julien, Hi, >> On 12 Jun 2020, at 11:53, Julien Grall wrote: >> The code below suggests the hypercall will just fail if you call it from a different vCPU. Is that correct? > > No the hypercall will work, but the area in this case won’t be updated. > When the hypercall is called on the current vcpu, the area will be updated when the context will be restored before returning to the guest so there is no need to do it an extra time in the hypercall itself. I am afraid this is not correct, update_runstate_area() is only called when context switching between 2 vCPUs. So the only way this could be called on return from hypercall is if the vCPU get preempted. > When this is done for a different vcpu the current code is not updating the area anymore. > > I did think at first to do it but the complexity it was adding (mainly due to the dual page case) was very high and I could not really think of a use case or find one in Linux. You may want to have an updated view without forcing the vCPU to exit to the hypervisor and do a context switch. > But now that I think of it I could, in that specific case, use a copy_to_guest. I think you should be able to call update_runstate_area() directly. > > Do you think this is something which would make sense to restore ? I would like to avoid diverging too much from the current definition of the hypercall. In this case, I don't think the restriction you add is necessary. >> >>> + if ( !page ) >>> + { >>> + spin_unlock(&v->arch.runstate_guest.lock); >>> + gprintk(XENLOG_DEBUG, "Runstate pointer is not mapped\n"); >>> + return -EINVAL; >>> } >>> - __copy_to_guest(runstate_guest(v), &runstate, 1); >>> + v->arch.runstate_guest.page = page; >>> + v->arch.runstate_guest.offset = offset; >>> + >> >> In the current implementation, the runstate area was update with the latest information during the hypercall. This doesn't seem to happen anymore. Is there any specific reason? > > As explained before, this is still happening on the current vcpu as a result of the context switch back to the guest at the end of the hypercall. See above, I don't believe this is correct. :). >>> + spin_unlock(&v->arch.runstate_guest.lock); >>> + >>> + return 0; >>> +} >>> + >>> + >>> +/* Update per-VCPU guest runstate shared memory area (if registered). */ >>> +static void update_runstate_area(struct vcpu *v) >>> +{ >>> + struct vcpu_runstate_info *guest_runstate; >>> + void *p; >>> + >>> + spin_lock(&v->arch.runstate_guest.lock); >>> - if ( guest_handle ) >>> + if ( v->arch.runstate_guest.page ) >>> { >>> - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; >>> + p = __map_domain_page(v->arch.runstate_guest.page); >>> + guest_runstate = p + v->arch.runstate_guest.offset; >>> + >>> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) >>> + { >>> + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; >>> + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; >>> + smp_wmb(); >>> + } >>> + >>> + memcpy(guest_runstate, &v->runstate, sizeof(v->runstate)); >>> smp_wmb(); >>> - __raw_copy_to_guest(guest_handle, >>> - (void *)(&runstate.state_entry_time + 1) - 1, 1); >>> + >>> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) >>> + { >>> + v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; >>> + guest_runstate->state_entry_time &= ~XEN_RUNSTATE_UPDATE; >>> + smp_wmb(); >> >> Why do you need this barrier? > > As the bit is supposed to be used to wait for an update to be done, I felt it was better to push this out as soon as possible. smp_wmb() only ensure that any write before the barrier will be seen before after write after the barrier. It doesn't guarantee the other end will see it right after it... > As there is already one after the memcpy, the cost should be fairly limited here. ... so this feel like more a micro-optimization (happy to be proved wrong). The memory barriers are already tricky enough to use/understand, so I would rather not want to use more than necessary. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 20:09:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 20:09:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjpyq-0003nq-HT; Fri, 12 Jun 2020 20:08:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjpyo-0003nl-Gf for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 20:08:46 +0000 X-Inumbo-ID: 84ef2c74-ace8-11ea-b60f-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 84ef2c74-ace8-11ea-b60f-12813bfff9fa; Fri, 12 Jun 2020 20:08:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B7BFCABE3; Fri, 12 Jun 2020 20:08:47 +0000 (UTC) Message-ID: <0fc7034d696bbc601ccf2bd563ef9fb435499eea.camel@suse.com> Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler From: Dario Faggioli To: Julien Grall , Volodymyr Babchuk , "jgross@suse.com" , "xen-devel@lists.xenproject.org" Date: Fri, 12 Jun 2020 22:08:41 +0200 In-Reply-To: <51fce146-f2bd-6098-bef9-2fd925ec7f96@xen.org> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> <7ec7b6568afb3df41f8407015c198b1ccb341c5b.camel@epam.com> <5bd54018f5e045816d25f686124395a1f27a2122.camel@epam.com> <51fce146-f2bd-6098-bef9-2fd925ec7f96@xen.org> Organization: SUSE Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-a9RRqL44kgNEFokXkhUn" User-Agent: Evolution 3.36.3 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "jbeulich@suse.com" , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --=-a9RRqL44kgNEFokXkhUn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2020-06-12 at 13:21 +0100, Julien Grall wrote: > On 12/06/2020 12:33, Volodymyr Babchuk wrote: > > On Fri, 2020-06-12 at 12:29 +0100, Julien Grall wrote: > > > > Basically, this value holds time span between calls to > > > > schedule(). This > > > > variable gets zeroed out every time scheduler requests for time > > > > adjustment value. So, it should not depend on total VM run > > > > time. > > > This is assuming that the scheduler will be called. With the NULL > > > scheduler in place, there is a fair chance this may never be > > > called. > > >=20 > Yeah, this is a good point. I mean, I wouldn't be sure about "never", as even there, we'd probably have softirqs, tasklets, etc... And I still have to look at these patches in more details to figure out properly whether they'd help for this. But I'd say that, in general, we should depend of the frequency of the scheduling events as few as possible. Therefore, using 64 bits from the start would be preferrable IMO. > > > So I think using a 64-bit value is likely safer. > >=20 Yep. > > Well, I wanted to use 64-bit value in the first place. But I got > > the > > impression that atomic_t supports only 32-bit values. At least, > > this is > > what I'm seeing in atomic.h > >=20 > > Am I wrong? >=20 > There is no atomic64_t support in Xen yet. It shouldn't be very=20 > difficult to add support for it if you require them. >=20 Cool! That would be much appreciated. :-D Regards --=20 Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <> (Raistlin Majere) --=-a9RRqL44kgNEFokXkhUn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAl7j4MkACgkQFkJ4iaW4 c+5AZQ//Zei1VtS8e4OqjD3aJm6mfxzS1VVqGut8VzP76PUF56gsqHreChryanVc swlprXxpHd1h7xtmlUzUZCPzWcrtJbFfCpmVQH1iuJ3fL3YpMJevOL+8+2MkUS4S LiewZteqkqPWmbwBTnFkYVxfdX+Lsogme0hv+PRDiePQ2RvzrmVKTo+BFtUVoWnw 5LGWgcUIpcgtC8wVVbTXx4mrHuVRUJcXQBK5b9UZRh7Grwn9TiH19jyMRzaylF3v P30X37UUBHkgfpBgh38XQpka5iOlaCVNcJvAr1UbtjAvCjcdmm5RCujR5nQNlL99 TDE+Br/6teFQpeV8nKv73HII3OFddjXe5Qj68qmBGSBKOdiT0U19mxMq7DbAtSDO wzeFfWGHFins4q4uoZBdO8UJRGbDeCHKFh3I3qgeg3kenBZouZn1H+aJuJps5Su3 89SaN66/OYHj9yDBqThbdE0g2uBRcdgM9tBuOOFH97WDeAtbORBC8nGHEte5vtrG pxPxizZdFyKyQvu/bJDbC7muoPODhilsJd4aF5Qgrn9ST93CGsEASBcH/96TmFki Wc7vAkcd58gALoxm9Nh/658cowUe5OQqy41NAy/2S+gyVswbBmN6tpBXV4H0e0G8 7cXyH9aniT9nvkcIxCDGymtnYyHGhdU/Czt3p317Jb2HaBmrLRM= =McQc -----END PGP SIGNATURE----- --=-a9RRqL44kgNEFokXkhUn-- From xen-devel-bounces@lists.xenproject.org Fri Jun 12 20:31:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 20:31:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjqKv-00069c-GT; Fri, 12 Jun 2020 20:31:37 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjqKu-00069X-Mp for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 20:31:36 +0000 X-Inumbo-ID: b5f4b7d2-aceb-11ea-b611-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b5f4b7d2-aceb-11ea-b611-12813bfff9fa; Fri, 12 Jun 2020 20:31:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=e1TMIE54Q4kiscicTcg3pw4vezN+fiy5hFhuJp2uWD8=; b=wL2sirVTxrkfGr9uhdQXRoevnp 14VY+18z3WkWVdzdCaOdB8UYG2S+QZ2FwJB5KVKtaSoiABPXWaXxUHPEQer+hCrP5BbotPLurb1vQ T/IhIRdSo4sedkfjVhJGVmDRBhXayCDKU358ppW5YlgPcXuIrq1T/YQqBc/jQqqRWsgc=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjqKp-000205-DD; Fri, 12 Jun 2020 20:31:31 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jjqKp-0001OC-5F; Fri, 12 Jun 2020 20:31:31 +0000 Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall To: Bertrand Marquis References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <974bf796-d410-9dd7-9e60-873987cd8434@xen.org> <71F7AE7B-BB12-4D3B-8337-3FA6040CA632@arm.com> From: Julien Grall Message-ID: <2ea01884-a254-47c5-68a7-98ca77afc06b@xen.org> Date: Fri, 12 Jun 2020 21:31:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <71F7AE7B-BB12-4D3B-8337-3FA6040CA632@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 17:51, Bertrand Marquis wrote: Hi, >>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h >>> index 4e2f582006..3a7f53e13d 100644 >>> --- a/xen/include/asm-arm/domain.h >>> +++ b/xen/include/asm-arm/domain.h >>> @@ -11,6 +11,7 @@ >>> #include >>> #include >>> #include >>> +#include >> >> Why do you need to add this new include? > > Sorry I forgot to answer to this one. > This is needed to have the definition of vcpu_register_runstate_memory_area. I might be missing something because nothing you have added this header seem to require vcpu_register_runstate_memory_area. So should the include be done in a different header? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 12 21:06:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 21:06:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjqsE-0000FX-3o; Fri, 12 Jun 2020 21:06:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjqsD-0000FS-5g for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 21:06:01 +0000 X-Inumbo-ID: 83386e06-acf0-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 83386e06-acf0-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 21:05:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z7n8dmGQJ7sabJlerTDWQ7TwMJuCseX4DcSNsEQroAk=; b=PIRRnfk/t113yC4iJsU04eCAe Fzdg5yvHXhG6EaCZp9Qap4UaSPy9akw6pOoHAH29/M8i4YUqZHfLNFCEWhbQt9ivgw3RB1XrZShQH fvRZAjudzaA3NM6CG4NOQ5MJtGQPqwMSMjJYyAEdrjcKAcTeukui0sQlcTvELQt734isI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjqs9-0002dB-Sx; Fri, 12 Jun 2020 21:05:57 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjqs9-0004KG-Hp; Fri, 12 Jun 2020 21:05:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjqs9-0006RA-FL; Fri, 12 Jun 2020 21:05:57 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151044: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression linux-linus:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=b29482fde649c72441d5478a4ea2c52c56d97a5e X-Osstest-Versions-That: linux=5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 From: osstest service owner Date: Fri, 12 Jun 2020 21:05:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151044 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151044/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151016 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151016 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151016 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail blocked in 151016 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151016 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151016 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux b29482fde649c72441d5478a4ea2c52c56d97a5e baseline version: linux 5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 Last test of basis 151016 2020-06-10 12:58:42 Z 2 days Testing same since 151044 2020-06-11 10:29:35 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: "Rafael J. Wysocki" # for the export Abel Vesa Adam Ford Ahmad Fatoum Al Viro Alain Volmat Alan Mikhak Alexander A. Klimov Alexander Duyck Alexandre Belloni Alexei Starovoitov Alexey Gladkov Amelie Delaunay Andrew Morton Andy Shevchenko Anson Huang Anton Ivanov Arnd Bergmann Arne Edholm Baolin Wang Bartosz Golaszewski Bjorn Andersson Bob Moore Boris Brezillon Boris Brezillon Boris Brezillon Borislav Petkov Brian Masney Bryan O'Donoghue Catalin Marinas Chanwoo Choi ChenTao Christoph Hellwig Christophe JAILLET Christophe Kerello Chunyan Zhang Claudiu Beznea Clément Péron Codrin Ciubotariu Colin Ian King Dan Carpenter Dan Murphy Daniel Golle Dave Jiang David Heidelberg David Hildenbrand Dejin Zheng Dinghao Liu Dinh Nguyen Dmitry Osipenko Dmitry Torokhov Eddie James Enric Balletbo i Serra Eric W. Biederman Erik Kaneda Eugeniy Paltsev Fenghua Yu Florian Fainelli Geert Uytterhoeven Geert Uytterhoeven Geordan Neukum Georg Waibel Georgi Djakov Gonglei Green Wan Greg Kroah-Hartman Guennadi Liakhovetski Gustavo A. R. Silva Gustavo Pimentel Hans de Goede Heinrich Schuchardt Hongbo Yao Jason Wang Jason Yan Jasper Korten Jean-Francois Dagenais Jean-Philippe Brucker Jeff LaBundy Jeffrey Hugo Jens Axboe Jerome Brunet Jiada Wang Jiaxun Yang Joe Perches Johnny Chuang Jolly Shah Jonathan Bakker Jonathan Corbet Joseph Lo Julia Lawall Jungseung Lee Kamal Dasu Kamil Konieczny Kejia Hu Kenny Levinsen Konrad Dybcio Kuldeep Singh Lad Prabhakar Leonid Ravich Linus Torvalds Linus Walleij Longpeng(Mike) Lubomir Rintel Luca Ceresoli Ludovic Desroches Lukas Bulwahn Macpaul Lin Manivannan Sadhasivam # actions Mantas Pucka Marc-André Lureau Marcel Ziswiler Marco Elver Marco Felsch Marek Szyprowski Marek Vasut Mark Rutland Markus Elfring Mars Cheng Martin Blumenstingl Masahiro Yamada Masahiro Yamada Mason Yang Matej Genci Mathew King Matti Vaittinen Maxime Ripard Mian Yousaf Kaukab Michael S. Tsirkin Michal Hocko Michal Hocko # for the export Michal Hocko # to export contig range allocator API Michal Simek Michał Mirosław Mike Looijmans Miquel Raynal Nathan Chancellor Nathan Chancellor [build] Neil Armstrong Nicolas Chauvet Nikolay Borisov Owen Chen Pankaj Gupta Paul Cercueil Peng Fan Peter De Schrijver Peter Geis Peter Oberparleiter Peter Ujfalusi Peter Zijlstra Pratyush Yadav Qiushi Wu Quanyang Wang Rafael Gandolfi Rafael J. Wysocki Rahul Tanwar Rajan Vaja Rajat Jain Richard Weinberger Rikard Falkeborn Rob Herring Robert Jarzmik Ron Minnich Samuel Zou Saravana Kannan Sascha Hauer Sebastian Reichel Sebastian Reichel SeongJae Park SeongJae Park Serge Semin Sergei Shtylyov Shawn Guo Shawn Guo Shengju Zhang Shreyas Joshi Sibi Sankar Sivaprakash Murugesan Sowjanya Komatineni Stephan Gerhold Stephen Boyd Sudeep Holla Sylwester Nawrocki Takahiro Kuwano Tang Bin Taniya Das Tejas Patel Tero Kristo Thierry Reding Tobias Schramm Tony Lindgren Tudor Ambarus Ulf Hansson Vignesh Raghavendra Vincent Knecht Vinod Koul Viresh Kumar Waibel Georg Weiyi Lu Will Deacon Wolfram Sang Wolfram Sang # for the I2C part Xiang Chen Xiaoming Ni Xiongfeng Wang Yicong Yang Yoshihiro Shimoda youling257@gmail.com Yuanjiang Yu YueHaibing Yufen Yu Zach van Rijn Zhu Lingshan Álvaro Fernández Rojas 周琰杰 (Zhou Yanjie) jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 12474 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 12 21:50:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 21:50:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjrZL-0004Bz-N8; Fri, 12 Jun 2020 21:50:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjrZJ-0004Bu-Nk for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 21:50:33 +0000 X-Inumbo-ID: bd5832d2-acf6-11ea-bca7-bc764e2007e4 Received: from mail-qk1-x741.google.com (unknown [2607:f8b0:4864:20::741]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bd5832d2-acf6-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 21:50:32 +0000 (UTC) Received: by mail-qk1-x741.google.com with SMTP id n141so10494127qke.2 for ; Fri, 12 Jun 2020 14:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0oAsN8Da8bV+mPgK/NY9uKiEw5ULRZnYyGSVH+RkLeo=; b=tiipPH5xTCb/rPu09rO+U/jYxHp3ZKew0Qek1yYQZdcUV7umjn1MI3YXZrczMZuWyn cvltIZ/d1+ey1sVrpxmPxI9bT1/q2AOHkQ987cce3cdzG750GZ+jd3P1w3AgjCKJhVkE z92wEInOy4eRl0Ft+hhn0ChE4oaadb7CKYeTJYhwNxxUFBnqVRavTrGOlzZNMuxpZxlF NMwWjYd4rUsXdInZBoqFWPb4zBYWZgQlzP3DWAAQkAF6YKL0vgg9DZcBYv3gC9sWNr9D xxClxI0yEhqwjED/9U80+5L83zV1qoZwGcMDIy/6Yy+9TUANlWnvQP8RlqroVSv8G+By senA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0oAsN8Da8bV+mPgK/NY9uKiEw5ULRZnYyGSVH+RkLeo=; b=uMSHAM+wCHFNok84nEgMU48tip3m7Jqni5dysQJP2giuFmASauLC+opUQwRLjnwYuo SeREuEQLFxdp4ouHbvES7ua0AaYg2zlJCQ9I4mXYa5wg1msdMeZUUDV+PiKQtTJbkNAM bct2IzxYhQlERKmo+t01A+9/ga8otfRfOjxZ53BpzGsovC/iojoCnYWhSEYWmisSIXmF xFsmD+9TuNbDM8kA2H4clBQY8+uA1K6CX1bHTBojCyPr596Yj2KquflmhYUzKB7IDEML jG1vDMhDCs/9gv/YlYghG8bR22+G97Z7BxUTCs+CuTtFllKbJaA0TbwDzhZC+2lu3zA+ kCUA== X-Gm-Message-State: AOAM533KNZgtW8c45Gnb/77NU6Wpm/3sNTlS1WY+mrHLEmxAiCaUehrl FmrtS1I3yOK9ALCHaB4etLc= X-Google-Smtp-Source: ABdhPJyHkD5Rd47+7KfRt3nGDn/rAq5qG9ok65w9MW4E5Mu4iiPVha2GK0kcfSk0sApq7ep4MbkXqg== X-Received: by 2002:a05:620a:20db:: with SMTP id f27mr5072976qka.400.1591998632333; Fri, 12 Jun 2020 14:50:32 -0700 (PDT) Received: from six (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252]) by smtp.gmail.com with ESMTPSA id 138sm5532439qkk.38.2020.06.12.14.50.30 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 Jun 2020 14:50:31 -0700 (PDT) Date: Fri, 12 Jun 2020 17:50:28 -0400 From: Nick Rosbrook To: Ian Jackson Subject: Re: [PATCH for-4.14] tools: check go compiler version if present Message-ID: <20200612215028.GA6286@six> References: <24291.45045.185355.587474@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24291.45045.185355.587474@mariner.uk.xensource.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , "xen-devel@lists.xenproject.org" , George Dunlap , Wei Liu , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 12, 2020 at 05:40:21PM +0100, Ian Jackson wrote: > Nick Rosbrook writes ("[PATCH for-4.14] tools: check go compiler version if present"): > > Currently, no minimum go compiler version is required by the configure > > scripts. However, the go bindings actually will not build with some > > older versions of go. Add a check for a minimum go version of 1.11.1 in > > accordance with tools/golang/xenlight/go.mod. > > > diff --git a/tools/configure.ac b/tools/configure.ac > > index a9af0a21c6..9d126b7a14 100644 > > --- a/tools/configure.ac > > +++ b/tools/configure.ac > > @@ -338,6 +338,13 @@ AS_IF([test "x$golang" = "xy"], [ > > AC_MSG_ERROR([Go tools enabled, but missing go compiler]) > > ]) > > golang="n" > > + ], [ > > + AX_COMPARE_VERSION([$GOVERSION], [lt], [1.11.1], [ > > + AS_IF([test "x$enable_golang" = "xyes"], [ > > + AC_MSG_ERROR(["Your version of go: $GOVERSION is not supported"]) > > + ]) > > + golang="n" > > + ]) > > ]) > > ]) > > I don't understand this code. Why are you checking $enable_golang in > your new code whereas the old code checks $golang ? I actually read > the generated code trying to see where $golang is set and AFAICT it is > only ever set to n ? For some background, in an attempt to be consistent with existing code here, I basically copied the logic for enabling the ocaml tools. The logic is setup in a way that (unless --disable-golang is set) if a suitable version of the go compiler is found, then golang is enabled by default. If, however, a suitable go compiler is not found (either go is not present at all, or it is too old), then golang is disabled. This part happens silently unless --enable-golang is _explicitly_ set by the user, in which case an error is thrown by ./configure. This is why $enable_golang is checked. > > This is all very weird. Surely golang should be enabled by default > when the proper compiler is present, and disabled by default > otherwise. I think this effect will be quite hard to achieve with > AX_ARG_DEFAULT_ENABLE. Probably you should be using AC_ARG_ENABLE > and doing the defaulting yourself so that you can use a computed > default etc. I believe the behavior you described here is the same as I described above (and is acheived in this patch). But, I'm happy to re-work the implementation if necessary so that the code is more clear. Thanks, -NR From xen-devel-bounces@lists.xenproject.org Fri Jun 12 22:16:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 22:16:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjryg-0005xm-Sr; Fri, 12 Jun 2020 22:16:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjrye-0005xh-Rl for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 22:16:45 +0000 X-Inumbo-ID: 6468cdf4-acfa-11ea-b619-12813bfff9fa Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.65]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6468cdf4-acfa-11ea-b619-12813bfff9fa; Fri, 12 Jun 2020 22:16:42 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SV/iRpbieaTOguu2iIzL0TqHjFVpnD1ZD7ZYC2cqF2KzJezs8cIHUMPxyq/18jQ3HuACa0WQioxpZc9mf9t3ck6+Uu25UZ/xT/7KFuk+HfL5shKVVIucD6Gq7HpFyg42coM21H+a/HuNv6YEuu0NDFSWqKf7DDSU9OWZTwqi1jUYcO/Y/iDmrNdsNqaoBIgfoLgix2IfWrTiJPb/aEF7KSY4TJAO2uT0lZbeubSuZlQRRM+HUgFPqcssb5F/0egZqajX9FjTS8Nc8TGqEyeqL+FdfzK0oW8t5raaaDVmEzWtHuvY4SjnkMvCgJXE10YCphbOefctVIJOSrRSiSAJCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wp2llx7M4jTT1D7H9z/BnI3QQQ5UWaGGnwXdHkQHQus=; b=RPrfuW6AbyY2mUrwhoz9cnE/laZ41djIHnNOcberzRe4fb2Z/RvBqVoTqtuOOnlywboqVZ42NbmDcx7S27U2WRKeuqHSl2UxEBWXM9DjTIJ/Zc83R2nWnaICIdONQIV4cVa7tAIvWg1vWw2EHPFdLv1biIcFgIQjkA2RGWZnfudWalMrQjjSFJyH2L/NRNdK5jf8uQxtxf02Bhxth2KrO2WYqrH+HQnhoPtv4ZpJpaGUM5nDqqUmbJB7GesG6VDoDocfr+WcRjd3i1d8urhA4EPIcrwbmeHGiQ43bL/twWCfKia+p6gJPcgnKGso8fUyf6JHFesGyiUSZhj+RBu55A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wp2llx7M4jTT1D7H9z/BnI3QQQ5UWaGGnwXdHkQHQus=; b=VpZGBLRp0uiM5qXVixdz+bxOidr/myI+W+GCLSPhuNCN5O/C3Oc03TNDWQUpY+QquniRi6OTF+aqeqKsbalSCRwfd7bKQmgtFkHT8YEnOlvFASAmTSMp6pdQQWc06XH2l+RMrS4ItG3EEPestjXC6zgOH2BX8x1JFq2J0KFyWjftAHKAAoS9RBeXNPaNzXZ/r2JYcxQpjF6rz2+0fcQbmB4XY66+zZgfN8hm1FnXChmg850XWb1X2qUlcb4Rd7e4fe8rmK5Osfjx8oYl7ng5C0Bl9XDlH9OnP7QLdylnxwQ9eTBGwUURhh+ZLnXnlv0Wq2c0DDd9BYBirsQXHA1EHQ== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB2750.eurprd03.prod.outlook.com (2603:10a6:800:e3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 12 Jun 2020 22:16:38 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.025; Fri, 12 Jun 2020 22:16:38 +0000 From: Volodymyr Babchuk To: "jgross@suse.com" , "julien@xen.org" , "xen-devel@lists.xenproject.org" Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Topic: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Index: AQHWQE+Tib/gTK49mk6bUudd1VvXZqjUa0CAgABx3ACAABDmgIAAn6WA Date: Fri, 12 Jun 2020 22:16:37 +0000 Message-ID: <4ce2fd02329d3fa72f7b43d365056a8029996dbb.camel@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <1fcd5d89691b775d1230bf3405e29893107edcb3.camel@epam.com> <92d81acb-fd78-3483-68fb-f52c7bfb3d65@xen.org> In-Reply-To: <92d81acb-fd78-3483-68fb-f52c7bfb3d65@xen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0a9cd00-33a1-444d-7a97-08d80f1e4694 x-ms-traffictypediagnostic: VI1PR0302MB2750: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:923; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8zuE95gai+2n+/CVHJsvDghsat5lb+IRCxoc2K/ZzAJftMUyEcK0WkQ+05bh3aWHvebseqBn2Tgl1VlF5LWE6Cta8uqjyV/LbXvGim0X1Yu8K/sG1tyOoIk3rdl1ZC64k/LpfdSLagrOGtq46XsIPXKJORX4RHh1KVAn4tjyfjBa1ZuOeVkVveda3gVf4lpFHRDchYMoaCuxHajcoYdLV0ieWUrteR+h+Xr4yThmXGllYO2Ip82LrNVhTuxJ5D0ZB9fMB4ca0+ex+VKKc1JF14Kl2Bu8UqslHYxINlPOGeo0RrmfBe8V+szsnw9jKQoiqwEvTv1YIHgRn4Y0g6IUQw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(396003)(366004)(346002)(36756003)(6512007)(8936002)(4326008)(66946007)(66446008)(83380400001)(66476007)(110136005)(91956017)(2616005)(64756008)(8676002)(66556008)(76116006)(66574014)(5660300002)(2906002)(71200400001)(86362001)(55236004)(26005)(316002)(6506007)(54906003)(186003)(478600001)(53546011)(7416002)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EyjWOl5z2WDmL4YQENWD0lqK0FBoU65hurryfU5kT3+0jGydnkho5W+2qSmYwMuVUDxJrQYcvUfgPXJRWIbyWx92CO1CJJ6ddbhlBbW8fxchYtFV4I6zifI3x/bVBNNXWq5CCurZ8mogXs55E1Fokc/O9b7vnHMDpdm85LQ0KUkyGn9Y32o/zlMkI/egSA/mA6bbWSTU+Hy/VIOdGBdu4HhqZVNMLhjUx5juYP1ezn1256XHXMRatmuEslGek0c3lXt4YYh/KFsAdm6WdCxZ6+Mbxn+PvM8iQQuYU9X8cQHvTKroTJydh6VSbWO8rhBdSMb1tl+2anJRqz2mpNmeppo5mdScTUwQSerC+UNwXSlaVurx/kOSeH8w6PMI4fAjJtIA8tS+wQCQncPB5JbUOs1G562nHaFrMbPyblctp5ZaHATU11mRnVRYUM+ffQANlKfpjy8FVtvv+V7zS7Jj+/MtrB2AEBYTyK9g2W0PVe4PwR5RSJO9SiUabBZQtNft x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2D682807789A8340979509E7DC1F55F2@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0a9cd00-33a1-444d-7a97-08d80f1e4694 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 22:16:37.9227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ivICViRzPZq4piAX4F4RkNQRYQoCETR+G+TVp0pqfjLuYicd8J1FMnPzASesZ4Mt8wPIZIfLmP0yJA7pC4oywgjbUDC5AqajJhMtNbKNPz8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB2750 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGkgSnVsaWVuLA0KDQpPbiBGcmksIDIwMjAtMDYtMTIgYXQgMTM6NDUgKzAxMDAsIEp1bGllbiBH cmFsbCB3cm90ZToNCj4gSGkgVm9sb2R5bXlyLA0KPiANCj4gT24gMTIvMDYvMjAyMCAxMjo0NCwg Vm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+ID4gT24gRnJpLCAyMDIwLTA2LTEyIGF0IDA2OjU3 ICswMjAwLCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPiA+ID4gT24gMTIuMDYuMjAgMDI6MjIsIFZv bG9keW15ciBCYWJjaHVrIHdyb3RlOg0KPiA+ID4gPiBBcyBzY2hlZHVsZXIgY29kZSBub3cgY29s bGVjdHMgdGltZSBzcGVudCBpbiBJUlEgaGFuZGxlcnMgYW5kIGluDQo+ID4gPiA+IGRvX3NvZnRp cnEoKSwgd2UgY2FuIHByZXNlbnQgdGhvc2UgdmFsdWVzIHRvIHVzZXJzcGFjZSB0b29scyBsaWtl DQo+ID4gPiA+IHhlbnRvcCwgc28gc3lzdGVtIGFkbWluaXN0cmF0b3IgY2FuIHNlZSBob3cgc3lz dGVtIGJlaGF2ZXMuDQo+ID4gPiA+IA0KPiA+ID4gPiBXZSBhcmUgdXBkYXRpbmcgY291bnRlcnMg b25seSBpbiBzY2hlZF9nZXRfdGltZV9jb3JyZWN0aW9uKCkgZnVuY3Rpb24NCj4gPiA+ID4gdG8g bWluaW1pemUgbnVtYmVyIG9mIHRha2VuIHNwaW5sb2Nrcy4gQXMgYXRvbWljX3QgaXMgMzIgYml0 IHdpZGUsIGl0DQo+ID4gPiA+IGlzIG5vdCBlbm91Z2ggdG8gc3RvcmUgdGltZSB3aXRoIG5hbm9z ZWNvbmQgcHJlY2lzaW9uLiBTbyB3ZSBuZWVkIHRvDQo+ID4gPiA+IHVzZSA2NCBiaXQgdmFyaWFi bGVzIGFuZCBwcm90ZWN0IHRoZW0gd2l0aCBzcGlubG9jay4NCj4gPiA+ID4gDQo+ID4gPiA+IFNp Z25lZC1vZmYtYnk6IFZvbG9keW15ciBCYWJjaHVrIDx2b2xvZHlteXJfYmFiY2h1a0BlcGFtLmNv bT4NCj4gPiA+ID4gLS0tDQo+ID4gPiA+ICAgIHhlbi9jb21tb24vc2NoZWQvY29yZS5jICAgICB8 IDE3ICsrKysrKysrKysrKysrKysrDQo+ID4gPiA+ICAgIHhlbi9jb21tb24vc3lzY3RsLmMgICAg ICAgICB8ICAxICsNCj4gPiA+ID4gICAgeGVuL2luY2x1ZGUvcHVibGljL3N5c2N0bC5oIHwgIDQg KysrLQ0KPiA+ID4gPiAgICB4ZW4vaW5jbHVkZS94ZW4vc2NoZWQuaCAgICAgfCAgMiArKw0KPiA+ ID4gPiAgICA0IGZpbGVzIGNoYW5nZWQsIDIzIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkN Cj4gPiA+ID4gDQo+ID4gPiA+IGRpZmYgLS1naXQgYS94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYyBi L3hlbi9jb21tb24vc2NoZWQvY29yZS5jDQo+ID4gPiA+IGluZGV4IGE3Mjk0ZmY1YzMuLmVlNmIx ZDkxNjEgMTAwNjQ0DQo+ID4gPiA+IC0tLSBhL3hlbi9jb21tb24vc2NoZWQvY29yZS5jDQo+ID4g PiA+ICsrKyBiL3hlbi9jb21tb24vc2NoZWQvY29yZS5jDQo+ID4gPiA+IEBAIC05NSw2ICs5NSwx MCBAQCBzdGF0aWMgc3RydWN0IHNjaGVkdWxlciBfX3JlYWRfbW9zdGx5IG9wczsNCj4gPiA+ID4g ICAgDQo+ID4gPiA+ICAgIHN0YXRpYyBib29sIHNjaGVkdWxlcl9hY3RpdmU7DQo+ID4gPiA+ICAg IA0KPiA+ID4gPiArc3RhdGljIERFRklORV9TUElOTE9DSyhzY2hlZF9zdGF0X2xvY2spOw0KPiA+ ID4gPiArc190aW1lX3Qgc2NoZWRfc3RhdF9pcnFfdGltZTsNCj4gPiA+ID4gK3NfdGltZV90IHNj aGVkX3N0YXRfaHlwX3RpbWU7DQo+ID4gPiA+ICsNCj4gPiA+ID4gICAgc3RhdGljIHZvaWQgc2No ZWRfc2V0X2FmZmluaXR5KA0KPiA+ID4gPiAgICAgICAgc3RydWN0IHNjaGVkX3VuaXQgKnVuaXQs IGNvbnN0IGNwdW1hc2tfdCAqaGFyZCwgY29uc3QgY3B1bWFza190ICpzb2Z0KTsNCj4gPiA+ID4g ICAgDQo+ID4gPiA+IEBAIC05OTQsOSArOTk4LDIyIEBAIHNfdGltZV90IHNjaGVkX2dldF90aW1l X2NvcnJlY3Rpb24oc3RydWN0IHNjaGVkX3VuaXQgKnUpDQo+ID4gPiA+ICAgICAgICAgICAgICAg IGJyZWFrOw0KPiA+ID4gPiAgICAgICAgfQ0KPiA+ID4gPiAgICANCj4gPiA+ID4gKyAgICBzcGlu X2xvY2tfaXJxc2F2ZSgmc2NoZWRfc3RhdF9sb2NrLCBmbGFncyk7DQo+ID4gPiA+ICsgICAgc2No ZWRfc3RhdF9pcnFfdGltZSArPSBpcnE7DQo+ID4gPiA+ICsgICAgc2NoZWRfc3RhdF9oeXBfdGlt ZSArPSBoeXA7DQo+ID4gPiA+ICsgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmc2NoZWRfc3Rh dF9sb2NrLCBmbGFncyk7DQo+ID4gPiANCj4gPiA+IFBsZWFzZSBkb24ndCB1c2UgYSBsb2NrLiBK dXN0IHVzZSBhZGRfc2l6ZWQoKSBpbnN0ZWFkIHdoaWNoIHdpbGwgYWRkDQo+ID4gPiBhdG9taWNh bGx5Lg0KPiA+IA0KPiA+IExvb2tzIGxpa2UgYXJtIGRvZXMgbm90IHN1cHBvcnQgNjQgYml0IHZh cmlhYmxlcy4gPg0KPiA+IEp1bGllbiwgSSBiZWxpZXZlLCB0aGlzIGlzIGFybXY3IGxpbWl0YXRp b24/IFNob3VsZCBhcm12OCB3b3JrIHdpdGggNjQtDQo+ID4gYml0IGF0b21pY3M/DQo+IA0KPiA2 NC1iaXQgYXRvbWljcyBjYW4gd29yayBvbiBib3RoIEFybXY3IGFuZCBBcm12OCA6KS4gSXQganVz dCBoYXZlbid0IGJlZW4gDQo+IHBsdW1iZWQgeWV0Lg0KDQpXb3csIGRpZG4ndCBrbm93IHRoYXQg YXJtdjcgaXMgY2FwYWJsZSBvZiB0aGF0Lg0KDQo+IEkgYW0gaGFwcHkgdG8gd3JpdGUgYSBwYXRj aCBpZiB5b3UgbmVlZCBhdG9taWM2NF90IG9yIGV2ZW4gYSA2NC1iaXQgDQo+IGFkZF9zaXplZCgp Lg0KDQpUaGF0IHdvdWxkIGJlIGNvb2wuIENlcnRhaW5seS4gQnV0IGxvb2tzIGxpa2UgeDg2IGNv ZGUgZG9lcyBub3QgaGF2ZQ0KaW1wbGVtZW50YXRpb24gZm9yIGF0b21pYzY0X3QgYXMgd2VsbC4g U28sIHRoZXJlIHdvdWxkIGJlIGxvdHMgb2YNCmNoYW5nZXMganVzdCBmb3Igb25lIHVzZSBjYXNl LiBJIGRvbid0IGtub3cgaWYgaXQgaXMgd29ydGggaXQuDQoNCkxldCdzIGZpbmlzaCBkaXNjdXNz aW9uIG9mIG90aGVyIHBhcnRzIG9mIHRoZSBzZXJpZXMuIElmIGl0IHdpbGwgYXBwZWFyDQp0aGF0 IGF0b21pYzY0X3QgaXMgYWJzb2x1dGVseSBuZWNlc3NheSwgSSdsbCByZXR1cm4gYmFjayB0byB5 b3UuDQpUaGFua3MgZm9yIG9mZmVyIGFueXdheXMuIA0KDQo= From xen-devel-bounces@lists.xenproject.org Fri Jun 12 22:25:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 22:25:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjs7D-0006oq-PM; Fri, 12 Jun 2020 22:25:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjs7C-0006ol-Bt for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 22:25:34 +0000 X-Inumbo-ID: a079f5d8-acfb-11ea-bca7-bc764e2007e4 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (unknown [40.107.5.47]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a079f5d8-acfb-11ea-bca7-bc764e2007e4; Fri, 12 Jun 2020 22:25:32 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eEZIO+R7d7d/2BWRQRvWV80PwxOpPlNJssH/K9zZN7HuABHVd+0Z7TNSxQfGUASNN5NDsRF2ZpaBGG4P1HUBo2ABM+NDMSY/G28xaPEGA835OdSWZpKdTZg22zSRzr4vL35k+L6njMd1+UKarSrSNwSJvbSNUxuZEanzp6x5NeUPC6ewQodmojw3kyPYh865MmPre6BRvxbCXe94bKh6Ty5HB+oZcNu13vhNcn3Y7+/w81eIxOmMuPJdTxMFky8bONBidaJp7prLeH74/wj2pkekDvQuUuA8wHUMC/hfWLFpnGodSILC3i5F88S+2ltvDvdR7Hu13BBe0F6dxiQSyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=swL4Ojj8gGjj5D3rZ9uED1BRECcyUb+YJ5SHAd6V9xk=; b=YQ+ixaOuhWjMVCydZziLI6aLTZBWJ6UIutkDfkG7m0nhsoKmzdOin3BIQIrV2mKghKna1SkGd46ZJqxlIH7P+JNErq57jqfJYAZ5yGO1vNOExUAlabMUimAsWjr4DlsV+HZMjAgfBfI183lOTxnW3Lk53s4v6OAGjwGbnFToMhIKQw6uALkfkjK6o0B2zp7nLVfeK8GW7j+p7ERnOVFKsXtFmWg65eWmnbjiwKML3mhz/Wva5ATxxVWoKDq5Aa3R0DpvqvRYz5GmknBfP2d3Y2z1yct4RCoPSx476O+eZ2/ChmJJRwBmfa1T8T7MGbtOyilNkD1rL7EtmIvTXzQh5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=swL4Ojj8gGjj5D3rZ9uED1BRECcyUb+YJ5SHAd6V9xk=; b=kEHttdGn30TOJsdMLloe6718yGHltVjdOdBDcPblMBBajTRYjbC1D/f2/yNa9enLSx24VHXoVZUS3EJG/I7uGUKljAUTtcdBNogNA3tpv0cv/Ec6Wn6iZaRN06Gww35PD91WeCEHJwJ67IiDLR2+VgaD5fYS1U1XbTTca02HkKgl3eMi/lppNj7R5NMxcMlWRNVOWzKtz/X7Q9WbStx5MO9agxImryCPN1w4OQwzpSI+yYyOy+Fl0JJyyVnk74g3XPY7x4x7vkQMbu0M7bZ4v/Wcx1NgPptMSpUubfIRpIgpSkof5kw36xxhiu9jH21Ck7PauE7dQYTD6unkBFKoeg== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB3341.eurprd03.prod.outlook.com (2603:10a6:803:25::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Fri, 12 Jun 2020 22:25:29 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.025; Fri, 12 Jun 2020 22:25:29 +0000 From: Volodymyr Babchuk To: "dfaggioli@suse.com" , "jgross@suse.com" , "julien@xen.org" , "xen-devel@lists.xenproject.org" Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler Thread-Topic: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler Thread-Index: AQHWQE+STyWApsQdk0CG54zgwiPygKjUZV2AgAByxQCAAADXAIAAAQ+AgAANYwCAAIJ+gIAAJjcA Date: Fri, 12 Jun 2020 22:25:29 +0000 Message-ID: <9e92fd70d92da18caa9e6345b4ce35b86f88605e.camel@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> <7ec7b6568afb3df41f8407015c198b1ccb341c5b.camel@epam.com> <5bd54018f5e045816d25f686124395a1f27a2122.camel@epam.com> <51fce146-f2bd-6098-bef9-2fd925ec7f96@xen.org> <0fc7034d696bbc601ccf2bd563ef9fb435499eea.camel@suse.com> In-Reply-To: <0fc7034d696bbc601ccf2bd563ef9fb435499eea.camel@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 318ad227-28dc-4c0d-f249-08d80f1f838d x-ms-traffictypediagnostic: VI1PR0302MB3341: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N2Ipgixd8mdrMiimoSVechLOU2AIWqQK11ThPQAa4bDZFckmv3Ym6QCjD/SJMI7AeORZozZHNyEymXByj8nyonFUR7JYEC/f7Ut5s1JHEyEnXUfSUbkH9mUEaYiUlpqPmd5YWSFtXlr0hVTd4kjUP/nqwa/ZQUlX9b/xE0OzneSUaYRRUfhsfsNo0riuOhjSOaa2yFUMnHRsb0YQSqoiOepGbyFmTUXz+DzmGCvaOOSKOodzgDmn9IiGo0xgh2h0VLPlVdUcgTmNuOCrzQ8t7Ircwdi1zfjp0WtR+ZEA6Te4sUMmomJ74spAZlZj86e/i5j8sjnOX8JUCjXJfVvX3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(346002)(376002)(136003)(2616005)(54906003)(36756003)(186003)(316002)(478600001)(83380400001)(86362001)(4326008)(110136005)(6512007)(5660300002)(71200400001)(6506007)(66556008)(66476007)(55236004)(76116006)(91956017)(66446008)(64756008)(26005)(7416002)(66946007)(2906002)(6486002)(53546011)(8676002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 8qaJUm8ELhwaJHjaV33s9uod8y42gBIYzZoOrRXWqZYT46Q7GA/RQYTruBLpxmnPJBn/Hq7mrxjH6J0azt5aVkOzdMYHSAFo82FvjmwiflRX77Z3L5IY0OQX38hTOEs3A1EQY/aiAUl752MwHbQKi1sYdDFyuK4R0yuIYuA9poA/HCrsNCd74rTyHnN3XB6StBIViTB1OjToHsiwSwUfP7XtEg4rcSmc+CcU6mXsOCJ2gBOP9kNhMqurizWL7aVFjfjPfFIKucy0hxQZr+7Ih2ghNV4wDbVTRL1CDtXlZk3gt+blmu3GRJOAVrb0jq/TgrPdcpnKkdwqit0ukyvw60L8xHNrylROxk6yupSWH5ETq94If8l6eOstgUS/66S0CXDHodQuv+unPgIf6cJrf9pHwCY9hG404fSxGt+15/yDGSw2qBzUcexiYR63V/uutyj3UxIO3Fmr8bXavYJYnEusgAuzfiZD6ctq2Md6+acu30PompxAQ+u3/uvwgQA9 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 318ad227-28dc-4c0d-f249-08d80f1f838d X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 22:25:29.6636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5umR+ZDJjDo2i3jr7KliBImXwp4cSe+g23rO6EAGOQSSE27wQU+1lFjFg4zuSqSu21uggxNm/2t70pmQOf9nq69BAhD5zsVO09RrQWzjqKc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB3341 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "jbeulich@suse.com" , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGkgRGFyaW8sDQoNCk9uIEZyaSwgMjAyMC0wNi0xMiBhdCAyMjowOCArMDIwMCwgRGFyaW8gRmFn Z2lvbGkgd3JvdGU6DQo+IE9uIEZyaSwgMjAyMC0wNi0xMiBhdCAxMzoyMSArMDEwMCwgSnVsaWVu IEdyYWxsIHdyb3RlOg0KPiA+IE9uIDEyLzA2LzIwMjAgMTI6MzMsIFZvbG9keW15ciBCYWJjaHVr IHdyb3RlOg0KPiA+ID4gT24gRnJpLCAyMDIwLTA2LTEyIGF0IDEyOjI5ICswMTAwLCBKdWxpZW4g R3JhbGwgd3JvdGU6DQo+ID4gPiA+ID4gQmFzaWNhbGx5LCB0aGlzIHZhbHVlIGhvbGRzIHRpbWUg c3BhbiBiZXR3ZWVuIGNhbGxzIHRvDQo+ID4gPiA+ID4gc2NoZWR1bGUoKS4gVGhpcw0KPiA+ID4g PiA+IHZhcmlhYmxlIGdldHMgemVyb2VkIG91dCBldmVyeSB0aW1lIHNjaGVkdWxlciByZXF1ZXN0 cyBmb3IgdGltZQ0KPiA+ID4gPiA+IGFkanVzdG1lbnQgdmFsdWUuIFNvLCBpdCBzaG91bGQgbm90 IGRlcGVuZCBvbiB0b3RhbCBWTSBydW4NCj4gPiA+ID4gPiB0aW1lLg0KPiA+ID4gPiBUaGlzIGlz IGFzc3VtaW5nIHRoYXQgdGhlIHNjaGVkdWxlciB3aWxsIGJlIGNhbGxlZC4gV2l0aCB0aGUgTlVM TA0KPiA+ID4gPiBzY2hlZHVsZXIgaW4gcGxhY2UsIHRoZXJlIGlzIGEgZmFpciBjaGFuY2UgdGhp cyBtYXkgbmV2ZXIgYmUNCj4gPiA+ID4gY2FsbGVkLg0KPiA+ID4gPiANCj4gWWVhaCwgdGhpcyBp cyBhIGdvb2QgcG9pbnQuIEkgbWVhbiwgSSB3b3VsZG4ndCBiZSBzdXJlIGFib3V0ICJuZXZlciIs DQo+IGFzIGV2ZW4gdGhlcmUsIHdlJ2QgcHJvYmFibHkgaGF2ZSBzb2Z0aXJxcywgdGFza2xldHMs IGV0Yy4uLiBBbmQgSQ0KPiBzdGlsbCBoYXZlIHRvIGxvb2sgYXQgdGhlc2UgcGF0Y2hlcyBpbiBt b3JlIGRldGFpbHMgdG8gZmlndXJlIG91dA0KPiBwcm9wZXJseSB3aGV0aGVyIHRoZXknZCBoZWxw IGZvciB0aGlzLg0KDQpXZWxsLiBJIHRoaW5rLCBpdCBpcyBwb3NzaWJsZSB0byByZXNldCBjb3Vu dGVycyB3aGVuIHdlIGFyZSBzd2l0Y2hpbmcNCnRvIGEgZGlmZmVyZW50IHNjaGVkdWxlci4gSnVz dCBmb3IgY2FzZXMgbGlrZSB0aGF0Lg0KDQo+IEJ1dCBJJ2Qgc2F5IHRoYXQsIGluIGdlbmVyYWws IHdlIHNob3VsZCBkZXBlbmQgb2YgdGhlIGZyZXF1ZW5jeSBvZiB0aGUNCj4gc2NoZWR1bGluZyBl dmVudHMgYXMgZmV3IGFzIHBvc3NpYmxlLiBUaGVyZWZvcmUsIHVzaW5nIDY0IGJpdHMgZnJvbSB0 aGUNCj4gc3RhcnQgd291bGQgYmUgcHJlZmVycmFibGUgSU1PLg0KDQpJIHNob3VsZCBkb25lIHRo YXQgY2FsY3VsYXRpb24gZWFybGllci4uLiBTbywgaXQgYXBwZWFycyB0aGF0IDMyIGJpdA0KY291 bnRlciBjYW4gY291bnQgdXAgdG8gNCBtZXJlIHNlY29uZHMuIEl0IHNob3VsZCBiZSBlbm91Z2h0 IGZvciBub3JtYWwNCmZsb3cuIEJ1dCBJJ20gYWdyZWUgd2l0aCB5b3UgLSA2NCBiaXRzIGxvb2tz IG11Y2ggc2FmZXIuIA0KDQo+IA0KPiA+ID4gPiBTbyBJIHRoaW5rIHVzaW5nIGEgNjQtYml0IHZh bHVlIGlzIGxpa2VseSBzYWZlci4NCj4gWWVwLg0KPiANCj4gPiA+IFdlbGwsIEkgd2FudGVkIHRv IHVzZSA2NC1iaXQgdmFsdWUgaW4gdGhlIGZpcnN0IHBsYWNlLiBCdXQgSSBnb3QNCj4gPiA+IHRo ZQ0KPiA+ID4gaW1wcmVzc2lvbiB0aGF0IGF0b21pY190IHN1cHBvcnRzIG9ubHkgMzItYml0IHZh bHVlcy4gQXQgbGVhc3QsDQo+ID4gPiB0aGlzIGlzDQo+ID4gPiB3aGF0IEknbSBzZWVpbmcgaW4g YXRvbWljLmgNCj4gPiA+IA0KPiA+ID4gQW0gSSB3cm9uZz8NCj4gPiANCj4gPiBUaGVyZSBpcyBu byBhdG9taWM2NF90IHN1cHBvcnQgaW4gWGVuIHlldC4gSXQgc2hvdWxkbid0IGJlIHZlcnkgDQo+ ID4gZGlmZmljdWx0IHRvIGFkZCBzdXBwb3J0IGZvciBpdCBpZiB5b3UgcmVxdWlyZSB0aGVtLg0K PiA+IA0KPiBDb29sISBUaGF0IHdvdWxkIGJlIG11Y2ggYXBwcmVjaWF0ZWQuIDotRA0KPiANCg0K Q2VydGFpbmx5ISA6KQ0KDQpJIGJlbGlldmUsIHRoZXJlIHdpbGwgYmUgYW5vdGhlciB1c2VycyBm b3IgYXRtaWM2NF90IGFzIHdlbGwuDQoNCg0K From xen-devel-bounces@lists.xenproject.org Fri Jun 12 22:26:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 22:26:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjs7x-0006sV-2p; Fri, 12 Jun 2020 22:26:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjs7w-0006sP-N8 for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 22:26:20 +0000 X-Inumbo-ID: bc929766-acfb-11ea-b619-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bc929766-acfb-11ea-b619-12813bfff9fa; Fri, 12 Jun 2020 22:26:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SVhRmEEQS30Yuefkkj/159pdzYZMrJvfgUsVqDC2GE0=; b=2jHO5TvkTzJtK+kdU156uROBy 7WwyrTU3pw1d7Wfa1f3e16a1W/oux5itlR0vkpJ2Ea2U0tOMLyouRvbP3Fp0eqkFLH9bZTb9MuECc x6UeE4Ml7pyGDXCsfYbv7GBLYYRe/73TqVX7GvzSMfKzE5PKGF/1aaqMkpHXqJL1RC6uA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjs7u-00044c-BG; Fri, 12 Jun 2020 22:26:18 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjs7u-0007Ev-3T; Fri, 12 Jun 2020 22:26:18 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjs7u-0005pY-2U; Fri, 12 Jun 2020 22:26:18 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151047: tolerable FAIL - PUSHED X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=9e7f1469b9994d910fc1b185c657778bde51639c X-Osstest-Versions-That: qemuu=31d321c2b3574dcc74e9f6411af06bca6b5d10f4 From: osstest service owner Date: Fri, 12 Jun 2020 22:26:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151047 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151047/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150970 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150970 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150970 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150970 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150970 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150970 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass version targeted for testing: qemuu 9e7f1469b9994d910fc1b185c657778bde51639c baseline version: qemuu 31d321c2b3574dcc74e9f6411af06bca6b5d10f4 Last test of basis 150970 2020-06-09 20:36:22 Z 3 days Testing same since 151047 2020-06-11 10:36:56 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Emilio G. Cota Fabiano Rosas Paolo Bonzini Peter Maydell Philippe Mathieu-Daudé Philippe Mathieu-Daudé jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/qemu-xen.git 31d321c2b3..9e7f1469b9 9e7f1469b9994d910fc1b185c657778bde51639c -> upstream-tested From xen-devel-bounces@lists.xenproject.org Fri Jun 12 22:27:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 22:27:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjs9A-00071A-Hp; Fri, 12 Jun 2020 22:27:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjs99-000714-7W for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 22:27:35 +0000 X-Inumbo-ID: e8a5cfc6-acfb-11ea-8496-bc764e2007e4 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (unknown [40.107.5.52]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e8a5cfc6-acfb-11ea-8496-bc764e2007e4; Fri, 12 Jun 2020 22:27:33 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c8wE5PIIcjnrnBa5qCRO/jWdkesSwAOYUztS0JA1Wzr9m+OjLt310MbJn3+qjlD1B0hxTLzLloH6LunF5j6NLEt2dekJgXHGc1o/2Y7kP6mSARnUgbNNjsG6gWqM7OvnFfuEmrmIHjAMj3LZOmqyvwhPmOz+7zhg5XYwfvo3+Qzzx2mc0UW8xcpsDT+q2YfpIXG3N99BMFmbp4du9z1pdJvkxKh4cx1xHEzZpm7l1PweSvzHyiW+UzuYxfBjDiUyk0s8vp4cHZjvcwIPXYF+j7hhOA1wIrUYHH+PtEBdL/SSBOV0WVAyFzdozcY7Igi3RkgoPD6wuKy8KFDGpPCWFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CX7rNOWmTwqIS4t0nZcNAiKNmekxJymKS62aZAzJS1E=; b=X0FOqdItB0Wm2XnCx2ts01kyXerKIkRfbWQ2ogIyhUj1385f982trBgQMe6Yoa1I0mDknuF4DZiGX1Vz+H4CEPCeGauyoNlBFbsYIiSu1mX0szBkVfQGjlydpXzp9blCwuEPVReEElM+PeWiVw8L89KAWw3V7p8Wz817BeZDvQiLqy6ko2RLJ3/N0qMZmyF+YUMZX86lBZtn7N0KqeheUprrd+b5a8pt8yfkWT9bv8Rmm31YifmQdtwqBHCO6afVtgS9rIQwIlnDzeOTbaC4/5zQb0ivuswQpTNlbtd2eGmXk8rmKwHU6HEHS3O5TiURCZpLNQt7LxbaXecwg1wt0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CX7rNOWmTwqIS4t0nZcNAiKNmekxJymKS62aZAzJS1E=; b=c7GZH7TN3vhMv751iOxH6DDle50+Uxskq+NKGG4N2X6fBFzHhKNVB3A40jnt7eovFA0C+G3BgA2aQLm5NUh05YvZAceYPMrpbegSCr+yU6x0bJT2DVDq/N2sh48dUksuBTLWvJnSGbPUB6xrfbU7Y9W3Qte8eJGs/J7wPBsuyJrknVqiP7rcL/D++JmHltiDOska3Fxwt3MpR9Q7LSeOPIRNYujsvC33voYSrZtQzQY7KttsfEkk2B6Cxr2wnelLHqyJzdL8UNjWwd20+N9ygHWqO2HLY2N7vExj6Z3+RLRVueRmY/BVmFoUXVDHA41f+SpsfkWXTrWLmIt8F7e9Fg== Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com (2603:10a6:803:23::18) by VI1PR0302MB3341.eurprd03.prod.outlook.com (2603:10a6:803:25::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Fri, 12 Jun 2020 22:27:32 +0000 Received: from VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75]) by VI1PR0302MB3407.eurprd03.prod.outlook.com ([fe80::a01e:c0b1:7174:4c75%5]) with mapi id 15.20.3088.025; Fri, 12 Jun 2020 22:27:32 +0000 From: Volodymyr Babchuk To: "dfaggioli@suse.com" , "jgross@suse.com" , "julien@xen.org" , "xen-devel@lists.xenproject.org" Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Topic: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Index: AQHWQE+Tib/gTK49mk6bUudd1VvXZqjUa0CAgAB+fACAAANFAIAALvMAgAB0vgA= Date: Fri, 12 Jun 2020 22:27:31 +0000 Message-ID: References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> <78910b5c27a3711726d53e931feb075c5cc4a64c.camel@suse.com> In-Reply-To: <78910b5c27a3711726d53e931feb075c5cc4a64c.camel@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9223f21-e098-4302-28c2-08d80f1fcc63 x-ms-traffictypediagnostic: VI1PR0302MB3341: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0432A04947 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BT2KpsWyjUhN4jT0C1ZHBfu6LpaS324KBZcspMGDrf3wCCMcuwbdn7XrP7Z8S6vluC7RjgcTMzsFk8kbkGYkG46oYN0U+X8JmaG/a3leuCzBVZtNFLQ5R+lRhS6YEbWOlqzAq06diauAe+UO8ke7VaSceo9SJzk1PfkjAMjjouUV0MBmloUWPjgZDZV4eCuYGJABGm99EUwx0IG5PWESJSEcUlup7CtlpS8N9FjonzGwjYJSeOF0Sv4aneCMwwxSeH0qalYcVwN7Ks8cKAsX3NPu35tcXG95s6aXaeSrMTfuAEw8g2PHI5pNrrwFqzCooRmuYpTrQ4N607f+ntLS6w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0302MB3407.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(346002)(376002)(136003)(2616005)(54906003)(66574014)(36756003)(186003)(316002)(478600001)(83380400001)(86362001)(4326008)(110136005)(6512007)(5660300002)(71200400001)(6506007)(66556008)(66476007)(55236004)(76116006)(91956017)(66446008)(64756008)(26005)(7416002)(66946007)(2906002)(6486002)(53546011)(8676002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DG+z4yymIVNgz66BONdykFWKsh+gZ04diMzVaAHNsBO9YQ+kqooEHFrIZ9Oy7BMx8NQkjzrp4fdgnvMUzVBdy3o0r6Vx6JTN2BDTu7XPquT8u4kN3Dog1M2NwFsXKL+11nCDh/erioOjKdNBqgxemiqq9HjrSEVZwqi/uKLFN5o+Je4aiDVuwxTWb3Hzwa6lBz+WS7lmRPxXE9ovvv0Zdt6HSIJIcjcwhh4aLiCDgRffUGDaGyRwGZEwpWkBeShp5uvDZNstvzg5egyR3BW5EnxnJcCiq/uLYk8dNKqrVLwg0NeSkZ/Pe4sA55po/fH2VG97kKWQpNAZCQTI4K+HS8pffRIJxYuL6YarKs2CoIUfTc/yAQDji/J7AzlCvPej3S93viUhgkDLRYs8mLNVg/0KQi5IlnO/iRSN5mnLBlC9PXQnQ3oe00uG/1NEViJMevw7g/Ke3bcYXcPXsgGiXUtsyYsJGmzmInxxNYVOOnsr7pX1JJWZGYJTEuNeMp2/ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4336E91F02C45E498A0B6603F2224509@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: b9223f21-e098-4302-28c2-08d80f1fcc63 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 22:27:31.9409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ytZxDGSgKij9EQhWN/SI9Q9wVcErvSsaBhqVes7a9iYRx5HJzBGfJPfSnaHnU1LLoUGRkIIf6UMhndzEOy4rroDO8fxTASEYCUgUTyV/BYE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB3341 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "jbeulich@suse.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gRnJpLCAyMDIwLTA2LTEyIGF0IDE3OjI5ICswMjAwLCBEYXJpbyBGYWdnaW9saSB3cm90ZToN Cj4gT24gRnJpLCAyMDIwLTA2LTEyIGF0IDE0OjQxICswMjAwLCBKw7xyZ2VuIEdyb8OfIHdyb3Rl Og0KPiA+IE9uIDEyLjA2LjIwIDE0OjI5LCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+ID4gPiBPbiAx Mi8wNi8yMDIwIDA1OjU3LCBKw7xyZ2VuIEdyb8OfIHdyb3RlOg0KPiA+ID4gPiBPbiAxMi4wNi4y MCAwMjoyMiwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+ID4gPiA+ID4gQEAgLTk5NCw5ICs5 OTgsMjIgQEAgc190aW1lX3Qgc2NoZWRfZ2V0X3RpbWVfY29ycmVjdGlvbihzdHJ1Y3QgDQo+ID4g PiA+ID4gc2NoZWRfdW5pdCAqdSkNCj4gPiA+ID4gPiAgICAgICAgICAgICAgIGJyZWFrOw0KPiA+ ID4gPiA+ICAgICAgIH0NCj4gPiA+ID4gPiArICAgIHNwaW5fbG9ja19pcnFzYXZlKCZzY2hlZF9z dGF0X2xvY2ssIGZsYWdzKTsNCj4gPiA+ID4gPiArICAgIHNjaGVkX3N0YXRfaXJxX3RpbWUgKz0g aXJxOw0KPiA+ID4gPiA+ICsgICAgc2NoZWRfc3RhdF9oeXBfdGltZSArPSBoeXA7DQo+ID4gPiA+ ID4gKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZzY2hlZF9zdGF0X2xvY2ssIGZsYWdzKTsN Cj4gPiA+ID4gDQo+ID4gPiA+IFBsZWFzZSBkb24ndCB1c2UgYSBsb2NrLiBKdXN0IHVzZSBhZGRf c2l6ZWQoKSBpbnN0ZWFkIHdoaWNoIHdpbGwNCj4gPiA+ID4gYWRkDQo+ID4gPiA+IGF0b21pY2Fs bHkuDQo+ID4gPiANCj4gPiA+IElmIHdlIGV4cGVjdCBzY2hlZF9nZXRfdGltZV9jb3JyZWN0aW9u IHRvIGJlIGNhbGxlZCBjb25jdXJyZW50bHkNCj4gPiA+IHRoZW4gd2UgDQo+ID4gPiB3b3VsZCBu ZWVkIHRvIGludHJvZHVjZSBhdG9taWM2NF90IG9yIGEgc3BpbiBsb2NrLg0KPiA+IA0KPiA+IE9y IHdlIGNvdWxkIHVzZSBwZXJjcHUgdmFyaWFibGVzIGFuZCBhZGQgdGhlIGNwdSB2YWx1ZXMgdXAg d2hlbg0KPiA+IGZldGNoaW5nIHRoZSB2YWx1ZXMuDQo+ID4gDQo+IFllcywgZWl0aGVyIHBlcmNw dSBvciBhdG9taWMgbG9va3MgbXVjaCBiZXR0ZXIgdGhhbiBsb2NraW5nLCB0byBtZSwgZm9yDQo+ IHRoaXMuDQoNCkxvb2tzIGxpa2Ugd2UgZ29pbmcgdG8gaGF2ZSBhdG9taWM2NF90IGFmdGVyIGFs bC4gU28sIEknbGwgcHJlZmVyIHRvIHRvDQp1c2UgYXRvbWljcyB0aGVyZS4NCg== From xen-devel-bounces@lists.xenproject.org Fri Jun 12 22:55:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 12 Jun 2020 22:55:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjsZu-00011d-QY; Fri, 12 Jun 2020 22:55:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjsZt-00011Y-8W for xen-devel@lists.xenproject.org; Fri, 12 Jun 2020 22:55:13 +0000 X-Inumbo-ID: c57dc22a-acff-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c57dc22a-acff-11ea-b7bb-bc764e2007e4; Fri, 12 Jun 2020 22:55:12 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id r7so11555232wro.1 for ; Fri, 12 Jun 2020 15:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dy1aaxvtcuz3mnfTAC2yz+cvULYV+C1JJaaRRKPziOQ=; b=ZC8ITsYj/qpLOUiQqonDHkkHEX628REBBL1p5zXMaqWhFiJqX3MjIQVz85ObEOGb4X FJfUep/LzfTIvw23OesoS1Rq4lLgEY2yCL5SvTY+uduuXuosGeis6j300Z8j/0gSY4yz hjFLsQB6KH8l+0Iu/vnxtWtG4rg7QQU164F2WQvMFWoIBov9zASMifQKssJziG8jj+ky 6VQLh+XpHMj9GJdGTJU5aSGzL185afYoIOL9IkgdzjEEQW7Dwcj6OBk5nuuV996R6xld IqtE96tyx0/sNll7NL9PJjOwSJCT74HQ1mq+F39uYlrV0cRtpM0tWoPHxFtqVqQs5sGn sMLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dy1aaxvtcuz3mnfTAC2yz+cvULYV+C1JJaaRRKPziOQ=; b=gWdfhIZV4nYibbJuZ2DN2KuK1QNGBmCYKmyh4Sk58O4/uIVUnwVyjsQJqOke/io+tu zDJS/QsFUpx3QeT1V2kRhWVfqaksYiwzTNcO47jAUSoto/IxqVj50s8tJKdXNQ9RGlF3 /O1iMRnBZRwZyrcUSYGjscROINfcIaLTBOQQi0OhoqY15vRoxzUo7e+PtM+IHjxCoZA0 soGcv58mUIo3U/IWX+gjnZy3cCvNPw+LwOShyLQ8m/35FTwj7xsiMlc4EAbJcJTlFwMg OyHO92qp+V4Q/iTf+B4Qh9ks8jsEPxE2g069NDCIGouSTg1JE7lftiboOXyeae8BGAZT pHTQ== X-Gm-Message-State: AOAM532kF8ByjkI+3Zwhvo3xaaaZxwERgqKOI8ua7YTbaHGQLETjHThI 16RhJlYl4opQZOypw0EDQSkV1e5z+ZlJfi7avro= X-Google-Smtp-Source: ABdhPJzI8DPRPPsqQXLiJSeicdIJBq0mgLRlQ5KlW7ZQvZayvtkIWn18k9v9fgDzt13Qkl/gwG/kzcu3UEZ+fQp2ZlU= X-Received: by 2002:adf:f790:: with SMTP id q16mr17657632wrp.399.1592002511356; Fri, 12 Jun 2020 15:55:11 -0700 (PDT) MIME-Version: 1.0 References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> <0ce0bbf8-fd15-e87b-727c-56dd7c09cdcb@suse.com> <7ec7b6568afb3df41f8407015c198b1ccb341c5b.camel@epam.com> <5bd54018f5e045816d25f686124395a1f27a2122.camel@epam.com> <51fce146-f2bd-6098-bef9-2fd925ec7f96@xen.org> <0fc7034d696bbc601ccf2bd563ef9fb435499eea.camel@suse.com> In-Reply-To: <0fc7034d696bbc601ccf2bd563ef9fb435499eea.camel@suse.com> From: Julien Grall Date: Fri, 12 Jun 2020 23:54:59 +0100 Message-ID: Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler To: Dario Faggioli Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , "roger.pau@citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 12 Jun 2020 at 21:08, Dario Faggioli wrote: > > On Fri, 2020-06-12 at 13:21 +0100, Julien Grall wrote: > > On 12/06/2020 12:33, Volodymyr Babchuk wrote: > > > On Fri, 2020-06-12 at 12:29 +0100, Julien Grall wrote: > > > > > Basically, this value holds time span between calls to > > > > > schedule(). This > > > > > variable gets zeroed out every time scheduler requests for time > > > > > adjustment value. So, it should not depend on total VM run > > > > > time. > > > > This is assuming that the scheduler will be called. With the NULL > > > > scheduler in place, there is a fair chance this may never be > > > > called. > > > > > > > Yeah, this is a good point. I mean, I wouldn't be sure about "never", > as even there, we'd probably have softirqs, tasklets, etc... And I > still have to look at these patches in more details to figure out > properly whether they'd help for this. Unlike x86, Xen doesn't prod another pCPU consistently. :) This was already discussed in multiple threads in the past (see [1] which not resolved yet). So yes, I am pretty confident I can recreate a case where the scheduling function may never be called on Arm :). Cheers, [1] 315740e1-3591-0e11-923a-718e06c36445@arm.com From xen-devel-bounces@lists.xenproject.org Sat Jun 13 00:24:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 00:24:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjtyB-0000L8-Cm; Sat, 13 Jun 2020 00:24:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjty9-0000L3-Ib for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 00:24:21 +0000 X-Inumbo-ID: 3940eb90-ad0c-11ea-b62a-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3940eb90-ad0c-11ea-b62a-12813bfff9fa; Sat, 13 Jun 2020 00:24:20 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 283A820739; Sat, 13 Jun 2020 00:24:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592007859; bh=WtYzOAGm8F6NDuTj6ACYHcybAzqMxQYB6yVaeujxXg4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UMVjGDNQNPjMH6f6ROfdzAO4EotnlBf2VCN+udDI481c5B5qjkpBQX6JqG/kWucua ZhrRLDORFSFoOJgY47b1nZLIv+TCtD3el6xMv11aLIIYrNVBFdel/VYz4w7lMccRpt 7xKAP7xKU4qKtsoFVbCFFNGaRTQnvk7kaN4vLDyg= Date: Fri, 12 Jun 2020 17:24:18 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall In-Reply-To: Message-ID: References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Bertrand Marquis , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 12 Jun 2020, Julien Grall wrote: > > Writing byte by byte is a different case. That is OK. In that case, the > > guest could see the state after 3 bytes written and it would be fine and > > consistent. > > Why? What does actually prevent a guest to see an in-between value? > > To give a concrete example, if the original value is 0xabc and you want to > write 0xdef. Why would the guest never see 0xabf or 0xaec? That is a good question, but the minimum granularity is 1 byte, so if current: 0xaabbcc new: 0xddeeff Can the guest see one of the following? 0xaabbff 0xaaeecc Yes, it can. I don't think it is a problem in this case because we only change 1 byte, so to continue with the example: current: 0xaabbcc new: 0xffbbcc So the only values the VM can see are either 0xaabbcc or 0xffbbcc. > > If this hadn't been the case, then yes, the existing code > > would also be buggy. > > > > So if we did the write with a memcpy, it would be fine, no need for > > atomics: > > > > memcpy(&guest_runstate->state_entry_time, > > &v->runstate.state_entry_time, > > XXX); > > > > > > The |= case is different: GCC could implement it in any way it likes, > > including going through a zero-write to any of the bytes in the word, or > > doing an addition then a subtraction. GCC doesn't make any guarantees. > > If we want guarantees we need to use atomics. > > Yes GCC can generate assembly for |= in any way it likes. But so does for > memcpy(). So I still don't understand why one would be fine for you and not > the other... It is down to the implementation of memcpy to guarantee that the only thing memcpy does is memory copies. memcpy doesn't specify whether it is going to use byte-copies or word-copies, but it should only do copies. If we have to write memcpy in assembly to make it so, so be it :-) From xen-devel-bounces@lists.xenproject.org Sat Jun 13 00:24:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 00:24:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjtyJ-0000LV-Km; Sat, 13 Jun 2020 00:24:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjtyI-0000LQ-H1 for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 00:24:30 +0000 X-Inumbo-ID: 3f0e6386-ad0c-11ea-b62a-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3f0e6386-ad0c-11ea-b62a-12813bfff9fa; Sat, 13 Jun 2020 00:24:30 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1265220739; Sat, 13 Jun 2020 00:24:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592007869; bh=hhAXpZ9T/WtwESP/EZN2wTcknQmo1c2sAeZm+M29/gI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GVUruxbBC8ODbFP2uQ33+k4D0fUwsvJwHfChTLs92dBToyemjrSdxZknhYax0lLcW gbPzzqtWJEwWNMiXd6JiNa9EDtBex+lbcu3BAWOn9kklkrLYIvrwx791mk7ugLJ61G +iv5Dk+FcdwJZllilXbL0IGTBD0WmtdeEK3ahJUo= Date: Fri, 12 Jun 2020 17:24:28 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Bertrand Marquis Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall In-Reply-To: <48F66B8F-3AEF-4E54-A572-C246F5A7C117@arm.com> Message-ID: References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> <48F66B8F-3AEF-4E54-A572-C246F5A7C117@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-993750421-1591980292=:2815" Content-ID: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-993750421-1591980292=:2815 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 12 Jun 2020, Bertrand Marquis wrote: > > On 12 Jun 2020, at 02:09, Stefano Stabellini wrote: > > > > On Thu, 11 Jun 2020, Julien Grall wrote: > >> Hi Stefano, > >> > >> On 11/06/2020 19:50, Stefano Stabellini wrote: > >>> On Thu, 11 Jun 2020, Julien Grall wrote: > >>>>>> + return -EINVAL; > >>>>>> } > >>>>>> > >>>>>> - __copy_to_guest(runstate_guest(v), &runstate, 1); > >>>>>> + v->arch.runstate_guest.page = page; > >>>>>> + v->arch.runstate_guest.offset = offset; > >>>>>> + > >>>>>> + spin_unlock(&v->arch.runstate_guest.lock); > >>>>>> + > >>>>>> + return 0; > >>>>>> +} > >>>>>> + > >>>>>> + > >>>>>> +/* Update per-VCPU guest runstate shared memory area (if registered). > >>>>>> */ > >>>>>> +static void update_runstate_area(struct vcpu *v) > >>>>>> +{ > >>>>>> + struct vcpu_runstate_info *guest_runstate; > >>>>>> + void *p; > >>>>>> + > >>>>>> + spin_lock(&v->arch.runstate_guest.lock); > >>>>>> > >>>>>> - if ( guest_handle ) > >>>>>> + if ( v->arch.runstate_guest.page ) > >>>>>> { > >>>>>> - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > >>>>>> + p = __map_domain_page(v->arch.runstate_guest.page); > >>>>>> + guest_runstate = p + v->arch.runstate_guest.offset; > >>>>>> + > >>>>>> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > >>>>>> + { > >>>>>> + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > >>>>>> + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; > >>>>> > >>>>> I think that this write to guest_runstate should use write_atomic or > >>>>> another atomic write operation. > >>>> > >>>> I thought about suggesting the same, but guest_copy_* helpers may not > >>>> do a single memory write to state_entry_time. > >>>> What are you trying to prevent with the write_atomic()? > >>> > >>> I am thinking that without using an atomic write, it would be (at least > >>> theoretically) possible for a guest to see a partial write to > >>> state_entry_time, which is not good. > >> > >> It is already the case with existing implementation as Xen may write byte by > >> byte. So are you suggesting the existing code is also buggy? > > > > Writing byte by byte is a different case. That is OK. In that case, the > > guest could see the state after 3 bytes written and it would be fine and > > consistent. If this hadn't been the case, then yes, the existing code > > would also be buggy. > > > > So if we did the write with a memcpy, it would be fine, no need for > > atomics: > > > > memcpy(&guest_runstate->state_entry_time, > > &v->runstate.state_entry_time, > > XXX); > > > > > > The |= case is different: GCC could implement it in any way it likes, > > including going through a zero-write to any of the bytes in the word, or > > doing an addition then a subtraction. GCC doesn't make any guarantees. > > If we want guarantees we need to use atomics. > > Wouldn’t that require all accesses to state_entry_time to use also atomic operations ? > In this case we could not propagate the changes to a guest without changing the interface itself. > > As the copy time needs to be protected, the write barriers are there to make sure that during the copy the bit is set and that when we unset it, the copy is done. > I added for this purpose a barrier after the memcpy to make sure that when/if we unset the bit the copy has already been done. As you say, we have a flag to mark a transitiong period, the flag is XEN_RUNSTATE_UPDATE. So, I think it is OK if we don't use atomics during the transitioning period. But we need to make sure to use atomics for the update of the XEN_RUNSTATE_UPDATE flag itself. Does it make sense? Or maybe I misunderstood some of the things you wrote? --8323329-993750421-1591980292=:2815-- From xen-devel-bounces@lists.xenproject.org Sat Jun 13 01:45:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 01:45:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjvEf-0007tw-MX; Sat, 13 Jun 2020 01:45:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjvEe-0007tr-Ev for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 01:45:28 +0000 X-Inumbo-ID: 8db919f8-ad17-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8db919f8-ad17-11ea-bca7-bc764e2007e4; Sat, 13 Jun 2020 01:45:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SgCblod7jIUYZtC4RfvvyLcPVm08lyjk3tsUct0RK1I=; b=RZcHuf8cdgx7YHpI3jwah5NWr CG0jRzYaRbZewfQyudtfw8r48sE70urluGd5Rh3nxkA5iknzxBr8JC2bk/BcOBu8DPNNjVwVzQNK+ 4/ZPOqlzMXcahb6jRbZP+a9sdYV/BX5oJrTf9HVXBy6mk9jEFSrlNsZswskpx1q74d9hc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjvEb-0001Az-Hj; Sat, 13 Jun 2020 01:45:25 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjvEb-0001b7-1T; Sat, 13 Jun 2020 01:45:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjvEa-0001DL-W6; Sat, 13 Jun 2020 01:45:25 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.13-testing test] 151048: tolerable FAIL - PUSHED X-Osstest-Failures: xen-4.13-testing:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=d8e1053bfa2726d122109d137fc6c489948b1c36 X-Osstest-Versions-That: xen=67958a166f6b019e5ad8dcd60a96dcd262669092 From: osstest service owner Date: Sat, 13 Jun 2020 01:45:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151048 xen-4.13-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151048/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150944 test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen d8e1053bfa2726d122109d137fc6c489948b1c36 baseline version: xen 67958a166f6b019e5ad8dcd60a96dcd262669092 Last test of basis 150944 2020-06-09 17:06:08 Z 3 days Testing same since 151048 2020-06-11 15:37:37 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 67958a166f..d8e1053bfa d8e1053bfa2726d122109d137fc6c489948b1c36 -> stable-4.13 From xen-devel-bounces@lists.xenproject.org Sat Jun 13 06:22:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 06:22:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjzYe-0005c6-1z; Sat, 13 Jun 2020 06:22:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjzYc-0005c1-Gt for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 06:22:22 +0000 X-Inumbo-ID: 3bf41e5d-ad3e-11ea-b638-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3bf41e5d-ad3e-11ea-b638-12813bfff9fa; Sat, 13 Jun 2020 06:22:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 5B10CAE25; Sat, 13 Jun 2020 06:22:22 +0000 (UTC) Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: Volodymyr Babchuk , "dfaggioli@suse.com" , "julien@xen.org" , "xen-devel@lists.xenproject.org" References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> <78910b5c27a3711726d53e931feb075c5cc4a64c.camel@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Sat, 13 Jun 2020 08:22:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "jbeulich@suse.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 13.06.20 00:27, Volodymyr Babchuk wrote: > On Fri, 2020-06-12 at 17:29 +0200, Dario Faggioli wrote: >> On Fri, 2020-06-12 at 14:41 +0200, Jürgen Groß wrote: >>> On 12.06.20 14:29, Julien Grall wrote: >>>> On 12/06/2020 05:57, Jürgen Groß wrote: >>>>> On 12.06.20 02:22, Volodymyr Babchuk wrote: >>>>>> @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct >>>>>> sched_unit *u) >>>>>> break; >>>>>> } >>>>>> + spin_lock_irqsave(&sched_stat_lock, flags); >>>>>> + sched_stat_irq_time += irq; >>>>>> + sched_stat_hyp_time += hyp; >>>>>> + spin_unlock_irqrestore(&sched_stat_lock, flags); >>>>> >>>>> Please don't use a lock. Just use add_sized() instead which will >>>>> add >>>>> atomically. >>>> >>>> If we expect sched_get_time_correction to be called concurrently >>>> then we >>>> would need to introduce atomic64_t or a spin lock. >>> >>> Or we could use percpu variables and add the cpu values up when >>> fetching the values. >>> >> Yes, either percpu or atomic looks much better than locking, to me, for >> this. > > Looks like we going to have atomic64_t after all. So, I'll prefer to to > use atomics there. Performance would be better using percpu variables, as those would avoid the cacheline moved between cpus a lot. Juergen From xen-devel-bounces@lists.xenproject.org Sat Jun 13 06:49:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 06:49:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjzyq-0007R6-Br; Sat, 13 Jun 2020 06:49:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjzyo-0007Qv-VW for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 06:49:27 +0000 X-Inumbo-ID: 05cd86f2-ad42-11ea-b63e-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 05cd86f2-ad42-11ea-b63e-12813bfff9fa; Sat, 13 Jun 2020 06:49:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AeieTgTfJ7gQ/5+813NS3B77h5MTPX6xmERjrHva2iA=; b=6MBnivZAkuSF67Mm+V/vKCpHQ LwbXMsLm8br1uPiyjc466T345sxSNro6fIyjW9AcsHksgJXIc7+ytrRn3RXyYY4oUTSI8adJmwpU5 kDV2YGjTC3YfEI9SzxlozYyQ7vZeWyG0zvuQSlbyWmaJnwXLI9xEwIJ+VDnpb2WbQb4X8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjzyn-0007ed-Lo; Sat, 13 Jun 2020 06:49:25 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jjzyn-0001Ud-Ez; Sat, 13 Jun 2020 06:49:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jjzyn-0002r9-EJ; Sat, 13 Jun 2020 06:49:25 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151054: all pass - PUSHED X-Osstest-Versions-This: ovmf=3ee4f6cb360a877d171f2f9bb76b0d46d2cfa985 X-Osstest-Versions-That: ovmf=dafce295e6f447ed8905db4e29241e2c6c2a4389 From: osstest service owner Date: Sat, 13 Jun 2020 06:49:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151054 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151054/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 3ee4f6cb360a877d171f2f9bb76b0d46d2cfa985 baseline version: ovmf dafce295e6f447ed8905db4e29241e2c6c2a4389 Last test of basis 150978 2020-06-09 21:39:29 Z 3 days Failing since 151024 2020-06-10 19:57:12 Z 2 days 2 attempts Testing same since 151054 2020-06-11 23:04:05 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Abdul Lateef Attar Ard Biesheuvel Dong, Eric Eric Dong Heyi Guo Laszlo Ersek Liming Gao Walon Li jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git dafce295e6..3ee4f6cb36 3ee4f6cb360a877d171f2f9bb76b0d46d2cfa985 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Jun 13 06:56:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 06:56:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk05q-0008GI-4i; Sat, 13 Jun 2020 06:56:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk05o-0008GD-Ls for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 06:56:40 +0000 X-Inumbo-ID: 072624b8-ad43-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 072624b8-ad43-11ea-bca7-bc764e2007e4; Sat, 13 Jun 2020 06:56:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TRbVsnYsL3HQdoXX/2vFd/nB8dodjevbPpzb4DcEl0g=; b=Ye1M+OoGoTKgTZ3/mKqBHENj0 ugd43a2k4WN33VZ8cSyLBqQa/3YMh6Y1k1kXzwbuplAKPkr8/B96qB6+QureMpG5tIwlqBVR9D99p kB81F73ZnHOh12PP1eKcZ4u1tJhLBAu2WL0HGxpUtJf/oJP0uDnPKwiWXJUxBVRRD+YPQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk05l-0007nH-F3; Sat, 13 Jun 2020 06:56:37 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jk05k-0001k4-Sk; Sat, 13 Jun 2020 06:56:36 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jk05k-0000Z2-SB; Sat, 13 Jun 2020 06:56:36 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 151056: regressions - FAIL X-Osstest-Failures: xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-arm64-xsm:xen-build:fail:regression xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-arm64:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-armhf:xen-build:fail:regression xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:build-arm64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:build-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking X-Osstest-Versions-This: xen=80d78acf9e60ae6a88d6cb6f3535eaf67c81f61c X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Sat, 13 Jun 2020 06:56:36 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151056 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151056/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-arm64-xsm 6 xen-build fail REGR. vs. 150120 build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-arm64 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-armhf 6 xen-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit1 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-arm64-arm64-xl-seattle 1 build-check(1) blocked n/a test-arm64-arm64-xl-thunderx 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a version targeted for testing: xen 80d78acf9e60ae6a88d6cb6f3535eaf67c81f61c baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 34 days Failing since 150940 2020-06-09 17:05:20 Z 3 days 6 attempts Testing same since 151056 2020-06-12 00:06:22 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm fail build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 fail build-armhf fail build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt blocked build-armhf-libvirt blocked build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl blocked test-armhf-armhf-xl blocked test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm blocked test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 blocked test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 blocked test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds blocked test-arm64-arm64-xl-seattle blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx blocked test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 80d78acf9e60ae6a88d6cb6f3535eaf67c81f61c Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. Extend libxl's table of named parameters to include RDRAND/RDSEED, and have the compiler construct it in .rodata, rather than on the stack at runtime each time it is called. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sat Jun 13 09:23:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 09:23:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk2Ns-0003y0-IY; Sat, 13 Jun 2020 09:23:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk2Nr-0003xX-2t for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 09:23:27 +0000 X-Inumbo-ID: 857ec16c-ad57-11ea-b64e-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 857ec16c-ad57-11ea-b64e-12813bfff9fa; Sat, 13 Jun 2020 09:23:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Hxl6LWbeWGX+Byl6h476pMS1FRB0Km/uE10SUnrnToI=; b=6IqD2SMJUzh2hdLtfxzntcmjd D35ZX3L2BCqFDNCpeu8j4NQIxJYtM02Ei3iTAXCKKKLrA1phe/6EXuL/R9PCsNbALFtGNfZG6XAZo ffCYPRg4kyK9Woq8fXqjX1MR/9WJjLaJ2H0vgtFSYqksm/AdsJThMRMdmv7F88mcuSiZk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk2Nj-0002ZP-QY; Sat, 13 Jun 2020 09:23:19 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jk2Nj-0006Pa-I5; Sat, 13 Jun 2020 09:23:19 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jk2Nj-00045y-HP; Sat, 13 Jun 2020 09:23:19 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151051: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=7028534d8482d25860c4d1aa8e45f0b911abfc5a X-Osstest-Versions-That: xen=058023b343d4e366864831db46e9b438e9e3a178 From: osstest service owner Date: Sat, 13 Jun 2020 09:23:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151051 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151051/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 150963 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150963 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 150963 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150963 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150963 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 150963 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150963 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 150963 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 150963 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150963 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 7028534d8482d25860c4d1aa8e45f0b911abfc5a baseline version: xen 058023b343d4e366864831db46e9b438e9e3a178 Last test of basis 150963 2020-06-09 20:06:30 Z 3 days Failing since 151021 2020-06-10 18:24:20 Z 2 days 2 attempts Testing same since 151051 2020-06-11 21:19:41 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Juergen Gross Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 058023b343..7028534d84 7028534d8482d25860c4d1aa8e45f0b911abfc5a -> master From xen-devel-bounces@lists.xenproject.org Sat Jun 13 12:40:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 12:40:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk5SH-00031u-RG; Sat, 13 Jun 2020 12:40:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk5SG-00031p-Q8 for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 12:40:13 +0000 X-Inumbo-ID: 0536ec84-ad73-11ea-8496-bc764e2007e4 Received: from out2-smtp.messagingengine.com (unknown [66.111.4.26]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0536ec84-ad73-11ea-8496-bc764e2007e4; Sat, 13 Jun 2020 12:40:10 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BB06B5C00F7; Sat, 13 Jun 2020 08:40:10 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 13 Jun 2020 08:40:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=7OL6su TazXlpOun+H6F6u+RY3HuJaKLFx6Mx6Htn88M=; b=nlMPAyhoQM3KZ4zV9F70UY OmLloAGAPI+PjtemNhLGzin0Ecraw9L9kTNM/RGN/8R1gBLib8YtVU9cxxnZF2cf qHVMHgo8LPgXoahcnACu1dgfPrkDVtLBCvfGqmCc2Iq8WDzVOZNYL6c7FrQiRZCs 449b68BmUl61USioLJSbvJ9wUfRUleD+K5I+vcVOqy0toevQS0/QYooauizDkvl/ 34pRYE9nLvoDcyvzghKPHFXTXLoa1ILEr7Jzmd0pvZTmcFJwHowBMrgb/MHLE3bk ONeL7Dou76GZP9s1plTgGFOucLSD8KyCuEGmpblQVUQiA/2E9URC1UMwm43qrqJQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeifedgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeetveff iefghfekhffggeeffffhgeevieektedthfehveeiheeiiedtudegfeetffenucfkpheple durdeihedrfeegrdeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd gtohhm X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id D6BEC30614FA; Sat, 13 Jun 2020 08:40:09 -0400 (EDT) Date: Sat, 13 Jun 2020 14:40:07 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jason Andryuk Subject: Re: [PATCH 1/8] vchan-socket-proxy: Ensure UNIX path NUL terminated Message-ID: <20200613124007.GM6329@mail-itl> References: <20200525024955.225415-1-jandryuk@gmail.com> <20200525024955.225415-2-jandryuk@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J+eNKFoVC4T1DV3f" Content-Disposition: inline In-Reply-To: <20200525024955.225415-2-jandryuk@gmail.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --J+eNKFoVC4T1DV3f Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 1/8] vchan-socket-proxy: Ensure UNIX path NUL terminated On Sun, May 24, 2020 at 10:49:48PM -0400, Jason Andryuk wrote: > Check the socket path length to ensure sun_path is NUL terminated. >=20 > This was spotted by Citrix's Coverity. >=20 > Signed-off-by: Jason Andryuk Reviewed-by: Marek Marczykowski-G=C3=B3recki > --- > tools/libvchan/vchan-socket-proxy.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) >=20 > diff --git a/tools/libvchan/vchan-socket-proxy.c b/tools/libvchan/vchan-s= ocket-proxy.c > index 13700c5d67..6d860af340 100644 > --- a/tools/libvchan/vchan-socket-proxy.c > +++ b/tools/libvchan/vchan-socket-proxy.c > @@ -148,6 +148,12 @@ static int connect_socket(const char *path_or_fd) { > return fd; > } > =20 > + if (strlen(path_or_fd) >=3D sizeof(addr.sun_path)) { > + fprintf(stderr, "UNIX socket path \"%s\" too long (%zd >=3D %zd)= \n", > + path_or_fd, strlen(path_or_fd), sizeof(addr.sun_path)); > + return -1; > + } > + > fd =3D socket(AF_UNIX, SOCK_STREAM, 0); > if (fd =3D=3D -1) > return -1; > @@ -174,6 +180,12 @@ static int listen_socket(const char *path_or_fd) { > return fd; > } > =20 > + if (strlen(path_or_fd) >=3D sizeof(addr.sun_path)) { > + fprintf(stderr, "UNIX socket path \"%s\" too long (%zd >=3D %zd)= \n", > + path_or_fd, strlen(path_or_fd), sizeof(addr.sun_path)); > + return -1; > + } > + > /* if not a number, assume a socket path */ > fd =3D socket(AF_UNIX, SOCK_STREAM, 0); > if (fd =3D=3D -1) --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --J+eNKFoVC4T1DV3f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7kySYACgkQ24/THMrX 1yyPGQf9EuMNWFC1HAYIQ/KT5Q0GjxqxcAQL1nJfVq5Ne4Q3XRw8+fUmIa/+tESW GzfTkAQj+FQUvANshYl2s9FwBirvQt0d0LDSozwY0zmtL/HU/WgjE06gZrD7dqXa gvUnmpayTKwZbg+4N/DTTVm+teeFJeg3So/aNY9Cx1x+GyhqsCJ3TQoWozwX9xxQ hVmnRSv/onnlSPmqiW+5CgqhMHEFo4M4skWlmOPEKhS8iuCBQdL5FI6yq4TVrnfg gobUwb+akk7pWFUFz0Rsxkov2C2ogvMymE3QKkd1CTmc0BbYum4W/3B15Hvno7k/ I+W/1C5r2HhEr3erlEYIFT6hbyJ5DQ== =/tC+ -----END PGP SIGNATURE----- --J+eNKFoVC4T1DV3f-- From xen-devel-bounces@lists.xenproject.org Sat Jun 13 12:40:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 12:40:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk5Sr-00033m-3e; Sat, 13 Jun 2020 12:40:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk5Sq-00033c-EA for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 12:40:48 +0000 X-Inumbo-ID: 1b39691c-ad73-11ea-b675-12813bfff9fa Received: from out2-smtp.messagingengine.com (unknown [66.111.4.26]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1b39691c-ad73-11ea-b675-12813bfff9fa; Sat, 13 Jun 2020 12:40:47 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ADA4E5C0109; Sat, 13 Jun 2020 08:40:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 13 Jun 2020 08:40:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Yt1FUr ieZSejFahl0lKYsx3SCjSZvSJd0zCGv8cs+Ew=; b=Vl+eybBrhzqD/gb1Smn7l4 vWYYw1UCYYBTHmvP72LYBw0VxWgdt9WUMNKtlirX/SsnM5sk5B4O3Hkvv1N1j8ua zYLxsNRvQPSydmGaWQfQTKfQ0LM0mm5hhCoZ7Lkw7YKCZVdjWWfaFDMl4IZd876r 2fsort8ytRzjY9UbWFYntMzJc9l/UE6L3D2ZN/Md/sM1qG1h2KVZGvDGRglLDzKi 0uj8VdpRsEW+9nTqnSu9/BzO6jLo0WzohERX7YP/xheDowscRQH4vOl0GT9EgVjH GeVvYoFPW4F4S2irobzDt4X1CxqVQnddG8+ZXNcMVw9ngReF8doA7KHqnIgqz/lA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeifedgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeetveff iefghfekhffggeeffffhgeevieektedthfehveeiheeiiedtudegfeetffenucfkpheple durdeihedrfeegrdeffeenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd gtohhm X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id F3A6D328005D; Sat, 13 Jun 2020 08:40:46 -0400 (EDT) Date: Sat, 13 Jun 2020 14:40:44 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Jason Andryuk Subject: Re: [PATCH 0/8] Coverity fixes for vchan-socket-proxy Message-ID: <20200613124044.GN6329@mail-itl> References: <20200525024955.225415-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EVh9lyqKgK19OcEf" Content-Disposition: inline In-Reply-To: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --EVh9lyqKgK19OcEf Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH 0/8] Coverity fixes for vchan-socket-proxy On Wed, May 27, 2020 at 10:59:55PM -0400, Jason Andryuk wrote: > On Mon, May 25, 2020 at 6:36 PM Jason Andryuk wrote: > > > > On Sun, May 24, 2020 at 10:50 PM Jason Andryuk wro= te: > > > > > > This series addresses some Coverity reports. To handle closing FDs, a > > > state struct is introduced to track FDs closed in both main() and > > > data_loop(). > > > > I've realized the changes here are insufficient to handle the FD > > leaks. That is, the accept()-ed FDs need to be closed inside the for > > loop so they aren't leaked with each iteration. I'll re-work for a > > v2. >=20 > So it turns out this series doesn't leak FDs in the for loop. FDs are > necessarily closed down in data_loop() when the read() returns 0. The > only returns from data_loop() are after the FDs have been closed. > data_loop() and some of the functions it calls will call exit(1) on > error, but that won't leak FDs. >=20 > Please review this series. Sorry for the confusion. For the whole series: Reviewed-by: Marek Marczykowski-G=C3=B3recki --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --EVh9lyqKgK19OcEf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7kyUsACgkQ24/THMrX 1yzcZQf/cRqczpfB7bFKJy59Cr7a7jW+YdgtS8IfUNL+mn2dKJuzLp4BoVwD8IhK aWZS2LrRWKN7V9rtGd7LHHlM4AZ7Ero/zwkv9fEK8ea0myvoL8MrBu7vniqAAxPJ N6NlMuwuFCKSMW4UO/4gyPoOpzVUU8jHYMYygSAdyjK8s3RbAufJXXk/TSevnnjz hnPW9EkSOi/jjXS9sstpCsmD5e7InKBqI+rEEBjG7WA7HjpSDv1rFn8NmrORllJH kaKiCUF8V2ORv+gYEDZCqU6QSVR/29OPL6hkTj5didvDd5ucTbadTFqXzRv63039 /LMFJ0l4VqSx34E7xN8v9JGC9hpN0Q== =vHik -----END PGP SIGNATURE----- --EVh9lyqKgK19OcEf-- From xen-devel-bounces@lists.xenproject.org Sat Jun 13 12:55:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 12:55:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk5hK-00044h-EC; Sat, 13 Jun 2020 12:55:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk5hI-00044c-JC for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 12:55:44 +0000 X-Inumbo-ID: 2faea1ee-ad75-11ea-b677-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2faea1ee-ad75-11ea-b677-12813bfff9fa; Sat, 13 Jun 2020 12:55:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ENwIKjuFXVH7kJP0WLx6dO5wHojLcMw32FQxJ7jsYjk=; b=oWTgWiZQbIPpsHfCOqTNKMkIS tqPom21VxrCnDK0Xz/mXIYDML45z8fg+7u1c/65c+M9eWFfTKTqsov72P5Vmn0eFHd8LTXEmaD2kZ K3Jzl+UCsIf8Y16HCFnb0EajSiWJrwMsIB5lvA4xCLsVA3YrrgTjsEI/H9s4gJ9YLZlR8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk5hE-0006UB-JB; Sat, 13 Jun 2020 12:55:40 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jk5hE-0001Yj-8R; Sat, 13 Jun 2020 12:55:40 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jk5hE-0000he-7p; Sat, 13 Jun 2020 12:55:40 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151058: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=d58c48df8c6ca819f5e6e6f1740bb114f24f024f X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Sat, 13 Jun 2020 12:55:40 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151058 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151058/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen d58c48df8c6ca819f5e6e6f1740bb114f24f024f baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 30 days Failing since 150943 2020-06-09 17:06:00 Z 3 days 4 attempts Testing same since 151058 2020-06-12 04:30:55 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sat Jun 13 17:13:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 17:13:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk9iL-0008V7-Ko; Sat, 13 Jun 2020 17:13:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk9iK-0008V2-Ha for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 17:13:04 +0000 X-Inumbo-ID: 24012c44-ad99-11ea-b6ae-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 24012c44-ad99-11ea-b6ae-12813bfff9fa; Sat, 13 Jun 2020 17:13:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=86qRHAHLao/vPDk64UwxyLUvebptAqm86eQcBUnaHMc=; b=tES+16+Y85LsVLt0LOok0ecGZ mcAy0Ho2X05LmswzHqYX4MfHtV9h5ksk0y6V5tLKBK7HNy7RQAMtCttIRHjuCo4sNCqR9+iX9LXHy lVBsNLL2KY0yCMoPBWVOoYy4O85Kh5XFN2sAseP/o5j4qizoVxUYuiJxLF/55Ovy/B1BA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jk9iI-0003Ho-Nh; Sat, 13 Jun 2020 17:13:02 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jk9iI-00073F-Et; Sat, 13 Jun 2020 17:13:02 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jk9iI-00040c-EM; Sat, 13 Jun 2020 17:13:02 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 151059: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.10-testing:build-arm64-libvirt:libvirt-build:fail:regression xen-4.10-testing:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression xen-4.10-testing:test-amd64-i386-xl-raw:debian-di-install:fail:regression xen-4.10-testing:test-amd64-amd64-pygrub:debian-di-install:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-amd64-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-armhf-libvirt:libvirt-build:fail:regression xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=ce056837082da7b2759a069045e480638094adcd X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Sat, 13 Jun 2020 17:13:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151059 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151059/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039 build-i386-prev 6 xen-build fail REGR. vs. 150039 build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 150039 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 150039 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen ce056837082da7b2759a069045e480638094adcd baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 39 days Failing since 150941 2020-06-09 17:05:34 Z 4 days 6 attempts Testing same since 151059 2020-06-12 08:13:16 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark John Thomson Julien Grall Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub fail test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw fail test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit ce056837082da7b2759a069045e480638094adcd Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 934d6e1a77947662504cf4d5e36c9520e03aa731 Author: John Thomson Date: Tue May 15 11:48:43 2018 +1000 tools/ocaml/libs/xc fix gcc-8 format-truncation warning CC xenctrl_stubs.o xenctrl_stubs.c: In function 'failwith_xc': xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "%d: %s: %s", error->code, ^ xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028 snprintf(error_str, sizeof(error_str), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%d: %s: %s", error->code, ~~~~~~~~~~~~~~~~~~~~~~~~~~ xc_error_code_to_desc(error->code), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error->message); ~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1 m Signed-off-by: John Thomson Acked-by: Christian Lindig Release-acked-by: Juergen Gross (cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795) commit 6e636f297f12a52ce12db11ea0787dd541937ed6 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:50 2018 +0200 tools/misc: fix hypothetical buffer overflow in xen-lowmemd gcc-8 complains: xen-lowmemd.c: In function 'handle_low_mem': xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=] snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~ ~~~~ xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In practice it wouldn't happen, because 'data' contains string representation of 64-bit unsigned number (20 characters at most). But place a limit to mute gcc warning. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080) commit dfc0b23403a2f0069bc7b9c0c20dfe5513eb8fb5 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:52 2018 +0200 tools/blktap2: fix possible '\0' truncation gcc-8 complains: tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring': tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^ tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255 snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "- 1" in buffer size should be actually applied to message, to leave place for terminating '\0', not the other way around (truncate '\0' even if it would fit). In function 'tapdisk_control_open_image', inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10: tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'tapdisk_control_create_socket', inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9: tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block-qcow.c: In function 'qcow_create': block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(backing_filename, backing_file, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(backing_filename)); ~~~~~~~~~~~~~~~~~~~~~~~~~ I those cases, reduce size of copied string and make sure final '\0' is added. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a) commit 2f83654fa3331d1ec79275072f8742f175f82bc5 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:54 2018 +0200 tools/gdbsx: fix -Wstringop-truncation warning gcc-8 complains: gx_main.c: In function 'prepare_stop_reply': gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(buf, "watch:", 6); ^~~~~~~~~~~~~~~~~~~~~~~~~ Since terminating '\0' isn't needed here at all, switch to memcpy. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f) commit bf467cc828bde380e9201d8b49c7866a5b92d719 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:53 2018 +0200 tools/xenpmd: fix possible '\0' truncation gcc-8 complains: xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->oem_info, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->battery_type, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->serial_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->model_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy 31 chars, then make sure terminating '\0' is present. Those fields are passed to strlen and as '%s' for snprintf later. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b) commit 6df4d40d846eb5151a89d26d1a63d632c6b9eb55 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:49 2018 +0200 tools/libxc: fix strncpy size gcc-8 warns about possible truncation of trailing '\0'. Final character is overridden by '\0' anyway, so don't bother to copy it. This fixes compile failure: xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159) commit e20bb5818174e9d09389776cb14781b9c6436554 Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit a1a9b055a349748083665e42843f75d6db2c6a7b Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit afca67fafde22033b9a967ae197a10af5c654f02 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sat Jun 13 18:42:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 18:42:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkB6G-0007Iz-C6; Sat, 13 Jun 2020 18:41:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkB6F-0007Iu-Cg for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 18:41:51 +0000 X-Inumbo-ID: 8a686928-ada5-11ea-b6c2-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8a686928-ada5-11ea-b6c2-12813bfff9fa; Sat, 13 Jun 2020 18:41:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=MFePwdJckU5c3mtocnCg48ruUviS+H7vs4qM4vnDBuQ=; b=xx9UH4tMWXBSWwg1m983PJovE2 iXY7FqpAd1BMM8GVdN/o0KQyILC0u7Udsfbz2XhfqkyW7tXAZPiw82R+Z9uRtOc8x56FE1aDdW+sA DMjKJmZROmvizR7nNLcXjKDbdr09tXBYENnCiHp4ULmq9/lHhmczbUsFZh03lhTAxRWc=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkB6B-0004vi-Lx; Sat, 13 Jun 2020 18:41:47 +0000 Received: from 54-240-197-227.amazon.com ([54.240.197.227] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jkB6B-0003hP-C5; Sat, 13 Jun 2020 18:41:47 +0000 From: Julien Grall To: xen-devel@lists.xenproject.org Subject: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches Date: Sat, 13 Jun 2020 19:41:32 +0100 Message-Id: <20200613184132.11880-1-julien@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Julien Grall The documentation of pvcalls suggests there is padding for 32-bit x86 at the end of most the structure. However, they are not described in in the public header. Because of that all the structures would be 32-bit aligned and not 64-bit aligned for 32-bit x86. For all the other architectures supported (Arm and 64-bit x86), the structure are aligned to 64-bit because they contain uint64_t field. Therefore all the structures contain implicit padding. The paddings are now corrected for 32-bit x86 and written explicitly for all the architectures. While the structure size between 32-bit and 64-bit x86 is different, it shouldn't cause any incompatibility between a 32-bit and 64-bit frontend/backend because the commands are always 56 bits and the padding are at the end of the structure. As an aside, the padding sadly cannot be mandated to be 0 as they are already present. So it is not going to be possible to use the padding for extending a command in the future. Signed-off-by: Julien Grall --- Changes in v3: - Use __i386__ rather than CONFIG_X86_32 Changes in v2: - It is not possible to use the same padding for 32-bit x86 and all the other supported architectures. --- docs/misc/pvcalls.pandoc | 18 ++++++++++-------- xen/include/public/io/pvcalls.h | 14 ++++++++++++++ 2 files changed, 24 insertions(+), 8 deletions(-) diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc index 665dad556c39..caa71b36d78b 100644 --- a/docs/misc/pvcalls.pandoc +++ b/docs/misc/pvcalls.pandoc @@ -246,9 +246,9 @@ The format is defined as follows: uint32_t domain; uint32_t type; uint32_t protocol; - #ifdef CONFIG_X86_32 + #ifndef __i386__ uint8_t pad[4]; - #endif + #endif } socket; struct xen_pvcalls_connect { uint64_t id; @@ -257,16 +257,18 @@ The format is defined as follows: uint32_t flags; grant_ref_t ref; uint32_t evtchn; - #ifdef CONFIG_X86_32 + #ifndef __i386__ uint8_t pad[4]; - #endif + #endif } connect; struct xen_pvcalls_release { uint64_t id; uint8_t reuse; - #ifdef CONFIG_X86_32 + #ifndef __i386__ uint8_t pad[7]; - #endif + #else + uint8_t pad[3]; + #endif } release; struct xen_pvcalls_bind { uint64_t id; @@ -276,9 +278,9 @@ The format is defined as follows: struct xen_pvcalls_listen { uint64_t id; uint32_t backlog; - #ifdef CONFIG_X86_32 + #ifndef __i386__ uint8_t pad[4]; - #endif + #endif } listen; struct xen_pvcalls_accept { uint64_t id; diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h index cb8171275c13..28374a82f410 100644 --- a/xen/include/public/io/pvcalls.h +++ b/xen/include/public/io/pvcalls.h @@ -65,6 +65,9 @@ struct xen_pvcalls_request { uint32_t domain; uint32_t type; uint32_t protocol; +#ifndef __i386__ + uint8_t pad[4]; +#endif } socket; struct xen_pvcalls_connect { uint64_t id; @@ -73,10 +76,18 @@ struct xen_pvcalls_request { uint32_t flags; grant_ref_t ref; uint32_t evtchn; +#ifndef __i386__ + uint8_t pad[4]; +#endif } connect; struct xen_pvcalls_release { uint64_t id; uint8_t reuse; +#ifndef __i386__ + uint8_t pad[7]; +#else + uint8_t pad[3]; +#endif } release; struct xen_pvcalls_bind { uint64_t id; @@ -86,6 +97,9 @@ struct xen_pvcalls_request { struct xen_pvcalls_listen { uint64_t id; uint32_t backlog; +#ifndef __i386__ + uint8_t pad[4]; +#endif } listen; struct xen_pvcalls_accept { uint64_t id; -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Sat Jun 13 20:32:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 20:32:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkCou-0007hr-B7; Sat, 13 Jun 2020 20:32:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkCot-0007hm-19 for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 20:32:03 +0000 X-Inumbo-ID: efa610d8-adb4-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id efa610d8-adb4-11ea-b7bb-bc764e2007e4; Sat, 13 Jun 2020 20:32:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MjHQblp3XHh3JO14df6l7OePanGzuffS3w1NvDHcnuE=; b=H6PqqapWnQlbJz8nobexrr83H bRCy/pxeVH8zg4xGhfMUODHtMj+OKc78jvU+tMyCJRCr4UavsZhbXhgWOg+VIvA03850JObWDDB+x FV5kP6jjNOaaHlNABYdr8X3XBlPr+0u38tVT28D7hKKn5lyEajFE+DieYwFlqhGpnOnRM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkCoq-0006zz-Vb; Sat, 13 Jun 2020 20:32:01 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkCoq-000128-N5; Sat, 13 Jun 2020 20:32:00 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkCoq-0002yo-MT; Sat, 13 Jun 2020 20:32:00 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151062: regressions - FAIL X-Osstest-Failures: libvirt:test-arm64-arm64-libvirt-qcow2:debian-di-install:fail:regression libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=63d08bec0b2dace2fcefffb23a1fa5b14c473d67 X-Osstest-Versions-That: libvirt=0d009ca646a4e7438952f6d2739ab7f48ef533ab From: osstest service owner Date: Sat, 13 Jun 2020 20:32:00 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151062 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151062/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-qcow2 10 debian-di-install fail REGR. vs. 151040 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151040 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151040 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 63d08bec0b2dace2fcefffb23a1fa5b14c473d67 baseline version: libvirt 0d009ca646a4e7438952f6d2739ab7f48ef533ab Last test of basis 151040 2020-06-11 04:19:36 Z 2 days Testing same since 151062 2020-06-12 12:50:09 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Yi Li jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 63d08bec0b2dace2fcefffb23a1fa5b14c473d67 Author: Andrea Bolognani Date: Thu Jun 11 20:06:02 2020 +0200 ci: Swap mipsel and ppc64le builds Debian sid is currently broken on mipsel, so use Debian 10 for that architecture; at the same time, move the ppc64le build from Debian 10 to Debian sid to keep things balanced. Signed-off-by: Andrea Bolognani commit 2250a0b56f12e30d67210fd49d2123014bc73d2c Author: Andrea Bolognani Date: Tue Jun 2 17:28:58 2020 +0200 ci: Update build system integration The ci-* targets need to know where our container images are stored and how they are called to work, so now that we use the GitLab container registry instead of Quay some changes are necessary. Signed-off-by: Andrea Bolognani Reviewed-by: Daniel P. Berrangé commit 95abbdc432133b9ae4a76d15251d64b5893717e6 Author: Andrea Bolognani Date: Tue Jun 2 17:28:57 2020 +0200 ci: Use GitLab container registry Instead of using pre-built containers hosted on Quay, build containers as part of the GitLab CI pipeline and upload them to the GitLab container registry for later use. This will not significantly slow down builds, because containers are only rebuilt when the corresponding Dockerfile has been modified. Signed-off-by: Andrea Bolognani Reviewed-by: Daniel P. Berrangé commit 7ef13242847405328836a38e445aa2894c0ebab9 Author: Andrea Bolognani Date: Tue Jun 2 17:28:55 2020 +0200 ci: Use variables to build image names This removes a lot of repetition and makes the configuration much easier to read. Signed-off-by: Andrea Bolognani Reviewed-by: Daniel P. Berrangé commit 9170b0ee6f867d2be1165e83c80910b0e0ac952d Author: Andrea Bolognani Date: Wed Jun 10 18:11:04 2020 +0200 docs: Document CIRRUS_GITHUB_REPO variable This needs to be set for every repository for Cirrus CI integration to work. Signed-off-by: Andrea Bolognani Reviewed-by: Daniel P. Berrangé commit 414aee194aed23370df87f5cde28dce1d1492235 Author: Yi Li Date: Thu Jun 11 11:26:29 2020 +0800 conf: snapshot: Drop unused variable 'creation' Signed-off-by: Yi Li Reviewed-by: Erik Skultety From xen-devel-bounces@lists.xenproject.org Sat Jun 13 20:53:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 13 Jun 2020 20:53:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkD9P-0000yE-7h; Sat, 13 Jun 2020 20:53:15 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkD9N-0000xu-QN for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 20:53:13 +0000 X-Inumbo-ID: e23a46fb-adb7-11ea-b6ce-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e23a46fb-adb7-11ea-b6ce-12813bfff9fa; Sat, 13 Jun 2020 20:53:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ggyunabqtzQ+ZnDL7kyzoyhss1rn9RX4KjYNsAXjtBA=; b=37ehXFprZ1jxUdJVp+CJSjH32 OlkxQuqjgHQ8aWgtT2i5S7KorEUBgrNlvxlJdgIb/EIhtzqFDBjAfxXijMdKIWZ6oF1X1tZv/tXPY aIAD2SqWSYg31h2K9X0ecMpYgaZ5KwGx7cnOAHzJTXNyS9ImxOzdjK+EZNEhsjS7l+ntM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkD9H-0007NI-KI; Sat, 13 Jun 2020 20:53:07 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkD9H-0001XM-8y; Sat, 13 Jun 2020 20:53:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkD9H-0008BR-7f; Sat, 13 Jun 2020 20:53:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151061: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Sat, 13 Jun 2020 20:53:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151061 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151061/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 39 days Failing since 150942 2020-06-09 17:05:43 Z 4 days 6 attempts Testing same since 151061 2020-06-12 12:25:05 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 2b77729888fb851ab96e7f77bc854122626b4861 Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Jun 14 05:02:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 05:02:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkKmI-0008T1-1v; Sun, 14 Jun 2020 05:01:54 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkKmH-0008Rx-Aw for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 05:01:53 +0000 X-Inumbo-ID: 251ad0e0-adfc-11ea-b712-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 251ad0e0-adfc-11ea-b712-12813bfff9fa; Sun, 14 Jun 2020 05:01:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=u+jeCrM7VW1xDVBXh4HeIpVrvPvcJHTj8tE6AryhLIo=; b=mVVtS8+NuM+o7VYtDp/9q3xzI reWeEpwjzuWkr/bU0IUy9XAbk8RBDVFB+RIsab4F29nYjkZVG9i825oXOGvrd+cjq2fQDcxJ1uHB3 HevN4DrvXm/vKj4nQPJbmOKnfqDjYK7hTkWiCl4RrjWkzMzWPZ5kyQwXEdMuBF3zOt0iM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkKm8-0002C4-TC; Sun, 14 Jun 2020 05:01:44 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkKm8-00076F-HE; Sun, 14 Jun 2020 05:01:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkKm8-0004pj-GB; Sun, 14 Jun 2020 05:01:44 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151064: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-amd64-libvirt-vhd:guest-start/debian.repeat:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=44ebe016df3aad96e3be8f95ec52397728dd7701 X-Osstest-Versions-That: linux=5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 From: osstest service owner Date: Sun, 14 Jun 2020 05:01:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151064 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151064/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 151016 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151016 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 151016 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail blocked in 151016 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151016 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151016 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 44ebe016df3aad96e3be8f95ec52397728dd7701 baseline version: linux 5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 Last test of basis 151016 2020-06-10 12:58:42 Z 3 days Failing since 151044 2020-06-11 10:29:35 Z 2 days 2 attempts Testing same since 151064 2020-06-12 21:09:06 Z 1 days 1 attempts ------------------------------------------------------------ 373 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 22010 lines long.) From xen-devel-bounces@lists.xenproject.org Sun Jun 14 05:45:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 05:45:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkLRy-0003In-E4; Sun, 14 Jun 2020 05:44:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkLRx-0003Ii-9p for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 05:44:57 +0000 X-Inumbo-ID: 2d289b22-ae02-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2d289b22-ae02-11ea-b7bb-bc764e2007e4; Sun, 14 Jun 2020 05:44:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XiQ1xmFgIQYYDdUYhdz/JkQF6jXycfVVhkhqlhYyi0A=; b=Fc4pqjEu9FpouL37cicjNSKsT Ax9K4R2v3e7zPCuS9PmviHLdpT3I+X1aM4eeeDcf1Brz/KfiS+5jxN3zddI8/s6pZ1K22hpZCfmRK vKj2RTLh+xKdMsQfazg2KkMgN+v3wBYLFDlhkXhi/p3XQYg3rsvvUmyUyteGkw0Mu2th4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkLRv-0002x1-8t; Sun, 14 Jun 2020 05:44:55 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkLRu-0000Kq-LO; Sun, 14 Jun 2020 05:44:54 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkLRu-0008PQ-Kk; Sun, 14 Jun 2020 05:44:54 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151069: all pass - PUSHED X-Osstest-Versions-This: ovmf=9af1064995d479df92e399a682ba7e4b2fc78415 X-Osstest-Versions-That: ovmf=3ee4f6cb360a877d171f2f9bb76b0d46d2cfa985 From: osstest service owner Date: Sun, 14 Jun 2020 05:44:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151069 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151069/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 9af1064995d479df92e399a682ba7e4b2fc78415 baseline version: ovmf 3ee4f6cb360a877d171f2f9bb76b0d46d2cfa985 Last test of basis 151054 2020-06-11 23:04:05 Z 2 days Testing same since 151069 2020-06-13 06:49:53 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel Chasel Chiu Gaurav Jain Jiewen Yao Laszlo Ersek Sami Mujawar Shenglei Zhang jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 3ee4f6cb36..9af1064995 9af1064995d479df92e399a682ba7e4b2fc78415 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sun Jun 14 06:15:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 06:15:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkLul-0005oK-R7; Sun, 14 Jun 2020 06:14:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkLul-0005nt-9g for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 06:14:43 +0000 X-Inumbo-ID: 51a53920-ae06-11ea-b715-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 51a53920-ae06-11ea-b715-12813bfff9fa; Sun, 14 Jun 2020 06:14:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QsUnloPjJrDMCtkYiQCDcaq7VX2P/37YRNEN26LU8Sw=; b=nIEzqaASCBbV1DlGiuXUiB45i KbThtuxU1nW313jlL+Th5YsnrvCJv5WksbrXnYwMQMNSQCotsqqvXUGu41Gy8NMW6/4V36EIpLh2/ 6D7MhjDTWqbbjwnwjkVtQzUI4Jlk/q2gS9FwaaI5K+5Kj59MB6R+d3y2t9Cqa9VZtmxIA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkLuc-0003ZI-AX; Sun, 14 Jun 2020 06:14:34 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkLub-0001Fj-Vm; Sun, 14 Jun 2020 06:14:34 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkLub-0000dN-V6; Sun, 14 Jun 2020 06:14:33 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 151070: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-arm64-libvirt:libvirt-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-armhf-libvirt:libvirt-build:fail:regression xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=6e477c2ea4d5c26a7a7b2f850166aa79edc5225c X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Sun, 14 Jun 2020 06:14:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151070 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151070/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150102 test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 35 days Failing since 150940 2020-06-09 17:05:20 Z 4 days 7 attempts Testing same since 151070 2020-06-13 06:57:26 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Ian Jackson John Thomson Julien Grall Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm pass build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 pass build-armhf pass build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c Author: Wei Liu Date: Mon Jun 12 16:04:17 2017 +0100 ipxe: update to newer commit To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7. The only patch we have applies cleanly. Reported-by: Zhongze Liu Signed-off-by: Wei Liu Acked-by: Ian Jackson (cherry picked from commit 461b2165346de236fff2d00d1c318062f1daab08) commit 6a1c431890599c701117bf9822898f60a18444a3 Author: John Thomson Date: Tue May 15 11:48:43 2018 +1000 tools/ocaml/libs/xc fix gcc-8 format-truncation warning CC xenctrl_stubs.o xenctrl_stubs.c: In function 'failwith_xc': xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "%d: %s: %s", error->code, ^ xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028 snprintf(error_str, sizeof(error_str), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%d: %s: %s", error->code, ~~~~~~~~~~~~~~~~~~~~~~~~~~ xc_error_code_to_desc(error->code), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error->message); ~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1 m Signed-off-by: John Thomson Acked-by: Christian Lindig Release-acked-by: Juergen Gross (cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795) commit 41f597f5167c2e78a3c70d219710c8805d7fec8e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:50 2018 +0200 tools/misc: fix hypothetical buffer overflow in xen-lowmemd gcc-8 complains: xen-lowmemd.c: In function 'handle_low_mem': xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=] snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~ ~~~~ xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In practice it wouldn't happen, because 'data' contains string representation of 64-bit unsigned number (20 characters at most). But place a limit to mute gcc warning. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080) commit 1eae17268887bacbc598ef6e3290059dbeb4fd8f Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:52 2018 +0200 tools/blktap2: fix possible '\0' truncation gcc-8 complains: tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring': tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^ tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255 snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "- 1" in buffer size should be actually applied to message, to leave place for terminating '\0', not the other way around (truncate '\0' even if it would fit). In function 'tapdisk_control_open_image', inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10: tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'tapdisk_control_create_socket', inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9: tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block-qcow.c: In function 'qcow_create': block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(backing_filename, backing_file, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(backing_filename)); ~~~~~~~~~~~~~~~~~~~~~~~~~ I those cases, reduce size of copied string and make sure final '\0' is added. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a) commit f1e75e5c7054d8cd7bdfe30c6a95af35cc24fbb2 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:54 2018 +0200 tools/gdbsx: fix -Wstringop-truncation warning gcc-8 complains: gx_main.c: In function 'prepare_stop_reply': gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(buf, "watch:", 6); ^~~~~~~~~~~~~~~~~~~~~~~~~ Since terminating '\0' isn't needed here at all, switch to memcpy. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f) commit f034ab45c15aef9c784dbcdc5c893e268d4a094c Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:53 2018 +0200 tools/xenpmd: fix possible '\0' truncation gcc-8 complains: xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->oem_info, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->battery_type, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->serial_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->model_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy 31 chars, then make sure terminating '\0' is present. Those fields are passed to strlen and as '%s' for snprintf later. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b) commit 9737f89b076ae4d05e6f974a7c21aced4459966e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:49 2018 +0200 tools/libxc: fix strncpy size gcc-8 warns about possible truncation of trailing '\0'. Final character is overridden by '\0' anyway, so don't bother to copy it. This fixes compile failure: xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159) commit 1dd64783024c5c9e600c3d33393b795c68a46f65 Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit 80d78acf9e60ae6a88d6cb6f3535eaf67c81f61c Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. Extend libxl's table of named parameters to include RDRAND/RDSEED, and have the compiler construct it in .rodata, rather than on the stack at runtime each time it is called. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Jun 14 08:31:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 08:31:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkO2g-0000e6-Fv; Sun, 14 Jun 2020 08:31:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkO2f-0000dg-59 for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 08:31:01 +0000 X-Inumbo-ID: 5bc0b9d0-ae19-11ea-b722-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5bc0b9d0-ae19-11ea-b722-12813bfff9fa; Sun, 14 Jun 2020 08:30:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VNesJzRPagLR3LDfsgVroEXQdN12+CuqMfayxAWJWB0=; b=0SWSQBvjQv7zoiOHeWKaP13Pz ZwsY+QRtynuUnVVOEpUyjPsBOjzGsRUXIfAjMS9Ij7iquc9VGDe36e58wSJC0OeBhE44ibsEeQzhy AXvPEtzCQSZgsNNjzeefZPHTfZ4rfINf6avk1+UD1G2gtG+mVB3kzkmFWwWFILLO8TVS0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkO2W-0006Y4-AB; Sun, 14 Jun 2020 08:30:52 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkO2V-0001h6-TO; Sun, 14 Jun 2020 08:30:51 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkO2V-00011W-So; Sun, 14 Jun 2020 08:30:51 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151065: tolerable FAIL - PUSHED X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a X-Osstest-Versions-That: qemuu=9e7f1469b9994d910fc1b185c657778bde51639c From: osstest service owner Date: Sun, 14 Jun 2020 08:30:51 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151065 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151065/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151047 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151047 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151047 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151047 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151047 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151047 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass version targeted for testing: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a baseline version: qemuu 9e7f1469b9994d910fc1b185c657778bde51639c Last test of basis 151047 2020-06-11 10:36:56 Z 2 days Testing same since 151065 2020-06-12 22:27:51 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Duyck Andrea Oliveri David Hildenbrand Dima Stepanov Dr. David Alan Gilbert Eric Auger Eric Blake Gerd Hoffmann Huacai Chen Huacai Chen Igor Mammedov Jason Wang Jon Derrick Julia Suvorova Kevin Wolf KONRAD Frederic Laurent Vivier Li Feng Marc-André Lureau Markus Armbruster Michael S. Tsirkin Peter Maydell Peter Turschmid Peter Xu Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Raphael Norwitz Raphael Norwitz Richard Henderson Stafford Horne Stefan Berger Stefan Hajnoczi Stefano Garzarella Swapnil Ingle Thomas Huth Vishal Verma Vladimir Sementsov-Ogievskiy jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/qemu-xen.git 9e7f1469b9..9e3903136d 9e3903136d9acde2fb2dd9e967ba928050a6cb4a -> upstream-tested From xen-devel-bounces@lists.xenproject.org Sun Jun 14 11:27:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 11:27:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkQnR-0005yp-E7; Sun, 14 Jun 2020 11:27:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkQnQ-0005yU-P2 for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 11:27:28 +0000 X-Inumbo-ID: 03558b86-ae32-11ea-b736-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 03558b86-ae32-11ea-b736-12813bfff9fa; Sun, 14 Jun 2020 11:27:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CqhVlYgpidU46rUCBNg6bBqT6FXDeV5Tq287JTyscnE=; b=Zf81fnxCxYOf6jQb2Yhs1o1ND qczUU1pQw8/8n96xjPdbEiRDHGpQ+v9HrYP3mxEu7n2iDNNFTSb36ej5a6HfoXIwIm1fNnBkX68qp mDUOXbX42vp3cWuKdoKa+48vPANPUZ/5Lh1gxf0g1my0azFeh0ry2Uku2sxmSmLxXyx7I=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkQnI-0001RL-Ug; Sun, 14 Jun 2020 11:27:20 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkQnH-0001yE-NU; Sun, 14 Jun 2020 11:27:19 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkQnH-00006s-Mn; Sun, 14 Jun 2020 11:27:19 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-coverity test] 151106: all pass - PUSHED X-Osstest-Versions-This: xen=b91825f628c9a62cf2a3a0d972ea81484a8b7fce X-Osstest-Versions-That: xen=51ca66c37371b10b378513af126646de22eddb17 From: osstest service owner Date: Sun, 14 Jun 2020 11:27:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151106 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/151106/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce baseline version: xen 51ca66c37371b10b378513af126646de22eddb17 Last test of basis 150905 2020-06-07 09:19:18 Z 7 days Failing since 151009 2020-06-10 09:20:09 Z 4 days 2 attempts Testing same since 151106 2020-06-14 09:23:09 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper George Dunlap Ian Jackson Jan Beulich Juergen Gross Julien Grall Nick Rosbrook Paul Durrant Roger Pau Monne Roger Pau Monné Tamas K Lengyel Wei Liu jobs: coverity-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 51ca66c373..b91825f628 b91825f628c9a62cf2a3a0d972ea81484a8b7fce -> coverity-tested/smoke From xen-devel-bounces@lists.xenproject.org Sun Jun 14 14:05:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 14:05:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkTGI-0001we-Jd; Sun, 14 Jun 2020 14:05:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkTGH-0001wZ-Jp for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 14:05:25 +0000 X-Inumbo-ID: 176a0a50-ae48-11ea-bb8b-bc764e2007e4 Received: from mail-lj1-x242.google.com (unknown [2a00:1450:4864:20::242]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 176a0a50-ae48-11ea-bb8b-bc764e2007e4; Sun, 14 Jun 2020 14:05:24 +0000 (UTC) Received: by mail-lj1-x242.google.com with SMTP id n24so16021755lji.10 for ; Sun, 14 Jun 2020 07:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ek51lNfJOUVZmpl2borP2GO2sHVw7RV31/wY1xuTfEs=; b=uPNqlx98V+AbSyvg85S8YWWT5gjWwLAClLqgTX1GEk6aqoVWFSG/EivrYB0/vMk5Gx /H2K5okIge2zaoqU0690RhB3HQ5Kzd/OFO1yOxzrkZ54sWIxiaTdJsSdQOcykESPrCNe rHrHEhX9LtuRoya+mLR3se8a/buFZoLM/U6ejPW9UOhM2lgSXOlwInBFJ/z0EdfDqeoP /WihJBd/GbvUeEjH/b13SpB4I8pigHiNTEixLOc8WV/LaNjLQZkohdMYNQevbuFQv7qJ kooiPeGNnyhUskIs2gx6t43XlpiEjcuO4x5W7DeUoIfpY5nIjeU/oFd5tmyTTiHc/eJ6 PN8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ek51lNfJOUVZmpl2borP2GO2sHVw7RV31/wY1xuTfEs=; b=D+9v9NwCff4zndnhuH9R2e2ADLA8jwcUbuZBdv0tjIlafEQ2nnQsq9J+BP2LPa4pOL LKsW9w8W6LyCoq1VSJS+hRZYrKa+GsHjo4fW+Nq2M9/70jbgORMne7CfisVCi6DJXLnC pEPIQYhOCaC5pn3aguVG11d7fZIifPaQPeQaBS0E+FKuj/iF2sn9wtqm/XRhTk+IsJ50 alB/rYCNN4SInHQF0rI/kRYfYSV7mRDhwLafMUYNkaLWOnYUkPz+/KkUc/i55Ewg2GHO IC3OpgXra67v5taaNhTP3zpSybtXtjqaqJqQ97K9xmkAooZBwc+v/lB3jvFCmNxG9sqF t0Pg== X-Gm-Message-State: AOAM532tiXVQIUV3sEg56BY05eWphClHMTR+JB8SRG2/dxibRW6Erosw uvUb5p5HvjaZIF2NUd4Yxp+gEf0R4ccjmxiOWDY8ng== X-Google-Smtp-Source: ABdhPJy7WHpJUIREpkkt1SiJoFuv7VMQeDJC7nvP/4yoTRC3ZslxlQX6Wq1GTot8v3nG8mxeJZIeO+idZwfyz+tHoSA= X-Received: by 2002:a2e:b88c:: with SMTP id r12mr10794956ljp.266.1592143523722; Sun, 14 Jun 2020 07:05:23 -0700 (PDT) MIME-Version: 1.0 References: <20200525024955.225415-1-jandryuk@gmail.com> <20200613124044.GN6329@mail-itl> In-Reply-To: <20200613124044.GN6329@mail-itl> From: Jason Andryuk Date: Sun, 14 Jun 2020 10:05:12 -0400 Message-ID: Subject: Re: [PATCH 0/8] Coverity fixes for vchan-socket-proxy To: =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sat, Jun 13, 2020 at 8:40 AM Marek Marczykowski-G=C3=B3recki wrote: > > On Wed, May 27, 2020 at 10:59:55PM -0400, Jason Andryuk wrote: > > On Mon, May 25, 2020 at 6:36 PM Jason Andryuk wrot= e: > > > > > > On Sun, May 24, 2020 at 10:50 PM Jason Andryuk w= rote: > > > > > > > > This series addresses some Coverity reports. To handle closing FDs= , a > > > > state struct is introduced to track FDs closed in both main() and > > > > data_loop(). > > > > > > I've realized the changes here are insufficient to handle the FD > > > leaks. That is, the accept()-ed FDs need to be closed inside the for > > > loop so they aren't leaked with each iteration. I'll re-work for a > > > v2. > > > > So it turns out this series doesn't leak FDs in the for loop. FDs are > > necessarily closed down in data_loop() when the read() returns 0. The > > only returns from data_loop() are after the FDs have been closed. > > data_loop() and some of the functions it calls will call exit(1) on > > error, but that won't leak FDs. > > > > Please review this series. Sorry for the confusion. > > For the whole series: > > Reviewed-by: Marek Marczykowski-G=C3=B3recki Thanks for the review. Sorry for forgetting to CC you on this series and the v2 posted on Jun 10th as well. For v2, patch 1 now also changes strncpy to strcpy to avoid a gcc-10 warning reported by Olaf Hering. Patches 2 & 3 are new to move some perror calls. v1 patches 2-8 shifted to 4-10 in v2, but are unchanged. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Sun Jun 14 14:08:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 14:08:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkTJJ-00024Y-1A; Sun, 14 Jun 2020 14:08:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkTJH-00024S-Pr for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 14:08:31 +0000 X-Inumbo-ID: 85dd2616-ae48-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 85dd2616-ae48-11ea-8496-bc764e2007e4; Sun, 14 Jun 2020 14:08:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VL/YXPX5RyTXluowkRpirECOKfqxyy1Gj2wIDzO6UN0=; b=aKpkey4VNna+m42q+DlB2Y+VS grGEsjRxAh4UYaKtWILm36xhg03UGxpGTGcSUDKAOQqYhp4Ibe/V1CvcKzg5m9q2Pz9dQ5dVE1f4E Cjv4/fQe6ywMD6mwWZdZEYXcU7QSKmmBAENG1723TBbCt4GXOM9UcpgSik+LzTB5HDaLI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkTJF-0004Ta-3Q; Sun, 14 Jun 2020 14:08:29 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkTJE-0003b5-Pl; Sun, 14 Jun 2020 14:08:28 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkTJE-0002Ao-Oh; Sun, 14 Jun 2020 14:08:28 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151073: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:regression xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=b91825f628c9a62cf2a3a0d972ea81484a8b7fce X-Osstest-Versions-That: xen=7028534d8482d25860c4d1aa8e45f0b911abfc5a From: osstest service owner Date: Sun, 14 Jun 2020 14:08:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151073 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151073/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 151051 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151051 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151051 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151051 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151051 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151051 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151051 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151051 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151051 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151051 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce baseline version: xen 7028534d8482d25860c4d1aa8e45f0b911abfc5a Last test of basis 151051 2020-06-11 21:19:41 Z 2 days Testing same since 151073 2020-06-13 09:25:00 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper George Dunlap Jan Beulich Juergen Gross Paul Durrant Roger Pau Monne Roger Pau Monné jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit b91825f628c9a62cf2a3a0d972ea81484a8b7fce Author: Andrew Cooper Date: Fri Jun 12 11:55:19 2020 +0100 tools/libxc: Drop config_transformed parameter from xc_cpuid_set() libxl is now the sole caller of xc_cpuid_set(). The config_transformed output is ignored, and this patch trivially highlights the resulting memory leak. "transformed" config is now properly forwarded on migrate as part of the general VM state, so delete the transformation logic completely, rather than trying to adjust just libxl to avoid leaking memory. Signed-off-by: Andrew Cooper Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant Reviewed-by: Ian Jackson commit 2995d0afdf2d3fb44d07eada088db3613741db1e Author: Roger Pau Monne Date: Wed Jun 10 16:29:23 2020 +0200 x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask There's no need to setup a timer for GSIs that are edge triggered, since those don't require any EIO or unmask, and hence couldn't block other interrupts. Note this is only used by PVH dom0, that can setup the passthrough of edge triggered interrupts from the vIO-APIC. One example of such kind of interrupt that can be used by a PVH dom0 would be the RTC timer. While there introduce an out label to do the unlock and reduce code duplication. Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper Release-acked-by: Paul Durrant commit 6fa25d568f4e597b1940309d97cfd98f4f6eecd6 Author: Roger Pau Monne Date: Wed Jun 10 16:29:22 2020 +0200 x86/passthrough: do not assert edge triggered GSIs for PVH dom0 Edge triggered interrupts do not assert the line, so the handling done in Xen should also avoid asserting it. Asserting the line prevents further edge triggered interrupts on the same vIO-APIC pin from being delivered, since the line is not de-asserted. One case of such kind of interrupt is the RTC timer, which is edge triggered and available to a PVH dom0. Note this should not affect domUs, as it only modifies the behavior of IDENTITY_GSI kind of passed through interrupts. Signed-off-by: Roger Pau Monné Acked-by: Andrew Cooper Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant commit 3664f7b7788b66bb802432e6748be0fb57993581 Author: Paul Durrant Date: Tue Jun 9 17:29:22 2020 +0100 CHANGELOG: add revised kdd handshake (supporting Windows 7, 8, and 10) Signed-off-by: Paul Durrant Acked-by: George Dunlap commit b87dd7bb3946c6a18f4c3f622ce7e77a3deb9f17 Author: Paul Durrant Date: Tue Jun 9 17:29:21 2020 +0100 CHANGELOG: add 'domid_policy' and domid preservation on migrate Signed-off-by: Paul Durrant Acked-by: George Dunlap commit 10ea4e417b4655f3550b6e9645f7f2bad08dba13 Author: Andrew Cooper Date: Mon Jun 8 18:12:44 2020 +0100 docs: Minor build improvements Don't use "set -x" for the figs rule. It doesn't take effect in the recursive make environment. Turn the HTML manpage comments into makefile comments, not shell comments. This saves 3x shell invocations per manpage. Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Release-acked-by: Paul Durrant commit aad20e538d7ba0e36f5ed8d2bebb74096e3a6d7f Author: Juergen Gross Date: Wed May 20 10:35:01 2020 +0200 tools/libxengnttab: correct size of allocated memory The size of the memory allocated for the IOCTL_GNTDEV_MAP_GRANT_REF ioctl() parameters is calculated wrong, which results in too much memory allocated. Signed-off-by: Juergen Gross Reviewed-by: Ian Jackson Reviewed-by: Roger Pau Monné Release-acked-by: Paul Durrant (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Jun 14 14:37:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 14:37:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkTl1-0004YG-N1; Sun, 14 Jun 2020 14:37:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkTl0-0004YB-SF for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 14:37:10 +0000 X-Inumbo-ID: 874c264c-ae4c-11ea-b7bb-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 874c264c-ae4c-11ea-b7bb-bc764e2007e4; Sun, 14 Jun 2020 14:37:10 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id l27so14724108ejc.1 for ; Sun, 14 Jun 2020 07:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=F6On6rf2nicxLWMEIcW1TLcL1Hrgjpywh0LpJEepZ+k=; b=oxPWLN2RwlVG6htFCyTgxZKsxUBq7DbHG2EtNWJHb3TseGAKq4i8qIVWF7B4jWv1Pp 5j62QlNPBifHdsNk4uFFi7DTWyyvAMSG7Jgzo/tacn45UddqAyK3tHGG5chf5hna3Nmp HodrGPRIca6y1EvLsrCmFa7m5yjcy9sJurLbXswQBfn6OqGLcKKql4jRIkwMatorKFRt zF1OTrHnVUPNAzHOFAJ1oWSl6w/TP1XY5ZVOuUMMOr00Ni9hRB1KrcBs4VCJxUROEQ1o AAo2xQGEzKZ7nhza8lhTPMnFLnvA4cjXEF7ihZRKX/DsG/iQKMefYATaVrwdyAO8VUDm L/jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=F6On6rf2nicxLWMEIcW1TLcL1Hrgjpywh0LpJEepZ+k=; b=gxlsF2j/H0+hzXpZLww8DCTtmcCJX1sDL+6bOvSBuV5Fx6AIfVbTSDXO/EqWs1mDYO 6sXOZhhSfRNvNHjltsrs20bLNyQv7O1pJ5pP9xpqziwB8S7E5AQXBKbFBknG7dR+NW+h rLN81C1uybVXcB1sdknULVQmS5rJ2QJZKhtAAZ6sa5HzfERrHrUyhAE57J1RL8gqvqHe OVMDItEstp0nNccRgB+J0AFeo34dHIBUYB7glK2L67wqW4ySCqZn9/JIXjuYa2GFDqcK Yj5nAHbLpIfVXKmyuteL53JBSDyvojPwfLjmtnbTF5VCmRU83u5SHfI6qh3xxljrvMgc nEVg== X-Gm-Message-State: AOAM530q/qdESSR5gvqQZOKWPGnDK/VmDpyjhjeokMH7Sci/uvNzLxLL QTh0xfIeFyoCfn5n8yExpaqaTXDEiAX5hA== X-Google-Smtp-Source: ABdhPJy2itoXi9nScreiQpUBnRAYugeC2fwZnD4WdPcs4gx2OBKLUy8Nsba+6yJV2mYuNx5COFgW2A== X-Received: by 2002:a17:906:784c:: with SMTP id p12mr21434137ejm.123.1592145429358; Sun, 14 Jun 2020 07:37:09 -0700 (PDT) Received: from localhost.localdomain (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id l18sm6753823eds.46.2020.06.14.07.37.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2020 07:37:08 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH 0/1] Fix broken suspend on some machines Date: Sun, 14 Jun 2020 14:36:27 +0000 Message-Id: X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , Jan Beulich , j.nowak26@student.uw.edu.pl, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, The included patch is a small subset of a bigger patch set spanning few projects aiming to isolate the GPU in Qubes OS to a dedicated security domain. I'm doing this together with 3 colleagues as part of our Bachelors thesis. While working on the project we came across 2 machines - newer gaming laptops on which the suspend functionality on unmodified xen is completely broken. The affected machines were able to suspend but not always resume. Even if the resume succeeded then the kernel time was trashed in the dmesg log and the machine never managed to suspend another time. After changing the xen clock to hpet, suspend started working again both on stock xen and Qubes OS - this indicates a bug in the ACPI PM Timer. After disassembling the FADT ACPI table on the ASUS FX504GM I understood that the reported bit width is 32 bits but the flags indicate a 24 bit PM timer. The included patch fixes the suspend feature on ASUS FX504GM and hopefully other laptops - Probably next week I will test this patch on my friend's laptop where this issue also occurs(suspend is broken, trashed kernel time after resume). Grzegorz Uriasz (1): x86/acpi: Use FADT flags to determine the PMTMR width xen/arch/x86/acpi/boot.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Sun Jun 14 14:37:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 14:37:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkTlA-0004Yp-VL; Sun, 14 Jun 2020 14:37:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkTl9-0004YZ-Na for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 14:37:19 +0000 X-Inumbo-ID: 8c810dbc-ae4c-11ea-8496-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8c810dbc-ae4c-11ea-8496-bc764e2007e4; Sun, 14 Jun 2020 14:37:19 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id l27so14724301ejc.1 for ; Sun, 14 Jun 2020 07:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=CedW14TZMrLJXwa4+9NGmni6qCAFSImofjSKJjmOefU=; b=gJQq1FDmHMLUhXCfeJ9EaXnakb1HIsoBaM/XtOYTk8lagU6V50luI9Wlhl+uu6KBl5 hLyw6rIprV2KPFLzGrBSvCLCQam1asQ4oLOwQ0zqUyvvljqKksTKa+sNJ7zQIUZUsDs2 PEP66Fsn+ntqXgnDt1w15ZTuXAfIKZMDElfj7qVtpfnVbFcJqrtrmaJ0g9DSRZSVU741 5LMBc8sWzWcmf0YeVG4RiZCJjGv8g8JWNYlFFSmAjDFe4B7i6PZ9Nq3izmOaEX0hLNPP lfVsoorjpSkQJPx7JNDdBpL3xXj+wOu/BmFR3wBmu79rwaxsrU7IcQrw2BT2SrGUt1nV 4xlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CedW14TZMrLJXwa4+9NGmni6qCAFSImofjSKJjmOefU=; b=G8woINkKRJIqncihWB27G19N7EpQt7YJ+U6/nn40jU/WYlO6x0S50ORbWOpJrxCmDg d2nFvBfXhbd7F227bRvmCH3EahugKiYlfQGMGr5OPmEaA+tPAPNAZvoYsc359DaDKHbB CuyfwOhz1ActdWk8YP/CPeVepvgFViU1RA6iZXp23SUL9mzRuitarhOSw8EedLOJpf/p dZZxWm9hmFDwLhJyeJcY4MYCShxCvTlv1cBoAoRueegmp2PcP/qWS+hAQq7XnlWA6Oqd MCwbZk/Vl70xGlazqnOXF8Mvfc1sfKi+uPcaSt+h6E8Pe+snxblHCDBBp0AJoBaHUDJL q0sA== X-Gm-Message-State: AOAM533c+mBS91BihmBj+KjdlcpCVZocDFe3yvPSPRvyw6VjS2vcS90Q 4629SCoR8bktpU6ngIaNKL1VC7xHwW7ZhA== X-Google-Smtp-Source: ABdhPJz0eyvA2OIgEU9X+Hg7Ah43Y42zZY+0qhsOZ53d3nnb1vpl798Adk67xG2sumjh0f9KqhCRgA== X-Received: by 2002:a17:906:d933:: with SMTP id rn19mr22297701ejb.158.1592145437986; Sun, 14 Jun 2020 07:37:17 -0700 (PDT) Received: from localhost.localdomain (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id l18sm6753823eds.46.2020.06.14.07.37.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2020 07:37:17 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Date: Sun, 14 Jun 2020 14:36:28 +0000 Message-Id: X-Mailer: git-send-email 2.27.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , Jan Beulich , j.nowak26@student.uw.edu.pl, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On some computers the bit width of the PM Timer as reported by ACPI is 32 bits when in fact the FADT flags report correctly that the timer is 24 bits wide. On affected machines such as the ASUS FX504GM and never gaming laptops this results in the inability to resume the machine from suspend. Without this patch suspend is broken on affected machines and even if a machine manages to resume correctly then the kernel time and xen timers are trashed. Signed-off-by: Grzegorz Uriasz Tested-by: Grzegorz Uriasz --- xen/arch/x86/acpi/boot.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c index bcba52e232..2ad3eb4abc 100644 --- a/xen/arch/x86/acpi/boot.c +++ b/xen/arch/x86/acpi/boot.c @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) if (fadt->xpm_timer_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO) { pmtmr_ioport = fadt->xpm_timer_block.address; - pmtmr_width = fadt->xpm_timer_block.bit_width; + if (fadt->flags & ACPI_FADT_32BIT_TIMER) + pmtmr_width = 32; + else + pmtmr_width = 24; } } /* -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Sun Jun 14 16:17:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 16:17:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkVKC-0004tY-NZ; Sun, 14 Jun 2020 16:17:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkVKA-0004tT-Kj for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 16:17:34 +0000 X-Inumbo-ID: 8d9f0812-ae5a-11ea-8496-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8d9f0812-ae5a-11ea-8496-bc764e2007e4; Sun, 14 Jun 2020 16:17:34 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id q19so14836778eja.7 for ; Sun, 14 Jun 2020 09:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=C3mRdoRg64BYc4ys1yIyprFZdBXkem8fN8ugpNmuLtA=; b=OgmSgp0YvbM4MjXhwP44uDmQ9IJchTdgBfvwlcsY4z0Knp2mv3PlL6fcJcdpuNKafO 1itnNmVeSD44yfoyyoVvnyGiTCmMQZi+2fxf9j+tNpyj45zMHojjthi+HrdZvsqga9VT CcxaV92AnGeqoXnsZZYFcom6qGjnFkpQKaAViILeMdHtQ08KrVUfLlDrUr3HVqhTirpP JS1Z/8K5xNQ3Ey0afUOGavvpflzd3cKTr1aWTn4jw+uZVabvC10AuR6HjTED73OLi45V F/ddhM+o7fp3RAO1otiEaNDoN6PkPgOXW5NUvQ8QSI4HhKdPTr0Z13Y5nIDy4YUCpCkd ss+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=C3mRdoRg64BYc4ys1yIyprFZdBXkem8fN8ugpNmuLtA=; b=SxU3gKfRhF+TXzG6hRxJOZ0mP5eOy76Geyb9jcJdZodOv6jGDK/JlRFKx3AT7wmtE9 mathdpxNh3FgVADYqs04GhUtvIeOaHWop6RWa7UDHmUy9p3JB+Np8jNKoMieG7Q5bSn5 GhO+0HD7+XxxDYmwmogrxa89HEqnaXibLklNqTJq/Hjy9tdZgWa3627p/CqmhFcvpCmx miPWHhZFJDsQHLK/ToAPlpJ5r0qEaIUJVfPYqDjK+yxVZHMR4m8LUqKdH728/ja47SdR A7aKLCciq6hhToBNVbkp5nuwFQaM6U2/bysbYs+KMggtcFldgXbl8R0eoV5J0DbMFSLA 0BGw== X-Gm-Message-State: AOAM530kcSaIGB6LjWfIOuVndE7KW7NgUI9wngiVkRn76MJOZdETVRQ1 SwVRckc71JTQO6MiRkSVm2QrG2lvyX/4tg== X-Google-Smtp-Source: ABdhPJzu809FPnL+SaqbdfLTTjXT3ClJxmAO7HnV+sg36krRUjBee4Bzk6FUlRj35IvMH7D64wzQhw== X-Received: by 2002:a17:906:1fcd:: with SMTP id e13mr21718301ejt.472.1592151452843; Sun, 14 Jun 2020 09:17:32 -0700 (PDT) Received: from localhost.localdomain (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id g25sm6752429edq.34.2020.06.14.09.17.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2020 09:17:32 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH] libxl: tooling expects wrong errno Date: Sun, 14 Jun 2020 16:17:08 +0000 Message-Id: X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Ian Jackson , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, Anthony PERARD , contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" When iommu is not enabled for a given domain then pci passthrough hypercalls such as xc_test_assign_device return EOPNOTSUPP. The code responsible for this is in "iommu_do_domctl" inside xen/drivers/passthrough/iommu.c This patch fixes the error message reported by libxl when assigning pci devices to domains without iommu. Signed-off-by: Grzegorz Uriasz Tested-by: Grzegorz Uriasz --- tools/libxl/libxl_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index 957ff5c8e9..bc5843b137 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -1561,7 +1561,7 @@ void libxl__device_pci_add(libxl__egc *egc, uint32_t domid, LOGD(ERROR, domid, "PCI device %04x:%02x:%02x.%u %s?", pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func, - errno == ENOSYS ? "cannot be assigned - no IOMMU" + errno == EOPNOTSUPP ? "cannot be assigned - no IOMMU" : "already assigned to a different guest"); goto out; } -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Sun Jun 14 16:48:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 16:48:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkVni-0007L6-4u; Sun, 14 Jun 2020 16:48:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkVng-0007L1-Sj for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 16:48:05 +0000 X-Inumbo-ID: cf264710-ae5e-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cf264710-ae5e-11ea-8496-bc764e2007e4; Sun, 14 Jun 2020 16:48:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VNlqYZmR5mAGo+69VfTIv/oam30gFReLSrZwU7KOKLI=; b=F9c8lKCRA6Brwf5Gw+xVovxe8 oFMF7z25yngxsOkZO/Q38U6aNOtq3qANmvZPj+fIOvz+qNB6BL/j4kO0Jl7a9VmxjwR5e94RnS8k4 Zee9kxl/AAe0wPpCqVimQO12epNgRTFhNP60i9AXvUFFOmPHMbUZPEhdWZfDLGLo/72DE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkVnc-0007qW-Ba; Sun, 14 Jun 2020 16:48:00 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkVnb-0002qe-WC; Sun, 14 Jun 2020 16:48:00 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkVnb-0004yo-VU; Sun, 14 Jun 2020 16:47:59 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151082: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=d58c48df8c6ca819f5e6e6f1740bb114f24f024f X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Sun, 14 Jun 2020 16:47:59 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151082 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151082/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 151058 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen d58c48df8c6ca819f5e6e6f1740bb114f24f024f baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 31 days Failing since 150943 2020-06-09 17:06:00 Z 4 days 5 attempts Testing same since 151058 2020-06-12 04:30:55 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Jun 14 20:32:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 20:32:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkZIF-0000Mo-G8; Sun, 14 Jun 2020 20:31:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkZID-0000Mj-Rw for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 20:31:49 +0000 X-Inumbo-ID: 1228a35e-ae7e-11ea-b790-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1228a35e-ae7e-11ea-b790-12813bfff9fa; Sun, 14 Jun 2020 20:31:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=t+SwwC7BXsjSC0nq6x9AKAAcgeUpG6cXs8YCT9GEac4=; b=AFO7bnxNn53GclLIw8CSvUDzt iUCb740m7KF9jPI3B3K1jghAmSgZDxkJ04z/OGb2w34YKKaQdfTNN8CpunEoJE7zocqjHxEmFfxd2 Oem3Xxu1pZUhXlBA7mpl/+4H03rtiSgoaA0cnbq+kP4HkjL0b/+NyJQNMyU0gjNZGpcvM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkZIB-0003dv-Nq; Sun, 14 Jun 2020 20:31:47 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkZIB-0005U6-C3; Sun, 14 Jun 2020 20:31:47 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkZIB-0003co-BN; Sun, 14 Jun 2020 20:31:47 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151091: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=63d08bec0b2dace2fcefffb23a1fa5b14c473d67 X-Osstest-Versions-That: libvirt=0d009ca646a4e7438952f6d2739ab7f48ef533ab From: osstest service owner Date: Sun, 14 Jun 2020 20:31:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151091 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151091/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151040 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151040 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 63d08bec0b2dace2fcefffb23a1fa5b14c473d67 baseline version: libvirt 0d009ca646a4e7438952f6d2739ab7f48ef533ab Last test of basis 151040 2020-06-11 04:19:36 Z 3 days Testing same since 151062 2020-06-12 12:50:09 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Yi Li jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 0d009ca646..63d08bec0b 63d08bec0b2dace2fcefffb23a1fa5b14c473d67 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sun Jun 14 20:51:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 20:51:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkZbQ-000221-Ae; Sun, 14 Jun 2020 20:51:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkZbO-00021b-OO for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 20:51:38 +0000 X-Inumbo-ID: d0c3d80e-ae80-11ea-b793-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d0c3d80e-ae80-11ea-b793-12813bfff9fa; Sun, 14 Jun 2020 20:51:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oBAg/6MD7FFS1lLPADWAH2e9L6U9bstfhxVJbmTbweQ=; b=UhTZp/Rr4C1fzhiBLElve58fl 2tDcPukUSaFnJ3BxZN3HcWLAPtu6WSPniqx0khieo4Ahkgw27Bov4NGML8PloTchXDw50mYPzEskH XnTCZGrMqH+mnq6AqdxijOZKaX0RhGReQj4Ac461002YNHNykaJCf7rsMyuuRZi32xjC8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkZbC-0003zA-FO; Sun, 14 Jun 2020 20:51:26 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkZbC-00067U-7J; Sun, 14 Jun 2020 20:51:26 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkZbC-00089A-5y; Sun, 14 Jun 2020 20:51:26 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 151087: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.10-testing:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression xen-4.10-testing:test-amd64-i386-xl-raw:debian-di-install:fail:regression xen-4.10-testing:test-amd64-amd64-pygrub:debian-di-install:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-amd64-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-arm64-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-armhf-libvirt:libvirt-build:fail:regression xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=ce056837082da7b2759a069045e480638094adcd X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Sun, 14 Jun 2020 20:51:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151087 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151087/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039 build-i386-prev 6 xen-build fail REGR. vs. 150039 build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 150039 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 150039 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen ce056837082da7b2759a069045e480638094adcd baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 40 days Failing since 150941 2020-06-09 17:05:34 Z 5 days 7 attempts Testing same since 151059 2020-06-12 08:13:16 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark John Thomson Julien Grall Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub fail test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw fail test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit ce056837082da7b2759a069045e480638094adcd Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 934d6e1a77947662504cf4d5e36c9520e03aa731 Author: John Thomson Date: Tue May 15 11:48:43 2018 +1000 tools/ocaml/libs/xc fix gcc-8 format-truncation warning CC xenctrl_stubs.o xenctrl_stubs.c: In function 'failwith_xc': xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "%d: %s: %s", error->code, ^ xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028 snprintf(error_str, sizeof(error_str), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%d: %s: %s", error->code, ~~~~~~~~~~~~~~~~~~~~~~~~~~ xc_error_code_to_desc(error->code), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error->message); ~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1 m Signed-off-by: John Thomson Acked-by: Christian Lindig Release-acked-by: Juergen Gross (cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795) commit 6e636f297f12a52ce12db11ea0787dd541937ed6 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:50 2018 +0200 tools/misc: fix hypothetical buffer overflow in xen-lowmemd gcc-8 complains: xen-lowmemd.c: In function 'handle_low_mem': xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=] snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~ ~~~~ xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In practice it wouldn't happen, because 'data' contains string representation of 64-bit unsigned number (20 characters at most). But place a limit to mute gcc warning. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080) commit dfc0b23403a2f0069bc7b9c0c20dfe5513eb8fb5 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:52 2018 +0200 tools/blktap2: fix possible '\0' truncation gcc-8 complains: tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring': tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^ tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255 snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "- 1" in buffer size should be actually applied to message, to leave place for terminating '\0', not the other way around (truncate '\0' even if it would fit). In function 'tapdisk_control_open_image', inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10: tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'tapdisk_control_create_socket', inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9: tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block-qcow.c: In function 'qcow_create': block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(backing_filename, backing_file, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(backing_filename)); ~~~~~~~~~~~~~~~~~~~~~~~~~ I those cases, reduce size of copied string and make sure final '\0' is added. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a) commit 2f83654fa3331d1ec79275072f8742f175f82bc5 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:54 2018 +0200 tools/gdbsx: fix -Wstringop-truncation warning gcc-8 complains: gx_main.c: In function 'prepare_stop_reply': gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(buf, "watch:", 6); ^~~~~~~~~~~~~~~~~~~~~~~~~ Since terminating '\0' isn't needed here at all, switch to memcpy. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f) commit bf467cc828bde380e9201d8b49c7866a5b92d719 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:53 2018 +0200 tools/xenpmd: fix possible '\0' truncation gcc-8 complains: xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->oem_info, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->battery_type, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->serial_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->model_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy 31 chars, then make sure terminating '\0' is present. Those fields are passed to strlen and as '%s' for snprintf later. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b) commit 6df4d40d846eb5151a89d26d1a63d632c6b9eb55 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:49 2018 +0200 tools/libxc: fix strncpy size gcc-8 warns about possible truncation of trailing '\0'. Final character is overridden by '\0' anyway, so don't bother to copy it. This fixes compile failure: xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159) commit e20bb5818174e9d09389776cb14781b9c6436554 Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit a1a9b055a349748083665e42843f75d6db2c6a7b Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit afca67fafde22033b9a967ae197a10af5c654f02 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Jun 14 22:12:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 22:12:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkarX-0000BP-1L; Sun, 14 Jun 2020 22:12:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkarV-00009r-Mu for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 22:12:21 +0000 X-Inumbo-ID: 1a644538-ae8c-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1a644538-ae8c-11ea-bb8b-bc764e2007e4; Sun, 14 Jun 2020 22:12:15 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id mb16so15382762ejb.4 for ; Sun, 14 Jun 2020 15:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=K9vVjeVfBAmD5toSQvhwolJYZoUXP1UxEwduLBU73+A=; b=adGPkbzd1pDFW3MMUjjil8woWTnpy+IswqfHTBgRpgUbyY0AVHlMEKG1ayjzQFjxGz 5G3gUp4An2Nvf5+xtlvUBunXcYc2WLQX42O7pVQmwJH/zJWgWgTIEr54qGeS/VuALz1Q 9wUpKwpddrfCgGMAKXevlA9ZRN+cEoWSsfsAwIBmt5lrAV/7cEXZ7u4de4sv1XjYr3HV FbEAYtti7lgeykcE0PlstCDtmD++QZDXkd+CQYw1hpNja4QvDqV5OIyA3PjeVLUtNQPE 1DNv4GtjP2YW3QlKlZDr/H5zzlG4vL6HpcWB4eHWUmFvZsSHBKFGFLXqAbmu10LaxikN gzYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=K9vVjeVfBAmD5toSQvhwolJYZoUXP1UxEwduLBU73+A=; b=ZGrwSYmnc1eJpEuYifzTk2Zr+TCDrYgbQ8Ksw8Ovw/xtywTrV5E/Wca15mbX7fUhpw WKR6UIpVlF0wPeL4JgC8gnVhH0xu96LbGApKVmK6neZ4IKpa725gSEoSqiyoOU9wKAoU MmVOcQSpK+O9k1WKK0mgK4wHJUJFfON+1wsp1GlhRrLADbRusoV1pedZSVq6S5CeLrcu bad4mf/MKCj/YfRHbSB4Q6Kr+s3lPqQorETM4CMWRhZlUnXl/qXJi3E7gU7oNS4Ujywi CxLaOlDniuBwFWIIhUkz6Jz/lmLCYR6c19URmPVgIIXu/oQ6XkTERChxLfM/bQ5RS2/p vjQA== X-Gm-Message-State: AOAM530pQpzJp4BTzGOw2Agh8W/T5+s2tT5OCbArFRK7PWJrOnLu//QI DsVA8qfluWAVVKV4UzIQgplNQtlLC4QrdQ== X-Google-Smtp-Source: ABdhPJxxMqGxxS/Bt2pPFAmezto6oZ1Tkhi9T994RozWfo95KLi4xIcCkyj/iEhidE91AhWez433ig== X-Received: by 2002:a17:906:b1c3:: with SMTP id bv3mr23526685ejb.292.1592172734456; Sun, 14 Jun 2020 15:12:14 -0700 (PDT) Received: from localhost.localdomain (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id o13sm7772828ejb.46.2020.06.14.15.12.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2020 15:12:13 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH 2/3] tools/libxl: Grant permission for mapping opregions to the target domain Date: Sun, 14 Jun 2020 22:12:02 +0000 Message-Id: <18bebc4af48b83d71b3247082434b958be84b841.1592171394.git.gorbak25@gmail.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Ian Jackson , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, Anthony PERARD , contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" IGD VGA devices require a special opregion MMIO region which functions as an extra BAR in the PCI configuration space. Right now qemu is assigning those permissions - this is failing inside a linux based stubdomain as the stubdomain is not privileged. This patch grants the permissions for opregions in libxl instead of qemu. Granting permissions in qemu may be removed when this patch get's merged - for now linux based stubdomains which use IGD's need to patch qemu and include this patch in xen for IGD passthrough to work. Signed-off-by: Grzegorz Uriasz --- tools/libxl/libxl_pci.c | 46 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index 436190f790..48b1d8073b 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -2497,7 +2497,51 @@ static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t dom } static int libxl__grant_igd_opregion_permission(libxl__gc *gc, const uint32_t domid) { - return 0; + char* sysfs_path; + FILE* f; + uint32_t igd_host_opregion; + int ret = 0; + uint32_t stubdom_domid = libxl_get_stubdom_id(CTX, domid); + + sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/config", 0, 0, 2, 0); + f = fopen(sysfs_path, "r"); + if (!f) { + LOGED(ERROR, domid, "Unable to access IGD config space"); + return ERROR_FAIL; + } + + ret = fseek(f, 0xfc, SEEK_SET); + if (ret < 0) { + LOGED(ERROR, domid, "Unable to lseek in PCI config space"); + goto out; + } + + ret = fread((void*)&igd_host_opregion, 4, 1, f); + if (ret < 0) { + LOGED(ERROR, domid, "Unable to read opregion register"); + goto out; + } + + ret = xc_domain_iomem_permission(CTX->xch, stubdom_domid, + (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), 0x3, 1); + if (ret < 0) { + LOGED(ERROR, domid, + "failed to give stubdom%d access to %"PRIx32" opregions for igd passthrough", stubdom_domid, igd_host_opregion); + goto out; + } + + ret = xc_domain_iomem_permission(CTX->xch, domid, + (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), 0x3, 1); + if (ret < 0) { + LOGED(ERROR, domid, + "failed to give dom%d access to %"PRIx32" opregions for igd passthrough", domid, igd_host_opregion); + goto out; + } + + out: + if(f) + fclose(f); + return ret; } int libxl__grant_vga_iomem_permission(libxl__gc *gc, const uint32_t domid, -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Sun Jun 14 22:12:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 22:12:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkarR-0000B4-P1; Sun, 14 Jun 2020 22:12:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkarQ-00009r-Md for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 22:12:16 +0000 X-Inumbo-ID: 1941eeb2-ae8c-11ea-b7bb-bc764e2007e4 Received: from mail-ed1-x543.google.com (unknown [2a00:1450:4864:20::543]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1941eeb2-ae8c-11ea-b7bb-bc764e2007e4; Sun, 14 Jun 2020 22:12:13 +0000 (UTC) Received: by mail-ed1-x543.google.com with SMTP id c35so10124983edf.5 for ; Sun, 14 Jun 2020 15:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=F2zlyMIKfLVDpbJSsJPj/zZztFJH8ixIurr3m9NMur4=; b=S0YApsTeJu5e/fblFRbEgUob92Yv1YnnRSUio+NYsQH6n5INj0+wUhrecL/1N/xJjf SSm0J7Kt9nMSfPUQPMCO0YsqxBMKDvR3xOpoiKWruwFbI/UrW53imvkfhsFN0Ge5IIRP PNxQqM9y46Ad6iyPnQqGiKTD3jK5jy2iWA/0gVs6HVfhErOtqyqeAbpBtspfGDJyde3I HV7wHZx4iGUyIsh3lwayBAf7j5SGrRwnASy8rL2ADi7ag79KWMHpcjYu9ZWhK9p8fRAn QMtJoHlNkL0xALXdy4uol9Sv1CPZcEYbx48gSip8qH91Wj6R6szOGvpB7vnwYwKVjYY6 GYAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=F2zlyMIKfLVDpbJSsJPj/zZztFJH8ixIurr3m9NMur4=; b=W34IDcnyKTiYVFJGL6qWlnZ5ZAzYWf9leoDdycY0CcZgIDWo4GghImv2ch64zjEbYX GFXi6HeSDiwB7cAQmiXCsGp+wrj5AOPmDBITH7yuE2JqC2VSBAaNKXRfTly/qN1+Zp1F 6F0LuPf1CjDim2gFoOc12nRnzXi/y+w04ahp6qs2SS+kw87TsVhukKo5Y237YcE8lrPJ GT3UG4M/z4jRabERiaPTMMl9J009dCtj+0gZFu2ygHgA21yI1J7vnMR7daLwT1sh+aYm XQO8EQfuuXzL9i8RQCRqFxGiR4j539cztphgmgaBgJijPEMcOvtvGMPpLwKMu+0CCFaT DRSA== X-Gm-Message-State: AOAM530Ttbue4j5LP4URCPkzQuBoHF2kYa/WqEJJ7s+Z++NccU+qiYd2 6WSmC4FZBBQ21+oQ5W7CIErT0s8A7eU7wg== X-Google-Smtp-Source: ABdhPJwjNFrm+gUduG2OvP3Fe30QR7Gt+WVgIEU4/reWGAeKtzYMyjGDi9XOsk8lHZ2Sy0Fa0n/icQ== X-Received: by 2002:a50:fb92:: with SMTP id e18mr20499391edq.135.1592172732450; Sun, 14 Jun 2020 15:12:12 -0700 (PDT) Received: from localhost.localdomain (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id o13sm7772828ejb.46.2020.06.14.15.12.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2020 15:12:12 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH 1/3] tools/libxl: Grant VGA IO port permission for stubdom/target domain Date: Sun, 14 Jun 2020 22:12:01 +0000 Message-Id: <87d74a21bde95cfc7c53fad56bf8f0e47724953e.1592171394.git.gorbak25@gmail.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Ian Jackson , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, Anthony PERARD , contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" When qemu is running inside a linux based stubdomain, qemu does not have the necessary permissions to map the ioports to the target domain. Currently, libxl is granting permissions only for the VGA RAM memory region and not passing the required ioports. This patch grants the required permission for the necessary vga io ports. Signed-off-by: Grzegorz Uriasz --- tools/libxl/libxl_pci.c | 99 ++++++++++++++++++++++++++++++----------- 1 file changed, 73 insertions(+), 26 deletions(-) diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index 957ff5c8e9..436190f790 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -2441,17 +2441,75 @@ void libxl__device_pci_destroy_all(libxl__egc *egc, uint32_t domid, } } +static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t domid) { + int ret, i; + uint64_t vga_iomem_start = 0xa0000 >> XC_PAGE_SHIFT; + uint64_t vga_iomem_npages = 0x20; + uint32_t stubdom_domid = libxl_get_stubdom_id(CTX, domid); + uint64_t vga_ioport_start[] = {0x3B0, 0x3C0}; + uint64_t vga_ioport_size[] = {0xC, 0x20}; + + /* VGA RAM */ + ret = xc_domain_iomem_permission(CTX->xch, stubdom_domid, + vga_iomem_start, vga_iomem_npages, 1); + if (ret < 0) { + LOGED(ERROR, domid, + "failed to give stubdom%d access to iomem range " + "%"PRIx64"-%"PRIx64" for VGA passthru", + stubdom_domid, + vga_iomem_start, (vga_iomem_start + (vga_iomem_npages << XC_PAGE_SHIFT) - 1)); + return ret; + } + ret = xc_domain_iomem_permission(CTX->xch, domid, + vga_iomem_start, vga_iomem_npages, 1); + if (ret < 0) { + LOGED(ERROR, domid, + "failed to give dom%d access to iomem range " + "%"PRIx64"-%"PRIx64" for VGA passthru", + domid, vga_iomem_start, (vga_iomem_start + (vga_iomem_npages << XC_PAGE_SHIFT) - 1)); + return ret; + } + + /* VGA IOPORTS */ + for (i = 0 ; i < 2 ; i++) { + ret = xc_domain_ioport_permission(CTX->xch, stubdom_domid, + vga_ioport_start[i], vga_ioport_size[i], 1); + if (ret < 0) { + LOGED(ERROR, domid, + "failed to give stubdom%d access to ioport range " + "%"PRIx64"-%"PRIx64" for VGA passthru", + stubdom_domid, + vga_ioport_start[i], (vga_ioport_start[i] + vga_ioport_size[i] - 1)); + return ret; + } + ret = xc_domain_ioport_permission(CTX->xch, domid, + vga_ioport_start[i], vga_ioport_size[i], 1); + if (ret < 0) { + LOGED(ERROR, domid, + "failed to give dom%d access to ioport range " + "%"PRIx64"-%"PRIx64" for VGA passthru", + domid, vga_ioport_start[i], (vga_ioport_start[i] + vga_ioport_size[i] - 1)); + return ret; + } + } + + return 0; +} + +static int libxl__grant_igd_opregion_permission(libxl__gc *gc, const uint32_t domid) { + return 0; +} + int libxl__grant_vga_iomem_permission(libxl__gc *gc, const uint32_t domid, libxl_domain_config *const d_config) { - int i, ret; + int i, ret = 0; + bool vga_found = false, igd_found = false; if (!libxl_defbool_val(d_config->b_info.u.hvm.gfx_passthru)) return 0; - for (i = 0 ; i < d_config->num_pcidevs ; i++) { - uint64_t vga_iomem_start = 0xa0000 >> XC_PAGE_SHIFT; - uint32_t stubdom_domid; + for (i = 0 ; i < d_config->num_pcidevs && !igd_found ; i++) { libxl_device_pci *pcidev = &d_config->pcidevs[i]; unsigned long pci_device_class; @@ -2460,30 +2518,19 @@ int libxl__grant_vga_iomem_permission(libxl__gc *gc, const uint32_t domid, if (pci_device_class != 0x030000) /* VGA class */ continue; - stubdom_domid = libxl_get_stubdom_id(CTX, domid); - ret = xc_domain_iomem_permission(CTX->xch, stubdom_domid, - vga_iomem_start, 0x20, 1); - if (ret < 0) { - LOGED(ERROR, domid, - "failed to give stubdom%d access to iomem range " - "%"PRIx64"-%"PRIx64" for VGA passthru", - stubdom_domid, - vga_iomem_start, (vga_iomem_start + 0x20 - 1)); - return ret; - } - ret = xc_domain_iomem_permission(CTX->xch, domid, - vga_iomem_start, 0x20, 1); - if (ret < 0) { - LOGED(ERROR, domid, - "failed to give dom%d access to iomem range " - "%"PRIx64"-%"PRIx64" for VGA passthru", - domid, vga_iomem_start, (vga_iomem_start + 0x20 - 1)); - return ret; - } - break; + vga_found = true; + if (pcidev->bus == 0 && pcidev->dev == 2 && pcidev->func == 0) + igd_found = true; } - return 0; + if (vga_found) + ret = libxl__grant_legacy_vga_permissions(gc, domid); + if (ret < 0) + return ret; + if (igd_found) + ret = libxl__grant_igd_opregion_permission(gc, domid); + + return ret; } static int libxl_device_pci_compare(const libxl_device_pci *d1, -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Sun Jun 14 22:12:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 22:12:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkarM-00009w-GN; Sun, 14 Jun 2020 22:12:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkarL-00009r-OD for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 22:12:11 +0000 X-Inumbo-ID: 17dec9f0-ae8c-11ea-8496-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 17dec9f0-ae8c-11ea-8496-bc764e2007e4; Sun, 14 Jun 2020 22:12:11 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id mb16so15382679ejb.4 for ; Sun, 14 Jun 2020 15:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=t7J+vBnr5qW0YqDWMwMgwG/Ldp8mMdAgk7lsL5Cc8KQ=; b=L1VerG+DAo+zLQDiLJsKgrMb/5MmrJDCWpZpmflYixnse0YsI5GbLqL1+vtDofLlwV FXuC8JmKPu1XAEHWk9uuengbfJDrCy6E18aNc16jIzYNJLeJa/HsZzuYv0rpRl2FPiWh KjYWdCgpbhD9vDp/xIHfVLCBpGHwHMFwEvkYcTv/t+zyVVAIPY3QY/Ddp8MpLeVScslT e9Yblpka8SmCTzMW/q/Z9B4t10cdMAz+4Grq63oz7vUNyaW43STf9vGgK0VvV60BqnP5 CK5wsBNGz01vJDlAL8lOKMtWmXWu96hn0g2XxrMkCiNTeWroVBLiA6KLVLx+nwy5u1SB vWIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=t7J+vBnr5qW0YqDWMwMgwG/Ldp8mMdAgk7lsL5Cc8KQ=; b=DmKBQoZSxfqRxZnwgodrZQ1MXKa7IhfLXU6ysiyT5pEVUZ0atSt3sFvonR/Lw5Wfes shb3Jn/X1wW6d+bCZZhKzqi/DKwaoB+5DQ8Ga/PCfZwiZ3A0FxQdOIKfPqeVcEv+iies jSe1Pf78z4QYIYKztROe/Y2FwzSYLESsf03AbXZlMPPdzSAPqMBhME5aXd1+0eq1WsjC AO+WwIc8z9L10TWUZ1q7cVoVabnSTBh8Mq/UybMsUBIURnAYRppWrePBqAfXoW21nv5h 3r3fSQG/OTz7RV74FESNgpOZiZo4lpX0IZjxZJeFM0NRg6H9/lZVUSDi6/8Vr+32Mj53 aNZg== X-Gm-Message-State: AOAM531wmHctbNd0aY/tbvcxrItRYtHxIXpeNDM/pC325hhnFHFrEJcp blj9yPauKSYusoIE1GH9WrxnBga7QPvTLQ== X-Google-Smtp-Source: ABdhPJxCisGBa7uuX9xs30Kf/32tkoMOjxd0hCAn7Ith9LY2zPfToaisRP4aWH2JR2DMw+aNK1ynsw== X-Received: by 2002:a17:906:aad8:: with SMTP id kt24mr22651804ejb.527.1592172730202; Sun, 14 Jun 2020 15:12:10 -0700 (PDT) Received: from localhost.localdomain (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id o13sm7772828ejb.46.2020.06.14.15.12.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2020 15:12:09 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH 0/3] IGD Passthrough fixes for linux based stubdomains Date: Sun, 14 Jun 2020 22:12:00 +0000 Message-Id: X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Ian Jackson , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, Anthony PERARD , contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, The included patches are a small subset of a bigger patch set spanning few projects aiming to isolate the GPU in Qubes OS to a dedicated security domain. I'm doing this together with 3 colleagues as part of our Bachelors thesis. Right now qemu assumes it runs in dom0 so it may grant access to required memory regions and ioports to the target domain for the IGD to work. This is no longer the case with linux based stubdomains as the stubdom is not privileged. Moving some logic from qemu to libxl is necessary for some features to work inside a stubdomain. The included patches were tested on a few laptops(together with the linked qemu patchset) and they work fine. Grzegorz Uriasz (3): tools/libxl: Grant VGA IO port permission for stubdom/target domain tools/libxl: Grant permission for mapping opregions to the target domain tools/libxl: Directly map VBIOS to stubdomain tools/libxl/libxl_pci.c | 153 +++++++++++++++++++++++++++++++++------- 1 file changed, 127 insertions(+), 26 deletions(-) -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Sun Jun 14 22:12:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 22:12:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkarc-0000Ci-9P; Sun, 14 Jun 2020 22:12:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkara-00009r-NB for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 22:12:26 +0000 X-Inumbo-ID: 1b898bb2-ae8c-11ea-8496-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1b898bb2-ae8c-11ea-8496-bc764e2007e4; Sun, 14 Jun 2020 22:12:17 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id gl26so15342904ejb.11 for ; Sun, 14 Jun 2020 15:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=kLRVBuDUDaOcgBVQ0wo5+UBjW8DkKN77rftCvaZTsIA=; b=nekzYCKtPlBwtlHnKvgZ9CzTcRT1AtzMXQnmTO+Ob3xGKrOHXKGXinBUOlfitQfQxj ZCEHH+Iun4a2lBF8xkAiON++UnRrbOE31OymdlD0PHC3t+wuYyKyIx2nU0d+Y/fyFv47 h6YeG9ALHOj+CJkXbphz5+cW8Qk/pF8Et213L8PHGdTIRvvbp1tgu/o6e5MUujYWcjCn q/x7AIO7U6QTbmFsuSrYCN502H+bD8/oj9kCiClP2/2dYf00xGN6Rq51llar0eVlwksR KTZdIAsPZTBTCQRjBd0iprT2fWDeovBcOmWB6bTZBKw1kOVLJbpWTKtIWE4or+AFvc4/ 5DtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=kLRVBuDUDaOcgBVQ0wo5+UBjW8DkKN77rftCvaZTsIA=; b=g8PP/JF8ae/cdlqh+0tDrVLCHie4S6s+iYAoC/tJx4dR72a4MnTGB6d4b4CPrZP/dl /RfCYSFigBsZV7qUrhpG8zhK4MD3XN58N5y907VkRtcdSdOsY9ahOlMGd+bFsLdf9EsY J/JWj/btUes8XZOjDMqBpHaphDH/QoYh0BqtHeYPcVLiPYgiQr/JAvN5W9DJ3edZUpxd KmU1jv/NPtUWbui3EnLLdjS7rsK7SWlBgt0YWHdLMpeTiSlVRGlmRsNW7kd9m1R4s5n9 ZhKSJlBqXB/2YksiHq87Ta+9CXx7h7+JsK4Wrw2cW58UNI0ntpShD/iT5SysvKZXfkDc h5Zw== X-Gm-Message-State: AOAM530F8Xc7fJ0aRrU43gjKtvaVrnlUX5rYmRhxueUe5XhWrwQ1XAHU hfiCjqBeaE774jp0ML6Q14FKE6u41GBXeQ== X-Google-Smtp-Source: ABdhPJz0czg6GoGOiQFBr78sHMKFKu2xW2RrdQcRTPNKDp6zAcszpEcJ6ykOIpV0LcbSQwAIhSlTJg== X-Received: by 2002:a17:907:2162:: with SMTP id rl2mr21608022ejb.365.1592172736358; Sun, 14 Jun 2020 15:12:16 -0700 (PDT) Received: from localhost.localdomain (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id o13sm7772828ejb.46.2020.06.14.15.12.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2020 15:12:15 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH 3/3] tools/libxl: Directly map VBIOS to stubdomain Date: Sun, 14 Jun 2020 22:12:03 +0000 Message-Id: <9817b73ea628c7ac86903bb9aa7fcfecf4f7b900.1592171394.git.gorbak25@gmail.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Ian Jackson , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, Anthony PERARD , contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" When passing through a IGD VGA device qemu needs to copy the host VBIOS to the target domain. Right now the current implementation on the qemu side is one big undefined behavior as described in my qemu patchset here: https://patchew.org/QEMU/20200428062847.7764-1-gorbak25@gmail.com/ This patch is tied to the linked patchset for qemu but fortunately this patch still works without the qemu part merged. When the qemu part gets merged then qemu will access the VBIOS using /dev/mem - this is required as currently the linux kernel forbids accessing this memory region when the VBIOS is corrupted - which will always be the case as described in the linked patchset. When qemu is running inside a linux based stubdomain then the stubdomain does not have access to the VBIOS. This patch maps the VBIOS to the stubdomain so qemu with my fixes may create a shadow copy for the target domain. Signed-off-by: Grzegorz Uriasz --- tools/libxl/libxl_pci.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c index 48b1d8073b..9b9564dd73 100644 --- a/tools/libxl/libxl_pci.c +++ b/tools/libxl/libxl_pci.c @@ -2445,6 +2445,8 @@ static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t dom int ret, i; uint64_t vga_iomem_start = 0xa0000 >> XC_PAGE_SHIFT; uint64_t vga_iomem_npages = 0x20; + uint64_t vga_vbios_start = 0xc0000 >> XC_PAGE_SHIFT; + uint64_t vga_vbios_npages = 0x20; uint32_t stubdom_domid = libxl_get_stubdom_id(CTX, domid); uint64_t vga_ioport_start[] = {0x3B0, 0x3C0}; uint64_t vga_ioport_size[] = {0xC, 0x20}; @@ -2460,6 +2462,7 @@ static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t dom vga_iomem_start, (vga_iomem_start + (vga_iomem_npages << XC_PAGE_SHIFT) - 1)); return ret; } + ret = xc_domain_iomem_permission(CTX->xch, domid, vga_iomem_start, vga_iomem_npages, 1); if (ret < 0) { @@ -2470,6 +2473,13 @@ static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t dom return ret; } + /* VGA ROM */ + ret = xc_domain_memory_mapping(CTX->xch, stubdom_domid, vga_vbios_start, vga_vbios_start, vga_vbios_npages, DPCI_ADD_MAPPING); + if (ret < 0) { + LOGED(ERROR, domid, "failed to map VBIOS to stubdom%d", stubdom_domid); + return ret; + } + /* VGA IOPORTS */ for (i = 0 ; i < 2 ; i++) { ret = xc_domain_ioport_permission(CTX->xch, stubdom_domid, -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Sun Jun 14 23:22:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 14 Jun 2020 23:22:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkbwf-00063a-6K; Sun, 14 Jun 2020 23:21:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkbwd-00063V-EF for xen-devel@lists.xenproject.org; Sun, 14 Jun 2020 23:21:43 +0000 X-Inumbo-ID: ce09bd9e-ae95-11ea-b7bb-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ce09bd9e-ae95-11ea-b7bb-bc764e2007e4; Sun, 14 Jun 2020 23:21:42 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id f7so15468254ejq.6 for ; Sun, 14 Jun 2020 16:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=SH6vGa/2KJH/HQw68J9t455+U0X8pVu2CUDEZICF8XY=; b=EkIv9BYDu2bqD1CBznjqgx+paP0JuGPGE0DqOLWDwiv7lfBUIT49NApiq0ZRi/3k2a HVdA1VVaLKHShFXr379eP0t9AVISe91N5vK3lsX9WU5PS/lT6Vfw9TKXZjmF4QZITHzt G/2TL4LJXm07PWpaXJ50e69gWgbFHaSBdFyIixlWacp/mMngaChRqG9E/78G3TQFuMQr qXHHfCAf20lHz7uFFDy/Xm5D+0dVs0J1AAfmOi6lqCMXXmHUhSs/U9Xxzn1Krtw1Vm/7 FIMZCbRr0oibg6NYn4EweryYKu6DtBVH+GkEwIzQPktg0aoE3md1Uki3WJ8rO02lghDP jQOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=SH6vGa/2KJH/HQw68J9t455+U0X8pVu2CUDEZICF8XY=; b=Csq3bqq7ehM53KRn2hGvCfMm4eAHEayxVTtggRiYQ7hb6/HBedgQphIrRTB30b1D8Y dSB5Cqyb0OkXXstjz1VcOBwutaTpjy5xZG30TBzMJea32WsNCwSRdc+OMebvTntqYQqU beUgQQ3iSzN+u/0XBuLXmA7e1WqFloClz9Vvvf4r+q/lbhckvxG+D9UVVvnn+f4nUM8A l0yGBzMUD5807Wz9Sz3yCikdY/l/w6dzFRNtIb4ANEDlZC3bLGvS8UaKlKXa2HcN88Tw XdLOC6ab4mCUW+ztunKDV/iwJlO5g9VlBru0P580GgQ9vMP6DiFVSqpliONy+X6El/0Y gtsw== X-Gm-Message-State: AOAM532efocYLm7yi2r2neErlh7/DSP17Xdu653gmy3BDqf+tmTo6D3g N07sT0u3XVgeVf71znz6jKw= X-Google-Smtp-Source: ABdhPJwOoAC6qLQWxDRL1D5jvqQBH2cD4fnGpHmX1LN/GMQycdeSu6OgkZRdLPIMHrPNtvN6+LLa8w== X-Received: by 2002:a17:906:7712:: with SMTP id q18mr22584732ejm.140.1592176901522; Sun, 14 Jun 2020 16:21:41 -0700 (PDT) Received: from localhost.localdomain (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id i21sm7332998edr.68.2020.06.14.16.21.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Jun 2020 16:21:41 -0700 (PDT) From: Grzegorz Uriasz To: qemu-devel@nongnu.org Subject: [PATCH] hw/xen_pt: Don't grant opregion permissions Date: Sun, 14 Jun 2020 23:21:09 +0000 Message-Id: <2157e10d63619d43151fe8b8ca913b44c54aba6e.1592176600.git.gorbak25@gmail.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , jakub@bartmin.ski, marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, Anthony Perard , xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" With the upstreaming of linux based stubdomains to xen, qemu can't assume it runs inside dom0 - permission assignment must be moved to libxl running in dom0. This xen patch: https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00973.html implements granting the required permissions to the stubdomain running qemu. This patch removes granting opregion permissions in qemu - this should be fine as when qemu is running inside dom0 the memory mapping will be successfully created without first explicitly granting the permission. Signed-off-by: Grzegorz Uriasz --- hw/xen/xen_pt_graphics.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c index 7d46e9c209..303674365b 100644 --- a/hw/xen/xen_pt_graphics.c +++ b/hw/xen/xen_pt_graphics.c @@ -283,19 +283,6 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val) igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK) | (igd_host_opregion & XEN_PCI_INTEL_OPREGION_MASK); - ret = xc_domain_iomem_permission(xen_xc, xen_domid, - (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), - XEN_PCI_INTEL_OPREGION_PAGES, - XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED); - - if (ret) { - XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:" - " 0x%lx.\n", ret, - (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT)), - igd_guest_opregion = 0; - return; - } - ret = xc_domain_memory_mapping(xen_xc, xen_domid, (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT), (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 00:55:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 00:55:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkdPQ-0005Se-Nw; Mon, 15 Jun 2020 00:55:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkdPP-0005SE-OW for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 00:55:31 +0000 X-Inumbo-ID: e563bd70-aea2-11ea-b7aa-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e563bd70-aea2-11ea-b7aa-12813bfff9fa; Mon, 15 Jun 2020 00:55:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=X720RaArEiz148fT4RhNvkfFWZ7mowktwJ0woSx3C5U=; b=RBqqrVEM+i9nJZ0CweczJFP8r Va33Fb4klOkbOE5luZsJ2sCckZOsGQo5o1jEagdKzoLpPkUhPMhjkRTI3R90sOQFVxLEQtpuKjgUc oYfMgq+TNHYJ89/GqX8TeZJ3vDKPnZMbrPdY/xbxgiFT4528aQjE7RezKZoeUkmguqPSg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkdPH-0000Ze-VU; Mon, 15 Jun 2020 00:55:24 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkdPH-00020k-GN; Mon, 15 Jun 2020 00:55:23 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkdPH-000720-Ff; Mon, 15 Jun 2020 00:55:23 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151093: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Mon, 15 Jun 2020 00:55:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151093 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151093/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 40 days Failing since 150942 2020-06-09 17:05:43 Z 5 days 7 attempts Testing same since 151061 2020-06-12 12:25:05 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 2b77729888fb851ab96e7f77bc854122626b4861 Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Jun 15 01:59:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 01:59:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkeOZ-0002xJ-JM; Mon, 15 Jun 2020 01:58:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkeOY-0002xE-B4 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 01:58:42 +0000 X-Inumbo-ID: bc16e4b6-aeab-11ea-bca7-bc764e2007e4 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [40.107.20.69]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bc16e4b6-aeab-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 01:58:41 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LpgXFeHP0KrCb092cOdVRGrUZ/oHYVbdkIECXQx1vRKZ92djEOaPall2KDf0+2csfXCqKeM6XCQVIapqRJKE2tAsMtiA33rPQy/JE9t9XT6j50vwEz/xSdkOh5zX7UbaPhei0m+Pn2bLL/vgb19BOOWQEpz1fO8NjyToge7HA8iWVg8HXgDJlLezCeC1/d6mJHI2Hs6pjsMqGiU0cz9PFo63M2xAm7M2vL2Uf5H1yZ1zL43fjqaGvGC3WgF1Zp/IW4Ge4K8T+bTdp9EY74QgzMuzZBcRqncetFy+o7sJyeB+qsZ9hYiGR74mVwcC2CWNq0pVVSMeThx8Jh+1sRk1nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PdAKC1uxTVfiefCGuDrSLGAVY237PwO2jpTLEcKuQmc=; b=FQTm3ciXiT0jirzHgKesRGqIpyZGNSx6s1a32v4Al7MUm0y0LvoTL+HVNvKKOLoTqfE9YI7s5py7kqjfpKJ3o0tdwVnc0CVNA6kfHLQnceEB3M4Q8uRnX8HVn2HkVDnvBJ2/RBBWLrhH0qkeX2HXTerzHAgf2Mvr9dMmOSoWR/32MNAyxQ/dKr5EVaSQ9LqumPCwkeK6G+80WAAQ2cZKA37BCFrgAlXL7MCc9YVs7yjW3Cp/UtCTQn3kk26yoGKFdJrDpxHmnQligEzWMdn3uRl3AmRlAGX3v2tponsKmPXhAjH/5b54/DDYGEbH83BuStkLIBveYvpZRPYcUI5OWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PdAKC1uxTVfiefCGuDrSLGAVY237PwO2jpTLEcKuQmc=; b=bB/+cwy3jdF7UCXFS079BjqntOv0Pjfr0hQBoSxMoni85yNfQ1CzN39XIvnh9Qm3sPHAOTbjIdaVh7C7Tj0kcIMurmcQGDsfQvPHhFRBoq32om2bTNiNvcbCEtie0k4rgLWPP5rNsFyCbFXws4fb+fJBZ6mhUGCwkU1RZ29Yh/Q= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2696.eurprd04.prod.outlook.com (2603:10a6:4:a1::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Mon, 15 Jun 2020 01:58:38 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3088.028; Mon, 15 Jun 2020 01:58:38 +0000 From: Peng Fan To: Stefano Stabellini , Oleksandr Andrushchenko Subject: RE: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWN5exllox/cqJUUS0HFcLChNz8ajHt2rggADieACAAAFjAIAQZaQA Date: Mon, 15 Jun 2020 01:58:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1bc5a175-3192-4232-bb99-08d810cf9f19 x-ms-traffictypediagnostic: DB6PR0402MB2696: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YQnBaNeW537xlZNI7iokLI+hbKVInSTpSCBIIal8CJfCMQpQp1y3BfzxepChVr7KWcmlSLedt+ik9ctTUBZkYLAXB3oA7XuqfNM2FRkGtUK5rdIiwFTljk2ieaa4+EXEt2S9cxP9IXz0HPodftkQLX02/kR9hy/c2AUZrXAxh+x26qmHGZiwMMFTPtKRhg81dXVtcQWB094Fczxl7fDWRPMzhV9c6G0fL+4q8Y0fiR6XgaAJ2FUeSXLjBV0DuUHwgmTYMFY4gpDipghz27EhTHlAxoEiEuPN9FeOl9bTq+WPxV6HszeKkGf0XKlajScsBpARWoeTqtAqYUUWzhRGF3Bv8is1lzbbrqlXkgMiqKdTmYwU6HqT/AS9shNZ4IKtXOh71aJQlL927mOzygtuKQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(396003)(366004)(376002)(39860400002)(66446008)(76116006)(66476007)(66556008)(64756008)(66946007)(86362001)(44832011)(54906003)(5660300002)(2906002)(6506007)(7696005)(186003)(52536014)(53546011)(26005)(55016002)(33656002)(478600001)(9686003)(71200400001)(8936002)(316002)(110136005)(966005)(8676002)(83380400001)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Aw9YAc3o6rcMZu6Z0vuYIxi8Y9c+FrtHOS92o4NR3nJ9jjecDjHzMmkO3IpcIhRTaXOEjy0m9xoxRssJQmJUoLkTdukrZk5qRqSUPAW+HzjFVSh49PJWPxcegcf3KOGFaaicXlS+xU0WFTNi+xIMGs/ClxXv5/kzhf3/bAlefTI0DYXngCuf8r4djRYdWaHX1TMWnrB1mlFZUCiS7mOqkxBNO3lWTjnnoDsYFaULbCWEpfWrXruf3dcmHXYlhhMWl9C5Q8ceo2Wtrd1sVWl8hOQZz5fQEydS9AVqf4Do1RnBSES8AwEPLICBBR6HezNFdFgZRjWTHpHFLErRKFs+os0tsvpfJTjeuz9AFxF3QzEZQ+NsZRVrZae8sno+OGiu/Zzpxb9enFuvV1/Df9wcVyHhXNEfEe7GT0ztDRmWkakNgfswFUPiHVhhVMcKgFQ2Vwb/YFBrOaBZebgBNiBW7rNuF7cw7VwU96l4Rp5v3Ss= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1bc5a175-3192-4232-bb99-08d810cf9f19 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 01:58:38.5504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mDJrh54OH9sjGjXbU8KXdzQyKP59OMAusqmw/wTmmYPukJPzV1iVwt5O1KY8ab/zaa7Z39J7ZgUMrv4TYZCxuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2696 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Roman Shaposhnik , Julien Grall , Nataliya Korovkina Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGkgU3RlZmFubywNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVm YW5vIFN0YWJlbGxpbmkgW21haWx0bzpzc3RhYmVsbGluaUBrZXJuZWwub3JnXQ0KPiBTZW50OiAy MDIwxOo21MI0yNUgMjM6MzINCj4gVG86IE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIDxPbGVrc2Fu ZHJfQW5kcnVzaGNoZW5rb0BlcGFtLmNvbT4NCj4gQ2M6IFBlbmcgRmFuIDxwZW5nLmZhbkBueHAu Y29tPjsgUm9tYW4gU2hhcG9zaG5paw0KPiA8cm9tYW5AemVkZWRhLmNvbT47IFhlbi1kZXZlbCA8 eGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3JnPjsgU3RlZmFubw0KPiBTdGFiZWxsaW5pIDxz c3RhYmVsbGluaUBrZXJuZWwub3JnPjsgSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IE5h dGFsaXlhDQo+IEtvcm92a2luYSA8bWFsdXMuYnJhbmR5d2luZUBnbWFpbC5jb20+DQo+IFN1Ympl Y3Q6IFJlOiBVRUZJIHN1cHBvcnQgaW4gQVJNIERvbVVzDQo+IA0KPiBPbiBUaHUsIDQgSnVuIDIw MjAsIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPiA+IE9uIDYvNC8yMCA0OjU3IEFN LCBQZW5nIEZhbiB3cm90ZToNCj4gPiA+IEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47DQo+ID4gPj4g TmF0YWxpeWEgS29yb3ZraW5hIDxtYWx1cy5icmFuZHl3aW5lQGdtYWlsLmNvbT4NCj4gPiA+PiBT dWJqZWN0OiBVRUZJIHN1cHBvcnQgaW4gQVJNIERvbVVzDQo+ID4gPiBXZSBoYXZlIG1hZGUgVS1C b290IHJ1biBpbnNpZGUgWEVOIERvbVUsIGJ1dCBqdXN0IG9ubHkgUFYgY29uc29sZQ0KPiA+ID4g cGFydCwgbm90IGltcGxlbWVudCBvdGhlciBmcm9udGVuZCBkcml2ZXJzIGN1cnJlbnRseS4gV291 bGQgdGhpcw0KPiA+ID4gaGVscCBmb3IgeW91ciBjYXNlIGlmIGVuYWJsZSBFRkkgaW4gVS1Cb290 Pw0KPiA+DQo+ID4gV2VsbCwgd2UgaGF2ZSBhIHdvcmtpbmcgUFYgYmxvY2sgaW1wbGVtZW50YXRp b24gb24gdG9wIG9mIHRoYXQgb24gaU1YOA0KPiA+DQo+ID4gcGxhdGZvcm0sIG1vc3RseSBwb3J0 ZWQgZnJvbSBtaW5pLW9zLiBDdXJyZW50bHkgd2UgYXJlIGZpbmFsaXppbmcgdGhlDQo+ID4gd29y aw0KPiA+DQo+ID4gYW5kIGNsZWFuaW5nIHVwIChpdCdzIGdvaW5nIHRvIHRha2UgYSB3ZWVrIG9y IHNvIGhvcGVmdWxseSkuIFRoZW4sIHdlDQo+ID4gd2UnbGwgcG9zdA0KPiA+DQo+ID4gaXQgb24g b3VyIHB1YmxpYyBnaXRodWIuIFdlIGFyZSBhbHNvIHRoaW5raW5nIGFib3V0IHVwc3RyZWFtaW5n IHRoZQ0KPiA+IHdvcmssIGJ1dCBpdCBtYXkNCj4gPg0KPiA+IHRha2UgcXVpdGUgc29tZSB0aW1l IGlmIHRoZSB3aG9sZSBpZGVhIGZpdHMgdS1ib290J3MgdmlldyBvbiBzdWNoIGFuDQo+IGV4dGVu c2lvbiBhdCBhbGwuDQo+IA0KPiBZZXMgcGxlYXNlIHRvIGJvdGggb2YgeW91ISA6LSkNCg0KVGhl IHNpbXBsZSBjb25zb2xlIHBhcnQNCg0KaHR0cHM6Ly9zb3VyY2UuY29kZWF1cm9yYS5vcmcvZXh0 ZXJuYWwvaW14L3Vib290LWlteC90cmVlL2RyaXZlcnMvc2VyaWFsL3NlcmlhbF94ZW4uYz9oPWlt eF92MjAyMC4wNF81LjQuMjRfMi4xLjANCg0KV2UgZW5hYmxlIFUtQm9vdCBpbiBEb21VIGlzIG1v c3RseSBmb3IgYW5kcm9pZCBhdXRvIGR1YWwgYm9vdGxvYWRlciBjYXNlLg0KDQpJdCBoYXMgdGhl IGlzc3VlIHRoYXQgb25seSBoYXZlIGNvbnNvbGUgb3V0cHV0IGFmdGVyIG1tdSBlbmFibGVkIGlu IFUtQm9vdCBzdGFnZS4NCg0KUmVnYXJkcywNClBlbmcuDQoNCj4gDQo+IEluIHRoZSBtZWFudGlt ZSwgd2hpbGUgd2Ugd2FpdCBmb3IgdGhvc2UgY2hhbmdlcyB0byBnbyB1cHN0cmVhbSBpbiB1Ym9v dCwNCj4gY291bGQgeW91IHBsZWFzZSBwb3N0IGEgYnJhbmNoIG9uIGdpdGh1YiBhbmQgYSBsaW5r IG9uIHRoaXMgZW1haWwgdGhyZWFkPw0KPiANCj4gTWF5YmUgd2Ugc2hvdWxkIGhhdmUgYSB3aWtp cGFnZSBvbiB3aWtpLnhlbnByb2plY3Qub3JnIGFib3V0DQo+IHdvcmstaW4tcHJvZ3Jlc3MgdWJv b3QgaXRlbXMuDQo+IA0KPiANCj4gDQo+IA0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IFBlbmcuDQo+ ID4gPg0KPiA+ID4+IEhpIQ0KPiA+ID4+DQo+ID4gPj4gd2l0aCBhIGxvdCBvZiBoZWxwIGZyb20g U3RlZmFubywgd2UncmUgZ2V0dGluZyBSUGk0IHN1cHBvcnQgaW4NCj4gPiA+PiBQcm9qZWN0IEVW RSBwcmV0dHkgbXVjaCBvbiBwYXIgYmV0d2VlbiBLVk0gYW5kIFhlbi4NCj4gPiA+Pg0KPiA+ID4+ IE9uZSBiaWcgYXJlYSB0aGF0IHN0aWxsIHJlbWFpbnMgaXMgc3VwcG9ydGluZyBVRUZJIGJvb3Qg c2VxdWVuY2UgZm9yDQo+IERvbVVzLg0KPiA+ID4+IFdpdGggS1ZNLCBnaXZlbiB0aGUgcWVtdSB2 aXJ0IGRldmljZSBtb2RlbCB0aGlzIGlzIGFzIHNpbXBsZSBhcw0KPiA+ID4+IHVzaW5nIGVpdGhl ciBzdG9jayBVRUZJIGJ1aWxkIGZvciBhcm0gb3IgZXZlbiBVLUJvb3QgRUZJIGVtdWxhdGlvbg0K PiA+ID4+IGVudmlyb25tZW50IGFuZCBwYXNzaW5nIGl0IHZpYSAtYmlvcyBvcHRpb24uDQo+ID4g Pj4NCj4gPiA+PiBPYnZpb3VzbHkgd2l0aCBYZW4gb24gQVJNIHdlIGRvbid0IGhhdmUgdGhlIGRl dmljZSBtb2RlbCBzbyBteQ0KPiA+ID4+IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgZWFzaWVz dCB3YXkgd2UgY2FuIHN1cHBvcnQgaXQgd291bGQgYmUgdG8NCj4gPiA+PiBwb3J0IFVFRkkncyBP dm1mUGtnL092bWZYZW4gdGFyZ2V0IHRvIEFSTSAoaXQgc2VlbXMgdG8gYmUgY3VycmVudGx5DQo+ ID4gPj4gZXhjbHVzaXZlbHkgWDY0KS4NCj4gPiA+Pg0KPiA+ID4+IFNvIGhlcmUncyBteSBmaXJz dCBxdWVzdGlvbjogaWYgdGhlcmUncyBhbnlib2R5IG9uIHRoaXMgbGlzdCB3aG8NCj4gPiA+PiBo YWQgYSBoYW5kIGluIGltcGxlbWVudGluZyBPdm1mUGtnL092bWZYZW4gY2FuIHlvdSBwbGVhc2Ug c2hhcmUNCj4gPiA+PiB5b3VyIHRob3VnaHRzIG9uIGhvdyBtdWNoIHdvcmsgdGhhdCBwb3J0IG1h eSBiZSAob3Igd2hldGhlciBpdCBpcw0KPiA+ID4+IGV2ZW4gZmVhc2libGUgLS0gSSBtYXkgdG90 YWxseSBiZSBtaXNzaW5nIHNvbWV0aGluZyByZWFsbHkgb2J2aW91cyBoZXJlKS4NCj4gPiA+Pg0K PiA+ID4+IEFuZCBhcyBsb25nIGFzIEkndmUgZ290IHlvdXIgYXR0ZW50aW9uOiB0d28gbW9yZSBx dWVzdGlvbnM6DQo+ID4gPj4gICAgIDEuLiBjb21wYXJlZCB0byB0aGUgYWJvdmUsIHdvdWxkIHBv cnRpbmcgcHZncnViIHRvIEFSTSBiZSBhbnkNCj4gPiA+PiAgICAgZWFzaWVyIG9yIG1vcmUgZGlm ZmljdWx0Pw0KPiA+ID4+DQo+ID4gPj4gICAgIDIuIHNhbWUgcXVlc3Rpb24gZm9yIHRlYWNoaW5n IHUtYm9vdCBhYm91dCBQViBjYWxscy4NCj4gPiA+Pg0KPiA+ID4+IFRoYW5rcywNCj4gPiA+PiBS b21hbi4NCj4gPiA+Pg0KPiA+ID4+IFAuUy4gT2ggYW5kIEkgZ3Vlc3MgYmV0d2VlbjoNCj4gPiA+ PiAgICAgMC4gT3ZtZlBrZy9Pdm1mWGVuIG9uIEFSTTY0DQo+ID4gPj4gICAgIDEuIHB2Z3J1YiBv biBBUk02NA0KPiA+ID4+ICAgICAyLiB1LWJvb3QvRUZJIGVtdWxhdGlvbiB3aXRoIFBWIGNhbGxz IGJhY2tlbmQgSSBkaWRuJ3QgbWlzcyBhbnkNCj4gPiA+PiBvdGhlciBvYnZpb3VzIHdheSBvZiBt YWtpbmcgVUVGSS1hd2FyZSBWTSBpbWFnZXMgdG8gYm9vdCBvbiBYZW4NCj4gPiA+PiBBUk02NCBE b21VLCByaWdodD8NCg== From xen-devel-bounces@lists.xenproject.org Mon Jun 15 02:07:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 02:07:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkeWz-0004BH-IB; Mon, 15 Jun 2020 02:07:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkeWx-0004BC-U7 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 02:07:23 +0000 X-Inumbo-ID: f321261e-aeac-11ea-b7bb-bc764e2007e4 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (unknown [40.107.5.54]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f321261e-aeac-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 02:07:23 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eE2fSnfU0rqQevo9IDw/E3S8uo9e9dW/Tag+QaJALvNE9CGewuzLarajSGjvaCuU21WHnF33cioOJf2Uk0PuQ0MxfmX8c5u5WkwEP+JPZ2b8e9gKvxaKsy2CSZ+milv+zWV/9qA8tzHMqIOYRtjk+pECvBfsa+PIVa3X5NNfoWCIzMzzARZDXIqnmVYB4EtATkSmV3wFMbWY7EBYHaWvot4g98FncxcZNW5STw8BAwDJJaag1eSXNRXCBAoA+FAeUoayfILYQsN5sY8l/IhZaSglBb4dngCWJXUtZe7fPJ/QF+pxdjLA6oFWOjMSzNGQ9m26n42SPCjc2q9JbndSMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lQQp9vYsqvwtbedk7b/0d9QHMLwJKtyURWXUHGrQSEI=; b=awXD6sW4kazUHdZZM39sDIxW0CFBfK6v+JPb5QKbPenrJmD7rLRXXOavNz7PC+x+Hzr9UIk4LrLYOGxR6QEcwLtt0Gxz1SS31N1TJQBmCcHSj9o/vM8fmA5MYKIpX9hiA4ZvPcKdhGPM9vQrxIsIhB9i1HzXeaTqeI46GT15tgcbbVPGUlTSWZ3xntw4DLLXckZYio0sybBp1iCh4f2g1agcIUr+kSb2nqs2rTAkON4IKHweRRJdhIDzHXN7O7Ga2ytqhitvporQ2j/vsgmz3WGsLKf+d74Q7ZTJzpPbDzboVop3AhoRwQPQj7MksR/AYVGwk/7XNto9BeoF09tBDA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lQQp9vYsqvwtbedk7b/0d9QHMLwJKtyURWXUHGrQSEI=; b=G+poceodYg0pUlck3XnioHtUkojr2/8xhtIVdxA3grftSbsq4GOlzYaGqAVNBs0dQP6SHhgJuor/yI6qkW9VW/n6rnYClZX4pxzqHGALvTxjevLHgAK0VX+hN7Wy00m9JyzLw4nPjH4zcHrB2esHJQZZQqhmDYOrlHj8zSZ+iv8= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2871.eurprd04.prod.outlook.com (2603:10a6:4:99::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.25; Mon, 15 Jun 2020 02:07:21 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3088.028; Mon, 15 Jun 2020 02:07:21 +0000 From: Peng Fan To: Xen-devel , Jens Wiklander , Oleksandr Andrushchenko , "tee-dev@lists.linaro.org" , Stefano Babic , Julien Grall Subject: TEE with XEN Thread-Topic: TEE with XEN Thread-Index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQ== Date: Mon, 15 Jun 2020 02:07:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b4403eaa-4e49-4289-4228-08d810d0d696 x-ms-traffictypediagnostic: DB6PR0402MB2871: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ioH7c2cbuWIse7s5vXjNI0emsjpFsqiDKdDdc3jC0k3fydMCZtXN32j7XjEsn+WoIxYYMk8lBuXPX3C8uF/e5vbe2TqVPV7aTmJC9bHz1e/j4EcJF64ydb/AthmYB2//atil1P+vnG33JdYllJ92rOx9zvoAi3ATh+qdQtWjRRKr/0arQeglK08qubMWFEfu7tugiBx9H2dsjf3lLM9zx8aHBdAR3wlum6oXsLrTKpROrGxMwDpbUgpUedSPM/gK124bVZjEHTaf8UYA7cRq5v1DNijneUu6O7GcW0o5PmKqbWbpJ6rvtfzExrKqYCliDyExKjlrIjllIHFbOqJRyA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(396003)(366004)(346002)(376002)(6506007)(44832011)(186003)(8936002)(71200400001)(4744005)(2906002)(478600001)(26005)(9686003)(3480700007)(55016002)(7116003)(66946007)(64756008)(66556008)(66476007)(66446008)(316002)(33656002)(110136005)(5660300002)(52536014)(8676002)(7696005)(76116006)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2yIjDeg7vsinaFVsH7c3B0J2NH6gRAQpG77xrOBULJC993xl4mc6uM+ISNBvNrrde8/UF2ESuE8gWlqsSjNDJ93tj5OsMDNOMHa5ljdWff0BG8ATcYkXE2ilvyletmqQ8EaXK8Ef44vWBg9nQzNj9r2apQnqGL0+7WxUHdeKd6ZQJ1rcObHaSmOZcyLaNyg/Km0W/ONjjl5TSkZjLiat1r9Ox6we0p0yDIQuKxTPZqnIFGFGB3K1qQP7RflatH1TJhU6ZdLsUkw7twJSBvdnJtBecwauC44+sfZkVybCOsRJpYrZw1qjdICcu5a4Vky5FI9kwQV4RMSBmiNvqztx/EZMLuLnXhUoVpwEkla1jluEptV2yuIrBuCIN1+XPsIpczNtjOzBjeCcQ7c8pezQhHZirdZ53uP6ZxXHcchEa9jiaGC9cLvObY7CaWFNsjnlDVmQm+jdmGAPyfcxulMxpuGFoj0YYsIDl8j6gdkzUN0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: b4403eaa-4e49-4289-4228-08d810d0d696 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 02:07:21.0919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TcPJUo387310E6AfTAwgScEj48ssmBLJxmhdc9Tjy5VFF3Q7t0l94fB6zlpFnbRyhyB/IA2VgpSlweCXOi3tiQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2871 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi All, While enabling trusty os with xen, I took same approach as OP-TEE,=20 with OP-TEE running in secure world. But I am also thinking this might introduce potential issue is that secure world OS communicate with DomU. If there are some misbehavior in secure world OS, it might let XEN hypervisor not work proper. In my setup, trusty os sometimes panic in secure world, xen will not able to control the panic core anymore. So I am thinking whether we need to emulating secure world in a XEN VM which is the VM running DomU. Just like what ACRN did to run trusty os. Any comments? Thanks, Peng. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 03:30:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 03:30:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkfpJ-0003Eo-IR; Mon, 15 Jun 2020 03:30:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkfpH-0003E5-Rj for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 03:30:23 +0000 X-Inumbo-ID: 87a82be2-aeb8-11ea-b7b3-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 87a82be2-aeb8-11ea-b7b3-12813bfff9fa; Mon, 15 Jun 2020 03:30:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7h5bok6Rsz5HrMajUk87U2CjzZdWI0awuanh23CRYK4=; b=6TK1x2gMWv2U3GXnuwUhWehLl kYNNktSQpKXE2qjE4wIlK95wrRHW7DsVRdCg2YtqVXPOMb+2M42fEpoJsFca4o11hZD7pHet9e9SO GCCb00ovxc1Z15OQ15b5tI/luGXXd/TaxIEwxmZhsLKsEzUahU2Nz6Y5L+NGXX/McqRns=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkfp9-0005fE-IN; Mon, 15 Jun 2020 03:30:15 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkfp9-0002MM-4h; Mon, 15 Jun 2020 03:30:15 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkfp9-000654-3T; Mon, 15 Jun 2020 03:30:15 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 151096: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-arm64-libvirt:libvirt-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-armhf-libvirt:libvirt-build:fail:regression xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:guest-start:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=6e477c2ea4d5c26a7a7b2f850166aa79edc5225c X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Mon, 15 Jun 2020 03:30:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151096 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151096/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-amd64-amd64-livepatch 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 12 guest-start fail like 150120 test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 36 days Failing since 150940 2020-06-09 17:05:20 Z 5 days 8 attempts Testing same since 151070 2020-06-13 06:57:26 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Ian Jackson John Thomson Julien Grall Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm pass build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 pass build-armhf pass build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c Author: Wei Liu Date: Mon Jun 12 16:04:17 2017 +0100 ipxe: update to newer commit To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7. The only patch we have applies cleanly. Reported-by: Zhongze Liu Signed-off-by: Wei Liu Acked-by: Ian Jackson (cherry picked from commit 461b2165346de236fff2d00d1c318062f1daab08) commit 6a1c431890599c701117bf9822898f60a18444a3 Author: John Thomson Date: Tue May 15 11:48:43 2018 +1000 tools/ocaml/libs/xc fix gcc-8 format-truncation warning CC xenctrl_stubs.o xenctrl_stubs.c: In function 'failwith_xc': xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "%d: %s: %s", error->code, ^ xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028 snprintf(error_str, sizeof(error_str), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%d: %s: %s", error->code, ~~~~~~~~~~~~~~~~~~~~~~~~~~ xc_error_code_to_desc(error->code), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error->message); ~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1 m Signed-off-by: John Thomson Acked-by: Christian Lindig Release-acked-by: Juergen Gross (cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795) commit 41f597f5167c2e78a3c70d219710c8805d7fec8e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:50 2018 +0200 tools/misc: fix hypothetical buffer overflow in xen-lowmemd gcc-8 complains: xen-lowmemd.c: In function 'handle_low_mem': xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=] snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~ ~~~~ xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In practice it wouldn't happen, because 'data' contains string representation of 64-bit unsigned number (20 characters at most). But place a limit to mute gcc warning. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080) commit 1eae17268887bacbc598ef6e3290059dbeb4fd8f Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:52 2018 +0200 tools/blktap2: fix possible '\0' truncation gcc-8 complains: tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring': tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^ tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255 snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "- 1" in buffer size should be actually applied to message, to leave place for terminating '\0', not the other way around (truncate '\0' even if it would fit). In function 'tapdisk_control_open_image', inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10: tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'tapdisk_control_create_socket', inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9: tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block-qcow.c: In function 'qcow_create': block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(backing_filename, backing_file, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(backing_filename)); ~~~~~~~~~~~~~~~~~~~~~~~~~ I those cases, reduce size of copied string and make sure final '\0' is added. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a) commit f1e75e5c7054d8cd7bdfe30c6a95af35cc24fbb2 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:54 2018 +0200 tools/gdbsx: fix -Wstringop-truncation warning gcc-8 complains: gx_main.c: In function 'prepare_stop_reply': gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(buf, "watch:", 6); ^~~~~~~~~~~~~~~~~~~~~~~~~ Since terminating '\0' isn't needed here at all, switch to memcpy. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f) commit f034ab45c15aef9c784dbcdc5c893e268d4a094c Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:53 2018 +0200 tools/xenpmd: fix possible '\0' truncation gcc-8 complains: xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->oem_info, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->battery_type, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->serial_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->model_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy 31 chars, then make sure terminating '\0' is present. Those fields are passed to strlen and as '%s' for snprintf later. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b) commit 9737f89b076ae4d05e6f974a7c21aced4459966e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:49 2018 +0200 tools/libxc: fix strncpy size gcc-8 warns about possible truncation of trailing '\0'. Final character is overridden by '\0' anyway, so don't bother to copy it. This fixes compile failure: xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159) commit 1dd64783024c5c9e600c3d33393b795c68a46f65 Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit 80d78acf9e60ae6a88d6cb6f3535eaf67c81f61c Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. Extend libxl's table of named parameters to include RDRAND/RDSEED, and have the compiler construct it in .rodata, rather than on the stack at runtime each time it is called. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Jun 15 05:21:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 05:21:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkhYs-00043z-0I; Mon, 15 Jun 2020 05:21:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkhYq-00043u-NR for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 05:21:33 +0000 X-Inumbo-ID: 12cdcb96-aec8-11ea-b7b9-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.61]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 12cdcb96-aec8-11ea-b7b9-12813bfff9fa; Mon, 15 Jun 2020 05:21:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592198491; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TOLcTSyAqQQu+LEbnmAy815PLwjKRhXBvQKM61rDIfM=; b=SxpYU3Ow8JIDCMga+cxrNlWGKBxEE3mGI9LKoJ12gpRlQM/WkK3qOuk+aSlaYEvBP5emms k1xf3gxn6C4TBnwvh9l+OQXysPakNc8ZQl50q5z8F24s8FdBgcsX5ox65iQbbpjAKn5x5P L3zrp3XlRs7ib8Cw0cnRdXvgCsLDllg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-172-bpTLcet6MtSykvWU2_4eNQ-1; Mon, 15 Jun 2020 01:21:19 -0400 X-MC-Unique: bpTLcet6MtSykvWU2_4eNQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0E57C80B73B; Mon, 15 Jun 2020 05:21:18 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-112-121.ams2.redhat.com [10.36.112.121]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 550477B91C; Mon, 15 Jun 2020 05:21:05 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id C745D1138648; Mon, 15 Jun 2020 07:21:03 +0200 (CEST) From: Markus Armbruster To: Greg Kurz Subject: Re: [PATCH v10 1/9] error: auto propagated local_err References: <20200317151625.20797-1-vsementsov@virtuozzo.com> <20200317151625.20797-2-vsementsov@virtuozzo.com> <20200610163921.28d824aa@bahia.lan> Date: Mon, 15 Jun 2020 07:21:03 +0200 In-Reply-To: <20200610163921.28d824aa@bahia.lan> (Greg Kurz's message of "Wed, 10 Jun 2020 16:39:21 +0200") Message-ID: <877dw8dhvk.fsf@dusky.pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Vladimir Sementsov-Ogievskiy , Michael Roth , qemu-block@nongnu.org, Paul Durrant , Philippe =?utf-8?Q?Mathieu-Daud?= =?utf-8?Q?=C3=A9?= , Christian Schoenebeck , armbru@redhat.com, qemu-devel@nongnu.org, Stefano Stabellini , Gerd Hoffmann , Stefan Hajnoczi , Anthony Perard , xen-devel@lists.xenproject.org, Max Reitz , Laszlo Ersek , Stefan Berger Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Greg Kurz writes: > On Tue, 17 Mar 2020 18:16:17 +0300 > Vladimir Sementsov-Ogievskiy wrote: > >> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of >> functions with an errp OUT parameter. >> >> It has three goals: >> >> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user >> can't see this additional information, because exit() happens in >> error_setg earlier than information is added. [Reported by Greg Kurz] >> > > I have more of these coming and I'd really like to use ERRP_AUTO_PROPAGATE. > > It seems we have a consensus on the macro itself but this series is gated > by the conversion of the existing code base. > > What about merging this patch separately so that people can start using > it at least ? Please give me a few more days to finish the work I feel should go in before the conversion. With any luck, Vladimir can then rebase / recreate the conversion easily, and you can finally use the macro for your own work. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 06:10:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 06:10:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkiKH-000886-0k; Mon, 15 Jun 2020 06:10:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkiKG-000881-4z for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 06:10:32 +0000 X-Inumbo-ID: eab6973a-aece-11ea-8496-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id eab6973a-aece-11ea-8496-bc764e2007e4; Mon, 15 Jun 2020 06:10:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592201431; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=v0ZBhyHuoiYyIG2YYqP1P0uyVeNRSfn/RhvYQHNps+U=; b=HR6d5Y+q1w//srC9pRimcOPORa7wRTn9MnMviPyx2d4YBD22o7CCLNQlu7jMxOxS+IWnqU yqPT7HrZroXfV2oMLsMWFtgBQTWMj+CNQo1y7tbW9M/1pevlbzdqr/soEDOKCshWaJNcHR ApXNYgrG50azP9BI+N2x3n1tYw/Vuwg= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-11-qMlZqkgFPYemA-KQkjQUVg-1; Mon, 15 Jun 2020 02:10:27 -0400 X-MC-Unique: qMlZqkgFPYemA-KQkjQUVg-1 Received: by mail-wm1-f70.google.com with SMTP id t145so6246973wmt.2 for ; Sun, 14 Jun 2020 23:10:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=v0ZBhyHuoiYyIG2YYqP1P0uyVeNRSfn/RhvYQHNps+U=; b=aA0tL2yhPgxT3ac23ZtUUaVPsuU5Sg7d2zMgPBEvQYJaghSpimlvAFME76ABqJaodz P7w1wrXmm6DXcDXip4TfsEd/E10K6hOZExvxvw3WbD0CHJJBGgIrcxVVPwDMvuuBilq/ v8FXCfIsr36fxM8pMZ41Z05NutKAtXziiD47IvdmCyIsp54ktxBFaTsQfKqw9S6ATmfV cgP+euFL2UvZWINvsOMS7f2nzJ3EZJIy1ZxDuUB5Jd4U+nUaQdO7eYXath7pEUFXsAi2 lDuE02RiNpo7kmSlsOHnsCzlrY3LG1BetRU+aw6uB6OQOCN8d3LvYiOgxpLb0w9BWgZE w2nQ== X-Gm-Message-State: AOAM5309nQLHKTJ6giGYJbNYY64Dz199Sln4fzoHKELkshsSYPXnGzfC liJ95zZWZmNrjrLZ2BWwLjQUus91Rr2yTSvvZrS2ntpMMDZmKusC6YeEC6uFjWv4BxROBGpKT2/ KxOAgPUarrSof+O55wIeF3AuMgV8= X-Received: by 2002:a05:6000:11cd:: with SMTP id i13mr25875575wrx.141.1592201426757; Sun, 14 Jun 2020 23:10:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZ2Uwva95g66+gjqRckuSUADgj2I6e2bVoFdTcJbxlN75hZn1xWlAEG9LV2gFxHDZZU3txZw== X-Received: by 2002:a05:6000:11cd:: with SMTP id i13mr25875553wrx.141.1592201426585; Sun, 14 Jun 2020 23:10:26 -0700 (PDT) Received: from [192.168.1.40] (181.red-88-10-103.dynamicip.rima-tde.net. [88.10.103.181]) by smtp.gmail.com with ESMTPSA id 88sm24672875wre.45.2020.06.14.23.10.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Jun 2020 23:10:26 -0700 (PDT) Subject: Re: [PATCH] hw/xen_pt: Don't grant opregion permissions To: Grzegorz Uriasz , qemu-devel@nongnu.org References: <2157e10d63619d43151fe8b8ca913b44c54aba6e.1592176600.git.gorbak25@gmail.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: Date: Mon, 15 Jun 2020 08:10:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <2157e10d63619d43151fe8b8ca913b44c54aba6e.1592176600.git.gorbak25@gmail.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , jakub@bartmin.ski, marmarek@invisiblethingslab.com, Anthony Perard , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Grzegorz, On 6/15/20 1:21 AM, Grzegorz Uriasz wrote: > With the upstreaming of linux based stubdomains to xen, qemu can't > assume it runs inside dom0 - permission assignment must be moved to > libxl running in dom0. This xen patch: > https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00973.html > implements granting the required permissions to the stubdomain running > qemu. This patch removes granting opregion permissions in qemu - this > should be fine as when qemu is running inside dom0 the memory mapping will > be successfully created without first explicitly granting the permission. > > Signed-off-by: Grzegorz Uriasz > --- > hw/xen/xen_pt_graphics.c | 13 ------------- > 1 file changed, 13 deletions(-) > > diff --git a/hw/xen/xen_pt_graphics.c b/hw/xen/xen_pt_graphics.c > index 7d46e9c209..303674365b 100644 > --- a/hw/xen/xen_pt_graphics.c > +++ b/hw/xen/xen_pt_graphics.c > @@ -283,19 +283,6 @@ void igd_write_opregion(XenPCIPassthroughState *s, uint32_t val) > igd_guest_opregion = (unsigned long)(val & ~XEN_PCI_INTEL_OPREGION_MASK) > | (igd_host_opregion & XEN_PCI_INTEL_OPREGION_MASK); > > - ret = xc_domain_iomem_permission(xen_xc, xen_domid, > - (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), > - XEN_PCI_INTEL_OPREGION_PAGES, > - XEN_PCI_INTEL_OPREGION_ENABLE_ACCESSED); > - > - if (ret) { > - XEN_PT_ERR(&s->dev, "[%d]:Can't enable to access IGD host opregion:" > - " 0x%lx.\n", ret, > - (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT)), > - igd_guest_opregion = 0; > - return; > - } Shouldn't this be somehow versioned? I.e. if the libxl does not have the change then keep the current code? > - > ret = xc_domain_memory_mapping(xen_xc, xen_domid, > (unsigned long)(igd_guest_opregion >> XC_PAGE_SHIFT), > (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), > From xen-devel-bounces@lists.xenproject.org Mon Jun 15 06:39:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 06:39:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkilm-0001VE-DI; Mon, 15 Jun 2020 06:38:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkill-0001V8-1S for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 06:38:57 +0000 X-Inumbo-ID: e26584ac-aed2-11ea-bb8b-bc764e2007e4 Received: from 6.mo179.mail-out.ovh.net (unknown [46.105.56.76]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e26584ac-aed2-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 06:38:55 +0000 (UTC) Received: from player789.ha.ovh.net (unknown [10.110.103.168]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id AED6B16F830 for ; Mon, 15 Jun 2020 08:38:54 +0200 (CEST) Received: from kaod.org (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player789.ha.ovh.net (Postfix) with ESMTPSA id 4707A136379BC; Mon, 15 Jun 2020 06:38:36 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-98R0023cd0aa35-8cad-4a04-9371-86d222787d89,F1BB0E26B38E3581C3F8E07DA172D6E56B46BED4) smtp.auth=groug@kaod.org Date: Mon, 15 Jun 2020 08:38:35 +0200 From: Greg Kurz To: Markus Armbruster Subject: Re: [PATCH v10 1/9] error: auto propagated local_err Message-ID: <20200615083835.54e3fcb1@bahia.lan> In-Reply-To: <877dw8dhvk.fsf@dusky.pond.sub.org> References: <20200317151625.20797-1-vsementsov@virtuozzo.com> <20200317151625.20797-2-vsementsov@virtuozzo.com> <20200610163921.28d824aa@bahia.lan> <877dw8dhvk.fsf@dusky.pond.sub.org> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 1692509037167942030 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeijedgudduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkjghfofggtgfgsehtjeertdertddvnecuhfhrohhmpefirhgvghcumfhurhiiuceoghhrohhugheskhgrohgurdhorhhgqeenucggtffrrghtthgvrhhnpeehkefhtdehgeehheejledufeekhfdvleefvdeihefhkefhudffhfeuuedvffdthfenucfkpheptddrtddrtddrtddpkedvrddvheefrddvtdekrddvgeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeekledrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehgrhhouhhgsehkrghougdrohhrghdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Vladimir Sementsov-Ogievskiy , Michael Roth , qemu-block@nongnu.org, Paul Durrant , Philippe =?UTF-8?B?TWF0aGlldS1EYXVkw6k=?= , Christian Schoenebeck , qemu-devel@nongnu.org, Max Reitz , Stefano Stabellini , Gerd Hoffmann , Stefan Hajnoczi , Anthony Perard , xen-devel@lists.xenproject.org, Laszlo Ersek , Stefan Berger Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 15 Jun 2020 07:21:03 +0200 Markus Armbruster wrote: > Greg Kurz writes: > > > On Tue, 17 Mar 2020 18:16:17 +0300 > > Vladimir Sementsov-Ogievskiy wrote: > > > >> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of > >> functions with an errp OUT parameter. > >> > >> It has three goals: > >> > >> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user > >> can't see this additional information, because exit() happens in > >> error_setg earlier than information is added. [Reported by Greg Kurz] > >> > > > > I have more of these coming and I'd really like to use ERRP_AUTO_PROPAGATE. > > > > It seems we have a consensus on the macro itself but this series is gated > > by the conversion of the existing code base. > > > > What about merging this patch separately so that people can start using > > it at least ? > > Please give me a few more days to finish the work I feel should go in > before the conversion. With any luck, Vladimir can then rebase / > recreate the conversion easily, and you can finally use the macro for > your own work. > Sure. Thanks. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 07:06:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 07:06:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkjBz-0003wy-Lw; Mon, 15 Jun 2020 07:06:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkjBy-0003wt-Nv for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 07:06:02 +0000 X-Inumbo-ID: aadc3fcc-aed6-11ea-b7c5-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id aadc3fcc-aed6-11ea-b7c5-12813bfff9fa; Mon, 15 Jun 2020 07:06:00 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 0WTN05Vi8M7oqOf5ArlUqW6cmr8syDAfoJDQqIWPIVHkjdE+tFQ1Gr/hyliRwcvcCAWlMwDtlG DlPFbTm5CDdeChWpSWIoQlYETY5GZkYEa8wWq9StiOc5UgKnM9xJ5y0PzN0JoUjEyDz8cbe7Hk LdOK5t4fhtKTW7yuCIK7K7OqIytjp1NGvgDfAzWdPH8HL6aeHsxuFeQC4u85oLOVb1tVo9YPr7 a2Tc0mPt2hQtNQ3I1O7O2nm0gBzd1ikzmWGZSK4qMR4b5GpCMxtJ3uabkJuGi+IWFDp+hJ6ZXz 0DU= X-SBRS: 2.7 X-MesageID: 20374503 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20374503" Date: Mon, 15 Jun 2020 09:05:49 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Grzegorz Uriasz Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Message-ID: <20200615070549.GA735@Air-de-Roger> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Jan Beulich , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sun, Jun 14, 2020 at 02:36:28PM +0000, Grzegorz Uriasz wrote: > On some computers the bit width of the PM Timer as reported > by ACPI is 32 bits when in fact the FADT flags report correctly > that the timer is 24 bits wide. On affected machines such as the > ASUS FX504GM and never gaming laptops this results in the inability > to resume the machine from suspend. Without this patch suspend is > broken on affected machines and even if a machine manages to resume > correctly then the kernel time and xen timers are trashed. > > Signed-off-by: Grzegorz Uriasz > Tested-by: Grzegorz Uriasz Thanks for the patch! I'm not sure it's required to add your Tested-by, I usually assume a patch has been tested by it's author unless told otherwise. > --- > xen/arch/x86/acpi/boot.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c > index bcba52e232..2ad3eb4abc 100644 > --- a/xen/arch/x86/acpi/boot.c > +++ b/xen/arch/x86/acpi/boot.c > @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > if (fadt->xpm_timer_block.space_id == > ACPI_ADR_SPACE_SYSTEM_IO) { > pmtmr_ioport = fadt->xpm_timer_block.address; > - pmtmr_width = fadt->xpm_timer_block.bit_width; > + if (fadt->flags & ACPI_FADT_32BIT_TIMER) > + pmtmr_width = 32; > + else > + pmtmr_width = 24; I think there's also a block below that you need to fix, when xpm_timer_block is not set the data is fetched from pm_timer_block instead, which AFAICT also needs to take ACPI_FADT_32BIT_TIMER into account in order to use the correct size. FWIW, I would set pmtmr_width only once after pmtmr_ioport has been set, since regardless of whether the port is discovered using xpm_timer_block or pm_timer_block the size will always be derived from the flags field. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 08:26:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 08:26:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkkRY-0002dj-Fr; Mon, 15 Jun 2020 08:26:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkkRX-0002de-7M for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 08:26:11 +0000 X-Inumbo-ID: dd7b138a-aee1-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dd7b138a-aee1-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 08:26:10 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id l11so16122841wru.0 for ; Mon, 15 Jun 2020 01:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=cqhzZxtqAsRRO3BzrlM6m9t/GkiBo/7EUSd/KzYdIbk=; b=MYpR7KNtizfDZo2iLVlKeXyFEvnN82kDlPWv+7SgEli37rq4gCv6oTD2jy4WL0TDYw SwQInUzLgI5iatZ/piryiorwntk0U2BQ19ySNBzmExnJ/ap5uCDvZTaKefsqXE+1CqW/ smoco1uVE+7qJ25cDlwwRQxV/7lXA7CUuqUG/kXfD/QJlmidGyU4w6oB+e7a8/h2OaGa NOViInN+a7zLYrFI9PQq9N/IlHoerWs7Nvtabj8cpoPq1jXzYND5WDJtjbTlNnGkNqOO gRNvzysniMTHC8ovoRNmeCaMNaHBPh/ON3Wah9XtFlakjq3VdlnhWPBn4YqA/BiptYAb 51yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=cqhzZxtqAsRRO3BzrlM6m9t/GkiBo/7EUSd/KzYdIbk=; b=ZUiZfmGsDpreMnZdJOP4zj0OxKumcUGRbDFu7okWqH5uXFRLp8yH0D/HIlHVp+Mghg a6YXxFiZlN3mqiAInHEJgy1JKRErbwyJwiohrFZhpPRJHYgu1glimvoHltUnXbcvF6LT 1jsaWXT7GwlCGcluWy2CtZXETjQZajLaa18RZZgoybb5Ith1WnQ4mIOBANABTAlUs+b1 +HMHLE5QT3xBrLF7oqe0OThJD9M6bPBPu9vTftlExZizw7sdamjKPbTzTAd0CCPjIdGj wrY+JRXn0PoebfoMxwbGS0jWpPNx/y6vMpNqrfo8NB31wKMiZBUGZRxm2unNhbeq/8vm EoPA== X-Gm-Message-State: AOAM530BdxsjHg3zB18sivDDcRu6OZmh1GDSQr6xOG4xkvrr6Oh6YUJG 6u4XJHGQsgkGSQVgujztNak= X-Google-Smtp-Source: ABdhPJxIO5NxtMYxrMLj02HiqnOMDm6/U4pOCMdhgOWYaNt1Js549ycX2ty/Oa7pDhAJPXEcBuLNHw== X-Received: by 2002:a05:6000:1184:: with SMTP id g4mr26351447wrx.46.1592209568984; Mon, 15 Jun 2020 01:26:08 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id r2sm23941985wrg.68.2020.06.15.01.26.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 01:26:08 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Julien Grall'" , References: <20200613184132.11880-1-julien@xen.org> In-Reply-To: <20200613184132.11880-1-julien@xen.org> Subject: RE: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches Date: Mon, 15 Jun 2020 09:26:06 +0100 Message-ID: <002301d642ee$9e86c390$db944ab0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIdN0zh64cmcx6NK7tx64iRcBxsdKhLbmMQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Juergen Gross' , 'Stefano Stabellini' , 'Wei Liu' , 'Andrew Cooper' , 'Julien Grall' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Julien Grall > Sent: 13 June 2020 19:42 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Julien Grall ; Andrew Cooper ; George > Dunlap ; Ian Jackson ; Jan Beulich > ; Julien Grall ; Stefano Stabellini ; Wei > Liu ; Juergen Gross > Subject: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches > > From: Julien Grall > > The documentation of pvcalls suggests there is padding for 32-bit x86 > at the end of most the structure. However, they are not described in > in the public header. > > Because of that all the structures would be 32-bit aligned and not > 64-bit aligned for 32-bit x86. > > For all the other architectures supported (Arm and 64-bit x86), the > structure are aligned to 64-bit because they contain uint64_t field. > Therefore all the structures contain implicit padding. > > The paddings are now corrected for 32-bit x86 and written explicitly for > all the architectures. > > While the structure size between 32-bit and 64-bit x86 is different, it > shouldn't cause any incompatibility between a 32-bit and 64-bit > frontend/backend because the commands are always 56 bits and the padding > are at the end of the structure. > > As an aside, the padding sadly cannot be mandated to be 0 as they are > already present. So it is not going to be possible to use the padding > for extending a command in the future. Ugh. > > Signed-off-by: Julien Grall Release-acked-by: Paul Durrant > > --- > Changes in v3: > - Use __i386__ rather than CONFIG_X86_32 > > Changes in v2: > - It is not possible to use the same padding for 32-bit x86 and > all the other supported architectures. > --- > docs/misc/pvcalls.pandoc | 18 ++++++++++-------- > xen/include/public/io/pvcalls.h | 14 ++++++++++++++ > 2 files changed, 24 insertions(+), 8 deletions(-) > > diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc > index 665dad556c39..caa71b36d78b 100644 > --- a/docs/misc/pvcalls.pandoc > +++ b/docs/misc/pvcalls.pandoc > @@ -246,9 +246,9 @@ The format is defined as follows: > uint32_t domain; > uint32_t type; > uint32_t protocol; > - #ifdef CONFIG_X86_32 > + #ifndef __i386__ > uint8_t pad[4]; > - #endif > + #endif > } socket; > struct xen_pvcalls_connect { > uint64_t id; > @@ -257,16 +257,18 @@ The format is defined as follows: > uint32_t flags; > grant_ref_t ref; > uint32_t evtchn; > - #ifdef CONFIG_X86_32 > + #ifndef __i386__ > uint8_t pad[4]; > - #endif > + #endif > } connect; > struct xen_pvcalls_release { > uint64_t id; > uint8_t reuse; > - #ifdef CONFIG_X86_32 > + #ifndef __i386__ > uint8_t pad[7]; > - #endif > + #else > + uint8_t pad[3]; > + #endif > } release; > struct xen_pvcalls_bind { > uint64_t id; > @@ -276,9 +278,9 @@ The format is defined as follows: > struct xen_pvcalls_listen { > uint64_t id; > uint32_t backlog; > - #ifdef CONFIG_X86_32 > + #ifndef __i386__ > uint8_t pad[4]; > - #endif > + #endif > } listen; > struct xen_pvcalls_accept { > uint64_t id; > diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h > index cb8171275c13..28374a82f410 100644 > --- a/xen/include/public/io/pvcalls.h > +++ b/xen/include/public/io/pvcalls.h > @@ -65,6 +65,9 @@ struct xen_pvcalls_request { > uint32_t domain; > uint32_t type; > uint32_t protocol; > +#ifndef __i386__ > + uint8_t pad[4]; > +#endif > } socket; > struct xen_pvcalls_connect { > uint64_t id; > @@ -73,10 +76,18 @@ struct xen_pvcalls_request { > uint32_t flags; > grant_ref_t ref; > uint32_t evtchn; > +#ifndef __i386__ > + uint8_t pad[4]; > +#endif > } connect; > struct xen_pvcalls_release { > uint64_t id; > uint8_t reuse; > +#ifndef __i386__ > + uint8_t pad[7]; > +#else > + uint8_t pad[3]; > +#endif > } release; > struct xen_pvcalls_bind { > uint64_t id; > @@ -86,6 +97,9 @@ struct xen_pvcalls_request { > struct xen_pvcalls_listen { > uint64_t id; > uint32_t backlog; > +#ifndef __i386__ > + uint8_t pad[4]; > +#endif > } listen; > struct xen_pvcalls_accept { > uint64_t id; > -- > 2.17.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 08:52:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 08:52:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkkr4-00052B-Qr; Mon, 15 Jun 2020 08:52:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkkr3-000526-Px for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 08:52:33 +0000 X-Inumbo-ID: 8ca08b58-aee5-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8ca08b58-aee5-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 08:52:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UGnmJngMZPmF/wXsacw7+iZWrvqufFgyE7wslIUyw8o=; b=a7wWIGa+KRbi/SngYkLbJYN1/ 9n+kLUTvg70509uH9mb6Q99Sm4T2yXWLNjVf6zmaA7lNDucTdVq/X6izTEGhlQDRYnviXCS9ULqnI xQMwKnNg+BH8YIw1epUsRFAo/A1WeZHvlmBUfwxiPznH6ASjrIGNAmXuWGimO8IM1xyKY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkkr1-0004Bu-7l; Mon, 15 Jun 2020 08:52:31 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkkr0-0002qA-U0; Mon, 15 Jun 2020 08:52:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkkr0-0000PD-S4; Mon, 15 Jun 2020 08:52:30 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151095: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-i386-freebsd10-i386:xen-boot:fail:regression linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-armhf-armhf-examine:reboot:fail:regression linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=96144c58abe7ff767e754b5b80995f7b8846d49b X-Osstest-Versions-That: linux=5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 From: osstest service owner Date: Mon, 15 Jun 2020 08:52:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151095 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151095/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 151016 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151016 test-armhf-armhf-examine 8 reboot fail REGR. vs. 151016 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151016 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151016 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 96144c58abe7ff767e754b5b80995f7b8846d49b baseline version: linux 5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 Last test of basis 151016 2020-06-10 12:58:42 Z 4 days Failing since 151044 2020-06-11 10:29:35 Z 3 days 3 attempts Testing same since 151095 2020-06-14 05:04:56 Z 1 days 1 attempts ------------------------------------------------------------ 535 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine fail test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 33687 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 15 09:59:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 09:59:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkltf-0001e3-MD; Mon, 15 Jun 2020 09:59:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jklte-0001dw-28 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 09:59:18 +0000 X-Inumbo-ID: df91b702-aeee-11ea-b7ed-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id df91b702-aeee-11ea-b7ed-12813bfff9fa; Mon, 15 Jun 2020 09:59:17 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: vcNWnx5yGh4hTkgXvYf/KIE4FiLddVEm/qddxeyhj1FbD+GPzmGUwI/oNcY6T7jFzNERtQNFC5 o8GZ5pHnG2j3qMgnkfJpVl1CcC6bDAA3OMgJhdEKY0xpvzvvkZ+2zKz1OgPjQTx7nNXavjSYlt /4t6Z8Dnp4hcI2vnpYgKXWTmWrVUkPShcjquUzjOu9Qe3wVu65WfoWqeA44FbtAyObPY7zJf93 x1mdBCYDA0mkw8cwQeRZRQ0PwVQWp2SyHspu4vdHFMwGpoGobUiWDEoR2z8hoRVWhHkBjlkhQC 1YM= X-SBRS: 2.7 X-MesageID: 20040644 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20040644" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.18033.208180.895089@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 10:59:13 +0100 To: Paul Durrant Subject: Re: [xen-unstable test] 151073: regressions - FAIL In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" osstest service owner writes ("[xen-unstable test] 151073: regressions - FAIL"): > flight 151073 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/151073/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 151051 FTR, following discussion with Paul on irc, I force pushed this. > version targeted for testing: > xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce Ian. 10:35 The only rewgression is a failure to boot freebsd on a uefi box. Which is expected. Not sure why the baseline didn't fail. 10:36 Probably it ran on a differnet host for some reason (presumably all the failing uefi hosts were too busy...) From xen-devel-bounces@lists.xenproject.org Mon Jun 15 10:00:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 10:00:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jklv5-0002RG-1H; Mon, 15 Jun 2020 10:00:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jklv3-0002Qz-40 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 10:00:45 +0000 X-Inumbo-ID: 11c752ea-aeef-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 11c752ea-aeef-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 10:00:41 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id q11so16456666wrp.3 for ; Mon, 15 Jun 2020 03:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=7FVvavwJRrtYZHpZPbhx3fXJrJ5Jws1zwwFYj2fs8rE=; b=dAhhjC9D6bGt5slqmC3gXs2TN8dkXW25+0L8bgrlyYwW5wA4gHFJsxIOWJChZAwbvo OMHmkTglUlxYxL6WTv4JFdJJ3GcgjIZXTOwSeXf+sl8WyyZvDgBwv4z0IGX19wR3CZTu fc6PqsleJcmpt4+Mjo+51VWIlwkpJVVy0jivAZ4sla6CX0OkffK/7BHzrQayl9AroqUg JQBn4ICBtEp2Bb05CSu3OQ9bqHvkSYXItNY3vhfczLSzBL2p9Nlzg8pM8bFPaPgfVpPl vJg1YAGREELtyddzd2DQYtlDWayDh5yxiFObfk8acvtl5HUN8S7M/+Pv1V4lKr0DUwdt SVJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=7FVvavwJRrtYZHpZPbhx3fXJrJ5Jws1zwwFYj2fs8rE=; b=GYjAAu2j8N/5CShgRijOlud+yj+r07cvKbRcgmz7KnUcycr+e4ljjE4+zGpJdjlOwT +B5vWt/vrN08R22Y9YtoxVwJMdeqW3y2R4S/OwPTYeMo3zF0/1nQbWLiJVPcQFUVf6JH 0Jva5O90J9+Jpp61ODH8WxlZuiXzxG2kRwf0TdS9duzdzhAw5aFHOXObsQHL1v9NBZ4m tZE/B9Qx8h5NlCFYbPxhiJq3W4ApNmMUcVosIjAzC0KtMkyaZwu4PTnGWGePTtLII1+w HT4kcGL+WpAMq4Du8O9uffdziuqX8Zuva+nNxuuyyAZJLrf6KZwNtil7rCJVDYt83DxZ qYNw== X-Gm-Message-State: AOAM533p8AW4XUmpsdzkRhPubJ5FWLsS4sbs3YJVovhJ/Sg+4kHKMxn4 5oVkfNDp26CdugI9OcJRiYo= X-Google-Smtp-Source: ABdhPJyFQ7nwu3Ca07xeA2Cv4O5oQ+DCZ/cJ0nIAe5qJTU/51EgphOOqRkHgMvGE05W9dNmpNdPPNQ== X-Received: by 2002:a5d:6789:: with SMTP id v9mr29908456wru.124.1592215240328; Mon, 15 Jun 2020 03:00:40 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id c206sm24337775wmf.36.2020.06.15.03.00.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 03:00:39 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-2-roger.pau@citrix.com> In-Reply-To: <20200612155640.4101-2-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14 1/8] x86/hvm: fix vIO-APIC build without IRQ0_SPECIAL_ROUTING Date: Mon, 15 Jun 2020 11:00:38 +0100 Message-ID: <002b01d642fb$d2e229b0$78a67d10$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIx2gY8gI577+TutNP+VjieYU4/XgB3+NohqB6DL3A= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 12 June 2020 16:57 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich = ; Andrew > Cooper ; Wei Liu > Subject: [PATCH for-4.14 1/8] x86/hvm: fix vIO-APIC build without = IRQ0_SPECIAL_ROUTING >=20 > pit_channel0_enabled needs to be guarded with IRQ0_SPECIAL_ROUTING > since it's only used when the special handling of ISA IRQ 0 is = enabled. >=20 > No functional change. >=20 > Signed-off-by: Roger Pau Monn=C3=A9 > --- > xen/arch/x86/hvm/vioapic.c | 2 ++ > 1 file changed, 2 insertions(+) >=20 > diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c > index b87facb0e0..bd41036137 100644 > --- a/xen/arch/x86/hvm/vioapic.c > +++ b/xen/arch/x86/hvm/vioapic.c > @@ -391,10 +391,12 @@ static void ioapic_inj_irq( > vlapic_set_irq(target, vector, trig_mode); > } >=20 > +#ifdef IRQ0_SPECIAL_ROUTING > static inline int pit_channel0_enabled(void) > { > return pt_active(¤t->domain->arch.vpit.pt0); > } > +#endif It's only called in two places. How about just manually inlining? Paul >=20 > static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int = pin) > { > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 10:27:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 10:27:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkmKc-0004Cv-KD; Mon, 15 Jun 2020 10:27:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkmKb-0004Cp-QN for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 10:27:09 +0000 X-Inumbo-ID: c3753888-aef2-11ea-b7ee-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c3753888-aef2-11ea-b7ee-12813bfff9fa; Mon, 15 Jun 2020 10:27:07 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: krUyUks5c+ci7PGGPG0nm5C+BrXk2ERKKujZibaw4mQQrK+XvvT7UAHzvWW54D+FeeSUBgaRu0 4QFEY+1nx/HMKckswkDwTDWDhwRE5iPpxOk5Ty6hS7//UHjAKLLZWEF8fn4LKLMbmwiuoJ/85P izt7PSCd09n5r4R9eVcep1RRLwWX7atxbsosFrMEk5uRbXPokeYq5szyeq3Z34oKdkZPItiLxV zPqsVBiEiZ8Z1zmSzrb12sdvOUCZkiFxDeAoDr+P1LnfuXSRRQTa18cY/c4H1HGjCqQox4du6V CQ8= X-SBRS: 2.7 X-MesageID: 20342262 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20342262" Date: Mon, 15 Jun 2020 12:26:59 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Grzegorz Uriasz Subject: Re: [PATCH 3/3] tools/libxl: Directly map VBIOS to stubdomain Message-ID: <20200615102659.GB735@Air-de-Roger> References: <9817b73ea628c7ac86903bb9aa7fcfecf4f7b900.1592171394.git.gorbak25@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <9817b73ea628c7ac86903bb9aa7fcfecf4f7b900.1592171394.git.gorbak25@gmail.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Ian Jackson , marmarek@invisiblethingslab.com, Anthony PERARD , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sun, Jun 14, 2020 at 10:12:03PM +0000, Grzegorz Uriasz wrote: > When passing through a IGD VGA device qemu needs to copy the host VBIOS > to the target domain. Right now the current implementation on the qemu side > is one big undefined behavior as described in my qemu patchset here: > https://patchew.org/QEMU/20200428062847.7764-1-gorbak25@gmail.com/ I think it would be good to elaborate a bit more here on the issue, that link could go away and we still need to keep the reasoning behind this change in the Xen changelog IMO. > This patch is tied to the linked patchset for qemu but fortunately > this patch still works without the qemu part merged. When the qemu part > gets merged then qemu will access the VBIOS using /dev/mem - this is > required as currently the linux kernel forbids accessing this memory > region when the VBIOS is corrupted - which will always be the case as > described in the linked patchset. When qemu is running inside a linux > based stubdomain then the stubdomain does not have access to the VBIOS. > This patch maps the VBIOS to the stubdomain so qemu with my fixes may > create a shadow copy for the target domain. > > Signed-off-by: Grzegorz Uriasz > --- > tools/libxl/libxl_pci.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > index 48b1d8073b..9b9564dd73 100644 > --- a/tools/libxl/libxl_pci.c > +++ b/tools/libxl/libxl_pci.c > @@ -2445,6 +2445,8 @@ static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t dom > int ret, i; > uint64_t vga_iomem_start = 0xa0000 >> XC_PAGE_SHIFT; > uint64_t vga_iomem_npages = 0x20; > + uint64_t vga_vbios_start = 0xc0000 >> XC_PAGE_SHIFT; > + uint64_t vga_vbios_npages = 0x20; Is this always 32 pages? Some claim [0] it's 32KiB (so 8 pages). Wouldn't it be safer to fetch the size from sysfs or some other place if possible? > uint32_t stubdom_domid = libxl_get_stubdom_id(CTX, domid); > uint64_t vga_ioport_start[] = {0x3B0, 0x3C0}; > uint64_t vga_ioport_size[] = {0xC, 0x20}; > @@ -2460,6 +2462,7 @@ static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t dom > vga_iomem_start, (vga_iomem_start + (vga_iomem_npages << XC_PAGE_SHIFT) - 1)); > return ret; > } > + Stray change? > ret = xc_domain_iomem_permission(CTX->xch, domid, > vga_iomem_start, vga_iomem_npages, 1); > if (ret < 0) { > @@ -2470,6 +2473,13 @@ static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t dom > return ret; > } > > + /* VGA ROM */ > + ret = xc_domain_memory_mapping(CTX->xch, stubdom_domid, vga_vbios_start, vga_vbios_start, vga_vbios_npages, DPCI_ADD_MAPPING); Line is too long, please limit lines to 75 characters (see libxl/CODING_STYLE). > + if (ret < 0) { > + LOGED(ERROR, domid, "failed to map VBIOS to stubdom%d", stubdom_domid); AFAICT you have to use LOGEVD here, since the errno value will be returned in 'ret'. Ie: if (ret < 0) { LOGED(ERROR, ret, domid, "failed to map VBIOS to stubdom%d", stubdom_domid); return ERROR_FAIL; } Thanks, Roger. [0] https://wiki.osdev.org/Memory_Map_(x86)#Overview From xen-devel-bounces@lists.xenproject.org Mon Jun 15 11:14:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 11:14:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkn3k-0008OM-Fr; Mon, 15 Jun 2020 11:13:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkn3j-0008OH-9w for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 11:13:47 +0000 X-Inumbo-ID: 46f2113a-aef9-11ea-b7f4-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 46f2113a-aef9-11ea-b7f4-12813bfff9fa; Mon, 15 Jun 2020 11:13:45 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: wYF8SK23NpXxXejiOJZOEZcReX0/O3yWik1Wb1AfZcpU8FlPW9D3HKTDuaKh0fAyjtVciPJCPn 7izEINcpXMHOdyk/0RMg25MpSqnDjpkmI13NzLtadkozNPuCFddMiy8VoYTRn9JX2oTMQ+AGaJ VbIdIhkk/z3Mm2hoPR8bbQh9n/FNbbA19MgNAXRFCuv+jVzP4eh056x6ByBxjw++c/CsCH+GRO 8DtpjWzuWK2eSwcyJZJ1G1PK6NzrC0EFt5ZZTKG3Fqxqd+ZyNFBeXgk7YsGZm5pWZpuCPBtEk6 kdk= X-SBRS: 2.7 X-MesageID: 20060624 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20060624" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.22498.780976.930384@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 12:13:38 +0100 To: "paul@xen.org" Subject: RE: [XEN PATCH for-4.14] tools/xen-ucode: fix error code propagation of microcode load operation In-Reply-To: <001001d640dc$db8704d0$92950e70$@xen.org> References: <1591980255-18811-1-git-send-email-igor.druzhinin@citrix.com> <24291.45845.782250.165305@mariner.uk.xensource.com> <001001d640dc$db8704d0$92950e70$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Igor Druzhinin , Andrew Cooper , 'Paul Durrant' , "wl@xen.org" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: [XEN PATCH for-4.14] tools/xen-ucode: fix error code propagation of microcode load operation"): > > -----Original Message----- > > From: Ian Jackson > > Paul, would you Release-ack a patch that replaced every `return errno' > > with (say) exit(12) ? > > Why 12? I tend to use 12 to mean `things went wrong'. 1 is a poor choice for this because you want to use smaller numbers for less severe errors and you want some space for things like "everything went OK but the thing you asked me to delete already didn't exist" or "I compared these files like you asked, and they are different". > > Otherwise, fixing this program not to try to > > fit errno into an exit status is future work. Also I notice that the > > program exits 0 if invoked wrongly. Unhelpful! I would want to fix > > that too. > > Agreed that is unhelpful. I'm happy in principle to release-ack > something replacing the returns with exits. Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 11:17:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 11:17:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkn7U-0008WB-Vu; Mon, 15 Jun 2020 11:17:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkn7U-0008W6-MF for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 11:17:40 +0000 X-Inumbo-ID: d1d9f06b-aef9-11ea-b7f5-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d1d9f06b-aef9-11ea-b7f5-12813bfff9fa; Mon, 15 Jun 2020 11:17:39 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: phlSTwlGDc+blEyPreYvkW/PoyrAa5zL+2v7HWYdFicrFzY1n+qq3inil5CfWSbHk4pR0FTiy+ 6getnJsnbyHculruL865rR1MtwtZXcqbre1CsQtjEjQIEjnRPeg0d77Fgkj0ntm5vYRkYEKgmR heiZNLtoqbntmzOive8zW4PRmcmBETSq+sU4+n6y2O/r30/9c0mbdkNQSYqq4bi4p+k57eC7fq FXh+g/BaKzBYhHyU1Nw/b1eTHe7CGolXxbKW79wA3YxGJ4/zE4sbiqPTaf6sLF3G1wmn5aaclw 6MA= X-SBRS: 2.7 X-MesageID: 20281770 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20281770" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.22733.121370.189379@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 12:17:33 +0100 To: Igor Druzhinin Subject: Re: [XEN PATCH for-4.14] tools/xen-ucode: fix error code propagation of microcode load operation In-Reply-To: <2d885485-c00f-9938-33fc-1f20d084b259@citrix.com> References: <1591980255-18811-1-git-send-email-igor.druzhinin@citrix.com> <24291.45845.782250.165305@mariner.uk.xensource.com> <2d885485-c00f-9938-33fc-1f20d084b259@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , "wl@xen.org" , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Igor Druzhinin writes ("Re: [XEN PATCH for-4.14] tools/xen-ucode: fix error code propagation of microcode load operation"): > On 12/06/2020 17:53, Ian Jackson wrote: > > Unfortunately I don't think this is right. errno might not fit into a > > return value. > > errno codes that Xen return are all lower than 127. It fits perfectly fine. I don't think this is a stable aspect of Xen's ABI, is it ? And of course what you get from libxc is not a Xen errno in Xen encoding, but a Xen errno in host errno encoding, whioch might be >=127 even if the Xen number for the same EFOOBAR is <=127. But anyway, if this is controversial I will drop it. > Probably but that is identical to what was suggested. > Cleaning resource is just a nice thing to do although unnecessary. > Can change to just "return errno" if that's what you'd prefer. Yes please. Would you care to at least arrange for bad usage to exit nonzero ? I will leave it up to you to resolve this quandry: your view is that this program's exit status is a Xen errno value (in host encoding, presumably, although you don't state this) but now you need to return an error that didn't come from Xen. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 11:18:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 11:18:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkn7r-000073-7z; Mon, 15 Jun 2020 11:18:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkn7q-00006r-1t for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 11:18:02 +0000 X-Inumbo-ID: df640ee6-aef9-11ea-b7bb-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id df640ee6-aef9-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 11:18:01 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ebrzSCwXQMMPYhKsmDkX2cBqaAc8BOt+LK8mHaBgYLg1+kE74OArTI1YVd1Ev8cYk00DH5stRZ yoY/ALUQFMjRsmGFKNt26LIP0aXRVOq4J3vL/0La/fWy9tKyafS936+MLuB21H16MT80KdTAlU gSomtmfLABc4L0oIh1z9DvIjLKdHuvX9fbmZeNeUKcbeECf9AiGdjmUwyUC+gXY7o4EsP0NAiD dVFuG6KBdBX/FpQqKdf+Z4SDHOg8GUtCP/pv1IiK7mlTQNSdGQzm7/l4DgJGP4e/wNvrMzuE7S Dyg= X-SBRS: 2.7 X-MesageID: 20391563 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20391563" Date: Mon, 15 Jun 2020 13:17:49 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Grzegorz Uriasz Subject: Re: [PATCH 1/3] tools/libxl: Grant VGA IO port permission for stubdom/target domain Message-ID: <20200615111749.GC735@Air-de-Roger> References: <87d74a21bde95cfc7c53fad56bf8f0e47724953e.1592171394.git.gorbak25@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <87d74a21bde95cfc7c53fad56bf8f0e47724953e.1592171394.git.gorbak25@gmail.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Ian Jackson , marmarek@invisiblethingslab.com, Anthony PERARD , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sun, Jun 14, 2020 at 10:12:01PM +0000, Grzegorz Uriasz wrote: > When qemu is running inside a linux based stubdomain, qemu does not > have the necessary permissions to map the ioports to the target domain. > Currently, libxl is granting permissions only for the VGA RAM memory region > and not passing the required ioports. This patch grants the required > permission for the necessary vga io ports. > > Signed-off-by: Grzegorz Uriasz > --- > tools/libxl/libxl_pci.c | 99 ++++++++++++++++++++++++++++++----------- > 1 file changed, 73 insertions(+), 26 deletions(-) > > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > index 957ff5c8e9..436190f790 100644 > --- a/tools/libxl/libxl_pci.c > +++ b/tools/libxl/libxl_pci.c > @@ -2441,17 +2441,75 @@ void libxl__device_pci_destroy_all(libxl__egc *egc, uint32_t domid, > } > } > > +static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t domid) { > + int ret, i; Nit: i can be unsigned int since it's only used as a loop counter. > + uint64_t vga_iomem_start = 0xa0000 >> XC_PAGE_SHIFT; > + uint64_t vga_iomem_npages = 0x20; unsigned int is fine to store the size. > + uint32_t stubdom_domid = libxl_get_stubdom_id(CTX, domid); > + uint64_t vga_ioport_start[] = {0x3B0, 0x3C0}; > + uint64_t vga_ioport_size[] = {0xC, 0x20}; For IO ports ranges/sizes you can safely use unsigned ints, those only go up to 65535, and also constify the array since it's read-only. Can you expand a bit on where those ranges are taken from? Why not pass the whole 0x03B0-0x03DF range? > + > + /* VGA RAM */ > + ret = xc_domain_iomem_permission(CTX->xch, stubdom_domid, > + vga_iomem_start, vga_iomem_npages, 1); > + if (ret < 0) { > + LOGED(ERROR, domid, > + "failed to give stubdom%d access to iomem range " > + "%"PRIx64"-%"PRIx64" for VGA passthru", > + stubdom_domid, > + vga_iomem_start, (vga_iomem_start + (vga_iomem_npages << XC_PAGE_SHIFT) - 1)); > + return ret; I think it would be better to return a libxl error code here: ERROR_FAIL. You already log the error code, and libxl functions have their own set of error codes. > + } > + ret = xc_domain_iomem_permission(CTX->xch, domid, > + vga_iomem_start, vga_iomem_npages, 1); > + if (ret < 0) { > + LOGED(ERROR, domid, > + "failed to give dom%d access to iomem range " > + "%"PRIx64"-%"PRIx64" for VGA passthru", > + domid, vga_iomem_start, (vga_iomem_start + (vga_iomem_npages << XC_PAGE_SHIFT) - 1)); > + return ret; > + } > + > + /* VGA IOPORTS */ > + for (i = 0 ; i < 2 ; i++) { Please use ARRAY_SIZE(vga_ioport_start) here. And I would also assert that both vga_ioport_start and vga_ioport_size arrays have the same sizes before the loop. > + ret = xc_domain_ioport_permission(CTX->xch, stubdom_domid, > + vga_ioport_start[i], vga_ioport_size[i], 1); > + if (ret < 0) { > + LOGED(ERROR, domid, > + "failed to give stubdom%d access to ioport range " > + "%"PRIx64"-%"PRIx64" for VGA passthru", > + stubdom_domid, > + vga_ioport_start[i], (vga_ioport_start[i] + vga_ioport_size[i] - 1)); > + return ret; > + } > + ret = xc_domain_ioport_permission(CTX->xch, domid, > + vga_ioport_start[i], vga_ioport_size[i], 1); > + if (ret < 0) { > + LOGED(ERROR, domid, > + "failed to give dom%d access to ioport range " > + "%"PRIx64"-%"PRIx64" for VGA passthru", > + domid, vga_ioport_start[i], (vga_ioport_start[i] + vga_ioport_size[i] - 1)); > + return ret; > + } > + } > + > + return 0; > +} > + > +static int libxl__grant_igd_opregion_permission(libxl__gc *gc, const uint32_t domid) { > + return 0; > +} > + > int libxl__grant_vga_iomem_permission(libxl__gc *gc, const uint32_t domid, > libxl_domain_config *const d_config) > { > - int i, ret; > + int i, ret = 0; > + bool vga_found = false, igd_found = false; > > if (!libxl_defbool_val(d_config->b_info.u.hvm.gfx_passthru)) > return 0; > > - for (i = 0 ; i < d_config->num_pcidevs ; i++) { > - uint64_t vga_iomem_start = 0xa0000 >> XC_PAGE_SHIFT; > - uint32_t stubdom_domid; > + for (i = 0 ; i < d_config->num_pcidevs && !igd_found ; i++) { > libxl_device_pci *pcidev = &d_config->pcidevs[i]; > unsigned long pci_device_class; > > @@ -2460,30 +2518,19 @@ int libxl__grant_vga_iomem_permission(libxl__gc *gc, const uint32_t domid, > if (pci_device_class != 0x030000) /* VGA class */ > continue; > > - stubdom_domid = libxl_get_stubdom_id(CTX, domid); > - ret = xc_domain_iomem_permission(CTX->xch, stubdom_domid, > - vga_iomem_start, 0x20, 1); > - if (ret < 0) { > - LOGED(ERROR, domid, > - "failed to give stubdom%d access to iomem range " > - "%"PRIx64"-%"PRIx64" for VGA passthru", > - stubdom_domid, > - vga_iomem_start, (vga_iomem_start + 0x20 - 1)); > - return ret; > - } > - ret = xc_domain_iomem_permission(CTX->xch, domid, > - vga_iomem_start, 0x20, 1); > - if (ret < 0) { > - LOGED(ERROR, domid, > - "failed to give dom%d access to iomem range " > - "%"PRIx64"-%"PRIx64" for VGA passthru", > - domid, vga_iomem_start, (vga_iomem_start + 0x20 - 1)); > - return ret; > - } > - break; > + vga_found = true; > + if (pcidev->bus == 0 && pcidev->dev == 2 && pcidev->func == 0) > + igd_found = true; Could you check that the vendor is Intel also using sysfs_dev_get_vendor? Or else this could trigger on AMD boxes if they happen to have a VGA PCI device at 00:2.0. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 11:32:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 11:32:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jknLp-0001lP-IA; Mon, 15 Jun 2020 11:32:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jknLo-0001lK-A7 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 11:32:28 +0000 X-Inumbo-ID: e3bb8fb2-aefb-11ea-b7bb-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e3bb8fb2-aefb-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 11:32:27 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: qZwCAiv/Kn5qj7A/xgprBXLybuJOS1Mv7kLf91iJYu84ToylJ48/+dVw0shWj7xEzHfHuMJYDh jWepxSu2L33EIKWZTk3KsWiOWkXUdImyUREjRoj4jZedu3cwv1JaeOqCRt8qX92EZnz6+gS7Ht 7qK4rheI/bbJEukZ7WBMZxELabpCQL4INeUL4hmhd3pYJUuzWtT+bWpVWaUIMjT4+1/Rz1vBNN gTTuN9mSWq5xCLUja1UTiu6PsVOjWVpR2FRvP4aCCuXU4OUCnnMcPuaTwifmf1gyN9o1NNkkxO 6dE= X-SBRS: 2.7 X-MesageID: 20347109 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20347109" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.23621.756554.824238@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 12:32:21 +0100 To: Grzegorz Uriasz Subject: Re: [PATCH 1/3] tools/libxl: Grant VGA IO port permission for stubdom/target domain In-Reply-To: <87d74a21bde95cfc7c53fad56bf8f0e47724953e.1592171394.git.gorbak25@gmail.com> References: <87d74a21bde95cfc7c53fad56bf8f0e47724953e.1592171394.git.gorbak25@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , "jakub@bartmin.ski" , "marmarek@invisiblethingslab.com" , "j.nowak26@student.uw.edu.pl" , Anthony Perard , "xen-devel@lists.xenproject.org" , "contact@puzio.waw.pl" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Grzegorz Uriasz writes ("[PATCH 1/3] tools/libxl: Grant VGA IO port permission for stubdom/target domain"): > When qemu is running inside a linux based stubdomain, qemu does not > have the necessary permissions to map the ioports to the target domain. > Currently, libxl is granting permissions only for the VGA RAM memory region > and not passing the required ioports. This patch grants the required > permission for the necessary vga io ports. Thanks. I'm afraid I don't know much about this. The code looks plausible, although there is a minor breach of official libxl coding style in the use of `ret' rather than `r' for the xc return values, and retuerning that value rather than a libxl error code. I wouldn't regard that as a blocker considering the state of the surrounding code. I see from SUPPPORT.md that graphics passthrough seems to be security supported. Frankly this seems very surprising to me. Given that, I think we need a review from someone who understood graphics passthrough. I think that applies to all 3 of these patches. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 11:42:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 11:42:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jknVf-0002de-Gw; Mon, 15 Jun 2020 11:42:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jknVd-0002cv-KU for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 11:42:37 +0000 X-Inumbo-ID: 4f01be44-aefd-11ea-b7bb-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4f01be44-aefd-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 11:42:36 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: fYcpnAMj5QakSDLOon9DMnk0cUKJ62zFVtVmeFl15rdfY8uJjciPfeUNFU/+C/9JQKDx3hAlZB NXzDXlpfIHz4w6Lt7m4ajUlBxq3kC1U27xEBGo33kXtngR9ECYTnNz4eJjoFKdLePVieMhzvDh PqXmpLMGcl+YL9LrzkJdoxJ0t4QbA8Z7PucKXRZ5nCNSnlmMsDYz5ntsGAEUezoLUUTXJd8NUQ 0241Z3W4VEGsdus0YLKtogWeQkytNqvA80Rk+xJd4U422FbCHDR7/YWLLr6aCPnCqS1gR8AnXr Huc= X-SBRS: 2.7 X-MesageID: 20821990 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20821990" From: George Dunlap To: Nick Rosbrook Subject: Re: [PATCH for-4.14] tools: check go compiler version if present Thread-Topic: [PATCH for-4.14] tools: check go compiler version if present Thread-Index: AQHWQMYebVnRI4xswUubEbtplwogO6jZcQgA Date: Mon, 15 Jun 2020 11:42:33 +0000 Message-ID: <1092B004-655B-4EC0-8380-EBCCE677A1A4@citrix.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , "xen-devel@lists.xenproject.org" , Ian Jackson , Wei Liu , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQo+IE9uIEp1biAxMiwgMjAyMCwgYXQgMzozMSBQTSwgTmljayBSb3Nicm9vayA8cm9zYnJvb2tu QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBDdXJyZW50bHksIG5vIG1pbmltdW0gZ28gY29tcGls ZXIgdmVyc2lvbiBpcyByZXF1aXJlZCBieSB0aGUgY29uZmlndXJlDQo+IHNjcmlwdHMuIEhvd2V2 ZXIsIHRoZSBnbyBiaW5kaW5ncyBhY3R1YWxseSB3aWxsIG5vdCBidWlsZCB3aXRoIHNvbWUNCj4g b2xkZXIgdmVyc2lvbnMgb2YgZ28uIEFkZCBhIGNoZWNrIGZvciBhIG1pbmltdW0gZ28gdmVyc2lv biBvZiAxLjExLjEgaW4NCj4gYWNjb3JkYW5jZSB3aXRoIHRvb2xzL2dvbGFuZy94ZW5saWdodC9n by5tb2QuDQo+IA0KPiBTaWduZWQtb2ZmLWJ5OiBOaWNrIFJvc2Jyb29rIDxyb3Nicm9va25AYWlu Zm9zZWMuY29tPg0KDQpUaGVyZeKAmXMgYSBnb29kIGNoYW5jZSBJIHdvbuKAmXQgaGF2ZSB0aW1l IHRvIHJldmlldyB0aGUgY29kZSBmb3IgdGhpcyBhdCBhbGwgdGhpcyB3ZWVrOyBidXQgcmVnYXJk aW5nIHRoZSBpbnRlbnRpb24gb2YgaGF2aW5nIDEuMTEuMSBhcyBhIG1pbmltdW0gdmVyc2lvbjoN Cg0KQWNrZWQtYnk6IEdlb3JnZSBEdW5sYXAgPGdlb3JnZS5kdW5sYXBAY2l0cml4LmNvbT4NCg0K From xen-devel-bounces@lists.xenproject.org Mon Jun 15 11:44:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 11:44:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jknXF-0002ko-8l; Mon, 15 Jun 2020 11:44:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jknXE-0002kf-FD for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 11:44:16 +0000 X-Inumbo-ID: 89484200-aefd-11ea-b7f9-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 89484200-aefd-11ea-b7f9-12813bfff9fa; Mon, 15 Jun 2020 11:44:16 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: +VCt2J+qFnmXbnirkPW43krISHVsBsidrbcUAhuV+z63IMl+vyqY1cjb5X0Odoyvv5FIoGpH++ Klwuay9ouLxBTBLRHL8CpkQg8ZUa3MkaVzi4G8OAztRXR69xBUZqjdBdtWOhy2mIGkk+Mu1EGR ep/VX8l26GoDNFCbocdoIF8ZVs5cwU2JWDJrPKrezRJHwFUbR1r4v7psvt1du9Lu0/MblpBa7R iv6m+gmejscEMep/q8V8OHoY4oUDj6zx9msqGQWADrwzEmW3uJ04yw7LSneNlllnIcWmwa4fAe 9M0= X-SBRS: 2.7 X-MesageID: 20822063 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20822063" Date: Mon, 15 Jun 2020 13:44:09 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Subject: Re: [PATCH for-4.14 1/8] x86/hvm: fix vIO-APIC build without IRQ0_SPECIAL_ROUTING Message-ID: <20200615114409.GD735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-2-roger.pau@citrix.com> <002b01d642fb$d2e229b0$78a67d10$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <002b01d642fb$d2e229b0$78a67d10$@xen.org> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Wei Liu' , 'Jan Beulich' , 'Andrew Cooper' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 11:00:38AM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Roger Pau Monne > > Sent: 12 June 2020 16:57 > > To: xen-devel@lists.xenproject.org > > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich ; Andrew > > Cooper ; Wei Liu > > Subject: [PATCH for-4.14 1/8] x86/hvm: fix vIO-APIC build without IRQ0_SPECIAL_ROUTING > > > > pit_channel0_enabled needs to be guarded with IRQ0_SPECIAL_ROUTING > > since it's only used when the special handling of ISA IRQ 0 is enabled. > > > > No functional change. > > > > Signed-off-by: Roger Pau Monné > > --- > > xen/arch/x86/hvm/vioapic.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c > > index b87facb0e0..bd41036137 100644 > > --- a/xen/arch/x86/hvm/vioapic.c > > +++ b/xen/arch/x86/hvm/vioapic.c > > @@ -391,10 +391,12 @@ static void ioapic_inj_irq( > > vlapic_set_irq(target, vector, trig_mode); > > } > > > > +#ifdef IRQ0_SPECIAL_ROUTING > > static inline int pit_channel0_enabled(void) > > { > > return pt_active(¤t->domain->arch.vpit.pt0); > > } > > +#endif > > It's only called in two places. How about just manually inlining? That would be fine, as I'm also removing one of the callers in a following patch. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 12:44:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 12:44:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkoTS-0007pi-79; Mon, 15 Jun 2020 12:44:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkoTQ-0007pd-64 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 12:44:24 +0000 X-Inumbo-ID: effd71e6-af05-11ea-bb8b-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id effd71e6-af05-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 12:44:22 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Makh8j15Bgehfs9r8zSNf1pupkRXeJKdgc5+e60sBNgUr83+Vgxfxb/z853DV87MKt3vkugXp5 TcL/pOCn6CK/Lui4nfSBGXo2Ncy42lcVGUy1kWim5UyzphIP7rGd1biBjCNpyFpFIs1D8fc0Im OKvam3e8NoRC8Fs2GmkqpJFWYFI+lNRVmtEja5EFWma7/HfG67pdgI1pm4H7B7zEKl2spm1Pgt DLnMRcWUIVC/X/c5p4ZuUUJbWqRNJ4Rh/wS3/DgYLgNYIinRi16Z57lxVv8PS/hTLalQWoutO9 /rA= X-SBRS: 2.7 X-MesageID: 20827550 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20827550" Date: Mon, 15 Jun 2020 14:44:13 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Grzegorz Uriasz Subject: Re: [PATCH 2/3] tools/libxl: Grant permission for mapping opregions to the target domain Message-ID: <20200615124413.GE735@Air-de-Roger> References: <18bebc4af48b83d71b3247082434b958be84b841.1592171394.git.gorbak25@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <18bebc4af48b83d71b3247082434b958be84b841.1592171394.git.gorbak25@gmail.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Ian Jackson , marmarek@invisiblethingslab.com, Anthony PERARD , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sun, Jun 14, 2020 at 10:12:02PM +0000, Grzegorz Uriasz wrote: > IGD VGA devices require a special opregion MMIO region which functions as > an extra BAR in the PCI configuration space. Right now qemu is assigning those > permissions - this is failing inside a linux based stubdomain as the > stubdomain is not privileged. This patch grants the permissions for > opregions in libxl instead of qemu. Granting permissions in qemu may be removed > when this patch get's merged - for now linux based stubdomains which use IGD's > need to patch qemu and include this patch in xen for IGD passthrough to work. > > Signed-off-by: Grzegorz Uriasz Thanks for the patch! > --- > tools/libxl/libxl_pci.c | 46 ++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 45 insertions(+), 1 deletion(-) > > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > index 436190f790..48b1d8073b 100644 > --- a/tools/libxl/libxl_pci.c > +++ b/tools/libxl/libxl_pci.c > @@ -2497,7 +2497,51 @@ static int libxl__grant_legacy_vga_permissions(libxl__gc *gc, const uint32_t dom > } > > static int libxl__grant_igd_opregion_permission(libxl__gc *gc, const uint32_t domid) { > - return 0; > + char* sysfs_path; > + FILE* f; > + uint32_t igd_host_opregion; > + int ret = 0; No need to init ret. > + uint32_t stubdom_domid = libxl_get_stubdom_id(CTX, domid); > + > + sysfs_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/config", 0, 0, 2, 0); > + f = fopen(sysfs_path, "r"); > + if (!f) { > + LOGED(ERROR, domid, "Unable to access IGD config space"); > + return ERROR_FAIL; > + } > + > + ret = fseek(f, 0xfc, SEEK_SET); > + if (ret < 0) { > + LOGED(ERROR, domid, "Unable to lseek in PCI config space"); > + goto out; > + } > + > + ret = fread((void*)&igd_host_opregion, 4, 1, f); > + if (ret < 0) { > + LOGED(ERROR, domid, "Unable to read opregion register"); > + goto out; > + } > + > + ret = xc_domain_iomem_permission(CTX->xch, stubdom_domid, > + (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), 0x3, 1); > + if (ret < 0) { > + LOGED(ERROR, domid, > + "failed to give stubdom%d access to %"PRIx32" opregions for igd passthrough", stubdom_domid, igd_host_opregion); > + goto out; > + } I think you only need to do this if there's a stubdomain? If stubdom_domid is 0 then you don't need to do this. Also, I'm not sure hardcoding the size is correct, AFAICT the size should be fetched from the OpRegion Header size field? The specification I'm reading for IGD OpRegion for Skylake processors mentions the size of the OpRegion is 8KiB (so 2 pages). > + > + ret = xc_domain_iomem_permission(CTX->xch, domid, > + (unsigned long)(igd_host_opregion >> XC_PAGE_SHIFT), 0x3, 1); > + if (ret < 0) { > + LOGED(ERROR, domid, > + "failed to give dom%d access to %"PRIx32" opregions for igd passthrough", domid, igd_host_opregion); > + goto out; > + } > + > + out: You should remove the leading spaces on the label. > + if(f) No need for the 'if (f)', since all code paths leading here will have f != NULL. > + fclose(f); > + return ret; I think you want to return ERROR_FAIL if ret, ie: return ret ? ERROR_FAIL : 0; Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 12:48:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 12:48:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkoX6-0007yQ-O7; Mon, 15 Jun 2020 12:48:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkoX5-0007yL-IH for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 12:48:11 +0000 X-Inumbo-ID: 75254b46-af06-11ea-b7fa-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 75254b46-af06-11ea-b7fa-12813bfff9fa; Mon, 15 Jun 2020 12:48:06 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Nh5LXmhLtCbbZ63JR5d3tnwCEewMo1+TaSAPZ8FxYOH1Kxe8NtpniYLsiKTds5PMA0laHTNakk nLiIwcZDT9zM0ygdqkZkaB3yBFEf2WKDoRxHP5wMshRODN2qn1iI+LdEUIavkGJrYx0Ub9dyDE aI+anYMAgQlixzXO6PTXZdj/aupni6RIg9tlQQI3kN+KttoWb2gufhS2Jm+Xl1CAOlXr+i9+k2 UxosB4mQvLqCiQtjssaxOl1tLBjKOoUYF8437gTzPoAugsUoTxPSSes8f6Vfxgkt3oz9NDi/S9 6PE= X-SBRS: 2.7 X-MesageID: 20289285 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20289285" Date: Mon, 15 Jun 2020 14:47:58 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Grzegorz Uriasz Subject: Re: [PATCH] hw/xen_pt: Don't grant opregion permissions Message-ID: <20200615124758.GF735@Air-de-Roger> References: <2157e10d63619d43151fe8b8ca913b44c54aba6e.1592176600.git.gorbak25@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <2157e10d63619d43151fe8b8ca913b44c54aba6e.1592176600.git.gorbak25@gmail.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , jakub@bartmin.ski, qemu-devel@nongnu.org, marmarek@invisiblethingslab.com, Anthony Perard , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sun, Jun 14, 2020 at 11:21:09PM +0000, Grzegorz Uriasz wrote: > With the upstreaming of linux based stubdomains to xen, qemu can't > assume it runs inside dom0 - permission assignment must be moved to > libxl running in dom0. This xen patch: > https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00973.html > implements granting the required permissions to the stubdomain running > qemu. This patch removes granting opregion permissions in qemu - this > should be fine as when qemu is running inside dom0 the memory mapping will > be successfully created without first explicitly granting the permission. In order to avoid breaking certain libxl - QEMU combinations, could you make the check below non-fatal? So that the current code can be kept for dom0 while not throwing an error when used inside of a stub domain? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 13:07:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 13:07:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkopE-0001Ey-En; Mon, 15 Jun 2020 13:06:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkopC-0001Ee-SK for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 13:06:54 +0000 X-Inumbo-ID: 106d7a22-af09-11ea-b7fa-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 106d7a22-af09-11ea-b7fa-12813bfff9fa; Mon, 15 Jun 2020 13:06:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=i5Y0eENlRcGRrIh9AeANI8SnuvoKzZQR+pAVOOefbs4=; b=6du0uWi4nTSiwcrMMdlVbzNU9 ZF16haNcT0YgROr8apii1GJYrLI4ZZG4QNjcLKUYs1AIIfHNW/SvfELA+ptjZPBPOO7561bgwx6AN K/GwSy1EmxLTBal0vwrqDW4qF23PjQKTaeV3NWCyB6EwJKfZv032G3DZnHrR0eEm6Ggbo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkop3-0000WW-3i; Mon, 15 Jun 2020 13:06:45 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkoos-0007fM-I9; Mon, 15 Jun 2020 13:06:34 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkoos-0004gd-HP; Mon, 15 Jun 2020 13:06:34 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151101: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-armhf-armhf-xl-credit2:xen-boot:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:xen-boot/l1:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:xen-boot/l1:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=7d3660e79830a069f1848bb4fa1cdf8f666424fb X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Mon, 15 Jun 2020 13:06:34 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151101 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151101/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 7 xen-boot fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151065 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151065 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151065 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass version targeted for testing: qemuu 7d3660e79830a069f1848bb4fa1cdf8f666424fb baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 2 days Testing same since 151101 2020-06-14 08:32:51 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alex Bennée Alex Williamson Alexander Bulekov Anthony PERARD Babu Moger Cathy Zhang Colin Xu Cédric Le Goater David Carlier David Gibson Edgar E. Iglesias Eric Auger Evgeny Yakovlev Igor Mammedov Janne Grunau Jon Doron Joseph Myers Julio Faracco Leonid Bloch Leonid Bloch Like Xu Liran Alon Maciej S. Szmigiero Markus Armbruster Masahiro Yamada Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Roman Bolshakov Roman Kagan Sai Pavan Boddu Thomas Huth WangBowen Wei Huang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 fail test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2277 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 15 13:29:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 13:29:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpBH-0002wq-D3; Mon, 15 Jun 2020 13:29:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpBG-0002wl-Ds for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 13:29:42 +0000 X-Inumbo-ID: 44283eda-af0c-11ea-b7fb-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 44283eda-af0c-11ea-b7fb-12813bfff9fa; Mon, 15 Jun 2020 13:29:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 72ACEACE1; Mon, 15 Jun 2020 13:29:43 +0000 (UTC) Subject: Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) To: Ian Jackson References: <24291.43673.301735.439410@mariner.uk.xensource.com> <24291.45488.423085.940252@mariner.uk.xensource.com> From: Jan Beulich Message-ID: <3c68a609-a069-f7e1-3c99-291da372df96@suse.com> Date: Mon, 15 Jun 2020 15:29:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24291.45488.423085.940252@mariner.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Julien Grall , George Dunlap , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 18:47, Ian Jackson wrote: > Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"): >>> test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 >>> test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 >>> test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 >> >> domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... >> domainbuilder: detail: XZ: Saw data stream end >> domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 0x1a7779c >> domainbuilder: detail: loader probe OK >> ... >> domainbuilder: detail: xc_dom_alloc_segment: module0 : 0xffffffff82c00000 -> 0xffffffff82c02000 (pfn 0x2c00 + 0x2 pages) >> xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed (rc=-5): Internal error >> libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: No such file or directory >> >> http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log >> >> ???? Anyone have any ideas ? I would have guessed that this was an >> incompatibility between pygrub and the boot config made by the new >> pygrub but >> git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/ >> suggests not. > > Andy suggested on IRC that there were some compression fixes which had > perhaps not been backported far enough. > > I think that's > > lz4: fix system halt at boot kernel on x86_64 > 14b62ab3e5a79816edfc6dd3afce1bb68c106ac5 > master commit: 5d90ff79542ab9c6eebe5c315c68c196bcf353b9 > > lz4: refine commit 9143a6c55ef7 for the 64-bit case > 6561994b87af3e9cd28ee99c42e8b2697621687d > master commit: 2d7572cdfa4d481c1ca246aa1ce5239ccae7eb59 > > Anyone have any objection to me sending those to 4.10 and maybe 4.9 ? > They apply cleanly in both cases. Seeing the other pieces that have been put onto these old branches recently, it's probably fine to add the two ones here as well. In general, as mentioned before, I view it as wrong to put non- security fixes onto the security-only branches. But since I can see why changes to address newer compilers' changed behavior may be wanted/needed, I guess the ones here fall into a pretty similar group. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 15 13:44:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 13:44:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpPj-0004ZR-29; Mon, 15 Jun 2020 13:44:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpPh-0004ZM-PG for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 13:44:37 +0000 X-Inumbo-ID: 59edc9f4-af0e-11ea-bca7-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 59edc9f4-af0e-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 13:44:36 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: gR2qyDqKKdvLukNS3333WdjMUNCY5Qx8IyMuFOQvmE7Y736g2SI7Vt4sYAOoyBFZcA15Xbc/Se MtZ51YV5EekUQdKumefw5rktkLMsiUhdK18MXdEl8uNKzzLi+3uSqtATi8f/Zj0ufF9GaCw7gr LTdNRyfJa9TQC7vBGIKIz8SFpwcBMKms2HyhY4WdvWsTJMwbpm0H9D/u9XHBiWWoJUqG0aOjMv DRQ2zOkg6VODx8uIdYyldUn2BUhGX86Oqc9tE5celOhbWOsAT1gG27niVLU0LEZKGeYVJliKWV mWY= X-SBRS: 2.7 X-MesageID: 20835255 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20835255" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <24295.31551.406528.629952@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 14:44:31 +0100 To: Jan Beulich , Andrew Cooper Subject: Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages] In-Reply-To: , <3c68a609-a069-f7e1-3c99-291da372df96@suse.com> References: <24291.43673.301735.439410@mariner.uk.xensource.com> <24291.45488.423085.940252@mariner.uk.xensource.com> <3c68a609-a069-f7e1-3c99-291da372df96@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , George Dunlap , "xen-devel@lists.xenproject.org" , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"): > On 12/06/2020 17:47, Ian Jackson wrote: > > Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"): > > I think that's > > > > lz4: fix system halt at boot kernel on x86_64 > > 14b62ab3e5a79816edfc6dd3afce1bb68c106ac5 > > master commit: 5d90ff79542ab9c6eebe5c315c68c196bcf353b9 > > > > lz4: refine commit 9143a6c55ef7 for the 64-bit case > > 6561994b87af3e9cd28ee99c42e8b2697621687d > > master commit: 2d7572cdfa4d481c1ca246aa1ce5239ccae7eb59 > > > > Anyone have any objection to me sending those to 4.10 and maybe 4.9 ? > > They apply cleanly in both cases. > > Ah - you found them faster than I did. Yes - these were the ones I was > thinking of. > > No objections. Thanks. Jan Beulich writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"): > Seeing the other pieces that have been put onto these old branches > recently, it's probably fine to add the two ones here as well. In > general, as mentioned before, I view it as wrong to put non- > security fixes onto the security-only branches. Yes. I can see why this is not ideal. > But since I can see why changes to address newer compilers' changed > behavior may be wanted/needed, I guess the ones here fall into a > pretty similar group. However, as a practical matter, I think it is probably a good idea to enable (i) us to test these branches with an up-to-date CI setup (ii) people to be able to build it with modern compilers. So I think in general I am saying that narrow and low-risk build fixes are reasonable backport candidates. Thanks to both for your opinions. I have pushed those two to 4.10 and will see how things go. I may send them to 4.9 too. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 13:48:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 13:48:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpTN-0004ij-Ig; Mon, 15 Jun 2020 13:48:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpTM-0004ib-93 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 13:48:24 +0000 X-Inumbo-ID: e10bee16-af0e-11ea-b7fc-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e10bee16-af0e-11ea-b7fc-12813bfff9fa; Mon, 15 Jun 2020 13:48:23 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: aBBBU2g03LugTNHfIOz64CIynLCdrXlWJMMpPaL7zydFaZpBZhwrcIBYm0d58Fihmv64Ra4L1p kNLbmx4dPMMrRI8+hT7DqT2mi6KYYFPUuscm45kxZJnX1hsbeO8LqoqC2Ms/Hx/4fq1f25SJ7N P4FeG1KLmnHOhZi0kCug61xeIYk6YiI9NkQzDTgknTDx4feMRkGro7uhIfBoIfX2YfrErHezQQ e3rmqk/yCXIiHsOlEQjiTwgviUdllzaHvHxDgiEXOyD8wyX1ttvNQXTsSg8CLqYwLmuCtDg95o 0Wc= X-SBRS: 2.7 X-MesageID: 20296205 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20296205" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.31778.201405.748753@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 14:48:18 +0100 To: Nick Rosbrook Subject: Re: [PATCH for-4.14] tools: check go compiler version if present In-Reply-To: <20200612215028.GA6286@six> References: <24291.45045.185355.587474@mariner.uk.xensource.com> <20200612215028.GA6286@six> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , "xen-devel@lists.xenproject.org" , George Dunlap , Wei Liu , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Nick Rosbrook writes ("Re: [PATCH for-4.14] tools: check go compiler version if present"): > On Fri, Jun 12, 2020 at 05:40:21PM +0100, Ian Jackson wrote: > > Nick Rosbrook writes ("[PATCH for-4.14] tools: check go compiler version if present"): > > > Currently, no minimum go compiler version is required by the configure > > > scripts. However, the go bindings actually will not build with some > > > older versions of go. Add a check for a minimum go version of 1.11.1 in > > > accordance with tools/golang/xenlight/go.mod. ... > > I don't understand this code. Why are you checking $enable_golang in > > your new code whereas the old code checks $golang ? I actually read > > the generated code trying to see where $golang is set and AFAICT it is > > only ever set to n ? > > For some background, in an attempt to be consistent with existing code > here, I basically copied the logic for enabling the ocaml tools. > > The logic is setup in a way that (unless --disable-golang is set) if a > suitable version of the go compiler is found, then golang is enabled by > default. If, however, a suitable go compiler is not found (either go > is not present at all, or it is too old), then golang is disabled. This > part happens silently unless --enable-golang is _explicitly_ set by the > user, in which case an error is thrown by ./configure. This is why > $enable_golang is checked. Thanks. Well, I have to say I still don't understand the code. But as you note, the behaviour you describe is the one I would want. And the confusingness doesn't seem to have been your fault. It would probably be worse to have two different arrangements. Let's leave it as it is for now. > > This is all very weird. Surely golang should be enabled by default > > when the proper compiler is present, and disabled by default > > otherwise. I think this effect will be quite hard to achieve with > > AX_ARG_DEFAULT_ENABLE. Probably you should be using AC_ARG_ENABLE > > and doing the defaulting yourself so that you can use a computed > > default etc. > > I believe the behavior you described here is the same as I described > above (and is acheived in this patch). But, I'm happy to re-work the > implementation if necessary so that the code is more clear. Ideally at some point maybe we would make this clearer but not now. Have you tested the situations you describe ? That might be a better way of checking that it's right than the code inspection which is obviously failing for me now... I definitely think we want to fix this for 4.14. So thanks for your continued help! Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 13:57:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 13:57:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpcJ-0005ZN-G9; Mon, 15 Jun 2020 13:57:39 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpcI-0005ZI-DJ for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 13:57:38 +0000 X-Inumbo-ID: 2b5c6530-af10-11ea-b7fc-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2b5c6530-af10-11ea-b7fc-12813bfff9fa; Mon, 15 Jun 2020 13:57:37 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /g7kB7xlQDXVDMGCY9mY1UFQfZIdY85IjVFIHsq/rKrIr4WlzRjduLm+jmYJG/oXrYNj2sdY13 ypa+3oLcrGdTAsPECN4Ox0+JvWjmG7ImBpXDEJEiLYPvwfrcNycw5d3HvOOXMkA4UdlhpDaItc esycCD4EVZyBRerwi1yQ6IAcyvt6r1xPBx35d3hLH7Ee6VdwllQ16VibiRXMKT4c5s0cPhgkGW pfdSYwLJXv7WQ7GXZGC6zF+3vAYVmGFnQabqQ/yeQtKsIuCz40B1MjZm3mY9KfjZsYD5EI2Lo1 A0s= X-SBRS: 2.7 X-MesageID: 20362233 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20362233" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.32330.508237.225844@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 14:57:30 +0100 To: Jan Beulich , "xen-devel@lists.xenproject.org" , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu Subject: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) In-Reply-To: <24291.43673.301735.439410@mariner.uk.xensource.com> References: <24291.43673.301735.439410@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"): > osstest service owner writes ("[xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved"): > > flight 151033 xen-4.10-testing real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/151033/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039 > > build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039 > > build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039 > > build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039 > > ../../../gnulib/lib/fseeko.c: In function 'rpl_fseeko': > ../../../gnulib/lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib." > #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib." > ^~~~~ > make[3]: *** [Makefile:2473: fseeko.lo] Error 1 > > http://logs.test-lab.xenproject.org/osstest/logs/151033/build-amd64-libvirt/6.ts-libvirt-build.log > > In principle maybe we could fix this by generating a private libvirt > branch with the build fixes ? Or maybe we should simply try plucking > a new version of libvirt ? We could update the pinned version in Xen > 4.10 to the one from 4.11 ? We might have to do the same for 4.9 > then. No-one has commented on this. I propose to update in http://xenbits.xen.org/gitweb/?p=libvirt.git;a=summary the refs refs/heads/osstest/frozen/xen-4.10-testing refs/heads/osstest/frozen/xen-4.9-testing from 681bc423e823ab86b20748db311721bdef20defe 981e2c70973454cad360f7c9eec2d6ded0a86747 respectively to 076a2b409667dd9f716a2a2085e1ffea9d58fe8b which is current value of refs/heads/osstest/frozen/xen-4.11-testing Both of those will be fast-forward updates. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:02:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:02:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpgW-0006Ru-1b; Mon, 15 Jun 2020 14:02:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpgU-0006Rp-GZ for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:01:58 +0000 X-Inumbo-ID: c626c48e-af10-11ea-bb8b-bc764e2007e4 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (unknown [40.107.5.83]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c626c48e-af10-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 14:01:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=43737ITja0zBaHL08O+LOoRG3LylD7T40HDB3k4aQr8=; b=3Y2FMRzRrphIgxQPeYodKdutM6Kk6LbhLoiMhEnKc/1vhWdbjN/qhCw/Iqxyf5RtkJXkFv8+fydgKgYSFnjs3TGI0bkPmqhBOt5FMhAIseAlFljzZB77aDiYl09YkbmAmddObAjbKM9o782z7KmAITq2hUVrPntK1enKFMvRjhc= Received: from AM7PR04CA0017.eurprd04.prod.outlook.com (2603:10a6:20b:110::27) by VI1PR08MB5406.eurprd08.prod.outlook.com (2603:10a6:803:133::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.22; Mon, 15 Jun 2020 14:01:54 +0000 Received: from VE1EUR03FT012.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:110:cafe::fa) by AM7PR04CA0017.outlook.office365.com (2603:10a6:20b:110::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Mon, 15 Jun 2020 14:01:54 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT012.mail.protection.outlook.com (10.152.18.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Mon, 15 Jun 2020 14:01:53 +0000 Received: ("Tessian outbound 56dbe829191e:v59"); Mon, 15 Jun 2020 14:01:53 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: afedc56cebf702d7 X-CR-MTA-TID: 64aa7808 Received: from 804de3e8dd63.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id EBBB3BC1-CCAB-4834-8F3B-57C7F8D95D87.1; Mon, 15 Jun 2020 14:01:48 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 804de3e8dd63.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 15 Jun 2020 14:01:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UIbT42Zj9AupHFtwWSprZhDVlnb9ddkj9H+tyvhF9vkRA7OPPqdw4j5nzGRi1gnPAFVaD1iJJbKGAiX1G27O9gU90oRTYGJfbqHAU/O26EIBWfhDY7pyjj77Poabuf+wXlQ2Ye5JoQQ/X+LfxZfvT1bzzfhNk96WbudPC82LB5/1w++JNKH5LB/ZoqY2/u4MFK0D6+XBXRfJ1a6sa26b4TpzN3sls1AMCYaUzDozBaJH7YBNxxnOp3aU9FdoTy8aRYjKEFCR3YMDymMxgxiN3GN3yybqmSRzVRVyiZVk+7vn4mv2kpeL6wfLJ4tqZBuZYJXa1GL3kSfiQ4N6pTBchw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=43737ITja0zBaHL08O+LOoRG3LylD7T40HDB3k4aQr8=; b=eB9/8tT/l/XnxrXY6wmT5lYPqUuRGiAcVYgsBdhKltZOggjv9rK6t3zxD5QLMBs3cYt+kgYoot7as8kHauAf/Nsv8yMFMbLMijG39hkIiVu05v9yU92W/FiwL9G5NCrMI3O0XIjsEVRN1gvBQni0k0gekRyObQMQBZK5eYpgZAffsYxrvsRJ6UChjZ4yKFP9sqS2QABW/nQxoOVHcw5Cyd9a3Rptzgx+ke1BRBYwFbCMnVqVQUxueLU1jE9kFVDU/aeMYxB0/cGE0pfvJr5FT1+b/2y23NpSBUg2IkNVHz+WFe7Zf5SixOQoUhpaCbe5xtT/UikGgG8SMQjB22yAMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=43737ITja0zBaHL08O+LOoRG3LylD7T40HDB3k4aQr8=; b=3Y2FMRzRrphIgxQPeYodKdutM6Kk6LbhLoiMhEnKc/1vhWdbjN/qhCw/Iqxyf5RtkJXkFv8+fydgKgYSFnjs3TGI0bkPmqhBOt5FMhAIseAlFljzZB77aDiYl09YkbmAmddObAjbKM9o782z7KmAITq2hUVrPntK1enKFMvRjhc= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3004.eurprd08.prod.outlook.com (2603:10a6:5:1c::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.20; Mon, 15 Jun 2020 14:01:45 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.028; Mon, 15 Jun 2020 14:01:45 +0000 From: Bertrand Marquis To: Julien Grall Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Topic: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Index: AQHWP+e0l1aGgjLKI0+XFOOVnv/iZKjUz6iAgABkF4CAAD1XAIAEShyA Date: Mon, 15 Jun 2020 14:01:45 +0000 Message-ID: References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <974bf796-d410-9dd7-9e60-873987cd8434@xen.org> <71F7AE7B-BB12-4D3B-8337-3FA6040CA632@arm.com> <2ea01884-a254-47c5-68a7-98ca77afc06b@xen.org> In-Reply-To: <2ea01884-a254-47c5-68a7-98ca77afc06b@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 59de04a6-c7ad-43f8-142e-08d81134a8ab x-ms-traffictypediagnostic: DB7PR08MB3004:|VI1PR08MB5406: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:8273; x-forefront-prvs: 04359FAD81 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: sx85KxS1jbYThNZXTBcQzZ7iAWAJjukAftZaFSBBGznO7PmLmiog33k28rhAmROFNDscOyfbhVkq85bCNBmyBYmLYhkvtelhcMtInZeJgj8f/h5Go+yhyFzDX16nf33gLxEytR5hV77SgOpspOoMz7fRVrQokq/l4oHk/y2TNmfZaf+9Y5r0ZeYinOQyhrYKzPM1BbKmRZIZpa8G3TzEftE5l43XJ4xi0KRTs6SsqvaQJGkr2oO000DfVfCJz+LU2ccmBmOoKBoUyrxweGfxXmy6sHTcQvjYgCa/OHMwbYajJkjtMML0bR1UBcToNBA9qMIKFebUB4MDAdi3lpjrNg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(346002)(376002)(136003)(5660300002)(36756003)(6916009)(66946007)(186003)(64756008)(8936002)(66476007)(6486002)(66556008)(66446008)(76116006)(26005)(8676002)(478600001)(4326008)(54906003)(71200400001)(91956017)(316002)(2906002)(33656002)(4744005)(83380400001)(86362001)(6506007)(53546011)(7416002)(2616005)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 3Xq+LhgLdaKPLln4Tp1+pHmyxs/lBxMMWF0Km8gHCHI3kMCvCZI+VqIcWccH9twfpVRNEa5M7bHjGhmSObjc7Blcw3FWgQLOeZBXzmRzuA1Th6VR1VPlPw7CFrQp26YPcjvugSadufVTnoWEX2yXaBpFxFjf5uckRT9OWyOx/lSwPNrEtM8k/d+oKh9/f0ePCCaIbEvog1KE6hky+x0o58i+ndRB7lkCmB+k7X/ZY1MRWa7JUPF9D/HqHBFoDPp4AXMIGs2IQP9gbg44ewq9ePr0RhnBpYTzrs4jHk+f4Xlcx/oqyl2duJWzHAMAZu3ww7hirYqGWP/WSX3rSTOeWF6cioV7Hj1fzVH3kE1PqtQ5fVZwoVbxEaldE1YpT1NQyx7p2G1VYk5cjj1Wf4tqizMvA9tFEesuQa4/i4HQ4CIn9u3M1XcMOEk3HVvDzGf3Alj/HlAjrDQKrmeLgYVaLmvySz7AR8jCnsJFghxPGj0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3004 Original-Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT012.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(136003)(376002)(46966005)(82310400002)(70586007)(5660300002)(86362001)(83380400001)(6862004)(70206006)(36906005)(36756003)(336012)(54906003)(8936002)(6506007)(53546011)(316002)(478600001)(2616005)(47076004)(82740400003)(356005)(186003)(33656002)(26005)(81166007)(4326008)(2906002)(107886003)(6486002)(8676002)(6512007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 9e6c0cb8-1b6f-44b4-9ddf-08d81134a3f2 X-Forefront-PRVS: 04359FAD81 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Scox1VTTytRTgMACe8OA+15R+qw5Wq/j/zX7wgYyRXV1iGq8jmQS37zpzQKLydohO40iZkZGsOX1zLla3dEp2o7A9Z1n+O5C37r0RGq4y1jfXjz7Im6s1y9OqxI6SWwuWsD93ijBd388yCYg66SlLKhFgyVu5sepjlV2rmllq8F6xEaWTIzfLdnEVeyAxT+XnvtTM9ahWAZi6FktKEau/pSIlsRctYdMPul4s2wx0ggDdW2OO86G20t4SjQI8bIyzUtErJJ3EzT6FVKE8M+UlgE9CSCfLcCLyOEKl2Kyb/teRMoSY1H2w5gDQkmn3jMa6xHAQ9/h1PEUytAHmjn2Cn/R0OvBfMNZEFlIA65KY3MWcjHlmlutUnAdUiPpbLWcKMXhsb+b0rnjsF4T2gvXOQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2020 14:01:53.7261 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 59de04a6-c7ad-43f8-142e-08d81134a8ab X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5406 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On 12 Jun 2020, at 21:31, Julien Grall wrote: >=20 >=20 >=20 > On 12/06/2020 17:51, Bertrand Marquis wrote: >=20 > Hi, >=20 >>>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain= .h >>>> index 4e2f582006..3a7f53e13d 100644 >>>> --- a/xen/include/asm-arm/domain.h >>>> +++ b/xen/include/asm-arm/domain.h >>>> @@ -11,6 +11,7 @@ >>>> #include >>>> #include >>>> #include >>>> +#include >>>=20 >>> Why do you need to add this new include? >> Sorry I forgot to answer to this one. >> This is needed to have the definition of vcpu_register_runstate_memory_a= rea. >=20 > I might be missing something because nothing you have added this header s= eem to require vcpu_register_runstate_memory_area. So should the include be= done in a different header? Right. This was required before when I had the definitions of the interface per ar= ch to have a static inline for x86. This is not needed and I will remove that include. Cheers Bertrand From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:04:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:04:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpj7-0006aH-G5; Mon, 15 Jun 2020 14:04:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpj6-0006ZX-CY for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:04:40 +0000 X-Inumbo-ID: 26859f30-af11-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 26859f30-af11-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 14:04:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 85ACEACE1; Mon, 15 Jun 2020 14:04:41 +0000 (UTC) Subject: Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages] To: Ian Jackson References: <24291.43673.301735.439410@mariner.uk.xensource.com> <24291.45488.423085.940252@mariner.uk.xensource.com> <3c68a609-a069-f7e1-3c99-291da372df96@suse.com> <24295.31551.406528.629952@mariner.uk.xensource.com> From: Jan Beulich Message-ID: <3849058f-32db-2294-6aa6-c8f829571f4b@suse.com> Date: Mon, 15 Jun 2020 16:04:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24295.31551.406528.629952@mariner.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , George Dunlap , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 15:44, Ian Jackson wrote: > Thanks to both for your opinions. I have pushed those two to 4.10 and > will see how things go. I may send them to 4.9 too. Won't 4.10 continue to be blocked then because or -prev issues? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:07:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:07:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkplj-0006hP-UA; Mon, 15 Jun 2020 14:07:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkplj-0006hI-F1 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:07:23 +0000 X-Inumbo-ID: 877fdd64-af11-11ea-b7bb-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 877fdd64-af11-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 14:07:22 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: kaEaQlfDnEA6486OL4gyF5vpHFV0EcEVq4roblVPlWPQ0fuNyCzmpUHvv1TYpwYQ7tIeb1hOSV RLvG/AR3p/4CxQyClDIZtjGOxycgAjznOygfKzWe3I1EN+cRSDi7rTgnnVhjCjGnVr8+o3Mbyb x+VDG+ayVqUKRkVF5+pH3MPjV0Pa/vqWFk1sDjKqWAf0lC6gAPpJiPe6uJpq8lz5AIPkjQW+ct AHb/+vBZvzjdEde4RZlIrhJCOI45gyijb9VWzVCYWAXRXXgXBZMeYjQFaU22yE8oy5gYg9o42F U34= X-SBRS: 2.7 X-MesageID: 20363608 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20363608" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <24295.32909.686801.47956@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:07:09 +0100 To: "paul@xen.org" Subject: RE: [PATCH] tools/libxengnttab: correct size of allocated memory In-Reply-To: <00f701d64009$c2c10000$48430000$@xen.org> References: <20200520083501.31704-1-jgross@suse.com> <24261.17303.413916.29534@mariner.uk.xensource.com> <20200520155621.GN54375@Air-de-Roger> <05eac1e1-63a3-1d03-9f91-d0ffdcc44f23@suse.com> <00f701d64009$c2c10000$48430000$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?iso-8859-1?Q?'J=FCrgen_Gro=DF'?= , "xen-devel@lists.xenproject.org" , 'Wei Liu' , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: [PATCH] tools/libxengnttab: correct size of allocated memory"): > > -----Original Message----- > > From: Xen-devel On Behalf Of Jrgen Gro > > Sent: 11 June 2020 16:26 > > To: Roger Pau Monn ; Ian Jackson > > Cc: xen-devel@lists.xenproject.org; Wei Liu > > Subject: Re: [PATCH] tools/libxengnttab: correct size of allocated memory > > > > On 20.05.20 17:56, Roger Pau Monn wrote: > > > On Wed, May 20, 2020 at 03:49:59PM +0100, Ian Jackson wrote: > > >> Juergen Gross writes ("[PATCH] tools/libxengnttab: correct size of allocated memory"): > > >>> The size of the memory allocated for the IOCTL_GNTDEV_MAP_GRANT_REF > > >>> ioctl() parameters is calculated wrong, which results in too much > > >>> memory allocated. > > >> > > >> Added Roger to CC. > > >> > > >> Firstly, > > >> > > >> Reviewed-by: Ian Jackson > > > > > > For the FreeBSD bits: > > > > > > Reviewed-by: Roger Pau Monn > > > > Any reason the patch didn't go in yet? > > > > I'd be quite happy for this to go in now, consider it > > Release-acked-by: Paul Durrant Thanks. I tried to apply this but it doesn't seem to apply to staging. Jrgen, would you care to rebase/resend ? Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:08:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:08:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpmi-0006oI-Bg; Mon, 15 Jun 2020 14:08:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpmg-0006o8-U2 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:08:22 +0000 X-Inumbo-ID: ab822c80-af11-11ea-b801-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ab822c80-af11-11ea-b801-12813bfff9fa; Mon, 15 Jun 2020 14:08:22 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: lieO5Y8i65c0oah4+P+E4mknepjfEoGWRztKuKEU9q/BbL8YNCpUJQVJyeBwdCc/DSbbLcKHN6 uRMFuf3EZYOddQa3vaPwJEboteqDodNm1aD7ckukIytTk0HY6HUkTFR4rvmI3nDm6Aov5SnKPc idfd7/TU7pztonbTlgE+aQC4SWbyfMRLs1tgDnChC/2hEfmZ3pt4deJxHsUQt7lkxKVueAXOSb RBS1ypWYxSYiaMNMZ0JoXQDZHpLI0VQQ21auJxkdPJGZaJ/cpTLLmy69RGhj48rE6IKLj79fH5 RTU= X-SBRS: 2.7 X-MesageID: 20363760 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20363760" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.32975.664225.928516@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:08:15 +0100 To: Jan Beulich Subject: Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages] In-Reply-To: <3849058f-32db-2294-6aa6-c8f829571f4b@suse.com> References: <24291.43673.301735.439410@mariner.uk.xensource.com> <24291.45488.423085.940252@mariner.uk.xensource.com> <3c68a609-a069-f7e1-3c99-291da372df96@suse.com> <24295.31551.406528.629952@mariner.uk.xensource.com> <3849058f-32db-2294-6aa6-c8f829571f4b@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , George Dunlap , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jan Beulich writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]"): > On 15.06.2020 15:44, Ian Jackson wrote: > > Thanks to both for your opinions. I have pushed those two to 4.10 and > > will see how things go. I may send them to 4.9 too. > > Won't 4.10 continue to be blocked then because or -prev issues? There are multiple issues. My hope is to get rid of all of them... Eventually I think we will have to force push 4.9 because its prev builds will fail and won't want to update 4.8. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:09:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:09:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpnv-0006uq-MW; Mon, 15 Jun 2020 14:09:39 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpnt-0006ui-Nm for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:09:37 +0000 X-Inumbo-ID: d81ae8b8-af11-11ea-b801-12813bfff9fa Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown [40.107.7.84]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d81ae8b8-af11-11ea-b801-12813bfff9fa; Mon, 15 Jun 2020 14:09:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=quv6W6xWEea6OAdOmQANiiOhCg9pSEvOjFb0PBq3SYY=; b=DbrdWq2XbCEth9JxifTHtV8UfOiZxB/X7IyN+SmIHW5+ykaI57N9x4W0CPQMq/FMSucvQ8Wk4lavRg1AVRr7oKhRRDJJVvje3RRt93vvBq8dT4zUGIaeY7vkKLZuoATX9wcPoiTV0vNx73QUbrA+FaPWoddG81FTaRMbCbYQ3pM= Received: from AM6PR08CA0047.eurprd08.prod.outlook.com (2603:10a6:20b:c0::35) by VI1PR08MB3566.eurprd08.prod.outlook.com (2603:10a6:803:81::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.24; Mon, 15 Jun 2020 14:09:34 +0000 Received: from AM5EUR03FT010.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:c0:cafe::4c) by AM6PR08CA0047.outlook.office365.com (2603:10a6:20b:c0::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Mon, 15 Jun 2020 14:09:34 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT010.mail.protection.outlook.com (10.152.16.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Mon, 15 Jun 2020 14:09:33 +0000 Received: ("Tessian outbound 3e82c366635e:v59"); Mon, 15 Jun 2020 14:09:33 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 7cfaea07e978a1af X-CR-MTA-TID: 64aa7808 Received: from c49ba98c9300.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 769075FC-3119-4A26-B106-82907FBE62F9.1; Mon, 15 Jun 2020 14:09:28 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c49ba98c9300.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 15 Jun 2020 14:09:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L7nKtNZ4XfDMkutfuVwiIRx69K8rg2vBHWzfn/KVPFJJAWONLjldAP0Uy1yJsvNqUWwE6nDWzk8GCCOlubALXLZWIDqILeR7IZiAAQ3OWbmwRGVpRz90Hqfd0R0/vtxi3/np29QAwVyfghSGnX45ufYDhZPQ/zE7po29N2uMrNcAw2M4FK5pszhFlRKOVKbI8Hc/hCPy2vtBH4SCaH8CSZbJsqs244xYpkTtT56et2HpNrEntNyqer2p+eKQynA6qGgZnLFzyNOEMkdYlWeM3ULHfvE3M0fhs0a1Whwwswu17wmR/5hS4lRug+bIq/VshSmkmK+pOeanjc6KrDAT4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=quv6W6xWEea6OAdOmQANiiOhCg9pSEvOjFb0PBq3SYY=; b=m8Hvzq4b7hgTYxDCL0OqwBD88CIwDcbNAwgiA8iK0Mn8vFrRYf7NZMuZXn+2CotI2NagAat9TqWX66/BSzv6Ukv0Ag6O+hkaW5HB64He62C12zjPqVABay6in0r5tvS78bEuwWmBlUv2iutKwY1i90eexz4bEKvdrq+ygFyUzZg6BLxgJZ7L91ocprUthNXfquhE+e1+XNPh4Zj5Qn5PcBQb4ULhufIDV8J8iH9+5/Vq3t8krVDOQg0Lr8F30gjwTFl+ZQ4lWI/ZUUUEWwTEcDX3gKijR+dYvEf6CpUNm7BgsrTNaTWwxNYnGpBPIt7Exleef9pUYpMLHuoBQX/dtQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=quv6W6xWEea6OAdOmQANiiOhCg9pSEvOjFb0PBq3SYY=; b=DbrdWq2XbCEth9JxifTHtV8UfOiZxB/X7IyN+SmIHW5+ykaI57N9x4W0CPQMq/FMSucvQ8Wk4lavRg1AVRr7oKhRRDJJVvje3RRt93vvBq8dT4zUGIaeY7vkKLZuoATX9wcPoiTV0vNx73QUbrA+FaPWoddG81FTaRMbCbYQ3pM= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3388.eurprd08.prod.outlook.com (2603:10a6:10:41::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.26; Mon, 15 Jun 2020 14:09:25 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.028; Mon, 15 Jun 2020 14:09:25 +0000 From: Bertrand Marquis To: Stefano Stabellini Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Topic: [PATCH 1/2] xen/arm: Convert runstate address during hypcall Thread-Index: AQHWP+e0l1aGgjLKI0+XFOOVnv/iZKjTuR6AgAACMICAAActAIAADWwAgABcfQCAAHaFAIABD0cAgAQLJQA= Date: Mon, 15 Jun 2020 14:09:25 +0000 Message-ID: <0D644096-05E3-44F3-A1FD-75006C718F23@arm.com> References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> <48F66B8F-3AEF-4E54-A572-C246F5A7C117@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d92da315-3ca5-45ec-5aa0-08d81135bae2 x-ms-traffictypediagnostic: DB7PR08MB3388:|VI1PR08MB3566: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04359FAD81 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: OI+/DdvJqOMY9BGNfRTYbm4lrwYqnv1WxRBKwu9HYdjB1id/rowDPL2ejNo1e6r/hHYXrYvr229ouOSNnuuLVb9N8hbcSU3TZ3qhGnNE68vtAhWpbUBDoNw9o9hUkN10JXIpivaI6GgERTAIv4Nxpainm65lcZZu5/XPGB/WblVFma2w38MHxHQplv6DXrwYsoiHoSA22uQnszednBmGged/PCVKWlNDHSkEOx7h8avvSCUqLTTuj5HfnDBnvosQ7qxEYSyCftyJS/b0w2ENht3SxkzNrZmHqtY4fgjfpaMWUOcLHoEMrrMeoucqCEJtEZr4RkLj85Hd4q0hjZBeQlPPKqadHzN46KYe1s2a/WyOuibIpn0rM8Njgg5dp/i3 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(396003)(346002)(136003)(376002)(478600001)(6512007)(5660300002)(2906002)(91956017)(66946007)(4326008)(66556008)(54906003)(7416002)(76116006)(83380400001)(66476007)(316002)(64756008)(66446008)(71200400001)(86362001)(6486002)(53546011)(26005)(8676002)(6506007)(186003)(6916009)(36756003)(33656002)(8936002)(2616005)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: lyO21IKMrgQl5XufDntT3kcYPl23fD2sdi3IjH6ChW7ka/VaFAJzzmrIybKUdgze1IAuo7UjhZsNVBhOr5ZwifgKCiujM8gxxSMrIQE0AnIVTxigEavpKuOxd0430X48uuCIW5jbNyStcUnbvQ9skenZcbUTJiYByHd3oDvN/Ksn1Eb0TJNiol/Rt12wqLC52ZpAZ3t9/p9/C+l1oROhsvdWC2yvvyXkr1BRdWeomndexgZmKU1vn/3QH43oOqMKp4VJLzrOme9k1qs+zKpPeEFE1xSw/mdEvGoF6496zjyHT3L4691eHcolcHX5Natmqaym8DVCz45iKFP8puabx0Py40JBqiKDR85pGFj5xDPxZj8qrhHhwEkDFTX3a1xVPqor+sBuNwe2gdRV4spLfVgzxMjTknesnvcHkhNES7ZjhkP/UZe+LZdSZLNhY37H4juCjzr5Tnrc03aMcRiMirZB25GQ4OrVbiMAUj5U2L8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3388 Original-Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT010.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(376002)(346002)(136003)(46966005)(82740400003)(2906002)(478600001)(5660300002)(81166007)(186003)(356005)(4326008)(54906003)(47076004)(86362001)(36756003)(70206006)(8676002)(70586007)(6512007)(53546011)(6506007)(316002)(36906005)(82310400002)(6862004)(33656002)(83380400001)(2616005)(107886003)(336012)(8936002)(26005)(6486002)(21314003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: e014153a-8cb9-4b27-d97e-08d81135b5e1 X-Forefront-PRVS: 04359FAD81 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: z2OiVT4iPNEF9e/p3sk3Pnagm1D5jRqScFo/zqVsTxAY8d5/yZ6c1Rum9QRFGNbwHsZeMcX4PXxPJjiQE5MQszxljRRae1fplP125xfowKa6qi3o+ymp00TqDllRPrZlHzV5ETopYpObpkrwypghu9OsHT3Wi6UojNoopeNJa1VOCbF/tfuAmPgV7n5IT6xeZcL0xtalq5qTq51cElpNuLMFAuVSm8x3mT8C3UklDEB8VTY5ILNzmvP+dGlKFDAp0UStlQ3uCPhy3W8Tn+qhroisu8GJAGfJE6Q/elvth1emQjCgavIvwMfT5mULSXwvUBorv4Dv+zuCxGBgXha49UtaWo1WPPLUfPzOKYBnFnAD3PWWlCyLgXguH/ch4W86KgYKKaTIVozMZ9sKYLYyqeyAeqd/y0dj90l+zi64IbY= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2020 14:09:33.8550 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d92da315-3ca5-45ec-5aa0-08d81135bae2 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3566 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gMTMgSnVuIDIwMjAsIGF0IDAxOjI0LCBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFi ZWxsaW5pQGtlcm5lbC5vcmc+IHdyb3RlOg0KPiANCj4gT24gRnJpLCAxMiBKdW4gMjAyMCwgQmVy dHJhbmQgTWFycXVpcyB3cm90ZToNCj4+PiBPbiAxMiBKdW4gMjAyMCwgYXQgMDI6MDksIFN0ZWZh bm8gU3RhYmVsbGluaSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4gd3JvdGU6DQo+Pj4gDQo+Pj4g T24gVGh1LCAxMSBKdW4gMjAyMCwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPj4+PiBIaSBTdGVmYW5v LA0KPj4+PiANCj4+Pj4gT24gMTEvMDYvMjAyMCAxOTo1MCwgU3RlZmFubyBTdGFiZWxsaW5pIHdy b3RlOg0KPj4+Pj4gT24gVGh1LCAxMSBKdW4gMjAyMCwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPj4+ Pj4+Pj4gKyAgICAgICAgcmV0dXJuIC1FSU5WQUw7DQo+Pj4+Pj4+PiAgICAgfQ0KPj4+Pj4+Pj4g DQo+Pj4+Pj4+PiAtICAgIF9fY29weV90b19ndWVzdChydW5zdGF0ZV9ndWVzdCh2KSwgJnJ1bnN0 YXRlLCAxKTsNCj4+Pj4+Pj4+ICsgICAgdi0+YXJjaC5ydW5zdGF0ZV9ndWVzdC5wYWdlID0gcGFn ZTsNCj4+Pj4+Pj4+ICsgICAgdi0+YXJjaC5ydW5zdGF0ZV9ndWVzdC5vZmZzZXQgPSBvZmZzZXQ7 DQo+Pj4+Pj4+PiArDQo+Pj4+Pj4+PiArICAgIHNwaW5fdW5sb2NrKCZ2LT5hcmNoLnJ1bnN0YXRl X2d1ZXN0LmxvY2spOw0KPj4+Pj4+Pj4gKw0KPj4+Pj4+Pj4gKyAgICByZXR1cm4gMDsNCj4+Pj4+ Pj4+ICt9DQo+Pj4+Pj4+PiArDQo+Pj4+Pj4+PiArDQo+Pj4+Pj4+PiArLyogVXBkYXRlIHBlci1W Q1BVIGd1ZXN0IHJ1bnN0YXRlIHNoYXJlZCBtZW1vcnkgYXJlYSAoaWYgcmVnaXN0ZXJlZCkuDQo+ Pj4+Pj4+PiAqLw0KPj4+Pj4+Pj4gK3N0YXRpYyB2b2lkIHVwZGF0ZV9ydW5zdGF0ZV9hcmVhKHN0 cnVjdCB2Y3B1ICp2KQ0KPj4+Pj4+Pj4gK3sNCj4+Pj4+Pj4+ICsgICAgc3RydWN0IHZjcHVfcnVu c3RhdGVfaW5mbyAqZ3Vlc3RfcnVuc3RhdGU7DQo+Pj4+Pj4+PiArICAgIHZvaWQgKnA7DQo+Pj4+ Pj4+PiArDQo+Pj4+Pj4+PiArICAgIHNwaW5fbG9jaygmdi0+YXJjaC5ydW5zdGF0ZV9ndWVzdC5s b2NrKTsNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gLSAgICBpZiAoIGd1ZXN0X2hhbmRsZSApDQo+Pj4+ Pj4+PiArICAgIGlmICggdi0+YXJjaC5ydW5zdGF0ZV9ndWVzdC5wYWdlICkNCj4+Pj4+Pj4+ICAg ICB7DQo+Pj4+Pj4+PiAtICAgICAgICBydW5zdGF0ZS5zdGF0ZV9lbnRyeV90aW1lICY9IH5YRU5f UlVOU1RBVEVfVVBEQVRFOw0KPj4+Pj4+Pj4gKyAgICAgICAgcCA9IF9fbWFwX2RvbWFpbl9wYWdl KHYtPmFyY2gucnVuc3RhdGVfZ3Vlc3QucGFnZSk7DQo+Pj4+Pj4+PiArICAgICAgICBndWVzdF9y dW5zdGF0ZSA9IHAgKyB2LT5hcmNoLnJ1bnN0YXRlX2d1ZXN0Lm9mZnNldDsNCj4+Pj4+Pj4+ICsN Cj4+Pj4+Pj4+ICsgICAgICAgIGlmICggVk1fQVNTSVNUKHYtPmRvbWFpbiwgcnVuc3RhdGVfdXBk YXRlX2ZsYWcpICkNCj4+Pj4+Pj4+ICsgICAgICAgIHsNCj4+Pj4+Pj4+ICsgICAgICAgICAgICB2 LT5ydW5zdGF0ZS5zdGF0ZV9lbnRyeV90aW1lIHw9IFhFTl9SVU5TVEFURV9VUERBVEU7DQo+Pj4+ Pj4+PiArICAgICAgICAgICAgZ3Vlc3RfcnVuc3RhdGUtPnN0YXRlX2VudHJ5X3RpbWUgfD0gWEVO X1JVTlNUQVRFX1VQREFURTsNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEkgdGhpbmsgdGhhdCB0aGlzIHdy aXRlIHRvIGd1ZXN0X3J1bnN0YXRlIHNob3VsZCB1c2Ugd3JpdGVfYXRvbWljIG9yDQo+Pj4+Pj4+ IGFub3RoZXIgYXRvbWljIHdyaXRlIG9wZXJhdGlvbi4NCj4+Pj4+PiANCj4+Pj4+PiBJIHRob3Vn aHQgYWJvdXQgc3VnZ2VzdGluZyB0aGUgc2FtZSwgYnV0ICBndWVzdF9jb3B5XyogaGVscGVycyBt YXkgbm90DQo+Pj4+Pj4gZG8gYSBzaW5nbGUgbWVtb3J5IHdyaXRlIHRvIHN0YXRlX2VudHJ5X3Rp bWUuDQo+Pj4+Pj4gV2hhdCBhcmUgeW91IHRyeWluZyB0byBwcmV2ZW50IHdpdGggdGhlIHdyaXRl X2F0b21pYygpPw0KPj4+Pj4gDQo+Pj4+PiBJIGFtIHRoaW5raW5nIHRoYXQgd2l0aG91dCB1c2lu ZyBhbiBhdG9taWMgd3JpdGUsIGl0IHdvdWxkIGJlIChhdCBsZWFzdA0KPj4+Pj4gdGhlb3JldGlj YWxseSkgcG9zc2libGUgZm9yIGEgZ3Vlc3QgdG8gc2VlIGEgcGFydGlhbCB3cml0ZSB0bw0KPj4+ Pj4gc3RhdGVfZW50cnlfdGltZSwgd2hpY2ggaXMgbm90IGdvb2QuIA0KPj4+PiANCj4+Pj4gSXQg aXMgYWxyZWFkeSB0aGUgY2FzZSB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9uIGFzIFhlbiBt YXkgd3JpdGUgYnl0ZSBieQ0KPj4+PiBieXRlLiBTbyBhcmUgeW91IHN1Z2dlc3RpbmcgdGhlIGV4 aXN0aW5nIGNvZGUgaXMgYWxzbyBidWdneT8NCj4+PiANCj4+PiBXcml0aW5nIGJ5dGUgYnkgYnl0 ZSBpcyBhIGRpZmZlcmVudCBjYXNlLiBUaGF0IGlzIE9LLiBJbiB0aGF0IGNhc2UsIHRoZQ0KPj4+ IGd1ZXN0IGNvdWxkIHNlZSB0aGUgc3RhdGUgYWZ0ZXIgMyBieXRlcyB3cml0dGVuIGFuZCBpdCB3 b3VsZCBiZSBmaW5lIGFuZA0KPj4+IGNvbnNpc3RlbnQuIElmIHRoaXMgaGFkbid0IGJlZW4gdGhl IGNhc2UsIHRoZW4geWVzLCB0aGUgZXhpc3RpbmcgY29kZQ0KPj4+IHdvdWxkIGFsc28gYmUgYnVn Z3kuDQo+Pj4gDQo+Pj4gU28gaWYgd2UgZGlkIHRoZSB3cml0ZSB3aXRoIGEgbWVtY3B5LCBpdCB3 b3VsZCBiZSBmaW5lLCBubyBuZWVkIGZvcg0KPj4+IGF0b21pY3M6DQo+Pj4gDQo+Pj4gbWVtY3B5 KCZndWVzdF9ydW5zdGF0ZS0+c3RhdGVfZW50cnlfdGltZSwNCj4+PiAgICAgICAgJnYtPnJ1bnN0 YXRlLnN0YXRlX2VudHJ5X3RpbWUsDQo+Pj4gICAgICAgIFhYWCk7DQo+Pj4gDQo+Pj4gDQo+Pj4g VGhlIHw9IGNhc2UgaXMgZGlmZmVyZW50OiBHQ0MgY291bGQgaW1wbGVtZW50IGl0IGluIGFueSB3 YXkgaXQgbGlrZXMsDQo+Pj4gaW5jbHVkaW5nIGdvaW5nIHRocm91Z2ggYSB6ZXJvLXdyaXRlIHRv IGFueSBvZiB0aGUgYnl0ZXMgaW4gdGhlIHdvcmQsIG9yDQo+Pj4gZG9pbmcgYW4gYWRkaXRpb24g dGhlbiBhIHN1YnRyYWN0aW9uLiBHQ0MgZG9lc24ndCBtYWtlIGFueSBndWFyYW50ZWVzLg0KPj4+ IElmIHdlIHdhbnQgZ3VhcmFudGVlcyB3ZSBuZWVkIHRvIHVzZSBhdG9taWNzLg0KPj4gDQo+PiBX b3VsZG7igJl0IHRoYXQgcmVxdWlyZSBhbGwgYWNjZXNzZXMgdG8gc3RhdGVfZW50cnlfdGltZSB0 byB1c2UgYWxzbyBhdG9taWMgb3BlcmF0aW9ucyA/DQo+PiBJbiB0aGlzIGNhc2Ugd2UgY291bGQg bm90IHByb3BhZ2F0ZSB0aGUgY2hhbmdlcyB0byBhIGd1ZXN0IHdpdGhvdXQgY2hhbmdpbmcgdGhl IGludGVyZmFjZSBpdHNlbGYuDQo+PiANCj4+IEFzIHRoZSBjb3B5IHRpbWUgbmVlZHMgdG8gYmUg cHJvdGVjdGVkLCB0aGUgd3JpdGUgYmFycmllcnMgYXJlIHRoZXJlIHRvIG1ha2Ugc3VyZSB0aGF0 IGR1cmluZyB0aGUgY29weSB0aGUgYml0IGlzIHNldCBhbmQgdGhhdCB3aGVuIHdlIHVuc2V0IGl0 LCB0aGUgY29weSBpcyBkb25lLg0KPj4gSSBhZGRlZCBmb3IgdGhpcyBwdXJwb3NlIGEgYmFycmll ciBhZnRlciB0aGUgbWVtY3B5IHRvIG1ha2Ugc3VyZSB0aGF0IHdoZW4vaWYgd2UgdW5zZXQgdGhl IGJpdCB0aGUgY29weSBoYXMgYWxyZWFkeSBiZWVuIGRvbmUuDQo+IA0KPiBBcyB5b3Ugc2F5LCB3 ZSBoYXZlIGEgZmxhZyB0byBtYXJrIGEgdHJhbnNpdGlvbmcgcGVyaW9kLCB0aGUgZmxhZyBpcw0K PiBYRU5fUlVOU1RBVEVfVVBEQVRFLiBTbywgSSB0aGluayBpdCBpcyBPSyBpZiB3ZSBkb24ndCB1 c2UgYXRvbWljcyBkdXJpbmcNCj4gdGhlIHRyYW5zaXRpb25pbmcgcGVyaW9kLiBCdXQgd2UgbmVl ZCB0byBtYWtlIHN1cmUgdG8gdXNlIGF0b21pY3MgZm9yIHRoZQ0KPiB1cGRhdGUgb2YgdGhlIFhF Tl9SVU5TVEFURV9VUERBVEUgZmxhZyBpdHNlbGYuDQo+IA0KPiBEb2VzIGl0IG1ha2Ugc2Vuc2U/ IE9yIG1heWJlIEkgbWlzdW5kZXJzdG9vZCBzb21lIG9mIHRoZSB0aGluZ3MgeW91DQo+IHdyb3Rl Pw0KDQpUbyBhY2hpZXZlIHRoaXMgeW91IHdvdWxkIGRvIGFuIGF0b21pYyBvcGVyYXRpb24gb24g c3RhdGVfZW50cnlfdGltZSB0byBzZXQvdW5zZXQgdGhlIFhFTl9SVU5TVEFURV9VUERBVEUgYml0 Lg0KVGhpcyBmaWVsZCBpcyBob2xkaW5nIGEgZmxhZyBpbiB0aGUgdXBwZXIgYml0IGJ1dCBhbHNv IGEgdmFsdWUsIHNvIGFsbCBvcGVyYXRpb25zIG9uIHN0YXRlX2VudHJ5X3RpbWUgd291bGQgbmVl ZCB0byBiZSBjaGFuZ2VkIHRvIHVzZSBhdG9taWMgb3BlcmF0aW9ucy4NCg0KQWxzbyB0aGlzIHN0 YXRlX2VudHJ5X3RpbWUgbWlnaHQgYWxzbyBiZSBhY2Nlc3NlZCBieSB0aGUgZ3Vlc3Qgb24gb3Ro ZXIgY29yZXMgYXQgdGhlIHNhbWUgdGltZSAodG8gcmV0cmlldmUgdGhlIHRpbWUgcGFydCkuDQoN ClRvIHByZXZlbnQgc29tZXRoaW5nIGJlaW5nIHVzZWQgYXMgYXRvbWljIGFuZCBub24gYXRvbWlj LCBzcGVjaWZpYyB0eXBlcyBhcmUgdXN1YWxseSB1c2VkIChhdG9taWNfdCkgYW5kIHRoaXMgc3Ry dWN0dXJlIGlzIGFsc28gdXNlZCBieSBndWVzdHMgc28gbW9kaWZ5aW5nIGl0IHdpbGwgbm90IGJl IGVhc3kuDQoNCk9yIGRpZCBJIG1pc3N1bmRlcnN0b29kIHNvbWV0aGluZyBoZXJlID8NCg0KUmVn YXJkcw0KQmVydHJhbmQNCg0KDQoNCg0K From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:09:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:09:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpo8-0006x7-VQ; Mon, 15 Jun 2020 14:09:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpo8-0006wu-1e for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:09:52 +0000 X-Inumbo-ID: e08fa592-af11-11ea-b7bb-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e08fa592-af11-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 14:09:50 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 40QYEQMnH06bZqtcGpCUHOoUd7xprwS42/gkbBBMAILWJBQxcsZ4ryY196SZADlxSZoe8k7/e5 DeM50SZaOYWrS6jSIiyXZFX3IKnd3DO7O+8SxCMFvZwirNgq0THj+KcV8KvKQe7GEYQUJcETR3 xMIwLATFniWs57iOD4krN8ZGRdubDu0zHJEOt0IQFxD/0k8rRh0uh2XyukvJnNlciHF7H0j1eR hP6YSzZarEWINiTbA1l7n9uYrwU3BUf55oHtHZvNWykHBsNzb7jVmrvqQBHxKW4DhxIjfiQRxf +yg= X-SBRS: 2.7 X-MesageID: 20409564 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20409564" Subject: Re: [PATCH] tools/libxengnttab: correct size of allocated memory To: Ian Jackson , "paul@xen.org" References: <20200520083501.31704-1-jgross@suse.com> <24261.17303.413916.29534@mariner.uk.xensource.com> <20200520155621.GN54375@Air-de-Roger> <05eac1e1-63a3-1d03-9f91-d0ffdcc44f23@suse.com> <00f701d64009$c2c10000$48430000$@xen.org> <24295.32909.686801.47956@mariner.uk.xensource.com> From: Andrew Cooper Message-ID: Date: Mon, 15 Jun 2020 15:09:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <24295.32909.686801.47956@mariner.uk.xensource.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?J0rDvHJnZW4gR3Jvw58n?= , "xen-devel@lists.xenproject.org" , 'Wei Liu' , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15/06/2020 15:07, Ian Jackson wrote: > Paul Durrant writes ("RE: [PATCH] tools/libxengnttab: correct size of allocated memory"): >>> -----Original Message----- >>> From: Xen-devel On Behalf Of Jürgen Groß >>> Sent: 11 June 2020 16:26 >>> To: Roger Pau Monné ; Ian Jackson >>> Cc: xen-devel@lists.xenproject.org; Wei Liu >>> Subject: Re: [PATCH] tools/libxengnttab: correct size of allocated memory >>> >>> On 20.05.20 17:56, Roger Pau Monné wrote: >>>> On Wed, May 20, 2020 at 03:49:59PM +0100, Ian Jackson wrote: >>>>> Juergen Gross writes ("[PATCH] tools/libxengnttab: correct size of allocated memory"): >>>>>> The size of the memory allocated for the IOCTL_GNTDEV_MAP_GRANT_REF >>>>>> ioctl() parameters is calculated wrong, which results in too much >>>>>> memory allocated. >>>>> Added Roger to CC. >>>>> >>>>> Firstly, >>>>> >>>>> Reviewed-by: Ian Jackson >>>> For the FreeBSD bits: >>>> >>>> Reviewed-by: Roger Pau Monné >>> Any reason the patch didn't go in yet? >>> >> I'd be quite happy for this to go in now, consider it >> >> Release-acked-by: Paul Durrant > Thanks. I tried to apply this but it doesn't seem to apply to > staging. Jürgen, would you care to rebase/resend ? I already committed it, seeing as it was fully acked. https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=aad20e538d7ba0e36f5ed8d2bebb74096e3a6d7f ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:15:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:15:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpu2-0007rJ-15; Mon, 15 Jun 2020 14:15:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpu0-0007r6-J6 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:15:56 +0000 X-Inumbo-ID: b9c24fe0-af12-11ea-b801-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b9c24fe0-af12-11ea-b801-12813bfff9fa; Mon, 15 Jun 2020 14:15:55 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Cu6wRtIKUxbfA+SASgGLv5eUG0SxnSpIjVacZ6OtwFV4F0RbLAW+psJUueV6Jou3w6iMeCBwFo YLki+Un47YVfO0rixgihdqXVtmUF/PgnMYvUMNs7guNvoROf6vMjE8rcSHh9SKoF0IcYHsO22C KcbXu2oLXZMKWWF4eQsJEkJmwGIi7qFrIJO0e/XTsRjFN0lvc+IfB4DIBBJY0R4UT0dX5n6Q0r cFfRfY0VZbsmPIEgmp3LGrjUcpMUiCE1T4dMwFxf29C8Mvf26QpeJkMx5Gx2jNMh1jwxD/OlM6 Cb0= X-SBRS: 2.7 X-MesageID: 20064841 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20064841" From: Andrew Cooper To: Xen-devel Subject: [PATCH 3/9] tools/libx[cl]: Move processing loop down into xc_cpuid_set() Date: Mon, 15 Jun 2020 15:15:26 +0100 Message-ID: <20200615141532.1927-4-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Ian Jackson , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Currently, libxl__cpuid_legacy() passes each element of the policy list to xc_cpuid_set() individually. This is wasteful both in terms of the number of hypercalls made, and the quantity of repeated merging/auditing work performed by Xen. Move the loop processing down into xc_cpuid_set(), which allows us to do one set of hypercalls, rather than one per list entry. In xc_cpuid_set(), obtain the full host, guest max and current policies to begin with, and loop over the xend array, processing one leaf at a time. Replace the linear search with a binary search, seeing as the serialised leaves are sorted. No change in behaviour from the guests point of view. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant --- tools/libxc/xc_cpuid_x86.c | 159 +++++++++++++++++++++++++++------------------ tools/libxl/libxl_cpuid.c | 4 +- 2 files changed, 95 insertions(+), 68 deletions(-) diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index edc2ad9b47..e827c48fd1 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -38,8 +38,6 @@ enum { #define bitmaskof(idx) (1u << ((idx) & 31)) #define featureword_of(idx) ((idx) >> 5) -#define clear_feature(idx, dst) ((dst) &= ~bitmaskof(idx)) -#define set_feature(idx, dst) ((dst) |= bitmaskof(idx)) int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps) { @@ -259,15 +257,42 @@ int xc_set_domain_cpu_policy(xc_interface *xch, uint32_t domid, return ret; } +static int compare_leaves(const void *l, const void *r) +{ + const xen_cpuid_leaf_t *lhs = l; + const xen_cpuid_leaf_t *rhs = r; + + if ( lhs->leaf != rhs->leaf ) + return lhs->leaf < rhs->leaf ? -1 : 1; + + if ( lhs->subleaf != rhs->subleaf ) + return lhs->subleaf < rhs->subleaf ? -1 : 1; + + return 0; +} + +static xen_cpuid_leaf_t *find_leaf( + xen_cpuid_leaf_t *leaves, unsigned int nr_leaves, + const struct xc_xend_cpuid *xend) +{ + const xen_cpuid_leaf_t key = { xend->leaf, xend->subleaf }; + + return bsearch(&key, leaves, nr_leaves, sizeof(*leaves), compare_leaves); +} + int xc_cpuid_set( xc_interface *xch, uint32_t domid, const struct xc_xend_cpuid *xend) { int rc; - unsigned int i, j, regs[4] = {}, polregs[4] = {}; xc_dominfo_t di; - xen_cpuid_leaf_t *leaves = NULL; - unsigned int nr_leaves, policy_leaves, nr_msrs; + unsigned int nr_leaves, nr_msrs; uint32_t err_leaf = -1, err_subleaf = -1, err_msr = -1; + /* + * Three full policies. The host, domain max, and domain current for the + * domain type. + */ + xen_cpuid_leaf_t *host = NULL, *max = NULL, *cur = NULL; + unsigned int nr_host, nr_max, nr_cur; if ( xc_domain_getinfo(xch, domid, 1, &di) != 1 || di.domid != domid ) @@ -286,99 +311,101 @@ int xc_cpuid_set( } rc = -ENOMEM; - if ( (leaves = calloc(nr_leaves, sizeof(*leaves))) == NULL ) + if ( (host = calloc(nr_leaves, sizeof(*host))) == NULL || + (max = calloc(nr_leaves, sizeof(*max))) == NULL || + (cur = calloc(nr_leaves, sizeof(*cur))) == NULL ) { ERROR("Unable to allocate memory for %u CPUID leaves", nr_leaves); goto fail; } + /* Get the domain's current policy. */ + nr_msrs = 0; + nr_cur = nr_leaves; + rc = xc_get_domain_cpu_policy(xch, domid, &nr_cur, cur, &nr_msrs, NULL); + if ( rc ) + { + PERROR("Failed to obtain d%d current policy", domid); + rc = -errno; + goto fail; + } + /* Get the domain's max policy. */ nr_msrs = 0; - policy_leaves = nr_leaves; + nr_max = nr_leaves; rc = xc_get_system_cpu_policy(xch, di.hvm ? XEN_SYSCTL_cpu_policy_hvm_max : XEN_SYSCTL_cpu_policy_pv_max, - &policy_leaves, leaves, &nr_msrs, NULL); + &nr_max, max, &nr_msrs, NULL); if ( rc ) { PERROR("Failed to obtain %s max policy", di.hvm ? "hvm" : "pv"); rc = -errno; goto fail; } - for ( i = 0; i < policy_leaves; ++i ) - if ( leaves[i].leaf == xend->leaf && - leaves[i].subleaf == xend->subleaf ) - { - polregs[0] = leaves[i].a; - polregs[1] = leaves[i].b; - polregs[2] = leaves[i].c; - polregs[3] = leaves[i].d; - break; - } /* Get the host policy. */ nr_msrs = 0; - policy_leaves = nr_leaves; + nr_host = nr_leaves; rc = xc_get_system_cpu_policy(xch, XEN_SYSCTL_cpu_policy_host, - &policy_leaves, leaves, &nr_msrs, NULL); + &nr_host, host, &nr_msrs, NULL); if ( rc ) { PERROR("Failed to obtain host policy"); rc = -errno; goto fail; } - for ( i = 0; i < policy_leaves; ++i ) - if ( leaves[i].leaf == xend->leaf && - leaves[i].subleaf == xend->subleaf ) - { - regs[0] = leaves[i].a; - regs[1] = leaves[i].b; - regs[2] = leaves[i].c; - regs[3] = leaves[i].d; - break; - } - for ( i = 0; i < 4; i++ ) + rc = -EINVAL; + for ( ; xend->leaf != XEN_CPUID_INPUT_UNUSED; ++xend ) { - if ( xend->policy[i] == NULL ) + xen_cpuid_leaf_t *cur_leaf = find_leaf(cur, nr_cur, xend); + const xen_cpuid_leaf_t *max_leaf = find_leaf(max, nr_max, xend); + const xen_cpuid_leaf_t *host_leaf = find_leaf(host, nr_host, xend); + + if ( cur_leaf == NULL || max_leaf == NULL || host_leaf == NULL ) { - regs[i] = polregs[i]; - continue; + ERROR("Missing leaf %#x, subleaf %#x", xend->leaf, xend->subleaf); + goto fail; } - /* - * Notes for following this algorithm: - * - * While it will accept any leaf data, it only makes sense to use on - * feature leaves. regs[] initially contains the host values. This, - * with the fall-through chain, is how the 's' and 'k' options work. - */ - for ( j = 0; j < 32; j++ ) + for ( int i = 0; i < 4; i++ ) { - unsigned char val = !!((regs[i] & (1U << (31 - j)))); - unsigned char polval = !!((polregs[i] & (1U << (31 - j)))); - - rc = -EINVAL; - if ( !strchr("10xks", xend->policy[i][j]) ) - goto fail; - - if ( xend->policy[i][j] == '1' ) - val = 1; - else if ( xend->policy[i][j] == '0' ) - val = 0; - else if ( xend->policy[i][j] == 'x' ) - val = polval; - - if ( val ) - set_feature(31 - j, regs[i]); - else - clear_feature(31 - j, regs[i]); + uint32_t *cur_reg = &cur_leaf->a + i; + const uint32_t *max_reg = &max_leaf->a + i; + const uint32_t *host_reg = &host_leaf->a + i; + + if ( xend->policy[i] == NULL ) + continue; + + for ( int j = 0; j < 32; j++ ) + { + bool val; + + if ( xend->policy[i][j] == '1' ) + val = true; + else if ( xend->policy[i][j] == '0' ) + val = false; + else if ( xend->policy[i][j] == 'x' ) + val = test_bit(31 - j, max_reg); + else if ( xend->policy[i][j] == 'k' || + xend->policy[i][j] == 's' ) + val = test_bit(31 - j, host_reg); + else + { + ERROR("Bad character '%c' in policy[%d] string '%s'", + xend->policy[i][j], i, xend->policy[i]); + goto fail; + } + + clear_bit(31 - j, cur_reg); + if ( val ) + set_bit(31 - j, cur_reg); + } } } - /* Feed the transformed leaf back up to Xen. */ - leaves[0] = (xen_cpuid_leaf_t){ xend->leaf, xend->subleaf, - regs[0], regs[1], regs[2], regs[3] }; - rc = xc_set_domain_cpu_policy(xch, domid, 1, leaves, 0, NULL, + /* Feed the transformed currrent policy back up to Xen. */ + rc = xc_set_domain_cpu_policy(xch, domid, nr_cur, cur, 0, NULL, &err_leaf, &err_subleaf, &err_msr); if ( rc ) { @@ -391,7 +418,9 @@ int xc_cpuid_set( /* Success! */ fail: - free(leaves); + free(cur); + free(max); + free(host); return rc; } diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c index e001cbcd4f..6f7cf2054e 100644 --- a/tools/libxl/libxl_cpuid.c +++ b/tools/libxl/libxl_cpuid.c @@ -420,7 +420,6 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, libxl_domain_build_info *info) { libxl_cpuid_policy_list cpuid = info->cpuid; - int i; bool pae = true; /* @@ -441,8 +440,7 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, if (!cpuid) return; - for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) - xc_cpuid_set(ctx->xch, domid, &cpuid[i]); + xc_cpuid_set(ctx->xch, domid, info->cpuid); } static const char *input_names[2] = { "leaf", "subleaf" }; -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:15:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:15:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkptz-0007qj-L6; Mon, 15 Jun 2020 14:15:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpty-0007qe-9F for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:15:54 +0000 X-Inumbo-ID: b8871778-af12-11ea-bca7-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b8871778-af12-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 14:15:53 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: VXRaQHLY4k7JjwaoxKNDHqKX0pr/aBzrF1Bbk363BgZ0pD1EnDAEaIUav89syhYzpOix2wEk6T fbU6En0io1tAXmylQSQ1n1Z/dSlK5n3ib3bJC1WrvAXEk5HMhUXXPrQnqrOQjEHLfcZ1JceZf3 ivBl5mCl4VuS5CVq+yoJ6j/iurALy7wXY9Yg13AqRvJPkDO+7A6Q15dkywCGG52h96VIhJXoWd r8I/n+eQT9C380AaKmhNNHTKMBa/TU5+FSxvGuADahUtSZoovtv4aEwA/kFkqo1lu1sNkL4WRM YAg= X-SBRS: 2.7 X-MesageID: 20064836 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20064836" From: Andrew Cooper To: Xen-devel Subject: [PATCH 6/9] x86/gen-cpuid: Distinguish default vs max in feature annotations Date: Mon, 15 Jun 2020 15:15:29 +0100 Message-ID: <20200615141532.1927-7-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Ian Jackson , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The toolstack logic can now correctly distinguish a clean boot from a migrate/restore. Allow lowercase a/s/h to be used to annotate a non-default feature. Due to the emulator work prepared earlier in 4.14, this now allows VMs to explicity opt in to the TSXLDTRK, MOVDIR{I,64B} and SERIALIZE instructions via their xl.cfg file, rather than getting them as a matter of default. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Ian Jackson CC: Wei Liu CC: Paul Durrant --- xen/tools/gen-cpuid.py | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py index 037954cfb8..ffd9529fdf 100755 --- a/xen/tools/gen-cpuid.py +++ b/xen/tools/gen-cpuid.py @@ -130,17 +130,13 @@ def crunch_numbers(state): MTRR, PGE, MCA, CMOV, PAT, PSE36, MMX, FXSR) state.common_1d = common_1d - state.pv_def = state.raw['A'] - state.hvm_shadow_def = state.pv_def | state.raw['S'] - state.hvm_hap_def = state.hvm_shadow_def | state.raw['H'] - - # TODO: Ignore def/max split until the toolstack migration logic is fixed - state.pv_max = state.pv_def - state.hvm_shadow_max = state.hvm_shadow_def - state.hvm_hap_max = state.hvm_hap_def - # state.pv_max = state.raw['A'] | state.raw['a'] - # state.hvm_shadow_max = state.pv_max | state.raw['S'] | state.raw['s'] - # state.hvm_hap_max = state.hvm_shadow_max | state.raw['H'] | state.raw['h'] + state.pv_def = state.raw['A'] + state.hvm_shadow_def = state.pv_def | state.raw['S'] + state.hvm_hap_def = state.hvm_shadow_def | state.raw['H'] + + state.pv_max = state.raw['A'] | state.raw['a'] + state.hvm_shadow_max = state.pv_max | state.raw['S'] | state.raw['s'] + state.hvm_hap_max = state.hvm_shadow_max | state.raw['H'] | state.raw['h'] # # Feature dependency information. -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:16:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:16:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpu4-0007sF-8o; Mon, 15 Jun 2020 14:16:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpu3-0007qe-5V for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:15:59 +0000 X-Inumbo-ID: b9508c70-af12-11ea-bca7-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b9508c70-af12-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 14:15:54 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: A04GakzAv8qhrDMfu5/dxLlX0prS/Tx3wC3kejqOajtC++rwD9oS+SnvHudkC83u52g3DzSgfK TV4xr+pPX6QLzEvL6PvEecxK9IVuJvWM5gavfu1BY4YBVv788HXRmdJZjKwQxcXuI4hFAZEhhn OhmE/WvawQRTrWmdKTYl4c3S7Bxa9sRIyejEPhoK7RMm6rbmttT01M3UrL2UAzmSWTLbh4QgFh 0UjeNYb3NLqj63Q/8JIiPnq0UfM1Q9LNUS0FEQHlW5+48GZcHH7NpTG4oVyXlXBp5IqdZx7eGk wlE= X-SBRS: 2.7 X-MesageID: 20064837 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20064837" From: Andrew Cooper To: Xen-devel Subject: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted Date: Mon, 15 Jun 2020 15:15:25 +0100 Message-ID: <20200615141532.1927-3-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Ian Jackson , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The existing x86_cpuid_copy_to_buffer() does produce sorted results, and we're about to start relying on this. Extend the unit tests. As test_cpuid_serialise_success() is a fairly limited set of synthetic examples right now, introduce test_cpuid_current() to operate on the full policy for the current CPU. Tweak the fail() macro to allow for simplified control flow. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Ian Jackson CC: Wei Liu CC: Paul Durrant --- tools/tests/cpu-policy/test-cpu-policy.c | 49 +++++++++++++++++++++++++++++++- 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/tools/tests/cpu-policy/test-cpu-policy.c b/tools/tests/cpu-policy/test-cpu-policy.c index fe8cdf6ea9..7ba9707236 100644 --- a/tools/tests/cpu-policy/test-cpu-policy.c +++ b/tools/tests/cpu-policy/test-cpu-policy.c @@ -16,7 +16,7 @@ static unsigned int nr_failures; #define fail(fmt, ...) \ ({ \ nr_failures++; \ - printf(fmt, ##__VA_ARGS__); \ + (void)printf(fmt, ##__VA_ARGS__); \ }) #define memdup(ptr) \ @@ -66,6 +66,45 @@ static void test_vendor_identification(void) } } +static bool leaves_are_sorted(const xen_cpuid_leaf_t *leaves, unsigned int nr) +{ + for ( unsigned int i = 1; i < nr; ++i ) + { + /* leaf index went backwards => not sorted. */ + if ( leaves[i - 1].leaf > leaves[i].leaf ) + return false; + + /* leaf index went forwards => ok */ + if ( leaves[i - 1].leaf < leaves[i].leaf ) + continue; + + /* leave index the same, subleaf didn't increase => not sorted. */ + if ( leaves[i - 1].subleaf >= leaves[i].subleaf ) + return false; + } + + return true; +} + +static void test_cpuid_current(void) +{ + struct cpuid_policy p; + xen_cpuid_leaf_t leaves[CPUID_MAX_SERIALISED_LEAVES]; + unsigned int nr = ARRAY_SIZE(leaves); + int rc; + + printf("Testing CPUID on current CPU\n"); + + x86_cpuid_policy_fill_native(&p); + + rc = x86_cpuid_copy_to_buffer(&p, leaves, &nr); + if ( rc != 0 ) + return fail(" Serialise, expected rc 0, got %d\n", rc); + + if ( !leaves_are_sorted(leaves, nr) ) + return fail(" Leaves not sorted\n"); +} + static void test_cpuid_serialise_success(void) { static const struct test { @@ -178,6 +217,13 @@ static void test_cpuid_serialise_success(void) goto test_done; } + if ( !leaves_are_sorted(leaves, nr) ) + { + fail(" Test %s, leaves not sorted\n", + t->name); + goto test_done; + } + test_done: free(leaves); } @@ -613,6 +659,7 @@ int main(int argc, char **argv) test_vendor_identification(); + test_cpuid_current(); test_cpuid_serialise_success(); test_cpuid_deserialise_failure(); test_cpuid_out_of_range_clearing(); -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:16:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:16:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpu7-0007tO-Hy; Mon, 15 Jun 2020 14:16:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpu5-0007r6-Fq for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:16:01 +0000 X-Inumbo-ID: ba6d0701-af12-11ea-b801-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ba6d0701-af12-11ea-b801-12813bfff9fa; Mon, 15 Jun 2020 14:15:58 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 0liUADho4YHnmkjoHbiQmt3aEb6H97PEKmCdIyS/QYd/PgEY1aj75590t45RXVJQjRaXyMvEFZ jD+nNaacMLVx8GZPk+qwZZfCzy3P5DAfeZD2Ht47pFY8ZVnD+USKOBEk+qidyxs6iaRFjFAHav VNnEDu6cjfeEre4NKKSvotgfNWs2bkeQyBYMJzidgcuZj7OASp9YqnDUqGOdT0pUw0+hrZBxNe s/y9NZjpjWs4f8XVnLh8I9L0qBhIF21WN8FjFiFnNTbEj5a3gZCIkP6IMUEO8w/7GpbpEKcLri 16w= X-SBRS: 2.7 X-MesageID: 20410406 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20410406" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge Date: Mon, 15 Jun 2020 15:15:23 +0100 Message-ID: <20200615141532.1927-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Ian Jackson , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This is some work in light of IvyBridge not gaining microcode to combat SRBDS / XSA-320. It is a mix of some work I'd planned for 4.15, and some patches posted already and delayed due to dependence's I'd discovered after-the-fact. This provides a more user-friendly way of making IvyBridge safe by default without encountering migration incompatibilities. In terms of functionality, it finishes the "fresh boot" vs "migrate/restore from pre-4.14" split in the libxc CPUID logic, and uses this to let us safely hide features by default without breaking the "divine what a guest may have seen previously" logic on migrate. On top of that, we hide RDRAND by default to mitigate XSA-320. Additionally, take the opportunity of finally getting this logic working to hide MPX by default (as posted previously), due to upcoming Intel timelines. Request for 4.14. The IvyBridge angle only became apparent after the public embargo on Tue 9th. Otherwise, I would have made a concerted effort to get this logic sorted sooner and/or part of XSA-320 itself. Strictly speaking, patches 1-4 aren't necessary, but without them the logic is very confusing to follow, particularly the reasoning about the safely of later changes. As it is a simple set of transforms, we're better with them than without. Also, the MPX patch isn't related to the RDRAND issue, but I was planning to get it into 4.14 already, until realising that the migration path was broken. Now that the path is fixed for the RDRAND issue, include the MPX patch as it pertains to future hardware compatibility (and would be backported to 4.14.1 if it misses 4.14.0). Andrew Cooper (9): tools/libx[cl]: Introduce struct xc_xend_cpuid for xc_cpuid_set() tests/cpu-policy: Confirm that CPUID serialisation is sorted tools/libx[cl]: Move processing loop down into xc_cpuid_set() tools/libx[cl]: Merge xc_cpuid_set() into xc_cpuid_apply_policy() tools/libx[cl]: Plumb bool restore down into xc_cpuid_apply_policy() x86/gen-cpuid: Distinguish default vs max in feature annotations x86/hvm: Disable MPX by default x86/cpuid: Introduce missing feature adjustment in calculate_pv_def_policy() x86/spec-ctrl: Hide RDRAND by default on IvyBridge docs/misc/xen-command-line.pandoc | 20 ++- tools/libxc/include/xenctrl.h | 42 ++++- tools/libxc/xc_cpuid_x86.c | 239 ++++++++++++++++------------ tools/libxl/libxl.h | 8 +- tools/libxl/libxl_cpuid.c | 17 +- tools/libxl/libxl_create.c | 2 +- tools/libxl/libxl_dom.c | 2 +- tools/libxl/libxl_internal.h | 12 +- tools/libxl/libxl_nocpuid.c | 2 +- tools/tests/cpu-policy/test-cpu-policy.c | 49 +++++- xen/arch/x86/cpuid.c | 23 +++ xen/include/public/arch-x86/cpufeatureset.h | 4 +- xen/tools/gen-cpuid.py | 18 +-- 13 files changed, 278 insertions(+), 160 deletions(-) -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:16:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:16:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpu8-0007uK-Qi; Mon, 15 Jun 2020 14:16:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpu8-0007qe-5t for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:16:04 +0000 X-Inumbo-ID: b92196c2-af12-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b92196c2-af12-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 14:15:54 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: mIjdbp5dwfK4SNh/gtIzQUviUFY1+aoEexNg9HA4wjQnxRIKigFWSgQALaJLKqpjAvgXbq0T9X zOmMSjph7GeFokY7BEcVNQDr+sC8YDCXZ5Dc/yO+h0c1ql9vgHwMwU9CjD/Z1u62LisAAIt7TS E5PVQLCSyuqiE0xGXtCIjWpjf10/vGP5jdltHz0YM42JO5+4PHRZ3/L8tLkFosOYZyjp4cRMUo Dj/jt+/3GDPsJELVvtcuBPV3Vs1Tk5U9a4ICmtra0D/r33ukOBV8Ose34QxYYqJWg9LV4N7xPx AAM= X-SBRS: 2.7 X-MesageID: 20064838 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20064838" From: Andrew Cooper To: Xen-devel Subject: [PATCH 9/9] x86/spec-ctrl: Hide RDRAND by default on IvyBridge Date: Mon, 15 Jun 2020 15:15:32 +0100 Message-ID: <20200615141532.1927-10-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Ian Jackson , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" To combat the absence of mitigating microcode, arrange to hide RDRAND by default on IvyBridge hardware. Adjust the default feature derivation to hide RDRAND on IvyBridge client parts, unless `cpuid=rdrand` is explicitly provided. Adjust the restore path in xc_cpuid_apply_policy() to not hide RDRAND from VMs which migrated from pre-4.14. In all cases, individual guests can continue using RDRAND if explicitly enabled in their config files. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant --- docs/misc/xen-command-line.pandoc | 20 +++++++++++++++----- tools/libxc/xc_cpuid_x86.c | 3 +++ xen/arch/x86/cpuid.c | 21 +++++++++++++++++++++ xen/include/public/arch-x86/cpufeatureset.h | 2 +- 4 files changed, 40 insertions(+), 6 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index fde749c669..c8ebfaf813 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -512,11 +512,21 @@ The Speculation Control hardware features `srbds-ctrl`, `md-clear`, `ibrsb`, `stibp`, `ibpb`, `l1d-flush` and `ssbd` are used by default if available and applicable. They can all be ignored. -`rdrand` and `rdseed` can be ignored, as a mitigation to XSA-320 / -CVE-2020-0543. The RDRAND feature is disabled by default on certain AMD -systems, due to possible malfunctions after ACPI S3 suspend/resume. `rdrand` -may be used in its positive form to override Xen's default behaviour on these -systems, and make the feature fully usable. +`rdrand` and `rdseed` have multiple interactions. + +* For Special Register Buffer Data Sampling (SRBDS, XSA-320, CVE-2020-0543), + RDRAND and RDSEED can be ignored. + + Due to the absence microcode to address SRBDS on IvyBridge hardware, the + RDRAND feature is hidden by default for guests, unless `rdrand` is used in + its positive form. Irrespective of the default setting here, VMs can use + RDRAND if explicitly enabled in guest config file, and VMs already using + RDRAND can migrate in. + +* The RDRAND feature is disabled by default on AMD Fam15/16 systems, due to + possible malfunctions after ACPI S3 suspend/resume. `rdrand` may be used + in its positive form to override Xen's default behaviour on these systems, + and make the feature fully usable. ### cpuid_mask_cpu > `= fam_0f_rev_[cdefg] | fam_10_rev_[bc] | fam_11_rev_b` diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index 5649913e69..877a5601f3 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -503,6 +503,9 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, */ if ( restore ) { + if ( test_bit(X86_FEATURE_RDRAND, host_featureset) && !p->basic.rdrand ) + p->basic.rdrand = true; + if ( di.hvm ) { p->feat.mpx = test_bit(X86_FEATURE_MPX, host_featureset); diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index f2fc0aa895..6a4a787b68 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -340,6 +340,25 @@ static void __init calculate_host_policy(void) } } +static void __init guest_common_default_feature_adjustments(uint32_t *fs) +{ + /* + * IvyBridge client parts suffer from leakage of RDRAND data due to SRBDS + * (XSA-320 / CVE-2020-0543), and won't be receiving microcode to + * compensate. + * + * Mitigate by hiding RDRAND from guests by default, unless explicitly + * overridden on the Xen command line (cpuid=rdrand). Irrespective of the + * default setting, guests can use RDRAND if explicitly enabled + * (cpuid="host,rdrand=1") in the VM's config file, and VMs which were + * previously using RDRAND can migrate in. + */ + if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x3a && + cpu_has_rdrand && !is_forced_cpu_cap(X86_FEATURE_RDRAND) ) + __clear_bit(X86_FEATURE_RDRAND, fs); +} + static void __init guest_common_feature_adjustments(uint32_t *fs) { /* Unconditionally claim to be able to set the hypervisor bit. */ @@ -403,6 +422,7 @@ static void __init calculate_pv_def_policy(void) pv_featureset[i] &= pv_def_featuremask[i]; guest_common_feature_adjustments(pv_featureset); + guest_common_default_feature_adjustments(pv_featureset); sanitise_featureset(pv_featureset); cpuid_featureset_to_policy(pv_featureset, p); @@ -485,6 +505,7 @@ static void __init calculate_hvm_def_policy(void) hvm_featureset[i] &= hvm_featuremask[i]; guest_common_feature_adjustments(hvm_featureset); + guest_common_default_feature_adjustments(hvm_featureset); sanitise_featureset(hvm_featureset); cpuid_featureset_to_policy(hvm_featureset, p); diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index af1b8a96a6..fe7492a225 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -149,7 +149,7 @@ XEN_CPUFEATURE(XSAVE, 1*32+26) /*A XSAVE/XRSTOR/XSETBV/XGETBV */ XEN_CPUFEATURE(OSXSAVE, 1*32+27) /*! OSXSAVE */ XEN_CPUFEATURE(AVX, 1*32+28) /*A Advanced Vector Extensions */ XEN_CPUFEATURE(F16C, 1*32+29) /*A Half-precision convert instruction */ -XEN_CPUFEATURE(RDRAND, 1*32+30) /*A Digital Random Number Generator */ +XEN_CPUFEATURE(RDRAND, 1*32+30) /*!A Digital Random Number Generator */ XEN_CPUFEATURE(HYPERVISOR, 1*32+31) /*!A Running under some hypervisor */ /* AMD-defined CPU features, CPUID level 0x80000001.edx, word 2 */ -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:16:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:16:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuC-0007wm-7I; Mon, 15 Jun 2020 14:16:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuA-0007r6-G3 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:16:06 +0000 X-Inumbo-ID: bc0677b8-af12-11ea-b801-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bc0677b8-af12-11ea-b801-12813bfff9fa; Mon, 15 Jun 2020 14:15:59 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: JU1Vs650gkYDzYMdXAJXYudu/aOm7faToFpWENF6iSlqlaSh8VZFf4te83IyZXexORmiMShiPJ aXpgt4sBt9nWBSKXmOy5LIPTkCMAVU+KhnNzjKYccOZ0HrUp0rWIzyEfTN+lZpib3Qc6IH8UDL AgSSykyH7Ss7D9bv7f2FOUwwF0ZpVBoyFB6IKG8yzUJRkMu51dJHZ3mOlhTKsNRoxHuZuutaMu b7GCXgG6IzI88ps90tsI7KCxx50mnOLoPSFVJJqYO1Jq+6L+FalNPtI22VS6d6Y3qSMt4OwQ/b PR0= X-SBRS: 2.7 X-MesageID: 20839545 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20839545" From: Andrew Cooper To: Xen-devel Subject: [PATCH 7/9] x86/hvm: Disable MPX by default Date: Mon, 15 Jun 2020 15:15:30 +0100 Message-ID: <20200615141532.1927-8-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Ian Jackson , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Memory Protection eXtension support has been dropped from GCC and Linux, and will be dropped from future Intel CPUs. With all other default/max pieces in place, move MPX from default to max. This means that VMs won't be offered it by default, but can explicitly opt into using it via cpuid="host,mpx=1" in their vm.cfg file. The difference as visible to the guest is: diff --git a/default b/mpx index 0e91765d6b..c8c33cd584 100644 --- a/default +++ b/mpx @@ -13,15 +13,17 @@ Native cpuid: 00000004:00000004 -> 00000000:00000000:00000000:00000000 00000005:ffffffff -> 00000000:00000000:00000000:00000000 00000006:ffffffff -> 00000000:00000000:00000000:00000000 - 00000007:00000000 -> 00000000:009c2fbb:00000000:9c000400 + 00000007:00000000 -> 00000000:009c6fbb:00000000:9c000400 00000008:ffffffff -> 00000000:00000000:00000000:00000000 00000009:ffffffff -> 00000000:00000000:00000000:00000000 0000000a:ffffffff -> 00000000:00000000:00000000:00000000 0000000b:ffffffff -> 00000000:00000000:00000000:00000000 0000000c:ffffffff -> 00000000:00000000:00000000:00000000 - 0000000d:00000000 -> 00000007:00000240:00000340:00000000 + 0000000d:00000000 -> 0000001f:00000240:00000440:00000000 0000000d:00000001 -> 0000000f:00000240:00000000:00000000 0000000d:00000002 -> 00000100:00000240:00000000:00000000 + 0000000d:00000003 -> 00000040:000003c0:00000000:00000000 + 0000000d:00000004 -> 00000040:00000400:00000000:00000000 40000000:ffffffff -> 40000005:566e6558:65584d4d:4d4d566e 40000001:ffffffff -> 0004000e:00000000:00000000:00000000 40000002:ffffffff -> 00000001:40000000:00000000:00000000 Adjust the legacy restore path in libxc to cope safely with pre-4.14 VMs. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Ian Jackson CC: Wei Liu CC: Paul Durrant Dropped Jan's R-by from previous posting, as the patch has gained new toolstack logic to avoid breaking migrate. --- tools/libxc/xc_cpuid_x86.c | 48 ++++++++++++++++++----------- xen/include/public/arch-x86/cpufeatureset.h | 2 +- 2 files changed, 31 insertions(+), 19 deletions(-) diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index e017abffce..5649913e69 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -436,6 +436,8 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, xen_cpuid_leaf_t *leaves = NULL; struct cpuid_policy *p = NULL; uint32_t err_leaf = -1, err_subleaf = -1, err_msr = -1; + uint32_t host_featureset[FEATURESET_NR_ENTRIES] = {}; + uint32_t len = ARRAY_SIZE(host_featureset); if ( xc_domain_getinfo(xch, domid, 1, &di) != 1 || di.domid != domid ) @@ -458,6 +460,22 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, (p = calloc(1, sizeof(*p))) == NULL ) goto out; + /* Get the host policy. */ + rc = xc_get_cpu_featureset(xch, XEN_SYSCTL_cpu_featureset_host, + &len, host_featureset); + if ( rc ) + { + /* Tolerate "buffer too small", as we've got the bits we need. */ + if ( errno == ENOBUFS ) + rc = 0; + else + { + PERROR("Failed to obtain host featureset"); + rc = -errno; + goto out; + } + } + /* Get the domain's default policy. */ nr_msrs = 0; rc = xc_get_system_cpu_policy(xch, di.hvm ? XEN_SYSCTL_cpu_policy_hvm_default @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, goto out; } + /* + * Account for feature which have been disabled by default since Xen 4.13, + * so migrated-in VM's don't risk seeing features disappearing. + */ + if ( restore ) + { + if ( di.hvm ) + { + p->feat.mpx = test_bit(X86_FEATURE_MPX, host_featureset); + } + } + if ( featureset ) { uint32_t disabled_features[FEATURESET_NR_ENTRIES], @@ -530,24 +560,6 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, if ( !di.hvm ) { - uint32_t host_featureset[FEATURESET_NR_ENTRIES] = {}; - uint32_t len = ARRAY_SIZE(host_featureset); - - rc = xc_get_cpu_featureset(xch, XEN_SYSCTL_cpu_featureset_host, - &len, host_featureset); - if ( rc ) - { - /* Tolerate "buffer too small", as we've got the bits we need. */ - if ( errno == ENOBUFS ) - rc = 0; - else - { - PERROR("Failed to obtain host featureset"); - rc = -errno; - goto out; - } - } - /* * On hardware without CPUID Faulting, PV guests see real topology. * As a consequence, they also need to see the host htt/cmp fields. diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 5ca35d9d97..af1b8a96a6 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -207,7 +207,7 @@ XEN_CPUFEATURE(INVPCID, 5*32+10) /*H Invalidate Process Context ID */ XEN_CPUFEATURE(RTM, 5*32+11) /*A Restricted Transactional Memory */ XEN_CPUFEATURE(PQM, 5*32+12) /* Platform QoS Monitoring */ XEN_CPUFEATURE(NO_FPU_SEL, 5*32+13) /*! FPU CS/DS stored as zero */ -XEN_CPUFEATURE(MPX, 5*32+14) /*S Memory Protection Extensions */ +XEN_CPUFEATURE(MPX, 5*32+14) /*s Memory Protection Extensions */ XEN_CPUFEATURE(PQE, 5*32+15) /* Platform QoS Enforcement */ XEN_CPUFEATURE(AVX512F, 5*32+16) /*A AVX-512 Foundation Instructions */ XEN_CPUFEATURE(AVX512DQ, 5*32+17) /*A AVX-512 Doubleword & Quadword Instrs */ -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:16:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:16:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuE-0007yW-GW; Mon, 15 Jun 2020 14:16:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuD-0007qe-5j for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:16:09 +0000 X-Inumbo-ID: b9b798b6-af12-11ea-bca7-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b9b798b6-af12-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 14:15:54 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 2lfisGOrd28c2GHAkOxBetBR4iUWm8SYG26l+LvzWyEiWbJePzyrFu8YSqnIWQt7VhZpV3f5Qp 6cjLb0bru0DW2nnuPoOXWqO51adVrVcHkWN+V7Xlhe+IKMP/fG4iqhytYUN2pHXdJZWxupvQz2 z5nialtJnULBif0S2RTGHZ371kp4MjU9O2tYVeL10Y5wL+ThjK0qtlG4iOi7djdwfUhg5bjPJs mOyd4IKjyS2zx5bwiugaVrKwZziG+BbpkxDscjSl7739tiSqCVnLTg+bin7TgXutUSZAqJrQmQ mF4= X-SBRS: 2.7 X-MesageID: 20064839 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20064839" From: Andrew Cooper To: Xen-devel Subject: [PATCH 5/9] tools/libx[cl]: Plumb bool restore down into xc_cpuid_apply_policy() Date: Mon, 15 Jun 2020 15:15:28 +0100 Message-ID: <20200615141532.1927-6-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Ian Jackson , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In order to safely disable some features by default, without breaking migration from 4.13 or older, the CPUID logic needs to distinguish the two cases. Plumb a restore boolean down from the two callers of libxl__cpuid_legacy() all the way down into xc_cpuid_apply_policy(). No functional change. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant Ideally, I'd have started the brand new CPUID/MSR interface for the boot path before cleaning up the legacy path, but that's far too much work to squeeze into 4.14 at this point. The restore boolean will do for now, and will disappear eventually. --- tools/libxc/include/xenctrl.h | 7 ++++++- tools/libxc/xc_cpuid_x86.c | 2 +- tools/libxl/libxl_cpuid.c | 4 ++-- tools/libxl/libxl_create.c | 2 +- tools/libxl/libxl_dom.c | 2 +- tools/libxl/libxl_internal.h | 2 +- tools/libxl/libxl_nocpuid.c | 2 +- 7 files changed, 13 insertions(+), 8 deletions(-) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 5f0978e0e5..634be88ac1 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -1822,13 +1822,18 @@ struct xc_xend_cpuid { /* * Make adjustments to the CPUID settings for a domain. * + * This path is used in two cases. First, for fresh boots of the domain, and + * secondly for migrate-in/restore of pre-4.14 guests (where CPUID data was + * missing from the stream). The @restore parameter distinguishes these + * cases, and the generated policy must be compatible with a 4.13. + * * Either pass a full new @featureset (and @nr_features), or adjust individual * features (@pae). * * Then (optionally) apply legacy XEND overrides (@xend) to the result. */ int xc_cpuid_apply_policy(xc_interface *xch, - uint32_t domid, + uint32_t domid, bool restore, const uint32_t *featureset, unsigned int nr_features, bool pae, const struct xc_xend_cpuid *xend); diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index 26a7b94dcf..e017abffce 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -425,7 +425,7 @@ static int xc_cpuid_xend_policy( return rc; } -int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, +int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, const uint32_t *featureset, unsigned int nr_features, bool pae, const struct xc_xend_cpuid *xend) diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c index edfcf315ca..db2f12d115 100644 --- a/tools/libxl/libxl_cpuid.c +++ b/tools/libxl/libxl_cpuid.c @@ -416,7 +416,7 @@ int libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list *cpuid, return 0; } -void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, +void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, bool restore, libxl_domain_build_info *info) { bool pae = true; @@ -434,7 +434,7 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, if (info->type == LIBXL_DOMAIN_TYPE_HVM) pae = libxl_defbool_val(info->u.hvm.pae); - xc_cpuid_apply_policy(ctx->xch, domid, NULL, 0, pae, info->cpuid); + xc_cpuid_apply_policy(ctx->xch, domid, restore, NULL, 0, pae, info->cpuid); } static const char *input_names[2] = { "leaf", "subleaf" }; diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 75862dc6ed..2814818e34 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -1447,7 +1447,7 @@ int libxl__srm_callout_callback_static_data_done(unsigned int missing, * stream doesn't contain any CPUID data. */ if (missing & XGR_SDD_MISSING_CPUID) - libxl__cpuid_legacy(ctx, dcs->guest_domid, info); + libxl__cpuid_legacy(ctx, dcs->guest_domid, true, info); return 0; } diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c index dd1aff89a3..f8661e90d4 100644 --- a/tools/libxl/libxl_dom.c +++ b/tools/libxl/libxl_dom.c @@ -391,7 +391,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid, * being migrated-in/restored have CPUID handled during the * static_data_done() callback. */ if (!state->restore) - libxl__cpuid_legacy(ctx, domid, info); + libxl__cpuid_legacy(ctx, domid, false, info); return rc; } diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index 79c2bf5f5e..94a23179d3 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -2056,7 +2056,7 @@ typedef yajl_gen_status (*libxl__gen_json_callback)(yajl_gen hand, void *); _hidden char *libxl__object_to_json(libxl_ctx *ctx, const char *type, libxl__gen_json_callback gen, void *p); -_hidden void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, +_hidden void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, bool retore, libxl_domain_build_info *info); /* Calls poll() again - useful to check whether a signaled condition diff --git a/tools/libxl/libxl_nocpuid.c b/tools/libxl/libxl_nocpuid.c index 3f30e148be..f47336565b 100644 --- a/tools/libxl/libxl_nocpuid.c +++ b/tools/libxl/libxl_nocpuid.c @@ -34,7 +34,7 @@ int libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list *cpuid, return 0; } -void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, +void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, bool restore, libxl_domain_build_info *info) { } -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:16:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:16:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuI-00081k-Qm; Mon, 15 Jun 2020 14:16:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuI-0007qe-5u for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:16:14 +0000 X-Inumbo-ID: b9e8f80c-af12-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b9e8f80c-af12-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 14:15:55 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: UDaqbc4TbHeYODtc+HkmveLoGbw/Tno3hC+KDZcJ96XhD748wssAHbyq/SyAnFuaZFPhHX+vxB bf1cOvEcp0XrYwqCjk25x88wV+9yrTrLLVnlEusbDIxnZ4PpdUg3a+Z87VhFRZFkHFN6X0fQXZ YOh1W6DRzAxgseB+FrUBfXJJ6zSxXo8A1nqKicOdIjaC0SInshwv1/D2pHwHSRMXxnEMCLs7Kj hkSjdhOwRY/mg9PzaAnrJ9vWkzMzIdWiK9nyKAvWl0IulfEsBIVT4PZwFNMarlVr63uUEv1R2Y SOY= X-SBRS: 2.7 X-MesageID: 20064840 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20064840" From: Andrew Cooper To: Xen-devel Subject: [PATCH 1/9] tools/libx[cl]: Introduce struct xc_xend_cpuid for xc_cpuid_set() Date: Mon, 15 Jun 2020 15:15:24 +0100 Message-ID: <20200615141532.1927-2-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Ian Jackson , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In order to combine the functionality of xc_cpuid_set() with xc_cpuid_apply_policy(), arrange to pass the data in a single contained struct, rather than two arrays. libxl__cpuid_policy is the ideal structure to use, but that would introduce a reverse dependency between libxc and libxl. Introduce xc_xend_cpuid (with a transparent union to provide more useful names for the inputs), and use this structure in libxl. The public API has libxl_cpuid_policy as an opaque type referencing libxl__cpuid_policy. Drop the inappropriate comment about its internals, and use xc_xend_cpuid as a differently named opaque backing object. Users of both libxl and libxc are not permitted to look at the internals. No change in behaviour. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant --- tools/libxc/include/xenctrl.h | 30 ++++++++++++++++++++++++++++-- tools/libxc/xc_cpuid_x86.c | 39 +++++++++++---------------------------- tools/libxl/libxl.h | 8 ++++---- tools/libxl/libxl_cpuid.c | 7 +++---- tools/libxl/libxl_internal.h | 10 ---------- 5 files changed, 46 insertions(+), 48 deletions(-) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 113ddd935d..178144e8e2 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -1792,10 +1792,36 @@ int xc_domain_debug_control(xc_interface *xch, uint32_t vcpu); #if defined(__i386__) || defined(__x86_64__) + +/* + * CPUID policy data, expressed in the legacy XEND format. + * + * Policy is an array of strings, 32 chars long: + * policy[0] = eax + * policy[1] = ebx + * policy[2] = ecx + * policy[3] = edx + * + * The format of the string is the following: + * '1' -> force to 1 + * '0' -> force to 0 + * 'x' -> we don't care (use default) + * 'k' -> pass through host value + * 's' -> legacy alias for 'k' + */ +struct xc_xend_cpuid { + union { + struct { + uint32_t leaf, subleaf; + }; + uint32_t input[2]; + }; + char *policy[4]; +}; + int xc_cpuid_set(xc_interface *xch, uint32_t domid, - const unsigned int *input, - const char **config); + const struct xc_xend_cpuid *xend); /* * Make adjustments to the CPUID settings for a domain. diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index b42edd6457..edc2ad9b47 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -259,27 +259,8 @@ int xc_set_domain_cpu_policy(xc_interface *xch, uint32_t domid, return ret; } -/* - * Configure a single input with the informatiom from config. - * - * Config is an array of strings: - * config[0] = eax - * config[1] = ebx - * config[2] = ecx - * config[3] = edx - * - * The format of the string is the following: - * '1' -> force to 1 - * '0' -> force to 0 - * 'x' -> we don't care (use default) - * 'k' -> pass through host value - * 's' -> legacy alias for 'k' - * - * In all cases, the returned string consists of just '0' and '1'. - */ int xc_cpuid_set( - xc_interface *xch, uint32_t domid, const unsigned int *input, - const char **config) + xc_interface *xch, uint32_t domid, const struct xc_xend_cpuid *xend) { int rc; unsigned int i, j, regs[4] = {}, polregs[4] = {}; @@ -324,7 +305,8 @@ int xc_cpuid_set( goto fail; } for ( i = 0; i < policy_leaves; ++i ) - if ( leaves[i].leaf == input[0] && leaves[i].subleaf == input[1] ) + if ( leaves[i].leaf == xend->leaf && + leaves[i].subleaf == xend->subleaf ) { polregs[0] = leaves[i].a; polregs[1] = leaves[i].b; @@ -345,7 +327,8 @@ int xc_cpuid_set( goto fail; } for ( i = 0; i < policy_leaves; ++i ) - if ( leaves[i].leaf == input[0] && leaves[i].subleaf == input[1] ) + if ( leaves[i].leaf == xend->leaf && + leaves[i].subleaf == xend->subleaf ) { regs[0] = leaves[i].a; regs[1] = leaves[i].b; @@ -356,7 +339,7 @@ int xc_cpuid_set( for ( i = 0; i < 4; i++ ) { - if ( config[i] == NULL ) + if ( xend->policy[i] == NULL ) { regs[i] = polregs[i]; continue; @@ -375,14 +358,14 @@ int xc_cpuid_set( unsigned char polval = !!((polregs[i] & (1U << (31 - j)))); rc = -EINVAL; - if ( !strchr("10xks", config[i][j]) ) + if ( !strchr("10xks", xend->policy[i][j]) ) goto fail; - if ( config[i][j] == '1' ) + if ( xend->policy[i][j] == '1' ) val = 1; - else if ( config[i][j] == '0' ) + else if ( xend->policy[i][j] == '0' ) val = 0; - else if ( config[i][j] == 'x' ) + else if ( xend->policy[i][j] == 'x' ) val = polval; if ( val ) @@ -393,7 +376,7 @@ int xc_cpuid_set( } /* Feed the transformed leaf back up to Xen. */ - leaves[0] = (xen_cpuid_leaf_t){ input[0], input[1], + leaves[0] = (xen_cpuid_leaf_t){ xend->leaf, xend->subleaf, regs[0], regs[1], regs[2], regs[3] }; rc = xc_set_domain_cpu_policy(xch, domid, 1, leaves, 0, NULL, &err_leaf, &err_subleaf, &err_msr); diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 71709dc585..1cd6c38e83 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1310,11 +1310,11 @@ typedef struct { void libxl_bitmap_init(libxl_bitmap *map); void libxl_bitmap_dispose(libxl_bitmap *map); -/* libxl_cpuid_policy_list is a dynamic array storing CPUID policies - * for multiple leafs. It is terminated with an entry holding - * XEN_CPUID_INPUT_UNUSED in input[0] +/* + * libxl_cpuid_policy is opaque in the libxl ABI. Users of both libxl and + * libxc may not make assumptions about xc_xend_cpuid. */ -typedef struct libxl__cpuid_policy libxl_cpuid_policy; +typedef struct xc_xend_cpuid libxl_cpuid_policy; typedef libxl_cpuid_policy * libxl_cpuid_policy_list; void libxl_cpuid_dispose(libxl_cpuid_policy_list *cpuid_list); int libxl_cpuid_policy_list_length(const libxl_cpuid_policy_list *l); diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c index 796ec4f2d9..e001cbcd4f 100644 --- a/tools/libxl/libxl_cpuid.c +++ b/tools/libxl/libxl_cpuid.c @@ -288,7 +288,7 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list *cpuid, const char* str) char *sep, *val, *endptr; int i; const struct cpuid_flags *flag; - struct libxl__cpuid_policy *entry; + struct xc_xend_cpuid *entry; unsigned long num; char flags[33], *resstr; @@ -366,7 +366,7 @@ int libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list *cpuid, char *endptr; unsigned long value; uint32_t leaf, subleaf = XEN_CPUID_INPUT_UNUSED; - struct libxl__cpuid_policy *entry; + struct xc_xend_cpuid *entry; /* parse the leaf number */ value = strtoul(str, &endptr, 0); @@ -442,8 +442,7 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, return; for (i = 0; cpuid[i].input[0] != XEN_CPUID_INPUT_UNUSED; i++) - xc_cpuid_set(ctx->xch, domid, cpuid[i].input, - (const char**)cpuid[i].policy); + xc_cpuid_set(ctx->xch, domid, &cpuid[i]); } static const char *input_names[2] = { "leaf", "subleaf" }; diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h index c7ece066c4..79c2bf5f5e 100644 --- a/tools/libxl/libxl_internal.h +++ b/tools/libxl/libxl_internal.h @@ -2056,16 +2056,6 @@ typedef yajl_gen_status (*libxl__gen_json_callback)(yajl_gen hand, void *); _hidden char *libxl__object_to_json(libxl_ctx *ctx, const char *type, libxl__gen_json_callback gen, void *p); - /* holds the CPUID response for a single CPUID leaf - * input contains the value of the EAX and ECX register, - * and each policy string contains a filter to apply to - * the host given values for that particular leaf. - */ -struct libxl__cpuid_policy { - uint32_t input[2]; - char *policy[4]; -}; - _hidden void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, libxl_domain_build_info *info); -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:16:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:16:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuO-00086L-4M; Mon, 15 Jun 2020 14:16:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuN-0007qe-69 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:16:19 +0000 X-Inumbo-ID: bb625930-af12-11ea-bca7-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bb625930-af12-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 14:15:58 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Snr8vaAfNSSAS8IA9g4PvhVBkLH0/PnPWvuDbtoqmonYGzjyOxXbL5wmjTDu+yzBJzr05Wh2+w n6WuIWB0krml7vYplkf6Inoh7/0f691r4YyDhewmBa1Jgm0W2qrkPOaWhORhbQfJJXNSY5sRy3 MfIycaEWwjkFZeYR/Vc78H930aT6tvGJWkqC8BrJEFrqd5iVzNjtVxhd3cPgIqvvXGtebQ+Rdr BcPydlb2/A+cDKDPoc+KLFDIlOWNB9ki6tOLMckpvMzGYaWlgh+H/HReULnLs/yUXoaiPHeumZ x18= X-SBRS: 2.7 X-MesageID: 20839539 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20839539" From: Andrew Cooper To: Xen-devel Subject: [PATCH 4/9] tools/libx[cl]: Merge xc_cpuid_set() into xc_cpuid_apply_policy() Date: Mon, 15 Jun 2020 15:15:27 +0100 Message-ID: <20200615141532.1927-5-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Ian Jackson , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This reduces the number of CPUID handling entry-points to just one. No functional change. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant --- tools/libxc/include/xenctrl.h | 9 ++++----- tools/libxc/xc_cpuid_x86.c | 8 ++++++-- tools/libxl/libxl_cpuid.c | 8 +------- 3 files changed, 11 insertions(+), 14 deletions(-) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 178144e8e2..5f0978e0e5 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -1819,20 +1819,19 @@ struct xc_xend_cpuid { char *policy[4]; }; -int xc_cpuid_set(xc_interface *xch, - uint32_t domid, - const struct xc_xend_cpuid *xend); - /* * Make adjustments to the CPUID settings for a domain. * * Either pass a full new @featureset (and @nr_features), or adjust individual * features (@pae). + * + * Then (optionally) apply legacy XEND overrides (@xend) to the result. */ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, const uint32_t *featureset, - unsigned int nr_features, bool pae); + unsigned int nr_features, bool pae, + const struct xc_xend_cpuid *xend); int xc_mca_op(xc_interface *xch, struct xen_mc *mc); int xc_mca_op_inject_v2(xc_interface *xch, unsigned int flags, xc_cpumap_t cpumap, unsigned int nr_cpus); diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index e827c48fd1..26a7b94dcf 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -280,7 +280,7 @@ static xen_cpuid_leaf_t *find_leaf( return bsearch(&key, leaves, nr_leaves, sizeof(*leaves), compare_leaves); } -int xc_cpuid_set( +static int xc_cpuid_xend_policy( xc_interface *xch, uint32_t domid, const struct xc_xend_cpuid *xend) { int rc; @@ -427,7 +427,8 @@ int xc_cpuid_set( int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, const uint32_t *featureset, unsigned int nr_features, - bool pae) + bool pae, + const struct xc_xend_cpuid *xend) { int rc; xc_dominfo_t di; @@ -637,6 +638,9 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, goto out; } + if ( xend && (rc = xc_cpuid_xend_policy(xch, domid, xend)) ) + goto out; + rc = 0; out: diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c index 6f7cf2054e..edfcf315ca 100644 --- a/tools/libxl/libxl_cpuid.c +++ b/tools/libxl/libxl_cpuid.c @@ -419,7 +419,6 @@ int libxl_cpuid_parse_config_xend(libxl_cpuid_policy_list *cpuid, void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, libxl_domain_build_info *info) { - libxl_cpuid_policy_list cpuid = info->cpuid; bool pae = true; /* @@ -435,12 +434,7 @@ void libxl__cpuid_legacy(libxl_ctx *ctx, uint32_t domid, if (info->type == LIBXL_DOMAIN_TYPE_HVM) pae = libxl_defbool_val(info->u.hvm.pae); - xc_cpuid_apply_policy(ctx->xch, domid, NULL, 0, pae); - - if (!cpuid) - return; - - xc_cpuid_set(ctx->xch, domid, info->cpuid); + xc_cpuid_apply_policy(ctx->xch, domid, NULL, 0, pae, info->cpuid); } static const char *input_names[2] = { "leaf", "subleaf" }; -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:16:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:16:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuT-0008BB-J7; Mon, 15 Jun 2020 14:16:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkpuS-0007qe-6W for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:16:24 +0000 X-Inumbo-ID: bbfd69de-af12-11ea-bca7-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bbfd69de-af12-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 14:15:58 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: EtXH1WdzMpHjyZOQeIdyhi9iU7Fe/sa9euWbx33WnPg4hcWHVky1sgjOroslZVaqfQ/xNZMRDY wCDok0bvE3/4bQb9XvjO9RBr4rr44GuBU7kGy7fMeo93lz35pxarJ8TSK/JSaoi1eXw3Y/RGOB SO9QEuzvHnwrp4CVJhJsXZHjdD7CgbrCkVTwDeQeXj7eJmLHVXjsebC318CTWrDJLH4RLRj1vm 3/rljIVBSMTr7IdZ8Hw3iuegwReeXb3LZN6uXv/v7ZOScXbxnjkRC2W0OTQPvR8debHpR2Po7o BKU= X-SBRS: 2.7 X-MesageID: 20839542 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20839542" From: Andrew Cooper To: Xen-devel Subject: [PATCH 8/9] x86/cpuid: Introduce missing feature adjustment in calculate_pv_def_policy() Date: Mon, 15 Jun 2020 15:15:31 +0100 Message-ID: <20200615141532.1927-9-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Paul Durrant , Wei Liu , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This was an accidental asymmetry with the HVM side. No change in behaviour at this point. Fixes: 83b387382 ("x86/cpuid: Introduce and use default CPUID policies") Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant --- xen/arch/x86/cpuid.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index ee11087626..f2fc0aa895 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -402,6 +402,8 @@ static void __init calculate_pv_def_policy(void) for ( i = 0; i < ARRAY_SIZE(pv_featureset); ++i ) pv_featureset[i] &= pv_def_featuremask[i]; + guest_common_feature_adjustments(pv_featureset); + sanitise_featureset(pv_featureset); cpuid_featureset_to_policy(pv_featureset, p); recalculate_xstate(p); -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:26:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:26:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkq3p-0001A4-Lv; Mon, 15 Jun 2020 14:26:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkq3o-00019n-GF for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:26:04 +0000 X-Inumbo-ID: 216686ec-af14-11ea-b802-12813bfff9fa Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 216686ec-af14-11ea-b802-12813bfff9fa; Mon, 15 Jun 2020 14:25:58 +0000 (UTC) Received: from webmail.moloch.sk (w3-s.a.lucina.net [62.176.169.73]) by smtp.lucina.net (Postfix) with ESMTPSA id D151C122804; Mon, 15 Jun 2020 16:25:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592231157; bh=ipoQyzITtXCOufopaXaEd/sFV/+23MisWaZOGj5QRF4=; h=Date:From:To:Subject:From; b=ZljQcOLci8Lxmy6VqcNFFxdz85y2zpztbaK2cudxoyfTmcSGqX3lW52gyoAKcBvo1 b/GeZYtQyTsDcj2spl7MOxlCoVoJ/4JYl7JJJ/s9g6/aW68GoOOneNFQlg+3vXerGA 8hvNpXMJzkgCJQIEGUUjX7dR+zFBGHKGvfNCqmCGuAwTXIwqL8/EChT0mGzxZdyUrr Ne5s1pJX1hbLaBsbmiVR5PcM/jeOWyhC/sFgoDLh+cCDcnxqp0/N0W7HnUe5M4GOjH nmEB8HtuNj4MY1UxuJSVD/OFV8mUUEXAdzed9atYc1Pm3JaMOAPTjBKshqg3OgAMNq VhuHHquq/WDjQ== MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 15 Jun 2020 16:25:57 +0200 From: Martin Lucina To: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org Subject: Event delivery and "domain blocking" on PVHv2 Mail-Followup-To: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org, martin@lucina.net Message-ID: <62479d08f7650c22678d7a86851eafc4@lucina.net> X-Sender: martin@lucina.net User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, puzzle time: In my continuing explorations of the PVHv2 ABIs for the new MirageOS Xen stack, I've run into some issues with what looks like missed deliveries of events on event channels. While a simple unikernel that only uses the Xen console and effectively does for (1..5) { printf("foo"); sleep(1); } works fine, once I plug in the existing OCaml Xenstore and Netfront code, the behaviour I see is that the unikernel hangs in random places, blocking as if an event that should have been delivered has been missed. Multiple runs of the unikernel have it block at different places during Netfront setup, and sometimes it will run as far as a fully setup Netfront, and then wait for network packets. However, even if it gets that far, packets are not actually being delivered: Solo5: Xen console: port 0x2, ring @0x00000000FEFFF000 | ___| __| _ \ | _ \ __ \ \__ \ ( | | ( | ) | ____/\___/ _|\___/____/ Solo5: Bindings version v0.6.5-6-gf4b47d11 Solo5: Memory map: 256 MB addressable: Solo5: reserved @ (0x0 - 0xfffff) Solo5: text @ (0x100000 - 0x28ffff) Solo5: rodata @ (0x290000 - 0x2e0fff) Solo5: data @ (0x2e1000 - 0x3fafff) Solo5: heap >= 0x3fb000 < stack < 0x10000000 gnttab_init(): pages=1 entries=256 2020-06-15 13:42:08 -00:00: INF [net-xen frontend] connect 0 >>>> Sometimes we hang here 2020-06-15 13:42:08 -00:00: INF [net-xen frontend] create: id=0 domid=0 2020-06-15 13:42:08 -00:00: INF [net-xen frontend] sg:true gso_tcpv4:true rx_copy:true rx_flip:false smart_poll:false 2020-06-15 13:42:08 -00:00: INF [net-xen frontend] MAC: 00:16:3e:30:49:52 >>>> Or here gnttab_grant_access(): ref=0x8, domid=0x0, addr=0x8f9000, readonly=0 gnttab_grant_access(): ref=0x9, domid=0x0, addr=0x8fb000, readonly=0 evtchn_alloc_unbound(remote=0x0) = 0x4 2020-06-15 13:42:08 -00:00: INF [ethernet] Connected Ethernet interface 00:16:3e:30:49:52 2020-06-15 13:42:08 -00:00: INF [ARP] Sending gratuitous ARP for 10.0.0.2 (00:16:3e:30:49:52) gnttab_grant_access(): ref=0xa, domid=0x0, addr=0x8fd000, readonly=1 2020-06-15 13:42:08 -00:00: INF [udp] UDP interface connected on 10.0.0.2 2020-06-15 13:42:08 -00:00: INF [tcpip-stack-direct] stack assembled: mac=00:16:3e:30:49:52,ip=10.0.0.2 Gntref.get(): Waiting for free grant Gntref.get(): Waiting for free grant >>>> The above are also rather odd, but not related to event channel >>>> delivery, so one problem at a time... >>>> Once we get this far, packets should be flowing but aren't (either >>>> way). However, Xenstore is obviously working, as we wouldn't get >>>> through Netfront setup without it. Given that I've essentially re-written the low-level event channel C code, I'd like to verify that the mechanisms I'm using for event delivery are indeed the right thing to do on PVHv2. For event delivery, I'm registering the upcall with Xen as follows: uint64_t val = 32ULL; val |= (uint64_t)HVM_PARAM_CALLBACK_TYPE_VECTOR << 56; int rc = hypercall_hvm_set_param(HVM_PARAM_CALLBACK_IRQ, val); assert(rc == 0); i.e. upcalls are to be delivered via IDT vector. Questions: 1. Being based on the Solo5 virtio code, the low-level setup code is doing the "usual" i8259 PIC setup, to remap the PIC IRQs to vectors 32 and above. Should I be doing this initialisation for Xen PVH at all? I'm not interested in using the PIC for anything, and all interrupts will be delivered via Xen event channels. 2. Related to the above, the IRQ handler code is ACKing the interrupt after the handler runs. Should I be doing that? Does ACKing "IRQ" 0 on the PIC have any interactions with Xen's view of event channels/pending upcalls? Next, for a PVHv2, uniprocessor only guest, is the following flow sufficient to unmask an event channel? struct shared_info *s = SHARED_INFO(); int pending = 0; atomic_sync_btc(port, &s->evtchn_mask[0]); pending = sync_bt(port, &s->evtchn_mask[0]); if (pending) { /* * Slow path: * * If pending is set here, then there was a race, and we lost the * upcall. Mask the port again and force an upcall via a call to * hyperspace. * * This should be sufficient for HVM/PVHv2 based on my understanding of * Linux drivers/xen/events/events_2l.c. */ atomic_sync_bts(port, &s->evtchn_mask[0]); hypercall_evtchn_unmask(port); } Lastly, the old PV-only Mini-OS based stack would do delays ("block the domain") by doing a HYPERVISOR_set_timer_op(deadline) followed by a HYPERVISOR_sched_op(SCHEDOP_block,0 ). In the new code, I'm doing the following (based on what Mini-OS seems to be doing for HVM): solo5_time_t deadline = Int64_val(v_deadline); if (solo5_clock_monotonic() < deadline) { hypercall_set_timer_op(deadline); __asm__ __volatile__ ("hlt" : : : "memory"); /* XXX: cancel timer_op here if woken up early? */ } Again, is this the right thing to do for PVH? As the comment says, do I need to cancel the timer_op? I understood the semantics to be "fire once at/after the time deadline is reached", if that is indeed the case then with my current VIRQ_TIMER handler which does nothing in the interrupt context and has no side effects I should be fine. I can also post the code that does the actual demuxing of events from Xen (i.e. the upcall handler), but I've read through that several times now and I don't think the problem is there; adding diagnostic prints to both the low-level C event channel code and higher-level OCaml Activations code confirms that received events are being mapped to their ports correctly. Any advice much appreciated, Thanks, Martin From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:33:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:33:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqAW-00022V-CV; Mon, 15 Jun 2020 14:33:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqAV-00022Q-3z for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:32:59 +0000 X-Inumbo-ID: 1bfc8be2-af15-11ea-8496-bc764e2007e4 Received: from mail-qk1-x743.google.com (unknown [2607:f8b0:4864:20::743]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1bfc8be2-af15-11ea-8496-bc764e2007e4; Mon, 15 Jun 2020 14:32:58 +0000 (UTC) Received: by mail-qk1-x743.google.com with SMTP id q8so15841502qkm.12 for ; Mon, 15 Jun 2020 07:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=xoZYTOrbaJ/qtaL6gpEpGtLcw0cV9fBngumMP/8sReM=; b=QqMwmPns7wD3eXZ6V0fxcUauGKmQdLa0qaGV+ui0UVjeLm3GJOf8PkWn05rZLVZ6cU MNa1fpNum1BkwRikQ/FGMbdafVZwS/DW4pPKA+l2KZj/kagtsti+YhIbeAc50CW8KIP4 IQXfGQm3t3C2zqMW/IvYHKtXWtBV3F3xANmv00MdwJYw9bZNg767PYgzbMQ6XmcyDAFP RULDhhEdblcWtq6b5nfNxZxBvH57qI+MSLsKUuPU4B1KNXGpB3DyY7g8qbYTEmC+sUEf 023/tK/31qHeHLvT/0tXnylBikV/DgGwYRIAV+TGLSPQPx02Xxq+831Bor96wmzoU9ez 7lNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xoZYTOrbaJ/qtaL6gpEpGtLcw0cV9fBngumMP/8sReM=; b=lnThhLiyoH1qhaW+rBzO7A+/d8nbSwGiuY9WZb2HkyHItCxY6sIaxuKNvhkSwjR5Wh IKnWP2Jeozc+sgIBe0bbuQWh0bK4QvDmCJKFW695yO0xQKHDsEQernu9ivQ/dfuZRgxP Q9IYPm2fGIsaPA275alSWTZ/3on0MPvwhNj/hIPE3aTlZkaL/Ys70WBKrovdrNacRUSQ 1OgE8p4bWk7eIImUy0ML6iiCH4UllwM95vDV52XgpsWTICKDeOfeAMoS5aeNbJgeUZGH Y49rnpLYe796lSVayK4LfLYgiD19q1IZ4aedDY0xFCN7Emjkl+UUvxvfTxL6ewyRWfRV sIzQ== X-Gm-Message-State: AOAM532xzTk1d8sYUmf6pQRhuAQOmAYl+4x298E0kKl0brBj4p32hDOy D9QAOjssqBcjqiY9rL+q2+Y= X-Google-Smtp-Source: ABdhPJw/swk4IFbSzol+4IYT/MmFSzV1G1JXY4dekTCGcaYcTfpMcGWLNv9chzO3z40pRE2+DA0+Ew== X-Received: by 2002:a37:f505:: with SMTP id l5mr15143174qkk.118.1592231578399; Mon, 15 Jun 2020 07:32:58 -0700 (PDT) Received: from six (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252]) by smtp.gmail.com with ESMTPSA id d14sm10990442qkk.5.2020.06.15.07.32.56 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 Jun 2020 07:32:56 -0700 (PDT) Date: Mon, 15 Jun 2020 10:32:54 -0400 From: Nick Rosbrook To: Ian Jackson Subject: Re: [PATCH for-4.14] tools: check go compiler version if present Message-ID: <20200615143254.GA29455@six> References: <24291.45045.185355.587474@mariner.uk.xensource.com> <20200612215028.GA6286@six> <24295.31778.201405.748753@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24295.31778.201405.748753@mariner.uk.xensource.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , "xen-devel@lists.xenproject.org" , George Dunlap , Wei Liu , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > Ideally at some point maybe we would make this clearer but not now. Okay, sounds good. > Have you tested the situations you describe ? That might be a better > way of checking that it's right than the code inspection which is > obviously failing for me now... Yes, I have tested the following situations: (1) ./configure without go installed => go is not enabled (2) ./configure with go version < 1.11.1 => go is not enabled (3) ./configure with go version > 1.11.1 => go is enabled (4) ./configure --enable-golang without go installed => error (5) ./configure --enable-golang with go < 1.11.1 => error (6) ./configure --disable-golang in any case => go is not enabled > > I definitely think we want to fix this for 4.14. So thanks for your > continued help! You're welcome. Thank you again for the review. -NR From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:42:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:42:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqJl-0002tx-9y; Mon, 15 Jun 2020 14:42:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqJk-0002ts-BZ for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:42:32 +0000 X-Inumbo-ID: 7110f400-af16-11ea-b803-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7110f400-af16-11ea-b803-12813bfff9fa; Mon, 15 Jun 2020 14:42:31 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ++b6ryou+3hcsRjgvvXk2cARcqWt54xrYj6Dbbd7DKytNOiIzqcEbFteRSGV3BctjB9jzaipW1 2TQC8HLBGlQUrqPKZdlS61mob8ZJ76ooUYaWhxdqmcZi/TwRia5urNAYNlSE4aN3mgprbqThIN uF9qZm+h44kawlV7IXhVWFO4FTc8VpiNMuR582zRBmFuHehKFu7xASlYJfak/eHnbfmjPXYsXn FlWaS016lFKk9yx/F+gunBD/NnXlxTT3Ufo8nl67ciVIpWr9SGeo/URdLpxvwxjHSLO+tlSL3T Swc= X-SBRS: 2.7 X-MesageID: 20067924 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20067924" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.35026.88022.957662@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:42:26 +0100 To: Nick Rosbrook Subject: Re: [PATCH for-4.14] tools: check go compiler version if present In-Reply-To: <20200615143254.GA29455@six> References: <24291.45045.185355.587474@mariner.uk.xensource.com> <20200612215028.GA6286@six> <24295.31778.201405.748753@mariner.uk.xensource.com> <20200615143254.GA29455@six> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Nick Rosbrook , "xen-devel@lists.xenproject.org" , George Dunlap , Wei Liu , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Nick Rosbrook writes ("Re: [PATCH for-4.14] tools: check go compiler version if present"): > > Ideally at some point maybe we would make this clearer but not now. > > Okay, sounds good. > > > Have you tested the situations you describe ? That might be a better > > way of checking that it's right than the code inspection which is > > obviously failing for me now... > > Yes, I have tested the following situations: > > (1) ./configure without go installed => go is not enabled > (2) ./configure with go version < 1.11.1 => go is not enabled > (3) ./configure with go version > 1.11.1 => go is enabled > (4) ./configure --enable-golang without go installed => error > (5) ./configure --enable-golang with go < 1.11.1 => error > (6) ./configure --disable-golang in any case => go is not enabled Thorough! Acked-by: Ian Jackson Paul, this should go into 4.14. Can I have a release ack plase ? Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:46:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:46:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqNK-00032r-QL; Mon, 15 Jun 2020 14:46:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqNJ-00032j-Ha for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:46:13 +0000 X-Inumbo-ID: f51ae72e-af16-11ea-bca7-bc764e2007e4 Received: from mail-ej1-x631.google.com (unknown [2a00:1450:4864:20::631]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f51ae72e-af16-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 14:46:12 +0000 (UTC) Received: by mail-ej1-x631.google.com with SMTP id p20so17706870ejd.13 for ; Mon, 15 Jun 2020 07:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=bV64FyCkRZZlsx2qh3xtsoegoc2vBUKU/6KGSKbhJsQ=; b=qPkV5H0QY+NbcSESAgZ+OdZK88+AQ7Io0M5SD7SIOzYL1UD+WytVbA3xCRjiDssNFr lDRWtI6OZocIekfp9CuKTzsGyA3QlkBCIyDXvaU9RJwoEVYLTdB2kt80oolKSw/2+abN PO16ct7mpca1ez2NeCojZ9+fprlvAX5WU99W8vcs0dIpec79Hirl3ANNvUl5zGRSKqgD NF01naEr6UZsx7vyWcM+s2ep9AcZg1mwXcA0Q/4Np2IB9Sdz2nGUqCPmA31SmWw0MqF8 /VwzvupS8QQMPQyVhrnwGkfRs1TEnJiBYhBfZj+3HxpqmQf/PSAZ17flzPb9rAGjUgsy 9LJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=bV64FyCkRZZlsx2qh3xtsoegoc2vBUKU/6KGSKbhJsQ=; b=BZxJ2GNMzdVoeOlMOTCC9aMsYVp7x4enfBrWzXiKoi02qnQzUG9srj3lWkOKz+zn36 xBTkX6g00m4XCLvZd7J+TS3mNcAVpx8weLB4lNXcHI2dndSQhsXYKEpT7x1qYL9lwsPe qpWebbPrUIV+nyQrD6aTSBhTPORujY/tVwpQ6jY6rj+NNVZfP7mQ7xdAKI5QiygbWWwS mXwGMMVcIwmyoOmCJWtvLrmQHFDOPCxLY2+S8M27Zh6jx0UjwzdsrHr//1TAbQ3Yfg5l P5j8W9/1WZ2vAKnNsRIuY0zLGJnLKb/dnFY4qRnkhg7jAwMjsWmAPbwg53O4rx60AMxx 0mhA== X-Gm-Message-State: AOAM5312j7EjBHXReGSZC2+7+lb5uIUOoC/S29XLAj4NsQz1fepPLt/c 9sW1xoqav3/xcAGxWo32/Mw= X-Google-Smtp-Source: ABdhPJwm3Inq9ex3n+bYEY6HT3j9GFdFKAkT1o3yhAe4n9dfUsa9wQw7rtTS+xIQXmbacguk7nxGFw== X-Received: by 2002:a17:906:1386:: with SMTP id f6mr24978433ejc.66.1592232372123; Mon, 15 Jun 2020 07:46:12 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id h17sm8601980edw.92.2020.06.15.07.46.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 07:46:11 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Nick Rosbrook'" References: <24291.45045.185355.587474@mariner.uk.xensource.com> <20200612215028.GA6286@six> <24295.31778.201405.748753@mariner.uk.xensource.com> <20200615143254.GA29455@six> <24295.35026.88022.957662@mariner.uk.xensource.com> In-Reply-To: <24295.35026.88022.957662@mariner.uk.xensource.com> Subject: RE: [PATCH for-4.14] tools: check go compiler version if present Date: Mon, 15 Jun 2020 15:46:10 +0100 Message-ID: <002e01d64323$b64bddf0$22e399d0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLvj3Cx2rRj513IhzeScODzcD7DmQK76zXVApflE6YCG+OqCAHzOOCIAtIKIUWmRYCswA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Nick Rosbrook' , xen-devel@lists.xenproject.org, 'George Dunlap' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 15 June 2020 15:42 > To: Nick Rosbrook > Cc: xen-devel@lists.xenproject.org; paul@xen.org; George Dunlap ; Nick > Rosbrook ; Wei Liu > Subject: Re: [PATCH for-4.14] tools: check go compiler version if present > > Nick Rosbrook writes ("Re: [PATCH for-4.14] tools: check go compiler version if present"): > > > Ideally at some point maybe we would make this clearer but not now. > > > > Okay, sounds good. > > > > > Have you tested the situations you describe ? That might be a better > > > way of checking that it's right than the code inspection which is > > > obviously failing for me now... > > > > Yes, I have tested the following situations: > > > > (1) ./configure without go installed => go is not enabled > > (2) ./configure with go version < 1.11.1 => go is not enabled > > (3) ./configure with go version > 1.11.1 => go is enabled > > (4) ./configure --enable-golang without go installed => error > > (5) ./configure --enable-golang with go < 1.11.1 => error > > (6) ./configure --disable-golang in any case => go is not enabled > > Thorough! > > Acked-by: Ian Jackson > > Paul, this should go into 4.14. Can I have a release ack plase ? You may... Release-acked-by: Paul Durrant > > Thanks, > Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:49:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:49:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqPw-0003BH-9H; Mon, 15 Jun 2020 14:48:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqPv-0003BC-5k for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:48:55 +0000 X-Inumbo-ID: 553512ce-af17-11ea-b803-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 553512ce-af17-11ea-b803-12813bfff9fa; Mon, 15 Jun 2020 14:48:54 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: nv3msrCV/3R+lRdCS9IwrDpR1FfYf6iFAp+/8txCAc3V4Uc9H7cWJ+cE69CP0pqrFFyDQDW3QU J6rHz38DSTPCKPkg+4Lt6F1+LUfTzeIbL4/UpgjsUJugzqSWkymvVV8yALgCwNJ2qsYZe7Fxg7 GhvCsbpMpzw/r1xg+qUZsj+2UsyTD9i5uknjqPh03gMyJ8CfeN0wibg6bHwNXArrLoP7Sd3Chu Z4Hvhziqev/AT7vtdwBpyLspjdP0xCGkJlg+KQufptDA9AZczqlRHtrU7wnKt9Z8pucbXz4Sek Eds= X-SBRS: 2.7 X-MesageID: 20082872 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20082872" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.35408.178162.309295@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:48:48 +0100 To: Andrew Cooper Subject: Re: [PATCH for-4.13] tools/libxl: Fix memory leak in libxl_cpuid_set() In-Reply-To: <20200612173227.4103-1-andrew.cooper3@citrix.com> References: <20200612173227.4103-1-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("[PATCH for-4.13] tools/libxl: Fix memory leak in libxl_cpuid_set()"): > xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to > free() seeing as it discards the results. > > This is logically a backport of c/s b91825f628 "tools/libxc: Drop > config_transformed parameter from xc_cpuid_set()" but rewritten as one caller > of xc_cpuid_set() does use returned values. > > Signed-off-by: Andrew Cooper > --- > CC: Ian Jackson > > Applicable for 4.13 and older. Thanks. I have committed this to 4.13 and 4.12. 4.12 is no longer supported for bugfixes like this one. > I'm not going to touch the Ocaml bindings - they're wrong in multiple ways > including this memory leak, and we deleted them in 4.14 because they were > totally unused. That makes sense to me. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:50:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:50:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqRE-0003u4-LN; Mon, 15 Jun 2020 14:50:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqRD-0003tn-4G for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:50:15 +0000 X-Inumbo-ID: 84bdda80-af17-11ea-b805-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 84bdda80-af17-11ea-b805-12813bfff9fa; Mon, 15 Jun 2020 14:50:13 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: vH+SYFSDxVfeIExTJUAhXlBm1uSxKSzSwvlUg+2Y/4egLFqj1hh3X3Cof+Vv3H76sKLs+D5Rxj 2j7g7UP2CoI0PDLsK90RqOz4NUu3TJWPLNfx+DjLhNDT61+myvv9C1rLKiNXzqQq/9Gai3MvhQ wFZVflB8bAjzl/XIdldWQiosHCw57Q/c2UKNfcA5OvqcE6Ti0qsnD51gzbTH5gPw2mQrrMkgKN ZndOyF0ZDcDNHy8Tje1wP1xNAQARhKl0pvSSIXkpPATOd9GSCO1X9xXSSj0T/tyutS6r5sos8+ 1ZU= X-SBRS: 2.7 X-MesageID: 20303476 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20303476" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.35482.331727.352030@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:50:02 +0100 To: "paul@xen.org" Subject: RE: [PATCH for-4.14] tools: check go compiler version if present In-Reply-To: <002e01d64323$b64bddf0$22e399d0$@xen.org> References: <24291.45045.185355.587474@mariner.uk.xensource.com> <20200612215028.GA6286@six> <24295.31778.201405.748753@mariner.uk.xensource.com> <20200615143254.GA29455@six> <24295.35026.88022.957662@mariner.uk.xensource.com> <002e01d64323$b64bddf0$22e399d0$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Nick Rosbrook' , "xen-devel@lists.xenproject.org" , 'Nick Rosbrook' , 'Wei Liu' , George Dunlap Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: [PATCH for-4.14] tools: check go compiler version if present"): > > Acked-by: Ian Jackson > > > > Paul, this should go into 4.14. Can I have a release ack plase ? > > You may... > > Release-acked-by: Paul Durrant Thanks, pushed. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:51:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:51:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqSa-00041W-5R; Mon, 15 Jun 2020 14:51:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqSY-00041O-NS for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:51:38 +0000 X-Inumbo-ID: b64e625e-af17-11ea-b805-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b64e625e-af17-11ea-b805-12813bfff9fa; Mon, 15 Jun 2020 14:51:37 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: f73RR2H5j2vDOwXb/RJuXFDuihdqf6B5sew/Fa3YXkJOzvggFGXRB8n/5vnMx/B7zgRdUBr5hP t2L/p8JpatIT75SNug2hBVfvZ2c8R7nd1yJCPtgSRaXeAaQwTnwCPyjr01v94WiPx9tEvBcdzs IQZ/ZzR7NYeuSPU0oKERpcdNWKwMPYkNopnYJ3OJUtchGTQITdSC4R3N5HrhUsAAQUr8N8xEcR GdgUxAfbM7XiOeFAkNfB4bex4INi2uXyiQBOLNZjHxaaR0o08fgkNtYxSaDNvmEisAFiboWf9S CpA= X-SBRS: 2.7 X-MesageID: 20083199 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20083199" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.35571.422130.264071@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:51:31 +0100 To: Andrew Cooper Subject: Re: [PATCH 1/9] tools/libx[cl]: Introduce struct xc_xend_cpuid for xc_cpuid_set() In-Reply-To: <20200615141532.1927-2-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-2-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Jan Beulich , Wei Liu , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("[PATCH 1/9] tools/libx[cl]: Introduce struct xc_xend_cpuid for xc_cpuid_set()"): > In order to combine the functionality of xc_cpuid_set() with > xc_cpuid_apply_policy(), arrange to pass the data in a single contained > struct, rather than two arrays. > > libxl__cpuid_policy is the ideal structure to use, but that would introduce a > reverse dependency between libxc and libxl. Introduce xc_xend_cpuid (with a > transparent union to provide more useful names for the inputs), and use this > structure in libxl. > > The public API has libxl_cpuid_policy as an opaque type referencing > libxl__cpuid_policy. Drop the inappropriate comment about its internals, and > use xc_xend_cpuid as a differently named opaque backing object. Users of both > libxl and libxc are not permitted to look at the internals. > > No change in behaviour. > Acked-by: Ian Jackson From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:52:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:52:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqTQ-000469-FR; Mon, 15 Jun 2020 14:52:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqTP-00045x-0r for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:52:31 +0000 X-Inumbo-ID: d5f1254c-af17-11ea-8496-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d5f1254c-af17-11ea-8496-bc764e2007e4; Mon, 15 Jun 2020 14:52:30 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: u7vFcgU0ZecUN9Y+nU75qkrK6QsHvMYHBHG02UDxLpDm/8PY7vLhfQHCaKFyzsnCEn0dfPcLJ0 v6vuDqkxTss84ZR8uhu3sLB91jgyqzCwXeBQN7H0TeWkPrCYCAqr9ISuFvA60Wgh9KuqQcpMyU rri4OV2+ELAxdZ7dUCkHzm8WkKjuBQpgl3Tx1AG26rU3BmAKJ6ZMl8ol5/x9Ucnfcq7BOTB3FY x5Th+XAi96+WGGrowGc6nStmipmP0esBz5ZKsy8y8n2LtdEGR1ON2U5cgEsM9Zfxpw055WDyNM ilU= X-SBRS: 2.7 X-MesageID: 20069067 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20069067" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.35624.644030.417783@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:52:24 +0100 To: Andrew Cooper Subject: Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted In-Reply-To: <20200615141532.1927-3-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-3-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("[PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted"): > The existing x86_cpuid_copy_to_buffer() does produce sorted results, and we're > about to start relying on this. Extend the unit tests. > > As test_cpuid_serialise_success() is a fairly limited set of synthetic > examples right now, introduce test_cpuid_current() to operate on the full > policy for the current CPU. > > Tweak the fail() macro to allow for simplified control flow. > > Signed-off-by: Andrew Cooper Acked-by: Ian Jackson I don't think anything in our normal dev workflow runs this automatically ? Maybe this would be something for us to think about... Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:55:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:55:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqVm-0004H3-T8; Mon, 15 Jun 2020 14:54:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqVl-0004Gy-UK for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:54:57 +0000 X-Inumbo-ID: 2dac61e8-af18-11ea-8496-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2dac61e8-af18-11ea-8496-bc764e2007e4; Mon, 15 Jun 2020 14:54:57 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: l1fclsBTfHR/StnfDRWourWOGq9MJluDdFLK5ZduVpRg7b4MLYtKtIbu/g5QDP+xu9+hNt4Rr6 cyEok8Wd9Moc6JPaQdLr3ljNXjfP4NLsL27lK16esa5kQ/8Z9KWSkk3JovQhgos+VPQS9TYNaA R45788FpvlmFoGYu3tK5GEuNRAR/7o2YjrMy8emW9r65LoAH3C92OU2hFyRbXPgh/ni0LxGNQq 8r0uFee8UX/h0pzw8T/ghhTZgYlkz98G/kfYTLmBGadLlUGxTP9z4pyc978LyNktf22rp+VlYc 4/U= X-SBRS: 2.7 X-MesageID: 20083622 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20083622" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.35771.662354.527867@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:54:51 +0100 To: Andrew Cooper Subject: Re: [PATCH 3/9] tools/libx[cl]: Move processing loop down into xc_cpuid_set() In-Reply-To: <20200615141532.1927-4-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-4-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Jan Beulich , Wei Liu , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("[PATCH 3/9] tools/libx[cl]: Move processing loop down into xc_cpuid_set()"): > Currently, libxl__cpuid_legacy() passes each element of the policy list to > xc_cpuid_set() individually. This is wasteful both in terms of the number of > hypercalls made, and the quantity of repeated merging/auditing work performed > by Xen. > > Move the loop processing down into xc_cpuid_set(), which allows us to do one > set of hypercalls, rather than one per list entry. > > In xc_cpuid_set(), obtain the full host, guest max and current policies to > begin with, and loop over the xend array, processing one leaf at a time. > Replace the linear search with a binary search, seeing as the serialised > leaves are sorted. > > No change in behaviour from the guests point of view. This is not my area of expertise. Ideally at this stage of the release I would like an ack from a 2nd hypervisor maintainer. The processing code in libxc looks OK to me. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:55:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:55:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqWF-0004LH-9O; Mon, 15 Jun 2020 14:55:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqWE-0004Kw-5Q for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:55:26 +0000 X-Inumbo-ID: 3e9ead6c-af18-11ea-b7bb-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3e9ead6c-af18-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 14:55:25 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: HFy1OS1RADCTFU66zfY/qVHvrHsV0QNMK57k/2l5CNXEuONzqAyJlk4i0Xk0GqyiPgIMRK2y/c YCQZGstmayEvCPRxycynCyHx23PCQAf1GCe6+NfNPxTHR+FqMyND7czeAOdHecqGFyBCphi860 a0ochkHuMoxwZ0MWbDT3cTo6NT8LAnrY4QUX/zLay/oR9j7PXvkC92XrDyYu1ih+yWBUfnp1Wq ZyfvVHII5R8ATv8if/S8oiaD37R02tLrz8fL6XiAD0jeC0bz+nedGXpxH33xYY2ug7D3y/qo2I mSg= X-SBRS: 2.7 X-MesageID: 20415087 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20415087" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.35800.851518.548162@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:55:20 +0100 To: Andrew Cooper Subject: Re: [PATCH 4/9] tools/libx[cl]: Merge xc_cpuid_set() into xc_cpuid_apply_policy() In-Reply-To: <20200615141532.1927-5-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-5-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Jan Beulich , Wei Liu , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("[PATCH 4/9] tools/libx[cl]: Merge xc_cpuid_set() into xc_cpuid_apply_policy()"): > This reduces the number of CPUID handling entry-points to just one. > > No functional change. Acked-by: Ian Jackson From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:56:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:56:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqWp-0004RB-Jp; Mon, 15 Jun 2020 14:56:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqWo-0004R2-Lf for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:56:02 +0000 X-Inumbo-ID: 53d7e2fc-af18-11ea-b807-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 53d7e2fc-af18-11ea-b807-12813bfff9fa; Mon, 15 Jun 2020 14:56:01 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Xqf7bF+CWtoO8YKHLW7lzHaz7j/K5hPwpmyFfv429rgnyfOGYkUzKIYb3KeVbvjHC5ZOvJNUEi dmNZOkZF/6eYRhbGFJTYoiGXpo0eEcCqbh3avqIbNi6RIEkcf7ReKyqo50UgmRKK5zyu2EFrtZ Ef5/Ez7WuIhVdDAaiNVZ3+cPUVKXJOwEDunaW+zYBRGnS+acogryN8ZUy3RUAIkfNo6mkYHPrn l93wyKDFp408fylCfO4vltxhGGDz0qvepF8aMVCkpISrvSFZu8JRvITkQ23nKWnMwFwbmYkV7o M4Q= X-SBRS: 2.7 X-MesageID: 20069424 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20069424" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.35835.908263.151283@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:55:55 +0100 To: Andrew Cooper Subject: Re: [PATCH 5/9] tools/libx[cl]: Plumb bool restore down into xc_cpuid_apply_policy() In-Reply-To: <20200615141532.1927-6-andrew.cooper3@citrix.com> References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-6-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Jan Beulich , Wei Liu , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("[PATCH 5/9] tools/libx[cl]: Plumb bool restore down into xc_cpuid_apply_policy()"): > In order to safely disable some features by default, without breaking > migration from 4.13 or older, the CPUID logic needs to distinguish the two > cases. > > Plumb a restore boolean down from the two callers of libxl__cpuid_legacy() all > the way down into xc_cpuid_apply_policy(). > > No functional change. Acked-by: Ian Jackson From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:56:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:56:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqXH-0004Ws-91; Mon, 15 Jun 2020 14:56:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqXG-0004Ud-Ih for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:56:30 +0000 X-Inumbo-ID: 5ebfdee0-af18-11ea-b807-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5ebfdee0-af18-11ea-b807-12813bfff9fa; Mon, 15 Jun 2020 14:56:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Reply-To:Message-Id:Date:Subject:To:From:Sender:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=dv/wHwxCaJTEGpCKu6iwv+PQf4ogcSKnHpLXGmCAhjk=; b=5pwfAO7U9E4Txh/zWFehuHw0PR Y6gX2AiQHmCmLS31Sk0jl84lD+fu12NxavaorDN0PetREYrcwt9fC2RPQJSpxhcnTrSGmAurHm4++ o6VPpoGai85UXowRcjxP22ny4kwpvwtgmfHgr9ZD3nXGdey6HQ0cRScId2eA+X5g+204=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqX5-0002hE-49; Mon, 15 Jun 2020 14:56:19 +0000 Received: from 54-240-197-234.amazon.com ([54.240.197.234] helo=CBG-R90WXYV0.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jkqX4-00086Z-R4; Mon, 15 Jun 2020 14:56:19 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Subject: Xen 4.14 RC2 Date: Mon, 15 Jun 2020 15:56:17 +0100 Message-Id: <20200615145617.6761-1-paul@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: xen-devel@lists.xenproject.org, paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi all, Xen 4.14 RC2 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.14.0-rc2 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.14.0-rc2/xen-4.14.0-rc2.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.14.0-rc2/xen-4.14.0-rc2.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (paul@xen.org). As a reminder, there will be a Xen Test Day. Please see the test day schedule at https://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions. Paul Durrant From xen-devel-bounces@lists.xenproject.org Mon Jun 15 14:57:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 14:57:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqYb-0004jL-KV; Mon, 15 Jun 2020 14:57:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqYa-0004jC-L6 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:57:52 +0000 X-Inumbo-ID: 92ebf118-af18-11ea-b807-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 92ebf118-af18-11ea-b807-12813bfff9fa; Mon, 15 Jun 2020 14:57:47 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: WvcSRmTTjTOvfKROtlgMP+AM2tivDfiioW0lo4OJ4pGLaWBxN7RR0ylykaGAdfGw/72/rCFUiq vfXM/yv371Qo1G34PkIH1nHZ1YJYwH1PPs24nACg1HGClGIAeLPUZr+O+YBPdgaihSteAi7+i9 vpOJCpOS7QSYITeljK8DPTRN062IMXTUSNG+YMouE73zCVNhzbxVa+69/4FzB4P8SPPNXtNUnB EUOL1uD+qeUGVhgOB+MN1FMFgMo70eFrN2FJ6q5CoFLiuUEpJThmsabqAh4p9p9LSO/Z9Zj1mC UIA= X-SBRS: 2.7 X-MesageID: 20369882 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20369882" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.35941.840393.542543@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:57:41 +0100 To: Andrew Cooper Subject: Re: [PATCH] tools/libxengnttab: correct size of allocated memory In-Reply-To: References: <20200520083501.31704-1-jgross@suse.com> <24261.17303.413916.29534@mariner.uk.xensource.com> <20200520155621.GN54375@Air-de-Roger> <05eac1e1-63a3-1d03-9f91-d0ffdcc44f23@suse.com> <00f701d64009$c2c10000$48430000$@xen.org> <24295.32909.686801.47956@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?iso-8859-1?Q?'J=FCrgen_Gro=DF'?= , "xen-devel@lists.xenproject.org" , Roger Pau Monne , 'Wei Liu' , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("Re: [PATCH] tools/libxengnttab: correct size of allocated memory"): > I already committed it, seeing as it was fully acked. > > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=aad20e538d7ba0e36f5ed8d2bebb74096e3a6d7f That must be why it didn't apply :-). Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:00:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:00:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqae-0004vM-0k; Mon, 15 Jun 2020 15:00:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqac-0004vE-Nq for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 14:59:58 +0000 X-Inumbo-ID: e08f5784-af18-11ea-b807-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e08f5784-af18-11ea-b807-12813bfff9fa; Mon, 15 Jun 2020 14:59:57 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: o4ViAK7hESQ6SkCZ+/JEqLi/z5Zjg/YN7ficxMOhcvppD1ukBUk2P5kNEyd4p0Dh7moWWrzdIo WwXgPXP4A1SwrwlJCuHV+jftiChJEuGLVpAOMAe38p5yTg+J0lySjwwlUUqJogoFE4rhqnfuS3 zVEf9uYY+Yb+Vq5qwBvSKm31JIrCkvPFRy/5QdTMbtON5X45u5JQwY39wdZkuduPKJnVWEjjq6 XN4BlHkZ50Anmwvce44bKq9Jz0iuX3Nyz+Hs3RpPKpBNzaXDGO+ZCsM1l8KY31UM0qa25TpkLC qhM= X-SBRS: 2.7 X-MesageID: 20415626 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20415626" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.36070.945693.791220@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 15:59:50 +0100 To: Grzegorz Uriasz , Jan Beulich , Andrew Cooper , Kevin Tian , Paul Durrant Subject: Re: [PATCH] libxl: tooling expects wrong errno In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , "jakub@bartmin.ski" , "marmarek@invisiblethingslab.com" , "j.nowak26@student.uw.edu.pl" , Anthony Perard , "xen-devel@lists.xenproject.org" , "contact@puzio.waw.pl" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Grzegorz Uriasz writes ("[PATCH] libxl: tooling expects wrong errno"): > When iommu is not enabled for a given domain then pci passthrough > hypercalls such as xc_test_assign_device return EOPNOTSUPP. > The code responsible for this is in "iommu_do_domctl" inside > xen/drivers/passthrough/iommu.c > This patch fixes the error message reported by libxl when assigning > pci devices to domains without iommu. > > Signed-off-by: Grzegorz Uriasz > Tested-by: Grzegorz Uriasz > --- > tools/libxl/libxl_pci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > index 957ff5c8e9..bc5843b137 100644 > --- a/tools/libxl/libxl_pci.c > +++ b/tools/libxl/libxl_pci.c > @@ -1561,7 +1561,7 @@ void libxl__device_pci_add(libxl__egc *egc, uint32_t domid, > LOGD(ERROR, domid, > "PCI device %04x:%02x:%02x.%u %s?", > pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func, > - errno == ENOSYS ? "cannot be assigned - no IOMMU" > + errno == EOPNOTSUPP ? "cannot be assigned - no IOMMU" > : "already assigned to a different guest"); > goto out; > } Thanks. I have addressed some Xen IOMMU maintainers. Can you confirm whether this is right ? Regards, Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:00:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:00:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqbO-0005fp-AW; Mon, 15 Jun 2020 15:00:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqbN-0005fd-5P for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:00:45 +0000 X-Inumbo-ID: fc4d877b-af18-11ea-b807-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fc4d877b-af18-11ea-b807-12813bfff9fa; Mon, 15 Jun 2020 15:00:44 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: iA9dAEPWvvElXBYE/r76lYVhY+kVnJeKSeon2KGW2OJeHj/NKvYKsC/FzQKK3qBU9po8shJvyC 1cXV4CAyRTVpaGTOD2M3PXOPcFpHP52Xa7yt2D2YAEeaHsHD8P0RvqiO2Jv8eYrS+Hp/iSogmh UbzYTAplQoTHuFJi1J+p8x8nnSpNdszXjCk5QIQLKGmo62Nn1rFxnRv32QqkhWOLhoOgve0BdX SGaESY5esALFqvImkYmvcyvrX3Y46++Kbra1rCkAfLeapjTxxDKFnPP6AFaxAlFPTS3ApV0gPT YvY= X-SBRS: 2.7 X-MesageID: 20084269 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20084269" Subject: Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted To: Ian Jackson References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-3-andrew.cooper3@citrix.com> <24295.35624.644030.417783@mariner.uk.xensource.com> From: Andrew Cooper Message-ID: Date: Mon, 15 Jun 2020 16:00:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <24295.35624.644030.417783@mariner.uk.xensource.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15/06/2020 15:52, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted"): >> The existing x86_cpuid_copy_to_buffer() does produce sorted results, and we're >> about to start relying on this. Extend the unit tests. >> >> As test_cpuid_serialise_success() is a fairly limited set of synthetic >> examples right now, introduce test_cpuid_current() to operate on the full >> policy for the current CPU. >> >> Tweak the fail() macro to allow for simplified control flow. >> >> Signed-off-by: Andrew Cooper > Acked-by: Ian Jackson > > I don't think anything in our normal dev workflow runs this > automatically ? Maybe this would be something for us to think > about... Nothing runs it by default, but it is part of my prepush testing for anything in the relevant area. We should do something better, but its not totally trivial.  The x86 emulator test for example needs a fairly bleeding edge version of binutils, given that we routinely add support for bleeding edge instruction groups. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:03:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:03:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqeP-0005u7-Ui; Mon, 15 Jun 2020 15:03:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqeO-0005u1-UM for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:03:52 +0000 X-Inumbo-ID: 6bdfef6a-af19-11ea-b807-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6bdfef6a-af19-11ea-b807-12813bfff9fa; Mon, 15 Jun 2020 15:03:51 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 4lB6PxmJeYWm+XlMP7xLA7fOZ65fLTIYKq2IWee2/NV0h8GNDq8KuKRB0tw0ExAun4d0xt99+Y JIqAujQMNtXqgN6yl/5kju6fa+ZH+5uQdEsf4vss3b/3nUkMQm6TsKgdCTQJ+bl2Xb7cLEBCyH 8J/vatIiDd1csX3H43MUT143iOopgZrSCJjJwLnHSSFnEtmMmZuERLWg0ttNCX4CC/OF3hXZVp 1mEsoCFz9tEv8Ffm/tI6pnNVGNUTEwFVxcT9fe75Q3H4krSOky7EFDPt/AA0GrbT9SE+uMUU6y jgs= X-SBRS: 2.7 X-MesageID: 20305325 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,514,1583211600"; d="scan'208";a="20305325" Date: Mon, 15 Jun 2020 17:03:44 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: , , Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200615150344.GG735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <62479d08f7650c22678d7a86851eafc4@lucina.net> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 04:25:57PM +0200, Martin Lucina wrote: > Hi, > > puzzle time: In my continuing explorations of the PVHv2 ABIs for the new > MirageOS Xen stack, I've run into some issues with what looks like missed > deliveries of events on event channels. That would be weird, as other OSes using PVHv2 seem to be fine. > While a simple unikernel that only uses the Xen console and effectively does > for (1..5) { printf("foo"); sleep(1); } works fine, once I plug in the > existing OCaml Xenstore and Netfront code, the behaviour I see is that the > unikernel hangs in random places, blocking as if an event that should have > been delivered has been missed. > > Multiple runs of the unikernel have it block at different places during > Netfront setup, and sometimes it will run as far as a fully setup Netfront, > and then wait for network packets. However, even if it gets that far, > packets are not actually being delivered: > > Solo5: Xen console: port 0x2, ring @0x00000000FEFFF000 > | ___| > __| _ \ | _ \ __ \ > \__ \ ( | | ( | ) | > ____/\___/ _|\___/____/ > Solo5: Bindings version v0.6.5-6-gf4b47d11 > Solo5: Memory map: 256 MB addressable: > Solo5: reserved @ (0x0 - 0xfffff) > Solo5: text @ (0x100000 - 0x28ffff) > Solo5: rodata @ (0x290000 - 0x2e0fff) > Solo5: data @ (0x2e1000 - 0x3fafff) > Solo5: heap >= 0x3fb000 < stack < 0x10000000 > gnttab_init(): pages=1 entries=256 > 2020-06-15 13:42:08 -00:00: INF [net-xen frontend] connect 0 > > > > > Sometimes we hang here > 2020-06-15 13:42:08 -00:00: INF [net-xen frontend] create: id=0 domid=0 > 2020-06-15 13:42:08 -00:00: INF [net-xen frontend] sg:true gso_tcpv4:true > rx_copy:true rx_flip:false smart_poll:false > 2020-06-15 13:42:08 -00:00: INF [net-xen frontend] MAC: 00:16:3e:30:49:52 > > > > > Or here > gnttab_grant_access(): ref=0x8, domid=0x0, addr=0x8f9000, readonly=0 > gnttab_grant_access(): ref=0x9, domid=0x0, addr=0x8fb000, readonly=0 > evtchn_alloc_unbound(remote=0x0) = 0x4 > 2020-06-15 13:42:08 -00:00: INF [ethernet] Connected Ethernet interface > 00:16:3e:30:49:52 > 2020-06-15 13:42:08 -00:00: INF [ARP] Sending gratuitous ARP for 10.0.0.2 > (00:16:3e:30:49:52) > gnttab_grant_access(): ref=0xa, domid=0x0, addr=0x8fd000, readonly=1 > 2020-06-15 13:42:08 -00:00: INF [udp] UDP interface connected on 10.0.0.2 > 2020-06-15 13:42:08 -00:00: INF [tcpip-stack-direct] stack assembled: > mac=00:16:3e:30:49:52,ip=10.0.0.2 > Gntref.get(): Waiting for free grant > Gntref.get(): Waiting for free grant > > > > > The above are also rather odd, but not related to event > > > > > channel delivery, so one problem at a time... > > > > > Once we get this far, packets should be flowing but aren't > > > > > (either way). However, Xenstore is obviously working, as we > > > > > wouldn't get through Netfront setup without it. > > Given that I've essentially re-written the low-level event channel C code, > I'd like to verify that the mechanisms I'm using for event delivery are > indeed the right thing to do on PVHv2. > > For event delivery, I'm registering the upcall with Xen as follows: > > uint64_t val = 32ULL; > val |= (uint64_t)HVM_PARAM_CALLBACK_TYPE_VECTOR << 56; > int rc = hypercall_hvm_set_param(HVM_PARAM_CALLBACK_IRQ, val); > assert(rc == 0); > > i.e. upcalls are to be delivered via IDT vector. This way of event channel injection is slitgly hackish, and I would recommend using HVMOP_set_evtchn_upcall_vector, that way vectors will be properly routed using the lapic. Using HVM_PARAM_CALLBACK_TYPE_VECTOR vectors are injected without setting the IRR/ISR bit in the lapic registers. > Questions: > > 1. Being based on the Solo5 virtio code, the low-level setup code is doing > the "usual" i8259 PIC setup, to remap the PIC IRQs to vectors 32 and above. > Should I be doing this initialisation for Xen PVH at all? Hm, there are no IO-APICs (or legacy PICs) on a PVH domU, so there's not much to route. If Solo5 is thinking it's somehow configuring them it's likely writing to some hole in memory, or to some RAM. IO-APIC presence is signaled on the ACPI MADT table on PVH domU. > I'm not interested > in using the PIC for anything, and all interrupts will be delivered via Xen > event channels. > > 2. Related to the above, the IRQ handler code is ACKing the interrupt after > the handler runs. Should I be doing that? Does ACKing "IRQ" 0 on the PIC > have any interactions with Xen's view of event channels/pending upcalls? Which kind of ACking it's doing? Is it writing to the lapic EOI register? If so that would be OK when using HVMOP_set_evtchn_upcall_vector. If using HVM_PARAM_CALLBACK_TYPE_VECTOR there's nothing to Ack I think. > Next, for a PVHv2, uniprocessor only guest, is the following flow sufficient > to unmask an event channel? > > struct shared_info *s = SHARED_INFO(); > int pending = 0; > > atomic_sync_btc(port, &s->evtchn_mask[0]); > pending = sync_bt(port, &s->evtchn_mask[0]); You should check for pending interrupts on evtchn_pending, not evtchn_mask. > if (pending) { > /* > * Slow path: > * > * If pending is set here, then there was a race, and we lost the > * upcall. Mask the port again and force an upcall via a call to > * hyperspace. > * > * This should be sufficient for HVM/PVHv2 based on my understanding > of > * Linux drivers/xen/events/events_2l.c. > */ > atomic_sync_bts(port, &s->evtchn_mask[0]); > hypercall_evtchn_unmask(port); > } FWIW, I use the hypercall unconditionally on FreeBSD because I didn't see a performance difference when compared to this method. > Lastly, the old PV-only Mini-OS based stack would do delays ("block the > domain") by doing a HYPERVISOR_set_timer_op(deadline) followed by a > HYPERVISOR_sched_op(SCHEDOP_block,0 ). In the new code, I'm doing the > following (based on what Mini-OS seems to be doing for HVM): > > solo5_time_t deadline = Int64_val(v_deadline); > > if (solo5_clock_monotonic() < deadline) { > hypercall_set_timer_op(deadline); > __asm__ __volatile__ ("hlt" : : : "memory"); > /* XXX: cancel timer_op here if woken up early? */ > } > > Again, is this the right thing to do for PVH? hlt will trap into the hypervisor, so it's fine to use. > As the comment says, do I need to cancel the timer_op? I'm not sure. Keep in mind that a new call to hypercall_set_timer_op will overwrite the previous timer, and hence should be fine I think as long as you are using the one-shot timer. > I understood the > semantics to be "fire once at/after the time deadline is reached", if that > is indeed the case then with my current VIRQ_TIMER handler which does > nothing in the interrupt context and has no side effects I should be fine. I have no idea how Solo5 works, maybe you should re-set the timer to the next deadline in the handler? Or that's fine because the timer is always set before blocking. > I can also post the code that does the actual demuxing of events from Xen > (i.e. the upcall handler), but I've read through that several times now and > I don't think the problem is there; adding diagnostic prints to both the > low-level C event channel code and higher-level OCaml Activations code > confirms that received events are being mapped to their ports correctly. I can take a look at the event channel handler if you want, as you wish. The only weird think I've noticed is the error in the unmask where you seem to use evtchn_mask instead of evtchn_pending. I would also recommend using HVMOP_set_evtchn_upcall_vector instead of HVM_PARAM_CALLBACK_TYPE_VECTOR. In order to make some tools happy just set HVM_PARAM_CALLBACK_TYPE_VECTOR to 1. You can take a look at how Xen does it when running as a guest: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/guest/xen/xen.c;h=2ff63d370a8a12fef166677e2ded7ed82a628ce8;hb=HEAD#l205 Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:16:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:16:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqqc-0006tY-72; Mon, 15 Jun 2020 15:16:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkqqa-0006tT-T0 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:16:28 +0000 X-Inumbo-ID: 2e9ccc5c-af1b-11ea-b80a-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2e9ccc5c-af1b-11ea-b80a-12813bfff9fa; Mon, 15 Jun 2020 15:16:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 031D9B001; Mon, 15 Jun 2020 15:16:29 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Andrew Cooper References: <20200608200259.17681-1-andrew.cooper3@citrix.com> <620e5f66-2802-24e7-bb6e-285e99f12975@suse.com> <6e353c85-b957-bdbe-6428-737b5bc8e801@citrix.com> From: Jan Beulich Message-ID: Date: Mon, 15 Jun 2020 17:16:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <6e353c85-b957-bdbe-6428-737b5bc8e801@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Konrad Rzeszutek Wilk , Ross Lagerwall , Paul Durrant , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10.06.2020 16:39, Andrew Cooper wrote: > On 09/06/2020 14:41, Jan Beulich wrote: >> On 08.06.2020 22:02, Andrew Cooper wrote: >>> Do we ever write into .rodata? AFAICT, we introduce new fuctions for >>> references to new .rodata, rather than modifying existing .rodata. If however >>> we do modify .rodata, then the virtual regions need extending with information >>> about .rodata so we can zap those dirty bits as well. >> Inspired by looking at setup_virtual_regions(), do exception fixup >> or bug frame tables possibly get patched? > > If they're not in .rodata, they really ought to be. They are, afaict, and hence my question. > That said, neither of those tables should get touched - we add new > subset tables in the livepatch, which covers anything arising from > modified code.  This means we don't merge/resort the table on load, or > edit the table at all on unload. I guessed it ought to be like that, but thought I'd better ask. >>> @@ -58,6 +59,10 @@ int arch_livepatch_safety_check(void) >>> >>> int arch_livepatch_quiesce(void) >>> { >>> + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ >>> + if ( cpu_has_xen_shstk ) >>> + write_cr4(read_cr4() & ~X86_CR4_CET); >>> + >>> /* Disable WP to allow changes to read-only pages. */ >>> write_cr0(read_cr0() & ~X86_CR0_WP); >>> >>> @@ -68,6 +73,29 @@ void arch_livepatch_revive(void) >>> { >>> /* Reinstate WP. */ >>> write_cr0(read_cr0() | X86_CR0_WP); >>> + >>> + /* Clobber dirty bits and reinstate CET, if applicable. */ >>> + if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) >>> + { >>> + unsigned long tmp; >>> + >>> + reset_virtual_region_perms(); >>> + >>> + write_cr4(read_cr4() | X86_CR4_CET); >>> + >>> + /* >>> + * Fix up the return address on the shadow stack, which currently >>> + * points at arch_livepatch_quiesce()'s caller. >>> + * >>> + * Note: this is somewhat fragile, and depends on both >>> + * arch_livepatch_{quiesce,revive}() being called from the same >>> + * function, which is currently the case. >>> + */ >>> + asm volatile ("rdsspq %[ssp];" >>> + "wrssq %[addr], (%[ssp]);" >>> + : [ssp] "=&r" (tmp) >>> + : [addr] "r" (__builtin_return_address(0))); >>> + } >> To be safe against LTO I think this wants accompanying with making >> both functions noinline. > > Hmm true. > >> As to the fragility - how about arch_livepatch_quiesce() returning >> __builtin_return_address(0) to its caller, for passing into here >> for verification? This would also make more noticeable that the >> two should be be called from the same function (or else the "token" >> would need passing further around). > > This I'm less certain about, as its fairly invasive to common code, just > to bodge around something I don't expect to last very long into the 4.15 > timeframe. I don't see it being invasive - there's a new local variable needed in both of apply_payload() and revert_payload(), and of course the call sites would need adjustment. >>> @@ -91,6 +92,18 @@ void unregister_virtual_region(struct virtual_region *r) >>> remove_virtual_region(r); >>> } >>> >>> +void reset_virtual_region_perms(void) >>> +{ >>> + const struct virtual_region *region; >>> + >>> + rcu_read_lock(&rcu_virtual_region_lock); >>> + list_for_each_entry_rcu( region, &virtual_region_list, list ) >>> + modify_xen_mappings((unsigned long)region->start, >>> + ROUNDUP((unsigned long)region->end, PAGE_SIZE), >>> + PAGE_HYPERVISOR_RX); >>> + rcu_read_unlock(&rcu_virtual_region_lock); >>> +} >> Doesn't this result in shattering the trailing (and currently still >> only) 2Mb page mapping .text in the xen.efi case? > > Not any more or less than its already clobbered by this logic in the > alternatives path, I think? Not afaict, there we have if ( cpu_has_xen_shstk ) modify_xen_mappings(XEN_VIRT_START + MB(2), (unsigned long)&__2M_text_end, PAGE_HYPERVISOR_RX); >> With the >> expectation of the approach changing in 4.15 this may not need >> addressing, but should imo be mentioned as a shortcoming in the >> description then. >> >> Also - how about "restore" instead of "reset"? > > Why?  We're not passing some state sideways into the new mappings - > we're resetting them to their expected values. To me as a non-native speaker "reset" means more like some initial state, whereas "restore" means more like "to some intended state". >> Finally, while indeed not a lot of code, should it nevertheless go >> inside #ifdef CONFIG_LIVEPATCH? > > Tbh, it could be CONFIG_XEN_SHSTK if we decide to go down that route. The the && of both, really. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:33:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:33:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkr7F-00005D-Lb; Mon, 15 Jun 2020 15:33:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkr7E-000057-D5 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:33:40 +0000 X-Inumbo-ID: 950b0c7d-af1d-11ea-b80e-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 950b0c7d-af1d-11ea-b80e-12813bfff9fa; Mon, 15 Jun 2020 15:33:39 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 7QT1MsNHvao7+56qherYyjnDUwjmRMJyADuszo0B1FsRffN16rSslb3luoG4+947Gkee50EOks kNCrfj3kJVnCQBbfvRdL5+KU3sd366mAMi6VAtr88hAum3HtAPmm125Kp8HsAsRg4QAwsGU6FR v3BgveZu1BtggJ+antYiwbzrCKaWN+od2KT71OruL4zd9pC6EH/5NPW8yzwT7JiS+bd2WKAQ2y V+lRcsvMIjm0LyGiS16qN91hrdustsNHpLS4Rrh2Yypii31S+MgdLLOlYvuqOvrFakr2OzjNqN rCg= X-SBRS: 2.7 X-MesageID: 20419838 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20419838" Subject: Re: [PATCH for-4.14 8/8] x86/hvm: enable emulated PIT for PVH dom0 To: Roger Pau Monne , References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-9-roger.pau@citrix.com> From: Andrew Cooper Message-ID: Date: Mon, 15 Jun 2020 16:33:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200612155640.4101-9-roger.pau@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12/06/2020 16:56, Roger Pau Monne wrote: > Some video BIOS require a PIT in order to work properly, hence classic > PV dom0 gets partial access to the physical PIT as long as it's not in > use by Xen. Is this actually true today? I can believe that it may have been necessary on old hardware, but the structure of systems has changed massively over the past 20 years, and the PIT is very legacy these days. We shouldn't be blindly propagating bodges like this forward. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:34:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:34:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkr87-000089-1J; Mon, 15 Jun 2020 15:34:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkr85-000082-Ob for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:34:33 +0000 X-Inumbo-ID: b5c0f9e0-af1d-11ea-b80e-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b5c0f9e0-af1d-11ea-b80e-12813bfff9fa; Mon, 15 Jun 2020 15:34:33 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: H49LTfxHpefTQU6RLb1fGMWXdogjCxJvRIoLSxZUZ0gbVEhpVIS5iTX34OB9xphD7lp5XIEMoz 14Of9prMVLgyjI6lQjY/0br34WsVuKzTIV35cgN00QRUgKl7DgUE+odf/Bt+1/aBZE56Tpff/t nXHm+hQRlVtsykWRfuu9Hdim85GjS68k2uL6AP8aS8XbvUqEbNnLSKt7K1z5dZTZy59lRRveZT N0XADO1vIIG/ngtmQ9hulmILEb3HDLV9UScXtqaYdlM65rZ+3cfL4GHHaaVYbpjQDcpaqlBcGK H+8= X-SBRS: 2.7 X-MesageID: 20374245 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20374245" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <24295.38146.988316.316252@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 16:34:26 +0100 To: Andrew Cooper Subject: Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted In-Reply-To: References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-3-andrew.cooper3@citrix.com> <24295.35624.644030.417783@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted"): > Nothing runs it by default, but it is part of my prepush testing for > anything in the relevant area. > > We should do something better, but its not totally trivial. The x86 > emulator test for example needs a fairly bleeding edge version of > binutils, given that we routinely add support for bleeding edge > instruction groups. Hmmm. Is it likely that installing the version from Debian testing (say) would work ? Or do we want to build it from source ? These are all possibilities. We could build binutils from source with a job-specific --prefix setting and that wouldn't stop it sharing the build host with other jobs. Maybe it could be a seperate job which provides an anointed binutils build. What other awkward requirements are there ? Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:39:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:39:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrDA-0000NG-Ot; Mon, 15 Jun 2020 15:39:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrD9-0000NB-Is for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:39:47 +0000 X-Inumbo-ID: 70fbfbe2-af1e-11ea-8496-bc764e2007e4 Received: from mail-qk1-x743.google.com (unknown [2607:f8b0:4864:20::743]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 70fbfbe2-af1e-11ea-8496-bc764e2007e4; Mon, 15 Jun 2020 15:39:46 +0000 (UTC) Received: by mail-qk1-x743.google.com with SMTP id b27so16090602qka.4 for ; Mon, 15 Jun 2020 08:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=r/4LSS2ARR1HnDNp9VBrA9sVpnsEV3py1FqBM276R1Y=; b=PDqXv6i7ad5sthSW66KEf0J+Y5CJEKhHQNO9/TNUF3IBMWQuR9VoFaVLBPDefrqzUJ iL4hJGIAN/VQbuZCo+nwo5w5K57tofgP2vUhH6o/z0ywT3kn87a9lJaGOrE8bS2aRuTD 97bQd4jY/ZKBGpIAwOFVir+98vl6TyEu8m9mvHBi4ZqcQczIXy1mOb/Cet5CmsZMzoSY dn8gy+xQaAeMzyy/45MDZlJnCzDNvRb1nxTqS00fylNCj3TniLy72iZSJAC218iQk+DY flTMVRkKo/ut44XxVMlgo/Xu09ps4tDdSw/8PKtIHN1kg56K0eDwwZaPznFNJBKOBg4F YxiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=r/4LSS2ARR1HnDNp9VBrA9sVpnsEV3py1FqBM276R1Y=; b=F5jCMQhWanlEhtiZP9PMYicpI6Rh6+qld0LU7t7QiEkEpNUw2qti7KPj5tPHZ4pbom 0bFSatVP7nzbBnaM6284ttVotmopmgzUWDCZxkl0MdQM9n66eAfWaNSRJOlY0WwWUyHJ f/sPIfNa+RJ0WdBN7FX0zAAiGd2avV9tqk4cIrN/WDJb2ckPK/i37mxzNbIVHo1+jBF/ JMUbWSEuY9hmbCe5osC9LFSlYo3Wtp/6x9nRmp4iY8PPys160xyGuxcm2vbZivsAq7QX 4zety6qJaBnGBgvSfpp1JZgZjZMzWTJMexNyC24WBsnfn+Yz7rBEeK0lIDWA5GbbUY0s Tv7A== X-Gm-Message-State: AOAM531mhZ1WMlpsekIUBN6GxVJG/nOCe5SSp4DH2oYm9TfgTUtwiOYA VguUaUpcpZ1OARF4Yrz9OBcbGnUJldc= X-Google-Smtp-Source: ABdhPJy4dVJReJwLuos2mxrWp9SF0D8SBfTrktzn12eLIlKqafn5SmSl5yr2C6rWP8bKs2TxiFP06g== X-Received: by 2002:a05:620a:9d8:: with SMTP id y24mr15434990qky.274.1592235586023; Mon, 15 Jun 2020 08:39:46 -0700 (PDT) Received: from six.lan (cpe-67-241-56-252.twcny.res.rr.com. [67.241.56.252]) by smtp.gmail.com with ESMTPSA id o33sm12476014qtj.44.2020.06.15.08.39.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2020 08:39:45 -0700 (PDT) From: Nick Rosbrook X-Google-Original-From: Nick Rosbrook To: xen-devel@lists.xenproject.org Subject: [PATCH for-4.14] golang/xenlight: sort cases in switch statement Date: Mon, 15 Jun 2020 11:39:42 -0400 Message-Id: <42ba06bc716cf91d25c8bb1d988cb1310219b8fe.1592234663.git.rosbrookn@ainfosec.com> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , paul@xen.org, andrew.cooper3@citrix.com, Ian Jackson , George Dunlap , Nick Rosbrook Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The xenlight_golang_union_from_C function iterates over a dict to construct a switch statement that marshals a C keyed union into a Go type. Because python does not guarantee dict ordering across all versions, this can result in the switch statement being generated in a different order depending on the version of python used. For example, running gengotypes.py with python2.7 and python3.6 will yield different orderings. Iterate over sorted(cases.items()) rather than cases.items() to fix this. This patch changes the ordering from what was previously checked-in, but running gengotypes.py with different versions of python will now yield the same result. Signed-off-by: Nick Rosbrook --- Andrew reported this in [1], so I intend this as a build fix for 4.14. [1] https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00881.html --- tools/golang/xenlight/gengotypes.py | 2 +- tools/golang/xenlight/helpers.gen.go | 32 ++++++++++++++-------------- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/tools/golang/xenlight/gengotypes.py b/tools/golang/xenlight/gengotypes.py index ecca59745f..557fecd07b 100644 --- a/tools/golang/xenlight/gengotypes.py +++ b/tools/golang/xenlight/gengotypes.py @@ -379,7 +379,7 @@ def xenlight_golang_union_from_C(ty = None, union_name = '', struct_name = ''): # Create switch statement to determine which 'union element' # to populate in the Go struct. - for case_name, case_tuple in cases.items(): + for case_name, case_tuple in sorted(cases.items()): (case_val, case_type) = case_tuple s += 'case {}:\n'.format(case_val) diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index 935d3bc50a..152c7e8e6b 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -431,8 +431,6 @@ x.Evtch = int(xc.evtch) x.Rref = int(xc.rref) x.Connection = ChannelConnection(xc.connection) switch x.Connection{ -case ChannelConnectionUnknown: -x.ConnectionUnion = nil case ChannelConnectionPty: var connectionPty ChannelinfoConnectionUnionPty if err := connectionPty.fromC(xc);err != nil { @@ -441,6 +439,8 @@ if err := connectionPty.fromC(xc);err != nil { x.ConnectionUnion = connectionPty case ChannelConnectionSocket: x.ConnectionUnion = nil +case ChannelConnectionUnknown: +x.ConnectionUnion = nil default: return fmt.Errorf("invalid union key '%v'", x.Connection)} @@ -1098,6 +1098,8 @@ if err := typeHvm.fromC(xc);err != nil { return fmt.Errorf("converting field typeHvm: %v", err) } x.TypeUnion = typeHvm +case DomainTypeInvalid: +x.TypeUnion = nil case DomainTypePv: var typePv DomainBuildInfoTypeUnionPv if err := typePv.fromC(xc);err != nil { @@ -1110,8 +1112,6 @@ if err := typePvh.fromC(xc);err != nil { return fmt.Errorf("converting field typePvh: %v", err) } x.TypeUnion = typePvh -case DomainTypeInvalid: -x.TypeUnion = nil default: return fmt.Errorf("invalid union key '%v'", x.Type)} x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version) @@ -2360,8 +2360,6 @@ x.Devid = Devid(xc.devid) x.Name = C.GoString(xc.name) x.Connection = ChannelConnection(xc.connection) switch x.Connection{ -case ChannelConnectionUnknown: -x.ConnectionUnion = nil case ChannelConnectionPty: x.ConnectionUnion = nil case ChannelConnectionSocket: @@ -2370,6 +2368,8 @@ if err := connectionSocket.fromC(xc);err != nil { return fmt.Errorf("converting field connectionSocket: %v", err) } x.ConnectionUnion = connectionSocket +case ChannelConnectionUnknown: +x.ConnectionUnion = nil default: return fmt.Errorf("invalid union key '%v'", x.Connection)} @@ -3933,28 +3933,28 @@ return fmt.Errorf("converting field Domuuid: %v", err) x.ForUser = uint64(xc.for_user) x.Type = EventType(xc._type) switch x.Type{ -case EventTypeDomainShutdown: -var typeDomainShutdown EventTypeUnionDomainShutdown -if err := typeDomainShutdown.fromC(xc);err != nil { - return fmt.Errorf("converting field typeDomainShutdown: %v", err) -} -x.TypeUnion = typeDomainShutdown -case EventTypeDomainDeath: -x.TypeUnion = nil case EventTypeDiskEject: var typeDiskEject EventTypeUnionDiskEject if err := typeDiskEject.fromC(xc);err != nil { return fmt.Errorf("converting field typeDiskEject: %v", err) } x.TypeUnion = typeDiskEject +case EventTypeDomainCreateConsoleAvailable: +x.TypeUnion = nil +case EventTypeDomainDeath: +x.TypeUnion = nil +case EventTypeDomainShutdown: +var typeDomainShutdown EventTypeUnionDomainShutdown +if err := typeDomainShutdown.fromC(xc);err != nil { + return fmt.Errorf("converting field typeDomainShutdown: %v", err) +} +x.TypeUnion = typeDomainShutdown case EventTypeOperationComplete: var typeOperationComplete EventTypeUnionOperationComplete if err := typeOperationComplete.fromC(xc);err != nil { return fmt.Errorf("converting field typeOperationComplete: %v", err) } x.TypeUnion = typeOperationComplete -case EventTypeDomainCreateConsoleAvailable: -x.TypeUnion = nil default: return fmt.Errorf("invalid union key '%v'", x.Type)} -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:43:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:43:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrGu-0001Bc-Ex; Mon, 15 Jun 2020 15:43:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrGs-0001BX-OQ for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:43:38 +0000 X-Inumbo-ID: fa8e72cc-af1e-11ea-8496-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fa8e72cc-af1e-11ea-8496-bc764e2007e4; Mon, 15 Jun 2020 15:43:38 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: XLNuK+rMv2pAcnrjJfENZtKybViCdhtxN40UnfVf2AWfD5pFAN4dGkcMCiVvPLkyhm6k5r8l0r aEeMQHzrvAWkwA3Fc/aomqexM15I+X9SjqGavXBuv31EnotfS5ONGxaF5scJwimWGO/CHc5Zdt jmCOtPdBN/J7iCxDQim9LgcI59W4x1+F0ixbThmkxBgIPrDRT6mQqBy//lqFU8uiNqmE/T/9ac focS2Rwhyl3/y3ZFJoxcPk1Fnyd5HH16jnR2bUl+Cs+P33yTBWJMv6fgOBvJ5g8Ukns4ib0zT8 438= X-SBRS: 2.7 X-MesageID: 20420760 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20420760" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.38675.682397.522303@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 16:43:15 +0100 To: Nick Rosbrook Subject: Re: [PATCH for-4.14] golang/xenlight: sort cases in switch statement In-Reply-To: <42ba06bc716cf91d25c8bb1d988cb1310219b8fe.1592234663.git.rosbrookn@ainfosec.com> References: <42ba06bc716cf91d25c8bb1d988cb1310219b8fe.1592234663.git.rosbrookn@ainfosec.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , "paul@xen.org" , Andrew Cooper , George Dunlap , Nick Rosbrook , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Nick Rosbrook writes ("[PATCH for-4.14] golang/xenlight: sort cases in switch statement"): > The xenlight_golang_union_from_C function iterates over a dict to > construct a switch statement that marshals a C keyed union into a Go > type. Because python does not guarantee dict ordering across all > versions, this can result in the switch statement being generated in a > different order depending on the version of python used. For example, > running gengotypes.py with python2.7 and python3.6 will yield different > orderings. > > Iterate over sorted(cases.items()) rather than cases.items() to fix > this. > > This patch changes the ordering from what was previously checked-in, but > running gengotypes.py with different versions of python will now yield > the same result. > > Signed-off-by: Nick Rosbrook > --- > Andrew reported this in [1], so I intend this as a build fix for 4.14. > > [1] https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00881.html > --- > tools/golang/xenlight/gengotypes.py | 2 +- > tools/golang/xenlight/helpers.gen.go | 32 ++++++++++++++-------------- > 2 files changed, 17 insertions(+), 17 deletions(-) > > diff --git a/tools/golang/xenlight/gengotypes.py b/tools/golang/xenlight/gengotypes.py > index ecca59745f..557fecd07b 100644 > --- a/tools/golang/xenlight/gengotypes.py > +++ b/tools/golang/xenlight/gengotypes.py > @@ -379,7 +379,7 @@ def xenlight_golang_union_from_C(ty = None, union_name = '', struct_name = ''): > > # Create switch statement to determine which 'union element' > # to populate in the Go struct. > - for case_name, case_tuple in cases.items(): > + for case_name, case_tuple in sorted(cases.items()): > (case_val, case_type) = case_tuple This part Acked-by: Ian Jackson But I don't think I have the right golang tools to verify the autogenerated code. George, can you check that this patch is right, and/or do the commit and rerun the generation ? Obviously that needs to wait for a release ack. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:48:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:48:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrLH-0001LI-23; Mon, 15 Jun 2020 15:48:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrLF-0001LD-PG for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:48:09 +0000 X-Inumbo-ID: 9c188d62-af1f-11ea-b80e-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9c188d62-af1f-11ea-b80e-12813bfff9fa; Mon, 15 Jun 2020 15:48:09 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: M5VQRtnHRZQc3T9olrbNYlwXfbbZwNmuiSAHgGezLGeSiarwyP0Fy9i4UyLhCKimEUXe2yZ2W8 LOkEDscE7ZI4mHHiEfooD+icyhInWe8nI5Wjj/erSWFgjF6ndV+03yteSwbbu3AvkZXLNPCDCH CiyBoAE4SI4ZrVpZOQCAoNWtncqJ58NxQVfBVERENejd7m3mglBFLrIjikwLIX0Xuw6/NWXtvX duN88D93Z4eNfOp64F/HJBimWIXFYHK8RUXes7PtGB0+CDRTPpAnpW3BgGwzdJrqcq8+jOiTvP +z0= X-SBRS: 2.7 X-MesageID: 20090069 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20090069" Date: Mon, 15 Jun 2020 17:47:59 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Andrew Cooper Subject: Re: [PATCH for-4.14 8/8] x86/hvm: enable emulated PIT for PVH dom0 Message-ID: <20200615154759.GH735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-9-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 04:33:33PM +0100, Andrew Cooper wrote: > On 12/06/2020 16:56, Roger Pau Monne wrote: > > Some video BIOS require a PIT in order to work properly, hence classic > > PV dom0 gets partial access to the physical PIT as long as it's not in > > use by Xen. > > Is this actually true today? TBH I have no idea and asked the same thing myself. > I can believe that it may have been necessary on old hardware, but the > structure of systems has changed massively over the past 20 years, and > the PIT is very legacy these days. I also wondered whether video BIOSes really changed in the last 20 years, I really have no idea. FWIW, Wikipedia still lists PIT as being used by video BIOSes on x86 systems [0] but there are no references to specific models or video BIOSes. Alternatively we could add this as a Xen command line option, ie: dom0=pit or some such. It's however not very nice to not get output because the video BIOS doesn't function properly due to lack of PIT. Thanks, Roger. [0] https://en.wikipedia.org/wiki/Intel_8253#IBM_PC_programming_tips_and_hints From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:51:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:51:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrOt-000274-Kc; Mon, 15 Jun 2020 15:51:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrOs-00026z-OK for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:51:54 +0000 X-Inumbo-ID: 21272040-af20-11ea-bb8b-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 21272040-af20-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 15:51:53 +0000 (UTC) Received: from webmail.moloch.sk (w3-s.a.lucina.net [62.176.169.73]) by smtp.lucina.net (Postfix) with ESMTPSA id 6DDC5122804; Mon, 15 Jun 2020 17:51:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592236311; bh=/FpB91+u9v9wBFgEkB147d5HxiDmF56rYU3flrWJCVU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kTh5y8BamtZt5tmZe83ebu+xnp6Dw+TZROg6BfUYP6g3hQqNHcuiKAmXSyCpFZKL6 8DuuaJeq8IZ2UYPEhhRstwyNWoMO086F+wrr91b0++VqNUvyHVa7IXmhFoC7Ewo5ei fKadqJ9IsNk1XUfYwIVBQ9gmhH0nr3DiSLnCveAH4Gz/yEOcSkmpnSuj1UzvefBEdX e/6R2DunG5goRu/VttgSD7zEoDtc8NN0fXX1RcGKLr89iLQSeue6sScfi4m1WpUbWi RMWMfhuS413z8TrQnZ4y0MtC+XXzpM7rJhpC+yoFOMn27opZYxZovCYeJ4g9ONJvGK YszBJCPolTJ/A== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 15 Jun 2020 17:51:51 +0200 From: Martin Lucina To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: Event delivery and "domain blocking" on PVHv2 In-Reply-To: <20200615150344.GG735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <20200615150344.GG735@Air-de-Roger> Message-ID: <4a0bb4fa4dca2732feae4e2f825eb2a6@lucina.net> X-Sender: martin@lucina.net User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-15 17:03, Roger Pau Monné wrote: > This way of event channel injection is slitgly hackish, and I would > recommend using HVMOP_set_evtchn_upcall_vector, that way vectors will > be properly routed using the lapic. > > Using HVM_PARAM_CALLBACK_TYPE_VECTOR vectors are injected without > setting the IRR/ISR bit in the lapic registers. I picked HVM_PARAM_CALLBACK_TYPE_VECTOR since that seemed like the easiest option for a uniprocessor, PVH-only guest. What does mean in the context of HVMOP_set_evtchn_upcall_vector? If it's an APIC vector number (sorry, not too familiar with the post-legacy i8259 world), does that imply that if I use HVMOP_set_evtchn_upcall_vector I need to do some APIC initialisation / programming? All I need for Solo5/Mirage purposes is to have the upcall land on IDT vector #32 or above. > >> Questions: >> >> 1. Being based on the Solo5 virtio code, the low-level setup code is >> doing >> the "usual" i8259 PIC setup, to remap the PIC IRQs to vectors 32 and >> above. >> Should I be doing this initialisation for Xen PVH at all? > > Hm, there are no IO-APICs (or legacy PICs) on a PVH domU, so there's > not much to route. If Solo5 is thinking it's somehow configuring them > it's likely writing to some hole in memory, or to some RAM. Solo5 only has a very primitive understanding of hardware interrupts, so it's only configuring the legacy PICs via port IO. > > IO-APIC presence is signaled on the ACPI MADT table on PVH domU. > Hmm, it'd be very unfortunate if I had to deal with ACPI, so here's hoping that I don't actually need to touch the APIC. >> I'm not interested >> in using the PIC for anything, and all interrupts will be delivered >> via Xen >> event channels. >> >> 2. Related to the above, the IRQ handler code is ACKing the interrupt >> after >> the handler runs. Should I be doing that? Does ACKing "IRQ" 0 on the >> PIC >> have any interactions with Xen's view of event channels/pending >> upcalls? > > Which kind of ACking it's doing? Is it writing to the lapic EOI > register? If so that would be OK when using > HVMOP_set_evtchn_upcall_vector. If using > HVM_PARAM_CALLBACK_TYPE_VECTOR there's nothing to Ack I think. Legacy PIC EOI via port IO. > >> Next, for a PVHv2, uniprocessor only guest, is the following flow >> sufficient >> to unmask an event channel? >> >> struct shared_info *s = SHARED_INFO(); >> int pending = 0; >> >> atomic_sync_btc(port, &s->evtchn_mask[0]); >> pending = sync_bt(port, &s->evtchn_mask[0]); > > You should check for pending interrupts on evtchn_pending, not > evtchn_mask. Ah, thanks for spotting that! Fixed, but just that change by itself does not seem to change the observed behaviour in any way. > >> if (pending) { >> /* >> * Slow path: >> * >> * If pending is set here, then there was a race, and we lost >> the >> * upcall. Mask the port again and force an upcall via a call >> to >> * hyperspace. >> * >> * This should be sufficient for HVM/PVHv2 based on my >> understanding >> of >> * Linux drivers/xen/events/events_2l.c. >> */ >> atomic_sync_bts(port, &s->evtchn_mask[0]); >> hypercall_evtchn_unmask(port); >> } > > FWIW, I use the hypercall unconditionally on FreeBSD because I didn't > see a performance difference when compared to this method. > >> Lastly, the old PV-only Mini-OS based stack would do delays ("block >> the >> domain") by doing a HYPERVISOR_set_timer_op(deadline) followed by a >> HYPERVISOR_sched_op(SCHEDOP_block,0 ). In the new code, I'm doing the >> following (based on what Mini-OS seems to be doing for HVM): >> >> solo5_time_t deadline = Int64_val(v_deadline); >> >> if (solo5_clock_monotonic() < deadline) { >> hypercall_set_timer_op(deadline); >> __asm__ __volatile__ ("hlt" : : : "memory"); >> /* XXX: cancel timer_op here if woken up early? */ >> } >> >> Again, is this the right thing to do for PVH? > > hlt will trap into the hypervisor, so it's fine to use. > Thanks for confirming. >> As the comment says, do I need to cancel the timer_op? > > I'm not sure. Keep in mind that a new call to hypercall_set_timer_op > will overwrite the previous timer, and hence should be fine I think as > long as you are using the one-shot timer. Is there something other than a one-shot timer? hypercall_set_timer_op is just a single-argument hypercall with an uint64_t deadline, right? (And not documented in xen.h either ...) > >> I understood the >> semantics to be "fire once at/after the time deadline is reached", if >> that >> is indeed the case then with my current VIRQ_TIMER handler which does >> nothing in the interrupt context and has no side effects I should be >> fine. > > I have no idea how Solo5 works, maybe you should re-set the timer to > the next deadline in the handler? > > Or that's fine because the timer is always set before blocking. Yes, it's always set before blocking, and we always unblock after the first interrupt (i.e. some event) is received, so should be fine. > >> I can also post the code that does the actual demuxing of events from >> Xen >> (i.e. the upcall handler), but I've read through that several times >> now and >> I don't think the problem is there; adding diagnostic prints to both >> the >> low-level C event channel code and higher-level OCaml Activations code >> confirms that received events are being mapped to their ports >> correctly. > > I can take a look at the event channel handler if you want, as you > wish. The only weird think I've noticed is the error in the unmask > where you seem to use evtchn_mask instead of evtchn_pending. Thanks for the offer, this stuff is fairly subtle. In the Mirage/Xen scenario, there are two parts to the upcall handler. The top half is executed in interrupt context and basically does nothing except acknowledge the upcall: int solo5__xen_evtchn_vector_handler(void *arg __attribute__((unused))) { struct vcpu_info *vi = VCPU0_INFO(); /* * All work is done outside of interrupt context by evtchn_demux_pending(), * so all we need to do here is acknowledge the upcall from Xen. */ vi->evtchn_upcall_pending = 0; return 1; } The bottom half is then called periodically (and always before blocking) by the OCaml code: static bool evtchn_demux_pending(void) { struct shared_info *s = SHARED_INFO(); struct vcpu_info *vi = VCPU0_INFO(); bool some_pending = false; vi->evtchn_upcall_pending = 0; /* * Demux events received from Xen. * * pending_l1 is the "outer" per-VCPU selector (evtchn_pending_sel). * pending_l2 is the "inner" system-wide word (evtchn_pending[l1i]). */ xen_ulong_t pending_l1, pending_l2; atomic_sync_xchg(&vi->evtchn_pending_sel, 0, &pending_l1); while (pending_l1 != 0) { xen_ulong_t l1i = ffs(pending_l1); /* * Masking pending_l2 with ~evtchn_mask[l1i] is necessary to get the * *current* masked events; otherwise races like the following * can occur: * * 1. X is generated, upcall scheduled by Xen. * 2. X is masked. * 3. Upcall is delivered. * 4. X fires despite now being masked. */ while ((pending_l2 = (s->evtchn_pending[l1i] & ~s->evtchn_mask[l1i])) != 0) { xen_ulong_t l2i = ffs(pending_l2); evtchn_port_t port = (l1i * (sizeof(xen_ulong_t) * 8)) + l2i; /* * Mark as pending on the OCaml side. */ evtchn_callback_ml[port] = 1; some_pending = true; atomic_sync_btc(l2i, &s->evtchn_pending[l1i]); } pending_l1 &= ~(1UL << l1i); } return some_pending; } > > I would also recommend using HVMOP_set_evtchn_upcall_vector instead of > HVM_PARAM_CALLBACK_TYPE_VECTOR. In order to make some tools happy just > set HVM_PARAM_CALLBACK_TYPE_VECTOR to 1. You can take a look at how > Xen does it when running as a guest: > > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/guest/xen/xen.c;h=2ff63d370a8a12fef166677e2ded7ed82a628ce8;hb=HEAD#l205 Thanks for the pointer. As I write above, if I can use HVMOP_set_evtchn_upcall_vector w/o doing too much "extra work" on the guest side then I will go with that. > > Roger. -mato From xen-devel-bounces@lists.xenproject.org Mon Jun 15 15:57:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 15:57:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrTl-0002JU-EI; Mon, 15 Jun 2020 15:56:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrTj-0002JP-KS for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 15:56:55 +0000 X-Inumbo-ID: d5616110-af20-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d5616110-af20-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 15:56:54 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: PaKzGeflOyUZvWh7dPfg4jaobUpOte0pvtGcAENGUQZDs3YHglDQxQ+9IC8xZrGr3YetE1TPbm MkQsGNDaW3c2Wh0s3tipEij0JcOVRMaAjJamxTgjft7xH5s6a1X9VMAYOo4iuJT6M7a+mJaLlh eo82oJzB9ILlzUTogivMgAgAjhpduUNoiSehNz4NKfGjb6jZykkeKwarDx5wr37R74UTo+w/cn YpZ/Ttfds8hPLYiv9QSaY+OQkbM4CU6K2NibHMJkxBWtSjKI4wQgIj+l8YOV6by9l/5ozhMI5D ZQI= X-SBRS: 2.7 X-MesageID: 20422282 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20422282" Date: Mon, 15 Jun 2020 17:56:46 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Ian Jackson Subject: Re: [PATCH] libxl: tooling expects wrong errno Message-ID: <20200615155646.GI735@Air-de-Roger> References: <24295.36070.945693.791220@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <24295.36070.945693.791220@mariner.uk.xensource.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Wei Liu , Paul Durrant , "jakub@bartmin.ski" , Andrew Cooper , "marmarek@invisiblethingslab.com" , Grzegorz Uriasz , Anthony Perard , Jan Beulich , "j.nowak26@student.uw.edu.pl" , "xen-devel@lists.xenproject.org" , "contact@puzio.waw.pl" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 03:59:50PM +0100, Ian Jackson wrote: > Grzegorz Uriasz writes ("[PATCH] libxl: tooling expects wrong errno"): > > When iommu is not enabled for a given domain then pci passthrough > > hypercalls such as xc_test_assign_device return EOPNOTSUPP. > > The code responsible for this is in "iommu_do_domctl" inside > > xen/drivers/passthrough/iommu.c > > This patch fixes the error message reported by libxl when assigning > > pci devices to domains without iommu. > > > > Signed-off-by: Grzegorz Uriasz > > Tested-by: Grzegorz Uriasz > > --- > > tools/libxl/libxl_pci.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > > index 957ff5c8e9..bc5843b137 100644 > > --- a/tools/libxl/libxl_pci.c > > +++ b/tools/libxl/libxl_pci.c > > @@ -1561,7 +1561,7 @@ void libxl__device_pci_add(libxl__egc *egc, uint32_t domid, > > LOGD(ERROR, domid, > > "PCI device %04x:%02x:%02x.%u %s?", > > pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func, > > - errno == ENOSYS ? "cannot be assigned - no IOMMU" > > + errno == EOPNOTSUPP ? "cannot be assigned - no IOMMU" > > : "already assigned to a different guest"); > > goto out; > > } > > Thanks. I have addressed some Xen IOMMU maintainers. Can you confirm > whether this is right ? Not an IOMMU maintainer myself, but I've taken a look at the code and I think Grzegorz is right. iommu_do_domctl will return -EOPNOTSUPP if the IOMMU is not enabled for the domain. Another option would be to check for EBUSY (which will certainly be returned when the device is busy) and log the error code with a message when it's different than EBUSY? There are many possible error here, for example the device itself might not be behind an IOMMU, in which case Xen will return -ENODEV at least on the Intel case. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 16:00:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 16:00:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrXb-0003de-VF; Mon, 15 Jun 2020 16:00:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrXa-0003dZ-SA for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 16:00:54 +0000 X-Inumbo-ID: 6420105e-af21-11ea-bca7-bc764e2007e4 Received: from mail-ej1-x629.google.com (unknown [2a00:1450:4864:20::629]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6420105e-af21-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 16:00:54 +0000 (UTC) Received: by mail-ej1-x629.google.com with SMTP id f7so18017461ejq.6 for ; Mon, 15 Jun 2020 09:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=ckivRBep5W5MCYXRFWoArmHpJzc0MY2sqkopEiOe/vY=; b=Eg/ZA/IzoTIemn66oQYYffgVai+jVl1yCiIdYPu1p+dxWQEitjwOGAFgZ9rrGk7O2e Y2z78aFIaA1qczN8OP8/Gziu5B5JwKtjbEcyR2BNbmyNjBrM6k3Mn5C32c5za/a6V+aj sXkJPUsJOw2ZMXzcKvre+LgWOx6feyEtzMrng/4ML/20hglcQGCIVuVUNaF3LrghrKvc fr6oZxBbW+nCjBMtGKzLk0Uhb1zcRuZODQCc9Mz4dtojzCNbu0H3gUe8GrGZS4me+F32 rc3QXxtlV1BU39MMu89HqVK+LPh9u3bl4kEntP9OJYX2heIJAd6BNGJr0Pa3Z3IIVm2b kBFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=ckivRBep5W5MCYXRFWoArmHpJzc0MY2sqkopEiOe/vY=; b=BPa/IYRAocEq/imGBoGKyI5a7P5ZLC7Iq22w6VS/NCC80jdFWQrVFDwuyF3YnyMj7/ hlRKgQTcim1KAMWKpKtN6jRETwU9scYvtA3e5U/TpputAX9AMWCR6yL3njtE74M4XiZT bDTXtiGGj+tLXPnp70BJluoQAGBQ6doB0qCz4HJzVFpiGQikZe7gXzeiS0H6mUoZ6ce+ x3gTTZ0QGo96tQw02x9V7eEvoj7elKG2OyHXxeIDtNEXL318q3q7zOfpvfgBNEMOd/GL 1yYlQebGZVajuTOsv71uxZsxTruwWyY26VvTDqUrFOyoSKduOLoEG5e56l0btKAdh+6v 2HGQ== X-Gm-Message-State: AOAM532sE99NqDXv95AY7aK4POtjHTTokvIhTI5KqIuaosf56LrNStyb qiY0ZiG+bHW4+u3T+3C6pu0= X-Google-Smtp-Source: ABdhPJwRyg/w6QO6E2GJfClG/NkBhKT/0JgTxQDxk0TmkcYeRg9TPuOWSf+B2gypq9bJ8mMkYAzNOg== X-Received: by 2002:a17:906:22da:: with SMTP id q26mr13463123eja.256.1592236853216; Mon, 15 Jun 2020 09:00:53 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id cn14sm8598744edb.22.2020.06.15.09.00.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 09:00:52 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Nick Rosbrook'" References: <42ba06bc716cf91d25c8bb1d988cb1310219b8fe.1592234663.git.rosbrookn@ainfosec.com> <24295.38675.682397.522303@mariner.uk.xensource.com> In-Reply-To: <24295.38675.682397.522303@mariner.uk.xensource.com> Subject: RE: [PATCH for-4.14] golang/xenlight: sort cases in switch statement Date: Mon, 15 Jun 2020 17:00:51 +0100 Message-ID: <002f01d6432e$2545b410$6fd11c30$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJnvHaHjNxn+zX7ehrvie/Qok7WjwE1L8Gpp605swA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Nick Rosbrook' , xen-devel@lists.xenproject.org, 'George Dunlap' , 'Wei Liu' , 'Andrew Cooper' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 15 June 2020 16:43 > To: Nick Rosbrook > Cc: xen-devel@lists.xenproject.org; paul@xen.org; Andrew Cooper ; Nick > Rosbrook ; George Dunlap ; Wei Liu > Subject: Re: [PATCH for-4.14] golang/xenlight: sort cases in switch statement > > Nick Rosbrook writes ("[PATCH for-4.14] golang/xenlight: sort cases in switch statement"): > > The xenlight_golang_union_from_C function iterates over a dict to > > construct a switch statement that marshals a C keyed union into a Go > > type. Because python does not guarantee dict ordering across all > > versions, this can result in the switch statement being generated in a > > different order depending on the version of python used. For example, > > running gengotypes.py with python2.7 and python3.6 will yield different > > orderings. > > > > Iterate over sorted(cases.items()) rather than cases.items() to fix > > this. > > > > This patch changes the ordering from what was previously checked-in, but > > running gengotypes.py with different versions of python will now yield > > the same result. > > > > Signed-off-by: Nick Rosbrook > > --- > > Andrew reported this in [1], so I intend this as a build fix for 4.14. > > > > [1] https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00881.html > > --- > > tools/golang/xenlight/gengotypes.py | 2 +- > > tools/golang/xenlight/helpers.gen.go | 32 ++++++++++++++-------------- > > 2 files changed, 17 insertions(+), 17 deletions(-) > > > > diff --git a/tools/golang/xenlight/gengotypes.py b/tools/golang/xenlight/gengotypes.py > > index ecca59745f..557fecd07b 100644 > > --- a/tools/golang/xenlight/gengotypes.py > > +++ b/tools/golang/xenlight/gengotypes.py > > @@ -379,7 +379,7 @@ def xenlight_golang_union_from_C(ty = None, union_name = '', struct_name = ''): > > > > # Create switch statement to determine which 'union element' > > # to populate in the Go struct. > > - for case_name, case_tuple in cases.items(): > > + for case_name, case_tuple in sorted(cases.items()): > > (case_val, case_type) = case_tuple > > This part > > Acked-by: Ian Jackson > > But I don't think I have the right golang tools to verify the > autogenerated code. George, can you check that this patch is right, > and/or do the commit and rerun the generation ? > > Obviously that needs to wait for a release ack. > Assuming George is happy... Release-acked-by: Paul Durrant > Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 16:02:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 16:02:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrYs-0003in-DC; Mon, 15 Jun 2020 16:02:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrYr-0003ig-0T for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 16:02:13 +0000 X-Inumbo-ID: 92bcbff2-af21-11ea-8496-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 92bcbff2-af21-11ea-8496-bc764e2007e4; Mon, 15 Jun 2020 16:02:12 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 5riCwz4p1wnpEEZqAejU2zm+FaabhOI3cpkXyHaxAdWOdmVDcbFxAw/8jModYlzuhOa0goVPd9 j0b44UAMwKSrdHNXKwarWWzkQCmdUeRKAcHyQvo6GilGI/p4KDpD3R+QpAf1KcAjNhFhFXqb4w SslpsunKoOuP77iBGP2senY14+v8GRx7tqNnZrw5rjlr5PvPD/ii0uVmULycuMXIuj6RtWfgVg /esenJNIKNxAMp6R3KG3vdNW63qo57ZlVzJq39os9hN+nbIhUVO2jYztUAjFhQKb1mVtbxIyzY gsM= X-SBRS: 2.7 X-MesageID: 20311901 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20311901" From: George Dunlap To: Ian Jackson Subject: Re: [PATCH for-4.14] golang/xenlight: sort cases in switch statement Thread-Topic: [PATCH for-4.14] golang/xenlight: sort cases in switch statement Thread-Index: AQHWQys0M2jXFQanD0CJHiScvqapGKjZr4CAgAAFQ4A= Date: Mon, 15 Jun 2020 16:02:05 +0000 Message-ID: <538130CB-BCAF-43A7-83E0-A1233A670D69@citrix.com> References: <42ba06bc716cf91d25c8bb1d988cb1310219b8fe.1592234663.git.rosbrookn@ainfosec.com> <24295.38675.682397.522303@mariner.uk.xensource.com> In-Reply-To: <24295.38675.682397.522303@mariner.uk.xensource.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , "paul@xen.org" , Andrew Cooper , Nick Rosbrook , Nick Rosbrook , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gSnVuIDE1LCAyMDIwLCBhdCA0OjQzIFBNLCBJYW4gSmFja3NvbiA8aWFuLmphY2tz b25AY2l0cml4LmNvbT4gd3JvdGU6DQo+IA0KPiBOaWNrIFJvc2Jyb29rIHdyaXRlcyAoIltQQVRD SCBmb3ItNC4xNF0gZ29sYW5nL3hlbmxpZ2h0OiBzb3J0IGNhc2VzIGluIHN3aXRjaCBzdGF0ZW1l bnQiKToNCj4+IFRoZSB4ZW5saWdodF9nb2xhbmdfdW5pb25fZnJvbV9DIGZ1bmN0aW9uIGl0ZXJh dGVzIG92ZXIgYSBkaWN0IHRvDQo+PiBjb25zdHJ1Y3QgYSBzd2l0Y2ggc3RhdGVtZW50IHRoYXQg bWFyc2hhbHMgYSBDIGtleWVkIHVuaW9uIGludG8gYSBHbw0KPj4gdHlwZS4gQmVjYXVzZSBweXRo b24gZG9lcyBub3QgZ3VhcmFudGVlIGRpY3Qgb3JkZXJpbmcgYWNyb3NzIGFsbA0KPj4gdmVyc2lv bnMsIHRoaXMgY2FuIHJlc3VsdCBpbiB0aGUgc3dpdGNoIHN0YXRlbWVudCBiZWluZyBnZW5lcmF0 ZWQgaW4gYQ0KPj4gZGlmZmVyZW50IG9yZGVyIGRlcGVuZGluZyBvbiB0aGUgdmVyc2lvbiBvZiBw eXRob24gdXNlZC4gRm9yIGV4YW1wbGUsDQo+PiBydW5uaW5nIGdlbmdvdHlwZXMucHkgd2l0aCBw eXRob24yLjcgYW5kIHB5dGhvbjMuNiB3aWxsIHlpZWxkIGRpZmZlcmVudA0KPj4gb3JkZXJpbmdz Lg0KPj4gDQo+PiBJdGVyYXRlIG92ZXIgc29ydGVkKGNhc2VzLml0ZW1zKCkpIHJhdGhlciB0aGFu IGNhc2VzLml0ZW1zKCkgdG8gZml4DQo+PiB0aGlzLg0KPj4gDQo+PiBUaGlzIHBhdGNoIGNoYW5n ZXMgdGhlIG9yZGVyaW5nIGZyb20gd2hhdCB3YXMgcHJldmlvdXNseSBjaGVja2VkLWluLCBidXQN Cj4+IHJ1bm5pbmcgZ2VuZ290eXBlcy5weSB3aXRoIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBweXRo b24gd2lsbCBub3cgeWllbGQNCj4+IHRoZSBzYW1lIHJlc3VsdC4NCj4+IA0KPj4gU2lnbmVkLW9m Zi1ieTogTmljayBSb3Nicm9vayA8cm9zYnJvb2tuQGFpbmZvc2VjLmNvbT4NCj4+IC0tLQ0KPj4g QW5kcmV3IHJlcG9ydGVkIHRoaXMgaW4gWzFdLCBzbyBJIGludGVuZCB0aGlzIGFzIGEgYnVpbGQg Zml4IGZvciA0LjE0Lg0KPj4gDQo+PiBbMV0gaHR0cHM6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9h cmNoaXZlcy9odG1sL3hlbi1kZXZlbC8yMDIwLTA2L21zZzAwODgxLmh0bWwNCj4+IC0tLQ0KPj4g dG9vbHMvZ29sYW5nL3hlbmxpZ2h0L2dlbmdvdHlwZXMucHkgIHwgIDIgKy0NCj4+IHRvb2xzL2dv bGFuZy94ZW5saWdodC9oZWxwZXJzLmdlbi5nbyB8IDMyICsrKysrKysrKysrKysrLS0tLS0tLS0t LS0tLS0NCj4+IDIgZmlsZXMgY2hhbmdlZCwgMTcgaW5zZXJ0aW9ucygrKSwgMTcgZGVsZXRpb25z KC0pDQo+PiANCj4+IGRpZmYgLS1naXQgYS90b29scy9nb2xhbmcveGVubGlnaHQvZ2VuZ290eXBl cy5weSBiL3Rvb2xzL2dvbGFuZy94ZW5saWdodC9nZW5nb3R5cGVzLnB5DQo+PiBpbmRleCBlY2Nh NTk3NDVmLi41NTdmZWNkMDdiIDEwMDY0NA0KPj4gLS0tIGEvdG9vbHMvZ29sYW5nL3hlbmxpZ2h0 L2dlbmdvdHlwZXMucHkNCj4+ICsrKyBiL3Rvb2xzL2dvbGFuZy94ZW5saWdodC9nZW5nb3R5cGVz LnB5DQo+PiBAQCAtMzc5LDcgKzM3OSw3IEBAIGRlZiB4ZW5saWdodF9nb2xhbmdfdW5pb25fZnJv bV9DKHR5ID0gTm9uZSwgdW5pb25fbmFtZSA9ICcnLCBzdHJ1Y3RfbmFtZSA9ICcnKToNCj4+IA0K Pj4gICAgICMgQ3JlYXRlIHN3aXRjaCBzdGF0ZW1lbnQgdG8gZGV0ZXJtaW5lIHdoaWNoICd1bmlv biBlbGVtZW50Jw0KPj4gICAgICMgdG8gcG9wdWxhdGUgaW4gdGhlIEdvIHN0cnVjdC4NCj4+IC0g ICAgZm9yIGNhc2VfbmFtZSwgY2FzZV90dXBsZSBpbiBjYXNlcy5pdGVtcygpOg0KPj4gKyAgICBm b3IgY2FzZV9uYW1lLCBjYXNlX3R1cGxlIGluIHNvcnRlZChjYXNlcy5pdGVtcygpKToNCj4+ICAg ICAgICAgKGNhc2VfdmFsLCBjYXNlX3R5cGUpID0gY2FzZV90dXBsZQ0KPiANCj4gVGhpcyBwYXJ0 DQo+IA0KPiBBY2tlZC1ieTogSWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+ DQo+IA0KPiBCdXQgSSBkb24ndCB0aGluayBJIGhhdmUgdGhlIHJpZ2h0IGdvbGFuZyB0b29scyB0 byB2ZXJpZnkgdGhlDQo+IGF1dG9nZW5lcmF0ZWQgY29kZS4gIEdlb3JnZSwgY2FuIHlvdSBjaGVj ayB0aGF0IHRoaXMgcGF0Y2ggaXMgcmlnaHQsDQo+IGFuZC9vciBkbyB0aGUgY29tbWl0IGFuZCBy ZXJ1biB0aGUgZ2VuZXJhdGlvbiA/DQoNCkkgY2FuIGNvbmZpcm0gdGhhdCAxKSByZXJ1bm5pbmcg dGhpcyBkb2VzbuKAmXQgY2F1c2UgYW55IGNoYW5nZXMgMikgdGhlIHJlc3VsdGluZyBjb2RlIGNv bXBpbGVzLg0KDQpBY2tlZC1ieTogR2VvcmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXgu Y29tPg0KDQpTaW5jZSBJ4oCZdmUgZ290IGl0IGluIG15IHRyZWUgSeKAmWxsIHB1c2ggaXQu From xen-devel-bounces@lists.xenproject.org Mon Jun 15 16:05:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 16:05:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrbZ-0003sn-RP; Mon, 15 Jun 2020 16:05:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrbZ-0003si-3H for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 16:05:01 +0000 X-Inumbo-ID: f6ebf056-af21-11ea-b7bb-bc764e2007e4 Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f6ebf056-af21-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 16:05:00 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id t21so11914879edr.12 for ; Mon, 15 Jun 2020 09:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=r8Uw0NEWGA4mNyeaEWdZRA2DF+M+XYvNd7arhcyLIPg=; b=YH8MbmfZT5l1CxsHbFPjVFNxFFmzH8bLHGSJlFNR/lb273PQi0wsklznSZ+8l/hpFb a3L3x80UvWgodBeUxyRAXXGZZSUH5scVA+XCHYn+b6H8eOgWfv9Stk3SifqFeyJZjZ8+ oIpzOXxbTPSGmWx3aSOp3CRIC+Ma2wlzlqmo3XUVmjSRrdIhK77bxiRgQXlqIg+6hb5y MlrpYTX6rBdauqvOZTnvlW5EJdzNyVvvxvYCDef0Guqhn9V8IG3kYvaHvfnsGvjFluY0 2Iy5DRXiiCXJIHZEBGgM1GfinItXpCEDQftdAjc3PZ6spWI8dTTuv/1g3XF047LgQC7j /oSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=r8Uw0NEWGA4mNyeaEWdZRA2DF+M+XYvNd7arhcyLIPg=; b=mfiUnhfhPApXTXsiwI4iWVz0MOHGV8h5qf5x5b2VOp484P28LH4Mc2RBA+25pswcXg aFEs41wnoN9cJm1cZnyvZ89Cnp71On23hiXYlBP5RdrE4jqi495Mn+OClpj08xA9RL91 mX6igz88sVZi5uk/Lh+ZbE40rOH7Bm+Ma6P2uKtKB8eZh275Hxn0aNFF79KA7BCAJBrJ UPJvKf25eln49iyadIp3yHh+mJ2T271QXmXnqtfb0Jo+94BNlUxWNEV3uj9GrooDrCTT DZGXWeE0D4zClmuVkke2Cm9JCT78dO7nLc9sXNOLsQNmvgxYSeTv7GGUhUMQMBwjCIR/ 6+ow== X-Gm-Message-State: AOAM531aFBtmgVAvRBsC1MrUCv+wrEcdbSr6hh3bXWThw4nPYxAxkgRc CGU3kWKspAyuus1Z5b5FOiw= X-Google-Smtp-Source: ABdhPJzMR2aoI/ot0cCAz4BNCYeiMpqDNIl7Z+V8x15JvqUclNNUEm4rrqbUKaE4483jmSty5OGgbw== X-Received: by 2002:a50:f289:: with SMTP id f9mr23897856edm.188.1592237099627; Mon, 15 Jun 2020 09:04:59 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id n35sm8751903edc.11.2020.06.15.09.04.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 09:04:58 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?UTF-8?Q?'Roger_Pau_Monn=C3=A9'?= , "'Ian Jackson'" References: <24295.36070.945693.791220@mariner.uk.xensource.com> <20200615155646.GI735@Air-de-Roger> In-Reply-To: <20200615155646.GI735@Air-de-Roger> Subject: RE: [PATCH] libxl: tooling expects wrong errno Date: Mon, 15 Jun 2020 17:04:57 +0100 Message-ID: <003001d6432e$b80d8a20$28289e60$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJRrVmR5Atw2cuOlpDTe0mFV6HHUQIpYa7PAtS50FGnuxEqwA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Kevin Tian' , 'Wei Liu' , jakub@bartmin.ski, 'Andrew Cooper' , marmarek@invisiblethingslab.com, 'Grzegorz Uriasz' , 'Anthony Perard' , 'Jan Beulich' , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monn=C3=A9 > Sent: 15 June 2020 16:57 > To: Ian Jackson > Cc: Grzegorz Uriasz ; Jan Beulich = ; Andrew Cooper > ; Kevin Tian ; Paul = Durrant ; Wei Liu > ; jakub@bartmin.ski; marmarek@invisiblethingslab.com; = j.nowak26@student.uw.edu.pl; Anthony > Perard ; xen-devel@lists.xenproject.org; = contact@puzio.waw.pl > Subject: Re: [PATCH] libxl: tooling expects wrong errno >=20 > On Mon, Jun 15, 2020 at 03:59:50PM +0100, Ian Jackson wrote: > > Grzegorz Uriasz writes ("[PATCH] libxl: tooling expects wrong = errno"): > > > When iommu is not enabled for a given domain then pci passthrough > > > hypercalls such as xc_test_assign_device return EOPNOTSUPP. > > > The code responsible for this is in "iommu_do_domctl" inside > > > xen/drivers/passthrough/iommu.c > > > This patch fixes the error message reported by libxl when = assigning > > > pci devices to domains without iommu. > > > > > > Signed-off-by: Grzegorz Uriasz > > > Tested-by: Grzegorz Uriasz > > > --- > > > tools/libxl/libxl_pci.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > > > index 957ff5c8e9..bc5843b137 100644 > > > --- a/tools/libxl/libxl_pci.c > > > +++ b/tools/libxl/libxl_pci.c > > > @@ -1561,7 +1561,7 @@ void libxl__device_pci_add(libxl__egc *egc, = uint32_t domid, > > > LOGD(ERROR, domid, > > > "PCI device %04x:%02x:%02x.%u %s?", > > > pcidev->domain, pcidev->bus, pcidev->dev, = pcidev->func, > > > - errno =3D=3D ENOSYS ? "cannot be assigned - no = IOMMU" > > > + errno =3D=3D EOPNOTSUPP ? "cannot be assigned - = no IOMMU" > > > : "already assigned to a different guest"); > > > goto out; > > > } > > > > Thanks. I have addressed some Xen IOMMU maintainers. Can you = confirm > > whether this is right ? >=20 > Not an IOMMU maintainer myself, but I've taken a look at the code and > I think Grzegorz is right. iommu_do_domctl will return -EOPNOTSUPP if > the IOMMU is not enabled for the domain. Another option would be to > check for EBUSY (which will certainly be returned when the device is > busy) and log the error code with a message when it's different than > EBUSY? >=20 > There are many possible error here, for example the device itself > might not be behind an IOMMU, in which case Xen will return -ENODEV at > least on the Intel case. ENOSYS is certainly wrong; it should only be used to indicate an = unimplemented hypercall. I think Roger's suggestion of avoiding EBUSY = and use LOGED would be better though. Paul >=20 > Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 16:12:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 16:12:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrj3-0004jm-Nc; Mon, 15 Jun 2020 16:12:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrj2-0004j3-G2 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 16:12:44 +0000 X-Inumbo-ID: 0af9cf18-af23-11ea-b816-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0af9cf18-af23-11ea-b816-12813bfff9fa; Mon, 15 Jun 2020 16:12:43 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: DVjhz2OacSxeHcAH78go9zXuHDZfmCQ8V8qTBQxH1YVNOxI4ifVpvOUMPMGkFv/O7PbAnYJdyD +5ke4Q5/dxJMGIfACccTgIaG5m0bwPX3OfutoFvA/F3DQ2T8CJ13FOE9V92Ia7/LYPJhLxiNT8 7wavVHNev1uLAjuFoHq+Y777dr6X5PSiQnpJUWC61dojbnex+X5CAmLO/RgDeErn8gWXC4lcni XRbJ3qdK6VAroN0uH05r3lraDBNwSRSEbyzP8GEH/EHAcnCSSk7FtHCwziFW6QdGY2Oz+UJi04 Rt0= X-SBRS: 2.7 X-MesageID: 20378738 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20378738" Subject: Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted To: Ian Jackson References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-3-andrew.cooper3@citrix.com> <24295.35624.644030.417783@mariner.uk.xensource.com> <24295.38146.988316.316252@mariner.uk.xensource.com> From: Andrew Cooper Message-ID: <53a1f221-89ae-0d8e-32ef-c9c8c83580c5@citrix.com> Date: Mon, 15 Jun 2020 17:12:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <24295.38146.988316.316252@mariner.uk.xensource.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15/06/2020 16:34, Ian Jackson wrote: > Andrew Cooper writes ("Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted"): >> Nothing runs it by default, but it is part of my prepush testing for >> anything in the relevant area. >> >> We should do something better, but its not totally trivial.  The x86 >> emulator test for example needs a fairly bleeding edge version of >> binutils, given that we routinely add support for bleeding edge >> instruction groups. > Hmmm. Is it likely that installing the version from Debian testing > (say) would work ? Or do we want to build it from source ? These are > all possibilities. Pulling from Sid may work, if they're fairly prompt to update to new binutils releases.  (They're certainly up to date ATM) Jan: are we ever in a position where we need something more bleeding edge than the latest binutils release? > > We could build binutils from source with a job-specific --prefix > setting and that wouldn't stop it sharing the build host with other > jobs. Maybe it could be a seperate job which provides an anointed > binutils build. > > What other awkward requirements are there ? Most of the tests require running under a suitably configured Xen, and even then, require doing some fairly custom things with the guest. Perhaps a good start would be to split our "unit test like" tests away from our "need a specifically configured Xen" tests.  The former would be rather more amenable to running by default. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 15 16:17:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 16:17:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrnL-0004t1-8Z; Mon, 15 Jun 2020 16:17:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkrnJ-0004sw-KT for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 16:17:09 +0000 X-Inumbo-ID: a90e7e06-af23-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a90e7e06-af23-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 16:17:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 95C0AAE61; Mon, 15 Jun 2020 16:17:11 +0000 (UTC) Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask To: paul@xen.org, 'Andrew Cooper' References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> <6de3a582-d9a8-60b5-9525-c9223932e4ed@citrix.com> <00f901d64013$6615a860$3240f920$@xen.org> From: Jan Beulich Message-ID: <73dcc93f-3d2e-e6f0-a044-83a060bddaa4@suse.com> Date: Mon, 15 Jun 2020 18:17:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <00f901d64013$6615a860$3240f920$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, 'Wei Liu' , 'Roger Pau Monne' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 11.06.2020 19:11, Paul Durrant wrote: >> -----Original Message----- >> From: Andrew Cooper >> Sent: 11 June 2020 17:26 >> To: Roger Pau Monne ; xen-devel@lists.xenproject.org >> Cc: paul@xen.org; Jan Beulich ; Wei Liu >> Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI >> or unmask >> >> On 10/06/2020 15:29, Roger Pau Monne wrote: >>> There's no need to setup a timer for GSIs that are edge triggered, >>> since those don't require any EIO or unmask, and hence couldn't block >>> other interrupts. >>> >>> Note this is only used by PVH dom0, that can setup the passthrough of >>> edge triggered interrupts from the vIO-APIC. One example of such kind >>> of interrupt that can be used by a PVH dom0 would be the RTC timer. >>> >>> While there introduce an out label to do the unlock and reduce code >>> duplication. >>> >>> Signed-off-by: Roger Pau Monné >> >> Acked-by: Andrew Cooper > > Release-acked-by: Paul Durrant Strictly speaking these tags were too little for the patch to go in - the change to drivers/passthrough/io.c would also have required Paul's (or my) R-b. I take it that this was sort of implied by the R-a-b. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 15 16:38:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 16:38:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jks7T-0006YC-28; Mon, 15 Jun 2020 16:37:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jks7S-0006Y7-7d for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 16:37:58 +0000 X-Inumbo-ID: 90c46562-af26-11ea-b81a-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 90c46562-af26-11ea-b81a-12813bfff9fa; Mon, 15 Jun 2020 16:37:56 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 6wL7nnxTvCEzHhOOw6QoD49jx/5X8vooQFJqq3Iy9SnIu0qPZvqdGjKnUwO4fh9ifYa0jwfKPI +SKh+c0682Ca/ZvSws2LEA7ruxZlGdX8DdUCGR/yC2tG7XqLkQNq50RBNNvKv0GrO58/IYQBKJ kX6W6gDupjOBByO4a0EJyhszykZ0d/GfnDFjF4LmuTLJ9rkKJ/6mlahamC8tgbqQavftbirzG+ s4fnhnPvEEDSyYGi47kZIGMRx4gESOGDrJs/VO2Lq8y2DyYiEFw1DA3+Nq5n32mXJzXdoRv7EC faI= X-SBRS: 2.7 X-MesageID: 20856669 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20856669" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.41945.883230.966002@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 17:37:45 +0100 To: Roger Pau Monne Subject: Re: [PATCH] libxl: tooling expects wrong errno In-Reply-To: <20200615155646.GI735@Air-de-Roger> References: <24295.36070.945693.791220@mariner.uk.xensource.com> <20200615155646.GI735@Air-de-Roger> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Wei Liu , Paul Durrant , "jakub@bartmin.ski" , Andrew Cooper , "marmarek@invisiblethingslab.com" , Grzegorz Uriasz , Anthony Perard , Jan Beulich , "j.nowak26@student.uw.edu.pl" , "xen-devel@lists.xenproject.org" , "contact@puzio.waw.pl" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Roger Pau Monne writes ("Re: [PATCH] libxl: tooling expects wrong errno"): > On Mon, Jun 15, 2020 at 03:59:50PM +0100, Ian Jackson wrote: > > Grzegorz Uriasz writes ("[PATCH] libxl: tooling expects wrong errno"): > > > When iommu is not enabled for a given domain then pci passthrough > > > hypercalls such as xc_test_assign_device return EOPNOTSUPP. > > > The code responsible for this is in "iommu_do_domctl" inside > > > xen/drivers/passthrough/iommu.c > > > This patch fixes the error message reported by libxl when assigning > > > pci devices to domains without iommu. > > > > > > Signed-off-by: Grzegorz Uriasz > > > Tested-by: Grzegorz Uriasz > > > --- > > > tools/libxl/libxl_pci.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > > > index 957ff5c8e9..bc5843b137 100644 > > > --- a/tools/libxl/libxl_pci.c > > > +++ b/tools/libxl/libxl_pci.c > > > @@ -1561,7 +1561,7 @@ void libxl__device_pci_add(libxl__egc *egc, uint32_t domid, > > > LOGD(ERROR, domid, > > > "PCI device %04x:%02x:%02x.%u %s?", > > > pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func, > > > - errno == ENOSYS ? "cannot be assigned - no IOMMU" > > > + errno == EOPNOTSUPP ? "cannot be assigned - no IOMMU" > > > : "already assigned to a different guest"); > > > goto out; > > > } > > > > Thanks. I have addressed some Xen IOMMU maintainers. Can you confirm > > whether this is right ? > > Not an IOMMU maintainer myself, but I've taken a look at the code and > I think Grzegorz is right. iommu_do_domctl will return -EOPNOTSUPP if > the IOMMU is not enabled for the domain. Another option would be to > check for EBUSY (which will certainly be returned when the device is > busy) and log the error code with a message when it's different than > EBUSY? > > There are many possible error here, for example the device itself > might not be behind an IOMMU, in which case Xen will return -ENODEV at > least on the Intel case. Thanks for the analysis. So: Acked-by: Ian Jackson This would seem to be a backport candidate. AFAICT check has been there, looking for ENOSYS, since this code was introduced in 826eb17271d3c647516d9944c47b0779afedea25 libxl: suppress device assignment to HVM guest when there is no IOMMU ? But that commit has a Tested-by. Maybe Xen changed its error return at some point ? Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 16:53:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 16:53:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksM2-00088h-H8; Mon, 15 Jun 2020 16:53:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksM1-000880-HO for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 16:53:01 +0000 X-Inumbo-ID: a7bbb898-af28-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a7bbb898-af28-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 16:52:54 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ogwVSP6sgRf3vISs9oDIA72rmuVO3ykqi0ng0XugkFMlFYpWvSszEQrgg5rnUQlX/r3HyRrAws 79Um+qmAsa/DJznWc5iTyejkKz9/1lWGI9etbKo4Dk1vXmSBqHpj5Qnq/y1uBFKfs61C8eJxFw QaPpOiVAUbx3q0IytCYwC8sovLU6KAVqBGhB8EVDU2w0ybqG5L9x8p6LyPEQy8l/OjyWloGXsE mlbyjVVY/vjNt0Oy4ckUKC6KtLsCqsCzlnO9m7kPQoFklgHRfGdnxhjM+oIgBNAipsKP015T6k REE= X-SBRS: 2.7 X-MesageID: 20427979 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20427979" Date: Mon, 15 Jun 2020 18:52:44 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Martin Lucina Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200615165101.GJ735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <20200615150344.GG735@Air-de-Roger> <4a0bb4fa4dca2732feae4e2f825eb2a6@lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4a0bb4fa4dca2732feae4e2f825eb2a6@lucina.net> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 05:51:51PM +0200, Martin Lucina wrote: > On 2020-06-15 17:03, Roger Pau Monné wrote: > > This way of event channel injection is slitgly hackish, and I would > > recommend using HVMOP_set_evtchn_upcall_vector, that way vectors will > > be properly routed using the lapic. > > > > Using HVM_PARAM_CALLBACK_TYPE_VECTOR vectors are injected without > > setting the IRR/ISR bit in the lapic registers. > > I picked HVM_PARAM_CALLBACK_TYPE_VECTOR since that seemed like the easiest > option for a uniprocessor, PVH-only guest. > > What does mean in the context of HVMOP_set_evtchn_upcall_vector? If > it's an APIC vector number (sorry, not too familiar with the post-legacy > i8259 world), does that imply that if I use HVMOP_set_evtchn_upcall_vector I > need to do some APIC initialisation / programming? > > All I need for Solo5/Mirage purposes is to have the upcall land on IDT > vector #32 or above. Oh, OK. It was reported that HVM_PARAM_CALLBACK_TYPE_VECTOR doesn't work well with migration and when using hardware APIC virtualization IIRC, because of the fact that interrupts are not signaled in the lapic and directly injected. > > > Questions: > > > > > > 1. Being based on the Solo5 virtio code, the low-level setup code is > > > doing > > > the "usual" i8259 PIC setup, to remap the PIC IRQs to vectors 32 and > > > above. > > > Should I be doing this initialisation for Xen PVH at all? > > > > Hm, there are no IO-APICs (or legacy PICs) on a PVH domU, so there's > > not much to route. If Solo5 is thinking it's somehow configuring them > > it's likely writing to some hole in memory, or to some RAM. > > Solo5 only has a very primitive understanding of hardware interrupts, so > it's only configuring the legacy PICs via port IO. Oh, then there's definitely no legacy PIC at all. Writes to the PIC IO ports will be dropped/ignored, and reads will return ~0. I guess you could implement some check based on that in order to avoid doing any initialization? I don't think it should be harmful in any way, but you are just likely spending a bunch of time trapping into the hypervisor to handle those reads/writes for no good reason. > > > > IO-APIC presence is signaled on the ACPI MADT table on PVH domU. > > > > Hmm, it'd be very unfortunate if I had to deal with ACPI, so here's hoping > that I don't actually need to touch the APIC. If you don't do any IO-APIC configuration at all then that's completely fine. > > > I'm not interested > > > in using the PIC for anything, and all interrupts will be delivered > > > via Xen > > > event channels. > > > > > > 2. Related to the above, the IRQ handler code is ACKing the > > > interrupt after > > > the handler runs. Should I be doing that? Does ACKing "IRQ" 0 on the > > > PIC > > > have any interactions with Xen's view of event channels/pending > > > upcalls? > > > > Which kind of ACking it's doing? Is it writing to the lapic EOI > > register? If so that would be OK when using > > HVMOP_set_evtchn_upcall_vector. If using > > HVM_PARAM_CALLBACK_TYPE_VECTOR there's nothing to Ack I think. > > Legacy PIC EOI via port IO. No need to do that. There's no legacy PIC on PVH, and then event channel interrupts are not routed through the PIC when using HVM_PARAM_CALLBACK_TYPE_VECTOR. > > I'm not sure. Keep in mind that a new call to hypercall_set_timer_op > > will overwrite the previous timer, and hence should be fine I think as > > long as you are using the one-shot timer. > > Is there something other than a one-shot timer? hypercall_set_timer_op is > just a single-argument hypercall with an uint64_t deadline, right? (And not > documented in xen.h either ...) There's also a periodic timer (see VCPUOP_{set/stop}_periodic_timer), which was enabled by default at 100Hz for PV guests. This is not the case for PVH. > > > I can also post the code that does the actual demuxing of events > > > from Xen > > > (i.e. the upcall handler), but I've read through that several times > > > now and > > > I don't think the problem is there; adding diagnostic prints to both > > > the > > > low-level C event channel code and higher-level OCaml Activations code > > > confirms that received events are being mapped to their ports > > > correctly. > > > > I can take a look at the event channel handler if you want, as you > > wish. The only weird think I've noticed is the error in the unmask > > where you seem to use evtchn_mask instead of evtchn_pending. > > Thanks for the offer, this stuff is fairly subtle. > > In the Mirage/Xen scenario, there are two parts to the upcall handler. The > top half is executed in interrupt context and basically does nothing except > acknowledge the upcall: > > int solo5__xen_evtchn_vector_handler(void *arg __attribute__((unused))) > { > struct vcpu_info *vi = VCPU0_INFO(); > > /* > * All work is done outside of interrupt context by > evtchn_demux_pending(), > * so all we need to do here is acknowledge the upcall from Xen. > */ > vi->evtchn_upcall_pending = 0; I think you should best avoid clearing evtchn_upcall_pending here, as Xen will then inject more vector callbacks if a new event is signaled, even when you have not processed the previous one? > return 1; > } > > The bottom half is then called periodically (and always before blocking) by > the OCaml code: > > static bool evtchn_demux_pending(void) > { > struct shared_info *s = SHARED_INFO(); > struct vcpu_info *vi = VCPU0_INFO(); > bool some_pending = false; > > vi->evtchn_upcall_pending = 0; > > /* > * Demux events received from Xen. > * > * pending_l1 is the "outer" per-VCPU selector (evtchn_pending_sel). > * pending_l2 is the "inner" system-wide word (evtchn_pending[l1i]). > */ > xen_ulong_t pending_l1, pending_l2; > atomic_sync_xchg(&vi->evtchn_pending_sel, 0, &pending_l1); > while (pending_l1 != 0) { > xen_ulong_t l1i = ffs(pending_l1); > > /* > * Masking pending_l2 with ~evtchn_mask[l1i] is necessary to get the > * *current* masked events; otherwise races like the following > * can occur: > * > * 1. X is generated, upcall scheduled by Xen. > * 2. X is masked. > * 3. Upcall is delivered. > * 4. X fires despite now being masked. > */ > while ((pending_l2 = > (s->evtchn_pending[l1i] & ~s->evtchn_mask[l1i])) != 0) { > xen_ulong_t l2i = ffs(pending_l2); > > evtchn_port_t port = (l1i * (sizeof(xen_ulong_t) * 8)) + l2i; > /* > * Mark as pending on the OCaml side. > */ > evtchn_callback_ml[port] = 1; How is this cleared? It must be cleared before the handler is run, or else you will likely miss interrupts. Also, I think you could mask the port before setting evtchn_callback_ml and unmask it when evtchn_callback_ml is cleared? > some_pending = true; > > atomic_sync_btc(l2i, &s->evtchn_pending[l1i]); > } > > pending_l1 &= ~(1UL << l1i); > } > > return some_pending; > } If you can dump the event channel numbers and their usage from Solo5 then you can check against the 'e' debug key from Xen in order to check if there are indeed pending events to be delivered on some of them. Just checking the output from the 'e' debug key will tell you if there's anything pending and if there are any channels masked. Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 16:58:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 16:58:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksRY-0008MT-AB; Mon, 15 Jun 2020 16:58:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksRW-0008MO-Vx for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 16:58:43 +0000 X-Inumbo-ID: 76887684-af29-11ea-b81b-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 76887684-af29-11ea-b81b-12813bfff9fa; Mon, 15 Jun 2020 16:58:41 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: EXtZe8DLeKVW4NdhUXHJmGzS59nbanjNfuh7yl5Z6MYZ/Kz9FQVS9HiRIleskPNxIm72kqgted AOGB8s90YLICbqr6FjalVEdRHyP4F79zci3LGleFoo9/t2Lo7GEq6+DUYDLS5pyyGl3KAXJpAK uthQbNTH8WWi950siBHikKGEDc4Zoaq7mP3/iaobTRbg+UD9ootzT0VIvv52jWVx97Zn+heRu5 iLZ9UkXvVuxmwXpEdzTlR9bW+gDx2sAAlUxKh3Qc3DHDLyn0YJhOC05c+LXpLpUyQuSb55w/TF pjg= X-SBRS: 2.7 X-MesageID: 20383002 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20383002" Subject: Re: Event delivery and "domain blocking" on PVHv2 To: , , References: <62479d08f7650c22678d7a86851eafc4@lucina.net> From: Andrew Cooper Message-ID: <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> Date: Mon, 15 Jun 2020 17:58:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <62479d08f7650c22678d7a86851eafc4@lucina.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15/06/2020 15:25, Martin Lucina wrote: > Hi, > > puzzle time: In my continuing explorations of the PVHv2 ABIs for the > new MirageOS Xen stack, I've run into some issues with what looks like > missed deliveries of events on event channels. > > While a simple unikernel that only uses the Xen console and > effectively does for (1..5) { printf("foo"); sleep(1); } works fine, > once I plug in the existing OCaml Xenstore and Netfront code, the > behaviour I see is that the unikernel hangs in random places, blocking > as if an event that should have been delivered has been missed. You can see what is going on, event channel wise, with the 'e' debug-key.  This will highlight cases such as the event channel being masked and pending, which is a common guest bug ending up in this state. > > > Given that I've essentially re-written the low-level event channel C > code, I'd like to verify that the mechanisms I'm using for event > delivery are indeed the right thing to do on PVHv2. > > For event delivery, I'm registering the upcall with Xen as follows: > >     uint64_t val = 32ULL; >     val |= (uint64_t)HVM_PARAM_CALLBACK_TYPE_VECTOR << 56; >     int rc = hypercall_hvm_set_param(HVM_PARAM_CALLBACK_IRQ, val); >     assert(rc == 0); > > i.e. upcalls are to be delivered via IDT vector. Don't use HVM_PARAM_CALLBACK_TYPE_VECTOR.  It is conceptually broken, as it bypasses all queueing and IRR logic in the LAPIC. At some point, I'm going to have to figure out a compatible way to deal with all the guests still using this mechanism, because it is incompatible with using hardware accelerated APIC support in IvyBridge/Zen+ hardware. Use HVMOP_set_evtchn_upcall_vector instead, which does the same thing, but actually behaves like a real vector as far as the rest of the LAPIC is concerned. > > Questions: > > 1. Being based on the Solo5 virtio code, the low-level setup code is > doing the "usual" i8259 PIC setup, to remap the PIC IRQs to vectors 32 > and above. Should I be doing this initialisation for Xen PVH at all? > I'm not interested in using the PIC for anything, and all interrupts > will be delivered via Xen event channels. PVH guests don't get a PIC by default.  Xen will just be swallowing all your setup and doing nothing with it. "plain" PVH guests also don't get an IO-APIC by default.  Unless you're wanting to get PVH dom0 support working, (or PCI Passthrough in the future), don't worry about the IO-APIC either. > > 2. Related to the above, the IRQ handler code is ACKing the interrupt > after the handler runs. Should I be doing that? Does ACKing "IRQ" 0 on > the PIC have any interactions with Xen's view of event > channels/pending upcalls? There's no PIC to begin with, but even then, talking to the PIC/IO-APIC would only be correct for type INTX/GSI. TYPE_VECTOR shouldn't have an ack at the LAPIC (it is this properly which makes it incompatible with hardware acceleration), while HVMOP_set_evtchn_upcall_vector should be acked at the LAPIC. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 15 17:04:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 17:04:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksX8-0000p9-1w; Mon, 15 Jun 2020 17:04:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksX7-0000p4-7n for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 17:04:29 +0000 X-Inumbo-ID: 458eff16-af2a-11ea-8496-bc764e2007e4 Received: from mail-ed1-x531.google.com (unknown [2a00:1450:4864:20::531]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 458eff16-af2a-11ea-8496-bc764e2007e4; Mon, 15 Jun 2020 17:04:28 +0000 (UTC) Received: by mail-ed1-x531.google.com with SMTP id w7so12094468edt.1 for ; Mon, 15 Jun 2020 10:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=S2de4X8bQU6oWpw9XaayCjvxIw6dq1jIeG/5ypF6h+0=; b=sK8XRmAd3KFxuWu4466Dk9HVnw2TiJbEsJSnm/6lyEXt5N0espnfh695n52Ooim3Q+ Kfu1H/t3HLf5O3oVs5KrkOYqugjesNReYM6Ub/6LZZLGe2nLlJsBfy2XnS/6DmBZI+su Z/u0bKGj912/LN39/OG/UxiT9KU7yEwLhaKzCAhEylz5NHicjxsGgIE7muU+Vjig+pzQ RCtwoHPgWVU1a4K2PeqHwm/aIcQ+kfo3rXkccGf15j4cbrt3F/xdFsOk+ib1WqCOY7zJ CCEtzTOtZ9r33QpeVOrc3tuII9BFLhWFlHIelJpMAY9sH7NNJSIWcmkrsUU2jTrpngYr wbJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=S2de4X8bQU6oWpw9XaayCjvxIw6dq1jIeG/5ypF6h+0=; b=jkSkmIcczUz9WQQtOoMg1SLokAqd3QiihwDJW6r+1ljXM12WSHTu7CjQtcm0o1WNuT 4SmP4NYMQuk9i1Sh+IIVDCeATEwxzREoBe80AklnM1O91YsYC8hPaCtnD2v/7An4idkh rlkTYV+UnGU6Ibh2+tId7eIbI2TbleqqjOcH1dAjqBT2AHMK0HuqENwn7vg0i71Hw97v jjMylZ1Pb1Ec/GZZRehiaf1tMvkglIrU8weo/arAXzTxRsOxbBgKXOtpNPxBUGRV7eSC +WmINk/Te4klvS3ufb6Ii0Duuw2U9ebAtFmn53AwMPBD2sbjLzRLYyY/DG3LdXcC5KrT wkwg== X-Gm-Message-State: AOAM531DNiFM3zVi4znaCOODv7mWVvRavwUJ7A8be0Eh3/rzjESCnmrP qX63tlBTC5GR5wrdi2zokhVdtWizrwY= X-Google-Smtp-Source: ABdhPJyDMSfThUyMXff4nQaOrfl9LFCNstxUsEyenT5TwyNyCOjz7pFCoVbJp91tnuNCUR4Hbbt9Qg== X-Received: by 2002:a05:6402:3052:: with SMTP id bu18mr24025992edb.323.1592240667450; Mon, 15 Jun 2020 10:04:27 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id o16sm9416577ejg.106.2020.06.15.10.04.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 10:04:26 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200615141532.1927-1-andrew.cooper3@citrix.com> In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge Date: Mon, 15 Jun 2020 18:04:25 +0100 Message-ID: <003101d64337$06b202c0$14160840$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQBu9n1OIN1/SF0JEfFzSQwAilcbPKuogK/g X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Ian Jackson' , 'Jan Beulich' , 'Wei Liu' , =?UTF-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = Andrew Cooper > Sent: 15 June 2020 15:15 > To: Xen-devel > Cc: Wei Liu ; Paul Durrant ; Andrew Cooper = ; Jan > Beulich ; Ian Jackson ; = Roger Pau Monn=C3=A9 > > Subject: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge >=20 > This is some work in light of IvyBridge not gaining microcode to = combat SRBDS > / XSA-320. It is a mix of some work I'd planned for 4.15, and some = patches > posted already and delayed due to dependence's I'd discovered = after-the-fact. >=20 > This provides a more user-friendly way of making IvyBridge safe by = default > without encountering migration incompatibilities. >=20 > In terms of functionality, it finishes the "fresh boot" vs = "migrate/restore > from pre-4.14" split in the libxc CPUID logic, and uses this to let us = safely > hide features by default without breaking the "divine what a guest may = have > seen previously" logic on migrate. >=20 > On top of that, we hide RDRAND by default to mitigate XSA-320. >=20 > Additionally, take the opportunity of finally getting this logic = working to > hide MPX by default (as posted previously), due to upcoming Intel = timelines. >=20 > Request for 4.14. The IvyBridge angle only became apparent after the = public > embargo on Tue 9th. Otherwise, I would have made a concerted effort = to get > this logic sorted sooner and/or part of XSA-320 itself. >=20 > Strictly speaking, patches 1-4 aren't necessary, but without them the = logic is > very confusing to follow, particularly the reasoning about the safely = of later > changes. As it is a simple set of transforms, we're better with them = than > without. >=20 > Also, the MPX patch isn't related to the RDRAND issue, but I was = planning to > get it into 4.14 already, until realising that the migration path was = broken. > Now that the path is fixed for the RDRAND issue, include the MPX patch = as it > pertains to future hardware compatibility (and would be backported to = 4.14.1 > if it misses 4.14.0). >=20 Fair enough. Once the series has all the requisite maintainer acks then = I'll release-ack it. Paul > Andrew Cooper (9): > tools/libx[cl]: Introduce struct xc_xend_cpuid for xc_cpuid_set() > tests/cpu-policy: Confirm that CPUID serialisation is sorted > tools/libx[cl]: Move processing loop down into xc_cpuid_set() > tools/libx[cl]: Merge xc_cpuid_set() into xc_cpuid_apply_policy() > tools/libx[cl]: Plumb bool restore down into xc_cpuid_apply_policy() > x86/gen-cpuid: Distinguish default vs max in feature annotations > x86/hvm: Disable MPX by default > x86/cpuid: Introduce missing feature adjustment in = calculate_pv_def_policy() > x86/spec-ctrl: Hide RDRAND by default on IvyBridge >=20 > docs/misc/xen-command-line.pandoc | 20 ++- > tools/libxc/include/xenctrl.h | 42 ++++- > tools/libxc/xc_cpuid_x86.c | 239 = ++++++++++++++++------------ > tools/libxl/libxl.h | 8 +- > tools/libxl/libxl_cpuid.c | 17 +- > tools/libxl/libxl_create.c | 2 +- > tools/libxl/libxl_dom.c | 2 +- > tools/libxl/libxl_internal.h | 12 +- > tools/libxl/libxl_nocpuid.c | 2 +- > tools/tests/cpu-policy/test-cpu-policy.c | 49 +++++- > xen/arch/x86/cpuid.c | 23 +++ > xen/include/public/arch-x86/cpufeatureset.h | 4 +- > xen/tools/gen-cpuid.py | 18 +-- > 13 files changed, 278 insertions(+), 160 deletions(-) >=20 > -- > 2.11.0 >=20 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 17:06:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 17:06:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksZG-0000vL-FN; Mon, 15 Jun 2020 17:06:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksZF-0000vB-92 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 17:06:41 +0000 X-Inumbo-ID: 9453c3de-af2a-11ea-b7bb-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9453c3de-af2a-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 17:06:40 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id mb16so18243033ejb.4 for ; Mon, 15 Jun 2020 10:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=fv7nnBeBN3t+0SzoePEsGvirfQqzkR7nUscp0sk7wKg=; b=B/UVhXhtGKeUjK5lw2T7YYj4Aswb4muvL7d9g5TG1wmqip47B1oMc+qO8jM/vbKmbb z/tf/PIv61WHstnUcvuYc3yVCJ210WeDgadwBZACY+he+wwYgE3vW+K0WZjK/nlXh7rT 8vPHXWE6/Aj+oLWAVgAnURWghLMs2Yn+DTQqdXzlNfFN99bJQe5f9c+3g7YLUFlGyrg9 6YcJufo30hNyGOUREZ/wEWMKCkgdTOugrf8+oFPbvrlAK1c7OIKMudTT3vY68J8i0Fuz l2cWsFRi7qNPXwVZ54earhr2ppaCU4I/wIigTKAU7RdbCaFV7qHcLwYfXheU8hIoi3q2 IrUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=fv7nnBeBN3t+0SzoePEsGvirfQqzkR7nUscp0sk7wKg=; b=ZgRnYKup00ZTxrqBISQR4rSQzvs+5Zh3ZY1Gf9n2dy6qkQlGlbzt5pFjOGFPWWWe+m 4bIjwT/YlJ1/3gPYos/p9Nn1+KJguf7pFZscL9gy8tn9mEO+chRzCcMLkHkk+yF4W4Je XxuFc9cMMXoVJkuHDZmzfVpB9KI8YB6jLF7FD8/A0jkrBOsjq/AtOv13/IUXRkSbfIgW e7G4KB0Ps6jGnIso7tGaaV6WMT4WA53RcrM+A9X9ljeWnwufANsSa/zKiQYL2e6Oz0fh HTDf2kOYfElhbNfdVYAg5g5s96SB0bNy9GlUzDf9CZl9aNAM2LhVO5CMLzj3VD+ChvrU OUhw== X-Gm-Message-State: AOAM533FVyP16R5uJVmkmoWVWMFtdfDvJ9nms/VlUUP+uYbeu40JKnd2 8/ePhTFWvqwTzZkjO9eIf2GXhYEndEY= X-Google-Smtp-Source: ABdhPJwzm23I3hKoXOt9OigmGejD9tyehF1OBbGUOfD/VNvvJ+hZvX/6iLfUx55zI+fB5OY3w/Cl3w== X-Received: by 2002:a17:906:b2c1:: with SMTP id cf1mr28060609ejb.135.1592240799696; Mon, 15 Jun 2020 10:06:39 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id ox27sm9352676ejb.101.2020.06.15.10.06.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 10:06:39 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> In-Reply-To: <20200610142923.9074-3-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask Date: Mon, 15 Jun 2020 18:06:38 +0100 Message-ID: <003201d64337$557ce8c0$0076ba40$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHx2+DDRjLQssRal4XfU2f+2Pe7FQIj4hRNqJGXxVA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 10 June 2020 15:29 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Jan Beulich = ; Andrew > Cooper ; Wei Liu > Subject: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for = GSIs not requiring an EOI or > unmask >=20 > There's no need to setup a timer for GSIs that are edge triggered, > since those don't require any EIO or unmask, and hence couldn't block > other interrupts. >=20 > Note this is only used by PVH dom0, that can setup the passthrough of > edge triggered interrupts from the vIO-APIC. One example of such kind > of interrupt that can be used by a PVH dom0 would be the RTC timer. >=20 > While there introduce an out label to do the unlock and reduce code > duplication. >=20 > Signed-off-by: Roger Pau Monn=C3=A9 Reviewed-by: Paul Durrant > --- > Changes since v1: > - Introduce an out label that does the unlock. > --- > xen/drivers/passthrough/io.c | 24 +++++++++++++++--------- > xen/include/asm-x86/hvm/irq.h | 2 ++ > 2 files changed, 17 insertions(+), 9 deletions(-) >=20 > diff --git a/xen/drivers/passthrough/io.c = b/xen/drivers/passthrough/io.c > index b292e79382..6b1305a3e5 100644 > --- a/xen/drivers/passthrough/io.c > +++ b/xen/drivers/passthrough/io.c > @@ -138,7 +138,8 @@ static void pt_pirq_softirq_reset(struct = hvm_pirq_dpci *pirq_dpci) >=20 > bool pt_irq_need_timer(uint32_t flags) > { > - return !(flags & (HVM_IRQ_DPCI_GUEST_MSI | = HVM_IRQ_DPCI_TRANSLATE)); > + return !(flags & (HVM_IRQ_DPCI_GUEST_MSI | HVM_IRQ_DPCI_TRANSLATE = | > + HVM_IRQ_DPCI_NO_EOI)); > } >=20 > static int pt_irq_guest_eoi(struct domain *d, struct hvm_pirq_dpci = *pirq_dpci, > @@ -558,6 +559,12 @@ int pt_irq_create_bind( > */ > ASSERT(!mask); > share =3D trigger_mode; > + if ( trigger_mode =3D=3D VIOAPIC_EDGE_TRIG ) > + /* > + * Edge IO-APIC interrupt, no EOI or unmask = to perform > + * and hence no timer needed. > + */ > + pirq_dpci->flags |=3D HVM_IRQ_DPCI_NO_EOI; > } > } >=20 > @@ -897,17 +904,13 @@ static void hvm_dirq_assist(struct domain *d, = struct hvm_pirq_dpci *pirq_dpci) > send_guest_pirq(d, pirq); >=20 > if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI ) > - { > - spin_unlock(&d->event_lock); > - return; > - } > + goto out; > } >=20 > if ( pirq_dpci->flags & HVM_IRQ_DPCI_GUEST_MSI ) > { > vmsi_deliver_pirq(d, pirq_dpci); > - spin_unlock(&d->event_lock); > - return; > + goto out; > } >=20 > list_for_each_entry ( digl, &pirq_dpci->digl_list, list ) > @@ -920,6 +923,8 @@ static void hvm_dirq_assist(struct domain *d, = struct hvm_pirq_dpci *pirq_dpci) > if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI ) > { > hvm_gsi_assert(d, pirq->pirq); > + if ( pirq_dpci->flags & HVM_IRQ_DPCI_NO_EOI ) > + goto out; > pirq_dpci->pending++; > } >=20 > @@ -927,8 +932,7 @@ static void hvm_dirq_assist(struct domain *d, = struct hvm_pirq_dpci *pirq_dpci) > { > /* for translated MSI to INTx interrupt, eoi as early as = possible */ > __msi_pirq_eoi(pirq_dpci); > - spin_unlock(&d->event_lock); > - return; > + goto out; > } >=20 > /* > @@ -941,6 +945,8 @@ static void hvm_dirq_assist(struct domain *d, = struct hvm_pirq_dpci *pirq_dpci) > ASSERT(pt_irq_need_timer(pirq_dpci->flags)); > set_timer(&pirq_dpci->timer, NOW() + PT_IRQ_TIME_OUT); > } > + > + out: > spin_unlock(&d->event_lock); > } >=20 > diff --git a/xen/include/asm-x86/hvm/irq.h = b/xen/include/asm-x86/hvm/irq.h > index d306cfeade..532880d497 100644 > --- a/xen/include/asm-x86/hvm/irq.h > +++ b/xen/include/asm-x86/hvm/irq.h > @@ -121,6 +121,7 @@ struct dev_intx_gsi_link { > #define _HVM_IRQ_DPCI_GUEST_PCI_SHIFT 4 > #define _HVM_IRQ_DPCI_GUEST_MSI_SHIFT 5 > #define _HVM_IRQ_DPCI_IDENTITY_GSI_SHIFT 6 > +#define _HVM_IRQ_DPCI_NO_EOI_SHIFT 7 > #define _HVM_IRQ_DPCI_TRANSLATE_SHIFT 15 > #define HVM_IRQ_DPCI_MACH_PCI (1u << = _HVM_IRQ_DPCI_MACH_PCI_SHIFT) > #define HVM_IRQ_DPCI_MACH_MSI (1u << = _HVM_IRQ_DPCI_MACH_MSI_SHIFT) > @@ -129,6 +130,7 @@ struct dev_intx_gsi_link { > #define HVM_IRQ_DPCI_GUEST_PCI (1u << = _HVM_IRQ_DPCI_GUEST_PCI_SHIFT) > #define HVM_IRQ_DPCI_GUEST_MSI (1u << = _HVM_IRQ_DPCI_GUEST_MSI_SHIFT) > #define HVM_IRQ_DPCI_IDENTITY_GSI (1u << = _HVM_IRQ_DPCI_IDENTITY_GSI_SHIFT) > +#define HVM_IRQ_DPCI_NO_EOI (1u << = _HVM_IRQ_DPCI_NO_EOI_SHIFT) > #define HVM_IRQ_DPCI_TRANSLATE (1u << = _HVM_IRQ_DPCI_TRANSLATE_SHIFT) >=20 > struct hvm_gmsi_info { > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 17:07:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 17:07:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksa2-0000zk-PV; Mon, 15 Jun 2020 17:07:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksa1-0000zY-CM for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 17:07:29 +0000 X-Inumbo-ID: b11ffa28-af2a-11ea-8496-bc764e2007e4 Received: from mail-ej1-x62f.google.com (unknown [2a00:1450:4864:20::62f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b11ffa28-af2a-11ea-8496-bc764e2007e4; Mon, 15 Jun 2020 17:07:28 +0000 (UTC) Received: by mail-ej1-x62f.google.com with SMTP id gl26so18206499ejb.11 for ; Mon, 15 Jun 2020 10:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=hqHhgaFrlcO83k4C5b2M9JPfNRM2JDDLhQ2XRBpOHtY=; b=LoGksC0K9WNR/Us8A+tvRA79I7Ek74p0qSFd5AgCgaTWtGOEd104GftXixeiTxsrlN t1KuucguMXMqKCj42OkQM2t61M9OEABVUcVJGDiQdgmLg9BTW0+CJh5KJwS94fLiFCZF HhcyCuIDTgayDsYeCa6R3XvTPHxKfBUuQnbK3YO/hx1lZYwr9VKVe8e+iw3zKhzcKYQi rlXjzEd0OG3OaKGKdhX4D5UNOz0y2PkbXxp0yJlN7HJ+8FxEdsFG4JUZ9pjj1Wmna8oF qMYkwzfMDeqfeoX0l9UynU9pZXrlMFF9qhicoHUPzy0DWIvFqdy+DBukJ1jEruX8GUfg Oh3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=hqHhgaFrlcO83k4C5b2M9JPfNRM2JDDLhQ2XRBpOHtY=; b=Eilsit1xJoacEdjUB2EhQhsPNjlfeccIovRjUYVTwXFgd2HwxCq40nUkPEzORNZDiN g7LfIZflbvEJKiAJJbQOo/4b5FgsahFh7Xb+UDwFs2bWKVKr5DaehdlwqcMcLrYYVtVl ubX7Dkr2cZCYjnH/b3hyQM/1PpCySCSFd5ljeURRHbkLlsIOTFl8xgb2KDMEn978wvhR N9QO6fOXomLV1oshfWHQtYcZ1MliMVILSOQSIbryBBWItJ2bC7Mvmn64yUOjbmWIdo7i Z3LnQlaRXmHlDhNF3AbRIsg+VTQv4qoPSe5FZ2tNKh+p9Z2JubVVkfQC3Q6x1jyltFQ8 /w3A== X-Gm-Message-State: AOAM531wcKjxz6KDMkg3LYpmHOxzfv3jyN+6IhRCdbJ4sV/iYrStZguq tunG/YmmnoSIXGtk0j5fo8M= X-Google-Smtp-Source: ABdhPJz0w5KKIX4jtQJHwTc3CgYftxEl23fW/zTaMRUnhIoZR0mGobxmlElq+Qej0P+z9sve6aznZw== X-Received: by 2002:a17:906:f1cf:: with SMTP id gx15mr25773015ejb.207.1592240848012; Mon, 15 Jun 2020 10:07:28 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id w21sm9462115ejc.11.2020.06.15.10.07.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 10:07:27 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , "'Andrew Cooper'" References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> <6de3a582-d9a8-60b5-9525-c9223932e4ed@citrix.com> <00f901d64013$6615a860$3240f920$@xen.org> <73dcc93f-3d2e-e6f0-a044-83a060bddaa4@suse.com> In-Reply-To: <73dcc93f-3d2e-e6f0-a044-83a060bddaa4@suse.com> Subject: RE: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask Date: Mon, 15 Jun 2020 18:07:26 +0100 Message-ID: <003301d64337$725ba800$5712f800$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHx2+DDRjLQssRal4XfU2f+2Pe7FQIj4hRNAekcXgMCG/MkqgGc689vqGSIHSA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Wei Liu' , 'Roger Pau Monne' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 15 June 2020 17:17 > To: paul@xen.org; 'Andrew Cooper' > Cc: 'Roger Pau Monne' ; = xen-devel@lists.xenproject.org; 'Wei Liu' > Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag = for GSIs not requiring an EOI > or unmask >=20 > On 11.06.2020 19:11, Paul Durrant wrote: > >> -----Original Message----- > >> From: Andrew Cooper > >> Sent: 11 June 2020 17:26 > >> To: Roger Pau Monne ; = xen-devel@lists.xenproject.org > >> Cc: paul@xen.org; Jan Beulich ; Wei Liu = > >> Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a = flag for GSIs not requiring an > EOI > >> or unmask > >> > >> On 10/06/2020 15:29, Roger Pau Monne wrote: > >>> There's no need to setup a timer for GSIs that are edge triggered, > >>> since those don't require any EIO or unmask, and hence couldn't = block > >>> other interrupts. > >>> > >>> Note this is only used by PVH dom0, that can setup the passthrough = of > >>> edge triggered interrupts from the vIO-APIC. One example of such = kind > >>> of interrupt that can be used by a PVH dom0 would be the RTC = timer. > >>> > >>> While there introduce an out label to do the unlock and reduce = code > >>> duplication. > >>> > >>> Signed-off-by: Roger Pau Monn=C3=A9 > >> > >> Acked-by: Andrew Cooper > > > > Release-acked-by: Paul Durrant >=20 > Strictly speaking these tags were too little for the patch to go > in - the change to drivers/passthrough/io.c would also have > required Paul's (or my) R-b. I take it that this was sort of > implied by the R-a-b. FAOD I have added my R-b. Paul >=20 > Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 15 17:11:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 17:11:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksdZ-0001ox-9r; Mon, 15 Jun 2020 17:11:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jksdY-0001os-0M for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 17:11:08 +0000 X-Inumbo-ID: 33218fb4-af2b-11ea-bca7-bc764e2007e4 Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 33218fb4-af2b-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 17:11:06 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id d15so12075773edm.10 for ; Mon, 15 Jun 2020 10:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=NQyNmeeYlzA3FqZTPsLGUbnEixa7Hg3xx8TpRJdFhgc=; b=IwsbgP1H1QIRpHl4gWXsKhniiGu1c5PzSANpCCEPENENzjh767LU9Y60re6DC/8cMf fQUAhWRPR2baFtUy8sv+aEe2LT++NOgGRmfsjue5O16uweBQPC2z/LWfSefqPvtebtzg MjIe4NajQGBK72K7T76QzpOjfhNTmmqCAM1lCesq5VlRa+MMUdre5fFkc9pazpSolUCk nTlC0V5AfcBRIoIE/ovOyNrobK8z3NYrfyUBKUMpzg2tB4fKRA4MhalSfXBXMfv6H+Zs NnypYmyFhD+BrmG3PpwJCqjMH61h9wa3Hn8XPgbYCg2XRqnofM7cUFcpsskhxjSxwkFb iKAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=NQyNmeeYlzA3FqZTPsLGUbnEixa7Hg3xx8TpRJdFhgc=; b=I1D46PPDY/tcpPAu8EHI5nQbPXdchc7it8SlywYfo8FiNkIH1q3xwBNA6mPUDfYoh0 vnQCDp8HsjMh41H7mCmRqpLxvLr+bnvZWBuY86M05hVKgOvyV+YfK5Enhy/Q8MdQ9VQI +xKA6qr4tdB4YDQCWwn3ASmU6UzczM28A9CBK9Jwp/pu8K/8cj2S3uxNXntuVlwgA5l2 mqiVtOOHohxcY+xuzwwW+aXgReXMu6/1MxMG5p58PbnDDQehm3gH84XF7F5Hwu58udsr 3rXuI/+MxtymXuOhGRBqRtXfO94La3FzT1VqZP7b57ezxmONaH3dgyUXvmQIIabtz/j9 CFUQ== X-Gm-Message-State: AOAM533v6wcLo/zaMW024QL9B1LT3Nwjg3BNlAsq0kTtFUwnbCZ6ma62 ufDCvwpPrOgtzJr0Itk4+z4= X-Google-Smtp-Source: ABdhPJyswca8Z6EvpzKtchFMaquA7fTSD1Ambul3SxVQ7HLBTPokSCBW25uIg7H0BQsHuSzEoh+A6Q== X-Received: by 2002:a50:934e:: with SMTP id n14mr24809333eda.88.1592241066054; Mon, 15 Jun 2020 10:11:06 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-234.amazon.com. [54.240.197.234]) by smtp.gmail.com with ESMTPSA id t9sm9472520ejy.43.2020.06.15.10.11.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 10:11:05 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Roger Pau Monne'" References: <24295.36070.945693.791220@mariner.uk.xensource.com> <20200615155646.GI735@Air-de-Roger> <24295.41945.883230.966002@mariner.uk.xensource.com> In-Reply-To: <24295.41945.883230.966002@mariner.uk.xensource.com> Subject: RE: [PATCH] libxl: tooling expects wrong errno Date: Mon, 15 Jun 2020 18:11:04 +0100 Message-ID: <003401d64337$f43c1990$dcb44cb0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJRrVmR5Atw2cuOlpDTe0mFV6HHUQIpYa7PAtS50FEBvgZ2vaetM+7Q X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Kevin Tian' , 'Wei Liu' , jakub@bartmin.ski, 'Andrew Cooper' , marmarek@invisiblethingslab.com, 'Grzegorz Uriasz' , 'Anthony Perard' , 'Jan Beulich' , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 15 June 2020 17:38 > To: Roger Pau Monne > Cc: Grzegorz Uriasz ; Jan Beulich ; Andrew Cooper > ; Kevin Tian ; Paul Durrant ; Wei Liu > ; jakub@bartmin.ski; marmarek@invisiblethingslab.com; j.nowak26@student.uw.edu.pl; Anthony > Perard ; xen-devel@lists.xenproject.org; contact@puzio.waw.pl > Subject: Re: [PATCH] libxl: tooling expects wrong errno > > Roger Pau Monne writes ("Re: [PATCH] libxl: tooling expects wrong errno"): > > On Mon, Jun 15, 2020 at 03:59:50PM +0100, Ian Jackson wrote: > > > Grzegorz Uriasz writes ("[PATCH] libxl: tooling expects wrong errno"): > > > > When iommu is not enabled for a given domain then pci passthrough > > > > hypercalls such as xc_test_assign_device return EOPNOTSUPP. > > > > The code responsible for this is in "iommu_do_domctl" inside > > > > xen/drivers/passthrough/iommu.c > > > > This patch fixes the error message reported by libxl when assigning > > > > pci devices to domains without iommu. > > > > > > > > Signed-off-by: Grzegorz Uriasz > > > > Tested-by: Grzegorz Uriasz > > > > --- > > > > tools/libxl/libxl_pci.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c > > > > index 957ff5c8e9..bc5843b137 100644 > > > > --- a/tools/libxl/libxl_pci.c > > > > +++ b/tools/libxl/libxl_pci.c > > > > @@ -1561,7 +1561,7 @@ void libxl__device_pci_add(libxl__egc *egc, uint32_t domid, > > > > LOGD(ERROR, domid, > > > > "PCI device %04x:%02x:%02x.%u %s?", > > > > pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func, > > > > - errno == ENOSYS ? "cannot be assigned - no IOMMU" > > > > + errno == EOPNOTSUPP ? "cannot be assigned - no IOMMU" > > > > : "already assigned to a different guest"); > > > > goto out; > > > > } > > > > > > Thanks. I have addressed some Xen IOMMU maintainers. Can you confirm > > > whether this is right ? > > > > Not an IOMMU maintainer myself, but I've taken a look at the code and > > I think Grzegorz is right. iommu_do_domctl will return -EOPNOTSUPP if > > the IOMMU is not enabled for the domain. Another option would be to > > check for EBUSY (which will certainly be returned when the device is > > busy) and log the error code with a message when it's different than > > EBUSY? > > > > There are many possible error here, for example the device itself > > might not be behind an IOMMU, in which case Xen will return -ENODEV at > > least on the Intel case. > > Thanks for the analysis. So: > > Acked-by: Ian Jackson > > This would seem to be a backport candidate. AFAICT check has been > there, looking for ENOSYS, since this code was introduced in > 826eb17271d3c647516d9944c47b0779afedea25 > libxl: suppress device assignment to HVM guest when there is no IOMMU > ? > > But that commit has a Tested-by. Maybe Xen changed its error return > at some point ? > Yes, it happened in 71e617a6b8f69849c70eda1b3c58f1ff6b244e5a use is_iommu_enabled() where appropriate... Paul > Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 17:18:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 17:18:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkskp-00022N-7p; Mon, 15 Jun 2020 17:18:39 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkskn-00021x-W9 for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 17:18:38 +0000 X-Inumbo-ID: 3c45986e-af2c-11ea-b81f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3c45986e-af2c-11ea-b81f-12813bfff9fa; Mon, 15 Jun 2020 17:18:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GPV+dLpexaNdiEns7BP73Nt6g7AHsjn5kPY63D/ayZo=; b=vuEFzXuR4LtiHTaPeMsKkq6u0 WHLFuX/VJn5OMyVOrIJTySun7Bzc/KqiiAM6G/MrnCsPuiR4gkJA8xhE+KLFJ/QFMgGFQt4A8oaql uEtzU2foHNaNyaLyF7BI7OegwdB2fZXKe7oD/u662r5EjUoNIwp+V6RBDKHZfUm3aaThI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkskg-0005wS-VF; Mon, 15 Jun 2020 17:18:31 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkskg-0003U2-MM; Mon, 15 Jun 2020 17:18:30 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkskg-00022G-L7; Mon, 15 Jun 2020 17:18:30 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151118: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=b91825f628c9a62cf2a3a0d972ea81484a8b7fce X-Osstest-Versions-That: xen=7028534d8482d25860c4d1aa8e45f0b911abfc5a From: osstest service owner Date: Mon, 15 Jun 2020 17:18:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151118 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151118/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-examine 4 memdisk-try-append fail in 151073 pass in 151118 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 151073 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151051 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151051 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151051 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151051 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151051 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151051 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151051 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151051 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151051 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce baseline version: xen 7028534d8482d25860c4d1aa8e45f0b911abfc5a Last test of basis 151051 2020-06-11 21:19:41 Z 3 days Testing same since 151073 2020-06-13 09:25:00 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper George Dunlap Jan Beulich Juergen Gross Paul Durrant Roger Pau Monne Roger Pau Monné jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : Everything up-to-date From xen-devel-bounces@lists.xenproject.org Mon Jun 15 17:39:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 17:39:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkt5E-0003i3-13; Mon, 15 Jun 2020 17:39:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkt5D-0003hx-4G for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 17:39:43 +0000 X-Inumbo-ID: 319d1e34-af2f-11ea-b823-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 319d1e34-af2f-11ea-b823-12813bfff9fa; Mon, 15 Jun 2020 17:39:42 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: LIxLEXBTV2Py4kYVPLwlph6n2kLbGFZEteyCwyNN9O8yAhLZX05mF3koPnpXXVTVQ9QToYHwQL aiK8Y/HrwR/F9GgUQWapTo50R8Qo2yTKDS8M4m1NPAsp+TsDWFhbP0N2LnbvhH3hbl0/3JmruW CEjVhy5g4L6c0Y7XkvpnqTzJnq1wJXB0qGAe+LxTV/cZmP4Vu4S1mfiBefrboiShDP9KOk8nQY 6imTynHUbUTmZeuE1FsPhTtu1GxRRlNKxgP6OjA/Db8yaY3VGKKIViHzH+zvdEFQt+VS319SXL hbg= X-SBRS: 2.7 X-MesageID: 20386887 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,515,1583211600"; d="scan'208";a="20386887" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24295.45650.388910.186169@mariner.uk.xensource.com> Date: Mon, 15 Jun 2020 18:39:30 +0100 To: "paul@xen.org" Subject: RE: [PATCH] libxl: tooling expects wrong errno In-Reply-To: <003401d64337$f43c1990$dcb44cb0$@xen.org> References: <24295.36070.945693.791220@mariner.uk.xensource.com> <20200615155646.GI735@Air-de-Roger> <24295.41945.883230.966002@mariner.uk.xensource.com> <003401d64337$f43c1990$dcb44cb0$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , 'Wei Liu' , "jakub@bartmin.ski" , Andrew Cooper , "marmarek@invisiblethingslab.com" , 'Grzegorz Uriasz' , Anthony Perard , 'Jan Beulich' , "j.nowak26@student.uw.edu.pl" , "xen-devel@lists.xenproject.org" , "contact@puzio.waw.pl" , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: [PATCH] libxl: tooling expects wrong errno"): > > -----Original Message----- > > From: Ian Jackson > > Thanks for the analysis. So: > > > > Acked-by: Ian Jackson > > > > This would seem to be a backport candidate. AFAICT check has been > > there, looking for ENOSYS, since this code was introduced in > > 826eb17271d3c647516d9944c47b0779afedea25 > > libxl: suppress device assignment to HVM guest when there is no IOMMU > > ? > > > > But that commit has a Tested-by. Maybe Xen changed its error return > > at some point ? > > > > Yes, it happened in 71e617a6b8f69849c70eda1b3c58f1ff6b244e5a > use is_iommu_enabled() where appropriate... So, Backport: 4.13 Thanks! Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 17:41:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 17:41:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkt6w-0004RS-Cp; Mon, 15 Jun 2020 17:41:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkt6u-0004RL-Ou for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 17:41:28 +0000 X-Inumbo-ID: 70c8de54-af2f-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 70c8de54-af2f-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 17:41:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a+BFCIoSr6YPVsQoz+Hh3MsFmyP7pv41qMOLHVGlXck=; b=NHR3g8ljom90rmOPqVQ9FCc1q PqZGTepTNFbcr9t8mm0RwYoLKawzrvnqjhlkUAN1Ul36sWSH/s/asc3QTtT1O9eg620SW/Gnvj6zL AmY4CPb0g4cBFuxuS3q/QDC8U6R7pLcCPMWIcUeM6Qzy3OGKZAKC4XvV+ewbmuTGJArh4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkt6t-0006M5-Gu; Mon, 15 Jun 2020 17:41:27 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkt6t-0004rs-6K; Mon, 15 Jun 2020 17:41:27 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkt6t-0003KO-5Y; Mon, 15 Jun 2020 17:41:27 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151152: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=fec6a7af5c5760b9bccd9e7c3eaf29f0401af264 X-Osstest-Versions-That: xen=b91825f628c9a62cf2a3a0d972ea81484a8b7fce From: osstest service owner Date: Mon, 15 Jun 2020 17:41:27 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151152 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151152/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen fec6a7af5c5760b9bccd9e7c3eaf29f0401af264 baseline version: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce Last test of basis 151063 2020-06-12 16:00:34 Z 3 days Testing same since 151152 2020-06-15 15:01:14 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: George Dunlap Ian Jackson Nick Rosbrook Nick Rosbrook jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git b91825f628..fec6a7af5c fec6a7af5c5760b9bccd9e7c3eaf29f0401af264 -> smoke From xen-devel-bounces@lists.xenproject.org Mon Jun 15 18:05:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 18:05:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jktUD-0006GI-91; Mon, 15 Jun 2020 18:05:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jktUB-0006GD-3t for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 18:05:31 +0000 X-Inumbo-ID: c9d40228-af32-11ea-bb8b-bc764e2007e4 Received: from forwardcorp1p.mail.yandex.net (unknown [2a02:6b8:0:1472:2741:0:8b6:217]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c9d40228-af32-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 18:05:26 +0000 (UTC) Received: from mxbackcorp1o.mail.yandex.net (mxbackcorp1o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::301]) by forwardcorp1p.mail.yandex.net (Yandex) with ESMTP id C5F052E15A6; Mon, 15 Jun 2020 21:05:24 +0300 (MSK) Received: from sas2-32987e004045.qloud-c.yandex.net (sas2-32987e004045.qloud-c.yandex.net [2a02:6b8:c08:b889:0:640:3298:7e00]) by mxbackcorp1o.mail.yandex.net (mxbackcorp/Yandex) with ESMTP id 8QHNbBaHmb-5Ka82GjA; Mon, 15 Jun 2020 21:05:24 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1592244324; bh=xm8NBmAShTjxBdIzgaGbM6kRTaHHnu7nJyv1yfP8QzY=; h=In-Reply-To:Message-ID:Subject:To:From:References:Date:Cc; b=BHcdKOqAaezM8nX/rmBd0yekLRkAj+47CQsQxYB0wqLsWLGkthbXhHfsARxR2sj0P 4nmSEqFRZUyPh1sXc4UB/1o3rFb1JpzDf5rrfikhWJZmUa9K0eMwSFmsJWKzsMz6gb /wgUm7AR4BKH362TaEutyxPN/vyz4svjz5Wb1I5k= Authentication-Results: mxbackcorp1o.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from dynamic-vpn.dhcp.yndx.net (dynamic-vpn.dhcp.yndx.net [2a02:6b8:b080:7317::1:4]) by sas2-32987e004045.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id JsFWVHDsbr-5JlqCpJO; Mon, 15 Jun 2020 21:05:20 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Date: Mon, 15 Jun 2020 21:05:18 +0300 From: Roman Kagan To: qemu-devel@nongnu.org Subject: Re: [PATCH v8 0/8] block: enhance handling of size-related BlockConf properties Message-ID: <20200615180518.GA4032@rvkaganb.lan> Mail-Followup-To: Roman Kagan , qemu-devel@nongnu.org, Fam Zheng , Kevin Wolf , Stefano Stabellini , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Eduardo Habkost , qemu-block@nongnu.org, Paul Durrant , John Snow , "Michael S. Tsirkin" , Laurent Vivier , Max Reitz , Keith Busch , Gerd Hoffmann , Stefan Hajnoczi , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= References: <20200528225516.1676602-1-rvkagan@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200528225516.1676602-1-rvkagan@yandex-team.ru> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Fam Zheng , Kevin Wolf , Stefano Stabellini , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Eduardo Habkost , qemu-block@nongnu.org, Paul Durrant , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , "Michael S. Tsirkin" , Laurent Vivier , Max Reitz , Anthony Perard , Gerd Hoffmann , Stefan Hajnoczi , xen-devel@lists.xenproject.org, Keith Busch , Paolo Bonzini , John Snow Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, May 29, 2020 at 01:55:08AM +0300, Roman Kagan wrote: > BlockConf includes several properties counted in bytes. > > Enhance their handling in some aspects, specifically > > - accept common size suffixes (k, m) > - perform consistency checks on the values > - lift the upper limit on physical_block_size and logical_block_size > > Also fix the accessor for opt_io_size in virtio-blk to make it consistent with > the size of the field. > > History: > v7 -> v8: > - replace stringify with %u in error messages [Eric] > - fix wording in logs [Eric] > > v6 -> v7: > - avoid overflow in min_io_size check [Eric] > - try again to perform the art form in patch splitting [Eric] > > v5 -> v6: > - fix forgotten xen-block and swim > - add prop_size32 instead of going with 64bit > > v4 -> v5: > - re-split the patches [Philippe] > - fix/reword error messages [Philippe, Kevin] > - do early return on failed consistency check [Philippe] > - use QEMU_IS_ALIGNED instead of open coding [Philippe] > - make all BlockConf size props support suffixes > - expand the log for virtio-blk opt_io_size [Michael] > > v3 -> v4: > - add patch to fix opt_io_size width in virtio-blk > - add patch to perform consistency checks [Kevin] > - check min_io_size against truncation [Kevin] > > v2 -> v3: > - mention qcow2 cluster size limit in the log and comment [Eric] > > v1 -> v2: > - cap the property at 2 MiB [Eric] > - accept size suffixes > > Roman Kagan (8): > virtio-blk: store opt_io_size with correct size > block: consolidate blocksize properties consistency checks > qdev-properties: blocksize: use same limits in code and description > qdev-properties: add size32 property type > qdev-properties: make blocksize accept size suffixes > block: make BlockConf size props 32bit and accept size suffixes > qdev-properties: add getter for size32 and blocksize > block: lift blocksize property limit to 2 MiB > > include/hw/block/block.h | 14 +- > include/hw/qdev-properties.h | 5 +- > hw/block/block.c | 40 ++- > hw/block/fdc.c | 5 +- > hw/block/nvme.c | 5 +- > hw/block/swim.c | 5 +- > hw/block/virtio-blk.c | 9 +- > hw/block/xen-block.c | 6 +- > hw/core/qdev-properties.c | 85 +++++- > hw/ide/qdev.c | 5 +- > hw/scsi/scsi-disk.c | 12 +- > hw/usb/dev-storage.c | 5 +- > tests/qemu-iotests/172.out | 532 +++++++++++++++++------------------ > 13 files changed, 419 insertions(+), 309 deletions(-) Ping? From xen-devel-bounces@lists.xenproject.org Mon Jun 15 19:14:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 19:14:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkuYv-0003Q9-Cn; Mon, 15 Jun 2020 19:14:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkuYu-0003Q4-Rw for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 19:14:28 +0000 X-Inumbo-ID: 6e60ee24-af3c-11ea-bb8b-bc764e2007e4 Received: from mail-ed1-x544.google.com (unknown [2a00:1450:4864:20::544]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6e60ee24-af3c-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 19:14:27 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id t21so12329431edr.12 for ; Mon, 15 Jun 2020 12:14:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tROvkrjLc9wHL2NHb6pbuOEf92Mjj7qEKcDXhQREEzo=; b=FPf+SZgnBdXkL7xsPfvJd6pSnWUwfgVmITDTr8bV4NLyNFcbfXMq8L81avvnCYy1gr Jrd/wrvyo41gkjzEFDsMGkFKFbp3tqjWLpWMgpTtudfGWxuESRj+Ga1jPueVsLlzei5K bbpjZ5V4MGxpvzJLux7xEBCR2VVPmau6dof1MrEs+4m1OhzBsOFtcXWSA52HiuQAcwpU BS+iqPpcWGPwyoZwGcIODzKdly5a3HmWa+IjIfrk41x6/omKZYQ+9zWcIsSv3Md6IgJw oR0SrCtPv2oiLnoF4xWOoaqbcKKhTqzh/HPVleDqgjR4Q39UBlptrsBMBofel3JRGPI0 DR/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tROvkrjLc9wHL2NHb6pbuOEf92Mjj7qEKcDXhQREEzo=; b=WUQMqW+ZNaA6hQxyfe/WLTr5BCHQS/o1MrOz6+Sj1hxKeAXYvbgbINJ2pXci/ijDif GxC7f+qAnJrPlCbryUWEHXBF73iGM63bfsiojZjVl4EQO1R7qtViz8oi0Tn8WrmecZlh 0GDgmpMxgVWY4Qsv2Rv3vIsQbjOnI3ekCl1IyK6UkKAkhCMgdq/AfRQvDFgnani+HP84 SuuErkuqhmFQBgR8oG3GQdz4PT6jL7WkCCi7tVjzIJ6YBG/4mTBc0Rk1lishOcv86nr9 lzGk/aPLPp+n7Hs51UTjc1XS06iFPNVXFLulJ6q0wg/sJVqRIIxFwqdARm0ttmbWFC2T +8jQ== X-Gm-Message-State: AOAM532P+6USZ2IxqU9UfwvHsCnHDrv3tOFjBA+8GJwPHJxNvxRDfVpT +/O6kLjm4n67uZlSxYHQnxavyIaqk4oGLWhJ5i8= X-Google-Smtp-Source: ABdhPJxQDbQDCl+YK9nOGLMGUCfWD2J/F3oaisbG5jgMI5i6CGhuy0eYWnxDU2frw1hL49Mf8KQNThPZTZ4Rqum7xU8= X-Received: by 2002:a05:6402:1d96:: with SMTP id dk22mr25867754edb.258.1592248466965; Mon, 15 Jun 2020 12:14:26 -0700 (PDT) MIME-Version: 1.0 References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> In-Reply-To: From: CodeWiz2280 Date: Mon, 15 Jun 2020 15:14:10 -0400 Message-ID: Subject: Re: Keystone Issue To: Julien Grall Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , nd , Stefano Stabellini , xen-devel , Bertrand Marquis Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 10, 2020 at 5:46 PM Julien Grall wrote: > > Hi Marc, > > On Tue, 9 Jun 2020 at 18:45, Marc Zyngier wrote: > > > I was wondering if you heard about any potential issue with guest EOI > > > not forwarded to the host. This is on TI Keystone (Cortex A-15). > > > > Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway > > all run just fine with guest EOI), and GIC-400 is a pretty solid piece > > of kit (it is just sloooooow...). > > > > Thinking of it, you would see something like that if the GIC was seeing > > the writes coming from the guest as secure instead of NS (cue the early > > firmware on XGene that exposed the wrong side of GIC-400). > > Ah, I remember that one. We used to carry an hack in Xen [1] for > X-Gene. Thankfully they fixed the firmware! > > If it is a similar issue, then the firmware path would definitely be > my preference. > > Thank you for the input! Thank you all for the information. If I pull the changes to use the maintenance interrupt for the X-Gene back into the latest build of Xen then my issue with the Edge and Level interrupts is resolved. My ethernet and other devices work fine again for the Keystone in dom0. Are there any concerns over operating this way, meaning with the maintenance interrupt workaround rather than the EOI? Is this safe? Also, the latest linux kernel still has the X-Gene storm distributor address as "0x78010000" in the device tree, which is what the Xen code considers a match with the old firmware. What were the addresses for the device tree supposed to be changed to? Is my understanding correct that there is a different base address required to access the "non-secure" region instead of the "secure" 0x78010000 region? I'm trying to see if there are corresponding different addresses for the keystone K2E, but haven't found them yet in the manuals. > > Cheers, > > [1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=50dcb3de603927db2fd87ba09e29c817415aaa44 From xen-devel-bounces@lists.xenproject.org Mon Jun 15 19:28:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 19:28:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkumZ-0004LZ-Ly; Mon, 15 Jun 2020 19:28:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkumY-0004LU-2N for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 19:28:34 +0000 X-Inumbo-ID: 66374566-af3e-11ea-b7bb-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 66374566-af3e-11ea-b7bb-bc764e2007e4; Mon, 15 Jun 2020 19:28:33 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id p20so18662102ejd.13 for ; Mon, 15 Jun 2020 12:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LStajdU5A97rbmxSqmjdia4JbDB3BVApLrPOJJzsEJ4=; b=v7Fwr4DxgQenRnlVbcXFIcivtrjqEgCljBqBdQ0lzIV3iGU9Z/7hec54kJu6qq4uU0 WEqn5yVnDx3d3/YUNTOsVD72kil5oO5TjfXbE6QL6J5tDoHiXZ7wEWvMBMsDc3zWT83Y n8nMPuGLR61bAzXdfTsuJUHlGiPR2MOHZaIAMfg5jkXECDvR5ySw+qV967z9sb0vY9lu i2Y2mucHNLGOVWTkQUSDGTyRwMfuZZnPVLU/Go3PtkzMaeddheQTxB6QwDELVy5uDpgy sCcP/gFBVlR1ld9QoHFIgvU52GKv/+rZ0P2XmAXqc2rZ/DOj5JbNNgsG0plXteeA2ktZ BLhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LStajdU5A97rbmxSqmjdia4JbDB3BVApLrPOJJzsEJ4=; b=fyCPnnLqmeYHQBfGDvCT7K5XDbSZtAj3xPIaENJ6quMnlR4uhcI4nLZ+QJPJsuHjjI 5fgnbapem4KxVsCWqUo9Nz3AWrYuYD/pI3JT/KKIHDNPBz4J8/wom0e785wKH7qPLmv1 vTmFyzRmtHv0qSz4ct+jjUI3i3C7SC1r/AuuFITIrQP9b1lo3MNF440YtQcalwNJFYbo Cgn5xfFLXVk7grbFdemkmDrSzkWOncnUIRo75toxVfO9twW1+G76p+VxGbcWMKTV19Ds 513iXHcGWynC2M98wdN/EGdR9V1aKwC9z0bYRxcV081MLIWcyBYXk2TpsiLBQ8vlkmM+ wzqw== X-Gm-Message-State: AOAM533e6VmHs9JF8XYlJ+fHmdCZOzsfi11YBXTjJ6Cfo4RnJOfWsDhk Va1oDYHVoyt+HnG88VDHXNABcziG/yE= X-Google-Smtp-Source: ABdhPJyiukRpCUdQmWi6CqZlbmW+OTsG11swd4UJu/ApUCzDRImEpGiE3Y34PDbqZiTQDimChKVEFQ== X-Received: by 2002:a17:906:f53:: with SMTP id h19mr12403945ejj.491.1592249311477; Mon, 15 Jun 2020 12:28:31 -0700 (PDT) Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com. [209.85.128.52]) by smtp.gmail.com with ESMTPSA id dm1sm9558735ejc.99.2020.06.15.12.28.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 12:28:30 -0700 (PDT) Received: by mail-wm1-f52.google.com with SMTP id g10so679573wmh.4 for ; Mon, 15 Jun 2020 12:28:29 -0700 (PDT) X-Received: by 2002:a1c:964d:: with SMTP id y74mr897479wmd.154.1592249309494; Mon, 15 Jun 2020 12:28:29 -0700 (PDT) MIME-Version: 1.0 References: <000c01d63826$6d125900$47370b00$@xen.org> <4017F2B3-BB9B-4E9F-813C-6FE68BA0D568@citrix.com> <002401d638b0$a5460f80$efd22e80$@xen.org> In-Reply-To: From: Tamas K Lengyel Date: Mon, 15 Jun 2020 13:27:54 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v19 for-4.14 00/13] VM forking To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Kevin Tian , Stefano Stabellini , Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , George Dunlap , Jun Nakajima , Ian Jackson , Anthony Perard , xen-devel , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 2, 2020 at 3:39 AM Jan Beulich wrote: > > On 02.06.2020 09:37, Paul Durrant wrote: > > Maintainers/committers, can we please get those patches in a.s.a.p.? > > The sole reason I didn't put in at least the 1st patch on Friday > (perhaps also the 2nd, as it is suitably ack-ed) was that it's > still missing a VMX maintainer ack, and Kevin had provided > comments on v2 of the smaller (2-patch) series. Can we get the first patches from this series merged now with Kevin's Reviewed-by he sent last week (https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00732.html)? Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Mon Jun 15 20:19:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 20:19:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkvZ8-0008QS-Kw; Mon, 15 Jun 2020 20:18:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkvZ7-0008Q6-3q for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 20:18:45 +0000 X-Inumbo-ID: 652b7173-af45-11ea-b83c-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 652b7173-af45-11ea-b83c-12813bfff9fa; Mon, 15 Jun 2020 20:18:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=u08XOvrZgx2f7JTaQjZ4AgQLrCa7wv9x+QdqQN39F/g=; b=Mn9cv+B5XkNgAG5vELqE6gGbV 5p+Rpk4aQDUQnj3YhywViAE6HQh+fOUSa7ZII3imJA2SjPmXXHirx1EV5iwflOl0OiYdHKYqwk9gF 4vMdZaMBTNW1qnLcW4U98h77+84vd/1FkptSH8SJQnShdBlisOVKMwSrHzkPafBKJaX7s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkvZ0-0000v3-Co; Mon, 15 Jun 2020 20:18:38 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkvYz-0007qX-UX; Mon, 15 Jun 2020 20:18:38 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkvYz-0005us-U3; Mon, 15 Jun 2020 20:18:37 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151159: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=1251402caf8685f45d9d580f01583370f7e2d272 X-Osstest-Versions-That: xen=fec6a7af5c5760b9bccd9e7c3eaf29f0401af264 From: osstest service owner Date: Mon, 15 Jun 2020 20:18:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151159 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151159/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 1251402caf8685f45d9d580f01583370f7e2d272 baseline version: xen fec6a7af5c5760b9bccd9e7c3eaf29f0401af264 Last test of basis 151152 2020-06-15 15:01:14 Z 0 days Testing same since 151159 2020-06-15 18:00:41 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: George Dunlap Ian Jackson Nick Rosbrook Nick Rosbrook jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git fec6a7af5c..1251402caf 1251402caf8685f45d9d580f01583370f7e2d272 -> smoke From xen-devel-bounces@lists.xenproject.org Mon Jun 15 20:31:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 20:31:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkvkr-0001Yy-MZ; Mon, 15 Jun 2020 20:30:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkvkq-0001Yt-5q for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 20:30:52 +0000 X-Inumbo-ID: 1a6c8c1e-af47-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1a6c8c1e-af47-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 20:30:51 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1E6E92071A; Mon, 15 Jun 2020 20:30:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592253050; bh=B8BcKnLFlX2Qxrnl55jdc/FDpiUylFO4osEaNFhVlzY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TBf64I58PX0wtOg9XDIcmVMB9EZo0hUp1AnGAcnLU/IB8TFqInN0jcIYar03Jzn04 j3KbiVBZ7kKX/XjYz8DaCLJCsMLASF04jMePO191ptIJuoswOHBssGaVfio05dgBTm NykfCoq5GOC64ZGqjdx5INwKG8ZHQa1Imu4y/ScI= Date: Mon, 15 Jun 2020 13:30:49 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Bertrand Marquis Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall In-Reply-To: <0D644096-05E3-44F3-A1FD-75006C718F23@arm.com> Message-ID: References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> <48F66B8F-3AEF-4E54-A572-C246F5A7C117@arm.com> <0D644096-05E3-44F3-A1FD-75006C718F23@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1291058156-1592253050=:9074" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1291058156-1592253050=:9074 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 15 Jun 2020, Bertrand Marquis wrote: > > On 13 Jun 2020, at 01:24, Stefano Stabellini wrote: > > > > On Fri, 12 Jun 2020, Bertrand Marquis wrote: > >>> On 12 Jun 2020, at 02:09, Stefano Stabellini wrote: > >>> > >>> On Thu, 11 Jun 2020, Julien Grall wrote: > >>>> Hi Stefano, > >>>> > >>>> On 11/06/2020 19:50, Stefano Stabellini wrote: > >>>>> On Thu, 11 Jun 2020, Julien Grall wrote: > >>>>>>>> + return -EINVAL; > >>>>>>>> } > >>>>>>>> > >>>>>>>> - __copy_to_guest(runstate_guest(v), &runstate, 1); > >>>>>>>> + v->arch.runstate_guest.page = page; > >>>>>>>> + v->arch.runstate_guest.offset = offset; > >>>>>>>> + > >>>>>>>> + spin_unlock(&v->arch.runstate_guest.lock); > >>>>>>>> + > >>>>>>>> + return 0; > >>>>>>>> +} > >>>>>>>> + > >>>>>>>> + > >>>>>>>> +/* Update per-VCPU guest runstate shared memory area (if registered). > >>>>>>>> */ > >>>>>>>> +static void update_runstate_area(struct vcpu *v) > >>>>>>>> +{ > >>>>>>>> + struct vcpu_runstate_info *guest_runstate; > >>>>>>>> + void *p; > >>>>>>>> + > >>>>>>>> + spin_lock(&v->arch.runstate_guest.lock); > >>>>>>>> > >>>>>>>> - if ( guest_handle ) > >>>>>>>> + if ( v->arch.runstate_guest.page ) > >>>>>>>> { > >>>>>>>> - runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE; > >>>>>>>> + p = __map_domain_page(v->arch.runstate_guest.page); > >>>>>>>> + guest_runstate = p + v->arch.runstate_guest.offset; > >>>>>>>> + > >>>>>>>> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > >>>>>>>> + { > >>>>>>>> + v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE; > >>>>>>>> + guest_runstate->state_entry_time |= XEN_RUNSTATE_UPDATE; > >>>>>>> > >>>>>>> I think that this write to guest_runstate should use write_atomic or > >>>>>>> another atomic write operation. > >>>>>> > >>>>>> I thought about suggesting the same, but guest_copy_* helpers may not > >>>>>> do a single memory write to state_entry_time. > >>>>>> What are you trying to prevent with the write_atomic()? > >>>>> > >>>>> I am thinking that without using an atomic write, it would be (at least > >>>>> theoretically) possible for a guest to see a partial write to > >>>>> state_entry_time, which is not good. > >>>> > >>>> It is already the case with existing implementation as Xen may write byte by > >>>> byte. So are you suggesting the existing code is also buggy? > >>> > >>> Writing byte by byte is a different case. That is OK. In that case, the > >>> guest could see the state after 3 bytes written and it would be fine and > >>> consistent. If this hadn't been the case, then yes, the existing code > >>> would also be buggy. > >>> > >>> So if we did the write with a memcpy, it would be fine, no need for > >>> atomics: > >>> > >>> memcpy(&guest_runstate->state_entry_time, > >>> &v->runstate.state_entry_time, > >>> XXX); > >>> > >>> > >>> The |= case is different: GCC could implement it in any way it likes, > >>> including going through a zero-write to any of the bytes in the word, or > >>> doing an addition then a subtraction. GCC doesn't make any guarantees. > >>> If we want guarantees we need to use atomics. > >> > >> Wouldn’t that require all accesses to state_entry_time to use also atomic operations ? > >> In this case we could not propagate the changes to a guest without changing the interface itself. > >> > >> As the copy time needs to be protected, the write barriers are there to make sure that during the copy the bit is set and that when we unset it, the copy is done. > >> I added for this purpose a barrier after the memcpy to make sure that when/if we unset the bit the copy has already been done. > > > > As you say, we have a flag to mark a transitiong period, the flag is > > XEN_RUNSTATE_UPDATE. So, I think it is OK if we don't use atomics during > > the transitioning period. But we need to make sure to use atomics for the > > update of the XEN_RUNSTATE_UPDATE flag itself. > > > > Does it make sense? Or maybe I misunderstood some of the things you > > wrote? > > To achieve this you would do an atomic operation on state_entry_time to set/unset the XEN_RUNSTATE_UPDATE bit. > This field is holding a flag in the upper bit but also a value, so all operations on state_entry_time would need to be changed to use atomic operations. I don't think that all operations on state_entry_time need to be atomic. Only the bit write to XEN_RUNSTATE_UPDATE. More on this below. > Also this state_entry_time might also be accessed by the guest on other cores at the same time (to retrieve the time part). Yes but they are all just readers, right? > To prevent something being used as atomic and non atomic, specific types are usually used (atomic_t) and this structure is also used by guests so modifying it will not be easy. > > Or did I missunderstood something here ? I was not suggesting to use an atomic_t type. I was only suggesting to use an atomic operation, i.e. calling write_u32_atomic directly (or something like that.) I would not change the type of state_entry_time. Also using memcpy would be acceptable due to the fact that we only need to update one byte. --8323329-1291058156-1592253050=:9074-- From xen-devel-bounces@lists.xenproject.org Mon Jun 15 20:44:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 20:44:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkvxw-0002Uy-Tz; Mon, 15 Jun 2020 20:44:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkvxv-0002Ut-Jk for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 20:44:23 +0000 X-Inumbo-ID: fdf8715e-af48-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fdf8715e-af48-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 20:44:22 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id y17so18487063wrn.11 for ; Mon, 15 Jun 2020 13:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Bgs8LxkfaewmQhhiyMdkzV4z6XrQZitYOZ1aJydvzxk=; b=cXgt5bP2xSMC5+4kBz9FEnZVa87utxu21vLLthqsvpVewBP2+PtvsxYraOAijver2K oSjFH5uDbOXsqYc5QUWU5LyuAHF0OoSmonLoBIxg8NomHUkY0faRFd17E4GqHG/UQfcd brqX7q8xlkzoB63yABeW3PGsxUSmsVjAfsH74GaILGyPSKFR5dVDclzFJXnG4vu3j/FE of1xWPJSeaE+x1z2PCyW5mmw9wVyHi5B39kybwsZPphAGi7FdqFmtcBnAszkJzb1rjFb fnkwm/k0YtTopYqQz2g13hITasKv7kEBnQyXs9xi2QJBInzO3UfaPE2s6TS3mPTcWQa7 Wd6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Bgs8LxkfaewmQhhiyMdkzV4z6XrQZitYOZ1aJydvzxk=; b=KZsvGmlw6nlk9Fd2lJDL106Ct8V29cZHxAUxqR4sMhHL0c9jZZ+t5vhSmDTF7yHp5a 8GWPrP5fW+2PwBKreKxjdVakLOvJR4cjOgFK9jBFNBEmKEbmY4EQr0MoyznUsCY5SPEr KHhl4bSqopOey/RN/bJr+Z0Y1dOQrH7OYwcM68y5AR+0p2JtdI5Vp9vPqvYjdLmaOm8K 3k6Xm0/U4diycFEQ+OQr3CVhAEQ17kEuHKNfIMzQA6qND3BSdo1OH9AvQjXaaE+6vHEv W5D/AoUjJE4JoNda3xLx8+eQNnvJFhotm9cXyuG/WkFp85k8V/cT6JpzjPzVa/kbkjPU f63w== X-Gm-Message-State: AOAM531/ip7tJWl2ONa9Ol0VHmA0Yi9vRikgRXEgxSO2LiuTxVNu9ckp nFx6j3te2Dr6hxuyKW5daWbpVe+oUlA0BA44Kgo= X-Google-Smtp-Source: ABdhPJzA5i7TDgHqPckirQbDCiAByZc7cWVSO6aLPvVFIHz6BBps5YgkeK9nHZ24j3XFbd0nhmXwnRIGMcBySkBmwa4= X-Received: by 2002:a5d:4ec3:: with SMTP id s3mr32732699wrv.103.1592253861661; Mon, 15 Jun 2020 13:44:21 -0700 (PDT) MIME-Version: 1.0 References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> <48F66B8F-3AEF-4E54-A572-C246F5A7C117@arm.com> <0D644096-05E3-44F3-A1FD-75006C718F23@arm.com> In-Reply-To: From: Julien Grall Date: Mon, 15 Jun 2020 21:44:09 +0100 Message-ID: Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Bertrand Marquis , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 15 Jun 2020 at 21:30, Stefano Stabellini w= rote: > > On Mon, 15 Jun 2020, Bertrand Marquis wrote: > > > On 13 Jun 2020, at 01:24, Stefano Stabellini = wrote: > > > > > > On Fri, 12 Jun 2020, Bertrand Marquis wrote: > > >>> On 12 Jun 2020, at 02:09, Stefano Stabellini wrote: > > >>> > > >>> On Thu, 11 Jun 2020, Julien Grall wrote: > > >>>> Hi Stefano, > > >>>> > > >>>> On 11/06/2020 19:50, Stefano Stabellini wrote: > > >>>>> On Thu, 11 Jun 2020, Julien Grall wrote: > > >>>>>>>> + return -EINVAL; > > >>>>>>>> } > > >>>>>>>> > > >>>>>>>> - __copy_to_guest(runstate_guest(v), &runstate, 1); > > >>>>>>>> + v->arch.runstate_guest.page =3D page; > > >>>>>>>> + v->arch.runstate_guest.offset =3D offset; > > >>>>>>>> + > > >>>>>>>> + spin_unlock(&v->arch.runstate_guest.lock); > > >>>>>>>> + > > >>>>>>>> + return 0; > > >>>>>>>> +} > > >>>>>>>> + > > >>>>>>>> + > > >>>>>>>> +/* Update per-VCPU guest runstate shared memory area (if regi= stered). > > >>>>>>>> */ > > >>>>>>>> +static void update_runstate_area(struct vcpu *v) > > >>>>>>>> +{ > > >>>>>>>> + struct vcpu_runstate_info *guest_runstate; > > >>>>>>>> + void *p; > > >>>>>>>> + > > >>>>>>>> + spin_lock(&v->arch.runstate_guest.lock); > > >>>>>>>> > > >>>>>>>> - if ( guest_handle ) > > >>>>>>>> + if ( v->arch.runstate_guest.page ) > > >>>>>>>> { > > >>>>>>>> - runstate.state_entry_time &=3D ~XEN_RUNSTATE_UPDATE; > > >>>>>>>> + p =3D __map_domain_page(v->arch.runstate_guest.page); > > >>>>>>>> + guest_runstate =3D p + v->arch.runstate_guest.offset; > > >>>>>>>> + > > >>>>>>>> + if ( VM_ASSIST(v->domain, runstate_update_flag) ) > > >>>>>>>> + { > > >>>>>>>> + v->runstate.state_entry_time |=3D XEN_RUNSTATE_UP= DATE; > > >>>>>>>> + guest_runstate->state_entry_time |=3D XEN_RUNSTAT= E_UPDATE; > > >>>>>>> > > >>>>>>> I think that this write to guest_runstate should use write_atom= ic or > > >>>>>>> another atomic write operation. > > >>>>>> > > >>>>>> I thought about suggesting the same, but guest_copy_* helpers m= ay not > > >>>>>> do a single memory write to state_entry_time. > > >>>>>> What are you trying to prevent with the write_atomic()? > > >>>>> > > >>>>> I am thinking that without using an atomic write, it would be (at= least > > >>>>> theoretically) possible for a guest to see a partial write to > > >>>>> state_entry_time, which is not good. > > >>>> > > >>>> It is already the case with existing implementation as Xen may wri= te byte by > > >>>> byte. So are you suggesting the existing code is also buggy? > > >>> > > >>> Writing byte by byte is a different case. That is OK. In that case,= the > > >>> guest could see the state after 3 bytes written and it would be fin= e and > > >>> consistent. If this hadn't been the case, then yes, the existing co= de > > >>> would also be buggy. > > >>> > > >>> So if we did the write with a memcpy, it would be fine, no need for > > >>> atomics: > > >>> > > >>> memcpy(&guest_runstate->state_entry_time, > > >>> &v->runstate.state_entry_time, > > >>> XXX); > > >>> > > >>> > > >>> The |=3D case is different: GCC could implement it in any way it li= kes, > > >>> including going through a zero-write to any of the bytes in the wor= d, or > > >>> doing an addition then a subtraction. GCC doesn't make any guarante= es. > > >>> If we want guarantees we need to use atomics. > > >> > > >> Wouldn=E2=80=99t that require all accesses to state_entry_time to us= e also atomic operations ? > > >> In this case we could not propagate the changes to a guest without c= hanging the interface itself. > > >> > > >> As the copy time needs to be protected, the write barriers are there= to make sure that during the copy the bit is set and that when we unset it= , the copy is done. > > >> I added for this purpose a barrier after the memcpy to make sure tha= t when/if we unset the bit the copy has already been done. > > > > > > As you say, we have a flag to mark a transitiong period, the flag is > > > XEN_RUNSTATE_UPDATE. So, I think it is OK if we don't use atomics dur= ing > > > the transitioning period. But we need to make sure to use atomics for= the > > > update of the XEN_RUNSTATE_UPDATE flag itself. > > > > > > Does it make sense? Or maybe I misunderstood some of the things you > > > wrote? > > > > To achieve this you would do an atomic operation on state_entry_time to= set/unset the XEN_RUNSTATE_UPDATE bit. > > This field is holding a flag in the upper bit but also a value, so all = operations on state_entry_time would need to be changed to use atomic opera= tions. > > I don't think that all operations on state_entry_time need to be atomic. > Only the bit write to XEN_RUNSTATE_UPDATE. More on this below. > > > > Also this state_entry_time might also be accessed by the guest on other= cores at the same time (to retrieve the time part). > > Yes but they are all just readers, right? This is only one part of the equation. The second part is the readers *must not* process the rest of the content while XEN_RUNSTATE_UDPATE is set. > > I was not suggesting to use an atomic_t type. I was only suggesting to > use an atomic operation, i.e. calling write_u32_atomic directly (or > something like that.) I would not change the type of state_entry_time. > Also using memcpy would be acceptable due to the fact that we only need > to update one byte. Please don't use memcpy. This is an abuse to think it can make atomic copy (even if it may be correct for byte). At the same time, lets avoid to introduce more atomic bit operation on guest memory that can be read-write (see XSA-295). In this case a write_atomic() is sufficient as it would do a single write for size smaller than 64-bit. Cheers, From xen-devel-bounces@lists.xenproject.org Mon Jun 15 21:33:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 21:33:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkwif-0006UQ-RX; Mon, 15 Jun 2020 21:32:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkwie-0006UJ-HP for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 21:32:40 +0000 X-Inumbo-ID: bcd0b310-af4f-11ea-bca7-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bcd0b310-af4f-11ea-bca7-bc764e2007e4; Mon, 15 Jun 2020 21:32:39 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id ABDAD20707; Mon, 15 Jun 2020 21:32:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592256759; bh=3peKaglNXSF71RHEwcxQB7QP4tsh16uS7MBiWTN7rpg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=pQDxLtj3AoT9jboufTX67dYFrwDykHBll54Ktts67hqK4QaE6HPHrza5FH8Nrh94P I9KwDaLETmRkni6jzpsf8oOzQf6iBUWoycdBPwoRioK5ou/MhbMQUOmACd469NJe2C 6yhJ2Fq3b8h78Jqy/ZYs+DpZFihD02upG4RnlqMs= Date: Mon, 15 Jun 2020 14:32:38 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: CodeWiz2280 Subject: Re: Keystone Issue In-Reply-To: Message-ID: References: <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Marc Zyngier , Bertrand Marquis , xen-devel , nd , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 15 Jun 2020, CodeWiz2280 wrote: > On Wed, Jun 10, 2020 at 5:46 PM Julien Grall wrote: > > > > Hi Marc, > > > > On Tue, 9 Jun 2020 at 18:45, Marc Zyngier wrote: > > > > I was wondering if you heard about any potential issue with guest EOI > > > > not forwarded to the host. This is on TI Keystone (Cortex A-15). > > > > > > Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway > > > all run just fine with guest EOI), and GIC-400 is a pretty solid piece > > > of kit (it is just sloooooow...). > > > > > > Thinking of it, you would see something like that if the GIC was seeing > > > the writes coming from the guest as secure instead of NS (cue the early > > > firmware on XGene that exposed the wrong side of GIC-400). > > > > Ah, I remember that one. We used to carry an hack in Xen [1] for > > X-Gene. Thankfully they fixed the firmware! > > > > If it is a similar issue, then the firmware path would definitely be > > my preference. > > > > Thank you for the input! > > Thank you all for the information. If I pull the changes to use the > maintenance interrupt for the X-Gene back into the latest build of Xen > then my issue with the Edge and Level interrupts is resolved. My > ethernet and other devices work fine again for the Keystone in dom0. > Are there any concerns over operating this way, meaning with the > maintenance interrupt workaround rather than the EOI? Is this safe? It should be fine, a small impact on performance, that's all. > Also, the latest linux kernel still has the X-Gene storm distributor > address as "0x78010000" in the device tree, which is what the Xen code > considers a match with the old firmware. What were the addresses for > the device tree supposed to be changed to? Is my understanding > correct that there is a different base address required to access the > "non-secure" region instead of the "secure" 0x78010000 region? I'm > trying to see if there are corresponding different addresses for the > keystone K2E, but haven't found them yet in the manuals. I went through the old emails archive but couldn't find a mention of the other address, sorry. From xen-devel-bounces@lists.xenproject.org Mon Jun 15 22:25:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 22:25:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkxY0-00029I-Lm; Mon, 15 Jun 2020 22:25:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkxXz-00029D-7O for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 22:25:43 +0000 X-Inumbo-ID: 255a63a2-af57-11ea-b853-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 255a63a2-af57-11ea-b853-12813bfff9fa; Mon, 15 Jun 2020 22:25:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z4Pq8epeVWQ3itDlZt8J3RjkA6xNj1Ns9kJOXPCwdKA=; b=6n354YJD8ta+K5VV4Y+FRXFqR DsV7Cgtd5VQ44fXf+DN37uOgn54LWVSYl5dwF5vMO2kXOU1n1w+wvyD7LQXVZWCtq6vsUw/J/WWBL PRld4hBsQAaGgi5V1mloSEjvHAK+tX7hLjnvBiJ+Rlzq/NvMldHSL/egAzIsN9bJh5TOw=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkxXw-0003EY-Mb; Mon, 15 Jun 2020 22:25:40 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jkxXw-0006e7-9t; Mon, 15 Jun 2020 22:25:40 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jkxXw-0001bw-8y; Mon, 15 Jun 2020 22:25:40 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151128: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-4.12-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=d58c48df8c6ca819f5e6e6f1740bb114f24f024f X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Mon, 15 Jun 2020 22:25:40 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151128 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151128/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 151058 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 151082 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen d58c48df8c6ca819f5e6e6f1740bb114f24f024f baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 32 days Failing since 150943 2020-06-09 17:06:00 Z 6 days 6 attempts Testing same since 151058 2020-06-12 04:30:55 Z 3 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Jun 15 22:29:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 22:29:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkxbN-0002Jb-AX; Mon, 15 Jun 2020 22:29:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkxbL-0002JW-6X for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 22:29:11 +0000 X-Inumbo-ID: a18958fc-af57-11ea-b853-12813bfff9fa Received: from gordon.huskydog.org.uk (unknown [81.187.95.156]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id a18958fc-af57-11ea-b853-12813bfff9fa; Mon, 15 Jun 2020 22:29:09 +0000 (UTC) Received: from [10.137.3.12] (percyq.huskydog.org.uk [10.42.42.111]) by gordon.huskydog.org.uk (Postfix) with ESMTP id 19EABDA796 for ; Mon, 15 Jun 2020 23:29:08 +0100 (BST) To: xen-devel@lists.xenproject.org From: Richard Simpson Subject: ARM - Successful install on RockPro64 Message-ID: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> Date: Mon, 15 Jun 2020 23:29:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, Just to report that I have successfully installed Xen on a Pine RockPro64 ARM SBC. I am using Xen 4.13 booting directly from u-boot on an SD card and my dom0 distribution is Gentoo. I haven't tried to create a domU yet and I am doing everything via the serial console so I can't say anything about the graphics. My biggest hurdle (apart from understanding u-boot) was needing to apply the vgic-v3: fix GICD_ISACTIVER patch. I will be happy to provide more details when I have got a bit further, but after two weeks of effort I was so delighted to finally be able to log into dom0 that I thought I'd better let somebody know. Richard Simpson From xen-devel-bounces@lists.xenproject.org Mon Jun 15 23:36:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 15 Jun 2020 23:36:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkydt-0007pD-CT; Mon, 15 Jun 2020 23:35:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkyds-0007p8-3E for xen-devel@lists.xenproject.org; Mon, 15 Jun 2020 23:35:52 +0000 X-Inumbo-ID: f287add6-af60-11ea-bb8b-bc764e2007e4 Received: from mail-ot1-x344.google.com (unknown [2607:f8b0:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f287add6-af60-11ea-bb8b-bc764e2007e4; Mon, 15 Jun 2020 23:35:51 +0000 (UTC) Received: by mail-ot1-x344.google.com with SMTP id v13so14536259otp.4 for ; Mon, 15 Jun 2020 16:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RskD6C5MxS8bssEQAwzWbTSPS9gY4FRfzYLmdbDz6do=; b=S8rwr1CXbMk9HK6xvVWi4QBxbnmefplHN9DcppspInsfa+AuqCXQCTHQEbh1uzoc4N bipBYBGBmqSAyhvz9k6B+V0Ciw3+ApDhgs3y0Hn+DlxB6JgRh3qzu3Q4sFFSJJbegLit 2dj/bX1rVV6kwq5Hrg9SH8RYqF4aJvATNKKkVEzy89U3adGvK8q3yttZP0Dnp0OYl6yQ W/kDhfUe1dzBM7ooaTPnQu4uPYZeYAO20U1ykMEVJj51L+QyJrIk7JCFiIH2ZjsNJ0wz h6kz2jSwnqFrM5W9OZcUvjti13wk08tNcS0F2btfWfUT7ACxQGsr5AL3NZxln/vlQApT l4ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RskD6C5MxS8bssEQAwzWbTSPS9gY4FRfzYLmdbDz6do=; b=kXF7HbdhEkAba2xRtuyscZODqD4TXQE4kWwUDwY4vEsB+92dStaDZagF/xeO0qEjpX LfmCQyhrCCVyMEWG009m4WhWqNd9SlimST8YFI5n0Um45OB8jgW+dAfTpfFVxDoTkDkK jdVGgJXEPIlyMg2E1q9xShLGeL4td1qXgL1hNIldzJE42aKK5RC+wEtHI1VRvgASgYCc n76KJJKMkWO3nD9wBjeZXBn89Ij/JEzf2wo2q0qY3GnQ8INUEOYobdolWbqhomGdhP9S aD0srhMBScA6CCexjsFS08/CgAUsIAZ0vt726MRIWeSslr7blZbEP04lVmWSs8MJ693d GiVw== X-Gm-Message-State: AOAM530Bbmn4e/yBymZer39wfOWgSOaUaAS/yFnOM2EbrPoVneONshh8 PNybxLJEnxhQQYfOJSRLXwSIC23QUZJiDVV7nAs= X-Google-Smtp-Source: ABdhPJzkVAD8lyCh5C8jOBNxwRG5jgpLMo6T6oSwOHxvVKknm0EYmDcsh/bddONVsBaetK3fuqNFn68bBHXyBp1S7Mw= X-Received: by 2002:a05:6830:1441:: with SMTP id w1mr333523otp.372.1592264150542; Mon, 15 Jun 2020 16:35:50 -0700 (PDT) MIME-Version: 1.0 References: <20200610185415.GG7231@minyard.net> In-Reply-To: From: Christopher Clark Date: Mon, 15 Jun 2020 16:35:39 -0700 Message-ID: Subject: Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel To: Roman Shaposhnik Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Corey Minyard , Stefano Stabellini , Julien Grall , tamas@tklengyel.com, Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote: > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote: > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > > existing sd cards, and this was working fine. I finally got to a full > > yocto build of the system, and it didn't boot. > > > > In fact, Xen didn't print anything at all, and nothing happens that > > might suggest it's booting without any console output. I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch works fine, whereas I see no console output from the kernel once Xen tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > > else the same, the 4.19 version of that overlay works, and the 5.4 > > version does not work. It also didn't work if I completely removed the > > overlay. The base device trees are the same between the two kernels. > > > > Looking at the overlay changes between the versions and Xen source, I > > can't trace down anything that would cause an issue. Has anyone seen > > this issue of have any ideas? Seen it: yes, but no progress on resolving it to report at this point. > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to 5.6.x: > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). Hi Roman - is there a specific commit in that rpi-5.6.y branch that you guys have working ok? It looks like the bcm2711_defconfig file wasn't included in the kernel source tree of that branch at the point the kernel version was bumped up to 5.6.14, so is there somewhere else to look for a matching kernel config? Christopher > > Thanks, > Roman. > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 00:14:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 00:14:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkzFA-0003Dr-4l; Tue, 16 Jun 2020 00:14:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkzF9-0003Dm-SW for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 00:14:23 +0000 X-Inumbo-ID: 54a4e9a2-af66-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 54a4e9a2-af66-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 00:14:23 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5B75320739; Tue, 16 Jun 2020 00:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592266462; bh=7/yhqzP4Yy86x9ThskDqDIa70wOp4qNlGxxo6hhx8Cc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=aurJiGTEKZy/D/DHIDQGG+4uJqcnWHrVUiGTN/NqdqUdKCVnEtHVCRAmGpVyeWv8X Gf27lrtcVanDG1rapSAdcvbEIcLN+x0olEVi12FIb/WIu2kQY1AjEJVTPN6ZHSN3uY xbMueF+Hl6kenf5oIXi04wGMni5baaS7DunmtXYE= Date: Mon, 15 Jun 2020 17:14:21 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Christopher Clark Subject: Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel In-Reply-To: Message-ID: References: <20200610185415.GG7231@minyard.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Corey Minyard , Stefano Stabellini , Julien Grall , Roman Shaposhnik , tamas@tklengyel.com, Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 15 Jun 2020, Christopher Clark wrote: > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote: > > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote: > > > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > > > existing sd cards, and this was working fine. I finally got to a full > > > yocto build of the system, and it didn't boot. > > > > > > In fact, Xen didn't print anything at all, and nothing happens that > > > might suggest it's booting without any console output. > > I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch > works fine, whereas I see no console output from the kernel once Xen > tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > > > else the same, the 4.19 version of that overlay works, and the 5.4 > > > version does not work. It also didn't work if I completely removed the > > > overlay. The base device trees are the same between the two kernels. > > > > > > Looking at the overlay changes between the versions and Xen source, I > > > can't trace down anything that would cause an issue. Has anyone seen > > > this issue of have any ideas? > > Seen it: yes, but no progress on resolving it to report at this point. > > > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to 5.6.x: > > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > > > The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). > > Hi Roman - is there a specific commit in that rpi-5.6.y branch that > you guys have working ok? > It looks like the bcm2711_defconfig file wasn't included in the kernel > source tree of that branch at the point the kernel version was bumped > up to 5.6.14, so is there somewhere else to look for a matching kernel > config? I don't know if that is the issue but beware that some device trees invert serial0 with serial1. Make sure to use /soc/serial@7e215040. You can do that by passing dtuart=/soc/serial@7e215040 to the Xen command line. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:00:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:00:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkzxu-00033L-NY; Tue, 16 Jun 2020 01:00:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jkzxt-0002WR-GS for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:00:37 +0000 X-Inumbo-ID: c99a6830-af6c-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c99a6830-af6c-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 01:00:36 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 63173207D4; Tue, 16 Jun 2020 01:00:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592269235; bh=J8jly909MLc0Y2ifdSI7UaZj0/Am7nLpruFY9//yKFE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=mrVy+HNgMsmIdtPo2H2g8Cq26JPA4K4xeahHH/6o324NISce4uA+GVqJ05iZf2QDD XaQvDvsxN2gcsit8CK7agQt37vfTwcw0FLp2l28xcUzfr5VkQ/Kh4XwhA3h0oqlMpp 4hZOitPpnPRG/oAtGTX58u43x8ohf1OvPDFenVro= Date: Mon, 15 Jun 2020 18:00:34 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches In-Reply-To: <20200613184132.11880-1-julien@xen.org> Message-ID: References: <20200613184132.11880-1-julien@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sat, 13 Jun 2020, Julien Grall wrote: > From: Julien Grall > > The documentation of pvcalls suggests there is padding for 32-bit x86 > at the end of most the structure. However, they are not described in > in the public header. > > Because of that all the structures would be 32-bit aligned and not > 64-bit aligned for 32-bit x86. > > For all the other architectures supported (Arm and 64-bit x86), the > structure are aligned to 64-bit because they contain uint64_t field. > Therefore all the structures contain implicit padding. > > The paddings are now corrected for 32-bit x86 and written explicitly for > all the architectures. > > While the structure size between 32-bit and 64-bit x86 is different, it > shouldn't cause any incompatibility between a 32-bit and 64-bit > frontend/backend because the commands are always 56 bits and the padding > are at the end of the structure. > > As an aside, the padding sadly cannot be mandated to be 0 as they are > already present. So it is not going to be possible to use the padding > for extending a command in the future. > > Signed-off-by: Julien Grall > > --- > Changes in v3: > - Use __i386__ rather than CONFIG_X86_32 > > Changes in v2: > - It is not possible to use the same padding for 32-bit x86 and > all the other supported architectures. > --- > docs/misc/pvcalls.pandoc | 18 ++++++++++-------- > xen/include/public/io/pvcalls.h | 14 ++++++++++++++ > 2 files changed, 24 insertions(+), 8 deletions(-) > > diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc > index 665dad556c39..caa71b36d78b 100644 > --- a/docs/misc/pvcalls.pandoc > +++ b/docs/misc/pvcalls.pandoc > @@ -246,9 +246,9 @@ The format is defined as follows: > uint32_t domain; > uint32_t type; > uint32_t protocol; > - #ifdef CONFIG_X86_32 > + #ifndef __i386__ > uint8_t pad[4]; > - #endif > + #endif Hi Julien, Thank you for doing this, and sorry for having missed v2 of this patch, I should have replied earlier. The intention of the #ifdef blocks like: #ifdef CONFIG_X86_32 uint8_t pad[4]; #endif in pvcalls.pandoc was to make sure that these structs would be 64bit aligned on x86_32 too. I realize that the public header doesn't match, but the spec is the "master copy". We have been saying it for a while (Andy in particular) that the specification documents are the one that define the protocol, not the public headers. This is the very first time we get to act on that statement. What a special occasion this is :-) So I think we should keep the specification as is and fix the public header instead. Something like v1 of this patch. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:03:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:03:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl00B-0008Lg-4e; Tue, 16 Jun 2020 01:02:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl009-0008Ku-3C for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:02:57 +0000 X-Inumbo-ID: 1c3d052a-af6d-11ea-bb8b-bc764e2007e4 Received: from mail-ot1-x342.google.com (unknown [2607:f8b0:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1c3d052a-af6d-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 01:02:55 +0000 (UTC) Received: by mail-ot1-x342.google.com with SMTP id g5so14677402otg.6 for ; Mon, 15 Jun 2020 18:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=iHDnNoDNU+c8dgUsqW6znGAfHjIobB34mz6wlM7mql8=; b=tyfkuskeAzZYSr1IbuTYE/gHpEoCylSi6Xe1DUFczTb8/fmC/PsWy3hu330GCqw8yu +9ZTgWhlkze+xl0mUTEdvoy3Tj3Slg5to0zz0QgbJDnbYV/96pQfOqg9nDZ8duFmF6Je tWhQzahdByWJXkCn193EbXYkgXKwjafm3Y8oOxluw9hCqjhRctkFYt9j1+VX7KxOCe/i WOeD3Uh15QEePcWQRuicTfLbYhe4NuAkby24G20BGl85eAgeIQhLHDUMHc5hXvt22SJr Lf8Hr+S5rGKzY3movz/e9k4Qduqf8DklgRQqK2NdQmLXxLqBJbC2GlOZ2n+pJnynfH2v fuUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=iHDnNoDNU+c8dgUsqW6znGAfHjIobB34mz6wlM7mql8=; b=l/Tijj2sumlkjCefzciJcJaF86TAhAq9c3vhgbdqVa9barqnGegp2o6tdxsDrcuFNK hl/OA4aoZNyMVF2I5qEnzkgk7X+RAURCZK/wk6JHnqX8946n7xVNM41ToYDWGEv2FXHV jChchTEH1ZYccx5hu2bvdBl/C66J39rTatuO49fVr7hKeJy5qXEQkLOigZYVbeOwAiWs SiunitZPhplRcDNwFt6IX57wR1rC4gglFX4Kqv/9Os+Cc3QIwn8FChkvzeE3Es9Zwe7k UBVR5/cJ+vI4dUNvZ+kXSxMIyWto3MIKJqSoMf7fasuvOKF0um9K2m7DvKAi1WIqV0i9 kf+g== X-Gm-Message-State: AOAM5331bfG6N/baQMMaeiFnAR3u2s8+DG1wfcx2ZWkt1eAOBTCg9m5u suerJrTbRRwuTJ0ooDBTDhYgVw== X-Google-Smtp-Source: ABdhPJw4cXoS8imzdZdUWhFtJ4chsI2NYqqaRsdqfgcLFN2tA3B+OAmosjSSgsWiq6H3f/z8UvsAKA== X-Received: by 2002:a05:6830:1d76:: with SMTP id l22mr514892oti.177.1592269374414; Mon, 15 Jun 2020 18:02:54 -0700 (PDT) Received: from minyard.net ([47.184.146.204]) by smtp.gmail.com with ESMTPSA id q10sm3680268otl.40.2020.06.15.18.02.53 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 Jun 2020 18:02:54 -0700 (PDT) Date: Mon, 15 Jun 2020 20:02:52 -0500 From: Corey Minyard To: Stefano Stabellini Subject: Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel Message-ID: <20200616010252.GC3113@minyard.net> References: <20200610185415.GG7231@minyard.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: cminyard@mvista.com Cc: Xen-devel , Roman Shaposhnik , Julien Grall , Christopher Clark , tamas@tklengyel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote: > On Mon, 15 Jun 2020, Christopher Clark wrote: > > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote: > > > > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote: > > > > > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > > > > existing sd cards, and this was working fine. I finally got to a full > > > > yocto build of the system, and it didn't boot. > > > > > > > > In fact, Xen didn't print anything at all, and nothing happens that > > > > might suggest it's booting without any console output. > > > > I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch > > works fine, whereas I see no console output from the kernel once Xen > > tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > > > > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > > > > else the same, the 4.19 version of that overlay works, and the 5.4 > > > > version does not work. It also didn't work if I completely removed the > > > > overlay. The base device trees are the same between the two kernels. > > > > > > > > Looking at the overlay changes between the versions and Xen source, I > > > > can't trace down anything that would cause an issue. Has anyone seen > > > > this issue of have any ideas? > > > > Seen it: yes, but no progress on resolving it to report at this point. > > > > > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to 5.6.x: > > > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > > > > > The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). > > > > Hi Roman - is there a specific commit in that rpi-5.6.y branch that > > you guys have working ok? > > It looks like the bcm2711_defconfig file wasn't included in the kernel > > source tree of that branch at the point the kernel version was bumped > > up to 5.6.14, so is there somewhere else to look for a matching kernel > > config? > > I don't know if that is the issue but beware that some device trees > invert serial0 with serial1. Make sure to use /soc/serial@7e215040. You > can do that by passing dtuart=/soc/serial@7e215040 to the Xen command > line. I already have that set as part of the boot process, but it still doesn't print anything out once Xen is started. I tried the 5.6 device tree, and no help there, eithers. I'm wondering if everyone is still running with the 4.19 device trees. The device tree differences between 4.19 and 5.4 are rather large, unfortunately. -corey From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:03:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:03:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl00G-0008Mc-DR; Tue, 16 Jun 2020 01:03:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl00F-0008MN-4I for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:03:03 +0000 X-Inumbo-ID: 20bb3f0e-af6d-11ea-bca7-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 20bb3f0e-af6d-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 01:03:02 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A2C73207D3; Tue, 16 Jun 2020 01:03:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592269382; bh=nD9QrmQZjM6IzEMASxvqOPSbGtmawHmtc8YwHVTx+PM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=nHzRT6myffydLwjVXVVmXGFlsooasrG4FDS5LEhOhN0XB1F3g1hb5XrDnx1CyZPhs g45cY4jQgGvWHI5qlIxsnULhgNQL5bEHxBbfbfv6sYKjJuPMPi5twcUiZU+HWc7YlE VBxXw0ZUdQZtGHJOh+jQTyPc6unKBhyUE97DW7pw= Date: Mon, 15 Jun 2020 18:03:01 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Bobby Eshleman Subject: Re: [RFC XEN PATCH 00/23] xen: beginning support for RISC-V In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Bobby Eshleman , Dan Robertson , Alistair Francis , Jan Beulich , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Any updates? I am looking forward to this :-) On Tue, 21 Jan 2020, Bobby Eshleman wrote: > Hey everybody, > > This is an RFC patchset for the very beginnings of adding RISC-V support > to Xen. This RFC is really just to start a dialogue about supporting > RISC-V and align with the Xen project and community before going > further. For that reason, it is very rough and very incomplete. > > My name is Bobby Eshleman, I'm a software engineer at > Star Lab / Wind River on the ARM team, mostly having worked in the Linux > kernel. I've also been involved a good amount with Xen on ARM here, > mostly dealing with tooling, deployment, and testing. A lot of this > patchset is heavily inspired by the Xen/ARM source code (particularly > the early setup up code). > > Currently, this patchset really only sets up virtual memory for Xen and > initializes UART to enable print output. None of RISC-V's > virtualization support has been implemented yet, although that is the > next road to start going down. Many functions only contain dummy > implementations. Many shortcuts have been taken and TODO's have been > left accordingly. It is very, very rough. Be forewarned: you are quite > likely to see some ungainly code here (despite my efforts to clean it up > before sending this patchset out). My intent with this RFC is to align > early and gauge interest, as opposed to presenting a totally complete > patchset. > > Because the ARM and RISC-V use cases will likely bear resemblance, the > RISC-V port should probably respect the design considerations that have > been laid out and respected by Xen on ARM for dom0less, safety > certification, etc... My inclination has been to initially target or > prioritize dom0less (without excluding dom0full) and use the ARM > dom0less implementation as a model to follow. I'd love feedback on this > point and on how the Xen project might envision a RISC-V implementation. > > This patchset has _some_ code for future support for 32-bit, but > currently my focus is on 64-bit. > > Again, this is a very, very rough and totally incomplete patchset. My > goal here is just to gauge community interest, begin discussing what Xen > on RISC-V may look like, receive feedback, and see if I'm heading in the > right direction. > > My big questions are: > Does the Xen project have interest in RISC-V? > What can be done to make the RISC-V port as upstreamable as > possible? > Any major pitfalls? > > It would be great to hear all of your feedback. > > Alistair Francis (20): > HACK: OE Build changes > HACK: Makefile: Don't build Xen tools > riscv: makefiles and Kconfig > riscv: Add riscv to tools/libxc header files > riscv: Add asm-offsets.c > riscv: Add delay.c > riscv: Add domain.c > riscv: Add domctl.c > riscv: Add guestcopy.c > riscv: Add time.c > riscv: Add smp.c > riscv: Add shutdown.c > riscv: Add traps.c > riscv: Add irq.c > riscv: Add vm_event.c > riscv: Add p2m.c > riscv: Add the lib directory > riscv: Add smpboot.c > riscv: Add percpu.c > riscv: Add sysctl.c > > Bobby Eshleman (3): > riscv: header files > riscv: early setup code > riscv: Add iommu.c > > Makefile | 13 +- > config/StdGNU.mk | 12 +- > config/riscv64.mk | 7 + > tools/configure | 32 +- > tools/firmware/Makefile | 12 +- > tools/libxc/include/xenctrl.h | 7 + > tools/libxc/xc_core.h | 2 + > tools/libxc/xc_core_riscv.h | 57 ++ > xen/Makefile | 2 +- > xen/Rules.mk | 2 +- > xen/arch/Kconfig | 1 + > xen/arch/riscv/Kconfig | 36 + > xen/arch/riscv/Makefile | 62 ++ > xen/arch/riscv/Rules.mk | 55 ++ > xen/arch/riscv/asm-offsets.c | 38 + > xen/arch/riscv/configs/riscv32_defconfig | 0 > xen/arch/riscv/configs/riscv64_defconfig | 0 > xen/arch/riscv/delay.c | 114 +++ > xen/arch/riscv/domain.c | 273 +++++++ > xen/arch/riscv/domctl.c | 53 ++ > xen/arch/riscv/guestcopy.c | 158 ++++ > xen/arch/riscv/head.S | 180 +++++ > xen/arch/riscv/irq.c | 107 +++ > xen/arch/riscv/lib/Makefile | 1 + > xen/arch/riscv/lib/find_next_bit.c | 284 +++++++ > xen/arch/riscv/mm.c | 925 +++++++++++++++++++++++ > xen/arch/riscv/p2m.c | 261 +++++++ > xen/arch/riscv/percpu.c | 84 ++ > xen/arch/riscv/platforms/Kconfig | 31 + > xen/arch/riscv/setup.c | 122 +++ > xen/arch/riscv/shutdown.c | 24 + > xen/arch/riscv/smp.c | 41 + > xen/arch/riscv/smpboot.c | 114 +++ > xen/arch/riscv/sysctl.c | 31 + > xen/arch/riscv/time.c | 74 ++ > xen/arch/riscv/traps.c | 56 ++ > xen/arch/riscv/vm_event.c | 42 + > xen/arch/riscv/xen.lds.S | 262 +++++++ > xen/drivers/passthrough/Makefile | 1 + > xen/drivers/passthrough/riscv/Makefile | 1 + > xen/drivers/passthrough/riscv/iommu.c | 74 ++ > xen/include/asm-riscv/altp2m.h | 39 + > xen/include/asm-riscv/asm.h | 76 ++ > xen/include/asm-riscv/atomic.h | 249 ++++++ > xen/include/asm-riscv/bitops.h | 331 ++++++++ > xen/include/asm-riscv/bug.h | 59 ++ > xen/include/asm-riscv/byteorder.h | 16 + > xen/include/asm-riscv/cache.h | 24 + > xen/include/asm-riscv/cmpxchg.h | 382 ++++++++++ > xen/include/asm-riscv/config.h | 203 +++++ > xen/include/asm-riscv/csr.h | 117 +++ > xen/include/asm-riscv/current.h | 50 ++ > xen/include/asm-riscv/debugger.h | 15 + > xen/include/asm-riscv/delay.h | 28 + > xen/include/asm-riscv/desc.h | 12 + > xen/include/asm-riscv/device.h | 15 + > xen/include/asm-riscv/div64.h | 23 + > xen/include/asm-riscv/domain.h | 85 +++ > xen/include/asm-riscv/event.h | 42 + > xen/include/asm-riscv/fence.h | 12 + > xen/include/asm-riscv/flushtlb.h | 56 ++ > xen/include/asm-riscv/grant_table.h | 93 +++ > xen/include/asm-riscv/guest_access.h | 164 ++++ > xen/include/asm-riscv/guest_atomics.h | 62 ++ > xen/include/asm-riscv/hardirq.h | 27 + > xen/include/asm-riscv/hypercall.h | 12 + > xen/include/asm-riscv/init.h | 42 + > xen/include/asm-riscv/io.h | 283 +++++++ > xen/include/asm-riscv/iocap.h | 16 + > xen/include/asm-riscv/iommu.h | 49 ++ > xen/include/asm-riscv/irq.h | 58 ++ > xen/include/asm-riscv/mem_access.h | 35 + > xen/include/asm-riscv/mm.h | 308 ++++++++ > xen/include/asm-riscv/monitor.h | 65 ++ > xen/include/asm-riscv/nospec.h | 25 + > xen/include/asm-riscv/numa.h | 41 + > xen/include/asm-riscv/p2m.h | 410 ++++++++++ > xen/include/asm-riscv/page.h | 327 ++++++++ > xen/include/asm-riscv/paging.h | 16 + > xen/include/asm-riscv/pci.h | 31 + > xen/include/asm-riscv/percpu.h | 34 + > xen/include/asm-riscv/pgtable-bits.h | 53 ++ > xen/include/asm-riscv/processor.h | 60 ++ > xen/include/asm-riscv/random.h | 9 + > xen/include/asm-riscv/regs.h | 42 + > xen/include/asm-riscv/riscv_encoding.h | 682 +++++++++++++++++ > xen/include/asm-riscv/setup.h | 16 + > xen/include/asm-riscv/smp.h | 50 ++ > xen/include/asm-riscv/softirq.h | 16 + > xen/include/asm-riscv/spinlock.h | 13 + > xen/include/asm-riscv/string.h | 28 + > xen/include/asm-riscv/sysregs.h | 14 + > xen/include/asm-riscv/system.h | 96 +++ > xen/include/asm-riscv/time.h | 60 ++ > xen/include/asm-riscv/trace.h | 12 + > xen/include/asm-riscv/types.h | 73 ++ > xen/include/asm-riscv/vm_event.h | 61 ++ > xen/include/asm-riscv/xenoprof.h | 12 + > xen/include/public/arch-riscv.h | 181 +++++ > xen/include/public/arch-riscv/hvm/save.h | 39 + > xen/include/public/hvm/save.h | 2 + > xen/include/public/pmu.h | 2 + > xen/include/public/xen.h | 2 + > 103 files changed, 9064 insertions(+), 42 deletions(-) > create mode 100644 config/riscv64.mk > create mode 100644 tools/libxc/xc_core_riscv.h > create mode 100644 xen/arch/riscv/Kconfig > create mode 100644 xen/arch/riscv/Makefile > create mode 100644 xen/arch/riscv/Rules.mk > create mode 100644 xen/arch/riscv/asm-offsets.c > create mode 100644 xen/arch/riscv/configs/riscv32_defconfig > create mode 100644 xen/arch/riscv/configs/riscv64_defconfig > create mode 100644 xen/arch/riscv/delay.c > create mode 100644 xen/arch/riscv/domain.c > create mode 100644 xen/arch/riscv/domctl.c > create mode 100644 xen/arch/riscv/guestcopy.c > create mode 100644 xen/arch/riscv/head.S > create mode 100644 xen/arch/riscv/irq.c > create mode 100644 xen/arch/riscv/lib/Makefile > create mode 100644 xen/arch/riscv/lib/find_next_bit.c > create mode 100644 xen/arch/riscv/mm.c > create mode 100644 xen/arch/riscv/p2m.c > create mode 100644 xen/arch/riscv/percpu.c > create mode 100644 xen/arch/riscv/platforms/Kconfig > create mode 100644 xen/arch/riscv/setup.c > create mode 100644 xen/arch/riscv/shutdown.c > create mode 100644 xen/arch/riscv/smp.c > create mode 100644 xen/arch/riscv/smpboot.c > create mode 100644 xen/arch/riscv/sysctl.c > create mode 100644 xen/arch/riscv/time.c > create mode 100644 xen/arch/riscv/traps.c > create mode 100644 xen/arch/riscv/vm_event.c > create mode 100644 xen/arch/riscv/xen.lds.S > create mode 100644 xen/drivers/passthrough/riscv/Makefile > create mode 100644 xen/drivers/passthrough/riscv/iommu.c > create mode 100644 xen/include/asm-riscv/altp2m.h > create mode 100644 xen/include/asm-riscv/asm.h > create mode 100644 xen/include/asm-riscv/atomic.h > create mode 100644 xen/include/asm-riscv/bitops.h > create mode 100644 xen/include/asm-riscv/bug.h > create mode 100644 xen/include/asm-riscv/byteorder.h > create mode 100644 xen/include/asm-riscv/cache.h > create mode 100644 xen/include/asm-riscv/cmpxchg.h > create mode 100644 xen/include/asm-riscv/config.h > create mode 100644 xen/include/asm-riscv/csr.h > create mode 100644 xen/include/asm-riscv/current.h > create mode 100644 xen/include/asm-riscv/debugger.h > create mode 100644 xen/include/asm-riscv/delay.h > create mode 100644 xen/include/asm-riscv/desc.h > create mode 100644 xen/include/asm-riscv/device.h > create mode 100644 xen/include/asm-riscv/div64.h > create mode 100644 xen/include/asm-riscv/domain.h > create mode 100644 xen/include/asm-riscv/event.h > create mode 100644 xen/include/asm-riscv/fence.h > create mode 100644 xen/include/asm-riscv/flushtlb.h > create mode 100644 xen/include/asm-riscv/grant_table.h > create mode 100644 xen/include/asm-riscv/guest_access.h > create mode 100644 xen/include/asm-riscv/guest_atomics.h > create mode 100644 xen/include/asm-riscv/hardirq.h > create mode 100644 xen/include/asm-riscv/hypercall.h > create mode 100644 xen/include/asm-riscv/init.h > create mode 100644 xen/include/asm-riscv/io.h > create mode 100644 xen/include/asm-riscv/iocap.h > create mode 100644 xen/include/asm-riscv/iommu.h > create mode 100644 xen/include/asm-riscv/irq.h > create mode 100644 xen/include/asm-riscv/mem_access.h > create mode 100644 xen/include/asm-riscv/mm.h > create mode 100644 xen/include/asm-riscv/monitor.h > create mode 100644 xen/include/asm-riscv/nospec.h > create mode 100644 xen/include/asm-riscv/numa.h > create mode 100644 xen/include/asm-riscv/p2m.h > create mode 100644 xen/include/asm-riscv/page.h > create mode 100644 xen/include/asm-riscv/paging.h > create mode 100644 xen/include/asm-riscv/pci.h > create mode 100644 xen/include/asm-riscv/percpu.h > create mode 100644 xen/include/asm-riscv/pgtable-bits.h > create mode 100644 xen/include/asm-riscv/processor.h > create mode 100644 xen/include/asm-riscv/random.h > create mode 100644 xen/include/asm-riscv/regs.h > create mode 100644 xen/include/asm-riscv/riscv_encoding.h > create mode 100644 xen/include/asm-riscv/setup.h > create mode 100644 xen/include/asm-riscv/smp.h > create mode 100644 xen/include/asm-riscv/softirq.h > create mode 100644 xen/include/asm-riscv/spinlock.h > create mode 100644 xen/include/asm-riscv/string.h > create mode 100644 xen/include/asm-riscv/sysregs.h > create mode 100644 xen/include/asm-riscv/system.h > create mode 100644 xen/include/asm-riscv/time.h > create mode 100644 xen/include/asm-riscv/trace.h > create mode 100644 xen/include/asm-riscv/types.h > create mode 100644 xen/include/asm-riscv/vm_event.h > create mode 100644 xen/include/asm-riscv/xenoprof.h > create mode 100644 xen/include/public/arch-riscv.h > create mode 100644 xen/include/public/arch-riscv/hvm/save.h > > -- > 2.25.0 > > The source code can be found on github: > https://github.com/beshleman/xen/tree/port-to-risc-v > > The patchset only targets the QEMU virt board and it is tested on > Alistair Francis's patchset for QEMU with RISC-V hypervisor extensions > v0.5, found here: > https://github.com/alistair23/qemu/tree/mainline/alistair/riscv-hyp-ext-v0.5.next > > QEMU is built with: > git clone --single-branch --branch mainline/alistair/riscv-hyp-ext-v0.5.next \ > https://github.com/alistair23/qemu.git > cd qemu > mkdir build && cd build > ../configure --target-list=riscv64-softmmu > make -j$(nproc) && make install > > The bootloader used is the standard OpenSBI, built with the command: > CROSS_COMPILE=riscv64-unknown-linux-gnu- PLATFORM=qemu/virt FW_PAYLOAD_PATH=../xen/xen/xen make > > Xen/RISC-V is built with: > XEN_TARGET_ARCH=riscv64 CROSS_COMPILE=riscv64-unknown-linux-gnu- make build > > Xen may be ran with the following command: > qemu-system-riscv64 -cpu rv64,x-h=true -M virt -m 512M -display none \ > -serial stdio -kernel \ > opensbi/build/platform/qemu/virt/firmware/fw_payload.elf > > Also, shoutout to Alistair Francis (from Western Digital) for getting > the ball rolling and doing a ton of the groundwork with > Makefile/Kconfig, a ton of the RISC-V specific header files, and also > the QEMU RISC-V H extension support, and Dan Robertson (a colleague of > mine at Star Lab) for help in forward porting a number of patches that > were out-of-sync with upstream. > > > Thanks, > Bobby Eshleman > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:06:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:06:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl03I-00009r-1U; Tue, 16 Jun 2020 01:06:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl03G-00009m-FK for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:06:10 +0000 X-Inumbo-ID: 8f8c225e-af6d-11ea-bca7-bc764e2007e4 Received: from mail-qt1-x841.google.com (unknown [2607:f8b0:4864:20::841]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8f8c225e-af6d-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 01:06:08 +0000 (UTC) Received: by mail-qt1-x841.google.com with SMTP id j32so14241044qte.10 for ; Mon, 15 Jun 2020 18:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wW+puVJHpMs7S9N79RyQRGtzBwwiwKyuY+x/s5I6TwI=; b=Jm1W/ZttYXDhfUgeO6GTfIZYh3cZAO4hDNXvNsiBDUNDL/5YfqFGCgpHvqfoMYfBc+ ahH7bSRDv1pYbyyfBkMk3OEo/d01Ck10pKaBXu7JdKSVjz6l5T61HhsbWaKS0Vms7c81 5fvj4oXlkJx9395lcyJH5cnY529Prg/SXJXno3KrI17Y+CwL9nhFrV/sCbvkELH2XzMy QJVgSNZXUJN0p9L4v19U7qe2HBQ8FLBgjR8K2TiT0gQPXEMZXdKSR4NWNrdEEr/EtvBv Q9Ji0T4qeXPQOYhWCfwMcOYhsCdRuOp2zLAP3YQwshJLWllp3XKsAiDvFw/Wfw3QwAnm qBGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wW+puVJHpMs7S9N79RyQRGtzBwwiwKyuY+x/s5I6TwI=; b=kgac7WOogatnzfx/LnwgSghp68cJiXcBueowZKhP/oSOyPD6JpM8NCeJvzBReypWNn yiaMsFwZc+luFBI6yjSq239YodHNVx2fvuPniMizOwx4L2SXgFm6AG9OPJo/TeovcReW gAuByjoXFjJMZlRhGFTL+P5yLnSolW2hmsO+Y+W37i4udQOcyZFHg+MqdUy7FKrAODFA K7+llYx5wAozBZ82bHTn8OQoBh0rUykqYN7thRybFSwhGsVd7Wkmn7mgWI0PDsj3k7FQ Ic7Nuvk8FX1BP5Hao6512ZOU+J5i6YjvnYU34HHHLC57EgQGniBHxpkvAzsL2HqPakJk qOcA== X-Gm-Message-State: AOAM533CFzE3rLUbh03fVUOXr5Fiyw9Kh1KHNAG0cPlhqd/VGR5cLVKw i6m2jALQEbkywZu2DR8idsHS5zPwfphxSxRZrkTfVg== X-Google-Smtp-Source: ABdhPJyWm8F8DxS2nF03ETgrRohjHFE4DNQ0uwOftHEG6wzEQsRkUUAi6rFuDxhIzLh8zht7qdy+5OnrTvTx4dXL1sE= X-Received: by 2002:ac8:4d0e:: with SMTP id w14mr18908099qtv.266.1592269567983; Mon, 15 Jun 2020 18:06:07 -0700 (PDT) MIME-Version: 1.0 References: <20200610185415.GG7231@minyard.net> <20200616010252.GC3113@minyard.net> In-Reply-To: <20200616010252.GC3113@minyard.net> From: Roman Shaposhnik Date: Mon, 15 Jun 2020 18:05:57 -0700 Message-ID: Subject: Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel To: Corey Minyard Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Stefano Stabellini , Julien Grall , Christopher Clark , tamas@tklengyel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 6:02 PM Corey Minyard wrote: > > On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote: > > On Mon, 15 Jun 2020, Christopher Clark wrote: > > > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote: > > > > > > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote: > > > > > > > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > > > > > existing sd cards, and this was working fine. I finally got to a full > > > > > yocto build of the system, and it didn't boot. > > > > > > > > > > In fact, Xen didn't print anything at all, and nothing happens that > > > > > might suggest it's booting without any console output. > > > > > > I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch > > > works fine, whereas I see no console output from the kernel once Xen > > > tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > > > > > > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > > > > > else the same, the 4.19 version of that overlay works, and the 5.4 > > > > > version does not work. It also didn't work if I completely removed the > > > > > overlay. The base device trees are the same between the two kernels. > > > > > > > > > > Looking at the overlay changes between the versions and Xen source, I > > > > > can't trace down anything that would cause an issue. Has anyone seen > > > > > this issue of have any ideas? > > > > > > Seen it: yes, but no progress on resolving it to report at this point. > > > > > > > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to 5.6.x: > > > > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > > > > > > > The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). > > > > > > Hi Roman - is there a specific commit in that rpi-5.6.y branch that > > > you guys have working ok? > > > It looks like the bcm2711_defconfig file wasn't included in the kernel > > > source tree of that branch at the point the kernel version was bumped > > > up to 5.6.14, so is there somewhere else to look for a matching kernel > > > config? > > > > I don't know if that is the issue but beware that some device trees > > invert serial0 with serial1. Make sure to use /soc/serial@7e215040. You > > can do that by passing dtuart=/soc/serial@7e215040 to the Xen command > > line. > > I already have that set as part of the boot process, but it still > doesn't print anything out once Xen is started. > > I tried the 5.6 device tree, and no help there, eithers. I'm wondering > if everyone is still running with the 4.19 device trees. As I pointed out in the EVE link above -- we're very happily running with 5.6 device trees. They are, of course, taken from RPI kernel tree. Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:08:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:08:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl05f-0000I0-Ev; Tue, 16 Jun 2020 01:08:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl05e-0000Hv-FR for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:08:38 +0000 X-Inumbo-ID: e84bc304-af6d-11ea-8496-bc764e2007e4 Received: from mail-qk1-x744.google.com (unknown [2607:f8b0:4864:20::744]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e84bc304-af6d-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 01:08:37 +0000 (UTC) Received: by mail-qk1-x744.google.com with SMTP id w3so17719152qkb.6 for ; Mon, 15 Jun 2020 18:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6EGHYhhX27oghi/u6jTNeekj6ThDyQW5OLIHAJ60l30=; b=KjFcpR3Hd2vywRYBhi8MkeG4C0iplM1KcBXN97Y6Cs1mzTfYdWsRjfXcU1ExsRvmuq eA55t550Q4KxsF2GSWPVQrEJDMkbnEEio7zn4dP1OteN9Tm17kn9yL1JC1+oK8woPXOc hkKDs0+9buhBGubpWXe9id2Kv5hxSaOPp8RFm0HDXZAldoq9Bz6xODvCLfHJARvmGait IqY/vDNvFzwXsMcGXGjWsgpPqR3kLh7j8L0FQ58naW41R8msbkb0+JyfwnQHiqTeiHLB 1jBqddvksZcfvq4hf2WuObX1WNdGLm5IPKawOfF0LPByWyaRjf7tzm+InB0vQL0p15LS tOxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6EGHYhhX27oghi/u6jTNeekj6ThDyQW5OLIHAJ60l30=; b=IM+rbHG2bO5DmnViX3NLBEfLDW9UkxAwbD3gXpa6yqMWWLL9WeWpufk/iod2J/wGLz w+BZvmrxSXtteXugkuyh+cWOzfHR+faQT5xklWx6TruefUf/F7znjcrYsgpPNFxVBTrf +HsKW7g81S3VjXgEDbFBgZaReV0m/1H+HgNwXmkZtbAZRQ8zVAr2DlUdP041wGkXBvGe glWlAGUSAae206LLDr3syhpmS9p4fFun6+FOPTIJIFdMEcvcIhQC14J+eh6RH4lp2bcg +gWMUnVnKusU0mr2gCUHiwpKtetjh02PZZkFMW7F11WfS+XTrY7tioZapm9Lqq7nunIa ZyEg== X-Gm-Message-State: AOAM53221t0vsvHTGsAMEuDVDWNkTiZdanPpoRJH68IfZuCbEp3PoUt+ AKXZ2cMKNam8vZSLaftS7EL8p/9siSBl8HGXgvFMhw== X-Google-Smtp-Source: ABdhPJxHo7CoMhuzau2RYJk6MLsqySFriSf7zk6ftOZU90tSb/xcnzyr+M234Rjv0h2BBIPbklfXWw9Gm3011jPmHgY= X-Received: by 2002:a37:8c04:: with SMTP id o4mr1140747qkd.270.1592269716738; Mon, 15 Jun 2020 18:08:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shaposhnik Date: Mon, 15 Jun 2020 18:08:25 -0700 Message-ID: Subject: Re: [RFC XEN PATCH 00/23] xen: beginning support for RISC-V To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Bobby Eshleman , Dan Robertson , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Bobby Eshleman , Alistair Francis , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 6:03 PM Stefano Stabellini wrote: > > Any updates? I am looking forward to this :-) At the risk of flooding the list with +1s -- I'm also very much looking forward to it! Thanks, Roman. > > > On Tue, 21 Jan 2020, Bobby Eshleman wrote: > > Hey everybody, > > > > This is an RFC patchset for the very beginnings of adding RISC-V support > > to Xen. This RFC is really just to start a dialogue about supporting > > RISC-V and align with the Xen project and community before going > > further. For that reason, it is very rough and very incomplete. > > > > My name is Bobby Eshleman, I'm a software engineer at > > Star Lab / Wind River on the ARM team, mostly having worked in the Linux > > kernel. I've also been involved a good amount with Xen on ARM here, > > mostly dealing with tooling, deployment, and testing. A lot of this > > patchset is heavily inspired by the Xen/ARM source code (particularly > > the early setup up code). > > > > Currently, this patchset really only sets up virtual memory for Xen and > > initializes UART to enable print output. None of RISC-V's > > virtualization support has been implemented yet, although that is the > > next road to start going down. Many functions only contain dummy > > implementations. Many shortcuts have been taken and TODO's have been > > left accordingly. It is very, very rough. Be forewarned: you are quite > > likely to see some ungainly code here (despite my efforts to clean it up > > before sending this patchset out). My intent with this RFC is to align > > early and gauge interest, as opposed to presenting a totally complete > > patchset. > > > > Because the ARM and RISC-V use cases will likely bear resemblance, the > > RISC-V port should probably respect the design considerations that have > > been laid out and respected by Xen on ARM for dom0less, safety > > certification, etc... My inclination has been to initially target or > > prioritize dom0less (without excluding dom0full) and use the ARM > > dom0less implementation as a model to follow. I'd love feedback on this > > point and on how the Xen project might envision a RISC-V implementation. > > > > This patchset has _some_ code for future support for 32-bit, but > > currently my focus is on 64-bit. > > > > Again, this is a very, very rough and totally incomplete patchset. My > > goal here is just to gauge community interest, begin discussing what Xen > > on RISC-V may look like, receive feedback, and see if I'm heading in the > > right direction. > > > > My big questions are: > > Does the Xen project have interest in RISC-V? > > What can be done to make the RISC-V port as upstreamable as > > possible? > > Any major pitfalls? > > > > It would be great to hear all of your feedback. > > > > Alistair Francis (20): > > HACK: OE Build changes > > HACK: Makefile: Don't build Xen tools > > riscv: makefiles and Kconfig > > riscv: Add riscv to tools/libxc header files > > riscv: Add asm-offsets.c > > riscv: Add delay.c > > riscv: Add domain.c > > riscv: Add domctl.c > > riscv: Add guestcopy.c > > riscv: Add time.c > > riscv: Add smp.c > > riscv: Add shutdown.c > > riscv: Add traps.c > > riscv: Add irq.c > > riscv: Add vm_event.c > > riscv: Add p2m.c > > riscv: Add the lib directory > > riscv: Add smpboot.c > > riscv: Add percpu.c > > riscv: Add sysctl.c > > > > Bobby Eshleman (3): > > riscv: header files > > riscv: early setup code > > riscv: Add iommu.c > > > > Makefile | 13 +- > > config/StdGNU.mk | 12 +- > > config/riscv64.mk | 7 + > > tools/configure | 32 +- > > tools/firmware/Makefile | 12 +- > > tools/libxc/include/xenctrl.h | 7 + > > tools/libxc/xc_core.h | 2 + > > tools/libxc/xc_core_riscv.h | 57 ++ > > xen/Makefile | 2 +- > > xen/Rules.mk | 2 +- > > xen/arch/Kconfig | 1 + > > xen/arch/riscv/Kconfig | 36 + > > xen/arch/riscv/Makefile | 62 ++ > > xen/arch/riscv/Rules.mk | 55 ++ > > xen/arch/riscv/asm-offsets.c | 38 + > > xen/arch/riscv/configs/riscv32_defconfig | 0 > > xen/arch/riscv/configs/riscv64_defconfig | 0 > > xen/arch/riscv/delay.c | 114 +++ > > xen/arch/riscv/domain.c | 273 +++++++ > > xen/arch/riscv/domctl.c | 53 ++ > > xen/arch/riscv/guestcopy.c | 158 ++++ > > xen/arch/riscv/head.S | 180 +++++ > > xen/arch/riscv/irq.c | 107 +++ > > xen/arch/riscv/lib/Makefile | 1 + > > xen/arch/riscv/lib/find_next_bit.c | 284 +++++++ > > xen/arch/riscv/mm.c | 925 +++++++++++++++++++++++ > > xen/arch/riscv/p2m.c | 261 +++++++ > > xen/arch/riscv/percpu.c | 84 ++ > > xen/arch/riscv/platforms/Kconfig | 31 + > > xen/arch/riscv/setup.c | 122 +++ > > xen/arch/riscv/shutdown.c | 24 + > > xen/arch/riscv/smp.c | 41 + > > xen/arch/riscv/smpboot.c | 114 +++ > > xen/arch/riscv/sysctl.c | 31 + > > xen/arch/riscv/time.c | 74 ++ > > xen/arch/riscv/traps.c | 56 ++ > > xen/arch/riscv/vm_event.c | 42 + > > xen/arch/riscv/xen.lds.S | 262 +++++++ > > xen/drivers/passthrough/Makefile | 1 + > > xen/drivers/passthrough/riscv/Makefile | 1 + > > xen/drivers/passthrough/riscv/iommu.c | 74 ++ > > xen/include/asm-riscv/altp2m.h | 39 + > > xen/include/asm-riscv/asm.h | 76 ++ > > xen/include/asm-riscv/atomic.h | 249 ++++++ > > xen/include/asm-riscv/bitops.h | 331 ++++++++ > > xen/include/asm-riscv/bug.h | 59 ++ > > xen/include/asm-riscv/byteorder.h | 16 + > > xen/include/asm-riscv/cache.h | 24 + > > xen/include/asm-riscv/cmpxchg.h | 382 ++++++++++ > > xen/include/asm-riscv/config.h | 203 +++++ > > xen/include/asm-riscv/csr.h | 117 +++ > > xen/include/asm-riscv/current.h | 50 ++ > > xen/include/asm-riscv/debugger.h | 15 + > > xen/include/asm-riscv/delay.h | 28 + > > xen/include/asm-riscv/desc.h | 12 + > > xen/include/asm-riscv/device.h | 15 + > > xen/include/asm-riscv/div64.h | 23 + > > xen/include/asm-riscv/domain.h | 85 +++ > > xen/include/asm-riscv/event.h | 42 + > > xen/include/asm-riscv/fence.h | 12 + > > xen/include/asm-riscv/flushtlb.h | 56 ++ > > xen/include/asm-riscv/grant_table.h | 93 +++ > > xen/include/asm-riscv/guest_access.h | 164 ++++ > > xen/include/asm-riscv/guest_atomics.h | 62 ++ > > xen/include/asm-riscv/hardirq.h | 27 + > > xen/include/asm-riscv/hypercall.h | 12 + > > xen/include/asm-riscv/init.h | 42 + > > xen/include/asm-riscv/io.h | 283 +++++++ > > xen/include/asm-riscv/iocap.h | 16 + > > xen/include/asm-riscv/iommu.h | 49 ++ > > xen/include/asm-riscv/irq.h | 58 ++ > > xen/include/asm-riscv/mem_access.h | 35 + > > xen/include/asm-riscv/mm.h | 308 ++++++++ > > xen/include/asm-riscv/monitor.h | 65 ++ > > xen/include/asm-riscv/nospec.h | 25 + > > xen/include/asm-riscv/numa.h | 41 + > > xen/include/asm-riscv/p2m.h | 410 ++++++++++ > > xen/include/asm-riscv/page.h | 327 ++++++++ > > xen/include/asm-riscv/paging.h | 16 + > > xen/include/asm-riscv/pci.h | 31 + > > xen/include/asm-riscv/percpu.h | 34 + > > xen/include/asm-riscv/pgtable-bits.h | 53 ++ > > xen/include/asm-riscv/processor.h | 60 ++ > > xen/include/asm-riscv/random.h | 9 + > > xen/include/asm-riscv/regs.h | 42 + > > xen/include/asm-riscv/riscv_encoding.h | 682 +++++++++++++++++ > > xen/include/asm-riscv/setup.h | 16 + > > xen/include/asm-riscv/smp.h | 50 ++ > > xen/include/asm-riscv/softirq.h | 16 + > > xen/include/asm-riscv/spinlock.h | 13 + > > xen/include/asm-riscv/string.h | 28 + > > xen/include/asm-riscv/sysregs.h | 14 + > > xen/include/asm-riscv/system.h | 96 +++ > > xen/include/asm-riscv/time.h | 60 ++ > > xen/include/asm-riscv/trace.h | 12 + > > xen/include/asm-riscv/types.h | 73 ++ > > xen/include/asm-riscv/vm_event.h | 61 ++ > > xen/include/asm-riscv/xenoprof.h | 12 + > > xen/include/public/arch-riscv.h | 181 +++++ > > xen/include/public/arch-riscv/hvm/save.h | 39 + > > xen/include/public/hvm/save.h | 2 + > > xen/include/public/pmu.h | 2 + > > xen/include/public/xen.h | 2 + > > 103 files changed, 9064 insertions(+), 42 deletions(-) > > create mode 100644 config/riscv64.mk > > create mode 100644 tools/libxc/xc_core_riscv.h > > create mode 100644 xen/arch/riscv/Kconfig > > create mode 100644 xen/arch/riscv/Makefile > > create mode 100644 xen/arch/riscv/Rules.mk > > create mode 100644 xen/arch/riscv/asm-offsets.c > > create mode 100644 xen/arch/riscv/configs/riscv32_defconfig > > create mode 100644 xen/arch/riscv/configs/riscv64_defconfig > > create mode 100644 xen/arch/riscv/delay.c > > create mode 100644 xen/arch/riscv/domain.c > > create mode 100644 xen/arch/riscv/domctl.c > > create mode 100644 xen/arch/riscv/guestcopy.c > > create mode 100644 xen/arch/riscv/head.S > > create mode 100644 xen/arch/riscv/irq.c > > create mode 100644 xen/arch/riscv/lib/Makefile > > create mode 100644 xen/arch/riscv/lib/find_next_bit.c > > create mode 100644 xen/arch/riscv/mm.c > > create mode 100644 xen/arch/riscv/p2m.c > > create mode 100644 xen/arch/riscv/percpu.c > > create mode 100644 xen/arch/riscv/platforms/Kconfig > > create mode 100644 xen/arch/riscv/setup.c > > create mode 100644 xen/arch/riscv/shutdown.c > > create mode 100644 xen/arch/riscv/smp.c > > create mode 100644 xen/arch/riscv/smpboot.c > > create mode 100644 xen/arch/riscv/sysctl.c > > create mode 100644 xen/arch/riscv/time.c > > create mode 100644 xen/arch/riscv/traps.c > > create mode 100644 xen/arch/riscv/vm_event.c > > create mode 100644 xen/arch/riscv/xen.lds.S > > create mode 100644 xen/drivers/passthrough/riscv/Makefile > > create mode 100644 xen/drivers/passthrough/riscv/iommu.c > > create mode 100644 xen/include/asm-riscv/altp2m.h > > create mode 100644 xen/include/asm-riscv/asm.h > > create mode 100644 xen/include/asm-riscv/atomic.h > > create mode 100644 xen/include/asm-riscv/bitops.h > > create mode 100644 xen/include/asm-riscv/bug.h > > create mode 100644 xen/include/asm-riscv/byteorder.h > > create mode 100644 xen/include/asm-riscv/cache.h > > create mode 100644 xen/include/asm-riscv/cmpxchg.h > > create mode 100644 xen/include/asm-riscv/config.h > > create mode 100644 xen/include/asm-riscv/csr.h > > create mode 100644 xen/include/asm-riscv/current.h > > create mode 100644 xen/include/asm-riscv/debugger.h > > create mode 100644 xen/include/asm-riscv/delay.h > > create mode 100644 xen/include/asm-riscv/desc.h > > create mode 100644 xen/include/asm-riscv/device.h > > create mode 100644 xen/include/asm-riscv/div64.h > > create mode 100644 xen/include/asm-riscv/domain.h > > create mode 100644 xen/include/asm-riscv/event.h > > create mode 100644 xen/include/asm-riscv/fence.h > > create mode 100644 xen/include/asm-riscv/flushtlb.h > > create mode 100644 xen/include/asm-riscv/grant_table.h > > create mode 100644 xen/include/asm-riscv/guest_access.h > > create mode 100644 xen/include/asm-riscv/guest_atomics.h > > create mode 100644 xen/include/asm-riscv/hardirq.h > > create mode 100644 xen/include/asm-riscv/hypercall.h > > create mode 100644 xen/include/asm-riscv/init.h > > create mode 100644 xen/include/asm-riscv/io.h > > create mode 100644 xen/include/asm-riscv/iocap.h > > create mode 100644 xen/include/asm-riscv/iommu.h > > create mode 100644 xen/include/asm-riscv/irq.h > > create mode 100644 xen/include/asm-riscv/mem_access.h > > create mode 100644 xen/include/asm-riscv/mm.h > > create mode 100644 xen/include/asm-riscv/monitor.h > > create mode 100644 xen/include/asm-riscv/nospec.h > > create mode 100644 xen/include/asm-riscv/numa.h > > create mode 100644 xen/include/asm-riscv/p2m.h > > create mode 100644 xen/include/asm-riscv/page.h > > create mode 100644 xen/include/asm-riscv/paging.h > > create mode 100644 xen/include/asm-riscv/pci.h > > create mode 100644 xen/include/asm-riscv/percpu.h > > create mode 100644 xen/include/asm-riscv/pgtable-bits.h > > create mode 100644 xen/include/asm-riscv/processor.h > > create mode 100644 xen/include/asm-riscv/random.h > > create mode 100644 xen/include/asm-riscv/regs.h > > create mode 100644 xen/include/asm-riscv/riscv_encoding.h > > create mode 100644 xen/include/asm-riscv/setup.h > > create mode 100644 xen/include/asm-riscv/smp.h > > create mode 100644 xen/include/asm-riscv/softirq.h > > create mode 100644 xen/include/asm-riscv/spinlock.h > > create mode 100644 xen/include/asm-riscv/string.h > > create mode 100644 xen/include/asm-riscv/sysregs.h > > create mode 100644 xen/include/asm-riscv/system.h > > create mode 100644 xen/include/asm-riscv/time.h > > create mode 100644 xen/include/asm-riscv/trace.h > > create mode 100644 xen/include/asm-riscv/types.h > > create mode 100644 xen/include/asm-riscv/vm_event.h > > create mode 100644 xen/include/asm-riscv/xenoprof.h > > create mode 100644 xen/include/public/arch-riscv.h > > create mode 100644 xen/include/public/arch-riscv/hvm/save.h > > > > -- > > 2.25.0 > > > > The source code can be found on github: > > https://github.com/beshleman/xen/tree/port-to-risc-v > > > > The patchset only targets the QEMU virt board and it is tested on > > Alistair Francis's patchset for QEMU with RISC-V hypervisor extensions > > v0.5, found here: > > https://github.com/alistair23/qemu/tree/mainline/alistair/riscv-hyp-ext-v0.5.next > > > > QEMU is built with: > > git clone --single-branch --branch mainline/alistair/riscv-hyp-ext-v0.5.next \ > > https://github.com/alistair23/qemu.git > > cd qemu > > mkdir build && cd build > > ../configure --target-list=riscv64-softmmu > > make -j$(nproc) && make install > > > > The bootloader used is the standard OpenSBI, built with the command: > > CROSS_COMPILE=riscv64-unknown-linux-gnu- PLATFORM=qemu/virt FW_PAYLOAD_PATH=../xen/xen/xen make > > > > Xen/RISC-V is built with: > > XEN_TARGET_ARCH=riscv64 CROSS_COMPILE=riscv64-unknown-linux-gnu- make build > > > > Xen may be ran with the following command: > > qemu-system-riscv64 -cpu rv64,x-h=true -M virt -m 512M -display none \ > > -serial stdio -kernel \ > > opensbi/build/platform/qemu/virt/firmware/fw_payload.elf > > > > Also, shoutout to Alistair Francis (from Western Digital) for getting > > the ball rolling and doing a ton of the groundwork with > > Makefile/Kconfig, a ton of the RISC-V specific header files, and also > > the QEMU RISC-V H extension support, and Dan Robertson (a colleague of > > mine at Star Lab) for help in forward porting a number of patches that > > were out-of-sync with upstream. > > > > > > Thanks, > > Bobby Eshleman > > > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:10:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:10:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl07N-00012o-RW; Tue, 16 Jun 2020 01:10:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl07L-00012i-MS for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:10:24 +0000 X-Inumbo-ID: 269803ca-af6e-11ea-b862-12813bfff9fa Received: from esa5.hgst.iphmx.com (unknown [216.71.153.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 269803ca-af6e-11ea-b862-12813bfff9fa; Tue, 16 Jun 2020 01:10:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1592269823; x=1623805823; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5efqvFhZ8WouspRqtLE3W8kfJUXr5lsoD3nudDXpXuY=; b=mwW46yVD058C4DoyKMsF77zplckVtKvzsXrlU6oSaiirLPQNUe+Q+9+U Y/X6yp1qoCBJivtNu8mxITvzad0sFSJc6LGWR1P92vlaWbXmEGAVauzBq NcHYdETafyaiLzmJb+nrTKUkptT4c36h7eMf+B9H7vvqB0W9lWTm9EckA tIBbJdqYpA2FmoqvvA15vgKvVYzF4vKT8+gYzneN78gfKFpDW0mOuyowe rVOX2jio/1vdnzUGt6sp5fymUI0fKamElPWzQ2nP9wcI1BZ04c2yaIHvh QUWOwIW3Bwsb6FIui041AFNZeTOzoINd4rzJcw7GR9tBXx6csJezM/LKp A==; IronPort-SDR: gjeNMpbVxV0TDvcX3mLqNES58YSelntVfato3zzPGQAGWVYzkIi/JrWKGwcr/5FYPPdYJAIZhY fhW2I5Ci9U7+nWfIR81ffgCl4HkIdCpXkisbXmhbIBaZpWHxoAHseb9FiOlnyweWKWDBd8AvS5 k6V2gJrIGyw3zpTXk9ZH3RnFPQJ+Q37j0InvZCIEuhEE/PIwCqTYDq8GOTkI5tSeCTjVhukLHp GKv5FreH/22pW4Wt8W0T2wmTBEYq5P/Bxto6kG4GSsj6MNc32T2+90+bdEK+qZoPIU1mSGJMLv yF8= X-IronPort-AV: E=Sophos;i="5.73,516,1583164800"; d="scan'208";a="140346942" Received: from mail-bn8nam11lp2176.outbound.protection.outlook.com (HELO NAM11-BN8-obe.outbound.protection.outlook.com) ([104.47.58.176]) by ob1.hgst.iphmx.com with ESMTP; 16 Jun 2020 09:10:20 +0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SvyPyhfvyhFBW5Lo3+udSmZ5Brg1JHom9XyG8a+E3nF/7ACRrjX0FFWOxMavL8EdIO2I0IOPaGdNqyBT8Kno8zX7b86sBLf2sff3uhTJTT1Hb3kpMPIVEtNglAPqrYagxl5xxmaGrkSMwHvz6fe33Ax6WkTlLtKQxP3qwEu8jO+KtdCO55FG64SylCDZOUdDVkzWzMSfwxxOBVCVAZCcnJXmp713SiUxN947zuNlqup6/hplPMsjy0p9AeovmnbjVLP++wryamr6YaRsyiOae/+yr/AWPaMNQCli5y/ezHWHXyKhKdXV9TWpYPm3BZnYzkUHihgLpb5feEzWGXr/Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5efqvFhZ8WouspRqtLE3W8kfJUXr5lsoD3nudDXpXuY=; b=k7oqG8EpMKlnIgP6Ty5jFHEvYy7eJDLLAK/UdJMLou/QzWxJNmuSGCmZemTQMz1Nj0yroVplrWKo0IZRokyA+Y3T9NGqVAT8dHNZbdZkGPGVgihGGSB9r21EExQFQkhwTPfSHrzSk4a2KThIdF5dXCm8/L+ff9fcrruXxumITaFN8lmlmPvbxfdX1hgonLsK+qQbVS0nm+QCV2tX7i39h7kFBvfPKJ65oDl90RUpXjGbyB129LMHim5eIIQ028Lp5J/+2G5etxI19+oBqKycnX6OPDJLEJfGnuRGT/99KaN+rBcFO4R4Oui3attayVjzTcF9fcx5VTWTIDyLm/PgQQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wdc.com; dmarc=pass action=none header.from=wdc.com; dkim=pass header.d=wdc.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharedspace.onmicrosoft.com; s=selector2-sharedspace-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5efqvFhZ8WouspRqtLE3W8kfJUXr5lsoD3nudDXpXuY=; b=am14mYlFoKNi1yH9ZE317kwe5dwFbPRVZRvCzRJSwChPLpoW2qMw841KHStsU4E24pPo7V4idtiWgcmlNs88flCrMdS94IDiehcpQaUy9GK6aY5uWYfyMFlWRX8ICvnFLcAOVU+k+9knV9dQ8b14PhA85ux7JTxbTZFoAMHjOw4= Received: from BY5PR04MB6882.namprd04.prod.outlook.com (2603:10b6:a03:21b::19) by BYAPR04MB4805.namprd04.prod.outlook.com (2603:10b6:a03:5f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Tue, 16 Jun 2020 01:10:18 +0000 Received: from BY5PR04MB6882.namprd04.prod.outlook.com ([fe80::5d51:59b1:8272:23fa]) by BY5PR04MB6882.namprd04.prod.outlook.com ([fe80::5d51:59b1:8272:23fa%6]) with mapi id 15.20.3088.029; Tue, 16 Jun 2020 01:10:17 +0000 From: Alistair Francis To: "bobbyeshleman@gmail.com" , "sstabellini@kernel.org" Subject: Re: [RFC XEN PATCH 00/23] xen: beginning support for RISC-V Thread-Topic: [RFC XEN PATCH 00/23] xen: beginning support for RISC-V Thread-Index: AQHV0MezYzwz2WaUv0S6mwDeUU8q0qjbUjOA////h4A= Date: Tue, 16 Jun 2020 01:10:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Evolution 3.36.3 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=wdc.com; x-originating-ip: [2601:646:8e00:37b2:f615:7f83:6835:448a] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ba20d21d-301d-4d67-03da-08d811920893 x-ms-traffictypediagnostic: BYAPR04MB4805: x-microsoft-antispam-prvs: wdcipoutbound: EOP-TRUE x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 04362AC73B x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QKQfYmPLFaJj4k9tddECk9WMexzCKy/8EuFSd2oLOz2QIJ5SI1YoD2E0mCBOSjA/mTHHfDE2COlJtlzWbaziljJ6znFkrEKGGMe1xyGkLjsyVlGyexPjL12VjvfZVuMOlAWuAORWq4Ni8tlf9uA5aVpo4nXirr3qTNji+OeQyeo+zuLFg0iT05VfcPVpuKMVIVzveFf7boxduc+xbZKYPlBrVu5kim2RcuOE6VZfeTSouz3ZSWhPzSlxMhkMihFLQ813tBeVAPH4mk+iVwrN2m9AERS9me0ewuhxWRQUCNMDvpVYvxDKNxxKQo16+E4y+/RtveoWB9hjOTupHTr8N0fvMxeTELo5ksECOYQiOTF+5SM5G3sbkxYH3vV/FzKI/uNKFIJsKbbcGJqsyB3v5g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR04MB6882.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(396003)(136003)(366004)(376002)(316002)(2616005)(54906003)(36756003)(4326008)(6506007)(5660300002)(8936002)(478600001)(186003)(110136005)(30864003)(8676002)(71200400001)(966005)(83380400001)(6512007)(7416002)(2906002)(64756008)(66946007)(76116006)(86362001)(66476007)(66556008)(66446008)(6486002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: nvPNBZXZBZvEE3BwG/nT3+AVlBcO003nbr84JQbPqAtG2CmnfORhn3xZzoJz6Iy8lgj/qekERYJzyDo0ETdbLEnA6TpyiGajwHZK9fsOKLeEzgFnTbqdUHZxJJIk+FWbV/PoeReOKkpRgUp85iMPEKHF9SRiy6HiSWCRjfHY5Hhrf1Z3+uIqJfJHNZT6sNH6BckI/FrwYBA0cRJxXwBZhJIYhI3o2SmnHz8FFb0ANQk1R2TPmVjVFuIlqRLTZP6PUMKQ+kRMO/MI3udwWZzpYcQEzZBw6s0XxRGPr5Q1SWp9sbduguVWU9sFFyaBnHZPBjh8uQV86/qYdmRDsJsUNUu1DYI6W/GNZgxFD6TPbRCk7KT46roIMTw1w7/GCKyco82/2TRGFJQodLGY2CRNVczzx9lKDUQHisewjiLQbka0F1yMqNNL0c8nLFXYzL3d8MAWJeUvV1lf3dCyhLYbV1FW7PcqzZllZTaGGHleWKgyNm8QGsv2VLm9NUQuGcKpfnDELPKltDQNQzvNpELI+HfbAt+St0VoaygmebJJVJTVhY88ePeci/kU4JS2JpEb x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <82C5FF5A8B2DF14D9C3F808F06DEB45E@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: wdc.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba20d21d-301d-4d67-03da-08d811920893 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2020 01:10:17.7858 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rVIV3h4TLXVPP3CECcYuERU12KczPak8XB+c+6s4ZMgttD5lCZVuprMmoldSosoCKTiVGheN2amVN0NM7mAVwYBNzBuyF6DVjrqZ1/U/Ui8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB4805 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "dan@dlrobertson.com" , "julien@xen.org" , "wl@xen.org" , "konrad.wilk@oracle.com" , "George.Dunlap@eu.citrix.com" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "bobby.eshleman@starlab.io" , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gTW9uLCAyMDIwLTA2LTE1IGF0IDE4OjAzIC0wNzAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3Jv dGU6DQo+IEFueSB1cGRhdGVzPyBJIGFtIGxvb2tpbmcgZm9yd2FyZCB0byB0aGlzIDotKQ0KDQpG WUksIEkgd291bGQgbGlrZSB0byB0YWxrIG1vcmUgYWJvdXQgUklTQy1WIFhlbiBhdCB0aGUgWGVu IFZpcnR1YWwNCnN1bW1pdC4gSSdsbCBwdXQgaXQgZm9yd2FyZCBhcyBhIEJvRiBzdWJqZWN0Lg0K DQpJIGhhdmVuJ3Qgd29ya2VkIG9uIHRoaXMsIGFsdGhvdWdoIHRoZSBSSVNDLVYgSHlwZXJ2aXNv ciBzcGVjIGlzDQpwcm9ncmVzc2luZyB0b3dhcmRzIHJhdGlmaWNhdGlvbi4NCg0KQWxpc3RhaXIN Cg0KPiANCj4gDQo+IE9uIFR1ZSwgMjEgSmFuIDIwMjAsIEJvYmJ5IEVzaGxlbWFuIHdyb3RlOg0K PiA+IEhleSBldmVyeWJvZHksDQo+ID4gDQo+ID4gVGhpcyBpcyBhbiBSRkMgcGF0Y2hzZXQgZm9y IHRoZSB2ZXJ5IGJlZ2lubmluZ3Mgb2YgYWRkaW5nIFJJU0MtVg0KPiA+IHN1cHBvcnQNCj4gPiB0 byBYZW4uICBUaGlzIFJGQyBpcyByZWFsbHkganVzdCB0byBzdGFydCBhIGRpYWxvZ3VlIGFib3V0 DQo+ID4gc3VwcG9ydGluZw0KPiA+IFJJU0MtViBhbmQgYWxpZ24gd2l0aCB0aGUgWGVuIHByb2pl Y3QgYW5kIGNvbW11bml0eSBiZWZvcmUgZ29pbmcNCj4gPiBmdXJ0aGVyLiAgRm9yIHRoYXQgcmVh c29uLCBpdCBpcyB2ZXJ5IHJvdWdoIGFuZCB2ZXJ5IGluY29tcGxldGUuIA0KPiA+IA0KPiA+IE15 IG5hbWUgaXMgQm9iYnkgRXNobGVtYW4sIEknbSBhIHNvZnR3YXJlIGVuZ2luZWVyIGF0DQo+ID4g U3RhciBMYWIgLyBXaW5kIFJpdmVyIG9uIHRoZSBBUk0gdGVhbSwgbW9zdGx5IGhhdmluZyB3b3Jr ZWQgaW4gdGhlDQo+ID4gTGludXgNCj4gPiBrZXJuZWwuICBJJ3ZlIGFsc28gYmVlbiBpbnZvbHZl ZCBhIGdvb2QgYW1vdW50IHdpdGggWGVuIG9uIEFSTQ0KPiA+IGhlcmUsDQo+ID4gbW9zdGx5IGRl YWxpbmcgd2l0aCB0b29saW5nLCBkZXBsb3ltZW50LCBhbmQgdGVzdGluZy4gIEEgbG90IG9mDQo+ ID4gdGhpcw0KPiA+IHBhdGNoc2V0IGlzIGhlYXZpbHkgaW5zcGlyZWQgYnkgdGhlIFhlbi9BUk0g c291cmNlIGNvZGUNCj4gPiAocGFydGljdWxhcmx5DQo+ID4gdGhlIGVhcmx5IHNldHVwIHVwIGNv ZGUpLg0KPiA+IA0KPiA+IEN1cnJlbnRseSwgdGhpcyBwYXRjaHNldCByZWFsbHkgb25seSBzZXRz IHVwIHZpcnR1YWwgbWVtb3J5IGZvciBYZW4NCj4gPiBhbmQNCj4gPiBpbml0aWFsaXplcyBVQVJU IHRvIGVuYWJsZSBwcmludCBvdXRwdXQuICBOb25lIG9mIFJJU0MtVidzDQo+ID4gdmlydHVhbGl6 YXRpb24gc3VwcG9ydCBoYXMgYmVlbiBpbXBsZW1lbnRlZCB5ZXQsIGFsdGhvdWdoIHRoYXQgaXMN Cj4gPiB0aGUNCj4gPiBuZXh0IHJvYWQgdG8gc3RhcnQgZ29pbmcgZG93bi4gIE1hbnkgZnVuY3Rp b25zIG9ubHkgY29udGFpbiBkdW1teQ0KPiA+IGltcGxlbWVudGF0aW9ucy4gIE1hbnkgc2hvcnRj dXRzIGhhdmUgYmVlbiB0YWtlbiBhbmQgVE9ETydzIGhhdmUNCj4gPiBiZWVuDQo+ID4gbGVmdCBh Y2NvcmRpbmdseS4gIEl0IGlzIHZlcnksIHZlcnkgcm91Z2guICBCZSBmb3Jld2FybmVkOiB5b3Ug YXJlDQo+ID4gcXVpdGUNCj4gPiBsaWtlbHkgdG8gc2VlIHNvbWUgdW5nYWlubHkgY29kZSBoZXJl IChkZXNwaXRlIG15IGVmZm9ydHMgdG8gY2xlYW4NCj4gPiBpdCB1cA0KPiA+IGJlZm9yZSBzZW5k aW5nIHRoaXMgcGF0Y2hzZXQgb3V0KS4gIE15IGludGVudCB3aXRoIHRoaXMgUkZDIGlzIHRvDQo+ ID4gYWxpZ24NCj4gPiBlYXJseSBhbmQgZ2F1Z2UgaW50ZXJlc3QsIGFzIG9wcG9zZWQgdG8gcHJl c2VudGluZyBhIHRvdGFsbHkNCj4gPiBjb21wbGV0ZQ0KPiA+IHBhdGNoc2V0Lg0KPiA+IA0KPiA+ IEJlY2F1c2UgdGhlIEFSTSBhbmQgUklTQy1WIHVzZSBjYXNlcyB3aWxsIGxpa2VseSBiZWFyIHJl c2VtYmxhbmNlLA0KPiA+IHRoZQ0KPiA+IFJJU0MtViBwb3J0IHNob3VsZCBwcm9iYWJseSByZXNw ZWN0IHRoZSBkZXNpZ24gY29uc2lkZXJhdGlvbnMgdGhhdA0KPiA+IGhhdmUNCj4gPiBiZWVuIGxh aWQgb3V0IGFuZCByZXNwZWN0ZWQgYnkgWGVuIG9uIEFSTSBmb3IgZG9tMGxlc3MsIHNhZmV0eQ0K PiA+IGNlcnRpZmljYXRpb24sIGV0Yy4uLiAgTXkgaW5jbGluYXRpb24gaGFzIGJlZW4gdG8gaW5p dGlhbGx5IHRhcmdldA0KPiA+IG9yDQo+ID4gcHJpb3JpdGl6ZSBkb20wbGVzcyAod2l0aG91dCBl eGNsdWRpbmcgZG9tMGZ1bGwpIGFuZCB1c2UgdGhlIEFSTQ0KPiA+IGRvbTBsZXNzIGltcGxlbWVu dGF0aW9uIGFzIGEgbW9kZWwgdG8gZm9sbG93LiAgSSdkIGxvdmUgZmVlZGJhY2sgb24NCj4gPiB0 aGlzDQo+ID4gcG9pbnQgYW5kIG9uIGhvdyB0aGUgWGVuIHByb2plY3QgbWlnaHQgZW52aXNpb24g YSBSSVNDLVYNCj4gPiBpbXBsZW1lbnRhdGlvbi4NCj4gPiANCj4gPiBUaGlzIHBhdGNoc2V0IGhh cyBfc29tZV8gY29kZSBmb3IgZnV0dXJlIHN1cHBvcnQgZm9yIDMyLWJpdCwgYnV0DQo+ID4gY3Vy cmVudGx5IG15IGZvY3VzIGlzIG9uIDY0LWJpdC4NCj4gPiANCj4gPiBBZ2FpbiwgdGhpcyBpcyBh IHZlcnksIHZlcnkgcm91Z2ggYW5kIHRvdGFsbHkgaW5jb21wbGV0ZQ0KPiA+IHBhdGNoc2V0LiAg TXkNCj4gPiBnb2FsIGhlcmUgaXMganVzdCB0byBnYXVnZSBjb21tdW5pdHkgaW50ZXJlc3QsIGJl Z2luIGRpc2N1c3NpbmcNCj4gPiB3aGF0IFhlbg0KPiA+IG9uIFJJU0MtViBtYXkgbG9vayBsaWtl LCByZWNlaXZlIGZlZWRiYWNrLCBhbmQgc2VlIGlmIEknbSBoZWFkaW5nDQo+ID4gaW4gdGhlDQo+ ID4gcmlnaHQgZGlyZWN0aW9uLg0KPiA+IA0KPiA+IE15IGJpZyBxdWVzdGlvbnMgYXJlOg0KPiA+ IAlEb2VzIHRoZSBYZW4gcHJvamVjdCBoYXZlIGludGVyZXN0IGluIFJJU0MtVj8NCj4gPiAJV2hh dCBjYW4gYmUgZG9uZSB0byBtYWtlIHRoZSBSSVNDLVYgcG9ydCBhcyB1cHN0cmVhbWFibGUgYXMN Cj4gPiAJCXBvc3NpYmxlPw0KPiA+IAlBbnkgbWFqb3IgcGl0ZmFsbHM/DQo+ID4gDQo+ID4gSXQg d291bGQgYmUgZ3JlYXQgdG8gaGVhciBhbGwgb2YgeW91ciBmZWVkYmFjay4NCj4gPiANCj4gPiBB bGlzdGFpciBGcmFuY2lzICgyMCk6DQo+ID4gICBIQUNLOiBPRSBCdWlsZCBjaGFuZ2VzDQo+ID4g ICBIQUNLOiBNYWtlZmlsZTogRG9uJ3QgYnVpbGQgWGVuIHRvb2xzDQo+ID4gICByaXNjdjogbWFr ZWZpbGVzIGFuZCBLY29uZmlnDQo+ID4gICByaXNjdjogQWRkIHJpc2N2IHRvIHRvb2xzL2xpYnhj IGhlYWRlciBmaWxlcw0KPiA+ICAgcmlzY3Y6IEFkZCBhc20tb2Zmc2V0cy5jDQo+ID4gICByaXNj djogQWRkIGRlbGF5LmMNCj4gPiAgIHJpc2N2OiBBZGQgZG9tYWluLmMNCj4gPiAgIHJpc2N2OiBB ZGQgZG9tY3RsLmMNCj4gPiAgIHJpc2N2OiBBZGQgZ3Vlc3Rjb3B5LmMNCj4gPiAgIHJpc2N2OiBB ZGQgdGltZS5jDQo+ID4gICByaXNjdjogQWRkIHNtcC5jDQo+ID4gICByaXNjdjogQWRkIHNodXRk b3duLmMNCj4gPiAgIHJpc2N2OiBBZGQgdHJhcHMuYw0KPiA+ICAgcmlzY3Y6IEFkZCBpcnEuYw0K PiA+ICAgcmlzY3Y6IEFkZCB2bV9ldmVudC5jDQo+ID4gICByaXNjdjogQWRkIHAybS5jDQo+ID4g ICByaXNjdjogQWRkIHRoZSBsaWIgZGlyZWN0b3J5DQo+ID4gICByaXNjdjogQWRkIHNtcGJvb3Qu Yw0KPiA+ICAgcmlzY3Y6IEFkZCBwZXJjcHUuYw0KPiA+ICAgcmlzY3Y6IEFkZCBzeXNjdGwuYw0K PiA+IA0KPiA+IEJvYmJ5IEVzaGxlbWFuICgzKToNCj4gPiAgIHJpc2N2OiBoZWFkZXIgZmlsZXMN Cj4gPiAgIHJpc2N2OiBlYXJseSBzZXR1cCBjb2RlDQo+ID4gICByaXNjdjogQWRkIGlvbW11LmMN Cj4gPiANCj4gPiAgTWFrZWZpbGUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAx MyArLQ0KPiA+ICBjb25maWcvU3RkR05VLm1rICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDEy ICstDQo+ID4gIGNvbmZpZy9yaXNjdjY0Lm1rICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDcg Kw0KPiA+ICB0b29scy9jb25maWd1cmUgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDMyICst DQo+ID4gIHRvb2xzL2Zpcm13YXJlL01ha2VmaWxlICAgICAgICAgICAgICAgICAgfCAgMTIgKy0N Cj4gPiAgdG9vbHMvbGlieGMvaW5jbHVkZS94ZW5jdHJsLmggICAgICAgICAgICB8ICAgNyArDQo+ ID4gIHRvb2xzL2xpYnhjL3hjX2NvcmUuaCAgICAgICAgICAgICAgICAgICAgfCAgIDIgKw0KPiA+ ICB0b29scy9saWJ4Yy94Y19jb3JlX3Jpc2N2LmggICAgICAgICAgICAgIHwgIDU3ICsrDQo+ID4g IHhlbi9NYWtlZmlsZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIDIgKy0NCj4gPiAg eGVuL1J1bGVzLm1rICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgMiArLQ0KPiA+ICB4 ZW4vYXJjaC9LY29uZmlnICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAxICsNCj4gPiAgeGVu L2FyY2gvcmlzY3YvS2NvbmZpZyAgICAgICAgICAgICAgICAgICB8ICAzNiArDQo+ID4gIHhlbi9h cmNoL3Jpc2N2L01ha2VmaWxlICAgICAgICAgICAgICAgICAgfCAgNjIgKysNCj4gPiAgeGVuL2Fy Y2gvcmlzY3YvUnVsZXMubWsgICAgICAgICAgICAgICAgICB8ICA1NSArKw0KPiA+ICB4ZW4vYXJj aC9yaXNjdi9hc20tb2Zmc2V0cy5jICAgICAgICAgICAgIHwgIDM4ICsNCj4gPiAgeGVuL2FyY2gv cmlzY3YvY29uZmlncy9yaXNjdjMyX2RlZmNvbmZpZyB8ICAgMA0KPiA+ICB4ZW4vYXJjaC9yaXNj di9jb25maWdzL3Jpc2N2NjRfZGVmY29uZmlnIHwgICAwDQo+ID4gIHhlbi9hcmNoL3Jpc2N2L2Rl bGF5LmMgICAgICAgICAgICAgICAgICAgfCAxMTQgKysrDQo+ID4gIHhlbi9hcmNoL3Jpc2N2L2Rv bWFpbi5jICAgICAgICAgICAgICAgICAgfCAyNzMgKysrKysrKw0KPiA+ICB4ZW4vYXJjaC9yaXNj di9kb21jdGwuYyAgICAgICAgICAgICAgICAgIHwgIDUzICsrDQo+ID4gIHhlbi9hcmNoL3Jpc2N2 L2d1ZXN0Y29weS5jICAgICAgICAgICAgICAgfCAxNTggKysrKw0KPiA+ICB4ZW4vYXJjaC9yaXNj di9oZWFkLlMgICAgICAgICAgICAgICAgICAgIHwgMTgwICsrKysrDQo+ID4gIHhlbi9hcmNoL3Jp c2N2L2lycS5jICAgICAgICAgICAgICAgICAgICAgfCAxMDcgKysrDQo+ID4gIHhlbi9hcmNoL3Jp c2N2L2xpYi9NYWtlZmlsZSAgICAgICAgICAgICAgfCAgIDEgKw0KPiA+ICB4ZW4vYXJjaC9yaXNj di9saWIvZmluZF9uZXh0X2JpdC5jICAgICAgIHwgMjg0ICsrKysrKysNCj4gPiAgeGVuL2FyY2gv cmlzY3YvbW0uYyAgICAgICAgICAgICAgICAgICAgICB8IDkyNQ0KPiA+ICsrKysrKysrKysrKysr KysrKysrKysrDQo+ID4gIHhlbi9hcmNoL3Jpc2N2L3AybS5jICAgICAgICAgICAgICAgICAgICAg fCAyNjEgKysrKysrKw0KPiA+ICB4ZW4vYXJjaC9yaXNjdi9wZXJjcHUuYyAgICAgICAgICAgICAg ICAgIHwgIDg0ICsrDQo+ID4gIHhlbi9hcmNoL3Jpc2N2L3BsYXRmb3Jtcy9LY29uZmlnICAgICAg ICAgfCAgMzEgKw0KPiA+ICB4ZW4vYXJjaC9yaXNjdi9zZXR1cC5jICAgICAgICAgICAgICAgICAg IHwgMTIyICsrKw0KPiA+ICB4ZW4vYXJjaC9yaXNjdi9zaHV0ZG93bi5jICAgICAgICAgICAgICAg IHwgIDI0ICsNCj4gPiAgeGVuL2FyY2gvcmlzY3Yvc21wLmMgICAgICAgICAgICAgICAgICAgICB8 ICA0MSArDQo+ID4gIHhlbi9hcmNoL3Jpc2N2L3NtcGJvb3QuYyAgICAgICAgICAgICAgICAgfCAx MTQgKysrDQo+ID4gIHhlbi9hcmNoL3Jpc2N2L3N5c2N0bC5jICAgICAgICAgICAgICAgICAgfCAg MzEgKw0KPiA+ICB4ZW4vYXJjaC9yaXNjdi90aW1lLmMgICAgICAgICAgICAgICAgICAgIHwgIDc0 ICsrDQo+ID4gIHhlbi9hcmNoL3Jpc2N2L3RyYXBzLmMgICAgICAgICAgICAgICAgICAgfCAgNTYg KysNCj4gPiAgeGVuL2FyY2gvcmlzY3Yvdm1fZXZlbnQuYyAgICAgICAgICAgICAgICB8ICA0MiAr DQo+ID4gIHhlbi9hcmNoL3Jpc2N2L3hlbi5sZHMuUyAgICAgICAgICAgICAgICAgfCAyNjIgKysr KysrKw0KPiA+ICB4ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9NYWtlZmlsZSAgICAgICAgIHwgICAx ICsNCj4gPiAgeGVuL2RyaXZlcnMvcGFzc3Rocm91Z2gvcmlzY3YvTWFrZWZpbGUgICB8ICAgMSAr DQo+ID4gIHhlbi9kcml2ZXJzL3Bhc3N0aHJvdWdoL3Jpc2N2L2lvbW11LmMgICAgfCAgNzQgKysN Cj4gPiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L2FsdHAybS5oICAgICAgICAgICB8ICAzOSArDQo+ ID4gIHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9hc20uaCAgICAgICAgICAgICAgfCAgNzYgKysNCj4g PiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L2F0b21pYy5oICAgICAgICAgICB8IDI0OSArKysrKysN Cj4gPiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L2JpdG9wcy5oICAgICAgICAgICB8IDMzMSArKysr KysrKw0KPiA+ICB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvYnVnLmggICAgICAgICAgICAgIHwgIDU5 ICsrDQo+ID4gIHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9ieXRlb3JkZXIuaCAgICAgICAgfCAgMTYg Kw0KPiA+ICB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvY2FjaGUuaCAgICAgICAgICAgIHwgIDI0ICsN Cj4gPiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L2NtcHhjaGcuaCAgICAgICAgICB8IDM4MiArKysr KysrKysrDQo+ID4gIHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9jb25maWcuaCAgICAgICAgICAgfCAy MDMgKysrKysNCj4gPiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L2Nzci5oICAgICAgICAgICAgICB8 IDExNyArKysNCj4gPiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L2N1cnJlbnQuaCAgICAgICAgICB8 ICA1MCArKw0KPiA+ICB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvZGVidWdnZXIuaCAgICAgICAgIHwg IDE1ICsNCj4gPiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L2RlbGF5LmggICAgICAgICAgICB8ICAy OCArDQo+ID4gIHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9kZXNjLmggICAgICAgICAgICAgfCAgMTIg Kw0KPiA+ICB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvZGV2aWNlLmggICAgICAgICAgIHwgIDE1ICsN Cj4gPiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L2RpdjY0LmggICAgICAgICAgICB8ICAyMyArDQo+ ID4gIHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9kb21haW4uaCAgICAgICAgICAgfCAgODUgKysrDQo+ ID4gIHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9ldmVudC5oICAgICAgICAgICAgfCAgNDIgKw0KPiA+ ICB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvZmVuY2UuaCAgICAgICAgICAgIHwgIDEyICsNCj4gPiAg eGVuL2luY2x1ZGUvYXNtLXJpc2N2L2ZsdXNodGxiLmggICAgICAgICB8ICA1NiArKw0KPiA+ICB4 ZW4vaW5jbHVkZS9hc20tcmlzY3YvZ3JhbnRfdGFibGUuaCAgICAgIHwgIDkzICsrKw0KPiA+ICB4 ZW4vaW5jbHVkZS9hc20tcmlzY3YvZ3Vlc3RfYWNjZXNzLmggICAgIHwgMTY0ICsrKysNCj4gPiAg eGVuL2luY2x1ZGUvYXNtLXJpc2N2L2d1ZXN0X2F0b21pY3MuaCAgICB8ICA2MiArKw0KPiA+ICB4 ZW4vaW5jbHVkZS9hc20tcmlzY3YvaGFyZGlycS5oICAgICAgICAgIHwgIDI3ICsNCj4gPiAgeGVu L2luY2x1ZGUvYXNtLXJpc2N2L2h5cGVyY2FsbC5oICAgICAgICB8ICAxMiArDQo+ID4gIHhlbi9p bmNsdWRlL2FzbS1yaXNjdi9pbml0LmggICAgICAgICAgICAgfCAgNDIgKw0KPiA+ICB4ZW4vaW5j bHVkZS9hc20tcmlzY3YvaW8uaCAgICAgICAgICAgICAgIHwgMjgzICsrKysrKysNCj4gPiAgeGVu L2luY2x1ZGUvYXNtLXJpc2N2L2lvY2FwLmggICAgICAgICAgICB8ICAxNiArDQo+ID4gIHhlbi9p bmNsdWRlL2FzbS1yaXNjdi9pb21tdS5oICAgICAgICAgICAgfCAgNDkgKysNCj4gPiAgeGVuL2lu Y2x1ZGUvYXNtLXJpc2N2L2lycS5oICAgICAgICAgICAgICB8ICA1OCArKw0KPiA+ICB4ZW4vaW5j bHVkZS9hc20tcmlzY3YvbWVtX2FjY2Vzcy5oICAgICAgIHwgIDM1ICsNCj4gPiAgeGVuL2luY2x1 ZGUvYXNtLXJpc2N2L21tLmggICAgICAgICAgICAgICB8IDMwOCArKysrKysrKw0KPiA+ICB4ZW4v aW5jbHVkZS9hc20tcmlzY3YvbW9uaXRvci5oICAgICAgICAgIHwgIDY1ICsrDQo+ID4gIHhlbi9p bmNsdWRlL2FzbS1yaXNjdi9ub3NwZWMuaCAgICAgICAgICAgfCAgMjUgKw0KPiA+ICB4ZW4vaW5j bHVkZS9hc20tcmlzY3YvbnVtYS5oICAgICAgICAgICAgIHwgIDQxICsNCj4gPiAgeGVuL2luY2x1 ZGUvYXNtLXJpc2N2L3AybS5oICAgICAgICAgICAgICB8IDQxMCArKysrKysrKysrDQo+ID4gIHhl bi9pbmNsdWRlL2FzbS1yaXNjdi9wYWdlLmggICAgICAgICAgICAgfCAzMjcgKysrKysrKysNCj4g PiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3BhZ2luZy5oICAgICAgICAgICB8ICAxNiArDQo+ID4g IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9wY2kuaCAgICAgICAgICAgICAgfCAgMzEgKw0KPiA+ICB4 ZW4vaW5jbHVkZS9hc20tcmlzY3YvcGVyY3B1LmggICAgICAgICAgIHwgIDM0ICsNCj4gPiAgeGVu L2luY2x1ZGUvYXNtLXJpc2N2L3BndGFibGUtYml0cy5oICAgICB8ICA1MyArKw0KPiA+ICB4ZW4v aW5jbHVkZS9hc20tcmlzY3YvcHJvY2Vzc29yLmggICAgICAgIHwgIDYwICsrDQo+ID4gIHhlbi9p bmNsdWRlL2FzbS1yaXNjdi9yYW5kb20uaCAgICAgICAgICAgfCAgIDkgKw0KPiA+ICB4ZW4vaW5j bHVkZS9hc20tcmlzY3YvcmVncy5oICAgICAgICAgICAgIHwgIDQyICsNCj4gPiAgeGVuL2luY2x1 ZGUvYXNtLXJpc2N2L3Jpc2N2X2VuY29kaW5nLmggICB8IDY4MiArKysrKysrKysrKysrKysrKw0K PiA+ICB4ZW4vaW5jbHVkZS9hc20tcmlzY3Yvc2V0dXAuaCAgICAgICAgICAgIHwgIDE2ICsNCj4g PiAgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3NtcC5oICAgICAgICAgICAgICB8ICA1MCArKw0KPiA+ ICB4ZW4vaW5jbHVkZS9hc20tcmlzY3Yvc29mdGlycS5oICAgICAgICAgIHwgIDE2ICsNCj4gPiAg eGVuL2luY2x1ZGUvYXNtLXJpc2N2L3NwaW5sb2NrLmggICAgICAgICB8ICAxMyArDQo+ID4gIHhl bi9pbmNsdWRlL2FzbS1yaXNjdi9zdHJpbmcuaCAgICAgICAgICAgfCAgMjggKw0KPiA+ICB4ZW4v aW5jbHVkZS9hc20tcmlzY3Yvc3lzcmVncy5oICAgICAgICAgIHwgIDE0ICsNCj4gPiAgeGVuL2lu Y2x1ZGUvYXNtLXJpc2N2L3N5c3RlbS5oICAgICAgICAgICB8ICA5NiArKysNCj4gPiAgeGVuL2lu Y2x1ZGUvYXNtLXJpc2N2L3RpbWUuaCAgICAgICAgICAgICB8ICA2MCArKw0KPiA+ICB4ZW4vaW5j bHVkZS9hc20tcmlzY3YvdHJhY2UuaCAgICAgICAgICAgIHwgIDEyICsNCj4gPiAgeGVuL2luY2x1 ZGUvYXNtLXJpc2N2L3R5cGVzLmggICAgICAgICAgICB8ICA3MyArKw0KPiA+ICB4ZW4vaW5jbHVk ZS9hc20tcmlzY3Yvdm1fZXZlbnQuaCAgICAgICAgIHwgIDYxICsrDQo+ID4gIHhlbi9pbmNsdWRl L2FzbS1yaXNjdi94ZW5vcHJvZi5oICAgICAgICAgfCAgMTIgKw0KPiA+ICB4ZW4vaW5jbHVkZS9w dWJsaWMvYXJjaC1yaXNjdi5oICAgICAgICAgIHwgMTgxICsrKysrDQo+ID4gIHhlbi9pbmNsdWRl L3B1YmxpYy9hcmNoLXJpc2N2L2h2bS9zYXZlLmggfCAgMzkgKw0KPiA+ICB4ZW4vaW5jbHVkZS9w dWJsaWMvaHZtL3NhdmUuaCAgICAgICAgICAgIHwgICAyICsNCj4gPiAgeGVuL2luY2x1ZGUvcHVi bGljL3BtdS5oICAgICAgICAgICAgICAgICB8ICAgMiArDQo+ID4gIHhlbi9pbmNsdWRlL3B1Ymxp Yy94ZW4uaCAgICAgICAgICAgICAgICAgfCAgIDIgKw0KPiA+ICAxMDMgZmlsZXMgY2hhbmdlZCwg OTA2NCBpbnNlcnRpb25zKCspLCA0MiBkZWxldGlvbnMoLSkNCj4gPiAgY3JlYXRlIG1vZGUgMTAw NjQ0IGNvbmZpZy9yaXNjdjY0Lm1rDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB0b29scy9saWJ4 Yy94Y19jb3JlX3Jpc2N2LmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL3Jpc2N2 L0tjb25maWcNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL3Jpc2N2L01ha2VmaWxl DQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9yaXNjdi9SdWxlcy5taw0KPiA+ICBj cmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvcmlzY3YvYXNtLW9mZnNldHMuYw0KPiA+ICBjcmVh dGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvcmlzY3YvY29uZmlncy9yaXNjdjMyX2RlZmNvbmZpZw0K PiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvcmlzY3YvY29uZmlncy9yaXNjdjY0X2Rl ZmNvbmZpZw0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvcmlzY3YvZGVsYXkuYw0K PiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvcmlzY3YvZG9tYWluLmMNCj4gPiAgY3Jl YXRlIG1vZGUgMTAwNjQ0IHhlbi9hcmNoL3Jpc2N2L2RvbWN0bC5jDQo+ID4gIGNyZWF0ZSBtb2Rl IDEwMDY0NCB4ZW4vYXJjaC9yaXNjdi9ndWVzdGNvcHkuYw0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2 NDQgeGVuL2FyY2gvcmlzY3YvaGVhZC5TDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJj aC9yaXNjdi9pcnEuYw0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvcmlzY3YvbGli L01ha2VmaWxlDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9yaXNjdi9saWIvZmlu ZF9uZXh0X2JpdC5jDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9yaXNjdi9tbS5j DQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9yaXNjdi9wMm0uYw0KPiA+ICBjcmVh dGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvcmlzY3YvcGVyY3B1LmMNCj4gPiAgY3JlYXRlIG1vZGUg MTAwNjQ0IHhlbi9hcmNoL3Jpc2N2L3BsYXRmb3Jtcy9LY29uZmlnDQo+ID4gIGNyZWF0ZSBtb2Rl IDEwMDY0NCB4ZW4vYXJjaC9yaXNjdi9zZXR1cC5jDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4 ZW4vYXJjaC9yaXNjdi9zaHV0ZG93bi5jDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJj aC9yaXNjdi9zbXAuYw0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvcmlzY3Yvc21w Ym9vdC5jDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9yaXNjdi9zeXNjdGwuYw0K PiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2FyY2gvcmlzY3YvdGltZS5jDQo+ID4gIGNyZWF0 ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9yaXNjdi90cmFwcy5jDQo+ID4gIGNyZWF0ZSBtb2RlIDEw MDY0NCB4ZW4vYXJjaC9yaXNjdi92bV9ldmVudC5jDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4 ZW4vYXJjaC9yaXNjdi94ZW4ubGRzLlMNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9kcml2 ZXJzL3Bhc3N0aHJvdWdoL3Jpc2N2L01ha2VmaWxlDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4 ZW4vZHJpdmVycy9wYXNzdGhyb3VnaC9yaXNjdi9pb21tdS5jDQo+ID4gIGNyZWF0ZSBtb2RlIDEw MDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvYWx0cDJtLmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAw NjQ0IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9hc20uaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQg eGVuL2luY2x1ZGUvYXNtLXJpc2N2L2F0b21pYy5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4 ZW4vaW5jbHVkZS9hc20tcmlzY3YvYml0b3BzLmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhl bi9pbmNsdWRlL2FzbS1yaXNjdi9idWcuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2lu Y2x1ZGUvYXNtLXJpc2N2L2J5dGVvcmRlci5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4v aW5jbHVkZS9hc20tcmlzY3YvY2FjaGUuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2lu Y2x1ZGUvYXNtLXJpc2N2L2NtcHhjaGcuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2lu Y2x1ZGUvYXNtLXJpc2N2L2NvbmZpZy5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5j bHVkZS9hc20tcmlzY3YvY3NyLmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRl L2FzbS1yaXNjdi9jdXJyZW50LmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRl L2FzbS1yaXNjdi9kZWJ1Z2dlci5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVk ZS9hc20tcmlzY3YvZGVsYXkuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUv YXNtLXJpc2N2L2Rlc2MuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNt LXJpc2N2L2RldmljZS5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20t cmlzY3YvZGl2NjQuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJp c2N2L2RvbWFpbi5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlz Y3YvZXZlbnQuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2 L2ZlbmNlLmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9m bHVzaHRsYi5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3Yv Z3JhbnRfdGFibGUuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJp c2N2L2d1ZXN0X2FjY2Vzcy5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9h c20tcmlzY3YvZ3Vlc3RfYXRvbWljcy5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5j bHVkZS9hc20tcmlzY3YvaGFyZGlycS5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5j bHVkZS9hc20tcmlzY3YvaHlwZXJjYWxsLmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9p bmNsdWRlL2FzbS1yaXNjdi9pbml0LmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNs dWRlL2FzbS1yaXNjdi9pby5oDQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9h c20tcmlzY3YvaW9jYXAuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNt LXJpc2N2L2lvbW11LmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL2FzbS1y aXNjdi9pcnEuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2 L21lbV9hY2Nlc3MuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJp c2N2L21tLmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9t b25pdG9yLmgNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9u b3NwZWMuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L251 bWEuaA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3AybS5o DQo+ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvcGFnZS5oDQo+ ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvcGFnaW5nLmgNCj4g PiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9wY2kuaA0KPiA+ICBj cmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3BlcmNwdS5oDQo+ID4gIGNy ZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvcGd0YWJsZS1iaXRzLmgNCj4g PiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9wcm9jZXNzb3IuaA0K PiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3JhbmRvbS5oDQo+ ID4gIGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvcmVncy5oDQo+ID4g IGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvcmlzY3ZfZW5jb2Rpbmcu aA0KPiA+ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3NldHVwLmgN Cj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9zbXAuaA0KPiA+ ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3NvZnRpcnEuaA0KPiA+ ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3NwaW5sb2NrLmgNCj4g PiAgY3JlYXRlIG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi9zdHJpbmcuaA0KPiA+ ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3N5c3JlZ3MuaA0KPiA+ ICBjcmVhdGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3N5c3RlbS5oDQo+ID4g IGNyZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvdGltZS5oDQo+ID4gIGNy ZWF0ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3YvdHJhY2UuaA0KPiA+ICBjcmVh dGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvYXNtLXJpc2N2L3R5cGVzLmgNCj4gPiAgY3JlYXRl IG1vZGUgMTAwNjQ0IHhlbi9pbmNsdWRlL2FzbS1yaXNjdi92bV9ldmVudC5oDQo+ID4gIGNyZWF0 ZSBtb2RlIDEwMDY0NCB4ZW4vaW5jbHVkZS9hc20tcmlzY3YveGVub3Byb2YuaA0KPiA+ICBjcmVh dGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvcHVibGljL2FyY2gtcmlzY3YuaA0KPiA+ICBjcmVh dGUgbW9kZSAxMDA2NDQgeGVuL2luY2x1ZGUvcHVibGljL2FyY2gtcmlzY3YvaHZtL3NhdmUuaA0K PiA+IA0KPiA+IC0tIA0KPiA+IDIuMjUuMA0KPiA+IA0KPiA+IFRoZSBzb3VyY2UgY29kZSBjYW4g YmUgZm91bmQgb24gZ2l0aHViOg0KPiA+IAlodHRwczovL2dpdGh1Yi5jb20vYmVzaGxlbWFuL3hl bi90cmVlL3BvcnQtdG8tcmlzYy12DQo+ID4gDQo+ID4gVGhlIHBhdGNoc2V0IG9ubHkgdGFyZ2V0 cyB0aGUgUUVNVSB2aXJ0IGJvYXJkIGFuZCBpdCBpcyB0ZXN0ZWQgb24NCj4gPiBBbGlzdGFpciBG cmFuY2lzJ3MgcGF0Y2hzZXQgZm9yIFFFTVUgd2l0aCBSSVNDLVYgaHlwZXJ2aXNvcg0KPiA+IGV4 dGVuc2lvbnMNCj4gPiB2MC41LCBmb3VuZCBoZXJlOg0KPiA+IAkNCj4gPiBodHRwczovL2dpdGh1 Yi5jb20vYWxpc3RhaXIyMy9xZW11L3RyZWUvbWFpbmxpbmUvYWxpc3RhaXIvcmlzY3YtaHlwLWV4 dC12MC41Lm5leHQNCj4gPiANCj4gPiBRRU1VIGlzIGJ1aWx0IHdpdGg6DQo+ID4gCWdpdCBjbG9u ZSAtLXNpbmdsZS1icmFuY2ggLS1icmFuY2ggbWFpbmxpbmUvYWxpc3RhaXIvcmlzY3YtaHlwLQ0K PiA+IGV4dC12MC41Lm5leHQgXA0KPiA+IAkJaHR0cHM6Ly9naXRodWIuY29tL2FsaXN0YWlyMjMv cWVtdS5naXQNCj4gPiAgICAgICAgIGNkIHFlbXUNCj4gPiAgICAgICAgIG1rZGlyIGJ1aWxkICYm IGNkIGJ1aWxkDQo+ID4gICAgICAgICAuLi9jb25maWd1cmUgLS10YXJnZXQtbGlzdD1yaXNjdjY0 LXNvZnRtbXUNCj4gPiAJbWFrZSAtaiQobnByb2MpICYmIG1ha2UgaW5zdGFsbA0KPiA+IA0KPiA+ IFRoZSBib290bG9hZGVyIHVzZWQgaXMgdGhlIHN0YW5kYXJkIE9wZW5TQkksIGJ1aWx0IHdpdGgg dGhlDQo+ID4gY29tbWFuZDoNCj4gPiAJQ1JPU1NfQ09NUElMRT1yaXNjdjY0LXVua25vd24tbGlu dXgtZ251LSBQTEFURk9STT1xZW11L3ZpcnQNCj4gPiBGV19QQVlMT0FEX1BBVEg9Li4veGVuL3hl bi94ZW4gbWFrZQ0KPiA+IA0KPiA+IFhlbi9SSVNDLVYgaXMgYnVpbHQgd2l0aDoNCj4gPiAJWEVO X1RBUkdFVF9BUkNIPXJpc2N2NjQgQ1JPU1NfQ09NUElMRT1yaXNjdjY0LXVua25vd24tbGludXgt DQo+ID4gZ251LSBtYWtlIGJ1aWxkDQo+ID4gDQo+ID4gWGVuIG1heSBiZSByYW4gd2l0aCB0aGUg Zm9sbG93aW5nIGNvbW1hbmQ6DQo+ID4gCXFlbXUtc3lzdGVtLXJpc2N2NjQgLWNwdSBydjY0LHgt aD10cnVlIC1NIHZpcnQgLW0gNTEyTSAtZGlzcGxheQ0KPiA+IG5vbmUgXA0KPiA+IAkJLXNlcmlh bCBzdGRpbyAta2VybmVsIFwNCj4gPiAJCW9wZW5zYmkvYnVpbGQvcGxhdGZvcm0vcWVtdS92aXJ0 L2Zpcm13YXJlL2Z3X3BheWxvYWQuZWwNCj4gPiBmDQo+ID4gDQo+ID4gQWxzbywgc2hvdXRvdXQg dG8gQWxpc3RhaXIgRnJhbmNpcyAoZnJvbSBXZXN0ZXJuIERpZ2l0YWwpIGZvcg0KPiA+IGdldHRp bmcNCj4gPiB0aGUgYmFsbCByb2xsaW5nIGFuZCBkb2luZyBhIHRvbiBvZiB0aGUgZ3JvdW5kd29y ayB3aXRoDQo+ID4gTWFrZWZpbGUvS2NvbmZpZywgYSB0b24gb2YgdGhlIFJJU0MtViBzcGVjaWZp YyBoZWFkZXIgZmlsZXMsIGFuZA0KPiA+IGFsc28NCj4gPiB0aGUgUUVNVSBSSVNDLVYgSCBleHRl bnNpb24gc3VwcG9ydCwgYW5kIERhbiBSb2JlcnRzb24gKGEgY29sbGVhZ3VlDQo+ID4gb2YNCj4g PiBtaW5lIGF0IFN0YXIgTGFiKSBmb3IgaGVscCBpbiBmb3J3YXJkIHBvcnRpbmcgYSBudW1iZXIg b2YgcGF0Y2hlcw0KPiA+IHRoYXQNCj4gPiB3ZXJlIG91dC1vZi1zeW5jIHdpdGggdXBzdHJlYW0u DQo+ID4gDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IEJvYmJ5IEVzaGxlbWFuDQo+ID4gDQo= From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:19:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:19:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0Fs-0001Hl-Qh; Tue, 16 Jun 2020 01:19:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0Fr-0001Hg-At for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:19:11 +0000 X-Inumbo-ID: 61b049da-af6f-11ea-bb8b-bc764e2007e4 Received: from mail-qt1-x844.google.com (unknown [2607:f8b0:4864:20::844]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 61b049da-af6f-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 01:19:10 +0000 (UTC) Received: by mail-qt1-x844.google.com with SMTP id q14so14264606qtr.9 for ; Mon, 15 Jun 2020 18:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iXsXRL7cKOK7W4zCPeLJpCiQpirlDE+jAyotbH2/Zco=; b=CL9QlwbWNe01cLygqxg1X2QsAvMCPdeBiKVdRI1gtvbHhntk46OmJ9FpaAYBgSVAJr 7lcvv8RGbd2lluLu7sFfeBIp4O9QvdasQNJrGoPJ5f2KYY6OtuCoolQiyEeuNUri9wno 9PUt7FlxpcS8hDqSzhm/a+KwASGnODAED8ToCWeMSBCGXQVksuTKiPFiesIu5FzVbwP9 VdK9qxeSFf0yC6dBOjPoXXbLOZvq8eEWV1vpN3n0t1PuObSoKtgThO1I9a08iCbs+67H 9kWK9swoxz6R7/vau+NbNjAxLvxmEIh7G9sw13xAqXY/TuDWvvH6Ymy0zQwCErEedH3B /8jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iXsXRL7cKOK7W4zCPeLJpCiQpirlDE+jAyotbH2/Zco=; b=ssuwpgA35BP7V3O2jkrzJva6jKHu1s4UQrwttZ84cw2EGJ1rNNnQ1ZWEYClNniBnsz IIpLExVsASyq/NbH3IGI33Y2WjXl8egur2cJ8ml27syoRoOCM60h3nCvUMGdXOrS0/TC o8vBoCPMr6J9J2IHuWZgNLXHmenjzeFevmEYAMczjidaSGZPaz/tuldd7hMWzEMcI8/k 0xQInU84YMYlkgHSXfD13xZuVnqjlR4Upe/tQr7E7DhQkcW/pLV1dLEA0eBA8D49K99m LblwyLUI3sNWc0qDv0oMtEQwOFAsZlZQ85b6suDkLnljeEJ8Nf2C+Ad+Ywysjt+bygzU z69Q== X-Gm-Message-State: AOAM532WGJRr8oCRz3MccYz6k1GwqrCrzyR8+21L1mheto8rQdvEnDNr OFrMLheEWrjKIX9X9fDvMzz1DCBNhM7+Ia6RyQ53UQ== X-Google-Smtp-Source: ABdhPJyNBl0oZoIp9VOvR37OdLYhvrCjw3kjpvFC5ePC4zZHOnAzJDQdBWTlJkxnAiDKfPMiEwmctkWTrZ7W9AGDQUo= X-Received: by 2002:ac8:7c8e:: with SMTP id y14mr19416964qtv.365.1592270350026; Mon, 15 Jun 2020 18:19:10 -0700 (PDT) MIME-Version: 1.0 References: <20200610185415.GG7231@minyard.net> In-Reply-To: From: Roman Shaposhnik Date: Mon, 15 Jun 2020 18:18:58 -0700 Message-ID: Subject: Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel To: Christopher Clark Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Corey Minyard , Stefano Stabellini , Julien Grall , tamas@tklengyel.com, Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 4:35 PM Christopher Clark wrote: > > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote: > > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote: > > > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > > > existing sd cards, and this was working fine. I finally got to a full > > > yocto build of the system, and it didn't boot. > > > > > > In fact, Xen didn't print anything at all, and nothing happens that > > > might suggest it's booting without any console output. > > I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch > works fine, whereas I see no console output from the kernel once Xen > tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > > > else the same, the 4.19 version of that overlay works, and the 5.4 > > > version does not work. It also didn't work if I completely removed the > > > overlay. The base device trees are the same between the two kernels. > > > > > > Looking at the overlay changes between the versions and Xen source, I > > > can't trace down anything that would cause an issue. Has anyone seen > > > this issue of have any ideas? > > Seen it: yes, but no progress on resolving it to report at this point. > > > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to 5.6.x: > > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > > > The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). > > Hi Roman - is there a specific commit in that rpi-5.6.y branch that > you guys have working ok? Pretty much the latest really. The problem is that it seems RPi ppl. keep forcepushing to that branch. Hence what we had to do on the EVE side is to basically "snapshot" it with this gigantic patch: https://github.com/lf-edge/eve/blob/master/pkg/new-kernel/patches-5.6.x/0000-rpi-kernel-changes.patch This needs to be applied on top of straight up upstream 5.6.14 (since that's what the closest common ancestor was on that branch at the time) In fact, the entire build process is captured here (if you're curious): https://github.com/lf-edge/eve/blob/master/pkg/new-kernel/Dockerfile (you can literally just docker build . build the whole thing) > It looks like the bcm2711_defconfig file wasn't included in the kernel > source tree of that branch at the point the kernel version was bumped > up to 5.6.14, so is there somewhere else to look for a matching kernel > config? Yes ;-) I can share the kind of config that has been pretty extensively tested by us here at Project EVE: https://github.com/lf-edge/eve/blob/master/pkg/new-kernel/kernel_config-5.6.x-aarch64 None of it is terribly EVE specific -- so you should have a reasonable base-line. Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:24:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:24:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0L3-00026K-FY; Tue, 16 Jun 2020 01:24:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0L2-00026F-AX for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:24:32 +0000 X-Inumbo-ID: 212b3112-af70-11ea-bb8b-bc764e2007e4 Received: from mail-vs1-xe43.google.com (unknown [2607:f8b0:4864:20::e43]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 212b3112-af70-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 01:24:31 +0000 (UTC) Received: by mail-vs1-xe43.google.com with SMTP id m25so10530402vsp.8 for ; Mon, 15 Jun 2020 18:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AWPRPexqcmyKI3v44fbOhZSz+HGtd9V7akn/oXB6X4A=; b=iy9ksS7dWc9insCdT65B93eg0YIQ0r+FJGVR6DCpsjTnZ465ZK6REocHE03NldZPoF XxXXlh+IcRe0HJUCihF7Ug+3ozrYJqzgT8sUSxkk74o34ZgNCWRES7sjXwU1BY414mO8 TUq79CdGAm9fiylanXeTtUPeLxqtiXDK0kcxc+sMoyJMeBQmICuFbUciAvk3K5xWnLcb rBOp6zuYueT+uryD5QTAcVC8ISUTqG9w+SSIwDNHV2+gIGNwTVf2R6+nTJblBqdkLjo0 OefZU7tuQeolaJm020iKLZJPmE/kVob/sP+bAB+AKegyVbNxzsz0kYlWPRV9RL8c0xEA ONUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AWPRPexqcmyKI3v44fbOhZSz+HGtd9V7akn/oXB6X4A=; b=rKqs8YXSK3yAsI+M77v5lZ1SXlukkh5OM6mHMdg8X0FwlkdZWgQFerIXAY/oWpzFTn ATJrEzsNLVaeR8E9mibGRDt6wbRe03pGIrJOorHlex+iXyBmh0AGMQFnkN0+BHj2DdCj XD/e8wiJtUzlh54oX7dNPpNhIWrQYWSTTa3yamnjFx9fCOk946IZjJ6etLqFz/fj+mcN Z66nBGKPpb703SX1hEZG5YIKQjkPDl3ieqxSlZt/UGaHvRjYLcwNOYfqVCnV1GLXqVXj 80K8ljrJB3So2/KkeI80X369SsDkqOTx0tObZLiXsOWlwXC9v6FfzuugoWzNOCFrJZY2 SuNw== X-Gm-Message-State: AOAM531lijXqg0dECefL0RjIjWp+0pOqzjrzpf7LirwbZCC2Py0klMIc r2/V/e5AEQ4xrG5PDYeUNRT3DN1Qy5IRGEsQSSI= X-Google-Smtp-Source: ABdhPJwMFqMuV/UdbdISJyaYS8N82sH5CUJkXQAF1CT+kyq94F4qTka7Egt9oTSyexZZwvo+u8+OUgts0cchTwtm95Q= X-Received: by 2002:a67:7d81:: with SMTP id y123mr343026vsc.126.1592270671186; Mon, 15 Jun 2020 18:24:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Volodymyr Babchuk Date: Tue, 16 Jun 2020 04:24:20 +0300 Message-ID: Subject: Re: [Tee-dev] TEE with XEN To: Peng Fan Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Oleksandr Andrushchenko , "tee-dev@lists.linaro.org" , Xen-devel , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Peng, On Mon, 15 Jun 2020 at 05:07, Peng Fan wrote: > > Hi All, > > While enabling trusty os with xen, I took same approach as OP-TEE, > with OP-TEE running in secure world. But I am also thinking this might > introduce potential issue is that secure world OS communicate with DomU. > If there are some misbehavior in secure world OS, it might let XEN > hypervisor not work proper. > > In my setup, trusty os sometimes panic in secure world, xen will not able > to control the panic core anymore. > > So I am thinking whether we need to emulating secure world in a XEN VM > which is the VM running DomU. Just like what ACRN did to run trusty > os. Well, it depends on whom you are trusting more. Both XEN and TEE are minimal OS implementations with aim at security. I'm speaking about generic TEE OS, not about particular OS like OP-TEE or Trusty. Problem is that, if TEE is running inside VM, it will be susceptible to a hypervisor misbehaviour. You need to understand that Xen and privileged domain (dom0, mostly) can access memory of any guest. At least, in default configuration. There are means to harden this setup. But anyways, Xen can't be stopped from reading TEE's secrets. If this is okay for your needs, then you can run TEE as a VM of course. So, this is heavilly depends on your security threats model. There can't be universal solution. Also, I'm proposing to check Google's requirements for Trusty environment. Do they allow it to run outside of TrustZone? For example, GPD TEE System Architecture document clearly says that TEE should be separated from REE by hardware mechanisms that are not controlled by REE (section 2.2.1). I believe, that should be a similar document for Trusty. -- WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babchuk@gmail.com From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:45:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:45:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0fA-0003mf-5x; Tue, 16 Jun 2020 01:45:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0f8-0003ma-Ul for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:45:18 +0000 X-Inumbo-ID: 06c51dbc-af73-11ea-8496-bc764e2007e4 Received: from mail-ot1-x342.google.com (unknown [2607:f8b0:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 06c51dbc-af73-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 01:45:15 +0000 (UTC) Received: by mail-ot1-x342.google.com with SMTP id n70so14745818ota.5 for ; Mon, 15 Jun 2020 18:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mvista-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kMi+jR3horvu1aylPf21nfSU/GNPdB0SU9oDs45H9fU=; b=nX+gSTTHhzZR1vuKJRqxVX5NMt/lsFovrjYbpyUeNJQdepET/yaqUo283csBqVYdBW uSbDQAskrjL9x4J+QfGWRPKH5P9ViTuJ4EWLvIq8ycKNRTySkqTpnJ0qHweT+kbYOkzo VygcXV5uOk7SwC1OKBqRb9/4vRM+gRhq9yxcfUl4FJuI4rZ5zEobaCQB3Ts7zqMRW/CI nacdVNOt9mGhTBMRNLZXz5TN6U1KvCidmOpPG51nHEskJF6BbUoOGc2TF3RMQXlZYfwm Q7496B+JUbJ2e+TFePcsMg2ee1She7NhKInoP9L+WFy85nel5vlmR3fp5pag6nYhywKe M1mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=kMi+jR3horvu1aylPf21nfSU/GNPdB0SU9oDs45H9fU=; b=ZLENUd7HzJ71JyGo6cxCRhd2KhEivrqeXaKuuiIkGV77U0Ga/DCV5kMnHhzhQQQk/N z4KCAub2mV76jouL2ouaBxk6vT9gfGnq8mHX4gUXaxtZ72diq6IfuoufSKRjZe1RFi7K 2PaQ1pKrdRZ43lNaOcnZFKQYO4i8iE1/TqIkApzIiXgJpiyzC2IfeD6bSc3cGIueB4AW tqowKnZxuQ+W8HgdgR0jLdCj77Dv4k/AikGlU3t/mAlUcNEnIAkTDfjG+FlxIjhlXAxn 4FO3AlTomW2HtvhIxJc8/p6/mHMsSLGhax86yr8A5tv8+67KNWwAg9UuE33DKtzZv+C5 AcMg== X-Gm-Message-State: AOAM533Bti6g9KrF2X/SRqCvymKA55CF59q/LuD421LFLNzUVIcRrl8Y CDuZiG44FyZjQZwW13aQsPxOuQ== X-Google-Smtp-Source: ABdhPJxr206Qo4tFc4ns8F2nRl5uHV2WeyGlEDTa6GqDf5bkdnVcTyJg99CyrrIJbxLCCAS7aA+tjQ== X-Received: by 2002:a9d:6048:: with SMTP id v8mr723177otj.231.1592271915436; Mon, 15 Jun 2020 18:45:15 -0700 (PDT) Received: from minyard.net ([47.184.146.204]) by smtp.gmail.com with ESMTPSA id t22sm3730736oth.53.2020.06.15.18.45.14 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 Jun 2020 18:45:14 -0700 (PDT) Date: Mon, 15 Jun 2020 20:45:13 -0500 From: Corey Minyard To: Roman Shaposhnik Subject: Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel Message-ID: <20200616014513.GD3113@minyard.net> References: <20200610185415.GG7231@minyard.net> <20200616010252.GC3113@minyard.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: cminyard@mvista.com Cc: Xen-devel , Stefano Stabellini , Julien Grall , Christopher Clark , tamas@tklengyel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 06:05:57PM -0700, Roman Shaposhnik wrote: > On Mon, Jun 15, 2020 at 6:02 PM Corey Minyard wrote: > > > > On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote: > > > On Mon, 15 Jun 2020, Christopher Clark wrote: > > > > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote: > > > > > > > > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote: > > > > > > > > > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > > > > > > existing sd cards, and this was working fine. I finally got to a full > > > > > > yocto build of the system, and it didn't boot. > > > > > > > > > > > > In fact, Xen didn't print anything at all, and nothing happens that > > > > > > might suggest it's booting without any console output. > > > > > > > > I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch > > > > works fine, whereas I see no console output from the kernel once Xen > > > > tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > > > > > > > > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > > > > > > else the same, the 4.19 version of that overlay works, and the 5.4 > > > > > > version does not work. It also didn't work if I completely removed the > > > > > > overlay. The base device trees are the same between the two kernels. > > > > > > > > > > > > Looking at the overlay changes between the versions and Xen source, I > > > > > > can't trace down anything that would cause an issue. Has anyone seen > > > > > > this issue of have any ideas? > > > > > > > > Seen it: yes, but no progress on resolving it to report at this point. > > > > > > > > > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to 5.6.x: > > > > > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > > > > > > > > > The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). > > > > > > > > Hi Roman - is there a specific commit in that rpi-5.6.y branch that > > > > you guys have working ok? > > > > It looks like the bcm2711_defconfig file wasn't included in the kernel > > > > source tree of that branch at the point the kernel version was bumped > > > > up to 5.6.14, so is there somewhere else to look for a matching kernel > > > > config? > > > > > > I don't know if that is the issue but beware that some device trees > > > invert serial0 with serial1. Make sure to use /soc/serial@7e215040. You > > > can do that by passing dtuart=/soc/serial@7e215040 to the Xen command > > > line. > > > > I already have that set as part of the boot process, but it still > > doesn't print anything out once Xen is started. > > > > I tried the 5.6 device tree, and no help there, eithers. I'm wondering > > if everyone is still running with the 4.19 device trees. > > As I pointed out in the EVE link above -- we're very happily running > with 5.6 device trees. They are, of course, taken from RPI kernel > tree. Ok, what version of Xen are you running? I'm using 4.13 with the Pi patches, but I have not tried the master branch. -corey > > Thanks, > Roman. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:49:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:49:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0jB-0003vp-Nv; Tue, 16 Jun 2020 01:49:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0jA-0003vk-LV for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:49:28 +0000 X-Inumbo-ID: 9d16cb26-af73-11ea-8496-bc764e2007e4 Received: from mail-qk1-x742.google.com (unknown [2607:f8b0:4864:20::742]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9d16cb26-af73-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 01:49:28 +0000 (UTC) Received: by mail-qk1-x742.google.com with SMTP id c185so17794109qke.7 for ; Mon, 15 Jun 2020 18:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GOOhgnXBYOMT6Aow+cxbcqElNl/+c5ulRJ3RfYpA7cY=; b=KrRgPCpiPQKgGYbPq+BLufENafE91I+lx3Dk1PcTsMOsE33zwEDcny74OyP7UU0xzY LaqoZQiTlXF1TMdt8PM1olFAlgwI5X7dn/Vhv1TbbgFW11hsD0NbwRz3I+19sxwptzcE 7vLGK0L4fBjRaNkSo+tlm8MOKsIKvg18Cs3ssM1YaOr0TGgkTZCQnXlsVV0Plyqh1yMg abddugkqNksjuYl7YeCW+KVDWsHrgAKiZ856qWsQUmcxun6cSQEC7UXAJmkVIYi4Vqto lK5yJg6LRNBQ9NtGj4o0Qv2RThAXuqqEhSTL8L21Lbt3/Tz45YiDTB/MOqznsAnzyTjZ nkEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GOOhgnXBYOMT6Aow+cxbcqElNl/+c5ulRJ3RfYpA7cY=; b=jhCc/GCnnYGFRhtrH0M8Q1n5oNijbXNz4M0IIZYhxXy9XOv12Beue5mHWLn7xDzKy4 7O+LgVEcdqOmSSLPWmghq8LP1PHvQZK8bB+nWd40fdraHGZS5cFipZKxNtMC4zqd6NWX XKKYgq2vCuJq6HQ/CiI1V2FmDXbgJRmCNhV7DiAVSjmzWVvYxQP1CAq4pzwxDiVdnnp2 0+vk00chDUDQNXbgHLA7bfVYf9TG213w9ccDG1lHBSvdH9fBhyl67IVi6YD0MsITyG8D B+Mmq3UW/MgpZrz2nLtyLkCU2MPB3qzrJU1i2dtzSFga6TcbESepaT8w1HC8QnzUGEkw TiCg== X-Gm-Message-State: AOAM533wjMqgp1MuLZ5ZDM+ZwrdrV6tViE600tZtRkBSVO4xqs9+VC83 IZaG6dC2lpL9ir18QwWhmOI0BBRQqCbeQjrPszvkTQ== X-Google-Smtp-Source: ABdhPJyaQ8IbMoJaszuzQnQ4Mf3b97Ft8a4GDd9dzIjpItwZ8WrbMiUBf7KadY9jjJzqJX8mvNYtIZe4hHrApwat250= X-Received: by 2002:a37:8c04:: with SMTP id o4mr1237437qkd.270.1592272167642; Mon, 15 Jun 2020 18:49:27 -0700 (PDT) MIME-Version: 1.0 References: <20200610185415.GG7231@minyard.net> <20200616010252.GC3113@minyard.net> <20200616014513.GD3113@minyard.net> In-Reply-To: <20200616014513.GD3113@minyard.net> From: Roman Shaposhnik Date: Mon, 15 Jun 2020 18:49:16 -0700 Message-ID: Subject: Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel To: Corey Minyard Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Stefano Stabellini , Julien Grall , Christopher Clark , tamas@tklengyel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 6:45 PM Corey Minyard wrote: > > On Mon, Jun 15, 2020 at 06:05:57PM -0700, Roman Shaposhnik wrote: > > On Mon, Jun 15, 2020 at 6:02 PM Corey Minyard wrote: > > > > > > On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote: > > > > On Mon, 15 Jun 2020, Christopher Clark wrote: > > > > > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote: > > > > > > > > > > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote: > > > > > > > > > > > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > > > > > > > existing sd cards, and this was working fine. I finally got to a full > > > > > > > yocto build of the system, and it didn't boot. > > > > > > > > > > > > > > In fact, Xen didn't print anything at all, and nothing happens that > > > > > > > might suggest it's booting without any console output. > > > > > > > > > > I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch > > > > > works fine, whereas I see no console output from the kernel once Xen > > > > > tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > > > > > > > > > > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > > > > > > > else the same, the 4.19 version of that overlay works, and the 5.4 > > > > > > > version does not work. It also didn't work if I completely removed the > > > > > > > overlay. The base device trees are the same between the two kernels. > > > > > > > > > > > > > > Looking at the overlay changes between the versions and Xen source, I > > > > > > > can't trace down anything that would cause an issue. Has anyone seen > > > > > > > this issue of have any ideas? > > > > > > > > > > Seen it: yes, but no progress on resolving it to report at this point. > > > > > > > > > > > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to 5.6.x: > > > > > > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > > > > > > > > > > > The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). > > > > > > > > > > Hi Roman - is there a specific commit in that rpi-5.6.y branch that > > > > > you guys have working ok? > > > > > It looks like the bcm2711_defconfig file wasn't included in the kernel > > > > > source tree of that branch at the point the kernel version was bumped > > > > > up to 5.6.14, so is there somewhere else to look for a matching kernel > > > > > config? > > > > > > > > I don't know if that is the issue but beware that some device trees > > > > invert serial0 with serial1. Make sure to use /soc/serial@7e215040. You > > > > can do that by passing dtuart=/soc/serial@7e215040 to the Xen command > > > > line. > > > > > > I already have that set as part of the boot process, but it still > > > doesn't print anything out once Xen is started. > > > > > > I tried the 5.6 device tree, and no help there, eithers. I'm wondering > > > if everyone is still running with the 4.19 device trees. > > > > As I pointed out in the EVE link above -- we're very happily running > > with 5.6 device trees. They are, of course, taken from RPI kernel > > tree. > > Ok, what version of Xen are you running? I'm using 4.13 with the Pi > patches, but I have not tried the master branch. We're running 4.14 + additional patches (not sure which ones will make it into 4.14 proper yet): https://github.com/lf-edge/eve/tree/master/pkg/xen/arch/aarch64 FWIW: the first patch is basically the delta between 4.13 and 4.14 Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 01:57:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 01:57:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0qy-0004lL-J6; Tue, 16 Jun 2020 01:57:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0qx-0004lG-29 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 01:57:31 +0000 X-Inumbo-ID: bc85e932-af74-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bc85e932-af74-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 01:57:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=p8eZKwR1Naox0wPPUr3MCu9U90Pc2Vu3aeQUjv5oeew=; b=sbudAxxlOAK2XxbtIO4FPc08H WzUDRrsGQ4pMmTF1ww6cwTLOmw0k6KTn3RM/Qu5K0AgnRwhmc3ry4BIHnyWLEAlimZJY1YdWudEMy iWPEsGWjsV+2k7CCWoEwmla4tLHxW0yt2tJlD56k+7vPDsL+dnpV7Kz2W9sZhe6Qf8E6s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0qv-0000ce-OP; Tue, 16 Jun 2020 01:57:29 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jl0qv-000297-Fd; Tue, 16 Jun 2020 01:57:29 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jl0qv-0000gi-Eo; Tue, 16 Jun 2020 01:57:29 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151139: all pass - PUSHED X-Osstest-Versions-This: ovmf=b90beadfae8f1153697fbb87f923cfa14578ee3e X-Osstest-Versions-That: ovmf=9af1064995d479df92e399a682ba7e4b2fc78415 From: osstest service owner Date: Tue, 16 Jun 2020 01:57:29 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151139 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151139/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b90beadfae8f1153697fbb87f923cfa14578ee3e baseline version: ovmf 9af1064995d479df92e399a682ba7e4b2fc78415 Last test of basis 151069 2020-06-13 06:49:53 Z 2 days Testing same since 151139 2020-06-15 00:09:55 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Michael Kubacki jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 9af1064995..b90beadfae b90beadfae8f1153697fbb87f923cfa14578ee3e -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Tue Jun 16 02:02:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 02:02:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0vi-0005x6-AU; Tue, 16 Jun 2020 02:02:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl0vg-0005x1-Dm for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 02:02:24 +0000 X-Inumbo-ID: 6a995e00-af75-11ea-b866-12813bfff9fa Received: from EUR01-HE1-obe.outbound.protection.outlook.com (unknown [40.107.13.53]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6a995e00-af75-11ea-b866-12813bfff9fa; Tue, 16 Jun 2020 02:02:23 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i16n+PlLnHtv4TkU4K/joJq83mNCBwaY5QRFsa7Icm8FDuvHragei4GXGlYVk2B4KZtbCaUHLWmF9w2p6YyEZ3EY7p2OmFnRWoYM4k+4eL78wBIp4nYZn/12VyTh2zzZ2t+Eo2DQZb1pGKq9ltt3Gcd4HiNAxY1pZbKtsy3fuAUJZG3VA0C2uuP1yPsljOCUfopyrsNeNgYTslvdsKnszLkrkUN9tqTZ9b8KEkBiFdO9x7fxu+HwasHl5rp7N8sfOCz3TZoK3SMjzC3Jx37cSkkRg0fS6tPaVXyf9gMFT4EvoTP3X8B9LC69Mze3fdSNZxQgZgbnTvJomUritsTErw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fi8b8PPe89sPxksvUWQxXqG2gfhC47pLd6CqSuQxY/k=; b=DXpxS2po1NY4N97FKYkJY8scecTkcfICwt738W+ZAgKt4OlPobaoWDqtBp76GaKSTntR949LgSl8YDPNm8YZPViW4zMO2Me3Y4LOw3jdTMK51alH37cfec2DTjhu2NoWHJP2UIFVJ3UKLH/qE9uU7i9w6KzCjQRCJQzNu7O6dIu+zy/eK3Pk1ZoYI3SwgyNKYD+SoeogFEKxsUYwovY5BuI58AK+ktSUnbOyR5hQXVijOFHax3O7dAH/5ryJI0hm0qmRQko+A7qVzN4erCNkVxLKl2JwJIuyXYJaWoUv/BdBsVlXJCkw0ecJH8In4siyqRPigmy9vWSrFr7qYPBsuw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fi8b8PPe89sPxksvUWQxXqG2gfhC47pLd6CqSuQxY/k=; b=i8INAKnZec9Wgs7X4KBCWNKtF9fh24PWdnopgD5AwNLpWSCgYI0Y//IRwctr/Lo1jmb5ioKtT4k4QSCUm1B9v3F80F8EnRzTWVlDVHQhFtjJSq9+GUxnqbUTDQH08q5RsJQ7kdjUHFi4iohROkLH7L34Us1t51XlAVCgwWduiaU= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2806.eurprd04.prod.outlook.com (2603:10a6:4:97::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.25; Tue, 16 Jun 2020 02:02:20 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3088.028; Tue, 16 Jun 2020 02:02:20 +0000 From: Peng Fan To: Volodymyr Babchuk Subject: RE: [Tee-dev] TEE with XEN Thread-Topic: [Tee-dev] TEE with XEN Thread-Index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQAw/zsAAAE3WoA= Date: Tue, 16 Jun 2020 02:02:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3fd092be-9ca5-4b08-d7d1-08d811994de4 x-ms-traffictypediagnostic: DB6PR0402MB2806: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04362AC73B x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GL2zywCMGykFZrAx0lhbzCnZlfbpcf+h0CZBYOFZnx+mWBgkHQc7NFvfUuLZTN7mT0X3ZhtafQwjvoTUmQWBvz2Z3sPsVJ8Jm8MXmuBU4zTdAHRRLrlGJeNEH0icO4U4OyHW4dysJFGbd6mLA3J6s5bllM5Sa0qQITljaZlJBoz7jtZLQkW+tS644KKvErCwyQXk0dyuACT8CAh7r99lLF6s5aQf2bER1DJU3mxphL7AZMUfrsRxhV+RoCdl+i1ose2Y5p6IeBWovl0MkLHiz2TqtgIgvQAphytJXkxra8eSBiejQLp59sB80LNecOj8BBDV9aJwF9bv0iddAJ3Rjg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(376002)(396003)(366004)(346002)(6506007)(186003)(83380400001)(4326008)(44832011)(8936002)(55016002)(2906002)(9686003)(478600001)(26005)(71200400001)(6916009)(76116006)(316002)(66446008)(64756008)(66946007)(66556008)(66476007)(54906003)(8676002)(5660300002)(86362001)(7696005)(52536014)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 7EyvHEhBJWHfWPZffSZ3v+em8BEEyfnLTS24L2RZN1nP/otjmCLDQHTjkybinr9aZzvvnXZo4ygPl6jgC1hWy1yfwj5QnWd+T5aFoXd3jVavN2l3pakOz59Pvt2kDgMQvJUKKLx1/IRxIF+SfSkbKQXRodDbztY8gMAppJ4bqLObdj/hEAjos13kvKtbxHZjhycw9T4fvDltlIGt3lYLACmm3MH2tufsspchPZqWLAcO/KEjtxalyoqRQeZLHzoRwbYbccSFu8zTrX7KN1N+IfBUAPUufkV/V3xiEbEYI8BQAaaUJBAjFGCSCgqNp+Pi17eV0lL7OLvNzkv+/hvWPBELl3j1N6Ms5onnp/wkOSOBJP/SK8y7cdjkTtPZc5Bo/HiOfcOrLWwr14bNGIUJy95ESKOJL2iFTTDxBtb24wYW05qCkr6lQobKUbhDXMZ4mtj4D2Q6F/A0+wVH3YF6zhfQOKiSamvTTS45gAqFludWb7Bj5Vjuvi1yIUf2J561 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3fd092be-9ca5-4b08-d7d1-08d811994de4 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2020 02:02:20.6247 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5dha9KScXB/KzSKkoyiV9F6ZcwvblZmJf8wdRP0eGaHu5ykfqZA+v8STxX0U/ntQGlqnefuJ8H4SCXlHOh3DPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2806 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Oleksandr Andrushchenko , "tee-dev@lists.linaro.org" , Xen-devel , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGksDQoNCj4gU3ViamVjdDogUmU6IFtUZWUtZGV2XSBURUUgd2l0aCBYRU4NCj4gDQo+IEhpIFBl bmcsDQo+IA0KPiBPbiBNb24sIDE1IEp1biAyMDIwIGF0IDA1OjA3LCBQZW5nIEZhbiA8cGVuZy5m YW5AbnhwLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBBbGwsDQo+ID4NCj4gPiBXaGlsZSBlbmFi bGluZyB0cnVzdHkgb3Mgd2l0aCB4ZW4sIEkgdG9vayBzYW1lIGFwcHJvYWNoIGFzIE9QLVRFRSwN Cj4gPiB3aXRoIE9QLVRFRSBydW5uaW5nIGluIHNlY3VyZSB3b3JsZC4gQnV0IEkgYW0gYWxzbyB0 aGlua2luZyB0aGlzIG1pZ2h0DQo+ID4gaW50cm9kdWNlIHBvdGVudGlhbCBpc3N1ZSBpcyB0aGF0 IHNlY3VyZSB3b3JsZCBPUyBjb21tdW5pY2F0ZSB3aXRoIERvbVUuDQo+ID4gSWYgdGhlcmUgYXJl IHNvbWUgbWlzYmVoYXZpb3IgaW4gc2VjdXJlIHdvcmxkIE9TLCBpdCBtaWdodCBsZXQgWEVODQo+ ID4gaHlwZXJ2aXNvciBub3Qgd29yayBwcm9wZXIuDQo+ID4NCj4gPiBJbiBteSBzZXR1cCwgdHJ1 c3R5IG9zIHNvbWV0aW1lcyBwYW5pYyBpbiBzZWN1cmUgd29ybGQsIHhlbiB3aWxsIG5vdA0KPiA+ IGFibGUgdG8gY29udHJvbCB0aGUgcGFuaWMgY29yZSBhbnltb3JlLg0KPiA+DQo+ID4gU28gSSBh bSB0aGlua2luZyB3aGV0aGVyIHdlIG5lZWQgdG8gZW11bGF0aW5nIHNlY3VyZSB3b3JsZCBpbiBh IFhFTiBWTQ0KPiA+IHdoaWNoIGlzIHRoZSBWTSBydW5uaW5nIERvbVUuIEp1c3QgbGlrZSB3aGF0 IEFDUk4gZGlkIHRvIHJ1biB0cnVzdHkNCj4gPiBvcy4NCj4gDQo+IFdlbGwsIGl0IGRlcGVuZHMg b24gd2hvbSB5b3UgYXJlIHRydXN0aW5nIG1vcmUuIEJvdGggWEVOIGFuZCBURUUgYXJlDQo+IG1p bmltYWwgT1MgaW1wbGVtZW50YXRpb25zIHdpdGggYWltIGF0IHNlY3VyaXR5LiANCg0KWEVOIGlz IHRhcmdldGluZyBzYWZldHkuDQpURUUgaXMgdGFyZ2V0aW5nIHNlY3VyaXR5Lg0KDQpJJ20gc3Bl YWtpbmcgYWJvdXQgZ2VuZXJpYw0KPiBURUUgT1MsIG5vdCBhYm91dCBwYXJ0aWN1bGFyIE9TIGxp a2UgT1AtVEVFIG9yIFRydXN0eS4gUHJvYmxlbSBpcyB0aGF0LCBpZiBURUUgaXMNCj4gcnVubmlu ZyBpbnNpZGUgVk0sIGl0IHdpbGwgYmUgc3VzY2VwdGlibGUgdG8gYSBoeXBlcnZpc29yIG1pc2Jl aGF2aW91ci4gWW91DQo+IG5lZWQgdG8gdW5kZXJzdGFuZCB0aGF0IFhlbiBhbmQgcHJpdmlsZWdl ZCBkb21haW4gKGRvbTAsIG1vc3RseSkgY2FuIGFjY2Vzcw0KPiBtZW1vcnkgb2YgYW55IGd1ZXN0 Lg0KPiBBdCBsZWFzdCwgaW4gZGVmYXVsdCBjb25maWd1cmF0aW9uLiBUaGVyZSBhcmUgbWVhbnMg dG8gaGFyZGVuIHRoaXMgc2V0dXAuIEJ1dA0KPiBhbnl3YXlzLCBYZW4gY2FuJ3QgYmUgc3RvcHBl ZCBmcm9tIHJlYWRpbmcgVEVFJ3Mgc2VjcmV0cy4NCg0KWWVzLiBVbmRlcnN0YW5kLg0KDQo+IA0K PiBJZiB0aGlzIGlzIG9rYXkgZm9yIHlvdXIgbmVlZHMsIHRoZW4geW91IGNhbiBydW4gVEVFIGFz IGEgVk0gb2YgY291cnNlLg0KPiANCj4gU28sIHRoaXMgaXMgaGVhdmlsbHkgZGVwZW5kcyBvbiB5 b3VyIHNlY3VyaXR5IHRocmVhdHMgbW9kZWwuIFRoZXJlIGNhbid0IGJlDQo+IHVuaXZlcnNhbCBz b2x1dGlvbi4gQWxzbywgSSdtIHByb3Bvc2luZyB0byBjaGVjayBHb29nbGUncyByZXF1aXJlbWVu dHMgZm9yDQo+IFRydXN0eSBlbnZpcm9ubWVudC4NCg0KTGV0IG1lIHRyeSB0byBhc2sgR29vZ2xl IGd1eXMgdG8gc2VlIGFueSBmZWVkYmFjay4NCg0KVGhhbmtzLA0KUGVuZy4NCg0KPiBEbyB0aGV5 IGFsbG93IGl0IHRvIHJ1biBvdXRzaWRlIG9mIFRydXN0Wm9uZT8gRm9yIGV4YW1wbGUsIEdQRCBU RUUgU3lzdGVtDQo+IEFyY2hpdGVjdHVyZSBkb2N1bWVudCBjbGVhcmx5IHNheXMgdGhhdCBURUUg c2hvdWxkIGJlIHNlcGFyYXRlZCBmcm9tIFJFRSBieQ0KPiBoYXJkd2FyZSBtZWNoYW5pc21zIHRo YXQgYXJlIG5vdCBjb250cm9sbGVkIGJ5IFJFRSAoc2VjdGlvbiAyLjIuMSkuIEkgYmVsaWV2ZSwN Cj4gdGhhdCBzaG91bGQgYmUgYSBzaW1pbGFyIGRvY3VtZW50IGZvciBUcnVzdHkuDQo+IA0KPiAt LQ0KPiBXQlIgVm9sb2R5bXlyIEJhYmNodWsgYWthIGxvcmMgWyszODA5NzY2NDYwMTNdDQo+IG1h aWx0bzogdmxhZC5iYWJjaHVrQGdtYWlsLmNvbQ0K From xen-devel-bounces@lists.xenproject.org Tue Jun 16 02:56:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 02:56:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl1lw-0001ng-Vz; Tue, 16 Jun 2020 02:56:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl1lw-0001nE-1F for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 02:56:24 +0000 X-Inumbo-ID: f21657f0-af7c-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f21657f0-af7c-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 02:56:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=f+LAFbSQ6Jh9ktERgy2e8kRJ2105qWraH/4Z5fy0SAY=; b=FXshy1VoIiMsgQVOmYO0p0ayb kZH5R02c7tBi6GFSTvW/WPD41wEpODLj4ggEPvtcyIS+owIMHgdi6XOZChQEG2q+izqbMpxcH+Nns BVGYVEmKkpVtpFSZBVrLbGx0D8psKMxJBL8P75hr9nhrK4XcLiWtY0SX3EUfQyTGNmGBc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl1ln-00027C-SR; Tue, 16 Jun 2020 02:56:15 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jl1ln-0003v4-KU; Tue, 16 Jun 2020 02:56:15 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jl1ln-0003d4-Jb; Tue, 16 Jun 2020 02:56:15 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 151137: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.10-testing:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression xen-4.10-testing:test-amd64-amd64-pygrub:debian-di-install:fail:regression xen-4.10-testing:test-amd64-i386-xl-raw:debian-di-install:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-amd64-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-arm64-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-armhf-libvirt:libvirt-build:fail:regression xen-4.10-testing:test-armhf-armhf-xl-vhd:guest-start:fail:heisenbug xen-4.10-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=ce056837082da7b2759a069045e480638094adcd X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Tue, 16 Jun 2020 02:56:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151137 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151137/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039 build-i386-prev 6 xen-build fail REGR. vs. 150039 build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 11 guest-start fail pass in 151087 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 151087 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 151087 never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 150039 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 150039 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen ce056837082da7b2759a069045e480638094adcd baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 41 days Failing since 150941 2020-06-09 17:05:34 Z 6 days 8 attempts Testing same since 151059 2020-06-12 08:13:16 Z 3 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark John Thomson Julien Grall Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub fail test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw fail test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit ce056837082da7b2759a069045e480638094adcd Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 934d6e1a77947662504cf4d5e36c9520e03aa731 Author: John Thomson Date: Tue May 15 11:48:43 2018 +1000 tools/ocaml/libs/xc fix gcc-8 format-truncation warning CC xenctrl_stubs.o xenctrl_stubs.c: In function 'failwith_xc': xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "%d: %s: %s", error->code, ^ xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028 snprintf(error_str, sizeof(error_str), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%d: %s: %s", error->code, ~~~~~~~~~~~~~~~~~~~~~~~~~~ xc_error_code_to_desc(error->code), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error->message); ~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1 m Signed-off-by: John Thomson Acked-by: Christian Lindig Release-acked-by: Juergen Gross (cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795) commit 6e636f297f12a52ce12db11ea0787dd541937ed6 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:50 2018 +0200 tools/misc: fix hypothetical buffer overflow in xen-lowmemd gcc-8 complains: xen-lowmemd.c: In function 'handle_low_mem': xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=] snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~ ~~~~ xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In practice it wouldn't happen, because 'data' contains string representation of 64-bit unsigned number (20 characters at most). But place a limit to mute gcc warning. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080) commit dfc0b23403a2f0069bc7b9c0c20dfe5513eb8fb5 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:52 2018 +0200 tools/blktap2: fix possible '\0' truncation gcc-8 complains: tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring': tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^ tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255 snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "- 1" in buffer size should be actually applied to message, to leave place for terminating '\0', not the other way around (truncate '\0' even if it would fit). In function 'tapdisk_control_open_image', inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10: tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'tapdisk_control_create_socket', inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9: tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block-qcow.c: In function 'qcow_create': block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(backing_filename, backing_file, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(backing_filename)); ~~~~~~~~~~~~~~~~~~~~~~~~~ I those cases, reduce size of copied string and make sure final '\0' is added. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a) commit 2f83654fa3331d1ec79275072f8742f175f82bc5 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:54 2018 +0200 tools/gdbsx: fix -Wstringop-truncation warning gcc-8 complains: gx_main.c: In function 'prepare_stop_reply': gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(buf, "watch:", 6); ^~~~~~~~~~~~~~~~~~~~~~~~~ Since terminating '\0' isn't needed here at all, switch to memcpy. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f) commit bf467cc828bde380e9201d8b49c7866a5b92d719 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:53 2018 +0200 tools/xenpmd: fix possible '\0' truncation gcc-8 complains: xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->oem_info, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->battery_type, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->serial_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->model_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy 31 chars, then make sure terminating '\0' is present. Those fields are passed to strlen and as '%s' for snprintf later. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b) commit 6df4d40d846eb5151a89d26d1a63d632c6b9eb55 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:49 2018 +0200 tools/libxc: fix strncpy size gcc-8 warns about possible truncation of trailing '\0'. Final character is overridden by '\0' anyway, so don't bother to copy it. This fixes compile failure: xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159) commit e20bb5818174e9d09389776cb14781b9c6436554 Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit a1a9b055a349748083665e42843f75d6db2c6a7b Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit afca67fafde22033b9a967ae197a10af5c654f02 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 16 03:25:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 03:25:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl2E0-0004GJ-Dv; Tue, 16 Jun 2020 03:25:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl2Dz-0004Ft-Jy for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 03:25:23 +0000 X-Inumbo-ID: fe8473c4-af80-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fe8473c4-af80-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 03:25:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sHNDfHCPka+t6klvWQ46PKOMNkkgEVS7s32PUN8vSs4=; b=DSG9n7XlsuW6V1tuaBSlv1i7E rRDxtonZfyqZfyUQB1Zgnuso4Vq4Ou+TJkVN6OEHgFj864IvNH+yWhgR9rQYhMVgPgt3kxnsplDsA cDuVeiz3Zr5mATZC5R8w0SlmhoRnfqTnif64tvBdfGb8UtGbKgN1DNC8LgmrVKFwmd5GA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl2Dq-0002dg-2u; Tue, 16 Jun 2020 03:25:14 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jl2Dp-0005qp-RR; Tue, 16 Jun 2020 03:25:13 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jl2Dp-0002sR-Qm; Tue, 16 Jun 2020 03:25:13 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 151141: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-arm64-libvirt:libvirt-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-armhf-libvirt:libvirt-build:fail:regression xen-4.9-testing:test-arm64-arm64-xl-credit2:xen-boot:fail:heisenbug xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:guest-start:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=6e477c2ea4d5c26a7a7b2f850166aa79edc5225c X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Tue, 16 Jun 2020 03:25:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151141 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151141/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150120 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-credit2 7 xen-boot fail pass in 151096 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 151096 never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 151096 never pass test-armhf-armhf-xl-rtds 12 guest-start fail like 150120 test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 37 days Failing since 150940 2020-06-09 17:05:20 Z 6 days 9 attempts Testing same since 151070 2020-06-13 06:57:26 Z 2 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Ian Jackson John Thomson Julien Grall Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm pass build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 pass build-armhf pass build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 fail test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c Author: Wei Liu Date: Mon Jun 12 16:04:17 2017 +0100 ipxe: update to newer commit To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7. The only patch we have applies cleanly. Reported-by: Zhongze Liu Signed-off-by: Wei Liu Acked-by: Ian Jackson (cherry picked from commit 461b2165346de236fff2d00d1c318062f1daab08) commit 6a1c431890599c701117bf9822898f60a18444a3 Author: John Thomson Date: Tue May 15 11:48:43 2018 +1000 tools/ocaml/libs/xc fix gcc-8 format-truncation warning CC xenctrl_stubs.o xenctrl_stubs.c: In function 'failwith_xc': xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "%d: %s: %s", error->code, ^ xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028 snprintf(error_str, sizeof(error_str), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%d: %s: %s", error->code, ~~~~~~~~~~~~~~~~~~~~~~~~~~ xc_error_code_to_desc(error->code), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error->message); ~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1 m Signed-off-by: John Thomson Acked-by: Christian Lindig Release-acked-by: Juergen Gross (cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795) commit 41f597f5167c2e78a3c70d219710c8805d7fec8e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:50 2018 +0200 tools/misc: fix hypothetical buffer overflow in xen-lowmemd gcc-8 complains: xen-lowmemd.c: In function 'handle_low_mem': xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=] snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~ ~~~~ xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In practice it wouldn't happen, because 'data' contains string representation of 64-bit unsigned number (20 characters at most). But place a limit to mute gcc warning. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080) commit 1eae17268887bacbc598ef6e3290059dbeb4fd8f Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:52 2018 +0200 tools/blktap2: fix possible '\0' truncation gcc-8 complains: tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring': tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^ tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255 snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "- 1" in buffer size should be actually applied to message, to leave place for terminating '\0', not the other way around (truncate '\0' even if it would fit). In function 'tapdisk_control_open_image', inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10: tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'tapdisk_control_create_socket', inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9: tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block-qcow.c: In function 'qcow_create': block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(backing_filename, backing_file, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(backing_filename)); ~~~~~~~~~~~~~~~~~~~~~~~~~ I those cases, reduce size of copied string and make sure final '\0' is added. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a) commit f1e75e5c7054d8cd7bdfe30c6a95af35cc24fbb2 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:54 2018 +0200 tools/gdbsx: fix -Wstringop-truncation warning gcc-8 complains: gx_main.c: In function 'prepare_stop_reply': gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(buf, "watch:", 6); ^~~~~~~~~~~~~~~~~~~~~~~~~ Since terminating '\0' isn't needed here at all, switch to memcpy. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f) commit f034ab45c15aef9c784dbcdc5c893e268d4a094c Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:53 2018 +0200 tools/xenpmd: fix possible '\0' truncation gcc-8 complains: xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->oem_info, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->battery_type, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->serial_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->model_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy 31 chars, then make sure terminating '\0' is present. Those fields are passed to strlen and as '%s' for snprintf later. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b) commit 9737f89b076ae4d05e6f974a7c21aced4459966e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:49 2018 +0200 tools/libxc: fix strncpy size gcc-8 warns about possible truncation of trailing '\0'. Final character is overridden by '\0' anyway, so don't bother to copy it. This fixes compile failure: xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159) commit 1dd64783024c5c9e600c3d33393b795c68a46f65 Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit 80d78acf9e60ae6a88d6cb6f3535eaf67c81f61c Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. Extend libxl's table of named parameters to include RDRAND/RDSEED, and have the compiler construct it in .rodata, rather than on the stack at runtime each time it is called. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 16 03:51:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 03:51:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl2cs-0006eK-Ih; Tue, 16 Jun 2020 03:51:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl2cr-0006eF-9L for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 03:51:05 +0000 X-Inumbo-ID: 9a16ec56-af84-11ea-bca7-bc764e2007e4 Received: from mail-pl1-x643.google.com (unknown [2607:f8b0:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9a16ec56-af84-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 03:51:04 +0000 (UTC) Received: by mail-pl1-x643.google.com with SMTP id bh7so7778457plb.11 for ; Mon, 15 Jun 2020 20:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=yCzz3ohVOu5XuO1kEDpexGnGERf5ty0vT5A2CFZMtV8=; b=XflChHkglKPf3esLBmCpQ3Rm3sQt/HYOIcYkol7QmE5VBtGa+7X9D+BV4ALE1mxVUI wx0D7o34uLNdoZt4y28WwlmAsis3GEMgRn1V9TPGGxGnkhiTZqmOqwXXDNdWnpWBCQ15 4p4accTkX1kRRjCHKlY0m+1qqRIuOhgErnXBC5eJnoUyr8SLJpk1RrDU3PTEIXi75M7h jm6XD4BYZTKv2YgLboQvp9saD/DL79OGRN+y77xKcP8CG9ZIcPuBqNfJT6bN+aZhf63a 4tTLXRCTuzUi8eUM8wcoWEJOtuCMQrV9K2QcWMAqwzxhWz6SY+xSuuWUu8zHa2xAsZqr BKJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=yCzz3ohVOu5XuO1kEDpexGnGERf5ty0vT5A2CFZMtV8=; b=sYCV3UVlGW/zn5maLoST/EyuPhJ0E1aulyOC0a8UFemJPBjO9zt6YqsRwdpAJwkfH4 y7yvCTWz2tSOBQTMK4GqVD+ywxlApDf/J+QUxjt8QMD9MMBiaSTqNUAkqJl3wFaNLrIx xBlGrvwjTWkuAleCagQ3Yd/G6Nz43oDvTAW5lyBfbVwsOCHn/CKxo+O2NwbHKd33pvyj MW7qstF6E1ZpxK4YeiVjYt2saDZmRVpfBAs38eQ9ztVYxkXPMTc5AVFQ7Mny9D/gY6Rl wjP2ea/luh+ItShHxAH9UhIfNcJVEDqLXaXy5fbRtKqQ/Re0sL7n4ZEmLPe7T3UgoO0m dhCw== X-Gm-Message-State: AOAM5310I3erplx7DMz9ICzgcf8zVpblVDNkgYk8lGwALJGqC05xUxlb rlpgIX/sqzuxbursKQSRpTQ= X-Google-Smtp-Source: ABdhPJzjpJc5bPHETGOc7VNjE+m2Xcmyn9qOYZilfENKep1CkOkHk960im/I44HXgvq5BObkgT735A== X-Received: by 2002:a17:902:b196:: with SMTP id s22mr412625plr.152.1592279463795; Mon, 15 Jun 2020 20:51:03 -0700 (PDT) Received: from piano ([2601:1c0:4202:2e60::a569]) by smtp.gmail.com with ESMTPSA id 12sm16031353pfb.3.2020.06.15.20.51.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2020 20:51:02 -0700 (PDT) Date: Mon, 15 Jun 2020 20:51:00 -0700 From: Bobby Eshleman To: Alistair Francis Subject: Re: [RFC XEN PATCH 00/23] xen: beginning support for RISC-V Message-ID: <20200616035100.GA19383@piano> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "dan@dlrobertson.com" , "julien@xen.org" , "wl@xen.org" , "konrad.wilk@oracle.com" , "George.Dunlap@eu.citrix.com" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "bobby.eshleman@starlab.io" , "sstabellini@kernel.org" , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 01:10:17AM +0000, Alistair Francis wrote: > On Mon, 2020-06-15 at 18:03 -0700, Stefano Stabellini wrote: > > Any updates? I am looking forward to this :-) > It has been on a slow burn since I became a new dad (shortly after the RFC). I've gradually regained free time, and so I've been able to change that slow burn to a moderate burn in the last couple weeks. Most of my progress has been around build environment improvements. I've done some work stripping it down to the bare minimum required to build a new arch and rooting the commit history from there, and some work with incorporating it into the gitlab CI, containerizing the build and QEMU run, etc... As far as hypervisor status: I'm just about done with incorporating the boot module FDT parsing code, extracting kernel info and ram regions (taken/generalized from arch/arm), plus implementing the arch-specific pieces of domain_create(). On the verge of being able to dive into a guest kernel and see what breaks first :) I'm expected to commit an extra day or two per week in the next month or so at Vates, so this will considerably bump up my cadence in comparison to the last few months. > FYI, I would like to talk more about RISC-V Xen at the Xen Virtual > summit. I'll put it forward as a BoF subject. > > I haven't worked on this, although the RISC-V Hypervisor spec is > progressing towards ratification. > > Alistair > That would be great :) -Bobby From xen-devel-bounces@lists.xenproject.org Tue Jun 16 06:11:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 06:11:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl4oV-0001RN-4h; Tue, 16 Jun 2020 06:11:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl4oT-0001RI-Qe for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 06:11:13 +0000 X-Inumbo-ID: 2da20916-af98-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2da20916-af98-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 06:11:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B745AAC85; Tue, 16 Jun 2020 06:11:15 +0000 (UTC) Subject: Re: [PATCH for-4.14 v2 1/2] x86/passthrough: do not assert edge triggered GSIs for PVH dom0 To: Roger Pau Monne References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-2-roger.pau@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 08:11:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200610142923.9074-2-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10.06.2020 16:29, Roger Pau Monne wrote: > @@ -186,9 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) > * to know if the GSI is pending or not. > */ > spin_lock(&d->arch.hvm.irq_lock); > - if ( !hvm_irq->gsi_assert_count[gsi] ) > + if ( trig == VIOAPIC_EDGE_TRIG || !hvm_irq->gsi_assert_count[gsi] ) > { > - hvm_irq->gsi_assert_count[gsi] = 1; > + if ( trig == VIOAPIC_LEVEL_TRIG ) > + hvm_irq->gsi_assert_count[gsi] = 1; Btw, along the lines of how you do things here, I think ... > @@ -196,11 +198,12 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) > > void hvm_gsi_deassert(struct domain *d, unsigned int gsi) > { > + int trig = vioapic_get_trigger_mode(d, gsi); > struct hvm_irq *hvm_irq = hvm_domain_irq(d); > > - if ( gsi >= hvm_irq->nr_gsis ) > + if ( trig <= VIOAPIC_EDGE_TRIG || gsi >= hvm_irq->nr_gsis ) ... this would better have been "trig != VIOAPIC_LEVEL_TRIG", to avoid the code being dependent upon the actual values of both VIOAPIC_*_TRIG constants. Jan > - ASSERT_UNREACHABLE(); > + ASSERT(trig == VIOAPIC_EDGE_TRIG && gsi < hvm_irq->nr_gsis); > return; > } > > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 06:28:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 06:28:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl54e-0002Pw-Jm; Tue, 16 Jun 2020 06:27:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl54d-0002Pr-QY for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 06:27:55 +0000 X-Inumbo-ID: 82e495e0-af9a-11ea-b884-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 82e495e0-af9a-11ea-b884-12813bfff9fa; Tue, 16 Jun 2020 06:27:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D1878AC85; Tue, 16 Jun 2020 06:27:57 +0000 (UTC) Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask To: Roger Pau Monne References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> From: Jan Beulich Message-ID: <1ccfdfdf-695e-00ce-7d49-401b1f4bb015@suse.com> Date: Tue, 16 Jun 2020 08:27:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200610142923.9074-3-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 10.06.2020 16:29, Roger Pau Monne wrote: > @@ -558,6 +559,12 @@ int pt_irq_create_bind( > */ > ASSERT(!mask); > share = trigger_mode; > + if ( trigger_mode == VIOAPIC_EDGE_TRIG ) > + /* > + * Edge IO-APIC interrupt, no EOI or unmask to perform > + * and hence no timer needed. > + */ > + pirq_dpci->flags |= HVM_IRQ_DPCI_NO_EOI; Is this really limited to edge triggered IO-APIC interrupts? MSI ones are effectively edge triggered too, aren't they? Along the lines of irq_acktype() maskable MSI may then also not need any such arrangements? The pirq_guest_eoi() -> desc_guest_eoi() path looks to confirm this. > @@ -920,6 +923,8 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) > if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI ) > { > hvm_gsi_assert(d, pirq->pirq); > + if ( pirq_dpci->flags & HVM_IRQ_DPCI_NO_EOI ) > + goto out; Immediately ahead of this there's a similar piece of code dealing with PCI INTx. They're commonly level triggered, but I don't think there's a strict need for this to be the case. At least hvm_pci_intx_assert() -> assert_gsi() -> vioapic_irq_positive_edge() also cover the edge triggered one. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 06:35:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 06:35:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl5CE-0003G9-EB; Tue, 16 Jun 2020 06:35:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl5CD-0003G4-PM for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 06:35:45 +0000 X-Inumbo-ID: 9af4dd42-af9b-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9af4dd42-af9b-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 06:35:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 82B76ACCF; Tue, 16 Jun 2020 06:35:47 +0000 (UTC) Subject: Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages] To: Ian Jackson References: <24291.43673.301735.439410@mariner.uk.xensource.com> <24291.45488.423085.940252@mariner.uk.xensource.com> <3c68a609-a069-f7e1-3c99-291da372df96@suse.com> <24295.31551.406528.629952@mariner.uk.xensource.com> <3849058f-32db-2294-6aa6-c8f829571f4b@suse.com> <24295.32975.664225.928516@mariner.uk.xensource.com> From: Jan Beulich Message-ID: <107f8a65-4b2d-7417-3625-73bc543bcc48@suse.com> Date: Tue, 16 Jun 2020 08:35:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24295.32975.664225.928516@mariner.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , George Dunlap , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 16:08, Ian Jackson wrote: > Jan Beulich writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]"): >> On 15.06.2020 15:44, Ian Jackson wrote: >>> Thanks to both for your opinions. I have pushed those two to 4.10 and >>> will see how things go. I may send them to 4.9 too. >> >> Won't 4.10 continue to be blocked then because or -prev issues? > > There are multiple issues. My hope is to get rid of all of them... > > Eventually I think we will have to force push 4.9 because its prev > builds will fail and won't want to update 4.8. Right - which will then enable 4.10's -prev build to work, which will in turn allow 4.11's -prev builds to work, and then the same for 4.12. I.e. osstest will continue to be quite busy for the next several days. Instead of building -prev anew each time, wouldn't it make sense to store and re-use the most recent "prev" tree's build? This ought to avoid this sort of cascade dependencies in particular when upgrading the test platform underneath. There's no reason to fail a flight just because the N-1 tree doesn't build anymore. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 06:51:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 06:51:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl5RG-0004qY-RC; Tue, 16 Jun 2020 06:51:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl5RF-0004qT-Sk for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 06:51:17 +0000 X-Inumbo-ID: c6b2893c-af9d-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c6b2893c-af9d-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 06:51:17 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EC30DAF96; Tue, 16 Jun 2020 06:51:19 +0000 (UTC) Subject: Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted To: Andrew Cooper , Ian Jackson References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-3-andrew.cooper3@citrix.com> <24295.35624.644030.417783@mariner.uk.xensource.com> <24295.38146.988316.316252@mariner.uk.xensource.com> <53a1f221-89ae-0d8e-32ef-c9c8c83580c5@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 08:51:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <53a1f221-89ae-0d8e-32ef-c9c8c83580c5@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 18:12, Andrew Cooper wrote: > On 15/06/2020 16:34, Ian Jackson wrote: >> Andrew Cooper writes ("Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted"): >>> Nothing runs it by default, but it is part of my prepush testing for >>> anything in the relevant area. >>> >>> We should do something better, but its not totally trivial.  The x86 >>> emulator test for example needs a fairly bleeding edge version of >>> binutils, given that we routinely add support for bleeding edge >>> instruction groups. >> Hmmm. Is it likely that installing the version from Debian testing >> (say) would work ? Or do we want to build it from source ? These are >> all possibilities. > > Pulling from Sid may work, if they're fairly prompt to update to new > binutils releases.  (They're certainly up to date ATM) > > Jan: are we ever in a position where we need something more bleeding > edge than the latest binutils release? Gcc needs to be about as recent: Right now the minimum is gcc 8 I think, and I have a few hacks in place locally to make things somewhat work back to gcc 5, as on my laptop (and hence when working from home) I don't have any custom gcc builds. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 07:07:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 07:07:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl5gs-0005rq-6l; Tue, 16 Jun 2020 07:07:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl5gr-0005rl-3a for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 07:07:25 +0000 X-Inumbo-ID: 06c1ef98-afa0-11ea-b88a-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 06c1ef98-afa0-11ea-b88a-12813bfff9fa; Tue, 16 Jun 2020 07:07:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B513DAC85; Tue, 16 Jun 2020 07:07:25 +0000 (UTC) Subject: Re: [PATCH v19 for-4.14 00/13] VM forking To: Tamas K Lengyel References: <000c01d63826$6d125900$47370b00$@xen.org> <4017F2B3-BB9B-4E9F-813C-6FE68BA0D568@citrix.com> <002401d638b0$a5460f80$efd22e80$@xen.org> From: Jan Beulich Message-ID: <52f24592-934a-da54-9439-a67fea004af3@suse.com> Date: Tue, 16 Jun 2020 09:07:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Kevin Tian , Stefano Stabellini , Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , George Dunlap , Jun Nakajima , Ian Jackson , Anthony Perard , xen-devel , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 21:27, Tamas K Lengyel wrote: > On Tue, Jun 2, 2020 at 3:39 AM Jan Beulich wrote: >> >> On 02.06.2020 09:37, Paul Durrant wrote: >>> Maintainers/committers, can we please get those patches in a.s.a.p.? >> >> The sole reason I didn't put in at least the 1st patch on Friday >> (perhaps also the 2nd, as it is suitably ack-ed) was that it's >> still missing a VMX maintainer ack, and Kevin had provided >> comments on v2 of the smaller (2-patch) series. > > Can we get the first patches from this series merged now with Kevin's > Reviewed-by he sent last week > (https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg00732.html)? Please can you be a little more patient? I've been out of the office until yesterday afternoon, and I'm dealing with half broken email now. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 07:13:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 07:13:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl5ml-0006h1-SB; Tue, 16 Jun 2020 07:13:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl5mk-0006gw-5A for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 07:13:30 +0000 X-Inumbo-ID: df1eb006-afa0-11ea-b88c-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id df1eb006-afa0-11ea-b88c-12813bfff9fa; Tue, 16 Jun 2020 07:13:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 48F85AF28; Tue, 16 Jun 2020 07:13:29 +0000 (UTC) Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Stefano Stabellini References: <20200613184132.11880-1-julien@xen.org> From: Jan Beulich Message-ID: <2e46c098-10c2-7978-c403-692528bd92b7@suse.com> Date: Tue, 16 Jun 2020 09:13:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 03:00, Stefano Stabellini wrote: > On Sat, 13 Jun 2020, Julien Grall wrote: >> From: Julien Grall >> >> The documentation of pvcalls suggests there is padding for 32-bit x86 >> at the end of most the structure. However, they are not described in >> in the public header. >> >> Because of that all the structures would be 32-bit aligned and not >> 64-bit aligned for 32-bit x86. >> >> For all the other architectures supported (Arm and 64-bit x86), the >> structure are aligned to 64-bit because they contain uint64_t field. >> Therefore all the structures contain implicit padding. >> >> The paddings are now corrected for 32-bit x86 and written explicitly for >> all the architectures. >> >> While the structure size between 32-bit and 64-bit x86 is different, it >> shouldn't cause any incompatibility between a 32-bit and 64-bit >> frontend/backend because the commands are always 56 bits and the padding >> are at the end of the structure. >> >> As an aside, the padding sadly cannot be mandated to be 0 as they are >> already present. So it is not going to be possible to use the padding >> for extending a command in the future. >> >> Signed-off-by: Julien Grall >> >> --- >> Changes in v3: >> - Use __i386__ rather than CONFIG_X86_32 >> >> Changes in v2: >> - It is not possible to use the same padding for 32-bit x86 and >> all the other supported architectures. >> --- >> docs/misc/pvcalls.pandoc | 18 ++++++++++-------- >> xen/include/public/io/pvcalls.h | 14 ++++++++++++++ >> 2 files changed, 24 insertions(+), 8 deletions(-) >> >> diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc >> index 665dad556c39..caa71b36d78b 100644 >> --- a/docs/misc/pvcalls.pandoc >> +++ b/docs/misc/pvcalls.pandoc >> @@ -246,9 +246,9 @@ The format is defined as follows: >> uint32_t domain; >> uint32_t type; >> uint32_t protocol; >> - #ifdef CONFIG_X86_32 >> + #ifndef __i386__ >> uint8_t pad[4]; >> - #endif >> + #endif > > > Hi Julien, > > Thank you for doing this, and sorry for having missed v2 of this patch, I > should have replied earlier. > > The intention of the #ifdef blocks like: > > #ifdef CONFIG_X86_32 > uint8_t pad[4]; > #endif > > in pvcalls.pandoc was to make sure that these structs would be 64bit > aligned on x86_32 too. > > I realize that the public header doesn't match, but the spec is the > "master copy". We have been saying it for a while (Andy in particular) > that the specification documents are the one that define the protocol, > not the public headers. This is the very first time we get to act on > that statement. What a special occasion this is :-) > > So I think we should keep the specification as is and fix the public > header instead. Something like v1 of this patch. But you've read the communication on v1 and v2? A public header can't be "fixed" if it may already be in use by anyone. We can only do as Andrew and you suggest (mandate textual descriptions to be "the ABI") when we do so for _new_ interfaces from the very beginning, making clear that the public header (if any) exists just for reference. I'm not convinced btw that expressing at least the majority of an ABI by way of a C reference implementation is a bad or unsuitable thing. It's just that aspects like underlying type properties need to be very clear and unambiguous. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 07:31:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 07:31:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl647-0008M0-E8; Tue, 16 Jun 2020 07:31:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl646-0008La-8B for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 07:31:26 +0000 X-Inumbo-ID: 5e9b50da-afa3-11ea-b88d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5e9b50da-afa3-11ea-b88d-12813bfff9fa; Tue, 16 Jun 2020 07:31:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kFzVa046d3qStiE6MgwyDri9PYCmrLn24rmYyJ2xSB4=; b=3xN+kLbDwOCZXiJ5XGrprVKUK WohTjdDmBX5+RzcpCJXo/7crFfAsmwG+54sGEJ7TEKmiBbF3kFZxXd4l71Qm43vf5M6X47ZjUtSGS m8bIv7/+a2o6P0/AXjeT4Tk+rsfpMM528j5fRAv/7l0VnLXJBjghNXZP3lzfmiSKV17Ag=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl63y-0007jO-50; Tue, 16 Jun 2020 07:31:18 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jl63w-0000tZ-RE; Tue, 16 Jun 2020 07:31:17 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jl63w-0001oR-QW; Tue, 16 Jun 2020 07:31:16 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151140: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Tue, 16 Jun 2020 07:31:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151140 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151140/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 41 days Failing since 150942 2020-06-09 17:05:43 Z 6 days 8 attempts Testing same since 151061 2020-06-12 12:25:05 Z 3 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 2b77729888fb851ab96e7f77bc854122626b4861 Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 16 07:56:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 07:56:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6ST-0001fX-LO; Tue, 16 Jun 2020 07:56:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6SS-0001fS-8m for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 07:56:36 +0000 X-Inumbo-ID: e59aa394-afa6-11ea-bb8b-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.54]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e59aa394-afa6-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 07:56:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X0Q5tkCE0pj0ucWbcV/dZjTLWhRBR8Y1d9il8nUHDoA=; b=ib7vBZStZsAmXZHS2MuBNcjQ/aI05Ng0dgCIXor8lOnz7QVJHk9Mp0yG/m/maqq/rkTSXXYsnLDz6QF1P+JKaYUz/yhrL4pOyscsjwetkLYtR3ZadKgUTSu0aMl4E9g3xQDrTP0OAh2nWxibIUVqdW0H57siJP8oR6cX3cP8PWY= Received: from DB6PR0501CA0020.eurprd05.prod.outlook.com (2603:10a6:4:8f::30) by DB6PR0802MB2152.eurprd08.prod.outlook.com (2603:10a6:4:83::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.26; Tue, 16 Jun 2020 07:56:32 +0000 Received: from DB5EUR03FT064.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:8f:cafe::13) by DB6PR0501CA0020.outlook.office365.com (2603:10a6:4:8f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Tue, 16 Jun 2020 07:56:32 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT064.mail.protection.outlook.com (10.152.21.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Tue, 16 Jun 2020 07:56:31 +0000 Received: ("Tessian outbound 79611f28bf50:v59"); Tue, 16 Jun 2020 07:56:31 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: ce21aba53b16ad50 X-CR-MTA-TID: 64aa7808 Received: from 853d4a4e57f0.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id FF135FD7-B10A-46AF-86C1-26802F7EF362.1; Tue, 16 Jun 2020 07:56:26 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 853d4a4e57f0.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 16 Jun 2020 07:56:26 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=No708oeQx5aVJdK2VoGxlQ5TuTAF9BFsSwZTGQKdLENIZh5a9tAeXBvhMqIsjYsV3QggpJOVi6CrJPIj5KSqqkkMQ/BQnvA2mlpiRVBWp2RIA+jdhuSGW4qs8q43J8EZTh3xSfP8+H9ZhYN2wOB12cAvV7HvuSvh7s8KMM0jk63bFm04ZSEaarock+jkHni9VmgT6xMrkXWWOkSpTzUys4On/UVdcq7Ih1LJpvsXYTpvEjo5fdbTEssTk2hVTNco/3aVnS4IRVqu3SOC4IvWhjV4uWYm/P6y44Pmi5HGU6cJspdgUveMVcV9bbcVUrnUe/YVAMmfhfyFkVxfbOcxWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X0Q5tkCE0pj0ucWbcV/dZjTLWhRBR8Y1d9il8nUHDoA=; b=nl5G+xa473vxW/iCarKs0yzglRmZM0FdF+zjjR3S7Kd8an0/VL/zApvPRVH/JdHMuv0E3FSpC0OnuG10LC3P64yyyazcdhjQPKOguI+3T7mJmhIqYGEXQYzp1nQg2FDaQQSbiiaJIqLbpA+gfC8zY2DIOiZhuvH+JaxQ3DK9YN4d/SJo5nxIhrZkEt/RN9a13jvK+Kx3217F8Ncfg+X/ZdLTmW5wuUY+BUh00IriYiUtQQE4n4v053oLE2rt2an3b1sQf3XDttYv+QFNhYxkQzmvF5bQ6qCZVlrD/OH76ggJJ2ky1v7hZBKa8kFgLb0HaB5g4RBTnVvF+JQKFvnWAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X0Q5tkCE0pj0ucWbcV/dZjTLWhRBR8Y1d9il8nUHDoA=; b=ib7vBZStZsAmXZHS2MuBNcjQ/aI05Ng0dgCIXor8lOnz7QVJHk9Mp0yG/m/maqq/rkTSXXYsnLDz6QF1P+JKaYUz/yhrL4pOyscsjwetkLYtR3ZadKgUTSu0aMl4E9g3xQDrTP0OAh2nWxibIUVqdW0H57siJP8oR6cX3cP8PWY= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3179.eurprd08.prod.outlook.com (2603:10a6:5:25::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.23; Tue, 16 Jun 2020 07:56:23 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.028; Tue, 16 Jun 2020 07:56:23 +0000 From: Bertrand Marquis To: Stefano Stabellini Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgIAAJpOAgABE7QCABAZcAIAAQRIAgAA9oACAAXYtAIAAD3sAgAAFaoCAABUzgIAAB/uAgAAD1ICAAdWTgIAHsRIAgAAmsACAAK5FAA== Date: Tue, 16 Jun 2020 07:56:23 +0000 Message-ID: <0A1E5483-1D34-4CA4-9161-09E2F47B3D5C@arm.com> References: <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: c12478de-6dae-4a6b-a316-08d811cac887 x-ms-traffictypediagnostic: DB7PR08MB3179:|DB6PR0802MB2152: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04362AC73B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: ByQgBN9z8APk4AKoN4Gq40ZtE5YoRBm6F5+PE2Bn3ZthCtOIZFIbDRg6P7PmvDWrYGra3ZITq5qzqYqgYOOjH4haV3lNstJGJv7/VQYu5rAaQHyTuJVRx+Mwgf0vsV05ETU4FBl4GeGzfH60vDMSom6Fu6/2ehH/XBFhEIq8H+ttIB2akqRjhhQR5RgeoVW0HK5DlYWsGxbBZJPg872MI2A2f5/qaE35MJJZz/IuoILgK1PW53ZxEdLbPjh/jVz0vdyhgMNgcy9dR5nmUs/4XiebuCWmbqTelFRhu7u+ZtYXs1/2ugtFaMNIgtAwXADM0Xnad7IxID6Ts7uXJVoyHw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(346002)(396003)(376002)(39860400002)(66446008)(64756008)(71200400001)(83380400001)(91956017)(26005)(478600001)(6486002)(86362001)(33656002)(2906002)(316002)(66476007)(3480700007)(76116006)(66556008)(8676002)(2616005)(5660300002)(6916009)(8936002)(54906003)(53546011)(6512007)(6506007)(186003)(36756003)(66946007)(4326008)(7116003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tafEKj7hNBQwVko2UNKFWgmhlJwQmOcon/eo/x0fA/s3nx4kLVGg0isYnrqO00HijGWivE5AyUSsRVEbm4ui0KayZZvIzFeuYWLoU3U6npOE8wqqqHl6nsGR6Hm30PCK97pRITQpFGAYLqBFuNP033Dk7KejbSFqASid1rrDBX25MvQdEW3bjWUoLJBUBFIE3iU5ILBXEwW4Z3+bwZ+0XDMHF3HL/sK3D+CCsUXHph+nr6J6wJqeW8k5osaRikniAiMs4PLlaxHso173vBrsCMWGSBvEu7QBtZZj/lePj7gBv0LLgJ6Hgtr3o1qt89QqGBXJc+l3DlXNXtqivNNS5g+C89ou01Yv0eWUgzXue4yBeZFg4eEZFGmfP4ipNalBB0QwqJH/OUOcixXthOLDiZ6Af39RcDh++AsFPe7PqAS7GvgltYxjWB5Fi71nL05KNU3tm7D4jYfAfbLk9sgrKhul6CE5SWpN5q1Fi07J6e8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <74294602DB3DA949A7977FE5B9978340@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3179 Original-Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT064.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(346002)(39860400002)(396003)(46966005)(478600001)(7116003)(26005)(186003)(2906002)(70206006)(36756003)(5660300002)(70586007)(4326008)(6512007)(82740400003)(6862004)(3480700007)(8936002)(82310400002)(356005)(336012)(33656002)(54906003)(81166007)(2616005)(86362001)(8676002)(47076004)(316002)(53546011)(83380400001)(6486002)(6506007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 6aa98f8c-be6f-4524-2e26-08d811cac372 X-Forefront-PRVS: 04362AC73B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: s70H4iDyFKRDsHVGpyQdRGMcOBb3RahioMbUYt4KhHyMEXi4dJ0+pYgfe6V8MRgYlSF0OGNEXEje4beaIKRMiEf6MB/xp8oZzSuVjTpxUZqg/eUb39oFS7nSbybKgYMjiTQJDPKdr/WA3+jpxM1yxOGAiK1V8/805BtT+7HJ1tOi93xfDWUrhpWBrBzFQnIxl12DMpFXCPy3JrIU0k83nTlIto6HtpMjvXbkl4Sa4914Efbwl4QMBJtvh3l7oTlzlGTV6o/MMW/rdD9NyZquiLjiUqkOBiW6at4HPnDB0IQTg7qRDUiLjlP1hScfRTOlZIYjtvNqTbmm5prXz4w3Rr2EV9rMTFpXaN83b6t8pAKhBSxVu4bX2B+BbMmngdZSN46r4u2YeEmXkQRJwi8EMQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2020 07:56:31.8243 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c12478de-6dae-4a6b-a316-08d811cac887 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0802MB2152 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , nd , xen-devel , CodeWiz2280 , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On 15 Jun 2020, at 22:32, Stefano Stabellini wro= te: >=20 > On Mon, 15 Jun 2020, CodeWiz2280 wrote: >> On Wed, Jun 10, 2020 at 5:46 PM Julien Grall wrote: >>>=20 >>> Hi Marc, >>>=20 >>> On Tue, 9 Jun 2020 at 18:45, Marc Zyngier wrote: >>>>> I was wondering if you heard about any potential issue with guest EOI >>>>> not forwarded to the host. This is on TI Keystone (Cortex A-15). >>>>=20 >>>> Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midw= ay >>>> all run just fine with guest EOI), and GIC-400 is a pretty solid piece >>>> of kit (it is just sloooooow...). >>>>=20 >>>> Thinking of it, you would see something like that if the GIC was seein= g >>>> the writes coming from the guest as secure instead of NS (cue the earl= y >>>> firmware on XGene that exposed the wrong side of GIC-400). >>>=20 >>> Ah, I remember that one. We used to carry an hack in Xen [1] for >>> X-Gene. Thankfully they fixed the firmware! >>>=20 >>> If it is a similar issue, then the firmware path would definitely be >>> my preference. >>>=20 >>> Thank you for the input! >>=20 >> Thank you all for the information. If I pull the changes to use the >> maintenance interrupt for the X-Gene back into the latest build of Xen >> then my issue with the Edge and Level interrupts is resolved. My >> ethernet and other devices work fine again for the Keystone in dom0. >> Are there any concerns over operating this way, meaning with the >> maintenance interrupt workaround rather than the EOI? Is this safe? >=20 > It should be fine, a small impact on performance, that's all. Agree, this is safe but you will have an overhead (one context switch back = to Xen on interrupt ack in Dom0 in your case). >=20 >=20 >> Also, the latest linux kernel still has the X-Gene storm distributor >> address as "0x78010000" in the device tree, which is what the Xen code >> considers a match with the old firmware. What were the addresses for >> the device tree supposed to be changed to? Is my understanding >> correct that there is a different base address required to access the >> "non-secure" region instead of the "secure" 0x78010000 region? I'm >> trying to see if there are corresponding different addresses for the >> keystone K2E, but haven't found them yet in the manuals. >=20 > I went through the old emails archive but couldn't find a mention of the > other address, sorry. I think there is no other address as even though there would be one the Sec= ure status reported by the core would still say that you are running in sec= ure mode. I would really suggest to try to contact directly TI on that part to get an= official answer from them as they might have a workaround. Cheers Bertrand From xen-devel-bounces@lists.xenproject.org Tue Jun 16 07:57:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 07:57:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6T6-0001iB-Vx; Tue, 16 Jun 2020 07:57:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6T5-0001hz-T7 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 07:57:15 +0000 X-Inumbo-ID: fd4f66a0-afa6-11ea-b893-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fd4f66a0-afa6-11ea-b893-12813bfff9fa; Tue, 16 Jun 2020 07:57:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 401FCAC53; Tue, 16 Jun 2020 07:57:17 +0000 (UTC) Subject: Re: [PATCH for-4.13] tools/libxl: Fix memory leak in libxl_cpuid_set() To: Andrew Cooper References: <20200612173227.4103-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <0b7a42e1-23b2-536c-1c08-d2d540d590d0@suse.com> Date: Tue, 16 Jun 2020 09:57:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612173227.4103-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 19:32, Andrew Cooper wrote: > xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to > free() seeing as it discards the results. > > This is logically a backport of c/s b91825f628 "tools/libxc: Drop > config_transformed parameter from xc_cpuid_set()" but rewritten as one caller > of xc_cpuid_set() does use returned values. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich in case it helps. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 08:04:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 08:04:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6Zp-0003AB-1m; Tue, 16 Jun 2020 08:04:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6Zn-0003A6-W8 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 08:04:12 +0000 X-Inumbo-ID: f577b468-afa7-11ea-8496-bc764e2007e4 Received: from FRA01-PR2-obe.outbound.protection.outlook.com (unknown [40.107.12.59]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f577b468-afa7-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 08:04:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eINlkI8XYulyl2J0Z2VMQ3PQ9YyXQUUYugIAai6Btis=; b=Mt6TnnCISNgVMW4fwwL4rxjTMlRk1xByB7lo2LtdLQr8okvLs1gWO+pG1HQk2ViUcjYf1Z/UTpEpYcbephqRnfGjmoNUGdw1yXeSVghYf4gR5s96umZKKFl79KZt0ZOQhAu+Jt+YoK8DI8YuPsx2YdrRXtP6vIZVJcVI/EiXuZY= Received: from DB6PR07CA0097.eurprd07.prod.outlook.com (2603:10a6:6:2c::11) by PR2PR08MB4761.eurprd08.prod.outlook.com (2603:10a6:101:17::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.25; Tue, 16 Jun 2020 08:04:08 +0000 Received: from DB5EUR03FT017.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:2c:cafe::4c) by DB6PR07CA0097.outlook.office365.com (2603:10a6:6:2c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10 via Frontend Transport; Tue, 16 Jun 2020 08:04:08 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT017.mail.protection.outlook.com (10.152.20.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18 via Frontend Transport; Tue, 16 Jun 2020 08:04:08 +0000 Received: ("Tessian outbound 0dafac4cedb7:v59"); Tue, 16 Jun 2020 08:04:08 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 8bff545eda6cd084 X-CR-MTA-TID: 64aa7808 Received: from e0357805048d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id DD1E6462-4E88-4C78-B001-5399A71EB4B9.1; Tue, 16 Jun 2020 08:04:02 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e0357805048d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 16 Jun 2020 08:04:01 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nxcpfhDwgvzUwbImqfhYm20OFC5Unbk4olPwqhzdfuQeVOZ0gnioZYFHZe/Himp3bkiLGuhF6jub7TdrZwqnASNENFji4Pdgl9stvPi93A3jylEy+EKeerGQroDG/wiNkF+P81A/3n//T7eYVRtFC55XLB3n/U6/NiVTYSYdIt7M+YZjpmc2+zOcXal2jpBsxW6kn+JnkGqhgrUlHbQOT+hN6oHSuIw3b8WAPUKVxAftwsEDkB8yRQaKxKfttH0vo9ZojOCGJAa/I+2wHRFQuF0AUaw1bSicmr7H9vrSnG3FroEiTOu5DMDEp2t3OBixpCvK55EI6Fhmz2U0PwXPhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eINlkI8XYulyl2J0Z2VMQ3PQ9YyXQUUYugIAai6Btis=; b=oBIUyMScTD3yAY/+HU2ziPLCM3ulRLI2IjX94CLN9CZ1A6VWQWHiQU3U3zsLerwU5vWlnJ7qLWu7aoBbCBWE2dTOLHugwC1PoCQdaZPRaN6f1Iv4pu6jjeucKAxe5iqzx8PnVtp7kWwEKm0rOf3PvjdNDr+XXfndPy2VcMvzlIe/rirzEgMg0Rc/kDu9XwbDsOrFopH3XvlMnat6lRZ3L1Cu4Q2HBccOqeVANMMQoFsdH+XPNqkrMURexvBkjn6wq/VGubr7mp1aHlmTZLK29GgHjJu6oRLMj6qTPTHZlzH5uoC2ZgFCV9qxdxiqGKSQwGJq/zBIW7yAmJj91y68iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eINlkI8XYulyl2J0Z2VMQ3PQ9YyXQUUYugIAai6Btis=; b=Mt6TnnCISNgVMW4fwwL4rxjTMlRk1xByB7lo2LtdLQr8okvLs1gWO+pG1HQk2ViUcjYf1Z/UTpEpYcbephqRnfGjmoNUGdw1yXeSVghYf4gR5s96umZKKFl79KZt0ZOQhAu+Jt+YoK8DI8YuPsx2YdrRXtP6vIZVJcVI/EiXuZY= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3179.eurprd08.prod.outlook.com (2603:10a6:5:25::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.23; Tue, 16 Jun 2020 08:04:00 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3088.028; Tue, 16 Jun 2020 08:04:00 +0000 From: Bertrand Marquis To: Richard Simpson Subject: Re: ARM - Successful install on RockPro64 Thread-Topic: ARM - Successful install on RockPro64 Thread-Index: AQHWQ2ShrK3tkdZjw0a1QQM7WjbXL6ja4peA Date: Tue, 16 Jun 2020 08:03:59 +0000 Message-ID: <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> References: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> In-Reply-To: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: huskydog.org.uk; dkim=none (message not signed) header.d=none;huskydog.org.uk; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 857c4306-1060-40ed-02e7-08d811cbd882 x-ms-traffictypediagnostic: DB7PR08MB3179:|PR2PR08MB4761: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:8273; x-forefront-prvs: 04362AC73B X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: T/yLF0MAdWCmSxLNAHaakxxR52c0nrYwb7IPdhN5C9VE/HILo+c1/oq1XrH1SCdDQudLv89YyjdyY6awP5SiXfln+s2kBLv672qTRebp0J6bscan4JXOWbYzjEzy4MShptNQfgb4tbA+AL4LcEGFkvBQEl3SZrXn0HinKN+gFDoCUlETaik8kFz4I7MkWC2xYkXBb8qd5eYKGOpET1ftqUE68hqrOyyU6b6/OV9V7YALozGDBLKaIUPXbOeFVrYWcF49EhW0TKd2ry4shnAH8tkwWKO8wDwf2yLQfPTjIZQcAfbB78WGkvAwnbbGRIC4iwEMupVF2Q4QwfopLWIuuw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(346002)(396003)(376002)(39860400002)(66446008)(64756008)(71200400001)(83380400001)(4744005)(91956017)(26005)(478600001)(6486002)(86362001)(33656002)(2906002)(316002)(66476007)(76116006)(66556008)(8676002)(2616005)(5660300002)(6916009)(8936002)(54906003)(53546011)(6512007)(6506007)(186003)(36756003)(66946007)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yHJM7g7gLM8PyMIQoJgOoun3rL6ceoNiuuvda/W2EgwRJa4jb49LQZ9YjKiWMFPjzVDDGKHF8683xE5ZfywT6a5SafF/vOAvoXATl3fbHeQNCByap7cOSmJqZt7iahoyvGLvhAyNGHJNJYDJbKEAGvOdvJsyIbhylWhrod9ZVBEd2LEQpPi9o/FUsVd9hSee8YlhwzptKrxlVcZ8YTYmNJtjsfXqbK6jqXWtrH/WCHtgty1HGQITVDRdWs3NjOR3g94tZopEqmN0Kv4X5bpIVEqx+4IIlW2SiqwElw7a0bTFkLuAMq1cGOvaz4pIrokGdD/61IA9/mm12VA6Zty3xJg4nZNgRmJxloHFgXsJNNqOinBCeSh56iNe0r4/QEimUPnrkWQwxY7Xugw3nTFfmebGU8xJYcuZKIOQRTXBNN/1YY8WMViQQFpLdC9bwLKoedHjaP0KqAVXTXjReIKZfyscTh3EDfN2U+UOTvxFqEBvvQ/xKwUWmw+1IRpwIEUP x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3179 Original-Authentication-Results: huskydog.org.uk; dkim=none (message not signed) header.d=none;huskydog.org.uk; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT017.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(396003)(39860400002)(136003)(46966005)(54906003)(70206006)(316002)(82310400002)(70586007)(5660300002)(33656002)(356005)(81166007)(86362001)(8676002)(6512007)(82740400003)(2616005)(36756003)(26005)(478600001)(4744005)(186003)(47076004)(6506007)(53546011)(4326008)(83380400001)(8936002)(336012)(6486002)(6862004)(2906002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: a240e052-8f4f-45ce-8d65-08d811cbd3ae X-Forefront-PRVS: 04362AC73B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dwVnWkFPmeBzDqOM0MLrYnVkeGaVD1uT6CNZ9d1bGeopeSte6Hery5OMZXamZgJohLkmqd+bxDQfe/ERpSStcERTEPMWz+4DxaRJaYiDqmBn7ulbRUfeeYfzgwo9rmQgl9Toe3J0bXcUd35Hi8gA6rmQl48Ugl2UOMwI/dWh8BpJIrQHjiREfz8DYULQ6g8VFlFPfxQhBFb8xq16LELRkwr42EyGPn3qJL5udg6mx33TYG741nBQUBMRFfXTJdtKRg3LZ9mschWcJBnNjHagJL1k51lNVn5GN3kgB9lK5X9PhhZhxhUtP22EpJQmxiYusC2KNJnMKYC0XV4tqHE6+3OszJ4HMSWq982MrVCgwn6nOPMPFniFVoPNAxq/cnxIks2ic5zpseXMCRKW5yECMg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jun 2020 08:04:08.1287 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 857c4306-1060-40ed-02e7-08d811cbd882 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR2PR08MB4761 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Richard, + Julien and Stefano > On 15 Jun 2020, at 23:29, Richard Simpson wrote: >=20 > Hello, >=20 > Just to report that I have successfully installed Xen on a Pine RockPro64= ARM SBC. Very nice :-) >=20 > I am using Xen 4.13 booting directly from u-boot on an SD card and my dom= 0 distribution is Gentoo. >=20 > I haven't tried to create a domU yet and I am doing everything via the se= rial console so I can't say anything about the graphics. >=20 > My biggest hurdle (apart from understanding u-boot) was needing to apply = the vgic-v3: fix GICD_ISACTIVER patch. What version of Linux are you running ? I added Julien and Stefano so that we reactivate the discussion on this pat= ch. >=20 > I will be happy to provide more details when I have got a bit further, bu= t after two weeks of effort I was so delighted to finally be able to log in= to dom0 that I thought I'd better let somebody know. Thanks a lot for the notice, and congrats again :-) Cheers Bertrand From xen-devel-bounces@lists.xenproject.org Tue Jun 16 08:07:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 08:07:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6cf-0003Hb-Hy; Tue, 16 Jun 2020 08:07:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6ce-0003Gs-La for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 08:07:08 +0000 X-Inumbo-ID: 5f10e692-afa8-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5f10e692-afa8-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 08:07:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 15CCCAD17; Tue, 16 Jun 2020 08:07:09 +0000 (UTC) Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: Grzegorz Uriasz References: From: Jan Beulich Message-ID: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> Date: Tue, 16 Jun 2020 10:07:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 14.06.2020 16:36, Grzegorz Uriasz wrote: > --- a/xen/arch/x86/acpi/boot.c > +++ b/xen/arch/x86/acpi/boot.c > @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > if (fadt->xpm_timer_block.space_id == > ACPI_ADR_SPACE_SYSTEM_IO) { > pmtmr_ioport = fadt->xpm_timer_block.address; > - pmtmr_width = fadt->xpm_timer_block.bit_width; > + if (fadt->flags & ACPI_FADT_32BIT_TIMER) > + pmtmr_width = 32; > + else > + pmtmr_width = 24; I think disagreement of the two wants logging, and you want to default to using the smaller of the two (or even to ignoring the timer altogether). Then there wants to be a way to override (unless we already have one) our defaulting, in case it's wrong. Also I'd prefer if you used a conditional operator for this assignment. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 08:11:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 08:11:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6gr-00045m-6y; Tue, 16 Jun 2020 08:11:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6gp-00045h-Fn for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 08:11:27 +0000 X-Inumbo-ID: f9a06d2c-afa8-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f9a06d2c-afa8-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 08:11:26 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2F3522074D; Tue, 16 Jun 2020 08:11:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592295086; bh=+4hfCnfrKejwBOUH9Y3IYrX+s3fhQQ/NaFyWmhSainc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nXQT5Its5JMKrImg7kWJsBy0/t4FY4yDJuhGzAhpYrglWQm/tCfPEhly6wZKRkSPL PurfgBbUlHUPe0wQU50JA731B2U5GqyW1KhmJ/9VYC3r21/LNbU4ORcvWSKElXb+i6 vb0mX4LwsqNsWm1u/IKtVpw8NaRkanV7+K2uXyjY= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jl6gm-003Le2-FY; Tue, 16 Jun 2020 09:11:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 16 Jun 2020 09:11:24 +0100 From: Marc Zyngier To: CodeWiz2280 Subject: Re: Keystone Issue In-Reply-To: References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <4bab90465acfddae5868ce2311bd9889@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: codewiz2280@gmail.com, julien.grall.oss@gmail.com, Bertrand.Marquis@arm.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Bertrand Marquis , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-15 20:14, CodeWiz2280 wrote: [...] > Also, the latest linux kernel still has the X-Gene storm distributor > address as "0x78010000" in the device tree, which is what the Xen code > considers a match with the old firmware. What were the addresses for > the device tree supposed to be changed to? We usually don't care, as the GIC address is provided by the bootloader, whether via DT or ACPI (this is certainly what happens on Mustang). Whatever is still in the kernel tree is just as dead as the platform it describes. > Is my understanding > correct that there is a different base address required to access the > "non-secure" region instead of the "secure" 0x78010000 region? I'm > trying to see if there are corresponding different addresses for the > keystone K2E, but haven't found them yet in the manuals. There is no such address. Think of the NS bit as an *address space* identifier. The only reason XGene presents the NS part of the GIC at a different address is because XGene is broken enough not to have EL3, hence no secure mode. To wire the GIC (and other standard ARM IPs) to the core, the designers simply used the CPU NS signal as an address bit. On your platform, the NS bit does exist. I strongly suppose that it isn't wired to the GIC. Please talk to your SoC vendor for whether iot is possible to work around this. M. -- Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Tue Jun 16 08:20:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 08:20:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6pI-0004x4-34; Tue, 16 Jun 2020 08:20:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6pH-0004wz-F8 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 08:20:11 +0000 X-Inumbo-ID: 31c87180-afaa-11ea-b893-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 31c87180-afaa-11ea-b893-12813bfff9fa; Tue, 16 Jun 2020 08:20:10 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: JOYXLTr9zv/b1G07GcaAIU6MeekcuFiFnBqH0Ve2kdkm18NqJ5UI4TPpJZVMeZ+8ocqK5u9iz5 /UQl7RxtSRcXH83BBQ96THbVre7iVc8agwC3sOlw+NFlYzb/PeugK4aaT/c7HiGTxHFmVd/AxP 6D1yX6VZhEbZ+1/ji6L5sxJJjYnDDWP5avbOeWXxIFSzgLJhHJtiz17XUTN/xYRkzcgGOiM2kJ XrPW2rD9NVSwoVlVCVuQm3+Jr2q6XyHANrqLzlkZtbp6izfayKP+yNYY643IlkbjKbSm50WBqN V9A= X-SBRS: 2.7 X-MesageID: 20368986 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20368986" Date: Tue, 16 Jun 2020 10:20:02 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 v2 1/2] x86/passthrough: do not assert edge triggered GSIs for PVH dom0 Message-ID: <20200616082002.GK735@Air-de-Roger> References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-2-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 08:11:12AM +0200, Jan Beulich wrote: > On 10.06.2020 16:29, Roger Pau Monne wrote: > > @@ -186,9 +187,10 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) > > * to know if the GSI is pending or not. > > */ > > spin_lock(&d->arch.hvm.irq_lock); > > - if ( !hvm_irq->gsi_assert_count[gsi] ) > > + if ( trig == VIOAPIC_EDGE_TRIG || !hvm_irq->gsi_assert_count[gsi] ) > > { > > - hvm_irq->gsi_assert_count[gsi] = 1; > > + if ( trig == VIOAPIC_LEVEL_TRIG ) > > + hvm_irq->gsi_assert_count[gsi] = 1; > > Btw, along the lines of how you do things here, I think ... > > > @@ -196,11 +198,12 @@ void hvm_gsi_assert(struct domain *d, unsigned int gsi) > > > > void hvm_gsi_deassert(struct domain *d, unsigned int gsi) > > { > > + int trig = vioapic_get_trigger_mode(d, gsi); > > struct hvm_irq *hvm_irq = hvm_domain_irq(d); > > > > - if ( gsi >= hvm_irq->nr_gsis ) > > + if ( trig <= VIOAPIC_EDGE_TRIG || gsi >= hvm_irq->nr_gsis ) > > ... this would better have been "trig != VIOAPIC_LEVEL_TRIG", to > avoid the code being dependent upon the actual values of both > VIOAPIC_*_TRIG constants. Sure, let me send a follow up patch, it's trivial to fix. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 08:26:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 08:26:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6v1-000576-Oo; Tue, 16 Jun 2020 08:26:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl6v0-000571-Kf for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 08:26:06 +0000 X-Inumbo-ID: 044f7284-afab-11ea-b893-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 044f7284-afab-11ea-b893-12813bfff9fa; Tue, 16 Jun 2020 08:26:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7A487ABCE; Tue, 16 Jun 2020 08:26:06 +0000 (UTC) Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Julien Grall References: <20200613184132.11880-1-julien@xen.org> From: Jan Beulich Message-ID: <61a4dccf-4dc8-11a7-7428-f48e39b05276@suse.com> Date: Tue, 16 Jun 2020 10:26:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200613184132.11880-1-julien@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 13.06.2020 20:41, Julien Grall wrote: > @@ -73,10 +76,18 @@ struct xen_pvcalls_request { > uint32_t flags; > grant_ref_t ref; > uint32_t evtchn; > +#ifndef __i386__ > + uint8_t pad[4]; > +#endif Where possible I think uint32_t would be slightly better to use. > } connect; > struct xen_pvcalls_release { > uint64_t id; > uint8_t reuse; > +#ifndef __i386__ > + uint8_t pad[7]; > +#else > + uint8_t pad[3]; > +#endif For this I'd recommend uniform "uint8_t pad[3];" (i.e. outside of any #ifdef) followed by a uint32_t again inside the #ifdef. Expressing everything through e.g. alignof() would seem even better, but I can't currently think of a way to do so cleanly. In any event - I'm not the maintainer of these headers, so it may be just me ... Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 08:32:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 08:32:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl71R-0005w6-GE; Tue, 16 Jun 2020 08:32:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl71P-0005w1-OK for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 08:32:43 +0000 X-Inumbo-ID: f152f76a-afab-11ea-b894-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f152f76a-afab-11ea-b894-12813bfff9fa; Tue, 16 Jun 2020 08:32:42 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id F0E40AAE8; Tue, 16 Jun 2020 08:32:44 +0000 (UTC) Subject: Re: [PATCH v19 for-4.14 00/13] VM forking To: Tamas K Lengyel References: From: Jan Beulich Message-ID: <12d37927-5608-b497-67cc-eb5436fa0b78@suse.com> Date: Tue, 16 Jun 2020 10:32:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Tamas K Lengyel , Jun Nakajima , Anthony PERARD , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 01.06.2020 15:21, Tamas K Lengyel wrote: > Tamas K Lengyel (13): > x86/mem_sharing: block interrupt injection for forks > tools/libxc: xc_memshr_fork with interrupts blocked I've committed these two, and I'll leave the rest to the tool stack maintainers. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 08:33:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 08:33:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl72H-000647-Sw; Tue, 16 Jun 2020 08:33:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl72F-00062D-No for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 08:33:35 +0000 X-Inumbo-ID: 0c4deae6-afac-11ea-8496-bc764e2007e4 Received: from gordon.huskydog.org.uk (unknown [81.187.95.156]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 0c4deae6-afac-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 08:33:26 +0000 (UTC) Received: from [10.137.3.12] (percyq.huskydog.org.uk [10.42.42.111]) by gordon.huskydog.org.uk (Postfix) with ESMTP id 012954BF2C; Tue, 16 Jun 2020 09:33:24 +0100 (BST) Subject: Re: ARM - Successful install on RockPro64 To: Bertrand Marquis References: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> From: Richard Simpson Message-ID: Date: Tue, 16 Jun 2020 09:33:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Dear Bertrand, Just to confirm that the Linux distro is Gentoo.  I know it's not very common these days, but I have used it for very many years and it is what I am used to. Gentoo has a xen package but only for arm32 and then masked as unstable so I just grabbed 4.13 via git.  It also has a xen-tools package which is packaged for arm64 (although still masked as unstable) so I unmasked and used that.  There were a couple of dependency problems with the package but after I resolved those it seemed to work OK. There is also a Gentoo u-boot tools package for arm64 but again I got u-boot via git. I would be happy to try to report my success via the smoke test page (https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results) if I can figure out how.  Strangely, I can't see anything listed under "Test Results" from anyone else.  Perhaps it is a problem with my browser. I also notice an instruction which reads "Test hypervisor functionalities: clone raisin on the platform and run ./raise test".  I can try to do this if it will help.  Do I just run "git clone " and then presumably the test prints out some results? Happy to try a beta version of Xen if you decide to include the patch and I can also try some of the interrupt config options if you want. Cheers,     Richard On 6/16/20 9:03 AM, Bertrand Marquis wrote: > Hi Richard, > > + Julien and Stefano > >> On 15 Jun 2020, at 23:29, Richard Simpson wrote: >> >> Hello, >> >> Just to report that I have successfully installed Xen on a Pine RockPro64 ARM SBC. > Very nice :-) > >> I am using Xen 4.13 booting directly from u-boot on an SD card and my dom0 distribution is Gentoo. >> >> I haven't tried to create a domU yet and I am doing everything via the serial console so I can't say anything about the graphics. >> >> My biggest hurdle (apart from understanding u-boot) was needing to apply the vgic-v3: fix GICD_ISACTIVER patch. > What version of Linux are you running ? > I added Julien and Stefano so that we reactivate the discussion on this patch. > >> I will be happy to provide more details when I have got a bit further, but after two weeks of effort I was so delighted to finally be able to log into dom0 that I thought I'd better let somebody know. > Thanks a lot for the notice, and congrats again :-) > > Cheers > Bertrand > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 08:37:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 08:37:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl75k-0006G6-EV; Tue, 16 Jun 2020 08:37:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl75j-0006G1-B7 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 08:37:11 +0000 X-Inumbo-ID: 91cb8e08-afac-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 91cb8e08-afac-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 08:37:10 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Z/ZNyfjJA3+IgJN2CawebcoSsjoGtrTZpcTMb2wqPHe2xP8XA+e1Wb+2tI/9jDr+f6beTRp1Cs CBrHl9BeRgeNCfKlp2Yv5XcrWBjx1hyxDzILugHx/qtvdtjRPG9551Cf2TogqPU1YXlEGggLTJ rcLvmA6fhfTc+YNq6kHHhjMRdJJNZTr6yjHouqwXqqFALzRvxZ5yR2rUJ5fvuiXHo4U/BGSWNf r/56Dco3WHHqELI1wCj/y+HdiwfVoqFNU6D0eEk8ClUMcDEP/bBOp30UYHb2CvhPbch/mZl/Tz Aqs= X-SBRS: 2.7 X-MesageID: 20481905 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20481905" Date: Tue, 16 Jun 2020 10:37:01 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask Message-ID: <20200616083701.GL735@Air-de-Roger> References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> <1ccfdfdf-695e-00ce-7d49-401b1f4bb015@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <1ccfdfdf-695e-00ce-7d49-401b1f4bb015@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 08:27:54AM +0200, Jan Beulich wrote: > On 10.06.2020 16:29, Roger Pau Monne wrote: > > @@ -558,6 +559,12 @@ int pt_irq_create_bind( > > */ > > ASSERT(!mask); > > share = trigger_mode; > > + if ( trigger_mode == VIOAPIC_EDGE_TRIG ) > > + /* > > + * Edge IO-APIC interrupt, no EOI or unmask to perform > > + * and hence no timer needed. > > + */ > > + pirq_dpci->flags |= HVM_IRQ_DPCI_NO_EOI; > > Is this really limited to edge triggered IO-APIC interrupts? > MSI ones are effectively edge triggered too, aren't they? MSIs do sometimes require an EOI, depending on whether they can be masked, see irq_acktype. > Along the lines of irq_acktype() maskable MSI may then also > not need any such arrangements? The pirq_guest_eoi() -> > desc_guest_eoi() path looks to confirm this. Yes, that's correct. AFAICT MSI interrupts won't get the EOI timer, since pt_irq_need_timer will return false because the HVM_IRQ_DPCI_GUEST_MSI flag will be set. > > @@ -920,6 +923,8 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) > > if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI ) > > { > > hvm_gsi_assert(d, pirq->pirq); > > + if ( pirq_dpci->flags & HVM_IRQ_DPCI_NO_EOI ) > > + goto out; > > Immediately ahead of this there's a similar piece of code > dealing with PCI INTx. They're commonly level triggered, but > I don't think there's a strict need for this to be the case. > At least hvm_pci_intx_assert() -> assert_gsi() -> > vioapic_irq_positive_edge() also cover the edge triggered one. Hm, I'm not sure it's safe to passthrough edge triggered IO-APIC interrupts, as Xen will mark those as 'shared' always, and sharing edge interrupts cannot reliably work. In any case the EOI timer is definitely set for those, and needs to be disabled before exiting hvm_dirq_assist. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 08:46:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 08:46:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7EE-00077p-9s; Tue, 16 Jun 2020 08:45:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7ED-00077k-DW for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 08:45:57 +0000 X-Inumbo-ID: c9951718-afad-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c9951718-afad-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 08:45:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B5E03AD7B; Tue, 16 Jun 2020 08:45:56 +0000 (UTC) Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> <1ccfdfdf-695e-00ce-7d49-401b1f4bb015@suse.com> <20200616083701.GL735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 10:45:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200616083701.GL735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 10:37, Roger Pau Monné wrote: > On Tue, Jun 16, 2020 at 08:27:54AM +0200, Jan Beulich wrote: >> On 10.06.2020 16:29, Roger Pau Monne wrote: >>> @@ -920,6 +923,8 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) >>> if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI ) >>> { >>> hvm_gsi_assert(d, pirq->pirq); >>> + if ( pirq_dpci->flags & HVM_IRQ_DPCI_NO_EOI ) >>> + goto out; >> >> Immediately ahead of this there's a similar piece of code >> dealing with PCI INTx. They're commonly level triggered, but >> I don't think there's a strict need for this to be the case. >> At least hvm_pci_intx_assert() -> assert_gsi() -> >> vioapic_irq_positive_edge() also cover the edge triggered one. > > Hm, I'm not sure it's safe to passthrough edge triggered IO-APIC > interrupts, as Xen will mark those as 'shared' always, and sharing > edge interrupts cannot reliably work. In any case the EOI timer is > definitely set for those, and needs to be disabled before exiting > hvm_dirq_assist. That's the if ( !is_hardware_domain(d) ) share = BIND_PIRQ__WILL_SHARE; in pt_irq_create_bind() aiui? I wonder why we have that ... At a guess it's to accommodate pciback in Dom0 also registering a handler. But wasn't it XenoLinux'es pciback only that does so, and upstream's doesn't? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 09:01:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 09:01:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7Sv-0000Lk-LP; Tue, 16 Jun 2020 09:01:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7St-0000Lf-ST for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 09:01:07 +0000 X-Inumbo-ID: e9e1c726-afaf-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e9e1c726-afaf-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 09:01:07 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id DE5F3AD63; Tue, 16 Jun 2020 09:01:09 +0000 (UTC) Subject: Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-3-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <768730e4-955c-e170-7ae6-58ea775cc6de@suse.com> Date: Tue, 16 Jun 2020 11:01:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200615141532.1927-3-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 16:15, Andrew Cooper wrote: > The existing x86_cpuid_copy_to_buffer() does produce sorted results, and we're > about to start relying on this. Extend the unit tests. > > As test_cpuid_serialise_success() is a fairly limited set of synthetic > examples right now, introduce test_cpuid_current() to operate on the full > policy for the current CPU. > > Tweak the fail() macro to allow for simplified control flow. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Tue Jun 16 09:16:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 09:16:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7hs-0001LB-52; Tue, 16 Jun 2020 09:16:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7hr-0001L6-Bj for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 09:16:35 +0000 X-Inumbo-ID: 124fbc8e-afb2-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 124fbc8e-afb2-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 09:16:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AF484AD76; Tue, 16 Jun 2020 09:16:36 +0000 (UTC) Subject: Re: [PATCH 3/9] tools/libx[cl]: Move processing loop down into xc_cpuid_set() To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-4-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <7ac49edf-1a8c-435d-0b5b-96496432e9f6@suse.com> Date: Tue, 16 Jun 2020 11:16:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200615141532.1927-4-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 16:15, Andrew Cooper wrote: > Currently, libxl__cpuid_legacy() passes each element of the policy list to > xc_cpuid_set() individually. This is wasteful both in terms of the number of > hypercalls made, and the quantity of repeated merging/auditing work performed > by Xen. > > Move the loop processing down into xc_cpuid_set(), which allows us to do one > set of hypercalls, rather than one per list entry. > > In xc_cpuid_set(), obtain the full host, guest max and current policies to > begin with, and loop over the xend array, processing one leaf at a time. > Replace the linear search with a binary search, seeing as the serialised > leaves are sorted. > > No change in behaviour from the guests point of view. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich with a few remarks: > @@ -286,99 +311,101 @@ int xc_cpuid_set( > } > > rc = -ENOMEM; > - if ( (leaves = calloc(nr_leaves, sizeof(*leaves))) == NULL ) > + if ( (host = calloc(nr_leaves, sizeof(*host))) == NULL || > + (max = calloc(nr_leaves, sizeof(*max))) == NULL || > + (cur = calloc(nr_leaves, sizeof(*cur))) == NULL ) > { > ERROR("Unable to allocate memory for %u CPUID leaves", nr_leaves); > goto fail; > } > > + /* Get the domain's current policy. */ > + nr_msrs = 0; > + nr_cur = nr_leaves; > + rc = xc_get_domain_cpu_policy(xch, domid, &nr_cur, cur, &nr_msrs, NULL); > + if ( rc ) > + { > + PERROR("Failed to obtain d%d current policy", domid); > + rc = -errno; > + goto fail; > + } > + > /* Get the domain's max policy. */ > nr_msrs = 0; > - policy_leaves = nr_leaves; > + nr_max = nr_leaves; > rc = xc_get_system_cpu_policy(xch, di.hvm ? XEN_SYSCTL_cpu_policy_hvm_max > : XEN_SYSCTL_cpu_policy_pv_max, > - &policy_leaves, leaves, &nr_msrs, NULL); > + &nr_max, max, &nr_msrs, NULL); > if ( rc ) > { > PERROR("Failed to obtain %s max policy", di.hvm ? "hvm" : "pv"); > rc = -errno; > goto fail; > } > - for ( i = 0; i < policy_leaves; ++i ) > - if ( leaves[i].leaf == xend->leaf && > - leaves[i].subleaf == xend->subleaf ) > - { > - polregs[0] = leaves[i].a; > - polregs[1] = leaves[i].b; > - polregs[2] = leaves[i].c; > - polregs[3] = leaves[i].d; > - break; > - } > > /* Get the host policy. */ > nr_msrs = 0; > - policy_leaves = nr_leaves; > + nr_host = nr_leaves; > rc = xc_get_system_cpu_policy(xch, XEN_SYSCTL_cpu_policy_host, > - &policy_leaves, leaves, &nr_msrs, NULL); > + &nr_host, host, &nr_msrs, NULL); > if ( rc ) > { > PERROR("Failed to obtain host policy"); > rc = -errno; > goto fail; > } > - for ( i = 0; i < policy_leaves; ++i ) > - if ( leaves[i].leaf == xend->leaf && > - leaves[i].subleaf == xend->subleaf ) > - { > - regs[0] = leaves[i].a; > - regs[1] = leaves[i].b; > - regs[2] = leaves[i].c; > - regs[3] = leaves[i].d; > - break; > - } > > - for ( i = 0; i < 4; i++ ) > + rc = -EINVAL; > + for ( ; xend->leaf != XEN_CPUID_INPUT_UNUSED; ++xend ) > { > - if ( xend->policy[i] == NULL ) > + xen_cpuid_leaf_t *cur_leaf = find_leaf(cur, nr_cur, xend); > + const xen_cpuid_leaf_t *max_leaf = find_leaf(max, nr_max, xend); > + const xen_cpuid_leaf_t *host_leaf = find_leaf(host, nr_host, xend); > + > + if ( cur_leaf == NULL || max_leaf == NULL || host_leaf == NULL ) > { > - regs[i] = polregs[i]; > - continue; > + ERROR("Missing leaf %#x, subleaf %#x", xend->leaf, xend->subleaf); > + goto fail; > } > > - /* > - * Notes for following this algorithm: > - * > - * While it will accept any leaf data, it only makes sense to use on > - * feature leaves. regs[] initially contains the host values. This, > - * with the fall-through chain, is how the 's' and 'k' options work. > - */ > - for ( j = 0; j < 32; j++ ) > + for ( int i = 0; i < 4; i++ ) As you move the declaration here, perhaps switch to unsigned int as well? And express 4 as ARRAY_SIZE()? > { > - unsigned char val = !!((regs[i] & (1U << (31 - j)))); > - unsigned char polval = !!((polregs[i] & (1U << (31 - j)))); > - > - rc = -EINVAL; > - if ( !strchr("10xks", xend->policy[i][j]) ) > - goto fail; > - > - if ( xend->policy[i][j] == '1' ) > - val = 1; > - else if ( xend->policy[i][j] == '0' ) > - val = 0; > - else if ( xend->policy[i][j] == 'x' ) > - val = polval; > - > - if ( val ) > - set_feature(31 - j, regs[i]); > - else > - clear_feature(31 - j, regs[i]); > + uint32_t *cur_reg = &cur_leaf->a + i; > + const uint32_t *max_reg = &max_leaf->a + i; > + const uint32_t *host_reg = &host_leaf->a + i; > + > + if ( xend->policy[i] == NULL ) > + continue; > + > + for ( int j = 0; j < 32; j++ ) unsigned int again? I don't think there's a suitable array available to also use ARRAY_SIZE() here. > + { > + bool val; > + > + if ( xend->policy[i][j] == '1' ) > + val = true; > + else if ( xend->policy[i][j] == '0' ) > + val = false; > + else if ( xend->policy[i][j] == 'x' ) > + val = test_bit(31 - j, max_reg); Still seeing "max" used here is somewhat confusing given the purpose of the series, and merely judging from the titles I can't yet spot where later on it'll change. But I assume it will ... Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 09:19:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 09:19:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7kU-0001TG-JP; Tue, 16 Jun 2020 09:19:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7kT-0001TB-Pd for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 09:19:17 +0000 X-Inumbo-ID: 73f97da8-afb2-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 73f97da8-afb2-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 09:19:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uNcSOBRJ4m/G3cKvPiPnd/BSRd1yzcUjdLL1eQmZ7sU=; b=4VvClosMytF8N2JJYPZuK+1J/o Mg9kRhCrY3zVrm+IOiblwjlmb2j0BRveeVZbbbIZtuymC8o1DDqFQxVruh0Gaa3yC3RJodQHwAieN aysN1bgrAPbBS41MR7U98mcWjuT8FQ1v9TlS2tu8m33RJN3uBQjE6mLYRWHPHTDx3hIw=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7kQ-0001pV-K9; Tue, 16 Jun 2020 09:19:14 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jl7kQ-0004r9-Cl; Tue, 16 Jun 2020 09:19:14 +0000 Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Jan Beulich References: <20200613184132.11880-1-julien@xen.org> <61a4dccf-4dc8-11a7-7428-f48e39b05276@suse.com> From: Julien Grall Message-ID: <035d1085-c08c-3dee-6e9b-faf245ef660d@xen.org> Date: Tue, 16 Jun 2020 10:19:11 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <61a4dccf-4dc8-11a7-7428-f48e39b05276@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 09:26, Jan Beulich wrote: > On 13.06.2020 20:41, Julien Grall wrote: >> @@ -73,10 +76,18 @@ struct xen_pvcalls_request { >> uint32_t flags; >> grant_ref_t ref; >> uint32_t evtchn; >> +#ifndef __i386__ >> + uint8_t pad[4]; >> +#endif > > Where possible I think uint32_t would be slightly better to use. OOI, why? > >> } connect; >> struct xen_pvcalls_release { >> uint64_t id; >> uint8_t reuse; >> +#ifndef __i386__ >> + uint8_t pad[7]; >> +#else >> + uint8_t pad[3]; >> +#endif > > For this I'd recommend uniform "uint8_t pad[3];" (i.e. outside > of any #ifdef) followed by a uint32_t again inside the #ifdef. Same question here. The more the padding cannot be re-used. > > Expressing everything through e.g. alignof() would seem even > better, but I can't currently think of a way to do so cleanly. I am afraid I don't have time to look at how alignof() can work nicely. Feel free to send a follow-up or pick-up the patch is you really want alignof(). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 16 09:28:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 09:28:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7t5-0002M3-Gp; Tue, 16 Jun 2020 09:28:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7t3-0002Ly-SN for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 09:28:09 +0000 X-Inumbo-ID: b06d6910-afb3-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b06d6910-afb3-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 09:28:08 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: eQFrrBdh0PW+LPVbxsfcSClVVY4OOjPhWXHCbAhLQ7tiDzmnaxKnyqUBhJ+xuePfPBqRDPvWGW KjGF6DaZzfKkkvdkkwa67yC61itTkslCxiJrZGQBgfKEFUdcX2m33lsiXBAUAuQFQsyjaY4rw9 G3FLvtwEft9eRqQnDMAc+5s6RSvtvUANh7Y2hNzIJ0nH349aEfXkfc3m/RINSUhRLc83VkwkZ7 4rfqzNX7UY2Ld66fsjIdiTYGZRKVeltw0yMYauuVaOBKRrq4osGqyx+EsWSbjPCFkigjFA6TW/ n9o= X-SBRS: 2.7 X-MesageID: 20485486 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20485486" Date: Tue, 16 Jun 2020 11:28:00 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask Message-ID: <20200616092800.GM735@Air-de-Roger> References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> <1ccfdfdf-695e-00ce-7d49-401b1f4bb015@suse.com> <20200616083701.GL735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 10:45:51AM +0200, Jan Beulich wrote: > On 16.06.2020 10:37, Roger Pau Monné wrote: > > On Tue, Jun 16, 2020 at 08:27:54AM +0200, Jan Beulich wrote: > >> On 10.06.2020 16:29, Roger Pau Monne wrote: > >>> @@ -920,6 +923,8 @@ static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci) > >>> if ( pirq_dpci->flags & HVM_IRQ_DPCI_IDENTITY_GSI ) > >>> { > >>> hvm_gsi_assert(d, pirq->pirq); > >>> + if ( pirq_dpci->flags & HVM_IRQ_DPCI_NO_EOI ) > >>> + goto out; > >> > >> Immediately ahead of this there's a similar piece of code > >> dealing with PCI INTx. They're commonly level triggered, but > >> I don't think there's a strict need for this to be the case. > >> At least hvm_pci_intx_assert() -> assert_gsi() -> > >> vioapic_irq_positive_edge() also cover the edge triggered one. > > > > Hm, I'm not sure it's safe to passthrough edge triggered IO-APIC > > interrupts, as Xen will mark those as 'shared' always, and sharing > > edge interrupts cannot reliably work. In any case the EOI timer is > > definitely set for those, and needs to be disabled before exiting > > hvm_dirq_assist. > > That's the > > if ( !is_hardware_domain(d) ) > share = BIND_PIRQ__WILL_SHARE; > > in pt_irq_create_bind() aiui? I wonder why we have that ... At a > guess it's to accommodate pciback in Dom0 also registering a handler. > But wasn't it XenoLinux'es pciback only that does so, and upstream's > doesn't? I'm not that familiar with pciback in Linux. I've taken a look and AFAICT modern Linux kernels will register a handler for the PCI interrupts before doing a device reset and when dealing with PV guests that use the pciif protocol (note that such IRQ is also unconditionally marked as shared in Linux). It might be safe for HVM domU passed through interrupts to set the share bit based on the triggering mode. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 09:33:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 09:33:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7yZ-0003A3-5M; Tue, 16 Jun 2020 09:33:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl7yX-00039y-Mx for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 09:33:49 +0000 X-Inumbo-ID: 78d06237-afb4-11ea-b89b-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 78d06237-afb4-11ea-b89b-12813bfff9fa; Tue, 16 Jun 2020 09:33:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 88627AD45; Tue, 16 Jun 2020 09:33:47 +0000 (UTC) Subject: Re: [PATCH 7/9] x86/hvm: Disable MPX by default To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-8-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <58d7254d-8953-93c4-9eb2-9be45f39bc4e@suse.com> Date: Tue, 16 Jun 2020 11:33:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200615141532.1927-8-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 16:15, Andrew Cooper wrote: > @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, > goto out; > } > > + /* > + * Account for feature which have been disabled by default since Xen 4.13, > + * so migrated-in VM's don't risk seeing features disappearing. > + */ > + if ( restore ) > + { > + if ( di.hvm ) > + { > + p->feat.mpx = test_bit(X86_FEATURE_MPX, host_featureset); Why do you derive this from the host featureset instead of the max one for the guest type? Also, while you modify p here, ... > + } > + } > + > if ( featureset ) > { > uint32_t disabled_features[FEATURESET_NR_ENTRIES], ... the code in this if()'s body ignores p altogether. I realize the only caller of the function passes NULL for "featureset", but I'd like to understand the rationale here anyway before giving an R-b. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 09:36:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 09:36:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl80v-0003H8-IV; Tue, 16 Jun 2020 09:36:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl80u-0003Gu-Cf for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 09:36:16 +0000 X-Inumbo-ID: d2ba3fd8-afb4-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d2ba3fd8-afb4-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 09:36:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 34D83AD6A; Tue, 16 Jun 2020 09:36:18 +0000 (UTC) Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Julien Grall References: <20200613184132.11880-1-julien@xen.org> <61a4dccf-4dc8-11a7-7428-f48e39b05276@suse.com> <035d1085-c08c-3dee-6e9b-faf245ef660d@xen.org> From: Jan Beulich Message-ID: <0dd2ffb5-88ff-114f-6127-5bbcc5eed1ae@suse.com> Date: Tue, 16 Jun 2020 11:36:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <035d1085-c08c-3dee-6e9b-faf245ef660d@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 11:19, Julien Grall wrote: > > > On 16/06/2020 09:26, Jan Beulich wrote: >> On 13.06.2020 20:41, Julien Grall wrote: >>> @@ -73,10 +76,18 @@ struct xen_pvcalls_request { >>> uint32_t flags; >>> grant_ref_t ref; >>> uint32_t evtchn; >>> +#ifndef __i386__ >>> + uint8_t pad[4]; >>> +#endif >> >> Where possible I think uint32_t would be slightly better to use. > > OOI, why? Because everything else here uses the wider type, plus the question of why use a compound type (array) when a simple one does. >> >>> } connect; >>> struct xen_pvcalls_release { >>> uint64_t id; >>> uint8_t reuse; >>> +#ifndef __i386__ >>> + uint8_t pad[7]; >>> +#else >>> + uint8_t pad[3]; >>> +#endif >> >> For this I'd recommend uniform "uint8_t pad[3];" (i.e. outside >> of any #ifdef) followed by a uint32_t again inside the #ifdef. > > Same question here. The more the padding cannot be re-used. > >> >> Expressing everything through e.g. alignof() would seem even >> better, but I can't currently think of a way to do so cleanly. > > I am afraid I don't have time to look at how alignof() can work nicely. > Feel free to send a follow-up or pick-up the patch is you really want > alignof(). I didn't mean to ask that you find a solution. I merely pointed out that expressing things properly rather than using hard coded numbers would be nice. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 09:40:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 09:40:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl84T-0003Qs-2h; Tue, 16 Jun 2020 09:39:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl84R-0003Qn-Tm for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 09:39:56 +0000 X-Inumbo-ID: 54d85e64-afb5-11ea-b89c-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 54d85e64-afb5-11ea-b89c-12813bfff9fa; Tue, 16 Jun 2020 09:39:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=dIVZIIj1oHbuogxwyQF6MVp3lZJUeLEuAu2G6vtH048=; b=hkyEwY3gD/D0PVBl13djH3mhJo fWkWTjh8Pv4uCSp7qXoPlxSEbMZJgtbYExqdUF1UiOxNWFvj0EnwCYb5QpDXvJ+se0/05zseKHR7x 1i3lbkR+7j5xv7xWQF3HmKOHxubhQp7/HUO0x3Rc0c8sKGl7pOvcM+k2gMv2n3ca9QQI=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl84M-0002DL-QQ; Tue, 16 Jun 2020 09:39:50 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jl84M-0005vR-Je; Tue, 16 Jun 2020 09:39:50 +0000 Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Stefano Stabellini References: <20200613184132.11880-1-julien@xen.org> From: Julien Grall Message-ID: <35c8373f-b691-d95e-17de-021c72faf216@xen.org> Date: Tue, 16 Jun 2020 10:39:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 16/06/2020 02:00, Stefano Stabellini wrote: > On Sat, 13 Jun 2020, Julien Grall wrote: >> From: Julien Grall >> >> The documentation of pvcalls suggests there is padding for 32-bit x86 >> at the end of most the structure. However, they are not described in >> in the public header. >> >> Because of that all the structures would be 32-bit aligned and not >> 64-bit aligned for 32-bit x86. >> >> For all the other architectures supported (Arm and 64-bit x86), the >> structure are aligned to 64-bit because they contain uint64_t field. >> Therefore all the structures contain implicit padding. >> >> The paddings are now corrected for 32-bit x86 and written explicitly for >> all the architectures. >> >> While the structure size between 32-bit and 64-bit x86 is different, it >> shouldn't cause any incompatibility between a 32-bit and 64-bit >> frontend/backend because the commands are always 56 bits and the padding >> are at the end of the structure. >> >> As an aside, the padding sadly cannot be mandated to be 0 as they are >> already present. So it is not going to be possible to use the padding >> for extending a command in the future. >> >> Signed-off-by: Julien Grall >> >> --- >> Changes in v3: >> - Use __i386__ rather than CONFIG_X86_32 >> >> Changes in v2: >> - It is not possible to use the same padding for 32-bit x86 and >> all the other supported architectures. >> --- >> docs/misc/pvcalls.pandoc | 18 ++++++++++-------- >> xen/include/public/io/pvcalls.h | 14 ++++++++++++++ >> 2 files changed, 24 insertions(+), 8 deletions(-) >> >> diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc >> index 665dad556c39..caa71b36d78b 100644 >> --- a/docs/misc/pvcalls.pandoc >> +++ b/docs/misc/pvcalls.pandoc >> @@ -246,9 +246,9 @@ The format is defined as follows: >> uint32_t domain; >> uint32_t type; >> uint32_t protocol; >> - #ifdef CONFIG_X86_32 >> + #ifndef __i386__ >> uint8_t pad[4]; >> - #endif >> + #endif > > > Hi Julien, > > Thank you for doing this, and sorry for having missed v2 of this patch, I > should have replied earlier. > > The intention of the #ifdef blocks like: > > #ifdef CONFIG_X86_32 > uint8_t pad[4]; > #endif > > in pvcalls.pandoc was to make sure that these structs would be 64bit > aligned on x86_32 too. > > I realize that the public header doesn't match, but the spec is the > "master copy". So far, the public headers are the defacto official ABI. So did you mark the pvcall header as just a reference? > We have been saying it for a while (Andy in particular) > that the specification documents are the one that define the protocol, > not the public headers. This is the very first time we get to act on > that statement. What a special occasion this is :-) > > So I think we should keep the specification as is and fix the public > header instead. Something like v1 of this patch. Well, the header is now part of multiple open-source projects (don't know about private). So adding padding will result to incompatibility between two x86 32-bit entities that may disagree on the ABI if they are using the per-command structure. TBH, I don't think the issue is worth the breakage here. You will never be able to use those paddings in any case as they are not reserved as 0. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 16 09:40:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 09:40:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl85P-000498-GX; Tue, 16 Jun 2020 09:40:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl85O-000490-Lo for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 09:40:54 +0000 X-Inumbo-ID: 78b69c1a-afb5-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 78b69c1a-afb5-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 09:40:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 349B1AFA8; Tue, 16 Jun 2020 09:40:57 +0000 (UTC) Subject: Re: [PATCH 8/9] x86/cpuid: Introduce missing feature adjustment in calculate_pv_def_policy() To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-9-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <9e27fb33-91d3-1a20-c956-24a0e0f28764@suse.com> Date: Tue, 16 Jun 2020 11:40:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200615141532.1927-9-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 16:15, Andrew Cooper wrote: > This was an accidental asymmetry with the HVM side. > > No change in behaviour at this point. > > Fixes: 83b387382 ("x86/cpuid: Introduce and use default CPUID policies") > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich with a remark: > --- a/xen/arch/x86/cpuid.c > +++ b/xen/arch/x86/cpuid.c > @@ -402,6 +402,8 @@ static void __init calculate_pv_def_policy(void) > for ( i = 0; i < ARRAY_SIZE(pv_featureset); ++i ) > pv_featureset[i] &= pv_def_featuremask[i]; > > + guest_common_feature_adjustments(pv_featureset); > + > sanitise_featureset(pv_featureset); > cpuid_featureset_to_policy(pv_featureset, p); > recalculate_xstate(p); These four calls are common to all three callers of the function. Perhaps them going out of sync would be less likely if all four called the same helper to carry out these four steps? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 09:42:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 09:42:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl879-0004HV-SX; Tue, 16 Jun 2020 09:42:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl878-0004HQ-R9 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 09:42:42 +0000 X-Inumbo-ID: b979119c-afb5-11ea-b89c-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b979119c-afb5-11ea-b89c-12813bfff9fa; Tue, 16 Jun 2020 09:42:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lAm2g1ojc6VEH7hmyiVMF3fiK5iNLWUygyth59wbesw=; b=En8AvKtDEWR53zg1NP60xgO/qg rlhq4CAFeDizwYNvPVhL0naKnZa4UUVOYx4/0Yt3xiGNT+JdZ8oi1/uWQVJxp4VpfL8mq/oGfUEIU enTtL5wBhr+S5niTe5FK6FWz8YAmuV/+kFlLcRNRKpF+mQi5kd9lbROUsWV9N1zdYPFs=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl875-0002Ha-Vn; Tue, 16 Jun 2020 09:42:39 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jl875-00062N-PN; Tue, 16 Jun 2020 09:42:39 +0000 Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Jan Beulich References: <20200613184132.11880-1-julien@xen.org> <61a4dccf-4dc8-11a7-7428-f48e39b05276@suse.com> <035d1085-c08c-3dee-6e9b-faf245ef660d@xen.org> <0dd2ffb5-88ff-114f-6127-5bbcc5eed1ae@suse.com> From: Julien Grall Message-ID: Date: Tue, 16 Jun 2020 10:42:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <0dd2ffb5-88ff-114f-6127-5bbcc5eed1ae@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 10:36, Jan Beulich wrote: > On 16.06.2020 11:19, Julien Grall wrote: >> >> >> On 16/06/2020 09:26, Jan Beulich wrote: >>> On 13.06.2020 20:41, Julien Grall wrote: >>>> @@ -73,10 +76,18 @@ struct xen_pvcalls_request { >>>> uint32_t flags; >>>> grant_ref_t ref; >>>> uint32_t evtchn; >>>> +#ifndef __i386__ >>>> + uint8_t pad[4]; >>>> +#endif >>> >>> Where possible I think uint32_t would be slightly better to use. >> >> OOI, why? > > Because everything else here uses the wider type, plus the > question of why use a compound type (array) when a simple > one does. This is pretty much a matter of taste. In this case, I decided to specify the padding the same way accross all the structure. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 16 10:00:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 10:00:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8OW-00063F-Dd; Tue, 16 Jun 2020 10:00:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8OU-000639-GL for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 10:00:38 +0000 X-Inumbo-ID: 398dfbca-afb8-11ea-b8a4-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 398dfbca-afb8-11ea-b8a4-12813bfff9fa; Tue, 16 Jun 2020 10:00:36 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 93198ADC1; Tue, 16 Jun 2020 10:00:39 +0000 (UTC) Subject: Re: [PATCH 9/9] x86/spec-ctrl: Hide RDRAND by default on IvyBridge To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-10-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 12:00:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200615141532.1927-10-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 16:15, Andrew Cooper wrote: > --- a/docs/misc/xen-command-line.pandoc > +++ b/docs/misc/xen-command-line.pandoc > @@ -512,11 +512,21 @@ The Speculation Control hardware features `srbds-ctrl`, `md-clear`, `ibrsb`, > `stibp`, `ibpb`, `l1d-flush` and `ssbd` are used by default if available and > applicable. They can all be ignored. > > -`rdrand` and `rdseed` can be ignored, as a mitigation to XSA-320 / > -CVE-2020-0543. The RDRAND feature is disabled by default on certain AMD > -systems, due to possible malfunctions after ACPI S3 suspend/resume. `rdrand` > -may be used in its positive form to override Xen's default behaviour on these > -systems, and make the feature fully usable. > +`rdrand` and `rdseed` have multiple interactions. > + > +* For Special Register Buffer Data Sampling (SRBDS, XSA-320, CVE-2020-0543), > + RDRAND and RDSEED can be ignored. > + > + Due to the absence microcode to address SRBDS on IvyBridge hardware, the Nit: "... absence of microcode ..." > + RDRAND feature is hidden by default for guests, unless `rdrand` is used in > + its positive form. Irrespective of the default setting here, VMs can use > + RDRAND if explicitly enabled in guest config file, and VMs already using > + RDRAND can migrate in. I'm somewhat confused by the use of "default setting" here, when at the same time you talk about our default behavior for guests. Aiui the two "default" mean different things, so I'd suggest dropping that latter "default". This raises a question though: Is disabling RDRAND just for guests good enough? I.e. what about Xen's own uses of RDRAND? There may not be any problematic ones right now, but wouldn't there be a latent issue no-one is going to notice? > --- a/tools/libxc/xc_cpuid_x86.c > +++ b/tools/libxc/xc_cpuid_x86.c > @@ -503,6 +503,9 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, > */ > if ( restore ) > { > + if ( test_bit(X86_FEATURE_RDRAND, host_featureset) && !p->basic.rdrand ) > + p->basic.rdrand = true; Same question as before: Why do you derive from the host feature set rather than the domain type's maximum one? > --- a/xen/arch/x86/cpuid.c > +++ b/xen/arch/x86/cpuid.c > @@ -340,6 +340,25 @@ static void __init calculate_host_policy(void) > } > } > > +static void __init guest_common_default_feature_adjustments(uint32_t *fs) > +{ > + /* > + * IvyBridge client parts suffer from leakage of RDRAND data due to SRBDS > + * (XSA-320 / CVE-2020-0543), and won't be receiving microcode to > + * compensate. > + * > + * Mitigate by hiding RDRAND from guests by default, unless explicitly > + * overridden on the Xen command line (cpuid=rdrand). Irrespective of the > + * default setting, guests can use RDRAND if explicitly enabled > + * (cpuid="host,rdrand=1") in the VM's config file, and VMs which were > + * previously using RDRAND can migrate in. > + */ > + if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && > + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x3a && This is the first time (description plus patch so far) that the issue gets mentioned to be for and the workaround restricted to client parts only. If so, I think at least the doc should say so too. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 10:06:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 10:06:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8UP-0006F3-5t; Tue, 16 Jun 2020 10:06:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8UO-0006Ey-Ka for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 10:06:44 +0000 X-Inumbo-ID: 1473bcd4-afb9-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1473bcd4-afb9-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 10:06:44 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 57284AD60; Tue, 16 Jun 2020 10:06:46 +0000 (UTC) Subject: Re: [RFC PATCH v1 1/6] sched: track time spent in IRQ handler To: Volodymyr Babchuk References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-2-volodymyr_babchuk@epam.com> From: Jan Beulich Message-ID: <423db379-785d-d003-638c-223c4465e635@suse.com> Date: Tue, 16 Jun 2020 12:06:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612002205.174295-2-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , "xen-devel@lists.xenproject.org" , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 02:22, Volodymyr Babchuk wrote: > --- a/xen/arch/x86/irq.c > +++ b/xen/arch/x86/irq.c > @@ -1895,6 +1895,7 @@ void do_IRQ(struct cpu_user_regs *regs) > int irq = this_cpu(vector_irq)[vector]; > struct cpu_user_regs *old_regs = set_irq_regs(regs); > > + vcpu_begin_irq_handler(); > perfc_incr(irqs); > this_cpu(irq_count)++; > irq_enter(); > @@ -2024,6 +2025,7 @@ void do_IRQ(struct cpu_user_regs *regs) > out_no_unlock: > irq_exit(); > set_irq_regs(old_regs); > + vcpu_end_irq_handler(); > } This looks like a fight for who's going to be first/last here. I think you want to add your calls after irq_enter() and before irq_exit(). Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 10:10:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 10:10:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8Y7-000725-PS; Tue, 16 Jun 2020 10:10:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8Y6-000720-P4 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 10:10:34 +0000 X-Inumbo-ID: 9c2ee356-afb9-11ea-b8a5-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9c2ee356-afb9-11ea-b8a5-12813bfff9fa; Tue, 16 Jun 2020 10:10:31 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7645DAD60; Tue, 16 Jun 2020 10:10:34 +0000 (UTC) Subject: Re: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks To: Volodymyr Babchuk References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-3-volodymyr_babchuk@epam.com> From: Jan Beulich Message-ID: <7d3e1741-b8bc-b522-8d64-20ca9c14744b@suse.com> Date: Tue, 16 Jun 2020 12:10:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612002205.174295-3-volodymyr_babchuk@epam.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 02:22, Volodymyr Babchuk wrote: > In most cases hypervisor code performs guest-related jobs. Tasks like > hypercall handling or MMIO access emulation are done for calling vCPU > so it is okay to charge time spent in hypervisor to the current vCPU. > > But, there are also tasks that are not originated from guests. This > includes things like TLB flushing or running tasklets. We don't want > to track time spent in this tasks to a total scheduling unit run > time. So we need to track time spent in such housekeeping tasks > separately. > > Those hypervisor tasks are run in do_softirq() function, so we'll > install our hooks there. I can see the point and desire, but it feels like you're moving from one kind of unfairness to another: A softirq may very well be on behalf of a specific vCPU, in which case not charging current should lead to charging that specific one (which may still be current then). Even more than for TLB flushes this may be relevant for the cases where (on x86) we issue WBINVD on behalf of a guest. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 10:14:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 10:14:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8c5-0007BG-DP; Tue, 16 Jun 2020 10:14:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8c3-0007BB-VP for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 10:14:40 +0000 X-Inumbo-ID: 30252a98-afba-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 30252a98-afba-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 10:14:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=IP0eoU13seZ6RUxXtGVdn7NzzDAWPAaqSZJja8JNS4U=; b=BOFHSqLALbL1qoz4uuvrC9u1ov j7yByNzJnEkiD5kY4mNW7AYbYQy+aIRPlXVTOwyuIFQEB6utxELd0ayT5eFk0JVNyPJ1G5CHKjEMj 67qW7DYeYKmHVLhW2JiOCzNY47uhAF3jrFybFpJEopcnN3osMLKufs8pOkmfmtdpsoVc=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8c3-0002ws-1Y; Tue, 16 Jun 2020 10:14:39 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jl8c2-0007mM-RV; Tue, 16 Jun 2020 10:14:38 +0000 Subject: Re: ARM - Successful install on RockPro64 To: Bertrand Marquis , Richard Simpson References: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> From: Julien Grall Message-ID: Date: Tue, 16 Jun 2020 11:14:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 16/06/2020 09:03, Bertrand Marquis wrote: > Hi Richard, > > + Julien and Stefano > >> On 15 Jun 2020, at 23:29, Richard Simpson wrote: >> >> Hello, >> >> Just to report that I have successfully installed Xen on a Pine RockPro64 ARM SBC. > > Very nice :-) > >> >> I am using Xen 4.13 booting directly from u-boot on an SD card and my dom0 distribution is Gentoo. >> >> I haven't tried to create a domU yet and I am doing everything via the serial console so I can't say anything about the graphics. >> >> My biggest hurdle (apart from understanding u-boot) was needing to apply the vgic-v3: fix GICD_ISACTIVER patch. > > What version of Linux are you running ? > I added Julien and Stefano so that we reactivate the discussion on this patch. A temporary patch to mark the register RAZ has been merged a couple of months ago. See 0796cb907f2c "xen/arm: vgic-v3: fix GICD_ISACTIVER range". This should probably be backported to Xen 4.13 and 4.12. Although, I haven't seen any update for a proper fix yet. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 16 10:21:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 10:21:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8iQ-00081L-4G; Tue, 16 Jun 2020 10:21:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8iO-00080c-9Q for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 10:21:12 +0000 X-Inumbo-ID: 19a42f3e-afbb-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 19a42f3e-afbb-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 10:21:11 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: GRjBZsy9kxu0D/p6GaawKqY6WO/uPQJvwbc/G4q2KaQ5qaPOv+gop+SJ8batzusqcUb1Y33edI m4SsHnYVBJk+UlGeFhlNb5hYWSmC949pc+azg6CJEKS7JTk6c98734WQMpaIJWHpvaupGCi4Gs Qm+GicgBjYNaP8/yNiPO2FvMfjxB6kI8IFqchSmZ9UgZIwn3Z0Mk60u1ByOwQJqTIHk6paQXBV 1HbnjN3NQCdcnV0ExhnDJaFKCDBvco68gVfm1GOFSpOlEmlKuyvaJiM2Px7051woLMNExUVjfY J1o= X-SBRS: 2.7 X-MesageID: 20489174 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20489174" From: Roger Pau Monne To: Subject: [PATCH] x86/hvm: check against VIOAPIC_LEVEL_TRIG in hvm_gsi_deassert Date: Tue, 16 Jun 2020 12:20:56 +0200 Message-ID: <20200616102056.18074-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In order to avoid relying on the specific values of VIOAPIC_{LEVEL/EDGE}_TRIG. No functional change. Requested-by: Jan Beulich Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c index 6cbea63f4c..6772aec721 100644 --- a/xen/arch/x86/hvm/irq.c +++ b/xen/arch/x86/hvm/irq.c @@ -202,7 +202,7 @@ void hvm_gsi_deassert(struct domain *d, unsigned int gsi) int trig = vioapic_get_trigger_mode(d, gsi); struct hvm_irq *hvm_irq = hvm_domain_irq(d); - if ( trig <= VIOAPIC_EDGE_TRIG || gsi >= hvm_irq->nr_gsis ) + if ( trig != VIOAPIC_LEVEL_TRIG || gsi >= hvm_irq->nr_gsis ) { ASSERT(trig == VIOAPIC_EDGE_TRIG && gsi < hvm_irq->nr_gsis); return; -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 10:26:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 10:26:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8nn-0008Du-PF; Tue, 16 Jun 2020 10:26:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8nn-0008Dp-2k for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 10:26:47 +0000 X-Inumbo-ID: e1611172-afbb-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e1611172-afbb-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 10:26:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6AU8q+Can2i4rgXg2sr3VGSvRrDgI1BfdpkASbJhCI0=; b=miQSii911zrPISIXOsq9p67WZ3 VUxgLeUAw4q+DSSKwMJWB1wwc38azd8HMtrHXja0bB44y89JQtW6CvKP66GUnW4qqM430hQ6jFXKj BqVDvcqHUPs9xBi0g3vR65/fxEa4rqdXRal+wxicrJvFOCY02ThvKWvz6ytzYQ5gy/8Y=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8nl-0003BE-Mp; Tue, 16 Jun 2020 10:26:45 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jl8nl-0008Ku-GM; Tue, 16 Jun 2020 10:26:45 +0000 Subject: Re: ARM - Successful install on RockPro64 To: Richard Simpson , Bertrand Marquis References: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> From: Julien Grall Message-ID: <8013f2db-3732-0679-81f6-7b274b39c44f@xen.org> Date: Tue, 16 Jun 2020 11:26:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello, On 16/06/2020 09:33, Richard Simpson wrote: > I would be happy to try to report my success via the smoke test page > (https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results) if > I can figure out how.  Strangely, I can't see anything listed under > "Test Results" from anyone else.  Perhaps it is a problem with my browser. This is not a browser problem :). In the past, we did attempt to list all the boards we know works on a given version of Xen. But this never really gain any momentum. If there is any specific setup you need for your board (e.g. non-upstream kernel, a new U-boot...), then I would suggest to create a new page with steps to boot Xen the platform. You can have a look how we list the other boards in [1]. > > I also notice an instruction which reads "Test hypervisor > functionalities: clone raisin on the platform and run ./raise test".  I > can try to do this if it will help.  Do I just run "git clone web page>" and then presumably the test prints out some results? It is just meant to be an easy way to test basic functionality of Xen (e.g booting a guest). You seem to have done it manually, so it should be sufficient. > > Happy to try a beta version of Xen if you decide to include the patch > and I can also try some of the interrupt config options if you want. The patch should already be included in xen 4.14-rc2. Would you mind to give a spin? Best regards, [1] https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 16 10:32:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 10:32:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8t6-0000cV-Hz; Tue, 16 Jun 2020 10:32:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl8t5-0000cN-GE for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 10:32:15 +0000 X-Inumbo-ID: a43af1ea-afbc-11ea-b8ac-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a43af1ea-afbc-11ea-b8ac-12813bfff9fa; Tue, 16 Jun 2020 10:32:13 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: bWFKksfp5EiXZY6hVfcd1q/6Ph05ZeEMTLrIKdwEoDD5zcXnHJvlxLox25BnEDi91oGFD28x9x tgdmDs1eGU3eSYNi5Zd+2Qf1VwczulxE+0VueZzRY5ghrmzfgrKcjLa/fSI7SZijqccvTiH24L eEmoEMo9smUeL0T9+ZAeOuk2qRQ4pnQPl4bWZ7p3NGWCjRSo0Xa1LnyZ5RzO/dSRfWZGJN1x4a rYUH/YtYOQ/b8BpNaWzgPfz41zELOw2j3lJFYTXvQt62WSpjRPtt3tR0hSopBlU4LCCXHKlwnt G/Q= X-SBRS: 2.7 X-MesageID: 20144470 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20144470" Date: Tue, 16 Jun 2020 12:32:04 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Message-ID: <20200616103204.GN735@Air-de-Roger> References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 10:07:05AM +0200, Jan Beulich wrote: > On 14.06.2020 16:36, Grzegorz Uriasz wrote: > > --- a/xen/arch/x86/acpi/boot.c > > +++ b/xen/arch/x86/acpi/boot.c > > @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > > if (fadt->xpm_timer_block.space_id == > > ACPI_ADR_SPACE_SYSTEM_IO) { > > pmtmr_ioport = fadt->xpm_timer_block.address; > > - pmtmr_width = fadt->xpm_timer_block.bit_width; > > + if (fadt->flags & ACPI_FADT_32BIT_TIMER) > > + pmtmr_width = 32; > > + else > > + pmtmr_width = 24; > > I think disagreement of the two wants logging, and you want to > default to using the smaller of the two (or even to ignoring the > timer altogether). Then there wants to be a way to override > (unless we already have one) our defaulting, in case it's wrong. TBH, I presume timer_block will always return 32bits, because that's the size of the register. Then the timer can implement less bits than the full size of the register, and that's what gets signaled using the ACPI flags. What we care about here is the number of bits used by the timer, not the size of the register. I think we should only ignore the timer if pm_timer_block.bit_width < pmtmr_width. Printing a (debug) message when those values disagree is fine, but I bet it's going to trigger always when the implemented timer is only using 24bits. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 10:42:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 10:42:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl92L-0001V5-Fw; Tue, 16 Jun 2020 10:41:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl92J-0001Uz-V3 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 10:41:47 +0000 X-Inumbo-ID: f97edc60-afbd-11ea-b8ae-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f97edc60-afbd-11ea-b8ae-12813bfff9fa; Tue, 16 Jun 2020 10:41:46 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: U4NJN7iYtxyl0XcC0hK+/k8Mtlg6T3m5Zz1w0una2aT//FccXLpzDe7HgnNcZSRhQEi73LEvnS fMDaLPZ6mtTaqvQwPek/a0puqPEWl6HWatP3BCidBqZlLVz2pyvBD4dJGKlE0OTjkthAfeuq5V vWW0Pw0YKKEIR9fblJohzvvQTRjPwdHzvft4HIfXm2MgH8g3FYKkFcj+m6ppzZ7Qw5nwY9birT GQnwteBoG3mA9EEGsxu6P6zgFP4q5iN3DMtvdrvviwpCi6ODwbd7yspXFxF/G/8SelPihhZw+i MSs= X-SBRS: 2.7 X-MesageID: 20921592 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20921592" Date: Tue, 16 Jun 2020 12:41:39 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Subject: Re: [PATCH] x86/hvm: check against VIOAPIC_LEVEL_TRIG in hvm_gsi_deassert Message-ID: <20200616104139.GO735@Air-de-Roger> References: <20200616102056.18074-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200616102056.18074-1-roger.pau@citrix.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Wei Liu , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Forgot to add maintainers. On Tue, Jun 16, 2020 at 12:20:56PM +0200, Roger Pau Monne wrote: > In order to avoid relying on the specific values of > VIOAPIC_{LEVEL/EDGE}_TRIG. > > No functional change. > > Requested-by: Jan Beulich > Signed-off-by: Roger Pau Monné > --- > xen/arch/x86/hvm/irq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c > index 6cbea63f4c..6772aec721 100644 > --- a/xen/arch/x86/hvm/irq.c > +++ b/xen/arch/x86/hvm/irq.c > @@ -202,7 +202,7 @@ void hvm_gsi_deassert(struct domain *d, unsigned int gsi) > int trig = vioapic_get_trigger_mode(d, gsi); > struct hvm_irq *hvm_irq = hvm_domain_irq(d); > > - if ( trig <= VIOAPIC_EDGE_TRIG || gsi >= hvm_irq->nr_gsis ) > + if ( trig != VIOAPIC_LEVEL_TRIG || gsi >= hvm_irq->nr_gsis ) > { > ASSERT(trig == VIOAPIC_EDGE_TRIG && gsi < hvm_irq->nr_gsis); > return; > -- > 2.26.2 > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 11:22:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 11:22:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl9f0-0004pF-Ja; Tue, 16 Jun 2020 11:21:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl9ey-0004p9-MW for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 11:21:44 +0000 X-Inumbo-ID: 8d4d717c-afc3-11ea-b8bc-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8d4d717c-afc3-11ea-b8bc-12813bfff9fa; Tue, 16 Jun 2020 11:21:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CC060B1A8; Tue, 16 Jun 2020 11:21:43 +0000 (UTC) Subject: Re: [PATCH] x86/hvm: check against VIOAPIC_LEVEL_TRIG in hvm_gsi_deassert To: Roger Pau Monne References: <20200616102056.18074-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 13:21:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200616102056.18074-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Paul Durrant , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 12:20, Roger Pau Monne wrote: > In order to avoid relying on the specific values of > VIOAPIC_{LEVEL/EDGE}_TRIG. > > No functional change. > > Requested-by: Jan Beulich > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich Since the other patch went in, also Cc-ing Paul for a possible release ack. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 11:43:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 11:43:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl9zV-0006W9-DO; Tue, 16 Jun 2020 11:42:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jl9zU-0006W4-3J for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 11:42:56 +0000 X-Inumbo-ID: 8432974a-afc6-11ea-bb8b-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8432974a-afc6-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 11:42:55 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: O2KA83HI7fUTm7TAwZ6nMx1C4u4oC9zA7xkOpFFh++cRCj61rv10i2lCjROsL+hssoDwx9bGyg 9hpE+YOuMmvHyb35yYj9UYKwxSUaeiYhTQ4PQc6J899hrXmlGN2oo+rpeB3EjVhPv1KtbZEeHy +scHh57n+F/1VQjS8DNjGo3jwwnjtXwIOSu8xdfNzaDbss9ap10r/iDBIqUGcwYuMy+HrT/hTY RcZfSdg9fAL52QSYQznj63qbFb+rTW85UxL6dy1AnfVp0gEwxlESAeZ0xfj6LiU/Vh9wLleSev czs= X-SBRS: 2.7 X-MesageID: 20164113 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20164113" From: Igor Druzhinin To: Subject: [PATCH for-4.14 v2] tools/xen-ucode: fix error code propagation of microcode load operation Date: Tue, 16 Jun 2020 12:42:34 +0100 Message-ID: <1592307754-8844-1-git-send-email-igor.druzhinin@citrix.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Igor Druzhinin , ian.jackson@eu.citrix.com, xadimgnik@gmail.com, wl@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Otherwise it's impossible to know the reason for a fault or blob rejection inside the automation. While at it, also change return code of incorrect invokation to EINVAL. Signed-off-by: Igor Druzhinin --- Changes in v2: - simply call "return errno". On Linux that seems to be safe as values <=255 are correctly propagated, on non-Linux I couldn't find error codes >127. - return positive value on incorrect invokation --- tools/misc/xen-ucode.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c index 0c257f4..409cace 100644 --- a/tools/misc/xen-ucode.c +++ b/tools/misc/xen-ucode.c @@ -25,7 +25,7 @@ int main(int argc, char *argv[]) fprintf(stderr, "xen-ucode: Xen microcode updating tool\n" "Usage: %s \n", argv[0]); - return 0; + return EINVAL; } filename = argv[1]; @@ -62,8 +62,11 @@ int main(int argc, char *argv[]) ret = xc_microcode_update(xch, buf, len); if ( ret ) + { fprintf(stderr, "Failed to update microcode. (err: %s)\n", strerror(errno)); + return errno; + } xc_interface_close(xch); -- 2.7.4 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 11:50:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 11:50:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlA6o-0007Nr-6y; Tue, 16 Jun 2020 11:50:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlA6n-0007Nm-Cw for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 11:50:29 +0000 X-Inumbo-ID: 92abc20a-afc7-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x42d.google.com (unknown [2a00:1450:4864:20::42d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 92abc20a-afc7-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 11:50:28 +0000 (UTC) Received: by mail-wr1-x42d.google.com with SMTP id q11so20459721wrp.3 for ; Tue, 16 Jun 2020 04:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=gJBqAYNuHTwcbvP6olgulukkw1YaLXwNhJaPEC0XO64=; b=j2Bu9pWTflXoVzG4of/FGVUmoSNCF5o52ls4ytFGzDvXAXA7nVEPewG8pY34dChiaB uqHCs2TLt9KCQo000nEduziqcDMC67p2DOEkj2Avz1EKXIY3Tpp5IdoA8PSX4zN9CPF9 Z3dLiVUqfX2F29v5pEvBgnTYUQ6DNVX5L55IZiXNMLVf0PBI0d8nuz3ProU5Nbowac/v Y7I0AZfwsZoOERZvs/odiIYvEFc1ynwXmYS7aOHkL9zZxq1TV21lSZzc4S0DLUPmMnvc 4QI+23g7C6a9nNgNt7H1bFWJtW3PpCXYcwcB96Y3vj9wQrIWp1lNxQ5R/BwietD8RH3W 9vNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=gJBqAYNuHTwcbvP6olgulukkw1YaLXwNhJaPEC0XO64=; b=o8i8pcQ+GisEqtfLQOcNqVMz/a2D1SdyV14Nj4R53W1rMDz3ifvL0KTJF6yMLWqBkd o4C2vP3KuxXCgTOE2r+SOUIy5M+8sbxALWxMy+1UsiotJokSNy13dZgKe1aBqbUuIkwy 56UmRMJjeDVV7HpjUEMeOSPPJWdWKAcFOcNIhVnyqbGOhJkPbFC4sgavZev1plnuCApS F3IvRnFNWc2Uf1Oc8Gcfp70Y/STamHGNH1mrSwXMNHAAoahZ+2LM2s4C2GKqIQVITua/ mGYkYi7fuH4k1SJY1utMzOGIMfeZfuq+TDOdzZPRiFma+YMIEj5bAOnhEFViCVKvDb3U l5rg== X-Gm-Message-State: AOAM5332w1dYLKhD9PhkFfNR3Mxla43EnqkUrKS/UR/0+74vpdsUqRo1 q/YM4GHfeBMnBwgBDUV/puQ= X-Google-Smtp-Source: ABdhPJzZQPvGU5M9lg0swP8ft8ziU+/pjYasxBer2JxfHa/s63nr9ATtpks0i2v7HykACCL6zct9Tg== X-Received: by 2002:adf:a350:: with SMTP id d16mr2755407wrb.237.1592308227941; Tue, 16 Jun 2020 04:50:27 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id r5sm29305450wrq.0.2020.06.16.04.50.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2020 04:50:27 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , "'Roger Pau Monne'" References: <20200616102056.18074-1-roger.pau@citrix.com> In-Reply-To: Subject: RE: [PATCH] x86/hvm: check against VIOAPIC_LEVEL_TRIG in hvm_gsi_deassert Date: Tue, 16 Jun 2020 12:50:25 +0100 Message-ID: <002d01d643d4$53e0d6a0$fba283e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGCFOmVxi5Iajm8LYmxSaYnvh23ZgNQQnvrqWj8oOA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Wei Liu' , 'Andrew Cooper' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 16 June 2020 12:22 > To: Roger Pau Monne > Cc: xen-devel@lists.xenproject.org; Wei Liu ; Andrew = Cooper ; > Paul Durrant > Subject: Re: [PATCH] x86/hvm: check against VIOAPIC_LEVEL_TRIG in = hvm_gsi_deassert >=20 > On 16.06.2020 12:20, Roger Pau Monne wrote: > > In order to avoid relying on the specific values of > > VIOAPIC_{LEVEL/EDGE}_TRIG. > > > > No functional change. > > > > Requested-by: Jan Beulich > > Signed-off-by: Roger Pau Monn=C3=A9 >=20 > Reviewed-by: Jan Beulich >=20 > Since the other patch went in, also Cc-ing Paul for a possible > release ack. >=20 Sure, it's trivial so... Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Tue Jun 16 12:06:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 12:06:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAMS-0008Tu-0u; Tue, 16 Jun 2020 12:06:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAMR-0008Tp-Cx for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 12:06:39 +0000 X-Inumbo-ID: d4e4c160-afc9-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d4e4c160-afc9-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 12:06:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2u7vdskhL38x3r+8LBhK0t86A/y0UEbVdU9sqpt2lU4=; b=LilHoScUpcpEIh0aIJjijpsFR 5s6vdjz6tkJ7mFkx2zbZngPY2EOR4t24Rxv4NyMIgQBqZXaq6is8RZZT29n+t9KSU8IUPLjnzcw7E 1xuxOcIZFNuhHd+v+u5LeQbRcKGeNA/egTR3CBCxxMvorS1zC/xWP5o6R/6wt6M0fDaAU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAMP-00051C-L0; Tue, 16 Jun 2020 12:06:37 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlAMP-0000XY-Bi; Tue, 16 Jun 2020 12:06:37 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlAMP-0005NC-9U; Tue, 16 Jun 2020 12:06:37 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151167: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=3625b04991b4d6affadd99d377ab84bac48dfff4 X-Osstest-Versions-That: xen=1251402caf8685f45d9d580f01583370f7e2d272 From: osstest service owner Date: Tue, 16 Jun 2020 12:06:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151167 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151167/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 3625b04991b4d6affadd99d377ab84bac48dfff4 baseline version: xen 1251402caf8685f45d9d580f01583370f7e2d272 Last test of basis 151159 2020-06-15 18:00:41 Z 0 days Testing same since 151167 2020-06-16 09:00:54 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Bertrand Marquis Ian Jackson Jason Andryuk Tamas K Lengyel Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 1251402caf..3625b04991 3625b04991b4d6affadd99d377ab84bac48dfff4 -> smoke From xen-devel-bounces@lists.xenproject.org Tue Jun 16 12:09:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 12:09:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAPL-0000BB-GS; Tue, 16 Jun 2020 12:09:39 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAPK-0000B5-Tm for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 12:09:38 +0000 X-Inumbo-ID: 3f53dfb8-afca-11ea-b8c1-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3f53dfb8-afca-11ea-b8c1-12813bfff9fa; Tue, 16 Jun 2020 12:09:38 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: KKdId0+JI8lDxNG/hV1k/8LBBAT3XBjHfWp9mKeBj/ulOnzyDxsJwPv03TRlJWn8P2gDeMDdAJ UVoCqb2neKxgNS1dEJRIFEVsFi6J2wkcjweJ6MXWiyvPtj9lWGbtgRLhJ9bn4MoaUSSzEnqcvu pApWqbEPFcRs8ddqZcPzYyHNyuJuHDdx7jrI+lyL3g2ISUabNgg8VWofXeSNiXtgoGSc9WzO9A PREdcumcbfl2OMmPpiXyoU4I4+JyaKgDW9hFOkXv9mYIlVOJlJQRBmkyKIHMQ46ufYRC6LAbT1 7N0= X-SBRS: 2.7 X-MesageID: 20497140 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20497140" From: George Dunlap To: xen-devel , "xen-announce@lists.xenproject.org" Subject: Submitting new talks to XenSummit via the design-sessions website Thread-Topic: Submitting new talks to XenSummit via the design-sessions website Thread-Index: AQHWQ9b/QLhthVHlrkGKEhIxW4JRpA== Date: Tue, 16 Jun 2020 12:09:33 +0000 Message-ID: <2BCC5487-5C91-4F2D-818C-7AB9A1C8A803@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <043B76A7F816014796AA14ED2AAFAA48@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" RHVlIHRvIHRoZSByZS1zY2hlZHVsaW5nIG9mIHRoZSBYZW5TdW1taXQgZnJvbSBKdW5lIHRvIEp1 bHksIGFzIHdlbGwgYXMgbWFraW5nIGl0IGEgdmlydHVhbCBldmVudCBjb3ZlcmluZyBhIGZldyBt b3JlIGRheXMsIHdlIGhhdmUgc3BhY2UgdG8gYWNjZXB0IG1vcmUgdGFsa3MuDQoNClJhdGhlciB0 aGFuIGdvaW5nIHRocm91Z2ggdGhlIGVudGlyZSBzdWJtaXNzaW9uIHByb2Nlc3MgYWdhaW4sIHdl 4oCZdmUgZGVjaWRlZCB0byB1dGlsaXplIHRoZSBkZXNpZ24gc2Vzc2lvbiB3ZWJzaXRlLiAgSWYg eW91IHdpc2ggdG8gZ2l2ZSBhIHRhbGssIHNpbXBseSBzdWJtaXQgYSBkZXNpZ24gc2Vzc2lvbiB3 aXRoIGBbVEFMS11gIGFzIHRoZSBmaXJzdCBwYXJ0IG9mIHRoZSB0aXRsZS4gIFRoZSBzZXNzaW9u IHdpbGwgYmUgc2NoZWR1bGVkIG5vcm1hbGx5IGJhc2VkIG9uIGludGVyZXN0LCBidXQgZXZlcnlv bmUgd2lsbCBrbm93IHRoYXQgdGhlIGRpcmVjdGlvbiBvZiB0aGlzIHNlc3Npb24gd2lsbCBwcmlt YXJpbHkgYmUgb25lLXdheS4NCg0KU29tZSB0YWxrcyB3ZSBtYXkgZW5kIHVwIOKAnHByb21vdGlu Z+KAnSBmcm9tIGRlc2lnbiBzZXNzaW9uIHRvIG5vcm1hbGx5IHNjaGVkdWxlZCB0YWxrcy4NCg0K TG9va2luZyBmb3J3YXJkIHRvIHNlZWluZyB5b3UgYWxsIGF0IHRoZSBTdW1taXQhDQoNCiAtR2Vv cmdlIER1bmxhcA== From xen-devel-bounces@lists.xenproject.org Tue Jun 16 12:25:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 12:25:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAee-0001p3-Td; Tue, 16 Jun 2020 12:25:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAed-0001oy-O9 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 12:25:27 +0000 X-Inumbo-ID: 7548c19a-afcc-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7548c19a-afcc-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 12:25:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D620BAD41; Tue, 16 Jun 2020 12:25:29 +0000 (UTC) Subject: Re: [PATCH for-4.14 v2] tools/xen-ucode: fix error code propagation of microcode load operation To: Igor Druzhinin References: <1592307754-8844-1-git-send-email-igor.druzhinin@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 14:25:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1592307754-8844-1-git-send-email-igor.druzhinin@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, wl@xen.org, xadimgnik@gmail.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 13:42, Igor Druzhinin wrote: > @@ -62,8 +62,11 @@ int main(int argc, char *argv[]) > > ret = xc_microcode_update(xch, buf, len); > if ( ret ) > + { > fprintf(stderr, "Failed to update microcode. (err: %s)\n", > strerror(errno)); > + return errno; I think you need to latch errno, as fprintf() may in principle run into another error. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 12:31:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 12:31:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAkZ-0002eU-JJ; Tue, 16 Jun 2020 12:31:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAkY-0002eP-Ig for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 12:31:34 +0000 X-Inumbo-ID: 4f68b114-afcd-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4f68b114-afcd-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 12:31:32 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 752CBAD35; Tue, 16 Jun 2020 12:31:35 +0000 (UTC) Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> From: Jan Beulich Message-ID: <440b1c62-e3bd-6a91-f75f-e85d8772f4e0@suse.com> Date: Tue, 16 Jun 2020 14:31:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200616103204.GN735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 12:32, Roger Pau Monné wrote: > On Tue, Jun 16, 2020 at 10:07:05AM +0200, Jan Beulich wrote: >> On 14.06.2020 16:36, Grzegorz Uriasz wrote: >>> --- a/xen/arch/x86/acpi/boot.c >>> +++ b/xen/arch/x86/acpi/boot.c >>> @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) >>> if (fadt->xpm_timer_block.space_id == >>> ACPI_ADR_SPACE_SYSTEM_IO) { >>> pmtmr_ioport = fadt->xpm_timer_block.address; >>> - pmtmr_width = fadt->xpm_timer_block.bit_width; >>> + if (fadt->flags & ACPI_FADT_32BIT_TIMER) >>> + pmtmr_width = 32; >>> + else >>> + pmtmr_width = 24; >> >> I think disagreement of the two wants logging, and you want to >> default to using the smaller of the two (or even to ignoring the >> timer altogether). Then there wants to be a way to override >> (unless we already have one) our defaulting, in case it's wrong. > > TBH, I presume timer_block will always return 32bits, because that's > the size of the register. Then the timer can implement less bits than > the full size of the register, and that's what gets signaled using the > ACPI flags. What we care about here is the number of bits used by the > timer, not the size of the register. The first random system I checked this on reports 24 bits as bit_width (and the flag clear, i.e. both are consistent). The flag, aiui, is really important only in the ACPI v1 case, where the size of the register was a byte-granular value. The spec isn't helpful in clarifying applicability of the flag though, i.e. one can interpret it either way imo. Jan > I think we should only ignore the timer if pm_timer_block.bit_width < > pmtmr_width. > > Printing a (debug) message when those values disagree is fine, but I > bet it's going to trigger always when the implemented timer is only > using 24bits. > > Roger. > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 12:41:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 12:41:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAtW-0003X8-G8; Tue, 16 Jun 2020 12:40:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlAtV-0003X2-4O for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 12:40:49 +0000 X-Inumbo-ID: 9a69e4d4-afce-11ea-8496-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9a69e4d4-afce-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 12:40:48 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: IxqVyysXiedplLMYiC8PyE27klOryAY1LIS89ayKLPhYWtlltfUNSovh6RpHfVJYYVF6NLi0Lb m6qDOBi2icrd/yi8gKx92DqbARYZfOqkS3bgRhyNDIEs1WYQtk3p1+VPokcuhPiQMlAED1XiSw Tqi60+lXr9Rn25VPfZjqzkspk+QUch8bKjTBxkMqnDjye6zOnFEOGfAj6rpi7+/7fgooKuTKjG paJhzBCD5zhcWPx6UXAx25i/I7VbpX1tnkkcU6Hra1A7tUeJytVs350V2xF8CJYOdEzjDUn01P Vgs= X-SBRS: 2.7 X-MesageID: 20456615 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20456615" Subject: Re: [PATCH for-4.14 v2] tools/xen-ucode: fix error code propagation of microcode load operation To: Jan Beulich References: <1592307754-8844-1-git-send-email-igor.druzhinin@citrix.com> From: Igor Druzhinin Message-ID: <4d0bacbf-506c-e3c3-5448-b5ab8f6dd0ba@citrix.com> Date: Tue, 16 Jun 2020 13:40:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, wl@xen.org, xadimgnik@gmail.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 13:25, Jan Beulich wrote: > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments unless you have verified the sender and know the content is safe. > > On 16.06.2020 13:42, Igor Druzhinin wrote: >> @@ -62,8 +62,11 @@ int main(int argc, char *argv[]) >> >> ret = xc_microcode_update(xch, buf, len); >> if ( ret ) >> + { >> fprintf(stderr, "Failed to update microcode. (err: %s)\n", >> strerror(errno)); >> + return errno; > > I think you need to latch errno, as fprintf() may in principle run > into another error. Yes, I also noticed that but the whole file has this problem so I didn't change it here specifically. If fixing the whole file - I'd rather rewrite error reporting completely: return 1 on error, 0 on success, etc. From what I've read returning errno has many incompatibilities and might lead to surprise consequences. I'll send v3 to clean this all up. Igor From xen-devel-bounces@lists.xenproject.org Tue Jun 16 13:06:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 13:06:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlBID-0005NM-L8; Tue, 16 Jun 2020 13:06:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlBIC-0005N9-RS for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 13:06:21 +0000 X-Inumbo-ID: 2bae44dc-afd2-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2bae44dc-afd2-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 13:06:20 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id o15so21385714ejm.12 for ; Tue, 16 Jun 2020 06:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tklengyel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hi5RfA1lgLnQxg+WfKSbNLbjWGiSN79j2OmzZMgyrlE=; b=NPx8O1KEJBIVUKhBoFnWjT0AABeXFxzEgzpWL2kcTPBxIeDxzXvXQ+JGYUb5f+CB4N t9/nw2fOdlymQ7CW74a2TGeVReMnGeD/McTw9NJ2hBJ2M0unQQtstkOWtDu4EIEvMZFA 7ihzCL/hXFUqstHNXnVdwUhB/GY3SBZJ6wFKbFnldEzrYmSbJMpvq48mRmwPMQQhJBdl aDTHAYMjBv1MqkGeF1IdvwJqi6WaT59ezS2n336LOuXGLCq6Tw7t0u/uGLuyh9qCPqlL esuZ+jIWTC6YQdtDGQCR/muRCbzfL+tiasKqxLIcFooNlJNdNU8m5hOiVKtlmmWEfWGG lRYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hi5RfA1lgLnQxg+WfKSbNLbjWGiSN79j2OmzZMgyrlE=; b=OwyDXevDIDydFvwiTbASXYKTt/CSmgHkxFRH9burAeuSeV7OEuTPVEYWZsq5IHEM+l x2yS6zJ6rcdcW9Hf5Ot7oRmYWz9ks6TEOnSsLiKBaYx609u/1Tx7MPP87CewRDseh+qS 9OSnYRrJKREyIIitrRCLaG07VBPsDpv9yLGqIj/eKdGDErRZNOU2eFdsiIzr3CuWYJde tDPC9kDXMEMY3xYk3tEnocn+ucfE1xFBcz/Zv09fTzJdOBB/FppPE4c30aGzJELxyyif xYJof9aSCboq2Y7KUzvg/x33vCK9eRUR8KuRGfOmVO57G3l2mXClwEpJ9eZSAjtTEsHC 60Dg== X-Gm-Message-State: AOAM533cy9mKfEFfGaFyO36wNo2cAE0gMiC8MfYldPIFR5vDJtvkQi4n /0FDImYMPTgnRCRNTYVTEjvwX036gXs= X-Google-Smtp-Source: ABdhPJxKrbel6HC1pGWcO1OKeAolTO8PpXTybRiEfVWWTPhivcm0v2d3TH/WuJKTKnCulLmy9RjZhA== X-Received: by 2002:a17:906:c10f:: with SMTP id do15mr2800308ejc.249.1592312779396; Tue, 16 Jun 2020 06:06:19 -0700 (PDT) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com. [209.85.221.46]) by smtp.gmail.com with ESMTPSA id z15sm10931989eju.18.2020.06.16.06.06.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2020 06:06:18 -0700 (PDT) Received: by mail-wr1-f46.google.com with SMTP id q11so20717448wrp.3 for ; Tue, 16 Jun 2020 06:06:17 -0700 (PDT) X-Received: by 2002:adf:f0c6:: with SMTP id x6mr3225697wro.301.1592312777282; Tue, 16 Jun 2020 06:06:17 -0700 (PDT) MIME-Version: 1.0 References: <12d37927-5608-b497-67cc-eb5436fa0b78@suse.com> In-Reply-To: <12d37927-5608-b497-67cc-eb5436fa0b78@suse.com> From: Tamas K Lengyel Date: Tue, 16 Jun 2020 07:05:40 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v19 for-4.14 00/13] VM forking To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Kevin Tian , Stefano Stabellini , Tamas K Lengyel , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jun Nakajima , Anthony PERARD , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 2:32 AM Jan Beulich wrote: > > On 01.06.2020 15:21, Tamas K Lengyel wrote: > > Tamas K Lengyel (13): > > x86/mem_sharing: block interrupt injection for forks > > tools/libxc: xc_memshr_fork with interrupts blocked > > I've committed these two, and I'll leave the rest to the tool stack > maintainers. Thanks! Tamas From xen-devel-bounces@lists.xenproject.org Tue Jun 16 13:26:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 13:26:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlBb2-00072s-A9; Tue, 16 Jun 2020 13:25:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlBb1-00072n-5c for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 13:25:47 +0000 X-Inumbo-ID: e25c7580-afd4-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e25c7580-afd4-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 13:25:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 47880AEF9; Tue, 16 Jun 2020 13:25:48 +0000 (UTC) Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Grzegorz Uriasz References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 15:25:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200616103204.GN735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 12:32, Roger Pau Monné wrote: > On Tue, Jun 16, 2020 at 10:07:05AM +0200, Jan Beulich wrote: >> On 14.06.2020 16:36, Grzegorz Uriasz wrote: >>> --- a/xen/arch/x86/acpi/boot.c >>> +++ b/xen/arch/x86/acpi/boot.c >>> @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) >>> if (fadt->xpm_timer_block.space_id == >>> ACPI_ADR_SPACE_SYSTEM_IO) { >>> pmtmr_ioport = fadt->xpm_timer_block.address; >>> - pmtmr_width = fadt->xpm_timer_block.bit_width; >>> + if (fadt->flags & ACPI_FADT_32BIT_TIMER) >>> + pmtmr_width = 32; >>> + else >>> + pmtmr_width = 24; >> >> I think disagreement of the two wants logging, and you want to >> default to using the smaller of the two (or even to ignoring the >> timer altogether). Then there wants to be a way to override >> (unless we already have one) our defaulting, in case it's wrong. > > TBH, I presume timer_block will always return 32bits, because that's > the size of the register. Then the timer can implement less bits than > the full size of the register, and that's what gets signaled using the > ACPI flags. What we care about here is the number of bits used by the > timer, not the size of the register. > > I think we should only ignore the timer if pm_timer_block.bit_width < > pmtmr_width. > > Printing a (debug) message when those values disagree is fine, but I > bet it's going to trigger always when the implemented timer is only > using 24bits. The 2nd system I tried on would trigger it, so maybe there's no point in logging indeed. How about the below as a basis? Jan --- unstable.orig/xen/arch/x86/acpi/boot.c +++ unstable/xen/arch/x86/acpi/boot.c @@ -480,7 +480,9 @@ static int __init acpi_parse_fadt(struct if (fadt->header.revision >= FADT2_REVISION_ID) { /* FADT rev. 2 */ if (fadt->xpm_timer_block.space_id == - ACPI_ADR_SPACE_SYSTEM_IO) { + ACPI_ADR_SPACE_SYSTEM_IO && + (fadt->xpm_timer_block.access_width == 0 || + fadt->xpm_timer_block.access_width == 3)) { pmtmr_ioport = fadt->xpm_timer_block.address; pmtmr_width = fadt->xpm_timer_block.bit_width; } @@ -492,8 +494,10 @@ static int __init acpi_parse_fadt(struct */ if (!pmtmr_ioport) { pmtmr_ioport = fadt->pm_timer_block; - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0; + pmtmr_width = fadt->pm_timer_length == 4 ? 32 : 0; } + if (pmtmr_width > 24 && !(fadt->flags & ACPI_FADT_32BIT_TIMER)) + pmtmr_width = 24; if (pmtmr_ioport) printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x (%u bits)\n", pmtmr_ioport, pmtmr_width); --- unstable.orig/xen/arch/x86/time.c +++ unstable/xen/arch/x86/time.c @@ -465,7 +465,7 @@ static s64 __init init_pmtimer(struct pl u64 start; u32 count, target, mask = 0xffffff; - if ( !pmtmr_ioport || !pmtmr_width ) + if ( !pmtmr_ioport ) return 0; if ( pmtmr_width == 32 ) @@ -473,6 +473,8 @@ static s64 __init init_pmtimer(struct pl pts->counter_bits = 32; mask = 0xffffffff; } + else if ( pmtmr_width != pts->counter_bits ) + return 0; count = inl(pmtmr_ioport) & mask; start = rdtsc_ordered(); From xen-devel-bounces@lists.xenproject.org Tue Jun 16 14:03:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 14:03:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlCB6-0001xn-5u; Tue, 16 Jun 2020 14:03:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlCB4-0001xi-LD for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 14:03:02 +0000 X-Inumbo-ID: 165d980a-afda-11ea-b8e8-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 165d980a-afda-11ea-b8e8-12813bfff9fa; Tue, 16 Jun 2020 14:03:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 83B12AC51; Tue, 16 Jun 2020 14:03:03 +0000 (UTC) Subject: Re: [PATCH-for-4.14] ioreq: handle pending emulation racing with ioreq server destruction To: paul@xen.org References: <20200608094619.28336-1-paul@xen.org> <4d63c9c7-f4e8-4c56-7778-df17b3c5254b@suse.com> <002a01d63d84$9c351430$d49f3c90$@xen.org> <86e29001-4b33-de46-0675-0107a2e2b386@suse.com> <00c201d63e72$a9d28bb0$fd77a310$@xen.org> <00c401d63e74$cf5c4ef0$6e14ecd0$@xen.org> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 16:02:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <00c401d63e74$cf5c4ef0$6e14ecd0$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 09.06.2020 17:44, Paul Durrant wrote: >> From: Jan Beulich >> Sent: 09 June 2020 16:33 >> >> On 09.06.2020 17:28, Paul Durrant wrote: >>>> From: Jan Beulich >>>> Sent: 09 June 2020 16:08 >>>> >>>> On 08.06.2020 13:04, Paul Durrant wrote: >>>>>> From: Jan Beulich >>>>>> Sent: 08 June 2020 11:58 >>>>>> >>>>>> On 08.06.2020 11:46, Paul Durrant wrote: >>>>>>> --- a/xen/arch/x86/hvm/ioreq.c >>>>>>> +++ b/xen/arch/x86/hvm/ioreq.c >>>>>>> @@ -109,15 +109,7 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data) >>>>>>> ioreq_t *ioreq = &v->arch.hvm.hvm_io.io_req; >>>>>>> >>>>>>> if ( hvm_ioreq_needs_completion(ioreq) ) >>>>>>> - { >>>>>>> - ioreq->state = STATE_IORESP_READY; >>>>>>> ioreq->data = data; >>>>>>> - } >>>>>>> - else >>>>>>> - ioreq->state = STATE_IOREQ_NONE; >>>>>>> - >>>>>>> - msix_write_completion(v); >>>>>>> - vcpu_end_shutdown_deferral(v); >>>>>>> >>>>>>> sv->pending = false; >>>>>>> } >>>>>> >>>>>> With this, is the function worth keeping at all? >>>>> >>>>> I did think about that, but it is called in more than one place. So, >>>>> in the interest of trying to make back-porting straightforward, I >>>>> thought it best to keep it simple. >>>> >>>> Fair enough, but going forward I still think it would be nice to get >>>> rid of the function. To do this sufficiently cleanly, the main >>>> question I have is: Why is hvm_wait_for_io() implemented as a loop? >>> >>> I guess the idea is that it should tolerate the emulator kicking the >>> event channel spuriously. I don't know whether this was the case at >>> one time, but it seems reasonable to be robust against waking up >>> from wait_on_xen_event_channel() before state has made it to >>> IORESP_READY. >> >> But such wakeup is taken care of by "goto recheck", not by the main >> loop in the function. > > Oh yes, sorry, I misread. It would be nice to get rid of the goto. I've done this in a pair of patches - first one doing as I suggested, second one doing as you suggested: Getting rid of the label and converting the fake loop put in place by the 1st one into a real loop again. I think it's better in two steps. But this isn't for 4.14, so I won't submit the pair right away. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 14:29:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 14:29:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlCaE-0003nB-Dx; Tue, 16 Jun 2020 14:29:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlCaC-0003n6-Tk for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 14:29:01 +0000 X-Inumbo-ID: b6fe111a-afdd-11ea-b8ef-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b6fe111a-afdd-11ea-b8ef-12813bfff9fa; Tue, 16 Jun 2020 14:28:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GNODHOI4/BU6f9CvM460r980pDYEkYQxnZf4eQNace4=; b=r3O3YDjA4VLzrLLS3vxlkzK1Y jssCNd8EtTFh4Wce6Glg8c7gX2aWiEbNC79zRRy7iwz5PssTILph3i1JG0EUjt4QjkdHjKgfTWUU8 8fy2+at9xygCRSPdtqQCqC8UhgToQg03dYcbDXae1Sp1uo0I9ywY+Z+Ja7mixy4nDvDcA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlCa9-0007jm-KM; Tue, 16 Jun 2020 14:28:57 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlCa9-0006vZ-9W; Tue, 16 Jun 2020 14:28:57 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlCa9-0001Cl-7R; Tue, 16 Jun 2020 14:28:57 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151148: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=b3a9e3b9622ae10064826dccb4f7a52bd88c7407 X-Osstest-Versions-That: linux=5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 From: osstest service owner Date: Tue, 16 Jun 2020 14:28:57 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151148 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151148/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151016 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151016 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151016 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux b3a9e3b9622ae10064826dccb4f7a52bd88c7407 baseline version: linux 5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 Last test of basis 151016 2020-06-10 12:58:42 Z 6 days Failing since 151044 2020-06-11 10:29:35 Z 5 days 4 attempts Testing same since 151148 2020-06-15 08:55:59 Z 1 days 1 attempts ------------------------------------------------------------ 538 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 33827 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:00:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:00:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlD4C-0006Kt-UZ; Tue, 16 Jun 2020 15:00:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlD4C-0006Kn-6j for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:00:00 +0000 X-Inumbo-ID: 0be86411-afe2-11ea-b8f6-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0be86411-afe2-11ea-b8f6-12813bfff9fa; Tue, 16 Jun 2020 14:59:59 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: pBu22Ny6/rkHpKQhPQ09Ef2otRuF2f8Ttb/FxRStwF4PuuiR8sMw0qk2946Ik7UDfGIPSIoqzD LYVR0jV+pQSkAoJR2/iDv5z28XrzcOwL6oEcII5fPKIyJdeyFDg91ktQPerC3NcC8HPmh5koGM 2sKTx4T4LmdgnD1WpNJuCtKsbj/sY6odzyTz/7dzi+1B2MRnyVHORaxDNUwYXpKHwTvenz/XD2 lKZ5kyJgsybm+IsLxYJZ8XPLVBZDYe3SwN/uy58Wl0Lcq50nn4btBasqgl8d9L+7lOnqKVv3ys llE= X-SBRS: 2.7 X-MesageID: 20188099 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20188099" Date: Tue, 16 Jun 2020 16:59:51 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Message-ID: <20200616145951.GP735@Air-de-Roger> References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 03:25:42PM +0200, Jan Beulich wrote: > On 16.06.2020 12:32, Roger Pau Monné wrote: > > On Tue, Jun 16, 2020 at 10:07:05AM +0200, Jan Beulich wrote: > >> On 14.06.2020 16:36, Grzegorz Uriasz wrote: > >>> --- a/xen/arch/x86/acpi/boot.c > >>> +++ b/xen/arch/x86/acpi/boot.c > >>> @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > >>> if (fadt->xpm_timer_block.space_id == > >>> ACPI_ADR_SPACE_SYSTEM_IO) { > >>> pmtmr_ioport = fadt->xpm_timer_block.address; > >>> - pmtmr_width = fadt->xpm_timer_block.bit_width; > >>> + if (fadt->flags & ACPI_FADT_32BIT_TIMER) > >>> + pmtmr_width = 32; > >>> + else > >>> + pmtmr_width = 24; > >> > >> I think disagreement of the two wants logging, and you want to > >> default to using the smaller of the two (or even to ignoring the > >> timer altogether). Then there wants to be a way to override > >> (unless we already have one) our defaulting, in case it's wrong. > > > > TBH, I presume timer_block will always return 32bits, because that's > > the size of the register. Then the timer can implement less bits than > > the full size of the register, and that's what gets signaled using the > > ACPI flags. What we care about here is the number of bits used by the > > timer, not the size of the register. > > > > I think we should only ignore the timer if pm_timer_block.bit_width < > > pmtmr_width. > > > > Printing a (debug) message when those values disagree is fine, but I > > bet it's going to trigger always when the implemented timer is only > > using 24bits. > > The 2nd system I tried on would trigger it, so maybe there's no point > in logging indeed. How about the below as a basis? > > Jan > > --- unstable.orig/xen/arch/x86/acpi/boot.c > +++ unstable/xen/arch/x86/acpi/boot.c > @@ -480,7 +480,9 @@ static int __init acpi_parse_fadt(struct > if (fadt->header.revision >= FADT2_REVISION_ID) { > /* FADT rev. 2 */ > if (fadt->xpm_timer_block.space_id == > - ACPI_ADR_SPACE_SYSTEM_IO) { > + ACPI_ADR_SPACE_SYSTEM_IO && > + (fadt->xpm_timer_block.access_width == 0 || > + fadt->xpm_timer_block.access_width == 3)) { We should really have defines for those values, or else they seem to imply actual access sizes. What about adding ACPI_ADDR_ACCESS_{LEGACY,BYTE,WORD,DWORD,QWORD}? Also the check for the access size seems kind of unrelated to the patch itself? (not that I'm opposed to it) > pmtmr_ioport = fadt->xpm_timer_block.address; > pmtmr_width = fadt->xpm_timer_block.bit_width; > } > @@ -492,8 +494,10 @@ static int __init acpi_parse_fadt(struct > */ > if (!pmtmr_ioport) { > pmtmr_ioport = fadt->pm_timer_block; > - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0; > + pmtmr_width = fadt->pm_timer_length == 4 ? 32 : 0; > } > + if (pmtmr_width > 24 && !(fadt->flags & ACPI_FADT_32BIT_TIMER)) > + pmtmr_width = 24; > if (pmtmr_ioport) > printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x (%u bits)\n", > pmtmr_ioport, pmtmr_width); > --- unstable.orig/xen/arch/x86/time.c > +++ unstable/xen/arch/x86/time.c > @@ -465,7 +465,7 @@ static s64 __init init_pmtimer(struct pl > u64 start; > u32 count, target, mask = 0xffffff; > > - if ( !pmtmr_ioport || !pmtmr_width ) > + if ( !pmtmr_ioport ) > return 0; > > if ( pmtmr_width == 32 ) > @@ -473,6 +473,8 @@ static s64 __init init_pmtimer(struct pl > pts->counter_bits = 32; > mask = 0xffffffff; > } > + else if ( pmtmr_width != pts->counter_bits ) > + return 0; > > count = inl(pmtmr_ioport) & mask; > start = rdtsc_ordered(); The rest LGTM. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:10:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:10:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDEE-0007uS-1b; Tue, 16 Jun 2020 15:10:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDEC-0007tw-UM for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:10:21 +0000 X-Inumbo-ID: 7dea92b2-afe3-11ea-b7bb-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7dea92b2-afe3-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 15:10:19 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id y13so21905348eju.2 for ; Tue, 16 Jun 2020 08:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=vjbzjTRd9SqaA31kjp9p8pzdssSbIqMwGtJOQtwIXT8=; b=f0Izth+twpiXefSm2ju6k2+iByI/ckTNnNOZIj0kVoNKSemOoJDm0OS0uLSR41vEad LbCADDXsUk3VCbZn47NrZjbkHJvi6cRgrV4jOe4JH2td4Zk9PXsYD9GQJA1jUvGxc0kK 75iLumt+Ef8ay3UcZwYwXY36sPlFlQoags1qOXfz0jbtLOXgD51u4zLy2CbloCBbtItd u9ctxyyMykNVK/Rz8ky+jEW74NsIVaNonss0SyBmD9tA3h3hzE4aWbPeGdjYrdOOipJ9 TfvEW0bvD50NkBZIuWb+7ktsI/m/HUsPLPNEtKDd4ahOxk96KyRBN66rY4v9YFZagVXe bJhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=vjbzjTRd9SqaA31kjp9p8pzdssSbIqMwGtJOQtwIXT8=; b=DGGRyYHc7yQMQvMi8qucJEiyPRqV2a6WZGQRY5I/JTZ94wPEM3mtBPZZndN/P7nyrQ s2vb05Xouz1D5+jAVqGTuKYCrb9NV7qeHprj3aIr/w9xyFiax9UDGfXh+FvuUWjEPsVG KA1wJTCt5SjeoUbvYMihH9OVgKjctPrmNDf5gFyf9Ce0WUtPxwOZnUsj0xkWG1KUEK9e ZkMfyjMU+l/lgMLld1fc9RmiW+qE0QuW7xR0OYXn0g+6STjPP7dq+79Pqif+c7RwH3cQ 1I9KCXsxjzbHjJ8hlOIU7EkaMOhI4CQJFUI2aO32feDuoNEWFqXlBi48dF/gKsfIoIpE UNVQ== X-Gm-Message-State: AOAM531PuBSYI89Y+VBSFWmjI6k9dN9EZlIkMBk/r20PUF+j9VdZPNCJ y4+lfcB0o5cMu8xttvR/pF4= X-Google-Smtp-Source: ABdhPJx48WaLsxbPWWBEwqnumbOBo/Fiob5ip8VxExxmzlO3VUJnQY1AozFJRfGWQPi9BV6bzDPAxw== X-Received: by 2002:a17:906:198d:: with SMTP id g13mr3158986ejd.281.1592320218673; Tue, 16 Jun 2020 08:10:18 -0700 (PDT) Received: from [192.168.8.124] (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id oq28sm11334217ejb.12.2020.06.16.08.10.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2020 08:10:17 -0700 (PDT) Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Jan Beulich References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> <20200616145951.GP735@Air-de-Roger> From: Grzegorz Uriasz Autocrypt: addr=gorbak25@gmail.com; prefer-encrypt=mutual; keydata= mQENBFyZgUUBCACo21Uf58hRRgX0uQd3kRJUqXp8/kJsC58tKZG9ENy8rvmcq15AmblqOQnD k6Pmh2lhh31A+m4ONF+TT0vlFYv9sN0kA1llvHPH95LYhROXt7UwSZBQTnQlLZFVqeGa3R6M pJwaAMQP/lyYgINt1pvBdCWtcNP/wKuNI/efnZuBOPDKSeBH/V0ZmmZxlSsx05/ktgtR6ibP FZXPBgx5DY0DxPm/jb8CqkXO5291wyYCP2VDy85oqG8EgsfFOOPZNwBQCKS7cWLZDMEsVNnB WyU3zJZBvEVK/5BwIzm1+AL9lR6RRLaOpC19k2ZqbyhEG9EhsR+/DIF0znBd9Nhjokd5ABEB AAG0JEdyemVnb3J6IFVyaWFzeiA8Z29yYmFrMjVAZ21haWwuY29tPokBVwQTAQgAQQIbAwUJ A8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHDkRnQjCGTnaTo/LngD9fcXMA1pBQJd /5CUAhkBAAoJEHgD9fcXMA1pb9YIAICTmZOrEGho9MC7z851jw507EamIqaAXQAADKpbxSGH yVxALYZv6cqR84rsQuML0N8ai4rdCJ7PviMYyaWVX3P09kJoFxSzKhjxbwZMkRF8O+9tIhNO 29h8v5cmv7Sp4NpssITFMZAms4LleJtdkivDeRxSCyJnHceZyGiD6pPTkopyuISGZIS+4axF zarn+JM+uiTm1QHdCbcvK3sor//QvHr9kKjLKTxMwiTZOGQzF8+oHpVxxwX8Bz3UbFwRX/Io rErT92f9WOsFWnvZHuLGcRLSlG0h9xljIuhP7mvGiudTgNoPt9YFtAG8KT/2HnUZ4XxJKi+B 8Ilet++3m4m5AQ0EXJmBRQEIANBww0bVhYwP1g4AMux/Fjp7KUjYj7Q8ej+t71ShZkAzvPQT 00ULdnYEa62uKM9YwXqOu0XJsnBveJKO1q3nfJuazAbsC0B3v0bYlUUQoTRxCUs3v22UOVxe kaTtN3KDdnSTq7QkkZBZFvV+vAwKGlqECzsYtZ86CiIEOgmUeVA82AzyMx306l1th90OdHYt LKkHxreEPWInN9jptOaKNwvB5cR6PxFfVRtVteN121tVJRK5geA0RVjHn35ig97ycDP5FcwP HuuuKfr+07ANXrtFM/QLGmIvEaMEgpPmzyGkXGhbsDpMikHOkXvQCRTesJ38r8DRUffinYXI vAw0IsMAEQEAAYkBPAQYAQgAJhYhBHDkRnQjCGTnaTo/LngD9fcXMA1pBQJcmYFFAhsMBQkD wmcAAAoJEHgD9fcXMA1p3y8H/2nftQbUcb2oKtpyePStdmdN45A1OWjorj6iBRvTOhoig6y7 PbveJ9Zj35IP0Zy4W77Ke4ayK/PiBkh7bRrdQAwTAc7EiYw3j+foO32JA/4bANMgSuRBxO/d xoloRPoaRE6eGUkA3N65V5WlWkinKxzSGDgSOz7Tit5QY8fGJYWeLTzFj605Y9iUu0MSLpfs LQQby+I9gETWh5TUMz1uNytIB80UdMpzqcC36zCMk7wIy1g8YhbehJq1zU1+ZpDrggrN3ucH 0NFFvHq5uwEkR8Llj29nDcyKuWMlnCMpM/iJcTde7N8UVdtN9yBGol4+yAZT0w5RP87pw3oD fuZMcoY= Message-ID: <3b02a2c4-1991-b7c3-1b5e-e388221fda19@gmail.com> Date: Tue, 16 Jun 2020 17:10:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200616145951.GP735@Air-de-Roger> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Hpm0V3gSivriNpTnX68iVzFwFe6oPVlE2" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Hpm0V3gSivriNpTnX68iVzFwFe6oPVlE2 Content-Type: multipart/mixed; boundary="C2RUB6eTBb9Ebz7wYKddxQ40ytaxzUc3B"; protected-headers="v1" From: Grzegorz Uriasz To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , marmarek@invisiblethingslab.com, artur@puzio.waw.pl, jakub@bartmin.ski, j.nowak26@student.uw.edu.pl Message-ID: <3b02a2c4-1991-b7c3-1b5e-e388221fda19@gmail.com> Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> <20200616145951.GP735@Air-de-Roger> In-Reply-To: <20200616145951.GP735@Air-de-Roger> --C2RUB6eTBb9Ebz7wYKddxQ40ytaxzUc3B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US I'm wondering why support for 32 bit acpi pm timers was introduced to xen= =2E Linux doesn't bother and just crops it to 24 bits: https://github.com/torvalds/linux/blob/a5dc8300df75e8b8384b4c82225f1e4a0b= 4d9b55/drivers/clocksource/acpi_pm.c#L37 Best regards, Grzegorz Uriasz On 16/06/2020 16:59, Roger Pau Monn=C3=A9 wrote: > On Tue, Jun 16, 2020 at 03:25:42PM +0200, Jan Beulich wrote: >> On 16.06.2020 12:32, Roger Pau Monn=C3=A9 wrote: >>> On Tue, Jun 16, 2020 at 10:07:05AM +0200, Jan Beulich wrote: >>>> On 14.06.2020 16:36, Grzegorz Uriasz wrote: >>>>> --- a/xen/arch/x86/acpi/boot.c >>>>> +++ b/xen/arch/x86/acpi/boot.c >>>>> @@ -480,7 +480,10 @@ static int __init acpi_parse_fadt(struct acpi_= table_header *table) >>>>> if (fadt->xpm_timer_block.space_id =3D=3D >>>>> ACPI_ADR_SPACE_SYSTEM_IO) { >>>>> pmtmr_ioport =3D fadt->xpm_timer_block.address; >>>>> - pmtmr_width =3D fadt->xpm_timer_block.bit_width; >>>>> + if (fadt->flags & ACPI_FADT_32BIT_TIMER) >>>>> + pmtmr_width =3D 32; >>>>> + else >>>>> + pmtmr_width =3D 24; >>>> I think disagreement of the two wants logging, and you want to >>>> default to using the smaller of the two (or even to ignoring the >>>> timer altogether). Then there wants to be a way to override >>>> (unless we already have one) our defaulting, in case it's wrong. >>> TBH, I presume timer_block will always return 32bits, because that's >>> the size of the register. Then the timer can implement less bits than= >>> the full size of the register, and that's what gets signaled using th= e >>> ACPI flags. What we care about here is the number of bits used by the= >>> timer, not the size of the register. >>> >>> I think we should only ignore the timer if pm_timer_block.bit_width <= >>> pmtmr_width. >>> >>> Printing a (debug) message when those values disagree is fine, but I >>> bet it's going to trigger always when the implemented timer is only >>> using 24bits. >> The 2nd system I tried on would trigger it, so maybe there's no point >> in logging indeed. How about the below as a basis? >> >> Jan >> >> --- unstable.orig/xen/arch/x86/acpi/boot.c >> +++ unstable/xen/arch/x86/acpi/boot.c >> @@ -480,7 +480,9 @@ static int __init acpi_parse_fadt(struct >> if (fadt->header.revision >=3D FADT2_REVISION_ID) { >> /* FADT rev. 2 */ >> if (fadt->xpm_timer_block.space_id =3D=3D >> - ACPI_ADR_SPACE_SYSTEM_IO) { >> + ACPI_ADR_SPACE_SYSTEM_IO && >> + (fadt->xpm_timer_block.access_width =3D=3D 0 || >> + fadt->xpm_timer_block.access_width =3D=3D 3)) { > We should really have defines for those values, or else they seem to > imply actual access sizes. What about adding > ACPI_ADDR_ACCESS_{LEGACY,BYTE,WORD,DWORD,QWORD}? > > Also the check for the access size seems kind of unrelated to the > patch itself? (not that I'm opposed to it) > >> pmtmr_ioport =3D fadt->xpm_timer_block.address; >> pmtmr_width =3D fadt->xpm_timer_block.bit_width; >> } >> @@ -492,8 +494,10 @@ static int __init acpi_parse_fadt(struct >> */ >> if (!pmtmr_ioport) { >> pmtmr_ioport =3D fadt->pm_timer_block; >> - pmtmr_width =3D fadt->pm_timer_length =3D=3D 4 ? 24 : 0; >> + pmtmr_width =3D fadt->pm_timer_length =3D=3D 4 ? 32 : 0; >> } >> + if (pmtmr_width > 24 && !(fadt->flags & ACPI_FADT_32BIT_TIMER)) >> + pmtmr_width =3D 24; >> if (pmtmr_ioport) >> printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x (%u bits)\n", >> pmtmr_ioport, pmtmr_width); >> --- unstable.orig/xen/arch/x86/time.c >> +++ unstable/xen/arch/x86/time.c >> @@ -465,7 +465,7 @@ static s64 __init init_pmtimer(struct pl >> u64 start; >> u32 count, target, mask =3D 0xffffff; >> =20 >> - if ( !pmtmr_ioport || !pmtmr_width ) >> + if ( !pmtmr_ioport ) >> return 0; >> =20 >> if ( pmtmr_width =3D=3D 32 ) >> @@ -473,6 +473,8 @@ static s64 __init init_pmtimer(struct pl >> pts->counter_bits =3D 32; >> mask =3D 0xffffffff; >> } >> + else if ( pmtmr_width !=3D pts->counter_bits ) >> + return 0; >> =20 >> count =3D inl(pmtmr_ioport) & mask; >> start =3D rdtsc_ordered(); > The rest LGTM. > > Thanks, Roger. --C2RUB6eTBb9Ebz7wYKddxQ40ytaxzUc3B-- --Hpm0V3gSivriNpTnX68iVzFwFe6oPVlE2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEcORGdCMIZOdpOj8ueAP19xcwDWkFAl7o4NcACgkQeAP19xcw DWnTxQgAlRurkr+IUwIwRgjB7vebvpbZBJI0/jYjYr9ri7yiWGiAcr98vTBTf5ps rVqC8MN3SYlrKx/AZDf7sODgDqhBn3UBcssXZcF18Tic7uU9BdjMHkx0lQ+RdHYW l5ol8GBEuK9KKXwGERt/YQKLAjmwGJ/nInWq66r5UmSAW4q82AYXM3z84Cc2/QLz My/kstsHrOrVXtz2NRDoHzI09LyMZw+mrDw8Of3D3aLL+T99lMTTAlNu2cwR1/l+ J0d9VeT5UojpTRE17hb6URtnWjRphWHi2HOVesk2kWZrkOnJkiiNpRZILhgd67ii rwLZRk53QSC6Ys9Vu+TQ0kihj+rVgQ== =+mWy -----END PGP SIGNATURE----- --Hpm0V3gSivriNpTnX68iVzFwFe6oPVlE2-- From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:12:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:12:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDFq-00080r-HE; Tue, 16 Jun 2020 15:12:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDFp-00080l-Rd for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:12:01 +0000 X-Inumbo-ID: ba28ffde-afe3-11ea-b8f8-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ba28ffde-afe3-11ea-b8f8-12813bfff9fa; Tue, 16 Jun 2020 15:12:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 71655B134; Tue, 16 Jun 2020 15:12:03 +0000 (UTC) Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> <20200616145951.GP735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 17:11:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200616145951.GP735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 16:59, Roger Pau Monné wrote: > On Tue, Jun 16, 2020 at 03:25:42PM +0200, Jan Beulich wrote: >> --- unstable.orig/xen/arch/x86/acpi/boot.c >> +++ unstable/xen/arch/x86/acpi/boot.c >> @@ -480,7 +480,9 @@ static int __init acpi_parse_fadt(struct >> if (fadt->header.revision >= FADT2_REVISION_ID) { >> /* FADT rev. 2 */ >> if (fadt->xpm_timer_block.space_id == >> - ACPI_ADR_SPACE_SYSTEM_IO) { >> + ACPI_ADR_SPACE_SYSTEM_IO && >> + (fadt->xpm_timer_block.access_width == 0 || >> + fadt->xpm_timer_block.access_width == 3)) { > > We should really have defines for those values, or else they seem to > imply actual access sizes. What about adding > ACPI_ADDR_ACCESS_{LEGACY,BYTE,WORD,DWORD,QWORD}? If there were such defines, I'd have used them. Adding them is inappropriate though, as this would modify an imported header in a Xen-specific way. We could leverage ACPI_ACCESS_BIT_WIDTH() here, though. > Also the check for the access size seems kind of unrelated to the > patch itself? (not that I'm opposed to it) It's related, but could also live in its own patch. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:13:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:13:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDGo-000862-Sm; Tue, 16 Jun 2020 15:13:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDGo-00085w-9y for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:13:02 +0000 X-Inumbo-ID: de536fca-afe3-11ea-8496-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id de536fca-afe3-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 15:13:01 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: G/ua9LN3ZDI39gmrIIaOyrreoRSGCiAsik8BKqfRXz+lTQuxBWiB+DolOHt+TxMoc7TcebbbVq s4twHHI0M9QCAkTb7fczPyg+ILCK4hoD9btL5Q5OtXN7hK4MjN+bga104z0HJ6uNvS81wFI0DZ 6jaTj4i8dR2H3wZbTNiXA1cSB8ZAqKBvVQtPPSj6IDldLw+a7s/TxV17O39YZybU1//CCebyV1 yTTRAqtLaCKdhQ8O/cjUlJUDzexwd3x0TY6zTvDtGSaO1x0hcq7GQld/yxo8B7lvXgdtTECq8t zmU= X-SBRS: 2.7 X-MesageID: 20522948 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20522948" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24296.57720.98604.298669@mariner.uk.xensource.com> Date: Tue, 16 Jun 2020 16:12:56 +0100 To: Jan Beulich Subject: Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages] In-Reply-To: <107f8a65-4b2d-7417-3625-73bc543bcc48@suse.com> References: <24291.43673.301735.439410@mariner.uk.xensource.com> <24291.45488.423085.940252@mariner.uk.xensource.com> <3c68a609-a069-f7e1-3c99-291da372df96@suse.com> <24295.31551.406528.629952@mariner.uk.xensource.com> <3849058f-32db-2294-6aa6-c8f829571f4b@suse.com> <24295.32975.664225.928516@mariner.uk.xensource.com> <107f8a65-4b2d-7417-3625-73bc543bcc48@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , George Dunlap , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jan Beulich writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]"): > Right - which will then enable 4.10's -prev build to work, which > will in turn allow 4.11's -prev builds to work, and then the same > for 4.12. I.e. osstest will continue to be quite busy for the > next several days. Yes. > Instead of building -prev anew each time, wouldn't it make sense > to store and re-use the most recent "prev" tree's build? This > ought to avoid this sort of cascade dependencies in particular > when upgrading the test platform underneath. There's no reason > to fail a flight just because the N-1 tree doesn't build anymore. Well. In principle, yes. Fairly recently osstest got machinery to do that kind of anointed build outputs. It's not entirely trivial, and this kind of thing happens about once every two years. We're noticing two such cases in a row because we put off the osstest stretch upgrade and are now doing the buster one early. Ian. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:13:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:13:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDH5-00089D-5L; Tue, 16 Jun 2020 15:13:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDH3-000891-Ky for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:13:17 +0000 X-Inumbo-ID: e797b046-afe3-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e797b046-afe3-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 15:13:17 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EF7A5B1A2; Tue, 16 Jun 2020 15:13:19 +0000 (UTC) Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: Grzegorz Uriasz References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> <20200616145951.GP735@Air-de-Roger> <3b02a2c4-1991-b7c3-1b5e-e388221fda19@gmail.com> From: Jan Beulich Message-ID: Date: Tue, 16 Jun 2020 17:13:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <3b02a2c4-1991-b7c3-1b5e-e388221fda19@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 17:10, Grzegorz Uriasz wrote: > I'm wondering why support for 32 bit acpi pm timers was introduced to xen. The handling of the timer wrapping is less overhead is a wider timer can be used. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:17:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:17:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDKb-0008OO-M6; Tue, 16 Jun 2020 15:16:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDKZ-0008OJ-P4 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:16:55 +0000 X-Inumbo-ID: 68f9762f-afe4-11ea-b8f8-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 68f9762f-afe4-11ea-b8f8-12813bfff9fa; Tue, 16 Jun 2020 15:16:54 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id BDEB0A1EDC; Tue, 16 Jun 2020 17:16:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id ADA4AA1E57; Tue, 16 Jun 2020 17:16:52 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id d4Oc7ZxbE7vG; Tue, 16 Jun 2020 17:16:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 41D26A1EDC; Tue, 16 Jun 2020 17:16:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7gQ3RLl0PgFk; Tue, 16 Jun 2020 17:16:52 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 11628A1E57; Tue, 16 Jun 2020 17:16:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id E7DC9214C8; Tue, 16 Jun 2020 17:16:21 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PXgAh7m7lCU2; Tue, 16 Jun 2020 17:16:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 7E9B82174D; Tue, 16 Jun 2020 17:16:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wt5N3s1wAxGg; Tue, 16 Jun 2020 17:16:16 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 5861D215F4; Tue, 16 Jun 2020 17:16:16 +0200 (CEST) Date: Tue, 16 Jun 2020 17:16:16 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Subject: [PATCH v1 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hg== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jun Nakajima , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Intel Processor Trace is an architectural extension available in modern Intel family CPUs. It allows recording the detailed trace of activity while the processor executes the code. One might use the recorded trace to reconstruct the code flow. It means, to find out the executed code paths, determine branches taken, and so forth. The abovementioned feature is described in Intel(R) 64 and IA-32 Architectures Software Developer's Manual Volume 3C: System Programming Guide, Part 3, Chapter 36: "Intel Processor Trace." This patch series implements an interface that Dom0 could use in order to enable IPT for particular vCPUs in DomU, allowing for external monitoring. Such a feature has numerous applications like malware monitoring, fuzzing, or performance testing. Michal Leszczynski (7): x86/vmx: add Intel PT MSR definitions x86/vmx: add IPT cpu feature x86/vmx: add ipt_state as part of vCPU state x86/vmx: add do_vmtrace_op tools/libxc: add xc_ptbuf_* functions tools/proctrace: add proctrace tool x86/vmx: switch IPT MSRs on vmentry/vmexit tools/libxc/include/xenctrl.h | 59 ++++ tools/libxc/xc_tbuf.c | 108 +++++++ tools/proctrace/COPYING | 339 ++++++++++++++++++++ tools/proctrace/Makefile | 49 +++ tools/proctrace/proctrace.c | 139 ++++++++ xen/arch/x86/hvm/hvm.c | 170 ++++++++++ xen/arch/x86/hvm/vmx/vmx.c | 52 +++ xen/include/asm-x86/cpufeature.h | 1 + xen/include/asm-x86/hvm/hvm.h | 9 + xen/include/asm-x86/hvm/vmx/vmcs.h | 11 + xen/include/asm-x86/msr-index.h | 37 +++ xen/include/public/arch-x86/cpufeatureset.h | 1 + xen/include/public/hvm/hvm_op.h | 27 ++ 13 files changed, 1002 insertions(+) create mode 100644 tools/proctrace/COPYING create mode 100644 tools/proctrace/Makefile create mode 100644 tools/proctrace/proctrace.c -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:20:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:20:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDO2-0000ld-5t; Tue, 16 Jun 2020 15:20:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDO0-0000lW-Lq for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:20:28 +0000 X-Inumbo-ID: e7e79543-afe4-11ea-b8fa-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e7e79543-afe4-11ea-b8fa-12813bfff9fa; Tue, 16 Jun 2020 15:20:27 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 61494A2F7F; Tue, 16 Jun 2020 17:20:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 5932FA2F1B; Tue, 16 Jun 2020 17:20:25 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ygcaQrcrZZFG; Tue, 16 Jun 2020 17:20:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id DF56DA2F83; Tue, 16 Jun 2020 17:20:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YzAseoL7iKyk; Tue, 16 Jun 2020 17:20:24 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id B8BA2A2F7F; Tue, 16 Jun 2020 17:20:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id A898C214C8; Tue, 16 Jun 2020 17:19:54 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0s9kBhbUbJkK; Tue, 16 Jun 2020 17:19:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 4831B219C6; Tue, 16 Jun 2020 17:19:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LDyti-DuYn1R; Tue, 16 Jun 2020 17:19:49 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 2BCD721979; Tue, 16 Jun 2020 17:19:49 +0200 (CEST) Date: Tue, 16 Jun 2020 17:19:49 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <2141998496.8765382.1592320789155.JavaMail.zimbra@cert.pl> In-Reply-To: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Subject: [PATCH v1 1/7] x86/vmx: add Intel PT MSR definitions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add Intel PT MSR definitions Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hpInjbCi X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Wei Liu , Jan Beulich , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Define constants related to Intel Processor Trace features. Signed-off-by: Michal Leszczynski --- xen/include/asm-x86/msr-index.h | 37 +++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h index b328a47ed8..ecf0dd8bab 100644 --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -621,4 +621,41 @@ #define MSR_PKGC9_IRTL 0x00000634 #define MSR_PKGC10_IRTL 0x00000635 +/* Intel PT MSRs */ +#define MSR_IA32_RTIT_CTL 0x00000570 +#define RTIT_CTL_TRACEEN (1ULL << 0) +#define RTIT_CTL_CYCEN (1ULL << 1) +#define RTIT_CTL_OS (1ULL << 2) +#define RTIT_CTL_USR (1ULL << 3) +#define RTIT_CTL_PWR_EVT_EN (1ULL << 4) +#define RTIT_CTL_FUP_ON_PTW (1ULL << 5) +#define RTIT_CTL_FABRIC_EN (1ULL << 6) +#define RTIT_CTL_CR3_FILTER (1ULL << 7) +#define RTIT_CTL_TOPA (1ULL << 8) +#define RTIT_CTL_MTC_EN (1ULL << 9) +#define RTIT_CTL_TSC_EN (1ULL << 10) +#define RTIT_CTL_DIS_RETC (1ULL << 11) +#define RTIT_CTL_PTW_EN (1ULL << 12) +#define RTIT_CTL_BRANCH_EN (1ULL << 13) +#define RTIT_CTL_MTC_FREQ_OFFSET 14 +#define RTIT_CTL_MTC_FREQ (0x0fULL << RTIT_CTL_MTC_FREQ_OFFSET) +#define RTIT_CTL_CYC_THRESH_OFFSET 19 +#define RTIT_CTL_CYC_THRESH (0x0fULL << RTIT_CTL_CYC_THRESH_OFFSET) +#define RTIT_CTL_PSB_FREQ_OFFSET 24 +#define RTIT_CTL_PSB_FREQ (0x0fULL << RTIT_CTL_PSB_FREQ_OFFSET) +#define RTIT_CTL_ADDR_OFFSET(n) (32 + 4 * (n)) +#define RTIT_CTL_ADDR(n) (0x0fULL << RTIT_CTL_ADDR_OFFSET(n)) +#define MSR_IA32_RTIT_STATUS 0x00000571 +#define RTIT_STATUS_FILTER_EN (1ULL << 0) +#define RTIT_STATUS_CONTEXT_EN (1ULL << 1) +#define RTIT_STATUS_TRIGGER_EN (1ULL << 2) +#define RTIT_STATUS_ERROR (1ULL << 4) +#define RTIT_STATUS_STOPPED (1ULL << 5) +#define RTIT_STATUS_BYTECNT (0x1ffffULL << 32) +#define MSR_IA32_RTIT_CR3_MATCH 0x00000572 +#define MSR_IA32_RTIT_OUTPUT_BASE 0x00000560 +#define MSR_IA32_RTIT_OUTPUT_MASK 0x00000561 +#define MSR_IA32_RTIT_ADDR_A(n) (0x00000580 + (n) * 2) +#define MSR_IA32_RTIT_ADDR_B(n) (0x00000581 + (n) * 2) + #endif /* __ASM_MSR_INDEX_H */ -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:21:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:21:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDOq-0000p0-Fk; Tue, 16 Jun 2020 15:21:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDOp-0000od-IM for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:21:19 +0000 X-Inumbo-ID: 0607135e-afe5-11ea-b8fa-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0607135e-afe5-11ea-b8fa-12813bfff9fa; Tue, 16 Jun 2020 15:21:17 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id DCE1AA2F7F; Tue, 16 Jun 2020 17:21:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id D1CF0A2F1B; Tue, 16 Jun 2020 17:21:15 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1IX_Wv1W9EV2; Tue, 16 Jun 2020 17:21:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3F5A9A2F7F; Tue, 16 Jun 2020 17:21:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CYIsx1oo8cqH; Tue, 16 Jun 2020 17:21:15 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id D8E49A2F1B; Tue, 16 Jun 2020 17:21:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id C7E88214C8; Tue, 16 Jun 2020 17:20:44 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UCz46vSR1JE1; Tue, 16 Jun 2020 17:20:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 3C30A215F4; Tue, 16 Jun 2020 17:20:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QRbMjIWtaEP1; Tue, 16 Jun 2020 17:20:39 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 1E18C214C8; Tue, 16 Jun 2020 17:20:39 +0200 (CEST) Date: Tue, 16 Jun 2020 17:20:39 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <1672321493.8765712.1592320839082.JavaMail.zimbra@cert.pl> In-Reply-To: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Subject: [PATCH v1 2/7] x86/vmx: add IPT cpu feature MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add IPT cpu feature Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hgbflCcQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Check if Intel Processor Trace feature is supported by current processor. Define hvm_ipt_supported function. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/vmx/vmx.c | 24 +++++++++++++++++++++ xen/include/asm-x86/cpufeature.h | 1 + xen/include/asm-x86/hvm/hvm.h | 9 ++++++++ xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + xen/include/public/arch-x86/cpufeatureset.h | 1 + 5 files changed, 36 insertions(+) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index ab19d9424e..a91bbdb798 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -2484,6 +2484,7 @@ static bool __init has_if_pschange_mc(void) const struct hvm_function_table * __init start_vmx(void) { + u64 _vmx_misc_cap; set_in_cr4(X86_CR4_VMXE); if ( vmx_vmcs_init() ) @@ -2557,6 +2558,29 @@ const struct hvm_function_table * __init start_vmx(void) vmx_function_table.get_guest_bndcfgs = vmx_get_guest_bndcfgs; } + /* Check whether IPT is supported in VMX operation */ + vmx_function_table.ipt_supported = 1; + + if ( !cpu_has_ipt ) + { + vmx_function_table.ipt_supported = 0; + printk("VMX: Missing support for Intel Processor Trace x86 feature.\n"); + } + + rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); + + if ( !( _vmx_misc_cap & VMX_MISC_PT_SUPPORTED ) ) + { + vmx_function_table.ipt_supported = 0; + printk("VMX: Missing support for Intel Processor Trace in VMX operation, VMX_MISC caps: %llx\n", + (unsigned long long)_vmx_misc_cap); + } + + if (vmx_function_table.ipt_supported) + { + printk("VMX: Intel Processor Trace is SUPPORTED"); + } + lbr_tsx_fixup_check(); ler_to_fixup_check(); diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h index f790d5c1f8..8d7955dd87 100644 --- a/xen/include/asm-x86/cpufeature.h +++ b/xen/include/asm-x86/cpufeature.h @@ -104,6 +104,7 @@ #define cpu_has_clwb boot_cpu_has(X86_FEATURE_CLWB) #define cpu_has_avx512er boot_cpu_has(X86_FEATURE_AVX512ER) #define cpu_has_avx512cd boot_cpu_has(X86_FEATURE_AVX512CD) +#define cpu_has_ipt boot_cpu_has(X86_FEATURE_IPT) #define cpu_has_sha boot_cpu_has(X86_FEATURE_SHA) #define cpu_has_avx512bw boot_cpu_has(X86_FEATURE_AVX512BW) #define cpu_has_avx512vl boot_cpu_has(X86_FEATURE_AVX512VL) diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h index 1eb377dd82..48465b6067 100644 --- a/xen/include/asm-x86/hvm/hvm.h +++ b/xen/include/asm-x86/hvm/hvm.h @@ -96,6 +96,9 @@ struct hvm_function_table { /* Necessary hardware support for alternate p2m's? */ bool altp2m_supported; + /* Hardware support for IPT? */ + bool ipt_supported; + /* Hardware virtual interrupt delivery enable? */ bool virtual_intr_delivery_enabled; @@ -630,6 +633,12 @@ static inline bool hvm_altp2m_supported(void) return hvm_funcs.altp2m_supported; } +/* returns true if hardware supports Intel Processor Trace */ +static inline bool hvm_ipt_supported(void) +{ + return hvm_funcs.ipt_supported; +} + /* updates the current hardware p2m */ static inline void altp2m_vcpu_update_p2m(struct vcpu *v) { diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h index 906810592f..4c81093aba 100644 --- a/xen/include/asm-x86/hvm/vmx/vmcs.h +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h @@ -285,6 +285,7 @@ extern u64 vmx_ept_vpid_cap; #define VMX_MISC_CR3_TARGET 0x01ff0000 #define VMX_MISC_VMWRITE_ALL 0x20000000 +#define VMX_MISC_PT_SUPPORTED 0x00004000 #define VMX_TSC_MULTIPLIER_MAX 0xffffffffffffffffULL diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 5ca35d9d97..7cfcac451d 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -217,6 +217,7 @@ XEN_CPUFEATURE(SMAP, 5*32+20) /*S Supervisor Mode Access Prevention */ XEN_CPUFEATURE(AVX512_IFMA, 5*32+21) /*A AVX-512 Integer Fused Multiply Add */ XEN_CPUFEATURE(CLFLUSHOPT, 5*32+23) /*A CLFLUSHOPT instruction */ XEN_CPUFEATURE(CLWB, 5*32+24) /*A CLWB instruction */ +XEN_CPUFEATURE(IPT, 5*32+25) /*H Intel Processor Trace */ XEN_CPUFEATURE(AVX512PF, 5*32+26) /*A AVX-512 Prefetch Instructions */ XEN_CPUFEATURE(AVX512ER, 5*32+27) /*A AVX-512 Exponent & Reciprocal Instrs */ XEN_CPUFEATURE(AVX512CD, 5*32+28) /*A AVX-512 Conflict Detection Instrs */ -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:22:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:22:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDPV-0000vc-Tl; Tue, 16 Jun 2020 15:22:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDPU-0000vQ-9X for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:22:00 +0000 X-Inumbo-ID: 1e18a612-afe5-11ea-b8fa-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1e18a612-afe5-11ea-b8fa-12813bfff9fa; Tue, 16 Jun 2020 15:21:59 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 18686A2F7F; Tue, 16 Jun 2020 17:21:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 0C8D0A2F1B; Tue, 16 Jun 2020 17:21:57 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UBh7yD0Q_2US; Tue, 16 Jun 2020 17:21:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A2C70A2F7F; Tue, 16 Jun 2020 17:21:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y0ro_Gds4p5k; Tue, 16 Jun 2020 17:21:56 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 844D7A2F1B; Tue, 16 Jun 2020 17:21:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 756FD21CD9; Tue, 16 Jun 2020 17:21:26 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1eyUKdjSSdwE; Tue, 16 Jun 2020 17:21:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 1F635215F4; Tue, 16 Jun 2020 17:21:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eWkXsYekw6L8; Tue, 16 Jun 2020 17:21:21 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 0277F214C8; Tue, 16 Jun 2020 17:21:21 +0200 (CEST) Date: Tue, 16 Jun 2020 17:21:20 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <350253733.8765869.1592320880975.JavaMail.zimbra@cert.pl> In-Reply-To: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Subject: [PATCH v1 3/7] x86/vmx: add ipt_state as part of vCPU state MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add ipt_state as part of vCPU state Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9htw5L6rA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Guest IPT state will be preserved across vmentry/vmexit using this structure. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/vmx/vmx.c | 2 ++ xen/include/asm-x86/hvm/vmx/vmcs.h | 10 ++++++++++ 2 files changed, 12 insertions(+) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index a91bbdb798..97104c319e 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -471,6 +471,8 @@ static int vmx_vcpu_initialise(struct vcpu *v) vmx_install_vlapic_mapping(v); + v->arch.hvm.vmx.ipt_state = NULL; + return 0; } diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h index 4c81093aba..273ade975e 100644 --- a/xen/include/asm-x86/hvm/vmx/vmcs.h +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h @@ -104,6 +104,13 @@ struct pi_blocking_vcpu { spinlock_t *lock; }; +struct ipt_state { + uint64_t ctl; + uint64_t status; + uint64_t output_base; + uint64_t output_mask; +}; + struct vmx_vcpu { /* Physical address of VMCS. */ paddr_t vmcs_pa; @@ -186,6 +193,9 @@ struct vmx_vcpu { * pCPU and wakeup the related vCPU. */ struct pi_blocking_vcpu pi_blocking; + + /* State of Intel Processor Trace feature */ + struct ipt_state *ipt_state; }; int vmx_create_vmcs(struct vcpu *v); -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:22:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:22:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDQG-00011J-82; Tue, 16 Jun 2020 15:22:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDQE-000115-EV for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:22:46 +0000 X-Inumbo-ID: 39ed800f-afe5-11ea-b8fb-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 39ed800f-afe5-11ea-b8fb-12813bfff9fa; Tue, 16 Jun 2020 15:22:45 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 87EA5A2F1B; Tue, 16 Jun 2020 17:22:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7EFD5A2F86; Tue, 16 Jun 2020 17:22:43 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id k520iwlHXV1R; Tue, 16 Jun 2020 17:22:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A3E14A2F1B; Tue, 16 Jun 2020 17:22:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S-E8qDuhu-li; Tue, 16 Jun 2020 17:22:42 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7883CA2EB4; Tue, 16 Jun 2020 17:22:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 6459D214C8; Tue, 16 Jun 2020 17:22:12 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZJhkWkqAVr-5; Tue, 16 Jun 2020 17:22:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id C3771215F4; Tue, 16 Jun 2020 17:22:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id U8Kp1bAsH24b; Tue, 16 Jun 2020 17:22:06 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id A637C214C8; Tue, 16 Jun 2020 17:22:06 +0200 (CEST) Date: Tue, 16 Jun 2020 17:22:06 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> In-Reply-To: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Subject: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hhQhQ0/T X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Provide an interface for privileged domains to manage external IPT monitoring. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/hvm.c | 170 ++++++++++++++++++++++++++++++++ xen/include/public/hvm/hvm_op.h | 27 +++++ 2 files changed, 197 insertions(+) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 5bb47583b3..9292caebe0 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4949,6 +4949,172 @@ static int compat_altp2m_op( return rc; } +static int do_vmtrace_op( + XEN_GUEST_HANDLE_PARAM(void) arg) +{ + struct xen_hvm_vmtrace_op a; + struct domain *d = NULL; + int rc = -EFAULT; + int i; + struct vcpu *v; + void* buf; + uint32_t buf_size; + uint32_t buf_order; + uint64_t buf_mfn; + struct page_info *pg; + + if ( !hvm_ipt_supported() ) + return -EOPNOTSUPP; + + if ( copy_from_guest(&a, arg, 1) ) + return -EFAULT; + + if ( a.version != HVMOP_VMTRACE_INTERFACE_VERSION ) + return -EINVAL; + + switch ( a.cmd ) + { + case HVMOP_vmtrace_ipt_enable: + case HVMOP_vmtrace_ipt_disable: + case HVMOP_vmtrace_ipt_get_buf: + case HVMOP_vmtrace_ipt_get_offset: + break; + + default: + return -EOPNOTSUPP; + } + + d = rcu_lock_domain_by_any_id(a.domain); + + if ( d == NULL ) + return -ESRCH; + + if ( !is_hvm_domain(d) ) + { + rc = -EOPNOTSUPP; + goto out; + } + + domain_pause(d); + + if ( a.vcpu >= d->max_vcpus ) + { + rc = -EINVAL; + goto out; + } + + v = d->vcpu[a.vcpu]; + + if ( a.cmd == HVMOP_vmtrace_ipt_enable ) + { + if ( v->arch.hvm.vmx.ipt_state ) { + // already enabled + rc = -EINVAL; + goto out; + } + + if ( a.size < PAGE_SIZE || a.size > 1000000 * PAGE_SIZE ) { + // we don't accept trace buffer size smaller than single page + // and the upper bound is defined as 4GB in the specification + rc = -EINVAL; + goto out; + } + + buf_order = get_order_from_bytes(a.size); + + if ( (a.size >> PAGE_SHIFT) != (1 << buf_order) ) { + rc = -EINVAL; + goto out; + } + + buf = page_to_virt(alloc_domheap_pages(d, buf_order, MEMF_no_refcount)); + buf_size = a.size; + + if ( !buf ) { + rc = -EFAULT; + goto out; + } + + memset(buf, 0, buf_size); + + for ( i = 0; i < (buf_size >> PAGE_SHIFT); i++ ) { + share_xen_page_with_privileged_guests(virt_to_page(buf) + i, SHARE_ro); + } + + v->arch.hvm.vmx.ipt_state = xmalloc(struct ipt_state); + v->arch.hvm.vmx.ipt_state->output_base = virt_to_mfn(buf) << PAGE_SHIFT; + v->arch.hvm.vmx.ipt_state->output_mask = buf_size - 1; + v->arch.hvm.vmx.ipt_state->status = 0; + v->arch.hvm.vmx.ipt_state->ctl = RTIT_CTL_TRACEEN | RTIT_CTL_OS | RTIT_CTL_USR | RTIT_CTL_BRANCH_EN; + } + else if ( a.cmd == HVMOP_vmtrace_ipt_disable ) + { + if ( !v->arch.hvm.vmx.ipt_state ) { + rc = -EINVAL; + goto out; + } + + buf_mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT; + buf_size = ( v->arch.hvm.vmx.ipt_state->output_mask + 1 ) & 0xFFFFFFFFUL; + + for ( i = 0; i < (buf_size >> PAGE_SHIFT); i++ ) + { + if ( (mfn_to_page(_mfn(buf_mfn + i))->count_info & PGC_count_mask) != 1 ) + { + rc = -EBUSY; + goto out; + } + } + + xfree(v->arch.hvm.vmx.ipt_state); + v->arch.hvm.vmx.ipt_state = NULL; + + for ( i = 0; i < (buf_size >> PAGE_SHIFT); i++ ) + { + pg = mfn_to_page(_mfn(buf_mfn + i)); + put_page_alloc_ref(pg); + if ( !test_and_clear_bit(_PGC_xen_heap, &pg->count_info) ) + ASSERT_UNREACHABLE(); + pg->u.inuse.type_info = 0; + page_set_owner(pg, NULL); + free_domheap_page(pg); + } + } + else if ( a.cmd == HVMOP_vmtrace_ipt_get_buf ) + { + if ( !v->arch.hvm.vmx.ipt_state ) { + rc = -EINVAL; + goto out; + } + + a.mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT; + a.size = (v->arch.hvm.vmx.ipt_state->output_mask + 1) & 0xFFFFFFFFUL; + } + else if ( a.cmd == HVMOP_vmtrace_ipt_get_offset ) + { + if ( !v->arch.hvm.vmx.ipt_state ) { + rc = -EINVAL; + goto out; + } + + a.offset = v->arch.hvm.vmx.ipt_state->output_mask >> 32; + } + + rc = -EFAULT; + if ( __copy_to_guest(arg, &a, 1) ) + goto out; + rc = 0; + + out: + smp_wmb(); + domain_unpause(d); + rcu_unlock_domain(d); + + return rc; +} + +DEFINE_XEN_GUEST_HANDLE(compat_hvm_vmtrace_op_t); + static int hvmop_get_mem_type( XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg) { @@ -5101,6 +5267,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) rc = current->hcall_compat ? compat_altp2m_op(arg) : do_altp2m_op(arg); break; + case HVMOP_vmtrace: + rc = do_vmtrace_op(arg); + break; + default: { gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op); diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h index 870ec52060..3bbcd54c96 100644 --- a/xen/include/public/hvm/hvm_op.h +++ b/xen/include/public/hvm/hvm_op.h @@ -382,6 +382,33 @@ struct xen_hvm_altp2m_op { typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); +/* HVMOP_vmtrace: Perform VM tracing related operation */ +#define HVMOP_vmtrace 26 + +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 + +struct xen_hvm_vmtrace_op { + /* IN variable */ + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ + uint32_t cmd; +/* Enable/disable external vmtrace for given domain */ +#define HVMOP_vmtrace_ipt_enable 1 +#define HVMOP_vmtrace_ipt_disable 2 +#define HVMOP_vmtrace_ipt_get_buf 3 +#define HVMOP_vmtrace_ipt_get_offset 4 + domid_t domain; + uint32_t vcpu; + + /* IN/OUT variable */ + uint64_t size; + + /* OUT variable */ + uint64_t mfn; + uint64_t offset; +}; +typedef struct xen_hvm_vmtrace_op xen_hvm_vmtrace_op_t; +DEFINE_XEN_GUEST_HANDLE(xen_hvm_vmtrace_op_t); + #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */ /* -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:23:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:23:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDQu-00017r-HJ; Tue, 16 Jun 2020 15:23:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDQt-00017i-8H for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:23:27 +0000 X-Inumbo-ID: 5287aa40-afe5-11ea-b8fc-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5287aa40-afe5-11ea-b8fc-12813bfff9fa; Tue, 16 Jun 2020 15:23:26 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 482C2A2F1B; Tue, 16 Jun 2020 17:23:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 43D40A2EB4; Tue, 16 Jun 2020 17:23:24 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QhxJwfgYP_-e; Tue, 16 Jun 2020 17:23:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A4B42A2F1B; Tue, 16 Jun 2020 17:23:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0bmM42s5bl3B; Tue, 16 Jun 2020 17:23:23 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 843CDA2EB4; Tue, 16 Jun 2020 17:23:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 77283214C8; Tue, 16 Jun 2020 17:22:53 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PSsucB3G25kB; Tue, 16 Jun 2020 17:22:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id E204B215F4; Tue, 16 Jun 2020 17:22:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FEy7X_fQbIBF; Tue, 16 Jun 2020 17:22:47 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id C7EA5214C8; Tue, 16 Jun 2020 17:22:47 +0200 (CEST) Date: Tue, 16 Jun 2020 17:22:47 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <1945850288.8766285.1592320967782.JavaMail.zimbra@cert.pl> In-Reply-To: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Subject: [PATCH v1 5/7] tools/libxc: add xc_ptbuf_* functions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: tools/libxc: add xc_ptbuf_* functions Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hpY5dAoC X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add functions in libxc that use the new HVMOP_vmtrace interface. Signed-off-by: Michal Leszczynski --- tools/libxc/include/xenctrl.h | 59 +++++++++++++++++++ tools/libxc/xc_tbuf.c | 108 ++++++++++++++++++++++++++++++++++ 2 files changed, 167 insertions(+) diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 113ddd935d..0a972deb7d 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -1585,6 +1585,65 @@ int xc_tbuf_set_cpu_mask(xc_interface *xch, xc_cpumap_t mask); int xc_tbuf_set_evt_mask(xc_interface *xch, uint32_t mask); +/** + * Enable Intel Processor Trace for given vCPU in given DomU. + * Allocate the trace ringbuffer with given size. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @parm size trace buffer size in bytes, must be power of 2, between 4 kB and 4 GB + * @return 0 on success, -1 on failure + */ +int xc_ptbuf_enable(xc_interface *xch, uint32_t domid, uint32_t vcpu, uint64_t size); + +/** + * Disable Intel Processor Trace for given vCPU in given DomU. + * Deallocate the trace ringbuffer. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @return 0 on success, -1 on failure + */ +int xc_ptbuf_disable(xc_interface *xch, uint32_t domid, uint32_t vcpu); + +/** + * Map the trace buffer into Dom0. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @parm buf pointer to the mapped buffer will be written there + * @parm trace buffer size (in bytes) will be written there + * @return 0 on success, -1 on failure + */ +int xc_ptbuf_map(xc_interface *xch, uint32_t domid, uint32_t vcpu, uint8_t **buf, uint64_t *size); + +/** + * Unmap the trace buffer from Dom0. + * + * @parm xch a handle to an open hypervisor interface + * @parm buf pointer to the mapped buffer + * @parm size of the trace buffer (in bytes) + * @return 0 on success, -1 on failure + */ +int xc_ptbuf_unmap(xc_interface *xch, uint8_t *buf, uint64_t size); + +/** + * Get current offset inside the trace ringbuffer. + * This allows to determine how much data was written into the buffer. + * Once buffer overflows, the offset will reset to 0 and the previous + * data will be overriden. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @parm offset current offset inside trace buffer will be written there + * @return 0 on success, -1 on failure + */ +int xc_ptbuf_get_offset(xc_interface *xch, uint32_t domid, uint32_t vcpu, uint64_t *offset); + int xc_domctl(xc_interface *xch, struct xen_domctl *domctl); int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl); diff --git a/tools/libxc/xc_tbuf.c b/tools/libxc/xc_tbuf.c index 283fbd1c8f..8fab7f7d79 100644 --- a/tools/libxc/xc_tbuf.c +++ b/tools/libxc/xc_tbuf.c @@ -79,6 +79,114 @@ int xc_tbuf_get_size(xc_interface *xch, unsigned long *size) return rc; } +int xc_ptbuf_enable(xc_interface *xch, uint32_t domid, uint32_t vcpu, uint64_t size) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->version = HVMOP_VMTRACE_INTERFACE_VERSION; + arg->cmd = HVMOP_vmtrace_ipt_enable; + arg->domain = domid; + arg->vcpu = vcpu; + arg->size = size; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + +int xc_ptbuf_get_offset(xc_interface *xch, uint32_t domid, uint32_t vcpu, uint64_t *offset) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->version = HVMOP_VMTRACE_INTERFACE_VERSION; + arg->cmd = HVMOP_vmtrace_ipt_get_offset; + arg->domain = domid; + arg->vcpu = vcpu; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + if ( rc == 0 ) + { + *offset = arg->offset; + } + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + +int xc_ptbuf_map(xc_interface *xch, uint32_t domid, uint32_t vcpu, uint8_t **buf, uint64_t *size) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + uint8_t *mapped_buf; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->version = HVMOP_VMTRACE_INTERFACE_VERSION; + arg->cmd = HVMOP_vmtrace_ipt_get_buf; + arg->domain = domid; + arg->vcpu = vcpu; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + if ( rc == 0 ) + { + mapped_buf = (uint8_t *)xc_map_foreign_range(xch, DOMID_XEN, arg->size, PROT_READ, arg->mfn); + + if ( mapped_buf == NULL ) + return -1; + + *buf = mapped_buf; + *size = arg->size; + } + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + +int xc_ptbuf_unmap(xc_interface *xch, uint8_t *buf, uint64_t size) +{ + xenforeignmemory_unmap(xch->fmem, buf, size >> PAGE_SHIFT); + return 0; +} + +int xc_ptbuf_disable(xc_interface *xch, uint32_t domid, uint32_t vcpu) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->version = HVMOP_VMTRACE_INTERFACE_VERSION; + arg->cmd = HVMOP_vmtrace_ipt_disable; + arg->domain = domid; + arg->vcpu = vcpu; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + int xc_tbuf_enable(xc_interface *xch, unsigned long pages, unsigned long *mfn, unsigned long *size) { -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:24:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:24:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDRa-0001Dd-R5; Tue, 16 Jun 2020 15:24:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDRZ-0001DP-FJ for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:24:09 +0000 X-Inumbo-ID: 6afacb5c-afe5-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6afacb5c-afe5-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 15:24:07 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 53641A1C0D; Tue, 16 Jun 2020 17:24:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 4F018A1D6C; Tue, 16 Jun 2020 17:24:05 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZEWxmQDo3L5P; Tue, 16 Jun 2020 17:24:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7117CA1EBE; Tue, 16 Jun 2020 17:24:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1Hw-ld9mw2Ky; Tue, 16 Jun 2020 17:24:03 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 464ACA1D6C; Tue, 16 Jun 2020 17:24:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 38EF122508; Tue, 16 Jun 2020 17:23:33 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id waTJYGZyvxbO; Tue, 16 Jun 2020 17:23:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 87E7B21867; Tue, 16 Jun 2020 17:23:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WqgOkT8yPmFG; Tue, 16 Jun 2020 17:23:26 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 61CB4214C8; Tue, 16 Jun 2020 17:23:26 +0200 (CEST) Date: Tue, 16 Jun 2020 17:23:26 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <1776308629.8766364.1592321006363.JavaMail.zimbra@cert.pl> In-Reply-To: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Subject: [PATCH v1 6/7] tools/proctrace: add proctrace tool MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: tools/proctrace: add proctrace tool Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9htw1Ldxj X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add an demonstration tool that uses xc_ptbuf_* calls in order to manage external IPT monitoring for DomU. Signed-off-by: Michal Leszczynski --- tools/proctrace/COPYING | 339 ++++++++++++++++++++++++++++++++++++ tools/proctrace/Makefile | 49 ++++++ tools/proctrace/proctrace.c | 139 +++++++++++++++ 3 files changed, 527 insertions(+) create mode 100644 tools/proctrace/COPYING create mode 100644 tools/proctrace/Makefile create mode 100644 tools/proctrace/proctrace.c diff --git a/tools/proctrace/COPYING b/tools/proctrace/COPYING new file mode 100644 index 0000000000..c0a841112c --- /dev/null +++ b/tools/proctrace/COPYING @@ -0,0 +1,339 @@ +=09=09 GNU GENERAL PUBLIC LICENSE +=09=09 Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +=09=09=09 Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + +=09=09 GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; o= r, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Softwa= re +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + +=09=09=09 NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITIN= G +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISIN= G +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + +=09=09 END OF TERMS AND CONDITIONS + +=09 How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms= . + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; If not, see . + + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show = w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriat= e +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + , 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program int= o +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with th= e +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. diff --git a/tools/proctrace/Makefile b/tools/proctrace/Makefile new file mode 100644 index 0000000000..d9231dfa24 --- /dev/null +++ b/tools/proctrace/Makefile @@ -0,0 +1,49 @@ +# Copyright (C) CERT Polska - NASK PIB +# Author: Micha=C5=82 Leszczy=C5=84ski +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; under version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +XEN_ROOT=3D$(CURDIR)/../.. +include $(XEN_ROOT)/tools/Rules.mk + +CFLAGS +=3D -Werror +CFLAGS +=3D $(CFLAGS_libxenevtchn) +CFLAGS +=3D $(CFLAGS_libxenctrl) +LDLIBS +=3D $(LDLIBS_libxenctrl) +LDLIBS +=3D $(LDLIBS_libxenevtchn) + +# SCRIPTS =3D xenmon.py + +.PHONY: all +all: build + +.PHONY: build +build: proctrace + +.PHONY: install +install: build +=09$(INSTALL_DIR) $(DESTDIR)$(sbindir) +=09$(INSTALL_PROG) proctrace $(DESTDIR)$(sbindir)/proctrace + +.PHONY: uninstall +uninstall: +=09rm -f $(DESTDIR)$(sbindir)/proctrace + +.PHONY: clean +clean: +=09$(RM) -f $(DEPS_RM) + +.PHONY: distclean +distclean: clean + +iptlive: iptlive.o Makefile +=09$(CC) $(LDFLAGS) $< -o $@ $(LDLIBS) $(APPEND_LDFLAGS) + +-include $(DEPS_INCLUDE) diff --git a/tools/proctrace/proctrace.c b/tools/proctrace/proctrace.c new file mode 100644 index 0000000000..74409428b4 --- /dev/null +++ b/tools/proctrace/proctrace.c @@ -0,0 +1,139 @@ +/*************************************************************************= ***** + * tools/proctrace.c + * + * Demonstrative tool for collecting Intel Processor Trace data from Xen. + * Could be used to externally monitor a given vCPU in given DomU. + * + * Copyright (C) 2020 by CERT Polska - NASK PIB + * + * Authors: Micha=C5=82 Leszczy=C5=84ski, michal.leszczynski@cert.pl + * Date: June, 2020 + *=20 + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; under version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; If not, see . + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +volatile int interrupted =3D 0; + +void term_handler(int signum) { + interrupted =3D 1; +} + +int main(int argc, char* argv[]) { + xc_interface *xc; + uint32_t domid; + uint32_t vcpu_id; + + int rc =3D -1; + uint8_t *buf; + uint64_t size; + uint64_t last_offset =3D 0; + + signal(SIGINT, term_handler); + + if (argc !=3D 3) { + fprintf(stderr, "Usage: %s \n", argv[0]); + fprintf(stderr, "It's recommended to redirect this program's outpu= t to file\n"); + fprintf(stderr, "or to pipe it's output to xxd or other program.\n= "); + return 1; + } + + domid =3D atoi(argv[1]); + vcpu_id =3D atoi(argv[2]); + + xc =3D xc_interface_open(0, 0, 0); + + if (!xc) { + fprintf(stderr, "Failed to open xc interface\n"); + return 1; + } + + rc =3D xc_ptbuf_enable(xc, domid, vcpu_id, 64 * 1024 * 1024); + + if (rc) { + fprintf(stderr, "Failed to call xc_ptbuf_enable\n"); + return 1; + } + + rc =3D xc_ptbuf_map(xc, domid, vcpu_id, &buf, &size); + + if (rc) { + fprintf(stderr, "Failed to call xc_ptbuf_map\n"); + return 1; + } + + while (!interrupted) { + uint64_t offset; + rc =3D xc_ptbuf_get_offset(xc, domid, vcpu_id, &offset); + + if (rc) { + fprintf(stderr, "Failed to call xc_ptbuf_get_offset\n"); + return 1; + } + + if (offset > last_offset) + { + fwrite(buf + last_offset, offset - last_offset, 1, stdout); + } + else + { + // buffer wrapped + fwrite(buf + last_offset, size - last_offset, 1, stdout); + fwrite(buf, offset, 1, stdout); + } + + last_offset =3D offset; + usleep(1000 * 100); + } + + rc =3D xc_ptbuf_unmap(xc, buf, size); + + if (rc) { + fprintf(stderr, "Failed to call xc_ptbuf_unmap\n"); + return 1; + } + + rc =3D xc_ptbuf_disable(xc, domid, vcpu_id); + + if (rc) { + fprintf(stderr, "Failed to call xc_ptbuf_disable\n"); + return 1; + } + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ --=20 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:24:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:24:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDSF-0001K8-8X; Tue, 16 Jun 2020 15:24:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDSE-0001K0-1N for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:24:50 +0000 X-Inumbo-ID: 842c0636-afe5-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 842c0636-afe5-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 15:24:49 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 8CF4AA2DE1; Tue, 16 Jun 2020 17:24:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 831C7A26F4; Tue, 16 Jun 2020 17:24:47 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id NOX4nYjrIjRB; Tue, 16 Jun 2020 17:24:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 19F97A2DE1; Tue, 16 Jun 2020 17:24:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VBXLA65P1sUY; Tue, 16 Jun 2020 17:24:46 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id E4797A26F4; Tue, 16 Jun 2020 17:24:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D4F2C214C8; Tue, 16 Jun 2020 17:24:16 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BU1h424fcYsI; Tue, 16 Jun 2020 17:24:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 75AC0215F4; Tue, 16 Jun 2020 17:24:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HFXNXOMpVXKA; Tue, 16 Jun 2020 17:24:11 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 594CB214C8; Tue, 16 Jun 2020 17:24:11 +0200 (CEST) Date: Tue, 16 Jun 2020 17:24:11 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> In-Reply-To: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Subject: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: switch IPT MSRs on vmentry/vmexit Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hiacNb1l X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Enable IPT when entering the VM and disable it on vmexit. Register state is persisted using vCPU ipt_state structure. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/vmx/vmx.c | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 97104c319e..01d9a7b584 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -3698,6 +3698,15 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) __vmread(GUEST_RSP, ®s->rsp); __vmread(GUEST_RFLAGS, ®s->rflags); + if ( unlikely(v->arch.hvm.vmx.ipt_state) ) + { + wrmsrl(MSR_IA32_RTIT_CTL, 0); + smp_rmb(); + + rdmsrl(MSR_IA32_RTIT_STATUS, v->arch.hvm.vmx.ipt_state->status); + rdmsrl(MSR_IA32_RTIT_OUTPUT_MASK, v->arch.hvm.vmx.ipt_state->output_mask); + } + hvm_invalidate_regs_fields(regs); if ( paging_mode_hap(v->domain) ) @@ -4497,6 +4506,23 @@ bool vmx_vmenter_helper(const struct cpu_user_regs *regs) } out: + if ( unlikely(curr->arch.hvm.vmx.ipt_state) ) + { + wrmsrl(MSR_IA32_RTIT_CTL, 0); + + if (curr->arch.hvm.vmx.ipt_state->ctl) + { + wrmsrl(MSR_IA32_RTIT_OUTPUT_BASE, curr->arch.hvm.vmx.ipt_state->output_base); + wrmsrl(MSR_IA32_RTIT_OUTPUT_MASK, curr->arch.hvm.vmx.ipt_state->output_mask); + wrmsrl(MSR_IA32_RTIT_STATUS, curr->arch.hvm.vmx.ipt_state->status); + + // MSR_IA32_RTIT_CTL is context-switched manually instead of being + // stored inside VMCS, as of Q2'20 only the most recent processors + // support such field in VMCS + wrmsrl(MSR_IA32_RTIT_CTL, curr->arch.hvm.vmx.ipt_state->ctl); + } + } + if ( unlikely(curr->arch.hvm.vmx.lbr_flags & LBR_FIXUP_MASK) ) lbr_fixup(); -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:25:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:25:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDSo-0001Pn-HS; Tue, 16 Jun 2020 15:25:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDSn-0001PT-Hr for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:25:25 +0000 X-Inumbo-ID: 9942cdf2-afe5-11ea-8496-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9942cdf2-afe5-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 15:25:24 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 4YeycwbLnR0Q+5ReITbnQGl3JzNlBbWvLCbC/GwLfj7fKXix6wIYIHJLjHr/sYe2Qit9DVvX4E /EY1zSLBHxYBeVAiceDHz3YTvIIsCd5sJ9jJH0XJ07wBKbRynwu56eQYuTpsF4gb7D+t5d1AlO 0oBoOLHFe79S94cQKaY6m48nke/OpqbNIOeLuboZX5Amokw0DhUSLREgBKoffKlJmLtf5LuWNe SCv+w+IgE7d+Dm1hEalo/NzjVZWnQ7ll5xQDVjZhlkSCPmC8a/hmlU/8hpyNd4AHWpvF1bgXSI TeQ= X-SBRS: 2.7 X-MesageID: 20178617 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20178617" Date: Tue, 16 Jun 2020 17:25:15 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Message-ID: <20200616152515.GQ735@Air-de-Roger> References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> <20200616145951.GP735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 05:11:58PM +0200, Jan Beulich wrote: > On 16.06.2020 16:59, Roger Pau Monné wrote: > > On Tue, Jun 16, 2020 at 03:25:42PM +0200, Jan Beulich wrote: > >> --- unstable.orig/xen/arch/x86/acpi/boot.c > >> +++ unstable/xen/arch/x86/acpi/boot.c > >> @@ -480,7 +480,9 @@ static int __init acpi_parse_fadt(struct > >> if (fadt->header.revision >= FADT2_REVISION_ID) { > >> /* FADT rev. 2 */ > >> if (fadt->xpm_timer_block.space_id == > >> - ACPI_ADR_SPACE_SYSTEM_IO) { > >> + ACPI_ADR_SPACE_SYSTEM_IO && > >> + (fadt->xpm_timer_block.access_width == 0 || > >> + fadt->xpm_timer_block.access_width == 3)) { > > > > We should really have defines for those values, or else they seem to > > imply actual access sizes. What about adding > > ACPI_ADDR_ACCESS_{LEGACY,BYTE,WORD,DWORD,QWORD}? > > If there were such defines, I'd have used them. Adding them is > inappropriate though, as this would modify an imported header in a > Xen-specific way. We could leverage ACPI_ACCESS_BIT_WIDTH() here, > though. Yes, that would be better IMO. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 15:58:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 15:58:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDyU-00048U-2x; Tue, 16 Jun 2020 15:58:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlDyS-00048O-2y for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 15:58:08 +0000 X-Inumbo-ID: 2a83dac8-afea-11ea-8496-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2a83dac8-afea-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 15:58:06 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 9RTjJn1cu1zbGK1/wMEoAbg1cEEXppsSBe2Wu3i7UhI/yIW3aNhaqLAqTEaCYY/tQ/bTOy0xFC dOkiq4jbO59DYhDhnYZQF0JL2Sg6HJsPFMnrD0S2S3eQZHRW9mdL9xTfK90UOtJRqvjDCwR0M5 2QE0uMI4ZeLTQ0feSNAr+zcBU4xQi0LRw2sn9OsaUGjnAzEe17eGYIc+MP4eL2I7cRtl4XPrK1 8m6TFmc8tVwky8F9FVZs2NtPk97izsUgJnuJaZOo33dhczjXaHSA7f/Q3q8irRAq/iBsFeq7f3 jtw= X-SBRS: 2.7 X-MesageID: 20528443 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20528443" Subject: Re: [PATCH 3/9] tools/libx[cl]: Move processing loop down into xc_cpuid_set() To: Jan Beulich References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-4-andrew.cooper3@citrix.com> <7ac49edf-1a8c-435d-0b5b-96496432e9f6@suse.com> From: Andrew Cooper Message-ID: Date: Tue, 16 Jun 2020 16:58:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <7ac49edf-1a8c-435d-0b5b-96496432e9f6@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 10:16, Jan Beulich wrote: > On 15.06.2020 16:15, Andrew Cooper wrote: >> Currently, libxl__cpuid_legacy() passes each element of the policy list to >> xc_cpuid_set() individually. This is wasteful both in terms of the number of >> hypercalls made, and the quantity of repeated merging/auditing work performed >> by Xen. >> >> Move the loop processing down into xc_cpuid_set(), which allows us to do one >> set of hypercalls, rather than one per list entry. >> >> In xc_cpuid_set(), obtain the full host, guest max and current policies to >> begin with, and loop over the xend array, processing one leaf at a time. >> Replace the linear search with a binary search, seeing as the serialised >> leaves are sorted. >> >> No change in behaviour from the guests point of view. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich > with a few remarks: > >> @@ -286,99 +311,101 @@ int xc_cpuid_set( >> } >> >> rc = -ENOMEM; >> - if ( (leaves = calloc(nr_leaves, sizeof(*leaves))) == NULL ) >> + if ( (host = calloc(nr_leaves, sizeof(*host))) == NULL || >> + (max = calloc(nr_leaves, sizeof(*max))) == NULL || >> + (cur = calloc(nr_leaves, sizeof(*cur))) == NULL ) >> { >> ERROR("Unable to allocate memory for %u CPUID leaves", nr_leaves); >> goto fail; >> } >> >> + /* Get the domain's current policy. */ >> + nr_msrs = 0; >> + nr_cur = nr_leaves; >> + rc = xc_get_domain_cpu_policy(xch, domid, &nr_cur, cur, &nr_msrs, NULL); >> + if ( rc ) >> + { >> + PERROR("Failed to obtain d%d current policy", domid); >> + rc = -errno; >> + goto fail; >> + } >> + >> /* Get the domain's max policy. */ >> nr_msrs = 0; >> - policy_leaves = nr_leaves; >> + nr_max = nr_leaves; >> rc = xc_get_system_cpu_policy(xch, di.hvm ? XEN_SYSCTL_cpu_policy_hvm_max >> : XEN_SYSCTL_cpu_policy_pv_max, >> - &policy_leaves, leaves, &nr_msrs, NULL); >> + &nr_max, max, &nr_msrs, NULL); >> if ( rc ) >> { >> PERROR("Failed to obtain %s max policy", di.hvm ? "hvm" : "pv"); >> rc = -errno; >> goto fail; >> } >> - for ( i = 0; i < policy_leaves; ++i ) >> - if ( leaves[i].leaf == xend->leaf && >> - leaves[i].subleaf == xend->subleaf ) >> - { >> - polregs[0] = leaves[i].a; >> - polregs[1] = leaves[i].b; >> - polregs[2] = leaves[i].c; >> - polregs[3] = leaves[i].d; >> - break; >> - } >> >> /* Get the host policy. */ >> nr_msrs = 0; >> - policy_leaves = nr_leaves; >> + nr_host = nr_leaves; >> rc = xc_get_system_cpu_policy(xch, XEN_SYSCTL_cpu_policy_host, >> - &policy_leaves, leaves, &nr_msrs, NULL); >> + &nr_host, host, &nr_msrs, NULL); >> if ( rc ) >> { >> PERROR("Failed to obtain host policy"); >> rc = -errno; >> goto fail; >> } >> - for ( i = 0; i < policy_leaves; ++i ) >> - if ( leaves[i].leaf == xend->leaf && >> - leaves[i].subleaf == xend->subleaf ) >> - { >> - regs[0] = leaves[i].a; >> - regs[1] = leaves[i].b; >> - regs[2] = leaves[i].c; >> - regs[3] = leaves[i].d; >> - break; >> - } >> >> - for ( i = 0; i < 4; i++ ) >> + rc = -EINVAL; >> + for ( ; xend->leaf != XEN_CPUID_INPUT_UNUSED; ++xend ) >> { >> - if ( xend->policy[i] == NULL ) >> + xen_cpuid_leaf_t *cur_leaf = find_leaf(cur, nr_cur, xend); >> + const xen_cpuid_leaf_t *max_leaf = find_leaf(max, nr_max, xend); >> + const xen_cpuid_leaf_t *host_leaf = find_leaf(host, nr_host, xend); >> + >> + if ( cur_leaf == NULL || max_leaf == NULL || host_leaf == NULL ) >> { >> - regs[i] = polregs[i]; >> - continue; >> + ERROR("Missing leaf %#x, subleaf %#x", xend->leaf, xend->subleaf); >> + goto fail; >> } >> >> - /* >> - * Notes for following this algorithm: >> - * >> - * While it will accept any leaf data, it only makes sense to use on >> - * feature leaves. regs[] initially contains the host values. This, >> - * with the fall-through chain, is how the 's' and 'k' options work. >> - */ >> - for ( j = 0; j < 32; j++ ) >> + for ( int i = 0; i < 4; i++ ) > As you move the declaration here, perhaps switch to unsigned int > as well? And express 4 as ARRAY_SIZE()? > >> { >> - unsigned char val = !!((regs[i] & (1U << (31 - j)))); >> - unsigned char polval = !!((polregs[i] & (1U << (31 - j)))); >> - >> - rc = -EINVAL; >> - if ( !strchr("10xks", xend->policy[i][j]) ) >> - goto fail; >> - >> - if ( xend->policy[i][j] == '1' ) >> - val = 1; >> - else if ( xend->policy[i][j] == '0' ) >> - val = 0; >> - else if ( xend->policy[i][j] == 'x' ) >> - val = polval; >> - >> - if ( val ) >> - set_feature(31 - j, regs[i]); >> - else >> - clear_feature(31 - j, regs[i]); >> + uint32_t *cur_reg = &cur_leaf->a + i; >> + const uint32_t *max_reg = &max_leaf->a + i; >> + const uint32_t *host_reg = &host_leaf->a + i; >> + >> + if ( xend->policy[i] == NULL ) >> + continue; >> + >> + for ( int j = 0; j < 32; j++ ) > unsigned int again? I don't think there's a suitable array available > to also use ARRAY_SIZE() here. All fixed. > >> + { >> + bool val; >> + >> + if ( xend->policy[i][j] == '1' ) >> + val = true; >> + else if ( xend->policy[i][j] == '0' ) >> + val = false; >> + else if ( xend->policy[i][j] == 'x' ) >> + val = test_bit(31 - j, max_reg); > Still seeing "max" used here is somewhat confusing given the purpose > of the series, and merely judging from the titles I can't yet spot > where later on it'll change. But I assume it will ... No - it won't change.  The legacy xend adjustments have always been based on the max featureset, and changing it will break VM migration. The soon-to-exist (4.15 at this point) brand new "what do I do for a fresh boot" path will do things differently even for the legacy Xend leaves, but the logic here must not semantically change. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 16 16:09:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 16:09:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlE9e-0005bZ-7c; Tue, 16 Jun 2020 16:09:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlE9c-0005bU-FZ for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 16:09:40 +0000 X-Inumbo-ID: c82443b6-afeb-11ea-bca7-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id c82443b6-afeb-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 16:09:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592323779; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0rqSFzZq3qFEqQpqMeOjnJbYfs9zNhM4NpNV+yeVM3M=; b=IzEa8fj8ZYqtM9P/g0LhSXYabvtGW5eTvnnSRYSSq3trfE/FZFNm7J7TVJ2alhnhgVFoyY DZyhTZn+EzsRE5tijp/xDKweKvBWPKwTi4JkW1vY1POjdU80AgFpU0Nfo10qLe0zPsEQy3 XHfYbXiJp7w/o0EVjFI/LgUlgiP1if0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-355-BZsOtuhpNI-w7lHrfoBlbQ-1; Tue, 16 Jun 2020 12:09:36 -0400 X-MC-Unique: BZsOtuhpNI-w7lHrfoBlbQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 281FE10059C0; Tue, 16 Jun 2020 16:09:34 +0000 (UTC) Received: from linux.fritz.box (ovpn-114-66.ams2.redhat.com [10.36.114.66]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C44325D9D7; Tue, 16 Jun 2020 16:09:21 +0000 (UTC) Date: Tue, 16 Jun 2020 18:09:20 +0200 From: Kevin Wolf To: Roman Kagan Subject: Re: [PATCH v8 0/8] block: enhance handling of size-related BlockConf properties Message-ID: <20200616160920.GG4305@linux.fritz.box> References: <20200528225516.1676602-1-rvkagan@yandex-team.ru> MIME-Version: 1.0 In-Reply-To: <20200528225516.1676602-1-rvkagan@yandex-team.ru> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Fam Zheng , Stefano Stabellini , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Eduardo Habkost , qemu-block@nongnu.org, Paul Durrant , John Snow , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Eric Blake , Max Reitz , Keith Busch , Gerd Hoffmann , Stefan Hajnoczi , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , Laurent Vivier Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Am 29.05.2020 um 00:55 hat Roman Kagan geschrieben: > BlockConf includes several properties counted in bytes. > > Enhance their handling in some aspects, specifically > > - accept common size suffixes (k, m) > - perform consistency checks on the values > - lift the upper limit on physical_block_size and logical_block_size > > Also fix the accessor for opt_io_size in virtio-blk to make it consistent with > the size of the field. Thanks, applied to the block branch. Kevin From xen-devel-bounces@lists.xenproject.org Tue Jun 16 16:15:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 16:15:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEF2-0006P2-Ss; Tue, 16 Jun 2020 16:15:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEF2-0006Ox-2y for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 16:15:16 +0000 X-Inumbo-ID: 8f996296-afec-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8f996296-afec-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 16:15:14 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: BithpZqCZRPYeDFMq8W9xUUBDG4l+01TqkK+wGNFSATYeCOsSHC4m6F7qBmQ+sCPBsXSgqxHu4 tHcp1EC1yQNxZqb65GZwoRh1s5WFvGldNDrCubxfAHnfjvpSkaGNB0z+Bwz0Px9uExT0gJH0Il 8Sv6ZzOW+bNMUrNK0du/fsewPvKX2HWRbDCiQQGzhNbALL07lysWwXf0MANAHbgH0ZVoqrNu2I nt2QpXBMN9H5etyfxdl/uazsMzHL90X+vUTaz7eQTGQjiyVd9NSgCFRuav5pq1Znjn/tR1+xNb 97o= X-SBRS: 2.7 X-MesageID: 20530975 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20530975" Subject: Re: [PATCH 7/9] x86/hvm: Disable MPX by default To: Jan Beulich References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-8-andrew.cooper3@citrix.com> <58d7254d-8953-93c4-9eb2-9be45f39bc4e@suse.com> From: Andrew Cooper Message-ID: Date: Tue, 16 Jun 2020 17:15:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <58d7254d-8953-93c4-9eb2-9be45f39bc4e@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 10:33, Jan Beulich wrote: > On 15.06.2020 16:15, Andrew Cooper wrote: >> @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, >> goto out; >> } >> >> + /* >> + * Account for feature which have been disabled by default since Xen 4.13, >> + * so migrated-in VM's don't risk seeing features disappearing. >> + */ >> + if ( restore ) >> + { >> + if ( di.hvm ) >> + { >> + p->feat.mpx = test_bit(X86_FEATURE_MPX, host_featureset); > Why do you derive this from the host featureset instead of the max > one for the guest type? Because that is how the logic worked for 4.13. Also, because we don't have easy access to the actual guest max featureset at this point.  I could add two new sysctl subops to get_featureset, but the reason for not doing so before are still applicable now. There is a theoretical case where host MPX is visible but guest max is hidden, and that is down to the vmentry controls.  As this doesn't exist in real hardware, I'm not terribly concerned about it. > Also, while you modify p here, ... > >> + } >> + } >> + >> if ( featureset ) >> { >> uint32_t disabled_features[FEATURESET_NR_ENTRIES], > ... the code in this if()'s body ignores p altogether. That is correct. > I realize the > only caller of the function passes NULL for "featureset", but I'd > like to understand the rationale here anyway before giving an R-b. The meaning of 'featureset' is "here are the exact bits I want you to use". It has existed since my original CPUID work in 4.6/4.7.  Currently, the only user in XenServer, and its a stopgap on the way to the "proper" solution which I've been working on for the past several years. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 16 16:18:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 16:18:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEHg-0006YO-B7; Tue, 16 Jun 2020 16:18:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEHe-0006YJ-Tj for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 16:17:58 +0000 X-Inumbo-ID: f0855772-afec-11ea-b906-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f0855772-afec-11ea-b906-12813bfff9fa; Tue, 16 Jun 2020 16:17:57 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: G+8b9eVKa0+ND22uA0LhmNWg6NgTW1xLPm6OpByyc3zUGAm30oTMCa0JaB1aiogHOLgy7hpo53 N6BndKAN6LXlGOxvbvnHYEWqvQlRRfeiLHvAshGYDjJM3J8MpqAN+i6TsD8tFfnADOLNjbmhK6 sWzux4wMv4RhILO8YSD2/KDo152KnOymhPN3bdFt0FlmRIfiWtunmNnfCfVfVLnZC31XAUOa3R kFbNp27VaPBwPZLJLu2rJRgLPbDzVipGD7gDaEZlSjX8EL2Bzhb+mwd/enGhoQAMxk3brAvJOW 9wk= X-SBRS: 2.7 X-MesageID: 20199082 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20199082" Subject: Re: [PATCH 8/9] x86/cpuid: Introduce missing feature adjustment in calculate_pv_def_policy() To: Jan Beulich References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-9-andrew.cooper3@citrix.com> <9e27fb33-91d3-1a20-c956-24a0e0f28764@suse.com> From: Andrew Cooper Message-ID: Date: Tue, 16 Jun 2020 17:17:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <9e27fb33-91d3-1a20-c956-24a0e0f28764@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 10:40, Jan Beulich wrote: > On 15.06.2020 16:15, Andrew Cooper wrote: >> This was an accidental asymmetry with the HVM side. >> >> No change in behaviour at this point. >> >> Fixes: 83b387382 ("x86/cpuid: Introduce and use default CPUID policies") >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Thanks. > with a remark: > >> --- a/xen/arch/x86/cpuid.c >> +++ b/xen/arch/x86/cpuid.c >> @@ -402,6 +402,8 @@ static void __init calculate_pv_def_policy(void) >> for ( i = 0; i < ARRAY_SIZE(pv_featureset); ++i ) >> pv_featureset[i] &= pv_def_featuremask[i]; >> >> + guest_common_feature_adjustments(pv_featureset); >> + >> sanitise_featureset(pv_featureset); >> cpuid_featureset_to_policy(pv_featureset, p); >> recalculate_xstate(p); > These four calls are common to all three callers of the function. > Perhaps them going out of sync would be less likely if all four > called the same helper to carry out these four steps? I'm not sure how many of them are going to survive the transformation to a fully libx86 based world. I expect it not to look exactly like this. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 16 16:27:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 16:27:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEQK-0007Sd-Bu; Tue, 16 Jun 2020 16:26:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEQI-0007SY-Ez for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 16:26:54 +0000 X-Inumbo-ID: 3019b562-afee-11ea-b7bb-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3019b562-afee-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 16:26:53 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: jFRHlA2SqXJTd1GAldKrz5PtrKSPhCaMf1yu+89Kqb4P3k9+/P/brE/QqcIkSM8CrHdOh5Ov3r lM8K4lC/Xy+E5AMPxQTsvIRS1z9Ah7EQ54yB3OIt2NUjtT5zNEG3tSDPTX3FlVppWOvVF1d3t7 ZQbHMSCrMzMVqTS65oJBO5Wx/3ZS2V+EkPQMOYyrQI2Vs9PL4isneHm9C5O0RwmulotXSHpEVL tRV62YjPbB98ys6BC80m2n8gN9Wti+M+WvFVAiNzixAmFZ6L1Ej4Bm1oA0QAq43+/E0UqwGLU9 G8k= X-SBRS: 2.7 X-MesageID: 20965500 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20965500" Subject: Re: [PATCH 9/9] x86/spec-ctrl: Hide RDRAND by default on IvyBridge To: Jan Beulich References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-10-andrew.cooper3@citrix.com> From: Andrew Cooper Message-ID: <00db98fd-d268-71ae-fad1-fb59d2f1eba1@citrix.com> Date: Tue, 16 Jun 2020 17:26:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 11:00, Jan Beulich wrote: > On 15.06.2020 16:15, Andrew Cooper wrote: >> --- a/docs/misc/xen-command-line.pandoc >> +++ b/docs/misc/xen-command-line.pandoc >> @@ -512,11 +512,21 @@ The Speculation Control hardware features `srbds-ctrl`, `md-clear`, `ibrsb`, >> `stibp`, `ibpb`, `l1d-flush` and `ssbd` are used by default if available and >> applicable. They can all be ignored. >> >> -`rdrand` and `rdseed` can be ignored, as a mitigation to XSA-320 / >> -CVE-2020-0543. The RDRAND feature is disabled by default on certain AMD >> -systems, due to possible malfunctions after ACPI S3 suspend/resume. `rdrand` >> -may be used in its positive form to override Xen's default behaviour on these >> -systems, and make the feature fully usable. >> +`rdrand` and `rdseed` have multiple interactions. >> + >> +* For Special Register Buffer Data Sampling (SRBDS, XSA-320, CVE-2020-0543), >> + RDRAND and RDSEED can be ignored. >> + >> + Due to the absence microcode to address SRBDS on IvyBridge hardware, the > Nit: "... absence of microcode ..." Fixed. > >> + RDRAND feature is hidden by default for guests, unless `rdrand` is used in >> + its positive form. Irrespective of the default setting here, VMs can use >> + RDRAND if explicitly enabled in guest config file, and VMs already using >> + RDRAND can migrate in. > I'm somewhat confused by the use of "default setting" here, when at the same > time you talk about our default behavior for guests. Aiui the two "default" > mean different things, so I'd suggest dropping that latter "default". Ok, done. > > This raises a question though: Is disabling RDRAND just for guests good > enough? I.e. what about Xen's own uses of RDRAND? There may not be any > problematic ones right now, but wouldn't there be a latent issue no-one is > going to notice? I was sorely tempted to delete all of Xen's use of RDRAND, seeing as its not even safe to the AMD issue. What we don't have is a "no-xen" concept for CPUID features, so I can't stop Xen using it without hiding it from all guests, which in turn would render the point of this series useless, and reintroduce the migration problems we're trying to code around. I was planning to leave the Xen uses as-are for now. > >> --- a/tools/libxc/xc_cpuid_x86.c >> +++ b/tools/libxc/xc_cpuid_x86.c >> @@ -503,6 +503,9 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, >> */ >> if ( restore ) >> { >> + if ( test_bit(X86_FEATURE_RDRAND, host_featureset) && !p->basic.rdrand ) >> + p->basic.rdrand = true; > Same question as before: Why do you derive from the host feature set rather > than the domain type's maximum one? Answer the same as previous. Although I do see now that this should be simplified to:     p->basic.rdrand = test_bit(X86_FEATURE_RDRAND, host_featureset); which I've done. > >> --- a/xen/arch/x86/cpuid.c >> +++ b/xen/arch/x86/cpuid.c >> @@ -340,6 +340,25 @@ static void __init calculate_host_policy(void) >> } >> } >> >> +static void __init guest_common_default_feature_adjustments(uint32_t *fs) >> +{ >> + /* >> + * IvyBridge client parts suffer from leakage of RDRAND data due to SRBDS >> + * (XSA-320 / CVE-2020-0543), and won't be receiving microcode to >> + * compensate. >> + * >> + * Mitigate by hiding RDRAND from guests by default, unless explicitly >> + * overridden on the Xen command line (cpuid=rdrand). Irrespective of the >> + * default setting, guests can use RDRAND if explicitly enabled >> + * (cpuid="host,rdrand=1") in the VM's config file, and VMs which were >> + * previously using RDRAND can migrate in. >> + */ >> + if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && >> + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x3a && > This is the first time (description plus patch so far) that the issue > gets mentioned to be for and the workaround restricted to client parts > only. If so, I think at least the doc should say so too. I've updated the command line doc, and patch subject. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 16 16:30:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 16:30:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlETo-0008Fb-SV; Tue, 16 Jun 2020 16:30:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlETo-0008FW-15 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 16:30:32 +0000 X-Inumbo-ID: b1f969a6-afee-11ea-b909-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b1f969a6-afee-11ea-b909-12813bfff9fa; Tue, 16 Jun 2020 16:30:31 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 8WCRVleYSWyRcKCY1Lu4bEIR4oys2xkvQNC+CyZxHm5KCU2azZfZBJQ/a5LazukssAOrrKsLm9 ELBe3um5vMK4lYK7G1GkWJvV4HR57RxDV07Q6zYoWriynFeaNpEsgQaTFDul+YnusMz42H/zfG 8gDc9ebGhepyu+kwS7VpIbTxS/VDdNJ+5GRiqWkw19uZT+hzWVanwu58cy4sxauF+2QORLeYV2 LeJ+0xn2CjaDytv+wnwVtu5E+4Xz6BqV94HWO8+tBvbvt3ySlqBHLTQNon/gG61xViKapM/P54 2T4= X-SBRS: 2.7 X-MesageID: 20418132 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20418132" Date: Tue, 16 Jun 2020 18:30:22 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 2/7] x86/vmx: add IPT cpu feature Message-ID: <20200616163022.GR735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1672321493.8765712.1592320839082.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1672321493.8765712.1592320839082.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 05:20:39PM +0200, Michał Leszczyński wrote: > Check if Intel Processor Trace feature is supported by current > processor. Define hvm_ipt_supported function. > > Signed-off-by: Michal Leszczynski > --- > xen/arch/x86/hvm/vmx/vmx.c | 24 +++++++++++++++++++++ > xen/include/asm-x86/cpufeature.h | 1 + > xen/include/asm-x86/hvm/hvm.h | 9 ++++++++ > xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + > xen/include/public/arch-x86/cpufeatureset.h | 1 + > 5 files changed, 36 insertions(+) > > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index ab19d9424e..a91bbdb798 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -2484,6 +2484,7 @@ static bool __init has_if_pschange_mc(void) > > const struct hvm_function_table * __init start_vmx(void) > { > + u64 _vmx_misc_cap; Please use uint64_t, and you can drop the leading _vmx prefix, this is already vmx specific. Also add a newline between variable definition and code. > set_in_cr4(X86_CR4_VMXE); > > if ( vmx_vmcs_init() ) > @@ -2557,6 +2558,29 @@ const struct hvm_function_table * __init start_vmx(void) > vmx_function_table.get_guest_bndcfgs = vmx_get_guest_bndcfgs; > } > > + /* Check whether IPT is supported in VMX operation */ > + vmx_function_table.ipt_supported = 1; > + > + if ( !cpu_has_ipt ) > + { > + vmx_function_table.ipt_supported = 0; > + printk("VMX: Missing support for Intel Processor Trace x86 feature.\n"); > + } > + > + rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); > + > + if ( !( _vmx_misc_cap & VMX_MISC_PT_SUPPORTED ) ) > + { > + vmx_function_table.ipt_supported = 0; > + printk("VMX: Missing support for Intel Processor Trace in VMX operation, VMX_MISC caps: %llx\n", > + (unsigned long long)_vmx_misc_cap); > + } > + > + if (vmx_function_table.ipt_supported) > + { > + printk("VMX: Intel Processor Trace is SUPPORTED"); > + } I think you could simplify this as: vmx_function_table.ipt_supported = cpu_has_ipt && (misc_cap & VMX_MISC_PT_SUPPORTED); Also the code is too chatty IMO. Looking at how other VMX features are detected, I think you should move the checks to vmx_init_vmcs_config and set the relevant bits in the VM control registers that you can then evaluate in vmx_display_features in order to print if the feature is supported? > + > lbr_tsx_fixup_check(); > ler_to_fixup_check(); > > diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h > index f790d5c1f8..8d7955dd87 100644 > --- a/xen/include/asm-x86/cpufeature.h > +++ b/xen/include/asm-x86/cpufeature.h > @@ -104,6 +104,7 @@ > #define cpu_has_clwb boot_cpu_has(X86_FEATURE_CLWB) > #define cpu_has_avx512er boot_cpu_has(X86_FEATURE_AVX512ER) > #define cpu_has_avx512cd boot_cpu_has(X86_FEATURE_AVX512CD) > +#define cpu_has_ipt boot_cpu_has(X86_FEATURE_IPT) > #define cpu_has_sha boot_cpu_has(X86_FEATURE_SHA) > #define cpu_has_avx512bw boot_cpu_has(X86_FEATURE_AVX512BW) > #define cpu_has_avx512vl boot_cpu_has(X86_FEATURE_AVX512VL) > diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h > index 1eb377dd82..48465b6067 100644 > --- a/xen/include/asm-x86/hvm/hvm.h > +++ b/xen/include/asm-x86/hvm/hvm.h > @@ -96,6 +96,9 @@ struct hvm_function_table { > /* Necessary hardware support for alternate p2m's? */ > bool altp2m_supported; > > + /* Hardware support for IPT? */ > + bool ipt_supported; We might want to name this pt_supported, since it's possible for other vendors to also introduce a processor tracing feature in the future? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 16:33:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 16:33:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEX2-0008O0-Bc; Tue, 16 Jun 2020 16:33:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEX0-0008Nu-RU for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 16:33:50 +0000 X-Inumbo-ID: 28335014-afef-11ea-b90a-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 28335014-afef-11ea-b90a-12813bfff9fa; Tue, 16 Jun 2020 16:33:50 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: jvfUrYOHSHCYB4SyXX7FReQKQY91o7NTTvHTsnW662VBvctov+kFwxsETOkvY670lAdyo33LZw 0tQO24kk7o8O354mi0u06TpEbmDkPL00drRSwluU5u3mlNHsTtfC7CTco9Do5pbtLAqqGjGP9X UOgERuqQFShAo1jkpT5Jvebj4gwdzx924Uv+U3AtR69LeD1WkvV+sfmHaOXu/L1aijlH3yBh0C cROHPrtgspi//xdXptODyJ63YENPp1TaQyv6PGIbgPd0ZZ5RiCoBU2GLwnI+twRq0YJol/sSSf 1nw= X-SBRS: 2.7 X-MesageID: 20533238 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20533238" Date: Tue, 16 Jun 2020 18:33:42 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 3/7] x86/vmx: add ipt_state as part of vCPU state Message-ID: <20200616163342.GS735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <350253733.8765869.1592320880975.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <350253733.8765869.1592320880975.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 05:21:20PM +0200, Michał Leszczyński wrote: > Guest IPT state will be preserved across vmentry/vmexit using > this structure. I think you should squash this patch with a patch where the structure it's actually used. > Signed-off-by: Michal Leszczynski > --- > xen/arch/x86/hvm/vmx/vmx.c | 2 ++ > xen/include/asm-x86/hvm/vmx/vmcs.h | 10 ++++++++++ > 2 files changed, 12 insertions(+) > > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index a91bbdb798..97104c319e 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -471,6 +471,8 @@ static int vmx_vcpu_initialise(struct vcpu *v) > > vmx_install_vlapic_mapping(v); > > + v->arch.hvm.vmx.ipt_state = NULL; Nit: there's no need to init this to NULL, since the structure is zeroed on allocation. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 16:47:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 16:47:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEkC-0000wa-Hn; Tue, 16 Jun 2020 16:47:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEkB-0000wV-7L for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 16:47:27 +0000 X-Inumbo-ID: 0ecd2486-aff1-11ea-b90f-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0ecd2486-aff1-11ea-b90f-12813bfff9fa; Tue, 16 Jun 2020 16:47:26 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: fSdtVnm6JJHdsgczPmagCN9PT3HkelCEfL3NgqETTrT+3N/7ePfXnC/KOzCDjEJp1wWLEHwJMX 1o/PpmsnHJQo2B9UL0ex/15T68j7DbvhCU9B6OmcHfsPaI7JsGMjun7Ff0RXvA0Uw7jWjb3jcC zrSmqDlTUCFq6yGUX6t2LZ9PJhkgAmuALYtoCQPo5zWaQVgDmNRzIk1GF5173/6x3OWWgDYu4b TrkeHlb88aqWBQS6WJIaksc0OeMHNcIJUy6oxi53VHDatfCeoNZjlDWjm7RvSuB7r21u30oy/X VUE= X-SBRS: 2.7 X-MesageID: 20202571 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20202571" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24296.63385.85216.194083@mariner.uk.xensource.com> Date: Tue, 16 Jun 2020 17:47:21 +0100 To: Jan Beulich , "xen-devel@lists.xenproject.org" , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu Subject: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) In-Reply-To: <24295.32330.508237.225844@mariner.uk.xensource.com> References: <24291.43673.301735.439410@mariner.uk.xensource.com> <24295.32330.508237.225844@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"): > I propose to update in > http://xenbits.xen.org/gitweb/?p=libvirt.git;a=summary > the refs > refs/heads/osstest/frozen/xen-4.10-testing > refs/heads/osstest/frozen/xen-4.9-testing > from > 681bc423e823ab86b20748db311721bdef20defe > 981e2c70973454cad360f7c9eec2d6ded0a86747 > respectively to > 076a2b409667dd9f716a2a2085e1ffea9d58fe8b > which is current value of > refs/heads/osstest/frozen/xen-4.11-testing > > Both of those will be fast-forward updates. I have now done this. There will be a further osstest change which I think will then sort all of this out. Ian. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:02:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:02:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEyW-0002az-Ss; Tue, 16 Jun 2020 17:02:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEyU-0002ar-Vv for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:02:15 +0000 X-Inumbo-ID: 1ffde70c-aff3-11ea-b7bb-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1ffde70c-aff3-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 17:02:14 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jlEyT-00084x-8A; Tue, 16 Jun 2020 18:02:13 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 2/4] standalone-generate-dump-flight-runvars: mkdir -p logs Date: Tue, 16 Jun 2020 17:58:10 +0100 Message-Id: <20200616165812.25380-2-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200616165812.25380-1-ian.jackson@eu.citrix.com> References: <20200616165812.25380-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Otherwise if logs doesn't exist, the code in `standalone' which is eventually called to build each flight will try to do it - but that code is not idempotent in the presence of other racing copies of itself. Rather than trusting mkdir -p there, do it here. No change other than to this dev-debugging script. Signed-off-by: Ian Jackson --- standalone-generate-dump-flight-runvars | 1 + 1 file changed, 1 insertion(+) diff --git a/standalone-generate-dump-flight-runvars b/standalone-generate-dump-flight-runvars index 3b893623..5c93b0af 100755 --- a/standalone-generate-dump-flight-runvars +++ b/standalone-generate-dump-flight-runvars @@ -53,6 +53,7 @@ if [ "x$AP_FETCH_PLACEHOLDERS" != xy ]; then mkdir tmp/apmemo fi export AP_FETCH_PFX='./memoise tmp/apmemo' + mkdir -p logs fi # In the future it might be nice for this script to arrange to use a -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:02:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:02:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEyf-0002by-Dc; Tue, 16 Jun 2020 17:02:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEye-0002ar-Qu for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:02:24 +0000 X-Inumbo-ID: 2028ce7c-aff3-11ea-bb8b-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2028ce7c-aff3-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 17:02:14 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jlEyT-00084x-HW; Tue, 16 Jun 2020 18:02:13 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 3/4] standalone: Do not complain about ssh if AP_FETCH_PLACEHOLDERS=y Date: Tue, 16 Jun 2020 17:58:11 +0100 Message-Id: <20200616165812.25380-3-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200616165812.25380-1-ian.jackson@eu.citrix.com> References: <20200616165812.25380-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In this case, there is no need to ssh anywhere. No change other than in dev-debugging setups. Signed-off-by: Ian Jackson --- standalone | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standalone b/standalone index b51acf7b..9553d6c9 100755 --- a/standalone +++ b/standalone @@ -136,7 +136,7 @@ if [ ! -r "$WebspaceLog" ] ; then echo "WARNING: Cannot read apache logs at $WebspaceLog. Some tests may fail" >&2 fi -if ! ssh-add -l >/dev/null ; then +if [ "x$AP_FETCH_PLACEHOLDERS" != x ] && ! ssh-add -l >/dev/null ; then echo "WARNING: Unable to access ssh-agent. Some tests may fail" >&2 fi -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:02:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:02:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEya-0002bB-4V; Tue, 16 Jun 2020 17:02:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEyZ-0002ar-Qp for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:02:19 +0000 X-Inumbo-ID: 1fd91f62-aff3-11ea-b7bb-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1fd91f62-aff3-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 17:02:14 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jlEyS-00084x-Vw; Tue, 16 Jun 2020 18:02:13 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 1/4] standalone: Fix spurious ] Date: Tue, 16 Jun 2020 17:58:09 +0100 Message-Id: <20200616165812.25380-1-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This looks like this was once a call to test(1). ssh-add, as it happens, seems to ignore this spuriuous `]' (!) so there isn't any significant change. Signed-off-by: Ian Jackson --- standalone | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standalone b/standalone index 977ad50c..b51acf7b 100755 --- a/standalone +++ b/standalone @@ -136,7 +136,7 @@ if [ ! -r "$WebspaceLog" ] ; then echo "WARNING: Cannot read apache logs at $WebspaceLog. Some tests may fail" >&2 fi -if ! ssh-add -l >/dev/null ] ; then +if ! ssh-add -l >/dev/null ; then echo "WARNING: Unable to access ssh-agent. Some tests may fail" >&2 fi -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:02:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:02:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEyk-0002dQ-Md; Tue, 16 Jun 2020 17:02:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlEyj-0002ar-Qu for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:02:29 +0000 X-Inumbo-ID: 204ab9c4-aff3-11ea-8496-bc764e2007e4 Received: from chiark.greenend.org.uk (unknown [2001:ba8:1e3::]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 204ab9c4-aff3-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 17:02:14 +0000 (UTC) Received: from [172.18.45.5] (helo=zealot.relativity.greenend.org.uk) by chiark.greenend.org.uk (Debian Exim 4.84_2 #1) with esmtp (return-path ijackson@chiark.greenend.org.uk) id 1jlEyT-00084x-Qv; Tue, 16 Jun 2020 18:02:13 +0100 From: Ian Jackson To: xen-devel@lists.xenproject.org Subject: [OSSTEST PATCH 4/4] make-flight: Test Xen 4.9 and Xen 4.10 on stretch Date: Tue, 16 Jun 2020 17:58:12 +0100 Message-Id: <20200616165812.25380-4-ian.jackson@eu.citrix.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200616165812.25380-1-ian.jackson@eu.citrix.com> References: <20200616165812.25380-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Xen 4.9 doesn't build on buster and won't be fixed for that. Xen 4.10's "-prev" migration tests also fail for the same reason. There is a (smallish) risk that Debian will break stretch before Xen 4.10 goes completely out of support from the Xen Project. If that happens we could revert this - but then the 4.10 -prev jobs will stop building. Xen 4.9 is nearly out of security support, so for the 4.9 tests this is a no-brainer. I have checked the runvar diff. The results are to change all_host_di_version [*] all_host_suite all_hostflags debian_suite debianhvm_suite host_hostflags in many jobs in qemu-upstream-4.9-testing qemu-upstream-4.10-testing xen-4.9-testing xen-4.10-testing [*] this is not visible in standalone-generate-dump-flight-runvars because it always just uses `current'. This command produces no output: diff -ub a <(perl -pe 's/stretch/buster/g' c) (where `a' is before and `c' is after.) Signed-off-by: Ian Jackson --- make-flight | 2 ++ 1 file changed, 2 insertions(+) diff --git a/make-flight b/make-flight index a361bcb1..836bc31c 100755 --- a/make-flight +++ b/make-flight @@ -41,6 +41,8 @@ case "$xenbranch" in xen-4.1-testing) defsuite="wheezy"; defguestsuite="wheezy";; xen-4.2-testing) defsuite="wheezy"; defguestsuite="wheezy";; xen-4.3-testing) defsuite="wheezy"; defguestsuite="wheezy";; + xen-4.9-testing) defsuite="stretch"; defguestsuite="stretch";; + xen-4.10-testing) defsuite="stretch"; defguestsuite="stretch";; *) defsuite=`getconfig DebianSuite` defguestsuite=`getconfig GuestDebianSuite` -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:24:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:24:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFJa-0004eL-PA; Tue, 16 Jun 2020 17:24:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFJZ-0004eG-4F for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:24:01 +0000 X-Inumbo-ID: 2a2e0f7e-aff6-11ea-b7bb-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2a2e0f7e-aff6-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 17:23:59 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ovqahp/+ZMcWeBRg7wcNi3fXc481L0avOVehRt+XTY65K7oaca2TUrlpHAParKuRy2pIo2gkDC CeG7y6B2IqGBSKhGZu/QVCp9JE2GF0zwvMDC3rS2gPcdt1GWNVJp/OkeD+PrnU9HSFGKv0iUUv uSDefTgNyIw5Y0hzOIabKvccw/RlcZ//xJNCTueE4BNMh1vdZBprwj6j2MkBaRrYeZWNhRZ0PW pE8gm/hFV5nRe8TaaXLHjYhfS5ZRkMJcu1j4XJQ730/eAB5UbPHVweOAMUCB/D9iEENim4F+1m sug= X-SBRS: 2.7 X-MesageID: 20539254 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20539254" Date: Tue, 16 Jun 2020 19:23:52 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op Message-ID: <20200616172352.GT735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 05:22:06PM +0200, Michał Leszczyński wrote: > Provide an interface for privileged domains to manage > external IPT monitoring. > > Signed-off-by: Michal Leszczynski Thanks for the patch! I have some questions below which require your input. > --- > xen/arch/x86/hvm/hvm.c | 170 ++++++++++++++++++++++++++++++++ > xen/include/public/hvm/hvm_op.h | 27 +++++ > 2 files changed, 197 insertions(+) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 5bb47583b3..9292caebe0 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -4949,6 +4949,172 @@ static int compat_altp2m_op( > return rc; > } > > +static int do_vmtrace_op( > + XEN_GUEST_HANDLE_PARAM(void) arg) No need for the newline, this can fit on a single line. > +{ > + struct xen_hvm_vmtrace_op a; > + struct domain *d = NULL; I don't think you need to init d to NULL (at least by looking at the current code below). > + int rc = -EFAULT; No need to init rc. > + int i; unsigned since it's used as a loop counter. > + struct vcpu *v; > + void* buf; Nit: '*' should be prepended to the variable name. > + uint32_t buf_size; size_t > + uint32_t buf_order; Order is generally fine using unsigned int, no need to use a specifically sized type. > + uint64_t buf_mfn; Could this use the mfn type? > + struct page_info *pg; > + > + if ( !hvm_ipt_supported() ) > + return -EOPNOTSUPP; > + > + if ( copy_from_guest(&a, arg, 1) ) > + return -EFAULT; > + > + if ( a.version != HVMOP_VMTRACE_INTERFACE_VERSION ) > + return -EINVAL; > + > + switch ( a.cmd ) > + { > + case HVMOP_vmtrace_ipt_enable: > + case HVMOP_vmtrace_ipt_disable: > + case HVMOP_vmtrace_ipt_get_buf: > + case HVMOP_vmtrace_ipt_get_offset: > + break; > + > + default: > + return -EOPNOTSUPP; > + } > + > + d = rcu_lock_domain_by_any_id(a.domain); > + > + if ( d == NULL ) > + return -ESRCH; > + > + if ( !is_hvm_domain(d) ) > + { > + rc = -EOPNOTSUPP; > + goto out; > + } > + > + domain_pause(d); > + > + if ( a.vcpu >= d->max_vcpus ) > + { > + rc = -EINVAL; > + goto out; > + } > + > + v = d->vcpu[a.vcpu]; > + > + if ( a.cmd == HVMOP_vmtrace_ipt_enable ) Please use a switch here, you might even consider re-using the switch from above and moving the domain checks before actually checking the command field, so that you don't need to perform two switches against a.cmd. > + { > + if ( v->arch.hvm.vmx.ipt_state ) { Coding style, brace should be on newline (there are more below which I'm not going to comment on). > + // already enabled Comments should use /* ... */, there multiple instances of this below which I'm not going to comment on, please check CODING_STYLE. Also, the interface looks racy, I think you are missing a lock to protect v->arch.hvm.vmx.ipt_state from being freed under your feet if you issue concurrent calls to the interface. > + rc = -EINVAL; > + goto out; > + } > + > + if ( a.size < PAGE_SIZE || a.size > 1000000 * PAGE_SIZE ) { You can use GB(4) which is easier to read. Should the size also be a multiple of a PAGE_SIZE? > + // we don't accept trace buffer size smaller than single page > + // and the upper bound is defined as 4GB in the specification > + rc = -EINVAL; > + goto out; > + } Stray tab. > + > + buf_order = get_order_from_bytes(a.size); > + > + if ( (a.size >> PAGE_SHIFT) != (1 << buf_order) ) { Oh here is the check. I think you can move this with the checks above by doing a.size & ~PAGE_MASK. > + rc = -EINVAL; > + goto out; > + } > + > + buf = page_to_virt(alloc_domheap_pages(d, buf_order, MEMF_no_refcount)); What if alloc_domheap_pages return NULL? Since I think you only what the linear address of the page to zero it I would suggest using clear_domain_page. > + buf_size = a.size; > + > + if ( !buf ) { > + rc = -EFAULT; > + goto out; > + } > + > + memset(buf, 0, buf_size); > + > + for ( i = 0; i < (buf_size >> PAGE_SHIFT); i++ ) { > + share_xen_page_with_privileged_guests(virt_to_page(buf) + i, SHARE_ro); This line (and some more below) exceeds 80 characters, please split it. > + } > + > + v->arch.hvm.vmx.ipt_state = xmalloc(struct ipt_state); You should check that xmalloc has succeeds before trying to access ipt_state. > + v->arch.hvm.vmx.ipt_state->output_base = virt_to_mfn(buf) << PAGE_SHIFT; > + v->arch.hvm.vmx.ipt_state->output_mask = buf_size - 1; > + v->arch.hvm.vmx.ipt_state->status = 0; > + v->arch.hvm.vmx.ipt_state->ctl = RTIT_CTL_TRACEEN | RTIT_CTL_OS | RTIT_CTL_USR | RTIT_CTL_BRANCH_EN; Shouldn't the user be able to select what tracing should be enabled? > + } > + else if ( a.cmd == HVMOP_vmtrace_ipt_disable ) > + { > + if ( !v->arch.hvm.vmx.ipt_state ) { > + rc = -EINVAL; > + goto out; > + } > + > + buf_mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT; > + buf_size = ( v->arch.hvm.vmx.ipt_state->output_mask + 1 ) & 0xFFFFFFFFUL; > + > + for ( i = 0; i < (buf_size >> PAGE_SHIFT); i++ ) > + { > + if ( (mfn_to_page(_mfn(buf_mfn + i))->count_info & PGC_count_mask) != 1 ) > + { > + rc = -EBUSY; > + goto out; > + } > + } > + > + xfree(v->arch.hvm.vmx.ipt_state); > + v->arch.hvm.vmx.ipt_state = NULL; > + > + for ( i = 0; i < (buf_size >> PAGE_SHIFT); i++ ) > + { > + pg = mfn_to_page(_mfn(buf_mfn + i)); > + put_page_alloc_ref(pg); > + if ( !test_and_clear_bit(_PGC_xen_heap, &pg->count_info) ) > + ASSERT_UNREACHABLE(); > + pg->u.inuse.type_info = 0; > + page_set_owner(pg, NULL); > + free_domheap_page(pg); Hm, this seems fairly dangerous, what guarantees that the caller is not going to map the buffer while you are trying to tear it down? You perform a check before freeing ipt_state, but between the check and the actual tearing down the domain might have setup mappings to them. I wonder, could you expand a bit on why trace buffers are allocated from domheap memory by Xen? There are a couple of options here, maybe the caller could provide it's own buffer, then Xen would take an extra reference to those pages and setup them to be used as buffers. Another alternative would be to use domhep memory but not let the caller map it directly, and instead introduce a hypercall to copy from the internal Xen buffer into a user-provided one. How much memory is used on average by those buffers? That would help decide a model that would best fit the usage. > + } > + } > + else if ( a.cmd == HVMOP_vmtrace_ipt_get_buf ) > + { > + if ( !v->arch.hvm.vmx.ipt_state ) { > + rc = -EINVAL; > + goto out; > + } > + > + a.mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT; This will not work for translated domains, ie: a PVH or HVM domain won't be able to use this interface since it has no way to request the mapping of a specific mfn into it's physmap. I think we need to take this into account when deciding how the interface should be, so that we don't corner ourselves with a PV only interface. > + a.size = (v->arch.hvm.vmx.ipt_state->output_mask + 1) & 0xFFFFFFFFUL; You can truncate it easier by casting to uint32_t I think. Or even better, you could put output_mask in a union like: union { uint64_t raw; struct { uint32_t size; uint32_t offset; } } Then you can avoid the shifting and the castings. > + } > + else if ( a.cmd == HVMOP_vmtrace_ipt_get_offset ) > + { > + if ( !v->arch.hvm.vmx.ipt_state ) { > + rc = -EINVAL; > + goto out; > + } > + > + a.offset = v->arch.hvm.vmx.ipt_state->output_mask >> 32; > + } > + > + rc = -EFAULT; > + if ( __copy_to_guest(arg, &a, 1) ) > + goto out; > + rc = 0; > + > + out: > + smp_wmb(); Why do you need a barrier here? > + domain_unpause(d); > + rcu_unlock_domain(d); > + > + return rc; > +} > + > +DEFINE_XEN_GUEST_HANDLE(compat_hvm_vmtrace_op_t); > + > static int hvmop_get_mem_type( > XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg) > { > @@ -5101,6 +5267,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) > rc = current->hcall_compat ? compat_altp2m_op(arg) : do_altp2m_op(arg); > break; > > + case HVMOP_vmtrace: > + rc = do_vmtrace_op(arg); > + break; > + > default: > { > gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op); > diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h > index 870ec52060..3bbcd54c96 100644 > --- a/xen/include/public/hvm/hvm_op.h > +++ b/xen/include/public/hvm/hvm_op.h > @@ -382,6 +382,33 @@ struct xen_hvm_altp2m_op { > typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; > DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); > > +/* HVMOP_vmtrace: Perform VM tracing related operation */ > +#define HVMOP_vmtrace 26 > + > +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 > + > +struct xen_hvm_vmtrace_op { > + /* IN variable */ > + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ > + uint32_t cmd; > +/* Enable/disable external vmtrace for given domain */ > +#define HVMOP_vmtrace_ipt_enable 1 > +#define HVMOP_vmtrace_ipt_disable 2 > +#define HVMOP_vmtrace_ipt_get_buf 3 > +#define HVMOP_vmtrace_ipt_get_offset 4 > + domid_t domain; You are missing a padding field here AFAICT. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:39:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:39:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFYA-0005fN-4Q; Tue, 16 Jun 2020 17:39:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFY9-0005fI-0E for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:39:05 +0000 X-Inumbo-ID: 453ec810-aff8-11ea-b91d-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 453ec810-aff8-11ea-b91d-12813bfff9fa; Tue, 16 Jun 2020 17:39:04 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Mb4s/JXwT4z+JVYADY0DJeKUP6xM8ze+DZ4hLLiiB98bE5Rj873p6CV9wW05uMe0RTNBOR29Kn PsBDttcGSlC79Us4WTSsWtB4AM5dY6NBJP6a8QlgOlYYcsc7Kl0jo1g56fPrBqZ9Y2ChF0rRsJ Z3Dfk4DSc14vrg8dGCHkch0m9n82fg9OrpJaZ0sYFeEGthnZCXPWcV53EAhwZ2otddyqtvUT+V zO66bIbwFoTlgfYmvobJndaZMdrF8dBe0NS2LnI72sCMMTORN4PjR5AyhpyvqbITUFLBByNH8q 0mQ= X-SBRS: 2.7 X-MesageID: 20975100 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,518,1583211600"; d="scan'208";a="20975100" Date: Tue, 16 Jun 2020 19:38:57 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit Message-ID: <20200616173857.GU735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 05:24:11PM +0200, Michał Leszczyński wrote: > Enable IPT when entering the VM and disable it on vmexit. > Register state is persisted using vCPU ipt_state structure. Shouldn't this be better done using Intel MSR load lists? That seems to be what the SDM recommends for tracing VM events. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:47:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:47:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFga-0006Xu-1G; Tue, 16 Jun 2020 17:47:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFgZ-0006Xp-5M for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:47:47 +0000 X-Inumbo-ID: 7c5e218c-aff9-11ea-bca7-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7c5e218c-aff9-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 17:47:46 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 41158A2F9F; Tue, 16 Jun 2020 19:47:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 35187A2F98; Tue, 16 Jun 2020 19:47:44 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QJtHddik42Er; Tue, 16 Jun 2020 19:47:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9947DA2F9F; Tue, 16 Jun 2020 19:47:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZrFB61byiPS5; Tue, 16 Jun 2020 19:47:43 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 71055A2F98; Tue, 16 Jun 2020 19:47:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 6145B2171F; Tue, 16 Jun 2020 19:47:13 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wtN2IQ-4u9Lm; Tue, 16 Jun 2020 19:47:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id EF8A221866; Tue, 16 Jun 2020 19:47:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id B5S2HbGMqY-G; Tue, 16 Jun 2020 19:47:07 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id C54C62171F; Tue, 16 Jun 2020 19:47:07 +0200 (CEST) Date: Tue, 16 Jun 2020 19:47:07 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> In-Reply-To: <20200616173857.GU735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> <20200616173857.GU735@Air-de-Roger> Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: switch IPT MSRs on vmentry/vmexit Thread-Index: IsFlRe2+pVIoLpVn5usOa8NJmss1gw== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 16 cze 2020 o 19:38, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Tue, Jun 16, 2020 at 05:24:11PM +0200, Micha=C5=82 Leszczy=C5=84ski wr= ote: >> Enable IPT when entering the VM and disable it on vmexit. >> Register state is persisted using vCPU ipt_state structure. >=20 > Shouldn't this be better done using Intel MSR load lists? >=20 > That seems to be what the SDM recommends for tracing VM events. >=20 > Thanks, Roger. This is intentional, additionally described by the comment: // MSR_IA32_RTIT_CTL is context-switched manually instead of being // stored inside VMCS, as of Q2'20 only the most recent processors // support such field in VMCS There is a special feature flag which indicates whether MSR_IA32_RTIT_CTL c= an be loaded using MR load lists. During my experiments, I haven't found an= y single CPU available to me that would declare such a feature flag. I was = mostly testing CPUs that were launched in 2018, so I suppose that this feat= ure is present only on very recent hardware. Unfortunately it's not possibl= e to check on Intel ARK as this information is not listed there at all. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:59:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:59:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFrq-0007UJ-2p; Tue, 16 Jun 2020 17:59:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFro-0007Ta-6d for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:59:24 +0000 X-Inumbo-ID: 1c2ca34a-affb-11ea-b923-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1c2ca34a-affb-11ea-b923-12813bfff9fa; Tue, 16 Jun 2020 17:59:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wGfJn96R3ZlVVuYZ9IwqkUyeFMh4LTwYfmmbem1Z51E=; b=tVQhtFigcnMutcLTi5GeqlfvhN YL1zs1vJkFKer+dmngOqbZboQXhLIaVontpJE1+6VKxw7YK92lwiNNslLANTETeQ1eqofTOH93M6B NbulPRnmaGeto2t4j8dxlwFYS1s+Dz5nqsTIvSJg8fBNr2QilNJMndRN5qP8DOYbr5Rc=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFri-0003kY-8n; Tue, 16 Jun 2020 17:59:18 +0000 Received: from 54-240-197-227.amazon.com ([54.240.197.227] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jlFrh-00036w-Uo; Tue, 16 Jun 2020 17:59:18 +0000 From: Julien Grall To: security@xenproject.org Subject: [PATCH 0/2] xen/arm: Mitigate straight-line speculation Date: Tue, 16 Jun 2020 18:59:11 +0100 Message-Id: <20200616175913.7368-1-julien@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, paul@xen.org, Andre.Przywara@arm.com, Julien Grall , Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org, Volodymyr_Babchuk@epam.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Julien Grall Hi all, Arm recently released a whitepaper about a new category of speculation. (see [1] and [2]). In short, a processor may be able to speculate past some of the unconditional control flow instructions (e.g eret, smc, br). In some of the cases, the registers will contain values controlled by the guest. While there is no known gadget afterwards, we still want to prevent any leakage in the future. The mitigation is planned in two parts: 1) Arm provided patches for both GCC and LLVM to add speculation barrier and remove problematic code sequence. 2) Inspection of assembly code and call to higher level (e.g smc in our case). I am still waiting on more input for 1), so this series only address 2) for the moment. Note that the ERET instruction was already addressed as part of XSA-312. The patch series is directly sent on the mailing list as the security team has been aware of the issues after the whitepaper was publicly released. Cheers, [1] https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability [2] https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation Julien Grall (2): xen/arm: entry: Place a speculation barrier following an ret instruction xen/arm: Mitigate straight-line speculation for SMC call xen/arch/arm/arm32/entry.S | 1 + xen/arch/arm/arm64/entry.S | 2 ++ xen/arch/arm/arm64/smc.S | 1 + xen/include/asm-arm/smccc.h | 13 +++++++++++++ xen/include/asm-arm/system.h | 8 ++++++++ 5 files changed, 25 insertions(+) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:59:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:59:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFru-0007Ug-Bt; Tue, 16 Jun 2020 17:59:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFrt-0007Ta-0W for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:59:29 +0000 X-Inumbo-ID: 1c087dbd-affb-11ea-b923-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1c087dbd-affb-11ea-b923-12813bfff9fa; Tue, 16 Jun 2020 17:59:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=W4Ily84UCBoYBbX+TgbLDPbYSt958UYp94RRwD0IRi4=; b=pfedFbfkmM6wYWHAroxsXB8U1v xtuP6mMvmNW6IpScKo7PEFQYLuCgrQDuWUM+fq9gN+DzJuK8fL7jszH5GXayggAYsQl62oBuWYzN+ +xdnM6o9q2bULSdXdEiXTrKPngJRRv7TWkHShDZuzuD866Epv9bqBhxvA2ztrw7hHgbY=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFrj-0003ka-KK; Tue, 16 Jun 2020 17:59:19 +0000 Received: from 54-240-197-227.amazon.com ([54.240.197.227] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jlFrj-00036w-B3; Tue, 16 Jun 2020 17:59:19 +0000 From: Julien Grall To: security@xenproject.org Subject: [PATCH 1/2] xen/arm: entry: Place a speculation barrier following an ret instruction Date: Tue, 16 Jun 2020 18:59:12 +0100 Message-Id: <20200616175913.7368-2-julien@xen.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200616175913.7368-1-julien@xen.org> References: <20200616175913.7368-1-julien@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, paul@xen.org, Andre.Przywara@arm.com, Julien Grall , Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org, Volodymyr_Babchuk@epam.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Julien Grall Some CPUs can speculate past a RET instruction and potentially perform speculative accesses to memory before processing the return. There is no known gadget available after the RET instruction today. However some of the registers (such as in check_pending_guest_serror()) may contain a value provided the guest. In order to harden the code, it would be better to add a speculation barrier after each RET instruction. The performance is meant to be negligeable as the speculation barrier is not meant to be archicturally executed. Note that on arm32, the ldmia instruction will act as a return from the function __context_switch(). While the whitepaper doesn't suggest it is possible to speculate after the instruction, add preventively a speculation barrier after it as well. This is part of the work to mitigate straight-line speculation. Signed-off-by: Julien Grall --- I am still unsure whether we preventively should add a speculation barrier preventively after all the RET instructions in arm*/lib/. The smc call be taken care in a follow-up patch. --- xen/arch/arm/arm32/entry.S | 1 + xen/arch/arm/arm64/entry.S | 2 ++ 2 files changed, 3 insertions(+) diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S index b228d44b190c..bd54fc43558b 100644 --- a/xen/arch/arm/arm32/entry.S +++ b/xen/arch/arm/arm32/entry.S @@ -442,6 +442,7 @@ ENTRY(__context_switch) add r4, r1, #VCPU_arch_saved_context ldmia r4, {r4 - sl, fp, sp, pc} /* Load registers and return */ + sb /* * Local variables: diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S index 175ea2981e72..b37d8fe09dc2 100644 --- a/xen/arch/arm/arm64/entry.S +++ b/xen/arch/arm/arm64/entry.S @@ -522,6 +522,7 @@ abort_guest_exit_end: cset x19, ne ret + sb ENDPROC(check_pending_guest_serror) /* @@ -583,6 +584,7 @@ ENTRY(__context_switch) ldr lr, [x8] mov sp, x9 ret + sb /* * Local variables: -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 17:59:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 17:59:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFry-0007V7-LR; Tue, 16 Jun 2020 17:59:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFry-0007Ta-0c for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 17:59:34 +0000 X-Inumbo-ID: 1d8b603c-affb-11ea-b923-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1d8b603c-affb-11ea-b923-12813bfff9fa; Tue, 16 Jun 2020 17:59:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=12y0VkXW+AgZVDIaCYlRD6wnppSAnpuFa9zY5Bz1Ye8=; b=0VaU6bUclTEw9ILq+fnMYdWFTN eHShCyoKH1HTBGkqadzPFyTgqYX3XBLsPKf/vY+9GDYKw8muoszOea5YkWDy488ILUqCDji90THrx zzgDX90mGPotO49+WpRL+y3wI/eq0xRHm6RQ1efh+OXM5E5MT1BR3+xjBbForhrLZcMs=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlFrl-0003ki-0g; Tue, 16 Jun 2020 17:59:21 +0000 Received: from 54-240-197-227.amazon.com ([54.240.197.227] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jlFrk-00036w-NU; Tue, 16 Jun 2020 17:59:20 +0000 From: Julien Grall To: security@xenproject.org Subject: [PATCH 2/2] xen/arm: Mitigate straight-line speculation for SMC call Date: Tue, 16 Jun 2020 18:59:13 +0100 Message-Id: <20200616175913.7368-3-julien@xen.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200616175913.7368-1-julien@xen.org> References: <20200616175913.7368-1-julien@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, paul@xen.org, Andre.Przywara@arm.com, Julien Grall , Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org, Volodymyr_Babchuk@epam.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Julien Grall SMC call will update some of registers (typically only x0) depending on the arguments provided. Some CPUs can speculate past a SMC instruction and potentially perform speculative access to emrmoy using the pre-call values before executing the SMC. There is no known gadget available after the SMC call today. However some of the registers may contain values from the guest and are expected to be updated by the SMC call. In order to harden the code, it would be better to prevent straight-line speculation from an SMC. Architecturally executing the speculation barrier after every SMC can be rather expensive (particularly on core not SB). Therefore we want to mitigate it diferrently: * For arm_smccc_1_0_smc, we can avoid a speculation barrier right after the SMC instruction and instead rely on the one after eret. * For arm_smccc_1_1_smc, we can place a B instruction after the SMC instruction to skip the barrier. Note that arm_smccc_1_0_smc version on arm32 is just an alias to arm_smccc_1_1_smc. Note that no speculation barrier has been added after the SMC instruction in arm64/entry.S. This is fine because the call is not expected to modify any registers. So straight-line speculation doesn't matter. Signed-off-by: Julien Grall --- Note this hasn't been vetted by Arm but they are using the same sort of mitigation for blr. So I am quite confident this could do the trick. --- xen/arch/arm/arm64/smc.S | 1 + xen/include/asm-arm/smccc.h | 13 +++++++++++++ xen/include/asm-arm/system.h | 8 ++++++++ 3 files changed, 22 insertions(+) diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S index b0752be57e8f..e0a3106dd7ec 100644 --- a/xen/arch/arm/arm64/smc.S +++ b/xen/arch/arm/arm64/smc.S @@ -30,3 +30,4 @@ ENTRY(__arm_smccc_1_0_smc) stp x2, x3, [x4, #SMCCC_RES_a2] 1: ret + sb diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h index 9d94beb3df2d..8650224923b1 100644 --- a/xen/include/asm-arm/smccc.h +++ b/xen/include/asm-arm/smccc.h @@ -200,11 +200,24 @@ struct arm_smccc_res { * We have an output list that is not necessarily used, and GCC feels * entitled to optimise the whole sequence away. "volatile" is what * makes it stick. + * + * Some of the SMC callers are passing directly values that are + * controlled by the guest. To mitigate against straight-line + * speculation, a speculation barrier is required. As it may be + * expensive to architecturally execute the speculation barrier, we are + * using a B instruction to architecturally skip it. + * + * Note that the speculation barrier is technically not necessary as the + * B instruction should already block straight-line speculation. But + * better be safe than sorry ;). */ #define arm_smccc_1_1_smc(...) \ do { \ __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ asm volatile("smc #0\n" \ + "b 1f\n" \ + ASM_SB \ + "1:\n" \ __constraints(__count_args(__VA_ARGS__))); \ if ( ___res ) \ *___res = (typeof(*___res)){r0, r1, r2, r3}; \ diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h index 65d5c8e423d7..e33ff4e0fc39 100644 --- a/xen/include/asm-arm/system.h +++ b/xen/include/asm-arm/system.h @@ -33,6 +33,14 @@ #define smp_mb__before_atomic() smp_mb() #define smp_mb__after_atomic() smp_mb() +/* + * Speculative barrier + * XXX: Add support for the 'sb' instruction + */ +#define ASM_SB "dsb nsh \n isb \n" + +#define sb() asm volatile(ASM_SB) + /* * This is used to ensure the compiler did actually allocate the register we * asked it for some inline assembly sequences. Apparently we can't trust -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 18:14:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 18:14:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlG63-0000wU-5N; Tue, 16 Jun 2020 18:14:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlG61-0000wP-Vk for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 18:14:06 +0000 X-Inumbo-ID: 298a3dca-affd-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 298a3dca-affd-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 18:14:05 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id q19so22623033eja.7 for ; Tue, 16 Jun 2020 11:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BmjCZtF1kgQ7PeaIEx8/UxbYmvWysAGr4o2NegH2AmY=; b=n/GveDtdtOhjYSOp7LF79tbS7jWdCSCfEyPFmO5XLwB3GwNMeqmr4a1zdqYMfir3Ui VUylr1ts4L2rpSiBfNm52HzQ+PazA6BJAGzvT/zAHimNN1SQYdp6BdAuC8gkJpB+Zaoe sgvXQFCFz8lYZo4lEzqL80Q4HVzcxeBza32xExymMNmDsVf0P7JTLkNHjYrI1HFowb8k PN5vSz7Ik/i/iI/n1gXZgNuMucGHzMzb2oUGHrJPof30nOYVRM0XI6yiEM6nK08JRGuc k/mVFgisHys2ZZa744fDzwUi4CW5LYfpCCeOb61DEUmffrczXhIHNMzXLf1afePmbnw0 JIyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BmjCZtF1kgQ7PeaIEx8/UxbYmvWysAGr4o2NegH2AmY=; b=tr26rRjK940XXF2IQXm/0kseOfVEa2XOqp6Ftv1/vHRJPTvBMN8XdcczdKTyt/3dEP I0UttWOEUVIxBTIoTgCeeOm/rdnZTWmydZnjhfTeTXl2pOQyxNDpR73cYoXudcmMgyVg 2tjdFDNL9WebxfWlm9zHsBTlTwKtN6nu9ayrkO9kePykz6DiXNYwktBgN6rV7nZll6YB zAA7yk9Hf7F+y9pmHxMtCFiriX4m0K94ba26iWX59xxww+CkOtzQz25kp+dUR/JAx77D qzzkYZCuGXiXow83ofCE1AUKJeURstuFMe20eDql84SrAyJ8Xrb29T8jtKLdSQPQMzDd RMoQ== X-Gm-Message-State: AOAM530z/qIf4/252J63vcU3Qf3JrfJeKI2f0xHZIVukD+IHaFDVK17o 54rYp+DKre18069mBWVHcDMaMVrsubSmeQVIHLg= X-Google-Smtp-Source: ABdhPJxkOnz6lRTtovRk+ANFmtyCHd/dTqvRSqcCw2W9M4fCozGArZY86RTCbUZ8nS9dvWdDL+XbVVwp+0jYTsfbM3w= X-Received: by 2002:a17:906:5f93:: with SMTP id a19mr3877092eju.10.1592331244326; Tue, 16 Jun 2020 11:14:04 -0700 (PDT) MIME-Version: 1.0 References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> In-Reply-To: <4bab90465acfddae5868ce2311bd9889@kernel.org> From: CodeWiz2280 Date: Tue, 16 Jun 2020 14:13:51 -0400 Message-ID: Subject: Re: Keystone Issue To: Marc Zyngier Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Bertrand Marquis , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: > > On 2020-06-15 20:14, CodeWiz2280 wrote: > > [...] > > > Also, the latest linux kernel still has the X-Gene storm distributor > > address as "0x78010000" in the device tree, which is what the Xen code > > considers a match with the old firmware. What were the addresses for > > the device tree supposed to be changed to? > > We usually don't care, as the GIC address is provided by the bootloader, > whether via DT or ACPI (this is certainly what happens on Mustang). > Whatever is still in the kernel tree is just as dead as the platform it > describes. > > > Is my understanding > > correct that there is a different base address required to access the > > "non-secure" region instead of the "secure" 0x78010000 region? I'm > > trying to see if there are corresponding different addresses for the > > keystone K2E, but haven't found them yet in the manuals. > > There is no such address. Think of the NS bit as an *address space* > identifier. > > The only reason XGene presents the NS part of the GIC at a different > address is because XGene is broken enough not to have EL3, hence no > secure mode. To wire the GIC (and other standard ARM IPs) to the core, > the designers simply used the CPU NS signal as an address bit. > > On your platform, the NS bit does exist. I strongly suppose that it > isn't wired to the GIC. Please talk to your SoC vendor for whether iot > is possible to work around this. > I do have a question about this out to TI, but at least this method gives me something to work with in the meantime. I was just looking to confirm that there wouldn't be any other undesirable side effects with Dom0 or DomU when using it. Was there an actual FPGA for the X-Gene that needed to be updated which controlled the GIC access? Or by firmware do you mean the boot loader (e.g. uboot). Thanks for the support so far to all. > M. > -- > Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Tue Jun 16 18:17:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 18:17:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlG95-00016C-LC; Tue, 16 Jun 2020 18:17:15 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlG93-000165-Jp for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 18:17:13 +0000 X-Inumbo-ID: 99142a8e-affd-11ea-b930-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 99142a8e-affd-11ea-b930-12813bfff9fa; Tue, 16 Jun 2020 18:17:12 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: rbklXlwjIEZTtPFq8K5+OVoUIngeX31A+norekkFqZe6P6oMKL/zjVmFtZI/E+W7caLjgfRMKK Q2b0a1oCtwghjOKxOWPps21494hvzI0/7Bunye7LnCfemQQN7HRJZuAHnInjPhlKaVprvAo/xD S5sRpxJYnX3PRvqzoZ6ioN+m7B96JL6C/RZW622hdfsob2Ph406eUmrK+e8g+EH47sbxmNa9ix 0hD/JvqEZrM3644U66JeBvlpXTmcDC/1ev1RCGi/Xz8z/CZLcvaXf0RBpkmbP3oNs1vMTJldUl vB4= X-SBRS: 2.7 X-MesageID: 20199518 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,519,1583211600"; d="scan'208";a="20199518" Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Xen-devel References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> From: Andrew Cooper Message-ID: Date: Tue, 16 Jun 2020 19:17:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Ian Jackson , George Dunlap , Jun Nakajima , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 16:16, Michał Leszczyński wrote: > Intel Processor Trace is an architectural extension available in modern Intel family CPUs. It allows recording the detailed trace of activity while the processor executes the code. One might use the recorded trace to reconstruct the code flow. It means, to find out the executed code paths, determine branches taken, and so forth. > > The abovementioned feature is described in Intel(R) 64 and IA-32 Architectures Software Developer's Manual Volume 3C: System Programming Guide, Part 3, Chapter 36: "Intel Processor Trace." > > This patch series implements an interface that Dom0 could use in order to enable IPT for particular vCPUs in DomU, allowing for external monitoring. Such a feature has numerous applications like malware monitoring, fuzzing, or performance testing. Hello, I'm very excited to see support like this appearing.  However, be aware that we're currently in code freeze for the 4.14 release, so in-depth reviews will probably be delayed somewhat due to our bug queue and release activities. That said, I've had a very quick look through the series, and have a few general questions first. AFAICT, this is strictly for external monitoring of the VM, not for the VM to use itself?  If so, it shouldn't have the H tag here: XEN_CPUFEATURE(IPT,           5*32+25) /*H  Intel Processor Trace */ because that exposes the feature to the guest, with the implication that all other parts of the feature work as advertised. Are there any restrictions on EPT being enabled in the first place?  I'm not aware of any, and in principle we could use this functionality for PV guests as well (using the CPL filter).  Therefore, I think it would be helpful to not tie the functionality to HVM guests, even if that is the only option enabled to start with. The buffer mapping and creation logic is fairly problematic.  Instead of fighting with another opencoded example, take a look at the IOREQ server's use of "acquire resource" which is a mapping interface which supports allocating memory on behalf of the guest, outside of the guest memory, for use by control tools. I think what this wants is a bit somewhere in domain_create to indicate that external tracing is used for this domain (and allocate whatever structures/buffers are necessary), acquire resource to map the buffers themselves, and a domctl for any necessary runtime controls. What semantics do you want for the buffer becoming full?  Given that debugging/tracing is the goal, I presume "pause vcpu on full" is the preferred behaviour, rather than drop packets on full? When this subject was broached on xen-devel before, one issue was the fact that all actions which are intercepted don't end up writing any appropriate packets.  This is perhaps less of an issue for this example, where the external agent can see VMExits in the trace, but it still results in missing information.  (It is a major problem for PT within the guest, and needs Xen's intercept/emulation framework being updated to be PT-aware so it can fill in the same packets which hardware would have done for equivalent actions.) Thanks, ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 16 18:23:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 18:23:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlGFE-0001xD-4i; Tue, 16 Jun 2020 18:23:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlGFC-0001x8-R8 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 18:23:34 +0000 X-Inumbo-ID: 7caee554-affe-11ea-b936-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7caee554-affe-11ea-b936-12813bfff9fa; Tue, 16 Jun 2020 18:23:34 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 22AD32098B; Tue, 16 Jun 2020 18:23:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592331813; bh=L+zcAlpK4LLcoh84ilQFXzQsymWz6X1k9LdpJlw13iY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FJckkZRumHrAUk1+W3+921XrTHy+vkfkgMqXbrIBc4n2nuofB1DvFe/Q2A+Pyg/gs cWFSlaFxWUZi1yk48J0R9HbTEkBs8uia5i2D2ijRW589MDaZYvPcvClQB/oTTHJg1b GbeBc0leDYXsfuzDSo7vwpbrvSnENC68EJiUX3Pk= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlGF9-003W3p-Ls; Tue, 16 Jun 2020 19:23:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 16 Jun 2020 19:23:31 +0100 From: Marc Zyngier To: CodeWiz2280 Subject: Re: Keystone Issue In-Reply-To: References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: codewiz2280@gmail.com, julien.grall.oss@gmail.com, Bertrand.Marquis@arm.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Bertrand Marquis , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-16 19:13, CodeWiz2280 wrote: > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: >> >> On 2020-06-15 20:14, CodeWiz2280 wrote: >> >> [...] >> >> > Also, the latest linux kernel still has the X-Gene storm distributor >> > address as "0x78010000" in the device tree, which is what the Xen code >> > considers a match with the old firmware. What were the addresses for >> > the device tree supposed to be changed to? >> >> We usually don't care, as the GIC address is provided by the >> bootloader, >> whether via DT or ACPI (this is certainly what happens on Mustang). >> Whatever is still in the kernel tree is just as dead as the platform >> it >> describes. >> >> > Is my understanding >> > correct that there is a different base address required to access the >> > "non-secure" region instead of the "secure" 0x78010000 region? I'm >> > trying to see if there are corresponding different addresses for the >> > keystone K2E, but haven't found them yet in the manuals. >> >> There is no such address. Think of the NS bit as an *address space* >> identifier. >> >> The only reason XGene presents the NS part of the GIC at a different >> address is because XGene is broken enough not to have EL3, hence no >> secure mode. To wire the GIC (and other standard ARM IPs) to the core, >> the designers simply used the CPU NS signal as an address bit. >> >> On your platform, the NS bit does exist. I strongly suppose that it >> isn't wired to the GIC. Please talk to your SoC vendor for whether iot >> is possible to work around this. >> > I do have a question about this out to TI, but at least this method > gives me something to work with in the meantime. I was just looking > to confirm that there wouldn't be any other undesirable side effects > with Dom0 or DomU when using it. Was there an actual FPGA for the > X-Gene that needed to be updated which controlled the GIC access? Or > by firmware do you mean the boot loader (e.g. uboot). Thanks for the > support so far to all. As I said, the specific case of XGene was just a matter of picking the right address, as the NS bit is used as an address bit on this platform. This was possible because this machine doesn't have any form of security. So no HW was changed, no FPGA reprogrammed. Only a firmware table was fixed to point to the right spot. Not even u-boot or EFI was changed. M. -- Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Tue Jun 16 18:48:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 18:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlGdV-0003nr-8l; Tue, 16 Jun 2020 18:48:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlGdU-0003nm-9w for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 18:48:40 +0000 X-Inumbo-ID: fdb3462e-b001-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fdb3462e-b001-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 18:48:39 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id F3E1EA1D92; Tue, 16 Jun 2020 20:48:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id E227BA1513; Tue, 16 Jun 2020 20:48:36 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id dlq2o9uqsAiz; Tue, 16 Jun 2020 20:48:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id C4407A14B2; Tue, 16 Jun 2020 20:48:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CZDzGml4J5bX; Tue, 16 Jun 2020 20:48:34 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 92500A2FA4; Tue, 16 Jun 2020 20:48:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 6EEE6224A8; Tue, 16 Jun 2020 20:48:04 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UdeCGprpZCxz; Tue, 16 Jun 2020 20:47:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id BD6EC22366; Tue, 16 Jun 2020 20:47:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9tGm1aEm48UM; Tue, 16 Jun 2020 20:47:58 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 9A9EB208EF; Tue, 16 Jun 2020 20:47:58 +0200 (CEST) Date: Tue, 16 Jun 2020 20:47:58 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Andrew Cooper Message-ID: <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> In-Reply-To: References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: Mv6kJb8Q6XwLCucBvgGCHIJZaiWzPA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Ian Jackson , George Dunlap , Jun Nakajima , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com napisa= =C5=82(a): > On 16/06/2020 16:16, Micha=C5=82 Leszczy=C5=84ski wrote: >> Intel Processor Trace is an architectural extension available in modern = Intel >> family CPUs. It allows recording the detailed trace of activity while th= e >> processor executes the code. One might use the recorded trace to reconst= ruct >> the code flow. It means, to find out the executed code paths, determine >> branches taken, and so forth. >> >> The abovementioned feature is described in Intel(R) 64 and IA-32 Archite= ctures >> Software Developer's Manual Volume 3C: System Programming Guide, Part 3, >> Chapter 36: "Intel Processor Trace." >> >> This patch series implements an interface that Dom0 could use in order t= o enable >> IPT for particular vCPUs in DomU, allowing for external monitoring. Such= a >> feature has numerous applications like malware monitoring, fuzzing, or >> performance testing. >=20 > Hello, >=20 > I'm very excited to see support like this appearing.=C2=A0 However, be aw= are > that we're currently in code freeze for the 4.14 release, so in-depth > reviews will probably be delayed somewhat due to our bug queue and > release activities. Sure, take your time :) >=20 > That said, I've had a very quick look through the series, and have a few > general questions first. >=20 > AFAICT, this is strictly for external monitoring of the VM, not for the > VM to use itself?=C2=A0 If so, it shouldn't have the H tag here: >=20 > XEN_CPUFEATURE(IPT,=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 5*32+25) /*H=C2=A0 Intel Processor Trace */ >=20 > because that exposes the feature to the guest, with the implication that > all other parts of the feature work as advertised. Ok, I will remove the H tag. >=20 >=20 > Are there any restrictions on EPT being enabled in the first place?=C2=A0= I'm > not aware of any, and in principle we could use this functionality for > PV guests as well (using the CPL filter).=C2=A0 Therefore, I think it wou= ld > be helpful to not tie the functionality to HVM guests, even if that is > the only option enabled to start with. I think at the moment it's not required to have EPT. This patch series does= n't use any translation feature flags, so the output address is always a ma= chine physical address, regardless of context. I will check if it could be = easily used with PV. >=20 > The buffer mapping and creation logic is fairly problematic.=C2=A0 Instea= d of > fighting with another opencoded example, take a look at the IOREQ > server's use of "acquire resource" which is a mapping interface which > supports allocating memory on behalf of the guest, outside of the guest > memory, for use by control tools. >=20 > I think what this wants is a bit somewhere in domain_create to indicate > that external tracing is used for this domain (and allocate whatever > structures/buffers are necessary), acquire resource to map the buffers > themselves, and a domctl for any necessary runtime controls. >=20 I will check this out, this sounds like a good option as it would remove lo= ts of complexity from the existing ipt_enable domctl. >=20 > What semantics do you want for the buffer becoming full?=C2=A0 Given that > debugging/tracing is the goal, I presume "pause vcpu on full" is the > preferred behaviour, rather than drop packets on full? >=20 Right now this is a ring-style buffer and when it would become full it woul= d simply wrap and override the old data. >=20 > When this subject was broached on xen-devel before, one issue was the > fact that all actions which are intercepted don't end up writing any > appropriate packets.=C2=A0 This is perhaps less of an issue for this exam= ple, > where the external agent can see VMExits in the trace, but it still > results in missing information.=C2=A0 (It is a major problem for PT withi= n > the guest, and needs Xen's intercept/emulation framework being updated > to be PT-aware so it can fill in the same packets which hardware would > have done for equivalent actions.) Ok, this sounds like a hard issue. Could you point out what could be the pa= rticular problematic cases? For instance, if something would alter EIP/RIP = or CR3 then I belive it would still be recorded in PT trace (i.e. these val= ues will be logged on VM entry). >=20 >=20 > Thanks, >=20 > ~Andrew Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Tue Jun 16 19:31:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 19:31:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlHIj-0007sQ-MY; Tue, 16 Jun 2020 19:31:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlHIi-0007sL-1C for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 19:31:16 +0000 X-Inumbo-ID: ef98d58a-b007-11ea-b7bb-bc764e2007e4 Received: from mga14.intel.com (unknown [192.55.52.115]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ef98d58a-b007-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 19:31:12 +0000 (UTC) IronPort-SDR: 0gE+PDsxsLCGKbCNedJVdA+OJceAKpvGUH75tEsKfbR+CA30T1IHCAUtMkNwjpaamQaTP9UfDd BHfd09jFbnXg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2020 12:31:10 -0700 IronPort-SDR: FHsQGahyx7EL1YEKfar76d9mA91IkHzGkoCSa8BM3nyjY7OxEbXpjZYOpe0LFGZMzMWRzQnoN/ Ke5d4Fl+Y7iw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,519,1583222400"; d="scan'208";a="291175270" Received: from hcwong-mobl2.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.212.64.215]) by orsmga002.jf.intel.com with ESMTP; 16 Jun 2020 12:31:08 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes Date: Tue, 16 Jun 2020 12:31:06 -0700 Message-Id: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been observed due to a mm-lock order violation while copying the HVM CPU context from the parent. This issue has been identified to be due to hap_update_paging_modes getting a lock on the gfn using get_gfn. This call also creates a shared entry in the fork's memory map for the cr3 gfn. The function later calls hap_update_cr3 while holding the paging_lock, which results in the lock-order violation in vmx_load_pdptrs when it tries to unshare the above entry. This issue has not affected VMs running other OS's as a call to vmx_load_pdptrs is benign if PAE is not enabled or if EFER_LMA is set and returns before trying to unshare and map the page. Using get_gfn_type to get a lock on the gfn avoids this problem as we can populate the fork's gfn with a copied page instead of a shared entry if its needed, thus avoiding the lock order violation while holding paging_lock. Signed-off-by: Tamas K Lengyel --- The bug seems to have been present since commit 4cb6c4f4941, only discovered now due to the heavy use of mem_sharing with VM forks. As this is a simple bug-fix it would be nice to include it in the 4.14 release. --- xen/arch/x86/mm/hap/hap.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c index 7f84d0c6ea..9ae4c3ae6e 100644 --- a/xen/arch/x86/mm/hap/hap.c +++ b/xen/arch/x86/mm/hap/hap.c @@ -748,12 +748,19 @@ static void hap_update_paging_modes(struct vcpu *v) struct domain *d = v->domain; unsigned long cr3_gfn = v->arch.hvm.guest_cr[3] >> PAGE_SHIFT; p2m_type_t t; + p2m_query_t q = P2M_ALLOC; - /* We hold onto the cr3 as it may be modified later, and - * we need to respect lock ordering. No need for - * checks here as they are performed by vmx_load_pdptrs - * (the potential user of the cr3) */ - (void)get_gfn(d, cr3_gfn, &t); + /* + * We hold onto the cr3 as it may be modified later, and + * we need to respect lock ordering. Unshare here if we have to as to avoid + * a lock-order violation later while we are holding the paging_lock. + * Further checks are performed by vmx_load_pdptrs (the potential user of + * the cr3). + */ + if ( hvm_pae_enabled(v) && !hvm_long_mode_active(v) ) + q |= P2M_UNSHARE; + + (void)get_gfn_type(d, cr3_gfn, &t, q); paging_lock(d); v->arch.paging.mode = hap_paging_get_mode(v); -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 20:11:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 20:11:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlHvV-0002wZ-Vj; Tue, 16 Jun 2020 20:11:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlHvV-0002w7-A4 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 20:11:21 +0000 X-Inumbo-ID: 87a6fd48-b00d-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 87a6fd48-b00d-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 20:11:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eZS8zH6HiF4/jh+lKZhYJEev/Br5SI+LOu/9kN0OiFs=; b=FadgZW5InN3ERrigELjff2hKW 1tNDztsm1PaD8XHx4RTDx9cExNgK01544lRIkZSxL50wVP9JbaFrGiz6vg8LJKfB/ErQZ78t+y+7R PTcl3HfxMZDIl4iY67U1llwfUPYhsSYz07bg7dV9hBdOamt3m9UQltJ30PdAMDf8mJV7w=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlHvO-0006Ly-Bc; Tue, 16 Jun 2020 20:11:14 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlHvN-0005Fl-MA; Tue, 16 Jun 2020 20:11:13 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlHvN-0000Dt-LV; Tue, 16 Jun 2020 20:11:13 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151149: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-amd64-qemuu-nested-intel:xen-boot/l1:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:xen-boot/l1:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=7d3660e79830a069f1848bb4fa1cdf8f666424fb X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Tue, 16 Jun 2020 20:11:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151149 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151149/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151065 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151065 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151065 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass version targeted for testing: qemuu 7d3660e79830a069f1848bb4fa1cdf8f666424fb baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 3 days Testing same since 151101 2020-06-14 08:32:51 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Alex Bennée Alex Williamson Alexander Bulekov Anthony PERARD Babu Moger Cathy Zhang Colin Xu Cédric Le Goater David Carlier David Gibson Edgar E. Iglesias Eric Auger Evgeny Yakovlev Igor Mammedov Janne Grunau Jon Doron Joseph Myers Julio Faracco Leonid Bloch Leonid Bloch Like Xu Liran Alon Maciej S. Szmigiero Markus Armbruster Masahiro Yamada Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Roman Bolshakov Roman Kagan Sai Pavan Boddu Thomas Huth WangBowen Wei Huang jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 2277 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 16 20:16:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 20:16:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlI0L-00038F-Jf; Tue, 16 Jun 2020 20:16:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlI0K-00037i-KU for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 20:16:20 +0000 X-Inumbo-ID: 3c966126-b00e-11ea-b94a-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3c966126-b00e-11ea-b94a-12813bfff9fa; Tue, 16 Jun 2020 20:16:18 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 49490208B3; Tue, 16 Jun 2020 20:16:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592338577; bh=zmH4JSlt9cywnDKhObbKR2vrK/IfOElB1ppkvvzcKQc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=DevMpiVp3dhXuh4jWdE29eCx3s5S5AfgXWRF15GTHzv9m/Cos65TMlLCbSH3scoLF ohpQwG36Bn/XbnWesFSNEt6ubG6Bc24dBAeAO26J5zJjcqqANjWE/OzTFxzmpsfjEs vTOOrWAp/obMezn+jN/dt1mQKZ0SqFo1E4p3/YqE= Date: Tue, 16 Jun 2020 13:16:10 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Bobby Eshleman Subject: Re: [RFC XEN PATCH 00/23] xen: beginning support for RISC-V In-Reply-To: <20200616035100.GA19383@piano> Message-ID: References: <20200616035100.GA19383@piano> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "dan@dlrobertson.com" , "julien@xen.org" , "wl@xen.org" , "konrad.wilk@oracle.com" , "George.Dunlap@eu.citrix.com" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "bobby.eshleman@starlab.io" , "sstabellini@kernel.org" , Alistair Francis , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 15 Jun 2020, Bobby Eshleman wrote: > On Tue, Jun 16, 2020 at 01:10:17AM +0000, Alistair Francis wrote: > > On Mon, 2020-06-15 at 18:03 -0700, Stefano Stabellini wrote: > > > Any updates? I am looking forward to this :-) > > > > It has been on a slow burn since I became a new dad (shortly after the RFC). > I've gradually regained free time, and so I've been able to change that > slow burn to a moderate burn in the last couple weeks. > > Most of my progress has been around build environment improvements. I've done > some work stripping it down to the bare minimum required to build a new arch > and rooting the commit history from there, and some work with incorporating it > into the gitlab CI, containerizing the build and QEMU run, etc... > > As far as hypervisor status: I'm just about done with incorporating the boot > module FDT parsing code, extracting kernel info and ram regions > (taken/generalized from arch/arm), plus implementing the arch-specific pieces > of domain_create(). > > On the verge of being able to dive into a guest kernel and see what breaks > first :) > > I'm expected to commit an extra day or two per week in the next month or so at > Vates, so this will considerably bump up my cadence in comparison to the last > few months. Great to hear and congratulations! I'll stay tuned. Next time I'll try to rebuild and run your series on QEMU, I might ask you for some help with the setup. > > FYI, I would like to talk more about RISC-V Xen at the Xen Virtual > > summit. I'll put it forward as a BoF subject. > > > > I haven't worked on this, although the RISC-V Hypervisor spec is > > progressing towards ratification. > > > > Alistair > > > > That would be great :) Indeed! From xen-devel-bounces@lists.xenproject.org Tue Jun 16 20:16:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 20:16:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlI0Z-0003BA-SD; Tue, 16 Jun 2020 20:16:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlI0Y-0003At-Ak for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 20:16:34 +0000 X-Inumbo-ID: 4525b094-b00e-11ea-b94a-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4525b094-b00e-11ea-b94a-12813bfff9fa; Tue, 16 Jun 2020 20:16:32 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: D9w8eurEA+OORasAjcLOUEtPX5ainqdE0/241ppbMrL6rsB+6+FTBzcQLgvBDNDJxhr2cikNYL x8U3KKPvs5YghfchNld89eX+4FPrn3oYxoyGzgfTj0v9w0Qyw+ACBn4H8Vxi8Pz8sBCMwtb7qr 22UoeJPgHSoXdrPS9D0JlYAmSv2qAm0LLvGPJMgCCXkr1O0caCvSq2njkOSak+1vz2DF/k0zC8 +hqWKBB59HNSst4j2KsVvz6+XNdsO69p5f+sdmVjOjyuxllXdQJ9uVW/eDLxj5CjSAFTLWKnSL /rA= X-SBRS: 2.7 X-MesageID: 20988688 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,519,1583211600"; d="scan'208";a="20988688" Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> From: Andrew Cooper Message-ID: Date: Tue, 16 Jun 2020 21:16:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Ian Jackson , George Dunlap , Jun Nakajima , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 19:47, Michał Leszczyński wrote: > ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com napisał(a): > >> Are there any restrictions on EPT being enabled in the first place?  I'm >> not aware of any, and in principle we could use this functionality for >> PV guests as well (using the CPL filter).  Therefore, I think it would >> be helpful to not tie the functionality to HVM guests, even if that is >> the only option enabled to start with. > I think at the moment it's not required to have EPT. This patch series doesn't use any translation feature flags, so the output address is always a machine physical address, regardless of context. I will check if it could be easily used with PV. If its trivial to add PV support then please do.  If its not, then don't feel obliged, but please do at least consider how PV support might look in the eventual feature. (Generally speaking, considering "how would I make this work in other modes where it is possible" leads to a better design.) >> The buffer mapping and creation logic is fairly problematic.  Instead of >> fighting with another opencoded example, take a look at the IOREQ >> server's use of "acquire resource" which is a mapping interface which >> supports allocating memory on behalf of the guest, outside of the guest >> memory, for use by control tools. >> >> I think what this wants is a bit somewhere in domain_create to indicate >> that external tracing is used for this domain (and allocate whatever >> structures/buffers are necessary), acquire resource to map the buffers >> themselves, and a domctl for any necessary runtime controls. >> > I will check this out, this sounds like a good option as it would remove lots of complexity from the existing ipt_enable domctl. Xen has traditionally opted for a "and turn this extra thing on dynamically" model, but this has caused no end of security issues and broken corner cases. You can see this still existing in the difference between XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being required to chose the number of vcpus for the domain) and we're making good progress undoing this particular wart (before 4.13, it was concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by issuing other hypercalls between these two). There is a lot of settings which should be immutable for the lifetime of the domain, and external monitoring looks like another one of these.  Specifying it at createdomain time allows for far better runtime behaviour (you are no longer in a situation where the first time you try to turn tracing on, you end up with -ENOMEM because another VM booted in the meantime and used the remaining memory), and it makes for rather more simple code in Xen itself (at runtime, you can rely on it having been set up properly, because a failure setting up will have killed the domain already). >> What semantics do you want for the buffer becoming full?  Given that >> debugging/tracing is the goal, I presume "pause vcpu on full" is the >> preferred behaviour, rather than drop packets on full? >> > Right now this is a ring-style buffer and when it would become full it would simply wrap and override the old data. How does the consumer spot that the data has wrapped?  What happens if data starts getting logged, but noone is listening?  What happens if the consumer exits/crashes/etc and stops listening as a consequence? It's fine to simply state what will happen, and possibly even "don't do that then", but the corner cases do at least need thinking about. >> When this subject was broached on xen-devel before, one issue was the >> fact that all actions which are intercepted don't end up writing any >> appropriate packets.  This is perhaps less of an issue for this example, >> where the external agent can see VMExits in the trace, but it still >> results in missing information.  (It is a major problem for PT within >> the guest, and needs Xen's intercept/emulation framework being updated >> to be PT-aware so it can fill in the same packets which hardware would >> have done for equivalent actions.) > Ok, this sounds like a hard issue. Could you point out what could be the particular problematic cases? For instance, if something would alter EIP/RIP or CR3 then I belive it would still be recorded in PT trace (i.e. these values will be logged on VM entry). One easy case is what happens on a Pstate transition while in the hypervisor.  That won't be recorded.  (Perhaps this bit of data isn't terribly interesting.) More complicated cases exist when you start combining Xen features.  E.g. with Introspection, a function pointer call which happens to set a pagetable access bit bit which is write-protected will trap for emulation, and be completed by the emulator (this is far faster than pausing the domain, changing EPT permissions, singlestepping the vcpu, then reinstating reduced EPT permissions). In this case, no TIP would be generated unless the x86 emulator were updated to know how to do this. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 16 20:50:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 20:50:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlIXO-0006Wx-Jj; Tue, 16 Jun 2020 20:50:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlIXM-0006WR-TZ for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 20:50:28 +0000 X-Inumbo-ID: 027a768a-b013-11ea-bb8b-bc764e2007e4 Received: from mail-oo1-xc42.google.com (unknown [2607:f8b0:4864:20::c42]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 027a768a-b013-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 20:50:28 +0000 (UTC) Received: by mail-oo1-xc42.google.com with SMTP id q188so4371162ooq.4 for ; Tue, 16 Jun 2020 13:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xXHB8t4A+Ri4ilG1DPgnSLVHP5CWTMD30dEOb8LHm5U=; b=gA5W0tze/lqfRV4puC1P1e7jLMDS/YA0jqmAv7FQpbcRf4Fk7TrMPBXZ0vY1tqRgE2 lQyReomy9LHjmUFUR2iO2pA48Og0zLIyRvTfDDOW7ev8wf469I+AUTyPgPh1kHDhf7XI hlUZ7iGE/WCevNHPTB2P2QqHdVafnQKONRU1mK4iEC7EIW4bZc85qxWSu08BQ5qU0FMw uvCKjCw/wz5NqYkNrp8GNMPvTLa7iNuzwG0fBQZhBUZMAlBFkyE0dWQJ7smDKdpmP5KB 3ZvZ1+Qfcc+FBpRQjmccsxGhpbwDm7KvQYeJzcuk/Ro/2jFfZsaiQ3hs9zJw+7KlXi5t +Sgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xXHB8t4A+Ri4ilG1DPgnSLVHP5CWTMD30dEOb8LHm5U=; b=fUb3WR4BcWcfh6R1v+ERbIo4h27f6KHBCdzAsZzGSPgYXnGXNCj2s/EHrLb/9m9nUD n4hzj/NnuMm98+IHVuTuXP5dm//33WlDQlS8O+KxGpeN9SDtT4G7HQBKmVCn9hcyGmb8 sthghKIKHFSnVKO1ZcLAqGF85aOHMAnqGoFhCjDubnNXMp3B/0/WhnFK7V8X7jZD/aQx LWpI8D9kopSW5EUVIIm5YRAs1joACTXTXL4xzt/ppNb/OM3zZjqnpGephCHmAOg1MJSI i0yHRlb1/suQ5yy9pY/g5jXtOH/XdQ3cYd18N8aQs1JkWeV02TRAB58PhH0E1kBq27qS 8CVA== X-Gm-Message-State: AOAM531xv7Z2fYPbAXhpzMO9WxLkt0A/WdqbSoFPs55I+ze3uApaxpI0 O8J2sS0c4BZ1Hz0tgs0xaVyZC5heaS4eBuS4BiE2Gg== X-Google-Smtp-Source: ABdhPJwCa2MKVG+6cU5mikK5F0XqNYrEKqqHRukOZl8JO9yt5RiyrhV6w+1VTLTEt70odCSzsFiH/JjH6ZiMIpTaR+k= X-Received: by 2002:a4a:5209:: with SMTP id d9mr3959114oob.28.1592340627392; Tue, 16 Jun 2020 13:50:27 -0700 (PDT) MIME-Version: 1.0 References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> <20200609152233.039cfc86.olaf@aepfle.de> <20200610191657.GA69414@deinos.phlegethon.org> <20200611211004.11e38f8f.olaf@aepfle.de> In-Reply-To: <20200611211004.11e38f8f.olaf@aepfle.de> From: Christopher Clark Date: Tue, 16 Jun 2020 13:50:15 -0700 Message-ID: Subject: Re: [PATCH v1] kdd: remove zero-length arrays To: Olaf Hering Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Tim Deegan , Ian Jackson , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 11, 2020 at 12:12 PM Olaf Hering wrote: > > Am Wed, 10 Jun 2020 20:16:57 +0100 > schrieb Tim Deegan : > > > How tedious. > > Indeed. This compiles for me as well: just a nudge on this; it would be nice to get a patch into the tree since the build failure affects master builds of Xen in OpenEmbedded now. Christopher > > --- orig/kdd.h 2020-06-08 17:40:05.000000000 +0000 > +++ kdd.h 2020-06-11 19:00:44.234364040 +0000 > @@ -68,7 +68,6 @@ > uint16_t len; /* Payload length, excl. header and trailing byte */ > uint32_t id; /* Echoed in responses */ > uint32_t sum; /* Unsigned sum of all payload bytes */ > - uint8_t payload[0]; > } PACKED kdd_hdr; > > #define KDD_PKT_CMD 0x0002 /* Debugger commands (and replies to them) */ > @@ -323,7 +322,7 @@ > kdd_msg msg; > kdd_reg reg; > kdd_stc stc; > - uint8_t payload[0]; > + uint8_t payload[65536]; > }; > } PACKED kdd_pkt; > > --- orig/kdd.c 2020-06-08 17:40:05.000000000 +0000 > +++ kdd.c 2020-06-11 19:08:36.775724640 +0000 > @@ -79,11 +79,11 @@ > /* State of the debugger stub */ > typedef struct { > union { > - uint8_t txb[sizeof (kdd_hdr) + 65536]; /* Marshalling area for tx */ > + uint8_t txb[sizeof (kdd_hdr) + 0xffff]; /* Marshalling area for tx */ > kdd_pkt txp; /* Also readable as a packet structure */ > }; > union { > - uint8_t rxb[sizeof (kdd_hdr) + 65536]; /* Marshalling area for rx */ > + uint8_t rxb[sizeof (kdd_hdr)]; /* Marshalling area for rx */ > kdd_pkt rxp; /* Also readable as a packet structure */ > }; > unsigned int cur; /* Offset into rx where we'll put the next byte */ > > Olaf From xen-devel-bounces@lists.xenproject.org Tue Jun 16 20:57:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 20:57:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlIe1-0006l5-C9; Tue, 16 Jun 2020 20:57:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlIe0-0006l0-Ad for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 20:57:20 +0000 X-Inumbo-ID: f751d194-b013-11ea-b94f-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f751d194-b013-11ea-b94f-12813bfff9fa; Tue, 16 Jun 2020 20:57:19 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E245E207DD; Tue, 16 Jun 2020 20:57:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592341038; bh=Brg6lcDmWmGFAdocTb50l+iamy8nImIVbXsNyMt2UMQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=knFYrKdEqTayb8ciCvaoWT8LOB85KiNKGWoe1PuImaB82y4GlUpSyoCTLHPtEJc6X B5ro9eyOmugU+xQv0D0+Hn/FxfS21tlDL0pKQUNzC/hNwVAHVpaCkqnrs/SCFveldp KpsKh0q4A/7vLIratzoTQLf6DLpVVVhaFKkyKjdg= Date: Tue, 16 Jun 2020 13:57:17 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches In-Reply-To: <35c8373f-b691-d95e-17de-021c72faf216@xen.org> Message-ID: References: <20200613184132.11880-1-julien@xen.org> <35c8373f-b691-d95e-17de-021c72faf216@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org, roger.pau@citrix.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 16 Jun 2020, Julien Grall wrote: > On 16/06/2020 02:00, Stefano Stabellini wrote: > > On Sat, 13 Jun 2020, Julien Grall wrote: > > > From: Julien Grall > > > > > > The documentation of pvcalls suggests there is padding for 32-bit x86 > > > at the end of most the structure. However, they are not described in > > > in the public header. > > > > > > Because of that all the structures would be 32-bit aligned and not > > > 64-bit aligned for 32-bit x86. > > > > > > For all the other architectures supported (Arm and 64-bit x86), the > > > structure are aligned to 64-bit because they contain uint64_t field. > > > Therefore all the structures contain implicit padding. > > > > > > The paddings are now corrected for 32-bit x86 and written explicitly for > > > all the architectures. > > > > > > While the structure size between 32-bit and 64-bit x86 is different, it > > > shouldn't cause any incompatibility between a 32-bit and 64-bit > > > frontend/backend because the commands are always 56 bits and the padding > > > are at the end of the structure. > > > > > > As an aside, the padding sadly cannot be mandated to be 0 as they are > > > already present. So it is not going to be possible to use the padding > > > for extending a command in the future. > > > > > > Signed-off-by: Julien Grall > > > > > > --- > > > Changes in v3: > > > - Use __i386__ rather than CONFIG_X86_32 > > > > > > Changes in v2: > > > - It is not possible to use the same padding for 32-bit x86 and > > > all the other supported architectures. > > > --- > > > docs/misc/pvcalls.pandoc | 18 ++++++++++-------- > > > xen/include/public/io/pvcalls.h | 14 ++++++++++++++ > > > 2 files changed, 24 insertions(+), 8 deletions(-) > > > > > > diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc > > > index 665dad556c39..caa71b36d78b 100644 > > > --- a/docs/misc/pvcalls.pandoc > > > +++ b/docs/misc/pvcalls.pandoc > > > @@ -246,9 +246,9 @@ The format is defined as follows: > > > uint32_t domain; > > > uint32_t type; > > > uint32_t protocol; > > > - #ifdef CONFIG_X86_32 > > > + #ifndef __i386__ > > > uint8_t pad[4]; > > > - #endif > > > + #endif > > > > > > Hi Julien, > > > > Thank you for doing this, and sorry for having missed v2 of this patch, I > > should have replied earlier. > > > > The intention of the #ifdef blocks like: > > > > #ifdef CONFIG_X86_32 > > uint8_t pad[4]; > > #endif > > > > in pvcalls.pandoc was to make sure that these structs would be 64bit > > aligned on x86_32 too. > > > > I realize that the public header doesn't match, but the spec is the > > "master copy". > > So far, the public headers are the defacto official ABI. So did you mark the > pvcall header as just a reference? No, there is no document that says that the canonical copy of the interface is pvcalls.pandoc. However, it was clearly spelled out from the start on xen-devel (see below.) In fact, if you notice, this is the first document under docs/misc that goes into this level of details in describing a new PV protocol. Also note the title of the document which is "PV Calls Protocol version 1". In reply to Jan: > A public header can't be "fixed" if it may already be in use by > anyone. We can only do as Andrew and you suggest (mandate textual > descriptions to be "the ABI") when we do so for _new_ interfaces from > the very beginning, making clear that the public header (if any) > exists just for reference. What if somebody took the specification of the interface from pvcalls.pandoc and wrote their own headers and code? It is definitely possible. At the time, it was clarified that the purpose of writing such a detailed specification document was that the document was the specification :-) See for instance this email (there are others): https://marc.info/?l=linux-kernel&m=149815619513930&w=2 """ This was done differently in the past, but now that we have a formal process, a person in charge of new PV drivers reviews, and design documents with clearly spelled out ABIs, I consider the design docs under docs/misc as the official specification. We don't need headers anymore, they are redundant. In fact, we cannot have two specifications, and the design docs are certainly the official ones (we don't want the specs to be written as header files in C). To me, the headers under xen/include/public/io/ are optional helpers. It doesn't matter what's in there, or if frontends and backends use them or not. There is really an argument for removing those headers, because they might get out of sync with the spec by mistake, and in those cases, then we really end up with two specifications for the same protocol. I would be in favor of `git rm'ing all files under xen/include/public/io/ for which we have a complete design doc under docs/misc. """ (Andy and Roger agreed on the thread if you look at the follow-up emails.) From xen-devel-bounces@lists.xenproject.org Tue Jun 16 21:25:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 21:25:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJ4h-0000rf-J3; Tue, 16 Jun 2020 21:24:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJ4g-0000ra-MM for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 21:24:54 +0000 X-Inumbo-ID: d1d0d132-b017-11ea-bca7-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d1d0d132-b017-11ea-bca7-bc764e2007e4; Tue, 16 Jun 2020 21:24:54 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3A02A2080D; Tue, 16 Jun 2020 21:24:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592342693; bh=8GZ3guWEpsb/L9wBXSoQdxYJ5sSygFGBEriRoxmrgUc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=soWQJSDHCE1ry72/QQH5eTg7/uZGgcwqhnqbSE/cplqrOEkkEo4BIPR2n1tYQReu0 yrCRnZOsaoWqnm4d+pp5xKNQSfOHq2IY8+WXWa0IMZXI9rnQEP9OGQ6w0ChGP146b1 e7wxYBx4395qsDyqPPCfazLx78TdCy+8kiqUgWWo= Date: Tue, 16 Jun 2020 14:24:52 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH 1/2] xen/arm: entry: Place a speculation barrier following an ret instruction In-Reply-To: <20200616175913.7368-2-julien@xen.org> Message-ID: References: <20200616175913.7368-1-julien@xen.org> <20200616175913.7368-2-julien@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, paul@xen.org, Andre.Przywara@arm.com, Julien Grall , Bertrand.Marquis@arm.com, security@xenproject.org, xen-devel@lists.xenproject.org, Volodymyr_Babchuk@epam.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 16 Jun 2020, Julien Grall wrote: > From: Julien Grall > > Some CPUs can speculate past a RET instruction and potentially perform > speculative accesses to memory before processing the return. > > There is no known gadget available after the RET instruction today. > However some of the registers (such as in check_pending_guest_serror()) > may contain a value provided the guest. ^ by > In order to harden the code, it would be better to add a speculation > barrier after each RET instruction. The performance is meant to be > negligeable as the speculation barrier is not meant to be archicturally > executed. > > Note that on arm32, the ldmia instruction will act as a return from the > function __context_switch(). While the whitepaper doesn't suggest it is > possible to speculate after the instruction, add preventively a > speculation barrier after it as well. > > This is part of the work to mitigate straight-line speculation. > > Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini I did a compile-test on the patch too. > --- > > I am still unsure whether we preventively should add a speculation barrier > preventively after all the RET instructions in arm*/lib/. The smc call be > taken care in a follow-up patch. SMC is great to have but it seems to be overkill to do the ones under lib/. > --- > xen/arch/arm/arm32/entry.S | 1 + > xen/arch/arm/arm64/entry.S | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/xen/arch/arm/arm32/entry.S b/xen/arch/arm/arm32/entry.S > index b228d44b190c..bd54fc43558b 100644 > --- a/xen/arch/arm/arm32/entry.S > +++ b/xen/arch/arm/arm32/entry.S > @@ -442,6 +442,7 @@ ENTRY(__context_switch) > > add r4, r1, #VCPU_arch_saved_context > ldmia r4, {r4 - sl, fp, sp, pc} /* Load registers and return */ > + sb > > /* > * Local variables: > diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S > index 175ea2981e72..b37d8fe09dc2 100644 > --- a/xen/arch/arm/arm64/entry.S > +++ b/xen/arch/arm/arm64/entry.S > @@ -522,6 +522,7 @@ abort_guest_exit_end: > cset x19, ne > > ret > + sb > ENDPROC(check_pending_guest_serror) > > /* > @@ -583,6 +584,7 @@ ENTRY(__context_switch) > ldr lr, [x8] > mov sp, x9 > ret > + sb > > /* > * Local variables: > -- > 2.17.1 > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 21:32:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 21:32:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJBh-0001k9-Bq; Tue, 16 Jun 2020 21:32:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJBg-0001k4-Cr for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 21:32:08 +0000 X-Inumbo-ID: d3eecb76-b018-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d3eecb76-b018-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 21:32:07 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id j10so155430wrw.8 for ; Tue, 16 Jun 2020 14:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bbz7zOoIy337G+1SGLsqaVhTrFOdE+Yf7K/dfCuRs/Y=; b=ZYIi+dQC4hdwvsBnGanamlYlCuTHULL5eSdfLxA91lTgkXgQlzAF2iv6wnjRdni/MN blflkRTfLy80iJk9lXxBPTrnhtVNnBjwlQapePycRPsNg9mOr3A60mrToN8aJrGM3Icy BAr1jzmIOhLKPSYLig0WbTUwwDbDujUGGPqlEHc/vhxl/EeXjaDf2XbfuRhytQIYwpyC QoPS9mRC083BX4gKB7WB7i5MpPw6MksACI21PzGjAfPPpqPddCbBANy0NlSa3UreHf5H dz4VBB6WK+TDykGKIF8GkDrF4+Hn87uZu0Qha4L3DMEmy3UYCo+vmNqI7xjeDadchzG8 xU2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bbz7zOoIy337G+1SGLsqaVhTrFOdE+Yf7K/dfCuRs/Y=; b=kPWRgOV3UmMyGwR0Ce2GTHBOpcWV36fdDWBETL2uFtu9M6oihYoh9tC9Py+WTrBbpQ 0SBdg9/6rP1mJI0oaFsKm96rEpb/cJFFeBK+ViHUmoOh49Qs/KtazZOd7hep5LzfK2pj uEdoFtnho6BlaIaDs8KOH6WWnn3afu2L2w9VbT02lEvZZNRCeVg2punBtATdTMhR6Fws 9HP20sZMtZ1ab+Nc2kbzDG+eYKYegKDJIGEhmw86D8ufPNjeT8PvD98+vu54Fs6ORiqo c4DU3H3Vga1tqjQ7bzctWq9VARN5mLmSGfuY134ewcd8+ljfI9GnNGzbyAaYahUPE2pd vm9Q== X-Gm-Message-State: AOAM531DySTWiWOc9NGlvzACJQiRCvZg/THZJXZ752CQWiesGwn7r9V9 7pfg2B2R+0WEDgxpM68Knhib5t6kFPXjqc3c514= X-Google-Smtp-Source: ABdhPJz31/tpJkRxBSJhdm9rc3q6KemybgUsS47j/u/6ubu7LDZmyAckJIIYRlmOAUaPYIrXlhqnUssQGf00KMdtOTI= X-Received: by 2002:adf:f64e:: with SMTP id x14mr5213028wrp.426.1592343126573; Tue, 16 Jun 2020 14:32:06 -0700 (PDT) MIME-Version: 1.0 References: <20200613184132.11880-1-julien@xen.org> <35c8373f-b691-d95e-17de-021c72faf216@xen.org> In-Reply-To: From: Julien Grall Date: Tue, 16 Jun 2020 22:31:55 +0100 Message-ID: Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , Paul Durrant , Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 16 Jun 2020 at 21:57, Stefano Stabellini wrote: > > On Tue, 16 Jun 2020, Julien Grall wrote: > > On 16/06/2020 02:00, Stefano Stabellini wrote: > > > On Sat, 13 Jun 2020, Julien Grall wrote: > > > > From: Julien Grall > > > > > > > > The documentation of pvcalls suggests there is padding for 32-bit x86 > > > > at the end of most the structure. However, they are not described in > > > > in the public header. > > > > > > > > Because of that all the structures would be 32-bit aligned and not > > > > 64-bit aligned for 32-bit x86. > > > > > > > > For all the other architectures supported (Arm and 64-bit x86), the > > > > structure are aligned to 64-bit because they contain uint64_t field. > > > > Therefore all the structures contain implicit padding. > > > > > > > > The paddings are now corrected for 32-bit x86 and written explicitly for > > > > all the architectures. > > > > > > > > While the structure size between 32-bit and 64-bit x86 is different, it > > > > shouldn't cause any incompatibility between a 32-bit and 64-bit > > > > frontend/backend because the commands are always 56 bits and the padding > > > > are at the end of the structure. > > > > > > > > As an aside, the padding sadly cannot be mandated to be 0 as they are > > > > already present. So it is not going to be possible to use the padding > > > > for extending a command in the future. > > > > > > > > Signed-off-by: Julien Grall > > > > > > > > --- > > > > Changes in v3: > > > > - Use __i386__ rather than CONFIG_X86_32 > > > > > > > > Changes in v2: > > > > - It is not possible to use the same padding for 32-bit x86 and > > > > all the other supported architectures. > > > > --- > > > > docs/misc/pvcalls.pandoc | 18 ++++++++++-------- > > > > xen/include/public/io/pvcalls.h | 14 ++++++++++++++ > > > > 2 files changed, 24 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc > > > > index 665dad556c39..caa71b36d78b 100644 > > > > --- a/docs/misc/pvcalls.pandoc > > > > +++ b/docs/misc/pvcalls.pandoc > > > > @@ -246,9 +246,9 @@ The format is defined as follows: > > > > uint32_t domain; > > > > uint32_t type; > > > > uint32_t protocol; > > > > - #ifdef CONFIG_X86_32 > > > > + #ifndef __i386__ > > > > uint8_t pad[4]; > > > > - #endif > > > > + #endif > > > > > > > > > Hi Julien, > > > > > > Thank you for doing this, and sorry for having missed v2 of this patch, I > > > should have replied earlier. > > > > > > The intention of the #ifdef blocks like: > > > > > > #ifdef CONFIG_X86_32 > > > uint8_t pad[4]; > > > #endif > > > > > > in pvcalls.pandoc was to make sure that these structs would be 64bit > > > aligned on x86_32 too. > > > > > > I realize that the public header doesn't match, but the spec is the > > > "master copy". > > > > So far, the public headers are the defacto official ABI. So did you mark the > > pvcall header as just a reference? > > No, there is no document that says that the canonical copy of the > interface is pvcalls.pandoc. However, it was clearly spelled out from > the start on xen-devel (see below.) > In fact, if you notice, this is the > first document under docs/misc that goes into this level of details in > describing a new PV protocol. Also note the title of the document which > is "PV Calls Protocol version 1". While I understand this may have been the original intention, you can't expect a developer to go through the archive to check whether he/she should trust the header of the document. > > > In reply to Jan: > > A public header can't be "fixed" if it may already be in use by > > anyone. We can only do as Andrew and you suggest (mandate textual > > descriptions to be "the ABI") when we do so for _new_ interfaces from > > the very beginning, making clear that the public header (if any) > > exists just for reference. > > What if somebody took the specification of the interface from > pvcalls.pandoc and wrote their own headers and code? It is definitely > possible. As it is possible for someone to have picked the headers from Xen as in the past public/ has always been the authority. > At the time, it was clarified that the purpose of writing such > a detailed specification document was that the document was the > specification :-) At the risk of being pedantic, if it is not written in xen.git it doesn't exist ;). Anyway, no matter the decision you take here, you are going to potentially break one set of the users. I am leaning towards the header as authoritative because this has always been the case in the past and nothing in xen.git says otherwise. However I am not a user of pvcalls, so I don't really have any big incentive to go either way. For the future, I would highly suggest writing down the support decision in xen.git. This would avoid such debate on what is the authority... Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 16 21:34:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 21:34:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJE7-0001sc-Pe; Tue, 16 Jun 2020 21:34:39 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJE6-0001sR-4M for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 21:34:38 +0000 X-Inumbo-ID: 2c23758b-b019-11ea-b956-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2c23758b-b019-11ea-b956-12813bfff9fa; Tue, 16 Jun 2020 21:34:36 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 280E42085B; Tue, 16 Jun 2020 21:34:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592343275; bh=D+pdHi31E7TsCSVDQt1gYFY7mD0R1ArodcVj97a2D5E=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=FKCRw6jm+T3Fie7eB/mg5Udp9ikh/s65V+zHlt78VQEaZO/b59SlABN43c9Vyy9Qk MvlbbnRGjhfYe/NlLuWzyTkZaKe1pbNJKt9TRsMwjvlr9gVnCI6SspshZycXEa4LKq e9MqTMcLRKZaF2q18cvLJfK1Tls1uAFkJeceFUow= Date: Tue, 16 Jun 2020 14:34:34 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH 2/2] xen/arm: Mitigate straight-line speculation for SMC call In-Reply-To: <20200616175913.7368-3-julien@xen.org> Message-ID: References: <20200616175913.7368-1-julien@xen.org> <20200616175913.7368-3-julien@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, paul@xen.org, Andre.Przywara@arm.com, Julien Grall , Bertrand.Marquis@arm.com, security@xenproject.org, xen-devel@lists.xenproject.org, Volodymyr_Babchuk@epam.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 16 Jun 2020, Julien Grall wrote: > From: Julien Grall > > SMC call will update some of registers (typically only x0) depending on ^a SMC call > the arguments provided. > > Some CPUs can speculate past a SMC instruction and potentially perform > speculative access to emrmoy using the pre-call values before executing ^ memory > the SMC. > > There is no known gadget available after the SMC call today. However > some of the registers may contain values from the guest and are expected > to be updated by the SMC call. > > In order to harden the code, it would be better to prevent straight-line > speculation from an SMC. Architecturally executing the speculation ^ a? any? > barrier after every SMC can be rather expensive (particularly on core > not SB). Therefore we want to mitigate it diferrently: ^ not SB capable? ^ differently > > * For arm_smccc_1_0_smc, we can avoid a speculation barrier right > after the SMC instruction and instead rely on the one after eret. ^ ret > * For arm_smccc_1_1_smc, we can place a B instruction after the SMC > instruction to skip the barrier. > > Note that arm_smccc_1_0_smc version on arm32 is just an alias to > arm_smccc_1_1_smc. > > Note that no speculation barrier has been added after the SMC > instruction in arm64/entry.S. This is fine because the call is not > expected to modify any registers. So straight-line speculation doesn't > matter. > > Signed-off-by: Julien Grall I couldn't spot any issues with the patch and I compile-tested it. > --- > > Note this hasn't been vetted by Arm but they are using the same > sort of mitigation for blr. So I am quite confident this could do the > trick. Noted > --- > xen/arch/arm/arm64/smc.S | 1 + > xen/include/asm-arm/smccc.h | 13 +++++++++++++ > xen/include/asm-arm/system.h | 8 ++++++++ > 3 files changed, 22 insertions(+) > > diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S > index b0752be57e8f..e0a3106dd7ec 100644 > --- a/xen/arch/arm/arm64/smc.S > +++ b/xen/arch/arm/arm64/smc.S > @@ -30,3 +30,4 @@ ENTRY(__arm_smccc_1_0_smc) > stp x2, x3, [x4, #SMCCC_RES_a2] > 1: > ret > + sb > diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h > index 9d94beb3df2d..8650224923b1 100644 > --- a/xen/include/asm-arm/smccc.h > +++ b/xen/include/asm-arm/smccc.h > @@ -200,11 +200,24 @@ struct arm_smccc_res { > * We have an output list that is not necessarily used, and GCC feels > * entitled to optimise the whole sequence away. "volatile" is what > * makes it stick. > + * > + * Some of the SMC callers are passing directly values that are > + * controlled by the guest. To mitigate against straight-line > + * speculation, a speculation barrier is required. As it may be > + * expensive to architecturally execute the speculation barrier, we are > + * using a B instruction to architecturally skip it. > + * > + * Note that the speculation barrier is technically not necessary as the > + * B instruction should already block straight-line speculation. But > + * better be safe than sorry ;). Eh eh indeed :-) I think this would be one thing to consider removing depending on ARM's feedback. > */ > #define arm_smccc_1_1_smc(...) \ > do { \ > __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > asm volatile("smc #0\n" \ > + "b 1f\n" \ > + ASM_SB \ > + "1:\n" \ > __constraints(__count_args(__VA_ARGS__))); \ > if ( ___res ) \ > *___res = (typeof(*___res)){r0, r1, r2, r3}; \ > diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h > index 65d5c8e423d7..e33ff4e0fc39 100644 > --- a/xen/include/asm-arm/system.h > +++ b/xen/include/asm-arm/system.h > @@ -33,6 +33,14 @@ > #define smp_mb__before_atomic() smp_mb() > #define smp_mb__after_atomic() smp_mb() > > +/* > + * Speculative barrier > + * XXX: Add support for the 'sb' instruction > + */ > +#define ASM_SB "dsb nsh \n isb \n" Why not ';' ? Anyway it doesn't matter. > +#define sb() asm volatile(ASM_SB) > + > /* > * This is used to ensure the compiler did actually allocate the register we > * asked it for some inline assembly sequences. Apparently we can't trust > -- > 2.17.1 > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 21:49:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 21:49:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJSm-0002wD-9M; Tue, 16 Jun 2020 21:49:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJSl-0002w8-H3 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 21:49:47 +0000 X-Inumbo-ID: 4b241424-b01b-11ea-b7bb-bc764e2007e4 Received: from smtp-fw-9101.amazon.com (unknown [207.171.184.25]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4b241424-b01b-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 21:49:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1592344188; x=1623880188; h=date:from:to:cc:message-id:references:mime-version: content-transfer-encoding:in-reply-to:subject; bh=2xZWar77dXkth8tk0V/E/5zPJfDMTckPDO14OJN6cFs=; b=S0KWAit/W96xLY6edIEKux3Zl9R0ulYlurEYcb452/iVIrYLPsdgVvUr eiIA7JRiRy7K/26SH2lDtEaRDHr8AtS7RkrkG+Wmz3R26zaeF5cq/kLQo Ja+nDsTbQg25cN36o2n41AdEhrYSVSz0y6f96V4lPNSp2NMyNYyCmw1hN g=; IronPort-SDR: mrYnVTXGTnnqHewBUIddvzzRXlflYMjMyxE96i0WnUJPOgd3L5PuAQgZhdT+1V4jG9PhbPquY9 XRYaFMbAvvQw== X-IronPort-AV: E=Sophos;i="5.73,519,1583193600"; d="scan'208";a="44534346" Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-87a10be6.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 16 Jun 2020 21:49:43 +0000 Received: from EX13MTAUEE002.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-87a10be6.us-west-2.amazon.com (Postfix) with ESMTPS id 8C216A07C3; Tue, 16 Jun 2020 21:49:41 +0000 (UTC) Received: from EX13D08UEE004.ant.amazon.com (10.43.62.182) by EX13MTAUEE002.ant.amazon.com (10.43.62.24) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 16 Jun 2020 21:49:26 +0000 Received: from EX13MTAUEA002.ant.amazon.com (10.43.61.77) by EX13D08UEE004.ant.amazon.com (10.43.62.182) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 16 Jun 2020 21:49:25 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.61.169) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 16 Jun 2020 21:49:25 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 872B240139; Tue, 16 Jun 2020 21:49:25 +0000 (UTC) Date: Tue, 16 Jun 2020 21:49:25 +0000 From: Anchal Agarwal To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200604070548.GH1195@Air-de-Roger> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monn wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hello, > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > On Tue, May 19, 2020 at 11:27:50PM +0000, Anchal Agarwal wrote: > > > From: Munehisa Kamata > > > > > > S4 power transition states are much different than xen > > > suspend/resume. Former is visible to the guest and frontend drivers should > > > be aware of the state transitions and should be able to take appropriate > > > actions when needed. In transition to S4 we need to make sure that at least > > > all the in-flight blkif requests get completed, since they probably contain > > > bits of the guest's memory image and that's not going to get saved any > > > other way. Hence, re-issuing of in-flight requests as in case of xen resume > > > will not work here. This is in contrast to xen-suspend where we need to > > > freeze with as little processing as possible to avoid dirtying RAM late in > > > the migration cycle and we know that in-flight data can wait. > > > > > > Add freeze, thaw and restore callbacks for PM suspend and hibernation > > > support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND > > > events, need to implement these xenbus_driver callbacks. The freeze handler > > > stops block-layer queue and disconnect the frontend from the backend while > > > freeing ring_info and associated resources. Before disconnecting from the > > > backend, we need to prevent any new IO from being queued and wait for existing > > > IO to complete. Freeze/unfreeze of the queues will guarantee that there are no > > > requests in use on the shared ring. However, for sanity we should check > > > state of the ring before disconnecting to make sure that there are no > > > outstanding requests to be processed on the ring. The restore handler > > > re-allocates ring_info, unquiesces and unfreezes the queue and re-connect to > > > the backend, so that rest of the kernel can continue to use the block device > > > transparently. > > > > > > Note:For older backends,if a backend doesn't have commit'12ea729645ace' > > > xen/blkback: unmap all persistent grants when frontend gets disconnected, > > > the frontend may see massive amount of grant table warning when freeing > > > resources. > > > [ 36.852659] deferring g.e. 0xf9 (pfn 0xffffffffffffffff) > > > [ 36.855089] xen:grant_table: WARNING:e.g. 0x112 still in use! > > > > > > In this case, persistent grants would need to be disabled. > > > > > > [Anchal Changelog: Removed timeout/request during blkfront freeze. > > > Reworked the whole patch to work with blk-mq and incorporate upstream's > > > comments] > > > > Please tag versions using vX and it would be helpful if you could list > > the specific changes that you performed between versions. There where > > 3 RFC versions IIRC, and there's no log of the changes between them. > > > > I will elaborate on "upstream's comments" in my changelog in my next round of patches. > > Sorry for being picky, but can you please make sure your email client > properly quotes previous emails on reply. Note the lack of '>' added > to the quoted parts of your reply. That was just my outlook probably. Note taken. > > > > + } > > > + > > > break; > > > + } > > > + > > > + /* > > > + * We may somehow receive backend's Closed again while thawing > > > + * or restoring and it causes thawing or restoring to fail. > > > + * Ignore such unexpected state regardless of the backend state. > > > + */ > > > + if (info->connected == BLKIF_STATE_FROZEN) { > > > > I think you can join this with the previous dev->state == XenbusStateClosed? > > > > Also, won't the device be in the Closed state already if it's in state > > frozen? > > Yes but I think this mostly due to a hypothetical case if during thawing backend switches to Closed state. > > I am not entirely sure if that could happen. Could use some expertise here. > > I think the frontend seeing the backend in the closed state during > restore would be a bug that should prevent the frontend from > resuming. > > > > + /* Kick the backend to disconnect */ > > > + xenbus_switch_state(dev, XenbusStateClosing); > > > + > > > + /* > > > + * We don't want to move forward before the frontend is diconnected > > > + * from the backend cleanly. > > > + */ > > > + timeout = wait_for_completion_timeout(&info->wait_backend_disconnected, > > > + timeout); > > > + if (!timeout) { > > > + err = -EBUSY; > > > > Note err is only used here, and I think could just be dropped. > > > > This err is what's being returned from the function. Am I missing anything? > > Just 'return -EBUSY;' directly, and remove the top level variable. You > can also use -EBUSY directly in the xenbus_dev_error call. Anyway, not > that important. > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > + "the device may become inconsistent state"); > > > > Leaving the device in this state is quite bad, as it's in a closed > > state and with the queues frozen. You should make an attempt to > > restore things to a working state. > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > You can manually force this state, and then check that it will behave > correctly. I would expect that on a failure to disconnect from the > backend you should switch the frontend to the 'Init' state in order to > try to reconnect to the backend when possible. > >From what I understand forcing manually is, failing the freeze without disconnect and try to revive the connection by unfreezing the queues->reconnecting to backend [which never got diconnected]. May be even tearing down things manually because I am not sure what state will frontend see if backend fails to to disconnect at any point in time. I assumed connected. Then again if its "CONNECTED" I may not need to tear down everything and start from Initialising state because that may not work. So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, I don't see it getting handled in the backend then what will be backend's state? Will it still switch xenbus state to 'Closed'? If not what will frontend see, if it tries to read backend's state through xenbus_read_driver_state ? So the flow be like: Front end marks XenbusStateClosing Backend marks its state as XenbusStateClosing Frontend marks XenbusStateClosed Backend disconnects calls xen_blkif_disconnect Backend fails to disconnect, the above function returns EBUSY What will be state of backend here? Frontend did not tear down the rings if backend does not switches the state to 'Closed' in case of failure. If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend won't be calling connect(). {From reading code in frontend_changed} IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus we did not tear down anything so calling talk_to_blkback may not be needed Does that sound correct? > > > + } > > > + > > > + return err; > > > +} > > > + > > > +static int blkfront_restore(struct xenbus_device *dev) > > > +{ > > > + struct blkfront_info *info = dev_get_drvdata(&dev->dev); > > > + int err = 0; > > > + > > > + err = talk_to_blkback(dev, info); > > > + blk_mq_unquiesce_queue(info->rq); > > > + blk_mq_unfreeze_queue(info->rq); > > > + if (!err) > > > + blk_mq_update_nr_hw_queues(&info->tag_set, info->nr_rings); > > > > Bad indentation. Also shouldn't you first update the queues and then > > unfreeze them? > > Please correct me if I am wrong, blk_mq_update_nr_hw_queues freezes the queue > > So I don't think the order could be reversed. > > Regardless of what blk_mq_update_nr_hw_queues does, I don't think it's > correct to unfreeze the queues without having updated them. Also the > freezing/unfreezing uses a refcount, so I think it's perfectly fine to > call blk_mq_update_nr_hw_queues first and then unfreeze the queues. > > Also note that talk_to_blkback returning an error should likely > prevent any unfreezing, as the queues won't be updated to match the > parameters of the backend. > I think you are right here. Will send out fixes in V2 > Thanks, Roger. > Thanks, Anchal From xen-devel-bounces@lists.xenproject.org Tue Jun 16 21:57:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 21:57:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJaM-0003oa-3i; Tue, 16 Jun 2020 21:57:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlJaK-0003oV-Nf for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 21:57:36 +0000 X-Inumbo-ID: 630c1784-b01c-11ea-bb8b-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 630c1784-b01c-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 21:57:36 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id b82so4296184wmb.1 for ; Tue, 16 Jun 2020 14:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9t7wxTVD8cO8pPAaDjStEF+l/wut0mddPi/6BK89dOg=; b=qgIXO1qmu0sv2u+KrkYrTHr83dTJvCb3KiokKLazVP36YFuvp5FCoYq+3UZgGsMMY5 zjKzn8bQULro+x7/ruZB/90ZPMH0BircWMAMqrvBlwUWdw5CKfwJssTcNVXqn8mwigFm bCmha/wDnJhB4GLoyDPy42iI3017TwfUsXCX2x5Z7o8MgEPJy+LA9YYBNjxiLbtjVdCg Wh7npOMKZQg35xd1PkB5M25sFlEPY3WVZGyYOv53b8MwsmVZzZkvHAqf+Gc4FCItrPnI TOTjmxbcL3+ycAS69HLN9vHz64xBYI6+7GtKClWU0NTwbkI5PfQiVybXKzt0MQRRy07T Tjaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9t7wxTVD8cO8pPAaDjStEF+l/wut0mddPi/6BK89dOg=; b=thHSJAPpsg5TAZ/n66Arb8Z4/eOztlAoIuhw2evlORECYsFpgT4miNMw4rlhPojGQ8 xoA/2iv9lH/pX6YJkCVBORZN5PW8tVhEaJRW/2MiRHzaCtT89teSutfr1SGMvoRP5uL4 3TkTqxgAEClueznUKRAUJk33Ax+ZF/XAU244MTDqKkJle3k2Ih8wL2d6/DPA2mVFv8xi OOQDHoHHRRX6wMeztJUGXQ8zkiBiTmWRozaURQwZvj3snYzdIgyR1jR/p6kuiEGkM4LN zNQ5x2Lk8epp538BwITSCMxpXZQ4x9SP59ee44+cstU00WgzhqpClzibyTYIhVg1GLBy PmGA== X-Gm-Message-State: AOAM533v/N1NaOvPoz6Wen4fKpBuNNF42MatZKHRH4snNXIvb7x8lJeC PCbtd5LIK2rtxtauhG8m+KlDGala5i9+kIMvyDE= X-Google-Smtp-Source: ABdhPJzHtjdXH29P7nu4e/iRkQo2JI/PBKz68nlc1fAdoSZelJcYuemXhorKb6DENdA+mTr+/k+Soigc21POsIvpDBY= X-Received: by 2002:a1c:230f:: with SMTP id j15mr5421257wmj.100.1592344655157; Tue, 16 Jun 2020 14:57:35 -0700 (PDT) MIME-Version: 1.0 References: <20200616175913.7368-1-julien@xen.org> <20200616175913.7368-3-julien@xen.org> In-Reply-To: From: Julien Grall Date: Tue, 16 Jun 2020 22:57:24 +0100 Message-ID: Subject: Re: [PATCH 2/2] xen/arm: Mitigate straight-line speculation for SMC call To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Andre Przywara , Julien Grall , Bertrand Marquis , "Xen.org security team" , xen-devel , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 16 Jun 2020 at 22:34, Stefano Stabellini wrote: > > On Tue, 16 Jun 2020, Julien Grall wrote: > > From: Julien Grall > > > > SMC call will update some of registers (typically only x0) depending on > ^a SMC call > > > the arguments provided. > > > > Some CPUs can speculate past a SMC instruction and potentially perform > > speculative access to emrmoy using the pre-call values before executing > ^ memory > > > the SMC. > > > > There is no known gadget available after the SMC call today. However > > some of the registers may contain values from the guest and are expected > > to be updated by the SMC call. > > > > In order to harden the code, it would be better to prevent straight-line > > speculation from an SMC. Architecturally executing the speculation > ^ a? any? "any" might be better. > > > > barrier after every SMC can be rather expensive (particularly on core > > not SB). Therefore we want to mitigate it diferrently: > ^ not SB capable? ^ differently It might be better to say "which doesn't support ARMv8.0-SB" > > */ > > #define arm_smccc_1_1_smc(...) \ > > do { \ > > __declare_args(__count_args(__VA_ARGS__), __VA_ARGS__); \ > > asm volatile("smc #0\n" \ > > + "b 1f\n" \ > > + ASM_SB \ > > + "1:\n" \ > > __constraints(__count_args(__VA_ARGS__))); \ > > if ( ___res ) \ > > *___res = (typeof(*___res)){r0, r1, r2, r3}; \ > > diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h > > index 65d5c8e423d7..e33ff4e0fc39 100644 > > --- a/xen/include/asm-arm/system.h > > +++ b/xen/include/asm-arm/system.h > > @@ -33,6 +33,14 @@ > > #define smp_mb__before_atomic() smp_mb() > > #define smp_mb__after_atomic() smp_mb() > > > > +/* > > + * Speculative barrier > > + * XXX: Add support for the 'sb' instruction > > + */ > > +#define ASM_SB "dsb nsh \n isb \n" > > Why not ';' ? Anyway it doesn't matter. Per [1] and [2], a semicolon is not portable as some assemblers may treat anything after it as a comment. This reminds me that I have been using semicolons in entry.S. I should probably have a look to avoid them. Cheers, [1] https://developer.arm.com/docs/dui0801/d/structure-of-assembly-language-modules/syntax-of-source-lines-in-assembly-language [2] https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#AssemblerTemplate From xen-devel-bounces@lists.xenproject.org Tue Jun 16 22:31:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 22:31:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlK6b-00077d-LV; Tue, 16 Jun 2020 22:30:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlK6a-00077Y-4p for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 22:30:56 +0000 X-Inumbo-ID: 0ad29e8a-b021-11ea-b7bb-bc764e2007e4 Received: from smtp-fw-6001.amazon.com (unknown [52.95.48.154]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0ad29e8a-b021-11ea-b7bb-bc764e2007e4; Tue, 16 Jun 2020 22:30:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1592346656; x=1623882656; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=/5Ov+gppYN7KJ5aQn25HOqJLUAtFPPVAyop7Fexu5eI=; b=HydIri+69QqYVrfQMhu7WQHXisg0S9+aHXTLmvwgGxYKQl9GBQ8KPyth QIImQLWGLmAEobj7Ay8UN5iwBQwhRs20ZQ+adVZQ+U79jPOVuTKOVoZiO cu+dFC6jEyVlIwej4VyU2esY0CR2XIaJFkdIoTLPTsqGMx8pp5PLA2SBB s=; IronPort-SDR: 0wp0vaMsG06ZplyB+5A5c/qT8EcLICE9E/lPyLBASpFVCVcIdV45ygLSeUw2A92LeT7u282MWJ LMXVSzXi0/BQ== X-IronPort-AV: E=Sophos;i="5.73,520,1583193600"; d="scan'208";a="38021711" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2a-53356bf6.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 16 Jun 2020 22:30:53 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2a-53356bf6.us-west-2.amazon.com (Postfix) with ESMTPS id 77B67A1F74; Tue, 16 Jun 2020 22:30:50 +0000 (UTC) Received: from EX13D01UWB002.ant.amazon.com (10.43.161.136) by EX13MTAUWB001.ant.amazon.com (10.43.161.207) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 16 Jun 2020 22:30:03 +0000 Received: from EX13MTAUWB001.ant.amazon.com (10.43.161.207) by EX13d01UWB002.ant.amazon.com (10.43.161.136) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 16 Jun 2020 22:30:03 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.161.249) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 16 Jun 2020 22:30:03 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 3892B40139; Tue, 16 Jun 2020 22:30:03 +0000 (UTC) Date: Tue, 16 Jun 2020 22:30:03 +0000 From: Anchal Agarwal To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Message-ID: <20200616223003.GA28769@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monn wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > Hello, > > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > On Tue, May 19, 2020 at 11:27:50PM +0000, Anchal Agarwal wrote: > > > > From: Munehisa Kamata > > > > > > > > S4 power transition states are much different than xen > > > > suspend/resume. Former is visible to the guest and frontend drivers should > > > > be aware of the state transitions and should be able to take appropriate > > > > actions when needed. In transition to S4 we need to make sure that at least > > > > all the in-flight blkif requests get completed, since they probably contain > > > > bits of the guest's memory image and that's not going to get saved any > > > > other way. Hence, re-issuing of in-flight requests as in case of xen resume > > > > will not work here. This is in contrast to xen-suspend where we need to > > > > freeze with as little processing as possible to avoid dirtying RAM late in > > > > the migration cycle and we know that in-flight data can wait. > > > > > > > > Add freeze, thaw and restore callbacks for PM suspend and hibernation > > > > support. All frontend drivers that needs to use PM_HIBERNATION/PM_SUSPEND > > > > events, need to implement these xenbus_driver callbacks. The freeze handler > > > > stops block-layer queue and disconnect the frontend from the backend while > > > > freeing ring_info and associated resources. Before disconnecting from the > > > > backend, we need to prevent any new IO from being queued and wait for existing > > > > IO to complete. Freeze/unfreeze of the queues will guarantee that there are no > > > > requests in use on the shared ring. However, for sanity we should check > > > > state of the ring before disconnecting to make sure that there are no > > > > outstanding requests to be processed on the ring. The restore handler > > > > re-allocates ring_info, unquiesces and unfreezes the queue and re-connect to > > > > the backend, so that rest of the kernel can continue to use the block device > > > > transparently. > > > > > > > > Note:For older backends,if a backend doesn't have commit'12ea729645ace' > > > > xen/blkback: unmap all persistent grants when frontend gets disconnected, > > > > the frontend may see massive amount of grant table warning when freeing > > > > resources. > > > > [ 36.852659] deferring g.e. 0xf9 (pfn 0xffffffffffffffff) > > > > [ 36.855089] xen:grant_table: WARNING:e.g. 0x112 still in use! > > > > > > > > In this case, persistent grants would need to be disabled. > > > > > > > > [Anchal Changelog: Removed timeout/request during blkfront freeze. > > > > Reworked the whole patch to work with blk-mq and incorporate upstream's > > > > comments] > > > > > > Please tag versions using vX and it would be helpful if you could list > > > the specific changes that you performed between versions. There where > > > 3 RFC versions IIRC, and there's no log of the changes between them. > > > > > > I will elaborate on "upstream's comments" in my changelog in my next round of patches. > > > > Sorry for being picky, but can you please make sure your email client > > properly quotes previous emails on reply. Note the lack of '>' added > > to the quoted parts of your reply. > That was just my outlook probably. Note taken. > > > > > > + } > > > > + > > > > break; > > > > + } > > > > + > > > > + /* > > > > + * We may somehow receive backend's Closed again while thawing > > > > + * or restoring and it causes thawing or restoring to fail. > > > > + * Ignore such unexpected state regardless of the backend state. > > > > + */ > > > > + if (info->connected == BLKIF_STATE_FROZEN) { > > > > > > I think you can join this with the previous dev->state == XenbusStateClosed? > > > > > > Also, won't the device be in the Closed state already if it's in state > > > frozen? > > > Yes but I think this mostly due to a hypothetical case if during thawing backend switches to Closed state. > > > I am not entirely sure if that could happen. Could use some expertise here. > > > > I think the frontend seeing the backend in the closed state during > > restore would be a bug that should prevent the frontend from > > resuming. > > > > > > + /* Kick the backend to disconnect */ > > > > + xenbus_switch_state(dev, XenbusStateClosing); > > > > + > > > > + /* > > > > + * We don't want to move forward before the frontend is diconnected > > > > + * from the backend cleanly. > > > > + */ > > > > + timeout = wait_for_completion_timeout(&info->wait_backend_disconnected, > > > > + timeout); > > > > + if (!timeout) { > > > > + err = -EBUSY; > > > > > > Note err is only used here, and I think could just be dropped. > > > > > > This err is what's being returned from the function. Am I missing anything? > > > > Just 'return -EBUSY;' directly, and remove the top level variable. You > > can also use -EBUSY directly in the xenbus_dev_error call. Anyway, not > > that important. > > > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > + "the device may become inconsistent state"); > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > state and with the queues frozen. You should make an attempt to > > > restore things to a working state. > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > You can manually force this state, and then check that it will behave > > correctly. I would expect that on a failure to disconnect from the > > backend you should switch the frontend to the 'Init' state in order to > > try to reconnect to the backend when possible. > > > From what I understand forcing manually is, failing the freeze without > disconnect and try to revive the connection by unfreezing the > queues->reconnecting to backend [which never got diconnected]. May be even > tearing down things manually because I am not sure what state will frontend > see if backend fails to to disconnect at any point in time. I assumed connected. > Then again if its "CONNECTED" I may not need to tear down everything and start > from Initialising state because that may not work. > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > I don't see it getting handled in the backend then what will be backend's state? > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > if it tries to read backend's state through xenbus_read_driver_state ? > > So the flow be like: > Front end marks XenbusStateClosing > Backend marks its state as XenbusStateClosing > Frontend marks XenbusStateClosed > Backend disconnects calls xen_blkif_disconnect > Backend fails to disconnect, the above function returns EBUSY > What will be state of backend here? > Frontend did not tear down the rings if backend does not switches the > state to 'Closed' in case of failure. > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend > won't be calling connect(). {From reading code in frontend_changed} > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > we did not tear down anything so calling talk_to_blkback may not be needed > > Does that sound correct? Send that too quickly, I also meant to add XenBusIntialised state should be ok only if we expect backend will stay in "Connected" state. Also, I experimented with that notion. I am little worried about the correctness here. Can the backend come to an Unknown state somehow? > > > > + } > > > > + > > > > + return err; > > > > +} > > > > + > > > > +static int blkfront_restore(struct xenbus_device *dev) > > > > +{ > > > > + struct blkfront_info *info = dev_get_drvdata(&dev->dev); > > > > + int err = 0; > > > > + > > > > + err = talk_to_blkback(dev, info); > > > > + blk_mq_unquiesce_queue(info->rq); > > > > + blk_mq_unfreeze_queue(info->rq); > > > > + if (!err) > > > > + blk_mq_update_nr_hw_queues(&info->tag_set, info->nr_rings); > > > > > > Bad indentation. Also shouldn't you first update the queues and then > > > unfreeze them? > > > Please correct me if I am wrong, blk_mq_update_nr_hw_queues freezes the queue > > > So I don't think the order could be reversed. > > > > Regardless of what blk_mq_update_nr_hw_queues does, I don't think it's > > correct to unfreeze the queues without having updated them. Also the > > freezing/unfreezing uses a refcount, so I think it's perfectly fine to > > call blk_mq_update_nr_hw_queues first and then unfreeze the queues. > > > > Also note that talk_to_blkback returning an error should likely > > prevent any unfreezing, as the queues won't be updated to match the > > parameters of the backend. > > > I think you are right here. Will send out fixes in V2 > > Thanks, Roger. > > > Thanks, > Anchal > From xen-devel-bounces@lists.xenproject.org Tue Jun 16 23:16:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 23:16:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlKoJ-0002FD-CK; Tue, 16 Jun 2020 23:16:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlKoI-0002F8-DG for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 23:16:06 +0000 X-Inumbo-ID: 59ebe462-b027-11ea-8496-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 59ebe462-b027-11ea-8496-bc764e2007e4; Tue, 16 Jun 2020 23:16:05 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: gym42pItmyO0ZUFu8Ue22OFWIrI4UIHPpFbx58NlFP8USp74m+FVEfb3BT/lu1akLibRAzWJek nZPQLkTgpxh7n79oFZeL7Kq4ngTImjVjUXvMBddQD4arTUtzvyaIvWjngy6/ZOcsm7SYfdLygC VLZkIttEcRw6rXHtAXcx1zIn1Bh+3aGaC0JD7lD4sFIHCRT+1pLjSi9IfuXVyVYitURsu0dQ/g l1LsKhELV+zt0EemQJ835uiCL0IpHfL+DiE10xbQbpRx697cL0VaSpJuGEn7Plj8hyN/bXBhMl Bk8= X-SBRS: 2.7 X-MesageID: 20450917 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,520,1583211600"; d="scan'208";a="20450917" Subject: Re: [PATCH 2/2] xen/arm: Mitigate straight-line speculation for SMC call To: Julien Grall , Stefano Stabellini References: <20200616175913.7368-1-julien@xen.org> <20200616175913.7368-3-julien@xen.org> From: Andrew Cooper Message-ID: <7b21fb8d-915c-7d87-1777-b0ed0febddd2@citrix.com> Date: Wed, 17 Jun 2020 00:16:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Andre Przywara , Julien Grall , Bertrand Marquis , "Xen.org security team" , xen-devel , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 22:57, Julien Grall wrote: > On Tue, 16 Jun 2020 at 22:34, Stefano Stabellini wrote: >> On Tue, 16 Jun 2020, Julien Grall wrote: >>> From: Julien Grall >>> >>> SMC call will update some of registers (typically only x0) depending on >> ^a SMC call An SMC call. >> >>> the arguments provided. >>> >>> Some CPUs can speculate past a SMC instruction and potentially perform >>> speculative access to emrmoy using the pre-call values before executing >> ^ memory >> >>> the SMC. >>> >>> There is no known gadget available after the SMC call today. However >>> some of the registers may contain values from the guest and are expected >>> to be updated by the SMC call. >>> >>> In order to harden the code, it would be better to prevent straight-line >>> speculation from an SMC. Architecturally executing the speculation >> ^ a? any? > "any" might be better. "an SMC" is correct, but "any" is also fine. 'a' vs 'an' is based on the sound of the following.  S in "S-M-C" as an abbreviation starts with an 'e' vowel sound, unlike 's' in secure, so the correct grammar is "an SMC" and "a secure monitor call". ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 16 23:22:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 23:22:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlKuR-00037U-1r; Tue, 16 Jun 2020 23:22:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlKuQ-00037P-DT for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 23:22:26 +0000 X-Inumbo-ID: 3ce636fa-b028-11ea-b965-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3ce636fa-b028-11ea-b965-12813bfff9fa; Tue, 16 Jun 2020 23:22:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fxX4ZsvW2nUF/qHmNzG5xbb3+vaVDgKTcQy4LJBl5p4=; b=y/8OS4L7gyJ7wiU1mipiJnuh4 No28+5RsbxJAYXRNQwRwg/v66BqUvrEAcKlFbk5/QDgCJ9cGHiXiVphxFVqNnbHUUOGi85m8KWLY2 uvSw4D4iWlvHD5gTr3piXUA9ooh8z0geS4NqPSDD99w2Xsa8x8K7D46Nl8XaY4L9mY98c=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlKuO-0001Rl-NE; Tue, 16 Jun 2020 23:22:24 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlKuO-0005ou-Di; Tue, 16 Jun 2020 23:22:24 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlKuO-0003es-Ct; Tue, 16 Jun 2020 23:22:24 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.13-testing test] 151153: tolerable FAIL - PUSHED X-Osstest-Failures: xen-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=c54de7d9df7718ea53bf21e1ff5bbd339602a704 X-Osstest-Versions-That: xen=d8e1053bfa2726d122109d137fc6c489948b1c36 From: osstest service owner Date: Tue, 16 Jun 2020 23:22:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151153 xen-4.13-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151153/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen c54de7d9df7718ea53bf21e1ff5bbd339602a704 baseline version: xen d8e1053bfa2726d122109d137fc6c489948b1c36 Last test of basis 151048 2020-06-11 15:37:37 Z 5 days Testing same since 151153 2020-06-15 15:06:03 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git d8e1053bfa..c54de7d9df c54de7d9df7718ea53bf21e1ff5bbd339602a704 -> stable-4.13 From xen-devel-bounces@lists.xenproject.org Tue Jun 16 23:28:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 16 Jun 2020 23:28:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlKzo-0003LI-Ja; Tue, 16 Jun 2020 23:28:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlKzm-0003LD-W8 for xen-devel@lists.xenproject.org; Tue, 16 Jun 2020 23:27:59 +0000 X-Inumbo-ID: 0334a2f6-b029-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0334a2f6-b029-11ea-bb8b-bc764e2007e4; Tue, 16 Jun 2020 23:27:58 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 654442078D; Tue, 16 Jun 2020 23:27:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592350077; bh=keyhVpc8dVr2vcXxFMMrlOclLA7NkXX0gWNtYmIEn/M=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sDZiseqCPS96EjDjWsp2G+hSdqpLETKG7Wx2kXFeKugC1sJNF9I2FPvsRzgJtSeTD 6wcbD2VMkbbFXi2rlOaI4odC17MBKi/1RHNHwAQK1PmyOshf71u1+0bRgRUIYdknU8 lVl4zOtrKWw7T2Zo/N1R8OOvpXuM/qu5xhq+XQzI= Date: Tue, 16 Jun 2020 16:27:56 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Andrew Cooper Subject: Re: [PATCH 2/2] xen/arm: Mitigate straight-line speculation for SMC call In-Reply-To: <7b21fb8d-915c-7d87-1777-b0ed0febddd2@citrix.com> Message-ID: References: <20200616175913.7368-1-julien@xen.org> <20200616175913.7368-3-julien@xen.org> <7b21fb8d-915c-7d87-1777-b0ed0febddd2@citrix.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-206843476-1592350077=:24982" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Paul Durrant , Andre Przywara , Julien Grall , Bertrand Marquis , "Xen.org security team" , xen-devel , Volodymyr Babchuk , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-206843476-1592350077=:24982 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Wed, 17 Jun 2020, Andrew Cooper wrote: > On 16/06/2020 22:57, Julien Grall wrote: > > On Tue, 16 Jun 2020 at 22:34, Stefano Stabellini wrote: > >> On Tue, 16 Jun 2020, Julien Grall wrote: > >>> From: Julien Grall > >>> > >>> SMC call will update some of registers (typically only x0) depending on > >> ^a SMC call > > An SMC call. > > >> > >>> the arguments provided. > >>> > >>> Some CPUs can speculate past a SMC instruction and potentially perform > >>> speculative access to emrmoy using the pre-call values before executing > >> ^ memory > >> > >>> the SMC. > >>> > >>> There is no known gadget available after the SMC call today. However > >>> some of the registers may contain values from the guest and are expected > >>> to be updated by the SMC call. > >>> > >>> In order to harden the code, it would be better to prevent straight-line > >>> speculation from an SMC. Architecturally executing the speculation > >> ^ a? any? > > "any" might be better. > > "an SMC" is correct, but "any" is also fine. > > 'a' vs 'an' is based on the sound of the following.  S in "S-M-C" as an > abbreviation starts with an 'e' vowel sound, unlike 's' in secure, so > the correct grammar is "an SMC" and "a secure monitor call". LOL! English sometimes... damn. Anyway, many thanks for the correction :-) --8323329-206843476-1592350077=:24982-- From xen-devel-bounces@lists.xenproject.org Wed Jun 17 01:35:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 01:35:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlMzD-0007SU-Hl; Wed, 17 Jun 2020 01:35:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlMzC-0007SP-H4 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 01:35:30 +0000 X-Inumbo-ID: d278bf64-b03a-11ea-b977-12813bfff9fa Received: from mga17.intel.com (unknown [192.55.52.151]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d278bf64-b03a-11ea-b977-12813bfff9fa; Wed, 17 Jun 2020 01:35:28 +0000 (UTC) IronPort-SDR: Pe/kASU3GQrQzT7JT7cpfgYUYc/wfQvDha6Ib72q6YoFnu/RF8a25HUFqrHwih2m6kQ9+TgLgh P331QWDoMrJg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2020 18:35:21 -0700 IronPort-SDR: 0u8esyyyIDW/FTM3vtBZ7JmjN7w6AhcQn42fKyszADqdZXCFuWWdug+6Q9gIMZkgmNV/+F+8Ax PwK6l8uUvu0w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,520,1583222400"; d="scan'208";a="309317458" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 16 Jun 2020 18:35:22 -0700 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 16 Jun 2020 18:35:22 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx118.amr.corp.intel.com (10.18.116.18) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 16 Jun 2020 18:35:21 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.173) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 16 Jun 2020 18:35:21 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S5IQjX5bdmmUyjTfjDFVLxpaN/4pEV6dwrPhY3hA45GYbiGqB01YIowyu+qKIWLTV/zGDEyat5xl5Fkyp2+SpVwJR3qbR3VQsavII0/pDZ3Xs/NlS9ZAPDCTJxoUVzMGO/YwUIgmilE+7PAscqYI4jTwfH6F0HPuv4uY0Gnc7kL9bSKEL1JZgoUVd7+HpzUEponGm0MW6J98w0fsV6b3pEiFIAXRf+2vKWRFDUKsVvIX0IiRptMwwQB7gKrHtrUFEJBA4l+pVkE18IY8+RiOU5qN3PzSXgD+VVL7dtdnTfvXzjJlbQUSMY5ICrgPf5o1/DDs8xR1HbH3JWOTJpzcXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oMMSCmctEBUBruZM3Q2idlJszNvZMlQw119LQSZiRMs=; b=WFsz0BSAyMDjg7G61vtmLw9W4Oe6qx37VTm0nhfm2dVoBS9qfGuxCMnb916vtRr7n3StKXty2vZ9xuhVMfKJ9CQ0WHW1xDcV5SuCSIfYSV+goPvkDcy3cDO96AqVrEoJZFMljw3cOqI79YiKklFAzF9DD8bVeTR7McvuWNvUqVmsFz6eSQ58yO7vQQ+HO27axAkkWweOQ09S8dfMoenzcaCoTtPacsrHHaidQdmGlmiOiJR5a6CNGrT5J/+O/EhZAzHuUX3gq4961Y+qWRLbwGecHvpvmvetbrn55wAtdUkrH5mK52VA5Ze3UrG12ToFgkZZ856cckaLTMUaXecQjw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oMMSCmctEBUBruZM3Q2idlJszNvZMlQw119LQSZiRMs=; b=Uav6HGG+aGGBYm0vLkEXlmYaK6xlTaEJHrEIP1lt9Hh1f4iRBankHnuWeTNHMC+qoH7xqqcMn/+YVYW+4IRivz/5Zg0xFXgMZ9xclewfSHX+UzD72CKVWsazXA+R5v/Xe5vskGv62J2xhBb4pZyLj6ZdmbuzW1iFlndup17/Eiw= Received: from MWHPR11MB1645.namprd11.prod.outlook.com (2603:10b6:301:b::12) by MWHPR11MB0013.namprd11.prod.outlook.com (2603:10b6:301:67::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Wed, 17 Jun 2020 01:35:20 +0000 Received: from MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb]) by MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb%5]) with mapi id 15.20.3088.029; Wed, 17 Jun 2020 01:35:20 +0000 From: "Tian, Kevin" To: =?utf-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Andrew Cooper Subject: RE: [PATCH v1 0/7] Implement support for external IPT monitoring Thread-Topic: [PATCH v1 0/7] Implement support for external IPT monitoring Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hpiVzvKAgAAIowCAAHHNAA== Date: Wed, 17 Jun 2020 01:35:20 +0000 Message-ID: References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> In-Reply-To: <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: cert.pl; dkim=none (message not signed) header.d=none;cert.pl; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.207] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53d06cdc-7e68-4994-4829-08d8125eb278 x-ms-traffictypediagnostic: MWHPR11MB0013: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04371797A5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1bJWTpTn6qii0pxy46q6J6y1KyjF6t/qwgH6MW2h9KgyOJiD+nlHy/tKkQQ3sBW8K5LMSAoWqZIsuq/VS3TpWuo0Mef4+pCYGRuKj0PjtynP+2e42Tlf2+yw5aYOCfh+hGY0TEhQxFF3y265URcOxhW3qLIWswf3lb5ZqcLc1NjyiHnw08k+oKwgvdLRu1L6Y5uVHwJBUMY1hEMLr5v6csDYny4sqbO8ISH7qEeReQScxHFGhmd/CZPtsOweJ0M8YqjkAKU3/VKKEgwUgSvYt7ncqhHEaDvs+OJgTzibJQbiHjp25ZO3ROcpT5w2Af8C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1645.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(346002)(136003)(39860400002)(76116006)(66946007)(66446008)(64756008)(86362001)(66556008)(5660300002)(52536014)(7416002)(33656002)(4326008)(107886003)(66476007)(478600001)(66574015)(55016002)(9686003)(2906002)(186003)(26005)(316002)(8936002)(110136005)(53546011)(54906003)(6506007)(83380400001)(71200400001)(7696005)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: L3fWBQ1/BlL9JLOeFC0Gj6uzOveCC2C0m1YkweNEX2el+ud58lJR6aiMeGWCMTf/oM6qJgWMhElWY8Hf2vdsmE9b22X86HMXK3mrQYpv6kTokEhYRO6Chtg/fIjcFrn7ZOkKepHKv7tjyUllMSlJKv0XGoRO/V7pitWmRqlaxSntiGcIagzvcOqCTlMk1ndKHa5uLBud5jv7RSaLrCQgsKaGSv1GeaOEB1xv1HqJrvsEUY52f8rtWACQ3nlayguTN2umz4IvrDIkvA6bJbziX18pR99cr0z94BxHphS+ehgESFwYP7NIqiX0ccL9RpNOZ+VtO2YCu/+0t+Z2msgFYF6RT+WtJAZjsIRIaz00hfKz53iw9VZbzL/nfrTUfVo6n7eu/QwQoC3DUTZyOnbRXssCRcih1ICiBeIFI3BSIMLnfb7YB/jSDxbwP2PISe837kGDytmnuLWikZV13M26G36qwu9dlcfCOCRYa2MUOb7hG2Zf4+DLMv2raPG6BYjT Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 53d06cdc-7e68-4994-4829-08d8125eb278 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 01:35:20.1539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: H6b4ONsJv+msHm6UzI1hGddBKLLsnEDYkb5NwE8ZuKyNLX1FhCX4UsvdWsn4gc7UKl3JdFqe4SjSEZCmj8uYVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB0013 X-OriginatorOrg: intel.com X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Ian Jackson , George Dunlap , "Kang, Luwei" , "Nakajima, Jun" , Xen-devel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" K0x1d2VpLCB3aG8gZGV2ZWxvcGVkIFBUIGZvciBLVk0gYW5kIGlzIHRoZSBiZXN0IG9uZSB3aG8g Y2FuIGhlbHANCnJldmlldyBWTVggY2hhbmdlcyBmcm9tIEludGVsIHNpZGUuIFBsZWFzZSBpbmNs dWRlIGhpbSBpbiBmdXR1cmUNCnBvc3Qgb3IgZGlzY3Vzc2lvbi4NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaWNoYcWCIExlc3pjennFhHNraSA8bWljaGFsLmxlc3pj enluc2tpQGNlcnQucGw+DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxNywgMjAyMCAyOjQ4IEFN DQo+IFRvOiBBbmRyZXcgQ29vcGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPg0KPiBDYzog WGVuLWRldmVsIDx4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmc+OyBKYW4gQmV1bGljaA0K PiA8amJldWxpY2hAc3VzZS5jb20+OyBXZWkgTGl1IDx3bEB4ZW4ub3JnPjsgUm9nZXIgUGF1IE1v bm7DqQ0KPiA8cm9nZXIucGF1QGNpdHJpeC5jb20+OyBOYWthamltYSwgSnVuIDxqdW4ubmFrYWpp bWFAaW50ZWwuY29tPjsgVGlhbiwNCj4gS2V2aW4gPGtldmluLnRpYW5AaW50ZWwuY29tPjsgR2Vv cmdlIER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPjsNCj4gSWFuIEphY2tzb24gPGlh bi5qYWNrc29uQGV1LmNpdHJpeC5jb20+OyBKdWxpZW4gR3JhbGwgPGp1bGllbkB4ZW4ub3JnPjsN Cj4gU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0KPiBTdWJqZWN0 OiBSZTogW1BBVENIIHYxIDAvN10gSW1wbGVtZW50IHN1cHBvcnQgZm9yIGV4dGVybmFsIElQVCBt b25pdG9yaW5nDQo+IA0KPiAtLS0tLSAxNiBjemUgMjAyMCBvIDIwOjE3LCBBbmRyZXcgQ29vcGVy IGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20NCj4gbmFwaXNhxYIoYSk6DQo+IA0KPiA+IE9uIDE2 LzA2LzIwMjAgMTY6MTYsIE1pY2hhxYIgTGVzemN6ecWEc2tpIHdyb3RlOg0KPiA+PiBJbnRlbCBQ cm9jZXNzb3IgVHJhY2UgaXMgYW4gYXJjaGl0ZWN0dXJhbCBleHRlbnNpb24gYXZhaWxhYmxlIGlu IG1vZGVybg0KPiBJbnRlbA0KPiA+PiBmYW1pbHkgQ1BVcy4gSXQgYWxsb3dzIHJlY29yZGluZyB0 aGUgZGV0YWlsZWQgdHJhY2Ugb2YgYWN0aXZpdHkgd2hpbGUgdGhlDQo+ID4+IHByb2Nlc3NvciBl eGVjdXRlcyB0aGUgY29kZS4gT25lIG1pZ2h0IHVzZSB0aGUgcmVjb3JkZWQgdHJhY2UgdG8NCj4g cmVjb25zdHJ1Y3QNCj4gPj4gdGhlIGNvZGUgZmxvdy4gSXQgbWVhbnMsIHRvIGZpbmQgb3V0IHRo ZSBleGVjdXRlZCBjb2RlIHBhdGhzLCBkZXRlcm1pbmUNCj4gPj4gYnJhbmNoZXMgdGFrZW4sIGFu ZCBzbyBmb3J0aC4NCj4gPj4NCj4gPj4gVGhlIGFib3ZlbWVudGlvbmVkIGZlYXR1cmUgaXMgZGVz Y3JpYmVkIGluIEludGVsKFIpIDY0IGFuZCBJQS0zMg0KPiBBcmNoaXRlY3R1cmVzDQo+ID4+IFNv ZnR3YXJlIERldmVsb3BlcidzIE1hbnVhbCBWb2x1bWUgM0M6IFN5c3RlbSBQcm9ncmFtbWluZyBH dWlkZSwNCj4gUGFydCAzLA0KPiA+PiBDaGFwdGVyIDM2OiAiSW50ZWwgUHJvY2Vzc29yIFRyYWNl LiINCj4gPj4NCj4gPj4gVGhpcyBwYXRjaCBzZXJpZXMgaW1wbGVtZW50cyBhbiBpbnRlcmZhY2Ug dGhhdCBEb20wIGNvdWxkIHVzZSBpbiBvcmRlciB0bw0KPiBlbmFibGUNCj4gPj4gSVBUIGZvciBw YXJ0aWN1bGFyIHZDUFVzIGluIERvbVUsIGFsbG93aW5nIGZvciBleHRlcm5hbCBtb25pdG9yaW5n LiBTdWNoIGENCj4gPj4gZmVhdHVyZSBoYXMgbnVtZXJvdXMgYXBwbGljYXRpb25zIGxpa2UgbWFs d2FyZSBtb25pdG9yaW5nLCBmdXp6aW5nLCBvcg0KPiA+PiBwZXJmb3JtYW5jZSB0ZXN0aW5nLg0K PiA+DQo+ID4gSGVsbG8sDQo+ID4NCj4gPiBJJ20gdmVyeSBleGNpdGVkIHRvIHNlZSBzdXBwb3J0 IGxpa2UgdGhpcyBhcHBlYXJpbmcuwqAgSG93ZXZlciwgYmUgYXdhcmUNCj4gPiB0aGF0IHdlJ3Jl IGN1cnJlbnRseSBpbiBjb2RlIGZyZWV6ZSBmb3IgdGhlIDQuMTQgcmVsZWFzZSwgc28gaW4tZGVw dGgNCj4gPiByZXZpZXdzIHdpbGwgcHJvYmFibHkgYmUgZGVsYXllZCBzb21ld2hhdCBkdWUgdG8g b3VyIGJ1ZyBxdWV1ZSBhbmQNCj4gPiByZWxlYXNlIGFjdGl2aXRpZXMuDQo+IA0KPiBTdXJlLCB0 YWtlIHlvdXIgdGltZSA6KQ0KPiANCj4gDQo+ID4NCj4gPiBUaGF0IHNhaWQsIEkndmUgaGFkIGEg dmVyeSBxdWljayBsb29rIHRocm91Z2ggdGhlIHNlcmllcywgYW5kIGhhdmUgYSBmZXcNCj4gPiBn ZW5lcmFsIHF1ZXN0aW9ucyBmaXJzdC4NCj4gPg0KPiA+IEFGQUlDVCwgdGhpcyBpcyBzdHJpY3Rs eSBmb3IgZXh0ZXJuYWwgbW9uaXRvcmluZyBvZiB0aGUgVk0sIG5vdCBmb3IgdGhlDQo+ID4gVk0g dG8gdXNlIGl0c2VsZj/CoCBJZiBzbywgaXQgc2hvdWxkbid0IGhhdmUgdGhlIEggdGFnIGhlcmU6 DQo+ID4NCj4gPiBYRU5fQ1BVRkVBVFVSRShJUFQswqDCoMKgwqDCoMKgwqDCoMKgwqAgNSozMisy NSkgLypIwqAgSW50ZWwgUHJvY2Vzc29yIFRyYWNlICovDQo+ID4NCj4gPiBiZWNhdXNlIHRoYXQg ZXhwb3NlcyB0aGUgZmVhdHVyZSB0byB0aGUgZ3Vlc3QsIHdpdGggdGhlIGltcGxpY2F0aW9uIHRo YXQNCj4gPiBhbGwgb3RoZXIgcGFydHMgb2YgdGhlIGZlYXR1cmUgd29yayBhcyBhZHZlcnRpc2Vk Lg0KPiANCj4gT2ssIEkgd2lsbCByZW1vdmUgdGhlIEggdGFnLg0KPiANCj4gDQo+ID4NCj4gPg0K PiA+IEFyZSB0aGVyZSBhbnkgcmVzdHJpY3Rpb25zIG9uIEVQVCBiZWluZyBlbmFibGVkIGluIHRo ZSBmaXJzdCBwbGFjZT/CoCBJJ20NCj4gPiBub3QgYXdhcmUgb2YgYW55LCBhbmQgaW4gcHJpbmNp cGxlIHdlIGNvdWxkIHVzZSB0aGlzIGZ1bmN0aW9uYWxpdHkgZm9yDQo+ID4gUFYgZ3Vlc3RzIGFz IHdlbGwgKHVzaW5nIHRoZSBDUEwgZmlsdGVyKS7CoCBUaGVyZWZvcmUsIEkgdGhpbmsgaXQgd291 bGQNCj4gPiBiZSBoZWxwZnVsIHRvIG5vdCB0aWUgdGhlIGZ1bmN0aW9uYWxpdHkgdG8gSFZNIGd1 ZXN0cywgZXZlbiBpZiB0aGF0IGlzDQo+ID4gdGhlIG9ubHkgb3B0aW9uIGVuYWJsZWQgdG8gc3Rh cnQgd2l0aC4NCj4gDQo+IEkgdGhpbmsgYXQgdGhlIG1vbWVudCBpdCdzIG5vdCByZXF1aXJlZCB0 byBoYXZlIEVQVC4gVGhpcyBwYXRjaCBzZXJpZXMgZG9lc24ndA0KPiB1c2UgYW55IHRyYW5zbGF0 aW9uIGZlYXR1cmUgZmxhZ3MsIHNvIHRoZSBvdXRwdXQgYWRkcmVzcyBpcyBhbHdheXMgYSBtYWNo aW5lDQo+IHBoeXNpY2FsIGFkZHJlc3MsIHJlZ2FyZGxlc3Mgb2YgY29udGV4dC4gSSB3aWxsIGNo ZWNrIGlmIGl0IGNvdWxkIGJlIGVhc2lseSB1c2VkDQo+IHdpdGggUFYuDQo+IA0KPiANCj4gPg0K PiA+IFRoZSBidWZmZXIgbWFwcGluZyBhbmQgY3JlYXRpb24gbG9naWMgaXMgZmFpcmx5IHByb2Js ZW1hdGljLsKgIEluc3RlYWQgb2YNCj4gPiBmaWdodGluZyB3aXRoIGFub3RoZXIgb3BlbmNvZGVk IGV4YW1wbGUsIHRha2UgYSBsb29rIGF0IHRoZSBJT1JFUQ0KPiA+IHNlcnZlcidzIHVzZSBvZiAi YWNxdWlyZSByZXNvdXJjZSIgd2hpY2ggaXMgYSBtYXBwaW5nIGludGVyZmFjZSB3aGljaA0KPiA+ IHN1cHBvcnRzIGFsbG9jYXRpbmcgbWVtb3J5IG9uIGJlaGFsZiBvZiB0aGUgZ3Vlc3QsIG91dHNp ZGUgb2YgdGhlIGd1ZXN0DQo+ID4gbWVtb3J5LCBmb3IgdXNlIGJ5IGNvbnRyb2wgdG9vbHMuDQo+ ID4NCj4gPiBJIHRoaW5rIHdoYXQgdGhpcyB3YW50cyBpcyBhIGJpdCBzb21ld2hlcmUgaW4gZG9t YWluX2NyZWF0ZSB0byBpbmRpY2F0ZQ0KPiA+IHRoYXQgZXh0ZXJuYWwgdHJhY2luZyBpcyB1c2Vk IGZvciB0aGlzIGRvbWFpbiAoYW5kIGFsbG9jYXRlIHdoYXRldmVyDQo+ID4gc3RydWN0dXJlcy9i dWZmZXJzIGFyZSBuZWNlc3NhcnkpLCBhY3F1aXJlIHJlc291cmNlIHRvIG1hcCB0aGUgYnVmZmVy cw0KPiA+IHRoZW1zZWx2ZXMsIGFuZCBhIGRvbWN0bCBmb3IgYW55IG5lY2Vzc2FyeSBydW50aW1l IGNvbnRyb2xzLg0KPiA+DQo+IA0KPiBJIHdpbGwgY2hlY2sgdGhpcyBvdXQsIHRoaXMgc291bmRz IGxpa2UgYSBnb29kIG9wdGlvbiBhcyBpdCB3b3VsZCByZW1vdmUgbG90cyBvZg0KPiBjb21wbGV4 aXR5IGZyb20gdGhlIGV4aXN0aW5nIGlwdF9lbmFibGUgZG9tY3RsLg0KPiANCj4gPg0KPiA+IFdo YXQgc2VtYW50aWNzIGRvIHlvdSB3YW50IGZvciB0aGUgYnVmZmVyIGJlY29taW5nIGZ1bGw/wqAg R2l2ZW4gdGhhdA0KPiA+IGRlYnVnZ2luZy90cmFjaW5nIGlzIHRoZSBnb2FsLCBJIHByZXN1bWUg InBhdXNlIHZjcHUgb24gZnVsbCIgaXMgdGhlDQo+ID4gcHJlZmVycmVkIGJlaGF2aW91ciwgcmF0 aGVyIHRoYW4gZHJvcCBwYWNrZXRzIG9uIGZ1bGw/DQo+ID4NCj4gDQo+IFJpZ2h0IG5vdyB0aGlz IGlzIGEgcmluZy1zdHlsZSBidWZmZXIgYW5kIHdoZW4gaXQgd291bGQgYmVjb21lIGZ1bGwgaXQg d291bGQNCj4gc2ltcGx5IHdyYXAgYW5kIG92ZXJyaWRlIHRoZSBvbGQgZGF0YS4NCj4gDQo+ID4N Cj4gPiBXaGVuIHRoaXMgc3ViamVjdCB3YXMgYnJvYWNoZWQgb24geGVuLWRldmVsIGJlZm9yZSwg b25lIGlzc3VlIHdhcyB0aGUNCj4gPiBmYWN0IHRoYXQgYWxsIGFjdGlvbnMgd2hpY2ggYXJlIGlu dGVyY2VwdGVkIGRvbid0IGVuZCB1cCB3cml0aW5nIGFueQ0KPiA+IGFwcHJvcHJpYXRlIHBhY2tl dHMuwqAgVGhpcyBpcyBwZXJoYXBzIGxlc3Mgb2YgYW4gaXNzdWUgZm9yIHRoaXMgZXhhbXBsZSwN Cj4gPiB3aGVyZSB0aGUgZXh0ZXJuYWwgYWdlbnQgY2FuIHNlZSBWTUV4aXRzIGluIHRoZSB0cmFj ZSwgYnV0IGl0IHN0aWxsDQo+ID4gcmVzdWx0cyBpbiBtaXNzaW5nIGluZm9ybWF0aW9uLsKgIChJ dCBpcyBhIG1ham9yIHByb2JsZW0gZm9yIFBUIHdpdGhpbg0KPiA+IHRoZSBndWVzdCwgYW5kIG5l ZWRzIFhlbidzIGludGVyY2VwdC9lbXVsYXRpb24gZnJhbWV3b3JrIGJlaW5nIHVwZGF0ZWQNCj4g PiB0byBiZSBQVC1hd2FyZSBzbyBpdCBjYW4gZmlsbCBpbiB0aGUgc2FtZSBwYWNrZXRzIHdoaWNo IGhhcmR3YXJlIHdvdWxkDQo+ID4gaGF2ZSBkb25lIGZvciBlcXVpdmFsZW50IGFjdGlvbnMuKQ0K PiANCj4gT2ssIHRoaXMgc291bmRzIGxpa2UgYSBoYXJkIGlzc3VlLiBDb3VsZCB5b3UgcG9pbnQg b3V0IHdoYXQgY291bGQgYmUgdGhlDQo+IHBhcnRpY3VsYXIgcHJvYmxlbWF0aWMgY2FzZXM/IEZv ciBpbnN0YW5jZSwgaWYgc29tZXRoaW5nIHdvdWxkIGFsdGVyIEVJUC9SSVANCj4gb3IgQ1IzIHRo ZW4gSSBiZWxpdmUgaXQgd291bGQgc3RpbGwgYmUgcmVjb3JkZWQgaW4gUFQgdHJhY2UgKGkuZS4g dGhlc2UgdmFsdWVzIHdpbGwNCj4gYmUgbG9nZ2VkIG9uIFZNIGVudHJ5KS4NCj4gDQo+ID4NCj4g Pg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+IH5BbmRyZXcNCj4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMs DQo+IE1pY2hhxYIgTGVzemN6ecWEc2tpDQo+IENFUlQgUG9sc2thDQo= From xen-devel-bounces@lists.xenproject.org Wed Jun 17 02:19:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 02:19:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlNg0-0002xD-4g; Wed, 17 Jun 2020 02:19:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlNfy-0002x8-SB for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 02:19:42 +0000 X-Inumbo-ID: ff829024-b040-11ea-b977-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ff829024-b040-11ea-b977-12813bfff9fa; Wed, 17 Jun 2020 02:19:40 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: cJhDtZTtaIATMqqZXba+kRqLsnVGcgf+mPNLAGvGqPsXmLy3m+f1W2mplsNXiTllp1+COJrGK7 rtlxJi5lrlJVZMLWJsqL3LlP/0vJW/LGeBNDkdNe9xu+aWTSX/Y0Ps+Nyl5Scxggn49GVkN/26 lWiqURkZvgwxvspdcL0vSEdziRrREysxEW78JzcMkyIVc5wsXG9AzhfV5yZP05wKYmbutAsObK l1JnghYtCblVCJMS6Ahlqw1McjrfB111jv6njoX03JSCCL6VHLS7nyB8tg0CLJA+v2jGt7ct5H F38= X-SBRS: 2.7 X-MesageID: 20529371 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,520,1583211600"; d="scan'208";a="20529371" From: Igor Druzhinin To: Subject: [PATCH for-4.14 v3] tools/xen-ucode: return correct exit code on failed microcode update Date: Wed, 17 Jun 2020 03:19:13 +0100 Message-ID: <1592360353-31231-1-git-send-email-igor.druzhinin@citrix.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Igor Druzhinin , ian.jackson@eu.citrix.com, xadimgnik@gmail.com, wl@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Otherwise it's difficult to know if operation failed inside the automation. While at it, also switch to returning 1 and 2 instead of errno to avoid incompatibilies between errno and special exit code numbers. Signed-off-by: Igor Druzhinin --- Changes in v3: - conventionally return 1 and 2 instead of errno as exit code --- tools/misc/xen-ucode.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c index 0c257f4..ad32fac 100644 --- a/tools/misc/xen-ucode.c +++ b/tools/misc/xen-ucode.c @@ -25,7 +25,7 @@ int main(int argc, char *argv[]) fprintf(stderr, "xen-ucode: Xen microcode updating tool\n" "Usage: %s \n", argv[0]); - return 0; + exit(2); } filename = argv[1]; @@ -34,14 +34,14 @@ int main(int argc, char *argv[]) { fprintf(stderr, "Could not open %s. (err: %s)\n", filename, strerror(errno)); - return errno; + exit(1); } if ( fstat(fd, &st) != 0 ) { fprintf(stderr, "Could not get the size of %s. (err: %s)\n", filename, strerror(errno)); - return errno; + exit(1); } len = st.st_size; @@ -49,7 +49,7 @@ int main(int argc, char *argv[]) if ( buf == MAP_FAILED ) { fprintf(stderr, "mmap failed. (error: %s)\n", strerror(errno)); - return errno; + exit(1); } xch = xc_interface_open(NULL, NULL, 0); @@ -57,20 +57,23 @@ int main(int argc, char *argv[]) { fprintf(stderr, "Error opening xc interface. (err: %s)\n", strerror(errno)); - return errno; + exit(1); } ret = xc_microcode_update(xch, buf, len); if ( ret ) + { fprintf(stderr, "Failed to update microcode. (err: %s)\n", strerror(errno)); + exit(1); + } xc_interface_close(xch); if ( munmap(buf, len) ) { printf("Could not unmap: %d(%s)\n", errno, strerror(errno)); - return errno; + exit(1); } close(fd); -- 2.7.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 02:37:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 02:37:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlNwj-0004eZ-Jw; Wed, 17 Jun 2020 02:37:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlNwh-0004eU-VK for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 02:37:00 +0000 X-Inumbo-ID: 6b01640e-b043-11ea-bca7-bc764e2007e4 Received: from mail-qv1-xf44.google.com (unknown [2607:f8b0:4864:20::f44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6b01640e-b043-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 02:36:59 +0000 (UTC) Received: by mail-qv1-xf44.google.com with SMTP id cv17so324804qvb.13 for ; Tue, 16 Jun 2020 19:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=nSKfD5d2+BwYaR4WdN1c/tjc8AtQ3TM9Fxf2YQVCFdE=; b=YwITUNCPcpczVoPZlIIzNDSk2OzucWlQYkDu4bVo0ZdTWJC68P2iImasxrLTQtTQ0H zfScFHjvyfkFx0+aVu5M8fAcIE0cgIuvfU45LwzydVqr8YhIcy4mSIqGxVm1q+HVPQJx DC8FAC+w9nPFAzRhu/f0iZ27wC9iIfBfGqOFQSN2CA4AKQX+j867kHDmZYYCvhKqa+XJ ZQKTRwl1Q0qBTPqotGBjknq36prgtXssxwfW6nMMdz+5UGqfRw5T98yWm7J0PXR/yemk ozUWs7a216+r7f5PfpBPSlNmXQGrrI0bApYAethYzMHEpi8UvJC07SQTL3l95oKTuanV Lb4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=nSKfD5d2+BwYaR4WdN1c/tjc8AtQ3TM9Fxf2YQVCFdE=; b=ZmZ/hXNYHfVJq+MFWEDnIx2xvH12zhLIBkChoFxeHgJhXMMqdTMbsaQa8mcjOT20gl eTQgeNtU5YpLAS2BlsKKMqik4VV7uW/dTxrUksZ5EiOgHxkJ6dJIDmRQklTCag0r3h7B XDxPFzto3Fo1QPQO/qewG92h7LDx16wG1b0ufV3wk33T9k6Z4R3uZYbu2/OFLlptRxyT 4UmUE33uvF6efc+3eYqmCzzKtI8kk0Qv9Bo5QTeG+doySFLo0ZwVxUPxDMGDhqQo0qVv B88VM7/aSwxo7o8FVvaeE1zcn3POOcOdO+ALt1KjxNNhbiVfG5EuCCpbwEoAZfIKaiuR FnLg== X-Gm-Message-State: AOAM531jweFwg4iDHdpDBs+MMbknPuTc6iUnuNkxaI8G3ZhHv0Hy0ijM srYPO6vsGGlECJttkjFSRlbzyuiE X-Google-Smtp-Source: ABdhPJzJYrzOWey3fg0wjUkfWvus9hkPeIrZyUHTuvBAIs9L/XD59VgDkguPoTukZhZg0su1mzIRUw== X-Received: by 2002:a05:6214:405:: with SMTP id z5mr5294960qvx.112.1592361418533; Tue, 16 Jun 2020 19:36:58 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:c083:40e9:3c38:2bd9]) by smtp.gmail.com with ESMTPSA id 124sm16308558qkm.115.2020.06.16.19.36.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2020 19:36:57 -0700 (PDT) From: Jason Andryuk To: xen-devel@lists.xenproject.org Subject: [PATCH] xl: Allow shutdown wait for domain death Date: Tue, 16 Jun 2020 22:36:42 -0400 Message-Id: <20200617023642.80594-1-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" `xl shutdown -w` waits for the first of either domain shutdown or death. Shutdown is the halting of the guest operating system, and death is the freeing of domain resources. Allow specifying -w multiple times to wait for only domain death. This is useful in scripts so that all resources are free before the script continues. Signed-off-by: Jason Andryuk --- docs/man/xl.1.pod.in | 4 +++- tools/xl/xl_vmcontrol.c | 17 +++++++++++------ 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in index 09339282e6..52a47a6fbd 100644 --- a/docs/man/xl.1.pod.in +++ b/docs/man/xl.1.pod.in @@ -743,7 +743,9 @@ of a Xen system. =item B<-w>, B<--wait> -Wait for the domain to complete shutdown before returning. +Wait for the domain to complete shutdown before returning. If given once, +the wait is for domain shutdown or domain death. If given multiple times, +the wait is for domain death only. =item B<-F> diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c index 17b4514c94..435155a033 100644 --- a/tools/xl/xl_vmcontrol.c +++ b/tools/xl/xl_vmcontrol.c @@ -162,7 +162,8 @@ static void shutdown_domain(uint32_t domid, } } -static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr) +static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr, + int wait_for_shutdown_or_death) { int rc, count = 0; LOG("Waiting for %d domains", nr); @@ -183,8 +184,12 @@ static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr) case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN: LOG("Domain %d has been shut down, reason code %d", event->domid, event->u.domain_shutdown.shutdown_reason); - libxl_evdisable_domain_death(ctx, deathws[event->for_user]); - count++; + if (wait_for_shutdown_or_death) { + libxl_evdisable_domain_death(ctx, deathws[event->for_user]); + count++; + } else { + LOG("Domain %d continue waiting for death", event->domid); + } break; default: LOG("Unexpected event type %d", event->type); @@ -214,7 +219,7 @@ static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv) all = 1; break; case 'w': - wait_for_it = 1; + wait_for_it++; break; case 'F': fallback_trigger = 1; @@ -246,7 +251,7 @@ static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv) } if (deathws) { - wait_for_domain_deaths(deathws, nrdeathws); + wait_for_domain_deaths(deathws, nrdeathws, wait_for_it == 1); free(deathws); } @@ -258,7 +263,7 @@ static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv) fn(domid, wait_for_it ? &deathw : NULL, 0, fallback_trigger); if (wait_for_it) - wait_for_domain_deaths(&deathw, 1); + wait_for_domain_deaths(&deathw, 1, wait_for_it == 1); } -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 03:03:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 03:03:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlOM1-0007BU-N6; Wed, 17 Jun 2020 03:03:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlOM0-0007BP-8h for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 03:03:08 +0000 X-Inumbo-ID: 114b8b7a-b047-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 114b8b7a-b047-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 03:03:07 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id c3so642133wru.12 for ; Tue, 16 Jun 2020 20:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FjXM/IwLBHDK3QOT5MbqpDBMbj+8Bj45bhvyM2CJ014=; b=Z6M3UXff/OqFGmAWtOgpHXdFNtacX8jkQbXGLXrSaseWOFzBhbWG5Q7ULOmZaPKOGY 6g8N8tB7F13M5etl1mOobPUvAhzoBgmGSTewdCOE5siAaRxIQNLTgmVzehlDWUPcgqNS kFs8HwAq47oDSrbZ2evwstbAPkCOGeR3K/vSpct2PxiQQselgkGP/ik9Fxjd4TFLqpzl pqyX5zFwSIz+4+dtRYe9NZ3Er9a3XvXz0oA3PmfS3AL8U3Nfg4RGYFyh112D9MdAalvR txE8F06CPmemK8Au7iUcnzA3LmNSHNWwExPQ3ZAGhb9DkoQErMnGh6e5nJf9gpMSk/Jj OGIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FjXM/IwLBHDK3QOT5MbqpDBMbj+8Bj45bhvyM2CJ014=; b=ELilvD5MUoo9v9W1pRqPUxRLyZufYUJqTHA1PmyV9dy05iNNUGdN9CI9kLH+N4Ijh3 i4Q2feLlj+D6EgMKHN4Z8jrbUSLYRdXaki9FiUZ5FsFu+7O57s3MrEy3VsXBZTAYKz/3 3Z8K34wvKLPQo9GeNmHHtmmUkEr6CUw1ZecSdt2EmM/WVYO47EhhdNJhKNj8g+Eo0YNc lY0llEZqEprwNT+iTJIp+YIkjZ5PFMGhbGK6c10xQjaN0Rz7tdKA/9r0t9jkxTaqbJbC hUy9dGdUsLQtKQ454Tb7s3wJXBALDuv2G3xHdMZSyCkhkpw+WCvWB+0GYiA6oj9hibvO afPw== X-Gm-Message-State: AOAM531b5ds19xvQ05BL9lTtYnkCfZiVm8ipbeZCbx2zgZKM1BCAqwua mXmV8ozKisKSz6iCwFROT60OXT03DHKaN2dRVMc= X-Google-Smtp-Source: ABdhPJzTa2JS66zBqAwQsijJblHvayeP4S+qH9M5g4GLHVBkvGlktEcA672mNhOcwlDP/9txArMrEhHLFkQznWVG+aM= X-Received: by 2002:a5d:490f:: with SMTP id x15mr5883871wrq.259.1592362986226; Tue, 16 Jun 2020 20:03:06 -0700 (PDT) MIME-Version: 1.0 References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> In-Reply-To: From: Tamas K Lengyel Date: Tue, 16 Jun 2020 21:02:30 -0600 Message-ID: Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring To: Andrew Cooper Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper w= rote: > > On 16/06/2020 19:47, Micha=C5=82 Leszczy=C5=84ski wrote: > > ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com napi= sa=C5=82(a): > > > >> Are there any restrictions on EPT being enabled in the first place? I= 'm > >> not aware of any, and in principle we could use this functionality for > >> PV guests as well (using the CPL filter). Therefore, I think it would > >> be helpful to not tie the functionality to HVM guests, even if that is > >> the only option enabled to start with. > > I think at the moment it's not required to have EPT. This patch series = doesn't use any translation feature flags, so the output address is always = a machine physical address, regardless of context. I will check if it could= be easily used with PV. > > If its trivial to add PV support then please do. If its not, then don't > feel obliged, but please do at least consider how PV support might look > in the eventual feature. > > (Generally speaking, considering "how would I make this work in other > modes where it is possible" leads to a better design.) > > >> The buffer mapping and creation logic is fairly problematic. Instead = of > >> fighting with another opencoded example, take a look at the IOREQ > >> server's use of "acquire resource" which is a mapping interface which > >> supports allocating memory on behalf of the guest, outside of the gues= t > >> memory, for use by control tools. > >> > >> I think what this wants is a bit somewhere in domain_create to indicat= e > >> that external tracing is used for this domain (and allocate whatever > >> structures/buffers are necessary), acquire resource to map the buffers > >> themselves, and a domctl for any necessary runtime controls. > >> > > I will check this out, this sounds like a good option as it would remov= e lots of complexity from the existing ipt_enable domctl. > > Xen has traditionally opted for a "and turn this extra thing on > dynamically" model, but this has caused no end of security issues and > broken corner cases. > > You can see this still existing in the difference between > XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being > required to chose the number of vcpus for the domain) and we're making > good progress undoing this particular wart (before 4.13, it was > concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by > issuing other hypercalls between these two). > > There is a lot of settings which should be immutable for the lifetime of > the domain, and external monitoring looks like another one of these. > Specifying it at createdomain time allows for far better runtime > behaviour (you are no longer in a situation where the first time you try > to turn tracing on, you end up with -ENOMEM because another VM booted in > the meantime and used the remaining memory), and it makes for rather > more simple code in Xen itself (at runtime, you can rely on it having > been set up properly, because a failure setting up will have killed the > domain already). I'm not in favor of this being a flag that gets set during domain creation time. It could certainly be the case that some users would want this being on from the start till the end but in other cases you may want to enable it intermittently only for some time in-between particular events. If it's an on/off flag during domain creation you pretty much force that choice on the users and while the overhead of PT is better than say MTF it's certainly not nothing. In case there is an OOM situation enabling IPT dynamically the user can always just pause the VM and wait till memory becomes available. > > >> What semantics do you want for the buffer becoming full? Given that > >> debugging/tracing is the goal, I presume "pause vcpu on full" is the > >> preferred behaviour, rather than drop packets on full? > >> > > Right now this is a ring-style buffer and when it would become full it = would simply wrap and override the old data. > > How does the consumer spot that the data has wrapped? What happens if > data starts getting logged, but noone is listening? What happens if the > consumer exits/crashes/etc and stops listening as a consequence? > > It's fine to simply state what will happen, and possibly even "don't do > that then", but the corner cases do at least need thinking about. AFAIU the current use-case is predominantly to be used in conjunction with VMI events where you want to be able to see the trace leading up to a particular vmexit. So in the case when the buffer is wrapped in-between events and data is lost that's not really of concern. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 03:06:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 03:06:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlOPd-0007MX-7f; Wed, 17 Jun 2020 03:06:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlOPb-0007MR-Tc for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 03:06:51 +0000 X-Inumbo-ID: 96fd4fe2-b047-11ea-bca7-bc764e2007e4 Received: from mail-pf1-x443.google.com (unknown [2607:f8b0:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 96fd4fe2-b047-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 03:06:51 +0000 (UTC) Received: by mail-pf1-x443.google.com with SMTP id 23so415292pfw.10 for ; Tue, 16 Jun 2020 20:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=dq2SjmoQupE4U9LhXdo/f9IZ6YV5RooIfJwqe+qSBlg=; b=cRtzcfZIAK/fnCW3uavu1pTWu4tlI6Gez8w4jjX7ksTVmViB2GmyPtbfv4pHB2N0B7 52+2ATk8e+AdXsI+gEvmXN+4fq+8vjqv5o1Q0+Vd0gW34QPnbxztqI7LwNR9biWgAZ+K iouMSgsyC99J7dM0nr1U+0TzVOj6EhcTo2mWN62PK3JzQGIoX4VIrHq49FgsD5+CV6F5 qU4zo67ue4q3ETFJqak0LoXVYaD8bpLC4qjg64CJULa32Hlk6S/kdBQ2e+0k+xTrp5Ap r2l0ZLwk0wBa1V5SVadZXT7AZlW/xY4KUHIACaXXJvCEgsyULxXV6Kpj0/Uv1SEvLz6T rMxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=dq2SjmoQupE4U9LhXdo/f9IZ6YV5RooIfJwqe+qSBlg=; b=hORn5p17sHhQpeBUECYZqH+SbV/gvZteRVgMX5dIg7ZmA6ZS0arz1AbZKgGkjTIA2U JqBmK9eqngpxXZRNW+8z7tTGp8onjoVNWRuf/CWZqTirJ+qtY+AUbNzjtypkYLTyoPNx GbIx2s3LfSPGoWNvuFGGoE0m/JFux75/g4n8gLu6lS05xpiVE3dwMNkV2uvanHra9FmK gB+JCcvsTqsMLEfbqFyB0UfVa9y7kMC8P5prvy9+EeU6qouzGwoN+0WujfymYqRPYvgp leiMvD4QnMVrH/OLdvhLdcfVxSIuS/CFoysZ8IvE+rabMCPtOCR//8SVz5QuHs69q2l7 aEjQ== X-Gm-Message-State: AOAM531mQFmIi9AI9nm5uccO+UNgbmtVwrD231Zs53YAmNei/KTJu8NA 2xpUQM8ut4viA0P4E9FRJ2Y= X-Google-Smtp-Source: ABdhPJw//k0NXcYX0XzZ+Ih/gjrZwd7t+FwVka95iS2KhwMy/vQRUu8NT/fZjBz2+jqHCu7RJ8h7ag== X-Received: by 2002:a63:4822:: with SMTP id v34mr3878745pga.81.1592363210656; Tue, 16 Jun 2020 20:06:50 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC.domain.name ([122.171.213.184]) by smtp.gmail.com with ESMTPSA id g19sm18210446pfo.209.2020.06.16.20.06.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2020 20:06:49 -0700 (PDT) From: Souptick Joarder To: boris.ostrovsky@oracle.com, jgross@suse.com, sstabellini@kernel.org Subject: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() Date: Wed, 17 Jun 2020 08:44:58 +0530 Message-Id: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> X-Mailer: git-send-email 1.9.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, John Hubbard , Souptick Joarder Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In 2019, we introduced pin_user_pages*() and now we are converting get_user_pages*() to the new API as appropriate. [1] & [2] could be referred for more information. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: Souptick Joarder Cc: John Hubbard --- Hi, I have compile tested this patch but unable to run-time test, so any testing help is much appriciated. Also have a question, why the existing code is not marking the pages dirty (since it did FOLL_WRITE) ? drivers/xen/privcmd.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index a250d11..543739e 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -594,7 +594,7 @@ static int lock_pages( if (requested > nr_pages) return -ENOSPC; - pinned = get_user_pages_fast( + pinned = pin_user_pages_fast( (unsigned long) kbufs[i].uptr, requested, FOLL_WRITE, pages); if (pinned < 0) @@ -614,10 +614,7 @@ static void unlock_pages(struct page *pages[], unsigned int nr_pages) if (!pages) return; - for (i = 0; i < nr_pages; i++) { - if (pages[i]) - put_page(pages[i]); - } + unpin_user_pages(pages, nr_pages); } static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) -- 1.9.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 03:16:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 03:16:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlOZ7-0008Hw-5m; Wed, 17 Jun 2020 03:16:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlOZ5-0008Hr-W4 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 03:16:40 +0000 X-Inumbo-ID: f4eb053a-b048-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f4eb053a-b048-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 03:16:38 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: uQjg1G0HvWxXWfGi5qH+NbnaYb7nco842zSXOWROgXsraU0tqCAnSMctSOGz8ZWTnN6Sre2lyY ShwG2mKWSKGsRkivYDUisV0EFyZkEQhIXs5C//Y+K2puS2TC3L1Aqeh6tOZr1vZFSsucHcImel OExCxLoTaRumjDNqRxUvX1F8MqUB54+IK6UTH9I5LES+ykWuTjHiW2LHocFN/b9hv6eKel4ELr SPRHCSqwVjEjv2xp7QifZk5E+hNxTYKkV0qrqhlk79gHDWP7E0VEtcarQGt10UJdSCvElT47NY HE4= X-SBRS: 2.7 X-MesageID: 20575272 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,521,1583211600"; d="scan'208";a="20575272" Subject: Re: [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load To: Laszlo Ersek , , xen-devel References: <1592275782-9369-1-git-send-email-igor.druzhinin@citrix.com> From: Igor Druzhinin Message-ID: <17ee2671-c44b-f3fb-43af-0a75f7d161fc@citrix.com> Date: Wed, 17 Jun 2020 04:16:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: julien@xen.org, jordan.l.justen@intel.com, Ray Ni , ard.biesheuvel@arm.com, anthony.perard@citrix.com, Paolo Bonzini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 19:42, Laszlo Ersek wrote > If I understand correctly, TimerInterruptHandler() > [OvmfPkg/8254TimerDxe/Timer.c] currently does the following: > > - RaiseTPL (TPL_HIGH_LEVEL) --> mask interrupts from being delivered > > - mLegacy8259->EndOfInterrupt() --> permit the PIC to generate further > interrupts (= make them pending) > > - RestoreTPL() --> unmask interrupts (allow delivery) > > RestoreTPL() is always expected to invoke handlers (on its own stack) > that have just been unmasked, so that behavior is not unexpected, in my > opinion. Yes, this is where I'd like to have a confirmation - opening a window for uncontrollable number of nested interrupts with a small stack looks dangerous. > What seems unexpected is the queueing of a huge number of timer > interrupts. I would think a timer interrupt is either pending or not > pending (i.e. if it's already pending, then the next generated interrupt > is coalesced, not queued). While there would still be a window between > the EOI and the unmasking, I don't think it would normally allow for a > *huge* number of queued interrupts (and consequently a stack overflow). It's not a window between EOI and unmasking but the very fact vCPU is descheduled for a considerable amount of time that causes backlog of timer interrupts to build up. This is Xen default behavior and is configurable (there are several timer modes including coalescing you mention). That is done for compatibility with some guests basing time accounting on the number of periodic interrupts they receive. > So I basically see the root of the problem in the interrupts being > queued rather than coalesced. I'm pretty unfamiliar with this x86 area > (= the 8259 PIC in general), but the following wiki article seems to > agree with my suspicion: > > https://wiki.osdev.org/8259_PIC#How_does_the_8259_PIC_chip_work.3F > > [...] and whether there's an interrupt already pending. If the > channel is unmasked and there's no interrupt pending, the PIC will > raise the interrupt line [...] > > Can we say that the interrupt queueing (as opposed to coalescing) is a > Xen issue? I can admit that the whole issue might be Xen specific if that form of timer mode is not used in QEMU-KVM. What mode is typical there then? We might consider switching Xen to a different mode if so, as I believe those guests are not in support for many years. > (Hmmm... maybe the hypervisor *has* to queue the timer interrupts, > otherwise some of them would simply be lost, and the guest would lose > track of time.) > > Either way, I'm not sure what the best approach is. This driver was > moved under OvmfPkg from PcAtChipsetPkg in commit 1a3ffdff82e6 > ("OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg", 2019-04-11). > HpetTimerDxe also lives under PcAtChipsetPkg. > > So I think I'll have to rely on the expertise of Ray here (CC'd). Also note that since the issue might be Xen specific we might want to try to fix it in XenTimer only - I modified 8254Timer due to the fact Xen is still present in general config (but that should soon go away). > Also, I recall a recent-ish QEMU commit that seems vaguely related > (i.e., to timer interrupt coalescing -- see 7a3e29b12f5a, "mc146818rtc: > fix timer interrupt reinjection again", 2019-11-19), so I'm CC'ing Paolo > too. Hmm that looks more like a RTC implementation specific issue. > Some more comments / questions below: > >> >> diff --git a/OvmfPkg/8254TimerDxe/Timer.c b/OvmfPkg/8254TimerDxe/Timer.c >> index 67e22f5..fd1691b 100644 >> --- a/OvmfPkg/8254TimerDxe/Timer.c >> +++ b/OvmfPkg/8254TimerDxe/Timer.c >> @@ -79,8 +79,6 @@ TimerInterruptHandler ( >> >> OriginalTPL = gBS->RaiseTPL (TPL_HIGH_LEVEL); >> >> - mLegacy8259->EndOfInterrupt (mLegacy8259, Efi8259Irq0); >> - >> if (mTimerNotifyFunction != NULL) { >> // >> // @bug : This does not handle missed timer interrupts >> @@ -89,6 +87,9 @@ TimerInterruptHandler ( >> } >> >> gBS->RestoreTPL (OriginalTPL); >> + >> + DisableInterrupts (); >> + mLegacy8259->EndOfInterrupt (mLegacy8259, Efi8259Irq0); >> } > > So this briefly (temporarily) unmasks interrupt delivery (between > RestoreTPL() and DisableInterrupts()) while the PIC is still blocked > from generating more, and then unblocks the PIC. > > It looks plausible for preventing the unbounded recursion per se, but > why is it safe to leave the function with interrupts disabled? Before > the patch, that didn't use to be the case. Quickly looking through the code it appears to me the first thing that caller does after interrupt handler - it clears interrupt flag to make sure those disabled. So I don't see any assumption that interrupts should be enabled on exiting. But I might not know about all of the possible combinations here. Igor From xen-devel-bounces@lists.xenproject.org Wed Jun 17 06:00:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 06:00:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlR6x-0005Tu-CQ; Wed, 17 Jun 2020 05:59:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlR6v-0005Tp-O2 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 05:59:45 +0000 X-Inumbo-ID: bbfe51de-b05f-11ea-b995-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bbfe51de-b05f-11ea-b995-12813bfff9fa; Wed, 17 Jun 2020 05:59:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BLkjDylnW88WfpG1wA8KCgi7WUJx+N/X+hLt6CYiPKo=; b=W8wNlb5X09YlU3sFBZ9Yvb9zs DSHNtqk+es65SI6Sl+Jw5c/e9UJuIV4AtM/oIvKZTN05CRd12IEEWu7u1KDSLkAl2eAHZBCMvqUyr g4KKkSDh6x+YTMuBZoHiYox5TPd3hJY7MBdplvddZ9wQtt68EdkpYoCHujYPoTytPIFMc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlR6q-00034c-F1; Wed, 17 Jun 2020 05:59:40 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlR6p-0002kU-Ve; Wed, 17 Jun 2020 05:59:40 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlR6p-00081z-Ug; Wed, 17 Jun 2020 05:59:39 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151155: tolerable FAIL X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=b91825f628c9a62cf2a3a0d972ea81484a8b7fce X-Osstest-Versions-That: xen=b91825f628c9a62cf2a3a0d972ea81484a8b7fce From: osstest service owner Date: Wed, 17 Jun 2020 05:59:39 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151155 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151155/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151118 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151118 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151118 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151118 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151118 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151118 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151118 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151118 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151118 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce baseline version: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce Last test of basis 151155 2020-06-15 17:20:09 Z 1 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Wed Jun 17 06:09:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 06:09:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlRFu-0006W1-9e; Wed, 17 Jun 2020 06:09:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlRFs-0006Vu-9j for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 06:09:01 +0000 X-Inumbo-ID: 078b6d8e-b061-11ea-b7bb-bc764e2007e4 Received: from mo4-p00-ob.smtp.rzone.de (unknown [85.215.255.20]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 078b6d8e-b061-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 06:08:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592374137; s=strato-dkim-0002; d=aepfle.de; h=Message-Id:Date:Subject:Cc:To:From:X-RZG-CLASS-ID:X-RZG-AUTH:From: Subject:Sender; bh=BPYpE9GksVEBqAS0fZJlKXX9acwPilfaAPWjwRABGJo=; b=AC8gwV4pgt0HB3V79wmnnfRHrfvykVtFBM01ZZ48yWKy3zEX2Y3AJOc5s0DsR0NiJr z9pua3jb9FeX86x560sQWZ88IsTmhBa7xnYu01LHtdknR8phrdgPx0PgPvSZMFVTBts5 dktq/NvXhkmvVo7G1SmlZWGmiXDmRpsVdEROT//fEXpsEn96r982t5+hPU0NgixKa77E vGTzeOwKN+XM5DBOGhUu/CfDwMkgWD0HeRNpCmWjtRLYKWluE2uFbu1UQEdcn5JJOYLo ugMcZiXRQov+lWGi6JzEdxxRMuAFcjqnpxzdnM30avl638xPNm1WJwx4t8TOCp2Biuy9 xRvQ== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QXkBR9MXjAuzBW/OdlBZQ4AHSS3GpKjw==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.10.4 DYNA|AUTH) with ESMTPSA id 0013a0w5H68mGuq (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) (Client did not present a certificate); Wed, 17 Jun 2020 08:08:48 +0200 (CEST) From: Olaf Hering To: xen-devel@lists.xenproject.org Subject: [PATCH v1] stubdom/vtpm: add extern to function declarations Date: Wed, 17 Jun 2020 08:08:41 +0200 Message-Id: <20200617060841.7241-1-olaf@aepfle.de> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Samuel Thibault , Olaf Hering , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Code compiled with gcc10 will not link properly due to multiple definition of the same function. Signed-off-by: Olaf Hering --- stubdom/Makefile | 1 + stubdom/vtpm_extern.patch | 48 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+) create mode 100644 stubdom/vtpm_extern.patch diff --git a/stubdom/Makefile b/stubdom/Makefile index 12aa211ac3..af8cde41b9 100644 --- a/stubdom/Makefile +++ b/stubdom/Makefile @@ -231,6 +231,7 @@ tpm_emulator-$(XEN_TARGET_ARCH): tpm_emulator-$(TPMEMU_VERSION).tar.gz patch -d $@ -p1 < vtpm-cmake-Wextra.patch patch -d $@ -p1 < vtpm-implicit-fallthrough.patch patch -d $@ -p1 < vtpm_TPM_ChangeAuthAsymFinish.patch + patch -d $@ -p1 < vtpm_extern.patch mkdir $@/build cd $@/build; CC=${CC} $(CMAKE) .. -DCMAKE_C_FLAGS:STRING="-std=c99 -DTPM_NO_EXTERN $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -Wno-declaration-after-statement" touch $@ diff --git a/stubdom/vtpm_extern.patch b/stubdom/vtpm_extern.patch new file mode 100644 index 0000000000..5ea4023e6d --- /dev/null +++ b/stubdom/vtpm_extern.patch @@ -0,0 +1,48 @@ +ld: /home/abuild/rpmbuild/BUILD/xen-4.8.20191211T160002.8db85532cb/non-dbg/stubdom/vtpm/vtpm.a(vtpm_cmd.o):(.bss+0x28): multiple definition of `tpm_malloc'; /home/abuild/rpmbuild/BUILD/xen-4.8.20191211T160002.8db85532cb/non-dbg/stubdom/vtpm/vtpm.a(vtpm.o):(.bss+0x728): first defined here +--- a/tpm/tpm_emulator_extern.h ++++ b/tpm/tpm_emulator_extern.h +@@ -29,7 +29,7 @@ enum { + TPM_LOG_ERROR + }; + +-void (*tpm_log)(int priority, const char *fmt, ...); ++extern void (*tpm_log)(int priority, const char *fmt, ...); + + #if defined(_WIN32) || defined(_WIN64) + #define __BFILE__ ((strrchr(__FILE__, '\\') ? : __FILE__ - 1) + 1) +@@ -44,27 +44,27 @@ void (*tpm_log)(int priority, const char + #define error(fmt, ...) tpm_log(TPM_LOG_ERROR, "%s:%d: Error: " fmt "\n", \ + __BFILE__, __LINE__, ## __VA_ARGS__) + /* initialization */ +-int (*tpm_extern_init)(void); +-void (*tpm_extern_release)(void); ++extern int (*tpm_extern_init)(void); ++extern void (*tpm_extern_release)(void); + + /* memory allocation */ + +-void* (*tpm_malloc)(size_t size); ++extern void* (*tpm_malloc)(size_t size); + +-void (*tpm_free)(/*const*/ void *ptr); ++extern void (*tpm_free)(/*const*/ void *ptr); + + /* random numbers */ + +-void (*tpm_get_extern_random_bytes)(void *buf, size_t nbytes); ++extern void (*tpm_get_extern_random_bytes)(void *buf, size_t nbytes); + + /* usec since last call */ + +-uint64_t (*tpm_get_ticks)(void); ++extern uint64_t (*tpm_get_ticks)(void); + + /* file handling */ + +-int (*tpm_write_to_storage)(uint8_t *data, size_t data_length); +-int (*tpm_read_from_storage)(uint8_t **data, size_t *data_length); ++extern int (*tpm_write_to_storage)(uint8_t *data, size_t data_length); ++extern int (*tpm_read_from_storage)(uint8_t **data, size_t *data_length); + + #endif /* _TPM_EMULATOR_EXTERN_H_ */ + From xen-devel-bounces@lists.xenproject.org Wed Jun 17 06:15:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 06:15:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlRLo-0007LN-0N; Wed, 17 Jun 2020 06:15:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlRLl-0007LI-RN for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 06:15:06 +0000 X-Inumbo-ID: e1a39a50-b061-11ea-b7bb-bc764e2007e4 Received: from mo4-p01-ob.smtp.rzone.de (unknown [81.169.146.166]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e1a39a50-b061-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 06:15:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592374503; s=strato-dkim-0002; d=aepfle.de; h=Message-Id:Date:Subject:Cc:To:From:X-RZG-CLASS-ID:X-RZG-AUTH:From: Subject:Sender; bh=LleofVG/8ySnMgVXLkfGiWlGl5Zthgo4wUc7zE2IRkw=; b=OJYblfXrv6ui9mwQt4uWQ5jClpn9/XTvMDD8n3KurA9SFfl31HOzObQqPfIa76l5Ll bWq+ceExjAAlTEauMBs4gJxctpWGmNrvm/4fDQN3PpmGdCaYNf+7E53qY7m3R7fKWqrk 1HO2ff4GX9DN6ruRPt84jG9294iCxCOqVgV9dhCHyphcTqbSN5l2Io76J4JVoGBgqDSG uajN3wG3Ouiv1PNc+0DGOEesTbA36APny4Cq9WEqLZVs73GvhdPmbamiA+xIJEMXSOBs oTdc+TpjzgHtYUmck7x/ryT+lQ2sVqriNSez1Kl9SQ1kko9fpvEtjUish2nNO9r5Sa6t FW4Q== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QXkBR9MXjAuzBW/OdlBZQ4AHSS3GpKjw==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.10.4 DYNA|AUTH) with ESMTPSA id 0013a0w5H6DpGvs (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) (Client did not present a certificate); Wed, 17 Jun 2020 08:13:51 +0200 (CEST) From: Olaf Hering To: xen-devel@lists.xenproject.org Subject: [PATCH v1] stubdom/vtpmmgr: simplify handling of hardware_version Date: Wed, 17 Jun 2020 08:13:49 +0200 Message-Id: <20200617061349.7623-1-olaf@aepfle.de> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Samuel Thibault , Olaf Hering , Quan Xu , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Remove complicated code which deals with a simple boolean, to make gcc10 happy. ld: /home/abuild/rpmbuild/BUILD/xen-4.14.20200616T103126.3625b04991/non-dbg/stubdom/vtpmmgr/vtpmmgr.a(vtpm_cmd_handler.o):(.bss+0x0): multiple definition of `tpm_version'; /home/abuild/rpmbuild/BUILD/xen-4.14.20200616T103126.3625b04991/non-dbg/stubdom/vtpmmgr/vtpmmgr.a(vtpmmgr.o):(.bss+0x0): first defined here Signed-off-by: Olaf Hering --- stubdom/vtpmmgr/vtpmmgr.c | 8 +++----- stubdom/vtpmmgr/vtpmmgr.h | 9 --------- 2 files changed, 3 insertions(+), 14 deletions(-) diff --git a/stubdom/vtpmmgr/vtpmmgr.c b/stubdom/vtpmmgr/vtpmmgr.c index 9fddaa24f8..94578adbff 100644 --- a/stubdom/vtpmmgr/vtpmmgr.c +++ b/stubdom/vtpmmgr/vtpmmgr.c @@ -45,9 +45,7 @@ #include "vtpmmgr.h" #include "tcg.h" -struct tpm_hardware_version hardware_version = { - .hw_version = TPM1_HARDWARE, -}; +static int hardware_version; int parse_cmdline_hw(int argc, char** argv) { @@ -55,7 +53,7 @@ int parse_cmdline_hw(int argc, char** argv) for (i = 1; i < argc; ++i) { if (!strcmp(argv[i], TPM2_EXTRA_OPT)) { - hardware_version.hw_version = TPM2_HARDWARE; + hardware_version = 2; break; } } @@ -64,7 +62,7 @@ int parse_cmdline_hw(int argc, char** argv) int hw_is_tpm2(void) { - return (hardware_version.hw_version == TPM2_HARDWARE) ? 1 : 0; + return hardware_version == 2 ? 1 : 0; } void main_loop(void) { diff --git a/stubdom/vtpmmgr/vtpmmgr.h b/stubdom/vtpmmgr/vtpmmgr.h index 2e6f8de9e4..6523604bdc 100644 --- a/stubdom/vtpmmgr/vtpmmgr.h +++ b/stubdom/vtpmmgr/vtpmmgr.h @@ -50,16 +50,7 @@ #define RSA_KEY_SIZE 0x0800 #define RSA_CIPHER_SIZE (RSA_KEY_SIZE / 8) -enum { - TPM1_HARDWARE = 1, - TPM2_HARDWARE, -} tpm_version; -struct tpm_hardware_version { - int hw_version; -}; - -extern struct tpm_hardware_version hardware_version; struct vtpm_globals { int tpm_fd; From xen-devel-bounces@lists.xenproject.org Wed Jun 17 06:16:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 06:16:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlRNZ-0007Up-DI; Wed, 17 Jun 2020 06:16:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlRNY-0007Uk-Cq for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 06:16:56 +0000 X-Inumbo-ID: 24790a4a-b062-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x643.google.com (unknown [2a00:1450:4864:20::643]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 24790a4a-b062-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 06:16:55 +0000 (UTC) Received: by mail-ej1-x643.google.com with SMTP id dr13so1013124ejc.3 for ; Tue, 16 Jun 2020 23:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to; bh=uIcdwr+mp7f2wJok//eahZc0osapd1m51kkI8OF62L4=; b=RbhVHUM5/yOPJ+UzO5lvcnShygKuDAfae6Fn0znZQhnQQT6Uk+dIf4qfFp5UI5FX4N GhPEyfaUHvnpEwV9dTUnUuuECkZ2+SHfnlhSLuQlmNWGb5Sgh0HVexJQjFDJ8gVU1c1o Ux1ld18V9qVIEl1Wmx24LPGjrNhVyynpTIYR3uZKLnkKiaYdj3zDU7aKdMwGsvbdLKCG Fw1eCF73kYjtgew0/ejUJAqseMInB3IIF9Xtb3WM1FWA/4MqHbs+FRsy6sXkmUtdUJH0 OOV7Sy1NNuqYfTaB5lY3mRoFzRxFxm7gp3fzfVWQGX23oHzxckLvtScy1GbAIwxJeFDW Juyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=uIcdwr+mp7f2wJok//eahZc0osapd1m51kkI8OF62L4=; b=AN1fZ7CjPBVCFzF8/sAbJh5QGZCy3gcd1PxbMa5EYimvRVyqetfnb/xcbNO031IW+E NR0Br2INGnXnc7vVQVUpKrqY+rLI6MViSlCNIYk5RXVgj+vFRdUaamo/l7BAsT2gjh2s Z1ewUJMFiWaEEI3vw8yeLYAyBjK+pizZrUV+wzkkHvKmYdNFq2i6uAhKvDONOgC5uLvc SABWv0jqLKMKWkseg8I8ZWn2QrCSpRsjUz4yudVyDptUhs3KtktTWg6YFBCVq1Nnikyo IZp6dWYIy3EBsKVAdTSXKMqiaYQPj/++OJaSFDMElCk0z238wnDxZVpCmd9aJNVvlKja zBOw== X-Gm-Message-State: AOAM533S1GBaVtGvknuhhCgMElSKsvTJ5YeKpDy3SdledFnL2sekbl82 1DMAO3Edh3pphjZHiKoG5dk= X-Google-Smtp-Source: ABdhPJyHMoJJ7xfHPdZmT9ioF3bvSs7ZRoc+/5gB5+JJyQMdxp3FAp3ZtrObWlifham9qQBNVLaahQ== X-Received: by 2002:a17:906:3282:: with SMTP id 2mr5899611ejw.93.1592374615005; Tue, 16 Jun 2020 23:16:55 -0700 (PDT) Received: from [192.168.8.124] (public-gprs354212.centertel.pl. [37.47.14.229]) by smtp.gmail.com with ESMTPSA id y2sm12509814ejj.103.2020.06.16.23.16.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Jun 2020 23:16:54 -0700 (PDT) Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Jan Beulich References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> <20200616145951.GP735@Air-de-Roger> <20200616152515.GQ735@Air-de-Roger> From: Grzegorz Uriasz Autocrypt: addr=gorbak25@gmail.com; prefer-encrypt=mutual; keydata= mQENBFyZgUUBCACo21Uf58hRRgX0uQd3kRJUqXp8/kJsC58tKZG9ENy8rvmcq15AmblqOQnD k6Pmh2lhh31A+m4ONF+TT0vlFYv9sN0kA1llvHPH95LYhROXt7UwSZBQTnQlLZFVqeGa3R6M pJwaAMQP/lyYgINt1pvBdCWtcNP/wKuNI/efnZuBOPDKSeBH/V0ZmmZxlSsx05/ktgtR6ibP FZXPBgx5DY0DxPm/jb8CqkXO5291wyYCP2VDy85oqG8EgsfFOOPZNwBQCKS7cWLZDMEsVNnB WyU3zJZBvEVK/5BwIzm1+AL9lR6RRLaOpC19k2ZqbyhEG9EhsR+/DIF0znBd9Nhjokd5ABEB AAG0JEdyemVnb3J6IFVyaWFzeiA8Z29yYmFrMjVAZ21haWwuY29tPokBVwQTAQgAQQIbAwUJ A8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHDkRnQjCGTnaTo/LngD9fcXMA1pBQJd /5CUAhkBAAoJEHgD9fcXMA1pb9YIAICTmZOrEGho9MC7z851jw507EamIqaAXQAADKpbxSGH yVxALYZv6cqR84rsQuML0N8ai4rdCJ7PviMYyaWVX3P09kJoFxSzKhjxbwZMkRF8O+9tIhNO 29h8v5cmv7Sp4NpssITFMZAms4LleJtdkivDeRxSCyJnHceZyGiD6pPTkopyuISGZIS+4axF zarn+JM+uiTm1QHdCbcvK3sor//QvHr9kKjLKTxMwiTZOGQzF8+oHpVxxwX8Bz3UbFwRX/Io rErT92f9WOsFWnvZHuLGcRLSlG0h9xljIuhP7mvGiudTgNoPt9YFtAG8KT/2HnUZ4XxJKi+B 8Ilet++3m4m5AQ0EXJmBRQEIANBww0bVhYwP1g4AMux/Fjp7KUjYj7Q8ej+t71ShZkAzvPQT 00ULdnYEa62uKM9YwXqOu0XJsnBveJKO1q3nfJuazAbsC0B3v0bYlUUQoTRxCUs3v22UOVxe kaTtN3KDdnSTq7QkkZBZFvV+vAwKGlqECzsYtZ86CiIEOgmUeVA82AzyMx306l1th90OdHYt LKkHxreEPWInN9jptOaKNwvB5cR6PxFfVRtVteN121tVJRK5geA0RVjHn35ig97ycDP5FcwP HuuuKfr+07ANXrtFM/QLGmIvEaMEgpPmzyGkXGhbsDpMikHOkXvQCRTesJ38r8DRUffinYXI vAw0IsMAEQEAAYkBPAQYAQgAJhYhBHDkRnQjCGTnaTo/LngD9fcXMA1pBQJcmYFFAhsMBQkD wmcAAAoJEHgD9fcXMA1p3y8H/2nftQbUcb2oKtpyePStdmdN45A1OWjorj6iBRvTOhoig6y7 PbveJ9Zj35IP0Zy4W77Ke4ayK/PiBkh7bRrdQAwTAc7EiYw3j+foO32JA/4bANMgSuRBxO/d xoloRPoaRE6eGUkA3N65V5WlWkinKxzSGDgSOz7Tit5QY8fGJYWeLTzFj605Y9iUu0MSLpfs LQQby+I9gETWh5TUMz1uNytIB80UdMpzqcC36zCMk7wIy1g8YhbehJq1zU1+ZpDrggrN3ucH 0NFFvHq5uwEkR8Llj29nDcyKuWMlnCMpM/iJcTde7N8UVdtN9yBGol4+yAZT0w5RP87pw3oD fuZMcoY= Message-ID: <4787679a-1f1a-5905-b130-a95a5542c7be@gmail.com> Date: Wed, 17 Jun 2020 08:16:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200616152515.GQ735@Air-de-Roger> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NSPFRzh7CyNbmQ9xlGrzZYSQtQ9cyNCsi" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NSPFRzh7CyNbmQ9xlGrzZYSQtQ9cyNCsi Content-Type: multipart/mixed; boundary="EZNMNhLYqG2sI4JEpgLTcNiA7zlGfs2qB"; protected-headers="v1" From: Grzegorz Uriasz To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , marmarek@invisiblethingslab.com, artur@puzio.waw.pl, jakub@bartmin.ski, j.nowak26@student.uw.edu.pl Message-ID: <4787679a-1f1a-5905-b130-a95a5542c7be@gmail.com> Subject: Re: [PATCH 1/1] x86/acpi: Use FADT flags to determine the PMTMR width References: <6b921b43-03f6-448c-297e-8c8f041eea2a@suse.com> <20200616103204.GN735@Air-de-Roger> <20200616145951.GP735@Air-de-Roger> <20200616152515.GQ735@Air-de-Roger> In-Reply-To: <20200616152515.GQ735@Air-de-Roger> --EZNMNhLYqG2sI4JEpgLTcNiA7zlGfs2qB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US I will submit the v2 patch today. Best Regards, Grzegorz On 16/06/2020 17:25, Roger Pau Monn=C3=A9 wrote: > On Tue, Jun 16, 2020 at 05:11:58PM +0200, Jan Beulich wrote: >> On 16.06.2020 16:59, Roger Pau Monn=C3=A9 wrote: >>> On Tue, Jun 16, 2020 at 03:25:42PM +0200, Jan Beulich wrote: >>>> --- unstable.orig/xen/arch/x86/acpi/boot.c >>>> +++ unstable/xen/arch/x86/acpi/boot.c >>>> @@ -480,7 +480,9 @@ static int __init acpi_parse_fadt(struct >>>> if (fadt->header.revision >=3D FADT2_REVISION_ID) { >>>> /* FADT rev. 2 */ >>>> if (fadt->xpm_timer_block.space_id =3D=3D >>>> - ACPI_ADR_SPACE_SYSTEM_IO) { >>>> + ACPI_ADR_SPACE_SYSTEM_IO && >>>> + (fadt->xpm_timer_block.access_width =3D=3D 0 || >>>> + fadt->xpm_timer_block.access_width =3D=3D 3)) { >>> We should really have defines for those values, or else they seem to >>> imply actual access sizes. What about adding >>> ACPI_ADDR_ACCESS_{LEGACY,BYTE,WORD,DWORD,QWORD}? >> If there were such defines, I'd have used them. Adding them is >> inappropriate though, as this would modify an imported header in a >> Xen-specific way. We could leverage ACPI_ACCESS_BIT_WIDTH() here, >> though. > Yes, that would be better IMO. > > Thanks, Roger. --EZNMNhLYqG2sI4JEpgLTcNiA7zlGfs2qB-- --NSPFRzh7CyNbmQ9xlGrzZYSQtQ9cyNCsi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEcORGdCMIZOdpOj8ueAP19xcwDWkFAl7ptVMACgkQeAP19xcw DWncCwgApkYn1DNOXvOYE2Fj7HmX3TEPgq+4Hgn+1N3E+0EfGPbcnZZ+Fq1kQE7R 38oW0DaJstwIfyqZzK+lfYi+kp3UfQf7J+wVrHfugrHWaDvO1ZxV2V/SEpfxCV0y cRb8pcNyf3aKVnNv1kHO6pVK08+OOrF2AVKXyjpvQH613IY/eAWQVrr3MNhXiMMe mYeKgnG68TUSTX45qkMGkHMCWfwRZSrJrZ0diNaXt4FIKLyRVH7Y2Kir5yKwQm1k jiM9uovtFqgQ71bnJSJyeAG+RH1Qzs6jiYTJeJm+cBfZTy3G106d94iR1SEjx7dR xixNavILrDm0E472lB8pjHKEJzC06Q== =r17S -----END PGP SIGNATURE----- --NSPFRzh7CyNbmQ9xlGrzZYSQtQ9cyNCsi-- From xen-devel-bounces@lists.xenproject.org Wed Jun 17 07:15:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 07:15:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlSHX-00049A-SF; Wed, 17 Jun 2020 07:14:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlRpK-0001bL-MS for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 06:45:38 +0000 X-Inumbo-ID: 257a288a-b066-11ea-8496-bc764e2007e4 Received: from mga14.intel.com (unknown [192.55.52.115]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 257a288a-b066-11ea-8496-bc764e2007e4; Wed, 17 Jun 2020 06:45:35 +0000 (UTC) IronPort-SDR: U4AMsr18tpfi+Ukc5NhJtP2IAhkZwbf0E84JqvBA33ECky18DvkML0kVEuPNcTWK0FpPjtiMXf /eFCQyPBkygg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2020 23:45:34 -0700 IronPort-SDR: MfGb4CciptqFEzYJ6cKl9Pu6BW4DfdbCZUBFbP1tTDHrwynnrLIENndoqzvXyuDMluRBmIOun7 VFM9qYGJOnZA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,521,1583222400"; d="scan'208";a="317446265" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by FMSMGA003.fm.intel.com with ESMTP; 16 Jun 2020 23:45:33 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 16 Jun 2020 23:45:24 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 16 Jun 2020 23:45:24 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 16 Jun 2020 23:45:24 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.106) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 16 Jun 2020 23:45:24 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cxgqVa5IPV8oT8ZfbNYg7dPCfPPEVFytoWl/da1aGn6Jzx6fqJT/L+RWkOq8YFIa6Y0AlfIg4Gt79j9u7dkgo1FLD/JqNZl5IbCmyAHQL8FKAJGTWXf4q9ZuaL3KoZgBzYkrEguFZFWO9Hvnlx0U//xQJ7xI26N/C7uP3NLsEp2Tf8BynHBkHjjZ+kG0eHFsPqUvuwYeFcOEvRY+nDkTPntiCKkihQY3toPdv9S/8M3xUN4OOnaiA/m6vF6vKamxNJ6c+rh/K50CvMRuGBeHwhzIOIaQbOryVoC8Oy8hZ2f2bJx6lOaDCRBnKcYt2Z0EyBQydnM5gSUuVUiTJkn61g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dyX7aos7dqWWXqrhWttgADAOtJuahBAkLRf0OxULrlo=; b=W0eQXP2lnDLcSFJoNnWKC6ioBx2tpid2Q5O8T8K7tW3WXO11x5rUqaUvOwejXeIIefI4Qkd8cvvTzgiFoOHSLL4MI9Y8PSvUPvFN2F7/vzY9wJQmNclgOOCyg4KQ024KS4u9L4Kep/xFMK4ROUN6MjZ/9DgdJ/wBULcd3AJP0c0AnRGRA8fbCmZO+GxXckaEQw4QYATN+2VQxA10UewC+rjvns/2XsxcqHw3fSigLUshUXufIliA/hXox07tCOXIJ4L7ylnZ3thHiqxt00heXSsTCyj3VTo0VfjmFxgzz0Sa36EBWj85ctFo6K/LYiyG9b27v8f33qt7V5WrFj6+EA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dyX7aos7dqWWXqrhWttgADAOtJuahBAkLRf0OxULrlo=; b=zcAR4uPJwAwd9Vtr2VJACTxMiKNPC6dOjjHiW1eiterWFP2d0QdBES+8DeLtKTGuhmeXGKmGKMuY4L8nt6hW+MuIYHrpfh0qscEUs28hs11uSac705ri7/nHxOXuDzFfTb4NQV+dm2gFJq19uaT0oXOpxW4hLyOban5iLfRShiY= Received: from DM5PR1101MB2266.namprd11.prod.outlook.com (2603:10b6:4:57::17) by DM6PR11MB4530.namprd11.prod.outlook.com (2603:10b6:5:2a4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Wed, 17 Jun 2020 06:45:23 +0000 Received: from DM5PR1101MB2266.namprd11.prod.outlook.com ([fe80::b07e:e40:d34e:b601]) by DM5PR1101MB2266.namprd11.prod.outlook.com ([fe80::b07e:e40:d34e:b601%6]) with mapi id 15.20.3109.021; Wed, 17 Jun 2020 06:45:23 +0000 From: "Kang, Luwei" To: "Tian, Kevin" , =?utf-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Andrew Cooper Subject: RE: [PATCH v1 0/7] Implement support for external IPT monitoring Thread-Topic: [PATCH v1 0/7] Implement support for external IPT monitoring Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hpiVzvKAgAAIowCAAHHNAIAAVp/w Date: Wed, 17 Jun 2020 06:45:22 +0000 Message-ID: References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.216] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7da5ecad-e0d6-4fc4-4f97-08d8128a028e x-ms-traffictypediagnostic: DM6PR11MB4530: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04371797A5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: l4mETXw6qtV02rtVCf0BwOmVSXl2BLIfse9jIkROH6NiUmVa7l5ZHQqoQPbNoXLX8IhVJhyNLEMQB3tVyLhBmGLm3kofmbLcPqvzQA9ASZT8177SFCu4C5mn5h3E4NeUTwlrivTTQBypPZJY0XuYSdUWl+tFwxHCM7P+k5qeL+wvAxy8XOQizb/zFgNg1YYaqpajWYaivOpJUsz8nBb7IdSlg7bgxdSyBtlqOwboJosm/jNY+k9GeJdoW1VAXMCjb/+v2L6a0/5otc5ozWzZdd6DFJoFVcevLooQYA92ECmNUYJ/PG8iWQmYdM/qvkdp x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR1101MB2266.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(376002)(136003)(396003)(39860400002)(26005)(7416002)(83380400001)(4326008)(71200400001)(6506007)(8936002)(66574015)(52536014)(478600001)(53546011)(110136005)(54906003)(316002)(86362001)(7696005)(76116006)(66946007)(66476007)(66556008)(5660300002)(66446008)(64756008)(33656002)(9686003)(55016002)(186003)(8676002)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 7FoioelfeK/kOQ0HVYT+5HUgQN7NjWP6/rB0EW/9ZwYKfcfmu+yuBS9kKz/FPINbaaEGf4IDBl10YxMMXkHMqTWHWttt93RkZL4zWcl5aqbBxBn8uAE2ZZi9ylcjgvdTRHbMr09O/LQzzXADtJFqGrz3OP7S0i4fomzeleq57pWYI0iuBnBmfG0kKchNQKnQ9vi7aHvPhUG1XC65ENAQL7JDaiig10SfPKapMscLyBfg6mdk/82wACx987tL86/9plotUycW09XLafLZOehY/GUt3PJQ7qghQabcXKAeFcRCV0bYjpMUxKWjYbeoHP+toCZfoOj+0GrQkPjEGO/pXz4R0i+ovXL1zuDeOffTqVINHW1uldND2TP5REWQjqqjNUe0J5MiKtP3ikcXWLp9otVyrEmBPEIAgkSiyPh/jAOO5/98haWcAeVd1qrE1HpaRaU36P/u34VoH9DpLIogGoOgKbQ6NuHYHcYMRAL/3uwbectjS98FK0T8MuBzOdrZ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7da5ecad-e0d6-4fc4-4f97-08d8128a028e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 06:45:22.8503 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KTqYLEfMQQFLJJfFYAdzP5WwPTVSlSIj7BxzNGq8D4u0F6e3T1kvfVgoYm6RGzQNjucYI4Wk0fBY7YHbMee3Mw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4530 X-OriginatorOrg: intel.com X-Mailman-Approved-At: Wed, 17 Jun 2020 07:14:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Ian Jackson , George Dunlap , "Nakajima, Jun" , Xen-devel , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUaWFuLCBLZXZpbiA8a2V2aW4u dGlhbkBpbnRlbC5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxNywgMjAyMCA5OjM1IEFN DQo+IFRvOiBNaWNoYcWCIExlc3pjennFhHNraSA8bWljaGFsLmxlc3pjenluc2tpQGNlcnQucGw+ OyBBbmRyZXcgQ29vcGVyDQo+IDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPg0KPiBDYzogWGVu LWRldmVsIDx4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmc+OyBKYW4gQmV1bGljaA0KPiA8 amJldWxpY2hAc3VzZS5jb20+OyBXZWkgTGl1IDx3bEB4ZW4ub3JnPjsgUm9nZXIgUGF1IE1vbm7D qQ0KPiA8cm9nZXIucGF1QGNpdHJpeC5jb20+OyBOYWthamltYSwgSnVuIDxqdW4ubmFrYWppbWFA aW50ZWwuY29tPjsgR2VvcmdlDQo+IER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPjsg SWFuIEphY2tzb24gPGlhbi5qYWNrc29uQGV1LmNpdHJpeC5jb20+Ow0KPiBKdWxpZW4gR3JhbGwg PGp1bGllbkB4ZW4ub3JnPjsgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwu b3JnPjsNCj4gS2FuZywgTHV3ZWkgPGx1d2VpLmthbmdAaW50ZWwuY29tPg0KPiBTdWJqZWN0OiBS RTogW1BBVENIIHYxIDAvN10gSW1wbGVtZW50IHN1cHBvcnQgZm9yIGV4dGVybmFsIElQVCBtb25p dG9yaW5nDQo+IA0KPiArTHV3ZWksIHdobyBkZXZlbG9wZWQgUFQgZm9yIEtWTSBhbmQgaXMgdGhl IGJlc3Qgb25lIHdobyBjYW4gaGVscA0KPiByZXZpZXcgVk1YIGNoYW5nZXMgZnJvbSBJbnRlbCBz aWRlLiBQbGVhc2UgaW5jbHVkZSBoaW0gaW4gZnV0dXJlIHBvc3Qgb3INCj4gZGlzY3Vzc2lvbi4N Cj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBNaWNoYcWCIExl c3pjennFhHNraSA8bWljaGFsLmxlc3pjenluc2tpQGNlcnQucGw+DQo+ID4gU2VudDogV2VkbmVz ZGF5LCBKdW5lIDE3LCAyMDIwIDI6NDggQU0NCj4gPiBUbzogQW5kcmV3IENvb3BlciA8YW5kcmV3 LmNvb3BlcjNAY2l0cml4LmNvbT4NCj4gPiBDYzogWGVuLWRldmVsIDx4ZW4tZGV2ZWxAbGlzdHMu eGVucHJvamVjdC5vcmc+OyBKYW4gQmV1bGljaA0KPiA+IDxqYmV1bGljaEBzdXNlLmNvbT47IFdl aSBMaXUgPHdsQHhlbi5vcmc+OyBSb2dlciBQYXUgTW9ubsOpDQo+ID4gPHJvZ2VyLnBhdUBjaXRy aXguY29tPjsgTmFrYWppbWEsIEp1biA8anVuLm5ha2FqaW1hQGludGVsLmNvbT47IFRpYW4sDQo+ ID4gS2V2aW4gPGtldmluLnRpYW5AaW50ZWwuY29tPjsgR2VvcmdlIER1bmxhcA0KPiA+IDxnZW9y Z2UuZHVubGFwQGNpdHJpeC5jb20+OyBJYW4gSmFja3NvbiA8aWFuLmphY2tzb25AZXUuY2l0cml4 LmNvbT47DQo+ID4gSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47IFN0ZWZhbm8gU3RhYmVs bGluaQ0KPiA+IDxzc3RhYmVsbGluaUBrZXJuZWwub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBbUEFU Q0ggdjEgMC83XSBJbXBsZW1lbnQgc3VwcG9ydCBmb3IgZXh0ZXJuYWwgSVBUDQo+ID4gbW9uaXRv cmluZw0KPiA+DQo+ID4gLS0tLS0gMTYgY3plIDIwMjAgbyAyMDoxNywgQW5kcmV3IENvb3BlciBh bmRyZXcuY29vcGVyM0BjaXRyaXguY29tDQo+ID4gbmFwaXNhxYIoYSk6DQo+ID4NCj4gPiA+IE9u IDE2LzA2LzIwMjAgMTY6MTYsIE1pY2hhxYIgTGVzemN6ecWEc2tpIHdyb3RlOg0KPiA+ID4+IElu dGVsIFByb2Nlc3NvciBUcmFjZSBpcyBhbiBhcmNoaXRlY3R1cmFsIGV4dGVuc2lvbiBhdmFpbGFi bGUgaW4NCj4gPiA+PiBtb2Rlcm4NCj4gPiBJbnRlbA0KPiA+ID4+IGZhbWlseSBDUFVzLiBJdCBh bGxvd3MgcmVjb3JkaW5nIHRoZSBkZXRhaWxlZCB0cmFjZSBvZiBhY3Rpdml0eQ0KPiA+ID4+IHdo aWxlIHRoZSBwcm9jZXNzb3IgZXhlY3V0ZXMgdGhlIGNvZGUuIE9uZSBtaWdodCB1c2UgdGhlIHJl Y29yZGVkDQo+ID4gPj4gdHJhY2UgdG8NCj4gPiByZWNvbnN0cnVjdA0KPiA+ID4+IHRoZSBjb2Rl IGZsb3cuIEl0IG1lYW5zLCB0byBmaW5kIG91dCB0aGUgZXhlY3V0ZWQgY29kZSBwYXRocywNCj4g PiA+PiBkZXRlcm1pbmUgYnJhbmNoZXMgdGFrZW4sIGFuZCBzbyBmb3J0aC4NCj4gPiA+Pg0KPiA+ ID4+IFRoZSBhYm92ZW1lbnRpb25lZCBmZWF0dXJlIGlzIGRlc2NyaWJlZCBpbiBJbnRlbChSKSA2 NCBhbmQgSUEtMzINCj4gPiBBcmNoaXRlY3R1cmVzDQo+ID4gPj4gU29mdHdhcmUgRGV2ZWxvcGVy J3MgTWFudWFsIFZvbHVtZSAzQzogU3lzdGVtIFByb2dyYW1taW5nIEd1aWRlLA0KPiA+IFBhcnQg MywNCj4gPiA+PiBDaGFwdGVyIDM2OiAiSW50ZWwgUHJvY2Vzc29yIFRyYWNlLiINCj4gPiA+Pg0K PiA+ID4+IFRoaXMgcGF0Y2ggc2VyaWVzIGltcGxlbWVudHMgYW4gaW50ZXJmYWNlIHRoYXQgRG9t MCBjb3VsZCB1c2UgaW4NCj4gPiA+PiBvcmRlciB0bw0KPiA+IGVuYWJsZQ0KPiA+ID4+IElQVCBm b3IgcGFydGljdWxhciB2Q1BVcyBpbiBEb21VLCBhbGxvd2luZyBmb3IgZXh0ZXJuYWwgbW9uaXRv cmluZy4NCj4gPiA+PiBTdWNoIGEgZmVhdHVyZSBoYXMgbnVtZXJvdXMgYXBwbGljYXRpb25zIGxp a2UgbWFsd2FyZSBtb25pdG9yaW5nLA0KPiA+ID4+IGZ1enppbmcsIG9yIHBlcmZvcm1hbmNlIHRl c3RpbmcuDQo+ID4gPg0KPiA+ID4gSGVsbG8sDQo+ID4gPg0KPiA+ID4gSSdtIHZlcnkgZXhjaXRl ZCB0byBzZWUgc3VwcG9ydCBsaWtlIHRoaXMgYXBwZWFyaW5nLsKgIEhvd2V2ZXIsIGJlDQo+ID4g PiBhd2FyZSB0aGF0IHdlJ3JlIGN1cnJlbnRseSBpbiBjb2RlIGZyZWV6ZSBmb3IgdGhlIDQuMTQg cmVsZWFzZSwgc28NCj4gPiA+IGluLWRlcHRoIHJldmlld3Mgd2lsbCBwcm9iYWJseSBiZSBkZWxh eWVkIHNvbWV3aGF0IGR1ZSB0byBvdXIgYnVnDQo+ID4gPiBxdWV1ZSBhbmQgcmVsZWFzZSBhY3Rp dml0aWVzLg0KPiA+DQo+ID4gU3VyZSwgdGFrZSB5b3VyIHRpbWUgOikNCj4gPg0KPiA+DQo+ID4g Pg0KPiA+ID4gVGhhdCBzYWlkLCBJJ3ZlIGhhZCBhIHZlcnkgcXVpY2sgbG9vayB0aHJvdWdoIHRo ZSBzZXJpZXMsIGFuZCBoYXZlIGENCj4gPiA+IGZldyBnZW5lcmFsIHF1ZXN0aW9ucyBmaXJzdC4N Cj4gPiA+DQo+ID4gPiBBRkFJQ1QsIHRoaXMgaXMgc3RyaWN0bHkgZm9yIGV4dGVybmFsIG1vbml0 b3Jpbmcgb2YgdGhlIFZNLCBub3QgZm9yDQo+ID4gPiB0aGUgVk0gdG8gdXNlIGl0c2VsZj/CoCBJ ZiBzbywgaXQgc2hvdWxkbid0IGhhdmUgdGhlIEggdGFnIGhlcmU6DQo+ID4gPg0KPiA+ID4gWEVO X0NQVUZFQVRVUkUoSVBULMKgwqDCoMKgwqDCoMKgwqDCoMKgIDUqMzIrMjUpIC8qSMKgIEludGVs IFByb2Nlc3NvciBUcmFjZSAqLw0KPiA+ID4NCj4gPiA+IGJlY2F1c2UgdGhhdCBleHBvc2VzIHRo ZSBmZWF0dXJlIHRvIHRoZSBndWVzdCwgd2l0aCB0aGUgaW1wbGljYXRpb24NCj4gPiA+IHRoYXQg YWxsIG90aGVyIHBhcnRzIG9mIHRoZSBmZWF0dXJlIHdvcmsgYXMgYWR2ZXJ0aXNlZC4NCj4gPg0K PiA+IE9rLCBJIHdpbGwgcmVtb3ZlIHRoZSBIIHRhZy4NCj4gPg0KPiA+DQo+ID4gPg0KPiA+ID4N Cj4gPiA+IEFyZSB0aGVyZSBhbnkgcmVzdHJpY3Rpb25zIG9uIEVQVCBiZWluZyBlbmFibGVkIGlu IHRoZSBmaXJzdCBwbGFjZT8NCj4gPiA+IEknbSBub3QgYXdhcmUgb2YgYW55LCBhbmQgaW4gcHJp bmNpcGxlIHdlIGNvdWxkIHVzZSB0aGlzDQo+ID4gPiBmdW5jdGlvbmFsaXR5IGZvciBQViBndWVz dHMgYXMgd2VsbCAodXNpbmcgdGhlIENQTCBmaWx0ZXIpLg0KPiA+ID4gVGhlcmVmb3JlLCBJIHRo aW5rIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gbm90IHRpZSB0aGUgZnVuY3Rpb25hbGl0eQ0KPiA+ ID4gdG8gSFZNIGd1ZXN0cywgZXZlbiBpZiB0aGF0IGlzIHRoZSBvbmx5IG9wdGlvbiBlbmFibGVk IHRvIHN0YXJ0IHdpdGguDQo+ID4NCj4gPiBJIHRoaW5rIGF0IHRoZSBtb21lbnQgaXQncyBub3Qg cmVxdWlyZWQgdG8gaGF2ZSBFUFQuIFRoaXMgcGF0Y2ggc2VyaWVzDQo+ID4gZG9lc24ndCB1c2Ug YW55IHRyYW5zbGF0aW9uIGZlYXR1cmUgZmxhZ3MsIHNvIHRoZSBvdXRwdXQgYWRkcmVzcyBpcw0K PiA+IGFsd2F5cyBhIG1hY2hpbmUgcGh5c2ljYWwgYWRkcmVzcywgcmVnYXJkbGVzcyBvZiBjb250 ZXh0LiBJIHdpbGwgY2hlY2sNCj4gPiBpZiBpdCBjb3VsZCBiZSBlYXNpbHkgdXNlZCB3aXRoIFBW Lg0KPiA+DQo+ID4NCj4gPiA+DQo+ID4gPiBUaGUgYnVmZmVyIG1hcHBpbmcgYW5kIGNyZWF0aW9u IGxvZ2ljIGlzIGZhaXJseSBwcm9ibGVtYXRpYy4NCj4gPiA+IEluc3RlYWQgb2YgZmlnaHRpbmcg d2l0aCBhbm90aGVyIG9wZW5jb2RlZCBleGFtcGxlLCB0YWtlIGEgbG9vayBhdA0KPiA+ID4gdGhl IElPUkVRIHNlcnZlcidzIHVzZSBvZiAiYWNxdWlyZSByZXNvdXJjZSIgd2hpY2ggaXMgYSBtYXBw aW5nDQo+ID4gPiBpbnRlcmZhY2Ugd2hpY2ggc3VwcG9ydHMgYWxsb2NhdGluZyBtZW1vcnkgb24g YmVoYWxmIG9mIHRoZSBndWVzdCwNCj4gPiA+IG91dHNpZGUgb2YgdGhlIGd1ZXN0IG1lbW9yeSwg Zm9yIHVzZSBieSBjb250cm9sIHRvb2xzLg0KPiA+ID4NCj4gPiA+IEkgdGhpbmsgd2hhdCB0aGlz IHdhbnRzIGlzIGEgYml0IHNvbWV3aGVyZSBpbiBkb21haW5fY3JlYXRlIHRvDQo+ID4gPiBpbmRp Y2F0ZSB0aGF0IGV4dGVybmFsIHRyYWNpbmcgaXMgdXNlZCBmb3IgdGhpcyBkb21haW4gKGFuZCBh bGxvY2F0ZQ0KPiA+ID4gd2hhdGV2ZXIgc3RydWN0dXJlcy9idWZmZXJzIGFyZSBuZWNlc3Nhcnkp LCBhY3F1aXJlIHJlc291cmNlIHRvIG1hcA0KPiA+ID4gdGhlIGJ1ZmZlcnMgdGhlbXNlbHZlcywg YW5kIGEgZG9tY3RsIGZvciBhbnkgbmVjZXNzYXJ5IHJ1bnRpbWUgY29udHJvbHMuDQo+ID4gPg0K PiA+DQo+ID4gSSB3aWxsIGNoZWNrIHRoaXMgb3V0LCB0aGlzIHNvdW5kcyBsaWtlIGEgZ29vZCBv cHRpb24gYXMgaXQgd291bGQNCj4gPiByZW1vdmUgbG90cyBvZiBjb21wbGV4aXR5IGZyb20gdGhl IGV4aXN0aW5nIGlwdF9lbmFibGUgZG9tY3RsLg0KPiA+DQo+ID4gPg0KPiA+ID4gV2hhdCBzZW1h bnRpY3MgZG8geW91IHdhbnQgZm9yIHRoZSBidWZmZXIgYmVjb21pbmcgZnVsbD/CoCBHaXZlbiB0 aGF0DQo+ID4gPiBkZWJ1Z2dpbmcvdHJhY2luZyBpcyB0aGUgZ29hbCwgSSBwcmVzdW1lICJwYXVz ZSB2Y3B1IG9uIGZ1bGwiIGlzIHRoZQ0KPiA+ID4gcHJlZmVycmVkIGJlaGF2aW91ciwgcmF0aGVy IHRoYW4gZHJvcCBwYWNrZXRzIG9uIGZ1bGw/DQo+ID4gPg0KPiA+DQo+ID4gUmlnaHQgbm93IHRo aXMgaXMgYSByaW5nLXN0eWxlIGJ1ZmZlciBhbmQgd2hlbiBpdCB3b3VsZCBiZWNvbWUgZnVsbCBp dA0KPiA+IHdvdWxkIHNpbXBseSB3cmFwIGFuZCBvdmVycmlkZSB0aGUgb2xkIGRhdGEuDQo+ID4N Cj4gPiA+DQo+ID4gPiBXaGVuIHRoaXMgc3ViamVjdCB3YXMgYnJvYWNoZWQgb24geGVuLWRldmVs IGJlZm9yZSwgb25lIGlzc3VlIHdhcw0KPiA+ID4gdGhlIGZhY3QgdGhhdCBhbGwgYWN0aW9ucyB3 aGljaCBhcmUgaW50ZXJjZXB0ZWQgZG9uJ3QgZW5kIHVwIHdyaXRpbmcNCj4gPiA+IGFueSBhcHBy b3ByaWF0ZSBwYWNrZXRzLsKgIFRoaXMgaXMgcGVyaGFwcyBsZXNzIG9mIGFuIGlzc3VlIGZvciB0 aGlzDQo+ID4gPiBleGFtcGxlLCB3aGVyZSB0aGUgZXh0ZXJuYWwgYWdlbnQgY2FuIHNlZSBWTUV4 aXRzIGluIHRoZSB0cmFjZSwgYnV0DQo+ID4gPiBpdCBzdGlsbCByZXN1bHRzIGluIG1pc3Npbmcg aW5mb3JtYXRpb24uwqAgKEl0IGlzIGEgbWFqb3IgcHJvYmxlbSBmb3INCj4gPiA+IFBUIHdpdGhp biB0aGUgZ3Vlc3QsIGFuZCBuZWVkcyBYZW4ncyBpbnRlcmNlcHQvZW11bGF0aW9uIGZyYW1ld29y aw0KPiA+ID4gYmVpbmcgdXBkYXRlZCB0byBiZSBQVC1hd2FyZSBzbyBpdCBjYW4gZmlsbCBpbiB0 aGUgc2FtZSBwYWNrZXRzDQo+ID4gPiB3aGljaCBoYXJkd2FyZSB3b3VsZCBoYXZlIGRvbmUgZm9y IGVxdWl2YWxlbnQgYWN0aW9ucy4pDQo+ID4NCj4gPiBPaywgdGhpcyBzb3VuZHMgbGlrZSBhIGhh cmQgaXNzdWUuIENvdWxkIHlvdSBwb2ludCBvdXQgd2hhdCBjb3VsZCBiZQ0KPiA+IHRoZSBwYXJ0 aWN1bGFyIHByb2JsZW1hdGljIGNhc2VzPyBGb3IgaW5zdGFuY2UsIGlmIHNvbWV0aGluZyB3b3Vs ZA0KPiA+IGFsdGVyIEVJUC9SSVAgb3IgQ1IzIHRoZW4gSSBiZWxpdmUgaXQgd291bGQgc3RpbGwg YmUgcmVjb3JkZWQgaW4gUFQNCj4gPiB0cmFjZSAoaS5lLiB0aGVzZSB2YWx1ZXMgd2lsbCBiZSBs b2dnZWQgb24gVk0gZW50cnkpLg0KDQplLmcuIElmIGEgVk0gZXhpdCBpcyB0YWtlbiBvbiBhIGd1 ZXN0IHdyaXRlIHRvIENSMyAoaW5jbHVkaW5nIOKAnE1PViBDUjPigJ0gYXMgd2VsbCBhcyB0YXNr IHN3aXRjaGVzKSwgdGhlIFBJUCBwYWNrZXQNCm5vcm1hbGx5IGdlbmVyYXRlZCBvbiB0aGUgQ1Iz IHdyaXRlIHdpbGwgYmUgbWlzc2luZy4gVGhlIFBJUCBwYWNrZXQgbmVlZHMgdG8gYmUgd3JpdHRl biB0byB0aGUgUFQgYnVmZmVyIGJ5IHNvZnR3YXJlLiBBbm90aGVyIGV4YW1wbGUgaXMgVk0tZXhp dCB0YWtlbiBvbiBSRFRTQy4gDQoNCkZvciBWTSBpbnRyb3NwZWN0aW9uLCBhbGwgdGhlIEludGVs IFBUIHBhY2tldHMgbWF5IG5lZWQgdG8gZW11bGF0ZWQgYnkgc29mdHdhcmUuIFNvbWUgZGVzY3Jp cHRpb24gaW4gU0RNIGFzIGJlbG93Og0KSWYgYSBWTU0gZW11bGF0ZXMgYW4gZWxlbWVudCBvZiBw cm9jZXNzb3Igc3RhdGUgYnkgdGFraW5nIGEgVk0gZXhpdCBvbiByZWFkcyBhbmQvb3Igd3JpdGVz IHRvIHRoYXQgcGllY2Ugb2Ygc3RhdGUsIGFuZCB0aGUgc3RhdGUgZWxlbWVudCBpbXBhY3RzIElu dGVsIFBUIHBhY2tldCBnZW5lcmF0aW9uIG9yIHZhbHVlcywgaXQgbWF5IGJlIGluY3VtYmVudCB1 cG9uIHRoZSBWTU0gdG8gaW5zZXJ0IG9yIG1vZGlmeSB0aGUgb3V0cHV0IHRyYWNlIGRhdGEuDQoN ClRoYW5rcywNCkx1d2VpIEthbmcNCg0KPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRoYW5rcywN Cj4gPiA+DQo+ID4gPiB+QW5kcmV3DQo+ID4NCj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBN aWNoYcWCIExlc3pjennFhHNraQ0KPiA+IENFUlQgUG9sc2thDQo= From xen-devel-bounces@lists.xenproject.org Wed Jun 17 08:21:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 08:21:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTK3-00022X-EX; Wed, 17 Jun 2020 08:21:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTK1-00022S-VD for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 08:21:26 +0000 X-Inumbo-ID: 88aaa8fa-b073-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 88aaa8fa-b073-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 08:21:25 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id c3so1296075wru.12 for ; Wed, 17 Jun 2020 01:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=XX6vOBkl7CUdr6Wcaym4pJD64r/uqplNd2RI5rA9oSc=; b=EuPnKvEqo+oH61QcsQjIc0VIG3SXtkA33gZcHHY6FmJbfQ2CzOyacZXldO9tb8NO9F FIJuaGgfgxeFIuof6LXF+f3TJy7vjhVWW8MkLQnju+PBE50kSqP43h1G4up9zsOuxKeP buuYkLC9S1dPei1EXduL9VNyIll3XXFPPvEDT1vu1AeQ7qxKp5dVDaaXDhItCTMaqBsc DtZxFGLg54lLyG2yH+qaNS/VMkjA5JGKFxyw8w2cRBP97Aim9UJq+1UUX8J5ovBIHyAE h/Leebj7CATHQ1x6EAqhJ0yWmibzuNu5Y6aC47seTqy8APAXUgGpq4VKK7hPGyzb6t75 7Mnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=XX6vOBkl7CUdr6Wcaym4pJD64r/uqplNd2RI5rA9oSc=; b=iClrspZRSzlHa1bAymVn14XILlQWk5Fd7XjBrrTvM/7NjFhzINf/aaJ6364CG/lnSp h16wp7RgQZzupC+CM7YQFxcM/XTVGUOUMYHBgqxAmn9j+Ypf/pS81QRMVcTaOZIpp08P INpTQVsF6BwMBNYUAtqNTVlDBlTaXJONiOQUVxrwktEI62aB61FObOrEUgECZnRzy0gC GwAhW90BYV/ubIJqg2eKKnliYr/49Yrj8IveQa+wVrdHABbmAo43TodgZBRDFJ+hDCPs t39iBU7f/0ZNnVYskiATYypq5uYMubB8gafFbP1cdRyBkOhNbxDywj8H2fWLWzRxFH+4 12SA== X-Gm-Message-State: AOAM531/z0v7C2BkDcYTdcMJOAk+2m4YsDkX9lOi4wmYXU8qtDCJKFiX kkQruKRPD0C869CZtvDSQVQ= X-Google-Smtp-Source: ABdhPJxyB7EhBRYOrz2iKOlOGnX8miyPVZxveDRPJ2X9Fjf4UDeze5XGZHpREWRHM8YBNENtC7vrRA== X-Received: by 2002:adf:f7ce:: with SMTP id a14mr7082462wrq.362.1592382084539; Wed, 17 Jun 2020 01:21:24 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id z12sm35480067wrg.9.2020.06.17.01.21.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2020 01:21:23 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Christopher Clark'" , "'Olaf Hering'" References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> <20200609152233.039cfc86.olaf@aepfle.de> <20200610191657.GA69414@deinos.phlegethon.org> <20200611211004.11e38f8f.olaf@aepfle.de> In-Reply-To: Subject: RE: [PATCH v1] kdd: remove zero-length arrays Date: Wed, 17 Jun 2020 09:21:22 +0100 Message-ID: <005a01d64480$49ce0730$dd6a1590$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIqIZk/Qusa7Qsu5bkjM27jAUAPHgHVoA+LAfW9KPcCU2XTcQH8d5RuAcV3opsCrD1gbKfQVYCQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'xen-devel' , 'Tim Deegan' , 'Ian Jackson' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Christopher Clark > Sent: 16 June 2020 21:50 > To: Olaf Hering > Cc: Tim Deegan ; xen-devel ; Ian Jackson > ; Wei Liu ; paul@xen.org > Subject: Re: [PATCH v1] kdd: remove zero-length arrays > > On Thu, Jun 11, 2020 at 12:12 PM Olaf Hering wrote: > > > > Am Wed, 10 Jun 2020 20:16:57 +0100 > > schrieb Tim Deegan : > > > > > How tedious. > > > > Indeed. This compiles for me as well: > > just a nudge on this; it would be nice to get a patch into the tree > since the build failure affects master builds of Xen in OpenEmbedded > now. > I'd be happy to take a patch into 4.14 if someone can provide one with a suitable maintainer ack. Paul > Christopher > > > > > --- orig/kdd.h 2020-06-08 17:40:05.000000000 +0000 > > +++ kdd.h 2020-06-11 19:00:44.234364040 +0000 > > @@ -68,7 +68,6 @@ > > uint16_t len; /* Payload length, excl. header and trailing byte */ > > uint32_t id; /* Echoed in responses */ > > uint32_t sum; /* Unsigned sum of all payload bytes */ > > - uint8_t payload[0]; > > } PACKED kdd_hdr; > > > > #define KDD_PKT_CMD 0x0002 /* Debugger commands (and replies to them) */ > > @@ -323,7 +322,7 @@ > > kdd_msg msg; > > kdd_reg reg; > > kdd_stc stc; > > - uint8_t payload[0]; > > + uint8_t payload[65536]; > > }; > > } PACKED kdd_pkt; > > > > --- orig/kdd.c 2020-06-08 17:40:05.000000000 +0000 > > +++ kdd.c 2020-06-11 19:08:36.775724640 +0000 > > @@ -79,11 +79,11 @@ > > /* State of the debugger stub */ > > typedef struct { > > union { > > - uint8_t txb[sizeof (kdd_hdr) + 65536]; /* Marshalling area for tx */ > > + uint8_t txb[sizeof (kdd_hdr) + 0xffff]; /* Marshalling area for tx */ > > kdd_pkt txp; /* Also readable as a packet structure */ > > }; > > union { > > - uint8_t rxb[sizeof (kdd_hdr) + 65536]; /* Marshalling area for rx */ > > + uint8_t rxb[sizeof (kdd_hdr)]; /* Marshalling area for rx */ > > kdd_pkt rxp; /* Also readable as a packet structure */ > > }; > > unsigned int cur; /* Offset into rx where we'll put the next byte */ > > > > Olaf From xen-devel-bounces@lists.xenproject.org Wed Jun 17 08:23:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 08:23:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTMO-0002AF-S4; Wed, 17 Jun 2020 08:23:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTMN-0002A8-Pc for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 08:23:51 +0000 X-Inumbo-ID: df7280ea-b073-11ea-b9a7-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id df7280ea-b073-11ea-b9a7-12813bfff9fa; Wed, 17 Jun 2020 08:23:51 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Yf04g/K2zQAYOiVFaYAWop5x5T9/Z1/Nc2LsWVgFWbfIeKdAYXwSJfdO0m13ailsvE3Rh4R8fN r7F2DZwY8Z/ym37F4zvK7t7V7X1dihwq4vuZs/7QGxxO5k3VdMA8zxr4bRwhKBwNprmFT7CfRM Oh1vdPfdwh5jfAcvNFSAvrLb7LUmwiq8IIFTsai/eyHbv8Q6KcBbXug4gmVEI5M8XxFXanYT5T z8DwkSbz9CYhC/+x4PcDMzJWZWFLgtZS5hIM7JNBMjlFeoAFfvF8+80/B8IciDVjbV+M4oKl6Y +Rs= X-SBRS: 2.7 X-MesageID: 20548223 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20548223" Date: Wed, 17 Jun 2020 10:23:40 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes Message-ID: <20200617082340.GV735@Air-de-Roger> References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 12:31:06PM -0700, Tamas K Lengyel wrote: > While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been > observed due to a mm-lock order violation while copying the HVM CPU context > from the parent. This issue has been identified to be due to > hap_update_paging_modes getting a lock on the gfn using get_gfn. This call also > creates a shared entry in the fork's memory map for the cr3 gfn. The function > later calls hap_update_cr3 while holding the paging_lock, which results in the > lock-order violation in vmx_load_pdptrs when it tries to unshare the above entry. > > This issue has not affected VMs running other OS's as a call to vmx_load_pdptrs > is benign if PAE is not enabled or if EFER_LMA is set and returns before > trying to unshare and map the page. > > Using get_gfn_type to get a lock on the gfn avoids this problem as we can > populate the fork's gfn with a copied page instead of a shared entry if its > needed, thus avoiding the lock order violation while holding paging_lock. > > Signed-off-by: Tamas K Lengyel > --- > The bug seems to have been present since commit 4cb6c4f4941, only discovered > now due to the heavy use of mem_sharing with VM forks. As this is a simple > bug-fix it would be nice to include it in the 4.14 release. I agree it seems like a candidate bugfix to be included. I've added Paul to the Cc so he is aware. > --- > xen/arch/x86/mm/hap/hap.c | 17 ++++++++++++----- > 1 file changed, 12 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c > index 7f84d0c6ea..9ae4c3ae6e 100644 > --- a/xen/arch/x86/mm/hap/hap.c > +++ b/xen/arch/x86/mm/hap/hap.c > @@ -748,12 +748,19 @@ static void hap_update_paging_modes(struct vcpu *v) > struct domain *d = v->domain; > unsigned long cr3_gfn = v->arch.hvm.guest_cr[3] >> PAGE_SHIFT; > p2m_type_t t; > + p2m_query_t q = P2M_ALLOC; > > - /* We hold onto the cr3 as it may be modified later, and > - * we need to respect lock ordering. No need for > - * checks here as they are performed by vmx_load_pdptrs > - * (the potential user of the cr3) */ > - (void)get_gfn(d, cr3_gfn, &t); > + /* > + * We hold onto the cr3 as it may be modified later, and > + * we need to respect lock ordering. Unshare here if we have to as to avoid > + * a lock-order violation later while we are holding the paging_lock. > + * Further checks are performed by vmx_load_pdptrs (the potential user of > + * the cr3). > + */ > + if ( hvm_pae_enabled(v) && !hvm_long_mode_active(v) ) > + q |= P2M_UNSHARE; > + > + (void)get_gfn_type(d, cr3_gfn, &t, q); While there I think you can drop the cast to void. In order for this to be more resilient, maybe it would be better to just use get_gfn_unshare directly and avoid checking what paging mode the guest is currently using? Or would that be too expensive in terms of performance for the not affected case? I feel like relying on the internals of vmx_load_pdptrs here is fragile. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 17 08:35:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 08:35:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTXr-00035j-1X; Wed, 17 Jun 2020 08:35:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTXq-00035e-EE for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 08:35:42 +0000 X-Inumbo-ID: 869741ca-b075-11ea-b9a8-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 869741ca-b075-11ea-b9a8-12813bfff9fa; Wed, 17 Jun 2020 08:35:41 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: KfZvMvC1oYnZ7gi+KDWOviH4clxbHShSY7Yli+xfkrqN6LkJMaGowI1WLqHxqcACgMUrxfkUAD Ay5pg5WGOeqKL0CCypgK4qhxMgOHjyTIf64e1aNhYRAm71VGxZrK78hisJYBoO7fnRxdMgfY7b vDubhXWnqwLSYTQ7ryxlfakGFVKT1POd8dRmcMBv35hFYrPvNJEhPlc4qaSrLIUxHxgq6p86dI Fvz6UQo69l4R4knwvEj6X3MlFh19OkyWqWkPIwHX3MDCwr+2pRlebLitMY4MMI8I/Szkk6yaRS 9UE= X-SBRS: 2.7 X-MesageID: 20261029 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20261029" Date: Wed, 17 Jun 2020 10:35:28 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Anchal Agarwal Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Message-ID: <20200617083528.GW735@Air-de-Roger> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monné wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > + "the device may become inconsistent state"); > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > state and with the queues frozen. You should make an attempt to > > > restore things to a working state. > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > You can manually force this state, and then check that it will behave > > correctly. I would expect that on a failure to disconnect from the > > backend you should switch the frontend to the 'Init' state in order to > > try to reconnect to the backend when possible. > > > From what I understand forcing manually is, failing the freeze without > disconnect and try to revive the connection by unfreezing the > queues->reconnecting to backend [which never got diconnected]. May be even > tearing down things manually because I am not sure what state will frontend > see if backend fails to to disconnect at any point in time. I assumed connected. > Then again if its "CONNECTED" I may not need to tear down everything and start > from Initialising state because that may not work. > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > I don't see it getting handled in the backend then what will be backend's state? > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > if it tries to read backend's state through xenbus_read_driver_state ? > > So the flow be like: > Front end marks XenbusStateClosing > Backend marks its state as XenbusStateClosing > Frontend marks XenbusStateClosed > Backend disconnects calls xen_blkif_disconnect > Backend fails to disconnect, the above function returns EBUSY > What will be state of backend here? Backend should stay in state 'Closing' then, until it can finish tearing down. > Frontend did not tear down the rings if backend does not switches the > state to 'Closed' in case of failure. > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend Backend will stay in state 'Closing' I think. > won't be calling connect(). {From reading code in frontend_changed} > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > we did not tear down anything so calling talk_to_blkback may not be needed > > Does that sound correct? I think switching to the initial state in order to try to attempt a reconnection would be our best bet here. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 17 08:39:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 08:39:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTb7-0003GD-Gs; Wed, 17 Jun 2020 08:39:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTb6-0003G8-Tz for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 08:39:04 +0000 X-Inumbo-ID: ffb3fe54-b075-11ea-b9a8-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ffb3fe54-b075-11ea-b9a8-12813bfff9fa; Wed, 17 Jun 2020 08:39:04 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: rXJCpYrqKVrAxeK/HGufl69LKC4pcQTcUUGZYB534dwGmUxVSqjN+x/504zNn9i+YPShSGKfW0 U0QMIZHnITxsotA99KOFT6OeNi8ZZ1m2L7oXIXDGt902t7cD4K5WSO+YP/COJ+vMNSTSziyGu7 HNftc9oo9lXvpx57ycrXBxaltImFbOK3Us6eexDysElhroEjtq8q7fatJV8B7YHjav9ncYU2JC 6yWJiQKYqhQurhE6bspELNnpxxK4ZszRp06jGIM0AlVuGxTyJg6YOrknOiMVmGXdVj9Ks/74SW yzE= X-SBRS: 2.7 X-MesageID: 20246153 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20246153" Date: Wed, 17 Jun 2020 10:38:50 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Anchal Agarwal Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Message-ID: <20200617083850.GX735@Air-de-Roger> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200616223003.GA28769@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200616223003.GA28769@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 10:30:03PM +0000, Anchal Agarwal wrote: > On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monné wrote: > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > > On Tue, May 19, 2020 at 11:27:50PM +0000, Anchal Agarwal wrote: > > > > > From: Munehisa Kamata > > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > > + "the device may become inconsistent state"); > > > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > > state and with the queues frozen. You should make an attempt to > > > > restore things to a working state. > > > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > > > You can manually force this state, and then check that it will behave > > > correctly. I would expect that on a failure to disconnect from the > > > backend you should switch the frontend to the 'Init' state in order to > > > try to reconnect to the backend when possible. > > > > > From what I understand forcing manually is, failing the freeze without > > disconnect and try to revive the connection by unfreezing the > > queues->reconnecting to backend [which never got diconnected]. May be even > > tearing down things manually because I am not sure what state will frontend > > see if backend fails to to disconnect at any point in time. I assumed connected. > > Then again if its "CONNECTED" I may not need to tear down everything and start > > from Initialising state because that may not work. > > > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > > I don't see it getting handled in the backend then what will be backend's state? > > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > > if it tries to read backend's state through xenbus_read_driver_state ? > > > > So the flow be like: > > Front end marks XenbusStateClosing > > Backend marks its state as XenbusStateClosing > > Frontend marks XenbusStateClosed > > Backend disconnects calls xen_blkif_disconnect > > Backend fails to disconnect, the above function returns EBUSY > > What will be state of backend here? > > Frontend did not tear down the rings if backend does not switches the > > state to 'Closed' in case of failure. > > > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend > > won't be calling connect(). {From reading code in frontend_changed} > > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > > we did not tear down anything so calling talk_to_blkback may not be needed > > > > Does that sound correct? > Send that too quickly, I also meant to add XenBusIntialised state should be ok > only if we expect backend will stay in "Connected" state. Also, I experimented > with that notion. I am little worried about the correctness here. > Can the backend come to an Unknown state somehow? Not really, there's no such thing as an Unknown state. There are no guarantees about what a backend can do really, so it could indeed switch to a not recognized state, but that would be a bug in the backend. Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 17 08:39:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 08:39:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTbo-0003Ju-QT; Wed, 17 Jun 2020 08:39:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTbn-0003J6-0u for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 08:39:47 +0000 X-Inumbo-ID: 18e58cc6-b076-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 18e58cc6-b076-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 08:39:46 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id g10so1007247wmh.4 for ; Wed, 17 Jun 2020 01:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=+wdC9mW3JSrWfdn3V4wPeinzlJyZ8c3Jf3+qdLTGosI=; b=FT5/HfzHHgg2TwcVBJ/08E6KZRbX4wHUg8PPwIxtSUQcZ3eWONSvIxmv6faKMmaYMY Wn3wk64gwz5Ru+Gbm259jzZuKyCU6ManqaqEExqE6A9mboYh0mTNrY+ABOJ0GA32yHxr Og31o8FPzWK8inNSUpXxhnsVUDgQxOOZMHk1RpaxmPBYGrsxpFetfFsMDUaB/YN0TSiE 6C+KlBG87QQraTUf8q5iIV9MFu8EVnLihCdIYnoZOQlin7hEO0U6LJXwygaXQq6edGoQ C54GYTKkzyZK1TtiNymzUzYicGOyDGZqf08VAykNbOxVTOb7sBKMpqfCCuVE5Y6bsrsz C3Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=+wdC9mW3JSrWfdn3V4wPeinzlJyZ8c3Jf3+qdLTGosI=; b=H/QatnBi0rfk/UPxMxJ20b6EFCtMHdJ/2NWq2EQlTmNoGGbXYVff+8CucnW8zAGlN2 rzjp9LYO/r+PrzwHE24iYk6+S8uhcE4x6e8+INJNhGO5q0y5+BNYOjkcn1dI0cX1zWts e5HHpxExCRvWaBscC6CQ/vKBC5dmTFVdTHu2qac3SQ+3BsiQ/oILOmw0mmPmZvjkRI58 7YxSUYZ9okibRUq0WyPYl9+cRAtCvpCTPFiTxqJHld6jHCt6bohg/mhyfrR9tZXtGBBj 1ysY1Uigr15tKEAkhIiIr2GrbLXnUyvS61rjBYwcpzaJ3W6KXVo25aY1RtODzT6EG5B6 n9nQ== X-Gm-Message-State: AOAM533Vsjtx/eEddg+EFIImoIP30u55P1hG5Uf2Wv8+At4dvrSEf6A4 vEeFUZxFl2zYBDCSZ7dQZYk= X-Google-Smtp-Source: ABdhPJyCl2D1rgnxUWSlyoAhU4WIeJGpGNIxu1nPmBqdBfpkJFANSFEdvywjqyubBzyX/Df3bIa5WQ== X-Received: by 2002:a1c:6884:: with SMTP id d126mr7371345wmc.121.1592383185461; Wed, 17 Jun 2020 01:39:45 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id g19sm7037742wmh.29.2020.06.17.01.39.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2020 01:39:45 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Igor Druzhinin'" , References: <1592360353-31231-1-git-send-email-igor.druzhinin@citrix.com> In-Reply-To: <1592360353-31231-1-git-send-email-igor.druzhinin@citrix.com> Subject: RE: [PATCH for-4.14 v3] tools/xen-ucode: return correct exit code on failed microcode update Date: Wed, 17 Jun 2020 09:39:43 +0100 Message-ID: <005b01d64482$da189650$8e49c2f0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGeNywcRe2CjUFC+SqYd4wUtfCSSqlMlzSQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: ian.jackson@eu.citrix.com, xadimgnik@gmail.com, wl@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Igor Druzhinin > Sent: 17 June 2020 03:19 > To: xen-devel@lists.xenproject.org > Cc: ian.jackson@eu.citrix.com; wl@xen.org; xadimgnik@gmail.com; Igor Druzhinin > > Subject: [PATCH for-4.14 v3] tools/xen-ucode: return correct exit code on failed microcode update > > Otherwise it's difficult to know if operation failed inside the automation. > > While at it, also switch to returning 1 and 2 instead of errno to avoid > incompatibilies between errno and special exit code numbers. > > Signed-off-by: Igor Druzhinin Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant > --- > Changes in v3: > - conventionally return 1 and 2 instead of errno as exit code > --- > tools/misc/xen-ucode.c | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c > index 0c257f4..ad32fac 100644 > --- a/tools/misc/xen-ucode.c > +++ b/tools/misc/xen-ucode.c > @@ -25,7 +25,7 @@ int main(int argc, char *argv[]) > fprintf(stderr, > "xen-ucode: Xen microcode updating tool\n" > "Usage: %s \n", argv[0]); > - return 0; > + exit(2); > } > > filename = argv[1]; > @@ -34,14 +34,14 @@ int main(int argc, char *argv[]) > { > fprintf(stderr, "Could not open %s. (err: %s)\n", > filename, strerror(errno)); > - return errno; > + exit(1); > } > > if ( fstat(fd, &st) != 0 ) > { > fprintf(stderr, "Could not get the size of %s. (err: %s)\n", > filename, strerror(errno)); > - return errno; > + exit(1); > } > > len = st.st_size; > @@ -49,7 +49,7 @@ int main(int argc, char *argv[]) > if ( buf == MAP_FAILED ) > { > fprintf(stderr, "mmap failed. (error: %s)\n", strerror(errno)); > - return errno; > + exit(1); > } > > xch = xc_interface_open(NULL, NULL, 0); > @@ -57,20 +57,23 @@ int main(int argc, char *argv[]) > { > fprintf(stderr, "Error opening xc interface. (err: %s)\n", > strerror(errno)); > - return errno; > + exit(1); > } > > ret = xc_microcode_update(xch, buf, len); > if ( ret ) > + { > fprintf(stderr, "Failed to update microcode. (err: %s)\n", > strerror(errno)); > + exit(1); > + } > > xc_interface_close(xch); > > if ( munmap(buf, len) ) > { > printf("Could not unmap: %d(%s)\n", errno, strerror(errno)); > - return errno; > + exit(1); > } > close(fd); > > -- > 2.7.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 08:39:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 08:39:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTbx-0003Lm-3O; Wed, 17 Jun 2020 08:39:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTbw-0003KZ-1K for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 08:39:56 +0000 X-Inumbo-ID: 1ba096cc-b076-11ea-b9a8-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1ba096cc-b076-11ea-b9a8-12813bfff9fa; Wed, 17 Jun 2020 08:39:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=t151jjmB4AtynrLrVFzh/ToMC0Ynu4LPnFp4kGkRAag=; b=r3mPXf8cAD3Iye+cwzEPep9JE CWq4Tla8EQRkSTwYFM3IRh6SA9q5sKphcOcva+2yY0+4Yq05ijtVl7Kx48RZOh6pafeasAJjYKxQG RQbZxmDEqWwfZOiAJSEkV9aP7OK0pehLRcCrGysj29LDbwdTdfUB1WV6sNki3DydrXfdA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlTbq-0006b8-2a; Wed, 17 Jun 2020 08:39:50 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlTbp-0001Cv-Ry; Wed, 17 Jun 2020 08:39:49 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlTbp-0004Nh-QY; Wed, 17 Jun 2020 08:39:49 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151161: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=06760c2bf322cef4622b56bafee74fe93ae01630 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Wed, 17 Jun 2020 08:39:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151161 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151161/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 06760c2bf322cef4622b56bafee74fe93ae01630 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 33 days Failing since 150943 2020-06-09 17:06:00 Z 7 days 7 attempts Testing same since 151161 2020-06-15 22:27:38 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 06760c2bf322cef4622b56bafee74fe93ae01630 Author: Andrew Cooper Date: Fri Jun 12 18:32:27 2020 +0100 tools/libxl: Fix memory leak in libxl_cpuid_set() xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to free() seeing as it discards the results. This is logically a backport of c/s b91825f628 "tools/libxc: Drop config_transformed parameter from xc_cpuid_set()" but rewritten as one caller of xc_cpuid_set() does use returned values. Signed-off-by: Andrew Cooper (cherry picked from commit c54de7d9df7718ea53bf21e1ff5bbd339602a704) commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Wed Jun 17 09:10:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 09:10:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlU4t-00061U-NI; Wed, 17 Jun 2020 09:09:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlU4s-00061P-Vp for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 09:09:51 +0000 X-Inumbo-ID: 4c1696b8-b07a-11ea-b9ae-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4c1696b8-b07a-11ea-b9ae-12813bfff9fa; Wed, 17 Jun 2020 09:09:50 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 2Ga5Ehl2ycOHUWmP6oHZ+QWITf7JVhV5CW0cohm862hmWIaZSU9gnW6p+X3Xh2MxK5Y7NLtGq4 jTMEAqUU94W+fofCGiq5piCeyxthkYN8VDrymV4/u9asg9eat3WwDiC9eGab2BasBM4XFERv1E bneHhbW/v/UEofkRf7jaAemOXv+YJp6Q6RdEU39GL3AvxmmxcxVxVv2MsXY6DpDnwT4BENlA/F v1GS8PH6PzIifqEbP2P1m2mLdbvULG0qfn1F2+slZJthS504ReM8reLMyvB0SBbdgveB8RO+dm Dq4= X-SBRS: 2.7 X-MesageID: 20263476 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20263476" Date: Wed, 17 Jun 2020 11:09:42 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit Message-ID: <20200617090942.GY735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> <20200616173857.GU735@Air-de-Roger> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 07:47:07PM +0200, Michał Leszczyński wrote: > ----- 16 cze 2020 o 19:38, Roger Pau Monné roger.pau@citrix.com napisał(a): > > > On Tue, Jun 16, 2020 at 05:24:11PM +0200, Michał Leszczyński wrote: > >> Enable IPT when entering the VM and disable it on vmexit. > >> Register state is persisted using vCPU ipt_state structure. > > > > Shouldn't this be better done using Intel MSR load lists? > > > > That seems to be what the SDM recommends for tracing VM events. > > > > Thanks, Roger. > > > This is intentional, additionally described by the comment: > > // MSR_IA32_RTIT_CTL is context-switched manually instead of being > // stored inside VMCS, as of Q2'20 only the most recent processors > // support such field in VMCS > > > There is a special feature flag which indicates whether MSR_IA32_RTIT_CTL can be loaded using MR load lists. I've been looking at the Intel SDM and I'm not able to find which bit signals whether MSR_IA32_RTIT_CTL can be loaded using MSR load lists. Sorry to ask, but can you elaborate on where is this signaled? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 17 09:21:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 09:21:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUFt-0007ZU-Qi; Wed, 17 Jun 2020 09:21:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUFs-0007ZP-CN for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 09:21:12 +0000 X-Inumbo-ID: e216d2da-b07b-11ea-bca7-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e216d2da-b07b-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 09:21:11 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: QTHvT4+wjw8k8S/o0nb4H+k3beeiN6CrswUQWjCGDmVPBmFDnKn4RziYsXwS3M8fLhka54ezPT T1He5jaDeLIgC2LEGIXyzZ9EVunhgEsJl+5G9rNoopBNTmpIR7id4VeQwQ9BNEKBmldTjgHHKd EyRcYg36xtr2pX09FptE9LM85AmkqRyHUT1z4QxCn1kclSFlhzL2Pnl/Pq2Wdea61xbYdJ8nHT iiARxx0MYapjnShPoQVjI+pRMXvRc005ejVqzm390KJkp5k9+2FQwl2HGFyqMADj3DY0Um9+rA N4Q= X-SBRS: 2.7 X-MesageID: 20264108 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20264108" Date: Wed, 17 Jun 2020 11:21:03 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: "Kang, Luwei" Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring Message-ID: <20200617092103.GZ735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Tian, Kevin" , Stefano Stabellini , Julien Grall , "Nakajima, Jun" , Wei Liu , Andrew Cooper , =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 06:45:22AM +0000, Kang, Luwei wrote: > > -----Original Message----- > > From: Tian, Kevin > > Sent: Wednesday, June 17, 2020 9:35 AM > > To: Michał Leszczyński ; Andrew Cooper > > > > Cc: Xen-devel ; Jan Beulich > > ; Wei Liu ; Roger Pau Monné > > ; Nakajima, Jun ; George > > Dunlap ; Ian Jackson ; > > Julien Grall ; Stefano Stabellini ; > > Kang, Luwei > > Subject: RE: [PATCH v1 0/7] Implement support for external IPT monitoring > > > > +Luwei, who developed PT for KVM and is the best one who can help > > review VMX changes from Intel side. Please include him in future post or > > discussion. > > > > > -----Original Message----- > > > From: Michał Leszczyński > > > Sent: Wednesday, June 17, 2020 2:48 AM > > > To: Andrew Cooper > > > Cc: Xen-devel ; Jan Beulich > > > ; Wei Liu ; Roger Pau Monné > > > ; Nakajima, Jun ; Tian, > > > Kevin ; George Dunlap > > > ; Ian Jackson ; > > > Julien Grall ; Stefano Stabellini > > > > > > Subject: Re: [PATCH v1 0/7] Implement support for external IPT > > > monitoring > > > > > > ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com > > > napisał(a): > > > > > > > On 16/06/2020 16:16, Michał Leszczyński wrote: > > > > When this subject was broached on xen-devel before, one issue was > > > > the fact that all actions which are intercepted don't end up writing > > > > any appropriate packets.  This is perhaps less of an issue for this > > > > example, where the external agent can see VMExits in the trace, but > > > > it still results in missing information.  (It is a major problem for > > > > PT within the guest, and needs Xen's intercept/emulation framework > > > > being updated to be PT-aware so it can fill in the same packets > > > > which hardware would have done for equivalent actions.) > > > > > > Ok, this sounds like a hard issue. Could you point out what could be > > > the particular problematic cases? For instance, if something would > > > alter EIP/RIP or CR3 then I belive it would still be recorded in PT > > > trace (i.e. these values will be logged on VM entry). > > e.g. If a VM exit is taken on a guest write to CR3 (including “MOV CR3” as well as task switches), the PIP packet > normally generated on the CR3 write will be missing. The PIP packet needs to be written to the PT buffer by software. Another example is VM-exit taken on RDTSC. > > For VM introspection, all the Intel PT packets may need to emulated by software. Some description in SDM as below: > If a VMM emulates an element of processor state by taking a VM exit on reads and/or writes to that piece of state, and the state element impacts Intel PT packet generation or values, it may be incumbent upon the VMM to insert or modify the output trace data. I got the impression that IPT was mostly useful together with introspection, as you can then get events from trapped instructions (and likely emulated) from the introspection interface, while being able to get the processor trace for non-trapped events. I'm not sure whether there would be corner cases with trapped instructions not being handled by the introspection framework. How does KVM deal with this, do they insert/modify trace packets on trapped and emulated instructions by the VMM? Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 17 09:28:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 09:28:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUMb-0007q6-Us; Wed, 17 Jun 2020 09:28:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUMa-0007ob-FV for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 09:28:08 +0000 X-Inumbo-ID: d79497c4-b07c-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d79497c4-b07c-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 09:28:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=szpolumGaZTwyvpQJZDSSUINfbwfFLmAiJYjhDWeicc=; b=GG4x90l2CYV2GIHDKrmBwZeM3 4dikHhOOYOPQppxw4dZIFT7SYnK6fijoxV2cSAoyOYLrHofOyjFVf+Eh0EU1/n3GP0u4ZGgmid8dW 80kmb8sTOj0d9VTnx7h4td3ospWxLqecw+y8saeQN4qgtSSKSWrIiE9rAeYNCFdQdTY+Y=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUMU-0007Uo-52; Wed, 17 Jun 2020 09:28:02 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlUMT-0002aD-QZ; Wed, 17 Jun 2020 09:28:01 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlUMT-0008E8-Pp; Wed, 17 Jun 2020 09:28:01 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151162: all pass - PUSHED X-Osstest-Versions-This: ovmf=8927e2777786a43cddfaa328b0f4c41a09c629c9 X-Osstest-Versions-That: ovmf=b90beadfae8f1153697fbb87f923cfa14578ee3e From: osstest service owner Date: Wed, 17 Jun 2020 09:28:01 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151162 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151162/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8927e2777786a43cddfaa328b0f4c41a09c629c9 baseline version: ovmf b90beadfae8f1153697fbb87f923cfa14578ee3e Last test of basis 151139 2020-06-15 00:09:55 Z 2 days Testing same since 151162 2020-06-16 01:58:37 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Rebecca Cran jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git b90beadfae..8927e27777 8927e2777786a43cddfaa328b0f4c41a09c629c9 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Wed Jun 17 09:48:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 09:48:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUgS-0001Fx-Nj; Wed, 17 Jun 2020 09:48:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUgR-0001Fd-AG for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 09:48:39 +0000 X-Inumbo-ID: b53fcf24-b07f-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b53fcf24-b07f-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 09:48:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eUZMhkBEY0GHPn35bUmtW2VgD75gHL5pCVCpExNeFRo=; b=XXSYhvpN99pIduVPEz5D21QKK YnA1YCXo5k/+c8jcs9W3jyxYdxz9c7dFTl+zEr2nn3OVRBJgp50z/cXc9fLnHJgJbGVLbMFZYhAYn rPVkldvQUDBcqHWOzFEg2KYVkZy7dDmhkNSs9QFUT6VJFCrMZlUlsgshVSRlQaPeQQKFo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUgK-0007ra-Ri; Wed, 17 Jun 2020 09:48:32 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlUgK-0003LH-Id; Wed, 17 Jun 2020 09:48:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlUgK-0005RB-I9; Wed, 17 Jun 2020 09:48:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-coverity test] 151186: all pass - PUSHED X-Osstest-Versions-This: xen=3625b04991b4d6affadd99d377ab84bac48dfff4 X-Osstest-Versions-That: xen=b91825f628c9a62cf2a3a0d972ea81484a8b7fce From: osstest service owner Date: Wed, 17 Jun 2020 09:48:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151186 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/151186/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 3625b04991b4d6affadd99d377ab84bac48dfff4 baseline version: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce Last test of basis 151106 2020-06-14 09:23:09 Z 3 days Testing same since 151186 2020-06-17 09:18:28 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Bertrand Marquis George Dunlap Ian Jackson Jason Andryuk Nick Rosbrook Nick Rosbrook Tamas K Lengyel Wei Liu jobs: coverity-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git b91825f628..3625b04991 3625b04991b4d6affadd99d377ab84bac48dfff4 -> coverity-tested/smoke From xen-devel-bounces@lists.xenproject.org Wed Jun 17 09:58:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 09:58:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUph-00028f-Lp; Wed, 17 Jun 2020 09:58:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUpg-00028a-Ri for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 09:58:12 +0000 X-Inumbo-ID: 0db546c4-b081-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0db546c4-b081-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 09:58:12 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0885AACF1; Wed, 17 Jun 2020 09:58:14 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Tamas K Lengyel References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> From: Jan Beulich Message-ID: Date: Wed, 17 Jun 2020 11:58:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , George Dunlap , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 21:31, Tamas K Lengyel wrote: > While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been > observed due to a mm-lock order violation while copying the HVM CPU context > from the parent. This issue has been identified to be due to > hap_update_paging_modes getting a lock on the gfn using get_gfn. This call also > creates a shared entry in the fork's memory map for the cr3 gfn. The function > later calls hap_update_cr3 while holding the paging_lock, which results in the > lock-order violation in vmx_load_pdptrs when it tries to unshare the above entry. > > This issue has not affected VMs running other OS's as a call to vmx_load_pdptrs > is benign if PAE is not enabled or if EFER_LMA is set and returns before > trying to unshare and map the page. > > Using get_gfn_type to get a lock on the gfn avoids this problem as we can > populate the fork's gfn with a copied page instead of a shared entry if its > needed, thus avoiding the lock order violation while holding paging_lock. > > Signed-off-by: Tamas K Lengyel > --- > The bug seems to have been present since commit 4cb6c4f4941, only discovered > now due to the heavy use of mem_sharing with VM forks. I'm unconvinced that commit is the origin of the problem. Before that, get_gfn_unshare() was used, which aiui had/has similar locking properties. In fact I'm having trouble seeing how this works at all, i.e. with or without mem-sharing: p2m_get_page_from_gfn() at the very least uses p2m_read_lock(), which also doesn't nest inside the paging lock. What am I overlooking? > --- a/xen/arch/x86/mm/hap/hap.c > +++ b/xen/arch/x86/mm/hap/hap.c > @@ -748,12 +748,19 @@ static void hap_update_paging_modes(struct vcpu *v) > struct domain *d = v->domain; > unsigned long cr3_gfn = v->arch.hvm.guest_cr[3] >> PAGE_SHIFT; > p2m_type_t t; > + p2m_query_t q = P2M_ALLOC; > > - /* We hold onto the cr3 as it may be modified later, and > - * we need to respect lock ordering. No need for > - * checks here as they are performed by vmx_load_pdptrs > - * (the potential user of the cr3) */ > - (void)get_gfn(d, cr3_gfn, &t); > + /* > + * We hold onto the cr3 as it may be modified later, and > + * we need to respect lock ordering. Unshare here if we have to as to avoid > + * a lock-order violation later while we are holding the paging_lock. > + * Further checks are performed by vmx_load_pdptrs (the potential user of > + * the cr3). > + */ Nit: Please re-flow such that the first line isn't very noticeably shorter than the later ones. > + if ( hvm_pae_enabled(v) && !hvm_long_mode_active(v) ) > + q |= P2M_UNSHARE; > + > + (void)get_gfn_type(d, cr3_gfn, &t, q); Imo this then wants to be accompanied by dropping the unsharing attempt from vmx_load_pdptrs(). By using get_gfn_query_unlocked() there (assuming all code paths hold the paging lock) the lock order issue could be addressed in full then. (If taking this route, the comment ahead of get_gfn_query_unlocked()'s declaration will want adjusting, to drop mentioning shadow mode explicitly as leveraging already holding the paging lock.) If there are code paths of both kinds, which approach to use in vmx_load_pdptrs() may need to be chosen based on what paging_locked_by_me() returns. Or perhaps an unlocked query is fine in either case? Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 10:02:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 10:02:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUtZ-0002zM-6t; Wed, 17 Jun 2020 10:02:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUtX-0002zD-Hx for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 10:02:11 +0000 X-Inumbo-ID: 9ad8c4fe-b081-11ea-b9bf-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9ad8c4fe-b081-11ea-b9bf-12813bfff9fa; Wed, 17 Jun 2020 10:02:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=crye4yAx0FNnkSDWtoNK4wH3HBivH3R+0BkBxYbvdBc=; b=W0cAwItHCoybWEqx/9SOdJgz6 0wb0iX0YUoXEIWAJnuWez+waA8lbs4IvDQqZODBMpHDwAmiiAEzf2OYiM/tY8I1Rup6J7A22JbZax 8TOG5YOpqC23EfP6NfKPaxOk2gc/Fylk6T3BojPNNKQ3F9VycSVNcu219Mkjy2U5+dAp8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlUtT-0008Ci-W3; Wed, 17 Jun 2020 10:02:08 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlUtT-0004Xa-JU; Wed, 17 Jun 2020 10:02:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlUtT-0004SM-IX; Wed, 17 Jun 2020 10:02:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 151164: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-arm64-libvirt:libvirt-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:build-armhf-libvirt:libvirt-build:fail:regression xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:guest-start:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=6e477c2ea4d5c26a7a7b2f850166aa79edc5225c X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Wed, 17 Jun 2020 10:02:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151164 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151164/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 12 guest-start fail like 150120 test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 38 days Failing since 150940 2020-06-09 17:05:20 Z 7 days 10 attempts Testing same since 151070 2020-06-13 06:57:26 Z 4 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Ian Jackson John Thomson Julien Grall Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm pass build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 pass build-armhf pass build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c Author: Wei Liu Date: Mon Jun 12 16:04:17 2017 +0100 ipxe: update to newer commit To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7. The only patch we have applies cleanly. Reported-by: Zhongze Liu Signed-off-by: Wei Liu Acked-by: Ian Jackson (cherry picked from commit 461b2165346de236fff2d00d1c318062f1daab08) commit 6a1c431890599c701117bf9822898f60a18444a3 Author: John Thomson Date: Tue May 15 11:48:43 2018 +1000 tools/ocaml/libs/xc fix gcc-8 format-truncation warning CC xenctrl_stubs.o xenctrl_stubs.c: In function 'failwith_xc': xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "%d: %s: %s", error->code, ^ xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028 snprintf(error_str, sizeof(error_str), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%d: %s: %s", error->code, ~~~~~~~~~~~~~~~~~~~~~~~~~~ xc_error_code_to_desc(error->code), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error->message); ~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1 m Signed-off-by: John Thomson Acked-by: Christian Lindig Release-acked-by: Juergen Gross (cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795) commit 41f597f5167c2e78a3c70d219710c8805d7fec8e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:50 2018 +0200 tools/misc: fix hypothetical buffer overflow in xen-lowmemd gcc-8 complains: xen-lowmemd.c: In function 'handle_low_mem': xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=] snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~ ~~~~ xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In practice it wouldn't happen, because 'data' contains string representation of 64-bit unsigned number (20 characters at most). But place a limit to mute gcc warning. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080) commit 1eae17268887bacbc598ef6e3290059dbeb4fd8f Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:52 2018 +0200 tools/blktap2: fix possible '\0' truncation gcc-8 complains: tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring': tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^ tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255 snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "- 1" in buffer size should be actually applied to message, to leave place for terminating '\0', not the other way around (truncate '\0' even if it would fit). In function 'tapdisk_control_open_image', inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10: tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'tapdisk_control_create_socket', inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9: tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block-qcow.c: In function 'qcow_create': block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(backing_filename, backing_file, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(backing_filename)); ~~~~~~~~~~~~~~~~~~~~~~~~~ I those cases, reduce size of copied string and make sure final '\0' is added. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a) commit f1e75e5c7054d8cd7bdfe30c6a95af35cc24fbb2 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:54 2018 +0200 tools/gdbsx: fix -Wstringop-truncation warning gcc-8 complains: gx_main.c: In function 'prepare_stop_reply': gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(buf, "watch:", 6); ^~~~~~~~~~~~~~~~~~~~~~~~~ Since terminating '\0' isn't needed here at all, switch to memcpy. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f) commit f034ab45c15aef9c784dbcdc5c893e268d4a094c Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:53 2018 +0200 tools/xenpmd: fix possible '\0' truncation gcc-8 complains: xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->oem_info, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->battery_type, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->serial_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->model_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy 31 chars, then make sure terminating '\0' is present. Those fields are passed to strlen and as '%s' for snprintf later. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b) commit 9737f89b076ae4d05e6f974a7c21aced4459966e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:49 2018 +0200 tools/libxc: fix strncpy size gcc-8 warns about possible truncation of trailing '\0'. Final character is overridden by '\0' anyway, so don't bother to copy it. This fixes compile failure: xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159) commit 1dd64783024c5c9e600c3d33393b795c68a46f65 Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit 80d78acf9e60ae6a88d6cb6f3535eaf67c81f61c Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. Extend libxl's table of named parameters to include RDRAND/RDSEED, and have the compiler construct it in .rodata, rather than on the stack at runtime each time it is called. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Wed Jun 17 10:32:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 10:32:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlVMn-0005Ug-VA; Wed, 17 Jun 2020 10:32:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlVMn-0005Ub-6A for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 10:32:25 +0000 X-Inumbo-ID: d4ced56e-b085-11ea-b9c5-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d4ced56e-b085-11ea-b9c5-12813bfff9fa; Wed, 17 Jun 2020 10:32:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 02B2CAC79; Wed, 17 Jun 2020 10:32:26 +0000 (UTC) Subject: Re: [PATCH 7/9] x86/hvm: Disable MPX by default To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-8-andrew.cooper3@citrix.com> <58d7254d-8953-93c4-9eb2-9be45f39bc4e@suse.com> From: Jan Beulich Message-ID: <6898eb94-868c-b706-7cdd-7d54db09c1b0@suse.com> Date: Wed, 17 Jun 2020 12:32:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 18:15, Andrew Cooper wrote: > On 16/06/2020 10:33, Jan Beulich wrote: >> On 15.06.2020 16:15, Andrew Cooper wrote: >>> @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, >>> goto out; >>> } >>> >>> + /* >>> + * Account for feature which have been disabled by default since Xen 4.13, >>> + * so migrated-in VM's don't risk seeing features disappearing. >>> + */ >>> + if ( restore ) >>> + { >>> + if ( di.hvm ) >>> + { >>> + p->feat.mpx = test_bit(X86_FEATURE_MPX, host_featureset); >> Why do you derive this from the host featureset instead of the max >> one for the guest type? > > Because that is how the logic worked for 4.13. > > Also, because we don't have easy access to the actual guest max > featureset at this point.  I could add two new sysctl subops to > get_featureset, but the reason for not doing so before are still > applicable now. > > There is a theoretical case where host MPX is visible but guest max is > hidden, and that is down to the vmentry controls.  As this doesn't exist > in real hardware, I'm not terribly concerned about it. I'd also see us allow features to be kept for the host, but masked off of the/some guest feature sets, by way of a to-be-introduced command line option. I take your reply to mean that you agree that conceptually it ought to be max which gets used here, but there's no practical difference at this point. >> Also, while you modify p here, ... >> >>> + } >>> + } >>> + >>> if ( featureset ) >>> { >>> uint32_t disabled_features[FEATURESET_NR_ENTRIES], >> ... the code in this if()'s body ignores p altogether. > > That is correct. > >> I realize the >> only caller of the function passes NULL for "featureset", but I'd >> like to understand the rationale here anyway before giving an R-b. > > The meaning of 'featureset' is "here are the exact bits I want you to use". With validation to happen only in the hypervisor then, I suppose? If for both parts my understanding is correct: Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 10:39:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 10:39:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlVTm-0005hK-N7; Wed, 17 Jun 2020 10:39:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlVTl-0005hF-CP for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 10:39:37 +0000 X-Inumbo-ID: d678ec28-b086-11ea-b9c6-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d678ec28-b086-11ea-b9c6-12813bfff9fa; Wed, 17 Jun 2020 10:39:36 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 64CB4AC12; Wed, 17 Jun 2020 10:39:39 +0000 (UTC) Subject: Re: [PATCH 9/9] x86/spec-ctrl: Hide RDRAND by default on IvyBridge To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-10-andrew.cooper3@citrix.com> <00db98fd-d268-71ae-fad1-fb59d2f1eba1@citrix.com> From: Jan Beulich Message-ID: Date: Wed, 17 Jun 2020 12:39:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <00db98fd-d268-71ae-fad1-fb59d2f1eba1@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 18:26, Andrew Cooper wrote: > On 16/06/2020 11:00, Jan Beulich wrote: >> On 15.06.2020 16:15, Andrew Cooper wrote: >>> --- a/tools/libxc/xc_cpuid_x86.c >>> +++ b/tools/libxc/xc_cpuid_x86.c >>> @@ -503,6 +503,9 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, >>> */ >>> if ( restore ) >>> { >>> + if ( test_bit(X86_FEATURE_RDRAND, host_featureset) && !p->basic.rdrand ) >>> + p->basic.rdrand = true; >> Same question as before: Why do you derive from the host feature set rather >> than the domain type's maximum one? > > Answer the same as previous. > > Although I do see now that this should be simplified to: > >     p->basic.rdrand = test_bit(X86_FEATURE_RDRAND, host_featureset); > > which I've done. Right. It makes even more noticeable though that this may mean a new feature suddenly appearing after the guest was migrated. But aiui this still is the default behavior for all features anyway. >>> --- a/xen/arch/x86/cpuid.c >>> +++ b/xen/arch/x86/cpuid.c >>> @@ -340,6 +340,25 @@ static void __init calculate_host_policy(void) >>> } >>> } >>> >>> +static void __init guest_common_default_feature_adjustments(uint32_t *fs) >>> +{ >>> + /* >>> + * IvyBridge client parts suffer from leakage of RDRAND data due to SRBDS >>> + * (XSA-320 / CVE-2020-0543), and won't be receiving microcode to >>> + * compensate. >>> + * >>> + * Mitigate by hiding RDRAND from guests by default, unless explicitly >>> + * overridden on the Xen command line (cpuid=rdrand). Irrespective of the >>> + * default setting, guests can use RDRAND if explicitly enabled >>> + * (cpuid="host,rdrand=1") in the VM's config file, and VMs which were >>> + * previously using RDRAND can migrate in. >>> + */ >>> + if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && >>> + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x3a && >> This is the first time (description plus patch so far) that the issue >> gets mentioned to be for and the workaround restricted to client parts >> only. If so, I think at least the doc should say so too. > > I've updated the command line doc, and patch subject. Thanks - with the adjustments Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 11:17:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 11:17:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlW46-0000Vb-88; Wed, 17 Jun 2020 11:17:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlW45-0000VW-CT for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 11:17:09 +0000 X-Inumbo-ID: 14f16dcc-b08c-11ea-b9cb-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 14f16dcc-b08c-11ea-b9cb-12813bfff9fa; Wed, 17 Jun 2020 11:17:08 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: WdTRJBj7EHOAV/mTYxUcEhTHTJ98vDTpC8EfLkUxSPnM9GmcVlPSUXeSMTbjNCjZadMm6541Qc 8/8yKyt7jmSbv2y+80XfGrjnx43Rp1oa0H55HPXqGICslzgg5Il8zJ6Suxplm4xzUkMRTlAYpH UJjiEV3NL9zSo4V5lr221Bi6gmOcgqfMRI95ex6bu34UOv7fp+W30Nck5A44jdIVM2aX8TZpYW f+M5LznYz8OJwd6R0Wmb6Bx0YFeSCDVRs/THYUuo2C0dP7f6kOaLeoD4xspNbrS+B4bpwP6Ujc hxY= X-SBRS: 2.7 X-MesageID: 20603627 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20603627" Subject: Re: [PATCH 7/9] x86/hvm: Disable MPX by default To: Jan Beulich References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-8-andrew.cooper3@citrix.com> <58d7254d-8953-93c4-9eb2-9be45f39bc4e@suse.com> <6898eb94-868c-b706-7cdd-7d54db09c1b0@suse.com> From: Andrew Cooper Message-ID: <76fabe81-3f2c-5c48-c2c0-879bc29f4fb7@citrix.com> Date: Wed, 17 Jun 2020 12:16:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <6898eb94-868c-b706-7cdd-7d54db09c1b0@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17/06/2020 11:32, Jan Beulich wrote: > On 16.06.2020 18:15, Andrew Cooper wrote: >> On 16/06/2020 10:33, Jan Beulich wrote: >>> On 15.06.2020 16:15, Andrew Cooper wrote: >>>> @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, >>>> goto out; >>>> } >>>> >>>> + /* >>>> + * Account for feature which have been disabled by default since Xen 4.13, >>>> + * so migrated-in VM's don't risk seeing features disappearing. >>>> + */ >>>> + if ( restore ) >>>> + { >>>> + if ( di.hvm ) >>>> + { >>>> + p->feat.mpx = test_bit(X86_FEATURE_MPX, host_featureset); >>> Why do you derive this from the host featureset instead of the max >>> one for the guest type? >> Because that is how the logic worked for 4.13. >> >> Also, because we don't have easy access to the actual guest max >> featureset at this point.  I could add two new sysctl subops to >> get_featureset, but the reason for not doing so before are still >> applicable now. >> >> There is a theoretical case where host MPX is visible but guest max is >> hidden, and that is down to the vmentry controls.  As this doesn't exist >> in real hardware, I'm not terribly concerned about it. > I'd also see us allow features to be kept for the host, but masked > off of the/some guest feature sets, by way of a to-be-introduced > command line option. What kind of usecase do you have in mind for this?  We've got a load of features which are blanket disabled for guests.  I suppose `ler` et al ought to have an impact, except for the fact that LBR at that level isn't architectural and always expected. > I take your reply to mean that you agree that conceptually it > ought to be max which gets used here, but there's no practical > difference at this point. If max were trivially available, I'd use use that, but its not, and host is equivalent in the cases we care about. > >>> Also, while you modify p here, ... >>> >>>> + } >>>> + } >>>> + >>>> if ( featureset ) >>>> { >>>> uint32_t disabled_features[FEATURESET_NR_ENTRIES], >>> ... the code in this if()'s body ignores p altogether. >> That is correct. >> >>> I realize the >>> only caller of the function passes NULL for "featureset", but I'd >>> like to understand the rationale here anyway before giving an R-b. >> The meaning of 'featureset' is "here are the exact bits I want you to use". > With validation to happen only in the hypervisor then, I suppose? Almost none of this logic has any validation in the toolstack side (that which does, was added by me fairly recently).  Its going to be one of several large changes in the new world. > If for both parts my understanding is correct: > Reviewed-by: Jan Beulich Thanks. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 17 11:21:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 11:21:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlW84-0001IU-PT; Wed, 17 Jun 2020 11:21:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlW83-0001IP-Gv for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 11:21:15 +0000 X-Inumbo-ID: a7d1a4f4-b08c-11ea-b9cb-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a7d1a4f4-b08c-11ea-b9cb-12813bfff9fa; Wed, 17 Jun 2020 11:21:15 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Njq6p6HfjQdQHbyy4JlsVIjH0+75e7NKJDU83mJN1ti+K0ene32611xjfCepaaYxziWuBS/TZ1 7fqMqTpoh64oH2p7qRdnml4FlVn8Fe+w8W0Yp+T6eTtsN1LqWGNpV40yumSKGyNzvIvaerLgCu HAD7wk/hFdXrbWIeEKtgfwzXcJPIIqWI8AAnrYOTtYBHLM0h0bzjiGDXToCnB2plymCm1KEjSu ZdK6+Fud+XG2DMYW7SRCWos66J4flNXkS2lX4o8MODC8NPpSDvGomr/kkyRXpTmC7f89dM9eyo MZw= X-SBRS: 2.7 X-MesageID: 20487720 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20487720" Subject: Re: [PATCH 9/9] x86/spec-ctrl: Hide RDRAND by default on IvyBridge To: Jan Beulich References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-10-andrew.cooper3@citrix.com> <00db98fd-d268-71ae-fad1-fb59d2f1eba1@citrix.com> From: Andrew Cooper Message-ID: <63106e4d-3603-9054-c144-1b89d11e30a0@citrix.com> Date: Wed, 17 Jun 2020 12:21:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17/06/2020 11:39, Jan Beulich wrote: > On 16.06.2020 18:26, Andrew Cooper wrote: >> On 16/06/2020 11:00, Jan Beulich wrote: >>> On 15.06.2020 16:15, Andrew Cooper wrote: >>>> --- a/tools/libxc/xc_cpuid_x86.c >>>> +++ b/tools/libxc/xc_cpuid_x86.c >>>> @@ -503,6 +503,9 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, >>>> */ >>>> if ( restore ) >>>> { >>>> + if ( test_bit(X86_FEATURE_RDRAND, host_featureset) && !p->basic.rdrand ) >>>> + p->basic.rdrand = true; >>> Same question as before: Why do you derive from the host feature set rather >>> than the domain type's maximum one? >> Answer the same as previous. >> >> Although I do see now that this should be simplified to: >> >>     p->basic.rdrand = test_bit(X86_FEATURE_RDRAND, host_featureset); >> >> which I've done. > Right. It makes even more noticeable though that this may mean a > new feature suddenly appearing after the guest was migrated. But > aiui this still is the default behavior for all features anyway. That is how migration always worked, until my migration v3 work in this release. I'm still surprised that it did, but both Linux and Windows were fine with FMS changing on migrate (Linux because it never checked again, while Windows would notice and install a new CPU HAL driver.) >>>> --- a/xen/arch/x86/cpuid.c >>>> +++ b/xen/arch/x86/cpuid.c >>>> @@ -340,6 +340,25 @@ static void __init calculate_host_policy(void) >>>> } >>>> } >>>> >>>> +static void __init guest_common_default_feature_adjustments(uint32_t *fs) >>>> +{ >>>> + /* >>>> + * IvyBridge client parts suffer from leakage of RDRAND data due to SRBDS >>>> + * (XSA-320 / CVE-2020-0543), and won't be receiving microcode to >>>> + * compensate. >>>> + * >>>> + * Mitigate by hiding RDRAND from guests by default, unless explicitly >>>> + * overridden on the Xen command line (cpuid=rdrand). Irrespective of the >>>> + * default setting, guests can use RDRAND if explicitly enabled >>>> + * (cpuid="host,rdrand=1") in the VM's config file, and VMs which were >>>> + * previously using RDRAND can migrate in. >>>> + */ >>>> + if ( boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && >>>> + boot_cpu_data.x86 == 6 && boot_cpu_data.x86_model == 0x3a && >>> This is the first time (description plus patch so far) that the issue >>> gets mentioned to be for and the workaround restricted to client parts >>> only. If so, I think at least the doc should say so too. >> I've updated the command line doc, and patch subject. > Thanks - with the adjustments > Reviewed-by: Jan Beulich Thanks. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 17 11:24:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 11:24:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWB0-0001RA-7S; Wed, 17 Jun 2020 11:24:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWAy-0001R4-H9 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 11:24:16 +0000 X-Inumbo-ID: 1384f980-b08d-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1384f980-b08d-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 11:24:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C0DD2AD2A; Wed, 17 Jun 2020 11:24:18 +0000 (UTC) Subject: Re: [PATCH 7/9] x86/hvm: Disable MPX by default To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-8-andrew.cooper3@citrix.com> <58d7254d-8953-93c4-9eb2-9be45f39bc4e@suse.com> <6898eb94-868c-b706-7cdd-7d54db09c1b0@suse.com> <76fabe81-3f2c-5c48-c2c0-879bc29f4fb7@citrix.com> From: Jan Beulich Message-ID: <356b06c9-b176-8e72-a3bf-2be62f5cbdb5@suse.com> Date: Wed, 17 Jun 2020 13:24:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <76fabe81-3f2c-5c48-c2c0-879bc29f4fb7@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17.06.2020 13:16, Andrew Cooper wrote: > On 17/06/2020 11:32, Jan Beulich wrote: >> On 16.06.2020 18:15, Andrew Cooper wrote: >>> On 16/06/2020 10:33, Jan Beulich wrote: >>>> On 15.06.2020 16:15, Andrew Cooper wrote: >>>>> @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, >>>>> goto out; >>>>> } >>>>> >>>>> + /* >>>>> + * Account for feature which have been disabled by default since Xen 4.13, >>>>> + * so migrated-in VM's don't risk seeing features disappearing. >>>>> + */ >>>>> + if ( restore ) >>>>> + { >>>>> + if ( di.hvm ) >>>>> + { >>>>> + p->feat.mpx = test_bit(X86_FEATURE_MPX, host_featureset); >>>> Why do you derive this from the host featureset instead of the max >>>> one for the guest type? >>> Because that is how the logic worked for 4.13. >>> >>> Also, because we don't have easy access to the actual guest max >>> featureset at this point.  I could add two new sysctl subops to >>> get_featureset, but the reason for not doing so before are still >>> applicable now. >>> >>> There is a theoretical case where host MPX is visible but guest max is >>> hidden, and that is down to the vmentry controls.  As this doesn't exist >>> in real hardware, I'm not terribly concerned about it. >> I'd also see us allow features to be kept for the host, but masked >> off of the/some guest feature sets, by way of a to-be-introduced >> command line option. > > What kind of usecase do you have in mind for this?  We've got a load of > features which are blanket disabled for guests.  I suppose `ler` et al > ought to have an impact, except for the fact that LBR at that level > isn't architectural and always expected. What I was thinking of was the kind of "none of my guests should use AVX512 - let me disable it globally, rather than individually in each guest's config" approach. Of course AVX512 is something we use in Xen only to emulate guest insns, but I think the example still serves the purpose. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 11:28:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 11:28:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWEm-0001ah-OF; Wed, 17 Jun 2020 11:28:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWEl-0001ac-1U for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 11:28:11 +0000 X-Inumbo-ID: 9f10a878-b08d-11ea-b7bb-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9f10a878-b08d-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 11:28:10 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: dCewLDUp+OXmjDIWJnQVCdx2/Nq64znMX2eYOpmePttCV7WcRc5BWyj6UMlLvR3RNa/toCb7Pi eq9SKUYJSlABSRDQ2uYPtMstEJht/RAhqy+M/fRcghH3cxF4jjFhljMP8tgZqxDbsid9H4zTqt MQW3wEHyqv5itrXad+iMztD0Tv28oPOo6cjMM43FIN3kVNCJEkqfTy+fVxehTXtglqFUaE6Rmo YtyTj9EUQ41I9rZgM+IpWOyp/Sf/gKY5U6rQKUTeJvn4TNzMXBKTD+jW764xc0VKiCsrtg4wyY brA= X-SBRS: 2.7 X-MesageID: 21038814 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="21038814" Subject: Re: [PATCH 7/9] x86/hvm: Disable MPX by default To: Jan Beulich References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-8-andrew.cooper3@citrix.com> <58d7254d-8953-93c4-9eb2-9be45f39bc4e@suse.com> <6898eb94-868c-b706-7cdd-7d54db09c1b0@suse.com> <76fabe81-3f2c-5c48-c2c0-879bc29f4fb7@citrix.com> <356b06c9-b176-8e72-a3bf-2be62f5cbdb5@suse.com> From: Andrew Cooper Message-ID: Date: Wed, 17 Jun 2020 12:28:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <356b06c9-b176-8e72-a3bf-2be62f5cbdb5@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17/06/2020 12:24, Jan Beulich wrote: > On 17.06.2020 13:16, Andrew Cooper wrote: >> On 17/06/2020 11:32, Jan Beulich wrote: >>> On 16.06.2020 18:15, Andrew Cooper wrote: >>>> On 16/06/2020 10:33, Jan Beulich wrote: >>>>> On 15.06.2020 16:15, Andrew Cooper wrote: >>>>>> @@ -479,6 +497,18 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore, >>>>>> goto out; >>>>>> } >>>>>> >>>>>> + /* >>>>>> + * Account for feature which have been disabled by default since Xen 4.13, >>>>>> + * so migrated-in VM's don't risk seeing features disappearing. >>>>>> + */ >>>>>> + if ( restore ) >>>>>> + { >>>>>> + if ( di.hvm ) >>>>>> + { >>>>>> + p->feat.mpx = test_bit(X86_FEATURE_MPX, host_featureset); >>>>> Why do you derive this from the host featureset instead of the max >>>>> one for the guest type? >>>> Because that is how the logic worked for 4.13. >>>> >>>> Also, because we don't have easy access to the actual guest max >>>> featureset at this point.  I could add two new sysctl subops to >>>> get_featureset, but the reason for not doing so before are still >>>> applicable now. >>>> >>>> There is a theoretical case where host MPX is visible but guest max is >>>> hidden, and that is down to the vmentry controls.  As this doesn't exist >>>> in real hardware, I'm not terribly concerned about it. >>> I'd also see us allow features to be kept for the host, but masked >>> off of the/some guest feature sets, by way of a to-be-introduced >>> command line option. >> What kind of usecase do you have in mind for this?  We've got a load of >> features which are blanket disabled for guests.  I suppose `ler` et al >> ought to have an impact, except for the fact that LBR at that level >> isn't architectural and always expected. > What I was thinking of was the kind of "none of my guests should use > AVX512 - let me disable it globally, rather than individually in > each guest's config" approach. Of course AVX512 is something we use > in Xen only to emulate guest insns, but I think the example still > serves the purpose. We actually have AVX512 disabled by default in XenServer.  The perf implications of letting 1 guest play with it is very severe. Now I think about it, I'm tempted to recommend it moves out of default generally. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 17 11:34:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 11:34:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWKp-0002Oi-Dc; Wed, 17 Jun 2020 11:34:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWKn-0002Od-Dj for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 11:34:25 +0000 X-Inumbo-ID: 7e583032-b08e-11ea-b9cf-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7e583032-b08e-11ea-b9cf-12813bfff9fa; Wed, 17 Jun 2020 11:34:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6FD47AEC8; Wed, 17 Jun 2020 11:34:27 +0000 (UTC) Subject: Re: [PATCH v1 2/7] x86/vmx: add IPT cpu feature To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1672321493.8765712.1592320839082.JavaMail.zimbra@cert.pl> <20200616163022.GR735@Air-de-Roger> From: Jan Beulich Message-ID: <4c338fef-0077-b69a-1ec1-8729caa218f0@suse.com> Date: Wed, 17 Jun 2020 13:34:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200616163022.GR735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Wei Liu , Andrew Cooper , Jun Nakajima , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 18:30, Roger Pau Monné wrote: > On Tue, Jun 16, 2020 at 05:20:39PM +0200, Michał Leszczyński wrote: >> Check if Intel Processor Trace feature is supported by current >> processor. Define hvm_ipt_supported function. >> >> Signed-off-by: Michal Leszczynski >> --- >> xen/arch/x86/hvm/vmx/vmx.c | 24 +++++++++++++++++++++ >> xen/include/asm-x86/cpufeature.h | 1 + >> xen/include/asm-x86/hvm/hvm.h | 9 ++++++++ >> xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + >> xen/include/public/arch-x86/cpufeatureset.h | 1 + >> 5 files changed, 36 insertions(+) >> >> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c >> index ab19d9424e..a91bbdb798 100644 >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -2484,6 +2484,7 @@ static bool __init has_if_pschange_mc(void) >> >> const struct hvm_function_table * __init start_vmx(void) >> { >> + u64 _vmx_misc_cap; > > Please use uint64_t, and you can drop the leading _vmx prefix, this is > already vmx specific. Actually, all of _vmx_ should be dropped (i.e. in particular local variables shouldn't start with an underscore). Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 11:41:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 11:41:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWRx-0003En-AN; Wed, 17 Jun 2020 11:41:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWRw-0003Ei-46 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 11:41:48 +0000 X-Inumbo-ID: 8400fb94-b08f-11ea-b9cf-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8400fb94-b08f-11ea-b9cf-12813bfff9fa; Wed, 17 Jun 2020 11:41:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7EAE7AEF6; Wed, 17 Jun 2020 11:41:46 +0000 (UTC) Subject: Re: [PATCH 7/9] x86/hvm: Disable MPX by default To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-8-andrew.cooper3@citrix.com> <58d7254d-8953-93c4-9eb2-9be45f39bc4e@suse.com> <6898eb94-868c-b706-7cdd-7d54db09c1b0@suse.com> <76fabe81-3f2c-5c48-c2c0-879bc29f4fb7@citrix.com> <356b06c9-b176-8e72-a3bf-2be62f5cbdb5@suse.com> From: Jan Beulich Message-ID: <7d0b514c-7af6-e1b2-4b95-1ab62fe02e1c@suse.com> Date: Wed, 17 Jun 2020 13:41:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17.06.2020 13:28, Andrew Cooper wrote: > We actually have AVX512 disabled by default in XenServer.  The perf > implications of letting 1 guest play with it is very severe. > > Now I think about it, I'm tempted to recommend it moves out of default > generally. Hmm, I'm tempted to ask whether you're kidding. This is the kind of feature that I see no reason at all to move out of default. Imo we shouldn't put in place policy like this - if anything shouldn't be on by default, it should imo be because of limitations in our handling (I've recently revived my UMIP emulation patch, which comes to mind here) or because of uncertainty on some aspects (like is the case for MOVDIR / ENQCMD for example). Anything else should be left to the admins to decide. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 11:47:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 11:47:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWX8-0003PT-UG; Wed, 17 Jun 2020 11:47:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWX8-0003PO-2n for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 11:47:10 +0000 X-Inumbo-ID: 4661bb06-b090-11ea-b9d3-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4661bb06-b090-11ea-b9d3-12813bfff9fa; Wed, 17 Jun 2020 11:47:09 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 1D84Szqh/iAfruf+3HZ72EEcKWxaZiZxMTdIzOxYGQ8ZqQ0S+gQVKGC27M9jVRENqFSelu01Yq hpMJ6+hKEBxcsoKIvC58ICUGuuGiVYJyqQ+PT4p5LFrJoUcHFJrfhk26LlWIFVpz+723h2VvBY RmemDw89BEotREbBE0T8eb/DCUxio6OLjyBIYqkVpQxGgFAn8XIjbV/D8W+yJrTjwDYpM3lU9E 97biLd0tT4tqAWSMYLEZMDN+8hDDcazdRx1aO2KilgjpxrzUvktGIK9SA+i+3xFhMDOmoy9vwR BWM= X-SBRS: 2.7 X-MesageID: 20605793 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20605793" Subject: Re: [PATCH 7/9] x86/hvm: Disable MPX by default To: Jan Beulich References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <20200615141532.1927-8-andrew.cooper3@citrix.com> <58d7254d-8953-93c4-9eb2-9be45f39bc4e@suse.com> <6898eb94-868c-b706-7cdd-7d54db09c1b0@suse.com> <76fabe81-3f2c-5c48-c2c0-879bc29f4fb7@citrix.com> <356b06c9-b176-8e72-a3bf-2be62f5cbdb5@suse.com> <7d0b514c-7af6-e1b2-4b95-1ab62fe02e1c@suse.com> From: Andrew Cooper Message-ID: <630ecde9-c56b-0d69-75f4-366d1ecc6928@citrix.com> Date: Wed, 17 Jun 2020 12:47:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <7d0b514c-7af6-e1b2-4b95-1ab62fe02e1c@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17/06/2020 12:41, Jan Beulich wrote: > On 17.06.2020 13:28, Andrew Cooper wrote: >> We actually have AVX512 disabled by default in XenServer.  The perf >> implications of letting 1 guest play with it is very severe. >> >> Now I think about it, I'm tempted to recommend it moves out of default >> generally. > Hmm, I'm tempted to ask whether you're kidding. I'm very definitely not. AVX512 is a disaster, perf wise on Skylake/CascadeLake, and its very easy to cripple the entire system, including the other guest. So much so that "better AVX512 frequency transitions" is a headline feature in IceLake. > This is the kind of > feature that I see no reason at all to move out of default. Imo we > shouldn't put in place policy like this - if anything shouldn't be > on by default, it should imo be because of limitations in our > handling (I've recently revived my UMIP emulation patch, which > comes to mind here) or because of uncertainty on some aspects (like > is the case for MOVDIR / ENQCMD for example). Anything else should > be left to the admins to decide. "left to the admins to decide" does not mean "on by default". "default" needs to be a sensible set, which migrates safely, and can't be used to trivially DoS the rest of the system.  An admin can always opt into allowing this DoS, but shouldn't have it by default. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 17 11:55:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 11:55:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWf7-0004GZ-Qu; Wed, 17 Jun 2020 11:55:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlWf6-0004GU-Sc for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 11:55:24 +0000 X-Inumbo-ID: 6d0557d0-b091-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6d0557d0-b091-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 11:55:24 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id E3A0EA3227; Wed, 17 Jun 2020 13:55:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id D5CEFA3221; Wed, 17 Jun 2020 13:55:21 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id C1Bl_heD8IBc; Wed, 17 Jun 2020 13:55:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3337EA3226; Wed, 17 Jun 2020 13:55:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id m_D4QzqUynqh; Wed, 17 Jun 2020 13:55:21 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 09244A3221; Wed, 17 Jun 2020 13:55:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id F0535215FA; Wed, 17 Jun 2020 13:54:50 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id h6igKZ9eMG5q; Wed, 17 Jun 2020 13:54:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 87B6E2244D; Wed, 17 Jun 2020 13:54:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QBZoRIukessH; Wed, 17 Jun 2020 13:54:45 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 6AD932182D; Wed, 17 Jun 2020 13:54:45 +0200 (CEST) Date: Wed, 17 Jun 2020 13:54:45 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> In-Reply-To: <20200617090942.GY735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> <20200616173857.GU735@Air-de-Roger> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> <20200617090942.GY735@Air-de-Roger> Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: switch IPT MSRs on vmentry/vmexit Thread-Index: Fne+GBNZEUczmf1siwoEM5lna0gtRA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 17 cze 2020 o 11:09, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Tue, Jun 16, 2020 at 07:47:07PM +0200, Micha=C5=82 Leszczy=C5=84ski wr= ote: >> ----- 16 cze 2020 o 19:38, Roger Pau Monn=C3=A9 roger.pau@citrix.com nap= isa=C5=82(a): >>=20 >> > On Tue, Jun 16, 2020 at 05:24:11PM +0200, Micha=C5=82 Leszczy=C5=84ski= wrote: >> >> Enable IPT when entering the VM and disable it on vmexit. >> >> Register state is persisted using vCPU ipt_state structure. >> >=20 >> > Shouldn't this be better done using Intel MSR load lists? >> >=20 >> > That seems to be what the SDM recommends for tracing VM events. >> >=20 >> > Thanks, Roger. >>=20 >>=20 >> This is intentional, additionally described by the comment: >>=20 >> // MSR_IA32_RTIT_CTL is context-switched manually instead of being >> // stored inside VMCS, as of Q2'20 only the most recent processors >> // support such field in VMCS >>=20 >>=20 >> There is a special feature flag which indicates whether MSR_IA32_RTIT_CT= L can be >> loaded using MR load lists. >=20 > I've been looking at the Intel SDM and I'm not able to find which bit > signals whether MSR_IA32_RTIT_CTL can be loaded using MSR load lists. > Sorry to ask, but can you elaborate on where is this signaled? >=20 > Thanks, Roger. According to SDM: > 24 Virtual Machine Control Structures -> 24.4 Guest-state Area -> 24.4.1 = Guest Register State > IA32_RTIT_CTL (64 bits). This field is supported only on processors that = support either the 1-setting of the "load IA32_RTIT_CTL" VM-entry control o= r that of the "clear IA32_RTIT_CTL" VM-exit control. > 24 Virtual Machine Control Structures -> 24.8 VM-entry Control Fields -> = 24.8.1 VM-Entry Controls > Software should consult the VMX capability MSRs IA32_VMX_ENTRY_CTLS to de= termine how it should set the reserved bits. Please look at bit position 18 "Load IA32_RTIT_CTL". Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:26:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:26:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlX8s-0006ry-Ko; Wed, 17 Jun 2020 12:26:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlX8r-0006rt-58 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:26:09 +0000 X-Inumbo-ID: b8a0e804-b095-11ea-b7bb-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id b8a0e804-b095-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 12:26:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592396768; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=i7Fhq/nMTPV4L9BtCZvLvgrxeMBQxohyRbXdk/P9aBA=; b=FfTPbND0+3jKZBT/Ko254KUxPHfWfNfIukIG2OMwjxQpun40O4XLHLV6IjxP9lh7v+X9Mf sDRgD8sGkQIc2ViTd8sToWPV47eKHrjlJIJG0Hz/ylqBkpQvAimoyS742W4/6N1LGpF4Uc /oDYRiO3jfapYqMuLWPhiapgyXuK91Y= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-226-EzyBSljVMdCehpHK2qf3Dw-1; Wed, 17 Jun 2020 08:26:06 -0400 X-MC-Unique: EzyBSljVMdCehpHK2qf3Dw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 14EED8CE68E; Wed, 17 Jun 2020 12:25:52 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-112-67.ams2.redhat.com [10.36.112.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2EDC279332; Wed, 17 Jun 2020 12:25:24 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 025DE16E16; Wed, 17 Jun 2020 14:25:23 +0200 (CEST) Date: Wed, 17 Jun 2020 14:25:22 +0200 From: Gerd Hoffmann To: qemu-devel@nongnu.org Subject: Re: [PATCH v3 0/4] microvm: memory config tweaks Message-ID: <20200617122522.wvkpkifysdpixzml@sirius.home.kraxel.org> References: <20200529073957.8018-1-kraxel@redhat.com> <20200608132507.snzujn4yb37z3xmj@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: <20200608132507.snzujn4yb37z3xmj@sirius.home.kraxel.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , Paul Durrant , "Michael S. Tsirkin" , imammedo@redhat.com, Marcel Apfelbaum , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini , philmd@redhat.com, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 08, 2020 at 03:25:07PM +0200, Gerd Hoffmann wrote: > Ping. Anyone going to pick this up? MAINTAINERS lists Sergio+Paolo ... > Or should I send a pull req myself? Hmm, no reply. I guess that means "send a pull req" ... take care, Gerd From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:29:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:29:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXBs-00070K-3b; Wed, 17 Jun 2020 12:29:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXBr-00070A-E0 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:29:15 +0000 X-Inumbo-ID: 27ec9168-b096-11ea-b9d6-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 27ec9168-b096-11ea-b9d6-12813bfff9fa; Wed, 17 Jun 2020 12:29:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592396954; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wUr9c1FJi7A1aTjG8v2DGsv6CTJYWqCn2CZCN7xc4cw=; b=BSg/OGnVFfzojhq5jt/hE4vfcjEikuNGZQ0Y+b6w955oH8E4MEW6dudDgnKyNX6YB7RnaF e6EuJmatv2gjCvvO7NRL6pSpkWn17KS8ZFnRzskUf4YreVY4kr5+UkuwV3OH5GXiD7xvFY Yj1M5MizUeRfR0ekJnGMsw2UuJ7WxkE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-312-SRuNPBTVOlyeotJDUcrfYQ-1; Wed, 17 Jun 2020 08:29:13 -0400 X-MC-Unique: SRuNPBTVOlyeotJDUcrfYQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A2D94107B472; Wed, 17 Jun 2020 12:29:11 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-112-67.ams2.redhat.com [10.36.112.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5782379302; Wed, 17 Jun 2020 12:29:03 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id C7C0A9D8F; Wed, 17 Jun 2020 14:29:01 +0200 (CEST) From: Gerd Hoffmann To: qemu-devel@nongnu.org Subject: [PULL 4/4] microvm: move virtio base to 0xfeb00000 Date: Wed, 17 Jun 2020 14:29:01 +0200 Message-Id: <20200617122901.13327-5-kraxel@redhat.com> In-Reply-To: <20200617122901.13327-1-kraxel@redhat.com> References: <20200617122901.13327-1-kraxel@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , "Michael S. Tsirkin" , Paul Durrant , Gerd Hoffmann , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Place virtio-mmio devices near the other mmio regions, next ioapic is at @ 0xfec00000. Signed-off-by: Gerd Hoffmann Reviewed-by: Michael S. Tsirkin Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Igor Mammedov Reviewed-by: Paul Durrant Acked-by: Paolo Bonzini Message-id: 20200529073957.8018-5-kraxel@redhat.com --- include/hw/i386/microvm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/hw/i386/microvm.h b/include/hw/i386/microvm.h index ba68d1f22bb3..fd34b78e0d2a 100644 --- a/include/hw/i386/microvm.h +++ b/include/hw/i386/microvm.h @@ -26,7 +26,7 @@ #include "hw/i386/x86.h" /* Platform virtio definitions */ -#define VIRTIO_MMIO_BASE 0xc0000000 +#define VIRTIO_MMIO_BASE 0xfeb00000 #define VIRTIO_IRQ_BASE 5 #define VIRTIO_NUM_TRANSPORTS 8 #define VIRTIO_CMDLINE_MAXLEN 64 -- 2.18.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:29:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:29:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXBt-00070b-B4; Wed, 17 Jun 2020 12:29:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXBr-00070F-W2 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:29:16 +0000 X-Inumbo-ID: 2826993a-b096-11ea-8496-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 2826993a-b096-11ea-8496-bc764e2007e4; Wed, 17 Jun 2020 12:29:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592396955; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zb2O4LSZD2edy8bGwjrUcS/0sbskbMKnSoDc3GN7pZo=; b=L2pGyrMsf3p95xbE9KH3T3jhVNMsik0HSHZuDHhONqkZhAaGQq3onZE5apd6HRpUQYfBBk 0jRoZ0aXtThVZRk0X5NeeEMvmOGsJy7hPoQDjp3/Be67nabdc06/2w9LHqOcUXTLngRgiV NwWFZlCW231584FXOvWsF7CPCAJ9upc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-164-_dMmP07cP0WQCOcEEX7-_A-1; Wed, 17 Jun 2020 08:29:13 -0400 X-MC-Unique: _dMmP07cP0WQCOcEEX7-_A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EAE79134D5; Wed, 17 Jun 2020 12:29:11 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-112-67.ams2.redhat.com [10.36.112.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5291F5D9D3; Wed, 17 Jun 2020 12:29:03 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id A32FE1750C; Wed, 17 Jun 2020 14:29:01 +0200 (CEST) From: Gerd Hoffmann To: qemu-devel@nongnu.org Subject: [PULL 1/4] microvm: use 3G split unconditionally Date: Wed, 17 Jun 2020 14:28:58 +0200 Message-Id: <20200617122901.13327-2-kraxel@redhat.com> In-Reply-To: <20200617122901.13327-1-kraxel@redhat.com> References: <20200617122901.13327-1-kraxel@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , "Michael S. Tsirkin" , Paul Durrant , Gerd Hoffmann , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Looks like the logic was copied over from q35. q35 does this for backward compatibility, there is no reason to do this on microvm though. Also microvm doesn't need much mmio space, 1G is more than enough. Using an mmio window smaller than 1G is bad for gigabyte alignment and hugepages though. So split @ 3G unconditionally. Signed-off-by: Gerd Hoffmann Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Igor Mammedov Acked-by: Paolo Bonzini Reviewed-by: Michael S. Tsirkin Message-id: 20200529073957.8018-2-kraxel@redhat.com --- hw/i386/microvm.c | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c index 937db10ae6a5..44f940813b07 100644 --- a/hw/i386/microvm.c +++ b/hw/i386/microvm.c @@ -170,23 +170,9 @@ static void microvm_memory_init(MicrovmMachineState *mms) MemoryRegion *ram_below_4g, *ram_above_4g; MemoryRegion *system_memory = get_system_memory(); FWCfgState *fw_cfg; - ram_addr_t lowmem; + ram_addr_t lowmem = 0xc0000000; /* 3G */ int i; - /* - * Check whether RAM fits below 4G (leaving 1/2 GByte for IO memory - * and 256 Mbytes for PCI Express Enhanced Configuration Access Mapping - * also known as MMCFG). - * If it doesn't, we need to split it in chunks below and above 4G. - * In any case, try to make sure that guest addresses aligned at - * 1G boundaries get mapped to host addresses aligned at 1G boundaries. - */ - if (machine->ram_size >= 0xb0000000) { - lowmem = 0x80000000; - } else { - lowmem = 0xb0000000; - } - /* * Handle the machine opt max-ram-below-4g. It is basically doing * min(qemu limit, user limit). -- 2.18.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:29:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:29:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXBx-00071x-KS; Wed, 17 Jun 2020 12:29:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXBw-00070A-8l for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:29:20 +0000 X-Inumbo-ID: 2990f3a7-b096-11ea-b9d6-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 2990f3a7-b096-11ea-b9d6-12813bfff9fa; Wed, 17 Jun 2020 12:29:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592396957; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7m5RRVrZvMI+hYy8ktqweMxRA2Yf3dzvRQTzQqdINX4=; b=fXfNxl0O8/tOFbMGgTgfqOfHgRIvIaQg9GkDwFDWiAXVHs0tTUvaHIapS6x6KKqgSMTAro RZscUHWJ+eDa+LG8p45/ZqUiI2Md7oH4MUem81rZm313/Cc997HFswusTdS1I0m36LLxVA nxfP6NfWBaOToW1303eIx/qNynUlyYc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-387-sth5Ug6LM0eMfV0zwjpDBA-1; Wed, 17 Jun 2020 08:29:13 -0400 X-MC-Unique: sth5Ug6LM0eMfV0zwjpDBA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3E57E188362E; Wed, 17 Jun 2020 12:29:12 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-112-67.ams2.redhat.com [10.36.112.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 50D7C7BA19; Wed, 17 Jun 2020 12:29:03 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id BEC2A1753D; Wed, 17 Jun 2020 14:29:01 +0200 (CEST) From: Gerd Hoffmann To: qemu-devel@nongnu.org Subject: [PULL 3/4] x86: move max-ram-below-4g to pc Date: Wed, 17 Jun 2020 14:29:00 +0200 Message-Id: <20200617122901.13327-4-kraxel@redhat.com> In-Reply-To: <20200617122901.13327-1-kraxel@redhat.com> References: <20200617122901.13327-1-kraxel@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , "Michael S. Tsirkin" , Paul Durrant , Gerd Hoffmann , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Move from X86MachineClass to PCMachineClass so it disappears from microvm machine type property list. Signed-off-by: Gerd Hoffmann Reviewed-by: Philippe Mathieu-Daudé Acked-by: Paolo Bonzini Reviewed-by: Michael S. Tsirkin Reviewed-by: Igor Mammedov Reviewed-by: Paul Durrant Message-id: 20200529073957.8018-4-kraxel@redhat.com --- include/hw/i386/pc.h | 2 ++ include/hw/i386/x86.h | 4 ---- hw/i386/pc.c | 46 +++++++++++++++++++++++++++++++++++++++++++ hw/i386/pc_piix.c | 10 +++++----- hw/i386/pc_q35.c | 10 +++++----- hw/i386/x86.c | 46 ------------------------------------------- hw/i386/xen/xen-hvm.c | 2 +- 7 files changed, 59 insertions(+), 61 deletions(-) diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h index 8d764f965cd3..e6135c34d656 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -35,6 +35,7 @@ struct PCMachineState { PFlashCFI01 *flash[2]; /* Configuration options: */ + uint64_t max_ram_below_4g; OnOffAuto vmport; bool acpi_build_enabled; @@ -51,6 +52,7 @@ struct PCMachineState { }; #define PC_MACHINE_ACPI_DEVICE_PROP "acpi-device" +#define PC_MACHINE_MAX_RAM_BELOW_4G "max-ram-below-4g" #define PC_MACHINE_DEVMEM_REGION_SIZE "device-memory-region-size" #define PC_MACHINE_VMPORT "vmport" #define PC_MACHINE_SMBUS "smbus" diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h index b52285481687..b79f24e28545 100644 --- a/include/hw/i386/x86.h +++ b/include/hw/i386/x86.h @@ -51,9 +51,6 @@ typedef struct { qemu_irq *gsi; GMappedFile *initrd_mapped_file; - /* Configuration options: */ - uint64_t max_ram_below_4g; - /* RAM information (sizes, addresses, configuration): */ ram_addr_t below_4g_mem_size, above_4g_mem_size; @@ -82,7 +79,6 @@ typedef struct { AddressSpace *ioapic_as; } X86MachineState; -#define X86_MACHINE_MAX_RAM_BELOW_4G "max-ram-below-4g" #define X86_MACHINE_SMM "smm" #define X86_MACHINE_ACPI "acpi" diff --git a/hw/i386/pc.c b/hw/i386/pc.c index ec39741c87ac..d103b8c0ab82 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1857,6 +1857,45 @@ static void pc_machine_set_pit(Object *obj, bool value, Error **errp) pcms->pit_enabled = value; } +static void pc_machine_get_max_ram_below_4g(Object *obj, Visitor *v, + const char *name, void *opaque, + Error **errp) +{ + PCMachineState *pcms = PC_MACHINE(obj); + uint64_t value = pcms->max_ram_below_4g; + + visit_type_size(v, name, &value, errp); +} + +static void pc_machine_set_max_ram_below_4g(Object *obj, Visitor *v, + const char *name, void *opaque, + Error **errp) +{ + PCMachineState *pcms = PC_MACHINE(obj); + Error *error = NULL; + uint64_t value; + + visit_type_size(v, name, &value, &error); + if (error) { + error_propagate(errp, error); + return; + } + if (value > 4 * GiB) { + error_setg(&error, + "Machine option 'max-ram-below-4g=%"PRIu64 + "' expects size less than or equal to 4G", value); + error_propagate(errp, error); + return; + } + + if (value < 1 * MiB) { + warn_report("Only %" PRIu64 " bytes of RAM below the 4GiB boundary," + "BIOS may not work with less than 1MiB", value); + } + + pcms->max_ram_below_4g = value; +} + static void pc_machine_initfn(Object *obj) { PCMachineState *pcms = PC_MACHINE(obj); @@ -1866,6 +1905,7 @@ static void pc_machine_initfn(Object *obj) #else pcms->vmport = ON_OFF_AUTO_OFF; #endif /* CONFIG_VMPORT */ + pcms->max_ram_below_4g = 0; /* use default */ /* acpi build is enabled by default if machine supports it */ pcms->acpi_build_enabled = PC_MACHINE_GET_CLASS(pcms)->has_acpi_build; pcms->smbus_enabled = true; @@ -1964,6 +2004,12 @@ static void pc_machine_class_init(ObjectClass *oc, void *data) mc->numa_mem_supported = true; mc->default_ram_id = "pc.ram"; + object_class_property_add(oc, PC_MACHINE_MAX_RAM_BELOW_4G, "size", + pc_machine_get_max_ram_below_4g, pc_machine_set_max_ram_below_4g, + NULL, NULL); + object_class_property_set_description(oc, PC_MACHINE_MAX_RAM_BELOW_4G, + "Maximum ram below the 4G boundary (32bit boundary)"); + object_class_property_add(oc, PC_MACHINE_DEVMEM_REGION_SIZE, "int", pc_machine_get_device_memory_region_size, NULL, NULL, NULL); diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 054d3aa9f7ae..1497d0e4ae94 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -129,11 +129,11 @@ static void pc_init1(MachineState *machine, if (xen_enabled()) { xen_hvm_init(pcms, &ram_memory); } else { - if (!x86ms->max_ram_below_4g) { - x86ms->max_ram_below_4g = 0xe0000000; /* default: 3.5G */ + if (!pcms->max_ram_below_4g) { + pcms->max_ram_below_4g = 0xe0000000; /* default: 3.5G */ } - lowmem = x86ms->max_ram_below_4g; - if (machine->ram_size >= x86ms->max_ram_below_4g) { + lowmem = pcms->max_ram_below_4g; + if (machine->ram_size >= pcms->max_ram_below_4g) { if (pcmc->gigabyte_align) { if (lowmem > 0xc0000000) { lowmem = 0xc0000000; @@ -142,7 +142,7 @@ static void pc_init1(MachineState *machine, warn_report("Large machine and max_ram_below_4g " "(%" PRIu64 ") not a multiple of 1G; " "possible bad performance.", - x86ms->max_ram_below_4g); + pcms->max_ram_below_4g); } } } diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c index 18d2fad9c513..46cd06524c68 100644 --- a/hw/i386/pc_q35.c +++ b/hw/i386/pc_q35.c @@ -156,18 +156,18 @@ static void pc_q35_init(MachineState *machine) /* Handle the machine opt max-ram-below-4g. It is basically doing * min(qemu limit, user limit). */ - if (!x86ms->max_ram_below_4g) { - x86ms->max_ram_below_4g = 4 * GiB; + if (!pcms->max_ram_below_4g) { + pcms->max_ram_below_4g = 4 * GiB; } - if (lowmem > x86ms->max_ram_below_4g) { - lowmem = x86ms->max_ram_below_4g; + if (lowmem > pcms->max_ram_below_4g) { + lowmem = pcms->max_ram_below_4g; if (machine->ram_size - lowmem > lowmem && lowmem & (1 * GiB - 1)) { warn_report("There is possibly poor performance as the ram size " " (0x%" PRIx64 ") is more then twice the size of" " max-ram-below-4g (%"PRIu64") and" " max-ram-below-4g is not a multiple of 1G.", - (uint64_t)machine->ram_size, x86ms->max_ram_below_4g); + (uint64_t)machine->ram_size, pcms->max_ram_below_4g); } } diff --git a/hw/i386/x86.c b/hw/i386/x86.c index bb31935f7017..34229b45c759 100644 --- a/hw/i386/x86.c +++ b/hw/i386/x86.c @@ -846,45 +846,6 @@ void x86_bios_rom_init(MemoryRegion *rom_memory, bool isapc_ram_fw) bios); } -static void x86_machine_get_max_ram_below_4g(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) -{ - X86MachineState *x86ms = X86_MACHINE(obj); - uint64_t value = x86ms->max_ram_below_4g; - - visit_type_size(v, name, &value, errp); -} - -static void x86_machine_set_max_ram_below_4g(Object *obj, Visitor *v, - const char *name, void *opaque, - Error **errp) -{ - X86MachineState *x86ms = X86_MACHINE(obj); - Error *error = NULL; - uint64_t value; - - visit_type_size(v, name, &value, &error); - if (error) { - error_propagate(errp, error); - return; - } - if (value > 4 * GiB) { - error_setg(&error, - "Machine option 'max-ram-below-4g=%"PRIu64 - "' expects size less than or equal to 4G", value); - error_propagate(errp, error); - return; - } - - if (value < 1 * MiB) { - warn_report("Only %" PRIu64 " bytes of RAM below the 4GiB boundary," - "BIOS may not work with less than 1MiB", value); - } - - x86ms->max_ram_below_4g = value; -} - bool x86_machine_is_smm_enabled(X86MachineState *x86ms) { bool smm_available = false; @@ -958,7 +919,6 @@ static void x86_machine_initfn(Object *obj) x86ms->smm = ON_OFF_AUTO_AUTO; x86ms->acpi = ON_OFF_AUTO_AUTO; - x86ms->max_ram_below_4g = 0; /* use default */ x86ms->smp_dies = 1; x86ms->apicid_from_cpu_idx = x86_apicid_from_cpu_idx; @@ -980,12 +940,6 @@ static void x86_machine_class_init(ObjectClass *oc, void *data) x86mc->save_tsc_khz = true; nc->nmi_monitor_handler = x86_nmi; - object_class_property_add(oc, X86_MACHINE_MAX_RAM_BELOW_4G, "size", - x86_machine_get_max_ram_below_4g, x86_machine_set_max_ram_below_4g, - NULL, NULL); - object_class_property_set_description(oc, X86_MACHINE_MAX_RAM_BELOW_4G, - "Maximum ram below the 4G boundary (32bit boundary)"); - object_class_property_add(oc, X86_MACHINE_SMM, "OnOffAuto", x86_machine_get_smm, x86_machine_set_smm, NULL, NULL); diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c index 628bde5fac0c..cde981bad667 100644 --- a/hw/i386/xen/xen-hvm.c +++ b/hw/i386/xen/xen-hvm.c @@ -205,7 +205,7 @@ static void xen_ram_init(PCMachineState *pcms, ram_addr_t block_len; uint64_t user_lowmem = object_property_get_uint(qdev_get_machine(), - X86_MACHINE_MAX_RAM_BELOW_4G, + PC_MACHINE_MAX_RAM_BELOW_4G, &error_abort); /* Handle the machine opt max-ram-below-4g. It is basically doing -- 2.18.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:29:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:29:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXBx-00072O-UP; Wed, 17 Jun 2020 12:29:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXBw-00070F-Tk for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:29:20 +0000 X-Inumbo-ID: 28402c42-b096-11ea-8496-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 28402c42-b096-11ea-8496-bc764e2007e4; Wed, 17 Jun 2020 12:29:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592396955; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YPFJFaMrpuHpn0jwnWZgZ+54i5WkkV9FY9G9bgKap2I=; b=ddlMiZ/4277tMrCbFJW8EiK5LL4Cuafv1OgLSBJYQcHRMArt9uNqiQLAfjk4en314a2xZk zWZ/0Cmt/G+FtnPoqSJJjCeC6WH4xZVqX4ZOnUuvTDYhclNucAFTC/LXJnWiuOVjKI0VSc IpBaddoxftIlPTW4tJPu5bvV9Ea1sjs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-427-dhvMQHhgMGCBolP3iquecA-1; Wed, 17 Jun 2020 08:29:13 -0400 X-MC-Unique: dhvMQHhgMGCBolP3iquecA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C31421009625; Wed, 17 Jun 2020 12:29:11 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-112-67.ams2.redhat.com [10.36.112.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2CA177BA14; Wed, 17 Jun 2020 12:29:03 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id AC3581753C; Wed, 17 Jun 2020 14:29:01 +0200 (CEST) From: Gerd Hoffmann To: qemu-devel@nongnu.org Subject: [PULL 2/4] microvm: drop max-ram-below-4g support Date: Wed, 17 Jun 2020 14:28:59 +0200 Message-Id: <20200617122901.13327-3-kraxel@redhat.com> In-Reply-To: <20200617122901.13327-1-kraxel@redhat.com> References: <20200617122901.13327-1-kraxel@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , "Michael S. Tsirkin" , Paul Durrant , Gerd Hoffmann , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Not useful for microvm and allows users to shoot themself into the foot (make ram + mmio overlap). Signed-off-by: Gerd Hoffmann Reviewed-by: Igor Mammedov Acked-by: Paolo Bonzini Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Michael S. Tsirkin Message-id: 20200529073957.8018-3-kraxel@redhat.com --- hw/i386/microvm.c | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c index 44f940813b07..5e931975a06d 100644 --- a/hw/i386/microvm.c +++ b/hw/i386/microvm.c @@ -173,25 +173,6 @@ static void microvm_memory_init(MicrovmMachineState *mms) ram_addr_t lowmem = 0xc0000000; /* 3G */ int i; - /* - * Handle the machine opt max-ram-below-4g. It is basically doing - * min(qemu limit, user limit). - */ - if (!x86ms->max_ram_below_4g) { - x86ms->max_ram_below_4g = 4 * GiB; - } - if (lowmem > x86ms->max_ram_below_4g) { - lowmem = x86ms->max_ram_below_4g; - if (machine->ram_size - lowmem > lowmem && - lowmem & (1 * GiB - 1)) { - warn_report("There is possibly poor performance as the ram size " - " (0x%" PRIx64 ") is more then twice the size of" - " max-ram-below-4g (%"PRIu64") and" - " max-ram-below-4g is not a multiple of 1G.", - (uint64_t)machine->ram_size, x86ms->max_ram_below_4g); - } - } - if (machine->ram_size > lowmem) { x86ms->above_4g_mem_size = machine->ram_size - lowmem; x86ms->below_4g_mem_size = lowmem; -- 2.18.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:29:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:29:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXC3-00075U-DJ; Wed, 17 Jun 2020 12:29:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXC1-00070F-U9 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:29:25 +0000 X-Inumbo-ID: 2b518610-b096-11ea-bb8b-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 2b518610-b096-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 12:29:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592396960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=njPufjQU9J06Is2FXVSy/pVf/aMSRVIW2nX5LRoWV4E=; b=HOgNyksFTYZRyaRfOK2pMNCHJgaSWp8MYQWAMCJs7kBfT8XOrKMfg0r6rerckoifQ0/m+F Nq/Pi9xYG7e4J+qpcadF/JzMBPRVBOyeBTqFRv2qsFNqEjqHQm9t0aIWprxrxENnXEEHy/ DNDWSVcoP9SW45KWPCZmWdM92i2EAgM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-266-KQmlQncdOiGFUbPBAR1Qlw-1; Wed, 17 Jun 2020 08:29:16 -0400 X-MC-Unique: KQmlQncdOiGFUbPBAR1Qlw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 75DFE100962B; Wed, 17 Jun 2020 12:29:15 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-112-67.ams2.redhat.com [10.36.112.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 09EB719D7B; Wed, 17 Jun 2020 12:29:06 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 9AC9B16E16; Wed, 17 Jun 2020 14:29:01 +0200 (CEST) From: Gerd Hoffmann To: qemu-devel@nongnu.org Subject: [PULL 0/4] Microvm 20200617 patches Date: Wed, 17 Jun 2020 14:28:57 +0200 Message-Id: <20200617122901.13327-1-kraxel@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , "Michael S. Tsirkin" , Paul Durrant , Gerd Hoffmann , Marcel Apfelbaum , Paolo Bonzini , Anthony Perard , xen-devel@lists.xenproject.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The following changes since commit 5c24bce3056ff209a1ecc50ff4b7e65b85ad8e74: Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-and-plugin-160620-2' into staging (2020-06-16 14:57:15 +0100) are available in the Git repository at: git://git.kraxel.org/qemu tags/microvm-20200617-pull-request for you to fetch changes up to c8b473594b8fbba169a6ea950493a3015d15a18d: microvm: move virtio base to 0xfeb00000 (2020-06-17 14:24:28 +0200) ---------------------------------------------------------------- microvm: memory config tweaks ---------------------------------------------------------------- Gerd Hoffmann (4): microvm: use 3G split unconditionally microvm: drop max-ram-below-4g support x86: move max-ram-below-4g to pc microvm: move virtio base to 0xfeb00000 include/hw/i386/microvm.h | 2 +- include/hw/i386/pc.h | 2 ++ include/hw/i386/x86.h | 4 ---- hw/i386/microvm.c | 35 +---------------------------- hw/i386/pc.c | 46 +++++++++++++++++++++++++++++++++++++++ hw/i386/pc_piix.c | 10 ++++----- hw/i386/pc_q35.c | 10 ++++----- hw/i386/x86.c | 46 --------------------------------------- hw/i386/xen/xen-hvm.c | 2 +- 9 files changed, 61 insertions(+), 96 deletions(-) -- 2.18.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:37:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:37:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXJg-0008Eq-7i; Wed, 17 Jun 2020 12:37:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXJf-0008El-2s for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:37:19 +0000 X-Inumbo-ID: 462fb9a7-b097-11ea-b9d9-12813bfff9fa Received: from mga01.intel.com (unknown [192.55.52.88]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 462fb9a7-b097-11ea-b9d9-12813bfff9fa; Wed, 17 Jun 2020 12:37:17 +0000 (UTC) IronPort-SDR: ks2vvZwu9VS083fy6iHS7oaBKrYrvQjSwIqJhKbeB3QIm1SWeThsFsW7nM40PAs5pAZqzQFD1z d/FV3BZikWyA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 05:37:16 -0700 IronPort-SDR: AOvhoC8mUFXcfT3wyIgHy00rdg0AdveeyuhNAbqbmEyRcB0RJKxgJJDEniP23GqTGrU8pk4YnL x4lkNqY6VfLQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,522,1583222400"; d="scan'208";a="352064235" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by orsmga001.jf.intel.com with ESMTP; 17 Jun 2020 05:37:16 -0700 Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 17 Jun 2020 05:37:15 -0700 Received: from orsmsx602.amr.corp.intel.com (10.22.229.15) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 17 Jun 2020 05:37:15 -0700 Received: from ORSEDG002.ED.cps.intel.com (10.7.248.5) by orsmsx602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 17 Jun 2020 05:37:15 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.54) by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 17 Jun 2020 05:37:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EO94mCJCZl1L+cDJUZGd0aMkxMUx8ug3lsyFlkWkitvtwlpKZ2CGWl6nZkuu6aNv1IcGd+yHg/SkK+ZDvgGhbRfWYipArI8f/Cfi3vxnmxlAnnguTGJesRPPARoCJf5fuhkC6ITj4sFpZi0gsKdTCNe+fL6q1kpXNq0het3vz657AWhOFinBMjtMVaQ0cpDmmERySWwqJkiqFX3kqW0uRqul6EkyjrbsCOA34GqA7H1nrVWN1Exg4MB0Nru66xDIOPEuetVF0ubdLCOw9O+1L9R+leKq1THo1evo3SnARndN/p+MAua8eycSU/1ZOlrrzVpVSRC+aDzEDSzGLgEBIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zAk8Rz8sLYZVur/7OUUPH1uAbQL/e5JT09fayQ4nB0Q=; b=f/fmbgvMdLYFgORlDjz60QNvHJqtdazHYzG/qIqpeOlnBqVPAOTUf/bBho0qKOb9YVojjoDbC300+MvkrzPrY6B0D5gkx4xThOR1zrqmb2X4xZClXN2FCAtGDe9dUdaNlsAUMYi7vn9vvD+yBP22kuSq/f5mzisVzYZ08GdTMVO+rRWdc1QsNc+18gVp0nEugurCx8n/9RCN9BcEDqb/sdGsejvriVaEDls5Z8vVgMjIO960Uumzz2cEVS619n0XQhK5olgsMnk38jonumeeWDNCiJ/DfXLEkXgx8i089jK0PJBYDOi8YQ23YLJgs6zOro3gTZbnQwTkBTtENbDeWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zAk8Rz8sLYZVur/7OUUPH1uAbQL/e5JT09fayQ4nB0Q=; b=K2v6XnyOGXAtuZHIhNthE8m6g7XQZ8n5NpaxlMoq+chfWaxBBCLkGXXJATailXd3IZ2KSeEWPdWMpxU49nzq6qVgKNum/pLlmAXlesqzPcgbOAH3GXAqSsB0zfkjPNoglEBIrX4lIU7/eG2uHdZNbFwxXsQ8ViG8hZMCo2xnoqo= Received: from DM5PR1101MB2266.namprd11.prod.outlook.com (2603:10b6:4:57::17) by DM5PR11MB1306.namprd11.prod.outlook.com (2603:10b6:3:b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Wed, 17 Jun 2020 12:37:13 +0000 Received: from DM5PR1101MB2266.namprd11.prod.outlook.com ([fe80::b07e:e40:d34e:b601]) by DM5PR1101MB2266.namprd11.prod.outlook.com ([fe80::b07e:e40:d34e:b601%6]) with mapi id 15.20.3109.021; Wed, 17 Jun 2020 12:37:13 +0000 From: "Kang, Luwei" To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH v1 0/7] Implement support for external IPT monitoring Thread-Topic: [PATCH v1 0/7] Implement support for external IPT monitoring Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hpiVzvKAgAAIowCAAHHNAIAAVp/wgAArhICAADbMIA== Date: Wed, 17 Jun 2020 12:37:13 +0000 Message-ID: References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <20200617092103.GZ735@Air-de-Roger> In-Reply-To: <20200617092103.GZ735@Air-de-Roger> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b06be3b8-b3fb-4bf6-2444-08d812bb295b x-ms-traffictypediagnostic: DM5PR11MB1306: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04371797A5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EHDF7Fl+LS8W+08IRUqnNYH77Lt1V4KU3GS304K0fvQITCnC06V0s7/rd1f7Gpn3bJbKIbxIJpMfzwrhXJqksduBHlgBhHo3YFFPkhzasgfdqa01twQofptP8RqvqV6oOkgKe7N2mlBDjvprDKWrXAVjPFMi0J3aaI8JjA3qVH35OF+2PGWeRbPfIvVx2CdkGui3WJAv0avOBiqKNugyEdPZvdEk1hCQVbHENIZxO/J8YWKZvbvCQpwqLWq0nVpV/q6nC8ghBEmR/JlvJ5CufdSqbGq4bB6H7ObeqLJXWgY6rslKT5CZDlCX9ZXU8q1L x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR1101MB2266.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(396003)(366004)(136003)(86362001)(66946007)(33656002)(26005)(186003)(8676002)(8936002)(53546011)(6916009)(4326008)(64756008)(6506007)(66574015)(52536014)(76116006)(66556008)(5660300002)(66446008)(66476007)(7696005)(54906003)(55016002)(71200400001)(7416002)(316002)(2906002)(9686003)(83380400001)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Y8/pmqf+THYt8oAwDVCu1BHSMJbkhRIVbGF3fdMYOXB+HteHVFfxJsvWc4eHwNGwzTxpqLHqnREZRLrTWj2/L6NxodyZeiGTCiBldbqs8IwSyEdyiTk+uL80aCGxoAX2Gtx41b1R1u6rerdYiogZPrXSXCNDjsAeH4TCbIonvHYEF0UhJ8SKEjxcF/bBaqa0zKJcXbhs0mBwZypPD+F1ztPkFPLpWEqwDHpaauQEyEAWuZjs38bIStzxo5c91JXBQOy3hS6AmZEjwoqvMkdnjYv+OBxZp+j6ydnYhk2U/5Mb4ImXHO+47xq3/vwTPWWRtHGQb5y19odz0qKECXtJTAUbAxwGJQYqXTzI3do/ZhLFyzFXnX9ZtAcMoXY+8M/pHAxWRoC0f+eZs/t2kptilpt+B5jBbCOq1YM4xWfX7abS2wz09RWtWDQV0ftICkPJt/dgGe6QG7dBaPybCSPnMb0NV5uHqssfHK3YF29sVMQSfxLRBE3TAriPio277xyZ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b06be3b8-b3fb-4bf6-2444-08d812bb295b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 12:37:13.3049 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BsazTXPVYbU5ZQZO7AaIwXnw40MZz1V4pUabIRquGCC6ZpZ2gByD4oFbb7oMhGXHZDo/FhNAwBkbG33QSFI1UA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1306 X-OriginatorOrg: intel.com X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Tian, Kevin" , Stefano Stabellini , Julien Grall , "Nakajima, Jun" , Wei Liu , Andrew Cooper , =?utf-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFRpYW4sIEtldmlu IDxrZXZpbi50aWFuQGludGVsLmNvbT4NCj4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAxNywg MjAyMCA5OjM1IEFNDQo+ID4gPiBUbzogTWljaGHFgiBMZXN6Y3p5xYRza2kgPG1pY2hhbC5sZXN6 Y3p5bnNraUBjZXJ0LnBsPjsgQW5kcmV3IENvb3Blcg0KPiA+ID4gPGFuZHJldy5jb29wZXIzQGNp dHJpeC5jb20+DQo+ID4gPiBDYzogWGVuLWRldmVsIDx4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVj dC5vcmc+OyBKYW4gQmV1bGljaA0KPiA+ID4gPGpiZXVsaWNoQHN1c2UuY29tPjsgV2VpIExpdSA8 d2xAeGVuLm9yZz47IFJvZ2VyIFBhdSBNb25uw6kNCj4gPiA+IDxyb2dlci5wYXVAY2l0cml4LmNv bT47IE5ha2FqaW1hLCBKdW4gPGp1bi5uYWthamltYUBpbnRlbC5jb20+Ow0KPiA+ID4gR2Vvcmdl IER1bmxhcCA8Z2VvcmdlLmR1bmxhcEBjaXRyaXguY29tPjsgSWFuIEphY2tzb24NCj4gPiA+IDxp YW4uamFja3NvbkBldS5jaXRyaXguY29tPjsgSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47 IFN0ZWZhbm8NCj4gPiA+IFN0YWJlbGxpbmkgPHNzdGFiZWxsaW5pQGtlcm5lbC5vcmc+OyBLYW5n LCBMdXdlaQ0KPiA+ID4gPGx1d2VpLmthbmdAaW50ZWwuY29tPg0KPiA+ID4gU3ViamVjdDogUkU6 IFtQQVRDSCB2MSAwLzddIEltcGxlbWVudCBzdXBwb3J0IGZvciBleHRlcm5hbCBJUFQNCj4gPiA+ IG1vbml0b3JpbmcNCj4gPiA+DQo+ID4gPiArTHV3ZWksIHdobyBkZXZlbG9wZWQgUFQgZm9yIEtW TSBhbmQgaXMgdGhlIGJlc3Qgb25lIHdobyBjYW4gaGVscA0KPiA+ID4gcmV2aWV3IFZNWCBjaGFu Z2VzIGZyb20gSW50ZWwgc2lkZS4gUGxlYXNlIGluY2x1ZGUgaGltIGluIGZ1dHVyZQ0KPiA+ID4g cG9zdCBvciBkaXNjdXNzaW9uLg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiA+ID4gRnJvbTogTWljaGHFgiBMZXN6Y3p5xYRza2kgPG1pY2hhbC5sZXN6Y3p5 bnNraUBjZXJ0LnBsPg0KPiA+ID4gPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMTcsIDIwMjAgMjo0 OCBBTQ0KPiA+ID4gPiBUbzogQW5kcmV3IENvb3BlciA8YW5kcmV3LmNvb3BlcjNAY2l0cml4LmNv bT4NCj4gPiA+ID4gQ2M6IFhlbi1kZXZlbCA8eGVuLWRldmVsQGxpc3RzLnhlbnByb2plY3Qub3Jn PjsgSmFuIEJldWxpY2gNCj4gPiA+ID4gPGpiZXVsaWNoQHN1c2UuY29tPjsgV2VpIExpdSA8d2xA eGVuLm9yZz47IFJvZ2VyIFBhdSBNb25uw6kNCj4gPiA+ID4gPHJvZ2VyLnBhdUBjaXRyaXguY29t PjsgTmFrYWppbWEsIEp1biA8anVuLm5ha2FqaW1hQGludGVsLmNvbT47DQo+ID4gPiA+IFRpYW4s IEtldmluIDxrZXZpbi50aWFuQGludGVsLmNvbT47IEdlb3JnZSBEdW5sYXANCj4gPiA+ID4gPGdl b3JnZS5kdW5sYXBAY2l0cml4LmNvbT47IElhbiBKYWNrc29uDQo+ID4gPiA+IDxpYW4uamFja3Nv bkBldS5jaXRyaXguY29tPjsgSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47DQo+ID4gPiA+ IFN0ZWZhbm8gU3RhYmVsbGluaSA8c3N0YWJlbGxpbmlAa2VybmVsLm9yZz4NCj4gPiA+ID4gU3Vi amVjdDogUmU6IFtQQVRDSCB2MSAwLzddIEltcGxlbWVudCBzdXBwb3J0IGZvciBleHRlcm5hbCBJ UFQNCj4gPiA+ID4gbW9uaXRvcmluZw0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLSAxNiBjemUgMjAy MCBvIDIwOjE3LCBBbmRyZXcgQ29vcGVyIGFuZHJldy5jb29wZXIzQGNpdHJpeC5jb20NCj4gPiA+ ID4gbmFwaXNhxYIoYSk6DQo+ID4gPiA+DQo+ID4gPiA+ID4gT24gMTYvMDYvMjAyMCAxNjoxNiwg TWljaGHFgiBMZXN6Y3p5xYRza2kgd3JvdGU6DQo+ID4gPiA+ID4gV2hlbiB0aGlzIHN1YmplY3Qg d2FzIGJyb2FjaGVkIG9uIHhlbi1kZXZlbCBiZWZvcmUsIG9uZSBpc3N1ZQ0KPiA+ID4gPiA+IHdh cyB0aGUgZmFjdCB0aGF0IGFsbCBhY3Rpb25zIHdoaWNoIGFyZSBpbnRlcmNlcHRlZCBkb24ndCBl bmQgdXANCj4gPiA+ID4gPiB3cml0aW5nIGFueSBhcHByb3ByaWF0ZSBwYWNrZXRzLsKgIFRoaXMg aXMgcGVyaGFwcyBsZXNzIG9mIGFuDQo+ID4gPiA+ID4gaXNzdWUgZm9yIHRoaXMgZXhhbXBsZSwg d2hlcmUgdGhlIGV4dGVybmFsIGFnZW50IGNhbiBzZWUgVk1FeGl0cw0KPiA+ID4gPiA+IGluIHRo ZSB0cmFjZSwgYnV0IGl0IHN0aWxsIHJlc3VsdHMgaW4gbWlzc2luZyBpbmZvcm1hdGlvbi7CoCAo SXQNCj4gPiA+ID4gPiBpcyBhIG1ham9yIHByb2JsZW0gZm9yIFBUIHdpdGhpbiB0aGUgZ3Vlc3Qs IGFuZCBuZWVkcyBYZW4ncw0KPiA+ID4gPiA+IGludGVyY2VwdC9lbXVsYXRpb24gZnJhbWV3b3Jr IGJlaW5nIHVwZGF0ZWQgdG8gYmUgUFQtYXdhcmUgc28gaXQNCj4gPiA+ID4gPiBjYW4gZmlsbCBp biB0aGUgc2FtZSBwYWNrZXRzIHdoaWNoIGhhcmR3YXJlIHdvdWxkIGhhdmUgZG9uZSBmb3INCj4g PiA+ID4gPiBlcXVpdmFsZW50IGFjdGlvbnMuKQ0KPiA+ID4gPg0KPiA+ID4gPiBPaywgdGhpcyBz b3VuZHMgbGlrZSBhIGhhcmQgaXNzdWUuIENvdWxkIHlvdSBwb2ludCBvdXQgd2hhdCBjb3VsZA0K PiA+ID4gPiBiZSB0aGUgcGFydGljdWxhciBwcm9ibGVtYXRpYyBjYXNlcz8gRm9yIGluc3RhbmNl LCBpZiBzb21ldGhpbmcNCj4gPiA+ID4gd291bGQgYWx0ZXIgRUlQL1JJUCBvciBDUjMgdGhlbiBJ IGJlbGl2ZSBpdCB3b3VsZCBzdGlsbCBiZQ0KPiA+ID4gPiByZWNvcmRlZCBpbiBQVCB0cmFjZSAo aS5lLiB0aGVzZSB2YWx1ZXMgd2lsbCBiZSBsb2dnZWQgb24gVk0gZW50cnkpLg0KPiA+DQo+ID4g ZS5nLiBJZiBhIFZNIGV4aXQgaXMgdGFrZW4gb24gYSBndWVzdCB3cml0ZSB0byBDUjMgKGluY2x1 ZGluZyDigJxNT1YNCj4gPiBDUjPigJ0gYXMgd2VsbCBhcyB0YXNrIHN3aXRjaGVzKSwgdGhlIFBJ UCBwYWNrZXQgbm9ybWFsbHkgZ2VuZXJhdGVkIG9uIHRoZSBDUjMNCj4gd3JpdGUgd2lsbCBiZSBt aXNzaW5nLiBUaGUgUElQIHBhY2tldCBuZWVkcyB0byBiZSB3cml0dGVuIHRvIHRoZSBQVCBidWZm ZXIgYnkNCj4gc29mdHdhcmUuIEFub3RoZXIgZXhhbXBsZSBpcyBWTS1leGl0IHRha2VuIG9uIFJE VFNDLg0KPiA+DQo+ID4gRm9yIFZNIGludHJvc3BlY3Rpb24sIGFsbCB0aGUgSW50ZWwgUFQgcGFj a2V0cyBtYXkgbmVlZCB0byBlbXVsYXRlZCBieQ0KPiBzb2Z0d2FyZS4gU29tZSBkZXNjcmlwdGlv biBpbiBTRE0gYXMgYmVsb3c6DQo+ID4gSWYgYSBWTU0gZW11bGF0ZXMgYW4gZWxlbWVudCBvZiBw cm9jZXNzb3Igc3RhdGUgYnkgdGFraW5nIGEgVk0gZXhpdCBvbg0KPiByZWFkcyBhbmQvb3Igd3Jp dGVzIHRvIHRoYXQgcGllY2Ugb2Ygc3RhdGUsIGFuZCB0aGUgc3RhdGUgZWxlbWVudCBpbXBhY3Rz IEludGVsDQo+IFBUIHBhY2tldCBnZW5lcmF0aW9uIG9yIHZhbHVlcywgaXQgbWF5IGJlIGluY3Vt YmVudCB1cG9uIHRoZSBWTU0gdG8gaW5zZXJ0DQo+IG9yIG1vZGlmeSB0aGUgb3V0cHV0IHRyYWNl IGRhdGEuDQo+IA0KPiBJIGdvdCB0aGUgaW1wcmVzc2lvbiB0aGF0IElQVCB3YXMgbW9zdGx5IHVz ZWZ1bCB0b2dldGhlciB3aXRoIGludHJvc3BlY3Rpb24sIGFzDQo+IHlvdSBjYW4gdGhlbiBnZXQg ZXZlbnRzIGZyb20gdHJhcHBlZCBpbnN0cnVjdGlvbnMgKGFuZCBsaWtlbHkgZW11bGF0ZWQpIGZy b20NCj4gdGhlIGludHJvc3BlY3Rpb24gaW50ZXJmYWNlLCB3aGlsZSBiZWluZyBhYmxlIHRvIGdl dCB0aGUgcHJvY2Vzc29yIHRyYWNlIGZvciBub24tDQo+IHRyYXBwZWQgZXZlbnRzLg0KPiANCj4g SSdtIG5vdCBzdXJlIHdoZXRoZXIgdGhlcmUgd291bGQgYmUgY29ybmVyIGNhc2VzIHdpdGggdHJh cHBlZCBpbnN0cnVjdGlvbnMNCj4gbm90IGJlaW5nIGhhbmRsZWQgYnkgdGhlIGludHJvc3BlY3Rp b24gZnJhbWV3b3JrLg0KPiANCj4gSG93IGRvZXMgS1ZNIGRlYWwgd2l0aCB0aGlzLCBkbyB0aGV5 IGluc2VydC9tb2RpZnkgdHJhY2UgcGFja2V0cyBvbiB0cmFwcGVkDQo+IGFuZCBlbXVsYXRlZCBp bnN0cnVjdGlvbnMgYnkgdGhlIFZNTT8NCg0KVGhlIEtWTSBpbmNsdWRlcyBpbnN0cnVjdGlvbiBk ZWNvZGVyIGFuZCBlbXVsYXRvcihhcmNoL3g4Ni9rdm0vZW11bGF0ZS5jKSwgYW5kIHRoZSBndWVz dCdzIG1lbW9yeSBjYW4gYmUgc2V0IHRvIHdyaXRlLXByb3RlY3QgYXMgd2VsbC4gQnV0IGl0IGRv ZXNuJ3Qgc3VwcG9ydCBJbnRlbCBQVCBwYWNrZXRzIHNvZnR3YXJlIGVtdWxhdG9yLiBGb3IgS1ZN LCB0aGUgSW50ZWwgUFQgZmVhdHVyZSB3aWxsIGJlIGV4cG9zZWQgdG8gS1ZNIGd1ZXN0IGFuZCBL Vk0gZ3Vlc3QgY2FuIHVzZSBJbnRlbCBQVCBmZWF0dXJlIGxpa2UgbmF0aXZlLg0KDQpUaGFua3Ms DQpMdXdlaSBLYW5nDQo= From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:44:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:44:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXQp-0000eR-2C; Wed, 17 Jun 2020 12:44:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXQo-0000eM-Qa for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:44:42 +0000 X-Inumbo-ID: 4ffa9568-b098-11ea-bb8b-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 4ffa9568-b098-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 12:44:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592397881; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wcOIvyOd7fQsYITZLOHJF2/UCRXJ2YKpaTOVPdzzZqc=; b=jDNAm8tu/HCxKuK6WpzehvwWr1Yf0d2flT/t2M+wr6tWiclllBy6uaVOzUf7NcxCcgPQbt KkgH39pfArL3B2SqLC0n+ZqA2QcpZ5zpGygaQsYVw82zKjxRld/zHbPPVuBSsFqB0oMM6e csiCmcOSqlD7soxRSpb+yYeALmihTNo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-115-rLJKltAtNA2KoiIUcSKVgA-1; Wed, 17 Jun 2020 08:44:33 -0400 X-MC-Unique: rLJKltAtNA2KoiIUcSKVgA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2B72181EE33; Wed, 17 Jun 2020 12:44:32 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-92.ams2.redhat.com [10.36.115.92]) by smtp.corp.redhat.com (Postfix) with ESMTP id EB80A89261; Wed, 17 Jun 2020 12:44:29 +0000 (UTC) Subject: Re: [PATCH] OvmfPkg: End timer interrupt later to avoid stack overflow under load To: Igor Druzhinin , devel@edk2.groups.io, xen-devel References: <1592275782-9369-1-git-send-email-igor.druzhinin@citrix.com> <17ee2671-c44b-f3fb-43af-0a75f7d161fc@citrix.com> From: Laszlo Ersek Message-ID: <020a65b1-7923-e8d6-dd11-9325ee4e70c7@redhat.com> Date: Wed, 17 Jun 2020 14:44:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <17ee2671-c44b-f3fb-43af-0a75f7d161fc@citrix.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: julien@xen.org, jordan.l.justen@intel.com, Ray Ni , ard.biesheuvel@arm.com, anthony.perard@citrix.com, Paolo Bonzini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 06/17/20 05:16, Igor Druzhinin wrote: > On 16/06/2020 19:42, Laszlo Ersek wrote >> If I understand correctly, TimerInterruptHandler() >> [OvmfPkg/8254TimerDxe/Timer.c] currently does the following: >> >> - RaiseTPL (TPL_HIGH_LEVEL) --> mask interrupts from being delivered >> >> - mLegacy8259->EndOfInterrupt() --> permit the PIC to generate further >> interrupts (= make them pending) >> >> - RestoreTPL() --> unmask interrupts (allow delivery) >> >> RestoreTPL() is always expected to invoke handlers (on its own stack) >> that have just been unmasked, so that behavior is not unexpected, in my >> opinion. > > Yes, this is where I'd like to have a confirmation - opening a window > for uncontrollable number of nested interrupts with a small stack > looks dangerous. Sorry, I meant the above more generally. The sentence RestoreTPL() is always expected to invoke handlers (on its own stack) that have just been unmasked doesn't only refer to actual timer hardware interrupts (in connection to TPL_HGIH_LEVEL), but also to invoking event notification functions that have been queued while running at the raised TPL. Quoting "EFI_BOOT_SERVICES.CreateEvent()" from the spec: Events exist in one of two states, “waiting” or “signaled.” When an event is created, firmware puts it in the “waiting” state. When the event is signaled, firmware changes its state to “signaled” and, if EVT_NOTIFY_SIGNAL is specified, places a call to its notification function in a FIFO queue. There is a queue for each of the “basic” task priority levels defined in Section 7.1 (TPL_CALLBACK, and TPL_NOTIFY). The functions in these queues are invoked in FIFO order, starting with the highest priority level queue and proceeding to the lowest priority queue that is unmasked by the current TPL. If the current TPL is equal to or greater than the queued notification, it will wait until the TPL is lowered via EFI_BOOT_SERVICES.RestoreTPL(). In practice, when the event is signaled, and the current TPL is not masking the TPL of the associated notify function, then the notify function is called internally to signaling the event. Otherwise, if the unmasking occurs via RestoreTPL(), then the queued notification functions are invoked on the stack of RestoreTPL() -- in other words, internally to the RestoreTPL() function call itself. So all I meant was that notification functions running internally to RestoreTPL() was by design. What's unexpected is the "uncontrollable number" of nested interrupts. > >> What seems unexpected is the queueing of a huge number of timer >> interrupts. I would think a timer interrupt is either pending or not >> pending (i.e. if it's already pending, then the next generated interrupt >> is coalesced, not queued). While there would still be a window between >> the EOI and the unmasking, I don't think it would normally allow for a >> *huge* number of queued interrupts (and consequently a stack overflow). > > It's not a window between EOI and unmasking but the very fact vCPU is > descheduled for a considerable amount of time that causes backlog of > timer interrupts to build up. This is Xen default behavior and is > configurable (there are several timer modes including coalescing > you mention). That is done for compatibility with some guests basing > time accounting on the number of periodic interrupts they receive. OK, thanks for explaining. > >> So I basically see the root of the problem in the interrupts being >> queued rather than coalesced. I'm pretty unfamiliar with this x86 area >> (= the 8259 PIC in general), but the following wiki article seems to >> agree with my suspicion: >> >> https://wiki.osdev.org/8259_PIC#How_does_the_8259_PIC_chip_work.3F >> >> [...] and whether there's an interrupt already pending. If the >> channel is unmasked and there's no interrupt pending, the PIC will >> raise the interrupt line [...] >> >> Can we say that the interrupt queueing (as opposed to coalescing) is a >> Xen issue? > > I can admit that the whole issue might be Xen specific if that form > of timer mode is not used in QEMU-KVM. What mode is typical there > then? That question is too difficult for me to answer :( > We might consider switching Xen to a different mode if so, as I believe > those guests are not in support for many years. Can you perhaps test this hypothesis? If you select the coalescing timer mode for the Xen guest in question, does the symptom go away? > >> (Hmmm... maybe the hypervisor *has* to queue the timer interrupts, >> otherwise some of them would simply be lost, and the guest would lose >> track of time.) >> >> Either way, I'm not sure what the best approach is. This driver was >> moved under OvmfPkg from PcAtChipsetPkg in commit 1a3ffdff82e6 >> ("OvmfPkg: Copy 8254TimerDxe driver from PcAtChipsetPkg", 2019-04-11). >> HpetTimerDxe also lives under PcAtChipsetPkg. >> >> So I think I'll have to rely on the expertise of Ray here (CC'd). > > Also note that since the issue might be Xen specific we might want to > try to fix it in XenTimer only - I modified 8254Timer due to the > fact Xen is still present in general config (but that should soon > go away). We could also modify 8254TimerDxe like this: - provide the new variant of the TimerInterruptHandler() function for Xen only, without touching the existent one -- simply introduce it as a new function, - in TimerDriverInitialize(), first call XenDetected() from XenPlatformLib, then choose the argument for the mCpu->RegisterInterruptHandler() call accordingly. This wouldn't be difficult to locate and revert when is addressed. (It would be easy to find by grepping for XenDetected().) [...] Thanks! Laszlo From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:46:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:46:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXSb-0000kf-EK; Wed, 17 Jun 2020 12:46:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXSa-0000ka-Lm for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:46:32 +0000 X-Inumbo-ID: 91c2a95e-b098-11ea-8496-bc764e2007e4 Received: from mail-ej1-x630.google.com (unknown [2a00:1450:4864:20::630]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 91c2a95e-b098-11ea-8496-bc764e2007e4; Wed, 17 Jun 2020 12:46:32 +0000 (UTC) Received: by mail-ej1-x630.google.com with SMTP id l27so2195223ejc.1 for ; Wed, 17 Jun 2020 05:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Sa5cuZtygHc8w7ntdXyCnAw36f3tKmdYWqElsxtulRk=; b=XYuQV9+1bEsNnaKTIpBazrdOu/s2VxvgHmxser9bqjMF++JeaXTr/0gpGu/0Jypvwm 46l1kVgV1UL9AA9JawiMH7d9C/5FJeofRCTcdscnI3rLWHFbrVV+6kbsUH/Sj7LIN2s+ G/zdc1x7Uqi9jw7v/MqepyG4/CyLTV5jyVXs4Sj5wLtd9rZyaO79M2OqFcsJ90AKblkN tAjp4Gelnt5YnUN20nhQeQ4clWqhnBjY6gdHstGKc5Z946S7J+gOw+dBS8RzpNNNhT1h 3G/I2/zUSqNBLwHtmLVbMPeOS871MmgR0cccgCwd37MLbgk1WDWkFfUnQ9dGEVGWZyxT 2g3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=Sa5cuZtygHc8w7ntdXyCnAw36f3tKmdYWqElsxtulRk=; b=lH0g2GOsyYREcOaQm2mUth7tmVNQteq14cEk/Z1e4Q3JWSkHCaimP0//2PlQRe8vf+ DLYkPWbYa/T3GH7Zi/iFAg3Ya0hHcwlqD/3/aMhQG0CJL+CTAJAgWaRciBuG8B4theEp DSQMfXKlBwuDiW9LI2lxVzDnlxUhpkZY+byW0yQ6R5vI91rV2QeVfb1fX5tCM/cG2teJ uGKAO26WsU8bphhLRx4Ww3f967Uyg6OTQ0deI/YWxTgWEtc8KF8l5AksFst16W9hdp91 xABS5sLzfp4i3WNOPMsMAonWAyGk64351z3dWwiL1SOmsKg3DKG/FnWPqjvPLQy06hL/ /7TA== X-Gm-Message-State: AOAM531g51IrKhVI6usklfS7JcWZvtmazGaH+1swPYKvAuR2LmoOOm0g ap3U/sUcC4NpGbA2dyymj8c= X-Google-Smtp-Source: ABdhPJwPhhzlBoZBbIky3xJy9D56Co3Wqz3Aenz2eKdcRToUGQK2AHxnLc9BT4DUNODipsaBi4cEeQ== X-Received: by 2002:a17:906:9381:: with SMTP id l1mr7604021ejx.380.1592397991140; Wed, 17 Jun 2020 05:46:31 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id d6sm12210552edn.75.2020.06.17.05.46.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jun 2020 05:46:30 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: , "'Andrew Cooper'" , "'Xen-devel'" References: <20200615141532.1927-1-andrew.cooper3@citrix.com> <003101d64337$06b202c0$14160840$@xen.org> In-Reply-To: <003101d64337$06b202c0$14160840$@xen.org> Subject: RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge Date: Wed, 17 Jun 2020 13:46:28 +0100 Message-ID: <005f01d644a5$52dd8470$f8988d50$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQBu9n1OIN1/SF0JEfFzSQwAilcbPAFLsmhVq6D/2CA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Ian Jackson' , 'Jan Beulich' , 'Wei Liu' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Paul Durrant > Sent: 15 June 2020 18:04 > To: 'Andrew Cooper' ; 'Xen-devel' = > Cc: 'Wei Liu' ; 'Jan Beulich' ; 'Ian = Jackson' ; > 'Roger Pau Monn=C3=A9' > Subject: RE: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge >=20 > > -----Original Message----- > > From: Xen-devel On Behalf = Of Andrew Cooper > > Sent: 15 June 2020 15:15 > > To: Xen-devel > > Cc: Wei Liu ; Paul Durrant ; Andrew Cooper = ; > Jan > > Beulich ; Ian Jackson ; = Roger Pau Monn=C3=A9 > > > > Subject: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge > > > > This is some work in light of IvyBridge not gaining microcode to = combat SRBDS > > / XSA-320. It is a mix of some work I'd planned for 4.15, and some = patches > > posted already and delayed due to dependence's I'd discovered = after-the-fact. > > > > This provides a more user-friendly way of making IvyBridge safe by = default > > without encountering migration incompatibilities. > > > > In terms of functionality, it finishes the "fresh boot" vs = "migrate/restore > > from pre-4.14" split in the libxc CPUID logic, and uses this to let = us safely > > hide features by default without breaking the "divine what a guest = may have > > seen previously" logic on migrate. > > > > On top of that, we hide RDRAND by default to mitigate XSA-320. > > > > Additionally, take the opportunity of finally getting this logic = working to > > hide MPX by default (as posted previously), due to upcoming Intel = timelines. > > > > Request for 4.14. The IvyBridge angle only became apparent after = the public > > embargo on Tue 9th. Otherwise, I would have made a concerted effort = to get > > this logic sorted sooner and/or part of XSA-320 itself. > > > > Strictly speaking, patches 1-4 aren't necessary, but without them = the logic is > > very confusing to follow, particularly the reasoning about the = safely of later > > changes. As it is a simple set of transforms, we're better with = them than > > without. > > > > Also, the MPX patch isn't related to the RDRAND issue, but I was = planning to > > get it into 4.14 already, until realising that the migration path = was broken. > > Now that the path is fixed for the RDRAND issue, include the MPX = patch as it > > pertains to future hardware compatibility (and would be backported = to 4.14.1 > > if it misses 4.14.0). > > >=20 > Fair enough. Once the series has all the requisite maintainer acks = then I'll release-ack it. >=20 I believe all acks are now place so the series is... Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:50:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:50:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXVr-0000x9-2H; Wed, 17 Jun 2020 12:49:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXVp-0000wQ-VY for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:49:54 +0000 X-Inumbo-ID: 09b17de6-b099-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 09b17de6-b099-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 12:49:53 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id u26so4408312wmn.1 for ; Wed, 17 Jun 2020 05:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7yjgcrCzyi5gJKaHwzaM4Sl+1lVQ4RLA2oI/3MRUaQI=; b=UA+bl5MGCV7qjwqxH/7WLeT5pC8zCzvqvWJThOz4DKwHONaZKO/Xy0/5sl7DLiPLmQ nCf9J7/MOYDyBUcAEeasz/K2pL6c6aw25sApjO/IzWWw6DIbqfVJ5Yv0fRJy/RLq2dLa Nb2upJ/0KgWDqUiv7wbbr6KN9pNRhnkC7Hk9e5SyWb3RhVaWSClXwgR9uuQ1xP6mWVWG 69IEIFw2sPGlKisiqwR9rOkDjuXalNVe9sGkKoB/eaTRMOvtFOSFv+1F1wcGdMYjwW2J Pzom5P0XWSGZYRaaFF/Cp/ABPG9Z25NN1FaGInxYBCVQj87wbD6N9A2NY8pA87URwpJm vG3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7yjgcrCzyi5gJKaHwzaM4Sl+1lVQ4RLA2oI/3MRUaQI=; b=qrCucSnFWYWWxGDpDv7Y7geRtBLUwgSTLMncCvQrTapWi+JdnKgpRxZq1m2khqTbbE 8cDn58dqm7IQFThkvfK50wfrUYTOQK9vtOfBXfyra/Rm4WXWQYDY5V53w0a+4JNDimM+ F64t3uMEr/UteVQUUVUiGE0eNnLdwE/XoP8qgeVk81My4v/q3hDT6VpI5oew3XLS/vWa 58W/otxxGXbQB1JftmL6v17y2XW90vkyujKn2vY6Dry8k0XdnmZGjt1PVlrnrS3qYy7y bAvUCX6loMllONmtxOr8At7fa6QX4O7oE2A1XyWX64mzMzMfQoAz82JWa20fKGrWPIRg xCHg== X-Gm-Message-State: AOAM530t34PUDhGOEICDds0uSJ30hxt9Px9JQdhRcJ74jPctilL4205h M3KtkDoPUWIWbutBmyRe4iQsKAH1rvk96VlKAjA= X-Google-Smtp-Source: ABdhPJyo8VEU0hZYeNoBzlg5o9X7hNrIpWgUn44s26PomvPq1vo7caFjbbpTGe55QHPfjjPWMe+OTGUE7mP4E7g1lLg= X-Received: by 2002:a1c:23d2:: with SMTP id j201mr8403913wmj.186.1592398192304; Wed, 17 Jun 2020 05:49:52 -0700 (PDT) MIME-Version: 1.0 References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <20200617082340.GV735@Air-de-Roger> In-Reply-To: <20200617082340.GV735@Air-de-Roger> From: Tamas K Lengyel Date: Wed, 17 Jun 2020 06:49:16 -0600 Message-ID: Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 2:25 AM Roger Pau Monn=C3=A9 = wrote: > > On Tue, Jun 16, 2020 at 12:31:06PM -0700, Tamas K Lengyel wrote: > > While forking VMs running a small RTOS systems (Zephyr) a Xen crash has= been > > observed due to a mm-lock order violation while copying the HVM CPU con= text > > from the parent. This issue has been identified to be due to > > hap_update_paging_modes getting a lock on the gfn using get_gfn. This c= all also > > creates a shared entry in the fork's memory map for the cr3 gfn. The fu= nction > > later calls hap_update_cr3 while holding the paging_lock, which results= in the > > lock-order violation in vmx_load_pdptrs when it tries to unshare the ab= ove entry. > > > > This issue has not affected VMs running other OS's as a call to vmx_loa= d_pdptrs > > is benign if PAE is not enabled or if EFER_LMA is set and returns befor= e > > trying to unshare and map the page. > > > > Using get_gfn_type to get a lock on the gfn avoids this problem as we c= an > > populate the fork's gfn with a copied page instead of a shared entry if= its > > needed, thus avoiding the lock order violation while holding paging_loc= k. > > > > Signed-off-by: Tamas K Lengyel > > --- > > The bug seems to have been present since commit 4cb6c4f4941, only disco= vered > > now due to the heavy use of mem_sharing with VM forks. As this is a sim= ple > > bug-fix it would be nice to include it in the 4.14 release. > > I agree it seems like a candidate bugfix to be included. I've added > Paul to the Cc so he is aware. > > > --- > > xen/arch/x86/mm/hap/hap.c | 17 ++++++++++++----- > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c > > index 7f84d0c6ea..9ae4c3ae6e 100644 > > --- a/xen/arch/x86/mm/hap/hap.c > > +++ b/xen/arch/x86/mm/hap/hap.c > > @@ -748,12 +748,19 @@ static void hap_update_paging_modes(struct vcpu *= v) > > struct domain *d =3D v->domain; > > unsigned long cr3_gfn =3D v->arch.hvm.guest_cr[3] >> PAGE_SHIFT; > > p2m_type_t t; > > + p2m_query_t q =3D P2M_ALLOC; > > > > - /* We hold onto the cr3 as it may be modified later, and > > - * we need to respect lock ordering. No need for > > - * checks here as they are performed by vmx_load_pdptrs > > - * (the potential user of the cr3) */ > > - (void)get_gfn(d, cr3_gfn, &t); > > + /* > > + * We hold onto the cr3 as it may be modified later, and > > + * we need to respect lock ordering. Unshare here if we have to as= to avoid > > + * a lock-order violation later while we are holding the paging_lo= ck. > > + * Further checks are performed by vmx_load_pdptrs (the potential = user of > > + * the cr3). > > + */ > > + if ( hvm_pae_enabled(v) && !hvm_long_mode_active(v) ) > > + q |=3D P2M_UNSHARE; > > + > > + (void)get_gfn_type(d, cr3_gfn, &t, q); > > While there I think you can drop the cast to void. Sure. > > In order for this to be more resilient, maybe it would be better to > just use get_gfn_unshare directly and avoid checking what paging mode > the guest is currently using? > > Or would that be too expensive in terms of performance for the not > affected case? That's what I originally considered sending in but yes, in the fuzzing case it would mean a full-page copy for each iteration even on unaffected cases instead of a one-time shared entry setup. That would be a considerable waste. > > I feel like relying on the internals of vmx_load_pdptrs here is > fragile. I agree it's not ideal. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:51:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:51:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXXV-0001g2-E3; Wed, 17 Jun 2020 12:51:37 +0000 Resent-Date: Wed, 17 Jun 2020 12:51:37 +0000 Resent-Message-Id: Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXXU-0001fs-0y for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:51:36 +0000 X-Inumbo-ID: 452fca9e-b099-11ea-b9df-12813bfff9fa Received: from sender4-of-o57.zoho.com (unknown [136.143.188.57]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 452fca9e-b099-11ea-b9df-12813bfff9fa; Wed, 17 Jun 2020 12:51:33 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1592398286; cv=none; d=zohomail.com; s=zohoarc; b=PuTfDnxvxEZ1wKQxRtF6BgqHLSIjPU9k8ILEPPVbbpop0MYHhBgbucVo8JHt6RLDPAg0OPbVHydDsm1t2wshDPu6Gl5M0OdgB4mYvArq5hldYpIMxfRLOl8cRiODRLNNqM7xm5fo5SmWT1gugnS6r3POAPcTK7O2VYHHOb9yw6g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1592398286; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:Reply-To:Subject:To; bh=DEWslv0hhvdgIHOBYyEAaBrztDkSSBd5TQluyLd17Ks=; b=iEk2dv05eSDb/oCys3j2IFgx1pJxOW1ZWyCII3/Xo6xJyNQiDmieBdH3OrBX9dNXlUAx4K1Te8AKqL/XQJXQzACG7A0Wncta/dtx6JVDMvzNvnDUqNamrV1SBhS2JWql0KdIstBzwELYWw91OdDxN3k37y/IKAx4ZPeoYhR1zWA= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=no-reply@patchew.org; dmarc=pass header.from= header.from= Received: from [172.17.0.3] (23.253.156.214 [23.253.156.214]) by mx.zohomail.com with SMTPS id 1592398284009980.9313228346884; Wed, 17 Jun 2020 05:51:24 -0700 (PDT) Message-ID: <159239828207.14731.15408979322702597452@d1fd068a5071> Subject: Re: [PULL 0/4] Microvm 20200617 patches In-Reply-To: <20200617122901.13327-1-kraxel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Resent-From: From: no-reply@patchew.org To: kraxel@redhat.com Date: Wed, 17 Jun 2020 05:51:24 -0700 (PDT) X-ZohoMailClient: External X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: qemu-devel@nongnu.org Cc: sstabellini@kernel.org, ehabkost@redhat.com, slp@redhat.com, paul@xen.org, mst@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com, marcel.apfelbaum@gmail.com, xen-devel@lists.xenproject.org, anthony.perard@citrix.com, pbonzini@redhat.com, rth@twiddle.net Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" UGF0Y2hldyBVUkw6IGh0dHBzOi8vcGF0Y2hldy5vcmcvUUVNVS8yMDIwMDYxNzEyMjkwMS4xMzMy Ny0xLWtyYXhlbEByZWRoYXQuY29tLwoKCgpIaSwKClRoaXMgc2VyaWVzIGZhaWxlZCB0aGUgYXNh biBidWlsZCB0ZXN0LiBQbGVhc2UgZmluZCB0aGUgdGVzdGluZyBjb21tYW5kcyBhbmQKdGhlaXIg b3V0cHV0IGJlbG93LiBJZiB5b3UgaGF2ZSBEb2NrZXIgaW5zdGFsbGVkLCB5b3UgY2FuIHByb2Jh Ymx5IHJlcHJvZHVjZSBpdApsb2NhbGx5LgoKPT09IFRFU1QgU0NSSVBUIEJFR0lOID09PQojIS9i aW4vYmFzaApleHBvcnQgQVJDSD14ODZfNjQKbWFrZSBkb2NrZXItaW1hZ2UtZmVkb3JhIFY9MSBO RVRXT1JLPTEKdGltZSBtYWtlIGRvY2tlci10ZXN0LWRlYnVnQGZlZG9yYSBUQVJHRVRfTElTVD14 ODZfNjQtc29mdG1tdSBKPTE0IE5FVFdPUks9MQo9PT0gVEVTVCBTQ1JJUFQgRU5EID09PQoKICBD QyAgICAgIHFnYS9tYWluLm8KICBDQyAgICAgIHFnYS9jb21tYW5kcy1wb3NpeC5vCiAgQ0MgICAg ICBxZ2EvY2hhbm5lbC1wb3NpeC5vCi91c3IvYmluL2xkOiAvdXNyL2xpYjY0L2NsYW5nLzEwLjAu MC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9yc192 Zm9yay5TLm8pOiB3YXJuaW5nOiBjb21tb24gb2YgYF9faW50ZXJjZXB0aW9uOjpyZWFsX3Zmb3Jr JyBvdmVycmlkZGVuIGJ5IGRlZmluaXRpb24gZnJvbSAvdXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9s aWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9ycy5jcHAu bykKICBDQyAgICAgIHFnYS9xYXBpLWdlbmVyYXRlZC9xZ2EtcWFwaS10eXBlcy5vCiAgQ0MgICAg ICBxZ2EvcWFwaS1nZW5lcmF0ZWQvcWdhLXFhcGktdmlzaXQubwogIENDICAgICAgcWdhL3FhcGkt Z2VuZXJhdGVkL3FnYS1xYXBpLWNvbW1hbmRzLm8KLS0tCiAgQ0MgICAgICBxZW11LWltZy5vCiAg QVIgICAgICBsaWJ2aG9zdC11c2VyLmEKICBHRU4gICAgIGRvY3MvaW50ZXJvcC9xZW11LWdhLXJl Zi5odG1sCi91c3IvYmluL2xkOiAvdXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGli Y2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9yc192Zm9yay5TLm8pOiB3YXJu aW5nOiBjb21tb24gb2YgYF9faW50ZXJjZXB0aW9uOjpyZWFsX3Zmb3JrJyBvdmVycmlkZGVuIGJ5 IGRlZmluaXRpb24gZnJvbSAvdXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xh bmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9ycy5jcHAubykKICBHRU4gICAgIGRv Y3MvaW50ZXJvcC9xZW11LWdhLXJlZi50eHQKICBHRU4gICAgIGRvY3MvaW50ZXJvcC9xZW11LWdh LXJlZi43CiAgTElOSyAgICBxZW11LWtleW1hcAovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFu Zy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNl cHRvcnNfdmZvcmsuUy5vKTogd2FybmluZzogY29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVh bF92Zm9yaycgb3ZlcnJpZGRlbiBieSBkZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8x MC4wLjAvbGliL2xpbnV4L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRv cnMuY3BwLm8pCiAgTElOSyAgICBpdnNobWVtLWNsaWVudAogIExJTksgICAgaXZzaG1lbS1zZXJ2 ZXIKL3Vzci9iaW4vbGQ6IC91c3IvbGliNjQvY2xhbmcvMTAuMC4wL2xpYi9saW51eC9saWJjbGFu Z19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzX3Zmb3JrLlMubyk6IHdhcm5pbmc6 IGNvbW1vbiBvZiBgX19pbnRlcmNlcHRpb246OnJlYWxfdmZvcmsnIG92ZXJyaWRkZW4gYnkgZGVm aW5pdGlvbiBmcm9tIC91c3IvbGliNjQvY2xhbmcvMTAuMC4wL2xpYi9saW51eC9saWJjbGFuZ19y dC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzLmNwcC5vKQogIEFTICAgICAgcGMtYmlv cy9vcHRpb25yb20vbXVsdGlib290Lm8KICBBUyAgICAgIHBjLWJpb3Mvb3B0aW9ucm9tL2xpbnV4 Ym9vdC5vCiAgQVMgICAgICBwYy1iaW9zL29wdGlvbnJvbS9rdm12YXBpYy5vCiAgQ0MgICAgICBw Yy1iaW9zL29wdGlvbnJvbS9saW51eGJvb3RfZG1hLm8KL3Vzci9iaW4vbGQ6IC91c3IvbGliNjQv Y2xhbmcvMTAuMC4wL2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50 ZXJjZXB0b3JzX3Zmb3JrLlMubyk6IHdhcm5pbmc6IGNvbW1vbiBvZiBgX19pbnRlcmNlcHRpb246 OnJlYWxfdmZvcmsnIG92ZXJyaWRkZW4gYnkgZGVmaW5pdGlvbiBmcm9tIC91c3IvbGliNjQvY2xh bmcvMTAuMC4wL2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJj ZXB0b3JzLmNwcC5vKQogIExJTksgICAgcWVtdS1uYmQKICBBUyAgICAgIHBjLWJpb3Mvb3B0aW9u cm9tL3B2aC5vCiAgQ0MgICAgICBwYy1iaW9zL29wdGlvbnJvbS9wdmhfbWFpbi5vCi0tLQogIEJV SUxEICAgcGMtYmlvcy9vcHRpb25yb20vbGludXhib290LnJhdwogIEJVSUxEICAgcGMtYmlvcy9v cHRpb25yb20vbGludXhib290X2RtYS5yYXcKICBCVUlMRCAgIHBjLWJpb3Mvb3B0aW9ucm9tL2t2 bXZhcGljLnJhdwovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4 L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTog d2FybmluZzogY29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRl biBieSBkZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xp YmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCiAgU0lHTiAg ICBwYy1iaW9zL29wdGlvbnJvbS9tdWx0aWJvb3QuYmluCiAgU0lHTiAgICBwYy1iaW9zL29wdGlv bnJvbS9saW51eGJvb3QuYmluCiAgTElOSyAgICBxZW11LXN0b3JhZ2UtZGFlbW9uCiAgU0lHTiAg ICBwYy1iaW9zL29wdGlvbnJvbS9saW51eGJvb3RfZG1hLmJpbgogIExJTksgICAgcWVtdS1pbWcK ICBTSUdOICAgIHBjLWJpb3Mvb3B0aW9ucm9tL2t2bXZhcGljLmJpbgovdXNyL2Jpbi9sZDogL3Vz ci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEo YXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTogd2FybmluZzogY29tbW9uIG9mIGBfX2ludGVy Y2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRlbiBieSBkZWZpbml0aW9uIGZyb20gL3Vzci9s aWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNh bl9pbnRlcmNlcHRvcnMuY3BwLm8pCi91c3IvYmluL2xkOiAvdXNyL2xpYjY0L2NsYW5nLzEwLjAu MC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9yc192 Zm9yay5TLm8pOiB3YXJuaW5nOiBjb21tb24gb2YgYF9faW50ZXJjZXB0aW9uOjpyZWFsX3Zmb3Jr JyBvdmVycmlkZGVuIGJ5IGRlZmluaXRpb24gZnJvbSAvdXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9s aWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9ycy5jcHAu bykKICBMSU5LICAgIHFlbXUtaW8KICBCVUlMRCAgIHBjLWJpb3Mvb3B0aW9ucm9tL3B2aC5pbWcK ICBMSU5LICAgIHFlbXUtZWRpZAogIEJVSUxEICAgcGMtYmlvcy9vcHRpb25yb20vcHZoLnJhdwog IFNJR04gICAgcGMtYmlvcy9vcHRpb25yb20vcHZoLmJpbgogIExJTksgICAgZnNkZXYvdmlydGZz LXByb3h5LWhlbHBlcgovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xp bnV4L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5v KTogd2FybmluZzogY29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJp ZGRlbiBieSBkZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4 L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCiAgTElO SyAgICBzY3NpL3FlbXUtcHItaGVscGVyCi91c3IvYmluL2xkOiAvdXNyL2xpYjY0L2NsYW5nLzEw LjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9y c192Zm9yay5TLm8pOiB3YXJuaW5nOiBjb21tb24gb2YgYF9faW50ZXJjZXB0aW9uOjpyZWFsX3Zm b3JrJyBvdmVycmlkZGVuIGJ5IGRlZmluaXRpb24gZnJvbSAvdXNyL2xpYjY0L2NsYW5nLzEwLjAu MC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9ycy5j cHAubykKL3Vzci9iaW4vbGQ6IC91c3IvbGliNjQvY2xhbmcvMTAuMC4wL2xpYi9saW51eC9saWJj bGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzX3Zmb3JrLlMubyk6IHdhcm5p bmc6IGNvbW1vbiBvZiBgX19pbnRlcmNlcHRpb246OnJlYWxfdmZvcmsnIG92ZXJyaWRkZW4gYnkg ZGVmaW5pdGlvbiBmcm9tIC91c3IvbGliNjQvY2xhbmcvMTAuMC4wL2xpYi9saW51eC9saWJjbGFu Z19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzLmNwcC5vKQogIExJTksgICAgcWVt dS1icmlkZ2UtaGVscGVyCiAgTElOSyAgICB2aXJ0aW9mc2QKICBMSU5LICAgIHZob3N0LXVzZXIt aW5wdXQKICBMSU5LICAgIHFlbXUtZ2EKL3Vzci9iaW4vbGQ6IC91c3IvbGliNjQvY2xhbmcvMTAu MC4wL2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3Jz X3Zmb3JrLlMubyk6IHdhcm5pbmc6IGNvbW1vbiBvZiBgX19pbnRlcmNlcHRpb246OnJlYWxfdmZv cmsnIG92ZXJyaWRkZW4gYnkgZGVmaW5pdGlvbiBmcm9tIC91c3IvbGliNjQvY2xhbmcvMTAuMC4w L2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzLmNw cC5vKQovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNs YW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTogd2Fybmlu ZzogY29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRlbiBieSBk ZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5n X3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCi91c3IvYmluL2xkOiAv dXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQu YShhc2FuX2ludGVyY2VwdG9yc192Zm9yay5TLm8pOiB3YXJuaW5nOiBjb21tb24gb2YgYF9faW50 ZXJjZXB0aW9uOjpyZWFsX3Zmb3JrJyBvdmVycmlkZGVuIGJ5IGRlZmluaXRpb24gZnJvbSAvdXNy L2xpYjY0L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShh c2FuX2ludGVyY2VwdG9ycy5jcHAubykKL3Vzci9iaW4vbGQ6IC91c3IvbGliNjQvY2xhbmcvMTAu MC4wL2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3Jz X3Zmb3JrLlMubyk6IHdhcm5pbmc6IGNvbW1vbiBvZiBgX19pbnRlcmNlcHRpb246OnJlYWxfdmZv cmsnIG92ZXJyaWRkZW4gYnkgZGVmaW5pdGlvbiBmcm9tIC91c3IvbGliNjQvY2xhbmcvMTAuMC4w L2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzLmNw cC5vKQovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNs YW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTogd2Fybmlu ZzogY29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRlbiBieSBk ZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5n X3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCiAgR0VOICAgICB4ODZf NjQtc29mdG1tdS9obXAtY29tbWFuZHMuaAogIEdFTiAgICAgeDg2XzY0LXNvZnRtbXUvY29uZmln LXRhcmdldC5oCiAgR0VOICAgICB4ODZfNjQtc29mdG1tdS9obXAtY29tbWFuZHMtaW5mby5oCi0t LQogIENDICAgICAgeDg2XzY0LXNvZnRtbXUvaHcvZGlzcGxheS92aG9zdC11c2VyLWdwdS5vCiAg Q0MgICAgICB4ODZfNjQtc29mdG1tdS9ody9kaXNwbGF5L3ZpcnRpby1ncHUtcGNpLm8KICBDQyAg ICAgIHg4Nl82NC1zb2Z0bW11L2h3L2Rpc3BsYXkvdmhvc3QtdXNlci1ncHUtcGNpLm8KL3RtcC9x ZW11LXRlc3Qvc3JjL2ZwdS9zb2Z0ZmxvYXQuYzozMzY1OjEzOiBlcnJvcjogYml0d2lzZSBuZWdh dGlvbiBvZiBhIGJvb2xlYW4gZXhwcmVzc2lvbjsgZGlkIHlvdSBtZWFuIGxvZ2ljYWwgbmVnYXRp b24/IFstV2Vycm9yLC1XYm9vbC1vcGVyYXRpb25dCiAgICBhYnNaICY9IH4gKCAoICggcm91bmRC aXRzIF4gMHg0MCApID09IDAgKSAmIHJvdW5kTmVhcmVzdEV2ZW4gKTsKICAgICAgICAgICAgXn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+CiAgICAg ICAgICAgICEKL3RtcC9xZW11LXRlc3Qvc3JjL2ZwdS9zb2Z0ZmxvYXQuYzozNDIzOjE4OiBlcnJv cjogYml0d2lzZSBuZWdhdGlvbiBvZiBhIGJvb2xlYW4gZXhwcmVzc2lvbjsgZGlkIHlvdSBtZWFu IGxvZ2ljYWwgbmVnYXRpb24/IFstV2Vycm9yLC1XYm9vbC1vcGVyYXRpb25dCiAgICAgICAgYWJz WjAgJj0gfiAoICggKHVpbnQ2NF90KSAoIGFic1oxPDwxICkgPT0gMCApICYgcm91bmROZWFyZXN0 RXZlbiApOwogICAgICAgICAgICAgICAgIF5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fgogICAgICAgICAgICAgICAgICEKL3RtcC9xZW11LXRl c3Qvc3JjL2ZwdS9zb2Z0ZmxvYXQuYzozNDgzOjE4OiBlcnJvcjogYml0d2lzZSBuZWdhdGlvbiBv ZiBhIGJvb2xlYW4gZXhwcmVzc2lvbjsgZGlkIHlvdSBtZWFuIGxvZ2ljYWwgbmVnYXRpb24/IFst V2Vycm9yLC1XYm9vbC1vcGVyYXRpb25dCiAgICAgICAgYWJzWjAgJj0gfigoKHVpbnQ2NF90KShh YnNaMTw8MSkgPT0gMCkgJiByb3VuZE5lYXJlc3RFdmVuKTsKICAgICAgICAgICAgICAgICBefn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+CiAgICAgICAgICAg ICAgICAgIQovdG1wL3FlbXUtdGVzdC9zcmMvZnB1L3NvZnRmbG9hdC5jOjM2MDY6MTM6IGVycm9y OiBiaXR3aXNlIG5lZ2F0aW9uIG9mIGEgYm9vbGVhbiBleHByZXNzaW9uOyBkaWQgeW91IG1lYW4g bG9naWNhbCBuZWdhdGlvbj8gWy1XZXJyb3IsLVdib29sLW9wZXJhdGlvbl0KICAgIHpTaWcgJj0g fiAoICggKCByb3VuZEJpdHMgXiAweDQwICkgPT0gMCApICYgcm91bmROZWFyZXN0RXZlbiApOwog ICAgICAgICAgICBefn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn4KICAgICAgICAgICAgIQovdG1wL3FlbXUtdGVzdC9zcmMvZnB1L3NvZnRmbG9hdC5j OjM3NjA6MTM6IGVycm9yOiBiaXR3aXNlIG5lZ2F0aW9uIG9mIGEgYm9vbGVhbiBleHByZXNzaW9u OyBkaWQgeW91IG1lYW4gbG9naWNhbCBuZWdhdGlvbj8gWy1XZXJyb3IsLVdib29sLW9wZXJhdGlv bl0KICAgIHpTaWcgJj0gfiAoICggKCByb3VuZEJpdHMgXiAweDIwMCApID09IDAgKSAmIHJvdW5k TmVhcmVzdEV2ZW4gKTsKICAgICAgICAgICAgXn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fgogICAgICAgICAgICAhCi90bXAvcWVtdS10ZXN0L3Ny Yy9mcHUvc29mdGZsb2F0LmM6Mzk4NzoyMTogZXJyb3I6IGJpdHdpc2UgbmVnYXRpb24gb2YgYSBi b29sZWFuIGV4cHJlc3Npb247IGRpZCB5b3UgbWVhbiBsb2dpY2FsIG5lZ2F0aW9uPyBbLVdlcnJv ciwtV2Jvb2wtb3BlcmF0aW9uXQogICAgICAgICAgICAgICAgICAgIH4gKCAoICh1aW50NjRfdCkg KCB6U2lnMTw8MSApID09IDAgKSAmIHJvdW5kTmVhcmVzdEV2ZW4gKTsKICAgICAgICAgICAgICAg ICAgICBefn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn4KICAgICAgICAgICAgICAgICAgICAhCi90bXAvcWVtdS10ZXN0L3NyYy9mcHUvc29mdGZs b2F0LmM6NDAwMzoyMjogZXJyb3I6IGJpdHdpc2UgbmVnYXRpb24gb2YgYSBib29sZWFuIGV4cHJl c3Npb247IGRpZCB5b3UgbWVhbiBsb2dpY2FsIG5lZ2F0aW9uPyBbLVdlcnJvciwtV2Jvb2wtb3Bl cmF0aW9uXQogICAgICAgICAgICB6U2lnMCAmPSB+ICggKCAodWludDY0X3QpICggelNpZzE8PDEg KSA9PSAwICkgJiByb3VuZE5lYXJlc3RFdmVuICk7CiAgICAgICAgICAgICAgICAgICAgIF5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fgogICAg ICAgICAgICAgICAgICAgICAhCi90bXAvcWVtdS10ZXN0L3NyYy9mcHUvc29mdGZsb2F0LmM6NDI3 MzoxODogZXJyb3I6IGJpdHdpc2UgbmVnYXRpb24gb2YgYSBib29sZWFuIGV4cHJlc3Npb247IGRp ZCB5b3UgbWVhbiBsb2dpY2FsIG5lZ2F0aW9uPyBbLVdlcnJvciwtV2Jvb2wtb3BlcmF0aW9uXQog ICAgICAgIHpTaWcxICY9IH4gKCAoIHpTaWcyICsgelNpZzIgPT0gMCApICYgcm91bmROZWFyZXN0 RXZlbiApOwogICAgICAgICAgICAgICAgIF5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+CiAgICAgICAgICAgICAgICAgIQo4IGVycm9ycyBnZW5lcmF0ZWQuCm1h a2VbMV06ICoqKiBbL3RtcC9xZW11LXRlc3Qvc3JjL3J1bGVzLm1hazo2OTogZnB1L3NvZnRmbG9h dC5vXSBFcnJvciAxCm1ha2VbMV06ICoqKiBXYWl0aW5nIGZvciB1bmZpbmlzaGVkIGpvYnMuLi4u Ci90bXAvcWVtdS10ZXN0L3NyYy9taWdyYXRpb24vcmFtLmM6OTE5OjQ1OiBlcnJvcjogaW1wbGlj aXQgY29udmVyc2lvbiBmcm9tICd1bnNpZ25lZCBsb25nJyB0byAnZG91YmxlJyBjaGFuZ2VzIHZh bHVlIGZyb20gMTg0NDY3NDQwNzM3MDk1NTE2MTUgdG8gMTg0NDY3NDQwNzM3MDk1NTE2MTYgWy1X ZXJyb3IsLVdpbXBsaWNpdC1pbnQtZmxvYXQtY29udmVyc2lvbl0KICAgICAgICAgICAgeGJ6cmxl X2NvdW50ZXJzLmVuY29kaW5nX3JhdGUgPSBVSU5UNjRfTUFYOwogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB+IF5+fn5+fn5+fn4KL3Vzci9pbmNsdWRlL3N0ZGludC5o OjEzMDoyMzogbm90ZTogZXhwYW5kZWQgZnJvbSBtYWNybyAnVUlOVDY0X01BWCcKLS0tCjE4NDQ2 NzQ0MDczNzA5NTUxNjE1VUwKXn5+fn5+fn5+fn5+fn5+fn5+fn5+fgoxIGVycm9yIGdlbmVyYXRl ZC4KbWFrZVsxXTogKioqIFsvdG1wL3FlbXUtdGVzdC9zcmMvcnVsZXMubWFrOjY5OiBtaWdyYXRp b24vcmFtLm9dIEVycm9yIDEKbWFrZTogKioqIFtNYWtlZmlsZTo1Mjc6IHg4Nl82NC1zb2Z0bW11 L2FsbF0gRXJyb3IgMgpUcmFjZWJhY2sgKG1vc3QgcmVjZW50IGNhbGwgbGFzdCk6CiAgRmlsZSAi Li90ZXN0cy9kb2NrZXIvZG9ja2VyLnB5IiwgbGluZSA2NjksIGluIDxtb2R1bGU+CiAgICBzeXMu ZXhpdChtYWluKCkpCi0tLQogICAgcmFpc2UgQ2FsbGVkUHJvY2Vzc0Vycm9yKHJldGNvZGUsIGNt ZCkKc3VicHJvY2Vzcy5DYWxsZWRQcm9jZXNzRXJyb3I6IENvbW1hbmQgJ1snc3VkbycsICctbics ICdkb2NrZXInLCAncnVuJywgJy0tbGFiZWwnLCAnY29tLnFlbXUuaW5zdGFuY2UudXVpZD1lMGFl YTMwZWI0ZTg0NjEyOTI4MjNmMjFhZGU5MjgwYycsICctdScsICcxMDAxJywgJy0tc2VjdXJpdHkt b3B0JywgJ3NlY2NvbXA9dW5jb25maW5lZCcsICctLXJtJywgJy1lJywgJ1RBUkdFVF9MSVNUPXg4 Nl82NC1zb2Z0bW11JywgJy1lJywgJ0VYVFJBX0NPTkZJR1VSRV9PUFRTPScsICctZScsICdWPScs ICctZScsICdKPTE0JywgJy1lJywgJ0RFQlVHPScsICctZScsICdTSE9XX0VOVj0nLCAnLWUnLCAn Q0NBQ0hFX0RJUj0vdmFyL3RtcC9jY2FjaGUnLCAnLXYnLCAnL2hvbWUvcGF0Y2hldy8uY2FjaGUv cWVtdS1kb2NrZXItY2NhY2hlOi92YXIvdG1wL2NjYWNoZTp6JywgJy12JywgJy92YXIvdG1wL3Bh dGNoZXctdGVzdGVyLXRtcC03bGYxM3dyMi9zcmMvZG9ja2VyLXNyYy4yMDIwLTA2LTE3LTA4LjQ3 LjE0LjMwODIwOi92YXIvdG1wL3FlbXU6eixybycsICdxZW11OmZlZG9yYScsICcvdmFyL3RtcC9x ZW11L3J1bicsICd0ZXN0LWRlYnVnJ10nIHJldHVybmVkIG5vbi16ZXJvIGV4aXQgc3RhdHVzIDIu CmZpbHRlcj0tLWZpbHRlcj1sYWJlbD1jb20ucWVtdS5pbnN0YW5jZS51dWlkPWUwYWVhMzBlYjRl ODQ2MTI5MjgyM2YyMWFkZTkyODBjCm1ha2VbMV06ICoqKiBbZG9ja2VyLXJ1bl0gRXJyb3IgMQpt YWtlWzFdOiBMZWF2aW5nIGRpcmVjdG9yeSBgL3Zhci90bXAvcGF0Y2hldy10ZXN0ZXItdG1wLTds ZjEzd3IyL3NyYycKbWFrZTogKioqIFtkb2NrZXItcnVuLXRlc3QtZGVidWdAZmVkb3JhXSBFcnJv ciAyCgpyZWFsICAgIDRtNy4xMzVzCnVzZXIgICAgMG04LjA4NXMKCgpUaGUgZnVsbCBsb2cgaXMg YXZhaWxhYmxlIGF0Cmh0dHA6Ly9wYXRjaGV3Lm9yZy9sb2dzLzIwMjAwNjE3MTIyOTAxLjEzMzI3 LTEta3JheGVsQHJlZGhhdC5jb20vdGVzdGluZy5hc2FuLz90eXBlPW1lc3NhZ2UuCi0tLQpFbWFp bCBnZW5lcmF0ZWQgYXV0b21hdGljYWxseSBieSBQYXRjaGV3IFtodHRwczovL3BhdGNoZXcub3Jn L10uClBsZWFzZSBzZW5kIHlvdXIgZmVlZGJhY2sgdG8gcGF0Y2hldy1kZXZlbEByZWRoYXQuY29t From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:51:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:51:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXXn-0001iQ-Mp; Wed, 17 Jun 2020 12:51:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXXm-0001iJ-SK for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:51:54 +0000 X-Inumbo-ID: 51d00b88-b099-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 51d00b88-b099-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 12:51:54 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: JelWnxgmzcGxW2RilfLHiKwTeGyTzsm+y9rEL7KMQEj43MMwwWZbkt1P5xdODg8VUJbhDWa8vU +NMXNNp8SvERiO0PqrhaeJXL3z0KqFUJVIT3DjKU8+sT5bwHWTRWAN0X1bM/6kXQcQsVdYaKlc cG7ujtsRPASJVA4pOihNkxH7Szz1UQLTWJYAzP41VChdEvmh+Hmay4LF4n0C56G81kSM3Spr8m zv+G8I8gIlOURRQQY0noKlL1//vrAw0uJRMELY/IqGVACHVp2Yso1L2mzo/u8m/Y2u+A/AmciS rz8= X-SBRS: 2.7 X-MesageID: 20611856 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20611856" Date: Wed, 17 Jun 2020 14:51:46 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit Message-ID: <20200617125146.GA735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> <20200616173857.GU735@Air-de-Roger> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> <20200617090942.GY735@Air-de-Roger> <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote: > ----- 17 cze 2020 o 11:09, Roger Pau Monné roger.pau@citrix.com napisał(a): > > > On Tue, Jun 16, 2020 at 07:47:07PM +0200, Michał Leszczyński wrote: > >> ----- 16 cze 2020 o 19:38, Roger Pau Monné roger.pau@citrix.com napisał(a): > >> > >> > On Tue, Jun 16, 2020 at 05:24:11PM +0200, Michał Leszczyński wrote: > >> >> Enable IPT when entering the VM and disable it on vmexit. > >> >> Register state is persisted using vCPU ipt_state structure. > >> > > >> > Shouldn't this be better done using Intel MSR load lists? > >> > > >> > That seems to be what the SDM recommends for tracing VM events. > >> > > >> > Thanks, Roger. > >> > >> > >> This is intentional, additionally described by the comment: > >> > >> // MSR_IA32_RTIT_CTL is context-switched manually instead of being > >> // stored inside VMCS, as of Q2'20 only the most recent processors > >> // support such field in VMCS > >> > >> > >> There is a special feature flag which indicates whether MSR_IA32_RTIT_CTL can be > >> loaded using MR load lists. > > > > I've been looking at the Intel SDM and I'm not able to find which bit > > signals whether MSR_IA32_RTIT_CTL can be loaded using MSR load lists. > > Sorry to ask, but can you elaborate on where is this signaled? > > > > Thanks, Roger. > > > According to SDM: > > > 24 Virtual Machine Control Structures -> 24.4 Guest-state Area -> 24.4.1 Guest Register State > > > IA32_RTIT_CTL (64 bits). This field is supported only on processors that support either the 1-setting of the "load IA32_RTIT_CTL" VM-entry control or that of the "clear IA32_RTIT_CTL" VM-exit control. > > > > 24 Virtual Machine Control Structures -> 24.8 VM-entry Control Fields -> 24.8.1 VM-Entry Controls > > > Software should consult the VMX capability MSRs IA32_VMX_ENTRY_CTLS to determine how it should set the reserved bits. > > Please look at bit position 18 "Load IA32_RTIT_CTL". I think this is something different from what I was referring to. Those options you refer to (load/clear IA32_RTIT_CTL) deal with loading/storing a specific field on the vmcs that maps to the guest IA32_RTIT_CTL. OTOH MSR load lists can be used to load and store any arbitrary MSR on vmentry/vmexit, see section 26.4 LOADING MSRS on the SDM. There's already infrastructure on Xen to do so, see vmx_{add/del/find}_msr. Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 17 12:53:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 12:53:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXZd-0001tH-2G; Wed, 17 Jun 2020 12:53:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXZc-0001tB-11 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 12:53:48 +0000 X-Inumbo-ID: 9542b9f6-b099-11ea-bb8b-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9542b9f6-b099-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 12:53:47 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: hFbQ4rmH6qBHHMliPvv+BVE5yCWgnHfKKS/Tpff7AFdUQbh5OcnX19iN/TFhP3Un6irs+K3dsX nVpcWjz0GwpMCH0syRTI21OTlAxJPjzph3YfiwoaUuZmhoNNt/RzF4UBJe11WpaguFYyJ9cofB q+zEIVhIA2yuTUCeoZyGGZeWQUWo4hOn3UOTHT76s9bk54EPS6feDMMii68pbS6S7f4WiWQhrB CYgKZ1oe28o+wBgNcyIcSwoKDleFBXxpfZEFLESogC6kjZ6z4S/RVv9aACfY7UH32xW+lahws+ MUg= X-SBRS: 2.7 X-MesageID: 20567749 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="20567749" Date: Wed, 17 Jun 2020 14:53:39 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: "Kang, Luwei" Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring Message-ID: <20200617125339.GB735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <20200617092103.GZ735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Tian, Kevin" , Stefano Stabellini , Julien Grall , "Nakajima, Jun" , Wei Liu , Andrew Cooper , =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 12:37:13PM +0000, Kang, Luwei wrote: > > How does KVM deal with this, do they insert/modify trace packets on trapped > > and emulated instructions by the VMM? > > The KVM includes instruction decoder and emulator(arch/x86/kvm/emulate.c), and the guest's memory can be set to write-protect as well. But it doesn't support Intel PT packets software emulator. For KVM, the Intel PT feature will be exposed to KVM guest and KVM guest can use Intel PT feature like native. But if such feature is exposed to the guest for it's own usage, won't it be missing packets for instructions emulated by the VMM? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:01:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:01:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXgb-0002mf-03; Wed, 17 Jun 2020 13:01:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXgZ-0002ma-GJ for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:00:59 +0000 X-Inumbo-ID: 965f52e4-b09a-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 965f52e4-b09a-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 13:00:58 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id b6so2223646wrs.11 for ; Wed, 17 Jun 2020 06:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v/rW5LTGj4GPKbMakqMHyvbq7KnUYJeC2G+6L8ZtCW4=; b=O6HLfmLnIfv3/+A9/zApgvPrdUa2WKqxf9UCNTvt7JT7V9uHMSLFZtkmxRz8D5OdFo THN6iOcKkpynDRKg0CmUFQH/dnFbhf2T+sIzAMH1OKfB9YivKn74lUAoPtLUnfsY1TAH H+Df//lb9P6hgQYjZmvILGN5PKcEFQlV90Y0D9HfO06nFsUZU8EAjlXRz+xZdYYRCOip 3TZ8RC+sbPrhTZETlr/cwskBq+4MmbGW+0RBumd9Vra61X0XKAuvv74NgOsTTS/yiQqX WlqlTB5lDkdt5duUe33Iny/QdldZef98cnxwUphE4k4XM/uKfCWkBxDP4RX9hUOn/JE8 TV3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v/rW5LTGj4GPKbMakqMHyvbq7KnUYJeC2G+6L8ZtCW4=; b=CVn0ZDJbiej53FLmIvBTRK0GnE+4aMi5g4Vv+emHO8tmOOYdSWqPOxjH7aRn8pzbX7 mrnhmx7bbjgT/CP3ctMH0g8nlqprkLTb96miblEW/UoiZsbrVXPQiOmwtPwNEZ9gcjrR X4gTh8pGcuDv3fGPdxQEzF89eyzV+S/pzwK3Wr6pWdCMk1/3enjr863HmA1eOJAxuSeX iw0rp3scjyXbYRi1qQOmoUMNYOPEka8OPlEgY30xcIYjUA17vmhUqs6bNytRSEOvRDdM ty3TpeAx/Giz3BEFSt7joH0Qf0Vlq2Lb+YD0kMbP1FboFeEVJASt+30ya4FQ7Uo2Uvd7 HkKA== X-Gm-Message-State: AOAM5325CzHK8HGrTjyLbOXSfqnBecjMwGDZaDCO/h2nUKiyzBGquBDa LKElHjq0mA4EmsbBZ86EnM1GMr5yCh26Z2WYtO0= X-Google-Smtp-Source: ABdhPJx1SgJMRQ8WjbNV2MT3xCeOdan/gzekjwMelb3d+q6tPwr/G39L6QaJjJvzHgky7TUsdMI9EJE/M903F8CAWeQ= X-Received: by 2002:a5d:490f:: with SMTP id x15mr8257488wrq.259.1592398857729; Wed, 17 Jun 2020 06:00:57 -0700 (PDT) MIME-Version: 1.0 References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> In-Reply-To: From: Tamas K Lengyel Date: Wed, 17 Jun 2020 07:00:22 -0600 Message-ID: Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: > > On 16.06.2020 21:31, Tamas K Lengyel wrote: > > While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been > > observed due to a mm-lock order violation while copying the HVM CPU context > > from the parent. This issue has been identified to be due to > > hap_update_paging_modes getting a lock on the gfn using get_gfn. This call also > > creates a shared entry in the fork's memory map for the cr3 gfn. The function > > later calls hap_update_cr3 while holding the paging_lock, which results in the > > lock-order violation in vmx_load_pdptrs when it tries to unshare the above entry. > > > > This issue has not affected VMs running other OS's as a call to vmx_load_pdptrs > > is benign if PAE is not enabled or if EFER_LMA is set and returns before > > trying to unshare and map the page. > > > > Using get_gfn_type to get a lock on the gfn avoids this problem as we can > > populate the fork's gfn with a copied page instead of a shared entry if its > > needed, thus avoiding the lock order violation while holding paging_lock. > > > > Signed-off-by: Tamas K Lengyel > > --- > > The bug seems to have been present since commit 4cb6c4f4941, only discovered > > now due to the heavy use of mem_sharing with VM forks. > > I'm unconvinced that commit is the origin of the problem. Before that, > get_gfn_unshare() was used, which aiui had/has similar locking > properties. In fact I'm having trouble seeing how this works at all, > i.e. with or without mem-sharing: p2m_get_page_from_gfn() at the very > least uses p2m_read_lock(), which also doesn't nest inside the paging > lock. What am I overlooking? I haven't investigated past what git blame showed, that's why I said "seems to have been present since". Entirely possible it was broken before as well due to the lock ordering. I'm not sure about p2m_get_page_from_gfn, haven't ran into an issue there (yet). > > > --- a/xen/arch/x86/mm/hap/hap.c > > +++ b/xen/arch/x86/mm/hap/hap.c > > @@ -748,12 +748,19 @@ static void hap_update_paging_modes(struct vcpu *v) > > struct domain *d = v->domain; > > unsigned long cr3_gfn = v->arch.hvm.guest_cr[3] >> PAGE_SHIFT; > > p2m_type_t t; > > + p2m_query_t q = P2M_ALLOC; > > > > - /* We hold onto the cr3 as it may be modified later, and > > - * we need to respect lock ordering. No need for > > - * checks here as they are performed by vmx_load_pdptrs > > - * (the potential user of the cr3) */ > > - (void)get_gfn(d, cr3_gfn, &t); > > + /* > > + * We hold onto the cr3 as it may be modified later, and > > + * we need to respect lock ordering. Unshare here if we have to as to avoid > > + * a lock-order violation later while we are holding the paging_lock. > > + * Further checks are performed by vmx_load_pdptrs (the potential user of > > + * the cr3). > > + */ > > Nit: Please re-flow such that the first line isn't very noticeably > shorter than the later ones. Sure. > > > + if ( hvm_pae_enabled(v) && !hvm_long_mode_active(v) ) > > + q |= P2M_UNSHARE; > > + > > + (void)get_gfn_type(d, cr3_gfn, &t, q); > > Imo this then wants to be accompanied by dropping the unsharing > attempt from vmx_load_pdptrs(). By using get_gfn_query_unlocked() > there (assuming all code paths hold the paging lock) the lock > order issue could be addressed in full then. (If taking this > route, the comment ahead of get_gfn_query_unlocked()'s declaration > will want adjusting, to drop mentioning shadow mode explicitly as > leveraging already holding the paging lock.) There is at least another path to vmx_load_pdptrs from arch_set_info_hvm_guest as well which doesn't hold the paging lock. > If there are code paths of both kinds, which approach to use in > vmx_load_pdptrs() may need to be chosen based on what > paging_locked_by_me() returns. Or perhaps an unlocked query is > fine in either case? Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be fine. But at that point what is the reason for having the lock ordering at all? Why not just have a single recursive lock and avoid issues like this altogether? Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:04:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:04:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXkD-0002vG-Gr; Wed, 17 Jun 2020 13:04:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlXkC-0002v8-8o for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:04:44 +0000 X-Inumbo-ID: 1c030a76-b09b-11ea-b9e4-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1c030a76-b09b-11ea-b9e4-12813bfff9fa; Wed, 17 Jun 2020 13:04:42 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B2F4FAAC7; Wed, 17 Jun 2020 13:04:45 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Tamas K Lengyel References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> From: Jan Beulich Message-ID: <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> Date: Wed, 17 Jun 2020 15:04:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17.06.2020 15:00, Tamas K Lengyel wrote: > On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: >> If there are code paths of both kinds, which approach to use in >> vmx_load_pdptrs() may need to be chosen based on what >> paging_locked_by_me() returns. Or perhaps an unlocked query is >> fine in either case? > > Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be > fine. But at that point what is the reason for having the lock > ordering at all? Why not just have a single recursive lock and avoid > issues like this altogether? With just a single lock, contention problems we already know we have would be even worse. When the current locking model was introduced, there was actually a plan to make gfn_lock() more fine-grained (i.e. not simply "de-generate" to p2m_lock()), for example. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:22:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:22:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlY1C-0004XK-1X; Wed, 17 Jun 2020 13:22:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlY1A-0004XF-Tp for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:22:16 +0000 X-Inumbo-ID: 8fc44162-b09d-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8fc44162-b09d-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 13:22:16 +0000 (UTC) Received: by mail-wm1-x343.google.com with SMTP id d128so1984461wmc.1 for ; Wed, 17 Jun 2020 06:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EULaudrOQif1rUxEpv1kEBycuTv3OmqyypseBuowOT8=; b=RKnczbQd0xpqb+gZiPuVDWgGpfjyE5WSj/JMylfIyEM4KseKKDg9YNHy/gKN2XO/TT n9Piwr2WVb+EXbK9JOTxt4N3Qqj8yfzQHlO34Qopmi2P/vbyp8C0FPBmGqcakah6HVrB fi0TJBE3ku0CTbHkKoeVWPKeOcd+b6cFXBp8IdqtQTuTKab9f0gEFZ0sY7bNLRgBmUpi LGzA5wIGbeWqwKGCVfJ/ugfXMwH8R5f/og20d2y+9NyScvx/dHm837KFQWnz4aKDSGr3 b+1pkhDdu9LriTUyGmoHJHvzC68KPJ5+T2cQOPHwbrhDXR7u7ab4D8GGiWOd6zfjBwQJ qQIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EULaudrOQif1rUxEpv1kEBycuTv3OmqyypseBuowOT8=; b=YtFYBi4pchZIVMO+JGGBr0090Dp3AUIzE0bnRAT/vVdYO/kzT4ycT4trIHACUMAxs2 gMaB0lnLkvIcmNNgfBGyQk2PD1hisjxQXOOeXyx04Jer8h4NT43HdMNCRpzUMAtv1hwM thLxdvUHKlqyDbJk2+TiCEYnXAt32GRlwXzMffnW9P6Mw6yUCAqCzCPvLRbBXXRGn9YS kxBkec/txXC0N7XAEnGwJGVyXnqUltHMHin7G8fbNyjYK1BMFRFxG3lDecpYK+EfcF+p bRte8C4AQqGYWW+65xYC/QdUCdCNX0z35vRuSVojECDVYYqTc46Vvholqzq3zOnYr0mN lrfQ== X-Gm-Message-State: AOAM5328o8uXuuBFMqnRwh3C12aTby1TlZEBTmM17p6+xU2K3hPjQ6mc stpug1yw81jNXnU3DI3eAORNru/GlzoKPHD1B1M= X-Google-Smtp-Source: ABdhPJzCOfsTYk8sgKd6wtgFy4YpVugvFXtIPBorD3uTzVGNjr5ZAtOp8uTM0XM1uyyO4Zk2DbQ4jdeL3piIE4ydAms= X-Received: by 2002:a1c:23d2:: with SMTP id j201mr8547150wmj.186.1592400135301; Wed, 17 Jun 2020 06:22:15 -0700 (PDT) MIME-Version: 1.0 References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> In-Reply-To: <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> From: Tamas K Lengyel Date: Wed, 17 Jun 2020 07:21:39 -0600 Message-ID: Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: > > On 17.06.2020 15:00, Tamas K Lengyel wrote: > > On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: > >> If there are code paths of both kinds, which approach to use in > >> vmx_load_pdptrs() may need to be chosen based on what > >> paging_locked_by_me() returns. Or perhaps an unlocked query is > >> fine in either case? > > > > Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be > > fine. But at that point what is the reason for having the lock > > ordering at all? Why not just have a single recursive lock and avoid > > issues like this altogether? > > With just a single lock, contention problems we already know we > have would be even worse. When the current locking model was > introduced, there was actually a plan to make gfn_lock() more > fine-grained (i.e. not simply "de-generate" to p2m_lock()), for > example. Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an unlocked query doesn't seem as straightforward because, well, there is no unlocked version of p2m_get_page_from_gfn which would also do the "fixups". What seems redundant to me though is that hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the paging_lock. Does it really need to take the paging_lock? If it only held the gfn_lock/p2m_lock then we would have the lock order violation down the road. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:28:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:28:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlY7O-0004jG-P5; Wed, 17 Jun 2020 13:28:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlY7N-0004jA-MU for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:28:41 +0000 X-Inumbo-ID: 75228b56-b09e-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 75228b56-b09e-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 13:28:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4833FB122; Wed, 17 Jun 2020 13:28:43 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Tamas K Lengyel References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> From: Jan Beulich Message-ID: <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> Date: Wed, 17 Jun 2020 15:28:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17.06.2020 15:21, Tamas K Lengyel wrote: > On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: >> >> On 17.06.2020 15:00, Tamas K Lengyel wrote: >>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: >>>> If there are code paths of both kinds, which approach to use in >>>> vmx_load_pdptrs() may need to be chosen based on what >>>> paging_locked_by_me() returns. Or perhaps an unlocked query is >>>> fine in either case? >>> >>> Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be >>> fine. But at that point what is the reason for having the lock >>> ordering at all? Why not just have a single recursive lock and avoid >>> issues like this altogether? >> >> With just a single lock, contention problems we already know we >> have would be even worse. When the current locking model was >> introduced, there was actually a plan to make gfn_lock() more >> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for >> example. > > Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an > unlocked query doesn't seem as straightforward because, well, there is > no unlocked version of p2m_get_page_from_gfn which would also do the > "fixups". Which fixups do we need here, in particular? Of course, whenever any fixups get done, the operation can't be lock-less. > What seems redundant to me though is that > hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the > paging_lock. Does it really need to take the paging_lock? >From mm-locks.h's comments: * For HAP, it protects the NPT/EPT tables and mode changes. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:30:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:30:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlY8n-0005Sh-3p; Wed, 17 Jun 2020 13:30:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlY8l-0005Ov-9g for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:30:07 +0000 X-Inumbo-ID: a8325648-b09e-11ea-bb8b-bc764e2007e4 Received: from mail-lf1-x143.google.com (unknown [2a00:1450:4864:20::143]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a8325648-b09e-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 13:30:06 +0000 (UTC) Received: by mail-lf1-x143.google.com with SMTP id z206so1296255lfc.6 for ; Wed, 17 Jun 2020 06:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=naV3pn/4joHIxnpAikiUebhOeeEfW7XndrRLctwWfSE=; b=a+G6aAFY2ZYuddGTbE64uaRh0wSUIDJP2E3Q8B/yZWMr6oQT84zjmZ27bE/ebFeYy4 W2G34cApbUZgI3zCzZf1JAcjPsys1wyl136/rIEGjcrat1QHvuAtX0lt1ESYWHHgNWVc mkXpYqtBoyEcCwoy5JL9VSmrZlD0yhYVHYDdi03svRbdXFH76PWD5UhHpo81MYZkGNpR +NkOHdX2T1Mj0WwmCSUKupnXOMnLlXnfqoJ9h74yscH3fqz8isjzWrwSLPecEipUmdtX MJfMFsWuIsBfAEqjYDKdsePC5yMT+Tz4Ti2IgjQhx789j/ETL6l9Mby/ONH2uWk4g9/o Om1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=naV3pn/4joHIxnpAikiUebhOeeEfW7XndrRLctwWfSE=; b=YFaihEgG2XjTf//MIIRgHVwPC3zSxdT44h65FmlmsuKAg076sdpSozq7TEatrZZnF9 RM5dITnA2HmjgVpjUHh6nOOuKYtOEIrNYl1OPqpXClkX9SYdSu/kGtLO0NsfpSxITOKK YGOtHeqZ0Y8ZUSPxyMQOgLMlMuu1T1pOKuni03WIQWGbD3JOxHq1Sd4TsAD0p5xHYzma 4ud3CCFKwnaxP5okdLx4JRWe2f0kIvoR4yZdJjau4Gr/nfVvjpac/T3BDyU4QLhnBrz4 IO+8pT5XDbmmmyvWdIHIgQ/Fv1ouF53AOHYQKvo3cwlajbKLvApJkHE+cv9G7Sm++lIZ Q9Bw== X-Gm-Message-State: AOAM5304dEYUDq7uo5ctrDS2RSzWw5vmEiSH4wqTpW4zFqP9dIY4XmlC Is5PWAji4oOvRkJhzrFv3FVfX7lPDzQ6X3mlx7k= X-Google-Smtp-Source: ABdhPJxA3ncGrXcJsse56MTtmuoV2AU6ErANEiZA6jt/WY0XTXuKKdRls+r6u6Ib8w3VOglDqxZrxnnY+E7kVsiqH/Q= X-Received: by 2002:a19:4a4e:: with SMTP id x75mr4535830lfa.70.1592400605719; Wed, 17 Jun 2020 06:30:05 -0700 (PDT) MIME-Version: 1.0 References: <20200617061349.7623-1-olaf@aepfle.de> In-Reply-To: <20200617061349.7623-1-olaf@aepfle.de> From: Jason Andryuk Date: Wed, 17 Jun 2020 09:29:54 -0400 Message-ID: Subject: Re: [PATCH v1] stubdom/vtpmmgr: simplify handling of hardware_version To: Olaf Hering Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Daniel De Graaf , Quan Xu , Samuel Thibault Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 2:16 AM Olaf Hering wrote: > > Remove complicated code which deals with a simple boolean, to make gcc10 = happy. > > ld: /home/abuild/rpmbuild/BUILD/xen-4.14.20200616T103126.3625b04991/non-d= bg/stubdom/vtpmmgr/vtpmmgr.a(vtpm_cmd_handler.o):(.bss+0x0): multiple defin= ition of `tpm_version'; /home/abuild/rpmbuild/BUILD/xen-4.14.20200616T10312= 6.3625b04991/non-dbg/stubdom/vtpmmgr/vtpmmgr.a(vtpmmgr.o):(.bss+0x0): first= defined here > > Signed-off-by: Olaf Hering Nice simplification. Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:32:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:32:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYAp-0005Zz-H6; Wed, 17 Jun 2020 13:32:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYAn-0005Zs-OO for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:32:13 +0000 X-Inumbo-ID: f3a57f4c-b09e-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f3a57f4c-b09e-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 13:32:13 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id e1so2367109wrt.5 for ; Wed, 17 Jun 2020 06:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=41N96wGg45X8tNPvMWjE+2C4QZnFC4aqzvjOlMDH9V8=; b=XQSBq9nPiE5u/KTDybiNKVnh9I1mxrJ+TzhzGRtjdQB9e0AI0Rd0PMyYbG7D1kRJDD prLuyIxYm+i4WUb9GmD3hmfi7TmGa02gyrF5CsFPb/tRh5yQijh9u+m8bjKjkIGtWy9O hPiFkHPagM69xAhnt+g5lItIXxNGtuLGqek3f2uXqlIkk9a64OAE3OHMJroFbDJF9cKx l031fppaYaYktGbs7JFLRDLHtNUievXt7i9N6ELqxAaEGPcMRUbIzhpLNep+4bJMRdb2 UrVDe1x8Lth0s3PuPN85jx8tFQCJJa0tGU5y/SwPwBbmTuvDGomU/lytuWDh/lUrNMpf 4PQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=41N96wGg45X8tNPvMWjE+2C4QZnFC4aqzvjOlMDH9V8=; b=I97/4H7RVnarydaSA9qL7wN8GkK314CYZP9O5NoDrYaP3LsVZ6DmgWiJY0Hb61+ELT EKHvxYX5K5nd3Sq6ZLSKVyXuI8r4GQfyQaeOX1VQM2uT0eexjAexEyp6ixUzJ37KvpMM x6L4GbGJeCRPq47QdiOoSWuZC9Gvekz/PDUKgMEYVmbZQg5HVGFAIXoamaBFnnOML3u6 8lew9rvErcubfTwKYr3waA4w0KvUZe0IZ0s8VCk7QX1tjNkfxnlkGAQIyvm5s1AsjpLY xATmLPfhDd1R1VObta9YrWETFGE/TsvGb5HatsaVXKbKLuYFkacER97DQSvQ9bSN1Jw9 boWA== X-Gm-Message-State: AOAM530AiHt01Q5T265UznoYScP/ahAQwneSAXhVuaTqZa0jR6Iefk93 7juH9BhAytOSk7OfxsL95S0BVq4zeoJVT2+LhlM= X-Google-Smtp-Source: ABdhPJz2o62Ss7oDQTTmGH81wnC7xKIUk4liobRoHw41O4mq9FIBCTf1pmYEiGN0f38RXzhdHHbm8rf3UmXqkLV/6XQ= X-Received: by 2002:adf:f707:: with SMTP id r7mr9141490wrp.390.1592400732305; Wed, 17 Jun 2020 06:32:12 -0700 (PDT) MIME-Version: 1.0 References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> In-Reply-To: <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> From: Tamas K Lengyel Date: Wed, 17 Jun 2020 07:31:36 -0600 Message-ID: Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote: > > On 17.06.2020 15:21, Tamas K Lengyel wrote: > > On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: > >> > >> On 17.06.2020 15:00, Tamas K Lengyel wrote: > >>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: > >>>> If there are code paths of both kinds, which approach to use in > >>>> vmx_load_pdptrs() may need to be chosen based on what > >>>> paging_locked_by_me() returns. Or perhaps an unlocked query is > >>>> fine in either case? > >>> > >>> Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be > >>> fine. But at that point what is the reason for having the lock > >>> ordering at all? Why not just have a single recursive lock and avoid > >>> issues like this altogether? > >> > >> With just a single lock, contention problems we already know we > >> have would be even worse. When the current locking model was > >> introduced, there was actually a plan to make gfn_lock() more > >> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for > >> example. > > > > Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an > > unlocked query doesn't seem as straightforward because, well, there is > > no unlocked version of p2m_get_page_from_gfn which would also do the > > "fixups". > > Which fixups do we need here, in particular? Of course, whenever > any fixups get done, the operation can't be lock-less. > > > What seems redundant to me though is that > > hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the > > paging_lock. Does it really need to take the paging_lock? > > From mm-locks.h's comments: > > * For HAP, it protects the NPT/EPT tables and mode changes. We do the population of the EPT as part of fork_page() if there was a hole in the p2m when the query was issued using P2M_ALLOC (or P2M_UNSHARE). I checked and without the paging lock held it throws up at hap_alloc's ASSERT.. So yea, currently I don't think we have a better route then what I currently sent in. Perhaps the "hvm_pae_enabled(v) && !hvm_long_mode_active(v)" can be moved into hvm.h and be used by vmx_load_pdptrs as well, making it less fragile in case there is an adjustment to it in the future. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:36:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:36:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYEd-0005u2-MQ; Wed, 17 Jun 2020 13:36:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYEc-0005tx-Lw for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:36:10 +0000 X-Inumbo-ID: 7dd3557c-b09f-11ea-b7bb-bc764e2007e4 Received: from mail-lj1-x242.google.com (unknown [2a00:1450:4864:20::242]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7dd3557c-b09f-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 13:36:05 +0000 (UTC) Received: by mail-lj1-x242.google.com with SMTP id z9so2842550ljh.13 for ; Wed, 17 Jun 2020 06:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fhxgw1sjLqMS7CqTdoFKMVQKulz+t3CEc2SleEtaktI=; b=DqQEbQJFwIrrc/9NwPOfF3yGvcgyRLZZlx9J17BBWZbtShTlhM8bsZ+pXI5N7Bg0OM 9SuaB6EAVMmzOKxMpvnGh/HAHtZUzyyTa2BbT/v/LROnbbmIcbRDnGm69Jn6lBF8FcAl f/Q1uVOAXFH71kldcQhvUNaQt2AUoUgDA9CFNiG+xVrAQngetNbFCz2ZDduBWkltYzIA O/yUr2jPhADNUDoy+8UtkpQh8QQ3XSbPlQtbt/wEdQ3NU5Q/7nWWhSt1lyHW3CXtKqKz v2KpmvmZ/TE9paGu+Up+NeDN4IjbIMZVkdrGhApW8rM/cmTc2HCY7cljGczU0w+ct3Pe sd6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fhxgw1sjLqMS7CqTdoFKMVQKulz+t3CEc2SleEtaktI=; b=Oc2xPcdRdpDFyOuH7v50jqJfFuYViQ0Zp7fONRxOS8qpGMZZh0GapOO4KL6+CKXKGT cQCrFSZb4IlnMJiNd1y6WxeJMsi7PlTgr2EwhgYKU4G2Y4rjbiT8ikDpuxMtRotLYDX9 pjWsxXJP2UaL1ee2SeiNEyu8eB+juw8VR/bFUnXPRW8kpQg/49JqGDx1hmwcXcyoQ5Dq Zz30Q3h0qv1N1NiQchAat4f07P1hS3GI9nWyh+ITaqD39z2Pp/PPrW4KZBO8bzSlsY0H A6axz9C7V/qUFId+EPKHRGS3mW2Hm+Ar5w56h0Ax7zotuRD/jAOmKeodG8O49cN8+kqH QuTw== X-Gm-Message-State: AOAM533VKKdXBmVv6xBr6NpUllkVJ6WftZT31ZNPpx43RJds6w/bUWgU CzMmtXYePXODqs9VjOI4ZGtCuA32/i1LPcBH5mw= X-Google-Smtp-Source: ABdhPJwp+ZgeNjs3mBEm0aiJXrfAmDdnI6eBtts8FYevch18MuxwEWijZ4rpDx4pV94UbCnhX4Tnl36SeC2vjHVjDD4= X-Received: by 2002:a2e:9c97:: with SMTP id x23mr4025489lji.36.1592400964126; Wed, 17 Jun 2020 06:36:04 -0700 (PDT) MIME-Version: 1.0 References: <20200617060841.7241-1-olaf@aepfle.de> In-Reply-To: <20200617060841.7241-1-olaf@aepfle.de> From: Jason Andryuk Date: Wed, 17 Jun 2020 09:35:52 -0400 Message-ID: Subject: Re: [PATCH v1] stubdom/vtpm: add extern to function declarations To: Olaf Hering Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Ian Jackson , Wei Liu , Samuel Thibault Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 2:10 AM Olaf Hering wrote: > > Code compiled with gcc10 will not link properly due to multiple definition of the same function. > > Signed-off-by: Olaf Hering Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:37:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:37:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYFR-0005xU-Vq; Wed, 17 Jun 2020 13:37:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYFQ-0005xL-Jy for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:37:00 +0000 X-Inumbo-ID: 9ea26d9c-b09f-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9ea26d9c-b09f-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 13:37:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 11187AD71; Wed, 17 Jun 2020 13:37:03 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Tamas K Lengyel References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> From: Jan Beulich Message-ID: <17dab1c9-175a-3faa-3937-9102e09f72b0@suse.com> Date: Wed, 17 Jun 2020 15:36:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17.06.2020 15:31, Tamas K Lengyel wrote: > On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote: >> >> On 17.06.2020 15:21, Tamas K Lengyel wrote: >>> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: >>>> >>>> On 17.06.2020 15:00, Tamas K Lengyel wrote: >>>>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: >>>>>> If there are code paths of both kinds, which approach to use in >>>>>> vmx_load_pdptrs() may need to be chosen based on what >>>>>> paging_locked_by_me() returns. Or perhaps an unlocked query is >>>>>> fine in either case? >>>>> >>>>> Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be >>>>> fine. But at that point what is the reason for having the lock >>>>> ordering at all? Why not just have a single recursive lock and avoid >>>>> issues like this altogether? >>>> >>>> With just a single lock, contention problems we already know we >>>> have would be even worse. When the current locking model was >>>> introduced, there was actually a plan to make gfn_lock() more >>>> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for >>>> example. >>> >>> Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an >>> unlocked query doesn't seem as straightforward because, well, there is >>> no unlocked version of p2m_get_page_from_gfn which would also do the >>> "fixups". >> >> Which fixups do we need here, in particular? Of course, whenever >> any fixups get done, the operation can't be lock-less. >> >>> What seems redundant to me though is that >>> hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the >>> paging_lock. Does it really need to take the paging_lock? >> >> From mm-locks.h's comments: >> >> * For HAP, it protects the NPT/EPT tables and mode changes. > > We do the population of the EPT as part of fork_page() if there was a > hole in the p2m when the query was issued using P2M_ALLOC (or > P2M_UNSHARE). I checked and without the paging lock held it throws up > at hap_alloc's ASSERT.. So yea, currently I don't think we have a > better route then what I currently sent in. You didn't answer my question regarding the "fixups" needed, so for the moment it's not clear to me yet whether indeed there's no better way. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:40:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:40:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYIJ-00068k-Dp; Wed, 17 Jun 2020 13:39:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYII-00068d-9C for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:39:58 +0000 X-Inumbo-ID: 080ab7e4-b0a0-11ea-bb8b-bc764e2007e4 Received: from hera.aquilenet.fr (unknown [185.233.100.1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 080ab7e4-b0a0-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 13:39:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id B9434D72; Wed, 17 Jun 2020 15:39:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8GbQ7YFzV9q; Wed, 17 Jun 2020 15:39:55 +0200 (CEST) Received: from function (lfbn-bor-1-797-11.w86-234.abo.wanadoo.fr [86.234.239.11]) by hera.aquilenet.fr (Postfix) with ESMTPSA id 0A43AC25; Wed, 17 Jun 2020 15:39:54 +0200 (CEST) Received: from samy by function with local (Exim 4.94) (envelope-from ) id 1jlYIE-0018V2-6e; Wed, 17 Jun 2020 15:39:54 +0200 Date: Wed, 17 Jun 2020 15:39:54 +0200 From: Samuel Thibault To: Olaf Hering Subject: Re: [PATCH v1] stubdom/vtpmmgr: simplify handling of hardware_version Message-ID: <20200617133954.f5s6znsgmhccndw3@function> Mail-Followup-To: Samuel Thibault , Olaf Hering , xen-devel@lists.xenproject.org, Daniel De Graaf , Quan Xu References: <20200617061349.7623-1-olaf@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200617061349.7623-1-olaf@aepfle.de> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Daniel De Graaf , Quan Xu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Olaf Hering, le mer. 17 juin 2020 08:13:49 +0200, a ecrit: > int hw_is_tpm2(void) > { > - return (hardware_version.hw_version == TPM2_HARDWARE) ? 1 : 0; > + return hardware_version == 2 ? 1 : 0; > } Or even return hardware_version == 2; ? Either case, Acked-by: Samuel Thibault Thanks! Samuel From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:40:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:40:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYJ3-0006pX-O5; Wed, 17 Jun 2020 13:40:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYJ2-0006pQ-S3 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:40:44 +0000 X-Inumbo-ID: 233e8158-b0a0-11ea-b9eb-12813bfff9fa Received: from hera.aquilenet.fr (unknown [185.233.100.1]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 233e8158-b0a0-11ea-b9eb-12813bfff9fa; Wed, 17 Jun 2020 13:40:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id CFAC9459; Wed, 17 Jun 2020 15:40:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at aquilenet.fr Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyPocBMOFRCV; Wed, 17 Jun 2020 15:40:41 +0200 (CEST) Received: from function (lfbn-bor-1-797-11.w86-234.abo.wanadoo.fr [86.234.239.11]) by hera.aquilenet.fr (Postfix) with ESMTPSA id AEDA711BE; Wed, 17 Jun 2020 15:40:26 +0200 (CEST) Received: from samy by function with local (Exim 4.94) (envelope-from ) id 1jlYIj-0018VO-Ob; Wed, 17 Jun 2020 15:40:25 +0200 Date: Wed, 17 Jun 2020 15:40:25 +0200 From: Samuel Thibault To: Jason Andryuk Subject: Re: [PATCH v1] stubdom/vtpm: add extern to function declarations Message-ID: <20200617134025.2tdrjxslnh66dmng@function> Mail-Followup-To: Samuel Thibault , Jason Andryuk , Olaf Hering , xen-devel , Ian Jackson , Wei Liu References: <20200617060841.7241-1-olaf@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Olaf Hering , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jason Andryuk, le mer. 17 juin 2020 09:35:52 -0400, a ecrit: > On Wed, Jun 17, 2020 at 2:10 AM Olaf Hering wrote: > > > > Code compiled with gcc10 will not link properly due to multiple definition of the same function. > > > > Signed-off-by: Olaf Hering > > Reviewed-by: Jason Andryuk Acked-by: Samuel Thibault Thanks! From xen-devel-bounces@lists.xenproject.org Wed Jun 17 13:44:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 13:44:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYMU-00071w-7Y; Wed, 17 Jun 2020 13:44:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYMS-00071r-Lk for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 13:44:16 +0000 X-Inumbo-ID: a284ec0e-b0a0-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a284ec0e-b0a0-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 13:44:16 +0000 (UTC) Received: by mail-wm1-x343.google.com with SMTP id b82so1931471wmb.1 for ; Wed, 17 Jun 2020 06:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lMz7IY7gl+Mkkhi+dR4UBtN/vHs57WZ7F9rIUGsGv9o=; b=ddjYeJnXtgoL2057ezHIaqpugx56p5lA3jxs5JedSe+ln0MR9euUqZ+E5spzG8qeGZ Vc43kpC3GxO+RHacXjnWnEy75f5nvOc0aSNxqMw+M2xW2Q5oqZC5F44U3hhx7dxhpphB KAsW74BLUMZV7XI15hJxWgIBHLY0LBPsHkDWWNQk62nD5+KZkUyNAS+b6m1PtMTcAnSK USjzp9MxLoExb5IG+39V05SLwuSkWfIfMlEgAE2Zg//dlj84x9WyuqrZyUSxtAEELQwB GtcITtxXB8MgrXjs+I9GyhyITjwXM4LGJF6h4VpFCDEaMH1W02RDOJppklEQIw6nTKHt uWCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lMz7IY7gl+Mkkhi+dR4UBtN/vHs57WZ7F9rIUGsGv9o=; b=lWL1x2unUhsqefp2waMju3+UOalCbumciq6oQNobM9sxJRRZbYUasLT85yQNVQ22rh ADxM0lNwGlQ6jACmWkQyEtZElBXkMpSlYLS+V58as8T0ncD9+v+eBZW5P2rSO5LfcUBs P4rr4QMqrZfIAV12l8FR0DheQnTxhCqXs5vFLKeKMMhnrg61PicKFuIOkwI81NIQh6Ni JfM7VneyMFXsJet0QR8hbfvSfLY6O90qmUkPYvYl/9aE2X5Kz8wx2PxraZY6df06KUgS 9vgvTPszPwgfN4GS/45aVJ38TBG/pZncBW+PxgCBZqe/hhUE4HI6N2mrTfwlEPEO5PIx Rktw== X-Gm-Message-State: AOAM532P3abIF6xFmAw7/MB98coDapTBeL4zJODLYT5COzbEdih/E6Ck VQEytjr9dS6OMs33n3CB1MPt8baAxhL4Ae6QIFE= X-Google-Smtp-Source: ABdhPJyf+BbSPnqED8cGTkOJq9ZzWfpBNNmROsNY4sqW9wc5bk312nsgFWmNL4HVtFKouql9IMLjymaLxGynUgW7y8M= X-Received: by 2002:a1c:964d:: with SMTP id y74mr9103273wmd.154.1592401454470; Wed, 17 Jun 2020 06:44:14 -0700 (PDT) MIME-Version: 1.0 References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> <17dab1c9-175a-3faa-3937-9102e09f72b0@suse.com> In-Reply-To: <17dab1c9-175a-3faa-3937-9102e09f72b0@suse.com> From: Tamas K Lengyel Date: Wed, 17 Jun 2020 07:43:38 -0600 Message-ID: Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote: > > On 17.06.2020 15:31, Tamas K Lengyel wrote: > > On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote: > >> > >> On 17.06.2020 15:21, Tamas K Lengyel wrote: > >>> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: > >>>> > >>>> On 17.06.2020 15:00, Tamas K Lengyel wrote: > >>>>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: > >>>>>> If there are code paths of both kinds, which approach to use in > >>>>>> vmx_load_pdptrs() may need to be chosen based on what > >>>>>> paging_locked_by_me() returns. Or perhaps an unlocked query is > >>>>>> fine in either case? > >>>>> > >>>>> Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be > >>>>> fine. But at that point what is the reason for having the lock > >>>>> ordering at all? Why not just have a single recursive lock and avoid > >>>>> issues like this altogether? > >>>> > >>>> With just a single lock, contention problems we already know we > >>>> have would be even worse. When the current locking model was > >>>> introduced, there was actually a plan to make gfn_lock() more > >>>> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for > >>>> example. > >>> > >>> Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an > >>> unlocked query doesn't seem as straightforward because, well, there is > >>> no unlocked version of p2m_get_page_from_gfn which would also do the > >>> "fixups". > >> > >> Which fixups do we need here, in particular? Of course, whenever > >> any fixups get done, the operation can't be lock-less. > >> > >>> What seems redundant to me though is that > >>> hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the > >>> paging_lock. Does it really need to take the paging_lock? > >> > >> From mm-locks.h's comments: > >> > >> * For HAP, it protects the NPT/EPT tables and mode changes. > > > > We do the population of the EPT as part of fork_page() if there was a > > hole in the p2m when the query was issued using P2M_ALLOC (or > > P2M_UNSHARE). I checked and without the paging lock held it throws up > > at hap_alloc's ASSERT.. So yea, currently I don't think we have a > > better route then what I currently sent in. > > You didn't answer my question regarding the "fixups" needed, so > for the moment it's not clear to me yet whether indeed there's > no better way. Umm, I did. The fixups entail populating the EPT from the parent as I described above. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 14:24:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 14:24:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYzG-0001yK-9V; Wed, 17 Jun 2020 14:24:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYzE-0001y0-Vx for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 14:24:21 +0000 X-Inumbo-ID: 380b2252-b0a6-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 380b2252-b0a6-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 14:24:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cExZkRDo/iO0LB9gcjLECHFKJQyBrR8Lobt6JfQD6yo=; b=rVNI7qBg0NFAmXrN1fadovXhT RNmyaq4IiWgRgGgJneo67RY3lx3M9QJfOdzWOXyJ5uxoXnnIsMrklvvFdXTesGb/jWwMqJMyl+N5k sajS15qvVZwskD7zhh7+fYG6JbDbVGH8lRk/tyfW3X0kz6Mdt9Yj6qqQkgsBrQ0H3rA0U=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYz7-0004lK-Le; Wed, 17 Jun 2020 14:24:13 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlYz7-0001SD-9s; Wed, 17 Jun 2020 14:24:13 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlYz7-0004nG-8q; Wed, 17 Jun 2020 14:24:13 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 151163: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.10-testing:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression xen-4.10-testing:test-amd64-amd64-pygrub:debian-di-install:fail:regression xen-4.10-testing:test-amd64-i386-xl-raw:debian-di-install:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-i386-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-amd64-libvirt:libvirt-build:fail:regression xen-4.10-testing:build-arm64-libvirt:libvirt-build:fail:regression xen-4.10-testing:test-armhf-armhf-xl-credit2:guest-start/debian.repeat:fail:regression xen-4.10-testing:build-armhf-libvirt:libvirt-build:fail:regression xen-4.10-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=fd6e49ecae03840610fdc6a416a638590c0b6535 X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Wed, 17 Jun 2020 14:24:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151163 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151163/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386-prev 6 xen-build fail REGR. vs. 150039 build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039 build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039 build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 150039 build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 150039 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 150039 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen fd6e49ecae03840610fdc6a416a638590c0b6535 baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 42 days Failing since 150941 2020-06-09 17:05:34 Z 7 days 9 attempts Testing same since 151163 2020-06-16 02:57:33 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Jan Beulich Jeremi Piotrowski John Thomson Julien Grall Krzysztof Kolasa Marek Marczykowski-Górecki Mark Pryor Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail build-arm64-libvirt fail build-armhf-libvirt fail build-i386-libvirt fail build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 fail test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub fail test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw fail test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 301 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 17 14:24:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 14:24:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYzO-0001z3-M9; Wed, 17 Jun 2020 14:24:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlYzM-0001yv-JG for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 14:24:28 +0000 X-Inumbo-ID: 3fdfdb3a-b0a6-11ea-b9f3-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3fdfdb3a-b0a6-11ea-b9f3-12813bfff9fa; Wed, 17 Jun 2020 14:24:27 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 07EC0AD72; Wed, 17 Jun 2020 14:24:29 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Tamas K Lengyel References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> <17dab1c9-175a-3faa-3937-9102e09f72b0@suse.com> From: Jan Beulich Message-ID: <15ff55e0-2b75-b1dd-9fa5-3b50f7aa8d9c@suse.com> Date: Wed, 17 Jun 2020 16:24:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17.06.2020 15:43, Tamas K Lengyel wrote: > On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote: >> >> On 17.06.2020 15:31, Tamas K Lengyel wrote: >>> On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote: >>>> >>>> On 17.06.2020 15:21, Tamas K Lengyel wrote: >>>>> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: >>>>>> >>>>>> On 17.06.2020 15:00, Tamas K Lengyel wrote: >>>>>>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: >>>>>>>> If there are code paths of both kinds, which approach to use in >>>>>>>> vmx_load_pdptrs() may need to be chosen based on what >>>>>>>> paging_locked_by_me() returns. Or perhaps an unlocked query is >>>>>>>> fine in either case? >>>>>>> >>>>>>> Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be >>>>>>> fine. But at that point what is the reason for having the lock >>>>>>> ordering at all? Why not just have a single recursive lock and avoid >>>>>>> issues like this altogether? >>>>>> >>>>>> With just a single lock, contention problems we already know we >>>>>> have would be even worse. When the current locking model was >>>>>> introduced, there was actually a plan to make gfn_lock() more >>>>>> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for >>>>>> example. >>>>> >>>>> Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an >>>>> unlocked query doesn't seem as straightforward because, well, there is >>>>> no unlocked version of p2m_get_page_from_gfn which would also do the >>>>> "fixups". >>>> >>>> Which fixups do we need here, in particular? Of course, whenever >>>> any fixups get done, the operation can't be lock-less. >>>> >>>>> What seems redundant to me though is that >>>>> hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the >>>>> paging_lock. Does it really need to take the paging_lock? >>>> >>>> From mm-locks.h's comments: >>>> >>>> * For HAP, it protects the NPT/EPT tables and mode changes. >>> >>> We do the population of the EPT as part of fork_page() if there was a >>> hole in the p2m when the query was issued using P2M_ALLOC (or >>> P2M_UNSHARE). I checked and without the paging lock held it throws up >>> at hap_alloc's ASSERT.. So yea, currently I don't think we have a >>> better route then what I currently sent in. >> >> You didn't answer my question regarding the "fixups" needed, so >> for the moment it's not clear to me yet whether indeed there's >> no better way. > > Umm, I did. The fixups entail populating the EPT from the parent as I > described above. Isn't this taken care of by the new call to get_gfn_type() which you add? As said before, I think at the point we want to obtain the PDPTs all other adjustments and arrangements should have been done already, by higher layers. This code should have no need to do anything beyond a simple lookup. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 14:29:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 14:29:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZ42-0002EY-8v; Wed, 17 Jun 2020 14:29:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZ41-0002ET-Rv for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 14:29:17 +0000 X-Inumbo-ID: ec266c56-b0a6-11ea-b7bb-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ec266c56-b0a6-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 14:29:16 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: tXawYVhJi4rmpuc0VBfdOaNDN2PVWsyFKEqGMhzZ95FoDydYUpd51AKDKoUkuiNPV1lgCKu3PO TKT3uc5KO99sQ1CkFDtYYOVQQJ9egA+U0SpTFSSuBiV1xD0+uC5MxHfLDE2fLC38BR7rkUhfDd WYM3uQpDZdSHLuAcO29tHWGUmSGtO1WA9K2OQ68m1zsn9AG44qzJSGX5kjNfEU7wQsQy3G0LE3 4YKCkHFx+mr5fYC/KERv14LCEXQmBDBPX1pwG16ecieWLOKtewbonMFegPi4Gha58xkWCVgLYy pl0= X-SBRS: 2.7 X-MesageID: 21059693 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,522,1583211600"; d="scan'208";a="21059693" Date: Wed, 17 Jun 2020 16:29:08 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes Message-ID: <20200617142908.GC735@Air-de-Roger> References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <20200617082340.GV735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 06:49:16AM -0600, Tamas K Lengyel wrote: > On Wed, Jun 17, 2020 at 2:25 AM Roger Pau Monné wrote: > > > > On Tue, Jun 16, 2020 at 12:31:06PM -0700, Tamas K Lengyel wrote: > > > While forking VMs running a small RTOS systems (Zephyr) a Xen crash has been > > > observed due to a mm-lock order violation while copying the HVM CPU context > > > from the parent. This issue has been identified to be due to > > > hap_update_paging_modes getting a lock on the gfn using get_gfn. This call also > > > creates a shared entry in the fork's memory map for the cr3 gfn. The function > > > later calls hap_update_cr3 while holding the paging_lock, which results in the > > > lock-order violation in vmx_load_pdptrs when it tries to unshare the above entry. > > > > > > This issue has not affected VMs running other OS's as a call to vmx_load_pdptrs > > > is benign if PAE is not enabled or if EFER_LMA is set and returns before > > > trying to unshare and map the page. > > > > > > Using get_gfn_type to get a lock on the gfn avoids this problem as we can > > > populate the fork's gfn with a copied page instead of a shared entry if its > > > needed, thus avoiding the lock order violation while holding paging_lock. > > > > > > Signed-off-by: Tamas K Lengyel > > > --- > > > The bug seems to have been present since commit 4cb6c4f4941, only discovered > > > now due to the heavy use of mem_sharing with VM forks. As this is a simple > > > bug-fix it would be nice to include it in the 4.14 release. > > > > I agree it seems like a candidate bugfix to be included. I've added > > Paul to the Cc so he is aware. > > > > > --- > > > xen/arch/x86/mm/hap/hap.c | 17 ++++++++++++----- > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c > > > index 7f84d0c6ea..9ae4c3ae6e 100644 > > > --- a/xen/arch/x86/mm/hap/hap.c > > > +++ b/xen/arch/x86/mm/hap/hap.c > > > @@ -748,12 +748,19 @@ static void hap_update_paging_modes(struct vcpu *v) > > > struct domain *d = v->domain; > > > unsigned long cr3_gfn = v->arch.hvm.guest_cr[3] >> PAGE_SHIFT; > > > p2m_type_t t; > > > + p2m_query_t q = P2M_ALLOC; > > > > > > - /* We hold onto the cr3 as it may be modified later, and > > > - * we need to respect lock ordering. No need for > > > - * checks here as they are performed by vmx_load_pdptrs > > > - * (the potential user of the cr3) */ > > > - (void)get_gfn(d, cr3_gfn, &t); > > > + /* > > > + * We hold onto the cr3 as it may be modified later, and > > > + * we need to respect lock ordering. Unshare here if we have to as to avoid > > > + * a lock-order violation later while we are holding the paging_lock. > > > + * Further checks are performed by vmx_load_pdptrs (the potential user of > > > + * the cr3). > > > + */ > > > + if ( hvm_pae_enabled(v) && !hvm_long_mode_active(v) ) > > > + q |= P2M_UNSHARE; > > > + > > > + (void)get_gfn_type(d, cr3_gfn, &t, q); > > > > While there I think you can drop the cast to void. > > Sure. > > > > > In order for this to be more resilient, maybe it would be better to > > just use get_gfn_unshare directly and avoid checking what paging mode > > the guest is currently using? > > > > Or would that be too expensive in terms of performance for the not > > affected case? > > That's what I originally considered sending in but yes, in the fuzzing > case it would mean a full-page copy for each iteration even on > unaffected cases instead of a one-time shared entry setup. That would > be a considerable waste. Right, I'm afraid I don't really like the implementation details of vmx_load_pdptrs leaking into hap_update_paging_modes which is a generic function, so IMO a cleaner solution would be to always use P2M_UNSHARE. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Wed Jun 17 14:29:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 14:29:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZ4I-0002Gd-Ic; Wed, 17 Jun 2020 14:29:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZ4H-0002Fq-Uz for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 14:29:33 +0000 X-Inumbo-ID: f30ecb9e-b0a6-11ea-b9f3-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f30ecb9e-b0a6-11ea-b9f3-12813bfff9fa; Wed, 17 Jun 2020 14:29:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=E8iNmU7G+JdRadaU33um9Y1eetN7gbjGTG51XjFJ8I8=; b=TlOOjHmDuO8sRTtDYSJ/suB7i mYd39zqrHaIc1c4pPjGQ2z74bRgOLPag17kfrhmb/Vw318qeNJL0S1kI/jfXIqFSu6wkSVxfpohBx TnZnreXmXvUq3R+2eKw2bS9Ic2DVQbwpuhACu+VBZwVQVotofDK34iyRvZaqIYigg7Kvw=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZ4B-0004rq-8g; Wed, 17 Jun 2020 14:29:27 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlZ4A-0001as-LE; Wed, 17 Jun 2020 14:29:26 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlZ4A-0007xK-Kc; Wed, 17 Jun 2020 14:29:26 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151165: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=1eabe312ea4fa80922443ad73a950857c1f87786 X-Osstest-Versions-That: libvirt=63d08bec0b2dace2fcefffb23a1fa5b14c473d67 From: osstest service owner Date: Wed, 17 Jun 2020 14:29:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151165 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151165/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151091 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151091 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 1eabe312ea4fa80922443ad73a950857c1f87786 baseline version: libvirt 63d08bec0b2dace2fcefffb23a1fa5b14c473d67 Last test of basis 151091 2020-06-13 20:33:29 Z 3 days Testing same since 151165 2020-06-16 04:18:45 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Daniel P. Berrangé Laine Stump Michal Privoznik Peter Krempa jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 63d08bec0b..1eabe312ea 1eabe312ea4fa80922443ad73a950857c1f87786 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Wed Jun 17 14:45:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 14:45:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZJq-0003wb-2l; Wed, 17 Jun 2020 14:45:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZJo-0003wW-J6 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 14:45:36 +0000 X-Inumbo-ID: 33cd197c-b0a9-11ea-8496-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 33cd197c-b0a9-11ea-8496-bc764e2007e4; Wed, 17 Jun 2020 14:45:35 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id p20so2569549ejd.13 for ; Wed, 17 Jun 2020 07:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m/yTYmzvGFtcBQEKmS/Xh/GNgdePSsbD/508KjACywo=; b=RqVGOyfSrVeas8FRVfJTSlg9mbdJxEIrrPU7+OT4ZK2PKQSHh9HXQ4PS3ksXvaPOu8 LzRKp3A3XKUwBpQr+aKZD2qNA89BE+VnIMi1iRQwrauFle39YYEhYkimdWFO21c73F41 TphO64F2kV+jLJ21fpxAbL4daTy5WPGAFkhgNQqTxkxKcsUlPjElpJQ3fnQR+VwWwAoF eW/sotwvS9wYbG7AB4lBUO1qNyPpom8dtc1ZP0fFgl/zI9f085o4I1Rg/B7T1bXR/7Eb ZJBV1xknmoDVJRIQOmo7ZzCSy+O1V5gXru8MLI8P7WJ95dgzjGxeyEvuyoMTThLOQXnc IenA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m/yTYmzvGFtcBQEKmS/Xh/GNgdePSsbD/508KjACywo=; b=sLm82PrVShUrt1BPJ8iPWeJULqbwb18udY/mCp97BBbXei4qGXn9d4Nk/biucKV0jV pcANfgmGPMufzroX2MbCDbELh8WqRGN3kOhg/Ty3nGs2hLDbVzRDiVans42X4qXy/0aL Ckqsq0wsh68ffqXZj1cOXTV9GdtN+fi/5dGEH5IdqDn3VYZBl2SbfQYWvBU1JK2EtBIV wyXvOHMzj3SMcKtzmhJu/4WA322QBlOIfbeN7HbV5JmFbb3u68tT798MnnHjnP5DLKcC Pz3uYVBCt5jEmTYiqUYHscIcb2qQ8ycEzlSkHjjNdTcJkTiTRSp27AWePL2kFTdKSIFy 5PFA== X-Gm-Message-State: AOAM532ck7+/WFQRpN4GlnGHqzeC1luVHTEbcKWXkyVHy9kBYBjsLZfy 0bgyzAJNrYyTraxN20qzGA3toRrJcIbxKYVUEhk= X-Google-Smtp-Source: ABdhPJwNeRoE4PzD0OzZnE8QsGMbHIQMzpIn0fEOIrCHnEyG0RXaJzMPs0vvY6vdjGdAlHHZyNKYdkKXMm1ARhRqZ6Q= X-Received: by 2002:a17:906:fa86:: with SMTP id lt6mr8296147ejb.148.1592405134931; Wed, 17 Jun 2020 07:45:34 -0700 (PDT) MIME-Version: 1.0 References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> In-Reply-To: From: CodeWiz2280 Date: Wed, 17 Jun 2020 10:45:21 -0400 Message-ID: Subject: Re: Keystone Issue To: Marc Zyngier Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Bertrand Marquis , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote: > > On 2020-06-16 19:13, CodeWiz2280 wrote: > > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: > >> > >> On 2020-06-15 20:14, CodeWiz2280 wrote: > >> > >> [...] > >> > >> > Also, the latest linux kernel still has the X-Gene storm distributor > >> > address as "0x78010000" in the device tree, which is what the Xen code > >> > considers a match with the old firmware. What were the addresses for > >> > the device tree supposed to be changed to? > >> > >> We usually don't care, as the GIC address is provided by the > >> bootloader, > >> whether via DT or ACPI (this is certainly what happens on Mustang). > >> Whatever is still in the kernel tree is just as dead as the platform > >> it > >> describes. > >> > >> > Is my understanding > >> > correct that there is a different base address required to access the > >> > "non-secure" region instead of the "secure" 0x78010000 region? I'm > >> > trying to see if there are corresponding different addresses for the > >> > keystone K2E, but haven't found them yet in the manuals. > >> > >> There is no such address. Think of the NS bit as an *address space* > >> identifier. > >> > >> The only reason XGene presents the NS part of the GIC at a different > >> address is because XGene is broken enough not to have EL3, hence no > >> secure mode. To wire the GIC (and other standard ARM IPs) to the core, > >> the designers simply used the CPU NS signal as an address bit. > >> > >> On your platform, the NS bit does exist. I strongly suppose that it > >> isn't wired to the GIC. Please talk to your SoC vendor for whether iot > >> is possible to work around this. > >> > > I do have a question about this out to TI, but at least this method > > gives me something to work with in the meantime. I was just looking > > to confirm that there wouldn't be any other undesirable side effects > > with Dom0 or DomU when using it. Was there an actual FPGA for the > > X-Gene that needed to be updated which controlled the GIC access? Or > > by firmware do you mean the boot loader (e.g. uboot). Thanks for the > > support so far to all. > > As I said, the specific case of XGene was just a matter of picking the > right address, as the NS bit is used as an address bit on this platform. > This was possible because this machine doesn't have any form of > security. So no HW was changed, no FPGA reprogrammed. Only a firmware > table was fixed to point to the right spot. Not even u-boot or EFI was > changed. Ok, thank you for clarifying. I have one more question if you don't mind. I'm aware that dom0 can share physical memory with dom1 via grant tables. However, is it possible to reserve a chunk of contiguous physical memory and directly allocate it only to dom1? For example, if I wanted dom1 to have access to 8MB of contiguous memory at 0x8200_0000 (in addition to whatever virtual memory Xen gives it). How would one go about doing this on ARM? Is there something in the guest config or device tree that can be set? Thanks for you help. > > M. > -- > Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Wed Jun 17 14:46:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 14:46:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZKE-0003yE-Bd; Wed, 17 Jun 2020 14:46:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZKC-0003y2-JI for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 14:46:00 +0000 X-Inumbo-ID: 4213a3f2-b0a9-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4213a3f2-b0a9-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 14:45:59 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id e1so2640870wrt.5 for ; Wed, 17 Jun 2020 07:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qaPksoMYV4W5KRf8pWPz0C86FQ7Z7ocvZ0a8hefIads=; b=Lr0fiEcFAWI7opZuCHAYoUAPajimerwNLrdBWF7fU/Sv0eeEKNrgmH+hiHNAGLujun ggMsdk2wWb0G5iSDoU8cYBMcQs84dhHcZ9FivzK43LRTdRsp5rCWEO24b7HVCeQE5SDu EKbyu43eAWU8bpeYcoO1PX12micjYHtQzKELp1wiOkcaQv/8GdbPiibcF8JvV3z8QBxz wxwz0MzjTJzXh26zLn4zp3eBDAOX7x+yzX3L/YO0Al4RVyjvhfs+AT+BGbUnRZMPTh7T 92TghzqpveKK4mHsjagkaSo82my4vCtzNKCwn2995Oc2nRCQDd+jslC4KgBT/E1uirF2 z7PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qaPksoMYV4W5KRf8pWPz0C86FQ7Z7ocvZ0a8hefIads=; b=uUwgIPYeokDWhJKMrHo0K19oerBfaEM60D3gn1p2L6viLu+kOIICKu8+R9VoTkZDYw SPzCw6GVDMAaE2rySTv56+fUS0tVTMam3cMRVnVrNixLjflyIOMlExQCvogZaFJHcNmc 20xXGLEyuf7OQiWTDPkv4sjPhkQ0Kea6LmQo9mHa6wRfKRLqS7yJJEquR9u9dZCfeHuv Uzugwv3edIvemvwzcfkxtADmBHdJk6R1uuHYsYFMCO8+45Jw+nIiUSYB1Q80TLniHm/b AhhrCOvUZVaITAbZYRCqFKy1hPmdNYyYqvzQWqpHu/W1RM8iQ96lQ+Q7Y4zKWc/v4qEw E5kw== X-Gm-Message-State: AOAM531Tte8w7JUoeti7SpPJVnMZovPGTQXHcFobtQHKZUuVUnxNgkhi HleegsX/W/NTsDOEBL/t39ubT0oQ43U8eoefH8E= X-Google-Smtp-Source: ABdhPJxLvRXLnFLTMSNUas6eyQpairvkKT6t09gkCKL+OlEpjDooxRuvD9+O2igNHWjUX3Ltjf6Ojm93yV/6Zj57bi4= X-Received: by 2002:a5d:490f:: with SMTP id x15mr8713685wrq.259.1592405158815; Wed, 17 Jun 2020 07:45:58 -0700 (PDT) MIME-Version: 1.0 References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <20200617082340.GV735@Air-de-Roger> <20200617142908.GC735@Air-de-Roger> In-Reply-To: <20200617142908.GC735@Air-de-Roger> From: Tamas K Lengyel Date: Wed, 17 Jun 2020 08:45:22 -0600 Message-ID: Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 8:29 AM Roger Pau Monn=C3=A9 = wrote: > > On Wed, Jun 17, 2020 at 06:49:16AM -0600, Tamas K Lengyel wrote: > > On Wed, Jun 17, 2020 at 2:25 AM Roger Pau Monn=C3=A9 wrote: > > > > > > On Tue, Jun 16, 2020 at 12:31:06PM -0700, Tamas K Lengyel wrote: > > > > While forking VMs running a small RTOS systems (Zephyr) a Xen crash= has been > > > > observed due to a mm-lock order violation while copying the HVM CPU= context > > > > from the parent. This issue has been identified to be due to > > > > hap_update_paging_modes getting a lock on the gfn using get_gfn. Th= is call also > > > > creates a shared entry in the fork's memory map for the cr3 gfn. Th= e function > > > > later calls hap_update_cr3 while holding the paging_lock, which res= ults in the > > > > lock-order violation in vmx_load_pdptrs when it tries to unshare th= e above entry. > > > > > > > > This issue has not affected VMs running other OS's as a call to vmx= _load_pdptrs > > > > is benign if PAE is not enabled or if EFER_LMA is set and returns b= efore > > > > trying to unshare and map the page. > > > > > > > > Using get_gfn_type to get a lock on the gfn avoids this problem as = we can > > > > populate the fork's gfn with a copied page instead of a shared entr= y if its > > > > needed, thus avoiding the lock order violation while holding paging= _lock. > > > > > > > > Signed-off-by: Tamas K Lengyel > > > > --- > > > > The bug seems to have been present since commit 4cb6c4f4941, only d= iscovered > > > > now due to the heavy use of mem_sharing with VM forks. As this is a= simple > > > > bug-fix it would be nice to include it in the 4.14 release. > > > > > > I agree it seems like a candidate bugfix to be included. I've added > > > Paul to the Cc so he is aware. > > > > > > > --- > > > > xen/arch/x86/mm/hap/hap.c | 17 ++++++++++++----- > > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c > > > > index 7f84d0c6ea..9ae4c3ae6e 100644 > > > > --- a/xen/arch/x86/mm/hap/hap.c > > > > +++ b/xen/arch/x86/mm/hap/hap.c > > > > @@ -748,12 +748,19 @@ static void hap_update_paging_modes(struct vc= pu *v) > > > > struct domain *d =3D v->domain; > > > > unsigned long cr3_gfn =3D v->arch.hvm.guest_cr[3] >> PAGE_SHIF= T; > > > > p2m_type_t t; > > > > + p2m_query_t q =3D P2M_ALLOC; > > > > > > > > - /* We hold onto the cr3 as it may be modified later, and > > > > - * we need to respect lock ordering. No need for > > > > - * checks here as they are performed by vmx_load_pdptrs > > > > - * (the potential user of the cr3) */ > > > > - (void)get_gfn(d, cr3_gfn, &t); > > > > + /* > > > > + * We hold onto the cr3 as it may be modified later, and > > > > + * we need to respect lock ordering. Unshare here if we have t= o as to avoid > > > > + * a lock-order violation later while we are holding the pagin= g_lock. > > > > + * Further checks are performed by vmx_load_pdptrs (the potent= ial user of > > > > + * the cr3). > > > > + */ > > > > + if ( hvm_pae_enabled(v) && !hvm_long_mode_active(v) ) > > > > + q |=3D P2M_UNSHARE; > > > > + > > > > + (void)get_gfn_type(d, cr3_gfn, &t, q); > > > > > > While there I think you can drop the cast to void. > > > > Sure. > > > > > > > > In order for this to be more resilient, maybe it would be better to > > > just use get_gfn_unshare directly and avoid checking what paging mode > > > the guest is currently using? > > > > > > Or would that be too expensive in terms of performance for the not > > > affected case? > > > > That's what I originally considered sending in but yes, in the fuzzing > > case it would mean a full-page copy for each iteration even on > > unaffected cases instead of a one-time shared entry setup. That would > > be a considerable waste. > > Right, I'm afraid I don't really like the implementation details of > vmx_load_pdptrs leaking into hap_update_paging_modes which is a > generic function, so IMO a cleaner solution would be to always use > P2M_UNSHARE. That's not an acceptable route due to the overhead it brings to unaffected use-cases. I find this reasoning for a purely style preference we are willing to sacrifice performance. In that case I'm going to stop sending fixes upstream and simply carry patches out-of-tree. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 14:49:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 14:49:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZNt-0004CN-0u; Wed, 17 Jun 2020 14:49:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZNs-0004CI-4R for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 14:49:48 +0000 X-Inumbo-ID: c9a6c81c-b0a9-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c9a6c81c-b0a9-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 14:49:47 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id t194so2297363wmt.4 for ; Wed, 17 Jun 2020 07:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hSWpm274MPGhOCPHV9mk3fhBFTpLNIA6HEiBY41YUdo=; b=MdKXT6wgSeFrUTirZPZj5kv8cAVPehhILlAcMhokolJXU+9aRhc9MJWQjE4Vy7nkE5 A1+mpUrziomGcZDVGLc+mf1LDhlmvp9e4+VuLoidXqCuQuZ5ovX3VLTc7LJIVGIPEry4 2j2QLtV+RrBhAkjBir711w6GonknWsjBNt3D2Uioe4cbnTczRqZX1iZgwujypXwPQ+sf /esZbHa5Xkp4nZFs4LW8LaJv0lVs0qDgrE8r/p2PWo6hGfT4GZS2kEPsN0YKBQUxAsMl qPmVJ/3POi/qPV+8QW/hUAeKfNRzCDY7Ks6gYZzgEtF+iiJ1VDrd9SBji33tEC+nvDYN D/jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hSWpm274MPGhOCPHV9mk3fhBFTpLNIA6HEiBY41YUdo=; b=RLISRybBxmHIe65zmhm8rEWIe2Ua7JEqmLsTCEAOUtmXij2i7Dggr/fq5b/5bf4O7e eUJvtLjF5MgkCp6/+J9/KoSzSPenW6Ledn8mOhQffWvmjAbOFOtPJ2g+TPoF7EPTXZgo 6JhofQSylxACX/7d7m5a6ZijVinlvm2olItCTtJ1UkjgkQhTN39ABtfu8LhHXI6d4U9/ GqeJpRrUpNbPu3jwAWwGDXAq35DKjUv55t/Ngj1Ys8nrQFKzDAJoHYGliVUV0/sdCabF IZUKH0MwLANToZCvmatlCO07HVUMgOZXeelKwOuh1CdRbUFB+XQaz2Ll59TvKpYh+/I9 xAjQ== X-Gm-Message-State: AOAM5338KbFhmBTT48c4BK4oyl003htNOC8dlJjMNQAhJzN5F15+T0SF BCOT0R8QXVsj51zxMhEhENuBOgetv7qwHdfQBQg= X-Google-Smtp-Source: ABdhPJw+lwxcbYKaZnIS5Nw5QURsMU3JNds59ZdJUbhZ8M/6lPIWo06k66oDna5bFBX1eWjfth64h9QhDIJIOTcxpP0= X-Received: by 2002:a05:600c:2294:: with SMTP id 20mr9425055wmf.51.1592405386306; Wed, 17 Jun 2020 07:49:46 -0700 (PDT) MIME-Version: 1.0 References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> <17dab1c9-175a-3faa-3937-9102e09f72b0@suse.com> <15ff55e0-2b75-b1dd-9fa5-3b50f7aa8d9c@suse.com> In-Reply-To: <15ff55e0-2b75-b1dd-9fa5-3b50f7aa8d9c@suse.com> From: Tamas K Lengyel Date: Wed, 17 Jun 2020 08:49:10 -0600 Message-ID: Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 8:24 AM Jan Beulich wrote: > > On 17.06.2020 15:43, Tamas K Lengyel wrote: > > On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote: > >> > >> On 17.06.2020 15:31, Tamas K Lengyel wrote: > >>> On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote: > >>>> > >>>> On 17.06.2020 15:21, Tamas K Lengyel wrote: > >>>>> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: > >>>>>> > >>>>>> On 17.06.2020 15:00, Tamas K Lengyel wrote: > >>>>>>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: > >>>>>>>> If there are code paths of both kinds, which approach to use in > >>>>>>>> vmx_load_pdptrs() may need to be chosen based on what > >>>>>>>> paging_locked_by_me() returns. Or perhaps an unlocked query is > >>>>>>>> fine in either case? > >>>>>>> > >>>>>>> Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be > >>>>>>> fine. But at that point what is the reason for having the lock > >>>>>>> ordering at all? Why not just have a single recursive lock and avoid > >>>>>>> issues like this altogether? > >>>>>> > >>>>>> With just a single lock, contention problems we already know we > >>>>>> have would be even worse. When the current locking model was > >>>>>> introduced, there was actually a plan to make gfn_lock() more > >>>>>> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for > >>>>>> example. > >>>>> > >>>>> Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an > >>>>> unlocked query doesn't seem as straightforward because, well, there is > >>>>> no unlocked version of p2m_get_page_from_gfn which would also do the > >>>>> "fixups". > >>>> > >>>> Which fixups do we need here, in particular? Of course, whenever > >>>> any fixups get done, the operation can't be lock-less. > >>>> > >>>>> What seems redundant to me though is that > >>>>> hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the > >>>>> paging_lock. Does it really need to take the paging_lock? > >>>> > >>>> From mm-locks.h's comments: > >>>> > >>>> * For HAP, it protects the NPT/EPT tables and mode changes. > >>> > >>> We do the population of the EPT as part of fork_page() if there was a > >>> hole in the p2m when the query was issued using P2M_ALLOC (or > >>> P2M_UNSHARE). I checked and without the paging lock held it throws up > >>> at hap_alloc's ASSERT.. So yea, currently I don't think we have a > >>> better route then what I currently sent in. > >> > >> You didn't answer my question regarding the "fixups" needed, so > >> for the moment it's not clear to me yet whether indeed there's > >> no better way. > > > > Umm, I did. The fixups entail populating the EPT from the parent as I > > described above. > > Isn't this taken care of by the new call to get_gfn_type() which you add? > As said before, I think at the point we want to obtain the PDPTs all > other adjustments and arrangements should have been done already, by > higher layers. This code should have no need to do anything beyond a > simple lookup. I don't really know what else to say. There are multiple paths leading to vmx_load_pdptrs, some take the paging_lock while some don't. In this particular case we can do the fixups earlier as I do in this patch because there happens to be a lookup before the paging_lock is taken but in other cases there isn't such a route so removing P2M_UNSHARE from vmx_load_pdptrs is not an option. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 15:15:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 15:15:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZm7-0006c7-4J; Wed, 17 Jun 2020 15:14:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZm5-0006c2-Re for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 15:14:49 +0000 X-Inumbo-ID: 48aecb02-b0ad-11ea-b9f5-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 48aecb02-b0ad-11ea-b9f5-12813bfff9fa; Wed, 17 Jun 2020 15:14:48 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: QTcOO6OqT59JxABZcSZ+l2UW6aTZ3UkOgqrrW/A8ICzqXAEEixBuIxDM0wCIGvtFGziSHJQRd4 b02YZ7f5XnL3G9JIARxNDR67lcCuiH+AV+ncKS23sH+bG7rBRcT8TwBUUVAx3VmkN4dA5pRdFX yogZMpnU28dAfZN3xNGkwv6+MbdqomXMDbAZ0EXwXcMWZIiQl0L/idNwSbPGk2j6kqRaZH1EvM NkD6Ra1+CFxM3iAPocu/ZOmtfseSZfFR2JgPoOsmNz0WlHiqyJMfCttKyVp8NxRyjDXeCvmo5O NAA= X-SBRS: 2.7 X-MesageID: 20629293 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,523,1583211600"; d="scan'208";a="20629293" Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> <20200616173857.GU735@Air-de-Roger> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> <20200617090942.GY735@Air-de-Roger> <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> <20200617125146.GA735@Air-de-Roger> From: Andrew Cooper Message-ID: <5ad138bb-9195-a8de-5566-468db553422e@citrix.com> Date: Wed, 17 Jun 2020 16:14:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200617125146.GA735@Air-de-Roger> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , luwei.kang@intel.com, Jun Nakajima , Wei Liu , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17/06/2020 13:51, Roger Pau Monné wrote: > On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote: >> ----- 17 cze 2020 o 11:09, Roger Pau Monné roger.pau@citrix.com napisał(a): >> >>> 24 Virtual Machine Control Structures -> 24.8 VM-entry Control Fields -> 24.8.1 VM-Entry Controls >>> Software should consult the VMX capability MSRs IA32_VMX_ENTRY_CTLS to determine how it should set the reserved bits. >> Please look at bit position 18 "Load IA32_RTIT_CTL". > I think this is something different from what I was referring to. > Those options you refer to (load/clear IA32_RTIT_CTL) deal with > loading/storing a specific field on the vmcs that maps to the guest > IA32_RTIT_CTL. > > OTOH MSR load lists can be used to load and store any arbitrary MSR on > vmentry/vmexit, see section 26.4 LOADING MSRS on the SDM. There's > already infrastructure on Xen to do so, see vmx_{add/del/find}_msr. If I remember the historic roadmaps correctly, there are 3 cases. The first hardware to support PT (Broadwell?) prohibited its use completely in VMX operations.  In this case, we can use it to trace PV guests iff we don't enable VMX in hardware to begin with. This was relaxed in later hardware (Skylake?) to permit use within VMX operations, but without any help in the VMCS.  (i.e. manual context switching per this patch, or MSR load lists as noted in the SDM.) Subsequent support for "virtualised PT" was added (IceLake?) which adds the load/save controls, and the ability to translate the output buffer under EPT. All of this is from memory so I'm quite possibly wrong with details, but I believe this is why the current complexity exists. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 17 15:25:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 15:25:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZwN-0007VE-5D; Wed, 17 Jun 2020 15:25:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlZwL-0007V9-H5 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 15:25:25 +0000 X-Inumbo-ID: c3f5b130-b0ae-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c3f5b130-b0ae-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 15:25:25 +0000 (UTC) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 46C3C206FA; Wed, 17 Jun 2020 15:25:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592407524; bh=Nuuzrx+M5/FZDa6ziN9baR7HX4AUzdEo2YtwnRa2ulU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KAP72ynht0+GaLrgI8S1n8pLj/YK4tOU57njEW4JN3NuatnGHlOv14qciYDOU7B/2 QjK1buON5/0iROamO6itgsHICTJLESce3mdQqSbN+O3bUIGXYhCMLFAe4TyQjL2rLN TCMxI0UkUwKZmgWzZumrk5VnOohGifI54Xy53B3Y= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlZwI-003oaL-O3; Wed, 17 Jun 2020 16:25:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 17 Jun 2020 16:25:22 +0100 From: Marc Zyngier To: CodeWiz2280 Subject: Re: Keystone Issue In-Reply-To: References: <8C6A23AE-6C2B-411F-ACAD-F5574211E8ED@arm.com> <14244e49-e1ac-a29d-bbd9-bd4c202bf186@xen.org> <77006AAF-BC3B-4C6E-BDFC-577CF87DE64E@arm.com> <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> User-Agent: Roundcube Webmail/1.4.5 Message-ID: <76414f25f6f1e9f27cfbe482d57d3cb1@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: codewiz2280@gmail.com, julien.grall.oss@gmail.com, Bertrand.Marquis@arm.com, sstabellini@kernel.org, xen-devel@lists.xenproject.org, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Bertrand Marquis , Stefano Stabellini , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-17 15:45, CodeWiz2280 wrote: > On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote: >> >> On 2020-06-16 19:13, CodeWiz2280 wrote: >> > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: >> >> >> >> On 2020-06-15 20:14, CodeWiz2280 wrote: >> >> >> >> [...] >> >> >> >> > Also, the latest linux kernel still has the X-Gene storm distributor >> >> > address as "0x78010000" in the device tree, which is what the Xen code >> >> > considers a match with the old firmware. What were the addresses for >> >> > the device tree supposed to be changed to? >> >> >> >> We usually don't care, as the GIC address is provided by the >> >> bootloader, >> >> whether via DT or ACPI (this is certainly what happens on Mustang). >> >> Whatever is still in the kernel tree is just as dead as the platform >> >> it >> >> describes. >> >> >> >> > Is my understanding >> >> > correct that there is a different base address required to access the >> >> > "non-secure" region instead of the "secure" 0x78010000 region? I'm >> >> > trying to see if there are corresponding different addresses for the >> >> > keystone K2E, but haven't found them yet in the manuals. >> >> >> >> There is no such address. Think of the NS bit as an *address space* >> >> identifier. >> >> >> >> The only reason XGene presents the NS part of the GIC at a different >> >> address is because XGene is broken enough not to have EL3, hence no >> >> secure mode. To wire the GIC (and other standard ARM IPs) to the core, >> >> the designers simply used the CPU NS signal as an address bit. >> >> >> >> On your platform, the NS bit does exist. I strongly suppose that it >> >> isn't wired to the GIC. Please talk to your SoC vendor for whether iot >> >> is possible to work around this. >> >> >> > I do have a question about this out to TI, but at least this method >> > gives me something to work with in the meantime. I was just looking >> > to confirm that there wouldn't be any other undesirable side effects >> > with Dom0 or DomU when using it. Was there an actual FPGA for the >> > X-Gene that needed to be updated which controlled the GIC access? Or >> > by firmware do you mean the boot loader (e.g. uboot). Thanks for the >> > support so far to all. >> >> As I said, the specific case of XGene was just a matter of picking the >> right address, as the NS bit is used as an address bit on this >> platform. >> This was possible because this machine doesn't have any form of >> security. So no HW was changed, no FPGA reprogrammed. Only a firmware >> table was fixed to point to the right spot. Not even u-boot or EFI was >> changed. > Ok, thank you for clarifying. I have one more question if you don't > mind. I'm aware that dom0 can share physical memory with dom1 via > grant tables. > However, is it possible to reserve a chunk of contiguous physical > memory and directly allocate it only to dom1? > For example, if I wanted dom1 to have access to 8MB of contiguous > memory at 0x8200_0000 (in addition to whatever virtual memory Xen > gives it). > How would one go about doing this on ARM? Is there something in the > guest config or device tree that can be set? Thanks for you help. That's a question for someone who understands Xen (KVM maintainer here, sorry). My hunch is that you could simply represent this memory as a device, and map that "device" into the guest. You'd still need Xen to give you the right memory attributes so that you can map it cacheable at Stage-1. M. -- Jazz is not dead. It just smells funny... From xen-devel-bounces@lists.xenproject.org Wed Jun 17 15:47:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 15:47:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaHC-0000kb-0e; Wed, 17 Jun 2020 15:46:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaHA-0000kW-So for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 15:46:56 +0000 X-Inumbo-ID: c2d0a776-b0b1-11ea-b9f7-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c2d0a776-b0b1-11ea-b9f7-12813bfff9fa; Wed, 17 Jun 2020 15:46:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B1CC5AB76; Wed, 17 Jun 2020 15:46:54 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Tamas K Lengyel References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> <17dab1c9-175a-3faa-3937-9102e09f72b0@suse.com> <15ff55e0-2b75-b1dd-9fa5-3b50f7aa8d9c@suse.com> From: Jan Beulich Message-ID: Date: Wed, 17 Jun 2020 17:46:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17.06.2020 16:49, Tamas K Lengyel wrote: > On Wed, Jun 17, 2020 at 8:24 AM Jan Beulich wrote: >> >> On 17.06.2020 15:43, Tamas K Lengyel wrote: >>> On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote: >>>> >>>> On 17.06.2020 15:31, Tamas K Lengyel wrote: >>>>> On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote: >>>>>> >>>>>> On 17.06.2020 15:21, Tamas K Lengyel wrote: >>>>>>> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: >>>>>>>> >>>>>>>> On 17.06.2020 15:00, Tamas K Lengyel wrote: >>>>>>>>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: >>>>>>>>>> If there are code paths of both kinds, which approach to use in >>>>>>>>>> vmx_load_pdptrs() may need to be chosen based on what >>>>>>>>>> paging_locked_by_me() returns. Or perhaps an unlocked query is >>>>>>>>>> fine in either case? >>>>>>>>> >>>>>>>>> Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be >>>>>>>>> fine. But at that point what is the reason for having the lock >>>>>>>>> ordering at all? Why not just have a single recursive lock and avoid >>>>>>>>> issues like this altogether? >>>>>>>> >>>>>>>> With just a single lock, contention problems we already know we >>>>>>>> have would be even worse. When the current locking model was >>>>>>>> introduced, there was actually a plan to make gfn_lock() more >>>>>>>> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for >>>>>>>> example. >>>>>>> >>>>>>> Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an >>>>>>> unlocked query doesn't seem as straightforward because, well, there is >>>>>>> no unlocked version of p2m_get_page_from_gfn which would also do the >>>>>>> "fixups". >>>>>> >>>>>> Which fixups do we need here, in particular? Of course, whenever >>>>>> any fixups get done, the operation can't be lock-less. >>>>>> >>>>>>> What seems redundant to me though is that >>>>>>> hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the >>>>>>> paging_lock. Does it really need to take the paging_lock? >>>>>> >>>>>> From mm-locks.h's comments: >>>>>> >>>>>> * For HAP, it protects the NPT/EPT tables and mode changes. >>>>> >>>>> We do the population of the EPT as part of fork_page() if there was a >>>>> hole in the p2m when the query was issued using P2M_ALLOC (or >>>>> P2M_UNSHARE). I checked and without the paging lock held it throws up >>>>> at hap_alloc's ASSERT.. So yea, currently I don't think we have a >>>>> better route then what I currently sent in. >>>> >>>> You didn't answer my question regarding the "fixups" needed, so >>>> for the moment it's not clear to me yet whether indeed there's >>>> no better way. >>> >>> Umm, I did. The fixups entail populating the EPT from the parent as I >>> described above. >> >> Isn't this taken care of by the new call to get_gfn_type() which you add? >> As said before, I think at the point we want to obtain the PDPTs all >> other adjustments and arrangements should have been done already, by >> higher layers. This code should have no need to do anything beyond a >> simple lookup. > > I don't really know what else to say. There are multiple paths leading > to vmx_load_pdptrs, some take the paging_lock while some don't. In > this particular case we can do the fixups earlier as I do in this > patch because there happens to be a lookup before the paging_lock is > taken but in other cases there isn't such a route so removing > P2M_UNSHARE from vmx_load_pdptrs is not an option. I disagree (because such missing unshare requests could be put elsewhere), but let me ask another question then: Why is it that vmx_load_pdptrs() needs to unshare? The function only reads from the page. Even if the page's content changed later on, we wouldn't care, as there's no coherence of the PDPTRs once loaded. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 17 15:55:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 15:55:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaPC-0001bg-SC; Wed, 17 Jun 2020 15:55:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaPB-0001bb-W2 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 15:55:14 +0000 X-Inumbo-ID: ed8b7cd8-b0b2-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ed8b7cd8-b0b2-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 15:55:13 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id q2so451346wrv.8 for ; Wed, 17 Jun 2020 08:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MoNwf3njTlBZ/VFDDQxE04qDwTVzjSiKlFCrUoJFXUQ=; b=H06cVxC+BUDEUgLVadY5WRpL4ecTpBwRxn+im30IeGoxc2BoaenV2xwfHAI1rktSn6 b/Umfmu5lC3Br7QOB55NoFoG0yr0QiFkCAzfkENohyk1YVd3VNvj4FDjh249eGIJNZUm HNUA63X/XTtMlQ1p2aT2o/G78VQ6gfFDzOC8FVR+0wje0GYtd7EokdJaAu25NniYcOql QqCo0YKXhyw+JorAVD3ALtlJqnCRHupIOePUfLN+oczhXQP5W5bNwIT7VUTaxYSKKkDG 2uEE2C8EqruaTtLNcaDHdVKM8jvOyb/Il1RfqtiYuGpfeZj7zud/mvXl00aF6aR/lxJ0 AerA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MoNwf3njTlBZ/VFDDQxE04qDwTVzjSiKlFCrUoJFXUQ=; b=ZgOA8O2ZEJTp8HtEwJykz62UfkiN11AyEO4mY09jpR1iInTNCW9zHU95X//QwTOFa7 qyRENnhPo63XubVm91cgyWG+24OawzSZfttZE/lvRgVBPgIBmooBVQqap6fQTfQfK9i+ wejxkYMkYvJa//7CwTyUR6Xe2zRqr79xGrFNhiIpSkEtogWXbCDkl+fYydu8UMRJoInE IRmS3wPS+rb7M3PzPgK7SX5+VHbNWEq8yfd75nTCn4w2x8SkDwZrLAKYqVw6xpqWscEr kx+nz1UyJKVvUns+/BnCbSLOSdJXM3YHXg+/byWExN/2tjV2/LJYuBxfItPj09ToXVuG uVTg== X-Gm-Message-State: AOAM532xFRi+3WO6Ytg/WjMJL5Rrf+mhsKhWsGFQC6kqaS30M1h8oDwQ Z6N5m3DAt0ypb2ZjM1YO8BG3T2cKlKELMC7FMkY= X-Google-Smtp-Source: ABdhPJyvc4Vb9ZqcJVfdUupHq2XjS4BDm1vlGL9HZXbHYSAjhWcS/Bm1b+EmXI7TOnuCmhgbEVcpVrecZTskaOwGso4= X-Received: by 2002:adf:e648:: with SMTP id b8mr9485486wrn.386.1592409312018; Wed, 17 Jun 2020 08:55:12 -0700 (PDT) MIME-Version: 1.0 References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> <17dab1c9-175a-3faa-3937-9102e09f72b0@suse.com> <15ff55e0-2b75-b1dd-9fa5-3b50f7aa8d9c@suse.com> In-Reply-To: From: Tamas K Lengyel Date: Wed, 17 Jun 2020 09:54:36 -0600 Message-ID: Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 9:46 AM Jan Beulich wrote: > > On 17.06.2020 16:49, Tamas K Lengyel wrote: > > On Wed, Jun 17, 2020 at 8:24 AM Jan Beulich wrote: > >> > >> On 17.06.2020 15:43, Tamas K Lengyel wrote: > >>> On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote: > >>>> > >>>> On 17.06.2020 15:31, Tamas K Lengyel wrote: > >>>>> On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote: > >>>>>> > >>>>>> On 17.06.2020 15:21, Tamas K Lengyel wrote: > >>>>>>> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: > >>>>>>>> > >>>>>>>> On 17.06.2020 15:00, Tamas K Lengyel wrote: > >>>>>>>>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: > >>>>>>>>>> If there are code paths of both kinds, which approach to use in > >>>>>>>>>> vmx_load_pdptrs() may need to be chosen based on what > >>>>>>>>>> paging_locked_by_me() returns. Or perhaps an unlocked query is > >>>>>>>>>> fine in either case? > >>>>>>>>> > >>>>>>>>> Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be > >>>>>>>>> fine. But at that point what is the reason for having the lock > >>>>>>>>> ordering at all? Why not just have a single recursive lock and avoid > >>>>>>>>> issues like this altogether? > >>>>>>>> > >>>>>>>> With just a single lock, contention problems we already know we > >>>>>>>> have would be even worse. When the current locking model was > >>>>>>>> introduced, there was actually a plan to make gfn_lock() more > >>>>>>>> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for > >>>>>>>> example. > >>>>>>> > >>>>>>> Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an > >>>>>>> unlocked query doesn't seem as straightforward because, well, there is > >>>>>>> no unlocked version of p2m_get_page_from_gfn which would also do the > >>>>>>> "fixups". > >>>>>> > >>>>>> Which fixups do we need here, in particular? Of course, whenever > >>>>>> any fixups get done, the operation can't be lock-less. > >>>>>> > >>>>>>> What seems redundant to me though is that > >>>>>>> hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the > >>>>>>> paging_lock. Does it really need to take the paging_lock? > >>>>>> > >>>>>> From mm-locks.h's comments: > >>>>>> > >>>>>> * For HAP, it protects the NPT/EPT tables and mode changes. > >>>>> > >>>>> We do the population of the EPT as part of fork_page() if there was a > >>>>> hole in the p2m when the query was issued using P2M_ALLOC (or > >>>>> P2M_UNSHARE). I checked and without the paging lock held it throws up > >>>>> at hap_alloc's ASSERT.. So yea, currently I don't think we have a > >>>>> better route then what I currently sent in. > >>>> > >>>> You didn't answer my question regarding the "fixups" needed, so > >>>> for the moment it's not clear to me yet whether indeed there's > >>>> no better way. > >>> > >>> Umm, I did. The fixups entail populating the EPT from the parent as I > >>> described above. > >> > >> Isn't this taken care of by the new call to get_gfn_type() which you add? > >> As said before, I think at the point we want to obtain the PDPTs all > >> other adjustments and arrangements should have been done already, by > >> higher layers. This code should have no need to do anything beyond a > >> simple lookup. > > > > I don't really know what else to say. There are multiple paths leading > > to vmx_load_pdptrs, some take the paging_lock while some don't. In > > this particular case we can do the fixups earlier as I do in this > > patch because there happens to be a lookup before the paging_lock is > > taken but in other cases there isn't such a route so removing > > P2M_UNSHARE from vmx_load_pdptrs is not an option. > > I disagree (because such missing unshare requests could be put > elsewhere), but let me ask another question then: Why is it that > vmx_load_pdptrs() needs to unshare? The function only reads from > the page. Even if the page's content changed later on, we wouldn't > care, as there's no coherence of the PDPTRs once loaded. Ah, I see what you mean. It really just looks like it reads from the page so P2M_ALLOC would suffice. Let me verify. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 15:59:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 15:59:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaTj-0001mG-IP; Wed, 17 Jun 2020 15:59:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaTh-0001mB-R1 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 15:59:53 +0000 X-Inumbo-ID: 948ba59e-b0b3-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 948ba59e-b0b3-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 15:59:53 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id q2so468695wrv.8 for ; Wed, 17 Jun 2020 08:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JCd+sxVc3WHf9M8vNhlh5kXn7lmtWraZ9nU9GyA1H2k=; b=vIL6E6HJaxpKvOnKWjHNw1+5tD9fdf4AaAeH2f9eCk63K5ZkE63irFk2o/HeL94YAU frHRoc3aDztismXohAD04GN0XJc5G/LW94q3humiHc0ktDRL8+qxUVxxNZJw4H1269jq qjfCcWV7nzEBcm9KzA8OraUXTSBIZ+AKkA0ENuo3Y1sWnaOoNmy/qIvlY8EG7lzw7N7X AmTffN9i9JkHdntOx9fSeLt/Zr8kSIlsTGhljw+kBYMNZHk2d0sG1pu4BEHr3m42IgO9 eQ58cZxGIYbppSrNg2zJeTakjsCMevgoivxrNypQccXh9MlVl+y1amXtedC4iEPf2Znz nNEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JCd+sxVc3WHf9M8vNhlh5kXn7lmtWraZ9nU9GyA1H2k=; b=WOx1X7xvsqMbXtxUg2iX5ixoTzvlAd/kvMVgFDOY0iyKMDdJexVlKU8tiQBKH+hZ0f jrCQW58R7OWyk+DCdtMy0S3+wmn9n2JR0bNr1bZKao1jz4cVg6eimeTYr3zNSJ/4u/QO 0g8L+Lv5LKYIVMO70PF8CJHyTUPR1dcRYjUjaCOoJCRMLqBemjQvAUFkFUpJ+bWR0B9E 33FkElElDUaMAi6Uoys7DPGIJw17X1/0BzjijWox5Opi2+jpfshReNblnpM2zWDutkg5 sx7FHt1OTRiAjbBe4TXs/aQ3EF0pqM0YA3GmboshkrPfB/yBgKFwoBSTsSjkZPjxu7PC 3RIg== X-Gm-Message-State: AOAM532jTjhATttWob44pDyGUXoj51rwhoO1OlEIjI3dLS3BET/B/vat 7t/NCQwIZMFi95TCP6v3FDI4vWbi+V1zYKGlX8U= X-Google-Smtp-Source: ABdhPJzOGbex+xZZHM6E5OzUcEyMWLsnOUR2G87CZ8ouZ6SNODIxjqHB/4Xa5OSrH/o//wht7AmeV1sBxxbhEyieswo= X-Received: by 2002:adf:f0c6:: with SMTP id x6mr9932216wro.301.1592409592212; Wed, 17 Jun 2020 08:59:52 -0700 (PDT) MIME-Version: 1.0 References: <6a2ae3bae4a4ad32bc7caecd8af2655a76a9fb19.1592335579.git.tamas.lengyel@intel.com> <4b06e4f3-2b23-359a-9d80-c881016c0d91@suse.com> <47abe61b-76e1-4491-f539-60c427c2ffc8@suse.com> <17dab1c9-175a-3faa-3937-9102e09f72b0@suse.com> <15ff55e0-2b75-b1dd-9fa5-3b50f7aa8d9c@suse.com> In-Reply-To: From: Tamas K Lengyel Date: Wed, 17 Jun 2020 09:59:16 -0600 Message-ID: Subject: Re: [PATCH for-4.14] x86/hap: use get_gfn_type in hap_update_paging_modes To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 9:54 AM Tamas K Lengyel wrote: > > On Wed, Jun 17, 2020 at 9:46 AM Jan Beulich wrote: > > > > On 17.06.2020 16:49, Tamas K Lengyel wrote: > > > On Wed, Jun 17, 2020 at 8:24 AM Jan Beulich wrote: > > >> > > >> On 17.06.2020 15:43, Tamas K Lengyel wrote: > > >>> On Wed, Jun 17, 2020 at 7:36 AM Jan Beulich wrote: > > >>>> > > >>>> On 17.06.2020 15:31, Tamas K Lengyel wrote: > > >>>>> On Wed, Jun 17, 2020 at 7:28 AM Jan Beulich wrote: > > >>>>>> > > >>>>>> On 17.06.2020 15:21, Tamas K Lengyel wrote: > > >>>>>>> On Wed, Jun 17, 2020 at 7:04 AM Jan Beulich wrote: > > >>>>>>>> > > >>>>>>>> On 17.06.2020 15:00, Tamas K Lengyel wrote: > > >>>>>>>>> On Wed, Jun 17, 2020 at 3:59 AM Jan Beulich wrote: > > >>>>>>>>>> If there are code paths of both kinds, which approach to use in > > >>>>>>>>>> vmx_load_pdptrs() may need to be chosen based on what > > >>>>>>>>>> paging_locked_by_me() returns. Or perhaps an unlocked query is > > >>>>>>>>>> fine in either case? > > >>>>>>>>> > > >>>>>>>>> Perhaps adjusting vmx_load_pdptrs to chose the unlocked query would be > > >>>>>>>>> fine. But at that point what is the reason for having the lock > > >>>>>>>>> ordering at all? Why not just have a single recursive lock and avoid > > >>>>>>>>> issues like this altogether? > > >>>>>>>> > > >>>>>>>> With just a single lock, contention problems we already know we > > >>>>>>>> have would be even worse. When the current locking model was > > >>>>>>>> introduced, there was actually a plan to make gfn_lock() more > > >>>>>>>> fine-grained (i.e. not simply "de-generate" to p2m_lock()), for > > >>>>>>>> example. > > >>>>>>> > > >>>>>>> Sigh. Well, I've been checking and adjust vmx_load_pdptrs to use an > > >>>>>>> unlocked query doesn't seem as straightforward because, well, there is > > >>>>>>> no unlocked version of p2m_get_page_from_gfn which would also do the > > >>>>>>> "fixups". > > >>>>>> > > >>>>>> Which fixups do we need here, in particular? Of course, whenever > > >>>>>> any fixups get done, the operation can't be lock-less. > > >>>>>> > > >>>>>>> What seems redundant to me though is that > > >>>>>>> hap_update_paging_modes takes both the p2m_lock via get_gfn PLUS the > > >>>>>>> paging_lock. Does it really need to take the paging_lock? > > >>>>>> > > >>>>>> From mm-locks.h's comments: > > >>>>>> > > >>>>>> * For HAP, it protects the NPT/EPT tables and mode changes. > > >>>>> > > >>>>> We do the population of the EPT as part of fork_page() if there was a > > >>>>> hole in the p2m when the query was issued using P2M_ALLOC (or > > >>>>> P2M_UNSHARE). I checked and without the paging lock held it throws up > > >>>>> at hap_alloc's ASSERT.. So yea, currently I don't think we have a > > >>>>> better route then what I currently sent in. > > >>>> > > >>>> You didn't answer my question regarding the "fixups" needed, so > > >>>> for the moment it's not clear to me yet whether indeed there's > > >>>> no better way. > > >>> > > >>> Umm, I did. The fixups entail populating the EPT from the parent as I > > >>> described above. > > >> > > >> Isn't this taken care of by the new call to get_gfn_type() which you add? > > >> As said before, I think at the point we want to obtain the PDPTs all > > >> other adjustments and arrangements should have been done already, by > > >> higher layers. This code should have no need to do anything beyond a > > >> simple lookup. > > > > > > I don't really know what else to say. There are multiple paths leading > > > to vmx_load_pdptrs, some take the paging_lock while some don't. In > > > this particular case we can do the fixups earlier as I do in this > > > patch because there happens to be a lookup before the paging_lock is > > > taken but in other cases there isn't such a route so removing > > > P2M_UNSHARE from vmx_load_pdptrs is not an option. > > > > I disagree (because such missing unshare requests could be put > > elsewhere), but let me ask another question then: Why is it that > > vmx_load_pdptrs() needs to unshare? The function only reads from > > the page. Even if the page's content changed later on, we wouldn't > > care, as there's no coherence of the PDPTRs once loaded. > > Ah, I see what you mean. It really just looks like it reads from the > page so P2M_ALLOC would suffice. Let me verify. Alright, that works and it's an even better solution as we don't unnecessarily unshare the page even for PAE guests. Thanks, will send v2 shortly, Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 16:19:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 16:19:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlama-0003xy-9I; Wed, 17 Jun 2020 16:19:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlamY-0003xt-P9 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 16:19:22 +0000 X-Inumbo-ID: 4c352a60-b0b6-11ea-8496-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4c352a60-b0b6-11ea-8496-bc764e2007e4; Wed, 17 Jun 2020 16:19:21 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: zq2ehM8fwF58L2dEjXpcOpRHXAr8oODFbTzIxMFCrit3qVo5gwSQuXXv0jv+Vb0P5nCVT7+EVS hnXxKIblzbHy/v9q9LPItditKQ0Vmkq7q6lWt5aVGcZilxD56vWUkl8JCi2LOO1QBBCXiB+YMy AdOcyIQ59piWmLAX4+Nc95+/SrtyeW6FOe/jqjYw3jFL0m3j2t5JGRtJ/SxfKvOzaFNfMMHBMK ZYJ8EVV5bosbREH0JXHOJYcrNMpZeCns0N/KATRgQeYWOP70lETeARb0CqmL4HQDVK0Z7p9scI Sg0= X-SBRS: 2.7 X-MesageID: 20592051 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,523,1583211600"; d="scan'208";a="20592051" Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring To: Tamas K Lengyel References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> From: Andrew Cooper Message-ID: <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> Date: Wed, 17 Jun 2020 17:19:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17/06/2020 04:02, Tamas K Lengyel wrote: > On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper wrote: >> On 16/06/2020 19:47, Michał Leszczyński wrote: >>> ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com napisał(a): >>> >>>> Are there any restrictions on EPT being enabled in the first place? I'm >>>> not aware of any, and in principle we could use this functionality for >>>> PV guests as well (using the CPL filter). Therefore, I think it would >>>> be helpful to not tie the functionality to HVM guests, even if that is >>>> the only option enabled to start with. >>> I think at the moment it's not required to have EPT. This patch series doesn't use any translation feature flags, so the output address is always a machine physical address, regardless of context. I will check if it could be easily used with PV. >> If its trivial to add PV support then please do. If its not, then don't >> feel obliged, but please do at least consider how PV support might look >> in the eventual feature. >> >> (Generally speaking, considering "how would I make this work in other >> modes where it is possible" leads to a better design.) >> >>>> The buffer mapping and creation logic is fairly problematic. Instead of >>>> fighting with another opencoded example, take a look at the IOREQ >>>> server's use of "acquire resource" which is a mapping interface which >>>> supports allocating memory on behalf of the guest, outside of the guest >>>> memory, for use by control tools. >>>> >>>> I think what this wants is a bit somewhere in domain_create to indicate >>>> that external tracing is used for this domain (and allocate whatever >>>> structures/buffers are necessary), acquire resource to map the buffers >>>> themselves, and a domctl for any necessary runtime controls. >>>> >>> I will check this out, this sounds like a good option as it would remove lots of complexity from the existing ipt_enable domctl. >> Xen has traditionally opted for a "and turn this extra thing on >> dynamically" model, but this has caused no end of security issues and >> broken corner cases. >> >> You can see this still existing in the difference between >> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being >> required to chose the number of vcpus for the domain) and we're making >> good progress undoing this particular wart (before 4.13, it was >> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by >> issuing other hypercalls between these two). >> >> There is a lot of settings which should be immutable for the lifetime of >> the domain, and external monitoring looks like another one of these. >> Specifying it at createdomain time allows for far better runtime >> behaviour (you are no longer in a situation where the first time you try >> to turn tracing on, you end up with -ENOMEM because another VM booted in >> the meantime and used the remaining memory), and it makes for rather >> more simple code in Xen itself (at runtime, you can rely on it having >> been set up properly, because a failure setting up will have killed the >> domain already). > I'm not in favor of this being a flag that gets set during domain > creation time. It could certainly be the case that some users would > want this being on from the start till the end but in other cases you > may want to enable it intermittently only for some time in-between > particular events. If it's an on/off flag during domain creation you > pretty much force that choice on the users and while the overhead of > PT is better than say MTF it's certainly not nothing. In case there is > an OOM situation enabling IPT dynamically the user can always just > pause the VM and wait till memory becomes available. There is nothing wrong with having "turn tracing on/off at runtime" hypercalls.  It is specifically what I suggested two posts up in this thread, but it should be limited to the TraceEn bit in RTIT_CTL. What isn't ok is trying to allocate the buffers, write the TOPA, etc on first-enable or first-map, because the runtime complexity of logic like this large, and far too easy to get wrong in security relevant ways. The domain create flag would mean "I wish to use tracing with this domain", and not "I want tracing enabled from the getgo". >>>> What semantics do you want for the buffer becoming full? Given that >>>> debugging/tracing is the goal, I presume "pause vcpu on full" is the >>>> preferred behaviour, rather than drop packets on full? >>>> >>> Right now this is a ring-style buffer and when it would become full it would simply wrap and override the old data. >> How does the consumer spot that the data has wrapped? What happens if >> data starts getting logged, but noone is listening? What happens if the >> consumer exits/crashes/etc and stops listening as a consequence? >> >> It's fine to simply state what will happen, and possibly even "don't do >> that then", but the corner cases do at least need thinking about. > AFAIU the current use-case is predominantly to be used in conjunction > with VMI events where you want to be able to see the trace leading up > to a particular vmexit. So in the case when the buffer is wrapped > in-between events and data is lost that's not really of concern. That's all fine.  I imagine the output here is voluminous, and needs help being cut down as much as possible. On a tangent, I presume you'd like to include VM-fork eventually, which ought to include copying the trace buffer on fork? ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 17 16:19:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 16:19:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlan5-0003zd-Ib; Wed, 17 Jun 2020 16:19:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlan5-0003zX-7u for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 16:19:55 +0000 X-Inumbo-ID: 601d0e12-b0b6-11ea-b9fe-12813bfff9fa Received: from mga02.intel.com (unknown [134.134.136.20]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 601d0e12-b0b6-11ea-b9fe-12813bfff9fa; Wed, 17 Jun 2020 16:19:53 +0000 (UTC) IronPort-SDR: Vz5BfJWgfi17m915PPDvWK3yczsOyPgcVYN6DLWChhEzX3OtlJjBhPZjv4ItZqfc4vr0bvVuR1 +39dA2vUCCZw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 09:19:52 -0700 IronPort-SDR: 4stfDd3SQSjkxnWKfMGK/jTRCLh1RYTXqlkM0QY1yxxu3cNcG+1V/VOB9+E/PvxsMVrXfluH3N 2T+TvKmg31aQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,523,1583222400"; d="scan'208";a="421191345" Received: from emagureg-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.212.104.207]) by orsmga004.jf.intel.com with ESMTP; 17 Jun 2020 09:19:51 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Date: Wed, 17 Jun 2020 09:19:49 -0700 Message-Id: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Jun Nakajima , Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" While forking VMs running a small RTOS system (Zephyr) a Xen crash has been observed due to a mm-lock order violation while copying the HVM CPU context from the parent. This issue has been identified to be due to hap_update_paging_modes first getting a lock on the gfn using get_gfn. This call also creates a shared entry in the fork's memory map for the cr3 gfn. The function later calls hap_update_cr3 while holding the paging_lock, which results in the lock-order violation in vmx_load_pdptrs when it tries to unshare the above entry when it grabs the page with the P2M_UNSHARE flag set. Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure the p2m is properly populated and to avoid the lock-order violation we observed. Signed-off-by: Tamas K Lengyel --- v2: This patch was previously sent as "x86/hap: use get_gfn_type in hap_update_paging_modes" --- xen/arch/x86/hvm/vmx/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index ab19d9424e..cc6d4ece22 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1325,7 +1325,7 @@ static void vmx_load_pdptrs(struct vcpu *v) if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) ) goto crash; - page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE); + page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_ALLOC); if ( !page ) { /* Ideally you don't want to crash but rather go into a wait -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 17 16:23:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 16:23:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaqN-0004pv-2P; Wed, 17 Jun 2020 16:23:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaqM-0004pp-1t for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 16:23:18 +0000 X-Inumbo-ID: d97c3ff8-b0b6-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d97c3ff8-b0b6-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 16:23:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qmp7KriPlTNX+dbyIsz4SSI8efFYX5h0yhnkAvyhYpU=; b=46RT7xRBZ6b5k4OQHzTxiXw21J GeU3XgZ0qBs+6D0TMlhhLnx3WT3VG37CWUciZNccX5o9IpzPBfssgzzYU9R93soTSfYrog0rmLwrE N1K4UDuPMwfCUtejskYBubQROz6ka9qrawQOcL01b2wkMX0BRbF6bza7afM92zk/rzYY=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaqE-0007UR-28; Wed, 17 Jun 2020 16:23:10 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlaqD-0004Or-RZ; Wed, 17 Jun 2020 16:23:09 +0000 Subject: Re: [PATCH 1/2] xen/arm: entry: Place a speculation barrier following an ret instruction To: Stefano Stabellini References: <20200616175913.7368-1-julien@xen.org> <20200616175913.7368-2-julien@xen.org> From: Julien Grall Message-ID: <57696b4d-da83-a4d6-4d82-41a6f6c9174c@xen.org> Date: Wed, 17 Jun 2020 17:23:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: paul@xen.org, Andre.Przywara@arm.com, Julien Grall , Bertrand.Marquis@arm.com, security@xenproject.org, xen-devel@lists.xenproject.org, Volodymyr_Babchuk@epam.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 16/06/2020 22:24, Stefano Stabellini wrote: > On Tue, 16 Jun 2020, Julien Grall wrote: >> From: Julien Grall >> >> Some CPUs can speculate past a RET instruction and potentially perform >> speculative accesses to memory before processing the return. >> >> There is no known gadget available after the RET instruction today. >> However some of the registers (such as in check_pending_guest_serror()) >> may contain a value provided the guest. > ^ by > > >> In order to harden the code, it would be better to add a speculation >> barrier after each RET instruction. The performance is meant to be >> negligeable as the speculation barrier is not meant to be archicturally >> executed. >> >> Note that on arm32, the ldmia instruction will act as a return from the >> function __context_switch(). While the whitepaper doesn't suggest it is >> possible to speculate after the instruction, add preventively a >> speculation barrier after it as well. >> >> This is part of the work to mitigate straight-line speculation. >> >> Signed-off-by: Julien Grall > > Reviewed-by: Stefano Stabellini > > I did a compile-test on the patch too. > > >> --- >> >> I am still unsure whether we preventively should add a speculation barrier >> preventively after all the RET instructions in arm*/lib/. The smc call be >> taken care in a follow-up patch. > > SMC is great to have but it seems to be overkill to do the ones under > lib/. From my understanding, the compiler will add a speculation barrier preventively after each 'ret' when the mitigation are turned on.So it feels to me we want to follow the same approach. Obviously, we can avoid them but I would like to have a justification for not adding them (nothing is overkilled against speculation ;)). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 17 16:27:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 16:27:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlauk-0004yR-L9; Wed, 17 Jun 2020 16:27:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaui-0004yM-TA for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 16:27:48 +0000 X-Inumbo-ID: 7ac7fa32-b0b7-11ea-bb8b-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7ac7fa32-b0b7-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 16:27:47 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id b82so2463558wmb.1 for ; Wed, 17 Jun 2020 09:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YXHpOWeBQgiev/hCsiOwbuwRn+k6Vqsq5BwuVxCq3Uo=; b=Y7ujb9RZhct+nG4S8T0s77cZDkh3a5cFVT/MSM4+i4NOUBmP30hSnnFqWENt2AEE5R 2ufDBn6RBc9gT8t3Mv3A9j6xygppOOttIuYQOLigTVV7n1Qwa8UftYFg9E/l6FDYYMb8 YPBVkMe1aU7yXNpKmBEjyVSCKY/a7XBHlUlDtgtyI8ApSy9Amm2+V9cpEtah4oYMNOHC Ic3MTjOU1oeOXPyHLP7evvQBWbijp7ZuQHSMRPsrLACtqf+185exYAdb+ms92VH17exR Gnj9n5a0yNaikJVSzDRqGdKDkj+6bEVbUnSZxUSpFCQ7fnLIdCOWvz94XiZXYAmo6mSA RjpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YXHpOWeBQgiev/hCsiOwbuwRn+k6Vqsq5BwuVxCq3Uo=; b=NZ7hU1zgcQthK9RG6exHHYC0Oyedqn/B0Y7Ko5PmdPuQIwiqKW1BT58euLIRvfJm5w YvFZ+r62sLTJzOsKOq/RjDNImVNmhkXCQ10o1M8WKk+Ee9rRGRpD+6fg7pt3CKo3MQ2n uIKSYVb0K3kgPTq6/ODkhAOUt+d/PwZ/d8UgF/ABvGiCACxps2+3V5C3633yM6OMhLMm myMHKl5qREb/c+tWnkyzwSwmwSNovyQ+AXvUPVb0tTlrVo/hMLO9tH7/yPONQ4/NblTa unlA8XNpKR1gFI6T9yEXa4RvcG7o//A+euRuHA1g25rgU7PMCxKCLzirD5LADStyFeh1 Hzlw== X-Gm-Message-State: AOAM5312tT7RVCY3elNZOzf2dkn8fYIFD28TKGZO+RCSO5/DYRjlMZoY YNVysW9IF8M+HmmjunJz6639mO1IFyI1yyuIsoI= X-Google-Smtp-Source: ABdhPJwi3HCwBtuMe6WgdWn+DmQtRl2xUBTJAxTg46wXu4g6dc/YJZ9mCMnfJA7rVb/Mu2XWZ7xn8sW7mY1sehsLiaQ= X-Received: by 2002:a1c:23d2:: with SMTP id j201mr9371658wmj.186.1592411266824; Wed, 17 Jun 2020 09:27:46 -0700 (PDT) MIME-Version: 1.0 References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> In-Reply-To: <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> From: Tamas K Lengyel Date: Wed, 17 Jun 2020 10:27:10 -0600 Message-ID: Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring To: Andrew Cooper Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 10:19 AM Andrew Cooper wrote: > > On 17/06/2020 04:02, Tamas K Lengyel wrote: > > On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper wrote: > >> On 16/06/2020 19:47, Micha=C5=82 Leszczy=C5=84ski wrote: > >>> ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com na= pisa=C5=82(a): > >>> > >>>> Are there any restrictions on EPT being enabled in the first place? = I'm > >>>> not aware of any, and in principle we could use this functionality f= or > >>>> PV guests as well (using the CPL filter). Therefore, I think it wou= ld > >>>> be helpful to not tie the functionality to HVM guests, even if that = is > >>>> the only option enabled to start with. > >>> I think at the moment it's not required to have EPT. This patch serie= s doesn't use any translation feature flags, so the output address is alway= s a machine physical address, regardless of context. I will check if it cou= ld be easily used with PV. > >> If its trivial to add PV support then please do. If its not, then don= 't > >> feel obliged, but please do at least consider how PV support might loo= k > >> in the eventual feature. > >> > >> (Generally speaking, considering "how would I make this work in other > >> modes where it is possible" leads to a better design.) > >> > >>>> The buffer mapping and creation logic is fairly problematic. Instea= d of > >>>> fighting with another opencoded example, take a look at the IOREQ > >>>> server's use of "acquire resource" which is a mapping interface whic= h > >>>> supports allocating memory on behalf of the guest, outside of the gu= est > >>>> memory, for use by control tools. > >>>> > >>>> I think what this wants is a bit somewhere in domain_create to indic= ate > >>>> that external tracing is used for this domain (and allocate whatever > >>>> structures/buffers are necessary), acquire resource to map the buffe= rs > >>>> themselves, and a domctl for any necessary runtime controls. > >>>> > >>> I will check this out, this sounds like a good option as it would rem= ove lots of complexity from the existing ipt_enable domctl. > >> Xen has traditionally opted for a "and turn this extra thing on > >> dynamically" model, but this has caused no end of security issues and > >> broken corner cases. > >> > >> You can see this still existing in the difference between > >> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being > >> required to chose the number of vcpus for the domain) and we're making > >> good progress undoing this particular wart (before 4.13, it was > >> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by > >> issuing other hypercalls between these two). > >> > >> There is a lot of settings which should be immutable for the lifetime = of > >> the domain, and external monitoring looks like another one of these. > >> Specifying it at createdomain time allows for far better runtime > >> behaviour (you are no longer in a situation where the first time you t= ry > >> to turn tracing on, you end up with -ENOMEM because another VM booted = in > >> the meantime and used the remaining memory), and it makes for rather > >> more simple code in Xen itself (at runtime, you can rely on it having > >> been set up properly, because a failure setting up will have killed th= e > >> domain already). > > I'm not in favor of this being a flag that gets set during domain > > creation time. It could certainly be the case that some users would > > want this being on from the start till the end but in other cases you > > may want to enable it intermittently only for some time in-between > > particular events. If it's an on/off flag during domain creation you > > pretty much force that choice on the users and while the overhead of > > PT is better than say MTF it's certainly not nothing. In case there is > > an OOM situation enabling IPT dynamically the user can always just > > pause the VM and wait till memory becomes available. > > There is nothing wrong with having "turn tracing on/off at runtime" > hypercalls. It is specifically what I suggested two posts up in this > thread, but it should be limited to the TraceEn bit in RTIT_CTL. > > What isn't ok is trying to allocate the buffers, write the TOPA, etc on > first-enable or first-map, because the runtime complexity of logic like > this large, and far too easy to get wrong in security relevant ways. > > The domain create flag would mean "I wish to use tracing with this > domain", and not "I want tracing enabled from the getgo". Gotcha, that's reasonable. > > >>>> What semantics do you want for the buffer becoming full? Given that > >>>> debugging/tracing is the goal, I presume "pause vcpu on full" is the > >>>> preferred behaviour, rather than drop packets on full? > >>>> > >>> Right now this is a ring-style buffer and when it would become full i= t would simply wrap and override the old data. > >> How does the consumer spot that the data has wrapped? What happens if > >> data starts getting logged, but noone is listening? What happens if t= he > >> consumer exits/crashes/etc and stops listening as a consequence? > >> > >> It's fine to simply state what will happen, and possibly even "don't d= o > >> that then", but the corner cases do at least need thinking about. > > AFAIU the current use-case is predominantly to be used in conjunction > > with VMI events where you want to be able to see the trace leading up > > to a particular vmexit. So in the case when the buffer is wrapped > > in-between events and data is lost that's not really of concern. > > That's all fine. I imagine the output here is voluminous, and needs > help being cut down as much as possible. > > On a tangent, I presume you'd like to include VM-fork eventually, which > ought to include copying the trace buffer on fork? I would eventually like to use it to reconstruct the branch history so we can update AFL's coverage map with that instead of having to do the current breakpoint-singlestep dance. But for that I would only care about the trace starting after the fork, so copying the parent's PT buffer is not needed. We'll also probably only use PT if the branch history is larger than what LBR can hold. I asked Michal to name the hypercall interface "vmtrace" for this reason so we can add other stuff like LBR later using the same interface (which I already implemented in https://github.com/tklengyel/xen/commits/lbr). Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 16:29:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 16:29:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlaw1-00055k-3L; Wed, 17 Jun 2020 16:29:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlavz-00055a-Nf for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 16:29:07 +0000 X-Inumbo-ID: aa58d24e-b0b7-11ea-ba00-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id aa58d24e-b0b7-11ea-ba00-12813bfff9fa; Wed, 17 Jun 2020 16:29:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jLrsrPzOHLeNdjs5Lv1cCzKoy7efXWWlddIdQP7glgs=; b=BlfVYt+m+RUht7VuW5gb1wKLy Wf3cSwTzIjRpwxl9VSBgsTOajtGQYGu793iDKU+80XF3WwK9VBhfurzkw9zUSkFYc0JdTgCrCcd7R ImL/vYEShj3jv4u+hMams4jiD+e3Q7mcWm0kiG0jIlDeflnSfS0Hocvts3J/Z5ASKxQf8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlavy-0007b7-U8; Wed, 17 Jun 2020 16:29:06 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlavy-0007oh-OE; Wed, 17 Jun 2020 16:29:06 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlavy-00016l-NX; Wed, 17 Jun 2020 16:29:06 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151194: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=71ca0e0ad000e690899936327eb09709ab182ade X-Osstest-Versions-That: xen=3625b04991b4d6affadd99d377ab84bac48dfff4 From: osstest service owner Date: Wed, 17 Jun 2020 16:29:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151194 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151194/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 71ca0e0ad000e690899936327eb09709ab182ade baseline version: xen 3625b04991b4d6affadd99d377ab84bac48dfff4 Last test of basis 151167 2020-06-16 09:00:54 Z 1 days Testing same since 151194 2020-06-17 14:00:29 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Ian Jackson jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 3625b04991..71ca0e0ad0 71ca0e0ad000e690899936327eb09709ab182ade -> smoke From xen-devel-bounces@lists.xenproject.org Wed Jun 17 17:24:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 17:24:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlbmt-0001RN-D6; Wed, 17 Jun 2020 17:23:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlbms-0001RI-T2 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 17:23:46 +0000 X-Inumbo-ID: 4c1f2cc0-b0bf-11ea-8496-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4c1f2cc0-b0bf-11ea-8496-bc764e2007e4; Wed, 17 Jun 2020 17:23:45 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: R3mq5HKs5sN7ZN05SiUGXn1Kw8PDbFatJ+xRe5acT9HwTHNwsWFeq39Q8418vch2xwhyUgSZDi NRIQI0tAj1xJsaLUEHP6HanCOeTRxDnZfwFLXfX9tlMuPVpFDeijR1icwFPj30FzGoD3lsbfVp 2DcntngsgGE25/JUD1qd54NzUrmaMhJ96w68ISYd7L4U8qsXpj95B3Vp+Bbsdyi/TOTKOMNbpe 4VRsHraGfSS5Yx0U/gWYGx8k05M48Z+pt3+2Gxnzmvcwdvr5sPp7oHv1/fgqrPDPXLg+3hk/G1 8/M= X-SBRS: 2.7 X-MesageID: 20643545 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,523,1583211600"; d="scan'208";a="20643545" Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring To: Tamas K Lengyel References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> From: Andrew Cooper Message-ID: <2df6eecb-df3b-7f6e-4185-99f4244ed9d1@citrix.com> Date: Wed, 17 Jun 2020 18:23:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17/06/2020 17:27, Tamas K Lengyel wrote: >>>>>> What semantics do you want for the buffer becoming full? Given that >>>>>> debugging/tracing is the goal, I presume "pause vcpu on full" is the >>>>>> preferred behaviour, rather than drop packets on full? >>>>>> >>>>> Right now this is a ring-style buffer and when it would become full it would simply wrap and override the old data. >>>> How does the consumer spot that the data has wrapped? What happens if >>>> data starts getting logged, but noone is listening? What happens if the >>>> consumer exits/crashes/etc and stops listening as a consequence? >>>> >>>> It's fine to simply state what will happen, and possibly even "don't do >>>> that then", but the corner cases do at least need thinking about. >>> AFAIU the current use-case is predominantly to be used in conjunction >>> with VMI events where you want to be able to see the trace leading up >>> to a particular vmexit. So in the case when the buffer is wrapped >>> in-between events and data is lost that's not really of concern. >> That's all fine. I imagine the output here is voluminous, and needs >> help being cut down as much as possible. >> >> On a tangent, I presume you'd like to include VM-fork eventually, which >> ought to include copying the trace buffer on fork? > I would eventually like to use it to reconstruct the branch history so > we can update AFL's coverage map with that instead of having to do the > current breakpoint-singlestep dance. But for that I would only care > about the trace starting after the fork, so copying the parent's PT > buffer is not needed. We'll also probably only use PT if the branch > history is larger than what LBR can hold. I asked Michal to name the > hypercall interface "vmtrace" for this reason so we can add other > stuff like LBR later using the same interface (which I already > implemented in https://github.com/tklengyel/xen/commits/lbr). I was wondering when someone was going to want LBR data like this.  Can't you borrow the LBR-stitching tricks from Linux's perf to recover the call trace even when its deeper than the LBR stack? What about PEBS?  ISTR there is a fairly complicated matrix of which features work in combination. As for naming, we should definitely have something fairly generic.  AFAICT, it would be applicable to ARM's CoreSight facilities as well. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 17 17:59:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 17:59:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlcLZ-0003xJ-85; Wed, 17 Jun 2020 17:59:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlcLY-0003xE-7r for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 17:59:36 +0000 X-Inumbo-ID: 4db8528c-b0c4-11ea-bca7-bc764e2007e4 Received: from userp2130.oracle.com (unknown [156.151.31.86]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4db8528c-b0c4-11ea-bca7-bc764e2007e4; Wed, 17 Jun 2020 17:59:35 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05HHloNU161537; Wed, 17 Jun 2020 17:59:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=a92NKzD+wELPlL5gwVmn6QwX3yrnJrCoSb0A1XwFyf8=; b=i9L+Ut15lVvT20mCi0Nj1r3yQI7IjVLSCiE1OWvmXPR6m5/xK1R30iysRBLTvzr1W+E0 n2x9dRA8elaNK+35AXjwUCSS68iEWHs7A89ZxsahvgtYNEMx6JovtsQ0gzJFwHIqxO/T IUBmqo32N/sfmKIpMn9Kam0NaeCcl4tqLSHu3wdjN3wkV1anQVnpA0+2eXBuwFEnugpI +eRqaPwIqCB50DBLaJGuUevpqzG9bHh/8L/uFd/mqr2ZljSorlTE/1986hN/PkDsm7tb ZeuDQ24a12RqOYszKOXIpp3warlR+YDCBpOX7sKBfAOVN7GvEdOHlfkbNDIx5q0/V+i5 vQ== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 31q65yvuew-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 17 Jun 2020 17:59:33 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05HHlerj026150; Wed, 17 Jun 2020 17:57:32 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 31q65y06nx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Jun 2020 17:57:32 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 05HHvV3e005931; Wed, 17 Jun 2020 17:57:31 GMT Received: from [10.39.247.125] (/10.39.247.125) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Jun 2020 10:57:31 -0700 Subject: Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Souptick Joarder , jgross@suse.com, sstabellini@kernel.org References: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: Date: Wed, 17 Jun 2020 13:57:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9655 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 spamscore=0 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006170141 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9655 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 phishscore=0 adultscore=0 priorityscore=1501 mlxscore=0 spamscore=0 clxscore=1011 mlxlogscore=999 suspectscore=0 impostorscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006170141 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, paul@xen.org, linux-kernel@vger.kernel.org, John Hubbard Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/16/20 11:14 PM, Souptick Joarder wrote: > In 2019, we introduced pin_user_pages*() and now we are converting > get_user_pages*() to the new API as appropriate. [1] & [2] could > be referred for more information. > > [1] Documentation/core-api/pin_user_pages.rst > > [2] "Explicit pinning of user-space pages": > https://lwn.net/Articles/807108/ > > Signed-off-by: Souptick Joarder > Cc: John Hubbard > --- > Hi, > > I have compile tested this patch but unable to run-time test, > so any testing help is much appriciated. > > Also have a question, why the existing code is not marking the > pages dirty (since it did FOLL_WRITE) ? Indeed, seems to me it should. Paul? > > drivers/xen/privcmd.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index a250d11..543739e 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -594,7 +594,7 @@ static int lock_pages( > if (requested > nr_pages) > return -ENOSPC; > =20 > - pinned =3D get_user_pages_fast( > + pinned =3D pin_user_pages_fast( > (unsigned long) kbufs[i].uptr, > requested, FOLL_WRITE, pages); > if (pinned < 0) > @@ -614,10 +614,7 @@ static void unlock_pages(struct page *pages[], uns= igned int nr_pages) > if (!pages) > return; > =20 > - for (i =3D 0; i < nr_pages; i++) { > - if (pages[i]) > - put_page(pages[i]); > - } > + unpin_user_pages(pages, nr_pages); Why are you no longer checking for valid pages? -boris From xen-devel-bounces@lists.xenproject.org Wed Jun 17 18:46:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 18:46:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jld57-00081c-WD; Wed, 17 Jun 2020 18:46:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jld56-00081X-1y for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 18:46:40 +0000 X-Inumbo-ID: e0f2f538-b0ca-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e0f2f538-b0ca-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 18:46:39 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A0F96206DB; Wed, 17 Jun 2020 18:46:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592419598; bh=AZlrV4tr4okvc/a6JtqMjvtsB5OnHTp5BUesZHw/d2A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dobZBLGGYuKTJwyNJUT+Ad5KjHTuwE5BDQOozZpiwPhSXjHXcBWWDUcdoIURxVVw/ uK2NIrZUofZOh2XRJzDaLGru2TbFxXlamq1EGGCmWoiJWBgyi1isvp175VBqnLFLdp 9BrxUfRWkp5K95Qcenj1VCD0NtcRhwsr6rFk1yd0= Date: Wed, 17 Jun 2020 11:46:38 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: CodeWiz2280 Subject: Re: Keystone Issue In-Reply-To: Message-ID: References: <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Marc Zyngier , Bertrand Marquis , xen-devel , nd , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 17 Jun 2020, CodeWiz2280 wrote: > On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote: > > > > On 2020-06-16 19:13, CodeWiz2280 wrote: > > > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: > > >> > > >> On 2020-06-15 20:14, CodeWiz2280 wrote: > > >> > > >> [...] > > >> > > >> > Also, the latest linux kernel still has the X-Gene storm distributor > > >> > address as "0x78010000" in the device tree, which is what the Xen code > > >> > considers a match with the old firmware. What were the addresses for > > >> > the device tree supposed to be changed to? > > >> > > >> We usually don't care, as the GIC address is provided by the > > >> bootloader, > > >> whether via DT or ACPI (this is certainly what happens on Mustang). > > >> Whatever is still in the kernel tree is just as dead as the platform > > >> it > > >> describes. > > >> > > >> > Is my understanding > > >> > correct that there is a different base address required to access the > > >> > "non-secure" region instead of the "secure" 0x78010000 region? I'm > > >> > trying to see if there are corresponding different addresses for the > > >> > keystone K2E, but haven't found them yet in the manuals. > > >> > > >> There is no such address. Think of the NS bit as an *address space* > > >> identifier. > > >> > > >> The only reason XGene presents the NS part of the GIC at a different > > >> address is because XGene is broken enough not to have EL3, hence no > > >> secure mode. To wire the GIC (and other standard ARM IPs) to the core, > > >> the designers simply used the CPU NS signal as an address bit. > > >> > > >> On your platform, the NS bit does exist. I strongly suppose that it > > >> isn't wired to the GIC. Please talk to your SoC vendor for whether iot > > >> is possible to work around this. > > >> > > > I do have a question about this out to TI, but at least this method > > > gives me something to work with in the meantime. I was just looking > > > to confirm that there wouldn't be any other undesirable side effects > > > with Dom0 or DomU when using it. Was there an actual FPGA for the > > > X-Gene that needed to be updated which controlled the GIC access? Or > > > by firmware do you mean the boot loader (e.g. uboot). Thanks for the > > > support so far to all. > > > > As I said, the specific case of XGene was just a matter of picking the > > right address, as the NS bit is used as an address bit on this platform. > > This was possible because this machine doesn't have any form of > > security. So no HW was changed, no FPGA reprogrammed. Only a firmware > > table was fixed to point to the right spot. Not even u-boot or EFI was > > changed. > Ok, thank you for clarifying. I have one more question if you don't > mind. I'm aware that dom0 can share physical memory with dom1 via > grant tables. > However, is it possible to reserve a chunk of contiguous physical > memory and directly allocate it only to dom1? > For example, if I wanted dom1 to have access to 8MB of contiguous > memory at 0x8200_0000 (in addition to whatever virtual memory Xen > gives it). > How would one go about doing this on ARM? Is there something in the > guest config or device tree that can be set? Thanks for you help. There isn't a "proper" way to do it, only a workaround. It is possible to do it by using the iomem option, which is meant for device MMIO regions. We have patches in the Xilinx Xen tree (not upstream) to allow for specifying the cacheability that you want for the iomem mapping so that you can map it as normal memory. This is the latest branch: https://github.com/Xilinx/xen.git xilinx/release-2020.1 The relevant commits are the ones from: https://github.com/Xilinx/xen/commit/a5c76ac1c5dc14d3e9ccedc5c1e7dd2ddc1397b6 to: https://github.com/Xilinx/xen/commit/b4b7e91c1524f9cf530b81b7ba95df2bf50c78e4 You might want to make sure that the page is not used by the normal memory allocator. This document explains how to something along those lines: https://github.com/Xilinx/xen/commit/35f72d9130448272e07466bd73cc30406f33135e From xen-devel-bounces@lists.xenproject.org Wed Jun 17 18:57:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 18:57:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldFj-0000Tv-2E; Wed, 17 Jun 2020 18:57:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldFi-0000Tq-Jo for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 18:57:38 +0000 X-Inumbo-ID: 6879686a-b0cc-11ea-8496-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6879686a-b0cc-11ea-8496-bc764e2007e4; Wed, 17 Jun 2020 18:57:36 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9EB83A3248; Wed, 17 Jun 2020 20:57:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 91040A322D; Wed, 17 Jun 2020 20:57:34 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id WTOIieWGefUJ; Wed, 17 Jun 2020 20:57:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id C3E2EA3248; Wed, 17 Jun 2020 20:57:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8PJVWMppmpYi; Wed, 17 Jun 2020 20:57:33 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9ED81A322D; Wed, 17 Jun 2020 20:57:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 898F0214EE; Wed, 17 Jun 2020 20:57:03 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Rt1YQxcsVDD6; Wed, 17 Jun 2020 20:56:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 080E820C14; Wed, 17 Jun 2020 20:56:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r8Oo0DNfTFnP; Wed, 17 Jun 2020 20:56:57 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id DC8692097A; Wed, 17 Jun 2020 20:56:57 +0200 (CEST) Date: Wed, 17 Jun 2020 20:56:57 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Andrew Cooper Message-ID: <219980918.9257247.1592420217746.JavaMail.zimbra@cert.pl> In-Reply-To: <5ad138bb-9195-a8de-5566-468db553422e@citrix.com> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> <20200616173857.GU735@Air-de-Roger> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> <20200617090942.GY735@Air-de-Roger> <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> <20200617125146.GA735@Air-de-Roger> <5ad138bb-9195-a8de-5566-468db553422e@citrix.com> Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: switch IPT MSRs on vmentry/vmexit Thread-Index: 8Ar+YGljiiLZAD48QNHpW98pP1stQw== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , luwei kang , Jun Nakajima , Wei Liu , Jan Beulich , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 17 cze 2020 o 17:14, Andrew Cooper andrew.cooper3@citrix.com napisa= =C5=82(a): > On 17/06/2020 13:51, Roger Pau Monn=C3=A9 wrote: >> On Wed, Jun 17, 2020 at 01:54:45PM +0200, Micha=C5=82 Leszczy=C5=84ski w= rote: >>> ----- 17 cze 2020 o 11:09, Roger Pau Monn=C3=A9 roger.pau@citrix.com na= pisa=C5=82(a): >>> >>>> 24 Virtual Machine Control Structures -> 24.8 VM-entry Control Fields = -> 24.8.1 >>>> VM-Entry Controls >>>> Software should consult the VMX capability MSRs IA32_VMX_ENTRY_CTLS to= determine >>>> how it should set the reserved bits. >>> Please look at bit position 18 "Load IA32_RTIT_CTL". >> I think this is something different from what I was referring to. >> Those options you refer to (load/clear IA32_RTIT_CTL) deal with >> loading/storing a specific field on the vmcs that maps to the guest >> IA32_RTIT_CTL. >> >> OTOH MSR load lists can be used to load and store any arbitrary MSR on >> vmentry/vmexit, see section 26.4 LOADING MSRS on the SDM. There's >> already infrastructure on Xen to do so, see vmx_{add/del/find}_msr. >=20 > If I remember the historic roadmaps correctly, there are 3 cases. >=20 > The first hardware to support PT (Broadwell?) prohibited its use > completely in VMX operations.=C2=A0 In this case, we can use it to trace = PV > guests iff we don't enable VMX in hardware to begin with. >=20 > This was relaxed in later hardware (Skylake?) to permit use within VMX > operations, but without any help in the VMCS.=C2=A0 (i.e. manual context > switching per this patch, or MSR load lists as noted in the SDM.) >=20 > Subsequent support for "virtualised PT" was added (IceLake?) which adds > the load/save controls, and the ability to translate the output buffer > under EPT. >=20 >=20 > All of this is from memory so I'm quite possibly wrong with details, but > I believe this is why the current complexity exists. >=20 > ~Andrew I've managed to toggle MSR_IA32_RTIT_CTL values using MSR load lists, as in= : > 35.5.2.2 Guest-Only Tracing > "For this usage, VM-entry is programmed to enable trace packet generation= , while VM-exit is programmed to clear MSR_IA32_RTIT_CTL.TraceEn so as to d= isable trace-packet generation in the host." it actually helped a bit. With patch v1 there were parts of hypervisor reco= rded in the trace (i.e. the moment between TRACE_EN being set and actual vm= enter, and the moment between vmexit and TRACE_EN being unset). Using MSR l= oad list this was eliminated. This change will be reflected in patch v2. I can't however implement any working scenario in which all these MSRs are = managed using MSR load lists. As in "35.3.3 Flushing Trace Output": packets= are buffered internally and are flushed only when TRACE_EN bit in MSR_IA32= _RTIT_CTL is set to 0. The values of remaining registers will be stable aft= er everything is serialized. I think this is too complex for the load lists= alone. I belive that currently SDM instructs to use load lists only for to= ggling this single bit on-or-off. Thus, for now I propose to stay with MSR_IA32_RTIT_CTL being managed by MSR= load lists and the rest of related MSRs being managed manually. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Wed Jun 17 19:13:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 19:13:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldVM-000298-J0; Wed, 17 Jun 2020 19:13:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldVL-000293-7u for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 19:13:47 +0000 X-Inumbo-ID: a9e746da-b0ce-11ea-ba16-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a9e746da-b0ce-11ea-ba16-12813bfff9fa; Wed, 17 Jun 2020 19:13:45 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 6957BA2C6C; Wed, 17 Jun 2020 21:13:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 59450A1E06; Wed, 17 Jun 2020 21:13:43 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QcdfFw0QIu1N; Wed, 17 Jun 2020 21:13:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 5A624A2C6C; Wed, 17 Jun 2020 21:13:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Hcot-ETBUUZk; Wed, 17 Jun 2020 21:13:42 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2D3E2A1BE2; Wed, 17 Jun 2020 21:13:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 15A6920755; Wed, 17 Jun 2020 21:13:12 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ltjCRaiJ2KCw; Wed, 17 Jun 2020 21:13:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 021F02097A; Wed, 17 Jun 2020 21:13:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4SqaTcL2sq0T; Wed, 17 Jun 2020 21:13:05 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id CE98A20755; Wed, 17 Jun 2020 21:13:05 +0200 (CEST) Date: Wed, 17 Jun 2020 21:13:05 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> In-Reply-To: <20200616172352.GT735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: 2F7rUJxrX+qiejqyNWQFiyWrG+s5iA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 16 cze 2020 o 19:23, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Tue, Jun 16, 2020 at 05:22:06PM +0200, Micha=C5=82 Leszczy=C5=84ski wr= ote: >> Provide an interface for privileged domains to manage >> external IPT monitoring. >>=20 >> Signed-off-by: Michal Leszczynski >=20 > Thanks for the patch! I have some questions below which require your > input. >=20 >> --- >> xen/arch/x86/hvm/hvm.c | 170 ++++++++++++++++++++++++++++++++ >> xen/include/public/hvm/hvm_op.h | 27 +++++ >> 2 files changed, 197 insertions(+) >>=20 >> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c >> index 5bb47583b3..9292caebe0 100644 >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -4949,6 +4949,172 @@ static int compat_altp2m_op( >> return rc; >> } >> =20 >> +static int do_vmtrace_op( >> + XEN_GUEST_HANDLE_PARAM(void) arg) >=20 > No need for the newline, this can fit on a single line. >=20 >> +{ >> + struct xen_hvm_vmtrace_op a; >> + struct domain *d =3D NULL; >=20 > I don't think you need to init d to NULL (at least by looking at the > current code below). >=20 >> + int rc =3D -EFAULT; >=20 > No need to init rc. >=20 >> + int i; >=20 > unsigned since it's used as a loop counter. >=20 >> + struct vcpu *v; >> + void* buf; >=20 > Nit: '*' should be prepended to the variable name. >=20 >> + uint32_t buf_size; >=20 > size_t >=20 >> + uint32_t buf_order; >=20 > Order is generally fine using unsigned int, no need to use a > specifically sized type. >=20 >> + uint64_t buf_mfn; >=20 > Could this use the mfn type? >=20 >> + struct page_info *pg; >> + >> + if ( !hvm_ipt_supported() ) >> + return -EOPNOTSUPP; >> + >> + if ( copy_from_guest(&a, arg, 1) ) >> + return -EFAULT; >> + >> + if ( a.version !=3D HVMOP_VMTRACE_INTERFACE_VERSION ) >> + return -EINVAL; >> + >> + switch ( a.cmd ) >> + { >> + case HVMOP_vmtrace_ipt_enable: >> + case HVMOP_vmtrace_ipt_disable: >> + case HVMOP_vmtrace_ipt_get_buf: >> + case HVMOP_vmtrace_ipt_get_offset: >> + break; >> + >> + default: >> + return -EOPNOTSUPP; >> + } >> + >> + d =3D rcu_lock_domain_by_any_id(a.domain); >> + >> + if ( d =3D=3D NULL ) >> + return -ESRCH; >> + >> + if ( !is_hvm_domain(d) ) >> + { >> + rc =3D -EOPNOTSUPP; >> + goto out; >> + } >> + >> + domain_pause(d); >> + >> + if ( a.vcpu >=3D d->max_vcpus ) >> + { >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + v =3D d->vcpu[a.vcpu]; >> + >> + if ( a.cmd =3D=3D HVMOP_vmtrace_ipt_enable ) >=20 > Please use a switch here, you might even consider re-using the switch > from above and moving the domain checks before actually checking the > command field, so that you don't need to perform two switches against > a.cmd. >=20 >> + { >> + if ( v->arch.hvm.vmx.ipt_state ) { >=20 > Coding style, brace should be on newline (there are more below which > I'm not going to comment on). >=20 >> + // already enabled >=20 > Comments should use /* ... */, there multiple instances of this below > which I'm not going to comment on, please check CODING_STYLE. >=20 > Also, the interface looks racy, I think you are missing a lock to > protect v->arch.hvm.vmx.ipt_state from being freed under your feet if > you issue concurrent calls to the interface. >=20 >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + if ( a.size < PAGE_SIZE || a.size > 1000000 * PAGE_SIZE ) { >=20 > You can use GB(4) which is easier to read. Should the size also be a > multiple of a PAGE_SIZE? >=20 >> + // we don't accept trace buffer size smaller than single pa= ge >> + // and the upper bound is defined as 4GB in the specificati= on >> + rc =3D -EINVAL; >> + goto out; >> +=09} >=20 > Stray tab. >=20 >> + >> + buf_order =3D get_order_from_bytes(a.size); >> + >> + if ( (a.size >> PAGE_SHIFT) !=3D (1 << buf_order) ) { >=20 > Oh here is the check. I think you can move this with the checks above > by doing a.size & ~PAGE_MASK. I belive it's more strict than a.size & ~PAGE_MASK. I think that CPU expect= s that the buffer size is a power of 2, so you can have 64 MB or 128 MB, bu= t not 96 MB buffer. >=20 >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + buf =3D page_to_virt(alloc_domheap_pages(d, buf_order, >> MEMF_no_refcount)); >=20 > What if alloc_domheap_pages return NULL? >=20 > Since I think you only what the linear address of the page to zero it > I would suggest using clear_domain_page. >=20 Hmm. This was fixed already. Most probably I did something strange with git= and this change was not stored. I will correct this with patch v2. >> + buf_size =3D a.size; >> + >> + if ( !buf ) { >> + rc =3D -EFAULT; >> + goto out; >> + } >> + >> + memset(buf, 0, buf_size); >> + >> + for ( i =3D 0; i < (buf_size >> PAGE_SHIFT); i++ ) { >> + share_xen_page_with_privileged_guests(virt_to_page(buf) + i= , >> SHARE_ro); >=20 > This line (and some more below) exceeds 80 characters, please split > it. >=20 >> + } >> + >> + v->arch.hvm.vmx.ipt_state =3D xmalloc(struct ipt_state); >=20 > You should check that xmalloc has succeeds before trying to access > ipt_state. >=20 >> + v->arch.hvm.vmx.ipt_state->output_base =3D virt_to_mfn(buf) << >> PAGE_SHIFT; >> + v->arch.hvm.vmx.ipt_state->output_mask =3D buf_size - 1; >> + v->arch.hvm.vmx.ipt_state->status =3D 0; >> + v->arch.hvm.vmx.ipt_state->ctl =3D RTIT_CTL_TRACEEN | RTIT_CTL_= OS | >> RTIT_CTL_USR | RTIT_CTL_BRANCH_EN; >=20 > Shouldn't the user be able to select what tracing should be enabled? >=20 >> + } >> + else if ( a.cmd =3D=3D HVMOP_vmtrace_ipt_disable ) >> + { >> + if ( !v->arch.hvm.vmx.ipt_state ) { >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + buf_mfn =3D v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIF= T; >> + buf_size =3D ( v->arch.hvm.vmx.ipt_state->output_mask + 1 ) & >> 0xFFFFFFFFUL; >> + >> + for ( i =3D 0; i < (buf_size >> PAGE_SHIFT); i++ ) >> + { >> + if ( (mfn_to_page(_mfn(buf_mfn + i))->count_info & PGC_coun= t_mask) >> !=3D 1 ) >> + { >> + rc =3D -EBUSY; >> + goto out; >> + } >> + } >> + >> + xfree(v->arch.hvm.vmx.ipt_state); >> +=09v->arch.hvm.vmx.ipt_state =3D NULL; >> + >> + for ( i =3D 0; i < (buf_size >> PAGE_SHIFT); i++ ) >> + { >> + pg =3D mfn_to_page(_mfn(buf_mfn + i)); >> + put_page_alloc_ref(pg); >> + if ( !test_and_clear_bit(_PGC_xen_heap, &pg->count_info) ) >> + ASSERT_UNREACHABLE(); >> + pg->u.inuse.type_info =3D 0; >> + page_set_owner(pg, NULL); >> + free_domheap_page(pg); >=20 > Hm, this seems fairly dangerous, what guarantees that the caller is > not going to map the buffer while you are trying to tear it down? >=20 > You perform a check before freeing ipt_state, but between the check > and the actual tearing down the domain might have setup mappings to > them. >=20 > I wonder, could you expand a bit on why trace buffers are allocated > from domheap memory by Xen? In general, I thought it would be good to account trace buffers for particu= lar DomUs, so it would be easier to troubleshoot the memory usage. >=20 > There are a couple of options here, maybe the caller could provide > it's own buffer, then Xen would take an extra reference to those pages > and setup them to be used as buffers. >=20 > Another alternative would be to use domhep memory but not let the > caller map it directly, and instead introduce a hypercall to copy > from the internal Xen buffer into a user-provided one. >=20 > How much memory is used on average by those buffers? That would help > decide a model that would best fit the usage. >From 4 kB to 4 GB. Right now I use 128 MB buffers and it takes just a few s= econds to fill them up completely. I think I've just copied the pattern which is already present in Xen's code= , e.g. interfaces used by xenbaked/xentrace tools. >=20 >> + } >> + } >> + else if ( a.cmd =3D=3D HVMOP_vmtrace_ipt_get_buf ) >> + { >> + if ( !v->arch.hvm.vmx.ipt_state ) { >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + a.mfn =3D v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT; >=20 > This will not work for translated domains, ie: a PVH or HVM domain > won't be able to use this interface since it has no way to request the > mapping of a specific mfn into it's physmap. I think we need to take > this into account when deciding how the interface should be, so that > we don't corner ourselves with a PV only interface. Please be aware that this is only going to be used by Dom0. Is is well-supp= orted case that somebody is using PVH/HVM Dom0? I think that all Virtual Machine Introspection stuff currently requires to = have Dom0 PV. Our main goal is to have this working well in combo with VMI. >=20 >> + a.size =3D (v->arch.hvm.vmx.ipt_state->output_mask + 1) & 0xFFF= FFFFFUL; >=20 > You can truncate it easier by casting to uint32_t I think. >=20 > Or even better, you could put output_mask in a union like: >=20 > union { > uint64_t raw; > struct { > uint32_t size; >=09uint32_t offset; > } > } >=20 > Then you can avoid the shifting and the castings. >=20 >> + } >> + else if ( a.cmd =3D=3D HVMOP_vmtrace_ipt_get_offset ) >> + { >> + if ( !v->arch.hvm.vmx.ipt_state ) { >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + a.offset =3D v->arch.hvm.vmx.ipt_state->output_mask >> 32; >> + } >> + >> + rc =3D -EFAULT; >> + if ( __copy_to_guest(arg, &a, 1) ) >> + goto out; >> + rc =3D 0; >> + >> + out: >> + smp_wmb(); >=20 > Why do you need a barrier here? >=20 >> + domain_unpause(d); >> + rcu_unlock_domain(d); >> + >> + return rc; >> +} >> + >> +DEFINE_XEN_GUEST_HANDLE(compat_hvm_vmtrace_op_t); >> + >> static int hvmop_get_mem_type( >> XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg) >> { >> @@ -5101,6 +5267,10 @@ long do_hvm_op(unsigned long op, >> XEN_GUEST_HANDLE_PARAM(void) arg) >> rc =3D current->hcall_compat ? compat_altp2m_op(arg) : do_altp2= m_op(arg); >> break; >> =20 >> + case HVMOP_vmtrace: >> + rc =3D do_vmtrace_op(arg); >> + break; >> + >> default: >> { >> gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op); >> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hv= m_op.h >> index 870ec52060..3bbcd54c96 100644 >> --- a/xen/include/public/hvm/hvm_op.h >> +++ b/xen/include/public/hvm/hvm_op.h >> @@ -382,6 +382,33 @@ struct xen_hvm_altp2m_op { >> typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; >> DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); >> =20 >> +/* HVMOP_vmtrace: Perform VM tracing related operation */ >> +#define HVMOP_vmtrace 26 >> + >> +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 >> + >> +struct xen_hvm_vmtrace_op { >> + /* IN variable */ >> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ >> + uint32_t cmd; >> +/* Enable/disable external vmtrace for given domain */ >> +#define HVMOP_vmtrace_ipt_enable 1 >> +#define HVMOP_vmtrace_ipt_disable 2 >> +#define HVMOP_vmtrace_ipt_get_buf 3 >> +#define HVMOP_vmtrace_ipt_get_offset 4 >> + domid_t domain; >=20 > You are missing a padding field here AFAICT. >=20 > Roger. Thanks for your feedback, I will apply all the remaining suggestions in pat= ch v2. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Wed Jun 17 19:24:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 19:24:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldf7-00031r-LN; Wed, 17 Jun 2020 19:23:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldf6-00031X-89 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 19:23:52 +0000 X-Inumbo-ID: 0fbc8fbe-b0d0-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0fbc8fbe-b0d0-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 19:23:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wJuhy9EHQ/AOptvi4Rmdc/tZQPF0tV72u2AwzQ5UR0k=; b=jgREwb31OZvw8P+8Rmbl28dpM Agh3Vfz1ate9MOC0CYYlS5XRUltbHdUenxXq7F287tQfJJTofTGMv3uWlIcJTvrQlbVqonUm8dkLo HQJ0PoM1uoVVbrtn+wTStt/HgH4iRJ+77B94GsdkY7ThP/0MpmbywPJ0qea2mqp9y+pTg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldey-0002SN-QW; Wed, 17 Jun 2020 19:23:44 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jldey-00007S-Im; Wed, 17 Jun 2020 19:23:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jldey-0005S9-Hn; Wed, 17 Jun 2020 19:23:44 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151166: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Wed, 17 Jun 2020 19:23:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151166 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151166/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 43 days Failing since 150942 2020-06-09 17:05:43 Z 8 days 9 attempts Testing same since 151061 2020-06-12 12:25:05 Z 5 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 2b77729888fb851ab96e7f77bc854122626b4861 Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Wed Jun 17 19:31:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 19:31:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldmY-0003s7-IV; Wed, 17 Jun 2020 19:31:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldmX-0003s2-R7 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 19:31:33 +0000 X-Inumbo-ID: 25d5654a-b0d1-11ea-ba16-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 25d5654a-b0d1-11ea-ba16-12813bfff9fa; Wed, 17 Jun 2020 19:31:32 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 36515A30FF; Wed, 17 Jun 2020 21:31:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 249BDA30C3; Wed, 17 Jun 2020 21:31:30 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xTqd_m2GGSEs; Wed, 17 Jun 2020 21:31:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 43DCAA30FF; Wed, 17 Jun 2020 21:31:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Kt6pWg2oZCBv; Wed, 17 Jun 2020 21:31:29 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1D878A30C3; Wed, 17 Jun 2020 21:31:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 00065204FF; Wed, 17 Jun 2020 21:30:58 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id oAHJYeVF9JNv; Wed, 17 Jun 2020 21:30:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D698A209D5; Wed, 17 Jun 2020 21:30:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yqmWjACCgADV; Wed, 17 Jun 2020 21:30:52 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id ABCFE204FF; Wed, 17 Jun 2020 21:30:52 +0200 (CEST) Date: Wed, 17 Jun 2020 21:30:52 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Tamas K Lengyel Message-ID: <11233541.9260387.1592422252636.JavaMail.zimbra@cert.pl> In-Reply-To: References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: BsYEZrJ7asFdwFXtpYfFwvq1Ux0v0g== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 17 cze 2020 o 18:27, Tamas K Lengyel tamas.k.lengyel@gmail.com napisa= =C5=82(a): > On Wed, Jun 17, 2020 at 10:19 AM Andrew Cooper > wrote: >> >> On 17/06/2020 04:02, Tamas K Lengyel wrote: >> > On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper wrote: >> >> On 16/06/2020 19:47, Micha=C5=82 Leszczy=C5=84ski wrote: >> >>> ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com n= apisa=C5=82(a): >> >>> >> >>>> Are there any restrictions on EPT being enabled in the first place?= I'm >> >>>> not aware of any, and in principle we could use this functionality = for >> >>>> PV guests as well (using the CPL filter). Therefore, I think it wo= uld >> >>>> be helpful to not tie the functionality to HVM guests, even if that= is >> >>>> the only option enabled to start with. >> >>> I think at the moment it's not required to have EPT. This patch seri= es doesn't >> >>> use any translation feature flags, so the output address is always a= machine >> >>> physical address, regardless of context. I will check if it could be= easily >> >>> used with PV. >> >> If its trivial to add PV support then please do. If its not, then do= n't >> >> feel obliged, but please do at least consider how PV support might lo= ok >> >> in the eventual feature. >> >> >> >> (Generally speaking, considering "how would I make this work in other >> >> modes where it is possible" leads to a better design.) >> >> >> >>>> The buffer mapping and creation logic is fairly problematic. Inste= ad of >> >>>> fighting with another opencoded example, take a look at the IOREQ >> >>>> server's use of "acquire resource" which is a mapping interface whi= ch >> >>>> supports allocating memory on behalf of the guest, outside of the g= uest >> >>>> memory, for use by control tools. >> >>>> >> >>>> I think what this wants is a bit somewhere in domain_create to indi= cate >> >>>> that external tracing is used for this domain (and allocate whateve= r >> >>>> structures/buffers are necessary), acquire resource to map the buff= ers >> >>>> themselves, and a domctl for any necessary runtime controls. >> >>>> >> >>> I will check this out, this sounds like a good option as it would re= move lots of >> >>> complexity from the existing ipt_enable domctl. >> >> Xen has traditionally opted for a "and turn this extra thing on >> >> dynamically" model, but this has caused no end of security issues and >> >> broken corner cases. >> >> >> >> You can see this still existing in the difference between >> >> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being >> >> required to chose the number of vcpus for the domain) and we're makin= g >> >> good progress undoing this particular wart (before 4.13, it was >> >> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by >> >> issuing other hypercalls between these two). >> >> >> >> There is a lot of settings which should be immutable for the lifetime= of >> >> the domain, and external monitoring looks like another one of these. >> >> Specifying it at createdomain time allows for far better runtime >> >> behaviour (you are no longer in a situation where the first time you = try >> >> to turn tracing on, you end up with -ENOMEM because another VM booted= in >> >> the meantime and used the remaining memory), and it makes for rather >> >> more simple code in Xen itself (at runtime, you can rely on it having >> >> been set up properly, because a failure setting up will have killed t= he >> >> domain already). >> > I'm not in favor of this being a flag that gets set during domain >> > creation time. It could certainly be the case that some users would >> > want this being on from the start till the end but in other cases you >> > may want to enable it intermittently only for some time in-between >> > particular events. If it's an on/off flag during domain creation you >> > pretty much force that choice on the users and while the overhead of >> > PT is better than say MTF it's certainly not nothing. In case there is >> > an OOM situation enabling IPT dynamically the user can always just >> > pause the VM and wait till memory becomes available. >> >> There is nothing wrong with having "turn tracing on/off at runtime" >> hypercalls. It is specifically what I suggested two posts up in this >> thread, but it should be limited to the TraceEn bit in RTIT_CTL. >> >> What isn't ok is trying to allocate the buffers, write the TOPA, etc on >> first-enable or first-map, because the runtime complexity of logic like >> this large, and far too easy to get wrong in security relevant ways. >> >> The domain create flag would mean "I wish to use tracing with this >> domain", and not "I want tracing enabled from the getgo". >=20 > Gotcha, that's reasonable. >=20 I think I also agree with this, i.e. to alloc buffers on domain creation an= d just enable/disable the feature in runtime. This would remove some comple= xity from runtime. I think it's usually (always?) known in advance whether = we would like to use external monitoring on a domain or not. I will try to adapt this approach in patch v2. >> >> >>>> What semantics do you want for the buffer becoming full? Given tha= t >> >>>> debugging/tracing is the goal, I presume "pause vcpu on full" is th= e >> >>>> preferred behaviour, rather than drop packets on full? >> >>>> >> >>> Right now this is a ring-style buffer and when it would become full = it would >> >>> simply wrap and override the old data. >> >> How does the consumer spot that the data has wrapped? What happens i= f >> >> data starts getting logged, but noone is listening? What happens if = the >> >> consumer exits/crashes/etc and stops listening as a consequence? >> >> >> >> It's fine to simply state what will happen, and possibly even "don't = do >> >> that then", but the corner cases do at least need thinking about. >> > AFAIU the current use-case is predominantly to be used in conjunction >> > with VMI events where you want to be able to see the trace leading up >> > to a particular vmexit. So in the case when the buffer is wrapped >> > in-between events and data is lost that's not really of concern. >> >> That's all fine. I imagine the output here is voluminous, and needs >> help being cut down as much as possible. >> >> On a tangent, I presume you'd like to include VM-fork eventually, which >> ought to include copying the trace buffer on fork? >=20 > I would eventually like to use it to reconstruct the branch history so > we can update AFL's coverage map with that instead of having to do the > current breakpoint-singlestep dance. But for that I would only care > about the trace starting after the fork, so copying the parent's PT > buffer is not needed. We'll also probably only use PT if the branch > history is larger than what LBR can hold. I asked Michal to name the > hypercall interface "vmtrace" for this reason so we can add other > stuff like LBR later using the same interface (which I already > implemented in https://github.com/tklengyel/xen/commits/lbr). >=20 > Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 19:32:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 19:32:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldnQ-0003vX-SX; Wed, 17 Jun 2020 19:32:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jldnP-0003vO-Lv for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 19:32:27 +0000 X-Inumbo-ID: 4644580e-b0d1-11ea-8496-bc764e2007e4 Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4644580e-b0d1-11ea-8496-bc764e2007e4; Wed, 17 Jun 2020 19:32:26 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id r7so3629516wro.1 for ; Wed, 17 Jun 2020 12:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+0AWIHIihw/EJzXtpDQw8ECfNVfhi3oNv71yEdx7FQ8=; b=DrcXo5Ya99/PijG+WJ8yk0hODEPQuiMOHbkDcitqCvy0EXZGReS7OGRt2y+QuuoU2m aPLX08ryH9Klt2G9xkCkoo7333FmPYalaiHfA6qTEaPj6TXa3P1QHLkF0vibTzll2U92 lGF+heMnUDKTMQUk8QgLbkJBgt1fU+4cZjTGFjhBdXAvzFCiGphl8XxoUTQgmssswk9+ B0vGD6ToQK8HjlDz/Kvnk0qiExG4e3SBlTKHHuE9LV0kaaxCNjbWa46Gx61zcA024pry ePZGdfcCD+6GWHqMvdcVzK99m44i6CWhWTUuDdu5Q6oF6cXVvpt4dtgitqyS4MwfGSWA dabQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+0AWIHIihw/EJzXtpDQw8ECfNVfhi3oNv71yEdx7FQ8=; b=U75fKWv4MgyMf53Y0cV8EqWFuBhfLpjW3DWOtb77jCYpjySdh+9WeO2PD/ZEbPTDEa BZNSpSh+JAEoJdBGAnkFa30n1zHaf5D0AemU6SITB6DBwfvP/xPeVm380EImnzNH6UKo OZtyvbFrFPxJDtm04BS6XVgNw3tXzWcSi/udPE1Nwel4kHvgAOe5ljS8bkFdL9cPe0Cm ZbgeuLPePVDCZ0SILN8eLKhHmHxjbB25U0OTby08AZT49kDTVLlVabJUvCRbEplI8XDE 4XMmdyAGcRpVXxN9i7VYDhlTDzDQHpsgVHv39ZvlYGsdY6gBU8i0UWV8zz/gx0J3FevS 3dAQ== X-Gm-Message-State: AOAM532VdWci/lI+G/io5snA51K2hH6JpCP/NMT6hqtiiQ0FnKvBUcOP KLMU4fXDhnN72KMJZM6SVWazQr6izXdfp94xwpI= X-Google-Smtp-Source: ABdhPJzRzt6RkYVHAywiJsyEhe5M10zMZfXeAdbbKTHPw2svNxCt0Vq8cKwVQIXM2xJv3pUwMxJR1ETO0jApnwcGamI= X-Received: by 2002:a5d:490f:: with SMTP id x15mr765447wrq.259.1592422345659; Wed, 17 Jun 2020 12:32:25 -0700 (PDT) MIME-Version: 1.0 References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> <2df6eecb-df3b-7f6e-4185-99f4244ed9d1@citrix.com> In-Reply-To: <2df6eecb-df3b-7f6e-4185-99f4244ed9d1@citrix.com> From: Tamas K Lengyel Date: Wed, 17 Jun 2020 13:31:49 -0600 Message-ID: Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring To: Andrew Cooper Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 11:23 AM Andrew Cooper wrote: > > On 17/06/2020 17:27, Tamas K Lengyel wrote: > >>>>>> What semantics do you want for the buffer becoming full? Given that > >>>>>> debugging/tracing is the goal, I presume "pause vcpu on full" is the > >>>>>> preferred behaviour, rather than drop packets on full? > >>>>>> > >>>>> Right now this is a ring-style buffer and when it would become full it would simply wrap and override the old data. > >>>> How does the consumer spot that the data has wrapped? What happens if > >>>> data starts getting logged, but noone is listening? What happens if the > >>>> consumer exits/crashes/etc and stops listening as a consequence? > >>>> > >>>> It's fine to simply state what will happen, and possibly even "don't do > >>>> that then", but the corner cases do at least need thinking about. > >>> AFAIU the current use-case is predominantly to be used in conjunction > >>> with VMI events where you want to be able to see the trace leading up > >>> to a particular vmexit. So in the case when the buffer is wrapped > >>> in-between events and data is lost that's not really of concern. > >> That's all fine. I imagine the output here is voluminous, and needs > >> help being cut down as much as possible. > >> > >> On a tangent, I presume you'd like to include VM-fork eventually, which > >> ought to include copying the trace buffer on fork? > > I would eventually like to use it to reconstruct the branch history so > > we can update AFL's coverage map with that instead of having to do the > > current breakpoint-singlestep dance. But for that I would only care > > about the trace starting after the fork, so copying the parent's PT > > buffer is not needed. We'll also probably only use PT if the branch > > history is larger than what LBR can hold. I asked Michal to name the > > hypercall interface "vmtrace" for this reason so we can add other > > stuff like LBR later using the same interface (which I already > > implemented in https://github.com/tklengyel/xen/commits/lbr). > > I was wondering when someone was going to want LBR data like this. > Can't you borrow the LBR-stitching tricks from Linux's perf to recover > the call trace even when its deeper than the LBR stack? TBH I only spent like an hour putting it together so I haven't investigated the topic too much. But thanks for the tip, first I heard about this LBR-stitching trick ;) > > What about PEBS? ISTR there is a fairly complicated matrix of which > features work in combination. There is also BTS.. I would assume it would take some experimentation to figure out what works and when and in what combination. Right now I have no plans for doing that experimentation or adding support for additional tracers. > > > As for naming, we should definitely have something fairly generic. > AFAICT, it would be applicable to ARM's CoreSight facilities as well. IMHO XEN_DOMCTL_vmtrace would be a good name for controlling these features. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 17 20:21:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 20:21:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jleYT-000833-Qk; Wed, 17 Jun 2020 20:21:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jleYS-00082y-SE for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 20:21:04 +0000 X-Inumbo-ID: 0e81573b-b0d8-11ea-ba1b-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0e81573b-b0d8-11ea-ba1b-12813bfff9fa; Wed, 17 Jun 2020 20:21:00 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 32E92A31B0; Wed, 17 Jun 2020 22:20:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1D8C9A257E; Wed, 17 Jun 2020 22:20:58 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5rrtAS5nqkY2; Wed, 17 Jun 2020 22:20:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 59215A31B0; Wed, 17 Jun 2020 22:20:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3t6qgpzmNbCy; Wed, 17 Jun 2020 22:20:57 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2A431A257E; Wed, 17 Jun 2020 22:20:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 11752211CB; Wed, 17 Jun 2020 22:20:27 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KpI_fyfxAuPZ; Wed, 17 Jun 2020 22:20:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 36E11216F3; Wed, 17 Jun 2020 22:20:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p9VkY0aLObAe; Wed, 17 Jun 2020 22:20:21 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 10586211CB; Wed, 17 Jun 2020 22:20:21 +0200 (CEST) Date: Wed, 17 Jun 2020 22:20:20 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Andrew Cooper Message-ID: <1348695738.9265003.1592425220928.JavaMail.zimbra@cert.pl> In-Reply-To: <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: bh8O+ZWqTow4BMcaNcDUXif7NpLI+w== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 17 cze 2020 o 18:19, Andrew Cooper andrew.cooper3@citrix.com napisa= =C5=82(a): > On 17/06/2020 04:02, Tamas K Lengyel wrote: >> On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper wrote: >>> On 16/06/2020 19:47, Micha=C5=82 Leszczy=C5=84ski wrote: >>>> ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com nap= isa=C5=82(a): >>>> >>>>> Are there any restrictions on EPT being enabled in the first place? = I'm >>>>> not aware of any, and in principle we could use this functionality fo= r >>>>> PV guests as well (using the CPL filter). Therefore, I think it woul= d >>>>> be helpful to not tie the functionality to HVM guests, even if that i= s >>>>> the only option enabled to start with. >>>> I think at the moment it's not required to have EPT. This patch series= doesn't >>>> use any translation feature flags, so the output address is always a m= achine >>>> physical address, regardless of context. I will check if it could be e= asily >>>> used with PV. >>> If its trivial to add PV support then please do. If its not, then don'= t >>> feel obliged, but please do at least consider how PV support might look >>> in the eventual feature. >>> >>> (Generally speaking, considering "how would I make this work in other >>> modes where it is possible" leads to a better design.) >>> >>>>> The buffer mapping and creation logic is fairly problematic. Instead= of >>>>> fighting with another opencoded example, take a look at the IOREQ >>>>> server's use of "acquire resource" which is a mapping interface which >>>>> supports allocating memory on behalf of the guest, outside of the gue= st >>>>> memory, for use by control tools. >>>>> One thing that remains unclear to me is the "acquire resource" part. Could = you give some more details on that? Assuming that buffers are allocated right from the domain creation, what me= chanism (instead of xc_map_foreign_range) should I use to map the IPT buffe= rs into Dom0? >>>>> I think what this wants is a bit somewhere in domain_create to indica= te >>>>> that external tracing is used for this domain (and allocate whatever >>>>> structures/buffers are necessary), acquire resource to map the buffer= s >>>>> themselves, and a domctl for any necessary runtime controls. >>>>> >>>> I will check this out, this sounds like a good option as it would remo= ve lots of >>>> complexity from the existing ipt_enable domctl. >>> Xen has traditionally opted for a "and turn this extra thing on >>> dynamically" model, but this has caused no end of security issues and >>> broken corner cases. >>> >>> You can see this still existing in the difference between >>> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being >>> required to chose the number of vcpus for the domain) and we're making >>> good progress undoing this particular wart (before 4.13, it was >>> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by >>> issuing other hypercalls between these two). >>> >>> There is a lot of settings which should be immutable for the lifetime o= f >>> the domain, and external monitoring looks like another one of these. >>> Specifying it at createdomain time allows for far better runtime >>> behaviour (you are no longer in a situation where the first time you tr= y >>> to turn tracing on, you end up with -ENOMEM because another VM booted i= n >>> the meantime and used the remaining memory), and it makes for rather >>> more simple code in Xen itself (at runtime, you can rely on it having >>> been set up properly, because a failure setting up will have killed the >>> domain already). >> I'm not in favor of this being a flag that gets set during domain >> creation time. It could certainly be the case that some users would >> want this being on from the start till the end but in other cases you >> may want to enable it intermittently only for some time in-between >> particular events. If it's an on/off flag during domain creation you >> pretty much force that choice on the users and while the overhead of >> PT is better than say MTF it's certainly not nothing. In case there is >> an OOM situation enabling IPT dynamically the user can always just >> pause the VM and wait till memory becomes available. >=20 > There is nothing wrong with having "turn tracing on/off at runtime" > hypercalls.=C2=A0 It is specifically what I suggested two posts up in thi= s > thread, but it should be limited to the TraceEn bit in RTIT_CTL. >=20 > What isn't ok is trying to allocate the buffers, write the TOPA, etc on > first-enable or first-map, because the runtime complexity of logic like > this large, and far too easy to get wrong in security relevant ways. >=20 > The domain create flag would mean "I wish to use tracing with this > domain", and not "I want tracing enabled from the getgo". >=20 >>>>> What semantics do you want for the buffer becoming full? Given that >>>>> debugging/tracing is the goal, I presume "pause vcpu on full" is the >>>>> preferred behaviour, rather than drop packets on full? >>>>> >>>> Right now this is a ring-style buffer and when it would become full it= would >>>> simply wrap and override the old data. >>> How does the consumer spot that the data has wrapped? What happens if >>> data starts getting logged, but noone is listening? What happens if th= e >>> consumer exits/crashes/etc and stops listening as a consequence? >>> >>> It's fine to simply state what will happen, and possibly even "don't do >>> that then", but the corner cases do at least need thinking about. >> AFAIU the current use-case is predominantly to be used in conjunction >> with VMI events where you want to be able to see the trace leading up >> to a particular vmexit. So in the case when the buffer is wrapped >> in-between events and data is lost that's not really of concern. >=20 > That's all fine.=C2=A0 I imagine the output here is voluminous, and needs > help being cut down as much as possible. >=20 > On a tangent, I presume you'd like to include VM-fork eventually, which > ought to include copying the trace buffer on fork? >=20 > ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 17 22:29:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 22:29:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlgY9-0000vV-Cp; Wed, 17 Jun 2020 22:28:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlgY7-0000vQ-Lw for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 22:28:51 +0000 X-Inumbo-ID: ea75c224-b0e9-11ea-bb8b-bc764e2007e4 Received: from gordon.huskydog.org.uk (unknown [81.187.95.156]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id ea75c224-b0e9-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 22:28:49 +0000 (UTC) Received: from [10.137.3.12] (percyq.huskydog.org.uk [10.42.42.111]) by gordon.huskydog.org.uk (Postfix) with ESMTP id 987C5B318A; Wed, 17 Jun 2020 23:28:48 +0100 (BST) Subject: Re: ARM - Successful install on RockPro64 To: Julien Grall , Bertrand Marquis References: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> <8013f2db-3732-0679-81f6-7b274b39c44f@xen.org> From: Richard Simpson Message-ID: <49e5b539-145a-726a-fb80-a93e65e44ca0@huskydog.org.uk> Date: Wed, 17 Jun 2020 23:28:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <8013f2db-3732-0679-81f6-7b274b39c44f@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello Julien, I have just tried 4.14-rc2 and it seems to work fine. I think that the most useful page regarding the board is the one for the Ibox3399 since this refers to the RK3399 chip which the RockPro64 uses (shouldn't the page actually be called RK3399 to make it more generic). Perhaps I can most usefully record what I did by updating that page and making sure that the instructions work correctly. If there is additional stuff relevant to the RockPro64 over and above the generic RK3399 info then I'll give some thought to how to best record it.  I will eventually be writing a fuller report on my progress on my blog at funfoodfreedom.huskydog.org.uk. I now need to finish automating the boot process (still requires manual u-boot command) and figure out how to get the console log to work.  Currently I can either see the xen and linux kernel boot messages OR see the dom0 console, but not both.  I then want to wipe the install and start again without all the blind alleys that I went down the first time (mostly a function of my ignorance). This should allow me to clearly document what is actually required from both a Xen and Gentoo perspective. I'll also try to more of the Xen config options to see what works and what is actually needed. On one more related note:  I suspect that Xen would run on the PineBookPro as well as I get the impression that it uses very similar hardware.  Of course that would rely on the GPU etc which I haven't tested at all as I am using the serial console. Finally, when I joined this mailing list I asked for a daily digest.  However I seem to be getting a new digest every hour or so.  Is this right? Regards,     Richard On 6/16/20 11:26 AM, Julien Grall wrote: > Hello, > > On 16/06/2020 09:33, Richard Simpson wrote: >> I would be happy to try to report my success via the smoke test page >> (https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results) >> if I can figure out how.  Strangely, I can't see anything listed >> under "Test Results" from anyone else.  Perhaps it is a problem with >> my browser. > This is not a browser problem :). In the past, we did attempt to list > all the boards we know works on a given version of Xen. But this never > really gain any momentum. > > If there is any specific setup you need for your board (e.g. > non-upstream kernel, a new U-boot...), then I would suggest to create > a new page with steps to boot Xen the platform. You can have a look > how we list the other boards in [1]. > >> >> I also notice an instruction which reads "Test hypervisor >> functionalities: clone raisin on the platform and run ./raise test".  >> I can try to do this if it will help.  Do I just run "git clone > from web page>" and then presumably the test prints out some results? > > It is just meant to be an easy way to test basic functionality of Xen > (e.g booting a guest). You seem to have done it manually, so it should > be sufficient. > >> >> Happy to try a beta version of Xen if you decide to include the patch >> and I can also try some of the interrupt config options if you want. > > The patch should already be included in xen 4.14-rc2. Would you mind > to give a spin? > > Best regards, > > [1] > https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions > From xen-devel-bounces@lists.xenproject.org Wed Jun 17 23:30:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 23:30:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlhVP-0006Sc-4m; Wed, 17 Jun 2020 23:30:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlhVO-0006Ox-4c for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 23:30:06 +0000 X-Inumbo-ID: 7841eb98-b0f2-11ea-b7bb-bc764e2007e4 Received: from mga14.intel.com (unknown [192.55.52.115]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7841eb98-b0f2-11ea-b7bb-bc764e2007e4; Wed, 17 Jun 2020 23:30:04 +0000 (UTC) IronPort-SDR: dZpLAHVXOx0EZRmVKRVjvDs2ykDPabbixeE9dfu+qxAdOiF+kw7lJ0drKvraZtoogRtsEDxQOx 2ctg6ljBaZbA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 16:30:02 -0700 IronPort-SDR: PptEuZ2UZYUbLPDgRhGTrwxs1DP58y5WCUXbKXdAf3NwgBGW2qeb2DufAz4HCrBXKu9CZclvFj aYZWb70rOh8w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,523,1583222400"; d="scan'208";a="277437060" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga006.jf.intel.com with ESMTP; 17 Jun 2020 16:30:01 -0700 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 17 Jun 2020 16:30:01 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 17 Jun 2020 16:30:00 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 17 Jun 2020 16:30:00 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.170) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 17 Jun 2020 16:30:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OMSgwHCa9oE0NDJw20SbewPdTDj6DF+qhq+f94h5Cd003S68zKyAqE2Z/zTuIuqgAbFICxAzP8stGvOEZAKFjV/oZQEQs0raDO+U/vTPgpjPB2KWk9VUB47DMf103cKNWO4MNGwaKuWqYt1UAuzp+Oy13wjqAItNF9F0PzEUm8tsKOYfrG5+xKiFQFpJugHyKebadR809dmp05qYyQC6WG6gvT8xHS7jjGhN4kbYBVAAgL3OPQAGuxXA32WK2UunU4ZnYh6w0uMwetE62wYiETuzFh3qD9o0hLB+UVkf5aPvbA+J6VtfrEVyasp2NexUJ91eCkGH9P9tsusDv9ftQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=08dvXD0VOFNYFfzaJYFsjbsUJIMlXCK9Yu42D5i9cfs=; b=QmR50JfAGmsbB/o0LRjNOVc5lhp9hcvl7kaG+IX1uMxlnc0wgueOzj/Xh3U5jsJ4MAPeUGRaxAZGgddjQHhyyzRiqW2ZrkjhfWyj9Ed7bHX0+08v6kxXRCsutur+nrl0BB/wDDkdnWhjbUOvVBpRA02Bx1cAFUNJQVLlaSF7xlw1tnM/WMzxpekv8Kz1i0wZ6QMj0q2HxZpfVcNlxNYUmgUsOaCmLzxWX9QLQWnT46ZELTBgO986nMVCIPNiLJzzvRyMq/jFM/ZfF1AVG+4Pv3uSKMqnuMUGhQfJGNGrn90nzmhCrHWsb819lRr67DM36fBExzuFTBSAq/NROC8kxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=08dvXD0VOFNYFfzaJYFsjbsUJIMlXCK9Yu42D5i9cfs=; b=Qz2XnRhqkr6eokoHlszIMM6AdYgLkCS2I/L795rKrIt5sl4IWLIY3D/WX69G6C4CrfitEtWlztFUkNULNqS5BKcFjt8sa9d0dFHGXdUCNmj4zhWIeFZjlDD9Axs5kJlvt6sI9Xy7mbKljYL0j3WT0C8Djk5LF9FCLr5yoDT7zm0= Received: from DM5PR1101MB2266.namprd11.prod.outlook.com (2603:10b6:4:57::17) by DM5PR11MB1306.namprd11.prod.outlook.com (2603:10b6:3:b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Wed, 17 Jun 2020 23:29:58 +0000 Received: from DM5PR1101MB2266.namprd11.prod.outlook.com ([fe80::b07e:e40:d34e:b601]) by DM5PR1101MB2266.namprd11.prod.outlook.com ([fe80::b07e:e40:d34e:b601%6]) with mapi id 15.20.3109.021; Wed, 17 Jun 2020 23:29:58 +0000 From: "Kang, Luwei" To: =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: RE: [PATCH v1 0/7] Implement support for external IPT monitoring Thread-Topic: [PATCH v1 0/7] Implement support for external IPT monitoring Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hpiVzvKAgAAIowCAAHHNAIAAVp/wgAArhICAADbMIIAABJuAgACxxQA= Date: Wed, 17 Jun 2020 23:29:58 +0000 Message-ID: References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <20200617092103.GZ735@Air-de-Roger> <20200617125339.GB735@Air-de-Roger> In-Reply-To: <20200617125339.GB735@Air-de-Roger> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.214] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bb39dce2-91d2-4690-c61c-08d813165992 x-ms-traffictypediagnostic: DM5PR11MB1306: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04371797A5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jbhrCrHwlunoXXoMBORg60y+8vWQV508kszKRlLb7dXnYaOm7Dox2pk6j+zup5955M5MbHrAo16OMx6nuves9dAHSuFzaeFpPTWQF5+KARU032QxNjnG9YMvGmVgJd4y61EVylmTjXHJMDs/IcvjnMRPn4f5s6P1atOWNZ3moITGtTAqbAkbhnPqnCfwsR+gW4pD2JIsBsQbTlbQbh8/eA0404By4+STbWBKYy1UwPSDA9QYZHveON56TMWXqQ7XY1vYt1sv/UPTf9qX+e1M3yPGPYRMyA4/7dn6P8FZp1eVGmON3vo+eFWSlxRlAPij2x5TXrfyIb8s7S+xqRIMYQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR1101MB2266.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(376002)(136003)(346002)(39860400002)(2906002)(4744005)(7416002)(316002)(55016002)(478600001)(71200400001)(54906003)(9686003)(26005)(33656002)(8936002)(86362001)(66946007)(66556008)(66446008)(66476007)(5660300002)(76116006)(7696005)(6916009)(4326008)(6506007)(186003)(8676002)(52536014)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: RZFbX1ouATHnlvwV5LGc2eG2aPLAm+eZDHNfadHBiUlLPwasr0SgmuQqfweIiPIiqJOkkVErdLuQolprw+WcqFC0PuWrSf9+YzhY8ZGwwmvbjbfhXi7HVrmCGSBxhbmqO/VIgTYSvfYqs0Mt5lopf7zPSf4ZcsEayeLQbUzppXUx6uE0Zbh/omB9ysWpk9w6OYXKOt+9Q2HpSKrHW02rEaFi9zEzieRJA29/jPeU4ldSkbrWU9km16665+CcwjS6r4IiF6mjhuFdt2enh55kZVOmRTnPfti1ldPj+DaMJFub+X/Ygw18y2bWooIUlYpqVPG7gPgjD3jVAfZ7iPVK0GHxzDX5vyxNEKQPbc+bEJMej/iWXSABSI44oEC8ACqu4F0CmxIc8JmfrEsnB6HvY1BRgNW+85ACfYe0sfPXe7Ysn6G/GERln8Pgjn6FQAolmHyeJtZVZWL5LVOqmzsL0yTqlX5R48hiqeY0QG+x3xrfWE+0iqHEQHATfmBtIRNF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bb39dce2-91d2-4690-c61c-08d813165992 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 23:29:58.4435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fR4MJsxjZWhYnWDFVTYB4UIm+95YahqpVT3fBXosifuEi0J5QEQluRjxTkVbeH8tBKZEeSrJh5jvFqWdTihHlg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1306 X-OriginatorOrg: intel.com X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Tian, Kevin" , Stefano Stabellini , Julien Grall , "Nakajima, Jun" , Wei Liu , Andrew Cooper , =?utf-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiA+ID4gSG93IGRvZXMgS1ZNIGRlYWwgd2l0aCB0aGlzLCBkbyB0aGV5IGluc2VydC9tb2RpZnkg dHJhY2UgcGFja2V0cyBvbg0KPiA+ID4gdHJhcHBlZCBhbmQgZW11bGF0ZWQgaW5zdHJ1Y3Rpb25z IGJ5IHRoZSBWTU0/DQo+ID4NCj4gPiBUaGUgS1ZNIGluY2x1ZGVzIGluc3RydWN0aW9uIGRlY29k ZXIgYW5kDQo+IGVtdWxhdG9yKGFyY2gveDg2L2t2bS9lbXVsYXRlLmMpLCBhbmQgdGhlIGd1ZXN0 J3MgbWVtb3J5IGNhbiBiZSBzZXQgdG8NCj4gd3JpdGUtcHJvdGVjdCBhcyB3ZWxsLiBCdXQgaXQg ZG9lc24ndCBzdXBwb3J0IEludGVsIFBUIHBhY2tldHMgc29mdHdhcmUgZW11bGF0b3IuDQo+IEZv ciBLVk0sIHRoZSBJbnRlbCBQVCBmZWF0dXJlIHdpbGwgYmUgZXhwb3NlZCB0byBLVk0gZ3Vlc3Qg YW5kIEtWTSBndWVzdCBjYW4NCj4gdXNlIEludGVsIFBUIGZlYXR1cmUgbGlrZSBuYXRpdmUuDQo+ IA0KPiBCdXQgaWYgc3VjaCBmZWF0dXJlIGlzIGV4cG9zZWQgdG8gdGhlIGd1ZXN0IGZvciBpdCdz IG93biB1c2FnZSwgd29uJ3QgaXQgYmUNCj4gbWlzc2luZyBwYWNrZXRzIGZvciBpbnN0cnVjdGlv bnMgZW11bGF0ZWQgYnkgdGhlIFZNTT8NCg0KSWYgc2V0dGluZyB0aGUgZ3Vlc3QncyBtZW1vcnkg d3JpdGUtcHJvdGVjdCwgSSB0aGluayB5ZXMuIA0KDQpUaGFua3MsDQpMdXdlaSBLYW5nDQoNCj4g DQo+IFRoYW5rcywgUm9nZXIuDQo= From xen-devel-bounces@lists.xenproject.org Wed Jun 17 23:30:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 23:30:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlhVi-0006Tu-DT; Wed, 17 Jun 2020 23:30:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlhVh-0006Tb-N1 for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 23:30:25 +0000 X-Inumbo-ID: 845f92fe-b0f2-11ea-ba2c-12813bfff9fa Received: from mga03.intel.com (unknown [134.134.136.65]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 845f92fe-b0f2-11ea-ba2c-12813bfff9fa; Wed, 17 Jun 2020 23:30:24 +0000 (UTC) IronPort-SDR: E6pNozX2IuE+MqZdflOlU9Y+GieO86k+l5sAOi/HCXLK+WxnXKCuCybI9cET3L8q5Ub4QXswzz KA74ZQuyGFSQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 16:30:23 -0700 IronPort-SDR: n2p3/vyP3iCSioJUGvV2RNH8TzPCAX31ijwnjc5ryiHP6Y1JUg5ep4tpPQDVvugUNPxDiRIQbG 6TBVEzjLTC5Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,523,1583222400"; d="scan'208";a="262734323" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga007.jf.intel.com with ESMTP; 17 Jun 2020 16:30:22 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 17 Jun 2020 16:30:22 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.174) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 17 Jun 2020 16:30:22 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NuGfLQ7FhDXmPVyiYK1g3IX2OHA87waAHB53igWKn9lRPBa6KuC6x66XWa2lqzhTLoky5gqSd7iTkloXnJo4p7FMsjvC/0YBZQme1EoY/BZzmZ/aIAWmHvQNv0SCb/2OQIHzluG7GKYJQYv1ANf3TWWoz9ualvjWqebv0u9HPGmeLUL0UogyZCJTel29qG0BTwp79okIfGVQpA3RP4sSf21GtPAlfmpazu9P2s1M+O7DU4kGI517jK240wLvDMKsQHLMkv/Wrz0Ukf3Dmt5RnT1cwb4u0Fu0ttVVNX6JyETd4VtiZd3m3bAQKc6YBDOvSKJOFtE2zkpNmXfBJsNjew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NbMPmNMCRf31sEUYAuqQ9dIp2fsZdxHCJN5Tg4Qo0l8=; b=HGin0GwZSnDeA2/QJME8hNKjOJng1ayQE8VDCMJQMCJ5/WXgSPqLO6KB8YoRZDpp1uR/989HNZ3gc/61ymBPoNwMoWLVRXFwnXc3NbaVIuk8Wb0W8ujytl+Ow6rmZL36JPCoxMGiTHFGu/AC8igfJYbJ6xeNyTGYES3+DwY+vQsTJFYbvWHa86ghKSwpkjQm9ONWiTbSOeTQbTCm+ReUIdVFSom3apQMg8p1SUUl/mqBKLFnvI+Bnq4yYJnaX4NYSdQmGJblgvMONKcZHe/5t2/6pceTiOO6LN2lXqFE5lxp4AsQGNVh6Fn3iLBO9b10X7QW9jOAr2Bhu/2FwTB2Qw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NbMPmNMCRf31sEUYAuqQ9dIp2fsZdxHCJN5Tg4Qo0l8=; b=oY70uqSQE3wYHAz6+27T6J/G6LyPzKbAS/SungBiDFlNpKfRnzq3VIzl9ODCMNeYQFRZ7ILiR/v3jtKQe98w8vHXfM9Dqy3KBE79yyHa5MG5RrmohUfFu92YILPTlRW9HISy8BCZsAciK3W93mhaedSZCahuY2BfJWYAQZasolE= Received: from DM5PR1101MB2266.namprd11.prod.outlook.com (2603:10b6:4:57::17) by DM5PR11MB1306.namprd11.prod.outlook.com (2603:10b6:3:b::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Wed, 17 Jun 2020 23:30:20 +0000 Received: from DM5PR1101MB2266.namprd11.prod.outlook.com ([fe80::b07e:e40:d34e:b601]) by DM5PR1101MB2266.namprd11.prod.outlook.com ([fe80::b07e:e40:d34e:b601%6]) with mapi id 15.20.3109.021; Wed, 17 Jun 2020 23:30:20 +0000 From: "Kang, Luwei" To: Andrew Cooper , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , =?utf-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= Subject: RE: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit Thread-Topic: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit Thread-Index: AQHWRLorqrdGrNJzv0i3WWOReT69qqjdbEMA Date: Wed, 17 Jun 2020 23:30:20 +0000 Message-ID: References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> <20200616173857.GU735@Air-de-Roger> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> <20200617090942.GY735@Air-de-Roger> <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> <20200617125146.GA735@Air-de-Roger> <5ad138bb-9195-a8de-5566-468db553422e@citrix.com> In-Reply-To: <5ad138bb-9195-a8de-5566-468db553422e@citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.214] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3bd7b287-df72-43d5-643c-08d8131666e4 x-ms-traffictypediagnostic: DM5PR11MB1306: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04371797A5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d6ye1gBGYqfP4o6QakFNDeplQkKCVXd5ARm/6dJ1AMpVkEqHnY9x66vueWBoQ3XnKrFRTTKrIyggDen/WnWCw8klhvzgXHQ5JTf7zpHFf1kCrYKBO6ceIpO5GhKBQLVP9dCEUQBgSQHZJGjVOqDp5W3EkBGNIfXkq2JEL9wr+pMBJ5XRP/zD98RopSg8YVjE/gOUt2pved/IVCMNwo2+KIJKnMbwMdOqQhYSRduKpepATCVM6NAcCZPSbzsv93q3CMkxLVU44xqxyiSKSiTeRhiCN6rD7dQFLg3xqFoy6GRNWWPXsHz90Y9r6NDvxEku x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR1101MB2266.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(376002)(136003)(346002)(39860400002)(2906002)(110136005)(316002)(55016002)(478600001)(71200400001)(54906003)(9686003)(26005)(33656002)(8936002)(86362001)(66946007)(66556008)(66446008)(66476007)(66574015)(5660300002)(76116006)(7696005)(4326008)(6506007)(186003)(8676002)(52536014)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ktdcDN7ezG0N7HM+1st0e8SkZYoyebMMjdhnAGY6FPjl2oIhvtzhcq/B4Hlt5mb9nP3CpaivOj0B///8GEcN6OEEeNiQKAMgNGaVGTBLJWjf6zNANTm2bABOIzp0UYiU9QDI47CSANXxwI7ezRjBy6fckVwo38+VjOb40J/4s9GyuXmhCT8cN2/7OwCf9TtFklnO0J8UUjjob9QQwuLDJ08Ir5PyqbwEBF8W4E7NVMctM8zmIvHLsbYmBEOVESgmT28tekbEdEtCWOt9q+lPV0QAKC0uy/h6byyboNb0YzIS6PO+8tW3KhqbvxCBeby5QNzbf4J40eFs5ZqwGjaQBSN1A70kBxnnBQORLs3IAflFTxMXDBGAA/WcopaIyQGEHGnrMH8frox3XbciZTFMuj8KznvoTw02ztn+ELEOkH46Smsob3EK9r9BvMSnpOx1iP2jXSB6AYV2B9t0Jb1yBN13JdaQvh+4WBbEkF4dVxP9Qhn26P4GKLu7HGIzO7rm Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3bd7b287-df72-43d5-643c-08d8131666e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2020 23:30:20.7808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UvRViusavHclwPBwvlTmh9Gr82E8Lox6WPG8qApJ+Djy2Ovmco25+rQT8fvZvkmY5Z0sqi3O0kGGTKoc0F60IA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1306 X-OriginatorOrg: intel.com X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , "Tian, Kevin" , Wei Liu , Jan Beulich , "Nakajima, Jun" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiA+IE9uIFdlZCwgSnVuIDE3LCAyMDIwIGF0IDAxOjU0OjQ1UE0gKzAyMDAsIE1pY2hhxYIgTGVz emN6ecWEc2tpIHdyb3RlOg0KPiA+PiAtLS0tLSAxNyBjemUgMjAyMCBvIDExOjA5LCBSb2dlciBQ YXUgTW9ubsOpIHJvZ2VyLnBhdUBjaXRyaXguY29tIG5hcGlzYcWCKGEpOg0KPiA+Pg0KPiA+Pj4g MjQgVmlydHVhbCBNYWNoaW5lIENvbnRyb2wgU3RydWN0dXJlcyAtPiAyNC44IFZNLWVudHJ5IENv bnRyb2wNCj4gPj4+IEZpZWxkcyAtPiAyNC44LjEgVk0tRW50cnkgQ29udHJvbHMgU29mdHdhcmUg c2hvdWxkIGNvbnN1bHQgdGhlIFZNWA0KPiBjYXBhYmlsaXR5IE1TUnMgSUEzMl9WTVhfRU5UUllf Q1RMUyB0byBkZXRlcm1pbmUgaG93IGl0IHNob3VsZCBzZXQgdGhlDQo+IHJlc2VydmVkIGJpdHMu DQo+ID4+IFBsZWFzZSBsb29rIGF0IGJpdCBwb3NpdGlvbiAxOCAiTG9hZCBJQTMyX1JUSVRfQ1RM Ii4NCj4gPiBJIHRoaW5rIHRoaXMgaXMgc29tZXRoaW5nIGRpZmZlcmVudCBmcm9tIHdoYXQgSSB3 YXMgcmVmZXJyaW5nIHRvLg0KPiA+IFRob3NlIG9wdGlvbnMgeW91IHJlZmVyIHRvIChsb2FkL2Ns ZWFyIElBMzJfUlRJVF9DVEwpIGRlYWwgd2l0aA0KPiA+IGxvYWRpbmcvc3RvcmluZyBhIHNwZWNp ZmljIGZpZWxkIG9uIHRoZSB2bWNzIHRoYXQgbWFwcyB0byB0aGUgZ3Vlc3QNCj4gPiBJQTMyX1JU SVRfQ1RMLg0KPiA+DQo+ID4gT1RPSCBNU1IgbG9hZCBsaXN0cyBjYW4gYmUgdXNlZCB0byBsb2Fk IGFuZCBzdG9yZSBhbnkgYXJiaXRyYXJ5IE1TUiBvbg0KPiA+IHZtZW50cnkvdm1leGl0LCBzZWUg c2VjdGlvbiAyNi40IExPQURJTkcgTVNSUyBvbiB0aGUgU0RNLiBUaGVyZSdzDQo+ID4gYWxyZWFk eSBpbmZyYXN0cnVjdHVyZSBvbiBYZW4gdG8gZG8gc28sIHNlZSB2bXhfe2FkZC9kZWwvZmluZH1f bXNyLg0KPiANCj4gSWYgSSByZW1lbWJlciB0aGUgaGlzdG9yaWMgcm9hZG1hcHMgY29ycmVjdGx5 LCB0aGVyZSBhcmUgMyBjYXNlcy4NCj4gDQo+IFRoZSBmaXJzdCBoYXJkd2FyZSB0byBzdXBwb3J0 IFBUIChCcm9hZHdlbGw/KSBwcm9oaWJpdGVkIGl0cyB1c2UgY29tcGxldGVseSBpbg0KPiBWTVgg b3BlcmF0aW9ucy7CoCBJbiB0aGlzIGNhc2UsIHdlIGNhbiB1c2UgaXQgdG8gdHJhY2UgUFYgZ3Vl c3RzIGlmZiB3ZSBkb24ndA0KPiBlbmFibGUgVk1YIGluIGhhcmR3YXJlIHRvIGJlZ2luIHdpdGgu DQo+IA0KPiBUaGlzIHdhcyByZWxheGVkIGluIGxhdGVyIGhhcmR3YXJlIChTa3lsYWtlPykgdG8g cGVybWl0IHVzZSB3aXRoaW4gVk1YDQo+IG9wZXJhdGlvbnMsIGJ1dCB3aXRob3V0IGFueSBoZWxw IGluIHRoZSBWTUNTLsKgIChpLmUuIG1hbnVhbCBjb250ZXh0IHN3aXRjaGluZw0KPiBwZXIgdGhp cyBwYXRjaCwgb3IgTVNSIGxvYWQgbGlzdHMgYXMgbm90ZWQgaW4gdGhlIFNETS4pDQo+IA0KPiBT dWJzZXF1ZW50IHN1cHBvcnQgZm9yICJ2aXJ0dWFsaXNlZCBQVCIgd2FzIGFkZGVkIChJY2VMYWtl Pykgd2hpY2ggYWRkcyB0aGUNCj4gbG9hZC9zYXZlIGNvbnRyb2xzLCBhbmQgdGhlIGFiaWxpdHkg dG8gdHJhbnNsYXRlIHRoZSBvdXRwdXQgYnVmZmVyIHVuZGVyIEVQVC4NCj4gDQo+IA0KPiBBbGwg b2YgdGhpcyBpcyBmcm9tIG1lbW9yeSBzbyBJJ20gcXVpdGUgcG9zc2libHkgd3Jvbmcgd2l0aCBk ZXRhaWxzLCBidXQgSSBiZWxpZXZlDQo+IHRoaXMgaXMgd2h5IHRoZSBjdXJyZW50IGNvbXBsZXhp dHkgZXhpc3RzLg0KDQpZZXMsIEl0IGluY2x1ZGUgMyBjYXNlcy4NCjEuIEJlZm9yZSBJQTMyX1ZN WF9NSVNDW2JpdCAxNF06DQogICAgIEludGVsIFBUIGRvZXNuJ3Qgc3VwcG9ydCB0cmFjaW5nIGlu IFZNWCBvcGVyYXRpb24uIEV4ZWN1dGlvbiBvZiB0aGUgVk1YT04gaW5zdHJ1Y3Rpb24gY2xlYXJz IElBMzJfUlRJVF9DVEwuVHJhY2VFbiBhbmQgYW55IGF0dGVtcHQgdG8gd3JpdGUgSUEzMl9SVElU X0NUTCBpbiBWTVggb3BlcmF0aW9uIGNhdXNlcyBhIGdlbmVyYWwtcHJvdGVjdGlvbiBleGNlcHRp b24gKCNHUCkNCjIuIFN1cHBvcnQgSUEzMl9WTVhfTUlTQ1tiaXQgMTRdIGJ1dCBubyBFUFQgdG8g ZGlyZWN0IFBUIG91dHB1dDoNCiAgICBJbnRlbCBQVCBjYW4gYmUgZW5hYmxlZCBhY3Jvc3MgVk1Y IGJ1dCB0aGUgYWRkcmVzcyBvZiBJbnRlbCBQVCBidWZmZXIgaXMgYWx3YXlzIEhQQSBmcm9tIEhX IHBvaW50IG9mIHZpZXcuIFRoZXJlIGlzIG5vdCBWTUNTIHN1cHBvcnQgaW4gdGhpcyBzdGFnZS4g VGhlIE1TUiBsb2FkIGxpc3QgY2FuIGJlIHVzZWQgZm9yIEludGVsIFBUIGNvbnRleHQgc3dpdGNo KFZNLUVudHJ5L0V4aXQpLg0KMy4gSW50ZWwgUFQgVk0gaW1wcm92ZW1lbnRzIChzdGFydCBmcm9t IEljZWxha2UpOg0KICAgIEFkZCBhIG5ldyBndWVzdCBJQTMyX1JUSVRfQ1RMIGZpZWxkIGluIFZN Q1MsIGFuZCBIVyB0cmVhdCB0aGUgUFQgb3V0cHV0IGFkZHJlc3NlcyBhcyBHUEEgYW5kIHRyYW5z bGF0ZSB0aGVtIHVzaW5nIEVQVC4NCg0KVGhhbmtzLA0KTHV3ZWkgS2FuZw0K From xen-devel-bounces@lists.xenproject.org Wed Jun 17 23:53:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 17 Jun 2020 23:53:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlhrZ-0008FP-8U; Wed, 17 Jun 2020 23:53:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlhrX-0008FF-Cs for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 23:52:59 +0000 X-Inumbo-ID: ab7e9d1e-b0f5-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ab7e9d1e-b0f5-11ea-bb8b-bc764e2007e4; Wed, 17 Jun 2020 23:52:58 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id o15so4431431ejm.12 for ; Wed, 17 Jun 2020 16:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+ahHqexj4nO5KkBjec2eEAPgSrIPxwEYP+2wlTG5wZE=; b=Kdwkh6YVkup94CQ6f7PEX5pDkaZEIbyxAfF1K2AaQfHEfSFsic/yLF+JWzwefxYu6+ n3hbDDnZ5KgHVJ2HlpQvJRV4wO6ExMB5txKimrpna/t5EWk4xHY5e/C84PWqIsSNhz49 /qSnwzTkJ2XLdJ+Gfj17H4WjgiuYu3aFQ4y4FTLEhuYE3aAwKWXfwut9SVrxVUOpkQub Tc/dOousVe09H03Lwr8wXXQVEh579BQ6G+lIxT+hb71NN+UasZ0n6wiCKmSBSz+tcPOj u+XjDLmKDGazaeJhz3JFesCbDfaoif5J56z4AbfYahhnC1fULOcFlYJnd8IV8HXxFwFn 89Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+ahHqexj4nO5KkBjec2eEAPgSrIPxwEYP+2wlTG5wZE=; b=BN1bfws7PWzpJ8UncsQCzbj3Ql8KY5ENXIn7RuBqH7k8UbQeOykJCHSslRG1RiqjkR BxfxrTiVbsmBkaoGYTCU19gN2QNEovGX/XZYYqMQKF/oDyhZcooURTNj8+ZRltWgPWJ2 +bM1GsHS45+BbuOm38KefPEFElXEF2K1HmrhkAwmEtXtnZlfsFRz6oX3RhK3BEXKJtyk sFR5v35CaDn3yiqVKvZgF8qAuBdBEO77x4BUzTY7Y4P27NSWlvhGZ9angB7AXiD1xixj I/uZ3iN5Z4ydb+rri6TEOhn2zHvqObljTbzn6F8t8kBr70b3ZJfl0JCq4LNgBxUL76wN MRFQ== X-Gm-Message-State: AOAM530RfnH4bgyVJ+3vG0f8jcHXob4I32BqT5ukbv/L/tsBlOLb/xlv To2YSxFujJpb1Fa2PzLKyoYCfjxybfTdR+dcTFo= X-Google-Smtp-Source: ABdhPJxFpIhxcvelT8mK9AnydFRIsC0FZ/j211N5b/73nGLTaEjngUhD8T/4nkgci5SB09OhQxyp2U/8hmHWARYOCRI= X-Received: by 2002:a17:906:6dcd:: with SMTP id j13mr1405867ejt.131.1592437977525; Wed, 17 Jun 2020 16:52:57 -0700 (PDT) MIME-Version: 1.0 References: <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> In-Reply-To: From: CodeWiz2280 Date: Wed, 17 Jun 2020 19:52:42 -0400 Message-ID: Subject: Re: Keystone Issue To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , nd , Bertrand Marquis , xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 2:46 PM Stefano Stabellini wrote: > > On Wed, 17 Jun 2020, CodeWiz2280 wrote: > > On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote: > > > > > > On 2020-06-16 19:13, CodeWiz2280 wrote: > > > > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: > > > >> > > > >> On 2020-06-15 20:14, CodeWiz2280 wrote: > > > >> > > > >> [...] > > > >> > > > >> > Also, the latest linux kernel still has the X-Gene storm distributor > > > >> > address as "0x78010000" in the device tree, which is what the Xen code > > > >> > considers a match with the old firmware. What were the addresses for > > > >> > the device tree supposed to be changed to? > > > >> > > > >> We usually don't care, as the GIC address is provided by the > > > >> bootloader, > > > >> whether via DT or ACPI (this is certainly what happens on Mustang). > > > >> Whatever is still in the kernel tree is just as dead as the platform > > > >> it > > > >> describes. > > > >> > > > >> > Is my understanding > > > >> > correct that there is a different base address required to access the > > > >> > "non-secure" region instead of the "secure" 0x78010000 region? I'm > > > >> > trying to see if there are corresponding different addresses for the > > > >> > keystone K2E, but haven't found them yet in the manuals. > > > >> > > > >> There is no such address. Think of the NS bit as an *address space* > > > >> identifier. > > > >> > > > >> The only reason XGene presents the NS part of the GIC at a different > > > >> address is because XGene is broken enough not to have EL3, hence no > > > >> secure mode. To wire the GIC (and other standard ARM IPs) to the core, > > > >> the designers simply used the CPU NS signal as an address bit. > > > >> > > > >> On your platform, the NS bit does exist. I strongly suppose that it > > > >> isn't wired to the GIC. Please talk to your SoC vendor for whether iot > > > >> is possible to work around this. > > > >> > > > > I do have a question about this out to TI, but at least this method > > > > gives me something to work with in the meantime. I was just looking > > > > to confirm that there wouldn't be any other undesirable side effects > > > > with Dom0 or DomU when using it. Was there an actual FPGA for the > > > > X-Gene that needed to be updated which controlled the GIC access? Or > > > > by firmware do you mean the boot loader (e.g. uboot). Thanks for the > > > > support so far to all. > > > > > > As I said, the specific case of XGene was just a matter of picking the > > > right address, as the NS bit is used as an address bit on this platform. > > > This was possible because this machine doesn't have any form of > > > security. So no HW was changed, no FPGA reprogrammed. Only a firmware > > > table was fixed to point to the right spot. Not even u-boot or EFI was > > > changed. > > Ok, thank you for clarifying. I have one more question if you don't > > mind. I'm aware that dom0 can share physical memory with dom1 via > > grant tables. > > However, is it possible to reserve a chunk of contiguous physical > > memory and directly allocate it only to dom1? > > For example, if I wanted dom1 to have access to 8MB of contiguous > > memory at 0x8200_0000 (in addition to whatever virtual memory Xen > > gives it). > > How would one go about doing this on ARM? Is there something in the > > guest config or device tree that can be set? Thanks for you help. > > There isn't a "proper" way to do it, only a workaround. > > It is possible to do it by using the iomem option, which is meant for > device MMIO regions. > > We have patches in the Xilinx Xen tree (not upstream) to allow for > specifying the cacheability that you want for the iomem mapping so that > you can map it as normal memory. This is the latest branch: > > https://github.com/Xilinx/xen.git xilinx/release-2020.1 > > The relevant commits are the ones from: > https://github.com/Xilinx/xen/commit/a5c76ac1c5dc14d3e9ccedc5c1e7dd2ddc1397b6 > to: > https://github.com/Xilinx/xen/commit/b4b7e91c1524f9cf530b81b7ba95df2bf50c78e4 > > You might want to make sure that the page is not used by the normal > memory allocator. This document explains how to something along those > lines: > > https://github.com/Xilinx/xen/commit/35f72d9130448272e07466bd73cc30406f33135e Thank you. I appreciate it. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 00:57:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 00:57:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlirT-0005HD-Ej; Thu, 18 Jun 2020 00:56:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlirR-0005H8-PO for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 00:56:57 +0000 X-Inumbo-ID: 9b33b90e-b0fe-11ea-ba33-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9b33b90e-b0fe-11ea-ba33-12813bfff9fa; Thu, 18 Jun 2020 00:56:56 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 625C0A2FAE; Thu, 18 Jun 2020 02:56:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 4E7D1A2F9E; Thu, 18 Jun 2020 02:56:54 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id o5n85De7uYtf; Thu, 18 Jun 2020 02:56:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id C4ECBA2FAE; Thu, 18 Jun 2020 02:56:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id M8zf2CvrWWM3; Thu, 18 Jun 2020 02:56:53 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 8C6C6A2F9E; Thu, 18 Jun 2020 02:56:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 6CF6420981; Thu, 18 Jun 2020 02:56:23 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id j0AqRmOhXW1I; Thu, 18 Jun 2020 02:56:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D6C1520BB5; Thu, 18 Jun 2020 02:56:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ts7feNZlCDTp; Thu, 18 Jun 2020 02:56:17 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 9BBA520981; Thu, 18 Jun 2020 02:56:17 +0200 (CEST) Date: Thu, 18 Jun 2020 02:56:17 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: "Kang, Luwei" Message-ID: <1683804232.9278740.1592441777496.JavaMail.zimbra@cert.pl> In-Reply-To: References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <20200617092103.GZ735@Air-de-Roger> <20200617125339.GB735@Air-de-Roger> Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: KAn5ItxMsuAqHW3ZzkheyNf1oni9hpiVzvKAgAAIowCAAHHNAIAAVp/wgAArhICAADbMIIAABJuAgACxxQC8IyuhIw== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Tian, Kevin" , Stefano Stabellini , Julien Grall , "Nakajima, Jun" , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Tamas K Lengyel , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 18 cze 2020 o 1:29, Kang, Luwei luwei.kang@intel.com napisa=C5=82(a): >> > > How does KVM deal with this, do they insert/modify trace packets on >> > > trapped and emulated instructions by the VMM? >> > >> > The KVM includes instruction decoder and >> emulator(arch/x86/kvm/emulate.c), and the guest's memory can be set to >> write-protect as well. But it doesn't support Intel PT packets software >> emulator. >> For KVM, the Intel PT feature will be exposed to KVM guest and KVM guest= can >> use Intel PT feature like native. >>=20 >> But if such feature is exposed to the guest for it's own usage, won't it= be >> missing packets for instructions emulated by the VMM? >=20 > If setting the guest's memory write-protect, I think yes. Thus, I propose to leave it as it is right now. If somebody is purposely al= tering the VM state then he/she should consult not only the IPT but also un= derstand what was done "in the meantime" by additional features, e.g. when = something was altered by vm_event callback. As Tamas said previously, we us= ually just want to see certain path leading to vmexit. Please also note that there is a PTWRITE instruction that could be used in = the future in order to add custom payloads/hints to the PT trace, when need= ed. >=20 > Thanks, > Luwei Kang >=20 >>=20 > > Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 01:13:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 01:13:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlj7a-000805-P8; Thu, 18 Jun 2020 01:13:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlj7Z-000800-R7 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 01:13:37 +0000 X-Inumbo-ID: efaea79e-b100-11ea-ba33-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id efaea79e-b100-11ea-ba33-12813bfff9fa; Thu, 18 Jun 2020 01:13:37 +0000 (UTC) Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C07F3221EB; Thu, 18 Jun 2020 01:13:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592442816; bh=w8V3cTH4FJj2K9JiCLrtLjXXfg1XK0Rl1yo5hamlduY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uyMWBSbjABXyGlynbRDNDWGl5kfLLRgPTowTwBJVD98rnW6OyLH+lOSn2PIyd+J9H NigPk/ICcq6pqWp+RACr97Oa0zLZx0sp84jaPb+NFb2CexQ7vlQd/t950GXRZrdg6p aHuH8rl9eRHnX85PfXOdKuaQFyyUf9uOKxfm/IWg= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH AUTOSEL 5.7 254/388] xen/cpuhotplug: Fix initial CPU offlining for PV(H) guests Date: Wed, 17 Jun 2020 21:05:51 -0400 Message-Id: <20200618010805.600873-254-sashal@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200618010805.600873-1-sashal@kernel.org> References: <20200618010805.600873-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Sasha Levin , Boris Ostrovsky , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Boris Ostrovsky [ Upstream commit c54b071c192dfe8061336f650ceaf358e6386e0b ] Commit a926f81d2f6c ("xen/cpuhotplug: Replace cpu_up/down() with device_online/offline()") replaced cpu_down() with device_offline() call which requires that the CPU has been registered before. This registration, however, happens later from topology_init() which is called as subsys_initcall(). setup_vcpu_hotplug_event(), on the other hand, is invoked earlier, during arch_initcall(). As result, booting a PV(H) guest with vcpus < maxvcpus causes a crash. Move setup_vcpu_hotplug_event() (and therefore setup_cpu_watcher()) to late_initcall(). In addition, instead of performing all offlining steps in setup_cpu_watcher() simply call disable_hotplug_cpu(). Fixes: a926f81d2f6c (xen/cpuhotplug: Replace cpu_up/down() with device_online/offline()" Signed-off-by: Boris Ostrovsky Link: https://lore.kernel.org/r/1588976923-3667-1-git-send-email-boris.ostrovsky@oracle.com Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin --- drivers/xen/cpu_hotplug.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c index ec975decb5de..b96b11e2b571 100644 --- a/drivers/xen/cpu_hotplug.c +++ b/drivers/xen/cpu_hotplug.c @@ -93,10 +93,8 @@ static int setup_cpu_watcher(struct notifier_block *notifier, (void)register_xenbus_watch(&cpu_watch); for_each_possible_cpu(cpu) { - if (vcpu_online(cpu) == 0) { - device_offline(get_cpu_device(cpu)); - set_cpu_present(cpu, false); - } + if (vcpu_online(cpu) == 0) + disable_hotplug_cpu(cpu); } return NOTIFY_DONE; @@ -119,5 +117,5 @@ static int __init setup_vcpu_hotplug_event(void) return 0; } -arch_initcall(setup_vcpu_hotplug_event); +late_initcall(setup_vcpu_hotplug_event); -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 01:34:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 01:34:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jljRU-0001Ed-BK; Thu, 18 Jun 2020 01:34:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jljRS-0001EY-W3 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 01:34:11 +0000 X-Inumbo-ID: cea8bcee-b103-11ea-ba33-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cea8bcee-b103-11ea-ba33-12813bfff9fa; Thu, 18 Jun 2020 01:34:10 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 22B372224B; Thu, 18 Jun 2020 01:34:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592444049; bh=4htdzxxYBO1kLA3P0d0+HK13o/0/qE/SSGDwUAsI9yI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=KSiuscW36W1Ai+NKkyGvMUkevKFMoomHz+jeoy/W3X6J/BPbVLrgHo8SzyGpBk5te njQMaWIWXjGF0NkNXXWi9rzRXpzK/VO8bvRPutXiTwHxIBpbCBr0bVuJT3FxKTulP5 YQjWtaYcdStdC+6/HDwmeQgS01hC52m7dt5I0SaM= Date: Wed, 17 Jun 2020 18:34:08 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches In-Reply-To: Message-ID: References: <20200613184132.11880-1-julien@xen.org> <35c8373f-b691-d95e-17de-021c72faf216@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , Paul Durrant , Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 16 Jun 2020, Julien Grall wrote: > On Tue, 16 Jun 2020 at 21:57, Stefano Stabellini wrote: > > > > On Tue, 16 Jun 2020, Julien Grall wrote: > > > On 16/06/2020 02:00, Stefano Stabellini wrote: > > > > On Sat, 13 Jun 2020, Julien Grall wrote: > > > > > From: Julien Grall > > > > > > > > > > The documentation of pvcalls suggests there is padding for 32-bit x86 > > > > > at the end of most the structure. However, they are not described in > > > > > in the public header. > > > > > > > > > > Because of that all the structures would be 32-bit aligned and not > > > > > 64-bit aligned for 32-bit x86. > > > > > > > > > > For all the other architectures supported (Arm and 64-bit x86), the > > > > > structure are aligned to 64-bit because they contain uint64_t field. > > > > > Therefore all the structures contain implicit padding. > > > > > > > > > > The paddings are now corrected for 32-bit x86 and written explicitly for > > > > > all the architectures. > > > > > > > > > > While the structure size between 32-bit and 64-bit x86 is different, it > > > > > shouldn't cause any incompatibility between a 32-bit and 64-bit > > > > > frontend/backend because the commands are always 56 bits and the padding > > > > > are at the end of the structure. > > > > > > > > > > As an aside, the padding sadly cannot be mandated to be 0 as they are > > > > > already present. So it is not going to be possible to use the padding > > > > > for extending a command in the future. > > > > > > > > > > Signed-off-by: Julien Grall > > > > > > > > > > --- > > > > > Changes in v3: > > > > > - Use __i386__ rather than CONFIG_X86_32 > > > > > > > > > > Changes in v2: > > > > > - It is not possible to use the same padding for 32-bit x86 and > > > > > all the other supported architectures. > > > > > --- > > > > > docs/misc/pvcalls.pandoc | 18 ++++++++++-------- > > > > > xen/include/public/io/pvcalls.h | 14 ++++++++++++++ > > > > > 2 files changed, 24 insertions(+), 8 deletions(-) > > > > > > > > > > diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc > > > > > index 665dad556c39..caa71b36d78b 100644 > > > > > --- a/docs/misc/pvcalls.pandoc > > > > > +++ b/docs/misc/pvcalls.pandoc > > > > > @@ -246,9 +246,9 @@ The format is defined as follows: > > > > > uint32_t domain; > > > > > uint32_t type; > > > > > uint32_t protocol; > > > > > - #ifdef CONFIG_X86_32 > > > > > + #ifndef __i386__ > > > > > uint8_t pad[4]; > > > > > - #endif > > > > > + #endif > > > > > > > > > > > > Hi Julien, > > > > > > > > Thank you for doing this, and sorry for having missed v2 of this patch, I > > > > should have replied earlier. > > > > > > > > The intention of the #ifdef blocks like: > > > > > > > > #ifdef CONFIG_X86_32 > > > > uint8_t pad[4]; > > > > #endif > > > > > > > > in pvcalls.pandoc was to make sure that these structs would be 64bit > > > > aligned on x86_32 too. > > > > > > > > I realize that the public header doesn't match, but the spec is the > > > > "master copy". > > > > > > So far, the public headers are the defacto official ABI. So did you mark the > > > pvcall header as just a reference? > > > > No, there is no document that says that the canonical copy of the > > interface is pvcalls.pandoc. However, it was clearly spelled out from > > the start on xen-devel (see below.) > > In fact, if you notice, this is the > > first document under docs/misc that goes into this level of details in > > describing a new PV protocol. Also note the title of the document which > > is "PV Calls Protocol version 1". > > While I understand this may have been the original intention, you > can't expect a developer to go through the archive to check whether > he/she should trust the header of the document. > > > > > > > In reply to Jan: > > > A public header can't be "fixed" if it may already be in use by > > > anyone. We can only do as Andrew and you suggest (mandate textual > > > descriptions to be "the ABI") when we do so for _new_ interfaces from > > > the very beginning, making clear that the public header (if any) > > > exists just for reference. > > > > What if somebody took the specification of the interface from > > pvcalls.pandoc and wrote their own headers and code? It is definitely > > possible. > > As it is possible for someone to have picked the headers from Xen as > in the past public/ has always been the authority. We never had documents under docs/ before specifying the interfaces before pvcalls. It is not written anywhere that the headers under public/ are the authoritative interfaces either, it is just that it was the only thing available before. If you are new to the project you might go to docs/ first. > > At the time, it was clarified that the purpose of writing such > > a detailed specification document was that the document was the > > specification :-) > > At the risk of being pedantic, if it is not written in xen.git it > doesn't exist ;). > > Anyway, no matter the decision you take here, you are going to > potentially break one set of the users. > > I am leaning towards the header as authoritative because this has > always been the case in the past and nothing in xen.git says > otherwise. However I am not a user of pvcalls, so I don't really have > any big incentive to go either way. Yeah, we are risking breaking one set of users either way :-/ In reality, we are using pvcalls on arm64 in a new project (but it is still very green). I am not aware of anybody using pvcalls on x86 (especially x86_32). I would prefer to honor the pvcalls.pandoc specification because that is what it was meant to be, and also leads to a better protocol specification. > For the future, I would highly suggest writing down the support > decision in xen.git. This would avoid such debate on what is the > authority... Yes that's the way to go From xen-devel-bounces@lists.xenproject.org Thu Jun 18 02:23:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 02:23:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlkDD-0005cD-2c; Thu, 18 Jun 2020 02:23:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlkDB-0005bk-2k for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 02:23:29 +0000 X-Inumbo-ID: ae7d4a32-b10a-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ae7d4a32-b10a-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 02:23:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RuiIVGguYAOEZLO1oPi9BbZXvxgeSg3guUNtilkuKLY=; b=s2B1+jW7FDgocIxjN14ZJqBVf ZRnx8AVps940r7psmDc3ylr6m7PT7mW3DBenkHLjZ5QoCxMbU59nk/Ltvbp7oO8HchtQ9vwhHTGrs 4U7608NylnvviATDeConXqeEZzwoA5cqyB2yZxoAeZ2L/wG05njnGOYFMtK7Nv+p1Ab/M=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlkD3-0004A1-Mi; Thu, 18 Jun 2020 02:23:21 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlkD3-0003UG-Ay; Thu, 18 Jun 2020 02:23:21 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlkD3-0007XI-AG; Thu, 18 Jun 2020 02:23:21 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151170: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=a5dc8300df75e8b8384b4c82225f1e4a0b4d9b55 X-Osstest-Versions-That: linux=5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 From: osstest service owner Date: Thu, 18 Jun 2020 02:23:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151170 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151170/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151016 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151016 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151016 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151016 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151016 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux a5dc8300df75e8b8384b4c82225f1e4a0b4d9b55 baseline version: linux 5b14671be58d0084e7e2d1cc9c2c36a94467f6e0 Last test of basis 151016 2020-06-10 12:58:42 Z 7 days Failing since 151044 2020-06-11 10:29:35 Z 6 days 5 attempts Testing same since 151170 2020-06-16 14:31:27 Z 1 days 1 attempts ------------------------------------------------------------ 547 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 5b14671be58d..a5dc8300df75 a5dc8300df75e8b8384b4c82225f1e4a0b4d9b55 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Thu Jun 18 02:51:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 02:51:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlkdk-00081X-FC; Thu, 18 Jun 2020 02:50:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlkdj-00081S-4K for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 02:50:55 +0000 X-Inumbo-ID: 8684eca2-b10e-11ea-8496-bc764e2007e4 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (unknown [40.107.14.54]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8684eca2-b10e-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 02:50:53 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OvAjnMA4z0MvsiREi0f4dsvaj0IbrFs753qzYcgJwNrLCUKIC+1FZeU1yLaMdk6yblJokfcdu5WB1G9GkdQE7L5JQjk4QI1AujpLVTFxK/jrbjw9mowF9VQiXKm6GNJnQZWUT6/x1/Ryez0BX4+ycRzkca48TfH2H/xCH4RRSudMWXxaLRDJjQlV+XYml3Gx0VZYmEXAl9jp6jEuT8+X2ietRgzISfS7KJ91EriulummEvl/Bcwx90j1jovzmdEnSFf6SV8CgfaRxDHNKOpMAprNBFtjaYdUOB2iJEvvGtk9XO4qlrZVtd8PzN8sDrVyeFswexNtBmBB5HYK2Sm/oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b20j/K/217vYUbZ/Ef5p7dL2LuEFddj3s/AcWuYZGfc=; b=UUrYa0+cbhj1MDvjpz9GVoK4HhfWRiA9rWCM+a4k7MHSePqmmjZbhK0m6q6d2nt4dJUpTg7JxCscutWVRh16bRCfVi6Ty/Mc+yUqflXo5xiz1I5Kw/U71PbO+ckRLqW/ROUX7lqvEvbL1cI/ZWEcaCiz+7Gimw0Kpuz9v+rLJcRLQj3630+MZnXHnJUZF6qmhyPI5PJtM/mKZhF/9dxKozEZa1ZZK17Baa7t5RYJp/J4cjPUQEPI4Cc7fOA6hwee5K0Z0C8Tzy+DYW+jDnJO8dfXluk6YVtfhe7yqqAkjzjib9/VCymZVPqLKWF2yPBoXfPZbi5lz7zB/rA/QSj0Dg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b20j/K/217vYUbZ/Ef5p7dL2LuEFddj3s/AcWuYZGfc=; b=etmtVuAHjWf3Zi0Ii53lQuMj+mVo9vOeWgFM5SS5mpMUQz1Myg4EVRgNfE0M+FxyOHzhagtEUBU3MQXQicHeaAAbbZ1XrcinIhrVnkblSGUAP04gHOdWzZ60DSWkNDF+dLLhO4fJZp4ljZY+xtKBRwdLb33uNFdbCH1B6jBQ6cA+mCFITcjATb+evIRHmVE/mAaI11JdmSCuKYXsffbjBNJxtyI+NHIysMsqlHEQ1nX2gIB7x57CPL7/uXo0LnoGQjRbTu6c3LWWzGDdK1IdtWwKPop4WzLAbxxUbj8eKI1LOgay6Ot6APzviJLNwvGabqX7pNCIxJMmqX4B2RLfYw== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB3535.eurprd03.prod.outlook.com (2603:10a6:803:2c::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.20; Thu, 18 Jun 2020 02:50:50 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3088.028; Thu, 18 Jun 2020 02:50:50 +0000 From: Volodymyr Babchuk To: Jan Beulich Subject: Re: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks Thread-Topic: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks Thread-Index: AQHWQE+SUtF98x/3akmRxwBff1s+m6jbDBqAgAKp0oA= Date: Thu, 18 Jun 2020 02:50:50 +0000 Message-ID: <871rmd3x4m.fsf@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-3-volodymyr_babchuk@epam.com> <7d3e1741-b8bc-b522-8d64-20ca9c14744b@suse.com> In-Reply-To: <7d3e1741-b8bc-b522-8d64-20ca9c14744b@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.4.10; emacs 26.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 71cb6675-fcd5-4fde-f8ec-08d813326942 x-ms-traffictypediagnostic: VI1PR03MB3535: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4/kR/YRy8emoov4ZlH4hjiMsw45HCQ2/3YUYdJfptQDNgaoXZsiYdI1wVSEaSTnnwKgpMXBU4QvUfZtBya6VlQ3nd5D9CEQbe/kJw2h55N09ldpSOMB+m/dC9cBWZlWWK/5z2os0TKI88iXCNVMLqefmhuc5eEj/nBliLFxAUBMpQlxOc8+9Eht96ymh9Lwi/XSIkpYDUjNPm3vH6XCw1cpexiKK2oJtHtQnN9DZiWHx3J+dwtk6hJ0ATyIw0GLQW6YtDpeQdaHSL7fTPmOQaO/6lkF5v+fLlq5TLvKkmx7+m8HEO8wUcsS8hHm6+0y8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(136003)(39860400002)(346002)(366004)(86362001)(4326008)(36756003)(6486002)(5660300002)(6916009)(6512007)(2616005)(83380400001)(478600001)(55236004)(8676002)(186003)(26005)(64756008)(66476007)(91956017)(54906003)(6506007)(66946007)(66446008)(2906002)(71200400001)(76116006)(53546011)(8936002)(66556008)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: IfxbIq8PHkNaRyUv47Q0DJTIB0TaYCN19XMql2vkL+wosoXnh26iurjrwz8uSKPMIX5gSFoC0zboywO5I9r7FXWxSAahaDH0k+UfQaUseEq+2wom/xeQHcG8TuWhm/nab9S0Wl5PLz7nmb0jlPsGQeM1vSJHODWylaQZKvr58ktuLGTIlMndP7kZ7PIaG2suNDU/g9kiO3ka798Y82iN/yo0f9XnC0DDSiT9AqtMwICvEj6GDtTj4gWK/mc+5XdDb29IL6f/eJWGcAold8p1WpuGlQDfdw3mkQ8V17JEEKPcFbhl3vhwCIH0IUYCOSaWpfJMArQQBfsoiq6eqjk5aF5QHdLXFJ4kw5Bbi+y6NoT1KYVo8SvCVmtQxyd+4ziOi/Bseml46KD9A5cn444dD7zTctCyA+xhpRHr0Nwj6n5e9NUHSb5dZo1W3k+x2pUcbN8k8FNzAxvznmeDDRM8QTIFoTsnhPeNqLptqheRDew= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 71cb6675-fcd5-4fde-f8ec-08d813326942 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 02:50:50.7165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gfBOnV4DQiskfVXONBAgUBacypZv9HaJVK2eXD8nYtjvDVj4vcnn+YtexcITr+l8FO2TEXNp5GRbo9F4N2XNogjFiQOhhzrJUlwnl6HfQB4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB3535 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Jan, Jan Beulich writes: > On 12.06.2020 02:22, Volodymyr Babchuk wrote: >> In most cases hypervisor code performs guest-related jobs. Tasks like >> hypercall handling or MMIO access emulation are done for calling vCPU >> so it is okay to charge time spent in hypervisor to the current vCPU. >>=20 >> But, there are also tasks that are not originated from guests. This >> includes things like TLB flushing or running tasklets. We don't want >> to track time spent in this tasks to a total scheduling unit run >> time. So we need to track time spent in such housekeeping tasks >> separately. >>=20 >> Those hypervisor tasks are run in do_softirq() function, so we'll >> install our hooks there. > > I can see the point and desire, but it feels like you're moving from > one kind of unfairness to another: A softirq may very well be on > behalf of a specific vCPU, in which case not charging current should > lead to charging that specific one (which may still be current then). > Even more than for TLB flushes this may be relevant for the cases > where (on x86) we issue WBINVD on behalf of a guest. I'm agree with you. Something similar we discussed with Dario, but in do_IRQ() context: we can determine for which CPU we are handling interrupt and we can charge that vcpu for the spent time. The same stands correct for cases that you described: for some soft irqs there is a known benefactor, so we can charge it for the spent time. I and Dario agreed to implement this in the second stage. I'm working on the next version of the patches and I'll look at this more closely. There is a possibility that I'll introduce that feature. But I'll need some help from you or some other x86 expert. Anyways, are you okay with the general approach? We will work out the details, but I want to be sure that I'm moving in the right direction. --=20 Volodymyr Babchuk at EPAM= From xen-devel-bounces@lists.xenproject.org Thu Jun 18 02:58:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 02:58:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlklR-0008EQ-9p; Thu, 18 Jun 2020 02:58:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlklP-0008EL-Lc for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 02:58:51 +0000 X-Inumbo-ID: a2874dfe-b10f-11ea-ba39-12813bfff9fa Received: from EUR01-HE1-obe.outbound.protection.outlook.com (unknown [40.107.13.53]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a2874dfe-b10f-11ea-ba39-12813bfff9fa; Thu, 18 Jun 2020 02:58:50 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k6JMS3ze7Iw3W5InMQIZ1L0etn1zLdCy8bIYoNAgJgLdtSPssEFqlz3nHZeelUM0g1SvyB8TLdDCQpx6PEHNuCxLd6G4UqDrvuSWsHQzYCP4YUR2+iBl7tUcJHTTDEKve/gINKWQv+PGKLOyeM5teAx8YVNy0Bu7nUfC/pbrLRrhU25nruSEc4GzuzxmrY7n7OZmiPcNTYg/h7jS3ZC/YTAXkoIUlek/BLfbpTLDjlKqQA6kJXnBgKjdxMjXus3Ea8nxg4ATCC5sfILIwFpFuN2poRkz8zDM7eB3C2zIijURv4ch6/MYxB8iAvkw2p7oYoo/2b0YbMmtQgGv4ltqYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qEcOKTTivdcI/+SmPUGs4eCU2VxuzFEADnyOKg3Ucm0=; b=bT/UFjE0uf3aqkr/tO1E+8OpdnAMPv0vetuR5xnuZrTJ1eF/VDhE/wHnBBVBSjaBTxwblC48RYb8Ohk1eJehnHa8cogJAiOOpi5SJHlqBjIeu++q/N4mMDUGPuJWyYTrhtZVJxsOVConLOMUE8Wv9+V9hNprZF56VDVisysnXbDpc8rRKd0X8N1rgUaZscRDeV1K8F5JGwufXMt7vORlNPfFjDGZ8jFJcIbz2/2LY0+53Xwdl35IajBjXIlbD+05+pRV0DBVzDFsb9XEEkHgIfYcZBPHmrvreDpusDNpVFcrXMWN+rc/RFUS0qNaFy6z15bCcfdfvAbcSQ61yLJ+ew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qEcOKTTivdcI/+SmPUGs4eCU2VxuzFEADnyOKg3Ucm0=; b=EjzRCcz0O4B1CjZHFkd5Aod1c2Mm5UvIYnI5f+ctbZWMSFWh3o5Mu1XaDmBi8ZnelW1LQTtMjNf/4/MtVTQh6yBZZ37jMvFHNaIo6TGujYQhxkK36TLWGK3vJq7UxzVpWL6c0+8kllkjD/ZCwAQ3jHemf1uEICmKy4rfOBg81PYI63ASh5bqy41SbM2NH3+I6yASJTc3Vvt+zedladzJApabQoHX31WJhgBXncWUV7zxCJ7uCVmpnBHAjlzv3gJiYqrKqyI7vkcymHuPW50XaDbGF7ha5cxO5gPEzNqMmtyTSqnz5wP0dXk7zH1d4VR5lhWm57sDEqsKEepu6AvPxg== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB4624.eurprd03.prod.outlook.com (2603:10a6:803:60::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 18 Jun 2020 02:58:46 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3088.028; Thu, 18 Jun 2020 02:58:46 +0000 From: Volodymyr Babchuk To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Topic: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Index: AQHWQE+Tib/gTK49mk6bUudd1VvXZqjUa0CAgAB+fACAAANFAIAALvMAgAB0vgCAAISmAIAHosuA Date: Thu, 18 Jun 2020 02:58:46 +0000 Message-ID: <87tuz92i6y.fsf@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> <78910b5c27a3711726d53e931feb075c5cc4a64c.camel@suse.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.4.10; emacs 26.3 authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6cf8f49c-22ca-42c7-8192-08d8133384d1 x-ms-traffictypediagnostic: VI1PR03MB4624: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: isDQoQ4ijE+oHEIS87f9y4cl3SGrTy87KRuKTSrI6GNheZ7WXcwpwBZ4cuRyH/Rgmgra1AzpgZJEQRCCMGrPfi2Wx7mPxfwZxw0WfoKui05qkCI3yAbYLo5P7iU0WdpdT91J8I+gB6qRHUZ0bHkb6cvzyjUkvB/tu0ef7zm649bbm0vXaKnvlS5DahnsGKpN0DtNA781nlJYcLhOxDALlokvjcDEyD3cNsV0Rk9+JOzoIJOb7NkVaTfoVndTQdtSbb7uIkUfJ3wWKdtI7QZwsuTBC0IswBeU8JDv6AYxw67Nl0GDCmrp6IdDmAk9ZiUV9Ff2hJVEZsmKRnFl2RPwCw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(376002)(136003)(396003)(346002)(86362001)(36756003)(2616005)(6512007)(71200400001)(6486002)(5660300002)(4326008)(478600001)(53546011)(7416002)(8676002)(66574015)(6916009)(66556008)(64756008)(8936002)(76116006)(91956017)(316002)(66946007)(186003)(54906003)(26005)(2906002)(55236004)(66476007)(66446008)(83380400001)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: bgKKR0kMMS1BgA29u1AHmXRY6ylfRgI1w+T6uyvl6ypSjePLC5eWr9PHOI8H5eNdeFBAeioLjd7WTorEZEsRj04fk2FaUAIjRdSR0gQ4+5ZSPeGIbbAG5NUEK1GHN2XKUud41ai+/VKDtPTf8y0XyMlP+yLuSIyPzFsuHOdfTUvmh9qAIgHC0zqhPyYaB4ZLZLpFkqJBmgw1OhZQC81POH0TmbJivNzvMHjzMfWbpjGUuPeARdwikMYpLAcjslptBrvtf/n4GYyEykpU6DQmbtNAe2qVUKYyzvTzDXFSaLEwfBNhvcCHngZvYp65qk9vC1ESgyq2JSoUwzsTI9QZnc62dSgHdLT2A4eBhrsMm0BGkmISsyC3+2z57nYJwHMYZrnI/jBn4uJB9Jz0UdrSxNKtsSeSC7jjJGE3q3Ze9yvrHO1mg5saUT82E0m0ByEw4bpO7f5LoIu4cvqDJkTeCnyVESoNQk2+6IHJKrHvWXY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cf8f49c-22ca-42c7-8192-08d8133384d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 02:58:46.4118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8x8Id5VXW7l5pB7dwIvHy4p0vvBCXQEuTrDrD2jum1x0zqYjQ8bm7qCYa8vNvixTuyWxVLv92UEDjKSjdHE19BWVbI8XFLE8rYoLv7E2pGw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4624 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "julien@xen.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpIaSBKw7xyZ2VuLA0KDQpKw7xyZ2VuIEdyb8OfIHdyaXRlczoNCg0KPiBPbiAxMy4wNi4yMCAw MDoyNywgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+PiBPbiBGcmksIDIwMjAtMDYtMTIgYXQg MTc6MjkgKzAyMDAsIERhcmlvIEZhZ2dpb2xpIHdyb3RlOg0KPj4+IE9uIEZyaSwgMjAyMC0wNi0x MiBhdCAxNDo0MSArMDIwMCwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4+Pj4gT24gMTIuMDYuMjAg MTQ6MjksIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+Pj4+IE9uIDEyLzA2LzIwMjAgMDU6NTcsIErD vHJnZW4gR3Jvw58gd3JvdGU6DQo+Pj4+Pj4gT24gMTIuMDYuMjAgMDI6MjIsIFZvbG9keW15ciBC YWJjaHVrIHdyb3RlOg0KPj4+Pj4+PiBAQCAtOTk0LDkgKzk5OCwyMiBAQCBzX3RpbWVfdCBzY2hl ZF9nZXRfdGltZV9jb3JyZWN0aW9uKHN0cnVjdA0KPj4+Pj4+PiBzY2hlZF91bml0ICp1KQ0KPj4+ Pj4+PiAgICAgICAgICAgICAgICBicmVhazsNCj4+Pj4+Pj4gICAgICAgIH0NCj4+Pj4+Pj4gKyAg ICBzcGluX2xvY2tfaXJxc2F2ZSgmc2NoZWRfc3RhdF9sb2NrLCBmbGFncyk7DQo+Pj4+Pj4+ICsg ICAgc2NoZWRfc3RhdF9pcnFfdGltZSArPSBpcnE7DQo+Pj4+Pj4+ICsgICAgc2NoZWRfc3RhdF9o eXBfdGltZSArPSBoeXA7DQo+Pj4+Pj4+ICsgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmc2No ZWRfc3RhdF9sb2NrLCBmbGFncyk7DQo+Pj4+Pj4NCj4+Pj4+PiBQbGVhc2UgZG9uJ3QgdXNlIGEg bG9jay4gSnVzdCB1c2UgYWRkX3NpemVkKCkgaW5zdGVhZCB3aGljaCB3aWxsDQo+Pj4+Pj4gYWRk DQo+Pj4+Pj4gYXRvbWljYWxseS4NCj4+Pj4+DQo+Pj4+PiBJZiB3ZSBleHBlY3Qgc2NoZWRfZ2V0 X3RpbWVfY29ycmVjdGlvbiB0byBiZSBjYWxsZWQgY29uY3VycmVudGx5DQo+Pj4+PiB0aGVuIHdl DQo+Pj4+PiB3b3VsZCBuZWVkIHRvIGludHJvZHVjZSBhdG9taWM2NF90IG9yIGEgc3BpbiBsb2Nr Lg0KPj4+Pg0KPj4+PiBPciB3ZSBjb3VsZCB1c2UgcGVyY3B1IHZhcmlhYmxlcyBhbmQgYWRkIHRo ZSBjcHUgdmFsdWVzIHVwIHdoZW4NCj4+Pj4gZmV0Y2hpbmcgdGhlIHZhbHVlcy4NCj4+Pj4NCj4+ PiBZZXMsIGVpdGhlciBwZXJjcHUgb3IgYXRvbWljIGxvb2tzIG11Y2ggYmV0dGVyIHRoYW4gbG9j a2luZywgdG8gbWUsIGZvcg0KPj4+IHRoaXMuDQo+Pg0KPj4gTG9va3MgbGlrZSB3ZSBnb2luZyB0 byBoYXZlIGF0b21pYzY0X3QgYWZ0ZXIgYWxsLiBTbywgSSdsbCBwcmVmZXIgdG8gdG8NCj4+IHVz ZSBhdG9taWNzIHRoZXJlLg0KPg0KPiBQZXJmb3JtYW5jZSB3b3VsZCBiZSBiZXR0ZXIgdXNpbmcg cGVyY3B1IHZhcmlhYmxlcywgYXMgdGhvc2Ugd291bGQgYXZvaWQNCj4gdGhlIGNhY2hlbGluZSBt b3ZlZCBiZXR3ZWVuIGNwdXMgYSBsb3QuDQoNCkkgc2VlLiBCdXQgZG9uJ3Qgd2UgbmVlZCBsb2Nr aW5nIGluIHRoaXMgY2FzZT8gSSBjYW4gc2VlIHNjZW5hcmlvLCB3aGVuDQpvbmUgcENQVSB1cGRh dGVzIG93biBjb3VudGVycyB3aGlsZSBhbm90aGVyIHBDUFUgaXMgcmVhZGluZyB0aGVtLg0KDQpJ SVJDLCBBUk12OCBndWFyYW50ZWVzIHRoYXQgNjQgYml0IHJlYWQgb2YgYWxpZ25lZCBkYXRhIHdv dWxkIGJlDQpjb25zaXN0ZW50LiAiQ29uc2lzdGVudCIgaW4gdGhlIHNlbnNlIHRoYXQsIGZvciBl eGFtcGxlLCB3ZSB3b3VsZCBub3QNCnNlZSBsb3dlciAzMiBiaXRzIG9mIHRoZSBuZXcgdmFsdWUg YW5kIHVwcGVyIDMyIGJpdHMgb2YgdGhlIG9sZCB2YWx1ZS4NCg0KSSBjYW4ndCBzYXkgZm9yIHN1 cmUgYWJvdXQgQVJNdjcgYW5kIGFib3V0IHg4Ni4NCg0KLS0gDQpWb2xvZHlteXIgQmFiY2h1ayBh dCBFUEFN From xen-devel-bounces@lists.xenproject.org Thu Jun 18 03:21:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 03:21:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jll78-0002AU-5k; Thu, 18 Jun 2020 03:21:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jll76-00029t-8D for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 03:21:16 +0000 X-Inumbo-ID: c450daba-b112-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c450daba-b112-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 03:21:15 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id x6so4416410wrm.13 for ; Wed, 17 Jun 2020 20:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qvpzg+EGseIk50qngoPxiQumjg4bKxs079YWUd41tSE=; b=sUjVf736F+EGAL1puUx5HVQ/sgR1OF3km9e/uueJ5sz0w3xott1ck2oQXUEA7QuQaH Xs3yiY1DdoRRJ5ACl2pPV3xhQyVTml+wvY3sAxCDVyCanm4n62FzGuujP2XXO2x9Tpzj dcNy2//Fws8/wWmPW6G2fvdx3nfAulJybAUCsC4Dkhdag0HvKW55aQJ14hqg1JggLPPc uRj8wsbBvGSUhQ40QHjZRbbzvBUpAkztdecltHkjZpb/JqEKgsl11xTIsUzcqAm+UIzs QkNDr1wGHshsrUmJlkVhpZ97bqnf2T4pfLCrmrbzEupMAT64xe498HFf8duxRjpeBSKF PWhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qvpzg+EGseIk50qngoPxiQumjg4bKxs079YWUd41tSE=; b=dVL11PaTjDyBTypTeF7gnG1em1yoENk6bQnSli4sRm9Io6idjKAOrcA9VmAhACvtXG DMITbwtZNNNtz0ocBwHIddF9GrFFpP0XIrK6NFLeks1ng7SVhaoDNLxgFcVG2sLF7U4B ORDRIyljgMbtWszNF1R5AV5ZROgjOs4Lb8vkYUvl4768UnSj6Jbl5P6fV8nO0fJ2e4u4 0U4rcKBLmNBR8WVCLx9ck/rZgUQe8HVWVyzekqdbOl8x56dT5p91qLl3K8Eb3VyH2PiJ WLQsnCDzwga0+K2ZzWzdyNqMzroWCFjYEmX7gBUhUoZA6/Wqh7i6FcvesJ5AVA8QxhWj Tmeg== X-Gm-Message-State: AOAM5301+MqJjr4frTJBRaEPM1N2PVHxduztLx+/tW8gaQH23CkbZI2T 5o63k5CzSefptJ7S3WNYgKDJvzV3s5OcElBckzE= X-Google-Smtp-Source: ABdhPJzinIel4mrPjxDli5yNbTMczS1/88+RN4zOEEnVLHS0xT21oDNbv+fkt/k4wM+CWVoEn9Bb2flNlPX0w88ZJfE= X-Received: by 2002:adf:f707:: with SMTP id r7mr2451622wrp.390.1592450474521; Wed, 17 Jun 2020 20:21:14 -0700 (PDT) MIME-Version: 1.0 References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> In-Reply-To: <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> From: Tamas K Lengyel Date: Wed, 17 Jun 2020 21:20:39 -0600 Message-ID: Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > >> + > >> + a.mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT; > > > > This will not work for translated domains, ie: a PVH or HVM domain > > won't be able to use this interface since it has no way to request the > > mapping of a specific mfn into it's physmap. I think we need to take > > this into account when deciding how the interface should be, so that > > we don't corner ourselves with a PV only interface. > > Please be aware that this is only going to be used by Dom0. Is is well-supported case that somebody is using PVH/HVM Dom0? > > I think that all Virtual Machine Introspection stuff currently requires to have Dom0 PV. Our main goal is to have this working well in combo with VMI. FYI the VMI interface doesn't require a PV domain. It works fine from PVH dom0 or even from a secondary privileged HVM DomU as well, provided you have the right XSM policy to allow that. Tamas From xen-devel-bounces@lists.xenproject.org Thu Jun 18 05:22:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 05:22:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jln0Q-0003lk-2Z; Thu, 18 Jun 2020 05:22:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jln0P-0003lf-6z for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 05:22:29 +0000 X-Inumbo-ID: b2fa2aee-b123-11ea-ba44-12813bfff9fa Received: from EUR03-AM5-obe.outbound.protection.outlook.com (unknown [40.107.3.45]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b2fa2aee-b123-11ea-ba44-12813bfff9fa; Thu, 18 Jun 2020 05:22:27 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I6GKIBdIMKE+gy/+a69ifUTRvYaWIQRJRoGyAQ+6wZ/+Ou5jz3T8wTqZeGFu5BA/1X8L+NWQOLIfH5de+R8LjZFWTkl3bT92OkDS2w0SYmxq79BK4SQuqIq8wnI+cJXlqyeRO32HWkw4VRKGxlf0yGCPm95DkAZv+SitBOGQOb4WU6V5qaFZn3HnJQUOiLcJtgJewrX7KhQ6dsF4FF0qODicJATH2YX92RbHvy8o29lwDdW1ty2xWb/FKoEDyVFQx3Rg8v2S5wp0DG9IEnpwuRYaHc+eT7sZMdtbM6m6RA/eZfhRePOhmu8iLYXzidaCp9yJ3kgulqk5hyZvH5yckA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QxIO4zK4kC1Av4SYmK9kcqwiogrTrZz4OIr8UIlNOQk=; b=Ml+wlTxpq6RoLxA3bLGvYKbPG7QucY4O7nHVPHE6Kog+7VtGJ8S9U9RoWzktwKDNUOgxAIDsYwiegzeu2uDGwtGjYqY6Aj8qV/BGk3OuGGDSsQFI45MkCB2qYeTeg9SlyjH7qeH2hayW9tQMsPj8C01Q09rxVVN3x/He4Mfx2O3FYqtQKYskFl8e6wsxQsBRJFx2qSa9Zybh2ZW/GZ7ZwawMsgsctBhMs9YFy8Vw/WGlNPPD6lJspgUpvQw67Wz8EjzdGwETARRepQdTAVcxKskQwRgdExK9Aj2o6Uo/2/dMTOuYuGx6WpyF0zxVKJYziQGoRQUN56kNLoIVJExC+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QxIO4zK4kC1Av4SYmK9kcqwiogrTrZz4OIr8UIlNOQk=; b=dfC35ijRLgo7mPM7XtMTBW8wndugY+fHXPbvpJg6QDMdjrczCWGrJMHHIzugaGvaWcLkRVvsdZme/ge7yZBfeQDaDMneEYVqg/LwhIpRQnGT2IWavxH0+7SH4NM3yCerRdEXhgGCklIqoubQHrvFeXLB5AtxkxLELsW5/XmZnHCRlZV3XS4lqS5aPWP6HO1QExE7LedWMqJMFyRBWTkigJvztOK8dtsh0FmuZCrcGrilgBl8q/LSM8AazXOupJ7lbi15wHtXUz5WP86dND4wWNfNUWXOAGeA2tckLxvAfgVli5MvJCwkXAsRt9PtCsoeeX5jfyry8yfkQC7xHaPQ9Q== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB4606.eurprd03.prod.outlook.com (2603:10a6:803:55::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Thu, 18 Jun 2020 05:22:25 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3109.021; Thu, 18 Jun 2020 05:22:25 +0000 From: Oleksandr Andrushchenko To: Stefano Stabellini Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwA= Date: Thu, 18 Jun 2020 05:22:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5eafb01-79f9-4ac7-9ea0-08d8134795e6 x-ms-traffictypediagnostic: VI1PR03MB4606: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iX2dbkeUGBdKFNalIX0gxvDNRtp3+3YZTfpcClfG50BESJFGLucfcoY3OdmruNh2S5/whvE9swFjSpCxAVf5IRVaXWEV7YLV0MGsmKQ2jk9caOHvj6GgCNfA0JPYwQqP+C20Ai92XrXQ5VvVDg2YAcwqPkWU78sqIhxEEVaEYMcd8sPL7rWuodDB/+A4if/Dp7UpM194ucCzFQRHa+1uXFvSVf/rR9Ny16u/MJlszyHpVkz6MjUFimEFjs3ib5WdBFGSaUeVIdc+eMw27c7uye4BdOTFhjSNs3g7THT2B3o8ElwALEsoxgVLw3UguNaMfLJJpCYViiysELm8mq0K/sFSr9f3TTlVj1FwqJavmZkqnFG60n6Npq9N9uz2ORYz0ctles5/4AcbTIp6uZx4mg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(346002)(39860400002)(376002)(396003)(4326008)(2906002)(6512007)(186003)(26005)(6486002)(8676002)(316002)(66446008)(8936002)(53546011)(478600001)(71200400001)(91956017)(76116006)(966005)(86362001)(83380400001)(5660300002)(66946007)(31696002)(2616005)(64756008)(36756003)(6506007)(54906003)(31686004)(66556008)(6916009)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rUC020mOphN3vu/kPhHVGqZmAnQOjdMtst48DdMi2iuQ1eETVoJXti9tl4CAFb1JBwZPnbPoOoAIuZljhZL00rhOiePftXr3yhM4CkbLE6U9ivqlZdgywEcUgZgPp0LhQ/dqkOj0SmpAbcrDwRX/+O+Dgd3S0RGbSm8eIsEsHo2OqZmIKkgkCGzdmUbuEFaP9IQh0Qw8mbQT8TjG/LAmbulHpkImpUtFUA2fMgz9ptyO6wpZtF8yNBz+AJo7H0JPXwYPE0c2NFY4o94Y1AfhXEjZLtD8XrY3qa/5uOCwW26cP69IbIO0DwBoAEnYWC/xHQr1rJCti7E7+fQs8AVwzKTJ6IUVAFnM2FmFCFW7roCkFSEzOmOOQjmJ0JReRsxWRtUXXBX1zoVcxARUxZ3YCaO7yjBXVxlsJd26jYE38kU+rsWrUJOgkRZSiTuWZvJKclDDGrCu3V83WvRhTXgbQYwgUXd00KKwXgkvzVfzn5s= Content-Type: text/plain; charset="utf-8" Content-ID: <2899978B83A0974AA26DA274FF0B221F@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5eafb01-79f9-4ac7-9ea0-08d8134795e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 05:22:25.0180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Q2Ix+dS3O1uk2CbYrlpF3df3PM05oDpKxlFzm3GvKdjyzE84jalIread3dMCO3J5iY9IDi7Ga5+j0yVORFAh8PRMr6NmKxFwaJhvHqSctjDXHd0onb0hD9haAFvc0aTS X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4606 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Julien Grall , Roman Shaposhnik , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzQvMjAgNjozMSBQTSwgU3RlZmFubyBTdGFiZWxsaW5pIHdyb3RlOg0KPiBPbiBUaHUs IDQgSnVuIDIwMjAsIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPj4gT24gNi80LzIw IDQ6NTcgQU0sIFBlbmcgRmFuIHdyb3RlOg0KPj4+IEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47DQo+ Pj4+IE5hdGFsaXlhIEtvcm92a2luYSA8bWFsdXMuYnJhbmR5d2luZUBnbWFpbC5jb20+DQo+Pj4+ IFN1YmplY3Q6IFVFRkkgc3VwcG9ydCBpbiBBUk0gRG9tVXMNCj4+PiBXZSBoYXZlIG1hZGUgVS1C b290IHJ1biBpbnNpZGUgWEVOIERvbVUsIGJ1dCBqdXN0IG9ubHkgUFYgY29uc29sZSBwYXJ0LA0K Pj4+IG5vdCBpbXBsZW1lbnQgb3RoZXIgZnJvbnRlbmQgZHJpdmVycyBjdXJyZW50bHkuIFdvdWxk IHRoaXMgaGVscCBmb3IgeW91cg0KPj4+IGNhc2UgaWYgZW5hYmxlIEVGSSBpbiBVLUJvb3Q/DQo+ PiBXZWxsLCB3ZSBoYXZlIGEgd29ya2luZyBQViBibG9jayBpbXBsZW1lbnRhdGlvbiBvbiB0b3Ag b2YgdGhhdCBvbiBpTVg4DQo+Pg0KPj4gcGxhdGZvcm0sIG1vc3RseSBwb3J0ZWQgZnJvbSBtaW5p LW9zLiBDdXJyZW50bHkgd2UgYXJlIGZpbmFsaXppbmcgdGhlIHdvcmsNCj4+DQo+PiBhbmQgY2xl YW5pbmcgdXAgKGl0J3MgZ29pbmcgdG8gdGFrZSBhIHdlZWsgb3Igc28gaG9wZWZ1bGx5KS4gVGhl biwgd2Ugd2UnbGwgcG9zdA0KPj4NCj4+IGl0IG9uIG91ciBwdWJsaWMgZ2l0aHViLiBXZSBhcmUg YWxzbyB0aGlua2luZyBhYm91dCB1cHN0cmVhbWluZyB0aGUgd29yaywgYnV0IGl0IG1heQ0KPj4N Cj4+IHRha2UgcXVpdGUgc29tZSB0aW1lIGlmIHRoZSB3aG9sZSBpZGVhIGZpdHMgdS1ib290J3Mg dmlldyBvbiBzdWNoIGFuIGV4dGVuc2lvbiBhdCBhbGwuDQo+IFllcyBwbGVhc2UgdG8gYm90aCBv ZiB5b3UhIDotKQ0KPg0KPiBJbiB0aGUgbWVhbnRpbWUsIHdoaWxlIHdlIHdhaXQgZm9yIHRob3Nl IGNoYW5nZXMgdG8gZ28gdXBzdHJlYW0gaW4NCj4gdWJvb3QsIGNvdWxkIHlvdSBwbGVhc2UgcG9z dCBhIGJyYW5jaCBvbiBnaXRodWIgYW5kIGEgbGluayBvbiB0aGlzIGVtYWlsDQo+IHRocmVhZD8N Cg0KSXQgdG9vayBhIGJpdCBtb3JlIHRpbWUgdGhhbiB3ZSBleHBlY3RlZCwgYnV0IGhlcmUgd2Ug Z28gWzFdOg0KDQp0aGlzIGlzIGluIGZvcm0gb2YgYSBwdWxsLXJlcXVlc3QgYXMgd2Ugd291bGQg bG92ZSB0byBoZWFyIGZyb20gdGhlDQoNCmNvbW11bml0eSBhbmQgaXQgaXMgZWFzaWVyIHRvIGRp c2N1c3MgdGhlIGNvZGUgKHBsZWFzZSBsZWF2ZSBjb21tZW50cyB0aGVyZSkNCg0KMS4gVGhlcmUg aXMgY29kZSBvcmlnaW5hdGluZyBmcm9tIE1pbmlPUyBhbmQgd29yayBkb25lIGJ5IFBlbmcsIHNv IHdlDQoNCndvdWxkIGxpa2UgdG8gYXNrIHRoZSByZXNwZWN0aXZlIGNvcHlyaWdodCBvd25lcnMg dG8gcmFpc2UgdGhlaXIgaGFuZHMgYW5kDQoNCmxldCB1cyAqZml4IGluYXBwcm9wcmlhdGUgbGlj ZW5zaW5nKiBpZiBhbnkuDQoNCjIuIFBsZWFzZSBub3RlLCB0aGUgc2VyaWVzIGhhcyBhIEhBQ0sg dG8gbW92ZSB0aGUgUkFNIGJhc2UgYXMgaXQgaXMgZXhwZWN0ZWQgYnkNCg0Kb3VyIHRlc3QgcGxh dGZvcm0gKGlNWDgpLCBzbyBvdGhlcnMgd2lsbCBuZWVkIHRvIHJlbW92ZSBvciBtb2RpZnkgdGhh dC4NCg0KMy4gVGhlcmUgaXMgYSBsaW1pdGF0aW9uIGFscmVhZHkgbm90ZWQgYnkgUGVuZyB0aGF0 IHdlIGRvIG5vdCBoYXZlIHNlcmlhbCBvdXRwdXQNCg0KdW50aWwgTU1VIGlzIHNldHVwLCBzbyB3 ZSBoYXZlIGludHJvZHVjZWQgeGVuX2Vhcmx5X3ByaW50ayBoZWxwZXIgd2hpY2ggYWx3YXlzDQoN CndvcmtzLCBzbyB5b3UgY2FuIHVzZSB0aGF0IGZvciBlYXJseSBzdGFnZSBkZWJ1Z2dpbmcuDQoN CjQuIE1pbmltYWwgbWVtb3J5IHNpemUgc3VwcG9ydGVkIGlzIH4xMjlNIGJlY2F1c2Ugb2YgZHRi IHBsYWNlbWVudCBieSBYZW4gdG9vbHMNCg0KNS4gV2UgdXNlIC1EX19YRU5fXyB0byBhY2Nlc3Mg c29tZSBvZiB0aGUgaGlkZGVuIGRlZmluZXMgd2UgbmVlZCBzdWNoIGFzDQoNCkdVRVNUX1JBTTBf QkFTRSBhbmQgdGhlIGZyaWVuZHMgYXMgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IGJ1dCBtYW51YWxs eSBkZWZpbmluZyB0aGUNCg0Kc2FtZSB3aGljaCBpcyBub3QgY3V0ZS4NCg0KSGF2ZSBmdW4sDQoN CkFuYXN0YXNpaWEsIE9sZWtzYW5kcg0KDQo+DQo+IE1heWJlIHdlIHNob3VsZCBoYXZlIGEgd2lr aXBhZ2Ugb24gd2lraS54ZW5wcm9qZWN0Lm9yZyBhYm91dA0KPiB3b3JrLWluLXByb2dyZXNzIHVi b290IGl0ZW1zLg0KPg0KPg0KPg0KPg0KPj4+IFJlZ2FyZHMsDQo+Pj4gUGVuZy4NCj4+Pg0KPj4+ PiBIaSENCj4+Pj4NCj4+Pj4gd2l0aCBhIGxvdCBvZiBoZWxwIGZyb20gU3RlZmFubywgd2UncmUg Z2V0dGluZyBSUGk0IHN1cHBvcnQgaW4gUHJvamVjdCBFVkUNCj4+Pj4gcHJldHR5IG11Y2ggb24g cGFyIGJldHdlZW4gS1ZNIGFuZCBYZW4uDQo+Pj4+DQo+Pj4+IE9uZSBiaWcgYXJlYSB0aGF0IHN0 aWxsIHJlbWFpbnMgaXMgc3VwcG9ydGluZyBVRUZJIGJvb3Qgc2VxdWVuY2UgZm9yIERvbVVzLg0K Pj4+PiBXaXRoIEtWTSwgZ2l2ZW4gdGhlIHFlbXUgdmlydCBkZXZpY2UgbW9kZWwgdGhpcyBpcyBh cyBzaW1wbGUgYXMgdXNpbmcgZWl0aGVyDQo+Pj4+IHN0b2NrIFVFRkkgYnVpbGQgZm9yIGFybSBv ciBldmVuIFUtQm9vdCBFRkkgZW11bGF0aW9uIGVudmlyb25tZW50IGFuZA0KPj4+PiBwYXNzaW5n IGl0IHZpYSAtYmlvcyBvcHRpb24uDQo+Pj4+DQo+Pj4+IE9idmlvdXNseSB3aXRoIFhlbiBvbiBB Uk0gd2UgZG9uJ3QgaGF2ZSB0aGUgZGV2aWNlIG1vZGVsIHNvIG15DQo+Pj4+IHVuZGVyc3RhbmRp bmcgaXMgdGhhdCB0aGUgZWFzaWVzdCB3YXkgd2UgY2FuIHN1cHBvcnQgaXQgd291bGQgYmUgdG8g cG9ydA0KPj4+PiBVRUZJJ3MgT3ZtZlBrZy9Pdm1mWGVuIHRhcmdldCB0byBBUk0gKGl0IHNlZW1z IHRvIGJlIGN1cnJlbnRseSBleGNsdXNpdmVseQ0KPj4+PiBYNjQpLg0KPj4+Pg0KPj4+PiBTbyBo ZXJlJ3MgbXkgZmlyc3QgcXVlc3Rpb246IGlmIHRoZXJlJ3MgYW55Ym9keSBvbiB0aGlzIGxpc3Qg d2hvIGhhZCBhIGhhbmQgaW4NCj4+Pj4gaW1wbGVtZW50aW5nIE92bWZQa2cvT3ZtZlhlbiBjYW4g eW91IHBsZWFzZSBzaGFyZSB5b3VyIHRob3VnaHRzIG9uIGhvdw0KPj4+PiBtdWNoIHdvcmsgdGhh dCBwb3J0IG1heSBiZSAob3Igd2hldGhlciBpdCBpcyBldmVuIGZlYXNpYmxlIC0tIEkgbWF5IHRv dGFsbHkgYmUNCj4+Pj4gbWlzc2luZyBzb21ldGhpbmcgcmVhbGx5IG9idmlvdXMgaGVyZSkuDQo+ Pj4+DQo+Pj4+IEFuZCBhcyBsb25nIGFzIEkndmUgZ290IHlvdXIgYXR0ZW50aW9uOiB0d28gbW9y ZSBxdWVzdGlvbnM6DQo+Pj4+ICAgICAgMS4uIGNvbXBhcmVkIHRvIHRoZSBhYm92ZSwgd291bGQg cG9ydGluZyBwdmdydWIgdG8gQVJNIGJlIGFueQ0KPj4+PiAgICAgIGVhc2llciBvciBtb3JlIGRp ZmZpY3VsdD8NCj4+Pj4NCj4+Pj4gICAgICAyLiBzYW1lIHF1ZXN0aW9uIGZvciB0ZWFjaGluZyB1 LWJvb3QgYWJvdXQgUFYgY2FsbHMuDQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4gUm9tYW4uDQo+ Pj4+DQo+Pj4+IFAuUy4gT2ggYW5kIEkgZ3Vlc3MgYmV0d2VlbjoNCj4+Pj4gICAgICAwLiBPdm1m UGtnL092bWZYZW4gb24gQVJNNjQNCj4+Pj4gICAgICAxLiBwdmdydWIgb24gQVJNNjQNCj4+Pj4g ICAgICAyLiB1LWJvb3QvRUZJIGVtdWxhdGlvbiB3aXRoIFBWIGNhbGxzIGJhY2tlbmQgSSBkaWRu J3QgbWlzcyBhbnkgb3RoZXINCj4+Pj4gb2J2aW91cyB3YXkgb2YgbWFraW5nIFVFRkktYXdhcmUg Vk0gaW1hZ2VzIHRvIGJvb3Qgb24gWGVuIEFSTTY0IERvbVUsDQo+Pj4+IHJpZ2h0Pw0KWzFdIGh0 dHBzOi8vZ2l0aHViLmNvbS94ZW4tdHJvb3BzL3UtYm9vdC9wdWxsLzE= From xen-devel-bounces@lists.xenproject.org Thu Jun 18 06:30:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 06:30:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlo40-0000yu-3f; Thu, 18 Jun 2020 06:30:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlo3z-0000yp-5N for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 06:30:15 +0000 X-Inumbo-ID: 2aecf76c-b12d-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2aecf76c-b12d-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 06:30:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 46947ACBD; Thu, 18 Jun 2020 06:30:17 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE To: Tamas K Lengyel References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 08:30:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Wei Liu , Paul Durrant , Andrew Cooper , Jun Nakajima , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17.06.2020 18:19, Tamas K Lengyel wrote: > While forking VMs running a small RTOS system (Zephyr) a Xen crash has been > observed due to a mm-lock order violation while copying the HVM CPU context > from the parent. This issue has been identified to be due to > hap_update_paging_modes first getting a lock on the gfn using get_gfn. This > call also creates a shared entry in the fork's memory map for the cr3 gfn. The > function later calls hap_update_cr3 while holding the paging_lock, which > results in the lock-order violation in vmx_load_pdptrs when it tries to unshare > the above entry when it grabs the page with the P2M_UNSHARE flag set. > > Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was > unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure > the p2m is properly populated and to avoid the lock-order violation we > observed. Using P2M_ALLOC is not going to address the original problem though afaict: You may hit the mem_sharing_fork_page() path that way, and via nominate_page() => __grab_shared_page() => mem_sharing_page_lock() you'd run into a lock order violation again. The change is an improvement, so I'd be fine with it going in this way, but only as long as the description mentions that there's still an open issue here (which may be non-trivial to address). Or perhaps combining with your v1 change is the way to go (for now or even permanently)? Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 06:34:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 06:34:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlo8U-00018o-Mv; Thu, 18 Jun 2020 06:34:54 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlo8T-00018j-6k for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 06:34:53 +0000 X-Inumbo-ID: d000fb36-b12d-11ea-ba4c-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d000fb36-b12d-11ea-ba4c-12813bfff9fa; Thu, 18 Jun 2020 06:34:51 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 52BDAAC7F; Thu, 18 Jun 2020 06:34:54 +0000 (UTC) Subject: Re: [RFC PATCH v1 2/6] sched: track time spent in hypervisor tasks To: Volodymyr Babchuk References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-3-volodymyr_babchuk@epam.com> <7d3e1741-b8bc-b522-8d64-20ca9c14744b@suse.com> <871rmd3x4m.fsf@epam.com> From: Jan Beulich Message-ID: <66826d88-00e6-c618-1f8d-1ca80b247c43@suse.com> Date: Thu, 18 Jun 2020 08:34:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <871rmd3x4m.fsf@epam.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Dario Faggioli , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 04:50, Volodymyr Babchuk wrote: > Anyways, are you okay with the general approach? We will work out the > details, but I want to be sure that I'm moving in the right direction. I'm certainly okay with the goal; I didn't look closely enough to say I'm okay with the approach - I trust Dario there. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 06:38:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 06:38:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jloBw-0001I1-6u; Thu, 18 Jun 2020 06:38:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jloBv-0001Hw-F8 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 06:38:27 +0000 X-Inumbo-ID: 504bccf8-b12e-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 504bccf8-b12e-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 06:38:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 9AA4EAC7F; Thu, 18 Jun 2020 06:38:29 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: Jan Beulich Subject: [PATCH] VT-x: simplify/clarify vmx_load_pdptrs() Message-ID: Date: Thu, 18 Jun 2020 08:38:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Kevin Tian , Wei Liu , Jun Nakajima , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" * Guests outside of long mode can't have PCID enabled. Drop the respective check to make more obvious that there's no security issue (from potentially accessing past the mapped page's boundary). * Only the low 32 bits of CR3 are relevant outside of long mode, even if they remained unchanged after leaving that mode. * Drop the unnecessary and badly typed local variable p. * Don't open-code hvm_long_mode_active() (and extend this to the related nested VT-x code). * Constify guest_pdptes to clarify that we're only reading from the page. Signed-off-by: Jan Beulich --- This is intentionally not addressing any of the other shortcomings of the function, as was done by the previously posted https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg01790.html. This will need to be the subject of a further change. --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1312,17 +1312,16 @@ static void vmx_set_interrupt_shadow(str static void vmx_load_pdptrs(struct vcpu *v) { - unsigned long cr3 = v->arch.hvm.guest_cr[3]; - uint64_t *guest_pdptes; + uint32_t cr3 = v->arch.hvm.guest_cr[3]; + const uint64_t *guest_pdptes; struct page_info *page; p2m_type_t p2mt; - char *p; /* EPT needs to load PDPTRS into VMCS for PAE. */ - if ( !hvm_pae_enabled(v) || (v->arch.hvm.guest_efer & EFER_LMA) ) + if ( !hvm_pae_enabled(v) || hvm_long_mode_active(v) ) return; - if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) ) + if ( cr3 & 0x1f ) goto crash; page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE); @@ -1332,14 +1331,12 @@ static void vmx_load_pdptrs(struct vcpu * queue, but this is the wrong place. We're holding at least * the paging lock */ gdprintk(XENLOG_ERR, - "Bad cr3 on load pdptrs gfn %lx type %d\n", + "Bad cr3 on load pdptrs gfn %"PRIx32" type %d\n", cr3 >> PAGE_SHIFT, (int) p2mt); goto crash; } - p = __map_domain_page(page); - - guest_pdptes = (uint64_t *)(p + (cr3 & ~PAGE_MASK)); + guest_pdptes = __map_domain_page(page) + (cr3 & ~PAGE_MASK); /* * We do not check the PDPTRs for validity. The CPU will do this during @@ -1356,7 +1353,7 @@ static void vmx_load_pdptrs(struct vcpu vmx_vmcs_exit(v); - unmap_domain_page(p); + unmap_domain_page(guest_pdptes); put_page(page); return; --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1234,7 +1234,7 @@ static void virtual_vmentry(struct cpu_u paging_update_paging_modes(v); if ( nvmx_ept_enabled(v) && hvm_pae_enabled(v) && - !(v->arch.hvm.guest_efer & EFER_LMA) ) + !hvm_long_mode_active(v) ) vvmcs_to_shadow_bulk(v, ARRAY_SIZE(gpdpte_fields), gpdpte_fields); regs->rip = get_vvmcs(v, GUEST_RIP); @@ -1437,7 +1437,7 @@ static void virtual_vmexit(struct cpu_us sync_exception_state(v); if ( nvmx_ept_enabled(v) && hvm_pae_enabled(v) && - !(v->arch.hvm.guest_efer & EFER_LMA) ) + !hvm_long_mode_active(v) ) shadow_to_vvmcs_bulk(v, ARRAY_SIZE(gpdpte_fields), gpdpte_fields); /* This will clear current pCPU bit in p2m->dirty_cpumask */ From xen-devel-bounces@lists.xenproject.org Thu Jun 18 07:00:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 07:00:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jloXZ-0003eD-3t; Thu, 18 Jun 2020 07:00:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jloXY-0003e8-7U for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 07:00:48 +0000 X-Inumbo-ID: 6f38d2e8-b131-11ea-bb8b-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6f38d2e8-b131-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 07:00:47 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: BaySQT8b1hKl0fkjL+lkUs3P1OxEcaeZTre6McMWNud+f3RNJskv9tlaBBtYkHLwBYG8JAardi UpgY8wsfKK0oaioTxdAfPRghFbVArxrGLfLhAZPDlXKyTirGQOz/7Rw9Ydy2V/zVk9q2Q8NJWk v0AziURMk/BI6jSr1+NQ4K8Zg8ZQwgcXl+VGSk1i26lNYYpZK7jCX/6gUZb+puhKSjSJbbz2HL DjsIXlTZ0LcwACripx81wFY0uaXpBMP/a5vSZaEwUrJ3U16D6ynNSAFSei6dHA+XYuNFVgg0py /Wg= X-SBRS: 2.7 X-MesageID: 20569672 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,525,1583211600"; d="scan'208";a="20569672" Date: Thu, 18 Jun 2020 09:00:35 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring Message-ID: <20200618070035.GD735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <20200617092103.GZ735@Air-de-Roger> <20200617125339.GB735@Air-de-Roger> <1683804232.9278740.1592441777496.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1683804232.9278740.1592441777496.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , "Tian, Kevin" , Stefano Stabellini , "Kang, Luwei" , "Nakajima, Jun" , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 02:56:17AM +0200, Michał Leszczyński wrote: > ----- 18 cze 2020 o 1:29, Kang, Luwei luwei.kang@intel.com napisał(a): > > >> > > How does KVM deal with this, do they insert/modify trace packets on > >> > > trapped and emulated instructions by the VMM? > >> > > >> > The KVM includes instruction decoder and > >> emulator(arch/x86/kvm/emulate.c), and the guest's memory can be set to > >> write-protect as well. But it doesn't support Intel PT packets software > >> emulator. > >> For KVM, the Intel PT feature will be exposed to KVM guest and KVM guest can > >> use Intel PT feature like native. > >> > >> But if such feature is exposed to the guest for it's own usage, won't it be > >> missing packets for instructions emulated by the VMM? > > > > If setting the guest's memory write-protect, I think yes. > > > Thus, I propose to leave it as it is right now. If somebody is purposely altering the VM state then he/she should consult not only the IPT but also understand what was done "in the meantime" by additional features, e.g. when something was altered by vm_event callback. As Tamas said previously, we usually just want to see certain path leading to vmexit. > > Please also note that there is a PTWRITE instruction that could be used in the future in order to add custom payloads/hints to the PT trace, when needed. Yes, I think the usage of IPT by a third party against a guest is fine, as such third party can also use introspection and get the information about the emulated instructions. OTOH exposing the feature to the guest itself for it's own usage seems wrong without adding the packets related to the instructions emulated. I understand the current series only cares about the first option, so that's perfectly fine. Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 07:18:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 07:18:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jloot-0004f5-LN; Thu, 18 Jun 2020 07:18:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jloos-0004f0-4n for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 07:18:42 +0000 X-Inumbo-ID: efa0bfd4-b133-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id efa0bfd4-b133-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 07:18:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8C2A5AD12; Thu, 18 Jun 2020 07:18:39 +0000 (UTC) Subject: Re: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge To: Andrew Cooper References: <20200615141532.1927-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 09:18:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200615141532.1927-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15.06.2020 16:15, Andrew Cooper wrote: > This is some work in light of IvyBridge not gaining microcode to combat SRBDS > / XSA-320. It is a mix of some work I'd planned for 4.15, and some patches > posted already and delayed due to dependence's I'd discovered after-the-fact. > > This provides a more user-friendly way of making IvyBridge safe by default > without encountering migration incompatibilities. > > In terms of functionality, it finishes the "fresh boot" vs "migrate/restore > from pre-4.14" split in the libxc CPUID logic, and uses this to let us safely > hide features by default without breaking the "divine what a guest may have > seen previously" logic on migrate. > > On top of that, we hide RDRAND by default to mitigate XSA-320. > > Additionally, take the opportunity of finally getting this logic working to > hide MPX by default (as posted previously), due to upcoming Intel timelines. > > Request for 4.14. The IvyBridge angle only became apparent after the public > embargo on Tue 9th. Otherwise, I would have made a concerted effort to get > this logic sorted sooner and/or part of XSA-320 itself. > > Strictly speaking, patches 1-4 aren't necessary, but without them the logic is > very confusing to follow, particularly the reasoning about the safely of later > changes. As it is a simple set of transforms, we're better with them than > without. > > Also, the MPX patch isn't related to the RDRAND issue, but I was planning to > get it into 4.14 already, until realising that the migration path was broken. > Now that the path is fixed for the RDRAND issue, include the MPX patch as it > pertains to future hardware compatibility (and would be backported to 4.14.1 > if it misses 4.14.0). Just to be sure - it is my understanding that none of this can sensibly be backported, even if it was nice for us to take care of the IvyBridge situation on older trees as well. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 08:26:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 08:26:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlprv-0002LS-29; Thu, 18 Jun 2020 08:25:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlpru-0002LN-Ah for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 08:25:54 +0000 X-Inumbo-ID: 529870ba-b13d-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 529870ba-b13d-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 08:25:53 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: aUzc8Ydkiseqfeq4nFLSZUDWWcmloLHuLBYYqBl0Io+PGkCEaQbMmNeBdQRwjcafxXNUqfR/mZ ZoJ2rdDztBdhKLIteYIiVvMYpmxHjxmuUgMYo04zGasWtZpiV7+rRVlV74XpEOqw2VPp6/BsL9 A8RCFf4CipTWeWoIkF0SCJ5QZoa8vPBR1RDuQETD/K8M6rPbY+qxAsVVj1+iFzL4b2gZ/ukF9y b79mynIbqnzHHmt9CPVgF2cSSpLLIBjez+wsAxiP2Ti5fZ1kI+Mc+mj+0Fuz16PL3wK2uE/o3q kug= X-SBRS: 2.7 X-MesageID: 20345651 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20345651" Date: Thu, 18 Jun 2020 10:25:39 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring Message-ID: <20200618082539.GE735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> <1348695738.9265003.1592425220928.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1348695738.9265003.1592425220928.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 10:20:20PM +0200, Michał Leszczyński wrote: > ----- 17 cze 2020 o 18:19, Andrew Cooper andrew.cooper3@citrix.com napisał(a): > > > On 17/06/2020 04:02, Tamas K Lengyel wrote: > >> On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper wrote: > >>> On 16/06/2020 19:47, Michał Leszczyński wrote: > >>>> ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com napisał(a): > >>>> > >>>>> Are there any restrictions on EPT being enabled in the first place? I'm > >>>>> not aware of any, and in principle we could use this functionality for > >>>>> PV guests as well (using the CPL filter). Therefore, I think it would > >>>>> be helpful to not tie the functionality to HVM guests, even if that is > >>>>> the only option enabled to start with. > >>>> I think at the moment it's not required to have EPT. This patch series doesn't > >>>> use any translation feature flags, so the output address is always a machine > >>>> physical address, regardless of context. I will check if it could be easily > >>>> used with PV. > >>> If its trivial to add PV support then please do. If its not, then don't > >>> feel obliged, but please do at least consider how PV support might look > >>> in the eventual feature. > >>> > >>> (Generally speaking, considering "how would I make this work in other > >>> modes where it is possible" leads to a better design.) > >>> > >>>>> The buffer mapping and creation logic is fairly problematic. Instead of > >>>>> fighting with another opencoded example, take a look at the IOREQ > >>>>> server's use of "acquire resource" which is a mapping interface which > >>>>> supports allocating memory on behalf of the guest, outside of the guest > >>>>> memory, for use by control tools. > >>>>> > > > One thing that remains unclear to me is the "acquire resource" part. Could you give some more details on that? > > Assuming that buffers are allocated right from the domain creation, what mechanism (instead of xc_map_foreign_range) should I use to map the IPT buffers into Dom0? Take a look at demu's demu_initialize function [0] (and it's usage of xenforeignmemory_map_resource), you likely need something similar for the trace buffers, introducing a new XENMEM_resource_trace_data kind of resource (naming subject to change), and use the id field in xen_mem_acquire_resource to signal which vCPU buffer you want to map. That's usable by both PV and HVM guests. Roger. [0] http://xenbits.xen.org/gitweb/?p=people/pauldu/demu.git;a=blob;f=demu.c;h=f785b394d0cf141dffa05bdddecf338214358aea;hb=refs/heads/master#l453 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 08:47:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 08:47:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlqCY-00040u-N7; Thu, 18 Jun 2020 08:47:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlqCX-00040p-Gb for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 08:47:13 +0000 X-Inumbo-ID: 4cc3b0ac-b140-11ea-ba55-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4cc3b0ac-b140-11ea-ba55-12813bfff9fa; Thu, 18 Jun 2020 08:47:11 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: PcQvqfoHE7Vw3F5SVbEBQSalkL2Rlin8QEAfeUiJnGk0dOGFgcRRB1TkGMgpjCADKHAao4NgPO u5SI9nUOytKNNDkSX9/p8kPOd+juGqH/ydQ0gheFchN7QD5SBvjZBeZssv3xLitn0ZKmllolZ6 Ic0+PWUQ5yUgiaM9A0vU5XdYTSEvtgRJSrVIlgbWLV/KLl7ShFroxFHtYqOR7Y+Cry5JjHade2 H7l0UVmyQdMNNquzLlXFZIYbJef4Dk4R5ichgipwBIWQAglp/Yg+Uf58MVT9QXa4jvPnD/6zv8 QrU= X-SBRS: 2.7 X-MesageID: 20575818 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20575818" Date: Thu, 18 Jun 2020 10:46:56 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op Message-ID: <20200618084656.GF735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 09:13:05PM +0200, Michał Leszczyński wrote: > ----- 16 cze 2020 o 19:23, Roger Pau Monné roger.pau@citrix.com napisał(a): > > > On Tue, Jun 16, 2020 at 05:22:06PM +0200, Michał Leszczyński wrote: > >> + buf_order = get_order_from_bytes(a.size); > >> + > >> + if ( (a.size >> PAGE_SHIFT) != (1 << buf_order) ) { > > > > Oh here is the check. I think you can move this with the checks above > > by doing a.size & ~PAGE_MASK. > > > I belive it's more strict than a.size & ~PAGE_MASK. I think that CPU expects that the buffer size is a power of 2, so you can have 64 MB or 128 MB, but not 96 MB buffer. Oh, sorry, didn't realize. I think it's clearer to check if a size is not a power of two by doing (size & (size - 1)). This could be joined with the previous checks. > > There are a couple of options here, maybe the caller could provide > > it's own buffer, then Xen would take an extra reference to those pages > > and setup them to be used as buffers. > > > > Another alternative would be to use domhep memory but not let the > > caller map it directly, and instead introduce a hypercall to copy > > from the internal Xen buffer into a user-provided one. > > > > How much memory is used on average by those buffers? That would help > > decide a model that would best fit the usage. > > > From 4 kB to 4 GB. Right now I use 128 MB buffers and it takes just a few seconds to fill them up completely. > > I think I've just copied the pattern which is already present in Xen's code, e.g. interfaces used by xenbaked/xentrace tools. I think using XENMEM_acquire_resource will result in cleaner code overall, it would also avoid having to share the pages with Xen AFAICT. It's also more inline with how new interfaces deal with this kind of memory sharing. Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 08:52:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 08:52:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlqHS-0004pD-Eo; Thu, 18 Jun 2020 08:52:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlqHQ-0004p8-S8 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 08:52:16 +0000 X-Inumbo-ID: 019f65b8-b141-11ea-ba55-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 019f65b8-b141-11ea-ba55-12813bfff9fa; Thu, 18 Jun 2020 08:52:16 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: hN2MGqKixUcU/enmJS6pEMBaRvB+ruUwsN6IPousl08imhb74/Xf0fNFYUGos+2LuEifq/5rN7 V3G3sKHuio628fvFouUyGCwbs/9+661kUI923jMmEmCIqVj93+dy6YM+4U2bmvrWMgfWPc3Ru8 lls2OcduGGVIos4EeBB1QXW0I2hP3VD12zQW9dL85YWGP5b0Lk6BYOdrNtd8I/kUzv7m/Uzhln uwKsfdgizCVRZuiE5e64a9M56VLAjO+3OUOxJKwvWfBd/ALt5LG39cB0FmrwFIE3TCuV1zmdU/ wbk= X-SBRS: 2.7 X-MesageID: 20649486 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20649486" Date: Thu, 18 Jun 2020 10:52:08 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit Message-ID: <20200618085208.GG735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> <20200616173857.GU735@Air-de-Roger> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> <20200617090942.GY735@Air-de-Roger> <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> <20200617125146.GA735@Air-de-Roger> <5ad138bb-9195-a8de-5566-468db553422e@citrix.com> <219980918.9257247.1592420217746.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <219980918.9257247.1592420217746.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , luwei kang , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 08:56:57PM +0200, Michał Leszczyński wrote: > ----- 17 cze 2020 o 17:14, Andrew Cooper andrew.cooper3@citrix.com napisał(a): > > > On 17/06/2020 13:51, Roger Pau Monné wrote: > >> On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote: > >>> ----- 17 cze 2020 o 11:09, Roger Pau Monné roger.pau@citrix.com napisał(a): > >>> > >>>> 24 Virtual Machine Control Structures -> 24.8 VM-entry Control Fields -> 24.8.1 > >>>> VM-Entry Controls > >>>> Software should consult the VMX capability MSRs IA32_VMX_ENTRY_CTLS to determine > >>>> how it should set the reserved bits. > >>> Please look at bit position 18 "Load IA32_RTIT_CTL". > >> I think this is something different from what I was referring to. > >> Those options you refer to (load/clear IA32_RTIT_CTL) deal with > >> loading/storing a specific field on the vmcs that maps to the guest > >> IA32_RTIT_CTL. > >> > >> OTOH MSR load lists can be used to load and store any arbitrary MSR on > >> vmentry/vmexit, see section 26.4 LOADING MSRS on the SDM. There's > >> already infrastructure on Xen to do so, see vmx_{add/del/find}_msr. > > > > If I remember the historic roadmaps correctly, there are 3 cases. > > > > The first hardware to support PT (Broadwell?) prohibited its use > > completely in VMX operations.  In this case, we can use it to trace PV > > guests iff we don't enable VMX in hardware to begin with. > > > > This was relaxed in later hardware (Skylake?) to permit use within VMX > > operations, but without any help in the VMCS.  (i.e. manual context > > switching per this patch, or MSR load lists as noted in the SDM.) > > > > Subsequent support for "virtualised PT" was added (IceLake?) which adds > > the load/save controls, and the ability to translate the output buffer > > under EPT. > > > > > > All of this is from memory so I'm quite possibly wrong with details, but > > I believe this is why the current complexity exists. > > > > ~Andrew > > > I've managed to toggle MSR_IA32_RTIT_CTL values using MSR load lists, as in: > > > 35.5.2.2 Guest-Only Tracing > > "For this usage, VM-entry is programmed to enable trace packet generation, while VM-exit is programmed to clear MSR_IA32_RTIT_CTL.TraceEn so as to disable trace-packet generation in the host." > > it actually helped a bit. With patch v1 there were parts of hypervisor recorded in the trace (i.e. the moment between TRACE_EN being set and actual vmenter, and the moment between vmexit and TRACE_EN being unset). Using MSR load list this was eliminated. This change will be reflected in patch v2. > > > I can't however implement any working scenario in which all these MSRs are managed using MSR load lists. As in "35.3.3 Flushing Trace Output": packets are buffered internally and are flushed only when TRACE_EN bit in MSR_IA32_RTIT_CTL is set to 0. The values of remaining registers will be stable after everything is serialized. I think this is too complex for the load lists alone. I belive that currently SDM instructs to use load lists only for toggling this single bit on-or-off. I think that's exactly what we want: handling TraceEn at vmentry/vmexit, so that no hypervisor packets are recorded. The rest of the MSRs can be handled in VMM mode without issues. Switching those on every vmentry/vmexit would also add more overhead that needed, since I assume they don't need to be modified on every entry/exit? > > Thus, for now I propose to stay with MSR_IA32_RTIT_CTL being managed by MSR load lists and the rest of related MSRs being managed manually. Yes, that' seems like a good approach. Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 09:37:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 09:37:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlqzB-0008Cz-54; Thu, 18 Jun 2020 09:37:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlqzA-0008Cu-KH for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 09:37:28 +0000 X-Inumbo-ID: 522e9a64-b147-11ea-ba63-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 522e9a64-b147-11ea-ba63-12813bfff9fa; Thu, 18 Jun 2020 09:37:27 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: aoLNRDg4pKbFug4ENtnfp9oCqMg/u3r1J0M6KeKYsxGpYbVpe/zKRIsWviehbpxL9DnZUY+OZv BZ0CP4xpZNtS9sJzxcKVarKodKcqQ+oGLijt8CXDxQfk7tn5pmBihqsXPshZd4X9sgN5cwLw3d M1GOT+a8AB+aXOyyQWxEoiNb1RHauLSRAO4uh90U5OTVdFoZUERHdzjqmPXSxaI6y4wg5IiSHg ATZj0oWgSs8jCnQGMRw1E8qxc3NguSFrzqyfuAXVMziyJUjtzJ//YpXXhCuup13omBgT+Ofo5X ziw= X-SBRS: 2.7 X-MesageID: 20349738 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20349738" Subject: Re: [PATCH for-4.14 0/9] XSA-320 follow for IvyBridge To: Jan Beulich References: <20200615141532.1927-1-andrew.cooper3@citrix.com> From: Andrew Cooper Message-ID: <498c3f3d-d461-40b6-b5a4-4cb3eceee014@citrix.com> Date: Thu, 18 Jun 2020 10:37:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Ian Jackson , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18/06/2020 08:18, Jan Beulich wrote: > On 15.06.2020 16:15, Andrew Cooper wrote: >> This is some work in light of IvyBridge not gaining microcode to combat SRBDS >> / XSA-320. It is a mix of some work I'd planned for 4.15, and some patches >> posted already and delayed due to dependence's I'd discovered after-the-fact. >> >> This provides a more user-friendly way of making IvyBridge safe by default >> without encountering migration incompatibilities. >> >> In terms of functionality, it finishes the "fresh boot" vs "migrate/restore >> from pre-4.14" split in the libxc CPUID logic, and uses this to let us safely >> hide features by default without breaking the "divine what a guest may have >> seen previously" logic on migrate. >> >> On top of that, we hide RDRAND by default to mitigate XSA-320. >> >> Additionally, take the opportunity of finally getting this logic working to >> hide MPX by default (as posted previously), due to upcoming Intel timelines. >> >> Request for 4.14. The IvyBridge angle only became apparent after the public >> embargo on Tue 9th. Otherwise, I would have made a concerted effort to get >> this logic sorted sooner and/or part of XSA-320 itself. >> >> Strictly speaking, patches 1-4 aren't necessary, but without them the logic is >> very confusing to follow, particularly the reasoning about the safely of later >> changes. As it is a simple set of transforms, we're better with them than >> without. >> >> Also, the MPX patch isn't related to the RDRAND issue, but I was planning to >> get it into 4.14 already, until realising that the migration path was broken. >> Now that the path is fixed for the RDRAND issue, include the MPX patch as it >> pertains to future hardware compatibility (and would be backported to 4.14.1 >> if it misses 4.14.0). > Just to be sure - it is my understanding that none of this can sensibly > be backported, even if it was nice for us to take care of the IvyBridge > situation on older trees as well. Correct.  Much as I'd like this to be backported, it depends on approximately all the toolstack work I got complete in 4.14. The changes to xc_apply_cpuid_policy() are only safe because the behaviour of 4.13 is known (and fixed), and that all versions of Xen we've made "breaking" default changes have the boot CPUID settings properly in the migrate stream. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 18 09:40:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 09:40:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlr2L-0000YG-KS; Thu, 18 Jun 2020 09:40:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlr2L-0000YB-10 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 09:40:45 +0000 X-Inumbo-ID: c7a5e824-b147-11ea-ba63-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c7a5e824-b147-11ea-ba63-12813bfff9fa; Thu, 18 Jun 2020 09:40:44 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 9l9gYOpZoF3aELz9ohdfOcT+Ql7E0mTvc4x10nDSnS4CM9h+s4vlFY2ie809rmlMs3/Arv57M0 Xu5NUgWV4WcHi9P1+TaoeRUxsDv/7ZVq0bPdn6bT8KMSj76fMqKLIHyFA5mw9Z3vahlxe499gi kJlivXnQo0oxVPstJLM7SQs6QxayLlI/EVCn9tZIEUFqtcMB8fAjU7RTZ+t2dhk/36S4wx3RJl CnGXjZdAg4LXlOSpWHxvatMZtFclRfO9dDN9O6/wxrJM1TDGEtbvaurAmXxVDpM8SGG0HW8sKi dEs= X-SBRS: 2.7 X-MesageID: 20697589 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20697589" Date: Thu, 18 Jun 2020 11:40:14 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Message-ID: <20200618094014.GH735@Air-de-Roger> References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , Jun Nakajima , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 08:30:08AM +0200, Jan Beulich wrote: > On 17.06.2020 18:19, Tamas K Lengyel wrote: > > While forking VMs running a small RTOS system (Zephyr) a Xen crash has been > > observed due to a mm-lock order violation while copying the HVM CPU context > > from the parent. This issue has been identified to be due to > > hap_update_paging_modes first getting a lock on the gfn using get_gfn. This > > call also creates a shared entry in the fork's memory map for the cr3 gfn. The > > function later calls hap_update_cr3 while holding the paging_lock, which > > results in the lock-order violation in vmx_load_pdptrs when it tries to unshare > > the above entry when it grabs the page with the P2M_UNSHARE flag set. > > > > Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was > > unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure > > the p2m is properly populated and to avoid the lock-order violation we > > observed. > > Using P2M_ALLOC is not going to address the original problem though > afaict: You may hit the mem_sharing_fork_page() path that way, and > via nominate_page() => __grab_shared_page() => mem_sharing_page_lock() > you'd run into a lock order violation again. Well, I guess Tamas avoids this because of the get_gfn call in hap_update_paging_modes will have already populated the entry, so it's never going to hit the p2m_is_hole check in __get_gfn_type_access. > The change is an improvement, so I'd be fine with it going in this > way, but only as long as the description mentions that there's still > an open issue here (which may be non-trivial to address). Or perhaps > combining with your v1 change is the way to go (for now or even > permanently)? If vmx_load_pdptrs only requires P2M_ALLOC then this is already covered by the call to get_gfn performed in hap_update_paging_modes, so I don't think there's much point in merging with v1, as forcing hap_update_paging_modes to unshare the entry won't affect vmx_load_pdptrs anymore. I'm however worried about other code paths that can call into vmx_load_pdptrs with mm locks taken, and I agree it would be safer to assert that all the higher layers make sure the cr3 loaded is correctly populated for a query without P2M_ALLOC to succeed. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 10:03:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 10:03:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlrNu-0002Lu-IH; Thu, 18 Jun 2020 10:03:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlrNs-0002Ll-Pd for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 10:03:00 +0000 X-Inumbo-ID: e3a26054-b14a-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e3a26054-b14a-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 10:02:59 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 7kl0LJ4HmwHIk9rU3Qfabu2Urcr72izzaoXcC4B/NzeSRv9olhlvbpcwjfLPD1aQcurqlDdIj+ RBnpjmcIAd20qK6+yfp+YeGsfCOsLaKl96POSMZCM2q4IizuQUc8sOiY+PDNxVabjdn7L03cpj 4W8A3Kj3EdkaO4huqt7IFNpUKAyaJUg8iH9lhCzJNN9Z3fuGFb2TQLKxJuYKUkWBR2HSsnHowH S3tKCTWndkKobCVDa+C3O0YdMdn3RpCI+loXWsCGA1q30jRpJR1me43gQXuMKX1o6UDIQnmOsu bh8= X-SBRS: 2.7 X-MesageID: 20351516 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20351516" Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit To: "Kang, Luwei" , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> <20200616173857.GU735@Air-de-Roger> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> <20200617090942.GY735@Air-de-Roger> <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> <20200617125146.GA735@Air-de-Roger> <5ad138bb-9195-a8de-5566-468db553422e@citrix.com> From: Andrew Cooper Message-ID: <1c476a2b-8d05-7634-3543-ba1c2768bb99@citrix.com> Date: Thu, 18 Jun 2020 11:02:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , "Tian, Kevin" , Wei Liu , Jan Beulich , "Nakajima, Jun" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18/06/2020 00:30, Kang, Luwei wrote: >>> On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote: >>>> ----- 17 cze 2020 o 11:09, Roger Pau Monné roger.pau@citrix.com napisał(a): >>>> >>>>> 24 Virtual Machine Control Structures -> 24.8 VM-entry Control >>>>> Fields -> 24.8.1 VM-Entry Controls Software should consult the VMX >> capability MSRs IA32_VMX_ENTRY_CTLS to determine how it should set the >> reserved bits. >>>> Please look at bit position 18 "Load IA32_RTIT_CTL". >>> I think this is something different from what I was referring to. >>> Those options you refer to (load/clear IA32_RTIT_CTL) deal with >>> loading/storing a specific field on the vmcs that maps to the guest >>> IA32_RTIT_CTL. >>> >>> OTOH MSR load lists can be used to load and store any arbitrary MSR on >>> vmentry/vmexit, see section 26.4 LOADING MSRS on the SDM. There's >>> already infrastructure on Xen to do so, see vmx_{add/del/find}_msr. >> If I remember the historic roadmaps correctly, there are 3 cases. >> >> The first hardware to support PT (Broadwell?) prohibited its use completely in >> VMX operations.  In this case, we can use it to trace PV guests iff we don't >> enable VMX in hardware to begin with. >> >> This was relaxed in later hardware (Skylake?) to permit use within VMX >> operations, but without any help in the VMCS.  (i.e. manual context switching >> per this patch, or MSR load lists as noted in the SDM.) >> >> Subsequent support for "virtualised PT" was added (IceLake?) which adds the >> load/save controls, and the ability to translate the output buffer under EPT. >> >> >> All of this is from memory so I'm quite possibly wrong with details, but I believe >> this is why the current complexity exists. > Yes, It include 3 cases. > 1. Before IA32_VMX_MISC[bit 14]: > Intel PT doesn't support tracing in VMX operation. Execution of the VMXON instruction clears IA32_RTIT_CTL.TraceEn and any attempt to write IA32_RTIT_CTL in VMX operation causes a general-protection exception (#GP) > 2. Support IA32_VMX_MISC[bit 14] but no EPT to direct PT output: > Intel PT can be enabled across VMX but the address of Intel PT buffer is always HPA from HW point of view. There is not VMCS support in this stage. The MSR load list can be used for Intel PT context switch(VM-Entry/Exit). > 3. Intel PT VM improvements (start from Icelake): > Add a new guest IA32_RTIT_CTL field in VMCS, and HW treat the PT output addresses as GPA and translate them using EPT. Thanks for the details, and confirming.  I think for now we can ignore case 1 for simplicity, as I don't think it is likely that we'll have someone on Broadwell hardware intending to run without VMX.  (If people really want it, we can retrofit it, but I don't think the effort is worth it for now) ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 18 10:06:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 10:06:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlrRS-0002VM-5O; Thu, 18 Jun 2020 10:06:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlrRQ-0002Uq-5B for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 10:06:40 +0000 X-Inumbo-ID: 6311d388-b14b-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6311d388-b14b-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 10:06:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VRZUtYR4XPM7Cybsm5jwqVbhW0fHIloCJ69ruEdg/Cs=; b=JfvTBhWmhctqE6tBl6MuAbvId ZNmHuQsxC1qmBP/wDsQVsdl6E6SrvvlV7wv3HXbE0Gk0RqCiFtgbpd/vlw+V//UdRE/FQYs5qeOLd 93qdp2C+Zcv/EM6IofXeDX9XKRbtCCCTVptv3uTeWtYg1jtbLCr32WBvXInWPMNvTqtvA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlrRI-0005Iu-R5; Thu, 18 Jun 2020 10:06:32 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlrRI-0007w7-H7; Thu, 18 Jun 2020 10:06:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlrRI-0000dz-Fz; Thu, 18 Jun 2020 10:06:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151175: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=5c24bce3056ff209a1ecc50ff4b7e65b85ad8e74 X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Thu, 18 Jun 2020 10:06:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151175 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151175/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass version targeted for testing: qemuu 5c24bce3056ff209a1ecc50ff4b7e65b85ad8e74 baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 5 days Failing since 151101 2020-06-14 08:32:51 Z 4 days 3 attempts Testing same since 151175 2020-06-16 20:13:59 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Anthony PERARD Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Cathy Zhang Claudio Fontana Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Carlier David Gibson Edgar E. Iglesias Emilio G. Cota Eric Auger Erik Smit Evgeny Yakovlev fangying Gerd Hoffmann Guenter Roeck Igor Mammedov Janne Grunau Jean-Christophe Dubois Jiaxun Yang Jon Doron Joseph Myers Julio Faracco Laurent Vivier Leonid Bloch Leonid Bloch Like Xu Lingfeng Yang Liran Alon Maciej S. Szmigiero Magnus Damm Marek Marczykowski-Górecki Markus Armbruster Masahiro Yamada Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Stefan Berger Thomas Huth WangBowen Wei Huang Ying Fang Yoshinori Sato jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6215 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 18 10:11:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 10:11:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlrVz-0003JW-Tp; Thu, 18 Jun 2020 10:11:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlrVz-0003JQ-7d for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 10:11:23 +0000 X-Inumbo-ID: 0f29e3ea-b14c-11ea-ba66-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0f29e3ea-b14c-11ea-ba66-12813bfff9fa; Thu, 18 Jun 2020 10:11:22 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 4xFnDDohsQfjgZbIbrpl7jJ4JNpxOzlFDDHTpYX4i/kLb4bQRTQl97nvtobJu6d2W4llrfZu5P dGldkYKylSxAwcRr/zFOpdAwIqdXi1jzXBzj7e2PGBYPFvkxxjJsQybhaCcTPYol1njRUhlW4K 5orALwiplwQ2Ni9/vCfN6+PnYa/6PPUJpnUVjhHo8EEEp3tXKR1twaZvhIea1q/2naal7UOn3T p9f7OWseNvZhwzyey3dVf88NmBUtsLk+rz9oAe6kufnDSIcwiQwcfBSTB/u1PVj+RcxQv20KG2 3+0= X-SBRS: 2.7 X-MesageID: 20366843 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20366843" Date: Thu, 18 Jun 2020 12:11:13 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH] VT-x: simplify/clarify vmx_load_pdptrs() Message-ID: <20200618101113.GI735@Air-de-Roger> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Kevin Tian , Wei Liu , Jun Nakajima , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 08:38:27AM +0200, Jan Beulich wrote: > * Guests outside of long mode can't have PCID enabled. Drop the > respective check to make more obvious that there's no security issue > (from potentially accessing past the mapped page's boundary). > > * Only the low 32 bits of CR3 are relevant outside of long mode, even > if they remained unchanged after leaving that mode. > > * Drop the unnecessary and badly typed local variable p. > > * Don't open-code hvm_long_mode_active() (and extend this to the related > nested VT-x code). > > * Constify guest_pdptes to clarify that we're only reading from the > page. > > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné As it's no worse that what was there before, yet I have a question. > --- > This is intentionally not addressing any of the other shortcomings of > the function, as was done by the previously posted > https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg01790.html. > This will need to be the subject of a further change. > > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -1312,17 +1312,16 @@ static void vmx_set_interrupt_shadow(str > > static void vmx_load_pdptrs(struct vcpu *v) > { > - unsigned long cr3 = v->arch.hvm.guest_cr[3]; > - uint64_t *guest_pdptes; > + uint32_t cr3 = v->arch.hvm.guest_cr[3]; > + const uint64_t *guest_pdptes; > struct page_info *page; > p2m_type_t p2mt; > - char *p; > > /* EPT needs to load PDPTRS into VMCS for PAE. */ > - if ( !hvm_pae_enabled(v) || (v->arch.hvm.guest_efer & EFER_LMA) ) > + if ( !hvm_pae_enabled(v) || hvm_long_mode_active(v) ) > return; > > - if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) ) > + if ( cr3 & 0x1f ) > goto crash; Intel SDM says bits 0 to 4 are ignored, not reserved, so I'm not sure we need to crash the guest here. I have no reference how real hardware behaves here, so maybe crashing is the right thing to do. > > page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE); > @@ -1332,14 +1331,12 @@ static void vmx_load_pdptrs(struct vcpu > * queue, but this is the wrong place. We're holding at least > * the paging lock */ > gdprintk(XENLOG_ERR, > - "Bad cr3 on load pdptrs gfn %lx type %d\n", > + "Bad cr3 on load pdptrs gfn %"PRIx32" type %d\n", > cr3 >> PAGE_SHIFT, (int) p2mt); > goto crash; > } > > - p = __map_domain_page(page); > - > - guest_pdptes = (uint64_t *)(p + (cr3 & ~PAGE_MASK)); > + guest_pdptes = __map_domain_page(page) + (cr3 & ~PAGE_MASK); Instead I think this could be: guest_pdptes = __map_domain_page(page) + (cr3 & ~(PAGE_MASK | 0x1f)); Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 10:13:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 10:13:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlrYB-0003Rd-D9; Thu, 18 Jun 2020 10:13:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlrY9-0003RI-SB for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 10:13:37 +0000 X-Inumbo-ID: 5c04d526-b14c-11ea-bb8b-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5c04d526-b14c-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 10:13:31 +0000 (UTC) Received: from nodbug.lucina.net (78-141-76-187.dynamic.orange.sk [78.141.76.187]) by smtp.lucina.net (Postfix) with ESMTPSA id 6F51B122804; Thu, 18 Jun 2020 12:13:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592475210; bh=zRQRVQN0mJzMxDkmlI6cM+DDPW8ivpPSJOLJe/aNXLU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ec8nG3maHRRkKIfLa+G76YcY9firEBI7k5QNVpH6ud61OIUtvEbpzFK88zN5iuPfF 7NyxcGfkjt4+diE10XfI9VoDICYjKl0/8GxnMZeugNbdM2WitrV1t80d/yh3XK/fdD 1fC0DQTrwTCc//zfXT89CIEnsS5yXXW5INYVd2kZTurmqXVWzTn5fdnnqufaRqV6PQ 8n9CDqkNWuHcGmxrB9diLJd9iIfu78kcX+mMET87dlGlrDe9dDkbIX4Q8a3DONQGGc BFa+AmhOSK2udgfMTPfWbBoHF30tV0IxW7pKys+phAZvuQf8bm9Nx3519yDxx2ma79 S4DS3Q6S/Nrtw== Received: by nodbug.lucina.net (Postfix, from userid 1000) id 588A8265E722; Thu, 18 Jun 2020 12:13:30 +0200 (CEST) Date: Thu, 18 Jun 2020 12:13:30 +0200 From: Martin Lucina To: Andrew Cooper , Roger Pau =?iso-8859-1?Q?Monn=E9?= Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200618101330.GB10330@nodbug.lucina.net> Mail-Followup-To: Martin Lucina , Andrew Cooper , Roger Pau =?iso-8859-1?Q?Monn=E9?= , xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Monday, 15.06.2020 at17:58, Andrew Cooper wrote: > On 15/06/2020 15:25, Martin Lucina wrote: > > Hi, > > > > puzzle time: In my continuing explorations of the PVHv2 ABIs for the > > new MirageOS Xen stack, I've run into some issues with what looks like > > missed deliveries of events on event channels. > > > > While a simple unikernel that only uses the Xen console and > > effectively does for (1..5) { printf("foo"); sleep(1); } works fine, > > once I plug in the existing OCaml Xenstore and Netfront code, the > > behaviour I see is that the unikernel hangs in random places, blocking > > as if an event that should have been delivered has been missed. > > You can see what is going on, event channel wise, with the 'e' > debug-key. This will highlight cases such as the event channel being > masked and pending, which is a common guest bug ending up in this state. Ok, based on your and Roger's suggestions I've made some changes: 1. I've dropped all the legacy PIC initialisation code from the Solo5 parts, written some basic APIC initialisation code and switched to using HVMOP_set_evtchn_upcall_vector for upcall registration, along with setting HVM_PARAM_CALLBACK_IRQ to 1 as suggested by Roger and done by Xen when running as a guest. Commit at [1], nothing controversial there. 2. I've re-worked the "bottom half" of the event channel upcall handler to mask the event when marking it as pending in the OCaml-side "shadow" structure, and unmask it immediately before an OCaml-side handler would be run, i.e. when doing a "test and clear port" operation on the OCaml-side structure. However, none of this seems to have fundamentally changed the behaviour. The unikernel still gets "stuck" at random points during netfront set-up. Now that I've extended the grant table size, *sometimes* get as far as a fully functioning netfront and packets will flow, but things will eventually freeze up (pretty much immediately if I do something like ping -f). When the unikernel is in the "frozen" state, the domain is blocked (so we think we're waiting for events), and the "e" debug key shows the relevant event channels (Xenstore or netfront) as pending but unmasked: Example - when hung during netfront bring-up: (XEN) Event channel information for domain 27: (XEN) Polling vCPUs: {} (XEN) port [p/m/s] (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 (1 is Xenstore, 2 is console which we don't care about, 3 is VIRQ_TIMER). When hung after hammering with "ping -f": (XEN) Event channel information for domain 28: (XEN) Polling vCPUs: {} (XEN) port [p/m/s] (XEN) 1 [0/0/1]: s=3 n=0 x=0 d=0 p=33 (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 (XEN) 4 [1/0/1]: s=3 n=0 x=0 d=0 p=35 (as above, 4 is netfront) Some more questions about the "bottom half" of the event channel upcall, called periodically by OCaml outside of interrupt context: static bool evtchn_demux_pending(void) { struct shared_info *s = SHARED_INFO(); struct vcpu_info *vi = VCPU0_INFO(); bool some_pending = false; vi->evtchn_upcall_pending = 0; >>>> Based on Roger's suggestion, this is now only done here and no longer >>>> in the "top half" in interrupt context, which now only ACKs the vector >>>> on the APIC. /* * Demux events received from Xen. * * pending_l1 is the "outer" per-VCPU selector (evtchn_pending_sel). * pending_l2 is the "inner" system-wide word (evtchn_pending[l1i]). */ xen_ulong_t pending_l1, pending_l2; atomic_sync_xchg(&vi->evtchn_pending_sel, 0, &pending_l1); while (pending_l1 != 0) { xen_ulong_t l1i = ffs(pending_l1); pending_l1 &= ~(1UL << l1i); /* * Masking pending_l2 with ~evtchn_mask[l1i] is necessary to get the * *current* masked events; otherwise races like the following * can occur: * * 1. X is generated, upcall scheduled by Xen. * 2. X is masked. * 3. Upcall is delivered. * 4. X fires despite now being masked. */ while ((pending_l2 = (s->evtchn_pending[l1i] & ~s->evtchn_mask[l1i])) != 0) { xen_ulong_t l2i = ffs(pending_l2); pending_l2 &= ~(1UL << l2i); >>>> Do I need the above? It doesn't make a difference and seems redundant >>>> since pending_l2 is always reassigned in the loop, but Mini-OS and >>>> others are doing it...? evtchn_port_t port = (l1i * (sizeof(xen_ulong_t) * 8)) + l2i; /* * Mark as pending on the OCaml side and mask the event until * just before OCaml gets around to handling it. Also, clear * the pending bit on the Xen side. */ evtchn_callback_ml[port] = 1; atomic_sync_bts(l2i, &s->evtchn_mask[l1i]); >>>> Mask added at Roger's suggestion, not in the original Mini-OS PV-based >>>> implementation. atomic_sync_btc(l2i, &s->evtchn_pending[l1i]); some_pending = true; } } return some_pending; } The OCaml code essentially calls the above periodically, and, if it returns true, then calls into the following "test and clear" operation for all ports: static inline bool evtchn_test_and_clear(evtchn_port_t port) { assert(port < EVTCHN_2L_NR_CHANNELS); if (evtchn_callback_ml[port] > 0) { evtchn_callback_ml[port] = 0; evtchn_unmask(port); >>>> Unmask added at Roger's suggestion, not in the original Mini-OS >>>> PV-based implementation. I'm not entirely happy about this, since >>>> it'll probably result in a lot more hypercalls when the event channel >>>> is busy? return true; } else { return false; } } If this returns true, then the event handler will get run immediately after returning from here, and before any further call to evtchn_demux_pending(). At this point I don't really have a clear idea of how to progress, comparing my implementation side-by-side with the original PV Mini-OS-based implementation doesn't show up any differences I can see. AFAICT the OCaml code I've also not changed in any material way, and that has been running in production on PV for years, so I'd be inclined to think the problem is in my reimplementation of the C parts, but where...? Martin [1] https://github.com/mato/solo5/commit/42afe3a2177b9caf63d0df435391ae03a6684ac8 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 11:02:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 11:02:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlsJJ-0007Ug-5M; Thu, 18 Jun 2020 11:02:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlsJH-0007Ub-Bz for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 11:02:19 +0000 X-Inumbo-ID: 2c887f9e-b153-11ea-ba6d-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2c887f9e-b153-11ea-ba6d-12813bfff9fa; Thu, 18 Jun 2020 11:02:18 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id D53BAA3039; Thu, 18 Jun 2020 13:02:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id C4FD9A303C; Thu, 18 Jun 2020 13:02:15 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Bo8gAYyq4HAL; Thu, 18 Jun 2020 13:02:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 40724A2FF9; Thu, 18 Jun 2020 13:02:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kiGmoCqz-ZJX; Thu, 18 Jun 2020 13:02:14 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id DB881A30EC; Thu, 18 Jun 2020 13:02:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id C0DD121831; Thu, 18 Jun 2020 13:01:44 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id u_UTAkaiJBay; Thu, 18 Jun 2020 13:01:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 5871F215FB; Thu, 18 Jun 2020 13:01:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JyQzBAqeapfo; Thu, 18 Jun 2020 13:01:39 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 35A8F21228; Thu, 18 Jun 2020 13:01:39 +0200 (CEST) Date: Thu, 18 Jun 2020 13:01:39 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Tamas K Lengyel Message-ID: <832789003.9534743.1592478099057.JavaMail.zimbra@cert.pl> In-Reply-To: References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: iRQyvzKYkyaR17bUuUHjUg0ZnN2ZpQ== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 18 cze 2020 o 5:20, Tamas K Lengyel tamas.k.lengyel@gmail.com napisa= =C5=82(a): >> >> + >> >> + a.mfn =3D v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHI= FT; >> > >> > This will not work for translated domains, ie: a PVH or HVM domain >> > won't be able to use this interface since it has no way to request the >> > mapping of a specific mfn into it's physmap. I think we need to take >> > this into account when deciding how the interface should be, so that >> > we don't corner ourselves with a PV only interface. >> >> Please be aware that this is only going to be used by Dom0. Is is well-s= upported >> case that somebody is using PVH/HVM Dom0? >> >> I think that all Virtual Machine Introspection stuff currently requires = to have >> Dom0 PV. Our main goal is to have this working well in combo with VMI. >=20 > FYI the VMI interface doesn't require a PV domain. It works fine from > PVH dom0 or even from a secondary privileged HVM DomU as well, > provided you have the right XSM policy to allow that. >=20 > Tamas It was previously stated that: > PVH or HVM domain > won't be able to use this interface since it has no way to request the > mapping of a specific mfn into it's physmap. but however, taking LibVMI as an example: https://github.com/libvmi/libvmi/blob/c461e20ae88bc62c08c27f50fcead23c27a30= f9e/libvmi/driver/xen/xen.c#L51 An essential abstraction xen_get_memory() relies on xc_map_foreign_range().= Doesn't this mean that it's not usable from PVH or HVM domains, or did I g= ot it all wrong? Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Thu Jun 18 11:08:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 11:08:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlsPJ-0007h9-Sx; Thu, 18 Jun 2020 11:08:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlsPJ-0007h4-3j for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 11:08:33 +0000 X-Inumbo-ID: 0b56d0f4-b154-11ea-bca7-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0b56d0f4-b154-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 11:08:31 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1723BA300C; Thu, 18 Jun 2020 13:08:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 092B0A30DE; Thu, 18 Jun 2020 13:08:30 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3__vHQuyugF1; Thu, 18 Jun 2020 13:08:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 5C582A300C; Thu, 18 Jun 2020 13:08:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wIQpAnQ0iAXn; Thu, 18 Jun 2020 13:08:29 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3566CA2FC6; Thu, 18 Jun 2020 13:08:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 03144210CE; Thu, 18 Jun 2020 13:07:39 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KiyBjdnCDhwb; Thu, 18 Jun 2020 13:07:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 59A3A21D50; Thu, 18 Jun 2020 13:07:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GqEiuDfdbvzR; Thu, 18 Jun 2020 13:07:33 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 1CAA8217E7; Thu, 18 Jun 2020 13:07:33 +0200 (CEST) Date: Thu, 18 Jun 2020 13:07:33 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <633218159.9539851.1592478453009.JavaMail.zimbra@cert.pl> In-Reply-To: <20200618085208.GG735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> <20200617090942.GY735@Air-de-Roger> <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> <20200617125146.GA735@Air-de-Roger> <5ad138bb-9195-a8de-5566-468db553422e@citrix.com> <219980918.9257247.1592420217746.JavaMail.zimbra@cert.pl> <20200618085208.GG735@Air-de-Roger> Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: switch IPT MSRs on vmentry/vmexit Thread-Index: zYISPLsv9GXpxcikHHHR7TvTXvoztA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , luwei kang , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 18 cze 2020 o 10:52, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Wed, Jun 17, 2020 at 08:56:57PM +0200, Micha=C5=82 Leszczy=C5=84ski wr= ote: >> ----- 17 cze 2020 o 17:14, Andrew Cooper andrew.cooper3@citrix.com napis= a=C5=82(a): >>=20 >> > On 17/06/2020 13:51, Roger Pau Monn=C3=A9 wrote: >> >> On Wed, Jun 17, 2020 at 01:54:45PM +0200, Micha=C5=82 Leszczy=C5=84sk= i wrote: >> >>> ----- 17 cze 2020 o 11:09, Roger Pau Monn=C3=A9 roger.pau@citrix.com= napisa=C5=82(a): >> >>> >> >>>> 24 Virtual Machine Control Structures -> 24.8 VM-entry Control Fiel= ds -> 24.8.1 >> >>>> VM-Entry Controls >> >>>> Software should consult the VMX capability MSRs IA32_VMX_ENTRY_CTLS= to determine >> >>>> how it should set the reserved bits. >> >>> Please look at bit position 18 "Load IA32_RTIT_CTL". >> >> I think this is something different from what I was referring to. >> >> Those options you refer to (load/clear IA32_RTIT_CTL) deal with >> >> loading/storing a specific field on the vmcs that maps to the guest >> >> IA32_RTIT_CTL. >> >> >> >> OTOH MSR load lists can be used to load and store any arbitrary MSR o= n >> >> vmentry/vmexit, see section 26.4 LOADING MSRS on the SDM. There's >> >> already infrastructure on Xen to do so, see vmx_{add/del/find}_msr. >> >=20 >> > If I remember the historic roadmaps correctly, there are 3 cases. >> >=20 >> > The first hardware to support PT (Broadwell?) prohibited its use >> > completely in VMX operations.=C2=A0 In this case, we can use it to tra= ce PV >> > guests iff we don't enable VMX in hardware to begin with. >> >=20 >> > This was relaxed in later hardware (Skylake?) to permit use within VMX >> > operations, but without any help in the VMCS.=C2=A0 (i.e. manual conte= xt >> > switching per this patch, or MSR load lists as noted in the SDM.) >> >=20 >> > Subsequent support for "virtualised PT" was added (IceLake?) which add= s >> > the load/save controls, and the ability to translate the output buffer >> > under EPT. >> >=20 >> >=20 >> > All of this is from memory so I'm quite possibly wrong with details, b= ut >> > I believe this is why the current complexity exists. >> >=20 >> > ~Andrew >>=20 >>=20 >> I've managed to toggle MSR_IA32_RTIT_CTL values using MSR load lists, as= in: >>=20 >> > 35.5.2.2 Guest-Only Tracing >> > "For this usage, VM-entry is programmed to enable trace packet generat= ion, while >> > VM-exit is programmed to clear MSR_IA32_RTIT_CTL.TraceEn so as to disa= ble >> > trace-packet generation in the host." >>=20 >> it actually helped a bit. With patch v1 there were parts of hypervisor r= ecorded >> in the trace (i.e. the moment between TRACE_EN being set and actual vmen= ter, >> and the moment between vmexit and TRACE_EN being unset). Using MSR load = list >> this was eliminated. This change will be reflected in patch v2. >>=20 >>=20 >> I can't however implement any working scenario in which all these MSRs a= re >> managed using MSR load lists. As in "35.3.3 Flushing Trace Output": pack= ets are >> buffered internally and are flushed only when TRACE_EN bit in MSR_IA32_R= TIT_CTL >> is set to 0. The values of remaining registers will be stable after ever= ything >> is serialized. I think this is too complex for the load lists alone. I b= elive >> that currently SDM instructs to use load lists only for toggling this si= ngle >> bit on-or-off. >=20 > I think that's exactly what we want: handling TraceEn at > vmentry/vmexit, so that no hypervisor packets are recorded. The rest > of the MSRs can be handled in VMM mode without issues. Switching those > on every vmentry/vmexit would also add more overhead that needed, > since I assume they don't need to be modified on every entry/exit? Assuming that there is a single DomU per pcpu and they are never migrated b= etween pcpus then you never need to modify the remaining MSRs. In case DomUs are floating or there are multiple DomUs per pcpu, we need to= read out a few MSRs on vm-exit and restore them on vm-entry. Right now I'm= always using this approach as I'm pretty not sure how to optimize it witho= ut introducing additional bugs. I will show the implementation in patch v2. >=20 >>=20 >> Thus, for now I propose to stay with MSR_IA32_RTIT_CTL being managed by = MSR load >> lists and the rest of related MSRs being managed manually. >=20 > Yes, that' seems like a good approach. >=20 > Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 11:15:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 11:15:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlsW4-0008Vz-L3; Thu, 18 Jun 2020 11:15:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlsW3-0008Vu-FQ for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 11:15:31 +0000 X-Inumbo-ID: 05437ec8-b155-11ea-b7bb-bc764e2007e4 Received: from mail-ot1-x331.google.com (unknown [2607:f8b0:4864:20::331]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 05437ec8-b155-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 11:15:30 +0000 (UTC) Received: by mail-ot1-x331.google.com with SMTP id e5so4190160ote.11 for ; Thu, 18 Jun 2020 04:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lfy+bP/6vJ3x/eThUcFMoD17ZCsLCF7U1giHYoTwtA4=; b=sUxznxSmchgqY2f5sYqi6xE3YfX14kI/Ag2KwH8ycZkmBoba3F+gzNOyDL+AkZm30b V8WrWBPR4W/AGEaGYd7o1M6CPMRS2iJi3GtlWVZdXcIl0DWvyY1w/qkhWIesrNYeva5x gmWhJY8Ho6jcQzf1jUHNhipod6sf0QKr/cPxpRxIVL1opWWcd8a+0+cx4Ny4zvpqUnfa iTt/HYuR4puUSdP0McH5kvLUdq3Fl50h18gSkxhUDa8jfYEnYaXVLeGdsJGXAHu1e7WX TkFo/sKLgUAf5ZMPUq79VtLepytd05CLpn7dWwwvmdNT9Zax52uL2iwrKlK8K+SgLUc2 f/fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lfy+bP/6vJ3x/eThUcFMoD17ZCsLCF7U1giHYoTwtA4=; b=eBcraZ+Trk9eQ8fLCks/j4yB/tMl+bI8sfrAOOHCM3SteeNLg5ml958iHvcNHBn1N4 TjLkQmtp4wk+oSBjnd07TOEN8VzPjiDyvHsOFNwbBAqluoh8LtisWFJsPx5qhjjsgK8o DzinjxFBytQx434VGERN8mVO9772H9KWdz1H6zcDl63vc8f5OhFECC8O+w+Y+e3tWPRO z221s3Ex/ubr6FSDJMoLl3rprbKhH9xyYgRQ7yECBSAbo02bQpet6eGiM4Bk4c1UqPCk s0uxy60ln/44LCEAuiSRmrpLn/2yAgSVftGf9I3ynx8NYNC9853P3hJ1JQK4VfkdPvf8 miUg== X-Gm-Message-State: AOAM531E/zxoee055eweqjzp6IFiGWv8s3sMAKHnKkIDTUH4R9Y9gO2D /21yeT1VgfdccjaaZ68uVhURfJ7HydEstZcZJ8w03Q== X-Google-Smtp-Source: ABdhPJy48JqtekoXt/q251dx9kp7Qx2YkwKld0xXxO1OsCMccwd06f7lZhP3D9H98GxoL52m/6CA5MxkhAk5hJKdiyk= X-Received: by 2002:a05:6830:8d:: with SMTP id a13mr2919781oto.91.1592478930363; Thu, 18 Jun 2020 04:15:30 -0700 (PDT) MIME-Version: 1.0 References: <20200617122901.13327-1-kraxel@redhat.com> In-Reply-To: <20200617122901.13327-1-kraxel@redhat.com> From: Peter Maydell Date: Thu, 18 Jun 2020 12:15:19 +0100 Message-ID: Subject: Re: [PULL 0/4] Microvm 20200617 patches To: Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Eduardo Habkost , Sergio Lopez , Paul Durrant , "Michael S. Tsirkin" , QEMU Developers , "open list:X86" , Anthony Perard , Paolo Bonzini , Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 17 Jun 2020 at 13:33, Gerd Hoffmann wrote: > > The following changes since commit 5c24bce3056ff209a1ecc50ff4b7e65b85ad8e74: > > Merge remote-tracking branch 'remotes/stsquad/tags/pull-testing-and-plugin-160620-2' into staging (2020-06-16 14:57:15 +0100) > > are available in the Git repository at: > > git://git.kraxel.org/qemu tags/microvm-20200617-pull-request > > for you to fetch changes up to c8b473594b8fbba169a6ea950493a3015d15a18d: > > microvm: move virtio base to 0xfeb00000 (2020-06-17 14:24:28 +0200) > > ---------------------------------------------------------------- > microvm: memory config tweaks > > ---------------------------------------------------------------- Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/5.1 for any user-visible changes. -- PMM From xen-devel-bounces@lists.xenproject.org Thu Jun 18 11:32:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 11:32:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlsmg-0001is-5J; Thu, 18 Jun 2020 11:32:42 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlsmf-0001in-4W for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 11:32:41 +0000 X-Inumbo-ID: 69d7018c-b157-11ea-ba74-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 69d7018c-b157-11ea-ba74-12813bfff9fa; Thu, 18 Jun 2020 11:32:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 13478ACA7; Thu, 18 Jun 2020 11:32:37 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> <20200618094014.GH735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 13:32:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200618094014.GH735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , Jun Nakajima , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 11:40, Roger Pau Monné wrote: > On Thu, Jun 18, 2020 at 08:30:08AM +0200, Jan Beulich wrote: >> On 17.06.2020 18:19, Tamas K Lengyel wrote: >>> While forking VMs running a small RTOS system (Zephyr) a Xen crash has been >>> observed due to a mm-lock order violation while copying the HVM CPU context >>> from the parent. This issue has been identified to be due to >>> hap_update_paging_modes first getting a lock on the gfn using get_gfn. This >>> call also creates a shared entry in the fork's memory map for the cr3 gfn. The >>> function later calls hap_update_cr3 while holding the paging_lock, which >>> results in the lock-order violation in vmx_load_pdptrs when it tries to unshare >>> the above entry when it grabs the page with the P2M_UNSHARE flag set. >>> >>> Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was >>> unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure >>> the p2m is properly populated and to avoid the lock-order violation we >>> observed. >> >> Using P2M_ALLOC is not going to address the original problem though >> afaict: You may hit the mem_sharing_fork_page() path that way, and >> via nominate_page() => __grab_shared_page() => mem_sharing_page_lock() >> you'd run into a lock order violation again. > > Well, I guess Tamas avoids this because of the get_gfn call in > hap_update_paging_modes will have already populated the entry, so it's > never going to hit the p2m_is_hole check in __get_gfn_type_access. > >> The change is an improvement, so I'd be fine with it going in this >> way, but only as long as the description mentions that there's still >> an open issue here (which may be non-trivial to address). Or perhaps >> combining with your v1 change is the way to go (for now or even >> permanently)? > > If vmx_load_pdptrs only requires P2M_ALLOC then this is already > covered by the call to get_gfn performed in hap_update_paging_modes, > so I don't think there's much point in merging with v1, as forcing > hap_update_paging_modes to unshare the entry won't affect > vmx_load_pdptrs anymore. Oh, I simply mis-remembered what v1 did; for some reason I thought it added a call rather than modifying the query type from alloc to unshare. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 11:46:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 11:46:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlt05-0002ej-D0; Thu, 18 Jun 2020 11:46:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlt03-0002dn-Ku for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 11:46:31 +0000 X-Inumbo-ID: 561f377a-b159-11ea-ba7a-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 561f377a-b159-11ea-ba7a-12813bfff9fa; Thu, 18 Jun 2020 11:46:25 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: sy/Tg8xTzfK+X5o0GbCh3t2mEwwRBxT7c/ucS7IEu41qVuoXUWhCmruU4w4/GFpz7BjSniz20p tr3fEW1ZfeMdDywwHNKeFNjWANYEa6arIDzMkGzEnqcZi+FvXWCxwQVebTayKMcyXMlpO62y9m KnC3KYbUryRbJeK5mU47Q1gdA137rXHU+NaFrmOoMXNE5zgZHDcpJatK4WKo5HhjpuuglDTpMj c69T+fJs5F3+aNeBRvaGKLSiNg+SNurZotH4ZqFmegQ7wz2pMeyivC/wWCQ47187U9RbaEk6yZ lzw= X-SBRS: 2.7 X-MesageID: 20705463 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20705463" Date: Thu, 18 Jun 2020 13:46:17 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Martin Lucina Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200618114617.GJ735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200618101330.GB10330@nodbug.lucina.net> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote: > On Monday, 15.06.2020 at 17:58, Andrew Cooper wrote: > > On 15/06/2020 15:25, Martin Lucina wrote: > > > Hi, > > > > > > puzzle time: In my continuing explorations of the PVHv2 ABIs for the > > > new MirageOS Xen stack, I've run into some issues with what looks like > > > missed deliveries of events on event channels. > > > > > > While a simple unikernel that only uses the Xen console and > > > effectively does for (1..5) { printf("foo"); sleep(1); } works fine, > > > once I plug in the existing OCaml Xenstore and Netfront code, the > > > behaviour I see is that the unikernel hangs in random places, blocking > > > as if an event that should have been delivered has been missed. > > > > You can see what is going on, event channel wise, with the 'e' > > debug-key.  This will highlight cases such as the event channel being > > masked and pending, which is a common guest bug ending up in this state. > > Ok, based on your and Roger's suggestions I've made some changes: > > 1. I've dropped all the legacy PIC initialisation code from the Solo5 > parts, written some basic APIC initialisation code and switched to using > HVMOP_set_evtchn_upcall_vector for upcall registration, along with setting > HVM_PARAM_CALLBACK_IRQ to 1 as suggested by Roger and done by Xen when > running as a guest. Commit at [1], nothing controversial there. > > 2. I've re-worked the "bottom half" of the event channel upcall handler to > mask the event when marking it as pending in the OCaml-side "shadow" > structure, and unmask it immediately before an OCaml-side handler would be > run, i.e. when doing a "test and clear port" operation on the OCaml-side > structure. As long as the unmask happens after you having cleared the bit on the ocaml-side structure I think it should be fine, however I would unmask the event channel once you have finished running the ocaml handler for it. > > However, none of this seems to have fundamentally changed the behaviour. > The unikernel still gets "stuck" at random points during netfront set-up. > Now that I've extended the grant table size, *sometimes* get as far as a > fully functioning netfront and packets will flow, but things will > eventually freeze up (pretty much immediately if I do something like ping > -f). > > When the unikernel is in the "frozen" state, the domain is blocked (so we > think we're waiting for events), and the "e" debug key shows the relevant > event channels (Xenstore or netfront) as pending but unmasked: > > Example - when hung during netfront bring-up: > > (XEN) Event channel information for domain 27: > (XEN) Polling vCPUs: {} > (XEN) port [p/m/s] > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 > > (1 is Xenstore, 2 is console which we don't care about, 3 is VIRQ_TIMER). > > When hung after hammering with "ping -f": > > (XEN) Event channel information for domain 28: > (XEN) Polling vCPUs: {} > (XEN) port [p/m/s] > (XEN) 1 [0/0/1]: s=3 n=0 x=0 d=0 p=33 > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 > (XEN) 4 [1/0/1]: s=3 n=0 x=0 d=0 p=35 > > (as above, 4 is netfront) So events are pending but somehow not injected. > > Some more questions about the "bottom half" of the event channel upcall, > called periodically by OCaml outside of interrupt context: > > static bool evtchn_demux_pending(void) > { > struct shared_info *s = SHARED_INFO(); > struct vcpu_info *vi = VCPU0_INFO(); > bool some_pending = false; > > vi->evtchn_upcall_pending = 0; > >>>> Based on Roger's suggestion, this is now only done here and no longer > >>>> in the "top half" in interrupt context, which now only ACKs the vector > >>>> on the APIC. > > /* > * Demux events received from Xen. > * > * pending_l1 is the "outer" per-VCPU selector (evtchn_pending_sel). > * pending_l2 is the "inner" system-wide word (evtchn_pending[l1i]). > */ > xen_ulong_t pending_l1, pending_l2; > atomic_sync_xchg(&vi->evtchn_pending_sel, 0, &pending_l1); > while (pending_l1 != 0) { > xen_ulong_t l1i = ffs(pending_l1); > pending_l1 &= ~(1UL << l1i); > > /* > * Masking pending_l2 with ~evtchn_mask[l1i] is necessary to get the > * *current* masked events; otherwise races like the following > * can occur: > * > * 1. X is generated, upcall scheduled by Xen. > * 2. X is masked. > * 3. Upcall is delivered. > * 4. X fires despite now being masked. > */ > while ((pending_l2 = > (s->evtchn_pending[l1i] & ~s->evtchn_mask[l1i])) != 0) { > xen_ulong_t l2i = ffs(pending_l2); > pending_l2 &= ~(1UL << l2i); > >>>> Do I need the above? It doesn't make a difference and seems redundant > >>>> since pending_l2 is always reassigned in the loop, but Mini-OS and > >>>> others are doing it...? No, pending_l2 AFAICT it's only used to get the event channel to process, so there's no point in clearing it on the local variable. What you care about is clearing it in evtchn_pending[l1i]. > > evtchn_port_t port = (l1i * (sizeof(xen_ulong_t) * 8)) + l2i; > /* > * Mark as pending on the OCaml side and mask the event until > * just before OCaml gets around to handling it. Also, clear > * the pending bit on the Xen side. > */ > evtchn_callback_ml[port] = 1; > atomic_sync_bts(l2i, &s->evtchn_mask[l1i]); > >>>> Mask added at Roger's suggestion, not in the original Mini-OS PV-based > >>>> implementation. > atomic_sync_btc(l2i, &s->evtchn_pending[l1i]); > some_pending = true; > } > } > return some_pending; > } > > The OCaml code essentially calls the above periodically, and, if > it returns true, then calls into the following "test and clear" operation > for all ports: > > static inline bool evtchn_test_and_clear(evtchn_port_t port) > { > assert(port < EVTCHN_2L_NR_CHANNELS); > if (evtchn_callback_ml[port] > 0) { > evtchn_callback_ml[port] = 0; > evtchn_unmask(port); > >>>> Unmask added at Roger's suggestion, not in the original Mini-OS > >>>> PV-based implementation. I'm not entirely happy about this, since > >>>> it'll probably result in a lot more hypercalls when the event channel > >>>> is busy? OTOH you will likely continue to get interrupts from it if you don't mask it, so you might receive several interrupts (because you clear the pending bit) without having executed the handler. IMO it would be better to do the unmask after the handler has run. > return true; > } > else { > return false; > } > } > > If this returns true, then the event handler will get run immediately after > returning from here, and before any further call to evtchn_demux_pending(). > > At this point I don't really have a clear idea of how to progress, > comparing my implementation side-by-side with the original PV Mini-OS-based > implementation doesn't show up any differences I can see. > > AFAICT the OCaml code I've also not changed in any material way, and that > has been running in production on PV for years, so I'd be inclined to think > the problem is in my reimplementation of the C parts, but where...? A good start would be to print the ISR and IRR lapic registers when blocked, to assert there are no pending vectors there. Can you apply the following patch to your Xen, rebuild and check the output of the 'l' debug key? Also add the output of the 'v' key. Roger. ---8<--- diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c index 7b5c633033..45b195cc05 100644 --- a/xen/arch/x86/hvm/vlapic.c +++ b/xen/arch/x86/hvm/vlapic.c @@ -23,6 +23,7 @@ #include #include #include +#include #include #include #include @@ -1662,6 +1663,34 @@ void vlapic_destroy(struct vcpu *v) free_domheap_page(vlapic->regs_page); } +static void print_lapic(unsigned char key) +{ + const struct domain *d; + + for_each_domain ( d ) + { + const struct vcpu *v; + + if ( !has_vlapic(d) ) + continue; + + for_each_vcpu ( d, v ) + { + const struct vlapic *vlapic = vcpu_vlapic(v); + + printk("%pv IRR: %*pb\n", v, 256, &vlapic->regs->data[APIC_IRR]); + printk("%pv ISR: %*pb\n", v, 256, &vlapic->regs->data[APIC_ISR]); + } + } +} + +static int __init print_lapic_init(void) +{ + register_keyhandler('l', print_lapic, "dump local APIC info", 1); + return 0; +} +__initcall(print_lapic_init); + /* * Local variables: * mode: C From xen-devel-bounces@lists.xenproject.org Thu Jun 18 11:49:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 11:49:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlt39-0002p9-Sf; Thu, 18 Jun 2020 11:49:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlt38-0002p3-Nv for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 11:49:42 +0000 X-Inumbo-ID: cb328e68-b159-11ea-bca7-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cb328e68-b159-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 11:49:41 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: FvWJse9e9MomQ5r6ZVF8hG4rPNJhsgJlkPBTPzlZLMJorWRD9IWUOFgrAqoYAI8Q/rk0dPCmcI FiBN8IPt7xNScWmJ6dOVuLZlHyobQ5748RHWqrzYww0NlzOoCFxrS9DR4tYtYqJBinTRSqqIiU vdtaAWwwC2m+vM8Eb4jbhBBxo4OYL3eaXsqNaHk7YAE05KGOFD/JtlhZ2oq2ATZYSFKhkrVKNt RrUsGB/fg2YAe7J1xZP32DtnHtoOi4pfBosK1YvD7D8A8gNc9Jjw1GECZUcwpsH7cFPG78hCq8 fJI= X-SBRS: 2.7 X-MesageID: 20359021 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20359021" Date: Thu, 18 Jun 2020 13:49:33 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit Message-ID: <20200618114933.GK735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <676696113.8782412.1592329627666.JavaMail.zimbra@cert.pl> <20200617090942.GY735@Air-de-Roger> <574150.9103505.1592394885283.JavaMail.zimbra@cert.pl> <20200617125146.GA735@Air-de-Roger> <5ad138bb-9195-a8de-5566-468db553422e@citrix.com> <219980918.9257247.1592420217746.JavaMail.zimbra@cert.pl> <20200618085208.GG735@Air-de-Roger> <633218159.9539851.1592478453009.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <633218159.9539851.1592478453009.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , luwei kang , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 01:07:33PM +0200, Michał Leszczyński wrote: > ----- 18 cze 2020 o 10:52, Roger Pau Monné roger.pau@citrix.com napisał(a): > > > On Wed, Jun 17, 2020 at 08:56:57PM +0200, Michał Leszczyński wrote: > >> ----- 17 cze 2020 o 17:14, Andrew Cooper andrew.cooper3@citrix.com napisał(a): > >> > >> > On 17/06/2020 13:51, Roger Pau Monné wrote: > >> >> On Wed, Jun 17, 2020 at 01:54:45PM +0200, Michał Leszczyński wrote: > >> >>> ----- 17 cze 2020 o 11:09, Roger Pau Monné roger.pau@citrix.com napisał(a): > >> >>> > >> >>>> 24 Virtual Machine Control Structures -> 24.8 VM-entry Control Fields -> 24.8.1 > >> >>>> VM-Entry Controls > >> >>>> Software should consult the VMX capability MSRs IA32_VMX_ENTRY_CTLS to determine > >> >>>> how it should set the reserved bits. > >> >>> Please look at bit position 18 "Load IA32_RTIT_CTL". > >> >> I think this is something different from what I was referring to. > >> >> Those options you refer to (load/clear IA32_RTIT_CTL) deal with > >> >> loading/storing a specific field on the vmcs that maps to the guest > >> >> IA32_RTIT_CTL. > >> >> > >> >> OTOH MSR load lists can be used to load and store any arbitrary MSR on > >> >> vmentry/vmexit, see section 26.4 LOADING MSRS on the SDM. There's > >> >> already infrastructure on Xen to do so, see vmx_{add/del/find}_msr. > >> > > >> > If I remember the historic roadmaps correctly, there are 3 cases. > >> > > >> > The first hardware to support PT (Broadwell?) prohibited its use > >> > completely in VMX operations.  In this case, we can use it to trace PV > >> > guests iff we don't enable VMX in hardware to begin with. > >> > > >> > This was relaxed in later hardware (Skylake?) to permit use within VMX > >> > operations, but without any help in the VMCS.  (i.e. manual context > >> > switching per this patch, or MSR load lists as noted in the SDM.) > >> > > >> > Subsequent support for "virtualised PT" was added (IceLake?) which adds > >> > the load/save controls, and the ability to translate the output buffer > >> > under EPT. > >> > > >> > > >> > All of this is from memory so I'm quite possibly wrong with details, but > >> > I believe this is why the current complexity exists. > >> > > >> > ~Andrew > >> > >> > >> I've managed to toggle MSR_IA32_RTIT_CTL values using MSR load lists, as in: > >> > >> > 35.5.2.2 Guest-Only Tracing > >> > "For this usage, VM-entry is programmed to enable trace packet generation, while > >> > VM-exit is programmed to clear MSR_IA32_RTIT_CTL.TraceEn so as to disable > >> > trace-packet generation in the host." > >> > >> it actually helped a bit. With patch v1 there were parts of hypervisor recorded > >> in the trace (i.e. the moment between TRACE_EN being set and actual vmenter, > >> and the moment between vmexit and TRACE_EN being unset). Using MSR load list > >> this was eliminated. This change will be reflected in patch v2. > >> > >> > >> I can't however implement any working scenario in which all these MSRs are > >> managed using MSR load lists. As in "35.3.3 Flushing Trace Output": packets are > >> buffered internally and are flushed only when TRACE_EN bit in MSR_IA32_RTIT_CTL > >> is set to 0. The values of remaining registers will be stable after everything > >> is serialized. I think this is too complex for the load lists alone. I belive > >> that currently SDM instructs to use load lists only for toggling this single > >> bit on-or-off. > > > > I think that's exactly what we want: handling TraceEn at > > vmentry/vmexit, so that no hypervisor packets are recorded. The rest > > of the MSRs can be handled in VMM mode without issues. Switching those > > on every vmentry/vmexit would also add more overhead that needed, > > since I assume they don't need to be modified on every entry/exit? > > > Assuming that there is a single DomU per pcpu and they are never migrated between pcpus then you never need to modify the remaining MSRs. > > In case DomUs are floating or there are multiple DomUs per pcpu, we need to read out a few MSRs on vm-exit and restore them on vm-entry. Right now I'm always using this approach as I'm pretty not sure how to optimize it without introducing additional bugs. I will show the implementation in patch v2. I think you might likely only need to modify the MSRs when doing context switches of domains, instead of doing it on every vmentry/vmexit? Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 11:49:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 11:49:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlt3P-0002qv-4i; Thu, 18 Jun 2020 11:49:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlt3O-0002qo-IK for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 11:49:58 +0000 X-Inumbo-ID: d526955e-b159-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d526955e-b159-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 11:49:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 092DDAC50; Thu, 18 Jun 2020 11:49:55 +0000 (UTC) Subject: Re: [PATCH] VT-x: simplify/clarify vmx_load_pdptrs() To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200618101113.GI735@Air-de-Roger> From: Jan Beulich Message-ID: <762c5e4a-4132-b82f-7234-3b3e9508d1ae@suse.com> Date: Thu, 18 Jun 2020 13:49:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200618101113.GI735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Kevin Tian , Wei Liu , Jun Nakajima , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 12:11, Roger Pau Monné wrote: > On Thu, Jun 18, 2020 at 08:38:27AM +0200, Jan Beulich wrote: >> * Guests outside of long mode can't have PCID enabled. Drop the >> respective check to make more obvious that there's no security issue >> (from potentially accessing past the mapped page's boundary). >> >> * Only the low 32 bits of CR3 are relevant outside of long mode, even >> if they remained unchanged after leaving that mode. >> >> * Drop the unnecessary and badly typed local variable p. >> >> * Don't open-code hvm_long_mode_active() (and extend this to the related >> nested VT-x code). >> >> * Constify guest_pdptes to clarify that we're only reading from the >> page. >> >> Signed-off-by: Jan Beulich > > Reviewed-by: Roger Pau Monné Thanks. >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -1312,17 +1312,16 @@ static void vmx_set_interrupt_shadow(str >> >> static void vmx_load_pdptrs(struct vcpu *v) >> { >> - unsigned long cr3 = v->arch.hvm.guest_cr[3]; >> - uint64_t *guest_pdptes; >> + uint32_t cr3 = v->arch.hvm.guest_cr[3]; >> + const uint64_t *guest_pdptes; >> struct page_info *page; >> p2m_type_t p2mt; >> - char *p; >> >> /* EPT needs to load PDPTRS into VMCS for PAE. */ >> - if ( !hvm_pae_enabled(v) || (v->arch.hvm.guest_efer & EFER_LMA) ) >> + if ( !hvm_pae_enabled(v) || hvm_long_mode_active(v) ) >> return; >> >> - if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) ) >> + if ( cr3 & 0x1f ) >> goto crash; > > Intel SDM says bits 0 to 4 are ignored, not reserved, so I'm not sure > we need to crash the guest here. I have no reference how real hardware > behaves here, so maybe crashing is the right thing to do. No, I was mislead by the wording of the description in the old patch I've referenced. IOW ... >> @@ -1332,14 +1331,12 @@ static void vmx_load_pdptrs(struct vcpu >> * queue, but this is the wrong place. We're holding at least >> * the paging lock */ >> gdprintk(XENLOG_ERR, >> - "Bad cr3 on load pdptrs gfn %lx type %d\n", >> + "Bad cr3 on load pdptrs gfn %"PRIx32" type %d\n", >> cr3 >> PAGE_SHIFT, (int) p2mt); >> goto crash; >> } >> >> - p = __map_domain_page(page); >> - >> - guest_pdptes = (uint64_t *)(p + (cr3 & ~PAGE_MASK)); >> + guest_pdptes = __map_domain_page(page) + (cr3 & ~PAGE_MASK); > > Instead I think this could be: > > guest_pdptes = __map_domain_page(page) + (cr3 & ~(PAGE_MASK | 0x1f)); ... I agree and will change to this; I'll assume your R-b stands with the change made (and the description adjusted accordingly). Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 11:55:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 11:55:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlt8j-0003iV-QC; Thu, 18 Jun 2020 11:55:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlt8i-0003iQ-4p for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 11:55:28 +0000 X-Inumbo-ID: 995a614e-b15a-11ea-8496-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 995a614e-b15a-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 11:55:27 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: CveAVyGHF0CqV5F/97PfNZUCLyjpXZyf5EDwD6GISBNuzu4Q8mr9ZOushC1k0UR/HaqcEWfvL8 9QZ7FRw47aX84jhFRkSjIg4/k3C6qiwxyFucQCteozJXjvzOY9YA58E5ujHrjob67oIN9altol UQjRU1byJUVa/9dpSZM2497mIE39BDW0sZBfzHz/nP1jNVfQCNv8QmSC654skFw3M8d/LS8Bgq 1kXLHNIJ65KpBtbSy2X1jRqlF4qqkpl+fnxEx3yaaNvSGxcv8CnmMESsnLDk5u9sm8jNh2A//G Twc= X-SBRS: 2.7 X-MesageID: 20706045 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20706045" Date: Thu, 18 Jun 2020 13:55:19 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op Message-ID: <20200618115519.GL735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> <832789003.9534743.1592478099057.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <832789003.9534743.1592478099057.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , Jan Beulich , Andrew Cooper , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote: > ----- 18 cze 2020 o 5:20, Tamas K Lengyel tamas.k.lengyel@gmail.com napisał(a): > > >> >> + > >> >> + a.mfn = v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT; > >> > > >> > This will not work for translated domains, ie: a PVH or HVM domain > >> > won't be able to use this interface since it has no way to request the > >> > mapping of a specific mfn into it's physmap. I think we need to take > >> > this into account when deciding how the interface should be, so that > >> > we don't corner ourselves with a PV only interface. > >> > >> Please be aware that this is only going to be used by Dom0. Is is well-supported > >> case that somebody is using PVH/HVM Dom0? > >> > >> I think that all Virtual Machine Introspection stuff currently requires to have > >> Dom0 PV. Our main goal is to have this working well in combo with VMI. > > > > FYI the VMI interface doesn't require a PV domain. It works fine from > > PVH dom0 or even from a secondary privileged HVM DomU as well, > > provided you have the right XSM policy to allow that. > > > > Tamas > > > It was previously stated that: > > > PVH or HVM domain > > won't be able to use this interface since it has no way to request the > > mapping of a specific mfn into it's physmap. > > but however, taking LibVMI as an example: > > https://github.com/libvmi/libvmi/blob/c461e20ae88bc62c08c27f50fcead23c27a30f9e/libvmi/driver/xen/xen.c#L51 > > An essential abstraction xen_get_memory() relies on xc_map_foreign_range(). Doesn't this mean that it's not usable from PVH or HVM domains, or did I got it all wrong? That was my fault, so the buffer mfns are assigned to Xen, and then the Xen domain ID is used to map those, which should work on both PV and HVM (or PVH). I still think using XENMEM_acquire_resource might be better, but I would let others comment. Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 12:22:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 12:22:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltYk-00069j-3h; Thu, 18 Jun 2020 12:22:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltYi-00069e-Jz for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 12:22:20 +0000 X-Inumbo-ID: 5a73fa86-b15e-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5a73fa86-b15e-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 12:22:19 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id q11so5854114wrp.3 for ; Thu, 18 Jun 2020 05:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NkLr5bWTwqZ1psD1HxctrB7WPqTEgw2PgcH6ag0UVxE=; b=P0C8R0cYYiUuB0nwpvtuNXPb9/YWUDE81t2J/aZa2eFgdzV6u9TFmPGI5c28F9Un+9 EYNZiAUbAtrZpnZnQ3/6mtVNH88m+VAvVzlrZhOmQVgYPwfzCP1DiQNtFJcZXGJwf2wU MaAAIqwBGI8Z+qu1D+kvSAB+2bfhx6Fqr95FuWz0VwbO1EBM8ohPl2KQmd1VVnqH6IV+ aTQ98MKRmCHs1H+xZr8t3nYDbiHRMYtP+lZv3ncJoqf7cFtW5pGSwXGEBmmqmkZIfh80 8OCsVWRVFlRwzuUPoE+GP1aNV1vPSecNUEMh2w1wgXxXNhrfFrB/PFl4dW1BQDSPDtw6 A7/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NkLr5bWTwqZ1psD1HxctrB7WPqTEgw2PgcH6ag0UVxE=; b=FVoJPGCa+3e55rOydqtI0AFB3XvOgmq58w1wVlA5b4mEgp6tzrzb9kyH/c+7+/U81A I3A31IvvfTbbZskobmWIleh+7I4ZyYr57wXb7r+dF+IHH6hJvEYZWZTGEg3k8qhksy/X Fb43zZy+2G76p2kZR6bh1sQ2CvhaQJ9zkk9WEJvI1H64SyWMWqn7uv5aSldOQbST4J/C bXXxq84c2sFEzMr3Ec/G0xsJSyBNzTVhYdGR8loXBlIC6eJ9yW4r+RMOXwq/QHl6Fxq8 d/JHN2MHXUSU3sllKoks4U6lGFzzdtsCUBENKzB8pvBBh5WAKdj/E2DrlBd+sn1exzZ/ Yijw== X-Gm-Message-State: AOAM533htgTRcC95bQd6mjS8fPFvf0p4lJUNbd2TYxDUPkQKiSQQc/Xs H9UcwK6d+zp6LbGPRDqPWDLFvgIKSLpH1XcGCNo= X-Google-Smtp-Source: ABdhPJzRhZbnXOowItpqnFl5MQXBbxtVMcMFozsnqb8GQz4eUHEruvH0x8rQpPc/MS6Hx05hwAAwQyv4kvzcQlb6BfI= X-Received: by 2002:adf:e648:: with SMTP id b8mr4501628wrn.386.1592482938644; Thu, 18 Jun 2020 05:22:18 -0700 (PDT) MIME-Version: 1.0 References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> <20200618094014.GH735@Air-de-Roger> In-Reply-To: <20200618094014.GH735@Air-de-Roger> From: Tamas K Lengyel Date: Thu, 18 Jun 2020 06:21:42 -0600 Message-ID: Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Jun Nakajima , Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 3:42 AM Roger Pau Monn=C3=A9 = wrote: > > On Thu, Jun 18, 2020 at 08:30:08AM +0200, Jan Beulich wrote: > > On 17.06.2020 18:19, Tamas K Lengyel wrote: > > > While forking VMs running a small RTOS system (Zephyr) a Xen crash ha= s been > > > observed due to a mm-lock order violation while copying the HVM CPU c= ontext > > > from the parent. This issue has been identified to be due to > > > hap_update_paging_modes first getting a lock on the gfn using get_gfn= . This > > > call also creates a shared entry in the fork's memory map for the cr3= gfn. The > > > function later calls hap_update_cr3 while holding the paging_lock, wh= ich > > > results in the lock-order violation in vmx_load_pdptrs when it tries = to unshare > > > the above entry when it grabs the page with the P2M_UNSHARE flag set. > > > > > > Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHA= RE was > > > unnecessary to start with. Using P2M_ALLOC is the appropriate flag to= ensure > > > the p2m is properly populated and to avoid the lock-order violation w= e > > > observed. > > > > Using P2M_ALLOC is not going to address the original problem though > > afaict: You may hit the mem_sharing_fork_page() path that way, and > > via nominate_page() =3D> __grab_shared_page() =3D> mem_sharing_page_loc= k() > > you'd run into a lock order violation again. > > Well, I guess Tamas avoids this because of the get_gfn call in > hap_update_paging_modes will have already populated the entry, so it's > never going to hit the p2m_is_hole check in __get_gfn_type_access. > > > The change is an improvement, so I'd be fine with it going in this > > way, but only as long as the description mentions that there's still > > an open issue here (which may be non-trivial to address). Or perhaps > > combining with your v1 change is the way to go (for now or even > > permanently)? > > If vmx_load_pdptrs only requires P2M_ALLOC then this is already > covered by the call to get_gfn performed in hap_update_paging_modes, > so I don't think there's much point in merging with v1, as forcing > hap_update_paging_modes to unshare the entry won't affect > vmx_load_pdptrs anymore. > > I'm however worried about other code paths that can call into > vmx_load_pdptrs with mm locks taken, and I agree it would be safer to > assert that all the higher layers make sure the cr3 loaded is > correctly populated for a query without P2M_ALLOC to succeed. Using P2M_ALLOC is always safe if 1) the entry is already populated like in this case but also in 2) in case the gfn is a hole and gets forked. In mem_sharing the paging lock order is only applicable when an already present entry is getting converted to a shared type or a shared typed is getting unshared. It does not apply when a hole is being plugged. So this is safe in other paths as well where the entry is not yet present. Tamas From xen-devel-bounces@lists.xenproject.org Thu Jun 18 12:39:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 12:39:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltpX-00078l-J4; Thu, 18 Jun 2020 12:39:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltpW-00078g-En for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 12:39:42 +0000 X-Inumbo-ID: c762a33e-b160-11ea-b7bb-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c762a33e-b160-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 12:39:41 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Vde6Lsb0Im3oy8Ro52P0XuqK9F/e+IpWZmeylbn043QgzeFa6UuA7tNdbQGhlZaiNTtnyYH6Th hGqY8TtUlpSZvyWv3+zNgRadANk7FMLcGNajE1H3VYC2NRyZ3lUw1jpJsowCDsbQZbsBt3E6Fr 9m3eVUd3ce95GuD3rv7xqoDJfbcp+3VmJ4E6wUZy3gONEB/xMN+KQOB/L9SDbO0VzBCdEWm25J xyyrbj2r0hg3Kk1v6yGoXGeiSIse8bSFwHNtvLIjAiZkNvEROw+FWO4MQV924Bd/5UA9BxH90R Jd8= X-SBRS: 2.7 X-MesageID: 20362933 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20362933" Date: Thu, 18 Jun 2020 14:39:33 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH] VT-x: simplify/clarify vmx_load_pdptrs() Message-ID: <20200618123933.GM735@Air-de-Roger> References: <20200618101113.GI735@Air-de-Roger> <762c5e4a-4132-b82f-7234-3b3e9508d1ae@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <762c5e4a-4132-b82f-7234-3b3e9508d1ae@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Kevin Tian , Wei Liu , Jun Nakajima , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 01:49:58PM +0200, Jan Beulich wrote: > On 18.06.2020 12:11, Roger Pau Monné wrote: > > On Thu, Jun 18, 2020 at 08:38:27AM +0200, Jan Beulich wrote: > >> - guest_pdptes = (uint64_t *)(p + (cr3 & ~PAGE_MASK)); > >> + guest_pdptes = __map_domain_page(page) + (cr3 & ~PAGE_MASK); > > > > Instead I think this could be: > > > > guest_pdptes = __map_domain_page(page) + (cr3 & ~(PAGE_MASK | 0x1f)); > > ... I agree and will change to this; I'll assume your R-b stands > with the change made (and the description adjusted accordingly). Sure. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 12:40:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 12:40:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltqN-0007qK-Sq; Thu, 18 Jun 2020 12:40:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltqM-0007qA-Q6 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 12:40:34 +0000 X-Inumbo-ID: e6f3ac20-b160-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e6f3ac20-b160-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 12:40:34 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id t194so5480975wmt.4 for ; Thu, 18 Jun 2020 05:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bt9px4pOf6S5pZhscAwBoRnbAk0cS6+u8RkZG2zxoYM=; b=Q+r8Lo3LYB21wWuycSLZ8ESK1Pdp+XXcrGFB4P+U3fIEtDEiLpl3p4fxwGYMZ8KNru CTt2NXZTuO2QKDzwmU9eDGeRBYMr95Xuy701A4F6uF0BTkLzVc8wdj5lfHxf3YIsr0zl XfWe2057DseiMvKJ1sUy9S3rBaOBkOKO8I4Ow+aOsE2GbO+FBt0SpYE4dnVJx/CzhOF+ fhdNJYMrymK5IOcfrm+ukTLIU1i83fOewrIurtubWhEQZDct1cgOm0O4cLgaFa24mCF5 /uqLdNvBquZfDu6jTTn+Fe53E7aftteWKG5DyLb+LE8KUgLoWVoQkORepsM+M+dFIuU8 o2QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bt9px4pOf6S5pZhscAwBoRnbAk0cS6+u8RkZG2zxoYM=; b=bgslk9zZMv4pZGLl2n1mzw+yyrTqVYvzHYz7lpC9fF2Gih8EhXpRRIW5M6jeRGdxQo Z6J3YO+Lo2+PZzaiypcvFRzt6ff1Ozn2qOsliPXE3k8u72tFDnqZQvqmnrIM0X0mvWJh ouEChXRvpy51akjsMAsX7V6YmCzVIq2VqtDSdIlm5kr/ZIqlrA4AMjgVu9YWz1jftN4n uGLAIhR3aKzJ7un9L3kTuGvoz2HSOXOFmCoQpRXTbhooHmQ5yXNLSzCx9aKitOH6wG63 ZyJ0gr9SOWpXLvj1mmtXZZ61QDQVSA72ES8QgweVjwO38mUOo+F81GIxpKCa6fgYG/Hj aGJw== X-Gm-Message-State: AOAM531X93Q85NaffbWvspe+msojNjL5EDi+yFZdFzsYqJ3lRpu9V3h3 QqGwzAz/yPhdDozhcNz2i6VgI7EjEwmPzviEx4Y= X-Google-Smtp-Source: ABdhPJyEzw4cb/NQnyfBzVR3Lv4bcUy5bFtXj2r/kHdAodvdz3FPx8CgVFAw27J/db/vbINEilpERyGuTb05y2h8tJY= X-Received: by 2002:a05:600c:2294:: with SMTP id 20mr4056159wmf.51.1592484033356; Thu, 18 Jun 2020 05:40:33 -0700 (PDT) MIME-Version: 1.0 References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> In-Reply-To: From: Tamas K Lengyel Date: Thu, 18 Jun 2020 06:39:57 -0600 Message-ID: Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , Jun Nakajima , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrote: > > On 17.06.2020 18:19, Tamas K Lengyel wrote: > > While forking VMs running a small RTOS system (Zephyr) a Xen crash has been > > observed due to a mm-lock order violation while copying the HVM CPU context > > from the parent. This issue has been identified to be due to > > hap_update_paging_modes first getting a lock on the gfn using get_gfn. This > > call also creates a shared entry in the fork's memory map for the cr3 gfn. The > > function later calls hap_update_cr3 while holding the paging_lock, which > > results in the lock-order violation in vmx_load_pdptrs when it tries to unshare > > the above entry when it grabs the page with the P2M_UNSHARE flag set. > > > > Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was > > unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure > > the p2m is properly populated and to avoid the lock-order violation we > > observed. > > Using P2M_ALLOC is not going to address the original problem though > afaict: You may hit the mem_sharing_fork_page() path that way, and > via nominate_page() => __grab_shared_page() => mem_sharing_page_lock() > you'd run into a lock order violation again. Note that the nominate_page you see in that path is for the parent VM. The paging lock is not taken for the parent VM thus nominate_page succeeds without any issues any time fork_page is called. There is no nominate_page called for the client domain as there is nothing to nominate when plugging a hole. Tamas From xen-devel-bounces@lists.xenproject.org Thu Jun 18 12:46:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 12:46:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltw2-00082P-Hs; Thu, 18 Jun 2020 12:46:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltw1-00082K-0x for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 12:46:25 +0000 X-Inumbo-ID: b7977bc2-b161-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b7977bc2-b161-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 12:46:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2B206ACA7; Thu, 18 Jun 2020 12:46:22 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE To: Tamas K Lengyel References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 14:46:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , Jun Nakajima , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 14:39, Tamas K Lengyel wrote: > On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrote: >> >> On 17.06.2020 18:19, Tamas K Lengyel wrote: >>> While forking VMs running a small RTOS system (Zephyr) a Xen crash has been >>> observed due to a mm-lock order violation while copying the HVM CPU context >>> from the parent. This issue has been identified to be due to >>> hap_update_paging_modes first getting a lock on the gfn using get_gfn. This >>> call also creates a shared entry in the fork's memory map for the cr3 gfn. The >>> function later calls hap_update_cr3 while holding the paging_lock, which >>> results in the lock-order violation in vmx_load_pdptrs when it tries to unshare >>> the above entry when it grabs the page with the P2M_UNSHARE flag set. >>> >>> Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was >>> unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure >>> the p2m is properly populated and to avoid the lock-order violation we >>> observed. >> >> Using P2M_ALLOC is not going to address the original problem though >> afaict: You may hit the mem_sharing_fork_page() path that way, and >> via nominate_page() => __grab_shared_page() => mem_sharing_page_lock() >> you'd run into a lock order violation again. > > Note that the nominate_page you see in that path is for the parent VM. > The paging lock is not taken for the parent VM thus nominate_page > succeeds without any issues any time fork_page is called. There is no > nominate_page called for the client domain as there is nothing to > nominate when plugging a hole. But that's still a lock order issue then, isn't it? Just one that the machinery can't detect / assert upon. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 12:50:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 12:50:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltzb-0000MV-1r; Thu, 18 Jun 2020 12:50:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jltzZ-0000G5-AU for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 12:50:05 +0000 X-Inumbo-ID: 3a3f3255-b162-11ea-ba90-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3a3f3255-b162-11ea-ba90-12813bfff9fa; Thu, 18 Jun 2020 12:50:03 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: lDJZg6VShbzXaw02eUhPtEgdJTN60PhsvsMwWw/DICKGK20hV7uWOZk7JGzQxW7n4dR+ANidpq UcF31dIASKj6c17itJeeREyA0gN7E3qxR4cw8mtbeOhS8CMoaNfNdWO+BsIAoVz4ZaUIbIHDIH UKKEc/NerjpaKrqGIi/WrKXEFMQaImtXQW3qlCxGbqgq792TMm6tOJUiiffURraV1C0TRAdXiI QIuLAc0xdtPfq1YTeamtaZEDxvEPgBHojD3LG0Ia0HBw3GKQ0yS1wRnYmxMWlvfj6QnSY8/2OC mj4= X-SBRS: 2.7 X-MesageID: 21149400 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="21149400" Date: Thu, 18 Jun 2020 14:49:56 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Message-ID: <20200618124956.GN735@Air-de-Roger> References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> <20200618094014.GH735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Jun Nakajima , Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 06:21:42AM -0600, Tamas K Lengyel wrote: > On Thu, Jun 18, 2020 at 3:42 AM Roger Pau Monné wrote: > > > > On Thu, Jun 18, 2020 at 08:30:08AM +0200, Jan Beulich wrote: > > > On 17.06.2020 18:19, Tamas K Lengyel wrote: > > > > While forking VMs running a small RTOS system (Zephyr) a Xen crash has been > > > > observed due to a mm-lock order violation while copying the HVM CPU context > > > > from the parent. This issue has been identified to be due to > > > > hap_update_paging_modes first getting a lock on the gfn using get_gfn. This > > > > call also creates a shared entry in the fork's memory map for the cr3 gfn. The > > > > function later calls hap_update_cr3 while holding the paging_lock, which > > > > results in the lock-order violation in vmx_load_pdptrs when it tries to unshare > > > > the above entry when it grabs the page with the P2M_UNSHARE flag set. > > > > > > > > Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was > > > > unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure > > > > the p2m is properly populated and to avoid the lock-order violation we > > > > observed. > > > > > > Using P2M_ALLOC is not going to address the original problem though > > > afaict: You may hit the mem_sharing_fork_page() path that way, and > > > via nominate_page() => __grab_shared_page() => mem_sharing_page_lock() > > > you'd run into a lock order violation again. > > > > Well, I guess Tamas avoids this because of the get_gfn call in > > hap_update_paging_modes will have already populated the entry, so it's > > never going to hit the p2m_is_hole check in __get_gfn_type_access. > > > > > The change is an improvement, so I'd be fine with it going in this > > > way, but only as long as the description mentions that there's still > > > an open issue here (which may be non-trivial to address). Or perhaps > > > combining with your v1 change is the way to go (for now or even > > > permanently)? > > > > If vmx_load_pdptrs only requires P2M_ALLOC then this is already > > covered by the call to get_gfn performed in hap_update_paging_modes, > > so I don't think there's much point in merging with v1, as forcing > > hap_update_paging_modes to unshare the entry won't affect > > vmx_load_pdptrs anymore. > > > > I'm however worried about other code paths that can call into > > vmx_load_pdptrs with mm locks taken, and I agree it would be safer to > > assert that all the higher layers make sure the cr3 loaded is > > correctly populated for a query without P2M_ALLOC to succeed. > > Using P2M_ALLOC is always safe if 1) the entry is already populated > like in this case but also in 2) in case the gfn is a hole and gets > forked. In mem_sharing the paging lock order is only applicable when > an already present entry is getting converted to a shared type or a > shared typed is getting unshared. It does not apply when a hole is > being plugged. But a hole being plugged can also imply that a page is being set shareable by nominate_page, which will take the mem sharing page lock? That would be the path: get_gfn_type_access -> __get_gfn_type_access -> (hole found in p2m) -> mem_sharing_fork_page -> nominate_page (with page not being shareable already). It's likely I'm missing some bits, this is all quite complex. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 12:51:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 12:51:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlu18-0000Uo-DZ; Thu, 18 Jun 2020 12:51:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlu16-0000Ui-Up for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 12:51:40 +0000 X-Inumbo-ID: 73e28290-b162-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 73e28290-b162-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 12:51:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 21086ACAD; Thu, 18 Jun 2020 12:51:38 +0000 (UTC) Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> <832789003.9534743.1592478099057.JavaMail.zimbra@cert.pl> <20200618115519.GL735@Air-de-Roger> From: Jan Beulich Message-ID: <9924a5d9-b851-257a-9a6a-7a5712898a71@suse.com> Date: Thu, 18 Jun 2020 14:51:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200618115519.GL735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , Andrew Cooper , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 13:55, Roger Pau Monné wrote: > On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote: >> It was previously stated that: >> >>> PVH or HVM domain >>> won't be able to use this interface since it has no way to request the >>> mapping of a specific mfn into it's physmap. >> >> but however, taking LibVMI as an example: >> >> https://github.com/libvmi/libvmi/blob/c461e20ae88bc62c08c27f50fcead23c27a30f9e/libvmi/driver/xen/xen.c#L51 >> >> An essential abstraction xen_get_memory() relies on xc_map_foreign_range(). Doesn't this mean that it's not usable from PVH or HVM domains, or did I got it all wrong? > > That was my fault, so the buffer mfns are assigned to Xen, and then > the Xen domain ID is used to map those, which should work on both PV > and HVM (or PVH). > > I still think using XENMEM_acquire_resource might be better, but I > would let others comment. +1 Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 12:52:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 12:52:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlu1i-0000Xx-Me; Thu, 18 Jun 2020 12:52:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlu1i-0000XS-0C for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 12:52:18 +0000 X-Inumbo-ID: 873353f6-b162-11ea-bca7-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 873353f6-b162-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 12:52:12 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: xbVmioi1Tt9J3AkzMvzVBKmTKpkEywDal7J9qwTkyXXT60NNx8TipqJGeH4j5dTE8nCnDtZQhK mgAVrtOohRL8hTDdoPFL+byvouZDvFtfp854BgJnFlA70616KTdgMpnswlqetqXUeDXnMaInHg WoJGKSgRzUayba0o3UZr5pPauilBjpGMyu8lI8ImlAf975e6wW1Zt+k9MpdmYa8NOzA+Hq1V2T EJsI2b/AzIvHdwXzg7b3HVq8+nwpcthYf6mgt6FaR6Ey1CiD6W8VSP9b0RdIBK1lVBmUaTozqS VvY= X-SBRS: 2.7 X-MesageID: 20592167 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20592167" Date: Thu, 18 Jun 2020 14:52:05 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Message-ID: <20200618125205.GO735@Air-de-Roger> References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Wei Liu , Paul Durrant , Tamas K Lengyel , Jun Nakajima , Andrew Cooper , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 02:46:24PM +0200, Jan Beulich wrote: > On 18.06.2020 14:39, Tamas K Lengyel wrote: > > On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrote: > >> > >> On 17.06.2020 18:19, Tamas K Lengyel wrote: > >>> While forking VMs running a small RTOS system (Zephyr) a Xen crash has been > >>> observed due to a mm-lock order violation while copying the HVM CPU context > >>> from the parent. This issue has been identified to be due to > >>> hap_update_paging_modes first getting a lock on the gfn using get_gfn. This > >>> call also creates a shared entry in the fork's memory map for the cr3 gfn. The > >>> function later calls hap_update_cr3 while holding the paging_lock, which > >>> results in the lock-order violation in vmx_load_pdptrs when it tries to unshare > >>> the above entry when it grabs the page with the P2M_UNSHARE flag set. > >>> > >>> Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was > >>> unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure > >>> the p2m is properly populated and to avoid the lock-order violation we > >>> observed. > >> > >> Using P2M_ALLOC is not going to address the original problem though > >> afaict: You may hit the mem_sharing_fork_page() path that way, and > >> via nominate_page() => __grab_shared_page() => mem_sharing_page_lock() > >> you'd run into a lock order violation again. > > > > Note that the nominate_page you see in that path is for the parent VM. > > The paging lock is not taken for the parent VM thus nominate_page > > succeeds without any issues any time fork_page is called. There is no > > nominate_page called for the client domain as there is nothing to > > nominate when plugging a hole. > > But that's still a lock order issue then, isn't it? Just one that > the machinery can't detect / assert upon. Yes, mm lock ordering doesn't differentiate between domains, and the current lock order on the pCPU is based on the last lock taken (regardless of the domain it belongs to). Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 13:01:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 13:01:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluAM-0001W0-OX; Thu, 18 Jun 2020 13:01:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluAL-0001Vv-Us for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 13:01:14 +0000 X-Inumbo-ID: c96a3c0c-b163-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c96a3c0c-b163-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 13:01:13 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id b82so5117308wmb.1 for ; Thu, 18 Jun 2020 06:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/BAcbHD+FNYqCmOTSTggIrjw3b8LA7HRlyFqGzv+6Qc=; b=a9qwrHfuMVjXURPsIJ8wGymBYG3Zsr39wMbZE8IxmRy0ZeZUnsa3kfzucHotGQr7uv hz4UdHucN6DQvs9QCOD6LVgtNzPUHM6mtBfwue0gaVd5D84INrSFnKVSzbzcSZDf1waE yEC07/cRIsFDC6DKgWhuHK+9yoW5HOfZdg4ozI9QdIICz0luyvXHeJa6Ivv8e1viKXaB sHhKzyAYiHQJOhkzFosX3EqVAwnuh6FNLSgpFXBpjOc3oHh0qVHUu0FjWR8T2ffrx16E gKg5B5bdbc9H+NnND2xWcbrkg3qLfYIP07Oer5Wbw+rDFEBfHISLTO9ATv3ZO/1twKE1 7JXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/BAcbHD+FNYqCmOTSTggIrjw3b8LA7HRlyFqGzv+6Qc=; b=Twiavu4elMLI85a0LIz+BEWlEQrdByDDtrlc+EkbRSiFtJqVEqjAtA4eUvskjAZ1QB YCwjmMZKxuQ4HYTk7gUBHC5UjYrV4KRYA11BEDi6zgS4G7HkgZHIOZnfg1CBJjV9rcV3 4HmAkqy8rPpZDWzCYQBNrNl/cDUUXNTcsZDIXrTLSh1pXHCg2Rom22zNAGmkxUAAMGtZ f9fb8cgr1nbWJeXgZNVqyuop3+Hazvm7uQ5/Re3ZENNrIrAcQtUeFTOGb1M2BxSZbE2i sg4+ouUP9b3/0Hq4MVcT8ttjABD2TRbpyWgp/NOZ9V6CR/5lrqwD+oOlHbn1tsu/976m cOTg== X-Gm-Message-State: AOAM533B0JTIXX88vDasKzHKuZEzK+c9BiQpnWurbCiqOsxK7roMNCik ISPBhPXilPWc8+XV5EZBRxUYwHGv9ymCTN7TsXfwKsfx7Vo= X-Google-Smtp-Source: ABdhPJxbWQfK/97nCEpBrBko87GdAvQRhOhWBDex74IKrrC71+WV1qdTJwJERZLs3QFIpf5QKuhgoDgfaksis73Jbyo= X-Received: by 2002:a1c:1b13:: with SMTP id b19mr3868419wmb.84.1592485272336; Thu, 18 Jun 2020 06:01:12 -0700 (PDT) MIME-Version: 1.0 References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> <20200618125205.GO735@Air-de-Roger> In-Reply-To: <20200618125205.GO735@Air-de-Roger> From: Tamas K Lengyel Date: Thu, 18 Jun 2020 07:00:37 -0600 Message-ID: Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Jun Nakajima , Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 6:52 AM Roger Pau Monn=C3=A9 = wrote: > > On Thu, Jun 18, 2020 at 02:46:24PM +0200, Jan Beulich wrote: > > On 18.06.2020 14:39, Tamas K Lengyel wrote: > > > On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrot= e: > > >> > > >> On 17.06.2020 18:19, Tamas K Lengyel wrote: > > >>> While forking VMs running a small RTOS system (Zephyr) a Xen crash = has been > > >>> observed due to a mm-lock order violation while copying the HVM CPU= context > > >>> from the parent. This issue has been identified to be due to > > >>> hap_update_paging_modes first getting a lock on the gfn using get_g= fn. This > > >>> call also creates a shared entry in the fork's memory map for the c= r3 gfn. The > > >>> function later calls hap_update_cr3 while holding the paging_lock, = which > > >>> results in the lock-order violation in vmx_load_pdptrs when it trie= s to unshare > > >>> the above entry when it grabs the page with the P2M_UNSHARE flag se= t. > > >>> > > >>> Since vmx_load_pdptrs only reads from the page its usage of P2M_UNS= HARE was > > >>> unnecessary to start with. Using P2M_ALLOC is the appropriate flag = to ensure > > >>> the p2m is properly populated and to avoid the lock-order violation= we > > >>> observed. > > >> > > >> Using P2M_ALLOC is not going to address the original problem though > > >> afaict: You may hit the mem_sharing_fork_page() path that way, and > > >> via nominate_page() =3D> __grab_shared_page() =3D> mem_sharing_page_= lock() > > >> you'd run into a lock order violation again. > > > > > > Note that the nominate_page you see in that path is for the parent VM= . > > > The paging lock is not taken for the parent VM thus nominate_page > > > succeeds without any issues any time fork_page is called. There is no > > > nominate_page called for the client domain as there is nothing to > > > nominate when plugging a hole. > > > > But that's still a lock order issue then, isn't it? Just one that > > the machinery can't detect / assert upon. > > Yes, mm lock ordering doesn't differentiate between domains, and the > current lock order on the pCPU is based on the last lock taken > (regardless of the domain it belongs to). I see, makes sense. In that case the issue is avoided purely due to get_gfn being called that happens before the paging_lock is taken. That would have to be the way-to-go on other paths leading to vmx_load_pdptrs as well but since all other paths leading there do it without the paging lock being taken there aren't any more adjustments necessary right now that I can see. Tamas From xen-devel-bounces@lists.xenproject.org Thu Jun 18 13:10:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 13:10:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluJS-0002PQ-OP; Thu, 18 Jun 2020 13:10:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluJR-0002PL-Cn for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 13:10:37 +0000 X-Inumbo-ID: 18d6dae2-b165-11ea-ba90-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 18d6dae2-b165-11ea-ba90-12813bfff9fa; Thu, 18 Jun 2020 13:10:36 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 04E0EA3054; Thu, 18 Jun 2020 15:10:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id E7E51A1C5A; Thu, 18 Jun 2020 15:10:33 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 63qMKdKcD9Rv; Thu, 18 Jun 2020 15:10:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 559B0A3054; Thu, 18 Jun 2020 15:10:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id U-akyG1LkELX; Thu, 18 Jun 2020 15:10:33 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2F7E0A1C5A; Thu, 18 Jun 2020 15:10:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 11B12222F3; Thu, 18 Jun 2020 15:10:03 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id bTjnkH134zcN; Thu, 18 Jun 2020 15:09:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 7E443214EE; Thu, 18 Jun 2020 15:09:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YfGNSuXkNlqH; Thu, 18 Jun 2020 15:09:57 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 5F96121125; Thu, 18 Jun 2020 15:09:57 +0200 (CEST) Date: Thu, 18 Jun 2020 15:09:57 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <1226758073.9662727.1592485797234.JavaMail.zimbra@cert.pl> In-Reply-To: <9924a5d9-b851-257a-9a6a-7a5712898a71@suse.com> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> <832789003.9534743.1592478099057.JavaMail.zimbra@cert.pl> <20200618115519.GL735@Air-de-Roger> <9924a5d9-b851-257a-9a6a-7a5712898a71@suse.com> Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: IRz1Owj0IBmW4onGTvXVKPePkcy0OA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , Andrew Cooper , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 18 cze 2020 o 14:51, Jan Beulich jbeulich@suse.com napisa=C5=82(a): > On 18.06.2020 13:55, Roger Pau Monn=C3=A9 wrote: >> On Thu, Jun 18, 2020 at 01:01:39PM +0200, Micha=C5=82 Leszczy=C5=84ski w= rote: >>> It was previously stated that: >>> >>>> PVH or HVM domain >>>> won't be able to use this interface since it has no way to request the >>>> mapping of a specific mfn into it's physmap. >>> >>> but however, taking LibVMI as an example: >>> >>> https://github.com/libvmi/libvmi/blob/c461e20ae88bc62c08c27f50fcead23c2= 7a30f9e/libvmi/driver/xen/xen.c#L51 >>> >>> An essential abstraction xen_get_memory() relies on xc_map_foreign_rang= e(). >>> Doesn't this mean that it's not usable from PVH or HVM domains, or did = I got it >>> all wrong? >>=20 >> That was my fault, so the buffer mfns are assigned to Xen, and then >> the Xen domain ID is used to map those, which should work on both PV >> and HVM (or PVH). >>=20 >> I still think using XENMEM_acquire_resource might be better, but I >> would let others comment. >=20 > +1 >=20 > Jan I'm trying to implement this right now. I've added some very simple code to= mm.c just for testing: --- diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e376fc7e8f..aaaefe6d23 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4624,6 +4624,26 @@ int arch_acquire_resource(struct domain *d, unsigned= int type, } break; } + + case XENMEM_resource_vmtrace_buf: + { + uint64_t output_base; + mfn_t mfn; + unsigned int i; + + printk("vmtrace buf acquire\n"); + output_base =3D d->vcpu[id]->arch.hvm.vmx.ipt_state->output_base; + mfn =3D mfn_x(output_base >> PAGE_SHIFT); + + rc =3D 0; + for ( i =3D 0; i < nr_frames; i++ ) + { + __map_domain_page_global(mfn_to_page(mfn + i)); + mfn_list[i] =3D mfn + i; + } + + break; + } #endif default: --- and then in my "proctrace" tool I'm trying to acquire it like this: fres =3D xenforeignmemory_map_resource( fmem, domid, XENMEM_resource_vmtrace_buf, /* vcpu: */ 0, /* frame: */ 0, /* num_frames: */ 128, (void **)&buf= , PROT_READ, 0); ioctl fails with "Argument list too long". It works fine when I provide som= e small number of frames (e.g. num_frames: 1 or 32), but doesn't work for a= ny larger quantity. How should I proceed with this? The PT buffer could be large, even up to 4 = GB. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Thu Jun 18 13:24:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 13:24:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluWw-0003Mk-1w; Thu, 18 Jun 2020 13:24:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluWu-0003M1-QP for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 13:24:32 +0000 X-Inumbo-ID: 0b02b5f6-b167-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0b02b5f6-b167-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 13:24:31 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B954AAD2A; Thu, 18 Jun 2020 13:24:29 +0000 (UTC) Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> <832789003.9534743.1592478099057.JavaMail.zimbra@cert.pl> <20200618115519.GL735@Air-de-Roger> <9924a5d9-b851-257a-9a6a-7a5712898a71@suse.com> <1226758073.9662727.1592485797234.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <1b7f1eb3-5cf5-869c-d2bc-48e3e7a85e1c@suse.com> Date: Thu, 18 Jun 2020 15:24:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1226758073.9662727.1592485797234.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , Andrew Cooper , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 15:09, Michał Leszczyński wrote: > ----- 18 cze 2020 o 14:51, Jan Beulich jbeulich@suse.com napisał(a): > >> On 18.06.2020 13:55, Roger Pau Monné wrote: >>> On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote: >>>> It was previously stated that: >>>> >>>>> PVH or HVM domain >>>>> won't be able to use this interface since it has no way to request the >>>>> mapping of a specific mfn into it's physmap. >>>> >>>> but however, taking LibVMI as an example: >>>> >>>> https://github.com/libvmi/libvmi/blob/c461e20ae88bc62c08c27f50fcead23c27a30f9e/libvmi/driver/xen/xen.c#L51 >>>> >>>> An essential abstraction xen_get_memory() relies on xc_map_foreign_range(). >>>> Doesn't this mean that it's not usable from PVH or HVM domains, or did I got it >>>> all wrong? >>> >>> That was my fault, so the buffer mfns are assigned to Xen, and then >>> the Xen domain ID is used to map those, which should work on both PV >>> and HVM (or PVH). >>> >>> I still think using XENMEM_acquire_resource might be better, but I >>> would let others comment. >> >> +1 >> >> Jan > > > I'm trying to implement this right now. I've added some very simple code to mm.c just for testing: > > --- > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index e376fc7e8f..aaaefe6d23 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -4624,6 +4624,26 @@ int arch_acquire_resource(struct domain *d, unsigned int type, > } > break; > } > + > + case XENMEM_resource_vmtrace_buf: > + { > + uint64_t output_base; > + mfn_t mfn; > + unsigned int i; > + > + printk("vmtrace buf acquire\n"); > + output_base = d->vcpu[id]->arch.hvm.vmx.ipt_state->output_base; > + mfn = mfn_x(output_base >> PAGE_SHIFT); > + > + rc = 0; > + for ( i = 0; i < nr_frames; i++ ) > + { > + __map_domain_page_global(mfn_to_page(mfn + i)); > + mfn_list[i] = mfn + i; > + } > + > + break; > + } > #endif > > default: > > --- > > > and then in my "proctrace" tool I'm trying to acquire it like this: > > fres = xenforeignmemory_map_resource( > fmem, domid, XENMEM_resource_vmtrace_buf, > /* vcpu: */ 0, /* frame: */ 0, /* num_frames: */ 128, (void **)&buf, > PROT_READ, 0); > > > ioctl fails with "Argument list too long". It works fine when I provide some small number of frames (e.g. num_frames: 1 or 32), but doesn't work for any larger quantity. See xen/common/memory.c:acquire_resource(). So far larger quantities weren't needed, so there's an implementation limit of 32 right now. This can be lifted, but please not by growing the on-stack array (as the comment there also suggests). Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 13:26:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 13:26:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluZA-0003Sm-EB; Thu, 18 Jun 2020 13:26:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluZ9-0003Sg-8U for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 13:26:51 +0000 X-Inumbo-ID: 5dbce122-b167-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5dbce122-b167-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 13:26:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8A166AD2A; Thu, 18 Jun 2020 13:26:48 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE To: Tamas K Lengyel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> <20200618125205.GO735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 15:26:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , Jun Nakajima , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 15:00, Tamas K Lengyel wrote: > On Thu, Jun 18, 2020 at 6:52 AM Roger Pau Monné wrote: >> >> On Thu, Jun 18, 2020 at 02:46:24PM +0200, Jan Beulich wrote: >>> On 18.06.2020 14:39, Tamas K Lengyel wrote: >>>> On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wrote: >>>>> >>>>> On 17.06.2020 18:19, Tamas K Lengyel wrote: >>>>>> While forking VMs running a small RTOS system (Zephyr) a Xen crash has been >>>>>> observed due to a mm-lock order violation while copying the HVM CPU context >>>>>> from the parent. This issue has been identified to be due to >>>>>> hap_update_paging_modes first getting a lock on the gfn using get_gfn. This >>>>>> call also creates a shared entry in the fork's memory map for the cr3 gfn. The >>>>>> function later calls hap_update_cr3 while holding the paging_lock, which >>>>>> results in the lock-order violation in vmx_load_pdptrs when it tries to unshare >>>>>> the above entry when it grabs the page with the P2M_UNSHARE flag set. >>>>>> >>>>>> Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was >>>>>> unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure >>>>>> the p2m is properly populated and to avoid the lock-order violation we >>>>>> observed. >>>>> >>>>> Using P2M_ALLOC is not going to address the original problem though >>>>> afaict: You may hit the mem_sharing_fork_page() path that way, and >>>>> via nominate_page() => __grab_shared_page() => mem_sharing_page_lock() >>>>> you'd run into a lock order violation again. >>>> >>>> Note that the nominate_page you see in that path is for the parent VM. >>>> The paging lock is not taken for the parent VM thus nominate_page >>>> succeeds without any issues any time fork_page is called. There is no >>>> nominate_page called for the client domain as there is nothing to >>>> nominate when plugging a hole. >>> >>> But that's still a lock order issue then, isn't it? Just one that >>> the machinery can't detect / assert upon. >> >> Yes, mm lock ordering doesn't differentiate between domains, and the >> current lock order on the pCPU is based on the last lock taken >> (regardless of the domain it belongs to). > > I see, makes sense. In that case the issue is avoided purely due to > get_gfn being called that happens before the paging_lock is taken. > That would have to be the way-to-go on other paths leading to > vmx_load_pdptrs as well but since all other paths leading there do it > without the paging lock being taken there aren't any more adjustments > necessary right now that I can see. If this is indeed the case, then I guess all that's needed is a further extended / refined commit message in v3. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 13:32:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 13:32:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlue4-0004Gu-1T; Thu, 18 Jun 2020 13:31:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlue2-0004Gp-NL for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 13:31:54 +0000 X-Inumbo-ID: 12a032b0-b168-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 12a032b0-b168-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 13:31:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 1E607AFF7; Thu, 18 Jun 2020 13:31:52 +0000 (UTC) Subject: Re: [PATCH v1 1/7] x86/vmx: add Intel PT MSR definitions To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <2141998496.8765382.1592320789155.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <82380390-f3c8-29e1-202e-a32abf5d8f58@suse.com> Date: Thu, 18 Jun 2020 15:31:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <2141998496.8765382.1592320789155.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.06.2020 17:19, Michał Leszczyński wrote: > --- a/xen/include/asm-x86/msr-index.h > +++ b/xen/include/asm-x86/msr-index.h > @@ -621,4 +621,41 @@ > #define MSR_PKGC9_IRTL 0x00000634 > #define MSR_PKGC10_IRTL 0x00000635 > > +/* Intel PT MSRs */ > +#define MSR_IA32_RTIT_CTL 0x00000570 > +#define RTIT_CTL_TRACEEN (1ULL << 0) > +#define RTIT_CTL_CYCEN (1ULL << 1) > +#define RTIT_CTL_OS (1ULL << 2) > +#define RTIT_CTL_USR (1ULL << 3) > +#define RTIT_CTL_PWR_EVT_EN (1ULL << 4) > +#define RTIT_CTL_FUP_ON_PTW (1ULL << 5) > +#define RTIT_CTL_FABRIC_EN (1ULL << 6) > +#define RTIT_CTL_CR3_FILTER (1ULL << 7) > +#define RTIT_CTL_TOPA (1ULL << 8) > +#define RTIT_CTL_MTC_EN (1ULL << 9) > +#define RTIT_CTL_TSC_EN (1ULL << 10) > +#define RTIT_CTL_DIS_RETC (1ULL << 11) > +#define RTIT_CTL_PTW_EN (1ULL << 12) > +#define RTIT_CTL_BRANCH_EN (1ULL << 13) > +#define RTIT_CTL_MTC_FREQ_OFFSET 14 > +#define RTIT_CTL_MTC_FREQ (0x0fULL << RTIT_CTL_MTC_FREQ_OFFSET) > +#define RTIT_CTL_CYC_THRESH_OFFSET 19 > +#define RTIT_CTL_CYC_THRESH (0x0fULL << RTIT_CTL_CYC_THRESH_OFFSET) > +#define RTIT_CTL_PSB_FREQ_OFFSET 24 > +#define RTIT_CTL_PSB_FREQ (0x0fULL << RTIT_CTL_PSB_FREQ_OFFSET) > +#define RTIT_CTL_ADDR_OFFSET(n) (32 + 4 * (n)) > +#define RTIT_CTL_ADDR(n) (0x0fULL << RTIT_CTL_ADDR_OFFSET(n)) > +#define MSR_IA32_RTIT_STATUS 0x00000571 > +#define RTIT_STATUS_FILTER_EN (1ULL << 0) > +#define RTIT_STATUS_CONTEXT_EN (1ULL << 1) > +#define RTIT_STATUS_TRIGGER_EN (1ULL << 2) > +#define RTIT_STATUS_ERROR (1ULL << 4) > +#define RTIT_STATUS_STOPPED (1ULL << 5) > +#define RTIT_STATUS_BYTECNT (0x1ffffULL << 32) > +#define MSR_IA32_RTIT_CR3_MATCH 0x00000572 > +#define MSR_IA32_RTIT_OUTPUT_BASE 0x00000560 > +#define MSR_IA32_RTIT_OUTPUT_MASK 0x00000561 > +#define MSR_IA32_RTIT_ADDR_A(n) (0x00000580 + (n) * 2) > +#define MSR_IA32_RTIT_ADDR_B(n) (0x00000581 + (n) * 2) Please honor the comment at the top of the file as well as the one separating new content from not necessarily well-formed one further down. I also think Andrew wants no IA32 infixes anymore in new additions, albeit I'm still not fully convinced the resulting deviation from SDM naming is really helpful. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 13:35:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 13:35:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluhE-0004PU-GR; Thu, 18 Jun 2020 13:35:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluhD-0004PN-78 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 13:35:11 +0000 X-Inumbo-ID: 87c76298-b168-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 87c76298-b168-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 13:35:10 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id c3so6051286wru.12 for ; Thu, 18 Jun 2020 06:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PgU7W2ZEDR8G3GYE3WyiZ0cSbfQREU9R2sTXUYCmOWE=; b=aDT75fKfc8y05/WXaHkV7n6rDQyhyUYVOHTG3MSWmHwCmWta4YLHlffJodsTMBV9Ph GqIL2vz9vh27obm0XPMCW2MRxMTwwNtajyzWUNFBFcC6LutwABGSV7HymmRBYpG44h30 A6x/A7/tqjs1uNWQ0cAsFCGlGmDLl3zoJLfgJV8Ckl21ochFBAmooiZW805vmIjBFy02 xsVaG4wIMGANDkcV5cGDxXgEeyC4JTZXpnusXpFxPe/FjVDlclxAoOE8/iuNzfVqBXuk skMhEmCU4T7H8VlrwPJFJVmCUSQN6TVJA5t4vWfWLlFtcYOnhvWs2AS1imwH21mWQZgT cxzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PgU7W2ZEDR8G3GYE3WyiZ0cSbfQREU9R2sTXUYCmOWE=; b=rfplPNphiKP0pz+BnjAlfi9/V+U38BzqiHqrfO6DWHDc3xqUK+wxvEd3Daizb600Rv g+nQ4kLr6g1aFh+15mqDUOPo7sk1w74Gcpndgy7qRrgcjDF1wMZCcUW3tRZv2xmmLqUE jcRg6i7ism9Ex9FnHqJBBWx8PazPvlEfupEpjXoVu/s001OJ0nCI0ahrIbcPFxai7lmu Scr9CZrkKhycgTz4kgQbOGcgwajI5BcOMODdTfHNbAFISz7V+5C93YvTFxylZUisQ55K 8jSnSIFePpXO1b2Zwt3kK6wnblNt/AtLDAhO3AVGRMbT7SHYuncHyEi6FuUP6nVH8qQm g0XQ== X-Gm-Message-State: AOAM530VSEgnLAjCgqAbntI2UqdRzvKpQx8z1gpWSFwazPW00wJfDlIY fU61G1L8QWgZbGijx6vNKGPcTWZ3bYL5fBB9NyI= X-Google-Smtp-Source: ABdhPJy+xNr1SKrJ2FJ8JLX6h0Q5JyhpIM+GFVJ+ZbWA6RDtumN9h0U/YCGf5dwmiguivgXwiK6oAMhhLgBNptU/ips= X-Received: by 2002:a5d:6809:: with SMTP id w9mr4944689wru.182.1592487309702; Thu, 18 Jun 2020 06:35:09 -0700 (PDT) MIME-Version: 1.0 References: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> <20200618125205.GO735@Air-de-Roger> In-Reply-To: From: Tamas K Lengyel Date: Thu, 18 Jun 2020 07:34:34 -0600 Message-ID: Subject: Re: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE To: Jan Beulich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Wei Liu , Paul Durrant , Andrew Cooper , Jun Nakajima , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 7:26 AM Jan Beulich wrote: > > On 18.06.2020 15:00, Tamas K Lengyel wrote: > > On Thu, Jun 18, 2020 at 6:52 AM Roger Pau Monn=C3=A9 wrote: > >> > >> On Thu, Jun 18, 2020 at 02:46:24PM +0200, Jan Beulich wrote: > >>> On 18.06.2020 14:39, Tamas K Lengyel wrote: > >>>> On Thu, Jun 18, 2020 at 12:31 AM Jan Beulich wro= te: > >>>>> > >>>>> On 17.06.2020 18:19, Tamas K Lengyel wrote: > >>>>>> While forking VMs running a small RTOS system (Zephyr) a Xen crash= has been > >>>>>> observed due to a mm-lock order violation while copying the HVM CP= U context > >>>>>> from the parent. This issue has been identified to be due to > >>>>>> hap_update_paging_modes first getting a lock on the gfn using get_= gfn. This > >>>>>> call also creates a shared entry in the fork's memory map for the = cr3 gfn. The > >>>>>> function later calls hap_update_cr3 while holding the paging_lock,= which > >>>>>> results in the lock-order violation in vmx_load_pdptrs when it tri= es to unshare > >>>>>> the above entry when it grabs the page with the P2M_UNSHARE flag s= et. > >>>>>> > >>>>>> Since vmx_load_pdptrs only reads from the page its usage of P2M_UN= SHARE was > >>>>>> unnecessary to start with. Using P2M_ALLOC is the appropriate flag= to ensure > >>>>>> the p2m is properly populated and to avoid the lock-order violatio= n we > >>>>>> observed. > >>>>> > >>>>> Using P2M_ALLOC is not going to address the original problem though > >>>>> afaict: You may hit the mem_sharing_fork_page() path that way, and > >>>>> via nominate_page() =3D> __grab_shared_page() =3D> mem_sharing_page= _lock() > >>>>> you'd run into a lock order violation again. > >>>> > >>>> Note that the nominate_page you see in that path is for the parent V= M. > >>>> The paging lock is not taken for the parent VM thus nominate_page > >>>> succeeds without any issues any time fork_page is called. There is n= o > >>>> nominate_page called for the client domain as there is nothing to > >>>> nominate when plugging a hole. > >>> > >>> But that's still a lock order issue then, isn't it? Just one that > >>> the machinery can't detect / assert upon. > >> > >> Yes, mm lock ordering doesn't differentiate between domains, and the > >> current lock order on the pCPU is based on the last lock taken > >> (regardless of the domain it belongs to). > > > > I see, makes sense. In that case the issue is avoided purely due to > > get_gfn being called that happens before the paging_lock is taken. > > That would have to be the way-to-go on other paths leading to > > vmx_load_pdptrs as well but since all other paths leading there do it > > without the paging lock being taken there aren't any more adjustments > > necessary right now that I can see. > > If this is indeed the case, then I guess all that's needed is a further > extended / refined commit message in v3. Alright. Thanks, Tamas From xen-devel-bounces@lists.xenproject.org Thu Jun 18 13:40:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 13:40:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlumS-0005Ec-8f; Thu, 18 Jun 2020 13:40:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlumQ-0005EX-CB for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 13:40:34 +0000 X-Inumbo-ID: 47ff4ae4-b169-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 47ff4ae4-b169-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 13:40:33 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: yN3UFB3VzsZR+28uTtTftXIBNXMfN1rGaIT6HroeD/cbj2HC4NKoRzn5wXPyHvBNJT6eJRHF9w z6QlPbhrRxpkItIXVRdPrBHf6PjvWDXEoWGPq2X46h7jtI15H7k2nJOiCFjInhBjNhizKxJO+v X9q4sfBA2EfOuBNQPadI6vH7GY5O2Su4XUCd5PIWkd1UXRaqYyhQD7HCC8a9Hy0e0heqwdz+4z S+kbaWbfYHBugtHnPEayn+XzhxufkscS/JHoMT5l24KkoyDLcLEOhJmOPr88Un5hPRNH5+Hpk3 Gj4= X-SBRS: 2.7 X-MesageID: 20717356 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20717356" Date: Thu, 18 Jun 2020 15:40:23 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op Message-ID: <20200618134023.GP735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <998292451.9258672.1592421185726.JavaMail.zimbra@cert.pl> <832789003.9534743.1592478099057.JavaMail.zimbra@cert.pl> <20200618115519.GL735@Air-de-Roger> <9924a5d9-b851-257a-9a6a-7a5712898a71@suse.com> <1226758073.9662727.1592485797234.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1226758073.9662727.1592485797234.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , Jan Beulich , Andrew Cooper , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 03:09:57PM +0200, Michał Leszczyński wrote: > ----- 18 cze 2020 o 14:51, Jan Beulich jbeulich@suse.com napisał(a): > > > On 18.06.2020 13:55, Roger Pau Monné wrote: > >> On Thu, Jun 18, 2020 at 01:01:39PM +0200, Michał Leszczyński wrote: > >>> It was previously stated that: > >>> > >>>> PVH or HVM domain > >>>> won't be able to use this interface since it has no way to request the > >>>> mapping of a specific mfn into it's physmap. > >>> > >>> but however, taking LibVMI as an example: > >>> > >>> https://github.com/libvmi/libvmi/blob/c461e20ae88bc62c08c27f50fcead23c27a30f9e/libvmi/driver/xen/xen.c#L51 > >>> > >>> An essential abstraction xen_get_memory() relies on xc_map_foreign_range(). > >>> Doesn't this mean that it's not usable from PVH or HVM domains, or did I got it > >>> all wrong? > >> > >> That was my fault, so the buffer mfns are assigned to Xen, and then > >> the Xen domain ID is used to map those, which should work on both PV > >> and HVM (or PVH). > >> > >> I still think using XENMEM_acquire_resource might be better, but I > >> would let others comment. > > > > +1 > > > > Jan > > > I'm trying to implement this right now. I've added some very simple code to mm.c just for testing: > > --- > > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index e376fc7e8f..aaaefe6d23 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -4624,6 +4624,26 @@ int arch_acquire_resource(struct domain *d, unsigned int type, > } > break; > } > + > + case XENMEM_resource_vmtrace_buf: > + { > + uint64_t output_base; > + mfn_t mfn; > + unsigned int i; > + > + printk("vmtrace buf acquire\n"); > + output_base = d->vcpu[id]->arch.hvm.vmx.ipt_state->output_base; > + mfn = mfn_x(output_base >> PAGE_SHIFT); > + > + rc = 0; > + for ( i = 0; i < nr_frames; i++ ) > + { > + __map_domain_page_global(mfn_to_page(mfn + i)); I don't think you need the __map_domain_page_global? > + mfn_list[i] = mfn + i; I think you need mfn_add here, or else this won't build? > + } > + > + break; > + } > #endif > > default: > > --- > > > and then in my "proctrace" tool I'm trying to acquire it like this: > > fres = xenforeignmemory_map_resource( > fmem, domid, XENMEM_resource_vmtrace_buf, > /* vcpu: */ 0, /* frame: */ 0, /* num_frames: */ 128, (void **)&buf, > PROT_READ, 0); > > > ioctl fails with "Argument list too long". It works fine when I provide some small number of frames (e.g. num_frames: 1 or 32), but doesn't work for any larger quantity. > > How should I proceed with this? The PT buffer could be large, even up to 4 GB. I think adding a loop and hypercall continuation support could make this work without having to expand the size of mfn_list and gfn_list? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 13:43:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 13:43:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluon-0005L9-ML; Thu, 18 Jun 2020 13:43:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluon-0005L3-5f for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 13:43:01 +0000 X-Inumbo-ID: 9fe57968-b169-11ea-ba94-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9fe57968-b169-11ea-ba94-12813bfff9fa; Thu, 18 Jun 2020 13:43:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A6AD6ACA7; Thu, 18 Jun 2020 13:42:58 +0000 (UTC) Subject: Re: [PATCH for-4.14 2/8] x86/hvm: don't force vCPU 0 for IRQ 0 when using fixed destination mode To: Roger Pau Monne References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-3-roger.pau@citrix.com> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 15:43:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612155640.4101-3-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 17:56, Roger Pau Monne wrote: > When the IO APIC pin mapped to the ISA IRQ 0 has been configured to > use fixed delivery mode do not forcefully route interrupts to vCPU 0, > as the OS might have setup those interrupts to be injected to a > different vCPU, and injecting to vCPU 0 can cause the OS to miss such > interrupts or errors to happen due to unexpected vectors being > injected on vCPU 0. > > In order to fix remove such handling altogether for fixed destination > mode pins and just inject them according to the data setup in the > IO-APIC entry. > > Signed-off-by: Roger Pau Monné Technically Reviewed-by: Jan Beulich I wonder though why this was done in the first place - it very much feels like a workaround for certain guest behavior, and hence getting rid of it may mean a certain risk of regressions. Not a very good point in time to make risky changes ... Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 13:48:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 13:48:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluuS-0005Ww-BO; Thu, 18 Jun 2020 13:48:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jluuQ-0005Wr-TI for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 13:48:50 +0000 X-Inumbo-ID: 6fe14b9c-b16a-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6fe14b9c-b16a-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 13:48:49 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: eXVrxiEZY1DNXvLGo3rlCYCDtQny+I3gKjdm4UkjXcR468D+HNe87PXVRpSVYmasUNYbNRhAJT YSLiSBcJyBpGBhozGgbXbCNZ4ovZ7YKmLiczsKd/sVHDOVF85O6ex502EqLPdEktsDvigFD9Wx bM2pOi4+e5bUqaSppZj/gGVc5SnrblMdnax50kdz5CJBI8wnUqkCokYst0IIjZMSHzY03H/i6A oxEVskuE9plik12RbD3ql01VRssoVDpxjRD4ZRrZXwoKUEjeta/Pfc9nD9ctj69K7ATiBkHPMS 3hw= X-SBRS: 2.7 X-MesageID: 20372001 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20372001" Date: Thu, 18 Jun 2020 15:48:41 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 2/8] x86/hvm: don't force vCPU 0 for IRQ 0 when using fixed destination mode Message-ID: <20200618134841.GQ735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-3-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote: > On 12.06.2020 17:56, Roger Pau Monne wrote: > > When the IO APIC pin mapped to the ISA IRQ 0 has been configured to > > use fixed delivery mode do not forcefully route interrupts to vCPU 0, > > as the OS might have setup those interrupts to be injected to a > > different vCPU, and injecting to vCPU 0 can cause the OS to miss such > > interrupts or errors to happen due to unexpected vectors being > > injected on vCPU 0. > > > > In order to fix remove such handling altogether for fixed destination > > mode pins and just inject them according to the data setup in the > > IO-APIC entry. > > > > Signed-off-by: Roger Pau Monné > > Technically > Reviewed-by: Jan Beulich > > I wonder though why this was done in the first place - it very much > feels like a workaround for certain guest behavior, and hence > getting rid of it may mean a certain risk of regressions. Not a > very good point in time to make risky changes ... We can defer to after the release I guess, but I will still ask for the changes to be backported. What we currently do is broken, up to the point that FreeBSD cannot use the PIT because it will likely route the interrupt to a vCPU != 0 in fixed mode, and then it will just get stuck because the vector is delivered to vCPU 0 where it's not even configured. Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:08:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:08:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvDT-0007J4-40; Thu, 18 Jun 2020 14:08:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvDS-0007Iz-1Z for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:08:30 +0000 X-Inumbo-ID: 2ee482f0-b16d-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2ee482f0-b16d-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 14:08:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 378C9ADC2; Thu, 18 Jun 2020 14:08:27 +0000 (UTC) Subject: Re: [PATCH for-4.14 2/8] x86/hvm: don't force vCPU 0 for IRQ 0 when using fixed destination mode To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-3-roger.pau@citrix.com> <20200618134841.GQ735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 16:08:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200618134841.GQ735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 15:48, Roger Pau Monné wrote: > On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote: >> On 12.06.2020 17:56, Roger Pau Monne wrote: >>> When the IO APIC pin mapped to the ISA IRQ 0 has been configured to >>> use fixed delivery mode do not forcefully route interrupts to vCPU 0, >>> as the OS might have setup those interrupts to be injected to a >>> different vCPU, and injecting to vCPU 0 can cause the OS to miss such >>> interrupts or errors to happen due to unexpected vectors being >>> injected on vCPU 0. >>> >>> In order to fix remove such handling altogether for fixed destination >>> mode pins and just inject them according to the data setup in the >>> IO-APIC entry. >>> >>> Signed-off-by: Roger Pau Monné >> >> Technically >> Reviewed-by: Jan Beulich >> >> I wonder though why this was done in the first place - it very much >> feels like a workaround for certain guest behavior, and hence >> getting rid of it may mean a certain risk of regressions. Not a >> very good point in time to make risky changes ... > > We can defer to after the release I guess, but I will still ask for > the changes to be backported. That's fine, albeit if we decide to delay it until 4.15 was branched, then I think we want to also wait longer than usual until it would hit the stable trees. Unfortunately c8e79412c001's description is of no help to understand what or why "time jumps" may result from delivering the interrupt as requested. > What we currently do is broken, up to the point that FreeBSD cannot > use the PIT because it will likely route the interrupt to a vCPU != 0 > in fixed mode, and then it will just get stuck because the vector is > delivered to vCPU 0 where it's not even configured. All understood. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:18:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:18:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvMu-0008Ar-2a; Thu, 18 Jun 2020 14:18:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvMs-0008Am-Eg for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:18:14 +0000 X-Inumbo-ID: 8af14df2-b16e-11ea-bb8b-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8af14df2-b16e-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 14:18:12 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: DNPYnxDFCiZ1iRya1W0zExaA/pzdco9IwLZmalLqQYQzRgX4QlOjh0tv28dFJgMB8dzSYjosTS nqR9wljgaTtXWgTvpyWTwpv98ZG78WU4fvYeqS/9wlT8ErcT40tv6F9gG1qgp1Sp1Mk0wTVyeN H6sA+jCU8b/j14mcfdjasKaP1o7oaKX0HY88Rzx07VIHQvcVWAkj/xxM36aZqGHqZimuXdW3uo UWKqY+I+SyiuxQ+QIgvBkm1Nng2vBkLZh/Hxe/vKeLTwbN+hbiivZOMYefz68krIMe2n//sZrt 0LQ= X-SBRS: 2.7 X-MesageID: 20603131 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.73,526,1583211600"; d="scan'208";a="20603131" Date: Thu, 18 Jun 2020 16:18:05 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 2/8] x86/hvm: don't force vCPU 0 for IRQ 0 when using fixed destination mode Message-ID: <20200618141805.GR735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-3-roger.pau@citrix.com> <20200618134841.GQ735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 04:08:28PM +0200, Jan Beulich wrote: > On 18.06.2020 15:48, Roger Pau Monné wrote: > > On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote: > >> On 12.06.2020 17:56, Roger Pau Monne wrote: > >>> When the IO APIC pin mapped to the ISA IRQ 0 has been configured to > >>> use fixed delivery mode do not forcefully route interrupts to vCPU 0, > >>> as the OS might have setup those interrupts to be injected to a > >>> different vCPU, and injecting to vCPU 0 can cause the OS to miss such > >>> interrupts or errors to happen due to unexpected vectors being > >>> injected on vCPU 0. > >>> > >>> In order to fix remove such handling altogether for fixed destination > >>> mode pins and just inject them according to the data setup in the > >>> IO-APIC entry. > >>> > >>> Signed-off-by: Roger Pau Monné > >> > >> Technically > >> Reviewed-by: Jan Beulich > >> > >> I wonder though why this was done in the first place - it very much > >> feels like a workaround for certain guest behavior, and hence > >> getting rid of it may mean a certain risk of regressions. Not a > >> very good point in time to make risky changes ... > > > > We can defer to after the release I guess, but I will still ask for > > the changes to be backported. > > That's fine, albeit if we decide to delay it until 4.15 was branched, > then I think we want to also wait longer than usual until it would hit > the stable trees. Unfortunately c8e79412c001's description is of no > help to understand what or why "time jumps" may result from delivering > the interrupt as requested. Yes, I've also looked at the original commit and have no idea what it was actually trying to fix, and why delivering to vCPU 0 fixed it. FWIW, I tried delivering to a different vCPU and it seems to work fine. Note that other timers (ie: RTC or HPET) are not tied to vCPU 0, so it must have been something related to the PIT? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:26:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:26:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvUY-0000Zo-Sq; Thu, 18 Jun 2020 14:26:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvUX-0000Zj-2C for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:26:09 +0000 X-Inumbo-ID: a651e484-b16f-11ea-baa3-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a651e484-b16f-11ea-baa3-12813bfff9fa; Thu, 18 Jun 2020 14:26:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 67436AC5E; Thu, 18 Jun 2020 14:26:06 +0000 (UTC) Subject: Re: [PATCH for-4.14 3/8] x86/hvm: fix ISA IRQ 0 handling when set as lowest priority mode in IO APIC To: Roger Pau Monne References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-4-roger.pau@citrix.com> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 16:26:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612155640.4101-4-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 17:56, Roger Pau Monne wrote: > --- a/xen/arch/x86/hvm/vioapic.c > +++ b/xen/arch/x86/hvm/vioapic.c > @@ -422,12 +422,13 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin) > case dest_LowestPrio: > { > #ifdef IRQ0_SPECIAL_ROUTING > - /* Force round-robin to pick VCPU 0 */ > - if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() ) > - { > - v = d->vcpu ? d->vcpu[0] : NULL; > - target = v ? vcpu_vlapic(v) : NULL; > - } > + struct vlapic *lapic0 = vcpu_vlapic(d->vcpu[0]); > + > + /* Force to pick vCPU 0 if part of the destination list */ > + if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() && > + vlapic_match_dest(lapic0, NULL, 0, dest, dest_mode) && > + vlapic_enabled(lapic0) ) The vlapic_enabled() part needs justification in the commit message (if it is to stay), the more that the other path that patch 2 touched doesn't have / gain it. I'm unconvinced this is a helpful check here (or anywhere when it's not current's LAPIC that gets probed), as its result may be stale right after probing. Having thought about this (including patch 2) some more, I also wonder whether, if no destination match was found, the IRQ0_SPECIAL_ROUTING hack should become to nevertheless deliver to CPU0. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:30:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:30:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvYH-0000ji-Cr; Thu, 18 Jun 2020 14:30:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvYG-0000jd-RA for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:30:00 +0000 X-Inumbo-ID: 305e2e94-b170-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 305e2e94-b170-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 14:30:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4C6E5AC5E; Thu, 18 Jun 2020 14:29:58 +0000 (UTC) Subject: Re: [PATCH for-4.14 2/8] x86/hvm: don't force vCPU 0 for IRQ 0 when using fixed destination mode To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-3-roger.pau@citrix.com> <20200618134841.GQ735@Air-de-Roger> <20200618141805.GR735@Air-de-Roger> From: Jan Beulich Message-ID: <69de3bdb-b521-798b-a727-fd8f20ee6294@suse.com> Date: Thu, 18 Jun 2020 16:29:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200618141805.GR735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 16:18, Roger Pau Monné wrote: > On Thu, Jun 18, 2020 at 04:08:28PM +0200, Jan Beulich wrote: >> On 18.06.2020 15:48, Roger Pau Monné wrote: >>> On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote: >>>> On 12.06.2020 17:56, Roger Pau Monne wrote: >>>>> When the IO APIC pin mapped to the ISA IRQ 0 has been configured to >>>>> use fixed delivery mode do not forcefully route interrupts to vCPU 0, >>>>> as the OS might have setup those interrupts to be injected to a >>>>> different vCPU, and injecting to vCPU 0 can cause the OS to miss such >>>>> interrupts or errors to happen due to unexpected vectors being >>>>> injected on vCPU 0. >>>>> >>>>> In order to fix remove such handling altogether for fixed destination >>>>> mode pins and just inject them according to the data setup in the >>>>> IO-APIC entry. >>>>> >>>>> Signed-off-by: Roger Pau Monné >>>> >>>> Technically >>>> Reviewed-by: Jan Beulich >>>> >>>> I wonder though why this was done in the first place - it very much >>>> feels like a workaround for certain guest behavior, and hence >>>> getting rid of it may mean a certain risk of regressions. Not a >>>> very good point in time to make risky changes ... >>> >>> We can defer to after the release I guess, but I will still ask for >>> the changes to be backported. >> >> That's fine, albeit if we decide to delay it until 4.15 was branched, >> then I think we want to also wait longer than usual until it would hit >> the stable trees. Unfortunately c8e79412c001's description is of no >> help to understand what or why "time jumps" may result from delivering >> the interrupt as requested. > > Yes, I've also looked at the original commit and have no idea what it > was actually trying to fix, and why delivering to vCPU 0 fixed it. > FWIW, I tried delivering to a different vCPU and it seems to work > fine. Right, I too was thinking that delivering to a "stable" CPU might be all that's needed. In patch 3 this may then call for latching that CPU, and preferring it over what vlapic_lowest_prio() produces. > Note that other timers (ie: RTC or HPET) are not tied to vCPU 0, so it > must have been something related to the PIT? Likely, but it may easily have been that an issue was papered over by this change. Then we won't even know whether that underlying issue still exists. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:38:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:38:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvg4-0001ZY-6C; Thu, 18 Jun 2020 14:38:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvg2-0001ZT-UG for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:38:02 +0000 X-Inumbo-ID: 4d4971f2-b171-11ea-baa7-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4d4971f2-b171-11ea-baa7-12813bfff9fa; Thu, 18 Jun 2020 14:37:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 36E52AC79; Thu, 18 Jun 2020 14:37:56 +0000 (UTC) Subject: Re: [PATCH for-4.14 4/8] x86/vpt: only try to resume timers belonging to enabled devices To: Roger Pau Monne References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-5-roger.pau@citrix.com> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 16:37:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612155640.4101-5-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 17:56, Roger Pau Monne wrote: > Check whether the emulated device is actually enabled before trying to > resume the associated timers. > > Thankfully all those structures are zeroed at initialization, and > since the devices are not enabled they are never populated, which > triggers the pt->vcpu check at the beginning of pt_resume forcing an > exit from the function. So really this is a benign transformation then, rather than fixing anything? If that's correct understanding of mine ... > While there limit the scope of i and make it unsigned. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:39:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:39:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvhB-0001g3-Lw; Thu, 18 Jun 2020 14:39:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvhA-0001fw-Ik for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:39:12 +0000 X-Inumbo-ID: 77941c1e-b171-11ea-bca7-bc764e2007e4 Received: from mga02.intel.com (unknown [134.134.136.20]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 77941c1e-b171-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 14:39:08 +0000 (UTC) IronPort-SDR: ZJwvxblUqawLx2cdqGGRGknGPinoslPeX/q0yZv33wL6t14wMm9k0thO3vDRj/WpNtQpnmf+xa tixZaxYE2FQw== X-IronPort-AV: E=McAfee;i="6000,8403,9655"; a="130991527" X-IronPort-AV: E=Sophos;i="5.73,526,1583222400"; d="scan'208";a="130991527" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2020 07:39:08 -0700 IronPort-SDR: EEyENaOnzeDXI0wIjSv/8wWcfF+r6GXpel4M9d2UGnpC2ie0Pu4vU45v3uh4eROki0CNV1VdyM DgvBrYliamdw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,526,1583222400"; d="scan'208";a="277642948" Received: from unknown (HELO ubuntu.localdomain) ([10.255.79.91]) by orsmga006.jf.intel.com with ESMTP; 18 Jun 2020 07:39:06 -0700 From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v3 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Date: Thu, 18 Jun 2020 07:39:04 -0700 Message-Id: X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Jun Nakajima , Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" While forking VMs running a small RTOS system (Zephyr) a Xen crash has been observed due to a mm-lock order violation while copying the HVM CPU context from the parent. This issue has been identified to be due to hap_update_paging_modes first getting a lock on the gfn using get_gfn. This call also creates a shared entry in the fork's memory map for the cr3 gfn. The function later calls hap_update_cr3 while holding the paging_lock, which results in the lock-order violation in vmx_load_pdptrs when it tries to unshare the above entry when it grabs the page with the P2M_UNSHARE flag set. Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure the p2m is properly populated. Note that the lock order violation is avoided because before the paging_lock is taken a lookup is performed with P2M_ALLOC that forks the page, thus the second lookup in vmx_load_pdptrs succeeds without having to perform the fork. We keep P2M_ALLOC in vmx_load_pdptrs because there are code-paths leading up to it which don't take the paging_lock and that have no previous lookup. Currently no other code-path exists leading there with the paging_lock taken, thus no further adjustments are necessary. Signed-off-by: Tamas K Lengyel --- v3: expand commit message to explain why there is no lock-order violation --- xen/arch/x86/hvm/vmx/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index ab19d9424e..cc6d4ece22 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1325,7 +1325,7 @@ static void vmx_load_pdptrs(struct vcpu *v) if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) ) goto crash; - page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UNSHARE); + page = get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_ALLOC); if ( !page ) { /* Ideally you don't want to crash but rather go into a wait -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:48:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:48:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvpf-0002Xe-I3; Thu, 18 Jun 2020 14:47:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvpd-0002XZ-H1 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:47:57 +0000 X-Inumbo-ID: b2584c7a-b172-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b2584c7a-b172-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 14:47:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 5157AAC79; Thu, 18 Jun 2020 14:47:55 +0000 (UTC) Subject: Re: [PATCH for-4.14 5/8] x86/hvm: only translate ISA interrupts to GSIs in virtual timers To: Roger Pau Monne References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-6-roger.pau@citrix.com> From: Jan Beulich Message-ID: <2b7eb220-afb8-26e6-6406-70759cac9333@suse.com> Date: Thu, 18 Jun 2020 16:47:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612155640.4101-6-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 17:56, Roger Pau Monne wrote: > Only call hvm_isa_irq_to_gsi for ISA interrupts, interrupts > originating from an IO APIC pin already use a GSI and don't need to be > translated. > > I haven't observed any issues from this, but I think it's better to > use it correctly. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich However, ... > --- a/xen/arch/x86/hvm/vpt.c > +++ b/xen/arch/x86/hvm/vpt.c > @@ -86,7 +86,7 @@ static int pt_irq_vector(struct periodic_time *pt, enum hvm_intsrc src) > return pt->irq; > > isa_irq = pt->irq; > - gsi = hvm_isa_irq_to_gsi(isa_irq); > + gsi = pt->source == PTSRC_isa ? hvm_isa_irq_to_gsi(isa_irq) : pt->irq; ... would you mind taking the opportunity and moving this ... > if ( src == hvm_intsrc_pic ) > return (v->domain->arch.hvm.vpic[isa_irq >> 3].irq_base ... below here, perhaps even past the ASSERT() that follows? (I have to admit that I find the two kinds of "source" indicators - the "src" function parameter and "pt->source" confusing. Aren't they supposed to match up?) Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:49:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:49:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvrO-0002eh-Tu; Thu, 18 Jun 2020 14:49:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvrO-0002ec-1I for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:49:46 +0000 X-Inumbo-ID: f215a9c0-b172-11ea-b7bb-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f215a9c0-b172-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 14:49:44 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 1lG9TJmFS1lODm2VDf0ABMvMQetjr4PVK63loxZZimOCO5xbvlxv8afIpfmhwHdjoQtuxzUnx6 e/dwoWjSpGGT4hrU/1GwXrmsm5E0Z+LuJneqzAKgqGdopy+S5uPn6RqVL/JldYVHY+hZqH5l2z rPQTJ8WqCrGQL/ExarenG5KCKT1w0pxrNuKcSkUJgVaXlP8lYw0S4QfeoI7VjQQHG5O8In7aGS uGGPBCjt8vrXo/BdUXZicKf9m7SSPsQSwTckdBNUZPENGBdz9NP5iq/iHPAm1Pl0Hvc1l8Dr5K TY4= X-SBRS: 2.7 X-MesageID: 20680575 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,526,1589256000"; d="scan'208";a="20680575" Date: Thu, 18 Jun 2020 16:49:36 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 2/8] x86/hvm: don't force vCPU 0 for IRQ 0 when using fixed destination mode Message-ID: <20200618144936.GS735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-3-roger.pau@citrix.com> <20200618134841.GQ735@Air-de-Roger> <20200618141805.GR735@Air-de-Roger> <69de3bdb-b521-798b-a727-fd8f20ee6294@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <69de3bdb-b521-798b-a727-fd8f20ee6294@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 04:29:59PM +0200, Jan Beulich wrote: > On 18.06.2020 16:18, Roger Pau Monné wrote: > > On Thu, Jun 18, 2020 at 04:08:28PM +0200, Jan Beulich wrote: > >> On 18.06.2020 15:48, Roger Pau Monné wrote: > >>> On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote: > >>>> On 12.06.2020 17:56, Roger Pau Monne wrote: > >>>>> When the IO APIC pin mapped to the ISA IRQ 0 has been configured to > >>>>> use fixed delivery mode do not forcefully route interrupts to vCPU 0, > >>>>> as the OS might have setup those interrupts to be injected to a > >>>>> different vCPU, and injecting to vCPU 0 can cause the OS to miss such > >>>>> interrupts or errors to happen due to unexpected vectors being > >>>>> injected on vCPU 0. > >>>>> > >>>>> In order to fix remove such handling altogether for fixed destination > >>>>> mode pins and just inject them according to the data setup in the > >>>>> IO-APIC entry. > >>>>> > >>>>> Signed-off-by: Roger Pau Monné > >>>> > >>>> Technically > >>>> Reviewed-by: Jan Beulich > >>>> > >>>> I wonder though why this was done in the first place - it very much > >>>> feels like a workaround for certain guest behavior, and hence > >>>> getting rid of it may mean a certain risk of regressions. Not a > >>>> very good point in time to make risky changes ... > >>> > >>> We can defer to after the release I guess, but I will still ask for > >>> the changes to be backported. > >> > >> That's fine, albeit if we decide to delay it until 4.15 was branched, > >> then I think we want to also wait longer than usual until it would hit > >> the stable trees. Unfortunately c8e79412c001's description is of no > >> help to understand what or why "time jumps" may result from delivering > >> the interrupt as requested. > > > > Yes, I've also looked at the original commit and have no idea what it > > was actually trying to fix, and why delivering to vCPU 0 fixed it. > > FWIW, I tried delivering to a different vCPU and it seems to work > > fine. > > Right, I too was thinking that delivering to a "stable" CPU might be > all that's needed. In patch 3 this may then call for latching that > CPU, and preferring it over what vlapic_lowest_prio() produces. Yes, I also considered that route for the lowest priority mode (which is dealt with in the next patch), but for fixed mode we need to delivered to the listed vCPUs, there's no trick we can play here IMO. Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:50:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:50:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvsD-0003Mm-6z; Thu, 18 Jun 2020 14:50:37 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvsB-0003Mb-Uc for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:50:35 +0000 X-Inumbo-ID: 0e752a5a-b173-11ea-baa8-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0e752a5a-b173-11ea-baa8-12813bfff9fa; Thu, 18 Jun 2020 14:50:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Yu0MZi/6HCce73HsqklCSPKPrUWmB2tMw9OQRD7ZdtY=; b=tKfNQ4/0vjC7yAW4yVe1NNKdUM 4gvBJKp9rjto+ZTz9MLL4HqVD7snSwdi0UK2UOrMszz2YI5y1mtpIOmu+0FY3R9mHwrV4CibI+hTJ 7lw/Ymk6pSO6TjlIkpZt7roJKlzhPQMGH3ECXWELR1F/GB+Qxb36rQSAOvHlKpJihtSc=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvs4-0002No-S2; Thu, 18 Jun 2020 14:50:28 +0000 Received: from 54-240-197-234.amazon.com ([54.240.197.234] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlvs4-0004O7-Kq; Thu, 18 Jun 2020 14:50:28 +0000 Subject: Re: UEFI support in ARM DomUs To: Oleksandr Andrushchenko , Stefano Stabellini References: From: Julien Grall Message-ID: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> Date: Thu, 18 Jun 2020 15:50:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18/06/2020 06:22, Oleksandr Andrushchenko wrote: > > On 6/4/20 6:31 PM, Stefano Stabellini wrote: >> On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote: >>> On 6/4/20 4:57 AM, Peng Fan wrote: >>>> Grall ; >>>>> Nataliya Korovkina >>>>> Subject: UEFI support in ARM DomUs >>>> We have made U-Boot run inside XEN DomU, but just only PV console part, >>>> not implement other frontend drivers currently. Would this help for your >>>> case if enable EFI in U-Boot? >>> Well, we have a working PV block implementation on top of that on iMX8 >>> >>> platform, mostly ported from mini-os. Currently we are finalizing the work >>> >>> and cleaning up (it's going to take a week or so hopefully). Then, we we'll post >>> >>> it on our public github. We are also thinking about upstreaming the work, but it may >>> >>> take quite some time if the whole idea fits u-boot's view on such an extension at all. >> Yes please to both of you! :-) >> >> In the meantime, while we wait for those changes to go upstream in >> uboot, could you please post a branch on github and a link on this email >> thread? > > It took a bit more time than we expected, but here we go [1]: > > this is in form of a pull-request as we would love to hear from the > > community and it is easier to discuss the code (please leave comments there) > > 1. There is code originating from MiniOS and work done by Peng, so we > > would like to ask the respective copyright owners to raise their hands and Not everyone are closely watching xen-devel. So if you want to find out who are the copyright owners, then your best solution is to go through the git log and CC the authors. > > let us *fix inappropriate licensing* if any. > > 2. Please note, the series has a HACK to move the RAM base as it is expected by > > our test platform (iMX8), so others will need to remove or modify that. > > 3. There is a limitation already noted by Peng that we do not have serial output > > until MMU is setup, so we have introduced xen_early_printk helper which always > > works, so you can use that for early stage debugging. > > 4. Minimal memory size supported is ~129M because of dtb placement by Xen tools Hmmm... Why? What's wrong with booting a guest with just 64MB? > > 5. We use -D__XEN__ to access some of the hidden defines we need such as > > GUEST_RAM0_BASE and the friends as there is no other way but manually defining the > > same which is not cute. I have replied to this in the pull request. But I want to bring the conversation here to have a wider discussion. For a first, __XEN__ should really only be defined by the hypervisor and not used by the guest. This is used to gate non-stable ABI (such as the tools) and anything behind it hasn't been vetted to work in other build configuration that the one used by Xen. In general, we expect the guest to discover everything for the device-tree because the memory layout is not stable (we want to be able to reshuffle as we add more features). I know that EDK2/Tianocore can be built once and work on every Xen configuration. It would be ideal that U-boot follow the same. If it is really not possible, then we should explore a path that is preventing to define __XEN__. How much does U-boot expect to know about the memory layout? Does it require to know all the memory banks? Or would it be sufficient for it to know the start address of the first bank and the minimum of RAM? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:55:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:55:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvwh-0003Yl-Pt; Thu, 18 Jun 2020 14:55:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvwg-0003Yg-Gz for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:55:14 +0000 X-Inumbo-ID: b69e75ec-b173-11ea-bb8b-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b69e75ec-b173-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 14:55:13 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: gsYsOBanvS8i2IL8WXSDyyvzQ9ABEf3u8LFFqIncaBkGc30Z4ys3EiQh7YkXY/ZIO0csGLjCRk IN0sjbdyUkwadk88QzZq1Ql4KasXlmTWRX0JkcyhnuHUBTmg4bXWEYrGBvO+xyhzuXYbL/CMl3 men/r1AmUH0OqZGCS4i93SK1i2wxvHyIUJswuy/wOZVo4R9W0Kjdb3ZQdMyd9psrrzRnTqWHRw L17jIf24CXi3GejgykGi6MJGNPjrqlucIXABafZ/hbOgRSDQQaWAVr5B7E2HQwE/BGxkFEHZFK E4o= X-SBRS: 2.7 X-MesageID: 20681234 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20681234" Date: Thu, 18 Jun 2020 16:55:06 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 3/8] x86/hvm: fix ISA IRQ 0 handling when set as lowest priority mode in IO APIC Message-ID: <20200618145506.GT735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-4-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 04:26:08PM +0200, Jan Beulich wrote: > On 12.06.2020 17:56, Roger Pau Monne wrote: > > --- a/xen/arch/x86/hvm/vioapic.c > > +++ b/xen/arch/x86/hvm/vioapic.c > > @@ -422,12 +422,13 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin) > > case dest_LowestPrio: > > { > > #ifdef IRQ0_SPECIAL_ROUTING > > - /* Force round-robin to pick VCPU 0 */ > > - if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() ) > > - { > > - v = d->vcpu ? d->vcpu[0] : NULL; > > - target = v ? vcpu_vlapic(v) : NULL; > > - } > > + struct vlapic *lapic0 = vcpu_vlapic(d->vcpu[0]); > > + > > + /* Force to pick vCPU 0 if part of the destination list */ > > + if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() && > > + vlapic_match_dest(lapic0, NULL, 0, dest, dest_mode) && > > + vlapic_enabled(lapic0) ) > > The vlapic_enabled() part needs justification in the commit message > (if it is to stay), the more that the other path that patch 2 touched > doesn't have / gain it. I'm unconvinced this is a helpful check here > (or anywhere when it's not current's LAPIC that gets probed), as its > result may be stale right after probing. This is modeled after what vlapic_lowest_prio does, which includes the vlapic_enabled check. I assumed this was done to prevent injecting to disabled lapics if possible. I agree it's stale by the point it gets acted upon, but anyone playing with enabling/disabling a lapic part of a destination list shouldn't expect anything sensible to happen IMO. > Having thought about this (including patch 2) some more, I also wonder > whether, if no destination match was found, the IRQ0_SPECIAL_ROUTING > hack should become to nevertheless deliver to CPU0. Hm, that wouldn't match what real hardware would do, but would indeed match what old Xen would do for IRQ 0. TBH I would be more comfortable with attempting to remove this behaviour, and hence don't inject to any vCPU if none match the list. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 14:56:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 14:56:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvxk-0003d8-3Q; Thu, 18 Jun 2020 14:56:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlvxi-0003d2-TJ for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 14:56:18 +0000 X-Inumbo-ID: dd4588f2-b173-11ea-baa8-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dd4588f2-b173-11ea-baa8-12813bfff9fa; Thu, 18 Jun 2020 14:56:18 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: RrLxoiyedqh8lE2oi+FyysfBzYSjYD/jI5T7A8N1IHFW0tCCAxkEAJ9kWGUYR4898bA4eJX0MS BlGOUoKFy9PObVxDadkrna4XO+T8R85vmgYDP7VS2sRXz5CIepuvA6PAcO6sTL65nkhY0eHitn Tf+pYxsPURNgxJO7bgM6f6q5hdSeMZb6xD4NjP16TcrbgLLJSg+eQusEybIaIEuDe8ntSZIM8O 0ySClCj5xVKNbvE3jESrw9RGCdCnqcDc2/HEJxOWKgSVN85U1h3ILR57rOzJhtp76eCE4Qk5K+ E64= X-SBRS: 2.7 X-MesageID: 20681338 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20681338" Date: Thu, 18 Jun 2020 16:56:10 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 4/8] x86/vpt: only try to resume timers belonging to enabled devices Message-ID: <20200618145610.GU735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-5-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 04:37:57PM +0200, Jan Beulich wrote: > On 12.06.2020 17:56, Roger Pau Monne wrote: > > Check whether the emulated device is actually enabled before trying to > > resume the associated timers. > > > > Thankfully all those structures are zeroed at initialization, and > > since the devices are not enabled they are never populated, which > > triggers the pt->vcpu check at the beginning of pt_resume forcing an > > exit from the function. > > So really this is a benign transformation then, rather than fixing > anything? If that's correct understanding of mine ... Yes, that's my understanding also. > > While there limit the scope of i and make it unsigned. > > > > Signed-off-by: Roger Pau Monné > > Reviewed-by: Jan Beulich Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:00:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:00:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlw1a-0004Tz-K1; Thu, 18 Jun 2020 15:00:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlw1Y-0004Tu-HS for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:00:16 +0000 X-Inumbo-ID: 6a836ef0-b174-11ea-baa9-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6a836ef0-b174-11ea-baa9-12813bfff9fa; Thu, 18 Jun 2020 15:00:15 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 27153A3194; Thu, 18 Jun 2020 17:00:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 12D77A316A; Thu, 18 Jun 2020 17:00:13 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id bfVy9dPkYP3D; Thu, 18 Jun 2020 17:00:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 43A61A3194; Thu, 18 Jun 2020 17:00:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LZCmIC5x5a7w; Thu, 18 Jun 2020 17:00:12 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id EA78FA316B; Thu, 18 Jun 2020 17:00:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id CE4462171F; Thu, 18 Jun 2020 16:59:41 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id mM1H3X7hY_WV; Thu, 18 Jun 2020 16:59:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 1533F21831; Thu, 18 Jun 2020 16:59:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r-yPd1aNJKGz; Thu, 18 Jun 2020 16:59:35 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id E65F621821; Thu, 18 Jun 2020 16:59:35 +0200 (CEST) Date: Thu, 18 Jun 2020 16:59:35 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Andrew Cooper Message-ID: <162473163.9748222.1592492375721.JavaMail.zimbra@cert.pl> In-Reply-To: <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <1555629278.8787770.1592333278517.JavaMail.zimbra@cert.pl> <6da28899-25ae-7355-fa0a-70fac44f597e@citrix.com> Subject: Re: [PATCH v1 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: UCWaOVhIz1IuIRy8y9FmAQDSGi2Khw== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 17 cze 2020 o 18:19, Andrew Cooper andrew.cooper3@citrix.com napisa= =C5=82(a): > On 17/06/2020 04:02, Tamas K Lengyel wrote: >> On Tue, Jun 16, 2020 at 2:17 PM Andrew Cooper wrote: >>> On 16/06/2020 19:47, Micha=C5=82 Leszczy=C5=84ski wrote: >>>> ----- 16 cze 2020 o 20:17, Andrew Cooper andrew.cooper3@citrix.com nap= isa=C5=82(a): >>>> >>>>> Are there any restrictions on EPT being enabled in the first place? = I'm >>>>> not aware of any, and in principle we could use this functionality fo= r >>>>> PV guests as well (using the CPL filter). Therefore, I think it woul= d >>>>> be helpful to not tie the functionality to HVM guests, even if that i= s >>>>> the only option enabled to start with. >>>> I think at the moment it's not required to have EPT. This patch series= doesn't >>>> use any translation feature flags, so the output address is always a m= achine >>>> physical address, regardless of context. I will check if it could be e= asily >>>> used with PV. >>> If its trivial to add PV support then please do. If its not, then don'= t >>> feel obliged, but please do at least consider how PV support might look >>> in the eventual feature. >>> >>> (Generally speaking, considering "how would I make this work in other >>> modes where it is possible" leads to a better design.) >>> >>>>> The buffer mapping and creation logic is fairly problematic. Instead= of >>>>> fighting with another opencoded example, take a look at the IOREQ >>>>> server's use of "acquire resource" which is a mapping interface which >>>>> supports allocating memory on behalf of the guest, outside of the gue= st >>>>> memory, for use by control tools. >>>>> >>>>> I think what this wants is a bit somewhere in domain_create to indica= te >>>>> that external tracing is used for this domain (and allocate whatever >>>>> structures/buffers are necessary), acquire resource to map the buffer= s >>>>> themselves, and a domctl for any necessary runtime controls. >>>>> >>>> I will check this out, this sounds like a good option as it would remo= ve lots of >>>> complexity from the existing ipt_enable domctl. >>> Xen has traditionally opted for a "and turn this extra thing on >>> dynamically" model, but this has caused no end of security issues and >>> broken corner cases. >>> >>> You can see this still existing in the difference between >>> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being >>> required to chose the number of vcpus for the domain) and we're making >>> good progress undoing this particular wart (before 4.13, it was >>> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by >>> issuing other hypercalls between these two). >>> >>> There is a lot of settings which should be immutable for the lifetime o= f >>> the domain, and external monitoring looks like another one of these. >>> Specifying it at createdomain time allows for far better runtime >>> behaviour (you are no longer in a situation where the first time you tr= y >>> to turn tracing on, you end up with -ENOMEM because another VM booted i= n >>> the meantime and used the remaining memory), and it makes for rather >>> more simple code in Xen itself (at runtime, you can rely on it having >>> been set up properly, because a failure setting up will have killed the >>> domain already). >> I'm not in favor of this being a flag that gets set during domain >> creation time. It could certainly be the case that some users would >> want this being on from the start till the end but in other cases you >> may want to enable it intermittently only for some time in-between >> particular events. If it's an on/off flag during domain creation you >> pretty much force that choice on the users and while the overhead of >> PT is better than say MTF it's certainly not nothing. In case there is >> an OOM situation enabling IPT dynamically the user can always just >> pause the VM and wait till memory becomes available. >=20 > There is nothing wrong with having "turn tracing on/off at runtime" > hypercalls.=C2=A0 It is specifically what I suggested two posts up in thi= s > thread, but it should be limited to the TraceEn bit in RTIT_CTL. >=20 > What isn't ok is trying to allocate the buffers, write the TOPA, etc on > first-enable or first-map, because the runtime complexity of logic like > this large, and far too easy to get wrong in security relevant ways. >=20 > The domain create flag would mean "I wish to use tracing with this > domain", and not "I want tracing enabled from the getgo". >=20 I'm trying to implement this suggestion right now. I've already switched to= acquire_resource and now I want to make buffers statically allocated on do= main creation. I think it would be reasonable to add an option like "vmtrace_ipt_size" in = xl.cfg. By default it would be 0 (meaning "disabled"), and when it's set to= non-zero value by the user, the IPT buffers of given size will be allocate= d for each vCPU upon domain creation. Could you give some hints about how to correctly add a new option in xl.cfg= in a way that it's accessible on the hypervisor part? This part related to= configuration parsing/processing is what I don't understand yet. >>>>> What semantics do you want for the buffer becoming full? Given that >>>>> debugging/tracing is the goal, I presume "pause vcpu on full" is the >>>>> preferred behaviour, rather than drop packets on full? >>>>> >>>> Right now this is a ring-style buffer and when it would become full it= would >>>> simply wrap and override the old data. >>> How does the consumer spot that the data has wrapped? What happens if >>> data starts getting logged, but noone is listening? What happens if th= e >>> consumer exits/crashes/etc and stops listening as a consequence? >>> >>> It's fine to simply state what will happen, and possibly even "don't do >>> that then", but the corner cases do at least need thinking about. >> AFAIU the current use-case is predominantly to be used in conjunction >> with VMI events where you want to be able to see the trace leading up >> to a particular vmexit. So in the case when the buffer is wrapped >> in-between events and data is lost that's not really of concern. >=20 > That's all fine.=C2=A0 I imagine the output here is voluminous, and needs > help being cut down as much as possible. >=20 > On a tangent, I presume you'd like to include VM-fork eventually, which > ought to include copying the trace buffer on fork? >=20 > ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:01:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:01:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlw2S-0004Yk-2v; Thu, 18 Jun 2020 15:01:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlw2Q-0004YE-Qg for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:01:10 +0000 X-Inumbo-ID: 8a4d15b0-b174-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8a4d15b0-b174-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 15:01:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=e6BiZ54Z/n2Xyd58G5HpcMng3Zpnf3qzBo6kBoUe6DA=; b=So8fSUxSIPgxfEZzeTzZRprjX0 swsEuswzmnwC9sQQfP1VXxw33nXWWrqohqdahzLtbF85e07wYTEGOzrYIfUVqc1ADkgVJFk1X2YnG q5cWkvDtExmavy3h0bmi2xi81y2TFWicZxkQoYkztydp0I5mcG82fUugISNEgyTtEYwM=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlw2I-0002cu-Os; Thu, 18 Jun 2020 15:01:02 +0000 Received: from 54-240-197-234.amazon.com ([54.240.197.234] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlw2I-00053t-AO; Thu, 18 Jun 2020 15:01:02 +0000 Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Stefano Stabellini , Julien Grall , "committers@xenproject.org" References: <20200613184132.11880-1-julien@xen.org> <35c8373f-b691-d95e-17de-021c72faf216@xen.org> From: Julien Grall Message-ID: Date: Thu, 18 Jun 2020 16:00:58 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , Paul Durrant , Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" (+ Committers) On 18/06/2020 02:34, Stefano Stabellini wrote: > On Tue, 16 Jun 2020, Julien Grall wrote: >> On Tue, 16 Jun 2020 at 21:57, Stefano Stabellini wrote: >>> >>> On Tue, 16 Jun 2020, Julien Grall wrote: >>>> On 16/06/2020 02:00, Stefano Stabellini wrote: >>>>> On Sat, 13 Jun 2020, Julien Grall wrote: >>>>>> From: Julien Grall >>>>>> >>>>>> The documentation of pvcalls suggests there is padding for 32-bit x86 >>>>>> at the end of most the structure. However, they are not described in >>>>>> in the public header. >>>>>> >>>>>> Because of that all the structures would be 32-bit aligned and not >>>>>> 64-bit aligned for 32-bit x86. >>>>>> >>>>>> For all the other architectures supported (Arm and 64-bit x86), the >>>>>> structure are aligned to 64-bit because they contain uint64_t field. >>>>>> Therefore all the structures contain implicit padding. >>>>>> >>>>>> The paddings are now corrected for 32-bit x86 and written explicitly for >>>>>> all the architectures. >>>>>> >>>>>> While the structure size between 32-bit and 64-bit x86 is different, it >>>>>> shouldn't cause any incompatibility between a 32-bit and 64-bit >>>>>> frontend/backend because the commands are always 56 bits and the padding >>>>>> are at the end of the structure. >>>>>> >>>>>> As an aside, the padding sadly cannot be mandated to be 0 as they are >>>>>> already present. So it is not going to be possible to use the padding >>>>>> for extending a command in the future. >>>>>> >>>>>> Signed-off-by: Julien Grall >>>>>> >>>>>> --- >>>>>> Changes in v3: >>>>>> - Use __i386__ rather than CONFIG_X86_32 >>>>>> >>>>>> Changes in v2: >>>>>> - It is not possible to use the same padding for 32-bit x86 and >>>>>> all the other supported architectures. >>>>>> --- >>>>>> docs/misc/pvcalls.pandoc | 18 ++++++++++-------- >>>>>> xen/include/public/io/pvcalls.h | 14 ++++++++++++++ >>>>>> 2 files changed, 24 insertions(+), 8 deletions(-) >>>>>> >>>>>> diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc >>>>>> index 665dad556c39..caa71b36d78b 100644 >>>>>> --- a/docs/misc/pvcalls.pandoc >>>>>> +++ b/docs/misc/pvcalls.pandoc >>>>>> @@ -246,9 +246,9 @@ The format is defined as follows: >>>>>> uint32_t domain; >>>>>> uint32_t type; >>>>>> uint32_t protocol; >>>>>> - #ifdef CONFIG_X86_32 >>>>>> + #ifndef __i386__ >>>>>> uint8_t pad[4]; >>>>>> - #endif >>>>>> + #endif >>>>> >>>>> >>>>> Hi Julien, >>>>> >>>>> Thank you for doing this, and sorry for having missed v2 of this patch, I >>>>> should have replied earlier. >>>>> >>>>> The intention of the #ifdef blocks like: >>>>> >>>>> #ifdef CONFIG_X86_32 >>>>> uint8_t pad[4]; >>>>> #endif >>>>> >>>>> in pvcalls.pandoc was to make sure that these structs would be 64bit >>>>> aligned on x86_32 too. >>>>> >>>>> I realize that the public header doesn't match, but the spec is the >>>>> "master copy". >>>> >>>> So far, the public headers are the defacto official ABI. So did you mark the >>>> pvcall header as just a reference? >>> >>> No, there is no document that says that the canonical copy of the >>> interface is pvcalls.pandoc. However, it was clearly spelled out from >>> the start on xen-devel (see below.) >>> In fact, if you notice, this is the >>> first document under docs/misc that goes into this level of details in >>> describing a new PV protocol. Also note the title of the document which >>> is "PV Calls Protocol version 1". >> >> While I understand this may have been the original intention, you >> can't expect a developer to go through the archive to check whether >> he/she should trust the header of the document. >> >>> >>> >>> In reply to Jan: >>>> A public header can't be "fixed" if it may already be in use by >>>> anyone. We can only do as Andrew and you suggest (mandate textual >>>> descriptions to be "the ABI") when we do so for _new_ interfaces from >>>> the very beginning, making clear that the public header (if any) >>>> exists just for reference. >>> >>> What if somebody took the specification of the interface from >>> pvcalls.pandoc and wrote their own headers and code? It is definitely >>> possible. >> >> As it is possible for someone to have picked the headers from Xen as >> in the past public/ has always been the authority. > > We never had documents under docs/ before specifying the interfaces > before pvcalls. It is not written anywhere that the headers under > public/ are the authoritative interfaces either, it is just that it was > the only thing available before. If you are new to the project you might > go to docs/ first. > > >>> At the time, it was clarified that the purpose of writing such >>> a detailed specification document was that the document was the >>> specification :-) >> >> At the risk of being pedantic, if it is not written in xen.git it >> doesn't exist ;). >> >> Anyway, no matter the decision you take here, you are going to >> potentially break one set of the users. >> >> I am leaning towards the header as authoritative because this has >> always been the case in the past and nothing in xen.git says >> otherwise. However I am not a user of pvcalls, so I don't really have >> any big incentive to go either way. > > Yeah, we are risking breaking one set of users either way :-/ > In reality, we are using pvcalls on arm64 in a new project (but it is > still very green). I am not aware of anybody using pvcalls on x86 > (especially x86_32). > > I would prefer to honor the pvcalls.pandoc specification because that is > what it was meant to be, and also leads to a better protocol > specification. As Jan and you disagree on the approach, I would like to get more input. To summarize the discussion, the document for PV calls and the public headers don't match when describing the padding. There is a disagreement on which of the two are the authority and therefore which one to fix. Does anyone else have a preference on the approach? > > >> For the future, I would highly suggest writing down the support >> decision in xen.git. This would avoid such debate on what is the >> authority... > > Yes that's the way to go > -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:03:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:03:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlw4e-0004iL-Fk; Thu, 18 Jun 2020 15:03:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlw4c-0004iF-Rc for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:03:26 +0000 X-Inumbo-ID: dc3a009a-b174-11ea-b7bb-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dc3a009a-b174-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 15:03:26 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: jS/4hb9kl5ri8lQqwPOY7uZJ+Usuv0maMMeS9Nuu7NbMxC3rSnlyRLRwUdYdwocD/VQfgDZVx/ VtkvXLKH1CbD8DoEBJDGLcaHy8Vj22WAn76u8vYJ2Xxy4RGCNuHv80o4Dj3p2HUHydRfn/ESlm bOHotUYkUIn0lqzFqU6ES8+d410omnaUJOZc8sN5XcGAMfZsz93JJfYwOZnSKB2GO/UZXMl0Ek Z03fe4avhfDMW8j7+7oKWJqD50U8ZGytEAZsMUyk3FDinLs601Lq13VC8DTl5c3kIQGONmmgyd UAo= X-SBRS: 2.7 X-MesageID: 20682596 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20682596" Date: Thu, 18 Jun 2020 17:03:18 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 5/8] x86/hvm: only translate ISA interrupts to GSIs in virtual timers Message-ID: <20200618150318.GV735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-6-roger.pau@citrix.com> <2b7eb220-afb8-26e6-6406-70759cac9333@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2b7eb220-afb8-26e6-6406-70759cac9333@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 04:47:57PM +0200, Jan Beulich wrote: > On 12.06.2020 17:56, Roger Pau Monne wrote: > > Only call hvm_isa_irq_to_gsi for ISA interrupts, interrupts > > originating from an IO APIC pin already use a GSI and don't need to be > > translated. > > > > I haven't observed any issues from this, but I think it's better to > > use it correctly. > > > > Signed-off-by: Roger Pau Monné > > Reviewed-by: Jan Beulich > > However, ... > > > --- a/xen/arch/x86/hvm/vpt.c > > +++ b/xen/arch/x86/hvm/vpt.c > > @@ -86,7 +86,7 @@ static int pt_irq_vector(struct periodic_time *pt, enum hvm_intsrc src) > > return pt->irq; > > > > isa_irq = pt->irq; > > - gsi = hvm_isa_irq_to_gsi(isa_irq); > > + gsi = pt->source == PTSRC_isa ? hvm_isa_irq_to_gsi(isa_irq) : pt->irq; > > ... would you mind taking the opportunity and moving this ... > > > if ( src == hvm_intsrc_pic ) > > return (v->domain->arch.hvm.vpic[isa_irq >> 3].irq_base > > ... below here, perhaps even past the ASSERT() that follows? > > (I have to admit that I find the two kinds of "source" indicators > - the "src" function parameter and "pt->source" confusing. Aren't > they supposed to match up?) They are supposed to match when the injected interrupt is the timer one, if there's a highest priority interrupt that gets injected instead of the timer one they don't match. AFAICT the function it's trying to get the vector that would match the timer using the 'src' interrupt source. TBH I think this is way more complex than needed, but I don't plan to deal with it right now. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:12:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:12:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwDE-0005aV-DF; Thu, 18 Jun 2020 15:12:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwDD-0005aQ-0z for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:12:19 +0000 X-Inumbo-ID: 19157840-b176-11ea-baac-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 19157840-b176-11ea-baac-12813bfff9fa; Thu, 18 Jun 2020 15:12:17 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 26202ADF7; Thu, 18 Jun 2020 15:12:16 +0000 (UTC) Subject: Re: [PATCH for-4.14 6/8] x86/vpt: fix injection to remote vCPU To: Roger Pau Monne References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-7-roger.pau@citrix.com> From: Jan Beulich Message-ID: <57b6f9fd-4cbc-abc9-09e3-6493eba6c377@suse.com> Date: Thu, 18 Jun 2020 17:12:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612155640.4101-7-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 17:56, Roger Pau Monne wrote: > vpt timers are usually added to the per-vCPU list of the vCPU where > they get setup, but depending on the timer source type that vCPU might > be different than the one where the interrupt vector gets injected. > > For example the PIT timer use a PIC or IO-APIC pin in order to select > the destination vCPU and vector, which might not match the vCPU they > are configured from. > > If such a situation happens pt_intr_post won't be called, and thus the > vpt will be left in a limbo where the next interrupt won't be > scheduled. Fix this by generalizing the special handling done to > IO-APIC level interrupts to be applied always when the destination > vCPU of the injected vector is different from the vCPU where the vpt > belongs to (ie: usually the one it's been configured from). > > A further improvement as noted in a comment added to the code might be > to move the vpt so it's handled by the same vCPU where the vector gets > injected. > > Signed-off-by: Roger Pau Monné > --- > xen/arch/x86/hvm/vpt.c | 80 +++++++++++++++++++++--------------------- > 1 file changed, 40 insertions(+), 40 deletions(-) > > diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c > index 6a975fc668..52ad5b90a7 100644 > --- a/xen/arch/x86/hvm/vpt.c > +++ b/xen/arch/x86/hvm/vpt.c > @@ -358,59 +358,59 @@ int pt_update_irq(struct vcpu *v) > * interrupt delivery case. Otherwise return -1 to do nothing. > */ > vlapic_set_irq(vcpu_vlapic(v), irq, 0); > - pt_vector = irq; > - break; > + return irq; > > case PTSRC_isa: > hvm_isa_irq_deassert(v->domain, irq); > if ( platform_legacy_irq(irq) && vlapic_accept_pic_intr(v) && > v->domain->arch.hvm.vpic[irq >> 3].int_output ) > - hvm_isa_irq_assert(v->domain, irq, NULL); > + pt_vector = hvm_isa_irq_assert(v->domain, irq, NULL); > else > - { > pt_vector = hvm_isa_irq_assert(v->domain, irq, vioapic_get_vector); > - /* > - * hvm_isa_irq_assert may not set the corresponding bit in vIRR > - * when mask field of IOAPIC RTE is set. Check it again. > - */ For one, the transformation done here looks to call for folding both calls to hvm_isa_irq_assert() into one. I'm not, however, convinced recording the function's return value is useful in the case where it wasn't recorded before. The change is benign right now because hvm_isa_irq_assert() will return -1 when its last argument is NULL, but the question is whether the code here should start depending on such behavior. And then, according to this comment (which doesn't get retained in any form or shape) ... > - if ( pt_vector < 0 || !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) > - pt_vector = -1; > - } > + > + if ( pt_vector < 0 ) > + return pt_vector; > + > break; > > case PTSRC_ioapic: > pt_vector = hvm_ioapic_assert(v->domain, irq, level); > - if ( pt_vector < 0 || !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) > - { > - pt_vector = -1; > - if ( level ) > + if ( pt_vector < 0 ) > + return pt_vector; > + > + break; > + } > + > + ASSERT(pt_vector >= 0); > + if ( !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) > + { > + time_cb *cb = NULL; > + void *cb_priv; > + > + /* > + * Vector has been injected to a different vCPU, call pt_irq_fired and > + * execute the callback, since the destination vCPU(s) won't call > + * pt_intr_post for it. ... this isn't the only reason to come here. Beyond what the comment says there is the hvm_domain_use_pirq() check in assert_gsi() which would similarly result in the IRR bit not observed set here. At the very least these cases want mentioning; I have to admit that I'm not entirely clear yet whether your handling is correct for both, or whether the information needs to be propagated into here. Also instead of ASSERT(pt_vector >= 0) would you pull the respective if() out of the switch(), to also cover the case of a fall through without hitting any of the explicitly handled cases, resulting in pt_vector left at its initial value of -1? > + * TODO: move this vpt to one of the vCPUs where the vector gets > + * injected. > + */ > + spin_lock(&v->arch.hvm.tm_lock); > + /* Make sure the timer is still on the list. */ > + list_for_each_entry ( pt, &v->arch.hvm.tm_list, list ) > + if ( pt == earliest_pt ) > { > - /* > - * Level interrupts are always asserted because the pin assert > - * count is incremented regardless of whether the pin is masked > - * or the vector latched in IRR, so also execute the callback > - * associated with the timer. > - */ > - time_cb *cb = NULL; > - void *cb_priv; > - > - spin_lock(&v->arch.hvm.tm_lock); > - /* Make sure the timer is still on the list. */ > - list_for_each_entry ( pt, &v->arch.hvm.tm_list, list ) > - if ( pt == earliest_pt ) > - { > - pt_irq_fired(v, pt); > - cb = pt->cb; > - cb_priv = pt->priv; > - break; > - } > - spin_unlock(&v->arch.hvm.tm_lock); > - > - if ( cb != NULL ) > - cb(v, cb_priv); > + pt_irq_fired(v, pt); > + cb = pt->cb; > + cb_priv = pt->priv; > + break; > } > - } > - break; > + spin_unlock(&v->arch.hvm.tm_lock); > + > + if ( cb != NULL ) > + cb(v, cb_priv); > + > + pt_vector = -1; > } > > return pt_vector; To further reduce indentation (and seeing the significant code churn that happens here anyway), could you consider inverting the surrounding if() to if ( vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) return pt_vector; ? Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:16:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:16:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwHF-0005ji-UX; Thu, 18 Jun 2020 15:16:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwHE-0005jd-QB for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:16:28 +0000 X-Inumbo-ID: ae5430b8-b176-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ae5430b8-b176-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 15:16:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8E85CADE3; Thu, 18 Jun 2020 15:16:26 +0000 (UTC) Subject: Re: [PATCH for-4.14 2/8] x86/hvm: don't force vCPU 0 for IRQ 0 when using fixed destination mode To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-3-roger.pau@citrix.com> <20200618134841.GQ735@Air-de-Roger> <20200618141805.GR735@Air-de-Roger> <69de3bdb-b521-798b-a727-fd8f20ee6294@suse.com> <20200618144936.GS735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 17:16:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200618144936.GS735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 16:49, Roger Pau Monné wrote: > On Thu, Jun 18, 2020 at 04:29:59PM +0200, Jan Beulich wrote: >> On 18.06.2020 16:18, Roger Pau Monné wrote: >>> On Thu, Jun 18, 2020 at 04:08:28PM +0200, Jan Beulich wrote: >>>> On 18.06.2020 15:48, Roger Pau Monné wrote: >>>>> On Thu, Jun 18, 2020 at 03:43:00PM +0200, Jan Beulich wrote: >>>>>> On 12.06.2020 17:56, Roger Pau Monne wrote: >>>>>>> When the IO APIC pin mapped to the ISA IRQ 0 has been configured to >>>>>>> use fixed delivery mode do not forcefully route interrupts to vCPU 0, >>>>>>> as the OS might have setup those interrupts to be injected to a >>>>>>> different vCPU, and injecting to vCPU 0 can cause the OS to miss such >>>>>>> interrupts or errors to happen due to unexpected vectors being >>>>>>> injected on vCPU 0. >>>>>>> >>>>>>> In order to fix remove such handling altogether for fixed destination >>>>>>> mode pins and just inject them according to the data setup in the >>>>>>> IO-APIC entry. >>>>>>> >>>>>>> Signed-off-by: Roger Pau Monné >>>>>> >>>>>> Technically >>>>>> Reviewed-by: Jan Beulich >>>>>> >>>>>> I wonder though why this was done in the first place - it very much >>>>>> feels like a workaround for certain guest behavior, and hence >>>>>> getting rid of it may mean a certain risk of regressions. Not a >>>>>> very good point in time to make risky changes ... >>>>> >>>>> We can defer to after the release I guess, but I will still ask for >>>>> the changes to be backported. >>>> >>>> That's fine, albeit if we decide to delay it until 4.15 was branched, >>>> then I think we want to also wait longer than usual until it would hit >>>> the stable trees. Unfortunately c8e79412c001's description is of no >>>> help to understand what or why "time jumps" may result from delivering >>>> the interrupt as requested. >>> >>> Yes, I've also looked at the original commit and have no idea what it >>> was actually trying to fix, and why delivering to vCPU 0 fixed it. >>> FWIW, I tried delivering to a different vCPU and it seems to work >>> fine. >> >> Right, I too was thinking that delivering to a "stable" CPU might be >> all that's needed. In patch 3 this may then call for latching that >> CPU, and preferring it over what vlapic_lowest_prio() produces. > > Yes, I also considered that route for the lowest priority mode (which > is dealt with in the next patch), but for fixed mode we need to > delivered to the listed vCPUs, there's no trick we can play here > IMO. The set may still be empty, in which case the lowest-prio consideration (of falling back to CPU0) may still apply here as well. But of course there's nothing to latch here, as fixed mode means multi-cast if more than one destination matches. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:17:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:17:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwId-0005pz-9L; Thu, 18 Jun 2020 15:17:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwIc-0005pu-N4 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:17:54 +0000 X-Inumbo-ID: e1c72ac2-b176-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e1c72ac2-b176-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 15:17:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2FLD38ENoAnOrLYIFvwSzGEuWsSJR2OlVzUCD6ih7/o=; b=VJUBZiZpRYsOqZgyMpESDHH+Gf hxK0cypzCxtek8qcs0szrzQeDIjE7jb6BURJzO3LiZNVYZbz5BA3Y280JdPAIBpfYqfY1EZH34aj0 e8AbGv6NO3THdoqy+2U3v4YFEqTXDcucIRoj0aZpIHCSYMcX8MntTbFH76oxpaMH+jAw=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwIZ-0002wH-Vd; Thu, 18 Jun 2020 15:17:51 +0000 Received: from 54-240-197-234.amazon.com ([54.240.197.234] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlwIZ-0005sa-OS; Thu, 18 Jun 2020 15:17:51 +0000 Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: Volodymyr Babchuk , =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> <78910b5c27a3711726d53e931feb075c5cc4a64c.camel@suse.com> <87tuz92i6y.fsf@epam.com> From: Julien Grall Message-ID: <8b87612e-52e3-8f75-27a9-557ed9e7991f@xen.org> Date: Thu, 18 Jun 2020 16:17:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <87tuz92i6y.fsf@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18/06/2020 03:58, Volodymyr Babchuk wrote: > > Hi Jürgen, > > Jürgen Groß writes: > >> On 13.06.20 00:27, Volodymyr Babchuk wrote: >>> On Fri, 2020-06-12 at 17:29 +0200, Dario Faggioli wrote: >>>> On Fri, 2020-06-12 at 14:41 +0200, Jürgen Groß wrote: >>>>> On 12.06.20 14:29, Julien Grall wrote: >>>>>> On 12/06/2020 05:57, Jürgen Groß wrote: >>>>>>> On 12.06.20 02:22, Volodymyr Babchuk wrote: >>>>>>>> @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct >>>>>>>> sched_unit *u) >>>>>>>> break; >>>>>>>> } >>>>>>>> + spin_lock_irqsave(&sched_stat_lock, flags); >>>>>>>> + sched_stat_irq_time += irq; >>>>>>>> + sched_stat_hyp_time += hyp; >>>>>>>> + spin_unlock_irqrestore(&sched_stat_lock, flags); >>>>>>> >>>>>>> Please don't use a lock. Just use add_sized() instead which will >>>>>>> add >>>>>>> atomically. >>>>>> >>>>>> If we expect sched_get_time_correction to be called concurrently >>>>>> then we >>>>>> would need to introduce atomic64_t or a spin lock. >>>>> >>>>> Or we could use percpu variables and add the cpu values up when >>>>> fetching the values. >>>>> >>>> Yes, either percpu or atomic looks much better than locking, to me, for >>>> this. >>> >>> Looks like we going to have atomic64_t after all. So, I'll prefer to to >>> use atomics there. >> >> Performance would be better using percpu variables, as those would avoid >> the cacheline moved between cpus a lot. > > I see. But don't we need locking in this case? I can see scenario, when > one pCPU updates own counters while another pCPU is reading them. > > IIRC, ARMv8 guarantees that 64 bit read of aligned data would be > consistent. "Consistent" in the sense that, for example, we would not > see lower 32 bits of the new value and upper 32 bits of the old value. That's right. Although this would be valid so long you use {read, write}_atomic(). > > I can't say for sure about ARMv7 and about x86. ARMv7 with LPAE support will guarantee 64-bit atomicity when using strd/ldrd as long as the alignment is correct. LPAE is mandatory when supporting HYP mode, so you can safely assume this will work. 64-bit on x86 is also guaranteed to be atomic when using write_atomic(). -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:20:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:20:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwLQ-0006dl-Rf; Thu, 18 Jun 2020 15:20:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwLP-0006de-8B for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:20:47 +0000 X-Inumbo-ID: 47c98eaa-b177-11ea-baac-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 47c98eaa-b177-11ea-baac-12813bfff9fa; Thu, 18 Jun 2020 15:20:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0CF10AAC7; Thu, 18 Jun 2020 15:20:43 +0000 (UTC) Subject: Re: [PATCH for-4.14 3/8] x86/hvm: fix ISA IRQ 0 handling when set as lowest priority mode in IO APIC To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-4-roger.pau@citrix.com> <20200618145506.GT735@Air-de-Roger> From: Jan Beulich Message-ID: <8d3c5b8f-ccf2-cc11-cf74-11e21e80f1a1@suse.com> Date: Thu, 18 Jun 2020 17:20:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200618145506.GT735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 16:55, Roger Pau Monné wrote: > On Thu, Jun 18, 2020 at 04:26:08PM +0200, Jan Beulich wrote: >> On 12.06.2020 17:56, Roger Pau Monne wrote: >>> --- a/xen/arch/x86/hvm/vioapic.c >>> +++ b/xen/arch/x86/hvm/vioapic.c >>> @@ -422,12 +422,13 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, unsigned int pin) >>> case dest_LowestPrio: >>> { >>> #ifdef IRQ0_SPECIAL_ROUTING >>> - /* Force round-robin to pick VCPU 0 */ >>> - if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() ) >>> - { >>> - v = d->vcpu ? d->vcpu[0] : NULL; >>> - target = v ? vcpu_vlapic(v) : NULL; >>> - } >>> + struct vlapic *lapic0 = vcpu_vlapic(d->vcpu[0]); >>> + >>> + /* Force to pick vCPU 0 if part of the destination list */ >>> + if ( (irq == hvm_isa_irq_to_gsi(0)) && pit_channel0_enabled() && >>> + vlapic_match_dest(lapic0, NULL, 0, dest, dest_mode) && >>> + vlapic_enabled(lapic0) ) >> >> The vlapic_enabled() part needs justification in the commit message >> (if it is to stay), the more that the other path that patch 2 touched >> doesn't have / gain it. I'm unconvinced this is a helpful check here >> (or anywhere when it's not current's LAPIC that gets probed), as its >> result may be stale right after probing. > > This is modeled after what vlapic_lowest_prio does, which includes the > vlapic_enabled check. I assumed this was done to prevent injecting to > disabled lapics if possible. All understood, but it wants justifying like that in the description, and the discrepancy to the fixed dest mode wants taking care of (either again verbally, or by a code change). > I agree it's stale by the point it gets acted upon, but anyone playing > with enabling/disabling a lapic part of a destination list shouldn't > expect anything sensible to happen IMO. Well, yes, agreed. >> Having thought about this (including patch 2) some more, I also wonder >> whether, if no destination match was found, the IRQ0_SPECIAL_ROUTING >> hack should become to nevertheless deliver to CPU0. > > Hm, that wouldn't match what real hardware would do, but would indeed > match what old Xen would do for IRQ 0. TBH I would be more comfortable > with attempting to remove this behaviour, and hence don't inject to > any vCPU if none match the list. I agree from an abstract perspective. But at the same time I fear hard to understand / debug regressions. I'd be curious to know what others think ... Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:23:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:23:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwNo-0006lg-8v; Thu, 18 Jun 2020 15:23:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwNm-0006lb-IQ for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:23:14 +0000 X-Inumbo-ID: a012be38-b177-11ea-baac-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a012be38-b177-11ea-baac-12813bfff9fa; Thu, 18 Jun 2020 15:23:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D95ABAAC7; Thu, 18 Jun 2020 15:23:11 +0000 (UTC) Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: Julien Grall , Volodymyr Babchuk References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <88eac035-8769-24f7-45e6-11a1c4739ccb@xen.org> <78910b5c27a3711726d53e931feb075c5cc4a64c.camel@suse.com> <87tuz92i6y.fsf@epam.com> <8b87612e-52e3-8f75-27a9-557ed9e7991f@xen.org> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 17:23:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <8b87612e-52e3-8f75-27a9-557ed9e7991f@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 17:17, Julien Grall wrote: > > > On 18/06/2020 03:58, Volodymyr Babchuk wrote: >> >> Hi Jürgen, >> >> Jürgen Groß writes: >> >>> On 13.06.20 00:27, Volodymyr Babchuk wrote: >>>> On Fri, 2020-06-12 at 17:29 +0200, Dario Faggioli wrote: >>>>> On Fri, 2020-06-12 at 14:41 +0200, Jürgen Groß wrote: >>>>>> On 12.06.20 14:29, Julien Grall wrote: >>>>>>> On 12/06/2020 05:57, Jürgen Groß wrote: >>>>>>>> On 12.06.20 02:22, Volodymyr Babchuk wrote: >>>>>>>>> @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct >>>>>>>>> sched_unit *u) >>>>>>>>> break; >>>>>>>>> } >>>>>>>>> + spin_lock_irqsave(&sched_stat_lock, flags); >>>>>>>>> + sched_stat_irq_time += irq; >>>>>>>>> + sched_stat_hyp_time += hyp; >>>>>>>>> + spin_unlock_irqrestore(&sched_stat_lock, flags); >>>>>>>> >>>>>>>> Please don't use a lock. Just use add_sized() instead which will >>>>>>>> add >>>>>>>> atomically. >>>>>>> >>>>>>> If we expect sched_get_time_correction to be called concurrently >>>>>>> then we >>>>>>> would need to introduce atomic64_t or a spin lock. >>>>>> >>>>>> Or we could use percpu variables and add the cpu values up when >>>>>> fetching the values. >>>>>> >>>>> Yes, either percpu or atomic looks much better than locking, to me, for >>>>> this. >>>> >>>> Looks like we going to have atomic64_t after all. So, I'll prefer to to >>>> use atomics there. >>> >>> Performance would be better using percpu variables, as those would avoid >>> the cacheline moved between cpus a lot. >> >> I see. But don't we need locking in this case? I can see scenario, when >> one pCPU updates own counters while another pCPU is reading them. >> >> IIRC, ARMv8 guarantees that 64 bit read of aligned data would be >> consistent. "Consistent" in the sense that, for example, we would not >> see lower 32 bits of the new value and upper 32 bits of the old value. > > That's right. Although this would be valid so long you use {read, > write}_atomic(). > >> >> I can't say for sure about ARMv7 and about x86. > ARMv7 with LPAE support will guarantee 64-bit atomicity when using > strd/ldrd as long as the alignment is correct. LPAE is mandatory when > supporting HYP mode, so you can safely assume this will work. > > 64-bit on x86 is also guaranteed to be atomic when using write_atomic(). ... and when again the data is suitably aligned, or at the very least (for WB RAM) doesn't cross certain boundaries. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:25:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:25:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwQM-0006sy-MN; Thu, 18 Jun 2020 15:25:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwQL-0006st-D4 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:25:53 +0000 X-Inumbo-ID: fe55a99c-b177-11ea-bca7-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fe55a99c-b177-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 15:25:52 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1EE53A2B94; Thu, 18 Jun 2020 17:25:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1B4C3A31AA; Thu, 18 Jun 2020 17:25:50 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id EjR4qVGw6oj3; Thu, 18 Jun 2020 17:25:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2AB65A2B94; Thu, 18 Jun 2020 17:25:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wVPw0jx0Ks3T; Thu, 18 Jun 2020 17:25:49 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id C367DA31AA; Thu, 18 Jun 2020 17:25:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id ADF2A212EF; Thu, 18 Jun 2020 17:25:18 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HYrLZivkmFdb; Thu, 18 Jun 2020 17:25:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id B47A221372; Thu, 18 Jun 2020 17:25:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Sa2-Jgj5VzY1; Thu, 18 Jun 2020 17:25:12 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 93BA4212EA; Thu, 18 Jun 2020 17:25:12 +0200 (CEST) Date: Thu, 18 Jun 2020 17:25:12 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <1599209169.9756264.1592493912556.JavaMail.zimbra@cert.pl> In-Reply-To: <20200616172352.GT735@Air-de-Roger> References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: eRoIf7uTtyuVM23EiI951sycntVcMw== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 16 cze 2020 o 19:23, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Tue, Jun 16, 2020 at 05:22:06PM +0200, Micha=C5=82 Leszczy=C5=84ski wr= ote: >> Provide an interface for privileged domains to manage >> external IPT monitoring. >>=20 >> Signed-off-by: Michal Leszczynski >=20 > Thanks for the patch! I have some questions below which require your > input. >=20 >> --- >> xen/arch/x86/hvm/hvm.c | 170 ++++++++++++++++++++++++++++++++ >> xen/include/public/hvm/hvm_op.h | 27 +++++ >> 2 files changed, 197 insertions(+) >>=20 >> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c >> index 5bb47583b3..9292caebe0 100644 >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -4949,6 +4949,172 @@ static int compat_altp2m_op( >> return rc; >> } >> =20 >> +static int do_vmtrace_op( >> + XEN_GUEST_HANDLE_PARAM(void) arg) >=20 > No need for the newline, this can fit on a single line. >=20 >> +{ >> + struct xen_hvm_vmtrace_op a; >> + struct domain *d =3D NULL; >=20 > I don't think you need to init d to NULL (at least by looking at the > current code below). >=20 >> + int rc =3D -EFAULT; >=20 > No need to init rc. >=20 >> + int i; >=20 > unsigned since it's used as a loop counter. >=20 >> + struct vcpu *v; >> + void* buf; >=20 > Nit: '*' should be prepended to the variable name. >=20 >> + uint32_t buf_size; >=20 > size_t >=20 >> + uint32_t buf_order; >=20 > Order is generally fine using unsigned int, no need to use a > specifically sized type. >=20 >> + uint64_t buf_mfn; >=20 > Could this use the mfn type? >=20 >> + struct page_info *pg; >> + >> + if ( !hvm_ipt_supported() ) >> + return -EOPNOTSUPP; >> + >> + if ( copy_from_guest(&a, arg, 1) ) >> + return -EFAULT; >> + >> + if ( a.version !=3D HVMOP_VMTRACE_INTERFACE_VERSION ) >> + return -EINVAL; >> + >> + switch ( a.cmd ) >> + { >> + case HVMOP_vmtrace_ipt_enable: >> + case HVMOP_vmtrace_ipt_disable: >> + case HVMOP_vmtrace_ipt_get_buf: >> + case HVMOP_vmtrace_ipt_get_offset: >> + break; >> + >> + default: >> + return -EOPNOTSUPP; >> + } >> + >> + d =3D rcu_lock_domain_by_any_id(a.domain); >> + >> + if ( d =3D=3D NULL ) >> + return -ESRCH; >> + >> + if ( !is_hvm_domain(d) ) >> + { >> + rc =3D -EOPNOTSUPP; >> + goto out; >> + } >> + >> + domain_pause(d); >> + >> + if ( a.vcpu >=3D d->max_vcpus ) >> + { >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + v =3D d->vcpu[a.vcpu]; >> + >> + if ( a.cmd =3D=3D HVMOP_vmtrace_ipt_enable ) >=20 > Please use a switch here, you might even consider re-using the switch > from above and moving the domain checks before actually checking the > command field, so that you don't need to perform two switches against > a.cmd. >=20 >> + { >> + if ( v->arch.hvm.vmx.ipt_state ) { >=20 > Coding style, brace should be on newline (there are more below which > I'm not going to comment on). >=20 >> + // already enabled >=20 > Comments should use /* ... */, there multiple instances of this below > which I'm not going to comment on, please check CODING_STYLE. >=20 > Also, the interface looks racy, I think you are missing a lock to > protect v->arch.hvm.vmx.ipt_state from being freed under your feet if > you issue concurrent calls to the interface. >=20 >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + if ( a.size < PAGE_SIZE || a.size > 1000000 * PAGE_SIZE ) { >=20 > You can use GB(4) which is easier to read. Should the size also be a > multiple of a PAGE_SIZE? >=20 >> + // we don't accept trace buffer size smaller than single pa= ge >> + // and the upper bound is defined as 4GB in the specificati= on >> + rc =3D -EINVAL; >> + goto out; >> +=09} >=20 > Stray tab. >=20 >> + >> + buf_order =3D get_order_from_bytes(a.size); >> + >> + if ( (a.size >> PAGE_SHIFT) !=3D (1 << buf_order) ) { >=20 > Oh here is the check. I think you can move this with the checks above > by doing a.size & ~PAGE_MASK. >=20 >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + buf =3D page_to_virt(alloc_domheap_pages(d, buf_order, >> MEMF_no_refcount)); >=20 > What if alloc_domheap_pages return NULL? >=20 > Since I think you only what the linear address of the page to zero it > I would suggest using clear_domain_page. >=20 >> + buf_size =3D a.size; >> + >> + if ( !buf ) { >> + rc =3D -EFAULT; >> + goto out; >> + } >> + >> + memset(buf, 0, buf_size); >> + >> + for ( i =3D 0; i < (buf_size >> PAGE_SHIFT); i++ ) { >> + share_xen_page_with_privileged_guests(virt_to_page(buf) + i= , >> SHARE_ro); >=20 > This line (and some more below) exceeds 80 characters, please split > it. >=20 >> + } >> + >> + v->arch.hvm.vmx.ipt_state =3D xmalloc(struct ipt_state); >=20 > You should check that xmalloc has succeeds before trying to access > ipt_state. >=20 >> + v->arch.hvm.vmx.ipt_state->output_base =3D virt_to_mfn(buf) << >> PAGE_SHIFT; >> + v->arch.hvm.vmx.ipt_state->output_mask =3D buf_size - 1; >> + v->arch.hvm.vmx.ipt_state->status =3D 0; >> + v->arch.hvm.vmx.ipt_state->ctl =3D RTIT_CTL_TRACEEN | RTIT_CTL_= OS | >> RTIT_CTL_USR | RTIT_CTL_BRANCH_EN; >=20 > Shouldn't the user be able to select what tracing should be enabled? >=20 >> + } >> + else if ( a.cmd =3D=3D HVMOP_vmtrace_ipt_disable ) >> + { >> + if ( !v->arch.hvm.vmx.ipt_state ) { >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + buf_mfn =3D v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIF= T; >> + buf_size =3D ( v->arch.hvm.vmx.ipt_state->output_mask + 1 ) & >> 0xFFFFFFFFUL; >> + >> + for ( i =3D 0; i < (buf_size >> PAGE_SHIFT); i++ ) >> + { >> + if ( (mfn_to_page(_mfn(buf_mfn + i))->count_info & PGC_coun= t_mask) >> !=3D 1 ) >> + { >> + rc =3D -EBUSY; >> + goto out; >> + } >> + } >> + >> + xfree(v->arch.hvm.vmx.ipt_state); >> +=09v->arch.hvm.vmx.ipt_state =3D NULL; >> + >> + for ( i =3D 0; i < (buf_size >> PAGE_SHIFT); i++ ) >> + { >> + pg =3D mfn_to_page(_mfn(buf_mfn + i)); >> + put_page_alloc_ref(pg); >> + if ( !test_and_clear_bit(_PGC_xen_heap, &pg->count_info) ) >> + ASSERT_UNREACHABLE(); >> + pg->u.inuse.type_info =3D 0; >> + page_set_owner(pg, NULL); >> + free_domheap_page(pg); >=20 > Hm, this seems fairly dangerous, what guarantees that the caller is > not going to map the buffer while you are trying to tear it down? >=20 > You perform a check before freeing ipt_state, but between the check > and the actual tearing down the domain might have setup mappings to > them. >=20 > I wonder, could you expand a bit on why trace buffers are allocated > from domheap memory by Xen? >=20 > There are a couple of options here, maybe the caller could provide > it's own buffer, then Xen would take an extra reference to those pages > and setup them to be used as buffers. >=20 > Another alternative would be to use domhep memory but not let the > caller map it directly, and instead introduce a hypercall to copy > from the internal Xen buffer into a user-provided one. >=20 > How much memory is used on average by those buffers? That would help > decide a model that would best fit the usage. >=20 >> + } >> + } >> + else if ( a.cmd =3D=3D HVMOP_vmtrace_ipt_get_buf ) >> + { >> + if ( !v->arch.hvm.vmx.ipt_state ) { >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + a.mfn =3D v->arch.hvm.vmx.ipt_state->output_base >> PAGE_SHIFT; >=20 > This will not work for translated domains, ie: a PVH or HVM domain > won't be able to use this interface since it has no way to request the > mapping of a specific mfn into it's physmap. I think we need to take > this into account when deciding how the interface should be, so that > we don't corner ourselves with a PV only interface. >=20 >> + a.size =3D (v->arch.hvm.vmx.ipt_state->output_mask + 1) & 0xFFF= FFFFFUL; >=20 > You can truncate it easier by casting to uint32_t I think. >=20 > Or even better, you could put output_mask in a union like: >=20 > union { > uint64_t raw; > struct { > uint32_t size; >=09uint32_t offset; > } > } >=20 > Then you can avoid the shifting and the castings. >=20 >> + } >> + else if ( a.cmd =3D=3D HVMOP_vmtrace_ipt_get_offset ) >> + { >> + if ( !v->arch.hvm.vmx.ipt_state ) { >> + rc =3D -EINVAL; >> + goto out; >> + } >> + >> + a.offset =3D v->arch.hvm.vmx.ipt_state->output_mask >> 32; >> + } >> + >> + rc =3D -EFAULT; >> + if ( __copy_to_guest(arg, &a, 1) ) >> + goto out; >> + rc =3D 0; >> + >> + out: >> + smp_wmb(); >=20 > Why do you need a barrier here? >=20 >> + domain_unpause(d); >> + rcu_unlock_domain(d); >> + >> + return rc; >> +} >> + >> +DEFINE_XEN_GUEST_HANDLE(compat_hvm_vmtrace_op_t); >> + >> static int hvmop_get_mem_type( >> XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg) >> { >> @@ -5101,6 +5267,10 @@ long do_hvm_op(unsigned long op, >> XEN_GUEST_HANDLE_PARAM(void) arg) >> rc =3D current->hcall_compat ? compat_altp2m_op(arg) : do_altp2= m_op(arg); >> break; >> =20 >> + case HVMOP_vmtrace: >> + rc =3D do_vmtrace_op(arg); >> + break; >> + >> default: >> { >> gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op); >> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hv= m_op.h >> index 870ec52060..3bbcd54c96 100644 >> --- a/xen/include/public/hvm/hvm_op.h >> +++ b/xen/include/public/hvm/hvm_op.h >> @@ -382,6 +382,33 @@ struct xen_hvm_altp2m_op { >> typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; >> DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); >> =20 >> +/* HVMOP_vmtrace: Perform VM tracing related operation */ >> +#define HVMOP_vmtrace 26 >> + >> +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 >> + >> +struct xen_hvm_vmtrace_op { >> + /* IN variable */ >> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ >> + uint32_t cmd; >> +/* Enable/disable external vmtrace for given domain */ >> +#define HVMOP_vmtrace_ipt_enable 1 >> +#define HVMOP_vmtrace_ipt_disable 2 >> +#define HVMOP_vmtrace_ipt_get_buf 3 >> +#define HVMOP_vmtrace_ipt_get_offset 4 >> + domid_t domain; >=20 > You are missing a padding field here AFAICT. Could you point out what is the purpose of this padding field and what shou= ld be the size in this case? It's pretty unclear to me. >=20 > Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:37:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:37:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwbc-0007mQ-Pd; Thu, 18 Jun 2020 15:37:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwbb-0007mL-Vd for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:37:32 +0000 X-Inumbo-ID: 9f0ec41c-b179-11ea-baae-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9f0ec41c-b179-11ea-baae-12813bfff9fa; Thu, 18 Jun 2020 15:37:31 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 70BC6B02C; Thu, 18 Jun 2020 15:37:29 +0000 (UTC) Subject: Re: [PATCH for-4.14 7/8] x86/hvm: add hardware domain support to hvm_isa_irq_to_gsi To: Roger Pau Monne References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-8-roger.pau@citrix.com> From: Jan Beulich Message-ID: <8c53946a-45de-cfd7-a5c3-49a8dc3112da@suse.com> Date: Thu, 18 Jun 2020 17:37:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612155640.4101-8-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, paul@xen.org, Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 17:56, Roger Pau Monne wrote: > The current function has the ISA IRQ 0 hardcoded to GSI 2 for HVM > domUs. Allow such function to also be used by the hardware domain by > taking into account the ACPI interrupt overwrites in order to get the Nit: overrides > --- a/xen/arch/x86/io_apic.c > +++ b/xen/arch/x86/io_apic.c > @@ -608,7 +608,7 @@ static int find_irq_entry(int apic, int pin, int type) > /* > * Find the pin to which IRQ[irq] (ISA) is connected > */ > -static int __init find_isa_irq_pin(int irq, int type) > +int io_apic_find_isa_irq_pin(int irq, int type) > { > int i; > > @@ -628,7 +628,7 @@ static int __init find_isa_irq_pin(int irq, int type) > return -1; > } > > -static int __init find_isa_irq_apic(int irq, int type) > +int io_apic_find_isa_irq_apic(int irq, int type) > { Since you touch these anyway, how about making their parameters "unsigned int"? Preferably with this Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:39:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:39:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwdP-0007tJ-5b; Thu, 18 Jun 2020 15:39:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwdO-0007tD-9K for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:39:22 +0000 X-Inumbo-ID: e0eab95e-b179-11ea-baae-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e0eab95e-b179-11ea-baae-12813bfff9fa; Thu, 18 Jun 2020 15:39:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C7785ADC8; Thu, 18 Jun 2020 15:39:19 +0000 (UTC) Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <1599209169.9756264.1592493912556.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: Date: Thu, 18 Jun 2020 17:39:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1599209169.9756264.1592493912556.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 17:25, Michał Leszczyński wrote: > ----- 16 cze 2020 o 19:23, Roger Pau Monné roger.pau@citrix.com napisał(a): >> On Tue, Jun 16, 2020 at 05:22:06PM +0200, Michał Leszczyński wrote: >>> --- a/xen/include/public/hvm/hvm_op.h >>> +++ b/xen/include/public/hvm/hvm_op.h >>> @@ -382,6 +382,33 @@ struct xen_hvm_altp2m_op { >>> typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; >>> DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); >>> >>> +/* HVMOP_vmtrace: Perform VM tracing related operation */ >>> +#define HVMOP_vmtrace 26 >>> + >>> +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 >>> + >>> +struct xen_hvm_vmtrace_op { >>> + /* IN variable */ >>> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ >>> + uint32_t cmd; >>> +/* Enable/disable external vmtrace for given domain */ >>> +#define HVMOP_vmtrace_ipt_enable 1 >>> +#define HVMOP_vmtrace_ipt_disable 2 >>> +#define HVMOP_vmtrace_ipt_get_buf 3 >>> +#define HVMOP_vmtrace_ipt_get_offset 4 >>> + domid_t domain; >> >> You are missing a padding field here AFAICT. > > > Could you point out what is the purpose of this padding field and what should be the size in this case? It's pretty unclear to me. In the public interface we aim at making all padding explicit. Also, as a general remark: Please trim your replies. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:40:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:40:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlweZ-0000CL-Kc; Thu, 18 Jun 2020 15:40:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlweX-0000CC-Mm for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:40:34 +0000 X-Inumbo-ID: 0b09d86e-b17a-11ea-bb8b-bc764e2007e4 Received: from mailout2.w1.samsung.com (unknown [210.118.77.12]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0b09d86e-b17a-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 15:40:32 +0000 (UTC) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20200618154031euoutp0223d5db3fa977ff7028764b632eeb944c~ZrZyWHt2t1314813148euoutp02P for ; Thu, 18 Jun 2020 15:40:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20200618154031euoutp0223d5db3fa977ff7028764b632eeb944c~ZrZyWHt2t1314813148euoutp02P DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1592494831; bh=KttQx/p+NwMYqZeVMMA/mdxDyA5P7MIUmLy+qtaSi8Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Lnh2Yj0aezq1/W1iVdiR1C+hQ088kbAiiypTZR6RAAW0KeRr3BAZhVJk2YZOgaEfa PGgD9rtrZmWJhLTX7/wA95tx46FWJd/x7/U34b3/+8auNofwwc9feeZtixKVj2RL5z Sd4b8hWriNDNEP5X20SLpWl/eBot0F6KyQWwR8GQ= Received: from eusmges2new.samsung.com (unknown [203.254.199.244]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20200618154031eucas1p1b2a5f82d438657ef26f917087674bb21~ZrZyFvvYn2141221412eucas1p1B; Thu, 18 Jun 2020 15:40:31 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges2new.samsung.com (EUCPMTA) with SMTP id 06.DE.60679.EEA8BEE5; Thu, 18 Jun 2020 16:40:30 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20200618154030eucas1p2f36e6ec52cea051fccedb1970f27bef9~ZrZxrWGHz2945829458eucas1p2s; Thu, 18 Jun 2020 15:40:30 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20200618154030eusmtrp100e1d8b9d488d275259cad6d740c1947~ZrZxqp9xw2230622306eusmtrp1D; Thu, 18 Jun 2020 15:40:30 +0000 (GMT) X-AuditID: cbfec7f4-0cbff7000001ed07-43-5eeb8aee6e4f Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id 9C.E9.07950.EEA8BEE5; Thu, 18 Jun 2020 16:40:30 +0100 (BST) Received: from AMDC2765.digital.local (unknown [106.120.51.73]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20200618154029eusmtip14b193a12662698378a07245764c6f5b6~ZrZxCgcmM0742307423eusmtip1V; Thu, 18 Jun 2020 15:40:29 +0000 (GMT) From: Marek Szyprowski To: dri-devel@lists.freedesktop.org, iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org Subject: [PATCH v6 24/36] xen: gntdev: fix common struct sg_table related issues Date: Thu, 18 Jun 2020 17:39:45 +0200 Message-Id: <20200618153956.29558-25-m.szyprowski@samsung.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200618153956.29558-1-m.szyprowski@samsung.com> X-Brightmail-Tracker: H4sIAAAAAAAAA0WSe0hTcRTH++3eu13NyW2a/rBQGCUVpan746JhJkGXHhQRRKHm0osz3bTN Z5SKNpP5SBNRRM1e+JrPrWWKppbNR77NfKam0sPMt6GJtXnV/vuc7znfcw6HgyO8RswC95UE 0VKJ0J/PNkQ171c7jv1STHsc/7DmSCa2N7PI8oxSjOxKl6PkX00KQvYuz7LJgqJGFpn7xonM GrAnl3rHWWTFRB9G9lRlscnidyMcsn5uEiN/q1NZLsaUMkcJqJqVXJR6tTKGUaPxWhaleh5J DW1MIFRqfx6g3s71olT1QBSbmp8aRKkkdSGgStUfUWqxwvIS97rhCW/a3zeElto6exqKytvm WYEtZmGz6mo0Cqh5CmCAQ0IAc3RWPfOIfADnP51RAEMdLwH4omsaZYJFADuepWPbjsUFOYdJ 5AGo1MSxdizZ6prNXmzCDipmFGw9mxJyAJsSjfRFCBGPwLTiws1WJsRlGN8fC/SMEgdhSsrP TeYSzrA8qQ9lxlnBorI6RM8GOr1VK8f0jSAxyIFPhtIQpug0fPh6hs2wCfyhVXMY3g9bUxNQ xhAD4Hh7MYcJEgDsic4ATJUTHG5f07lx3X6HYWmVLSOfgi9nhoFehoQx7J/Zo5cRHT7SpCOM zIVxsVuHtIaZ2pKdsfWd3VurUbB2ugxjLpQCYMJoCZIMrDL/D8sFoBCY08EysQ8ts5fQoTYy oVgWLPGx8QoQVwDdc7VuaJcqQdX6zQZA4IBvxP12ZdqDhwlDZOHiBgBxhG/KdW1r9eBxvYXh d2hpwA1psD8tawD7cJRvznV4+t2dR/gIg2g/mg6kpdtZFm5gEQXonnXRwtTcOeerXyQe7uGP LxzYvRoa4TB3zy3S3lLsd79TSXiV1gyJBPIxpWPMsqV4UTqpOOvabBbR7fUn7S7+VbDqMnJN ELZwaKnukudF6/p5T5+uZteVW7NVvkfdKgv25kcn396VLFLVkCreyc/2ti2Z4mxVkyCjtvxB c/7IeT4qEwntjiBSmfAftXBXYVgDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsVy+t/xu7rvul7HGWy/oGjRe+4kk8XGGetZ LS5Ob2Wx+L9tIrPFla/v2SxWrj7KZLFgv7XFnJtGFl+uPGSy2PT4GqvF5V1z2CzWHrnLbnHw wxNWi+9bJjM58HmsmbeG0WPvtwUsHtu/PWD1uN99nMlj85J6j9v/HjN7TL6xnNHj8IcrLB67 bzaweXx8eovFo2/LKkaP9Vuusnh83iQXwBulZ1OUX1qSqpCRX1xiqxRtaGGkZ2hpoWdkYqln aGwea2VkqqRvZ5OSmpNZllqkb5egl7Hx7EemglNiFe+37GZpYNwi1MXIySEhYCLx+VMrexcj F4eQwFJGiTXH57JBJGQkTk5rYIWwhSX+XOtigyj6xChx8MxXsCI2AUOJrrcQCRGBTkaJad0f wUYxC0xmlni2+joTSJWwQIDE7devwGwWAVWJiRPfMILYvAJ2Ehv7rrFArJCXWL3hADOIzQkU P328FWy1kICtxPMPbWwTGPkWMDKsYhRJLS3OTc8tNtIrTswtLs1L10vOz93ECIykbcd+btnB 2PUu+BCjAAejEg/vi5DXcUKsiWXFlbmHGCU4mJVEeJ3Ono4T4k1JrKxKLcqPLyrNSS0+xGgK dNREZinR5HxglOeVxBuaGppbWBqaG5sbm1koifN2CByMERJITyxJzU5NLUgtgulj4uCUamCc KDxra4rLva77UmUNcVsEP6gwWTbl3PuU9mLf850yE7/2PTy6SMr/RfvpQ9o2h//t+umRdDja XCx4qk1fyAKFG0sOn8qZdTDnv9D1mLNPPySp+Gxdb7n4XNKXU1eW8Rznen3ih1f3Mq6sXWas LVNvzeJ3t/7AYFOgG77jUS+rokTIh6PdkRdWKrEUZyQaajEXFScCAHXemBa6AgAA X-CMS-MailID: 20200618154030eucas1p2f36e6ec52cea051fccedb1970f27bef9 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200618154030eucas1p2f36e6ec52cea051fccedb1970f27bef9 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200618154030eucas1p2f36e6ec52cea051fccedb1970f27bef9 References: <20200618153956.29558-1-m.szyprowski@samsung.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Bartlomiej Zolnierkiewicz , David Airlie , Daniel Vetter , xen-devel@lists.xenproject.org, Boris Ostrovsky , Robin Murphy , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, Marek Szyprowski Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_map_sg(). struct sg_table is a common structure used for describing a non-contiguous memory buffer, used commonly in the DRM and graphics subsystems. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA mapped pages (nents entry). It turned out that it was a common mistake to misuse nents and orig_nents entries, calling DMA-mapping functions with a wrong number of entries or ignoring the number of mapped entries returned by the dma_map_sg() function. To avoid such issues, lets use a common dma-mapping wrappers operating directly on the struct sg_table objects and use scatterlist page iterators where possible. This, almost always, hides references to the nents and orig_nents entries, making the code robust, easier to follow and copy/paste safe. Signed-off-by: Marek Szyprowski Acked-by: Juergen Gross --- drivers/xen/gntdev-dmabuf.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c index 75d3bb948bf3..ba6cad871568 100644 --- a/drivers/xen/gntdev-dmabuf.c +++ b/drivers/xen/gntdev-dmabuf.c @@ -247,10 +247,9 @@ static void dmabuf_exp_ops_detach(struct dma_buf *dma_buf, if (sgt) { if (gntdev_dmabuf_attach->dir != DMA_NONE) - dma_unmap_sg_attrs(attach->dev, sgt->sgl, - sgt->nents, - gntdev_dmabuf_attach->dir, - DMA_ATTR_SKIP_CPU_SYNC); + dma_unmap_sgtable(attach->dev, sgt, + gntdev_dmabuf_attach->dir, + DMA_ATTR_SKIP_CPU_SYNC); sg_free_table(sgt); } @@ -288,8 +287,8 @@ dmabuf_exp_ops_map_dma_buf(struct dma_buf_attachment *attach, sgt = dmabuf_pages_to_sgt(gntdev_dmabuf->pages, gntdev_dmabuf->nr_pages); if (!IS_ERR(sgt)) { - if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir, - DMA_ATTR_SKIP_CPU_SYNC)) { + if (dma_map_sgtable(attach->dev, sgt, dir, + DMA_ATTR_SKIP_CPU_SYNC)) { sg_free_table(sgt); kfree(sgt); sgt = ERR_PTR(-ENOMEM); @@ -625,7 +624,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device *dev, /* Now convert sgt to array of pages and check for page validity. */ i = 0; - for_each_sg_page(sgt->sgl, &sg_iter, sgt->nents, 0) { + for_each_sgtable_page(sgt, &sg_iter, 0) { struct page *page = sg_page_iter_page(&sg_iter); /* * Check if page is valid: this can happen if we are given -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:43:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:43:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwhf-0000NK-34; Thu, 18 Jun 2020 15:43:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwhd-0000NC-Od for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:43:45 +0000 X-Inumbo-ID: 7dc8a56b-b17a-11ea-bab1-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7dc8a56b-b17a-11ea-bab1-12813bfff9fa; Thu, 18 Jun 2020 15:43:44 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: bgtLkhZLDUWS9ieYmtFGFJuIM0D//NLNSt4C9yZ3MtD1/PE9EPQkRbB4yBKnsHoyXViP++4o5d Sr08uTpYh7QDCzV/SyxN+5XxJxO8kSPJ4AN2360fdPqJUhzcHa11YqMKCYGVto6p7I+lNUHrLU NiH/APdJWgB63N1dQ0LvSYFkNpTlvAKfma6hDyftoip6A1pSxVXG57c/noNAmS9+pbtKHvY6Cm UktYCLZbodYncTmBTE4gP8/sQru55NTJh74Qd+86BzhbuepZO2Ft6qxguK6FxmgNL4avRgWcJj GKo= X-SBRS: 2.7 X-MesageID: 20613185 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20613185" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24299.35750.218855.454255@mariner.uk.xensource.com> Date: Thu, 18 Jun 2020 16:43:34 +0100 To: Jason Andryuk , Paul Durrant Subject: Re: [PATCH for-4.14] xl: Allow shutdown wait for domain death In-Reply-To: <20200617023642.80594-1-jandryuk@gmail.com> References: <20200617023642.80594-1-jandryuk@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , "xen-devel@lists.xenproject.org" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jason Andryuk writes ("[PATCH] xl: Allow shutdown wait for domain death"): > `xl shutdown -w` waits for the first of either domain shutdown or death. > Shutdown is the halting of the guest operating system, and death is the > freeing of domain resources. > > Allow specifying -w multiple times to wait for only domain death. This > is useful in scripts so that all resources are free before the script > continues. Thanks! Reviewed-by: Ian Jackson Paul, I think this is a candidate for 4.14. Without this patch it is not possible to reliably wait for a domain, with xl, and then restart it. (At least not without a good deal of pratting about and polling with xl list.) osstest has a `sleep' as a workaround... I have reviewed this patch particularly carefully with a view to understanding what happens if you pass just one `-w' as before. I have convinced myself that there is definitely no change, so I don't think this patch can introduce a regression. Ian. > Signed-off-by: Jason Andryuk > --- > docs/man/xl.1.pod.in | 4 +++- > tools/xl/xl_vmcontrol.c | 17 +++++++++++------ > 2 files changed, 14 insertions(+), 7 deletions(-) > > diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in > index 09339282e6..52a47a6fbd 100644 > --- a/docs/man/xl.1.pod.in > +++ b/docs/man/xl.1.pod.in > @@ -743,7 +743,9 @@ of a Xen system. > > =item B<-w>, B<--wait> > > -Wait for the domain to complete shutdown before returning. > +Wait for the domain to complete shutdown before returning. If given once, > +the wait is for domain shutdown or domain death. If given multiple times, > +the wait is for domain death only. > > =item B<-F> > > diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c > index 17b4514c94..435155a033 100644 > --- a/tools/xl/xl_vmcontrol.c > +++ b/tools/xl/xl_vmcontrol.c > @@ -162,7 +162,8 @@ static void shutdown_domain(uint32_t domid, > } > } > > -static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr) > +static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr, > + int wait_for_shutdown_or_death) > { > int rc, count = 0; > LOG("Waiting for %d domains", nr); > @@ -183,8 +184,12 @@ static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr) > case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN: > LOG("Domain %d has been shut down, reason code %d", > event->domid, event->u.domain_shutdown.shutdown_reason); > - libxl_evdisable_domain_death(ctx, deathws[event->for_user]); > - count++; > + if (wait_for_shutdown_or_death) { > + libxl_evdisable_domain_death(ctx, deathws[event->for_user]); > + count++; > + } else { > + LOG("Domain %d continue waiting for death", event->domid); > + } > break; > default: > LOG("Unexpected event type %d", event->type); > @@ -214,7 +219,7 @@ static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv) > all = 1; > break; > case 'w': > - wait_for_it = 1; > + wait_for_it++; > break; > case 'F': > fallback_trigger = 1; > @@ -246,7 +251,7 @@ static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv) > } > > if (deathws) { > - wait_for_domain_deaths(deathws, nrdeathws); > + wait_for_domain_deaths(deathws, nrdeathws, wait_for_it == 1); > free(deathws); > } > > @@ -258,7 +263,7 @@ static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv) > fn(domid, wait_for_it ? &deathw : NULL, 0, fallback_trigger); > > if (wait_for_it) > - wait_for_domain_deaths(&deathw, 1); > + wait_for_domain_deaths(&deathw, 1, wait_for_it == 1); > } > > > -- > 2.25.1 > From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:44:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:44:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwie-0000Rq-Dw; Thu, 18 Jun 2020 15:44:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwid-0000Rl-Pb for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:44:47 +0000 X-Inumbo-ID: a2cd5bd0-b17a-11ea-bab1-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a2cd5bd0-b17a-11ea-bab1-12813bfff9fa; Thu, 18 Jun 2020 15:44:46 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: XaVla1quVof99QrAtv8blUWXu9G6GZWD3AN49519F+akA1o5/jZ1qohqu6i0voh6YcCltUcM8e 9rSGk8QRaKsFW3gVkuVtjo4Xti2atfbGJpR2iO0hBKZzqRzNjkSqpulVxoP5nd3zeV0HPDWMPk +M5b/BNWKIGBE6gX8Lxb5dSk1FgpfHUMM5z2ME80awtjkArO6az6n6lE7EgHde67UYgNn1GO0G cIzhjhJVQ/pp+OIgrQXoTbpXHZB5af1syYNDqrs9QRqlty2rSdcnijJir88PVbturk37oOqHpM jPk= X-SBRS: 2.7 X-MesageID: 20386899 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20386899" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24299.35817.486533.42273@mariner.uk.xensource.com> Date: Thu, 18 Jun 2020 16:44:41 +0100 To: "paul@xen.org" Subject: RE: [PATCH for-4.14 v3] tools/xen-ucode: return correct exit code on failed microcode update In-Reply-To: <005b01d64482$da189650$8e49c2f0$@xen.org> References: <1592360353-31231-1-git-send-email-igor.druzhinin@citrix.com> <005b01d64482$da189650$8e49c2f0$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Igor Druzhinin , "xadimgnik@gmail.com" , "wl@xen.org" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: [PATCH for-4.14 v3] tools/xen-ucode: return correct exit code on failed microcode update"): > > -----Original Message----- > > From: Igor Druzhinin > > Sent: 17 June 2020 03:19 > > To: xen-devel@lists.xenproject.org > > Cc: ian.jackson@eu.citrix.com; wl@xen.org; xadimgnik@gmail.com; Igor Druzhinin > > > > Subject: [PATCH for-4.14 v3] tools/xen-ucode: return correct exit code on failed microcode update > > > > Otherwise it's difficult to know if operation failed inside the automation. > > > > While at it, also switch to returning 1 and 2 instead of errno to avoid > > incompatibilies between errno and special exit code numbers. > > > > Signed-off-by: Igor Druzhinin Thanks, this looks good to me. > Reviewed-by: Paul Durrant > Release-acked-by: Paul Durrant Reviewed-by: Ian Jackson I will commit this in a moment. Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:46:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:46:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwkQ-0000a5-QA; Thu, 18 Jun 2020 15:46:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwkP-0000Zz-RD for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:46:37 +0000 X-Inumbo-ID: e48eb924-b17a-11ea-bab1-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e48eb924-b17a-11ea-bab1-12813bfff9fa; Thu, 18 Jun 2020 15:46:37 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: hhva6BU1rQl2VCDwwk4yuwkMXe2Wypada6Qo5g3E1C5DylH6c8+igtX3x48pwlmui30ekuvEmq eZhlbiXd5fv3vQscjL+gn5MMmOM1UJIxJXh5noXZglJ1izwktmdPtzMAISMyuwX7s4vwg1jrpc W5U2o3pCvpJgFOfmhW168H+P4/Td2yjpZv0OSCVBCZa8Kl9n5Fi4crHngXTi+ldRkaTbzihZA8 u3mChOrap0PzZFJBPYy8Ag4ifxsTk3G6cbPewM6AFUVHqFNb7HverkaHpuFZS3JUBYhsQSXvNK Raw= X-SBRS: 2.7 X-MesageID: 20400594 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20400594" Date: Thu, 18 Jun 2020 17:46:28 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Tamas K Lengyel Subject: Re: [PATCH v3 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Message-ID: <20200618154628.GW735@Air-de-Roger> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 07:39:04AM -0700, Tamas K Lengyel wrote: > While forking VMs running a small RTOS system (Zephyr) a Xen crash has been > observed due to a mm-lock order violation while copying the HVM CPU context > from the parent. This issue has been identified to be due to > hap_update_paging_modes first getting a lock on the gfn using get_gfn. This > call also creates a shared entry in the fork's memory map for the cr3 gfn. The > function later calls hap_update_cr3 while holding the paging_lock, which > results in the lock-order violation in vmx_load_pdptrs when it tries to unshare > the above entry when it grabs the page with the P2M_UNSHARE flag set. > > Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was > unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure > the p2m is properly populated. > > Note that the lock order violation is avoided because before the paging_lock is > taken a lookup is performed with P2M_ALLOC that forks the page, thus the second > lookup in vmx_load_pdptrs succeeds without having to perform the fork. We keep > P2M_ALLOC in vmx_load_pdptrs because there are code-paths leading up to it > which don't take the paging_lock and that have no previous lookup. Currently no > other code-path exists leading there with the paging_lock taken, thus no > further adjustments are necessary. > > Signed-off-by: Tamas K Lengyel Reviewed-by: Roger Pau Monné Thanks! From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:47:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:47:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwkt-0000d3-2u; Thu, 18 Jun 2020 15:47:07 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwks-0000cv-8H for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:47:06 +0000 X-Inumbo-ID: f3acc28e-b17a-11ea-bab1-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f3acc28e-b17a-11ea-bab1-12813bfff9fa; Thu, 18 Jun 2020 15:47:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4mn7y2aYkxcMMjHrMiXOWrcyhUwxHl1mErobBE5tXbg=; b=TYd1C5+AoEw03+36hKp3c2VYj iHgWhQcQHJaROLpArgdUAl9tA1jGkVAlmuwXvCiWPfwaLwaLdCU04NFKT0qfVhyFJzp4aNXKjzqc9 HUQv2oPbHhC6fBUCiJBlS02GMhVm2weRXe3I94dQJin54Q3PdNqctU4xVTR9PVGl2HcWY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwkn-0003Uo-El; Thu, 18 Jun 2020 15:47:01 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlwkn-0008G6-4b; Thu, 18 Jun 2020 15:47:01 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlwkn-0000iz-34; Thu, 18 Jun 2020 15:47:01 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 151188: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.9-testing:build-i386-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64-prev:xen-build:fail:regression xen-4.9-testing:build-i386-prev:xen-build:fail:regression xen-4.9-testing:build-amd64-xsm:xen-build:fail:regression xen-4.9-testing:build-amd64:xen-build:fail:regression xen-4.9-testing:build-i386:xen-build:fail:regression xen-4.9-testing:test-amd64-amd64-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qcow2:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-5:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-4:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-amd64-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-i386:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemuu-rhel6hvm-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-1:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-multivcpu:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ovmf-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:build-i386-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-i386-pvgrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-qemut-rhel6hvm-amd:build-check(1):blocked:nonblocking xen-4.9-testing:test-xtf-amd64-amd64-3:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-rtds:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-raw:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-credit2:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:build-check(1):blocked:nonblocking xen-4.9-testing:build-amd64-libvirt:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-debianhvm-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-livepatch:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pygrub:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-freebsd10-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-intel:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-pair:build-check(1):blocked:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:build-check(1):blocked:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:guest-start:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=6e477c2ea4d5c26a7a7b2f850166aa79edc5225c X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Thu, 18 Jun 2020 15:47:01 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151188 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151188/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm 6 xen-build fail REGR. vs. 150120 build-amd64-prev 6 xen-build fail REGR. vs. 150120 build-i386-prev 6 xen-build fail REGR. vs. 150120 build-amd64-xsm 6 xen-build fail REGR. vs. 150120 build-amd64 6 xen-build fail REGR. vs. 150120 build-i386 6 xen-build fail REGR. vs. 150120 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-xtf-amd64-amd64-2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-livepatch 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-xtf-amd64-amd64-5 1 build-check(1) blocked n/a test-xtf-amd64-amd64-4 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-xtf-amd64-amd64-1 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-xtf-amd64-amd64-3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-i386-xl-raw 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-livepatch 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 12 guest-start fail like 150120 test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 39 days Failing since 150940 2020-06-09 17:05:20 Z 8 days 11 attempts Testing same since 151070 2020-06-13 06:57:26 Z 5 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Ian Jackson John Thomson Julien Grall Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm fail build-arm64-xsm pass build-i386-xsm fail build-amd64-xtf pass build-amd64 fail build-arm64 pass build-armhf pass build-i386 fail build-amd64-libvirt blocked build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt blocked build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 blocked test-xtf-amd64-amd64-2 blocked test-xtf-amd64-amd64-3 blocked test-xtf-amd64-amd64-4 blocked test-xtf-amd64-amd64-5 blocked test-amd64-amd64-xl blocked test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl blocked test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm blocked test-amd64-amd64-xl-qemut-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemut-debianhvm-i386-xsm blocked test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-i386-xl-qemuu-debianhvm-i386-xsm blocked test-amd64-amd64-libvirt-xsm blocked test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-xl-xsm blocked test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm blocked test-amd64-amd64-qemuu-nested-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-debianhvm-amd64 blocked test-amd64-i386-xl-qemut-debianhvm-amd64 blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked test-amd64-i386-freebsd10-amd64 blocked test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 blocked test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 blocked test-amd64-i386-xl-qemuu-win7-amd64 blocked test-amd64-amd64-xl-qemut-ws16-amd64 blocked test-amd64-i386-xl-qemut-ws16-amd64 blocked test-amd64-amd64-xl-qemuu-ws16-amd64 blocked test-amd64-i386-xl-qemuu-ws16-amd64 blocked test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 blocked test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 blocked test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 blocked test-amd64-amd64-qemuu-nested-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-amd64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt blocked test-amd64-amd64-livepatch blocked test-amd64-i386-livepatch blocked test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu blocked test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair blocked test-amd64-i386-pair blocked test-amd64-amd64-libvirt-pair blocked test-amd64-i386-libvirt-pair blocked test-amd64-amd64-amd64-pvgrub blocked test-amd64-amd64-i386-pvgrub blocked test-amd64-amd64-pygrub blocked test-amd64-amd64-xl-qcow2 blocked test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw blocked test-amd64-amd64-xl-rtds blocked test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow blocked test-amd64-amd64-xl-shadow blocked test-amd64-i386-xl-shadow blocked test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd blocked test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c Author: Wei Liu Date: Mon Jun 12 16:04:17 2017 +0100 ipxe: update to newer commit To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7. The only patch we have applies cleanly. Reported-by: Zhongze Liu Signed-off-by: Wei Liu Acked-by: Ian Jackson (cherry picked from commit 461b2165346de236fff2d00d1c318062f1daab08) commit 6a1c431890599c701117bf9822898f60a18444a3 Author: John Thomson Date: Tue May 15 11:48:43 2018 +1000 tools/ocaml/libs/xc fix gcc-8 format-truncation warning CC xenctrl_stubs.o xenctrl_stubs.c: In function 'failwith_xc': xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] "%d: %s: %s", error->code, ^ xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028 snprintf(error_str, sizeof(error_str), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%d: %s: %s", error->code, ~~~~~~~~~~~~~~~~~~~~~~~~~~ xc_error_code_to_desc(error->code), ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error->message); ~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1 m Signed-off-by: John Thomson Acked-by: Christian Lindig Release-acked-by: Juergen Gross (cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795) commit 41f597f5167c2e78a3c70d219710c8805d7fec8e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:50 2018 +0200 tools/misc: fix hypothetical buffer overflow in xen-lowmemd gcc-8 complains: xen-lowmemd.c: In function 'handle_low_mem': xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=] snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~ ~~~~ xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512 snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In practice it wouldn't happen, because 'data' contains string representation of 64-bit unsigned number (20 characters at most). But place a limit to mute gcc warning. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080) commit 1eae17268887bacbc598ef6e3290059dbeb4fd8f Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:52 2018 +0200 tools/blktap2: fix possible '\0' truncation gcc-8 complains: tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring': tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=] snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^ tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255 snprintf(params.name, sizeof(params.name) - 1, "%s", message); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The "- 1" in buffer size should be actually applied to message, to leave place for terminating '\0', not the other way around (truncate '\0' even if it would fit). In function 'tapdisk_control_open_image', inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10: tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'tapdisk_control_create_socket', inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9: tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation] strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ block-qcow.c: In function 'qcow_create': block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(backing_filename, backing_file, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(backing_filename)); ~~~~~~~~~~~~~~~~~~~~~~~~~ I those cases, reduce size of copied string and make sure final '\0' is added. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a) commit f1e75e5c7054d8cd7bdfe30c6a95af35cc24fbb2 Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:54 2018 +0200 tools/gdbsx: fix -Wstringop-truncation warning gcc-8 complains: gx_main.c: In function 'prepare_stop_reply': gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation] strncpy(buf, "watch:", 6); ^~~~~~~~~~~~~~~~~~~~~~~~~ Since terminating '\0' isn't needed here at all, switch to memcpy. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f) commit f034ab45c15aef9c784dbcdc5c893e268d4a094c Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:53 2018 +0200 tools/xenpmd: fix possible '\0' truncation gcc-8 complains: xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->oem_info, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->battery_type, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->serial_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(info->model_number, attrib_value, 32); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copy 31 chars, then make sure terminating '\0' is present. Those fields are passed to strlen and as '%s' for snprintf later. Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b) commit 9737f89b076ae4d05e6f974a7c21aced4459966e Author: Marek Marczykowski-Górecki Date: Thu Apr 5 03:50:49 2018 +0200 tools/libxc: fix strncpy size gcc-8 warns about possible truncation of trailing '\0'. Final character is overridden by '\0' anyway, so don't bother to copy it. This fixes compile failure: xc_pm.c: In function 'xc_set_cpufreq_gov': xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Marek Marczykowski-Górecki Acked-by: Wei Liu Release-Acked-by: Juergen Gross (cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159) commit 1dd64783024c5c9e600c3d33393b795c68a46f65 Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit 80d78acf9e60ae6a88d6cb6f3535eaf67c81f61c Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. Extend libxl's table of named parameters to include RDRAND/RDSEED, and have the compiler construct it in .rodata, rather than on the stack at runtime each time it is called. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit ad0c1a0023077ee03d325a6f84bb654150539f49 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 04af886e1bc87bb321339417c5588d12f506003c Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:47:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:47:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwle-0000lZ-JI; Thu, 18 Jun 2020 15:47:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwld-0000lN-BL for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:47:53 +0000 X-Inumbo-ID: 119b612e-b17b-11ea-8496-bc764e2007e4 Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 119b612e-b17b-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 15:47:52 +0000 (UTC) Received: by mail-wm1-x343.google.com with SMTP id r15so6177289wmh.5 for ; Thu, 18 Jun 2020 08:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WGXKW0CHLmKn1eEWTHdkXEOrmpITF5JY9osaKifbsEM=; b=Z2FtwT4eSZnz+iLtE8XBR/74hRh+BWYXKxHyagfaQkrRutSl1+KqRPQKl1gl0gT4dP /W96riqNzlbWtjJDIOHrW2nfhVsk3FC5oP+0AfktM+A9h8/U7/pvtzzHbTpSe5wjJ+Zd UjFhp4MOUU4gHVa28vC5ruMi5Z8xjJWpRt79DZVWt5IB44MecnKM2CYGKpqvqd4axRxC GzRBd7L+08XinC1ZagqeWfdTMs9ZFD8o8ChCe2MSoVoATbGNdtLi0EmnIKrcjnqDi/Gl oNaD9lLBk5V61OkNc3gmeAORA+tIewTxQumhURRVl+H5eSP5+DRlHLa8kCHkwBDoL9CE 971g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WGXKW0CHLmKn1eEWTHdkXEOrmpITF5JY9osaKifbsEM=; b=TKgVgJ/T/oIuyU2wzCBc1xwlk+QArVhi83G0LFsqnqCILCcrUwzQvKL9ZjurtDWwDj lJmLjoPItJdliZ7Afc1GHwmGlBH7R181ItdHV9h08W858F0RNvF+6ItfAB8xcWcQMYzc 8JyqjNbx6vpSDMPX7n/gKZCdsTBJsxxKT1Sxll5KMj6KzZmorzmMc0rVj/bF3V/I6v00 q5sVa6APqc2h+rxipGWZZzTiSX9abChmJJDhLSNx1shSDUzm8h4TIG6k8bQEH1+1MgEK 3tuj3UsPA4adY1X3IfHFYGctK0TsiXpvxgDhmkRzC16qV9VJGnE7Lq8MlpsSU2gg5lqM kH3w== X-Gm-Message-State: AOAM530lkOYsiMYjenZkLwHSgMvqBxwjropnjviaLIrV2KaFO4bjKreZ nJIHAC41G77txKaPbwj/M06FtbM8+ObVpokkv4U= X-Google-Smtp-Source: ABdhPJy9hC7RLzyoHijRaKuppw4qDKT6RCdSgJ8qaqVRmcKDNimR2ogmdqssjrwgweUfmtOIJU68vt624ks1wzySvXc= X-Received: by 2002:a1c:964d:: with SMTP id y74mr4945156wmd.154.1592495271700; Thu, 18 Jun 2020 08:47:51 -0700 (PDT) MIME-Version: 1.0 References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <1599209169.9756264.1592493912556.JavaMail.zimbra@cert.pl> In-Reply-To: From: Tamas K Lengyel Date: Thu, 18 Jun 2020 09:47:16 -0600 Message-ID: Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op To: Jan Beulich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Ian Jackson , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 9:41 AM Jan Beulich wrote: > > On 18.06.2020 17:25, Micha=C5=82 Leszczy=C5=84ski wrote: > > ----- 16 cze 2020 o 19:23, Roger Pau Monn=C3=A9 roger.pau@citrix.com na= pisa=C5=82(a): > >> On Tue, Jun 16, 2020 at 05:22:06PM +0200, Micha=C5=82 Leszczy=C5=84ski= wrote: > >>> --- a/xen/include/public/hvm/hvm_op.h > >>> +++ b/xen/include/public/hvm/hvm_op.h > >>> @@ -382,6 +382,33 @@ struct xen_hvm_altp2m_op { > >>> typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; > >>> DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); > >>> > >>> +/* HVMOP_vmtrace: Perform VM tracing related operation */ > >>> +#define HVMOP_vmtrace 26 > >>> + > >>> +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 > >>> + > >>> +struct xen_hvm_vmtrace_op { > >>> + /* IN variable */ > >>> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ > >>> + uint32_t cmd; > >>> +/* Enable/disable external vmtrace for given domain */ > >>> +#define HVMOP_vmtrace_ipt_enable 1 > >>> +#define HVMOP_vmtrace_ipt_disable 2 > >>> +#define HVMOP_vmtrace_ipt_get_buf 3 > >>> +#define HVMOP_vmtrace_ipt_get_offset 4 > >>> + domid_t domain; > >> > >> You are missing a padding field here AFAICT. > > > > > > Could you point out what is the purpose of this padding field and what = should be the size in this case? It's pretty unclear to me. > > In the public interface we aim at making all padding explicit. Just to expand a bit on this: this is an ABI meaning the hypervisor and the tool sending this structure communicate via memory only. Since the hypervisor and the compiler can be compiled using different compilers, using stuff that's not explicit in the C standard needs to be avoided. For example using standard types like "int" or "long" is no good since it's really up to the compiler to decide how much memory those need. The C specification is great like that.. Same stands for padding. Different compilers can decide to align things differently, pack things or not pack things, so we have to manually add the padding to take that choice away from the compiler. As discussed many times on the list, using C struct as the base of the ABI was a bad design decision to start with, but we are now stuck with it. It would now make more sense to use something like JSON to pass information like this between the hypervisor and the toolstack which is what we opted to do in new hypervisors like Bareflank/Boxy. Tamas From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:48:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:48:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwmK-0000sF-TF; Thu, 18 Jun 2020 15:48:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwmK-0000qu-IO for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:48:36 +0000 X-Inumbo-ID: 2b8214f3-b17b-11ea-bab1-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2b8214f3-b17b-11ea-bab1-12813bfff9fa; Thu, 18 Jun 2020 15:48:36 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: D59ZWsE6GzKmRc2OHWzd73A2GxLC/H+Eni2KbiRziJrxpCbIi4Weh+AvpgwY6HAob9ti9cTP0I UTT2h2ijGFVOVRDsdylvHguXi+pqmBerRiwaSkjZmRl+Povnv6xxqFzFziQB2JTpLzTvDjQjIe 6WNdgi5AoHpPbCQuWVLBOhQTlxCj3+AUOroa88h5rPkxAU8eaTYjicpN4pfv0jGXRDBfjGAhQq YU4QYlrYyI0aRaLo2Jvnf9sGIwKR3isrqROozmrMyDuxdE7ZNSQxWlCNS0pXZ0ju/+vE08rU3g /E0= X-SBRS: 2.7 X-MesageID: 20732853 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20732853" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24299.36041.946061.376335@mariner.uk.xensource.com> Date: Thu, 18 Jun 2020 16:48:25 +0100 To: Wei Liu , Anthony Perard , "Andrew Cooper" , Paul Durrant Subject: Re: [XEN PATCH for-4.14 0/2] tools: Update/reset autogenerated files In-Reply-To: <20200612151931.1083-1-ian.jackson@eu.citrix.com> References: <000401d640c9$7b14e760$713eb620$@xen.org> <20200612151931.1083-1-ian.jackson@eu.citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Nick Rosbrook , Samuel Thibault Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Ian Jackson writes ("[XEN PATCH for-4.14 0/2] tools: Update/reset autogenerated files"): > We commit the output of autogen.sh, and the outputs of flex and bison, > to help people without recent versions of the corresponding tools. > > Our usual practice hitherto has been to declare a version of Debian > that we are tracking, and have committers run autogen.sh, or make -C > tools/libxl clean && make -C tools/libxl all, on that version of > Debian. > > Patches to osstest to detect violations of this rule would be welcome. > > After 4.14 we can perhaps revisit which of these files should be > committed and how they should be managed. Ping. Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:49:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:49:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwnU-00010N-76; Thu, 18 Jun 2020 15:49:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwnT-00010E-G2 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:49:47 +0000 X-Inumbo-ID: 5592f40a-b17b-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5592f40a-b17b-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 15:49:46 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id r7so6602284wro.1 for ; Thu, 18 Jun 2020 08:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+DWoeFkopjjNX1PbX1m7YzEf1NbfIy2AI/0OrJadQp4=; b=kNjbbLFw4D7RVWzpqM5bEj4Ofjh4f94HgFK4Lt4YtGTcKDny1ugyb3tYKaoNCYg/wU ctutCbAVc2GqUTEOrbtIhGQ3v2j8VD50vsDfIaBfAKYjBjHFLnBSUP8chFs/onSJq6rl 3qTenjqlWHYczvGc9Fx9IxTwKTfPAyBWMMJJXX8kf8RlExpnHFuEMo742vEMxyxfgepZ es5ah/nFDmfHTX5y8oro8rp+VBHRHO6cUOwNSPbL4tnhUzLOwptSa88aRmN8KbayXVce l+por2joOp6QJ/wwh3rOUsKcDksPZlJ1hwxwEls8DlWJsmt7Td68+M/vw3T+qT63Jy/7 Y/cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+DWoeFkopjjNX1PbX1m7YzEf1NbfIy2AI/0OrJadQp4=; b=DTnijGxcN6tS7Lk0k4f5vXSMabNOQY0zeKFHvfmfESD+jLnv2/ycozzcg+Hjw3xx3L B+++s55H0i05gAH15tCd6sZq9D9jFygcIMvvoNvOa9Rj/SfoW8aoryMa7GC6NmXn1IR7 XR61ypMvE7/8xe3s9uMv0bbbVO8CXZg3VNqUzJdA2lqQLBrtEqkGnbkTJXM4ZWn3HTrD VCrM8LqYmahSJK0YUbVZNcSIK564dQytL7JD6VGuQNVSFEGdY8drK6d8gcAZsXck3zDx uT5Xtd+IPsOdWDb4g7UJL3yxYO0+8r9EdL33Z/giJTAklN98ip4cLkqtSjRrXftpeaIU Tytg== X-Gm-Message-State: AOAM533X/LvAM6CIGve7+11Up15pvZZdmrdkYwPPr5fCT6ovJtV5u4Z3 OI1eaihY+Xb6lHi6OsETL7prrejtnCzAisWsSes= X-Google-Smtp-Source: ABdhPJy6xrnztjHjy/7VPTjC89LXE7trX76wXLnB0zidbWIkw0GWWWxCh1ntuJjc9tlpIu9czTODWhogbvDjpUxkSj8= X-Received: by 2002:a5d:490f:: with SMTP id x15mr5151188wrq.259.1592495385898; Thu, 18 Jun 2020 08:49:45 -0700 (PDT) MIME-Version: 1.0 References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <34833328.8766172.1592320926648.JavaMail.zimbra@cert.pl> <20200616172352.GT735@Air-de-Roger> <1599209169.9756264.1592493912556.JavaMail.zimbra@cert.pl> In-Reply-To: From: Tamas K Lengyel Date: Thu, 18 Jun 2020 09:49:10 -0600 Message-ID: Subject: Re: [PATCH v1 4/7] x86/vmx: add do_vmtrace_op To: Jan Beulich Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Ian Jackson , George Dunlap , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 9:47 AM Tamas K Lengyel wrote: > > On Thu, Jun 18, 2020 at 9:41 AM Jan Beulich wrote: > > > > On 18.06.2020 17:25, Micha=C5=82 Leszczy=C5=84ski wrote: > > > ----- 16 cze 2020 o 19:23, Roger Pau Monn=C3=A9 roger.pau@citrix.com = napisa=C5=82(a): > > >> On Tue, Jun 16, 2020 at 05:22:06PM +0200, Micha=C5=82 Leszczy=C5=84s= ki wrote: > > >>> --- a/xen/include/public/hvm/hvm_op.h > > >>> +++ b/xen/include/public/hvm/hvm_op.h > > >>> @@ -382,6 +382,33 @@ struct xen_hvm_altp2m_op { > > >>> typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; > > >>> DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); > > >>> > > >>> +/* HVMOP_vmtrace: Perform VM tracing related operation */ > > >>> +#define HVMOP_vmtrace 26 > > >>> + > > >>> +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 > > >>> + > > >>> +struct xen_hvm_vmtrace_op { > > >>> + /* IN variable */ > > >>> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ > > >>> + uint32_t cmd; > > >>> +/* Enable/disable external vmtrace for given domain */ > > >>> +#define HVMOP_vmtrace_ipt_enable 1 > > >>> +#define HVMOP_vmtrace_ipt_disable 2 > > >>> +#define HVMOP_vmtrace_ipt_get_buf 3 > > >>> +#define HVMOP_vmtrace_ipt_get_offset 4 > > >>> + domid_t domain; > > >> > > >> You are missing a padding field here AFAICT. > > > > > > > > > Could you point out what is the purpose of this padding field and wha= t should be the size in this case? It's pretty unclear to me. > > > > In the public interface we aim at making all padding explicit. > > Just to expand a bit on this: this is an ABI meaning the hypervisor > and the tool sending this structure communicate via memory only. Since > the hypervisor and the compiler can be compiled using different ^ meant to write "hypervisor and the toolstack" above Tamas From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:50:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:50:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwoQ-0001jP-H0; Thu, 18 Jun 2020 15:50:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwoO-0001jG-UH for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:50:44 +0000 X-Inumbo-ID: 77e3b1c0-b17b-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x431.google.com (unknown [2a00:1450:4864:20::431]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 77e3b1c0-b17b-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 15:50:44 +0000 (UTC) Received: by mail-wr1-x431.google.com with SMTP id r7so6605700wro.1 for ; Thu, 18 Jun 2020 08:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=lT/7EcXsvOOiTprb3aYSPlNH1XuyuZBC0soAOJPxS3k=; b=OjBcL4bplMOHQG2ee/6u6IS0yYbsSfHjTTBO83JIZyo1LDgdgm7NsPg0qNLUMonpbb auxTix0Y1elhf8uVO2qxKfnKF9LrpOfZ4Xt4UiImJpRqpDHvLnZaf2GYHpUfpaFZbnga 96HAj95olu8uT/ARKl02w3d2dkaEREPrDE+vACyzGSXX8FBV5XC3wR19bSxeMhkA7Vvv FRacu3qVNbLiX51oBRYYgpejsYxIzFN3RRCHgtV1fPgj7z2/pXGoTGvEhuE5JRPZ7H+B 5RDBxuqXzbA5HFETbgqfl8hhddgQIv1O0sBl+Ww45v1eJAwiah6sOUHxR/A1NTe+ZMkb syMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=lT/7EcXsvOOiTprb3aYSPlNH1XuyuZBC0soAOJPxS3k=; b=XpuLkjctfKnydl6Y74sRRevfHANV7sPfZH67WbPQJ6JXb1JZFnhhKr/6oZ1TyvvBKI 0EAyURjvXBFibiHNRgUzUN8DyIfU5wGvmw7KPCslgkb3PDEW4JrenAFqgqVRIDRiWb2y u95wq30l9gHm7U3wa4YywsQw7+RQolwWHNNarGrnhU+i53NIldiZ5altGY4TsGD00L5V Q8JXkRV097weIK4AJJUwjowATkO7UMXihNhqXf5HeqTk/g+7iahE3pb+OEDbQ7c+yurI ywXYd25LDLNLySBifQxSDOC3HaZYgtA8RwLroiHIPc5cPeREGgLdor5IOldK4+YDbM+l S9oA== X-Gm-Message-State: AOAM531sdNP1+Hag/uVPgPjer4zF0gItaB+8Xvg39TmrGVn6jQtteNWA CzJmJCQs5L8rZra8WXpL5uE= X-Google-Smtp-Source: ABdhPJwyo0PlQA9bUpwg4NRH66zpkHTf3KnkFLNV/+jAKE0DCJzh0eAS2rMdP79w8X65EOUt3+MQ8Q== X-Received: by 2002:adf:db47:: with SMTP id f7mr5496496wrj.101.1592495443576; Thu, 18 Jun 2020 08:50:43 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id b18sm3936992wrn.88.2020.06.18.08.50.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 08:50:43 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Wei Liu'" , "'Anthony Perard'" , "'Andrew Cooper'" References: <000401d640c9$7b14e760$713eb620$@xen.org> <20200612151931.1083-1-ian.jackson@eu.citrix.com> <24299.36041.946061.376335@mariner.uk.xensource.com> In-Reply-To: <24299.36041.946061.376335@mariner.uk.xensource.com> Subject: RE: [XEN PATCH for-4.14 0/2] tools: Update/reset autogenerated files Date: Thu, 18 Jun 2020 16:50:41 +0100 Message-ID: <006601d64588$39208670$ab619350$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGI6gSxEetYUPUyGoePfPOSoDqDyQGre5JTAfp36mWpXAyOoA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Nick Rosbrook' , 'Samuel Thibault' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 18 June 2020 16:48 > To: Wei Liu ; Anthony Perard ; Andrew Cooper > ; Paul Durrant > Cc: xen-devel@lists.xenproject.org; Samuel Thibault ; Nick Rosbrook > > Subject: Re: [XEN PATCH for-4.14 0/2] tools: Update/reset autogenerated files > > Ian Jackson writes ("[XEN PATCH for-4.14 0/2] tools: Update/reset autogenerated files"): > > We commit the output of autogen.sh, and the outputs of flex and bison, > > to help people without recent versions of the corresponding tools. > > > > Our usual practice hitherto has been to declare a version of Debian > > that we are tracking, and have committers run autogen.sh, or make -C > > tools/libxl clean && make -C tools/libxl all, on that version of > > Debian. > > > > Patches to osstest to detect violations of this rule would be welcome. > > > > After 4.14 we can perhaps revisit which of these files should be > > committed and how they should be managed. > > Ping. > You can consider this... Release-acked-by: Paul Durrant ...once the appropriate maintainer acks are given. > Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:52:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:52:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwq5-0001rZ-UG; Thu, 18 Jun 2020 15:52:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwq4-0001rU-4w for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:52:28 +0000 X-Inumbo-ID: b5552afc-b17b-11ea-8496-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b5552afc-b17b-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 15:52:27 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id q11so6606820wrp.3 for ; Thu, 18 Jun 2020 08:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=li8oNN6ew0XxeSaemvQowz7zMpb4IhYQRYuOZlpR9iA=; b=VdI3CU3HVI9QgOOl87oggvIpp4Aqg9NOkOszxFc1laqe5BnG3mQonGGokUwkQPAV0O K71zW3qNISPdk5L1mL2gQzivk5/9hbzNLfBtUay9ksQuaeaEws4H+SnnvIYO3lQIKL4C acal+12kgAdPhH1mFzyG2GIc+xAOKTQwid1aSrV0laDea5F7JenwVE8aWscnUh1Iao5o i1hWbZawt1y2PG2GzjlR/1endJxWMLFaOLRRokppQgJc6Kbv8Ol0XPXNj1gPCDdiHjDr Ml9aU63adOPpQsomH8fiM0+wXVceCYzQBamiQWaOPwqK6EbcYRWCSdXrFNee9+JEBGd1 2f2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=li8oNN6ew0XxeSaemvQowz7zMpb4IhYQRYuOZlpR9iA=; b=I10lA5H9DLZxJCWEPjMGM4ThUid2RqomhF7zKj9gBHsqqoTADzhPbpOC7eOxv11Kue xN4Hbvk4rm12D3I4ZpXAntBJsRCCHkSHGul1hT40wIBpfCqWsrQGY3MuGkqLAyeGeYlo x5qpKVVutzP9A/6htGiqiZK/x4xH0pakXWV9LSqANoSyQ2bzhMmKroxTmrMFh3NvRRPH Z8N1CzjcZni2crbmyBSrTLo2kXJA7Yr2W7iR0ov5bQlI3aO/OYp2U7sXJOgQ5hBGuS/J rQMhfA4LibRcWERlhiZYCOp4w9FjFpmSIhXL5+w13TjXdgiJEwOOlrTQiCjnv3vaG+7N xjqA== X-Gm-Message-State: AOAM530r82aEZXV/rBUzdDqGHJh7gm77mEps+7voA+TRoT+9owgyPoU3 8EQwsczLgVx/mI+7eAZ7LzU= X-Google-Smtp-Source: ABdhPJywNomNciTkbMbtXKWzCsoWo4d59SvcZqmmWsJ7oz3AIpANNz9Gp2RzmwOH2FiGybsyNZZ/rQ== X-Received: by 2002:adf:fd4b:: with SMTP id h11mr5092570wrs.209.1592495546649; Thu, 18 Jun 2020 08:52:26 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.186]) by smtp.gmail.com with ESMTPSA id v24sm4706202wrd.92.2020.06.18.08.52.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 08:52:26 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Jason Andryuk'" , "'Paul Durrant'" References: <20200617023642.80594-1-jandryuk@gmail.com> <24299.35750.218855.454255@mariner.uk.xensource.com> In-Reply-To: <24299.35750.218855.454255@mariner.uk.xensource.com> Subject: RE: [PATCH for-4.14] xl: Allow shutdown wait for domain death Date: Thu, 18 Jun 2020 16:52:24 +0100 Message-ID: <006701d64588$768bf1c0$63a3d540$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQETCCTnF9zzaa9ZdYDjbhQPQhOWdgHtT5ikqlWV2OA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Anthony Perard' , xen-devel@lists.xenproject.org, 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 18 June 2020 16:44 > To: Jason Andryuk ; Paul Durrant > Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard > Subject: Re: [PATCH for-4.14] xl: Allow shutdown wait for domain death > > Jason Andryuk writes ("[PATCH] xl: Allow shutdown wait for domain death"): > > `xl shutdown -w` waits for the first of either domain shutdown or death. > > Shutdown is the halting of the guest operating system, and death is the > > freeing of domain resources. > > > > Allow specifying -w multiple times to wait for only domain death. This > > is useful in scripts so that all resources are free before the script > > continues. > > Thanks! > > Reviewed-by: Ian Jackson > > Paul, I think this is a candidate for 4.14. Without this patch it is > not possible to reliably wait for a domain, with xl, and then restart > it. (At least not without a good deal of pratting about and polling > with xl list.) osstest has a `sleep' as a workaround... > Yes, it would nice to drop such workarounds. > I have reviewed this patch particularly carefully with a view to > understanding what happens if you pass just one `-w' as before. > I have convinced myself that there is definitely no change, so I don't > think this patch can introduce a regression. Ok, I'll trust your judgement. Release-acked-by: Paul Durrant > > Ian. > > > Signed-off-by: Jason Andryuk > > --- > > docs/man/xl.1.pod.in | 4 +++- > > tools/xl/xl_vmcontrol.c | 17 +++++++++++------ > > 2 files changed, 14 insertions(+), 7 deletions(-) > > > > diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in > > index 09339282e6..52a47a6fbd 100644 > > --- a/docs/man/xl.1.pod.in > > +++ b/docs/man/xl.1.pod.in > > @@ -743,7 +743,9 @@ of a Xen system. > > > > =item B<-w>, B<--wait> > > > > -Wait for the domain to complete shutdown before returning. > > +Wait for the domain to complete shutdown before returning. If given once, > > +the wait is for domain shutdown or domain death. If given multiple times, > > +the wait is for domain death only. > > > > =item B<-F> > > > > diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c > > index 17b4514c94..435155a033 100644 > > --- a/tools/xl/xl_vmcontrol.c > > +++ b/tools/xl/xl_vmcontrol.c > > @@ -162,7 +162,8 @@ static void shutdown_domain(uint32_t domid, > > } > > } > > > > -static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr) > > +static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr, > > + int wait_for_shutdown_or_death) > > { > > int rc, count = 0; > > LOG("Waiting for %d domains", nr); > > @@ -183,8 +184,12 @@ static void wait_for_domain_deaths(libxl_evgen_domain_death **deathws, int nr) > > case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN: > > LOG("Domain %d has been shut down, reason code %d", > > event->domid, event->u.domain_shutdown.shutdown_reason); > > - libxl_evdisable_domain_death(ctx, deathws[event->for_user]); > > - count++; > > + if (wait_for_shutdown_or_death) { > > + libxl_evdisable_domain_death(ctx, deathws[event->for_user]); > > + count++; > > + } else { > > + LOG("Domain %d continue waiting for death", event->domid); > > + } > > break; > > default: > > LOG("Unexpected event type %d", event->type); > > @@ -214,7 +219,7 @@ static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv) > > all = 1; > > break; > > case 'w': > > - wait_for_it = 1; > > + wait_for_it++; > > break; > > case 'F': > > fallback_trigger = 1; > > @@ -246,7 +251,7 @@ static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv) > > } > > > > if (deathws) { > > - wait_for_domain_deaths(deathws, nrdeathws); > > + wait_for_domain_deaths(deathws, nrdeathws, wait_for_it == 1); > > free(deathws); > > } > > > > @@ -258,7 +263,7 @@ static int main_shutdown_or_reboot(int do_reboot, int argc, char **argv) > > fn(domid, wait_for_it ? &deathw : NULL, 0, fallback_trigger); > > > > if (wait_for_it) > > - wait_for_domain_deaths(&deathw, 1); > > + wait_for_domain_deaths(&deathw, 1, wait_for_it == 1); > > } > > > > > > -- > > 2.25.1 > > From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:53:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:53:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwqu-0001xI-7S; Thu, 18 Jun 2020 15:53:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwqs-0001x9-RU for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:53:18 +0000 X-Inumbo-ID: d3a4d750-b17b-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x329.google.com (unknown [2a00:1450:4864:20::329]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d3a4d750-b17b-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 15:53:18 +0000 (UTC) Received: by mail-wm1-x329.google.com with SMTP id t194so6202138wmt.4 for ; Thu, 18 Jun 2020 08:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=7OemMlugsfNR/zOcIFRBo1G90vX4bXrh9IltK8wewwk=; b=BEVBEEOymBbYZSHRwJbW6pZ+M9b8NzIk7qEvgyeHBNkRj3xzaErcbByHVUvBeBVfYO lj+2X40Kbf8GcVXNM3JIFupwAeV2zQ5myyz9xYgumoCgIAguGm0dO4+6h+xsimZJZ9Sm Nyy+qaCKh5OpAbceWyR7nDGXqON3pRt9IvnAVClQgdsia6IxOKKUP7/gdUYRPCJuA78w CjFefFxRQwN7gCB80jAAIIT27MDf3cQuUxQ6k8m8iPENQBKT5VgyfWJMbeUqWry+r20b SDa67raTQcFGWyJNXMdWajsYVB0X3fp52B5i4LYJEnSGS8K9DqT13oAbb61i59BrlFpZ oWRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=7OemMlugsfNR/zOcIFRBo1G90vX4bXrh9IltK8wewwk=; b=NG2ERQr4ov3VhsTLCISrwcnFaOBj4G8BVLsj/3U2jKwezL7B9mo8kAelH2J/idzmL/ H4cDt7Stno/n9GibWHVI17a49g2rrYTMWfEiRAiNutXGki8pctD7E3IygGFhDc3hLPm9 L/j2p7RrfVGRbsNDNzIoIs+r8EFLTmwjDdk6MKIjojJVg5fCBCKF9VBb8yzOS6mMyDTV A554rVY/GjliL5JFHLxMj19JpcJPapcY50VjMEb3AOW44Fve+UDk9S/nrgX1afZYlJGK fuu6DxuKqwYaE28Hxy9k9J3Y1vl6Go1VnBY5H9F4eLuAJ/4TjbAzE5JUNGs1MSK10MSa wXVw== X-Gm-Message-State: AOAM530M/voMsyeYi5KvblvTRtVmmfAg0w1/rwpkLsOdVUMHqDQ1CpRo oS30O+C8WNtjk7DkuU2WtXI= X-Google-Smtp-Source: ABdhPJyEwRrV2scBIT8jVnXYBE80tA2ka4XPswQoaXNSnqJHKL0EjP1povvUU2RYTeDhzG0l4p/unw== X-Received: by 2002:a1c:2002:: with SMTP id g2mr4545826wmg.132.1592495597447; Thu, 18 Jun 2020 08:53:17 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id b18sm3944314wrn.88.2020.06.18.08.53.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 08:53:16 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= , "'Tamas K Lengyel'" References: <20200618154628.GW735@Air-de-Roger> In-Reply-To: <20200618154628.GW735@Air-de-Roger> Subject: RE: [PATCH v3 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Date: Thu, 18 Jun 2020 16:53:15 +0100 Message-ID: <006801d64588$94d23040$be7690c0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHYIgYxVlP9Qzxyln81XR9BR28vqgI/b39iqMjRgGA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Kevin Tian' , 'Jun Nakajima' , 'Wei Liu' , 'Andrew Cooper' , 'Jan Beulich' , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monn=C3=A9 > Sent: 18 June 2020 16:46 > To: Tamas K Lengyel > Cc: xen-devel@lists.xenproject.org; Jun Nakajima = ; Kevin Tian > ; Jan Beulich ; Andrew Cooper = ; > Wei Liu ; Paul Durrant > Subject: Re: [PATCH v3 for-4.14] x86/vmx: use P2M_ALLOC in = vmx_load_pdptrs instead of P2M_UNSHARE >=20 > On Thu, Jun 18, 2020 at 07:39:04AM -0700, Tamas K Lengyel wrote: > > While forking VMs running a small RTOS system (Zephyr) a Xen crash = has been > > observed due to a mm-lock order violation while copying the HVM CPU = context > > from the parent. This issue has been identified to be due to > > hap_update_paging_modes first getting a lock on the gfn using = get_gfn. This > > call also creates a shared entry in the fork's memory map for the = cr3 gfn. The > > function later calls hap_update_cr3 while holding the paging_lock, = which > > results in the lock-order violation in vmx_load_pdptrs when it tries = to unshare > > the above entry when it grabs the page with the P2M_UNSHARE flag = set. > > > > Since vmx_load_pdptrs only reads from the page its usage of = P2M_UNSHARE was > > unnecessary to start with. Using P2M_ALLOC is the appropriate flag = to ensure > > the p2m is properly populated. > > > > Note that the lock order violation is avoided because before the = paging_lock is > > taken a lookup is performed with P2M_ALLOC that forks the page, thus = the second > > lookup in vmx_load_pdptrs succeeds without having to perform the = fork. We keep > > P2M_ALLOC in vmx_load_pdptrs because there are code-paths leading up = to it > > which don't take the paging_lock and that have no previous lookup. = Currently no > > other code-path exists leading there with the paging_lock taken, = thus no > > further adjustments are necessary. > > > > Signed-off-by: Tamas K Lengyel >=20 > Reviewed-by: Roger Pau Monn=C3=A9 >=20 Release-acked-by: Paul Durrant > Thanks! From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:56:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:56:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwu0-00029o-Qy; Thu, 18 Jun 2020 15:56:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwtz-00029i-T6 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:56:31 +0000 X-Inumbo-ID: 4545a222-b17c-11ea-bab2-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4545a222-b17c-11ea-bab2-12813bfff9fa; Thu, 18 Jun 2020 15:56:29 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: IF2lUxJiCLfeb+NMa0u2nWI+U9T1Cqi5ttIEA/BMekhF9lgo6tP9pa9rXzPWDL/GZrzem8+eW1 la+xNqD1+yRHRz4ygBLIavLDEbFvUBdinfpO5e2RFzTb8WMEza5D0MB9dsMJAZmegf/kxj5SJA 9r/cDXNndrO0T4JpdOMPeqOp6JHYZhOTrv/vpnDmufp9hEo4COGK/4wReZechVaZjZMbjwrEah 0HeqBtDe9QGC/Mqqb6v0Yvd09i5+VqfDuG46zevJrfgiwI+YJiSik3xhejJuVLF4jyIb23wXgq BmI= X-SBRS: 2.7 X-MesageID: 20401635 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20401635" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24299.36521.246994.731819@mariner.uk.xensource.com> Date: Thu, 18 Jun 2020 16:56:25 +0100 To: Paul Durrant Subject: Re: [XEN PATCH for-4.14 v1] stubdom/vtpm: add extern to function declarations In-Reply-To: <20200617134025.2tdrjxslnh66dmng@function> References: <20200617060841.7241-1-olaf@aepfle.de> <20200617134025.2tdrjxslnh66dmng@function> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Samuel Thibault , Olaf Hering , xen-devel , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Samuel Thibault writes ("Re: [PATCH v1] stubdom/vtpm: add extern to function declarations"): > Jason Andryuk, le mer. 17 juin 2020 09:35:52 -0400, a ecrit: > > On Wed, Jun 17, 2020 at 2:10 AM Olaf Hering wrote: > > > > > > Code compiled with gcc10 will not link properly due to multiple definition of the same function. > > > > > > Signed-off-by: Olaf Hering > > > > Reviewed-by: Jason Andryuk > > Acked-by: Samuel Thibault Reviewed-by: Ian Jackson Thanks. I have confirmed that these symbols look to be defined (in tpm/tpm_emulator_extern.c). So the patch is correct. I think this is 4.14 material. Paul ? We should also consider it for backports. How far back do we need to go ? Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 15:59:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 15:59:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwxA-0002JH-Al; Thu, 18 Jun 2020 15:59:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwx9-0002It-6R for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 15:59:47 +0000 X-Inumbo-ID: b7abf23a-b17c-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b7abf23a-b17c-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 15:59:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/m4hhAbYRXxVs/6BHbqMYZQbCYkRvIwnh8GF+JvC7LE=; b=231qTh29NXsevi9gFGWK+Y59N fXgL2WTl3E9XgNtZkESRj0lp90sUbOQjUB4prKYP+erD3BES6aAi2HztYlNWWu1F2WCBpJhnaDoDg gmLj4erAU0CWuErBOKz1RrZ9wFbdZZ7BjvwAP9GVQmbqgmx+9B4cPIkKt899A3rp+uAMc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwx1-0003kJ-OC; Thu, 18 Jun 2020 15:59:39 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlwx1-0000OF-DD; Thu, 18 Jun 2020 15:59:39 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlwx1-0007fF-Bi; Thu, 18 Jun 2020 15:59:39 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151181: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=3625b04991b4d6affadd99d377ab84bac48dfff4 X-Osstest-Versions-That: xen=b91825f628c9a62cf2a3a0d972ea81484a8b7fce From: osstest service owner Date: Thu, 18 Jun 2020 15:59:39 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151181 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151181/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 151155 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151155 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151155 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151155 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151155 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151155 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151155 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151155 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151155 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151155 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 3625b04991b4d6affadd99d377ab84bac48dfff4 baseline version: xen b91825f628c9a62cf2a3a0d972ea81484a8b7fce Last test of basis 151155 2020-06-15 17:20:09 Z 2 days Testing same since 151181 2020-06-17 06:01:52 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Bertrand Marquis George Dunlap Ian Jackson Jason Andryuk Nick Rosbrook Nick Rosbrook Tamas K Lengyel Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git b91825f628..3625b04991 3625b04991b4d6affadd99d377ab84bac48dfff4 -> master From xen-devel-bounces@lists.xenproject.org Thu Jun 18 16:00:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 16:00:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwxW-0003RX-L5; Thu, 18 Jun 2020 16:00:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwxV-0003RJ-5z for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 16:00:09 +0000 X-Inumbo-ID: c7f818c6-b17c-11ea-8496-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c7f818c6-b17c-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 16:00:08 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: NDAXoFPalvBpS5wXQFuB417IHjeB67cSo9X8ad1CfoZTJniq0JiGeYFHdr9dkQhV+g+v4SdrTj ApJtq9Eh9AmfJXdbOwbg45h6ZslONaOUT3RZB0Xwcbndi5mRQ5YF//s9CJmG1RnsgZIWs3V0aS QstuC8mCw4kA8U98tWUgECeh67dvqtuNim/vSh0H+D1nZx31toerLCcDSvaGkDjaeCPEZsufKO mabEmw8NPGahbINssD0JnEH85U3L/re0gT4ELYRN/QMflWlfCEw4KOwHQqvDcs2s4HeeA7qDMe +v0= X-SBRS: 2.7 X-MesageID: 20689301 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20689301" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24299.36738.827663.937330@mariner.uk.xensource.com> Date: Thu, 18 Jun 2020 17:00:02 +0100 To: "paul@xen.org" Subject: RE: [PATCH for-4.14] xl: Allow shutdown wait for domain death In-Reply-To: <006701d64588$768bf1c0$63a3d540$@xen.org> References: <20200617023642.80594-1-jandryuk@gmail.com> <24299.35750.218855.454255@mariner.uk.xensource.com> <006701d64588$768bf1c0$63a3d540$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , "xen-devel@lists.xenproject.org" , 'Wei Liu' , 'Paul Durrant' , 'Jason Andryuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: [PATCH for-4.14] xl: Allow shutdown wait for domain death"): > > -----Original Message----- > > From: Ian Jackson ... > > I have reviewed this patch particularly carefully with a view to > > understanding what happens if you pass just one `-w' as before. > > I have convinced myself that there is definitely no change, so I don't > > think this patch can introduce a regression. > > Ok, I'll trust your judgement. Thanks :-). Pushed. Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 16:01:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 16:01:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwyj-0003lh-AW; Thu, 18 Jun 2020 16:01:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwyi-0003lX-3z for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 16:01:24 +0000 X-Inumbo-ID: f4217802-b17c-11ea-bab3-12813bfff9fa Received: from mailout1.w1.samsung.com (unknown [210.118.77.11]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f4217802-b17c-11ea-bab3-12813bfff9fa; Thu, 18 Jun 2020 16:01:22 +0000 (UTC) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20200618160121euoutp01159e2df84a3ab07d785aca0be57a9b31~Zrr_r9jnA0233602336euoutp010 for ; Thu, 18 Jun 2020 16:01:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20200618160121euoutp01159e2df84a3ab07d785aca0be57a9b31~Zrr_r9jnA0233602336euoutp010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1592496081; bh=Q6nmdHxiLcADSmmOczfWQ1kCLD9EfF+zt7aqe3afHuk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FaM4R6h/1wQ2+FHQCJnS7+FathW2IZKJjpwutCurOEg6h45s7KLfV7Gpv51DBCUup J7rCIfYl4j/tVGm0/T1Xyaf7YJXYSpd8kl9PaWTVA0yImIhugXhe481W8IxYVS49g9 xmbuS//EvQcHWZjeWKifhd7Ag7HEsXetzGhrbmEU= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20200618160121eucas1p25152fd9c21e6f800fe9f095d79056daa~Zrr_Wk0ia2423724237eucas1p2B; Thu, 18 Jun 2020 16:01:21 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id 5A.52.60698.1DF8BEE5; Thu, 18 Jun 2020 17:01:21 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p2.samsung.com (KnoxPortal) with ESMTPA id 20200618160120eucas1p20b771c3b6dc06549c7f4a4d569c3e0ec~Zrr98WwZc1444214442eucas1p2T; Thu, 18 Jun 2020 16:01:20 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20200618160120eusmtrp19b1f7bc59472a1a799da9bbde8edea03~Zrr97nA460376803768eusmtrp1W; Thu, 18 Jun 2020 16:01:20 +0000 (GMT) X-AuditID: cbfec7f5-a29ff7000001ed1a-8e-5eeb8fd1154a Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id B4.E0.08375.0DF8BEE5; Thu, 18 Jun 2020 17:01:20 +0100 (BST) Received: from AMDC2765.digital.local (unknown [106.120.51.73]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20200618160119eusmtip2b6913e0a93ea45b7293f1adb592e0866~Zrr9SQydu3011030110eusmtip21; Thu, 18 Jun 2020 16:01:19 +0000 (GMT) From: Marek Szyprowski To: dri-devel@lists.freedesktop.org, iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org Subject: [PATCH v6 36/36] drm: xen: fix common struct sg_table related issues Date: Thu, 18 Jun 2020 18:01:11 +0200 Message-Id: <20200618160111.3045-1-m.szyprowski@samsung.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200618153956.29558-1-m.szyprowski@samsung.com> X-Brightmail-Tracker: H4sIAAAAAAAAA0VSe0hTURzm7O5uV3Nym8IOKgoLgwQ1M9YFH1go3b+0PwIha7rypqKbsunK CvKRj5aPfKGZ1Qxf+X6smZqllm6yWpoPtAw1g3w0lJzTLDS3a/bf932/7zvfOT8OhnBfog5Y jCSRkkpEcXyWNVM99EvvPpq/Ijyu2kKJXP0wg2gra0GJXXUBQoxvrLKIZw2DDEL52ocwjs8z iPaFSZQY665gEU1vv7CJtYZVlOhf+4YSm6oiRgCHbHzcCMiZ6i5A9pqUTLLTNIeSs/c0DLKj 6jb5eWcBIYumagH5Zm2cSfZMp7DIPFU9INfbnc/ZXLD2jaTiYuSU1NM/wjq6V5HFSMizvV46 mg5SgOGQAmAYxE/Cd/VBCmCNcfE6AOc3qtg0MQKYP6hk0WQdwK9LKXvEypLo/D0F6EEtgN+7 PjAPIj/qjYjZxcK9oMKgsCTs8QwAtbk2ZhOCbzGgvkbLNg/s8BCYWlJnCTBxV1ij1FkwB/eF LTMrKF3nAhta+yy6Fe4PdZoM1HwQxPVsmKldQmhTIOxcN7FpbAeXNap97AR1RTlMOpC+9zx9 E5smOQCOpZUB2uUDZ/TbLPM+EPwYbOn2pOXTsHioD6XXZAunDIfNMrIHC9WlCC1zYHYml3Yf heWa5oPa/pGP+1cjobaydH+pBQAaFidZ94FL+f8yJQD1gEclycRRlMxbQl3zkInEsiRJlMeV eHE72PtTuh3Nxgvw6s/lAYBjgG/DWTy/IuSiIrksWTwAIIbw7Tln3uuEXE6kKPkGJY0PlybF UbIB4Igx+TyO99OlS1w8SpRIxVJUAiX9N2VgVg4pICIQGAOC56Sb7md9gyrzhKkNwlO7bab+ R/JbMcHO8k9d2ppQTmx/XLzT8JGb8rCHjuH5RE/qT9OD6cxWQUsejwirdK14oveLHLnTszzh 1pw9LxE8LRS0dcwuq65GxyanPbe7q145kbo25BfCq1ZOFWQ184p3xKG9E9uCkovhlXymLFrk 5YZIZaK/qYRK+08DAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsVy+t/xe7oX+l/HGeyYpGbRe+4kk8XGGetZ Lf5vm8hsceXrezaLlauPMlks2G9t8eXKQyaLTY+vsVpc3jWHzWLtkbvsFh9Wv2e1OPjhCavF 9y2TmRx4PdbMW8PocWfpTkaPvd8WsHhs//aA1eN+93Emj81L6j1u/3vM7DH5xnJGj8MfrrB4 7L7ZwObRt2UVo8fnTXIBPFF6NkX5pSWpChn5xSW2StGGFkZ6hpYWekYmlnqGxuaxVkamSvp2 NimpOZllqUX6dgl6GXu72pkK+vgqpl9sZmxgfMvdxcjJISFgIrH99w3GLkYuDiGBpYwSt5c1 sEMkZCROTmtghbCFJf5c62KDKPrEKPHt7iYmkASbgKFE11uIhIhAJ6PEtO6P7CAOs8A/JokT e7eDVQkL+Eocf7iXDcRmEVCVWLbgNDOIzStgI7H+zmuoFfISqzccAItzCthJnD7eChYXErCV eP6hjW0CI98CRoZVjCKppcW56bnFhnrFibnFpXnpesn5uZsYgXGz7djPzTsYL20MPsQowMGo xMP7IuR1nBBrYllxZe4hRgkOZiURXqezp+OEeFMSK6tSi/Lji0pzUosPMZoCHTWRWUo0OR8Y 03kl8YamhuYWlobmxubGZhZK4rwdAgdjhATSE0tSs1NTC1KLYPqYODilGhjbVuhEzl6UNU/i eVq+64SElclV7bJ3Tc+FbT302Gmj5pdNVZMWxnnM1GZQS9qTyyGvEbT84ctn70XF3Kdv7w6t eXWAb1t1TMrcDsfgtwvLvlx+qJwk/kDq7fs3T95/v6cY7mZef3vDTRmp4AlTj7a8EwlL/fmS 71BQFp9t6wdTQWWbmLrqy5OVWIozEg21mIuKEwG7wX5nsQIAAA== X-CMS-MailID: 20200618160120eucas1p20b771c3b6dc06549c7f4a4d569c3e0ec X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200618160120eucas1p20b771c3b6dc06549c7f4a4d569c3e0ec X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200618160120eucas1p20b771c3b6dc06549c7f4a4d569c3e0ec References: <20200618153956.29558-1-m.szyprowski@samsung.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Bartlomiej Zolnierkiewicz , David Airlie , Oleksandr Andrushchenko , Daniel Vetter , xen-devel@lists.xenproject.org, Robin Murphy , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, Marek Szyprowski Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_map_sg(). struct sg_table is a common structure used for describing a non-contiguous memory buffer, used commonly in the DRM and graphics subsystems. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA mapped pages (nents entry). It turned out that it was a common mistake to misuse nents and orig_nents entries, calling DMA-mapping functions with a wrong number of entries or ignoring the number of mapped entries returned by the dma_map_sg() function. Fix the code to refer to proper nents or orig_nents entries. This driver reports the number of the pages in the imported scatterlist, so it should refer to sg_table->orig_nents entry. Signed-off-by: Marek Szyprowski Acked-by: Oleksandr Andrushchenko --- drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c b/drivers/gpu/drm/xen/xen_drm_front_gem.c index f0b85e094111..ba4bdc5590ea 100644 --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c @@ -215,7 +215,7 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev, return ERR_PTR(ret); DRM_DEBUG("Imported buffer of size %zu with nents %u\n", - size, sgt->nents); + size, sgt->orig_nents); return &xen_obj->base; } -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 16:01:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 16:01:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwz9-0003q3-OZ; Thu, 18 Jun 2020 16:01:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlwz8-0003pj-7h for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 16:01:50 +0000 X-Inumbo-ID: 0479602a-b17d-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x436.google.com (unknown [2a00:1450:4864:20::436]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0479602a-b17d-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 16:01:49 +0000 (UTC) Received: by mail-wr1-x436.google.com with SMTP id q2so4186659wrv.8 for ; Thu, 18 Jun 2020 09:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=fYe3LoFUceqMJwwcKHTwyFS5p3TKF8kVHKKkDzRMsFU=; b=qQOHKOpI/WBha+qg4XrmxITIaC3ckHMZUGqFdziGhWJ8vpEaaBuhDtwvE0ffySqV7u 9R4o99h16dCHghxphnjoSb2Ya7nfnzhTrjSlLjjJRxj+mcn9vNcyPaBlP6BdyhYpVM4a aSV0Ds+wQfR031awI9mGOIVQyrBneZB1+ZBBzdktmSJcTD/KixTPVPjMK+chf7iGhcsj OXuE8KtBOpfFOI7dpRvJYtCQ3J7Xl98sbnBxe5R8cTTd46mh/UIExUtolqXJ+QCPC3QX LZWm5Yx7ONFlXbYAwWhsD0KfWsbbYML63KEqYFaWC0+OJgzLBpggRj7MikxcXn4qBCxp ZVuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=fYe3LoFUceqMJwwcKHTwyFS5p3TKF8kVHKKkDzRMsFU=; b=sdmLP8DkDWGRcojAdW8GegTD11evyoLIPMmHDIiSOf3YMX0nf0NMBNLarPbiKwaQ5K Coi2taiabDf1aDyLaDGLGED62gQ4bAwpmYfSGYWQZIu+q7K/sISi/06GpD9iLN8apLla IIQzD/ugR9b2hDCEaGBj/Z9x9oIaboajwPZj6tBkqrA08PpZ9nyrRkKSDBj0Dpi0lk29 gMLgDprZZElVhzr4g+l3/LKAIhrMxTP+oAbc7HJgxK1Q6fkqTMIST+ngwXjb5V5r50dT XoJjuZuqYFjjcGwRYnkkH1bQEf3SHruEbyW38OAv7CymGy4fpX17hXkRV8o3Hy/wZO6Y xlAA== X-Gm-Message-State: AOAM530RQoidU2qtqwCgOHYL+p6fQEmcSl9XDZ8Wr/IoPf/2vraGW7nO ifcAX6DqqFQVUikOPHd6VJw= X-Google-Smtp-Source: ABdhPJzk8LQUJOSuRcE11JXMS40YUYyeRp83+bAz9LIB3hos/f0ydGeNJrLtcNFXjcN2Ln4mbzbmbA== X-Received: by 2002:a5d:66c3:: with SMTP id k3mr5228904wrw.401.1592496108917; Thu, 18 Jun 2020 09:01:48 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id d11sm4223536wrm.64.2020.06.18.09.01.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 09:01:48 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Paul Durrant'" References: <20200617060841.7241-1-olaf@aepfle.de> <20200617134025.2tdrjxslnh66dmng@function> <24299.36521.246994.731819@mariner.uk.xensource.com> In-Reply-To: <24299.36521.246994.731819@mariner.uk.xensource.com> Subject: RE: [XEN PATCH for-4.14 v1] stubdom/vtpm: add extern to function declarations Date: Thu, 18 Jun 2020 17:01:46 +0100 Message-ID: <006901d64589$c593c440$50bb4cc0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIv4nHnfBuTNWH2eRSm761nFo0E0wJ3IkteAgwDO1EB4kHQg6f4IwYw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Samuel Thibault' , 'Olaf Hering' , 'xen-devel' , 'Wei Liu' , 'Jason Andryuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 18 June 2020 16:56 > To: Paul Durrant > Cc: Samuel Thibault ; Jason Andryuk ; Olaf Hering > ; xen-devel ; Wei Liu > Subject: Re: [XEN PATCH for-4.14 v1] stubdom/vtpm: add extern to function declarations > > Samuel Thibault writes ("Re: [PATCH v1] stubdom/vtpm: add extern to function declarations"): > > Jason Andryuk, le mer. 17 juin 2020 09:35:52 -0400, a ecrit: > > > On Wed, Jun 17, 2020 at 2:10 AM Olaf Hering wrote: > > > > > > > > Code compiled with gcc10 will not link properly due to multiple definition of the same function. > > > > > > > > Signed-off-by: Olaf Hering > > > > > > Reviewed-by: Jason Andryuk > > > > Acked-by: Samuel Thibault > > Reviewed-by: Ian Jackson > > Thanks. I have confirmed that these symbols look to be defined (in > tpm/tpm_emulator_extern.c). So the patch is correct. > > I think this is 4.14 material. Paul ? Agreed. Release-acked-by: Paul Durrant > > We should also consider it for backports. How far back do we need > to go ? > > Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 16:04:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 16:04:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlx1Z-00042K-5n; Thu, 18 Jun 2020 16:04:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlx1X-00042D-Ac for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 16:04:19 +0000 X-Inumbo-ID: 5c3de826-b17d-11ea-bab3-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5c3de826-b17d-11ea-bab3-12813bfff9fa; Thu, 18 Jun 2020 16:04:16 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: tzvRTewNofvhfiPxTGCJNfeG0dDxnhB/rgCyeCmChpF4gw5vhgIeWeblUHzWdizrIQb8HSypUh tM8S0HnT/fK5Qu4LnZIrCXILThjEso64ra9hHZKjq5LceA871Lb37LzhlgooSeynRPPj78IIZM mZdxRACPyWQKRWWNsZCakvx5G87MxY3BlAL8TIfiMQpTiWRylxFzU79hB5Oa7kW8iLAptJzj/k Yrl4qgEEa5eZWy1H4hq3ca5y+hVuB48PjtcffyoSaSlCbAEWS5jJgCT046YigveeEmVhXaV778 KKw= X-SBRS: 2.7 X-MesageID: 20734531 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20734531" From: Roger Pau Monne To: Subject: [PATCH for-4.14] x86/tlb: fix assisted flush usage Date: Thu, 18 Jun 2020 18:04:03 +0200 Message-ID: <20200618160403.35199-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Volodymyr Babchuk , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Commit e9aca9470ed86 introduced a regression when avoiding sending IPIs for certain flush operations. Xen page fault handler (spurious_page_fault) relies on blocking interrupts in order to prevent handling TLB flush IPIs and thus preventing other CPUs from removing page tables pages. Switching to assisted flushing avoided such IPIs, and thus can result in pages belonging to the page tables being removed (and possibly re-used) while __page_fault_type is being executed. Force some of the TLB flushes to use IPIs, thus avoiding the assisted TLB flush. Those selected flushes are the page type change (when switching from a page table type to a different one, ie: a page that has been removed as a page table) and page allocation. This sadly has a negative performance impact on the pvshim, as less assisted flushes can be used. Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush using an IPI (flush_tlb_mask_sync). Note that the flag is only meaningfully defined when the hypervisor supports PV mode, as otherwise translated domains are in charge of their page tables and won't share page tables with Xen, thus not influencing the result of page walks performed by the spurious fault handler. Note the flag is not defined on Arm, and the introduced helper is just a dummy alias to the existing flush_tlb_mask. Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') Reported-by: Andrew Cooper Signed-off-by: Roger Pau Monné --- It's my understanding that not doing such IPI flushes could lead to the pages tables being read by __page_fault_type being modified by a third party, which could make them point to other mfns out of the scope of the guest allowed physical memory addresses. However those accesses would be limited to __page_fault_type, and hence the main worry would be that a guest could make it point to read from a physical memory region that has side effects? Given that pvshim doesn't support passthrough devices, I'm not aware of any such region being part of the physmap in the specific pvshim case, so I wonder if it would be fine to remove the restriction for the pvshim only case? --- xen/arch/x86/mm.c | 12 +++++++++++- xen/common/memory.c | 2 +- xen/common/page_alloc.c | 2 +- xen/include/asm-arm/flushtlb.h | 1 + xen/include/asm-x86/flushtlb.h | 14 ++++++++++++++ xen/include/xen/mm.h | 8 ++++++-- 6 files changed, 34 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index c294092f93..0be6b38769 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2894,7 +2894,17 @@ static int _get_page_type(struct page_info *page, unsigned long type, ((nx & PGT_type_mask) == PGT_writable_page)) ) { perfc_incr(need_flush_tlb_flush); - flush_tlb_mask(mask); + if ( (x & PGT_type_mask) && + (x & PGT_type_mask) <= PGT_l4_page_table ) + /* + * If page was a page table make sure the flush is + * performed using an IPI in order to avoid changing + * the type of a page table page under the feet of + * spurious_page_fault. + */ + flush_tlb_mask_sync(mask); + else + flush_tlb_mask(mask); } /* We lose existing type and validity. */ diff --git a/xen/common/memory.c b/xen/common/memory.c index 714077c1e5..0d224d6675 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -278,7 +278,7 @@ static void populate_physmap(struct memop_args *a) out: if ( need_tlbflush ) - filtered_flush_tlb_mask(tlbflush_timestamp); + filtered_flush_tlb_mask(tlbflush_timestamp, false); if ( a->memflags & MEMF_no_icache_flush ) invalidate_icache(); diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 10b7aeca48..765f8d8e78 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1060,7 +1060,7 @@ static struct page_info *alloc_heap_pages( } if ( need_tlbflush ) - filtered_flush_tlb_mask(tlbflush_timestamp); + filtered_flush_tlb_mask(tlbflush_timestamp, true); return pg; } diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h index ab1aae5c90..7ae0543885 100644 --- a/xen/include/asm-arm/flushtlb.h +++ b/xen/include/asm-arm/flushtlb.h @@ -27,6 +27,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) /* Flush specified CPUs' TLBs */ void flush_tlb_mask(const cpumask_t *mask); +#define flush_tlb_mask_sync flush_tlb_mask /* * Flush a range of VA's hypervisor mappings from the TLB of the local diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h index 8639427cce..3650a822ac 100644 --- a/xen/include/asm-x86/flushtlb.h +++ b/xen/include/asm-x86/flushtlb.h @@ -126,6 +126,12 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4); #else #define FLUSH_HVM_ASID_CORE 0 #endif +#if CONFIG_PV +/* Force an IPI to be sent */ +# define FLUSH_FORCE_IPI 0x8000 +#else +# define FLUSH_FORCE_IPI 0 +#endif /* Flush local TLBs/caches. */ unsigned int flush_area_local(const void *va, unsigned int flags); @@ -148,6 +154,14 @@ void flush_area_mask(const cpumask_t *, const void *va, unsigned int flags); /* Flush specified CPUs' TLBs */ #define flush_tlb_mask(mask) \ flush_mask(mask, FLUSH_TLB) +/* + * Flush specified CPUs' TLBs and force the usage of an IPI to do so. This is + * required for certain operations that rely on page tables themselves not + * being freed and reused when interrupts are blocked, as the flush IPI won't + * be fulfilled until exiting from that critical region. + */ +#define flush_tlb_mask_sync(mask) \ + flush_mask(mask, FLUSH_TLB | FLUSH_FORCE_IPI) #define flush_tlb_one_mask(mask,v) \ flush_area_mask(mask, (const void *)(v), FLUSH_TLB|FLUSH_ORDER(0)) diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 9b62087be1..f360166f00 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -639,7 +639,8 @@ static inline void accumulate_tlbflush(bool *need_tlbflush, } } -static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) +static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp, + bool sync) { cpumask_t mask; @@ -648,7 +649,10 @@ static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) if ( !cpumask_empty(&mask) ) { perfc_incr(need_flush_tlb_flush); - flush_tlb_mask(&mask); + if ( sync ) + flush_tlb_mask_sync(&mask); + else + flush_tlb_mask(&mask); } } -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 16:05:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 16:05:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlx2Y-00047E-Gn; Thu, 18 Jun 2020 16:05:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlx2Y-000478-98 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 16:05:22 +0000 X-Inumbo-ID: 82bfcb04-b17d-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 82bfcb04-b17d-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 16:05:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B8121ADC9; Thu, 18 Jun 2020 16:05:19 +0000 (UTC) Subject: Re: [PATCH for-4.14 8/8] x86/hvm: enable emulated PIT for PVH dom0 To: Roger Pau Monne References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-9-roger.pau@citrix.com> From: Jan Beulich Message-ID: <88a91a26-1ad8-bf85-d55e-4fc29afaf554@suse.com> Date: Thu, 18 Jun 2020 18:05:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200612155640.4101-9-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, paul@xen.org, Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 12.06.2020 17:56, Roger Pau Monne wrote: > Some video BIOS require a PIT in order to work properly, hence classic > PV dom0 gets partial access to the physical PIT as long as it's not in > use by Xen. > > Since PVH dom0 is built on top of HVM support, there's already an > emulated PIT implementation available for use. Tweak the emulated PIT > code so it injects interrupts directly into the vIO-APIC if the legacy > PIC (i8259) is disabled. Make sure the GSI used matches the ISA IRQ 0 > in the likely case there's an interrupt overwrite in the MADT ACPI Same nit again as for the earlier patch (also applicable to a code comment below). > @@ -578,7 +579,7 @@ int arch_domain_create(struct domain *d, > > emflags = config->arch.emulation_flags; > > - if ( is_hardware_domain(d) && is_pv_domain(d) ) > + if ( is_hardware_domain(d) ) > emflags |= XEN_X86_EMU_PIT; Wouldn't this better go into create_dom0(), where all the other flags get set? Or otherwise all of that be moved here (to cover the late-hwdom case)? > --- a/xen/arch/x86/emul-i8254.c > +++ b/xen/arch/x86/emul-i8254.c > @@ -168,6 +168,7 @@ static void pit_load_count(PITState *pit, int channel, int val) > u32 period; > struct hvm_hw_pit_channel *s = &pit->hw.channels[channel]; > struct vcpu *v = vpit_vcpu(pit); > + const struct domain *d = v ? v->domain : NULL; I think this local variable would better be omitted - its initializer may raise questions, while at its use sites v can't be NULL afaict. Plus it's not needed ... > @@ -190,14 +191,18 @@ static void pit_load_count(PITState *pit, int channel, int val) > case 3: > /* Periodic timer. */ > TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, period); > - create_periodic_time(v, &pit->pt0, period, period, 0, pit_time_fired, > + create_periodic_time(v, &pit->pt0, period, period, > + has_vpic(d) ? 0 : hvm_isa_irq_to_gsi(d, 0), > + pit_time_fired, > &pit->count_load_time[channel], false); > break; > case 1: > case 4: > /* One-shot timer. */ > TRACE_2D(TRC_HVM_EMUL_PIT_START_TIMER, period, 0); > - create_periodic_time(v, &pit->pt0, period, 0, 0, pit_time_fired, > + create_periodic_time(v, &pit->pt0, period, 0, > + has_vpic(d) ? 0 : hvm_isa_irq_to_gsi(d, 0), > + pit_time_fired, > &pit->count_load_time[channel], false); > break; > default: ... on this path. > --- a/xen/arch/x86/hvm/vioapic.c > +++ b/xen/arch/x86/hvm/vioapic.c > @@ -268,7 +268,14 @@ static void vioapic_write_redirent( > > spin_unlock(&d->arch.hvm.irq_lock); > > - if ( is_hardware_domain(d) && unmasked ) > + if ( is_hardware_domain(d) && unmasked && > + /* > + * A PVH dom0 can have an emulated PIT that should respect any > + * interrupt overwrites found in the ACPI MADT table, so we need to > + * check to which GSI the ISA IRQ 0 is mapped in order to prevent > + * identity mapping it. > + */ > + (!has_vpit(d) || gsi != hvm_isa_irq_to_gsi(d, 0)) ) Isn't has_vpit() true now for Dom0, and hence that part of the condition is kind of pointless? And shouldn't Dom0 never have seen physical IRQ 0 in the first place (we don't allow PV Dom0 to use that IRQ either, after all)? Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 18 16:06:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 16:06:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlx3F-0004Cb-Q3; Thu, 18 Jun 2020 16:06:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlx3E-0004BQ-QL for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 16:06:04 +0000 X-Inumbo-ID: 9b483c42-b17d-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9b483c42-b17d-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 16:06:02 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Hl0G3fsw5f+xJIThZPjqGLn0DtiChGDUUw9SiCEejxDWYA+0BlPSeHrMYkSKthx5oDbhEROmX6 8yFNS2qyCwgxlAFsAilmg0uXLkWnJXUoB/xOg4JQnyv3bmHr/j39DNU3NfxJY9/tvVOw+oblop VLMYS9JQQck2sKWivv5JPSX1uBsMHe5YM4A4eEfrI//RtCv39dnDYwvyRSogHUEIKNt4X3gbv2 lUlMM7Vj/1jkf62D/VFRP1SiK8Ne6df2lWKcXmexL6QvuEOrsjxJtXgXjP3bPWZHlKU/TKIRIW oNA= X-SBRS: 2.7 X-MesageID: 20389157 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20389157" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24299.37089.975405.523661@mariner.uk.xensource.com> Date: Thu, 18 Jun 2020 17:05:53 +0100 To: "paul@xen.org" Subject: RE: [XEN PATCH for-4.14 v1] stubdom/vtpm: add extern to function declarations In-Reply-To: <006901d64589$c593c440$50bb4cc0$@xen.org> References: <20200617060841.7241-1-olaf@aepfle.de> <20200617134025.2tdrjxslnh66dmng@function> <24299.36521.246994.731819@mariner.uk.xensource.com> <006901d64589$c593c440$50bb4cc0$@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Olaf Hering' , 'Wei Liu' , 'Jason Andryuk' , 'Paul Durrant' , 'xen-devel' , 'Samuel Thibault' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("RE: [XEN PATCH for-4.14 v1] stubdom/vtpm: add extern to function declarations"): > > -----Original Message----- > > From: Ian Jackson ... > > I think this is 4.14 material. Paul ? > > Agreed. > > Release-acked-by: Paul Durrant Thanks, pushed. Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 16:23:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 16:23:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlxK8-0005t3-CL; Thu, 18 Jun 2020 16:23:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlxK7-0005sy-7f for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 16:23:31 +0000 X-Inumbo-ID: 0b74dd34-b180-11ea-babb-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0b74dd34-b180-11ea-babb-12813bfff9fa; Thu, 18 Jun 2020 16:23:30 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 08509A31E1; Thu, 18 Jun 2020 18:23:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id F2373A1E22; Thu, 18 Jun 2020 18:23:27 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id t_SUwrxZQpDC; Thu, 18 Jun 2020 18:23:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 8D2BCA31E1; Thu, 18 Jun 2020 18:23:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ykPHM6-kYoqo; Thu, 18 Jun 2020 18:23:27 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 6BE59A1E22; Thu, 18 Jun 2020 18:23:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 5BF4D20981; Thu, 18 Jun 2020 18:22:57 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id bHSnnSqrvzd7; Thu, 18 Jun 2020 18:22:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id EDE8821698; Thu, 18 Jun 2020 18:22:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4TBmn3T2BaKb; Thu, 18 Jun 2020 18:22:51 +0200 (CEST) Received: from arnold.localdomain (unknown [195.187.238.48]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 7D5EF20981; Thu, 18 Jun 2020 18:22:51 +0200 (CEST) From: Hubert Jasudowicz To: xen-devel@lists.xenproject.org Subject: [PATCH] x86/cpuid: Expose number of vCPUs in CPUID.1.EBX Date: Thu, 18 Jun 2020 18:22:33 +0200 Message-Id: X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Wei Liu , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" When running under KVM (or presumably other hypervisors) we enable the CPUID.1.EDX.HTT flag, thus indicating validity of CPUID.1.EBX[23:16] - maximum number of logical processors which the guest reads as 0. Although this method of topology detection is considered legacy, Windows falls back to it when CPUID.0BH.EBX is 0. CPUID.1.EBX[23:16] being equal to 0, triggers memory corruption in ntoskrnl.exe as Windows assumes that number of logical processors would be at least 1. Memory corruption manifests itself while mapping framebuffer for early graphical subsystem, causing BSOD. This patch fixes running nested Windows (tested on 7 and 10) with KVM as L0 hypervisor, by setting the value to maximum number of vCPUs in domain. Signed-off-by: Hubert Jasudowicz --- xen/arch/x86/cpuid.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c index ee11087626..bf38398ef3 100644 --- a/xen/arch/x86/cpuid.c +++ b/xen/arch/x86/cpuid.c @@ -811,10 +811,12 @@ void guest_cpuid(const struct vcpu *v, uint32_t lea= f, =20 case 0x1: /* TODO: Rework topology logic. */ - res->b &=3D 0x00ffffffu; + res->b &=3D 0x0000ffffu; if ( is_hvm_domain(d) ) res->b |=3D (v->vcpu_id * 2) << 24; =20 + res->b |=3D (d->max_vcpus & 0xff) << 16; + /* TODO: Rework vPMU control in terms of toolstack choices. */ if ( vpmu_available(v) && vpmu_is_set(vcpu_vpmu(v), VPMU_CPU_HAS_DS) ) --=20 2.27.0 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 16:49:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 16:49:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlxiw-0007g9-DA; Thu, 18 Jun 2020 16:49:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlxiu-0007g4-Od for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 16:49:08 +0000 X-Inumbo-ID: a0289058-b183-11ea-bb8b-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a0289058-b183-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 16:49:07 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Zr+m9GWFRCHyYgtlCuEKnE2kRxikAl8R4vqWx98h+7Z9U/KSoQVb+Vk4L2eVXIBW5Ea1NuJxFt WXioX74NbCpLmEZVH1lY34pt+HHRxXMnsgrzls8nkUrQ6ySyAkGwTxAhIRMf9iGjHjdY9Mag8z UF2PQrIeAOWxzoQFenJyGLDOP8TCGt5JiVjJMT99rcAkgeravj8v0GPVcz4Ql+TaXo3GIel/1I WAOx6lVHJChQwVCUD6xOfmoHsV18UfJTjeza9xsAH8jqeGE5XluhBL52xpQPrUVvxAzk4YcX8b /Ts= X-SBRS: 2.7 X-MesageID: 20694624 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20694624" Date: Thu, 18 Jun 2020 17:48:57 +0100 From: Anthony PERARD To: Ian Jackson Subject: Re: [XEN PATCH for-4.14 2/2] tools: Commit flex (2.6.4) & bison (3.3.2) output from Debian buster Message-ID: <20200618164857.GA2099@perard.uk.xensource.com> References: <000401d640c9$7b14e760$713eb620$@xen.org> <20200612151931.1083-3-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200612151931.1083-3-ian.jackson@eu.citrix.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 12, 2020 at 04:19:31PM +0100, Ian Jackson wrote: > These files are in tree so that people can build (including from git) > without needing less-than-a-decade-old flex and bison. > > We should update them periodically. Debian buster has been Debian > stable for a while. Our CI is running buster. > > There should be no significant functional change; it's possible that > there are bugfixes but I have not reviewed the changes. I *have* > checked that the flex I am using has the fix for CVE-2016-6354. > > CC: Paul Durrant > CC: Andrew Cooper > Signed-off-by: Ian Jackson Acked-by: Anthony PERARD -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Thu Jun 18 16:51:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 16:51:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlxlN-0008Rr-U1; Thu, 18 Jun 2020 16:51:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlxlM-0008Rl-E0 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 16:51:40 +0000 X-Inumbo-ID: fab7c282-b183-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fab7c282-b183-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 16:51:39 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: f1riQasH8QZqtsOlROjpTqsXBW2rrs/N96EWdeBNYx49E9591RdHGoYYVog2fay6LCLS5d9gou RbvX4DQrtwUYGD3RXZFeyY0DGdYL77Jb81CVRKjhTRV31eBYO80mb63EKu/EtzygiNhumJSBc6 U59lIoZkq/s/vUkSp91nfLUTAK5vxE9X4vGHL6K9OcXfd6qhTOe027j4fBYOpHkF8Ynf9pfl3c B05GhE0//ypY/2qo6fXAscrcpixmvgRHYkhLthyhn4X5ZqIkUdHn8kheTe6kuY9FNO4Eb7l9wm ljE= X-SBRS: 2.7 X-MesageID: 20394136 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20394136" Subject: Re: [PATCH] x86/cpuid: Expose number of vCPUs in CPUID.1.EBX To: Hubert Jasudowicz , References: From: Andrew Cooper Message-ID: Date: Thu, 18 Jun 2020 17:51:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18/06/2020 17:22, Hubert Jasudowicz wrote: > When running under KVM (or presumably other hypervisors) we enable > the CPUID.1.EDX.HTT flag, thus indicating validity of CPUID.1.EBX[23:16] > - maximum number of logical processors which the guest reads as 0. > > Although this method of topology detection is considered legacy, > Windows falls back to it when CPUID.0BH.EBX is 0. > > CPUID.1.EBX[23:16] being equal to 0, triggers memory corruption in > ntoskrnl.exe as Windows assumes that number of logical processors would > be at least 1. Memory corruption manifests itself while mapping > framebuffer for early graphical subsystem, causing BSOD. > > This patch fixes running nested Windows (tested on 7 and 10) with KVM as > L0 hypervisor, by setting the value to maximum number of vCPUs in domain. > > Signed-off-by: Hubert Jasudowicz I'm afraid fixing guest topology is more complicated than just this.  On its own, I'm not sure if this is safe for VMs migrating in. While I agree that Xen's logic is definitely broken, I suspect the conditions for the BSOD are more complicated than this, because Windows does work fine when there is no KVM in the setup described. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 18 17:14:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 17:14:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jly7L-0001n8-MW; Thu, 18 Jun 2020 17:14:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jly7J-0001n3-Ry for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 17:14:21 +0000 X-Inumbo-ID: 25fd2b64-b187-11ea-baca-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 25fd2b64-b187-11ea-baca-12813bfff9fa; Thu, 18 Jun 2020 17:14:21 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: JASF7GRpPBs5Fl0DMNvb7Ros0btKZ8MgjHCh1B7bYGZ0Y0cCo3zQtboY7NEB0wun3teXdb9Tzg WX7KWP9hT/MUJpXFsP9fETYJsJcWdegI72h3Vi6YqJesuGbPsE95G4FHSBdIIAV2kQbXz8997W TN2O7dt0bco3irdsWmzY5IFn0dLi2/mE6s/xbhmX36k1mFBA2PGKQDaEFkQpa1BKTCUuuBrpZx V1pY5oJG0uE0OJ2Ui24LWqhDr8Ntysvyb+wV0bSfowVMvpSzWac1a1pq0FhelShzlQG1/3Ko4N xfU= X-SBRS: 2.7 X-MesageID: 20396566 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,251,1589256000"; d="scan'208";a="20396566" Date: Thu, 18 Jun 2020 19:14:13 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 6/8] x86/vpt: fix injection to remote vCPU Message-ID: <20200618171413.GX735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-7-roger.pau@citrix.com> <57b6f9fd-4cbc-abc9-09e3-6493eba6c377@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <57b6f9fd-4cbc-abc9-09e3-6493eba6c377@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 05:12:17PM +0200, Jan Beulich wrote: > On 12.06.2020 17:56, Roger Pau Monne wrote: > > vpt timers are usually added to the per-vCPU list of the vCPU where > > they get setup, but depending on the timer source type that vCPU might > > be different than the one where the interrupt vector gets injected. > > > > For example the PIT timer use a PIC or IO-APIC pin in order to select > > the destination vCPU and vector, which might not match the vCPU they > > are configured from. > > > > If such a situation happens pt_intr_post won't be called, and thus the > > vpt will be left in a limbo where the next interrupt won't be > > scheduled. Fix this by generalizing the special handling done to > > IO-APIC level interrupts to be applied always when the destination > > vCPU of the injected vector is different from the vCPU where the vpt > > belongs to (ie: usually the one it's been configured from). > > > > A further improvement as noted in a comment added to the code might be > > to move the vpt so it's handled by the same vCPU where the vector gets > > injected. > > > > Signed-off-by: Roger Pau Monné > > --- > > xen/arch/x86/hvm/vpt.c | 80 +++++++++++++++++++++--------------------- > > 1 file changed, 40 insertions(+), 40 deletions(-) > > > > diff --git a/xen/arch/x86/hvm/vpt.c b/xen/arch/x86/hvm/vpt.c > > index 6a975fc668..52ad5b90a7 100644 > > --- a/xen/arch/x86/hvm/vpt.c > > +++ b/xen/arch/x86/hvm/vpt.c > > @@ -358,59 +358,59 @@ int pt_update_irq(struct vcpu *v) > > * interrupt delivery case. Otherwise return -1 to do nothing. > > */ > > vlapic_set_irq(vcpu_vlapic(v), irq, 0); > > - pt_vector = irq; > > - break; > > + return irq; > > > > case PTSRC_isa: > > hvm_isa_irq_deassert(v->domain, irq); > > if ( platform_legacy_irq(irq) && vlapic_accept_pic_intr(v) && > > v->domain->arch.hvm.vpic[irq >> 3].int_output ) > > - hvm_isa_irq_assert(v->domain, irq, NULL); > > + pt_vector = hvm_isa_irq_assert(v->domain, irq, NULL); > > else > > - { > > pt_vector = hvm_isa_irq_assert(v->domain, irq, vioapic_get_vector); > > - /* > > - * hvm_isa_irq_assert may not set the corresponding bit in vIRR > > - * when mask field of IOAPIC RTE is set. Check it again. > > - */ > > For one, the transformation done here looks to call for folding > both calls to hvm_isa_irq_assert() into one. I'm not, however, > convinced recording the function's return value is useful in the > case where it wasn't recorded before. The change is benign right > now because hvm_isa_irq_assert() will return -1 when its last > argument is NULL, but the question is whether the code here should > start depending on such behavior. I see, I shouldn't have adjusted this first call to store pt_vector, and just leave pt_vector as initialized (-1) to not rely on hvm_isa_irq_assert returning -1. Coalescing both calls would make the code harder to read IMO, as then the condition of the if clause would need to be moved inside the call to hvm_isa_irq_assert in order to decide whether to pass NULL or vioapic_get_vector. > And then, according to this comment (which doesn't get retained in > any form or shape) ... > > > - if ( pt_vector < 0 || !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) > > - pt_vector = -1; > > - } > > + > > + if ( pt_vector < 0 ) > > + return pt_vector; > > + > > break; > > > > case PTSRC_ioapic: > > pt_vector = hvm_ioapic_assert(v->domain, irq, level); > > - if ( pt_vector < 0 || !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) > > - { > > - pt_vector = -1; > > - if ( level ) > > + if ( pt_vector < 0 ) > > + return pt_vector; > > + > > + break; > > + } > > + > > + ASSERT(pt_vector >= 0); > > + if ( !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) > > + { > > + time_cb *cb = NULL; > > + void *cb_priv; > > + > > + /* > > + * Vector has been injected to a different vCPU, call pt_irq_fired and > > + * execute the callback, since the destination vCPU(s) won't call > > + * pt_intr_post for it. > > ... this isn't the only reason to come here. Beyond what the comment > says there is the hvm_domain_use_pirq() check in assert_gsi() which > would similarly result in the IRR bit not observed set here. At the > very least these cases want mentioning; I have to admit that I'm not > entirely clear yet whether your handling is correct for both, or > whether the information needs to be propagated into here. I always forget about that weird pirq stuff (and I'm refraining from using other adjectives) that we have for HVM. AFAICT vpt is already broken when trying to inject interrupts generated from it over an event channel. hvm_ioapic_assert will return whatever garbage is in the IO-APIC entry, which will likely not be initialized because the GSI is routed over an event channel. I really have no idea what hvm_ioapic_assert should return in that case, the event channel callback vector maybe? Maybe just returning -1 would be fine, a guest using this routing of pirqs over event channels shouldn't be using any of the emulated timers, and hence vpt is not required to be functional in that case? > Also instead of ASSERT(pt_vector >= 0) would you pull the respective > if() out of the switch(), to also cover the case of a fall through > without hitting any of the explicitly handled cases, resulting in > pt_vector left at its initial value of -1? Sure. > > > + * TODO: move this vpt to one of the vCPUs where the vector gets > > + * injected. > > + */ > > + spin_lock(&v->arch.hvm.tm_lock); > > + /* Make sure the timer is still on the list. */ > > + list_for_each_entry ( pt, &v->arch.hvm.tm_list, list ) > > + if ( pt == earliest_pt ) > > { > > - /* > > - * Level interrupts are always asserted because the pin assert > > - * count is incremented regardless of whether the pin is masked > > - * or the vector latched in IRR, so also execute the callback > > - * associated with the timer. > > - */ > > - time_cb *cb = NULL; > > - void *cb_priv; > > - > > - spin_lock(&v->arch.hvm.tm_lock); > > - /* Make sure the timer is still on the list. */ > > - list_for_each_entry ( pt, &v->arch.hvm.tm_list, list ) > > - if ( pt == earliest_pt ) > > - { > > - pt_irq_fired(v, pt); > > - cb = pt->cb; > > - cb_priv = pt->priv; > > - break; > > - } > > - spin_unlock(&v->arch.hvm.tm_lock); > > - > > - if ( cb != NULL ) > > - cb(v, cb_priv); > > + pt_irq_fired(v, pt); > > + cb = pt->cb; > > + cb_priv = pt->priv; > > + break; > > } > > - } > > - break; > > + spin_unlock(&v->arch.hvm.tm_lock); > > + > > + if ( cb != NULL ) > > + cb(v, cb_priv); > > + > > + pt_vector = -1; > > } > > > > return pt_vector; > > To further reduce indentation (and seeing the significant code > churn that happens here anyway), could you consider inverting the > surrounding if() to > > if ( vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) > return pt_vector; > > ? Yup, that's indeed better. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 17:38:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 17:38:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlyUd-0003XK-Oi; Thu, 18 Jun 2020 17:38:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlyUc-0003XF-P8 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 17:38:26 +0000 X-Inumbo-ID: 829af196-b18a-11ea-bad5-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 829af196-b18a-11ea-bad5-12813bfff9fa; Thu, 18 Jun 2020 17:38:24 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: NQRoZSU6P1CbILpFQq2kWXrh4/ktG9XtP9Qh7LIo8+ZmU32IuLDP474E33WUp8GqqYKvB4BJr6 fO29vQBeAzT0sUjEh+whlMK1O8SayV7GC5txzGTfQ2TBU1idwLhfCF83ALWZAJMEeyzfm8/+zN +hzMUndn0cyOJcsD1jY5Ntxi+FA9M3TV1s9MXO6tWsaKidNtZg3tLwgBg4j4Kg8MTwBR7lkX+p nsQZ9EmHJ2n05AvgCJubq+LTBmnJgLFgmdpST82ah/fL6QflV8btZbrQ0wt5mubIctkTvX59Cp YEQ= X-SBRS: 2.7 X-MesageID: 20699660 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,252,1589256000"; d="scan'208";a="20699660" Subject: Re: [PATCH v1 7/7] x86/vmx: switch IPT MSRs on vmentry/vmexit To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Xen-devel References: <1548605014.8764792.1592320576239.JavaMail.zimbra@cert.pl> <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> From: Andrew Cooper Message-ID: <16148f3e-6c63-6caa-30f6-50a97889284e@citrix.com> Date: Thu, 18 Jun 2020 18:38:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <317430261.8766476.1592321051337.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Kevin Tian , Jan Beulich , Jun Nakajima , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 16:24, Michał Leszczyński wrote: > Enable IPT when entering the VM and disable it on vmexit. > Register state is persisted using vCPU ipt_state structure. > > Signed-off-by: Michal Leszczynski > --- > xen/arch/x86/hvm/vmx/vmx.c | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index 97104c319e..01d9a7b584 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -3698,6 +3698,15 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) > __vmread(GUEST_RSP, ®s->rsp); > __vmread(GUEST_RFLAGS, ®s->rflags); > > + if ( unlikely(v->arch.hvm.vmx.ipt_state) ) > + { > + wrmsrl(MSR_IA32_RTIT_CTL, 0); > + smp_rmb(); > + > + rdmsrl(MSR_IA32_RTIT_STATUS, v->arch.hvm.vmx.ipt_state->status); > + rdmsrl(MSR_IA32_RTIT_OUTPUT_MASK, v->arch.hvm.vmx.ipt_state->output_mask); > + } > + > hvm_invalidate_regs_fields(regs); > > if ( paging_mode_hap(v->domain) ) > @@ -4497,6 +4506,23 @@ bool vmx_vmenter_helper(const struct cpu_user_regs *regs) > } > > out: > + if ( unlikely(curr->arch.hvm.vmx.ipt_state) ) > + { > + wrmsrl(MSR_IA32_RTIT_CTL, 0); > + > + if (curr->arch.hvm.vmx.ipt_state->ctl) > + { > + wrmsrl(MSR_IA32_RTIT_OUTPUT_BASE, curr->arch.hvm.vmx.ipt_state->output_base); > + wrmsrl(MSR_IA32_RTIT_OUTPUT_MASK, curr->arch.hvm.vmx.ipt_state->output_mask); > + wrmsrl(MSR_IA32_RTIT_STATUS, curr->arch.hvm.vmx.ipt_state->status); > + > + // MSR_IA32_RTIT_CTL is context-switched manually instead of being > + // stored inside VMCS, as of Q2'20 only the most recent processors > + // support such field in VMCS > + wrmsrl(MSR_IA32_RTIT_CTL, curr->arch.hvm.vmx.ipt_state->ctl); > + } > + } > + Some notes to help with v2. RTIT_CTL wants managing by MSR load/save list.  See how vmx_update_guest_efer() manages MSR_EFER for the Gen1 hardware case, because RTIT_CTL is very similar until we get to IceLake hardware and have a GUEST_RTIT_CTRL field. With RTIT_CTL handled by MSR load/save list, we are now certain that TraceEn is always clear in hypervisor context, so there's no need to explicitly zero it before playing with other MSRs. You don't need to save/restore the values in vmentry/exit, because that is very expensive an unnecessary.  Instead, you can use vmx_ctxt_switch_{from,to}() which is based on when the vcpu is switched in/out of context. Specifically, from your current code, it looks to be safe to leave RTIT_STATUS/OUTPUT_MASK dirty in hardware across multiple vmentries/exits while the vcpu is in context. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 18 17:46:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 17:46:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlycG-0004Mi-Io; Thu, 18 Jun 2020 17:46:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlycE-0004Md-RI for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 17:46:18 +0000 X-Inumbo-ID: 9cd39b0c-b18b-11ea-bad6-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9cd39b0c-b18b-11ea-bad6-12813bfff9fa; Thu, 18 Jun 2020 17:46:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VBX4pk3vzbZUK3ycpONoacX6vu9VZUWAfcvVsS1/NiI=; b=v6d4jRcYa9tJh3hs5BngBPWAZ2 GlqtY6KQPcKp9Lb4zgu+FX8M6whInSDGRoDS2cQxV0R0v8/bgpWW96ZjddAA+LM/RD6i0LqCr0iZ4 ZuIH9J3b8hhAbKlY+QXVd6b7n/H8Cl/T73B6TajsT8WElsbEJ+R7b8fMjlv1ZyhKUKPM=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlyc6-0006HA-9q; Thu, 18 Jun 2020 17:46:10 +0000 Received: from 54-240-197-234.amazon.com ([54.240.197.234] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlyc6-0000VK-2c; Thu, 18 Jun 2020 17:46:10 +0000 Subject: Re: [PATCH 2/2] xen/arm: Mitigate straight-line speculation for SMC call To: security@xenproject.org References: <20200616175913.7368-1-julien@xen.org> <20200616175913.7368-3-julien@xen.org> From: Julien Grall Message-ID: <0ae27312-f8ab-e3b6-fbaa-a4aba4905405@xen.org> Date: Thu, 18 Jun 2020 18:46:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200616175913.7368-3-julien@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, paul@xen.org, Andre.Przywara@arm.com, Julien Grall , Bertrand.Marquis@arm.com, xen-devel@lists.xenproject.org, Volodymyr_Babchuk@epam.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16/06/2020 18:59, Julien Grall wrote: > From: Julien Grall > > SMC call will update some of registers (typically only x0) depending on > the arguments provided. > > Some CPUs can speculate past a SMC instruction and potentially perform > speculative access to emrmoy using the pre-call values before executing > the SMC. > > There is no known gadget available after the SMC call today. However > some of the registers may contain values from the guest and are expected > to be updated by the SMC call. > > In order to harden the code, it would be better to prevent straight-line > speculation from an SMC. Architecturally executing the speculation > barrier after every SMC can be rather expensive (particularly on core > not SB). Therefore we want to mitigate it diferrently: > > * For arm_smccc_1_0_smc, we can avoid a speculation barrier right > after the SMC instruction and instead rely on the one after eret. > * For arm_smccc_1_1_smc, we can place a B instruction after the SMC > instruction to skip the barrier. > > Note that arm_smccc_1_0_smc version on arm32 is just an alias to > arm_smccc_1_1_smc. > > Note that no speculation barrier has been added after the SMC > instruction in arm64/entry.S. This is fine because the call is not > expected to modify any registers. So straight-line speculation doesn't > matter. > > Signed-off-by: Julien Grall > > --- > > Note this hasn't been vetted by Arm but they are using the same > sort of mitigation for blr. So I am quite confident this could do the > trick. Actually there is some unknown on whether this may introduce issue on other sort of speculation. As there is no known reveal gadge after the SMC call and this is only about prevention, I will withdraw this patch for the time being. Patch #1 is still valid though. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 18 17:57:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 17:57:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlymy-0005Hg-Lh; Thu, 18 Jun 2020 17:57:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlymx-0005HM-67 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 17:57:23 +0000 X-Inumbo-ID: 25e01c4e-b18d-11ea-bad6-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 25e01c4e-b18d-11ea-bad6-12813bfff9fa; Thu, 18 Jun 2020 17:57:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=x7BcZZlwu9qytH9KhY0g9sb6h7eqjhk6L8CUWXlIZHQ=; b=fEg1jiXHv4aLBw04kuIleUfrn SR6LGQkrGfilND8tMuAndiDnlpO/AGWJFtCVBClLdlTdMRD4PXb+P3ALum300PuVO+F1EGWGk1zf7 aFEEYuNgjwXTq6OTwll9qFzp8+SznOiE6Gk0B9QBHPGO2SAWtOtsM05O64M8mkktD9LoE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlymq-0006Ta-Ob; Thu, 18 Jun 2020 17:57:16 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlymq-000830-GH; Thu, 18 Jun 2020 17:57:16 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlymq-0002Zo-Fa; Thu, 18 Jun 2020 17:57:16 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151225: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=f0dca895a58710ecd49d813c96d382d5625b74c1 X-Osstest-Versions-That: xen=71ca0e0ad000e690899936327eb09709ab182ade From: osstest service owner Date: Thu, 18 Jun 2020 17:57:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151225 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151225/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen f0dca895a58710ecd49d813c96d382d5625b74c1 baseline version: xen 71ca0e0ad000e690899936327eb09709ab182ade Last test of basis 151194 2020-06-17 14:00:29 Z 1 days Testing same since 151225 2020-06-18 16:01:13 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Igor Druzhinin Jason Andryuk jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 71ca0e0ad0..f0dca895a5 f0dca895a58710ecd49d813c96d382d5625b74c1 -> smoke From xen-devel-bounces@lists.xenproject.org Thu Jun 18 18:05:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 18:05:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlyud-0006Ds-Jc; Thu, 18 Jun 2020 18:05:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlyuc-0006Dn-OM for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 18:05:18 +0000 X-Inumbo-ID: 43e30fe8-b18e-11ea-bad7-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 43e30fe8-b18e-11ea-bad7-12813bfff9fa; Thu, 18 Jun 2020 18:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LiNn3uEpSqSiX3FNi5dguXCf75bYB8eCsqDdSWZ3ii0=; b=hBciOBFUCsGhA/O4Rn+9ct3/lC czoDIz49X4TgWjS2V/mmlWszNimXd3JA5sfpCaMYdMpWQBg0b/R1+DQvf1zCMLNXP3AWHGN8Y3R08 IFslYPFN9dBLqM33CXZoj8RiNFtNu19hpt525A1tzSLQgRYBArIES4SDe/dhxj68qeI8=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlyuW-0006hA-U8; Thu, 18 Jun 2020 18:05:12 +0000 Received: from 54-240-197-234.amazon.com ([54.240.197.234] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jlyuW-0001Ov-MK; Thu, 18 Jun 2020 18:05:12 +0000 Subject: Re: [Tee-dev] TEE with XEN To: Volodymyr Babchuk , Peng Fan References: From: Julien Grall Message-ID: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> Date: Thu, 18 Jun 2020 19:05:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Oleksandr Andrushchenko , Bertrand Marquis , "tee-dev@lists.linaro.org" , Xen-devel , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" +Bertrand and Stefano On 16/06/2020 02:24, Volodymyr Babchuk wrote: > Hi Peng, > > On Mon, 15 Jun 2020 at 05:07, Peng Fan wrote: >> >> Hi All, >> >> While enabling trusty os with xen, I took same approach as OP-TEE, >> with OP-TEE running in secure world. But I am also thinking this might >> introduce potential issue is that secure world OS communicate with DomU. >> If there are some misbehavior in secure world OS, it might let XEN >> hypervisor not work proper. >> >> In my setup, trusty os sometimes panic in secure world, xen will not able >> to control the panic core anymore. May I ask in which case Trusty is panicking? >> >> So I am thinking whether we need to emulating secure world in a XEN VM >> which is the VM running DomU. Just like what ACRN did to run trusty >> os. > > Well, it depends on whom you are trusting more. Both XEN and TEE are minimal > OS implementations with aim at security. I'm speaking about generic TEE OS, not > about particular OS like OP-TEE or Trusty. Problem is that, if TEE is > running inside > VM, it will be susceptible to a hypervisor misbehaviour. You need to understand > that Xen and privileged domain (dom0, mostly) can access memory of any guest. > At least, in default configuration. There are means to harden this > setup. But anyways, > Xen can't be stopped from reading TEE's secrets. IIRC, we discussed this approach for OP-TEE in the past. There was other potential pitfalls with it. For instance, you wouldn't be able to directly access any secure device from that guest (it is running in non-secure world). There are also issues in term of latency as you may have the following model: domU -> Xen -> domU TEE -> (Xen -> host TEE -> Xen -> domU TEE) -> Xen -> domU. The bit in () is if you require to call the host TEE. One possibility would be to use Secure-EL2 for your Trusty OS. But I don't know whether your platform supports it. Depending on whether you can modify Trusty OS, alternative would be to make itvirtualization aware as OP-TEE did. The core would need to be resilient and the panic only affect a given client. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 18 19:13:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 19:13:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlzyI-0003Rk-VF; Thu, 18 Jun 2020 19:13:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlzyH-0003Rf-0b for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 19:13:09 +0000 X-Inumbo-ID: bd89614a-b197-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bd89614a-b197-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 19:13:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1PwD+e6uEkDTWr1f0FtZDAro9Jvgny39UjiTpUbwQQ8=; b=ZvXcUGsuOZ+gyNwSnthjVcuFD nqZzayQKn8hiSA9OxBuzprRpryu6JbatKjKZIc7WyPYHnRkjwjlIfO+x/owS6lmq3e7R+Ot6gGOeZ PQJWFR1LdlJatJnMGjlrzO0d9QPGNPbs1VxuT4CQtsCZOzAKINohpgokMfzPikiQqUmGk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlzyE-0007vb-94; Thu, 18 Jun 2020 19:13:06 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jlzyD-0002iX-Rp; Thu, 18 Jun 2020 19:13:05 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jlzyD-0004Od-RA; Thu, 18 Jun 2020 19:13:05 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151184: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-saverestore.2:fail:heisenbug xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=06760c2bf322cef4622b56bafee74fe93ae01630 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Thu, 18 Jun 2020 19:13:05 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151184 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151184/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qcow2 16 guest-saverestore.2 fail pass in 151161 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail in 151161 like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 06760c2bf322cef4622b56bafee74fe93ae01630 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 35 days Failing since 150943 2020-06-09 17:06:00 Z 9 days 8 attempts Testing same since 151161 2020-06-15 22:27:38 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 06760c2bf322cef4622b56bafee74fe93ae01630 Author: Andrew Cooper Date: Fri Jun 12 18:32:27 2020 +0100 tools/libxl: Fix memory leak in libxl_cpuid_set() xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to free() seeing as it discards the results. This is logically a backport of c/s b91825f628 "tools/libxc: Drop config_transformed parameter from xc_cpuid_set()" but rewritten as one caller of xc_cpuid_set() does use returned values. Signed-off-by: Andrew Cooper (cherry picked from commit c54de7d9df7718ea53bf21e1ff5bbd339602a704) commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Thu Jun 18 19:18:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 19:18:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm03P-0003c2-Ja; Thu, 18 Jun 2020 19:18:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm03N-0003bu-Ij for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 19:18:25 +0000 X-Inumbo-ID: 7af12916-b198-11ea-bae9-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7af12916-b198-11ea-bae9-12813bfff9fa; Thu, 18 Jun 2020 19:18:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Xnt5wAlsC8js/GY6TG3eLt1Ge2bgp9Kyfb2z8+rqfuc=; b=aLrZepfyEyR/GWvAbvsy5WXLj 048foBuj5YUtKyVIz3s1odQolmraKUoo2UdFjrCEa7yGamS1w+jJD+YeTr/TIL9PlN2V3A5GtgiaR ntSJn4MUh2ioLv1r3Him7L7VEQpNQOi9hqa9EO550JomYmEAmKFjyHPFPsV0H08JCom8I=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm03L-00081y-UT; Thu, 18 Jun 2020 19:18:23 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jm03L-0003CJ-Et; Thu, 18 Jun 2020 19:18:23 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jm03L-0006TG-EC; Thu, 18 Jun 2020 19:18:23 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151187: all pass - PUSHED X-Osstest-Versions-This: ovmf=58ae92a993687d913aa6dd00ef3497a1bc5f6c40 X-Osstest-Versions-That: ovmf=8927e2777786a43cddfaa328b0f4c41a09c629c9 From: osstest service owner Date: Thu, 18 Jun 2020 19:18:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151187 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151187/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 58ae92a993687d913aa6dd00ef3497a1bc5f6c40 baseline version: ovmf 8927e2777786a43cddfaa328b0f4c41a09c629c9 Last test of basis 151162 2020-06-16 01:58:37 Z 2 days Testing same since 151187 2020-06-17 09:28:29 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel Ilias Apalodimas Jiewen Yao Laszlo Ersek Ming Tan Tan, Ming jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 8927e27777..58ae92a993 58ae92a993687d913aa6dd00ef3497a1bc5f6c40 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Thu Jun 18 20:25:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 20:25:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm15k-0001DD-6f; Thu, 18 Jun 2020 20:24:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm15i-0001D8-DD for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 20:24:54 +0000 X-Inumbo-ID: c3ed96fa-b1a1-11ea-bca7-bc764e2007e4 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [40.107.6.65]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c3ed96fa-b1a1-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 20:24:52 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DRXjcZREO5np5G9LlJHR4XgjxIPHfVbgc3JktwIpWth+6/c3GThfQZdOS11Bgmu4dRGaJdYrAD/xHrmsU4jTzpIKIgYh35V8GpE1QTEjpYE6otAB2MYoAIdNkRH8p0j22V+dPYiz8t7bgU7herUZEBHemRH/1vIILbckVDHCGbfeNBXZdZF2vv0oP6EcdAKQtBtr5Ti5sd0s1DcMzjUNFMSe5clDK3X7t6debEJ4leMaJKnu4dwKiuAo1htEDn4BJB2HMtoMW4ODoUOITFyv/ZWF8TERlHUGLfDWh/0pQRnc0UWF00BkvztlBFoQQzou8YhhXuv/v7C38cvyMrs0Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=na25ahuFea09fEF4sXKL6wV565mkcRkDMhGmlR1U5HY=; b=nsi/c8etmavMETBhjOsVfAk31CajvD1AmYegegwhoIsx9V1n6Cp4RPlB2dnPhgIowUM7sG/xZ/uEgpge7Uk9DJWm5Ks5aZQrhWehiwGVwxuUjvejlf82Ymy4zDJrM6ZdlNbukZTpWc70OCCsBC8DFSVwkwz0DBO+csdBDoXzvbHAGgANfnpd1gCfH4u6siiX0TQCJViDP42ZSd20GxOj4mfuNn0RG8SKycCmon3rVU8Yj9Mr3UhD8+hSHvDP4ZPstLICWEKR2gNmeKgFh7/kVoKanvDDUWT87voXMbQtd4keyDzI+UtRFX+C1EbOofgV952SJXEE0Hh7l7vl4WTS+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=na25ahuFea09fEF4sXKL6wV565mkcRkDMhGmlR1U5HY=; b=4v+uTtSy1j/FcqtDlc4x2TmyYYhoz7RTm3yANEvtERRTUnA4zKiB2ggduKWuREfR5CILCM6bAB/IHau7+1rlrgR6wyDGSrhNTNkCndEvh8ApEZWXeUYvZ7cT3Ymra+Pyzh3GgJMPlpypkY6LNj77PnUNLDLFGaIKh1653pED4f1PsNTHw5qS6d/enyIRweMmDoV2iOtU/71fT4q3f0AITeJyRdZ9Spaynb5a+k0cYIYYpxkzCfo9c+theE7oHGhg4xq9JJ05PUlv1lLgEc0rsBAGk34/hzetsLb1ZsxbT1uZHfA7MZj5ejynQ2mUf06qTc577YrCQq6hJKO7+h99hw== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB4032.eurprd03.prod.outlook.com (2603:10a6:803:72::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 18 Jun 2020 20:24:49 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3088.028; Thu, 18 Jun 2020 20:24:49 +0000 From: Volodymyr Babchuk To: Julien Grall Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Topic: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Index: AQHWQE+Tib/gTK49mk6bUudd1VvXZqjUa0CAgABx3ACAABDmgIAJ7mUA Date: Thu, 18 Jun 2020 20:24:48 +0000 Message-ID: <87imfo2kbz.fsf@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <1fcd5d89691b775d1230bf3405e29893107edcb3.camel@epam.com> <92d81acb-fd78-3483-68fb-f52c7bfb3d65@xen.org> In-Reply-To: <92d81acb-fd78-3483-68fb-f52c7bfb3d65@xen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.4.10; emacs 26.3 authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c1752c83-c660-41e2-0263-08d813c5a68d x-ms-traffictypediagnostic: VI1PR03MB4032: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:318; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XTgmo/5KzS0Kbn82zkeyEXZVDVU+s3OGv+GxMJC2TPLzpBFBrULUXmFm53UXXPKkHa4CPEY44K8RqjFUtcf/1WT4w3RN1hxrs4wr7IDOqmP8DWqY3G5PjwYIc47eJ+Tm+l8D7alD0BhcJ0N6JDk7iiwz0TbnkholmS4QttG8AsSBXu9WZJMe9SPP66I8Bzp+asgIEMlnfUvQQrVRK9EW5UnY/Mwxji9/H9GYVWMWukfgRNbHswKkn83VCYF3LPJChFmlTBIx83Jd/Z2/e7izYP0gGsIndgeklrQytI8RtujbH8bXJzci31+59i8n/j1s9pbBGmSGbMgNzgjnNh9slA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(66574015)(83380400001)(71200400001)(91956017)(66946007)(6486002)(66476007)(66446008)(76116006)(6512007)(4326008)(5660300002)(86362001)(64756008)(66556008)(6506007)(6916009)(7416002)(2906002)(8936002)(53546011)(316002)(2616005)(54906003)(478600001)(186003)(8676002)(36756003)(26005)(55236004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 8UAF4QMc6VytnRD2mlFEE0cLDr8YYdpoNN/8fTn9e0WOfYWw0X9IxeqwF4CDBWmFwXToIblf8e3Cg7bKyK27emUNaEAhzi5tmAtURHnTne8XdnKRv9TNA6Hj5OQWuzVZTksqbFPpHofFUD1t6+fkx28CC63w9ZEurkabjUf7X1y+HEIkLs7FwsIl1PyxqF5Yyu/x3/0CSxxm6ZzD1N4hWTzgaF2rLMq/mgd3zQtcpOeWWRXbvkZIV1k69JIrvIYMChJKh9xyT0nxq6dac7dzH9FXoSe+TiZBzkoXoD7mD/sCBCQGED9uPPXB5DjkU5K99qMg5ONZTD20LN+/QLxPALwnFIKXFf1D6x1IGuelQP6x87G8NialIatuS0eE3RteWJp4jKhUmS2nR32TRX3UtHpeQhqecORbkZwQ4/xfzMuViGw069o45kW1VakjZjPOxs9eKesVJSiC+x0GZCN51gM51Ov+x0ZzjNyvoVKfvC8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <01167F0B1A3DC244895F53C795BEFD81@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: c1752c83-c660-41e2-0263-08d813c5a68d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 20:24:48.7194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Q8ww+lKZ2rT1R9HySn85dHPlFNvWbUSMpy5p6UYuA7i2URxGaJ4D/N4mKbaWZA4P5WBnjQPMt39H8BHIieOXJq1WnOb1WsxsiiRwS+VBa8M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4032 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpIaSBKdWxpZW4sDQoNCkp1bGllbiBHcmFsbCB3cml0ZXM6DQoNCj4gSGkgVm9sb2R5bXlyLA0K Pg0KPiBPbiAxMi8wNi8yMDIwIDEyOjQ0LCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4+DQo+ PiBPbiBGcmksIDIwMjAtMDYtMTIgYXQgMDY6NTcgKzAyMDAsIErDvHJnZW4gR3Jvw58gd3JvdGU6 DQo+Pj4gT24gMTIuMDYuMjAgMDI6MjIsIFZvbG9keW15ciBCYWJjaHVrIHdyb3RlOg0KPj4+PiBB cyBzY2hlZHVsZXIgY29kZSBub3cgY29sbGVjdHMgdGltZSBzcGVudCBpbiBJUlEgaGFuZGxlcnMg YW5kIGluDQo+Pj4+IGRvX3NvZnRpcnEoKSwgd2UgY2FuIHByZXNlbnQgdGhvc2UgdmFsdWVzIHRv IHVzZXJzcGFjZSB0b29scyBsaWtlDQo+Pj4+IHhlbnRvcCwgc28gc3lzdGVtIGFkbWluaXN0cmF0 b3IgY2FuIHNlZSBob3cgc3lzdGVtIGJlaGF2ZXMuDQo+Pj4+DQo+Pj4+IFdlIGFyZSB1cGRhdGlu ZyBjb3VudGVycyBvbmx5IGluIHNjaGVkX2dldF90aW1lX2NvcnJlY3Rpb24oKSBmdW5jdGlvbg0K Pj4+PiB0byBtaW5pbWl6ZSBudW1iZXIgb2YgdGFrZW4gc3BpbmxvY2tzLiBBcyBhdG9taWNfdCBp cyAzMiBiaXQgd2lkZSwgaXQNCj4+Pj4gaXMgbm90IGVub3VnaCB0byBzdG9yZSB0aW1lIHdpdGgg bmFub3NlY29uZCBwcmVjaXNpb24uIFNvIHdlIG5lZWQgdG8NCj4+Pj4gdXNlIDY0IGJpdCB2YXJp YWJsZXMgYW5kIHByb3RlY3QgdGhlbSB3aXRoIHNwaW5sb2NrLg0KPj4+Pg0KPj4+PiBTaWduZWQt b2ZmLWJ5OiBWb2xvZHlteXIgQmFiY2h1ayA8dm9sb2R5bXlyX2JhYmNodWtAZXBhbS5jb20+DQo+ Pj4+IC0tLQ0KPj4+PiAgICB4ZW4vY29tbW9uL3NjaGVkL2NvcmUuYyAgICAgfCAxNyArKysrKysr KysrKysrKysrKw0KPj4+PiAgICB4ZW4vY29tbW9uL3N5c2N0bC5jICAgICAgICAgfCAgMSArDQo+ Pj4+ICAgIHhlbi9pbmNsdWRlL3B1YmxpYy9zeXNjdGwuaCB8ICA0ICsrKy0NCj4+Pj4gICAgeGVu L2luY2x1ZGUveGVuL3NjaGVkLmggICAgIHwgIDIgKysNCj4+Pj4gICAgNCBmaWxlcyBjaGFuZ2Vk LCAyMyBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pDQo+Pj4+DQo+Pj4+IGRpZmYgLS1naXQg YS94ZW4vY29tbW9uL3NjaGVkL2NvcmUuYyBiL3hlbi9jb21tb24vc2NoZWQvY29yZS5jDQo+Pj4+ IGluZGV4IGE3Mjk0ZmY1YzMuLmVlNmIxZDkxNjEgMTAwNjQ0DQo+Pj4+IC0tLSBhL3hlbi9jb21t b24vc2NoZWQvY29yZS5jDQo+Pj4+ICsrKyBiL3hlbi9jb21tb24vc2NoZWQvY29yZS5jDQo+Pj4+ IEBAIC05NSw2ICs5NSwxMCBAQCBzdGF0aWMgc3RydWN0IHNjaGVkdWxlciBfX3JlYWRfbW9zdGx5 IG9wczsNCj4+Pj4gICAgICAgc3RhdGljIGJvb2wgc2NoZWR1bGVyX2FjdGl2ZTsNCj4+Pj4gICAg K3N0YXRpYyBERUZJTkVfU1BJTkxPQ0soc2NoZWRfc3RhdF9sb2NrKTsNCj4+Pj4gK3NfdGltZV90 IHNjaGVkX3N0YXRfaXJxX3RpbWU7DQo+Pj4+ICtzX3RpbWVfdCBzY2hlZF9zdGF0X2h5cF90aW1l Ow0KPj4+PiArDQo+Pj4+ICAgIHN0YXRpYyB2b2lkIHNjaGVkX3NldF9hZmZpbml0eSgNCj4+Pj4g ICAgICAgIHN0cnVjdCBzY2hlZF91bml0ICp1bml0LCBjb25zdCBjcHVtYXNrX3QgKmhhcmQsIGNv bnN0IGNwdW1hc2tfdCAqc29mdCk7DQo+Pj4+ICAgIEBAIC05OTQsOSArOTk4LDIyIEBAIHNfdGlt ZV90IHNjaGVkX2dldF90aW1lX2NvcnJlY3Rpb24oc3RydWN0DQo+Pj4+IHNjaGVkX3VuaXQgKnUp DQo+Pj4+ICAgICAgICAgICAgICAgIGJyZWFrOw0KPj4+PiAgICAgICAgfQ0KPj4+PiAgICArICAg IHNwaW5fbG9ja19pcnFzYXZlKCZzY2hlZF9zdGF0X2xvY2ssIGZsYWdzKTsNCj4+Pj4gKyAgICBz Y2hlZF9zdGF0X2lycV90aW1lICs9IGlycTsNCj4+Pj4gKyAgICBzY2hlZF9zdGF0X2h5cF90aW1l ICs9IGh5cDsNCj4+Pj4gKyAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlKCZzY2hlZF9zdGF0X2xv Y2ssIGZsYWdzKTsNCj4+Pg0KPj4+IFBsZWFzZSBkb24ndCB1c2UgYSBsb2NrLiBKdXN0IHVzZSBh ZGRfc2l6ZWQoKSBpbnN0ZWFkIHdoaWNoIHdpbGwgYWRkDQo+Pj4gYXRvbWljYWxseS4NCj4+DQo+ PiBMb29rcyBsaWtlIGFybSBkb2VzIG5vdCBzdXBwb3J0IDY0IGJpdCB2YXJpYWJsZXMuID4NCj4+ IEp1bGllbiwgSSBiZWxpZXZlLCB0aGlzIGlzIGFybXY3IGxpbWl0YXRpb24/IFNob3VsZCBhcm12 OCB3b3JrIHdpdGggNjQtDQo+PiBiaXQgYXRvbWljcz8NCj4NCj4gNjQtYml0IGF0b21pY3MgY2Fu IHdvcmsgb24gYm90aCBBcm12NyBhbmQgQXJtdjggOikuIEl0IGp1c3QgaGF2ZW4ndA0KPiBiZWVu IHBsdW1iZWQgeWV0Lg0KPg0KPiBJIGFtIGhhcHB5IHRvIHdyaXRlIGEgcGF0Y2ggaWYgeW91IG5l ZWQgYXRvbWljNjRfdCBvciBldmVuIGEgNjQtYml0DQo+IGFkZF9zaXplZCgpLg0KDQpMb29rcyBs aWtlIEknbGwgbmVlZCB0aGlzIHBhdGNoLiBTbywgaWYgeW91IHN0aWxsIGhhdmUgdGltZSwgaXQg d2lsbCBiZQ0KZ3JlYXQsIGlmIHlvdSdsbCB3cml0ZSBpdC4NCg0KLS0gDQpWb2xvZHlteXIgQmFi Y2h1ayBhdCBFUEFN From xen-devel-bounces@lists.xenproject.org Thu Jun 18 20:35:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 20:35:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm1Fa-00025P-62; Thu, 18 Jun 2020 20:35:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm1FY-00025K-HD for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 20:35:04 +0000 X-Inumbo-ID: 300a2320-b1a3-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 300a2320-b1a3-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 20:35:03 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id l26so6453474wme.3 for ; Thu, 18 Jun 2020 13:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UjSv5RVxmAzxiHW9gbbgC/lK7j6x6Pkr9ILwSOee/tA=; b=r1K5FX8zAlZM2jNEdwTyzrYCCkE5SUcIP7TXX6Yh6cOpGPfS5BIln3tJA3DDcn8AFp JDxnsPeJLq+2AhceweZdWi89BYQtiMRHILffJV9zJj86zB91SmQPnOkqVn1l43DB0uvP PAPh2iMYRDAtcPzUXefRNVWxvDl6sA8t/PXz+fAmDwa/2FSMnJmICNAWpR3jr9Y4if40 cltqtu7+42et55hLAuT9UPtnaYnzx5vJT+Jg2kDcWssQRVr7I8t42rmnKkDuPBr3TwwQ 2JQi9+EeT8e3hmYZiEtPn3kGCWQ8YobqszxPBnlnY2sXwjOStpogFOJrWTi2nKCs85P3 8Pzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UjSv5RVxmAzxiHW9gbbgC/lK7j6x6Pkr9ILwSOee/tA=; b=CKl2oJJA5uTHG0F+fci27B0rRWcBM8mKDyvCHG8QPah9LGOkM0ZgafsgCeAxPPu6px N9eLmqwLVPcad87zJuYf2frOaMxBOFXmR1RMh90E8k/cMyEkWCrK1fc8n5mPdNSaxr+7 F3VCl6R8AdREZ8ZLjipylfrbOAW1aOiBgdeitM2KAeMEBuXJ3tawkvBJ9HLRtPf/r2/e dGVc576cV9hYSXrraeA+mhwdqfPI0hNGKKg0WdtrFcMyyJQQLMlXgeipZToyxb35fF6/ CRJV3hpNw6J+y/VZkU9Z0g8tMB8LqcSMPSxhzujce1ECM3oGtdRO1JkVSdxXM8maGMNI yqwQ== X-Gm-Message-State: AOAM531cuNGCnkQzd65kIxAnlKlQcekL7WRWzCeM0H0xtCmap83u5uck kVW98hcQGlR7dNFZhOI2mEWYp3w/lo2QaBKSm0s= X-Google-Smtp-Source: ABdhPJxD2+M2LwQHH1WNhmnw6gQ1GmkjOMk+XMg1wYMST7H7tiNA3R4mFQmgbPh4VtOt790GdQT8cFegHiCZXMO9fZw= X-Received: by 2002:a1c:230f:: with SMTP id j15mr138234wmj.100.1592512502752; Thu, 18 Jun 2020 13:35:02 -0700 (PDT) MIME-Version: 1.0 References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <1fcd5d89691b775d1230bf3405e29893107edcb3.camel@epam.com> <92d81acb-fd78-3483-68fb-f52c7bfb3d65@xen.org> <87imfo2kbz.fsf@epam.com> In-Reply-To: <87imfo2kbz.fsf@epam.com> From: Julien Grall Date: Thu, 18 Jun 2020 21:34:51 +0100 Message-ID: Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. To: Volodymyr Babchuk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 18 Jun 2020 at 21:24, Volodymyr Babchuk wrote: > > > Hi Julien, > > Julien Grall writes: > > > Hi Volodymyr, > > > > On 12/06/2020 12:44, Volodymyr Babchuk wrote: > >> > >> On Fri, 2020-06-12 at 06:57 +0200, J=C3=BCrgen Gro=C3=9F wrote: > >>> On 12.06.20 02:22, Volodymyr Babchuk wrote: > >>>> As scheduler code now collects time spent in IRQ handlers and in > >>>> do_softirq(), we can present those values to userspace tools like > >>>> xentop, so system administrator can see how system behaves. > >>>> > >>>> We are updating counters only in sched_get_time_correction() functio= n > >>>> to minimize number of taken spinlocks. As atomic_t is 32 bit wide, i= t > >>>> is not enough to store time with nanosecond precision. So we need to > >>>> use 64 bit variables and protect them with spinlock. > >>>> > >>>> Signed-off-by: Volodymyr Babchuk > >>>> --- > >>>> xen/common/sched/core.c | 17 +++++++++++++++++ > >>>> xen/common/sysctl.c | 1 + > >>>> xen/include/public/sysctl.h | 4 +++- > >>>> xen/include/xen/sched.h | 2 ++ > >>>> 4 files changed, 23 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c > >>>> index a7294ff5c3..ee6b1d9161 100644 > >>>> --- a/xen/common/sched/core.c > >>>> +++ b/xen/common/sched/core.c > >>>> @@ -95,6 +95,10 @@ static struct scheduler __read_mostly ops; > >>>> static bool scheduler_active; > >>>> +static DEFINE_SPINLOCK(sched_stat_lock); > >>>> +s_time_t sched_stat_irq_time; > >>>> +s_time_t sched_stat_hyp_time; > >>>> + > >>>> static void sched_set_affinity( > >>>> struct sched_unit *unit, const cpumask_t *hard, const cpumask= _t *soft); > >>>> @@ -994,9 +998,22 @@ s_time_t sched_get_time_correction(struct > >>>> sched_unit *u) > >>>> break; > >>>> } > >>>> + spin_lock_irqsave(&sched_stat_lock, flags); > >>>> + sched_stat_irq_time +=3D irq; > >>>> + sched_stat_hyp_time +=3D hyp; > >>>> + spin_unlock_irqrestore(&sched_stat_lock, flags); > >>> > >>> Please don't use a lock. Just use add_sized() instead which will add > >>> atomically. > >> > >> Looks like arm does not support 64 bit variables. > > >> Julien, I believe, this is armv7 limitation? Should armv8 work with 64= - > >> bit atomics? > > > > 64-bit atomics can work on both Armv7 and Armv8 :). It just haven't > > been plumbed yet. > > > > I am happy to write a patch if you need atomic64_t or even a 64-bit > > add_sized(). > > Looks like I'll need this patch. So, if you still have time, it will be > great, if you'll write it. I offered help for either the atomic64_t or the add_sized(). Can you confirm which one you need? Cheers, From xen-devel-bounces@lists.xenproject.org Thu Jun 18 21:30:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 21:30:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm26y-0006q3-Ar; Thu, 18 Jun 2020 21:30:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm26x-0006py-Mi for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 21:30:15 +0000 X-Inumbo-ID: e5b86aea-b1aa-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e5b86aea-b1aa-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 21:30:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LcglarJfONXNGzrI+oh2jgJEj/k/dJmSiFAROMNim8U=; b=zmMKXAauIPNfosmJIrSv3tBD4 652/kh7zWq3JN3vtJp8ykDmFyWrxewKYV6q5VVvVZjQc4UaoB3WPtrK8JhOMmVu3YH8lS3dXm4kc8 TQOMaYoQkpi6HtYshcBYQZZXMWD0MAYyrOdbf+juUhtNWkB88XzE+pWTrlsnAbJ7bphpY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm26w-0002GH-33; Thu, 18 Jun 2020 21:30:14 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jm26v-0000BC-PG; Thu, 18 Jun 2020 21:30:13 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jm26v-0003Jn-Ok; Thu, 18 Jun 2020 21:30:13 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151226: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=f1d376a825f4878eab0ef9cabe50ec4299968629 X-Osstest-Versions-That: xen=f0dca895a58710ecd49d813c96d382d5625b74c1 From: osstest service owner Date: Thu, 18 Jun 2020 21:30:13 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151226 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151226/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen f1d376a825f4878eab0ef9cabe50ec4299968629 baseline version: xen f0dca895a58710ecd49d813c96d382d5625b74c1 Last test of basis 151225 2020-06-18 16:01:13 Z 0 days Testing same since 151226 2020-06-18 18:00:35 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Olaf Hering Samuel Thibault jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f0dca895a5..f1d376a825 f1d376a825f4878eab0ef9cabe50ec4299968629 -> smoke From xen-devel-bounces@lists.xenproject.org Thu Jun 18 22:00:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 22:00:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2Zy-0000tK-Iy; Thu, 18 Jun 2020 22:00:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2Zx-0000tF-VV for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 22:00:14 +0000 X-Inumbo-ID: 15c3fffc-b1af-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 15c3fffc-b1af-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 22:00:13 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6AF2320773; Thu, 18 Jun 2020 22:00:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592517612; bh=W5lSpBNi/2zBEZMgGS4FlPiTuC7YUa6vQZ+95L6WU2I=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dia08sogqOwOE/qt+Ws0RmUmEUdt7+dVb2Kf1FWdYsDF1qO6C3fFWq3obtFS7fWDj XLDJdZKn4oWGmaGW3+noFYXOBU45kjULDx8yF/hSG5CjuFahDxE2NIbYClJb7gGnXO bXGyhZZ8+eg/dEMm1E8sFpyk98x+BKaVHDIQcp6c= Date: Thu, 18 Jun 2020 15:00:11 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: UEFI support in ARM DomUs In-Reply-To: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Stefano Stabellini , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 18 Jun 2020, Julien Grall wrote: > On 18/06/2020 06:22, Oleksandr Andrushchenko wrote: > > > > On 6/4/20 6:31 PM, Stefano Stabellini wrote: > > > On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote: > > > > On 6/4/20 4:57 AM, Peng Fan wrote: > > > > > Grall ; > > > > > > Nataliya Korovkina > > > > > > Subject: UEFI support in ARM DomUs > > > > > We have made U-Boot run inside XEN DomU, but just only PV console > > > > > part, > > > > > not implement other frontend drivers currently. Would this help for > > > > > your > > > > > case if enable EFI in U-Boot? > > > > Well, we have a working PV block implementation on top of that on iMX8 > > > > > > > > platform, mostly ported from mini-os. Currently we are finalizing the > > > > work > > > > > > > > and cleaning up (it's going to take a week or so hopefully). Then, we > > > > we'll post > > > > > > > > it on our public github. We are also thinking about upstreaming the > > > > work, but it may > > > > > > > > take quite some time if the whole idea fits u-boot's view on such an > > > > extension at all. > > > Yes please to both of you! :-) > > > > > > In the meantime, while we wait for those changes to go upstream in > > > uboot, could you please post a branch on github and a link on this email > > > thread? > > > > It took a bit more time than we expected, but here we go [1]: > > > > this is in form of a pull-request as we would love to hear from the > > > > community and it is easier to discuss the code (please leave comments there) > > > > 1. There is code originating from MiniOS and work done by Peng, so we > > > > would like to ask the respective copyright owners to raise their hands and > > Not everyone are closely watching xen-devel. So if you want to find out who > are the copyright owners, then your best solution is to go through the git log > and CC the authors. That is true. But why do you want to contact them? It doesn't look like there would be any licensing issues. > > let us *fix inappropriate licensing* if any. > > > > 2. Please note, the series has a HACK to move the RAM base as it is expected > > by > > > > our test platform (iMX8), so others will need to remove or modify that. > > > > 3. There is a limitation already noted by Peng that we do not have serial > > output > > > > until MMU is setup, so we have introduced xen_early_printk helper which > > always > > > > works, so you can use that for early stage debugging. > > > > 4. Minimal memory size supported is ~129M because of dtb placement by Xen > > tools > > Hmmm... Why? What's wrong with booting a guest with just 64MB? I agree that it would be nice to support 64MB at least as a minimum. We are talking about embedded here, every byte counts :-) > > > > 5. We use -D__XEN__ to access some of the hidden defines we need such as > > > > GUEST_RAM0_BASE and the friends as there is no other way but manually > > defining the > > > > same which is not cute. > > I have replied to this in the pull request. But I want to bring the > conversation here to have a wider discussion. > > For a first, __XEN__ should really only be defined by the hypervisor and not > used by the guest. This is used to gate non-stable ABI (such as the tools) and > anything behind it hasn't been vetted to work in other build configuration > that the one used by Xen. > > In general, we expect the guest to discover everything for the device-tree > because the memory layout is not stable (we want to be able to reshuffle as we > add more features). > > I know that EDK2/Tianocore can be built once and work on every Xen > configuration. It would be ideal that U-boot follow the same. If it is really > not possible, then we should explore a path that is preventing to define > __XEN__. > > How much does U-boot expect to know about the memory layout? Does it require > to know all the memory banks? Or would it be sufficient for it to know the > start address of the first bank and the minimum of RAM? Copy/pasting here from my comment on the pull request plus additional thoughts. Uboot is one of those embedded projects that typically assumes that all the information about the platform is available at *build time*. It is meant to be built tailored for a specific version of a specific board. A Uboot binary is not expected to be "portable" across different versions of the platform or different platforms. In other words, it is not expected to be portable across Xen versions. This is a different model meant for different use-cases. I don't think it is a problem "philosophically" to let Uboot know about Xen details at build time. Yes, that is not what we did historically but it is very much in the spirit of Uboot. But of course the least Uboot depends on these details the better because it will be more flexible, but it could very well be that we won't be able to reach the point where the binary works on any version like we did with Tianocore. The two projects work differently. That said, I think Julien is right that we need to be careful on how we expose these information to Uboot, i.e. defining __XEN__ to build Uboot doesn't seem like a good idea because we enable definitions that were never meant to be used outside of a Xen build. Also, it wouldn't be easy to know exactly which definitions are actively used by Uboot and which ones aren't. If we are going to make Uboot dependent on version-specific information of the Xen interface, it would be better to be very clear about which definitions we are using. So that one day if we need to change them, we can find them easily. So I think it would be better to introduce a set of defines with the minimum amount of information required by Uboot statically. That way, at least we have a single place where to find all the version-specific definitions that Uboot is using. We can also manage versioning of the Xen interface (like we do in QEMU) if we have to. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 22:17:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 22:17:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2qL-0001sC-Vn; Thu, 18 Jun 2020 22:17:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2qK-0001s7-SZ for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 22:17:08 +0000 X-Inumbo-ID: 72b4dbbc-b1b1-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 72b4dbbc-b1b1-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 22:17:08 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5E0D82083B; Thu, 18 Jun 2020 22:17:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592518627; bh=HsHRQUoX57oUkk6Dfirz9XaoQFQ6mQvR/LpqyiHjNVY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=kN/UQt3aGceAVfoJydwUBZhEsKqKRjlrM/VGcflqFSjDr4icfhKJiZpxFBOAFLPop Ap0qjP4ePjw0+E2ekKjKOcpe+lg0yKP9yUbfnxzegfVqIUB2/I0vVR7TFWNsKyA79X m/eZU+dX1ittpGzmJhacKHKuQz5E84wQmAv6ev4o= Date: Thu, 18 Jun 2020 15:17:06 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [Tee-dev] TEE with XEN In-Reply-To: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> Message-ID: References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peng Fan , Stefano Stabellini , Oleksandr Andrushchenko , Volodymyr Babchuk , Bertrand Marquis , "tee-dev@lists.linaro.org" , Xen-devel , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 18 Jun 2020, Julien Grall wrote: > +Bertrand and Stefano Thanks for CC'ing me > On 16/06/2020 02:24, Volodymyr Babchuk wrote: > > Hi Peng, > > > > On Mon, 15 Jun 2020 at 05:07, Peng Fan wrote: > > > > > > Hi All, > > > > > > While enabling trusty os with xen, I took same approach as OP-TEE, > > > with OP-TEE running in secure world. But I am also thinking this might > > > introduce potential issue is that secure world OS communicate with DomU. > > > If there are some misbehavior in secure world OS, it might let XEN > > > hypervisor not work proper. > > > > > > In my setup, trusty os sometimes panic in secure world, xen will not able > > > to control the panic core anymore. > > May I ask in which case Trusty is panicking? > > > > > > > So I am thinking whether we need to emulating secure world in a XEN VM > > > which is the VM running DomU. Just like what ACRN did to run trusty > > > os. > > > > Well, it depends on whom you are trusting more. Both XEN and TEE are minimal > > OS implementations with aim at security. I'm speaking about generic TEE OS, > > not > > about particular OS like OP-TEE or Trusty. Problem is that, if TEE is > > running inside > > VM, it will be susceptible to a hypervisor misbehaviour. You need to > > understand > > that Xen and privileged domain (dom0, mostly) can access memory of any > > guest. > > At least, in default configuration. There are means to harden this > > setup. But anyways, > > Xen can't be stopped from reading TEE's secrets. > > IIRC, we discussed this approach for OP-TEE in the past. There was other > potential pitfalls with it. For instance, you wouldn't be able to directly > access any secure device from that guest (it is running in non-secure world). Given that Secure World has access to Normal World but not vice versa, it is more natural to run Trusty in one of the Secure execution levels. The expectation is that Trusty has higher privilege, thus it is more "trusted" than anything running in Normal World, including Xen. Of course no client should be able to crash Trusty, so the reality sometimes can be very different from the theory :-) If I were you, I would consider running the TEE "inside" the VM only if the service that the TEE provides is strongly coupled with the VM and doesn't actually need a high level of privilege to function (i.e. doesn't access secure devices or at least not often.) > Depending on whether you can modify Trusty OS, alternative would be to make > itvirtualization aware as OP-TEE did. The core would need to be resilient and > the panic only affect a given client. This would most probably be the best compromise. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 22:20:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 22:20:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2tE-0002fM-FS; Thu, 18 Jun 2020 22:20:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2tD-0002fG-Dj for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 22:20:07 +0000 X-Inumbo-ID: dd2ab2aa-b1b1-11ea-bb01-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dd2ab2aa-b1b1-11ea-bb01-12813bfff9fa; Thu, 18 Jun 2020 22:20:07 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 25C8220732; Thu, 18 Jun 2020 22:20:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592518806; bh=97MnkYmSqV/7tBXJAe7OdCms1pYVADnv/18dq1g0KzI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=e8rk9yTNgVMZQx2ckLhYGaYS6oRixUuILIEWnuRXObzsZATJtO6qqnSpD6M0OyLfn CcComxb8x2TXUaRh5TR6OLKfpH77Zk4eoS4hSJXrclQU1yxVGJK1BTsNU5V0nc3yAG k2eGl43aUne4BamQW2tSZjJ7wZ5YDb9OviXYIoC8= Date: Thu, 18 Jun 2020 15:20:05 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Stefano Stabellini Subject: Re: [PATCH] optee: immediately free buffers that are released by OP-TEE In-Reply-To: Message-ID: References: <20200506014246.3397490-1-volodymyr_babchuk@epam.com> <51b8c855-5e94-2829-a703-d43c84948120@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-707305805-1592518798=:14005" Content-ID: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "tee-dev@lists.linaro.org" , Andrew Cooper , Julien Grall , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-707305805-1592518798=:14005 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: Hi Paul, Julien, Volodymyr hasn't come back with an update to this patch, but I think it is good enough as-is as a bug fix and I would rather have it in its current form in 4.14 than not having it at all leaving the bug unfixed. I think Julien agrees. Paul, are you OK with this? On Mon, 11 May 2020, Stefano Stabellini wrote: > On Mon, 11 May 2020, Andrew Cooper wrote: > > On 11/05/2020 10:34, Julien Grall wrote: > > > Hi Volodymyr, > > > > > > On 06/05/2020 02:44, Volodymyr Babchuk wrote: > > >> Normal World can share buffer with OP-TEE for two reasons: > > >> 1. Some client application wants to exchange data with TA > > >> 2. OP-TEE asks for shared buffer for internal needs > > >> > > >> The second case was handle more strictly than necessary: > > >> > > >> 1. In RPC request OP-TEE asks for buffer > > >> 2. NW allocates buffer and provides it via RPC response > > >> 3. Xen pins pages and translates data > > >> 4. Xen provides buffer to OP-TEE > > >> 5. OP-TEE uses it > > >> 6. OP-TEE sends request to free the buffer > > >> 7. NW frees the buffer and sends the RPC response > > >> 8. Xen unpins pages and forgets about the buffer > > >> > > >> The problem is that Xen should forget about buffer in between stages 6 > > >> and 7. I.e. the right flow should be like this: > > >> > > >> 6. OP-TEE sends request to free the buffer > > >> 7. Xen unpins pages and forgets about the buffer > > >> 8. NW frees the buffer and sends the RPC response > > >> > > >> This is because OP-TEE internally frees the buffer before sending the > > >> "free SHM buffer" request. So we have no reason to hold reference for > > >> this buffer anymore. Moreover, in multiprocessor systems NW have time > > >> to reuse buffer cookie for another buffer. Xen complained about this > > >> and denied the new buffer registration. I have seen this issue while > > >> running tests on iMX SoC. > > >> > > >> So, this patch basically corrects that behavior by freeing the buffer > > >> earlier, when handling RPC return from OP-TEE. > > >> > > >> Signed-off-by: Volodymyr Babchuk > > >> --- > > >>   xen/arch/arm/tee/optee.c | 24 ++++++++++++++++++++---- > > >>   1 file changed, 20 insertions(+), 4 deletions(-) > > >> > > >> diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > > >> index 6a035355db..af19fc31f8 100644 > > >> --- a/xen/arch/arm/tee/optee.c > > >> +++ b/xen/arch/arm/tee/optee.c > > >> @@ -1099,6 +1099,26 @@ static int handle_rpc_return(struct > > >> optee_domain *ctx, > > >>           if ( shm_rpc->xen_arg->cmd == OPTEE_RPC_CMD_SHM_ALLOC ) > > >>               call->rpc_buffer_type = > > >> shm_rpc->xen_arg->params[0].u.value.a; > > >>   +        /* > > >> +         * OP-TEE signals that it frees the buffer that it requested > > >> +         * before. This is the right for us to do the same. > > >> +         */ > > >> +        if ( shm_rpc->xen_arg->cmd == OPTEE_RPC_CMD_SHM_FREE ) > > >> +        { > > >> +            uint64_t cookie = shm_rpc->xen_arg->params[0].u.value.b; > > >> + > > >> +            free_optee_shm_buf(ctx, cookie); > > >> + > > >> +            /* > > >> +             * This should never happen. We have a bug either in the > > >> +             * OP-TEE or in the mediator. > > >> +             */ > > >> +            if ( call->rpc_data_cookie && call->rpc_data_cookie != > > >> cookie ) > > >> +                gprintk(XENLOG_ERR, > > >> +                        "Saved RPC cookie does not corresponds to > > >> OP-TEE's (%"PRIx64" != %"PRIx64")\n", > > > > > > s/corresponds/correspond/ > > > > > >> +                        call->rpc_data_cookie, cookie); > > > > > > IIUC, if you free the wrong SHM buffer then your guest is likely to be > > > running incorrectly afterwards. So shouldn't we crash the guest to > > > avoid further issue? > > > > No - crashing the guest prohibits testing of the interface, and/or the > > guest realising it screwed up and dumping enough state to usefully debug > > what is going on. > > > > Furthermore, if userspace could trigger this path, we'd have to issue an > > XSA. > > > > Crashing the guest is almost never the right thing to do, and definitely > > not appropriate for a bad parameter. > > Maybe we want to close the OPTEE interface for the guest, instead of > crashing the whole VM. I.e. freeing the OPTEE context for the domain > (d->arch.tee)? > > But I think the patch is good as it is honestly. --8323329-707305805-1592518798=:14005-- From xen-devel-bounces@lists.xenproject.org Thu Jun 18 22:21:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 22:21:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2uM-0002ke-Q2; Thu, 18 Jun 2020 22:21:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2uL-0002kZ-MJ for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 22:21:17 +0000 X-Inumbo-ID: 070d1374-b1b2-11ea-bb01-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 070d1374-b1b2-11ea-bb01-12813bfff9fa; Thu, 18 Jun 2020 22:21:17 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 62EAE206FA; Thu, 18 Jun 2020 22:21:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592518876; bh=CAfbf9n3DseA0vfy5RJ+T0k+lqpQXx+WALdwoiPceug=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=w0X7JpPrOMumIZxW75n7Y/1XnRg7IFPv9pXGwc1+Q80mS38rQqDAQzmOTex8qLNIt loGrM0obrNKTDUmEoqjBm2MJxir59SB2EzpBRofyQemr+5GcJQWUuyIAGVir2Cv2Mq JpfcyllUc4qNh5eiDPsi+MqcRsHPv+A2H/vjdizo= Date: Thu, 18 Jun 2020 15:21:15 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: xadimgnik@gmail.com, pdurrant@amazon.co.uk Subject: Re: [PATCH] optee: immediately free buffers that are released by OP-TEE In-Reply-To: Message-ID: References: <20200506014246.3397490-1-volodymyr_babchuk@epam.com> <51b8c855-5e94-2829-a703-d43c84948120@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-836085116-1592518849=:14005" Content-ID: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "tee-dev@lists.linaro.org" , Andrew Cooper , Julien Grall , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-836085116-1592518849=:14005 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: Actually adding Paul On Thu, 18 Jun 2020, Stefano Stabellini wrote: > Hi Paul, Julien, > > Volodymyr hasn't come back with an update to this patch, but I think it > is good enough as-is as a bug fix and I would rather have it in its > current form in 4.14 than not having it at all leaving the bug unfixed. > > I think Julien agrees. > > > Paul, are you OK with this? > > > > On Mon, 11 May 2020, Stefano Stabellini wrote: > > On Mon, 11 May 2020, Andrew Cooper wrote: > > > On 11/05/2020 10:34, Julien Grall wrote: > > > > Hi Volodymyr, > > > > > > > > On 06/05/2020 02:44, Volodymyr Babchuk wrote: > > > >> Normal World can share buffer with OP-TEE for two reasons: > > > >> 1. Some client application wants to exchange data with TA > > > >> 2. OP-TEE asks for shared buffer for internal needs > > > >> > > > >> The second case was handle more strictly than necessary: > > > >> > > > >> 1. In RPC request OP-TEE asks for buffer > > > >> 2. NW allocates buffer and provides it via RPC response > > > >> 3. Xen pins pages and translates data > > > >> 4. Xen provides buffer to OP-TEE > > > >> 5. OP-TEE uses it > > > >> 6. OP-TEE sends request to free the buffer > > > >> 7. NW frees the buffer and sends the RPC response > > > >> 8. Xen unpins pages and forgets about the buffer > > > >> > > > >> The problem is that Xen should forget about buffer in between stages 6 > > > >> and 7. I.e. the right flow should be like this: > > > >> > > > >> 6. OP-TEE sends request to free the buffer > > > >> 7. Xen unpins pages and forgets about the buffer > > > >> 8. NW frees the buffer and sends the RPC response > > > >> > > > >> This is because OP-TEE internally frees the buffer before sending the > > > >> "free SHM buffer" request. So we have no reason to hold reference for > > > >> this buffer anymore. Moreover, in multiprocessor systems NW have time > > > >> to reuse buffer cookie for another buffer. Xen complained about this > > > >> and denied the new buffer registration. I have seen this issue while > > > >> running tests on iMX SoC. > > > >> > > > >> So, this patch basically corrects that behavior by freeing the buffer > > > >> earlier, when handling RPC return from OP-TEE. > > > >> > > > >> Signed-off-by: Volodymyr Babchuk > > > >> --- > > > >>   xen/arch/arm/tee/optee.c | 24 ++++++++++++++++++++---- > > > >>   1 file changed, 20 insertions(+), 4 deletions(-) > > > >> > > > >> diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > > > >> index 6a035355db..af19fc31f8 100644 > > > >> --- a/xen/arch/arm/tee/optee.c > > > >> +++ b/xen/arch/arm/tee/optee.c > > > >> @@ -1099,6 +1099,26 @@ static int handle_rpc_return(struct > > > >> optee_domain *ctx, > > > >>           if ( shm_rpc->xen_arg->cmd == OPTEE_RPC_CMD_SHM_ALLOC ) > > > >>               call->rpc_buffer_type = > > > >> shm_rpc->xen_arg->params[0].u.value.a; > > > >>   +        /* > > > >> +         * OP-TEE signals that it frees the buffer that it requested > > > >> +         * before. This is the right for us to do the same. > > > >> +         */ > > > >> +        if ( shm_rpc->xen_arg->cmd == OPTEE_RPC_CMD_SHM_FREE ) > > > >> +        { > > > >> +            uint64_t cookie = shm_rpc->xen_arg->params[0].u.value.b; > > > >> + > > > >> +            free_optee_shm_buf(ctx, cookie); > > > >> + > > > >> +            /* > > > >> +             * This should never happen. We have a bug either in the > > > >> +             * OP-TEE or in the mediator. > > > >> +             */ > > > >> +            if ( call->rpc_data_cookie && call->rpc_data_cookie != > > > >> cookie ) > > > >> +                gprintk(XENLOG_ERR, > > > >> +                        "Saved RPC cookie does not corresponds to > > > >> OP-TEE's (%"PRIx64" != %"PRIx64")\n", > > > > > > > > s/corresponds/correspond/ > > > > > > > >> +                        call->rpc_data_cookie, cookie); > > > > > > > > IIUC, if you free the wrong SHM buffer then your guest is likely to be > > > > running incorrectly afterwards. So shouldn't we crash the guest to > > > > avoid further issue? > > > > > > No - crashing the guest prohibits testing of the interface, and/or the > > > guest realising it screwed up and dumping enough state to usefully debug > > > what is going on. > > > > > > Furthermore, if userspace could trigger this path, we'd have to issue an > > > XSA. > > > > > > Crashing the guest is almost never the right thing to do, and definitely > > > not appropriate for a bad parameter. > > > > Maybe we want to close the OPTEE interface for the guest, instead of > > crashing the whole VM. I.e. freeing the OPTEE context for the domain > > (d->arch.tee)? > > > > But I think the patch is good as it is honestly. --8323329-836085116-1592518849=:14005-- From xen-devel-bounces@lists.xenproject.org Thu Jun 18 22:26:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 22:26:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2zg-0002wk-EG; Thu, 18 Jun 2020 22:26:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm2zf-0002wf-L0 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 22:26:47 +0000 X-Inumbo-ID: cbb601d6-b1b2-11ea-bb01-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cbb601d6-b1b2-11ea-bb01-12813bfff9fa; Thu, 18 Jun 2020 22:26:47 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3BB5420732; Thu, 18 Jun 2020 22:26:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592519206; bh=6hEaxs3Os3Ntt1eEip0VCSuElqgUOpWvSOqLbFxpfPk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XEwN85c3hFei1VZBeZQedt8vsKczlLKSVb6tRL+pOkwVihSqqYvuxgo8DNqzRFbDw fe/My2II6vSM9ZeFV0aFJEWfGt1+jHtBojJdzSl43F2HQaMSLHUlqUOFBVSXwhawED Zv1WvcU88dUlppBPjg8o5J+lvArPnjV5jLJLdtyI= Date: Thu, 18 Jun 2020 15:26:45 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: xadimgnik@gmail.com, paul@xen.org, pdurrant@amazon.com Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address In-Reply-To: <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> Message-ID: References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: julien@xen.org, "xen-devel@lists.xenproject.org" , "sstabellini@kernel.org" , Volodymyr Babchuk , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Paul, Julien, Volodymyr, This is another bug fix that I would like to get in 4.14. It doesn't look like we need any changes to this patch, assuming that it is accurate to the spec. It would be nice if Volodymyr could provide more info on the spec side, but honestly I trust his experience on this. Paul, are you OK with this going into 4.14? On Sat, 6 Jun 2020, Julien Grall wrote: > (+Paul) > > Hi, > > On 18/05/2020 02:53, Volodymyr Babchuk wrote: > > Trusted Applications use popular approach to determine required size > > of buffer: client provides a memory reference with the NULL pointer to > > a buffer. This is so called "Null memory reference". TA updates the > > NIT: You use double space after '.' here but all the others use a single > space. > > > reference with the required size and returns it back to client. Then > > client allocates buffer of needed size and repeats the operation. > > > > This behavior is described in TEE Client API Specification, paragraph > > 3.2.5. Memory References. > > From the spec, it is not a clear cut that NULL will always used as fetching > the required size of an output buffer. In particular, they suggest to refer to > the protocol. > > In your commit message you indirectly point to an example where 0/NULL would > have a different meaning depending on the flags. This is not explained in the > TEE Client API Specification. Do you have some pointer I could use to check > the behavior? > > > > > OP-TEE represents this null memory reference as a TMEM parameter with > > buf_ptr == NULL. This is the only case when we should allow TMEM > > buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. > > IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer at > address 0" but with the flag cleared, it would mean "return the size". Am I > correct? > > > > > Signed-off-by: Volodymyr Babchuk > The code looks to match your commit message, but I wasn't able to match it > with the spec. Do you have other pointer I could use to check the behavior? > > I assume this wants to be part of Xen 4.14. The change is only for OP-TEE > which is a tech preview feature. So the risk is very limited. From xen-devel-bounces@lists.xenproject.org Thu Jun 18 22:50:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 22:50:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm3Lr-0004di-2H; Thu, 18 Jun 2020 22:49:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm3Lp-0004dd-QO for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 22:49:41 +0000 X-Inumbo-ID: fe4461c6-b1b5-11ea-bb8b-bc764e2007e4 Received: from mail-wm1-x331.google.com (unknown [2a00:1450:4864:20::331]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fe4461c6-b1b5-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 22:49:40 +0000 (UTC) Received: by mail-wm1-x331.google.com with SMTP id y20so7341024wmi.2 for ; Thu, 18 Jun 2020 15:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e4v5lGFAfpa4m/MPKqRqTZ8nc/gfuYPKkhcMxsNKeT4=; b=sIya2hykS0aDKCgm6LdW6vLYW0Y7OMWgkIXWRxIuIxUE/Wf4iQdRatgWVx1kn38/MP H+2Vq4Fvo1IdcAmcfQiC9tOLHz/VhQk2STtVRUB2NVwpB2IA0GRFlBMdLlhqrVKY/f0n RBQgmeMRfgGGFziIlrskILvHGx5TXDCp5Z1DV3zo0PYeLUI+Rh/j9Q8sWdPA6+eHQ03d YJ0fPHS7XyVw5wEPI1BgeY+w1rDrpYAE1YKhZG4tExwjSk01lMIBeASHb66GbHshlKik LWyL/vCwmw/DNGxEe/0AjOef7vEtNr9YbEVoqumMqiU9qG/Uq2GdwhLvfXboWRpQsLf6 gD+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e4v5lGFAfpa4m/MPKqRqTZ8nc/gfuYPKkhcMxsNKeT4=; b=a5mY2HpTDVCZJ7OXNq4uvjNglS+dpm4cfW6Q475eUlbYLtIWvad9pOMJrBg+DL6J4/ ToOBMKyHVKzj7aIcKzkFzdqjAdIoMt4z8jMyErhgQvpf3RZC4HKQQEZqlCg5M9rqKebe yk2yUJCDorM6uhj6H64+s87AKArnuvoe9R8D/CCXV+9Ce1DaQW/SXD/JFZc2gAioR+qK R8+ZvOxVrn3gg6OvUtVlpwRkRrtO/RzdQKlQexw1HihPABxJjgf+yJ1f6CQpwAgtjS/H Il2WWihHo0ucEjL45/N1jp0FFjWUZx7h7Ja9eHRAMx9rBTR2Z7TZ3viVNGvJD/b4HEbV FLXw== X-Gm-Message-State: AOAM532KF+zR0F23OW6px6R0TnYwmaitaZjniwYueevv1LLIAcBERDZS rhLwxqRQPaNd+YYVL0VTbrgLc6zGrxLwd95xpFg= X-Google-Smtp-Source: ABdhPJzVjjjIo24UGU0ekySe9iGYTjHxs1H+O7FYAU2n4DRr/FCblWMUMvvccBi3NTN3xvV+LxOA2+VRISdypg796Ig= X-Received: by 2002:a1c:c1:: with SMTP id 184mr560500wma.74.1592520579547; Thu, 18 Jun 2020 15:49:39 -0700 (PDT) MIME-Version: 1.0 References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> In-Reply-To: From: Julien Grall Date: Thu, 18 Jun 2020 23:49:28 +0100 Message-ID: Subject: Re: UEFI support in ARM DomUs To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 18 Jun 2020 at 23:00, Stefano Stabellini wrote: > > On Thu, 18 Jun 2020, Julien Grall wrote: > > On 18/06/2020 06:22, Oleksandr Andrushchenko wrote: > > > > > > On 6/4/20 6:31 PM, Stefano Stabellini wrote: > > > > On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote: > > > > > On 6/4/20 4:57 AM, Peng Fan wrote: > > > > > > Grall ; > > > > > > > Nataliya Korovkina > > > > > > > Subject: UEFI support in ARM DomUs > > > > > > We have made U-Boot run inside XEN DomU, but just only PV console > > > > > > part, > > > > > > not implement other frontend drivers currently. Would this help for > > > > > > your > > > > > > case if enable EFI in U-Boot? > > > > > Well, we have a working PV block implementation on top of that on iMX8 > > > > > > > > > > platform, mostly ported from mini-os. Currently we are finalizing the > > > > > work > > > > > > > > > > and cleaning up (it's going to take a week or so hopefully). Then, we > > > > > we'll post > > > > > > > > > > it on our public github. We are also thinking about upstreaming the > > > > > work, but it may > > > > > > > > > > take quite some time if the whole idea fits u-boot's view on such an > > > > > extension at all. > > > > Yes please to both of you! :-) > > > > > > > > In the meantime, while we wait for those changes to go upstream in > > > > uboot, could you please post a branch on github and a link on this email > > > > thread? > > > > > > It took a bit more time than we expected, but here we go [1]: > > > > > > this is in form of a pull-request as we would love to hear from the > > > > > > community and it is easier to discuss the code (please leave comments there) > > > > > > 1. There is code originating from MiniOS and work done by Peng, so we > > > > > > would like to ask the respective copyright owners to raise their hands and > > > > Not everyone are closely watching xen-devel. So if you want to find out who > > are the copyright owners, then your best solution is to go through the git log > > and CC the authors. > > That is true. But why do you want to contact them? It doesn't look like > there would be any licensing issues. >From the sentence, I wasn't entirely sure whether he wanted to contact the copyright owner for crediting them in the headers. > > > > > > 5. We use -D__XEN__ to access some of the hidden defines we need such as > > > > > > GUEST_RAM0_BASE and the friends as there is no other way but manually > > > defining the > > > > > > same which is not cute. > > > > I have replied to this in the pull request. But I want to bring the > > conversation here to have a wider discussion. > > > > For a first, __XEN__ should really only be defined by the hypervisor and not > > used by the guest. This is used to gate non-stable ABI (such as the tools) and > > anything behind it hasn't been vetted to work in other build configuration > > that the one used by Xen. > > > > In general, we expect the guest to discover everything for the device-tree > > because the memory layout is not stable (we want to be able to reshuffle as we > > add more features). > > > > I know that EDK2/Tianocore can be built once and work on every Xen > > configuration. It would be ideal that U-boot follow the same. If it is really > > not possible, then we should explore a path that is preventing to define > > __XEN__. > > > > How much does U-boot expect to know about the memory layout? Does it require > > to know all the memory banks? Or would it be sufficient for it to know the > > start address of the first bank and the minimum of RAM? > > Copy/pasting here from my comment on the pull request plus additional > thoughts. > > Uboot is one of those embedded projects that typically assumes that all > the information about the platform is available at *build time*. It is > meant to be built tailored for a specific version of a specific board. A > Uboot binary is not expected to be "portable" across different versions > of the platform or different platforms. In other words, it is not > expected to be portable across Xen versions. Can you define "version" here? Do you refer to the difference in terms of memory? > > This is a different model meant for different use-cases. I don't think > it is a problem "philosophically" to let Uboot know about Xen details at > build time. Yes, that is not what we did historically but it is very > much in the spirit of Uboot. TBH, I don't particularly mind that U-boot is built against a specific version of Xen. I am more concerned about the long term implication if we endorse it and then try to change the memory layout in depth. > > But of course the least Uboot depends on these details the better > because it will be more flexible, but it could very well be that we > won't be able to reach the point where the binary works on any version > like we did with Tianocore. The two projects work differently. Can we have a list of things U-boot require to know at compile time? In particular, I would like to understand if it would be sufficient to only be aware of the first bank. If it is, then my preference would be to standardize that bit of the layout. > That said, I think Julien is right that we need to be careful on how we > expose these information to Uboot, i.e. defining __XEN__ to build Uboot > doesn't seem like a good idea because we enable definitions that were > never meant to be used outside of a Xen build. Also, it wouldn't be easy > to know exactly which definitions are actively used by Uboot and which > ones aren't. > > If we are going to make Uboot dependent on version-specific information > of the Xen interface, it would be better to be very clear about which > definitions we are using. So that one day if we need to change them, we > can find them easily. > > So I think it would be better to introduce a set of defines with the > minimum amount of information required by Uboot statically. That way, > at least we have a single place where to find all the version-specific > definitions that Uboot is using. I am not sure what you are suggesting. Can you expand a bit more? > We can also manage versioning of the > Xen interface (like we do in QEMU) if we have to. Can you provide more details about the compatibility? I am quite interested in the part where you would have to deal with an older QEMU version built against a new Xen? Cheers, From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:29:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:29:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm3y4-0007tV-Ap; Thu, 18 Jun 2020 23:29:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm3y2-0007tQ-Kb for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:29:10 +0000 X-Inumbo-ID: 822bf828-b1bb-11ea-bca7-bc764e2007e4 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (unknown [40.107.2.65]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 822bf828-b1bb-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 23:29:09 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l7Gd3dXLhrflVSrzgXMgM9E3UIM3MYaPlxwf1uBuWldJFDp96B6D3jWeb283H1IxLkoomhwKLaWNSmb10wstPMoChUqCUjgRlEmosXe5lHJBIw1h31LUSDYdRBwnUcWM1OBFWDdfQST2Kr6IBxsbH3P1DqRRuN47svl85BaWGOz/fmOsWUnfNcbdwifPiBZ64QLx367Ty7nw05P6lA27XNx/tp+W80JJExthe1qw0HLbQeocwjG61jFl6qQKamVf/pwS2Il8/bMn1J6ZJpwDKiWDPheNxztyH1me6kwIPkaG5DxA8atsnVBYY089N5lKNzOjj35dnRK2ZpsPrqC0Sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BE3xGRqIJ5fZeXZq5TpIagarg1WJmbmqwsnEhcIfRhE=; b=l3cSafqEj2+S3SoDIp1AOTPRjfc1VGm/4QtfdtMScqQCjI3HjbjorfABdeJ1RFchbmoyLdCDPL5S2mzHofh1fxzNAEUzYeLcnjlqvvaz7x0tGOHCmDVlyPTMqislOIIVjX1219/0We5Mu14QQPHEhBa8WDu3KpAe5wHIjsn4pWmbQUhYeKcWltEzsE+CkalKyA22NU8D/JRny9I/wLrpfAaIhwQp1LBWMpTcUm7NSFCm8HL+iYAKok1hhmSKebvFLPyGgtarjuWk8sSBYlKrcuzF7DQTQHa1P19kZuQPFyqrY7gSZiHux11/pSyIKJc2crAPrFFHuFVGuZpSb5uPLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BE3xGRqIJ5fZeXZq5TpIagarg1WJmbmqwsnEhcIfRhE=; b=FAJApfXIRi9n+MBkiYKio2gOeQDTrFQDFyQl2eWUsdCKCNFhONzJEL8eGZMZrN/f+yQEFY9HYQU/chEs+WKvxZBVCICjBmu4Oiksjiy+qmrSL0GMt5apgKVw7HJJOZpg/xsX9VDsgJTLyI1/Bv2Hka6c7TFpuVRLPJ6PFsxfjuDQz//Ctrvb6GvY2/8nHcjeJBzYWx6ikE6BlJVZYV4591Glc9WOoX5sQhKLsVrWaTmpgiWriXeHms4hcSakfaEXvn9TQFZrCHm5TcnRcME9do28XEHWJgYQUkiI8cvJ8fIPvF2y04C0C2Qf4FO/3geF/Ive76CRxzn3MxEfCNqFCA== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB5005.eurprd03.prod.outlook.com (2603:10a6:803:b7::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 18 Jun 2020 23:29:07 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3088.028; Thu, 18 Jun 2020 23:29:07 +0000 From: Volodymyr Babchuk To: Julien Grall Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address Thread-Topic: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address Thread-Index: AQHWLLcTxhZtogukPEOG78aedSZTLajL0lyAgBNkugA= Date: Thu, 18 Jun 2020 23:29:07 +0000 Message-ID: <878sgk2bst.fsf@epam.com> References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> In-Reply-To: <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.4.10; emacs 26.3 authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 85797aee-a6ba-457f-6371-08d813df6594 x-ms-traffictypediagnostic: VI1PR03MB5005: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kiNeWXaFAg5hzOFMpOXuA69R8cWiek7mro5KMErihYyUwCtGzebnC9Ia7e2N4oRoXysIDEZFEUAVc04m+HhoNhAas24FRsTdRrHHHwrCRQz0el4mAttWFmw+MU5O+43eNZoHxP9ODHUxLqC9cOUOtv3ZPpzKHQ3LMzFN6u5d7FlReJT4O1yRxRodBm2l136bxcWD6izVpI8GpQTVE8+1++NsxcHGom2i50PBiVuRUVN/Xw1lp7c7QFdriUM5ZZmz1ML8h2ahr8m3+VgEkMluub81x9KElsPr9Hv9mfra8NtKwtATmD8bk1s5rgV9M5ooOrfVOniY54zGQvaIY8gGaQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(136003)(396003)(366004)(2906002)(6506007)(53546011)(26005)(83380400001)(6486002)(5660300002)(8936002)(8676002)(71200400001)(55236004)(186003)(36756003)(4326008)(6916009)(66946007)(86362001)(54906003)(316002)(478600001)(76116006)(91956017)(66476007)(64756008)(66556008)(2616005)(66446008)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: RECDs+Z/Oz3USSfu0CwTx1KYeYLeEYoQqqXoewmBb35JY9iZT09rhZTYLDUV5SE0uGjcneNkjxBEUeOOYmRdQ1+QGykDul+uLgOrWTPfxQOqc8qqLqn7rlI0UAV+zmBZHeK4ImoVeqsrvTtyCJShJSdPaKzIsgZKD7imo//B3ZLxjMD9nCvYZDzgZPvU84GzVImd4nc7E1YH4DQQbI0B0b5ZzP4yvz8U8l4nVloj5Mk8NUo9msldaF7QCJG3tOxDYCmCxxur1I+3qPg+HgOpUuxo15Z4KSc3fHdj4M8HGnkOYsn7x1Q60L5vYhj96AMvvBLNwCuVBWyo02zX+SWW8UBS9xBZxIOJLcAFcaZ7epar3U9EIei7+Ikk9E5TW2qL+zdhjiaD9A9h01nESFFcu3CgoIBkKlaRUEW18VLVvXrfFiME3R+LsXDRlll5gaMeifvVcchd/vWQV/eC+k3Nf9sQlS5o1lOVqY8ipYr2Hzg= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 85797aee-a6ba-457f-6371-08d813df6594 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 23:29:07.4704 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: j9qPPnPwFThcVZab86Bo4QHA7LoTrf6HiDSi0TxO/1nDih0Sg6AjGFbjdVAiH8tcu+ng/XHK6lcgmewyVekPkroXS7MuJc6Vs+YJgw9v5R8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB5005 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "sstabellini@kernel.org" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Julien, Julien Grall writes: > (+Paul) > > Hi, > > On 18/05/2020 02:53, Volodymyr Babchuk wrote: >> Trusted Applications use popular approach to determine required size >> of buffer: client provides a memory reference with the NULL pointer to >> a buffer. This is so called "Null memory reference". TA updates the > > NIT: You use double space after '.' here but all the others use a > single space. Oops, missed that. >> reference with the required size and returns it back to client. Then >> client allocates buffer of needed size and repeats the operation. >> >> This behavior is described in TEE Client API Specification, paragraph >> 3.2.5. Memory References. > > From the spec, it is not a clear cut that NULL will always used as > fetching the required size of an output buffer. In particular, they > suggest to refer to the protocol. > > In your commit message you indirectly point to an example where 0/NULL > would have a different meaning depending on the flags. This is not > explained in the TEE Client API Specification. Do you have some > pointer I could use to check the behavior? Well, GP specification describes application interface. It does not specifies how implementation should handle this internally. Basically, GP defines functions, data types, macros, etc to be used by CAs and TAs. But it does not define how exactly call from CA will be delivered to TA. Implementation is free to use any means as far, as they conform with rules described in the specification. OPTEE's REE<->TEE interface is described in the header files, that I added to xen (optee_msg.h, optee_rpc_cmd.h,optee_smc.h). But it does not describe every aspect, unfortunately. >> >> OP-TEE represents this null memory reference as a TMEM parameter with >> buf_ptr =3D=3D NULL. This is the only case when we should allow TMEM >> buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. > > IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer > at address 0" but with the flag cleared, it would mean "return the > size". Am I correct? Not exactly. This flag does not affect behavior for buffers with address NULL. In any case, this would not mean "return the size" to OP-TEE. This is because OP-TEE works as a transport between CA and TA and it does not assign any meaning to client buffers. But certainly, null buffer will mean "return the size" for some TAs, as described in GlobalPlatform specification. Reason why I prohibited buffers without OPTEE_MSG_ATTR_NONCONTIG flag in the the original patch is that such buffers could span across page boundary, which is no-go for fragmented p2m. But I missed that special case: null buffer without OPTEE_MSG_ATTR_NONCONTIG flag. As this is a special type of buffer, it can be allowed with and without said flag. > >> >> Signed-off-by: Volodymyr Babchuk > The code looks to match your commit message, but I wasn't able to > match it with the spec. Do you have other pointer I could use to check > the behavior? > > I assume this wants to be part of Xen 4.14. The change is only for > OP-TEE which is a tech preview feature. So the risk is very limited. Sure. --=20 Volodymyr Babchuk at EPAM= From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:32:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:32:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm41O-0000D7-Qj; Thu, 18 Jun 2020 23:32:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm41N-0000D1-7V for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:32:37 +0000 X-Inumbo-ID: fd5bcba4-b1bb-11ea-bca7-bc764e2007e4 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (unknown [40.107.2.42]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fd5bcba4-b1bb-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 23:32:36 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SIHikpxl1ZW4T/vNKEKLhVhunksozaIlIhG9VUla23z1tpJLbrsOV2plvwxfCYd227Nf2ahl2dT7Q+XdAh3RPgM3ICVC0Cxpcr1O4fAclTbLj8LiVs35hJtMa11tDchOcwRp2S1Bex3ncLqd9uqiWWBLMFtKTL2cEnsJUykaHYTVyKFB740pojIyevAVXDdInwA1yP8CueZ6qo0HNJQefhK3AK54WGB9Mbb7F9id4a5Yy3VRs/U05EGzbrJfsXO+EsqV/QXF3/a2vqrIgsl0zEc1pl2epU2EZ3pr/QWhIQtzlAHMH8LRYdg/YcsLsCQHwp14/WJ1FGY2HLrB9wTRxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e7hZM8c+yFgdJK1pVUcrcRMzanV6KtMbZ2wsOksde2w=; b=f+zHVpkHAtNfeDz3totfozPP1JJtty14bksJcf4Kekm0fUISURX6HFrIj244WdSS2EXrzToIipc70/WhX7wxqTyytcxGz8I0DGa1e382TjlLTNe/EHmEmC1GWNfe+1Xts4JFkWV8g30KuukoBvfgf6QK/qD3SdUdcbWoxBouF3boaVUlE0B8mkZolTskydtkia4Gt1HlVdvhwS4uUwBZu8E+upznsY8+N/2Wk+1P9yB35NXoXJcV4DWQ1NjBczOxpVScl9ozil279ssE3JCo9TmL7V5UxoYfpyL2nOv4LP4TiBsLxwYYFCBIJa080Thxhs2h1akf+yBxXxNZkn9w9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e7hZM8c+yFgdJK1pVUcrcRMzanV6KtMbZ2wsOksde2w=; b=JumNNtQQ6FsONdwCOq8h8bEhrjzvap5qWSnFMl73aNkSlZN89ZQzOnmATvZkZoHWN5hpunE+YQ1wGfpg03TXHEqThsOm6GmeCspSGePypVija/KUNVflEDS5vKYrMEgeepVF6TkhZWA/acHuhDIJ/AO4YUya1SUVq1JZXJZQljwKrZOqkjXv+0CcFZtOCjW/aaBAq5jaRIIxhpDEPCHFGaZStl5xB1zcXFBZgq50WPHg2tFuFr0T0cgdGAYG0zKDKv/6NPAPVsqvgCyLrL0F4Wnh8bcP6uzL4qmhzi3a/vZMAjNDioZ1Uh29v78G7KL9Ma1UvHDReIIGjEUswoRS/w== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB5005.eurprd03.prod.outlook.com (2603:10a6:803:b7::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 18 Jun 2020 23:32:34 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3088.028; Thu, 18 Jun 2020 23:32:34 +0000 From: Volodymyr Babchuk To: Stefano Stabellini Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address Thread-Topic: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address Thread-Index: AQHWLLcTxhZtogukPEOG78aedSZTLajL0lyAgBNTToCAABJigA== Date: Thu, 18 Jun 2020 23:32:34 +0000 Message-ID: <871rmc2bn2.fsf@epam.com> References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.4.10; emacs 26.3 authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bd550ef5-9a10-4c6d-a38a-08d813dfe0cb x-ms-traffictypediagnostic: VI1PR03MB5005: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rzb9BgE26ZRg+FoY1M6xMjggH52/Eh+RROdUpKOJLquiMQCsJvBRyeWwqbMYDbgGQim//buIGjDadex8XpxFgYP1v1lmbBvWoJ7M60vExKuPEqu1TYg+Tcthg7r8EQXABPtAgYOeS9N/rM+CpyGI1UeQZSjUtcXsLE88SqqImUYAH6yPr7dGHxYIbpWMpI5zCHXvf4qmyCVJcTGmd1d1SiiuV9Wh40Pbp8F0oJ8ajksM+9itOcI71jg3pCSG8Ld4yM0qo6DQbSst1O7rVS4nagknd9PVMXKRonrnfX6bhdACMo9QYh7d7WGXasoiuqKYlYTSVnknyaJKrDiAkMG/5A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(136003)(396003)(366004)(2906002)(6506007)(26005)(6486002)(5660300002)(8936002)(8676002)(71200400001)(55236004)(186003)(36756003)(4326008)(6916009)(66946007)(86362001)(54906003)(316002)(4744005)(478600001)(76116006)(91956017)(66476007)(64756008)(66556008)(2616005)(66446008)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: YzMe4UQAbMOSRi/lhioQmhZNjUlgNYR/fjATCQx6icSlLlwK2ww/hhGDKBN9YQNaPFlx11mHDB6Xhu+R5+ELpXpwBgNC0VfhCJLahz7hJTpa5r9/XV43is4dPr9e4YAKtuYXh+t4j15kYo69TEHpIh7BAqLVsoDHvemMH+j7LzVlosffCZPiwDknYOpvGbDxI8DM2Y2kTi6LTrPt9b4zYgitR5mDiDAmdx+7Jraoq7AGDmddqO6KC2TAsnTgQsmAwpQmZtBOFkobB5q0t8jWmKt4BBJU4z01n//sdCf2mGCVcTWu/Q+A70+bfpIek8oMUVbbLjg6e3k5rGxy9PdUW0GkeqSK0vQq/iBXhRrit5JD9pYQB8ddErWl6/2f6h6zGHNiIR+oC3IJZffFFs4uqPhmfQUDZSXKIOIX+pgqB91cLBzIdxOqKeHisqAHpXBjklp7+xzMM/imEvn0nd1lf9ncLRJnQ+e9NKbg1VjYyN0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd550ef5-9a10-4c6d-a38a-08d813dfe0cb X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 23:32:34.1442 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bRmg1Fmn9LXOzcVlhsvEVqg/8Trfp0LDk2DtqYl4MY5DbYXXR4xI3VJGoeJl/8XT1cvVhn1eEGX2ww1nJVgffNWJXZCeDUU8y2YyNjP4YoE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB5005 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "pdurrant@amazon.com" , "julien@xen.org" , "xadimgnik@gmail.com" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Stefano, Stefano Stabellini writes: > Hi Paul, Julien, Volodymyr, > > This is another bug fix that I would like to get in 4.14. It doesn't > look like we need any changes to this patch, assuming that it is > accurate to the spec. > > It would be nice if Volodymyr could provide more info on the spec side, > but honestly I trust his experience on this. I'm sorry for the delay. Julien asks very good and deep questions and it sometimes requires deep research, to fully and correctly answer to them. This was exactly that case. I'll answer timely to the next e-mails. --=20 Volodymyr Babchuk at EPAM= From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:35:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:35:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm43m-0000MF-96; Thu, 18 Jun 2020 23:35:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm43l-0000MA-EU for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:35:05 +0000 X-Inumbo-ID: 55a21aca-b1bc-11ea-8496-bc764e2007e4 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [40.107.6.69]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 55a21aca-b1bc-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 23:35:04 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DXFfk1wvERFgGd+1UXPIcRuwwKox+YOZZEncHUdP1ip3r0asBZLNw5mYmklN1glYZRHTQZWecqVrakBKeC2IfLjAKZJALaeg5yI9t5QgOxm1zb/6MvgoBK+UpaPFO2rTSn5up2Nqcnuqwb3hgiHMpqFWSSNh0VOlSsbIKbIDXLsZX3a4tfkmrg0jVMcHZZv5UkuDRwn95zbzNg5/caqDaus4Ce4wGE/HSY5Vzok/SdbPzSQgf3qX2EUKM+mdwYAWsgG6i5MzcPcXPXrGhPDM3outljvUtE/iO/0SFcJW1B/6HyoED6xmucH0HS/RVewcizb2xIT57M6LJcnlTnpywg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o8+Q+jf5xbjTFhRDwE6iSTk5EhgelitcYhnPXcVkZmQ=; b=nKYnyoZX4yj0mLmLa0g2ZlNlePGg0hh90sll626enLZY7VkG8V1SefBl/PipDUgbu3cABH2spUuZddZ0Sb+KwL6vyeqMOPnMeyWae1+8KcMhFOf5h3B/rUo5eiWFQBb/WI11sjiFbu9+wwxnZzbm5UrRVEtcxVRgVT0nOjbGkJrjQrX0k7gXu0DXXfcaowVpzegQUWzZfnwN/4H8XoZkzRd213ox5OGL1qDwoQjA8QjDOuOZirHHgyHszqexr+/DgNeRXb9+Cd2A93f+38xXz+1cVACCy+ubqmUehkbL4sfjGsseYKotqUsK3Qwyo+2t7DMIZ96i14Dh9NsMf51HqA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o8+Q+jf5xbjTFhRDwE6iSTk5EhgelitcYhnPXcVkZmQ=; b=Pin5fmLU2RFWyU+K2YaFBFb5/MH0wxlBkj1rzVecJwRnuC4yXDYM3IyetCHYmulRvp0se9NdO8KLyL7+L3BnY8PSG4zSuDO1odr0uk+Kq3KbZX4LqlwzZRayAYRH4S0kr7z3hKXD315OOqf2kruaEMJMc20MgQeLVsW3sXnqUa6dzD17q0wca8uqeUJevkXUMby4zKabvnRuN+G2kRV8LXX4y7LH9p6Alv7rGE2IscgqIaMorjepY7a8KAfd0hHua5qWBL461TDNM18kQnMuepKYrrc0D4Ut/jOHiZT634nj2uACen9Y70L6pwcnpJ5v53ZwDb6fGICkp+Tn84+u+g== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB5005.eurprd03.prod.outlook.com (2603:10a6:803:b7::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 18 Jun 2020 23:35:02 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3088.028; Thu, 18 Jun 2020 23:35:02 +0000 From: Volodymyr Babchuk To: Julien Grall Subject: Re: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Topic: [RFC PATCH v1 4/6] xentop: collect IRQ and HYP time statistics. Thread-Index: AQHWQE+Tib/gTK49mk6bUudd1VvXZqjUa0CAgABx3ACAABDmgIAJ7mUAgAACzoCAADJXgA== Date: Thu, 18 Jun 2020 23:35:02 +0000 Message-ID: <87wo440wyi.fsf@epam.com> References: <20200612002205.174295-1-volodymyr_babchuk@epam.com> <20200612002205.174295-5-volodymyr_babchuk@epam.com> <2a0ff6f5-1ada-9d0a-5014-709c873ec3e3@suse.com> <1fcd5d89691b775d1230bf3405e29893107edcb3.camel@epam.com> <92d81acb-fd78-3483-68fb-f52c7bfb3d65@xen.org> <87imfo2kbz.fsf@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.4.10; emacs 26.3 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2159aba7-9564-4816-b06d-08d813e03928 x-ms-traffictypediagnostic: VI1PR03MB5005: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2449; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HTnX3Rys3st1K4mBkhmiDkcaIiJZtPGXWhWJsRdkPJ0EptLgf8op/CMMxB476cZQrvLT/oaKSzlBDOLcLZ78OhiBGu+MMx5aUa7MNPx9FRft1Y6ry1NJA+ReKAetlHVuoj7sQsLMWFjQLy57WY1Wvdls4+cp0BXhMgYejlWB1y1H7i/PVRuh3anVNY+rXmcQupKY0QibPZDpJICgSJRSrqK9by4fJv6SNpgTf52sAgHxRGHGhxWIq7MyBVNXHWvEuvutrSsLOg/uPzjueZth7e3CVMpInzMjzqqUgKh11pYmT2bVU+gFlqYFpbSsx+9ozCY0MXnAskT5KkayCcY8Qg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(478600001)(76116006)(91956017)(86362001)(66946007)(54906003)(316002)(2616005)(66446008)(6512007)(64756008)(66556008)(66476007)(66574015)(6486002)(2906002)(6506007)(53546011)(7416002)(83380400001)(26005)(186003)(55236004)(8676002)(71200400001)(4326008)(6916009)(36756003)(8936002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: uou9zL+D+E8fkdqpQh75gGzaJh57env37euLuqzV/1WYcwGAR+7NUZGSBlSfOGYAxptxq3WcJe667Mdeso+6wRoQzICHIEyropbXuoInTL5YQJfSPI1OH7fIwvKzlRujB4yQoNhzTcSqPe1nyFkopuYqjTQxH2Xj01EmQUPgKgkwGKV3yWjN2aMtw5JPGUkKxatokVXq4u+0j3CzRumT1wlZzCsPVvhVb3fmJjdaM7KzGi/aHeTkwalxTX1O3r4dXnZ7g4jYqFAaGTlnCfF6KEumtv3W7Hbby24K/DifU8eiaM0OiPdLm8sLntG5ca1OsrvllN2xRnGywmtGAaJEXCvNi9bZMdKEwn5tFzh1kV1kzdmU+aaE058xLKzgGsJjrg7dNn8xswqeAQV5b5Rc1DcfnQyUIYfr/wFyBSoboVyWSrDRNaiA3sqsMiq74QgWl/OzQ1I2mloZhyITZZeSPCOMydGqegCBDixSeqhBZv8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2159aba7-9564-4816-b06d-08d813e03928 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 23:35:02.4165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RVd/1xv/oaaNNZ5IXzZvocdEjOKM8YG/Zh0u139DPz8xry8YE3Ngs3/vZ1YByHA667bcW5ZRa2aVoZZNA+vkrBz4l15fsJB9KxKBLKw6ZvI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB5005 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , "sstabellini@kernel.org" , "wl@xen.org" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "george.dunlap@citrix.com" , "dfaggioli@suse.com" , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpIaSBKdWxpZW4sDQoNCkp1bGllbiBHcmFsbCB3cml0ZXM6DQoNCj4gT24gVGh1LCAxOCBKdW4g MjAyMCBhdCAyMToyNCwgVm9sb2R5bXlyIEJhYmNodWsNCj4gPFZvbG9keW15cl9CYWJjaHVrQGVw YW0uY29tPiB3cm90ZToNCj4+DQo+Pg0KPj4gSGkgSnVsaWVuLA0KPj4NCj4+IEp1bGllbiBHcmFs bCB3cml0ZXM6DQo+Pg0KPj4gPiBIaSBWb2xvZHlteXIsDQo+PiA+DQo+PiA+IE9uIDEyLzA2LzIw MjAgMTI6NDQsIFZvbG9keW15ciBCYWJjaHVrIHdyb3RlOg0KPj4gPj4NCj4+ID4+IE9uIEZyaSwg MjAyMC0wNi0xMiBhdCAwNjo1NyArMDIwMCwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4+ID4+PiBP biAxMi4wNi4yMCAwMjoyMiwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+PiA+Pj4+IEFzIHNj aGVkdWxlciBjb2RlIG5vdyBjb2xsZWN0cyB0aW1lIHNwZW50IGluIElSUSBoYW5kbGVycyBhbmQg aW4NCj4+ID4+Pj4gZG9fc29mdGlycSgpLCB3ZSBjYW4gcHJlc2VudCB0aG9zZSB2YWx1ZXMgdG8g dXNlcnNwYWNlIHRvb2xzIGxpa2UNCj4+ID4+Pj4geGVudG9wLCBzbyBzeXN0ZW0gYWRtaW5pc3Ry YXRvciBjYW4gc2VlIGhvdyBzeXN0ZW0gYmVoYXZlcy4NCj4+ID4+Pj4NCj4+ID4+Pj4gV2UgYXJl IHVwZGF0aW5nIGNvdW50ZXJzIG9ubHkgaW4gc2NoZWRfZ2V0X3RpbWVfY29ycmVjdGlvbigpIGZ1 bmN0aW9uDQo+PiA+Pj4+IHRvIG1pbmltaXplIG51bWJlciBvZiB0YWtlbiBzcGlubG9ja3MuIEFz IGF0b21pY190IGlzIDMyIGJpdCB3aWRlLCBpdA0KPj4gPj4+PiBpcyBub3QgZW5vdWdoIHRvIHN0 b3JlIHRpbWUgd2l0aCBuYW5vc2Vjb25kIHByZWNpc2lvbi4gU28gd2UgbmVlZCB0bw0KPj4gPj4+ PiB1c2UgNjQgYml0IHZhcmlhYmxlcyBhbmQgcHJvdGVjdCB0aGVtIHdpdGggc3BpbmxvY2suDQo+ PiA+Pj4+DQo+PiA+Pj4+IFNpZ25lZC1vZmYtYnk6IFZvbG9keW15ciBCYWJjaHVrIDx2b2xvZHlt eXJfYmFiY2h1a0BlcGFtLmNvbT4NCj4+ID4+Pj4gLS0tDQo+PiA+Pj4+ICAgIHhlbi9jb21tb24v c2NoZWQvY29yZS5jICAgICB8IDE3ICsrKysrKysrKysrKysrKysrDQo+PiA+Pj4+ICAgIHhlbi9j b21tb24vc3lzY3RsLmMgICAgICAgICB8ICAxICsNCj4+ID4+Pj4gICAgeGVuL2luY2x1ZGUvcHVi bGljL3N5c2N0bC5oIHwgIDQgKysrLQ0KPj4gPj4+PiAgICB4ZW4vaW5jbHVkZS94ZW4vc2NoZWQu aCAgICAgfCAgMiArKw0KPj4gPj4+PiAgICA0IGZpbGVzIGNoYW5nZWQsIDIzIGluc2VydGlvbnMo KyksIDEgZGVsZXRpb24oLSkNCj4+ID4+Pj4NCj4+ID4+Pj4gZGlmZiAtLWdpdCBhL3hlbi9jb21t b24vc2NoZWQvY29yZS5jIGIveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMNCj4+ID4+Pj4gaW5kZXgg YTcyOTRmZjVjMy4uZWU2YjFkOTE2MSAxMDA2NDQNCj4+ID4+Pj4gLS0tIGEveGVuL2NvbW1vbi9z Y2hlZC9jb3JlLmMNCj4+ID4+Pj4gKysrIGIveGVuL2NvbW1vbi9zY2hlZC9jb3JlLmMNCj4+ID4+ Pj4gQEAgLTk1LDYgKzk1LDEwIEBAIHN0YXRpYyBzdHJ1Y3Qgc2NoZWR1bGVyIF9fcmVhZF9tb3N0 bHkgb3BzOw0KPj4gPj4+PiAgICAgICBzdGF0aWMgYm9vbCBzY2hlZHVsZXJfYWN0aXZlOw0KPj4g Pj4+PiAgICArc3RhdGljIERFRklORV9TUElOTE9DSyhzY2hlZF9zdGF0X2xvY2spOw0KPj4gPj4+ PiArc190aW1lX3Qgc2NoZWRfc3RhdF9pcnFfdGltZTsNCj4+ID4+Pj4gK3NfdGltZV90IHNjaGVk X3N0YXRfaHlwX3RpbWU7DQo+PiA+Pj4+ICsNCj4+ID4+Pj4gICAgc3RhdGljIHZvaWQgc2NoZWRf c2V0X2FmZmluaXR5KA0KPj4gPj4+PiAgICAgICAgc3RydWN0IHNjaGVkX3VuaXQgKnVuaXQsIGNv bnN0IGNwdW1hc2tfdCAqaGFyZCwgY29uc3QgY3B1bWFza190ICpzb2Z0KTsNCj4+ID4+Pj4gICAg QEAgLTk5NCw5ICs5OTgsMjIgQEAgc190aW1lX3Qgc2NoZWRfZ2V0X3RpbWVfY29ycmVjdGlvbihz dHJ1Y3QNCj4+ID4+Pj4gc2NoZWRfdW5pdCAqdSkNCj4+ID4+Pj4gICAgICAgICAgICAgICAgYnJl YWs7DQo+PiA+Pj4+ICAgICAgICB9DQo+PiA+Pj4+ICAgICsgICAgc3Bpbl9sb2NrX2lycXNhdmUo JnNjaGVkX3N0YXRfbG9jaywgZmxhZ3MpOw0KPj4gPj4+PiArICAgIHNjaGVkX3N0YXRfaXJxX3Rp bWUgKz0gaXJxOw0KPj4gPj4+PiArICAgIHNjaGVkX3N0YXRfaHlwX3RpbWUgKz0gaHlwOw0KPj4g Pj4+PiArICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJnNjaGVkX3N0YXRfbG9jaywgZmxhZ3Mp Ow0KPj4gPj4+DQo+PiA+Pj4gUGxlYXNlIGRvbid0IHVzZSBhIGxvY2suIEp1c3QgdXNlIGFkZF9z aXplZCgpIGluc3RlYWQgd2hpY2ggd2lsbCBhZGQNCj4+ID4+PiBhdG9taWNhbGx5Lg0KPj4gPj4N Cj4+ID4+IExvb2tzIGxpa2UgYXJtIGRvZXMgbm90IHN1cHBvcnQgNjQgYml0IHZhcmlhYmxlcy4g Pg0KPj4gPj4gSnVsaWVuLCBJIGJlbGlldmUsIHRoaXMgaXMgYXJtdjcgbGltaXRhdGlvbj8gU2hv dWxkIGFybXY4IHdvcmsgd2l0aCA2NC0NCj4+ID4+IGJpdCBhdG9taWNzPw0KPj4gPg0KPj4gPiA2 NC1iaXQgYXRvbWljcyBjYW4gd29yayBvbiBib3RoIEFybXY3IGFuZCBBcm12OCA6KS4gSXQganVz dCBoYXZlbid0DQo+PiA+IGJlZW4gcGx1bWJlZCB5ZXQuDQo+PiA+DQo+PiA+IEkgYW0gaGFwcHkg dG8gd3JpdGUgYSBwYXRjaCBpZiB5b3UgbmVlZCBhdG9taWM2NF90IG9yIGV2ZW4gYSA2NC1iaXQN Cj4+ID4gYWRkX3NpemVkKCkuDQo+Pg0KPj4gTG9va3MgbGlrZSBJJ2xsIG5lZWQgdGhpcyBwYXRj aC4gU28sIGlmIHlvdSBzdGlsbCBoYXZlIHRpbWUsIGl0IHdpbGwgYmUNCj4+IGdyZWF0LCBpZiB5 b3UnbGwgd3JpdGUgaXQuDQo+DQo+IEkgb2ZmZXJlZCBoZWxwIGZvciBlaXRoZXIgdGhlIGF0b21p YzY0X3Qgb3IgdGhlIGFkZF9zaXplZCgpLiBDYW4geW91DQo+IGNvbmZpcm0gd2hpY2ggb25lIHlv dSBuZWVkPw0KDQpZZXMsIHNvcnJ5LiBJIGhhZCBhdG9taWM2NF90IGluIG1pbmQuDQoNCi0tIA0K Vm9sb2R5bXlyIEJhYmNodWsgYXQgRVBBTQ== From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:35:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:35:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm43r-0000Mk-Iw; Thu, 18 Jun 2020 23:35:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm43q-0000MA-7c for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:35:10 +0000 X-Inumbo-ID: 55622500-b1bc-11ea-8496-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 55622500-b1bc-11ea-8496-bc764e2007e4; Thu, 18 Jun 2020 23:35:03 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id CDD80A303E; Fri, 19 Jun 2020 01:35:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id B0FD1A3037; Fri, 19 Jun 2020 01:35:01 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xXyKT2Mq5nE9; Fri, 19 Jun 2020 01:35:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id D732FA303E; Fri, 19 Jun 2020 01:35:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6f9GeTGTX6mH; Fri, 19 Jun 2020 01:35:00 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id A2865A3037; Fri, 19 Jun 2020 01:35:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 8602621447; Fri, 19 Jun 2020 01:34:30 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id nZULIfJ6rzLJ; Fri, 19 Jun 2020 01:34:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id F0F4021493; Fri, 19 Jun 2020 01:34:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PJnnIJxFyCih; Fri, 19 Jun 2020 01:34:24 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id BBF6521447; Fri, 19 Jun 2020 01:34:24 +0200 (CEST) Date: Fri, 19 Jun 2020 01:34:24 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> Subject: [PATCH v2 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Tamas K Lengyel , Anthony PERARD , "Kang, Luwei" , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Intel Processor Trace is an architectural extension available in modern Intel family CPUs. It allows recording the detailed trace of activity while the processor executes the code. One might use the recorded trace to reconstruct the code flow. It means, to find out the executed code paths, determine branches taken, and so forth. The abovementioned feature is described in Intel(R) 64 and IA-32 Architectures Software Developer's Manual Volume 3C: System Programming Guide, Part 3, Chapter 36: "Intel Processor Trace." This patch series implements an interface that Dom0 could use in order to enable IPT for particular vCPUs in DomU, allowing for external monitoring. Such a feature has numerous applications like malware monitoring, fuzzing, or performance testing. Also thanks to Tamas K Lengyel for a few preliminary hints before first version of this patch was submitted to xen-devel. Changed since v1: * MSR_RTIT_CTL is managed using MSR load lists * other PT-related MSRs are modified only when vCPU goes out of context * trace buffer is now acquired as a resource * added vmtrace_pt_size parameter in xl.cfg, the size of trace buffer must be specified in the moment of domain creation * trace buffers are allocated on domain creation, destructed on domain destruction * HVMOP_vmtrace_ipt_enable/disable is limited to enabling/disabling PT these calls don't manage buffer memory anymore * lifted 32 MFN/GFN array limit when acquiring resources * minor code style changes according to review Michal Leszczynski (7): xen/mm: lift 32 item limit from mfn/gfn arrays x86/vmx: add Intel PT MSR definitions x86/vmx: add IPT cpu feature x86/vmx: add do_vmtrace_op tools/libxc: add xc_vmtrace_* functions tools/libxl: add vmtrace_pt_size parameter tools/proctrace: add proctrace tool tools/golang/xenlight/helpers.gen.go | 2 + tools/golang/xenlight/types.gen.go | 1 + tools/libxc/Makefile | 1 + tools/libxc/include/xenctrl.h | 39 +++ tools/libxc/xc_vmtrace.c | 97 ++++++ tools/libxl/libxl_types.idl | 2 + tools/libxl/libxl_x86.c | 5 + tools/proctrace/COPYING | 339 ++++++++++++++++++++ tools/proctrace/Makefile | 50 +++ tools/proctrace/proctrace.c | 153 +++++++++ tools/xl/xl_parse.c | 4 + xen/arch/x86/hvm/hvm.c | 167 ++++++++++ xen/arch/x86/hvm/vmx/vmcs.c | 4 + xen/arch/x86/hvm/vmx/vmx.c | 24 ++ xen/arch/x86/mm.c | 37 +++ xen/common/domain.c | 1 + xen/common/memory.c | 39 +-- xen/include/asm-x86/cpufeature.h | 1 + xen/include/asm-x86/hvm/hvm.h | 9 + xen/include/asm-x86/hvm/vmx/vmcs.h | 17 + xen/include/asm-x86/msr-index.h | 37 +++ xen/include/public/arch-x86/cpufeatureset.h | 1 + xen/include/public/hvm/hvm_op.h | 23 ++ xen/include/public/hvm/params.h | 5 +- xen/include/public/memory.h | 1 + xen/include/xen/sched.h | 3 + 26 files changed, 1039 insertions(+), 23 deletions(-) create mode 100644 tools/libxc/xc_vmtrace.c create mode 100644 tools/proctrace/COPYING create mode 100644 tools/proctrace/Makefile create mode 100644 tools/proctrace/proctrace.c -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:38:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:38:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm47E-0000bi-4o; Thu, 18 Jun 2020 23:38:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm47D-0000bd-CF for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:38:39 +0000 X-Inumbo-ID: d5692046-b1bc-11ea-bca7-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d5692046-b1bc-11ea-bca7-bc764e2007e4; Thu, 18 Jun 2020 23:38:38 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id AA011A303E; Fri, 19 Jun 2020 01:38:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A79C1A3037; Fri, 19 Jun 2020 01:38:36 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id F06oJBad2ZVS; Fri, 19 Jun 2020 01:38:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 24480A303E; Fri, 19 Jun 2020 01:38:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id msA5h8fHzbdi; Fri, 19 Jun 2020 01:38:36 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id EAC71A3037; Fri, 19 Jun 2020 01:38:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D25832059A; Fri, 19 Jun 2020 01:38:05 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YwEJBqIWbjmm; Fri, 19 Jun 2020 01:38:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 4EC3121493; Fri, 19 Jun 2020 01:38:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TK6es7ReU9sb; Fri, 19 Jun 2020 01:38:00 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 2675A21447; Fri, 19 Jun 2020 01:38:00 +0200 (CEST) Date: Fri, 19 Jun 2020 01:38:00 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <1060400786.9820894.1592523480084.JavaMail.zimbra@cert.pl> In-Reply-To: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> Subject: [PATCH v2 1/7] xen/mm: lift 32 item limit from mfn/gfn arrays MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: xen/mm: lift 32 item limit from mfn/gfn arrays Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyLI0cUXZ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Tamas K Lengyel , "Kang, Luwei" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Replace on-stack array allocation with heap allocation in order to lift the limit of 32 items in mfn/gfn arrays when calling acquire_resource. Signed-off-by: Michal Leszczynski --- xen/common/memory.c | 39 +++++++++++++++++---------------------- 1 file changed, 17 insertions(+), 22 deletions(-) diff --git a/xen/common/memory.c b/xen/common/memory.c index 714077c1e5..e02606ebe5 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -1050,12 +1050,7 @@ static int acquire_resource( { struct domain *d, *currd = current->domain; xen_mem_acquire_resource_t xmar; - /* - * The mfn_list and gfn_list (below) arrays are ok on stack for the - * moment since they are small, but if they need to grow in future - * use-cases then per-CPU arrays or heap allocations may be required. - */ - xen_pfn_t mfn_list[32]; + xen_pfn_t *mfn_list; int rc; if ( copy_from_guest(&xmar, arg, 1) ) @@ -1064,25 +1059,17 @@ static int acquire_resource( if ( xmar.pad != 0 ) return -EINVAL; - if ( guest_handle_is_null(xmar.frame_list) ) - { - if ( xmar.nr_frames ) - return -EINVAL; - - xmar.nr_frames = ARRAY_SIZE(mfn_list); - - if ( __copy_field_to_guest(arg, &xmar, nr_frames) ) - return -EFAULT; - - return 0; - } + mfn_list = xmalloc_array(xen_pfn_t, xmar.nr_frames); - if ( xmar.nr_frames > ARRAY_SIZE(mfn_list) ) - return -E2BIG; + if ( ! mfn_list ) + return -EFAULT; rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); if ( rc ) + { + xfree(mfn_list); return rc; + } rc = xsm_domain_resource_map(XSM_DM_PRIV, d); if ( rc ) @@ -1111,7 +1098,7 @@ static int acquire_resource( } else { - xen_pfn_t gfn_list[ARRAY_SIZE(mfn_list)]; + xen_pfn_t *gfn_list; unsigned int i; /* @@ -1120,7 +1107,12 @@ static int acquire_resource( * resource pages unless the caller is the hardware domain. */ if ( !is_hardware_domain(currd) ) - return -EACCES; + { + rc = -EACCES; + goto out; + } + + gfn_list = xmalloc_array(xen_pfn_t, xmar.nr_frames); if ( copy_from_guest(gfn_list, xmar.frame_list, xmar.nr_frames) ) rc = -EFAULT; @@ -1133,9 +1125,12 @@ static int acquire_resource( if ( rc && i ) rc = -EIO; } + + xfree(gfn_list); } out: + xfree(mfn_list); rcu_unlock_domain(d); return rc; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:40:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:40:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm48m-0001MM-Gq; Thu, 18 Jun 2020 23:40:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm48k-0001MG-VZ for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:40:15 +0000 X-Inumbo-ID: 0e4fef48-b1bd-11ea-bb0d-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0e4fef48-b1bd-11ea-bb0d-12813bfff9fa; Thu, 18 Jun 2020 23:40:14 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2B59FA30C7; Fri, 19 Jun 2020 01:40:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1E79FA3107; Fri, 19 Jun 2020 01:40:12 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ePoMG7alAwZC; Fri, 19 Jun 2020 01:40:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9C30BA30D9; Fri, 19 Jun 2020 01:40:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wgORxRw3ojJL; Fri, 19 Jun 2020 01:40:11 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7407FA30C7; Fri, 19 Jun 2020 01:40:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 5D9502059A; Fri, 19 Jun 2020 01:39:41 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id NU5woIfCpQRp; Fri, 19 Jun 2020 01:39:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id E60DD215FA; Fri, 19 Jun 2020 01:39:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5_UMZebq8ABB; Fri, 19 Jun 2020 01:39:35 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id BEFA72059A; Fri, 19 Jun 2020 01:39:35 +0200 (CEST) Date: Fri, 19 Jun 2020 01:39:35 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <61296395.9820908.1592523575731.JavaMail.zimbra@cert.pl> In-Reply-To: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> Subject: [PATCH v2 2/7] x86/vmx: add Intel PT MSR definitions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add Intel PT MSR definitions Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyPG5uWby X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Kang, Luwei" , Wei Liu , Andrew Cooper , Jan Beulich , Tamas K Lengyel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Define constants related to Intel Processor Trace features. Signed-off-by: Michal Leszczynski --- xen/include/asm-x86/msr-index.h | 37 +++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h index b328a47ed8..812516f340 100644 --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -621,4 +621,41 @@ #define MSR_PKGC9_IRTL 0x00000634 #define MSR_PKGC10_IRTL 0x00000635 +/* Intel PT MSRs */ +#define MSR_RTIT_OUTPUT_BASE 0x00000560 +#define MSR_RTIT_OUTPUT_MASK 0x00000561 +#define MSR_RTIT_CTL 0x00000570 +#define RTIT_CTL_TRACEEN (_AC(1, ULL) << 0) +#define RTIT_CTL_CYCEN (_AC(1, ULL) << 1) +#define RTIT_CTL_OS (_AC(1, ULL) << 2) +#define RTIT_CTL_USR (_AC(1, ULL) << 3) +#define RTIT_CTL_PWR_EVT_EN (_AC(1, ULL) << 4) +#define RTIT_CTL_FUP_ON_PTW (_AC(1, ULL) << 5) +#define RTIT_CTL_FABRIC_EN (_AC(1, ULL) << 6) +#define RTIT_CTL_CR3_FILTER (_AC(1, ULL) << 7) +#define RTIT_CTL_TOPA (_AC(1, ULL) << 8) +#define RTIT_CTL_MTC_EN (_AC(1, ULL) << 9) +#define RTIT_CTL_TSC_EN (_AC(1, ULL) << 10) +#define RTIT_CTL_DIS_RETC (_AC(1, ULL) << 11) +#define RTIT_CTL_PTW_EN (_AC(1, ULL) << 12) +#define RTIT_CTL_BRANCH_EN (_AC(1, ULL) << 13) +#define RTIT_CTL_MTC_FREQ_OFFSET 14 +#define RTIT_CTL_MTC_FREQ (0x0fULL << RTIT_CTL_MTC_FREQ_OFFSET) +#define RTIT_CTL_CYC_THRESH_OFFSET 19 +#define RTIT_CTL_CYC_THRESH (0x0fULL << RTIT_CTL_CYC_THRESH_OFFSET) +#define RTIT_CTL_PSB_FREQ_OFFSET 24 +#define RTIT_CTL_PSB_FREQ (0x0fULL << RTIT_CTL_PSB_FREQ_OFFSET) +#define RTIT_CTL_ADDR_OFFSET(n) (32 + 4 * (n)) +#define RTIT_CTL_ADDR(n) (0x0fULL << RTIT_CTL_ADDR_OFFSET(n)) +#define MSR_RTIT_STATUS 0x00000571 +#define RTIT_STATUS_FILTER_EN (_AC(1, ULL) << 0) +#define RTIT_STATUS_CONTEXT_EN (_AC(1, ULL) << 1) +#define RTIT_STATUS_TRIGGER_EN (_AC(1, ULL) << 2) +#define RTIT_STATUS_ERROR (_AC(1, ULL) << 4) +#define RTIT_STATUS_STOPPED (_AC(1, ULL) << 5) +#define RTIT_STATUS_BYTECNT (0x1ffffULL << 32) +#define MSR_RTIT_CR3_MATCH 0x00000572 +#define MSR_RTIT_ADDR_A(n) (0x00000580 + (n) * 2) +#define MSR_RTIT_ADDR_B(n) (0x00000581 + (n) * 2) + #endif /* __ASM_MSR_INDEX_H */ -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:41:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:41:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm49V-0001QS-R3; Thu, 18 Jun 2020 23:41:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm49V-0001QM-CS for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:41:01 +0000 X-Inumbo-ID: 29f8c6ca-b1bd-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 29f8c6ca-b1bd-11ea-b7bb-bc764e2007e4; Thu, 18 Jun 2020 23:41:00 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9FE36A30D9; Fri, 19 Jun 2020 01:40:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 92934A30C7; Fri, 19 Jun 2020 01:40:58 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id WknqXp5-8-yZ; Fri, 19 Jun 2020 01:40:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id CF581A30D9; Fri, 19 Jun 2020 01:40:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Y5oS8u3hbHyS; Fri, 19 Jun 2020 01:40:57 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id AA3DAA30C7; Fri, 19 Jun 2020 01:40:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 9CF192059A; Fri, 19 Jun 2020 01:40:27 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Y1ZQch1Q1ym7; Fri, 19 Jun 2020 01:40:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 0D583215FA; Fri, 19 Jun 2020 01:40:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id v4RaGm9zPPRR; Fri, 19 Jun 2020 01:40:21 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id D64412059A; Fri, 19 Jun 2020 01:40:21 +0200 (CEST) Date: Fri, 19 Jun 2020 01:40:21 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <626789888.9820937.1592523621821.JavaMail.zimbra@cert.pl> In-Reply-To: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> Subject: [PATCH v2 3/7] x86/vmx: add IPT cpu feature MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add IPT cpu feature Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyBGenYvm X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , "Kang, Luwei" , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Tamas K Lengyel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Check if Intel Processor Trace feature is supported by current processor. Define hvm_ipt_supported function. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/vmx/vmcs.c | 4 ++++ xen/include/asm-x86/cpufeature.h | 1 + xen/include/asm-x86/hvm/hvm.h | 9 +++++++++ xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + xen/include/public/arch-x86/cpufeatureset.h | 1 + 5 files changed, 16 insertions(+) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index ca94c2bedc..8466ccb912 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -315,6 +315,10 @@ static int vmx_init_vmcs_config(void) if ( opt_ept_pml ) opt |= SECONDARY_EXEC_ENABLE_PML; + /* Check whether IPT is supported in VMX operation */ + hvm_funcs.pt_supported = cpu_has_ipt && + ( _vmx_misc_cap & VMX_MISC_PT_SUPPORTED ); + /* * "APIC Register Virtualization" and "Virtual Interrupt Delivery" * can be set only when "use TPR shadow" is set diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h index f790d5c1f8..8d7955dd87 100644 --- a/xen/include/asm-x86/cpufeature.h +++ b/xen/include/asm-x86/cpufeature.h @@ -104,6 +104,7 @@ #define cpu_has_clwb boot_cpu_has(X86_FEATURE_CLWB) #define cpu_has_avx512er boot_cpu_has(X86_FEATURE_AVX512ER) #define cpu_has_avx512cd boot_cpu_has(X86_FEATURE_AVX512CD) +#define cpu_has_ipt boot_cpu_has(X86_FEATURE_IPT) #define cpu_has_sha boot_cpu_has(X86_FEATURE_SHA) #define cpu_has_avx512bw boot_cpu_has(X86_FEATURE_AVX512BW) #define cpu_has_avx512vl boot_cpu_has(X86_FEATURE_AVX512VL) diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h index 1eb377dd82..8c0d0ece67 100644 --- a/xen/include/asm-x86/hvm/hvm.h +++ b/xen/include/asm-x86/hvm/hvm.h @@ -96,6 +96,9 @@ struct hvm_function_table { /* Necessary hardware support for alternate p2m's? */ bool altp2m_supported; + /* Hardware support for processor tracing? */ + bool pt_supported; + /* Hardware virtual interrupt delivery enable? */ bool virtual_intr_delivery_enabled; @@ -630,6 +633,12 @@ static inline bool hvm_altp2m_supported(void) return hvm_funcs.altp2m_supported; } +/* returns true if hardware supports Intel Processor Trace */ +static inline bool hvm_pt_supported(void) +{ + return hvm_funcs.pt_supported; +} + /* updates the current hardware p2m */ static inline void altp2m_vcpu_update_p2m(struct vcpu *v) { diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h index 906810592f..4c81093aba 100644 --- a/xen/include/asm-x86/hvm/vmx/vmcs.h +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h @@ -285,6 +285,7 @@ extern u64 vmx_ept_vpid_cap; #define VMX_MISC_CR3_TARGET 0x01ff0000 #define VMX_MISC_VMWRITE_ALL 0x20000000 +#define VMX_MISC_PT_SUPPORTED 0x00004000 #define VMX_TSC_MULTIPLIER_MAX 0xffffffffffffffffULL diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 5ca35d9d97..0d3f15f628 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -217,6 +217,7 @@ XEN_CPUFEATURE(SMAP, 5*32+20) /*S Supervisor Mode Access Prevention */ XEN_CPUFEATURE(AVX512_IFMA, 5*32+21) /*A AVX-512 Integer Fused Multiply Add */ XEN_CPUFEATURE(CLFLUSHOPT, 5*32+23) /*A CLFLUSHOPT instruction */ XEN_CPUFEATURE(CLWB, 5*32+24) /*A CLWB instruction */ +XEN_CPUFEATURE(IPT, 5*32+25) /* Intel Processor Trace */ XEN_CPUFEATURE(AVX512PF, 5*32+26) /*A AVX-512 Prefetch Instructions */ XEN_CPUFEATURE(AVX512ER, 5*32+27) /*A AVX-512 Exponent & Reciprocal Instrs */ XEN_CPUFEATURE(AVX512CD, 5*32+28) /*A AVX-512 Conflict Detection Instrs */ -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:41:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:41:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4AD-0001Vx-4e; Thu, 18 Jun 2020 23:41:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4AC-0001Vm-42 for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:41:44 +0000 X-Inumbo-ID: 431e8cac-b1bd-11ea-bb0d-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 431e8cac-b1bd-11ea-bb0d-12813bfff9fa; Thu, 18 Jun 2020 23:41:42 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id B4BD3A30D9; Fri, 19 Jun 2020 01:41:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A99A5A30C7; Fri, 19 Jun 2020 01:41:40 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9ygDCIWrKsf2; Fri, 19 Jun 2020 01:41:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id BCF7EA30D9; Fri, 19 Jun 2020 01:41:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id B-EdGVto19Q2; Fri, 19 Jun 2020 01:41:39 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 8B45EA30C7; Fri, 19 Jun 2020 01:41:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 7A2572059A; Fri, 19 Jun 2020 01:41:09 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZvupjoWRDJTP; Fri, 19 Jun 2020 01:41:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 61350216B0; Fri, 19 Jun 2020 01:41:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 39RlJeFx7jAG; Fri, 19 Jun 2020 01:41:03 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 3B25B2165A; Fri, 19 Jun 2020 01:41:03 +0200 (CEST) Date: Fri, 19 Jun 2020 01:41:03 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> In-Reply-To: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> Subject: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyEuhVFaU X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Tamas K Lengyel , "Kang, Luwei" , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Provide an interface for privileged domains to manage external IPT monitoring. Guest IPT state will be preserved across vmentry/vmexit using ipt_state structure. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/hvm.c | 167 +++++++++++++++++++++++++++++ xen/arch/x86/hvm/vmx/vmx.c | 24 +++++ xen/arch/x86/mm.c | 37 +++++++ xen/common/domain.c | 1 + xen/include/asm-x86/hvm/vmx/vmcs.h | 16 +++ xen/include/public/hvm/hvm_op.h | 23 ++++ xen/include/public/hvm/params.h | 5 +- xen/include/public/memory.h | 1 + xen/include/xen/sched.h | 3 + 9 files changed, 276 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 5bb47583b3..145ad053d2 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1612,6 +1612,24 @@ int hvm_vcpu_initialise(struct vcpu *v) return rc; } +void hvm_vmtrace_destroy(struct vcpu *v) +{ + unsigned int i; + struct page_info *pg; + struct ipt_state *ipt = v->arch.hvm.vmx.ipt_state; + mfn_t buf_mfn = ipt->output_base >> PAGE_SHIFT; + size_t buf_size = ipt->output_mask.size + 1; + + xfree(ipt); + v->arch.hvm.vmx.ipt_state = NULL; + + for ( i = 0; i < (buf_size >> PAGE_SHIFT); i++ ) + { + pg = mfn_to_page(_mfn(mfn_add(buf_mfn, i))); + free_domheap_page(pg); + } +} + void hvm_vcpu_destroy(struct vcpu *v) { viridian_vcpu_deinit(v); @@ -1631,6 +1649,8 @@ void hvm_vcpu_destroy(struct vcpu *v) vlapic_destroy(v); hvm_vcpu_cacheattr_destroy(v); + + hvm_vmtrace_destroy(v); } void hvm_vcpu_down(struct vcpu *v) @@ -4066,6 +4086,51 @@ static int hvmop_set_evtchn_upcall_vector( return 0; } +static int hvm_set_vmtrace_pt_size(struct domain *d, uint64_t value) +{ + void *buf; + unsigned int buf_order; + struct page_info *pg; + struct ipt_state *ipt; + struct vcpu *v; + + if ( value < PAGE_SIZE || + value > GB(4) || + ( value & (value - 1) ) ) { + /* we don't accept trace buffer size smaller than single page + * and the upper bound is defined as 4GB in the specification */ + return -EINVAL; + } + + for_each_vcpu ( d, v ) + { + buf_order = get_order_from_bytes(value); + pg = alloc_domheap_pages(d, buf_order, MEMF_no_refcount); + + if ( !pg ) + return -EFAULT; + + buf = page_to_virt(pg); + + if ( vmx_add_host_load_msr(v, MSR_RTIT_CTL, 0) ) + return -EFAULT; + + ipt = xmalloc(struct ipt_state); + + if ( !ipt ) + return -EFAULT; + + ipt->output_base = virt_to_mfn(buf) << PAGE_SHIFT; + ipt->output_mask.raw = value - 1; + ipt->status = 0; + ipt->active = 0; + + v->arch.hvm.vmx.ipt_state = ipt; + } + + return 0; +} + static int hvm_allow_set_param(struct domain *d, uint32_t index, uint64_t new_value) @@ -4127,6 +4192,7 @@ static int hvm_allow_set_param(struct domain *d, case HVM_PARAM_NR_IOREQ_SERVER_PAGES: case HVM_PARAM_ALTP2M: case HVM_PARAM_MCA_CAP: + case HVM_PARAM_VMTRACE_PT_SIZE: if ( value != 0 && new_value != value ) rc = -EEXIST; break; @@ -4328,6 +4394,9 @@ static int hvm_set_param(struct domain *d, uint32_t index, uint64_t value) case HVM_PARAM_MCA_CAP: rc = vmce_enable_mca_cap(d, value); break; + case HVM_PARAM_VMTRACE_PT_SIZE: + rc = hvm_set_vmtrace_pt_size(d, value); + break; } if ( !rc ) @@ -4949,6 +5018,100 @@ static int compat_altp2m_op( return rc; } +static int do_vmtrace_op(XEN_GUEST_HANDLE_PARAM(void) arg) +{ + struct xen_hvm_vmtrace_op a; + struct domain *d; + int rc; + struct vcpu *v; + struct ipt_state *ipt; + + if ( !hvm_pt_supported() ) + return -EOPNOTSUPP; + + if ( copy_from_guest(&a, arg, 1) ) + return -EFAULT; + + if ( a.version != HVMOP_VMTRACE_INTERFACE_VERSION ) + return -EINVAL; + + d = rcu_lock_domain_by_any_id(a.domain); + spin_lock(&d->vmtrace_lock); + + if ( d == NULL ) + return -ESRCH; + + if ( !is_hvm_domain(d) ) + { + rc = -EOPNOTSUPP; + goto out; + } + + domain_pause(d); + + if ( a.vcpu >= d->max_vcpus ) + { + rc = -EINVAL; + goto out; + } + + v = d->vcpu[a.vcpu]; + ipt = v->arch.hvm.vmx.ipt_state; + + if ( !ipt ) + { + /* + * PT must be first initialized upon domain creation. + */ + rc = -EINVAL; + goto out; + } + + switch ( a.cmd ) + { + case HVMOP_vmtrace_ipt_enable: + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, + RTIT_CTL_TRACEEN | RTIT_CTL_OS | + RTIT_CTL_USR | RTIT_CTL_BRANCH_EN) ) + { + rc = -EFAULT; + goto out; + } + + ipt->active = 1; + break; + case HVMOP_vmtrace_ipt_disable: + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, 0) ) + { + rc = -EFAULT; + goto out; + } + + ipt->active = 0; + break; + case HVMOP_vmtrace_ipt_get_offset: + a.offset = ipt->output_mask.offset; + break; + default: + rc = -EOPNOTSUPP; + goto out; + } + + rc = -EFAULT; + if ( __copy_to_guest(arg, &a, 1) ) + goto out; + rc = 0; + + out: + domain_unpause(d); + spin_unlock(&d->vmtrace_lock); + rcu_unlock_domain(d); + + return rc; +} + +DEFINE_XEN_GUEST_HANDLE(compat_hvm_vmtrace_op_t); + static int hvmop_get_mem_type( XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg) { @@ -5101,6 +5264,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) rc = current->hcall_compat ? compat_altp2m_op(arg) : do_altp2m_op(arg); break; + case HVMOP_vmtrace: + rc = do_vmtrace_op(arg); + break; + default: { gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op); diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index ab19d9424e..51f0046483 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -508,11 +508,25 @@ static void vmx_restore_host_msrs(void) static void vmx_save_guest_msrs(struct vcpu *v) { + uint64_t rtit_ctl; + /* * We cannot cache SHADOW_GS_BASE while the VCPU runs, as it can * be updated at any time via SWAPGS, which we cannot trap. */ v->arch.hvm.vmx.shadow_gs = rdgsshadow(); + + if ( unlikely(v->arch.hvm.vmx.ipt_state && v->arch.hvm.vmx.ipt_state->active) ) + { + smp_rmb(); + rdmsrl(MSR_RTIT_CTL, rtit_ctl); + + if ( rtit_ctl & RTIT_CTL_TRACEEN ) + BUG(); + + rdmsrl(MSR_RTIT_STATUS, v->arch.hvm.vmx.ipt_state->status); + rdmsrl(MSR_RTIT_OUTPUT_MASK, v->arch.hvm.vmx.ipt_state->output_mask.raw); + } } static void vmx_restore_guest_msrs(struct vcpu *v) @@ -524,6 +538,16 @@ static void vmx_restore_guest_msrs(struct vcpu *v) if ( cpu_has_msr_tsc_aux ) wrmsr_tsc_aux(v->arch.msrs->tsc_aux); + + if ( unlikely(v->arch.hvm.vmx.ipt_state && v->arch.hvm.vmx.ipt_state->active) ) + { + wrmsrl(MSR_RTIT_OUTPUT_BASE, + v->arch.hvm.vmx.ipt_state->output_base); + wrmsrl(MSR_RTIT_OUTPUT_MASK, + v->arch.hvm.vmx.ipt_state->output_mask.raw); + wrmsrl(MSR_RTIT_STATUS, + v->arch.hvm.vmx.ipt_state->status); + } } void vmx_update_cpu_exec_control(struct vcpu *v) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e376fc7e8f..e4658dc27f 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4624,6 +4624,43 @@ int arch_acquire_resource(struct domain *d, unsigned int type, } break; } + + case XENMEM_resource_vmtrace_buf: + { + mfn_t mfn; + unsigned int i; + struct ipt_state *ipt; + + if ( id >= d->max_vcpus ) + { + rc = -EINVAL; + break; + } + + ipt = d->vcpu[id]->arch.hvm.vmx.ipt_state; + + if ( !ipt ) + { + rc = -EINVAL; + break; + } + + mfn = mfn_x(ipt->output_base >> PAGE_SHIFT); + + if (nr_frames > ( ( ipt->output_mask.size + 1 ) >> PAGE_SHIFT )) + { + rc = -EINVAL; + break; + } + + rc = 0; + for ( i = 0; i < nr_frames; i++ ) + { + mfn_list[i] = mfn_add(mfn, i); + } + + break; + } #endif default: diff --git a/xen/common/domain.c b/xen/common/domain.c index 7cc9526139..6f6458cd5b 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -414,6 +414,7 @@ struct domain *domain_create(domid_t domid, d->shutdown_code = SHUTDOWN_CODE_INVALID; spin_lock_init(&d->pbuf_lock); + spin_lock_init(&d->vmtrace_lock); rwlock_init(&d->vnuma_rwlock); diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h index 4c81093aba..9fc4653777 100644 --- a/xen/include/asm-x86/hvm/vmx/vmcs.h +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h @@ -104,6 +104,19 @@ struct pi_blocking_vcpu { spinlock_t *lock; }; +struct ipt_state { + uint64_t active; + uint64_t status; + uint64_t output_base; + union { + uint64_t raw; + struct { + uint32_t size; + uint32_t offset; + }; + } output_mask; +}; + struct vmx_vcpu { /* Physical address of VMCS. */ paddr_t vmcs_pa; @@ -186,6 +199,9 @@ struct vmx_vcpu { * pCPU and wakeup the related vCPU. */ struct pi_blocking_vcpu pi_blocking; + + /* State of Intel Processor Trace feature */ + struct ipt_state *ipt_state; }; int vmx_create_vmcs(struct vcpu *v); diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h index 870ec52060..8cd0b6ea49 100644 --- a/xen/include/public/hvm/hvm_op.h +++ b/xen/include/public/hvm/hvm_op.h @@ -382,6 +382,29 @@ struct xen_hvm_altp2m_op { typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); +/* HVMOP_vmtrace: Perform VM tracing related operation */ +#define HVMOP_vmtrace 26 + +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 + +struct xen_hvm_vmtrace_op { + /* IN variable */ + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ + uint32_t cmd; +/* Enable/disable external vmtrace for given domain */ +#define HVMOP_vmtrace_ipt_enable 1 +#define HVMOP_vmtrace_ipt_disable 2 +#define HVMOP_vmtrace_ipt_get_offset 3 + domid_t domain; + uint32_t vcpu; + uint64_t size; + + /* OUT variable */ + uint64_t offset; +}; +typedef struct xen_hvm_vmtrace_op xen_hvm_vmtrace_op_t; +DEFINE_XEN_GUEST_HANDLE(xen_hvm_vmtrace_op_t); + #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */ /* diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h index 0a91bfa749..adbc7e5d08 100644 --- a/xen/include/public/hvm/params.h +++ b/xen/include/public/hvm/params.h @@ -300,6 +300,9 @@ #define XEN_HVM_MCA_CAP_LMCE (xen_mk_ullong(1) << 0) #define XEN_HVM_MCA_CAP_MASK XEN_HVM_MCA_CAP_LMCE -#define HVM_NR_PARAMS 39 +/* VM trace capabilities */ +#define HVM_PARAM_VMTRACE_PT_SIZE 39 + +#define HVM_NR_PARAMS 40 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */ diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index dbd35305df..f823c784c3 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -620,6 +620,7 @@ struct xen_mem_acquire_resource { #define XENMEM_resource_ioreq_server 0 #define XENMEM_resource_grant_table 1 +#define XENMEM_resource_vmtrace_buf 2 /* * IN - a type-specific resource identifier, which must be zero diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index ac53519d7f..b3a36f3788 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -457,6 +457,9 @@ struct domain unsigned pbuf_idx; spinlock_t pbuf_lock; + /* Used by vmtrace domctls */ + spinlock_t vmtrace_lock; + /* OProfile support. */ struct xenoprof *xenoprof; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:42:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:42:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4Ak-0001bK-HS; Thu, 18 Jun 2020 23:42:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4Aj-0001b9-BE for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:42:17 +0000 X-Inumbo-ID: 56ece1f2-b1bd-11ea-bb0d-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 56ece1f2-b1bd-11ea-bb0d-12813bfff9fa; Thu, 18 Jun 2020 23:42:16 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 11DE2A30D9; Fri, 19 Jun 2020 01:42:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 09E4BA30C7; Fri, 19 Jun 2020 01:42:14 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id STBNX7WuqB4b; Fri, 19 Jun 2020 01:42:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 61647A30D9; Fri, 19 Jun 2020 01:42:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id A093swVWaL80; Fri, 19 Jun 2020 01:42:13 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 42F71A30C7; Fri, 19 Jun 2020 01:42:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 32F14216FE; Fri, 19 Jun 2020 01:41:43 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JhuFvCO24gwZ; Fri, 19 Jun 2020 01:41:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 77C612165A; Fri, 19 Jun 2020 01:41:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rn7me6lTfX3G; Fri, 19 Jun 2020 01:41:37 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 558C7215FA; Fri, 19 Jun 2020 01:41:37 +0200 (CEST) Date: Fri, 19 Jun 2020 01:41:37 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <1593123263.9820951.1592523697296.JavaMail.zimbra@cert.pl> In-Reply-To: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> Subject: [PATCH v2 5/7] tools/libxc: add xc_vmtrace_* functions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: tools/libxc: add xc_vmtrace_* functions Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyOzjXSg4 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Ian Jackson , "Kang, Luwei" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add functions in libxc that use the new HVMOP_vmtrace interface. Signed-off-by: Michal Leszczynski --- tools/libxc/Makefile | 1 + tools/libxc/include/xenctrl.h | 39 ++++++++++++++ tools/libxc/xc_vmtrace.c | 97 +++++++++++++++++++++++++++++++++++ 3 files changed, 137 insertions(+) create mode 100644 tools/libxc/xc_vmtrace.c diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile index fae5969a73..605e44501d 100644 --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -27,6 +27,7 @@ CTRL_SRCS-y += xc_csched2.c CTRL_SRCS-y += xc_arinc653.c CTRL_SRCS-y += xc_rt.c CTRL_SRCS-y += xc_tbuf.c +CTRL_SRCS-y += xc_vmtrace.c CTRL_SRCS-y += xc_pm.c CTRL_SRCS-y += xc_cpu_hotplug.c CTRL_SRCS-y += xc_resume.c diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 113ddd935d..101cc9b712 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -1585,6 +1585,45 @@ int xc_tbuf_set_cpu_mask(xc_interface *xch, xc_cpumap_t mask); int xc_tbuf_set_evt_mask(xc_interface *xch, uint32_t mask); +/** + * Enable Intel Processor Trace for given vCPU in given DomU. + * Allocate the trace ringbuffer with given size. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @return 0 on success, -1 on failure + */ +int xc_vmtrace_ipt_enable(xc_interface *xch, uint32_t domid, + uint32_t vcpu); + +/** + * Disable Intel Processor Trace for given vCPU in given DomU. + * Deallocate the trace ringbuffer. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @return 0 on success, -1 on failure + */ +int xc_vmtrace_ipt_disable(xc_interface *xch, uint32_t domid, + uint32_t vcpu); + +/** + * Get current offset inside the trace ringbuffer. + * This allows to determine how much data was written into the buffer. + * Once buffer overflows, the offset will reset to 0 and the previous + * data will be overriden. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @parm offset current offset inside trace buffer will be written there + * @return 0 on success, -1 on failure + */ +int xc_vmtrace_ipt_get_offset(xc_interface *xch, uint32_t domid, + uint32_t vcpu, uint64_t *offset); + int xc_domctl(xc_interface *xch, struct xen_domctl *domctl); int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl); diff --git a/tools/libxc/xc_vmtrace.c b/tools/libxc/xc_vmtrace.c new file mode 100644 index 0000000000..5f0551ad71 --- /dev/null +++ b/tools/libxc/xc_vmtrace.c @@ -0,0 +1,97 @@ +/****************************************************************************** + * xc_vmtrace.c + * + * API for manipulating hardware tracing features + * + * Copyright (c) 2020, Michal Leszczynski + * + * Copyright 2020 CERT Polska. All rights reserved. + * Use is subject to license terms. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; + * version 2.1 of the License. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; If not, see . + */ + +#include "xc_private.h" +#include + +int xc_vmtrace_ipt_enable( + xc_interface *xch, uint32_t domid, uint32_t vcpu) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->version = HVMOP_VMTRACE_INTERFACE_VERSION; + arg->cmd = HVMOP_vmtrace_ipt_enable; + arg->domain = domid; + arg->vcpu = vcpu; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + +int xc_vmtrace_ipt_get_offset( + xc_interface *xch, uint32_t domid, uint32_t vcpu, uint64_t *offset) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->version = HVMOP_VMTRACE_INTERFACE_VERSION; + arg->cmd = HVMOP_vmtrace_ipt_get_offset; + arg->domain = domid; + arg->vcpu = vcpu; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + if ( rc == 0 ) + { + *offset = arg->offset; + } + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + +int xc_vmtrace_ipt_disable(xc_interface *xch, uint32_t domid, uint32_t vcpu) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->version = HVMOP_VMTRACE_INTERFACE_VERSION; + arg->cmd = HVMOP_vmtrace_ipt_disable; + arg->domain = domid; + arg->vcpu = vcpu; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:42:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:42:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4BE-0001hV-QG; Thu, 18 Jun 2020 23:42:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4BD-0001gW-In for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:42:47 +0000 X-Inumbo-ID: 694a04f6-b1bd-11ea-bb0d-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 694a04f6-b1bd-11ea-bb0d-12813bfff9fa; Thu, 18 Jun 2020 23:42:46 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id D43ECA30D9; Fri, 19 Jun 2020 01:42:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id D166CA30C7; Fri, 19 Jun 2020 01:42:44 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xNpoFLq-6dLZ; Fri, 19 Jun 2020 01:42:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 5D0B3A30D9; Fri, 19 Jun 2020 01:42:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J3KGtSk5WrGH; Fri, 19 Jun 2020 01:42:44 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 346BAA30C7; Fri, 19 Jun 2020 01:42:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 2A1182059A; Fri, 19 Jun 2020 01:42:14 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id FFFWMQ1p63gx; Fri, 19 Jun 2020 01:42:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 8A390215FA; Fri, 19 Jun 2020 01:42:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1NMEayWZazcC; Fri, 19 Jun 2020 01:42:08 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 6C8F72059A; Fri, 19 Jun 2020 01:42:08 +0200 (CEST) Date: Fri, 19 Jun 2020 01:42:08 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <2064075230.9820955.1592523728387.JavaMail.zimbra@cert.pl> In-Reply-To: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> Subject: [PATCH v2 6/7] tools/libxl: add vmtrace_pt_size parameter MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: tools/libxl: add vmtrace_pt_size parameter Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyI5Kl+C5 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Kang, Luwei" , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , Anthony PERARD Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Allow to specify the size of per-vCPU trace buffer upon domain creation. This is zero by default (meaning: not enabled). Signed-off-by: Michal Leszczynski --- tools/golang/xenlight/helpers.gen.go | 2 ++ tools/golang/xenlight/types.gen.go | 1 + tools/libxl/libxl_types.idl | 2 ++ tools/libxl/libxl_x86.c | 5 +++++ tools/xl/xl_parse.c | 4 ++++ 5 files changed, 14 insertions(+) diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index 935d3bc50a..986ebbd681 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -1117,6 +1117,7 @@ return fmt.Errorf("invalid union key '%v'", x.Type)} x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version) x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart) x.Altp2M = Altp2MMode(xc.altp2m) +x.VmtracePtSize = int(xc.vmtrace_pt_size) return nil} @@ -1592,6 +1593,7 @@ return fmt.Errorf("invalid union key '%v'", x.Type)} xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion) xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart) xc.altp2m = C.libxl_altp2m_mode(x.Altp2M) +xc.vmtrace_pt_size = C.int(x.VmtracePtSize) return nil } diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go index 663c1e86b4..41ec7cdd32 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -516,6 +516,7 @@ GicVersion GicVersion Vuart VuartType } Altp2M Altp2MMode +VmtracePtSize int } type domainBuildInfoTypeUnion interface { diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 9d3f05f399..04c1704b72 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -645,6 +645,8 @@ libxl_domain_build_info = Struct("domain_build_info",[ # supported by x86 HVM and ARM support is planned. ("altp2m", libxl_altp2m_mode), + ("vmtrace_pt_size", integer), + ], dir=DIR_IN, copy_deprecated_fn="libxl__domain_build_info_copy_deprecated", ) diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c index e57f63282e..14be2b395a 100644 --- a/tools/libxl/libxl_x86.c +++ b/tools/libxl/libxl_x86.c @@ -404,6 +404,11 @@ static int hvm_set_conf_params(libxl__gc *gc, uint32_t domid, libxl_defbool_val(info->u.hvm.altp2m)) altp2m = libxl_defbool_val(info->u.hvm.altp2m); + if (xc_hvm_param_set(xch, domid, HVM_PARAM_VMTRACE_PT_SIZE, + info->vmtrace_pt_size)) { + LOG(ERROR, "Couldn't set HVM_PARAM_VMTRACE_PT_SIZE"); + goto out; + } if (xc_hvm_param_set(xch, domid, HVM_PARAM_HPET_ENABLED, libxl_defbool_val(info->u.hvm.hpet))) { LOG(ERROR, "Couldn't set HVM_PARAM_HPET_ENABLED"); diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 61b4ef7b7e..6ab98dda55 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1861,6 +1861,10 @@ void parse_config_data(const char *config_source, } } + if (!xlu_cfg_get_long(config, "vmtrace_pt_size", &l, 1)) { + b_info->vmtrace_pt_size = l; + } + if (!xlu_cfg_get_list(config, "ioports", &ioports, &num_ioports, 0)) { b_info->num_ioports = num_ioports; b_info->ioports = calloc(num_ioports, sizeof(*b_info->ioports)); -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:43:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:43:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4Bw-0001p4-3X; Thu, 18 Jun 2020 23:43:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4Bu-0001or-SJ for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:43:30 +0000 X-Inumbo-ID: 825e0c30-b1bd-11ea-bb8b-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 825e0c30-b1bd-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 23:43:28 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id EE237A30D9; Fri, 19 Jun 2020 01:43:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id EBA38A30C7; Fri, 19 Jun 2020 01:43:26 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 13xRvDoEv8el; Fri, 19 Jun 2020 01:43:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2B90EA30D9; Fri, 19 Jun 2020 01:43:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qqymjspFdV0h; Fri, 19 Jun 2020 01:43:25 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 07EBEA30C7; Fri, 19 Jun 2020 01:43:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id EF0092059A; Fri, 19 Jun 2020 01:42:54 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xKySNHyeD6dB; Fri, 19 Jun 2020 01:42:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 47AD4215FA; Fri, 19 Jun 2020 01:42:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YloaxQWlVfCJ; Fri, 19 Jun 2020 01:42:48 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 1BB6E2059A; Fri, 19 Jun 2020 01:42:48 +0200 (CEST) Date: Fri, 19 Jun 2020 01:42:48 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <1496868180.9820956.1592523768036.JavaMail.zimbra@cert.pl> In-Reply-To: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> Subject: [PATCH v2 7/7] tools/proctrace: add proctrace tool MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: tools/proctrace: add proctrace tool Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyNFk8ea8 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Ian Jackson , "Kang, Luwei" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add an demonstration tool that uses xc_vmtrace_* calls in order to manage external IPT monitoring for DomU. Signed-off-by: Michal Leszczynski --- tools/proctrace/COPYING | 339 ++++++++++++++++++++++++++++++++++++ tools/proctrace/Makefile | 50 ++++++ tools/proctrace/proctrace.c | 153 ++++++++++++++++ 3 files changed, 542 insertions(+) create mode 100644 tools/proctrace/COPYING create mode 100644 tools/proctrace/Makefile create mode 100644 tools/proctrace/proctrace.c diff --git a/tools/proctrace/COPYING b/tools/proctrace/COPYING new file mode 100644 index 0000000000..c0a841112c --- /dev/null +++ b/tools/proctrace/COPYING @@ -0,0 +1,339 @@ +=09=09 GNU GENERAL PUBLIC LICENSE +=09=09 Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +=09=09=09 Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + +=09=09 GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; o= r, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Softwa= re +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + +=09=09=09 NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITIN= G +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISIN= G +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + +=09=09 END OF TERMS AND CONDITIONS + +=09 How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms= . + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; If not, see . + + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show = w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriat= e +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + , 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program int= o +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with th= e +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. diff --git a/tools/proctrace/Makefile b/tools/proctrace/Makefile new file mode 100644 index 0000000000..76d7387a64 --- /dev/null +++ b/tools/proctrace/Makefile @@ -0,0 +1,50 @@ +# Copyright (C) CERT Polska - NASK PIB +# Author: Micha=C4=B9=E2=80=9A Leszczy=C4=B9=E2=80=9Eski +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; under version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +XEN_ROOT=3D$(CURDIR)/../.. +include $(XEN_ROOT)/tools/Rules.mk + +CFLAGS +=3D -Werror +CFLAGS +=3D $(CFLAGS_libxenevtchn) +CFLAGS +=3D $(CFLAGS_libxenctrl) +LDLIBS +=3D $(LDLIBS_libxenctrl) +LDLIBS +=3D $(LDLIBS_libxenevtchn) +LDLIBS +=3D $(LDLIBS_libxenforeignmemory) + +# SCRIPTS =3D xenmon.py + +.PHONY: all +all: build + +.PHONY: build +build: proctrace + +.PHONY: install +install: build +=09$(INSTALL_DIR) $(DESTDIR)$(sbindir) +=09$(INSTALL_PROG) proctrace $(DESTDIR)$(sbindir)/proctrace + +.PHONY: uninstall +uninstall: +=09rm -f $(DESTDIR)$(sbindir)/proctrace + +.PHONY: clean +clean: +=09$(RM) -f $(DEPS_RM) + +.PHONY: distclean +distclean: clean + +iptlive: iptlive.o Makefile +=09$(CC) $(LDFLAGS) $< -o $@ $(LDLIBS) $(APPEND_LDFLAGS) + +-include $(DEPS_INCLUDE) diff --git a/tools/proctrace/proctrace.c b/tools/proctrace/proctrace.c new file mode 100644 index 0000000000..b2c3da49f1 --- /dev/null +++ b/tools/proctrace/proctrace.c @@ -0,0 +1,153 @@ +/*************************************************************************= ***** + * tools/proctrace.c + * + * Demonstrative tool for collecting Intel Processor Trace data from Xen. + * Could be used to externally monitor a given vCPU in given DomU. + * + * Copyright (C) 2020 by CERT Polska - NASK PIB + * + * Authors: Micha=C4=B9=E2=80=9A Leszczy=C4=B9=E2=80=9Eski, michal.leszczy= nski@cert.pl + * Date: June, 2020 + *=20 + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; under version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; If not, see . + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#define XC_WANT_COMPAT_MAP_FOREIGN_API +#include +#include + +#define BUF_SIZE 16384 * 4096 + +volatile int interrupted =3D 0; + +void term_handler(int signum) { + interrupted =3D 1; +} + +int main(int argc, char* argv[]) { + xc_interface *xc; + uint32_t domid; + uint32_t vcpu_id; + + int rc =3D -1; + uint8_t *buf; + uint64_t last_offset =3D 0; + + xenforeignmemory_handle* fmem; + xenforeignmemory_resource_handle *fres; + + signal(SIGINT, term_handler); + + if (argc !=3D 3) { + fprintf(stderr, "Usage: %s \n", argv[0]); + fprintf(stderr, "It's recommended to redirect this" + "program's output to file\n"); + fprintf(stderr, "or to pipe it's output to xxd or other program.\n= "); + return 1; + } + + domid =3D atoi(argv[1]); + vcpu_id =3D atoi(argv[2]); + + xc =3D xc_interface_open(0, 0, 0); + + fmem =3D xenforeignmemory_open(0, 0); + + if (!xc) { + fprintf(stderr, "Failed to open xc interface\n"); + return 1; + } + + rc =3D xc_vmtrace_ipt_enable(xc, domid, vcpu_id); + + if (rc) { + fprintf(stderr, "Failed to call xc_vmtrace_ipt_enable\n"); + return 1; + } + + fres =3D xenforeignmemory_map_resource( + fmem, domid, XENMEM_resource_vmtrace_buf, + /* vcpu: */ vcpu_id, + /* frame: */ 0, + /* num_frames: */ BUF_SIZE >> XC_PAGE_SHIFT, + (void **)&buf, + PROT_READ, 0); + + while (!interrupted) { + uint64_t offset; + rc =3D xc_vmtrace_ipt_get_offset(xc, domid, vcpu_id, &offset); + + if (rc) { + fprintf(stderr, "Failed to call xc_vmtrace_ipt_get_offset\n"); + return 1; + } + + if (offset > last_offset) + { + fwrite(buf + last_offset, offset - last_offset, 1, stdout); + } + else if (offset < last_offset) + { + // buffer wrapped + fwrite(buf + last_offset, BUF_SIZE - last_offset, 1, stdout); + fwrite(buf, offset, 1, stdout); + } + + last_offset =3D offset; + usleep(1000 * 100); + } + + rc =3D xenforeignmemory_unmap_resource(fmem, fres); + + if (rc) { + fprintf(stderr, "Failed to unmap resource\n"); + return 1; + } + + rc =3D xc_vmtrace_ipt_disable(xc, domid, vcpu_id); + + if (rc) { + fprintf(stderr, "Failed to call xc_vmtrace_ipt_disable\n"); + return 1; + } + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ --=20 2.20.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:44:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:44:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4CU-0001vQ-J8; Thu, 18 Jun 2020 23:44:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4CT-0001uX-MN for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:44:05 +0000 X-Inumbo-ID: 94ae3310-b1bd-11ea-bb8b-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 94ae3310-b1bd-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 23:43:59 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: uFy2yF6A3Sz1dmKVsQj8ZhJG1SABuqaEaoPwHhB8Y6/iNzyUA/U/xV0ZpN9d06cQS2bdfVIWUl bJauUP46LSy9HaJd9th/lLF/rusg4AEYsYC3H3U3qZSnhLmyUsXEBzhX60YNVoA7JT9g+2tbAY aXLXo3bBlfCVkM2VNolaXd54+MZl/cAY7DOx+9NcGqeV/paOHuf3GYs+ehwff2bdptf4xVmY3U Ni3Mx7ShySsIofO22N9sHbMdVgGtEUW1RpTfVDBJf0ZkQW48nJALoxJRXZFaqQFu/5mc+nlXXH geE= X-SBRS: 2.7 X-MesageID: 20650521 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,253,1589256000"; d="scan'208";a="20650521" Subject: Re: Event delivery and "domain blocking" on PVHv2 To: Martin Lucina , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , , References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> From: Andrew Cooper Message-ID: <2f5c8fbc-0153-17b7-4a44-8f8ba0e3179f@citrix.com> Date: Fri, 19 Jun 2020 00:43:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200618101330.GB10330@nodbug.lucina.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18/06/2020 11:13, Martin Lucina wrote: > On Monday, 15.06.2020 at 17:58, Andrew Cooper wrote: >> On 15/06/2020 15:25, Martin Lucina wrote: >>> Hi, >>> >>> puzzle time: In my continuing explorations of the PVHv2 ABIs for the >>> new MirageOS Xen stack, I've run into some issues with what looks like >>> missed deliveries of events on event channels. >>> >>> While a simple unikernel that only uses the Xen console and >>> effectively does for (1..5) { printf("foo"); sleep(1); } works fine, >>> once I plug in the existing OCaml Xenstore and Netfront code, the >>> behaviour I see is that the unikernel hangs in random places, blocking >>> as if an event that should have been delivered has been missed. >> You can see what is going on, event channel wise, with the 'e' >> debug-key.  This will highlight cases such as the event channel being >> masked and pending, which is a common guest bug ending up in this state. > Ok, based on your and Roger's suggestions I've made some changes: > > 1. I've dropped all the legacy PIC initialisation code from the Solo5 > parts, written some basic APIC initialisation code and switched to using > HVMOP_set_evtchn_upcall_vector for upcall registration, along with setting > HVM_PARAM_CALLBACK_IRQ to 1 as suggested by Roger and done by Xen when > running as a guest. Commit at [1], nothing controversial there. Well...     uint64_t apic_base = rdmsrq(MSR_IA32_APIC_BASE);     wrmsrq(MSR_IA32_APIC_BASE,             apic_base | (APIC_BASE << 4) | MSR_IA32_APIC_BASE_ENABLE);     apic_base = rdmsrq(MSR_IA32_APIC_BASE);     if (!(apic_base & MSR_IA32_APIC_BASE_ENABLE)) {         log(ERROR, "Solo5: Could not enable APIC or not present\n");         assert(false);     } The only reason Xen doesn't crash your guest on that WRMSR is because 0xfee00080ull | (0xfee00000u << 4) == 0xfee00080ull, due to truncation and 0xfe | 0xee == 0xfe. Either way, the logic isn't correct. Xen doesn't support moving the APIC MMIO window (and almost certainly never will, because the only thing which changes it is malware).  You can rely on the default state being correct, because it is architecturally specified. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 18 23:52:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 18 Jun 2020 23:52:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4Ka-0002sA-EN; Thu, 18 Jun 2020 23:52:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm4KZ-0002s5-Gv for xen-devel@lists.xenproject.org; Thu, 18 Jun 2020 23:52:27 +0000 X-Inumbo-ID: c2c31594-b1be-11ea-bb8b-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c2c31594-b1be-11ea-bb8b-bc764e2007e4; Thu, 18 Jun 2020 23:52:26 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 47E1AA3131; Fri, 19 Jun 2020 01:52:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2EE21A312D; Fri, 19 Jun 2020 01:52:24 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id DR3LhTfkcpdE; Fri, 19 Jun 2020 01:52:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id B18F2A3131; Fri, 19 Jun 2020 01:52:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TCKmSYjHPzGH; Fri, 19 Jun 2020 01:52:22 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 8D449A312D; Fri, 19 Jun 2020 01:52:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 7A01D2059A; Fri, 19 Jun 2020 01:51:52 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id dUW_3J0fmgSG; Fri, 19 Jun 2020 01:51:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D49EF215FA; Fri, 19 Jun 2020 01:51:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iiAAqbqYF5FN; Fri, 19 Jun 2020 01:51:46 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id A22402059A; Fri, 19 Jun 2020 01:51:46 +0200 (CEST) Date: Fri, 19 Jun 2020 01:51:46 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <782191628.9821033.1592524306516.JavaMail.zimbra@cert.pl> In-Reply-To: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> Subject: Re: [PATCH v2 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyINWwTy9 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jun Nakajima , Tamas K Lengyel , Anthony PERARD , "Kang, Luwei" , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 1:34, Micha=C5=82 Leszczy=C5=84ski michal.leszczynski@c= ert.pl napisa=C5=82(a): > Intel Processor Trace is an architectural extension available in modern I= ntel > family CPUs. It allows recording the detailed trace of activity while the > processor executes the code. One might use the recorded trace to reconstr= uct > the code flow. It means, to find out the executed code paths, determine > branches taken, and so forth. >=20 > The abovementioned feature is described in Intel(R) 64 and IA-32 Architec= tures > Software Developer's Manual Volume 3C: System Programming Guide, Part 3, > Chapter 36: "Intel Processor Trace." >=20 > This patch series implements an interface that Dom0 could use in order to > enable IPT for particular vCPUs in DomU, allowing for external monitoring= . Such > a feature has numerous applications like malware monitoring, fuzzing, or > performance testing. >=20 > Also thanks to Tamas K Lengyel for a few preliminary hints before > first version of this patch was submitted to xen-devel. >=20 > Changed since v1: > * MSR_RTIT_CTL is managed using MSR load lists > * other PT-related MSRs are modified only when vCPU goes out of context > * trace buffer is now acquired as a resource > * added vmtrace_pt_size parameter in xl.cfg, the size of trace buffer > must be specified in the moment of domain creation > * trace buffers are allocated on domain creation, destructed on > domain destruction > * HVMOP_vmtrace_ipt_enable/disable is limited to enabling/disabling PT > these calls don't manage buffer memory anymore > * lifted 32 MFN/GFN array limit when acquiring resources > * minor code style changes according to review >=20 > Michal Leszczynski (7): > xen/mm: lift 32 item limit from mfn/gfn arrays > x86/vmx: add Intel PT MSR definitions > x86/vmx: add IPT cpu feature > x86/vmx: add do_vmtrace_op > tools/libxc: add xc_vmtrace_* functions > tools/libxl: add vmtrace_pt_size parameter > tools/proctrace: add proctrace tool >=20 > tools/golang/xenlight/helpers.gen.go | 2 + > tools/golang/xenlight/types.gen.go | 1 + > tools/libxc/Makefile | 1 + > tools/libxc/include/xenctrl.h | 39 +++ > tools/libxc/xc_vmtrace.c | 97 ++++++ > tools/libxl/libxl_types.idl | 2 + > tools/libxl/libxl_x86.c | 5 + > tools/proctrace/COPYING | 339 ++++++++++++++++++++ > tools/proctrace/Makefile | 50 +++ > tools/proctrace/proctrace.c | 153 +++++++++ > tools/xl/xl_parse.c | 4 + > xen/arch/x86/hvm/hvm.c | 167 ++++++++++ > xen/arch/x86/hvm/vmx/vmcs.c | 4 + > xen/arch/x86/hvm/vmx/vmx.c | 24 ++ > xen/arch/x86/mm.c | 37 +++ > xen/common/domain.c | 1 + > xen/common/memory.c | 39 +-- > xen/include/asm-x86/cpufeature.h | 1 + > xen/include/asm-x86/hvm/hvm.h | 9 + > xen/include/asm-x86/hvm/vmx/vmcs.h | 17 + > xen/include/asm-x86/msr-index.h | 37 +++ > xen/include/public/arch-x86/cpufeatureset.h | 1 + > xen/include/public/hvm/hvm_op.h | 23 ++ > xen/include/public/hvm/params.h | 5 +- > xen/include/public/memory.h | 1 + > xen/include/xen/sched.h | 3 + > 26 files changed, 1039 insertions(+), 23 deletions(-) > create mode 100644 tools/libxc/xc_vmtrace.c > create mode 100644 tools/proctrace/COPYING > create mode 100644 tools/proctrace/Makefile > create mode 100644 tools/proctrace/proctrace.c >=20 > -- > 2.20.1 Thanks for all comments related to v1. I did my best to address all of them= and thus almost all code was altered. Due to that, I've decided to post the nex= t version at this stage. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 00:47:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 00:47:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm5BU-0007Y4-1e; Fri, 19 Jun 2020 00:47:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm5BS-0007Xz-NM for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 00:47:06 +0000 X-Inumbo-ID: 6535c072-b1c6-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6535c072-b1c6-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 00:47:05 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 192CFA317E; Fri, 19 Jun 2020 02:47:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 0213FA3013; Fri, 19 Jun 2020 02:47:03 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id WUzRUmcp1MrN; Fri, 19 Jun 2020 02:47:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7A087A317E; Fri, 19 Jun 2020 02:47:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XPbQq1Wdyg6o; Fri, 19 Jun 2020 02:47:02 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 42CCEA3013; Fri, 19 Jun 2020 02:47:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 2967021000; Fri, 19 Jun 2020 02:46:32 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0UrZxVoLe2hT; Fri, 19 Jun 2020 02:46:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id B317921128; Fri, 19 Jun 2020 02:46:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rUoXKgizFVyL; Fri, 19 Jun 2020 02:46:26 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 90B3E21000; Fri, 19 Jun 2020 02:46:26 +0200 (CEST) Date: Fri, 19 Jun 2020 02:46:26 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <1171450280.9822275.1592527586479.JavaMail.zimbra@cert.pl> In-Reply-To: <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyEuhVFaU7P5v8mM= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jun Nakajima , Tamas K Lengyel , "Kang, Luwei" , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 1:41, Micha=C5=82 Leszczy=C5=84ski michal.leszczynski@c= ert.pl napisa=C5=82(a): > Provide an interface for privileged domains to manage > external IPT monitoring. Guest IPT state will be preserved > across vmentry/vmexit using ipt_state structure. >=20 > Signed-off-by: Michal Leszczynski > --- ... > +struct xen_hvm_vmtrace_op { > + /* IN variable */ > + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ > + uint32_t cmd; > +/* Enable/disable external vmtrace for given domain */ > +#define HVMOP_vmtrace_ipt_enable 1 > +#define HVMOP_vmtrace_ipt_disable 2 > +#define HVMOP_vmtrace_ipt_get_offset 3 > + domid_t domain; > + uint32_t vcpu; > + uint64_t size; > + > + /* OUT variable */ > + uint64_t offset; > +}; > +typedef struct xen_hvm_vmtrace_op xen_hvm_vmtrace_op_t; > +DEFINE_XEN_GUEST_HANDLE(xen_hvm_vmtrace_op_t); > + I've forgotten about the padding thing here. This will be fixed in the next= patch version, sorry. ml From xen-devel-bounces@lists.xenproject.org Fri Jun 19 01:15:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 01:15:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm5cz-0002dm-8y; Fri, 19 Jun 2020 01:15:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm5cx-0002dh-Us for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 01:15:32 +0000 X-Inumbo-ID: 5df1528c-b1ca-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5df1528c-b1ca-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 01:15:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=taKxPN8BmGHwiBWhvp+bQCiaNAbvgr/FmHtq6p1t48c=; b=WFRN159mNuzZ37Em8qw1peZ17 zsvHMcj1osuQqMibElft0BCtTRnzMhM+EiPwgEyqKUPN9mT1Chyk59kzpDQXafEuVWLZCG9qjxOr4 2Yft2Hl1xsHtWj9785kOpwqhe14mWnHae2HAEnmw+cj8kyTu7n1RuqilSfJIVB3llOa34=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm5cw-0000h8-9U; Fri, 19 Jun 2020 01:15:30 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jm5cw-00047d-24; Fri, 19 Jun 2020 01:15:30 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jm5cw-0001Rt-16; Fri, 19 Jun 2020 01:15:30 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151197: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=6f28865223292a816f1bfde589901a00156cf8a1 X-Osstest-Versions-That: libvirt=1eabe312ea4fa80922443ad73a950857c1f87786 From: osstest service owner Date: Fri, 19 Jun 2020 01:15:30 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151197 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151197/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151165 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151165 test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 6f28865223292a816f1bfde589901a00156cf8a1 baseline version: libvirt 1eabe312ea4fa80922443ad73a950857c1f87786 Last test of basis 151165 2020-06-16 04:18:45 Z 2 days Testing same since 151197 2020-06-17 14:34:03 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Boris Fiuczynski Daniel Henrique Barboza Erik Skultety Fedora Weblate Translation Jiri Denemark John Ferlan Michal Privoznik Paulo de Rezende Pinatti Peter Krempa Viktor Mihajlovski Weblate Yuri Chornoivan jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 1eabe312ea..6f28865223 6f28865223292a816f1bfde589901a00156cf8a1 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Fri Jun 19 01:27:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 01:27:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm5oF-0003XO-CR; Fri, 19 Jun 2020 01:27:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm5oE-0003XJ-Ib for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 01:27:10 +0000 X-Inumbo-ID: fd7639e8-b1cb-11ea-bb1b-12813bfff9fa Received: from mga04.intel.com (unknown [192.55.52.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fd7639e8-b1cb-11ea-bb1b-12813bfff9fa; Fri, 19 Jun 2020 01:27:08 +0000 (UTC) IronPort-SDR: OZ62ioNrKfck6emZnBlQf+qYdCiA933GPsgQjmN4Wk+XCZn0rUdcN4xuUZMb03IFuc3x/QuINr zWZbg6KGv8Ng== X-IronPort-AV: E=McAfee;i="6000,8403,9656"; a="140329186" X-IronPort-AV: E=Sophos;i="5.75,253,1589266800"; d="scan'208";a="140329186" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2020 18:27:07 -0700 IronPort-SDR: UxsThT7uRVvLTBfdffEPEWM16aZCaMp5VIYe5D0d0zW0t5t/lS5bn0dJYRPhYIue4uw6kQRc4T u7UyIfxsq3oQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,253,1589266800"; d="scan'208";a="352584598" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by orsmga001.jf.intel.com with ESMTP; 18 Jun 2020 18:27:07 -0700 Received: from ORSEDG002.ED.cps.intel.com (10.7.248.5) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 18 Jun 2020 18:27:06 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.102) by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 18 Jun 2020 18:27:06 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BQT9ML8TWEJxKs96urnUIkr/Vv1860WAhNOeAOmaY1lgCUANwWUvqeB/Dotw1R3IF7wLA5PECQ2KVDCLDF6XgpY5FTD6nHx0WGE/WwX/YWnmUlbMdbSpZqQyEsYehWjfTQR0UoozxWs0ZR8fqAADhHteNO0rjToXSkm7q3AwbM18Z9S6r8j4bk1N9BXAzFkYj41B61v36NxAgfNMujovrCkXKTHezO4ONAZQ3OY0p/5ueOTb9rADLAO3aoJj73t6IaPFPxlMGPwoYBhQI6sbC4g+x461mA/0RWxUPKmYHazMSmhipz9oz81sgt1XfYj6Ne4p22pFjKIqRSJQCwRO6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tQkI0yamfSNutIMYlfjEegApKS7mS2dEbOKvygxGeok=; b=K6Rxo/h4uBquS2zf9gcEqrCaULzVb6wriviFEkuQ50+bWY31SVugGuolG9HECFtmi7yvctuG47MMA+GRpWvMTQV+hnrRof5+TRa1co5yMEtj0QelNdzsAeMOwhMiKdRAbQm4EYD6Wh/08E3U9NMXgyTbN5DBBWRhAzeJdPAwgkOWyYfCy7dqrVXatSrD+Uj/dcPkhogrkxOso4P9lpvUMfatQ3EauyyMzYotKe6JbMEMsmBwaB1T/zEM/OgZ+rYnIy+yPNZ8EdL4ynFuWet58CpMGrICtE2L3nkwhD6w432CsNG7DBWeqWDfoJM8rSqOECDQzmZxkY8rNWozcK+xSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tQkI0yamfSNutIMYlfjEegApKS7mS2dEbOKvygxGeok=; b=zCr/iMULXKBDm6VUMQ9aOFDrn8rY/4eRGfB2UTLGqQiDmyQX9j4ky7pxbN3A2SpEjpDSGLW8E0xP9dG9cByaP3ZxFTrKDumnicpyVYwtzIP2utf5aaINlrBPYbs47JCF6FO/Pf7evqHXDCPyyyxXENiCziOkcTViEEZfpeEZh44= Received: from MWHPR11MB1645.namprd11.prod.outlook.com (2603:10b6:301:b::12) by MWHPR11MB1391.namprd11.prod.outlook.com (2603:10b6:300:23::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Fri, 19 Jun 2020 01:27:05 +0000 Received: from MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb]) by MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb%5]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 01:27:05 +0000 From: "Tian, Kevin" To: Jan Beulich , "xen-devel@lists.xenproject.org" Subject: RE: [PATCH] VT-x: simplify/clarify vmx_load_pdptrs() Thread-Topic: [PATCH] VT-x: simplify/clarify vmx_load_pdptrs() Thread-Index: AQHWRTsZ99HPJcDaf0KsaKSIfuDNiajfJt7Q Date: Fri, 19 Jun 2020 01:27:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.202] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1adbc222-4249-4656-d623-08d813efe052 x-ms-traffictypediagnostic: MWHPR11MB1391: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dlVqeHZ9XoOz+brk7Kufp+J1aXvSvA1YZc1/iFq4rq4P0tAcICJKK4ixaFiWAQTxQhVBO2llevdiJt6sHG1or3gHs5dTpkTE/4mnuB1F4KuyuTHZ/8ubXO6Y4k3c0nCgoZj2osia3tjfSglOAjexALj4X9zCjl0ZAMNqTSS7y7D4eAzs7KQ8d/uhbF1QaBVJzJeCYIZTp1mbTFGOAoNWVlr2v8ik46NZ7PcqqGpEbHX04qAuKZnjzCGic3ZxSEkyPvig6A0iHCpjQK3jcnoPqFpLClz7IJ7xHCuAj+O2OZ1mIj5wVO6ViqmC9FebwuoVXG14B/CoWCA9Xqvapipc/NU4bo1FmHzQMBABAVVAdcCLIYQ7uA2eEbZjABFjb/J1Vog7rVN/ToseGWzg4XZ7zA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1645.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(39860400002)(346002)(396003)(136003)(26005)(52536014)(66946007)(71200400001)(64756008)(66556008)(76116006)(66476007)(66446008)(5660300002)(55016002)(9686003)(186003)(4326008)(86362001)(316002)(966005)(8676002)(83380400001)(2906002)(33656002)(110136005)(8936002)(478600001)(54906003)(6506007)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: bsCh0OPydHwGEi0FnST3R0qi/vDLo4h+hkz82FA3IQvl+MepHoH+HevqbWOCsZ7s4L8DKdAXE1tEaRbH3K3n5nOqyErDIOeEGIZqG6qQvKAODbrHPBLJy2rVf/1DTjF3+nriwBTM6DrxA39jm3XLRjJYNaA/q6mo5aGumZfTzE6d3ICYHk+zxcmRCTmf2TGClghErbkxgrUqN6d5P1SmqsC31neBT0T+ZmWnsw9Y3RxNc8RIjWoS7ktBqY/LKX1iyZ7orUHSqInJ7GtcptGMShGTlr/moQnDKqQV8sxLtdg5v0WoxQTbe8ITSoewmB414ICv2d6A+HtoBimAUQiiZB+rU9ZGTXtEBryrLwMV5BpJse/pTXcrbUPcriH8ewmhEaCJe4ZMeZKmwPKfAMNoFGi2v5PP70iiOdHqusc89USvZjEjXIyFvAygKZ42+hcrJJoPvQF57GxC34HSzwXbpY8be4bGHrof7pYtFP6HV5rYpuoNlaVcXug8iZh49nqP Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1adbc222-4249-4656-d623-08d813efe052 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 01:27:05.3462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZRfzIMin9XHSXD7P4mx7E4s8pd060nARDakS6uck2bVtFzReo50Wq4i0oIWIju6EToZ2DmMaGUg7DL6pGGMjfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1391 X-OriginatorOrg: intel.com X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Wei Liu , "Nakajima, Jun" , =?utf-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiBGcm9tOiBKYW4gQmV1bGljaCA8amJldWxpY2hAc3VzZS5jb20+DQo+IFNlbnQ6IFRodXJzZGF5 LCBKdW5lIDE4LCAyMDIwIDI6MzggUE0NCj4gDQo+ICogR3Vlc3RzIG91dHNpZGUgb2YgbG9uZyBt b2RlIGNhbid0IGhhdmUgUENJRCBlbmFibGVkLiBEcm9wIHRoZQ0KPiAgIHJlc3BlY3RpdmUgY2hl Y2sgdG8gbWFrZSBtb3JlIG9idmlvdXMgdGhhdCB0aGVyZSdzIG5vIHNlY3VyaXR5IGlzc3VlDQo+ ICAgKGZyb20gcG90ZW50aWFsbHkgYWNjZXNzaW5nIHBhc3QgdGhlIG1hcHBlZCBwYWdlJ3MgYm91 bmRhcnkpLg0KPiANCj4gKiBPbmx5IHRoZSBsb3cgMzIgYml0cyBvZiBDUjMgYXJlIHJlbGV2YW50 IG91dHNpZGUgb2YgbG9uZyBtb2RlLCBldmVuDQo+ICAgaWYgdGhleSByZW1haW5lZCB1bmNoYW5n ZWQgYWZ0ZXIgbGVhdmluZyB0aGF0IG1vZGUuDQo+IA0KPiAqIERyb3AgdGhlIHVubmVjZXNzYXJ5 IGFuZCBiYWRseSB0eXBlZCBsb2NhbCB2YXJpYWJsZSBwLg0KPiANCj4gKiBEb24ndCBvcGVuLWNv ZGUgaHZtX2xvbmdfbW9kZV9hY3RpdmUoKSAoYW5kIGV4dGVuZCB0aGlzIHRvIHRoZSByZWxhdGVk DQo+ICAgbmVzdGVkIFZULXggY29kZSkuDQo+IA0KPiAqIENvbnN0aWZ5IGd1ZXN0X3BkcHRlcyB0 byBjbGFyaWZ5IHRoYXQgd2UncmUgb25seSByZWFkaW5nIGZyb20gdGhlDQo+ICAgcGFnZS4NCj4g DQo+IFNpZ25lZC1vZmYtYnk6IEphbiBCZXVsaWNoIDxqYmV1bGljaEBzdXNlLmNvbT4NCg0KUmV2 aWV3ZWQtYnk6IEtldmluIFRpYW4gPGtldmluLnRpYW5AaW50ZWwuY29tPg0KDQo+IC0tLQ0KPiBU aGlzIGlzIGludGVudGlvbmFsbHkgbm90IGFkZHJlc3NpbmcgYW55IG9mIHRoZSBvdGhlciBzaG9y dGNvbWluZ3Mgb2YNCj4gdGhlIGZ1bmN0aW9uLCBhcyB3YXMgZG9uZSBieSB0aGUgcHJldmlvdXNs eSBwb3N0ZWQNCj4gaHR0cHM6Ly9saXN0cy54ZW5wcm9qZWN0Lm9yZy9hcmNoaXZlcy9odG1sL3hl bi1kZXZlbC8yMDE4LQ0KPiAwNy9tc2cwMTc5MC5odG1sLg0KPiBUaGlzIHdpbGwgbmVlZCB0byBi ZSB0aGUgc3ViamVjdCBvZiBhIGZ1cnRoZXIgY2hhbmdlLg0KPiANCj4gLS0tIGEveGVuL2FyY2gv eDg2L2h2bS92bXgvdm14LmMNCj4gKysrIGIveGVuL2FyY2gveDg2L2h2bS92bXgvdm14LmMNCj4g QEAgLTEzMTIsMTcgKzEzMTIsMTYgQEAgc3RhdGljIHZvaWQgdm14X3NldF9pbnRlcnJ1cHRfc2hh ZG93KHN0cg0KPiANCj4gIHN0YXRpYyB2b2lkIHZteF9sb2FkX3BkcHRycyhzdHJ1Y3QgdmNwdSAq dikNCj4gIHsNCj4gLSAgICB1bnNpZ25lZCBsb25nIGNyMyA9IHYtPmFyY2guaHZtLmd1ZXN0X2Ny WzNdOw0KPiAtICAgIHVpbnQ2NF90ICpndWVzdF9wZHB0ZXM7DQo+ICsgICAgdWludDMyX3QgY3Iz ID0gdi0+YXJjaC5odm0uZ3Vlc3RfY3JbM107DQo+ICsgICAgY29uc3QgdWludDY0X3QgKmd1ZXN0 X3BkcHRlczsNCj4gICAgICBzdHJ1Y3QgcGFnZV9pbmZvICpwYWdlOw0KPiAgICAgIHAybV90eXBl X3QgcDJtdDsNCj4gLSAgICBjaGFyICpwOw0KPiANCj4gICAgICAvKiBFUFQgbmVlZHMgdG8gbG9h ZCBQRFBUUlMgaW50byBWTUNTIGZvciBQQUUuICovDQo+IC0gICAgaWYgKCAhaHZtX3BhZV9lbmFi bGVkKHYpIHx8ICh2LT5hcmNoLmh2bS5ndWVzdF9lZmVyICYgRUZFUl9MTUEpICkNCj4gKyAgICBp ZiAoICFodm1fcGFlX2VuYWJsZWQodikgfHwgaHZtX2xvbmdfbW9kZV9hY3RpdmUodikgKQ0KPiAg ICAgICAgICByZXR1cm47DQo+IA0KPiAtICAgIGlmICggKGNyMyAmIDB4MWZVTCkgJiYgIWh2bV9w Y2lkX2VuYWJsZWQodikgKQ0KPiArICAgIGlmICggY3IzICYgMHgxZiApDQo+ICAgICAgICAgIGdv dG8gY3Jhc2g7DQo+IA0KPiAgICAgIHBhZ2UgPSBnZXRfcGFnZV9mcm9tX2dmbih2LT5kb21haW4s IGNyMyA+PiBQQUdFX1NISUZULCAmcDJtdCwNCj4gUDJNX1VOU0hBUkUpOw0KPiBAQCAtMTMzMiwx NCArMTMzMSwxMiBAQCBzdGF0aWMgdm9pZCB2bXhfbG9hZF9wZHB0cnMoc3RydWN0IHZjcHUNCj4g ICAgICAgICAgICogcXVldWUsIGJ1dCB0aGlzIGlzIHRoZSB3cm9uZyBwbGFjZS4gV2UncmUgaG9s ZGluZyBhdCBsZWFzdA0KPiAgICAgICAgICAgKiB0aGUgcGFnaW5nIGxvY2sgKi8NCj4gICAgICAg ICAgZ2RwcmludGsoWEVOTE9HX0VSUiwNCj4gLSAgICAgICAgICAgICAgICAgIkJhZCBjcjMgb24g bG9hZCBwZHB0cnMgZ2ZuICVseCB0eXBlICVkXG4iLA0KPiArICAgICAgICAgICAgICAgICAiQmFk IGNyMyBvbiBsb2FkIHBkcHRycyBnZm4gJSJQUkl4MzIiIHR5cGUgJWRcbiIsDQo+ICAgICAgICAg ICAgICAgICAgIGNyMyA+PiBQQUdFX1NISUZULCAoaW50KSBwMm10KTsNCj4gICAgICAgICAgZ290 byBjcmFzaDsNCj4gICAgICB9DQo+IA0KPiAtICAgIHAgPSBfX21hcF9kb21haW5fcGFnZShwYWdl KTsNCj4gLQ0KPiAtICAgIGd1ZXN0X3BkcHRlcyA9ICh1aW50NjRfdCAqKShwICsgKGNyMyAmIH5Q QUdFX01BU0spKTsNCj4gKyAgICBndWVzdF9wZHB0ZXMgPSBfX21hcF9kb21haW5fcGFnZShwYWdl KSArIChjcjMgJiB+UEFHRV9NQVNLKTsNCj4gDQo+ICAgICAgLyoNCj4gICAgICAgKiBXZSBkbyBu b3QgY2hlY2sgdGhlIFBEUFRScyBmb3IgdmFsaWRpdHkuIFRoZSBDUFUgd2lsbCBkbyB0aGlzIGR1 cmluZw0KPiBAQCAtMTM1Niw3ICsxMzUzLDcgQEAgc3RhdGljIHZvaWQgdm14X2xvYWRfcGRwdHJz KHN0cnVjdCB2Y3B1DQo+IA0KPiAgICAgIHZteF92bWNzX2V4aXQodik7DQo+IA0KPiAtICAgIHVu bWFwX2RvbWFpbl9wYWdlKHApOw0KPiArICAgIHVubWFwX2RvbWFpbl9wYWdlKGd1ZXN0X3BkcHRl cyk7DQo+ICAgICAgcHV0X3BhZ2UocGFnZSk7DQo+ICAgICAgcmV0dXJuOw0KPiANCj4gLS0tIGEv eGVuL2FyY2gveDg2L2h2bS92bXgvdnZteC5jDQo+ICsrKyBiL3hlbi9hcmNoL3g4Ni9odm0vdm14 L3Z2bXguYw0KPiBAQCAtMTIzNCw3ICsxMjM0LDcgQEAgc3RhdGljIHZvaWQgdmlydHVhbF92bWVu dHJ5KHN0cnVjdCBjcHVfdQ0KPiAgICAgICAgICBwYWdpbmdfdXBkYXRlX3BhZ2luZ19tb2Rlcyh2 KTsNCj4gDQo+ICAgICAgaWYgKCBudm14X2VwdF9lbmFibGVkKHYpICYmIGh2bV9wYWVfZW5hYmxl ZCh2KSAmJg0KPiAtICAgICAgICAgISh2LT5hcmNoLmh2bS5ndWVzdF9lZmVyICYgRUZFUl9MTUEp ICkNCj4gKyAgICAgICAgICFodm1fbG9uZ19tb2RlX2FjdGl2ZSh2KSApDQo+ICAgICAgICAgIHZ2 bWNzX3RvX3NoYWRvd19idWxrKHYsIEFSUkFZX1NJWkUoZ3BkcHRlX2ZpZWxkcyksIGdwZHB0ZV9m aWVsZHMpOw0KPiANCj4gICAgICByZWdzLT5yaXAgPSBnZXRfdnZtY3ModiwgR1VFU1RfUklQKTsN Cj4gQEAgLTE0MzcsNyArMTQzNyw3IEBAIHN0YXRpYyB2b2lkIHZpcnR1YWxfdm1leGl0KHN0cnVj dCBjcHVfdXMNCj4gICAgICBzeW5jX2V4Y2VwdGlvbl9zdGF0ZSh2KTsNCj4gDQo+ICAgICAgaWYg KCBudm14X2VwdF9lbmFibGVkKHYpICYmIGh2bV9wYWVfZW5hYmxlZCh2KSAmJg0KPiAtICAgICAg ICAgISh2LT5hcmNoLmh2bS5ndWVzdF9lZmVyICYgRUZFUl9MTUEpICkNCj4gKyAgICAgICAgICFo dm1fbG9uZ19tb2RlX2FjdGl2ZSh2KSApDQo+ICAgICAgICAgIHNoYWRvd190b192dm1jc19idWxr KHYsIEFSUkFZX1NJWkUoZ3BkcHRlX2ZpZWxkcyksIGdwZHB0ZV9maWVsZHMpOw0KPiANCj4gICAg ICAvKiBUaGlzIHdpbGwgY2xlYXIgY3VycmVudCBwQ1BVIGJpdCBpbiBwMm0tPmRpcnR5X2NwdW1h c2sgKi8NCg== From xen-devel-bounces@lists.xenproject.org Fri Jun 19 01:27:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 01:27:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm5or-0003ay-QV; Fri, 19 Jun 2020 01:27:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm5oq-0003ar-UB for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 01:27:48 +0000 X-Inumbo-ID: 14afe87a-b1cc-11ea-b7bb-bc764e2007e4 Received: from mga01.intel.com (unknown [192.55.52.88]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 14afe87a-b1cc-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 01:27:47 +0000 (UTC) IronPort-SDR: 5cQN70sYRDBDUgKM6/Jv6UJpBdbnkcaeIrUUapb3Q7FcFSnTzc5+ZHVgdufo4vZHHizDAJI5te n/c/z2FL5dbw== X-IronPort-AV: E=McAfee;i="6000,8403,9656"; a="160897144" X-IronPort-AV: E=Sophos;i="5.75,253,1589266800"; d="scan'208";a="160897144" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2020 18:27:46 -0700 IronPort-SDR: zpGYIWk+nr+0Gpvxm8VTM6Qr/0DjX3+SBXWecR5T1hgP4oet72IlNj0457sr5F85Ee7YTtZuoZ tjG1ipVY6wMw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,253,1589266800"; d="scan'208";a="383693782" Received: from orsmsx101.amr.corp.intel.com ([10.22.225.128]) by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2020 18:27:46 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX101.amr.corp.intel.com (10.22.225.128) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 18 Jun 2020 18:27:46 -0700 Received: from orsmsx608.amr.corp.intel.com (10.22.229.21) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 18 Jun 2020 18:27:45 -0700 Received: from ORSEDG002.ED.cps.intel.com (10.7.248.5) by orsmsx608.amr.corp.intel.com (10.22.229.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 18 Jun 2020 18:27:45 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.109) by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 18 Jun 2020 18:27:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aWqbPTyeUgc7lVAaHjfkp2MWkcZjR3RdboiFVf7gPAPsSNmFNnemolAOv8NngHTiwVlHVbZNB2mXRfmC2FwWlMpA9AKqX5HlWiS8Cp+dFhZYYA2NuLpzD5jdqQ+EIeXJHrJD9eiw21mHyfnucr3fICOxejvdHvoRC6Hy5wUHUetIrKS3OfPp0sjortw9nq/rRtJiylCHHffo7YYZwCZ4Nul8m2rD8HT32gPfeKtcClV27Z2e54sKM2pJQUVQ7vlO/DZ91KisxRtvaxw6EyuSi4GvQsfuzRz3N6z98x46H7Z6a7Omt4aMkE/taXBaPmj6VcZ4xLn9W1KuCMctej0gXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Irwg3jMVO+U7YBGlwxYPxnl6+M8wEfdDrLbZpDSWY9k=; b=SfMaAMHCqW0XV1+UWzTxzQnrtz26lKCAoNlRjrHCEYF+iDczAW2ZCYiL+BEgmOrV141HW2cuoyoUBRg8urF2r4TG7mWBP4PtLGps/OzZZoeAn37aRhRpN99vuhZHd2pSMvANSgPu1oIXNQo/fidnsOHN3OO7G7XQI3UzhSGTstXfHoLqDXhFB9J8r412OqdZ9vBQuLk3ZDXCdw2dImCkbLlRQk1WFdGsgQK+wNQ31NXOlzGUpzkX0K+1Le4fipVfXQI0tLjuD9y3OiBnHJdm0L61of/At2eW6ucF/l06clMUxk2SXELhlEclMFo6y34KK4lXm1O0YYsShq/emTZL3Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Irwg3jMVO+U7YBGlwxYPxnl6+M8wEfdDrLbZpDSWY9k=; b=J/xxAwPyTMjPReeS/rgG8Q4KC6WrUgjp9tcDsWdOv88BWLZu1ssytzzutoGoj4nBleMeksw6XrLZGrJcRE+W9TUnlUBz60ICpDGXKX+MqCwgp9wqKVx1U2feSzg8DPphwlmZzS5OBGmwW4lyg4ZlJoC1wLtdjflEAM0xVj67K9M= Received: from MWHPR11MB1645.namprd11.prod.outlook.com (2603:10b6:301:b::12) by MWHPR11MB1391.namprd11.prod.outlook.com (2603:10b6:300:23::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Fri, 19 Jun 2020 01:27:44 +0000 Received: from MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb]) by MWHPR11MB1645.namprd11.prod.outlook.com ([fe80::9864:e0cb:af36:6feb%5]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 01:27:43 +0000 From: "Tian, Kevin" To: "Lengyel, Tamas" , "xen-devel@lists.xenproject.org" Subject: RE: [PATCH v3 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Thread-Topic: [PATCH v3 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Thread-Index: AQHWRX5CY0soX8hKWUKiNsqVFtfc26jfJoww Date: Fri, 19 Jun 2020 01:27:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.147.202] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 38ec0f2b-364b-4d74-741b-08d813eff744 x-ms-traffictypediagnostic: MWHPR11MB1391: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2958; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RlBh7SERJqEFsnbncd6Vf8+pRdeqEL9HrhddtqLYYvLW86NH5LAZxRmfOqo7OzRHiY97fNMUUtYUPDLdN54tpCdw7R44l+9Ys7UrlHSDsQC1aMARmRC2qL03R/Jg2jfepCW7aoCl9g0FMcrJmgOcoBNWkK2jDAhosMAerM8DJA157ss51FAxiEvbE66bC/2cZvklBxn6zkOidwPAXP/Pf3Mooh7bItNVvNa4oDMcz8jiDJby+VRqsbLiEElQbs9kpBd2UWh8qGIJL2II5a24mQk+UdBkfhFJzSfOqsz3Zz8nJk0hf1AsDD4p7a3JPN1O x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1645.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(39860400002)(346002)(396003)(136003)(26005)(52536014)(66946007)(71200400001)(64756008)(66556008)(76116006)(66476007)(66446008)(5660300002)(55016002)(9686003)(186003)(4326008)(86362001)(316002)(8676002)(83380400001)(2906002)(33656002)(110136005)(8936002)(478600001)(54906003)(6506007)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: bKZWRrhbK6MzL2Cl2KU9prvog1uo42JqzfZW801/laZNSZTvXC/v6dDeNTMYjOMRwIG6wmAJFRhoEn+AiOCpHgUoqs7NY4i8uy+yB+gm0oA8cacG8sxkGf8xCp36absXl88Tz7K1dNPykpMD2y/R2otlIZp7Ws5Qfe+NAwsryjh7RZXAujcxvH2hwx5lU9qgrPrpLwMz9qadxJjfKLfs0W7vY9zC2c7SItxcyBaCXF85TBFuAjGYivpzgWag5beqV9CymLUzYES+zcClNjSpDnsWxfHrLvJLqAi4GGHR6QeqvwMmGpQjsAyOYT3XWVfreNNXgPQsOj5Jd/u5lsWOAobTB9qPs3QuChpLgotdRz7WMT+4/AtHCdWzRGjz/zzXaX3GIQ6OebhH5AR65C7pJCbtKd+/PPbU8Bx4d7F8fhPFMc4IPop1WetHti7JSr+/ZiTdokqLpzZfDldJqHr/QgtNTR9BlspAMv2lCwDg01OBGOzscopothsmxmEs3L7I Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 38ec0f2b-364b-4d74-741b-08d813eff744 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 01:27:43.8745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evccvtA3OGQ9+hO/G+LPJ3l8K/J9GtlCIr8z8bagf3SLB+RpZc/uB2Ld7nwvwqbmlin+uMcyGjjA4eAoe2xkEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1391 X-OriginatorOrg: intel.com X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Nakajima, Jun" , Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > From: Lengyel, Tamas > Sent: Thursday, June 18, 2020 10:39 PM >=20 > While forking VMs running a small RTOS system (Zephyr) a Xen crash has > been > observed due to a mm-lock order violation while copying the HVM CPU > context > from the parent. This issue has been identified to be due to > hap_update_paging_modes first getting a lock on the gfn using get_gfn. Th= is > call also creates a shared entry in the fork's memory map for the cr3 gfn= . The > function later calls hap_update_cr3 while holding the paging_lock, which > results in the lock-order violation in vmx_load_pdptrs when it tries to > unshare > the above entry when it grabs the page with the P2M_UNSHARE flag set. >=20 > Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE > was > unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ens= ure > the p2m is properly populated. >=20 > Note that the lock order violation is avoided because before the paging_l= ock > is > taken a lookup is performed with P2M_ALLOC that forks the page, thus the > second > lookup in vmx_load_pdptrs succeeds without having to perform the fork. We > keep > P2M_ALLOC in vmx_load_pdptrs because there are code-paths leading up to > it > which don't take the paging_lock and that have no previous lookup. > Currently no > other code-path exists leading there with the paging_lock taken, thus no > further adjustments are necessary. >=20 > Signed-off-by: Tamas K Lengyel Reviewed-by: Kevin Tian > --- > v3: expand commit message to explain why there is no lock-order violation > --- > xen/arch/x86/hvm/vmx/vmx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index ab19d9424e..cc6d4ece22 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -1325,7 +1325,7 @@ static void vmx_load_pdptrs(struct vcpu *v) > if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) ) > goto crash; >=20 > - page =3D get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, > P2M_UNSHARE); > + page =3D get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, > P2M_ALLOC); > if ( !page ) > { > /* Ideally you don't want to crash but rather go into a wait > -- > 2.25.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 01:40:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 01:40:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm60w-0005ES-Va; Fri, 19 Jun 2020 01:40:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm60v-0005E2-9Y for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 01:40:17 +0000 X-Inumbo-ID: d19c0300-b1cd-11ea-bb1b-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d19c0300-b1cd-11ea-bb1b-12813bfff9fa; Fri, 19 Jun 2020 01:40:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UNHTrPTBC+/2XVQNwmkowv1eWCHrSkHmK1MRpp9OGPM=; b=nuO1LWpKhWsBzLOcnGHUtPoKA UTLkECcpFCMaV+K5sXUQwDXuLST7g++xguo97dN/H4HI+0JUm5TH7ZXINhqQJH1jvLElcbodC2s71 MMPl8dbjkGRx7djjnmhoKYkqiVGXdeWAgSMqdk6rzS1ys2xfNMxzDQvULWMm92BIhwavs=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm60q-0001DN-Jg; Fri, 19 Jun 2020 01:40:12 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jm60q-0005AB-9D; Fri, 19 Jun 2020 01:40:12 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jm60q-0000il-82; Fri, 19 Jun 2020 01:40:12 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 151196: regressions - trouble: blocked/fail/pass/starved X-Osstest-Failures: xen-4.10-testing:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression xen-4.10-testing:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression xen-4.10-testing:test-amd64-amd64-pygrub:debian-di-install:fail:regression xen-4.10-testing:test-amd64-i386-xl-raw:debian-di-install:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=fd6e49ecae03840610fdc6a416a638590c0b6535 X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Fri, 19 Jun 2020 01:40:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151196 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151196/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 150039 test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039 test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039 build-amd64-prev 6 xen-build fail REGR. vs. 150039 build-i386-prev 6 xen-build fail REGR. vs. 150039 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 150039 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 150039 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen fd6e49ecae03840610fdc6a416a638590c0b6535 baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 44 days Failing since 150941 2020-06-09 17:05:34 Z 9 days 10 attempts Testing same since 151163 2020-06-16 02:57:33 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Jan Beulich Jeremi Piotrowski John Thomson Julien Grall Krzysztof Kolasa Marek Marczykowski-Górecki Mark Pryor Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub fail test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw fail test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 301 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 19 03:13:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 03:13:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm7SY-0004PI-RF; Fri, 19 Jun 2020 03:12:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm7SX-0004OZ-GH for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 03:12:53 +0000 X-Inumbo-ID: c2fe21f4-b1da-11ea-b7bb-bc764e2007e4 Received: from mail-lf1-x142.google.com (unknown [2a00:1450:4864:20::142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c2fe21f4-b1da-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 03:12:52 +0000 (UTC) Received: by mail-lf1-x142.google.com with SMTP id y13so4707073lfe.9 for ; Thu, 18 Jun 2020 20:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ux+RlrRIaul1vx3+RsucEfoBIW1+wn2hepN2AwYL3gA=; b=Bt+wAPHbtIEVMjqIuaGC/1uyx9g+h0JmstAgvL3YJl4+t451+WyOTbJOfEvXeXX9eD 1Ltc346gaSEn7p3ivSehx5IBh4xH6ymqh+Cq5lYwtfijHLGYMnDbhhfUEQEC6v7QTi9t Gvpm/+doEjzk2t50RGWoXl/eMh2lar/D82DnoQZeJv6XzRq+Fc5AvAcG2D+/Hskhaijt 5qOCFYr9fyIP7Xa+r/t0Lv45+tYjKdVg59nS+ejWw+WcV4bkYdYXGAGgDgDTeKjRc7CK GEn4QL8/i4qrDlg0rT9E35HKdjJaOz/dsHKWRrtezLn9lpB9h6gMQoE0SemWFonpZquG NmHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ux+RlrRIaul1vx3+RsucEfoBIW1+wn2hepN2AwYL3gA=; b=IYliRRqc6IEOAdgJqxof/Aoev/iZY6uCgWKMcTc2TCRJt7gZCy6jeEHyO7KRJC/lvz QI2AOVzCwWeCYMxvkyOoyHw0SftK8CHRdUWBLm3GNzdxzRZchZRRtPuPogSKhMus1lzh 7YhNvpSWfr8SCPk6aiFO3d7ZtGzjhhNbhdDuQnDj1Gpd10+I2252rYu8RNfVS8pbPazO ZQO/fO6i0K/270XvCgm56dBGozZx320FYL+fpza5VUyk94oL8rmk/Szx5gdElY8D/6fE fVPg51Wd9QS3BMN4MUZhcgwG0y07D308U/dictuv53ohhsSYmKMwryjC3H7IGhfF93/i z3zw== X-Gm-Message-State: AOAM532cHINz2ABDnU+n8YNX6rws7slXnraOGRv+NinHmvii3J0WMbEC 3dGk48Il/GND/PpehndJbpUWENR+Vh93m8WDjNw= X-Google-Smtp-Source: ABdhPJwoJSHfdvQytNKngbcarE9utMq6l97RiL9akPNyVTfXUc439uP32EBiYbbxCOoeDZvLjAyRLu9iHNLCGLt7VZU= X-Received: by 2002:a19:b07:: with SMTP id 7mr509645lfl.38.1592536371497; Thu, 18 Jun 2020 20:12:51 -0700 (PDT) MIME-Version: 1.0 References: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> In-Reply-To: From: Souptick Joarder Date: Fri, 19 Jun 2020 08:42:39 +0530 Message-ID: Subject: Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Boris Ostrovsky Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, paul@xen.org, John Hubbard , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 11:29 PM Boris Ostrovsky wrote: > > On 6/16/20 11:14 PM, Souptick Joarder wrote: > > In 2019, we introduced pin_user_pages*() and now we are converting > > get_user_pages*() to the new API as appropriate. [1] & [2] could > > be referred for more information. > > > > [1] Documentation/core-api/pin_user_pages.rst > > > > [2] "Explicit pinning of user-space pages": > > https://lwn.net/Articles/807108/ > > > > Signed-off-by: Souptick Joarder > > Cc: John Hubbard > > --- > > Hi, > > > > I have compile tested this patch but unable to run-time test, > > so any testing help is much appriciated. > > > > Also have a question, why the existing code is not marking the > > pages dirty (since it did FOLL_WRITE) ? > > > Indeed, seems to me it should. Paul? > > > > > > drivers/xen/privcmd.c | 7 ++----- > > 1 file changed, 2 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > > index a250d11..543739e 100644 > > --- a/drivers/xen/privcmd.c > > +++ b/drivers/xen/privcmd.c > > @@ -594,7 +594,7 @@ static int lock_pages( > > if (requested > nr_pages) > > return -ENOSPC; > > > > - pinned = get_user_pages_fast( > > + pinned = pin_user_pages_fast( > > (unsigned long) kbufs[i].uptr, > > requested, FOLL_WRITE, pages); > > if (pinned < 0) > > @@ -614,10 +614,7 @@ static void unlock_pages(struct page *pages[], unsigned int nr_pages) > > if (!pages) > > return; > > > > - for (i = 0; i < nr_pages; i++) { > > - if (pages[i]) > > - put_page(pages[i]); > > - } > > + unpin_user_pages(pages, nr_pages); > > > Why are you no longer checking for valid pages? My understanding is, in case of lock_pages() end up returning partial mapped pages, we should pass no. of partial mapped pages to unlock_pages(), not nr_pages. This will avoid checking extra check to validate the pages[i]. and if lock_pages() returns 0 in success, anyway we have all the pages[i] valid. I will try to correct it in v2. But I agree, there is no harm to check for pages[i] and I believe, unpin_user_pages() is the right place to do so. John any thought ? From xen-devel-bounces@lists.xenproject.org Fri Jun 19 04:29:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 04:29:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm8eV-0001k6-Q1; Fri, 19 Jun 2020 04:29:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm8eU-0001jn-PE for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 04:29:18 +0000 X-Inumbo-ID: 6fb3a752-b1e5-11ea-bca7-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6fb3a752-b1e5-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 04:29:17 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id l12so8715266ejn.10 for ; Thu, 18 Jun 2020 21:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=8eQIxO3Kr7u1l5tfF2Odv1QyLJr1FfEFhmjrwVHW0Ek=; b=l2h4A1LUXHp/LA9pW4BB2lU0bs11DK9zT61+VkW19o1vxRVSIhGPZek5t8Wb6/XFTl JytqtRyh0sizHYHNaqFFKNvsntJZeGHhXZu+Vv5P923LevpmD6I3V3yTPBQOZxaFZxyy HqZ5uouugq8IVEiavAkv4m8mNrSggUeQ3uw0KOxDo/VcHeUzoE6y/pXl52I4vwVkQxpb obECXrz38jPF5ZBT94TIOqST41nRimE+qrpiE4ccGB+Zi2zTDtcursQq8a1lOLykmeEk wLEPn6DDFtQsAK5ryTwAvsH9XnW8xaqK/5hxSiiKIAHvhRGr5caOpCAk5BTR4mVjR7uJ 9Wjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=8eQIxO3Kr7u1l5tfF2Odv1QyLJr1FfEFhmjrwVHW0Ek=; b=h9v9VtCrwwq9QBcfHAuk5DEw/eN7WeUI85Gz4kb1zoN8la03f5+kKbqE95wPEZYmSn W8YGXr5hm/juqVlSfflce3lffuzapyh+Phscb9Wny6+T6U2aRwr5zIj4n8PR4bB93K9B /jncKx3RY0WmOPN0ZlFjVz0ahcCTnymbznJtCRXW1JXRaenG7TKWpJFPj9eUGA8/8yN3 il8Nj9tU10knQACrDLcqeaOcjUOCua4KKQ3Z1eh6cMImnRUW+GWgLUqLChcgzze5tWlh tMfE08VGka1B7cmVmd/WMenm7uP0fLrdiMtIPUDkI3npZAfetPkuUMop0910YegPhzp/ fxbw== X-Gm-Message-State: AOAM5326reAnesc5r76zdhYcI/8V2hQDS1NJroVM5j+GV2c8eLIW5VjL Sy7nI7O8l5nr6YkUPmsJ9TU1ZdVQrQRZjg== X-Google-Smtp-Source: ABdhPJwiMjEShCiwwpQZHUvfRcmIfP+8hj1OHmGB2RDX9ojZsWDGLtIm3nK2pRQCGZux2of8l4Tolw== X-Received: by 2002:a17:906:8614:: with SMTP id o20mr1943356ejx.444.1592540956313; Thu, 18 Jun 2020 21:29:16 -0700 (PDT) Received: from localhost.localdomain (public-gprs354184.centertel.pl. [37.47.14.201]) by smtp.gmail.com with ESMTPSA id r6sm3850340edq.44.2020.06.18.21.29.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2020 21:29:15 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH v2 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Date: Fri, 19 Jun 2020 04:28:47 +0000 Message-Id: X-Mailer: git-send-email 2.27.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , Jan Beulich , j.nowak26@student.uw.edu.pl, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On some computers the bit width of the PM Timer as reported by ACPI is 32 bits when in fact the FADT flags report correctly that the timer is 24 bits wide. On affected machines such as the ASUS FX504GM and never gaming laptops this results in the inability to resume the machine from suspend. Without this patch suspend is broken on affected machines and even if a machine manages to resume correctly then the kernel time and xen timers are trashed. Signed-off-by: Grzegorz Uriasz --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: "Roger Pau Monné" Cc: marmarek@invisiblethingslab.com Cc: artur@puzio.waw.pl Cc: jakub@bartmin.ski Cc: j.nowak26@student.uw.edu.pl Changes in v2: - Check pm timer access width - Proper timer width is set when xpm block is not present - Cleanup timer initialization --- xen/arch/x86/acpi/boot.c | 8 ++++++-- xen/arch/x86/time.c | 15 +++++++-------- xen/include/acpi/acmacros.h | 8 ++++++++ 3 files changed, 21 insertions(+), 10 deletions(-) diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c index bcba52e232..8d514388b4 100644 --- a/xen/arch/x86/acpi/boot.c +++ b/xen/arch/x86/acpi/boot.c @@ -478,7 +478,9 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) if (fadt->header.revision >= FADT2_REVISION_ID) { /* FADT rev. 2 */ if (fadt->xpm_timer_block.space_id == - ACPI_ADR_SPACE_SYSTEM_IO) { + ACPI_ADR_SPACE_SYSTEM_IO && + (fadt->xpm_timer_block.access_width == 0 || + ACPI_ACCESS_BIT_WIDTH(fadt->xpm_timer_block.access_width) == 32)) { pmtmr_ioport = fadt->xpm_timer_block.address; pmtmr_width = fadt->xpm_timer_block.bit_width; } @@ -490,8 +492,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) */ if (!pmtmr_ioport) { pmtmr_ioport = fadt->pm_timer_block; - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0; + pmtmr_width = fadt->pm_timer_length == 4 ? 32 : 0; } + if (pmtmr_width > 24 && !(fadt->flags & ACPI_FADT_32BIT_TIMER)) + pmtmr_width = 24; if (pmtmr_ioport) printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x (%u bits)\n", pmtmr_ioport, pmtmr_width); diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c index d643590c0a..e9180175e0 100644 --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -457,16 +457,16 @@ static u64 read_pmtimer_count(void) static s64 __init init_pmtimer(struct platform_timesource *pts) { u64 start; - u32 count, target, mask = 0xffffff; + u32 count, target, mask; - if ( !pmtmr_ioport || !pmtmr_width ) + if ( !pmtmr_ioport ) return 0; - if ( pmtmr_width == 32 ) - { - pts->counter_bits = 32; - mask = 0xffffffff; - } + if ( pmtmr_width != 24 && pmtmr_width != 32 ) + return 0; + + pts->counter_bits = (int) pmtmr_width; + mask = (1ull << pmtmr_width) - 1; count = inl(pmtmr_ioport) & mask; start = rdtsc_ordered(); @@ -486,7 +486,6 @@ static struct platform_timesource __initdata plt_pmtimer = .name = "ACPI PM Timer", .frequency = ACPI_PM_FREQUENCY, .read_counter = read_pmtimer_count, - .counter_bits = 24, .init = init_pmtimer }; diff --git a/xen/include/acpi/acmacros.h b/xen/include/acpi/acmacros.h index 6765535053..86c503c20f 100644 --- a/xen/include/acpi/acmacros.h +++ b/xen/include/acpi/acmacros.h @@ -121,6 +121,14 @@ #define ACPI_COMPARE_NAME(a,b) (!ACPI_STRNCMP (ACPI_CAST_PTR (char,(a)), ACPI_CAST_PTR (char,(b)), ACPI_NAME_SIZE)) #endif +/* + * Algorithm to obtain access bit or byte width. + * Can be used with access_width of struct acpi_generic_address and access_size of + * struct acpi_resource_generic_register. + */ +#define ACPI_ACCESS_BIT_WIDTH(size) (1 << ((size) + 2)) +#define ACPI_ACCESS_BYTE_WIDTH(size) (1 << ((size) - 1)) + /* * Macros for moving data around to/from buffers that are possibly unaligned. * If the hardware supports the transfer of unaligned data, just do the store. -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 04:29:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 04:29:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm8eR-0001js-Hb; Fri, 19 Jun 2020 04:29:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm8eP-0001jn-SF for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 04:29:13 +0000 X-Inumbo-ID: 6d49d798-b1e5-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6d49d798-b1e5-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 04:29:13 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id y13so8747089eju.2 for ; Thu, 18 Jun 2020 21:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=J1oXoX9ewxOq7myqcx3lKm9apt/L2OmhEwobt1usPiA=; b=YXRBmOdUgzI1e0Q4ZWUMo+3KiWPwpAh2NSEptI+c69rNOl8CiuXqalLAdAVBF78v2K 8a2VGvOsQY8TO6q7x6HNofQjZd8QpN5ehJen4yGTeEYwNf+GMvZiur7ricjnF5p/GinR MUb/BS2TmXue5VRhYYpAVh2RK63Zq0oGFEspqIUUEQqOSSkNLQO6lq0kSoHskmKk3omX AhgrKZEbDK8WrCtrQfjR69ivYm1CRqHqFWVkrxf30EYXdypqTW5rwmcgBEurN8MR8gQE YOVv9hOxPd9fs16aS8idENPVIM+aLFGu7ab4h5SREHaw3uSB/CM4tGMzE79ZZPInKg0/ cOGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=J1oXoX9ewxOq7myqcx3lKm9apt/L2OmhEwobt1usPiA=; b=b/9dAnIAa7MNFuKiJU002Eyfg1LDt3A4t07oKYvTzAdABaPJcHbtPwmgAcI9vqJaxK UPy+xFZaErkFswG4fR/jXgY9bn49PitGSjv4T9KxNDvnci6mFsYeKpHifvK4FDiI7sIn fGGaCjjiy+DbSQx7H0q/mm0gBrTOo6erWQPAUKl0XilnikUIKEtYQ4Z2BP0ILg3rIc8r +qoK1mRlITqsAENhkrLASd/BRqp6o+eqF1y3zEsGAosHNTCvyXpa9LWON7Q4BsKmzqdV 49le5dnHbC9M6+gJOQGLav68yRp83lzE7BsOqu1L4f7Avo1Y6W0hSS6/H3SLXZkhDjhj 3SPA== X-Gm-Message-State: AOAM530CPm0ZvHFJPKL1c0qEQL7oras5/lm+i0Pbul0Y3VqeMIeXgQVM zZiPZQt2A4V9gKHinfQk8DLaB124J9hLwQ== X-Google-Smtp-Source: ABdhPJwSnPCly9HxviAX/OQ3Eiyxlq43RvAviRySQBWLEBituau3Pq0meh5lepTaw2alQ8TWpYXSpg== X-Received: by 2002:a17:906:35ca:: with SMTP id p10mr1838817ejb.392.1592540952126; Thu, 18 Jun 2020 21:29:12 -0700 (PDT) Received: from localhost.localdomain (public-gprs354184.centertel.pl. [37.47.14.201]) by smtp.gmail.com with ESMTPSA id r6sm3850340edq.44.2020.06.18.21.29.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jun 2020 21:29:11 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH v2 0/1] Fix broken suspend on some machines Date: Fri, 19 Jun 2020 04:28:46 +0000 Message-Id: X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , Jan Beulich , j.nowak26@student.uw.edu.pl, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, The included patch is a small subset of a bigger patch set spanning few projects aiming to isolate the GPU in Qubes OS to a dedicated security domain. I'm doing this together with 3 colleagues as part of our Bachelors thesis. While working on the project we came across 2 machines - newer gaming laptops on which the suspend functionality on unmodified xen is completely broken. The affected machines were able to suspend but not always resume. Even if the resume succeeded then the kernel time was trashed in the dmesg log and the machine never managed to suspend another time. After changing the xen clock to hpet, suspend started working again both on stock xen and Qubes OS - this indicates a bug in the ACPI PM Timer. After disassembling the FADT ACPI table on the ASUS FX504GM I understood that the reported bit width is 32 bits but the flags indicate a 24 bit PM timer. The included patch fixes the suspend feature on ASUS FX504GM and hopefully other laptops - Probably next week I will test this patch on my friend's laptop where this issue also occurs(suspend is broken, trashed kernel time after resume). Changes in v2: - Check pm timer access width - Proper timer width is set when xpm block is not present - Cleanup timer initialization Grzegorz Uriasz (1): x86/acpi: Use FADT flags to determine the PMTMR width xen/arch/x86/acpi/boot.c | 8 ++++++-- xen/arch/x86/time.c | 15 +++++++-------- xen/include/acpi/acmacros.h | 8 ++++++++ 3 files changed, 21 insertions(+), 10 deletions(-) -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 05:31:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 05:31:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm9cW-0007km-41; Fri, 19 Jun 2020 05:31:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm9cU-0007kS-3G for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 05:31:18 +0000 X-Inumbo-ID: 13e054e4-b1ee-11ea-bb33-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 13e054e4-b1ee-11ea-bb33-12813bfff9fa; Fri, 19 Jun 2020 05:31:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TrpeFcUMBuc4o3QpgBylh6slwC3QKDJJsPb2+GEmsuI=; b=Q+Zqrjo2VyIO3fIyPO0LsnAXb +gSUqHVwLWmqy3r/ubV7zWaYTeiEvCe5G0+U+sEv0qYXbiDLUw7LNfiCFvcb4PmdzcNy0y2IPYyEo 6fMtan8gS4iDN5U8+CWv2bbHGwM9e7AUdC8NU5dLZ+3rd+HvqVcaBdjG7clvyT61NzxRQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jm9cJ-0006gy-QU; Fri, 19 Jun 2020 05:31:07 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jm9cJ-0000S0-Id; Fri, 19 Jun 2020 05:31:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jm9cJ-0003Hd-Hz; Fri, 19 Jun 2020 05:31:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 151200: regressions - FAIL X-Osstest-Failures: linux-5.4:test-amd64-amd64-libvirt-vhd:guest-start/debian.repeat:fail:regression linux-5.4:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=fd8cd8ac940c8b45b75474415291a3b941c865ab X-Osstest-Versions-That: linux=5e3c511539228fa03c8d00d61b5b5f32333ed0b0 From: osstest service owner Date: Fri, 19 Jun 2020 05:31:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151200 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/151200/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 151022 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151022 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux fd8cd8ac940c8b45b75474415291a3b941c865ab baseline version: linux 5e3c511539228fa03c8d00d61b5b5f32333ed0b0 Last test of basis 151022 2020-06-10 18:39:22 Z 8 days Testing same since 151200 2020-06-17 16:10:55 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: "Eric W. Biederman" Alexander Potapenko Alexandre Belloni Alla Segal Amir Goldstein Andi Shyti Andreas Gruenbacher Andrew Morton Andrii Nakryiko Anson Huang Anthony Steinhauser Ard Biesheuvel Aristeu Rozanski Arnaldo Carvalho de Melo Arnaud Pouliquen Arnd Bergmann Barret Rhoden Bartlomiej Zolnierkiewicz Bjorn Andersson Bjorn Helgaas Bob Haarman Boris Ostrovsky Borislav Petkov Breno Lima Casey Schaufler Chandrakanth Patil Chris Wilson Christoph Hellwig Christophe JAILLET Christophe Leroy Chuhong Yuan Cédric Le Goater Daniel Borkmann Daniel Jordan Dave Rodgman David Howells David S. Miller Denis Efremov Dennis Kadioglu Dick Kennedy Dmitry Torokhov Eiichi Tsukata Eric Biggers Eric W. Biederman Ezequiel Garcia Fabio Estevam Fangrui Song Felipe Franciosi Florian Fainelli Franck LENORMAND Fredrik Strupe Geert Uytterhoeven Giuseppe Scrivano Gonglei Greg Kroah-Hartman Guenter Roeck Guo Ren Hangbin Liu Hans de Goede Herbert Xu Hill Ma Huacai Chen Hui Wang Ido Schimmel Ingo Molnar James Morse James Smart Jan Kara Jason Gunthorpe Jens Axboe Jiri Kosina Jue Wang Juergen Gross Justin Chen Kai-Heng Feng Kalle Valo Kamal Dasu Kan Liang Kim Phillips Kirill Shutemov Leonard Crestez Libor Pechacek Linus Torvalds Linus Walleij Longpeng(Mike) Lorenzo Pieralisi Luca Coelho Ludovic Barre Ludovic Desroches Lukas Wunner Marc Zyngier Marcelo Ricardo Leitner Marcelo Ricardo Leitner Maria Teguiani Mark Brown Martin K. Petersen Masahiro Yamada Masami Hiramatsu Masashi Honma Matthias Maennich Maxim Mikityanskiy Michael Ellerman Michael Ellerman (powerpc) Michael S. Tsirkin Michał Mirosław Miklos Szeredi Namjae Jeon Nick Desaulniers Nikolay Aleksandrov OGAWA Hirofumi Oleg Nesterov Paolo Bonzini Pavel Dobias Peng Fan Petar Penkov Peter Zijlstra (Intel) Peter Zijlstra Petr Tesarik Qian Cai Qiujun Huang Qiushi Wu Qiuxu Zhuo Rafael J. Wysocki Rodrigo Siqueira Russell King Ryusuke Konishi Saeed Mahameed Sam Ravnborg Sasha Levin Sean Christopherson Sedat Dilek # build+boot on Serge Semin Shawn Guo Shay Drory Shuah Khan Stanislav Fomichev Stephan Gerhold Steve French Suman Anna Sumit Saxena Takashi Iwai Takashi Sakamoto Tanner Love tannerlove Tero Kristo Thomas Falcon Thomas Gleixner Tony Luck Ulf Hansson Vadim Pasternak Vasily Averin Vasily Gorbik Veerabhadrarao Badiganti Viresh Kumar Vlad Buslov Waiman Long Wang Hai Wei Yongjun Will Deacon Willem de Bruijn Wim Van Sebroeck Wolfram Sang Xiaochun Lee Xin Long Xing Li youling257@gmail.com Yuxuan Shui jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 4147 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 19 07:04:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 07:04:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmB4P-0006fd-4g; Fri, 19 Jun 2020 07:04:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmB4O-0006fY-4P for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 07:04:12 +0000 X-Inumbo-ID: 130636ee-b1fb-11ea-8496-bc764e2007e4 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [40.107.6.84]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 130636ee-b1fb-11ea-8496-bc764e2007e4; Fri, 19 Jun 2020 07:04:10 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NGLvpUesbAVzlS/xQLN6986Wmb9JVf4X7Wp6NDZa2qprg2th+gE82nL52+gBMn87lWeJ76p0yQb6zYVTPJqLQWhjkWl+3KYh7gAGvSFyODUgFcQwdSFMhaHOdKAOSvfe4gBk8/PliewnWx6wULHmTemGqh67VPcAUFxbuT4XaSC/SGdTSeUUdszQjwi0oiCilJClsWqsGUjZmcUOPKMA6lRCy2V9UXs7NlGWIV55rjYFPIgfOtw0Et5OYkRfqbU8npSMY+Yz6LKVrZtTyOjZxgxG/xP+vxmg3hTXUGXbywZ0iOX+Fob9rqcNRQprZsk3ud2dMjJRZOTfU+PLqrdlWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IX10gaq8mT5z7N3X0XaZB5NGJLfFs/lGAlNs6eoqfkU=; b=gj23dno78KUQfu6T36cZTffcQQvxDXbR36DMO6L2cdFwcnnG0P9JiLpDYnMHDjXnbUh8eISbQrvAARwd2zjR2mLmIRDSKR+6/XxIRHKtEIoVbkSNqyCnpI7aqqKKXIOXfF+R3b0arvS1xQQr1usbOiUJU9MylRvgY6q6+JB/JjZ7zBLCZ7qT2QAfnMmTTfF3HyVk3Jhq8KTkXG2mETT71ELH96qlramUzN+mQl/2LMI19AKID63PaeEJVnZa7ckXxqABGKYAhCIfN0DJMFJyTdO2Ig8kKUjTcnP8T/9e9DdzZwl5x/NeiC43LBtKoj9XpbqaFxBFaaeFp4idzlWigA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IX10gaq8mT5z7N3X0XaZB5NGJLfFs/lGAlNs6eoqfkU=; b=FwAqNHb5aQeazxxQwSDvlfuHiqLUUt81djKxoO4iu9dm760t8GkKinFCjgSnPEUwa+BDgGO1/leO56JiW0Ues9B8DD07lUUfVdOH/eX6h6hekU6duYHPxFy60N4k7ymffbS4lE6IJJKTkEmmDByG8JwYTjNyTk0t3aO2c6goDdNK+UVk6Fs8N/eMturtIEO3mmvCWTRlMAYaQPiOL3Y5fBLuTaJUzR1K88aFj6V5mkhxJ9aEEhUAG3kVaYtMfmTSHT+P7+fBHhbr+uXrjAbpnO2p5bCYMapYaQtZvT3j9Jt3ym+Z1xiAcq0v779cc6rI1g9UPAGqpZnHSACwF3oF2g== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB6448.eurprd03.prod.outlook.com (2603:10a6:800:17d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 19 Jun 2020 07:04:07 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 07:04:06 +0000 From: Oleksandr Andrushchenko To: Julien Grall , Stefano Stabellini Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIABEAqA Date: Fri, 19 Jun 2020 07:04:06 +0000 Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> In-Reply-To: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d007dd33-75fd-4648-4c7a-08d8141ef547 x-ms-traffictypediagnostic: VI1PR03MB6448: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3ghIs9S3v3CfPmPF1cFlOy0zcTKBFwi1OWOGNI3mr3I1rYvepn2i0NmSyYladIB6ewPqxYIdaLos0XcAJ3dCZ+6un390xyZZYXt7AiPvPCE+eAeKgUFJEjKeCk0XfsxeQWaz7/M94oIqRA0LM1LwsxbccR2OUo1bEGB4V+zycfRTLx+rBCgM5feYinv4awyrg9ueux9AyLixooQ7byjH+/V7xul6F6JGzOyewwbj4kpWcIGVRZVxFiaW+PRaoKrJqJRU4ZJK9UdYjI6MIm6HwEU6jPQe5O6qOBItUDY6vZwqzOnJPXXflVh8az1KqaQLbYOQcepW4I26OJBBLWlcWwH83xM1qb0QQRIltFsyEEEt/pp4RjWgjdcDYaO/qi5n7VFAFB+MDhGAu74YJGEn7w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(136003)(396003)(366004)(8676002)(53546011)(31696002)(83380400001)(36756003)(8936002)(31686004)(5660300002)(186003)(110136005)(66556008)(64756008)(54906003)(66446008)(86362001)(6506007)(2906002)(6512007)(966005)(478600001)(316002)(4326008)(76116006)(66476007)(71200400001)(91956017)(66946007)(26005)(6486002)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: d8Wa17p4Y3wknGBqxlWAcv7NRBAaPW8vDNwumBp9wPXtWgJT5YuhWNb7qYDXccs0Qhes8TPzi2iq0kuIWntUCdpPvZO6o3AGFYt7dVzp9N89heNNPp26upgMQDYrruvyTV/VZJqIQ9elWf5CFJKv6LOGHjYv7Wy1aeLWY4WeWUIIz2OPsLXlrNTtpUiaFItZ2/6W1z0CjKPHk+AfUsRcV71mVGGCxCPTtmGGJ8qMP3ZbM891s9Y4yNBNmijkb5E+NOj/BRgX1IZFTWWIov5Ftghpe+zvldqNeeiYsFyMa0k3GHWr49KMPJA7TatJA7TQKXe0Ai6AgO1jeU/9swN904c/PctD9i9LLEWGQ025Q/nkxPxyrY6Nk9TjYvjhnJlE/B8wf3jLascB6R7voHkHUPvfSAsf61TBh5Axyh2tuBYrlGYtH9de2yW5Tm5+1bKiYRxlYy9ADRLJqdKRpJ2dgV6mRzaPBzgB3KBv6FzY0qo= Content-Type: text/plain; charset="utf-8" Content-ID: <981E3D710F5F3041A0ABCD65CBF093C6@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: d007dd33-75fd-4648-4c7a-08d8141ef547 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 07:04:06.8150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: n0KsntJi0rsIcIv4NeCrZBq/3492dfjZ8LH5h9h/nATfcN2AUJeQj/ogQAG2nh2WLUSxleC0xM/iWWlFhDk6nNk3yLkzFDejGNP4Kr35nFr0yEnW7PwByY5tjfDcKavr X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6448 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzE4LzIwIDU6NTAgUE0sIEp1bGllbiBHcmFsbCB3cm90ZToNCj4NCj4NCj4gT24gMTgv MDYvMjAyMCAwNjoyMiwgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gd3JvdGU6DQo+Pg0KPj4gT24g Ni80LzIwIDY6MzEgUE0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4+PiBPbiBUaHUsIDQg SnVuIDIwMjAsIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPj4+PiBPbiA2LzQvMjAg NDo1NyBBTSwgUGVuZyBGYW4gd3JvdGU6DQo+Pj4+PiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+Ow0K Pj4+Pj4+IE5hdGFsaXlhIEtvcm92a2luYSA8bWFsdXMuYnJhbmR5d2luZUBnbWFpbC5jb20+DQo+ Pj4+Pj4gU3ViamVjdDogVUVGSSBzdXBwb3J0IGluIEFSTSBEb21Vcw0KPj4+Pj4gV2UgaGF2ZSBt YWRlIFUtQm9vdCBydW4gaW5zaWRlIFhFTiBEb21VLCBidXQganVzdCBvbmx5IFBWIGNvbnNvbGUg cGFydCwNCj4+Pj4+IG5vdCBpbXBsZW1lbnQgb3RoZXIgZnJvbnRlbmQgZHJpdmVycyBjdXJyZW50 bHkuIFdvdWxkIHRoaXMgaGVscCBmb3IgeW91cg0KPj4+Pj4gY2FzZSBpZiBlbmFibGUgRUZJIGlu IFUtQm9vdD8NCj4+Pj4gV2VsbCwgd2UgaGF2ZSBhIHdvcmtpbmcgUFYgYmxvY2sgaW1wbGVtZW50 YXRpb24gb24gdG9wIG9mIHRoYXQgb24gaU1YOA0KPj4+Pg0KPj4+PiBwbGF0Zm9ybSwgbW9zdGx5 IHBvcnRlZCBmcm9tIG1pbmktb3MuIEN1cnJlbnRseSB3ZSBhcmUgZmluYWxpemluZyB0aGUgd29y aw0KPj4+Pg0KPj4+PiBhbmQgY2xlYW5pbmcgdXAgKGl0J3MgZ29pbmcgdG8gdGFrZSBhIHdlZWsg b3Igc28gaG9wZWZ1bGx5KS4gVGhlbiwgd2Ugd2UnbGwgcG9zdA0KPj4+Pg0KPj4+PiBpdCBvbiBv dXIgcHVibGljIGdpdGh1Yi4gV2UgYXJlIGFsc28gdGhpbmtpbmcgYWJvdXQgdXBzdHJlYW1pbmcg dGhlIHdvcmssIGJ1dCBpdCBtYXkNCj4+Pj4NCj4+Pj4gdGFrZSBxdWl0ZSBzb21lIHRpbWUgaWYg dGhlIHdob2xlIGlkZWEgZml0cyB1LWJvb3QncyB2aWV3IG9uIHN1Y2ggYW4gZXh0ZW5zaW9uIGF0 IGFsbC4NCj4+PiBZZXMgcGxlYXNlIHRvIGJvdGggb2YgeW91ISA6LSkNCj4+Pg0KPj4+IEluIHRo ZSBtZWFudGltZSwgd2hpbGUgd2Ugd2FpdCBmb3IgdGhvc2UgY2hhbmdlcyB0byBnbyB1cHN0cmVh bSBpbg0KPj4+IHVib290LCBjb3VsZCB5b3UgcGxlYXNlIHBvc3QgYSBicmFuY2ggb24gZ2l0aHVi IGFuZCBhIGxpbmsgb24gdGhpcyBlbWFpbA0KPj4+IHRocmVhZD8NCj4+DQo+PiBJdCB0b29rIGEg Yml0IG1vcmUgdGltZSB0aGFuIHdlIGV4cGVjdGVkLCBidXQgaGVyZSB3ZSBnbyBbMV06DQo+Pg0K Pj4gdGhpcyBpcyBpbiBmb3JtIG9mIGEgcHVsbC1yZXF1ZXN0IGFzIHdlIHdvdWxkIGxvdmUgdG8g aGVhciBmcm9tIHRoZQ0KPj4NCj4+IGNvbW11bml0eSBhbmQgaXQgaXMgZWFzaWVyIHRvIGRpc2N1 c3MgdGhlIGNvZGUgKHBsZWFzZSBsZWF2ZSBjb21tZW50cyB0aGVyZSkNCj4+DQo+PiAxLiBUaGVy ZSBpcyBjb2RlIG9yaWdpbmF0aW5nIGZyb20gTWluaU9TIGFuZCB3b3JrIGRvbmUgYnkgUGVuZywg c28gd2UNCj4+DQo+PiB3b3VsZCBsaWtlIHRvIGFzayB0aGUgcmVzcGVjdGl2ZSBjb3B5cmlnaHQg b3duZXJzIHRvIHJhaXNlIHRoZWlyIGhhbmRzIGFuZA0KPg0KPiBOb3QgZXZlcnlvbmUgYXJlIGNs b3NlbHkgd2F0Y2hpbmcgeGVuLWRldmVsLiBTbyBpZiB5b3Ugd2FudCB0byBmaW5kIG91dCB3aG8g YXJlIHRoZSBjb3B5cmlnaHQgb3duZXJzLCB0aGVuIHlvdXIgYmVzdCBzb2x1dGlvbiBpcyB0byBn byB0aHJvdWdoIHRoZSBnaXQgbG9nIGFuZCBDQyB0aGUgYXV0aG9ycy4NCg0KV2UgZGlkbid0IHdh bnQgdG8gY29udGFjdCB0aGUgcmVzcGVjdGl2ZSBhdXRob3JzIGFuZCBjb3B5cmlnaHQgb3duZXJz IChzb21lIG9mIHRob3NlDQoNCmFyZSBkYXRlZCAyMDA1IG9yIHNvKS4gVGhpcyBpcyB0byBzdHJl c3MgdGhhdCB3ZSBhcmUgdHJ5aW5nIGhhcmQgdG8gcHV0IGFsbCB0aGUgY29weXJpZ2h0cw0KDQph bmQgbm90IG1pc3MgYW55b25lOiB0aGVyZSBpcyBubyBpbnRlbnRpb24gdG8gcHV0IG91ciBjb3B5 cmlnaHQgYXQgc29tZSBpbmFwcHJvcHJpYXRlDQoNCnBsYWNlIGFuZCByZW1vdmUgc29tZW9uZXMg ZWxzZS4NCg0KPg0KPj4NCj4+IGxldCB1cyAqZml4IGluYXBwcm9wcmlhdGUgbGljZW5zaW5nKiBp ZiBhbnkuDQo+Pg0KPj4gMi4gUGxlYXNlIG5vdGUsIHRoZSBzZXJpZXMgaGFzIGEgSEFDSyB0byBt b3ZlIHRoZSBSQU0gYmFzZSBhcyBpdCBpcyBleHBlY3RlZCBieQ0KPj4NCj4+IG91ciB0ZXN0IHBs YXRmb3JtIChpTVg4KSwgc28gb3RoZXJzIHdpbGwgbmVlZCB0byByZW1vdmUgb3IgbW9kaWZ5IHRo YXQuDQo+Pg0KPj4gMy4gVGhlcmUgaXMgYSBsaW1pdGF0aW9uIGFscmVhZHkgbm90ZWQgYnkgUGVu ZyB0aGF0IHdlIGRvIG5vdCBoYXZlIHNlcmlhbCBvdXRwdXQNCj4+DQo+PiB1bnRpbCBNTVUgaXMg c2V0dXAsIHNvIHdlIGhhdmUgaW50cm9kdWNlZCB4ZW5fZWFybHlfcHJpbnRrIGhlbHBlciB3aGlj aCBhbHdheXMNCj4+DQo+PiB3b3Jrcywgc28geW91IGNhbiB1c2UgdGhhdCBmb3IgZWFybHkgc3Rh Z2UgZGVidWdnaW5nLg0KPj4NCj4+IDQuIE1pbmltYWwgbWVtb3J5IHNpemUgc3VwcG9ydGVkIGlz IH4xMjlNIGJlY2F1c2Ugb2YgZHRiIHBsYWNlbWVudCBieSBYZW4gdG9vbHMNCj4NCj4gSG1tbS4u LiBXaHk/IFdoYXQncyB3cm9uZyB3aXRoIGJvb3RpbmcgYSBndWVzdCB3aXRoIGp1c3QgNjRNQj8N Cg0KQmVjYXVzZSBvZiB0aGUgYnVnIGluIFUtYm9vdCBbMV06IGl0IHRyaWVzIHRvIHJlYWQgYmV5 b25kIHRoZSBwaHlzaWNhbCBtZW1vcnkgaWYgZ3Vlc3QNCg0KaGFzIGxlc3MgdGhhbiAxMjhNKyBh cyBvbmx5IHRoZW4gWGVuIHRvb2xzIHB1dCB0aGUgZmR0IGF0IDEyOE0gYW5kIG5vdCBhdCB0aGUg UkFNIGVuZC4NCg0KPg0KPj4NCj4+IDUuIFdlIHVzZSAtRF9fWEVOX18gdG8gYWNjZXNzIHNvbWUg b2YgdGhlIGhpZGRlbiBkZWZpbmVzIHdlIG5lZWQgc3VjaCBhcw0KPj4NCj4+IEdVRVNUX1JBTTBf QkFTRSBhbmQgdGhlIGZyaWVuZHMgYXMgdGhlcmUgaXMgbm8gb3RoZXIgd2F5IGJ1dCBtYW51YWxs eSBkZWZpbmluZyB0aGUNCj4+DQo+PiBzYW1lIHdoaWNoIGlzIG5vdCBjdXRlLg0KPg0KPiBJIGhh dmUgcmVwbGllZCB0byB0aGlzIGluIHRoZSBwdWxsIHJlcXVlc3QuIEJ1dCBJIHdhbnQgdG8gYnJp bmcgdGhlIGNvbnZlcnNhdGlvbiBoZXJlIHRvIGhhdmUgYSB3aWRlciBkaXNjdXNzaW9uLg0KPg0K PiBGb3IgYSBmaXJzdCwgX19YRU5fXyBzaG91bGQgcmVhbGx5IG9ubHkgYmUgZGVmaW5lZCBieSB0 aGUgaHlwZXJ2aXNvciBhbmQgbm90IHVzZWQgYnkgdGhlIGd1ZXN0LiBUaGlzIGlzIHVzZWQgdG8g Z2F0ZSBub24tc3RhYmxlIEFCSSAoc3VjaCBhcyB0aGUgdG9vbHMpIGFuZCBhbnl0aGluZyBiZWhp bmQgaXQgaGFzbid0IGJlZW4gdmV0dGVkIHRvIHdvcmsgaW4gb3RoZXIgYnVpbGQgY29uZmlndXJh dGlvbiB0aGF0IHRoZSBvbmUgdXNlZCBieSBYZW4uDQo+DQo+IEluIGdlbmVyYWwsIHdlIGV4cGVj dCB0aGUgZ3Vlc3QgdG8gZGlzY292ZXIgZXZlcnl0aGluZyBmb3IgdGhlIGRldmljZS10cmVlIGJl Y2F1c2UgdGhlIG1lbW9yeSBsYXlvdXQgaXMgbm90IHN0YWJsZSAod2Ugd2FudCB0byBiZSBhYmxl IHRvIHJlc2h1ZmZsZSBhcyB3ZSBhZGQgbW9yZSBmZWF0dXJlcykuDQo+DQo+IEkga25vdyB0aGF0 IEVESzIvVGlhbm9jb3JlIGNhbiBiZSBidWlsdCBvbmNlIGFuZCB3b3JrIG9uIGV2ZXJ5IFhlbiBj b25maWd1cmF0aW9uLiBJdCB3b3VsZCBiZSBpZGVhbCB0aGF0IFUtYm9vdCBmb2xsb3cgdGhlIHNh bWUuIElmIGl0IGlzIHJlYWxseSBub3QgcG9zc2libGUsIHRoZW4gd2Ugc2hvdWxkIGV4cGxvcmUg YSBwYXRoIHRoYXQgaXMgcHJldmVudGluZyB0byBkZWZpbmUgX19YRU5fXy4NCj4NCj4gSG93IG11 Y2ggZG9lcyBVLWJvb3QgZXhwZWN0IHRvIGtub3cgYWJvdXQgdGhlIG1lbW9yeSBsYXlvdXQ/IERv ZXMgaXQgcmVxdWlyZSB0byBrbm93IGFsbCB0aGUgbWVtb3J5IGJhbmtzPyBPciB3b3VsZCBpdCBi ZSBzdWZmaWNpZW50IGZvciBpdCB0byBrbm93IHRoZSBzdGFydCBhZGRyZXNzIG9mIHRoZSBmaXJz dCBiYW5rIGFuZCB0aGUgbWluaW11bSBvZiBSQU0/DQo+DQo+IENoZWVycywNCj4NClsxXSBodHRw czovL2dpdGh1Yi5jb20veGVuLXRyb29wcy91LWJvb3QvcHVsbC8xL2NvbW1pdHMvOWM2MzliZDUx NDk2MWU3MGNmYjJlYmVkOWQ4YmFkYjdiMjJkMjFhYg== From xen-devel-bounces@lists.xenproject.org Fri Jun 19 07:30:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 07:30:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmBU0-0000cO-8U; Fri, 19 Jun 2020 07:30:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmBTz-0000cJ-9r for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 07:30:39 +0000 X-Inumbo-ID: c570c120-b1fe-11ea-bb3e-12813bfff9fa Received: from hqnvemgate24.nvidia.com (unknown [216.228.121.143]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c570c120-b1fe-11ea-bb3e-12813bfff9fa; Fri, 19 Jun 2020 07:30:38 +0000 (UTC) Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Fri, 19 Jun 2020 00:28:56 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Fri, 19 Jun 2020 00:30:37 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Fri, 19 Jun 2020 00:30:37 -0700 Received: from [10.2.62.75] (172.20.13.39) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 19 Jun 2020 07:30:37 +0000 Subject: Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Souptick Joarder , Boris Ostrovsky References: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> From: John Hubbard Message-ID: Date: Fri, 19 Jun 2020 00:30:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1592551736; bh=Fe6+LEcBGqkmcut7uJjH2j1++zsWFrmLLtaEG5FehVs=; h=X-PGP-Universal:Subject:To:CC:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:X-Originating-IP: X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=PO9cecDSmGNiqNB9v5SItJ0pP9uHG0j0hqx1mly0Bozfnb61r+QlkigFmHiTrjnVA 50uX8ugVzjFrQw9jzH7jZsAMEl15fvx3mdu/9Gcq7OD00kQJskp6KzIJUGz6hc8OL4 KMekN5uR3E7Z+Wc/XpK5k89x0TIpuvw7DQYHPhudM544WumvUaJGuay2QtZFqcmFd5 DsfAD52xAevCZE4moN72e/Vm5ogJR7OQldT//bYwFB+jBy/UHz24CJjD2BdN3Uj6/l 9Z/5BV/dhjoeF3QGmiYjbHENP6qry3q39uhEjU5fcIBe5nxaOlx4cz3UlErPqcrUsb ZWF0KVgCIk6xg== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , xen-devel@lists.xenproject.org, sstabellini@kernel.org, linux-kernel@vger.kernel.org, paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-18 20:12, Souptick Joarder wrote: > On Wed, Jun 17, 2020 at 11:29 PM Boris Ostrovsky > wrote: >> >> On 6/16/20 11:14 PM, Souptick Joarder wrote: >>> In 2019, we introduced pin_user_pages*() and now we are converting >>> get_user_pages*() to the new API as appropriate. [1] & [2] could >>> be referred for more information. Ideally, the commit description should say which case, in pin_user_pages.rst, that this is. >>> >>> [1] Documentation/core-api/pin_user_pages.rst >>> >>> [2] "Explicit pinning of user-space pages": >>> https://lwn.net/Articles/807108/ >>> >>> Signed-off-by: Souptick Joarder >>> Cc: John Hubbard >>> --- >>> Hi, >>> >>> I have compile tested this patch but unable to run-time test, >>> so any testing help is much appriciated. >>> >>> Also have a question, why the existing code is not marking the >>> pages dirty (since it did FOLL_WRITE) ? >> >> >> Indeed, seems to me it should. Paul? Definitely good to get an answer from an expert in this code, but meanwhile, it's reasonable to just mark them dirty. Below... >> >> >>> >>> drivers/xen/privcmd.c | 7 ++----- >>> 1 file changed, 2 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c >>> index a250d11..543739e 100644 >>> --- a/drivers/xen/privcmd.c >>> +++ b/drivers/xen/privcmd.c >>> @@ -594,7 +594,7 @@ static int lock_pages( >>> if (requested > nr_pages) >>> return -ENOSPC; >>> >>> - pinned = get_user_pages_fast( >>> + pinned = pin_user_pages_fast( >>> (unsigned long) kbufs[i].uptr, >>> requested, FOLL_WRITE, pages); >>> if (pinned < 0) >>> @@ -614,10 +614,7 @@ static void unlock_pages(struct page *pages[], unsigned int nr_pages) >>> if (!pages) >>> return; >>> >>> - for (i = 0; i < nr_pages; i++) { >>> - if (pages[i]) >>> - put_page(pages[i]); >>> - } >>> + unpin_user_pages(pages, nr_pages); ...so just use unpin_user_pages_dirty_lock() here, I think. >> >> >> Why are you no longer checking for valid pages? > > My understanding is, in case of lock_pages() end up returning partial > mapped pages, > we should pass no. of partial mapped pages to unlock_pages(), not nr_pages. > This will avoid checking extra check to validate the pages[i]. > > and if lock_pages() returns 0 in success, anyway we have all the pages[i] valid. > I will try to correct it in v2. > > But I agree, there is no harm to check for pages[i] and I believe, Generally, it *is* harmful to do unnecessary checks, in most code, but especially in most kernel code. If you can convince yourself that the check for null pages is redundant here, then please let's remove that check. The code becomes then becomes shorter, simpler, and faster. > unpin_user_pages() > is the right place to do so. > > John any thought ? So far I haven't seen any cases to justify changing the implementation of unpin_user_pages(). thanks, -- John Hubbard NVIDIA From xen-devel-bounces@lists.xenproject.org Fri Jun 19 07:33:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 07:33:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmBWc-0000kX-MT; Fri, 19 Jun 2020 07:33:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmBWb-0000kR-Gw for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 07:33:21 +0000 X-Inumbo-ID: 25b6fb4e-b1ff-11ea-bb3e-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 25b6fb4e-b1ff-11ea-bb3e-12813bfff9fa; Fri, 19 Jun 2020 07:33:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date: Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=728HHyIo6p5jd0t/nnpHhhDp0disceXIBDG94ds5xwo=; b=itPeCfYxp2CmDQGWUHYz4B4gRO vXX/lAWg1/copLPrIUvzINDNdAtppL9Q16fcrxQ3mRi05sJ6MTqg8YavIjY8XE2Wemfhi1nqQyEJa P7mYvsMnGmqNdveIr2KIn2CS2ZZWttQea+/E0f0MpQb8IRHsPEu+3a5lLplkv7UvhZH0=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmBWY-0000XM-RK; Fri, 19 Jun 2020 07:33:18 +0000 Received: from 54-240-197-224.amazon.com ([54.240.197.224] helo=u2f063a87eabd5f.cbg10.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jmBWY-0001QB-He; Fri, 19 Jun 2020 07:33:18 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org Subject: [PATCH for 4.14] libxl: allow passthrough to PV guests regardless of whether IOMMU is enabled Date: Fri, 19 Jun 2020 08:33:15 +0100 Message-Id: <20200619073315.8414-1-paul@xen.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Paul Durrant , Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Paul Durrant Commit babde47a "introduce a 'passthrough' configuration option to xl.cfg..." added a check to xl_parse.c:parse_config_data() to make sure that an IOMMU was present and enabled in the system before allowing devices to be passed through to a guest. This check was then subsequently moved into libxl_create.c:libxl__domain_config_setdefault() by commit ad011ad0 "libxl/xl: Overhaul passthrough setting logic". Prior to this check being added, it was possible (although not in any way safe or supported) to pass devices through to a PV guest without an IOMMU being enabled in the system. This patch relaxes the check for PV guests to restore that possibility, emitting a warning instead. Signed-off-by: Paul Durrant --- Cc: Ian Jackson Cc: Wei Liu A Cc: Anthony PERARD This patch ought to be in 4.14 as it as very obvious change, restoring lost functionality that has affected a user. --- tools/libxl/libxl_create.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 2814818e34..f1d17cfb87 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -1104,10 +1104,14 @@ int libxl__domain_config_setdefault(libxl__gc *gc, bool iommu_enabled = physinfo.cap_hvm_directio; if (c_info->passthrough != LIBXL_PASSTHROUGH_DISABLED && !iommu_enabled) { - LOGD(ERROR, domid, - "passthrough not supported on this platform\n"); - ret = ERROR_INVAL; - goto error_out; + if (c_info->type != LIBXL_DOMAIN_TYPE_PV) { + LOGD(ERROR, domid, + "passthrough not supported on this platform\n"); + ret = ERROR_INVAL; + goto error_out; + } + LOGD(WARN, domid, + "passthrough is enabled but IOMMU is not present/enabled\n"); } if (c_info->passthrough == LIBXL_PASSTHROUGH_DISABLED && need_pt) { -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 08:41:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 08:41:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCa5-0006px-Jx; Fri, 19 Jun 2020 08:41:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCa3-0006ps-Uc for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 08:41:00 +0000 X-Inumbo-ID: 98b5ad30-b208-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 98b5ad30-b208-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 08:40:58 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id t13so6417692wrs.2 for ; Fri, 19 Jun 2020 01:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=tPIVcPOh9X2NVe2nN9LV2R3qW5V9zX1EvT4m1GHYZj4=; b=N+ifp5rlDp5SDl7qaGVjc2BywRzFQLcmaWaInLHUlI1ANG4ML9T55D/T1KdnriDztN 5TUlpSAscMu+4RYXaw/6tl5Rh6S/yUz63rIDLas43wZMp2mr4wvQTDeaipVyblgAIy6G g8uaOAuxT45nVLyi6IKLAbegGjasJxytO7oCB8epw2lnxOAftjnVy5RCkkVFykjOPZ7G gwfkfHLpbZ0BRP+pDmoDqL67Z6Q5ixWqQbtkwHHd0GipMD5vC32GRXkmchN3godX+NmU vFlY+dUbr/tOGjovs7HVNBCvGtwyHjiekrBItlmUKwkBR+XuV+2jJFcO2ZUg+f+udErO hWRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=tPIVcPOh9X2NVe2nN9LV2R3qW5V9zX1EvT4m1GHYZj4=; b=Gb9Ox/VWQh/AUbtRffRZExlbEEqdDqLPxJG3fna1rrKuVepWwhKoJweL3KqFXKrDk4 eFrYDi7uuqrlS90UPCcoSGeI7Y67eX8Ledj71Puy/bZSchfEro/Q13YUMNYkUQ2fIvz9 EQjk9CEi8NrG3dBvu41TSkFXeHG8Kio0GjtwpBl1Gw4aBi/JUbMmSJMWr9ZcdKTOlE5G f580AsntDu4kkeFaUKlhIS2Kt6mkMXqOeFHVWxrBQTkLyw4UDh2gh6iqTL7qV880RTp0 5mixTkMvp+RV+SE8xzAvoN9QqPNQtnD+wDv5S+7ajY19OXuPfI5DRYRVsgEvcAagDXcV qTGQ== X-Gm-Message-State: AOAM533BdMzBlMxvthVTy0SrU+pkXk4lcSxdtLcvsKgQNPsH8E6aHkHQ RI/C1FL2GFExwxpxkDj90cs= X-Google-Smtp-Source: ABdhPJwPirNlXIVk7lJXXph+kEmtOaXhxUQz1BUt+HRAA3IQKAJ1co98aVEwVdHjvoY/rWbORtjTpw== X-Received: by 2002:adf:f70e:: with SMTP id r14mr3054581wrp.150.1592556057574; Fri, 19 Jun 2020 01:40:57 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id r12sm6472281wrc.22.2020.06.19.01.40.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 01:40:56 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Stefano Stabellini'" , , References: <20200506014246.3397490-1-volodymyr_babchuk@epam.com> <51b8c855-5e94-2829-a703-d43c84948120@xen.org> In-Reply-To: Subject: RE: [PATCH] optee: immediately free buffers that are released by OP-TEE Date: Fri, 19 Jun 2020 09:40:55 +0100 Message-ID: <00a701d64615$59d076e0$0d7164a0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKXhFJJ4ChNwzgTFWNefwS6FU305wI2G0MJA0Yfo+0BhgRBlwL2OG+uAiWMtYCm/DAoEA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: tee-dev@lists.linaro.org, 'Andrew Cooper' , 'Julien Grall' , 'Volodymyr Babchuk' , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Stefano Stabellini > Sent: 18 June 2020 23:21 > To: xadimgnik@gmail.com; pdurrant@amazon.co.uk > Cc: Andrew Cooper ; Julien Grall = ; Volodymyr Babchuk > ; xen-devel@lists.xenproject.org; = tee-dev@lists.linaro.org > Subject: Re: [PATCH] optee: immediately free buffers that are released = by OP-TEE >=20 > Actually adding Paul >=20 >=20 > On Thu, 18 Jun 2020, Stefano Stabellini wrote: > > Hi Paul, Julien, > > > > Volodymyr hasn't come back with an update to this patch, but I think = it > > is good enough as-is as a bug fix and I would rather have it in its > > current form in 4.14 than not having it at all leaving the bug = unfixed. > > > > I think Julien agrees. > > > > > > Paul, are you OK with this? I will take my direction from the maintainers as to whether this fixes a = critical issue and hence is a candidate for 4.14. If Volodymyr doesn't = come back with a v2 then I would at least want a formal ack of this = patch, and the cosmetic change requested by Julien fixed on commit, as = well as... > > > > > > > > On Mon, 11 May 2020, Stefano Stabellini wrote: > > > On Mon, 11 May 2020, Andrew Cooper wrote: > > > > On 11/05/2020 10:34, Julien Grall wrote: > > > > > Hi Volodymyr, > > > > > > > > > > On 06/05/2020 02:44, Volodymyr Babchuk wrote: > > > > >> Normal World can share buffer with OP-TEE for two reasons: > > > > >> 1. Some client application wants to exchange data with TA > > > > >> 2. OP-TEE asks for shared buffer for internal needs > > > > >> > > > > >> The second case was handle more strictly than necessary: > > > > >> > > > > >> 1. In RPC request OP-TEE asks for buffer > > > > >> 2. NW allocates buffer and provides it via RPC response > > > > >> 3. Xen pins pages and translates data > > > > >> 4. Xen provides buffer to OP-TEE > > > > >> 5. OP-TEE uses it > > > > >> 6. OP-TEE sends request to free the buffer > > > > >> 7. NW frees the buffer and sends the RPC response > > > > >> 8. Xen unpins pages and forgets about the buffer > > > > >> > > > > >> The problem is that Xen should forget about buffer in between = stages 6 > > > > >> and 7. I.e. the right flow should be like this: > > > > >> > > > > >> 6. OP-TEE sends request to free the buffer > > > > >> 7. Xen unpins pages and forgets about the buffer > > > > >> 8. NW frees the buffer and sends the RPC response > > > > >> > > > > >> This is because OP-TEE internally frees the buffer before = sending the > > > > >> "free SHM buffer" request. So we have no reason to hold = reference for > > > > >> this buffer anymore. Moreover, in multiprocessor systems NW = have time > > > > >> to reuse buffer cookie for another buffer. Xen complained = about this > > > > >> and denied the new buffer registration. I have seen this = issue while > > > > >> running tests on iMX SoC. > > > > >> > > > > >> So, this patch basically corrects that behavior by freeing = the buffer > > > > >> earlier, when handling RPC return from OP-TEE. > > > > >> > > > > >> Signed-off-by: Volodymyr Babchuk > > > > >> --- > > > > >> xen/arch/arm/tee/optee.c | 24 ++++++++++++++++++++---- > > > > >> 1 file changed, 20 insertions(+), 4 deletions(-) > > > > >> > > > > >> diff --git a/xen/arch/arm/tee/optee.c = b/xen/arch/arm/tee/optee.c > > > > >> index 6a035355db..af19fc31f8 100644 > > > > >> --- a/xen/arch/arm/tee/optee.c > > > > >> +++ b/xen/arch/arm/tee/optee.c > > > > >> @@ -1099,6 +1099,26 @@ static int handle_rpc_return(struct > > > > >> optee_domain *ctx, > > > > >> if ( shm_rpc->xen_arg->cmd =3D=3D = OPTEE_RPC_CMD_SHM_ALLOC ) > > > > >> call->rpc_buffer_type =3D > > > > >> shm_rpc->xen_arg->params[0].u.value.a; > > > > >> + /* > > > > >> + * OP-TEE signals that it frees the buffer that it = requested > > > > >> + * before. This is the right for us to do the same. > > > > >> + */ ...this comment being re-worded: "OP-TEE is signalling that it has freed the buffer that it requested = before. This is the right time for us to do the same." perhaps? Paul > > > > >> + if ( shm_rpc->xen_arg->cmd =3D=3D = OPTEE_RPC_CMD_SHM_FREE ) > > > > >> + { > > > > >> + uint64_t cookie =3D = shm_rpc->xen_arg->params[0].u.value.b; > > > > >> + > > > > >> + free_optee_shm_buf(ctx, cookie); > > > > >> + > > > > >> + /* > > > > >> + * This should never happen. We have a bug = either in the > > > > >> + * OP-TEE or in the mediator. > > > > >> + */ > > > > >> + if ( call->rpc_data_cookie && = call->rpc_data_cookie !=3D > > > > >> cookie ) > > > > >> + gprintk(XENLOG_ERR, > > > > >> + "Saved RPC cookie does not = corresponds to > > > > >> OP-TEE's (%"PRIx64" !=3D %"PRIx64")\n", > > > > > > > > > > s/corresponds/correspond/ > > > > > > > > > >> + call->rpc_data_cookie, cookie); > > > > > > > > > > IIUC, if you free the wrong SHM buffer then your guest is = likely to be > > > > > running incorrectly afterwards. So shouldn't we crash the = guest to > > > > > avoid further issue? > > > > > > > > No - crashing the guest prohibits testing of the interface, = and/or the > > > > guest realising it screwed up and dumping enough state to = usefully debug > > > > what is going on. > > > > > > > > Furthermore, if userspace could trigger this path, we'd have to = issue an > > > > XSA. > > > > > > > > Crashing the guest is almost never the right thing to do, and = definitely > > > > not appropriate for a bad parameter. > > > > > > Maybe we want to close the OPTEE interface for the guest, instead = of > > > crashing the whole VM. I.e. freeing the OPTEE context for the = domain > > > (d->arch.tee)? > > > > > > But I think the patch is good as it is honestly. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 08:41:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 08:41:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCaF-0006rK-0A; Fri, 19 Jun 2020 08:41:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCaD-0006rB-PL for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 08:41:09 +0000 X-Inumbo-ID: 9ed8c7d8-b208-11ea-b7bb-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9ed8c7d8-b208-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 08:41:08 +0000 (UTC) Received: from webmail.moloch.sk (w3-s.a.lucina.net [62.176.169.73]) by smtp.lucina.net (Postfix) with ESMTPSA id BDF71122804; Fri, 19 Jun 2020 10:41:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592556067; bh=asZAW8ytMFfTsgxokf5mQeT7kTk0KwF+C+X+TX76kis=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gBdOW0isyKQbxhes8TGpBinbxv+ekQpFt73NxNCMIZPWZ9Ie3ZjdNKotH+UEW1Z2A rz58VGU6FO00Lew2vgwzvRq9WO7ji5SmxHzSCxWdUdmLkTWWNX8FtVeyb9jq/RUU5N uV4qP+5LM68PlEWHg17BnLJ2c/iH9nhQoPXVbxQZ5dtta+2dFdcjzOU4iBS3Gpgp/0 haDWVqD6a07/Ti4brGxWiK+9PDb1MILdv1URQj2u6eGivUX2DPj3NkvP6upOpV+j/v 9bA9gW6rODd8c8rnJC6cd5P4QsHMamUO7GJMp4WeyhU6yCMN2oZ66c6YRlee6wBHk9 K8PwGr+DrBf+w== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 19 Jun 2020 10:41:07 +0200 From: Martin Lucina To: Andrew Cooper Subject: Re: Event delivery and "domain blocking" on PVHv2 In-Reply-To: <2f5c8fbc-0153-17b7-4a44-8f8ba0e3179f@citrix.com> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <2f5c8fbc-0153-17b7-4a44-8f8ba0e3179f@citrix.com> Message-ID: X-Sender: martin@lucina.net User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-19 01:43, Andrew Cooper wrote: > On 18/06/2020 11:13, Martin Lucina wrote: >> On Monday, 15.06.2020 at 17:58, Andrew Cooper wrote: >>> On 15/06/2020 15:25, Martin Lucina wrote: >>>> Hi, >>>> >>>> puzzle time: In my continuing explorations of the PVHv2 ABIs for the >>>> new MirageOS Xen stack, I've run into some issues with what looks >>>> like >>>> missed deliveries of events on event channels. >>>> >>>> While a simple unikernel that only uses the Xen console and >>>> effectively does for (1..5) { printf("foo"); sleep(1); } works fine, >>>> once I plug in the existing OCaml Xenstore and Netfront code, the >>>> behaviour I see is that the unikernel hangs in random places, >>>> blocking >>>> as if an event that should have been delivered has been missed. >>> You can see what is going on, event channel wise, with the 'e' >>> debug-key.  This will highlight cases such as the event channel being >>> masked and pending, which is a common guest bug ending up in this >>> state. >> Ok, based on your and Roger's suggestions I've made some changes: >> >> 1. I've dropped all the legacy PIC initialisation code from the Solo5 >> parts, written some basic APIC initialisation code and switched to >> using >> HVMOP_set_evtchn_upcall_vector for upcall registration, along with >> setting >> HVM_PARAM_CALLBACK_IRQ to 1 as suggested by Roger and done by Xen when >> running as a guest. Commit at [1], nothing controversial there. > > Well... > >     uint64_t apic_base = rdmsrq(MSR_IA32_APIC_BASE); >     wrmsrq(MSR_IA32_APIC_BASE, >             apic_base | (APIC_BASE << 4) | MSR_IA32_APIC_BASE_ENABLE); >     apic_base = rdmsrq(MSR_IA32_APIC_BASE); >     if (!(apic_base & MSR_IA32_APIC_BASE_ENABLE)) { >         log(ERROR, "Solo5: Could not enable APIC or not present\n"); >         assert(false); >     } > > The only reason Xen doesn't crash your guest on that WRMSR is because > 0xfee00080ull | (0xfee00000u << 4) == 0xfee00080ull, due to truncation > and 0xfe | 0xee == 0xfe. > > Either way, the logic isn't correct. Oh, thanks. Don't you wish C had a "strict" mode where you could disable/warn on implicit type promotion? I certainly do. > > Xen doesn't support moving the APIC MMIO window (and almost certainly > never will, because the only thing which changes it is malware).  You > can rely on the default state being correct, because it is > architecturally specified. Noted. I'll change the code to just verify that APIC_BASE is indeed FEE00000 at start of day and that the enable operation succeeded -- I like to keep the code robust, e.g. against cut-n-pasting to somewhere else that might be used in a non-Xen context later where the precondition may not hold. Martin > > ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 19 08:46:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 08:46:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCes-00078j-Lq; Fri, 19 Jun 2020 08:45:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCer-00078e-IC for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 08:45:57 +0000 X-Inumbo-ID: 49cd7ddc-b209-11ea-bb8b-bc764e2007e4 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.41]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 49cd7ddc-b209-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 08:45:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p8NAY2KUazQ/5vajcMbELbyEbERL6Tt41EYXFTZPD/A=; b=7jMc2RudMZCB2jUVJeOYJ84iT9vS4Rpgs8fsWsy3pY6fo878EkndF1crqZx8IQ3TLcKuaB7tasBsDH9olUissaPR2a0JxmxhZRlYWxEkO2dXy1NeQrjuJ5AO1dGxUMp5bDc7+LSZjTinti2KxXq5E1fBEI41tjGdvfcO9/xIUy4= Received: from DB6PR1001CA0006.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:4:b7::16) by HE1PR08MB2683.eurprd08.prod.outlook.com (2603:10a6:7:2b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.25; Fri, 19 Jun 2020 08:45:54 +0000 Received: from DB5EUR03FT045.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:b7:cafe::b) by DB6PR1001CA0006.outlook.office365.com (2603:10a6:4:b7::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Fri, 19 Jun 2020 08:45:53 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT045.mail.protection.outlook.com (10.152.21.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Fri, 19 Jun 2020 08:45:53 +0000 Received: ("Tessian outbound cdcc6148d2f4:v59"); Fri, 19 Jun 2020 08:45:53 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 570f18e698e1fc00 X-CR-MTA-TID: 64aa7808 Received: from 7a2918b6f7c6.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1F222A07-C281-40E8-B776-8584FDBE8EB0.1; Fri, 19 Jun 2020 08:45:48 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 7a2918b6f7c6.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 19 Jun 2020 08:45:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UJgt2zU2wMTvI97b9VAk8zTcxWiZTzzx7iIxutQhUs2LBCiLHng2NdPXUgcOrQOIo7iHnSGuyCGpIRo3+7QsleA7ytCJCfaVVBRMVe6gEXRyjZ9R4Ht03qOM7azGqzDxPhXxEhoNTSnKDNZtGVDVjzQpSTylx7AGqP01ne9NkRh/Ttyz+h9kA1oNICI3UuKUQxnmM3jVzyBKhqiQV3hYsl940EJvY8klwR6oA/qMi2NLFrKEM0GHfHPngJR6iXFKmdJA19QAXTi8Ca4kBYd2ORXYGYM+2/X1FoAR0GWamnd0TOac6ys/mDD+yEzqwb1BKPceG5Ul//ugpzTOnVcUQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p8NAY2KUazQ/5vajcMbELbyEbERL6Tt41EYXFTZPD/A=; b=aOWPFYWQtbKNTbLxXA88dv2cJO5B06E1Z+ldsyGOoKAegTMSzWDGH+a/D9Ym0UxF1u9mgQKdJ8FsUCtOk0Ch33feWR0Hzin/qQklELD2582SJx31d4VhVKM3/nxrF9YN7Z4EGVIDHwQDwSywcYyzXNM6JsJTqKf3gAo2JNO7QfGc6Q2G5qeM63trQshQdR/XePoKZgAfNTKiZmp1gkvpk5K6/ixJKMoD5oWLijzDewL14tnCrLEaw0/WA2Wg9KuZxfm6uSaz82p8eyS87gpDxx+XDc7my4S+u4aVE3CBpXmY68yR/PyKf4w3g02umGWaxT7XIMUksqcwJCMSY1bCMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p8NAY2KUazQ/5vajcMbELbyEbERL6Tt41EYXFTZPD/A=; b=7jMc2RudMZCB2jUVJeOYJ84iT9vS4Rpgs8fsWsy3pY6fo878EkndF1crqZx8IQ3TLcKuaB7tasBsDH9olUissaPR2a0JxmxhZRlYWxEkO2dXy1NeQrjuJ5AO1dGxUMp5bDc7+LSZjTinti2KxXq5E1fBEI41tjGdvfcO9/xIUy4= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3387.eurprd08.prod.outlook.com (2603:10a6:10:45::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 19 Jun 2020 08:45:46 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 08:45:46 +0000 From: Bertrand Marquis To: Julien Grall Subject: Re: [Tee-dev] TEE with XEN Thread-Topic: [Tee-dev] TEE with XEN Thread-Index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQAw/zsAAIeJWwAAHsEHgA== Date: Fri, 19 Jun 2020 08:45:46 +0000 Message-ID: <68572FBC-8AE3-44A4-A815-1A9A7FFFA098@arm.com> References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> In-Reply-To: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 77d9986e-8ada-45d7-2bc0-08d8142d2d2c x-ms-traffictypediagnostic: DB7PR08MB3387:|HE1PR08MB2683: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0439571D1D X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: pDq3vheIwV16leFs7cn5vpImXIJRhuKLvMnZWSkv7QXmgwiRnsZgFectr9h3TPtH7uhlM/EolHKjPlCfob5kAWNsS3GInDkD7CPmoZxDqoKntLHTihV6I+02lSbvbj5MXMlYVgQBMn5Oh0XtojPDQvNtcgwuInn6ev54icH5cseJh7n74Ry+14sZBkxvZaFPhlYIuVlWlOKbdnfIoWf/+ejzsvmyGapBCpeJZYMg0nCc/5eVY0526Edot5YU7aknPNBqucpb0cax1TLBs23mt7pPLYeWWverRLjML0rcQZfgRU0euAAMy+cCCT7jpECcIHTJz7uSs8ktGP9LKL//vA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(39860400002)(366004)(346002)(83380400001)(6512007)(86362001)(8936002)(6486002)(478600001)(5660300002)(8676002)(2906002)(36756003)(4326008)(2616005)(186003)(6916009)(66446008)(64756008)(54906003)(66476007)(53546011)(33656002)(6506007)(76116006)(91956017)(66946007)(316002)(66556008)(71200400001)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0E9toorM09dFfLlzYGPi4c3W84SQziWu7L/Sv3ro6DDD42/fhozELyPasqAPtVL7Dp5htSEyni5YbGWuCejliVaxhFguaP7qM3/H/DkZgkL4kNdLz/CYW6WdD9N/k4TcpXEHyNl8tO6/mOejnOGZfvp/2de8AMenuH1Shcy24UNqFmtRMPsOqMuaDmIr1GKRATHJlRjCo7s3EYi2oLxUkMc2iZY1aWSjZBDXxbyjKD5+ne/W8v1CcE2PeOC01XB4n3FvUCorqoanB/1NR3C6GgD+Ggjf4oK57ULXcvq73wtV1xpJmw1IMah8xUxH/gfffn8F+LFkiAWN0Gld9Cgt76IeTl4Z+Nd0piIxmJEhvP1HDuhkhdVSPgE/di7sMxmNhI7VQf8iDs7777mxt3e0pFiWVgFCsrxceoCyzYLJDJwhPQ+QbBqPlld+4OMSrqtHCMsw49hLVpI5zdlIOo0ssJC2AvzT+KKxyJXFtmJpKUg3NSYuv/4IuKBHvg9f2gEr x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2C1A9EDA11296C4395B8185FADACD7AE@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3387 Original-Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT045.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(346002)(376002)(46966005)(6512007)(70586007)(70206006)(2616005)(6486002)(186003)(356005)(8936002)(82310400002)(336012)(478600001)(83380400001)(26005)(36756003)(33656002)(81166007)(2906002)(47076004)(86362001)(4326008)(8676002)(53546011)(54906003)(5660300002)(6862004)(316002)(82740400003)(6506007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 1b4febd1-7ad3-43f2-a8db-08d8142d28df X-Forefront-PRVS: 0439571D1D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KOZ4LuC43s9NZmL3eK1J5XT2BaKsuepM3CqV3Mr9OfTD4Y8FbvPbg9WleEVtWFjGfMAu5XsnakyWbPBmWSz+4nyZ6FhyN9Dy80TYGCb8rU4yBKcF8BNPtAgyVjUfFJE07x441KbJoTsWCr8pZbVe7pn/PBAKfVNqx8LQWVToWdefktpmI070Eu/MIi+tj/2nBYyE03VWJ2RS3bRTxkNY/tEZ1aX1+/FXigd7b0esntox0EcuUASyZ/Q/EvDWo1mECcD9j0wURPXgJfI9ANNIvDKCEH0rgPlMqjzSkmNV2iKPAVPfWhxoFmpeC3eZJYvFoV4kYTp2j888MIWl5tX+rSyLq82THrdvPxJqZxEriDkzAapaTqyTTMY/1grfe8AWEPSiN3jqfrcAhZNL5k72tg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2020 08:45:53.6808 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77d9986e-8ada-45d7-2bc0-08d8142d2d2c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB2683 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peng Fan , Stefano Stabellini , Oleksandr Andrushchenko , Volodymyr Babchuk , "tee-dev@lists.linaro.org" , Xen-devel , nd , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGksDQoNCj4gT24gMTggSnVuIDIwMjAsIGF0IDE5OjA1LCBKdWxpZW4gR3JhbGwgPGp1bGllbkB4 ZW4ub3JnPiB3cm90ZToNCj4gDQo+ICtCZXJ0cmFuZCBhbmQgU3RlZmFubw0KPiANCj4gT24gMTYv MDYvMjAyMCAwMjoyNCwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+PiBIaSBQZW5nLA0KPj4g T24gTW9uLCAxNSBKdW4gMjAyMCBhdCAwNTowNywgUGVuZyBGYW4gPHBlbmcuZmFuQG54cC5jb20+ IHdyb3RlOg0KPj4+IA0KPj4+IEhpIEFsbCwNCj4+PiANCj4+PiBXaGlsZSBlbmFibGluZyB0cnVz dHkgb3Mgd2l0aCB4ZW4sIEkgdG9vayBzYW1lIGFwcHJvYWNoIGFzIE9QLVRFRSwNCj4+PiB3aXRo IE9QLVRFRSBydW5uaW5nIGluIHNlY3VyZSB3b3JsZC4gQnV0IEkgYW0gYWxzbyB0aGlua2luZyB0 aGlzIG1pZ2h0DQo+Pj4gaW50cm9kdWNlIHBvdGVudGlhbCBpc3N1ZSBpcyB0aGF0IHNlY3VyZSB3 b3JsZCBPUyBjb21tdW5pY2F0ZSB3aXRoIERvbVUuDQo+Pj4gSWYgdGhlcmUgYXJlIHNvbWUgbWlz YmVoYXZpb3IgaW4gc2VjdXJlIHdvcmxkIE9TLCBpdCBtaWdodCBsZXQgWEVODQo+Pj4gaHlwZXJ2 aXNvciBub3Qgd29yayBwcm9wZXIuDQo+Pj4gDQo+Pj4gSW4gbXkgc2V0dXAsIHRydXN0eSBvcyBz b21ldGltZXMgcGFuaWMgaW4gc2VjdXJlIHdvcmxkLCB4ZW4gd2lsbCBub3QgYWJsZQ0KPj4+IHRv IGNvbnRyb2wgdGhlIHBhbmljIGNvcmUgYW55bW9yZS4NCj4gDQo+IE1heSBJIGFzayBpbiB3aGlj aCBjYXNlIFRydXN0eSBpcyBwYW5pY2tpbmc/DQoNCkluIGFueSBjYXNlLCBvcHRlZSBzaG91bGQg cHJvdGVjdCBpdHNlbGYgYWdhaW5zdCB0aGlzIGFuZCBpdCBzaG91bGQgYmUgY29uc2lkZXJlZCB0 aGF0IG9wdGVlIGlzIG1vcmUgcHJpdmlsZWRnZWQgdGhlbiBYZW4uDQpTbyBpZiBvcHRlZSBpcyBj cmFzaGluZyB3ZSBjYW5ub3QgZXhwZWN0IHRoYXQgWGVuIGNhbiByZWNvdmVyIG9yIGZpeCBpdC4N Cg0KSSB3b3VsZCBtb3JlIGNvbnNpZGVyIHRoaXMgYXMgYSBidWcgdGhhdCBvcHRlZSBuZWVkcyB0 byBiZSByb2J1c3QgYWdhaW5zdC4NCg0KPiANCj4+PiANCj4+PiBTbyBJIGFtIHRoaW5raW5nIHdo ZXRoZXIgd2UgbmVlZCB0byBlbXVsYXRpbmcgc2VjdXJlIHdvcmxkIGluIGEgWEVOIFZNDQo+Pj4g d2hpY2ggaXMgdGhlIFZNIHJ1bm5pbmcgRG9tVS4gSnVzdCBsaWtlIHdoYXQgQUNSTiBkaWQgdG8g cnVuIHRydXN0eQ0KPj4+IG9zLg0KPj4gV2VsbCwgaXQgZGVwZW5kcyBvbiB3aG9tIHlvdSBhcmUg dHJ1c3RpbmcgbW9yZS4gQm90aCBYRU4gYW5kIFRFRSBhcmUgbWluaW1hbA0KPj4gT1MgaW1wbGVt ZW50YXRpb25zIHdpdGggYWltIGF0IHNlY3VyaXR5LiBJJ20gc3BlYWtpbmcgYWJvdXQgZ2VuZXJp YyBURUUgT1MsIG5vdA0KPj4gYWJvdXQgcGFydGljdWxhciBPUyBsaWtlIE9QLVRFRSBvciBUcnVz dHkuIFByb2JsZW0gaXMgdGhhdCwgaWYgVEVFIGlzDQo+PiBydW5uaW5nIGluc2lkZQ0KPj4gVk0s IGl0IHdpbGwgYmUgc3VzY2VwdGlibGUgdG8gYSBoeXBlcnZpc29yIG1pc2JlaGF2aW91ci4gWW91 IG5lZWQgdG8gdW5kZXJzdGFuZA0KPj4gdGhhdCBYZW4gYW5kIHByaXZpbGVnZWQgZG9tYWluIChk b20wLCBtb3N0bHkpIGNhbiBhY2Nlc3MgbWVtb3J5IG9mIGFueSBndWVzdC4NCj4+IEF0IGxlYXN0 LCBpbiBkZWZhdWx0IGNvbmZpZ3VyYXRpb24uIFRoZXJlIGFyZSBtZWFucyB0byBoYXJkZW4gdGhp cw0KPj4gc2V0dXAuIEJ1dCBhbnl3YXlzLA0KPj4gWGVuIGNhbid0IGJlIHN0b3BwZWQgZnJvbSBy ZWFkaW5nIFRFRSdzIHNlY3JldHMuDQo+IA0KPiBJSVJDLCB3ZSBkaXNjdXNzZWQgdGhpcyBhcHBy b2FjaCBmb3IgT1AtVEVFIGluIHRoZSBwYXN0LiBUaGVyZSB3YXMgb3RoZXIgcG90ZW50aWFsIHBp dGZhbGxzIHdpdGggaXQuIEZvciBpbnN0YW5jZSwgeW91IHdvdWxkbid0IGJlIGFibGUgdG8gZGly ZWN0bHkgYWNjZXNzIGFueSBzZWN1cmUgZGV2aWNlIGZyb20gdGhhdCBndWVzdCAoaXQgaXMgcnVu bmluZyBpbiBub24tc2VjdXJlIHdvcmxkKS4NCj4gDQo+IFRoZXJlIGFyZSBhbHNvIGlzc3VlcyBp biB0ZXJtIG9mIGxhdGVuY3kgYXMgeW91IG1heSBoYXZlIHRoZSBmb2xsb3dpbmcgbW9kZWw6DQo+ IA0KPiBkb21VIC0+IFhlbiAtPiBkb21VIFRFRSAtPiAoWGVuIC0+IGhvc3QgVEVFIC0+IFhlbiAt PiBkb21VIFRFRSkgLT4gWGVuIC0+IGRvbVUuDQo+IA0KPiBUaGUgYml0IGluICgpIGlzIGlmIHlv dSByZXF1aXJlIHRvIGNhbGwgdGhlIGhvc3QgVEVFLg0KPiANCj4gT25lIHBvc3NpYmlsaXR5IHdv dWxkIGJlIHRvIHVzZSBTZWN1cmUtRUwyIGZvciB5b3VyIFRydXN0eSBPUy4gQnV0IEkgZG9uJ3Qg a25vdyB3aGV0aGVyIHlvdXIgcGxhdGZvcm0gc3VwcG9ydHMgaXQuDQo+IA0KPiBEZXBlbmRpbmcg b24gd2hldGhlciB5b3UgY2FuIG1vZGlmeSBUcnVzdHkgT1MsIGFsdGVybmF0aXZlIHdvdWxkIGJl IHRvIG1ha2UgaXR2aXJ0dWFsaXphdGlvbiBhd2FyZSBhcyBPUC1URUUgZGlkLiBUaGUgY29yZSB3 b3VsZCBuZWVkIHRvIGJlIHJlc2lsaWVudCBhbmQgdGhlIHBhbmljIG9ubHkgYWZmZWN0IGEgZ2l2 ZW4gY2xpZW50Lg0KDQpJIGRvIG5vdCBoYXZlIHJpZ2h0IGEgY2xlYXIgaWRlYSBvZiB3aGF0IGlz IHRoZSBzdGF0dXMgb2Ygb3B0ZWUgYW5kIHhlbiBidXQgaW4gdGhlb3J5IEkgd291bGQgc2VlIDIg cG9zc2libGUgd2F5cyB0byBoYW5kbGUgdGhpczoNCi0gd2l0aG91dCBvcHRlZSBtb2RpZmljYXRp b24sIHNvbWV0aGluZyBpbiBhIGd1ZXN0IChEb20wIG9yIGFuIG90aGVyIHByaXZpbGVkZ2VkIG9u ZSkgbmVlZHMgdG8gaGF2ZSBhY2Nlc3MgdG8gb3B0ZWUgYW5kIGVtdWxhdGUgb3B0ZWUgYWNjZXNz IGZvciBvdGhlcnMuDQotIHdpdGggb3B0ZWUgbW9kaWZpY2F0aW9ucywgb3B0ZWUgbmVlZHMgdG8g aGF2ZSBhIGNvbmNlcHQgb2YgY2xpZW50IGFuZCBYZW4gd291bGQgbmVlZCB0byBwYXNzdGhyb3Vn aCBvcHRlZSByZXF1ZXN0cyBidXQgYmVpbmcgcmVzcG9uc2libGUgb2YgYWRkaW5nIGEg4oCcY2xp ZW504oCdIGlkZW50aWZpZXIuIE1heWJlIGFsc28gaW5mb3JtaW5nIE9wdGVlIHdoZW4gYSBuZXcg Y2xpZW50IGlzIGNyZWF0ZWQvcmVtb3ZlZC4NCg0KVGhlIHNlY29uZCBzY2VuYXJpbyBjb3VsZCB0 aGVuIGJlIHNvbWVob3cgc3BsaXR0ZWQgaW4gdGhlIHByZXZpb3VzIG9uZSBmcm9tIEp1bGllbiBp ZiBzb21lIHBhcnRzIHdvdWxkIG5lZWQgdG8gYmUgZW11bGF0ZWQgc29tZXdoZXJlIGluIHNvbWUg a2luZCBvZiBjb21iaW5hdGlvbiBvZiB0aGUgMiBtb2RlbHMuDQoNCkluIGFueSBjYXNlIGkgd291 bGQgYWx3YXlzIGNvbnNpZGVyIHRoYXQgYW55dGhpbmcgcnVubmluZyBvbiBvcHRlZSAob3IgaW4g Z2VuZXJhbCBpbiB0aGUgc2VjdXJlIHdvcmxkKSBpcyBtb3JlIHRydXN0ZWQgdGhlbiBYZW4uDQoN ClJlZ2FyZHMNCkJlcnRyYW5kDQoNCg== From xen-devel-bounces@lists.xenproject.org Fri Jun 19 08:47:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 08:47:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCgE-0007FB-1H; Fri, 19 Jun 2020 08:47:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCgC-0007F5-FI for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 08:47:20 +0000 X-Inumbo-ID: 7c0aea6e-b209-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7c0aea6e-b209-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 08:47:19 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id x6so8831592wrm.13 for ; Fri, 19 Jun 2020 01:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=mqf7gmAtr3fRGXGHHE1sI/oDfkiaWa710N1nUTNPgNk=; b=IXP7Sxq3fT94UeMEreu5WbChuX/mLYcWr/ZOgkGYYm2ydo7fXm8OWNqeojzQb1dzJn 7GxDpM17yfo1cX2RFuWxhUNSabFq4OJVTtUVYxyLqcFpD0gShl8/2BfNCC24gK958Fjy WOM4a6vXmnhE6gFUKto57eOnmVsq0uVW7Dsgxv54THUoCNsIWAurXlxLuAyXqXcK0dcs Qim+qnft9d0qbPuY8HjKxu1m6eJx/858ilQnNXc4qNyIRKSzeebwHrrB6L6xg+vGiwZo t27fU+Eo/qE+ZdnwPyh2xXsTGkIt4bZNzXnqSrZgY8yCfptswHDU2xtZJUEVgxVdkrxJ 9m2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=mqf7gmAtr3fRGXGHHE1sI/oDfkiaWa710N1nUTNPgNk=; b=RyY0fu4jsV+m5yk7GdcUWRoQpD0o7WovevYuO/xsmfwVr6RDAAkvrSCHcrxM+a9VVw YKzitN81BFjAAZn3wi6rgO7E1H/yCPWwzmjFHvb9EGJlrhLX/yk2LSye6p0pZ0H85awX 7LVRWbnkdUwwTziVYqgEzKQInEqFjVDOZJWNq2iokYP9Qqp9hxWXxkchkR0PRTT2DSr+ 9dbRIFaVP4kFLefKlZGrsZhRgeX6xhLFvvGQVW4UAQanstbdyP7TsQm0eqT3Ss0Qfn6Q xDk0sOjOSRsmsOeNE+K+nqBuFxV+JQvcc4tIJYViIy5iwMqHrzJzpFu3ZMrPfy2fJLW8 SaAA== X-Gm-Message-State: AOAM533o0W09AonYeLCZcvnhBumRspFyHnVhFjy+2SxOureTusD57B3u Mnbmb/U9Uqs4SGLmvJsy6kE= X-Google-Smtp-Source: ABdhPJy727/YYKrwWonqAcULw+EW9Bp15F0Kn1PDBg6smd5IBcWTslDnrYv20Lynn15VN7a1HJ/D8w== X-Received: by 2002:adf:a34d:: with SMTP id d13mr2793600wrb.270.1592556439010; Fri, 19 Jun 2020 01:47:19 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id b204sm5406114wmb.12.2020.06.19.01.47.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 01:47:18 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Stefano Stabellini'" , , References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> In-Reply-To: Subject: RE: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address Date: Fri, 19 Jun 2020 09:47:16 +0100 Message-ID: <00a801d64616$3d3a15d0$b7ae4170$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFpSyMwNg/TcnqdYmslaqhk/GonbAGu4tJYAXmKTO2poFINUA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: julien@xen.org, xen-devel@lists.xenproject.org, 'Volodymyr Babchuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Stefano Stabellini > Sent: 18 June 2020 23:27 > To: xadimgnik@gmail.com; paul@xen.org; pdurrant@amazon.com > Cc: Volodymyr Babchuk ; sstabellini@kernel.org; xen- > devel@lists.xenproject.org; paul@xen.org; julien@xen.org > Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address > > Hi Paul, Julien, Volodymyr, > > This is another bug fix that I would like to get in 4.14. It doesn't > look like we need any changes to this patch, assuming that it is > accurate to the spec. > > It would be nice if Volodymyr could provide more info on the spec side, > but honestly I trust his experience on this. > > Paul, are you OK with this going into 4.14? > In principle, yes. It appears, from Julien's comments though, that the commit message may need a little expansion (for the benefit of those mining this code in future). Paul > > > On Sat, 6 Jun 2020, Julien Grall wrote: > > (+Paul) > > > > Hi, > > > > On 18/05/2020 02:53, Volodymyr Babchuk wrote: > > > Trusted Applications use popular approach to determine required size > > > of buffer: client provides a memory reference with the NULL pointer to > > > a buffer. This is so called "Null memory reference". TA updates the > > > > NIT: You use double space after '.' here but all the others use a single > > space. > > > > > reference with the required size and returns it back to client. Then > > > client allocates buffer of needed size and repeats the operation. > > > > > > This behavior is described in TEE Client API Specification, paragraph > > > 3.2.5. Memory References. > > > > From the spec, it is not a clear cut that NULL will always used as fetching > > the required size of an output buffer. In particular, they suggest to refer to > > the protocol. > > > > In your commit message you indirectly point to an example where 0/NULL would > > have a different meaning depending on the flags. This is not explained in the > > TEE Client API Specification. Do you have some pointer I could use to check > > the behavior? > > > > > > > > OP-TEE represents this null memory reference as a TMEM parameter with > > > buf_ptr == NULL. This is the only case when we should allow TMEM > > > buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. > > > > IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer at > > address 0" but with the flag cleared, it would mean "return the size". Am I > > correct? > > > > > > > > Signed-off-by: Volodymyr Babchuk > > The code looks to match your commit message, but I wasn't able to match it > > with the spec. Do you have other pointer I could use to check the behavior? > > > > I assume this wants to be part of Xen 4.14. The change is only for OP-TEE > > which is a tech preview feature. So the risk is very limited. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 08:50:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 08:50:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCim-0007NP-FL; Fri, 19 Jun 2020 08:50:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCik-0007NK-Sa for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 08:49:58 +0000 X-Inumbo-ID: da252614-b209-11ea-bb4b-12813bfff9fa Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.71]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id da252614-b209-11ea-bb4b-12813bfff9fa; Fri, 19 Jun 2020 08:49:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MHuUM1caB3fKi1KJ4cB2DVD7ajRsxVL/D26k4TX4KkE=; b=KZFr9p+njNXF4ds591pz/F2CHkWyipTA/rwW33C6TakgTPAMhOUB75ltXJM+TPhoufhTISHY/7Im8pHySs7Dii241cpMW52OG+SeYV0piOVFP/cGa2OinqxHQGrU7xMgW33WRVnQA0WAHL0UPi6nOMt7W33GOqAhdzd43BaCUXs= Received: from MR2P264CA0085.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:32::25) by HE1PR0801MB1977.eurprd08.prod.outlook.com (2603:10a6:3:4d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Fri, 19 Jun 2020 08:49:55 +0000 Received: from VE1EUR03FT051.eop-EUR03.prod.protection.outlook.com (2603:10a6:500:32:cafe::f6) by MR2P264CA0085.outlook.office365.com (2603:10a6:500:32::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Fri, 19 Jun 2020 08:49:54 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT051.mail.protection.outlook.com (10.152.19.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Fri, 19 Jun 2020 08:49:54 +0000 Received: ("Tessian outbound 09efa10eaf29:v59"); Fri, 19 Jun 2020 08:49:54 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 1cf2a60be84adb22 X-CR-MTA-TID: 64aa7808 Received: from f85a629d5c6a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id EC0ECA7A-E341-4A15-9D4E-460F2F62C3BA.1; Fri, 19 Jun 2020 08:49:48 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f85a629d5c6a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 19 Jun 2020 08:49:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JgvFZLRJ0hWo36N6UkfOlnIP+RMjnR5dz7pVkCkqVjkJz4Y/vD0YJv8kacDe+PA/N5QKV0stKybT9KD2KSidxi0YHMi2wbu7g8bWjV4zmSqUXJ9L4yhvENEZ5yMhTHljH6ID3VsMz3HZmamemz2fHCqdws7g9Zihhou+eTcSA3DawVA8srWAk1SnDwAZNLFA6b2Bk3EUe1Ik9m2sHqUAw9JHZs9wW3d9j8H+2pq0r8Nv91CRxkO7YzAJIz1FOJH91xkZxZOUx3s+864sLW6ql6BAyvvESYA1EGNBdkdfgiVlhUQM1OOqqmY1F4aZVK5/x027QDZdmv43Gr4vAegMdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MHuUM1caB3fKi1KJ4cB2DVD7ajRsxVL/D26k4TX4KkE=; b=hgZaTJUiOgkZO0y3i4vMiLNvyzrk6zcMThnL5pECsJCrAVRu1ld6q86/e6sZg3P8qBzPUXpX4tCgZEq2QF1MdFLll3nDHJ4uw4zeCP7/TGEPNZd0DXtai13eD9zN0ZX1dJPWAIJ6RM0wniGT4253LP483Y93CdykA4NNN7F19WkQRfLnMv+bewE08qMLKJgVBsjIDCQyQvk4mKa0CdXWzuxlwlHAVB44AlwTg2s4+y68JoKujg3WT92z7UsWYHpmccAkVjizFc6a3w2gC1GX2AOoJ0bdZdgtfIFr+Jhx9z/5jT8YGIsJRlIhm7hMNDMJCVDfbDaI4JpK+ElRQ9OXpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MHuUM1caB3fKi1KJ4cB2DVD7ajRsxVL/D26k4TX4KkE=; b=KZFr9p+njNXF4ds591pz/F2CHkWyipTA/rwW33C6TakgTPAMhOUB75ltXJM+TPhoufhTISHY/7Im8pHySs7Dii241cpMW52OG+SeYV0piOVFP/cGa2OinqxHQGrU7xMgW33WRVnQA0WAHL0UPi6nOMt7W33GOqAhdzd43BaCUXs= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3387.eurprd08.prod.outlook.com (2603:10a6:10:45::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 19 Jun 2020 08:49:48 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 08:49:47 +0000 From: Bertrand Marquis To: Stefano Stabellini Subject: Re: [Tee-dev] TEE with XEN Thread-Topic: [Tee-dev] TEE with XEN Thread-Index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQAw/zsAAIeJWwAACMx1AAAWGKGA Date: Fri, 19 Jun 2020 08:49:47 +0000 Message-ID: References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: fb736af4-d2f9-4055-d2b6-08d8142dbcc6 x-ms-traffictypediagnostic: DB7PR08MB3387:|HE1PR0801MB1977: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0439571D1D X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 3x/ItV9aWpRJ14/UdOJ8puNH/xQMGLsFQqS0gNnBru2j9d+tGBSyZlLfmuLzu3FhkBg53t//AIyT0NpZLTAFR3z0M7cwL/8C9lqbOmvJtpCWXLcwH8MydMzTNNsTre0+P9SqpaCB+ZdWYkf0EeyNkKEW9plQ7S0Q6I0rizOW7Nyj12Ci/+enn+mcg8+d9GmKFR31rVhjSw2QQA4/az0MdfmbhnvNoxeExMsnQ3EV5SqbOwRNMvCae+dk6FHf6PyNZUp6ntA80eKjYdDXPGyB1qhplv/2D/KbJXKofR4rNpo9Ae14wUzrYZQSEPYqfaQRy31HWI0AfeoDGUFB3GZV0Q== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(39860400002)(366004)(346002)(83380400001)(6512007)(86362001)(8936002)(6486002)(478600001)(5660300002)(8676002)(2906002)(36756003)(4326008)(2616005)(186003)(6916009)(66446008)(64756008)(54906003)(66476007)(53546011)(33656002)(6506007)(76116006)(91956017)(66946007)(316002)(66556008)(71200400001)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: XGtFa/0evpMBP0H8vttHao4M4D/7O3+w6CmhXnWHOLoPMkfyAxLhlITRhj9AG7Wyw/S4jXAO8uMANBznoQFcYr5Z7aGzzsavzdjj6Bbb97KEGIGMJsk6p5v+HtSDh6zHPgLl+/66SHeA2MJTN3khIa/91RgWFp13YtK3o3del3oU2Qywhju2EhkpdIPP+ubBV7Ud+rbuLsXRnWeB5/+vg5N8ezoGAphemAPZtOCZhj2/M3oUysG2VRBqkHmfP2M7pmOV219XkRPL4H50FNw/ZzLz2wl76M4V+F1X3Jz9x9JUVoQdf+4BYi+s9wvHfZNsVKIxJDG9Eg9EfOFqMDjKDYXuB5b0IQ4YH3Ku1RJLC7VtjcTUsv00fL94f76h3FfuDHd1/yqkK/CZ+VSSMUSi2zFbEqfskeKvC9fOkuWwO9Pc3VTcFTqlCH/c3E7tzI5H2t5pGORa4dchpE5FFB820qupAP7xVNy53yMSQArb328k/3QGSdcPoYpJpU2D2/KH x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <330E7F673DA9384F837BC46E29168CD2@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3387 Original-Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT051.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(346002)(376002)(46966005)(33656002)(8936002)(36756003)(6486002)(8676002)(83380400001)(54906003)(6862004)(86362001)(4326008)(478600001)(82310400002)(316002)(26005)(2616005)(186003)(5660300002)(6506007)(53546011)(81166007)(47076004)(336012)(70206006)(70586007)(356005)(36906005)(2906002)(6512007)(82740400003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 421f00a0-b84d-47e1-ed92-08d8142db8d1 X-Forefront-PRVS: 0439571D1D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 49UqTfo6mWctHLBhipRAi0OTLG3N0nBVJat3Ok4pJrFH2eAIhlpyFzcfw7BiPSmcOwP0hA3r4PU8sB30GYOWxc5f+q4YpxszF5Sf4fJyR2straJ19+C/X/GHIdLMXXZ2fJN7X16/XakuV3XcihIpNvhtxVVsyNN+EfXP2VrWbMCDKw+tq8v2yPRfdaGi54fjCdfDla1QjifSW7mXJ+ve/5xDcWWsLl28LdxJU68FZRW1sua+iLkWSbNEJphrhKKOjIZCsn1Dw2HO1WKjAnDmobFEixio8+Un8G2TXlQ3oKzoVHZ6HiBkJjzEqd1nR77yKyZwey+D0t5dGFqLyG3wYOUmpKFvi/ZLBw6juO2j+bpxPfsws2srE921K31rdP4yQap4/mh8QX1skZgswA499Q== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2020 08:49:54.5006 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fb736af4-d2f9-4055-d2b6-08d8142dbcc6 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1977 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peng Fan , Julien Grall , Oleksandr Andrushchenko , Volodymyr Babchuk , "tee-dev@lists.linaro.org" , Xen-devel , nd , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gMTggSnVuIDIwMjAsIGF0IDIzOjE3LCBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFi ZWxsaW5pQGtlcm5lbC5vcmc+IHdyb3RlOg0KPiANCj4gT24gVGh1LCAxOCBKdW4gMjAyMCwgSnVs aWVuIEdyYWxsIHdyb3RlOg0KPj4gK0JlcnRyYW5kIGFuZCBTdGVmYW5vDQo+IA0KPiBUaGFua3Mg Zm9yIENDJ2luZyBtZQ0KPiANCj4gDQo+PiBPbiAxNi8wNi8yMDIwIDAyOjI0LCBWb2xvZHlteXIg QmFiY2h1ayB3cm90ZToNCj4+PiBIaSBQZW5nLA0KPj4+IA0KPj4+IE9uIE1vbiwgMTUgSnVuIDIw MjAgYXQgMDU6MDcsIFBlbmcgRmFuIDxwZW5nLmZhbkBueHAuY29tPiB3cm90ZToNCj4+Pj4gDQo+ Pj4+IEhpIEFsbCwNCj4+Pj4gDQo+Pj4+IFdoaWxlIGVuYWJsaW5nIHRydXN0eSBvcyB3aXRoIHhl biwgSSB0b29rIHNhbWUgYXBwcm9hY2ggYXMgT1AtVEVFLA0KPj4+PiB3aXRoIE9QLVRFRSBydW5u aW5nIGluIHNlY3VyZSB3b3JsZC4gQnV0IEkgYW0gYWxzbyB0aGlua2luZyB0aGlzIG1pZ2h0DQo+ Pj4+IGludHJvZHVjZSBwb3RlbnRpYWwgaXNzdWUgaXMgdGhhdCBzZWN1cmUgd29ybGQgT1MgY29t bXVuaWNhdGUgd2l0aCBEb21VLg0KPj4+PiBJZiB0aGVyZSBhcmUgc29tZSBtaXNiZWhhdmlvciBp biBzZWN1cmUgd29ybGQgT1MsIGl0IG1pZ2h0IGxldCBYRU4NCj4+Pj4gaHlwZXJ2aXNvciBub3Qg d29yayBwcm9wZXIuDQo+Pj4+IA0KPj4+PiBJbiBteSBzZXR1cCwgdHJ1c3R5IG9zIHNvbWV0aW1l cyBwYW5pYyBpbiBzZWN1cmUgd29ybGQsIHhlbiB3aWxsIG5vdCBhYmxlDQo+Pj4+IHRvIGNvbnRy b2wgdGhlIHBhbmljIGNvcmUgYW55bW9yZS4NCj4+IA0KPj4gTWF5IEkgYXNrIGluIHdoaWNoIGNh c2UgVHJ1c3R5IGlzIHBhbmlja2luZz8NCj4+IA0KPj4+PiANCj4+Pj4gU28gSSBhbSB0aGlua2lu ZyB3aGV0aGVyIHdlIG5lZWQgdG8gZW11bGF0aW5nIHNlY3VyZSB3b3JsZCBpbiBhIFhFTiBWTQ0K Pj4+PiB3aGljaCBpcyB0aGUgVk0gcnVubmluZyBEb21VLiBKdXN0IGxpa2Ugd2hhdCBBQ1JOIGRp ZCB0byBydW4gdHJ1c3R5DQo+Pj4+IG9zLg0KPj4+IA0KPj4+IFdlbGwsIGl0IGRlcGVuZHMgb24g d2hvbSB5b3UgYXJlIHRydXN0aW5nIG1vcmUuIEJvdGggWEVOIGFuZCBURUUgYXJlIG1pbmltYWwN Cj4+PiBPUyBpbXBsZW1lbnRhdGlvbnMgd2l0aCBhaW0gYXQgc2VjdXJpdHkuIEknbSBzcGVha2lu ZyBhYm91dCBnZW5lcmljIFRFRSBPUywNCj4+PiBub3QNCj4+PiBhYm91dCBwYXJ0aWN1bGFyIE9T IGxpa2UgT1AtVEVFIG9yIFRydXN0eS4gUHJvYmxlbSBpcyB0aGF0LCBpZiBURUUgaXMNCj4+PiBy dW5uaW5nIGluc2lkZQ0KPj4+IFZNLCBpdCB3aWxsIGJlIHN1c2NlcHRpYmxlIHRvIGEgaHlwZXJ2 aXNvciBtaXNiZWhhdmlvdXIuIFlvdSBuZWVkIHRvDQo+Pj4gdW5kZXJzdGFuZA0KPj4+IHRoYXQg WGVuIGFuZCBwcml2aWxlZ2VkIGRvbWFpbiAoZG9tMCwgbW9zdGx5KSBjYW4gYWNjZXNzIG1lbW9y eSBvZiBhbnkNCj4+PiBndWVzdC4NCj4+PiBBdCBsZWFzdCwgaW4gZGVmYXVsdCBjb25maWd1cmF0 aW9uLiBUaGVyZSBhcmUgbWVhbnMgdG8gaGFyZGVuIHRoaXMNCj4+PiBzZXR1cC4gQnV0IGFueXdh eXMsDQo+Pj4gWGVuIGNhbid0IGJlIHN0b3BwZWQgZnJvbSByZWFkaW5nIFRFRSdzIHNlY3JldHMu DQo+PiANCj4+IElJUkMsIHdlIGRpc2N1c3NlZCB0aGlzIGFwcHJvYWNoIGZvciBPUC1URUUgaW4g dGhlIHBhc3QuIFRoZXJlIHdhcyBvdGhlcg0KPj4gcG90ZW50aWFsIHBpdGZhbGxzIHdpdGggaXQu IEZvciBpbnN0YW5jZSwgeW91IHdvdWxkbid0IGJlIGFibGUgdG8gZGlyZWN0bHkNCj4+IGFjY2Vz cyBhbnkgc2VjdXJlIGRldmljZSBmcm9tIHRoYXQgZ3Vlc3QgKGl0IGlzIHJ1bm5pbmcgaW4gbm9u LXNlY3VyZSB3b3JsZCkuDQo+IA0KPiBHaXZlbiB0aGF0IFNlY3VyZSBXb3JsZCBoYXMgYWNjZXNz IHRvIE5vcm1hbCBXb3JsZCBidXQgbm90IHZpY2UgdmVyc2EsDQo+IGl0IGlzIG1vcmUgbmF0dXJh bCB0byBydW4gVHJ1c3R5IGluIG9uZSBvZiB0aGUgU2VjdXJlIGV4ZWN1dGlvbiBsZXZlbHMuDQo+ IFRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IFRydXN0eSBoYXMgaGlnaGVyIHByaXZpbGVnZSwgdGh1 cyBpdCBpcyBtb3JlDQo+ICJ0cnVzdGVkIiB0aGFuIGFueXRoaW5nIHJ1bm5pbmcgaW4gTm9ybWFs IFdvcmxkLCBpbmNsdWRpbmcgWGVuLg0KPiANCj4gT2YgY291cnNlIG5vIGNsaWVudCBzaG91bGQg YmUgYWJsZSB0byBjcmFzaCBUcnVzdHksIHNvIHRoZSByZWFsaXR5DQo+IHNvbWV0aW1lcyBjYW4g YmUgdmVyeSBkaWZmZXJlbnQgZnJvbSB0aGUgdGhlb3J5IDotKQ0KPiANCj4gSWYgSSB3ZXJlIHlv dSwgSSB3b3VsZCBjb25zaWRlciBydW5uaW5nIHRoZSBURUUgImluc2lkZSIgdGhlIFZNIG9ubHkg aWYNCj4gdGhlIHNlcnZpY2UgdGhhdCB0aGUgVEVFIHByb3ZpZGVzIGlzIHN0cm9uZ2x5IGNvdXBs ZWQgd2l0aCB0aGUgVk0gYW5kDQo+IGRvZXNuJ3QgYWN0dWFsbHkgbmVlZCBhIGhpZ2ggbGV2ZWwg b2YgcHJpdmlsZWdlIHRvIGZ1bmN0aW9uIChpLmUuDQo+IGRvZXNuJ3QgYWNjZXNzIHNlY3VyZSBk ZXZpY2VzIG9yIGF0IGxlYXN0IG5vdCBvZnRlbi4pDQo+IA0KDQpJIGNvdWxkIHNlZSBzb21lIHNj ZW5hcmlvcyB3aGVyZSB0aGlzIHdvdWxkIG1ha2Ugc2Vuc2UgaWYgeW91IHRydXN0IG9uZSBWTSBt b3JlIHRoZW4gYW4gb3RoZXIuDQpCdXQgdGhpcyBmYWxscyBpbnRvIGEgbW9kZWwgb2Yg4oCcdmly dHVhbGl6aW5n4oCdIG9wdGVlIHVzaW5nIGEgVk0gd2hlcmUgZnJvbSB0aGUgc3lzdGVtIHBvaW50 IG9mIHZpZXcgYW55IHVzYWdlIG9mIHRoaXMgVk0gZnJvbSB0aGUgZnVuY3Rpb25hbGl0eSBjb3Vs ZCBub3QgYmUgbW9yZSB0cnVzdGVkIHRoZW4gWGVuIEFuZCB0aGUgVk0gcHJvdmlkaW5nIHRoZSBz ZXJ2aWNlLg0KDQo+IA0KPj4gRGVwZW5kaW5nIG9uIHdoZXRoZXIgeW91IGNhbiBtb2RpZnkgVHJ1 c3R5IE9TLCBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBtYWtlDQo+PiBpdHZpcnR1YWxpemF0aW9u IGF3YXJlIGFzIE9QLVRFRSBkaWQuIFRoZSBjb3JlIHdvdWxkIG5lZWQgdG8gYmUgcmVzaWxpZW50 IGFuZA0KPj4gdGhlIHBhbmljIG9ubHkgYWZmZWN0IGEgZ2l2ZW4gY2xpZW50Lg0KPiANCj4gVGhp cyB3b3VsZCBtb3N0IHByb2JhYmx5IGJlIHRoZSBiZXN0IGNvbXByb21pc2UuDQoNCkFncmVlLg0K DQpCZXJ0cmFuZA0KDQoNCg== From xen-devel-bounces@lists.xenproject.org Fri Jun 19 08:52:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 08:52:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCkv-00089Q-WD; Fri, 19 Jun 2020 08:52:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCku-00089K-Vf for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 08:52:13 +0000 X-Inumbo-ID: 2a56b167-b20a-11ea-bb4c-12813bfff9fa Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [40.107.20.45]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2a56b167-b20a-11ea-bb4c-12813bfff9fa; Fri, 19 Jun 2020 08:52:12 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=csTtp/tSfpeztOLEiikysewSDABz1mE8vL/QL8JiaudyqKn22OyeenanhSHfRSSGohaFJXXj76CA3pI59cN+yo5LUZjN2MPGMyEM30J+oiI2umVEjjlttdDnhD0GFED8HZTy+3ocGdSXuDtJaTLDrp5+9P0oGUEoIqCkTHRPUi5/eWlqnm7CqUzJwK/Sau9rlxW3AAf/JO+u6X6nRlLRldUrd7Pt9VjVVs0j5BmctQrsxj6c26qHLEcfzEJ+9FDBe0zX0nHLUkfvZYEVjOFhPT1aalxeDxLhEVKQwF2nFQvgJU1L7Kj6jOMFrE3Xaft0psLk9KKSb4pNK6cUmkQQhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TTUkD1W9y0FK0blpskNf23+lGdOQ8an9T/nu/OEc0vk=; b=YNlLZeqgfbYAiodr/QUzY/ECqdxByU5kp4UTnebbdtfn9H/h2ymh0jSSZ1k2iHt/yA/fsB7m7LWk1Sia5aCU1AeT2wzsXlUevw2hEp0oiPgAKV+bqQXG9tFtkUA+h71h3urRteKnI8vGxPPJbcA1gXIcBrdJ7X3CfrEPpyyMk7ZWhctNnA1i/GQ1iI5Xf5CRUC7sZktvtWifi5DZ/kggO3qP1no9DysFL7FCHT6BZKhtlGezLlSROvphcaCm5xLPq9/dRRmZbWVyu7ZYhE6nOvQiuMwB5CnRKaEDdyFOC4Of5X4a4V69NRsyaGc+Rz0ZZ733+lHuanPTon8ffHQH/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TTUkD1W9y0FK0blpskNf23+lGdOQ8an9T/nu/OEc0vk=; b=nPVBol3ue+lU5eF1SsDdiCO7bWOaDoXjxijSkQsL+uBeojbNeJ2NhlXD18k/RWSua1gWcvezd5uljDt1l7iV9k2+5w4ZLnRULt83zCGDDXgi8RRl8ilycBXRG83VXs05KklU3RtPywg88aDmBqEWMdcyIIgXV4WYgIUmjnw0IlA= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2840.eurprd04.prod.outlook.com (2603:10a6:4:97::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Fri, 19 Jun 2020 08:52:11 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3088.028; Fri, 19 Jun 2020 08:52:10 +0000 From: Peng Fan To: Bertrand Marquis , Julien Grall Subject: RE: [Tee-dev] TEE with XEN Thread-Topic: [Tee-dev] TEE with XEN Thread-Index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQAw/zsAAIeJWwAAHsEHgAAAD3aw Date: Fri, 19 Jun 2020 08:52:10 +0000 Message-ID: References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> <68572FBC-8AE3-44A4-A815-1A9A7FFFA098@arm.com> In-Reply-To: <68572FBC-8AE3-44A4-A815-1A9A7FFFA098@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 09a7846f-70db-41a7-6151-08d8142e0e04 x-ms-traffictypediagnostic: DB6PR0402MB2840: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6N5J+TgUFh8IDlFOlnkPnJtaCyquNlRTeXqXu6MJRK9ORUoRqjTZEW3iFsNP3ygeVtbqLgk0CUk8lH7+f1wIECtBEdptnpks5IY3oVhWa0rNP4nlcogTpGFGn0Cb36ZPVnH967WE+Bvc5Ldxp3utr+WAu9cAsYSJq/2XQaolQMsevbD11lfYtzs9EYID7AWw22ZGf65siR8TFSy+lV6aOQ7X5N8ssVJibEaQCm4jkooNnF9LaoB8WfstlmE92SBZJPgOBa111734FjJuaP9qc1mvIWvu97npm+aPYEfjaRHBZCgRn8DRs0E+unDIXKDd0C0uZtn23gS7YMFiYJGAdA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(376002)(39860400002)(346002)(396003)(4326008)(478600001)(83380400001)(44832011)(7416002)(5660300002)(33656002)(9686003)(66946007)(76116006)(71200400001)(66556008)(110136005)(86362001)(54906003)(64756008)(52536014)(55016002)(66476007)(66446008)(53546011)(7696005)(8676002)(186003)(2906002)(8936002)(26005)(6506007)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: h3UhwwoiItmrVInT91jcCJEnDU84KMK04tLkn5ymCJ5whABhRKhD0T0UQ9kKHh2bNtnIVBqyKnj22ThO3f7XUMoi7+/gRV3YrRRXnxBkHK/qTbPQA4VUdhNVKe6ZQSoPA5Ltr5n3GU3U+YqbITH2CUU88FfhN1CuGcuwQKUeZs28EdSnr+5cOZAzX7+UpI0sz68PcmUH3SVWXRSpuLwuEHLT9USrqBqys9Dbk1r3w+Eahk1FBckxS8ZvCaSo1EwKhR8ZQYs2N1Mc2rtZu0fTiG170rh04Uim7PHIHiVBotm/qjUDEC1te+F1VwI/nUxDzllFyYBDZ5sVy/Q9pwImdU9fumukBAiCjQI89LB8Vq28NwMVbA0carSdxz/2FNH6Ae7Lkg4wQ2PHPZ2IsuTeYtY2KedIqaMjgIfkAZiZPr7pPL8SXtxZ+i6Xg2BMVhWtZ8358YcW9YQXmSvrfOO35WOR62z89P0TVVHw0777sgI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 09a7846f-70db-41a7-6151-08d8142e0e04 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 08:52:10.8694 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: G4EJQfESyZQZfmJ7QojJx8fBsysSX2UdnSHUjWG1qPZQ4Lh+i36jXg6P72/fERzZCFABAtyVQN6rtZF7WafUjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2840 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Oleksandr Andrushchenko , Volodymyr Babchuk , "tee-dev@lists.linaro.org" , Xen-devel , nd , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGkgQmVydHJhbmQsDQoNCj4gU3ViamVjdDogUmU6IFtUZWUtZGV2XSBURUUgd2l0aCBYRU4NCj4g DQo+IEhpLA0KPiANCj4gPiBPbiAxOCBKdW4gMjAyMCwgYXQgMTk6MDUsIEp1bGllbiBHcmFsbCA8 anVsaWVuQHhlbi5vcmc+IHdyb3RlOg0KPiA+DQo+ID4gK0JlcnRyYW5kIGFuZCBTdGVmYW5vDQo+ ID4NCj4gPiBPbiAxNi8wNi8yMDIwIDAyOjI0LCBWb2xvZHlteXIgQmFiY2h1ayB3cm90ZToNCj4g Pj4gSGkgUGVuZywNCj4gPj4gT24gTW9uLCAxNSBKdW4gMjAyMCBhdCAwNTowNywgUGVuZyBGYW4g PHBlbmcuZmFuQG54cC5jb20+IHdyb3RlOg0KPiA+Pj4NCj4gPj4+IEhpIEFsbCwNCj4gPj4+DQo+ ID4+PiBXaGlsZSBlbmFibGluZyB0cnVzdHkgb3Mgd2l0aCB4ZW4sIEkgdG9vayBzYW1lIGFwcHJv YWNoIGFzIE9QLVRFRSwNCj4gPj4+IHdpdGggT1AtVEVFIHJ1bm5pbmcgaW4gc2VjdXJlIHdvcmxk LiBCdXQgSSBhbSBhbHNvIHRoaW5raW5nIHRoaXMNCj4gPj4+IG1pZ2h0IGludHJvZHVjZSBwb3Rl bnRpYWwgaXNzdWUgaXMgdGhhdCBzZWN1cmUgd29ybGQgT1MgY29tbXVuaWNhdGUgd2l0aA0KPiBE b21VLg0KPiA+Pj4gSWYgdGhlcmUgYXJlIHNvbWUgbWlzYmVoYXZpb3IgaW4gc2VjdXJlIHdvcmxk IE9TLCBpdCBtaWdodCBsZXQgWEVODQo+ID4+PiBoeXBlcnZpc29yIG5vdCB3b3JrIHByb3Blci4N Cj4gPj4+DQo+ID4+PiBJbiBteSBzZXR1cCwgdHJ1c3R5IG9zIHNvbWV0aW1lcyBwYW5pYyBpbiBz ZWN1cmUgd29ybGQsIHhlbiB3aWxsIG5vdA0KPiA+Pj4gYWJsZSB0byBjb250cm9sIHRoZSBwYW5p YyBjb3JlIGFueW1vcmUuDQo+ID4NCj4gPiBNYXkgSSBhc2sgaW4gd2hpY2ggY2FzZSBUcnVzdHkg aXMgcGFuaWNraW5nPw0KPiANCj4gSW4gYW55IGNhc2UsIG9wdGVlIHNob3VsZCBwcm90ZWN0IGl0 c2VsZiBhZ2FpbnN0IHRoaXMgYW5kIGl0IHNob3VsZCBiZQ0KPiBjb25zaWRlcmVkIHRoYXQgb3B0 ZWUgaXMgbW9yZSBwcml2aWxlZGdlZCB0aGVuIFhlbi4NCj4gU28gaWYgb3B0ZWUgaXMgY3Jhc2hp bmcgd2UgY2Fubm90IGV4cGVjdCB0aGF0IFhlbiBjYW4gcmVjb3ZlciBvciBmaXggaXQuDQo+IA0K PiBJIHdvdWxkIG1vcmUgY29uc2lkZXIgdGhpcyBhcyBhIGJ1ZyB0aGF0IG9wdGVlIG5lZWRzIHRv IGJlIHJvYnVzdCBhZ2FpbnN0Lg0KDQpvay4gSSBhbSBub3QgdXNpbmcgT1AtVEVFLCBjdXJyZW50 bHkgSSB1c2UgZ29vZ2xlIHRydXN0eSBPUy4NCg0KSSBoYXZlIHR3byBPUywgRG9tMCBsaW51eCAr IERvbVUgYW5kcm9pZCBhdXRvLg0KDQpEb21VIGFuZHJvaWQgYXV0byBuZWVkcyB0cnVzdHkgT1Ms IERvbTAgTGludXggbm90IG5lZWQgdGhhdC4NCg0KSSBub3Qgd2FubmEgdHJ1c3R5IE9TIGZvciBE b21VIGNvdWxkIGJyaW5nIGFueSBkZXRlY3QgdG8gRG9tMCBvciB4ZW4uDQoNCk9uZSBtb3JlIGNh c2UgaXMgaWYgZG9tMCBsaW51eCBuZWVkcyBPUC1URUUsIERvbVUgbmVlZHMgZ29vZ2xlIHRydXN0 eSwNCmhvdyB3ZSBoYW5kbGUgdGhpcyBpbiBvbmUgU29DPw0KDQo+IA0KPiA+DQo+ID4+Pg0KPiA+ Pj4gU28gSSBhbSB0aGlua2luZyB3aGV0aGVyIHdlIG5lZWQgdG8gZW11bGF0aW5nIHNlY3VyZSB3 b3JsZCBpbiBhIFhFTg0KPiA+Pj4gVk0gd2hpY2ggaXMgdGhlIFZNIHJ1bm5pbmcgRG9tVS4gSnVz dCBsaWtlIHdoYXQgQUNSTiBkaWQgdG8gcnVuDQo+ID4+PiB0cnVzdHkgb3MuDQo+ID4+IFdlbGws IGl0IGRlcGVuZHMgb24gd2hvbSB5b3UgYXJlIHRydXN0aW5nIG1vcmUuIEJvdGggWEVOIGFuZCBU RUUgYXJlDQo+ID4+IG1pbmltYWwgT1MgaW1wbGVtZW50YXRpb25zIHdpdGggYWltIGF0IHNlY3Vy aXR5LiBJJ20gc3BlYWtpbmcgYWJvdXQNCj4gPj4gZ2VuZXJpYyBURUUgT1MsIG5vdCBhYm91dCBw YXJ0aWN1bGFyIE9TIGxpa2UgT1AtVEVFIG9yIFRydXN0eS4NCj4gPj4gUHJvYmxlbSBpcyB0aGF0 LCBpZiBURUUgaXMgcnVubmluZyBpbnNpZGUgVk0sIGl0IHdpbGwgYmUgc3VzY2VwdGlibGUNCj4g Pj4gdG8gYSBoeXBlcnZpc29yIG1pc2JlaGF2aW91ci4gWW91IG5lZWQgdG8gdW5kZXJzdGFuZCB0 aGF0IFhlbiBhbmQNCj4gPj4gcHJpdmlsZWdlZCBkb21haW4gKGRvbTAsIG1vc3RseSkgY2FuIGFj Y2VzcyBtZW1vcnkgb2YgYW55IGd1ZXN0Lg0KPiA+PiBBdCBsZWFzdCwgaW4gZGVmYXVsdCBjb25m aWd1cmF0aW9uLiBUaGVyZSBhcmUgbWVhbnMgdG8gaGFyZGVuIHRoaXMNCj4gPj4gc2V0dXAuIEJ1 dCBhbnl3YXlzLCBYZW4gY2FuJ3QgYmUgc3RvcHBlZCBmcm9tIHJlYWRpbmcgVEVFJ3Mgc2VjcmV0 cy4NCj4gPg0KPiA+IElJUkMsIHdlIGRpc2N1c3NlZCB0aGlzIGFwcHJvYWNoIGZvciBPUC1URUUg aW4gdGhlIHBhc3QuIFRoZXJlIHdhcyBvdGhlcg0KPiBwb3RlbnRpYWwgcGl0ZmFsbHMgd2l0aCBp dC4gRm9yIGluc3RhbmNlLCB5b3Ugd291bGRuJ3QgYmUgYWJsZSB0byBkaXJlY3RseSBhY2Nlc3MN Cj4gYW55IHNlY3VyZSBkZXZpY2UgZnJvbSB0aGF0IGd1ZXN0IChpdCBpcyBydW5uaW5nIGluIG5v bi1zZWN1cmUgd29ybGQpLg0KPiA+DQo+ID4gVGhlcmUgYXJlIGFsc28gaXNzdWVzIGluIHRlcm0g b2YgbGF0ZW5jeSBhcyB5b3UgbWF5IGhhdmUgdGhlIGZvbGxvd2luZw0KPiBtb2RlbDoNCj4gPg0K PiA+IGRvbVUgLT4gWGVuIC0+IGRvbVUgVEVFIC0+IChYZW4gLT4gaG9zdCBURUUgLT4gWGVuIC0+ IGRvbVUgVEVFKSAtPiBYZW4gLT4NCj4gZG9tVS4NCj4gPg0KPiA+IFRoZSBiaXQgaW4gKCkgaXMg aWYgeW91IHJlcXVpcmUgdG8gY2FsbCB0aGUgaG9zdCBURUUuDQo+ID4NCj4gPiBPbmUgcG9zc2li aWxpdHkgd291bGQgYmUgdG8gdXNlIFNlY3VyZS1FTDIgZm9yIHlvdXIgVHJ1c3R5IE9TLiBCdXQg SSBkb24ndA0KPiBrbm93IHdoZXRoZXIgeW91ciBwbGF0Zm9ybSBzdXBwb3J0cyBpdC4NCj4gPg0K PiA+IERlcGVuZGluZyBvbiB3aGV0aGVyIHlvdSBjYW4gbW9kaWZ5IFRydXN0eSBPUywgYWx0ZXJu YXRpdmUgd291bGQgYmUgdG8NCj4gbWFrZSBpdHZpcnR1YWxpemF0aW9uIGF3YXJlIGFzIE9QLVRF RSBkaWQuIFRoZSBjb3JlIHdvdWxkIG5lZWQgdG8gYmUNCj4gcmVzaWxpZW50IGFuZCB0aGUgcGFu aWMgb25seSBhZmZlY3QgYSBnaXZlbiBjbGllbnQuDQo+IA0KPiBJIGRvIG5vdCBoYXZlIHJpZ2h0 IGEgY2xlYXIgaWRlYSBvZiB3aGF0IGlzIHRoZSBzdGF0dXMgb2Ygb3B0ZWUgYW5kIHhlbiBidXQg aW4NCj4gdGhlb3J5IEkgd291bGQgc2VlIDIgcG9zc2libGUgd2F5cyB0byBoYW5kbGUgdGhpczoN Cj4gLSB3aXRob3V0IG9wdGVlIG1vZGlmaWNhdGlvbiwgc29tZXRoaW5nIGluIGEgZ3Vlc3QgKERv bTAgb3IgYW4gb3RoZXINCj4gcHJpdmlsZWRnZWQgb25lKSBuZWVkcyB0byBoYXZlIGFjY2VzcyB0 byBvcHRlZSBhbmQgZW11bGF0ZSBvcHRlZSBhY2Nlc3MgZm9yDQo+IG90aGVycy4NCj4gLSB3aXRo IG9wdGVlIG1vZGlmaWNhdGlvbnMsIG9wdGVlIG5lZWRzIHRvIGhhdmUgYSBjb25jZXB0IG9mIGNs aWVudCBhbmQgWGVuDQo+IHdvdWxkIG5lZWQgdG8gcGFzc3Rocm91Z2ggb3B0ZWUgcmVxdWVzdHMg YnV0IGJlaW5nIHJlc3BvbnNpYmxlIG9mIGFkZGluZyBhDQo+IOKAnGNsaWVudOKAnSBpZGVudGlm aWVyLiBNYXliZSBhbHNvIGluZm9ybWluZyBPcHRlZSB3aGVuIGEgbmV3IGNsaWVudCBpcw0KPiBj cmVhdGVkL3JlbW92ZWQuDQo+IA0KPiBUaGUgc2Vjb25kIHNjZW5hcmlvIGNvdWxkIHRoZW4gYmUg c29tZWhvdyBzcGxpdHRlZCBpbiB0aGUgcHJldmlvdXMgb25lIGZyb20NCj4gSnVsaWVuIGlmIHNv bWUgcGFydHMgd291bGQgbmVlZCB0byBiZSBlbXVsYXRlZCBzb21ld2hlcmUgaW4gc29tZSBraW5k IG9mDQo+IGNvbWJpbmF0aW9uIG9mIHRoZSAyIG1vZGVscy4NCj4gDQo+IEluIGFueSBjYXNlIGkg d291bGQgYWx3YXlzIGNvbnNpZGVyIHRoYXQgYW55dGhpbmcgcnVubmluZyBvbiBvcHRlZSAob3Ig aW4NCj4gZ2VuZXJhbCBpbiB0aGUgc2VjdXJlIHdvcmxkKSBpcyBtb3JlIHRydXN0ZWQgdGhlbiBY ZW4uDQoNCk9rLCB0aGlzIG1lYW5zIG9wdGVlIHJ1bnMgb24gYWxsIGNvcmVzIGluIHNlY3VyZSB3 b3JsZCwgYnV0IHRoaXMgd291bGQgbm90DQp3b3JrIHdoZW4gd2UgbmVlZCB0byBzdXBwb3J0IG11 bHRpcGxlIE9TZXMgd2l0aCB0aGVpciBvd24gVEVFLg0KDQpSZWdhcmRzLA0KUGVuZy4NCg0KPiAN Cj4gUmVnYXJkcw0KPiBCZXJ0cmFuZA0KDQo= From xen-devel-bounces@lists.xenproject.org Fri Jun 19 08:53:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 08:53:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCm2-0008Fi-Am; Fri, 19 Jun 2020 08:53:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCm1-0008Fb-38 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 08:53:21 +0000 X-Inumbo-ID: 5310d924-b20a-11ea-bb4d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5310d924-b20a-11ea-bb4d-12813bfff9fa; Fri, 19 Jun 2020 08:53:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VZO0uOh6nVnPqft8aQEp9HP5uX28S4DIE8weJ4CUQUA=; b=2i0U8szgZhoRxu0WIRBiCbz44/ Ul0RLetBv9hwMTbbi838WutfAay1ZVL99NTK9f4dlj0v9ph3z452c7S03MPeEegH3G0OnsLUGR89+ ggnVV5MXx3pLF/MoZ+ot3mVnyOoFQ3NEm+A5wgbqeYDQpzMrqVv6ogAlLus67GCe73Pk=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmClz-0002VI-Na; Fri, 19 Jun 2020 08:53:19 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jmClz-0005lZ-Fo; Fri, 19 Jun 2020 08:53:19 +0000 Subject: Re: [PATCH] optee: immediately free buffers that are released by OP-TEE To: Stefano Stabellini References: <20200506014246.3397490-1-volodymyr_babchuk@epam.com> <51b8c855-5e94-2829-a703-d43c84948120@xen.org> From: Julien Grall Message-ID: <57e24ddd-5ba1-eea9-2961-d7dc9ce22688@xen.org> Date: Fri, 19 Jun 2020 09:53:16 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "tee-dev@lists.linaro.org" , Andrew Cooper , Volodymyr Babchuk , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18/06/2020 23:20, Stefano Stabellini wrote: > Hi Paul, Julien, > > Volodymyr hasn't come back with an update to this patch, but I think it > is good enough as-is as a bug fix and I would rather have it in its > current form in 4.14 than not having it at all leaving the bug unfixed. > > I think Julien agrees. The approach is okayish but this is not ideal at least without any explanation why ignoring a potential bug is fine. I could settle with an expanded commit message for now. Therefore, I don't feel I should provide my Ack on this approach. That said, I am not the maintainers of this code. You are free to Ack and commit it. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 19 08:58:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 08:58:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCrG-0008RL-V9; Fri, 19 Jun 2020 08:58:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCrF-0008RG-UF for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 08:58:45 +0000 X-Inumbo-ID: 14617d5e-b20b-11ea-b7bb-bc764e2007e4 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe02::626]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 14617d5e-b20b-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 08:58:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9mMM7QI/Wb+lHb3XyzTsLYOckaGqklUKgi8N/ybm6i0=; b=LYnFy7hwdyGNgDFC/c88cNozHyarpsnJ5QeCAfbUXmFBAlAO/8eid8Le38rSGM1pBQ4vWZHi6P3es/v+bXAi+6WqjmbV+jmkjckcTbM0kkA78REL7eeiEw2yFNwcEpPHIlZX0kFA3Nq8LnaxXGEgnJpyhKRVd8AhR1uIl8TxuNs= Received: from DB6PR0501CA0017.eurprd05.prod.outlook.com (2603:10a6:4:8f::27) by VI1PR08MB2894.eurprd08.prod.outlook.com (2603:10a6:802:1c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Fri, 19 Jun 2020 08:58:42 +0000 Received: from DB5EUR03FT055.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:8f:cafe::55) by DB6PR0501CA0017.outlook.office365.com (2603:10a6:4:8f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Fri, 19 Jun 2020 08:58:42 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT055.mail.protection.outlook.com (10.152.21.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Fri, 19 Jun 2020 08:58:42 +0000 Received: ("Tessian outbound 68e1a9769289:v59"); Fri, 19 Jun 2020 08:58:42 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 199589257879c1ff X-CR-MTA-TID: 64aa7808 Received: from d335e21db9a4.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B29E9C24-906D-4329-8ADD-08E4BD054966.1; Fri, 19 Jun 2020 08:58:35 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d335e21db9a4.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 19 Jun 2020 08:58:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I4fC7l80IemMWKrtFJ74emDYDp61TM9wLgZ+cqKPQCL16iX6LDSdN7cMvWCD++2uCevKJ2ActzYy3zg/dAWJarsXXDTivs9gttKXUmtV3cam+DweeK2M7SBh2mahTpzJtVKuVoRg6L31Tbjp+evtxxtg+ubbagDdJPYxRkdWPOW9H+/WQ2KcMlwSw2L0Ae3mWRXGtME5RE8xLIzEBHOX8hlgqn55+H+0fQV7Djzz5tafkH6jqKtZ/M4/K4UaFzwIDe+8llW14ktr6sk+OwUvGv1PzdMk6+5M4J1ShYC8sIlBg5XmJiDsR6+m7VIl3GAwFTrY7Lyzh+57SLRJoQAY5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9mMM7QI/Wb+lHb3XyzTsLYOckaGqklUKgi8N/ybm6i0=; b=ofnnTE3V2ROc6xBzRNyzklxBnAJjRKAd1h1GC9Z8mDyUG7dNAxUpD/vVZqt+DBszwsGR0XT790D4EbA+joTFlIkKCQeZkU4GzjoXEF8AyejLW3USGNRdDxigGpC6BKdbJUTSuQCIT+VdcIzSR3DstosaSlTxqHmVrhb+VIAVwV2SyaQXfIe29+6ISqhyvz5zXAHzmzw6/9ZEerkR0Fahig5ZK9Ry3c9bs7mRi5Ntz6TXvpB+vGJpZzyN8/iG8KBPbzbOhYDvyo4+16QxuX8lrZ5Io1Y++X/d9ebm3fMM1kQyCfHqCc141Ye6xDPaXlxm8v1m3S7D0dMMKjtTrkuNrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9mMM7QI/Wb+lHb3XyzTsLYOckaGqklUKgi8N/ybm6i0=; b=LYnFy7hwdyGNgDFC/c88cNozHyarpsnJ5QeCAfbUXmFBAlAO/8eid8Le38rSGM1pBQ4vWZHi6P3es/v+bXAi+6WqjmbV+jmkjckcTbM0kkA78REL7eeiEw2yFNwcEpPHIlZX0kFA3Nq8LnaxXGEgnJpyhKRVd8AhR1uIl8TxuNs= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3100.eurprd08.prod.outlook.com (2603:10a6:5:28::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 19 Jun 2020 08:58:33 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 08:58:33 +0000 From: Bertrand Marquis To: Peng Fan Subject: Re: [Tee-dev] TEE with XEN Thread-Topic: [Tee-dev] TEE with XEN Thread-Index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQAw/zsAAIeJWwAAHsEHgAAAD3awAABi1QA= Date: Fri, 19 Jun 2020 08:58:33 +0000 Message-ID: References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> <68572FBC-8AE3-44A4-A815-1A9A7FFFA098@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [217.140.99.251] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b9dcbe00-b644-4cf8-f819-08d8142ef773 x-ms-traffictypediagnostic: DB7PR08MB3100:|VI1PR08MB2894: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0439571D1D X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: YOeRlQJTcErTMLxSlaLBwgOq8nKiRaag7yYulIlyuhVyxDtaWhX74hgadSdQZQCEsT+Yr5jsXFeDhb/XjB5Vx2a5Tsx8VOIW0HaGKlosyjaw8A8I2tCKVdkg0FxlK+eWzeH9Eyi+uce5dWascpFyZCmmaLxgaXBd039S8sSwiYZo32RtLcIadufpfJ39nTUNyGsu7b4HWbSTWxkwUy00C8iKuk52LwOlJmzu43eeqdccTMn8mDzDibqhIb48RPVbwnVW5q0jNUBV6Z4qejnDiCerhEVdFyPQUKLpsc9UiJb4Oe6o7mughELNFLqb6Sz+4uBO7V1dR79Bb+hjp9mZ6w== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(376002)(39860400002)(366004)(2906002)(83380400001)(6512007)(86362001)(8936002)(6486002)(478600001)(5660300002)(8676002)(36756003)(4326008)(2616005)(186003)(6916009)(66446008)(64756008)(54906003)(53546011)(33656002)(66476007)(6506007)(66946007)(76116006)(316002)(91956017)(66556008)(71200400001)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9dlKpWlcyi2oISL31t8rOh0cgUyI3/W/dqXjQEiMpz8fN0jX1oYWGztMyZy4hYO411B+/E6giVDvYhczNFWfVk+pn2trJsL+nTLhi7Oq+VZHyqgyblS1lJ7TG/mz2DlX/7cACgyOW1oMfrPOomGSV3HFlZRRIFdxaK1Kq+Fd7Kkur6r1CelnUIGTuYq5xvnBjENFNhUnZRKaLf2ITs1fwM1OvXF2PxejWbMNXvK3I0yfoNO0DllMjyFXlSBr3UAhqvhoKNB638K1zM0iJKbHDhVtKMKj0TStg0TArHoWUE4IVN92MxLvuJFXhdtSCDJoq4mCqliLshd2opM2v7wihOAaUafyf6XrX6j2eSgjF7lbRV0eRv47H+RCull+L7obb4mj9jYOSBwaO+rw1dl3U0Aa2+3iu1RbjjVZhMJzeIlia+I0rAfllFi1HocRHncm4jPmsgPYxR/4Ksw1sKHTxayKyeo9lRQFFGI6YUp/SKiwz8H9599C1iEbSYF4xaZ6 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3897C35E78AF24409A79598AE2140EF1@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3100 Original-Authentication-Results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT055.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(376002)(346002)(136003)(46966005)(70586007)(70206006)(26005)(33656002)(83380400001)(6862004)(54906003)(336012)(2616005)(186003)(82310400002)(86362001)(82740400003)(81166007)(316002)(356005)(53546011)(47076004)(6506007)(8936002)(478600001)(6486002)(8676002)(5660300002)(2906002)(36756003)(4326008)(6512007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 7abced8d-006f-4231-f6f0-08d8142ef1ea X-Forefront-PRVS: 0439571D1D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BtlNH9HExLWuN/mIlkxTvDZT2CtzFXWqDW1zgOTp793IeYYr+sJS0NqQtuACP8F92c57fja5ZDk32emTiBqG9a/rn8pJUMorjD0cm9bK2nRhkOnMKhtXU27rMnHuNiE3mzXmNzhZYKCN4OuXNojb7K6Djt93PsAWZsSb1Z46pKyaeH+FXgsIr6kz7rK6csBiYWEPwbdTYb6h2fH/BIDPITABAbBvgUcRdaCrvttXHrlVTAwXkKAG0Z2cWnacUTwurCCAXaIrMEC4j7qdszaIFkxoZQRvXIieNp2Z2kuaYkqGEf+1CAryctghFKbeVfvGFy1jf7afTBKa6tuy8HkVsydDjXS+3SNyFrz+g0IIBKQMeDL8lKr/QyZPSPDAQZ8Yepovecr8pRTlGJAzWMAxYQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2020 08:58:42.5315 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b9dcbe00-b644-4cf8-f819-08d8142ef773 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB2894 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Oleksandr Andrushchenko , Volodymyr Babchuk , "tee-dev@lists.linaro.org" , Xen-devel , nd , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gMTkgSnVuIDIwMjAsIGF0IDA5OjUyLCBQZW5nIEZhbiA8cGVuZy5mYW5AbnhwLmNv bT4gd3JvdGU6DQo+IA0KPiBIaSBCZXJ0cmFuZCwNCj4gDQo+PiBTdWJqZWN0OiBSZTogW1RlZS1k ZXZdIFRFRSB3aXRoIFhFTg0KPj4gDQo+PiBIaSwNCj4+IA0KPj4+IE9uIDE4IEp1biAyMDIwLCBh dCAxOTowNSwgSnVsaWVuIEdyYWxsIDxqdWxpZW5AeGVuLm9yZz4gd3JvdGU6DQo+Pj4gDQo+Pj4g K0JlcnRyYW5kIGFuZCBTdGVmYW5vDQo+Pj4gDQo+Pj4gT24gMTYvMDYvMjAyMCAwMjoyNCwgVm9s b2R5bXlyIEJhYmNodWsgd3JvdGU6DQo+Pj4+IEhpIFBlbmcsDQo+Pj4+IE9uIE1vbiwgMTUgSnVu IDIwMjAgYXQgMDU6MDcsIFBlbmcgRmFuIDxwZW5nLmZhbkBueHAuY29tPiB3cm90ZToNCj4+Pj4+ IA0KPj4+Pj4gSGkgQWxsLA0KPj4+Pj4gDQo+Pj4+PiBXaGlsZSBlbmFibGluZyB0cnVzdHkgb3Mg d2l0aCB4ZW4sIEkgdG9vayBzYW1lIGFwcHJvYWNoIGFzIE9QLVRFRSwNCj4+Pj4+IHdpdGggT1At VEVFIHJ1bm5pbmcgaW4gc2VjdXJlIHdvcmxkLiBCdXQgSSBhbSBhbHNvIHRoaW5raW5nIHRoaXMN Cj4+Pj4+IG1pZ2h0IGludHJvZHVjZSBwb3RlbnRpYWwgaXNzdWUgaXMgdGhhdCBzZWN1cmUgd29y bGQgT1MgY29tbXVuaWNhdGUgd2l0aA0KPj4gRG9tVS4NCj4+Pj4+IElmIHRoZXJlIGFyZSBzb21l IG1pc2JlaGF2aW9yIGluIHNlY3VyZSB3b3JsZCBPUywgaXQgbWlnaHQgbGV0IFhFTg0KPj4+Pj4g aHlwZXJ2aXNvciBub3Qgd29yayBwcm9wZXIuDQo+Pj4+PiANCj4+Pj4+IEluIG15IHNldHVwLCB0 cnVzdHkgb3Mgc29tZXRpbWVzIHBhbmljIGluIHNlY3VyZSB3b3JsZCwgeGVuIHdpbGwgbm90DQo+ Pj4+PiBhYmxlIHRvIGNvbnRyb2wgdGhlIHBhbmljIGNvcmUgYW55bW9yZS4NCj4+PiANCj4+PiBN YXkgSSBhc2sgaW4gd2hpY2ggY2FzZSBUcnVzdHkgaXMgcGFuaWNraW5nPw0KPj4gDQo+PiBJbiBh bnkgY2FzZSwgb3B0ZWUgc2hvdWxkIHByb3RlY3QgaXRzZWxmIGFnYWluc3QgdGhpcyBhbmQgaXQg c2hvdWxkIGJlDQo+PiBjb25zaWRlcmVkIHRoYXQgb3B0ZWUgaXMgbW9yZSBwcml2aWxlZGdlZCB0 aGVuIFhlbi4NCj4+IFNvIGlmIG9wdGVlIGlzIGNyYXNoaW5nIHdlIGNhbm5vdCBleHBlY3QgdGhh dCBYZW4gY2FuIHJlY292ZXIgb3IgZml4IGl0Lg0KPj4gDQo+PiBJIHdvdWxkIG1vcmUgY29uc2lk ZXIgdGhpcyBhcyBhIGJ1ZyB0aGF0IG9wdGVlIG5lZWRzIHRvIGJlIHJvYnVzdCBhZ2FpbnN0Lg0K PiANCj4gb2suIEkgYW0gbm90IHVzaW5nIE9QLVRFRSwgY3VycmVudGx5IEkgdXNlIGdvb2dsZSB0 cnVzdHkgT1MuDQoNClNvcnJ5IGkgc2hvdWxkIGhhdmUgYmVlbiBtb3JlIGdlbmVyaWMuDQpQbGVh c2UgcmVhZCB0aGlzIGFzIOKAnEFueXRoaW5nIHJ1bm5pbmcgaW4gc2VjdXJlIHdvcmxk4oCdLCBi ZWluZyBvcHRlZSBvciB0cnVzdHkuDQoNCj4gDQo+IEkgaGF2ZSB0d28gT1MsIERvbTAgbGludXgg KyBEb21VIGFuZHJvaWQgYXV0by4NCj4gDQo+IERvbVUgYW5kcm9pZCBhdXRvIG5lZWRzIHRydXN0 eSBPUywgRG9tMCBMaW51eCBub3QgbmVlZCB0aGF0Lg0KDQpCdXQgaSB3b3VsZCBndWVzcyB5b3Vy IERvbTAgaXMgbW9yZSDigJxjcml0aWNhbOKAnSB0aGVuIHlvdXIgRG9tVS4NCkluIHRoaXMgY2Fz ZSB5b3UgbXVzdCBtYWtlIHN1cmUgdGhhdCBhbnkgcmVzb3VyY2UgZ2l2ZW4gdG8geW91ciBEb21V IGNhbm5vdCBhZmZlY3QgeW91ciBEb20wLg0KRm9yIGV4YW1wbGU6IGlmIHRoZSBEb21VIGlzIHN0 YXJ0aW5nIGEgdmVyeSBoZWF2eSBvcGVyYXRpb24gaW4gYmxvY2tlZCBpbiB0cnVzdHksIGFueSBp bnRlcnJ1cHQgZm9yIG5vbi1zZWN1cmUgY291bGQgYmUgYmxvY2tlZCwgdGh1cyBhZmZlY3Rpbmcg dGhlIGFiaWxpdHkgb2YgeW91ciBEb20wLg0KDQo+IA0KPiBJIG5vdCB3YW5uYSB0cnVzdHkgT1Mg Zm9yIERvbVUgY291bGQgYnJpbmcgYW55IGRldGVjdCB0byBEb20wIG9yIHhlbi4NCj4gDQo+IE9u ZSBtb3JlIGNhc2UgaXMgaWYgZG9tMCBsaW51eCBuZWVkcyBPUC1URUUsIERvbVUgbmVlZHMgZ29v Z2xlIHRydXN0eSwNCj4gaG93IHdlIGhhbmRsZSB0aGlzIGluIG9uZSBTb0M/DQoNCllvdSBoYXZl IGEgc2hhcmVkIHJlc291cmNlIGluIHRoaXMgY2FzZSwgc29tZW9uZSBtb3JlIG9yIGFzIHRydXN0 ZWQgYXMgdGhlIGNsaWVudHMgbmVlZHMgdG8gZGVjaWRlIGhvdyB0aGUgcmVzb3VyY2UgY2FuIGJl IHNoYXJlZC4NCkluIHRoaXMgY2FzZSBjb3VsZCBiZSBEb20wIG9yIFhlbiBvciBUcnVzdHkgb3Ig b3AtVGVlIChpZiBpIHNob3VsZCBtYWtlIGFuIG9yZGVyKS4NCg0KPiANCj4+IA0KPj4+IA0KPj4+ Pj4gDQo+Pj4+PiBTbyBJIGFtIHRoaW5raW5nIHdoZXRoZXIgd2UgbmVlZCB0byBlbXVsYXRpbmcg c2VjdXJlIHdvcmxkIGluIGEgWEVODQo+Pj4+PiBWTSB3aGljaCBpcyB0aGUgVk0gcnVubmluZyBE b21VLiBKdXN0IGxpa2Ugd2hhdCBBQ1JOIGRpZCB0byBydW4NCj4+Pj4+IHRydXN0eSBvcy4NCj4+ Pj4gV2VsbCwgaXQgZGVwZW5kcyBvbiB3aG9tIHlvdSBhcmUgdHJ1c3RpbmcgbW9yZS4gQm90aCBY RU4gYW5kIFRFRSBhcmUNCj4+Pj4gbWluaW1hbCBPUyBpbXBsZW1lbnRhdGlvbnMgd2l0aCBhaW0g YXQgc2VjdXJpdHkuIEknbSBzcGVha2luZyBhYm91dA0KPj4+PiBnZW5lcmljIFRFRSBPUywgbm90 IGFib3V0IHBhcnRpY3VsYXIgT1MgbGlrZSBPUC1URUUgb3IgVHJ1c3R5Lg0KPj4+PiBQcm9ibGVt IGlzIHRoYXQsIGlmIFRFRSBpcyBydW5uaW5nIGluc2lkZSBWTSwgaXQgd2lsbCBiZSBzdXNjZXB0 aWJsZQ0KPj4+PiB0byBhIGh5cGVydmlzb3IgbWlzYmVoYXZpb3VyLiBZb3UgbmVlZCB0byB1bmRl cnN0YW5kIHRoYXQgWGVuIGFuZA0KPj4+PiBwcml2aWxlZ2VkIGRvbWFpbiAoZG9tMCwgbW9zdGx5 KSBjYW4gYWNjZXNzIG1lbW9yeSBvZiBhbnkgZ3Vlc3QuDQo+Pj4+IEF0IGxlYXN0LCBpbiBkZWZh dWx0IGNvbmZpZ3VyYXRpb24uIFRoZXJlIGFyZSBtZWFucyB0byBoYXJkZW4gdGhpcw0KPj4+PiBz ZXR1cC4gQnV0IGFueXdheXMsIFhlbiBjYW4ndCBiZSBzdG9wcGVkIGZyb20gcmVhZGluZyBURUUn cyBzZWNyZXRzLg0KPj4+IA0KPj4+IElJUkMsIHdlIGRpc2N1c3NlZCB0aGlzIGFwcHJvYWNoIGZv ciBPUC1URUUgaW4gdGhlIHBhc3QuIFRoZXJlIHdhcyBvdGhlcg0KPj4gcG90ZW50aWFsIHBpdGZh bGxzIHdpdGggaXQuIEZvciBpbnN0YW5jZSwgeW91IHdvdWxkbid0IGJlIGFibGUgdG8gZGlyZWN0 bHkgYWNjZXNzDQo+PiBhbnkgc2VjdXJlIGRldmljZSBmcm9tIHRoYXQgZ3Vlc3QgKGl0IGlzIHJ1 bm5pbmcgaW4gbm9uLXNlY3VyZSB3b3JsZCkuDQo+Pj4gDQo+Pj4gVGhlcmUgYXJlIGFsc28gaXNz dWVzIGluIHRlcm0gb2YgbGF0ZW5jeSBhcyB5b3UgbWF5IGhhdmUgdGhlIGZvbGxvd2luZw0KPj4g bW9kZWw6DQo+Pj4gDQo+Pj4gZG9tVSAtPiBYZW4gLT4gZG9tVSBURUUgLT4gKFhlbiAtPiBob3N0 IFRFRSAtPiBYZW4gLT4gZG9tVSBURUUpIC0+IFhlbiAtPg0KPj4gZG9tVS4NCj4+PiANCj4+PiBU aGUgYml0IGluICgpIGlzIGlmIHlvdSByZXF1aXJlIHRvIGNhbGwgdGhlIGhvc3QgVEVFLg0KPj4+ IA0KPj4+IE9uZSBwb3NzaWJpbGl0eSB3b3VsZCBiZSB0byB1c2UgU2VjdXJlLUVMMiBmb3IgeW91 ciBUcnVzdHkgT1MuIEJ1dCBJIGRvbid0DQo+PiBrbm93IHdoZXRoZXIgeW91ciBwbGF0Zm9ybSBz dXBwb3J0cyBpdC4NCj4+PiANCj4+PiBEZXBlbmRpbmcgb24gd2hldGhlciB5b3UgY2FuIG1vZGlm eSBUcnVzdHkgT1MsIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvDQo+PiBtYWtlIGl0dmlydHVhbGl6 YXRpb24gYXdhcmUgYXMgT1AtVEVFIGRpZC4gVGhlIGNvcmUgd291bGQgbmVlZCB0byBiZQ0KPj4g cmVzaWxpZW50IGFuZCB0aGUgcGFuaWMgb25seSBhZmZlY3QgYSBnaXZlbiBjbGllbnQuDQo+PiAN Cj4+IEkgZG8gbm90IGhhdmUgcmlnaHQgYSBjbGVhciBpZGVhIG9mIHdoYXQgaXMgdGhlIHN0YXR1 cyBvZiBvcHRlZSBhbmQgeGVuIGJ1dCBpbg0KPj4gdGhlb3J5IEkgd291bGQgc2VlIDIgcG9zc2li bGUgd2F5cyB0byBoYW5kbGUgdGhpczoNCj4+IC0gd2l0aG91dCBvcHRlZSBtb2RpZmljYXRpb24s IHNvbWV0aGluZyBpbiBhIGd1ZXN0IChEb20wIG9yIGFuIG90aGVyDQo+PiBwcml2aWxlZGdlZCBv bmUpIG5lZWRzIHRvIGhhdmUgYWNjZXNzIHRvIG9wdGVlIGFuZCBlbXVsYXRlIG9wdGVlIGFjY2Vz cyBmb3INCj4+IG90aGVycy4NCj4+IC0gd2l0aCBvcHRlZSBtb2RpZmljYXRpb25zLCBvcHRlZSBu ZWVkcyB0byBoYXZlIGEgY29uY2VwdCBvZiBjbGllbnQgYW5kIFhlbg0KPj4gd291bGQgbmVlZCB0 byBwYXNzdGhyb3VnaCBvcHRlZSByZXF1ZXN0cyBidXQgYmVpbmcgcmVzcG9uc2libGUgb2YgYWRk aW5nIGENCj4+IOKAnGNsaWVudOKAnSBpZGVudGlmaWVyLiBNYXliZSBhbHNvIGluZm9ybWluZyBP cHRlZSB3aGVuIGEgbmV3IGNsaWVudCBpcw0KPj4gY3JlYXRlZC9yZW1vdmVkLg0KPj4gDQo+PiBU aGUgc2Vjb25kIHNjZW5hcmlvIGNvdWxkIHRoZW4gYmUgc29tZWhvdyBzcGxpdHRlZCBpbiB0aGUg cHJldmlvdXMgb25lIGZyb20NCj4+IEp1bGllbiBpZiBzb21lIHBhcnRzIHdvdWxkIG5lZWQgdG8g YmUgZW11bGF0ZWQgc29tZXdoZXJlIGluIHNvbWUga2luZCBvZg0KPj4gY29tYmluYXRpb24gb2Yg dGhlIDIgbW9kZWxzLg0KPj4gDQo+PiBJbiBhbnkgY2FzZSBpIHdvdWxkIGFsd2F5cyBjb25zaWRl ciB0aGF0IGFueXRoaW5nIHJ1bm5pbmcgb24gb3B0ZWUgKG9yIGluDQo+PiBnZW5lcmFsIGluIHRo ZSBzZWN1cmUgd29ybGQpIGlzIG1vcmUgdHJ1c3RlZCB0aGVuIFhlbi4NCj4gDQo+IE9rLCB0aGlz IG1lYW5zIG9wdGVlIHJ1bnMgb24gYWxsIGNvcmVzIGluIHNlY3VyZSB3b3JsZCwgYnV0IHRoaXMg d291bGQgbm90DQo+IHdvcmsgd2hlbiB3ZSBuZWVkIHRvIHN1cHBvcnQgbXVsdGlwbGUgT1NlcyB3 aXRoIHRoZWlyIG93biBURUUuDQoNCkkgd291bGQgdGhpbmsgeW91IGhhdmUgb25lIFRFRSBydW5u aW5nIG9uIGFsbCBjb3JlcyAob3IgcnVubmFibGUgaW4gdGhpcyBjYXNlKS4NClNvIHRoZSBUZWUg bmVlZHMgdG8gaGFuZGxlIHNldmVyYWwgY29udGV4dHMgb3Igc29tZW9uZSBuZWVkcyB0byB2aXJ0 dWFsaXplIGl0Lg0KDQpSZWdhcmRzDQpCZXJ0cmFuZA0KDQo= From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:01:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:01:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCu2-0000oo-LO; Fri, 19 Jun 2020 09:01:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCu1-0000oj-5t for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:01:37 +0000 X-Inumbo-ID: 7a7b9692-b20b-11ea-bb8b-bc764e2007e4 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (unknown [40.107.4.76]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7a7b9692-b20b-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 09:01:36 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jZuLuQvySxAps6jBA17Wfd1Own+D6o4F1PO/0tBpFpmw32CxNZZFGkJ8X55wrCMnx6hPtxP+PTnKSH/RvtiEB3nrBNm7AUH6kFEFPcAMVA2XcywIHe/EihAE5OuidCQ+9T54G1bDc912EF0gHsEH//HB5rjG1hByT6m/WlGpcj0SoB9btzWocLvxO+3a1FmIx7iRzEdWvjXlh0Hf7NZ8lvhgdFFdoBbH8qfH869Ncr3f1mHZPw5BNl1c8NigRwAMJUVWzOAmODW4UCHGmY2A2Ej2qVoS/0VzWxOmrUVOIo8loEtrsmG4ujUglEjv+ZYIp5e6A6cLks4/XgOk33kmew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cowXw8WTi53GmEDVmNewfn2D9Hr6EV/2QnhPcV8Mg2Y=; b=h/G/EQ1tLJjXOqKKAv/O13cBHTkhC0L4Fg/VtqDPyAJmrAGxysx16aqgvJGO7IgnpShNSZSrTlnHSvFMlgbXs5KaNyAsJqDejxDteDZ3oTyj2peAMxIGDEnDiFFBh7zHIQC2e/OtT1tJ/FcyUPVri4ix3BpBIR2zh3QS0RO1SoXqPy3FTalhz1nlr5QSx31lRsIXCkNsGF1EPvrt9beFHbih7dF87v7puitAqLJ1ER83+ptWhjOLEE4X4g3ssXrzGNExXLWBO+tpE6rfnpSnBke2rujFnC+PRLG2MRZiR9XlgN72XmDMrXHK2nSJTlhgQPXZ8lBVMOtZra/c6OxFaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cowXw8WTi53GmEDVmNewfn2D9Hr6EV/2QnhPcV8Mg2Y=; b=CrReyM7fH6MBgC6yZLoqCufhpxMQAIM5EnMbKuTULmENFDjRhpKTe2Duee9tMQnYc/57CzM0UeA6Hu28LRwLf6DGMWdg21RBl+dZEzh/ZjK9tdXUiAw8AbpwizZFxedwAGiwmKLCrLubVhC8zJMoEL/grnPExA6mB6cbHZD0KG+We3l17M+DP5nXY0NvT3qF15dpAhAw1l/3EABhzy827/xofOP8Q39fTjh35NOJPMgzX/+T2FNhn9rvCZ2d08ijEasLzcFyI/kMwaQobDbLAJjOa5rPF3BiNBlMyoatXsMfbLm2ZU3b8901jdwWm8Z/y9lzaJj8yPFX4dEcPit24A== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB4670.eurprd03.prod.outlook.com (2603:10a6:803:5d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.18; Fri, 19 Jun 2020 09:01:33 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3109.023; Fri, 19 Jun 2020 09:01:33 +0000 From: Volodymyr Babchuk To: Julien Grall Subject: Re: [PATCH] optee: immediately free buffers that are released by OP-TEE Thread-Topic: [PATCH] optee: immediately free buffers that are released by OP-TEE Thread-Index: AQHWI0fTRy+rlPvmsUKZMLlR49t2iaiiqEuAgAAKD4CAANCDAIA7s8+AgACw6QCAAAJPAA== Date: Fri, 19 Jun 2020 09:01:33 +0000 Message-ID: <87sger1lar.fsf@epam.com> References: <20200506014246.3397490-1-volodymyr_babchuk@epam.com> <51b8c855-5e94-2829-a703-d43c84948120@xen.org> <57e24ddd-5ba1-eea9-2961-d7dc9ce22688@xen.org> In-Reply-To: <57e24ddd-5ba1-eea9-2961-d7dc9ce22688@xen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.4.10; emacs 26.3 authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a3474750-dc00-4a81-d959-08d8142f5d56 x-ms-traffictypediagnostic: VI1PR03MB4670: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9saxKQfWq7mSjQipbKWSIAJUD8os+JLqZmMxcx5jl06+ziZHF/I1y2bfaul5vIpUONlZVARWat9Ai2rza70QG51dkVl398UmmL+DplYaHJ7wMWkHmhF1TllwdvTGqST5HxHVjdXnvSklpTJZ1HBZ7tzsPL7UFd7gNhMGJjG7esm/H24pI1fZWKlMXqHto+y2/clP8li11RB3m5ZvYOjCWJoNdWA3R7ottZ3TR77TFzO304nu5o/NMEYWYwcmgiXcOGh9BFv66AapxYHZZsraXS1R/3f/ihxR5xjTfedbkrtPIhdmG+SrWVMpgeWP50GjV/CxBTqncydWGuE68BGwIJeGQs7/Z1xQTrgRQqaZ0xJ6WTks5EoLiPbbGzlULs/o x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(396003)(136003)(376002)(346002)(6506007)(36756003)(55236004)(4326008)(53546011)(6486002)(316002)(91956017)(2616005)(186003)(66476007)(26005)(66946007)(54906003)(64756008)(66556008)(66446008)(76116006)(83380400001)(6916009)(6512007)(8936002)(71200400001)(478600001)(86362001)(4744005)(8676002)(2906002)(5660300002)(14773001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xmm2xT8Ds9jS4/JDXZAlOuBgIAxtKntLFkKdTfaiRRreZOkiE9FbvERkyqamHM+pn7fk+S/0BMlnx31KNgY5izq9Y4RvvEPkc3TPM3q3NEmoEasSduUatHCW5MNlD0U0uBFRBfnTiKyof+dDviCVti6flZKwAqqkQYUpV877ucJqIcBlS9CidS0TBUoYekAWLE7N6PIuH5Ys/T0BV1VfDeCwSBRacq23q1IQx1MTeaWAQDr/P5HfiHsPF/BbjgMHe49X0Pe+ZXrmD0/XAdR/vlQujjEu/IoyKbIbb9hQpac7d3WKJUyKg7NOt5SrZUUDxzGZvEFBHP1tV9QY0XLMnEeNkVhtJUIpE+DjXW6+8uYtZ1CW/iDLXnQypSDlde40Z9JjEsjw2+VYbBn2WHM4Qlok31C0lr3iMt1JO2a+zvFm13cxJ1sI7k8oGLePdJvwVJqjBYbl/lgMskmSI7sbHNYUtrPL1nNMDb+b3q8vRao= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: a3474750-dc00-4a81-d959-08d8142f5d56 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 09:01:33.3657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FINU/zhGd7n+TIy1EGcwDaVD7rY2izZ7jJwTDyaaL9DDyBP7t6a72c5k8MPsUvnjqHAQrCYxEK76I/Ev4ldAS/Mua2lwsbhMGMA3aNHataU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4670 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "tee-dev@lists.linaro.org" , Andrew Cooper , Stefano Stabellini , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Julien, Paul, Julien Grall writes: > On 18/06/2020 23:20, Stefano Stabellini wrote: >> Hi Paul, Julien, >> >> Volodymyr hasn't come back with an update to this patch, but I think it >> is good enough as-is as a bug fix and I would rather have it in its >> current form in 4.14 than not having it at all leaving the bug unfixed. >> >> I think Julien agrees. > > The approach is okayish but this is not ideal at least without any > explanation why ignoring a potential bug is fine. I could settle with > an expanded commit message for now. > > Therefore, I don't feel I should provide my Ack on this approach. That > said, I am not the maintainers of this code. You are free to Ack and > commit it. Sorry for the delay. I'll provide v2 later today. --=20 Volodymyr Babchuk at EPAM= From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:03:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:03:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCw7-0000wg-1t; Fri, 19 Jun 2020 09:03:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCw5-0000wb-Oc for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:03:45 +0000 X-Inumbo-ID: c75643a4-b20b-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c75643a4-b20b-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 09:03:45 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id r15so8389396wmh.5 for ; Fri, 19 Jun 2020 02:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=eqGVTaL7I09fSt8xiiKydMdPTw03g9WyqCugj1c7ZRA=; b=WHZegl49L3AkFCgz3WyYZZbEvupHczYEKrdM1x6tWtAezTNUXZBegkTQukvdkW707A 6dxg9RLez7dkRHPxfd7qtiHLBdxozDGoNK24+x7iXX2VKl1f1RnGpAivJ9JeRJsaniwE OZA/7X9gVSsadd5s8rkvYY1MKSNo9N7Lc+sn8D5EMJi6CSECyZ4aLUAY6IrndZDHLQSK vsjLCnypQXQ0JN6ABfEk7UPJQXXGQDwq/B+QIJRjEw9jf7+/JZTGS7zPbPRh1xMX4A8J 3n+p45V3dd/TzpmoWS7qrq/wIYjQ96oWWpgXUTSxv9rVlc8jdTHvADOLSSN5UuJtPlY5 jHOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=eqGVTaL7I09fSt8xiiKydMdPTw03g9WyqCugj1c7ZRA=; b=BXTTdDUOpBcR35Lj+Vcitgw6yUgL5HCUHtwN4ZmbAcb/K8IRacU/4z6xZ2YfqTLdnZ uZqtiK3+oI/kFRhT7A3OUZX7SaXje5Fi+1H1mVg7/gwfpx7ois30hCFQn2jyW5peHNOj Zbd+nCgMb+Yl8BVsEdtuUbGYmwH6Sa+JhbY6y8Crub/a1+YLWuV3mxRsxcMIc3ZhtzU6 GZpnjssNeBHJeiY3roNmdzDz/LIfxVWFcDvSXzYbY370Ph07GtgNuZ2/C79DuNbR4Nvc /JbRhSLU+IgUcCXoja5Ul1XVQaQJH+rDPjleethCZSX2riOCdSsKv7qgJnfS83XhWQlU imNQ== X-Gm-Message-State: AOAM533yqNuf+jvs06EX4x23DkAMA7yDz07kKwDT0RoaF+AWbPgCRCTh GB09pBybEd0Ox7SXoFjhnmY= X-Google-Smtp-Source: ABdhPJzuTfHjOBExJd3YwtBUHiqSp3UHmcldRUcFGypgt2huvdymHXtQIIzqnWZVOgUAKmQBDbZxSw== X-Received: by 2002:a1c:7f87:: with SMTP id a129mr2857945wmd.10.1592557424353; Fri, 19 Jun 2020 02:03:44 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.188]) by smtp.gmail.com with ESMTPSA id h188sm6418392wmh.2.2020.06.19.02.03.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 02:03:43 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Boris Ostrovsky'" , "'Souptick Joarder'" , , References: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> In-Reply-To: Subject: RE: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() Date: Fri, 19 Jun 2020 10:03:42 +0100 Message-ID: <00a901d64618$888e12a0$99aa37e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLNWdkmTQEG0NOkr/mSq3vuIFPj4QGVx8AxpuTONkA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, 'John Hubbard' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Boris Ostrovsky > Sent: 17 June 2020 18:57 > To: Souptick Joarder ; jgross@suse.com; = sstabellini@kernel.org > Cc: xen-devel@lists.xenproject.org; linux-kernel@vger.kernel.org; John = Hubbard ; > paul@xen.org > Subject: Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to = pin_user_pages*() >=20 > On 6/16/20 11:14 PM, Souptick Joarder wrote: > > In 2019, we introduced pin_user_pages*() and now we are converting > > get_user_pages*() to the new API as appropriate. [1] & [2] could > > be referred for more information. > > > > [1] Documentation/core-api/pin_user_pages.rst > > > > [2] "Explicit pinning of user-space pages": > > https://lwn.net/Articles/807108/ > > > > Signed-off-by: Souptick Joarder > > Cc: John Hubbard > > --- > > Hi, > > > > I have compile tested this patch but unable to run-time test, > > so any testing help is much appriciated. > > > > Also have a question, why the existing code is not marking the > > pages dirty (since it did FOLL_WRITE) ? >=20 >=20 > Indeed, seems to me it should. Paul? >=20 Yes, it looks like that was an oversight. The hypercall may well result = in data being copied back into the buffers so the whole pages array = should be considered dirty. Paul >=20 > > > > drivers/xen/privcmd.c | 7 ++----- > > 1 file changed, 2 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > > index a250d11..543739e 100644 > > --- a/drivers/xen/privcmd.c > > +++ b/drivers/xen/privcmd.c > > @@ -594,7 +594,7 @@ static int lock_pages( > > if (requested > nr_pages) > > return -ENOSPC; > > > > - pinned =3D get_user_pages_fast( > > + pinned =3D pin_user_pages_fast( > > (unsigned long) kbufs[i].uptr, > > requested, FOLL_WRITE, pages); > > if (pinned < 0) > > @@ -614,10 +614,7 @@ static void unlock_pages(struct page *pages[], = unsigned int nr_pages) > > if (!pages) > > return; > > > > - for (i =3D 0; i < nr_pages; i++) { > > - if (pages[i]) > > - put_page(pages[i]); > > - } > > + unpin_user_pages(pages, nr_pages); >=20 >=20 > Why are you no longer checking for valid pages? >=20 >=20 > -boris >=20 >=20 >=20 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:06:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:06:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCyO-00013y-Et; Fri, 19 Jun 2020 09:06:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmCyN-00013t-6O for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:06:07 +0000 X-Inumbo-ID: 18a7221e-b20c-11ea-b7bb-bc764e2007e4 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:7e1a::626]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 18a7221e-b20c-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 09:06:01 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N2vcOqqoDwdSMohOFkbe67Q5cLdUjsZTUcGd6B38CT9LkPmJuvCP1m9bIXGVEm4taOHdkU7hOGKQpR6v/60zUWpgikfrTeD8vCJyS4D1KlcuzmziPQrLlZqOLLJ3ECCnXs+s3xGRRkhF1wsAMPfVfptGvlRcx8kmbdLF2I1mbPdLZTNK/bZP77+Ulnx8vwgr0eKHkqVBITep9CQ7fSt4PHBptFt6Gc15STiNCBlmbRwDManVrdKxvBMKXgQYScItz5TkuytPXRkaqLdAYC6EZettTYD9Z8N1b2fgILrLnSzIwub/xpZpNizbWMda3vP028bMiHs5igWY2hCeJLCdGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OOnH1iBFRnHJ2a/DHiXrVHs2u9y+PQpdX0HHBIolzts=; b=JG4rSVZ/iW0Y57xpV5jLJoHNM7D4q7Y0mnMf3ks5JX2+MuM1u3UT00CkLaYFmYPL0QbsI1BSiBcDaoHcblVvM9wbw753S1lm+qZX7XELU3YRJz5aHDEFZvB533nPCKjf3OAXy170N9YwWFwKKC4YXCE/mkVaXXzXiefHOIe7Ch3ZO0DHNxql2xXVfjX+vDEoA+ZzRFNejGlggAVA5FWP2IHactJG7Ewdv1w0wi0S17dGS20r+x12YrDt7X2wzR/5zvqkIYrJMub0KDV02C0bHagiqt9F+aOBFXheTyom8hjMMobxbrFYheHG0/mWC9gShprFprEhER4TznpvnaoJZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OOnH1iBFRnHJ2a/DHiXrVHs2u9y+PQpdX0HHBIolzts=; b=frS+re2tSyqfEkzVJqZUT4cEj7nza3dUOxe1w2XOBJ2RcCkAfczthfEsP/OX9F5oknZwAXW+q1qJQJfSwD/LRcBD//Lzbbq9Ea3xKQbRyBvYNWR+g3riPGSpJI0vUqp7PMWzuGmd6TwbLidZs3ES1eKJdGApeqikacmPDlFEXs0= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2710.eurprd04.prod.outlook.com (2603:10a6:4:95::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 19 Jun 2020 09:06:00 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3088.028; Fri, 19 Jun 2020 09:05:59 +0000 From: Peng Fan To: Bertrand Marquis Subject: RE: [Tee-dev] TEE with XEN Thread-Topic: [Tee-dev] TEE with XEN Thread-Index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQAw/zsAAIeJWwAAHsEHgAAAD3awAABi1QAAADlWUA== Date: Fri, 19 Jun 2020 09:05:59 +0000 Message-ID: References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> <68572FBC-8AE3-44A4-A815-1A9A7FFFA098@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2eeb6075-5f52-4acc-0344-08d8142ffc2f x-ms-traffictypediagnostic: DB6PR0402MB2710: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5I5Oaz2Rr6GKVLDtUBhA3K/86ShQTvils7FvvVfVRODit+DMDcsQqcrhvMuU1U3/Jai++5lIvJ3Ey5tJf/IJe+DuhO7biqM/Befr2yXX7lzEod6uXNpfTb4HZVJVMTzcS9um/f9jStHP32Ne+ISLRO32E6yd7XPr2JBGTNg++2q0TER66Cr83FPYfs6ZaxAkfPmemWbWq4iMypzMqTrzxe0UWM+2FtZm0xmvKvAoXMwtjt1rfhwfysQF3ivxUo0xAYUqekCzK9Z64/C9UvLW9Em5wBcU5CQlPBE4SLDs69gzstFVsgQwxdWO4hKnywDgUWHMmkIeLPYZo0TQr4SxoQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(366004)(39860400002)(376002)(6916009)(44832011)(26005)(53546011)(76116006)(6506007)(66946007)(71200400001)(8676002)(478600001)(7696005)(66446008)(66476007)(33656002)(64756008)(66556008)(186003)(7416002)(52536014)(5660300002)(54906003)(316002)(83380400001)(55016002)(8936002)(86362001)(9686003)(2906002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: XEf3Eej8lvtCk1hYgMvyFnmMWVwWM2Z0+e4cJTmHXym+IbubRVI7rEaYmIONfrF26Pdd0LN84/kWEVYnsqEDWt+b1nZ2TaiT8SchrukBtuzjphaHeT+qHL3BZOV9d+2d4nMY4Kf4qK5oUUvrtXaBoXw7/xtMV2Djv/cxjgm0E453/RRs+2xWOvSTRS4zFvVhk+wO199Qb7pvc/UHn+0WU3GrhMwNI9YJoqIg7ZRRcgTusI2FLj55G0KC6IT/4YsZCBLv/zCAmSssod86uAuzhGG286R7rroAPuDYFbX/tIlFOhEPhlDpVIpoWLHSn19Eh/DVbI/KE9zee10PT0FEvOYnNGpqD6GV9rUo4oiL62wHpFZDky5M0TfXkIZhYFiQUGmgFb+u8NjRzNJMgixREWY7SxdkYKjY10x+O8kPNQRFhRkt8cAOavzjCH2eTHSMIaehKcUE7TwjDxczAP1x6iljhKq5acb2EogYGQ3aSWY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2eeb6075-5f52-4acc-0344-08d8142ffc2f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 09:05:59.9063 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /Bg2Ea5d1Z0dzETeKC+XrVgZzrxWr/Ynyp6tgD7ZlV0kJPnp2YcDJ0apnJqYJ1cu7bUZUdG/xMvctTw+Uk+eJQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2710 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Oleksandr Andrushchenko , Volodymyr Babchuk , "tee-dev@lists.linaro.org" , Xen-devel , nd , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiBTdWJqZWN0OiBSZTogW1RlZS1kZXZdIFRFRSB3aXRoIFhFTg0KPiANCj4gDQo+IA0KPiA+IE9u IDE5IEp1biAyMDIwLCBhdCAwOTo1MiwgUGVuZyBGYW4gPHBlbmcuZmFuQG54cC5jb20+IHdyb3Rl Og0KPiA+DQo+ID4gSGkgQmVydHJhbmQsDQo+ID4NCj4gPj4gU3ViamVjdDogUmU6IFtUZWUtZGV2 XSBURUUgd2l0aCBYRU4NCj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+PiBPbiAxOCBKdW4gMjAy MCwgYXQgMTk6MDUsIEp1bGllbiBHcmFsbCA8anVsaWVuQHhlbi5vcmc+IHdyb3RlOg0KPiA+Pj4N Cj4gPj4+ICtCZXJ0cmFuZCBhbmQgU3RlZmFubw0KPiA+Pj4NCj4gPj4+IE9uIDE2LzA2LzIwMjAg MDI6MjQsIFZvbG9keW15ciBCYWJjaHVrIHdyb3RlOg0KPiA+Pj4+IEhpIFBlbmcsDQo+ID4+Pj4g T24gTW9uLCAxNSBKdW4gMjAyMCBhdCAwNTowNywgUGVuZyBGYW4gPHBlbmcuZmFuQG54cC5jb20+ IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+PiBIaSBBbGwsDQo+ID4+Pj4+DQo+ID4+Pj4+IFdoaWxl IGVuYWJsaW5nIHRydXN0eSBvcyB3aXRoIHhlbiwgSSB0b29rIHNhbWUgYXBwcm9hY2ggYXMgT1At VEVFLA0KPiA+Pj4+PiB3aXRoIE9QLVRFRSBydW5uaW5nIGluIHNlY3VyZSB3b3JsZC4gQnV0IEkg YW0gYWxzbyB0aGlua2luZyB0aGlzDQo+ID4+Pj4+IG1pZ2h0IGludHJvZHVjZSBwb3RlbnRpYWwg aXNzdWUgaXMgdGhhdCBzZWN1cmUgd29ybGQgT1MNCj4gPj4+Pj4gY29tbXVuaWNhdGUgd2l0aA0K PiA+PiBEb21VLg0KPiA+Pj4+PiBJZiB0aGVyZSBhcmUgc29tZSBtaXNiZWhhdmlvciBpbiBzZWN1 cmUgd29ybGQgT1MsIGl0IG1pZ2h0IGxldCBYRU4NCj4gPj4+Pj4gaHlwZXJ2aXNvciBub3Qgd29y ayBwcm9wZXIuDQo+ID4+Pj4+DQo+ID4+Pj4+IEluIG15IHNldHVwLCB0cnVzdHkgb3Mgc29tZXRp bWVzIHBhbmljIGluIHNlY3VyZSB3b3JsZCwgeGVuIHdpbGwNCj4gPj4+Pj4gbm90IGFibGUgdG8g Y29udHJvbCB0aGUgcGFuaWMgY29yZSBhbnltb3JlLg0KPiA+Pj4NCj4gPj4+IE1heSBJIGFzayBp biB3aGljaCBjYXNlIFRydXN0eSBpcyBwYW5pY2tpbmc/DQo+ID4+DQo+ID4+IEluIGFueSBjYXNl LCBvcHRlZSBzaG91bGQgcHJvdGVjdCBpdHNlbGYgYWdhaW5zdCB0aGlzIGFuZCBpdCBzaG91bGQN Cj4gPj4gYmUgY29uc2lkZXJlZCB0aGF0IG9wdGVlIGlzIG1vcmUgcHJpdmlsZWRnZWQgdGhlbiBY ZW4uDQo+ID4+IFNvIGlmIG9wdGVlIGlzIGNyYXNoaW5nIHdlIGNhbm5vdCBleHBlY3QgdGhhdCBY ZW4gY2FuIHJlY292ZXIgb3IgZml4IGl0Lg0KPiA+Pg0KPiA+PiBJIHdvdWxkIG1vcmUgY29uc2lk ZXIgdGhpcyBhcyBhIGJ1ZyB0aGF0IG9wdGVlIG5lZWRzIHRvIGJlIHJvYnVzdCBhZ2FpbnN0Lg0K PiA+DQo+ID4gb2suIEkgYW0gbm90IHVzaW5nIE9QLVRFRSwgY3VycmVudGx5IEkgdXNlIGdvb2ds ZSB0cnVzdHkgT1MuDQo+IA0KPiBTb3JyeSBpIHNob3VsZCBoYXZlIGJlZW4gbW9yZSBnZW5lcmlj Lg0KPiBQbGVhc2UgcmVhZCB0aGlzIGFzIOKAnEFueXRoaW5nIHJ1bm5pbmcgaW4gc2VjdXJlIHdv cmxk4oCdLCBiZWluZyBvcHRlZSBvciB0cnVzdHkuDQo+IA0KPiA+DQo+ID4gSSBoYXZlIHR3byBP UywgRG9tMCBsaW51eCArIERvbVUgYW5kcm9pZCBhdXRvLg0KPiA+DQo+ID4gRG9tVSBhbmRyb2lk IGF1dG8gbmVlZHMgdHJ1c3R5IE9TLCBEb20wIExpbnV4IG5vdCBuZWVkIHRoYXQuDQo+IA0KPiBC dXQgaSB3b3VsZCBndWVzcyB5b3VyIERvbTAgaXMgbW9yZSDigJxjcml0aWNhbOKAnSB0aGVuIHlv dXIgRG9tVS4NCj4gSW4gdGhpcyBjYXNlIHlvdSBtdXN0IG1ha2Ugc3VyZSB0aGF0IGFueSByZXNv dXJjZSBnaXZlbiB0byB5b3VyIERvbVUgY2Fubm90DQo+IGFmZmVjdCB5b3VyIERvbTAuDQo+IEZv ciBleGFtcGxlOiBpZiB0aGUgRG9tVSBpcyBzdGFydGluZyBhIHZlcnkgaGVhdnkgb3BlcmF0aW9u IGluIGJsb2NrZWQgaW4NCj4gdHJ1c3R5LCBhbnkgaW50ZXJydXB0IGZvciBub24tc2VjdXJlIGNv dWxkIGJlIGJsb2NrZWQsIHRodXMgYWZmZWN0aW5nIHRoZSBhYmlsaXR5DQo+IG9mIHlvdXIgRG9t MC4NCj4gDQo+ID4NCj4gPiBJIG5vdCB3YW5uYSB0cnVzdHkgT1MgZm9yIERvbVUgY291bGQgYnJp bmcgYW55IGRldGVjdCB0byBEb20wIG9yIHhlbi4NCj4gPg0KPiA+IE9uZSBtb3JlIGNhc2UgaXMg aWYgZG9tMCBsaW51eCBuZWVkcyBPUC1URUUsIERvbVUgbmVlZHMgZ29vZ2xlIHRydXN0eSwNCj4g PiBob3cgd2UgaGFuZGxlIHRoaXMgaW4gb25lIFNvQz8NCj4gDQo+IFlvdSBoYXZlIGEgc2hhcmVk IHJlc291cmNlIGluIHRoaXMgY2FzZSwgc29tZW9uZSBtb3JlIG9yIGFzIHRydXN0ZWQgYXMgdGhl DQo+IGNsaWVudHMgbmVlZHMgdG8gZGVjaWRlIGhvdyB0aGUgcmVzb3VyY2UgY2FuIGJlIHNoYXJl ZC4NCj4gSW4gdGhpcyBjYXNlIGNvdWxkIGJlIERvbTAgb3IgWGVuIG9yIFRydXN0eSBvciBvcC1U ZWUgKGlmIGkgc2hvdWxkIG1ha2UgYW4NCj4gb3JkZXIpLg0KPiANCj4gPg0KPiA+Pg0KPiA+Pj4N Cj4gPj4+Pj4NCj4gPj4+Pj4gU28gSSBhbSB0aGlua2luZyB3aGV0aGVyIHdlIG5lZWQgdG8gZW11 bGF0aW5nIHNlY3VyZSB3b3JsZCBpbiBhDQo+ID4+Pj4+IFhFTiBWTSB3aGljaCBpcyB0aGUgVk0g cnVubmluZyBEb21VLiBKdXN0IGxpa2Ugd2hhdCBBQ1JOIGRpZCB0bw0KPiA+Pj4+PiBydW4gdHJ1 c3R5IG9zLg0KPiA+Pj4+IFdlbGwsIGl0IGRlcGVuZHMgb24gd2hvbSB5b3UgYXJlIHRydXN0aW5n IG1vcmUuIEJvdGggWEVOIGFuZCBURUUNCj4gPj4+PiBhcmUgbWluaW1hbCBPUyBpbXBsZW1lbnRh dGlvbnMgd2l0aCBhaW0gYXQgc2VjdXJpdHkuIEknbSBzcGVha2luZw0KPiA+Pj4+IGFib3V0IGdl bmVyaWMgVEVFIE9TLCBub3QgYWJvdXQgcGFydGljdWxhciBPUyBsaWtlIE9QLVRFRSBvciBUcnVz dHkuDQo+ID4+Pj4gUHJvYmxlbSBpcyB0aGF0LCBpZiBURUUgaXMgcnVubmluZyBpbnNpZGUgVk0s IGl0IHdpbGwgYmUNCj4gPj4+PiBzdXNjZXB0aWJsZSB0byBhIGh5cGVydmlzb3IgbWlzYmVoYXZp b3VyLiBZb3UgbmVlZCB0byB1bmRlcnN0YW5kDQo+ID4+Pj4gdGhhdCBYZW4gYW5kIHByaXZpbGVn ZWQgZG9tYWluIChkb20wLCBtb3N0bHkpIGNhbiBhY2Nlc3MgbWVtb3J5IG9mDQo+IGFueSBndWVz dC4NCj4gPj4+PiBBdCBsZWFzdCwgaW4gZGVmYXVsdCBjb25maWd1cmF0aW9uLiBUaGVyZSBhcmUg bWVhbnMgdG8gaGFyZGVuIHRoaXMNCj4gPj4+PiBzZXR1cC4gQnV0IGFueXdheXMsIFhlbiBjYW4n dCBiZSBzdG9wcGVkIGZyb20gcmVhZGluZyBURUUncyBzZWNyZXRzLg0KPiA+Pj4NCj4gPj4+IElJ UkMsIHdlIGRpc2N1c3NlZCB0aGlzIGFwcHJvYWNoIGZvciBPUC1URUUgaW4gdGhlIHBhc3QuIFRo ZXJlIHdhcw0KPiA+Pj4gb3RoZXINCj4gPj4gcG90ZW50aWFsIHBpdGZhbGxzIHdpdGggaXQuIEZv ciBpbnN0YW5jZSwgeW91IHdvdWxkbid0IGJlIGFibGUgdG8NCj4gPj4gZGlyZWN0bHkgYWNjZXNz IGFueSBzZWN1cmUgZGV2aWNlIGZyb20gdGhhdCBndWVzdCAoaXQgaXMgcnVubmluZyBpbg0KPiBu b24tc2VjdXJlIHdvcmxkKS4NCj4gPj4+DQo+ID4+PiBUaGVyZSBhcmUgYWxzbyBpc3N1ZXMgaW4g dGVybSBvZiBsYXRlbmN5IGFzIHlvdSBtYXkgaGF2ZSB0aGUNCj4gPj4+IGZvbGxvd2luZw0KPiA+ PiBtb2RlbDoNCj4gPj4+DQo+ID4+PiBkb21VIC0+IFhlbiAtPiBkb21VIFRFRSAtPiAoWGVuIC0+ IGhvc3QgVEVFIC0+IFhlbiAtPiBkb21VIFRFRSkgLT4NCj4gPj4+IFhlbiAtPg0KPiA+PiBkb21V Lg0KPiA+Pj4NCj4gPj4+IFRoZSBiaXQgaW4gKCkgaXMgaWYgeW91IHJlcXVpcmUgdG8gY2FsbCB0 aGUgaG9zdCBURUUuDQo+ID4+Pg0KPiA+Pj4gT25lIHBvc3NpYmlsaXR5IHdvdWxkIGJlIHRvIHVz ZSBTZWN1cmUtRUwyIGZvciB5b3VyIFRydXN0eSBPUy4gQnV0IEkNCj4gPj4+IGRvbid0DQo+ID4+ IGtub3cgd2hldGhlciB5b3VyIHBsYXRmb3JtIHN1cHBvcnRzIGl0Lg0KPiA+Pj4NCj4gPj4+IERl cGVuZGluZyBvbiB3aGV0aGVyIHlvdSBjYW4gbW9kaWZ5IFRydXN0eSBPUywgYWx0ZXJuYXRpdmUg d291bGQgYmUNCj4gPj4+IHRvDQo+ID4+IG1ha2UgaXR2aXJ0dWFsaXphdGlvbiBhd2FyZSBhcyBP UC1URUUgZGlkLiBUaGUgY29yZSB3b3VsZCBuZWVkIHRvIGJlDQo+ID4+IHJlc2lsaWVudCBhbmQg dGhlIHBhbmljIG9ubHkgYWZmZWN0IGEgZ2l2ZW4gY2xpZW50Lg0KPiA+Pg0KPiA+PiBJIGRvIG5v dCBoYXZlIHJpZ2h0IGEgY2xlYXIgaWRlYSBvZiB3aGF0IGlzIHRoZSBzdGF0dXMgb2Ygb3B0ZWUg YW5kDQo+ID4+IHhlbiBidXQgaW4gdGhlb3J5IEkgd291bGQgc2VlIDIgcG9zc2libGUgd2F5cyB0 byBoYW5kbGUgdGhpczoNCj4gPj4gLSB3aXRob3V0IG9wdGVlIG1vZGlmaWNhdGlvbiwgc29tZXRo aW5nIGluIGEgZ3Vlc3QgKERvbTAgb3IgYW4gb3RoZXINCj4gPj4gcHJpdmlsZWRnZWQgb25lKSBu ZWVkcyB0byBoYXZlIGFjY2VzcyB0byBvcHRlZSBhbmQgZW11bGF0ZSBvcHRlZQ0KPiA+PiBhY2Nl c3MgZm9yIG90aGVycy4NCj4gPj4gLSB3aXRoIG9wdGVlIG1vZGlmaWNhdGlvbnMsIG9wdGVlIG5l ZWRzIHRvIGhhdmUgYSBjb25jZXB0IG9mIGNsaWVudA0KPiA+PiBhbmQgWGVuIHdvdWxkIG5lZWQg dG8gcGFzc3Rocm91Z2ggb3B0ZWUgcmVxdWVzdHMgYnV0IGJlaW5nDQo+ID4+IHJlc3BvbnNpYmxl IG9mIGFkZGluZyBhIOKAnGNsaWVudOKAnSBpZGVudGlmaWVyLiBNYXliZSBhbHNvIGluZm9ybWlu Zw0KPiA+PiBPcHRlZSB3aGVuIGEgbmV3IGNsaWVudCBpcyBjcmVhdGVkL3JlbW92ZWQuDQo+ID4+ DQo+ID4+IFRoZSBzZWNvbmQgc2NlbmFyaW8gY291bGQgdGhlbiBiZSBzb21laG93IHNwbGl0dGVk IGluIHRoZSBwcmV2aW91cw0KPiA+PiBvbmUgZnJvbSBKdWxpZW4gaWYgc29tZSBwYXJ0cyB3b3Vs ZCBuZWVkIHRvIGJlIGVtdWxhdGVkIHNvbWV3aGVyZSBpbg0KPiA+PiBzb21lIGtpbmQgb2YgY29t YmluYXRpb24gb2YgdGhlIDIgbW9kZWxzLg0KPiA+Pg0KPiA+PiBJbiBhbnkgY2FzZSBpIHdvdWxk IGFsd2F5cyBjb25zaWRlciB0aGF0IGFueXRoaW5nIHJ1bm5pbmcgb24gb3B0ZWUNCj4gPj4gKG9y IGluIGdlbmVyYWwgaW4gdGhlIHNlY3VyZSB3b3JsZCkgaXMgbW9yZSB0cnVzdGVkIHRoZW4gWGVu Lg0KPiA+DQo+ID4gT2ssIHRoaXMgbWVhbnMgb3B0ZWUgcnVucyBvbiBhbGwgY29yZXMgaW4gc2Vj dXJlIHdvcmxkLCBidXQgdGhpcyB3b3VsZA0KPiA+IG5vdCB3b3JrIHdoZW4gd2UgbmVlZCB0byBz dXBwb3J0IG11bHRpcGxlIE9TZXMgd2l0aCB0aGVpciBvd24gVEVFLg0KPiANCj4gSSB3b3VsZCB0 aGluayB5b3UgaGF2ZSBvbmUgVEVFIHJ1bm5pbmcgb24gYWxsIGNvcmVzIChvciBydW5uYWJsZSBp biB0aGlzIGNhc2UpLg0KPiBTbyB0aGUgVGVlIG5lZWRzIHRvIGhhbmRsZSBzZXZlcmFsIGNvbnRl eHRzIG9yIHNvbWVvbmUgbmVlZHMgdG8gdmlydHVhbGl6ZSBpdC4NCg0KVGhpcyBiYWNrIHRvIG15 IG9yaWdpbmFsIHF1ZXN0aW9uLCBzaG91bGQgSSB2aXJ0dWFsaXplIFRFRSBpbiBhIFhFTiBkZWRp Y2F0ZWQgVk0/DQpvciBJIG5lZWQgdG8gZW11bGF0ZSBzZWN1cmUgd29ybGQgdG8gbGV0IG9uZSBW TSBjb3VsZCBoYXZlIHNlY3VyZSBhbmQgbm9uLXNlY3VyZQ0Kd29ybGQ/DQoNClRoYW5rcywNClBl bmcuDQoNCj4gDQo+IFJlZ2FyZHMNCj4gQmVydHJhbmQNCg0K From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:12:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:12:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmD4R-0001tE-5A; Fri, 19 Jun 2020 09:12:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmD4P-0001t9-D5 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:12:21 +0000 X-Inumbo-ID: fab31bcc-b20c-11ea-b7bb-bc764e2007e4 Received: from mail-vk1-xa32.google.com (unknown [2607:f8b0:4864:20::a32]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fab31bcc-b20c-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 09:12:20 +0000 (UTC) Received: by mail-vk1-xa32.google.com with SMTP id e1so2127949vkd.1 for ; Fri, 19 Jun 2020 02:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EDENB6gkDBT5GIDa/YNo8xEfnnxfxJftsLe+hfT1MSw=; b=YRyuS+n4RlMOy2cbDXiSTKp4o3y8LUsRdWmwFj6/e+v1XdP/vYwz+nocPQ/728YiCt UBM7+1V1cDgUfcRDw+8LWfppmrsE963EMKM3Hg5SY+6WhjcTcYz9xByiqhxRUDqn3b2I BKsG7ihGde7iaQ4a5K6zgsL6Fz4ayGFB9ClXr6JvKi7q2EBgWlxmmiTfJsTRV3K/6E5/ Y34IxMeyVP88SjAdLwpkH6pZ5BQIRwtYjSnCPvSNz+s7SwHC/0/FWTKKCRpr8DYDGNmy BCXlOlpo5kW17hMelkaThqbQ0zWyqFcaSpfx3z6BRGnEYp5ry1JY7C+9ahgfhegbArA2 bSnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EDENB6gkDBT5GIDa/YNo8xEfnnxfxJftsLe+hfT1MSw=; b=BaOuq/5/cg1BpOnusCP11sT0/TRYBbtBM8FTYykgIS0y+mO7xznN1hyy+m+qXdJdcN kvPdT6EZCkqY0x52NSz2UytJiIQHcX+QWD0+/puuPAVfRqHXBITHHx7Dc098YPi1XDHe ebTwGg1nsEJOOUkgh9KTZSmfAD0jTSEh42A2QEHmCjPL7HS75JTHiBl+4lrksdffdoHW mL9tA/BUYybNf/PVmpk/3m9mXrV2rdx0Xv76Kx9zaj1419HwICRRsUkLVfrfAMayskWH IzzASIXE+/OeFoGASL4+SltUxWJBZI3ltsxIWzdNl/wH7rDOfogDIty3HEJS181hmLWe bCjA== X-Gm-Message-State: AOAM533JuPKwE+JxbBr9ij7+QbsCGyMdJCi1r+mpbxUIYU+KxgTJW09z YiYRK7/TnB41Sg40bAbvbk35BpFQiEAnsbk6YFc= X-Google-Smtp-Source: ABdhPJx4WF9S/bhsMQYcCcMCYEGPbvrlOf44UEED05Jv+R72pRvp4ATcvuk+zSzqiQwkqK3uyt7Hs7nJzo8rFxSSnIk= X-Received: by 2002:a05:6122:2d6:: with SMTP id k22mr6632301vki.89.1592557939967; Fri, 19 Jun 2020 02:12:19 -0700 (PDT) MIME-Version: 1.0 References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> <68572FBC-8AE3-44A4-A815-1A9A7FFFA098@arm.com> In-Reply-To: From: Volodymyr Babchuk Date: Fri, 19 Jun 2020 12:12:08 +0300 Message-ID: Subject: Re: [Tee-dev] TEE with XEN To: Peng Fan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Oleksandr Andrushchenko , Bertrand Marquis , "tee-dev@lists.linaro.org" , Xen-devel , nd , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Peng, On Fri, 19 Jun 2020 at 12:06, Peng Fan wrote: > > > Subject: Re: [Tee-dev] TEE with XEN > > > > > > > > > On 19 Jun 2020, at 09:52, Peng Fan wrote: > > > > > > Hi Bertrand, > > > > > >> Subject: Re: [Tee-dev] TEE with XEN > > >> > > >> Hi, > > >> > > >>> On 18 Jun 2020, at 19:05, Julien Grall wrote: > > >>> > > >>> +Bertrand and Stefano > > >>> > > >>> On 16/06/2020 02:24, Volodymyr Babchuk wrote: > > >>>> Hi Peng, > > >>>> On Mon, 15 Jun 2020 at 05:07, Peng Fan wrote: > > >>>>> > > >>>>> Hi All, > > >>>>> > > >>>>> While enabling trusty os with xen, I took same approach as OP-TEE= , > > >>>>> with OP-TEE running in secure world. But I am also thinking this > > >>>>> might introduce potential issue is that secure world OS > > >>>>> communicate with > > >> DomU. > > >>>>> If there are some misbehavior in secure world OS, it might let XE= N > > >>>>> hypervisor not work proper. > > >>>>> > > >>>>> In my setup, trusty os sometimes panic in secure world, xen will > > >>>>> not able to control the panic core anymore. > > >>> > > >>> May I ask in which case Trusty is panicking? > > >> > > >> In any case, optee should protect itself against this and it should > > >> be considered that optee is more priviledged then Xen. > > >> So if optee is crashing we cannot expect that Xen can recover or fix= it. > > >> > > >> I would more consider this as a bug that optee needs to be robust ag= ainst. > > > > > > ok. I am not using OP-TEE, currently I use google trusty OS. > > > > Sorry i should have been more generic. > > Please read this as =E2=80=9CAnything running in secure world=E2=80=9D,= being optee or trusty. > > > > > > > > I have two OS, Dom0 linux + DomU android auto. > > > > > > DomU android auto needs trusty OS, Dom0 Linux not need that. > > > > But i would guess your Dom0 is more =E2=80=9Ccritical=E2=80=9D then you= r DomU. > > In this case you must make sure that any resource given to your DomU ca= nnot > > affect your Dom0. > > For example: if the DomU is starting a very heavy operation in blocked = in > > trusty, any interrupt for non-secure could be blocked, thus affecting t= he ability > > of your Dom0. > > > > > > > > I not wanna trusty OS for DomU could bring any detect to Dom0 or xen. > > > > > > One more case is if dom0 linux needs OP-TEE, DomU needs google trusty= , > > > how we handle this in one SoC? > > > > You have a shared resource in this case, someone more or as trusted as = the > > clients needs to decide how the resource can be shared. > > In this case could be Dom0 or Xen or Trusty or op-Tee (if i should make= an > > order). > > > > > > > >> > > >>> > > >>>>> > > >>>>> So I am thinking whether we need to emulating secure world in a > > >>>>> XEN VM which is the VM running DomU. Just like what ACRN did to > > >>>>> run trusty os. > > >>>> Well, it depends on whom you are trusting more. Both XEN and TEE > > >>>> are minimal OS implementations with aim at security. I'm speaking > > >>>> about generic TEE OS, not about particular OS like OP-TEE or Trust= y. > > >>>> Problem is that, if TEE is running inside VM, it will be > > >>>> susceptible to a hypervisor misbehaviour. You need to understand > > >>>> that Xen and privileged domain (dom0, mostly) can access memory of > > any guest. > > >>>> At least, in default configuration. There are means to harden this > > >>>> setup. But anyways, Xen can't be stopped from reading TEE's secret= s. > > >>> > > >>> IIRC, we discussed this approach for OP-TEE in the past. There was > > >>> other > > >> potential pitfalls with it. For instance, you wouldn't be able to > > >> directly access any secure device from that guest (it is running in > > non-secure world). > > >>> > > >>> There are also issues in term of latency as you may have the > > >>> following > > >> model: > > >>> > > >>> domU -> Xen -> domU TEE -> (Xen -> host TEE -> Xen -> domU TEE) -> > > >>> Xen -> > > >> domU. > > >>> > > >>> The bit in () is if you require to call the host TEE. > > >>> > > >>> One possibility would be to use Secure-EL2 for your Trusty OS. But = I > > >>> don't > > >> know whether your platform supports it. > > >>> > > >>> Depending on whether you can modify Trusty OS, alternative would be > > >>> to > > >> make itvirtualization aware as OP-TEE did. The core would need to be > > >> resilient and the panic only affect a given client. > > >> > > >> I do not have right a clear idea of what is the status of optee and > > >> xen but in theory I would see 2 possible ways to handle this: > > >> - without optee modification, something in a guest (Dom0 or an other > > >> priviledged one) needs to have access to optee and emulate optee > > >> access for others. > > >> - with optee modifications, optee needs to have a concept of client > > >> and Xen would need to passthrough optee requests but being > > >> responsible of adding a =E2=80=9Cclient=E2=80=9D identifier. Maybe a= lso informing > > >> Optee when a new client is created/removed. > > >> > > >> The second scenario could then be somehow splitted in the previous > > >> one from Julien if some parts would need to be emulated somewhere in > > >> some kind of combination of the 2 models. > > >> > > >> In any case i would always consider that anything running on optee > > >> (or in general in the secure world) is more trusted then Xen. > > > > > > Ok, this means optee runs on all cores in secure world, but this woul= d > > > not work when we need to support multiple OSes with their own TEE. > > > > I would think you have one TEE running on all cores (or runnable in thi= s case). > > So the Tee needs to handle several contexts or someone needs to virtual= ize it. > > This back to my original question, should I virtualize TEE in a XEN dedic= ated VM? > or I need to emulate secure world to let one VM could have secure and non= -secure > world? > Well, I think that the best approach is that we did in the OP-TEE: make Tru= sty virtualization-aware, so it can handle multiple VMs. Things are more funny if you want to use multiple different TEEs (like OP-TEE and Trusty) at the same time. If this is your case, then the best approach is to implem= ent something like para-virtualization in the Secure World. But this would requ= ire quite big efforts, of course. --=20 WBR Volodymyr Babchuk aka lorc [+380976646013] mailto: vlad.babchuk@gmail.com From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:23:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:23:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDEr-0002o9-AY; Fri, 19 Jun 2020 09:23:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDEq-0002o4-Ek for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:23:08 +0000 X-Inumbo-ID: 7c811b6c-b20e-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7c811b6c-b20e-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 09:23:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4L1+2ofd40nD+e0zXmN+kCCWAhLuklnDtMFFkL2Aesg=; b=DGBQNRngAfaSBS6rU9H0dDGWFG QcZn+l2trWP5oMplR3QnOEPgPB6zHeWo3bhCYHk6rBPvqlcx84sp2jc8xI4EJ/NDdBE1BxowQrdKR +xNd5EmWsUsFoGg0QhU+v+QtF6O6LBNncAB9vn68seILvpgn4XoQyFIESSjBByIgkS3w=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDEp-00035H-Cg; Fri, 19 Jun 2020 09:23:07 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jmDEp-0007Ii-5v; Fri, 19 Jun 2020 09:23:07 +0000 Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address To: Volodymyr Babchuk References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> <878sgk2bst.fsf@epam.com> From: Julien Grall Message-ID: <8d2f3475-4191-fa80-f476-e72af73e0559@xen.org> Date: Fri, 19 Jun 2020 10:23:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <878sgk2bst.fsf@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "sstabellini@kernel.org" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/06/2020 00:29, Volodymyr Babchuk wrote: > > Hi Julien, Hi Volodymyr, > > Julien Grall writes: > >> (+Paul) >> >> Hi, >> >> On 18/05/2020 02:53, Volodymyr Babchuk wrote: >>> Trusted Applications use popular approach to determine required size >>> of buffer: client provides a memory reference with the NULL pointer to >>> a buffer. This is so called "Null memory reference". TA updates the >> >> NIT: You use double space after '.' here but all the others use a >> single space. > > Oops, missed that. > >>> reference with the required size and returns it back to client. Then >>> client allocates buffer of needed size and repeats the operation. >>> >>> This behavior is described in TEE Client API Specification, paragraph >>> 3.2.5. Memory References. >> >> From the spec, it is not a clear cut that NULL will always used as >> fetching the required size of an output buffer. In particular, they >> suggest to refer to the protocol. >> >> In your commit message you indirectly point to an example where 0/NULL >> would have a different meaning depending on the flags. This is not >> explained in the TEE Client API Specification. Do you have some >> pointer I could use to check the behavior? > > Well, GP specification describes application interface. It does not > specifies how implementation should handle this internally. Basically, > GP defines functions, data types, macros, etc to be used by CAs and > TAs. But it does not define how exactly call from CA will be delivered > to TA. Implementation is free to use any means as far, as they conform > with rules described in the specification. > > OPTEE's REE<->TEE interface is described in the header files, that I > added to xen (optee_msg.h, optee_rpc_cmd.h,optee_smc.h). But it does not > describe every aspect, unfortunately. Thanks for digging-through! More below. > >>> >>> OP-TEE represents this null memory reference as a TMEM parameter with >>> buf_ptr == NULL. This is the only case when we should allow TMEM >>> buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. >> >> IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer >> at address 0" but with the flag cleared, it would mean "return the >> size". Am I correct? > > Not exactly. This flag does not affect behavior for buffers with address > NULL. In any case, this would not mean "return the size" to > OP-TEE. This is because OP-TEE works as a transport between CA and TA > and it does not assign any meaning to client buffers. But certainly, > null buffer will mean "return the size" for some TAs, as described in > GlobalPlatform specification. Does it mean a guest TA may potentially access address 0? I am asking that because 0 can be a valid host physical address. We are currently carving out 0 from the heap allocator to workaround a bug, but there is no promise this address will be used by the boot allocator and therefore Xen. > Reason why I prohibited buffers without OPTEE_MSG_ATTR_NONCONTIG flag in > the the original patch is that such buffers could span across page > boundary, which is no-go for fragmented p2m. > > But I missed that special case: null buffer without > OPTEE_MSG_ATTR_NONCONTIG flag. As this is a special type of buffer, it > can be allowed with and without said flag. Looking at translate_noncontig(), there is no specific treatment for NULL. So the address will get translated. This is likely to result to an error as usually a guest doesn't have anything mapped at address 0. Did I miss anything? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:41:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:41:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDWQ-0004S2-SZ; Fri, 19 Jun 2020 09:41:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDWQ-0004Rx-72 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:41:18 +0000 X-Inumbo-ID: 05132414-b211-11ea-bb55-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 05132414-b211-11ea-bb55-12813bfff9fa; Fri, 19 Jun 2020 09:41:16 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: pejYoSrGVDLqR9CnO0UKEqpk1WOYG2xC+FvupLtGs6LDD9pedgEYV2N6TAVG+Q4THmvwqACNIH TBzCz+9hBke4BGoleSROoGqw60fuRAuUIlr2HzNmKQnwaxHON4Bw9ObLrgSJsFD4LP16prKogf zZADnGgYgpKKNz71BbqbGUruObbaxb0FKFu4kgsVUF4LK0S8PIXwYS1kmU4MXmU6k9X19PPbso J00FMmKpz/bM3/CVGxU+RIbfe9kTo6Vv8RDdVhBnUc6K7/bVtkewwB7gsEc1O18Dma8zCu3cik 0z0= X-SBRS: 2.7 X-MesageID: 20753374 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,254,1589256000"; d="scan'208";a="20753374" Date: Fri, 19 Jun 2020 10:41:10 +0100 From: Anthony PERARD To: Ian Jackson Subject: Re: [XEN PATCH for-4.14 1/2] tools: Commit autoconf (2.69) output from Debian buster Message-ID: <20200619094110.GA131624@perard.uk.xensource.com> References: <000401d640c9$7b14e760$713eb620$@xen.org> <20200612151931.1083-2-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200612151931.1083-2-ian.jackson@eu.citrix.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Paul Durrant , Nick Rosbrook , Wei Liu , Samuel Thibault Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 12, 2020 at 04:19:30PM +0100, Ian Jackson wrote: > These files are in tree so that people can build (including from git) > without needing recent autotools. > > We should update them periodically. Debian buster has been Debian > stable fopr a while. Our CI is running buster. > > There should be no significant functional change; it's possible that > there are bugfixes to the configure scripts but I have not reviewed > them. > > These files were last changed in > 83c845033dc8bb3a35ae245effb7832b6823174a > libxl: use vchan for QMP access with Linux stubdomain > where a new feature was added. However, that commit contains a lot of > extraneous noise in configure compared to its parent. > > Compared to 83c845033dc8bb3a35ae245effb7832b6823174a~, this commit > restores those extraneous changes, leaving precisely the correct > changes. So one way of looking at the changes we are making now, is > that we are undoing accidental changes to the autoconf output. > > CC: Wei Liu > CC: Nick Rosbrook > Reported-by: Nick Rosbrook > CC: Paul Durrant > Signed-off-by: Ian Jackson FIY, this is the output of autoconf from Debian buster, but it isn't the output of autoconf 2.69. Debian is likely to have patches on top of the latest autoconf release. 2.69 is apparently 8 years old. Anyway: Reviewed-by: Anthony PERARD -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:47:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:47:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDbs-0004cS-Gi; Fri, 19 Jun 2020 09:46:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDbr-0004cN-Fp for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:46:55 +0000 X-Inumbo-ID: ceaabec2-b211-11ea-8496-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ceaabec2-b211-11ea-8496-bc764e2007e4; Fri, 19 Jun 2020 09:46:54 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: iKMzJOQSc6zNQhN9VdxClX4YkACyR7zhiQAZ4KQnPoofTzxRYyfZ1168MHstw//dF2CBcyGRyZ 46JDvqkAfBsVO/4xoGxPF5TeUECfef1Mz11JEmPPPoFTagUOY9gSC0963GZUmzYt0MaiwAJSdL 4b36QSC+MsGG7cDT1HHjaJMOupItuD1p4Af3djGFwToR/R0hlOD+v7HMogCHDYk5B7bNe6+HAp 485DEUBvvRAaCoebNZSxag4HO68ZjiGs2oevoeHQ9upqecEpzfJov++9I1AalXEOKiuJRxPEEj xoY= X-SBRS: 2.7 X-MesageID: 21240923 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,254,1589256000"; d="scan'208";a="21240923" Date: Fri, 19 Jun 2020 10:46:48 +0100 From: Anthony PERARD To: Ian Jackson Subject: Re: [XEN PATCH for-4.14 0/2] tools: Update/reset autogenerated files Message-ID: <20200619094648.GB131624@perard.uk.xensource.com> References: <000401d640c9$7b14e760$713eb620$@xen.org> <20200612151931.1083-1-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200612151931.1083-1-ian.jackson@eu.citrix.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Nick Rosbrook , Samuel Thibault , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 12, 2020 at 04:19:29PM +0100, Ian Jackson wrote: > We commit the output of autogen.sh, and the outputs of flex and bison, > to help people without recent versions of the corresponding tools. > After 4.14 we can perhaps revisit which of these files should be > committed and how they should be managed. FYI, Building Xen requires flex/bison, this is to build Kconfig. Linux upstream stop shipping generated file, so when I updated our version of Kconfig, I didn't try to generate them myself. But I don't know if it needs to be recent versions of flex/bison. -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:50:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:50:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDf8-0005PL-0C; Fri, 19 Jun 2020 09:50:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDf6-0005PF-6M for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:50:16 +0000 X-Inumbo-ID: 4628a464-b212-11ea-b7bb-bc764e2007e4 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [40.107.6.72]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4628a464-b212-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 09:50:14 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S4dLMkFNxqSWpv37LtsKJ/qhLOP+LDKIM6MNVdmNWEJZDpmPRo3Agdg+998vEe8gnM74nWu5E7+vDKvMLVjorTfQdGVRFtrBA5Z+/2MvmPs2s70ycjF39cGTX//fi4w4MY7W1f8jdUlA6PI1orMpWWcqXxXIAKw67/cTWIqoOKsAPMZ15kgTOnXE7mNQK/5C9PUCSmj0Lz9M1tAQ7s/gvmOLLRNf0B8OX29D4r3daMSJZ/vr+DVNt/VOBS/8D+wt18cUN1p8T+Ns58nFdlIuuC9Cox0yMw6kbGWCUQhlG2FDSZXt2XzlcnER7F/m3MAxhB8aUAz5ORgC5/+mGH2Hzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/h++iTraW+qt4pQb47GWRm9tGpZShVGy7Hg/3i6u72E=; b=KpOmhxDk9Jy9q+IjIrma7Cp50VR3rT2Un6xBTplApbB+u5csXFXYfzezHJCx2qfBUuLSEQq7c/uad5TJmpDSz2qI/Yvwg72t0wgGHAcSAEjNEY6LDNoQm1Bf9a8lgba37ac6jm0Wc19tK8S+H/M9f3t5DT+NCuSCv6DfxMDe8EFme7282eBagTMZXZEeniesfCNGIHxb6mPBaeSNe557jiGXN9iQWQskGt/ZkGlEKUxrwgCzaM7pd0Qxh0wrxhQHCjYO4tkenp1zlD/2mv3NvzJgmekRiqw98BI+A8VB0FoICWVlGSclhaSVAFoHga0C5PfHF6sbk2ZvC4paFCqIIQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/h++iTraW+qt4pQb47GWRm9tGpZShVGy7Hg/3i6u72E=; b=SzfHYETBgeep168KxjNi7rpxKlNamE8k+Y9t0q/LEzEd011zCB7hQyX/3Aq4rAl19ww53W3Wl1iEqc9rpjyP7ke2k2hpBHigu4j9kHuhnOcWNKAVETBt5LiWh+JRqWudhHVBeQ++Dampw8lgkd5ZyrqbIF7tMpRWcALM5AsHbio= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2695.eurprd04.prod.outlook.com (2603:10a6:4:95::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Fri, 19 Jun 2020 09:50:13 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3088.028; Fri, 19 Jun 2020 09:50:13 +0000 From: Peng Fan To: Volodymyr Babchuk Subject: RE: [Tee-dev] TEE with XEN Thread-Topic: [Tee-dev] TEE with XEN Thread-Index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQAw/zsAAIeJWwAAHsEHgAAAD3awAABi1QAAADlWUAAAQEIAAAEvDkA= Date: Fri, 19 Jun 2020 09:50:13 +0000 Message-ID: References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> <68572FBC-8AE3-44A4-A815-1A9A7FFFA098@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3e82d9b3-651f-44ce-ff58-08d8143629d5 x-ms-traffictypediagnostic: DB6PR0402MB2695: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: brWPv9O2DSHJcwQVPPmAXqc93nTJ+vMLck3sDxa/6OJs2fBu6xa9O8nzcufFso/S2IOUUVjLciucj9yyYZpc5P3anQ+3u7bjHByGm/B1RQvB8JC6DW+jTh1EIhB4bGo7vqMNEgp3jRwWaXPLwIgyJAlmgp7m6Gad4+BCTjJXFm8OQ/j5C7FgosK1SCiyBHe3nT9nkP0kk/WoxgqS6EjGkp01ecOChHVpgfPSa8Hi25GgJ26cqdY0SYqn1q/rFlOeSbt6XuCUOfz0YMSVvk0ncz1jzjLsUWV2uWN4OPSJjYjyHOhvnweKHFUw3G3mvpdJvzaphvaivypevIRHUk6/cA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(396003)(376002)(136003)(346002)(2906002)(26005)(66946007)(76116006)(66476007)(66556008)(64756008)(33656002)(66446008)(186003)(7696005)(55016002)(9686003)(4326008)(54906003)(5660300002)(316002)(6506007)(71200400001)(478600001)(53546011)(44832011)(52536014)(7416002)(6916009)(8936002)(86362001)(83380400001)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: IVn2dohTg4rgWK/mDY50EAjevzxDiG8EMzXQou7tqo+Ub/o763ifuNREHATOage1ILdqsekEHvNPfJt+bdkJ3Qqt7q5/h+rqLZ0qp52KSEWGSeKMQ+/Q3AAcwo+nJzKcFU2EM3KkAndmjH8eW/VcaZgXv5l2YrOimnqQneEWGlGL1W7aotyfx9GWYAAZJVofZXyIqhHn3phPI8XOCuZM6bjcvFODQu8eC1NB+4zVWTPNVbgl2G0UQXipTnkWIyla+7chmxEEy8pR8CL7tREb0Hk2JutY5HNowOVYyuB5+q7Z7TsmdoexvFYrmNkyp3k+LHqcvNp084fC5vEJQarNgRBceDb+izUURckUenLx4QyuUxWQkhZ5g34bwUjE5tH0dbDxDnJklQ/42HQmCxKkId2HlIUpR7YueGSOKDHY3TQCMHT6BP0ZJ+TZOxudxBto8bO7/uY2cTRLwHUJsdBZ5TzzI/qIHIAQEkdjDufnjqE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e82d9b3-651f-44ce-ff58-08d8143629d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 09:50:13.4795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NGIOEsM8S/luqhkSjIQynYVpUJh9S1LkBMDJKp4qqcG5q2cXGnhNYsxpCJb850FLd0tPr2U5qpolfDCzcx2cmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2695 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Oleksandr Andrushchenko , Bertrand Marquis , "tee-dev@lists.linaro.org" , Xen-devel , nd , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiBTdWJqZWN0OiBSZTogW1RlZS1kZXZdIFRFRSB3aXRoIFhFTg0KPiANCj4gSGkgUGVuZywNCj4g DQo+IE9uIEZyaSwgMTkgSnVuIDIwMjAgYXQgMTI6MDYsIFBlbmcgRmFuIDxwZW5nLmZhbkBueHAu Y29tPiB3cm90ZToNCj4gPg0KPiA+ID4gU3ViamVjdDogUmU6IFtUZWUtZGV2XSBURUUgd2l0aCBY RU4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gT24gMTkgSnVuIDIwMjAsIGF0IDA5OjUy LCBQZW5nIEZhbiA8cGVuZy5mYW5AbnhwLmNvbT4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+IEhp IEJlcnRyYW5kLA0KPiA+ID4gPg0KPiA+ID4gPj4gU3ViamVjdDogUmU6IFtUZWUtZGV2XSBURUUg d2l0aCBYRU4NCj4gPiA+ID4+DQo+ID4gPiA+PiBIaSwNCj4gPiA+ID4+DQo+ID4gPiA+Pj4gT24g MTggSnVuIDIwMjAsIGF0IDE5OjA1LCBKdWxpZW4gR3JhbGwgPGp1bGllbkB4ZW4ub3JnPiB3cm90 ZToNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ICtCZXJ0cmFuZCBhbmQgU3RlZmFubw0KPiA+ID4gPj4+ DQo+ID4gPiA+Pj4gT24gMTYvMDYvMjAyMCAwMjoyNCwgVm9sb2R5bXlyIEJhYmNodWsgd3JvdGU6 DQo+ID4gPiA+Pj4+IEhpIFBlbmcsDQo+ID4gPiA+Pj4+IE9uIE1vbiwgMTUgSnVuIDIwMjAgYXQg MDU6MDcsIFBlbmcgRmFuIDxwZW5nLmZhbkBueHAuY29tPg0KPiB3cm90ZToNCj4gPiA+ID4+Pj4+ DQo+ID4gPiA+Pj4+PiBIaSBBbGwsDQo+ID4gPiA+Pj4+Pg0KPiA+ID4gPj4+Pj4gV2hpbGUgZW5h YmxpbmcgdHJ1c3R5IG9zIHdpdGggeGVuLCBJIHRvb2sgc2FtZSBhcHByb2FjaCBhcw0KPiA+ID4g Pj4+Pj4gT1AtVEVFLCB3aXRoIE9QLVRFRSBydW5uaW5nIGluIHNlY3VyZSB3b3JsZC4gQnV0IEkg YW0gYWxzbw0KPiA+ID4gPj4+Pj4gdGhpbmtpbmcgdGhpcyBtaWdodCBpbnRyb2R1Y2UgcG90ZW50 aWFsIGlzc3VlIGlzIHRoYXQgc2VjdXJlDQo+ID4gPiA+Pj4+PiB3b3JsZCBPUyBjb21tdW5pY2F0 ZSB3aXRoDQo+ID4gPiA+PiBEb21VLg0KPiA+ID4gPj4+Pj4gSWYgdGhlcmUgYXJlIHNvbWUgbWlz YmVoYXZpb3IgaW4gc2VjdXJlIHdvcmxkIE9TLCBpdCBtaWdodCBsZXQNCj4gPiA+ID4+Pj4+IFhF TiBoeXBlcnZpc29yIG5vdCB3b3JrIHByb3Blci4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBJ biBteSBzZXR1cCwgdHJ1c3R5IG9zIHNvbWV0aW1lcyBwYW5pYyBpbiBzZWN1cmUgd29ybGQsIHhl bg0KPiA+ID4gPj4+Pj4gd2lsbCBub3QgYWJsZSB0byBjb250cm9sIHRoZSBwYW5pYyBjb3JlIGFu eW1vcmUuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBNYXkgSSBhc2sgaW4gd2hpY2ggY2FzZSBUcnVz dHkgaXMgcGFuaWNraW5nPw0KPiA+ID4gPj4NCj4gPiA+ID4+IEluIGFueSBjYXNlLCBvcHRlZSBz aG91bGQgcHJvdGVjdCBpdHNlbGYgYWdhaW5zdCB0aGlzIGFuZCBpdA0KPiA+ID4gPj4gc2hvdWxk IGJlIGNvbnNpZGVyZWQgdGhhdCBvcHRlZSBpcyBtb3JlIHByaXZpbGVkZ2VkIHRoZW4gWGVuLg0K PiA+ID4gPj4gU28gaWYgb3B0ZWUgaXMgY3Jhc2hpbmcgd2UgY2Fubm90IGV4cGVjdCB0aGF0IFhl biBjYW4gcmVjb3ZlciBvciBmaXggaXQuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gSSB3b3VsZCBtb3Jl IGNvbnNpZGVyIHRoaXMgYXMgYSBidWcgdGhhdCBvcHRlZSBuZWVkcyB0byBiZSByb2J1c3QNCj4g YWdhaW5zdC4NCj4gPiA+ID4NCj4gPiA+ID4gb2suIEkgYW0gbm90IHVzaW5nIE9QLVRFRSwgY3Vy cmVudGx5IEkgdXNlIGdvb2dsZSB0cnVzdHkgT1MuDQo+ID4gPg0KPiA+ID4gU29ycnkgaSBzaG91 bGQgaGF2ZSBiZWVuIG1vcmUgZ2VuZXJpYy4NCj4gPiA+IFBsZWFzZSByZWFkIHRoaXMgYXMg4oCc QW55dGhpbmcgcnVubmluZyBpbiBzZWN1cmUgd29ybGTigJ0sIGJlaW5nIG9wdGVlIG9yDQo+IHRy dXN0eS4NCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEkgaGF2ZSB0d28gT1MsIERvbTAgbGludXgg KyBEb21VIGFuZHJvaWQgYXV0by4NCj4gPiA+ID4NCj4gPiA+ID4gRG9tVSBhbmRyb2lkIGF1dG8g bmVlZHMgdHJ1c3R5IE9TLCBEb20wIExpbnV4IG5vdCBuZWVkIHRoYXQuDQo+ID4gPg0KPiA+ID4g QnV0IGkgd291bGQgZ3Vlc3MgeW91ciBEb20wIGlzIG1vcmUg4oCcY3JpdGljYWzigJ0gdGhlbiB5 b3VyIERvbVUuDQo+ID4gPiBJbiB0aGlzIGNhc2UgeW91IG11c3QgbWFrZSBzdXJlIHRoYXQgYW55 IHJlc291cmNlIGdpdmVuIHRvIHlvdXIgRG9tVQ0KPiA+ID4gY2Fubm90IGFmZmVjdCB5b3VyIERv bTAuDQo+ID4gPiBGb3IgZXhhbXBsZTogaWYgdGhlIERvbVUgaXMgc3RhcnRpbmcgYSB2ZXJ5IGhl YXZ5IG9wZXJhdGlvbiBpbg0KPiA+ID4gYmxvY2tlZCBpbiB0cnVzdHksIGFueSBpbnRlcnJ1cHQg Zm9yIG5vbi1zZWN1cmUgY291bGQgYmUgYmxvY2tlZCwNCj4gPiA+IHRodXMgYWZmZWN0aW5nIHRo ZSBhYmlsaXR5IG9mIHlvdXIgRG9tMC4NCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEkgbm90IHdh bm5hIHRydXN0eSBPUyBmb3IgRG9tVSBjb3VsZCBicmluZyBhbnkgZGV0ZWN0IHRvIERvbTAgb3Ig eGVuLg0KPiA+ID4gPg0KPiA+ID4gPiBPbmUgbW9yZSBjYXNlIGlzIGlmIGRvbTAgbGludXggbmVl ZHMgT1AtVEVFLCBEb21VIG5lZWRzIGdvb2dsZQ0KPiA+ID4gPiB0cnVzdHksIGhvdyB3ZSBoYW5k bGUgdGhpcyBpbiBvbmUgU29DPw0KPiA+ID4NCj4gPiA+IFlvdSBoYXZlIGEgc2hhcmVkIHJlc291 cmNlIGluIHRoaXMgY2FzZSwgc29tZW9uZSBtb3JlIG9yIGFzIHRydXN0ZWQNCj4gPiA+IGFzIHRo ZSBjbGllbnRzIG5lZWRzIHRvIGRlY2lkZSBob3cgdGhlIHJlc291cmNlIGNhbiBiZSBzaGFyZWQu DQo+ID4gPiBJbiB0aGlzIGNhc2UgY291bGQgYmUgRG9tMCBvciBYZW4gb3IgVHJ1c3R5IG9yIG9w LVRlZSAoaWYgaSBzaG91bGQNCj4gPiA+IG1ha2UgYW4gb3JkZXIpLg0KPiA+ID4NCj4gPiA+ID4N Cj4gPiA+ID4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pj4+DQo+ID4gPiA+Pj4+PiBTbyBJIGFtIHRo aW5raW5nIHdoZXRoZXIgd2UgbmVlZCB0byBlbXVsYXRpbmcgc2VjdXJlIHdvcmxkIGluDQo+ID4g PiA+Pj4+PiBhIFhFTiBWTSB3aGljaCBpcyB0aGUgVk0gcnVubmluZyBEb21VLiBKdXN0IGxpa2Ug d2hhdCBBQ1JOIGRpZA0KPiA+ID4gPj4+Pj4gdG8gcnVuIHRydXN0eSBvcy4NCj4gPiA+ID4+Pj4g V2VsbCwgaXQgZGVwZW5kcyBvbiB3aG9tIHlvdSBhcmUgdHJ1c3RpbmcgbW9yZS4gQm90aCBYRU4g YW5kDQo+ID4gPiA+Pj4+IFRFRSBhcmUgbWluaW1hbCBPUyBpbXBsZW1lbnRhdGlvbnMgd2l0aCBh aW0gYXQgc2VjdXJpdHkuIEknbQ0KPiA+ID4gPj4+PiBzcGVha2luZyBhYm91dCBnZW5lcmljIFRF RSBPUywgbm90IGFib3V0IHBhcnRpY3VsYXIgT1MgbGlrZSBPUC1URUUNCj4gb3IgVHJ1c3R5Lg0K PiA+ID4gPj4+PiBQcm9ibGVtIGlzIHRoYXQsIGlmIFRFRSBpcyBydW5uaW5nIGluc2lkZSBWTSwg aXQgd2lsbCBiZQ0KPiA+ID4gPj4+PiBzdXNjZXB0aWJsZSB0byBhIGh5cGVydmlzb3IgbWlzYmVo YXZpb3VyLiBZb3UgbmVlZCB0bw0KPiA+ID4gPj4+PiB1bmRlcnN0YW5kIHRoYXQgWGVuIGFuZCBw cml2aWxlZ2VkIGRvbWFpbiAoZG9tMCwgbW9zdGx5KSBjYW4NCj4gPiA+ID4+Pj4gYWNjZXNzIG1l bW9yeSBvZg0KPiA+ID4gYW55IGd1ZXN0Lg0KPiA+ID4gPj4+PiBBdCBsZWFzdCwgaW4gZGVmYXVs dCBjb25maWd1cmF0aW9uLiBUaGVyZSBhcmUgbWVhbnMgdG8gaGFyZGVuDQo+ID4gPiA+Pj4+IHRo aXMgc2V0dXAuIEJ1dCBhbnl3YXlzLCBYZW4gY2FuJ3QgYmUgc3RvcHBlZCBmcm9tIHJlYWRpbmcg VEVFJ3MNCj4gc2VjcmV0cy4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IElJUkMsIHdlIGRpc2N1c3Nl ZCB0aGlzIGFwcHJvYWNoIGZvciBPUC1URUUgaW4gdGhlIHBhc3QuIFRoZXJlDQo+ID4gPiA+Pj4g d2FzIG90aGVyDQo+ID4gPiA+PiBwb3RlbnRpYWwgcGl0ZmFsbHMgd2l0aCBpdC4gRm9yIGluc3Rh bmNlLCB5b3Ugd291bGRuJ3QgYmUgYWJsZSB0bw0KPiA+ID4gPj4gZGlyZWN0bHkgYWNjZXNzIGFu eSBzZWN1cmUgZGV2aWNlIGZyb20gdGhhdCBndWVzdCAoaXQgaXMgcnVubmluZw0KPiA+ID4gPj4g aW4NCj4gPiA+IG5vbi1zZWN1cmUgd29ybGQpLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gVGhlcmUg YXJlIGFsc28gaXNzdWVzIGluIHRlcm0gb2YgbGF0ZW5jeSBhcyB5b3UgbWF5IGhhdmUgdGhlDQo+ ID4gPiA+Pj4gZm9sbG93aW5nDQo+ID4gPiA+PiBtb2RlbDoNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+ IGRvbVUgLT4gWGVuIC0+IGRvbVUgVEVFIC0+IChYZW4gLT4gaG9zdCBURUUgLT4gWGVuIC0+IGRv bVUgVEVFKQ0KPiA+ID4gPj4+IC0+IFhlbiAtPg0KPiA+ID4gPj4gZG9tVS4NCj4gPiA+ID4+Pg0K PiA+ID4gPj4+IFRoZSBiaXQgaW4gKCkgaXMgaWYgeW91IHJlcXVpcmUgdG8gY2FsbCB0aGUgaG9z dCBURUUuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBPbmUgcG9zc2liaWxpdHkgd291bGQgYmUgdG8g dXNlIFNlY3VyZS1FTDIgZm9yIHlvdXIgVHJ1c3R5IE9TLg0KPiA+ID4gPj4+IEJ1dCBJIGRvbid0 DQo+ID4gPiA+PiBrbm93IHdoZXRoZXIgeW91ciBwbGF0Zm9ybSBzdXBwb3J0cyBpdC4NCj4gPiA+ ID4+Pg0KPiA+ID4gPj4+IERlcGVuZGluZyBvbiB3aGV0aGVyIHlvdSBjYW4gbW9kaWZ5IFRydXN0 eSBPUywgYWx0ZXJuYXRpdmUgd291bGQNCj4gPiA+ID4+PiBiZSB0bw0KPiA+ID4gPj4gbWFrZSBp dHZpcnR1YWxpemF0aW9uIGF3YXJlIGFzIE9QLVRFRSBkaWQuIFRoZSBjb3JlIHdvdWxkIG5lZWQg dG8NCj4gPiA+ID4+IGJlIHJlc2lsaWVudCBhbmQgdGhlIHBhbmljIG9ubHkgYWZmZWN0IGEgZ2l2 ZW4gY2xpZW50Lg0KPiA+ID4gPj4NCj4gPiA+ID4+IEkgZG8gbm90IGhhdmUgcmlnaHQgYSBjbGVh ciBpZGVhIG9mIHdoYXQgaXMgdGhlIHN0YXR1cyBvZiBvcHRlZQ0KPiA+ID4gPj4gYW5kIHhlbiBi dXQgaW4gdGhlb3J5IEkgd291bGQgc2VlIDIgcG9zc2libGUgd2F5cyB0byBoYW5kbGUgdGhpczoN Cj4gPiA+ID4+IC0gd2l0aG91dCBvcHRlZSBtb2RpZmljYXRpb24sIHNvbWV0aGluZyBpbiBhIGd1 ZXN0IChEb20wIG9yIGFuDQo+ID4gPiA+PiBvdGhlciBwcml2aWxlZGdlZCBvbmUpIG5lZWRzIHRv IGhhdmUgYWNjZXNzIHRvIG9wdGVlIGFuZCBlbXVsYXRlDQo+ID4gPiA+PiBvcHRlZSBhY2Nlc3Mg Zm9yIG90aGVycy4NCj4gPiA+ID4+IC0gd2l0aCBvcHRlZSBtb2RpZmljYXRpb25zLCBvcHRlZSBu ZWVkcyB0byBoYXZlIGEgY29uY2VwdCBvZg0KPiA+ID4gPj4gY2xpZW50IGFuZCBYZW4gd291bGQg bmVlZCB0byBwYXNzdGhyb3VnaCBvcHRlZSByZXF1ZXN0cyBidXQgYmVpbmcNCj4gPiA+ID4+IHJl c3BvbnNpYmxlIG9mIGFkZGluZyBhIOKAnGNsaWVudOKAnSBpZGVudGlmaWVyLiBNYXliZSBhbHNv IGluZm9ybWluZw0KPiA+ID4gPj4gT3B0ZWUgd2hlbiBhIG5ldyBjbGllbnQgaXMgY3JlYXRlZC9y ZW1vdmVkLg0KPiA+ID4gPj4NCj4gPiA+ID4+IFRoZSBzZWNvbmQgc2NlbmFyaW8gY291bGQgdGhl biBiZSBzb21laG93IHNwbGl0dGVkIGluIHRoZQ0KPiA+ID4gPj4gcHJldmlvdXMgb25lIGZyb20g SnVsaWVuIGlmIHNvbWUgcGFydHMgd291bGQgbmVlZCB0byBiZSBlbXVsYXRlZA0KPiA+ID4gPj4g c29tZXdoZXJlIGluIHNvbWUga2luZCBvZiBjb21iaW5hdGlvbiBvZiB0aGUgMiBtb2RlbHMuDQo+ ID4gPiA+Pg0KPiA+ID4gPj4gSW4gYW55IGNhc2UgaSB3b3VsZCBhbHdheXMgY29uc2lkZXIgdGhh dCBhbnl0aGluZyBydW5uaW5nIG9uDQo+ID4gPiA+PiBvcHRlZSAob3IgaW4gZ2VuZXJhbCBpbiB0 aGUgc2VjdXJlIHdvcmxkKSBpcyBtb3JlIHRydXN0ZWQgdGhlbiBYZW4uDQo+ID4gPiA+DQo+ID4g PiA+IE9rLCB0aGlzIG1lYW5zIG9wdGVlIHJ1bnMgb24gYWxsIGNvcmVzIGluIHNlY3VyZSB3b3Js ZCwgYnV0IHRoaXMNCj4gPiA+ID4gd291bGQgbm90IHdvcmsgd2hlbiB3ZSBuZWVkIHRvIHN1cHBv cnQgbXVsdGlwbGUgT1NlcyB3aXRoIHRoZWlyIG93bg0KPiBURUUuDQo+ID4gPg0KPiA+ID4gSSB3 b3VsZCB0aGluayB5b3UgaGF2ZSBvbmUgVEVFIHJ1bm5pbmcgb24gYWxsIGNvcmVzIChvciBydW5u YWJsZSBpbiB0aGlzDQo+IGNhc2UpLg0KPiA+ID4gU28gdGhlIFRlZSBuZWVkcyB0byBoYW5kbGUg c2V2ZXJhbCBjb250ZXh0cyBvciBzb21lb25lIG5lZWRzIHRvDQo+IHZpcnR1YWxpemUgaXQuDQo+ ID4NCj4gPiBUaGlzIGJhY2sgdG8gbXkgb3JpZ2luYWwgcXVlc3Rpb24sIHNob3VsZCBJIHZpcnR1 YWxpemUgVEVFIGluIGEgWEVOIGRlZGljYXRlZA0KPiBWTT8NCj4gPiBvciBJIG5lZWQgdG8gZW11 bGF0ZSBzZWN1cmUgd29ybGQgdG8gbGV0IG9uZSBWTSBjb3VsZCBoYXZlIHNlY3VyZSBhbmQNCj4g PiBub24tc2VjdXJlIHdvcmxkPw0KPiA+DQo+IA0KPiBXZWxsLCBJIHRoaW5rIHRoYXQgdGhlIGJl c3QgYXBwcm9hY2ggaXMgdGhhdCB3ZSBkaWQgaW4gdGhlIE9QLVRFRTogbWFrZSBUcnVzdHkNCj4g dmlydHVhbGl6YXRpb24tYXdhcmUsIHNvIGl0IGNhbiBoYW5kbGUgbXVsdGlwbGUgVk1zLg0KDQpU cnVzdHkgdmlydHVhbGl6YXRpb24tYXdhcmUsIHlvdSBtZWFuIGFuZHJvaWQgTGludXggdHJ1c3R5 IGRyaXZlciBjb21tdW5pY2F0ZQ0Kd2l0aCBPUC1URUUgb3IgZWxzZT8NCg0KPiANCj4gVGhpbmdz IGFyZSBtb3JlIGZ1bm55IGlmIHlvdSB3YW50IHRvIHVzZSBtdWx0aXBsZSBkaWZmZXJlbnQgVEVF cyAobGlrZSBPUC1URUUNCj4gYW5kIFRydXN0eSkgYXQgdGhlIHNhbWUgdGltZS4gSWYgdGhpcyBp cyB5b3VyIGNhc2UsIHRoZW4gdGhlIGJlc3QgYXBwcm9hY2ggaXMgdG8NCj4gaW1wbGVtZW50IHNv bWV0aGluZyBsaWtlIHBhcmEtdmlydHVhbGl6YXRpb24gaW4gdGhlIFNlY3VyZSBXb3JsZC4gQnV0 IHRoaXMNCj4gd291bGQgcmVxdWlyZSBxdWl0ZSBiaWcgZWZmb3J0cywgb2YgY291cnNlLg0KDQpU aGlzIGlzIGp1c3QgYSBicmFpbnN0b3JtIGlkZWEsIEkgbm90IGhhdmUgdGhlIGNhc2UgcmlnaHQg bm93LiBJIGp1c3Qgd2FubmENCmF2b2lkIHRydXN0eSBvcyB0aGF0IG9ubHkgd29yayB3aXRoIGFu ZHJvaWQgYXV0byB2bSBub3QgYnJlYWsgZG9tMCBhbmQNCnhlbi4gDQoNClRoYW5rcywNClBlbmcu DQoNCj4gDQo+IC0tDQo+IFdCUiBWb2xvZHlteXIgQmFiY2h1ayBha2EgbG9yYyBbKzM4MDk3NjY0 NjAxM10NCj4gbWFpbHRvOiB2bGFkLmJhYmNodWtAZ21haWwuY29tDQo= From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:51:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:51:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDgG-0005Ux-FE; Fri, 19 Jun 2020 09:51:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDgF-0005Ur-OE for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:51:27 +0000 X-Inumbo-ID: 712063fa-b212-11ea-bca7-bc764e2007e4 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [40.107.20.64]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 712063fa-b212-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 09:51:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=67N7wh8pm8mWPLGueulx1BLDlYEeFxKYrKUdpBlS9IM=; b=nWzqtrxjrmjNVPlao0npaRQUgTjgQA5/G6nImBMa1uY3C72CJuddOXRm2hXpkNU3f6AQjROKQnPkhsj71iAwCU8O+8XoNIaoLxQ/KqTfTcrHvhgt4hA7BoMnj1Pkww7oSCQy8RdbF7deMfFZB0Hn/rLvXuAfyqoL4cBy7Souu2Y= Received: from AM6P195CA0099.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:86::40) by DB7PR08MB3036.eurprd08.prod.outlook.com (2603:10a6:5:18::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 19 Jun 2020 09:51:24 +0000 Received: from AM5EUR03FT016.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:86:cafe::dd) by AM6P195CA0099.outlook.office365.com (2603:10a6:209:86::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Fri, 19 Jun 2020 09:51:24 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT016.mail.protection.outlook.com (10.152.16.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Fri, 19 Jun 2020 09:51:24 +0000 Received: ("Tessian outbound 68e1a9769289:v59"); Fri, 19 Jun 2020 09:51:24 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 9a41cddaf6276a12 X-CR-MTA-TID: 64aa7808 Received: from 1420850e6021.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D7496F23-2D61-4B01-92DC-985F571FD7B8.1; Fri, 19 Jun 2020 09:51:18 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1420850e6021.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 19 Jun 2020 09:51:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hJtulr51eP/pVJqFnwDfdtqj5zUooD/iFu4huUM78rttb8p2d5/xuRA9y7uC9UTtPG95LY89gGspe9jzBDWRyO/DxIHVrwCiQutB0ldnmTt6HVWZdZzAl5cFOUdjErBMp6lwXB6ym42mufwVxCBCuItzS4KSIAAOEoiXbEhBTi5nss9leX6X5BExwmCwHHrsKgOgh+6sAc0E07NYd4ZGltNiXnhhjrUitTOgsEVj/35DNEqNxEg4NjP2gkWXUH/X4tCmfitKUIpL+hcGzleOfj6oc5LHL/F0e13r/KFxA5GgW0OltpVgCCiXGOt576BUxs/raiPlGXa8Q9Rys2BTIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=67N7wh8pm8mWPLGueulx1BLDlYEeFxKYrKUdpBlS9IM=; b=cdkxXw0OE9o/mtynRD88x3va6tsz31MNvb+UR3s6S033XbgP2ojuAl9tybNGn3SdkvAxJxiA8qsEQAQHGvftJhIMCMub7iacId6lbIHO4fM/gy/DopUnBK7fyMTfUeUtk+GgPtMrjH4hqC3MjUjLplCGUNDm7v2Yx9KlzT8JGhYTMpWThad/grp2JI64GPpzqDstjnV1H/E4GZ/S7Qqo1MJ0H1PUazl2AbVuDB5foRL2/lk+pj1bZRhFnGkT5/3IbgpM3ctx8m5/zvnxFbhnqbyWHeHFvQil5KEwJ/tNyksxouyYcIp2Yg8HC0XNtTih/qu4C0Fl02/PMsXIvocG6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=67N7wh8pm8mWPLGueulx1BLDlYEeFxKYrKUdpBlS9IM=; b=nWzqtrxjrmjNVPlao0npaRQUgTjgQA5/G6nImBMa1uY3C72CJuddOXRm2hXpkNU3f6AQjROKQnPkhsj71iAwCU8O+8XoNIaoLxQ/KqTfTcrHvhgt4hA7BoMnj1Pkww7oSCQy8RdbF7deMfFZB0Hn/rLvXuAfyqoL4cBy7Souu2Y= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3483.eurprd08.prod.outlook.com (2603:10a6:10:4a::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 19 Jun 2020 09:51:17 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 09:51:17 +0000 From: Bertrand Marquis To: Volodymyr Babchuk Subject: Re: [Tee-dev] TEE with XEN Thread-Topic: [Tee-dev] TEE with XEN Thread-Index: AdZCuN8SyGfGPx9hRva/eeajiUtqpQAw/zsAAIeJWwAAHsEHgAAAD3awAABi1QAAADlWUAAAQEIAAAFd4QA= Date: Fri, 19 Jun 2020 09:51:17 +0000 Message-ID: <90E7B0D3-669E-4776-9936-9890E923C5B8@arm.com> References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> <68572FBC-8AE3-44A4-A815-1A9A7FFFA098@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: ed396778-fe63-48ef-9df6-08d814365428 x-ms-traffictypediagnostic: DB7PR08MB3483:|DB7PR08MB3036: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0439571D1D X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: +hgAOPnxg3I1EGPJRQGR5fopY6i999fOajEAYIJxS9DhzCR5Zj3wtEc8/eeQU7JKuElc5fyQXfz/CrcVf0U6yZQo8MentHi1JYDbq3W3yT2Yyyyy0KY+Q9dOwoEsTzmTQUmFPPlZ8Y481hc7DiBCSFmcGfjjIho9kb0iKvPHyP8WGjvGGfz601hXdWqeaWgjErnBfyvMnJnJznBWC3zAvXhnMsopkKf4KCNcnqEK+0hEHE28/pPykuUFZR2uTDgYQE84hdVELKK1DOKj2zKK1I2MwlpRIIiRC0QWN+rUIBrW83jYNbW31QNqTTv+NPsCQf78O+v++fUCGCJGGWWQGA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(396003)(376002)(346002)(366004)(2616005)(66446008)(64756008)(66556008)(4326008)(71200400001)(76116006)(91956017)(478600001)(6486002)(5660300002)(66946007)(66476007)(54906003)(8936002)(26005)(6506007)(53546011)(86362001)(83380400001)(8676002)(36756003)(186003)(2906002)(6916009)(33656002)(316002)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 40kmGwirTJOkAO++lV8IIN6+HMfZUlGJGAUyGyIGXIAmS0Lh8x8anwmGFZ8YA/qqDhqBqwbqrVQvMPSR+0x+2dcGYaVQsW3DZX3rwSXa+HYuOa1z6GnFxEosAsXTHFRAlaahnl0gjkN1gcX6BOmVMQCCOXxrsRaXTAHVjFmBkvbE0kUntkWGBQZ5APgNRSj4Ri6Zg4iRuSVET6XvBQaGaXkg4QDPcSTF9Fuxs10W/kApQcKQmHyPjVIfF1V53m6CFkIg/wzezAM/2MMS5USjtYBXSJ01bY8P02zk+GnFSg4UBcRLJ7ZMXDt/JdPnFYfkg7te6Osal5H8ArEJpJIxWaq85Gvjp9IIloA437g4tyulewkpeDpZg/Pw/2tysHGkeQt7GNwPKd8KK+7NpUdQUkfEiMcGvx4MjXm1HyeAM4l8kjNcKJQHSGsK59GEr5IjKdftjmDOTTEnhW+7dYZvmroAei0FEOYLdUXy1rCkG/S3iH2hrBozoIWiMHYe7gPe x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7A649AC5375C7943B99301BBEEEC080B@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3483 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT016.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(136003)(396003)(346002)(46966005)(6862004)(4326008)(36756003)(83380400001)(86362001)(5660300002)(6486002)(8676002)(2906002)(82310400002)(2616005)(8936002)(356005)(336012)(6506007)(47076004)(81166007)(53546011)(33656002)(70586007)(478600001)(26005)(186003)(6512007)(316002)(36906005)(70206006)(54906003)(82740400003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: dbe80fef-793b-4671-bed2-08d814364fcd X-Forefront-PRVS: 0439571D1D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fcbO1sMoDach/4+L9sIKL+fL/0U462hqWut4l5ncTvuq4qCjfhkKxwbR5oczT6YazOXG3guFheH4Jxg8znxnr3ecucIRVl2l7smHWdxcECXuXmqPWXxMHsEBWjuKqsPB+znhD5qAmbmPADkn6ubFAq0YAw0/iqK/YZ/ULJibA5DJ0bvsrG5GsYN7QahTdUt5B3aVKrxqtokVmsnUmu4mx1ZvIhj17TNOS6bzFsB9/X5CuMcpHzuBz4ZtLY4/lu8Q9+2os+veEdMHif5zrMJ8AGN3aB5JfwnXlz8Nww7VcCsuuCWYIM0aoWacDymBxrL6skgrfJQo3OvIJpmxRJQRveurYPtLJMK4HpA6sMOOllzwyAK1WMjIfilbYIO1pgExngOWsfGg2y6cFFhpb7TTCA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2020 09:51:24.4853 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ed396778-fe63-48ef-9df6-08d814365428 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3036 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peng Fan , Stefano Stabellini , Julien Grall , Oleksandr Andrushchenko , "tee-dev@lists.linaro.org" , Xen-devel , nd , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gMTkgSnVuIDIwMjAsIGF0IDEwOjEyLCBWb2xvZHlteXIgQmFiY2h1ayA8dmxhZC5i YWJjaHVrQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBQZW5nLA0KPiANCj4gT24gRnJpLCAx OSBKdW4gMjAyMCBhdCAxMjowNiwgUGVuZyBGYW4gPHBlbmcuZmFuQG54cC5jb20+IHdyb3RlOg0K Pj4gDQo+Pj4gU3ViamVjdDogUmU6IFtUZWUtZGV2XSBURUUgd2l0aCBYRU4NCj4+PiANCj4+PiAN Cj4+PiANCj4+Pj4gT24gMTkgSnVuIDIwMjAsIGF0IDA5OjUyLCBQZW5nIEZhbiA8cGVuZy5mYW5A bnhwLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBIaSBCZXJ0cmFuZCwNCj4+Pj4gDQo+Pj4+PiBT dWJqZWN0OiBSZTogW1RlZS1kZXZdIFRFRSB3aXRoIFhFTg0KPj4+Pj4gDQo+Pj4+PiBIaSwNCj4+ Pj4+IA0KPj4+Pj4+IE9uIDE4IEp1biAyMDIwLCBhdCAxOTowNSwgSnVsaWVuIEdyYWxsIDxqdWxp ZW5AeGVuLm9yZz4gd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+Pj4gK0JlcnRyYW5kIGFuZCBTdGVmYW5v DQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gMTYvMDYvMjAyMCAwMjoyNCwgVm9sb2R5bXlyIEJhYmNodWsg d3JvdGU6DQo+Pj4+Pj4+IEhpIFBlbmcsDQo+Pj4+Pj4+IE9uIE1vbiwgMTUgSnVuIDIwMjAgYXQg MDU6MDcsIFBlbmcgRmFuIDxwZW5nLmZhbkBueHAuY29tPiB3cm90ZToNCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gSGkgQWxsLA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBXaGlsZSBlbmFibGluZyB0cnVzdHkg b3Mgd2l0aCB4ZW4sIEkgdG9vayBzYW1lIGFwcHJvYWNoIGFzIE9QLVRFRSwNCj4+Pj4+Pj4+IHdp dGggT1AtVEVFIHJ1bm5pbmcgaW4gc2VjdXJlIHdvcmxkLiBCdXQgSSBhbSBhbHNvIHRoaW5raW5n IHRoaXMNCj4+Pj4+Pj4+IG1pZ2h0IGludHJvZHVjZSBwb3RlbnRpYWwgaXNzdWUgaXMgdGhhdCBz ZWN1cmUgd29ybGQgT1MNCj4+Pj4+Pj4+IGNvbW11bmljYXRlIHdpdGgNCj4+Pj4+IERvbVUuDQo+ Pj4+Pj4+PiBJZiB0aGVyZSBhcmUgc29tZSBtaXNiZWhhdmlvciBpbiBzZWN1cmUgd29ybGQgT1Ms IGl0IG1pZ2h0IGxldCBYRU4NCj4+Pj4+Pj4+IGh5cGVydmlzb3Igbm90IHdvcmsgcHJvcGVyLg0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJbiBteSBzZXR1cCwgdHJ1c3R5IG9zIHNvbWV0aW1lcyBwYW5p YyBpbiBzZWN1cmUgd29ybGQsIHhlbiB3aWxsDQo+Pj4+Pj4+PiBub3QgYWJsZSB0byBjb250cm9s IHRoZSBwYW5pYyBjb3JlIGFueW1vcmUuDQo+Pj4+Pj4gDQo+Pj4+Pj4gTWF5IEkgYXNrIGluIHdo aWNoIGNhc2UgVHJ1c3R5IGlzIHBhbmlja2luZz8NCj4+Pj4+IA0KPj4+Pj4gSW4gYW55IGNhc2Us IG9wdGVlIHNob3VsZCBwcm90ZWN0IGl0c2VsZiBhZ2FpbnN0IHRoaXMgYW5kIGl0IHNob3VsZA0K Pj4+Pj4gYmUgY29uc2lkZXJlZCB0aGF0IG9wdGVlIGlzIG1vcmUgcHJpdmlsZWRnZWQgdGhlbiBY ZW4uDQo+Pj4+PiBTbyBpZiBvcHRlZSBpcyBjcmFzaGluZyB3ZSBjYW5ub3QgZXhwZWN0IHRoYXQg WGVuIGNhbiByZWNvdmVyIG9yIGZpeCBpdC4NCj4+Pj4+IA0KPj4+Pj4gSSB3b3VsZCBtb3JlIGNv bnNpZGVyIHRoaXMgYXMgYSBidWcgdGhhdCBvcHRlZSBuZWVkcyB0byBiZSByb2J1c3QgYWdhaW5z dC4NCj4+Pj4gDQo+Pj4+IG9rLiBJIGFtIG5vdCB1c2luZyBPUC1URUUsIGN1cnJlbnRseSBJIHVz ZSBnb29nbGUgdHJ1c3R5IE9TLg0KPj4+IA0KPj4+IFNvcnJ5IGkgc2hvdWxkIGhhdmUgYmVlbiBt b3JlIGdlbmVyaWMuDQo+Pj4gUGxlYXNlIHJlYWQgdGhpcyBhcyDigJxBbnl0aGluZyBydW5uaW5n IGluIHNlY3VyZSB3b3JsZOKAnSwgYmVpbmcgb3B0ZWUgb3IgdHJ1c3R5Lg0KPj4+IA0KPj4+PiAN Cj4+Pj4gSSBoYXZlIHR3byBPUywgRG9tMCBsaW51eCArIERvbVUgYW5kcm9pZCBhdXRvLg0KPj4+ PiANCj4+Pj4gRG9tVSBhbmRyb2lkIGF1dG8gbmVlZHMgdHJ1c3R5IE9TLCBEb20wIExpbnV4IG5v dCBuZWVkIHRoYXQuDQo+Pj4gDQo+Pj4gQnV0IGkgd291bGQgZ3Vlc3MgeW91ciBEb20wIGlzIG1v cmUg4oCcY3JpdGljYWzigJ0gdGhlbiB5b3VyIERvbVUuDQo+Pj4gSW4gdGhpcyBjYXNlIHlvdSBt dXN0IG1ha2Ugc3VyZSB0aGF0IGFueSByZXNvdXJjZSBnaXZlbiB0byB5b3VyIERvbVUgY2Fubm90 DQo+Pj4gYWZmZWN0IHlvdXIgRG9tMC4NCj4+PiBGb3IgZXhhbXBsZTogaWYgdGhlIERvbVUgaXMg c3RhcnRpbmcgYSB2ZXJ5IGhlYXZ5IG9wZXJhdGlvbiBpbiBibG9ja2VkIGluDQo+Pj4gdHJ1c3R5 LCBhbnkgaW50ZXJydXB0IGZvciBub24tc2VjdXJlIGNvdWxkIGJlIGJsb2NrZWQsIHRodXMgYWZm ZWN0aW5nIHRoZSBhYmlsaXR5DQo+Pj4gb2YgeW91ciBEb20wLg0KPj4+IA0KPj4+PiANCj4+Pj4g SSBub3Qgd2FubmEgdHJ1c3R5IE9TIGZvciBEb21VIGNvdWxkIGJyaW5nIGFueSBkZXRlY3QgdG8g RG9tMCBvciB4ZW4uDQo+Pj4+IA0KPj4+PiBPbmUgbW9yZSBjYXNlIGlzIGlmIGRvbTAgbGludXgg bmVlZHMgT1AtVEVFLCBEb21VIG5lZWRzIGdvb2dsZSB0cnVzdHksDQo+Pj4+IGhvdyB3ZSBoYW5k bGUgdGhpcyBpbiBvbmUgU29DPw0KPj4+IA0KPj4+IFlvdSBoYXZlIGEgc2hhcmVkIHJlc291cmNl IGluIHRoaXMgY2FzZSwgc29tZW9uZSBtb3JlIG9yIGFzIHRydXN0ZWQgYXMgdGhlDQo+Pj4gY2xp ZW50cyBuZWVkcyB0byBkZWNpZGUgaG93IHRoZSByZXNvdXJjZSBjYW4gYmUgc2hhcmVkLg0KPj4+ IEluIHRoaXMgY2FzZSBjb3VsZCBiZSBEb20wIG9yIFhlbiBvciBUcnVzdHkgb3Igb3AtVGVlIChp ZiBpIHNob3VsZCBtYWtlIGFuDQo+Pj4gb3JkZXIpLg0KPj4+IA0KPj4+PiANCj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBTbyBJIGFtIHRoaW5raW5nIHdoZXRoZXIgd2UgbmVl ZCB0byBlbXVsYXRpbmcgc2VjdXJlIHdvcmxkIGluIGENCj4+Pj4+Pj4+IFhFTiBWTSB3aGljaCBp cyB0aGUgVk0gcnVubmluZyBEb21VLiBKdXN0IGxpa2Ugd2hhdCBBQ1JOIGRpZCB0bw0KPj4+Pj4+ Pj4gcnVuIHRydXN0eSBvcy4NCj4+Pj4+Pj4gV2VsbCwgaXQgZGVwZW5kcyBvbiB3aG9tIHlvdSBh cmUgdHJ1c3RpbmcgbW9yZS4gQm90aCBYRU4gYW5kIFRFRQ0KPj4+Pj4+PiBhcmUgbWluaW1hbCBP UyBpbXBsZW1lbnRhdGlvbnMgd2l0aCBhaW0gYXQgc2VjdXJpdHkuIEknbSBzcGVha2luZw0KPj4+ Pj4+PiBhYm91dCBnZW5lcmljIFRFRSBPUywgbm90IGFib3V0IHBhcnRpY3VsYXIgT1MgbGlrZSBP UC1URUUgb3IgVHJ1c3R5Lg0KPj4+Pj4+PiBQcm9ibGVtIGlzIHRoYXQsIGlmIFRFRSBpcyBydW5u aW5nIGluc2lkZSBWTSwgaXQgd2lsbCBiZQ0KPj4+Pj4+PiBzdXNjZXB0aWJsZSB0byBhIGh5cGVy dmlzb3IgbWlzYmVoYXZpb3VyLiBZb3UgbmVlZCB0byB1bmRlcnN0YW5kDQo+Pj4+Pj4+IHRoYXQg WGVuIGFuZCBwcml2aWxlZ2VkIGRvbWFpbiAoZG9tMCwgbW9zdGx5KSBjYW4gYWNjZXNzIG1lbW9y eSBvZg0KPj4+IGFueSBndWVzdC4NCj4+Pj4+Pj4gQXQgbGVhc3QsIGluIGRlZmF1bHQgY29uZmln dXJhdGlvbi4gVGhlcmUgYXJlIG1lYW5zIHRvIGhhcmRlbiB0aGlzDQo+Pj4+Pj4+IHNldHVwLiBC dXQgYW55d2F5cywgWGVuIGNhbid0IGJlIHN0b3BwZWQgZnJvbSByZWFkaW5nIFRFRSdzIHNlY3Jl dHMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gSUlSQywgd2UgZGlzY3Vzc2VkIHRoaXMgYXBwcm9hY2ggZm9y IE9QLVRFRSBpbiB0aGUgcGFzdC4gVGhlcmUgd2FzDQo+Pj4+Pj4gb3RoZXINCj4+Pj4+IHBvdGVu dGlhbCBwaXRmYWxscyB3aXRoIGl0LiBGb3IgaW5zdGFuY2UsIHlvdSB3b3VsZG4ndCBiZSBhYmxl IHRvDQo+Pj4+PiBkaXJlY3RseSBhY2Nlc3MgYW55IHNlY3VyZSBkZXZpY2UgZnJvbSB0aGF0IGd1 ZXN0IChpdCBpcyBydW5uaW5nIGluDQo+Pj4gbm9uLXNlY3VyZSB3b3JsZCkuDQo+Pj4+Pj4gDQo+ Pj4+Pj4gVGhlcmUgYXJlIGFsc28gaXNzdWVzIGluIHRlcm0gb2YgbGF0ZW5jeSBhcyB5b3UgbWF5 IGhhdmUgdGhlDQo+Pj4+Pj4gZm9sbG93aW5nDQo+Pj4+PiBtb2RlbDoNCj4+Pj4+PiANCj4+Pj4+ PiBkb21VIC0+IFhlbiAtPiBkb21VIFRFRSAtPiAoWGVuIC0+IGhvc3QgVEVFIC0+IFhlbiAtPiBk b21VIFRFRSkgLT4NCj4+Pj4+PiBYZW4gLT4NCj4+Pj4+IGRvbVUuDQo+Pj4+Pj4gDQo+Pj4+Pj4g VGhlIGJpdCBpbiAoKSBpcyBpZiB5b3UgcmVxdWlyZSB0byBjYWxsIHRoZSBob3N0IFRFRS4NCj4+ Pj4+PiANCj4+Pj4+PiBPbmUgcG9zc2liaWxpdHkgd291bGQgYmUgdG8gdXNlIFNlY3VyZS1FTDIg Zm9yIHlvdXIgVHJ1c3R5IE9TLiBCdXQgSQ0KPj4+Pj4+IGRvbid0DQo+Pj4+PiBrbm93IHdoZXRo ZXIgeW91ciBwbGF0Zm9ybSBzdXBwb3J0cyBpdC4NCj4+Pj4+PiANCj4+Pj4+PiBEZXBlbmRpbmcg b24gd2hldGhlciB5b3UgY2FuIG1vZGlmeSBUcnVzdHkgT1MsIGFsdGVybmF0aXZlIHdvdWxkIGJl DQo+Pj4+Pj4gdG8NCj4+Pj4+IG1ha2UgaXR2aXJ0dWFsaXphdGlvbiBhd2FyZSBhcyBPUC1URUUg ZGlkLiBUaGUgY29yZSB3b3VsZCBuZWVkIHRvIGJlDQo+Pj4+PiByZXNpbGllbnQgYW5kIHRoZSBw YW5pYyBvbmx5IGFmZmVjdCBhIGdpdmVuIGNsaWVudC4NCj4+Pj4+IA0KPj4+Pj4gSSBkbyBub3Qg aGF2ZSByaWdodCBhIGNsZWFyIGlkZWEgb2Ygd2hhdCBpcyB0aGUgc3RhdHVzIG9mIG9wdGVlIGFu ZA0KPj4+Pj4geGVuIGJ1dCBpbiB0aGVvcnkgSSB3b3VsZCBzZWUgMiBwb3NzaWJsZSB3YXlzIHRv IGhhbmRsZSB0aGlzOg0KPj4+Pj4gLSB3aXRob3V0IG9wdGVlIG1vZGlmaWNhdGlvbiwgc29tZXRo aW5nIGluIGEgZ3Vlc3QgKERvbTAgb3IgYW4gb3RoZXINCj4+Pj4+IHByaXZpbGVkZ2VkIG9uZSkg bmVlZHMgdG8gaGF2ZSBhY2Nlc3MgdG8gb3B0ZWUgYW5kIGVtdWxhdGUgb3B0ZWUNCj4+Pj4+IGFj Y2VzcyBmb3Igb3RoZXJzLg0KPj4+Pj4gLSB3aXRoIG9wdGVlIG1vZGlmaWNhdGlvbnMsIG9wdGVl IG5lZWRzIHRvIGhhdmUgYSBjb25jZXB0IG9mIGNsaWVudA0KPj4+Pj4gYW5kIFhlbiB3b3VsZCBu ZWVkIHRvIHBhc3N0aHJvdWdoIG9wdGVlIHJlcXVlc3RzIGJ1dCBiZWluZw0KPj4+Pj4gcmVzcG9u c2libGUgb2YgYWRkaW5nIGEg4oCcY2xpZW504oCdIGlkZW50aWZpZXIuIE1heWJlIGFsc28gaW5m b3JtaW5nDQo+Pj4+PiBPcHRlZSB3aGVuIGEgbmV3IGNsaWVudCBpcyBjcmVhdGVkL3JlbW92ZWQu DQo+Pj4+PiANCj4+Pj4+IFRoZSBzZWNvbmQgc2NlbmFyaW8gY291bGQgdGhlbiBiZSBzb21laG93 IHNwbGl0dGVkIGluIHRoZSBwcmV2aW91cw0KPj4+Pj4gb25lIGZyb20gSnVsaWVuIGlmIHNvbWUg cGFydHMgd291bGQgbmVlZCB0byBiZSBlbXVsYXRlZCBzb21ld2hlcmUgaW4NCj4+Pj4+IHNvbWUg a2luZCBvZiBjb21iaW5hdGlvbiBvZiB0aGUgMiBtb2RlbHMuDQo+Pj4+PiANCj4+Pj4+IEluIGFu eSBjYXNlIGkgd291bGQgYWx3YXlzIGNvbnNpZGVyIHRoYXQgYW55dGhpbmcgcnVubmluZyBvbiBv cHRlZQ0KPj4+Pj4gKG9yIGluIGdlbmVyYWwgaW4gdGhlIHNlY3VyZSB3b3JsZCkgaXMgbW9yZSB0 cnVzdGVkIHRoZW4gWGVuLg0KPj4+PiANCj4+Pj4gT2ssIHRoaXMgbWVhbnMgb3B0ZWUgcnVucyBv biBhbGwgY29yZXMgaW4gc2VjdXJlIHdvcmxkLCBidXQgdGhpcyB3b3VsZA0KPj4+PiBub3Qgd29y ayB3aGVuIHdlIG5lZWQgdG8gc3VwcG9ydCBtdWx0aXBsZSBPU2VzIHdpdGggdGhlaXIgb3duIFRF RS4NCj4+PiANCj4+PiBJIHdvdWxkIHRoaW5rIHlvdSBoYXZlIG9uZSBURUUgcnVubmluZyBvbiBh bGwgY29yZXMgKG9yIHJ1bm5hYmxlIGluIHRoaXMgY2FzZSkuDQo+Pj4gU28gdGhlIFRlZSBuZWVk cyB0byBoYW5kbGUgc2V2ZXJhbCBjb250ZXh0cyBvciBzb21lb25lIG5lZWRzIHRvIHZpcnR1YWxp emUgaXQuDQo+PiANCj4+IFRoaXMgYmFjayB0byBteSBvcmlnaW5hbCBxdWVzdGlvbiwgc2hvdWxk IEkgdmlydHVhbGl6ZSBURUUgaW4gYSBYRU4gZGVkaWNhdGVkIFZNPw0KPj4gb3IgSSBuZWVkIHRv IGVtdWxhdGUgc2VjdXJlIHdvcmxkIHRvIGxldCBvbmUgVk0gY291bGQgaGF2ZSBzZWN1cmUgYW5k IG5vbi1zZWN1cmUNCj4+IHdvcmxkPw0KPj4gDQo+IA0KPiBXZWxsLCBJIHRoaW5rIHRoYXQgdGhl IGJlc3QgYXBwcm9hY2ggaXMgdGhhdCB3ZSBkaWQgaW4gdGhlIE9QLVRFRTogbWFrZSBUcnVzdHkN Cj4gdmlydHVhbGl6YXRpb24tYXdhcmUsIHNvIGl0IGNhbiBoYW5kbGUgbXVsdGlwbGUgVk1zLg0K PiANCj4gVGhpbmdzIGFyZSBtb3JlIGZ1bm55IGlmIHlvdSB3YW50IHRvIHVzZSBtdWx0aXBsZSBk aWZmZXJlbnQgVEVFcyAobGlrZQ0KPiBPUC1URUUgYW5kIFRydXN0eSkNCj4gYXQgdGhlIHNhbWUg dGltZS4gSWYgdGhpcyBpcyB5b3VyIGNhc2UsIHRoZW4gdGhlIGJlc3QgYXBwcm9hY2ggaXMgdG8g aW1wbGVtZW50DQo+IHNvbWV0aGluZyBsaWtlIHBhcmEtdmlydHVhbGl6YXRpb24gaW4gdGhlIFNl Y3VyZSBXb3JsZC4gQnV0IHRoaXMgd291bGQgcmVxdWlyZQ0KPiBxdWl0ZSBiaWcgZWZmb3J0cywg b2YgY291cnNlLg0KDQpJIGFncmVlIHRoaXMgaXMgdGhlIGJlc3QgYXBwcm9hY2ggdG8gbWFrZSBz ZWN1cmUgd29ybGQgaGFuZGxlIHNldmVyYWwgY2xpZW50cy4NCkJ1dCBpdCBtaWdodCBiZSB0aGUg bW9zdCBjb21wbGV4IG9uZSB0aG91Z2guDQoNClVzaW5nIGEgVk0gZm9yIGl0IG1pZ2h0IGJlIGVh c2llciBidXQgeW91IG5lZWQgdG8gY2hlY2sgdGhhdCBpdCBhY2hpZXZpbmcgdGhlIGxldmVsIG9m IHRydXN0IHRoYXQgeW91IG5lZWQuDQpZb3UgY291bGQgaGF2ZSBhIFZNIGFjdGluZyBhcyBhIG11 eGVyL2NoZWNrZXIgYW5kIHBhc3NpbmcgZG93biByZXF1ZXN0cyB0byB0aGUgc2VjdXJlIHdvcmxk DQoNClRoZSBkZWZpbml0aXZlIGFuc3dlciByZWFsbHkgZGVwZW5kcyBvbiB0aGUgYW1vdW50IG9m IGVmZm9ydCwgdGhlIGxldmVsIG9mIHNlY3VyaXR5IGFuZCB5b3VyIGdlbmVyYWwgc3lzdGVtIG5l ZWRzLg0KDQpCZXJ0cmFuZA0KDQo= From xen-devel-bounces@lists.xenproject.org Fri Jun 19 09:52:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 09:52:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDhY-0005bO-Qe; Fri, 19 Jun 2020 09:52:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmDhY-0005bJ-CH for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 09:52:48 +0000 X-Inumbo-ID: a0d176fc-b212-11ea-b7bb-bc764e2007e4 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.50]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a0d176fc-b212-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 09:52:47 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W38mVwoQgw6tlH2M9eISPcmDD8zzMh1+K3aEPRWODi5lN3WhbHj1FbiJH2hI9hDK/WIevVp2pCG0u77GYiwVh4dH1rbi7U/aOdhE9qHPymmKXBO0p6SGKaQa8uOQzvZfpx4DeCxU3pq3eIbpiRpsp1okDRb4ATTMOi9v0UMchQkT+8PHmWT+c8TpDig1PzDyL/dGdhz0JBAXnE5sYOTDUXik7fywXPOT1wCRsiGmOS3X6/z3XHJzMqxCqebH8Kx8aQNM3ivOR2so1LdIFo3r7kBJLriWM9FCcZaufDoZsrFZ4rjhtEw57IaxD0tDwBkWxP35wTiVK0oWpa1ngb36xQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nSAIFLl/JBZVYKwQ11W2i/ROCM2BixfB8A+9m3RJ5+8=; b=HrhTySdye83u1NJuUIszlgs/dcSaG30Cw8wdX1dTiIXzIyoXpffSmLE+1NC8ASJ/0jIimkH5ixAqgyppQwciaaCVm8ZGV49SHAwZhIjt/k3+t2TidAhbcaf+aTGIm8TG4B1EKe2ROU+JKF/AxjSoLBlcXWTcBwWu2LNsgxAgndyWPNHSPL4odsH0iFHML8sta2LUIIwGHT5IRZhxItwboEPYjVn9mQhEsT2fTxDlAqPJ1MrivxStaw308qEiPq+lDzseBYScJYAmVsnOPcjGrMIw89ZF08HTy0gpF9k5T5RSv0k2QWJnAsUNrN+584atTPwK7GQN+heNRFiqo1jjKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nSAIFLl/JBZVYKwQ11W2i/ROCM2BixfB8A+9m3RJ5+8=; b=Xyq4fYGNAmBI/D2DxYdX8mDk3t7lnwpCh+EDZYs0z8JUxXyECS4q1dX3IqvA1oYbZrxkbQo6fX0OEdJhMHDsjqUbf1I4JY0Z8W9DqhYYKvES9LJCmpJitTg0oj7/2MtzisTiCQMSejhN3fIbjfjzAUmAVrbqsCEdcnG9/oR63mifb59TBdrZdjoho/Su5M0yIGkuhn4c3tky7dk6ORchEgDttuJOwYI2YrAo0nnmxYoVAgN+eCPbHfrU8BN9LvEIGHEW+FpXUr/n7IMjykK0JGL8xKXzrlYl57i4hnIp9wRYo+wdGJeeoebvdu8tqq53GiGZMXhh2qS/FMM+hWJT4Q== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB5023.eurprd03.prod.outlook.com (2603:10a6:803:c4::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 19 Jun 2020 09:52:45 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3109.023; Fri, 19 Jun 2020 09:52:45 +0000 From: Volodymyr Babchuk To: Julien Grall Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address Thread-Topic: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address Thread-Index: AQHWLLcTxhZtogukPEOG78aedSZTLajL0lyAgBNkugCAAKX1gIAACEgA Date: Fri, 19 Jun 2020 09:52:45 +0000 Message-ID: <87h7v71ixf.fsf@epam.com> References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> <878sgk2bst.fsf@epam.com> <8d2f3475-4191-fa80-f476-e72af73e0559@xen.org> In-Reply-To: <8d2f3475-4191-fa80-f476-e72af73e0559@xen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.4.10; emacs 26.3 authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a02c990-516f-4b71-cf56-08d81436846d x-ms-traffictypediagnostic: VI1PR03MB5023: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qwLUBnet2SRaUr+IqS7AoMgldV6RdpR1/ofP19qWg4VUp6Qs+sKtrisgV7zz9yDrPflOQJVF+sFfN9hKbIPmaf31vHbnPv0miobIbUXcfVW5lDlB/livBMI6G//hNvfZZt1w9Cbfix2VedtZ4BWjtkxP4dkYZ4qz2embBhRTw7hAlDRThBFw8L4UIIbxl+9EdAbLzjsePZ1SnzvY298KCFgWU4jFgcHrQTxcDZcfNFS67N5Z7ExUeGRS+nJiFLq34Li/PLb4QAyqS3NT9Dai1iDI45KxoJToNR6vAUxj4RX/Z7q0hqKKHUk0w2VRL49xQRxslQQjU5E1u2jU8jdTQQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(376002)(136003)(39860400002)(366004)(478600001)(76116006)(91956017)(66946007)(66476007)(6916009)(2616005)(36756003)(8676002)(86362001)(66446008)(64756008)(66556008)(71200400001)(8936002)(83380400001)(26005)(316002)(186003)(6486002)(55236004)(6506007)(53546011)(2906002)(5660300002)(6512007)(4326008)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: u3BK5SjlxmiETqjUPna0dUVXUYeDxAUkMQJPPsdfNGqAMIvpgjcimCS6uXKYyyGChq8BVc/nia97/5DoeIOevC6lwkJyZVFGXem3J+VR2Iojv1Um4k7hVvupCDqsKwzpaNrUU7psRBVKyMI8ULKzAy6QZK15LD89LYlBdzZOU7nSDnOISpYJvBNZ9o+bs7+fEs7TiiqmaavbQMRdtZtOZ+cDSGiTNTzHwzeBA5BkJhQOLvu8d5B32PHZJMkRHcigodOjosZ8y9bPlB/lD8VEMP3F6/xR89Ve4J9ZbUm4VVqu6Sin4KBrD2dTUhuKBUv2cCyGE9zr3UDzf7gd5MBXlFtwELVLcyOfBeghexNWZ2BhMnRvwXMdy8JzZRVOeUwmAJJKvvao8tG/f0qqRSgrF3IbfHb8wZ7AMxssYJj1VVJJ8pO0669xYW/IVSKvqhFBGyDJR4+W68xxAOG4H97x/uZIYhH4W/7wutUop/uVdLw= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a02c990-516f-4b71-cf56-08d81436846d X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 09:52:45.5013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zwO+Fq8k7nTxx/ua6AOmw6cPPzqNL8UNf9KOefaX0GoYMkVj59Gip9iW20yqcGCBr8zDWPKkKCLvjsIBFU7pf/ykDGmGPSLo+2aWbNjwyvU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB5023 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "sstabellini@kernel.org" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Julien Grall writes: > On 19/06/2020 00:29, Volodymyr Babchuk wrote: >> >> Hi Julien, > > Hi Volodymyr, > >> >> Julien Grall writes: >> >>> (+Paul) >>> >>> Hi, >>> >>> On 18/05/2020 02:53, Volodymyr Babchuk wrote: >>>> Trusted Applications use popular approach to determine required size >>>> of buffer: client provides a memory reference with the NULL pointer to >>>> a buffer. This is so called "Null memory reference". TA updates the >>> >>> NIT: You use double space after '.' here but all the others use a >>> single space. >> >> Oops, missed that. >> >>>> reference with the required size and returns it back to client. Then >>>> client allocates buffer of needed size and repeats the operation. >>>> >>>> This behavior is described in TEE Client API Specification, paragraph >>>> 3.2.5. Memory References. >>> >>> From the spec, it is not a clear cut that NULL will always used as >>> fetching the required size of an output buffer. In particular, they >>> suggest to refer to the protocol. >>> >>> In your commit message you indirectly point to an example where 0/NULL >>> would have a different meaning depending on the flags. This is not >>> explained in the TEE Client API Specification. Do you have some >>> pointer I could use to check the behavior? >> >> Well, GP specification describes application interface. It does not >> specifies how implementation should handle this internally. Basically, >> GP defines functions, data types, macros, etc to be used by CAs and >> TAs. But it does not define how exactly call from CA will be delivered >> to TA. Implementation is free to use any means as far, as they conform >> with rules described in the specification. >> >> OPTEE's REE<->TEE interface is described in the header files, that I >> added to xen (optee_msg.h, optee_rpc_cmd.h,optee_smc.h). But it does not >> describe every aspect, unfortunately. > > Thanks for digging-through! More below. > >> >>>> >>>> OP-TEE represents this null memory reference as a TMEM parameter with >>>> buf_ptr =3D=3D NULL. This is the only case when we should allow TMEM >>>> buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. >>> >>> IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer >>> at address 0" but with the flag cleared, it would mean "return the >>> size". Am I correct? >> >> Not exactly. This flag does not affect behavior for buffers with address >> NULL. In any case, this would not mean "return the size" to >> OP-TEE. This is because OP-TEE works as a transport between CA and TA >> and it does not assign any meaning to client buffers. But certainly, >> null buffer will mean "return the size" for some TAs, as described in >> GlobalPlatform specification. > > Does it mean a guest TA may potentially access address 0? TA is running in S-EL0. That buffer with PA=3D0x0 will be not mapped in TA address space at all. So, if TA will try to access address 0, it will be terminated with data abort. > I am asking that because 0 can be a valid host physical address. We > are currently carving out 0 from the heap allocator to workaround a > bug, but there is no promise this address will be used by the boot > allocator and therefore Xen. > Well, this is a potential issue in OP-TEE. It does not treat 0 as a valid address. So, in that rare case, when REE will try to use 0 as a correct address for data buffer, OP-TEE will not map it into TA address space, instead it will pass NULL to TA, so TA will think that no buffer was provided. >> Reason why I prohibited buffers without OPTEE_MSG_ATTR_NONCONTIG flag in >> the the original patch is that such buffers could span across page >> boundary, which is no-go for fragmented p2m. >> >> But I missed that special case: null buffer without >> OPTEE_MSG_ATTR_NONCONTIG flag. As this is a special type of buffer, it >> can be allowed with and without said flag. > > Looking at translate_noncontig(), there is no specific treatment for > NULL. So the address will get translated. This is likely to result to > an error as usually a guest doesn't have anything mapped at address 0. Yes, you are right. Right now, optee client driver will not emit buffer wit OPTEE_MSG_ATTR_NONCONTIG and address 0. But this is possible. And this should be handled correctly. I'll add fix for that. Today, as well. Thanks for pointing this out. --=20 Volodymyr Babchuk at EPAM= From xen-devel-bounces@lists.xenproject.org Fri Jun 19 10:12:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 10:12:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmE0H-0007O9-Ik; Fri, 19 Jun 2020 10:12:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmE0G-0007O4-C5 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 10:12:08 +0000 X-Inumbo-ID: 54b87ce0-b215-11ea-b7bb-bc764e2007e4 Received: from mail-vs1-xe44.google.com (unknown [2607:f8b0:4864:20::e44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 54b87ce0-b215-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 10:12:07 +0000 (UTC) Received: by mail-vs1-xe44.google.com with SMTP id r11so5284039vsj.5 for ; Fri, 19 Jun 2020 03:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yvaN1qxUPGSdWMwKU0Ou8hlse2UJHRAHTqFMZkg1nwg=; b=qiOUUnINsjdjcCih4F5FnZCvgRihsgtEpkhbroFd/X1YhkiAIogQTZhTpYH0XQXaA3 PicJDmNtcCJ5oeHPZZ9uPak0Lt7mwCPrkUdoBYbsMeuVLKuVRlAv8UQnpt5rhjjIMd/U 0u4BkjN4LVWkQDHqbSWhgqb3c0iS6SNQOYzRqB4e2uJKFQ6Wau5xbXcSfDvmMKSUpRtq YEQmHDy665Yq0JECRiC2kzsBCqPGoa6ErQZRIhHC8PXL/aTB7zUr+PG49qP56FgawPD7 Mb6kXKdDAuV/YNEDfnxknfT3v1pa+yCaVB59s91AwRIyjrC5P7FCchTRkMyPvY0Xx80I iPcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yvaN1qxUPGSdWMwKU0Ou8hlse2UJHRAHTqFMZkg1nwg=; b=ceQrbk4wvCdlRH21ISFETX2p1PvEZNzmu/zmRhHuMOnPrWblmol4AAXeWGjKkZpDI6 AZTvfZLci4Dt8CzjhANo07cjyO6upFW4HrP7R4l3A5TM/Cj0buvBZgcbQYOBKa/jqOQQ 6S5cUqKsIqjzrAitBWahIghe0RvybfIUMVnbLedfJgWEsBenrBvKHQofQAGUjOxfhCwM dbYNgwIQ3zQHWkOOigI/vRQNJf3a8QOHuLg1O7hguymou7vYOPkJxkXVzgZwrgxWN8XK ZJ0SJOQA/06R9qUyUGup2DgAYteX8FjxrQT9nbidTxs3dUGCyrg+kMyQSMJ3Ptg77keY k4OA== X-Gm-Message-State: AOAM533wwRucbw252Y5NmKh6apzjM2ldwUDExy0DtTGjprVexkHJQT4W +Wf0Z0aOpOBCIDd4Zc1TRJz7rckP5DT7HRjCwjA= X-Google-Smtp-Source: ABdhPJw6u9WruL/fd3NvdDc62ui/4aydu3pFohNcipHa+lsJF9RtXXXB6qYqrqe07npNuspcoqTea0xGgck3ETxODRA= X-Received: by 2002:a67:e451:: with SMTP id n17mr6942925vsm.238.1592561526885; Fri, 19 Jun 2020 03:12:06 -0700 (PDT) MIME-Version: 1.0 References: <8a6ba53e-59c8-0c18-00e9-2902b6edaf39@xen.org> <68572FBC-8AE3-44A4-A815-1A9A7FFFA098@arm.com> In-Reply-To: From: Volodymyr Babchuk Date: Fri, 19 Jun 2020 13:11:55 +0300 Message-ID: Subject: Re: [Tee-dev] TEE with XEN To: Peng Fan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Oleksandr Andrushchenko , Bertrand Marquis , "tee-dev@lists.linaro.org" , Xen-devel , nd , Jens Wiklander , Stefano Babic Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 19 Jun 2020 at 12:50, Peng Fan wrote: > > > Subject: Re: [Tee-dev] TEE with XEN > > > > Hi Peng, > > > > On Fri, 19 Jun 2020 at 12:06, Peng Fan wrote: > > > > > > > Subject: Re: [Tee-dev] TEE with XEN > > > > > > > > > > > > > > > > > On 19 Jun 2020, at 09:52, Peng Fan wrote: > > > > > > > > > > Hi Bertrand, > > > > > > > > > >> Subject: Re: [Tee-dev] TEE with XEN > > > > >> > > > > >> Hi, > > > > >> > > > > >>> On 18 Jun 2020, at 19:05, Julien Grall wrote: > > > > >>> > > > > >>> +Bertrand and Stefano > > > > >>> > > > > >>> On 16/06/2020 02:24, Volodymyr Babchuk wrote: > > > > >>>> Hi Peng, > > > > >>>> On Mon, 15 Jun 2020 at 05:07, Peng Fan > > wrote: > > > > >>>>> > > > > >>>>> Hi All, > > > > >>>>> > > > > >>>>> While enabling trusty os with xen, I took same approach as > > > > >>>>> OP-TEE, with OP-TEE running in secure world. But I am also > > > > >>>>> thinking this might introduce potential issue is that secure > > > > >>>>> world OS communicate with > > > > >> DomU. > > > > >>>>> If there are some misbehavior in secure world OS, it might le= t > > > > >>>>> XEN hypervisor not work proper. > > > > >>>>> > > > > >>>>> In my setup, trusty os sometimes panic in secure world, xen > > > > >>>>> will not able to control the panic core anymore. > > > > >>> > > > > >>> May I ask in which case Trusty is panicking? > > > > >> > > > > >> In any case, optee should protect itself against this and it > > > > >> should be considered that optee is more priviledged then Xen. > > > > >> So if optee is crashing we cannot expect that Xen can recover or= fix it. > > > > >> > > > > >> I would more consider this as a bug that optee needs to be robus= t > > against. > > > > > > > > > > ok. I am not using OP-TEE, currently I use google trusty OS. > > > > > > > > Sorry i should have been more generic. > > > > Please read this as =E2=80=9CAnything running in secure world=E2=80= =9D, being optee or > > trusty. > > > > > > > > > > > > > > I have two OS, Dom0 linux + DomU android auto. > > > > > > > > > > DomU android auto needs trusty OS, Dom0 Linux not need that. > > > > > > > > But i would guess your Dom0 is more =E2=80=9Ccritical=E2=80=9D then= your DomU. > > > > In this case you must make sure that any resource given to your Dom= U > > > > cannot affect your Dom0. > > > > For example: if the DomU is starting a very heavy operation in > > > > blocked in trusty, any interrupt for non-secure could be blocked, > > > > thus affecting the ability of your Dom0. > > > > > > > > > > > > > > I not wanna trusty OS for DomU could bring any detect to Dom0 or = xen. > > > > > > > > > > One more case is if dom0 linux needs OP-TEE, DomU needs google > > > > > trusty, how we handle this in one SoC? > > > > > > > > You have a shared resource in this case, someone more or as trusted > > > > as the clients needs to decide how the resource can be shared. > > > > In this case could be Dom0 or Xen or Trusty or op-Tee (if i should > > > > make an order). > > > > > > > > > > > > > >> > > > > >>> > > > > >>>>> > > > > >>>>> So I am thinking whether we need to emulating secure world in > > > > >>>>> a XEN VM which is the VM running DomU. Just like what ACRN di= d > > > > >>>>> to run trusty os. > > > > >>>> Well, it depends on whom you are trusting more. Both XEN and > > > > >>>> TEE are minimal OS implementations with aim at security. I'm > > > > >>>> speaking about generic TEE OS, not about particular OS like OP= -TEE > > or Trusty. > > > > >>>> Problem is that, if TEE is running inside VM, it will be > > > > >>>> susceptible to a hypervisor misbehaviour. You need to > > > > >>>> understand that Xen and privileged domain (dom0, mostly) can > > > > >>>> access memory of > > > > any guest. > > > > >>>> At least, in default configuration. There are means to harden > > > > >>>> this setup. But anyways, Xen can't be stopped from reading TEE= 's > > secrets. > > > > >>> > > > > >>> IIRC, we discussed this approach for OP-TEE in the past. There > > > > >>> was other > > > > >> potential pitfalls with it. For instance, you wouldn't be able t= o > > > > >> directly access any secure device from that guest (it is running > > > > >> in > > > > non-secure world). > > > > >>> > > > > >>> There are also issues in term of latency as you may have the > > > > >>> following > > > > >> model: > > > > >>> > > > > >>> domU -> Xen -> domU TEE -> (Xen -> host TEE -> Xen -> domU TEE) > > > > >>> -> Xen -> > > > > >> domU. > > > > >>> > > > > >>> The bit in () is if you require to call the host TEE. > > > > >>> > > > > >>> One possibility would be to use Secure-EL2 for your Trusty OS. > > > > >>> But I don't > > > > >> know whether your platform supports it. > > > > >>> > > > > >>> Depending on whether you can modify Trusty OS, alternative woul= d > > > > >>> be to > > > > >> make itvirtualization aware as OP-TEE did. The core would need t= o > > > > >> be resilient and the panic only affect a given client. > > > > >> > > > > >> I do not have right a clear idea of what is the status of optee > > > > >> and xen but in theory I would see 2 possible ways to handle this= : > > > > >> - without optee modification, something in a guest (Dom0 or an > > > > >> other priviledged one) needs to have access to optee and emulate > > > > >> optee access for others. > > > > >> - with optee modifications, optee needs to have a concept of > > > > >> client and Xen would need to passthrough optee requests but bein= g > > > > >> responsible of adding a =E2=80=9Cclient=E2=80=9D identifier. May= be also informing > > > > >> Optee when a new client is created/removed. > > > > >> > > > > >> The second scenario could then be somehow splitted in the > > > > >> previous one from Julien if some parts would need to be emulated > > > > >> somewhere in some kind of combination of the 2 models. > > > > >> > > > > >> In any case i would always consider that anything running on > > > > >> optee (or in general in the secure world) is more trusted then X= en. > > > > > > > > > > Ok, this means optee runs on all cores in secure world, but this > > > > > would not work when we need to support multiple OSes with their o= wn > > TEE. > > > > > > > > I would think you have one TEE running on all cores (or runnable in= this > > case). > > > > So the Tee needs to handle several contexts or someone needs to > > virtualize it. > > > > > > This back to my original question, should I virtualize TEE in a XEN d= edicated > > VM? > > > or I need to emulate secure world to let one VM could have secure and > > > non-secure world? > > > > > > > Well, I think that the best approach is that we did in the OP-TEE: make= Trusty > > virtualization-aware, so it can handle multiple VMs. > > Trusty virtualization-aware, you mean android Linux trusty driver communi= cate > with OP-TEE or else? Okay, OP-TEE is implemented right as Bertran has suggested: OP-TEE can work with multiple VMs at the same time. It has special calls to create and destroy VM contextes. So, when a new VM/guest is spawned, Xen says "Hey, OP-TEE, there is a new VM with ID NNN". OP-TEE then initializes internal state for the new VM. At any moment Xen can say "Oops, that VM with ID NNN is dead". OP-TEE will immediately destroy the internal state for that VM. Also, Xen needs to perform certain actions every time VM calls OP-TEE: tran= slate addresses, tell OP-TEE id of that VM, lock guest pages... And no changes to the OP-TEE client in Linux are needed. It thinks that it communicates directly with the OP-TEE. OP-TEE is running in the Secure World as usual. The same can be done for any other TEE. Trusty, for example. Downside is th= at you can't run two different TEEs in the Secure world. Actually, ARM added virtualization support in Secure mode, but AFAIK, i.MX8= does not support it. To sum it up: 1. If you want to run only Trusty on your system, and you want to run it in Secure World, you need to make Trusty virtualization-aware, and write mediator in Xen. This is what I did for OP-TEE. 2. If you want to run Trusty AND OP-TEE in the Secure World, then you need to do p1. and then implement some paravirtualization support in Secure Monitor, Trusty and OP-TEE 3. If your use case does not require high security, you can try to run Trusty as a VM. But, I am almost certain that this will not pass Google's requirements. So no Google Pay, no E-SIM, no DRM for this setup. But, you should clarify this with Google. I'm not a Google representative :) From xen-devel-bounces@lists.xenproject.org Fri Jun 19 10:25:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 10:25:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEDN-0008Kl-Qw; Fri, 19 Jun 2020 10:25:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEDM-0008Kg-OT for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 10:25:40 +0000 X-Inumbo-ID: 3901a3bc-b217-11ea-bb5e-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3901a3bc-b217-11ea-bb5e-12813bfff9fa; Fri, 19 Jun 2020 10:25:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=gXfD+L0aycXZvm7GG3dvd8WMtQK0meque3tAx6JuIgU=; b=blRaPhUkAtp1Bk7I0GDz4runvB Fszv3xFSDuVW/6bOd5UTybeIHltDvdegfih2lcQrI9euwCLseqRNs3A5XvPdi2kTC/nR7OjaUsRIm 3B+odK6olwy+35+k7ZULxk+LEVOjccXTliDgQOV0fI5UrGOsCL8dzje5GLh/+juh1BrU=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEDL-0004JV-Im; Fri, 19 Jun 2020 10:25:39 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jmEDL-0002UK-Bf; Fri, 19 Jun 2020 10:25:39 +0000 Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address To: Volodymyr Babchuk References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> <878sgk2bst.fsf@epam.com> <8d2f3475-4191-fa80-f476-e72af73e0559@xen.org> <87h7v71ixf.fsf@epam.com> From: Julien Grall Message-ID: Date: Fri, 19 Jun 2020 11:25:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <87h7v71ixf.fsf@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "sstabellini@kernel.org" , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Volodymyr, On 19/06/2020 10:52, Volodymyr Babchuk wrote: >>>>> OP-TEE represents this null memory reference as a TMEM parameter with >>>>> buf_ptr == NULL. This is the only case when we should allow TMEM >>>>> buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. >>>> >>>> IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer >>>> at address 0" but with the flag cleared, it would mean "return the >>>> size". Am I correct? >>> >>> Not exactly. This flag does not affect behavior for buffers with address >>> NULL. In any case, this would not mean "return the size" to >>> OP-TEE. This is because OP-TEE works as a transport between CA and TA >>> and it does not assign any meaning to client buffers. But certainly, >>> null buffer will mean "return the size" for some TAs, as described in >>> GlobalPlatform specification. >> >> Does it mean a guest TA may potentially access address 0? > > TA is running in S-EL0. That buffer with PA=0x0 will be not mapped in TA > address space at all. So, if TA will try to access address 0, it > will be terminated with data abort. > >> I am asking that because 0 can be a valid host physical address. We >> are currently carving out 0 from the heap allocator to workaround a >> bug, but there is no promise this address will be used by the boot >> allocator and therefore Xen. >> > > Well, this is a potential issue in OP-TEE. It does not treat 0 as a > valid address. So, in that rare case, when REE will try to use 0 > as a correct address for data buffer, OP-TEE will not map it into > TA address space, instead it will pass NULL to TA, so TA will think that > no buffer was provided. Thanks! That's reassuring. Although, I think we may still need to prevent MFN 0 to be allocated for a guest using OP-TEE. So they don't end up with weird failure. I don't think this is an issue so far, but this may change with Stefano's dom0less series to support direct mapping. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 19 10:28:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 10:28:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEGV-0008Tk-9x; Fri, 19 Jun 2020 10:28:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEGT-0008Tf-Up for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 10:28:53 +0000 X-Inumbo-ID: ab136fc6-b217-11ea-bb5e-12813bfff9fa Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ab136fc6-b217-11ea-bb5e-12813bfff9fa; Fri, 19 Jun 2020 10:28:51 +0000 (UTC) Received: from webmail.moloch.sk (w3-s.a.lucina.net [62.176.169.73]) by smtp.lucina.net (Postfix) with ESMTPSA id DDE30122804; Fri, 19 Jun 2020 12:28:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592562530; bh=n/UcbhmynjYkE8I4QJZoH1EVb+BPwxBhePbHkQIhJ9U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=GyaCk2uHNYTD3+9cf+WBXPBbTmyvFMy8yrwKd0q9pDQaOQiZ96NCAgfmvQ3q1KRQw KiSkwWeSj6FLwui58hlSi7Xmy61cHuRxiJC5FHP5KHmq7+EnfQfDZXd3/Dw1JBm9uv SUeZgqDPdLp2G+3wdvk2G/dx2dJCBguPZHPwdK2Smq1vImhLfafaaqNdTHnBN+LW49 Ej5Htdagf/MUwDFWDMweTQIFOrk6CTMxsM7YRhOk7YIlJC/3p/liwBt1cqLOBZeeoR cdLvP62mds4GcvfGpaAeU/kZjnk/t/O91WLhvq61fiySBUpNdZFud0RaU9LaeVpVJg q5mvmn3LUUn9w== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 19 Jun 2020 12:28:50 +0200 From: Martin Lucina To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: Event delivery and "domain blocking" on PVHv2 In-Reply-To: <20200618114617.GJ735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> Message-ID: <17deb17cec442f96cc7aba98ef4c047c@lucina.net> X-Sender: martin@lucina.net User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-18 13:46, Roger Pau Monné wrote: > On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote: >> At this point I don't really have a clear idea of how to progress, >> comparing my implementation side-by-side with the original PV >> Mini-OS-based >> implementation doesn't show up any differences I can see. >> >> AFAICT the OCaml code I've also not changed in any material way, and >> that >> has been running in production on PV for years, so I'd be inclined to >> think >> the problem is in my reimplementation of the C parts, but where...? > > A good start would be to print the ISR and IRR lapic registers when > blocked, to assert there are no pending vectors there. > > Can you apply the following patch to your Xen, rebuild and check the > output of the 'l' debug key? > > Also add the output of the 'v' key. Had to fight the Xen Debian packages a bit as I wanted to patch the exact same Xen (there are some failures when building on a system that has Xen installed due to following symlinks when fixing shebangs). Here you go, when stuck during netfront setup, after allocating its event channel, presumably waiting on Xenstore: 'e': (XEN) Event channel information for domain 3: (XEN) Polling vCPUs: {} (XEN) port [p/m/s] (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 (XEN) 4 [0/1/1]: s=2 n=0 x=0 d=0 'l': (XEN) d3v0 IRR: ffff8301732dc200b (XEN) d3v0 ISR: ffff8301732dc100b 'v': (XEN) *********** VMCS Areas ************** (XEN) (XEN) >>> Domain 3 <<< (XEN) VCPU 0 (XEN) *** Guest State *** (XEN) CR0: actual=0x0000000080000033, shadow=0x0000000080000033, gh_mask=ffffffffffffffff (XEN) CR4: actual=0x0000000000002660, shadow=0x0000000000000020, gh_mask=ffffffffffc8f860 (XEN) CR3 = 0x00000000002e9000 (XEN) RSP = 0x000000000ffffec0 (0x000000000ffffec0) RIP = 0x0000000000209997 (0x0000000000209998) (XEN) RFLAGS=0x00000297 (0x00000297) DR7 = 0x0000000000000400 (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) sel attr limit base (XEN) CS: 0008 0a099 ffffffff 0000000000000000 (XEN) DS: 0010 0c093 ffffffff 0000000000000000 (XEN) SS: 0010 0c093 ffffffff 0000000000000000 (XEN) ES: 0010 0c093 ffffffff 0000000000000000 (XEN) FS: 0000 1c000 ffffffff 0000000000000000 (XEN) GS: 0000 1c000 ffffffff 0000000000000000 (XEN) GDTR: 00000027 00000000003e13c0 (XEN) LDTR: 0000 10000 00000000 0000000000000000 (XEN) IDTR: 000002ff 00000000003e10a8 (XEN) TR: 0018 0008b 00000068 00000000003e1040 (XEN) EFER = 0x0000000000000000 PAT = 0x0007040600070406 (XEN) PreemptionTimer = 0x00000000 SM Base = 0x00000000 (XEN) DebugCtl = 0x0000000000000000 DebugExceptions = 0x0000000000000000 (XEN) Interruptibility = 00000000 ActivityState = 00000000 (XEN) *** Host State *** (XEN) RIP = 0xffff82d08031dd30 (vmx_asm_vmexit_handler) RSP = 0xffff83009c057f70 (XEN) CS=e008 SS=0000 DS=0000 ES=0000 FS=0000 GS=0000 TR=e040 (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff82d08055e000 (XEN) GDTBase=ffff82d08042e000 IDTBase=ffff82d080559000 (XEN) CR0=0000000080050033 CR3=0000000172a67000 CR4=00000000003526e0 (XEN) Sysenter RSP=ffff83009c057fa0 CS:RIP=e008:ffff82d0803654b0 (XEN) EFER = 0x0000000000000000 PAT = 0x0000050100070406 (XEN) *** Control State *** (XEN) PinBased=0000003f CPUBased=b6a065fa SecondaryExec=000014eb (XEN) EntryControls=000053ff ExitControls=000fefff (XEN) ExceptionBitmap=00060002 PFECmask=00000000 PFECmatch=00000000 (XEN) VMEntry: intr_info=00000020 errcode=00000000 ilen=00000000 (XEN) VMExit: intr_info=00000000 errcode=00000000 ilen=00000001 (XEN) reason=0000000c qualification=0000000000000000 (XEN) IDTVectoring: info=00000000 errcode=00000000 (XEN) TSC Offset = 0xffffffcf8453199b TSC Multiplier = 0x0000000000000000 (XEN) TPR Threshold = 0x00 PostedIntrVec = 0x00 (XEN) EPT pointer = 0x0000000172a0b01e EPTP index = 0x0000 (XEN) PLE Gap=00000080 Window=00001000 (XEN) Virtual processor ID = 0x000e VMfunc controls = 0000000000000000 (XEN) ************************************** RIP 0x209997 is the 'hlt' instruction in mirage_xen_evtchn_block_domain() so we are indeed blocking waiting for events to show up. Martin From xen-devel-bounces@lists.xenproject.org Fri Jun 19 10:31:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 10:31:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEJD-0000qd-Ro; Fri, 19 Jun 2020 10:31:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEJD-0000qY-C5 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 10:31:43 +0000 X-Inumbo-ID: 1086eb9e-b218-11ea-bb60-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1086eb9e-b218-11ea-bb60-12813bfff9fa; Fri, 19 Jun 2020 10:31:42 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: fYsZu61/2ZYIqvY2si0AkUINxkWzpin0GRMWoIaFvWIqTj+jIEhBt+O/jzhO6fCY7ZlKmnFqDJ uRS9Qq+n7TV99RcpIur2A50qlKP9ZaAuzNPfFL7D8ln3WHsK/IQMa2RU5ud+OV3lSpCT2QZYz/ 3zYWPRpBprx4QGm7TElREiVJ03itvX2G0RB0euKtADDDubWQLfDDXT8vIWICnuc2yNkRjjUPuY p5NvJCg5T4OzApEaCdCYke2l4NauscZN+2YTGvy875mSFT9TTm0dB4JapeinR+FMqWmkzzJfV8 4Og= X-SBRS: 2.7 X-MesageID: 20756471 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20756471" From: Anthony PERARD To: Subject: [PATCH] xen: Actually fix build without passthrough Date: Fri, 19 Jun 2020 11:31:15 +0100 Message-ID: <20200619103115.254127-1-anthony.perard@citrix.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , Paolo Bonzini , Stefano Stabellini , xen-devel@lists.xenproject.org, Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Fix typo. Fixes: acd0c9416d48 ("xen: fix build without pci passthrough") Signed-off-by: Anthony PERARD --- hw/xen/Makefile.objs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs index 3fc715e5954d..502b32d877a0 100644 --- a/hw/xen/Makefile.objs +++ b/hw/xen/Makefile.objs @@ -4,4 +4,4 @@ common-obj-y += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o xen-bus.o xen-b obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_graphics.o xen_pt_msi.o obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_load_rom.o -obj-$(call $(lnot, $(CONFIG_XEN_PCI_PASSTHROUGH))) += xen_pt_stub.o +obj-$(call lnot,$(CONFIG_XEN_PCI_PASSTHROUGH)) += xen_pt_stub.o -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Fri Jun 19 10:37:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 10:37:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEOd-000131-ST; Fri, 19 Jun 2020 10:37:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEOb-00012D-UW for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 10:37:17 +0000 X-Inumbo-ID: d50bf162-b218-11ea-b7bb-bc764e2007e4 Received: from mailout1.w1.samsung.com (unknown [210.118.77.11]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d50bf162-b218-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 10:37:11 +0000 (UTC) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20200619103710euoutp015bf0dde28f4f6e75b365306f52d390c2~Z66OHUPha1836418364euoutp01p for ; Fri, 19 Jun 2020 10:37:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20200619103710euoutp015bf0dde28f4f6e75b365306f52d390c2~Z66OHUPha1836418364euoutp01p DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1592563030; bh=KttQx/p+NwMYqZeVMMA/mdxDyA5P7MIUmLy+qtaSi8Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RzVwOmNjTGd4ySElcOMb4faJhJt7GwRrHtUfllCqXDfMFPBeXjTNomdOkHtwFXlDv QlrspxBexZJDD5Y0yiuW4F+5CDABhZ3NGjA6Q/vuB0e2Xyw8uJhmYNhN5JP+nU8DGd 6vuqUgeWfloTSbFdFL0fW2UPMDWJFNc1zIaTwU3I= Received: from eusmges3new.samsung.com (unknown [203.254.199.245]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20200619103710eucas1p1b26b19044fdf0ab23ddf00e8af5dac02~Z66NuxP790706007060eucas1p1v; Fri, 19 Jun 2020 10:37:10 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges3new.samsung.com (EUCPMTA) with SMTP id B6.9C.06318.6559CEE5; Fri, 19 Jun 2020 11:37:10 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20200619103710eucas1p1873c8ebb37e6717a5864c31d10b50efd~Z66NYik2Q0708007080eucas1p16; Fri, 19 Jun 2020 10:37:10 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20200619103710eusmtrp1e00a23e8c33180e37d7e2e5e3c29611b~Z66NXlFAw0949709497eusmtrp1h; Fri, 19 Jun 2020 10:37:10 +0000 (GMT) X-AuditID: cbfec7f5-371ff700000018ae-79-5eec955600b0 Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id B9.EA.06314.5559CEE5; Fri, 19 Jun 2020 11:37:09 +0100 (BST) Received: from AMDC2765.digital.local (unknown [106.120.51.73]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20200619103709eusmtip229150f3f49532456da9435edbf1b0eb1~Z66Mp5_mW0244902449eusmtip2r; Fri, 19 Jun 2020 10:37:09 +0000 (GMT) From: Marek Szyprowski To: dri-devel@lists.freedesktop.org, iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org Subject: [PATCH v7 25/36] xen: gntdev: fix common struct sg_table related issues Date: Fri, 19 Jun 2020 12:36:25 +0200 Message-Id: <20200619103636.11974-26-m.szyprowski@samsung.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200619103636.11974-1-m.szyprowski@samsung.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMKsWRmVeSWpSXmKPExsWy7djPc7phU9/EGTQ+ErPoPXeSyWLjjPWs Fhent7JY/N82kdniytf3bBYrVx9lsliw39pizk0jiy9XHjJZbHp8jdXi8q45bBZrj9xltzj4 4Qmrxfctk5kc+DzWzFvD6LH32wIWj+3fHrB63O8+zuSxeUm9x+1/j5k9Jt9Yzuhx+MMVFo/d NxvYPD4+vcXi0bdlFaPH+i1XWTw+b5IL4I3isklJzcksSy3St0vgylh/4xJLwUmxivdbdrM0 MG4R6mLk4JAQMJFYspSni5GLQ0hgBaPEk5OLmCGcL4wSzxfuYYdwPjNKbJ3/EijDCdYxc8cZ qMRyRol9rc8Y4VoObd/DBlLFJmAo0fW2C8wWEWhllDjRC7aEWaCbWWLq2lWsIAlhgSCJm1dO gRWxCKhKbO5ZyQ5i8wrYSdz5fZ4VYp28xOoNB8BWcwLFX7cchIrfY5f4810fwnaRuHz5EhOE LSzx6vgWdghbRuL05B4WkMUSAs2MEg/PrWWHcHoYJS43zWCEqLKWuHPuFxsoOJgFNCXW79KH hIyjxLb2JAiTT+LGW0GQYmYgc9K26cwQYV6JjjYhiBlqErOOr4PbevDCJWhgeUjsOreIFRI+ ExklWk81sE1glJ+FsGsBI+MqRvHU0uLc9NRi47zUcr3ixNzi0rx0veT83E2MwKR1+t/xrzsY 9/1JOsQowMGoxMP7IuR1nBBrYllxZe4hRgkOZiURXqezp+OEeFMSK6tSi/Lji0pzUosPMUpz sCiJ8xovehkrJJCeWJKanZpakFoEk2Xi4JRqYLwT/ipGNpPvOOvPqRvf2Om+fMrheqTk+OfG C8VibYFHdjT12zinPnt5S9z5gpPui09HrGU2tn/UeelfGLT7f2/Wx1UJe1i93Zz4Juf4H9t4 0XnOgjrZozxr3wcv5vrRua7b7lkg5x1ZkZ87Z6Vw8PrwVSzXXB2rHTnN7F16wevZ62Iue7w/ lKXEUpyRaKjFXFScCAAwPjcEVgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsVy+t/xe7qhU9/EGTx5bmnRe+4kk8XGGetZ LS5Ob2Wx+L9tIrPFla/v2SxWrj7KZLFgv7XFnJtGFl+uPGSy2PT4GqvF5V1z2CzWHrnLbnHw wxNWi+9bJjM58HmsmbeG0WPvtwUsHtu/PWD1uN99nMlj85J6j9v/HjN7TL6xnNHj8IcrLB67 bzaweXx8eovFo2/LKkaP9Vuusnh83iQXwBulZ1OUX1qSqpCRX1xiqxRtaGGkZ2hpoWdkYqln aGwea2VkqqRvZ5OSmpNZllqkb5egl7H+xiWWgpNiFe+37GZpYNwi1MXIySEhYCIxc8cZ9i5G Lg4hgaWMEhd+LmWESMhInJzWwAphC0v8udbFBlH0iVHi2KUTbCAJNgFDia63EAkRgU5GiWnd H8FGMQtMZpZ4tvo6UxcjB4ewQIBEX2MVSAOLgKrE5p6V7CA2r4CdxJ3f56E2yEus3nCAGcTm BIq/bjkIFhcSsJVYvuA98wRGvgWMDKsYRVJLi3PTc4sN9YoTc4tL89L1kvNzNzEC42jbsZ+b dzBe2hh8iFGAg1GJh/dFyOs4IdbEsuLK3EOMEhzMSiK8TmdPxwnxpiRWVqUW5ccXleakFh9i NAU6aiKzlGhyPjDG80riDU0NzS0sDc2NzY3NLJTEeTsEDsYICaQnlqRmp6YWpBbB9DFxcEo1 MAYtmJk782PZ2r5F3zsVHNIjv+Yu3Xu89pmp2/9nkfUX1sz6tKHq/P6wz6erXv9b7VFlqM9l 4nT46qrvrT8vHhLTU3jNlHIgfafeCYFoj0/u7udYuO96SC4qVv/55vWEKb7di+ZOETjhp6Nv vzb50zlu4+NFZgyz0iPcC1ZvnXRq6WKeLcDQiVNiKc5INNRiLipOBABev5EouQIAAA== X-CMS-MailID: 20200619103710eucas1p1873c8ebb37e6717a5864c31d10b50efd X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200619103710eucas1p1873c8ebb37e6717a5864c31d10b50efd X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200619103710eucas1p1873c8ebb37e6717a5864c31d10b50efd References: <20200619103636.11974-1-m.szyprowski@samsung.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Bartlomiej Zolnierkiewicz , David Airlie , Daniel Vetter , xen-devel@lists.xenproject.org, Boris Ostrovsky , Robin Murphy , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, Marek Szyprowski Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_map_sg(). struct sg_table is a common structure used for describing a non-contiguous memory buffer, used commonly in the DRM and graphics subsystems. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA mapped pages (nents entry). It turned out that it was a common mistake to misuse nents and orig_nents entries, calling DMA-mapping functions with a wrong number of entries or ignoring the number of mapped entries returned by the dma_map_sg() function. To avoid such issues, lets use a common dma-mapping wrappers operating directly on the struct sg_table objects and use scatterlist page iterators where possible. This, almost always, hides references to the nents and orig_nents entries, making the code robust, easier to follow and copy/paste safe. Signed-off-by: Marek Szyprowski Acked-by: Juergen Gross --- drivers/xen/gntdev-dmabuf.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c index 75d3bb948bf3..ba6cad871568 100644 --- a/drivers/xen/gntdev-dmabuf.c +++ b/drivers/xen/gntdev-dmabuf.c @@ -247,10 +247,9 @@ static void dmabuf_exp_ops_detach(struct dma_buf *dma_buf, if (sgt) { if (gntdev_dmabuf_attach->dir != DMA_NONE) - dma_unmap_sg_attrs(attach->dev, sgt->sgl, - sgt->nents, - gntdev_dmabuf_attach->dir, - DMA_ATTR_SKIP_CPU_SYNC); + dma_unmap_sgtable(attach->dev, sgt, + gntdev_dmabuf_attach->dir, + DMA_ATTR_SKIP_CPU_SYNC); sg_free_table(sgt); } @@ -288,8 +287,8 @@ dmabuf_exp_ops_map_dma_buf(struct dma_buf_attachment *attach, sgt = dmabuf_pages_to_sgt(gntdev_dmabuf->pages, gntdev_dmabuf->nr_pages); if (!IS_ERR(sgt)) { - if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir, - DMA_ATTR_SKIP_CPU_SYNC)) { + if (dma_map_sgtable(attach->dev, sgt, dir, + DMA_ATTR_SKIP_CPU_SYNC)) { sg_free_table(sgt); kfree(sgt); sgt = ERR_PTR(-ENOMEM); @@ -625,7 +624,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device *dev, /* Now convert sgt to array of pages and check for page validity. */ i = 0; - for_each_sg_page(sgt->sgl, &sg_iter, sgt->nents, 0) { + for_each_sgtable_page(sgt, &sg_iter, 0) { struct page *page = sg_page_iter_page(&sg_iter); /* * Check if page is valid: this can happen if we are given -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 10:37:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 10:37:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEOY-00012J-GM; Fri, 19 Jun 2020 10:37:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEOX-00012D-3J for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 10:37:13 +0000 X-Inumbo-ID: d4a18980-b218-11ea-b7bb-bc764e2007e4 Received: from mailout1.w1.samsung.com (unknown [210.118.77.11]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d4a18980-b218-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 10:37:10 +0000 (UTC) Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20200619103710euoutp017be01f9197ad89a1fc5a9c91362ea14e~Z66NdigKC1896418964euoutp01F for ; Fri, 19 Jun 2020 10:37:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20200619103710euoutp017be01f9197ad89a1fc5a9c91362ea14e~Z66NdigKC1896418964euoutp01F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1592563030; bh=Q6nmdHxiLcADSmmOczfWQ1kCLD9EfF+zt7aqe3afHuk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VHefC+JluP5Qj9mL1rqlzJ5Mwi6i+VmN0PI3DSZX3mC6EZoTRF3R9qCpbOvbbI+Yx AO+zze1FItWiPcD2nRjl0pgTufThZWqTrRRLsyCUZu29Uu8J6VFAKhqRyl2cNTCR+H 4hjv4h89AnE9SvAnKUpg3DurLeWXDTZ+xaRkBh5w= Received: from eusmges2new.samsung.com (unknown [203.254.199.244]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20200619103709eucas1p21d6de6a02ac0a38a1c40613598ad7c02~Z66NDFxOM0715307153eucas1p2E; Fri, 19 Jun 2020 10:37:09 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges2new.samsung.com (EUCPMTA) with SMTP id DA.9D.05997.5559CEE5; Fri, 19 Jun 2020 11:37:09 +0100 (BST) Received: from eusmtrp1.samsung.com (unknown [182.198.249.138]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20200619103709eucas1p12c32fa6377caf78e5dc28ce0ff51e7a0~Z66MxwK080706007060eucas1p1t; Fri, 19 Jun 2020 10:37:09 +0000 (GMT) Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by eusmtrp1.samsung.com (KnoxPortal) with ESMTP id 20200619103709eusmtrp1073acf67ba92e93a81c52f0c01cf0521~Z66Mr3ezn0959609596eusmtrp1S; Fri, 19 Jun 2020 10:37:09 +0000 (GMT) X-AuditID: cbfec7f4-677ff7000000176d-fa-5eec95557eb9 Received: from eusmtip2.samsung.com ( [203.254.199.222]) by eusmgms2.samsung.com (EUCPMTA) with SMTP id 03.1B.06017.5559CEE5; Fri, 19 Jun 2020 11:37:09 +0100 (BST) Received: from AMDC2765.digital.local (unknown [106.120.51.73]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20200619103708eusmtip20f150a4cbcaa1a29d802f5e72289a3ee~Z66MCpa440111401114eusmtip2N; Fri, 19 Jun 2020 10:37:08 +0000 (GMT) From: Marek Szyprowski To: dri-devel@lists.freedesktop.org, iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org Subject: [PATCH v7 24/36] drm: xen: fix common struct sg_table related issues Date: Fri, 19 Jun 2020 12:36:24 +0200 Message-Id: <20200619103636.11974-25-m.szyprowski@samsung.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200619103636.11974-1-m.szyprowski@samsung.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJKsWRmVeSWpSXmKPExsWy7djPc7qhU9/EGbTPVLPoPXeSyWLjjPWs Fv+3TWS2uPL1PZvFytVHmSwW7Le2+HLlIZPFpsfXWC0u75rDZrH2yF12iw+r37NaHPzwhNXi +5bJTA68HmvmrWH0uLN0J6PH3m8LWDy2f3vA6nG/+ziTx+Yl9R63/z1m9ph8Yzmjx+EPV1g8 dt9sYPPo27KK0ePzJrkAnigum5TUnMyy1CJ9uwSujL1d7UwFfXwV0y82MzYwvuXuYuTkkBAw kTjxYDFbFyMXh5DACkaJvmezWSCcL4wSTxZNZYdwPjNKbN1wCaiMA6zl5XVziPhyRolr736y gowC6/h0SBHEZhMwlOh628UGYosItDJKnOjlAWlgFvjBJHFu2Ql2kISwgL9Ew7+HjCBDWQRU JfZtlQEJ8wrYSXy5foMd4jx5idUbDjCD2JxA8dctB1kh4pfYJSZNlYGwXST6HjyHqheWeHV8 C5QtI3F6cg/YNxICzYwSD8+tZYdwehglLjfNYISospa4c+4X2GfMApoS63fpQ4QdJbbuOsoM 8TCfxI23giBhZiBz0rbpUGFeiY42IYhqNYlZx9fBrT144RIzhO0h0ToZ5ENQWE1klOhf/oB5 AqP8LIRlCxgZVzGKp5YW56anFhvlpZbrFSfmFpfmpesl5+duYgQmqNP/jn/ZwbjrT9IhRgEO RiUe3hchr+OEWBPLiitzDzFKcDArifA6nT0dJ8SbklhZlVqUH19UmpNafIhRmoNFSZzXeNHL WCGB9MSS1OzU1ILUIpgsEwenVANjH6doi+B3Ww2Tp/s6C3QZzxm8qjzYXvNOXWRum2pUd2/W zxS/t390RTPrts7KS1OLfrpMpK1Xa/fxTXlFDgosQtdv3Li98fSe6CzdmTxar1XltXWfJEs+ VDnxPmwZQ9VXyad+3c9LFv8tZ+jYnrakUe7r6RuMn+/ESby6LpegcZvxz1bD6eFKLMUZiYZa zEXFiQAV/hk2TAMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsVy+t/xe7qhU9/EGRzs5rPoPXeSyWLjjPWs Fv+3TWS2uPL1PZvFytVHmSwW7Le2+HLlIZPFpsfXWC0u75rDZrH2yF12iw+r37NaHPzwhNXi +5bJTA68HmvmrWH0uLN0J6PH3m8LWDy2f3vA6nG/+ziTx+Yl9R63/z1m9ph8Yzmjx+EPV1g8 dt9sYPPo27KK0ePzJrkAnig9m6L80pJUhYz84hJbpWhDCyM9Q0sLPSMTSz1DY/NYKyNTJX07 m5TUnMyy1CJ9uwS9jL1d7UwFfXwV0y82MzYwvuXuYuTgkBAwkXh53byLkYtDSGApo8SHW9tY uhg5geIyEienNbBC2MISf651sYHYQgKfGCXOz2cGsdkEDCW63oLEuThEBDoZJaZ1f2QHcZgF /jFJnNi7nQmkSljAV+Lwmz2MINtYBFQl9m2VAQnzCthJfLl+gx1igbzE6g0HwIZyAsVftxxk hVhmK7F8wXvmCYx8CxgZVjGKpJYW56bnFhvpFSfmFpfmpesl5+duYgRGzLZjP7fsYOx6F3yI UYCDUYmH90XI6zgh1sSy4srcQ4wSHMxKIrxOZ0/HCfGmJFZWpRblxxeV5qQWH2I0BbppIrOU aHI+MJrzSuINTQ3NLSwNzY3Njc0slMR5OwQOxggJpCeWpGanphakFsH0MXFwSjUwlmusllia NLd7y62CFuePloqXituO9YR6/ZO6rzIt21juU8GFFSfZL/efrg2oSN8tMuGiU8KrcJn2FkUb gQf9M9+3Opyq+8+745SblW2lyrO6l009Fz4tftktE/BzpZfBkvCZy1WUK39+MTYv/OEwZe/v sqo3E1I2blmcn6KqqxvGx3K/5mKvEktxRqKhFnNRcSIAGXz7bK4CAAA= X-CMS-MailID: 20200619103709eucas1p12c32fa6377caf78e5dc28ce0ff51e7a0 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20200619103709eucas1p12c32fa6377caf78e5dc28ce0ff51e7a0 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20200619103709eucas1p12c32fa6377caf78e5dc28ce0ff51e7a0 References: <20200619103636.11974-1-m.szyprowski@samsung.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Bartlomiej Zolnierkiewicz , David Airlie , Oleksandr Andrushchenko , Daniel Vetter , xen-devel@lists.xenproject.org, Robin Murphy , Christoph Hellwig , linux-arm-kernel@lists.infradead.org, Marek Szyprowski Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_map_sg(). struct sg_table is a common structure used for describing a non-contiguous memory buffer, used commonly in the DRM and graphics subsystems. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA mapped pages (nents entry). It turned out that it was a common mistake to misuse nents and orig_nents entries, calling DMA-mapping functions with a wrong number of entries or ignoring the number of mapped entries returned by the dma_map_sg() function. Fix the code to refer to proper nents or orig_nents entries. This driver reports the number of the pages in the imported scatterlist, so it should refer to sg_table->orig_nents entry. Signed-off-by: Marek Szyprowski Acked-by: Oleksandr Andrushchenko --- drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c b/drivers/gpu/drm/xen/xen_drm_front_gem.c index f0b85e094111..ba4bdc5590ea 100644 --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c @@ -215,7 +215,7 @@ xen_drm_front_gem_import_sg_table(struct drm_device *dev, return ERR_PTR(ret); DRM_DEBUG("Imported buffer of size %zu with nents %u\n", - size, sgt->nents); + size, sgt->orig_nents); return &xen_obj->base; } -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 10:41:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 10:41:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEST-0001va-Eh; Fri, 19 Jun 2020 10:41:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmESS-0001vV-6M for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 10:41:16 +0000 X-Inumbo-ID: 65dc4f8e-b219-11ea-bca7-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 65dc4f8e-b219-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 10:41:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592563273; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=1BMxPj6jvkgxEoqHhhNw20WQP+13803h1hAdaccBo/Q=; b=Ne9hFeiy016cmj+16acc/AtARExfJerAPRWtukMSavBUmlPR8O7I0Dz+/ViZfsifhTk/Fx HYn6sqmTL71fOoBM0qnRyA5zUJEMGl+uLYVQYQmumk92CLyGUd7cDqKfVhQm1nBv4z/Lo8 UR2mEr+kjDNg5Q396zeISeVIGBuE4O4= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-294-SzAsRwlgO6W1a9iqSi722w-1; Fri, 19 Jun 2020 06:41:12 -0400 X-MC-Unique: SzAsRwlgO6W1a9iqSi722w-1 Received: by mail-wm1-f70.google.com with SMTP id u15so2535550wmm.5 for ; Fri, 19 Jun 2020 03:41:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1BMxPj6jvkgxEoqHhhNw20WQP+13803h1hAdaccBo/Q=; b=HXryhGFLBY05Em0M9bn6n/y4N6V3TBgB6yWQkSdZ6tcvJkesl6EqkAoH/VU1JIsUNB Aqwo5ArZ245YDn6qU9sJL5513JkFfXlLLuksa8T5iYiXJG2K42X67U3jkc0BU482bNNk Crp28ZK2xRxDpyrMJkDHpFWw93c/raAZOrYj9d0xSLcHy7KAbaICNr4yiRdJREEO+Dvr Fgpv/pK0KmTMIZrSlwm15bWtloObjPkfmZrbUygTw3LKhi4lq6oqXUZLZZmSKLvspuSP I7qBxs0R9sNvosZu0zWiOTy117SKMoTXZDLQdEhgc1osr27jyBCX2TclwqzJ0tIBIwB1 7P5w== X-Gm-Message-State: AOAM5332WzeX+RMZ34IAt/9w8qlHs86G6JOp0t/2Jxgiwdfo9EwfqW/Y vIYdpZV6P62SGvWEGVUJnooldrArjoCpXq1IQ55cm97G/uBSJODM3+e7FdV1PWcD4vdLPDiAr8x ylbfVNulL95Qmw+hAtDy6mHNTgso= X-Received: by 2002:a1c:408:: with SMTP id 8mr2998293wme.15.1592563270875; Fri, 19 Jun 2020 03:41:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJysr9XU0u8Oe1wPyRQ/8NIjEzFmaKRLuA+Bks786+y4wSunuhXx2jSFnMskrfFEi6CWBCEgTg== X-Received: by 2002:a1c:408:: with SMTP id 8mr2998284wme.15.1592563270692; Fri, 19 Jun 2020 03:41:10 -0700 (PDT) Received: from [192.168.1.37] (93.red-83-59-160.dynamicip.rima-tde.net. [83.59.160.93]) by smtp.gmail.com with ESMTPSA id 30sm2018044wrm.74.2020.06.19.03.41.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 03:41:10 -0700 (PDT) Subject: Re: [PATCH] xen: Actually fix build without passthrough To: Anthony PERARD , qemu-devel@nongnu.org References: <20200619103115.254127-1-anthony.perard@citrix.com> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: <3d2f13ca-abb3-1e96-8fa2-cc9c462c58ed@redhat.com> Date: Fri, 19 Jun 2020 12:41:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200619103115.254127-1-anthony.perard@citrix.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Paolo Bonzini , Stefano Stabellini , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/19/20 12:31 PM, Anthony PERARD wrote: > Fix typo. > > Fixes: acd0c9416d48 ("xen: fix build without pci passthrough") > Signed-off-by: Anthony PERARD > --- > hw/xen/Makefile.objs | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs > index 3fc715e5954d..502b32d877a0 100644 > --- a/hw/xen/Makefile.objs > +++ b/hw/xen/Makefile.objs > @@ -4,4 +4,4 @@ common-obj-y += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o xen-bus.o xen-b > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_graphics.o xen_pt_msi.o > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_load_rom.o > -obj-$(call $(lnot, $(CONFIG_XEN_PCI_PASSTHROUGH))) += xen_pt_stub.o > +obj-$(call lnot,$(CONFIG_XEN_PCI_PASSTHROUGH)) += xen_pt_stub.o Uh... Reviewed-by: Philippe Mathieu-Daudé From xen-devel-bounces@lists.xenproject.org Fri Jun 19 10:42:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 10:42:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmETi-000216-QA; Fri, 19 Jun 2020 10:42:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmETh-00020z-S5 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 10:42:33 +0000 X-Inumbo-ID: 94b79d2c-b219-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 94b79d2c-b219-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 10:42:33 +0000 (UTC) Received: by mail-wm1-x343.google.com with SMTP id g21so4225723wmg.0 for ; Fri, 19 Jun 2020 03:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=BFR8jLnFKKzeoiedj3QuphMlqG56YWoxLvBPjARRM6s=; b=cqdHZN3lGUoim3IIaQwimQW5V78VYIck3tvM6ETOkgSzqun5sM8fyS13Xgy0ejB+7v zMPeHCkhKMhMvTH6XofFMiO6a4p0p6q6T7H37uwpepmVm5femEPCBcIpyYH/uXuexJrT CrKtWn4FJMCb4M2vn9B0RUlonng5wZzhrdETTnUJRYV+PArYJKHp2Hnt5CPVc3/zpxWH WHZCEuZhasY36RAP+QbNybnUUMkIke77udyXXcr5TfjaX50E17QiQ5CAtfSrywoDMidf Xa1sP/dx3TIbbXqgeYvKjmpP7FVobUzSgIXjb65c5+J0H5OlTNiWNVinkhg8ReP8eud5 n8qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=BFR8jLnFKKzeoiedj3QuphMlqG56YWoxLvBPjARRM6s=; b=L8q/G1SVaMsmwmL9w5aL2je9Gu0M6rkuAwpl636Nn3QEanvC05Y3f87j0dtzzkUSAM JHtNeTYc8f2v2kfjUtqCKGDFOn4WOtEyr/JeEN4J11bor+Ep9Ummoos4nrEJ5R2xFwq+ UoM15Zf2h0BkYZcWtVMX7NZUMlHG0/BUDM16F1J5boDgb0sPS4Tpm5fyD8mnTb39fmyc SIJ4r3Pi+fVBU72HXRfAX7eBISc0kq7BGHEbkzyw99vrVIS3XrfStptafVvs0BUCVEPV LW3s0tolkYAkwt4vdEe8LDbAcUw2deipGMuiEZRjjhZdg1Iyxmwr81QHxMc0iTYjKzKe Kd7A== X-Gm-Message-State: AOAM531d3mZthdIZuTHqtIiE17GbgNlLD9c14OAY00OnNSYslGELx0g1 NgIC8N+eHY3Wd/NEEfwQzBA= X-Google-Smtp-Source: ABdhPJwaMMa/gMidMkxVhqK2lMz2pHCDECZBsvrFXbGWiBgBbPmK/XjcBpmTcn0NiMim+ey/IktetQ== X-Received: by 2002:a1c:e355:: with SMTP id a82mr3057725wmh.1.1592563352358; Fri, 19 Jun 2020 03:42:32 -0700 (PDT) Received: from CBGR90WXYV0 ([54.239.6.187]) by smtp.gmail.com with ESMTPSA id i8sm6717120wru.30.2020.06.19.03.42.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2020 03:42:31 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Anthony PERARD'" , References: <20200619103115.254127-1-anthony.perard@citrix.com> In-Reply-To: <20200619103115.254127-1-anthony.perard@citrix.com> Subject: RE: [PATCH] xen: Actually fix build without passthrough Date: Fri, 19 Jun 2020 11:42:30 +0100 Message-ID: <00aa01d64626$55eec020$01cc4060$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJ4Bmae6BJqEg639TdZnK5dfFEOPaecP7gQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Paolo Bonzini' , 'Stefano Stabellini' , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Anthony PERARD > Sent: 19 June 2020 11:31 > To: qemu-devel@nongnu.org > Cc: Paolo Bonzini ; Anthony PERARD ; Stefano > Stabellini ; Paul Durrant ; xen-devel@lists.xenproject.org > Subject: [PATCH] xen: Actually fix build without passthrough > > Fix typo. > > Fixes: acd0c9416d48 ("xen: fix build without pci passthrough") > Signed-off-by: Anthony PERARD Acked-by: Paul Durrant > --- > hw/xen/Makefile.objs | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs > index 3fc715e5954d..502b32d877a0 100644 > --- a/hw/xen/Makefile.objs > +++ b/hw/xen/Makefile.objs > @@ -4,4 +4,4 @@ common-obj-y += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o xen-bus.o xen-b > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_graphics.o xen_pt_msi.o > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_load_rom.o > -obj-$(call $(lnot, $(CONFIG_XEN_PCI_PASSTHROUGH))) += xen_pt_stub.o > +obj-$(call lnot,$(CONFIG_XEN_PCI_PASSTHROUGH)) += xen_pt_stub.o > -- > Anthony PERARD From xen-devel-bounces@lists.xenproject.org Fri Jun 19 11:10:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 11:10:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEuo-0004Xq-3i; Fri, 19 Jun 2020 11:10:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEum-0004XW-IU for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 11:10:32 +0000 X-Inumbo-ID: 799bc3d4-b21d-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 799bc3d4-b21d-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 11:10:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dqkN9jtebFBosZOrr0/9H5yUCkngvtJRFHvZuhCNaMU=; b=dpug7KEC3ynXUuw+AU5USwwWS bF7dNCO2XTK0nubs2rWNMON46IdBreSXdtmJ+OBWRMokTuzowTRxiwQbD8RNzzAmzNmnNQf4e7LWC ktVzvbDKp7N0ZtjkVvgKUZj2kNkgNFVF24bSOaKg8hDYWSeNlFGy5dzPgFFj1HW0cRw80=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmEue-00059N-V4; Fri, 19 Jun 2020 11:10:25 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmEue-0002W0-NW; Fri, 19 Jun 2020 11:10:24 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmEue-0007RA-Ln; Fri, 19 Jun 2020 11:10:24 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151204: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Fri, 19 Jun 2020 11:10:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151204 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151204/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 44 days Failing since 150942 2020-06-09 17:05:43 Z 9 days 10 attempts Testing same since 151061 2020-06-12 12:25:05 Z 6 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 2b77729888fb851ab96e7f77bc854122626b4861 Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Fri Jun 19 11:21:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 11:21:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmF5Q-0005SF-74; Fri, 19 Jun 2020 11:21:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmF5O-0005SA-H2 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 11:21:30 +0000 X-Inumbo-ID: 0507e2f8-b21f-11ea-bb68-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0507e2f8-b21f-11ea-bb68-12813bfff9fa; Fri, 19 Jun 2020 11:21:29 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 0wOIVdkT3G2h9ju7T5EzUsx6SBGvXUlgnK5eFMP+qBhY5WNfDQ/REVj9kYLvuRG/sdPXzUx31n RbhZmvqLcCnMXoLAWB5ZuDPC9EdvrtZhoDu/GErkMf4tITCnpa2zC1oFEypJM9IgktVXdUk+aR 5WfoKQuVIFIPvVFcE/pSRVA2HUO57TlDBrX0N7TQr1Wy9TAmSc+w5nlsbDr7QneoQXMjn4b1Ty Dm7au3d1WHSfCPmJpub+MIjbw7nU4cmg0+Xx/72eDnFH5YdFaWZMJyppxb0NuABRT1YY32uLZ1 Re0= X-SBRS: 2.7 X-MesageID: 20806862 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20806862" Date: Fri, 19 Jun 2020 13:21:19 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Martin Lucina Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200619112119.GY735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17deb17cec442f96cc7aba98ef4c047c@lucina.net> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote: > On 2020-06-18 13:46, Roger Pau Monné wrote: > > On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote: > > > At this point I don't really have a clear idea of how to progress, > > > comparing my implementation side-by-side with the original PV > > > Mini-OS-based > > > implementation doesn't show up any differences I can see. > > > > > > AFAICT the OCaml code I've also not changed in any material way, and > > > that > > > has been running in production on PV for years, so I'd be inclined > > > to think > > > the problem is in my reimplementation of the C parts, but where...? > > > > A good start would be to print the ISR and IRR lapic registers when > > blocked, to assert there are no pending vectors there. > > > > Can you apply the following patch to your Xen, rebuild and check the > > output of the 'l' debug key? > > > > Also add the output of the 'v' key. > > Had to fight the Xen Debian packages a bit as I wanted to patch the exact > same Xen (there are some failures when building on a system that has Xen > installed due to following symlinks when fixing shebangs). > > Here you go, when stuck during netfront setup, after allocating its event > channel, presumably waiting on Xenstore: > > 'e': > > (XEN) Event channel information for domain 3: > (XEN) Polling vCPUs: {} > (XEN) port [p/m/s] > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 > (XEN) 4 [0/1/1]: s=2 n=0 x=0 d=0 > > 'l': > > (XEN) d3v0 IRR: > ffff8301732dc200b > (XEN) d3v0 ISR: > ffff8301732dc100b Which version of Xen is this? AFAICT it doesn't have the support to print a bitmap. Do you think you could also pick commit 8cd9500958d818e3deabdd0d4164ea6fe1623d7c [0] and rebuild? (and print the info again). Thanks, Roger. [0] http://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=8cd9500958d818e3deabdd0d4164ea6fe1623d7c From xen-devel-bounces@lists.xenproject.org Fri Jun 19 11:22:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 11:22:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmF5r-0005W7-Nr; Fri, 19 Jun 2020 11:21:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmF5r-0005Ud-6D for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 11:21:59 +0000 X-Inumbo-ID: 12e54d3f-b21f-11ea-bb68-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 12e54d3f-b21f-11ea-bb68-12813bfff9fa; Fri, 19 Jun 2020 11:21:53 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: m/UIk+IX4OhBIYj0b83yvLEjPBBNyDvazVVdFlb1mUvnvNLYLj5hciS1LySpTayJnnxhEfJYAK lAumgPgX9GEfhTqBMr67BWay63HtuSzqaUIUp+XFu8mI3eStJxuwiPtv02Ri6OJOeYGvV1+uqd HMNZHPbFo5bTeegevcF/Tw9TNrsRtQgVEZO9qefDDB3fC/CscQVJnl/w17ptzdFMACZH6zC6wt ZRfyvthrtzHQ/JJRYYHziUezpaybO8W7Hbg0q8fGNvPGFXP2iklufgGYHQ70hobc5VQA9M/bdd Nv8= X-SBRS: 2.7 X-MesageID: 20806877 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20806877" Subject: Re: Event delivery and "domain blocking" on PVHv2 To: Martin Lucina , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> From: Andrew Cooper Message-ID: <0ebf1417-49e5-d9b2-81b0-b02c7e6cf833@citrix.com> Date: Fri, 19 Jun 2020 12:21:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <17deb17cec442f96cc7aba98ef4c047c@lucina.net> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/06/2020 11:28, Martin Lucina wrote: > On 2020-06-18 13:46, Roger Pau Monné wrote: >> On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote: >>> At this point I don't really have a clear idea of how to progress, >>> comparing my implementation side-by-side with the original PV >>> Mini-OS-based >>> implementation doesn't show up any differences I can see. >>> >>> AFAICT the OCaml code I've also not changed in any material way, and >>> that >>> has been running in production on PV for years, so I'd be inclined >>> to think >>> the problem is in my reimplementation of the C parts, but where...? >> >> A good start would be to print the ISR and IRR lapic registers when >> blocked, to assert there are no pending vectors there. >> >> Can you apply the following patch to your Xen, rebuild and check the >> output of the 'l' debug key? >> >> Also add the output of the 'v' key. > > Had to fight the Xen Debian packages a bit as I wanted to patch the > exact same Xen (there are some failures when building on a system that > has Xen installed due to following symlinks when fixing shebangs). > > Here you go, when stuck during netfront setup, after allocating its > event channel, presumably waiting on Xenstore: > > 'e': > > (XEN) Event channel information for domain 3: > (XEN) Polling vCPUs: {} > (XEN)     port [p/m/s] > (XEN)        1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 > (XEN)        2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > (XEN)        3 [1/0/1]: s=5 n=0 x=0 v=0 > (XEN)        4 [0/1/1]: s=2 n=0 x=0 d=0 > > 'l': > > (XEN) d3v0 > IRR:                                                          >                                                                          >                                                                          >                                      ffff8301732dc200b > (XEN) d3v0 > ISR:                                                          >                                                                          >                                                                          >                                      ffff8301732dc100b > > 'v': > > (XEN) *********** VMCS Areas ************** > (XEN) > (XEN) >>> Domain 3 <<< > (XEN)   VCPU 0 > (XEN) *** Guest State *** > (XEN) CR0: actual=0x0000000080000033, shadow=0x0000000080000033, > gh_mask=ffffffffffffffff > (XEN) CR4: actual=0x0000000000002660, shadow=0x0000000000000020, > gh_mask=ffffffffffc8f860 > (XEN) CR3 = 0x00000000002e9000 > (XEN) RSP = 0x000000000ffffec0 (0x000000000ffffec0)  RIP = > 0x0000000000209997 (0x0000000000209998) > (XEN) RFLAGS=0x00000297 (0x00000297)  DR7 = 0x0000000000000400 > (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 > (XEN)        sel  attr  limit   base > (XEN)   CS: 0008 0a099 ffffffff 0000000000000000 > (XEN)   DS: 0010 0c093 ffffffff 0000000000000000 > (XEN)   SS: 0010 0c093 ffffffff 0000000000000000 > (XEN)   ES: 0010 0c093 ffffffff 0000000000000000 > (XEN)   FS: 0000 1c000 ffffffff 0000000000000000 > (XEN)   GS: 0000 1c000 ffffffff 0000000000000000 > (XEN) GDTR:            00000027 00000000003e13c0 > (XEN) LDTR: 0000 10000 00000000 0000000000000000 > (XEN) IDTR:            000002ff 00000000003e10a8 > (XEN)   TR: 0018 0008b 00000068 00000000003e1040 > (XEN) EFER = 0x0000000000000000  PAT = 0x0007040600070406 > (XEN) PreemptionTimer = 0x00000000  SM Base = 0x00000000 > (XEN) DebugCtl = 0x0000000000000000  DebugExceptions = 0x0000000000000000 > (XEN) Interruptibility = 00000000  ActivityState = 00000000 > (XEN) *** Host State *** > (XEN) RIP = 0xffff82d08031dd30 (vmx_asm_vmexit_handler)  RSP = > 0xffff83009c057f70 > (XEN) CS=e008 SS=0000 DS=0000 ES=0000 FS=0000 GS=0000 TR=e040 > (XEN) FSBase=0000000000000000 GSBase=0000000000000000 > TRBase=ffff82d08055e000 > (XEN) GDTBase=ffff82d08042e000 IDTBase=ffff82d080559000 > (XEN) CR0=0000000080050033 CR3=0000000172a67000 CR4=00000000003526e0 > (XEN) Sysenter RSP=ffff83009c057fa0 CS:RIP=e008:ffff82d0803654b0 > (XEN) EFER = 0x0000000000000000  PAT = 0x0000050100070406 > (XEN) *** Control State *** > (XEN) PinBased=0000003f CPUBased=b6a065fa SecondaryExec=000014eb > (XEN) EntryControls=000053ff ExitControls=000fefff > (XEN) ExceptionBitmap=00060002 PFECmask=00000000 PFECmatch=00000000 > (XEN) VMEntry: intr_info=00000020 errcode=00000000 ilen=00000000 > (XEN) VMExit: intr_info=00000000 errcode=00000000 ilen=00000001 > (XEN)         reason=0000000c qualification=0000000000000000 > (XEN) IDTVectoring: info=00000000 errcode=00000000 > (XEN) TSC Offset = 0xffffffcf8453199b  TSC Multiplier = > 0x0000000000000000 > (XEN) TPR Threshold = 0x00  PostedIntrVec = 0x00 > (XEN) EPT pointer = 0x0000000172a0b01e  EPTP index = 0x0000 > (XEN) PLE Gap=00000080 Window=00001000 > (XEN) Virtual processor ID = 0x000e VMfunc controls = 0000000000000000 > (XEN) ************************************** > > RIP 0x209997 is the 'hlt' instruction in > mirage_xen_evtchn_block_domain() so we are indeed blocking waiting for > events to show up. I can't find this in the code, but it might be an x86-ism you're falling over here. Its not safe to use hlt with interrupts enabled, unless it is exactly `sti; hlt` where the STI instruction transitions the interrupt flag from clear to set (i.e. you had interrupts disabled beforehand). Otherwise you can take the interrupt intended to wake you on the before the hlt is executed. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 19 11:34:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 11:34:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFIB-0006YV-TS; Fri, 19 Jun 2020 11:34:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFIA-0006YQ-Eb for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 11:34:42 +0000 X-Inumbo-ID: dd497bf8-b220-11ea-bb68-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dd497bf8-b220-11ea-bb68-12813bfff9fa; Fri, 19 Jun 2020 11:34:41 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: PjcMl5Va+MTY639Yg3lLjm98tx6+wShgVKLNj0ereRPAGL+fmycsM2qYnK9+q0Yb+BcEpXaMhZ GKvYLm9b6GGXgiqqvIbCwYdL0CsuZ2BnSzhK/8Z2zzQeT+OW8y3Un1cO/5BEDbX5H5xqKckIJj 26P2/l/iHfH9hVtC36SMDEJYBhc9uUTaYKeexLSgC+lPV1zs8fGVkwvKHdqC1dnpsk7DId0Eua uUNc8NMg/P7QkzIEh9L9aMQZeJ8odPzbI4aetrIlIj3ITz6/IVGjoTk0tX1C2fAH8oXC56AWUn ly8= X-SBRS: 2.7 X-MesageID: 21247920 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="21247920" Date: Fri, 19 Jun 2020 13:34:34 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v2 1/7] xen/mm: lift 32 item limit from mfn/gfn arrays Message-ID: <20200619113434.GZ735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1060400786.9820894.1592523480084.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1060400786.9820894.1592523480084.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 01:38:00AM +0200, Michał Leszczyński wrote: > Replace on-stack array allocation with heap allocation > in order to lift the limit of 32 items in mfn/gfn arrays > when calling acquire_resource. I'm afraid this is not correct, you cannot allow unbounded amounts of items to be processed like this, it's likely that you manage to trigger the watchdog if the list is long enough, specially when doing set_foreign_p2m_entry. You need to process the items in batches (32 was IMO a good start), and then add support for hypercall continuations. Take a look at how XENMEM_populate_physmap just a couple of lines below makes use of hypercall_create_continuation. After processing every batch you need to check if hypercall_preempt_check returns true and if so use hypercall_create_continuation in order to encode a continuation. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 11:35:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 11:35:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFJ6-0006cR-77; Fri, 19 Jun 2020 11:35:40 +0000 Resent-Date: Fri, 19 Jun 2020 11:35:40 +0000 Resent-Message-Id: Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFJ5-0006cI-7A for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 11:35:39 +0000 X-Inumbo-ID: fe72a69c-b220-11ea-bb69-12813bfff9fa Received: from sender4-of-o57.zoho.com (unknown [136.143.188.57]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fe72a69c-b220-11ea-bb69-12813bfff9fa; Fri, 19 Jun 2020 11:35:37 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1592566531; cv=none; d=zohomail.com; s=zohoarc; b=b2pMXpKCg7eG7/iJYNfUk9ySJYrKyapqRyMLM7EJ4nUW/eTsBt/EpdxGSoX0k2zN0fKW/w0tSYMRuPmztZNh2pOfsM0ZxkDG/2ALk4BDqXOiciDeiIk15Q3kyiU28fOGJhv26MSteMjgBEcGSszg8Cx/ebgXzuat+uuOaLjUaxA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1592566531; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:Reply-To:Subject:To; bh=8rkKCoffJ1cpqvsTT8Tj6GQeo5jb65ooQUL/fz55PGY=; b=ZKi52E6/cdu42n0k/nlPb3eqw4atHiUDfPE36Y0Lk7NLpZ5FAoGQSFCEBRGFeT2R3lYLN3bOvrt7exCK/QFuys/KOi4F80KhWmuL7KSU+fjUCB8cVwLrtt7e6P9kGWq5pdTombIfJjp9tcvx8AHk9zNuf2QIHyG+fT9tRAK0tio= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=no-reply@patchew.org; dmarc=pass header.from= header.from= Received: from [172.17.0.3] (23.253.156.214 [23.253.156.214]) by mx.zohomail.com with SMTPS id 1592566528833368.792353190996; Fri, 19 Jun 2020 04:35:28 -0700 (PDT) Message-ID: <159256652740.466.9253850977314410773@d1fd068a5071> Subject: Re: [PATCH] xen: Actually fix build without passthrough In-Reply-To: <20200619103115.254127-1-anthony.perard@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Resent-From: From: no-reply@patchew.org To: anthony.perard@citrix.com Date: Fri, 19 Jun 2020 04:35:28 -0700 (PDT) X-ZohoMailClient: External X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: qemu-devel@nongnu.org Cc: sstabellini@kernel.org, paul@xen.org, qemu-devel@nongnu.org, xen-devel@lists.xenproject.org, anthony.perard@citrix.com, pbonzini@redhat.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" UGF0Y2hldyBVUkw6IGh0dHBzOi8vcGF0Y2hldy5vcmcvUUVNVS8yMDIwMDYxOTEwMzExNS4yNTQx MjctMS1hbnRob255LnBlcmFyZEBjaXRyaXguY29tLwoKCgpIaSwKClRoaXMgc2VyaWVzIGZhaWxl ZCB0aGUgYXNhbiBidWlsZCB0ZXN0LiBQbGVhc2UgZmluZCB0aGUgdGVzdGluZyBjb21tYW5kcyBh bmQKdGhlaXIgb3V0cHV0IGJlbG93LiBJZiB5b3UgaGF2ZSBEb2NrZXIgaW5zdGFsbGVkLCB5b3Ug Y2FuIHByb2JhYmx5IHJlcHJvZHVjZSBpdApsb2NhbGx5LgoKPT09IFRFU1QgU0NSSVBUIEJFR0lO ID09PQojIS9iaW4vYmFzaApleHBvcnQgQVJDSD14ODZfNjQKbWFrZSBkb2NrZXItaW1hZ2UtZmVk b3JhIFY9MSBORVRXT1JLPTEKdGltZSBtYWtlIGRvY2tlci10ZXN0LWRlYnVnQGZlZG9yYSBUQVJH RVRfTElTVD14ODZfNjQtc29mdG1tdSBKPTE0IE5FVFdPUks9MQo9PT0gVEVTVCBTQ1JJUFQgRU5E ID09PQoKICBDQyAgICAgIHFnYS9tYWluLm8KICBDQyAgICAgIHFnYS9jb21tYW5kcy1wb3NpeC5v CiAgQ0MgICAgICBxZ2EvY2hhbm5lbC1wb3NpeC5vCi91c3IvYmluL2xkOiAvdXNyL2xpYjY0L2Ns YW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVy Y2VwdG9yc192Zm9yay5TLm8pOiB3YXJuaW5nOiBjb21tb24gb2YgYCAgQ0MgICAgICBxZ2EvcWFw aS1nZW5lcmF0ZWQvcWdhLXFhcGktdHlwZXMubwpfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycg b3ZlcnJpZGRlbiBieSBkZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGli L2xpbnV4L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8p CiAgQ0MgICAgICBxZ2EvcWFwaS1nZW5lcmF0ZWQvcWdhLXFhcGktdmlzaXQubwogIENDICAgICAg cWdhL3FhcGktZ2VuZXJhdGVkL3FnYS1xYXBpLWNvbW1hbmRzLm8KLS0tCiAgR0VOICAgICBkb2Nz L2ludGVyb3AvcWVtdS1nYS1yZWYuaHRtbAogIEdFTiAgICAgZG9jcy9pbnRlcm9wL3FlbXUtZ2Et cmVmLnR4dAogIEFSICAgICAgbGlidmhvc3QtdXNlci5hCi91c3IvYmluL2xkOiAvdXNyL2xpYjY0 L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2lu dGVyY2VwdG9yc192Zm9yay5TLm8pOiB3YXJuaW5nOiBjb21tb24gb2YgYF9faW50ZXJjZXB0aW9u OjpyZWFsX3Zmb3JrJyBvdmVycmlkZGVuIGJ5IGRlZmluaXRpb24gZnJvbSAvdXNyL2xpYjY0L2Ns YW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVy Y2VwdG9ycy5jcHAubykKICBHRU4gICAgIGRvY3MvaW50ZXJvcC9xZW11LWdhLXJlZi43CiAgQVMg ICAgICBwYy1iaW9zL29wdGlvbnJvbS9wdmgubwogIEFTICAgICAgcGMtYmlvcy9vcHRpb25yb20v bXVsdGlib290Lm8KLS0tCiAgTElOSyAgICBxZW11LWdhCiAgTElOSyAgICBxZW11LWtleW1hcAog IExJTksgICAgaXZzaG1lbS1jbGllbnQKL3Vzci9iaW4vbGQ6IC91c3IvbGliNjQvY2xhbmcvMTAu MC4wL2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3Jz X3Zmb3JrLlMubyk6IHdhcm5pbmc6IGNvbW1vbiBvZiBgX19pbnRlcmNlcHRpb246OnJlYWxfdmZv cmsnIG92ZXJyaWRkZW4gYnkgZGVmaW5pdGlvbiBmcm9tIC91c3IvbGliNjQvY2xhbmcvMTAuMC4w L2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzLmNw cC5vKQovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNs YW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTogd2Fybmlu ZzogY29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRlbiBieSBk ZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5n X3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCiAgTElOSyAgICBpdnNo bWVtLXNlcnZlcgovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4 L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTog d2FybmluZzogY29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRl biBieSBkZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xp YmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCiAgTElOSyAg ICBxZW11LW5iZAovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4 L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTog d2FybmluZzogY29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRl biBieSBkZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xp YmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCi91c3IvYmlu L2xkOiAvdXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14 ODZfNjQuYShhc2FuX2ludGVyY2VwdG9yc192Zm9yay5TLm8pOiB3YXJuaW5nOiBjb21tb24gb2Yg YF9faW50ZXJjZXB0aW9uOjpyZWFsX3Zmb3JrJyBvdmVycmlkZGVuIGJ5IGRlZmluaXRpb24gZnJv bSAvdXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZf NjQuYShhc2FuX2ludGVyY2VwdG9ycy5jcHAubykKICBMSU5LICAgIHFlbXUtc3RvcmFnZS1kYWVt b24KICBMSU5LICAgIHFlbXUtaW1nCi91c3IvYmluL2xkOiAvdXNyL2xpYjY0L2NsYW5nLzEwLjAu MC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9yc192 Zm9yay5TLm8pOiB3YXJuaW5nOiBjb21tb24gb2YgYF9faW50ZXJjZXB0aW9uOjpyZWFsX3Zmb3Jr JyBvdmVycmlkZGVuIGJ5IGRlZmluaXRpb24gZnJvbSAvdXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9s aWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9ycy5jcHAu bykKICBMSU5LICAgIHFlbXUtaW8KL3Vzci9iaW4vbGQ6IC91c3IvbGliNjQvY2xhbmcvMTAuMC4w L2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzX3Zm b3JrLlMubyk6IHdhcm5pbmc6IGNvbW1vbiBvZiBgX19pbnRlcmNlcHRpb246OnJlYWxfdmZvcmsn IG92ZXJyaWRkZW4gYnkgZGVmaW5pdGlvbiBmcm9tIC91c3IvbGliNjQvY2xhbmcvMTAuMC4wL2xp Yi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzLmNwcC5v KQovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5n X3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTogd2FybmluZzog Y29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRlbiBieSBkZWZp bml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5nX3J0 LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCiAgTElOSyAgICBxZW11LWVk aWQKICBMSU5LICAgIGZzZGV2L3ZpcnRmcy1wcm94eS1oZWxwZXIKL3Vzci9iaW4vbGQ6IC91c3Iv bGliNjQvY2xhbmcvMTAuMC4wL2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFz YW5faW50ZXJjZXB0b3JzX3Zmb3JrLlMubyk6IHdhcm5pbmc6IGNvbW1vbiBvZiBgX19pbnRlcmNl cHRpb246OnJlYWxfdmZvcmsnIG92ZXJyaWRkZW4gYnkgZGVmaW5pdGlvbiBmcm9tIC91c3IvbGli NjQvY2xhbmcvMTAuMC4wL2xpYi9saW51eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5f aW50ZXJjZXB0b3JzLmNwcC5vKQogIExJTksgICAgc2NzaS9xZW11LXByLWhlbHBlcgovdXNyL2Jp bi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5nX3J0LmFzYW4t eDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTogd2FybmluZzogY29tbW9uIG9m IGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRlbiBieSBkZWZpbml0aW9uIGZy b20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5nX3J0LmFzYW4teDg2 XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCiAgTElOSyAgICBxZW11LWJyaWRnZS1oZWxw ZXIKL3Vzci9iaW4vbGQ6IC91c3IvbGliNjQvY2xhbmcvMTAuMC4wL2xpYi9saW51eC9saWJjbGFu Z19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzX3Zmb3JrLlMubyk6IHdhcm5pbmc6 IGNvbW1vbiBvZiBgX19pbnRlcmNlcHRpb246OnJlYWxfdmZvcmsnIG92ZXJyaWRkZW4gYnkgZGVm aW5pdGlvbiBmcm9tIC91c3IvbGliNjQvY2xhbmcvMTAuMC4wL2xpYi9saW51eC9saWJjbGFuZ19y dC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzLmNwcC5vKQogIExJTksgICAgdmlydGlv ZnNkCi91c3IvYmluL2xkOiAvdXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xh bmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9yc192Zm9yay5TLm8pOiB3YXJuaW5n OiBjb21tb24gb2YgYF9faW50ZXJjZXB0aW9uOjpyZWFsX3Zmb3JrJyBvdmVycmlkZGVuIGJ5IGRl ZmluaXRpb24gZnJvbSAvdXNyL2xpYjY0L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdf cnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVyY2VwdG9ycy5jcHAubykKICBMSU5LICAgIHZob3N0 LXVzZXItaW5wdXQKL3Vzci9iaW4vbGQ6IC91c3IvbGliNjQvY2xhbmcvMTAuMC4wL2xpYi9saW51 eC9saWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzX3Zmb3JrLlMubyk6 IHdhcm5pbmc6IGNvbW1vbiBvZiBgX19pbnRlcmNlcHRpb246OnJlYWxfdmZvcmsnIG92ZXJyaWRk ZW4gYnkgZGVmaW5pdGlvbiBmcm9tIC91c3IvbGliNjQvY2xhbmcvMTAuMC4wL2xpYi9saW51eC9s aWJjbGFuZ19ydC5hc2FuLXg4Nl82NC5hKGFzYW5faW50ZXJjZXB0b3JzLmNwcC5vKQovdXNyL2Jp bi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5nX3J0LmFzYW4t eDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTogd2FybmluZzogY29tbW9uIG9m IGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRlbiBieSBkZWZpbml0aW9uIGZy b20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xpYmNsYW5nX3J0LmFzYW4teDg2 XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCiAgR0VOICAgICB4ODZfNjQtc29mdG1tdS9o bXAtY29tbWFuZHMuaAogIEdFTiAgICAgeDg2XzY0LXNvZnRtbXUvaG1wLWNvbW1hbmRzLWluZm8u aAogIEdFTiAgICAgeDg2XzY0LXNvZnRtbXUvY29uZmlnLWRldmljZXMuaAotLS0KICBDQyAgICAg IHg4Nl82NC1zb2Z0bW11L2dkYnN0dWIteG1sLm8KICBDQyAgICAgIHg4Nl82NC1zb2Z0bW11L3Ry YWNlL2dlbmVyYXRlZC1oZWxwZXJzLm8KICBMSU5LICAgIHg4Nl82NC1zb2Z0bW11L3FlbXUtc3lz dGVtLXg4Nl82NAovdXNyL2Jpbi9sZDogL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4 L2xpYmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnNfdmZvcmsuUy5vKTog d2FybmluZzogY29tbW9uIG9mIGBfX2ludGVyY2VwdGlvbjo6cmVhbF92Zm9yaycgb3ZlcnJpZGRl biBieSBkZWZpbml0aW9uIGZyb20gL3Vzci9saWI2NC9jbGFuZy8xMC4wLjAvbGliL2xpbnV4L2xp YmNsYW5nX3J0LmFzYW4teDg2XzY0LmEoYXNhbl9pbnRlcmNlcHRvcnMuY3BwLm8pCmNvbW1vbi5y YzogbGluZSA1MDogdGVzdDogY2hlY2s6IGJpbmFyeSBvcGVyYXRvciBleHBlY3RlZAoocHJpbnRm ICcjZGVmaW5lIFFFTVVfUEtHVkVSU0lPTiAiIlxuJzsgcHJpbnRmICcjZGVmaW5lIFFFTVVfRlVM TF9WRVJTSU9OICI1LjAuNTAiXG4nOyApID4gcWVtdS12ZXJzaW9uLmgudG1wCm1ha2UgLUMgL3Rt cC9xZW11LXRlc3Qvc3JjL3NsaXJwIEJVSUxEX0RJUj0iL3RtcC9xZW11LXRlc3QvYnVpbGQvc2xp cnAiIFBLR19DT05GSUc9InBrZy1jb25maWciIENDPSJjbGFuZyIgQVI9ImFyIiAgICAgIExEPSJs ZCIgUkFOTElCPSJyYW5saWIiIENGTEFHUz0iLUkvdXNyL2luY2x1ZGUvcGl4bWFuLTEgICAtV2Vy cm9yIC1mc2FuaXRpemU9dW5kZWZpbmVkIC1mc2FuaXRpemU9YWRkcmVzcyAgLXB0aHJlYWQgLUkv dXNyL2luY2x1ZGUvZ2xpYi0yLjAgLUkvdXNyL2xpYjY0L2dsaWItMi4wL2luY2x1ZGUgIC1mUElF IC1EUElFIC1tNjQgLW1jeDE2IC1EX0dOVV9TT1VSQ0UgLURfRklMRV9PRkZTRVRfQklUUz02NCAt RF9MQVJHRUZJTEVfU09VUkNFIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdyZWR1bmRhbnQtZGVjbHMg LVdhbGwgLVd1bmRlZiAtV3dyaXRlLXN0cmluZ3MgLVdtaXNzaW5nLXByb3RvdHlwZXMgLWZuby1z dHJpY3QtYWxpYXNpbmcgLWZuby1jb21tb24gLWZ3cmFwdiAtc3RkPWdudTk5ICAtV29sZC1zdHls ZS1kZWZpbml0aW9uIC1XdHlwZS1saW1pdHMgLVdmb3JtYXQtc2VjdXJpdHkgLVdmb3JtYXQteTJr IC1XaW5pdC1zZWxmIC1XaWdub3JlZC1xdWFsaWZpZXJzIC1XZW1wdHktYm9keSAtV25lc3RlZC1l eHRlcm5zIC1XZW5kaWYtbGFiZWxzIC1XZXhwYW5zaW9uLXRvLWRlZmluZWQgLVduby1pbml0aWFs aXplci1vdmVycmlkZXMgLVduby1taXNzaW5nLWluY2x1ZGUtZGlycyAtV25vLXNoaWZ0LW5lZ2F0 aXZlLXZhbHVlIC1Xbm8tc3RyaW5nLXBsdXMtaW50IC1Xbm8tdHlwZWRlZi1yZWRlZmluaXRpb24g LVduby10YXV0b2xvZ2ljYWwtdHlwZS1saW1pdC1jb21wYXJlIC1mc3RhY2stcHJvdGVjdG9yLXN0 cm9uZyAgIC1JL3Vzci9pbmNsdWRlL3AxMS1raXQtMSAgIC1EU1RSVUNUX0lPVkVDX0RFRklORUQg IC1JL3Vzci9pbmNsdWRlL2xpYnBuZzE2ICAtSS91c3IvaW5jbHVkZS9zcGljZS0xIC1JL3Vzci9p bmNsdWRlL3NwaWNlLXNlcnZlciAtSS91c3IvaW5jbHVkZS9jYWNhcmQgLUkvdXNyL2luY2x1ZGUv Z2xpYi0yLjAgLUkvdXNyL2xpYjY0L2dsaWItMi4wL2luY2x1ZGUgLUkvdXNyL2luY2x1ZGUvbnNz MyAtSS91c3IvaW5jbHVkZS9uc3ByNCAtcHRocmVhZCAtSS91c3IvaW5jbHVkZS9saWJtb3VudCAt SS91c3IvaW5jbHVkZS9ibGtpZCAtSS91c3IvaW5jbHVkZS9waXhtYW4tMSAgIC1JL3RtcC9xZW11 LXRlc3Qvc3JjL3Rlc3RzIC1JL3RtcC9xZW11LXRlc3Qvc3JjL3Rlc3RzL3F0ZXN0IC1nICIgTERG TEFHUz0iLVdsLC0td2Fybi1jb21tb24gLWZzYW5pdGl6ZT11bmRlZmluZWQgLWZzYW5pdGl6ZT1h ZGRyZXNzIC1XbCwteixyZWxybyAtV2wsLXosbm93IC1waWUgLW02NCAgLWZzdGFjay1wcm90ZWN0 b3Itc3Ryb25nIgotLS0KY2xhbmcgLWlxdW90ZSAvdG1wL3FlbXUtdGVzdC9idWlsZC90ZXN0cyAt aXF1b3RlIHRlc3RzIC1pcXVvdGUgL3RtcC9xZW11LXRlc3Qvc3JjL3RjZy9pMzg2IC1pc3lzdGVt IC90bXAvcWVtdS10ZXN0L3NyYy9saW51eC1oZWFkZXJzIC1pc3lzdGVtIC90bXAvcWVtdS10ZXN0 L2J1aWxkL2xpbnV4LWhlYWRlcnMgLWlxdW90ZSAuIC1pcXVvdGUgL3RtcC9xZW11LXRlc3Qvc3Jj IC1pcXVvdGUgL3RtcC9xZW11LXRlc3Qvc3JjL2FjY2VsL3RjZyAtaXF1b3RlIC90bXAvcWVtdS10 ZXN0L3NyYy9pbmNsdWRlIC1pcXVvdGUgL3RtcC9xZW11LXRlc3Qvc3JjL2Rpc2FzL2xpYnZpeGwg LUkvdXNyL2luY2x1ZGUvcGl4bWFuLTEgICAtV2Vycm9yIC1mc2FuaXRpemU9dW5kZWZpbmVkIC1m c2FuaXRpemU9YWRkcmVzcyAgLXB0aHJlYWQgLUkvdXNyL2luY2x1ZGUvZ2xpYi0yLjAgLUkvdXNy L2xpYjY0L2dsaWItMi4wL2luY2x1ZGUgIC1mUElFIC1EUElFIC1tNjQgLW1jeDE2IC1EX0dOVV9T T1VSQ0UgLURfRklMRV9PRkZTRVRfQklUUz02NCAtRF9MQVJHRUZJTEVfU09VUkNFIC1Xc3RyaWN0 LXByb3RvdHlwZXMgLVdyZWR1bmRhbnQtZGVjbHMgLVdhbGwgLVd1bmRlZiAtV3dyaXRlLXN0cmlu Z3MgLVdtaXNzaW5nLXByb3RvdHlwZXMgLWZuby1zdHJpY3QtYWxpYXNpbmcgLWZuby1jb21tb24g LWZ3cmFwdiAtc3RkPWdudTk5ICAtV29sZC1zdHlsZS1kZWZpbml0aW9uIC1XdHlwZS1saW1pdHMg LVdmb3JtYXQtc2VjdXJpdHkgLVdmb3JtYXQteTJrIC1XaW5pdC1zZWxmIC1XaWdub3JlZC1xdWFs aWZpZXJzIC1XZW1wdHktYm9keSAtV25lc3RlZC1leHRlcm5zIC1XZW5kaWYtbGFiZWxzIC1XZXhw YW5zaW9uLXRvLWRlZmluZWQgLVduby1pbml0aWFsaXplci1vdmVycmlkZXMgLVduby1taXNzaW5n LWluY2x1ZGUtZGlycyAtV25vLXNoaWZ0LW5lZ2F0aXZlLXZhbHVlIC1Xbm8tc3RyaW5nLXBsdXMt aW50IC1Xbm8tdHlwZWRlZi1yZWRlZmluaXRpb24gLVduby10YXV0b2xvZ2ljYWwtdHlwZS1saW1p dC1jb21wYXJlIC1mc3RhY2stcHJvdGVjdG9yLXN0cm9uZyAgIC1JL3Vzci9pbmNsdWRlL3AxMS1r aXQtMSAgIC1EU1RSVUNUX0lPVkVDX0RFRklORUQgIC1JL3Vzci9pbmNsdWRlL2xpYnBuZzE2ICAt SS91c3IvaW5jbHVkZS9zcGljZS0xIC1JL3Vzci9pbmNsdWRlL3NwaWNlLXNlcnZlciAtSS91c3Iv aW5jbHVkZS9jYWNhcmQgLUkvdXNyL2luY2x1ZGUvZ2xpYi0yLjAgLUkvdXNyL2xpYjY0L2dsaWIt Mi4wL2luY2x1ZGUgLUkvdXNyL2luY2x1ZGUvbnNzMyAtSS91c3IvaW5jbHVkZS9uc3ByNCAtcHRo cmVhZCAtSS91c3IvaW5jbHVkZS9saWJtb3VudCAtSS91c3IvaW5jbHVkZS9ibGtpZCAtSS91c3Iv aW5jbHVkZS9waXhtYW4tMSAgIC1JL3RtcC9xZW11LXRlc3Qvc3JjL3Rlc3RzIC1JL3RtcC9xZW11 LXRlc3Qvc3JjL3Rlc3RzL3F0ZXN0IC1NTUQgLU1QIC1NVCB0ZXN0cy90ZXN0LXFncmFwaC5vIC1N RiB0ZXN0cy90ZXN0LXFncmFwaC5kIC1nICAgLWMgLW8gdGVzdHMvdGVzdC1xZ3JhcGgubyAvdG1w L3FlbXUtdGVzdC9zcmMvdGVzdHMvdGVzdC1xZ3JhcGguYwpjbGFuZyAtaXF1b3RlIC90bXAvcWVt dS10ZXN0L2J1aWxkL3Rlc3RzL3F0ZXN0L2xpYnFvcyAtaXF1b3RlIHRlc3RzL3F0ZXN0L2xpYnFv cyAtaXF1b3RlIC90bXAvcWVtdS10ZXN0L3NyYy90Y2cvaTM4NiAtaXN5c3RlbSAvdG1wL3FlbXUt dGVzdC9zcmMvbGludXgtaGVhZGVycyAtaXN5c3RlbSAvdG1wL3FlbXUtdGVzdC9idWlsZC9saW51 eC1oZWFkZXJzIC1pcXVvdGUgLiAtaXF1b3RlIC90bXAvcWVtdS10ZXN0L3NyYyAtaXF1b3RlIC90 bXAvcWVtdS10ZXN0L3NyYy9hY2NlbC90Y2cgLWlxdW90ZSAvdG1wL3FlbXUtdGVzdC9zcmMvaW5j bHVkZSAtaXF1b3RlIC90bXAvcWVtdS10ZXN0L3NyYy9kaXNhcy9saWJ2aXhsIC1JL3Vzci9pbmNs dWRlL3BpeG1hbi0xICAgLVdlcnJvciAtZnNhbml0aXplPXVuZGVmaW5lZCAtZnNhbml0aXplPWFk ZHJlc3MgIC1wdGhyZWFkIC1JL3Vzci9pbmNsdWRlL2dsaWItMi4wIC1JL3Vzci9saWI2NC9nbGli LTIuMC9pbmNsdWRlICAtZlBJRSAtRFBJRSAtbTY0IC1tY3gxNiAtRF9HTlVfU09VUkNFIC1EX0ZJ TEVfT0ZGU0VUX0JJVFM9NjQgLURfTEFSR0VGSUxFX1NPVVJDRSAtV3N0cmljdC1wcm90b3R5cGVz IC1XcmVkdW5kYW50LWRlY2xzIC1XYWxsIC1XdW5kZWYgLVd3cml0ZS1zdHJpbmdzIC1XbWlzc2lu Zy1wcm90b3R5cGVzIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1mbm8tY29tbW9uIC1md3JhcHYgLXN0 ZD1nbnU5OSAgLVdvbGQtc3R5bGUtZGVmaW5pdGlvbiAtV3R5cGUtbGltaXRzIC1XZm9ybWF0LXNl Y3VyaXR5IC1XZm9ybWF0LXkyayAtV2luaXQtc2VsZiAtV2lnbm9yZWQtcXVhbGlmaWVycyAtV2Vt cHR5LWJvZHkgLVduZXN0ZWQtZXh0ZXJucyAtV2VuZGlmLWxhYmVscyAtV2V4cGFuc2lvbi10by1k ZWZpbmVkIC1Xbm8taW5pdGlhbGl6ZXItb3ZlcnJpZGVzIC1Xbm8tbWlzc2luZy1pbmNsdWRlLWRp cnMgLVduby1zaGlmdC1uZWdhdGl2ZS12YWx1ZSAtV25vLXN0cmluZy1wbHVzLWludCAtV25vLXR5 cGVkZWYtcmVkZWZpbml0aW9uIC1Xbm8tdGF1dG9sb2dpY2FsLXR5cGUtbGltaXQtY29tcGFyZSAt ZnN0YWNrLXByb3RlY3Rvci1zdHJvbmcgICAtSS91c3IvaW5jbHVkZS9wMTEta2l0LTEgICAtRFNU UlVDVF9JT1ZFQ19ERUZJTkVEICAtSS91c3IvaW5jbHVkZS9saWJwbmcxNiAgLUkvdXNyL2luY2x1 ZGUvc3BpY2UtMSAtSS91c3IvaW5jbHVkZS9zcGljZS1zZXJ2ZXIgLUkvdXNyL2luY2x1ZGUvY2Fj YXJkIC1JL3Vzci9pbmNsdWRlL2dsaWItMi4wIC1JL3Vzci9saWI2NC9nbGliLTIuMC9pbmNsdWRl IC1JL3Vzci9pbmNsdWRlL25zczMgLUkvdXNyL2luY2x1ZGUvbnNwcjQgLXB0aHJlYWQgLUkvdXNy L2luY2x1ZGUvbGlibW91bnQgLUkvdXNyL2luY2x1ZGUvYmxraWQgLUkvdXNyL2luY2x1ZGUvcGl4 bWFuLTEgICAtSS90bXAvcWVtdS10ZXN0L3NyYy90ZXN0cyAtSS90bXAvcWVtdS10ZXN0L3NyYy90 ZXN0cy9xdGVzdCAtTU1EIC1NUCAtTVQgdGVzdHMvcXRlc3QvbGlicW9zL3FncmFwaC5vIC1NRiB0 ZXN0cy9xdGVzdC9saWJxb3MvcWdyYXBoLmQgLWcgICAtYyAtbyB0ZXN0cy9xdGVzdC9saWJxb3Mv cWdyYXBoLm8gL3RtcC9xZW11LXRlc3Qvc3JjL3Rlc3RzL3F0ZXN0L2xpYnFvcy9xZ3JhcGguYwpt YWtlICBCVUlMRF9ESVI9L3RtcC9xZW11LXRlc3QvYnVpbGQgLUMgL3RtcC9xZW11LXRlc3QvYnVp bGQvdGVzdHMvZnAvIFY9IjEiIGZwLXRlc3QKL3RtcC9xZW11LXRlc3Qvc3JjL3Rlc3RzL3FodC1i ZW5jaC5jOjI4NzoyOTogZXJyb3I6IGltcGxpY2l0IGNvbnZlcnNpb24gZnJvbSAndW5zaWduZWQg bG9uZycgdG8gJ2RvdWJsZScgY2hhbmdlcyB2YWx1ZSBmcm9tIDE4NDQ2NzQ0MDczNzA5NTUxNjE1 IHRvIDE4NDQ2NzQ0MDczNzA5NTUxNjE2IFstV2Vycm9yLC1XaW1wbGljaXQtaW50LWZsb2F0LWNv bnZlcnNpb25dCiAgICAgICAgKnRocmVzaG9sZCA9IHJhdGUgKiBVSU5UNjRfTUFYOwogICAgICAg ICAgICAgICAgICAgICAgICAgIH4gXn5+fn5+fn5+fgovdXNyL2luY2x1ZGUvc3RkaW50Lmg6MTMw OjIzOiBub3RlOiBleHBhbmRlZCBmcm9tIG1hY3JvICdVSU5UNjRfTUFYJwotLS0KMTg0NDY3NDQw NzM3MDk1NTE2MTVVTApefn5+fn5+fn5+fn5+fn5+fn5+fn5+CjEgZXJyb3IgZ2VuZXJhdGVkLgpt YWtlOiAqKiogWy90bXAvcWVtdS10ZXN0L3NyYy9ydWxlcy5tYWs6Njk6IHRlc3RzL3FodC1iZW5j aC5vXSBFcnJvciAxCm1ha2U6ICoqKiBXYWl0aW5nIGZvciB1bmZpbmlzaGVkIGpvYnMuLi4uCm1h a2VbMV06IEVudGVyaW5nIGRpcmVjdG9yeSAnL3RtcC9xZW11LXRlc3QvYnVpbGQvdGVzdHMvZnAn CmNsYW5nIC1pcXVvdGUgL3RtcC9xZW11LXRlc3QvYnVpbGQvLiAtaXF1b3RlIC4gLWlxdW90ZSAv dG1wL3FlbXUtdGVzdC9zcmMvdGNnL2kzODYgLWlzeXN0ZW0gL3RtcC9xZW11LXRlc3Qvc3JjL2xp bnV4LWhlYWRlcnMgLWlzeXN0ZW0gL3RtcC9xZW11LXRlc3QvYnVpbGQvbGludXgtaGVhZGVycyAt aXF1b3RlIC4gLWlxdW90ZSAvdG1wL3FlbXUtdGVzdC9zcmMgLWlxdW90ZSAvdG1wL3FlbXUtdGVz dC9zcmMvYWNjZWwvdGNnIC1pcXVvdGUgL3RtcC9xZW11LXRlc3Qvc3JjL2luY2x1ZGUgLWlxdW90 ZSAvdG1wL3FlbXUtdGVzdC9zcmMvZGlzYXMvbGlidml4bCAtSS90bXAvcWVtdS10ZXN0L3NyYy90 ZXN0cy9mcCAtSS90bXAvcWVtdS10ZXN0L3NyYy90ZXN0cy9mcC9iZXJrZWxleS1zb2Z0ZmxvYXQt My9zb3VyY2UvaW5jbHVkZSAtSS90bXAvcWVtdS10ZXN0L3NyYy90ZXN0cy9mcC9iZXJrZWxleS1z b2Z0ZmxvYXQtMy9zb3VyY2UvODA4Ni1TU0UgLUkvdG1wL3FlbXUtdGVzdC9zcmMvdGVzdHMvZnAv YmVya2VsZXktdGVzdGZsb2F0LTMvc291cmNlIC1JL3Vzci9pbmNsdWRlL3BpeG1hbi0xIC1XZXJy b3IgLWZzYW5pdGl6ZT11bmRlZmluZWQgLWZzYW5pdGl6ZT1hZGRyZXNzIC1wdGhyZWFkIC1JL3Vz ci9pbmNsdWRlL2dsaWItMi4wIC1JL3Vzci9saWI2NC9nbGliLTIuMC9pbmNsdWRlIC1mUElFIC1E UElFIC1tNjQgLW1jeDE2IC1EX0dOVV9TT1VSQ0UgLURfRklMRV9PRkZTRVRfQklUUz02NCAtRF9M QVJHRUZJTEVfU09VUkNFIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdyZWR1bmRhbnQtZGVjbHMgLVdh bGwgLVd1bmRlZiAtV3dyaXRlLXN0cmluZ3MgLVdtaXNzaW5nLXByb3RvdHlwZXMgLWZuby1zdHJp Y3QtYWxpYXNpbmcgLWZuby1jb21tb24gLWZ3cmFwdiAtc3RkPWdudTk5IC1Xb2xkLXN0eWxlLWRl ZmluaXRpb24gLVd0eXBlLWxpbWl0cyAtV2Zvcm1hdC1zZWN1cml0eSAtV2Zvcm1hdC15MmsgLVdp bml0LXNlbGYgLVdpZ25vcmVkLXF1YWxpZmllcnMgLVdlbXB0eS1ib2R5IC1XbmVzdGVkLWV4dGVy bnMgLVdlbmRpZi1sYWJlbHMgLVdleHBhbnNpb24tdG8tZGVmaW5lZCAtV25vLWluaXRpYWxpemVy LW92ZXJyaWRlcyAtV25vLW1pc3NpbmctaW5jbHVkZS1kaXJzIC1Xbm8tc2hpZnQtbmVnYXRpdmUt dmFsdWUgLVduby1zdHJpbmctcGx1cy1pbnQgLVduby10eXBlZGVmLXJlZGVmaW5pdGlvbiAtV25v LXRhdXRvbG9naWNhbC10eXBlLWxpbWl0LWNvbXBhcmUgLWZzdGFjay1wcm90ZWN0b3Itc3Ryb25n IC1JL3Vzci9pbmNsdWRlL3AxMS1raXQtMSAtRFNUUlVDVF9JT1ZFQ19ERUZJTkVEIC1JL3Vzci9p bmNsdWRlL2xpYnBuZzE2IC1JL3Vzci9pbmNsdWRlL3NwaWNlLTEgLUkvdXNyL2luY2x1ZGUvc3Bp Y2Utc2VydmVyIC1JL3Vzci9pbmNsdWRlL2NhY2FyZCAtSS91c3IvaW5jbHVkZS9nbGliLTIuMCAt SS91c3IvbGliNjQvZ2xpYi0yLjAvaW5jbHVkZSAtSS91c3IvaW5jbHVkZS9uc3MzIC1JL3Vzci9p bmNsdWRlL25zcHI0IC1wdGhyZWFkIC1JL3Vzci9pbmNsdWRlL2xpYm1vdW50IC1JL3Vzci9pbmNs dWRlL2Jsa2lkIC1JL3Vzci9pbmNsdWRlL3BpeG1hbi0xIC1ESFdfUE9JU09OX0ggLURUQVJHRVRf QVJNICAtRFNPRlRGTE9BVF9ST1VORF9PREQgLURJTkxJTkVfTEVWRUw9NSAtRFNPRlRGTE9BVF9G QVNUX0RJVjMyVE8xNiAtRFNPRlRGTE9BVF9GQVNUX0RJVjY0VE8zMiAtRFNPRlRGTE9BVF9GQVNU X0lOVDY0ICAtREZMT0FUMTYgLURGTE9BVDY0IC1ERVhURkxPQVQ4MCAtREZMT0FUMTI4IC1ERkxP QVRfUk9VTkRfT0REIC1ETE9OR19ET1VCTEVfSVNfRVhURkxPQVQ4MCAtTU1EIC1NUCAtTVQgZnAt dGVzdC5vIC1NRiAuL2ZwLXRlc3QuZCAtZyAgIC1jIC1vIGZwLXRlc3QubyAvdG1wL3FlbXUtdGVz dC9zcmMvdGVzdHMvZnAvZnAtdGVzdC5jCi0tLQpybSAtZiBsaWJ0ZXN0ZmxvYXQuYSAmJiBhciBy Y3MgbGlidGVzdGZsb2F0LmEgdWludDEyOF9pbmxpbmUubyB1aW50MTI4Lm8gZmFpbC5vIGZ1bmN0 aW9uc19jb21tb24ubyBmdW5jdGlvbkluZm9zLm8gc3RhbmRhcmRGdW5jdGlvbkluZm9zLm8gcmFu ZG9tLm8gZ2VuQ2FzZXNfY29tbW9uLm8gZ2VuQ2FzZXNfdWkzMi5vIGdlbkNhc2VzX3VpNjQubyBn ZW5DYXNlc19pMzIubyBnZW5DYXNlc19pNjQubyBnZW5DYXNlc19mMTYubyBnZW5DYXNlc19mMzIu byBnZW5DYXNlc19mNjQubyBnZW5DYXNlc19leHRGODAubyBnZW5DYXNlc19mMTI4Lm8gZ2VuQ2Fz ZXNfd3JpdGVUZXN0c1RvdGFsLm8gdmVyQ2FzZXNfaW5saW5lLm8gdmVyQ2FzZXNfY29tbW9uLm8g dmVyQ2FzZXNfd3JpdGVGdW5jdGlvbk5hbWUubyByZWFkSGV4Lm8gd3JpdGVIZXgubyB3cml0ZUNh c2VfYV91aTMyLm8gd3JpdGVDYXNlX2FfdWk2NC5vIHdyaXRlQ2FzZV9hX2YxNi5vIHdyaXRlQ2Fz ZV9hYl9mMTYubyB3cml0ZUNhc2VfYWJjX2YxNi5vIHdyaXRlQ2FzZV9hX2YzMi5vIHdyaXRlQ2Fz ZV9hYl9mMzIubyB3cml0ZUNhc2VfYWJjX2YzMi5vIHdyaXRlQ2FzZV9hX2Y2NC5vIHdyaXRlQ2Fz ZV9hYl9mNjQubyB3cml0ZUNhc2VfYWJjX2Y2NC5vIHdyaXRlQ2FzZV9hX2V4dEY4ME0ubyB3cml0 ZUNhc2VfYWJfZXh0RjgwTS5vIHdyaXRlQ2FzZV9hX2YxMjhNLm8gd3JpdGVDYXNlX2FiX2YxMjhN Lm8gd3JpdGVDYXNlX2FiY19mMTI4TS5vIHdyaXRlQ2FzZV96X2Jvb2wubyB3cml0ZUNhc2Vfel91 aTMyLm8gd3JpdGVDYXNlX3pfdWk2NC5vIHdyaXRlQ2FzZV96X2YxNi5vIHdyaXRlQ2FzZV96X2Yz Mi5vIHdyaXRlQ2FzZV96X2Y2NC5vIHdyaXRlQ2FzZV96X2V4dEY4ME0ubyB3cml0ZUNhc2Vfel9m MTI4TS5vIHRlc3RMb29wc19jb21tb24ubyB0ZXN0X2FfdWkzMl96X2YxNi5vIHRlc3RfYV91aTMy X3pfZjMyLm8gdGVzdF9hX3VpMzJfel9mNjQubyB0ZXN0X2FfdWkzMl96X2V4dEY4MC5vIHRlc3Rf YV91aTMyX3pfZjEyOC5vIHRlc3RfYV91aTY0X3pfZjE2Lm8gdGVzdF9hX3VpNjRfel9mMzIubyB0 ZXN0X2FfdWk2NF96X2Y2NC5vIHRlc3RfYV91aTY0X3pfZXh0RjgwLm8gdGVzdF9hX3VpNjRfel9m MTI4Lm8gdGVzdF9hX2kzMl96X2YxNi5vIHRlc3RfYV9pMzJfel9mMzIubyB0ZXN0X2FfaTMyX3pf ZjY0Lm8gdGVzdF9hX2kzMl96X2V4dEY4MC5vIHRlc3RfYV9pMzJfel9mMTI4Lm8gdGVzdF9hX2k2 NF96X2YxNi5vIHRlc3RfYV9pNjRfel9mMzIubyB0ZXN0X2FfaTY0X3pfZjY0Lm8gdGVzdF9hX2k2 NF96X2V4dEY4MC5vIHRlc3RfYV9pNjRfel9mMTI4Lm8gdGVzdF9hX2YxNl96X3VpMzJfcngubyB0 ZXN0X2FfZjE2X3pfdWk2NF9yeC5vIHRlc3RfYV9mMTZfel9pMzJfcngubyB0ZXN0X2FfZjE2X3pf aTY0X3J4Lm8gdGVzdF9hX2YxNl96X3VpMzJfeC5vIHRlc3RfYV9mMTZfel91aTY0X3gubyB0ZXN0 X2FfZjE2X3pfaTMyX3gubyB0ZXN0X2FfZjE2X3pfaTY0X3gubyB0ZXN0X2FfZjE2X3pfZjMyLm8g dGVzdF9hX2YxNl96X2Y2NC5vIHRlc3RfYV9mMTZfel9leHRGODAubyB0ZXN0X2FfZjE2X3pfZjEy OC5vIHRlc3RfYXpfZjE2Lm8gdGVzdF9hel9mMTZfcngubyB0ZXN0X2Fiel9mMTYubyB0ZXN0X2Fi Y3pfZjE2Lm8gdGVzdF9hYl9mMTZfel9ib29sLm8gdGVzdF9hX2YzMl96X3VpMzJfcngubyB0ZXN0 X2FfZjMyX3pfdWk2NF9yeC5vIHRlc3RfYV9mMzJfel9pMzJfcngubyB0ZXN0X2FfZjMyX3pfaTY0 X3J4Lm8gdGVzdF9hX2YzMl96X3VpMzJfeC5vIHRlc3RfYV9mMzJfel91aTY0X3gubyB0ZXN0X2Ff ZjMyX3pfaTMyX3gubyB0ZXN0X2FfZjMyX3pfaTY0X3gubyB0ZXN0X2FfZjMyX3pfZjE2Lm8gdGVz dF9hX2YzMl96X2Y2NC5vIHRlc3RfYV9mMzJfel9leHRGODAubyB0ZXN0X2FfZjMyX3pfZjEyOC5v IHRlc3RfYXpfZjMyLm8gdGVzdF9hel9mMzJfcngubyB0ZXN0X2Fiel9mMzIubyB0ZXN0X2FiY3pf ZjMyLm8gdGVzdF9hYl9mMzJfel9ib29sLm8gdGVzdF9hX2Y2NF96X3VpMzJfcngubyB0ZXN0X2Ff ZjY0X3pfdWk2NF9yeC5vIHRlc3RfYV9mNjRfel9pMzJfcngubyB0ZXN0X2FfZjY0X3pfaTY0X3J4 Lm8gdGVzdF9hX2Y2NF96X3VpMzJfeC5vIHRlc3RfYV9mNjRfel91aTY0X3gubyB0ZXN0X2FfZjY0 X3pfaTMyX3gubyB0ZXN0X2FfZjY0X3pfaTY0X3gubyB0ZXN0X2FfZjY0X3pfZjE2Lm8gdGVzdF9h X2Y2NF96X2YzMi5vIHRlc3RfYV9mNjRfel9leHRGODAubyB0ZXN0X2FfZjY0X3pfZjEyOC5vIHRl c3RfYXpfZjY0Lm8gdGVzdF9hel9mNjRfcngubyB0ZXN0X2Fiel9mNjQubyB0ZXN0X2FiY3pfZjY0 Lm8gdGVzdF9hYl9mNjRfel9ib29sLm8gdGVzdF9hX2V4dEY4MF96X3VpMzJfcngubyB0ZXN0X2Ff ZXh0RjgwX3pfdWk2NF9yeC5vIHRlc3RfYV9leHRGODBfel9pMzJfcngubyB0ZXN0X2FfZXh0Rjgw X3pfaTY0X3J4Lm8gdGVzdF9hX2V4dEY4MF96X3VpMzJfeC5vIHRlc3RfYV9leHRGODBfel91aTY0 X3gubyB0ZXN0X2FfZXh0RjgwX3pfaTMyX3gubyB0ZXN0X2FfZXh0RjgwX3pfaTY0X3gubyB0ZXN0 X2FfZXh0RjgwX3pfZjE2Lm8gdGVzdF9hX2V4dEY4MF96X2YzMi5vIHRlc3RfYV9leHRGODBfel9m NjQubyB0ZXN0X2FfZXh0RjgwX3pfZjEyOC5vIHRlc3RfYXpfZXh0RjgwLm8gdGVzdF9hel9leHRG ODBfcngubyB0ZXN0X2Fiel9leHRGODAubyB0ZXN0X2FiX2V4dEY4MF96X2Jvb2wubyB0ZXN0X2Ff ZjEyOF96X3VpMzJfcngubyB0ZXN0X2FfZjEyOF96X3VpNjRfcngubyB0ZXN0X2FfZjEyOF96X2kz Ml9yeC5vIHRlc3RfYV9mMTI4X3pfaTY0X3J4Lm8gdGVzdF9hX2YxMjhfel91aTMyX3gubyB0ZXN0 X2FfZjEyOF96X3VpNjRfeC5vIHRlc3RfYV9mMTI4X3pfaTMyX3gubyB0ZXN0X2FfZjEyOF96X2k2 NF94Lm8gdGVzdF9hX2YxMjhfel9mMTYubyB0ZXN0X2FfZjEyOF96X2YzMi5vIHRlc3RfYV9mMTI4 X3pfZjY0Lm8gdGVzdF9hX2YxMjhfel9leHRGODAubyB0ZXN0X2F6X2YxMjgubyB0ZXN0X2F6X2Yx MjhfcngubyB0ZXN0X2Fiel9mMTI4Lm8gdGVzdF9hYmN6X2YxMjgubyB0ZXN0X2FiX2YxMjhfel9i b29sLm8Kcm0gLWYgbGlic29mdGZsb2F0LmEgJiYgYXIgcmNzIGxpYnNvZnRmbG9hdC5hIHNfZXEx MjgubyBzX2xlMTI4Lm8gc19sdDEyOC5vIHNfc2hvcnRTaGlmdExlZnQxMjgubyBzX3Nob3J0U2hp ZnRSaWdodDEyOC5vIHNfc2hvcnRTaGlmdFJpZ2h0SmFtNjQubyBzX3Nob3J0U2hpZnRSaWdodEph bTY0RXh0cmEubyBzX3Nob3J0U2hpZnRSaWdodEphbTEyOC5vIHNfc2hvcnRTaGlmdFJpZ2h0SmFt MTI4RXh0cmEubyBzX3NoaWZ0UmlnaHRKYW0zMi5vIHNfc2hpZnRSaWdodEphbTY0Lm8gc19zaGlm dFJpZ2h0SmFtNjRFeHRyYS5vIHNfc2hpZnRSaWdodEphbTEyOC5vIHNfc2hpZnRSaWdodEphbTEy OEV4dHJhLm8gc19zaGlmdFJpZ2h0SmFtMjU2TS5vIHNfY291bnRMZWFkaW5nWmVyb3M4Lm8gc19j b3VudExlYWRpbmdaZXJvczE2Lm8gc19jb3VudExlYWRpbmdaZXJvczMyLm8gc19jb3VudExlYWRp bmdaZXJvczY0Lm8gc19hZGQxMjgubyBzX2FkZDI1Nk0ubyBzX3N1YjEyOC5vIHNfc3ViMjU2TS5v IHNfbXVsNjRCeVNoaWZ0ZWQzMlRvMTI4Lm8gc19tdWw2NFRvMTI4Lm8gc19tdWwxMjhCeTMyLm8g c19tdWwxMjhUbzI1Nk0ubyBzX2FwcHJveFJlY2lwXzFLcy5vIHNfYXBwcm94UmVjaXAzMl8xLm8g c19hcHByb3hSZWNpcFNxcnRfMUtzLm8gc19hcHByb3hSZWNpcFNxcnQzMl8xLm8gc19yb3VuZFRv VUkzMi5vIHNfcm91bmRUb1VJNjQubyBzX3JvdW5kVG9JMzIubyBzX3JvdW5kVG9JNjQubyBzX25v cm1TdWJub3JtYWxGMTZTaWcubyBzX3JvdW5kUGFja1RvRjE2Lm8gc19ub3JtUm91bmRQYWNrVG9G MTYubyBzX2FkZE1hZ3NGMTYubyBzX3N1Yk1hZ3NGMTYubyBzX211bEFkZEYxNi5vIHNfbm9ybVN1 Ym5vcm1hbEYzMlNpZy5vIHNfcm91bmRQYWNrVG9GMzIubyBzX25vcm1Sb3VuZFBhY2tUb0YzMi5v IHNfYWRkTWFnc0YzMi5vIHNfc3ViTWFnc0YzMi5vIHNfbXVsQWRkRjMyLm8gc19ub3JtU3Vibm9y bWFsRjY0U2lnLm8gc19yb3VuZFBhY2tUb0Y2NC5vIHNfbm9ybVJvdW5kUGFja1RvRjY0Lm8gc19h ZGRNYWdzRjY0Lm8gc19zdWJNYWdzRjY0Lm8gc19tdWxBZGRGNjQubyBzX25vcm1TdWJub3JtYWxF eHRGODBTaWcubyBzX3JvdW5kUGFja1RvRXh0RjgwLm8gc19ub3JtUm91bmRQYWNrVG9FeHRGODAu byBzX2FkZE1hZ3NFeHRGODAubyBzX3N1Yk1hZ3NFeHRGODAubyBzX25vcm1TdWJub3JtYWxGMTI4 U2lnLm8gc19yb3VuZFBhY2tUb0YxMjgubyBzX25vcm1Sb3VuZFBhY2tUb0YxMjgubyBzX2FkZE1h Z3NGMTI4Lm8gc19zdWJNYWdzRjEyOC5vIHNfbXVsQWRkRjEyOC5vIHNvZnRmbG9hdF9zdGF0ZS5v IHVpMzJfdG9fZjE2Lm8gdWkzMl90b19mMzIubyB1aTMyX3RvX2Y2NC5vIHVpMzJfdG9fZXh0Rjgw Lm8gdWkzMl90b19leHRGODBNLm8gdWkzMl90b19mMTI4Lm8gdWkzMl90b19mMTI4TS5vIHVpNjRf dG9fZjE2Lm8gdWk2NF90b19mMzIubyB1aTY0X3RvX2Y2NC5vIHVpNjRfdG9fZXh0RjgwLm8gdWk2 NF90b19leHRGODBNLm8gdWk2NF90b19mMTI4Lm8gdWk2NF90b19mMTI4TS5vIGkzMl90b19mMTYu byBpMzJfdG9fZjMyLm8gaTMyX3RvX2Y2NC5vIGkzMl90b19leHRGODAubyBpMzJfdG9fZXh0Rjgw TS5vIGkzMl90b19mMTI4Lm8gaTMyX3RvX2YxMjhNLm8gaTY0X3RvX2YxNi5vIGk2NF90b19mMzIu byBpNjRfdG9fZjY0Lm8gaTY0X3RvX2V4dEY4MC5vIGk2NF90b19leHRGODBNLm8gaTY0X3RvX2Yx MjgubyBpNjRfdG9fZjEyOE0ubyBmMTZfdG9fdWkzMi5vIGYxNl90b191aTY0Lm8gZjE2X3RvX2kz Mi5vIGYxNl90b19pNjQubyBmMTZfdG9fdWkzMl9yX21pbk1hZy5vIGYxNl90b191aTY0X3JfbWlu TWFnLm8gZjE2X3RvX2kzMl9yX21pbk1hZy5vIGYxNl90b19pNjRfcl9taW5NYWcubyBmMTZfdG9f ZjMyLm8gZjE2X3RvX2Y2NC5vIGYxNl90b19leHRGODAubyBmMTZfdG9fZXh0RjgwTS5vIGYxNl90 b19mMTI4Lm8gZjE2X3RvX2YxMjhNLm8gZjE2X3JvdW5kVG9JbnQubyBmMTZfYWRkLm8gZjE2X3N1 Yi5vIGYxNl9tdWwubyBmMTZfbXVsQWRkLm8gZjE2X2Rpdi5vIGYxNl9yZW0ubyBmMTZfc3FydC5v IGYxNl9lcS5vIGYxNl9sZS5vIGYxNl9sdC5vIGYxNl9lcV9zaWduYWxpbmcubyBmMTZfbGVfcXVp ZXQubyBmMTZfbHRfcXVpZXQubyBmMTZfaXNTaWduYWxpbmdOYU4ubyBmMzJfdG9fdWkzMi5vIGYz Ml90b191aTY0Lm8gZjMyX3RvX2kzMi5vIGYzMl90b19pNjQubyBmMzJfdG9fdWkzMl9yX21pbk1h Zy5vIGYzMl90b191aTY0X3JfbWluTWFnLm8gZjMyX3RvX2kzMl9yX21pbk1hZy5vIGYzMl90b19p NjRfcl9taW5NYWcubyBmMzJfdG9fZjE2Lm8gZjMyX3RvX2Y2NC5vIGYzMl90b19leHRGODAubyBm MzJfdG9fZXh0RjgwTS5vIGYzMl90b19mMTI4Lm8gZjMyX3RvX2YxMjhNLm8gZjMyX3JvdW5kVG9J bnQubyBmMzJfYWRkLm8gZjMyX3N1Yi5vIGYzMl9tdWwubyBmMzJfbXVsQWRkLm8gZjMyX2Rpdi5v IGYzMl9yZW0ubyBmMzJfc3FydC5vIGYzMl9lcS5vIGYzMl9sZS5vIGYzMl9sdC5vIGYzMl9lcV9z aWduYWxpbmcubyBmMzJfbGVfcXVpZXQubyBmMzJfbHRfcXVpZXQubyBmMzJfaXNTaWduYWxpbmdO YU4ubyBmNjRfdG9fdWkzMi5vIGY2NF90b191aTY0Lm8gZjY0X3RvX2kzMi5vIGY2NF90b19pNjQu byBmNjRfdG9fdWkzMl9yX21pbk1hZy5vIGY2NF90b191aTY0X3JfbWluTWFnLm8gZjY0X3RvX2kz Ml9yX21pbk1hZy5vIGY2NF90b19pNjRfcl9taW5NYWcubyBmNjRfdG9fZjE2Lm8gZjY0X3RvX2Yz Mi5vIGY2NF90b19leHRGODAubyBmNjRfdG9fZXh0RjgwTS5vIGY2NF90b19mMTI4Lm8gZjY0X3Rv X2YxMjhNLm8gZjY0X3JvdW5kVG9JbnQubyBmNjRfYWRkLm8gZjY0X3N1Yi5vIGY2NF9tdWwubyBm NjRfbXVsQWRkLm8gZjY0X2Rpdi5vIGY2NF9yZW0ubyBmNjRfc3FydC5vIGY2NF9lcS5vIGY2NF9s ZS5vIGY2NF9sdC5vIGY2NF9lcV9zaWduYWxpbmcubyBmNjRfbGVfcXVpZXQubyBmNjRfbHRfcXVp ZXQubyBmNjRfaXNTaWduYWxpbmdOYU4ubyBleHRGODBfdG9fdWkzMi5vIGV4dEY4MF90b191aTY0 Lm8gZXh0RjgwX3RvX2kzMi5vIGV4dEY4MF90b19pNjQubyBleHRGODBfdG9fdWkzMl9yX21pbk1h Zy5vIGV4dEY4MF90b191aTY0X3JfbWluTWFnLm8gZXh0RjgwX3RvX2kzMl9yX21pbk1hZy5vIGV4 dEY4MF90b19pNjRfcl9taW5NYWcubyBleHRGODBfdG9fZjE2Lm8gZXh0RjgwX3RvX2YzMi5vIGV4 dEY4MF90b19mNjQubyBleHRGODBfdG9fZjEyOC5vIGV4dEY4MF9yb3VuZFRvSW50Lm8gZXh0Rjgw X2FkZC5vIGV4dEY4MF9zdWIubyBleHRGODBfbXVsLm8gZXh0RjgwX2Rpdi5vIGV4dEY4MF9yZW0u byBleHRGODBfc3FydC5vIGV4dEY4MF9lcS5vIGV4dEY4MF9sZS5vIGV4dEY4MF9sdC5vIGV4dEY4 MF9lcV9zaWduYWxpbmcubyBleHRGODBfbGVfcXVpZXQubyBleHRGODBfbHRfcXVpZXQubyBleHRG ODBfaXNTaWduYWxpbmdOYU4ubyBleHRGODBNX3RvX3VpMzIubyBleHRGODBNX3RvX3VpNjQubyBl eHRGODBNX3RvX2kzMi5vIGV4dEY4ME1fdG9faTY0Lm8gZXh0RjgwTV90b191aTMyX3JfbWluTWFn Lm8gZXh0RjgwTV90b191aTY0X3JfbWluTWFnLm8gZXh0RjgwTV90b19pMzJfcl9taW5NYWcubyBl eHRGODBNX3RvX2k2NF9yX21pbk1hZy5vIGV4dEY4ME1fdG9fZjE2Lm8gZXh0RjgwTV90b19mMzIu byBleHRGODBNX3RvX2Y2NC5vIGV4dEY4ME1fdG9fZjEyOE0ubyBleHRGODBNX3JvdW5kVG9JbnQu byBleHRGODBNX2FkZC5vIGV4dEY4ME1fc3ViLm8gZXh0RjgwTV9tdWwubyBleHRGODBNX2Rpdi5v IGV4dEY4ME1fcmVtLm8gZXh0RjgwTV9zcXJ0Lm8gZXh0RjgwTV9lcS5vIGV4dEY4ME1fbGUubyBl eHRGODBNX2x0Lm8gZXh0RjgwTV9lcV9zaWduYWxpbmcubyBleHRGODBNX2xlX3F1aWV0Lm8gZXh0 RjgwTV9sdF9xdWlldC5vIGYxMjhfdG9fdWkzMi5vIGYxMjhfdG9fdWk2NC5vIGYxMjhfdG9faTMy Lm8gZjEyOF90b19pNjQubyBmMTI4X3RvX3VpMzJfcl9taW5NYWcubyBmMTI4X3RvX3VpNjRfcl9t aW5NYWcubyBmMTI4X3RvX2kzMl9yX21pbk1hZy5vIGYxMjhfdG9faTY0X3JfbWluTWFnLm8gZjEy OF90b19mMTYubyBmMTI4X3RvX2YzMi5vIGYxMjhfdG9fZXh0RjgwLm8gZjEyOF90b19mNjQubyBm MTI4X3JvdW5kVG9JbnQubyBmMTI4X2FkZC5vIGYxMjhfc3ViLm8gZjEyOF9tdWwubyBmMTI4X211 bEFkZC5vIGYxMjhfZGl2Lm8gZjEyOF9yZW0ubyBmMTI4X3NxcnQubyBmMTI4X2VxLm8gZjEyOF9s ZS5vIGYxMjhfbHQubyBmMTI4X2VxX3NpZ25hbGluZy5vIGYxMjhfbGVfcXVpZXQubyBmMTI4X2x0 X3F1aWV0Lm8gZjEyOF9pc1NpZ25hbGluZ05hTi5vIGYxMjhNX3RvX3VpMzIubyBmMTI4TV90b191 aTY0Lm8gZjEyOE1fdG9faTMyLm8gZjEyOE1fdG9faTY0Lm8gZjEyOE1fdG9fdWkzMl9yX21pbk1h Zy5vIGYxMjhNX3RvX3VpNjRfcl9taW5NYWcubyBmMTI4TV90b19pMzJfcl9taW5NYWcubyBmMTI4 TV90b19pNjRfcl9taW5NYWcubyBmMTI4TV90b19mMTYubyBmMTI4TV90b19mMzIubyBmMTI4TV90 b19leHRGODBNLm8gZjEyOE1fdG9fZjY0Lm8gZjEyOE1fcm91bmRUb0ludC5vIGYxMjhNX2FkZC5v IGYxMjhNX3N1Yi5vIGYxMjhNX211bC5vIGYxMjhNX211bEFkZC5vIGYxMjhNX2Rpdi5vIGYxMjhN X3JlbS5vIGYxMjhNX3NxcnQubyBmMTI4TV9lcS5vIGYxMjhNX2xlLm8gZjEyOE1fbHQubyBmMTI4 TV9lcV9zaWduYWxpbmcubyBmMTI4TV9sZV9xdWlldC5vIGYxMjhNX2x0X3F1aWV0Lm8gc29mdGZs b2F0X3JhaXNlRmxhZ3MubyBzX2YxNlVJVG9Db21tb25OYU4ubyBzX2NvbW1vbk5hTlRvRjE2VUku byBzX3Byb3BhZ2F0ZU5hTkYxNlVJLm8gc19mMzJVSVRvQ29tbW9uTmFOLm8gc19jb21tb25OYU5U b0YzMlVJLm8gc19wcm9wYWdhdGVOYU5GMzJVSS5vIHNfZjY0VUlUb0NvbW1vbk5hTi5vIHNfY29t bW9uTmFOVG9GNjRVSS5vIHNfcHJvcGFnYXRlTmFORjY0VUkubyBleHRGODBNX2lzU2lnbmFsaW5n TmFOLm8gc19leHRGODBVSVRvQ29tbW9uTmFOLm8gc19jb21tb25OYU5Ub0V4dEY4MFVJLm8gc19w cm9wYWdhdGVOYU5FeHRGODBVSS5vIGYxMjhNX2lzU2lnbmFsaW5nTmFOLm8gc19mMTI4VUlUb0Nv bW1vbk5hTi5vIHNfY29tbW9uTmFOVG9GMTI4VUkubyBzX3Byb3BhZ2F0ZU5hTkYxMjhVSS5vCmNs YW5nKysgLWcgIC1XbCwtLXdhcm4tY29tbW9uIC1mc2FuaXRpemU9dW5kZWZpbmVkIC1mc2FuaXRp emU9YWRkcmVzcyAtV2wsLXoscmVscm8gLVdsLC16LG5vdyAtcGllIC1tNjQgIC1mc3RhY2stcHJv dGVjdG9yLXN0cm9uZyAtbyBmcC10ZXN0IGZwLXRlc3QubyBzbG93ZmxvYXQubyBzb2Z0ZmxvYXQu byAgbGlidGVzdGZsb2F0LmEgbGlic29mdGZsb2F0LmEgL3RtcC9xZW11LXRlc3QvYnVpbGQvbGli cWVtdXV0aWwuYSAgIC1sbSAtbHogIC1sZ3RocmVhZC0yLjAgLXB0aHJlYWQgLWxnbGliLTIuMCAg LWxuZXR0bGUgIC1sZ251dGxzICAtbHpzdGQgICAtbHJ0Ci91c3IvYmluL2xkOiAvdXNyL2xpYjY0 L2NsYW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2lu dGVyY2VwdG9yc192Zm9yay5TLm8pOiB3YXJuaW5nOiBjb21tb24gb2YgYF9faW50ZXJjZXB0aW9u OjpyZWFsX3Zmb3JrJyBvdmVycmlkZGVuIGJ5IGRlZmluaXRpb24gZnJvbSAvdXNyL2xpYjY0L2Ns YW5nLzEwLjAuMC9saWIvbGludXgvbGliY2xhbmdfcnQuYXNhbi14ODZfNjQuYShhc2FuX2ludGVy Y2VwdG9ycy5jcHAubykKbWFrZVsxXTogTGVhdmluZyBkaXJlY3RvcnkgJy90bXAvcWVtdS10ZXN0 L2J1aWxkL3Rlc3RzL2ZwJwpUcmFjZWJhY2sgKG1vc3QgcmVjZW50IGNhbGwgbGFzdCk6CiAgRmls ZSAiLi90ZXN0cy9kb2NrZXIvZG9ja2VyLnB5IiwgbGluZSA2NjksIGluIDxtb2R1bGU+Ci0tLQog ICAgcmFpc2UgQ2FsbGVkUHJvY2Vzc0Vycm9yKHJldGNvZGUsIGNtZCkKc3VicHJvY2Vzcy5DYWxs ZWRQcm9jZXNzRXJyb3I6IENvbW1hbmQgJ1snc3VkbycsICctbicsICdkb2NrZXInLCAncnVuJywg Jy0tbGFiZWwnLCAnY29tLnFlbXUuaW5zdGFuY2UudXVpZD1iNmY4MzU3YjY0MmI0OTlmOWZmODU3 NjFjMzYyNDQ3ZCcsICctdScsICcxMDAzJywgJy0tc2VjdXJpdHktb3B0JywgJ3NlY2NvbXA9dW5j b25maW5lZCcsICctLXJtJywgJy1lJywgJ1RBUkdFVF9MSVNUPXg4Nl82NC1zb2Z0bW11JywgJy1l JywgJ0VYVFJBX0NPTkZJR1VSRV9PUFRTPScsICctZScsICdWPScsICctZScsICdKPTE0JywgJy1l JywgJ0RFQlVHPScsICctZScsICdTSE9XX0VOVj0nLCAnLWUnLCAnQ0NBQ0hFX0RJUj0vdmFyL3Rt cC9jY2FjaGUnLCAnLXYnLCAnL2hvbWUvcGF0Y2hldzIvLmNhY2hlL3FlbXUtZG9ja2VyLWNjYWNo ZTovdmFyL3RtcC9jY2FjaGU6eicsICctdicsICcvdmFyL3RtcC9wYXRjaGV3LXRlc3Rlci10bXAt YWZuYWtsdDQvc3JjL2RvY2tlci1zcmMuMjAyMC0wNi0xOS0wNy4zMC4xMS4xOTU5ODovdmFyL3Rt cC9xZW11Onoscm8nLCAncWVtdTpmZWRvcmEnLCAnL3Zhci90bXAvcWVtdS9ydW4nLCAndGVzdC1k ZWJ1ZyddJyByZXR1cm5lZCBub24temVybyBleGl0IHN0YXR1cyAyLgpmaWx0ZXI9LS1maWx0ZXI9 bGFiZWw9Y29tLnFlbXUuaW5zdGFuY2UudXVpZD1iNmY4MzU3YjY0MmI0OTlmOWZmODU3NjFjMzYy NDQ3ZAptYWtlWzFdOiAqKiogW2RvY2tlci1ydW5dIEVycm9yIDEKbWFrZVsxXTogTGVhdmluZyBk aXJlY3RvcnkgYC92YXIvdG1wL3BhdGNoZXctdGVzdGVyLXRtcC1hZm5ha2x0NC9zcmMnCm1ha2U6 ICoqKiBbZG9ja2VyLXJ1bi10ZXN0LWRlYnVnQGZlZG9yYV0gRXJyb3IgMgoKcmVhbCAgICA1bTE1 LjI4MnMKdXNlciAgICAwbTcuODY2cwoKClRoZSBmdWxsIGxvZyBpcyBhdmFpbGFibGUgYXQKaHR0 cDovL3BhdGNoZXcub3JnL2xvZ3MvMjAyMDA2MTkxMDMxMTUuMjU0MTI3LTEtYW50aG9ueS5wZXJh cmRAY2l0cml4LmNvbS90ZXN0aW5nLmFzYW4vP3R5cGU9bWVzc2FnZS4KLS0tCkVtYWlsIGdlbmVy YXRlZCBhdXRvbWF0aWNhbGx5IGJ5IFBhdGNoZXcgW2h0dHBzOi8vcGF0Y2hldy5vcmcvXS4KUGxl YXNlIHNlbmQgeW91ciBmZWVkYmFjayB0byBwYXRjaGV3LWRldmVsQHJlZGhhdC5jb20= From xen-devel-bounces@lists.xenproject.org Fri Jun 19 11:36:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 11:36:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFK8-0006jz-LP; Fri, 19 Jun 2020 11:36:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFK7-0006jt-WC for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 11:36:44 +0000 X-Inumbo-ID: 25bda04e-b221-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 25bda04e-b221-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 11:36:43 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id E5D57A3446; Fri, 19 Jun 2020 13:36:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A1C8CA30FF; Fri, 19 Jun 2020 13:36:40 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5-zl2hLezTDP; Fri, 19 Jun 2020 13:36:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2F868A345C; Fri, 19 Jun 2020 13:36:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4Xbq02PKyOuN; Fri, 19 Jun 2020 13:36:40 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id EBF59A30FF; Fri, 19 Jun 2020 13:36:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id DF16720ABA; Fri, 19 Jun 2020 13:36:39 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id N_87Cm35tyct; Fri, 19 Jun 2020 13:36:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 7CB4B221F4; Fri, 19 Jun 2020 13:36:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1SGWV3SH0RCb; Fri, 19 Jun 2020 13:36:34 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 5D04D21866; Fri, 19 Jun 2020 13:36:34 +0200 (CEST) Date: Fri, 19 Jun 2020 13:36:34 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <1542506040.10138544.1592566594292.JavaMail.zimbra@cert.pl> In-Reply-To: <20200619113434.GZ735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1060400786.9820894.1592523480084.JavaMail.zimbra@cert.pl> <20200619113434.GZ735@Air-de-Roger> Subject: Re: [PATCH v2 1/7] xen/mm: lift 32 item limit from mfn/gfn arrays MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: xen/mm: lift 32 item limit from mfn/gfn arrays Thread-Index: o52pDmEo/M3rZXM9GSd5Yw4nuw1ngg== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 13:34, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Fri, Jun 19, 2020 at 01:38:00AM +0200, Micha=C5=82 Leszczy=C5=84ski wr= ote: >> Replace on-stack array allocation with heap allocation >> in order to lift the limit of 32 items in mfn/gfn arrays >> when calling acquire_resource. >=20 > I'm afraid this is not correct, you cannot allow unbounded amounts of > items to be processed like this, it's likely that you manage to > trigger the watchdog if the list is long enough, specially when doing > set_foreign_p2m_entry. >=20 > You need to process the items in batches (32 was IMO a good start), and > then add support for hypercall continuations. Take a look at how > XENMEM_populate_physmap just a couple of lines below makes use of > hypercall_create_continuation. >=20 > After processing every batch you need to check if > hypercall_preempt_check returns true and if so use > hypercall_create_continuation in order to encode a continuation. >=20 > Thanks, Roger. Somebody previously suggested that this limit could be lifted this way, so I would like to hear some more opinions on that. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Fri Jun 19 11:48:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 11:48:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFVa-0007hf-PC; Fri, 19 Jun 2020 11:48:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFVZ-0007ha-FB for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 11:48:33 +0000 X-Inumbo-ID: cca81a6e-b222-11ea-bb69-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cca81a6e-b222-11ea-bb69-12813bfff9fa; Fri, 19 Jun 2020 11:48:32 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8DE85AD18; Fri, 19 Jun 2020 11:48:30 +0000 (UTC) Subject: Re: [PATCH v2 1/7] xen/mm: lift 32 item limit from mfn/gfn arrays To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1060400786.9820894.1592523480084.JavaMail.zimbra@cert.pl> <20200619113434.GZ735@Air-de-Roger> <1542506040.10138544.1592566594292.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <8f38c905-c5ed-06d7-db4e-e8024e897b43@suse.com> Date: Fri, 19 Jun 2020 13:48:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1542506040.10138544.1592566594292.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Tamas K Lengyel , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 13:36, Michał Leszczyński wrote: > ----- 19 cze 2020 o 13:34, Roger Pau Monné roger.pau@citrix.com napisał(a): > >> On Fri, Jun 19, 2020 at 01:38:00AM +0200, Michał Leszczyński wrote: >>> Replace on-stack array allocation with heap allocation >>> in order to lift the limit of 32 items in mfn/gfn arrays >>> when calling acquire_resource. >> >> I'm afraid this is not correct, you cannot allow unbounded amounts of >> items to be processed like this, it's likely that you manage to >> trigger the watchdog if the list is long enough, specially when doing >> set_foreign_p2m_entry. >> >> You need to process the items in batches (32 was IMO a good start), and >> then add support for hypercall continuations. Take a look at how >> XENMEM_populate_physmap just a couple of lines below makes use of >> hypercall_create_continuation. >> >> After processing every batch you need to check if >> hypercall_preempt_check returns true and if so use >> hypercall_create_continuation in order to encode a continuation. >> >> Thanks, Roger. > > > Somebody previously suggested that this limit could be lifted this way, > so I would like to hear some more opinions on that. I did suggest the limit can be lifted, but not by processing all pieces in one go. Whether batches of 32 or 64 or 128 are chosen is a different thing, but you can't do arbitrary amounts without any preemption checks. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 19 11:52:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 11:52:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFZ6-0008TD-8v; Fri, 19 Jun 2020 11:52:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFZ5-0008T8-1b for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 11:52:11 +0000 X-Inumbo-ID: 4e45b108-b223-11ea-bca7-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4e45b108-b223-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 11:52:10 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1A8FEA3457; Fri, 19 Jun 2020 13:52:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 09658A328F; Fri, 19 Jun 2020 13:52:08 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id VtwnB6FmtmDD; Fri, 19 Jun 2020 13:52:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 82627A3457; Fri, 19 Jun 2020 13:52:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b9OA9_9QeFuU; Fri, 19 Jun 2020 13:52:07 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 56CE6A328F; Fri, 19 Jun 2020 13:52:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 3F3C621747; Fri, 19 Jun 2020 13:51:37 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id tmSQ1ygic8_q; Fri, 19 Jun 2020 13:51:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id B6C0A2256C; Fri, 19 Jun 2020 13:51:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8G8oGYxRY3RS; Fri, 19 Jun 2020 13:51:31 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 8CFF52255E; Fri, 19 Jun 2020 13:51:31 +0200 (CEST) Date: Fri, 19 Jun 2020 13:51:31 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <1261259347.10148244.1592567491475.JavaMail.zimbra@cert.pl> In-Reply-To: <8f38c905-c5ed-06d7-db4e-e8024e897b43@suse.com> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1060400786.9820894.1592523480084.JavaMail.zimbra@cert.pl> <20200619113434.GZ735@Air-de-Roger> <1542506040.10138544.1592566594292.JavaMail.zimbra@cert.pl> <8f38c905-c5ed-06d7-db4e-e8024e897b43@suse.com> Subject: Re: [PATCH v2 1/7] xen/mm: lift 32 item limit from mfn/gfn arrays MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: xen/mm: lift 32 item limit from mfn/gfn arrays Thread-Index: LZiSNEInEtZmx5F3W49fgkm7P7pLww== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Tamas K Lengyel , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 13:48, Jan Beulich jbeulich@suse.com napisa=C5=82(a): > On 19.06.2020 13:36, Micha=C5=82 Leszczy=C5=84ski wrote: >> ----- 19 cze 2020 o 13:34, Roger Pau Monn=C3=A9 roger.pau@citrix.com nap= isa=C5=82(a): >>=20 >>> On Fri, Jun 19, 2020 at 01:38:00AM +0200, Micha=C5=82 Leszczy=C5=84ski = wrote: >>>> Replace on-stack array allocation with heap allocation >>>> in order to lift the limit of 32 items in mfn/gfn arrays >>>> when calling acquire_resource. >>> >>> I'm afraid this is not correct, you cannot allow unbounded amounts of >>> items to be processed like this, it's likely that you manage to >>> trigger the watchdog if the list is long enough, specially when doing >>> set_foreign_p2m_entry. >>> >>> You need to process the items in batches (32 was IMO a good start), and >>> then add support for hypercall continuations. Take a look at how >>> XENMEM_populate_physmap just a couple of lines below makes use of >>> hypercall_create_continuation. >>> >>> After processing every batch you need to check if >>> hypercall_preempt_check returns true and if so use >>> hypercall_create_continuation in order to encode a continuation. >>> >>> Thanks, Roger. >>=20 >>=20 >> Somebody previously suggested that this limit could be lifted this way, >> so I would like to hear some more opinions on that. >=20 > I did suggest the limit can be lifted, but not by processing all > pieces in one go. Whether batches of 32 or 64 or 128 are chosen > is a different thing, but you can't do arbitrary amounts without > any preemption checks. >=20 > Jan Okay. I will try to correct it within v3. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Fri Jun 19 11:58:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 11:58:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFfR-0000FN-04; Fri, 19 Jun 2020 11:58:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFfP-0000FH-Uj for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 11:58:43 +0000 X-Inumbo-ID: 3832a7ee-b224-11ea-bb6a-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3832a7ee-b224-11ea-bb6a-12813bfff9fa; Fri, 19 Jun 2020 11:58:42 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: +7J+OWjJIU6EWdeeKMTmt2zgYYGTKWDh1shP6ZC4kaGrNIXQmNgXkAjujPijnbwymFREVfVaDY 7CJftRgY1wZLte4b5J+iS5NrDqAab6FM37RFRqjCtbJ/ehVfCpFP8GQMZPWjQ8LX9rd/iEU9Gs Pd5kQGRaApOgoBJYud9p4wiWQVFiVzViCu4MBSD9G+tqwJ9OmgSt/Nf+WSxKwQyHbyY3rvK0uC gdfZQui4uSwfnlXXqlouywsZXGmoA5YpMxwWzN5Vg73NTeB9a/0C5ygm4Ydv/wVzyJN0n6hs/B GpY= X-SBRS: 2.7 X-MesageID: 20687932 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20687932" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs Date: Fri, 19 Jun 2020 12:58:23 +0100 Message-ID: <20200619115823.22243-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" We do not expose the feature to guests, so should disallow access to the respective MSRs. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant CC: Michał Leszczyński Paul: For 4.14. This needs backporting to older trees as well. Michał: CC'ing, just to keep you in the loop. Xen has some dubious default MSR semantics which we're still in the middle of untangling in a backwards compatible way. Patches like this will eventually not be necessary, but they are for now. --- xen/arch/x86/msr.c | 12 ++++++++++++ xen/include/asm-x86/msr-index.h | 8 ++++++++ 2 files changed, 20 insertions(+) diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index 0bfb5839b2..05afe601a8 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) case MSR_TSX_FORCE_ABORT: case MSR_TSX_CTRL: case MSR_MCU_OPT_CTRL: + case MSR_RTIT_OUTPUT_BASE: + case MSR_RTIT_OUTPUT_MASK: + case MSR_RTIT_CTL: + case MSR_RTIT_STATUS: + case MSR_RTIT_CR3_MATCH: + case MSR_RTIT_ADDR_A(0) ... MSR_RTIT_ADDR_B(3): case MSR_U_CET: case MSR_S_CET: case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE: @@ -329,6 +335,12 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val) case MSR_TSX_FORCE_ABORT: case MSR_TSX_CTRL: case MSR_MCU_OPT_CTRL: + case MSR_RTIT_OUTPUT_BASE: + case MSR_RTIT_OUTPUT_MASK: + case MSR_RTIT_CTL: + case MSR_RTIT_STATUS: + case MSR_RTIT_CR3_MATCH: + case MSR_RTIT_ADDR_A(0) ... MSR_RTIT_ADDR_B(3): case MSR_U_CET: case MSR_S_CET: case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE: diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h index b328a47ed8..0fe98af923 100644 --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -69,6 +69,14 @@ #define MSR_MCU_OPT_CTRL 0x00000123 #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) +#define MSR_RTIT_OUTPUT_BASE 0x00000560 +#define MSR_RTIT_OUTPUT_MASK 0x00000561 +#define MSR_RTIT_CTL 0x00000570 +#define MSR_RTIT_STATUS 0x00000571 +#define MSR_RTIT_CR3_MATCH 0x00000572 +#define MSR_RTIT_ADDR_A(n) (0x00000580 + (n) * 2) +#define MSR_RTIT_ADDR_B(n) (0x00000581 + (n) * 2) + #define MSR_U_CET 0x000006a0 #define MSR_S_CET 0x000006a2 #define CET_SHSTK_EN (_AC(1, ULL) << 0) -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:11:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:11:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFrD-0001v5-GS; Fri, 19 Jun 2020 12:10:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmFrC-0001v0-6J for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:10:54 +0000 X-Inumbo-ID: ebc512f0-b225-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ebc512f0-b225-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 12:10:53 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 693B1A3386; Fri, 19 Jun 2020 14:10:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 5E29FA3370; Fri, 19 Jun 2020 14:10:51 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 8AaQQhPXtcCk; Fri, 19 Jun 2020 14:10:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9ED5AA3386; Fri, 19 Jun 2020 14:10:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mseaQXxCB_C5; Fri, 19 Jun 2020 14:10:50 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7BECCA3370; Fri, 19 Jun 2020 14:10:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 65C60224D5; Fri, 19 Jun 2020 14:10:20 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id FDYSmT8m_dfK; Fri, 19 Jun 2020 14:10:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id DD5F322521; Fri, 19 Jun 2020 14:10:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ovMWrDscSs9Z; Fri, 19 Jun 2020 14:10:14 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id BAD0F2189E; Fri, 19 Jun 2020 14:10:14 +0200 (CEST) Date: Fri, 19 Jun 2020 14:10:14 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Andrew Cooper Message-ID: <1417373854.10164826.1592568614663.JavaMail.zimbra@cert.pl> In-Reply-To: <20200619115823.22243-1-andrew.cooper3@citrix.com> References: <20200619115823.22243-1-andrew.cooper3@citrix.com> Subject: Re: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/msr: Disallow access to Processor Trace MSRs Thread-Index: yk1CdCvPz6X6kk6c5uJDk+Ktx5/rpw== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , Jan Beulich , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 13:58, Andrew Cooper andrew.cooper3@citrix.com napisa= =C5=82(a): > We do not expose the feature to guests, so should disallow access to the > respective MSRs. >=20 > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monn=C3=A9 > CC: Paul Durrant > CC: Micha=C5=82 Leszczy=C5=84ski >=20 > Paul: For 4.14. This needs backporting to older trees as well. >=20 > Micha=C5=82: CC'ing, just to keep you in the loop. Xen has some dubious = default > MSR semantics which we're still in the middle of untangling in a backward= s > compatible way. Patches like this will eventually not be necessary, but = they > are for now. As for external IPT monitoring, it would be best if the VM would think that IPT is simply not supported at all by the underlying hypervisor. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:32:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:32:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGBv-0003eK-ED; Fri, 19 Jun 2020 12:32:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGBu-0003eF-1v for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:32:18 +0000 X-Inumbo-ID: e8bb42de-b228-11ea-8496-bc764e2007e4 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:7d00::612]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e8bb42de-b228-11ea-8496-bc764e2007e4; Fri, 19 Jun 2020 12:32:16 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dm/Elfgr1WPtuQx3Xw0Nz6kFZ5YrhjxHafP0Q9bxjrQ2BmXoFzYyxmoj/c6YDab+MQq1LTSk2FZtYUH6wJFd5SfYJUN86+KCwzP2vx6MWAkL9/7WVsWVRwVT18wh26EX09BmmezW1IEtUr2zbeTr4RpMigbJlPMk2dD19nmfB1aLWbIfnCcrkhBusiaOUcCyKk2zV+S5+CJk+kZ69cho4rmKDSq5Gi6Dg9XA15bsfX9wfuTtA8u65sOM6TU8wHL74K95jxygqwZuyvThqXjKdjjVZHJjmLURwlbGSPqwim/tXr/X1zJhhNxsw6liWp/uj0HnBU5MSAEtWymQ4QGa5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GbP2RTlkNxVnRFwh3YeM/LZxhrjsq9/+z4Ag+Q5G2b8=; b=ejmT/dFVN8htPY7AuICO5neHEEKnXquXj3jcWGd/c/o7kZ4ejcsztl5HV6pYRhRNVOmhVUKQ8xScjvLja/6cOG1287jcIAjNfbvm8pd1w+u4ooowX9dix64F60/FACccQhItJXDuwSjzMWqBODT7FtPUi3vf/JCB+umwiOWpRQXVGaiydseTcVtNug8U/jTTDxO8gznTDsU+mifFrSU+b5td/7DOzPwXySYmF2oDYt4A9CIvltR3eok7HhXJiL5VzIMVqhBTWAOzDx1khxCxJlZT3Et6lCe0sK/SRWQTzaBoBoKIMalhKXwMVZV42b/Xp6ZAgkJhhJEKeoB3Wx1HZw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GbP2RTlkNxVnRFwh3YeM/LZxhrjsq9/+z4Ag+Q5G2b8=; b=wAkVAUBKZ5eZ1fCIvVXvBOCan/YUdf8MtA1aQyQhlI+E02w/lNtzOobbBWHiMbPaaZx/b62PU9K1i/NL+rdRIQHOutwCKfCOqzo1x3qoEjljMgDF0oVSUoDGY1PJxx+mrWVUmjPEigqOKdG1og0bLQAtBxmtTv2FpY3ULRnVBD1GOu354H5Y2h0e19TRDZDJ4TcuFBQrn1kowDvC7RHxDHseZazw6obgObdSwv/YwOK7ZdVbZZuP0qOaFUqikbvK01io41PD+RzoZoUbkASMaaeSWLmkCtupNV7lPEV48kNionGLqxjAp4S5boMrLQYwBgAMDRnugV9Be50ObGQwRA== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB3135.eurprd03.prod.outlook.com (2603:10a6:802:35::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 19 Jun 2020 12:32:15 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 12:32:15 +0000 From: Oleksandr Andrushchenko To: Julien Grall , Stefano Stabellini Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAOXggA== Date: Fri, 19 Jun 2020 12:32:14 +0000 Message-ID: <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: da65ac34-a1e0-4c04-59c4-08d8144ccc65 x-ms-traffictypediagnostic: VI1PR03MB3135: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vZFCzBY/9O2h30V886a2+0Os61qYkeKf+AW69X/FwNAaJx7NYWjEfVcumKAzskIvUtfXvrXvZhKcv939gjP62S75NM5QlDGDk/PwNU7cjj8iNH79EoRQNjLvcYzR6/PXBSOmE0+4nT5OOGPCgarz8pjI0Vf2vw2pWEm3EhJ8M20bbS5DmZJEWS9g1wdQBXNiduwp5jLRv1BqEWmmVo2+IQc/gXpdIWBEqOC4JQG23s7XKOLbCayP4fGK+DizkLXGM9zQkzh7YqJ28CaycQLvISE6VXcF/mACnB05jDWgGyM9B4W8/5SRiU5QDOfCBwQs8wfuKSGiCvYVzW2TO9MwgQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(136003)(366004)(39860400002)(376002)(110136005)(26005)(478600001)(54906003)(83380400001)(6512007)(316002)(6486002)(8936002)(186003)(91956017)(64756008)(4326008)(8676002)(53546011)(2906002)(6506007)(66946007)(66556008)(66446008)(66476007)(76116006)(5660300002)(31696002)(31686004)(2616005)(71200400001)(36756003)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rT9vPbUuALlZ4c7JDMzaJnTukiAQt65nAxsyXuRbDM1PmLN0uV6YCYlZBSt8nbHXjAHohNZp6ITFMn1p81XIBWtTjzAcs4ylt664jwKMjA2Y6QqhSEiXq033tO8omqPm+eljQnIVRIAwF4dxETMIPTUDo95rne16gVHt2RHoTU2oL/R32VoP+iSiQxI/oBkq0eqKZE6RAP+8z2V9N2W0YJqGhnlyHhzTtZSNa3evXmz+UWmU8wtdVZnMny9KqA6ScIBATo/WarVXEulpjY2dJNsfEApa/wbQu+Ia1Lmm0RPfYDYOaYubS+uknX2yWDhS1e7cMFk/8TuZZg0gJqdH1tXI35H8W5H3+SELNeXPssbXWAuzTkxiRMrMceJzGN6mXHUcYsTShVv1kKf1ILgCdxFTVd8MWTeaCb09S/h851MsD2Z+6RPNvPixHu2HlQIbW3cEKwvSIeI18HRLxdQe5xqcSbLpyNfdr+h6vFqxDBY= Content-Type: text/plain; charset="utf-8" Content-ID: <80C5D2518023DB488495E4EEDA14C993@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: da65ac34-a1e0-4c04-59c4-08d8144ccc65 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 12:32:15.0060 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gEu6xnYqSMCDrLUqAXJSzeRd9+PHIVmbWv5tXRAvSrFQ8cjQ5qq3uMu8JhZgxrauX/yTrY8w1aGZj5Btadlt1L6nU1OH8wSzlvtel2u1p1m7Y6xsuaT12gkzXXcuhQ5N X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB3135 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzE5LzIwIDE6NDkgQU0sIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gT24gVGh1LCAxOCBK dW4gMjAyMCBhdCAyMzowMCwgU3RlZmFubyBTdGFiZWxsaW5pIDxzc3RhYmVsbGluaUBrZXJuZWwu b3JnPiB3cm90ZToNCj4+IE9uIFRodSwgMTggSnVuIDIwMjAsIEp1bGllbiBHcmFsbCB3cm90ZToN Cj4+PiBPbiAxOC8wNi8yMDIwIDA2OjIyLCBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbyB3cm90ZToN Cj4+Pj4gT24gNi80LzIwIDY6MzEgUE0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4+Pj4+ IE9uIFRodSwgNCBKdW4gMjAyMCwgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gd3JvdGU6DQo+Pj4+ Pj4gT24gNi80LzIwIDQ6NTcgQU0sIFBlbmcgRmFuIHdyb3RlOg0KPj4+Pj4+PiBHcmFsbCA8anVs aWVuQHhlbi5vcmc+Ow0KPj4+Pj4+Pj4gTmF0YWxpeWEgS29yb3ZraW5hIDxtYWx1cy5icmFuZHl3 aW5lQGdtYWlsLmNvbT4NCj4+Pj4+Pj4+IFN1YmplY3Q6IFVFRkkgc3VwcG9ydCBpbiBBUk0gRG9t VXMNCj4+Pj4+Pj4gV2UgaGF2ZSBtYWRlIFUtQm9vdCBydW4gaW5zaWRlIFhFTiBEb21VLCBidXQg anVzdCBvbmx5IFBWIGNvbnNvbGUNCj4+Pj4+Pj4gcGFydCwNCj4+Pj4+Pj4gbm90IGltcGxlbWVu dCBvdGhlciBmcm9udGVuZCBkcml2ZXJzIGN1cnJlbnRseS4gV291bGQgdGhpcyBoZWxwIGZvcg0K Pj4+Pj4+PiB5b3VyDQo+Pj4+Pj4+IGNhc2UgaWYgZW5hYmxlIEVGSSBpbiBVLUJvb3Q/DQo+Pj4+ Pj4gV2VsbCwgd2UgaGF2ZSBhIHdvcmtpbmcgUFYgYmxvY2sgaW1wbGVtZW50YXRpb24gb24gdG9w IG9mIHRoYXQgb24gaU1YOA0KPj4+Pj4+DQo+Pj4+Pj4gcGxhdGZvcm0sIG1vc3RseSBwb3J0ZWQg ZnJvbSBtaW5pLW9zLiBDdXJyZW50bHkgd2UgYXJlIGZpbmFsaXppbmcgdGhlDQo+Pj4+Pj4gd29y aw0KPj4+Pj4+DQo+Pj4+Pj4gYW5kIGNsZWFuaW5nIHVwIChpdCdzIGdvaW5nIHRvIHRha2UgYSB3 ZWVrIG9yIHNvIGhvcGVmdWxseSkuIFRoZW4sIHdlDQo+Pj4+Pj4gd2UnbGwgcG9zdA0KPj4+Pj4+ DQo+Pj4+Pj4gaXQgb24gb3VyIHB1YmxpYyBnaXRodWIuIFdlIGFyZSBhbHNvIHRoaW5raW5nIGFi b3V0IHVwc3RyZWFtaW5nIHRoZQ0KPj4+Pj4+IHdvcmssIGJ1dCBpdCBtYXkNCj4+Pj4+Pg0KPj4+ Pj4+IHRha2UgcXVpdGUgc29tZSB0aW1lIGlmIHRoZSB3aG9sZSBpZGVhIGZpdHMgdS1ib290J3Mg dmlldyBvbiBzdWNoIGFuDQo+Pj4+Pj4gZXh0ZW5zaW9uIGF0IGFsbC4NCj4+Pj4+IFllcyBwbGVh c2UgdG8gYm90aCBvZiB5b3UhIDotKQ0KPj4+Pj4NCj4+Pj4+IEluIHRoZSBtZWFudGltZSwgd2hp bGUgd2Ugd2FpdCBmb3IgdGhvc2UgY2hhbmdlcyB0byBnbyB1cHN0cmVhbSBpbg0KPj4+Pj4gdWJv b3QsIGNvdWxkIHlvdSBwbGVhc2UgcG9zdCBhIGJyYW5jaCBvbiBnaXRodWIgYW5kIGEgbGluayBv biB0aGlzIGVtYWlsDQo+Pj4+PiB0aHJlYWQ/DQo+Pj4+IEl0IHRvb2sgYSBiaXQgbW9yZSB0aW1l IHRoYW4gd2UgZXhwZWN0ZWQsIGJ1dCBoZXJlIHdlIGdvIFsxXToNCj4+Pj4NCj4+Pj4gdGhpcyBp cyBpbiBmb3JtIG9mIGEgcHVsbC1yZXF1ZXN0IGFzIHdlIHdvdWxkIGxvdmUgdG8gaGVhciBmcm9t IHRoZQ0KPj4+Pg0KPj4+PiBjb21tdW5pdHkgYW5kIGl0IGlzIGVhc2llciB0byBkaXNjdXNzIHRo ZSBjb2RlIChwbGVhc2UgbGVhdmUgY29tbWVudHMgdGhlcmUpDQo+Pj4+DQo+Pj4+IDEuIFRoZXJl IGlzIGNvZGUgb3JpZ2luYXRpbmcgZnJvbSBNaW5pT1MgYW5kIHdvcmsgZG9uZSBieSBQZW5nLCBz byB3ZQ0KPj4+Pg0KPj4+PiB3b3VsZCBsaWtlIHRvIGFzayB0aGUgcmVzcGVjdGl2ZSBjb3B5cmln aHQgb3duZXJzIHRvIHJhaXNlIHRoZWlyIGhhbmRzIGFuZA0KPj4+IE5vdCBldmVyeW9uZSBhcmUg Y2xvc2VseSB3YXRjaGluZyB4ZW4tZGV2ZWwuIFNvIGlmIHlvdSB3YW50IHRvIGZpbmQgb3V0IHdo bw0KPj4+IGFyZSB0aGUgY29weXJpZ2h0IG93bmVycywgdGhlbiB5b3VyIGJlc3Qgc29sdXRpb24g aXMgdG8gZ28gdGhyb3VnaCB0aGUgZ2l0IGxvZw0KPj4+IGFuZCBDQyB0aGUgYXV0aG9ycy4NCj4+ IFRoYXQgaXMgdHJ1ZS4gQnV0IHdoeSBkbyB5b3Ugd2FudCB0byBjb250YWN0IHRoZW0/IEl0IGRv ZXNuJ3QgbG9vayBsaWtlDQo+PiB0aGVyZSB3b3VsZCBiZSBhbnkgbGljZW5zaW5nIGlzc3Vlcy4N Cj4gIEZyb20gdGhlIHNlbnRlbmNlLCBJIHdhc24ndCBlbnRpcmVseSBzdXJlIHdoZXRoZXIgaGUg d2FudGVkIHRvIGNvbnRhY3QNCj4gdGhlIGNvcHlyaWdodCBvd25lciBmb3IgY3JlZGl0aW5nIHRo ZW0gaW4gdGhlIGhlYWRlcnMuDQo+DQo+Pj4+IDUuIFdlIHVzZSAtRF9fWEVOX18gdG8gYWNjZXNz IHNvbWUgb2YgdGhlIGhpZGRlbiBkZWZpbmVzIHdlIG5lZWQgc3VjaCBhcw0KPj4+Pg0KPj4+PiBH VUVTVF9SQU0wX0JBU0UgYW5kIHRoZSBmcmllbmRzIGFzIHRoZXJlIGlzIG5vIG90aGVyIHdheSBi dXQgbWFudWFsbHkNCj4+Pj4gZGVmaW5pbmcgdGhlDQo+Pj4+DQo+Pj4+IHNhbWUgd2hpY2ggaXMg bm90IGN1dGUuDQo+Pj4gSSBoYXZlIHJlcGxpZWQgdG8gdGhpcyBpbiB0aGUgcHVsbCByZXF1ZXN0 LiBCdXQgSSB3YW50IHRvIGJyaW5nIHRoZQ0KPj4+IGNvbnZlcnNhdGlvbiBoZXJlIHRvIGhhdmUg YSB3aWRlciBkaXNjdXNzaW9uLg0KPj4+DQo+Pj4gRm9yIGEgZmlyc3QsIF9fWEVOX18gc2hvdWxk IHJlYWxseSBvbmx5IGJlIGRlZmluZWQgYnkgdGhlIGh5cGVydmlzb3IgYW5kIG5vdA0KPj4+IHVz ZWQgYnkgdGhlIGd1ZXN0LiBUaGlzIGlzIHVzZWQgdG8gZ2F0ZSBub24tc3RhYmxlIEFCSSAoc3Vj aCBhcyB0aGUgdG9vbHMpIGFuZA0KPj4+IGFueXRoaW5nIGJlaGluZCBpdCBoYXNuJ3QgYmVlbiB2 ZXR0ZWQgdG8gd29yayBpbiBvdGhlciBidWlsZCBjb25maWd1cmF0aW9uDQo+Pj4gdGhhdCB0aGUg b25lIHVzZWQgYnkgWGVuLg0KPj4+DQo+Pj4gSW4gZ2VuZXJhbCwgd2UgZXhwZWN0IHRoZSBndWVz dCB0byBkaXNjb3ZlciBldmVyeXRoaW5nIGZvciB0aGUgZGV2aWNlLXRyZWUNCj4+PiBiZWNhdXNl IHRoZSBtZW1vcnkgbGF5b3V0IGlzIG5vdCBzdGFibGUgKHdlIHdhbnQgdG8gYmUgYWJsZSB0byBy ZXNodWZmbGUgYXMgd2UNCj4+PiBhZGQgbW9yZSBmZWF0dXJlcykuDQo+Pj4NCj4+PiBJIGtub3cg dGhhdCBFREsyL1RpYW5vY29yZSBjYW4gYmUgYnVpbHQgb25jZSBhbmQgd29yayBvbiBldmVyeSBY ZW4NCj4+PiBjb25maWd1cmF0aW9uLiBJdCB3b3VsZCBiZSBpZGVhbCB0aGF0IFUtYm9vdCBmb2xs b3cgdGhlIHNhbWUuIElmIGl0IGlzIHJlYWxseQ0KPj4+IG5vdCBwb3NzaWJsZSwgdGhlbiB3ZSBz aG91bGQgZXhwbG9yZSBhIHBhdGggdGhhdCBpcyBwcmV2ZW50aW5nIHRvIGRlZmluZQ0KPj4+IF9f WEVOX18uDQo+Pj4NCj4+PiBIb3cgbXVjaCBkb2VzIFUtYm9vdCBleHBlY3QgdG8ga25vdyBhYm91 dCB0aGUgbWVtb3J5IGxheW91dD8gRG9lcyBpdCByZXF1aXJlDQo+Pj4gdG8ga25vdyBhbGwgdGhl IG1lbW9yeSBiYW5rcz8gT3Igd291bGQgaXQgYmUgc3VmZmljaWVudCBmb3IgaXQgdG8ga25vdyB0 aGUNCj4+PiBzdGFydCBhZGRyZXNzIG9mIHRoZSBmaXJzdCBiYW5rIGFuZCB0aGUgbWluaW11bSBv ZiBSQU0/DQo+PiBDb3B5L3Bhc3RpbmcgaGVyZSBmcm9tIG15IGNvbW1lbnQgb24gdGhlIHB1bGwg cmVxdWVzdCBwbHVzIGFkZGl0aW9uYWwNCj4+IHRob3VnaHRzLg0KPj4NCj4+IFVib290IGlzIG9u ZSBvZiB0aG9zZSBlbWJlZGRlZCBwcm9qZWN0cyB0aGF0IHR5cGljYWxseSBhc3N1bWVzIHRoYXQg YWxsDQo+PiB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBsYXRmb3JtIGlzIGF2YWlsYWJsZSBh dCAqYnVpbGQgdGltZSouIEl0IGlzDQo+PiBtZWFudCB0byBiZSBidWlsdCB0YWlsb3JlZCBmb3Ig YSBzcGVjaWZpYyB2ZXJzaW9uIG9mIGEgc3BlY2lmaWMgYm9hcmQuIEENCj4+IFVib290IGJpbmFy eSBpcyBub3QgZXhwZWN0ZWQgdG8gYmUgInBvcnRhYmxlIiBhY3Jvc3MgZGlmZmVyZW50IHZlcnNp b25zDQo+PiBvZiB0aGUgcGxhdGZvcm0gb3IgZGlmZmVyZW50IHBsYXRmb3Jtcy4gSW4gb3RoZXIg d29yZHMsIGl0IGlzIG5vdA0KPj4gZXhwZWN0ZWQgdG8gYmUgcG9ydGFibGUgYWNyb3NzIFhlbiB2 ZXJzaW9ucy4NCj4gQ2FuIHlvdSBkZWZpbmUgInZlcnNpb24iIGhlcmU/IERvIHlvdSByZWZlciB0 byB0aGUgZGlmZmVyZW5jZSBpbiB0ZXJtcw0KPiBvZiBtZW1vcnk/DQo+DQo+PiBUaGlzIGlzIGEg ZGlmZmVyZW50IG1vZGVsIG1lYW50IGZvciBkaWZmZXJlbnQgdXNlLWNhc2VzLiBJIGRvbid0IHRo aW5rDQo+PiBpdCBpcyBhIHByb2JsZW0gInBoaWxvc29waGljYWxseSIgdG8gbGV0IFVib290IGtu b3cgYWJvdXQgWGVuIGRldGFpbHMgYXQNCj4+IGJ1aWxkIHRpbWUuIFllcywgdGhhdCBpcyBub3Qg d2hhdCB3ZSBkaWQgaGlzdG9yaWNhbGx5IGJ1dCBpdCBpcyB2ZXJ5DQo+PiBtdWNoIGluIHRoZSBz cGlyaXQgb2YgVWJvb3QuDQo+IFRCSCwgSSBkb24ndCBwYXJ0aWN1bGFybHkgbWluZCB0aGF0IFUt Ym9vdCBpcyBidWlsdCBhZ2FpbnN0IGEgc3BlY2lmaWMNCj4gdmVyc2lvbiBvZiBYZW4uIEkgYW0g bW9yZSBjb25jZXJuZWQgYWJvdXQgdGhlIGxvbmcgdGVybSBpbXBsaWNhdGlvbiBpZg0KPiB3ZSBl bmRvcnNlIGl0DQo+IGFuZCB0aGVuIHRyeSB0byBjaGFuZ2UgdGhlIG1lbW9yeSBsYXlvdXQgaW4g ZGVwdGguDQo+DQo+PiBCdXQgb2YgY291cnNlIHRoZSBsZWFzdCBVYm9vdCBkZXBlbmRzIG9uIHRo ZXNlIGRldGFpbHMgdGhlIGJldHRlcg0KPj4gYmVjYXVzZSBpdCB3aWxsIGJlIG1vcmUgZmxleGli bGUsIGJ1dCBpdCBjb3VsZCB2ZXJ5IHdlbGwgYmUgdGhhdCB3ZQ0KPj4gd29uJ3QgYmUgYWJsZSB0 byByZWFjaCB0aGUgcG9pbnQgd2hlcmUgdGhlIGJpbmFyeSB3b3JrcyBvbiBhbnkgdmVyc2lvbg0K Pj4gbGlrZSB3ZSBkaWQgd2l0aCBUaWFub2NvcmUuIFRoZSB0d28gcHJvamVjdHMgd29yayBkaWZm ZXJlbnRseS4NCj4gQ2FuIHdlIGhhdmUgYSBsaXN0IG9mIHRoaW5ncyBVLWJvb3QgcmVxdWlyZSB0 byBrbm93IGF0IGNvbXBpbGUgdGltZT8NCj4NCj4gSW4gcGFydGljdWxhciwgSSB3b3VsZCBsaWtl IHRvIHVuZGVyc3RhbmQgaWYgaXQgd291bGQgYmUgc3VmZmljaWVudCB0bw0KPiBvbmx5IGJlIGF3 YXJlIG9mIHRoZSBmaXJzdCBiYW5rLiBJZiBpdCBpcywgdGhlbiBteSBwcmVmZXJlbmNlIHdvdWxk IGJlDQo+IHRvIHN0YW5kYXJkaXplIHRoYXQgYml0IG9mIHRoZSBsYXlvdXQuDQoNCldlbGwsIG15 IGJhZCwgSSB3YXMgbm90IHJpZ2h0IGFib3V0IFBJRS4gV2UgYXJlIGx1Y2t5IHRoYXQgaXQgaXMg c3VwcG9ydGVkDQoNCmZvciBBUk02NCwgc28gd2UgY2FuIGF2b2lkIHVzaW5nIEdVRVNUX1JBTTBf QkFTRS4NCg0KV2l0aCByZXNwZWN0IHRvIHRoZSBudW1iZXIgb2YgYmFua3MgSSBzZWUgbm8gYmln IGlzc3VlIGlmIHdlIGRvIG5vdCB1c2UNCg0KR1VFU1RfUkFNX0JBTktTLCBidXQgc2V0IGl0IHRv IDEuDQoNClRoZSBsYXN0IHRoaW5nIGF0IHRoZSBtb21lbnQgdGhhdCBJIGFtIG5vdCBzdXJlIG9m IGlzIEdVRVNUX01BR0lDX3tCQVNFfFNJWkV9Og0KDQp0aG9zZSBjYW4gYmUgcmV0cmlldmVkIGZy b20gdGhlIGRldmljZSB0cmVlIGFuZCBJJ2xsIGhhdmUgdG8gY2hlY2sgaWYNCg0KZmR0IGlzIGF2 YWlsYWJsZSBhdCB0aGUgdmVyeSBlYXJseSBib290IHN0YWdlIHNvIHdlIGNhbiBnZXQgdGhhdCB3 aGVuIGl0IGlzIG5lZWRlZC4NCg0KV2UnbGwga2VlcCB5b3UgdXBkYXRlZCBvbiB0aGlzDQoNCj4+ IFRoYXQgc2FpZCwgSSB0aGluayBKdWxpZW4gaXMgcmlnaHQgdGhhdCB3ZSBuZWVkIHRvIGJlIGNh cmVmdWwgb24gaG93IHdlDQo+PiBleHBvc2UgdGhlc2UgaW5mb3JtYXRpb24gdG8gVWJvb3QsIGku ZS4gZGVmaW5pbmcgX19YRU5fXyB0byBidWlsZCBVYm9vdA0KPj4gZG9lc24ndCBzZWVtIGxpa2Ug YSBnb29kIGlkZWEgYmVjYXVzZSB3ZSBlbmFibGUgZGVmaW5pdGlvbnMgdGhhdCB3ZXJlDQo+PiBu ZXZlciBtZWFudCB0byBiZSB1c2VkIG91dHNpZGUgb2YgYSBYZW4gYnVpbGQuIEFsc28sIGl0IHdv dWxkbid0IGJlIGVhc3kNCj4+IHRvIGtub3cgZXhhY3RseSB3aGljaCBkZWZpbml0aW9ucyBhcmUg YWN0aXZlbHkgdXNlZCBieSBVYm9vdCBhbmQgd2hpY2gNCj4+IG9uZXMgYXJlbid0Lg0KPj4NCj4+ IElmIHdlIGFyZSBnb2luZyB0byBtYWtlIFVib290IGRlcGVuZGVudCBvbiB2ZXJzaW9uLXNwZWNp ZmljIGluZm9ybWF0aW9uDQo+PiBvZiB0aGUgWGVuIGludGVyZmFjZSwgaXQgd291bGQgYmUgYmV0 dGVyIHRvIGJlIHZlcnkgY2xlYXIgYWJvdXQgd2hpY2gNCj4+IGRlZmluaXRpb25zIHdlIGFyZSB1 c2luZy4gU28gdGhhdCBvbmUgZGF5IGlmIHdlIG5lZWQgdG8gY2hhbmdlIHRoZW0sIHdlDQo+PiBj YW4gZmluZCB0aGVtIGVhc2lseS4NCj4+DQo+PiBTbyBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRl ciB0byBpbnRyb2R1Y2UgYSBzZXQgb2YgZGVmaW5lcyB3aXRoIHRoZQ0KPj4gbWluaW11bSBhbW91 bnQgb2YgaW5mb3JtYXRpb24gcmVxdWlyZWQgYnkgVWJvb3Qgc3RhdGljYWxseS4gVGhhdCB3YXks DQo+PiBhdCBsZWFzdCB3ZSBoYXZlIGEgc2luZ2xlIHBsYWNlIHdoZXJlIHRvIGZpbmQgYWxsIHRo ZSB2ZXJzaW9uLXNwZWNpZmljDQo+PiBkZWZpbml0aW9ucyB0aGF0IFVib290IGlzIHVzaW5nLg0K PiBJIGFtIG5vdCBzdXJlIHdoYXQgeW91IGFyZSBzdWdnZXN0aW5nLiBDYW4geW91IGV4cGFuZCBh IGJpdCBtb3JlPw0KPg0KPj4gV2UgY2FuIGFsc28gbWFuYWdlIHZlcnNpb25pbmcgb2YgdGhlDQo+ PiBYZW4gaW50ZXJmYWNlIChsaWtlIHdlIGRvIGluIFFFTVUpIGlmIHdlIGhhdmUgdG8uDQo+IENh biB5b3UgcHJvdmlkZSBtb3JlIGRldGFpbHMgYWJvdXQgdGhlIGNvbXBhdGliaWxpdHk/IEkgYW0g cXVpdGUNCj4gaW50ZXJlc3RlZCBpbiB0aGUgcGFydCB3aGVyZSB5b3Ugd291bGQgaGF2ZSB0byBk ZWFsIHdpdGggYW4gb2xkZXIgUUVNVQ0KPiB2ZXJzaW9uIGJ1aWx0IGFnYWluc3QgYSBuZXcgWGVu Pw0KPg0KPiBDaGVlcnMs From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:36:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:36:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGFa-0003nl-Uo; Fri, 19 Jun 2020 12:36:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGFZ-0003ng-7L for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:36:05 +0000 X-Inumbo-ID: 6df5ff20-b229-11ea-bb79-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6df5ff20-b229-11ea-bb79-12813bfff9fa; Fri, 19 Jun 2020 12:36:00 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id B4C86A3479; Fri, 19 Jun 2020 14:35:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A23B6A2C6C; Fri, 19 Jun 2020 14:35:57 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PIGH2CyjRmv1; Fri, 19 Jun 2020 14:35:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id E9BBEA3478; Fri, 19 Jun 2020 14:35:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rD96HgxpXxCn; Fri, 19 Jun 2020 14:35:56 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id B0A9AA2C6C; Fri, 19 Jun 2020 14:35:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 9CCA321000; Fri, 19 Jun 2020 14:35:26 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id bXILZbiN6RZR; Fri, 19 Jun 2020 14:35:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 370052247F; Fri, 19 Jun 2020 14:35:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vIObhvTjidDM; Fri, 19 Jun 2020 14:35:21 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 0E1AA21000; Fri, 19 Jun 2020 14:35:21 +0200 (CEST) Date: Fri, 19 Jun 2020 14:35:20 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <1494219989.10184041.1592570120971.JavaMail.zimbra@cert.pl> In-Reply-To: <20200619113434.GZ735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1060400786.9820894.1592523480084.JavaMail.zimbra@cert.pl> <20200619113434.GZ735@Air-de-Roger> Subject: Re: [PATCH v2 1/7] xen/mm: lift 32 item limit from mfn/gfn arrays MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: xen/mm: lift 32 item limit from mfn/gfn arrays Thread-Index: 9ePTz9uC4rSX28Kka1ieARXLoMMfNw== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 13:34, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Fri, Jun 19, 2020 at 01:38:00AM +0200, Micha=C5=82 Leszczy=C5=84ski wr= ote: >> Replace on-stack array allocation with heap allocation >> in order to lift the limit of 32 items in mfn/gfn arrays >> when calling acquire_resource. >=20 > I'm afraid this is not correct, you cannot allow unbounded amounts of > items to be processed like this, it's likely that you manage to > trigger the watchdog if the list is long enough, specially when doing > set_foreign_p2m_entry. >=20 > You need to process the items in batches (32 was IMO a good start), and > then add support for hypercall continuations. Take a look at how > XENMEM_populate_physmap just a couple of lines below makes use of > hypercall_create_continuation. >=20 > After processing every batch you need to check if > hypercall_preempt_check returns true and if so use > hypercall_create_continuation in order to encode a continuation. >=20 > Thanks, Roger. One more question. Are these continuations transparent from the caller side= , or do I also need to add something on the invoker side to properly handle t= hese continuations? Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:37:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:37:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGGw-0003vn-9f; Fri, 19 Jun 2020 12:37:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGGv-0003vi-I9 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:37:29 +0000 X-Inumbo-ID: a2b21280-b229-11ea-bb79-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a2b21280-b229-11ea-bb79-12813bfff9fa; Fri, 19 Jun 2020 12:37:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EF96AAEBF; Fri, 19 Jun 2020 12:37:26 +0000 (UTC) Subject: Re: [PATCH for-4.14 6/8] x86/vpt: fix injection to remote vCPU To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Stefano Stabellini References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-7-roger.pau@citrix.com> <57b6f9fd-4cbc-abc9-09e3-6493eba6c377@suse.com> <20200618171413.GX735@Air-de-Roger> From: Jan Beulich Message-ID: <164b1af6-a1e0-c25d-0d79-062803cc7c77@suse.com> Date: Fri, 19 Jun 2020 14:37:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200618171413.GX735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 19:14, Roger Pau Monné wrote: > On Thu, Jun 18, 2020 at 05:12:17PM +0200, Jan Beulich wrote: >> On 12.06.2020 17:56, Roger Pau Monne wrote: >>> case PTSRC_ioapic: >>> pt_vector = hvm_ioapic_assert(v->domain, irq, level); >>> - if ( pt_vector < 0 || !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) >>> - { >>> - pt_vector = -1; >>> - if ( level ) >>> + if ( pt_vector < 0 ) >>> + return pt_vector; >>> + >>> + break; >>> + } >>> + >>> + ASSERT(pt_vector >= 0); >>> + if ( !vlapic_test_irq(vcpu_vlapic(v), pt_vector) ) >>> + { >>> + time_cb *cb = NULL; >>> + void *cb_priv; >>> + >>> + /* >>> + * Vector has been injected to a different vCPU, call pt_irq_fired and >>> + * execute the callback, since the destination vCPU(s) won't call >>> + * pt_intr_post for it. >> >> ... this isn't the only reason to come here. Beyond what the comment >> says there is the hvm_domain_use_pirq() check in assert_gsi() which >> would similarly result in the IRR bit not observed set here. At the >> very least these cases want mentioning; I have to admit that I'm not >> entirely clear yet whether your handling is correct for both, or >> whether the information needs to be propagated into here. > > I always forget about that weird pirq stuff (and I'm refraining from > using other adjectives) that we have for HVM. > > AFAICT vpt is already broken when trying to inject interrupts > generated from it over an event channel. hvm_ioapic_assert will return > whatever garbage is in the IO-APIC entry, which will likely not be > initialized because the GSI is routed over an event channel. > > I really have no idea what hvm_ioapic_assert should return in that > case, the event channel callback vector maybe? > > Maybe just returning -1 would be fine, a guest using this routing of > pirqs over event channels shouldn't be using any of the emulated > timers, and hence vpt is not required to be functional in that case? I would guess(!) that -1 ought to be fine. But this whole thing escapes me as well, so let's ask Stefano, who iirc was who introduced this. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:38:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:38:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGHa-00041G-Mm; Fri, 19 Jun 2020 12:38:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGHZ-000418-LQ for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:38:09 +0000 X-Inumbo-ID: bb032bbc-b229-11ea-b7bb-bc764e2007e4 Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id bb032bbc-b229-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 12:38:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592570288; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0vzAKNhIebVNhmPTwwk2+p6+FeyRJcrmAq4fe7SPCF8=; b=QqXsN73Xd3UR+F5S5SrZZdF9D+XDzE2gnwYRobTuq3HE8eO1h/PKFb1AMr471Yos/o0a4o BnteE/xhz1LqZmoSjHh4h9j9PzRbOH5CwXqnL9GkkDy016aemJMMsSClgynU1pUM88iTBa OGOfaAM81g1QAPhaPJ6Ox1WJUWWLf4I= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-313-MZOZUjo2OZym8Wv5_BRnNg-1; Fri, 19 Jun 2020 08:38:06 -0400 X-MC-Unique: MZOZUjo2OZym8Wv5_BRnNg-1 Received: by mail-wr1-f70.google.com with SMTP id y16so435896wrr.20 for ; Fri, 19 Jun 2020 05:38:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0vzAKNhIebVNhmPTwwk2+p6+FeyRJcrmAq4fe7SPCF8=; b=R1TVsgTAhKllER/pAo3egWT3lfty7do7IwfxbQv3aYlRVYtm1kpFH3A7yARNvIGxT/ bgZjhNZklKfYOAbkJSDmPHgCPkLjGfPXgMduJW9j0bWe7AqFCyQakY5sGfV0dfz6zR21 ZTmxdZGHICvuqClqeb32wmSAsgEW9MS3NZnEQkc92C7ZLCi4QBWZ2pH8UQpClBnygBit VfwQFQ//z3GuQaemhVQimiaGxO+BH8rw1JNMQAg5gOmJalZgx4+bAu4Btj3rg3KQoWec EeQ2ATfFXG6Ggty922W3sa/av5wcE6DcdsSqsEqkAu/gikOgZVURZYHu2/Jfk/P5ffAe ho0Q== X-Gm-Message-State: AOAM530qyzVxRTypdFWn6hRuP2rLUxmCoYMWYWCFfctseDTq9bY/DWmI gXBWr3+2YamAiTvdYcsFF06MlRpRgyC+U77rsOmbcj75df39n15byLLtCm8Ci3gHkLGK7joHGW5 FM2ucbN0u5Jg+XYj+tye2EVec6LQ= X-Received: by 2002:adf:a1c1:: with SMTP id v1mr3988940wrv.205.1592570285588; Fri, 19 Jun 2020 05:38:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKe+Jqm+9+qRBocH+ge+ctOBwEa9VJyyU/fXDgduU6zy7HpK/JjOJEWzFAFBJZy+Rk1KZCjw== X-Received: by 2002:adf:a1c1:: with SMTP id v1mr3988925wrv.205.1592570285337; Fri, 19 Jun 2020 05:38:05 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:e1d2:138e:4eff:42cb? ([2001:b07:6468:f312:e1d2:138e:4eff:42cb]) by smtp.gmail.com with ESMTPSA id z16sm7179070wrm.70.2020.06.19.05.38.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 05:38:04 -0700 (PDT) Subject: Re: [PATCH] xen: Actually fix build without passthrough To: Anthony PERARD , qemu-devel@nongnu.org References: <20200619103115.254127-1-anthony.perard@citrix.com> From: Paolo Bonzini Message-ID: Date: Fri, 19 Jun 2020 14:38:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200619103115.254127-1-anthony.perard@citrix.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Stefano Stabellini , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/06/20 12:31, Anthony PERARD wrote: > Fix typo. > > Fixes: acd0c9416d48 ("xen: fix build without pci passthrough") > Signed-off-by: Anthony PERARD > --- > hw/xen/Makefile.objs | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs > index 3fc715e5954d..502b32d877a0 100644 > --- a/hw/xen/Makefile.objs > +++ b/hw/xen/Makefile.objs > @@ -4,4 +4,4 @@ common-obj-y += xen-legacy-backend.o xen_devconfig.o xen_pvdev.o xen-bus.o xen-b > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o xen_pt_graphics.o xen_pt_msi.o > obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt_load_rom.o > -obj-$(call $(lnot, $(CONFIG_XEN_PCI_PASSTHROUGH))) += xen_pt_stub.o > +obj-$(call lnot,$(CONFIG_XEN_PCI_PASSTHROUGH)) += xen_pt_stub.o > Queued, thanks and sorry about that. Paolo From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:39:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:39:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGJC-00049e-29; Fri, 19 Jun 2020 12:39:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGJA-00049W-FZ for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:39:48 +0000 X-Inumbo-ID: f5c21538-b229-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f5c21538-b229-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 12:39:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EAF48ACA3; Fri, 19 Jun 2020 12:39:45 +0000 (UTC) Subject: Re: [PATCH v2 1/7] xen/mm: lift 32 item limit from mfn/gfn arrays To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1060400786.9820894.1592523480084.JavaMail.zimbra@cert.pl> <20200619113434.GZ735@Air-de-Roger> <1494219989.10184041.1592570120971.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <4cbf963d-7cf0-3fdb-b456-db2845244dec@suse.com> Date: Fri, 19 Jun 2020 14:39:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1494219989.10184041.1592570120971.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Tamas K Lengyel , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 14:35, Michał Leszczyński wrote: > ----- 19 cze 2020 o 13:34, Roger Pau Monné roger.pau@citrix.com napisał(a): > >> On Fri, Jun 19, 2020 at 01:38:00AM +0200, Michał Leszczyński wrote: >>> Replace on-stack array allocation with heap allocation >>> in order to lift the limit of 32 items in mfn/gfn arrays >>> when calling acquire_resource. >> >> I'm afraid this is not correct, you cannot allow unbounded amounts of >> items to be processed like this, it's likely that you manage to >> trigger the watchdog if the list is long enough, specially when doing >> set_foreign_p2m_entry. >> >> You need to process the items in batches (32 was IMO a good start), and >> then add support for hypercall continuations. Take a look at how >> XENMEM_populate_physmap just a couple of lines below makes use of >> hypercall_create_continuation. >> >> After processing every batch you need to check if >> hypercall_preempt_check returns true and if so use >> hypercall_create_continuation in order to encode a continuation. > > One more question. Are these continuations transparent from the caller side, > or do I also need to add something on the invoker side to properly handle these > continuations? They are (mostly) transparent to the guest, yes. "Mostly" because we have cases (iirc) where the continuation data is stored in a way that a guest could observe it. But it still wouldn't need to do anything in order for the hypercall to get continued until it completes (which may be "fails", faod). Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:47:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:47:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGQI-00052e-RY; Fri, 19 Jun 2020 12:47:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGQH-00052Z-Fn for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:47:09 +0000 X-Inumbo-ID: fc977758-b22a-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fc977758-b22a-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 12:47:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=HTgC+hpoU6gPMr/gJxnOul3qmLpvAZ+e4obyg0AhgNc=; b=mKoYCMH7WCJi/A0cnUFuJFr75p YCVEHPYtnrT+dkdGeYXLGrIOcsJcHDlrtXefz6v7zOz/43uPsBPzlZGcQzjWTMXCRctpMQ5tPm6sw 4vnP33Tu/RWZf1HvcYe9n7EfRTShYhI27/yVgUGVaAIj6cDMBXdjJrYTQK5uq9pX2jUQ=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGQE-0006yE-Fs; Fri, 19 Jun 2020 12:47:06 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jmGQD-0000tm-Mx; Fri, 19 Jun 2020 12:47:06 +0000 Subject: Re: UEFI support in ARM DomUs To: Oleksandr Andrushchenko , Julien Grall , Stefano Stabellini References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> From: Julien Grall Message-ID: <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> Date: Fri, 19 Jun 2020 13:47:03 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Oleksandr, On 19/06/2020 13:32, Oleksandr Andrushchenko wrote: > > On 6/19/20 1:49 AM, Julien Grall wrote: >> On Thu, 18 Jun 2020 at 23:00, Stefano Stabellini wrote: >>> On Thu, 18 Jun 2020, Julien Grall wrote: >>>> On 18/06/2020 06:22, Oleksandr Andrushchenko wrote: >>>>> On 6/4/20 6:31 PM, Stefano Stabellini wrote: >>>>>> On Thu, 4 Jun 2020, Oleksandr Andrushchenko wrote: >>>>>>> On 6/4/20 4:57 AM, Peng Fan wrote: >>>>>>>> Grall ; >>>>>>>>> Nataliya Korovkina >>>>>>>>> Subject: UEFI support in ARM DomUs >>>>>>>> We have made U-Boot run inside XEN DomU, but just only PV console >>>>>>>> part, >>>>>>>> not implement other frontend drivers currently. Would this help for >>>>>>>> your >>>>>>>> case if enable EFI in U-Boot? >>>>>>> Well, we have a working PV block implementation on top of that on iMX8 >>>>>>> >>>>>>> platform, mostly ported from mini-os. Currently we are finalizing the >>>>>>> work >>>>>>> >>>>>>> and cleaning up (it's going to take a week or so hopefully). Then, we >>>>>>> we'll post >>>>>>> >>>>>>> it on our public github. We are also thinking about upstreaming the >>>>>>> work, but it may >>>>>>> >>>>>>> take quite some time if the whole idea fits u-boot's view on such an >>>>>>> extension at all. >>>>>> Yes please to both of you! :-) >>>>>> >>>>>> In the meantime, while we wait for those changes to go upstream in >>>>>> uboot, could you please post a branch on github and a link on this email >>>>>> thread? >>>>> It took a bit more time than we expected, but here we go [1]: >>>>> >>>>> this is in form of a pull-request as we would love to hear from the >>>>> >>>>> community and it is easier to discuss the code (please leave comments there) >>>>> >>>>> 1. There is code originating from MiniOS and work done by Peng, so we >>>>> >>>>> would like to ask the respective copyright owners to raise their hands and >>>> Not everyone are closely watching xen-devel. So if you want to find out who >>>> are the copyright owners, then your best solution is to go through the git log >>>> and CC the authors. >>> That is true. But why do you want to contact them? It doesn't look like >>> there would be any licensing issues. >> From the sentence, I wasn't entirely sure whether he wanted to contact >> the copyright owner for crediting them in the headers. >> >>>>> 5. We use -D__XEN__ to access some of the hidden defines we need such as >>>>> >>>>> GUEST_RAM0_BASE and the friends as there is no other way but manually >>>>> defining the >>>>> >>>>> same which is not cute. >>>> I have replied to this in the pull request. But I want to bring the >>>> conversation here to have a wider discussion. >>>> >>>> For a first, __XEN__ should really only be defined by the hypervisor and not >>>> used by the guest. This is used to gate non-stable ABI (such as the tools) and >>>> anything behind it hasn't been vetted to work in other build configuration >>>> that the one used by Xen. >>>> >>>> In general, we expect the guest to discover everything for the device-tree >>>> because the memory layout is not stable (we want to be able to reshuffle as we >>>> add more features). >>>> >>>> I know that EDK2/Tianocore can be built once and work on every Xen >>>> configuration. It would be ideal that U-boot follow the same. If it is really >>>> not possible, then we should explore a path that is preventing to define >>>> __XEN__. >>>> >>>> How much does U-boot expect to know about the memory layout? Does it require >>>> to know all the memory banks? Or would it be sufficient for it to know the >>>> start address of the first bank and the minimum of RAM? >>> Copy/pasting here from my comment on the pull request plus additional >>> thoughts. >>> >>> Uboot is one of those embedded projects that typically assumes that all >>> the information about the platform is available at *build time*. It is >>> meant to be built tailored for a specific version of a specific board. A >>> Uboot binary is not expected to be "portable" across different versions >>> of the platform or different platforms. In other words, it is not >>> expected to be portable across Xen versions. >> Can you define "version" here? Do you refer to the difference in terms >> of memory? >> >>> This is a different model meant for different use-cases. I don't think >>> it is a problem "philosophically" to let Uboot know about Xen details at >>> build time. Yes, that is not what we did historically but it is very >>> much in the spirit of Uboot. >> TBH, I don't particularly mind that U-boot is built against a specific >> version of Xen. I am more concerned about the long term implication if >> we endorse it >> and then try to change the memory layout in depth. >> >>> But of course the least Uboot depends on these details the better >>> because it will be more flexible, but it could very well be that we >>> won't be able to reach the point where the binary works on any version >>> like we did with Tianocore. The two projects work differently. >> Can we have a list of things U-boot require to know at compile time? >> >> In particular, I would like to understand if it would be sufficient to >> only be aware of the first bank. If it is, then my preference would be >> to standardize that bit of the layout. > > Well, my bad, I was not right about PIE. We are lucky that it is supported > > for ARM64, so we can avoid using GUEST_RAM0_BASE. Cool! > > With respect to the number of banks I see no big issue if we do not use > > GUEST_RAM_BANKS, but set it to 1. I am guessing U-boot wouldn't be able to load modules into the second bank. Am I corre > The last thing at the moment that I am not sure of is GUEST_MAGIC_{BASE|SIZE}: > > those can be retrieved from the device tree and I'll have to check if > > fdt is available at the very early boot stage so we can get that when it is needed. They will not be available from the fdt, but you can retrieve them with an hypervisor call (see HVM_PARAM_STORE_PFN, HVM_PARAM_CONSOLE_PFN). One question though, why do you need to map them in advance? Couldn't you map them on demand? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:48:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:48:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGRH-00057x-5O; Fri, 19 Jun 2020 12:48:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGRG-00057r-L0 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:48:10 +0000 X-Inumbo-ID: 1e8a1c30-b22b-11ea-bb7a-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1e8a1c30-b22b-11ea-bb7a-12813bfff9fa; Fri, 19 Jun 2020 12:48:05 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 18EC3ACB8; Fri, 19 Jun 2020 12:48:03 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs To: Andrew Cooper References: <20200619115823.22243-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <32440578-e346-85cc-abad-1aa5694f0ab2@suse.com> Date: Fri, 19 Jun 2020 14:48:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200619115823.22243-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 13:58, Andrew Cooper wrote: > --- a/xen/arch/x86/msr.c > +++ b/xen/arch/x86/msr.c > @@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) > case MSR_TSX_FORCE_ABORT: > case MSR_TSX_CTRL: > case MSR_MCU_OPT_CTRL: > + case MSR_RTIT_OUTPUT_BASE: > + case MSR_RTIT_OUTPUT_MASK: > + case MSR_RTIT_CTL: > + case MSR_RTIT_STATUS: > + case MSR_RTIT_CR3_MATCH: > + case MSR_RTIT_ADDR_A(0) ... MSR_RTIT_ADDR_B(3): The respective CPUID field is 3 bits wide, so wouldn't it be better to cover the full possible range (0...6 afaict)? Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:49:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:49:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGSF-0005EP-FA; Fri, 19 Jun 2020 12:49:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGSE-0005EI-TK for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:49:10 +0000 X-Inumbo-ID: 4424b8b0-b22b-11ea-bb7a-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4424b8b0-b22b-11ea-bb7a-12813bfff9fa; Fri, 19 Jun 2020 12:49:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 59BD8ABCE; Fri, 19 Jun 2020 12:49:07 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <20200619115823.22243-1-andrew.cooper3@citrix.com> <1417373854.10164826.1592568614663.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: Date: Fri, 19 Jun 2020 14:49:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1417373854.10164826.1592568614663.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 14:10, Michał Leszczyński wrote: > ----- 19 cze 2020 o 13:58, Andrew Cooper andrew.cooper3@citrix.com napisał(a): > >> We do not expose the feature to guests, so should disallow access to the >> respective MSRs. >> >> Signed-off-by: Andrew Cooper >> --- >> CC: Jan Beulich >> CC: Wei Liu >> CC: Roger Pau Monné >> CC: Paul Durrant >> CC: Michał Leszczyński >> >> Paul: For 4.14. This needs backporting to older trees as well. >> >> Michał: CC'ing, just to keep you in the loop. Xen has some dubious default >> MSR semantics which we're still in the middle of untangling in a backwards >> compatible way. Patches like this will eventually not be necessary, but they >> are for now. > > > As for external IPT monitoring, it would be best if the VM would think > that IPT is simply not supported at all by the underlying hypervisor. This is already the case, isn't it? Yet not reporting a feature may not keep a guest from trying to access the respective MSRs. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:51:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:51:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGUr-00060P-VI; Fri, 19 Jun 2020 12:51:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGUq-00060K-U0 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:51:52 +0000 X-Inumbo-ID: a514d380-b22b-11ea-bca7-bc764e2007e4 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.79]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a514d380-b22b-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 12:51:51 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FpcLMO/d1qeq6GJkM02yrGo/11Soys4OQJsv5zHRFBydwQ2iT4uRDCdzGL3Ga/QqkAOdw0kxfmPuVc+WFJZfzJxRlzbsbPcmynoPM7Zx+zX8Sj0qly+lyVvOcFkXyjs0uP+rhJCI05lgWC0ELOvkUDmI610TUm9S99lXBbVhIZmS+LUoJjuFjDpBfjP+TpjCEMsrR9KFHnI6KIZa5tlo8BsfrBzKNqWdmADk7SnyBM3AbcF9DUSMmf43Wz1DzwF6MxymPQPai4sESNJ02i1tzqAqwOPI/qNcBUcSGMBXRYfv5Nb3Bn1oM44LgIWhR16EbfH6MuYKGvvvTADtvP6w3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HDcnI4KgVWRjuMitVxQSkotXiuFxzW5CUoKP4RMbwNg=; b=YuIjhipby5AiprxlJT7Yc0tfoLWYrpZo1ZFcPYMR1i4eG1tcjI/rXHFXau/UJoHrLK98srkU7ydLL988JW9fdCd1PVvNKxZoGRPs3ujgMRVE20aaL0G9UTbBZZIRSsWBlRAfT6ven1KAnNBrp8g892VWGEvIZV9pFn1fA6leOYlISgGMBO/7JDe1mvjtK6s5IEtI8GPba31asQGbOBOlcjE1po6DUq8uX7zPC9Hx4VQU/DqOIyRDvwVse/RiY97q07uX8oKaGMAIZOqqbiGmwOjIJ7erUJB/63RRI6DUI8l31dZ7oraWbr3ugnY7Iryi5IFYst15tGdamqEzNw8dRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HDcnI4KgVWRjuMitVxQSkotXiuFxzW5CUoKP4RMbwNg=; b=6Tu3s29kPNbR1rcAf+75q9EkE4Ng9cm6VbZnjUr9JvmoSYDPTl2rWursziOXqEs5XyZgYXZ8DpYtOohEK4DXRUglsTiT/GUlSb26jy/C1jyCsmvRyvoKB7VBCLwdd13tbPgb+8gcOa87Oidg+mAdOZzrorIl9Br/PPBqRQWEhJ1mKMVNTDhXpLMBxdATbHzdF5mQuGxNvi8CKkB9lm9lI6ejZiLeEs9LLRIU8281nYwPTQXwf8ReKJywmaypKXwv00LmnlImD9pyZDCwfcu9wwQj/ZAvDxb0MDC5uePvXD0w9lz+w8enzWRBew952Pn28bwz5ropC9lm0mNDpI1tWw== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB6559.eurprd03.prod.outlook.com (2603:10a6:800:193::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Fri, 19 Jun 2020 12:51:50 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 12:51:50 +0000 From: Oleksandr Andrushchenko To: Julien Grall , Julien Grall , Stefano Stabellini Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAOXggIAABCWAgAABUwA= Date: Fri, 19 Jun 2020 12:51:49 +0000 Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> In-Reply-To: <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a2a79ca8-3d84-4fe4-4d97-08d8144f88a2 x-ms-traffictypediagnostic: VI1PR03MB6559: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FDOTIiozBTjWvVvlWJfU9JnYa3JfXuaeohWFGclTVFQK2yFRf3rwxyNo6HSM6tQ7u2eUQDNUKA/Iz0JsQkUUBCicY+S8joKYV1BSiS8HPPcsdTcU1ZznUTLVNtFw9jRlK80gkzBFPHe5PUtcS6H9D7K/IASRO5GsNg+VQ0IBanHRoF896rooob/LDPFZ/9VHOrRQ/IKd/YpoYvpxpzGFm6Ixz02tUpf+z/+3PXEGEPDV0zMca8H1s/nNQetx3m285gWHZ3tE6I9d+ekg7/S8+JNJtuWoomJXVeDJxB7AsOZqImHW5Iv7UQ+aroKtrbW1T7yB9sgdZCIWCaPacKTZ5w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(366004)(376002)(136003)(396003)(83380400001)(478600001)(6512007)(31696002)(91956017)(76116006)(5660300002)(110136005)(66556008)(66446008)(64756008)(6506007)(86362001)(316002)(66476007)(66946007)(53546011)(6486002)(186003)(26005)(4326008)(8676002)(2906002)(71200400001)(31686004)(8936002)(54906003)(2616005)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: /ff5yT0t7zjVcFLc96xO0NvON+59wPoAr4BU+vWTOlWipBeCNllExY0s/XjzOZR0Z/QWrIUU/EX/L6LojyuOHRuWx2SlRpwXsdA6mhV16GFiL7yIRPm5eewUkurXfhh39XTCp6mS4lpoULGaWbcnAQs3oqd07CiOIEuOs9RNw0Yh52ylaNdvYNUfh1jvwfxnnTNFxk9FrY+FUpijaa5mSLI7cRxa4qkkTUgVxrdlNDoEO3s+AwX9hkt7rtvYwdnpwGCeJC7Q86bZlJMY5EygPK55JFPcqLNSC/FrRHsC8yREU4jo6JMCaqs6gFWElTVn9thcRp4X8DTibobtfxK1KBhM3bVF5h9ydkMsFodV+NiNon2Vbp8Y/VQemktIPzX+ujYxdSvI+iFCkACxFX2hp7dDb4fHTXZSOQIAIbxo5wfClMaDtD+biAEV8QmMem+wuHTwnVJdeFuV0xOWhgCXSFNr/Wa8j6d50FiktcGm4dQ= Content-Type: text/plain; charset="utf-8" Content-ID: <0020F99FA59F9C45AFF58317D92110E2@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2a79ca8-3d84-4fe4-4d97-08d8144f88a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 12:51:49.8316 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: k8nal8yMDiUpCE9Pk1AIKQKviJEGfKrGu213IiYEHPvfGj4ZWb/aQwUVqIDPCJw4y3jSzRLFMeC9vK2JN6D89cnF7XQo/5YqJ5Y/C4tOGQtW1BfoDArVTdCrXkxUCsKB X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6559 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzE5LzIwIDM6NDcgUE0sIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkgT2xla3NhbmRy LA0KPg0KPiBPbiAxOS8wNi8yMDIwIDEzOjMyLCBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbyB3cm90 ZToNCj4+DQo+PiBPbiA2LzE5LzIwIDE6NDkgQU0sIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+PiBP biBUaHUsIDE4IEp1biAyMDIwIGF0IDIzOjAwLCBTdGVmYW5vIFN0YWJlbGxpbmkgPHNzdGFiZWxs aW5pQGtlcm5lbC5vcmc+IHdyb3RlOg0KPj4+PiBPbiBUaHUsIDE4IEp1biAyMDIwLCBKdWxpZW4g R3JhbGwgd3JvdGU6DQo+Pj4+PiBPbiAxOC8wNi8yMDIwIDA2OjIyLCBPbGVrc2FuZHIgQW5kcnVz aGNoZW5rbyB3cm90ZToNCj4+Pj4+PiBPbiA2LzQvMjAgNjozMSBQTSwgU3RlZmFubyBTdGFiZWxs aW5pIHdyb3RlOg0KPj4+Pj4+PiBPbiBUaHUsIDQgSnVuIDIwMjAsIE9sZWtzYW5kciBBbmRydXNo Y2hlbmtvIHdyb3RlOg0KPj4+Pj4+Pj4gT24gNi80LzIwIDQ6NTcgQU0sIFBlbmcgRmFuIHdyb3Rl Og0KPj4+Pj4+Pj4+IEdyYWxsIDxqdWxpZW5AeGVuLm9yZz47DQo+Pj4+Pj4+Pj4+IE5hdGFsaXlh IEtvcm92a2luYSA8bWFsdXMuYnJhbmR5d2luZUBnbWFpbC5jb20+DQo+Pj4+Pj4+Pj4+IFN1Ympl Y3Q6IFVFRkkgc3VwcG9ydCBpbiBBUk0gRG9tVXMNCj4+Pj4+Pj4+PiBXZSBoYXZlIG1hZGUgVS1C b290IHJ1biBpbnNpZGUgWEVOIERvbVUsIGJ1dCBqdXN0IG9ubHkgUFYgY29uc29sZQ0KPj4+Pj4+ Pj4+IHBhcnQsDQo+Pj4+Pj4+Pj4gbm90IGltcGxlbWVudCBvdGhlciBmcm9udGVuZCBkcml2ZXJz IGN1cnJlbnRseS4gV291bGQgdGhpcyBoZWxwIGZvcg0KPj4+Pj4+Pj4+IHlvdXINCj4+Pj4+Pj4+ PiBjYXNlIGlmIGVuYWJsZSBFRkkgaW4gVS1Cb290Pw0KPj4+Pj4+Pj4gV2VsbCwgd2UgaGF2ZSBh IHdvcmtpbmcgUFYgYmxvY2sgaW1wbGVtZW50YXRpb24gb24gdG9wIG9mIHRoYXQgb24gaU1YOA0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IHBsYXRmb3JtLCBtb3N0bHkgcG9ydGVkIGZyb20gbWluaS1vcy4g Q3VycmVudGx5IHdlIGFyZSBmaW5hbGl6aW5nIHRoZQ0KPj4+Pj4+Pj4gd29yaw0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+IGFuZCBjbGVhbmluZyB1cCAoaXQncyBnb2luZyB0byB0YWtlIGEgd2VlayBvciBz byBob3BlZnVsbHkpLiBUaGVuLCB3ZQ0KPj4+Pj4+Pj4gd2UnbGwgcG9zdA0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IGl0IG9uIG91ciBwdWJsaWMgZ2l0aHViLiBXZSBhcmUgYWxzbyB0aGlua2luZyBhYm91 dCB1cHN0cmVhbWluZyB0aGUNCj4+Pj4+Pj4+IHdvcmssIGJ1dCBpdCBtYXkNCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiB0YWtlIHF1aXRlIHNvbWUgdGltZSBpZiB0aGUgd2hvbGUgaWRlYSBmaXRzIHUtYm9v dCdzIHZpZXcgb24gc3VjaCBhbg0KPj4+Pj4+Pj4gZXh0ZW5zaW9uIGF0IGFsbC4NCj4+Pj4+Pj4g WWVzIHBsZWFzZSB0byBib3RoIG9mIHlvdSEgOi0pDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEluIHRoZSBt ZWFudGltZSwgd2hpbGUgd2Ugd2FpdCBmb3IgdGhvc2UgY2hhbmdlcyB0byBnbyB1cHN0cmVhbSBp bg0KPj4+Pj4+PiB1Ym9vdCwgY291bGQgeW91IHBsZWFzZSBwb3N0IGEgYnJhbmNoIG9uIGdpdGh1 YiBhbmQgYSBsaW5rIG9uIHRoaXMgZW1haWwNCj4+Pj4+Pj4gdGhyZWFkPw0KPj4+Pj4+IEl0IHRv b2sgYSBiaXQgbW9yZSB0aW1lIHRoYW4gd2UgZXhwZWN0ZWQsIGJ1dCBoZXJlIHdlIGdvIFsxXToN Cj4+Pj4+Pg0KPj4+Pj4+IHRoaXMgaXMgaW4gZm9ybSBvZiBhIHB1bGwtcmVxdWVzdCBhcyB3ZSB3 b3VsZCBsb3ZlIHRvIGhlYXIgZnJvbSB0aGUNCj4+Pj4+Pg0KPj4+Pj4+IGNvbW11bml0eSBhbmQg aXQgaXMgZWFzaWVyIHRvIGRpc2N1c3MgdGhlIGNvZGUgKHBsZWFzZSBsZWF2ZSBjb21tZW50cyB0 aGVyZSkNCj4+Pj4+Pg0KPj4+Pj4+IDEuIFRoZXJlIGlzIGNvZGUgb3JpZ2luYXRpbmcgZnJvbSBN aW5pT1MgYW5kIHdvcmsgZG9uZSBieSBQZW5nLCBzbyB3ZQ0KPj4+Pj4+DQo+Pj4+Pj4gd291bGQg bGlrZSB0byBhc2sgdGhlIHJlc3BlY3RpdmUgY29weXJpZ2h0IG93bmVycyB0byByYWlzZSB0aGVp ciBoYW5kcyBhbmQNCj4+Pj4+IE5vdCBldmVyeW9uZSBhcmUgY2xvc2VseSB3YXRjaGluZyB4ZW4t ZGV2ZWwuIFNvIGlmIHlvdSB3YW50IHRvIGZpbmQgb3V0IHdobw0KPj4+Pj4gYXJlIHRoZSBjb3B5 cmlnaHQgb3duZXJzLCB0aGVuIHlvdXIgYmVzdCBzb2x1dGlvbiBpcyB0byBnbyB0aHJvdWdoIHRo ZSBnaXQgbG9nDQo+Pj4+PiBhbmQgQ0MgdGhlIGF1dGhvcnMuDQo+Pj4+IFRoYXQgaXMgdHJ1ZS4g QnV0IHdoeSBkbyB5b3Ugd2FudCB0byBjb250YWN0IHRoZW0/IEl0IGRvZXNuJ3QgbG9vayBsaWtl DQo+Pj4+IHRoZXJlIHdvdWxkIGJlIGFueSBsaWNlbnNpbmcgaXNzdWVzLg0KPj4+IMKgIEZyb20g dGhlIHNlbnRlbmNlLCBJIHdhc24ndCBlbnRpcmVseSBzdXJlIHdoZXRoZXIgaGUgd2FudGVkIHRv IGNvbnRhY3QNCj4+PiB0aGUgY29weXJpZ2h0IG93bmVyIGZvciBjcmVkaXRpbmcgdGhlbSBpbiB0 aGUgaGVhZGVycy4NCj4+Pg0KPj4+Pj4+IDUuIFdlIHVzZSAtRF9fWEVOX18gdG8gYWNjZXNzIHNv bWUgb2YgdGhlIGhpZGRlbiBkZWZpbmVzIHdlIG5lZWQgc3VjaCBhcw0KPj4+Pj4+DQo+Pj4+Pj4g R1VFU1RfUkFNMF9CQVNFIGFuZCB0aGUgZnJpZW5kcyBhcyB0aGVyZSBpcyBubyBvdGhlciB3YXkg YnV0IG1hbnVhbGx5DQo+Pj4+Pj4gZGVmaW5pbmcgdGhlDQo+Pj4+Pj4NCj4+Pj4+PiBzYW1lIHdo aWNoIGlzIG5vdCBjdXRlLg0KPj4+Pj4gSSBoYXZlIHJlcGxpZWQgdG8gdGhpcyBpbiB0aGUgcHVs bCByZXF1ZXN0LiBCdXQgSSB3YW50IHRvIGJyaW5nIHRoZQ0KPj4+Pj4gY29udmVyc2F0aW9uIGhl cmUgdG8gaGF2ZSBhIHdpZGVyIGRpc2N1c3Npb24uDQo+Pj4+Pg0KPj4+Pj4gRm9yIGEgZmlyc3Qs IF9fWEVOX18gc2hvdWxkIHJlYWxseSBvbmx5IGJlIGRlZmluZWQgYnkgdGhlIGh5cGVydmlzb3Ig YW5kIG5vdA0KPj4+Pj4gdXNlZCBieSB0aGUgZ3Vlc3QuIFRoaXMgaXMgdXNlZCB0byBnYXRlIG5v bi1zdGFibGUgQUJJIChzdWNoIGFzIHRoZSB0b29scykgYW5kDQo+Pj4+PiBhbnl0aGluZyBiZWhp bmQgaXQgaGFzbid0IGJlZW4gdmV0dGVkIHRvIHdvcmsgaW4gb3RoZXIgYnVpbGQgY29uZmlndXJh dGlvbg0KPj4+Pj4gdGhhdCB0aGUgb25lIHVzZWQgYnkgWGVuLg0KPj4+Pj4NCj4+Pj4+IEluIGdl bmVyYWwsIHdlIGV4cGVjdCB0aGUgZ3Vlc3QgdG8gZGlzY292ZXIgZXZlcnl0aGluZyBmb3IgdGhl IGRldmljZS10cmVlDQo+Pj4+PiBiZWNhdXNlIHRoZSBtZW1vcnkgbGF5b3V0IGlzIG5vdCBzdGFi bGUgKHdlIHdhbnQgdG8gYmUgYWJsZSB0byByZXNodWZmbGUgYXMgd2UNCj4+Pj4+IGFkZCBtb3Jl IGZlYXR1cmVzKS4NCj4+Pj4+DQo+Pj4+PiBJIGtub3cgdGhhdCBFREsyL1RpYW5vY29yZSBjYW4g YmUgYnVpbHQgb25jZSBhbmQgd29yayBvbiBldmVyeSBYZW4NCj4+Pj4+IGNvbmZpZ3VyYXRpb24u IEl0IHdvdWxkIGJlIGlkZWFsIHRoYXQgVS1ib290IGZvbGxvdyB0aGUgc2FtZS4gSWYgaXQgaXMg cmVhbGx5DQo+Pj4+PiBub3QgcG9zc2libGUsIHRoZW4gd2Ugc2hvdWxkIGV4cGxvcmUgYSBwYXRo IHRoYXQgaXMgcHJldmVudGluZyB0byBkZWZpbmUNCj4+Pj4+IF9fWEVOX18uDQo+Pj4+Pg0KPj4+ Pj4gSG93IG11Y2ggZG9lcyBVLWJvb3QgZXhwZWN0IHRvIGtub3cgYWJvdXQgdGhlIG1lbW9yeSBs YXlvdXQ/IERvZXMgaXQgcmVxdWlyZQ0KPj4+Pj4gdG8ga25vdyBhbGwgdGhlIG1lbW9yeSBiYW5r cz8gT3Igd291bGQgaXQgYmUgc3VmZmljaWVudCBmb3IgaXQgdG8ga25vdyB0aGUNCj4+Pj4+IHN0 YXJ0IGFkZHJlc3Mgb2YgdGhlIGZpcnN0IGJhbmsgYW5kIHRoZSBtaW5pbXVtIG9mIFJBTT8NCj4+ Pj4gQ29weS9wYXN0aW5nIGhlcmUgZnJvbSBteSBjb21tZW50IG9uIHRoZSBwdWxsIHJlcXVlc3Qg cGx1cyBhZGRpdGlvbmFsDQo+Pj4+IHRob3VnaHRzLg0KPj4+Pg0KPj4+PiBVYm9vdCBpcyBvbmUg b2YgdGhvc2UgZW1iZWRkZWQgcHJvamVjdHMgdGhhdCB0eXBpY2FsbHkgYXNzdW1lcyB0aGF0IGFs bA0KPj4+PiB0aGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBsYXRmb3JtIGlzIGF2YWlsYWJsZSBh dCAqYnVpbGQgdGltZSouIEl0IGlzDQo+Pj4+IG1lYW50IHRvIGJlIGJ1aWx0IHRhaWxvcmVkIGZv ciBhIHNwZWNpZmljIHZlcnNpb24gb2YgYSBzcGVjaWZpYyBib2FyZC4gQQ0KPj4+PiBVYm9vdCBi aW5hcnkgaXMgbm90IGV4cGVjdGVkIHRvIGJlICJwb3J0YWJsZSIgYWNyb3NzIGRpZmZlcmVudCB2 ZXJzaW9ucw0KPj4+PiBvZiB0aGUgcGxhdGZvcm0gb3IgZGlmZmVyZW50IHBsYXRmb3Jtcy4gSW4g b3RoZXIgd29yZHMsIGl0IGlzIG5vdA0KPj4+PiBleHBlY3RlZCB0byBiZSBwb3J0YWJsZSBhY3Jv c3MgWGVuIHZlcnNpb25zLg0KPj4+IENhbiB5b3UgZGVmaW5lICJ2ZXJzaW9uIiBoZXJlPyBEbyB5 b3UgcmVmZXIgdG8gdGhlIGRpZmZlcmVuY2UgaW4gdGVybXMNCj4+PiBvZiBtZW1vcnk/DQo+Pj4N Cj4+Pj4gVGhpcyBpcyBhIGRpZmZlcmVudCBtb2RlbCBtZWFudCBmb3IgZGlmZmVyZW50IHVzZS1j YXNlcy4gSSBkb24ndCB0aGluaw0KPj4+PiBpdCBpcyBhIHByb2JsZW0gInBoaWxvc29waGljYWxs eSIgdG8gbGV0IFVib290IGtub3cgYWJvdXQgWGVuIGRldGFpbHMgYXQNCj4+Pj4gYnVpbGQgdGlt ZS4gWWVzLCB0aGF0IGlzIG5vdCB3aGF0IHdlIGRpZCBoaXN0b3JpY2FsbHkgYnV0IGl0IGlzIHZl cnkNCj4+Pj4gbXVjaCBpbiB0aGUgc3Bpcml0IG9mIFVib290Lg0KPj4+IFRCSCwgSSBkb24ndCBw YXJ0aWN1bGFybHkgbWluZCB0aGF0IFUtYm9vdCBpcyBidWlsdCBhZ2FpbnN0IGEgc3BlY2lmaWMN Cj4+PiB2ZXJzaW9uIG9mIFhlbi4gSSBhbSBtb3JlIGNvbmNlcm5lZCBhYm91dCB0aGUgbG9uZyB0 ZXJtIGltcGxpY2F0aW9uIGlmDQo+Pj4gd2UgZW5kb3JzZSBpdA0KPj4+IGFuZCB0aGVuIHRyeSB0 byBjaGFuZ2UgdGhlIG1lbW9yeSBsYXlvdXQgaW4gZGVwdGguDQo+Pj4NCj4+Pj4gQnV0IG9mIGNv dXJzZSB0aGUgbGVhc3QgVWJvb3QgZGVwZW5kcyBvbiB0aGVzZSBkZXRhaWxzIHRoZSBiZXR0ZXIN Cj4+Pj4gYmVjYXVzZSBpdCB3aWxsIGJlIG1vcmUgZmxleGlibGUsIGJ1dCBpdCBjb3VsZCB2ZXJ5 IHdlbGwgYmUgdGhhdCB3ZQ0KPj4+PiB3b24ndCBiZSBhYmxlIHRvIHJlYWNoIHRoZSBwb2ludCB3 aGVyZSB0aGUgYmluYXJ5IHdvcmtzIG9uIGFueSB2ZXJzaW9uDQo+Pj4+IGxpa2Ugd2UgZGlkIHdp dGggVGlhbm9jb3JlLiBUaGUgdHdvIHByb2plY3RzIHdvcmsgZGlmZmVyZW50bHkuDQo+Pj4gQ2Fu IHdlIGhhdmUgYSBsaXN0IG9mIHRoaW5ncyBVLWJvb3QgcmVxdWlyZSB0byBrbm93IGF0IGNvbXBp bGUgdGltZT8NCj4+Pg0KPj4+IEluIHBhcnRpY3VsYXIsIEkgd291bGQgbGlrZSB0byB1bmRlcnN0 YW5kIGlmIGl0IHdvdWxkIGJlIHN1ZmZpY2llbnQgdG8NCj4+PiBvbmx5IGJlIGF3YXJlIG9mIHRo ZSBmaXJzdCBiYW5rLiBJZiBpdCBpcywgdGhlbiBteSBwcmVmZXJlbmNlIHdvdWxkIGJlDQo+Pj4g dG8gc3RhbmRhcmRpemUgdGhhdCBiaXQgb2YgdGhlIGxheW91dC4NCj4+DQo+PiBXZWxsLCBteSBi YWQsIEkgd2FzIG5vdCByaWdodCBhYm91dCBQSUUuIFdlIGFyZSBsdWNreSB0aGF0IGl0IGlzIHN1 cHBvcnRlZA0KPj4NCj4+IGZvciBBUk02NCwgc28gd2UgY2FuIGF2b2lkIHVzaW5nIEdVRVNUX1JB TTBfQkFTRS4NCj4NCj4gQ29vbCENCj4NCj4+DQo+PiBXaXRoIHJlc3BlY3QgdG8gdGhlIG51bWJl ciBvZiBiYW5rcyBJIHNlZSBubyBiaWcgaXNzdWUgaWYgd2UgZG8gbm90IHVzZQ0KPj4NCj4+IEdV RVNUX1JBTV9CQU5LUywgYnV0IHNldCBpdCB0byAxLg0KPg0KPiBJIGFtIGd1ZXNzaW5nIFUtYm9v dCB3b3VsZG4ndCBiZSBhYmxlIHRvIGxvYWQgbW9kdWxlcyBpbnRvIHRoZSBzZWNvbmQgYmFuay4g QW0gSSBjb3JyZQ0KTm90IHN1cmUsIGJ1dCB0aGlzIGNhbiBiZSB0aGUgY2FzZQ0KPj4gVGhlIGxh c3QgdGhpbmcgYXQgdGhlIG1vbWVudCB0aGF0IEkgYW0gbm90IHN1cmUgb2YgaXMgR1VFU1RfTUFH SUNfe0JBU0V8U0laRX06DQo+Pg0KPj4gdGhvc2UgY2FuIGJlIHJldHJpZXZlZCBmcm9tIHRoZSBk ZXZpY2UgdHJlZSBhbmQgSSdsbCBoYXZlIHRvIGNoZWNrIGlmDQo+Pg0KPj4gZmR0IGlzIGF2YWls YWJsZSBhdCB0aGUgdmVyeSBlYXJseSBib290IHN0YWdlIHNvIHdlIGNhbiBnZXQgdGhhdCB3aGVu IGl0IGlzIG5lZWRlZC4NCj4NCj4gVGhleSB3aWxsIG5vdCBiZSBhdmFpbGFibGUgZnJvbSB0aGUg ZmR0LCBidXQgeW91IGNhbiByZXRyaWV2ZSB0aGVtIHdpdGggYW4gaHlwZXJ2aXNvciBjYWxsIChz ZWUgSFZNX1BBUkFNX1NUT1JFX1BGTiwgSFZNX1BBUkFNX0NPTlNPTEVfUEZOKS4NClllcywgYW5k IGl0IHVzZWQgaW4gdGhlIHJlbGV2YW50IHBpZWNlcyBvZiBjb2RlIChoeXAgY2FsbHMpDQo+IE9u ZSBxdWVzdGlvbiB0aG91Z2gsIHdoeSBkbyB5b3UgbmVlZCB0byBtYXAgdGhlbSBpbiBhZHZhbmNl PyBDb3VsZG4ndCB5b3UgbWFwIHRoZW0gb24gZGVtYW5kPw0KDQpXZWxsLCB3ZSBuZWVkIHRvIGF0 IGxlYXN0IGVzdGltYXRlIHRoZSBwZ190YWJsZSBzaXplIHNvIHdlIGNhbiByZXNlcnZlIGFuZCBh bGxvY2F0ZSBtZW1vcnkgbGF0ZXIsDQoNCnNvIEkgaGF2ZSB0byBwcm92aWRlIG1lbW9yeSByYW5n ZSBmcm9tIGVpdGhlciBieSBjb2RpbmcgYSBjb25zdGFudCBvciBsb29raW5nIGludG8gdGhlIGRl dnRyZWUgYXQNCg0KaHlwZXJ2aXNvciB7IHJlZyA9IDw+OyB9LiBJdCBpcyBhIGJpdCB0cmlja3kg dGhvdWdoDQoNCj4gQ2hlZXJzLA0KPg== From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:58:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:58:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGbT-0006Fy-QS; Fri, 19 Jun 2020 12:58:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGbR-0006Ft-Rb for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:58:41 +0000 X-Inumbo-ID: 9672a1f8-b22c-11ea-bb7c-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9672a1f8-b22c-11ea-bb7c-12813bfff9fa; Fri, 19 Jun 2020 12:58:36 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9C973A3285; Fri, 19 Jun 2020 14:58:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 90327A2EC5; Fri, 19 Jun 2020 14:58:34 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QE3FnZ5m0wSX; Fri, 19 Jun 2020 14:58:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id D760CA3285; Fri, 19 Jun 2020 14:58:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id w1LIOBKjBj8d; Fri, 19 Jun 2020 14:58:33 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id B1154A2EC5; Fri, 19 Jun 2020 14:58:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 9FA7622599; Fri, 19 Jun 2020 14:58:03 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id WVRasQth4Gm2; Fri, 19 Jun 2020 14:57:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 338EA22537; Fri, 19 Jun 2020 14:57:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HTVcf9ezIggt; Fri, 19 Jun 2020 14:57:58 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 16B152254F; Fri, 19 Jun 2020 14:57:58 +0200 (CEST) Date: Fri, 19 Jun 2020 14:57:57 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <893375527.10199950.1592571477991.JavaMail.zimbra@cert.pl> In-Reply-To: References: <20200619115823.22243-1-andrew.cooper3@citrix.com> <1417373854.10164826.1592568614663.JavaMail.zimbra@cert.pl> Subject: Re: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/msr: Disallow access to Processor Trace MSRs Thread-Index: THc0AA/6//Z2X6lhwGGVbYcd5iRAcA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Andrew Cooper , Roger Pau =?utf-8?Q?Monn=C3=A9?= , Wei Liu , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 14:49, Jan Beulich jbeulich@suse.com napisa=C5=82(a): > On 19.06.2020 14:10, Micha=C5=82 Leszczy=C5=84ski wrote: >> ----- 19 cze 2020 o 13:58, Andrew Cooper andrew.cooper3@citrix.com napis= a=C5=82(a): >>=20 >>> We do not expose the feature to guests, so should disallow access to th= e >>> respective MSRs. >>> >>> Signed-off-by: Andrew Cooper >>> --- >>> CC: Jan Beulich >>> CC: Wei Liu >>> CC: Roger Pau Monn=C3=A9 >>> CC: Paul Durrant >>> CC: Micha=C5=82 Leszczy=C5=84ski >>> >>> Paul: For 4.14. This needs backporting to older trees as well. >>> >>> Micha=C5=82: CC'ing, just to keep you in the loop. Xen has some dubiou= s default >>> MSR semantics which we're still in the middle of untangling in a backwa= rds >>> compatible way. Patches like this will eventually not be necessary, bu= t they >>> are for now. >>=20 >>=20 >> As for external IPT monitoring, it would be best if the VM would think >> that IPT is simply not supported at all by the underlying hypervisor. >=20 > This is already the case, isn't it? Yet not reporting a feature may > not keep a guest from trying to access the respective MSRs. >=20 > Jan Okay, understood :) ml From xen-devel-bounces@lists.xenproject.org Fri Jun 19 12:59:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 12:59:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGcM-0006Jj-4i; Fri, 19 Jun 2020 12:59:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGcL-0006Jb-24 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 12:59:37 +0000 X-Inumbo-ID: ba81e96e-b22c-11ea-bb7c-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ba81e96e-b22c-11ea-bb7c-12813bfff9fa; Fri, 19 Jun 2020 12:59:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zZXV2cGq8quVC8rQLL/wToEmak2+bNq8yjvSM/moiPM=; b=TJeOos2H7cDfy/H/QukOyIaTHl Bnmdvk0XQaEILqjcVKprk9i3Eh/Rbf+iwYOoY/mhNpXbpjrUsDHgJ2jwOYodg7vABzc2PYqFQHla8 k2BnHksTG5kf78rKaIHNQc1gGB/BVJLkmTks0kY+8FSUD/WJkDYnMSnJxbePFAMYdndo=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGcI-0007C3-Gq; Fri, 19 Jun 2020 12:59:34 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jmGcI-0001Jc-9g; Fri, 19 Jun 2020 12:59:34 +0000 Subject: Re: UEFI support in ARM DomUs To: Oleksandr Andrushchenko , Julien Grall , Stefano Stabellini References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> From: Julien Grall Message-ID: Date: Fri, 19 Jun 2020 13:59:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 19/06/2020 13:51, Oleksandr Andrushchenko wrote: > On 6/19/20 3:47 PM, Julien Grall wrote: >> They will not be available from the fdt, but you can retrieve them with an hypervisor call (see HVM_PARAM_STORE_PFN, HVM_PARAM_CONSOLE_PFN). > Yes, and it used in the relevant pieces of code (hyp calls) >> One question though, why do you need to map them in advance? Couldn't you map them on demand? > > Well, we need to at least estimate the pg_table size so we can reserve and allocate memory later, Oh, so U-boot doesn't support runtime page-table table allocation. Is that right? > > so I have to provide memory range from either by coding a constant or looking into the devtree at > > hypervisor { reg = <>; }. It is a bit tricky though Looking for a node in the device-tree shouldn't be too difficult given that you have fdt_* available. However, please not that doesn't refer to the guest magic pages. Instead, it provides a region you can use for mapping the grant-table frames Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:06:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:06:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGiq-0007En-SM; Fri, 19 Jun 2020 13:06:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGiq-0007Ei-BM for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:06:20 +0000 X-Inumbo-ID: aa034316-b22d-11ea-bca7-bc764e2007e4 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe02::615]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id aa034316-b22d-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 13:06:18 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cmo23AvDRLbD9rNDDO2LXj1x50WFDfJ7XNCYNNhOCQLsQ+m8IBgpNS+OGIGSeUj1v5vfqkHF+OXQddys70crh/y6Q3tQyC6ToArqGFbJVdn8JhiGFaiBeYuDRwa1bBR5rJM7Bz2mmymbU/QSTNJxdTRw3qU2l873pkCYWUrlA5YN+ckrzcYH693TugyeayyGEy7EQWH84j7coZoUAi6xfxEG/5HPRSyGDFksF1J4cEG9ZovOpMYYIY+ahM1X9YKMl2ng70Wan88Ls58xy/geetw04a/NoCHhoiUFRTyP/Pkl7OS9TO6lIoLPJstxNiWWX8SF1WuC0PiT1M0oTuqw/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M4IG927phKcKuWZha4ldwB8ecfLzlDq4Hy3RACrniXk=; b=ddZ7jZq8rlKGdKPlI4ySljsSgGIJwJ2YUgFuXsDD+9N8AmYUTkOfKZatIb9s6QyezKRWKYGH/7DtSjoy1UweS/zTQvlwyJjKyrrADkTxI6FPf8gc1CYmpFq6B0ayy75EB/Ve22xLdPREg+QXXUJCF+O9T+Frar019lRHLLz2FEz+f9N3EUq7ZPpUGT1GdogA0dlduQx8yUAXrXDub6uM81wYfYlLhljNfaP376r5wCezwC0msq9In/tWHfvv6KjFylgyr1QMhy4lE6WIwBIb/o5dhDXssNhwLqqrByLzS9U5feUz3eMAil256PkfWZf/nsRfKz2tqBkONqqbcNeLcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M4IG927phKcKuWZha4ldwB8ecfLzlDq4Hy3RACrniXk=; b=L5G13lbb6lJarkGOxPsAIdfvaxiFXzN81i81TXEz0lS/NUGOxPhGriISNOyRRHGQwp3PzfdEGexouQGmA3e6yhnoJjIOS913xqJIdVRkAtiz7UQ9H+0k/UJe9dTKu8kkRE7spZ0iyHh2MPIXtbFjT9Et9A18hz3dL+HLheuJSR/9yeDE3XNTulCYt1YDd64aHnhSNo2sYUrqGNIyra+OBGJ6LsnHHxSJ0QrtbmS5wkDpgfeLqYZ7jDcBtxKdd3xDkUGzAYgzZxUErc95niubJXjEUR4g6TubTO+pfmaGIxhUAJDRYAsQb6Wvve08seO9QhAnP3U/uaDPaml0MTQb7Q== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB3920.eurprd03.prod.outlook.com (2603:10a6:803:6a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Fri, 19 Jun 2020 13:06:17 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3109.021; Fri, 19 Jun 2020 13:06:17 +0000 From: Oleksandr Andrushchenko To: Julien Grall , Julien Grall , Stefano Stabellini Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAOXggIAABCWAgAABUwCAAAIogIAAAeMA Date: Fri, 19 Jun 2020 13:06:17 +0000 Message-ID: <424cfbdc-0744-fcf7-5bb4-52aca2357df7@epam.com> References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 13403899-cc69-4d96-ad96-08d814518d96 x-ms-traffictypediagnostic: VI1PR03MB3920: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FUYpAmmwHP1ThhsxTlMrFZxh0Zw47cfdQdw8raqLA767hFq2uptIdQsKrKEuvz+Bm8WCyPv1PViZlT1bePXUGBaX3f2qTu5fdimIN1sGDsyUtbAMUgW56rRUlrQodkfPF3paEnT+dOTSn9g3SKRqiApZj46RNiUYfYRVe/lzC9C/nBDNGVQxFtxOmphb+3cb84k/ZdkoV9WjgFIFDL0QJPMuUSLl898Ex7/HLudLGyGoS0umZscQ2g8HY9J7AsqhrfB7Ijcy9MuvRo5OR01qstgDXuBZGKLGfE9gBRTJszfi8+4bL4sQmlY2xDJx2pTMVetWBfWh9NN4yiC3LVCVKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(376002)(396003)(136003)(346002)(2906002)(26005)(66946007)(91956017)(66476007)(64756008)(66556008)(66446008)(76116006)(54906003)(4326008)(5660300002)(6512007)(110136005)(316002)(186003)(6506007)(53546011)(36756003)(478600001)(2616005)(83380400001)(31686004)(86362001)(31696002)(8936002)(71200400001)(8676002)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Z+vRQlwu+ABVk6ZuIt0vqAfcd5jKwo7Fcn6BwoseugmBgujyHKyPzdsMRlNqn9iJHjnmO3W6qxy5hfE5R7vKKi7v2uI/ccbWqV7X2VuNmw96OzowEOWI6zlpEAOwv4IBWiClvj2HAbDsRttoUDhE9buySzwQZQVa0808JPs1Mm9gexiCCRNsn+T1LtYnxmcoU3Swpl5zrVf7aENwx07eLfGDmEkJxUIliVQFiUwhjDMZ0WEVCIT6bQeT2O703QXTgIl8CyfYNQybJ4p3cWZNmKJjQlXlOmxdsV5rp8ysonm7MAqvWwp7A/2xilf3YX0w0HkASCEwaGQ4pLh7EI5Qyo60iY+SxxW1ERpEPZyZYSsPdGISoxrWBwBcVfIO0YF8NWs+WKH/O7cECfTFigdl+oKFOpoUl9c6PDb7ubXP3eN9p+kgTdDXmM+vneTzCe5B4SJVQyZcHWtNY1Cs+i8or6oTtkleuSXU7Xk9IC6ZRmM= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13403899-cc69-4d96-ad96-08d814518d96 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 13:06:17.1724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bkmTD/7D36MmZAbV11rq5sgpAdBBe+p4mErvHxRP1znhk+LFfrsIuivN4ETqYbrJCP1mRiK/2c3TeRmKHrCc/cJHo2ThAMBxKuZQKFHq+thhbW4vpkKqOcf7HyrH75y2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB3920 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzE5LzIwIDM6NTkgUE0sIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGksDQo+DQo+IE9u IDE5LzA2LzIwMjAgMTM6NTEsIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPj4gT24g Ni8xOS8yMCAzOjQ3IFBNLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+Pj4gVGhleSB3aWxsIG5vdCBi ZSBhdmFpbGFibGUgZnJvbSB0aGUgZmR0LCBidXQgeW91IGNhbiByZXRyaWV2ZSB0aGVtIHdpdGgg YW4gaHlwZXJ2aXNvciBjYWxsIChzZWUgSFZNX1BBUkFNX1NUT1JFX1BGTiwgSFZNX1BBUkFNX0NP TlNPTEVfUEZOKS4NCj4+IFllcywgYW5kIGl0IHVzZWQgaW4gdGhlIHJlbGV2YW50IHBpZWNlcyBv ZiBjb2RlIChoeXAgY2FsbHMpDQo+Pj4gT25lIHF1ZXN0aW9uIHRob3VnaCwgd2h5IGRvIHlvdSBu ZWVkIHRvIG1hcCB0aGVtIGluIGFkdmFuY2U/IENvdWxkbid0IHlvdSBtYXAgdGhlbSBvbiBkZW1h bmQ/DQo+Pg0KPj4gV2VsbCwgd2UgbmVlZCB0byBhdCBsZWFzdCBlc3RpbWF0ZSB0aGUgcGdfdGFi bGUgc2l6ZSBzbyB3ZSBjYW4gcmVzZXJ2ZSBhbmQgYWxsb2NhdGUgbWVtb3J5IGxhdGVyLA0KPg0K PiBPaCwgc28gVS1ib290IGRvZXNuJ3Qgc3VwcG9ydCBydW50aW1lIHBhZ2UtdGFibGUgdGFibGUg YWxsb2NhdGlvbi4gSXMgdGhhdCByaWdodD8NCkFzIHBlciBteSB1bmRlcnN0YW5kaW5nIG5vLCB3 ZSBwcm92aWRlIGEgbWVtb3J5IG1hcCBhbmQgdGhlIHRhYmxlcyBhcmUgYWxsb2NhdGVkIGJlZm9y ZWhhbmQNCj4NCj4+DQo+PiBzbyBJIGhhdmUgdG8gcHJvdmlkZSBtZW1vcnkgcmFuZ2UgZnJvbSBl aXRoZXIgYnkgY29kaW5nIGEgY29uc3RhbnQgb3IgbG9va2luZyBpbnRvIHRoZSBkZXZ0cmVlIGF0 DQo+Pg0KPj4gaHlwZXJ2aXNvciB7IHJlZyA9IDw+OyB9LiBJdCBpcyBhIGJpdCB0cmlja3kgdGhv dWdoDQo+DQo+IExvb2tpbmcgZm9yIGEgbm9kZSBpbiB0aGUgZGV2aWNlLXRyZWUgc2hvdWxkbid0 IGJlIHRvbyBkaWZmaWN1bHQgZ2l2ZW4gdGhhdCB5b3UgaGF2ZSBmZHRfKiBhdmFpbGFibGUuDQo+ DQo+IEhvd2V2ZXIsIHBsZWFzZSBub3QgdGhhdCA8cmVnPiBkb2Vzbid0IHJlZmVyIHRvIHRoZSBn dWVzdCBtYWdpYyBwYWdlcy4gSW5zdGVhZCwgaXQgcHJvdmlkZXMgYSByZWdpb24geW91IGNhbiB1 c2UgZm9yIG1hcHBpbmcgdGhlIGdyYW50LXRhYmxlIGZyYW1lcw0KDQpJbmRlZWQsIHRoaXMgaXMg aW4gbXkgY2FzZSAweDM4MDAwMDAwLCBidXQgdGhlIG1hZ2ljIGlzIGF0IDB4MzkwMDAwMDANCg0K U28sIEkgbmVlZCB0aGUgbWVtb3J5IHJhbmdlIHNldCB1cCBiZWZvcmVoYW5kLCBidXQgSSBjYW4n dCBhcyB0aGVyZSBpcyBubyBjdXRlIHdheSB0byBnZXQgdGhhdC4NCg0KT2YgY291cnNlLCBJIGNh biBpc3N1ZSBhIGh5cCBjYWxsIHRvIGdldCBIVk1fUEFSQU1fQ09OU09MRV9QRk4gYW5kIHVzZSBp dCBhcyB0aGUgYmFzZSBhZGRyZXNzLA0KDQpidXQgdGhpcyBzbWVsbHMgbGlrZSBhIGhhY2suIEkg Y2FuIGNhbGwgb3RoZXIgSFZNX1BBUkFNXyB0byBnZXQgdGhlaXIgcGZucyBhbmQgc2V0IHVwIHRo ZSBtZW1vcnkgcmVnaW9ucywNCg0KYnV0IHRoaXMgbG9va3MgYSBiaXQgd2VpcmQuIEkgbmVlZCB0 aGF0IGNvbnN0YW50IGJhZGx5IDspDQoNCj4NCj4gQ2hlZXJzLA0KPg== From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:16:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:16:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGsH-00086C-RL; Fri, 19 Jun 2020 13:16:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGsG-000867-99 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:16:04 +0000 X-Inumbo-ID: 05c729f0-b22f-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 05c729f0-b22f-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 13:16:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Gxtpy3wKaiujZqGND5x3qlI360qJxjKkMgMBDWnt/eM=; b=kM1yvideLYs22lXVHvRvMSqG8t bxFK4UBbs6oYIipkXcWf7b2LWiXQaJ5KDoSKTCpwIS+9bNV724rZTixH3UmKtso6nCKjK3xFtI6FE MBLY1lFuo3qkQSOjt55vvciwkP18iPmO38WyWYgRfph8/mrVD2cJdnjpvwix7iWYCxlU=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGsB-0007Xz-SY; Fri, 19 Jun 2020 13:15:59 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jmGsB-0002Tj-KS; Fri, 19 Jun 2020 13:15:59 +0000 Subject: Re: UEFI support in ARM DomUs To: Oleksandr Andrushchenko , Julien Grall , Stefano Stabellini References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> <424cfbdc-0744-fcf7-5bb4-52aca2357df7@epam.com> From: Julien Grall Message-ID: Date: Fri, 19 Jun 2020 14:15:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <424cfbdc-0744-fcf7-5bb4-52aca2357df7@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/06/2020 14:06, Oleksandr Andrushchenko wrote: > > On 6/19/20 3:59 PM, Julien Grall wrote: >> Hi, >> >> On 19/06/2020 13:51, Oleksandr Andrushchenko wrote: >>> On 6/19/20 3:47 PM, Julien Grall wrote: >>>> They will not be available from the fdt, but you can retrieve them with an hypervisor call (see HVM_PARAM_STORE_PFN, HVM_PARAM_CONSOLE_PFN). >>> Yes, and it used in the relevant pieces of code (hyp calls) >>>> One question though, why do you need to map them in advance? Couldn't you map them on demand? >>> >>> Well, we need to at least estimate the pg_table size so we can reserve and allocate memory later, >> >> Oh, so U-boot doesn't support runtime page-table table allocation. Is that right? > As per my understanding no, we provide a memory map and the tables are allocated beforehand Ok :(. >> >>> >>> so I have to provide memory range from either by coding a constant or looking into the devtree at >>> >>> hypervisor { reg = <>; }. It is a bit tricky though >> >> Looking for a node in the device-tree shouldn't be too difficult given that you have fdt_* available. >> >> However, please not that doesn't refer to the guest magic pages. Instead, it provides a region you can use for mapping the grant-table frames > > Indeed, this is in my case 0x38000000, but the magic is at 0x39000000 > > So, I need the memory range set up beforehand, but I can't as there is no cute way to get that. > > Of course, I can issue a hyp call to get HVM_PARAM_CONSOLE_PFN and use it as the base address, > > but this smells like a hack. I can call other HVM_PARAM_ to get their pfns and set up the memory regions, > > but this looks a bit weird. Why is it weird? In general, you only want to map exactly what you need. Not less, not more. In your situation, you only care about two pages, the console page and the xenstore page. The rest shouldn't be mapped. > I need that constant badly ;) No you don't ;). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:16:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:16:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGsM-00086v-3h; Fri, 19 Jun 2020 13:16:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGsK-00086L-Cn for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:16:08 +0000 X-Inumbo-ID: 07a4126a-b22f-11ea-bb7d-12813bfff9fa Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.43]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 07a4126a-b22f-11ea-bb7d-12813bfff9fa; Fri, 19 Jun 2020 13:16:05 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mqhAmZvxCsPKRU+/gfVNSOiqPU0Uw6+dYvKCgZVXpbfwjih6NfvNKz7fYYh3odzkK7MfrLA9JIKozqsExxd0sToZ1sAnp0Wao8AgiH7jqhSLH5FzEzV7/bY7xaUvE8YREvgxDxOgh8suWmWZ6z1O8L4f3KG31f9IvBGxuWqH97FTz0P+LUCgajus2DooOriIK/rJkgnrzaIEykCKeyT4pp8ooZVKjfX3aygULb+Opyrq2GsRkAJ81vOHm6H/lm5XlzKNjzOK/fqS9f8it16X2xXwmObUylmCM7ypXsuUy6XlEaki3H9sYtpheYVvs3M0m1JI7A6O30UhIJN5GePP5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UEdNxY+g7LQrXV8ZeUkIs+/yYdtSpwkUlHJjyyLUgeg=; b=SPNTcWdugMK5P8J/FBCyiJQB03xjVz8irHqlzQRw/D9XKMVES6LAmMXj+csLo9OzyUx0ZwY6W44X0w6jht9RpekTMecr7G7otkQsVXJJcjiydPGcF/SGspglrpgzGD34a11GMx6OVqewkF1fYaFgRoviiJGtgksXUTZbhzahtWes6zwJeacEbRMOeJ6ffEE43Yx92RjE4i2C03qdD3zQujDjSmceBniHD/9TGj0daIgDjAH33kACwgjMNXqheNhIBNebVojRG4vMECG3aAcmy7zqfCFJ+slL/p3a48+N2sKaXhCRjDvsmGsZE8eW8MPzNNndkaLJdOTWS3N50m0jAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UEdNxY+g7LQrXV8ZeUkIs+/yYdtSpwkUlHJjyyLUgeg=; b=Icj+zMYy652aMy2tz3e4ncHg7aEh6W8mqr19XGpVAmkANTOV/X1ZXVArYzJeo66X0/D+ZVDCjFHbRV4ejuamPt/s/tLk30tyg4xqGJLiwUFfIEwg/8s0HEjbjEQ7yHIlKLUCp5/YrB48cR75DRJ2KU70fdzne+nCFATs/gYN3zA= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2919.eurprd04.prod.outlook.com (2603:10a6:4:9b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Fri, 19 Jun 2020 13:16:04 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3088.028; Fri, 19 Jun 2020 13:16:03 +0000 From: Peng Fan To: Oleksandr Andrushchenko , Julien Grall , Julien Grall , Stefano Stabellini Subject: RE: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWN5exllox/cqJUUS0HFcLChNz8ajHt2rggADieACAAAFjAIAVVnEAgACes4CAAHgUgIAADcUAgADl4QCAAAQjgIAAAVWAgAACJ4CAAAHkgIAAAn4A Date: Fri, 19 Jun 2020 13:16:03 +0000 Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> <424cfbdc-0744-fcf7-5bb4-52aca2357df7@epam.com> In-Reply-To: <424cfbdc-0744-fcf7-5bb4-52aca2357df7@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: epam.com; dkim=none (message not signed) header.d=none;epam.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [49.72.109.34] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 54c4c149-85d0-4000-5b17-08d81452eb3d x-ms-traffictypediagnostic: DB6PR0402MB2919: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Rj+KAp8p2p15Ue4rDYvbLXbYC2JnchUlxHt9aKm/W1mJPsyPRph7R4krHyRap9J9aLFA91RjGxu5pnMxzTCupj84/c/rHtAyhCGKzzsAgc8BxPkkwvzYAj0MbAoNcil6POAJ/j0CTRMn+5dtSFJhhp4grtivrPIgNI98SnWVHORozWw9GvzzK8xv+PN8gGDU43Yc8QZBFXPoW0e2k3aa11hdDaxeq8u9ZslNSzl2NxL3uJ6zAYNKQ6lEyrfXAr9SUdLP3TyrHpGTiqIdbnymddhU6td6FH0exqUgi4fnfAmpf2u+nz7mJnFFU0Fh/LTtyKtp9wAyXupZRAbiMIHAJA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(366004)(346002)(136003)(396003)(26005)(52536014)(66946007)(71200400001)(44832011)(66556008)(64756008)(76116006)(66476007)(66446008)(5660300002)(186003)(86362001)(9686003)(4326008)(55016002)(53546011)(7416002)(316002)(8676002)(110136005)(2906002)(478600001)(6506007)(54906003)(8936002)(33656002)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LlbiR0yH6DnOqvg5z6P+oOWVIISWM8sNWUeY0gldd55nbWWl3kqjx7/BsC3JqBnRV1ZB+l5xyCinI5xXBwQtjNZ/A8MfTEJHSC/RCfEtOtZgmoAcXjJ2aLMQRJiqwWmdhqh47zgfUeeWz8/EPcVpjLwR+03eN+vkK+MUApmA4Naydk+xB5Vcw0u2Hf6Z7sexGmVu23+Yg7LgaeRlH5wmmgWQuB4mYoEwaXKKDowVWgX2noUpbUSRkefetkFbwQBKJW0/qjAkTE4PFPv+oTXMR2RM97zJTuKWY0Icu6qPBDckC18q6FHouovLEBbwhrZejYsQiGDs7GNIodHwFL/mqHfAKXC58vncyp/6K1fZ9y3OZShGG4f9W21Kjwfz9uAzYTnTBo6XTZbUqJvqag8LCByno32ri9MXwFwprktHN5R2cdq9cPlQzO2VuuY+IK7yyaQtbuDsvZhQsXUrRnFA6LU2FwL9shHedMALvRR2eJc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54c4c149-85d0-4000-5b17-08d81452eb3d X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 13:16:03.8156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yv6Cqkee5qJaZtvs4OaJCPrQw5CtU2MB6ap/4UODRWX+v4WQhLxquOya7MfK2VVpfgADNOo657HXE7eUtB53nQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2919 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiBTdWJqZWN0OiBSZTogVUVGSSBzdXBwb3J0IGluIEFSTSBEb21Vcw0KPiANCj4gDQo+IE9uIDYv MTkvMjAgMzo1OSBQTSwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gT24g MTkvMDYvMjAyMCAxMzo1MSwgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gd3JvdGU6DQo+ID4+IE9u IDYvMTkvMjAgMzo0NyBQTSwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiA+Pj4gVGhleSB3aWxsIG5v dCBiZSBhdmFpbGFibGUgZnJvbSB0aGUgZmR0LCBidXQgeW91IGNhbiByZXRyaWV2ZSB0aGVtIHdp dGggYW4NCj4gaHlwZXJ2aXNvciBjYWxsIChzZWUgSFZNX1BBUkFNX1NUT1JFX1BGTiwNCj4gSFZN X1BBUkFNX0NPTlNPTEVfUEZOKS4NCj4gPj4gWWVzLCBhbmQgaXQgdXNlZCBpbiB0aGUgcmVsZXZh bnQgcGllY2VzIG9mIGNvZGUgKGh5cCBjYWxscykNCj4gPj4+IE9uZSBxdWVzdGlvbiB0aG91Z2gs IHdoeSBkbyB5b3UgbmVlZCB0byBtYXAgdGhlbSBpbiBhZHZhbmNlPw0KPiBDb3VsZG4ndCB5b3Ug bWFwIHRoZW0gb24gZGVtYW5kPw0KPiA+Pg0KPiA+PiBXZWxsLCB3ZSBuZWVkIHRvIGF0IGxlYXN0 IGVzdGltYXRlIHRoZSBwZ190YWJsZSBzaXplIHNvIHdlIGNhbiByZXNlcnZlIGFuZA0KPiBhbGxv Y2F0ZSBtZW1vcnkgbGF0ZXIsDQo+ID4NCj4gPiBPaCwgc28gVS1ib290IGRvZXNuJ3Qgc3VwcG9y dCBydW50aW1lIHBhZ2UtdGFibGUgdGFibGUgYWxsb2NhdGlvbi4gSXMgdGhhdA0KPiByaWdodD8N Cj4gQXMgcGVyIG15IHVuZGVyc3RhbmRpbmcgbm8sIHdlIHByb3ZpZGUgYSBtZW1vcnkgbWFwIGFu ZCB0aGUgdGFibGVzIGFyZQ0KPiBhbGxvY2F0ZWQgYmVmb3JlaGFuZA0KDQpZb3UgYXJlIHJpZ2h0 Lg0KDQpSZWdhcmRzLA0KUGVuZy4NCj4gPg0KPiA+Pg0KPiA+PiBzbyBJIGhhdmUgdG8gcHJvdmlk ZSBtZW1vcnkgcmFuZ2UgZnJvbSBlaXRoZXIgYnkgY29kaW5nIGEgY29uc3RhbnQgb3INCj4gbG9v a2luZyBpbnRvIHRoZSBkZXZ0cmVlIGF0DQo+ID4+DQo+ID4+IGh5cGVydmlzb3IgeyByZWcgPSA8 PjsgfS4gSXQgaXMgYSBiaXQgdHJpY2t5IHRob3VnaA0KPiA+DQo+ID4gTG9va2luZyBmb3IgYSBu b2RlIGluIHRoZSBkZXZpY2UtdHJlZSBzaG91bGRuJ3QgYmUgdG9vIGRpZmZpY3VsdCBnaXZlbiB0 aGF0IHlvdQ0KPiBoYXZlIGZkdF8qIGF2YWlsYWJsZS4NCj4gPg0KPiA+IEhvd2V2ZXIsIHBsZWFz ZSBub3QgdGhhdCA8cmVnPiBkb2Vzbid0IHJlZmVyIHRvIHRoZSBndWVzdCBtYWdpYyBwYWdlcy4N Cj4gSW5zdGVhZCwgaXQgcHJvdmlkZXMgYSByZWdpb24geW91IGNhbiB1c2UgZm9yIG1hcHBpbmcg dGhlIGdyYW50LXRhYmxlIGZyYW1lcw0KPiANCj4gSW5kZWVkLCB0aGlzIGlzIGluIG15IGNhc2Ug MHgzODAwMDAwMCwgYnV0IHRoZSBtYWdpYyBpcyBhdCAweDM5MDAwMDAwDQo+IA0KPiBTbywgSSBu ZWVkIHRoZSBtZW1vcnkgcmFuZ2Ugc2V0IHVwIGJlZm9yZWhhbmQsIGJ1dCBJIGNhbid0IGFzIHRo ZXJlIGlzIG5vIGN1dGUNCj4gd2F5IHRvIGdldCB0aGF0Lg0KPiANCj4gT2YgY291cnNlLCBJIGNh biBpc3N1ZSBhIGh5cCBjYWxsIHRvIGdldCBIVk1fUEFSQU1fQ09OU09MRV9QRk4gYW5kIHVzZSBp dA0KPiBhcyB0aGUgYmFzZSBhZGRyZXNzLA0KPiANCj4gYnV0IHRoaXMgc21lbGxzIGxpa2UgYSBo YWNrLiBJIGNhbiBjYWxsIG90aGVyIEhWTV9QQVJBTV8gdG8gZ2V0IHRoZWlyIHBmbnMgYW5kDQo+ IHNldCB1cCB0aGUgbWVtb3J5IHJlZ2lvbnMsDQo+IA0KPiBidXQgdGhpcyBsb29rcyBhIGJpdCB3 ZWlyZC4gSSBuZWVkIHRoYXQgY29uc3RhbnQgYmFkbHkgOykNCj4gDQo+ID4NCj4gPiBDaGVlcnMs DQo+ID4NCg== From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:17:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:17:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGtx-0008JG-Jy; Fri, 19 Jun 2020 13:17:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmGtx-0008J7-5J for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:17:49 +0000 X-Inumbo-ID: 45133414-b22f-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 45133414-b22f-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 13:17:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 78971B142; Fri, 19 Jun 2020 13:17:46 +0000 (UTC) Subject: Re: [PATCH v2 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: Grzegorz Uriasz References: From: Jan Beulich Message-ID: Date: Fri, 19 Jun 2020 15:17:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 06:28, Grzegorz Uriasz wrote: > --- a/xen/arch/x86/acpi/boot.c > +++ b/xen/arch/x86/acpi/boot.c > @@ -478,7 +478,9 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > if (fadt->header.revision >= FADT2_REVISION_ID) { > /* FADT rev. 2 */ > if (fadt->xpm_timer_block.space_id == > - ACPI_ADR_SPACE_SYSTEM_IO) { > + ACPI_ADR_SPACE_SYSTEM_IO && > + (fadt->xpm_timer_block.access_width == 0 || > + ACPI_ACCESS_BIT_WIDTH(fadt->xpm_timer_block.access_width) == 32)) { Thinking about it again, since we're already tightening this check, I think we would better also verify bit_offset == 0. There also looks to be an indenting blank missing here. > @@ -490,8 +492,10 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > */ > if (!pmtmr_ioport) { > pmtmr_ioport = fadt->pm_timer_block; > - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0; > + pmtmr_width = fadt->pm_timer_length == 4 ? 32 : 0; > } > + if (pmtmr_width > 24 && !(fadt->flags & ACPI_FADT_32BIT_TIMER)) > + pmtmr_width = 24; > if (pmtmr_ioport) > printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x (%u bits)\n", > pmtmr_ioport, pmtmr_width); I thought we had agreed to log at the very least the case where the FADT flag is set but the width is less than 32 bits. (And I agree that perhaps there's not much more to log, unless we'd suspect e.g. strange access widths to be present somewhere.) > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -457,16 +457,16 @@ static u64 read_pmtimer_count(void) > static s64 __init init_pmtimer(struct platform_timesource *pts) > { > u64 start; > - u32 count, target, mask = 0xffffff; > + u32 count, target, mask; > > - if ( !pmtmr_ioport || !pmtmr_width ) > + if ( !pmtmr_ioport ) > return 0; > > - if ( pmtmr_width == 32 ) > - { > - pts->counter_bits = 32; > - mask = 0xffffffff; > - } > + if ( pmtmr_width != 24 && pmtmr_width != 32 ) > + return 0; > + > + pts->counter_bits = (int) pmtmr_width; > + mask = (1ull << pmtmr_width) - 1; > > count = inl(pmtmr_ioport) & mask; > start = rdtsc_ordered(); > @@ -486,7 +486,6 @@ static struct platform_timesource __initdata plt_pmtimer = > .name = "ACPI PM Timer", > .frequency = ACPI_PM_FREQUENCY, > .read_counter = read_pmtimer_count, > - .counter_bits = 24, > .init = init_pmtimer > }; I'm struggling a little to see why this code churn is needed / wanted. The change I had suggested was quite a bit less intrusive. I'm not entirely opposed though, but at the very least please drop the odd (int) cast. If anything we want the struct field changed to unsigned int (but unlikely in this very patch). If you want to stick to this larger change, then also please fold the two if()s at the beginning of the function. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:26:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:26:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmH2a-0000nj-Es; Fri, 19 Jun 2020 13:26:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmH2Z-0000ne-5k for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:26:43 +0000 X-Inumbo-ID: 830223c4-b230-11ea-bb81-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 830223c4-b230-11ea-bb81-12813bfff9fa; Fri, 19 Jun 2020 13:26:42 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: +5taL90pSMM1Y4K2q2iQcjiklfgmDetB8Q5UeYJus7vndKpTNNbucnXkStBDhwwfi95O5F6JF3 VpF3Z/AEjR2mL9wZtAiKpvSl603BoiVxiyoWZnTvQEXUvbRdoK0Z67WidrgYkoOBcOgmmSkkBc S/gVNp1S4zd6BEeKdt473Sv4lY0/Mrimd1omR/+hOBHw29yC0sY644jzXBmypqO3d4b6ee1XZT 1jJbYDPbjwWvD3WOF/Ph0iEtRNS+Q3YjAgr1a+W55tF3Sg4bumhR/HsVpgVXVOHMvFa9xMzh6l 3nQ= X-SBRS: 2.7 X-MesageID: 20481370 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20481370" Subject: Re: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , "Jan Beulich" References: <20200619115823.22243-1-andrew.cooper3@citrix.com> <1417373854.10164826.1592568614663.JavaMail.zimbra@cert.pl> <893375527.10199950.1592571477991.JavaMail.zimbra@cert.pl> From: Andrew Cooper Message-ID: <0d520017-23b2-9f91-fe5b-160cc46866fa@citrix.com> Date: Fri, 19 Jun 2020 14:26:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <893375527.10199950.1592571477991.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/06/2020 13:57, Michał Leszczyński wrote: > ----- 19 cze 2020 o 14:49, Jan Beulich jbeulich@suse.com napisał(a): > >> On 19.06.2020 14:10, Michał Leszczyński wrote: >>> ----- 19 cze 2020 o 13:58, Andrew Cooper andrew.cooper3@citrix.com napisał(a): >>> >>>> We do not expose the feature to guests, so should disallow access to the >>>> respective MSRs. >>>> >>>> Signed-off-by: Andrew Cooper >>>> --- >>>> CC: Jan Beulich >>>> CC: Wei Liu >>>> CC: Roger Pau Monné >>>> CC: Paul Durrant >>>> CC: Michał Leszczyński >>>> >>>> Paul: For 4.14. This needs backporting to older trees as well. >>>> >>>> Michał: CC'ing, just to keep you in the loop. Xen has some dubious default >>>> MSR semantics which we're still in the middle of untangling in a backwards >>>> compatible way. Patches like this will eventually not be necessary, but they >>>> are for now. >>> >>> As for external IPT monitoring, it would be best if the VM would think >>> that IPT is simply not supported at all by the underlying hypervisor. >> This is already the case, isn't it? Yet not reporting a feature may >> not keep a guest from trying to access the respective MSRs. >> >> Jan > > Okay, understood :) Hiding bits in CPUID doesn't magically make the feature disappear out of the pipeline. Some things we can effectively disable (using suitable intercepts to audit changes to control registers), but for most instruction groups, its trivial to discover if the pipeline supports them, via fault analysis. Despite the software manuals being clear on the matter, not all code checks CPUID properly before poking features.  If anything in your VM does do this, then it is likely to crash on migrate, so wherever possible, block access at all levels, not just in CPUID. (Windows DRM/Anti-cheat systems seem to have a particular knack for finding features we haven't disabled properly, and architectural corner cases we don't cope with correctly.) ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:29:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:29:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmH4p-0000vK-Sd; Fri, 19 Jun 2020 13:29:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmH4o-0000vF-Nl for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:29:02 +0000 X-Inumbo-ID: d6205d3c-b230-11ea-b7bb-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d6205d3c-b230-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 13:29:01 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: pLU/hlGo7Oq7gTSVlXPjoEOWkvHOyHO5R+EV8dws81gr5+18S3Od+/LcaTrmn816kWm3qcD/2R mylw4vFh7kSsLe31EpNVNGACoIi0cfh/mMqhgkyHfOziidCFI70uPYUFfaqBrW9pju84R4BXNP LoVBInbpEhBTsub7dkVF+pAntjxYU6Z412x5N5TYHK+fXDiiDo4koFeK9ij9jFqjT/2JJy8h9Y nxhtw/d0pr62sS3UYbZKaIGvD97eDDXa1q+lZYAHm7VSLdKFim/tNsw+cdBuab0fsWnllqjChK ljc= X-SBRS: 2.7 X-MesageID: 20817032 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20817032" Subject: Re: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs To: Jan Beulich References: <20200619115823.22243-1-andrew.cooper3@citrix.com> <32440578-e346-85cc-abad-1aa5694f0ab2@suse.com> From: Andrew Cooper Message-ID: <855c1668-3f91-c084-70d5-76f3e171f074@citrix.com> Date: Fri, 19 Jun 2020 14:28:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <32440578-e346-85cc-abad-1aa5694f0ab2@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/06/2020 13:48, Jan Beulich wrote: > On 19.06.2020 13:58, Andrew Cooper wrote: >> --- a/xen/arch/x86/msr.c >> +++ b/xen/arch/x86/msr.c >> @@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) >> case MSR_TSX_FORCE_ABORT: >> case MSR_TSX_CTRL: >> case MSR_MCU_OPT_CTRL: >> + case MSR_RTIT_OUTPUT_BASE: >> + case MSR_RTIT_OUTPUT_MASK: >> + case MSR_RTIT_CTL: >> + case MSR_RTIT_STATUS: >> + case MSR_RTIT_CR3_MATCH: >> + case MSR_RTIT_ADDR_A(0) ... MSR_RTIT_ADDR_B(3): > The respective CPUID field is 3 bits wide, so wouldn't it be better > to cover the full possible range (0...6 afaict)? Last time I tried, you objected to me covering MSR ranges which weren't defined. If you want to extend the range like that, it ought to be MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7) to cover the entire area which seems to be exclusively for PT. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:29:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:29:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmH5R-0000zF-5F; Fri, 19 Jun 2020 13:29:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmH5P-0000ya-Pr for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:29:39 +0000 X-Inumbo-ID: e9d72306-b230-11ea-bca7-bc764e2007e4 Received: from mail-ej1-x62b.google.com (unknown [2a00:1450:4864:20::62b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e9d72306-b230-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 13:29:34 +0000 (UTC) Received: by mail-ej1-x62b.google.com with SMTP id y13so10217236eju.2 for ; Fri, 19 Jun 2020 06:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=PaKgpu3SbRk0W/p/Y9wdwsKzeRIqBbye0JpiACweMuA=; b=QV0OKVgs5Gaaf3lUVKLkF4Iok/qgTt0GhjuT1T3W43BheL+EuvPoYXKQnt+G0CIRgg /QUClyiPn7GiJ6vCOWzAhGVjviZ2FvL5LBqNZoUHNtuLnyDilskryFafl7Gdcf0yGcDB BjDBGS9h35SX46pNL0EECtfqCxU3Bo2Q+D9KBSO7b2CCJseVtTVo5T9R0buXp2g/BYkQ i2IQdqRwB9A/kMGGqQ0jfqdlyXzsmiiiY0NktdqujYoObdtN7rkS7hTQVhUbbFDUm9hu P137vV+nt+qmCv1+0y6k3u8pQg8u4HSQZfc3m5mVfY32adqoZx6gWtleLcP6Pxai1PV6 r6nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=PaKgpu3SbRk0W/p/Y9wdwsKzeRIqBbye0JpiACweMuA=; b=LiorRPGYPHuc4msiB5wV0r/A6d1IwT4nIJDtbAB2+BMBgQayNmtkkcAeETVzTFJuiU l9I+4X+CKaE7caId6tEYkVs6jL5vccKF8scPfoUhKI8s/74C152QNXaiPYZLkKWCsGDN SfWZK17Wrq2TFmywHyttVLXK+iUZzL5JkRNCFkVSwFozN0vZAdnUdc95/Xxq53zRd/OE PNmUo9lGdb377hPpJ00v60mnCGyjVseu1/gfHH+vBAbrV8CM80Qlq8gwht4HJTH98CV0 OKi0DbNmrC/vk+1tlxgGvScIncYRF68bphQjUlIF4D1Fu3u+oMqxXG7Wqm/EJ0KsAPEd Tcyg== X-Gm-Message-State: AOAM533HsP7X3nWWdhS65UZO1kmCqgCfSiLH2gNsIH3uOGi/8TpIPxMQ vcGw7nHq/mZVXT+BPWf0FgCPH644fzo= X-Google-Smtp-Source: ABdhPJzeeN6ZLrMsZgQNXTLPMnYiOV9Nr/gzkb453ZogbwZ2nhrdPIOtqYIL1NsXqUhhhfx/NXnvVw== X-Received: by 2002:a17:906:c150:: with SMTP id dp16mr3588367ejc.536.1592573373031; Fri, 19 Jun 2020 06:29:33 -0700 (PDT) Received: from [192.168.10.4] ([185.199.97.5]) by smtp.gmail.com with ESMTPSA id d6sm4788714edn.75.2020.06.19.06.29.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 06:29:32 -0700 (PDT) Subject: Re: UEFI support in ARM DomUs To: Julien Grall , Oleksandr Andrushchenko , Julien Grall , Stefano Stabellini References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> <424cfbdc-0744-fcf7-5bb4-52aca2357df7@epam.com> From: Oleksandr Andrushchenko Message-ID: Date: Fri, 19 Jun 2020 16:29:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/19/20 4:15 PM, Julien Grall wrote: > > > On 19/06/2020 14:06, Oleksandr Andrushchenko wrote: >> >> On 6/19/20 3:59 PM, Julien Grall wrote: >>> Hi, >>> >>> On 19/06/2020 13:51, Oleksandr Andrushchenko wrote: >>>> On 6/19/20 3:47 PM, Julien Grall wrote: >>>>> They will not be available from the fdt, but you can retrieve them with an hypervisor call (see HVM_PARAM_STORE_PFN, HVM_PARAM_CONSOLE_PFN). >>>> Yes, and it used in the relevant pieces of code (hyp calls) >>>>> One question though, why do you need to map them in advance? Couldn't you map them on demand? >>>> >>>> Well, we need to at least estimate the pg_table size so we can reserve and allocate memory later, >>> >>> Oh, so U-boot doesn't support runtime page-table table allocation. Is that right? >> As per my understanding no, we provide a memory map and the tables are allocated beforehand > > Ok :(. > >>> >>>> >>>> so I have to provide memory range from either by coding a constant or looking into the devtree at >>>> >>>> hypervisor { reg = <>; }. It is a bit tricky though >>> >>> Looking for a node in the device-tree shouldn't be too difficult given that you have fdt_* available. >>> >>> However, please not that doesn't refer to the guest magic pages. Instead, it provides a region you can use for mapping the grant-table frames >> >> Indeed, this is in my case 0x38000000, but the magic is at 0x39000000 >> >> So, I need the memory range set up beforehand, but I can't as there is no cute way to get that. >> >> Of course, I can issue a hyp call to get HVM_PARAM_CONSOLE_PFN and use it as the base address, >> >> but this smells like a hack. I can call other HVM_PARAM_ to get their pfns and set up the memory regions, >> >> but this looks a bit weird. > > Why is it weird? In general, you only want to map exactly what you need. Not less, not more. > > In your situation, you only care about two pages, the console page and the xenstore page. The rest shouldn't be mapped. Ok, so I'll try get pfns for HVM_PARAM_CONSOLE_PFN + XENSTORE_PFN_OFFSET via hyp call and map those > >> I need that constant badly ;) > > No you don't ;). > > Cheers, > Thanks for helping with this From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:31:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:31:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmH73-0001lX-HH; Fri, 19 Jun 2020 13:31:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmH73-0001lP-0e for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:31:21 +0000 X-Inumbo-ID: 2902c15c-b231-11ea-bca7-bc764e2007e4 Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2902c15c-b231-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 13:31:20 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id t21so7574833edr.12 for ; Fri, 19 Jun 2020 06:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Oxt1StwaUiC4djXg8ZT3f+J1WnLfc5wAvRyWOgwguKg=; b=Aa7LWdLKXj8wj6UIAaWWeoltjgxQ4Vxm+CIJJUnrcLbpSbFFg7M6nkOzdKoOUKkEap v4TSY6GPJbS/ZvJmuQsNQAjCCq1SCSU+GxrbyiQv1hQt/3fBRf0JbJHVVIzxKHj1ipHI eDFZhI4qPVKZPDsPfMcFkDkfGZh9GPkO7UAhUfE98Yp6NeDiq7T290jawKRUmKwO0vTV FPUCxKnFSDE83RgxaMYJAr16mwTHjpf102O65D0QsWhRQKWqU3vx2sAXCAJVnUkeB+F2 a9/8Za64+/qnY9LmN5wm/a5WkAQoVQyKvMUwloB++XnUUu7f35QHbeKm5MTKmAiMktrq d7nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Oxt1StwaUiC4djXg8ZT3f+J1WnLfc5wAvRyWOgwguKg=; b=LLwvltI5wfHLTyklP+rJ2WEdPau+RdXozFMePzY5S5gO1pTzfSA+Y5y7Ib8JaZdWpN hNxGGJUfMM8LDM6zjLSnUXhNp6R3TIWaFtMqss5Oh4d94EZW4mi+VcrjUPyuUQDvKKmn czeQSVpeJ7CM7a0tqGXo5z1QCM8JChKanlweVs+ZfDsSqx66z+1SFsaZUDnXXbd6B2kQ 9mpegXqXZiRWtEEhD1KVeVKi5pSVRA91y/SRkomBiSwsbyvXl+eMImVMswkD/KKKm8Ze oXRHVrprfLMPHbIOQ5VB31q+RVZS73as1Cmgx4vIp3Cu+oPtTgqdkHBZc4HHL1XHriWc W/7w== X-Gm-Message-State: AOAM531nBqWUIAuaBcd0E7m3mMmBYaM1+7IRGsY35aQb6PSB5Cq7AEoP +U51/dm4RobCofDFgiZ1u1a8bbQfwJM= X-Google-Smtp-Source: ABdhPJzjCN26/UEWXvyN3yxsvsZgg/Ik6GuChNV3fxyvx6YI6AV59C4i7ug+X4uv4RqJxMyA+GHCLg== X-Received: by 2002:a05:6402:3c1:: with SMTP id t1mr3427952edw.350.1592573478628; Fri, 19 Jun 2020 06:31:18 -0700 (PDT) Received: from [192.168.10.4] ([185.199.97.5]) by smtp.gmail.com with ESMTPSA id p26sm4530673eds.57.2020.06.19.06.31.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 06:31:18 -0700 (PDT) Subject: Re: UEFI support in ARM DomUs To: Peng Fan , Oleksandr Andrushchenko , Julien Grall , Julien Grall , Stefano Stabellini References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> <424cfbdc-0744-fcf7-5bb4-52aca2357df7@epam.com> From: Oleksandr Andrushchenko Message-ID: Date: Fri, 19 Jun 2020 16:31:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/19/20 4:16 PM, Peng Fan wrote: >> Subject: Re: UEFI support in ARM DomUs >> >> >> On 6/19/20 3:59 PM, Julien Grall wrote: >>> Hi, >>> >>> On 19/06/2020 13:51, Oleksandr Andrushchenko wrote: >>>> On 6/19/20 3:47 PM, Julien Grall wrote: >>>>> They will not be available from the fdt, but you can retrieve them with an >> hypervisor call (see HVM_PARAM_STORE_PFN, >> HVM_PARAM_CONSOLE_PFN). >>>> Yes, and it used in the relevant pieces of code (hyp calls) >>>>> One question though, why do you need to map them in advance? >> Couldn't you map them on demand? >>>> Well, we need to at least estimate the pg_table size so we can reserve and >> allocate memory later, >>> Oh, so U-boot doesn't support runtime page-table table allocation. Is that >> right? >> As per my understanding no, we provide a memory map and the tables are >> allocated beforehand > You are right. ok, so then we only have a choice of probing the range via hyp calls > Regards, > Peng. >>>> so I have to provide memory range from either by coding a constant or >> looking into the devtree at >>>> hypervisor { reg = <>; }. It is a bit tricky though >>> Looking for a node in the device-tree shouldn't be too difficult given that you >> have fdt_* available. >>> However, please not that doesn't refer to the guest magic pages. >> Instead, it provides a region you can use for mapping the grant-table frames >> >> Indeed, this is in my case 0x38000000, but the magic is at 0x39000000 >> >> So, I need the memory range set up beforehand, but I can't as there is no cute >> way to get that. >> >> Of course, I can issue a hyp call to get HVM_PARAM_CONSOLE_PFN and use it >> as the base address, >> >> but this smells like a hack. I can call other HVM_PARAM_ to get their pfns and >> set up the memory regions, >> >> but this looks a bit weird. I need that constant badly ;) >> >>> Cheers, >>> From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:39:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:39:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHF6-00023j-Ei; Fri, 19 Jun 2020 13:39:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHF4-00023d-Tb for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:39:38 +0000 X-Inumbo-ID: 51b41410-b232-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 51b41410-b232-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 13:39:38 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 71AF6AAF1; Fri, 19 Jun 2020 13:39:36 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs To: Andrew Cooper References: <20200619115823.22243-1-andrew.cooper3@citrix.com> <32440578-e346-85cc-abad-1aa5694f0ab2@suse.com> <855c1668-3f91-c084-70d5-76f3e171f074@citrix.com> From: Jan Beulich Message-ID: Date: Fri, 19 Jun 2020 15:39:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <855c1668-3f91-c084-70d5-76f3e171f074@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 15:28, Andrew Cooper wrote: > On 19/06/2020 13:48, Jan Beulich wrote: >> On 19.06.2020 13:58, Andrew Cooper wrote: >>> --- a/xen/arch/x86/msr.c >>> +++ b/xen/arch/x86/msr.c >>> @@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) >>> case MSR_TSX_FORCE_ABORT: >>> case MSR_TSX_CTRL: >>> case MSR_MCU_OPT_CTRL: >>> + case MSR_RTIT_OUTPUT_BASE: >>> + case MSR_RTIT_OUTPUT_MASK: >>> + case MSR_RTIT_CTL: >>> + case MSR_RTIT_STATUS: >>> + case MSR_RTIT_CR3_MATCH: >>> + case MSR_RTIT_ADDR_A(0) ... MSR_RTIT_ADDR_B(3): >> The respective CPUID field is 3 bits wide, so wouldn't it be better >> to cover the full possible range (0...6 afaict)? > > Last time I tried, you objected to me covering MSR ranges which weren't > defined. Wasn't that for a range where some number had been re-used from earlier models (with entirely different purpose)? > If you want to extend the range like that, it ought to be > MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7) to cover the entire area > which seems to be exclusively for PT. I'd be okay with that, just that I'm not sure about (7): While SDM Vol 2 oddly enough doesn't seem to list anything for leaf 7 subleaf 1 (or I'm sufficiently blind today), Vol 4 clearly says for n=0...3 "If CPUID.(EAX=07H,ECX=1):EAX[2:0] > ", and the field obviously can't be > 7. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 19 13:45:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 13:45:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHKI-0002s2-5y; Fri, 19 Jun 2020 13:45:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHKG-0002rx-LW for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 13:45:00 +0000 X-Inumbo-ID: 117e380c-b233-11ea-bb81-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 117e380c-b233-11ea-bb81-12813bfff9fa; Fri, 19 Jun 2020 13:44:59 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: KCqsDXjhRe6xidaxQhUBWEa+7/hyWKSHLXgGmWKv2u7PUEIfdUZJxINcBRV6PgS8bmtqfUaJVi fGmahqMyCXLslVSlUpfgFLoTHWM8fPrK1vvMiQ7xisRkL2AQ3Ec3KPuYPsaVu021ixaGYqv/7c bsl/biUGzJeJfcVwMxRL6w6cGsfBHnHST6JR71z56ReYz8wmEn6ks9+yulrh3wbh5lGmB4daGh EB4niZ7Zb68WNHYcFHPgTBXiZIcLSV2pcMyJaeKI2KdSmZARHTW/Rg/sMH4HcrQXP/sDngoX1z 6qM= X-SBRS: 2.7 X-MesageID: 20696736 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20696736" Date: Fri, 19 Jun 2020 15:44:52 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v2 3/7] x86/vmx: add IPT cpu feature Message-ID: <20200619134452.GA735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <626789888.9820937.1592523621821.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <626789888.9820937.1592523621821.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , "Kang, Luwei" , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 01:40:21AM +0200, Michał Leszczyński wrote: > Check if Intel Processor Trace feature is supported by current > processor. Define hvm_ipt_supported function. > > Signed-off-by: Michal Leszczynski > --- We usually keep a shirt list of the changes between versions, so it's easier for the reviewers to know what changed. As an example: https://lore.kernel.org/xen-devel/20200613184132.11880-1-julien@xen.org/ > xen/arch/x86/hvm/vmx/vmcs.c | 4 ++++ > xen/include/asm-x86/cpufeature.h | 1 + > xen/include/asm-x86/hvm/hvm.h | 9 +++++++++ > xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + > xen/include/public/arch-x86/cpufeatureset.h | 1 + > 5 files changed, 16 insertions(+) > > diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c > index ca94c2bedc..8466ccb912 100644 > --- a/xen/arch/x86/hvm/vmx/vmcs.c > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > @@ -315,6 +315,10 @@ static int vmx_init_vmcs_config(void) > if ( opt_ept_pml ) > opt |= SECONDARY_EXEC_ENABLE_PML; > > + /* Check whether IPT is supported in VMX operation */ > + hvm_funcs.pt_supported = cpu_has_ipt && > + ( _vmx_misc_cap & VMX_MISC_PT_SUPPORTED ); By the placement of this chunk you are tying IPT support to the secondary exec availability, but I don't think that's required? Ie: You should move the read of misc_cap to the top-level of the function and perform the VMX_MISC_PT_SUPPORTED check there also. Note that space inside parentheses is only required for conditions of 'if', 'for' and those kind of statements, here it's not required, so this should be: hvm_funcs.pt_supported = cpu_has_ipt && (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); I also think this should look like: if ( !smp_processor_id() ) hvm_funcs.pt_supported = cpu_has_ipt && (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); else if ( hvm_funcs.pt_supported && !(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED) ) { printk("VMX: IPT capabilities fatally differ between CPU%u and CPU0\n", smp_processor_id()); return -EINVAL; } So that you can detect mismatches between CPUs. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 14:07:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 14:07:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHfV-0004jT-Ro; Fri, 19 Jun 2020 14:06:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHfU-0004jO-AJ for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 14:06:56 +0000 X-Inumbo-ID: 21941f24-b236-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 21941f24-b236-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 14:06:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3998BADE5; Fri, 19 Jun 2020 14:06:53 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage To: Roger Pau Monne References: <20200618160403.35199-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> Date: Fri, 19 Jun 2020 16:06:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200618160403.35199-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.06.2020 18:04, Roger Pau Monne wrote: > Commit e9aca9470ed86 introduced a regression when avoiding sending > IPIs for certain flush operations. Xen page fault handler > (spurious_page_fault) relies on blocking interrupts in order to > prevent handling TLB flush IPIs and thus preventing other CPUs from > removing page tables pages. Switching to assisted flushing avoided such > IPIs, and thus can result in pages belonging to the page tables being > removed (and possibly re-used) while __page_fault_type is being > executed. > > Force some of the TLB flushes to use IPIs, thus avoiding the assisted > TLB flush. Those selected flushes are the page type change (when > switching from a page table type to a different one, ie: a page that > has been removed as a page table) and page allocation. This sadly has > a negative performance impact on the pvshim, as less assisted flushes > can be used. > > Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush > using an IPI (flush_tlb_mask_sync). Note that the flag is only > meaningfully defined when the hypervisor supports PV mode, as > otherwise translated domains are in charge of their page tables and > won't share page tables with Xen, thus not influencing the result of > page walks performed by the spurious fault handler. Is this true for shadow mode? If a page shadowing a guest one was given back quickly enough to the allocator and then re-used, I think the same situation could in principle arise. > Note the flag is not defined on Arm, and the introduced helper is just > a dummy alias to the existing flush_tlb_mask. > > Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') > Reported-by: Andrew Cooper > Signed-off-by: Roger Pau Monné > --- > It's my understanding that not doing such IPI flushes could lead to > the pages tables being read by __page_fault_type being modified by a > third party, which could make them point to other mfns out of the > scope of the guest allowed physical memory addresses. However those > accesses would be limited to __page_fault_type, and hence the main > worry would be that a guest could make it point to read from a > physical memory region that has side effects? I don't think so, no - the memory could be changed such that the PTEs are invalid altogether (like having reserved bits set). Consider for example the case of reading an MFN out of such a PTE that's larger than the physical address width supported by the CPU. Afaict map_domain_page() will happily install a respective page table entry, but we'd get a reserved-bit #PF upon reading from that mapping. > --- > xen/arch/x86/mm.c | 12 +++++++++++- > xen/common/memory.c | 2 +- > xen/common/page_alloc.c | 2 +- > xen/include/asm-arm/flushtlb.h | 1 + > xen/include/asm-x86/flushtlb.h | 14 ++++++++++++++ > xen/include/xen/mm.h | 8 ++++++-- > 6 files changed, 34 insertions(+), 5 deletions(-) Not finding a consumer of the new flag, my first reaction was to ask whether there's code missing somewhere. Having looked at flush_area_mask() another time I now understand the itended behavior results because of the extra flag now allowing hypervisor_flush_tlb() to be entered. I think that's something that's worth calling out in the description, or perhaps even in the comment next to the #define. > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -2894,7 +2894,17 @@ static int _get_page_type(struct page_info *page, unsigned long type, > ((nx & PGT_type_mask) == PGT_writable_page)) ) > { > perfc_incr(need_flush_tlb_flush); > - flush_tlb_mask(mask); > + if ( (x & PGT_type_mask) && > + (x & PGT_type_mask) <= PGT_l4_page_table ) With there being 5-level page tables around the corner, I think we ought to get used to use PGT_root_page_table (or alike) whenever possible, to avoid having to touch such code when adding support for the new paging mode. > --- a/xen/include/asm-x86/flushtlb.h > +++ b/xen/include/asm-x86/flushtlb.h > @@ -126,6 +126,12 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4); > #else > #define FLUSH_HVM_ASID_CORE 0 > #endif > +#if CONFIG_PV #ifdef > +/* Force an IPI to be sent */ > +# define FLUSH_FORCE_IPI 0x8000 > +#else > +# define FLUSH_FORCE_IPI 0 > +#endif If my shadow mode concern above is unwarranted, this overhead could also be avoided if there's no PV domain at all in the system. Perhaps an improvement not for now, but for the future ... Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 19 14:20:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 14:20:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHsk-0006KX-1X; Fri, 19 Jun 2020 14:20:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHsi-0006KS-Ax for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 14:20:36 +0000 X-Inumbo-ID: 0a0e3e32-b238-11ea-bb8b-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0a0e3e32-b238-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 14:20:35 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1A105A34AB; Fri, 19 Jun 2020 16:20:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 0F97AA34AF; Fri, 19 Jun 2020 16:20:33 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1fY7hZqoS_MI; Fri, 19 Jun 2020 16:20:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 8B662A34AB; Fri, 19 Jun 2020 16:20:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Sw_AqVrLcHbf; Fri, 19 Jun 2020 16:20:32 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 67D29A34A9; Fri, 19 Jun 2020 16:20:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 52EAB225A8; Fri, 19 Jun 2020 16:20:02 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UxnE5D_69fkj; Fri, 19 Jun 2020 16:19:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id DA91822577; Fri, 19 Jun 2020 16:19:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jb21ZM7euPDe; Fri, 19 Jun 2020 16:19:56 +0200 (CEST) Received: from [192.168.70.4] (unknown [195.187.238.48]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 75DCF22542; Fri, 19 Jun 2020 16:19:56 +0200 (CEST) Subject: Re: [PATCH] x86/cpuid: Expose number of vCPUs in CPUID.1.EBX To: Andrew Cooper , xen-devel@lists.xenproject.org References: From: Hubert Jasudowicz Message-ID: <8174d110-be3b-5735-9085-f35f7f0318ab@cert.pl> Date: Fri, 19 Jun 2020 16:19:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/18/20 6:51 PM, Andrew Cooper wrote: > On 18/06/2020 17:22, Hubert Jasudowicz wrote: >> When running under KVM (or presumably other hypervisors) we enable >> the CPUID.1.EDX.HTT flag, thus indicating validity of CPUID.1.EBX[23:1= 6] >> - maximum number of logical processors which the guest reads as 0. >> >> Although this method of topology detection is considered legacy, >> Windows falls back to it when CPUID.0BH.EBX is 0. >> >> CPUID.1.EBX[23:16] being equal to 0, triggers memory corruption in >> ntoskrnl.exe as Windows assumes that number of logical processors woul= d >> be at least 1. Memory corruption manifests itself while mapping >> framebuffer for early graphical subsystem, causing BSOD. >> >> This patch fixes running nested Windows (tested on 7 and 10) with KVM = as >> L0 hypervisor, by setting the value to maximum number of vCPUs in doma= in. >> >> Signed-off-by: Hubert Jasudowicz >=20 > I'm afraid fixing guest topology is more complicated than just this.=C2= =A0 On > its own, I'm not sure if this is safe for VMs migrating in. >=20 > While I agree that Xen's logic is definitely broken, I suspect the > conditions for the BSOD are more complicated than this, because Windows > does work fine when there is no KVM in the setup described. >=20 > ~Andrew >=20 After some more testing, I've managed to boot Windows by explicitly confi= guring the guest with cpuid=3D"host,htt=3D0". If I understand correctly, the default behav= ior is to enable HTT for the guest and basically pass through the value of CPUID.1.= EBX[23:16] without any sanity checks. The reason this works in other setups is that the non-zero value returned= by real hardware leaks into the guest. In my setup, what Xen sees is: CPUID.1h =3D=3D EAX: 000806ea EBX: 00000800 ECX: fffab223 EDX: 0f8bfbff In terms of VM migration, this seems already broken because guest might r= ead different values depending on what underlying hardware reports. The patch would at = least provide some consistency between hosts. Another solution would be not to enable H= TT bit by default. Kind regards, Hubert Jasudowicz From xen-devel-bounces@lists.xenproject.org Fri Jun 19 14:23:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 14:23:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHvB-0006S6-Eq; Fri, 19 Jun 2020 14:23:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmHvA-0006S1-LA for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 14:23:08 +0000 X-Inumbo-ID: 64c99a9c-b238-11ea-bb8d-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 64c99a9c-b238-11ea-bb8d-12813bfff9fa; Fri, 19 Jun 2020 14:23:07 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 60B9DA34AB; Fri, 19 Jun 2020 16:23:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 51A41A34A9; Fri, 19 Jun 2020 16:23:05 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id GIPNdGmJpqXx; Fri, 19 Jun 2020 16:23:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id AD72EA34AB; Fri, 19 Jun 2020 16:23:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2hoFb0Vus2Zp; Fri, 19 Jun 2020 16:23:04 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7ACEAA34A9; Fri, 19 Jun 2020 16:23:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 630E222545; Fri, 19 Jun 2020 16:22:34 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id IMX6U4J8ygIo; Fri, 19 Jun 2020 16:22:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D5D8C225BE; Fri, 19 Jun 2020 16:22:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TClQRQzEUa34; Fri, 19 Jun 2020 16:22:28 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id B288E2252E; Fri, 19 Jun 2020 16:22:28 +0200 (CEST) Date: Fri, 19 Jun 2020 16:22:28 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <445735893.10257958.1592576548575.JavaMail.zimbra@cert.pl> In-Reply-To: <20200619134452.GA735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <626789888.9820937.1592523621821.JavaMail.zimbra@cert.pl> <20200619134452.GA735@Air-de-Roger> Subject: Re: [PATCH v2 3/7] x86/vmx: add IPT cpu feature MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add IPT cpu feature Thread-Index: 1g23H8hkLlU0wPEd8HWtNPXINDQbVQ== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , "Kang, Luwei" , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 15:44, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Fri, Jun 19, 2020 at 01:40:21AM +0200, Micha=C5=82 Leszczy=C5=84ski wr= ote: >> Check if Intel Processor Trace feature is supported by current >> processor. Define hvm_ipt_supported function. >>=20 >> Signed-off-by: Michal Leszczynski >> --- >=20 > We usually keep a shirt list of the changes between versions, so it's > easier for the reviewers to know what changed. As an example: >=20 > https://lore.kernel.org/xen-devel/20200613184132.11880-1-julien@xen.org/ >=20 There is a change list in the cover letter. Should I also add changelog for each individual patch? >> xen/arch/x86/hvm/vmx/vmcs.c | 4 ++++ >> xen/include/asm-x86/cpufeature.h | 1 + >> xen/include/asm-x86/hvm/hvm.h | 9 +++++++++ >> xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + >> xen/include/public/arch-x86/cpufeatureset.h | 1 + >> 5 files changed, 16 insertions(+) >>=20 >> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c >> index ca94c2bedc..8466ccb912 100644 >> --- a/xen/arch/x86/hvm/vmx/vmcs.c >> +++ b/xen/arch/x86/hvm/vmx/vmcs.c >> @@ -315,6 +315,10 @@ static int vmx_init_vmcs_config(void) >> if ( opt_ept_pml ) >> opt |=3D SECONDARY_EXEC_ENABLE_PML; >> =20 >> + /* Check whether IPT is supported in VMX operation */ >> + hvm_funcs.pt_supported =3D cpu_has_ipt && >> + ( _vmx_misc_cap & VMX_MISC_PT_SUPPORTED ); >=20 > By the placement of this chunk you are tying IPT support to the > secondary exec availability, but I don't think that's required? >=20 > Ie: You should move the read of misc_cap to the top-level of the > function and perform the VMX_MISC_PT_SUPPORTED check there also. >=20 > Note that space inside parentheses is only required for conditions of > 'if', 'for' and those kind of statements, here it's not required, so > this should be: >=20 > hvm_funcs.pt_supported =3D cpu_has_ipt && > (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); >=20 > I also think this should look like: >=20 > if ( !smp_processor_id() ) > =09hvm_funcs.pt_supported =3D cpu_has_ipt && > (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); > else if ( hvm_funcs.pt_supported && > !(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED) ) > { > printk("VMX: IPT capabilities fatally differ between CPU%u and CPU= 0\n", > smp_processor_id()); > return -EINVAL; > } >=20 >=20 > So that you can detect mismatches between CPUs. I will fix this. >=20 > Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 15:22:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 15:22:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmIq2-00030b-Q0; Fri, 19 Jun 2020 15:21:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmIq1-00030W-Aj for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 15:21:53 +0000 X-Inumbo-ID: 99b7bb3c-b240-11ea-bb8b-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 99b7bb3c-b240-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 15:21:52 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: g6adGLq1Vf7Jij2RISKfK7bsivmkvhd8TCE6E2E2JdEnOtqdONvSZQHMos6GOnrkdwVWN4x0nL L+VLVHMof2fxOgInQFerd+FpUb/a/OnOeXpWDWz7P8y01L6LcUyVbQgXyC4sO0JiDBFxvEuc5z dXFeaVEoud2YpnUeH5XIxjhS/5vCMeFQEM5kevBnICVDyDcoQJYTEhXYe7Xp+nczXi55lwGoYR HWOfcXy8Frj4WgK6Aoi3g2Ta2bSV9dTQjjU35xtu4ZILXJDTNmzLWcD3MFJHQpWoDOfSbyvvsa O+k= X-SBRS: 2.7 X-MesageID: 20493478 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20493478" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24300.55306.485698.834941@mariner.uk.xensource.com> Date: Fri, 19 Jun 2020 16:21:46 +0100 To: Anthony PERARD Subject: Re: [XEN PATCH for-4.14 1/2] tools: Commit autoconf (2.69) output from Debian buster In-Reply-To: <20200619094110.GA131624@perard.uk.xensource.com> References: <000401d640c9$7b14e760$713eb620$@xen.org> <20200612151931.1083-2-ian.jackson@eu.citrix.com> <20200619094110.GA131624@perard.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , Nick Rosbrook , Wei Liu , Samuel Thibault Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Anthony PERARD writes ("Re: [XEN PATCH for-4.14 1/2] tools: Commit autoconf (2.69) output from Debian buster"): > FIY, this is the output of autoconf from Debian buster, but it isn't the > output of autoconf 2.69. Debian is likely to have patches on top of > the latest autoconf release. 2.69 is apparently 8 years old. Blimey. > Anyway: > Reviewed-by: Anthony PERARD Thanks all. I updated the commit message for this patch slightly in the light of Anthony's comments above and will push both these in a moment. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 15:25:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 15:25:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmIte-0003Be-Fi; Fri, 19 Jun 2020 15:25:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmItd-0003BZ-Bp for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 15:25:37 +0000 X-Inumbo-ID: 1f5fe980-b241-11ea-bba6-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1f5fe980-b241-11ea-bba6-12813bfff9fa; Fri, 19 Jun 2020 15:25:36 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /mSgulF+ycME8TtcnonrGmCH8Byxg2si0Wz7VVPdJ4wvABsGA4c3np5bWsLHKgbSaP70TioZb+ vGIKqeqOQv0zacONna5UKXgUTMd+7+5/Qez50c8WRW0kpy/63v5RmgfSMm8yZi5Bq4qekBuCnl 7BhW1ev5XzXXwk9cCYDm15ZMiSW1y1kbCMqEPVSqnyf/RitR1M8K4GqCHtpriP2vUT8J2gTW/J zLxP4dyoH7TwYxpAPb1v+XRQBnr3o6ynbxkPfVyZ4nHQMzTZ0TLZ8jAXqVkAatuAW0QyWOImk1 Zc0= X-SBRS: 2.7 X-MesageID: 20479828 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20479828" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <24300.55530.451581.376231@mariner.uk.xensource.com> Date: Fri, 19 Jun 2020 16:25:30 +0100 To: Paul Durrant , Patrik =?iso-8859-1?Q?Horn=EDk?= Subject: Re: [PATCH for 4.14] libxl: allow passthrough to PV guests regardless of whether IOMMU is enabled In-Reply-To: <20200619073315.8414-1-paul@xen.org> References: <20200619073315.8414-1-paul@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , "xen-devel@lists.xenproject.org" , Paul Durrant , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Paul Durrant writes ("[PATCH for 4.14] libxl: allow passthrough to PV guests regardless of whether IOMMU is enabled"): > From: Paul Durrant > > Commit babde47a "introduce a 'passthrough' configuration option to xl.cfg..." > added a check to xl_parse.c:parse_config_data() to make sure that an IOMMU > was present and enabled in the system before allowing devices to be passed > through to a guest. This check was then subsequently moved into > libxl_create.c:libxl__domain_config_setdefault() by commit ad011ad0 "libxl/xl: > Overhaul passthrough setting logic". > > Prior to this check being added, it was possible (although not in any way safe > or supported) to pass devices through to a PV guest without an IOMMU being > enabled in the system. This patch relaxes the check for PV guests to restore > that possibility, emitting a warning instead. Thanks. Reviewed-by: Ian Jackson I think this patch could have Reported-by: Patrik Hornk Patrik, if we put your credit in like this it will be permanently recorded in our git history, as part of our code traceability etc. Please let us know what you would prefer. > Signed-off-by: Paul Durrant > --- > Cc: Ian Jackson > Cc: Wei Liu A > Cc: Anthony PERARD > > This patch ought to be in 4.14 as it as very obvious change, restoring lost > functionality that has affected a user. Thanks. I'll take that as a release-ack :-). Also, I will add this tag too when I commit this: Backport: 4.13+ Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 15:30:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 15:30:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmIy6-00043C-8n; Fri, 19 Jun 2020 15:30:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmIy5-000437-Fw for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 15:30:13 +0000 X-Inumbo-ID: c395f878-b241-11ea-b7bb-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c395f878-b241-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 15:30:11 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 9f90II21qK+ghf7yClbc14NQ8KaWgHAf8nxsOQECCPKGd6LjoVJphzKjCip9bxNnGX6rzplLam Hfvsf1q5DtfF5Lfa4LiRPRoScPRFnJ8mg+bgpf8Uk8JbLxl9n/Ujix52fnsZphEdCLmG8c6fSL J6zc8cC4VnXfOsHz7B6HiflL3RBrtB63W+zAB8n61M0D1tAHVTjryeA+KzVfAxgDR8ugoqizKY mYW3foiALHMS9udoqBz2rz+KSsqSdG5gRauMxY1aWyrCWt4kjEPolyIrgEnFgsO8jYG6ohWiqB mHk= X-SBRS: 2.7 X-MesageID: 20782841 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="20782841" Date: Fri, 19 Jun 2020 17:30:03 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op Message-ID: <20200619153003.GB735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 01:41:03AM +0200, Michał Leszczyński wrote: > Provide an interface for privileged domains to manage > external IPT monitoring. Guest IPT state will be preserved > across vmentry/vmexit using ipt_state structure. Thanks! I have some comments below, some of them are cosmetic coding style issues. Sorry the Xen coding style is quite different from other projects, and it takes a bit to get used to. > Signed-off-by: Michal Leszczynski > --- > xen/arch/x86/hvm/hvm.c | 167 +++++++++++++++++++++++++++++ > xen/arch/x86/hvm/vmx/vmx.c | 24 +++++ > xen/arch/x86/mm.c | 37 +++++++ > xen/common/domain.c | 1 + > xen/include/asm-x86/hvm/vmx/vmcs.h | 16 +++ > xen/include/public/hvm/hvm_op.h | 23 ++++ > xen/include/public/hvm/params.h | 5 +- > xen/include/public/memory.h | 1 + > xen/include/xen/sched.h | 3 + > 9 files changed, 276 insertions(+), 1 deletion(-) > > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 5bb47583b3..145ad053d2 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -1612,6 +1612,24 @@ int hvm_vcpu_initialise(struct vcpu *v) > return rc; > } > > +void hvm_vmtrace_destroy(struct vcpu *v) > +{ > + unsigned int i; > + struct page_info *pg; > + struct ipt_state *ipt = v->arch.hvm.vmx.ipt_state; > + mfn_t buf_mfn = ipt->output_base >> PAGE_SHIFT; Does this build? I think you are missing a _mfn(...) here? > + size_t buf_size = ipt->output_mask.size + 1; > + > + xfree(ipt); > + v->arch.hvm.vmx.ipt_state = NULL; > + > + for ( i = 0; i < (buf_size >> PAGE_SHIFT); i++ ) > + { > + pg = mfn_to_page(_mfn(mfn_add(buf_mfn, i))); > + free_domheap_page(pg); There's no need for the loop, just use free_domheap_pages and free the whole allocated area at once. Also you can use maddr_to_page to get the page from output_base. > + } > +} > + > void hvm_vcpu_destroy(struct vcpu *v) > { > viridian_vcpu_deinit(v); > @@ -1631,6 +1649,8 @@ void hvm_vcpu_destroy(struct vcpu *v) > vlapic_destroy(v); > > hvm_vcpu_cacheattr_destroy(v); > + > + hvm_vmtrace_destroy(v); > } > > void hvm_vcpu_down(struct vcpu *v) > @@ -4066,6 +4086,51 @@ static int hvmop_set_evtchn_upcall_vector( > return 0; > } > > +static int hvm_set_vmtrace_pt_size(struct domain *d, uint64_t value) No need for the hvm_ prefix since it's a local function, and then I would name it: vmtrace_alloc_buffers(struct domain *d, uint64_t size) I would name the variable size, so it's purpose it's clearer. > +{ > + void *buf; > + unsigned int buf_order; > + struct page_info *pg; > + struct ipt_state *ipt; > + struct vcpu *v; > + > + if ( value < PAGE_SIZE || > + value > GB(4) || > + ( value & (value - 1) ) ) { Extra spaces, and no need to place each condition on a new line as long as you don't exceed the 80 character limit. Also thee opening brace should be on a newline: if ( value < PAGE_SIZE || value > GB(4) || (value & (value - 1)) ) { > + /* we don't accept trace buffer size smaller than single page > + * and the upper bound is defined as 4GB in the specification */ Comment style is wrong, according to CODING_STYLE this should be: /* * We don't accept trace buffer size smaller than single page * and the upper bound is defined as 4GB in the specification. */ Since you mention the limitations of the buffer size, I would also mention that size must be a power of 2. > + return -EINVAL; > + } > + > + for_each_vcpu ( d, v ) > + { > + buf_order = get_order_from_bytes(value); There's no need for the buf_order variable, just place the call inside alloc_domheap_pages. > + pg = alloc_domheap_pages(d, buf_order, MEMF_no_refcount); You can define the variable here: struct page_info *pg = alloc_domheap_pages(d, get_order_from_bytes(value), MEMF_no_refcount); ipt variable can also be defined here to reduce it's scope. > + > + if ( !pg ) > + return -EFAULT; -ENOMEM > + > + buf = page_to_virt(pg); Why do you need buf? You seem to get the virtual address of the page(s) just to use it in virt_to_mfn, but you can directly use page_to_maddr and remove the buf variable (and the shift done below). > + > + if ( vmx_add_host_load_msr(v, MSR_RTIT_CTL, 0) ) > + return -EFAULT; You leak the pg allocation here... > + > + ipt = xmalloc(struct ipt_state); If you use xzalloc you can avoid setting the fields to 0 below. > + > + if ( !ipt ) > + return -EFAULT; ... and here in the failure paths. This should be -ENOMEM also. > + > + ipt->output_base = virt_to_mfn(buf) << PAGE_SHIFT; > + ipt->output_mask.raw = value - 1; > + ipt->status = 0; > + ipt->active = 0; > + > + v->arch.hvm.vmx.ipt_state = ipt; > + } > + > + return 0; > +} > + > static int hvm_allow_set_param(struct domain *d, > uint32_t index, > uint64_t new_value) > @@ -4127,6 +4192,7 @@ static int hvm_allow_set_param(struct domain *d, > case HVM_PARAM_NR_IOREQ_SERVER_PAGES: > case HVM_PARAM_ALTP2M: > case HVM_PARAM_MCA_CAP: > + case HVM_PARAM_VMTRACE_PT_SIZE: > if ( value != 0 && new_value != value ) > rc = -EEXIST; > break; > @@ -4328,6 +4394,9 @@ static int hvm_set_param(struct domain *d, uint32_t index, uint64_t value) > case HVM_PARAM_MCA_CAP: > rc = vmce_enable_mca_cap(d, value); > break; > + case HVM_PARAM_VMTRACE_PT_SIZE: > + rc = hvm_set_vmtrace_pt_size(d, value); > + break; > } > > if ( !rc ) > @@ -4949,6 +5018,100 @@ static int compat_altp2m_op( > return rc; > } > > +static int do_vmtrace_op(XEN_GUEST_HANDLE_PARAM(void) arg) > +{ > + struct xen_hvm_vmtrace_op a; > + struct domain *d; > + int rc; > + struct vcpu *v; > + struct ipt_state *ipt; > + > + if ( !hvm_pt_supported() ) > + return -EOPNOTSUPP; > + > + if ( copy_from_guest(&a, arg, 1) ) > + return -EFAULT; > + > + if ( a.version != HVMOP_VMTRACE_INTERFACE_VERSION ) > + return -EINVAL; > + > + d = rcu_lock_domain_by_any_id(a.domain); > + spin_lock(&d->vmtrace_lock); This must be moved after you have checked d is not NULL. > + > + if ( d == NULL ) > + return -ESRCH; > + > + if ( !is_hvm_domain(d) ) You don't need to hold vmtrace_lock to check this... > + { > + rc = -EOPNOTSUPP; > + goto out; > + } > + > + domain_pause(d); Do you really need to pause the whole domain, or just the vcpu you are avoid to modify the parameters? Also for HVMOP_vmtrace_ipt_get_offset there's no need to pause anything? > + > + if ( a.vcpu >= d->max_vcpus ) ... neither this. I think you can reduce the locked section a bit. > + { > + rc = -EINVAL; > + goto out; > + } > + > + v = d->vcpu[a.vcpu]; > + ipt = v->arch.hvm.vmx.ipt_state; > + > + if ( !ipt ) > + { > + /* > + * PT must be first initialized upon domain creation. > + */ You have a couple of hard tab in the lines above. Also single line comments are /* ... */. > + rc = -EINVAL; > + goto out; > + } > + > + switch ( a.cmd ) > + { > + case HVMOP_vmtrace_ipt_enable: > + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, > + RTIT_CTL_TRACEEN | RTIT_CTL_OS | > + RTIT_CTL_USR | RTIT_CTL_BRANCH_EN) ) > + { > + rc = -EFAULT; vmx_add_guest_msr already returns a valid error code, please don't replace it with -EFAULT unconditionally (here and below). > + goto out; > + } > + > + ipt->active = 1; > + break; Please add an empty newline after break;. > + case HVMOP_vmtrace_ipt_disable: > + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, 0) ) > + { > + rc = -EFAULT; > + goto out; > + } > + > + ipt->active = 0; > + break; > + case HVMOP_vmtrace_ipt_get_offset: > + a.offset = ipt->output_mask.offset; > + break; > + default: > + rc = -EOPNOTSUPP; > + goto out; > + } > + > + rc = -EFAULT; > + if ( __copy_to_guest(arg, &a, 1) ) > + goto out; > + rc = 0; > + > + out: > + domain_unpause(d); > + spin_unlock(&d->vmtrace_lock); > + rcu_unlock_domain(d); > + > + return rc; > +} > + > +DEFINE_XEN_GUEST_HANDLE(compat_hvm_vmtrace_op_t); > + > static int hvmop_get_mem_type( > XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg) > { > @@ -5101,6 +5264,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) > rc = current->hcall_compat ? compat_altp2m_op(arg) : do_altp2m_op(arg); > break; > > + case HVMOP_vmtrace: > + rc = do_vmtrace_op(arg); > + break; > + > default: > { > gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op); > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index ab19d9424e..51f0046483 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -508,11 +508,25 @@ static void vmx_restore_host_msrs(void) > > static void vmx_save_guest_msrs(struct vcpu *v) > { > + uint64_t rtit_ctl; > + > /* > * We cannot cache SHADOW_GS_BASE while the VCPU runs, as it can > * be updated at any time via SWAPGS, which we cannot trap. > */ > v->arch.hvm.vmx.shadow_gs = rdgsshadow(); > + > + if ( unlikely(v->arch.hvm.vmx.ipt_state && v->arch.hvm.vmx.ipt_state->active) ) > + { > + smp_rmb(); If this barrier is required I think it warrants a comment about why it's needed. > + rdmsrl(MSR_RTIT_CTL, rtit_ctl); > + > + if ( rtit_ctl & RTIT_CTL_TRACEEN ) > + BUG(); BUG_ON(rtit_ctl & RTIT_CTL_TRACEEN); > + > + rdmsrl(MSR_RTIT_STATUS, v->arch.hvm.vmx.ipt_state->status); > + rdmsrl(MSR_RTIT_OUTPUT_MASK, v->arch.hvm.vmx.ipt_state->output_mask.raw); > + } > } > > static void vmx_restore_guest_msrs(struct vcpu *v) > @@ -524,6 +538,16 @@ static void vmx_restore_guest_msrs(struct vcpu *v) > > if ( cpu_has_msr_tsc_aux ) > wrmsr_tsc_aux(v->arch.msrs->tsc_aux); > + > + if ( unlikely(v->arch.hvm.vmx.ipt_state && v->arch.hvm.vmx.ipt_state->active) ) Line is too long. > + { > + wrmsrl(MSR_RTIT_OUTPUT_BASE, > + v->arch.hvm.vmx.ipt_state->output_base); > + wrmsrl(MSR_RTIT_OUTPUT_MASK, > + v->arch.hvm.vmx.ipt_state->output_mask.raw); > + wrmsrl(MSR_RTIT_STATUS, > + v->arch.hvm.vmx.ipt_state->status); Can you please align to the start of the parentheses: wrmsrl(MSR_RTIT_STATUS, v->arch.hvm.vmx.ipt_state->status); > + } > } > > void vmx_update_cpu_exec_control(struct vcpu *v) > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index e376fc7e8f..e4658dc27f 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -4624,6 +4624,43 @@ int arch_acquire_resource(struct domain *d, unsigned int type, > } > break; > } > + > + case XENMEM_resource_vmtrace_buf: > + { > + mfn_t mfn; > + unsigned int i; > + struct ipt_state *ipt; > + > + if ( id >= d->max_vcpus ) > + { > + rc = -EINVAL; You can just set rc = -EINVAL at the top and then avoid setting it on every error case. > + break; > + } > + > + ipt = d->vcpu[id]->arch.hvm.vmx.ipt_state; > + > + if ( !ipt ) > + { > + rc = -EINVAL; > + break; > + } > + > + mfn = mfn_x(ipt->output_base >> PAGE_SHIFT); > + > + if (nr_frames > ( ( ipt->output_mask.size + 1 ) >> PAGE_SHIFT )) Spaces are wrongly positioned. ie: if ( frame + nr_frames > ((ipt->output_mask.size + 1) >> PAGE_SHIFT) ) > + { > + rc = -EINVAL; > + break; > + } > + > + rc = 0; > + for ( i = 0; i < nr_frames; i++ ) I think you should init i to the the 'frame' field from xen_mem_acquire_resource, since it's possible to select the offset you want to map from a resource. You will also need to take it into account, because IMO that's where I would store the last processed frame when dealing with continuations. > + { > + mfn_list[i] = mfn_add(mfn, i); > + } > + > + break; > + } > #endif > > default: > diff --git a/xen/common/domain.c b/xen/common/domain.c > index 7cc9526139..6f6458cd5b 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -414,6 +414,7 @@ struct domain *domain_create(domid_t domid, > d->shutdown_code = SHUTDOWN_CODE_INVALID; > > spin_lock_init(&d->pbuf_lock); > + spin_lock_init(&d->vmtrace_lock); > > rwlock_init(&d->vnuma_rwlock); > > diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h > index 4c81093aba..9fc4653777 100644 > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h > @@ -104,6 +104,19 @@ struct pi_blocking_vcpu { > spinlock_t *lock; > }; > > +struct ipt_state { > + uint64_t active; Could this be a boolean? > + uint64_t status; > + uint64_t output_base; > + union { > + uint64_t raw; > + struct { > + uint32_t size; > + uint32_t offset; > + }; > + } output_mask; > +}; > + > struct vmx_vcpu { > /* Physical address of VMCS. */ > paddr_t vmcs_pa; > @@ -186,6 +199,9 @@ struct vmx_vcpu { > * pCPU and wakeup the related vCPU. > */ > struct pi_blocking_vcpu pi_blocking; > + > + /* State of Intel Processor Trace feature */ > + struct ipt_state *ipt_state; > }; > > int vmx_create_vmcs(struct vcpu *v); > diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h > index 870ec52060..8cd0b6ea49 100644 > --- a/xen/include/public/hvm/hvm_op.h > +++ b/xen/include/public/hvm/hvm_op.h > @@ -382,6 +382,29 @@ struct xen_hvm_altp2m_op { > typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; > DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); > > +/* HVMOP_vmtrace: Perform VM tracing related operation */ > +#define HVMOP_vmtrace 26 > + > +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 > + > +struct xen_hvm_vmtrace_op { > + /* IN variable */ > + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ > + uint32_t cmd; > +/* Enable/disable external vmtrace for given domain */ > +#define HVMOP_vmtrace_ipt_enable 1 > +#define HVMOP_vmtrace_ipt_disable 2 > +#define HVMOP_vmtrace_ipt_get_offset 3 > + domid_t domain; > + uint32_t vcpu; > + uint64_t size; > + > + /* OUT variable */ > + uint64_t offset; > +}; > +typedef struct xen_hvm_vmtrace_op xen_hvm_vmtrace_op_t; > +DEFINE_XEN_GUEST_HANDLE(xen_hvm_vmtrace_op_t); > + > #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */ > > /* > diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h > index 0a91bfa749..adbc7e5d08 100644 > --- a/xen/include/public/hvm/params.h > +++ b/xen/include/public/hvm/params.h > @@ -300,6 +300,9 @@ > #define XEN_HVM_MCA_CAP_LMCE (xen_mk_ullong(1) << 0) > #define XEN_HVM_MCA_CAP_MASK XEN_HVM_MCA_CAP_LMCE > > -#define HVM_NR_PARAMS 39 > +/* VM trace capabilities */ > +#define HVM_PARAM_VMTRACE_PT_SIZE 39 I think it was recommended that IPT should be set at domain creation, but using a HVM param still allows you to init this after the domain has been created. I think it might be best to just add a new field to xen_domctl_createdomain, as it seems like the interface could also be helpful for other arches? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 15:31:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 15:31:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmIzd-00048Y-LJ; Fri, 19 Jun 2020 15:31:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmIzc-00048R-QZ for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 15:31:48 +0000 X-Inumbo-ID: fd121a28-b241-11ea-bb8b-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fd121a28-b241-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 15:31:48 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: +6YHcBZ7jxmtPwZPLygqajhk+pqOKWRDZCpEOKn2tbqHKPKtd1Nl9ZoF0QlaNzpdY9OiSxwFue bJwvw2dYrxFNs/4QmnnhhBeMJqT+XZjD4wxxYPOhjh3FriH2HkmSAewC/hkNFda6d4fHdxLNiH 1ZaxZhqZJYYQ8atK8n+QSSc07CEXpTC2KGNygCDTLCMFyd3pdkdV39GZU5HpBd5Batcx2V8jHU BrelWJmzLtce0gqSUGjt5r9sX1G/BHjqmN+VSIhsfC7eK+dmIDOx+Xx5lR56Km1Ch+FMyHifzK hGg= X-SBRS: 2.7 X-MesageID: 21270335 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,255,1589256000"; d="scan'208";a="21270335" Date: Fri, 19 Jun 2020 17:31:40 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v2 3/7] x86/vmx: add IPT cpu feature Message-ID: <20200619153140.GC735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <626789888.9820937.1592523621821.JavaMail.zimbra@cert.pl> <20200619134452.GA735@Air-de-Roger> <445735893.10257958.1592576548575.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <445735893.10257958.1592576548575.JavaMail.zimbra@cert.pl> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , "Kang, Luwei" , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 04:22:28PM +0200, Michał Leszczyński wrote: > ----- 19 cze 2020 o 15:44, Roger Pau Monné roger.pau@citrix.com napisał(a): > > > On Fri, Jun 19, 2020 at 01:40:21AM +0200, Michał Leszczyński wrote: > >> Check if Intel Processor Trace feature is supported by current > >> processor. Define hvm_ipt_supported function. > >> > >> Signed-off-by: Michal Leszczynski > >> --- > > > > We usually keep a shirt list of the changes between versions, so it's > > easier for the reviewers to know what changed. As an example: > > > > https://lore.kernel.org/xen-devel/20200613184132.11880-1-julien@xen.org/ > > > > There is a change list in the cover letter. Should I also add changelog for > each individual patch? Oh, sorry, completely missed that. IMO yes, it's easier for reviewers because we then have the diff and the changelog at the same place. Changelogs in cover letters are also fine, but I would tend to only add big architectural changes there. Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 15:50:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 15:50:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmJHM-0005qd-7B; Fri, 19 Jun 2020 15:50:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmJHK-0005my-IP for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 15:50:06 +0000 X-Inumbo-ID: 8a7fe60e-b244-11ea-bbaf-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8a7fe60e-b244-11ea-bbaf-12813bfff9fa; Fri, 19 Jun 2020 15:50:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EBF79AD31; Fri, 19 Jun 2020 15:50:01 +0000 (UTC) Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <20200619153003.GB735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Fri, 19 Jun 2020 17:50:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200619153003.GB735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 17:30, Roger Pau Monné wrote: > On Fri, Jun 19, 2020 at 01:41:03AM +0200, Michał Leszczyński wrote: >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -1612,6 +1612,24 @@ int hvm_vcpu_initialise(struct vcpu *v) >> return rc; >> } >> >> +void hvm_vmtrace_destroy(struct vcpu *v) >> +{ >> + unsigned int i; >> + struct page_info *pg; >> + struct ipt_state *ipt = v->arch.hvm.vmx.ipt_state; >> + mfn_t buf_mfn = ipt->output_base >> PAGE_SHIFT; > > Does this build? I think you are missing a _mfn(...) here? This as well as ... >> + size_t buf_size = ipt->output_mask.size + 1; >> + >> + xfree(ipt); >> + v->arch.hvm.vmx.ipt_state = NULL; >> + >> + for ( i = 0; i < (buf_size >> PAGE_SHIFT); i++ ) >> + { >> + pg = mfn_to_page(_mfn(mfn_add(buf_mfn, i))); ... the extra _mfn() here suggest the code was only ever built in release mode so far. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 19 16:41:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 16:41:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmK50-00029F-47; Fri, 19 Jun 2020 16:41:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmK4y-00029A-9Q for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 16:41:24 +0000 X-Inumbo-ID: b51ab1b2-b24b-11ea-b7bb-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b51ab1b2-b24b-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 16:41:22 +0000 (UTC) Received: from webmail.moloch.sk (w3-s.a.lucina.net [62.176.169.73]) by smtp.lucina.net (Postfix) with ESMTPSA id 6F49D122804; Fri, 19 Jun 2020 18:41:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592584881; bh=ZBT3d1lzWFughmSUjt+Pfhm1LcKzzY40X07feeXVQYQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YEFKAPIeZQrrKhxVKabTImMkOs2UrMzLrhNwHG+5MC1yJVRAJW7J7ejxu8g5G0PiX KBjUryeBhCWb5N/npRtW88r77gARJeFsdwcXr18iiiYIS9RwULlmZ7qCaG2WVGmDQh cqqiU/p+FTZr8WbkuhIKEuxigMGBBukLoODIGMU4Joxx94PVPLWM5NDb3tyFFBOeGE o31zJs4bFNcJOLtxxfYNjXexpvoyGeWGL7kaswCXRjNHafUjuedmAI6mgvDyJKK9DK UHe+L3SH1csrJrObmCA+silUKDUpwHq7NG2OcQwvolZ4S1cXTYAbDbP+FVDjEoF02/ q+bw9ReQHAHuw== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 19 Jun 2020 18:41:21 +0200 From: Martin Lucina To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: Event delivery and "domain blocking" on PVHv2 In-Reply-To: <20200619112119.GY735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> Message-ID: X-Sender: martin@lucina.net User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-19 13:21, Roger Pau Monné wrote: > On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote: >> On 2020-06-18 13:46, Roger Pau Monné wrote: >> > On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote: >> > > At this point I don't really have a clear idea of how to progress, >> > > comparing my implementation side-by-side with the original PV >> > > Mini-OS-based >> > > implementation doesn't show up any differences I can see. >> > > >> > > AFAICT the OCaml code I've also not changed in any material way, and >> > > that >> > > has been running in production on PV for years, so I'd be inclined >> > > to think >> > > the problem is in my reimplementation of the C parts, but where...? >> > >> > A good start would be to print the ISR and IRR lapic registers when >> > blocked, to assert there are no pending vectors there. >> > >> > Can you apply the following patch to your Xen, rebuild and check the >> > output of the 'l' debug key? >> > >> > Also add the output of the 'v' key. >> >> Had to fight the Xen Debian packages a bit as I wanted to patch the >> exact >> same Xen (there are some failures when building on a system that has >> Xen >> installed due to following symlinks when fixing shebangs). >> >> Here you go, when stuck during netfront setup, after allocating its >> event >> channel, presumably waiting on Xenstore: >> >> 'e': >> >> (XEN) Event channel information for domain 3: >> (XEN) Polling vCPUs: {} >> (XEN) port [p/m/s] >> (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 >> (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 >> (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 >> (XEN) 4 [0/1/1]: s=2 n=0 x=0 d=0 >> >> 'l': >> >> (XEN) d3v0 IRR: >> ffff8301732dc200b >> (XEN) d3v0 ISR: >> ffff8301732dc100b > > Which version of Xen is this? AFAICT it doesn't have the support to > print a bitmap. That in Debian 10 (stable): ii xen-hypervisor-4.11-amd64 4.11.3+24-g14b62ab3e5-1~deb10u1.2 amd64 Xen Hypervisor on AMD64 xen_major : 4 xen_minor : 11 xen_extra : .4-pre xen_version : 4.11.4-pre > > Do you think you could also pick commit > 8cd9500958d818e3deabdd0d4164ea6fe1623d7c [0] and rebuild? (and print > the info again). Done, here you go: (XEN) Event channel information for domain 3: (XEN) Polling vCPUs: {} (XEN) port [p/m/s] (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 (XEN) 4 [0/1/1]: s=3 n=0 x=0 d=0 p=35 (XEN) d3v0 IRR: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 (XEN) d3v0 ISR: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 (XEN) *********** VMCS Areas ************** (XEN) (XEN) >>> Domain 3 <<< (XEN) VCPU 0 (XEN) *** Guest State *** (XEN) CR0: actual=0x0000000080000033, shadow=0x0000000080000033, gh_mask=ffffffffffffffff (XEN) CR4: actual=0x0000000000002660, shadow=0x0000000000000020, gh_mask=ffffffffffc8f860 (XEN) CR3 = 0x00000000002e9000 (XEN) RSP = 0x000000000ffffec0 (0x000000000ffffec0) RIP = 0x0000000000209997 (0x0000000000209998) (XEN) RFLAGS=0x00000297 (0x00000297) DR7 = 0x0000000000000400 (XEN) Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000 (XEN) sel attr limit base (XEN) CS: 0008 0a099 ffffffff 0000000000000000 (XEN) DS: 0010 0c093 ffffffff 0000000000000000 (XEN) SS: 0010 0c093 ffffffff 0000000000000000 (XEN) ES: 0010 0c093 ffffffff 0000000000000000 (XEN) FS: 0000 1c000 ffffffff 0000000000000000 (XEN) GS: 0000 1c000 ffffffff 0000000000000000 (XEN) GDTR: 00000027 00000000003e13c0 (XEN) LDTR: 0000 10000 00000000 0000000000000000 (XEN) IDTR: 000002ff 00000000003e10a8 (XEN) TR: 0018 0008b 00000068 00000000003e1040 (XEN) EFER = 0x0000000000000000 PAT = 0x0007040600070406 (XEN) PreemptionTimer = 0x00000000 SM Base = 0x00000000 (XEN) DebugCtl = 0x0000000000000000 DebugExceptions = 0x0000000000000000 (XEN) Interruptibility = 00000000 ActivityState = 00000000 (XEN) *** Host State *** (XEN) RIP = 0xffff82d08031df40 (vmx_asm_vmexit_handler) RSP = 0xffff83009c057f70 (XEN) CS=e008 SS=0000 DS=0000 ES=0000 FS=0000 GS=0000 TR=e040 (XEN) FSBase=0000000000000000 GSBase=0000000000000000 TRBase=ffff82d08055e000 (XEN) GDTBase=ffff82d08042f000 IDTBase=ffff82d080559000 (XEN) CR0=0000000080050033 CR3=0000000171d9b000 CR4=00000000003526e0 (XEN) Sysenter RSP=ffff83009c057fa0 CS:RIP=e008:ffff82d0803664b0 (XEN) EFER = 0x0000000000000000 PAT = 0x0000050100070406 (XEN) *** Control State *** (XEN) PinBased=0000003f CPUBased=b6a065fa SecondaryExec=000014eb (XEN) EntryControls=000053ff ExitControls=000fefff (XEN) ExceptionBitmap=00060002 PFECmask=00000000 PFECmatch=00000000 (XEN) VMEntry: intr_info=00000020 errcode=00000000 ilen=00000000 (XEN) VMExit: intr_info=00000000 errcode=00000000 ilen=00000001 (XEN) reason=0000000c qualification=0000000000000000 (XEN) IDTVectoring: info=00000000 errcode=00000000 (XEN) TSC Offset = 0xffffffd2984c98e6 TSC Multiplier = 0x0000000000000000 (XEN) TPR Threshold = 0x00 PostedIntrVec = 0x00 (XEN) EPT pointer = 0x000000016e5ac01e EPTP index = 0x0000 (XEN) PLE Gap=00000080 Window=00001000 (XEN) Virtual processor ID = 0x000e VMfunc controls = 0000000000000000 (XEN) ************************************** Martin > > Thanks, Roger. > > [0] > http://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=8cd9500958d818e3deabdd0d4164ea6fe1623d7c From xen-devel-bounces@lists.xenproject.org Fri Jun 19 16:46:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 16:46:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmK9t-0002Ox-39; Fri, 19 Jun 2020 16:46:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmK9s-0002OM-Kx for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 16:46:28 +0000 X-Inumbo-ID: 6835d63c-b24c-11ea-bb8b-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6835d63c-b24c-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 16:46:23 +0000 (UTC) Received: from webmail.moloch.sk (w3-s.a.lucina.net [62.176.169.73]) by smtp.lucina.net (Postfix) with ESMTPSA id 0E521122804; Fri, 19 Jun 2020 18:46:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592585182; bh=oAGUPnrn4Qyr0dXzpsV9TWyYeXe15zTyF+cf1o6lts0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mWEOVhcL6UHDibFbWtvYEO8ki/QNwXfxWJZV7HgRAw0kerywsa3ieRyu7m0ekcRGQ WVb5/9Sg6WopcXdclVeyVAl0pbdZSKs4Z2A93DW3lgFg0bf1xxv/ox1drRuXLYit2S 8uztEoM8mGWOAX/8CzwivdCyVNR5hWPhFjr1FBkQEo9J1y0QcdFAzeio6DmO901ps8 ciCHkgJvVCAui/riDLanE9Elyv6pLURJpHQIJ5sW+gy1sVEcdFhyW2zHWBITQTKKVG fH9H9KpjKFvDWwu1Ozs1F0k8XTxJsVs4qeZ2vIihqmNPwn5Io3WHzH2CM9/EzXmXHX GW+5O/4cg94gg== MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Jun 2020 18:46:22 +0200 From: Martin Lucina To: Andrew Cooper Subject: Re: Event delivery and "domain blocking" on PVHv2 In-Reply-To: <0ebf1417-49e5-d9b2-81b0-b02c7e6cf833@citrix.com> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <0ebf1417-49e5-d9b2-81b0-b02c7e6cf833@citrix.com> Message-ID: <89c4e6e5bc1b986989e549a467eed439@lucina.net> X-Sender: martin@lucina.net User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-19 13:21, Andrew Cooper wrote: > On 19/06/2020 11:28, Martin Lucina wrote: >> RIP 0x209997 is the 'hlt' instruction in >> mirage_xen_evtchn_block_domain() so we are indeed blocking waiting for >> events to show up. > > I can't find this in the code, but it might be an x86-ism you're > falling > over here. Solo5 only contains the lowest-level bits, and only then those parts that "fit" the responsibility of that layer. The rest is here (WIP, not cleaned up yet): https://github.com/mato/mirage-xen/tree/xen-pvh-via-solo5 The event channel code, including the function that blocks the domain, is in lib/bindings/evtchn_stubs.c. > > Its not safe to use hlt with interrupts enabled, unless it is exactly > `sti; hlt` where the STI instruction transitions the interrupt flag > from > clear to set (i.e. you had interrupts disabled beforehand). > > Otherwise you can take the interrupt intended to wake you on the before > the hlt is executed. Hmm, so what is the right thing to do when blocking on PVHv2 in this scenario? Just use SCHEDOP_block? "cli; sti; hlt"? (Tried the latter, doesn't help). Martin From xen-devel-bounces@lists.xenproject.org Fri Jun 19 16:54:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 16:54:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmKHr-0003Hn-0Y; Fri, 19 Jun 2020 16:54:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmKHp-0003HJ-Mu for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 16:54:41 +0000 X-Inumbo-ID: 8d3fba32-b24d-11ea-bbbd-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8d3fba32-b24d-11ea-bbbd-12813bfff9fa; Fri, 19 Jun 2020 16:54:34 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: J4TTlQT1ID5jKu5v1esKXrwor2/zAp+QL4MzFP8/Stzr6ep8JzIq6TBWC+2B+1wu//P/e5inS4 Mn+DHxXvKIzOl357XnfHqoDs0xpYy0xl5mx3Qzfp4Y2nJCSwldpSHki+p2eq7mkHJ1b861/8/I GyMOC9YGppDuxYiIY4JPgX7QbJeksDSYAaHK046KnsDVsZCVQVBLjNXD9JApWmG51ra658sgN6 Zurgw2NkuBv/NTad0SpeRA77u6mgdvgfkLmAzs9QpfMXKvk2Mt7j2xXW0PNB1w0LeFWck5Li3s tyI= X-SBRS: 2.7 X-MesageID: 20791138 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,256,1589256000"; d="scan'208";a="20791138" Date: Fri, 19 Jun 2020 18:54:26 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Martin Lucina Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200619165426.GD735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 06:41:21PM +0200, Martin Lucina wrote: > On 2020-06-19 13:21, Roger Pau Monné wrote: > > On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote: > > > On 2020-06-18 13:46, Roger Pau Monné wrote: > > > > On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote: > > > > > At this point I don't really have a clear idea of how to progress, > > > > > comparing my implementation side-by-side with the original PV > > > > > Mini-OS-based > > > > > implementation doesn't show up any differences I can see. > > > > > > > > > > AFAICT the OCaml code I've also not changed in any material way, and > > > > > that > > > > > has been running in production on PV for years, so I'd be inclined > > > > > to think > > > > > the problem is in my reimplementation of the C parts, but where...? > > > > > > > > A good start would be to print the ISR and IRR lapic registers when > > > > blocked, to assert there are no pending vectors there. > > > > > > > > Can you apply the following patch to your Xen, rebuild and check the > > > > output of the 'l' debug key? > > > > > > > > Also add the output of the 'v' key. > > > > > > Had to fight the Xen Debian packages a bit as I wanted to patch the > > > exact > > > same Xen (there are some failures when building on a system that has > > > Xen > > > installed due to following symlinks when fixing shebangs). > > > > > > Here you go, when stuck during netfront setup, after allocating its > > > event > > > channel, presumably waiting on Xenstore: > > > > > > 'e': > > > > > > (XEN) Event channel information for domain 3: > > > (XEN) Polling vCPUs: {} > > > (XEN) port [p/m/s] > > > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 > > > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > > > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 > > > (XEN) 4 [0/1/1]: s=2 n=0 x=0 d=0 > > > > > > 'l': > > > > > > (XEN) d3v0 IRR: > > > ffff8301732dc200b > > > (XEN) d3v0 ISR: > > > ffff8301732dc100b > > > > Which version of Xen is this? AFAICT it doesn't have the support to > > print a bitmap. > > That in Debian 10 (stable): > > ii xen-hypervisor-4.11-amd64 4.11.3+24-g14b62ab3e5-1~deb10u1.2 > amd64 Xen Hypervisor on AMD64 > > xen_major : 4 > xen_minor : 11 > xen_extra : .4-pre > xen_version : 4.11.4-pre > > > > > Do you think you could also pick commit > > 8cd9500958d818e3deabdd0d4164ea6fe1623d7c [0] and rebuild? (and print > > the info again). > > Done, here you go: > > (XEN) Event channel information for domain 3: > (XEN) Polling vCPUs: {} > (XEN) port [p/m/s] > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 > (XEN) 4 [0/1/1]: s=3 n=0 x=0 d=0 p=35 > > > (XEN) d3v0 IRR: > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > (XEN) d3v0 ISR: > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 So there's nothing pending on the lapic. Can you assert that you will always execute evtchn_demux_pending after you have received an event channel interrupt (ie: executed solo5__xen_evtchn_vector_handler)? I think this would be simpler if you moved evtchn_demux_pending into solo5__xen_evtchn_vector_handler? As there would be less asynchronous processing, and thus likely less races? Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 17:15:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 17:15:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmKbm-00055t-Nk; Fri, 19 Jun 2020 17:15:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmKbl-00055o-J1 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 17:15:17 +0000 X-Inumbo-ID: 71b91404-b250-11ea-bbc2-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 71b91404-b250-11ea-bbc2-12813bfff9fa; Fri, 19 Jun 2020 17:15:16 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C920B20757; Fri, 19 Jun 2020 17:15:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592586916; bh=cqrOmi0QLWtV24IgR/WAUNmM6ppN3/hW917OU1uM3ZY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=GMqtRlsdS+sWl/wd7cGocuwPut9kC8EExQTOf2+RsBxtvBMbKYpgsV8rkCF0L78rv wszWBJxZAupnkTBcd556zaeO0xsYPH+6u90IwHrpJoYuEsnGuMQNFQd3fdXptQqhyq KYsK+p9DyXXoG4Tjo9WyFmpfGvjH6I5pr2rwjGkk= Date: Fri, 19 Jun 2020 10:15:09 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address In-Reply-To: Message-ID: References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> <878sgk2bst.fsf@epam.com> <8d2f3475-4191-fa80-f476-e72af73e0559@xen.org> <87h7v71ixf.fsf@epam.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "sstabellini@kernel.org" , Volodymyr Babchuk , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 19 Jun 2020, Julien Grall wrote: > Hi Volodymyr, > > On 19/06/2020 10:52, Volodymyr Babchuk wrote: > > > > > > OP-TEE represents this null memory reference as a TMEM parameter > > > > > > with > > > > > > buf_ptr == NULL. This is the only case when we should allow TMEM > > > > > > buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. > > > > > > > > > > IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer > > > > > at address 0" but with the flag cleared, it would mean "return the > > > > > size". Am I correct? > > > > > > > > Not exactly. This flag does not affect behavior for buffers with address > > > > NULL. In any case, this would not mean "return the size" to > > > > OP-TEE. This is because OP-TEE works as a transport between CA and TA > > > > and it does not assign any meaning to client buffers. But certainly, > > > > null buffer will mean "return the size" for some TAs, as described in > > > > GlobalPlatform specification. > > > > > > Does it mean a guest TA may potentially access address 0? > > > > TA is running in S-EL0. That buffer with PA=0x0 will be not mapped in TA > > address space at all. So, if TA will try to access address 0, it > > will be terminated with data abort. > > > > > I am asking that because 0 can be a valid host physical address. We > > > are currently carving out 0 from the heap allocator to workaround a > > > bug, but there is no promise this address will be used by the boot > > > allocator and therefore Xen. > > > > > > > Well, this is a potential issue in OP-TEE. It does not treat 0 as a > > valid address. So, in that rare case, when REE will try to use 0 > > as a correct address for data buffer, OP-TEE will not map it into > > TA address space, instead it will pass NULL to TA, so TA will think that > > no buffer was provided. > > Thanks! That's reassuring. Although, I think we may still need to prevent MFN > 0 to be allocated for a guest using OP-TEE. So they don't end up with weird > failure. > > I don't think this is an issue so far, but this may change with Stefano's > dom0less series to support direct mapping. Yes, it is interesting to know about this limitation. In regards to this patch, it looks OK as-is in terms of code changes. Aside from a link to this conversation in the xen-devel archives, is there anything else you would like to add to the commit message? From xen-devel-bounces@lists.xenproject.org Fri Jun 19 17:40:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 17:40:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmKzp-0007YC-Ow; Fri, 19 Jun 2020 17:40:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmKzn-0007Y7-Nb for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 17:40:07 +0000 X-Inumbo-ID: ea2f1f20-b253-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ea2f1f20-b253-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 17:40:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZrZqR1Z8AbU/p89/Cc25kexNMNuZkwc/7uqbQfIjJ7E=; b=092tmZ5yLAGMSzlR8XWbj86G3C DLPjzB3Z6ItU0QN9Z10b3g9ucgFk9+PtH0TD1UlqaodN8NEFfFIM4xISelmJ4N6HXnS8JrvrW3o5x 0m3q0rX0//YAdF+wAZ3E1tNAiY1+WBqsWkcDairvzAmXIBrYkM8+DjO90YctMifKpBwo=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmKzm-0004ZC-Fp; Fri, 19 Jun 2020 17:40:06 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jmKzm-0003nH-90; Fri, 19 Jun 2020 17:40:06 +0000 Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address To: Stefano Stabellini References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> <878sgk2bst.fsf@epam.com> <8d2f3475-4191-fa80-f476-e72af73e0559@xen.org> <87h7v71ixf.fsf@epam.com> From: Julien Grall Message-ID: Date: Fri, 19 Jun 2020 18:40:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Volodymyr Babchuk , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/06/2020 18:15, Stefano Stabellini wrote: > On Fri, 19 Jun 2020, Julien Grall wrote: >> Hi Volodymyr, >> >> On 19/06/2020 10:52, Volodymyr Babchuk wrote: >>>>>>> OP-TEE represents this null memory reference as a TMEM parameter >>>>>>> with >>>>>>> buf_ptr == NULL. This is the only case when we should allow TMEM >>>>>>> buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. >>>>>> >>>>>> IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the buffer >>>>>> at address 0" but with the flag cleared, it would mean "return the >>>>>> size". Am I correct? >>>>> >>>>> Not exactly. This flag does not affect behavior for buffers with address >>>>> NULL. In any case, this would not mean "return the size" to >>>>> OP-TEE. This is because OP-TEE works as a transport between CA and TA >>>>> and it does not assign any meaning to client buffers. But certainly, >>>>> null buffer will mean "return the size" for some TAs, as described in >>>>> GlobalPlatform specification. >>>> >>>> Does it mean a guest TA may potentially access address 0? >>> >>> TA is running in S-EL0. That buffer with PA=0x0 will be not mapped in TA >>> address space at all. So, if TA will try to access address 0, it >>> will be terminated with data abort. >>> >>>> I am asking that because 0 can be a valid host physical address. We >>>> are currently carving out 0 from the heap allocator to workaround a >>>> bug, but there is no promise this address will be used by the boot >>>> allocator and therefore Xen. >>>> >>> >>> Well, this is a potential issue in OP-TEE. It does not treat 0 as a >>> valid address. So, in that rare case, when REE will try to use 0 >>> as a correct address for data buffer, OP-TEE will not map it into >>> TA address space, instead it will pass NULL to TA, so TA will think that >>> no buffer was provided. >> >> Thanks! That's reassuring. Although, I think we may still need to prevent MFN >> 0 to be allocated for a guest using OP-TEE. So they don't end up with weird >> failure. >> >> I don't think this is an issue so far, but this may change with Stefano's >> dom0less series to support direct mapping. > > Yes, it is interesting to know about this limitation. > > In regards to this patch, it looks OK as-is in terms of code changes. I would disagree here. NULL has never been handled correctly for TMEM buffers (see [1]). I would argue this needs to be folded within this patch rather than be a separate one. > Aside from a link to this conversation in the xen-devel archives, is > there anything else you would like to add to the commit message? +1 for the link. However, I don't think the commit message fully match/summarize the discussion here. What needs to be clearly spell out is that existing OP-TEEs will never map MFN 0. Cheers, [1] <87h7v71ixf.fsf@epam.com> -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 19 17:42:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 17:42:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmL23-0007fE-6r; Fri, 19 Jun 2020 17:42:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmL22-0007ev-F3 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 17:42:26 +0000 X-Inumbo-ID: 39954076-b254-11ea-bbd2-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 39954076-b254-11ea-bbd2-12813bfff9fa; Fri, 19 Jun 2020 17:42:20 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: HM6kqYKEN36aCLijVPw3284hmcR2Na5SOQ+OAAXLJbsd9Nic+H94ffrxC5fn7opoNSiRrdq/cN rNob5PWveZm6aYImuegajhC2XkEK8nXcubPXaXLxbbTVRKDWjnZR7STIHIsAA+ZP3trP92Qj56 XHb7l8yy4YgO8pU1HNK/B1WGA5KUdaA1w0cvOGjCeH4qJV9BuyQn/rDHmdDSCFjPMpxvl9bU/t tfNrxGJvBLVAe9UGKCZTEWKfcpgwRp9SIXe6Uw47C3jc+GFuNW9R1LaSSG5aQ0pOwPMrgfY2aM 8uQ= X-SBRS: 2.7 X-MesageID: 21282996 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,256,1589256000"; d="scan'208";a="21282996" Date: Fri, 19 Jun 2020 19:42:13 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Martin Lucina Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200619174143.GE735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> <20200619165426.GD735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200619165426.GD735@Air-de-Roger> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 06:54:26PM +0200, Roger Pau Monné wrote: > On Fri, Jun 19, 2020 at 06:41:21PM +0200, Martin Lucina wrote: > > On 2020-06-19 13:21, Roger Pau Monné wrote: > > > On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote: > > > > On 2020-06-18 13:46, Roger Pau Monné wrote: > > > > > On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote: > > > > > > At this point I don't really have a clear idea of how to progress, > > > > > > comparing my implementation side-by-side with the original PV > > > > > > Mini-OS-based > > > > > > implementation doesn't show up any differences I can see. > > > > > > > > > > > > AFAICT the OCaml code I've also not changed in any material way, and > > > > > > that > > > > > > has been running in production on PV for years, so I'd be inclined > > > > > > to think > > > > > > the problem is in my reimplementation of the C parts, but where...? > > > > > > > > > > A good start would be to print the ISR and IRR lapic registers when > > > > > blocked, to assert there are no pending vectors there. > > > > > > > > > > Can you apply the following patch to your Xen, rebuild and check the > > > > > output of the 'l' debug key? > > > > > > > > > > Also add the output of the 'v' key. > > > > > > > > Had to fight the Xen Debian packages a bit as I wanted to patch the > > > > exact > > > > same Xen (there are some failures when building on a system that has > > > > Xen > > > > installed due to following symlinks when fixing shebangs). > > > > > > > > Here you go, when stuck during netfront setup, after allocating its > > > > event > > > > channel, presumably waiting on Xenstore: > > > > > > > > 'e': > > > > > > > > (XEN) Event channel information for domain 3: > > > > (XEN) Polling vCPUs: {} > > > > (XEN) port [p/m/s] > > > > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 > > > > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > > > > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 > > > > (XEN) 4 [0/1/1]: s=2 n=0 x=0 d=0 > > > > > > > > 'l': > > > > > > > > (XEN) d3v0 IRR: > > > > ffff8301732dc200b > > > > (XEN) d3v0 ISR: > > > > ffff8301732dc100b > > > > > > Which version of Xen is this? AFAICT it doesn't have the support to > > > print a bitmap. > > > > That in Debian 10 (stable): > > > > ii xen-hypervisor-4.11-amd64 4.11.3+24-g14b62ab3e5-1~deb10u1.2 > > amd64 Xen Hypervisor on AMD64 > > > > xen_major : 4 > > xen_minor : 11 > > xen_extra : .4-pre > > xen_version : 4.11.4-pre > > > > > > > > Do you think you could also pick commit > > > 8cd9500958d818e3deabdd0d4164ea6fe1623d7c [0] and rebuild? (and print > > > the info again). > > > > Done, here you go: > > > > (XEN) Event channel information for domain 3: > > (XEN) Polling vCPUs: {} > > (XEN) port [p/m/s] > > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 > > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 > > (XEN) 4 [0/1/1]: s=3 n=0 x=0 d=0 p=35 > > > > > > (XEN) d3v0 IRR: > > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > > (XEN) d3v0 ISR: > > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > > So there's nothing pending on the lapic. Can you assert that you will > always execute evtchn_demux_pending after you have received an event > channel interrupt (ie: executed solo5__xen_evtchn_vector_handler)? > > I think this would be simpler if you moved evtchn_demux_pending into > solo5__xen_evtchn_vector_handler? As there would be less asynchronous > processing, and thus likely less races? Having though about this, I think this model of not demuxing in solo5__xen_evtchn_vector_handler is always racy, as it's not possible to assert that you would always call evtchn_demux_pending after solo5__xen_evtchn_vector_handler? Ie: if you receive an interrupt just before going to sleep (after the sti and before the hlt) you will execute solo5__xen_evtchn_vector_handler and EOI the vector, but then evtchn_demux_pending will never get called, and thus the interrupts will stay indefinitely pending? Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 19 18:04:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 18:04:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmLNQ-00017h-2M; Fri, 19 Jun 2020 18:04:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmLNP-00017c-4Z for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 18:04:31 +0000 X-Inumbo-ID: 51e3471b-b257-11ea-bbdb-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 51e3471b-b257-11ea-bbdb-12813bfff9fa; Fri, 19 Jun 2020 18:04:30 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1CA2E20DD4; Fri, 19 Jun 2020 18:04:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592589869; bh=9U29+BVl1swW9146VN/4P8eJUSjGnGmPDxuGpmJAwn4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=wsJfZ2CZWiF2NBGJ6InL8H0prHLWWBwKcuIk4gxNAM4AHD7aPPNxqLljqGgZr49oh /UDQucoBDhr/RqBLzcKn9/mtJa1ttxbZiufVVeNonXm9GKXkallzOSkhX42atnl4OI 8b+6yvE5TkApoFQmFwKpT5qbcQSkuNp55uBqd4Bk= Date: Fri, 19 Jun 2020 11:04:28 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH] xen/arm: optee: allow plain TMEM buffers with NULL address In-Reply-To: Message-ID: References: <2a32c7c2048333169c9378194d6a435e2e7ed2d7.camel@epam.com> <1b596a11-95b5-3e87-bbf5-c0c4dceb6489@xen.org> <878sgk2bst.fsf@epam.com> <8d2f3475-4191-fa80-f476-e72af73e0559@xen.org> <87h7v71ixf.fsf@epam.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Stefano Stabellini , Volodymyr Babchuk , "paul@xen.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 19 Jun 2020, Julien Grall wrote: > On 19/06/2020 18:15, Stefano Stabellini wrote: > > On Fri, 19 Jun 2020, Julien Grall wrote: > > > Hi Volodymyr, > > > > > > On 19/06/2020 10:52, Volodymyr Babchuk wrote: > > > > > > > > OP-TEE represents this null memory reference as a TMEM parameter > > > > > > > > with > > > > > > > > buf_ptr == NULL. This is the only case when we should allow TMEM > > > > > > > > buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. > > > > > > > > > > > > > > IIUC, 0 with OPTEE_MSG_ATTR_NONCONTIG set would mean "use the > > > > > > > buffer > > > > > > > at address 0" but with the flag cleared, it would mean "return the > > > > > > > size". Am I correct? > > > > > > > > > > > > Not exactly. This flag does not affect behavior for buffers with > > > > > > address > > > > > > NULL. In any case, this would not mean "return the size" to > > > > > > OP-TEE. This is because OP-TEE works as a transport between CA and > > > > > > TA > > > > > > and it does not assign any meaning to client buffers. But certainly, > > > > > > null buffer will mean "return the size" for some TAs, as described > > > > > > in > > > > > > GlobalPlatform specification. > > > > > > > > > > Does it mean a guest TA may potentially access address 0? > > > > > > > > TA is running in S-EL0. That buffer with PA=0x0 will be not mapped in TA > > > > address space at all. So, if TA will try to access address 0, it > > > > will be terminated with data abort. > > > > > > > > > I am asking that because 0 can be a valid host physical address. We > > > > > are currently carving out 0 from the heap allocator to workaround a > > > > > bug, but there is no promise this address will be used by the boot > > > > > allocator and therefore Xen. > > > > > > > > > > > > > Well, this is a potential issue in OP-TEE. It does not treat 0 as a > > > > valid address. So, in that rare case, when REE will try to use 0 > > > > as a correct address for data buffer, OP-TEE will not map it into > > > > TA address space, instead it will pass NULL to TA, so TA will think that > > > > no buffer was provided. > > > > > > Thanks! That's reassuring. Although, I think we may still need to prevent > > > MFN > > > 0 to be allocated for a guest using OP-TEE. So they don't end up with > > > weird > > > failure. > > > > > > I don't think this is an issue so far, but this may change with Stefano's > > > dom0less series to support direct mapping. > > > > Yes, it is interesting to know about this limitation. > > > > In regards to this patch, it looks OK as-is in terms of code changes. > > I would disagree here. NULL has never been handled correctly for TMEM buffers > (see [1]). I would argue this needs to be folded within this patch rather than > be a separate one. I am OK with that too. > > Aside from a link to this conversation in the xen-devel archives, is > > there anything else you would like to add to the commit message? > +1 for the link. However, I don't think the commit message fully > match/summarize the discussion here. > > What needs to be clearly spell out is that existing OP-TEEs will never map MFN > 0. That would be nice > Cheers, > > [1] <87h7v71ixf.fsf@epam.com> From xen-devel-bounces@lists.xenproject.org Fri Jun 19 18:23:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 18:23:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmLfn-0002s1-LQ; Fri, 19 Jun 2020 18:23:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmLfm-0002rw-E6 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 18:23:30 +0000 X-Inumbo-ID: f944cedc-b259-11ea-bca7-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f944cedc-b259-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 18:23:29 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id y13so11168668eju.2 for ; Fri, 19 Jun 2020 11:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:autocrypt:subject:message-id:date:user-agent :mime-version:in-reply-to; bh=Vfy+JjQpvugirTgGbla1mvn1w9sg4RdrB9Z6ncIWjks=; b=K/OaIL9F9dK44pJOR0GOY60OwH918Kmoe5tConvHMONOumzKKMC82+auUzC+AV66zL cpDYK4YaTjZLd1E42Ai0sRJhsim+hbvCSgy4vdMKoRHi3hmNSzylZJ84YAxlygFNFQUX LmLLtZXmO7Kww3ago+FY+V1AtlW/fWh/JiXDWPZXEGjOohSneuTYRWlYlIdf8YvFx4LT eemIyXC8aw/jV1Cl7QCMPKJC4eX2IJpdtVMDFZHpoimz0g9MsKpongmPG2q9rz747HEZ hFRnEB96AhcI7oyLnmDuZdQYs/UgR3QBAakWx4ZrPLWqf1RU45MxitzJlFeKZhBZYaN9 JDUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to; bh=Vfy+JjQpvugirTgGbla1mvn1w9sg4RdrB9Z6ncIWjks=; b=ntzg7rZ9EzoXFT5RoDiPIDe1p1HuntbI2LXzP0A/jz9qWWdjrVq+BCUD0QHJzBpjlc 0hfbFdlL3wvrjP++uBBB29jv/4jduldZZcEJGCS7PsLqhdX4rhGFHkVOrA1/Re/DsFg3 1AwrEI4UIuXq5tiARWqyp00Um5rdejHKk8s4b7b+b3NElULQUu1xtaoD7vhzRPdMZ0nt KiRVG7DcbzXnzgMrM04cgmWGbKIDw1uE5QMMu3Tkz633hvbrdYd55ZMeaBYxOjrtbhes lrvnPYnREoCGJ9wsU2PxK8N0vV7IVZyJs2ew4BO10zFNBEVIrzOFuwyWqHDG1+xQPPAw MlRQ== X-Gm-Message-State: AOAM531Rly8PFnEP+u/j5rug2ishlmMtz98bIQtmh7iJUclEWqqWoy/T 4k41Bg4bsWKeuTY0Qo9h26A= X-Google-Smtp-Source: ABdhPJxCr3A+V5osae3kNNt1xFYptDn2Tu245o96nsYCwCub+GEqaIVZKHVLVJHvZeT35qPq/BK2Nw== X-Received: by 2002:a17:906:3e84:: with SMTP id a4mr4634106ejj.372.1592591008810; Fri, 19 Jun 2020 11:23:28 -0700 (PDT) Received: from [192.168.8.124] (public-gprs354184.centertel.pl. [37.47.14.201]) by smtp.gmail.com with ESMTPSA id y62sm5160839edy.61.2020.06.19.11.23.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 11:23:28 -0700 (PDT) To: Jan Beulich References: From: Grzegorz Uriasz Autocrypt: addr=gorbak25@gmail.com; prefer-encrypt=mutual; keydata= mQENBFyZgUUBCACo21Uf58hRRgX0uQd3kRJUqXp8/kJsC58tKZG9ENy8rvmcq15AmblqOQnD k6Pmh2lhh31A+m4ONF+TT0vlFYv9sN0kA1llvHPH95LYhROXt7UwSZBQTnQlLZFVqeGa3R6M pJwaAMQP/lyYgINt1pvBdCWtcNP/wKuNI/efnZuBOPDKSeBH/V0ZmmZxlSsx05/ktgtR6ibP FZXPBgx5DY0DxPm/jb8CqkXO5291wyYCP2VDy85oqG8EgsfFOOPZNwBQCKS7cWLZDMEsVNnB WyU3zJZBvEVK/5BwIzm1+AL9lR6RRLaOpC19k2ZqbyhEG9EhsR+/DIF0znBd9Nhjokd5ABEB AAG0JEdyemVnb3J6IFVyaWFzeiA8Z29yYmFrMjVAZ21haWwuY29tPokBVwQTAQgAQQIbAwUJ A8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBHDkRnQjCGTnaTo/LngD9fcXMA1pBQJd /5CUAhkBAAoJEHgD9fcXMA1pb9YIAICTmZOrEGho9MC7z851jw507EamIqaAXQAADKpbxSGH yVxALYZv6cqR84rsQuML0N8ai4rdCJ7PviMYyaWVX3P09kJoFxSzKhjxbwZMkRF8O+9tIhNO 29h8v5cmv7Sp4NpssITFMZAms4LleJtdkivDeRxSCyJnHceZyGiD6pPTkopyuISGZIS+4axF zarn+JM+uiTm1QHdCbcvK3sor//QvHr9kKjLKTxMwiTZOGQzF8+oHpVxxwX8Bz3UbFwRX/Io rErT92f9WOsFWnvZHuLGcRLSlG0h9xljIuhP7mvGiudTgNoPt9YFtAG8KT/2HnUZ4XxJKi+B 8Ilet++3m4m5AQ0EXJmBRQEIANBww0bVhYwP1g4AMux/Fjp7KUjYj7Q8ej+t71ShZkAzvPQT 00ULdnYEa62uKM9YwXqOu0XJsnBveJKO1q3nfJuazAbsC0B3v0bYlUUQoTRxCUs3v22UOVxe kaTtN3KDdnSTq7QkkZBZFvV+vAwKGlqECzsYtZ86CiIEOgmUeVA82AzyMx306l1th90OdHYt LKkHxreEPWInN9jptOaKNwvB5cR6PxFfVRtVteN121tVJRK5geA0RVjHn35ig97ycDP5FcwP HuuuKfr+07ANXrtFM/QLGmIvEaMEgpPmzyGkXGhbsDpMikHOkXvQCRTesJ38r8DRUffinYXI vAw0IsMAEQEAAYkBPAQYAQgAJhYhBHDkRnQjCGTnaTo/LngD9fcXMA1pBQJcmYFFAhsMBQkD wmcAAAoJEHgD9fcXMA1p3y8H/2nftQbUcb2oKtpyePStdmdN45A1OWjorj6iBRvTOhoig6y7 PbveJ9Zj35IP0Zy4W77Ke4ayK/PiBkh7bRrdQAwTAc7EiYw3j+foO32JA/4bANMgSuRBxO/d xoloRPoaRE6eGUkA3N65V5WlWkinKxzSGDgSOz7Tit5QY8fGJYWeLTzFj605Y9iUu0MSLpfs LQQby+I9gETWh5TUMz1uNytIB80UdMpzqcC36zCMk7wIy1g8YhbehJq1zU1+ZpDrggrN3ucH 0NFFvHq5uwEkR8Llj29nDcyKuWMlnCMpM/iJcTde7N8UVdtN9yBGol4+yAZT0w5RP87pw3oD fuZMcoY= Subject: Re: [PATCH v2 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Message-ID: Date: Fri, 19 Jun 2020 20:23:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wnyo5xbJ5COLKig1aSkN1SX5mDPO82EtB" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wnyo5xbJ5COLKig1aSkN1SX5mDPO82EtB Content-Type: multipart/mixed; boundary="cNNM5kT93BLjfWRA9MTttUZY7XDXOXIy4"; protected-headers="v1" From: Grzegorz Uriasz To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , marmarek@invisiblethingslab.com, artur@puzio.waw.pl, jakub@bartmin.ski, j.nowak26@student.uw.edu.pl Message-ID: Subject: Re: [PATCH v2 1/1] x86/acpi: Use FADT flags to determine the PMTMR width References: In-Reply-To: --cNNM5kT93BLjfWRA9MTttUZY7XDXOXIy4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 19/06/2020 15:17, Jan Beulich wrote: > On 19.06.2020 06:28, Grzegorz Uriasz wrote: >> --- a/xen/arch/x86/acpi/boot.c >> +++ b/xen/arch/x86/acpi/boot.c >> @@ -478,7 +478,9 @@ static int __init acpi_parse_fadt(struct acpi_tabl= e_header *table) >> if (fadt->header.revision >=3D FADT2_REVISION_ID) { >> /* FADT rev. 2 */ >> if (fadt->xpm_timer_block.space_id =3D=3D >> - ACPI_ADR_SPACE_SYSTEM_IO) { >> + ACPI_ADR_SPACE_SYSTEM_IO && >> + (fadt->xpm_timer_block.access_width =3D=3D 0 || >> + ACPI_ACCESS_BIT_WIDTH(fadt->xpm_timer_block.access_width) =3D=3D= 32)) { > Thinking about it again, since we're already tightening this > check, I think we would better also verify bit_offset =3D=3D 0. > > There also looks to be an indenting blank missing here. I will add the check and correct the indentation. > >> @@ -490,8 +492,10 @@ static int __init acpi_parse_fadt(struct acpi_tab= le_header *table) >> */ >> if (!pmtmr_ioport) { >> pmtmr_ioport =3D fadt->pm_timer_block; >> - pmtmr_width =3D fadt->pm_timer_length =3D=3D 4 ? 24 : 0; >> + pmtmr_width =3D fadt->pm_timer_length =3D=3D 4 ? 32 : 0; >> } >> + if (pmtmr_width > 24 && !(fadt->flags & ACPI_FADT_32BIT_TIMER)) >> + pmtmr_width =3D 24; >> if (pmtmr_ioport) >> printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x (%u bits)\n", >> pmtmr_ioport, pmtmr_width); > I thought we had agreed to log at the very least the case where > the FADT flag is set but the width is less than 32 bits. (And I > agree that perhaps there's not much more to log, unless we'd > suspect e.g. strange access widths to be present somewhere.) > My bad - I've misunderstood the discussion. >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -457,16 +457,16 @@ static u64 read_pmtimer_count(void) >> static s64 __init init_pmtimer(struct platform_timesource *pts) >> { >> u64 start; >> - u32 count, target, mask =3D 0xffffff; >> + u32 count, target, mask; >> =20 >> - if ( !pmtmr_ioport || !pmtmr_width ) >> + if ( !pmtmr_ioport ) >> return 0; >> =20 >> - if ( pmtmr_width =3D=3D 32 ) >> - { >> - pts->counter_bits =3D 32; >> - mask =3D 0xffffffff; >> - } >> + if ( pmtmr_width !=3D 24 && pmtmr_width !=3D 32 ) >> + return 0; >> + >> + pts->counter_bits =3D (int) pmtmr_width; >> + mask =3D (1ull << pmtmr_width) - 1; >> =20 >> count =3D inl(pmtmr_ioport) & mask; >> start =3D rdtsc_ordered(); >> @@ -486,7 +486,6 @@ static struct platform_timesource __initdata plt_p= mtimer =3D >> .name =3D "ACPI PM Timer", >> .frequency =3D ACPI_PM_FREQUENCY, >> .read_counter =3D read_pmtimer_count, >> - .counter_bits =3D 24, >> .init =3D init_pmtimer >> }; > I'm struggling a little to see why this code churn is needed / wanted. > The change I had suggested was quite a bit less intrusive. I'm not > entirely opposed though, but at the very least please drop the odd > (int) cast. If anything we want the struct field changed to unsigned > int (but unlikely in this very patch). > > If you want to stick to this larger change, then also please fold the > two if()s at the beginning of the function. I wanted to avoid hard coding the masks -> Linux has a nice macro for generating the masks but I haven't found a similar macro in xen. Additionally this version sets the counter width in a single place instead of two. > > Jan Best Regards, Grzegorz --cNNM5kT93BLjfWRA9MTttUZY7XDXOXIy4-- --wnyo5xbJ5COLKig1aSkN1SX5mDPO82EtB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEcORGdCMIZOdpOj8ueAP19xcwDWkFAl7tAp0ACgkQeAP19xcw DWmofAgAp4CNdDnecJipl8pUbJ9QD37Cpe52fwDXB0p0wHY7QS7xUf4AeCOfZeLF WklS6U1ms2iH9wn5u9BKpx/nVPE+BNpwBnqwiL8IZOW+32jXkzwvDli/L9slFW37 j6cEBR5g43ieupJYN1W/30CGrRBrCs/ReUUXrfM5Fj/7gsn3SNJ1AvluduA7gRXO 0uUvqNquGowr7mwp0P+mkbGSXXQxZn4mWS/pVzmMG5J0xc3z007AfyORNWSH/xID 9bip8td/RzuYRI+wUMJFWLM3GtnjIyKVV590lE9zitGXUI9LXGepkjAeGBug+LWh Qo628NV7GFXILO+DR8EFEGjTzOGGIg== =U5n8 -----END PGP SIGNATURE----- --wnyo5xbJ5COLKig1aSkN1SX5mDPO82EtB-- From xen-devel-bounces@lists.xenproject.org Fri Jun 19 19:00:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 19:00:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmMFe-0006Cg-Jc; Fri, 19 Jun 2020 19:00:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmMFe-0006Cb-73 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 19:00:34 +0000 X-Inumbo-ID: 26aafe1e-b25f-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 26aafe1e-b25f-11ea-bb8b-bc764e2007e4; Fri, 19 Jun 2020 19:00:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wQOC6qBs+qcdrbxqfTLJ4MspUqu10s5QdTTs/lKHv5c=; b=v+6HLmTUT9daG2ybodAZDoNfC AfX6S7RjBD2MURYDK9Bu+kp5RlIc1TZ7pljSUSwgR0FqbnGD4Ly8USWAI7ZbPHBalNdS5LeUFZGVY lT8ZhLed12PGVHLB2CfU53WQ17f3Fascj/OcKdZlbbJaNTOYEasPFYqLjDsMH89Wg4if8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmMFc-00068Z-CI; Fri, 19 Jun 2020 19:00:32 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmMFb-0001gM-LT; Fri, 19 Jun 2020 19:00:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmMFb-0003s7-Kh; Fri, 19 Jun 2020 19:00:31 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151235: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=b67e859d0823f5b450e29379af9142d44a3ea370 X-Osstest-Versions-That: xen=f1d376a825f4878eab0ef9cabe50ec4299968629 From: osstest service owner Date: Fri, 19 Jun 2020 19:00:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151235 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151235/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen b67e859d0823f5b450e29379af9142d44a3ea370 baseline version: xen f1d376a825f4878eab0ef9cabe50ec4299968629 Last test of basis 151226 2020-06-18 18:00:35 Z 1 days Testing same since 151235 2020-06-19 14:00:30 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Roger Pau Monné Tamas K Lengyel jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git f1d376a825..b67e859d08 b67e859d0823f5b450e29379af9142d44a3ea370 -> smoke From xen-devel-bounces@lists.xenproject.org Fri Jun 19 19:08:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 19:08:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmMMy-0006UV-Dt; Fri, 19 Jun 2020 19:08:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmMMx-0006TJ-R2 for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 19:08:07 +0000 X-Inumbo-ID: 31a3a32e-b260-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 31a3a32e-b260-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 19:08:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rBQ+NSWhHQwy0L9xTJTWoBh+5I7mz05m8eysA3mbmSg=; b=SDDAJkMYLxS3WyrigoE1oprZt wWtoVElXDzo5LiyxwYuy3NHSApIV3MtcDxlQiGkXen60J4DGofcaIec1kzvQe8BJnuZC5lpalKw1o KA6glTRBRPfxubo4kVclZOLsuAXW0UpuVVu3G0B6p4EJ+woGVuuvVoHK38SGIEFDPAHJc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmMMq-0006HS-F0; Fri, 19 Jun 2020 19:08:00 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmMMq-0002Ur-6n; Fri, 19 Jun 2020 19:08:00 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmMMq-00016z-5Z; Fri, 19 Jun 2020 19:08:00 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151214: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 X-Osstest-Versions-That: linux=a5dc8300df75e8b8384b4c82225f1e4a0b4d9b55 From: osstest service owner Date: Fri, 19 Jun 2020 19:08:00 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151214 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151214/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151170 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151170 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151170 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151170 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151170 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151170 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151170 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151170 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 baseline version: linux a5dc8300df75e8b8384b4c82225f1e4a0b4d9b55 Last test of basis 151170 2020-06-16 14:31:27 Z 3 days Testing same since 151214 2020-06-18 02:27:46 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aaron Brown Aditya Pakki Alaa Hleihel Alex Xu (Hello71) Arnd Bergmann Arvind Sankar Bartosz Golaszewski Charles Keepax Chen Yu Christoph Hellwig Colin Ian King Corentin Labbe David Howells David Rientjes David S. Miller Eric Dumazet Geert Uytterhoeven Geert Uytterhoeven Geliang Tang Gene Chen Gustavo A. R. Silva Gustavo A. R. Silva Hangbin Liu Horatiu Vultur Ido Schimmel Jeff Kirsher Ka-Cheong Poon Lee Jones Linus Torvalds Marcelo Ricardo Leitner Martin Michael Chan Michal Simek Neal Cardwell Pablo Neira Ayuso Phil Sutter Randy Dunlap Richard Cochran Santosh Shilimkar Sergei Shtylyov Stefano Brivio Sven Auhagen Thomas Falcon Tim Harvey Vaibhav Gupta Vasundhara Volam Vladimir Oltean Wang Hai Wang Qing Wei Yongjun Zekun Shen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git a5dc8300df75..1b5044021070 1b5044021070efa3259f3e9548dc35d1eb6aa844 -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Fri Jun 19 20:03:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 20:03:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmNDu-00034j-SM; Fri, 19 Jun 2020 20:02:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmNDt-00034e-9Q for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 20:02:49 +0000 X-Inumbo-ID: d918a652-b267-11ea-bca7-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d918a652-b267-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 20:02:48 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8457320C09; Fri, 19 Jun 2020 20:02:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592596967; bh=xe6f8xVE2c7sP+o0l9LR95vqUYc1YGec51+cHjGjrho=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eG/b0fibL/aORRg7B6B7jEHbsopAzR4FkjYympc4U9jM2OMTAnnGVMJJAdtIaabwp Ljd7mQRFNTWQullN1Sk0SXc5HfPuPaJ2b7ATBhMTa+90uLZwv4OkFDRUhqZiss8dJ6 yoocFlb6Lmom3lQil+It5gj8BA/ufz8CRvmXe91Y= Date: Fri, 19 Jun 2020 13:02:47 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: UEFI support in ARM DomUs In-Reply-To: Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Stefano Stabellini , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, 18 Jun 2020, Julien Grall wrote: > > Copy/pasting here from my comment on the pull request plus additional > > thoughts. > > > > Uboot is one of those embedded projects that typically assumes that all > > the information about the platform is available at *build time*. It is > > meant to be built tailored for a specific version of a specific board. A > > Uboot binary is not expected to be "portable" across different versions > > of the platform or different platforms. In other words, it is not > > expected to be portable across Xen versions. > > Can you define "version" here? Do you refer to the difference in terms > of memory? Yes, I meant any meaningful differences in any of the external interfaces that end up impacting the UBoot implementation. A primary example would be the memory addresses for instance. > > This is a different model meant for different use-cases. I don't think > > it is a problem "philosophically" to let Uboot know about Xen details at > > build time. Yes, that is not what we did historically but it is very > > much in the spirit of Uboot. > > TBH, I don't particularly mind that U-boot is built against a specific > version of Xen. I am more concerned about the long term implication if > we endorse it > and then try to change the memory layout in depth. I'll provide more information below. > > But of course the least Uboot depends on these details the better > > because it will be more flexible, but it could very well be that we > > won't be able to reach the point where the binary works on any version > > like we did with Tianocore. The two projects work differently. > > Can we have a list of things U-boot require to know at compile time? > > In particular, I would like to understand if it would be sufficient to > only be aware of the first bank. If it is, then my preference would be > to standardize that bit of the layout. That would be my preference too, and it was great to read that it looks like it can be done. Yay! > > That said, I think Julien is right that we need to be careful on how we > > expose these information to Uboot, i.e. defining __XEN__ to build Uboot > > doesn't seem like a good idea because we enable definitions that were > > never meant to be used outside of a Xen build. Also, it wouldn't be easy > > to know exactly which definitions are actively used by Uboot and which > > ones aren't. > > > > If we are going to make Uboot dependent on version-specific information > > of the Xen interface, it would be better to be very clear about which > > definitions we are using. So that one day if we need to change them, we > > can find them easily. > > > > So I think it would be better to introduce a set of defines with the > > minimum amount of information required by Uboot statically. That way, > > at least we have a single place where to find all the version-specific > > definitions that Uboot is using. > > I am not sure what you are suggesting. Can you expand a bit more? > > > We can also manage versioning of the > > Xen interface (like we do in QEMU) if we have to. > > Can you provide more details about the compatibility? I am quite > interested in the part where you would have to deal with an older QEMU > version built against a new Xen? Sure let me expand a bit more. I'll switch "hat" to "QEMU (or UBoot) contributor" for the sake of this discussion. Xen Project offers certain stability guarantees on some interfaces and not others. Let's say that for any reason you have to or want to use one of the unstable interfaces in QEMU/UBoot/Whatever. Then it becomes your responsibility as QEMU developer to maintain compatibility in QEMU itself. First I'd add code to detect the version of the interface. The detection is based on the Xen headers/libraries provided. In QEMU it is done in the "configure" script. It sets a preprocessor #define to the version of the interface (e.g. CONFIG_XEN_CTRL_INTERFACE_VERSION == 41100). Then you can have preprocessors checks in one of the headers such as: #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40701 #define xenevtchn_open(l, f) xc_evtchn_open(l, f); #else XXX #endif And also like: #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40600 #ifndef HVM_IOREQSRV_BUFIOREQ_ATOMIC #define HVM_IOREQSRV_BUFIOREQ_ATOMIC 2 #endif #endif This works OK to handle differences in the interface between past versions of Xen. What about building an older QEMU against a new version of Xen? That is not going to work if something changes again on the Xen side. However, it becomes much easier to add support for the new Xen interface in QEMU, because you can go and look at that compatibility header and just add the right #else XXX. It also makes it clear what interfaces and definitions have been used that are unstable. Of course it is better to use the stable interfaces when possible :-) From xen-devel-bounces@lists.xenproject.org Fri Jun 19 22:00:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 22:00:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmP3l-0004kY-LZ; Fri, 19 Jun 2020 22:00:29 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmP3k-0004kT-Im for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 22:00:28 +0000 X-Inumbo-ID: 48b94da8-b278-11ea-b7bb-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 48b94da8-b278-11ea-b7bb-bc764e2007e4; Fri, 19 Jun 2020 22:00:27 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id gl26so11757970ejb.11 for ; Fri, 19 Jun 2020 15:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=D3c6isltU9wDsjvWe1FRxWQI8iE4xtXifjJQA9egUR8=; b=Etv4sm9AEDdjRMs/DjtAua8wlLcuwzn/HaH5fhUku7iwUOFQk+aVjLvX3WIqH5skMU h64cMB9hZCdYu4HXPdxiG47sipua7TKM4oTe22YVQUI8e0zX1YJIWlpxcQ3JJWPETMVn NHg5ZPXqYPXyd3QwH+EywidsVCxYrgLbL+GPmixOJ/ktL6bzGiS1WguUPl62TZkbsYFW vjhE82uiD7/QuhRtZqImHqsiYmZx8dWGpFC7pX0qeC4O9+sNKRgRA9vrIWg2uIkxT2Ht TAQs+F37XOy80HcXIOGjbR8EtelW7DenTRSocPdQO5+OddsI1RtJAL7DM70h79uhA4QB L1VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=D3c6isltU9wDsjvWe1FRxWQI8iE4xtXifjJQA9egUR8=; b=SQBh3+xmCttjIll8bvxOOuLZOyreuEtbsV7igBhcMXHETuSQBRY36rRv2vSQ39qn+V 6Sn0iCUkHHSjBVrlKDudZHxgbhWB2+0bMvJpoY6h/ZJT4UVVBZlnezcsisphEz9o8o4x T7LEPYO1J4iw4fqfrEpZVB3qUzAHp9RxLDsP+PifA0XQTZzweXVJkbC1h/p+2EWdRrD5 AFOCKc1rfxQAt9MUvffvescv8tUjChEBfIm5jbqJ1Orq4MdFpWVZLrEpKPCV0f+s7gYZ /Vvbq5nwfxtoKOgVQwlMCvodK16fdEzu2kYnieS2wXfxJV8V9PuMnfkWI09dgsxEVplq 6sUg== X-Gm-Message-State: AOAM532YRDgOqUSsEc6XRw8/RJmiT8hZzNYHtGkWTM+pSQkkLORw2AjG fLPZ3v/3StVoyrYf+LJDNkmMDPctqcaf4A== X-Google-Smtp-Source: ABdhPJxFsCMAmvhnsDSAU7sNWxW+E/M2QT2vmjkYo1vZ7iuaFJ6FlFTAKDFNhSn5SsSHzMaHxd0MqA== X-Received: by 2002:a17:906:c952:: with SMTP id fw18mr5167804ejb.505.1592604026800; Fri, 19 Jun 2020 15:00:26 -0700 (PDT) Received: from localhost.localdomain (public-gprs354184.centertel.pl. [37.47.14.201]) by smtp.gmail.com with ESMTPSA id b4sm5261360ejp.40.2020.06.19.15.00.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2020 15:00:26 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH v3 0/1] Fix broken suspend on some machines Date: Fri, 19 Jun 2020 22:00:15 +0000 Message-Id: X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , Jan Beulich , j.nowak26@student.uw.edu.pl, contact@puzio.waw.pl, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, The included patch is a small subset of a bigger patch set spanning few projects aiming to isolate the GPU in Qubes OS to a dedicated security domain. I'm doing this together with 3 colleagues as part of our Bachelors thesis. While working on the project we came across 2 machines - newer gaming laptops on which the suspend functionality on unmodified xen is completely broken. The affected machines were able to suspend but not always resume. Even if the resume succeeded then the kernel time was trashed in the dmesg log and the machine never managed to suspend another time. After changing the xen clock to hpet, suspend started working again both on stock xen and Qubes OS - this indicates a bug in the ACPI PM Timer. After disassembling the FADT ACPI table on the ASUS FX504GM I understood that the reported bit width is 32 bits but the flags indicate a 24 bit PM timer. The included patch fixes the suspend feature on ASUS FX504GM and hopefully other laptops - Probably next week I will test this patch on my friend's laptop where this issue also occurs(suspend is broken, trashed kernel time after resume). Changes in v2: - Check pm timer access width - Proper timer width is set when xpm block is not present - Cleanup timer initialization Changes in v3: - Check pm timer bit offset - Warn about acpi firmware bugs - Drop int cast in init_pmtimer - Merge if's in init_pmtimer Grzegorz Uriasz (1): x86/acpi: Use FADT flags to determine the PMTMR width xen/arch/x86/acpi/boot.c | 19 +++++++++++++++---- xen/arch/x86/time.c | 12 ++++-------- xen/include/acpi/acmacros.h | 8 ++++++++ 3 files changed, 27 insertions(+), 12 deletions(-) -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 22:00:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 22:00:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmP3q-0004kk-V6; Fri, 19 Jun 2020 22:00:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmP3p-0004kT-DR for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 22:00:33 +0000 X-Inumbo-ID: 499234ce-b278-11ea-bca7-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 499234ce-b278-11ea-bca7-bc764e2007e4; Fri, 19 Jun 2020 22:00:29 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id o15so11735016ejm.12 for ; Fri, 19 Jun 2020 15:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HfYUNEU41EvFg2RZy0do+m9ixRVuyVGzvdL5MBLFCAo=; b=UP8cug/qv3i80NJ5OH4fU+mt5dwnKjMvJo5F0FYD8RXUqbA+0IJbWqQ31njqbWpRuX aICuVrkg2AiQgY5+PtIr/cp4JasmhkGdTCpIGnQjX9fj85TeG83nacgaAPm/yIBFS0gj 5A+mf0e9cdnOdKOizyidr57hpNwEQfxrv7EWbW8vSA/rrrtXkVwfpNpwQEcVYiIMlVd0 maiWHDbjmONRUunBPofhi9gQLCifu2Wvw/AYuPRIcWSpNR68HMvyP2UA4Qg5pvY+7YPW kZzPhyBC0JRxHXCG6WIvWkK7y2kpSNtBYJfxhITfNccX6oKzGbZKxLL49K6d1WCg9MjK Vlig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HfYUNEU41EvFg2RZy0do+m9ixRVuyVGzvdL5MBLFCAo=; b=H9ap1MvpcbHhrNhGY4TnlwaSwSkXyqVqLyFNIvrZXlpJwMENZlrsohnXiSkdH1dl3C WO61NA0cCzRSTsVnAJGEXV7+pAzLa+4ewauy5gbH7mak5Dz5U4EKyrYbUCJGz9IKlaJf 3Jk3ynoYu+3Zx8LiH/RxHm0o7memDgc/758BSf5d46HJ/LFuqbzu9OwKehHQPURNrzag fj/V1WV0vGH7ljdyKqaU9PdQzB+bFMNAgufL4n8eaGeyiFpheRUOoiVggi/O9JLP4BSB GKpfOtHqXLRoDHP06PRZS5TmMaDS0GyQpCteJfKFih9SyZ50F27K/chnhcAU/vQ8Aq4C idhQ== X-Gm-Message-State: AOAM530de3miXoX+ajVm72Ma89u7tvuirFg4ASVmkHAEj3KUwsJkBH32 19lIkcWmwsYZeA2e8BZ+RoMpsfhmf0RTmg== X-Google-Smtp-Source: ABdhPJwNHICadOoy5W3bfZb4CTH5KXnZ/0Dc2VMPfnFG4+wxe72TSXxvaRJpe2cFnmA71uGUv6SCfg== X-Received: by 2002:a17:906:cc58:: with SMTP id mm24mr5930152ejb.134.1592604028264; Fri, 19 Jun 2020 15:00:28 -0700 (PDT) Received: from localhost.localdomain (public-gprs354184.centertel.pl. [37.47.14.201]) by smtp.gmail.com with ESMTPSA id b4sm5261360ejp.40.2020.06.19.15.00.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2020 15:00:27 -0700 (PDT) From: Grzegorz Uriasz To: xen-devel@lists.xenproject.org Subject: [PATCH v3 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Date: Fri, 19 Jun 2020 22:00:16 +0000 Message-Id: X-Mailer: git-send-email 2.27.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , Jan Beulich , j.nowak26@student.uw.edu.pl, contact@puzio.waw.pl, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On some computers the bit width of the PM Timer as reported by ACPI is 32 bits when in fact the FADT flags report correctly that the timer is 24 bits wide. On affected machines such as the ASUS FX504GM and never gaming laptops this results in the inability to resume the machine from suspend. Without this patch suspend is broken on affected machines and even if a machine manages to resume correctly then the kernel time and xen timers are trashed. Signed-off-by: Grzegorz Uriasz --- Cc: Jan Beulich Cc: Andrew Cooper Cc: Wei Liu Cc: "Roger Pau Monné" Cc: marmarek@invisiblethingslab.com Cc: contact@puzio.waw.pl Cc: jakub@bartmin.ski Cc: j.nowak26@student.uw.edu.pl Changes in v2: - Check pm timer access width - Proper timer width is set when xpm block is not present - Cleanup timer initialization Changes in v3: - Check pm timer bit offset - Warn about acpi firmware bugs - Drop int cast in init_pmtimer - Merge if's in init_pmtimer --- xen/arch/x86/acpi/boot.c | 19 +++++++++++++++---- xen/arch/x86/time.c | 12 ++++-------- xen/include/acpi/acmacros.h | 8 ++++++++ 3 files changed, 27 insertions(+), 12 deletions(-) diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c index bcba52e232..24fd236eb5 100644 --- a/xen/arch/x86/acpi/boot.c +++ b/xen/arch/x86/acpi/boot.c @@ -475,10 +475,17 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) #ifdef CONFIG_X86_PM_TIMER /* detect the location of the ACPI PM Timer */ - if (fadt->header.revision >= FADT2_REVISION_ID) { + if (fadt->header.revision >= FADT2_REVISION_ID && + fadt->xpm_timer_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO) { /* FADT rev. 2 */ - if (fadt->xpm_timer_block.space_id == - ACPI_ADR_SPACE_SYSTEM_IO) { + if (fadt->xpm_timer_block.access_width != 0 && + ACPI_ACCESS_BIT_WIDTH(fadt->xpm_timer_block.access_width) != 32) + printk(KERN_WARNING PREFIX "PM-Timer has invalid access width(%u)\n", + fadt->xpm_timer_block.access_width); + else if (fadt->xpm_timer_block.bit_offset != 0) + printk(KERN_WARNING PREFIX "PM-Timer has invalid bit offset(%u)\n", + fadt->xpm_timer_block.bit_offset); + else { pmtmr_ioport = fadt->xpm_timer_block.address; pmtmr_width = fadt->xpm_timer_block.bit_width; } @@ -490,8 +497,12 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) */ if (!pmtmr_ioport) { pmtmr_ioport = fadt->pm_timer_block; - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0; + pmtmr_width = fadt->pm_timer_length == 4 ? 32 : 0; } + if (pmtmr_width < 32 && fadt->flags & ACPI_FADT_32BIT_TIMER) + printk(KERN_WARNING PREFIX "PM-Timer is too short\n"); + if (pmtmr_width > 24 && !(fadt->flags & ACPI_FADT_32BIT_TIMER)) + pmtmr_width = 24; if (pmtmr_ioport) printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x (%u bits)\n", pmtmr_ioport, pmtmr_width); diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c index d643590c0a..8a45514908 100644 --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -457,16 +457,13 @@ static u64 read_pmtimer_count(void) static s64 __init init_pmtimer(struct platform_timesource *pts) { u64 start; - u32 count, target, mask = 0xffffff; + u32 count, target, mask; - if ( !pmtmr_ioport || !pmtmr_width ) + if ( !pmtmr_ioport || (pmtmr_width != 24 && pmtmr_width != 32) ) return 0; - if ( pmtmr_width == 32 ) - { - pts->counter_bits = 32; - mask = 0xffffffff; - } + pts->counter_bits = pmtmr_width; + mask = (1ull << pmtmr_width) - 1; count = inl(pmtmr_ioport) & mask; start = rdtsc_ordered(); @@ -486,7 +483,6 @@ static struct platform_timesource __initdata plt_pmtimer = .name = "ACPI PM Timer", .frequency = ACPI_PM_FREQUENCY, .read_counter = read_pmtimer_count, - .counter_bits = 24, .init = init_pmtimer }; diff --git a/xen/include/acpi/acmacros.h b/xen/include/acpi/acmacros.h index 6765535053..86c503c20f 100644 --- a/xen/include/acpi/acmacros.h +++ b/xen/include/acpi/acmacros.h @@ -121,6 +121,14 @@ #define ACPI_COMPARE_NAME(a,b) (!ACPI_STRNCMP (ACPI_CAST_PTR (char,(a)), ACPI_CAST_PTR (char,(b)), ACPI_NAME_SIZE)) #endif +/* + * Algorithm to obtain access bit or byte width. + * Can be used with access_width of struct acpi_generic_address and access_size of + * struct acpi_resource_generic_register. + */ +#define ACPI_ACCESS_BIT_WIDTH(size) (1 << ((size) + 2)) +#define ACPI_ACCESS_BYTE_WIDTH(size) (1 << ((size) - 1)) + /* * Macros for moving data around to/from buffers that are possibly unaligned. * If the hardware supports the transfer of unaligned data, just do the store. -- 2.27.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 22:34:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 22:34:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmPaK-0007Td-KM; Fri, 19 Jun 2020 22:34:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmPaJ-0007TH-BI for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 22:34:07 +0000 X-Inumbo-ID: f9b03fd2-b27c-11ea-bc14-12813bfff9fa Received: from EUR02-VE1-obe.outbound.protection.outlook.com (unknown [40.107.2.83]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f9b03fd2-b27c-11ea-bc14-12813bfff9fa; Fri, 19 Jun 2020 22:34:02 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FffT4ONo8ifhOx0OsH2Oz/aFSP5LVsam3uNimhGBZg/gj68iaLXeu8E8tcPde3ZpLEbKp6nIQLnMAiSYWkxon5GfmdibTcEqNJOq7MJXORr6VqP+yfHB1zzhU0Hsi2uh0cDDxiTDpbkp1RJtphwezWOVBXOWEHL9vPEecK8X/4XyA6sp62Cf1wuhuN1mkqCmJDw05kWx1m4eeDbIuqfo+hE96Vbb+Rxts3wdFknE8t3fK8QkeQb4VvnHYCz4z4TKM6eAZxZLdZjbiKGBWGqbw0TT9FTlhyV0+Lk2W7+fZWurMlwPH9+IqbgwLG8YRIbDXgGjegpKcVOGX5RYkoGmxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0bdpwoLHFQMj1SYEBKXuxitCU7+h+os+vfddbprIScE=; b=hT70BpSTY4HGqZOzVDEuJj6zz/mafoFzW0egH+TjxeGXPXA7yjF2KpvWOpwqChZz7fMg/imUgwZJYLBMh4l7jTFO7X8XbiniN8BbD5uS8L5kwyMBfQSPGqW/n7CSdcMRRAMNmSnQNs/Lbgg3hNXZ8zcOuO070ciyrlgurjHF3XJPD+n6sYr1NBHIrLH0JCWH9gtV07W88HlKYR7JIuG6gaZ/gLkdNpvVkVl1cuisohTQVgaRRZYIigBIOV5VvYubzIcszmY3+SUQ9xc0NmyBJa77vWeGS6XqqUchfnVwqjG33sBf8ZMMefsUq9QNf0AASWnW66zAI9wyO6dpF/zZCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0bdpwoLHFQMj1SYEBKXuxitCU7+h+os+vfddbprIScE=; b=r2aHDYPsYhEMiNpOd++hgNSxzRXe6+0bQ476ggWh1jVfmOak+k5s9Eu85GkccDgL+kxfKqHnCnGor/0l6ZWajYa3OjyTLWN4g5Aa891ma4cl2W8lGkNYNyyuC60LQQblKzfKF9q9lEWwauPVVZ6IPUzRi+0EmUYGuheBhRZlzvdSlBzqh0aOkiV3OcAfSBB2OzHMDtYikkltoMIEvwaiPnUN6ePSf2ZLQ029LcI4XCOGjVzHZuelm1YIT1E4J3tnaSa9na/qT3cLfY4snm0HiunX2GsM+axDRaTrSE5Fhp2NlZHaZpjVVGfEKjTt3HpKZW8j8Y2nzgHOZIADZWixeA== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB6304.eurprd03.prod.outlook.com (2603:10a6:800:136::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Fri, 19 Jun 2020 22:34:00 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3109.023; Fri, 19 Jun 2020 22:34:00 +0000 From: Volodymyr Babchuk To: "pdurrant@amazon.com" , "xen-devel@lists.xenproject.org" Subject: [PATCH v2 1/2] optee: immediately free buffers that are released by OP-TEE Thread-Topic: [PATCH v2 1/2] optee: immediately free buffers that are released by OP-TEE Thread-Index: AQHWRom6MCrom+3VqUO0pBfpeyeOQA== Date: Fri, 19 Jun 2020 22:33:59 +0000 Message-ID: <20200619223332.438344-2-volodymyr_babchuk@epam.com> References: <20200619223332.438344-1-volodymyr_babchuk@epam.com> In-Reply-To: <20200619223332.438344-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amazon.com; dkim=none (message not signed) header.d=none;amazon.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9a766f3-029b-4244-9a6b-08d814a0dc96 x-ms-traffictypediagnostic: VI1PR03MB6304: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3s00kgvd36aXVnXNv1pM4WjPlnjq6KbaB6WUF1EjThKZU+WNp40rkVFpMGBlRvPGNDVte75ke+kgoXUzTFkoZ/laYfRH4rkI0IJsrwF8S0QTqTo/m7nGFZltmcUwtmFrg+ylbYRd35jwZRcHIjkB60fUyeypqvc23ALzgTeS3pexZ2uqCbTfznlIJCZdKbd4FXZ/pS8OnsDYlTbhOoaRRUmrZg+KDe3HyLQ7loMrUw5SVlPCKWuNNczCoJAEyDS/LXs6jag/yWiqVB5GscGiHRb5Pbs6nMOTRfbhsJzI4qNEGfAQDsk06W6X0BKOH4+oTNLha6mZo6GqKmxa67yrQqrW3sSIFaqOvaoCc/DYAbYurJMpNavZJHxOCOwq3OQF x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(346002)(136003)(66946007)(66476007)(76116006)(91956017)(66556008)(64756008)(86362001)(5660300002)(66446008)(2616005)(4326008)(36756003)(6486002)(478600001)(71200400001)(2906002)(316002)(1076003)(186003)(54906003)(55236004)(8936002)(26005)(6506007)(110136005)(8676002)(83380400001)(6512007)(14773001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wxR7DXmKoBz8ZTNhFTMn6dPuhxfcsBdN3lIwI/bHb5vKI+u5CQH8ks/3TDCBXy6hCWoc9Zi0wD7ne5imNWWrhKZdzGXsE5jvezMOFMh1o5uD0ZzZ0H2hvBtLZf2gEjYCarOF36sFKrzfjHKJ6RNHxofdYB+pyBQBwqziGM8RPykbfO+PH0PJQAxKMKrRkDp0S9LjlurGXyqsEFTKEuRzCAodnmli394rqdjU8/BmDbHJloa4fbJ2YZW6sm9Zxe1QiYqj3E/r5+3SMwRfpLbAFyM0MzVsza5Hog47qFK42LJwNCW+RlHH0YI2U3yz9jH6MVF4lxv/R0l2xfBtQMAGz/d6AVwCTej9BIwZPjjWojXPubIG+GVBbJHA+/gI15SVEd51XtinbYs90/mQ5cxFlOet1+jfKMumB3HNjdixry804nSlkZF6pRolSYQwX+n6ej+w+ukbbmeGpvkcb72HyzZeSIn3Ohz9sljS9rTd2MQ= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9a766f3-029b-4244-9a6b-08d814a0dc96 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 22:33:59.9476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CSacZWdHnbH+p/pSxWQ6//OPfg7wUXmXw7Cfwm3R5H22nZl4Jv3aCnMS7t2XHWAQ2FpPNlvU3quzwRWVz0EEa9OOfmloRmHznVIu32yZYuU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6304 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , "op-tee@lists.trustedfirmware.org" , Volodymyr Babchuk , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Normal World can share buffer with OP-TEE for two reasons: 1. Some client application wants to exchange data with TA 2. OP-TEE asks for shared buffer for internal needs The second case was handle more strictly than necessary: 1. In RPC request OP-TEE asks for buffer 2. NW allocates buffer and provides it via RPC response 3. Xen pins pages and translates data 4. Xen provides buffer to OP-TEE 5. OP-TEE uses it 6. OP-TEE sends request to free the buffer 7. NW frees the buffer and sends the RPC response 8. Xen unpins pages and forgets about the buffer The problem is that Xen should forget about buffer in between stages 6 and 7. I.e. the right flow should be like this: 6. OP-TEE sends request to free the buffer 7. Xen unpins pages and forgets about the buffer 8. NW frees the buffer and sends the RPC response This is because OP-TEE internally frees the buffer before sending the "free SHM buffer" request. So we have no reason to hold reference for this buffer anymore. Moreover, in multiprocessor systems NW have time to reuse buffer cookie for another buffer. Xen complained about this and denied the new buffer registration. I have seen this issue while running tests on iMX SoC. So, this patch basically corrects that behavior by freeing the buffer earlier, when handling RPC return from OP-TEE. Signed-off-by: Volodymyr Babchuk --- Changes from v1: - reworded the comments - added WARN() for a case when OP-TEE wants to release not the buffer it requeset to allocate durint this call --- xen/arch/arm/tee/optee.c | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index 6a035355db..6963238056 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -1099,6 +1099,34 @@ static int handle_rpc_return(struct optee_domain *ct= x, if ( shm_rpc->xen_arg->cmd =3D=3D OPTEE_RPC_CMD_SHM_ALLOC ) call->rpc_buffer_type =3D shm_rpc->xen_arg->params[0].u.value.= a; =20 + /* + * OP-TEE is signalling that it has freed the buffer that it + * requested before. This is the right time for us to do the + * same. + */ + if ( shm_rpc->xen_arg->cmd =3D=3D OPTEE_RPC_CMD_SHM_FREE ) + { + uint64_t cookie =3D shm_rpc->xen_arg->params[0].u.value.b; + + free_optee_shm_buf(ctx, cookie); + + /* + * OP-TEE asks to free buffer, but this is not the same + * buffer we previously allocated for it. While nothing + * prevents OP-TEE from asking this, it is the strange + * situation. This may or may not be caused by a bug in + * OP-TEE or mediator. But is better to print warning. + */ + if ( call->rpc_data_cookie && call->rpc_data_cookie !=3D cooki= e ) + { + gprintk(XENLOG_ERR, + "Saved RPC cookie does not corresponds to OP-TEE's= (%"PRIx64" !=3D %"PRIx64")\n", + call->rpc_data_cookie, cookie); + + WARN(); + } + call->rpc_data_cookie =3D 0; + } unmap_domain_page(shm_rpc->xen_arg); } =20 @@ -1464,10 +1492,6 @@ static void handle_rpc_cmd(struct optee_domain *ctx,= struct cpu_user_regs *regs, } break; case OPTEE_RPC_CMD_SHM_FREE: - free_optee_shm_buf(ctx, shm_rpc->xen_arg->params[0].u.value.b)= ; - if ( call->rpc_data_cookie =3D=3D - shm_rpc->xen_arg->params[0].u.value.b ) - call->rpc_data_cookie =3D 0; break; default: break; --=20 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 22:34:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 22:34:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmPaG-0007TM-Bg; Fri, 19 Jun 2020 22:34:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmPaE-0007TH-Fj for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 22:34:02 +0000 X-Inumbo-ID: f72248c8-b27c-11ea-bc14-12813bfff9fa Received: from EUR02-VE1-obe.outbound.protection.outlook.com (unknown [40.107.2.83]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f72248c8-b27c-11ea-bc14-12813bfff9fa; Fri, 19 Jun 2020 22:33:58 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UF7llm1WkqnZ0l+BeFEgw7Cbrmzx0qEoO4K/Mjb1Cg7ALF2V8jQQsNprY4rugOIvzF3eRBBLRRppg+mNALphT/AH4qYpVOmFI21mvQObF/SCnEnUIJ/VAksA0Kex3O8DKBkc/1QrJ+oT/8Fw8gHVBUBL/84yyESIsv+8yeLS/BPvgv5wZkfNQ3SB0li1FNnn9z9zN1Yyf6Uc+Xu3lYf/Bn4ViwxgTSm5fNOMieTZjRTFqpSK/Bob6mhAu3MOVawJyjb7jCflZXbe5ZR+rMG6SU4OtBJDzt1fvCJyIzlkHf7ReEiLQEOq7i/x3MQP3VYNIOYfhL41z+jboJqBJFha1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1m/qnUjI/zR2Dk1NrXmpLkzO7PmIHROqTQgtwyhxXcE=; b=NwoYfgER4lSZBqUqaguMOzakgzA+t2SmS1/WiZ1UhoCJv/PvPSHTcZC5RH9luNujhWD2BYvbV/JOu1VYFwr67JQViDHdNyp0begNQ4m8uv3jHtPYGLMabC+1wEwJ9Rkh+o/w7TrR18rwF5O+OQBauWN69aQTUueOBJnqrgGhbYmqYFV5ZYZy36HEEu5DpkZ51JKxM0EtxgM9/c8e0NRZUwZO2kUWSO8UpPXKqGGsGkcjqnMA95Y8VwIyCVF69AApwN9wzXiXwesJ1jKfC4nXZEKMxIt4zFRcuTwnMW8x3AeOEqAz/SI4odmwt4ekoFOfphdd8DQ0Rrg5djsj6xhntg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1m/qnUjI/zR2Dk1NrXmpLkzO7PmIHROqTQgtwyhxXcE=; b=wC7lQCDBv8A7j4Gnqi0Y78c6sImW770/UAWLMiFk+Ls1sp/t+ettR7jngChpeRFjyI4djCM773mjqUEyJrT9bVbuSyErzow84FmCSgT/D9VGKGITNHtL0U08K41bD9BGZSy6cyugOTpS/TniIuPbmMgxcp3mjPSpqlnETCYJpYKq+BWmmi5bavVIOvkQiNak0vKvOdJtuj/V0B1csQ/l5SjrJKrPhh+iDGqtLEtiRy1KqGggJM1p/Gh3R0VfTQybtSEQhuRaxsTFStA/m+Gb4wXMGFeCAFivtDNZp5wobBL2NKgdz5ofWibXtFyItk29dlc1IHVlDPTyNSr0ckdqoQ== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB6304.eurprd03.prod.outlook.com (2603:10a6:800:136::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Fri, 19 Jun 2020 22:33:55 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3109.023; Fri, 19 Jun 2020 22:33:55 +0000 From: Volodymyr Babchuk To: "pdurrant@amazon.com" , "xen-devel@lists.xenproject.org" Subject: [PATCH v2 0/2] optee: SHM handling fixes Thread-Topic: [PATCH v2 0/2] optee: SHM handling fixes Thread-Index: AQHWRom3ZYG+JNafjk+6b4hYNOXtgw== Date: Fri, 19 Jun 2020 22:33:55 +0000 Message-ID: <20200619223332.438344-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amazon.com; dkim=none (message not signed) header.d=none;amazon.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06b4d038-271b-41f4-8130-08d814a0d9fa x-ms-traffictypediagnostic: VI1PR03MB6304: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2Dl+wINLZebK0+lGwRD60FQpuH7//LxpZtSqJMB4ukFzKgBRd812/qI9YpptTfFT2hO8PAhiN+ZWUbJ7tIevHvum9474xnDyX3QxQTLk5d89LkYBPYDJvZPp4KyQ42qSytNHV1bE2Vd/2DXFQljhL8Gl0fK5Ij1jqjxN40XIRYsL2TS3pTmCrMZy2i3EANQ8riHzDr5q2swK6NhO+ei/Up/hB2ectFbzDUP/XVF0C6+Y78oQXWBKHNI3xvVqPhK0WHnG4fPECyBN+Mi6k61fducHRTPum3lbJV5ZKBwhKXtSgzovqgnAdWZ4Ng9vXwj1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(346002)(136003)(66946007)(66476007)(76116006)(91956017)(66556008)(64756008)(86362001)(5660300002)(66446008)(2616005)(4326008)(36756003)(6486002)(478600001)(71200400001)(4744005)(2906002)(316002)(1076003)(186003)(54906003)(55236004)(8936002)(26005)(6506007)(110136005)(8676002)(83380400001)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ie6HgA07Il1Jxz06XWxcXJO5tkoOAksAaF/mFNzRAO0iFi0OaM+dctRZmFUQmvw7PSU2ZVjahQyJCjjXCSYNl6CsnrBG2EzlhznO3q2/S/CFtjOZgCeoWX8W/Gsnb+egD64pgBlKbeCd7XMuYizlPqqp9e/Q5W8Caa7l6sZ+lDSYWVqSl185chC2Jd3BBD5HBOmEBbwZ0HmhStjTRAkghQ/ddR41EquovaPfeBb8jlq6HcQawkxLwTOl9NSdAmMRzh636oVr1DmAWRjMbVLYj7IFso8FfwXyRKrl7IXh+djl48hLMNW+ZXwSkCwqnPTa5DbKOPalyS1rNSgTEgM9Hi9V7SbmAGWqCaktkShmcYl59YcCh9h+RZrtI2jWyhOsSX7rDhWOhTtd7y7tlrjGp/+YrCHgnKm9iBWjWTx7iu+miM9pBNq8jN9nyyKhWAbsTSlxAqCDI71ewp/BkTw4lhLqj8MoycmVjbqs5D2EPN0= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06b4d038-271b-41f4-8130-08d814a0d9fa X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 22:33:55.6491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1yXNtDaX35/OR9ThAQKEl3O16dD9YHm4t+P8s25CQ/u79UeNcC6vQEWIuCNIzi9QEuCeRgoxxa0cmoNTwgTQ22RzDOxkyjTMtwiusocaedI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6304 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , "op-tee@lists.trustedfirmware.org" , Volodymyr Babchuk , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" There are two patches that previously was mailed separatedly. Both patches fix issues found during testing the OP-TEE 3.9 release. Julien and Stefano suggested to include this patches in Xen 4.14 release, because optee support still in the preview state and those patches provide no new functionality, bugfixes only. Volodymyr Babchuk (2): optee: immediately free buffers that are released by OP-TEE optee: allow plain TMEM buffers with NULL address xen/arch/arm/tee/optee.c | 59 +++++++++++++++++++++++++++++++++++----- 1 file changed, 52 insertions(+), 7 deletions(-) --=20 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 22:34:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 22:34:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmPaQ-0007Ul-0G; Fri, 19 Jun 2020 22:34:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmPaO-0007TH-BP for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 22:34:12 +0000 X-Inumbo-ID: f9b03fd3-b27c-11ea-bc14-12813bfff9fa Received: from EUR02-VE1-obe.outbound.protection.outlook.com (unknown [40.107.2.83]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f9b03fd3-b27c-11ea-bc14-12813bfff9fa; Fri, 19 Jun 2020 22:34:03 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Thtc1tGbhDltbnVamDKC92aY1/I3rkoDIjA87DehlksUcANdDogo2z3CY4PgBpWsaDOVV2nlNlDtyvM/enk9G3NJNEukvOjjCrr9lxz/JuAozxcw6Q85VfP0N3vO6TQE8gXrpEsvo+KwbtiVwjPTTVyBUQ0xTsWd78xqb86J+U1w9+90R/9wh62hwEmGbTdQnwhjmCx8avHhg4kGleHDl9+RdeHZCoxlaj4Fq53mCnzCSgPyRVn/lIruFA1OtdNAB2ANXojzQ7UeDw01rPsVHYuX6FzPCFryUgGmBVSDvJw+pQ46Zpjcs+MhLYJDi5Nf4w3V6Tekbm8jP9u7m+cKFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VAnBWq8tWHxmxrR1Lhikfu3J6pxcgll70UUIJjlkUNM=; b=TJGbMikEq95GYRQb91V6rPTatVIPels3MHmf751eDP+ATxdMG1qFsIxCYGl9BlvmBk2fyth31HrERTvPP2VXKTWIr9aJEwnpj5Gkc36/P9BUJcc3XYgUDEqVu0HIwvv7/6V7UCAEakQ4xtdI2fCZJCTZhec6xQnEQBJLVKQ3QUI/kC2nauerK5VhOhFF+kyI9sDzxsKYBo8sYP13qXdeaSbIgKakYaY/WkozNi6AWZnr4L9Sf41XkV/7pC4cafg0UjlvMN9hc25yKRaPb1j+IRcmf3bMbSi2FMHlUj7MPZKXFqFJeivK1qlp+pkW8F0Pob+3ra/OS2H6gyfb8dJpDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VAnBWq8tWHxmxrR1Lhikfu3J6pxcgll70UUIJjlkUNM=; b=FfMfZRLaOViq3yFscyeWC1EpOuo+ZvjWs5vxxFDnrZqB5jMtA5z6FHANIW6d00nu32qQYyjA9Up1GeRivmhXmfhjcXGwFeAm9Ap+SCxUZdQzHPd9vR+izbFU16voSa6R8uNFrCboGYmKTE7NGIsGcrHoWA1maUo669iaaYe/2/waQWhcRxzPcE3t6adY3LpNS8X681vhAomalFI5vW9w0CIb8JstZ7OD/3IrQHuACvF/+lxTqZd0ykdlKSpcSnM21juNL2+IXOQopqp/hK37o9B0RSBmtHypSG70CWrKh/2yIkKG/JUyjjOW1CANei8JotbhRnEv+uXcnKE3ZEMR7w== Received: from VI1PR03MB2926.eurprd03.prod.outlook.com (2603:10a6:802:35::28) by VI1PR03MB6304.eurprd03.prod.outlook.com (2603:10a6:800:136::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Fri, 19 Jun 2020 22:34:01 +0000 Received: from VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37]) by VI1PR03MB2926.eurprd03.prod.outlook.com ([fe80::95fd:55d9:421b:1f37%7]) with mapi id 15.20.3109.023; Fri, 19 Jun 2020 22:34:01 +0000 From: Volodymyr Babchuk To: "pdurrant@amazon.com" , "xen-devel@lists.xenproject.org" Subject: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address Thread-Topic: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address Thread-Index: AQHWRom6aQ+ko86LqESb88QJVYc4LQ== Date: Fri, 19 Jun 2020 22:34:01 +0000 Message-ID: <20200619223332.438344-3-volodymyr_babchuk@epam.com> References: <20200619223332.438344-1-volodymyr_babchuk@epam.com> In-Reply-To: <20200619223332.438344-1-volodymyr_babchuk@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: amazon.com; dkim=none (message not signed) header.d=none;amazon.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b8d71259-a699-47b1-9fec-08d814a0dd39 x-ms-traffictypediagnostic: VI1PR03MB6304: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2331; x-forefront-prvs: 0439571D1D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PHhC2yX5B7fEWI6Ricbea9m75Dsjg60RlMMS+wmPGODdma5GXn0ez9lOpKap5TiTmqZl8vgh5bi6wM12ZJCkiP3KOlH1WJMoprAy+zFXIphrymPSrTuXpBSMGIQdzOkXR3IkFy9jWfUH1F6ZUeIiK/5UEUlHr++RwNsvl8c+Bi6MJCnNPqN3RxzyrzevVd4QHP0DXhkPPOWtMK5ed12ensuy4qLtkrn08wq4ycfXzrPbLwiRowXjUiTPZrgY8d8ZBJwABnQlBR7aINx4mk22Un416c+6eBgp0oXy08Y8T7GGgP/gzOakwo1bT1tOrJ2EWOpVsMh+IxhDNVVVCGfBqQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB2926.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(39860400002)(346002)(136003)(66946007)(66476007)(76116006)(91956017)(66556008)(64756008)(86362001)(5660300002)(66446008)(2616005)(4326008)(36756003)(6486002)(478600001)(71200400001)(2906002)(316002)(1076003)(186003)(54906003)(55236004)(8936002)(26005)(6506007)(110136005)(8676002)(83380400001)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EwgVDIyclKS2zfZGbyPhO9kQsSSDKdcU5WY3daFNe9BFSxPJ5zjjb10DKudo0vI2ZIggzUkfBEGK1rqRgbaFNzgS6eBszPpa5TlPnGEZVjp53AOYNZ3TONTuuLfNEV5DSne/JICl2H092iiVGYlNZlQ1InceqC2l4goTaiCwOk9OhrBgxTG2WPS61ebq2lbPCG44+F4T1iQ5NTCE1yXkEdlZdAjaskvkZJ5oVw1lLNrCMjtbvF6J3Ng7oI6kibhuUr0SPAFLtEUUB/cY+JHwxWtNnBJ3IliDT4Lzmy1qB8wm39y0dsOmvvSxaFxWNrW7R5suLZaIO0c58GOf+qZ3jd1DHx7ldNyqbeh7js1U7OmWMkiv/iFDnJjJoRKtWS4/3l0MP8/wS3ylQOyqLgqUPy7FjtcTJpm7UtEG6ecU6tXS5XO+3zx3wjg0Re4efROwnSxAZOidO1SCSsv5oFyb4ilu1sBG72VGFU7v1P5L5Aw= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8d71259-a699-47b1-9fec-08d814a0dd39 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 22:34:01.0430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RxxPRC6aYy/lrCpOvMPuQ8FxXvzo2YG78KqOoXInMFU1DyDGOu5EvlxyhqC78EZavTEE7iUA1nIuX5Fele7IKhw9YoS5BN7X7ZFFYvXvisc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6304 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , "op-tee@lists.trustedfirmware.org" , Volodymyr Babchuk , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Trusted Applications use popular approach to determine required size of buffer: client provides a memory reference with the NULL pointer to a buffer. This is so called "Null memory reference". TA updates the reference with the required size and returns it back to the client. Then client allocates buffer of needed size and repeats the operation. This behavior is described in TEE Client API Specification, paragraph 3.2.5. Memory References. OP-TEE represents this null memory reference as a TMEM parameter with buf_ptr =3D 0x0. This is the only case when we should allow TMEM buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. This also the special case for a buffer with OPTEE_MSG_ATTR_NONCONTIG flag. This could lead to a potential issue, because IPA 0x0 is a valid address, but OP-TEE will treat it as a special case. So, care should be taken when construction OP-TEE enabled guest to make sure that such guest have no memory at IPA 0x0 and none of its memory is mapped at PA 0x0. Signed-off-by: Volodymyr Babchuk --- Changes from v1: - Added comment with TODO about possible PA/IPA 0x0 issue - The same is described in the commit message - Added check in translate_noncontig() for the NULL ptr buffer --- xen/arch/arm/tee/optee.c | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c index 6963238056..70bfef7e5f 100644 --- a/xen/arch/arm/tee/optee.c +++ b/xen/arch/arm/tee/optee.c @@ -215,6 +215,15 @@ static bool optee_probe(void) return true; } =20 +/* + * TODO: There is a potential issue with guests that either have RAM + * at IPA of 0x0 or some of theirs memory is mapped at PA 0x0. This is + * because PA of 0x0 is considered as NULL pointer by OP-TEE. It will + * not be able to map buffer with such pointer to TA address space, or + * use such buffer for communication with the guest. We either need to + * check that guest have no such mappings or ensure that OP-TEE + * enabled guest will not be created with such mappings. + */ static int optee_domain_init(struct domain *d) { struct arm_smccc_res resp; @@ -725,6 +734,15 @@ static int translate_noncontig(struct optee_domain *ct= x, uint64_t next_page_data; } *guest_data, *xen_data; =20 + /* + * Special case: buffer with buf_ptr =3D=3D 0x0 is considered as NULL + * pointer by OP-TEE. No translation is needed. This can lead to + * an issue as IPA 0x0 is a valid address for Xen. See the comment + * near optee_domain_init() + */ + if ( !param->u.tmem.buf_ptr ) + return 0; + /* Offset of user buffer withing OPTEE_MSG_NONCONTIG_PAGE_SIZE-sized p= age */ offset =3D param->u.tmem.buf_ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1)= ; =20 @@ -865,9 +883,12 @@ static int translate_params(struct optee_domain *ctx, } else { - gdprintk(XENLOG_WARNING, "Guest tries to use old tmem arg\= n"); - ret =3D -EINVAL; - goto out; + if ( call->xen_arg->params[i].u.tmem.buf_ptr ) + { + gdprintk(XENLOG_WARNING, "Guest tries to use old tmem = arg\n"); + ret =3D -EINVAL; + goto out; + } } break; case OPTEE_MSG_ATTR_TYPE_NONE: --=20 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 19 23:23:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 23:23:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmQLq-0003VX-Su; Fri, 19 Jun 2020 23:23:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmQLq-0003VS-6m for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 23:23:14 +0000 X-Inumbo-ID: d8445b6a-b283-11ea-bc21-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d8445b6a-b283-11ea-bc21-12813bfff9fa; Fri, 19 Jun 2020 23:23:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0sO+Uba5QuiVqmFCiYs//CMhQp+LgBdEf++/PVhAT5c=; b=okkosn28gOtlINwKZ32ii3QW8 S8857eso8G3MYJ0TGOK0CqoOrRaEXqrdh0XVXElC+T7Zeu1wJxZ2+RMeFF61PGz8D+gr4uMwptnou qbavjwlSSpExQumJCJPheDXRDL0E3yRw5q4IQMoDBEc2igzbDHVAkryW8xoCq3gR7W5dc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmQLo-0002Wd-BK; Fri, 19 Jun 2020 23:23:12 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmQLn-00076J-SF; Fri, 19 Jun 2020 23:23:11 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmQLn-0000zx-RP; Fri, 19 Jun 2020 23:23:11 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151237: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=fde76f895d0aa817a1207d844d793239c6639bc6 X-Osstest-Versions-That: xen=b67e859d0823f5b450e29379af9142d44a3ea370 From: osstest service owner Date: Fri, 19 Jun 2020 23:23:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151237 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151237/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen fde76f895d0aa817a1207d844d793239c6639bc6 baseline version: xen b67e859d0823f5b450e29379af9142d44a3ea370 Last test of basis 151235 2020-06-19 14:00:30 Z 0 days Testing same since 151237 2020-06-19 20:00:46 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ian Jackson jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git b67e859d08..fde76f895d fde76f895d0aa817a1207d844d793239c6639bc6 -> smoke From xen-devel-bounces@lists.xenproject.org Fri Jun 19 23:43:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 19 Jun 2020 23:43:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmQfO-0005Hj-Ft; Fri, 19 Jun 2020 23:43:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmQfN-0005Gz-RK for xen-devel@lists.xenproject.org; Fri, 19 Jun 2020 23:43:25 +0000 X-Inumbo-ID: aaf33764-b286-11ea-bc28-12813bfff9fa Received: from smtp-fw-4101.amazon.com (unknown [72.21.198.25]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id aaf33764-b286-11ea-bc28-12813bfff9fa; Fri, 19 Jun 2020 23:43:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1592610205; x=1624146205; h=date:from:to:cc:message-id:references:mime-version: content-transfer-encoding:in-reply-to:subject; bh=SWB6zi6dk7H1UFvBjGxqa8Wz12tvOQnfaL06ZbePiho=; b=b/IjkLlvSKGQXcP1y4JWse3VifWK3OmRE60eon8K784R+TY7SxGIGTlt L5Y+0uc1TCnDsVxb5Ujfj2tiqLeiF+YkZ/fp6CJYYAZIR7kkBvz8CXS6t 9G7/5bcceO+aG7Xb/taqJY2TRf34V4R/3fmwPRnSGqC6ZnQhwu9pZWnUC 8=; IronPort-SDR: V0SG/zvLllpjNx79VHvm2vDaL3yuY6Sm12ogn2cv5SkcExVpFNIj0wUosu91G3vrCbL2gp8Rph pcBrxyqWaheg== X-IronPort-AV: E=Sophos;i="5.75,256,1589241600"; d="scan'208";a="37314133" Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2a-53356bf6.us-west-2.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 19 Jun 2020 23:43:22 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2a-53356bf6.us-west-2.amazon.com (Postfix) with ESMTPS id 46E48A1ECE; Fri, 19 Jun 2020 23:43:20 +0000 (UTC) Received: from EX13D05UWB003.ant.amazon.com (10.43.161.26) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 23:43:12 +0000 Received: from EX13MTAUWB001.ant.amazon.com (10.43.161.207) by EX13D05UWB003.ant.amazon.com (10.43.161.26) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 19 Jun 2020 23:43:11 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.161.249) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Fri, 19 Jun 2020 23:43:11 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 1C38F40384; Fri, 19 Jun 2020 23:43:12 +0000 (UTC) Date: Fri, 19 Jun 2020 23:43:12 +0000 From: Anchal Agarwal To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20200619234312.GA24846@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200617083528.GW735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200617083528.GW735@Air-de-Roger> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monn wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monn wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > > + "the device may become inconsistent state"); > > > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > > state and with the queues frozen. You should make an attempt to > > > > restore things to a working state. > > > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > > > You can manually force this state, and then check that it will behave > > > correctly. I would expect that on a failure to disconnect from the > > > backend you should switch the frontend to the 'Init' state in order to > > > try to reconnect to the backend when possible. > > > > > From what I understand forcing manually is, failing the freeze without > > disconnect and try to revive the connection by unfreezing the > > queues->reconnecting to backend [which never got diconnected]. May be even > > tearing down things manually because I am not sure what state will frontend > > see if backend fails to to disconnect at any point in time. I assumed connected. > > Then again if its "CONNECTED" I may not need to tear down everything and start > > from Initialising state because that may not work. > > > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > > I don't see it getting handled in the backend then what will be backend's state? > > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > > if it tries to read backend's state through xenbus_read_driver_state ? > > > > So the flow be like: > > Front end marks XenbusStateClosing > > Backend marks its state as XenbusStateClosing > > Frontend marks XenbusStateClosed > > Backend disconnects calls xen_blkif_disconnect > > Backend fails to disconnect, the above function returns EBUSY > > What will be state of backend here? > > Backend should stay in state 'Closing' then, until it can finish > tearing down. > It disconnects the ring after switching to connected state too. > > Frontend did not tear down the rings if backend does not switches the > > state to 'Closed' in case of failure. > > > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend > > Backend will stay in state 'Closing' I think. > > > won't be calling connect(). {From reading code in frontend_changed} > > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > > we did not tear down anything so calling talk_to_blkback may not be needed > > > > Does that sound correct? > > I think switching to the initial state in order to try to attempt a > reconnection would be our best bet here. > It does not seems to work correctly, I get hung tasks all over and all the requests to filesystem gets stuck. Backend does shows the state as connected after xenbus_dev_suspend fails but I think there may be something missing. I don't seem to get IO interrupts thereafter i.e hitting the function blkif_interrupts. I think just marking it initialised may not be the only thing. Here is a short description of what I am trying to do: So, on timeout: Switch XenBusState to "Initialized" unquiesce/unfreeze the queues and return mark info->connected = BLKIF_STATE_CONNECTED return EBUSY I even allowed blkfront_connect to switch state to "CONNECTED" rather me doing it explicitly as mentioned above without re-allocating/re-registering the device just to make sure bklfront_info object has all the right values. Do you see anythign missing here? Also, while wrapping my brain around this recovery, one of the reasons I see backend may not disconnct is if there are inflight I/O requests. There cannot be pending I/O on shared ring because that check is already there before we switch bus state to Closing. Also, queues are frozen so there will be no new I/O. The only situation I can think of is since there too much of memory state to be written and modified that may not get completed within the timeout provided and disconnect may fail. In that case, the time out needs to be configurable by the user since the hibernation may always fail depending on infrastructure or workload running during hibernation. Thanks, Anchal From xen-devel-bounces@lists.xenproject.org Sat Jun 20 00:53:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jun 2020 00:53:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmRkb-0003Mp-Ic; Sat, 20 Jun 2020 00:52:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmRkZ-0003Mk-CD for xen-devel@lists.xenproject.org; Sat, 20 Jun 2020 00:52:51 +0000 X-Inumbo-ID: 5d2597d4-b290-11ea-bc2f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5d2597d4-b290-11ea-bc2f-12813bfff9fa; Sat, 20 Jun 2020 00:52:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zV9TJPqXYCOFY45aOuepEqDW2AUDvgJn/ivrdXoqbuw=; b=xtJmnaj2oCBaFmcASmvHqtb/T D+9isnR7HVwRTJalsoF1qOMh7oWLIrYeIbTM6cg22lzdkXWmILxXq+U9vFQc5lHn1Bsu5s6M9FSF2 7tNFUOhNQ4xXHvcLRsrZNERJ12WkujQRr1rqpLQkRRWo0OKR4vFwiGW0apzm8Aj2I3ou0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmRkX-0004jE-3C; Sat, 20 Jun 2020 00:52:49 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmRkW-0003T4-Fy; Sat, 20 Jun 2020 00:52:48 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmRkW-0008G7-F1; Sat, 20 Jun 2020 00:52:48 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.9-testing test] 151223: tolerable trouble: fail/pass/starved - PUSHED X-Osstest-Failures: xen-4.9-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-localmigrate/x10:fail:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-localmigrate/x10:fail:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-localmigrate/x10:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-4.9-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-localmigrate/x10:fail:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-localmigrate/x10:fail:nonblocking xen-4.9-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.9-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.9-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.9-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=6e477c2ea4d5c26a7a7b2f850166aa79edc5225c X-Osstest-Versions-That: xen=93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 From: osstest service owner Date: Sat, 20 Jun 2020 00:52:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151223 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151223/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 150068 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 150068 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 150085 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 150085 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 150102 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 150102 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150120 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 150120 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150120 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c baseline version: xen 93cc305d1f3e7c6949a8f4116446624fa2dbfdf4 Last test of basis 150120 2020-05-10 02:18:09 Z 40 days Failing since 150940 2020-06-09 17:05:20 Z 10 days 12 attempts Testing same since 151070 2020-06-13 06:57:26 Z 6 days 6 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Ian Jackson John Thomson Julien Grall Marek Marczykowski-Górecki Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 93cc305d1f..6e477c2ea4 6e477c2ea4d5c26a7a7b2f850166aa79edc5225c -> stable-4.9 From xen-devel-bounces@lists.xenproject.org Sat Jun 20 01:33:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jun 2020 01:33:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmSNu-00088g-D6; Sat, 20 Jun 2020 01:33:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmSNt-00087f-6L for xen-devel@lists.xenproject.org; Sat, 20 Jun 2020 01:33:29 +0000 X-Inumbo-ID: 06fbc42c-b296-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 06fbc42c-b296-11ea-b7bb-bc764e2007e4; Sat, 20 Jun 2020 01:33:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=B5jAGTU8ZKKxhdNI7oR+15faKd7hSwkX+X0NF60dJAw=; b=o/NhBN/NKSW1cMOZ6APJ96B1D ZHxzZ2wm37FQhk7Ia0EIG/MCAzXKmblkD02oO6pqmNAHw2jeAekt/rOXYRLnJiPoQ1OGn0HsDIKiO 19SSqkemsXAbb0EylYgUpUo7HV9edXVYflHGWlu7cWyqyJeDRzkJBjHMgbrNeWCuk1o+g=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmSNl-0006rJ-9S; Sat, 20 Jun 2020 01:33:21 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmSNk-000553-Pc; Sat, 20 Jun 2020 01:33:20 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmSNk-0007kZ-Mp; Sat, 20 Jun 2020 01:33:20 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151221: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=26bf4a29213b432eb390726c698a1915550a9cf9 X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Sat, 20 Jun 2020 01:33:20 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151221 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151221/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151065 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass version targeted for testing: qemuu 26bf4a29213b432eb390726c698a1915550a9cf9 baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 7 days Failing since 151101 2020-06-14 08:32:51 Z 5 days 4 attempts Testing same since 151221 2020-06-18 10:10:21 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Anthony PERARD Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Cathy Zhang Claudio Fontana Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Carlier David Gibson Edgar E. Iglesias Emilio G. Cota Eric Auger Erik Smit Evgeny Yakovlev fangying Gerd Hoffmann Guenter Roeck Igor Mammedov Janne Grunau Jean-Christophe Dubois Jiaxun Yang Jon Doron Joseph Myers Julio Faracco Laurent Vivier Leonid Bloch Leonid Bloch Like Xu Lingfeng Yang Liran Alon Maciej S. Szmigiero Magnus Damm Marek Marczykowski-Górecki Markus Armbruster Masahiro Yamada Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Stefan Berger Thomas Huth WangBowen Wei Huang Ying Fang Yoshinori Sato jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6268 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 20 06:43:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jun 2020 06:43:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmXDf-0001Ii-0H; Sat, 20 Jun 2020 06:43:15 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmXDe-0001Id-4X for xen-devel@lists.xenproject.org; Sat, 20 Jun 2020 06:43:14 +0000 X-Inumbo-ID: 4dddf0ba-b2c1-11ea-bc4b-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4dddf0ba-b2c1-11ea-bc4b-12813bfff9fa; Sat, 20 Jun 2020 06:43:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hmW3VeEuR26357pFMDbJpgKGvADQBW/+Bpmtw48Lxis=; b=Xk4pMfx17iau552ZQkESVoFjg n/P6AerloIYF6fStDqjOyPmTJHoLijtIxT+KMGECY9suU+/1G9FjRLgQJ0PV2q9+dg2fFUSnIGmwT 21fHbjr8+DIrfWPcDgFXQ5BCXb6QKBa23QoF5cgGRK7WH3rmKUp7QwZ+Sx34lST8Pf03s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmXDY-0005FO-Ui; Sat, 20 Jun 2020 06:43:08 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmXDY-0005mH-PI; Sat, 20 Jun 2020 06:43:08 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmXDY-0007fT-Oe; Sat, 20 Jun 2020 06:43:08 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151224: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=71ca0e0ad000e690899936327eb09709ab182ade X-Osstest-Versions-That: xen=3625b04991b4d6affadd99d377ab84bac48dfff4 From: osstest service owner Date: Sat, 20 Jun 2020 06:43:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151224 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151224/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151181 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151181 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151181 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151181 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151181 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151181 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151181 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151181 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 71ca0e0ad000e690899936327eb09709ab182ade baseline version: xen 3625b04991b4d6affadd99d377ab84bac48dfff4 Last test of basis 151181 2020-06-17 06:01:52 Z 3 days Testing same since 151224 2020-06-18 16:01:07 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Ian Jackson jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 71ca0e0ad000e690899936327eb09709ab182ade Author: Andrew Cooper Date: Fri Jun 12 13:39:13 2020 +0100 x86/spec-ctrl: Hide RDRAND by default on IvyBridge client To combat the absence of mitigating microcode, arrange to hide RDRAND by default on IvyBridge client hardware. Adjust the default feature derivation to hide RDRAND on IvyBridge client parts, unless `cpuid=rdrand` is explicitly provided. Adjust the restore path in xc_cpuid_apply_policy() to not hide RDRAND from VMs which migrated from pre-4.14. In all cases, individual guests can continue using RDRAND if explicitly enabled in their config files. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Ian Jackson Release-acked-by: Paul Durrant commit fde4acd5feb7961269a2e6edd918c7a46626cf6b Author: Andrew Cooper Date: Mon Jun 15 13:42:11 2020 +0100 x86/cpuid: Introduce missing feature adjustment in calculate_pv_def_policy() This was an accidental asymmetry with the HVM side. No change in behaviour at this point. Fixes: 83b387382 ("x86/cpuid: Introduce and use default CPUID policies") Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Release-acked-by: Paul Durrant commit 54463aa79dac70a9d92f55650c7b8fe3e9fcc967 Author: Andrew Cooper Date: Mon Feb 24 17:15:56 2020 +0000 x86/hvm: Disable MPX by default Memory Protection eXtension support has been dropped from GCC and Linux, and will be dropped from future Intel CPUs. With all other default/max pieces in place, move MPX from default to max. This means that VMs won't be offered it by default, but can explicitly opt into using it via cpuid="host,mpx=1" in their vm.cfg file. The difference as visible to the guest is: diff --git a/default b/mpx index 0e91765d6b..c8c33cd584 100644 --- a/default +++ b/mpx @@ -13,15 +13,17 @@ Native cpuid: 00000004:00000004 -> 00000000:00000000:00000000:00000000 00000005:ffffffff -> 00000000:00000000:00000000:00000000 00000006:ffffffff -> 00000000:00000000:00000000:00000000 - 00000007:00000000 -> 00000000:009c2fbb:00000000:9c000400 + 00000007:00000000 -> 00000000:009c6fbb:00000000:9c000400 00000008:ffffffff -> 00000000:00000000:00000000:00000000 00000009:ffffffff -> 00000000:00000000:00000000:00000000 0000000a:ffffffff -> 00000000:00000000:00000000:00000000 0000000b:ffffffff -> 00000000:00000000:00000000:00000000 0000000c:ffffffff -> 00000000:00000000:00000000:00000000 - 0000000d:00000000 -> 00000007:00000240:00000340:00000000 + 0000000d:00000000 -> 0000001f:00000240:00000440:00000000 0000000d:00000001 -> 0000000f:00000240:00000000:00000000 0000000d:00000002 -> 00000100:00000240:00000000:00000000 + 0000000d:00000003 -> 00000040:000003c0:00000000:00000000 + 0000000d:00000004 -> 00000040:00000400:00000000:00000000 40000000:ffffffff -> 40000005:566e6558:65584d4d:4d4d566e 40000001:ffffffff -> 0004000e:00000000:00000000:00000000 40000002:ffffffff -> 00000001:40000000:00000000:00000000 Adjust the legacy restore path in libxc to cope safely with pre-4.14 VMs. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Ian Jackson Release-acked-by: Paul Durrant commit 1accd92514f286c44e76f198f1bba90ad2e9e83b Author: Andrew Cooper Date: Tue Feb 25 15:33:31 2020 +0000 x86/gen-cpuid: Distinguish default vs max in feature annotations The toolstack logic can now correctly distinguish a clean boot from a migrate/restore. Allow lowercase a/s/h to be used to annotate a non-default feature. Due to the emulator work prepared earlier in 4.14, this now allows VMs to explicity opt in to the TSXLDTRK, MOVDIR{I,64B} and SERIALIZE instructions via their xl.cfg file, rather than getting them as a matter of default. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Release-acked-by: Paul Durrant commit 057012d2899e4e71e274f77fcab136b0cad23099 Author: Andrew Cooper Date: Fri Jun 12 14:07:10 2020 +0100 tools/libx[cl]: Plumb bool restore down into xc_cpuid_apply_policy() In order to safely disable some features by default, without breaking migration from 4.13 or older, the CPUID logic needs to distinguish the two cases. Plumb a restore boolean down from the two callers of libxl__cpuid_legacy() all the way down into xc_cpuid_apply_policy(). No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson Release-acked-by: Paul Durrant commit f79cd47cd7a2ea321a0fe7d46586bdbea4845cdd Author: Andrew Cooper Date: Fri Jun 12 14:07:10 2020 +0100 tools/libx[cl]: Merge xc_cpuid_set() into xc_cpuid_apply_policy() This reduces the number of CPUID handling entry-points to just one. No functional change. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson Release-acked-by: Paul Durrant commit 585c7f4317987b4e92a381d6178be238be4c9653 Author: Andrew Cooper Date: Fri Jun 12 14:07:10 2020 +0100 tools/libx[cl]: Move processing loop down into xc_cpuid_set() Currently, libxl__cpuid_legacy() passes each element of the policy list to xc_cpuid_set() individually. This is wasteful both in terms of the number of hypercalls made, and the quantity of repeated merging/auditing work performed by Xen. Move the loop processing down into xc_cpuid_set(), which allows us to do one set of hypercalls, rather than one per list entry. In xc_cpuid_set(), obtain the full host, guest max and current policies to begin with, and loop over the xend array, processing one leaf at a time. Replace the linear search with a binary search, seeing as the serialised leaves are sorted. No change in behaviour from the guests point of view. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Ian Jackson Release-acked-by: Paul Durrant commit c22ced93e167f56104111fcc414298c0cd2db3e9 Author: Andrew Cooper Date: Fri Jun 12 16:48:02 2020 +0100 tests/cpu-policy: Confirm that CPUID serialisation is sorted The existing x86_cpuid_copy_to_buffer() does produce sorted results, and we're about to start relying on this. Extend the unit tests. As test_cpuid_serialise_success() is a fairly limited set of synthetic examples right now, introduce test_cpuid_current() to operate on the full policy for the current CPU. Tweak the fail() macro to allow for simplified control flow. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson Reviewed-by: Jan Beulich Release-acked-by: Paul Durrant commit 700738bf6a7a89a1b41cc783ae58f7c8ec1e9cfa Author: Andrew Cooper Date: Fri Jun 12 14:05:44 2020 +0100 tools/libx[cl]: Introduce struct xc_xend_cpuid for xc_cpuid_set() In order to combine the functionality of xc_cpuid_set() with xc_cpuid_apply_policy(), arrange to pass the data in a single contained struct, rather than two arrays. libxl__cpuid_policy is the ideal structure to use, but that would introduce a reverse dependency between libxc and libxl. Introduce xc_xend_cpuid (with a transparent union to provide more useful names for the inputs), and use this structure in libxl. The public API has libxl_cpuid_policy as an opaque type referencing libxl__cpuid_policy. Drop the inappropriate comment about its internals, and use xc_xend_cpuid as a differently named opaque backing object. Users of both libxl and libxc are not permitted to look at the internals. No change in behaviour. Signed-off-by: Andrew Cooper Acked-by: Ian Jackson Release-acked-by: Paul Durrant (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sat Jun 20 09:16:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jun 2020 09:16:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmZbd-0006AZ-1S; Sat, 20 Jun 2020 09:16:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmZbc-0006AU-2y for xen-devel@lists.xenproject.org; Sat, 20 Jun 2020 09:16:08 +0000 X-Inumbo-ID: aa9c7a8c-b2d6-11ea-bc69-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id aa9c7a8c-b2d6-11ea-bc69-12813bfff9fa; Sat, 20 Jun 2020 09:16:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cveiZ8HvDqii2AC8U4dKVHEFlbl746xN5aAIDcoPg44=; b=ONttQkmQ0PTrKRIe9kQdT+84b bNzGmXCR9safrJdA9vCKEH6T717qOYmM6l12maxLGsxa57dAudBYM2cJ0uBGPf7TSeaH++abvzDIy mYwytjStsemlSeGknvTpsznTbPrr88qlS8iZH2+k7YbAjt/11WohMP8jmBvZgtAKe/vxk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmZbY-00007G-46; Sat, 20 Jun 2020 09:16:04 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmZbX-0003c9-RQ; Sat, 20 Jun 2020 09:16:03 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmZbX-00072V-Py; Sat, 20 Jun 2020 09:16:03 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151227: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=06760c2bf322cef4622b56bafee74fe93ae01630 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Sat, 20 Jun 2020 09:16:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151227 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151227/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 06760c2bf322cef4622b56bafee74fe93ae01630 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 36 days Failing since 150943 2020-06-09 17:06:00 Z 10 days 9 attempts Testing same since 151161 2020-06-15 22:27:38 Z 4 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 06760c2bf322cef4622b56bafee74fe93ae01630 Author: Andrew Cooper Date: Fri Jun 12 18:32:27 2020 +0100 tools/libxl: Fix memory leak in libxl_cpuid_set() xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to free() seeing as it discards the results. This is logically a backport of c/s b91825f628 "tools/libxc: Drop config_transformed parameter from xc_cpuid_set()" but rewritten as one caller of xc_cpuid_set() does use returned values. Signed-off-by: Andrew Cooper (cherry picked from commit c54de7d9df7718ea53bf21e1ff5bbd339602a704) commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sat Jun 20 09:21:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jun 2020 09:21:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmZga-00071y-LQ; Sat, 20 Jun 2020 09:21:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmZgY-00071s-RD for xen-devel@lists.xenproject.org; Sat, 20 Jun 2020 09:21:14 +0000 X-Inumbo-ID: 6145eade-b2d7-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6145eade-b2d7-11ea-bca7-bc764e2007e4; Sat, 20 Jun 2020 09:21:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+zFt4BN8Mp4TYpBkNA2UIK8nOeqUyR66A7JkHwQGRcE=; b=qsIWiCyp9LaKZHqKENtlCT+QW H9FS4kcw0GO46Z+NXG+DSnVQ2/vEEXR72zguBVHiMmzEiz5Arvft66IJ7s5VlcZ439hwZ8UFhVcON 3xOgJOWuqNP1F8M6ROSisLmyRk29+Y8bbxPAw3Odgq6KpPxSoVFUJ1d2pBrzdsEG9RPeE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmZgU-0000DK-65; Sat, 20 Jun 2020 09:21:10 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmZgT-0003ya-UF; Sat, 20 Jun 2020 09:21:09 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmZgT-0000wq-Sl; Sat, 20 Jun 2020 09:21:09 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151228: all pass - PUSHED X-Osstest-Versions-This: ovmf=239b50a863704f7960525799eda82de061c7c458 X-Osstest-Versions-That: ovmf=58ae92a993687d913aa6dd00ef3497a1bc5f6c40 From: osstest service owner Date: Sat, 20 Jun 2020 09:21:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151228 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151228/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 239b50a863704f7960525799eda82de061c7c458 baseline version: ovmf 58ae92a993687d913aa6dd00ef3497a1bc5f6c40 Last test of basis 151187 2020-06-17 09:28:29 Z 2 days Testing same since 151228 2020-06-18 19:18:56 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ard Biesheuvel Dorapika Wu Igor Druzhinin Laszlo Ersek Ming Tan Tan, Ming jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 58ae92a993..239b50a863 239b50a863704f7960525799eda82de061c7c458 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Jun 20 09:58:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jun 2020 09:58:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmaGZ-0001Nx-Kh; Sat, 20 Jun 2020 09:58:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmaGX-0001Ns-PV for xen-devel@lists.xenproject.org; Sat, 20 Jun 2020 09:58:25 +0000 X-Inumbo-ID: 9432bd8c-b2dc-11ea-bc6d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9432bd8c-b2dc-11ea-bc6d-12813bfff9fa; Sat, 20 Jun 2020 09:58:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tSkoicnv7H0AWYUHzhgzsWG2RNienWOguRf/YqOe87k=; b=wekOPFAEk59EIgH95MZwovYpu mgmiowOlpBPiq3WWL8NR7gy/nmjgyMKzXzkGWGOAHp5At29/xhrotSFNndmBMevnWlhXPTJeNrq3q bTGq819P3Pby5b41YKlJeQANyDgmt1vJ8Fj4+NJxNbJvUGca9ApHjwxyt40qco7uDajNo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmaGV-0000su-Hy; Sat, 20 Jun 2020 09:58:23 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmaGV-00079J-9M; Sat, 20 Jun 2020 09:58:23 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmaGV-0001jJ-8r; Sat, 20 Jun 2020 09:58:23 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151229: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=ea3320048897f5279bc49cb49d26f8099706a834 X-Osstest-Versions-That: libvirt=6f28865223292a816f1bfde589901a00156cf8a1 From: osstest service owner Date: Sat, 20 Jun 2020 09:58:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151229 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151229/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151197 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151197 test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt ea3320048897f5279bc49cb49d26f8099706a834 baseline version: libvirt 6f28865223292a816f1bfde589901a00156cf8a1 Last test of basis 151197 2020-06-17 14:34:03 Z 2 days Testing same since 151229 2020-06-19 01:17:13 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Daniel Henrique Barboza Daniel P. Berrangé Erik Skultety Ján Tomko Michal Privoznik Paulo de Rezende Pinatti jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 6f28865223..ea33200488 ea3320048897f5279bc49cb49d26f8099706a834 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Jun 20 12:21:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jun 2020 12:21:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmcUt-0005pq-Be; Sat, 20 Jun 2020 12:21:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmcUr-0005pl-Tl for xen-devel@lists.xenproject.org; Sat, 20 Jun 2020 12:21:21 +0000 X-Inumbo-ID: 8be9a190-b2f0-11ea-bc8b-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8be9a190-b2f0-11ea-bc8b-12813bfff9fa; Sat, 20 Jun 2020 12:21:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ilVIfoQs7XNtKywUpuM9GnfxpGMAOFWPRl+pz2hfU80=; b=KeRU7vW6bHsPr/KetRDk6hdPE XVs/933mqVzc/hon4AwFbmiVqoBYbHON6K3F0634p9adP/OY2jQ79YynAREsZ9Duxc3wU5hE8qoav l05+CyBMdIragzRLoQtPD7XKQ+Q4poD5Mg27pmpb0lVjFlVYJ/tLqonKfxK3MdOGhvRTM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmcUp-0003Yc-Bz; Sat, 20 Jun 2020 12:21:19 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmcUo-0007Bf-VU; Sat, 20 Jun 2020 12:21:19 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmcUo-0007XD-Ul; Sat, 20 Jun 2020 12:21:18 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 151231: regressions - trouble: fail/pass/starved X-Osstest-Failures: xen-4.10-testing:build-i386-prev:xen-build:fail:regression xen-4.10-testing:build-amd64-prev:xen-build:fail:regression xen-4.10-testing:test-amd64-amd64-xl-qcow2:debian-di-install:fail:heisenbug xen-4.10-testing:test-amd64-amd64-pygrub:debian-di-install:fail:heisenbug xen-4.10-testing:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:heisenbug xen-4.10-testing:test-amd64-i386-xl-raw:debian-di-install:fail:heisenbug xen-4.10-testing:test-armhf-armhf-xl-multivcpu:xen-boot:fail:heisenbug xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-localmigrate/x10:fail:heisenbug xen-4.10-testing:test-armhf-armhf-xl-vhd:guest-start:fail:heisenbug xen-4.10-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=fd6e49ecae03840610fdc6a416a638590c0b6535 X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Sat, 20 Jun 2020 12:21:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151231 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151231/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail in 151196 REGR. vs. 150039 build-amd64-prev 6 xen-build fail in 151196 REGR. vs. 150039 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qcow2 10 debian-di-install fail in 151196 pass in 151231 test-amd64-amd64-pygrub 10 debian-di-install fail in 151196 pass in 151231 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail in 151196 pass in 151231 test-amd64-i386-xl-raw 10 debian-di-install fail in 151196 pass in 151231 test-armhf-armhf-xl-multivcpu 7 xen-boot fail pass in 151196 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 151196 test-armhf-armhf-xl-vhd 11 guest-start fail pass in 151196 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked in 151196 n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked in 151196 n/a test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 151196 never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 151196 never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail in 151196 never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 151196 never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 151196 never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 150039 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 150039 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen fd6e49ecae03840610fdc6a416a638590c0b6535 baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 45 days Failing since 150941 2020-06-09 17:05:34 Z 10 days 11 attempts Testing same since 151163 2020-06-16 02:57:33 Z 4 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Jan Beulich Jeremi Piotrowski John Thomson Julien Grall Krzysztof Kolasa Marek Marczykowski-Górecki Mark Pryor Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 301 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 20 16:00:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jun 2020 16:00:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmfum-0008O6-3Q; Sat, 20 Jun 2020 16:00:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmful-0008Nm-87 for xen-devel@lists.xenproject.org; Sat, 20 Jun 2020 16:00:19 +0000 X-Inumbo-ID: 1d7fb45a-b30f-11ea-bcb1-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1d7fb45a-b30f-11ea-bcb1-12813bfff9fa; Sat, 20 Jun 2020 16:00:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l1cTo3k2pZMN/cy4QoK26vh3q7sKmKAh6ZXs+dxQMZI=; b=I3Y+espZOdTrQMCHbaUIWGgkR kMDX5Y+V42jd61L4n3byRKNmB9xbcdkVKm7uQ2VV/CBx/W0MGJhg2lcNCVadxr254Bxx3sKnyEVdo rVDKLPwUjch5s5dzIlmlVl06HUdN7weyj3b98DAudujM6vxWnIVDBRnYduNs+mqpnduXE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmfua-000883-Jo; Sat, 20 Jun 2020 16:00:08 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmfua-0001LF-CN; Sat, 20 Jun 2020 16:00:08 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmfua-0006b0-Bm; Sat, 20 Jun 2020 16:00:08 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 151232: tolerable FAIL - PUSHED X-Osstest-Failures: linux-5.4:test-amd64-amd64-libvirt-vhd:guest-start/debian.repeat:fail:heisenbug linux-5.4:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug linux-5.4:test-amd64-amd64-examine:memdisk-try-append:fail:heisenbug linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=fd8cd8ac940c8b45b75474415291a3b941c865ab X-Osstest-Versions-That: linux=5e3c511539228fa03c8d00d61b5b5f32333ed0b0 From: osstest service owner Date: Sat, 20 Jun 2020 16:00:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151232 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/151232/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 151200 pass in 151232 test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail in 151200 pass in 151232 test-amd64-amd64-examine 4 memdisk-try-append fail pass in 151200 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux fd8cd8ac940c8b45b75474415291a3b941c865ab baseline version: linux 5e3c511539228fa03c8d00d61b5b5f32333ed0b0 Last test of basis 151022 2020-06-10 18:39:22 Z 9 days Testing same since 151200 2020-06-17 16:10:55 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: "Eric W. Biederman" Alexander Potapenko Alexandre Belloni Alla Segal Amir Goldstein Andi Shyti Andreas Gruenbacher Andrew Morton Andrii Nakryiko Anson Huang Anthony Steinhauser Ard Biesheuvel Aristeu Rozanski Arnaldo Carvalho de Melo Arnaud Pouliquen Arnd Bergmann Barret Rhoden Bartlomiej Zolnierkiewicz Bjorn Andersson Bjorn Helgaas Bob Haarman Boris Ostrovsky Borislav Petkov Breno Lima Casey Schaufler Chandrakanth Patil Chris Wilson Christoph Hellwig Christophe JAILLET Christophe Leroy Chuhong Yuan Cédric Le Goater Daniel Borkmann Daniel Jordan Dave Rodgman David Howells David S. Miller Denis Efremov Dennis Kadioglu Dick Kennedy Dmitry Torokhov Eiichi Tsukata Eric Biggers Eric W. Biederman Ezequiel Garcia Fabio Estevam Fangrui Song Felipe Franciosi Florian Fainelli Franck LENORMAND Fredrik Strupe Geert Uytterhoeven Giuseppe Scrivano Gonglei Greg Kroah-Hartman Guenter Roeck Guo Ren Hangbin Liu Hans de Goede Herbert Xu Hill Ma Huacai Chen Hui Wang Ido Schimmel Ingo Molnar James Morse James Smart Jan Kara Jason Gunthorpe Jens Axboe Jiri Kosina Jue Wang Juergen Gross Justin Chen Kai-Heng Feng Kalle Valo Kamal Dasu Kan Liang Kim Phillips Kirill Shutemov Leonard Crestez Libor Pechacek Linus Torvalds Linus Walleij Longpeng(Mike) Lorenzo Pieralisi Luca Coelho Ludovic Barre Ludovic Desroches Lukas Wunner Marc Zyngier Marcelo Ricardo Leitner Marcelo Ricardo Leitner Maria Teguiani Mark Brown Martin K. Petersen Masahiro Yamada Masami Hiramatsu Masashi Honma Matthias Maennich Maxim Mikityanskiy Michael Ellerman Michael Ellerman (powerpc) Michael S. Tsirkin Michał Mirosław Miklos Szeredi Namjae Jeon Nick Desaulniers Nikolay Aleksandrov OGAWA Hirofumi Oleg Nesterov Paolo Bonzini Pavel Dobias Peng Fan Petar Penkov Peter Zijlstra (Intel) Peter Zijlstra Petr Tesarik Qian Cai Qiujun Huang Qiushi Wu Qiuxu Zhuo Rafael J. Wysocki Rodrigo Siqueira Russell King Ryusuke Konishi Saeed Mahameed Sam Ravnborg Sasha Levin Sean Christopherson Sedat Dilek # build+boot on Serge Semin Shawn Guo Shay Drory Shuah Khan Stanislav Fomichev Stephan Gerhold Steve French Suman Anna Sumit Saxena Takashi Iwai Takashi Sakamoto Tanner Love tannerlove Tero Kristo Thomas Falcon Thomas Gleixner Tony Luck Ulf Hansson Vadim Pasternak Vasily Averin Vasily Gorbik Veerabhadrarao Badiganti Viresh Kumar Vlad Buslov Waiman Long Wang Hai Wei Yongjun Will Deacon Willem de Bruijn Wim Van Sebroeck Wolfram Sang Xiaochun Lee Xin Long Xing Li youling257@gmail.com Yuxuan Shui jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 5e3c51153922..fd8cd8ac940c fd8cd8ac940c8b45b75474415291a3b941c865ab -> tested/linux-5.4 From xen-devel-bounces@lists.xenproject.org Sat Jun 20 21:57:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 20 Jun 2020 21:57:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmlUK-0004e4-Ca; Sat, 20 Jun 2020 21:57:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmlUI-0004dy-D7 for xen-devel@lists.xenproject.org; Sat, 20 Jun 2020 21:57:22 +0000 X-Inumbo-ID: 01127758-b341-11ea-bced-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 01127758-b341-11ea-bced-12813bfff9fa; Sat, 20 Jun 2020 21:57:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=or1dh56RTXxbA6uCJI7s0JIQaaQB4ooGj+stLpWNcGo=; b=lBygRn/R5iVpprAgMzAsWwi+7 0gvT8SlV0t6aIM4sBll8ExZzTsHnQvPfP5wW9fGGkBsgFKSd/R+pEYf//MNAPxX5OXMyY5Huc2psd GwOZpXkNTYQ1jfCNa096hry7CxYXnyXtjwmFIjd9z5zAbIS6j8N3V92LBUGLCFTAy7DHw=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmlUB-0006Ya-FR; Sat, 20 Jun 2020 21:57:15 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmlUB-00040N-40; Sat, 20 Jun 2020 21:57:15 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmlUB-0008Sm-3K; Sat, 20 Jun 2020 21:57:15 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151234: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Sat, 20 Jun 2020 21:57:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151234 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151234/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 46 days Failing since 150942 2020-06-09 17:05:43 Z 11 days 11 attempts Testing same since 151061 2020-06-12 12:25:05 Z 8 days 6 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 2b77729888fb851ab96e7f77bc854122626b4861 Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Jun 21 03:01:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 21 Jun 2020 03:01:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmqDl-0007aI-Vj; Sun, 21 Jun 2020 03:00:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmqDj-0007aD-Uy for xen-devel@lists.xenproject.org; Sun, 21 Jun 2020 03:00:36 +0000 X-Inumbo-ID: 5f6bd202-b36b-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5f6bd202-b36b-11ea-8496-bc764e2007e4; Sun, 21 Jun 2020 03:00:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4EuybYWKvsBw1Q3JZm+xZC7m+Jm9vfrrMRnMNStUxKc=; b=EC6l7S/aKwypobfUfkezTvgiP PxF8uWsfwrhp5Jne12kwpJozawvwTWhzRJqHmTbRX6lf8A+qySMbtT1rGjx63NMhYrFSO8W0K+RL7 yRM9O+DKHdL/bFAEMFw3i6TAACEGWG1yQax3aWuuCeC7a98NNaoHmkdOOY5UsQgqxQQkM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmqDg-00061h-Mf; Sun, 21 Jun 2020 03:00:32 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmqDg-0001NO-C8; Sun, 21 Jun 2020 03:00:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmqDg-00058O-BS; Sun, 21 Jun 2020 03:00:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151236: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=5e857ce6eae7ca21b2055cca4885545e29228fe2 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Sun, 21 Jun 2020 03:00:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151236 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151236/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 5e857ce6eae7ca21b2055cca4885545e29228fe2 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 3 days Testing same since 151236 2020-06-19 19:10:35 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Christoph Hellwig Linus Torvalds Luc Van Oostenryck Miguel Ojeda jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 5e857ce6eae7ca21b2055cca4885545e29228fe2 Merge: 670d0a4b1070 0c389d89abc2 Author: Linus Torvalds Date: Thu Jun 18 12:35:51 2020 -0700 Merge branch 'hch' (maccess patches from Christoph Hellwig) Merge non-faulting memory access cleanups from Christoph Hellwig: "Andrew and I decided to drop the patches implementing your suggested rename of the probe_kernel_* and probe_user_* helpers from -mm as there were way to many conflicts. After -rc1 might be a good time for this as all the conflicts are resolved now" This also adds a type safety checking patch on top of the renaming series to make the subtle behavioral difference between 'get_user()' and 'get_kernel_nofault()' less potentially dangerous and surprising. * emailed patches from Christoph Hellwig : maccess: make get_kernel_nofault() check for minimal type compatibility maccess: rename probe_kernel_address to get_kernel_nofault maccess: rename probe_user_{read,write} to copy_{from,to}_user_nofault maccess: rename probe_kernel_{read,write} to copy_{from,to}_kernel_nofault commit 0c389d89abc28edf70ae847ee2fa55acb267b826 Author: Linus Torvalds Date: Thu Jun 18 12:10:37 2020 -0700 maccess: make get_kernel_nofault() check for minimal type compatibility Now that we've renamed probe_kernel_address() to get_kernel_nofault() and made it look and behave more in line with get_user(), some of the subtle type behavior differences end up being more obvious and possibly dangerous. When you do get_user(val, user_ptr); the type of the access comes from the "user_ptr" part, and the above basically acts as val = *user_ptr; by design (except, of course, for the fact that the actual dereference is done with a user access). Note how in the above case, the type of the end result comes from the pointer argument, and then the value is cast to the type of 'val' as part of the assignment. So the type of the pointer is ultimately the more important type both for the access itself. But 'get_kernel_nofault()' may now _look_ similar, but it behaves very differently. When you do get_kernel_nofault(val, kernel_ptr); it behaves like val = *(typeof(val) *)kernel_ptr; except, of course, for the fact that the actual dereference is done with exception handling so that a faulting access is suppressed and returned as the error code. But note how different the casting behavior of the two superficially similar accesses are: one does the actual access in the size of the type the pointer points to, while the other does the access in the size of the target, and ignores the pointer type entirely. Actually changing get_kernel_nofault() to act like get_user() is almost certainly the right thing to do eventually, but in the meantime this patch adds logit to at least verify that the pointer type is compatible with the type of the result. In many cases, this involves just casting the pointer to 'void *' to make it obvious that the type of the pointer is not the important part. It's not how 'get_user()' acts, but at least the behavioral difference is now obvious and explicit. Cc: Christoph Hellwig Signed-off-by: Linus Torvalds commit 25f12ae45fc1931a1dce3cc59f9989a9d87834b0 Author: Christoph Hellwig Date: Wed Jun 17 09:37:55 2020 +0200 maccess: rename probe_kernel_address to get_kernel_nofault Better describe what this helper does, and match the naming of copy_from_kernel_nofault. Also switch the argument order around, so that it acts and looks like get_user(). Signed-off-by: Christoph Hellwig Signed-off-by: Linus Torvalds commit 670d0a4b10704667765f7d18f7592993d02783aa Author: Luc Van Oostenryck Date: Thu Jun 18 00:02:26 2020 +0200 sparse: use identifiers to define address spaces Currently, address spaces in warnings are displayed as '' with 'X' being the address space's arbitrary number. But since sparse v0.6.0-rc1 (late December 2018), sparse allows you to define the address spaces using an identifier instead of a number. This identifier is then directly used in the warnings. So, use the identifiers '__user', '__iomem', '__percpu' & '__rcu' for the corresponding address spaces. The default address space, __kernel, being not displayed in warnings, stays defined as '0'. With this change, warnings that used to be displayed as: cast removes address space '' of expression ... void [noderef] * will now be displayed as: cast removes address space '__user' of expression ... void [noderef] __iomem * This also moves the __kernel annotation to be the first one, since it is quite different from the others because it's the default one, and so: - it's never displayed - it's normally not needed, nor in type annotations, nor in cast between address spaces. The only time it's needed is when it's combined with a typeof to express "the same type as this one but without the address space" - it can't be defined with a name, '0' must be used. So, it seemed strange to me to have it in the middle of the other ones. Signed-off-by: Luc Van Oostenryck Acked-by: Miguel Ojeda Signed-off-by: Linus Torvalds commit c0ee37e85e0e47402b8bbe35b6cec8e06937ca58 Author: Christoph Hellwig Date: Wed Jun 17 09:37:54 2020 +0200 maccess: rename probe_user_{read,write} to copy_{from,to}_user_nofault Better describe what these functions do. Suggested-by: Linus Torvalds Signed-off-by: Christoph Hellwig Signed-off-by: Linus Torvalds commit fe557319aa06c23cffc9346000f119547e0f289a Author: Christoph Hellwig Date: Wed Jun 17 09:37:53 2020 +0200 maccess: rename probe_kernel_{read,write} to copy_{from,to}_kernel_nofault Better describe what these functions do. Suggested-by: Linus Torvalds Signed-off-by: Christoph Hellwig Signed-off-by: Linus Torvalds From xen-devel-bounces@lists.xenproject.org Sun Jun 21 06:55:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 21 Jun 2020 06:55:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmtsP-0002Pu-0G; Sun, 21 Jun 2020 06:54:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmtsO-0002Pp-6W for xen-devel@lists.xenproject.org; Sun, 21 Jun 2020 06:54:48 +0000 X-Inumbo-ID: 177c809c-b38c-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 177c809c-b38c-11ea-bb8b-bc764e2007e4; Sun, 21 Jun 2020 06:54:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lh1uOD9eAmIS4K9VAlIizahim/u57BgmBYBzRHeIobc=; b=e0hBtbc95DbQJvoT1+dBu7hV6 9A1xY90etzZPhrdT4hxH2ixktHyNMNws5lDi/bvRD8hVwmXQ2ufuCLePAQoZWNs06MG+lLuefFmaY PbhvxyODRHS/SJxGCDHIg/Q6cOnC8nIOnRaay8R2pLDqRxCME2AJ/XuvpwKoax3CpMmVs=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmtsL-0002Mi-9T; Sun, 21 Jun 2020 06:54:45 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmtsL-0004jH-0A; Sun, 21 Jun 2020 06:54:45 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmtsK-00084y-VU; Sun, 21 Jun 2020 06:54:44 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151241: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-xl-rtds:guest-start:fail:allowable qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=06c4cc3660b366278bdc7bc8b6677032d7b1118c X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Sun, 21 Jun 2020 06:54:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151241 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151241/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: qemuu 06c4cc3660b366278bdc7bc8b6677032d7b1118c baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 8 days Failing since 151101 2020-06-14 08:32:51 Z 6 days 5 attempts Testing same since 151241 2020-06-20 01:36:13 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Anthony PERARD Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Cathy Zhang Christian Borntraeger Claudio Fontana Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Gerd Hoffmann Guenter Roeck Helge Deller Igor Mammedov Janne Grunau Jason Wang Jean-Christophe Dubois Jiaxun Yang John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marek Marczykowski-Górecki Markus Armbruster Masahiro Yamada Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Stefan Berger Stefan Hajnoczi Thomas Huth Tong Ho WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 8468 lines long.) From xen-devel-bounces@lists.xenproject.org Sun Jun 21 09:46:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 21 Jun 2020 09:46:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmwYS-0000fB-Oa; Sun, 21 Jun 2020 09:46:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmwYR-0000bG-U4 for xen-devel@lists.xenproject.org; Sun, 21 Jun 2020 09:46:23 +0000 X-Inumbo-ID: 0d81f852-b3a4-11ea-bd70-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0d81f852-b3a4-11ea-bd70-12813bfff9fa; Sun, 21 Jun 2020 09:46:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qAxRwbTFH0SbQhgpa0OFl4C9ltt+4sB7fNVwKbe2sUs=; b=kpMfNlDL+dtSbNDvL5OMyalGO yhfyW9aMYvPBKroohhoqEIGh8eQWg49mOPY6FIv4UlS9u8rre19lmcySzdDKc70v+cNPH5eu3whmE 2Wjp9pF9fFbSnN8a8+HA4kt9rOPpDfO7M+xGVT9UqBnYLhKZG3vw0h9M6Jjemg7RvDClA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmwYK-000605-D6; Sun, 21 Jun 2020 09:46:16 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmwYK-0004Sh-4e; Sun, 21 Jun 2020 09:46:16 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmwYK-0002yX-3t; Sun, 21 Jun 2020 09:46:16 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151245: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:allowable xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=fde76f895d0aa817a1207d844d793239c6639bc6 X-Osstest-Versions-That: xen=3625b04991b4d6affadd99d377ab84bac48dfff4 From: osstest service owner Date: Sun, 21 Jun 2020 09:46:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151245 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151245/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151181 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 151181 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151181 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151181 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151181 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151181 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151181 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen fde76f895d0aa817a1207d844d793239c6639bc6 baseline version: xen 3625b04991b4d6affadd99d377ab84bac48dfff4 Last test of basis 151181 2020-06-17 06:01:52 Z 4 days Failing since 151224 2020-06-18 16:01:07 Z 2 days 2 attempts Testing same since 151245 2020-06-20 06:44:46 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Ian Jackson Igor Druzhinin Jason Andryuk Olaf Hering Roger Pau Monné Samuel Thibault Tamas K Lengyel jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 364 lines long.) From xen-devel-bounces@lists.xenproject.org Sun Jun 21 10:29:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 21 Jun 2020 10:29:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmxEP-0004FK-5O; Sun, 21 Jun 2020 10:29:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmxEO-0004FF-DK for xen-devel@lists.xenproject.org; Sun, 21 Jun 2020 10:29:44 +0000 X-Inumbo-ID: 1efa5344-b3aa-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1efa5344-b3aa-11ea-bca7-bc764e2007e4; Sun, 21 Jun 2020 10:29:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ja/EE2N96pf72jASmbavq9qCgjWCNSqOKolw8ltrnbA=; b=wQtW/M6cXNkQUgs2SkdoeaChw ze5USgCl+1Ji303T216bTCI7jafhr/6cGAdTUN4K4Yzu2TBHm45JftI2l7YoB0Be2T8BK71QnH8Nu 4769hwIKdYDSSAKAgSy/4wnJtxDTy0A86CUCrYw2a4xO2kmt1qkXVBMqdOz4FZu+pcpY8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmxEN-0006vk-7j; Sun, 21 Jun 2020 10:29:43 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmxEM-0006Z9-MF; Sun, 21 Jun 2020 10:29:42 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmxEM-0005hL-Lb; Sun, 21 Jun 2020 10:29:42 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-coverity test] 151271: all pass - PUSHED X-Osstest-Versions-This: xen=fde76f895d0aa817a1207d844d793239c6639bc6 X-Osstest-Versions-That: xen=3625b04991b4d6affadd99d377ab84bac48dfff4 From: osstest service owner Date: Sun, 21 Jun 2020 10:29:42 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151271 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/151271/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen fde76f895d0aa817a1207d844d793239c6639bc6 baseline version: xen 3625b04991b4d6affadd99d377ab84bac48dfff4 Last test of basis 151186 2020-06-17 09:18:28 Z 4 days Testing same since 151271 2020-06-21 09:18:26 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Ian Jackson Igor Druzhinin Jason Andryuk Olaf Hering Roger Pau Monné Samuel Thibault Tamas K Lengyel jobs: coverity-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 3625b04991..fde76f895d fde76f895d0aa817a1207d844d793239c6639bc6 -> coverity-tested/smoke From xen-devel-bounces@lists.xenproject.org Sun Jun 21 13:00:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 21 Jun 2020 13:00:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmzZV-0000El-Ni; Sun, 21 Jun 2020 12:59:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmzZU-0000EQ-HN for xen-devel@lists.xenproject.org; Sun, 21 Jun 2020 12:59:40 +0000 X-Inumbo-ID: 0e417306-b3bf-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0e417306-b3bf-11ea-8496-bc764e2007e4; Sun, 21 Jun 2020 12:59:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WMm/7BkJOzyXdnNmCRjSdN0pgm141Z2bOCqathVLvfE=; b=vNovUdI5kwmjO0eBS9xhaGBJK 52W9MeoaOj6ofxOEKeF9wi6bEsGdzGQe/p3wZSsjWmxSI/oCzbFHu4FL3xZ0JTTNRER1RLxmCaT8j uwM229BMlXziMR23U0dLlApuWhxqiuQWlEcgw5f271Jnvp+D8qKMrmCCb6925sm/d1heE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jmzZO-0001GA-8O; Sun, 21 Jun 2020 12:59:34 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jmzZN-0006uL-VV; Sun, 21 Jun 2020 12:59:34 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jmzZN-00084G-Uu; Sun, 21 Jun 2020 12:59:33 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151249: all pass - PUSHED X-Osstest-Versions-This: ovmf=322969adf1fb3d6cfbd613f35121315715aff2ed X-Osstest-Versions-That: ovmf=239b50a863704f7960525799eda82de061c7c458 From: osstest service owner Date: Sun, 21 Jun 2020 12:59:33 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151249 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151249/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 322969adf1fb3d6cfbd613f35121315715aff2ed baseline version: ovmf 239b50a863704f7960525799eda82de061c7c458 Last test of basis 151228 2020-06-18 19:18:56 Z 2 days Testing same since 151249 2020-06-20 09:21:45 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Wasim Khan jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 239b50a863..322969adf1 322969adf1fb3d6cfbd613f35121315715aff2ed -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sun Jun 21 14:29:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 21 Jun 2020 14:29:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn0yW-0007zE-0H; Sun, 21 Jun 2020 14:29:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn0yU-0007yu-FJ for xen-devel@lists.xenproject.org; Sun, 21 Jun 2020 14:29:34 +0000 X-Inumbo-ID: 9c6da71a-b3cb-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9c6da71a-b3cb-11ea-8496-bc764e2007e4; Sun, 21 Jun 2020 14:29:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lKkZQ1D9tXmy981uue4NQ2eejBJfJ+hInsbvRx2KanE=; b=skz2dTxhbUuZYFozhOPG4L17Q EXy0WnA10fs8XuTWxkesV8lKmSAYiJCS53bS/4czrZnWybqQ0egWPW1OIAeO7La2C1HfJGX5PmTc1 f8bVeBdHx5QwQ/0paNgMKz73N2KgXhVWSt8ENlB2+dIwmUk1vCgKFaNx0q78bTgRYkb3E=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn0yN-0002wb-27; Sun, 21 Jun 2020 14:29:27 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jn0yM-0007Ja-Nx; Sun, 21 Jun 2020 14:29:26 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jn0yM-0004JY-NR; Sun, 21 Jun 2020 14:29:26 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151251: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=96a39aad705f8e37950109d11636085b212af790 X-Osstest-Versions-That: libvirt=ea3320048897f5279bc49cb49d26f8099706a834 From: osstest service owner Date: Sun, 21 Jun 2020 14:29:26 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151251 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151251/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151229 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151229 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 96a39aad705f8e37950109d11636085b212af790 baseline version: libvirt ea3320048897f5279bc49cb49d26f8099706a834 Last test of basis 151229 2020-06-19 01:17:13 Z 2 days Testing same since 151251 2020-06-20 10:00:44 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Erik Skultety Jiri Denemark Jonathon Jongsma jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git ea33200488..96a39aad70 96a39aad705f8e37950109d11636085b212af790 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sun Jun 21 14:50:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 21 Jun 2020 14:50:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn1IY-0001zX-Rw; Sun, 21 Jun 2020 14:50:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn1IX-0001zD-Cl for xen-devel@lists.xenproject.org; Sun, 21 Jun 2020 14:50:17 +0000 X-Inumbo-ID: 804f9a68-b3ce-11ea-bdad-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 804f9a68-b3ce-11ea-bdad-12813bfff9fa; Sun, 21 Jun 2020 14:50:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Hko1p6vB1i0EJgeEUehnEv3wOU0a5QNsRJrbGvGjFLg=; b=5vjB4Y5Q6jOmWESzBdNWWLCw7 RBwNSITTrVPLNBNQ0oOBrNXSlH2hvyhqX8wq8UQ6BLCl1TU+ijMgR360CWsJuOq04HCUkZfPze+Rf zXU7FiI0f4ydx/EQWu56+16e6v5tGBYir9xYzZl76L8qDsfqrThvX2fhtnOmEjD1Dfh1s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn1IN-0003J3-Ut; Sun, 21 Jun 2020 14:50:08 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jn1IN-00018g-K7; Sun, 21 Jun 2020 14:50:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jn1IN-0002Su-HG; Sun, 21 Jun 2020 14:50:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151248: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:heisenbug xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=06760c2bf322cef4622b56bafee74fe93ae01630 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Sun, 21 Jun 2020 14:50:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151248 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151248/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 151227 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail pass in 151227 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail in 151227 never pass test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 06760c2bf322cef4622b56bafee74fe93ae01630 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 38 days Failing since 150943 2020-06-09 17:06:00 Z 11 days 10 attempts Testing same since 151161 2020-06-15 22:27:38 Z 5 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 06760c2bf322cef4622b56bafee74fe93ae01630 Author: Andrew Cooper Date: Fri Jun 12 18:32:27 2020 +0100 tools/libxl: Fix memory leak in libxl_cpuid_set() xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to free() seeing as it discards the results. This is logically a backport of c/s b91825f628 "tools/libxc: Drop config_transformed parameter from xc_cpuid_set()" but rewritten as one caller of xc_cpuid_set() does use returned values. Signed-off-by: Andrew Cooper (cherry picked from commit c54de7d9df7718ea53bf21e1ff5bbd339602a704) commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Jun 21 17:06:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 21 Jun 2020 17:06:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn3Pf-0005Uq-SK; Sun, 21 Jun 2020 17:05:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn3Pe-0005UP-KA for xen-devel@lists.xenproject.org; Sun, 21 Jun 2020 17:05:46 +0000 X-Inumbo-ID: 6ec8f736-b3e1-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6ec8f736-b3e1-11ea-bca7-bc764e2007e4; Sun, 21 Jun 2020 17:05:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AO7IXmrJf9B2OOGXj2NtmR++oE4D45Cvy93dsnkjOrM=; b=CYKmzAzv7M3bkmnYy63xYBA5J pXAs2W0Idpw6Xve54B+IoCmoL7dw9KOMnue2FARVrqa7EOCNjPZLyj2BE/DsZL/NrtlYWie4lnTwv Sk2GjLZVxCoMp1xpnZgpS+dLWSzyizijcqOmxyKTLVO7oKQ+PIxVSTGp1p6OQJdJkM83k=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn3PX-0006J0-2s; Sun, 21 Jun 2020 17:05:39 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jn3PW-0007Uh-91; Sun, 21 Jun 2020 17:05:38 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jn3PW-0006G9-8O; Sun, 21 Jun 2020 17:05:38 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.10-testing test] 151255: tolerable trouble: fail/pass/starved - PUSHED X-Osstest-Failures: xen-4.10-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.10-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.10-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.10-testing:test-arm64-arm64-xl-thunderx:hosts-allocate:starved:nonblocking X-Osstest-Versions-This: xen=fd6e49ecae03840610fdc6a416a638590c0b6535 X-Osstest-Versions-That: xen=b922c4431df33ed5b724e53c3f3348e470ddd349 From: osstest service owner Date: Sun, 21 Jun 2020 17:05:38 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151255 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151255/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 150039 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 150039 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a version targeted for testing: xen fd6e49ecae03840610fdc6a416a638590c0b6535 baseline version: xen b922c4431df33ed5b724e53c3f3348e470ddd349 Last test of basis 150039 2020-05-05 16:06:01 Z 47 days Failing since 150941 2020-06-09 17:05:34 Z 11 days 12 attempts Testing same since 151163 2020-06-16 02:57:33 Z 5 days 4 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christian Lindig Christopher Clark Christopher Clark Jan Beulich Jeremi Piotrowski John Thomson Julien Grall Krzysztof Kolasa Marek Marczykowski-Górecki Mark Pryor Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx starved test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git b922c4431d..fd6e49ecae fd6e49ecae03840610fdc6a416a638590c0b6535 -> stable-4.10 From xen-devel-bounces@lists.xenproject.org Sun Jun 21 20:45:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 21 Jun 2020 20:45:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn6q6-0007ia-29; Sun, 21 Jun 2020 20:45:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn6q4-0007iV-Iw for xen-devel@lists.xenproject.org; Sun, 21 Jun 2020 20:45:16 +0000 X-Inumbo-ID: 1b3d3fae-b400-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1b3d3fae-b400-11ea-bb8b-bc764e2007e4; Sun, 21 Jun 2020 20:45:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MRxi7/o0SxigdJ/hlx4PL9uBcVz4iFQzaabOdCkPNo8=; b=F8SXoujOet9DoWye8Q2u03DMq t06Co5FlgbeokuHmtVgl5CR/RihnRgF0nfGHOmzd+3mt15U617o98oxlvGmU/pHiv3qISIqKz89ep WM4uD3SCnRb2h+dWz4Pqw1LE3uO5rm8CaHLEDMj0Ps41urwLR29dYd+veXewpUmjpuQrI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jn6q1-0001wt-0g; Sun, 21 Jun 2020 20:45:13 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jn6q0-0003Rt-Mc; Sun, 21 Jun 2020 20:45:12 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jn6q0-0002Qm-M2; Sun, 21 Jun 2020 20:45:12 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151260: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Sun, 21 Jun 2020 20:45:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151260 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151260/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail REGR. vs. 150040 build-i386-prev 6 xen-build fail REGR. vs. 150040 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 47 days Failing since 150942 2020-06-09 17:05:43 Z 12 days 12 attempts Testing same since 151061 2020-06-12 12:25:05 Z 9 days 7 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 2b77729888fb851ab96e7f77bc854122626b4861 Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Jun 22 02:24:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 02:24:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnC8B-0005IG-Ts; Mon, 22 Jun 2020 02:24:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnC8A-0005IB-SZ for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 02:24:18 +0000 X-Inumbo-ID: 783f2382-b42f-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 783f2382-b42f-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 02:24:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Fc87MVQvg2ao+2aiqVkROFZPBHhufm3vCCRv5koLGs8=; b=RWnOGc0E6UjlsEoOl0MLb5n/w yz88nHVxuwE8nkUdTLpo1tKJsPawcVDJOlzMu6V5w0xseL6CdnnZy+3tBF48GQSgjw6kplNRNWMn1 bwzEETxlJz4qVxByar4TYxHMTn0LWlz13WQsrtGeIkH1/X/IGHAfvQf39gDLd4dJBLaIU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnC87-00022R-MO; Mon, 22 Jun 2020 02:24:15 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnC87-0000XI-Ej; Mon, 22 Jun 2020 02:24:15 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnC87-00013f-E4; Mon, 22 Jun 2020 02:24:15 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151264: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:xen-boot:fail:regression linux-linus:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:xen-boot:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=64677779e8962c20b580b471790fe42367750599 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Mon, 22 Jun 2020 02:24:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151264 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151264/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 151214 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 151214 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 64677779e8962c20b580b471790fe42367750599 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 3 days Failing since 151236 2020-06-19 19:10:35 Z 2 days 2 attempts Testing same since 151264 2020-06-21 03:03:16 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alex Deucher Alex Deucher Alexey Budankov Andy Shevchenko Ard Biesheuvel Arnaldo Carvalho de Melo Arnd Bergmann Atish Patra Baolin Wang Barry Song Chen Zhou Chris Wilson Christoph Hellwig Coly Li Cornelia Huck Dan Williams Daniel Schaefer Daniel Vetter Dave Airlie Dave Martin David Howells Denis Efremov Dinghao Liu Dmitry V. Levin Felix Kuehling Flavio Suligoi Gaurav Singh Gustavo A. R. Silva Heiko Carstens Hongbo Yao Ian Rogers Ilya Dryomov Imre Deak Ira Weiny Jack Wang Jan Kara Jason Yan Jens Axboe Jiri Olsa Jiri Olsa John Garry Joonas Lahtinen Julian Wiedmann Kai-Heng Feng Kaitao Cheng Kees Cook Kefeng Wang Keyur Patel Khaled Almahallawy Lee Jones Linus Torvalds Loic Poulain Lorenz Brun Luc Van Oostenryck Luis Chamberlain Mark Rutland Martin K. Petersen Martin Schwidefsky Masami Hiramatsu Mauricio Faria de Oliveira Michael Ellerman Miguel Ojeda Milian Wolff Nathan Chancellor Nathan Huckleberry Navid Emamdoost Nick Desaulniers Nirmoy Das Palmer Dabbelt Pavel Begunkov Qingqing Zhuo Randy Dunlap Robert Foss Rodrigo Siqueira Roman Gushchin Sami Tolvanen Sandeep Raghuraman Sedat Dilek Shuah Khan Shyam Thombre Steven Rostedt (VMware) Sumanth Korikkar Sven Schnelle Tiezhu Yang Uma Shankar Vaibhav Jain Vamshi K Sthambamkadi Vandita Kulkarni Vasily Gorbik Vincenzo Frascino Vishal Verma Wei Yang Weiping Zhang Will Deacon Wolfram Sang Wolfram Sang Xiaoguang Wang YangHui Yash Shah Ye Bin Zheng Bin Zhiqiang Liu Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 5154 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 22 02:46:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 02:46:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnCT8-00075e-OL; Mon, 22 Jun 2020 02:45:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnCT7-00075Z-VE for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 02:45:57 +0000 X-Inumbo-ID: 7ef41d42-b432-11ea-be2b-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7ef41d42-b432-11ea-be2b-12813bfff9fa; Mon, 22 Jun 2020 02:45:56 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 51E38A2735; Mon, 22 Jun 2020 04:45:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3E874A272E; Mon, 22 Jun 2020 04:45:54 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id a7WyR7uYazyS; Mon, 22 Jun 2020 04:45:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A0090A2735; Mon, 22 Jun 2020 04:45:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3dDfVGCViHz3; Mon, 22 Jun 2020 04:45:53 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 6C0E5A272E; Mon, 22 Jun 2020 04:45:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 54BBF21B70; Mon, 22 Jun 2020 04:45:23 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id zq17v4hpkMiR; Mon, 22 Jun 2020 04:45:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D504121B84; Mon, 22 Jun 2020 04:45:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FJuc2iGxDVV5; Mon, 22 Jun 2020 04:45:17 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id A697221B70; Mon, 22 Jun 2020 04:45:17 +0200 (CEST) Date: Mon, 22 Jun 2020 04:45:17 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <922166039.10901755.1592793917485.JavaMail.zimbra@cert.pl> In-Reply-To: References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <20200619153003.GB735@Air-de-Roger> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: Jqc1uJ7WJHJxmr7vi9qQTOYlMrKEPA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 17:50, Jan Beulich jbeulich@suse.com napisa=C5=82(a): > On 19.06.2020 17:30, Roger Pau Monn=C3=A9 wrote: >> On Fri, Jun 19, 2020 at 01:41:03AM +0200, Micha=C5=82 Leszczy=C5=84ski w= rote: >>> --- a/xen/arch/x86/hvm/hvm.c >>> +++ b/xen/arch/x86/hvm/hvm.c >>> @@ -1612,6 +1612,24 @@ int hvm_vcpu_initialise(struct vcpu *v) >>> return rc; >>> } >>> =20 >>> +void hvm_vmtrace_destroy(struct vcpu *v) >>> +{ >>> + unsigned int i; >>> + struct page_info *pg; >>> + struct ipt_state *ipt =3D v->arch.hvm.vmx.ipt_state; >>> + mfn_t buf_mfn =3D ipt->output_base >> PAGE_SHIFT; >>=20 >> Does this build? I think you are missing a _mfn(...) here? >=20 > This as well as ... >=20 >>> + size_t buf_size =3D ipt->output_mask.size + 1; >>> + >>> + xfree(ipt); >>> + v->arch.hvm.vmx.ipt_state =3D NULL; >>> + >>> + for ( i =3D 0; i < (buf_size >> PAGE_SHIFT); i++ ) >>> + { >>> + pg =3D mfn_to_page(_mfn(mfn_add(buf_mfn, i))); >=20 > ... the extra _mfn() here suggest the code was only ever built in > release mode so far. >=20 > Jan Ah, I forgot to enable developer checks. This will be corrected in v3. ml From xen-devel-bounces@lists.xenproject.org Mon Jun 22 02:49:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 02:49:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnCWy-0007IT-8Q; Mon, 22 Jun 2020 02:49:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnCWx-0007IO-5A for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 02:49:55 +0000 X-Inumbo-ID: 0cc22164-b433-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0cc22164-b433-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 02:49:54 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 8A7F0A272E; Mon, 22 Jun 2020 04:49:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7E760A25C8; Mon, 22 Jun 2020 04:49:52 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 16lp179SGDVI; Mon, 22 Jun 2020 04:49:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 0AD30A272E; Mon, 22 Jun 2020 04:49:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YnUmZR3bpQ4A; Mon, 22 Jun 2020 04:49:51 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id D8CE9A25C8; Mon, 22 Jun 2020 04:49:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id C66F821B84; Mon, 22 Jun 2020 04:49:21 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id EsH0JemhSKHn; Mon, 22 Jun 2020 04:49:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 528F621BA4; Mon, 22 Jun 2020 04:49:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XifsTh83YZI6; Mon, 22 Jun 2020 04:49:16 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 34AAA21B84; Mon, 22 Jun 2020 04:49:16 +0200 (CEST) Date: Mon, 22 Jun 2020 04:49:16 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <222341136.10901881.1592794156165.JavaMail.zimbra@cert.pl> In-Reply-To: <20200619134452.GA735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <626789888.9820937.1592523621821.JavaMail.zimbra@cert.pl> <20200619134452.GA735@Air-de-Roger> Subject: Re: [PATCH v2 3/7] x86/vmx: add IPT cpu feature MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add IPT cpu feature Thread-Index: m8aeRlqjhgkyDEuDglIEjaGJfTeSrw== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , "Kang, Luwei" , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 15:44, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Fri, Jun 19, 2020 at 01:40:21AM +0200, Micha=C5=82 Leszczy=C5=84ski wr= ote: >> Check if Intel Processor Trace feature is supported by current >> processor. Define hvm_ipt_supported function. >>=20 >> Signed-off-by: Michal Leszczynski >> --- >=20 > We usually keep a shirt list of the changes between versions, so it's > easier for the reviewers to know what changed. As an example: >=20 > https://lore.kernel.org/xen-devel/20200613184132.11880-1-julien@xen.org/ >=20 >> xen/arch/x86/hvm/vmx/vmcs.c | 4 ++++ >> xen/include/asm-x86/cpufeature.h | 1 + >> xen/include/asm-x86/hvm/hvm.h | 9 +++++++++ >> xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + >> xen/include/public/arch-x86/cpufeatureset.h | 1 + >> 5 files changed, 16 insertions(+) >>=20 >> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c >> index ca94c2bedc..8466ccb912 100644 >> --- a/xen/arch/x86/hvm/vmx/vmcs.c >> +++ b/xen/arch/x86/hvm/vmx/vmcs.c >> @@ -315,6 +315,10 @@ static int vmx_init_vmcs_config(void) >> if ( opt_ept_pml ) >> opt |=3D SECONDARY_EXEC_ENABLE_PML; >> =20 >> + /* Check whether IPT is supported in VMX operation */ >> + hvm_funcs.pt_supported =3D cpu_has_ipt && >> + ( _vmx_misc_cap & VMX_MISC_PT_SUPPORTED ); >=20 > By the placement of this chunk you are tying IPT support to the > secondary exec availability, but I don't think that's required? >=20 > Ie: You should move the read of misc_cap to the top-level of the > function and perform the VMX_MISC_PT_SUPPORTED check there also. >=20 > Note that space inside parentheses is only required for conditions of > 'if', 'for' and those kind of statements, here it's not required, so > this should be: >=20 > hvm_funcs.pt_supported =3D cpu_has_ipt && > (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); >=20 > I also think this should look like: >=20 > if ( !smp_processor_id() ) > =09hvm_funcs.pt_supported =3D cpu_has_ipt && > (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); > else if ( hvm_funcs.pt_supported && > !(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED) ) > { > printk("VMX: IPT capabilities fatally differ between CPU%u and CPU= 0\n", > smp_processor_id()); > return -EINVAL; > } >=20 >=20 > So that you can detect mismatches between CPUs. I'm afraid this snippet doesn't work. All CPUs read hvm_funcs.pt_supported = as 0 even when it was set to 1 for CPU=3D0. I'm not sure if this is some mu= ltithreading issue or there is a separate hvm_funcs for each CPU? ml >=20 > Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 02:57:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 02:57:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnCeD-0008Dg-6M; Mon, 22 Jun 2020 02:57:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnCeC-0008Db-5F for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 02:57:24 +0000 X-Inumbo-ID: 173176a8-b434-11ea-be2b-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 173176a8-b434-11ea-be2b-12813bfff9fa; Mon, 22 Jun 2020 02:57:21 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 52F14A272F; Mon, 22 Jun 2020 04:57:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3E947A272E; Mon, 22 Jun 2020 04:57:19 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id sAousFnn5qOW; Mon, 22 Jun 2020 04:57:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 19A8BA272F; Mon, 22 Jun 2020 04:57:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fvZdZZPu0WMs; Mon, 22 Jun 2020 04:57:17 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id D8219A272E; Mon, 22 Jun 2020 04:57:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id C167C21BA4; Mon, 22 Jun 2020 04:56:47 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wN6l0XzX0Eh5; Mon, 22 Jun 2020 04:56:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id AB50521BAA; Mon, 22 Jun 2020 04:56:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ixqhfdNQ-5o5; Mon, 22 Jun 2020 04:56:41 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 7ADC421BA4; Mon, 22 Jun 2020 04:56:41 +0200 (CEST) Date: Mon, 22 Jun 2020 04:56:41 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Xen-devel Message-ID: <227951948.10901979.1592794601349.JavaMail.zimbra@cert.pl> In-Reply-To: <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: hSzh8Vr462omVBiCuz/GiNtdRkOdyEuhVFaUn2lwLpo= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jun Nakajima , Tamas K Lengyel , "Kang, Luwei" , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 1:41, Micha=C5=82 Leszczy=C5=84ski michal.leszczynski@c= ert.pl napisa=C5=82(a): > Provide an interface for privileged domains to manage > external IPT monitoring. Guest IPT state will be preserved > across vmentry/vmexit using ipt_state structure. >=20 > Signed-off-by: Michal Leszczynski > --- > xen/arch/x86/hvm/hvm.c | 167 +++++++++++++++++++++++++++++ > xen/arch/x86/hvm/vmx/vmx.c | 24 +++++ > xen/arch/x86/mm.c | 37 +++++++ > xen/common/domain.c | 1 + > xen/include/asm-x86/hvm/vmx/vmcs.h | 16 +++ > xen/include/public/hvm/hvm_op.h | 23 ++++ > xen/include/public/hvm/params.h | 5 +- > xen/include/public/memory.h | 1 + > xen/include/xen/sched.h | 3 + > 9 files changed, 276 insertions(+), 1 deletion(-) >=20 > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 5bb47583b3..145ad053d2 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -1612,6 +1612,24 @@ int hvm_vcpu_initialise(struct vcpu *v) > return rc; > } >=20 > +void hvm_vmtrace_destroy(struct vcpu *v) > +{ > + unsigned int i; > + struct page_info *pg; > + struct ipt_state *ipt =3D v->arch.hvm.vmx.ipt_state; > + mfn_t buf_mfn =3D ipt->output_base >> PAGE_SHIFT; > + size_t buf_size =3D ipt->output_mask.size + 1; > + > + xfree(ipt); > + v->arch.hvm.vmx.ipt_state =3D NULL; > + > + for ( i =3D 0; i < (buf_size >> PAGE_SHIFT); i++ ) > + { > + pg =3D mfn_to_page(_mfn(mfn_add(buf_mfn, i))); > + free_domheap_page(pg); > + } > +} > + > void hvm_vcpu_destroy(struct vcpu *v) > { > viridian_vcpu_deinit(v); > @@ -1631,6 +1649,8 @@ void hvm_vcpu_destroy(struct vcpu *v) > vlapic_destroy(v); >=20 > hvm_vcpu_cacheattr_destroy(v); > + > + hvm_vmtrace_destroy(v); > } >=20 > void hvm_vcpu_down(struct vcpu *v) > @@ -4066,6 +4086,51 @@ static int hvmop_set_evtchn_upcall_vector( > return 0; > } >=20 > +static int hvm_set_vmtrace_pt_size(struct domain *d, uint64_t value) > +{ > + void *buf; > + unsigned int buf_order; > + struct page_info *pg; > + struct ipt_state *ipt; > + struct vcpu *v; > + > + if ( value < PAGE_SIZE || > + value > GB(4) || > + ( value & (value - 1) ) ) { > + /* we don't accept trace buffer size smaller than single page > + * and the upper bound is defined as 4GB in the specification */ > + return -EINVAL; > + } > + > + for_each_vcpu ( d, v ) > + { > + buf_order =3D get_order_from_bytes(value); > + pg =3D alloc_domheap_pages(d, buf_order, MEMF_no_refcount); > + > + if ( !pg ) > + return -EFAULT; > + > + buf =3D page_to_virt(pg); > + > + if ( vmx_add_host_load_msr(v, MSR_RTIT_CTL, 0) ) > + return -EFAULT; > + > + ipt =3D xmalloc(struct ipt_state); > + > + if ( !ipt ) > + return -EFAULT; > + > + ipt->output_base =3D virt_to_mfn(buf) << PAGE_SHIFT; > + ipt->output_mask.raw =3D value - 1; > + ipt->status =3D 0; > + ipt->active =3D 0; > + > + v->arch.hvm.vmx.ipt_state =3D ipt; > + } > + > + return 0; > +} > + > static int hvm_allow_set_param(struct domain *d, > uint32_t index, > uint64_t new_value) > @@ -4127,6 +4192,7 @@ static int hvm_allow_set_param(struct domain *d, > case HVM_PARAM_NR_IOREQ_SERVER_PAGES: > case HVM_PARAM_ALTP2M: > case HVM_PARAM_MCA_CAP: > + case HVM_PARAM_VMTRACE_PT_SIZE: > if ( value !=3D 0 && new_value !=3D value ) > rc =3D -EEXIST; > break; > @@ -4328,6 +4394,9 @@ static int hvm_set_param(struct domain *d, uint32_t= index, > uint64_t value) > case HVM_PARAM_MCA_CAP: > rc =3D vmce_enable_mca_cap(d, value); > break; > + case HVM_PARAM_VMTRACE_PT_SIZE: > + rc =3D hvm_set_vmtrace_pt_size(d, value); > + break; > } >=20 > if ( !rc ) > @@ -4949,6 +5018,100 @@ static int compat_altp2m_op( > return rc; > } >=20 > +static int do_vmtrace_op(XEN_GUEST_HANDLE_PARAM(void) arg) > +{ > + struct xen_hvm_vmtrace_op a; > + struct domain *d; > + int rc; > + struct vcpu *v; > + struct ipt_state *ipt; > + > + if ( !hvm_pt_supported() ) > + return -EOPNOTSUPP; > + > + if ( copy_from_guest(&a, arg, 1) ) > + return -EFAULT; > + > + if ( a.version !=3D HVMOP_VMTRACE_INTERFACE_VERSION ) > + return -EINVAL; > + > + d =3D rcu_lock_domain_by_any_id(a.domain); > + spin_lock(&d->vmtrace_lock); > + > + if ( d =3D=3D NULL ) > + return -ESRCH; > + > + if ( !is_hvm_domain(d) ) > + { > + rc =3D -EOPNOTSUPP; > + goto out; > + } > + > + domain_pause(d); > + > + if ( a.vcpu >=3D d->max_vcpus ) > + { > + rc =3D -EINVAL; > + goto out; > + } > + > + v =3D d->vcpu[a.vcpu]; > + ipt =3D v->arch.hvm.vmx.ipt_state; > + > + if ( !ipt ) > + { > + /* > +=09 * PT must be first initialized upon domain creation. > +=09 */ > + rc =3D -EINVAL; > + goto out; > + } > + > + switch ( a.cmd ) > + { > + case HVMOP_vmtrace_ipt_enable: > + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, > + RTIT_CTL_TRACEEN | RTIT_CTL_OS | > + RTIT_CTL_USR | RTIT_CTL_BRANCH_EN) ) > + { > + rc =3D -EFAULT; > + goto out; > + } > + > + ipt->active =3D 1; > + break; > + case HVMOP_vmtrace_ipt_disable: > + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, 0) ) > + { > + rc =3D -EFAULT; > + goto out; > + } > + > + ipt->active =3D 0; > + break; > + case HVMOP_vmtrace_ipt_get_offset: > + a.offset =3D ipt->output_mask.offset; > + break; > + default: > + rc =3D -EOPNOTSUPP; > + goto out; > + } > + > + rc =3D -EFAULT; > + if ( __copy_to_guest(arg, &a, 1) ) > + goto out; > + rc =3D 0; > + > + out: > + domain_unpause(d); > + spin_unlock(&d->vmtrace_lock); > + rcu_unlock_domain(d); > + > + return rc; > +} > + > +DEFINE_XEN_GUEST_HANDLE(compat_hvm_vmtrace_op_t); > + > static int hvmop_get_mem_type( > XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg) > { > @@ -5101,6 +5264,10 @@ long do_hvm_op(unsigned long op, > XEN_GUEST_HANDLE_PARAM(void) arg) > rc =3D current->hcall_compat ? compat_altp2m_op(arg) : do_altp2m_= op(arg); > break; >=20 > + case HVMOP_vmtrace: > + rc =3D do_vmtrace_op(arg); > + break; > + > default: > { > gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op); > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c > index ab19d9424e..51f0046483 100644 > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -508,11 +508,25 @@ static void vmx_restore_host_msrs(void) >=20 > static void vmx_save_guest_msrs(struct vcpu *v) > { > + uint64_t rtit_ctl; > + > /* > * We cannot cache SHADOW_GS_BASE while the VCPU runs, as it can > * be updated at any time via SWAPGS, which we cannot trap. > */ > v->arch.hvm.vmx.shadow_gs =3D rdgsshadow(); > + > + if ( unlikely(v->arch.hvm.vmx.ipt_state && > v->arch.hvm.vmx.ipt_state->active) ) > + { > + smp_rmb(); > + rdmsrl(MSR_RTIT_CTL, rtit_ctl); > + > + if ( rtit_ctl & RTIT_CTL_TRACEEN ) > + BUG(); > + > + rdmsrl(MSR_RTIT_STATUS, v->arch.hvm.vmx.ipt_state->status); > + rdmsrl(MSR_RTIT_OUTPUT_MASK, > v->arch.hvm.vmx.ipt_state->output_mask.raw); > + } > } It was suggested to move this piece of code from vm-entry/vm-exit handling = to vmx_save_guest_msrs/vmx_restore_guest_msrs functions. Please note that we do need to periodically read MSR_RTIT_OUTPUT_MASK in or= der to know how much data was written into the buffer by the processor. During = tests, I've spotted that in some cases vCPUs get out of scope very rarely. For instance: when IPT gets enabled, xc_vmtrace_ipt_get_offset() is returni= ng zero value for the first few seconds, because it's relying on the value of v->arch.hvm.vmx.ipt_state->output_mask which we only read in vmx_save_guest= _msrs() and in some cases this occurs very rarely. Could you guys suggest some solution to the problem? If we would leave this= value dirty in hardware, AFAIK we have no possibility to directly access it, but observing this particular value is very important in the runtime. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska >=20 > static void vmx_restore_guest_msrs(struct vcpu *v) > @@ -524,6 +538,16 @@ static void vmx_restore_guest_msrs(struct vcpu *v) >=20 > if ( cpu_has_msr_tsc_aux ) > wrmsr_tsc_aux(v->arch.msrs->tsc_aux); > + > + if ( unlikely(v->arch.hvm.vmx.ipt_state && > v->arch.hvm.vmx.ipt_state->active) ) > + { > + wrmsrl(MSR_RTIT_OUTPUT_BASE, > + v->arch.hvm.vmx.ipt_state->output_base); > + wrmsrl(MSR_RTIT_OUTPUT_MASK, > + v->arch.hvm.vmx.ipt_state->output_mask.raw); > + wrmsrl(MSR_RTIT_STATUS, > + v->arch.hvm.vmx.ipt_state->status); > + } > } >=20 > void vmx_update_cpu_exec_control(struct vcpu *v) > diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c > index e376fc7e8f..e4658dc27f 100644 > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -4624,6 +4624,43 @@ int arch_acquire_resource(struct domain *d, unsign= ed int > type, > } > break; > } > + > + case XENMEM_resource_vmtrace_buf: > + { > + mfn_t mfn; > + unsigned int i; > + struct ipt_state *ipt; > + > + if ( id >=3D d->max_vcpus ) > + { > + rc =3D -EINVAL; > + break; > + } > + > + ipt =3D d->vcpu[id]->arch.hvm.vmx.ipt_state; > + > + if ( !ipt ) > + { > + rc =3D -EINVAL; > + break; > + } > + > + mfn =3D mfn_x(ipt->output_base >> PAGE_SHIFT); > + > + if (nr_frames > ( ( ipt->output_mask.size + 1 ) >> PAGE_SHIFT )) > + { > + rc =3D -EINVAL; > + break; > + } > + > + rc =3D 0; > + for ( i =3D 0; i < nr_frames; i++ ) > + { > + mfn_list[i] =3D mfn_add(mfn, i); > + } > + > + break; > + } > #endif >=20 > default: > diff --git a/xen/common/domain.c b/xen/common/domain.c > index 7cc9526139..6f6458cd5b 100644 > --- a/xen/common/domain.c > +++ b/xen/common/domain.c > @@ -414,6 +414,7 @@ struct domain *domain_create(domid_t domid, > d->shutdown_code =3D SHUTDOWN_CODE_INVALID; >=20 > spin_lock_init(&d->pbuf_lock); > + spin_lock_init(&d->vmtrace_lock); >=20 > rwlock_init(&d->vnuma_rwlock); >=20 > diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h > b/xen/include/asm-x86/hvm/vmx/vmcs.h > index 4c81093aba..9fc4653777 100644 > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h > @@ -104,6 +104,19 @@ struct pi_blocking_vcpu { > spinlock_t *lock; > }; >=20 > +struct ipt_state { > + uint64_t active; > + uint64_t status; > + uint64_t output_base; > + union { > + uint64_t raw; > + struct { > + uint32_t size; > + uint32_t offset; > + }; > + } output_mask; > +}; > + > struct vmx_vcpu { > /* Physical address of VMCS. */ > paddr_t vmcs_pa; > @@ -186,6 +199,9 @@ struct vmx_vcpu { > * pCPU and wakeup the related vCPU. > */ > struct pi_blocking_vcpu pi_blocking; > + > + /* State of Intel Processor Trace feature */ > + struct ipt_state *ipt_state; > }; >=20 > int vmx_create_vmcs(struct vcpu *v); > diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm= _op.h > index 870ec52060..8cd0b6ea49 100644 > --- a/xen/include/public/hvm/hvm_op.h > +++ b/xen/include/public/hvm/hvm_op.h > @@ -382,6 +382,29 @@ struct xen_hvm_altp2m_op { > typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; > DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); >=20 > +/* HVMOP_vmtrace: Perform VM tracing related operation */ > +#define HVMOP_vmtrace 26 > + > +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 > + > +struct xen_hvm_vmtrace_op { > + /* IN variable */ > + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ > + uint32_t cmd; > +/* Enable/disable external vmtrace for given domain */ > +#define HVMOP_vmtrace_ipt_enable 1 > +#define HVMOP_vmtrace_ipt_disable 2 > +#define HVMOP_vmtrace_ipt_get_offset 3 > + domid_t domain; > + uint32_t vcpu; > + uint64_t size; > + > + /* OUT variable */ > + uint64_t offset; > +}; > +typedef struct xen_hvm_vmtrace_op xen_hvm_vmtrace_op_t; > +DEFINE_XEN_GUEST_HANDLE(xen_hvm_vmtrace_op_t); > + > #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */ >=20 > /* > diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/par= ams.h > index 0a91bfa749..adbc7e5d08 100644 > --- a/xen/include/public/hvm/params.h > +++ b/xen/include/public/hvm/params.h > @@ -300,6 +300,9 @@ > #define XEN_HVM_MCA_CAP_LMCE (xen_mk_ullong(1) << 0) > #define XEN_HVM_MCA_CAP_MASK XEN_HVM_MCA_CAP_LMCE >=20 > -#define HVM_NR_PARAMS 39 > +/* VM trace capabilities */ > +#define HVM_PARAM_VMTRACE_PT_SIZE 39 > + > +#define HVM_NR_PARAMS 40 >=20 > #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */ > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h > index dbd35305df..f823c784c3 100644 > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -620,6 +620,7 @@ struct xen_mem_acquire_resource { >=20 > #define XENMEM_resource_ioreq_server 0 > #define XENMEM_resource_grant_table 1 > +#define XENMEM_resource_vmtrace_buf 2 >=20 > /* > * IN - a type-specific resource identifier, which must be zero > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h > index ac53519d7f..b3a36f3788 100644 > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -457,6 +457,9 @@ struct domain > unsigned pbuf_idx; > spinlock_t pbuf_lock; >=20 > + /* Used by vmtrace domctls */ > + spinlock_t vmtrace_lock; > + > /* OProfile support. */ > struct xenoprof *xenoprof; >=20 > -- > 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 03:01:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 03:01:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnCi2-00013E-Ny; Mon, 22 Jun 2020 03:01:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnCi1-000139-OR for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 03:01:21 +0000 X-Inumbo-ID: a5d38266-b434-11ea-be2b-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a5d38266-b434-11ea-be2b-12813bfff9fa; Mon, 22 Jun 2020 03:01:20 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id B7394A2735; Mon, 22 Jun 2020 05:01:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A5B72A271A; Mon, 22 Jun 2020 05:01:18 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id mWQqzyt6Udb5; Mon, 22 Jun 2020 05:01:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2993BA2735; Mon, 22 Jun 2020 05:01:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EL9kClQGd2SP; Mon, 22 Jun 2020 05:01:18 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 09DB8A271A; Mon, 22 Jun 2020 05:01:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id EDBD521A10; Mon, 22 Jun 2020 05:00:47 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id u8sh5X4nkqzO; Mon, 22 Jun 2020 05:00:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 783BC21A91; Mon, 22 Jun 2020 05:00:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ySI8ykVHcZe3; Mon, 22 Jun 2020 05:00:42 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 4D49921A10; Mon, 22 Jun 2020 05:00:42 +0200 (CEST) Date: Mon, 22 Jun 2020 05:00:42 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <934104575.10902082.1592794842242.JavaMail.zimbra@cert.pl> In-Reply-To: <4cbf963d-7cf0-3fdb-b456-db2845244dec@suse.com> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1060400786.9820894.1592523480084.JavaMail.zimbra@cert.pl> <20200619113434.GZ735@Air-de-Roger> <1494219989.10184041.1592570120971.JavaMail.zimbra@cert.pl> <4cbf963d-7cf0-3fdb-b456-db2845244dec@suse.com> Subject: Re: [PATCH v2 1/7] xen/mm: lift 32 item limit from mfn/gfn arrays MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: xen/mm: lift 32 item limit from mfn/gfn arrays Thread-Index: pF59bWH9iYKvzECv6qANtkxo1o7SkA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Tamas K Lengyel , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 19 cze 2020 o 14:39, Jan Beulich jbeulich@suse.com napisa=C5=82(a): > On 19.06.2020 14:35, Micha=C5=82 Leszczy=C5=84ski wrote: >> ----- 19 cze 2020 o 13:34, Roger Pau Monn=C3=A9 roger.pau@citrix.com nap= isa=C5=82(a): >>=20 >>> On Fri, Jun 19, 2020 at 01:38:00AM +0200, Micha=C5=82 Leszczy=C5=84ski = wrote: >>>> Replace on-stack array allocation with heap allocation >>>> in order to lift the limit of 32 items in mfn/gfn arrays >>>> when calling acquire_resource. >>> >>> I'm afraid this is not correct, you cannot allow unbounded amounts of >>> items to be processed like this, it's likely that you manage to >>> trigger the watchdog if the list is long enough, specially when doing >>> set_foreign_p2m_entry. >>> >>> You need to process the items in batches (32 was IMO a good start), and >>> then add support for hypercall continuations. Take a look at how >>> XENMEM_populate_physmap just a couple of lines below makes use of >>> hypercall_create_continuation. >>> >>> After processing every batch you need to check if >>> hypercall_preempt_check returns true and if so use >>> hypercall_create_continuation in order to encode a continuation. >>=20 >> One more question. Are these continuations transparent from the caller s= ide, >> or do I also need to add something on the invoker side to properly handl= e these >> continuations? >=20 > They are (mostly) transparent to the guest, yes. "Mostly" because we > have cases (iirc) where the continuation data is stored in a way that > a guest could observe it. But it still wouldn't need to do anything > in order for the hypercall to get continued until it completes (which > may be "fails", faod). >=20 > Jan Okay, I've managed to implement continuations while still having these arra= y small. The operation could simply process max. 32 elements at the time and creates= continuation until everything gets processed. This will be in patch v3. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Mon Jun 22 06:00:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 06:00:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnFVP-0000CA-PW; Mon, 22 Jun 2020 06:00:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnFVO-0000C5-Jt for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 06:00:30 +0000 X-Inumbo-ID: aa541648-b44d-11ea-be40-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id aa541648-b44d-11ea-be40-12813bfff9fa; Mon, 22 Jun 2020 06:00:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9QDQG9CY2+2QO2ci7szBCwrFAbFWfFp/MNzS8YDNRko=; b=nPpbEpMH9FxkcMNBbVH8BKxnP HvE0PaekrhQSr2Me1nFk4AKWmNoLNqeJd0X1GA/OkteZpSPhJ7yWNQPVz/JK6P0EMadncUNN3T0kI iiAKMJY8MAtrdAR9rVt1xMY1/abeV6QzWfpcR6N421FJawxMa5ltFmKxgPmy+fs+FcH+g=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnFVI-0006z7-QP; Mon, 22 Jun 2020 06:00:24 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnFVI-0003w8-Gj; Mon, 22 Jun 2020 06:00:24 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnFVI-0007Wr-G4; Mon, 22 Jun 2020 06:00:24 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151269: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-xl-rtds:guest-start:fail:allowable qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=06c4cc3660b366278bdc7bc8b6677032d7b1118c X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Mon, 22 Jun 2020 06:00:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151269 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151269/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: qemuu 06c4cc3660b366278bdc7bc8b6677032d7b1118c baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 9 days Failing since 151101 2020-06-14 08:32:51 Z 7 days 6 attempts Testing same since 151241 2020-06-20 01:36:13 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Anthony PERARD Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Cathy Zhang Christian Borntraeger Claudio Fontana Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Gerd Hoffmann Guenter Roeck Helge Deller Igor Mammedov Janne Grunau Jason Wang Jean-Christophe Dubois Jiaxun Yang John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marek Marczykowski-Górecki Markus Armbruster Masahiro Yamada Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Stefan Berger Stefan Hajnoczi Thomas Huth Tong Ho WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 8468 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 22 07:46:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 07:46:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnH9h-0000YS-Lz; Mon, 22 Jun 2020 07:46:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnH9h-0000YN-0i for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 07:46:13 +0000 X-Inumbo-ID: 707d0dc6-b45c-11ea-be48-12813bfff9fa Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.64]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 707d0dc6-b45c-11ea-be48-12813bfff9fa; Mon, 22 Jun 2020 07:46:12 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FP5a1peS0NMlG0qOmZ+msQPAWPKTpiiHxNyRYOXGIUfZsNZYPdg1dceXXf4zEoefO7PTGk44ZePUIcP+pflFlPhF+ftfIzU3Jz1dSaLbzEwisY1eVcAjSU92UAT93x3c8RrEY6PFnY96MTKMmhXM4Mr86QLG1s3J1MO0I2RxUtLwYAjEetWikyvL9TThcDguXdfY0bPZEGnmD28d5TcIZnvySh1+tDzOFLtYLQuRdF+fA3rD/f/Q6+eKgTJvQCu0U2UP+qcRa31P0Kf1GcVc7g9W8HFPTNxMirUwyaQrYMmud2eCPZL/PgdskfE1jUBoUOsQSLBtI2scOdl3ebY3GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rIXjtw8rpt2im2PJqVoJPd6ABNVHoSLEN5afQ+Pr+cQ=; b=kVSv8ff7/zu6Y0riNUm0TEwuBfhXeSbDG0qac3f1PlXjD8J00guK3lzCviNxM7tg5TPrmdgn8xrOyPr0RdyxKw+AjeqFAaKObZnkxrTYIZiUd6T9cTbQCRXegCF+NYiz4kP0jcYx6O2xQ40w/vbaAsbsUt4a2Gsv11FONOc3lgntOL3D6u+JulNNaDl9jPUfqADpRhsUOlFKHzO8vAs8pWT44fZ15GCNPyXKkESdK6w6/8T7la4CTxV0pTYbJVGk+s41uCiMDShgBlmqV1XRn21RI3iA4u7KRvHMYYhJCP1JHKOF2m+jYqXEgIOijWAvC1DZXB6nJOAyU0HxydGh2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rIXjtw8rpt2im2PJqVoJPd6ABNVHoSLEN5afQ+Pr+cQ=; b=kIC7XXX0eL/utehsyeSPutaAdCFwxa0ci3HtdeM7hoPC+OVxdIsWysVqvs4Med34uui/5by7qadISAPZLJWD1b6Kw3X3p32sMvDQoJ80N+RRvBvHbPc0+GcAXxYWI15hCD/aDIeMfL9sGCm25Wp0y3ql64Uv/ZLug22Olz71WWgJDn/EOkXlMg57UMx0QDD0ssJLkIH6sIhNiNtqJ0twSLj3s+Wko6VdmqhYHsU4LaonPz4J8H75eoIp2AYjxLPdsiCZ7ocnBD66RyKTBVGuUQV3O4Tf74gC7WybiEBMRO0pAwHnfD+pXDRi/j6OiH33Eq0lV2SIVgemlwQiljF4sQ== Authentication-Results: student.uw.edu.pl; dkim=none (message not signed) header.d=none; student.uw.edu.pl; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB7039.eurprd04.prod.outlook.com (2603:10a6:800:12b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 22 Jun 2020 07:46:09 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 07:46:09 +0000 Subject: Re: [PATCH v2 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: Grzegorz Uriasz References: From: Jan Beulich Message-ID: Date: Mon, 22 Jun 2020 09:45:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: FR2P281CA0025.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::12) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by FR2P281CA0025.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:14::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23 via Frontend Transport; Mon, 22 Jun 2020 07:46:08 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 37a3eec4-9f03-408c-e139-08d8168053c0 X-MS-TrafficTypeDiagnostic: VI1PR04MB7039: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XZ3HxIDtLHl1yIDrOgPLtd5ZPGX4DmdThZgz7SsIR+JjDaxOtfVuRhH/XTLW+15D8OQEewRwobCagy/VGlIsdCX0zcq1F0O4YuGsZlf7+zi8IIXjIZKRv+QIYF+f207njK2FjMKj+fwDM7iL27K9LY0/gMNZZeQcszAw4oUwepah7gC/8t4cyemLTCDslh7ZlBgQ3dDiVqdf6qM7Gf5LLZJAi42Aw26TkpXlwpHZ2ONPIEraQAT5byYTM7vaml0ZQUby25U2/mcGWRKriD9BPPDSz8QwXQV0GQG0EhZWusDC14BmqWd/8Colh5lNATPItsx0O/lSqiE0vCj+s6HyqOMJiK4MOZJTnHouETftd9518jWxjqorGe1JC18q9doS X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(396003)(376002)(39850400004)(366004)(136003)(346002)(31686004)(16576012)(478600001)(16526019)(26005)(186003)(53546011)(52116002)(316002)(8936002)(2616005)(5660300002)(66556008)(6916009)(66476007)(54906003)(2906002)(66946007)(6666004)(6486002)(956004)(4326008)(86362001)(31696002)(83380400001)(8676002)(36756003)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: xUpNIB4hUITUkgTxgBD6u4HuhgLjwBWuUFXtHiUy1GB3x5BTn9MokJYQ0ofmAgv0zGOIEiNt/+O6U2L9S2Exhi1xtbgBQ21VHYpK44vEyHaB0CsUToN9Jhxp8e87A0lN0O/rNHChGwFk5MUA7mz9FYPNJ+ff3OL1IZ8ik72XH3Tgrw9jgdi7l89ti2eYaNMLd6fJmSUKtYBwAuIik+IsXpSCwYdjFLi/mO7FZnyuR9LEcD+G3nYp8/S6t+CX+XIB8Tde+ZbkowbvEaFDDov+qjF/JLgbCdfx//LSLtYBBMssH05V/9rp6lNA3aWOOLLN4PgZHhLu/euO5qxkOS3XHiSVT0inhDWBg0LgVAg7l/01m+qFGvwevh69+DFU0d3cn7TmNDzCFDpjIih0NYpGk+kl03oL0tmaVYgCe4/c60Y= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37a3eec4-9f03-408c-e139-08d8168053c0 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 07:46:09.6225 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: FUuqKChsNYGZs1MpU+4PKlbW27uX3hKcPdquzcm6e18Db0BHG02B0gzam8Csmes3iqAMWYkL16C4W5PIY+muag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB7039 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: artur@puzio.waw.pl, Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 20:23, Grzegorz Uriasz wrote: > On 19/06/2020 15:17, Jan Beulich wrote: >> On 19.06.2020 06:28, Grzegorz Uriasz wrote: >>> --- a/xen/arch/x86/time.c >>> +++ b/xen/arch/x86/time.c >>> @@ -457,16 +457,16 @@ static u64 read_pmtimer_count(void) >>> static s64 __init init_pmtimer(struct platform_timesource *pts) >>> { >>> u64 start; >>> - u32 count, target, mask = 0xffffff; >>> + u32 count, target, mask; >>> >>> - if ( !pmtmr_ioport || !pmtmr_width ) >>> + if ( !pmtmr_ioport ) >>> return 0; >>> >>> - if ( pmtmr_width == 32 ) >>> - { >>> - pts->counter_bits = 32; >>> - mask = 0xffffffff; >>> - } >>> + if ( pmtmr_width != 24 && pmtmr_width != 32 ) >>> + return 0; >>> + >>> + pts->counter_bits = (int) pmtmr_width; >>> + mask = (1ull << pmtmr_width) - 1; >>> >>> count = inl(pmtmr_ioport) & mask; >>> start = rdtsc_ordered(); >>> @@ -486,7 +486,6 @@ static struct platform_timesource __initdata plt_pmtimer = >>> .name = "ACPI PM Timer", >>> .frequency = ACPI_PM_FREQUENCY, >>> .read_counter = read_pmtimer_count, >>> - .counter_bits = 24, >>> .init = init_pmtimer >>> }; >> I'm struggling a little to see why this code churn is needed / wanted. >> The change I had suggested was quite a bit less intrusive. I'm not >> entirely opposed though, but at the very least please drop the odd >> (int) cast. If anything we want the struct field changed to unsigned >> int (but unlikely in this very patch). >> >> If you want to stick to this larger change, then also please fold the >> two if()s at the beginning of the function. > > I wanted to avoid hard coding the masks -> Linux has a nice macro for > generating the masks but I haven't found a similar macro in xen. > Additionally this version sets the counter width in a single place > instead of two. I guessed this was the goal, but I think such adjustments, if indeed wanted, would better go into a separate patch. The bug fix here wants backporting, while this extra cleanup probably doesn't. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 08:31:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 08:31:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnHrX-0005NR-Gu; Mon, 22 Jun 2020 08:31:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnHrW-0005NM-9b for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 08:31:30 +0000 X-Inumbo-ID: c186dae8-b462-11ea-be4b-12813bfff9fa Received: from EUR02-AM5-obe.outbound.protection.outlook.com (unknown [40.107.0.41]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c186dae8-b462-11ea-be4b-12813bfff9fa; Mon, 22 Jun 2020 08:31:24 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TDgYWfQE2km+PJgZcpWkrua+galLBdruqY10D0Yf8q+zvCoz5Hy7Itg7BHb2CK02iWBV0cAeTbJQucrR6GgEMq2nkInhebA0LYlPTDWcYLrBEZ+Kt7hk+aYXski56buQznYSaKeEkE8TohFbC1ImRJNIFo540kGQiGpAsUWJdrwzI+P6UIbK1mj2lTtT5FXeOL2m3FYvvIanBq0sBbpP63uf4qmtX/eG3KlJhwpnR0aAtpDwC7gvirCnnO/PFUiyOa97gQKagiyKNz5jFYJNbP4FIw7JkEByy/WfeBqhDYP7WT/tONCtDn5xEkg/G4xvGHj4i44NxXpvNXzkibnlBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=25ytYj9uCGoj+ojl69tAQKmC4JucJCp9GoThbB8TDmk=; b=jWb7S5WLybFNLzo3oIUrmZajuP264eQARRH1jiEESM5C5CHW1zQTEoVAVVoKRtZ/ZMjkfAqEIHD/NB+e5kAlupRYviwtojiNBWZe2KpeXgmgozW5Lg4KsLUp1bhdxEEtZ/tmdVCZPLU4ZeMwHzjYyFlJjdyE+jTD9Hl7Vo5FrbUB9+tGEkIHH6o88QfMGl4K/SLrWWzuWG4Xf9kI/48MQ+i6jClOUeIgExl+b2naz4pYBPfRgdYN9VENJDgt0/qdRuCyDzMsug2IivaO7D3u3oz6enQOMVnzyvmIn8O0a6Unzk4xIw1/L535cwy9Hvef0hERn+UjY2qousGU58Tagw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=25ytYj9uCGoj+ojl69tAQKmC4JucJCp9GoThbB8TDmk=; b=MOixHdnaTXOJi6PNKXhANOQdRGs5VWrpsvA9h8UZ1b9A4vQegXehXegm4XZo9R13fAVItqiw23/3OoSQ+C43TUMrCYAyLIWgWK33PZBcUdN1DSRy3W+O+Dn9UpdVCMZ0h95CsdZMkdpeEXsUPL+H2KPG7FfauuCaNGXbDwkPrDBD8xWXpLbMKIewKcrJYB3tomqBvgssSoROqJAqJdHHOjc0l1P0rnnyIrEGSkGVySJbSSF67OrVBBZWI7Mf4b/s4jlELNMYQ8Un8ZwR2/dWtlNUi6ZbQeWREWQmiQHwIH0l5ZWXRDq6VcuN3FlbIFOiX2hIZVtSJMYu6WLJ0SYiSQ== Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB5454.eurprd04.prod.outlook.com (2603:10a6:803:d1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Mon, 22 Jun 2020 08:31:22 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 08:31:22 +0000 Subject: Re: [PATCH v2 3/7] x86/vmx: add IPT cpu feature To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <626789888.9820937.1592523621821.JavaMail.zimbra@cert.pl> <20200619134452.GA735@Air-de-Roger> <222341136.10901881.1592794156165.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <4dc53352-3936-efc8-c21c-54053fe210f7@suse.com> Date: Mon, 22 Jun 2020 10:31:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <222341136.10901881.1592794156165.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR02CA0077.eurprd02.prod.outlook.com (2603:10a6:208:154::18) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM0PR02CA0077.eurprd02.prod.outlook.com (2603:10a6:208:154::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Mon, 22 Jun 2020 08:31:21 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5562369b-e065-40f8-4ed4-08d81686a4b3 X-MS-TrafficTypeDiagnostic: VI1PR04MB5454: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fxKa5FC3w5J5LCdNJJoVhjtgrScYgA49FfJm0x/9uGsdP2/QSoJ5FnEpH/NdXki3S8gMSz7lAh0s3LCQAOgqJ0N6LKqhAjyeDb7Eah8/rYC+4amEqAADiCmA/9+2DW15MT7MB89CDlAWiLFz45uCNVmuUYLsBvYjqE9GVf1zoSHIRsL9FBlLgAtlpEa+Vcur2U91/u9x/spGyEXIHSuXQMRAHNmpexQ5xiqhHuLT9+WAzr9PFEJe/5vZXJfleuviq5908tFsxzl8obQmHwDjh+1FZW+afuYrvRI2O0ux58gWT0Ep/Iby5ZVRxzb0c25zHvafqE6x8eJwXxbf6KLGgBeafdZcHH/AXjxvwJ30hNXxlQH1NQ/TVBGkkbnguPMsdflNv1Hwl+SWnwl7IJlbtg6h/g6MaPRbuTvNwnep77f5B+q01qH1nfKmtBNBJR0FBc8s5uPW4ZT/VTkh+MctUA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(396003)(39860400002)(346002)(376002)(366004)(2616005)(66476007)(66946007)(66556008)(31696002)(26005)(6916009)(6666004)(53546011)(956004)(6486002)(16526019)(2906002)(186003)(86362001)(36756003)(478600001)(966005)(316002)(16576012)(52116002)(5660300002)(8936002)(83380400001)(66574015)(54906003)(4326008)(31686004)(8676002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: xtRGtJRypGnrGYA9B/7Vv1sfZCxXgRkxJ0WmK/1KoCqnSoWKgz4ItZqT//SsV++ueSZ8edeAII5HFhzaQvSHzTS812gPtHHCAADuRM4sUQLcnuH2vsGmD2kcWx+XW6Wkk5U4CNNMe0cymm8vFlgHUs0ajro7H0k2shk9K7wJEU/OKsL4nepMfkmKjpgtZICL5FVtx/9v8OPkGpNo0vdbDQLCMaNWo0UWDOipEsc7P9jA8J8YbENowNP96MaWS4+XUQMLG3+wWzC/2XMBi5U5PCffA3uAxjUhCx+8S6pPBtIM4cWdoYxMWhYYkbi0+sSLMQcvU/dmekUXlltiOLvovgo2nUdj8ExRh+IlkhR9i5bc5RaRDwKO/WtfyTPG4FEdPnslXG3NIl9vgy4gO+Gn7dHDB++0a4aSilj095/5OHX9ZaByVdDvcfjsnYtfi40/pNHJryDpi1qoqs9jcS0ypAn6CiIkKNB0sVlz69uJzqc= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5562369b-e065-40f8-4ed4-08d81686a4b3 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 08:31:21.8807 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: DOdceobeyRxud/ZKnCSQ5c8keNl6PY82M3CLt3lF5P0WJXF9paCl99mrqCb2LJDj8TwQE92zIMDFowL+5Pp3SA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5454 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , "Kang, Luwei" , Wei Liu , Andrew Cooper , Jun Nakajima , Tamas K Lengyel , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 04:49, Michał Leszczyński wrote: > ----- 19 cze 2020 o 15:44, Roger Pau Monné roger.pau@citrix.com napisał(a): > >> On Fri, Jun 19, 2020 at 01:40:21AM +0200, Michał Leszczyński wrote: >>> Check if Intel Processor Trace feature is supported by current >>> processor. Define hvm_ipt_supported function. >>> >>> Signed-off-by: Michal Leszczynski >>> --- >> >> We usually keep a shirt list of the changes between versions, so it's >> easier for the reviewers to know what changed. As an example: >> >> https://lore.kernel.org/xen-devel/20200613184132.11880-1-julien@xen.org/ >> >>> xen/arch/x86/hvm/vmx/vmcs.c | 4 ++++ >>> xen/include/asm-x86/cpufeature.h | 1 + >>> xen/include/asm-x86/hvm/hvm.h | 9 +++++++++ >>> xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + >>> xen/include/public/arch-x86/cpufeatureset.h | 1 + >>> 5 files changed, 16 insertions(+) >>> >>> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c >>> index ca94c2bedc..8466ccb912 100644 >>> --- a/xen/arch/x86/hvm/vmx/vmcs.c >>> +++ b/xen/arch/x86/hvm/vmx/vmcs.c >>> @@ -315,6 +315,10 @@ static int vmx_init_vmcs_config(void) >>> if ( opt_ept_pml ) >>> opt |= SECONDARY_EXEC_ENABLE_PML; >>> >>> + /* Check whether IPT is supported in VMX operation */ >>> + hvm_funcs.pt_supported = cpu_has_ipt && >>> + ( _vmx_misc_cap & VMX_MISC_PT_SUPPORTED ); >> >> By the placement of this chunk you are tying IPT support to the >> secondary exec availability, but I don't think that's required? >> >> Ie: You should move the read of misc_cap to the top-level of the >> function and perform the VMX_MISC_PT_SUPPORTED check there also. >> >> Note that space inside parentheses is only required for conditions of >> 'if', 'for' and those kind of statements, here it's not required, so >> this should be: >> >> hvm_funcs.pt_supported = cpu_has_ipt && >> (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); >> >> I also think this should look like: >> >> if ( !smp_processor_id() ) >> hvm_funcs.pt_supported = cpu_has_ipt && >> (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); >> else if ( hvm_funcs.pt_supported && >> !(_vmx_misc_cap & VMX_MISC_PT_SUPPORTED) ) >> { >> printk("VMX: IPT capabilities fatally differ between CPU%u and CPU0\n", >> smp_processor_id()); >> return -EINVAL; >> } >> >> >> So that you can detect mismatches between CPUs. > > > I'm afraid this snippet doesn't work. All CPUs read hvm_funcs.pt_supported as 0 even when it was set to 1 for CPU=0. I'm not sure if this is some multithreading issue or there is a separate hvm_funcs for each CPU? hvm_funcs will be set from start_vmx()'s return value, i.e. vmx_function_table. Therefore at least prior to start_vmx() completing you need to fiddle with vmx_function_table, not hvm_funcs. And in the code here, where for APs you only read the value, you could easily use the former uniformly, I think. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 08:39:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 08:39:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnHyl-0005eT-Ai; Mon, 22 Jun 2020 08:38:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnHyk-0005eK-Ul for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 08:38:58 +0000 X-Inumbo-ID: d013ca02-b463-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d013ca02-b463-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 08:38:57 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 4TpWVnbtiqhHqTm8UcF3OpAb2ZHi7hzxMchVDlx84oPPC2OsOAjK2SGuA51o1ODupl2ywABbKs sTGTZwEKCHOWRk3j67f09FvjcIBqouRt4xz0ohd5suQxkDHg1yk+MHmJxOxAluIGqpnqFIF2OH 04YAJ30lc/a5kSPPrGakF2TBnKOjBMH1fUOJ6TzqIMxiVO3Q14HqKHl9cdBd1jOqInig3Z6IN1 SRgzwpiMw315v8aBPVr76xaemjJo64jKEZKyF3QQUDhxS0lx2+OvdOzT0m389dE4n5hBxoFbH/ 0mM= X-SBRS: 2.7 X-MesageID: 20942116 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,266,1589256000"; d="scan'208";a="20942116" Date: Mon, 22 Jun 2020 10:38:46 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Anchal Agarwal Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Message-ID: <20200622083846.GF735@Air-de-Roger> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200617083528.GW735@Air-de-Roger> <20200619234312.GA24846@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200619234312.GA24846@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 11:43:12PM +0000, Anchal Agarwal wrote: > On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monné wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monné wrote: > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > > > + "the device may become inconsistent state"); > > > > > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > > > state and with the queues frozen. You should make an attempt to > > > > > restore things to a working state. > > > > > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > > > > > You can manually force this state, and then check that it will behave > > > > correctly. I would expect that on a failure to disconnect from the > > > > backend you should switch the frontend to the 'Init' state in order to > > > > try to reconnect to the backend when possible. > > > > > > > From what I understand forcing manually is, failing the freeze without > > > disconnect and try to revive the connection by unfreezing the > > > queues->reconnecting to backend [which never got diconnected]. May be even > > > tearing down things manually because I am not sure what state will frontend > > > see if backend fails to to disconnect at any point in time. I assumed connected. > > > Then again if its "CONNECTED" I may not need to tear down everything and start > > > from Initialising state because that may not work. > > > > > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > > > I don't see it getting handled in the backend then what will be backend's state? > > > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > > > if it tries to read backend's state through xenbus_read_driver_state ? > > > > > > So the flow be like: > > > Front end marks XenbusStateClosing > > > Backend marks its state as XenbusStateClosing > > > Frontend marks XenbusStateClosed > > > Backend disconnects calls xen_blkif_disconnect > > > Backend fails to disconnect, the above function returns EBUSY > > > What will be state of backend here? > > > > Backend should stay in state 'Closing' then, until it can finish > > tearing down. > > > It disconnects the ring after switching to connected state too. > > > Frontend did not tear down the rings if backend does not switches the > > > state to 'Closed' in case of failure. > > > > > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend > > > > Backend will stay in state 'Closing' I think. > > > > > won't be calling connect(). {From reading code in frontend_changed} > > > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > > > we did not tear down anything so calling talk_to_blkback may not be needed > > > > > > Does that sound correct? > > > > I think switching to the initial state in order to try to attempt a > > reconnection would be our best bet here. > > > It does not seems to work correctly, I get hung tasks all over and all the > requests to filesystem gets stuck. Backend does shows the state as connected > after xenbus_dev_suspend fails but I think there may be something missing. > I don't seem to get IO interrupts thereafter i.e hitting the function blkif_interrupts. > I think just marking it initialised may not be the only thing. > Here is a short description of what I am trying to do: > So, on timeout: > Switch XenBusState to "Initialized" > unquiesce/unfreeze the queues and return > mark info->connected = BLKIF_STATE_CONNECTED If xenbus state is Initialized isn't it wrong to set info->connected == CONNECTED? You should tear down all the internal state (like a proper close)? > return EBUSY > > I even allowed blkfront_connect to switch state to "CONNECTED" rather me doing > it explicitly as mentioned above without re-allocating/re-registering the device > just to make sure bklfront_info object has all the right values. > Do you see anythign missing here? I'm afraid you will have to do a little bit of debugging here to figure out what's going on. You can add printk's to several places to see which path is taken, and why blkfront ends in such state. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 08:39:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 08:39:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnHzA-0005gb-KT; Mon, 22 Jun 2020 08:39:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnHz9-0005gP-CD for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 08:39:23 +0000 X-Inumbo-ID: deb3d674-b463-11ea-bb8b-bc764e2007e4 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [40.107.20.55]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id deb3d674-b463-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 08:39:22 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IrJ9lFXKEGkDVfO/DlY7YW78zPyuf7fQBIlfWRmkpW/WUuz0Pa198M2ndi7xbiIAhmr0EXyN2szlTl+GKzodteinCSqeweVU5ZTF/LromOy3K3NQKUzoiF2quM3G50pmTd7ghnN4kc5Tjeu8vMSv/KYHHSKNdvUvB9mnoSjXPb6eJXTqt/qth++UUKnQ0Cah3WyuZ5wytRAWQapFEOu1AHd2/M1SQjLI8hDwUQXBrsUaklONNA9XEsqYyZRdGIBAJfwvEbwv0Gt4B0+hGH1M8tbQA1umnNF70o+LX++EUN/cWk6DrLJgiof0bkqkyy+hv+C++dKM1xfiTIDsDBxR1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AzLQgpaLcUta3sDI7R2cn8rDxD/Tgo+eeo3raKNb6gA=; b=bgBdYawOjgbyzQ5NiYi+e62Fcmf+VB+O6ZwXYUd0xmTfiQhnS/JAmNHSnQIxIB0izVORS7HTgqC/bdNGvwX0G4Yt2EynmBYMPanFcclnxlEerLXyEN4vOLPcrx2aVKw0ROn0m7BqqB0WRl/q8EfWwrlEHe6iCLpzZcxIEo22E5NNOyrwZuZI3DHmhw5ldY4qpWB9H6Jv+a1QOWPy9LCGhzIXDwXhuBZaVI7GF0SIwnlLbDALyD0UQdru/X4K6RGYvgIKjNT5oNaT6IQEylBreqCzui4pEi6Mf/tGJhQPI9ztxvg9IKMkFYiWmz+RxLoUWrSybln/BzGiLmY7+ipZsw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AzLQgpaLcUta3sDI7R2cn8rDxD/Tgo+eeo3raKNb6gA=; b=miWSyBvzRysT87Bz0+Fj7k8YHR6084Ze0g80hjlJ/7/2k8f9BakRafy4z+12NAyOGuTH0AJmmcZTDyOTXY1/ZdYD8k587wBsv7Ni0tI4cVmgwwpMmKhjogB57klNnU56rTaAU0yNG8FyWxJuDMCWEsX87tpMq1GBae9KZoBqq4RMRJVRqDGB2igZksjK3vtXTLcKr5kfugqPD9g6rP+oLW29Slq7yFibruTxgu1iL/SEAlJwiiRdM2vQKmiezR1T7EtVPMkbP9cfcOLDs6hF9JIv0PUxtjkrNdzu966z8brLQX24fA7Jng4q4ZDlfe66UpI3luD5bPCKBzIdGAntLQ== Authentication-Results: citrix.com; dkim=none (message not signed) header.d=none;citrix.com; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB4015.eurprd04.prod.outlook.com (2603:10a6:803:48::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Mon, 22 Jun 2020 08:39:20 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 08:39:20 +0000 Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <227951948.10901979.1592794601349.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: Date: Mon, 22 Jun 2020 10:39:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <227951948.10901979.1592794601349.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR03CA0097.eurprd03.prod.outlook.com (2603:10a6:208:69::38) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM0PR03CA0097.eurprd03.prod.outlook.com (2603:10a6:208:69::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Mon, 22 Jun 2020 08:39:19 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b3048bad-85cd-496b-0a60-08d81687c1b4 X-MS-TrafficTypeDiagnostic: VI1PR04MB4015: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kNhQGzRXQp1UJwhzIR+wE+KbYxWE0cnTa8TeGHoJH9N1FN9spEfmGikfx8/DREae2j89CS2UgI+F88aRYrk/xrzSkkCOPBhGfFD+7cUFqqh8y2QNM3MfhU2ae+GTzA3kMSOp/7bq4UTZ/WdTOY9FS0NMPyQvy45saJf4NnQCTmu5T8zN2CxMI3AoVPYqXTdpjNoID7c/EOPTyc9WC8I9TbEWmMyQG9zWD3BLMwvX/g20HkmDC6Wojt6LWmCwxmSYcUBAVs1GGFNafc82p5YQoSsd3Xh5oXJ0669Yu7oRDJhXwVmgPkOtBrG73kI+WrGSgYPMrwgpit03tuyap2ClamnHjS4gOmcHBSSGaB5Ubl0hkY3MOg92OFgwK1ahbv+j X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(136003)(39860400002)(376002)(396003)(366004)(31686004)(316002)(478600001)(2906002)(53546011)(16576012)(52116002)(6916009)(6486002)(7416002)(26005)(66574015)(83380400001)(956004)(2616005)(186003)(16526019)(31696002)(86362001)(8936002)(8676002)(5660300002)(54906003)(66946007)(4326008)(36756003)(66556008)(66476007)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: CukqWp9b/euGxQ/91FjiDWHxM71rqQvogfROyns3YEYNoHw0mENeqG2addOolATPhamBhocnu7EW9qDKArDNGOZAGiqH1k0HBpQBjoQFqcM97qeEWldaZa/UBK/zP0DsoyYvrWB5cWtjfRyfPZzIvjkc1B8wuY436Zs16YZypeNuiUiEnUtZvSp6x0p0SasBM/3UR3rTv/T4TqPW2SA4DVWlXyfER6Yge+hAwSrj+R5OQ7HCs+fswYaalZyRnSCzG357IEsZswXLwPEhux9YcYPoij1eGJfaqbl4bfjUliPl7E5XXWsuY0TKgd8XTcAM6eQaMJCMXXbZKHC4QvgveHkbE/UelWvW13qQx9QSf3sNjdtbfYM6qlNfWA2uQCox6r4l0fqo3SYy5C6JQMpVwkMB1847740xAr+UFc2xOqRfwy6HOLzcmL3e8YcktfXZKbUC8YhKKLTVSPGMl4iqgu6hTMTTdVWdsbOQ0fcdXcI= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3048bad-85cd-496b-0a60-08d81687c1b4 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 08:39:20.0472 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: f+SoFnaClzlHRZieZspBlBxlSbXtyEG4lOFV5My4m3qugoG1aVP7qU6F3QZRYYVmLnIid2cTMoLwOiOczJm2DQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4015 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 04:56, Michał Leszczyński wrote: > ----- 19 cze 2020 o 1:41, Michał Leszczyński michal.leszczynski@cert.pl napisał(a): >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -508,11 +508,25 @@ static void vmx_restore_host_msrs(void) >> >> static void vmx_save_guest_msrs(struct vcpu *v) >> { >> + uint64_t rtit_ctl; >> + >> /* >> * We cannot cache SHADOW_GS_BASE while the VCPU runs, as it can >> * be updated at any time via SWAPGS, which we cannot trap. >> */ >> v->arch.hvm.vmx.shadow_gs = rdgsshadow(); >> + >> + if ( unlikely(v->arch.hvm.vmx.ipt_state && >> v->arch.hvm.vmx.ipt_state->active) ) >> + { >> + smp_rmb(); >> + rdmsrl(MSR_RTIT_CTL, rtit_ctl); >> + >> + if ( rtit_ctl & RTIT_CTL_TRACEEN ) >> + BUG(); >> + >> + rdmsrl(MSR_RTIT_STATUS, v->arch.hvm.vmx.ipt_state->status); >> + rdmsrl(MSR_RTIT_OUTPUT_MASK, >> v->arch.hvm.vmx.ipt_state->output_mask.raw); >> + } >> } > > > It was suggested to move this piece of code from vm-entry/vm-exit handling to > vmx_save_guest_msrs/vmx_restore_guest_msrs functions. > > Please note that we do need to periodically read MSR_RTIT_OUTPUT_MASK in order > to know how much data was written into the buffer by the processor. During tests, > I've spotted that in some cases vCPUs get out of scope very rarely. > > For instance: when IPT gets enabled, xc_vmtrace_ipt_get_offset() is returning zero > value for the first few seconds, because it's relying on the value of > v->arch.hvm.vmx.ipt_state->output_mask which we only read in vmx_save_guest_msrs() > and in some cases this occurs very rarely. > > Could you guys suggest some solution to the problem? If we would leave this value > dirty in hardware, AFAIK we have no possibility to directly access it, > but observing this particular value is very important in the runtime. Much depends on what state the vCPU in question is in when you need to "periodically read" the value. If it's paused, you may need to invoke sync_vcpu_execstate(). If it's actively running you can't get at the value anyway except when you're on the CPU that this vCPU is running on (and then you can RDMSR it quite easily). Any intermediate state between paused and running is prone to change immediately after you've established it anyway, so you need to get the vCPU into one of the two "stable" states in order to get at the register. Also (and I think I said so before) - please trim your replies. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 08:49:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 08:49:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnI8d-0006hM-OK; Mon, 22 Jun 2020 08:49:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnI8b-0006hH-Vk for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 08:49:10 +0000 X-Inumbo-ID: 3c4c1322-b465-11ea-8496-bc764e2007e4 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe0c::607]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3c4c1322-b465-11ea-8496-bc764e2007e4; Mon, 22 Jun 2020 08:49:09 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BtrdZACy1TtRB/PDBLiEMnxyYN1zrYzs+KVydMoFOXZ738pRif1Okef6FExYrrwgug30tNW1bgOq52xB4Zre82icWIK2pkli1P7jfKQ5JHW4adZoZc/gKyhzn7zbeP9Vm9wR/B8fdk6GEEDn0oQB1OdgtjpfHvd8++2KndjPvFM2tHLaeQhjbnIuWZhfECcl5i2ClUmR7Lbd8kyoP4S1D0q+1ITK5mcH2r3LVHQO316/oQnjOlFBNxV+rU+KxhRZ4mXTvDxZuhxVYqgMUlbFoqFHXMUxf7flvj98jyDTjfpOwEyeOo1PPtbSIpEwMtYY8Tt06zqCnzrMtOqU5MM6NA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cZH7/xZQX+TdFs0CqjEu3za0269PNeZnFsQkTcfLmfw=; b=HE8XhBBv02af3Pp5ZtQtqgUEDO50/Yga1qOzpSyu+D7iQsy8iOmhtMHm8UCru3WsSShduJ0Ra3Z1eXDOQSMy5ABvtSxxSBWmrPuBG1W1MB6TxU4PYONk7+t8ehTu3+TJYzmBCO0dMfrKF2tmnLL2BaUxXKjYPjD+mo/aqWJbF7Mgq+0RxNbctIAZe9VawVp+bRcclgF0JP/RDZoZ9kXwqLk2gFd8rrN4WiW7+Y6+D92i6cSO/Xet5nIs+8omkvWt5T3NHovC9JQ47PCOxx7sbbFqn2gigpcB71RpoptesxIVmksz37f9Q6smxzOjv4ihVRfNci7hDJLxEOsFRnpMLw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cZH7/xZQX+TdFs0CqjEu3za0269PNeZnFsQkTcfLmfw=; b=etX/yD4O2MwGNPtx37NA1igRWzQNKQFEbkEpmS+GNQcRQmV0JbTNxn4s9U8xoi742qqfaasicvN5GFHQ12UPBcaibGPceMVZpOilw5pyMTdduvaau8YRev7KmDl6vDMU4UxwtjHFT6wiHXiP+T+6C7zG8KFLFggElNmisScq1PwEkTxDgAcDzNRHXs0qNu5E3aF1PozObwE/sEWJbV356/Xxs0vY1hq/mq0npNUqYBQ1Ii7yguSaT0N9+Rm3mDZV4xirjp8SzFjmB9cXrlW+SGhse/tDDJ1i7UhGa2O3GS1Skt8QhwWyJR/szQDqqKDxhcD+8ECfmiIlmENXacoAtA== Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB5230.eurprd04.prod.outlook.com (2603:10a6:803:5f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 22 Jun 2020 08:49:07 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 08:49:07 +0000 Subject: Re: [PATCH v3 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: Grzegorz Uriasz References: From: Jan Beulich Message-ID: <5993e716-d71d-cbc0-a186-5325e2bdeba4@suse.com> Date: Mon, 22 Jun 2020 10:49:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM0PR10CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::12) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM0PR10CA0002.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Mon, 22 Jun 2020 08:49:06 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 356962eb-1335-4a8b-bdf6-08d816891f80 X-MS-TrafficTypeDiagnostic: VI1PR04MB5230: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4303; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nN3ylsmMiqy3rDdrKWqr7bg2j8Z5f3O/3NKcb6l4dwXs1zUewgAT36wa5DybNmaoy1mT34d41inVej9MArV+R+ElREyyc7FLEw4qa5aR3Uov9DKBz7iuTgf+pbicsdFBfWygtiYIJ9wQ4OgdWjBsq9NWQIZwmORMdVzrhZk217T7LrMhSnBFMR6HOsiXHq/UFL4Zt2F0bJpTpKP7KDL+JUJVGNck8wIknhPnsdltW3WZlRrKSjwtH+s6vGiO+0VHG+YOf5HHYenl3dT81yrc/RBpPhxBdL01VQsIWp2HXMk3fqCfCReHKwLc8w/TZqnxpyz/FYel/feSjx80Hi1uI7FJfJhhO3jFDEsZFPplzUWWauAOe19FK7lyor2U9Mf2 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(346002)(376002)(136003)(396003)(39860400002)(4326008)(31686004)(8676002)(53546011)(186003)(52116002)(54906003)(83380400001)(26005)(36756003)(8936002)(16526019)(2906002)(5660300002)(956004)(2616005)(478600001)(7416002)(86362001)(6486002)(31696002)(316002)(16576012)(66946007)(66476007)(66556008)(6916009)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: d/0RR1SESjllfuSFNG6YAC3GxzA7thf/qUJeD7EFL2Y4EIw3Ayrn7hMFkLiPVWbTMww3Mh7eYp9sg8PUzgOeZecrsJhXihVHO3trReTt4mnqYe+5mrRcREW0F+9UlI9n6VTQXE6yMpfs/F8W+l/hy3tWiTjx5Ccbre0q2WCEG+VdG8Wrn3mOYq834MPMY/yxiT/OPcMMo0qhLdbLN+m88N6sY1tLiw+83Ztv81SIdGxunhscdd0U6oBO4WbP1v/VQGYsLUJYBfqA15ym/6qSpG/GZqjsMqKYO++OBErm3JnJWXMVb7Y+IChNi0SXNgGw0XUWxif0Y1MzIQn/L3UZfCmyGfepfbAwdbUOOV3qLeiOH57mWpeIY78Cp/RKjMupVN7oRUyMJ880485d8wGGFxN6iQZY8pHtO+oFtQHr5ei7Vf8RBU7yi7y53C4a1QziiWv4uNYSLLGyiqW6V/bwO7IwzhkipZYDHq05inqBe1M= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 356962eb-1335-4a8b-bdf6-08d816891f80 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 08:49:06.8976 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7b1W+PRq2VB9D9Od7uToT8QJ2hnX2FRZdbcVx0/JQxuDurLpPSjUPe8Tc6TqpbgXCwXuYg//qtMe66qgJiBllg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5230 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 20.06.2020 00:00, Grzegorz Uriasz wrote: > @@ -490,8 +497,12 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > */ > if (!pmtmr_ioport) { > pmtmr_ioport = fadt->pm_timer_block; > - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0; > + pmtmr_width = fadt->pm_timer_length == 4 ? 32 : 0; > } > + if (pmtmr_width < 32 && fadt->flags & ACPI_FADT_32BIT_TIMER) > + printk(KERN_WARNING PREFIX "PM-Timer is too short\n"); Indentation is screwed up here. > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -457,16 +457,13 @@ static u64 read_pmtimer_count(void) > static s64 __init init_pmtimer(struct platform_timesource *pts) > { > u64 start; > - u32 count, target, mask = 0xffffff; > + u32 count, target, mask; > > - if ( !pmtmr_ioport || !pmtmr_width ) > + if ( !pmtmr_ioport || (pmtmr_width != 24 && pmtmr_width != 32) ) > return 0; > > - if ( pmtmr_width == 32 ) > - { > - pts->counter_bits = 32; > - mask = 0xffffffff; > - } > + pts->counter_bits = pmtmr_width; > + mask = (1ull << pmtmr_width) - 1; "mask" being of "u32" type, the use of 1ull is certainly a little odd here, and one of the reasons why I think this extra "cleanup" would better go in a separate patch. Seeing that besides cosmetic aspects the patch looks okay now, I'd be willing to leave the bigger adjustment mostly as is, albeit I'd prefer the 1ull to go away, by instead switching to e.g. mask = 0xffffffff >> (32 - pmtmr_width); With the adjustments (which I'd be happy to make while committing, provided you agree) Reviewed-by: Jan Beulich Also Cc-ing Paul for a possible release ack (considering this is a backporting candidate). Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 08:54:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 08:54:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnIDS-0007Uz-BT; Mon, 22 Jun 2020 08:54:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnIDQ-0007Uu-Ll for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 08:54:08 +0000 X-Inumbo-ID: ee44fc74-b465-11ea-bb8b-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ee44fc74-b465-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 08:54:07 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: HWnmjrmVZgCMpEtOY4vA0aZV95vVKdFN4K+3jruL1UoEekN79rS7pekQR17zyZVi/h59yCAwCE PWrNKb9IdYkwdYwG6WY79NgfmUiC9sfsbtv0iNEB9is4WikHeUxYC44l2FT1jDsO+cAOiLbzKj CYwk2ZMYTp9ISA+Xpw3P6xZ9dkDu0pz3+Q9o1IvJMlS8NNHGo+ne+NeW4lW6ZqxdC5QkJQaaBZ oiR5pI6poymasx2vHRtTw3dBLfSs///Jf5l7ZZUel2MRMwpRvPqIVUWHw5tWOHHR+JimtEkg7O 5Rk= X-SBRS: 2.7 X-MesageID: 20605835 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,266,1589256000"; d="scan'208";a="20605835" Date: Mon, 22 Jun 2020 10:54:00 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Grzegorz Uriasz Subject: Re: [PATCH v3 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Message-ID: <20200622085400.GG735@Air-de-Roger> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Jan Beulich , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 10:00:16PM +0000, Grzegorz Uriasz wrote: > On some computers the bit width of the PM Timer as reported > by ACPI is 32 bits when in fact the FADT flags report correctly > that the timer is 24 bits wide. On affected machines such as the > ASUS FX504GM and never gaming laptops this results in the inability > to resume the machine from suspend. Without this patch suspend is > broken on affected machines and even if a machine manages to resume > correctly then the kernel time and xen timers are trashed. > > Signed-off-by: Grzegorz Uriasz > --- > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Wei Liu > Cc: "Roger Pau Monné" > Cc: marmarek@invisiblethingslab.com > Cc: contact@puzio.waw.pl > Cc: jakub@bartmin.ski > Cc: j.nowak26@student.uw.edu.pl > > Changes in v2: > - Check pm timer access width > - Proper timer width is set when xpm block is not present > - Cleanup timer initialization > > Changes in v3: > - Check pm timer bit offset > - Warn about acpi firmware bugs > - Drop int cast in init_pmtimer > - Merge if's in init_pmtimer > --- > xen/arch/x86/acpi/boot.c | 19 +++++++++++++++---- > xen/arch/x86/time.c | 12 ++++-------- > xen/include/acpi/acmacros.h | 8 ++++++++ > 3 files changed, 27 insertions(+), 12 deletions(-) > > diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c > index bcba52e232..24fd236eb5 100644 > --- a/xen/arch/x86/acpi/boot.c > +++ b/xen/arch/x86/acpi/boot.c > @@ -475,10 +475,17 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > > #ifdef CONFIG_X86_PM_TIMER > /* detect the location of the ACPI PM Timer */ > - if (fadt->header.revision >= FADT2_REVISION_ID) { > + if (fadt->header.revision >= FADT2_REVISION_ID && > + fadt->xpm_timer_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO) { > /* FADT rev. 2 */ > - if (fadt->xpm_timer_block.space_id == > - ACPI_ADR_SPACE_SYSTEM_IO) { > + if (fadt->xpm_timer_block.access_width != 0 && > + ACPI_ACCESS_BIT_WIDTH(fadt->xpm_timer_block.access_width) != 32) > + printk(KERN_WARNING PREFIX "PM-Timer has invalid access width(%u)\n", > + fadt->xpm_timer_block.access_width); > + else if (fadt->xpm_timer_block.bit_offset != 0) This should be a plain if instead of an else if, it's possible the block has both the access_width and the bit_offset wrong. > + printk(KERN_WARNING PREFIX "PM-Timer has invalid bit offset(%u)\n", > + fadt->xpm_timer_block.bit_offset); > + else { > pmtmr_ioport = fadt->xpm_timer_block.address; > pmtmr_width = fadt->xpm_timer_block.bit_width; > } > @@ -490,8 +497,12 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > */ > if (!pmtmr_ioport) { > pmtmr_ioport = fadt->pm_timer_block; > - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0; > + pmtmr_width = fadt->pm_timer_length == 4 ? 32 : 0; > } > + if (pmtmr_width < 32 && fadt->flags & ACPI_FADT_32BIT_TIMER) > + printk(KERN_WARNING PREFIX "PM-Timer is too short\n"); Indentation. Also this should be a fatal error likely? You should set pmtmr_ioport = 0? > + if (pmtmr_width > 24 && !(fadt->flags & ACPI_FADT_32BIT_TIMER)) > + pmtmr_width = 24; > if (pmtmr_ioport) > printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x (%u bits)\n", > pmtmr_ioport, pmtmr_width); > diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c > index d643590c0a..8a45514908 100644 > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -457,16 +457,13 @@ static u64 read_pmtimer_count(void) > static s64 __init init_pmtimer(struct platform_timesource *pts) > { > u64 start; > - u32 count, target, mask = 0xffffff; > + u32 count, target, mask; > > - if ( !pmtmr_ioport || !pmtmr_width ) > + if ( !pmtmr_ioport || (pmtmr_width != 24 && pmtmr_width != 32) ) > return 0; > > - if ( pmtmr_width == 32 ) > - { > - pts->counter_bits = 32; > - mask = 0xffffffff; > - } > + pts->counter_bits = pmtmr_width; > + mask = (1ull << pmtmr_width) - 1; > > count = inl(pmtmr_ioport) & mask; > start = rdtsc_ordered(); > @@ -486,7 +483,6 @@ static struct platform_timesource __initdata plt_pmtimer = > .name = "ACPI PM Timer", > .frequency = ACPI_PM_FREQUENCY, > .read_counter = read_pmtimer_count, > - .counter_bits = 24, > .init = init_pmtimer > }; > > diff --git a/xen/include/acpi/acmacros.h b/xen/include/acpi/acmacros.h > index 6765535053..86c503c20f 100644 > --- a/xen/include/acpi/acmacros.h > +++ b/xen/include/acpi/acmacros.h > @@ -121,6 +121,14 @@ > #define ACPI_COMPARE_NAME(a,b) (!ACPI_STRNCMP (ACPI_CAST_PTR (char,(a)), ACPI_CAST_PTR (char,(b)), ACPI_NAME_SIZE)) > #endif > > +/* > + * Algorithm to obtain access bit or byte width. > + * Can be used with access_width of struct acpi_generic_address and access_size of > + * struct acpi_resource_generic_register. > + */ > +#define ACPI_ACCESS_BIT_WIDTH(size) (1 << ((size) + 2)) > +#define ACPI_ACCESS_BYTE_WIDTH(size) (1 << ((size) - 1)) Note sure I would introduce this last one, since it's not used by the code. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 08:58:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 08:58:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnIHd-0007iY-TJ; Mon, 22 Jun 2020 08:58:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnIHd-0007iT-EN for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 08:58:29 +0000 X-Inumbo-ID: 89e6a75e-b466-11ea-be4c-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 89e6a75e-b466-11ea-be4c-12813bfff9fa; Mon, 22 Jun 2020 08:58:28 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 8geRtY5uERBwhau9Jk2Wbodh6QmEHkneOYPOUy9Adx5myeR4R6tyRvz93guA69ufqyIWpiRUOI N9CyGxmjSkfmju4J85oHgPl9sIObgB5huRlMtNHESoUAsNm9wgU7UF2MukZFldzEnY6o/d6t2o WMgmA5knywRpJ12slehtSyC+ut8WXOf4rap1a8mEDs7rv97msMdqEc5/okrG6jQfueQ3FAJhbZ adwGRX8FN36tkZnZpqDe7L51MRFoBNgIBfmT6KG9bLPyKKj89AAC0Ymh1Tcw4qaYVfWPcQCDJG xVM= X-SBRS: 2.7 X-MesageID: 20943361 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,266,1589256000"; d="scan'208";a="20943361" Date: Mon, 22 Jun 2020 10:58:19 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Grzegorz Uriasz Subject: Re: [PATCH v3 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Message-ID: <20200622085819.GH735@Air-de-Roger> References: <20200622085400.GG735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200622085400.GG735@Air-de-Roger> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Jan Beulich , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 10:54:00AM +0200, Roger Pau Monné wrote: > On Fri, Jun 19, 2020 at 10:00:16PM +0000, Grzegorz Uriasz wrote: > > On some computers the bit width of the PM Timer as reported > > by ACPI is 32 bits when in fact the FADT flags report correctly > > that the timer is 24 bits wide. On affected machines such as the > > ASUS FX504GM and never gaming laptops this results in the inability > > to resume the machine from suspend. Without this patch suspend is > > broken on affected machines and even if a machine manages to resume > > correctly then the kernel time and xen timers are trashed. > > > > Signed-off-by: Grzegorz Uriasz > > --- > > Cc: Jan Beulich > > Cc: Andrew Cooper > > Cc: Wei Liu > > Cc: "Roger Pau Monné" > > Cc: marmarek@invisiblethingslab.com > > Cc: contact@puzio.waw.pl > > Cc: jakub@bartmin.ski > > Cc: j.nowak26@student.uw.edu.pl > > > > Changes in v2: > > - Check pm timer access width > > - Proper timer width is set when xpm block is not present > > - Cleanup timer initialization > > > > Changes in v3: > > - Check pm timer bit offset > > - Warn about acpi firmware bugs > > - Drop int cast in init_pmtimer > > - Merge if's in init_pmtimer > > --- > > xen/arch/x86/acpi/boot.c | 19 +++++++++++++++---- > > xen/arch/x86/time.c | 12 ++++-------- > > xen/include/acpi/acmacros.h | 8 ++++++++ > > 3 files changed, 27 insertions(+), 12 deletions(-) > > > > diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c > > index bcba52e232..24fd236eb5 100644 > > --- a/xen/arch/x86/acpi/boot.c > > +++ b/xen/arch/x86/acpi/boot.c > > @@ -475,10 +475,17 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) > > > > #ifdef CONFIG_X86_PM_TIMER > > /* detect the location of the ACPI PM Timer */ > > - if (fadt->header.revision >= FADT2_REVISION_ID) { > > + if (fadt->header.revision >= FADT2_REVISION_ID && > > + fadt->xpm_timer_block.space_id == ACPI_ADR_SPACE_SYSTEM_IO) { > > /* FADT rev. 2 */ > > - if (fadt->xpm_timer_block.space_id == > > - ACPI_ADR_SPACE_SYSTEM_IO) { > > + if (fadt->xpm_timer_block.access_width != 0 && > > + ACPI_ACCESS_BIT_WIDTH(fadt->xpm_timer_block.access_width) != 32) > > + printk(KERN_WARNING PREFIX "PM-Timer has invalid access width(%u)\n", > > + fadt->xpm_timer_block.access_width); > > + else if (fadt->xpm_timer_block.bit_offset != 0) > > This should be a plain if instead of an else if, it's possible the > block has both the access_width and the bit_offset wrong. My bad, realized this avoids setting pmtmr_ioport. Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 09:18:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 09:18:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnIao-00017E-MD; Mon, 22 Jun 2020 09:18:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnIam-000178-Im for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 09:18:17 +0000 X-Inumbo-ID: 4a02df6a-b469-11ea-be54-12813bfff9fa Received: from mo4-p00-ob.smtp.rzone.de (unknown [85.215.255.21]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4a02df6a-b469-11ea-be54-12813bfff9fa; Mon, 22 Jun 2020 09:18:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592817489; s=strato-dkim-0002; d=aepfle.de; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=/Wnz5DZ94JL+6N1kDWP4UJgwIXviIIbPBAQ8FVpCj3o=; b=cTEmeBuhZJgEXJq+zJGi7ALIxH7qwMsjMlBcn6suqoj9izrGP8zFBPI/117iF+iYyM PseX73sSy7a8YBW0dcxDmO/5VM58ybw3V0cbSQRsR1rgQ1x6QNtXRzemVrYj+fu3AB3i kUdD4b1anoDg7MznTlTixutSt6LCHNw54vHeMarN7UqAXnRJlt49gPXkoJKddSOTHkwX wSGWey61V0n27e9hAay+TNr+purPCsqHLizJ8KidoFMmmdyvSwZ5R5WQnka8vcGfvcij GBQVAJFIGWA86lKhYEZlF7cLys1KfT2LIRugGrIny7QvNJNFYYDvjYHVaT2EGNGYemim NQXg== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QXkBR9MXjAuzBW/OdlBZQ4AHSS3G1Pjw==" X-RZG-CLASS-ID: mo00 Received: from aepfle.de by smtp.strato.de (RZmta 46.10.4 DYNA|AUTH) with ESMTPSA id 0013a0w5M9I3X3H (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 22 Jun 2020 11:18:03 +0200 (CEST) Date: Mon, 22 Jun 2020 11:17:51 +0200 From: Olaf Hering To: Ian Jackson Subject: Re: [XEN PATCH for-4.14 1/2] tools: Commit autoconf (2.69) output from Debian buster Message-ID: <20200622091738.GA27631@aepfle.de> References: <000401d640c9$7b14e760$713eb620$@xen.org> <20200612151931.1083-2-ian.jackson@eu.citrix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: <20200612151931.1083-2-ian.jackson@eu.citrix.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Paul Durrant , Nick Rosbrook , Wei Liu , Samuel Thibault Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Fri, Jun 12, Ian Jackson wrote: > These files are in tree so that people can build (including from git) > without needing recent autotools. Do you know those people who can not possibly install the required (now 8year old) autoconf version? Olaf --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE97o7Um30LT3B+5b/86SN7mm1DoAFAl7wdz8ACgkQ86SN7mm1 DoCiQA/9HF3/RR3TaGbtcaKHzFWAAsq/3xuJ5I5/+bDe0rjzYRklRhY9wgjcEf06 T8FZqySA7X0dXpD31Vm8w+S2gcEtpNY7dV3ZAz3gq75ur87NshzpaVOwfreq+/OY vGlIL/sxRFI+tUaqhtLDFJ3v0kiHhnsOrdoiI/EKvFQRTXyxIz+q0pxJ96Xw2Ba1 zGDATjFV765J6HapzZ2sYTvTg9Az1xlBSQuqGZ4XYaJw7nuVTB9RfGeziJjuRh0A tICK5V12htE3jdq8u6ks+wnVa0CWzOWICIbt9JZkwQm6klwpZ9Uby4Z4yGtt4hLp uXf8r094qmhZSaxz/O6JA+FAG5KjVlYv9OTaKB5Q509+0M5DZzrjVOMlqxn5UjO1 ySAsMA780X8YiB7f7EHbWVPPawAUBofDCe7t3Z+bBbvQeUDGbNGLTaDhwyOn5pEV 4nQhbQKT9D3oOzelmAA8T8Whspj40AchWJX2RwNRFwQGTlrI74G+WJQw1gknycYb EpCCzgyvlskJU1rUP/I6RgDDgBU1JhVnAnNuN84uNzxOQF/O9YNEe3UoWd1qo7uN tYGhBHRSj3j60UP8tynEL6gk0SYCOxB/HN/xlqJmBFyDN/BRronAn8o2rJZ+/ReG 9+9XdBvCsgjoBcz/EM6r15xaHTmK7v5WuokvZu7gNKDHZ/GL688= =bzS3 -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From xen-devel-bounces@lists.xenproject.org Mon Jun 22 09:31:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 09:31:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnIng-0002ij-TC; Mon, 22 Jun 2020 09:31:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnInf-0002ie-A7 for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 09:31:35 +0000 X-Inumbo-ID: 295b7946-b46b-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 295b7946-b46b-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 09:31:34 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 0X73z1w2Bk0Skytn43gA6dE5BYrGftvErUanFqlLzE7YG/FZFVp0XNcBlxOSr/pr/6L1ylYy9O CBO0Idq3+FECjmKpMelTaJA9SBLgqMJ0o2eiHetZ4n0cTsxiEAVn4nSKs/TW5X4jh3A0jdNw8H HUz9J5vTi/PjK/05Y66OQIZFT5Zy+fHG4v0J/R6BtoP8EwhBsNszzxnORIdhynC1qJLRn/DktF c3l8HpZ7XWBGyQdMwRlHMmLgMWt1Os/qM4rxI+gIv5d6/fMOG1qlDh0zSMwauU9j7KXVHUxpNO 4sw= X-SBRS: 2.7 X-MesageID: 20596152 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,266,1589256000"; d="scan'208";a="20596152" Date: Mon, 22 Jun 2020 11:31:23 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage Message-ID: <20200622093123.GI735@Air-de-Roger> References: <20200618160403.35199-1-roger.pau@citrix.com> <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote: > On 18.06.2020 18:04, Roger Pau Monne wrote: > > Commit e9aca9470ed86 introduced a regression when avoiding sending > > IPIs for certain flush operations. Xen page fault handler > > (spurious_page_fault) relies on blocking interrupts in order to > > prevent handling TLB flush IPIs and thus preventing other CPUs from > > removing page tables pages. Switching to assisted flushing avoided such > > IPIs, and thus can result in pages belonging to the page tables being > > removed (and possibly re-used) while __page_fault_type is being > > executed. > > > > Force some of the TLB flushes to use IPIs, thus avoiding the assisted > > TLB flush. Those selected flushes are the page type change (when > > switching from a page table type to a different one, ie: a page that > > has been removed as a page table) and page allocation. This sadly has > > a negative performance impact on the pvshim, as less assisted flushes > > can be used. > > > > Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush > > using an IPI (flush_tlb_mask_sync). Note that the flag is only > > meaningfully defined when the hypervisor supports PV mode, as > > otherwise translated domains are in charge of their page tables and > > won't share page tables with Xen, thus not influencing the result of > > page walks performed by the spurious fault handler. > > Is this true for shadow mode? If a page shadowing a guest one was > given back quickly enough to the allocator and then re-used, I think > the same situation could in principle arise. Hm, I think it's not applicable to HVM shadow mode at least, because CR3 is switched as part of vmentry/vmexit, and the page tables are not shared between Xen and the guest, so there's no way for a HVM shadow guest to modify the page-tables while Xen is walking them in spurious_page_fault (note spurious_page_fault is only called when the fault happens in non-guest context). > > Note the flag is not defined on Arm, and the introduced helper is just > > a dummy alias to the existing flush_tlb_mask. > > > > Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') > > Reported-by: Andrew Cooper > > Signed-off-by: Roger Pau Monné > > --- > > It's my understanding that not doing such IPI flushes could lead to > > the pages tables being read by __page_fault_type being modified by a > > third party, which could make them point to other mfns out of the > > scope of the guest allowed physical memory addresses. However those > > accesses would be limited to __page_fault_type, and hence the main > > worry would be that a guest could make it point to read from a > > physical memory region that has side effects? > > I don't think so, no - the memory could be changed such that the > PTEs are invalid altogether (like having reserved bits set). Consider > for example the case of reading an MFN out of such a PTE that's larger > than the physical address width supported by the CPU. Afaict > map_domain_page() will happily install a respective page table entry, > but we'd get a reserved-bit #PF upon reading from that mapping. So there are no hazards from executing __page_fault_type against a page-table that could be modified by a user? > > --- > > xen/arch/x86/mm.c | 12 +++++++++++- > > xen/common/memory.c | 2 +- > > xen/common/page_alloc.c | 2 +- > > xen/include/asm-arm/flushtlb.h | 1 + > > xen/include/asm-x86/flushtlb.h | 14 ++++++++++++++ > > xen/include/xen/mm.h | 8 ++++++-- > > 6 files changed, 34 insertions(+), 5 deletions(-) > > Not finding a consumer of the new flag, my first reaction was to > ask whether there's code missing somewhere. Having looked at > flush_area_mask() another time I now understand the itended > behavior results because of the extra flag now allowing > hypervisor_flush_tlb() to be entered. I think that's something > that's worth calling out in the description, or perhaps even in > the comment next to the #define. Oh right, the condition to use assisted flush is not actually changed in flush_area_mask since setting any bit in the flags would prevent using it. > > --- a/xen/arch/x86/mm.c > > +++ b/xen/arch/x86/mm.c > > @@ -2894,7 +2894,17 @@ static int _get_page_type(struct page_info *page, unsigned long type, > > ((nx & PGT_type_mask) == PGT_writable_page)) ) > > { > > perfc_incr(need_flush_tlb_flush); > > - flush_tlb_mask(mask); > > + if ( (x & PGT_type_mask) && > > + (x & PGT_type_mask) <= PGT_l4_page_table ) > > With there being 5-level page tables around the corner, I think > we ought to get used to use PGT_root_page_table (or alike) > whenever possible, to avoid having to touch such code when > adding support for the new paging mode. > > > --- a/xen/include/asm-x86/flushtlb.h > > +++ b/xen/include/asm-x86/flushtlb.h > > @@ -126,6 +126,12 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4); > > #else > > #define FLUSH_HVM_ASID_CORE 0 > > #endif > > +#if CONFIG_PV > > #ifdef > > > +/* Force an IPI to be sent */ > > +# define FLUSH_FORCE_IPI 0x8000 > > +#else > > +# define FLUSH_FORCE_IPI 0 > > +#endif > > If my shadow mode concern above is unwarranted, this overhead could > also be avoided if there's no PV domain at all in the system. > Perhaps an improvement not for now, but for the future ... Hm, right, I guess it would be possible to turn FLUSH_FORCE_IPI into a dynamic flag. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 09:53:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 09:53:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnJ8q-0004ZJ-UK; Mon, 22 Jun 2020 09:53:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnJ8p-0004Yv-7s for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 09:53:27 +0000 X-Inumbo-ID: 343f763e-b46e-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 343f763e-b46e-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 09:53:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=j94yKlWJgbRYkdTQo6xmdpRAujINf5uviuWVl0QgBRI=; b=aXjkI5pXcx2zSXlQb6d7TVWlv WFgd3uGZ7EeOytb8S9sddFBG+x3b/GbUduHrOZIfVC64zXV0rF7YDaZiOU3pq8Uhmm3UULwJg3r6K zqu42ivmhq4QfO6nmp2JTfND344ffMO9FtTaymLhWQRfbGuigLAvstbbLpYIiOYidiNrg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnJ8h-0003Io-OB; Mon, 22 Jun 2020 09:53:19 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnJ8h-0007xy-FK; Mon, 22 Jun 2020 09:53:19 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnJ8h-0002Ec-ED; Mon, 22 Jun 2020 09:53:19 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151273: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:heisenbug xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:guest-start/debianhvm.repeat:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=fde76f895d0aa817a1207d844d793239c6639bc6 X-Osstest-Versions-That: xen=3625b04991b4d6affadd99d377ab84bac48dfff4 From: osstest service owner Date: Mon, 22 Jun 2020 09:53:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151273 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151273/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 151245 pass in 151273 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail in 151245 pass in 151273 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 guest-start/debianhvm.repeat fail pass in 151245 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151181 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151181 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151181 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151181 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151181 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151181 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151181 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen fde76f895d0aa817a1207d844d793239c6639bc6 baseline version: xen 3625b04991b4d6affadd99d377ab84bac48dfff4 Last test of basis 151181 2020-06-17 06:01:52 Z 5 days Failing since 151224 2020-06-18 16:01:07 Z 3 days 3 attempts Testing same since 151245 2020-06-20 06:44:46 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Ian Jackson Igor Druzhinin Jason Andryuk Olaf Hering Roger Pau Monné Samuel Thibault Tamas K Lengyel jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 3625b04991..fde76f895d fde76f895d0aa817a1207d844d793239c6639bc6 -> master From xen-devel-bounces@lists.xenproject.org Mon Jun 22 10:13:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 10:13:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnJRx-0006io-Ee; Mon, 22 Jun 2020 10:13:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnJRv-0006ij-OS for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 10:13:11 +0000 X-Inumbo-ID: f91ceef8-b470-11ea-be67-12813bfff9fa Received: from EUR02-AM5-obe.outbound.protection.outlook.com (unknown [40.107.0.65]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f91ceef8-b470-11ea-be67-12813bfff9fa; Mon, 22 Jun 2020 10:13:10 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WR5JBbEA45jQ11tvnYYANudscsx/5bEMetrsX+mQ5Y4PMcjnmG+0gv6LqW/g7F0DBzQfxmuFH2wkysQUEwNKhziKNG/SmGv+RRGSS4EERu1DUwUzahy3vgIYifejtwgcJT7spyqJ0JKhArFbxEhL3+Ve8EZ4R9172u3h86K8MKI5Z7FreTMhy3dzlMNFBoaOqPKoYWJ7Sxv1Gu6PmhMWWk6ezykfX02RaR7jx+kQcQfX6tFzeWfMuldNOUb1L/U0cHjptbC5wqL9nQUXCdZrrHlzd08SXgVPQbou6S1yvr6tO6L9TQR39AtlHEwyolwgop8dynvIJ215CrW5uGJ/Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s+UPrxyc4/+1Zs7EAwGKH1DqHIk5F3sdmAc6aSj1IYs=; b=JBpUE+U1oul/FEAc/Nhbe632S1neW4Qf2zQxoY3lSIXXkSHFUDnVrfTnx8IUMatA074tTVT8CajbpWOqKLysCe0VVC19AlLjkj9kWqTgqUvcGKYzT6HggKDajuHixIGnQlUE44FSt8O+u19hE5vbwOJa/afTXTmWEw0wEjCWBetvyYGrt08PTd60KNW2JfGja1a2l6Ayq/FH7GamgpHzTDjD2wPdstENIwEpHy11SNa0YkQpFNjWyrBWiq9/AXbKGr/gzBFM7kx7bmxjxNWBC7e7z4vX7Aw0TvQmKYxc0UmpS20rpHKFsfcwljbfbhI721AVciC9H/daNNif5FRTzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s+UPrxyc4/+1Zs7EAwGKH1DqHIk5F3sdmAc6aSj1IYs=; b=LkXNVOQTSg+cEG7get3g+Yi/Hk/9GlHfQ3Yc6QvEA9ho35uheWHl/xkxIw3zAxFVhB/Gk7hFDioWh82Hy7SsvGYmgW0DozVqsf+VAQysb4menH5Sg72eF5wWklU+LR+/AtVYJ8rPS00POSrYZ/w8qTdYPAD30q8ey/Upoo6/O4223ERR4dRPVQ9gNXWcOz2yDRgDOzxU8Xtw03gPdSduvT12ggPCJcBbxricA9wRw8/8PEcI98+fLx0YLiWgOG4y1PifnDN85+4KspkBgYNRZFpubjCzEwV2JLo26SEG3z2MRHzGvUHUTz5V80u0dyFPW7C4jmWxBzR30YFXg7wzCw== Authentication-Results: student.uw.edu.pl; dkim=none (message not signed) header.d=none; student.uw.edu.pl; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB6797.eurprd04.prod.outlook.com (2603:10a6:803:13e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 22 Jun 2020 10:13:08 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 10:13:08 +0000 Subject: Re: [PATCH v3 1/1] x86/acpi: Use FADT flags to determine the PMTMR width To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200622085400.GG735@Air-de-Roger> From: Jan Beulich Message-ID: <6c286697-99d6-93f3-1bbf-925ce54c08fb@suse.com> Date: Mon, 22 Jun 2020 12:13:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <20200622085400.GG735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM3PR05CA0126.eurprd05.prod.outlook.com (2603:10a6:207:2::28) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM3PR05CA0126.eurprd05.prod.outlook.com (2603:10a6:207:2::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Mon, 22 Jun 2020 10:13:07 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 445327d8-2f29-46fd-097a-08d81694dc61 X-MS-TrafficTypeDiagnostic: VI1PR04MB6797: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YiVEYNRLfWNUKZClve6XuQ2AHk8cg7vWyLJg6gLAho/oFNcGUSmwHoec8zgTMoR4BmH16iov8DU9s8XLuJ9qQCk8bYqGO2xMV+W4TM41sSKQ0ruVgP/hE2ZvqT+sNjAobBJN5CgFvvso73/89rcaEfubFGGr5GoMo5WdaGFJU8NGpCWlXnxoATemhjaUqhP08xu5vvRmWzjxFb7ZQkCY0gg2ZAWFnmxxqF5ud3djVPi78wHvhn9FggRcMzkuInj+VpNjiSfT1wmkkYzn7JJjyOoPfSoODpiu73Ir46KpTQTaS6JGn0cYij4rYaj2JUKbLFQ4jYpOs+H7dw7wJ+RVtryTLSYBoEMEN4tyjGnt98txbuAWhCpc8ot9oA9fACsn X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(366004)(346002)(376002)(39860400002)(396003)(6666004)(26005)(53546011)(6916009)(8676002)(5660300002)(31696002)(52116002)(316002)(66946007)(66476007)(66556008)(31686004)(4326008)(478600001)(16576012)(86362001)(36756003)(54906003)(6486002)(956004)(2616005)(16526019)(4744005)(8936002)(186003)(83380400001)(2906002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: w67RjlETI+ful9UTtxSAoF3mWAMR69zK66h+6IQcO53lK08peiQMbrDLaSMcE7ViXbEABc34wjPA9ziixwHiY6xRBWyDhfb5+Hl18d6pJoZm4CQuO+1K1zwWe8pbHoBJY6CbBaQMHNs8kbKNSGQn66myFpLE1VTuR3WeOIa75wRseAtt7UGsq4XoQR3BnmG/7lzvZzROmAFMhnFwwUQxtStnFAv2y+NpKBISpeT47hjX+x25S/39L+MnhIlEvxF2pjyI8yw01KMxkgZi1TDYaiWtgOZbtqhivFSdCSpARgUo/TVsDWEjOyOBQIXlLR7f0FVR7eouTTGeYWvUupFsRf5BTj7xCFDStEH5oOdq+bnjWQENZP2ufQKk7vLVDJQtMbnBOowSFSRk383VwHlzCfl3HcLUY53xm4iLru91AW3VC0lI1k1Q6rfwQEJMfMCnRAvChYgaNLDy3Yg5LAP8HQsTcbwPDTktKp+pvVGtzqU= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 445327d8-2f29-46fd-097a-08d81694dc61 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 10:13:08.3201 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dtg7fSFUhgkr63tzelsFs7rKmYmIvkk0mdaxYeswdiguUpIVCQ3qaYwENlLjs1QKz7GgMDvaF9wc5qSzkXtvZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB6797 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 10:54, Roger Pau Monné wrote: > On Fri, Jun 19, 2020 at 10:00:16PM +0000, Grzegorz Uriasz wrote: >> @@ -490,8 +497,12 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) >> */ >> if (!pmtmr_ioport) { >> pmtmr_ioport = fadt->pm_timer_block; >> - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0; >> + pmtmr_width = fadt->pm_timer_length == 4 ? 32 : 0; >> } >> + if (pmtmr_width < 32 && fadt->flags & ACPI_FADT_32BIT_TIMER) >> + printk(KERN_WARNING PREFIX "PM-Timer is too short\n"); > > Indentation. Also this should be a fatal error likely? You should set > pmtmr_ioport = 0? Not sure, to be honest. It's entirely fuzzy what mode to use in this case, yet assuming a working 24-bit timer looks valid in this case. And indeed we'd use the timer (with a 24-bit mask) exactly when pmtmr_width == 24 (alongside the bogus set ACPI_FADT_32BIT_TIMER bit). What I do notice only now though is that inside the if() there's a pair of parentheses missing. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 10:59:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 10:59:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnKA2-0001wS-Vy; Mon, 22 Jun 2020 10:58:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnKA1-0001wB-MU for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 10:58:45 +0000 X-Inumbo-ID: 53956c2e-b477-11ea-bb8b-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 53956c2e-b477-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 10:58:39 +0000 (UTC) Received: from webmail.moloch.sk (w3-s.a.lucina.net [62.176.169.73]) by smtp.lucina.net (Postfix) with ESMTPSA id 06159122804; Mon, 22 Jun 2020 12:58:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592823518; bh=AjldR7lSzE4srHcYluGJ3oH/ie3BZmsR0Ph46rZZm5g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qltgW80XAzY/26uZa6rBcCiVvcxFVpmI0xHD3h8HuPyQA5LT+qW/llhBSj/EZk4V2 AcfdeOuyKX8nZreZGbfwl9RteRy3B83kMx6l+tMdmT/9eJsOh7yqMBKHiH3KM4Tv3E Zvru9vfe2zDLGMUBHUg9U88dVlWupRTy/BnxrTNvmukmnMmrbwPr5ASAJYxPbHG5SQ nkG+lXhNaSczpPvwx1vo113WnafmFEwoDMeHhxliADZWy2ri728Gb3OgJzUCh03VNa V7ivlI3ihgJkuBPFyvSZRMwjhLq/AOy8qLr5Va6WpLxKSvW0X9pDC90XuAatUAXnpR EF1JUM15gCx4w== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 22 Jun 2020 12:58:37 +0200 From: Martin Lucina To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: Event delivery and "domain blocking" on PVHv2 In-Reply-To: <20200619174143.GE735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> <20200619165426.GD735@Air-de-Roger> <20200619174143.GE735@Air-de-Roger> Message-ID: <7ed4a5f98b3002f3233e02d5ce803ef0@lucina.net> X-Sender: martin@lucina.net User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-19 19:42, Roger Pau Monné wrote: > On Fri, Jun 19, 2020 at 06:54:26PM +0200, Roger Pau Monné wrote: >> On Fri, Jun 19, 2020 at 06:41:21PM +0200, Martin Lucina wrote: >> > On 2020-06-19 13:21, Roger Pau Monné wrote: >> > > On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote: >> > > > On 2020-06-18 13:46, Roger Pau Monné wrote: >> > > > > On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote: >> > > > > > At this point I don't really have a clear idea of how to progress, >> > > > > > comparing my implementation side-by-side with the original PV >> > > > > > Mini-OS-based >> > > > > > implementation doesn't show up any differences I can see. >> > > > > > >> > > > > > AFAICT the OCaml code I've also not changed in any material way, and >> > > > > > that >> > > > > > has been running in production on PV for years, so I'd be inclined >> > > > > > to think >> > > > > > the problem is in my reimplementation of the C parts, but where...? >> > > > > >> > > > > A good start would be to print the ISR and IRR lapic registers when >> > > > > blocked, to assert there are no pending vectors there. >> > > > > >> > > > > Can you apply the following patch to your Xen, rebuild and check the >> > > > > output of the 'l' debug key? >> > > > > >> > > > > Also add the output of the 'v' key. >> > > > >> > > > Had to fight the Xen Debian packages a bit as I wanted to patch the >> > > > exact >> > > > same Xen (there are some failures when building on a system that has >> > > > Xen >> > > > installed due to following symlinks when fixing shebangs). >> > > > >> > > > Here you go, when stuck during netfront setup, after allocating its >> > > > event >> > > > channel, presumably waiting on Xenstore: >> > > > >> > > > 'e': >> > > > >> > > > (XEN) Event channel information for domain 3: >> > > > (XEN) Polling vCPUs: {} >> > > > (XEN) port [p/m/s] >> > > > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 >> > > > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 >> > > > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 >> > > > (XEN) 4 [0/1/1]: s=2 n=0 x=0 d=0 >> > > > >> > > > 'l': >> > > > >> > > > (XEN) d3v0 IRR: >> > > > ffff8301732dc200b >> > > > (XEN) d3v0 ISR: >> > > > ffff8301732dc100b >> > > >> > > Which version of Xen is this? AFAICT it doesn't have the support to >> > > print a bitmap. >> > >> > That in Debian 10 (stable): >> > >> > ii xen-hypervisor-4.11-amd64 4.11.3+24-g14b62ab3e5-1~deb10u1.2 >> > amd64 Xen Hypervisor on AMD64 >> > >> > xen_major : 4 >> > xen_minor : 11 >> > xen_extra : .4-pre >> > xen_version : 4.11.4-pre >> > >> > > >> > > Do you think you could also pick commit >> > > 8cd9500958d818e3deabdd0d4164ea6fe1623d7c [0] and rebuild? (and print >> > > the info again). >> > >> > Done, here you go: >> > >> > (XEN) Event channel information for domain 3: >> > (XEN) Polling vCPUs: {} >> > (XEN) port [p/m/s] >> > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 >> > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 >> > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 >> > (XEN) 4 [0/1/1]: s=3 n=0 x=0 d=0 p=35 >> > >> > >> > (XEN) d3v0 IRR: >> > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 >> > (XEN) d3v0 ISR: >> > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 >> >> So there's nothing pending on the lapic. Can you assert that you will >> always execute evtchn_demux_pending after you have received an event >> channel interrupt (ie: executed solo5__xen_evtchn_vector_handler)? >> >> I think this would be simpler if you moved evtchn_demux_pending into >> solo5__xen_evtchn_vector_handler? As there would be less asynchronous >> processing, and thus likely less races? > > Having though about this, I think this model of not demuxing in > solo5__xen_evtchn_vector_handler is always racy, as it's not possible > to assert that you would always call evtchn_demux_pending after > solo5__xen_evtchn_vector_handler? > > Ie: if you receive an interrupt just before going to sleep (after the > sti and before the hlt) you will execute > solo5__xen_evtchn_vector_handler and EOI the vector, but then > evtchn_demux_pending will never get called, and thus the interrupts > will stay indefinitely pending? Aha! Thank you for pointing this out. I think you may be right, but this should be possible without doing the demuxing in interrupt context. How about this arrangement, which appears to work for me; no hangs I can see so far and domU survives ping -f fine with no packet loss: CAMLprim value mirage_xen_evtchn_block_domain(value v_deadline) { struct vcpu_info *vi = VCPU0_INFO(); solo5_time_t deadline = Int64_val(v_deadline); if (solo5_clock_monotonic() < deadline) { __asm__ __volatile__ ("cli" : : : "memory"); if (vi->evtchn_upcall_pending) { __asm__ __volatile__ ("sti"); } else { hypercall_set_timer_op(deadline); __asm__ __volatile__ ("sti; hlt"); } } return Val_unit; } i.e. Always go to sleep with interrupts disabled, but before doing so re-check that no events have become pending since the last time evtchn_demux_pending() was called. This holds, since the only thing that sets vi->evtchn_upcall_pending is Xen, and the only thing that clears it is evtchn_demux_pending(). Right? In an attempt to understand why the original PV code worked I re-read the PV Mini-OS block_domain code again and realised that I had entirely missed one part of its behaviour, which is that it intends[*] to run with interrupts/upcalls disabled *all* the time and relies on SCHEDOP_block atomically re-enabling them and triggering an upcall before returning (PV) or "briefly enabling interrupts to allow handlers to run" (HVM). We're doing the inverse, but our behaviour matches my mental model of how things should work. [*] AFAICT there's a bug in Mini-OS as ASSERT(irqs_disabled) is a no-op, and block_domain is called with upcalls/interrupts enabled the first time round. But I'm not 100% sure, and that code is a twisty little maze of #ifdefs all alike. Martin > Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 11:07:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 11:07:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnKIH-0002wV-U6; Mon, 22 Jun 2020 11:07:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnKIG-0002wN-6j for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 11:07:16 +0000 X-Inumbo-ID: 87676ca4-b478-11ea-b7bb-bc764e2007e4 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [40.107.20.47]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 87676ca4-b478-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 11:07:15 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SYWfCSMnoa319nsrG0OFxyIoyGnc3i8ydR25U3YVa1l3ADoeWrkykCgSK6aKy2HPMzTnhY9NUgtiC3niZytYa2ULUtgsKRXXL7bYVClMetDanGbcm2ysrlmL6mJpcwFGdzvnawdQV5pG9ABu07nFqiPEktqPsq//FlzPHjqjWduaPXJ7foEqtg3Vb1v3qlMu2hEQPM17KA40mUQnMiBFj3WYKKZ1NmuKJMSi4Tal75PGKgfcru38EGPjFfxa+mMBKssGWAqOxupYk1KW99ZQAA2P11NFg2uS3BFY2sE0gorEyRsp1PZXV8HhBGwuM66WKieD53IGr4gR4yEerHAfBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4d7R8yFQ34wsCJ6WFbtDARl8fhNNb4F/O/edTEMV+0o=; b=il7FGHBnFoK1+jDosD/+Kg1fGqnNe8/XScJo5ALWqwCbUc+58fDboaBCPHA/3SZDzi7rUr9qTlETIkO6IVPqMlODScnM7WAaNRQVwW657TDmR7H56GaA5yh5mLD4nQwQwzUIgfN+hCKDnMwTqKUF+5/Ww4stxVhLsC3DpFSSN0kNjPvCrlpgPjK3JG9O7IFbXxXbWoJcNhn9A3neo04kkDjNKhEYtWSs65tpiCFJ8rkNEar4UcSDaQocMWdCcjqPrQxJjHv4KljlbfcncN12rVGvoHxFv83i+6OuOpCR9RxiSFwvbug13PzQoECw/gUOoNoxw1fnUFiVVc1kH/M6MA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4d7R8yFQ34wsCJ6WFbtDARl8fhNNb4F/O/edTEMV+0o=; b=cGOkqVmOZBNWgYlIl/hb2nYXmr+O0gGTDhlLQGjhKRi3+b0TD+64efmX619pMvEYLR3p5WOeq6ENDIK1E32PG9K8UDxqwTGHFB09lJ2nFatKERk4Qh9zymi1GL3jtJajgNjolMkY8w6G+A+rN1cD8qWMJI1hQp6BL63oNjCUdsbx6i/pUtfXHq2cPQSXiLjioUnA26kV1YReYz0pQS4hpWXiZAL7vIft4nDgOhRyAl4DCB5Sx6HklasZTl39p7mtcxeWo8+Z0jBhFIXW8qM4Fa2LhjmawgNT0ttO7Z8HSxeyE3opzVTAx8C2fDdj+d2fMwmZgsrS8YpGQ73SSZ17Rw== Authentication-Results: epam.com; dkim=none (message not signed) header.d=none;epam.com; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB4286.eurprd04.prod.outlook.com (2603:10a6:803:46::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Mon, 22 Jun 2020 11:07:13 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 11:07:13 +0000 Subject: Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200618160403.35199-1-roger.pau@citrix.com> <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> <20200622093123.GI735@Air-de-Roger> From: Jan Beulich Message-ID: <5ad66ef4-9406-f35a-5683-ac4608242dd7@suse.com> Date: Mon, 22 Jun 2020 13:07:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <20200622093123.GI735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: FR2P281CA0005.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::15) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by FR2P281CA0005.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Mon, 22 Jun 2020 11:07:13 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 13be6c2a-d215-4834-f4b3-08d8169c6abd X-MS-TrafficTypeDiagnostic: VI1PR04MB4286: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0yR5LoDDiYKYj62/5seI6MpR2herFq88gj5aF4jsnyswce8ECxY+21Kf4Mt7xlY0+fN27XsffnCzNTpP5uUpHybrKD5mnLWwPisDFrc+troZIeMPf5CfLKatkYBs3oEsQdiryNw6GSTIZm/XbJiHNpGQDZHRhMJKIPPZBKTXZTknNkVw2GM2tJ01DszZgAeS9gVxMZ8SzYukAXS1XwgV4Ek9GZp6z9HCkDPHbJpTc+3JqoQhBfV/MILOznro4qY5N5FBYJEQLF0wbbZCM8oG+fzWv1XSojotj8h8CwrU+W4eSby+MHrU1YcVBDslBqUR5OelBlNJyAO7ofvYE14yMgblT00mf/oP7bEqNW1IszF5lTRn/PpO3RJbeswkyi/G X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(39860400002)(396003)(376002)(346002)(136003)(8936002)(31686004)(6486002)(956004)(52116002)(2616005)(8676002)(36756003)(86362001)(26005)(16526019)(186003)(316002)(16576012)(31696002)(4326008)(54906003)(53546011)(7416002)(478600001)(5660300002)(66946007)(66476007)(6916009)(83380400001)(2906002)(66556008)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: XcQ7vKg1yGe2nsqbUi8FaQdWFOS5oXzZKZThk1wzxwBt5Ka4+HmiXgwhN3w/ZAqLqz7FTvr2CpXbnhcTGgq+07ZeILCtJ8gMHYAf0R7w200jQuiWhi9AV2AR4RrNYGKhT7PQxO3TARp0soJP6dzRkPY3Tds68GXIIAIkIFu5+gVLhKirpUtSwrSLQSc62t9/AKFkrc3m80S4Np1Le+PNOV2sOt8v5j8fROv0EMIfk307A0LrSjGaER/LbGFjkIMvAXRb/zLUX6RGBWXgbsMWlpx/ruksGzon+UEa6V4X0YOeE0aiDsAlyhxpUsjl3SdnRtC40qkeli5HlcoINUSGNDJ+7t0vNhsb2iq/R7DDCcwcjeclB7iGk4bt5HmIdVNhGL/MX3g0Khci/Wxlo+HbalyoE9o6MKxaFH0sk3nNJJX1DNlybBXjRirAeCAguScSlGs/lg7UsFib3iFNQAKpBYyPjiJDNXtFswtkGGWIw/U= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13be6c2a-d215-4834-f4b3-08d8169c6abd X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 11:07:13.5517 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zG96Na0Zesg+h7SIUOXyPbEd/o4MNBufywgmwgzxSMh70BdkLL+RWrdsmEQGw20104F67gy4cwQeWr6TrodCxA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4286 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 11:31, Roger Pau Monné wrote: > On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote: >> On 18.06.2020 18:04, Roger Pau Monne wrote: >>> Commit e9aca9470ed86 introduced a regression when avoiding sending >>> IPIs for certain flush operations. Xen page fault handler >>> (spurious_page_fault) relies on blocking interrupts in order to >>> prevent handling TLB flush IPIs and thus preventing other CPUs from >>> removing page tables pages. Switching to assisted flushing avoided such >>> IPIs, and thus can result in pages belonging to the page tables being >>> removed (and possibly re-used) while __page_fault_type is being >>> executed. >>> >>> Force some of the TLB flushes to use IPIs, thus avoiding the assisted >>> TLB flush. Those selected flushes are the page type change (when >>> switching from a page table type to a different one, ie: a page that >>> has been removed as a page table) and page allocation. This sadly has >>> a negative performance impact on the pvshim, as less assisted flushes >>> can be used. >>> >>> Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush >>> using an IPI (flush_tlb_mask_sync). Note that the flag is only >>> meaningfully defined when the hypervisor supports PV mode, as >>> otherwise translated domains are in charge of their page tables and >>> won't share page tables with Xen, thus not influencing the result of >>> page walks performed by the spurious fault handler. >> >> Is this true for shadow mode? If a page shadowing a guest one was >> given back quickly enough to the allocator and then re-used, I think >> the same situation could in principle arise. > > Hm, I think it's not applicable to HVM shadow mode at least, because > CR3 is switched as part of vmentry/vmexit, and the page tables are not > shared between Xen and the guest, so there's no way for a HVM shadow > guest to modify the page-tables while Xen is walking them in > spurious_page_fault (note spurious_page_fault is only called when the > fault happens in non-guest context). I'm afraid I disagree, because of shadow's use of "linear page tables". >>> Note the flag is not defined on Arm, and the introduced helper is just >>> a dummy alias to the existing flush_tlb_mask. >>> >>> Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') >>> Reported-by: Andrew Cooper >>> Signed-off-by: Roger Pau Monné >>> --- >>> It's my understanding that not doing such IPI flushes could lead to >>> the pages tables being read by __page_fault_type being modified by a >>> third party, which could make them point to other mfns out of the >>> scope of the guest allowed physical memory addresses. However those >>> accesses would be limited to __page_fault_type, and hence the main >>> worry would be that a guest could make it point to read from a >>> physical memory region that has side effects? >> >> I don't think so, no - the memory could be changed such that the >> PTEs are invalid altogether (like having reserved bits set). Consider >> for example the case of reading an MFN out of such a PTE that's larger >> than the physical address width supported by the CPU. Afaict >> map_domain_page() will happily install a respective page table entry, >> but we'd get a reserved-bit #PF upon reading from that mapping. > > So there are no hazards from executing __page_fault_type against a > page-table that could be modified by a user? There are - I realize only now that the way I started my earlier reply was ambiguous. I meant to negate your "only with side effects" way of thinking. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 11:38:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 11:38:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnKmU-0005d9-DE; Mon, 22 Jun 2020 11:38:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnKmS-0005d4-FP for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 11:38:28 +0000 X-Inumbo-ID: e28ec146-b47c-11ea-be7b-12813bfff9fa Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.44]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e28ec146-b47c-11ea-be7b-12813bfff9fa; Mon, 22 Jun 2020 11:38:26 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jGA1KykcibwSxYi4X/rLpz9CTNUq0aoSyBS2pLkDU1+4JN1kOPcdgyUHYozl7BM7bTPZ66To0gE6CjtJ2+eARmgmLJeix7xp1Vm8pCWQG9KdA4VGawQkBAQgM65AyScRg89iqoO2wn4g9NlbOpsvEy4pny5YaCyf5P6hOo68sq8Zb2XoIOiIk22Bjv0vm8Azq2hFtCaVbCvj3aewGhG4sVOQ6W45Ea3pRpVuF2RNib5sH1SMzPUH75IxrE22X1EC8mJ0b1UJem8nmp1wnW8y+D4yLug7TUVwgBYe6EZEeB6wM+zTGiVbqUxJmyWw0KB3fTWKDeTAEZzMSmEfSNDsQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F8Cd6J/K4V4jsqO+vKKXl7+fwVhRT2ulpMtyVF9SAro=; b=PrVBDXRnULYzWfTbKsC76CEPTaB2vNODuAQtSp1OaxPW3OLkja9hg5X7F8rShT69W1TTDgGEEiZQpZFfvhrKHar+vyFegcHHdsiAc5AvvLkvmdE2Fxrm8UDzWHP9YO29i5e1Q9YTX2ueAlidm+KvyTZIti0VMOYumLjlI+Nluf01yL5WT6ZQ1sFdOWS4ZUkVie4SKO1XWFpymVmjOKEKwes1yC6Duq6QOy4pF6ztOaDeN2BY3kRCsm3gth3xHqNrjrEhnCI3sFh2Zk/EAxpkuUokGANYNBU3YKwOJ4U/0cPzDRq14RB6uEFkkN+PW35aqiPR9fLYEfCvkl3lCzZDig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F8Cd6J/K4V4jsqO+vKKXl7+fwVhRT2ulpMtyVF9SAro=; b=lvORNLSfYwJfIv1N4npzAJk2QUb8H1qx8d3jGfhIZDKk74os8kdU78aiXgfnZnWIVGYoH+2BMeiE7NAnaLRRnFh0SKQDRXZy7xlglb0MUNsXQt12btAvmq5Vn9W4D+5bc58S9/j72dqisoj8L69gk4+/5fvMz+dLBeYF33QcluZpDSmFS+6P0eUIvlrTyiXfXdkVCi8kIDNw3iMTs+gKhSldorE+CQde6Bt6re8DFLAjYh1PJoPZ3pSTdBsZZDQAjY1Fjwxwubwd4K/mNE4eNeLy4bBYQrX/dggG+Kj4RZetD75RQqTIc3ukRnZnKPP7GC8W1B6EzckhvTfz57PcLw== Authentication-Results: starlab.io; dkim=none (message not signed) header.d=none;starlab.io; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB3184.eurprd04.prod.outlook.com (2603:10a6:802:9::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 22 Jun 2020 11:38:25 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 11:38:24 +0000 Subject: Re: [RFC XEN PATCH 19/23] riscv: Add the lib directory To: Bobby Eshleman References: <65b894a039c4097a25a8d0b19e56646574159b14.1579615303.git.bobbyeshleman@gmail.com> From: Jan Beulich Message-ID: <8e76ed4b-6d96-40ad-54bc-4243e6d12915@suse.com> Date: Mon, 22 Jun 2020 13:38:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <65b894a039c4097a25a8d0b19e56646574159b14.1579615303.git.bobbyeshleman@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM0PR06CA0114.eurprd06.prod.outlook.com (2603:10a6:208:ab::19) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM0PR06CA0114.eurprd06.prod.outlook.com (2603:10a6:208:ab::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Mon, 22 Jun 2020 11:38:24 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 29f86139-1a3a-4a7d-8f5f-08d816a0c61b X-MS-TrafficTypeDiagnostic: VI1PR04MB3184: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5516; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: WwzxEIponUsjjxUEVIeXJ0N6yVZj7+f2DSC9WuM63MkEea3wYuAJUbQZmw5dggvxR9RHIfTsVTbp2r5sbTkaBMe4s1ZHL3QvBJru1A28hVCZbSXlfMHPpeJvViq2/6g94U12fGhSOaJ6rYwxx4dBVvMRvwi/fDuH2Fwj9UdJw7Z9blpb8uge0GKzGZ0rNy0OlKHb7nPbEZVyAoxeSJkhzIbYIwT/sfn2etIhW44CIEpEs9cDRupgPyKXi1a7q92hx0DycgqxW1ZelBDjbks1SXtYJe/yUSz9fA4wkkSi5km6hcHm4jx0zBmboDT1ggAbRCc3TuXGpSKbFJi7rVtSjaWZLBuDhl0++Bo04Ac78WjfwqfIlA7/SQvggZ/zLWYX X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(136003)(366004)(39860400002)(396003)(376002)(66556008)(54906003)(6916009)(558084003)(5660300002)(66946007)(66476007)(2906002)(31696002)(4326008)(36756003)(86362001)(6486002)(8676002)(956004)(6666004)(7416002)(26005)(16526019)(186003)(53546011)(52116002)(31686004)(16576012)(478600001)(316002)(8936002)(2616005)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: FGYZr99cA0uW/1CjdKVemzZLn1GddIqRj9jGNkP6UTPgSPLXCkPDoxM4c1LQubX5AvlzUbt4EOOO5ku9Nj+UmWT2rl0Wk7bACB7HTH6lELmS9lGUCe/UqxLx5YrMDayLTCuN1UT7+BACnBqY5RXHOjxx4XoZ4oWMonR8ITG/+TzI1GX2o2E2YOClQ+xaBJdvhB1l751cHaqjAs+aoBqiI2ePv41pfS58tH5clATUaPBvmVjb4s7IpRdqrJtVEFZh53xRM01FmsTNI5LcgEHvdpESjM7T4S34eJsBqDNwpEy5TEOA1Y7F6aO/CRoN69FGAQ916esKKqoKq8phuBm9BXmfjgOO69DduRnuZNYEhTpR5iwoM0Ny9PDscHQyV2+cmHGv+BA+9hLEZV5iF8AOKfJXT9ja2a4EIOxshbbPjWXDrD0xkTGRRuHkJd01eE/H5ac2el3G+9ugrQntOCpuNfMovtlwHZUgeLW6mATOEpo= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29f86139-1a3a-4a7d-8f5f-08d816a0c61b X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 11:38:24.8018 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0XbDx04FhF3eOG4xJ0oAnzjq91+H3SVPHcb3raHCAbjpGu3F4DrV/KJU210T0ljJIRaCUe1ta94zzIqoqDKrJA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3184 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Bobby Eshleman , Dan Robertson , Alistair Francis , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.01.2020 02:58, Bobby Eshleman wrote: > From: Alistair Francis > > Add the lib directory with find_next_bit support. > > This was taken from Linux As was Arm64's - the two definitely would want folding. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 11:43:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 11:43:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnKrb-0006Qt-1X; Mon, 22 Jun 2020 11:43:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnKra-0006Qm-3o for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 11:43:46 +0000 X-Inumbo-ID: a09dfd3c-b47d-11ea-bb8b-bc764e2007e4 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (unknown [40.107.3.59]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a09dfd3c-b47d-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 11:43:45 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JpvFXO74JMXGHYMRjs5mL/g2WH2Sqrl5I7dRyDqT3AXe221Z7P6w0/XQTE1b7N3mB02nBqnmprPrc3yBmK1IJO+5aTd1H25k8z5MyKEyJg/a0eVRN7funCQRyi+Hxk4CXmkf16CdmcIuHnHxywpMB25Cg8eA/Kst8klYEM1yH35osRBCAC5sDy2Tx9RMxx1F/2T66LuxkycD1RqM0QinswC2afonsS79/6MABcScIpQ1WonvBmKhSZALV1MpMXyS1nnBO7re+720gc+yM4BtdumLRTJWWgU05EPUbd2dAgO4EtNmdwyCsMd0DTT+QumCgY4tLfyYk9246DUyX3gHNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/SYjeg/ozQ31IKYOJt0B1R7JJDh2aIqKSbtZjFwpt24=; b=fEnuTK+Dje/VBvQueK+0Iquuus4Nwl62vV5+f9ktgLmxFZaX5fE26Avyq5lvrdQLMjED1mQINDRE7hMiaI+q20BKIcpc6TjYTCK6JrAYhjCamxY/4BQWSU26GDhwQcGqEleWYkoDS1uYtGsqprg0/eg4ec43Dyd4x1J6Nii/iC7NI63xHeXt65C8vBF+/L+/YM5GnJ0LWQwpSG0LcXsZ4gFnJBMrb0vdgJOS8R9HbLS5hmrcZdGvFKlLrZuVVoR3meh5Gb67rBMkIE7+zvlzgQpDEKQB+Y+RlYm5hXJdgSuhdXg6mRsPVUfjCiDdG7O5uHo6v1HWakWecDYYAjDRoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/SYjeg/ozQ31IKYOJt0B1R7JJDh2aIqKSbtZjFwpt24=; b=H5EYSKbNkJRca7QtTpmwFnj31jzcgu6lms0k8UPjmg8c9NMFtcPdnAhJJqwvCZUQVp69qSKK9KHNiWyLPX5lmCuNshBzwhTLWVg/T7iRWIuF7KPfLO+sX6RspKTYeWYOEkxNaxW/S6exD4eUrRUYT8J8Oec7Jk6w2QfgVvouOylLg9AY9BMA8UjxTnd7kpstF+98j5n0cYFJ+zHtSl1chiVZsacR7gSTlu+a6dbO0MmGhcOREs2k8hGMzdNvzDXuwDiEb0P70O7+z0BzML/F4GyIGcnJctR4Ntt7e/2wC1B7ef5TXmDyLT120Es3okqOgS22BSpXJ3E7G4xnMZNRGA== Authentication-Results: starlab.io; dkim=none (message not signed) header.d=none;starlab.io; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB5936.eurprd04.prod.outlook.com (2603:10a6:803:e1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 22 Jun 2020 11:43:43 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 11:43:43 +0000 Subject: Re: [RFC XEN PATCH 22/23] riscv: Add sysctl.c To: Bobby Eshleman References: <7ebc34d888493f27302ed0a53e09216233cc9e7e.1579615303.git.bobbyeshleman@gmail.com> From: Jan Beulich Message-ID: Date: Mon, 22 Jun 2020 13:43:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <7ebc34d888493f27302ed0a53e09216233cc9e7e.1579615303.git.bobbyeshleman@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM4PR0202CA0010.eurprd02.prod.outlook.com (2603:10a6:200:89::20) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM4PR0202CA0010.eurprd02.prod.outlook.com (2603:10a6:200:89::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Mon, 22 Jun 2020 11:43:42 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 939db084-1a86-40a4-2275-08d816a18430 X-MS-TrafficTypeDiagnostic: VI1PR04MB5936: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4941; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Tk+lhjXS3YD21LtMV8KFDRIL983Jl+lreVSkwfE310nZCYFzNc+vIGlPfMBNLq9DgOoEeTp5MgiW70rK3gO+HGzZKvJOPTFpdbNKWdF/jT5/WAFDmoiucZFUaRGuukTHpp7cRYxXLN14WleEb3BRiYXDfudc9UqHnwuN3IxgY0qxjYOf1OHSpqCFXsgW+I05LeDb9hmGm/TTiTsBTzyzUsQSbkG9kuZceNN/gizD2y4WykCumttZOlphYrXnlcVcDdrJ9lKkUuCH36fS8AZCMQLw4TXVNkQGHkPjvwlleYZhbi1rYAxdrAp9ryM2nvO8oje6ehphzuAgpjeRJ2zfthH+Hx1V6z02NOHbCOunRZQgv9WNwqSo3+O7YNreuCKZ X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(376002)(39860400002)(396003)(366004)(136003)(86362001)(31686004)(16526019)(478600001)(186003)(7416002)(316002)(53546011)(6916009)(52116002)(26005)(16576012)(31696002)(54906003)(2616005)(956004)(6486002)(8936002)(5660300002)(66476007)(66946007)(36756003)(4744005)(2906002)(8676002)(66556008)(4326008)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: rL75Eio2v/tOinaoynee25FFjaWJnT6C1ZWCci9Q7zdMPzBhe2R0kLAO+czxAmavFEiBavt6vpU3Yy1qnt8wRDmBE+oXfCcLn5lPXCmhhtccK/vNpOU5aK/3OKXXoOajblh+Hc4HIA0LcCtKv8TivLzdo6AZlYPixAO9hLAiuc0CghRAKTZI7aU0tOmV8X9kzOPg0SBGsgTnyk/FrD0e4yJ+62QqZbFJnR304JC0KZ0ELjxs3E49gpy3wrnFg8AQtnoAy5ScDV7gh6/o3GW4DuZukO0qeNceK4aphWYDM2HYz6TPKCQwdl2I1vV+eOZ7IT0PoXDpLkXYowAWdMj/sCzQIGzQhUhRSL9BQBXcKakEzJ961mBWd5wdysjLtjI6H5v85Owo4i/gpfc5ydnQ757SafSubthK7gOvyb86RPy9drla8aWLX3Jm1ReO8eRCOpRqmDeL0hgrlW1oDGGCTH5xDs8e/L8FJFV9OkOn0y0= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 939db084-1a86-40a4-2275-08d816a18430 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 11:43:43.7067 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zRe0E5axH25jWRBeJgK7OxlNonULkQSSFbYOJ7Hj7oQdHDDC5ZaFmVksT+6KaTfglF09SzIbljoVzj9RyuCeBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5936 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Bobby Eshleman , Dan Robertson , Alistair Francis , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.01.2020 02:59, Bobby Eshleman wrote: > --- /dev/null > +++ b/xen/arch/riscv/sysctl.c > @@ -0,0 +1,31 @@ > +/****************************************************************************** > + * Arch-specific sysctl.c > + * > + * System management operations. For use by node control stack. > + * > + * Copyright (c) 2012, Citrix Systems > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +void arch_do_physinfo(struct xen_sysctl_physinfo *pi) { } > + > +long arch_do_sysctl(struct xen_sysctl *sysctl, > + XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) > +{ > + return -ENOSYS; At the example of this (there may be more in this series) - -EOPNOTSUPP please. Only top level hypercall handlers ought to produce -ENOSYS, for major hypercall numbers with no handler. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 12:09:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 12:09:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnLGL-000057-Mo; Mon, 22 Jun 2020 12:09:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnLGK-00004x-DX for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 12:09:20 +0000 X-Inumbo-ID: 32ff2a36-b481-11ea-be80-12813bfff9fa Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.60]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 32ff2a36-b481-11ea-be80-12813bfff9fa; Mon, 22 Jun 2020 12:09:19 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NhQhe6VOQ8v3XFZqzMKWrw8dKFoDlTqeu35cR+cEU0NkXpXAE1LMzMPpkEVNxeaJ0tEJAvf5bHaDAUlZMWWpPoKMjzq50nP6hV5xVRklFDfTtIomCST8PyimeaIMUK1MpibR8nAfdcDwNll0Ix7etPZP4e3utKcG6IcLR4ey51Olo2GtEQ0AW36OebKbzDHc5DiS83RHguU/Jd8F5ioDOqAQpCw81sFXYF4+dqzYtEM+i228p05+JIfn2CmZsgOEfZRoXFZ1WGh7T14F/UJf2y5OZdEPwK6LJV6CTjPsa8acxl1mLi9KjRqjkgNVXoziD22QYQWOFBBioPInxy2t0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m2QBB9clr1SHHh3MBypsBjTwJY1i/ptJALFqpBUTIKI=; b=PzWYmjEvZIf5DMeSDMkfExzbGjNXvYxUtwtSluqHqUnfl+8aAnJSWMQ/zb9dGsxnAmTqs1QqPo/YqxNluTQzmwtwT/v9JkGEc36iDPp3KkTErTkoWxPwTPDwe5LgqIh2RkVclAxf8uRpp93BSOpJ1Qr6wJoEBm8mb5QhwbtA75+6kEi/uWTbchwgQfrJtnU5VdVm1IQ3u9kb8FjJSkfBVelxRx9sJkqvu2AkFEsh7TIPb8G2fHlPDHNmkNjF42TnETid5TcE8CeXrqcpN4k5MfUUgwRyr0fwd0Tz4P5JSErXLeMpgaUn/oLJtEBmueChf9eGJnOttmfl/81gUzEyvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m2QBB9clr1SHHh3MBypsBjTwJY1i/ptJALFqpBUTIKI=; b=N9CV9sMJtoE36cjNjLP0lJcne4bLDpxBw55yeHnP1Ao4mw0NijpGPtQ47DrleILANhZ59cvDnQLH/egb0B4jFUop1gTQE2nJpNCfh1KvgwDmfm3K6l9hk6bopv9lCP4piFMUPtfI4yD6y50AyVBapLFM+BNxHBAL7JRyOSgmd2h6EzUtqh8UyRMJHeeFINrOSQWj02NLbF1y+BJ3RGj5vM8e60UmCTkn9IEzRDPRm3f9JmJMvIEJBLxu98MhwbPmkZRd6/a8F+Ff//SMOfD7nxJfk607z0r8JLNm9fJWz0Eu3a9BZ8W8pVN3oYMrVr1BdfhwIKC9Y6VBy11Yt5e7pA== Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB3293.eurprd04.prod.outlook.com (2603:10a6:802:11::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 22 Jun 2020 12:09:17 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 12:09:17 +0000 To: "xen-devel@lists.xenproject.org" From: Jan Beulich Subject: [PATCH] x86/CPUID: fill all fields in x86_cpuid_policy_fill_native() Message-ID: <41177396-9944-0bbd-66d2-8b4f2bd063f0@suse.com> Date: Mon, 22 Jun 2020 14:09:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM0PR03CA0103.eurprd03.prod.outlook.com (2603:10a6:208:69::44) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM0PR03CA0103.eurprd03.prod.outlook.com (2603:10a6:208:69::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21 via Frontend Transport; Mon, 22 Jun 2020 12:09:16 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6299d30b-cb81-48f3-fe5e-08d816a51639 X-MS-TrafficTypeDiagnostic: VI1PR04MB3293: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:820; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jmnREIui+5CvL4mXRW8yTydA52W/lpy/K3/7fTZrl6Yt5CdcwyRz4oMTWb0fns/hDFYskUKqOlhV6j9KrIGlZIvmQIP0FW734D22i65sEndcQmhoANHlrCGLjyKkG77b/b7+LBXfh27R3JBRatTVkWd548tzTW/k4RAfntMSKOIPKRqZDavvNKGuMaho6Vldh5YIO8aSzvV0Q3SisFqkthcCVPcFJelsGdZWIXJHpL6c9pjbsUpTdiOoBzzBntC9ZUgD+kAjDD2LcyKXQLcET7QG5O1fiRFcgB4+XlQmvq29FMaoJ2TLgecbcY50O96ItKOa7Ecq1NYeo8vi07JJDO+E1fXvtyBQlzABdyfMVubKznHuOftSCmWX4uw+ShyA X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(396003)(136003)(39860400002)(366004)(376002)(346002)(6666004)(956004)(2616005)(6916009)(31696002)(16526019)(186003)(83380400001)(86362001)(4744005)(5660300002)(26005)(66946007)(31686004)(66476007)(66556008)(478600001)(2906002)(16576012)(4326008)(54906003)(52116002)(8936002)(316002)(6486002)(8676002)(36756003)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: q3X7VrizBm7u+QN6xJuNtzFEiFCr6cL0VdSHjaDGh4D+3z7joZfYFUqQLcLDwCijr5b343OmYj2A362xR3tV+eAC8jQlVR3Tizk66lQ7OlX8ZhIPG6MJMtx/bsRZ2w2V3kMZNmaFavkQUJlcsGTS3GsaRH7SzHZP9NAz6s2ncn7h+UTZkgoo6R3lIGPSuHrDNzyAdl+DeA0kKxSJAG9CRwJHW9iZmd6ILX574iy2TJq45PYxF9disRpORoHcK5Vl/anaSMVyObS8pCRRqxeYSNqt1souDVXs3X+r91ZgBOJFJ0KzGT0PlActrSZXCoKORC7yWEgCKnQcJtYwcZv0HlqAlzFx3CRI+ckCkrSwq8BWT9/qpqRwhRVEMbOS5BDOahsmsGQbKer6ZdiBsMa4y8d7wc2OGy9ez/sMC7XC16bxFdx+EQLxBKciHNkf7arICnxNucEgLh7FY0AnTcAroZoOVbGrTJl6zpZOidNndIo= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6299d30b-cb81-48f3-fe5e-08d816a51639 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 12:09:17.1959 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Dl5bloqmc64EKMXUkSEfWxAUuPzNbEajVLFJ0UP109DVbhrPJAYtP1SD3PGisOuBukRNaIThxDqPsUnCz4HFpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB3293 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Coverity validly complains that the new call from tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves two fields uninitialized, yet they get then consumed by x86_cpuid_copy_to_buffer(). (All other present callers of the function pass a pointer to a static - and hence initialized - buffer.) Coverity-ID: 1464809 Fixes: c22ced93e167 ("tests/cpu-policy: Confirm that CPUID serialisation is sorted") Signed-off-by: Jan Beulich --- a/xen/lib/x86/cpuid.c +++ b/xen/lib/x86/cpuid.c @@ -176,6 +176,10 @@ void x86_cpuid_policy_fill_native(struct ARRAY_SIZE(p->extd.raw) - 1); ++i ) cpuid_leaf(0x80000000 + i, &p->extd.raw[i]); + /* Don't report leaves from possible lower level hypervisor. */ + p->hv_limit = 0; + p->hv2_limit = 0; + x86_cpuid_policy_recalc_synth(p); } From xen-devel-bounces@lists.xenproject.org Mon Jun 22 12:36:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 12:36:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnLgK-0002c4-TR; Mon, 22 Jun 2020 12:36:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnLgJ-0002bz-QD for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 12:36:11 +0000 X-Inumbo-ID: f27881ca-b484-11ea-be86-12813bfff9fa Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [40.107.6.45]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f27881ca-b484-11ea-be86-12813bfff9fa; Mon, 22 Jun 2020 12:36:09 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TUegx7t13yIqVFmrh6EF9tAeP+6Fq+p+YFuSl6HDNEX2JJE9y0ZHKE3QuZgtnBteRktXVr62f5O41iO0Qqtfj5/O3ehogCh5M4sndiJARi/XEgVpL9zvVeTstdLbMNcD7kGjYTsC7eW0kQmTDvsQdfCGCd7RRu4xSGFo2ttH6unqHcy2F77NAgMICRFaLI9dwxdJbuAwDDRoVuWB0kEY3vwaFyxjtrRg7g4C30QOKTeXluIOxezT5X2VSvZoqCeJzGqC+0uUC8qPlhbrxVTMBi+9YQlLX/uuqSrjlGCbllrt2KJ84QJDXSTSE92II23O6YawCvXWLHniBy0aSpw6nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mDMm5egDgN3EYbBLG3djJ7VTHj0NgvGfUORgRWj74og=; b=ciDUrRFH57g29/kuErccHMdODURGYOntHkK3agpU+Mm3xWxJizEdoLt+cLHmDC98wu3lzISymZ+zAR0bjWgtO/LD4LHpqBDdeNvpILkygg8maBxkPhS56YxYYcg/A9b9mZjWVAWF/zbSoovY0OYORsmCRCToYAjCsMLJwQA2tFlkhR5njFpe881jWObdjW6MxtZkp+Yp779kAuCOzZdbcl32qkK53eoO4yd/AbpYekAPO+jdirSzJR91iOubfT5/3VwC383b8EulS9nBB0WwWXwiaZQ76LfEY6SE1AG1W4n7cwKb2z+qDFLrb2VvcSYVc5BvcZdYywRceTSxuyuxJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mDMm5egDgN3EYbBLG3djJ7VTHj0NgvGfUORgRWj74og=; b=fVzenMpBTvlE26JOnsVn1vKvUc/uVYQStFc5p4sHUL4R15JUlYoDB045xeiaO9OnMlFBjDNB/q67CpvwGF6YlLk4fI7re7Jm4yIl0ITP5w8UtULUVonClmdoG+lt0vEgCsJMP/un0eTMSOGHfblDJWrRRjlfSCbKm2qjUCwe43CyP0r9Zy4La7OGOsfxxdT7gTanKJAUr7ycBs3vsw4ub/YtsGrDWUr2s+YIQ8oQH2oBbwnj3A1g4ig5pKoGgP/1omP8cGwzMjne/boqlXkJweOUdQFWd2izDk0SW26IU1zVpSduzNQwLZR5Z29X3FDoRT/6R6RxG1aOeRVJf1hIYg== Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB5583.eurprd04.prod.outlook.com (2603:10a6:803:d4::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Mon, 22 Jun 2020 12:36:07 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 12:36:06 +0000 Subject: Re: [PATCH v2 2/7] x86/vmx: add Intel PT MSR definitions To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <61296395.9820908.1592523575731.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <5cbc6d81-03f3-2c24-4d6e-5aba458ebfc7@suse.com> Date: Mon, 22 Jun 2020 14:35:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <61296395.9820908.1592523575731.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR10CA0006.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::16) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM0PR10CA0006.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Mon, 22 Jun 2020 12:36:05 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 827dd706-6302-4357-eda1-08d816a8d563 X-MS-TrafficTypeDiagnostic: VI1PR04MB5583: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /FpxeuP5bUSqpgmNPQMHH5frKhdZJfsbVcXa1atR53M1qLyFbhQogXavq0PvZfcSVK3oBqos08XPE/zIZ1RARyPP+XCIPwA08jvaYYX4AnUYDbk5VY15lZ2TN7/4/DXwshbg/wmp101sRxH0Z9HKQfn3r4XJOAFzL/rTn5jXZnq58Qo0DzO8uc3QiAK6/OpE3Anqm3+NHHj0KfBGD9r7agz+F3V351+C5vx5Qo1OeJncM3UeMtycvdBaLc+719fUT+KKy4uTwlwYWi1CNSGEECm4xjgTQWxghBcDv2i/ezrRGorw/b4hGXdhP/wmBf9YX/U9pNd3ZlI1hn1E04q3pbRR604cD/HqN06Cj9km/1wElR8DrARE0L7xajE43VDX X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(39860400002)(346002)(136003)(366004)(396003)(86362001)(8676002)(5660300002)(16526019)(66556008)(66476007)(66946007)(8936002)(26005)(186003)(36756003)(2906002)(66574015)(31686004)(4326008)(31696002)(52116002)(478600001)(54906003)(16576012)(6666004)(53546011)(83380400001)(316002)(956004)(6916009)(2616005)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: ZyPVAIMn1yNwH9GD0kPV4b56aE1G2rG83s7pgwP2nmtLwCx9hSA+w5a93kMPoUfeQIuyaOsVX90NwMrT3pTQFDjjai5YMu1b6NxkUDWTfqHhFlTvmtTrIZB2NeIdplAnazOeV6QO/DGrJxQDA7rDrPo9oSstweL9lletgHfh147JlDrzMJozh5uJSndfTEaQz88QFqS2gtSmITQpvAKw/P/612zFlnvgP4TBkqZMARTjb04lkWqPimmJqH+VyqqLwYG5nmKiUWsuQat44p86HJipvMzyGWcWregs1UJt1FMM9qKBuPFNQNpr6j39kfEOKv5W8YM5EPAhHc6kPux1a/+Ojq6mVEHBVcDfvSjmh1GDbJDpDJ7lRUul6WJfTArOdbNgUNuXyv6rAmPGNnvhPAXWuOAyg3zZDFHz9n3ojlSyqKSE9kJjCdZRz1ZkCO40GuXRlmsy+J5Kthl983cfla9o8tIzQ0VCAhTTPzeZ72o= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 827dd706-6302-4357-eda1-08d816a8d563 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 12:36:06.4267 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: KOwzU7L3v93BixDuo1ppQGwIM9HKZmj8YcgQTd5sNxwJUaOcJG4Sdgih/wpKo9S4WX/65A8h7xWTUVQvrCJGtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5583 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Kang, Luwei" , Wei Liu , Tamas K Lengyel , Andrew Cooper , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 01:39, Michał Leszczyński wrote: > --- a/xen/include/asm-x86/msr-index.h > +++ b/xen/include/asm-x86/msr-index.h > @@ -621,4 +621,41 @@ > #define MSR_PKGC9_IRTL 0x00000634 > #define MSR_PKGC10_IRTL 0x00000635 > > +/* Intel PT MSRs */ > +#define MSR_RTIT_OUTPUT_BASE 0x00000560 > +#define MSR_RTIT_OUTPUT_MASK 0x00000561 > +#define MSR_RTIT_CTL 0x00000570 > +#define RTIT_CTL_TRACEEN (_AC(1, ULL) << 0) > +#define RTIT_CTL_CYCEN (_AC(1, ULL) << 1) > +#define RTIT_CTL_OS (_AC(1, ULL) << 2) > +#define RTIT_CTL_USR (_AC(1, ULL) << 3) > +#define RTIT_CTL_PWR_EVT_EN (_AC(1, ULL) << 4) > +#define RTIT_CTL_FUP_ON_PTW (_AC(1, ULL) << 5) > +#define RTIT_CTL_FABRIC_EN (_AC(1, ULL) << 6) > +#define RTIT_CTL_CR3_FILTER (_AC(1, ULL) << 7) > +#define RTIT_CTL_TOPA (_AC(1, ULL) << 8) > +#define RTIT_CTL_MTC_EN (_AC(1, ULL) << 9) > +#define RTIT_CTL_TSC_EN (_AC(1, ULL) << 10) > +#define RTIT_CTL_DIS_RETC (_AC(1, ULL) << 11) > +#define RTIT_CTL_PTW_EN (_AC(1, ULL) << 12) > +#define RTIT_CTL_BRANCH_EN (_AC(1, ULL) << 13) > +#define RTIT_CTL_MTC_FREQ_OFFSET 14 > +#define RTIT_CTL_MTC_FREQ (0x0fULL << RTIT_CTL_MTC_FREQ_OFFSET) This was a fair step in the right direction, but you've missed some instances (like here) wanting to use _AC(), and you've also not moved the whole block up above the legacy line. As Andrew's "x86/msr: Disallow access to Processor Trace MSRs" is likely to go in before 4.14 in some form, you'll want to re-base over it eventually anyway. You may want to take a look there right away, to see where in the header to place your addition. If you look further up in the file you'll also notice how we try to visually separate MSR numbers from bit-within-MSR definitions. Finally I'd also like to ask that you omit all RTIT_CTL_*_OFFSET values. Only the _OFFSET-less #define-s should really be needed - see MASK_EXTR() and MASK_INSR() in case right now you're using these for some open-coded shifting ... Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 12:39:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 12:39:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnLjX-0002ow-Ck; Mon, 22 Jun 2020 12:39:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnLjV-0002or-RD for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 12:39:29 +0000 X-Inumbo-ID: 690cdffd-b485-11ea-be86-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 690cdffd-b485-11ea-be86-12813bfff9fa; Mon, 22 Jun 2020 12:39:28 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: OVk8geFmR6xtVi3u5EUW/YEMvHM4My/nqALXbeX7+H+Ue9g98FP3POgm3gds5sjABmMjp4iDoB hMIaWM3whag9L+/MKtfiHjF+5xIxf3+7NbnZwLSO5rxDUCNBmKVNQLp6ouexCpJsQ3ezcv3CAG 8Zeurgx1Fr7nCzSDpf8gUzMCCG7OrlrDfdf1Ht/F73Hi/PAnnoLxqLRM/dBpUODVls4aAhDw4X FxeVgb4UO+rPjwxAFn/FoWiYLYQRSCQZ+F6KckE5uLuongOFVzpFoZKp0/ORenImiBSx3qdW7H jaU= X-SBRS: 2.7 X-MesageID: 20622817 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,266,1589256000"; d="scan'208";a="20622817" Subject: Re: [PATCH] x86/CPUID: fill all fields in x86_cpuid_policy_fill_native() To: Jan Beulich , "xen-devel@lists.xenproject.org" References: <41177396-9944-0bbd-66d2-8b4f2bd063f0@suse.com> From: Andrew Cooper Message-ID: Date: Mon, 22 Jun 2020 13:39:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <41177396-9944-0bbd-66d2-8b4f2bd063f0@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22/06/2020 13:09, Jan Beulich wrote: > Coverity validly complains that the new call from > tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves > two fields uninitialized, yet they get then consumed by > x86_cpuid_copy_to_buffer(). (All other present callers of the function > pass a pointer to a static - and hence initialized - buffer.) > > Coverity-ID: 1464809 > Fixes: c22ced93e167 ("tests/cpu-policy: Confirm that CPUID serialisation is sorted") > Signed-off-by: Jan Beulich > > --- a/xen/lib/x86/cpuid.c > +++ b/xen/lib/x86/cpuid.c > @@ -176,6 +176,10 @@ void x86_cpuid_policy_fill_native(struct > ARRAY_SIZE(p->extd.raw) - 1); ++i ) > cpuid_leaf(0x80000000 + i, &p->extd.raw[i]); > > + /* Don't report leaves from possible lower level hypervisor. */ ", for now." This will change in the future. With this, Reviewed-by: Andrew Cooper > + p->hv_limit = 0; > + p->hv2_limit = 0; > + > x86_cpuid_policy_recalc_synth(p); > } > From xen-devel-bounces@lists.xenproject.org Mon Jun 22 12:40:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 12:40:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnLkn-0003Y1-Nr; Mon, 22 Jun 2020 12:40:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnLkm-0003Xv-92 for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 12:40:48 +0000 X-Inumbo-ID: 98374ae2-b485-11ea-bca7-bc764e2007e4 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (unknown [40.107.14.88]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 98374ae2-b485-11ea-bca7-bc764e2007e4; Mon, 22 Jun 2020 12:40:47 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AaXf7hNxjE/AdURDa2FUMOdCT4Sn5FBsLjSRQEFDwQ7SYeawh0ByX/nWAp/34vYg4eVITDJLtQxjlQtJo46oYdUGXfXVZZseWN5QCFaUCZWllJ/op4AQ7axyXGSgBnkUIBn/FHAXB6d3qhvIgDOL9Q075qqx7g1EUaWCXW6YZyrYP9SRS1VhOz2ALCPNpJdIs09jPqV3MzDHYrRNst11WtnSIEmgKUZZ+QKHrJjYBCN4k0DG7l3BEncW4D8afGgL7/9k4S7rxvGQboF0ti+0cUWWZi5WqEY6gszLMVcRPulsYLGSN7wBVtK1iQSgx/iHHHf6ABbyEwgweoeeJ1Pw2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3n9+xLmlyddooYjRjmoM4rOUfnxJtGQuUXHMaDgnOBg=; b=mHW67qXbr6vcmJbIaByt4SzQ4s9S9vW+avyIR3irvjbsUAM1rzR7kQX1ggJOy6uiZhcX3VLZL/x14TvhDz9OYnRyaRJdhW30A8NrDfOp5AtKOgzOrW3UqXp/nBEucbnm4cHhNa/E1O2CVLeQazbsL2g66q3cxeUlAtJK7T7wzG9KhTQpbSX8Hkm6lYEUAZN6nIn/3jb6cr9cPWpRp5jN/adOYx4dr+koI9Hx+Xz42lbHDJs12YT0RRZvv/WfbCK6U+7BZuf8yFUOcpYPSKrIio1ZDbCscrzAktXuyEfzTsZw1rJA1t2EmPsPQVk/j/lBuvrtPzamLWSc4p51SEskVw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3n9+xLmlyddooYjRjmoM4rOUfnxJtGQuUXHMaDgnOBg=; b=CdPoA+997DbYwqpHZ5QJBcYDkBvbxBOIWlhAPx33H4jDM+FUMI3JgwPLl/1IQ41DftdRk2tiFh88HeDXRp5WUixg3/6tAdBPFY5qrdJhy1cXyfXJV9TPu0IMA6H0jGq7NNWydAFGfjto0aRAmf08wHIwtW+gDRB34s9kvfnpM1EdNsH0QM2DOHRNqY+kfdccGBFQK7zI4UBQ9jAS/KUraUwu9IMvZG79Q0aSMdHwVBxWlJ3X2icp0GahPZ6AOENQffIh77cbxp+52df99VLy8mr5p67uK0hWANY1Z25YRBLWnKId7Wx/sar2PpjsGYkkT3cgVMI7X4oHVGXtZgh7XQ== Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB5583.eurprd04.prod.outlook.com (2603:10a6:803:d4::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Mon, 22 Jun 2020 12:40:45 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 12:40:45 +0000 Subject: Re: [PATCH v2 3/7] x86/vmx: add IPT cpu feature To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <626789888.9820937.1592523621821.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <3e197deb-325f-81fd-7464-900f4fad29ad@suse.com> Date: Mon, 22 Jun 2020 14:40:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <626789888.9820937.1592523621821.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM0PR02CA0024.eurprd02.prod.outlook.com (2603:10a6:208:3e::37) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM0PR02CA0024.eurprd02.prod.outlook.com (2603:10a6:208:3e::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Mon, 22 Jun 2020 12:40:44 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 667747a1-8833-4dd6-138c-08d816a97b83 X-MS-TrafficTypeDiagnostic: VI1PR04MB5583: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KccFh+u3EEUJLnNRn2E4xIOO7Qkpvd4IQ4I/uuX/2q89Ycs6aYNJeaheUblqWw4RNXObLyOnmHBglS7lt4WzOroba3h+X/ibOjfw6V+dmUtecxa0eNFeCCOvUZfAwcoq/RwCyL1RxHCtEQ296k64oLBXi/5iakSocwyBQhC7MxYPvMBqsSnX0OEy1i11NOcHO8x8CL+ws/Ph1FOD68U9iIrGVJ7uUQ9iwen6cnpD+VA4rFF8fFEznLyWRhc0sIwO2tqMyzlBxiJiXi+Te/ANABVz6IlkgDZVi47Fd82NsDV3cgzJaSx7jM3wedI9u1qE+LtvVhJo7qseNgpH1NOWc9lXMGohS/DgkXqyoj4AMOC/ugneCQh94ggwTLVHnyPI X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(39860400002)(346002)(136003)(366004)(396003)(4744005)(86362001)(8676002)(5660300002)(16526019)(66556008)(66476007)(66946007)(8936002)(26005)(186003)(36756003)(2906002)(66574015)(31686004)(4326008)(31696002)(52116002)(478600001)(54906003)(16576012)(6666004)(53546011)(316002)(956004)(6916009)(2616005)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: WDtR9pGHuzy17tnsPp36nQCO892cNQL59pimFeB4ZPvlb4VclA4NlVy6gkDxnktvl+BK3hYYmH6NezEI1WDO99NOI8xL9Ag8/m/VtkpzUgxsuVjbie0on5jTThHBfapX1KiZJrJO6RDvEw4/p1a/ezO51acQaIXKIrth6BxuXSP7KljWcuXgZemgHjyYXMd32xfP54LlYq7Y5ffzLT6c4BTZKlL++TvZVw506tD+lnDh7IyMqKiCu0x8LLo0Q7tgsIEVtMNZ8qWKGKHxVyde6kfejq2mmMZH0kYuPh5ruETNsVEyBiGBqull+MOcFcgx9LVWITJHYX/y+a0RfeRLISfQGnGRCrlb2jZKeTbHZbFtU5vffBO+VGjVnPJD8/XEQaGP2z9c/ABwcXaGLSiCJzjmNkphRnkw/tOSlCF9vPk+gSpFfYXf2hXGEfx3m4FlFMRh02wXB/KIIA4y65aE5CZux8l5KJLaXoqs7n2mUDs= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 667747a1-8833-4dd6-138c-08d816a97b83 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 12:40:45.1177 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: YMqUAmxdZBiaOdr1jMVTKdCiGFfyKjnbx9VA6eJ8ySkAXzSRB6Wlo0nyBsCqrulXQaptxYeTTuLksy2hQZD19Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5583 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , "Kang, Luwei" , Wei Liu , Andrew Cooper , Jun Nakajima , Tamas K Lengyel , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 01:40, Michał Leszczyński wrote: > @@ -630,6 +633,12 @@ static inline bool hvm_altp2m_supported(void) > return hvm_funcs.altp2m_supported; > } > > +/* returns true if hardware supports Intel Processor Trace */ > +static inline bool hvm_pt_supported(void) > +{ > + return hvm_funcs.pt_supported; > +} This is vendor-independent code, hence I'd like to see "Intel" dropped from the comment. > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h > @@ -285,6 +285,7 @@ extern u64 vmx_ept_vpid_cap; > > #define VMX_MISC_CR3_TARGET 0x01ff0000 > #define VMX_MISC_VMWRITE_ALL 0x20000000 > +#define VMX_MISC_PT_SUPPORTED 0x00004000 Move this up by two lines, so the values continue to be numerically sorted? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 13:19:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 13:19:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMLX-0006QM-Kk; Mon, 22 Jun 2020 13:18:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMLV-0006QH-Qj for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 13:18:45 +0000 X-Inumbo-ID: e57ebe84-b48a-11ea-be8f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e57ebe84-b48a-11ea-be8f-12813bfff9fa; Mon, 22 Jun 2020 13:18:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AMa/70ObHhI30ZVz2Xn3ZWW/uyAL9Ol1xp3yQJPOYT8=; b=JTSdX5ktrwjVXnPEEBm/f5unA aX9ZfGA+APCmPoH9KOFetH8BOvAOL4ID5La7NdZGwqG4suZZHZJ62vxnvbLElncALJopKgXxsdPOT wAwepOK9TE6bEo4TAtslLqYe3UO+31T8fol0E8f3b/MlTpLE/MGlTTJT9ZBFskAQjd8MA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMLT-0007EQ-Dh; Mon, 22 Jun 2020 13:18:43 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnMLT-00018G-4c; Mon, 22 Jun 2020 13:18:43 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnMLT-00016K-3v; Mon, 22 Jun 2020 13:18:43 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151276: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=06760c2bf322cef4622b56bafee74fe93ae01630 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Mon, 22 Jun 2020 13:18:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151276 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151276/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 06760c2bf322cef4622b56bafee74fe93ae01630 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 39 days Failing since 150943 2020-06-09 17:06:00 Z 12 days 11 attempts Testing same since 151161 2020-06-15 22:27:38 Z 6 days 5 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 06760c2bf322cef4622b56bafee74fe93ae01630 Author: Andrew Cooper Date: Fri Jun 12 18:32:27 2020 +0100 tools/libxl: Fix memory leak in libxl_cpuid_set() xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to free() seeing as it discards the results. This is logically a backport of c/s b91825f628 "tools/libxc: Drop config_transformed parameter from xc_cpuid_set()" but rewritten as one caller of xc_cpuid_set() does use returned values. Signed-off-by: Andrew Cooper (cherry picked from commit c54de7d9df7718ea53bf21e1ff5bbd339602a704) commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Jun 22 13:24:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 13:24:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMQu-0007Fo-DR; Mon, 22 Jun 2020 13:24:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMQt-0007Fj-BA for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 13:24:19 +0000 X-Inumbo-ID: ac4d037c-b48b-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ac4d037c-b48b-11ea-bca7-bc764e2007e4; Mon, 22 Jun 2020 13:24:17 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 72JLREy5tlnWQy2N//vIJ+8DWcwz/J3H3u0UlwN6DNyt08rAowWiXLXf8VohKcriNiYVrPQqt0 0qRpFHSLhgsOUL6YRvx9VQMKbvjskcn8iSlaYqzmw0YhL5qxa/+EDvHUOrsUNS3+WyZnAozU0d mw701/nAkFWDcTDw3WiV114Qnv9dj7fTOM2dCtdbRCS7ZJhcd1laVFrF0lvr1bUyX/Q3rW4Ipg t9gs7Qvf0O7oGnlFwPjX/d0TElTwOKqAl7djGt1kt1ZruKiukcrYuDWz/R8X9zZtFqJ0TNyGaB NL0= X-SBRS: 2.7 X-MesageID: 20964307 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,266,1589256000"; d="scan'208";a="20964307" Date: Mon, 22 Jun 2020 15:24:10 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage Message-ID: <20200622132410.GJ735@Air-de-Roger> References: <20200618160403.35199-1-roger.pau@citrix.com> <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> <20200622093123.GI735@Air-de-Roger> <5ad66ef4-9406-f35a-5683-ac4608242dd7@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5ad66ef4-9406-f35a-5683-ac4608242dd7@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote: > On 22.06.2020 11:31, Roger Pau Monné wrote: > > On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote: > >> On 18.06.2020 18:04, Roger Pau Monne wrote: > >>> Commit e9aca9470ed86 introduced a regression when avoiding sending > >>> IPIs for certain flush operations. Xen page fault handler > >>> (spurious_page_fault) relies on blocking interrupts in order to > >>> prevent handling TLB flush IPIs and thus preventing other CPUs from > >>> removing page tables pages. Switching to assisted flushing avoided such > >>> IPIs, and thus can result in pages belonging to the page tables being > >>> removed (and possibly re-used) while __page_fault_type is being > >>> executed. > >>> > >>> Force some of the TLB flushes to use IPIs, thus avoiding the assisted > >>> TLB flush. Those selected flushes are the page type change (when > >>> switching from a page table type to a different one, ie: a page that > >>> has been removed as a page table) and page allocation. This sadly has > >>> a negative performance impact on the pvshim, as less assisted flushes > >>> can be used. > >>> > >>> Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush > >>> using an IPI (flush_tlb_mask_sync). Note that the flag is only > >>> meaningfully defined when the hypervisor supports PV mode, as > >>> otherwise translated domains are in charge of their page tables and > >>> won't share page tables with Xen, thus not influencing the result of > >>> page walks performed by the spurious fault handler. > >> > >> Is this true for shadow mode? If a page shadowing a guest one was > >> given back quickly enough to the allocator and then re-used, I think > >> the same situation could in principle arise. > > > > Hm, I think it's not applicable to HVM shadow mode at least, because > > CR3 is switched as part of vmentry/vmexit, and the page tables are not > > shared between Xen and the guest, so there's no way for a HVM shadow > > guest to modify the page-tables while Xen is walking them in > > spurious_page_fault (note spurious_page_fault is only called when the > > fault happens in non-guest context). > > I'm afraid I disagree, because of shadow's use of "linear page tables". You will have to bear with me, but I don't follow. Could you provide some pointers at how/where the shadow (I assume guest controlled) "linear page tables" are used while in Xen context? do_page_fault will only call spurious_page_fault (and thus attempt a page walk) when the fault happens in non-guest context, yet on HVM all accesses to guest memory are performed using __hvm_copy which doesn't load any guest page tables into CR3, but instead performs a software walk of the paging structures in order to find and map the destination address into the hypervisor page tables and perform the read or copy. > >>> Note the flag is not defined on Arm, and the introduced helper is just > >>> a dummy alias to the existing flush_tlb_mask. > >>> > >>> Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') > >>> Reported-by: Andrew Cooper > >>> Signed-off-by: Roger Pau Monné > >>> --- > >>> It's my understanding that not doing such IPI flushes could lead to > >>> the pages tables being read by __page_fault_type being modified by a > >>> third party, which could make them point to other mfns out of the > >>> scope of the guest allowed physical memory addresses. However those > >>> accesses would be limited to __page_fault_type, and hence the main > >>> worry would be that a guest could make it point to read from a > >>> physical memory region that has side effects? > >> > >> I don't think so, no - the memory could be changed such that the > >> PTEs are invalid altogether (like having reserved bits set). Consider > >> for example the case of reading an MFN out of such a PTE that's larger > >> than the physical address width supported by the CPU. Afaict > >> map_domain_page() will happily install a respective page table entry, > >> but we'd get a reserved-bit #PF upon reading from that mapping. > > > > So there are no hazards from executing __page_fault_type against a > > page-table that could be modified by a user? > > There are - I realize only now that the way I started my earlier > reply was ambiguous. I meant to negate your "only with side effects" > way of thinking. Ack. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 13:25:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 13:25:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMRp-0007Jz-NP; Mon, 22 Jun 2020 13:25:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMRo-0007Ju-NM for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 13:25:16 +0000 X-Inumbo-ID: ce6c9710-b48b-11ea-be8f-12813bfff9fa Received: from EUR01-VE1-obe.outbound.protection.outlook.com (unknown [40.107.14.40]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ce6c9710-b48b-11ea-be8f-12813bfff9fa; Mon, 22 Jun 2020 13:25:15 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WXzTW0ZXn/0xE2NDPpQaIKFMCxWlIv2mwzj/NUzOBpuhWlhUSadhDoSoSn5zYeZXRa1CafYkGejwd1ZwqECcJc/cZwbsn3x1nvmsaYQEgU8otmhxWZfvOWk8lF8zwpSmDycgpuXm1zw0QoVD7ogslkPs5QHruJt21LMlbaytZI4x3+7C39WAl65iJl7pBkGm3H6lV1/46xH+ZlUjfrHavgEDTRx5X7IPIhbkMdfL0luBjpOzI8fTB6Uz3fFosgaGB+nVmO3edKUz5hPLuF+yvwIzpLIKtUTzcfT0ZUN0MZUUtjIIyKTj01mclocy5DA09I57eekfUYbRxGPLWwggcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h/3qiXh/KRx32LrOeslzu7ZsTcQLk4cSzuTZWmdNvO4=; b=Nx7Ky2UR/tkzPsc4dmXkv309cFP19gMTym3rdcLTXls+8zZmgJmMep5UuYeQMZ6xg3aCg6T62VX43p5rB1qSpGB3K+hyVjcjm8w+RiJOoR4HocbtYvk1TIkFBg5EpjSV2aTQy8e4AYyvUDnilgoQJHjBkrs2wimlsBe8yshbxNZhkibUd/zMCSW5Ogsr16gaoOMCRbvT7Q0sCUiX+a0ymdw23e1hqFnwFsKYCSmu5F3puDHK+Imenf7qRjN5qioVPsbbSGkjYkhlKkpmWr1+IoBBiFN4LFpUCVlWtA2t+SOJ0UNzwoF9bhW/cK5w0t5V1GxItY8hqyDsAZncneAWtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h/3qiXh/KRx32LrOeslzu7ZsTcQLk4cSzuTZWmdNvO4=; b=Lv/mZzYcRZVReji8eHPRcCE0cPr7N7+AaPhcQKvEfRDrDLJnSw+z3Tlgxhg1WW/1369qMIxp6jIYhB+tOZs/tOhpioytaP7w5zX73NQxWJ/b+e8ZX84w8cAAK+8rq2+lYU0P6JWzI1qWpUEcTg4lShMWn/1Yu5L9TxurR4Nk16vOFI3sM08pM3dCGnQBpHI5QR909c848kuhjeW647U65E8bsWUbYO1fSf3vPjtsLVGaR6oDB5V/56WGC6Dqp6v9tJOMN335VjnXav71vgctlMt2olSL18MNU3nJQrC9nUAYPNwUfS09wL+zfNKiX15eq3JjQoDSpCmoSxH14YBxQw== Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB5421.eurprd04.prod.outlook.com (2603:10a6:803:d5::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Mon, 22 Jun 2020 13:25:13 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 13:25:13 +0000 Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> Date: Mon, 22 Jun 2020 15:25:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM3PR05CA0124.eurprd05.prod.outlook.com (2603:10a6:207:2::26) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM3PR05CA0124.eurprd05.prod.outlook.com (2603:10a6:207:2::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Mon, 22 Jun 2020 13:25:12 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: adfe08e7-065c-42c3-6a60-08d816afb1e3 X-MS-TrafficTypeDiagnostic: VI1PR04MB5421: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MLZynMEBLRNihZzKpzp8MYIfHXe6FuZCuvX4E3FMyrf/oXvAqMtoYWBPOM0xmZT4EQvCyKUZQ0Vra0QUfr/MZZ5xMesYGtQmXs3hTQe2alYqZUNFXaMT5uFiR4EyZEuKilNRKNlmK2yMHeKK4jNfuNzZhunKAdOIV32rELnQMAzp3kcoqhfb5LBzJUraR8Y9UZ98FUZ8e/YbHCR0M7E0BW3aWJKPUotQ15Ydvd6DOomE5TIA8aSGG7i5p5VIz9BUqtoxs7umR5E4Jq2cEyhBzkDOmLfHtwBBbUdgZRw7Oz7yBAVUD20E6ieLa90pgW9M2cajGzBj8APt7rG1EwgoOcGJSQt51ssqKTUuqBiBqivhupgG1qh1H1ZTD2agQV/T X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(396003)(346002)(366004)(39860400002)(376002)(7416002)(5660300002)(6666004)(6486002)(16576012)(6916009)(316002)(8936002)(956004)(8676002)(2616005)(66574015)(66556008)(66476007)(66946007)(186003)(53546011)(31686004)(54906003)(16526019)(52116002)(26005)(2906002)(36756003)(86362001)(478600001)(4326008)(83380400001)(31696002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: xQuexSc+MAH+doJ4yTKngv8bnSjdEBHOWA9yJAzLZVFr6hEpRfapL2RP1HgIurQMz4gRqbu8GlL+31mLhJixVWSyZB1j8WJAh3i5nI73nJaVsQs47fKo18chfdyxdhzXpsLB4wNXUo3ksSAl1snmP+c3/LdgRXzqpTHyma0jHCH5ki/iRIzhpH0wPRNvyD+8JljC0G/f5S4XLc6xS+LsOFV/HR02stHhwfMWxBAs0O5MxBJIvq8osASIZKdnEXfDs5EH0WZaCl2+D5219X+ZbNjd/KroHc4YB3cs+uvRbaGHQo3k+LtRYQYt2b+kzY/LkKYYBeKpHh+Ru8r/SpUN75ttwFtmmOPM2BIb/n+N4aWqHtTUj0TyEWzRABwP8xsrN3hKmkWT17NqCUN2EQFprX68QvmwMDkARXUB9prxk2KUUXRKA6Uds8IDESEjtMqxKCyCKNck2sUbeutcP9tK4RPRRqCFVRHaK/5n2cdDrjU= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: adfe08e7-065c-42c3-6a60-08d816afb1e3 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 13:25:13.3853 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EdqMKHyD+oFkXcm/aQv1u9VVsn2aGf3zqh178vsqNafLMPDtHssBLCox7vCgyCpDnuPh8pBBbKuQKuZDWqLxng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5421 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19.06.2020 01:41, Michał Leszczyński wrote: > @@ -1631,6 +1649,8 @@ void hvm_vcpu_destroy(struct vcpu *v) > vlapic_destroy(v); > > hvm_vcpu_cacheattr_destroy(v); > + > + hvm_vmtrace_destroy(v); > } Whenever possible resource cleanup should occur from hvm_domain_relinquish_resources(). Is there anything preventing this here? > @@ -4066,6 +4086,51 @@ static int hvmop_set_evtchn_upcall_vector( > return 0; > } > > +static int hvm_set_vmtrace_pt_size(struct domain *d, uint64_t value) > +{ > + void *buf; > + unsigned int buf_order; > + struct page_info *pg; > + struct ipt_state *ipt; > + struct vcpu *v; > + > + if ( value < PAGE_SIZE || > + value > GB(4) || > + ( value & (value - 1) ) ) { > + /* we don't accept trace buffer size smaller than single page > + * and the upper bound is defined as 4GB in the specification */ > + return -EINVAL; > + } > + > + for_each_vcpu ( d, v ) > + { > + buf_order = get_order_from_bytes(value); > + pg = alloc_domheap_pages(d, buf_order, MEMF_no_refcount); > + > + if ( !pg ) > + return -EFAULT; > + > + buf = page_to_virt(pg); In addition to what Roger has said here, just fyi that you can't use page_to_virt() on anything returned from alloc_domheap_pages(), unless you suitably restrict the address range such that the result is guaranteed to have a direct mapping. > @@ -4949,6 +5018,100 @@ static int compat_altp2m_op( > return rc; > } > > +static int do_vmtrace_op(XEN_GUEST_HANDLE_PARAM(void) arg) > +{ > + struct xen_hvm_vmtrace_op a; > + struct domain *d; > + int rc; > + struct vcpu *v; > + struct ipt_state *ipt; > + > + if ( !hvm_pt_supported() ) > + return -EOPNOTSUPP; > + > + if ( copy_from_guest(&a, arg, 1) ) > + return -EFAULT; > + > + if ( a.version != HVMOP_VMTRACE_INTERFACE_VERSION ) > + return -EINVAL; > + > + d = rcu_lock_domain_by_any_id(a.domain); > + spin_lock(&d->vmtrace_lock); > + > + if ( d == NULL ) > + return -ESRCH; > + > + if ( !is_hvm_domain(d) ) > + { > + rc = -EOPNOTSUPP; > + goto out; > + } > + > + domain_pause(d); Who's the intended caller of this interface? You making it a hvm-op suggests the guest may itself call this. But of course a guest can't pause itself. If this is supposed to be a tools-only interface, then you should frame it suitably in the public header and of course you need to enforce this here (which would e.g. mean you shouldn't use rcu_lock_domain_by_any_id()). Also please take a look at hvm/ioreq.c, which makes quite a bit of use of domain_pause(). In particular I think you want to acquire the lock only after having paused the domain. > + if ( a.vcpu >= d->max_vcpus ) > + { > + rc = -EINVAL; > + goto out; > + } > + > + v = d->vcpu[a.vcpu]; > + ipt = v->arch.hvm.vmx.ipt_state; > + > + if ( !ipt ) > + { > + /* > + * PT must be first initialized upon domain creation. > + */ > + rc = -EINVAL; > + goto out; > + } > + > + switch ( a.cmd ) > + { > + case HVMOP_vmtrace_ipt_enable: > + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, > + RTIT_CTL_TRACEEN | RTIT_CTL_OS | > + RTIT_CTL_USR | RTIT_CTL_BRANCH_EN) ) > + { > + rc = -EFAULT; > + goto out; > + } > + > + ipt->active = 1; > + break; > + case HVMOP_vmtrace_ipt_disable: > + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, 0) ) Shouldn't you rather remove the MSR from the load list here? Is any of what you do in this switch() actually legitimate without hvm_set_vmtrace_pt_size() having got called for the guest? From remarks elsewhere I imply you expect the param that you currently use to be set upon domain creation time, but at the very least the potentially big buffer should imo not get allocated up front, but only when tracing is to actually be enabled. Also please have blank lines between individual case blocks. > + { > + rc = -EFAULT; > + goto out; > + } > + > + ipt->active = 0; > + break; > + case HVMOP_vmtrace_ipt_get_offset: > + a.offset = ipt->output_mask.offset; > + break; > + default: > + rc = -EOPNOTSUPP; > + goto out; > + } > + > + rc = -EFAULT; > + if ( __copy_to_guest(arg, &a, 1) ) > + goto out; Only HVMOP_vmtrace_ipt_get_offset needs this - please avoid copying back on other paths. Even there you could in principle copy back just the one field; the function taking XEN_GUEST_HANDLE_PARAM(void) gets in the way of this, though. The last line above also has an indentation issue, but the use of "goto" in this case can be avoided anyway. > + rc = 0; > + > + out: > + domain_unpause(d); > + spin_unlock(&d->vmtrace_lock); > + rcu_unlock_domain(d); > + > + return rc; > +} > + > +DEFINE_XEN_GUEST_HANDLE(compat_hvm_vmtrace_op_t); I don't see any use of this handle further down - why do you force it being declared? > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -4624,6 +4624,43 @@ int arch_acquire_resource(struct domain *d, unsigned int type, > } > break; > } > + > + case XENMEM_resource_vmtrace_buf: > + { > + mfn_t mfn; > + unsigned int i; > + struct ipt_state *ipt; > + > + if ( id >= d->max_vcpus ) > + { > + rc = -EINVAL; > + break; > + } > + > + ipt = d->vcpu[id]->arch.hvm.vmx.ipt_state; Please use domain_vcpu() here. > + if ( !ipt ) > + { > + rc = -EINVAL; > + break; > + } > + > + mfn = mfn_x(ipt->output_base >> PAGE_SHIFT); maddr_to_mfn()? > + if (nr_frames > ( ( ipt->output_mask.size + 1 ) >> PAGE_SHIFT )) > + { > + rc = -EINVAL; > + break; > + } > + > + rc = 0; > + for ( i = 0; i < nr_frames; i++ ) > + { > + mfn_list[i] = mfn_add(mfn, i); > + } Please omit the braces in cases like this one. > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h > @@ -104,6 +104,19 @@ struct pi_blocking_vcpu { > spinlock_t *lock; > }; > > +struct ipt_state { > + uint64_t active; > + uint64_t status; > + uint64_t output_base; > + union { > + uint64_t raw; > + struct { > + uint32_t size; > + uint32_t offset; > + }; > + } output_mask; > +}; While referenced ... > struct vmx_vcpu { > /* Physical address of VMCS. */ > paddr_t vmcs_pa; > @@ -186,6 +199,9 @@ struct vmx_vcpu { > * pCPU and wakeup the related vCPU. > */ > struct pi_blocking_vcpu pi_blocking; > + > + /* State of Intel Processor Trace feature */ > + struct ipt_state *ipt_state; ... here, the struct declaration itself doesn't really belong in this header, as not being VMCS-related. The better place likely is vmx.h. > --- a/xen/include/public/hvm/hvm_op.h > +++ b/xen/include/public/hvm/hvm_op.h > @@ -382,6 +382,29 @@ struct xen_hvm_altp2m_op { > typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; > DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); > > +/* HVMOP_vmtrace: Perform VM tracing related operation */ > +#define HVMOP_vmtrace 26 > + > +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 I'm unconvinced we want to introduce yet another versioned interface. In any event, as hinted at earlier, this suggests it wants to be a tools-only interface instead (which, at least for the time being, is not required to be a stable interface then, but that's also something we apparently want to move away from, and hence you may better not try to rely on it not needing to be stable). > +struct xen_hvm_vmtrace_op { > + /* IN variable */ > + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ > + uint32_t cmd; > +/* Enable/disable external vmtrace for given domain */ > +#define HVMOP_vmtrace_ipt_enable 1 > +#define HVMOP_vmtrace_ipt_disable 2 > +#define HVMOP_vmtrace_ipt_get_offset 3 > + domid_t domain; > + uint32_t vcpu; > + uint64_t size; > + > + /* OUT variable */ > + uint64_t offset; If this is to be a tools-only interface, please use uint64_aligned_t. You also want to add an entry to xen/include/xlat.lst and use the resulting macro to prove that the struct layout is the same for native and compat callers. > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -457,6 +457,9 @@ struct domain > unsigned pbuf_idx; > spinlock_t pbuf_lock; > > + /* Used by vmtrace domctls */ > + spinlock_t vmtrace_lock; There's no domctl invovled here anymore, I think. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 13:37:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 13:37:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMdR-0008Pa-Rl; Mon, 22 Jun 2020 13:37:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMdQ-0008PV-Me for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 13:37:16 +0000 X-Inumbo-ID: 7c0f1d38-b48d-11ea-8496-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.73]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7c0f1d38-b48d-11ea-8496-bc764e2007e4; Mon, 22 Jun 2020 13:37:15 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=luoqD8AUmefMtjd1uCfObt8rOR8iOYE1AdTTaRgrF0EyJpBteLvoWm3/QqbNbK75ahkLOXfZrLF4dX20+03sWYiPlQv0CWgvhpPhK3imaoBOg9Q2MZV4IZAcjoJ6TUmbOT6EGYMaUSaj9hrsw3XyFCfkOuzzh+a/XhiyMMd13XA9QFdDfQWScorhvaUJeFOxankM2UgISref1lfORoXn3+Wof5ghI5Q9xiXvQNYKV0WQ5U70LdrXLJf3ApoJFr7W8biWvztlYTtTVCrsHXtaDH+yZNc/0nNuozNJmKKs6ls92Qe9p/4VBBgzxZeXf08NUcArfCW+yAHfjYQclkRdGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m/XzEBPQQXzXR08MRCb0HnUC8pEe4WsH9GVfgMfzLyg=; b=LIbNbh9jkrDW15nalNhKHGFHmBBqhTRY7yd4/5P3Ixvwnj79WRmIExW8uVS28S78SGgq5LS9CHHLB3k/PFxQbj3B067tq/omj61CNM2ndwXc+K3fwaCREZp9WCYtlcP1No5Ex5qLLhNTYiuWYhp9EuACpCmxmupCiAjs146KuB3EmREP3aOSIwZ4Js/7Mbzci+P8KiE9Lp6xU8fuBiAXZgtyn5wxZbGnqN6kLl6LpYLKwQNXzs7I7L+IILzmmk+jl5wPKMSlzeoz/S3mucP4/B8jxdcv/D4HPhDn8cruIaZmt/ZHEO2iMabtIwOMu4uMu4oTK/26V34cCWO0uwwjTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m/XzEBPQQXzXR08MRCb0HnUC8pEe4WsH9GVfgMfzLyg=; b=jK0VaHuuROzgjCLf8HTZA7z2/RMnu6AV/6i9oyI5TNqYyjDRo5oWXg1S1Xcetreds/gSCQp3p5OdDswIqDRMfA8ZnOW3BCNfKanmFIucK2bP7sOVRwAnLQ4cjBywIroYqguH3LvLGIRxoPll0qx46KhcYIDOmYlzKomtwWzCxXS30IlclXjcissempzNtefConUbicIrwVFiX3ycFRq+4M7fMJ74cX5PE9nP9HHQ7FOo8CBDpKQyK4VN2Xr77RVUYTiQc7sOXUR7b+jDKK3oTJLBqoqPAo/JPIhxte3XbdpB+Chme3sn37gwcFJlueEtv3ZhK+g5ddhYqIN2qzP+iQ== Authentication-Results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB4815.eurprd04.prod.outlook.com (2603:10a6:803:5d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Mon, 22 Jun 2020 13:37:14 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 13:37:14 +0000 Subject: Re: [PATCH] x86/CPUID: fill all fields in x86_cpuid_policy_fill_native() To: Andrew Cooper References: <41177396-9944-0bbd-66d2-8b4f2bd063f0@suse.com> From: Jan Beulich Message-ID: Date: Mon, 22 Jun 2020 15:37:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: AM4PR0101CA0052.eurprd01.prod.exchangelabs.com (2603:10a6:200:41::20) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM4PR0101CA0052.eurprd01.prod.exchangelabs.com (2603:10a6:200:41::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Mon, 22 Jun 2020 13:37:13 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4333c71e-a0a5-4146-e22a-08d816b15f84 X-MS-TrafficTypeDiagnostic: VI1PR04MB4815: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: CzTL+qleB5I3n0lpDmCfJtURlYQ0ZAtbDQa0rkSu9/eMU0LNCvGlSwsxAciBf+pEmxq06YcmAYwmQQHOkTlO0H9Dg9nvK3cB86QX+79X0X918vFq/HIDrsxs6yQtq+5/fpX31XIvNu23a5z7Xvh96spYpQXkjTMToWoI8LcpQG+5IZS+xpo3H8GO1VKY8yAoFYuW1fJ/nhg73jcUSq/fXTmzv1P8BRhsBQj7EEDVk5GPBIV1tL1HmDtHq0gbxwGZhanEgifErNkRLsBWOutNM6pvJwkDQyn3t1pc86aM+/XCviuM9lMUg5GJj2b0nmaxFarED5Ey7wFiX5pHhl3LPX3Syu/NKllKR/l/Ebd0Sc7vJ1AtG3SuzmphRw2o9/x8 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(376002)(396003)(366004)(346002)(136003)(36756003)(16576012)(54906003)(316002)(6916009)(8936002)(8676002)(956004)(2616005)(478600001)(6486002)(16526019)(2906002)(66556008)(66476007)(66946007)(186003)(53546011)(26005)(31696002)(83380400001)(5660300002)(86362001)(6666004)(4326008)(31686004)(52116002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: QVQE/3a2AlpkguwxC7U4NEkZaG9ajniF2qxkphJJCe9lPgSHmP0gHh19Sj5zdvlLoVOQC58NDWH7D+rEd8pA7HGvsjjAhh34CUZMT0hdM0lJ7x9LVocBFwsmST75pRqRF6QN8Oso5FFsC3VG8Vh6xXfPIjO+oJxI/3r6PtvQPCwDGVr605hgsNSwx9VsBSHwIe+iyO6qagAW1E8RCIuVfBV8FCmQEuG3KKQem+fGXCa0yYaYHq7fnMTxROZ9jBAp1wn36tWFUWOfC/v/ASHFRE4nK3G1e/3C6O17zurHU4mcxWoxgoEEvkl+EHzK7DUpP+X9bS+BSaOgFDAC6cd5TSjERoXzuxWz8jZyg8MI9KX88eUwgiCVOYvF6up4ByfTvuwGb9zLCVdCC0vGXwWwAzBU5a8vHxoqO0uNqcPJCZ9Ej7UC64o94tuzUAzScagTEmcKYWsRpS4fVJiffBdakcPlSHOLTgMRooyk/YchJwY= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4333c71e-a0a5-4146-e22a-08d816b15f84 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 13:37:14.1970 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QEpqwubYWGOXUK0F/5sXkiZsg2C29xAv3K2xAQryUgrd2DMYoImfGh3JwCukuaAypB7MmjD9m12O9fn63DIv3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4815 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 14:39, Andrew Cooper wrote: > On 22/06/2020 13:09, Jan Beulich wrote: >> Coverity validly complains that the new call from >> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves >> two fields uninitialized, yet they get then consumed by >> x86_cpuid_copy_to_buffer(). (All other present callers of the function >> pass a pointer to a static - and hence initialized - buffer.) >> >> Coverity-ID: 1464809 >> Fixes: c22ced93e167 ("tests/cpu-policy: Confirm that CPUID serialisation is sorted") >> Signed-off-by: Jan Beulich >> >> --- a/xen/lib/x86/cpuid.c >> +++ b/xen/lib/x86/cpuid.c >> @@ -176,6 +176,10 @@ void x86_cpuid_policy_fill_native(struct >> ARRAY_SIZE(p->extd.raw) - 1); ++i ) >> cpuid_leaf(0x80000000 + i, &p->extd.raw[i]); >> >> + /* Don't report leaves from possible lower level hypervisor. */ > > ", for now." > > This will change in the future. I was pondering at that moment whether to add it, but then I didn't think we'd want to let shine through lower level hypervisor info. But yes, I've added it, because it won't be wrong to say "for now", even if it end up being for much longer. > With this, Reviewed-by: Andrew Cooper Thanks, Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 13:51:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 13:51:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMrV-0001dR-9L; Mon, 22 Jun 2020 13:51:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMrT-0001dM-1h for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 13:51:47 +0000 X-Inumbo-ID: 8268a1ca-b48f-11ea-b7bb-bc764e2007e4 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown [40.107.7.42]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8268a1ca-b48f-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 13:51:45 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SA9YtEe5CQSzAGsGhrPjEbuj1CVjLI6hfAxpJrtWLKf9B6QGNPfmWVsaOJMV00i5WqM/zzfYKD3EQfuyLabGuvjZ52bnIWuHliOON6a/VhKAXCffNU+yeI2kduxKw9ZVbUgCyeZAfuXszulf6uh/9NQuVdZTQuGMxhoBwCTevZ1oGFyIw9FO5kPww3p2ETysF4bfoGfRcXlYBUumhxZJ23BtaBJ8aiQsojKnzERN5x9YK60CLfc02kJJFPIuey33qcWuZxipfQ/EwBzBRTsUTNJNplqJoMHEPmprvW7K/6gKaQ1FbP+M32z72zS20WsY3Yu3lfNefL+ZP/gaNLusbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hujfMTMP0tIzoS1jqk05YbwQnrnj3UD8mmZHlQTgdfs=; b=gdStSaHbbzExRbbhFyOeqOnFyoe99h3gXV8mdJHBUWcHQ1swTpMX3CQAx6XUwdRf0dYeAHvPSY2gveWdcyX0uGTFj6Co/EU0x0qWM/b3rAedGVfrPOffbBLsW77Ga7cZYdhiMhDxhkCirqU+3/PZ8hMIAddVqm75dXTY18fWpLbmOtofHEwDgIv+QH5fqeGWvIpm0X8+OTTTe7MYpHMhjP6pUvDr7HsTfrdgU+C+4xrKZvEpQUyBdL1KaXUFs9aj1s4j/MqFhDMUhkPKki2FwngSijMPlRrH2+o6CdQsTWo9gNcOuuUwS6qFqsyenBRTz9ZKCTEuAL7QDhDXDwHgtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hujfMTMP0tIzoS1jqk05YbwQnrnj3UD8mmZHlQTgdfs=; b=hyAB76lKO4lVxfsJsKKccGEBwpWRl1luMB8nPwowCEYqqVeQUbE6hOk7gnOxBbAT7fda16ke8ToKpFubv3M9A1iBW+lfrlah0ARAnUHtbOMUd/A7U96DBDEL4FO7CMo68FcrQHnJD4Yn4M366FLfrX5nHFxbqZeZJQklVrL33KrEGbyuWX5mgTjT00w/GBsPN8FySgZSKh2o3CAlVQSfXGxXvrue6Xzl4Ng2b/f4dkiXyX0cP3IoBURWdoTO7GLGKxiLI3g7Z+g3XZ52tO71l/dsycwS1FtAIWEHSuUlc9fDhs+IZTZsK7usnYUbzT6c1pT2wHB4+DJcXAWQd0j6ug== Authentication-Results: epam.com; dkim=none (message not signed) header.d=none;epam.com; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB5309.eurprd04.prod.outlook.com (2603:10a6:803:59::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Mon, 22 Jun 2020 13:51:43 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 13:51:43 +0000 Subject: Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200618160403.35199-1-roger.pau@citrix.com> <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> <20200622093123.GI735@Air-de-Roger> <5ad66ef4-9406-f35a-5683-ac4608242dd7@suse.com> <20200622132410.GJ735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Mon, 22 Jun 2020 15:51:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <20200622132410.GJ735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM4PR0302CA0022.eurprd03.prod.outlook.com (2603:10a6:205:2::35) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM4PR0302CA0022.eurprd03.prod.outlook.com (2603:10a6:205:2::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Mon, 22 Jun 2020 13:51:42 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7b4e4b0e-d67c-4b82-e0c3-08d816b365a1 X-MS-TrafficTypeDiagnostic: VI1PR04MB5309: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eXYmTcn+u6r08Zxv3Of1tsX7hwGzucsT4tmraRGBmEc2iouFzhVz1RY46IGzwUtRt5m9kTl3qZmO8SrnE2iJaoPIEZA4BLjmLC4jpJ9PC7zqXOmxfqCuZEIYaJqzjLgxtsWNW5hHz3NboVr/wI9Zqh87PZ0joDE+NMdHcnm2MsgtoI7l4G6LcCxs0f40kISLxCkfdr2ykb82bq1nNCkCNseZ2G4GKPjYf5/3WkjzoBnqbqDEhK1Gynda3KBmrccvZEfGhINFuRcXyEACWj0OjbX4+B4OPPPA38YeDPQA04bZD6auZlQ+EMMXo2rFa+JF7owxdQkBo8kFgH8b1u1HBMHRuEoF5KStRSXvoMp/FCzZoT9HB5hpcBtdto63wdMa X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(346002)(396003)(136003)(39860400002)(366004)(86362001)(8936002)(8676002)(52116002)(5660300002)(2906002)(478600001)(31686004)(26005)(83380400001)(54906003)(186003)(16526019)(4326008)(16576012)(316002)(53546011)(6666004)(956004)(2616005)(31696002)(66476007)(36756003)(6486002)(66556008)(7416002)(6916009)(66946007)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: JFifSoV/q413TAgo+MyxsEFpCaJpUsPm+AoIydB4O2P/ZPt63wX0IYFhwP9klIJRJPxqsALmgtnHluRWb0NmDijyWiAIxyd9zHbi/ZpUEwiRfNJ90sws1fJRQYjQltbcGl/6eqDmqu3+M8cp+8b4Gb0keksYrtfapH6CaO4RUzXuQisEet6bdNy2C6VUJ4LcG9VSzEOBzJ3wToXDPOExWAK9ir8Zauo+MMwHj5mwevGjFnSeywBV/ZuYZBzeMKRdC6Kyl4BhVuEn8Du+3FNrwBnMYjQ2CoDAoqrslC15XprkIenAKjgBABSsHUGUJDMq8RxFpelvELxTiWiuCnQTSvTbAEp2Q6On/2AuzTRlD/D+L8xygWTh7KfVoFI3XoeJ0FutGs0lP+ElVMh/TbggCiCt82ORohp1FQfDAfngr5etyfIHZZdVMDMsGpcj8P2yPzQlYMlewa0Br4JHINo7YgexNcfKChTeo4crcQXf1kU= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b4e4b0e-d67c-4b82-e0c3-08d816b365a1 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 13:51:43.4409 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: jR41N3iH637bLV5CMnZ+PmGPgQOPW4VYiwFfXG+EpGaziT81jDw36F322IyDiua5ttK4UtLP54K0nxzh2d4U7Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB5309 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 15:24, Roger Pau Monné wrote: > On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote: >> On 22.06.2020 11:31, Roger Pau Monné wrote: >>> On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote: >>>> On 18.06.2020 18:04, Roger Pau Monne wrote: >>>>> Commit e9aca9470ed86 introduced a regression when avoiding sending >>>>> IPIs for certain flush operations. Xen page fault handler >>>>> (spurious_page_fault) relies on blocking interrupts in order to >>>>> prevent handling TLB flush IPIs and thus preventing other CPUs from >>>>> removing page tables pages. Switching to assisted flushing avoided such >>>>> IPIs, and thus can result in pages belonging to the page tables being >>>>> removed (and possibly re-used) while __page_fault_type is being >>>>> executed. >>>>> >>>>> Force some of the TLB flushes to use IPIs, thus avoiding the assisted >>>>> TLB flush. Those selected flushes are the page type change (when >>>>> switching from a page table type to a different one, ie: a page that >>>>> has been removed as a page table) and page allocation. This sadly has >>>>> a negative performance impact on the pvshim, as less assisted flushes >>>>> can be used. >>>>> >>>>> Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush >>>>> using an IPI (flush_tlb_mask_sync). Note that the flag is only >>>>> meaningfully defined when the hypervisor supports PV mode, as >>>>> otherwise translated domains are in charge of their page tables and >>>>> won't share page tables with Xen, thus not influencing the result of >>>>> page walks performed by the spurious fault handler. >>>> >>>> Is this true for shadow mode? If a page shadowing a guest one was >>>> given back quickly enough to the allocator and then re-used, I think >>>> the same situation could in principle arise. >>> >>> Hm, I think it's not applicable to HVM shadow mode at least, because >>> CR3 is switched as part of vmentry/vmexit, and the page tables are not >>> shared between Xen and the guest, so there's no way for a HVM shadow >>> guest to modify the page-tables while Xen is walking them in >>> spurious_page_fault (note spurious_page_fault is only called when the >>> fault happens in non-guest context). >> >> I'm afraid I disagree, because of shadow's use of "linear page tables". > > You will have to bear with me, but I don't follow. > > Could you provide some pointers at how/where the shadow (I assume > guest controlled) "linear page tables" are used while in Xen > context? See config.h: /* Slot 258: linear page table (guest table). */ #define LINEAR_PT_VIRT_START (PML4_ADDR(258)) #define LINEAR_PT_VIRT_END (LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) /* Slot 259: linear page table (shadow table). */ #define SH_LINEAR_PT_VIRT_START (PML4_ADDR(259)) #define SH_LINEAR_PT_VIRT_END (SH_LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) These linear page tables exist in the Xen page tables at basically all times as long as a shadow guest's vCPU is in context. They're there to limit the overhead of accessing guest page tables and their shadows from inside Xen. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 13:56:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 13:56:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMwK-0001ra-TE; Mon, 22 Jun 2020 13:56:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMwK-0001rV-8f for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 13:56:48 +0000 X-Inumbo-ID: 35c2e3f2-b490-11ea-b7bb-bc764e2007e4 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe0d::60f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 35c2e3f2-b490-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 13:56:46 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RjnlQGT/4MyDDRhMG7nIDtyNWZUrrTTJxm2pSio3Zp2MA5J685t3VgoSE4cX6u8Jc7Go0lmunweqAkSF9SIq8digfnVnmqD4On/2uiIEsATKuneEhUcmQbRmzvsnAqK9FqBUIIQzQH96yqu5Qxsas72COZ4hCPFqoak0h1683U4OchzNVIL06H9cYbeD7tdLBtxrFrrGCX6V45Wt0x5SADkv0f1pCVeXTNR/HDvP3/CYfSpjdBmbgVAqfxkkSKDcB3ecNR9U36qrOsElZAQr8JbDT4k1oyCt9Pm+POs/8hTkO4ZI9z0jWMUWewk24uIHKgWfgLWdCqQYYRvPqGVv+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jVOvB/yzooCwwq6oZQ6CQdZJZH/l+WZowYVZ+GbFVzw=; b=fo5FhVZbBz2hXogf1hqb7bwmTjRsaGjjwjcGNLLVZTf7uQRPR94PriN3la89c/K8ApUnRqHH7PrebhN3nk7txaf/1U9Ujxynnl69JTPGIiRy/QyWaJyGuSwk5G4fpnazAYkrtAfTSjejnWXSrNu0Ngxvn1FJzx89MG4kAdE/h6MlAwkzqU683sT016OFJxwxsExMWafbXpZVQVwg8JjF+JSDeWpph1HXiPWMzykC+/i+boC6IrFheCMErtm1cGlSYFLQJY62osgnZR87BAV9HO4O6SZynqfNGA4vMxTmvYlpLO6aS3D6fAYgv2QSOZZPc3DiC0RvyA2tMvrQh5fPiw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jVOvB/yzooCwwq6oZQ6CQdZJZH/l+WZowYVZ+GbFVzw=; b=FmL3DEUgSNybcl3hVdO2YnrWXJ2DplMssYZCXgFu5l86jkA4Pnd3GItBgIAzRybOrSidljNtnJ8+wEXgBK3m5Qkpsi860TqJ4yMd/SRPlcgvWjPJ3x9rdxFEUYBm898yDAOIU2LRwM2KUcPuKxMZVlhRgs5iP7z44T3nyaJUvQlO2VtvYLkI0OaMwCY2Y7bB3YjsncMqVmvl6hTAahdfSSmhavPrW837HVx57LxZw0Rk1obv4WoYdW+lJ5c1RdDOh1f1Or42EsUBhq9/OpTN4y9N98T/KhHa4GkgYFdx4sOvgmwpTGTEj35j1rkjit6jxfmZbKlsxTYWsikBMnJSkQ== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB4927.eurprd03.prod.outlook.com (2603:10a6:803:bf::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Mon, 22 Jun 2020 13:56:44 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 13:56:44 +0000 From: Oleksandr Andrushchenko To: Julien Grall , Oleksandr Andrushchenko , Julien Grall , Stefano Stabellini Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAOXggIAABCWAgAABUwCAAAIogIAAAeMAgAACtYCAAAPKgIAEvpiA Date: Mon, 22 Jun 2020 13:56:44 +0000 Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> <424cfbdc-0744-fcf7-5bb4-52aca2357df7@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.245.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b6bf3f4-be3d-4bdf-569c-08d816b41962 x-ms-traffictypediagnostic: VI1PR03MB4927: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0442E569BC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LGh05987MNo91Cd6mcI+mdaKDDatMHI55V2hMw5VYFGUB0EmKNBDkgEEQkh84PlapfX02T85VBwuGI1LnCt4GLEOj429/f/W/1LwwaelM0dCeiFR3Zf7Gby7mGyrIDuKmgvxaaL1BptobCQtChhf8VpJg/yoDDoYQOJffVRO15pf+3CU6asbKFarTpRBFBbAU9GFP+Zpgwlw9YefgbaeMWG/MhabsBtgOMcRus+SvOks7p1hxR3Nz381LJwqKx35uy4n50uZPSf/EQNvApcGI6KIjAcsX3NuYH55QmzmNOCYhkHk4Fy3QSxL+zGJZ91k+mw9SCpLgWG3HD8H5U4mLmGhAglW2Vkk7nmwC/4BC8a/Vt/1g7lVVITZgpllI9NC x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(366004)(396003)(39860400002)(2616005)(6486002)(86362001)(8936002)(31696002)(8676002)(5660300002)(64756008)(66446008)(66476007)(83380400001)(91956017)(71200400001)(66946007)(76116006)(66556008)(186003)(6506007)(4326008)(26005)(55236004)(2906002)(6512007)(31686004)(53546011)(478600001)(7416002)(110136005)(36756003)(316002)(54906003)(98474003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: iVL/gZKcIrY2CqEo2epl7N6rui8qQvG4k7UWmFvNJIDAXPUVB7zaI8olaSyd+UeLMA/Oe9edKjLj6zm/8i98eUWdg4mU4N9s39UNkNNxyCmsH422GnDQOYWEN2RTQ1LRymeDs5K9VYJJ/YvRoBMI99JNvd+w8j2a8qmcCGKKLa2XkoPprEVMRsdk8guzs/WA5tn6pD+f3ZLQ3y48zH8xSpHPBdI0aVso0rjfjJ8z0vroQGYGazXwKxbQHahOg86AglVcXuArKGsdXXx4XUeQ2L9EKfsb0wzL6dSOkMYYjYv4R3SfBgBzMw7hLE2m2TOg/MtHrHWW0nmLlLCVWflN2xeEWi4e9NqFm7YEaWAnYGLLeG5f26CV7XJIFLP4tjFAL5d4uD//bOk/IUIGvaVFjsMn3K1HZ7Ji5ucLa2rTiTyZiyIqxylJPzyjtrzo8qUtgopMHEK55XNSSCfE7ri4XMp3CYuYy9ep1VwHz4L2xWX8/6/2KT92k1QWkPLYSsO5 Content-Type: text/plain; charset="utf-8" Content-ID: <12290F8468A9B4409B4EC1C19812689E@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b6bf3f4-be3d-4bdf-569c-08d816b41962 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2020 13:56:44.7535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: v/fmxxRyeuXBn8yR4GgOVSC9UKS+IKb459N41KPvq4TVNbtUcdHZVTftXGn9oO3lNgAGGdKhTvOuDOl+h0TUU5FiXWrNDNz90w1FUNLi/80ti29Ja8FoGdYQLihIiQx0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4927 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzE5LzIwIDQ6MjkgUE0sIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPiBP biA2LzE5LzIwIDQ6MTUgUE0sIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+DQo+Pg0KPj4gT24gMTkv MDYvMjAyMCAxNDowNiwgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gd3JvdGU6DQo+Pj4NCj4+PiBP biA2LzE5LzIwIDM6NTkgUE0sIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+Pj4gSGksDQo+Pj4+DQo+ Pj4+IE9uIDE5LzA2LzIwMjAgMTM6NTEsIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0K Pj4+Pj4gT24gNi8xOS8yMCAzOjQ3IFBNLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+Pj4+Pj4gVGhl eSB3aWxsIG5vdCBiZSBhdmFpbGFibGUgZnJvbSB0aGUgZmR0LCBidXQgeW91IGNhbiByZXRyaWV2 ZSB0aGVtIHdpdGggYW4gaHlwZXJ2aXNvciBjYWxsIChzZWUgSFZNX1BBUkFNX1NUT1JFX1BGTiwg SFZNX1BBUkFNX0NPTlNPTEVfUEZOKS4NCj4+Pj4+IFllcywgYW5kIGl0IHVzZWQgaW4gdGhlIHJl bGV2YW50IHBpZWNlcyBvZiBjb2RlIChoeXAgY2FsbHMpDQo+Pj4+Pj4gT25lIHF1ZXN0aW9uIHRo b3VnaCwgd2h5IGRvIHlvdSBuZWVkIHRvIG1hcCB0aGVtIGluIGFkdmFuY2U/IENvdWxkbid0IHlv dSBtYXAgdGhlbSBvbiBkZW1hbmQ/DQo+Pj4+Pg0KPj4+Pj4gV2VsbCwgd2UgbmVlZCB0byBhdCBs ZWFzdCBlc3RpbWF0ZSB0aGUgcGdfdGFibGUgc2l6ZSBzbyB3ZSBjYW4gcmVzZXJ2ZSBhbmQgYWxs b2NhdGUgbWVtb3J5IGxhdGVyLA0KPj4+Pg0KPj4+PiBPaCwgc28gVS1ib290IGRvZXNuJ3Qgc3Vw cG9ydCBydW50aW1lIHBhZ2UtdGFibGUgdGFibGUgYWxsb2NhdGlvbi4gSXMgdGhhdCByaWdodD8N Cj4+PiBBcyBwZXIgbXkgdW5kZXJzdGFuZGluZyBubywgd2UgcHJvdmlkZSBhIG1lbW9yeSBtYXAg YW5kIHRoZSB0YWJsZXMgYXJlIGFsbG9jYXRlZCBiZWZvcmVoYW5kDQo+Pg0KPj4gT2sgOiguDQo+ Pg0KPj4+Pg0KPj4+Pj4NCj4+Pj4+IHNvIEkgaGF2ZSB0byBwcm92aWRlIG1lbW9yeSByYW5nZSBm cm9tIGVpdGhlciBieSBjb2RpbmcgYSBjb25zdGFudCBvciBsb29raW5nIGludG8gdGhlIGRldnRy ZWUgYXQNCj4+Pj4+DQo+Pj4+PiBoeXBlcnZpc29yIHsgcmVnID0gPD47IH0uIEl0IGlzIGEgYml0 IHRyaWNreSB0aG91Z2gNCj4+Pj4NCj4+Pj4gTG9va2luZyBmb3IgYSBub2RlIGluIHRoZSBkZXZp Y2UtdHJlZSBzaG91bGRuJ3QgYmUgdG9vIGRpZmZpY3VsdCBnaXZlbiB0aGF0IHlvdSBoYXZlIGZk dF8qIGF2YWlsYWJsZS4NCj4+Pj4NCj4+Pj4gSG93ZXZlciwgcGxlYXNlIG5vdCB0aGF0IDxyZWc+ IGRvZXNuJ3QgcmVmZXIgdG8gdGhlIGd1ZXN0IG1hZ2ljIHBhZ2VzLiBJbnN0ZWFkLCBpdCBwcm92 aWRlcyBhIHJlZ2lvbiB5b3UgY2FuIHVzZSBmb3IgbWFwcGluZyB0aGUgZ3JhbnQtdGFibGUgZnJh bWVzDQo+Pj4NCj4+PiBJbmRlZWQsIHRoaXMgaXMgaW4gbXkgY2FzZSAweDM4MDAwMDAwLCBidXQg dGhlIG1hZ2ljIGlzIGF0IDB4MzkwMDAwMDANCj4+Pg0KPj4+IFNvLCBJIG5lZWQgdGhlIG1lbW9y eSByYW5nZSBzZXQgdXAgYmVmb3JlaGFuZCwgYnV0IEkgY2FuJ3QgYXMgdGhlcmUgaXMgbm8gY3V0 ZSB3YXkgdG8gZ2V0IHRoYXQuDQo+Pj4NCj4+PiBPZiBjb3Vyc2UsIEkgY2FuIGlzc3VlIGEgaHlw IGNhbGwgdG8gZ2V0IEhWTV9QQVJBTV9DT05TT0xFX1BGTiBhbmQgdXNlIGl0IGFzIHRoZSBiYXNl IGFkZHJlc3MsDQo+Pj4NCj4+PiBidXQgdGhpcyBzbWVsbHMgbGlrZSBhIGhhY2suIEkgY2FuIGNh bGwgb3RoZXIgSFZNX1BBUkFNXyB0byBnZXQgdGhlaXIgcGZucyBhbmQgc2V0IHVwIHRoZSBtZW1v cnkgcmVnaW9ucywNCj4+Pg0KPj4+IGJ1dCB0aGlzIGxvb2tzIGEgYml0IHdlaXJkLg0KPj4NCj4+ IFdoeSBpcyBpdCB3ZWlyZD8gSW4gZ2VuZXJhbCwgeW91IG9ubHkgd2FudCB0byBtYXAgZXhhY3Rs eSB3aGF0IHlvdSBuZWVkLiBOb3QgbGVzcywgbm90IG1vcmUuDQo+Pg0KPj4gSW4geW91ciBzaXR1 YXRpb24sIHlvdSBvbmx5IGNhcmUgYWJvdXQgdHdvIHBhZ2VzLCB0aGUgY29uc29sZSBwYWdlIGFu ZCB0aGUgeGVuc3RvcmUgcGFnZS4gVGhlIHJlc3Qgc2hvdWxkbid0IGJlIG1hcHBlZC4NCj4gT2ss IHNvIEknbGwgdHJ5IGdldCBwZm5zIGZvciBIVk1fUEFSQU1fQ09OU09MRV9QRk4gKyBYRU5TVE9S RV9QRk5fT0ZGU0VUIHZpYSBoeXAgY2FsbCBhbmQgbWFwIHRob3NlDQo+Pg0KPj4+IEkgbmVlZCB0 aGF0IGNvbnN0YW50IGJhZGx5IDspDQo+Pg0KPj4gTm8geW91IGRvbid0IDspLg0KDQpXZSBoYXZl IG1hbmFnZWQgdG8gbWFrZSB1c2Ugb2YgdGhlIHJlbGV2YW50IGh5cGVyY2FsbHMgdG8gZ2V0IHRo ZSBQRk5zLCBidXQgZm9yIHRoYXQNCg0Kd2UgbmVlZCB0byBtYWludGFpbiB0aGUgY2FjaGVzIGFz IHRoaXMgaGFwcGVucyAodGhlIGNhbGxzKSB3aGVuIE1NVSBpcyBub3QgeWV0DQoNCnNldHVwIGFu ZCBpcyBpbiB0aGUgcHJvY2VzcyBvZi4NCg0KPj4NCj4+IENoZWVycywNCj4+DQo+IFRoYW5rcyBm b3IgaGVscGluZyB3aXRoIHRoaXM= From xen-devel-bounces@lists.xenproject.org Mon Jun 22 13:59:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 13:59:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMyW-00022G-NL; Mon, 22 Jun 2020 13:59:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMyV-00022B-GC for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 13:59:03 +0000 X-Inumbo-ID: 85dc6c64-b490-11ea-8496-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 85dc6c64-b490-11ea-8496-bc764e2007e4; Mon, 22 Jun 2020 13:59:00 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 7y4rcKvZcox4JFp72HsObqCBchKdRBPFQ+txFZgp5PYBmgG+CpJa2dAZJs5k057cPFD9L0p+9v bssuV7vrAiO89TodoThg07a2b9QUBMrdkiS3JZLO1ifQtw6hZE05Zw1kq/bEAOQuK0emmgKdqN LEdrw7WS8Lo4S05270JNP23KAQ2CR1Pt5iQttOoV26p+SQwHIKFCzns5zwUagRl2HspJApiJmQ 3pgBxfsMdCIbovvJEsHAYblfqYcBBUa/FWRhV8okz+PMlVo11BUjLFw+EJHkFoTxlYhcCtZDNk wGU= X-SBRS: 2.7 X-MesageID: 20968042 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,267,1589256000"; d="scan'208";a="20968042" Date: Mon, 22 Jun 2020 15:58:53 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Martin Lucina Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200622135853.GK735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> <20200619165426.GD735@Air-de-Roger> <20200619174143.GE735@Air-de-Roger> <7ed4a5f98b3002f3233e02d5ce803ef0@lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7ed4a5f98b3002f3233e02d5ce803ef0@lucina.net> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote: > On 2020-06-19 19:42, Roger Pau Monné wrote: > > On Fri, Jun 19, 2020 at 06:54:26PM +0200, Roger Pau Monné wrote: > > > On Fri, Jun 19, 2020 at 06:41:21PM +0200, Martin Lucina wrote: > > > > On 2020-06-19 13:21, Roger Pau Monné wrote: > > > > > On Fri, Jun 19, 2020 at 12:28:50PM +0200, Martin Lucina wrote: > > > > > > On 2020-06-18 13:46, Roger Pau Monné wrote: > > > > > > > On Thu, Jun 18, 2020 at 12:13:30PM +0200, Martin Lucina wrote: > > > > > > > > At this point I don't really have a clear idea of how to progress, > > > > > > > > comparing my implementation side-by-side with the original PV > > > > > > > > Mini-OS-based > > > > > > > > implementation doesn't show up any differences I can see. > > > > > > > > > > > > > > > > AFAICT the OCaml code I've also not changed in any material way, and > > > > > > > > that > > > > > > > > has been running in production on PV for years, so I'd be inclined > > > > > > > > to think > > > > > > > > the problem is in my reimplementation of the C parts, but where...? > > > > > > > > > > > > > > A good start would be to print the ISR and IRR lapic registers when > > > > > > > blocked, to assert there are no pending vectors there. > > > > > > > > > > > > > > Can you apply the following patch to your Xen, rebuild and check the > > > > > > > output of the 'l' debug key? > > > > > > > > > > > > > > Also add the output of the 'v' key. > > > > > > > > > > > > Had to fight the Xen Debian packages a bit as I wanted to patch the > > > > > > exact > > > > > > same Xen (there are some failures when building on a system that has > > > > > > Xen > > > > > > installed due to following symlinks when fixing shebangs). > > > > > > > > > > > > Here you go, when stuck during netfront setup, after allocating its > > > > > > event > > > > > > channel, presumably waiting on Xenstore: > > > > > > > > > > > > 'e': > > > > > > > > > > > > (XEN) Event channel information for domain 3: > > > > > > (XEN) Polling vCPUs: {} > > > > > > (XEN) port [p/m/s] > > > > > > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 > > > > > > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > > > > > > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 > > > > > > (XEN) 4 [0/1/1]: s=2 n=0 x=0 d=0 > > > > > > > > > > > > 'l': > > > > > > > > > > > > (XEN) d3v0 IRR: > > > > > > ffff8301732dc200b > > > > > > (XEN) d3v0 ISR: > > > > > > ffff8301732dc100b > > > > > > > > > > Which version of Xen is this? AFAICT it doesn't have the support to > > > > > print a bitmap. > > > > > > > > That in Debian 10 (stable): > > > > > > > > ii xen-hypervisor-4.11-amd64 4.11.3+24-g14b62ab3e5-1~deb10u1.2 > > > > amd64 Xen Hypervisor on AMD64 > > > > > > > > xen_major : 4 > > > > xen_minor : 11 > > > > xen_extra : .4-pre > > > > xen_version : 4.11.4-pre > > > > > > > > > > > > > > Do you think you could also pick commit > > > > > 8cd9500958d818e3deabdd0d4164ea6fe1623d7c [0] and rebuild? (and print > > > > > the info again). > > > > > > > > Done, here you go: > > > > > > > > (XEN) Event channel information for domain 3: > > > > (XEN) Polling vCPUs: {} > > > > (XEN) port [p/m/s] > > > > (XEN) 1 [1/0/1]: s=3 n=0 x=0 d=0 p=33 > > > > (XEN) 2 [1/1/1]: s=3 n=0 x=0 d=0 p=34 > > > > (XEN) 3 [1/0/1]: s=5 n=0 x=0 v=0 > > > > (XEN) 4 [0/1/1]: s=3 n=0 x=0 d=0 p=35 > > > > > > > > > > > > (XEN) d3v0 IRR: > > > > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > > > > (XEN) d3v0 ISR: > > > > 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000 > > > > > > So there's nothing pending on the lapic. Can you assert that you will > > > always execute evtchn_demux_pending after you have received an event > > > channel interrupt (ie: executed solo5__xen_evtchn_vector_handler)? > > > > > > I think this would be simpler if you moved evtchn_demux_pending into > > > solo5__xen_evtchn_vector_handler? As there would be less asynchronous > > > processing, and thus likely less races? > > > > Having though about this, I think this model of not demuxing in > > solo5__xen_evtchn_vector_handler is always racy, as it's not possible > > to assert that you would always call evtchn_demux_pending after > > solo5__xen_evtchn_vector_handler? > > > > Ie: if you receive an interrupt just before going to sleep (after the > > sti and before the hlt) you will execute > > solo5__xen_evtchn_vector_handler and EOI the vector, but then > > evtchn_demux_pending will never get called, and thus the interrupts > > will stay indefinitely pending? > > Aha! Thank you for pointing this out. I think you may be right, but this > should be possible without doing the demuxing in interrupt context. If you don't do the demuxing in the interrupt context (ie: making the interrupt handler a noop), then you don't likely need such interrupt anyway? > How about this arrangement, which appears to work for me; no hangs I can see > so far and domU survives ping -f fine with no packet loss: > > CAMLprim value > mirage_xen_evtchn_block_domain(value v_deadline) > { > struct vcpu_info *vi = VCPU0_INFO(); > solo5_time_t deadline = Int64_val(v_deadline); > > if (solo5_clock_monotonic() < deadline) { > __asm__ __volatile__ ("cli" : : : "memory"); > if (vi->evtchn_upcall_pending) { > __asm__ __volatile__ ("sti"); > } > else { > hypercall_set_timer_op(deadline); What if you set a deadline so close that evtchn_upcall_pending gets set by Xen here and the interrupt is injected? You would execute the noop handler and just hlt, and could likely end up in the same blocked situation as before? > __asm__ __volatile__ ("sti; hlt"); > } > } > return Val_unit; > } > > i.e. Always go to sleep with interrupts disabled, but before doing so > re-check that no events have become pending since the last time > evtchn_demux_pending() was called. This holds, since the only thing that > sets vi->evtchn_upcall_pending is Xen, and the only thing that clears it is > evtchn_demux_pending(). > > Right? TBH this is a hard model to get right, I think your best bet at attempting something along this lines is to forget about using the event channel interrupt and instead use SCHEDOP_poll. You could do something like (written in pure C as I have no idea of the ocaml bindings): int mirage_xen_evtchn_block_domain(uint64_t timeout) { evtchn_port_t ports[MAX_PORTS]; struct sched_poll poll = { .timeout = timeout, .nr_ports = 0, }; set_xen_guest_handle(poll.ports, ports); /* Fill ports you care about (ie: all event channel ports in use) */ ports[poll.nr_ports++] = port_1; ports[poll.nr_ports++] = port_2; [...] /* Check that you don't overrun MAX_PORTS */ /* On return demux events and call timer handler if timeout expired. */ return hypercall_sched_op(SCHEDOP_poll, &poll); } Doing something like the above you could forget about setting up the event channel interrupt and the timer. > __asm__ __volatile__ ("sti; hlt"); > } > } > return Val_unit; > } > > In an attempt to understand why the original PV code worked I re-read the PV > Mini-OS block_domain code again and realised that I had entirely missed one > part of its behaviour, which is that it intends[*] to run with > interrupts/upcalls disabled *all* the time and relies on SCHEDOP_block > atomically re-enabling them and triggering an upcall before returning (PV) > or "briefly enabling interrupts to allow handlers to run" (HVM). We're doing > the inverse, but our behaviour matches my mental model of how things should > work. Not really IMO, as SCHEDOP_block is a single 'instruction' from a guest PoV that does the enabling of interrupts and returns if there are pending ones. Also SCHEDOP_block is not exactly the same on HVM, as it just checks for pending vectors to inject, but not for pending event channels. On HVM you cannot call hlt with interrupts disabled, or the vCPU will be taken down. There are quite a lot of subtle differences between PV and HVM in this regard, and I think the best approach would be to use SCHEDOP_poll in order to implement the kind of model you describe. Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 13:59:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 13:59:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMz0-00027B-6Q; Mon, 22 Jun 2020 13:59:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnMyz-000271-KQ for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 13:59:33 +0000 X-Inumbo-ID: 99080bd6-b490-11ea-be90-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 99080bd6-b490-11ea-be90-12813bfff9fa; Mon, 22 Jun 2020 13:59:32 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 7X9gmyIAKOlQL8nvF1udnwKS4JBWh3MorgVme+hYznieiE5DEWK3pAhQlytfVS3c+dgZ96e4N8 eSfj/FsfUlFahmGdFJlPquz7PeEyimAOetHx2xjTsFbb45IlRYa7qMuA5w6DnE5Hz0IQvEXNJp Kx0RttgZ5u3yqAKGrA9X6Lh3jRg0iLtkTAHk7Fa5PusrhQZjWEgLambRYX3zl8LuEhhdkWF6sd nd4Ld+4Lzw5RPQ98Zoy/YU3CYfsvB0LC47QOQp6/q2liT+jcMfpaWYtXhWc/TVi1pBCxgremps 8KM= X-SBRS: 2.7 X-MesageID: 20842150 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,267,1589256000"; d="scan'208";a="20842150" Subject: Re: [PATCH] x86/CPUID: fill all fields in x86_cpuid_policy_fill_native() To: Jan Beulich References: <41177396-9944-0bbd-66d2-8b4f2bd063f0@suse.com> From: Andrew Cooper Message-ID: <9675d3dc-d554-0231-25bc-bb24f0d9157c@citrix.com> Date: Mon, 22 Jun 2020 14:59:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22/06/2020 14:37, Jan Beulich wrote: > On 22.06.2020 14:39, Andrew Cooper wrote: >> On 22/06/2020 13:09, Jan Beulich wrote: >>> Coverity validly complains that the new call from >>> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves >>> two fields uninitialized, yet they get then consumed by >>> x86_cpuid_copy_to_buffer(). (All other present callers of the function >>> pass a pointer to a static - and hence initialized - buffer.) >>> >>> Coverity-ID: 1464809 >>> Fixes: c22ced93e167 ("tests/cpu-policy: Confirm that CPUID serialisation is sorted") >>> Signed-off-by: Jan Beulich >>> >>> --- a/xen/lib/x86/cpuid.c >>> +++ b/xen/lib/x86/cpuid.c >>> @@ -176,6 +176,10 @@ void x86_cpuid_policy_fill_native(struct >>> ARRAY_SIZE(p->extd.raw) - 1); ++i ) >>> cpuid_leaf(0x80000000 + i, &p->extd.raw[i]); >>> >>> + /* Don't report leaves from possible lower level hypervisor. */ >> ", for now." >> >> This will change in the future. > I was pondering at that moment whether to add it, but then I didn't > think we'd want to let shine through lower level hypervisor info. > But yes, I've added it, because it won't be wrong to say "for now", > even if it end up being for much longer. It won't be very much longer. I don't intend to let it "shine though", but the outer hypervisors data should be in the raw/host policy, just as the Xen Xen/Viridian leaves need to be in the guest policies. This is the longterm plan to handle Viridian features, because the existing HVMPARAM simply isn't expressive enough. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 22 14:04:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 14:04:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnN3g-0003AN-Qi; Mon, 22 Jun 2020 14:04:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnN3g-0003AI-36 for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 14:04:24 +0000 X-Inumbo-ID: 45df487e-b491-11ea-8496-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.85]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 45df487e-b491-11ea-8496-bc764e2007e4; Mon, 22 Jun 2020 14:04:23 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lW8LEWWvgvDkKxOXZAdNlbOKRNZeZgqck+8AbsP8QBcIOAIAZsxqCFBIkilQYwHGJZzok9yVyQpU3ni4lc4/09Ugi9rtjYJT6UYvGbU+YlZpv7eq/omM7W/1XEVyKYhbgU9AtEaZQK4BfOtmmJoZqiUleQ9ezPABUknBV25e8myO5gEFp9ht56qSRwFCyEk0myUwRi0D5MNJFFuPEIuyxUTr3eCHuhlGwWKUTxBc++/7ondOHj7FiNmLy4VWg1hmREtWrDSB41KidaDVjsc3hF64Cqg85VgY6JjWBJBLtowWDdPoQ9Q7ECUZmUdsOZMns5vlhzjTAgT6pp6UDMGwBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0iNLQhrmGd2Wbnano8zriqB40/uUisQlNDMqBo9zPVs=; b=IUgFD0w/9OGdMrnYdM0u8G3gX9bYwCZF/x8DbFlbqO0bZs8AsSsip6TAXCkLccTGd8hS4egeJpFpGih0HdGFgaIChiO7lStbLATonOyifRHcfCHM/Nod9wfpPqBSX2pjpXdCuKz0fUrKhEmn87G416R0jWcXeC1KB80AY29PvMclNZVLD+u9JOTTS8jblVY0raqDNd+o/K328LO2iZnW5XqHDK08IDNPqs0R6hOq9/vWLxHSumhLudvMCz2mIcKbmEtewH6vcga/LTNJzWfd0AC3V1zaoZFvVUn+CoH8ofWkvTMuSfjFb+pAcst5Bnpth64ndD1ik48jfX+7tAfQJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0iNLQhrmGd2Wbnano8zriqB40/uUisQlNDMqBo9zPVs=; b=mcTF9rGw7TUMLjgLtPFhOdXS3Tww0M9dyVOEzFBLk7QtE/kLLnXasQ72g5KAwPTVoaSRc99IP5qLJ1J/finIf3UBuVbaxCGjhfV8szJqiM1UzY418WUZlcg6KGVAlV0F2KEH9nsHi99ygfCiQSguIoM3Oh8E/LQdQVssuv41o5IpHnvKhvhWiTLw7ZOoT0MbL5L1vCpPaAMnVWftLgn2x3NylAmwx/LFjljerVxUIYWXWXLRTn0SF36Jy5TepaKLD9q0PnKDnh+zDG5OWB2gGRSCe11mCyVkXgB4lvZcvfKHRuhkgE9d4eknOMpeSYwbhz5Qd57hGuBrS8Gh80C6GQ== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB6445.eurprd03.prod.outlook.com (2603:10a6:800:17f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.25; Mon, 22 Jun 2020 14:04:21 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 14:04:21 +0000 From: Oleksandr Andrushchenko To: Stefano Stabellini , Julien Grall Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAWPDgIAEUtgA Date: Mon, 22 Jun 2020 14:04:21 +0000 Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.245.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c476bed3-d369-4f21-bf19-08d816b529ad x-ms-traffictypediagnostic: VI1PR03MB6445: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0442E569BC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3Jp7MQfCHo2M+EpWZjqP4Ymcj2bd85WAF2bPM3S7hnR34QN8AjEZSizQWkOKVsyv8hK28A1bs09x+YSc6qJKrOAabwRaV7ED7vS4rVPyZE4XMGdCA20zNney+pUMKjp5LYDQoMmts2QWFcdZVgVC9wolpsgV+Diuhti6dPx4vPlmDSJIPReDHFQCXisApglHICJ/0VqlEvL+pctRZGBKkc3S5AS6+ifMuVItL/FKh/A+XvnfWyzp0otDSLVhavdy/Q+6J3+gLv9Ako8Q/PM9qOmJUDbOpHLeCE7mx3WdJNEvIHyVZzPkbin82GyB6Zk1NoCpXIhjoV6PWdI6BAA0ldIr5pkMgH3xo646HZCY/Fj4LKR1qBtIeLdskVBsraMZvxDclsHy2z3aQNjPyXleHZTT0I7in7D1OrvrP6tBOint27p47/5nQrcqsoa0D39Dxi/+3ehjXMdWoNI8Pi6tWQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(376002)(366004)(136003)(316002)(54906003)(186003)(6512007)(31696002)(2616005)(5660300002)(31686004)(4326008)(6486002)(110136005)(55236004)(6506007)(53546011)(36756003)(478600001)(966005)(26005)(71200400001)(66476007)(66946007)(8936002)(83380400001)(91956017)(64756008)(76116006)(66556008)(86362001)(2906002)(66446008)(8676002)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: GU6mfYd3hLOAZzK6n6X1ms8yM99ac2QxfB5NaTF0EntAmFyOGckwx2XdAjK1mRYIK1X5rCkulB+NYMxAApFC0L1yC2LOZe4u1e+e9Q19bvqtwNT7sk74Karaj2gQ97ktUdeh6x7sgCMacTJYmRdS+UJ6QVB3pcZOKeZ+b4JKCag1WMRg2qIVkQsm4IbLcrRs1cwcOWoh8TguCU2DcgVldgtgXC9GVMg7jnv96QqO0YPTOk8rv/B897kQBp4Crf/U5EsK+xDhrxNn3r7BhYuAralGG0TN2kTf7/YpLmPltf+VRu0wM5NUL6aAHsAc7hik45C4F0AzVqSKXZVZuN6PbKqlTulOdE4DhqBE7zrbMEB1rQKbtA3wyGYmXyGsFQil5t6IWuwCMDzKcE+bhwgXwpFh9dH2vlptm4id34rO2TnbUdSvi0bVfSOsLeu2iotBwkmHQuZSb6rFa4RbV6Xep5fUEI3+jWGfqxJruxdRal8miZAr9/Y3TQRLWE5VahyG Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: c476bed3-d369-4f21-bf19-08d816b529ad X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2020 14:04:21.5800 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eak0KGj50Oh7MjRwZCfPwfeLIWp18Qlizzq+YSL1Y/i4SWK775opYTOrXt4EBcfTe3Pd2mODp8JXhZngvRy417u3Tx86bm7BdUt3Hstu5F08GCg4PwWefxTGYYL4qpQY X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6445 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzE5LzIwIDExOjAyIFBNLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+IE9uIFRo dSwgMTggSnVuIDIwMjAsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+PiBDb3B5L3Bhc3RpbmcgaGVy ZSBmcm9tIG15IGNvbW1lbnQgb24gdGhlIHB1bGwgcmVxdWVzdCBwbHVzIGFkZGl0aW9uYWwNCj4+ PiB0aG91Z2h0cy4NCj4+Pg0KPj4+IFVib290IGlzIG9uZSBvZiB0aG9zZSBlbWJlZGRlZCBwcm9q ZWN0cyB0aGF0IHR5cGljYWxseSBhc3N1bWVzIHRoYXQgYWxsDQo+Pj4gdGhlIGluZm9ybWF0aW9u IGFib3V0IHRoZSBwbGF0Zm9ybSBpcyBhdmFpbGFibGUgYXQgKmJ1aWxkIHRpbWUqLiBJdCBpcw0K Pj4+IG1lYW50IHRvIGJlIGJ1aWx0IHRhaWxvcmVkIGZvciBhIHNwZWNpZmljIHZlcnNpb24gb2Yg YSBzcGVjaWZpYyBib2FyZC4gQQ0KPj4+IFVib290IGJpbmFyeSBpcyBub3QgZXhwZWN0ZWQgdG8g YmUgInBvcnRhYmxlIiBhY3Jvc3MgZGlmZmVyZW50IHZlcnNpb25zDQo+Pj4gb2YgdGhlIHBsYXRm b3JtIG9yIGRpZmZlcmVudCBwbGF0Zm9ybXMuIEluIG90aGVyIHdvcmRzLCBpdCBpcyBub3QNCj4+ PiBleHBlY3RlZCB0byBiZSBwb3J0YWJsZSBhY3Jvc3MgWGVuIHZlcnNpb25zLg0KPj4gQ2FuIHlv dSBkZWZpbmUgInZlcnNpb24iIGhlcmU/IERvIHlvdSByZWZlciB0byB0aGUgZGlmZmVyZW5jZSBp biB0ZXJtcw0KPj4gb2YgbWVtb3J5Pw0KPiAgIA0KPiBZZXMsIEkgbWVhbnQgYW55IG1lYW5pbmdm dWwgZGlmZmVyZW5jZXMgaW4gYW55IG9mIHRoZSBleHRlcm5hbA0KPiBpbnRlcmZhY2VzIHRoYXQg ZW5kIHVwIGltcGFjdGluZyB0aGUgVUJvb3QgaW1wbGVtZW50YXRpb24uIEEgcHJpbWFyeQ0KPiBl eGFtcGxlIHdvdWxkIGJlIHRoZSBtZW1vcnkgYWRkcmVzc2VzIGZvciBpbnN0YW5jZS4NCj4NCj4N Cj4+PiBUaGlzIGlzIGEgZGlmZmVyZW50IG1vZGVsIG1lYW50IGZvciBkaWZmZXJlbnQgdXNlLWNh c2VzLiBJIGRvbid0IHRoaW5rDQo+Pj4gaXQgaXMgYSBwcm9ibGVtICJwaGlsb3NvcGhpY2FsbHki IHRvIGxldCBVYm9vdCBrbm93IGFib3V0IFhlbiBkZXRhaWxzIGF0DQo+Pj4gYnVpbGQgdGltZS4g WWVzLCB0aGF0IGlzIG5vdCB3aGF0IHdlIGRpZCBoaXN0b3JpY2FsbHkgYnV0IGl0IGlzIHZlcnkN Cj4+PiBtdWNoIGluIHRoZSBzcGlyaXQgb2YgVWJvb3QuDQo+PiBUQkgsIEkgZG9uJ3QgcGFydGlj dWxhcmx5IG1pbmQgdGhhdCBVLWJvb3QgaXMgYnVpbHQgYWdhaW5zdCBhIHNwZWNpZmljDQo+PiB2 ZXJzaW9uIG9mIFhlbi4gSSBhbSBtb3JlIGNvbmNlcm5lZCBhYm91dCB0aGUgbG9uZyB0ZXJtIGlt cGxpY2F0aW9uIGlmDQo+PiB3ZSBlbmRvcnNlIGl0DQo+PiBhbmQgdGhlbiB0cnkgdG8gY2hhbmdl IHRoZSBtZW1vcnkgbGF5b3V0IGluIGRlcHRoLg0KPiBJJ2xsIHByb3ZpZGUgbW9yZSBpbmZvcm1h dGlvbiBiZWxvdy4NCj4NCj4NCj4+PiBCdXQgb2YgY291cnNlIHRoZSBsZWFzdCBVYm9vdCBkZXBl bmRzIG9uIHRoZXNlIGRldGFpbHMgdGhlIGJldHRlcg0KPj4+IGJlY2F1c2UgaXQgd2lsbCBiZSBt b3JlIGZsZXhpYmxlLCBidXQgaXQgY291bGQgdmVyeSB3ZWxsIGJlIHRoYXQgd2UNCj4+PiB3b24n dCBiZSBhYmxlIHRvIHJlYWNoIHRoZSBwb2ludCB3aGVyZSB0aGUgYmluYXJ5IHdvcmtzIG9uIGFu eSB2ZXJzaW9uDQo+Pj4gbGlrZSB3ZSBkaWQgd2l0aCBUaWFub2NvcmUuIFRoZSB0d28gcHJvamVj dHMgd29yayBkaWZmZXJlbnRseS4NCj4+IENhbiB3ZSBoYXZlIGEgbGlzdCBvZiB0aGluZ3MgVS1i b290IHJlcXVpcmUgdG8ga25vdyBhdCBjb21waWxlIHRpbWU/DQo+Pg0KPj4gSW4gcGFydGljdWxh ciwgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgaWYgaXQgd291bGQgYmUgc3VmZmljaWVudCB0 bw0KPj4gb25seSBiZSBhd2FyZSBvZiB0aGUgZmlyc3QgYmFuay4gSWYgaXQgaXMsIHRoZW4gbXkg cHJlZmVyZW5jZSB3b3VsZCBiZQ0KPj4gdG8gc3RhbmRhcmRpemUgdGhhdCBiaXQgb2YgdGhlIGxh eW91dC4NCj4gVGhhdCB3b3VsZCBiZSBteSBwcmVmZXJlbmNlIHRvbywgYW5kIGl0IHdhcyBncmVh dCB0byByZWFkIHRoYXQgaXQgbG9va3MNCj4gbGlrZSBpdCBjYW4gYmUgZG9uZS4gWWF5IQ0KPg0K Pg0KPj4+IFRoYXQgc2FpZCwgSSB0aGluayBKdWxpZW4gaXMgcmlnaHQgdGhhdCB3ZSBuZWVkIHRv IGJlIGNhcmVmdWwgb24gaG93IHdlDQo+Pj4gZXhwb3NlIHRoZXNlIGluZm9ybWF0aW9uIHRvIFVi b290LCBpLmUuIGRlZmluaW5nIF9fWEVOX18gdG8gYnVpbGQgVWJvb3QNCj4+PiBkb2Vzbid0IHNl ZW0gbGlrZSBhIGdvb2QgaWRlYSBiZWNhdXNlIHdlIGVuYWJsZSBkZWZpbml0aW9ucyB0aGF0IHdl cmUNCj4+PiBuZXZlciBtZWFudCB0byBiZSB1c2VkIG91dHNpZGUgb2YgYSBYZW4gYnVpbGQuIEFs c28sIGl0IHdvdWxkbid0IGJlIGVhc3kNCj4+PiB0byBrbm93IGV4YWN0bHkgd2hpY2ggZGVmaW5p dGlvbnMgYXJlIGFjdGl2ZWx5IHVzZWQgYnkgVWJvb3QgYW5kIHdoaWNoDQo+Pj4gb25lcyBhcmVu J3QuDQo+Pj4NCj4+PiBJZiB3ZSBhcmUgZ29pbmcgdG8gbWFrZSBVYm9vdCBkZXBlbmRlbnQgb24g dmVyc2lvbi1zcGVjaWZpYyBpbmZvcm1hdGlvbg0KPj4+IG9mIHRoZSBYZW4gaW50ZXJmYWNlLCBp dCB3b3VsZCBiZSBiZXR0ZXIgdG8gYmUgdmVyeSBjbGVhciBhYm91dCB3aGljaA0KPj4+IGRlZmlu aXRpb25zIHdlIGFyZSB1c2luZy4gU28gdGhhdCBvbmUgZGF5IGlmIHdlIG5lZWQgdG8gY2hhbmdl IHRoZW0sIHdlDQo+Pj4gY2FuIGZpbmQgdGhlbSBlYXNpbHkuDQo+Pj4NCj4+PiBTbyBJIHRoaW5r IGl0IHdvdWxkIGJlIGJldHRlciB0byBpbnRyb2R1Y2UgYSBzZXQgb2YgZGVmaW5lcyB3aXRoIHRo ZQ0KPj4+IG1pbmltdW0gYW1vdW50IG9mIGluZm9ybWF0aW9uIHJlcXVpcmVkIGJ5IFVib290IHN0 YXRpY2FsbHkuIFRoYXQgd2F5LA0KPj4+IGF0IGxlYXN0IHdlIGhhdmUgYSBzaW5nbGUgcGxhY2Ug d2hlcmUgdG8gZmluZCBhbGwgdGhlIHZlcnNpb24tc3BlY2lmaWMNCj4+PiBkZWZpbml0aW9ucyB0 aGF0IFVib290IGlzIHVzaW5nLg0KPj4gSSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBhcmUgc3VnZ2Vz dGluZy4gQ2FuIHlvdSBleHBhbmQgYSBiaXQgbW9yZT8NCj4+DQo+Pj4gV2UgY2FuIGFsc28gbWFu YWdlIHZlcnNpb25pbmcgb2YgdGhlDQo+Pj4gWGVuIGludGVyZmFjZSAobGlrZSB3ZSBkbyBpbiBR RU1VKSBpZiB3ZSBoYXZlIHRvLg0KPj4gQ2FuIHlvdSBwcm92aWRlIG1vcmUgZGV0YWlscyBhYm91 dCB0aGUgY29tcGF0aWJpbGl0eT8gSSBhbSBxdWl0ZQ0KPj4gaW50ZXJlc3RlZCBpbiB0aGUgcGFy dCB3aGVyZSB5b3Ugd291bGQgaGF2ZSB0byBkZWFsIHdpdGggYW4gb2xkZXIgUUVNVQ0KPj4gdmVy c2lvbiBidWlsdCBhZ2FpbnN0IGEgbmV3IFhlbj8NCj4gU3VyZSBsZXQgbWUgZXhwYW5kIGEgYml0 IG1vcmUuIEknbGwgc3dpdGNoICJoYXQiIHRvICJRRU1VIChvciBVQm9vdCkNCj4gY29udHJpYnV0 b3IiIGZvciB0aGUgc2FrZSBvZiB0aGlzIGRpc2N1c3Npb24uDQo+DQo+IFhlbiBQcm9qZWN0IG9m ZmVycyBjZXJ0YWluIHN0YWJpbGl0eSBndWFyYW50ZWVzIG9uIHNvbWUgaW50ZXJmYWNlcyBhbmQN Cj4gbm90IG90aGVycy4gTGV0J3Mgc2F5IHRoYXQgZm9yIGFueSByZWFzb24geW91IGhhdmUgdG8g b3Igd2FudCB0byB1c2Ugb25lDQo+IG9mIHRoZSB1bnN0YWJsZSBpbnRlcmZhY2VzIGluIFFFTVUv VUJvb3QvV2hhdGV2ZXIuIFRoZW4gaXQgYmVjb21lcyB5b3VyDQo+IHJlc3BvbnNpYmlsaXR5IGFz IFFFTVUgZGV2ZWxvcGVyIHRvIG1haW50YWluIGNvbXBhdGliaWxpdHkgaW4gUUVNVQ0KPiBpdHNl bGYuDQo+DQo+IEZpcnN0IEknZCBhZGQgY29kZSB0byBkZXRlY3QgdGhlIHZlcnNpb24gb2YgdGhl IGludGVyZmFjZS4gVGhlIGRldGVjdGlvbg0KPiBpcyBiYXNlZCBvbiB0aGUgWGVuIGhlYWRlcnMv bGlicmFyaWVzIHByb3ZpZGVkLiBJbiBRRU1VIGl0IGlzIGRvbmUgaW4NCj4gdGhlICJjb25maWd1 cmUiIHNjcmlwdC4gSXQgc2V0cyBhIHByZXByb2Nlc3NvciAjZGVmaW5lIHRvIHRoZSB2ZXJzaW9u DQo+IG9mIHRoZSBpbnRlcmZhY2UgKGUuZy4gQ09ORklHX1hFTl9DVFJMX0lOVEVSRkFDRV9WRVJT SU9OID09IDQxMTAwKS4NCg0KSSBsb29rZWQgYXQgUUVNVSdzIGNvbmZpZ3VyZSBzY3JpcHQgYW5k IEknbSBhZnJhaWQgd2UgY2FuJ3QgaGF2ZSB0aGUNCg0Kc2FtZSBmbGV4aWJpbGl0eSBpbiBVLWJv b3Q6IHdlIGRvbid0IGhhdmUgY29uZmlndXJlIHNjcmlwdCwgcGtnLWNvbmZpZw0KDQppcyBub3Qg d2lkZWx5IHVzZWQgZXRjLiBTbywgZm9yIG5vdyB3ZSBoYXZlIGhhcmRjb2RlZDoNCg0KaWZlcSAo JChDT05GSUdfWEVOKSx5KQ0KYXJjaC15ICs9IC1EX19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXz0w eDAwMDQwZDAwDQplbmRpZg0KDQphbmQgd2UgYWxzbyBoYXZlIFhlbiA0LjEzIGhlYWRlcnMgaW4g dGhlIFUtYm9vdCB0cmVlLg0KDQpGb3IgdGhlIGZpcnN0IHBhcnQgKF9fWEVOX0lOVEVSRkFDRV9W RVJTSU9OX18pIEkgdGhpbmsgd2UgY2FuIHByb3ZpZGUgaXQgdmlhDQoNCkNGTEFHUyBvciBzb21l dGhpbmcuIFRoaXMgY2FuIGFsc28gYmUgZG9uZSBmb3IgdGhlIGxvY2F0aW9uIG9mIFhlbiBoZWFk ZXJzLg0KDQpXZSBkb24ndCBoYXZlIHN0cm9uZyBvcGluaW9uIGhlcmUsIHNvIHdvdWxkIGxvdmUg dG8gaGVhciBmcm9tIFhlbiBjb21tdW5pdHkgb24gdGhpcw0KDQpDdXJyZW50IFdJUCB3aXRoIHRo ZSBmaXhlcyByZXF1ZXN0ZWQgYnkgSnVsaWVuIGFyZSBhdCBbMV06IGNhbiBiZSBhbmQgd2lsbCBi ZSBmb3JjZSBwdXNoZWQNCg0KYXMgd2UgYXJlIHN0aWxsIHdvcmtpbmcgb24gaXQsIGJ1dCBjYW4g Z2l2ZSB5b3UgYW4gaW1wcmVzc2lvbiBvZiB3aGF0IHdlIGhhdmUgYXMgb2Ygbm93DQoNCj4NCj4g VGhlbiB5b3UgY2FuIGhhdmUgcHJlcHJvY2Vzc29ycyBjaGVja3MgaW4gb25lIG9mIHRoZSBoZWFk ZXJzIHN1Y2ggYXM6DQo+DQo+ICNpZiBDT05GSUdfWEVOX0NUUkxfSU5URVJGQUNFX1ZFUlNJT04g PCA0MDcwMQ0KPiAgICAgICNkZWZpbmUgeGVuZXZ0Y2huX29wZW4obCwgZikgeGNfZXZ0Y2huX29w ZW4obCwgZik7DQo+ICNlbHNlDQo+ICAgICAgWFhYDQo+ICNlbmRpZg0KPg0KPg0KPiBBbmQgYWxz byBsaWtlOg0KPg0KPiAjaWYgQ09ORklHX1hFTl9DVFJMX0lOVEVSRkFDRV9WRVJTSU9OIDwgNDA2 MDANCj4NCj4gI2lmbmRlZiBIVk1fSU9SRVFTUlZfQlVGSU9SRVFfQVRPTUlDDQo+ICNkZWZpbmUg SFZNX0lPUkVRU1JWX0JVRklPUkVRX0FUT01JQyAyDQo+ICNlbmRpZg0KPg0KPiAjZW5kaWYNCj4N Cj4NCj4gVGhpcyB3b3JrcyBPSyB0byBoYW5kbGUgZGlmZmVyZW5jZXMgaW4gdGhlIGludGVyZmFj ZSBiZXR3ZWVuIHBhc3QNCj4gdmVyc2lvbnMgb2YgWGVuLiBXaGF0IGFib3V0IGJ1aWxkaW5nIGFu IG9sZGVyIFFFTVUgYWdhaW5zdCBhIG5ldyB2ZXJzaW9uDQo+IG9mIFhlbj8gVGhhdCBpcyBub3Qg Z29pbmcgdG8gd29yayBpZiBzb21ldGhpbmcgY2hhbmdlcyBhZ2FpbiBvbiB0aGUgWGVuDQo+IHNp ZGUuIEhvd2V2ZXIsIGl0IGJlY29tZXMgbXVjaCBlYXNpZXIgdG8gYWRkIHN1cHBvcnQgZm9yIHRo ZSBuZXcgWGVuDQo+IGludGVyZmFjZSBpbiBRRU1VLCBiZWNhdXNlIHlvdSBjYW4gZ28gYW5kIGxv b2sgYXQgdGhhdCBjb21wYXRpYmlsaXR5DQo+IGhlYWRlciBhbmQganVzdCBhZGQgdGhlIHJpZ2h0 ICNlbHNlIFhYWC4gSXQgYWxzbyBtYWtlcyBpdCBjbGVhciB3aGF0DQo+IGludGVyZmFjZXMgYW5k IGRlZmluaXRpb25zIGhhdmUgYmVlbiB1c2VkIHRoYXQgYXJlIHVuc3RhYmxlLg0KPg0KPiBPZiBj b3Vyc2UgaXQgaXMgYmV0dGVyIHRvIHVzZSB0aGUgc3RhYmxlIGludGVyZmFjZXMgd2hlbiBwb3Nz aWJsZSA6LSkNClsxXSBodHRwczovL2dpdGh1Yi5jb20vYW5kcjIwMDAvdS1ib290L3RyZWUvcHZi bG9ja191cHN0cmVhbV92MQ== From xen-devel-bounces@lists.xenproject.org Mon Jun 22 14:23:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 14:23:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNM2-00051q-Ec; Mon, 22 Jun 2020 14:23:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNM0-00051l-PD for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 14:23:20 +0000 X-Inumbo-ID: ebc940bc-b493-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ebc940bc-b493-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 14:23:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jrqxFqIC+BTFC5+kkr7QfOjtcOsp2KVBBk4aYROktng=; b=XjzQoSxUqaxjTz6weSsCiKgxpH glhMT9cWM/7Ll0b9/N/DMGtg/MuKBxdOvoZ+TcY/uTVj8+eZ4C1G7vlDvQqnsfOf05L7bJEx641Cf 2/vgGickwM7Y5WgSRnLbRA/OAmPdebPcO3ZlhUrdgRzuq7toh9OnenfkYsRWsE6i9SIQ=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNLz-0008V3-7l; Mon, 22 Jun 2020 14:23:19 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnNLy-0003Um-WC; Mon, 22 Jun 2020 14:23:19 +0000 Subject: Re: UEFI support in ARM DomUs To: Oleksandr Andrushchenko , Oleksandr Andrushchenko , Julien Grall , Stefano Stabellini References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <17a14578-6fc7-925d-6f69-8b2fcbf40ff3@epam.com> <9d4a6e78-49d3-01c3-251b-6d66f56c2761@xen.org> <424cfbdc-0744-fcf7-5bb4-52aca2357df7@epam.com> From: Julien Grall Message-ID: <0f1e6ee7-3cd9-87ed-f18e-7c135eb9233e@xen.org> Date: Mon, 22 Jun 2020 15:23:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22/06/2020 14:56, Oleksandr Andrushchenko wrote: > > On 6/19/20 4:29 PM, Oleksandr Andrushchenko wrote: >> On 6/19/20 4:15 PM, Julien Grall wrote: >>> >>> >>> On 19/06/2020 14:06, Oleksandr Andrushchenko wrote: >>>> >>>> On 6/19/20 3:59 PM, Julien Grall wrote: >>>>> Hi, >>>>> >>>>> On 19/06/2020 13:51, Oleksandr Andrushchenko wrote: >>>>>> On 6/19/20 3:47 PM, Julien Grall wrote: >>>>>>> They will not be available from the fdt, but you can retrieve them with an hypervisor call (see HVM_PARAM_STORE_PFN, HVM_PARAM_CONSOLE_PFN). >>>>>> Yes, and it used in the relevant pieces of code (hyp calls) >>>>>>> One question though, why do you need to map them in advance? Couldn't you map them on demand? >>>>>> >>>>>> Well, we need to at least estimate the pg_table size so we can reserve and allocate memory later, >>>>> >>>>> Oh, so U-boot doesn't support runtime page-table table allocation. Is that right? >>>> As per my understanding no, we provide a memory map and the tables are allocated beforehand >>> >>> Ok :(. >>> >>>>> >>>>>> >>>>>> so I have to provide memory range from either by coding a constant or looking into the devtree at >>>>>> >>>>>> hypervisor { reg = <>; }. It is a bit tricky though >>>>> >>>>> Looking for a node in the device-tree shouldn't be too difficult given that you have fdt_* available. >>>>> >>>>> However, please not that doesn't refer to the guest magic pages. Instead, it provides a region you can use for mapping the grant-table frames >>>> >>>> Indeed, this is in my case 0x38000000, but the magic is at 0x39000000 >>>> >>>> So, I need the memory range set up beforehand, but I can't as there is no cute way to get that. >>>> >>>> Of course, I can issue a hyp call to get HVM_PARAM_CONSOLE_PFN and use it as the base address, >>>> >>>> but this smells like a hack. I can call other HVM_PARAM_ to get their pfns and set up the memory regions, >>>> >>>> but this looks a bit weird. >>> >>> Why is it weird? In general, you only want to map exactly what you need. Not less, not more. >>> >>> In your situation, you only care about two pages, the console page and the xenstore page. The rest shouldn't be mapped. >> Ok, so I'll try get pfns for HVM_PARAM_CONSOLE_PFN + XENSTORE_PFN_OFFSET via hyp call and map those >>> >>>> I need that constant badly ;) >>> >>> No you don't ;). > > We have managed to make use of the relevant hypercalls to get the PFNs, but for that > > we need to maintain the caches as this happens (the calls) when MMU is not yet > > setup and is in the process of. Glad to hear it works. Yes, that's unfortunately the drawback of using hypercalls with MMU off. But at least you make U-boot more generic :). Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jun 22 14:27:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 14:27:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNQG-0005Hf-3b; Mon, 22 Jun 2020 14:27:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNQE-0005HY-AK for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 14:27:42 +0000 X-Inumbo-ID: 87d9c4e0-b494-11ea-be9b-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 87d9c4e0-b494-11ea-be9b-12813bfff9fa; Mon, 22 Jun 2020 14:27:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WNRA0zhjXm1fdNAIxQSe9Rf2cnK9w/uNmAyFaZ5paFA=; b=U2X0xk96ZjnPE6QM1XTxDqxFnK IQdOy1VjsEqLscVTWQn+NvM+Uj+0jmWlrXNWxcs73vV8O4HSHCN4A5Ge96tdVWENypvwJP8ByZdaa 47V5jaA57EZ2rQOZs/lvvIaBK+NjvSa6NDFw8TJ6BN0LA2e83V3JCimYH5zKhDspvxog=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNQB-00008g-Mg; Mon, 22 Jun 2020 14:27:39 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnNQB-0003fH-GK; Mon, 22 Jun 2020 14:27:39 +0000 Subject: Re: UEFI support in ARM DomUs To: Oleksandr Andrushchenko , Stefano Stabellini , Julien Grall References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> From: Julien Grall Message-ID: <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> Date: Mon, 22 Jun 2020 15:27:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Oleksandr, On 22/06/2020 15:04, Oleksandr Andrushchenko wrote: > On 6/19/20 11:02 PM, Stefano Stabellini wrote: >> On Thu, 18 Jun 2020, Julien Grall wrote: > ifeq ($(CONFIG_XEN),y) > arch-y += -D__XEN_INTERFACE_VERSION__=0x00040d00 > endif > > and we also have Xen 4.13 headers in the U-boot tree. Sorry if this was already asked before. Why do you need to specify __XEN_INTERFACE_VERSION__? > > For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it via > > CFLAGS or something. This can also be done for the location of Xen headers. __XEN_INTERFACE_VERSION__ should work through the CFLAGS. An alternative would be to allow the user to specify through the Kconfig. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jun 22 14:34:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 14:34:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNWM-00067z-UX; Mon, 22 Jun 2020 14:34:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNWM-00067u-DB for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 14:34:02 +0000 X-Inumbo-ID: 67c895e0-b495-11ea-bca7-bc764e2007e4 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (unknown [40.107.14.42]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 67c895e0-b495-11ea-bca7-bc764e2007e4; Mon, 22 Jun 2020 14:33:57 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DOo85M+L+9z5oyyd+xwWwrJlMdVud17kCNV26VKYBVJkUImd0WCvTT+a6pRmsnuVcb8BozPLJ+nq2Ubp6t3uydFbVVXsI04S2sBqDWs8jadYxUSd4lC7JN9R+H/DUdFnwa5RXaCq0f8aN/aiUDgXDJxu8RcK8N6oFgUIXf3J1IFlV32wrh6kT4HYAjQ5aeOz3r4bPwLbeGxNl3RMRgCRTjVDiIklen+h2/G8eogCG9O6AeDgJnx/LeE0WM2yvTMeMqspLTAwmEgTF510c2jMDAsKlx/HVvhgPAtucczvzXlgAtxm3HtID10RkQ4Xic8t/WcQoYUrzn62i5NKn2SBQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W1MVAF7AYJDnpBfewUOntEO3RdJbQ5xhbYNZrtFpTLE=; b=DlTU4pOBGsNvoRQVuA9Ix7pbcSuJvbGv5eopP08VLV6pEXzqGfaqx2epKX2WEaqaRn32+OpqW0E4zsIghNg5X4zDnCYJazi3QFxNSmXqIoT/r84T6d15Yx2JJAUA5XDLlsihjCEZOtKHWC/hW0736rtKybR1SU1lH3eHY83v1HqeyDKbgKdG78SUDTegE+5PNdkleEZPZi4cln/hFUdWr0MSlAEI+XhzMmq7tXxNtGqMxcCoDIg5by5k+4DNc0rw2lX772k4hH3/IS8T5/unL26hZfbgWtA11/fg3BigTovgysB+ZYAsQd41geciq+LMMLQ82eZFVnY112SGd4iTvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W1MVAF7AYJDnpBfewUOntEO3RdJbQ5xhbYNZrtFpTLE=; b=H8Z1QhfZ581m6nShu5xMtBw/K98Bg3ZaY4Bb4VScaFUL+O09YwAcLhOAyH9xzeNvs1C/X5gyZ66V+Cc0vM2Er5ATWlzjSfKqN9bcPKe3kVx7vszGHdZorWJkGX+g8kNgzNjSyXUa7wgEJMAjn4K/f4AY6msv+cX/1u59Ol9/NBdIFplH05KJj2rhiq76+o7+7KbueHGBBlJtNSxoqvaGRxQmJenhFHfSpCw2wqTYTfjrGwtyNjWwrA1vedJT+U8h1nRuUJtbeiEwXtetb3Aqs+/W2Weh9ux4wdpWxVvng8O0kwdVd6YuGGUZud/eG8MbW/zF34qssUoACgyLok5VrA== Received: from VI1PR03MB3998.eurprd03.prod.outlook.com (2603:10a6:803:72::14) by VI1PR03MB6238.eurprd03.prod.outlook.com (2603:10a6:800:13f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Mon, 22 Jun 2020 14:33:54 +0000 Received: from VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4]) by VI1PR03MB3998.eurprd03.prod.outlook.com ([fe80::28ec:3584:94d:27a4%7]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 14:33:53 +0000 From: Oleksandr Andrushchenko To: Julien Grall , Stefano Stabellini , Julien Grall Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAWPDgIAEUtgAgAAGgYCAAAHAgA== Date: Mon, 22 Jun 2020 14:33:53 +0000 Message-ID: <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> In-Reply-To: <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.245.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a8a8e7c-8980-4221-0e14-08d816b94a0b x-ms-traffictypediagnostic: VI1PR03MB6238: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0442E569BC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dGRqQBXJphRu1kADDgr9VLuQDYyDf3hq3bX3OdL2nXng2RJRKsVewzq2XVyV1LUvczPRdJcGshMl/xNjwpg2OAmMFVw/l7o1XimQ7BvPmWtuUyG3koKmzqJmFdpbLCTC8FfZDpATELgZUUpDexf8OmB8fItXwUNcyC0xQIiPr/j9ko4YTGcl3wT6LWjbjKlxZLRq1vM4HHd8IRAFh7tHvyoKk5iSybZParXGswE4m/076Bd0J7nJ1eklUQgrwkAyd6B7OwlVZM5/5zuJKXlM80Ay49Izl5WpOLf9o07+W5vhprlAsxM0/IktM5ekZ/Zp x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR03MB3998.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(346002)(396003)(136003)(39860400002)(316002)(5660300002)(8936002)(36756003)(478600001)(8676002)(31686004)(7416002)(54906003)(6512007)(4326008)(110136005)(66556008)(64756008)(31696002)(26005)(91956017)(76116006)(66476007)(66946007)(66446008)(2616005)(2906002)(186003)(86362001)(71200400001)(55236004)(53546011)(6506007)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: KUYyrZOsG2OCdmIyXganATft7xNx1WM6wXesiHVyXD2Jg+GjXfQQwWUI1b7jQ8JV+y0NjdEHQMQxwlLWIlHxroTVdEO6GAsuspQyn8nMLAHXuJI0v0kOl7wocnINQnc8KMC7AmpDDMYtui9ANynJz7AVmIIv4XPFPbGEz9sEgygIs4AXqyrLIz3nIpuQoVBa8I/1Wlg/TloGOGBxWj/V/BvPE7AHcFPR/XQLy7+whnwaY2wp+eItDcjc8DQpU+P8vVSq+U5D2NV2OEKANE+Tv0GuUzPXVr9T5TBn5NTUV2gaSA+5m4vMNIs/evMGzfNddKry1ejgpy1QRq4jjoRxSffDCV+aqkyUZI8JaGsqCElchNd4E3u32SB34TmLsbIi8iJ2BbL5CVjvg6t9WPpNp0KDZuZsIA8Ba39nrtw1uOHUBdh1u0jCjwGjDX6R75dl3Qfaf8cWihUOfFisjOwqO5I3oAPRuOaCnMDuRdrSdv1DRCoDF5dGDZ41S+3OY6tt Content-Type: text/plain; charset="utf-8" Content-ID: <4B4F707C5A06344B9ED31CE4B55D91A0@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a8a8e7c-8980-4221-0e14-08d816b94a0b X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2020 14:33:53.8195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zbxb5eLMi/KnXF2LsLMiQ8pIujU7BjshSWZ7YKkE2tdL8ioWX4L1wFia0t3vAIVjyl7/f5qSs0oD8x6Vqjn7TyP+uohVzEPmweEgQOwhrmtkeEBzHsEXBlywzfO5N/ga X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB6238 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzIyLzIwIDU6MjcgUE0sIEp1bGllbiBHcmFsbCB3cm90ZToNCj4gSGkgT2xla3NhbmRy LA0KPg0KPiBPbiAyMi8wNi8yMDIwIDE1OjA0LCBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbyB3cm90 ZToNCj4+IE9uIDYvMTkvMjAgMTE6MDIgUE0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4+ PiBPbiBUaHUsIDE4IEp1biAyMDIwLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+PiBpZmVxICgkKENP TkZJR19YRU4pLHkpDQo+PiBhcmNoLXkgKz0gLURfX1hFTl9JTlRFUkZBQ0VfVkVSU0lPTl9fPTB4 MDAwNDBkMDANCj4+IGVuZGlmDQo+Pg0KPj4gYW5kIHdlIGFsc28gaGF2ZSBYZW4gNC4xMyBoZWFk ZXJzIGluIHRoZSBVLWJvb3QgdHJlZS4NCj4NCj4gU29ycnkgaWYgdGhpcyB3YXMgYWxyZWFkeSBh c2tlZCBiZWZvcmUuIFdoeSBkbyB5b3UgbmVlZCB0byBzcGVjaWZ5IF9fWEVOX0lOVEVSRkFDRV9W RVJTSU9OX18/DQoNClRoaXMgaXMgYmVjYXVzZSBvZiBpbmNsdWRlL3hlbi9pbnRlcmZhY2UveGVu LWNvbXBhdC5oOg0KDQojaWYgZGVmaW5lZChfX1hFTl9fKSB8fCBkZWZpbmVkKF9fWEVOX1RPT0xT X18pDQoNCi8qIFhlbiBpcyBidWlsdCB3aXRoIG1hdGNoaW5nIGhlYWRlcnMgYW5kIGltcGxlbWVu dHMgdGhlIGxhdGVzdCBpbnRlcmZhY2UuICovDQojZGVmaW5lIF9fWEVOX0lOVEVSRkFDRV9WRVJT SU9OX18gX19YRU5fTEFURVNUX0lOVEVSRkFDRV9WRVJTSU9OX18NCiNlbGlmICFkZWZpbmVkKF9f WEVOX0lOVEVSRkFDRV9WRVJTSU9OX18pDQovKiBHdWVzdHMgd2hpY2ggZG8gbm90IHNwZWNpZnkg YSB2ZXJzaW9uIGdldCB0aGUgbGVnYWN5IGludGVyZmFjZS4gKi8NCiNkZWZpbmUgX19YRU5fSU5U RVJGQUNFX1ZFUlNJT05fXyAweDAwMDAwMDAwDQojZW5kaWYNCg0KU28sIG9uZSBuZWVkcyB0byBz cGVjaWZ5IHRoZSB2ZXJzaW9uIChRRU1VIGRvZXMgdGhhdCB2aWEgaXRzIGNvbmZpZ3VyZSBzY3Jp cHQgYWZ0ZXINCg0Kc29tZSB0ZXN0cykNCg0KPg0KPj4NCj4+IEZvciB0aGUgZmlyc3QgcGFydCAo X19YRU5fSU5URVJGQUNFX1ZFUlNJT05fXykgSSB0aGluayB3ZSBjYW4gcHJvdmlkZSBpdCB2aWEN Cj4+DQo+PiBDRkxBR1Mgb3Igc29tZXRoaW5nLiBUaGlzIGNhbiBhbHNvIGJlIGRvbmUgZm9yIHRo ZSBsb2NhdGlvbiBvZiBYZW4gaGVhZGVycy4NCj4NCj4gX19YRU5fSU5URVJGQUNFX1ZFUlNJT05f XyBzaG91bGQgd29yayB0aHJvdWdoIHRoZSBDRkxBR1MuIEFuIGFsdGVybmF0aXZlIHdvdWxkIGJl IHRvIGFsbG93IHRoZSB1c2VyIHRvIHNwZWNpZnkgdGhyb3VnaCB0aGUgS2NvbmZpZy4NCg0KWW91 IG1lYW4gc3BlY2lmeWluZyB2aWEgS2NvbmZpZyBzb21ldGhpbmcgbGlrZSAiMHgwMDA0MGQwMCI/ DQoNCkFuZCB3aGF0IGFib3V0IHRoZSBoZWFkZXJzPyBIb3cgd2lsbCB3ZSBwcm92aWRlIHRoZWly IGxvY2F0aW9uIGlmIHdlIGRlY2lkZSBub3QgdG8gaW5jbHVkZSB0aG9zZQ0KDQppbiB0aGUgdHJl ZT8NCg0KPiBDaGVlcnMsDQo+ From xen-devel-bounces@lists.xenproject.org Mon Jun 22 14:36:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 14:36:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNYS-0006Eo-B6; Mon, 22 Jun 2020 14:36:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNYR-0006Ei-Cz for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 14:36:11 +0000 X-Inumbo-ID: b67a2d8e-b495-11ea-be9b-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b67a2d8e-b495-11ea-be9b-12813bfff9fa; Mon, 22 Jun 2020 14:36:10 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id D16A8A2800; Mon, 22 Jun 2020 16:36:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9AE62A27F7; Mon, 22 Jun 2020 16:36:07 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qYy-84ZuC1iK; Mon, 22 Jun 2020 16:36:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id C2A61A2800; Mon, 22 Jun 2020 16:36:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DZEZsAODQqT8; Mon, 22 Jun 2020 16:36:06 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 947E6A27F7; Mon, 22 Jun 2020 16:36:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 7DF262168B; Mon, 22 Jun 2020 16:35:36 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id L0re4ANfyr_d; Mon, 22 Jun 2020 16:35:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id E63B421C2D; Mon, 22 Jun 2020 16:35:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8hth-wQ9UJ3a; Mon, 22 Jun 2020 16:35:30 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id C0D5621BF6; Mon, 22 Jun 2020 16:35:30 +0200 (CEST) Date: Mon, 22 Jun 2020 16:35:30 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> In-Reply-To: <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: RlrguZCOMbAulIfOOXv3zf4lULTvtQ== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisa=C5=82(a): > On 19.06.2020 01:41, Micha=C5=82 Leszczy=C5=84ski wrote: >> + >> + domain_pause(d); >=20 > Who's the intended caller of this interface? You making it a hvm-op > suggests the guest may itself call this. But of course a guest > can't pause itself. If this is supposed to be a tools-only interface, > then you should frame it suitably in the public header and of course > you need to enforce this here (which would e.g. mean you shouldn't > use rcu_lock_domain_by_any_id()). >=20 What should I use instead of rcu_lock_domain_by_and_id()? > Also please take a look at hvm/ioreq.c, which makes quite a bit of > use of domain_pause(). In particular I think you want to acquire > the lock only after having paused the domain. >=20 This domain_pause() will be changed to vcpu_pause(). > Shouldn't you rather remove the MSR from the load list here? >=20 This will be fixed. > Is any of what you do in this switch() actually legitimate without > hvm_set_vmtrace_pt_size() having got called for the guest? From > remarks elsewhere I imply you expect the param that you currently > use to be set upon domain creation time, but at the very least the > potentially big buffer should imo not get allocated up front, but > only when tracing is to actually be enabled. Wait... so you want to allocate these buffers in runtime? Previously we were talking that there is too much runtime logic and these enable/disable hypercalls should be stripped to absolute minimum. >> --- a/xen/include/public/hvm/hvm_op.h >> +++ b/xen/include/public/hvm/hvm_op.h >> @@ -382,6 +382,29 @@ struct xen_hvm_altp2m_op { >> typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; >> DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); >> =20 >> +/* HVMOP_vmtrace: Perform VM tracing related operation */ >> +#define HVMOP_vmtrace 26 >> + >> +#define HVMOP_VMTRACE_INTERFACE_VERSION 0x00000001 >=20 > I'm unconvinced we want to introduce yet another versioned interface. > In any event, as hinted at earlier, this suggests it wants to be a > tools-only interface instead (which, at least for the time being, is > not required to be a stable interface then, but that's also something > we apparently want to move away from, and hence you may better not > try to rely on it not needing to be stable). Ok. I will remove the interface version. >=20 >> +struct xen_hvm_vmtrace_op { >> + /* IN variable */ >> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ >> + uint32_t cmd; >> +/* Enable/disable external vmtrace for given domain */ >> +#define HVMOP_vmtrace_ipt_enable 1 >> +#define HVMOP_vmtrace_ipt_disable 2 >> +#define HVMOP_vmtrace_ipt_get_offset 3 >> + domid_t domain; >> + uint32_t vcpu; >> + uint64_t size; >> + >> + /* OUT variable */ >> + uint64_t offset; >=20 > If this is to be a tools-only interface, please use uint64_aligned_t. >=20 This type is not defined within hvm_op.h header. What should I do about it? > You also want to add an entry to xen/include/xlat.lst and use the > resulting macro to prove that the struct layout is the same for > native and compat callers. Could you tell a little bit more about this? What are "native" and "compat" callers and what is the purpose of this file? Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Mon Jun 22 14:57:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 14:57:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNt0-0008AF-4l; Mon, 22 Jun 2020 14:57:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnNsy-0008AA-6x for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 14:57:24 +0000 X-Inumbo-ID: accec116-b498-11ea-b7bb-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id accec116-b498-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 14:57:22 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Gb07eQDSrBgJ48tHC6dN4aPTaO82hRETLrKWvYtU979mxAG9/fDK9WSNJLl9xGw38Dk+kB++4R vK0LxwC8SUJI3ma8HpvooexB4EShUoUMCUq0j0b3r2Aisyswqi+gAbnX9oDx/Drofso7K2T6aj jqPTv055cS0m+reMGMSiA7USxyEWG866ZQD2XCUWiufzvSitxtHR53Nzq49TKkBIMrmU2g4xoZ BgJGVgDgigIEHX16C8XXralUSFHJ0ktbEkSRIldrC12pYHYhjMa4sdbm5c4XNuXfCEtcVCRq2l li8= X-SBRS: 2.7 X-MesageID: 20849722 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,267,1589256000"; d="scan'208";a="20849722" Date: Mon, 22 Jun 2020 16:56:59 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage Message-ID: <20200622145659.GL735@Air-de-Roger> References: <20200618160403.35199-1-roger.pau@citrix.com> <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> <20200622093123.GI735@Air-de-Roger> <5ad66ef4-9406-f35a-5683-ac4608242dd7@suse.com> <20200622132410.GJ735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 03:51:24PM +0200, Jan Beulich wrote: > On 22.06.2020 15:24, Roger Pau Monné wrote: > > On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote: > >> On 22.06.2020 11:31, Roger Pau Monné wrote: > >>> On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote: > >>>> On 18.06.2020 18:04, Roger Pau Monne wrote: > >>>>> Commit e9aca9470ed86 introduced a regression when avoiding sending > >>>>> IPIs for certain flush operations. Xen page fault handler > >>>>> (spurious_page_fault) relies on blocking interrupts in order to > >>>>> prevent handling TLB flush IPIs and thus preventing other CPUs from > >>>>> removing page tables pages. Switching to assisted flushing avoided such > >>>>> IPIs, and thus can result in pages belonging to the page tables being > >>>>> removed (and possibly re-used) while __page_fault_type is being > >>>>> executed. > >>>>> > >>>>> Force some of the TLB flushes to use IPIs, thus avoiding the assisted > >>>>> TLB flush. Those selected flushes are the page type change (when > >>>>> switching from a page table type to a different one, ie: a page that > >>>>> has been removed as a page table) and page allocation. This sadly has > >>>>> a negative performance impact on the pvshim, as less assisted flushes > >>>>> can be used. > >>>>> > >>>>> Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush > >>>>> using an IPI (flush_tlb_mask_sync). Note that the flag is only > >>>>> meaningfully defined when the hypervisor supports PV mode, as > >>>>> otherwise translated domains are in charge of their page tables and > >>>>> won't share page tables with Xen, thus not influencing the result of > >>>>> page walks performed by the spurious fault handler. > >>>> > >>>> Is this true for shadow mode? If a page shadowing a guest one was > >>>> given back quickly enough to the allocator and then re-used, I think > >>>> the same situation could in principle arise. > >>> > >>> Hm, I think it's not applicable to HVM shadow mode at least, because > >>> CR3 is switched as part of vmentry/vmexit, and the page tables are not > >>> shared between Xen and the guest, so there's no way for a HVM shadow > >>> guest to modify the page-tables while Xen is walking them in > >>> spurious_page_fault (note spurious_page_fault is only called when the > >>> fault happens in non-guest context). > >> > >> I'm afraid I disagree, because of shadow's use of "linear page tables". > > > > You will have to bear with me, but I don't follow. > > > > Could you provide some pointers at how/where the shadow (I assume > > guest controlled) "linear page tables" are used while in Xen > > context? > > See config.h: > > /* Slot 258: linear page table (guest table). */ > #define LINEAR_PT_VIRT_START (PML4_ADDR(258)) > #define LINEAR_PT_VIRT_END (LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) > /* Slot 259: linear page table (shadow table). */ > #define SH_LINEAR_PT_VIRT_START (PML4_ADDR(259)) > #define SH_LINEAR_PT_VIRT_END (SH_LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) > > These linear page tables exist in the Xen page tables at basically > all times as long as a shadow guest's vCPU is in context. They're > there to limit the overhead of accessing guest page tables and > their shadows from inside Xen. Oh, I have to admit I know very little about all this, and I'm not able to find a description of how this is to be used. I think the shadow linear page tables should be per-pCPU, and hence they cannot be modified by the guest while a spurious page fault is being processed? (since the vCPU running on the pCPU is in Xen context). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 15:12:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 15:12:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnO79-0001PL-EJ; Mon, 22 Jun 2020 15:12:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnO77-0001PG-Fz for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 15:12:01 +0000 X-Inumbo-ID: b89b4b66-b49a-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b89b4b66-b49a-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 15:12:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Reply-To:Message-Id:Date:Subject:To:From:Sender:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZkYFftt9zY4NTku9bpwUBXznZU5RfaCO8ptYf1B1Tpg=; b=gpwPDSYlvgpIoB+ZDfRl7vSllG Cbtk42P7qaOswXRNn8Y7754AaBlBPcUcFni+Rs2ehsWamutetM+eJv2Ki+mzLYjXxfofB8zX/2w5g jmm9HAISGSlwc5PA6o3YySx0xFOR3WZ5maYGUxx6so7waJWbRt0hLWuSodx8poO9u6lk=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnO76-0000z5-8V; Mon, 22 Jun 2020 15:12:00 +0000 Received: from 54-240-197-234.amazon.com ([54.240.197.234] helo=CBG-R90WXYV0.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jnO75-00075K-VK; Mon, 22 Jun 2020 15:12:00 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Subject: Xen 4.14 RC3 Date: Mon, 22 Jun 2020 16:11:58 +0100 Message-Id: <20200622151158.109-1-paul@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: xen-devel@lists.xenproject.org, paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi all, Xen 4.14 RC3 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.14.0-rc3 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.14.0-rc3/xen-4.14.0-rc3.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.14.0-rc3/xen-4.14.0-rc3.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (paul@xen.org). As a reminder, there will be a Xen Test Day. Please see the test day schedule at https://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions. Paul Durrant From xen-devel-bounces@lists.xenproject.org Mon Jun 22 15:22:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 15:22:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOH1-0002YR-QZ; Mon, 22 Jun 2020 15:22:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOH0-0002YL-FQ for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 15:22:14 +0000 X-Inumbo-ID: 25a8be72-b49c-11ea-b7bb-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.48]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 25a8be72-b49c-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 15:22:13 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S7VeEIU/iw/QUOM2Ywk//xlvJ3f4GyUi0hVMQvH2fzsvDTfm+cI0RySJr8WEkt1JetBR/4kzJmkTYd5TFBYS+gRjACMhLlguuSbMa7q8jRXt8k0Zx6/6JJZdxexWQTfmrPlveBujRRhr2oAuIXHqFu4mBo2iEMLoG2Xk/sIjAtZ4ssaW4GH9fkW7tdTev01KIuT97OxJsC/1dMc/k85ej2oyldXmDX25spgRSLpTHy4sH88ETfwj+NLz/zz0Kh7lVKrq/z4jYnVJn2Z5w+M3jjmkgauYLujAEaau7ksbcfJA1lrJTC/Cyk8eMgmE9yT+gnlX9KSYFJtfOgXZrqzvxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+PjXg3PzYzzcxJGTITGiqTsNtikdSrALWz0hLC1D5Xc=; b=EjlZpnItQpra6l098mq1AgaHApZibGj89pOBtmK3nkO11DyHPCftviOT6dkFzQVYFDsnLOac4X2nF5iN/5eW3u6BAVRYGdtp/p0RlP/zB7tr57PyNayMn4lCL9+i6azDRc+sRPxTYaDDtgMzqxB37oZSB9NUj1ZcOJ+soJNhwAPpEndCgI9RZE7r/0d57D3Nu1srewhC5hJSQkr93p3dkmBoTZbffMxQ2igx/QVVxLD2uniIG1aS8v/6Q2+mbQncthPG5eeL/KOMgFaaszQDsHbVF9o2EyrHt/w/PIU+31OZYZUVYiPvkx4guIftgmH/YVva9iJzngysrKJ4GxZtRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mysuse.onmicrosoft.com; s=selector1-mysuse-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+PjXg3PzYzzcxJGTITGiqTsNtikdSrALWz0hLC1D5Xc=; b=H6wGgwIBM+YIrgNe11amPkvVDHj26CsdK62YFd5RJ2jWy6worcNrep7kPBaGLv93dF8gbZ8kRNVDfucV/R2tXcjMmotJlhIX/XhW0+adXju6KSXK+AnIhCXQfhK7Xp5X//l05MfOqdmqr1EVBtKzxi2xA+q888cZafb8bN2PQQSFc78KaV1yEpdrQFoGxrBUq2FQEXr29xeBxvjSvl3e6pH7ZItfqHV5jqJ8w4CAN3LIWh6H+bw3C+dXlaGATxki4DuPRpYylgSBfjKAG915kwykZcoqBw+v7cF4fFwG2xD+LB61QhpFjQHLdAhPUyAs4iZ7KDr074aVbJWW8OqnFQ== Authentication-Results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=suse.com; Received: from VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) by VI1PR04MB4432.eurprd04.prod.outlook.com (2603:10a6:803:69::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Mon, 22 Jun 2020 15:22:11 +0000 Received: from VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600]) by VI1PR04MB5600.eurprd04.prod.outlook.com ([fe80::3de3:8e44:3eee:8600%6]) with mapi id 15.20.3109.027; Mon, 22 Jun 2020 15:22:11 +0000 Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <87576264-e7df-2590-f141-351d76baac7a@suse.com> Date: Mon, 22 Jun 2020 17:22:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 In-Reply-To: <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: AM3PR07CA0116.eurprd07.prod.outlook.com (2603:10a6:207:7::26) To VI1PR04MB5600.eurprd04.prod.outlook.com (2603:10a6:803:e7::16) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.156.60.99] (37.24.206.209) by AM3PR07CA0116.eurprd07.prod.outlook.com (2603:10a6:207:7::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.10 via Frontend Transport; Mon, 22 Jun 2020 15:22:10 +0000 X-Originating-IP: [37.24.206.209] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4e8cb101-a90a-4c48-77b6-08d816c008c4 X-MS-TrafficTypeDiagnostic: VI1PR04MB4432: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0442E569BC X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UOseMuJdYqAMwR+KpUxxremwtkdxTRPhi+fSjy9QZvlPeM0k+ZYqy65Npv/mnRp6pkHXLDXcZxoENyOgODcfMCdGWWqThXkBUHXzkCJPDIBqVJrhYNQ+If/EGcCRpdolaUX60fX2dkRLwLeUxhBb86EuN3yQh2lxX4DLOXVPC8yUYAglgfyydJIUDl91eQ7wuNTYgM/3hgP+B5HhkEsRYlr1wZ5CJFLAgt62cz1+fF5uG1MmGvoC6wSUgpLK5SZng8/Io2WiugWLYN0a8WoQz1rpsy94wnfhf9CGIHDNnDo87z/zB955PU9J/Gbkrj5JsoleweSTQb2MvGPfbivcKqL9xklUiV9SsIyB69atGiw2frno3ob3/IfaVsd+gUng X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR04MB5600.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(136003)(396003)(39860400002)(376002)(346002)(7416002)(6486002)(478600001)(26005)(6666004)(6916009)(31696002)(2906002)(5660300002)(8936002)(54906003)(186003)(16576012)(16526019)(316002)(956004)(66476007)(66556008)(2616005)(8676002)(66946007)(4326008)(52116002)(86362001)(83380400001)(36756003)(31686004)(66574015)(53546011)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Nm+7I6cF+WeBbjm7qgrNIVGI0XrQx0ZXV5ZnjCAuavu6k7tk8H35wlWj/w4pIEadM3JimtwYXv7GmeFHRmqwE1A7tylBBPw1pOgQG3z7PxU2viJh3JMh52tKsJTw2Pjq2znNfHscpOhzer812YpnFOF5qvaR4KHLNSM9o25mV7vbkhWWr4q/26jf0HGkJ4vmSCD6IRWtO8ErpXIQjo55mJ9kU6bo6UZRNxXCaFa/sGYDf2g0nszvPiUCr0wUArMOKxEVOkyxT1bRC56CWQYpvSKhU+4E3U1G74kbWgeziieiqcXCLZN7+W2haf+hFDpKfx/3qmk040nfZqF0Q9sXgAuKRLcgQc3yKa5mYemcUYr4i+HFBUa1hqD7Mrpr8lUyw6kurCUCINdumXzNiyPOW8le9004hs8bLvdusFMmtuLJhJj/17cYKcmuGbyNSGGEK1Trbcmlyxe0DwtgXo1pdTrckvhytMQqcp+quLOjS6Y= X-OriginatorOrg: suse.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e8cb101-a90a-4c48-77b6-08d816c008c4 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2020 15:22:11.1099 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: epsE4Zu4VCjMGabGK5MzdDsh46Is0AG5yHcSpyK5132R95mBfytCsh8guTUnD4E3LKSzzCsghcwpTcgtxpbk2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR04MB4432 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 16:35, Michał Leszczyński wrote: > ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisał(a): >> On 19.06.2020 01:41, Michał Leszczyński wrote: >>> + >>> + domain_pause(d); >> >> Who's the intended caller of this interface? You making it a hvm-op >> suggests the guest may itself call this. But of course a guest >> can't pause itself. If this is supposed to be a tools-only interface, >> then you should frame it suitably in the public header and of course >> you need to enforce this here (which would e.g. mean you shouldn't >> use rcu_lock_domain_by_any_id()). >> > > What should I use instead of rcu_lock_domain_by_and_id()? Please take a look at the header where its declaration lives. It's admittedly not the usual thing in Xen, but there are even comments describing the differences between the four related by-id functions. I guess rcu_lock_live_remote_domain_by_id() is the one you want to use, despite being puzzled by there being surprisingly little uses elsewhere. >> Also please take a look at hvm/ioreq.c, which makes quite a bit of >> use of domain_pause(). In particular I think you want to acquire >> the lock only after having paused the domain. > > This domain_pause() will be changed to vcpu_pause(). And you understand that my comment then still applies? >> Shouldn't you rather remove the MSR from the load list here? > > This will be fixed. Thanks for trimming your reply, but I think you've gone too far: Context should still be such that one can see what the comments are about without having to go back to the original mail. Please try to find some middle ground. >> Is any of what you do in this switch() actually legitimate without >> hvm_set_vmtrace_pt_size() having got called for the guest? From >> remarks elsewhere I imply you expect the param that you currently >> use to be set upon domain creation time, but at the very least the >> potentially big buffer should imo not get allocated up front, but >> only when tracing is to actually be enabled. > > Wait... so you want to allocate these buffers in runtime? > Previously we were talking that there is too much runtime logic > and these enable/disable hypercalls should be stripped to absolute > minimum. Basic arrangements can be made at domain creation time. I don't think though that it would be a good use of memory if you allocated perhaps many gigabytes of memory just for possibly wanting to enable tracing on a guest. >>> +struct xen_hvm_vmtrace_op { >>> + /* IN variable */ >>> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ >>> + uint32_t cmd; >>> +/* Enable/disable external vmtrace for given domain */ >>> +#define HVMOP_vmtrace_ipt_enable 1 >>> +#define HVMOP_vmtrace_ipt_disable 2 >>> +#define HVMOP_vmtrace_ipt_get_offset 3 >>> + domid_t domain; >>> + uint32_t vcpu; >>> + uint64_t size; >>> + >>> + /* OUT variable */ >>> + uint64_t offset; >> >> If this is to be a tools-only interface, please use uint64_aligned_t. >> > > This type is not defined within hvm_op.h header. What should I do about it? It gets defined by xen.h, so should be available here. Its definitions live in a #if defined(__XEN__) || defined(__XEN_TOOLS__) section, which is what I did recommend to put your interface in as well. Unless you want this to be exposed to the guest itself, at which point further constraints would arise. >> You also want to add an entry to xen/include/xlat.lst and use the >> resulting macro to prove that the struct layout is the same for >> native and compat callers. > > Could you tell a little bit more about this? What are "native" and > "compat" callers and what is the purpose of this file? A native caller is one whose bitness matches Xen's, i.e. for x86 a guest running in 64-bit mode. A compat guest is one running in 32-bit mode. Interface structure layout, at least for historical reasons, can differ between the two. If it does, these structures need translation. In the case here the layouts look to match, which we still want to be verified at build time. If you add a suitable line to xlat.lst starting with a ?, a macro will be generated that you can then invoke somewhere near the code that actually handles this sub-hypercall. See e.g. the top of xen/common/hypfs.c for a relatively recent addition of such. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 15:31:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 15:31:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOPK-0003Wg-R2; Mon, 22 Jun 2020 15:30:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOPJ-0003Wb-Hm for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 15:30:49 +0000 X-Inumbo-ID: 58b128d0-b49d-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 58b128d0-b49d-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 15:30:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 16206C1A2; Mon, 22 Jun 2020 15:30:47 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200618160403.35199-1-roger.pau@citrix.com> <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> <20200622093123.GI735@Air-de-Roger> <5ad66ef4-9406-f35a-5683-ac4608242dd7@suse.com> <20200622132410.GJ735@Air-de-Roger> <20200622145659.GL735@Air-de-Roger> From: Jan Beulich Message-ID: <9848eebc-f904-cb2f-b5e1-499f5ce6994b@suse.com> Date: Mon, 22 Jun 2020 17:30:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200622145659.GL735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 16:56, Roger Pau Monné wrote: > On Mon, Jun 22, 2020 at 03:51:24PM +0200, Jan Beulich wrote: >> On 22.06.2020 15:24, Roger Pau Monné wrote: >>> On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote: >>>> On 22.06.2020 11:31, Roger Pau Monné wrote: >>>>> On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote: >>>>>> On 18.06.2020 18:04, Roger Pau Monne wrote: >>>>>>> Commit e9aca9470ed86 introduced a regression when avoiding sending >>>>>>> IPIs for certain flush operations. Xen page fault handler >>>>>>> (spurious_page_fault) relies on blocking interrupts in order to >>>>>>> prevent handling TLB flush IPIs and thus preventing other CPUs from >>>>>>> removing page tables pages. Switching to assisted flushing avoided such >>>>>>> IPIs, and thus can result in pages belonging to the page tables being >>>>>>> removed (and possibly re-used) while __page_fault_type is being >>>>>>> executed. >>>>>>> >>>>>>> Force some of the TLB flushes to use IPIs, thus avoiding the assisted >>>>>>> TLB flush. Those selected flushes are the page type change (when >>>>>>> switching from a page table type to a different one, ie: a page that >>>>>>> has been removed as a page table) and page allocation. This sadly has >>>>>>> a negative performance impact on the pvshim, as less assisted flushes >>>>>>> can be used. >>>>>>> >>>>>>> Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush >>>>>>> using an IPI (flush_tlb_mask_sync). Note that the flag is only >>>>>>> meaningfully defined when the hypervisor supports PV mode, as >>>>>>> otherwise translated domains are in charge of their page tables and >>>>>>> won't share page tables with Xen, thus not influencing the result of >>>>>>> page walks performed by the spurious fault handler. >>>>>> >>>>>> Is this true for shadow mode? If a page shadowing a guest one was >>>>>> given back quickly enough to the allocator and then re-used, I think >>>>>> the same situation could in principle arise. >>>>> >>>>> Hm, I think it's not applicable to HVM shadow mode at least, because >>>>> CR3 is switched as part of vmentry/vmexit, and the page tables are not >>>>> shared between Xen and the guest, so there's no way for a HVM shadow >>>>> guest to modify the page-tables while Xen is walking them in >>>>> spurious_page_fault (note spurious_page_fault is only called when the >>>>> fault happens in non-guest context). >>>> >>>> I'm afraid I disagree, because of shadow's use of "linear page tables". >>> >>> You will have to bear with me, but I don't follow. >>> >>> Could you provide some pointers at how/where the shadow (I assume >>> guest controlled) "linear page tables" are used while in Xen >>> context? >> >> See config.h: >> >> /* Slot 258: linear page table (guest table). */ >> #define LINEAR_PT_VIRT_START (PML4_ADDR(258)) >> #define LINEAR_PT_VIRT_END (LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) >> /* Slot 259: linear page table (shadow table). */ >> #define SH_LINEAR_PT_VIRT_START (PML4_ADDR(259)) >> #define SH_LINEAR_PT_VIRT_END (SH_LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) >> >> These linear page tables exist in the Xen page tables at basically >> all times as long as a shadow guest's vCPU is in context. They're >> there to limit the overhead of accessing guest page tables and >> their shadows from inside Xen. > > Oh, I have to admit I know very little about all this, and I'm not > able to find a description of how this is to be used. > > I think the shadow linear page tables should be per-pCPU, and hence > they cannot be modified by the guest while a spurious page fault is > being processed? (since the vCPU running on the pCPU is in Xen > context). A guest would have for some linear address e.g. vCR3 -> G4 -> G3 -> G2 -> G1 visible to some random set of its CPUs (i.e. the same CR3 can be in use by multiple vCPU-s). This will then have shadows like this: pCR3 -> S4 -> S3 -> S2 -> S1 The G4 page gets hooked up into LINEAR_PT (i.e. becomes an L3 page) for all vCPU-s that have this very CR3 active. Same goes for S4 and SH_LINEAR_PT respectively. Afaik shadows of guest page tables also don't get created on a per-pCPU basis - a page table either has a shadow, or it doesn't. Hence afaict page tables mapped through these facilities (and reachable while in Xen) can very well be modified "behind our backs". Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 15:31:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 15:31:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOPZ-0003Xw-3H; Mon, 22 Jun 2020 15:31:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOPX-0003X1-Su for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 15:31:04 +0000 X-Inumbo-ID: 60416c0e-b49d-11ea-bca7-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 60416c0e-b49d-11ea-bca7-bc764e2007e4; Mon, 22 Jun 2020 15:31:01 +0000 (UTC) Received: from webmail.moloch.sk (w3-s.a.lucina.net [62.176.169.73]) by smtp.lucina.net (Postfix) with ESMTPSA id 2B5BA122804; Mon, 22 Jun 2020 17:31:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592839860; bh=Xws8g1Wi5dE+ZjqV+LiybhYjyilm/86GEW8v+QkfRc4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pnLlAt8Do/2GfKL/HAydudr90+ZlKTYedk1C+x8MHzL7kIkx6dvtQC+5eJKDqQG64 3hX1OUCi3hgX/4ZbWmnq2e4mlw8XR0rn87KW2c9sfo5JLObxYf/VdkkdZwsBLEO6F4 cLxMpoIXApI2U87il2HjNj5Z+nD4pSc1fen+3IA9OJeH6b6Shugx0PId04RnY7vOEW GmpyQptkfw64HDbSFgopbszgq6rXhAIMywSGDsFXA02mlFm4vlyjBNdtacgJa2uigp 041BCTREpK2FXfdqmO/nk0zpKVxEF6atSVqfcfHKT5EF8nbkDz+nzSsR7jDXMcZy6C 7PymPZbi1Altw== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 22 Jun 2020 17:31:00 +0200 From: Martin Lucina To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Re: Event delivery and "domain blocking" on PVHv2 In-Reply-To: <20200622135853.GK735@Air-de-Roger> References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> <20200619165426.GD735@Air-de-Roger> <20200619174143.GE735@Air-de-Roger> <7ed4a5f98b3002f3233e02d5ce803ef0@lucina.net> <20200622135853.GK735@Air-de-Roger> Message-ID: <745e4ac251b146480b2c6d6afbf5f34a@lucina.net> X-Sender: martin@lucina.net User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-22 15:58, Roger Pau Monné wrote: > On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote: >> Aha! Thank you for pointing this out. I think you may be right, but >> this >> should be possible without doing the demuxing in interrupt context. > > If you don't do the demuxing in the interrupt context (ie: making the > interrupt handler a noop), then you don't likely need such interrupt > anyway? I need the/an interrupt to wake the VCPU from HLT state if we went to sleep. > >> How about this arrangement, which appears to work for me; no hangs I >> can see >> so far and domU survives ping -f fine with no packet loss: >> >> CAMLprim value >> mirage_xen_evtchn_block_domain(value v_deadline) >> { >> struct vcpu_info *vi = VCPU0_INFO(); >> solo5_time_t deadline = Int64_val(v_deadline); >> >> if (solo5_clock_monotonic() < deadline) { >> __asm__ __volatile__ ("cli" : : : "memory"); >> if (vi->evtchn_upcall_pending) { >> __asm__ __volatile__ ("sti"); >> } >> else { >> hypercall_set_timer_op(deadline); > > What if you set a deadline so close that evtchn_upcall_pending gets > set by Xen here and the interrupt is injected? You would execute the > noop handler and just hlt, and could likely end up in the same blocked > situation as before? Why would an interrupt be injected here? Doesn't the immediately preceding "cli" disable that? Or perhaps I need to do a PV/HVM hybrid and set vi->evtchn_upcall_mask just before the cli, and clear it after the sti? >> i.e. Always go to sleep with interrupts disabled, but before doing so >> re-check that no events have become pending since the last time >> evtchn_demux_pending() was called. This holds, since the only thing >> that >> sets vi->evtchn_upcall_pending is Xen, and the only thing that clears >> it is >> evtchn_demux_pending(). >> >> Right? > > TBH this is a hard model to get right, I think your best bet at > attempting something along this lines is to forget about using the > event channel interrupt and instead use SCHEDOP_poll. You could do > something like (written in pure C as I have no idea of the ocaml > bindings): > [SCHEDOP_poll code snipped] Thanks for the suggestion. This brings us full-circle -- I found [1] and [2] way back from 2013 when Mirage/Xen was initially using SCHEDOP_poll and then switched to the current interrupts + SCHEDOP_block approach. Part of the motivation for the change at the time was to allow waiting on/servicing more than 128 ports (the limit for SCHEDOP_poll). I doubt anyone wants to do that these days, but it still makes me a bit reluctant to change back to SCHEDOP_poll. >> In an attempt to understand why the original PV code worked I re-read >> the PV >> Mini-OS block_domain code again and realised that I had entirely >> missed one >> part of its behaviour, which is that it intends[*] to run with >> interrupts/upcalls disabled *all* the time and relies on SCHEDOP_block >> atomically re-enabling them and triggering an upcall before returning >> (PV) >> or "briefly enabling interrupts to allow handlers to run" (HVM). We're >> doing >> the inverse, but our behaviour matches my mental model of how things >> should >> work. > > Not really IMO, as SCHEDOP_block is a single 'instruction' from a > guest PoV that does the enabling of interrupts and returns if there > are pending ones. Indeed and this is exactly the operation I need in the HVM world with the current model. > Also SCHEDOP_block is not exactly the same on HVM, as it just checks > for pending vectors to inject, but not for pending event channels. ... well, I don't want to use SCHEDOP_block anyway since that is not possible on ARM, and I would like to keep the code at least "portable with not too much effort". So there should be a non-racy "HVM way" to do this? > HVM you cannot call hlt with interrupts disabled, or the vCPU will be > taken down. > > There are quite a lot of subtle differences between PV and HVM in this > regard, and I think the best approach would be to use SCHEDOP_poll in > order to implement the kind of model you describe. I can see that now. The interactions between the "virtual hardware" (interrupt delivery, VCPU IF) and "PV" parts (event delivery, masking) are hard to understand for me, yet the two are intertwined in the way HVM works :-( Coming back to your earlier suggestion of moving the event demuxing (but not the handling) into the upcall interrupt handler itself, perhaps that approach is still worth investigating in combination with re-working the OCaml side array view of pending events, or at least ensuring that atomic operations are used since it would now be updated asynchronously. Martin [1] https://lists.cam.ac.uk/pipermail/cl-mirage/2013-September/msg00053.html [2] https://github.com/mirage/mirage-platform/pull/58 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 15:36:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 15:36:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOUW-0003p5-T8; Mon, 22 Jun 2020 15:36:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOUV-0003oZ-MU for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 15:36:11 +0000 X-Inumbo-ID: 15868a2c-b49e-11ea-bea5-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 15868a2c-b49e-11ea-bea5-12813bfff9fa; Mon, 22 Jun 2020 15:36:05 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DE694C1D3; Mon, 22 Jun 2020 15:36:03 +0000 (UTC) Subject: Re: Event delivery and "domain blocking" on PVHv2 To: Martin Lucina References: <62479d08f7650c22678d7a86851eafc4@lucina.net> <5865159c-4190-e841-8020-7a4f3cf0fc24@citrix.com> <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> <20200619165426.GD735@Air-de-Roger> <20200619174143.GE735@Air-de-Roger> <7ed4a5f98b3002f3233e02d5ce803ef0@lucina.net> <20200622135853.GK735@Air-de-Roger> <745e4ac251b146480b2c6d6afbf5f34a@lucina.net> From: Jan Beulich Message-ID: <7667cd25-238f-9822-f560-9f507baab5c3@suse.com> Date: Mon, 22 Jun 2020 17:36:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <745e4ac251b146480b2c6d6afbf5f34a@lucina.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 17:31, Martin Lucina wrote: > On 2020-06-22 15:58, Roger Pau Monné wrote: >> On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote: >>> How about this arrangement, which appears to work for me; no hangs I >>> can see >>> so far and domU survives ping -f fine with no packet loss: >>> >>> CAMLprim value >>> mirage_xen_evtchn_block_domain(value v_deadline) >>> { >>> struct vcpu_info *vi = VCPU0_INFO(); >>> solo5_time_t deadline = Int64_val(v_deadline); >>> >>> if (solo5_clock_monotonic() < deadline) { >>> __asm__ __volatile__ ("cli" : : : "memory"); >>> if (vi->evtchn_upcall_pending) { >>> __asm__ __volatile__ ("sti"); >>> } >>> else { >>> hypercall_set_timer_op(deadline); >> >> What if you set a deadline so close that evtchn_upcall_pending gets >> set by Xen here and the interrupt is injected? You would execute the >> noop handler and just hlt, and could likely end up in the same blocked >> situation as before? > > Why would an interrupt be injected here? Doesn't the immediately > preceding > "cli" disable that? > > Or perhaps I need to do a PV/HVM hybrid and set vi->evtchn_upcall_mask > just > before the cli, and clear it after the sti? evtchn_upcall_mask is a strictly PV-only thing. See e.g. the code comment in hvm_set_callback_irq_level(). Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:03:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:03:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOur-00072a-6d; Mon, 22 Jun 2020 16:03:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnOup-00072V-UO for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:03:23 +0000 X-Inumbo-ID: e55bc25a-b4a1-11ea-bb8b-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e55bc25a-b4a1-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 16:03:22 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7987AA27EB; Mon, 22 Jun 2020 18:03:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 6351DA27C8; Mon, 22 Jun 2020 18:03:20 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id kj1vaCdaXmpD; Mon, 22 Jun 2020 18:03:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id AD82AA27EB; Mon, 22 Jun 2020 18:03:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZkLwt0f8AdBS; Mon, 22 Jun 2020 18:03:19 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7E891A27C8; Mon, 22 Jun 2020 18:03:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 656E121B03; Mon, 22 Jun 2020 18:02:49 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id PeRZeNtTH-X1; Mon, 22 Jun 2020 18:02:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 9B70F219DB; Mon, 22 Jun 2020 18:02:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hpgL1geaYLMQ; Mon, 22 Jun 2020 18:02:43 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 7129C21999; Mon, 22 Jun 2020 18:02:43 +0200 (CEST) Date: Mon, 22 Jun 2020 18:02:43 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> In-Reply-To: <87576264-e7df-2590-f141-351d76baac7a@suse.com> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: hAM9A3NcvqmPiUmz43AEWAK5kVI4oQ== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisa=C5=82(a): > On 22.06.2020 16:35, Micha=C5=82 Leszczy=C5=84ski wrote: >> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisa=C5=82(a)= : >>> On 19.06.2020 01:41, Micha=C5=82 Leszczy=C5=84ski wrote: >>>> + >>>> + domain_pause(d); >>> >>> Who's the intended caller of this interface? You making it a hvm-op >>> suggests the guest may itself call this. But of course a guest >>> can't pause itself. If this is supposed to be a tools-only interface, >>> then you should frame it suitably in the public header and of course >>> you need to enforce this here (which would e.g. mean you shouldn't >>> use rcu_lock_domain_by_any_id()). >>> >>=20 >> What should I use instead of rcu_lock_domain_by_and_id()? >=20 > Please take a look at the header where its declaration lives. It's > admittedly not the usual thing in Xen, but there are even comments > describing the differences between the four related by-id functions. > I guess rcu_lock_live_remote_domain_by_id() is the one you want to > use, despite being puzzled by there being surprisingly little uses > elsewhere. >=20 Ok, I will correct this. >>> Also please take a look at hvm/ioreq.c, which makes quite a bit of >>> use of domain_pause(). In particular I think you want to acquire >>> the lock only after having paused the domain. >>=20 >> This domain_pause() will be changed to vcpu_pause(). >=20 > And you understand that my comment then still applies? If you mean that we should first call vcpu_pause() and then acquire spinlock, then yes, this will be corrected in v3. >>> Is any of what you do in this switch() actually legitimate without >>> hvm_set_vmtrace_pt_size() having got called for the guest? From >>> remarks elsewhere I imply you expect the param that you currently >>> use to be set upon domain creation time, but at the very least the >>> potentially big buffer should imo not get allocated up front, but >>> only when tracing is to actually be enabled. >>=20 >> Wait... so you want to allocate these buffers in runtime? >> Previously we were talking that there is too much runtime logic >> and these enable/disable hypercalls should be stripped to absolute >> minimum. >=20 > Basic arrangements can be made at domain creation time. I don't > think though that it would be a good use of memory if you > allocated perhaps many gigabytes of memory just for possibly > wanting to enable tracing on a guest. >=20 >From our previous conversations I thought that you want to have as much logic moved to the domain creation as possible. Thus, a parameter "vmtrace_pt_size" was introduced. By default it's zero (=3D disabled), if you set it to a non-zero value, then trace buffers of given size will be allocated for the domain and you have possibility to use ipt_enable/ipt_disable at any moment. This way the runtime logic is as thin as possible. I assume user knows in advance whether he/she would want to use external monitoring with IPT or not. It's also not "many gigabytes". In most use cases a buffer of 16/32/64 MB would suffice, I think. If we want to fall back to the scenario where the trace buffer is allocated dynamically, then we basically get back to patch v1 implementation. >>>> +struct xen_hvm_vmtrace_op { >>>> + /* IN variable */ >>>> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ >>>> + uint32_t cmd; >>>> +/* Enable/disable external vmtrace for given domain */ >>>> +#define HVMOP_vmtrace_ipt_enable 1 >>>> +#define HVMOP_vmtrace_ipt_disable 2 >>>> +#define HVMOP_vmtrace_ipt_get_offset 3 >>>> + domid_t domain; >>>> + uint32_t vcpu; >>>> + uint64_t size; >>>> + >>>> + /* OUT variable */ >>>> + uint64_t offset; >>> >>> If this is to be a tools-only interface, please use uint64_aligned_t. >>> >>=20 >> This type is not defined within hvm_op.h header. What should I do about = it? >=20 > It gets defined by xen.h, so should be available here. Its > definitions live in a >=20 > #if defined(__XEN__) || defined(__XEN_TOOLS__) >=20 > section, which is what I did recommend to put your interface in > as well. Unless you want this to be exposed to the guest itself, > at which point further constraints would arise. >=20 >>> You also want to add an entry to xen/include/xlat.lst and use the >>> resulting macro to prove that the struct layout is the same for >>> native and compat callers. >>=20 >> Could you tell a little bit more about this? What are "native" and >> "compat" callers and what is the purpose of this file? >=20 > A native caller is one whose bitness matches Xen's, i.e. for x86 > a guest running in 64-bit mode. A compat guest is one running in > 32-bit mode. Interface structure layout, at least for historical > reasons, can differ between the two. If it does, these > structures need translation. In the case here the layouts look > to match, which we still want to be verified at build time. If > you add a suitable line to xlat.lst starting with a ?, a macro > will be generated that you can then invoke somewhere near the > code that actually handles this sub-hypercall. See e.g. the top > of xen/common/hypfs.c for a relatively recent addition of such. >=20 Thanks for this explanation, I will try to address this. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:09:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:09:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnP0h-0007IZ-T8; Mon, 22 Jun 2020 16:09:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnP0g-0007IU-LO for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:09:26 +0000 X-Inumbo-ID: bd055ae0-b4a2-11ea-bb8b-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bd055ae0-b4a2-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 16:09:24 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: tDwExkz/82tywebeocbKJhBdFN3tfWzBkUEjqD0yrjau6Dgh72pmX88KugfvDvdOjp7SHWf2MZ DjE0YoP9SpfZ2YIIj4q+jIBvoZMLpS+qnEF4WLe1//t1s+UzNqmfgUaQC0x/Gf1si2lGDUo6Kh fsrbykdyUi5wlIrRUBxugyjoLSDc1Gf84PoP8UQx0hqD3VoD6rkImYBRzfPv0PDkWW9OoeyWvN 9Eqlwo5235qYcwh060Q5TVEOI+4k9xuK+CYExK3wgMgnbMtBqte8iZVASFZOlvvtY+uEjo2SC6 jmw= X-SBRS: 2.7 X-MesageID: 20648870 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,267,1589256000"; d="scan'208";a="20648870" Date: Mon, 22 Jun 2020 18:09:16 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Martin Lucina Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200622160916.GM735@Air-de-Roger> References: <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> <20200619165426.GD735@Air-de-Roger> <20200619174143.GE735@Air-de-Roger> <7ed4a5f98b3002f3233e02d5ce803ef0@lucina.net> <20200622135853.GK735@Air-de-Roger> <745e4ac251b146480b2c6d6afbf5f34a@lucina.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <745e4ac251b146480b2c6d6afbf5f34a@lucina.net> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote: > On 2020-06-22 15:58, Roger Pau Monné wrote: > > On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote: > > > Aha! Thank you for pointing this out. I think you may be right, but > > > this > > > should be possible without doing the demuxing in interrupt context. > > > > If you don't do the demuxing in the interrupt context (ie: making the > > interrupt handler a noop), then you don't likely need such interrupt > > anyway? > > I need the/an interrupt to wake the VCPU from HLT state if we went to sleep. > > > > > > How about this arrangement, which appears to work for me; no hangs I > > > can see > > > so far and domU survives ping -f fine with no packet loss: > > > > > > CAMLprim value > > > mirage_xen_evtchn_block_domain(value v_deadline) > > > { > > > struct vcpu_info *vi = VCPU0_INFO(); > > > solo5_time_t deadline = Int64_val(v_deadline); > > > > > > if (solo5_clock_monotonic() < deadline) { > > > __asm__ __volatile__ ("cli" : : : "memory"); > > > if (vi->evtchn_upcall_pending) { > > > __asm__ __volatile__ ("sti"); > > > } > > > else { > > > hypercall_set_timer_op(deadline); > > > > What if you set a deadline so close that evtchn_upcall_pending gets > > set by Xen here and the interrupt is injected? You would execute the > > noop handler and just hlt, and could likely end up in the same blocked > > situation as before? > > Why would an interrupt be injected here? Doesn't the immediately preceding > "cli" disable that? Well, I mean between the sti and the hlt instruction. I think there's always a window for a race here, and that's the reason for having SCHEDOP_block (see comment referring to avoiding a "wakeup waiting" race). > Or perhaps I need to do a PV/HVM hybrid and set vi->evtchn_upcall_mask just > before the cli, and clear it after the sti? I think SCHEDOP_block is broken on HVM, as as Jan points out evtchn_upcall_mask is not used on HVM (we should really have a comment about this in xen.h). So that hypercall is no longer useful to avoid wakeup waiting races. > > > i.e. Always go to sleep with interrupts disabled, but before doing so > > > re-check that no events have become pending since the last time > > > evtchn_demux_pending() was called. This holds, since the only thing > > > that > > > sets vi->evtchn_upcall_pending is Xen, and the only thing that > > > clears it is > > > evtchn_demux_pending(). > > > > > > Right? > > > > TBH this is a hard model to get right, I think your best bet at > > attempting something along this lines is to forget about using the > > event channel interrupt and instead use SCHEDOP_poll. You could do > > something like (written in pure C as I have no idea of the ocaml > > bindings): > > [SCHEDOP_poll code snipped] > > Thanks for the suggestion. This brings us full-circle -- I found [1] and > [2] way back from 2013 when Mirage/Xen was initially using SCHEDOP_poll > and then switched to the current interrupts + SCHEDOP_block approach. > > Part of the motivation for the change at the time was to allow waiting > on/servicing more than 128 ports (the limit for SCHEDOP_poll). I doubt > anyone wants to do that these days, but it still makes me a bit reluctant > to change back to SCHEDOP_poll. Right, Mirage/Xen being single processor it's not likely to use more than 128 event channels, but I can understand the desire to not be limited by that amount. > > > In an attempt to understand why the original PV code worked I > > > re-read the PV > > > Mini-OS block_domain code again and realised that I had entirely > > > missed one > > > part of its behaviour, which is that it intends[*] to run with > > > interrupts/upcalls disabled *all* the time and relies on SCHEDOP_block > > > atomically re-enabling them and triggering an upcall before > > > returning (PV) > > > or "briefly enabling interrupts to allow handlers to run" (HVM). > > > We're doing > > > the inverse, but our behaviour matches my mental model of how things > > > should > > > work. > > > > Not really IMO, as SCHEDOP_block is a single 'instruction' from a > > guest PoV that does the enabling of interrupts and returns if there > > are pending ones. > > Indeed and this is exactly the operation I need in the HVM world with the > current model. Another option would be to consider re-purposing SCHEDOP_block for HVM so it does a sti on behalf of the guest and then checks for pending interrupts to inject. > > Also SCHEDOP_block is not exactly the same on HVM, as it just checks > > for pending vectors to inject, but not for pending event channels. > > ... well, I don't want to use SCHEDOP_block anyway since that is not > possible > on ARM, and I would like to keep the code at least "portable with not too > much effort". So there should be a non-racy "HVM way" to do this? One solution (albeit it would be slightly crappy IMO) is to make sure the timer is always fully handled in interrupt context, so that you _never_ call hlt with a timer event pending. That way you are always guaranteed to be woken up. > > HVM you cannot call hlt with interrupts disabled, or the vCPU will be > > taken down. > > > > There are quite a lot of subtle differences between PV and HVM in this > > regard, and I think the best approach would be to use SCHEDOP_poll in > > order to implement the kind of model you describe. > > I can see that now. The interactions between the "virtual hardware" > (interrupt delivery, VCPU IF) and "PV" parts (event delivery, masking) are > hard to understand for me, yet the two are intertwined in the way HVM > works :-( > > Coming back to your earlier suggestion of moving the event demuxing (but not > the handling) into the upcall interrupt handler itself, perhaps that > approach > is still worth investigating in combination with re-working the OCaml side > array > view of pending events, or at least ensuring that atomic operations are used > since it would now be updated asynchronously. I assume you must be doing something similar for KVM in Solo5, where you handle (at least certain) interrupts in interrupt context, or else the same issues would arise? Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:17:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:17:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnP82-0008Hm-UA; Mon, 22 Jun 2020 16:17:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnP81-0008Hh-A3 for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:17:01 +0000 X-Inumbo-ID: ccabafca-b4a3-11ea-bea8-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ccabafca-b4a3-11ea-bea8-12813bfff9fa; Mon, 22 Jun 2020 16:16:59 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9AEDBB616; Mon, 22 Jun 2020 16:16:58 +0000 (UTC) Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Andrew Cooper References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> Date: Mon, 22 Jun 2020 18:16:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 18:02, Michał Leszczyński wrote: > ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisał(a): >> On 22.06.2020 16:35, Michał Leszczyński wrote: >>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisał(a): >>>> Is any of what you do in this switch() actually legitimate without >>>> hvm_set_vmtrace_pt_size() having got called for the guest? From >>>> remarks elsewhere I imply you expect the param that you currently >>>> use to be set upon domain creation time, but at the very least the >>>> potentially big buffer should imo not get allocated up front, but >>>> only when tracing is to actually be enabled. >>> >>> Wait... so you want to allocate these buffers in runtime? >>> Previously we were talking that there is too much runtime logic >>> and these enable/disable hypercalls should be stripped to absolute >>> minimum. >> >> Basic arrangements can be made at domain creation time. I don't >> think though that it would be a good use of memory if you >> allocated perhaps many gigabytes of memory just for possibly >> wanting to enable tracing on a guest. >> > > From our previous conversations I thought that you want to have > as much logic moved to the domain creation as possible. > > Thus, a parameter "vmtrace_pt_size" was introduced. By default it's > zero (= disabled), if you set it to a non-zero value, then trace buffers > of given size will be allocated for the domain and you have possibility > to use ipt_enable/ipt_disable at any moment. > > This way the runtime logic is as thin as possible. I assume user knows > in advance whether he/she would want to use external monitoring with IPT > or not. Andrew - I think you requested movement to domain_create(). Could you clarify if indeed you mean to also allocate the big buffers this early? > It's also not "many gigabytes". In most use cases a buffer of 16/32/64 MB > would suffice, I think. But that one such buffer per vCPU, isn't it? Plus these buffers need to be physically contiguous, which is an additional possibly severe constraint. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:20:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:20:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPBc-0000eI-H9; Mon, 22 Jun 2020 16:20:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPBb-0000dk-3X for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:20:43 +0000 X-Inumbo-ID: 4e02af10-b4a4-11ea-beaa-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4e02af10-b4a4-11ea-beaa-12813bfff9fa; Mon, 22 Jun 2020 16:20:36 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B120DC220; Mon, 22 Jun 2020 16:20:35 +0000 (UTC) Subject: Re: Event delivery and "domain blocking" on PVHv2 To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> <20200619165426.GD735@Air-de-Roger> <20200619174143.GE735@Air-de-Roger> <7ed4a5f98b3002f3233e02d5ce803ef0@lucina.net> <20200622135853.GK735@Air-de-Roger> <745e4ac251b146480b2c6d6afbf5f34a@lucina.net> <20200622160916.GM735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Mon, 22 Jun 2020 18:20:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200622160916.GM735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Martin Lucina , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 18:09, Roger Pau Monné wrote: > On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote: >> On 2020-06-22 15:58, Roger Pau Monné wrote: >>> On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote: >>>> Aha! Thank you for pointing this out. I think you may be right, but >>>> this >>>> should be possible without doing the demuxing in interrupt context. >>> >>> If you don't do the demuxing in the interrupt context (ie: making the >>> interrupt handler a noop), then you don't likely need such interrupt >>> anyway? >> >> I need the/an interrupt to wake the VCPU from HLT state if we went to sleep. >> >>> >>>> How about this arrangement, which appears to work for me; no hangs I >>>> can see >>>> so far and domU survives ping -f fine with no packet loss: >>>> >>>> CAMLprim value >>>> mirage_xen_evtchn_block_domain(value v_deadline) >>>> { >>>> struct vcpu_info *vi = VCPU0_INFO(); >>>> solo5_time_t deadline = Int64_val(v_deadline); >>>> >>>> if (solo5_clock_monotonic() < deadline) { >>>> __asm__ __volatile__ ("cli" : : : "memory"); >>>> if (vi->evtchn_upcall_pending) { >>>> __asm__ __volatile__ ("sti"); >>>> } >>>> else { >>>> hypercall_set_timer_op(deadline); >>> >>> What if you set a deadline so close that evtchn_upcall_pending gets >>> set by Xen here and the interrupt is injected? You would execute the >>> noop handler and just hlt, and could likely end up in the same blocked >>> situation as before? >> >> Why would an interrupt be injected here? Doesn't the immediately preceding >> "cli" disable that? > > Well, I mean between the sti and the hlt instruction. When EFLAGS.IF was clear before STI, then the first point at which an interrupt can get injected is when HLT is already executed (i.e. to wake from this HLT). That's the so called "STI shadow". Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:22:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:22:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPDX-0000mG-TY; Mon, 22 Jun 2020 16:22:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPDW-0000mB-OA for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:22:42 +0000 X-Inumbo-ID: 97beafc0-b4a4-11ea-beaa-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 97beafc0-b4a4-11ea-beaa-12813bfff9fa; Mon, 22 Jun 2020 16:22:41 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id ACEFEA287A; Mon, 22 Jun 2020 18:22:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 99E97A2860; Mon, 22 Jun 2020 18:22:39 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id UwW_gYi1Mr9a; Mon, 22 Jun 2020 18:22:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 0EC82A287A; Mon, 22 Jun 2020 18:22:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ustoazb4ieT0; Mon, 22 Jun 2020 18:22:38 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id D55C7A2860; Mon, 22 Jun 2020 18:22:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id B545821BFF; Mon, 22 Jun 2020 18:22:08 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id G3BaCcsvAPUO; Mon, 22 Jun 2020 18:22:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 2E17E21BF6; Mon, 22 Jun 2020 18:22:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4ZGMNt-xpVUh; Mon, 22 Jun 2020 18:22:03 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id F309821BEA; Mon, 22 Jun 2020 18:22:02 +0200 (CEST) Date: Mon, 22 Jun 2020 18:22:02 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <1402108091.11431889.1592842922883.JavaMail.zimbra@cert.pl> In-Reply-To: <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: vOPHlHoSDCFKXDoky6RsptumR5lekg== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 22 cze 2020 o 18:16, Jan Beulich jbeulich@suse.com napisa=C5=82(a): > On 22.06.2020 18:02, Micha=C5=82 Leszczy=C5=84ski wrote: >> ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisa=C5=82(a)= : >>> On 22.06.2020 16:35, Micha=C5=82 Leszczy=C5=84ski wrote: >>>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisa=C5=82(= a): >>>>> Is any of what you do in this switch() actually legitimate without >>>>> hvm_set_vmtrace_pt_size() having got called for the guest? From >>>>> remarks elsewhere I imply you expect the param that you currently >>>>> use to be set upon domain creation time, but at the very least the >>>>> potentially big buffer should imo not get allocated up front, but >>>>> only when tracing is to actually be enabled. >>>> >>>> Wait... so you want to allocate these buffers in runtime? >>>> Previously we were talking that there is too much runtime logic >>>> and these enable/disable hypercalls should be stripped to absolute >>>> minimum. >>> >>> Basic arrangements can be made at domain creation time. I don't >>> think though that it would be a good use of memory if you >>> allocated perhaps many gigabytes of memory just for possibly >>> wanting to enable tracing on a guest. >>> >>=20 >> From our previous conversations I thought that you want to have >> as much logic moved to the domain creation as possible. >>=20 >> Thus, a parameter "vmtrace_pt_size" was introduced. By default it's >> zero (=3D disabled), if you set it to a non-zero value, then trace buffe= rs >> of given size will be allocated for the domain and you have possibility >> to use ipt_enable/ipt_disable at any moment. >>=20 >> This way the runtime logic is as thin as possible. I assume user knows >> in advance whether he/she would want to use external monitoring with IPT >> or not. >=20 > Andrew - I think you requested movement to domain_create(). Could > you clarify if indeed you mean to also allocate the big buffers > this early? >=20 >> It's also not "many gigabytes". In most use cases a buffer of 16/32/64 M= B >> would suffice, I think. >=20 > But that one such buffer per vCPU, isn't it? Plus these buffers > need to be physically contiguous, which is an additional possibly > severe constraint. Yes. For my use case (VMI stuff) I estimate 16-64 MB per vCPU and for fuzzi= ng I think it would be even less. And also yes - these buffers need to be physically contigous and aligned because otherwise CPU would refuse to use them. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:26:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:26:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPGh-0000vo-EF; Mon, 22 Jun 2020 16:25:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPGg-0000vh-1W for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:25:58 +0000 X-Inumbo-ID: 0cd64172-b4a5-11ea-beaa-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0cd64172-b4a5-11ea-beaa-12813bfff9fa; Mon, 22 Jun 2020 16:25:57 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: JPCS0cf80VYvtfI+8vgub0sN+VBISTRtnfsNXZzckre2EgeRDcSdOil7WWcERMKRmwwpNq2svd 92QQGK6sXKJkASCg1kpXaaTpmxOHvlOWH+cEvs9n6NtebPFzxuov0oSGVp2mew4pkcOSeou5RO Kmd2uzdRPIbcS30yPLOe/9I2clK/8ZJkx9gvoCmMsGM0Q0fNcno+Lypx1dsr0bqM0rQBqPRy1e qkdXBs2ISYQWTUThmzaGtVlo1mcDCER2yAi93ckXTgyFf85m/UdPrpStWv/RrgJeYFNNZ2tX+W gMg= X-SBRS: 2.7 X-MesageID: 20639313 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,267,1589256000"; d="scan'208";a="20639313" Date: Mon, 22 Jun 2020 18:25:49 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op Message-ID: <20200622162237.GN735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 06:16:57PM +0200, Jan Beulich wrote: > On 22.06.2020 18:02, Michał Leszczyński wrote: > > ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisał(a): > >> On 22.06.2020 16:35, Michał Leszczyński wrote: > >>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisał(a): > > It's also not "many gigabytes". In most use cases a buffer of 16/32/64 MB > > would suffice, I think. > > But that one such buffer per vCPU, isn't it? Plus these buffers > need to be physically contiguous, which is an additional possibly > severe constraint. FTR, from my reading of the SDM you can use a mode called ToPA where the buffer is some kind of linked list of tables that map to output regions. That would be nice, but IMO it should be implemented in a next iteration after the basic support is in. Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:26:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:26:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPHT-000155-OH; Mon, 22 Jun 2020 16:26:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPHS-00014w-Ko for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:26:46 +0000 X-Inumbo-ID: 29cbd8a0-b4a5-11ea-bb8b-bc764e2007e4 Received: from smtp.lucina.net (unknown [62.176.169.44]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 29cbd8a0-b4a5-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 16:26:45 +0000 (UTC) Received: from webmail.moloch.sk (w3-s.a.lucina.net [62.176.169.73]) by smtp.lucina.net (Postfix) with ESMTPSA id DC2A0122804; Mon, 22 Jun 2020 18:26:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lucina.net; s=dkim-201811; t=1592843204; bh=mQQXPxHXOMJnHmwl/M96HjVCwVd2JTdxTuAjUdi23H8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=S4ACGWs+Kz/7HOI8guY2BTY+7HMQp7b4VKVLow5o4N2MPfwD6hy7J3EGLdOTG/Nv8 DtqY1StSPlGWGG+Ir9ntH8NyUt5FdfyOE7b6gRZdz0qnulOVH8N1pods77LEdJ5qZU ACSg+YEXiuchewfwx5g+8kesVQbzYoRC0oiY4YryqtwpM2sppkf71euzhQOBFPpEpr O3lhwhaqrS9bfpEGw/RdYjlQQDV3CqaReZwqn3XDdSXRFuMNTUUNUHfQRBm2pO9xfk 7Ibi8QD5HRhLKRcV+qxadw+0DZdWWiNEv5/QE/8IsxV8UeCmW434xtCxELL0QdtZY2 pN2A936vVhByA== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 22 Jun 2020 18:26:44 +0200 From: Martin Lucina To: Jan Beulich Subject: Re: Event delivery and "domain blocking" on PVHv2 In-Reply-To: References: <20200618101330.GB10330@nodbug.lucina.net> <20200618114617.GJ735@Air-de-Roger> <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> <20200619165426.GD735@Air-de-Roger> <20200619174143.GE735@Air-de-Roger> <7ed4a5f98b3002f3233e02d5ce803ef0@lucina.net> <20200622135853.GK735@Air-de-Roger> <745e4ac251b146480b2c6d6afbf5f34a@lucina.net> <20200622160916.GM735@Air-de-Roger> Message-ID: <7db6ae6c0270fde4d417e3c6134f3dbc@lucina.net> X-Sender: martin@lucina.net User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , xen-devel@lists.xenproject.org, mirageos-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-22 18:20, Jan Beulich wrote: > On 22.06.2020 18:09, Roger Pau Monné wrote: >> On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote: >>> On 2020-06-22 15:58, Roger Pau Monné wrote: >>>> On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote: >>>>> Aha! Thank you for pointing this out. I think you may be right, but >>>>> this >>>>> should be possible without doing the demuxing in interrupt context. >>>> >>>> If you don't do the demuxing in the interrupt context (ie: making >>>> the >>>> interrupt handler a noop), then you don't likely need such interrupt >>>> anyway? >>> >>> I need the/an interrupt to wake the VCPU from HLT state if we went to >>> sleep. >>> >>>> >>>>> How about this arrangement, which appears to work for me; no hangs >>>>> I >>>>> can see >>>>> so far and domU survives ping -f fine with no packet loss: >>>>> >>>>> CAMLprim value >>>>> mirage_xen_evtchn_block_domain(value v_deadline) >>>>> { >>>>> struct vcpu_info *vi = VCPU0_INFO(); >>>>> solo5_time_t deadline = Int64_val(v_deadline); >>>>> >>>>> if (solo5_clock_monotonic() < deadline) { >>>>> __asm__ __volatile__ ("cli" : : : "memory"); >>>>> if (vi->evtchn_upcall_pending) { >>>>> __asm__ __volatile__ ("sti"); >>>>> } >>>>> else { >>>>> hypercall_set_timer_op(deadline); >>>> >>>> What if you set a deadline so close that evtchn_upcall_pending gets >>>> set by Xen here and the interrupt is injected? You would execute the >>>> noop handler and just hlt, and could likely end up in the same >>>> blocked >>>> situation as before? >>> >>> Why would an interrupt be injected here? Doesn't the immediately >>> preceding >>> "cli" disable that? >> >> Well, I mean between the sti and the hlt instruction. > > When EFLAGS.IF was clear before STI, then the first point at which > an interrupt can get injected is when HLT is already executed (i.e. > to wake from this HLT). That's the so called "STI shadow". Indeed, that's what the Intel SDM says, and Andrew already mentioned earlier in this thread in a different context, here: https://lists.xenproject.org/archives/html/mirageos-devel/2020-06/msg00021.html . So it would seem that my latest approach is race-free? Martin From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:34:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:34:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPOh-00020K-K3; Mon, 22 Jun 2020 16:34:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPOg-00020E-0H for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:34:14 +0000 X-Inumbo-ID: 343945a6-b4a6-11ea-bb8b-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 343945a6-b4a6-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 16:34:12 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id CD238A23FE; Mon, 22 Jun 2020 18:34:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id CAA8DA1D3A; Mon, 22 Jun 2020 18:34:10 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id v16cT_qraLV1; Mon, 22 Jun 2020 18:34:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 5261FA23FE; Mon, 22 Jun 2020 18:34:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uoKYThEnuR4e; Mon, 22 Jun 2020 18:34:10 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2CE73A1D3A; Mon, 22 Jun 2020 18:34:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 15E8D218C6; Mon, 22 Jun 2020 18:33:40 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vReO675wXacE; Mon, 22 Jun 2020 18:33:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 8483921A10; Mon, 22 Jun 2020 18:33:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LtOUdmnuBOAN; Mon, 22 Jun 2020 18:33:34 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 5E74320562; Mon, 22 Jun 2020 18:33:34 +0200 (CEST) Date: Mon, 22 Jun 2020 18:33:34 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Roger Pau =?utf-8?Q?Monn=C3=A9?= Message-ID: <895766097.11433345.1592843614252.JavaMail.zimbra@cert.pl> In-Reply-To: <20200622162237.GN735@Air-de-Roger> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> <20200622162237.GN735@Air-de-Roger> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: f7GTr4GfAQdWl0vLqzhU8plHMDvsqg== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Tamas K Lengyel , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 22 cze 2020 o 18:25, Roger Pau Monn=C3=A9 roger.pau@citrix.com napisa= =C5=82(a): > On Mon, Jun 22, 2020 at 06:16:57PM +0200, Jan Beulich wrote: >> On 22.06.2020 18:02, Micha=C5=82 Leszczy=C5=84ski wrote: >> > ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisa=C5=82(= a): >> >> On 22.06.2020 16:35, Micha=C5=82 Leszczy=C5=84ski wrote: >> >>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisa=C5= =82(a): >> > It's also not "many gigabytes". In most use cases a buffer of 16/32/64= MB >> > would suffice, I think. >>=20 >> But that one such buffer per vCPU, isn't it? Plus these buffers >> need to be physically contiguous, which is an additional possibly >> severe constraint. >=20 > FTR, from my reading of the SDM you can use a mode called ToPA where > the buffer is some kind of linked list of tables that map to output > regions. That would be nice, but IMO it should be implemented in a > next iteration after the basic support is in. >=20 > Roger. Yes. I keep that in mind but right now I would like to go for the minimum viable implementation, while ToPA could be added in the next patch series. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:36:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:36:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPQx-0002DY-9C; Mon, 22 Jun 2020 16:36:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPQw-0002D1-7H for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:36:34 +0000 X-Inumbo-ID: 84e521c8-b4a6-11ea-beaf-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 84e521c8-b4a6-11ea-beaf-12813bfff9fa; Mon, 22 Jun 2020 16:36:28 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: zenzgTPE0gwVQjxT8qMs0u6lkcHLDtZd0ulrGRJqKik6SlE3UsmONSxc6EJJHX2OsTNN4ZJjDO zQKRbX6kGGU4IaiYNrRIYYxXh1eWDB4oltec5YfhTjmbghoUd8Xo9WCEWbrq6zY165QjRx4MV6 vPQumjzDD0loK3L8huzC+MozOEk+e2SIG71LbLsTjb9n9LJGf8TVQ0y0oJeXhaK1x7CsF11054 Jfkz9g+voi5w+jLQD2+/O8PUgCh4vG6zVdN92tC9qurBytHXFziDltxhSs6mXQG0Jc72ERiDII QqU= X-SBRS: 2.7 X-MesageID: 20944777 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,267,1589256000"; d="scan'208";a="20944777" Date: Mon, 22 Jun 2020 18:36:20 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich , Martin Lucina Subject: Re: Event delivery and "domain blocking" on PVHv2 Message-ID: <20200622163620.GO735@Air-de-Roger> References: <17deb17cec442f96cc7aba98ef4c047c@lucina.net> <20200619112119.GY735@Air-de-Roger> <20200619165426.GD735@Air-de-Roger> <20200619174143.GE735@Air-de-Roger> <7ed4a5f98b3002f3233e02d5ce803ef0@lucina.net> <20200622135853.GK735@Air-de-Roger> <745e4ac251b146480b2c6d6afbf5f34a@lucina.net> <20200622160916.GM735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , mirageos-devel@lists.xenproject.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 06:20:34PM +0200, Jan Beulich wrote: > On 22.06.2020 18:09, Roger Pau Monné wrote: > > On Mon, Jun 22, 2020 at 05:31:00PM +0200, Martin Lucina wrote: > >> On 2020-06-22 15:58, Roger Pau Monné wrote: > >>> On Mon, Jun 22, 2020 at 12:58:37PM +0200, Martin Lucina wrote: > >>>> Aha! Thank you for pointing this out. I think you may be right, but > >>>> this > >>>> should be possible without doing the demuxing in interrupt context. > >>> > >>> If you don't do the demuxing in the interrupt context (ie: making the > >>> interrupt handler a noop), then you don't likely need such interrupt > >>> anyway? > >> > >> I need the/an interrupt to wake the VCPU from HLT state if we went to sleep. > >> > >>> > >>>> How about this arrangement, which appears to work for me; no hangs I > >>>> can see > >>>> so far and domU survives ping -f fine with no packet loss: > >>>> > >>>> CAMLprim value > >>>> mirage_xen_evtchn_block_domain(value v_deadline) > >>>> { > >>>> struct vcpu_info *vi = VCPU0_INFO(); > >>>> solo5_time_t deadline = Int64_val(v_deadline); > >>>> > >>>> if (solo5_clock_monotonic() < deadline) { > >>>> __asm__ __volatile__ ("cli" : : : "memory"); > >>>> if (vi->evtchn_upcall_pending) { > >>>> __asm__ __volatile__ ("sti"); > >>>> } > >>>> else { > >>>> hypercall_set_timer_op(deadline); > >>> > >>> What if you set a deadline so close that evtchn_upcall_pending gets > >>> set by Xen here and the interrupt is injected? You would execute the > >>> noop handler and just hlt, and could likely end up in the same blocked > >>> situation as before? > >> > >> Why would an interrupt be injected here? Doesn't the immediately preceding > >> "cli" disable that? > > > > Well, I mean between the sti and the hlt instruction. > > When EFLAGS.IF was clear before STI, then the first point at which > an interrupt can get injected is when HLT is already executed (i.e. > to wake from this HLT). That's the so called "STI shadow". Oh, so then what Martin does seems to be fine, as there's no race, by the fact that evtchn_upcall_pending is checked with interrupts disabled. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 16:52:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 16:52:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPgW-0003xC-Q9; Mon, 22 Jun 2020 16:52:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPgV-0003wi-PS for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 16:52:39 +0000 X-Inumbo-ID: c42a76b0-b4a8-11ea-beaf-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c42a76b0-b4a8-11ea-beaf-12813bfff9fa; Mon, 22 Jun 2020 16:52:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Crn1QAxSjnI84XAt7PcnDfhmfATGtcW6kr0DQxtmwh0=; b=x1IldzjxeGxnC/Tj1O8WDI4D3 e1Td6MIIPxWRNNtXDBT7YKpeNY+RcxkNhqshrK3x8aUxmf/o+dGbDWgQwthHQFvD4BXKoryWsxYNJ hzMdXKg2883TqDNSXMwdyTziIO4Tx7RrLXG1o9BeEMD5LzcR06aTUzOypinnYlinLyjkQ=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPgO-0003Oj-Da; Mon, 22 Jun 2020 16:52:32 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnPgO-0005Cv-5B; Mon, 22 Jun 2020 16:52:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnPgO-0006Bj-4V; Mon, 22 Jun 2020 16:52:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151279: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-4.11-testing:test-armhf-armhf-xl-rtds:guest-start:fail:heisenbug xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Mon, 22 Jun 2020 16:52:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151279 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151279/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail in 151260 REGR. vs. 150040 build-i386-prev 6 xen-build fail in 151260 REGR. vs. 150040 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 151260 test-armhf-armhf-xl-rtds 12 guest-start fail pass in 151260 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked in 151260 n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked in 151260 n/a test-armhf-armhf-xl-rtds 13 migrate-support-check fail in 151260 never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 151260 never pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 48 days Failing since 150942 2020-06-09 17:05:43 Z 12 days 13 attempts Testing same since 151061 2020-06-12 12:25:05 Z 10 days 8 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 2b77729888fb851ab96e7f77bc854122626b4861 Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Mon Jun 22 17:05:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 17:05:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPtI-000507-0z; Mon, 22 Jun 2020 17:05:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnPtG-000501-8V for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 17:05:50 +0000 X-Inumbo-ID: 9e917db7-b4aa-11ea-beb0-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9e917db7-b4aa-11ea-beb0-12813bfff9fa; Mon, 22 Jun 2020 17:05:49 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3BE55A2860; Mon, 22 Jun 2020 19:05:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 28C8CA285E; Mon, 22 Jun 2020 19:05:47 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id zzkxUPM-CLgq; Mon, 22 Jun 2020 19:05:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id AC515A2860; Mon, 22 Jun 2020 19:05:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aXEdW161MWE6; Mon, 22 Jun 2020 19:05:46 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 80336A285E; Mon, 22 Jun 2020 19:05:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 6514821BD2; Mon, 22 Jun 2020 19:05:16 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QdigVfcrHFzN; Mon, 22 Jun 2020 19:05:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 053FA21C36; Mon, 22 Jun 2020 19:05:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gVdlHYltxTnT; Mon, 22 Jun 2020 19:05:10 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id D59AF21C35; Mon, 22 Jun 2020 19:05:10 +0200 (CEST) Date: Mon, 22 Jun 2020 19:05:10 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <1880428355.11437172.1592845510789.JavaMail.zimbra@cert.pl> In-Reply-To: <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: hAM9A3NcvqmPiUmz43AEWAK5kVI4obMO8mGL X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Xen-devel , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jun Nakajima , Tamas K Lengyel , "Kang, Luwei" , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" >>>>> +struct xen_hvm_vmtrace_op { >>>>> + /* IN variable */ >>>>> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ >>>>> + uint32_t cmd; >>>>> +/* Enable/disable external vmtrace for given domain */ >>>>> +#define HVMOP_vmtrace_ipt_enable 1 >>>>> +#define HVMOP_vmtrace_ipt_disable 2 >>>>> +#define HVMOP_vmtrace_ipt_get_offset 3 >>>>> + domid_t domain; >>>>> + uint32_t vcpu; >>>>> + uint64_t size; >>>>> + >>>>> + /* OUT variable */ >>>>> + uint64_t offset; >>>> >>>> If this is to be a tools-only interface, please use uint64_aligned_t. >>>> >>> >>> This type is not defined within hvm_op.h header. What should I do about it? >> >> It gets defined by xen.h, so should be available here. Its >> definitions live in a >> >> #if defined(__XEN__) || defined(__XEN_TOOLS__) >> >> section, which is what I did recommend to put your interface in >> as well. Unless you want this to be exposed to the guest itself, >> at which point further constraints would arise. >> When I've putted it into #if defined(__XEN__) || defined(__XEN_TOOLS__) then it complains about uint64_aligned_compat_t type missing. I also can't spot any single instance of uint64_aligned_t within this file. ml From xen-devel-bounces@lists.xenproject.org Mon Jun 22 17:16:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 17:16:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQ3n-00065b-04; Mon, 22 Jun 2020 17:16:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQ3l-00065W-Ng for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 17:16:41 +0000 X-Inumbo-ID: 22ef1c20-b4ac-11ea-beb0-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 22ef1c20-b4ac-11ea-beb0-12813bfff9fa; Mon, 22 Jun 2020 17:16:40 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: hJvmAA4P5Vj+eLdeFrVChFjHf5w+aJy5ku8a4hfTC99wEquHUHSsi8DRHjpIjcKawhiN4izQfK BXv4Tk8l85oZUHDrJYbWl2xo0II6jp0kXYqvwvitNmbE+M6Hd2tTPVFyD6e5QOXSac7vIwILOy T3P/AVBW7o4++AvJfjZkZ+7sEwXgZZbFuzdMaqt2Qr8xnxv500aYr+GXCubcuYFj17yzg0wy5c PhVENiCYkrAqnnAVqh8r+GCX2uZmCXgptp/ROj+jUY3TnDLiZ+SYSBHXvdY23DSVTmk7OkSiry QQ4= X-SBRS: 2.7 X-MesageID: 20865635 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,268,1589256000"; d="scan'208";a="20865635" Subject: Re: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs To: Jan Beulich References: <20200619115823.22243-1-andrew.cooper3@citrix.com> <32440578-e346-85cc-abad-1aa5694f0ab2@suse.com> <855c1668-3f91-c084-70d5-76f3e171f074@citrix.com> From: Andrew Cooper Message-ID: Date: Mon, 22 Jun 2020 18:16:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/06/2020 14:39, Jan Beulich wrote: > On 19.06.2020 15:28, Andrew Cooper wrote: >> On 19/06/2020 13:48, Jan Beulich wrote: >>> On 19.06.2020 13:58, Andrew Cooper wrote: >>>> --- a/xen/arch/x86/msr.c >>>> +++ b/xen/arch/x86/msr.c >>>> @@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) >>>> case MSR_TSX_FORCE_ABORT: >>>> case MSR_TSX_CTRL: >>>> case MSR_MCU_OPT_CTRL: >>>> + case MSR_RTIT_OUTPUT_BASE: >>>> + case MSR_RTIT_OUTPUT_MASK: >>>> + case MSR_RTIT_CTL: >>>> + case MSR_RTIT_STATUS: >>>> + case MSR_RTIT_CR3_MATCH: >>>> + case MSR_RTIT_ADDR_A(0) ... MSR_RTIT_ADDR_B(3): >>> The respective CPUID field is 3 bits wide, so wouldn't it be better >>> to cover the full possible range (0...6 afaict)? >> Last time I tried, you objected to me covering MSR ranges which weren't >> defined. > Wasn't that for a range where some number had been re-used from > earlier models (with entirely different purpose)? I don't recall, but the answer isn't relevant to whether the MSRs at those indices ought to be available to guests. >> If you want to extend the range like that, it ought to be >> MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7) to cover the entire area >> which seems to be exclusively for PT. > I'd be okay with that, just that I'm not sure about (7): While > SDM Vol 2 oddly enough doesn't seem to list anything for leaf 7 > subleaf 1 (or I'm sufficiently blind today), Vol 4 clearly says > for n=0...3 "If CPUID.(EAX=07H,ECX=1):EAX[2:0] > ", and the > field obviously can't be > 7. 7 gives the top of the bank of MSRs.  It isn't related to CPUID data. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 22 17:49:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 17:49:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQZN-0000SB-JC; Mon, 22 Jun 2020 17:49:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQZM-0000S6-Jz for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 17:49:20 +0000 X-Inumbo-ID: b3131dca-b4b0-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b3131dca-b4b0-11ea-bca7-bc764e2007e4; Mon, 22 Jun 2020 17:49:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9weotV/SNrMZyG1N1H3/PFtyW42B6wbbtW+YFspt8Zk=; b=insdBMx2bfBXoUpm9PYFijyIXm eeMtEfWsUy8zv1zWqnXNBM+nAPhn6zlh1v7+XijiV2m8HB5tu+bywNKAUIboHoi65fEbaHo/KmAy3 CPTkGwr8VwhtQ2OwGAePrcF67+SBn/0qn9elHyV67x0Tt+UqjJcsZSQm/CBjN81Xjczs=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQZK-0004RH-37; Mon, 22 Jun 2020 17:49:18 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnQZJ-0003qH-RY; Mon, 22 Jun 2020 17:49:18 +0000 Subject: Re: UEFI support in ARM DomUs To: Oleksandr Andrushchenko , Stefano Stabellini , Julien Grall References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> From: Julien Grall Message-ID: <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> Date: Mon, 22 Jun 2020 18:49:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22/06/2020 15:33, Oleksandr Andrushchenko wrote: > > On 6/22/20 5:27 PM, Julien Grall wrote: >> Hi Oleksandr, >> >> On 22/06/2020 15:04, Oleksandr Andrushchenko wrote: >>> On 6/19/20 11:02 PM, Stefano Stabellini wrote: >>>> On Thu, 18 Jun 2020, Julien Grall wrote: >>> ifeq ($(CONFIG_XEN),y) >>> arch-y += -D__XEN_INTERFACE_VERSION__=0x00040d00 >>> endif >>> >>> and we also have Xen 4.13 headers in the U-boot tree. >> >> Sorry if this was already asked before. Why do you need to specify __XEN_INTERFACE_VERSION__? > > This is because of include/xen/interface/xen-compat.h: > > #if defined(__XEN__) || defined(__XEN_TOOLS__) > > /* Xen is built with matching headers and implements the latest interface. */ > #define __XEN_INTERFACE_VERSION__ __XEN_LATEST_INTERFACE_VERSION__ > #elif !defined(__XEN_INTERFACE_VERSION__) > /* Guests which do not specify a version get the legacy interface. */ > #define __XEN_INTERFACE_VERSION__ 0x00000000 > #endif I am afraid this doesn't explain why you need to define it to a specific version. __XEN_INTERFACE_VERSION__ is really mostly here to allow a guest to build if they rely on header from xen.git (we may have done some renaming). Most (if not all) the interfaces you care ought to be stable. Older Xen will return -ENOSYS/-EOPNOTSUPP should deny any values they don't know. As you pull the headers in U-boot, you could safely define __XEN_INTERFACE_VERSION__ as __XEN_LATEST_INTERFACE_VERSION__. FWIW, this is what Linux is doing to some extend. Note that I haven't suggested to keep __XEN_INTERFACE_VERSION__ as 0x00000000 because it looks like it is going to do the wrong thing on arm32 :(. I have at least spot one issue with GNTTABOP_setup_table where it will use unsigned long (i.e 32-bit) for older interface. But the hypervisor will always 64-bits. This probably going to result to some overwrite. I think we should fix the headers to force it to use xen_pfn_t for all Xen on Arm version. Something like: #if !(defined(__arch64__) || defined(__arm__)) && __XEN_INTERFACE_VERSION__ < 0x00040300 XEN_GUEST_HANDLE(ulong) frame_list; #else XEN_GUEST_HANDLE(xen_pfn_t) frame_list; #endif > > So, one needs to specify the version (QEMU does that via its configure script after > > some tests) Well libxc is definitely not stable, hence why QEMU requires to specify the version. But the interface with the guest is always meant to be stable. >> >>> >>> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it via >>> >>> CFLAGS or something. This can also be done for the location of Xen headers. >> >> __XEN_INTERFACE_VERSION__ should work through the CFLAGS. An alternative would be to allow the user to specify through the Kconfig. > > You mean specifying via Kconfig something like "0x00040d00"? Possibly yes. > > And what about the headers? How will we provide their location if we decide not to include those > > in the tree? I would do through Kconfig as well. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:06:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:06:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQqI-0002Jh-30; Mon, 22 Jun 2020 18:06:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQqH-0002Jc-GW for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:06:49 +0000 X-Inumbo-ID: 232b9a68-b4b3-11ea-beb6-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 232b9a68-b4b3-11ea-beb6-12813bfff9fa; Mon, 22 Jun 2020 18:06:47 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 85B54A2894; Mon, 22 Jun 2020 20:06:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 6FA8CA2881; Mon, 22 Jun 2020 20:06:45 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id KLl5yrCTlsJO; Mon, 22 Jun 2020 20:06:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id C3B55A2894; Mon, 22 Jun 2020 20:06:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oQ3AfMYdIzwJ; Mon, 22 Jun 2020 20:06:44 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 90A17A2881; Mon, 22 Jun 2020 20:06:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 73AE821890; Mon, 22 Jun 2020 20:06:14 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id QL2k4gIO7Y9l; Mon, 22 Jun 2020 20:06:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D030521C2B; Mon, 22 Jun 2020 20:06:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8N5wYx1KKGyw; Mon, 22 Jun 2020 20:06:08 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id AA27421890; Mon, 22 Jun 2020 20:06:08 +0200 (CEST) Date: Mon, 22 Jun 2020 20:06:08 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Message-ID: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> Subject: [PATCH v3 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: fAatEklvenYpYrSWj77J6AQD/dj+xA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Anthony PERARD , Tamas K Lengyel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Intel Processor Trace is an architectural extension available in modern Intel family CPUs. It allows recording the detailed trace of activity while the processor executes the code. One might use the recorded trace to reconstruct the code flow. It means, to find out the executed code paths, determine branches taken, and so forth. The abovementioned feature is described in Intel(R) 64 and IA-32 Architectures Software Developer's Manual Volume 3C: System Programming Guide, Part 3, Chapter 36: "Intel Processor Trace." This patch series implements an interface that Dom0 could use in order to enable IPT for particular vCPUs in DomU, allowing for external monitoring. Such a feature has numerous applications like malware monitoring, fuzzing, or performance testing. Also thanks to Tamas K Lengyel for a few preliminary hints before first version of this patch was submitted to xen-devel. Changed since v1: * MSR_RTIT_CTL is managed using MSR load lists * other PT-related MSRs are modified only when vCPU goes out of context * trace buffer is now acquired as a resource * added vmtrace_pt_size parameter in xl.cfg, the size of trace buffer must be specified in the moment of domain creation * trace buffers are allocated on domain creation, destructed on domain destruction * HVMOP_vmtrace_ipt_enable/disable is limited to enabling/disabling PT these calls don't manage buffer memory anymore * lifted 32 MFN/GFN array limit when acquiring resources * minor code style changes according to review Changed since v2: * trace buffer is now allocated on domain creation (in v2 it was allocated when hvm param was set) * restored 32-item limit in mfn/gfn arrays in acquire_resource and instead implemented hypercall continuations * code changes according to Jan's and Roger's review Michal Leszczynski (7): memory: batch processing in acquire_resource() x86/vmx: add Intel PT MSR definitions x86/vmx: add IPT cpu feature x86/vmx: add do_vmtrace_op tools/libxc: add xc_vmtrace_* functions tools/libxl: add vmtrace_pt_size parameter tools/proctrace: add proctrace tool docs/man/xl.cfg.5.pod.in | 10 + tools/golang/xenlight/helpers.gen.go | 2 + tools/golang/xenlight/types.gen.go | 1 + tools/libxc/Makefile | 1 + tools/libxc/include/xenctrl.h | 39 +++ tools/libxc/xc_vmtrace.c | 94 ++++++ tools/libxl/libxl_create.c | 1 + tools/libxl/libxl_types.idl | 2 + tools/proctrace/COPYING | 339 ++++++++++++++++++++ tools/proctrace/Makefile | 50 +++ tools/proctrace/proctrace.c | 158 +++++++++ tools/xl/xl_parse.c | 4 + xen/arch/x86/hvm/hvm.c | 168 ++++++++++ xen/arch/x86/hvm/vmx/vmcs.c | 7 +- xen/arch/x86/hvm/vmx/vmx.c | 31 ++ xen/arch/x86/mm.c | 28 ++ xen/common/domain.c | 3 + xen/common/memory.c | 32 +- xen/include/asm-x86/cpufeature.h | 1 + xen/include/asm-x86/hvm/hvm.h | 9 + xen/include/asm-x86/hvm/vmx/vmcs.h | 4 + xen/include/asm-x86/hvm/vmx/vmx.h | 14 + xen/include/asm-x86/msr-index.h | 37 +++ xen/include/public/arch-x86/cpufeatureset.h | 1 + xen/include/public/domctl.h | 1 + xen/include/public/hvm/hvm_op.h | 26 ++ xen/include/public/hvm/params.h | 2 +- xen/include/public/memory.h | 1 + xen/include/xen/sched.h | 4 + xen/include/xlat.lst | 1 + 30 files changed, 1066 insertions(+), 5 deletions(-) create mode 100644 tools/libxc/xc_vmtrace.c create mode 100644 tools/proctrace/COPYING create mode 100644 tools/proctrace/Makefile create mode 100644 tools/proctrace/proctrace.c -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:10:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:10:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQuH-00036Z-Kv; Mon, 22 Jun 2020 18:10:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQuG-00036U-FB for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:10:56 +0000 X-Inumbo-ID: b6d10532-b4b3-11ea-beb6-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b6d10532-b4b3-11ea-beb6-12813bfff9fa; Mon, 22 Jun 2020 18:10:55 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7B606A28AD; Mon, 22 Jun 2020 20:10:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 6DC65A289F; Mon, 22 Jun 2020 20:10:53 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xrxK1elMFI4u; Mon, 22 Jun 2020 20:10:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id F07BDA28AD; Mon, 22 Jun 2020 20:10:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rLJEQchKP-ea; Mon, 22 Jun 2020 20:10:52 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id CA29FA289F; Mon, 22 Jun 2020 20:10:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id B4AE02025C; Mon, 22 Jun 2020 20:10:22 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xqe4aqcn-H8Q; Mon, 22 Jun 2020 20:10:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 4107D212DF; Mon, 22 Jun 2020 20:10:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nd361qW19IcA; Mon, 22 Jun 2020 20:10:17 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 1FCBF2025C; Mon, 22 Jun 2020 20:10:17 +0200 (CEST) Date: Mon, 22 Jun 2020 20:10:17 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Message-ID: <1211846582.11443665.1592849417087.JavaMail.zimbra@cert.pl> In-Reply-To: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> Subject: [PATCH v3 1/7] memory: batch processing in acquire_resource() MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: memory: batch processing in acquire_resource() Thread-Index: fAatEklvenYpYrSWj77J6AQD/dj+xJkDPLHZ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Tamas K Lengyel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Allow to acquire large resources by allowing acquire_resource() to process items in batches, using hypercall continuation. Signed-off-by: Michal Leszczynski --- xen/common/memory.c | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/xen/common/memory.c b/xen/common/memory.c index 714077c1e5..3ab06581a2 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -1046,10 +1046,12 @@ static int acquire_grant_table(struct domain *d, unsigned int id, } static int acquire_resource( - XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg) + XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg, + unsigned long *start_extent) { struct domain *d, *currd = current->domain; xen_mem_acquire_resource_t xmar; + uint32_t total_frames; /* * The mfn_list and gfn_list (below) arrays are ok on stack for the * moment since they are small, but if they need to grow in future @@ -1077,8 +1079,17 @@ static int acquire_resource( return 0; } + total_frames = xmar.nr_frames; + + if ( *start_extent ) + { + xmar.frame += *start_extent; + xmar.nr_frames -= *start_extent; + guest_handle_add_offset(xmar.frame_list, *start_extent); + } + if ( xmar.nr_frames > ARRAY_SIZE(mfn_list) ) - return -E2BIG; + xmar.nr_frames = ARRAY_SIZE(mfn_list); rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); if ( rc ) @@ -1135,6 +1146,14 @@ static int acquire_resource( } } + if ( !rc ) + { + *start_extent += xmar.nr_frames; + + if ( *start_extent != total_frames ) + rc = -ERESTART; + } + out: rcu_unlock_domain(d); @@ -1600,7 +1619,14 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case XENMEM_acquire_resource: rc = acquire_resource( - guest_handle_cast(arg, xen_mem_acquire_resource_t)); + guest_handle_cast(arg, xen_mem_acquire_resource_t), + &start_extent); + + if ( rc == -ERESTART ) + return hypercall_create_continuation( + __HYPERVISOR_memory_op, "lh", + op | (start_extent << MEMOP_EXTENT_SHIFT), arg); + break; default: -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:11:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:11:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQug-00039U-Ts; Mon, 22 Jun 2020 18:11:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQuf-00039K-Gy for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:11:21 +0000 X-Inumbo-ID: c5d378c6-b4b3-11ea-bca7-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c5d378c6-b4b3-11ea-bca7-bc764e2007e4; Mon, 22 Jun 2020 18:11:20 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id AF2D3A28AD; Mon, 22 Jun 2020 20:11:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A2E8AA289F; Mon, 22 Jun 2020 20:11:18 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id TEka0gx5_A-v; Mon, 22 Jun 2020 20:11:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3219CA28AD; Mon, 22 Jun 2020 20:11:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FROVCkMHABuq; Mon, 22 Jun 2020 20:11:18 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 0C7C7A289F; Mon, 22 Jun 2020 20:11:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id EDE4921C91; Mon, 22 Jun 2020 20:10:47 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 7KSDxykLdhlt; Mon, 22 Jun 2020 20:10:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 53AFA21760; Mon, 22 Jun 2020 20:10:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3YWADGKblyU0; Mon, 22 Jun 2020 20:10:42 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 345C9212DF; Mon, 22 Jun 2020 20:10:42 +0200 (CEST) Date: Mon, 22 Jun 2020 20:10:42 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Message-ID: <639255187.11443691.1592849442180.JavaMail.zimbra@cert.pl> In-Reply-To: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> Subject: [PATCH v3 2/7] x86/vmx: add Intel PT MSR definitions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add Intel PT MSR definitions Thread-Index: fAatEklvenYpYrSWj77J6AQD/dj+xEaWCbCH X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Kang, Luwei" , Wei Liu , Andrew Cooper , Jan Beulich , Tamas K Lengyel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Define constants related to Intel Processor Trace features. Signed-off-by: Michal Leszczynski --- xen/include/asm-x86/msr-index.h | 37 +++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h index b328a47ed8..0203029be9 100644 --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -69,6 +69,43 @@ #define MSR_MCU_OPT_CTRL 0x00000123 #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) +/* Intel PT MSRs */ +#define MSR_RTIT_OUTPUT_BASE 0x00000560 + +#define MSR_RTIT_OUTPUT_MASK 0x00000561 + +#define MSR_RTIT_CTL 0x00000570 +#define RTIT_CTL_TRACEEN (_AC(1, ULL) << 0) +#define RTIT_CTL_CYCEN (_AC(1, ULL) << 1) +#define RTIT_CTL_OS (_AC(1, ULL) << 2) +#define RTIT_CTL_USR (_AC(1, ULL) << 3) +#define RTIT_CTL_PWR_EVT_EN (_AC(1, ULL) << 4) +#define RTIT_CTL_FUP_ON_PTW (_AC(1, ULL) << 5) +#define RTIT_CTL_FABRIC_EN (_AC(1, ULL) << 6) +#define RTIT_CTL_CR3_FILTER (_AC(1, ULL) << 7) +#define RTIT_CTL_TOPA (_AC(1, ULL) << 8) +#define RTIT_CTL_MTC_EN (_AC(1, ULL) << 9) +#define RTIT_CTL_TSC_EN (_AC(1, ULL) << 10) +#define RTIT_CTL_DIS_RETC (_AC(1, ULL) << 11) +#define RTIT_CTL_PTW_EN (_AC(1, ULL) << 12) +#define RTIT_CTL_BRANCH_EN (_AC(1, ULL) << 13) +#define RTIT_CTL_MTC_FREQ (_AC(0x0F, ULL) << 14) +#define RTIT_CTL_CYC_THRESH (_AC(0x0F, ULL) << 19) +#define RTIT_CTL_PSB_FREQ (_AC(0x0F, ULL) << 24) +#define RTIT_CTL_ADDR(n) (_AC(0x0F, ULL) << (32 + (4 * (n)))) + +#define MSR_RTIT_STATUS 0x00000571 +#define RTIT_STATUS_FILTER_EN (_AC(1, ULL) << 0) +#define RTIT_STATUS_CONTEXT_EN (_AC(1, ULL) << 1) +#define RTIT_STATUS_TRIGGER_EN (_AC(1, ULL) << 2) +#define RTIT_STATUS_ERROR (_AC(1, ULL) << 4) +#define RTIT_STATUS_STOPPED (_AC(1, ULL) << 5) +#define RTIT_STATUS_BYTECNT (_AC(0x1FFFF, ULL) << 32) + +#define MSR_RTIT_CR3_MATCH 0x00000572 +#define MSR_RTIT_ADDR_A(n) (0x00000580 + (n) * 2) +#define MSR_RTIT_ADDR_B(n) (0x00000581 + (n) * 2) + #define MSR_U_CET 0x000006a0 #define MSR_S_CET 0x000006a2 #define CET_SHSTK_EN (_AC(1, ULL) << 0) -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:11:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:11:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQv5-0003DW-A0; Mon, 22 Jun 2020 18:11:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQv3-0003DC-Dt for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:11:45 +0000 X-Inumbo-ID: d432a784-b4b3-11ea-bb8b-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d432a784-b4b3-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 18:11:44 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id CAC32A28AD; Mon, 22 Jun 2020 20:11:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id C58EFA289F; Mon, 22 Jun 2020 20:11:42 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id g1QFmLP3cP3F; Mon, 22 Jun 2020 20:11:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 37BC4A28AD; Mon, 22 Jun 2020 20:11:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CtOkqe-EOeKk; Mon, 22 Jun 2020 20:11:42 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 13697A289F; Mon, 22 Jun 2020 20:11:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id EE70C2025C; Mon, 22 Jun 2020 20:11:11 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id TUKugPhKZ-EV; Mon, 22 Jun 2020 20:11:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 69C5321C93; Mon, 22 Jun 2020 20:11:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yLWasTgV15CF; Mon, 22 Jun 2020 20:11:06 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 4BDA62025C; Mon, 22 Jun 2020 20:11:06 +0200 (CEST) Date: Mon, 22 Jun 2020 20:11:06 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Message-ID: <1045158707.11443757.1592849466278.JavaMail.zimbra@cert.pl> In-Reply-To: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> Subject: [PATCH v3 3/7] x86/vmx: add IPT cpu feature MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add IPT cpu feature Thread-Index: fAatEklvenYpYrSWj77J6AQD/dj+xMmEiEzJ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , "Kang, Luwei" , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Check if Intel Processor Trace feature is supported by current processor. Define hvm_ipt_supported function. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/vmx/vmcs.c | 7 ++++++- xen/include/asm-x86/cpufeature.h | 1 + xen/include/asm-x86/hvm/hvm.h | 9 +++++++++ xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + xen/include/public/arch-x86/cpufeatureset.h | 1 + 5 files changed, 18 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index ca94c2bedc..8c78c906b2 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -291,6 +291,12 @@ static int vmx_init_vmcs_config(void) _vmx_cpu_based_exec_control &= ~(CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING); + rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); + + /* Check whether IPT is supported in VMX operation. */ + hvm_funcs.pt_supported = cpu_has_ipt && + (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); + if ( _vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_SECONDARY_CONTROLS ) { min = 0; @@ -305,7 +311,6 @@ static int vmx_init_vmcs_config(void) SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS | SECONDARY_EXEC_XSAVES | SECONDARY_EXEC_TSC_SCALING); - rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL ) opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING; if ( opt_vpid_enabled ) diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h index f790d5c1f8..8d7955dd87 100644 --- a/xen/include/asm-x86/cpufeature.h +++ b/xen/include/asm-x86/cpufeature.h @@ -104,6 +104,7 @@ #define cpu_has_clwb boot_cpu_has(X86_FEATURE_CLWB) #define cpu_has_avx512er boot_cpu_has(X86_FEATURE_AVX512ER) #define cpu_has_avx512cd boot_cpu_has(X86_FEATURE_AVX512CD) +#define cpu_has_ipt boot_cpu_has(X86_FEATURE_IPT) #define cpu_has_sha boot_cpu_has(X86_FEATURE_SHA) #define cpu_has_avx512bw boot_cpu_has(X86_FEATURE_AVX512BW) #define cpu_has_avx512vl boot_cpu_has(X86_FEATURE_AVX512VL) diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h index 1eb377dd82..8c0d0ece67 100644 --- a/xen/include/asm-x86/hvm/hvm.h +++ b/xen/include/asm-x86/hvm/hvm.h @@ -96,6 +96,9 @@ struct hvm_function_table { /* Necessary hardware support for alternate p2m's? */ bool altp2m_supported; + /* Hardware support for processor tracing? */ + bool pt_supported; + /* Hardware virtual interrupt delivery enable? */ bool virtual_intr_delivery_enabled; @@ -630,6 +633,12 @@ static inline bool hvm_altp2m_supported(void) return hvm_funcs.altp2m_supported; } +/* returns true if hardware supports Intel Processor Trace */ +static inline bool hvm_pt_supported(void) +{ + return hvm_funcs.pt_supported; +} + /* updates the current hardware p2m */ static inline void altp2m_vcpu_update_p2m(struct vcpu *v) { diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h index 906810592f..0e9a0b8de6 100644 --- a/xen/include/asm-x86/hvm/vmx/vmcs.h +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h @@ -283,6 +283,7 @@ extern u32 vmx_secondary_exec_control; #define VMX_VPID_INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL 0x80000000000ULL extern u64 vmx_ept_vpid_cap; +#define VMX_MISC_PT_SUPPORTED 0x00004000 #define VMX_MISC_CR3_TARGET 0x01ff0000 #define VMX_MISC_VMWRITE_ALL 0x20000000 diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 5ca35d9d97..0d3f15f628 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -217,6 +217,7 @@ XEN_CPUFEATURE(SMAP, 5*32+20) /*S Supervisor Mode Access Prevention */ XEN_CPUFEATURE(AVX512_IFMA, 5*32+21) /*A AVX-512 Integer Fused Multiply Add */ XEN_CPUFEATURE(CLFLUSHOPT, 5*32+23) /*A CLFLUSHOPT instruction */ XEN_CPUFEATURE(CLWB, 5*32+24) /*A CLWB instruction */ +XEN_CPUFEATURE(IPT, 5*32+25) /* Intel Processor Trace */ XEN_CPUFEATURE(AVX512PF, 5*32+26) /*A AVX-512 Prefetch Instructions */ XEN_CPUFEATURE(AVX512ER, 5*32+27) /*A AVX-512 Exponent & Reciprocal Instrs */ XEN_CPUFEATURE(AVX512CD, 5*32+28) /*A AVX-512 Conflict Detection Instrs */ -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:12:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:12:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQvb-0003Jz-Jo; Mon, 22 Jun 2020 18:12:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQva-0003Jq-SP for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:12:18 +0000 X-Inumbo-ID: e7d7e682-b4b3-11ea-bb8b-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e7d7e682-b4b3-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 18:12:17 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id A7E73A28C2; Mon, 22 Jun 2020 20:12:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9477FA28AD; Mon, 22 Jun 2020 20:12:15 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JNOa44oL45Ms; Mon, 22 Jun 2020 20:12:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 8F3F9A28DD; Mon, 22 Jun 2020 20:12:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id N2e-sZ1Fgu28; Mon, 22 Jun 2020 20:12:14 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 65731A289F; Mon, 22 Jun 2020 20:12:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 4F90421CD8; Mon, 22 Jun 2020 20:11:44 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id GWabTm1LrnFz; Mon, 22 Jun 2020 20:11:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 41A6021CBB; Mon, 22 Jun 2020 20:11:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eoPR0vu2eetH; Mon, 22 Jun 2020 20:11:38 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 21A9521760; Mon, 22 Jun 2020 20:11:38 +0200 (CEST) Date: Mon, 22 Jun 2020 20:11:38 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Message-ID: <97440747.11443782.1592849498089.JavaMail.zimbra@cert.pl> In-Reply-To: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> Subject: [PATCH v3 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: fAatEklvenYpYrSWj77J6AQD/dj+xNwDcrpl X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Tamas K Lengyel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Provide an interface for privileged domains to manage external IPT monitoring. Guest IPT state will be preserved across vmentry/vmexit using ipt_state structure. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/hvm.c | 168 +++++++++++++++++++++++++++++ xen/arch/x86/hvm/vmx/vmx.c | 31 ++++++ xen/arch/x86/mm.c | 28 +++++ xen/common/domain.c | 3 + xen/include/asm-x86/hvm/vmx/vmcs.h | 3 + xen/include/asm-x86/hvm/vmx/vmx.h | 14 +++ xen/include/public/domctl.h | 1 + xen/include/public/hvm/hvm_op.h | 26 +++++ xen/include/public/hvm/params.h | 2 +- xen/include/public/memory.h | 1 + xen/include/xen/sched.h | 4 + xen/include/xlat.lst | 1 + 12 files changed, 281 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 5bb47583b3..5899df52c3 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -58,6 +58,7 @@ #include #include #include +#include #include #include #include @@ -606,6 +607,57 @@ static int hvm_print_line( return X86EMUL_OKAY; } +static int vmtrace_alloc_buffers(struct vcpu *v, uint64_t size) +{ + struct page_info *pg; + struct pt_state *pt; + + if ( size < PAGE_SIZE || size > GB(4) || (size & (size - 1)) ) + { + /* + * We don't accept trace buffer size smaller than single page + * and the upper bound is defined as 4GB in the specification. + * The buffer size must be also a power of 2. + */ + return -EINVAL; + } + + if ( vmx_add_host_load_msr(v, MSR_RTIT_CTL, 0) ) + return -EFAULT; + + pg = alloc_domheap_pages(v->domain, get_order_from_bytes(size), + MEMF_no_refcount); + + if ( !pg ) + return -ENOMEM; + + pt = xzalloc(struct pt_state); + + if ( !pt ) + return -ENOMEM; + + pt->output_base = page_to_maddr(pg); + pt->output_mask.raw = size - 1; + + v->arch.hvm.vmx.pt_state = pt; + + return 0; +} + +static void vmtrace_destroy_buffers(struct vcpu *v) +{ + struct pt_state *pt = v->arch.hvm.vmx.pt_state; + + if ( pt ) + { + free_domheap_pages(maddr_to_page(pt->output_base), + get_order_from_bytes(pt->output_mask.size + 1)); + + xfree(pt); + v->arch.hvm.vmx.pt_state = NULL; + } +} + int hvm_domain_initialise(struct domain *d) { unsigned int nr_gsis; @@ -747,7 +799,10 @@ void hvm_domain_relinquish_resources(struct domain *d) hpet_deinit(d); for_each_vcpu ( d, v ) + { + vmtrace_destroy_buffers(v); hvmemul_cache_destroy(v); + } } void hvm_domain_destroy(struct domain *d) @@ -1594,6 +1649,13 @@ int hvm_vcpu_initialise(struct vcpu *v) hvm_set_guest_tsc(v, 0); } + if ( d->vmtrace_pt_size ) + { + rc = vmtrace_alloc_buffers(v, d->vmtrace_pt_size); + if ( rc != 0 ) + goto fail1; + } + return 0; fail6: @@ -4949,6 +5011,108 @@ static int compat_altp2m_op( return rc; } +CHECK_hvm_vmtrace_op; + +static int do_vmtrace_op(XEN_GUEST_HANDLE_PARAM(void) arg) +{ + struct xen_hvm_vmtrace_op a; + struct domain *d; + int rc; + struct vcpu *v; + struct pt_state *pt; + + if ( !hvm_pt_supported() ) + return -EOPNOTSUPP; + + if ( copy_from_guest(&a, arg, 1) ) + return -EFAULT; + + if ( a.pad1 || a.pad2 ) + return -EINVAL; + + rc = rcu_lock_live_remote_domain_by_id(a.domain, &d); + + if ( rc ) + goto out; + + if ( !is_hvm_domain(d) ) + { + rc = -EOPNOTSUPP; + goto out; + } + + if ( a.vcpu >= d->max_vcpus ) + { + rc = -EINVAL; + goto out; + } + + v = domain_vcpu(d, a.vcpu); + pt = v->arch.hvm.vmx.pt_state; + + if ( !pt ) + { + /* PT must be first initialized upon domain creation. */ + rc = -EINVAL; + goto out; + } + + switch ( a.cmd ) + { + case HVMOP_vmtrace_pt_enable: + vcpu_pause(v); + spin_lock(&d->vmtrace_lock); + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, + RTIT_CTL_TRACEEN | RTIT_CTL_OS | + RTIT_CTL_USR | RTIT_CTL_BRANCH_EN) ) + { + rc = -EFAULT; + goto out; + } + + pt->active = 1; + spin_unlock(&d->vmtrace_lock); + vcpu_unpause(v); + break; + + case HVMOP_vmtrace_pt_disable: + vcpu_pause(v); + spin_lock(&d->vmtrace_lock); + + if ( vmx_del_msr(v, MSR_RTIT_CTL, VMX_MSR_GUEST) ) + { + rc = -EFAULT; + goto out; + } + + pt->active = 0; + spin_unlock(&d->vmtrace_lock); + vcpu_unpause(v); + break; + + case HVMOP_vmtrace_pt_get_offset: + a.offset = pt->output_mask.offset; + + if ( __copy_field_to_guest(guest_handle_cast(arg, xen_hvm_vmtrace_op_t), &a, offset) ) + { + rc = -EFAULT; + goto out; + } + break; + + default: + rc = -EOPNOTSUPP; + goto out; + } + + rc = 0; + + out: + rcu_unlock_domain(d); + + return rc; +} + static int hvmop_get_mem_type( XEN_GUEST_HANDLE_PARAM(xen_hvm_get_mem_type_t) arg) { @@ -5101,6 +5265,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) rc = current->hcall_compat ? compat_altp2m_op(arg) : do_altp2m_op(arg); break; + case HVMOP_vmtrace: + rc = do_vmtrace_op(arg); + break; + default: { gdprintk(XENLOG_DEBUG, "Bad HVM op %ld.\n", op); diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index ab19d9424e..3798a58d0f 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -508,11 +508,24 @@ static void vmx_restore_host_msrs(void) static void vmx_save_guest_msrs(struct vcpu *v) { + uint64_t rtit_ctl; + /* * We cannot cache SHADOW_GS_BASE while the VCPU runs, as it can * be updated at any time via SWAPGS, which we cannot trap. */ v->arch.hvm.vmx.shadow_gs = rdgsshadow(); + + if ( unlikely(v->arch.hvm.vmx.pt_state && + v->arch.hvm.vmx.pt_state->active) ) + { + rdmsrl(MSR_RTIT_CTL, rtit_ctl); + BUG_ON(rtit_ctl & RTIT_CTL_TRACEEN); + + rdmsrl(MSR_RTIT_STATUS, v->arch.hvm.vmx.pt_state->status); + rdmsrl(MSR_RTIT_OUTPUT_MASK, + v->arch.hvm.vmx.pt_state->output_mask.raw); + } } static void vmx_restore_guest_msrs(struct vcpu *v) @@ -524,6 +537,17 @@ static void vmx_restore_guest_msrs(struct vcpu *v) if ( cpu_has_msr_tsc_aux ) wrmsr_tsc_aux(v->arch.msrs->tsc_aux); + + if ( unlikely(v->arch.hvm.vmx.pt_state && + v->arch.hvm.vmx.pt_state->active) ) + { + wrmsrl(MSR_RTIT_OUTPUT_BASE, + v->arch.hvm.vmx.pt_state->output_base); + wrmsrl(MSR_RTIT_OUTPUT_MASK, + v->arch.hvm.vmx.pt_state->output_mask.raw); + wrmsrl(MSR_RTIT_STATUS, + v->arch.hvm.vmx.pt_state->status); + } } void vmx_update_cpu_exec_control(struct vcpu *v) @@ -3674,6 +3698,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) hvm_invalidate_regs_fields(regs); + if ( unlikely(v->arch.hvm.vmx.pt_state && + v->arch.hvm.vmx.pt_state->active) ) + { + rdmsrl(MSR_RTIT_OUTPUT_MASK, + v->arch.hvm.vmx.pt_state->output_mask.raw); + } + if ( paging_mode_hap(v->domain) ) { /* diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e376fc7e8f..10fc26d13e 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -142,6 +142,7 @@ #include #include #include +#include #include #include @@ -4624,6 +4625,33 @@ int arch_acquire_resource(struct domain *d, unsigned int type, } break; } + + case XENMEM_resource_vmtrace_buf: + { + mfn_t mfn; + unsigned int i; + struct pt_state *pt; + rc = -EINVAL; + + if ( id >= d->max_vcpus ) + break; + + pt = d->vcpu[id]->arch.hvm.vmx.pt_state; + + if ( !pt ) + break; + + mfn = _mfn(pt->output_base >> PAGE_SHIFT); + + if ( frame + nr_frames > (pt->output_mask.size >> PAGE_SHIFT) + 1 ) + break; + + rc = 0; + for ( i = 0; i < nr_frames; i++ ) + mfn_list[i] = mfn_x(mfn_add(mfn, frame + i)); + + break; + } #endif default: diff --git a/xen/common/domain.c b/xen/common/domain.c index 7cc9526139..52ccd678f4 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -414,6 +414,7 @@ struct domain *domain_create(domid_t domid, d->shutdown_code = SHUTDOWN_CODE_INVALID; spin_lock_init(&d->pbuf_lock); + spin_lock_init(&d->vmtrace_lock); rwlock_init(&d->vnuma_rwlock); @@ -441,6 +442,8 @@ struct domain *domain_create(domid_t domid, d->nr_pirqs = min(d->nr_pirqs, nr_irqs); radix_tree_init(&d->pirq_tree); + + d->vmtrace_pt_size = config->vmtrace_pt_size; } if ( (err = arch_domain_create(d, config)) != 0 ) diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h index 0e9a0b8de6..64c0d82614 100644 --- a/xen/include/asm-x86/hvm/vmx/vmcs.h +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h @@ -186,6 +186,9 @@ struct vmx_vcpu { * pCPU and wakeup the related vCPU. */ struct pi_blocking_vcpu pi_blocking; + + /* State of processor trace feature */ + struct pt_state *pt_state; }; int vmx_create_vmcs(struct vcpu *v); diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h index 111ccd7e61..be7213d3c0 100644 --- a/xen/include/asm-x86/hvm/vmx/vmx.h +++ b/xen/include/asm-x86/hvm/vmx/vmx.h @@ -689,4 +689,18 @@ typedef union ldt_or_tr_instr_info { }; } ldt_or_tr_instr_info_t; +/* Processor Trace state per vCPU */ +struct pt_state { + bool_t active; + uint64_t status; + uint64_t output_base; + union { + uint64_t raw; + struct { + uint32_t size; + uint32_t offset; + }; + } output_mask; +}; + #endif /* __ASM_X86_HVM_VMX_VMX_H__ */ diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index 59bdc28c89..054892befe 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -92,6 +92,7 @@ struct xen_domctl_createdomain { uint32_t max_evtchn_port; int32_t max_grant_frames; int32_t max_maptrack_frames; + uint64_t vmtrace_pt_size; struct xen_arch_domainconfig arch; }; diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h index 870ec52060..6d8841668e 100644 --- a/xen/include/public/hvm/hvm_op.h +++ b/xen/include/public/hvm/hvm_op.h @@ -382,6 +382,32 @@ struct xen_hvm_altp2m_op { typedef struct xen_hvm_altp2m_op xen_hvm_altp2m_op_t; DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_op_t); +#if defined(__XEN__) || defined(__XEN_TOOLS__) + +/* HVMOP_vmtrace: Perform VM tracing related operation */ +#define HVMOP_vmtrace 26 + +struct xen_hvm_vmtrace_op { + /* IN variable */ + uint32_t cmd; +/* Enable/disable external vmtrace for given domain */ +#define HVMOP_vmtrace_pt_enable 1 +#define HVMOP_vmtrace_pt_disable 2 +#define HVMOP_vmtrace_pt_get_offset 3 + domid_t domain; + uint16_t pad1; + uint32_t vcpu; + uint32_t pad2; + uint64_t size; + + /* OUT variable */ + uint64_t offset; +}; +typedef struct xen_hvm_vmtrace_op xen_hvm_vmtrace_op_t; +DEFINE_XEN_GUEST_HANDLE(xen_hvm_vmtrace_op_t); + +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ + #endif /* __XEN_PUBLIC_HVM_HVM_OP_H__ */ /* diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h index 0a91bfa749..22f6185e01 100644 --- a/xen/include/public/hvm/params.h +++ b/xen/include/public/hvm/params.h @@ -300,6 +300,6 @@ #define XEN_HVM_MCA_CAP_LMCE (xen_mk_ullong(1) << 0) #define XEN_HVM_MCA_CAP_MASK XEN_HVM_MCA_CAP_LMCE -#define HVM_NR_PARAMS 39 +#define HVM_NR_PARAMS 40 #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */ diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index dbd35305df..f823c784c3 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -620,6 +620,7 @@ struct xen_mem_acquire_resource { #define XENMEM_resource_ioreq_server 0 #define XENMEM_resource_grant_table 1 +#define XENMEM_resource_vmtrace_buf 2 /* * IN - a type-specific resource identifier, which must be zero diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index ac53519d7f..48f0a61bbd 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -457,6 +457,10 @@ struct domain unsigned pbuf_idx; spinlock_t pbuf_lock; + /* Used by vmtrace features */ + spinlock_t vmtrace_lock; + uint64_t vmtrace_pt_size; + /* OProfile support. */ struct xenoprof *xenoprof; diff --git a/xen/include/xlat.lst b/xen/include/xlat.lst index 0921d4a8d0..c15529a43f 100644 --- a/xen/include/xlat.lst +++ b/xen/include/xlat.lst @@ -83,6 +83,7 @@ ? dm_op_set_pci_link_route hvm/dm_op.h ? dm_op_track_dirty_vram hvm/dm_op.h ! hvm_altp2m_set_mem_access_multi hvm/hvm_op.h +? hvm_vmtrace_op hvm/hvm_op.h ? vcpu_hvm_context hvm/hvm_vcpu.h ? vcpu_hvm_x86_32 hvm/hvm_vcpu.h ? vcpu_hvm_x86_64 hvm/hvm_vcpu.h -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:12:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:12:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQvz-0003Ny-T7; Mon, 22 Jun 2020 18:12:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQvy-0003Nh-DG for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:12:42 +0000 X-Inumbo-ID: f6199f74-b4b3-11ea-bca7-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f6199f74-b4b3-11ea-bca7-bc764e2007e4; Mon, 22 Jun 2020 18:12:41 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id B0790A28AD; Mon, 22 Jun 2020 20:12:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A75DAA289F; Mon, 22 Jun 2020 20:12:39 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id if3INixpMjEY; Mon, 22 Jun 2020 20:12:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 12584A28AD; Mon, 22 Jun 2020 20:12:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Zfd4oL12jK0T; Mon, 22 Jun 2020 20:12:38 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id E9E0EA289F; Mon, 22 Jun 2020 20:12:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D1E102025C; Mon, 22 Jun 2020 20:12:08 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id chpGD0rJx_CV; Mon, 22 Jun 2020 20:12:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 1E4C221CDD; Mon, 22 Jun 2020 20:12:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ia2NYqSLHUCw; Mon, 22 Jun 2020 20:12:03 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id F0C3C21CBE; Mon, 22 Jun 2020 20:12:02 +0200 (CEST) Date: Mon, 22 Jun 2020 20:12:02 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Message-ID: <1478140470.11443872.1592849522947.JavaMail.zimbra@cert.pl> In-Reply-To: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> Subject: [PATCH v3 5/7] tools/libxc: add xc_vmtrace_* functions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: tools/libxc: add xc_vmtrace_* functions Thread-Index: fAatEklvenYpYrSWj77J6AQD/dj+xEE0T8id X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Ian Jackson , "Kang, Luwei" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add functions in libxc that use the new HVMOP_vmtrace interface. Signed-off-by: Michal Leszczynski --- tools/libxc/Makefile | 1 + tools/libxc/include/xenctrl.h | 39 +++++++++++++++ tools/libxc/xc_vmtrace.c | 94 +++++++++++++++++++++++++++++++++++ 3 files changed, 134 insertions(+) create mode 100644 tools/libxc/xc_vmtrace.c diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile index fae5969a73..605e44501d 100644 --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -27,6 +27,7 @@ CTRL_SRCS-y += xc_csched2.c CTRL_SRCS-y += xc_arinc653.c CTRL_SRCS-y += xc_rt.c CTRL_SRCS-y += xc_tbuf.c +CTRL_SRCS-y += xc_vmtrace.c CTRL_SRCS-y += xc_pm.c CTRL_SRCS-y += xc_cpu_hotplug.c CTRL_SRCS-y += xc_resume.c diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 113ddd935d..66966f6c17 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -1585,6 +1585,45 @@ int xc_tbuf_set_cpu_mask(xc_interface *xch, xc_cpumap_t mask); int xc_tbuf_set_evt_mask(xc_interface *xch, uint32_t mask); +/** + * Enable processor trace for given vCPU in given DomU. + * Allocate the trace ringbuffer with given size. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @return 0 on success, -1 on failure + */ +int xc_vmtrace_pt_enable(xc_interface *xch, uint32_t domid, + uint32_t vcpu); + +/** + * Disable processor trace for given vCPU in given DomU. + * Deallocate the trace ringbuffer. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @return 0 on success, -1 on failure + */ +int xc_vmtrace_pt_disable(xc_interface *xch, uint32_t domid, + uint32_t vcpu); + +/** + * Get current offset inside the trace ringbuffer. + * This allows to determine how much data was written into the buffer. + * Once buffer overflows, the offset will reset to 0 and the previous + * data will be overriden. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @parm offset current offset inside trace buffer will be written there + * @return 0 on success, -1 on failure + */ +int xc_vmtrace_pt_get_offset(xc_interface *xch, uint32_t domid, + uint32_t vcpu, uint64_t *offset); + int xc_domctl(xc_interface *xch, struct xen_domctl *domctl); int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl); diff --git a/tools/libxc/xc_vmtrace.c b/tools/libxc/xc_vmtrace.c new file mode 100644 index 0000000000..79aad2d9a8 --- /dev/null +++ b/tools/libxc/xc_vmtrace.c @@ -0,0 +1,94 @@ +/****************************************************************************** + * xc_vmtrace.c + * + * API for manipulating hardware tracing features + * + * Copyright (c) 2020, Michal Leszczynski + * + * Copyright 2020 CERT Polska. All rights reserved. + * Use is subject to license terms. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; + * version 2.1 of the License. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; If not, see . + */ + +#include "xc_private.h" +#include + +int xc_vmtrace_pt_enable( + xc_interface *xch, uint32_t domid, uint32_t vcpu) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->cmd = HVMOP_vmtrace_pt_enable; + arg->domain = domid; + arg->vcpu = vcpu; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + +int xc_vmtrace_pt_get_offset( + xc_interface *xch, uint32_t domid, uint32_t vcpu, uint64_t *offset) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->cmd = HVMOP_vmtrace_pt_get_offset; + arg->domain = domid; + arg->vcpu = vcpu; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + if ( rc == 0 ) + { + *offset = arg->offset; + } + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + +int xc_vmtrace_pt_disable(xc_interface *xch, uint32_t domid, uint32_t vcpu) +{ + DECLARE_HYPERCALL_BUFFER(xen_hvm_vmtrace_op_t, arg); + int rc = -1; + + arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg)); + if ( arg == NULL ) + return -1; + + arg->cmd = HVMOP_vmtrace_pt_disable; + arg->domain = domid; + arg->vcpu = vcpu; + + rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_vmtrace, + HYPERCALL_BUFFER_AS_ARG(arg)); + + xc_hypercall_buffer_free(xch, arg); + return rc; +} + -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:13:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:13:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQwP-0003Uk-9j; Mon, 22 Jun 2020 18:13:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQwN-0003UR-OU for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:13:07 +0000 X-Inumbo-ID: 0445adf4-b4b4-11ea-beb6-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0445adf4-b4b4-11ea-beb6-12813bfff9fa; Mon, 22 Jun 2020 18:13:05 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 6DBA2A28AD; Mon, 22 Jun 2020 20:13:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 68515A289F; Mon, 22 Jun 2020 20:13:03 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id o5U_5lY6m-8j; Mon, 22 Jun 2020 20:13:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id CE166A28AD; Mon, 22 Jun 2020 20:13:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CrZv7OGCmzBA; Mon, 22 Jun 2020 20:13:02 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id AA7CEA289F; Mon, 22 Jun 2020 20:13:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 95E6B21760; Mon, 22 Jun 2020 20:12:32 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id iIwhw7ECFOeD; Mon, 22 Jun 2020 20:12:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 05B4721CD0; Mon, 22 Jun 2020 20:12:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zQy07s7sB-yu; Mon, 22 Jun 2020 20:12:26 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id DC4FA21CC8; Mon, 22 Jun 2020 20:12:26 +0200 (CEST) Date: Mon, 22 Jun 2020 20:12:26 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Message-ID: <192922589.11444004.1592849546858.JavaMail.zimbra@cert.pl> In-Reply-To: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> Subject: [PATCH v3 6/7] tools/libxl: add vmtrace_pt_size parameter MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: tools/libxl: add vmtrace_pt_size parameter Thread-Index: fAatEklvenYpYrSWj77J6AQD/dj+xILnWivP X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Ian Jackson , George Dunlap , Anthony PERARD , "Kang, Luwei" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Allow to specify the size of per-vCPU trace buffer upon domain creation. This is zero by default (meaning: not enabled). Signed-off-by: Michal Leszczynski --- docs/man/xl.cfg.5.pod.in | 10 ++++++++++ tools/golang/xenlight/helpers.gen.go | 2 ++ tools/golang/xenlight/types.gen.go | 1 + tools/libxl/libxl_create.c | 1 + tools/libxl/libxl_types.idl | 2 ++ tools/xl/xl_parse.c | 4 ++++ 6 files changed, 20 insertions(+) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index 0532739c1f..78f434b722 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -278,6 +278,16 @@ memory=8096 will report significantly less memory available for use than a system with maxmem=8096 memory=8096 due to the memory overhead of having to track the unused pages. +=item B + +Specifies the size of processor trace buffer that would be allocated +for each vCPU belonging to this domain. Disabled (i.e. B +by default. This must be set to non-zero value in order to be able to +use processor tracing features with this domain. + +B: The size value must be between 4 kB and 4 GB and it must +be also a power of 2. + =back =head3 Guest Virtual NUMA Configuration diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index 935d3bc50a..986ebbd681 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -1117,6 +1117,7 @@ return fmt.Errorf("invalid union key '%v'", x.Type)} x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version) x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart) x.Altp2M = Altp2MMode(xc.altp2m) +x.VmtracePtSize = int(xc.vmtrace_pt_size) return nil} @@ -1592,6 +1593,7 @@ return fmt.Errorf("invalid union key '%v'", x.Type)} xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion) xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart) xc.altp2m = C.libxl_altp2m_mode(x.Altp2M) +xc.vmtrace_pt_size = C.int(x.VmtracePtSize) return nil } diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go index 663c1e86b4..41ec7cdd32 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -516,6 +516,7 @@ GicVersion GicVersion Vuart VuartType } Altp2M Altp2MMode +VmtracePtSize int } type domainBuildInfoTypeUnion interface { diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 75862dc6ed..32204b83b0 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -608,6 +608,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, .max_evtchn_port = b_info->event_channels, .max_grant_frames = b_info->max_grant_frames, .max_maptrack_frames = b_info->max_maptrack_frames, + .vmtrace_pt_size = b_info->vmtrace_pt_size, }; if (info->type != LIBXL_DOMAIN_TYPE_PV) { diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 9d3f05f399..04c1704b72 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -645,6 +645,8 @@ libxl_domain_build_info = Struct("domain_build_info",[ # supported by x86 HVM and ARM support is planned. ("altp2m", libxl_altp2m_mode), + ("vmtrace_pt_size", integer), + ], dir=DIR_IN, copy_deprecated_fn="libxl__domain_build_info_copy_deprecated", ) diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 61b4ef7b7e..6ab98dda55 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1861,6 +1861,10 @@ void parse_config_data(const char *config_source, } } + if (!xlu_cfg_get_long(config, "vmtrace_pt_size", &l, 1)) { + b_info->vmtrace_pt_size = l; + } + if (!xlu_cfg_get_list(config, "ioports", &ioports, &num_ioports, 0)) { b_info->num_ioports = num_ioports; b_info->ioports = calloc(num_ioports, sizeof(*b_info->ioports)); -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:13:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:13:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQwu-0003aq-Iv; Mon, 22 Jun 2020 18:13:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnQwt-0003ab-9P for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:13:39 +0000 X-Inumbo-ID: 172084a8-b4b4-11ea-beb6-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 172084a8-b4b4-11ea-beb6-12813bfff9fa; Mon, 22 Jun 2020 18:13:37 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1B3C0A28AD; Mon, 22 Jun 2020 20:13:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 13EB2A289F; Mon, 22 Jun 2020 20:13:35 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id r3cGg7iykwin; Mon, 22 Jun 2020 20:13:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 5DA99A28AD; Mon, 22 Jun 2020 20:13:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id chuUBgGhswFs; Mon, 22 Jun 2020 20:13:33 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3DECCA289F; Mon, 22 Jun 2020 20:13:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 2C0FD21A1C; Mon, 22 Jun 2020 20:13:03 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id STAM67wBAUGM; Mon, 22 Jun 2020 20:12:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 8159C21CBB; Mon, 22 Jun 2020 20:12:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nNtYkJ-u0RCq; Mon, 22 Jun 2020 20:12:56 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 51A8321CB5; Mon, 22 Jun 2020 20:12:56 +0200 (CEST) Date: Mon, 22 Jun 2020 20:12:56 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Message-ID: <1786138246.11444015.1592849576272.JavaMail.zimbra@cert.pl> In-Reply-To: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> Subject: [PATCH v3 7/7] tools/proctrace: add proctrace tool MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: tools/proctrace: add proctrace tool Thread-Index: fAatEklvenYpYrSWj77J6AQD/dj+xGztgTaA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Ian Jackson , "Kang, Luwei" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Add an demonstration tool that uses xc_vmtrace_* calls in order to manage external IPT monitoring for DomU. Signed-off-by: Michal Leszczynski --- tools/proctrace/COPYING | 339 ++++++++++++++++++++++++++++++++++++ tools/proctrace/Makefile | 50 ++++++ tools/proctrace/proctrace.c | 158 +++++++++++++++++ 3 files changed, 547 insertions(+) create mode 100644 tools/proctrace/COPYING create mode 100644 tools/proctrace/Makefile create mode 100644 tools/proctrace/proctrace.c diff --git a/tools/proctrace/COPYING b/tools/proctrace/COPYING new file mode 100644 index 0000000000..c0a841112c --- /dev/null +++ b/tools/proctrace/COPYING @@ -0,0 +1,339 @@ +=09=09 GNU GENERAL PUBLIC LICENSE +=09=09 Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 59 Temple Place, Suite 330, Boston, MA 02111-1307 = USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + +=09=09=09 Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + +=09=09 GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; o= r, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Softwa= re +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + +=09=09=09 NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITIN= G +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISIN= G +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + +=09=09 END OF TERMS AND CONDITIONS + +=09 How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms= . + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; If not, see . + + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show = w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriat= e +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + , 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program int= o +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with th= e +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. diff --git a/tools/proctrace/Makefile b/tools/proctrace/Makefile new file mode 100644 index 0000000000..76d7387a64 --- /dev/null +++ b/tools/proctrace/Makefile @@ -0,0 +1,50 @@ +# Copyright (C) CERT Polska - NASK PIB +# Author: Micha=C5=82 Leszczy=C5=84ski +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; under version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +XEN_ROOT=3D$(CURDIR)/../.. +include $(XEN_ROOT)/tools/Rules.mk + +CFLAGS +=3D -Werror +CFLAGS +=3D $(CFLAGS_libxenevtchn) +CFLAGS +=3D $(CFLAGS_libxenctrl) +LDLIBS +=3D $(LDLIBS_libxenctrl) +LDLIBS +=3D $(LDLIBS_libxenevtchn) +LDLIBS +=3D $(LDLIBS_libxenforeignmemory) + +# SCRIPTS =3D xenmon.py + +.PHONY: all +all: build + +.PHONY: build +build: proctrace + +.PHONY: install +install: build +=09$(INSTALL_DIR) $(DESTDIR)$(sbindir) +=09$(INSTALL_PROG) proctrace $(DESTDIR)$(sbindir)/proctrace + +.PHONY: uninstall +uninstall: +=09rm -f $(DESTDIR)$(sbindir)/proctrace + +.PHONY: clean +clean: +=09$(RM) -f $(DEPS_RM) + +.PHONY: distclean +distclean: clean + +iptlive: iptlive.o Makefile +=09$(CC) $(LDFLAGS) $< -o $@ $(LDLIBS) $(APPEND_LDFLAGS) + +-include $(DEPS_INCLUDE) diff --git a/tools/proctrace/proctrace.c b/tools/proctrace/proctrace.c new file mode 100644 index 0000000000..dddc6515f8 --- /dev/null +++ b/tools/proctrace/proctrace.c @@ -0,0 +1,158 @@ +/*************************************************************************= ***** + * tools/proctrace.c + * + * Demonstrative tool for collecting Intel Processor Trace data from Xen. + * Could be used to externally monitor a given vCPU in given DomU. + * + * Copyright (C) 2020 by CERT Polska - NASK PIB + * + * Authors: Micha=C5=82 Leszczy=C5=84ski, michal.leszczynski@cert.pl + * Date: June, 2020 + *=20 + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; under version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; If not, see . + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#define XC_WANT_COMPAT_MAP_FOREIGN_API +#include +#include + +#define BUF_SIZE 16384 * 4096 + +volatile int interrupted =3D 0; + +void term_handler(int signum) { + interrupted =3D 1; +} + +int main(int argc, char* argv[]) { + xc_interface *xc; + uint32_t domid; + uint32_t vcpu_id; + + int rc =3D -1; + uint8_t *buf =3D NULL; + uint64_t last_offset =3D 0; + + xenforeignmemory_handle* fmem; + xenforeignmemory_resource_handle *fres; + + signal(SIGINT, term_handler); + + if (argc !=3D 3) { + fprintf(stderr, "Usage: %s \n", argv[0]); + fprintf(stderr, "It's recommended to redirect this" + "program's output to file\n"); + fprintf(stderr, "or to pipe it's output to xxd or other program.\n= "); + return 1; + } + + domid =3D atoi(argv[1]); + vcpu_id =3D atoi(argv[2]); + + xc =3D xc_interface_open(0, 0, 0); + + fmem =3D xenforeignmemory_open(0, 0); + + if (!xc) { + fprintf(stderr, "Failed to open xc interface\n"); + return 1; + } + + rc =3D xc_vmtrace_pt_enable(xc, domid, vcpu_id); + + if (rc) { + fprintf(stderr, "Failed to call xc_vmtrace_pt_enable\n"); + return 1; + } + + fres =3D xenforeignmemory_map_resource( + fmem, domid, XENMEM_resource_vmtrace_buf, + /* vcpu: */ vcpu_id, + /* frame: */ 0, + /* num_frames: */ BUF_SIZE >> XC_PAGE_SHIFT, + (void **)&buf, + PROT_READ, 0); + + if (!buf) { + fprintf(stderr, "Failed to map trace buffer\n"); + return 1; + } + + while (!interrupted) { + uint64_t offset; + rc =3D xc_vmtrace_pt_get_offset(xc, domid, vcpu_id, &offset); + + if (rc) { + fprintf(stderr, "Failed to call xc_vmtrace_pt_get_offset\n"); + return 1; + } + + if (offset > last_offset) + { + fwrite(buf + last_offset, offset - last_offset, 1, stdout); + } + else if (offset < last_offset) + { + // buffer wrapped + fwrite(buf + last_offset, BUF_SIZE - last_offset, 1, stdout); + fwrite(buf, offset, 1, stdout); + } + + last_offset =3D offset; + usleep(1000 * 100); + } + + rc =3D xenforeignmemory_unmap_resource(fmem, fres); + + if (rc) { + fprintf(stderr, "Failed to unmap resource\n"); + return 1; + } + + rc =3D xc_vmtrace_pt_disable(xc, domid, vcpu_id); + + if (rc) { + fprintf(stderr, "Failed to call xc_vmtrace_pt_disable\n"); + return 1; + } + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ --=20 2.20.1 From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:20:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:20:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnR3Y-0004dd-Ee; Mon, 22 Jun 2020 18:20:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnR3X-0004dY-Il for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:20:31 +0000 X-Inumbo-ID: 0dea60d8-b4b5-11ea-b7bb-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0dea60d8-b4b5-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 18:20:30 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 0A645A289F; Mon, 22 Jun 2020 20:20:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 003A7A2860; Mon, 22 Jun 2020 20:20:28 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id bo3toW_T4XV9; Mon, 22 Jun 2020 20:20:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 22AA7A289F; Mon, 22 Jun 2020 20:20:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DFDwG06CTQ1j; Mon, 22 Jun 2020 20:20:27 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id EBCEBA2860; Mon, 22 Jun 2020 20:20:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id D6FA821C91; Mon, 22 Jun 2020 20:19:56 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id TxhTAidltDwQ; Mon, 22 Jun 2020 20:19:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 8478121C93; Mon, 22 Jun 2020 20:19:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3N-Ukwlvsuc1; Mon, 22 Jun 2020 20:19:51 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 6329721C91; Mon, 22 Jun 2020 20:19:51 +0200 (CEST) Date: Mon, 22 Jun 2020 20:19:51 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Message-ID: <1731956046.11444288.1592849991363.JavaMail.zimbra@cert.pl> In-Reply-To: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> Subject: Re: [PATCH v3 0/7] Implement support for external IPT monitoring MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: Implement support for external IPT monitoring Thread-Index: fAatEklvenYpYrSWj77J6AQD/dj+xC9WPo0B X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jan Beulich , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Tamas K Lengyel , Jun Nakajima , Anthony PERARD , "Kang, Luwei" , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 22 cze 2020 o 20:06, Micha=C5=82 Leszczy=C5=84ski michal.leszczynski@= cert.pl napisa=C5=82(a): > This patch series implements an interface that Dom0 could use in order to > enable IPT for particular vCPUs in DomU, allowing for external monitoring= . Such > a feature has numerous applications like malware monitoring, fuzzing, or > performance testing. There is also a git branch with these patches: https://github.com/icedevml/xen/tree/ipt-patch-v3b From xen-devel-bounces@lists.xenproject.org Mon Jun 22 18:44:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 18:44:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnRQx-0006XP-Ds; Mon, 22 Jun 2020 18:44:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnRQv-0006XK-W0 for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 18:44:42 +0000 X-Inumbo-ID: 6e3ce688-b4b8-11ea-bb8b-bc764e2007e4 Received: from mail-lf1-x142.google.com (unknown [2a00:1450:4864:20::142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6e3ce688-b4b8-11ea-bb8b-bc764e2007e4; Mon, 22 Jun 2020 18:44:41 +0000 (UTC) Received: by mail-lf1-x142.google.com with SMTP id g2so10260033lfb.0 for ; Mon, 22 Jun 2020 11:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bsa2D8UcUdmWeSVi19Th9t5QWO+7dW+3wkTgqvnKWig=; b=rkI2USsN/jAc+p2oilopycy25wr5sVI0tpE2XgEi6pMS/rAQbP7Hu26UR19nfOq1AJ 1Np5Qo2/xMDdO95rUi5ytBqxbCK2w4BlWMl5z+bmsPHMTUSBbdJt5DbMQuaFAHu3GsE3 hwGcOZtlqQSOx98Ccw6FViwLUqd8WVOjvdPIk8D9wZMA9ReaVhAYgEHpiR64jXe9FJKD SSXVNwkefgbQAKI/mrun0pFeINVWBsg+T/l3iCorhuci/7B5/ehgHBErhOy9GFBHPr08 lmKZj+cqwUytlTTcH2nJyWykLOcJJ/aZT0F2qIBlAhfLdLnxlmRp+NlswiEiG6VvnbO5 PZow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bsa2D8UcUdmWeSVi19Th9t5QWO+7dW+3wkTgqvnKWig=; b=NCPbRw5i148Jo4wHfo209iXL1S5n4SsxVFPn6zX+FUklnT5uro2sbJawE8Flvs9CTW WmnacfV1P508z8+K5kuAsINr4FzEuGiK+KkJvM+9t4ntT5uphrwtRyR4Qj/0JI27QkaS NfV+8AKzwEu5ts6tyM8fj4WfYBtHedF5oH5WkDiZwMX2rio0gnjyVkD5Z1DCYK7ILzQ2 2Ws0hG5gtIUSgadoPszYMF557JYFh57sp2NoQbelX4jHI2nADCODdQcpDWvbT4cJDtP2 w1d9l3luZ5Hh2J6msgbjL9hVXTf7Q652rbd5UaCus4rqCxS+OzJqcCOX58DwYU9T/Okk +AAg== X-Gm-Message-State: AOAM530Sl1KlmPFKtNdONnXHuIw5ikCtBdoJwxPVTYVW8ingSUcYtv2C o84fOmua4sC+ct1fEHKhz1bHl5cV/vBQkH+QF/g= X-Google-Smtp-Source: ABdhPJxr4uBUcKdGTWVm9gTrdLJWlX+Uz75PHVP1LlPA9Qi3PeqXxZmwj0YtBtqv0zY1bHUzBIsUY0GR1ixqYwH0wio= X-Received: by 2002:a19:c744:: with SMTP id x65mr10603363lff.133.1592851479925; Mon, 22 Jun 2020 11:44:39 -0700 (PDT) MIME-Version: 1.0 References: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> In-Reply-To: From: Souptick Joarder Date: Tue, 23 Jun 2020 00:22:56 +0530 Message-ID: Subject: Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: John Hubbard Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, paul@xen.org, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Boris Ostrovsky Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 19, 2020 at 1:00 PM John Hubbard wrote: > > On 2020-06-18 20:12, Souptick Joarder wrote: > > On Wed, Jun 17, 2020 at 11:29 PM Boris Ostrovsky > > wrote: > >> > >> On 6/16/20 11:14 PM, Souptick Joarder wrote: > >>> In 2019, we introduced pin_user_pages*() and now we are converting > >>> get_user_pages*() to the new API as appropriate. [1] & [2] could > >>> be referred for more information. > > > Ideally, the commit description should say which case, in > pin_user_pages.rst, that this is. > Ok. > > >>> > >>> [1] Documentation/core-api/pin_user_pages.rst > >>> > >>> [2] "Explicit pinning of user-space pages": > >>> https://lwn.net/Articles/807108/ > >>> > >>> Signed-off-by: Souptick Joarder > >>> Cc: John Hubbard > >>> --- > >>> Hi, > >>> > >>> I have compile tested this patch but unable to run-time test, > >>> so any testing help is much appriciated. > >>> > >>> Also have a question, why the existing code is not marking the > >>> pages dirty (since it did FOLL_WRITE) ? > >> > >> > >> Indeed, seems to me it should. Paul? > > Definitely good to get an answer from an expert in this code, but > meanwhile, it's reasonable to just mark them dirty. Below... > > >> > >> > >>> > >>> drivers/xen/privcmd.c | 7 ++----- > >>> 1 file changed, 2 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > >>> index a250d11..543739e 100644 > >>> --- a/drivers/xen/privcmd.c > >>> +++ b/drivers/xen/privcmd.c > >>> @@ -594,7 +594,7 @@ static int lock_pages( > >>> if (requested > nr_pages) > >>> return -ENOSPC; > >>> > >>> - pinned = get_user_pages_fast( > >>> + pinned = pin_user_pages_fast( > >>> (unsigned long) kbufs[i].uptr, > >>> requested, FOLL_WRITE, pages); > >>> if (pinned < 0) > >>> @@ -614,10 +614,7 @@ static void unlock_pages(struct page *pages[], unsigned int nr_pages) > >>> if (!pages) > >>> return; > >>> > >>> - for (i = 0; i < nr_pages; i++) { > >>> - if (pages[i]) > >>> - put_page(pages[i]); > >>> - } > >>> + unpin_user_pages(pages, nr_pages); > > > ...so just use unpin_user_pages_dirty_lock() here, I think. > > > >> > >> > >> Why are you no longer checking for valid pages? > > > > My understanding is, in case of lock_pages() end up returning partial > > mapped pages, > > we should pass no. of partial mapped pages to unlock_pages(), not nr_pages. > > This will avoid checking extra check to validate the pages[i]. > > > > and if lock_pages() returns 0 in success, anyway we have all the pages[i] valid. > > I will try to correct it in v2. > > > > But I agree, there is no harm to check for pages[i] and I believe, > > > Generally, it *is* harmful to do unnecessary checks, in most code, but especially > in most kernel code. If you can convince yourself that the check for null pages > is redundant here, then please let's remove that check. The code becomes then > becomes shorter, simpler, and faster. I read the code again. I think, this check is needed to handle a scenario when lock_pages() return -ENOSPC. Better to keep this check. Let me post v2 of this RFC for a clear view. > > > > unpin_user_pages() > > is the right place to do so. > > > > John any thought ? > > > So far I haven't seen any cases to justify changing the implementation of > unpin_user_pages(). > > > thanks, > -- > John Hubbard > NVIDIA From xen-devel-bounces@lists.xenproject.org Mon Jun 22 19:11:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 19:11:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnRqT-0000ph-HG; Mon, 22 Jun 2020 19:11:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnRqR-0000pc-IS for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 19:11:03 +0000 X-Inumbo-ID: 1c31c833-b4bc-11ea-bebf-12813bfff9fa Received: from aserp2120.oracle.com (unknown [141.146.126.78]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1c31c833-b4bc-11ea-bebf-12813bfff9fa; Mon, 22 Jun 2020 19:11:02 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05MIvcUe015162; Mon, 22 Jun 2020 19:10:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=YTvW6KF022iWqscuEpgkJdymiHV7M4r563GhRk8Gi08=; b=skkVmVom6vtg02f1frWfAAG9oc0kZ1AMSB2aidKGJn0QJ+tlVVRXVA1mBy15k6Detpkw eZWa1xL3AjvrCNUr5saBcqQIzfK1Ub6/LWHBJQuo4FURD5upkaqa0JIQkc50wJS7b+3o Yw9/b+ws2wvQoBP3MOUtgWey38+GSK1IsROHwNNacxzWpEiFtVsPXIXzhW0w8C4INJsz zL7d6sTg1khqrTaG2IHXtNC3T5d8MQFWqS+u3Yd6V6SbrmsPCtLdrcm2ZLS3ocIGWDuz 3tkcLwPXaNLK2xasPuHbsXWZOrkKMCXmXcFZbKnKhRimlOMM9WMWouCbkjUeVeURplUM 2w== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 31sebb97nw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 22 Jun 2020 19:10:59 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05MIw6Y3075152; Mon, 22 Jun 2020 19:10:58 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 31sv7qkhdy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Jun 2020 19:10:58 +0000 Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 05MJAuEt010530; Mon, 22 Jun 2020 19:10:56 GMT Received: from [10.39.220.59] (/10.39.220.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Jun 2020 19:10:56 +0000 Subject: Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Souptick Joarder , John Hubbard References: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <5a5133e6-b84d-a2cc-fcb4-db85c4e65d62@oracle.com> Date: Mon, 22 Jun 2020 15:10:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9660 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006220126 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9660 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 cotscore=-2147483648 lowpriorityscore=0 phishscore=0 bulkscore=0 clxscore=1015 impostorscore=0 malwarescore=0 priorityscore=1501 spamscore=0 mlxscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006220126 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , xen-devel@lists.xenproject.org, sstabellini@kernel.org, linux-kernel@vger.kernel.org, paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/22/20 2:52 PM, Souptick Joarder wrote: > > I read the code again. I think, this check is needed to handle a scenar= io when > lock_pages() return -ENOSPC. Better to keep this check. Let me post v2 = of this > RFC for a clear view. Actually, error handling seems to be somewhat broken here. If lock_pages() returns number of pinned pages then that's what we end up returning from privcmd_ioctl_dm_op(), all the way to user ioctl(). Which I don't think is right, we should return proper (negative) error. Do you mind fixing that we well? Then you should be able to avoid testing pages in a loop. -boris From xen-devel-bounces@lists.xenproject.org Mon Jun 22 19:20:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 19:20:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnRzR-0001no-Dc; Mon, 22 Jun 2020 19:20:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnRzQ-0001nj-2l for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 19:20:20 +0000 X-Inumbo-ID: 688cd16c-b4bd-11ea-b7bb-bc764e2007e4 Received: from mail-lf1-x142.google.com (unknown [2a00:1450:4864:20::142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 688cd16c-b4bd-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 19:20:19 +0000 (UTC) Received: by mail-lf1-x142.google.com with SMTP id y18so1677351lfh.11 for ; Mon, 22 Jun 2020 12:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FQGOol6oHmAM1Ng4z/uCNOq7Oann9kEoHMOFg8EwYLs=; b=IFBDbRGuOV6E9NDzvc7om4hzvpex+EGEmN8GTzzHydmrjGWlNV1uO2E/g0yWsPAWi9 zjE8fuW1yOUP8g12Xuq00kdOTLqwSAJjTTg4ZhbhSNW78kg7QgBPir5Ap1BUj/a16o21 J57EE3or5bby4Cv0SEw6LiqfvNQgXwWltI7MvZlT8kzMM3Tsk60+advzEk7PdkR7W8ew lAX4Uf72XIJc7hIEhbjko+c/4/DUWSRg2tWy/gAaZ6fE3lyf47k3iqQJVh4oETlneyHj rbyugQ5vCtpTGtNlXxITC7wQNanT6yfSqWFi8FTnk95apjQCxRAxuFuuW7sA49kDUMsN wbTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FQGOol6oHmAM1Ng4z/uCNOq7Oann9kEoHMOFg8EwYLs=; b=QQPqW8lF3daF5ru+UGgWBtSvYCaOmWFv9I6SL14yN82gshU1Brm4JEHT+6l8Sn7cnU 8vAycMXdRUDBfqQG9EAh2ozcIRb0CChS1PjRsxo+I57k/L5oPmowtvbsJaQM2YEpm57b qTHEAmBoCmKVIPYbF71XT9SDv5AC7iNuj3lORWpFvZfjIHSa9txDtabkVjWLosYRXUKQ Ap1tlt5IW98xnRU7/lY2G0Dk1Zoiba/RESK5VbGeqHEDbJs61qzPeHFT04x8SkhtrAB4 nHeYYU8uAju8kO7X6BKfftk2e3itviKwsnfvpDX1/6s26y3v+0UpGEu6rufJCxiY2nvE mHeg== X-Gm-Message-State: AOAM531phwGYfINbqbsir3VdPyQNLmcnPsmlhinXO+7m+obLDtEgsrY0 bo+xWezq/1ewQcyaRtcyoKfAqnS4fLYAt4E1vI0= X-Google-Smtp-Source: ABdhPJz4RZaNe5vITzo3tnXIR0fi+rJgtxh0xTAogXKk2pl7INIbw94pdlI6wWGIyDWeWTdqocO4Dka7MgKG6ttG2UI= X-Received: by 2002:a19:b07:: with SMTP id 7mr10494968lfl.38.1592853617855; Mon, 22 Jun 2020 12:20:17 -0700 (PDT) MIME-Version: 1.0 References: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> <5a5133e6-b84d-a2cc-fcb4-db85c4e65d62@oracle.com> In-Reply-To: <5a5133e6-b84d-a2cc-fcb4-db85c4e65d62@oracle.com> From: Souptick Joarder Date: Tue, 23 Jun 2020 00:58:32 +0530 Message-ID: Subject: Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Boris Ostrovsky Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, paul@xen.org, John Hubbard , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 12:40 AM Boris Ostrovsky wrote: > > On 6/22/20 2:52 PM, Souptick Joarder wrote: > > > > I read the code again. I think, this check is needed to handle a scenario when > > lock_pages() return -ENOSPC. Better to keep this check. Let me post v2 of this > > RFC for a clear view. > > > Actually, error handling seems to be somewhat broken here. If > lock_pages() returns number of pinned pages then that's what we end up > returning from privcmd_ioctl_dm_op(), all the way to user ioctl(). Which > I don't think is right, we should return proper (negative) error. > What -ERRNO is more appropriate here ? -ENOSPC ? > > Do you mind fixing that we well? Then you should be able to avoid > testing pages in a loop. Ok, let me try to fix it. > > > -boris > From xen-devel-bounces@lists.xenproject.org Mon Jun 22 19:27:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 19:27:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnS6d-000253-85; Mon, 22 Jun 2020 19:27:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnS6c-00024v-0H for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 19:27:46 +0000 X-Inumbo-ID: 72b6dcea-b4be-11ea-bec3-12813bfff9fa Received: from userp2130.oracle.com (unknown [156.151.31.86]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 72b6dcea-b4be-11ea-bec3-12813bfff9fa; Mon, 22 Jun 2020 19:27:45 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05MJIMZA047465; Mon, 22 Jun 2020 19:27:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=AFeKQK+7PpeSsuTM9GbzxOWXuT7baNsIyUiZ9VdcdPw=; b=WnDSvRDeptablqMg2WNo/yaqlTQX3NsA1DgFZSBivqa0n07pfQEaxfNz8m9OeROVyAmG PHobFvGxFZ1M+DFJUT4JrwA+trJn77+Ve5Nv+j3l42ZnKOvBFhe4XP2Rtq9oPFnTKW76 nYONLdcQkeAVX9C7ElEyPzEH/2R/bUOTLH5/U5to5TRO8EQmgejJ0CBJphsKg8QAogM1 A3dEKVzWGv6PYbzhAFJtLM8ebggfwU/IzkPscK070MNF18mQIjZdJN4sowuDbe+r2V3l jFknOzGLAaj+pAH2VMXFL9JUf36AT8XlpTRM9Hw9A0lpuWrvt0+a0Aruq4EoC76ovNZS uQ== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 31sebbh8vd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 22 Jun 2020 19:27:42 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05MJO6wN008547; Mon, 22 Jun 2020 19:25:42 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 31sv7qm43j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Jun 2020 19:25:42 +0000 Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 05MJPe8P017178; Mon, 22 Jun 2020 19:25:41 GMT Received: from [10.39.220.59] (/10.39.220.59) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Jun 2020 19:25:40 +0000 Subject: Re: [RFC PATCH] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Souptick Joarder References: <1592363698-4266-1-git-send-email-jrdr.linux@gmail.com> <5a5133e6-b84d-a2cc-fcb4-db85c4e65d62@oracle.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: Date: Mon, 22 Jun 2020 15:25:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9660 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 suspectscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006220127 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9660 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 lowpriorityscore=0 mlxlogscore=999 cotscore=-2147483648 mlxscore=0 phishscore=0 priorityscore=1501 malwarescore=0 bulkscore=0 suspectscore=0 clxscore=1015 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006220127 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, paul@xen.org, John Hubbard , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/22/20 3:28 PM, Souptick Joarder wrote: > On Tue, Jun 23, 2020 at 12:40 AM Boris Ostrovsky > wrote: >> On 6/22/20 2:52 PM, Souptick Joarder wrote: >>> I read the code again. I think, this check is needed to handle a scenario when >>> lock_pages() return -ENOSPC. Better to keep this check. Let me post v2 of this >>> RFC for a clear view. >> >> Actually, error handling seems to be somewhat broken here. If >> lock_pages() returns number of pinned pages then that's what we end up >> returning from privcmd_ioctl_dm_op(), all the way to user ioctl(). Which >> I don't think is right, we should return proper (negative) error. >> > What -ERRNO is more appropriate here ? -ENOSPC ? You can simply pass along error code that get_user_pages_fast() returned. -boris From xen-devel-bounces@lists.xenproject.org Mon Jun 22 20:33:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 20:33:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnT87-0008Ii-Ag; Mon, 22 Jun 2020 20:33:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnT86-0008Id-DO for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 20:33:22 +0000 X-Inumbo-ID: 9ca6235e-b4c7-11ea-8496-bc764e2007e4 Received: from mail-lf1-x136.google.com (unknown [2a00:1450:4864:20::136]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9ca6235e-b4c7-11ea-8496-bc764e2007e4; Mon, 22 Jun 2020 20:33:21 +0000 (UTC) Received: by mail-lf1-x136.google.com with SMTP id m26so10401938lfo.13 for ; Mon, 22 Jun 2020 13:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4mVoyL2zNAqGyZ2Atn/eutyBqxa/yw21nCBslNZLJdY=; b=suJxtYlckZvugRErHhopXGyvzHiGcRVutgVuU6LAyvY5obkxUo9d5YvFy2FH6VIf+h 6HUb42wgZ9QVWgySM7Y2/kfUMqHeB99U7nuJHiK1dFjpvtL7T9+xa1eqUAZVwV3tPIob KEVlQGduAdP++XpMZjmet+dd26ipYaZq4jDWQ4rdIoHYMIJn/Cp0crgb9HOjLUjTWAOU TLeMeJp3dGAHXRoBvEaNLvMDr1h5U7NBrakXkg95GIrxpgkdp4MSnJ/xV2pHgz2o4zol HC0+/9s+rMPJqs2yzYPVGEr0y3VCyFqgcMUypdonGwGLKarw5Kb5Q5qqtkzV2k2r8SAe paAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4mVoyL2zNAqGyZ2Atn/eutyBqxa/yw21nCBslNZLJdY=; b=l9WJrqqILuyMiIE+WLQ6bOibcRduDtkAadzyr3LgrRiJ/+/cCDYDgl2pOdxqh1Qu90 bMzZqH7er2VQhUAcjB+cq+rsn6Dzg+zrJotFKA9E4q4+MSoUXuqTmOEybemTuRbWVr5a Zb+jQFft1WRTWIZWJtkycbiT220MpYGNoqtN+J6G7FsbAJbJH0ygXeAE9FkgD5lbhG6l 3PhEIKlksqs/998jEtGGGkGMxnQSHICbdqecEmal24VvyhyHDsDgMRaWTjeelIIn5uGH q3+aCxTQwq4Xpq/LJNYtQvVb7ERjJE05bpFtPJvcl+eS6bTw7/xkDKZhzROF2XmTBHct lA/w== X-Gm-Message-State: AOAM531dIZvwoRxJOVrHOTrknqYiUT7sgMeoWql/FHOFiZTFH0Rtxbc4 nZ4WRonwrorpxoAp+5tSeazOZ4FMFPt5U5YKNn4= X-Google-Smtp-Source: ABdhPJyEtjtgqI457ZpiHwadW+wM55mq6wUWDwE/hJk43J7BbO+VFenO9m7QvkMe8EQ9JuKmhBBlfP7JPenXEqkW8gw= X-Received: by 2002:a05:6512:3049:: with SMTP id b9mr10668922lfb.44.1592858000356; Mon, 22 Jun 2020 13:33:20 -0700 (PDT) MIME-Version: 1.0 From: Jason Andryuk Date: Mon, 22 Jun 2020 16:33:09 -0400 Message-ID: Subject: sysbus failed assert for xen_sysdev To: QEMU , Markus Armbruster , xen-devel , Anthony PERARD , Paul Durrant Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, Running qemu devel for a Xen VM is failing an assert after the recent "qdev: Rework how we plug into the parent bus" sysbus changes. qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' failed. dc->bus_type is "xen-sysbus" and it's the `object_dynamic_cast(OBJECT(bus), dc->bus_type)` portion that fails the assert. bus seems to be "main-system-bus", I think: (gdb) p *bus $3 = {obj = {class = 0x55555636d780, free = 0x7ffff7c40db0 , properties = 0x5555563f7180, ref = 3, parent = 0x5555563fe980}, parent = 0x0, name = 0x5555563fec60 "main-system-bus", ... The call comes from hw/xen/xen-legacy-backend.c:706 sysbus_realize_and_unref(SYS_BUS_DEVICE(xen_sysdev), &error_fatal); Any pointers on what needs to be fixed? Thanks, Jason From xen-devel-bounces@lists.xenproject.org Mon Jun 22 21:01:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 21:01:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnTZF-0002aw-FP; Mon, 22 Jun 2020 21:01:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnTZD-0002aa-Ko for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 21:01:23 +0000 X-Inumbo-ID: 834b92c8-b4cb-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 834b92c8-b4cb-11ea-8496-bc764e2007e4; Mon, 22 Jun 2020 21:01:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Message-Id:Subject:To:Sender: Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SUdG+LnLv3W/YDt8N+Cr2enhbpty9uMhV6qQnjBWJOw=; b=RPCoQWmpMwW3zi6CXXu3dr+T0Y l1IqISr00kxwtJrKN4/KkYIeezLXw9kjBeZXB9ktcNpYmLqY3JptIqw8RN4p9QA030RkvlCyr4I6a ANImOrEpjXXJqWndXeBY8thXut0E9qW3e4YzdWq+geubyx/Hg5o2BY1mpJXljyVMNrK0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnTZ5-0008Bn-Ky; Mon, 22 Jun 2020 21:01:15 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnTZ5-0007uV-4h; Mon, 22 Jun 2020 21:01:15 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnTZ5-0004rr-45; Mon, 22 Jun 2020 21:01:15 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Subject: [qemu-mainline bisection] complete test-amd64-i386-freebsd10-amd64 Message-Id: From: osstest service owner Date: Mon, 22 Jun 2020 21:01:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" branch xen-unstable xenbranch xen-unstable job test-amd64-i386-freebsd10-amd64 testid guest-start Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 81cb05732efb36971901c515b007869cc1d3a532 Bug not present: d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/151298/ commit 81cb05732efb36971901c515b007869cc1d3a532 Author: Markus Armbruster Date: Tue Jun 9 14:23:37 2020 +0200 qdev: Assert devices are plugged into a bus that can take them This would have caught some of the bugs I just fixed. Signed-off-by: Markus Armbruster Reviewed-by: Mark Cave-Ayland Message-Id: <20200609122339.937862-23-armbru@redhat.com> For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-i386-freebsd10-amd64.guest-start.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Running cs-bisection-step --graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-i386-freebsd10-amd64.guest-start --summary-out=tmp/151298.bisection-summary --basis-template=151065 --blessings=real,real-bisect qemu-mainline test-amd64-i386-freebsd10-amd64 guest-start Searching for failure / basis pass: 151269 fail [host=chardonnay1] / 151149 [host=pinot1] 151101 [host=fiano1] 151065 [host=huxelrebe0] 151047 [host=fiano0] 150970 [host=pinot0] 150930 [host=huxelrebe1] 150916 [host=elbling0] 150909 [host=huxelrebe0] 150895 [host=debina1] 150831 [host=elbling1] 150694 [host=fiano0] 150631 ok. Failure / basis pass flights: 151269 / 150631 (tree with no url: minios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 239b50a863704f7960525799eda82de061c7c458 3c659044118e34603161457db9934a34f816d78b 06c4cc3660b366278bdc7bc8b6677032d7b1118c 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9-239b50a863704f7960525799eda82de061c7c458 git://xenbits.xen.org/qemu-xen-traditional.git#3c659044118e34603161457db99\ 34a34f816d78b-3c659044118e34603161457db9934a34f816d78b git://git.qemu.org/qemu.git#5cc7a54c2e91d82cb6a52e4921325c511fd90712-06c4cc3660b366278bdc7bc8b6677032d7b1118c git://xenbits.xen.org/osstest/seabios.git#2e3de6253422112ae43e608661ba94ea6b345694-2e3de6253422112ae43e608661ba94ea6b345694 git://xenbits.xen.org/xen.git#1497e78068421d83956f8e82fb6e1bf1fc3b1199-3625b04991b4d6affadd99d377ab84bac48dfff4 Loaded 84118 nodes in revision graph Searching for test results: 150631 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 150694 [host=fiano0] 150831 [host=elbling1] 150909 [host=huxelrebe0] 150930 [host=huxelrebe1] 150916 [host=elbling0] 150895 [host=debina1] 150899 [] 150970 [host=pinot0] 151047 [host=fiano0] 151101 [host=fiano1] 151065 [host=huxelrebe0] 151149 [host=pinot1] 151244 pass irrelevant 151221 fail irrelevant 151239 blocked irrelevant 151253 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 567bc4b4ae8a975791382dd30ac413bc0d3ce88c 3c659044118e34603161457db9934a34f816d78b eea8f5df4ecc607d64f091b8d916fcc11a697541 2e3de6253422112ae43e608661ba94ea6b345694 2995d0afdf2d3fb44d07eada088db3613741db1e 151175 fail irrelevant 151257 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 567bc4b4ae8a975791382dd30ac413bc0d3ce88c 3c659044118e34603161457db9934a34f816d78b 3575b0aea983ad57804c9af739ed8ff7bc168393 2e3de6253422112ae43e608661ba94ea6b345694 b91825f628c9a62cf2a3a0d972ea81484a8b7fce 151240 fail irrelevant 151250 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 e1d24410da356731da70b3334f86343e11e207d2 3c659044118e34603161457db9934a34f816d78b 470dd165d152ff7ceac61c7b71c2b89220b3aad7 2e3de6253422112ae43e608661ba94ea6b345694 6a49b9a7920c82015381740905582b666160d955 151242 fail irrelevant 151222 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151238 fail irrelevant 151243 pass irrelevant 151247 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3ee4f6cb360a877d171f2f9bb76b0d46d2cfa985 3c659044118e34603161457db9934a34f816d78b 9f1f264edbdf5516d6f208497310b3eedbc7b74c 2e3de6253422112ae43e608661ba94ea6b345694 2995d0afdf2d3fb44d07eada088db3613741db1e 151256 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 3c659044118e34603161457db9934a34f816d78b 86e8c353f705f14f2f2fd7a6195cefa431aa24d9 2e3de6253422112ae43e608661ba94ea6b345694 058023b343d4e366864831db46e9b438e9e3a178 151258 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 3c659044118e34603161457db9934a34f816d78b 49ee11555262a256afec592dfed7c5902d5eefd2 2e3de6253422112ae43e608661ba94ea6b345694 726c78d14dfe6ec76f5e4c7756821a91f0a04b34 151259 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae 3c659044118e34603161457db9934a34f816d78b 5d2f557b47dfbf8f23277a5bdd8473d4607c681a 2e3de6253422112ae43e608661ba94ea6b345694 51ca66c37371b10b378513af126646de22eddb17 151267 fail irrelevant 151261 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae 3c659044118e34603161457db9934a34f816d78b 7d2410cea154bf915fb30179ebda3b17ac36e70e 2e3de6253422112ae43e608661ba94ea6b345694 780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 151241 fail irrelevant 151262 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae 3c659044118e34603161457db9934a34f816d78b d64c1bd6ca0323e9e5e848c6a8193dc12ab1273e 2e3de6253422112ae43e608661ba94ea6b345694 51ca66c37371b10b378513af126646de22eddb17 151266 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151297 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151270 fail irrelevant 151298 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151272 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 58ae92a993687d913aa6dd00ef3497a1bc5f6c40 3c659044118e34603161457db9934a34f816d78b 54cdfe511219b8051046be55a6e156c4f08ff7ff 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151274 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a2433243fbe471c250d7eddc2c7da325d91265fd 3c659044118e34603161457db9934a34f816d78b 6675a653d2e57ab09c32c0ea7b44a1d6c40a7f58 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151275 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 53550e81e2cafe7c03a39526b95cd21b5194d9b1 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151277 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 250bc43a406f7d46e319abe87c19548d4f027828 2e3de6253422112ae43e608661ba94ea6b345694 3371ced37ced359167b5a71abee2062854371323 151278 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 567bc4b4ae8a975791382dd30ac413bc0d3ce88c 3c659044118e34603161457db9934a34f816d78b 23374a84c5f08e20ec2506a6322330d51f9134c5 2e3de6253422112ae43e608661ba94ea6b345694 2995d0afdf2d3fb44d07eada088db3613741db1e 151280 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b da9630c57ee386f8beb571ba6bb4a98d546c42ca 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151281 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 7d3660e79830a069f1848bb4fa1cdf8f666424fb 2e3de6253422112ae43e608661ba94ea6b345694 b91825f628c9a62cf2a3a0d972ea81484a8b7fce 151282 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b efa0559547e7e2c10dee16a78066176c1ea75e97 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151269 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 239b50a863704f7960525799eda82de061c7c458 3c659044118e34603161457db9934a34f816d78b 06c4cc3660b366278bdc7bc8b6677032d7b1118c 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151284 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 75a6ed875ff0a2eb6b2971ae2098ed09963d7329 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151285 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151287 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 239b50a863704f7960525799eda82de061c7c458 3c659044118e34603161457db9934a34f816d78b 06c4cc3660b366278bdc7bc8b6677032d7b1118c 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151289 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 007d1dbf72536ec1b847a944832e4de1546af2ac 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151291 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151293 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151294 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151296 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 Searching for interesting versions Result found: flight 150631 (pass), for basis pass Result found: flight 151269 (fail), for basis failure (at ancestor ~1) Repro found: flight 151285 (pass), for basis pass Repro found: flight 151287 (fail), for basis failure 0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 No revisions left to test, checking graph state. Result found: flight 151291 (pass), for last pass Result found: flight 151293 (fail), for first failure Repro found: flight 151294 (pass), for last pass Repro found: flight 151296 (fail), for first failure Repro found: flight 151297 (pass), for last pass Repro found: flight 151298 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 81cb05732efb36971901c515b007869cc1d3a532 Bug not present: d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/151298/ commit 81cb05732efb36971901c515b007869cc1d3a532 Author: Markus Armbruster Date: Tue Jun 9 14:23:37 2020 +0200 qdev: Assert devices are plugged into a bus that can take them This would have caught some of the bugs I just fixed. Signed-off-by: Markus Armbruster Reviewed-by: Mark Cave-Ayland Message-Id: <20200609122339.937862-23-armbru@redhat.com> pnmtopng: 230 colors found Revision graph left in /home/logs/results/bisect/qemu-mainline/test-amd64-i386-freebsd10-amd64.guest-start.{dot,ps,png,html,svg}. ---------------------------------------- 151298: tolerable ALL FAIL flight 151298 qemu-mainline real-bisect [real] http://logs.test-lab.xenproject.org/osstest/logs/151298/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-i386-freebsd10-amd64 11 guest-start fail baseline untested jobs: test-amd64-i386-freebsd10-amd64 fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary From xen-devel-bounces@lists.xenproject.org Mon Jun 22 21:18:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 21:18:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnTpB-0003kN-WB; Mon, 22 Jun 2020 21:17:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnTpB-0003kI-Cv for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 21:17:53 +0000 X-Inumbo-ID: d4f1bc4a-b4cd-11ea-8496-bc764e2007e4 Received: from mail.default.ilande.uk0.bigv.io (unknown [2001:41c9:1:41f::167]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d4f1bc4a-b4cd-11ea-8496-bc764e2007e4; Mon, 22 Jun 2020 21:17:52 +0000 (UTC) Received: from host86-158-109-79.range86-158.btcentralplus.com ([86.158.109.79] helo=[192.168.1.65]) by mail.default.ilande.uk0.bigv.io with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnTp9-0005Zs-OY; Mon, 22 Jun 2020 22:17:52 +0100 To: Jason Andryuk , QEMU , Markus Armbruster , xen-devel , Anthony PERARD , Paul Durrant References: From: Mark Cave-Ayland Autocrypt: addr=mark.cave-ayland@ilande.co.uk; keydata= mQENBFQJuzwBCADAYvxrwUh1p/PvUlNFwKosVtVHHplgWi5p29t58QlOUkceZG0DBYSNqk93 3JzBTbtd4JfFcSupo6MNNOrCzdCbCjZ64ik8ycaUOSzK2tKbeQLEXzXoaDL1Y7vuVO7nL9bG E5Ru3wkhCFc7SkoypIoAUqz8EtiB6T89/D9TDEyjdXUacc53R5gu8wEWiMg5MQQuGwzbQy9n PFI+mXC7AaEUqBVc2lBQVpAYXkN0EyqNNT12UfDLdxaxaFpUAE2pCa2LTyo5vn5hEW+i3VdN PkmjyPvL6DdY03fvC01PyY8zaw+UI94QqjlrDisHpUH40IUPpC/NB0LwzL2aQOMkzT2NABEB AAG0ME1hcmsgQ2F2ZS1BeWxhbmQgPG1hcmsuY2F2ZS1heWxhbmRAaWxhbmRlLmNvLnVrPokB OAQTAQIAIgUCVAm7PAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQW8LFb64PMh9f NAgAuc3ObOEY8NbZko72AGrg2tWKdybcMVITxmcor4hb9155o/OWcA4IDbeATR6cfiDL/oxU mcmtXVgPqOwtW3NYAKr5g/FrZZ3uluQ2mtNYAyTFeALy8YF7N3yhs7LOcpbFP7tEbkSzoXNG z8iYMiYtKwttt40WaheWuRs0ZOLbs6yoczZBDhna3Nj0LA3GpeJKlaV03O4umjKJgACP1c/q T2Pkg+FCBHHFP454+waqojHp4OCBo6HyK+8I4wJRa9Z0EFqXIu8lTDYoggeX0Xd6bWeCFHK3 DhD0/Xi/kegSW33unsp8oVcM4kcFxTkpBgj39dB4KwAUznhTJR0zUHf63LkBDQRUCbs8AQgA y7kyevA4bpetM/EjtuqQX4U05MBhEz/2SFkX6IaGtTG2NNw5wbcAfhOIuNNBYbw6ExuaJ3um 2uLseHnudmvN4VSJ5Hfbd8rhqoMmmO71szgT/ZD9MEe2KHzBdmhmhxJdp+zQNivy215j6H27 14mbC2dia7ktwP1rxPIX1OOfQwPuqlkmYPuVwZP19S4EYnCELOrnJ0m56tZLn5Zj+1jZX9Co YbNLMa28qsktYJ4oU4jtn6V79H+/zpERZAHmH40IRXdR3hA+Ye7iC/ZpWzT2VSDlPbGY9Yja Sp7w2347L5G+LLbAfaVoejHlfy/msPeehUcuKjAdBLoEhSPYzzdvEQARAQABiQEfBBgBAgAJ BQJUCbs8AhsMAAoJEFvCxW+uDzIfabYIAJXmBepHJpvCPiMNEQJNJ2ZSzSjhic84LTMWMbJ+ opQgr5cb8SPQyyb508fc8b4uD8ejlF/cdbbBNktp3BXsHlO5BrmcABgxSP8HYYNsX0n9kERv NMToU0oiBuAaX7O/0K9+BW+3+PGMwiu5ml0cwDqljxfVN0dUBZnQ8kZpLsY+WDrIHmQWjtH+ Ir6VauZs5Gp25XLrL6bh/SL8aK0BX6y79m5nhfKI1/6qtzHAjtMAjqy8ChPvOqVVVqmGUzFg KPsrrIoklWcYHXPyMLj9afispPVR8e0tMKvxzFBWzrWX1mzljbBlnV2n8BIwVXWNbgwpHSsj imgcU9TTGC5qd9g= Message-ID: Date: Mon, 22 Jun 2020 22:17:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 86.158.109.79 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.default.ilande.uk0.bigv.io X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: sysbus failed assert for xen_sysdev X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on mail.default.ilande.uk0.bigv.io) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22/06/2020 21:33, Jason Andryuk wrote: > Hi, > > Running qemu devel for a Xen VM is failing an assert after the recent > "qdev: Rework how we plug into the parent bus" sysbus changes. > > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > failed. > > dc->bus_type is "xen-sysbus" and it's the > `object_dynamic_cast(OBJECT(bus), dc->bus_type)` portion that fails > the assert. bus seems to be "main-system-bus", I think: > (gdb) p *bus > $3 = {obj = {class = 0x55555636d780, free = 0x7ffff7c40db0 , > properties = 0x5555563f7180, ref = 3, parent = 0x5555563fe980}, parent > = 0x0, name = 0x5555563fec60 "main-system-bus", ... > > The call comes from hw/xen/xen-legacy-backend.c:706 > sysbus_realize_and_unref(SYS_BUS_DEVICE(xen_sysdev), &error_fatal); > > Any pointers on what needs to be fixed? Hi Jason, My understanding is that the assert() is telling you that you're plugging a TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. A quick look at the file in question suggests that you could try changing the parent class of TYPE_XENSYSBUS from TYPE_BUS to TYPE_SYSTEM_BUS to see if that helps? ATB, Mark. From xen-devel-bounces@lists.xenproject.org Mon Jun 22 23:53:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 22 Jun 2020 23:53:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnWFh-00013N-JF; Mon, 22 Jun 2020 23:53:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnWFg-00012t-EL for xen-devel@lists.xenproject.org; Mon, 22 Jun 2020 23:53:24 +0000 X-Inumbo-ID: 8af9dbca-b4e3-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8af9dbca-b4e3-11ea-b7bb-bc764e2007e4; Mon, 22 Jun 2020 23:53:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WgiNKpINmgvHFHCoeJJYZVbiKte1QIbnqn8Qz5qzwi4=; b=HLlmBObBBptnZw5ZDBt6YnrnQ BS5jFdvYRVmHtnXYeH4L32mzMzDpoF6/e5vC7n6Wf4pACLwgjOMixWC9l/ZiV4YXnDC7lbSNlOhO2 yCkWFYOxb0M1btiMCP4AAP+IZxFu6/O1k2GzmUPqf1wYWvHbifL5QV6zpp9B+GvlhWI+o=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnWFY-0002rU-MK; Mon, 22 Jun 2020 23:53:16 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnWFY-0006Tm-AQ; Mon, 22 Jun 2020 23:53:16 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnWFY-0001ij-9e; Mon, 22 Jun 2020 23:53:16 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151283: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-i386-xl-qemuu-ovmf-amd64:xen-boot:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=48778464bb7d346b47157d21ffde2af6b2d39110 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Mon, 22 Jun 2020 23:53:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151283 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151283/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 151214 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 48778464bb7d346b47157d21ffde2af6b2d39110 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 4 days Failing since 151236 2020-06-19 19:10:35 Z 3 days 3 attempts Testing same since 151283 2020-06-22 02:26:44 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alex Deucher Alex Deucher Alexey Budankov Andy Shevchenko Aneesh Kumar K.V Ard Biesheuvel Arnaldo Carvalho de Melo Arnd Bergmann Arvind Sankar Atish Patra Baolin Wang Barry Song Chen Zhou Chris Wilson Christian Zigotzky Christoph Hellwig Christophe Leroy Coly Li Cornelia Huck Dan Carpenter Dan Williams Daniel Schaefer Daniel Vetter Dave Airlie Dave Martin David Howells Denis Efremov Dinghao Liu Dmitry Baryshkov Dmitry V. Levin Drew Fustini Eric Biggers Felix Kuehling Flavio Suligoi Gaurav Singh Guenter Roeck Gustavo A. R. Silva Haibo Chen Heiko Carstens Heinrich Schuchardt Herbert Xu Hongbo Yao Ian Rogers Ilya Dryomov Imre Deak Ira Weiny Jack Wang Jan Kara Jason Yan Jens Axboe Jiri Olsa Jiri Olsa John Garry Joonas Lahtinen Julian Wiedmann Kai-Heng Feng Kaitao Cheng Kees Cook Kefeng Wang kernel test robot Keyur Patel Khaled Almahallawy Lee Jones Linus Torvalds Linus Walleij Loic Poulain Lorenz Brun Luc Van Oostenryck Luis Chamberlain Manivannan Sadhasivam Mark Rutland Martin K. Petersen Martin Schwidefsky Masahiro Yamada Masami Hiramatsu Masanari Iida Mauricio Faria de Oliveira Michael Ellerman Miguel Ojeda Mike Rapoport Milian Wolff Nathan Chancellor Nathan Huckleberry Navid Emamdoost Nicholas Piggin Nick Desaulniers Nirmoy Das Palmer Dabbelt Paul Moore Pavel Begunkov Peter Zijlstra (Intel) Qingqing Zhuo Randy Dunlap Robert Foss Rodrigo Siqueira Roman Gushchin Sami Tolvanen Sandeep Raghuraman Sedat Dilek Shuah Khan Shyam Thombre Sivaprakash Murugesan Stephan Mueller Stephan Müller Stephen Smalley Steven Rostedt (VMware) Sumanth Korikkar Sven Schnelle Tiezhu Yang Tom Lendacky Tom Rix Uma Shankar Vaibhav Jain Vamshi K Sthambamkadi Vandita Kulkarni Vasily Gorbik Vidya Sagar Vincenzo Frascino Vishal Verma Wei Yang Weiping Zhang Will Deacon Wolfram Sang Wolfram Sang Xiaoguang Wang YangHui Yash Shah Ye Bin Zheng Bin Zhiqiang Liu Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6042 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 23 00:43:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 00:43:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnX2B-0006BD-Hb; Tue, 23 Jun 2020 00:43:31 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnX2A-0006B8-1W for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 00:43:30 +0000 X-Inumbo-ID: 8dc46333-b4ea-11ea-bef0-12813bfff9fa Received: from smtp-fw-33001.amazon.com (unknown [207.171.190.10]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8dc46333-b4ea-11ea-bef0-12813bfff9fa; Tue, 23 Jun 2020 00:43:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1592873009; x=1624409009; h=date:from:to:cc:message-id:references:mime-version: content-transfer-encoding:in-reply-to:subject; bh=xyL/GE+//VNND4ClwSzcCDyd8/X/TGjOdivfmtA0Muo=; b=v8gI0I1nStvjgJsGCAagFSTxJif4O9OhilXHeixi/TLZXdhSc2kgnCcI oBvRdjzkrR2WGSDAYDktpSgo6v+4ewNi6WVnkHhz//SFwm0EDviLGC9BA MwXLc/trWUe4cbwEz0WwjiInn4ZfPlHeellii/eU3Xjn0/2Ph6AZBGlNM g=; IronPort-SDR: ptAdrfFwuUgauX+U5uC5bBETq8cuc67rFZsuJj1H/pREvnxOuOIJ9yvB1TRAzAWBXdw2Q6TQ8N fIajCpJtaqLg== X-IronPort-AV: E=Sophos;i="5.75,268,1589241600"; d="scan'208";a="53039173" Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-c6afef2e.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 23 Jun 2020 00:43:24 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2c-c6afef2e.us-west-2.amazon.com (Postfix) with ESMTPS id 9574BA2519; Tue, 23 Jun 2020 00:43:23 +0000 (UTC) Received: from EX13D05UWC003.ant.amazon.com (10.43.162.226) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 00:43:14 +0000 Received: from EX13MTAUWC001.ant.amazon.com (10.43.162.135) by EX13D05UWC003.ant.amazon.com (10.43.162.226) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 23 Jun 2020 00:43:14 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.162.232) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 23 Jun 2020 00:43:14 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 1816D40359; Tue, 23 Jun 2020 00:43:14 +0000 (UTC) Date: Tue, 23 Jun 2020 00:43:14 +0000 From: Anchal Agarwal To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20200623004314.GA28586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200617083528.GW735@Air-de-Roger> <20200619234312.GA24846@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200622083846.GF735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200622083846.GF735@Air-de-Roger> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 10:38:46AM +0200, Roger Pau Monn wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On Fri, Jun 19, 2020 at 11:43:12PM +0000, Anchal Agarwal wrote: > > On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monn wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > > > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monn wrote: > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > > > > + "the device may become inconsistent state"); > > > > > > > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > > > > state and with the queues frozen. You should make an attempt to > > > > > > restore things to a working state. > > > > > > > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > > > > > > > You can manually force this state, and then check that it will behave > > > > > correctly. I would expect that on a failure to disconnect from the > > > > > backend you should switch the frontend to the 'Init' state in order to > > > > > try to reconnect to the backend when possible. > > > > > > > > > From what I understand forcing manually is, failing the freeze without > > > > disconnect and try to revive the connection by unfreezing the > > > > queues->reconnecting to backend [which never got diconnected]. May be even > > > > tearing down things manually because I am not sure what state will frontend > > > > see if backend fails to to disconnect at any point in time. I assumed connected. > > > > Then again if its "CONNECTED" I may not need to tear down everything and start > > > > from Initialising state because that may not work. > > > > > > > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > > > > I don't see it getting handled in the backend then what will be backend's state? > > > > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > > > > if it tries to read backend's state through xenbus_read_driver_state ? > > > > > > > > So the flow be like: > > > > Front end marks XenbusStateClosing > > > > Backend marks its state as XenbusStateClosing > > > > Frontend marks XenbusStateClosed > > > > Backend disconnects calls xen_blkif_disconnect > > > > Backend fails to disconnect, the above function returns EBUSY > > > > What will be state of backend here? > > > > > > Backend should stay in state 'Closing' then, until it can finish > > > tearing down. > > > > > It disconnects the ring after switching to connected state too. > > > > Frontend did not tear down the rings if backend does not switches the > > > > state to 'Closed' in case of failure. > > > > > > > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend > > > > > > Backend will stay in state 'Closing' I think. > > > > > > > won't be calling connect(). {From reading code in frontend_changed} > > > > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > > > > we did not tear down anything so calling talk_to_blkback may not be needed > > > > > > > > Does that sound correct? > > > > > > I think switching to the initial state in order to try to attempt a > > > reconnection would be our best bet here. > > > > > It does not seems to work correctly, I get hung tasks all over and all the > > requests to filesystem gets stuck. Backend does shows the state as connected > > after xenbus_dev_suspend fails but I think there may be something missing. > > I don't seem to get IO interrupts thereafter i.e hitting the function blkif_interrupts. > > I think just marking it initialised may not be the only thing. > > Here is a short description of what I am trying to do: > > So, on timeout: > > Switch XenBusState to "Initialized" > > unquiesce/unfreeze the queues and return > > mark info->connected = BLKIF_STATE_CONNECTED > > If xenbus state is Initialized isn't it wrong to set info->connected > == CONNECTED? > Yes, you are right earlier I was marking it explicitly but that was not right, the connect path for blkfront will do that. > You should tear down all the internal state (like a proper close)? > Isn't that similar to disconnecting in the first place that failed during freeze? Do you mean re-try to close but this time re-connect after close basically do everything you would at "restore"? Also, I experimented with that and it works intermittently. I want to take a step back on this issue and ask few questions here: 1. Is fixing this recovery a blocker for me sending in a V2 version? 2. In our 2-3 years of supporting this feature at large scale we haven't seen this issue where backend fails to disconnect. What we are trying to do here is create a hypothetical situation where we leave backend in Closing state and try and see how it recovers. The reason why I think it "may not" occur and the timeout of 5HZ is sufficient is because we haven't come across even a single use-case where it caused hibernation to fail. The reason why I think "it may" occur is if we are running a really memory intensive workload and ring is busy and is unable to complete all the requests in the given timeout. This is very unlikely though. 3) Also, I do not think this may be straight forward to fix and expect hibernation to work flawlessly in subsequent invocations. I am open to all suggestions. Thanks, Anchal > > return EBUSY > > > > I even allowed blkfront_connect to switch state to "CONNECTED" rather me doing > > it explicitly as mentioned above without re-allocating/re-registering the device > > just to make sure bklfront_info object has all the right values. > > Do you see anythign missing here? > > I'm afraid you will have to do a little bit of debugging here to > figure out what's going on. You can add printk's to several places to > see which path is taken, and why blkfront ends in such state. > > Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 01:05:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 01:05:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnXN4-0000iE-A1; Tue, 23 Jun 2020 01:05:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnXN3-0000i9-HW for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 01:05:05 +0000 X-Inumbo-ID: 9190af40-b4ed-11ea-bef2-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9190af40-b4ed-11ea-bef2-12813bfff9fa; Tue, 23 Jun 2020 01:05:03 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 963B5A234A; Tue, 23 Jun 2020 03:05:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 69E61A22B6; Tue, 23 Jun 2020 03:05:01 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id bitQuvZ7NmEI; Tue, 23 Jun 2020 03:05:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A833BA234A; Tue, 23 Jun 2020 03:05:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JNHeiI_Wmx6L; Tue, 23 Jun 2020 03:05:00 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 76CE4A22B6; Tue, 23 Jun 2020 03:05:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 51BEC20D97; Tue, 23 Jun 2020 03:04:30 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id o_KNW34omj-b; Tue, 23 Jun 2020 03:04:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id AAE8F216C8; Tue, 23 Jun 2020 03:04:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id q3ukrnuaByvJ; Tue, 23 Jun 2020 03:04:24 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 8244C20D97; Tue, 23 Jun 2020 03:04:24 +0200 (CEST) Date: Tue, 23 Jun 2020 03:04:24 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Jan Beulich Message-ID: <901046162.11470361.1592874264410.JavaMail.zimbra@cert.pl> In-Reply-To: <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: skHlUZZiKLRaZ/TNKOwd8rxjdwwr3g== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 22 cze 2020 o 18:16, Jan Beulich jbeulich@suse.com napisa=C5=82(a): > On 22.06.2020 18:02, Micha=C5=82 Leszczy=C5=84ski wrote: >> ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisa=C5=82(a)= : >>> On 22.06.2020 16:35, Micha=C5=82 Leszczy=C5=84ski wrote: >>>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisa=C5=82(= a): >>>>> Is any of what you do in this switch() actually legitimate without >>>>> hvm_set_vmtrace_pt_size() having got called for the guest? From >>>>> remarks elsewhere I imply you expect the param that you currently >>>>> use to be set upon domain creation time, but at the very least the >>>>> potentially big buffer should imo not get allocated up front, but >>>>> only when tracing is to actually be enabled. >>>> >>>> Wait... so you want to allocate these buffers in runtime? >>>> Previously we were talking that there is too much runtime logic >>>> and these enable/disable hypercalls should be stripped to absolute >>>> minimum. >>> >>> Basic arrangements can be made at domain creation time. I don't >>> think though that it would be a good use of memory if you >>> allocated perhaps many gigabytes of memory just for possibly >>> wanting to enable tracing on a guest. >>> >>=20 >> From our previous conversations I thought that you want to have >> as much logic moved to the domain creation as possible. >>=20 >> Thus, a parameter "vmtrace_pt_size" was introduced. By default it's >> zero (=3D disabled), if you set it to a non-zero value, then trace buffe= rs >> of given size will be allocated for the domain and you have possibility >> to use ipt_enable/ipt_disable at any moment. >>=20 >> This way the runtime logic is as thin as possible. I assume user knows >> in advance whether he/she would want to use external monitoring with IPT >> or not. >=20 > Andrew - I think you requested movement to domain_create(). Could > you clarify if indeed you mean to also allocate the big buffers > this early? I would like to recall what Andrew wrote few days ago: ----- 16 cze 2020 o 22:16, Andrew Cooper andrew.cooper3@citrix.com wrote: > Xen has traditionally opted for a "and turn this extra thing on > dynamically" model, but this has caused no end of security issues and > broken corner cases. >=20 > You can see this still existing in the difference between > XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being > required to chose the number of vcpus for the domain) and we're making > good progress undoing this particular wart (before 4.13, it was > concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by > issuing other hypercalls between these two). >=20 > There is a lot of settings which should be immutable for the lifetime of > the domain, and external monitoring looks like another one of these. > Specifying it at createdomain time allows for far better runtime > behaviour (you are no longer in a situation where the first time you try > to turn tracing on, you end up with -ENOMEM because another VM booted in > the meantime and used the remaining memory), and it makes for rather > more simple code in Xen itself (at runtime, you can rely on it having > been set up properly, because a failure setting up will have killed the > domain already). >=20 > ... >=20 > ~Andrew according to this quote I've moved buffer allocation to the create_domain, the updated version was already sent to the list as patch v3. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Tue Jun 23 01:19:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 01:19:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnXbA-0001sE-Ka; Tue, 23 Jun 2020 01:19:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnXb9-0001s8-60 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 01:19:39 +0000 X-Inumbo-ID: 9b2b10c0-b4ef-11ea-bef2-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9b2b10c0-b4ef-11ea-bef2-12813bfff9fa; Tue, 23 Jun 2020 01:19:38 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 76C162053B; Tue, 23 Jun 2020 01:19:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592875177; bh=4OIRBLg0H5N3bTEb42UdP6Mxrr+RntsK/pnHuwgTYh4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=0GYXeFn5S0k7Z2rh9P66W3HmFEEip564VofjPy/wJOVHHTTBqbkYpB/i4Y5Bwjsnk X3nZwKHZHR1FKGYBdQOqJsWS82OqHn3ZJ1G9sgvXPWFbhqqdg1TSe6GO7cpgPO+h6n PngixMCGY4CskEFvf5bcPl/0J5bCI/rwZPmvCqIU= Date: Mon, 22 Jun 2020 18:19:37 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Volodymyr Babchuk Subject: Re: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address In-Reply-To: <20200619223332.438344-3-volodymyr_babchuk@epam.com> Message-ID: References: <20200619223332.438344-1-volodymyr_babchuk@epam.com> <20200619223332.438344-3-volodymyr_babchuk@epam.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "pdurrant@amazon.com" , "op-tee@lists.trustedfirmware.org" , Julien Grall , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 19 Jun 2020, Volodymyr Babchuk wrote: > Trusted Applications use popular approach to determine required size > of buffer: client provides a memory reference with the NULL pointer to > a buffer. This is so called "Null memory reference". TA updates the > reference with the required size and returns it back to the > client. Then client allocates buffer of needed size and repeats the > operation. > > This behavior is described in TEE Client API Specification, paragraph > 3.2.5. Memory References. > > OP-TEE represents this null memory reference as a TMEM parameter with > buf_ptr = 0x0. This is the only case when we should allow TMEM > buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. This also the > special case for a buffer with OPTEE_MSG_ATTR_NONCONTIG flag. > > This could lead to a potential issue, because IPA 0x0 is a valid > address, but OP-TEE will treat it as a special case. So, care should > be taken when construction OP-TEE enabled guest to make sure that such > guest have no memory at IPA 0x0 and none of its memory is mapped at PA > 0x0. > > Signed-off-by: Volodymyr Babchuk > --- > > Changes from v1: > - Added comment with TODO about possible PA/IPA 0x0 issue > - The same is described in the commit message > - Added check in translate_noncontig() for the NULL ptr buffer > > --- > xen/arch/arm/tee/optee.c | 27 ++++++++++++++++++++++++--- > 1 file changed, 24 insertions(+), 3 deletions(-) > > diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > index 6963238056..70bfef7e5f 100644 > --- a/xen/arch/arm/tee/optee.c > +++ b/xen/arch/arm/tee/optee.c > @@ -215,6 +215,15 @@ static bool optee_probe(void) > return true; > } > > +/* > + * TODO: There is a potential issue with guests that either have RAM > + * at IPA of 0x0 or some of theirs memory is mapped at PA 0x0. This is ^ their > + * because PA of 0x0 is considered as NULL pointer by OP-TEE. It will > + * not be able to map buffer with such pointer to TA address space, or > + * use such buffer for communication with the guest. We either need to > + * check that guest have no such mappings or ensure that OP-TEE > + * enabled guest will not be created with such mappings. > + */ > static int optee_domain_init(struct domain *d) > { > struct arm_smccc_res resp; > @@ -725,6 +734,15 @@ static int translate_noncontig(struct optee_domain *ctx, > uint64_t next_page_data; > } *guest_data, *xen_data; > > + /* > + * Special case: buffer with buf_ptr == 0x0 is considered as NULL > + * pointer by OP-TEE. No translation is needed. This can lead to > + * an issue as IPA 0x0 is a valid address for Xen. See the comment > + * near optee_domain_init() > + */ > + if ( !param->u.tmem.buf_ptr ) > + return 0; Given that today it is not possible for this to happen, it could even be an ASSERT. But I think I would just return an error, maybe -EINVAL? Aside from this, and the small grammar issue, everything else looks fine to me. Let's wait for Julien's reply, but if this is the only thing I could fix on commit. > /* Offset of user buffer withing OPTEE_MSG_NONCONTIG_PAGE_SIZE-sized page */ > offset = param->u.tmem.buf_ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE - 1); > > @@ -865,9 +883,12 @@ static int translate_params(struct optee_domain *ctx, > } > else > { > - gdprintk(XENLOG_WARNING, "Guest tries to use old tmem arg\n"); > - ret = -EINVAL; > - goto out; > + if ( call->xen_arg->params[i].u.tmem.buf_ptr ) > + { > + gdprintk(XENLOG_WARNING, "Guest tries to use old tmem arg\n"); > + ret = -EINVAL; > + goto out; > + } > } > break; > case OPTEE_MSG_ATTR_TYPE_NONE: > -- > 2.26.2 > From xen-devel-bounces@lists.xenproject.org Tue Jun 23 01:19:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 01:19:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnXbF-0001sX-TL; Tue, 23 Jun 2020 01:19:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnXbE-0001s8-20 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 01:19:44 +0000 X-Inumbo-ID: 9d70a0de-b4ef-11ea-bef2-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9d70a0de-b4ef-11ea-bef2-12813bfff9fa; Tue, 23 Jun 2020 01:19:42 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 866B62053B; Tue, 23 Jun 2020 01:19:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592875181; bh=w6rTVAhgIBPh0garjvhse4Q6AvioIJLVTatcx1vBVuI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=gdQ4R5aB/2vicmqYRFKzs0bLFh+3N8XMCVfWakp129haNAF2QoO8Yew6231FBodW5 G/Mp8mndv73JHNaQBj9lMBXKLgXMXrLjbKaX6TiKLof0M7/gO5Qd4NWFMVVqNxlGG1 IzxaQyQVsxbjhE/Wh1WH+NRusqFhGPVwqsOTdkRA= Date: Mon, 22 Jun 2020 18:19:41 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Volodymyr Babchuk Subject: Re: [PATCH v2 1/2] optee: immediately free buffers that are released by OP-TEE In-Reply-To: <20200619223332.438344-2-volodymyr_babchuk@epam.com> Message-ID: References: <20200619223332.438344-1-volodymyr_babchuk@epam.com> <20200619223332.438344-2-volodymyr_babchuk@epam.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "pdurrant@amazon.com" , "op-tee@lists.trustedfirmware.org" , Julien Grall , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 19 Jun 2020, Volodymyr Babchuk wrote: > Normal World can share buffer with OP-TEE for two reasons: > 1. Some client application wants to exchange data with TA > 2. OP-TEE asks for shared buffer for internal needs > > The second case was handle more strictly than necessary: > > 1. In RPC request OP-TEE asks for buffer > 2. NW allocates buffer and provides it via RPC response > 3. Xen pins pages and translates data > 4. Xen provides buffer to OP-TEE > 5. OP-TEE uses it > 6. OP-TEE sends request to free the buffer > 7. NW frees the buffer and sends the RPC response > 8. Xen unpins pages and forgets about the buffer > > The problem is that Xen should forget about buffer in between stages 6 > and 7. I.e. the right flow should be like this: > > 6. OP-TEE sends request to free the buffer > 7. Xen unpins pages and forgets about the buffer > 8. NW frees the buffer and sends the RPC response > > This is because OP-TEE internally frees the buffer before sending the > "free SHM buffer" request. So we have no reason to hold reference for > this buffer anymore. Moreover, in multiprocessor systems NW have time > to reuse buffer cookie for another buffer. Xen complained about this > and denied the new buffer registration. I have seen this issue while > running tests on iMX SoC. > > So, this patch basically corrects that behavior by freeing the buffer > earlier, when handling RPC return from OP-TEE. > > Signed-off-by: Volodymyr Babchuk There are a couple of grammar issues in the comments, but we can fix them on commit. Acked-by: Stefano Stabellini > --- > > Changes from v1: > - reworded the comments > - added WARN() for a case when OP-TEE wants to release not the > buffer it requeset to allocate durint this call > > --- > xen/arch/arm/tee/optee.c | 32 ++++++++++++++++++++++++++++---- > 1 file changed, 28 insertions(+), 4 deletions(-) > > diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > index 6a035355db..6963238056 100644 > --- a/xen/arch/arm/tee/optee.c > +++ b/xen/arch/arm/tee/optee.c > @@ -1099,6 +1099,34 @@ static int handle_rpc_return(struct optee_domain *ctx, > if ( shm_rpc->xen_arg->cmd == OPTEE_RPC_CMD_SHM_ALLOC ) > call->rpc_buffer_type = shm_rpc->xen_arg->params[0].u.value.a; > > + /* > + * OP-TEE is signalling that it has freed the buffer that it > + * requested before. This is the right time for us to do the > + * same. > + */ > + if ( shm_rpc->xen_arg->cmd == OPTEE_RPC_CMD_SHM_FREE ) > + { > + uint64_t cookie = shm_rpc->xen_arg->params[0].u.value.b; > + > + free_optee_shm_buf(ctx, cookie); > + > + /* > + * OP-TEE asks to free buffer, but this is not the same > + * buffer we previously allocated for it. While nothing > + * prevents OP-TEE from asking this, it is the strange ^ a > + * situation. This may or may not be caused by a bug in > + * OP-TEE or mediator. But is better to print warning. ^ it is > + */ > + if ( call->rpc_data_cookie && call->rpc_data_cookie != cookie ) > + { > + gprintk(XENLOG_ERR, > + "Saved RPC cookie does not corresponds to OP-TEE's (%"PRIx64" != %"PRIx64")\n", ^ correspond > + call->rpc_data_cookie, cookie); > + > + WARN(); > + } > + call->rpc_data_cookie = 0; > + } > unmap_domain_page(shm_rpc->xen_arg); > } > > @@ -1464,10 +1492,6 @@ static void handle_rpc_cmd(struct optee_domain *ctx, struct cpu_user_regs *regs, > } > break; > case OPTEE_RPC_CMD_SHM_FREE: > - free_optee_shm_buf(ctx, shm_rpc->xen_arg->params[0].u.value.b); > - if ( call->rpc_data_cookie == > - shm_rpc->xen_arg->params[0].u.value.b ) > - call->rpc_data_cookie = 0; > break; > default: > break; > -- > 2.26.2 > From xen-devel-bounces@lists.xenproject.org Tue Jun 23 01:20:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 01:20:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnXcD-0002e0-CC; Tue, 23 Jun 2020 01:20:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnXcC-0002dq-HX for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 01:20:44 +0000 X-Inumbo-ID: c232a7c8-b4ef-11ea-8496-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c232a7c8-b4ef-11ea-8496-bc764e2007e4; Tue, 23 Jun 2020 01:20:44 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0596F20675; Tue, 23 Jun 2020 01:20:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592875243; bh=wcXgJbJlUk8bITf2CCrZAFYv+RTmBjCLBeNZ0Mjjr1A=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=P/7pAL/yZr8dYQ000cFXro1hRptCvQ//z1CZ0wvZ7Fya81RQWR68KmqAk/gfRbdFV JEtg10HadkzageiEQRdmG+bOym7WIlXqTvxqGPQ4z4tSFPyoXxi+neE7F+gLGJxHQp QJyxuhhoJi5PvfW+glbV+hf9wQ6AsVyeUkczs8a4= Date: Mon, 22 Jun 2020 18:20:42 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: UEFI support in ARM DomUs In-Reply-To: <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Stefano Stabellini , Oleksandr Andrushchenko , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 22 Jun 2020, Julien Grall wrote: > > > > For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it > > > > via > > > > > > > > CFLAGS or something. This can also be done for the location of Xen > > > > headers. > > > > > > __XEN_INTERFACE_VERSION__ should work through the CFLAGS. An alternative > > > would be to allow the user to specify through the Kconfig. > > > > You mean specifying via Kconfig something like "0x00040d00"? > > Possibly yes. > > > > > And what about the headers? How will we provide their location if we decide > > not to include those > > > > in the tree? > > I would do through Kconfig as well. If we specify the external location of the Xen headers via Kconfig, it seems to me that we should be able to detect the interface version automatically from any Makefile as part of the build. No need to ask the user. However, if Oleksandr is thinking of using the Xen headers for the hypercalls definitions, then I think we might not need external headers at all because that is a stable interface, as Julien wrote. We could just define our own few headers for just what you need like Linux does. If you can do that, I think it would be better because we decouple the UBoot build from the Xen build completely. We don't even need the Xen tree checked out to build UBoot. It would be a huge advantage because it makes it far easier to build-test changes for others in the community that don't know about Xen and also it becomes far easier to integrate into any build system. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 02:22:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 02:22:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnYZm-0008W4-6m; Tue, 23 Jun 2020 02:22:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnYZl-0008VW-3X for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 02:22:17 +0000 X-Inumbo-ID: 56269aaf-b4f8-11ea-bef7-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 56269aaf-b4f8-11ea-bef7-12813bfff9fa; Tue, 23 Jun 2020 02:22:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e5/QcNusIgdlsQvicWd65EAMFQrfFrk2G434+q9U6/w=; b=PjsSaXSZ9kYKiMD7nWebih2lQ 11I/hds0mGPJzcjcHENW/3IAK5Fem83na4qHlJLXw2nSMljrnDvYbC8l5+9yab/8wsPYkVAucFgjd 49b7MS95at+shRc6ikSfFTZ8io4ljEnfo+20bDRGgIQxSYmLNMRzn/xcqq3unqbp/ro8g=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnYZb-00081T-KI; Tue, 23 Jun 2020 02:22:07 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnYZb-00061Y-An; Tue, 23 Jun 2020 02:22:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnYZb-0003vy-96; Tue, 23 Jun 2020 02:22:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151286: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=06c4cc3660b366278bdc7bc8b6677032d7b1118c X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Tue, 23 Jun 2020 02:22:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151286 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151286/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass version targeted for testing: qemuu 06c4cc3660b366278bdc7bc8b6677032d7b1118c baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 10 days Failing since 151101 2020-06-14 08:32:51 Z 8 days 7 attempts Testing same since 151241 2020-06-20 01:36:13 Z 3 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Anthony PERARD Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Cathy Zhang Christian Borntraeger Claudio Fontana Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Gerd Hoffmann Guenter Roeck Helge Deller Igor Mammedov Janne Grunau Jason Wang Jean-Christophe Dubois Jiaxun Yang John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marek Marczykowski-Górecki Markus Armbruster Masahiro Yamada Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Stefan Berger Stefan Hajnoczi Thomas Huth Tong Ho WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 8468 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 23 02:49:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 02:49:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnYzp-0002Ac-D2; Tue, 23 Jun 2020 02:49:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnYzo-0002AX-6C for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 02:49:12 +0000 X-Inumbo-ID: 1d60e9ab-b4fc-11ea-befc-12813bfff9fa Received: from EUR01-DB5-obe.outbound.protection.outlook.com (unknown [40.107.15.48]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1d60e9ab-b4fc-11ea-befc-12813bfff9fa; Tue, 23 Jun 2020 02:49:11 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gZTO2a3VIQqjuvm27727puXlUNfjlQulEvQH3Y90Qbu3O9niRGfu25TI38Ltd6NTe8LNpQe2m2/nOl41fUKF9PLTa6dIns/ZSGfYi8G0cqyjJ3HTI+gPxUF/q+5ZUOkuemx95Zp07ieq5TFsIhkaFAoQqk00xH9CY7PqgCDo4FcT/R/DvjQjYpgcIG3V8vxc8XooMQrBr0w8+8/HPibsXR3Kmjr2Z+RKPaUpv0Knz0nfpLOQLtOWlAbaoPaPVs6DfQ4kxDwIJs3AmWGX1iOIsH6XioQ1ZrSI+X2iO68mMg5Q1oF1LQUok7514bZYuI7wO2UyxoUW7j9UytAbTs9+xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qqNR09fnA/SWiVnyexrL1RD5D2+EU3RfWusK2lD0GkU=; b=K+H5IpN1Xd3e9ag3eQGlPugJyQiIdBmoAZo4lU5pHUC894thulHZXUFmBwztB8RmWVKrFy2wjfi8SIY19OLPF9HmrfB/sA9WasCOHPLB8kttEMWgLWc8ct0u4anrSZZlMjw5wuuDMJSewdH59FbMquESvz9RtcTeI+ceC6JPAnESoEQf6BoqBFsfJKUR3KeeeTMIFhK6J7wjyOIWML4jvKsq1cLJkuQZzXRiu5KoSjbipM0fbszeZMyazs5Gmudl2gGrTUzGxJJPyuRFL8EoveOFOPMOcti172WSalVMyC2Qdw3ilmVIjIbt4XeX+N4Fnl+862tRIPGfBXFj7BQN3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qqNR09fnA/SWiVnyexrL1RD5D2+EU3RfWusK2lD0GkU=; b=P86gxqnTCSzjy/K6O3IbSanttohqSj1mGyw5GCOypSZDdEHBjiG7UWq+HcpIm9wRT/Bob+3EDA8wS2BwVr6NF/XuMFAEBso0NNB1iFVMXe3OQluLmcg6CUvK9JyWMSBUHLgDlrhUiJdDVlueciIcUO1xKzM8WIJMxaXcbW/KzGFkJYgojWlP2G8d8it1EpCkMbq3qpPUZNzHfyP9ebYjdVXgSbmt9juL0OITBQ35Tt7WQsCL1tlFx4lec2Aab5jRYNrAEHqy3Je8Lu/9T/DVrC3hJZU3bSgdiS8w956ipADhT6p7s9NPzt90NHMAp5STh1usHpsAdWgM2/YmIcisfg== Received: from HE1PR0302MB2699.eurprd03.prod.outlook.com (2603:10a6:3:ee::17) by HE1PR0302MB2826.eurprd03.prod.outlook.com (2603:10a6:3:f3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.27; Tue, 23 Jun 2020 02:49:09 +0000 Received: from HE1PR0302MB2699.eurprd03.prod.outlook.com ([fe80::1d03:ee47:b130:ef55]) by HE1PR0302MB2699.eurprd03.prod.outlook.com ([fe80::1d03:ee47:b130:ef55%9]) with mapi id 15.20.3109.027; Tue, 23 Jun 2020 02:49:09 +0000 From: Volodymyr Babchuk To: Stefano Stabellini Subject: Re: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address Thread-Topic: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address Thread-Index: AQHWRom6aQ+ko86LqESb88QJVYc4Lajla6SAgAAZAwA= Date: Tue, 23 Jun 2020 02:49:08 +0000 Message-ID: <87ftampkd7.fsf@epam.com> References: <20200619223332.438344-1-volodymyr_babchuk@epam.com> <20200619223332.438344-3-volodymyr_babchuk@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: mu4e 1.4.10; emacs 26.3 authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [176.36.48.175] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 281a4bd4-ac86-45d8-8dfd-08d8172000ac x-ms-traffictypediagnostic: HE1PR0302MB2826: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04433051BF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KI8jvVdPoW1gF7Lb43oGHCXaM2XpJiioittT1xaiJo3IfffoHfRbL2hG4ObVo/Jww0K37KLJ0PHdtb4f2MUd6rmU82JyELLjpmjjwBLtqnucg9E361i1bhKgAHBhqnGvqK6eKbfW+/ewoKqFZ2riHeMRdyk7FCj/af27GYSnGEszb5og4scUMIxfUt4Yvx1aK2PgzYQpt2dKGjrQEq7wc21JGlx8QeUHx21VKkYDaGcJL0lhrtJOK2fR04UJcQX4kriWz/hhFzG3rE4vj1i5MmgEW+huA8+obLJKIuIKfie0zY7DLyM2oKrvDy5e4miFOfXsP33XrP0cw5K7LPIWbg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0302MB2699.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(39860400002)(346002)(136003)(396003)(54906003)(478600001)(6486002)(8936002)(5660300002)(6512007)(83380400001)(4326008)(66946007)(6506007)(76116006)(91956017)(6916009)(2906002)(66476007)(66556008)(64756008)(66446008)(26005)(2616005)(316002)(186003)(71200400001)(8676002)(55236004)(86362001)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 74bVMkMgtAf5+T8X9+/US0f34bq9tOKD/znVzdVh0nQ2R0VDqNhSC4/x2vVupRBYY2lylSE1eYlH9ewzHfPL/a0qR800sb14X/GBYaF2b65eAnqozvf/2Y5txhBkYUixJ0P+2df+SqiK7hc6Ko1pV/UeXRvkyeXYmSWAJDGbzhMwFQNVWF/j+V6WAyhMkle+H0BMIB49wzaKpnAhiSyuM8/WI4q3cw5/j4u+xdhQl7tCm16vURY6PgoAgiY/2FB7ZJWv8Ho2lrl/UQi5pO0sRL/66/4QZlOWjhcxMghyiyLRmU4g0hzfbz2ZyN3/Q4EXSrsQeGhR6Ye+fC3caXE0a9lgqfMohoqAhA5Sl4Bgqy/SN9Ijwpv/cNA+CIc5w5hobZQ2cFK8Cj1TnuYH6WBfYK3dXPb2lpXRHttzGZhk9IX/c/+ECVKDs2i6qpawEwSJss3uwQGA3pmeIaq+E9YqZGXhC6kHnjkP2siFvAs/dsM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 281a4bd4-ac86-45d8-8dfd-08d8172000ac X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 02:49:08.9606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PxmO9NtL2cqwP9blqXZ6thOBoDcBka+p7Pm8+PpwJTrov8+Yatm1QyU46uRr8eYvxuAObXhyfrlTmqFnZSnn/84VLKJ2toM9bAjISL0xTRw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0302MB2826 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "pdurrant@amazon.com" , "op-tee@lists.trustedfirmware.org" , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Stefano, Stefano Stabellini writes: > On Fri, 19 Jun 2020, Volodymyr Babchuk wrote: >> Trusted Applications use popular approach to determine required size >> of buffer: client provides a memory reference with the NULL pointer to >> a buffer. This is so called "Null memory reference". TA updates the >> reference with the required size and returns it back to the >> client. Then client allocates buffer of needed size and repeats the >> operation. >>=20 >> This behavior is described in TEE Client API Specification, paragraph >> 3.2.5. Memory References. >>=20 >> OP-TEE represents this null memory reference as a TMEM parameter with >> buf_ptr =3D 0x0. This is the only case when we should allow TMEM >> buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. This also the >> special case for a buffer with OPTEE_MSG_ATTR_NONCONTIG flag. >>=20 >> This could lead to a potential issue, because IPA 0x0 is a valid >> address, but OP-TEE will treat it as a special case. So, care should >> be taken when construction OP-TEE enabled guest to make sure that such >> guest have no memory at IPA 0x0 and none of its memory is mapped at PA >> 0x0. >>=20 >> Signed-off-by: Volodymyr Babchuk >> --- >>=20 >> Changes from v1: >> - Added comment with TODO about possible PA/IPA 0x0 issue >> - The same is described in the commit message >> - Added check in translate_noncontig() for the NULL ptr buffer >>=20 >> --- >> xen/arch/arm/tee/optee.c | 27 ++++++++++++++++++++++++--- >> 1 file changed, 24 insertions(+), 3 deletions(-) >>=20 >> diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c >> index 6963238056..70bfef7e5f 100644 >> --- a/xen/arch/arm/tee/optee.c >> +++ b/xen/arch/arm/tee/optee.c >> @@ -215,6 +215,15 @@ static bool optee_probe(void) >> return true; >> } >> =20 >> +/* >> + * TODO: There is a potential issue with guests that either have RAM >> + * at IPA of 0x0 or some of theirs memory is mapped at PA 0x0. This is > ^ their > >> + * because PA of 0x0 is considered as NULL pointer by OP-TEE. It will >> + * not be able to map buffer with such pointer to TA address space, or >> + * use such buffer for communication with the guest. We either need to >> + * check that guest have no such mappings or ensure that OP-TEE >> + * enabled guest will not be created with such mappings. >> + */ >> static int optee_domain_init(struct domain *d) >> { >> struct arm_smccc_res resp; >> @@ -725,6 +734,15 @@ static int translate_noncontig(struct optee_domain = *ctx, >> uint64_t next_page_data; >> } *guest_data, *xen_data; >> =20 >> + /* >> + * Special case: buffer with buf_ptr =3D=3D 0x0 is considered as NU= LL >> + * pointer by OP-TEE. No translation is needed. This can lead to >> + * an issue as IPA 0x0 is a valid address for Xen. See the comment >> + * near optee_domain_init() >> + */ >> + if ( !param->u.tmem.buf_ptr ) >> + return 0; > > Given that today it is not possible for this to happen, it could even be > an ASSERT. But I think I would just return an error, maybe -EINVAL? Hmm, looks like my comment is somewhat misleading :( What I mean, is that param->u.tmem.buf_ptr =3D=3D 0 is the normal situation= . This is the special case, when OP-TEE treats this buffer as a NULL. So we are doing nothing there. Thus, "return 0". But, as Julien pointed out, we can have machine where 0x0 is the valid memory address and there is a chance, that some guest will use it as a pointer to buffer. > Aside from this, and the small grammar issue, everything else looks fine > to me. > > Let's wait for Julien's reply, but if this is the only thing I could fix > on commit. > > >> /* Offset of user buffer withing OPTEE_MSG_NONCONTIG_PAGE_SIZE-size= d page */ >> offset =3D param->u.tmem.buf_ptr & (OPTEE_MSG_NONCONTIG_PAGE_SIZE -= 1); >> =20 >> @@ -865,9 +883,12 @@ static int translate_params(struct optee_domain *ct= x, >> } >> else >> { >> - gdprintk(XENLOG_WARNING, "Guest tries to use old tmem a= rg\n"); >> - ret =3D -EINVAL; >> - goto out; >> + if ( call->xen_arg->params[i].u.tmem.buf_ptr ) >> + { >> + gdprintk(XENLOG_WARNING, "Guest tries to use old tm= em arg\n"); >> + ret =3D -EINVAL; >> + goto out; >> + } >> } >> break; >> case OPTEE_MSG_ATTR_TYPE_NONE: >> --=20 >> 2.26.2 >>=20 --=20 Volodymyr Babchuk at EPAM= From xen-devel-bounces@lists.xenproject.org Tue Jun 23 03:36:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 03:36:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnZjF-0006Zt-2f; Tue, 23 Jun 2020 03:36:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnZjE-0006Zo-DQ for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 03:36:08 +0000 X-Inumbo-ID: ac143746-b502-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x434.google.com (unknown [2a00:1450:4864:20::434]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ac143746-b502-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 03:36:07 +0000 (UTC) Received: by mail-wr1-x434.google.com with SMTP id h5so18962220wrc.7 for ; Mon, 22 Jun 2020 20:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D4wqSIKGFsCHRVPBqjkiTbY/zH06jC+fIhRvgpJIiRU=; b=Y8mu6Abx12+ismB6uSJQcWNz1U4KObb1fv+ZO/HCEIUMDU0tFskFQ/uZP+ppekSRqD e5DLnGx4+7C1QE1E8NsiSCcXKhlgJNqVyBcHJ7M74Q+J07azDm7BhGXAK4S7SM2nksH0 jc3TYfPhHiXOeVEtepLo6MmhstAlAdTTzmYT9hy/KLfvnCsnGqaMXD2aAM7snsV/A0xm zIKnLAgRCwjZQWo/EWMLyASOV5a4tsKW/f3EaB8K8M/hCxMN3AH3S1BDbSik2advqosK amMmR8jjNIYjq02IFLc7TWS6Coj5GqXIAvf11Lx/+xuX1aX2d09LhVcoTzjCl7BF+ika XtFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D4wqSIKGFsCHRVPBqjkiTbY/zH06jC+fIhRvgpJIiRU=; b=okUfmo5Weq3v5aEeCIx62s9hKUTO9TjPh/d/7i011l8JA5mLhCp49eXgHLx1ttzKnD 998UkZev+I75SS52OPlcvcVT/4/gp58GGW5/tpINSluQ7jMbaQg/J8YtfbPA8K+EBw1f QKiC6pq0pgyrxYf+wPtZTag0BxY0TJZad3OEQXaM5dmS3q471H1lUXQ6i13Bs6gWH+bc muREyQlQtkwe1GR/GCviHeuz2l55frejg4w3QrI6hy1LdIKxDjyksvi0ONB+07T0n5Fd WaTiBKxC4jolfGtUcRS7vrcXZyiITfQuizniW+NI2/BMcuf4bNpIJS8mhuIm2n1T/DhA GPSQ== X-Gm-Message-State: AOAM531QIoSCRYT6bOi0IAJGTvXq87F9Y62kQE8aHUUW5VIMNLgN1IsM xQhCfbrTd7HsMbiBiKo243QCiOfpDADYoIdEfh4= X-Google-Smtp-Source: ABdhPJwq3+OdYkvL8iKBnT/liMA1JSKAnZ1WjN/qvc31cItfopI06QHOwwj2CnuqmdMz6dWbG8NJWERAd7BnTSj0BWU= X-Received: by 2002:adf:e648:: with SMTP id b8mr23262509wrn.386.1592883366619; Mon, 22 Jun 2020 20:36:06 -0700 (PDT) MIME-Version: 1.0 References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> <1786138246.11444015.1592849576272.JavaMail.zimbra@cert.pl> In-Reply-To: <1786138246.11444015.1592849576272.JavaMail.zimbra@cert.pl> From: Tamas K Lengyel Date: Tue, 23 Jun 2020 03:35:30 -0600 Message-ID: Subject: Re: [PATCH v3 7/7] tools/proctrace: add proctrace tool To: =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Wei Liu , Tamas K Lengyel , Ian Jackson , "Kang, Luwei" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > + rc = xenforeignmemory_unmap_resource(fmem, fres); > + > + if (rc) { > + fprintf(stderr, "Failed to unmap resource\n"); > + return 1; > + } > + > + rc = xc_vmtrace_pt_disable(xc, domid, vcpu_id); > + > + if (rc) { > + fprintf(stderr, "Failed to call xc_vmtrace_pt_disable\n"); > + return 1; > + } Looks like you are missing an xc_interface_close here. > + > + return 0; > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > -- > 2.20.1 > > From xen-devel-bounces@lists.xenproject.org Tue Jun 23 03:41:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 03:41:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnZo5-0007Tl-MF; Tue, 23 Jun 2020 03:41:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnZo4-0007Td-OB for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 03:41:08 +0000 X-Inumbo-ID: 5f25dfb0-b503-11ea-b7bb-bc764e2007e4 Received: from mail-lj1-x22f.google.com (unknown [2a00:1450:4864:20::22f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5f25dfb0-b503-11ea-b7bb-bc764e2007e4; Tue, 23 Jun 2020 03:41:08 +0000 (UTC) Received: by mail-lj1-x22f.google.com with SMTP id i27so21708972ljb.12 for ; Mon, 22 Jun 2020 20:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g780v6WnLYQ1QZQRWq+6mQKK2XsAf/u1xfSFw0Z6JFs=; b=nkO5PKTHb8KutOobp7Hgg+WgOCYi/XoTF9/3Vxe5VfF8NFti+41Pbu/33yI+D8AQsq Ky9jOYjaj1wJff8Skb2LVhjnLwjyOwRsnOUvotHAXYRKjTCiHmIX9wn4jCAksbtjIdTI 58vdQCHRAVYOmMvccfsH9inZ2nczLKA7q2rbGBJXGFqkrkecCToCo25wfPFefpORLBl6 JS3sRSuX6u/92iF1QgVsQwiWvLFpR5rX4wdzG/TcZ8fL2fKLgyEkNx5UrTPAYTC00oNx Iede+FD2k91tVb53kUAVjYO9dajw6a5TtNiTIfbLa8tBAMCeQE+vMbS567v9CzUXNNtX MnDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g780v6WnLYQ1QZQRWq+6mQKK2XsAf/u1xfSFw0Z6JFs=; b=TUWhsb1wWE9ar0UMk2RVImiIwhQAkgtAa6pu2TIcexxCuTdm5FMaeKvfAssCMNNIAN HAIegPf11wn4IumY43Xo/u3C9DO3ZsZY8qO5wVLPnUfvZ3EK+ivDyqXBd2wF6+Kd07W7 gU4nRjLTKOvmofO02RDvrF8TYhEcqjoaROXJ/5D/zQ2qkRMAPEby9FKbcMV3zLBW6mRf gxk07IseXPp3EZnnnrpiRqC3dYm8ut4v61n1QUJAj2/yH/aD5BykL3iFdlSrs8kb2y4c vx0ecIIdAkj3oFE0dqtC3ZUwGGp8TrvuW5HHiCxXHFcLYtSFm9Cnt4eOnkqNV9DDijgx NzrA== X-Gm-Message-State: AOAM531WlQ6QrmXmk5wD6w8elED04BHqy5ToxUzSgWgxqDlnpJnXXEF7 zDF/GDBRB06Q4BzX6tdFl7TiNR/buSZAeyALYSE= X-Google-Smtp-Source: ABdhPJyBZV5fmqperXCFj6v08Ebo6e6nCRkDfnitOFhxpl87pM0Cj79N1j1ptSWGuTMvlschI12cqgk9yx9AUkKiFyY= X-Received: by 2002:a2e:9141:: with SMTP id q1mr9666796ljg.196.1592883666790; Mon, 22 Jun 2020 20:41:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jason Andryuk Date: Mon, 22 Jun 2020 23:40:55 -0400 Message-ID: Subject: Re: sysbus failed assert for xen_sysdev To: Mark Cave-Ayland Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , xen-devel , Paul Durrant , QEMU , Markus Armbruster Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 5:17 PM Mark Cave-Ayland wrote: > > On 22/06/2020 21:33, Jason Andryuk wrote: > > > Hi, > > > > Running qemu devel for a Xen VM is failing an assert after the recent > > "qdev: Rework how we plug into the parent bus" sysbus changes. > > > > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > > failed. > > > > dc->bus_type is "xen-sysbus" and it's the > > `object_dynamic_cast(OBJECT(bus), dc->bus_type)` portion that fails > > the assert. bus seems to be "main-system-bus", I think: > > (gdb) p *bus > > $3 = {obj = {class = 0x55555636d780, free = 0x7ffff7c40db0 , > > properties = 0x5555563f7180, ref = 3, parent = 0x5555563fe980}, parent > > = 0x0, name = 0x5555563fec60 "main-system-bus", ... > > > > The call comes from hw/xen/xen-legacy-backend.c:706 > > sysbus_realize_and_unref(SYS_BUS_DEVICE(xen_sysdev), &error_fatal); > > > > Any pointers on what needs to be fixed? > > Hi Jason, > > My understanding is that the assert() is telling you that you're plugging a > TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. A quick look > at the file in question suggests that you could try changing the parent class of > TYPE_XENSYSBUS from TYPE_BUS to TYPE_SYSTEM_BUS to see if that helps? Hi, Mark. Thanks, but unfortunately changing xensysbus_info .parent does not stop the assert. But it kinda pointed me in the right direction. xen-sysdev overrode the bus_type which was breaking sysbus_realize. So drop that: --- a/hw/xen/xen-legacy-backend.c +++ b/hw/xen/xen-legacy-backend.c @@ -824,7 +825,7 @@ static void xen_sysdev_class_init(ObjectClass *klass, void *data) DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_props(dc, xen_sysdev_properties); - dc->bus_type = TYPE_XENSYSBUS; + //dc->bus_type = TYPE_XENSYSBUS; } static const TypeInfo xensysdev_info = { Then I had a different instance of the failed assert trying to attach xen-console-0 to xen-sysbus. So I made this change: --- a/hw/xen/xen-legacy-backend.c +++ b/hw/xen/xen-legacy-backend.c @@ -789,6 +789,7 @@ static void xendev_class_init(ObjectClass *klass, void *data) set_bit(DEVICE_CATEGORY_MISC, dc->categories); /* xen-backend devices can be plugged/unplugged dynamically */ dc->user_creatable = true; + dc->bus_type = TYPE_XENSYSBUS; } static const TypeInfo xendev_type_info = { Then it gets farther... until qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: Assertion `dev->realized' failed. dev->id is NULL. The failing device is: (gdb) p *dev.parent_obj.class.type $12 = {name = 0x555556207770 "cfi.pflash01", Is that right? I'm going to have to take a break from this now. Regards, Jason From xen-devel-bounces@lists.xenproject.org Tue Jun 23 03:54:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 03:54:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jna0O-0008Vx-Tj; Tue, 23 Jun 2020 03:53:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jna0N-0008VX-7f for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 03:53:51 +0000 X-Inumbo-ID: 21a31f16-b505-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 21a31f16-b505-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 03:53:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xpevqBMxCQoXFKX6ilWoXOKWupTcwmBY30WLjTJiY+s=; b=qu71Cg2HAozWwYOI+BHKNmA53 1dSovuXDb0U85aiyoAm6GQ/aX5+mayUFpuPbL/9Ft8zeXFPOuiof/Y/PmyI2RGm3tzIg2Q7Peumqz POKC5+XvBbteFYSax4xRnX+mY77RMnm9FfkT/TCf6LUg7ye1qpBrF5X5GVyYGqNGuc1M4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jna0E-0001DE-2L; Tue, 23 Jun 2020 03:53:42 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jna0D-000116-Oz; Tue, 23 Jun 2020 03:53:41 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jna0D-0007Xa-Nb; Tue, 23 Jun 2020 03:53:41 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 151288: regressions - FAIL X-Osstest-Failures: linux-5.4:test-amd64-amd64-xl-credit2:guest-localmigrate:fail:regression linux-5.4:test-amd64-i386-libvirt-xsm:guest-start.2:fail:regression linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=67cb016870e2fa9ffc8d34cf20db5331e6f2cf4d X-Osstest-Versions-That: linux=fd8cd8ac940c8b45b75474415291a3b941c865ab From: osstest service owner Date: Tue, 23 Jun 2020 03:53:41 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151288 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/151288/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 16 guest-localmigrate fail REGR. vs. 151232 test-amd64-i386-libvirt-xsm 19 guest-start.2 fail REGR. vs. 151232 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 67cb016870e2fa9ffc8d34cf20db5331e6f2cf4d baseline version: linux fd8cd8ac940c8b45b75474415291a3b941c865ab Last test of basis 151232 2020-06-19 05:33:37 Z 3 days Testing same since 151288 2020-06-22 07:40:16 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aaron Brown Adrian Hunter Al Viro Alan Maguire Alex Deucher Alexander Monakov Alexander Sverdlin Alexandre Belloni Alexei Starovoitov Alexey Malahov Anand Jain Anders Roxell Andrea Arcangeli Andrea Parri (Microsoft) Andrew Bowers Andrew Morton Andrii Nakryiko Andrzej Hajda Andy Shevchenko Anton Protopopov Ard Biesheuvel Arnaldo Carvalho de Melo Arnd Bergmann Arthur Kiyanovski Arvind Sankar Ashok Raj Ayush Sawal Bart van Assche Bhupesh Sharma Bingbu Cao Bjorn Andersson Bjorn Helgaas Bjorn Helgaas Bob Moore Bogdan Togorean Boris Brezillon Borislav Petkov Brad Love Brian Foster chen gong Chih-Min Chen Chris Chiu Christian König Christian Lamparter Christoph Hellwig Christophe JAILLET Christophe Leroy Chuhong Yuan Chun-Kuang Hu Colin Ian King Coly Li Corentin Labbe Dan Carpenter Daniel Axtens Daniel Borkmann Daniel Jordan Daniel Lezcano Daniel Thompson Darrel Goeddel Darrick J. Wong Dave Hansen Dave Jiang David Gow David Hildenbrand David S. Miller David Sterba David.Laight@aculab.com (big endian system concerns) Dejin Zheng Devulapally Shiva Krishna Dmitry Osipenko Doug Berger Douglas Anderson Eelco Chaudron Erez Shitrit Erhard F. Eric Biggers Erik Kaneda Evan Green Felix Fietkau Felix Kuehling Feng Tang Filipe Manana Finn Thain Florian Fainelli Ganapathi Bhat Gavin Shan Geert Uytterhoeven Geert Uytterhoeven Georgy Vlasov Govindaraj Saminathan Greg Kroah-Hartman Guenter Roeck Guoqing Jiang H. Nikolaus Schaller Haibo Chen Hans de Goede Hans Verkuil Hari Bathini Harshad Shirwadkar Herbert Xu Hsin-Yu Chao Huaixin Chang Ian Rogers Ingo Molnar Ioana Ciornei Ivan Kokshaysky J. Bruce Fields Jacob Keller Jaegeuk Kim Jaehoon Chung Jakub Sitnicki James Morris Jann Horn Jay Cornwall Jean-Philippe Brucker Jeff Kirsher Jeffle Xu Jens Axboe Jeremy Cline Jeremy Kerr Jernej Skrabec Jesper Dangaard Brouer Jia-Ju Bai Jiaxun Yang Jiri Olsa Jitao Shi Johan Hovold John Fastabend Jon Derrick Jon Doron Jonathan Bakker Josef Bacik Josh Poimboeuf Julien Thierry Juxin Gao Kai-Heng Feng Kaige Li Kalle Valo Kees Cook Kevin Buettner Kieran Bingham Kirill A. Shutemov Koba Ko Krzysztof Kozlowski Krzysztof Struczynski Larry Finger Laurent Pinchart Laurent Pinchart limingyu Linus Torvalds Linus Walleij Lorenzo Pieralisi Luca Coelho Ludovic Desroches Lukas Wunner Luke Nelson Luke Nelson Maharaja Kennadyrajan Marcel Holtmann Marcos Paulo de Souza Marcos Scriven Marek Szyprowski Mark Brown Mark Starovoytov Martin Blumenstingl Masahiro Yamada Masami Hiramatsu Matt Turner Mauro Carvalho Chehab Michael Ellerman Michael Ellerman (powerpc) Michal Hocko Michał Mirosław Mike Snitzer Mikulas Patocka Mimi Zohar Ming Lei Miquel Raynal Mordechay Goodstein Nathan Chancellor NeilBrown Nick Desaulniers Nickolai Kozachenko Nicolas Chauvet Nicolas Toromanoff Nikolay Borisov Omar Sandoval Pablo Neira Ayuso Pali Rohár Paolo Bonzini Paul Moore Pavel Tatashin Peter Zijlstra (Intel) Peter Zijlstra Punit Agrawal Qian Cai Qiushi Wu Qu Wenruo Rafael J. Wysocki Rajmohan Mani Rakesh Pillai Rob Herring Roberto Sassu Rui Miguel Silva Russell King Ryder Lee Saeed Mahameed Sagi Grimberg Sakari Ailus Sameeh Jubran Samuel Holland Sasha Levin Sean Young Sebastian Reichel Serge Semin Shaokun Zhang Sharon Simon Wunderlich Song Liu Stephane Eranian Stephen Boyd Surabhi Boob Sven Eckelmann Tejun Heo Theodore Ts'o Thierry Reding Thomas Bogendoerfer Tiezhu Yang Tobias Baumann <017623705678@o2online.de> Toke Høiland-Jørgensen Tom Lendacky Tomasz Figa Tomi Valkeinen Tomohito Esaki Tony Lindgren Tony Nguyen Toshiaki Makita Tuan Phan Ulf Hansson Veerabhadrarao Badiganti Venkateswara Naralasetty Vinod Koul Vladimir Zapolskiy Vlastimil Babka Wei Liu Wei Yongjun Weiping Zhang Weiyi Lu Wen Gong Will Deacon Xi Wang Xie XiuQi Yan-Hsuan Chuang Yazen Ghannam YuanJunQing Yunjian Wang zhoubinbin Álvaro Fernández Rojas jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 fail test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 8527 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 23 05:32:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 05:32:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnbXQ-00019V-AM; Tue, 23 Jun 2020 05:32:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnbXO-00019Q-O6 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 05:32:02 +0000 X-Inumbo-ID: dcc8365c-b512-11ea-bf0e-12813bfff9fa Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [40.107.20.86]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dcc8365c-b512-11ea-bf0e-12813bfff9fa; Tue, 23 Jun 2020 05:32:01 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n/zLWZ7IsmFGxawv7bBFp1jRt+cUKe/EojuCv5H8yEGEl4vRPknv7t+ztH3i94bS6r4tUtkG+v0omQRBuLzw2dzQ2lpoUtLdJHiapZGsEkjzeXzf866ZC4YprpLK1My811X+9357OL5lFNiNvKgPy4uy/Ow6ktTQkvq8og1c2lCbT85h3R/hUk6dQ0JyMBRgQZCnF8alFJAOMoqj14VRpLADRS6YuvPQF095lEhgZK4r82bMJ/Hi2a1JhcTrxsLmBJWiLKROkIhKxjfTPpMzIeSV4AVAJYUE62wyLqDMTRmPK+4ja2lK6L3rT7dLOaOyjfLea5+Ll1I25WjA1wZAjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1vOkOwfSKYJz+QCvsXcJFiDvR8ra5FU5+BzRpP0dZnQ=; b=ki7aEw+uAHy5Tvl8ANTL2fMbXuGDSx015vc2U4Qn+LZiB+ifWqsI8CrXIHLPOIBZLjDANK4P52je3jkXuFl+i/3ga/B++nOg5Z2W2hjmQqNvQvAte/qxY+ak6dcoHPc53bF5Ajq8xZtH5auVkoJtci6br9AdWkvnvFoECDwz636rb+DtFDpfOVSaK9v/JTsVMTzPoeZ0NuJqRW/LSlEZlWgSAMQYqa2a8QfNkJcnLjEfQgGIvC76bVnmpjprGU+OfAnKGeRtoxUqBCqFNY83rc0E0AT1lFjW4IlNuiojumrQoTdSDtXr4KnSGpZPRyEjFgD9R8/beX89Gv92BGk0tA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1vOkOwfSKYJz+QCvsXcJFiDvR8ra5FU5+BzRpP0dZnQ=; b=yzJNAErUSNMcmskTZOSXFeujlEhhsN1cX5VfF1w0haosctVxhoeA3F0KpDSf9EItyDvP1TakJ0WIUyGEek15lWYBzcLTTdWhqmO7ktikcCWh8AFPdsc7FdvSvE5o99KDRPiwdN+JMpQ1CKGZkeuLRUsDvmAhuevN9LOD3XKNuvwjV2bMXZChFk0wNFrdbL1U6phsD9LbkO/EXAOrpe9fSxmCMOQ3T+XRjY+q9HIcSkhHlhK8ENJ86lhvJyaMOxTHucm55ekosJuD7ABa6QfsMVEkr25XYReOpwqm2uxW74nKEDjtygM7G7GtnUyzERD6qSmU/P4kNSYpqcXBdxezgg== Received: from AM6PR03MB3991.eurprd03.prod.outlook.com (2603:10a6:20b:25::20) by AM6PR03MB4024.eurprd03.prod.outlook.com (2603:10a6:20b:1b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Tue, 23 Jun 2020 05:31:58 +0000 Received: from AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c]) by AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c%4]) with mapi id 15.20.3109.027; Tue, 23 Jun 2020 05:31:58 +0000 From: Oleksandr Andrushchenko To: Stefano Stabellini , Julien Grall Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAWPDgIAEUtgAgAAGgYCAAAHAgIAANpaAgAB+IgCAAEYyAA== Date: Tue, 23 Jun 2020 05:31:58 +0000 Message-ID: <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [46.133.149.85] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 61fef3a9-d425-4b84-3ab1-08d81736bfb2 x-ms-traffictypediagnostic: AM6PR03MB4024: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 04433051BF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7XAv0lLnuILoViAbKQN43oNXZ/KyPou4DEEeLuCUmSS6Opore6bZQYtyLiCsKD+19G6PQG7lEuFQE/h+plB54x6IBjDnyzE6ZeoLwrObE36floIDpqEnpEY0/1FTjrRU/X9FnoV6Q+8voO15c5iJQ9CyFJnETpRn/vMaoABDa2LaaYG+8lEjGVpHxyAaPwgDjfND3lpj1FwbpD7sbzeiz3R9uLpZd/I35wodjnx157ay5wuUjXVXRDM34o9gIZAjt73fH2FAASO1eZc3MAKjlOuWEEHctL0NsSdXERloWYHdO7Gz+URrayj78EPLa4MA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR03MB3991.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(39860400002)(366004)(376002)(86362001)(6512007)(7416002)(71200400001)(2906002)(8936002)(83380400001)(478600001)(2616005)(8676002)(5660300002)(6486002)(54906003)(76116006)(66556008)(64756008)(66446008)(66476007)(36756003)(66946007)(91956017)(6506007)(4326008)(53546011)(316002)(110136005)(31696002)(31686004)(186003)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: lThZ8TJeUEvlL89StVVIfo6KHqsapgV2oCnAcxnVLUssZesLwOlxte5yVg3pOTIi7+h7PZOGmN5/w5R8hxuJxImsEagjI3ehodojSLuRoPO4oiHeWtPI2WqV31+3aLLLL1hjRRF/W+YMhVA4WMvkRglekO2pV+412LZAAVgGKtDTzkDZj4CoiEq56sBX7Q7osPCt7lVUx/TkHq2Scq9m7F1tMfGV5BuLhiFxGjfU8NZRv+0/eujP07v/w4jW+DPO7JYBQWPxOykKebRD3Fs8XAmu73i/Am9eEu0PP7bv4KP0yRJuoRAN7k8My05L+crI5gVfohm3G0B8V/3yBkj2rC0a88rB0ZiM16pmuyevsr15Bb3N9bf/NCpkLvVQrsa/dvUYxV6WZeZ6hNtrihoB14w3Mia0knIDs5iJXSA124JuSn7NKQ7zPFkD5qSNQj80dQQtIceup3ljQqgfDjjW4n1gVA8xETtUUX9KKrHM31o= Content-Type: text/plain; charset="utf-8" Content-ID: <0AE33060BD6EFA43B47B506147271983@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 61fef3a9-d425-4b84-3ab1-08d81736bfb2 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 05:31:58.4107 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f9yj3e01/i0lFon5IummjYhW/l2abeCtp8z+f+ikhKuSNmd6iEGX5SX4corzaeO6IClII0ccz8JgJdZA1WUuDbO49hzhmms1hkO8VV90r+EuZ5QzPLqAviALrIekIjPy X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB4024 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzIzLzIwIDQ6MjAgQU0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gT24gTW9u LCAyMiBKdW4gMjAyMCwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPj4+Pj4gRm9yIHRoZSBmaXJzdCBw YXJ0IChfX1hFTl9JTlRFUkZBQ0VfVkVSU0lPTl9fKSBJIHRoaW5rIHdlIGNhbiBwcm92aWRlIGl0 DQo+Pj4+PiB2aWENCj4+Pj4+DQo+Pj4+PiBDRkxBR1Mgb3Igc29tZXRoaW5nLiBUaGlzIGNhbiBh bHNvIGJlIGRvbmUgZm9yIHRoZSBsb2NhdGlvbiBvZiBYZW4NCj4+Pj4+IGhlYWRlcnMuDQo+Pj4+ IF9fWEVOX0lOVEVSRkFDRV9WRVJTSU9OX18gc2hvdWxkIHdvcmsgdGhyb3VnaCB0aGUgQ0ZMQUdT LiBBbiBhbHRlcm5hdGl2ZQ0KPj4+PiB3b3VsZCBiZSB0byBhbGxvdyB0aGUgdXNlciB0byBzcGVj aWZ5IHRocm91Z2ggdGhlIEtjb25maWcuDQo+Pj4gWW91IG1lYW4gc3BlY2lmeWluZyB2aWEgS2Nv bmZpZyBzb21ldGhpbmcgbGlrZSAiMHgwMDA0MGQwMCI/DQo+PiBQb3NzaWJseSB5ZXMuDQo+Pg0K Pj4+IEFuZCB3aGF0IGFib3V0IHRoZSBoZWFkZXJzPyBIb3cgd2lsbCB3ZSBwcm92aWRlIHRoZWly IGxvY2F0aW9uIGlmIHdlIGRlY2lkZQ0KPj4+IG5vdCB0byBpbmNsdWRlIHRob3NlDQo+Pj4NCj4+ PiBpbiB0aGUgdHJlZT8NCj4+IEkgd291bGQgZG8gdGhyb3VnaCBLY29uZmlnIGFzIHdlbGwuDQo+ IElmIHdlIHNwZWNpZnkgdGhlIGV4dGVybmFsIGxvY2F0aW9uIG9mIHRoZSBYZW4gaGVhZGVycyB2 aWEgS2NvbmZpZywgaXQNCj4gc2VlbXMgdG8gbWUgdGhhdCB3ZSBzaG91bGQgYmUgYWJsZSB0byBk ZXRlY3QgdGhlIGludGVyZmFjZSB2ZXJzaW9uDQo+IGF1dG9tYXRpY2FsbHkgZnJvbSBhbnkgTWFr ZWZpbGUgYXMgcGFydCBvZiB0aGUgYnVpbGQuIE5vIG5lZWQgdG8gYXNrIHRoZQ0KPiB1c2VyLg0K Pg0KPiBIb3dldmVyLCBpZiBPbGVrc2FuZHIgaXMgdGhpbmtpbmcgb2YgdXNpbmcgdGhlIFhlbiBo ZWFkZXJzIGZvciB0aGUNCj4gaHlwZXJjYWxscyBkZWZpbml0aW9ucywgdGhlbiBJIHRoaW5rIHdl IG1pZ2h0IG5vdCBuZWVkIGV4dGVybmFsIGhlYWRlcnMNCj4gYXQgYWxsIGJlY2F1c2UgdGhhdCBp cyBhIHN0YWJsZSBpbnRlcmZhY2UsIGFzIEp1bGllbiB3cm90ZS4gV2UgY291bGQNCj4ganVzdCBk ZWZpbmUgb3VyIG93biBmZXcgaGVhZGVycyBmb3IganVzdCB3aGF0IHlvdSBuZWVkIGxpa2UgTGlu dXggZG9lcy4NCg0KVGhpcyBpcyBhIGdvb2QgaWRlYTogSSdsbCB0cnkgdG8gZ2V0IHRoZSBtaW5p bWFsIHNldCBvZiBoZWFkZXJzIGZyb20gTGludXgNCg0KaW5zdGVhZCBvZiBYZW4gYXMgdGhvc2Ug c2VlbSB0byBiZSB3ZWxsIHByZXBhcmVkIGZvciBzdWNoIGEgdXNlLWNhc2UuIFRoaXMNCg0Kd2F5 IHdlJ2xsIGhhdmUgaGVhZGVycyBpbiBVLWJvb3QgdHJlZSBhbmQgZ3VhcmFudGVlIHRoYXQgd2Ug aGF2ZSBhIG1pbmltYWwNCg0Kc3Vic2V0IHdoaWNoIGlzIGVhc2llciB0byBtYWludGFpbi4gSSds bCBrZWVwIHlvdSB1cGRhdGVkIG9uIHRoZSBwcm9ncmVzcw0KDQo+DQo+IElmIHlvdSBjYW4gZG8g dGhhdCwgSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgYmVjYXVzZSB3ZSBkZWNvdXBsZSB0aGUN Cj4gVUJvb3QgYnVpbGQgZnJvbSB0aGUgWGVuIGJ1aWxkIGNvbXBsZXRlbHkuIFdlIGRvbid0IGV2 ZW4gbmVlZCB0aGUgWGVuDQo+IHRyZWUgY2hlY2tlZCBvdXQgdG8gYnVpbGQgVUJvb3QuIEl0IHdv dWxkIGJlIGEgaHVnZSBhZHZhbnRhZ2UgYmVjYXVzZSBpdA0KPiBtYWtlcyBpdCBmYXIgZWFzaWVy IHRvIGJ1aWxkLXRlc3QgY2hhbmdlcyBmb3Igb3RoZXJzIGluIHRoZSBjb21tdW5pdHkNCj4gdGhh dCBkb24ndCBrbm93IGFib3V0IFhlbiBhbmQgYWxzbyBpdCBiZWNvbWVzIGZhciBlYXNpZXIgdG8g aW50ZWdyYXRlDQo+IGludG8gYW55IGJ1aWxkIHN5c3RlbS4= From xen-devel-bounces@lists.xenproject.org Tue Jun 23 08:19:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 08:19:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jne9G-00083I-9S; Tue, 23 Jun 2020 08:19:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jne9F-00083D-Mc for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 08:19:17 +0000 X-Inumbo-ID: 39602264-b52a-11ea-bf26-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 39602264-b52a-11ea-bf26-12813bfff9fa; Tue, 23 Jun 2020 08:19:15 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ZRmsZgvndMLKlaHYgf+qJD/49thRx3s73TfBWrx+DqKTmUHpwKUQKNuTooiaUqS9PwlHrCRV6r MDsF3Ur+0CBVWuWqfZd82RxcsMJwhSMOAkU2xSEibiYfblGe2hF7fHZdC+cgc/hNdS/ZsGEUGI wl/aKVu9h+7Qh/QJ/o9WFe5kYjq+scFieaixz3fJa4aTAGAvwjV0Fzkwl7G+hg+SNUgQXQ4OCK K/ZSc6/OtOogVSoledpNc1794Fa9bGBUZDOc5hjyf5Yk9Z1U7yEm47l9laczbBDdQRs1Q6ztuH ZWI= X-SBRS: 2.7 X-MesageID: 21489538 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,270,1589256000"; d="scan'208";a="21489538" Date: Tue, 23 Jun 2020 10:19:03 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Anchal Agarwal Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Message-ID: <20200623081903.GP735@Air-de-Roger> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200617083528.GW735@Air-de-Roger> <20200619234312.GA24846@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200622083846.GF735@Air-de-Roger> <20200623004314.GA28586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200623004314.GA28586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 12:43:14AM +0000, Anchal Agarwal wrote: > On Mon, Jun 22, 2020 at 10:38:46AM +0200, Roger Pau Monné wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > On Fri, Jun 19, 2020 at 11:43:12PM +0000, Anchal Agarwal wrote: > > > On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monné wrote: > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > > > > > On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > > > > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monné wrote: > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > > > > > + "the device may become inconsistent state"); > > > > > > > > > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > > > > > state and with the queues frozen. You should make an attempt to > > > > > > > restore things to a working state. > > > > > > > > > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > > > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > > > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > > > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > > > > > > > > > You can manually force this state, and then check that it will behave > > > > > > correctly. I would expect that on a failure to disconnect from the > > > > > > backend you should switch the frontend to the 'Init' state in order to > > > > > > try to reconnect to the backend when possible. > > > > > > > > > > > From what I understand forcing manually is, failing the freeze without > > > > > disconnect and try to revive the connection by unfreezing the > > > > > queues->reconnecting to backend [which never got diconnected]. May be even > > > > > tearing down things manually because I am not sure what state will frontend > > > > > see if backend fails to to disconnect at any point in time. I assumed connected. > > > > > Then again if its "CONNECTED" I may not need to tear down everything and start > > > > > from Initialising state because that may not work. > > > > > > > > > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > > > > > I don't see it getting handled in the backend then what will be backend's state? > > > > > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > > > > > if it tries to read backend's state through xenbus_read_driver_state ? > > > > > > > > > > So the flow be like: > > > > > Front end marks XenbusStateClosing > > > > > Backend marks its state as XenbusStateClosing > > > > > Frontend marks XenbusStateClosed > > > > > Backend disconnects calls xen_blkif_disconnect > > > > > Backend fails to disconnect, the above function returns EBUSY > > > > > What will be state of backend here? > > > > > > > > Backend should stay in state 'Closing' then, until it can finish > > > > tearing down. > > > > > > > It disconnects the ring after switching to connected state too. > > > > > Frontend did not tear down the rings if backend does not switches the > > > > > state to 'Closed' in case of failure. > > > > > > > > > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend > > > > > > > > Backend will stay in state 'Closing' I think. > > > > > > > > > won't be calling connect(). {From reading code in frontend_changed} > > > > > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > > > > > we did not tear down anything so calling talk_to_blkback may not be needed > > > > > > > > > > Does that sound correct? > > > > > > > > I think switching to the initial state in order to try to attempt a > > > > reconnection would be our best bet here. > > > > > > > It does not seems to work correctly, I get hung tasks all over and all the > > > requests to filesystem gets stuck. Backend does shows the state as connected > > > after xenbus_dev_suspend fails but I think there may be something missing. > > > I don't seem to get IO interrupts thereafter i.e hitting the function blkif_interrupts. > > > I think just marking it initialised may not be the only thing. > > > Here is a short description of what I am trying to do: > > > So, on timeout: > > > Switch XenBusState to "Initialized" > > > unquiesce/unfreeze the queues and return > > > mark info->connected = BLKIF_STATE_CONNECTED > > > > If xenbus state is Initialized isn't it wrong to set info->connected > > == CONNECTED? > > > Yes, you are right earlier I was marking it explicitly but that was not right, > the connect path for blkfront will do that. > > You should tear down all the internal state (like a proper close)? > > > Isn't that similar to disconnecting in the first place that failed during > freeze? Do you mean re-try to close but this time re-connect after close > basically do everything you would at "restore"? Last time I checked blkfront supported reconnections (ie: disconnect from a backend and connect again). I was assuming we could apply the same here on timeout, and just follow the same path where the frontend waits indefinitely for the backend to close and then attempts to reconnect. > Also, I experimented with that and it works intermittently. I want to take a > step back on this issue and ask few questions here: > 1. Is fixing this recovery a blocker for me sending in a V2 version? At the end of day it's your feature. I would certainly prefer for it to work as good as possible, this being a recovery in case of failure just make sure it does something sane (ie: crash/close the frontend) and add a TODO note. > 2. In our 2-3 years of supporting this feature at large scale we haven't seen this issue > where backend fails to disconnect. What we are trying to do here is create a > hypothetical situation where we leave backend in Closing state and try and see how it > recovers. The reason why I think it "may not" occur and the timeout of 5HZ is > sufficient is because we haven't come across even a single use-case where it > caused hibernation to fail. > The reason why I think "it may" occur is if we are running a really memory > intensive workload and ring is busy and is unable to complete all the requests > in the given timeout. This is very unlikely though. As said above I would generally prefer for code to handle possible failures the best way, and hence I think here it would be nice to fallback to the normal disconnect path and just wait for the backend to close. You likely have this very well tuned to your own environment and workloads, since this will now be upstream others might have more contended systems where it could start to fail. > 3) Also, I do not think this may be straight forward to fix and expect > hibernation to work flawlessly in subsequent invocations. I am open to > all suggestions. Right, adding a TODO would seem appropriate then. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 08:21:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 08:21:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jneBA-0000LN-Ly; Tue, 23 Jun 2020 08:21:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jneB9-0000LE-St for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 08:21:15 +0000 X-Inumbo-ID: 8139d6c0-b52a-11ea-bf26-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8139d6c0-b52a-11ea-bf26-12813bfff9fa; Tue, 23 Jun 2020 08:21:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 326CCADCA; Tue, 23 Jun 2020 08:21:14 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/msr: Disallow access to Processor Trace MSRs To: Andrew Cooper References: <20200619115823.22243-1-andrew.cooper3@citrix.com> <32440578-e346-85cc-abad-1aa5694f0ab2@suse.com> <855c1668-3f91-c084-70d5-76f3e171f074@citrix.com> From: Jan Beulich Message-ID: <7e20b9fb-7722-eac2-be73-81b40eb7c5ac@suse.com> Date: Tue, 23 Jun 2020 10:21:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 19:16, Andrew Cooper wrote: > On 19/06/2020 14:39, Jan Beulich wrote: >> On 19.06.2020 15:28, Andrew Cooper wrote: >>> On 19/06/2020 13:48, Jan Beulich wrote: >>>> On 19.06.2020 13:58, Andrew Cooper wrote: >>>>> --- a/xen/arch/x86/msr.c >>>>> +++ b/xen/arch/x86/msr.c >>>>> @@ -168,6 +168,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) >>>>> case MSR_TSX_FORCE_ABORT: >>>>> case MSR_TSX_CTRL: >>>>> case MSR_MCU_OPT_CTRL: >>>>> + case MSR_RTIT_OUTPUT_BASE: >>>>> + case MSR_RTIT_OUTPUT_MASK: >>>>> + case MSR_RTIT_CTL: >>>>> + case MSR_RTIT_STATUS: >>>>> + case MSR_RTIT_CR3_MATCH: >>>>> + case MSR_RTIT_ADDR_A(0) ... MSR_RTIT_ADDR_B(3): >>>> The respective CPUID field is 3 bits wide, so wouldn't it be better >>>> to cover the full possible range (0...6 afaict)? >>> Last time I tried, you objected to me covering MSR ranges which weren't >>> defined. >> Wasn't that for a range where some number had been re-used from >> earlier models (with entirely different purpose)? > > I don't recall, but the answer isn't relevant to whether the MSRs at > those indices ought to be available to guests. > >>> If you want to extend the range like that, it ought to be >>> MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7) to cover the entire area >>> which seems to be exclusively for PT. >> I'd be okay with that, just that I'm not sure about (7): While >> SDM Vol 2 oddly enough doesn't seem to list anything for leaf 7 >> subleaf 1 (or I'm sufficiently blind today), Vol 4 clearly says >> for n=0...3 "If CPUID.(EAX=07H,ECX=1):EAX[2:0] > ", and the >> field obviously can't be > 7. > > 7 gives the top of the bank of MSRs.  It isn't related to CPUID data. Well, okay - let's go that route then? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 23 08:41:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 08:41:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jneUM-0002Fq-Bb; Tue, 23 Jun 2020 08:41:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jneUK-0002Fl-Fr for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 08:41:04 +0000 X-Inumbo-ID: 456f99a6-b52d-11ea-bb8b-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 456f99a6-b52d-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 08:41:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592901662; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=sl2aLIMZTkMUzz73gxGV+eU20yHtpI0l7eAFEJS0YFk=; b=COBX1rmpPnA1BdjXpklHaM0iKhWir8BJXJaGMVXTKjlBHsiEMi3UYwjutoqjhFFrss1Ro/ L1ZQbb1/ULVHOTXHvidogSjqDMoGWxKHaw8mwoXfryFm8uKxM88NNaiFLTS/TcFndQH27b qmQBWPsYVwD++iCu9/qt6zqOZNwxKjY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-95-YRIQTpICPz27ImUjIsSi6g-1; Tue, 23 Jun 2020 04:40:58 -0400 X-MC-Unique: YRIQTpICPz27ImUjIsSi6g-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5A8018035A8; Tue, 23 Jun 2020 08:40:57 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-112-121.ams2.redhat.com [10.36.112.121]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8C2F91002391; Tue, 23 Jun 2020 08:40:56 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id E6694113846D; Tue, 23 Jun 2020 10:40:54 +0200 (CEST) From: Markus Armbruster To: Jason Andryuk Subject: Re: sysbus failed assert for xen_sysdev References: Date: Tue, 23 Jun 2020 10:40:54 +0200 In-Reply-To: (Jason Andryuk's message of "Mon, 22 Jun 2020 23:40:55 -0400") Message-ID: <87k0zykwdl.fsf@dusky.pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=armbru@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , xen-devel , Mark Cave-Ayland , QEMU , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jason Andryuk writes: > On Mon, Jun 22, 2020 at 5:17 PM Mark Cave-Ayland > wrote: >> >> On 22/06/2020 21:33, Jason Andryuk wrote: >> >> > Hi, >> > >> > Running qemu devel for a Xen VM is failing an assert after the recent >> > "qdev: Rework how we plug into the parent bus" sysbus changes. >> > >> > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion >> > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' >> > failed. >> > >> > dc->bus_type is "xen-sysbus" and it's the >> > `object_dynamic_cast(OBJECT(bus), dc->bus_type)` portion that fails >> > the assert. bus seems to be "main-system-bus", I think: >> > (gdb) p *bus >> > $3 = {obj = {class = 0x55555636d780, free = 0x7ffff7c40db0 , >> > properties = 0x5555563f7180, ref = 3, parent = 0x5555563fe980}, parent >> > = 0x0, name = 0x5555563fec60 "main-system-bus", ... >> > >> > The call comes from hw/xen/xen-legacy-backend.c:706 >> > sysbus_realize_and_unref(SYS_BUS_DEVICE(xen_sysdev), &error_fatal); >> > >> > Any pointers on what needs to be fixed? >> >> Hi Jason, >> >> My understanding is that the assert() is telling you that you're plugging a >> TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. >> TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. A quick look Correct. Let's review the assertion: assert(dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)); Context: we're supposted to plug @dev into @bus, and @dc is @dev's DeviceClass. The assertion checks that 1. @dev plugs into a bus: dc->bus_type 2. @bus is an instance of the type of bus @dev plugs into: object_dynamic_cast(OBJECT(bus), dc->bus_type) >> at the file in question suggests that you could try changing the parent class of >> TYPE_XENSYSBUS from TYPE_BUS to TYPE_SYSTEM_BUS to see if that helps? > > Hi, Mark. > > Thanks, but unfortunately changing xensysbus_info .parent does not > stop the assert. But it kinda pointed me in the right direction. > > xen-sysdev overrode the bus_type which was breaking sysbus_realize. > So drop that: > > --- a/hw/xen/xen-legacy-backend.c > +++ b/hw/xen/xen-legacy-backend.c > @@ -824,7 +825,7 @@ static void xen_sysdev_class_init(ObjectClass > *klass, void *data) > DeviceClass *dc = DEVICE_CLASS(klass); > > device_class_set_props(dc, xen_sysdev_properties); > - dc->bus_type = TYPE_XENSYSBUS; > + //dc->bus_type = TYPE_XENSYSBUS; > } Uff! Let me explain how things are supposed to work. Say we have FOO bus (QOM type TYPE_FOO_BUS), with FOO devices plugging into it (abstract QOM type TYPE_FOO_DEVICE). One of them is SOME_FOO (concrete QOM type TYPE_SOME_FOO). Code ties them together like this: static const TypeInfo pci_bus_info = { .name = TYPE_PCI_BUS, .parent = TYPE_BUS, ... }; static const TypeInfo foo_device_info = { .name = TYPE_FOO_DEVICE, .parent = TYPE_DEVICE, .abstract = true, .class_init = foo_device_class_init, ... }; static void foo_device_class_init(ObjectClass *oc, void *data) { DeviceClass *dc = DEVICE_CLASS(oc); dc->bus_type = TYPE_FOO_BUS; ... } static const TypeInfo some_foo_info = { .name = TYPE_SOME_FOO, .parent = TYPE_FOO_DEVICE, ... }; When you plug an instance of TYPE_SOME_FOO into a bus, the assertion checks that the bus is an instance of TYPE_FOO_BUS. Note that subtypes of TYPE_FOO_DEVICE do not mess with dc->bus_type! TYPE_XENSYSDEV does mess with it: static void xen_sysdev_class_init(ObjectClass *klass, void *data) { DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_props(dc, xen_sysdev_properties); dc->bus_type = TYPE_XENSYSBUS; } static const TypeInfo xensysdev_info = { .name = TYPE_XENSYSDEV, .parent = TYPE_SYS_BUS_DEVICE, .instance_size = sizeof(SysBusDevice), .class_init = xen_sysdev_class_init, }; On the one hand, xensysdev_info.parent claims TYPE_XENSYSDEV is a TYPE_SYS_BUS_DEVICE (and therefore should plug into a TYPE_SYSTEM_BUS). On the other hand, its dc->bus_type is a TYPE_XENSYSBUS, which is *not* a subtype of TYPE_SYSTEM_BUS: static const TypeInfo xensysbus_info = { .name = TYPE_XENSYSBUS, ---> .parent = TYPE_BUS, .class_init = xen_sysbus_class_init, .interfaces = (InterfaceInfo[]) { { TYPE_HOTPLUG_HANDLER }, { } } }; This is an inconsistent mess. Are TYPE_XENSYSDEV and TYPE_XENSYSBUS related to TYPE_SYS_BUS_DEVICE and TYPE_SYSTEM_BUS? If no, then xensysbus_info.parent should not be TYPE_SYS_BUS_DEVICE, and you must not pass instances of one kind to functions expecting the other kind. If yes, how? If the former are specializations of the latter, consider making the former subtypes of the latter. Both of them. Then a TYPE_XENSYSDEV device can plug into a TYPE_XENSYSBUS bus, but not into a TYPE_SYSTEM_BUS bus. A TYPE_SYS_BUS_DEVICE could still plug into TYPE_XENSYSBUS, because the latter is also an instance of TYPE_SYSTEM_BUS. Questions? > > static const TypeInfo xensysdev_info = { > > Then I had a different instance of the failed assert trying to attach > xen-console-0 to xen-sysbus. So I made this change: > --- a/hw/xen/xen-legacy-backend.c > +++ b/hw/xen/xen-legacy-backend.c > @@ -789,6 +789,7 @@ static void xendev_class_init(ObjectClass *klass, > void *data) > set_bit(DEVICE_CATEGORY_MISC, dc->categories); > /* xen-backend devices can be plugged/unplugged dynamically */ > dc->user_creatable = true; > + dc->bus_type = TYPE_XENSYSBUS; > } > > static const TypeInfo xendev_type_info = { > > Then it gets farther... until > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > Assertion `dev->realized' failed. > > dev->id is NULL. The failing device is: > (gdb) p *dev.parent_obj.class.type > $12 = {name = 0x555556207770 "cfi.pflash01", > > Is that right? > > I'm going to have to take a break from this now. > > Regards, > Jason From xen-devel-bounces@lists.xenproject.org Tue Jun 23 08:49:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 08:49:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnecB-0002au-Bm; Tue, 23 Jun 2020 08:49:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnec9-0002ap-Vs for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 08:49:10 +0000 X-Inumbo-ID: 66f20bee-b52e-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 66f20bee-b52e-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 08:49:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0E23AAE39; Tue, 23 Jun 2020 08:49:08 +0000 (UTC) Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <1880428355.11437172.1592845510789.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <287076b5-95d7-2ee9-dd1f-45d86546f978@suse.com> Date: Tue, 23 Jun 2020 10:49:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1880428355.11437172.1592845510789.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Xen-devel , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Jun Nakajima , Tamas K Lengyel , "Kang, Luwei" , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 19:05, Michał Leszczyński wrote: >>>>>> +struct xen_hvm_vmtrace_op { >>>>>> + /* IN variable */ >>>>>> + uint32_t version; /* HVMOP_VMTRACE_INTERFACE_VERSION */ >>>>>> + uint32_t cmd; >>>>>> +/* Enable/disable external vmtrace for given domain */ >>>>>> +#define HVMOP_vmtrace_ipt_enable 1 >>>>>> +#define HVMOP_vmtrace_ipt_disable 2 >>>>>> +#define HVMOP_vmtrace_ipt_get_offset 3 >>>>>> + domid_t domain; >>>>>> + uint32_t vcpu; >>>>>> + uint64_t size; >>>>>> + >>>>>> + /* OUT variable */ >>>>>> + uint64_t offset; >>>>> >>>>> If this is to be a tools-only interface, please use uint64_aligned_t. >>>>> >>>> >>>> This type is not defined within hvm_op.h header. What should I do about it? >>> >>> It gets defined by xen.h, so should be available here. Its >>> definitions live in a >>> >>> #if defined(__XEN__) || defined(__XEN_TOOLS__) >>> >>> section, which is what I did recommend to put your interface in >>> as well. Unless you want this to be exposed to the guest itself, >>> at which point further constraints would arise. >>> > > When I've putted it into #if defined(__XEN__) || defined(__XEN_TOOLS__) > then it complains about uint64_aligned_compat_t type missing. One the interface is tools-only, the requirement for compat checking isn't as strict anymore. As you can see from domctl and sysctl, there's no checking there, but to compensate we use uint64_aligned_t instead (arranging for struct layouts to match). > I also can't spot any single instance of uint64_aligned_t within > this file. That's unrelated. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 23 08:51:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 08:51:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jneeH-0003L7-Qp; Tue, 23 Jun 2020 08:51:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jneeH-0003L0-3g for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 08:51:21 +0000 X-Inumbo-ID: b4bbf2d6-b52e-11ea-bf2f-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b4bbf2d6-b52e-11ea-bf2f-12813bfff9fa; Tue, 23 Jun 2020 08:51:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 978CCAE39; Tue, 23 Jun 2020 08:51:18 +0000 (UTC) Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> <901046162.11470361.1592874264410.JavaMail.zimbra@cert.pl> From: Jan Beulich Message-ID: <32b7234b-dc64-a0ea-2c5c-448bcec44c34@suse.com> Date: Tue, 23 Jun 2020 10:51:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <901046162.11470361.1592874264410.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Tamas K Lengyel , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23.06.2020 03:04, Michał Leszczyński wrote: > ----- 22 cze 2020 o 18:16, Jan Beulich jbeulich@suse.com napisał(a): > >> On 22.06.2020 18:02, Michał Leszczyński wrote: >>> ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisał(a): >>>> On 22.06.2020 16:35, Michał Leszczyński wrote: >>>>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisał(a): >>>>>> Is any of what you do in this switch() actually legitimate without >>>>>> hvm_set_vmtrace_pt_size() having got called for the guest? From >>>>>> remarks elsewhere I imply you expect the param that you currently >>>>>> use to be set upon domain creation time, but at the very least the >>>>>> potentially big buffer should imo not get allocated up front, but >>>>>> only when tracing is to actually be enabled. >>>>> >>>>> Wait... so you want to allocate these buffers in runtime? >>>>> Previously we were talking that there is too much runtime logic >>>>> and these enable/disable hypercalls should be stripped to absolute >>>>> minimum. >>>> >>>> Basic arrangements can be made at domain creation time. I don't >>>> think though that it would be a good use of memory if you >>>> allocated perhaps many gigabytes of memory just for possibly >>>> wanting to enable tracing on a guest. >>>> >>> >>> From our previous conversations I thought that you want to have >>> as much logic moved to the domain creation as possible. >>> >>> Thus, a parameter "vmtrace_pt_size" was introduced. By default it's >>> zero (= disabled), if you set it to a non-zero value, then trace buffers >>> of given size will be allocated for the domain and you have possibility >>> to use ipt_enable/ipt_disable at any moment. >>> >>> This way the runtime logic is as thin as possible. I assume user knows >>> in advance whether he/she would want to use external monitoring with IPT >>> or not. >> >> Andrew - I think you requested movement to domain_create(). Could >> you clarify if indeed you mean to also allocate the big buffers >> this early? > > I would like to recall what Andrew wrote few days ago: > > ----- 16 cze 2020 o 22:16, Andrew Cooper andrew.cooper3@citrix.com wrote: >> Xen has traditionally opted for a "and turn this extra thing on >> dynamically" model, but this has caused no end of security issues and >> broken corner cases. >> >> You can see this still existing in the difference between >> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being >> required to chose the number of vcpus for the domain) and we're making >> good progress undoing this particular wart (before 4.13, it was >> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by >> issuing other hypercalls between these two). >> >> There is a lot of settings which should be immutable for the lifetime of >> the domain, and external monitoring looks like another one of these. >> Specifying it at createdomain time allows for far better runtime >> behaviour (you are no longer in a situation where the first time you try >> to turn tracing on, you end up with -ENOMEM because another VM booted in >> the meantime and used the remaining memory), and it makes for rather >> more simple code in Xen itself (at runtime, you can rely on it having >> been set up properly, because a failure setting up will have killed the >> domain already). >> >> ... >> >> ~Andrew > > according to this quote I've moved buffer allocation to the create_domain, > the updated version was already sent to the list as patch v3. I'd still like to see an explicit confirmation by him that this use of memory is indeed what he has intended. There are much smaller amounts of memory which we allocate on demand, just to avoid allocating some without then ever using it. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 23 09:26:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 09:26:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnfBk-0006G5-SP; Tue, 23 Jun 2020 09:25:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnfBj-0006G0-SO for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 09:25:55 +0000 X-Inumbo-ID: 894eaabd-b533-11ea-bf36-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 894eaabd-b533-11ea-bf36-12813bfff9fa; Tue, 23 Jun 2020 09:25:54 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: u1sJnI9rDczZMiqPmwFEjMxVNh5tPJfJ+5ibHNDCgnJeiVTP2J8cVCIqGwMLVE9u6/MK0NpQXM rxKkN0xirGZz+Z/MnqCBaQklLWJL3/ipzxJBirIPMay/tqD7qylXop+Myjag49isTTt+DGTnxN X3TugBHeayANL3pPlkifeO3x+4pYzu7IyR1sPq6eGQB6T9OugO2V85hjaGksp3oGYFffLR47yA xmgd5+eQKwWBqWLZjz3TkjFT8k3uK/HzKNoYhASsppgnFPhfgE8lvlN3xyYJgWoC6Bv/VObYvX /kg= X-SBRS: 2.7 X-MesageID: 20696889 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,270,1589256000"; d="scan'208";a="20696889" Date: Tue, 23 Jun 2020 11:25:43 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage Message-ID: <20200623092543.GQ735@Air-de-Roger> References: <20200618160403.35199-1-roger.pau@citrix.com> <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> <20200622093123.GI735@Air-de-Roger> <5ad66ef4-9406-f35a-5683-ac4608242dd7@suse.com> <20200622132410.GJ735@Air-de-Roger> <20200622145659.GL735@Air-de-Roger> <9848eebc-f904-cb2f-b5e1-499f5ce6994b@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9848eebc-f904-cb2f-b5e1-499f5ce6994b@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 05:30:11PM +0200, Jan Beulich wrote: > On 22.06.2020 16:56, Roger Pau Monné wrote: > > On Mon, Jun 22, 2020 at 03:51:24PM +0200, Jan Beulich wrote: > >> On 22.06.2020 15:24, Roger Pau Monné wrote: > >>> On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote: > >>>> On 22.06.2020 11:31, Roger Pau Monné wrote: > >>>>> On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote: > >>>>>> On 18.06.2020 18:04, Roger Pau Monne wrote: > >>>>>>> Commit e9aca9470ed86 introduced a regression when avoiding sending > >>>>>>> IPIs for certain flush operations. Xen page fault handler > >>>>>>> (spurious_page_fault) relies on blocking interrupts in order to > >>>>>>> prevent handling TLB flush IPIs and thus preventing other CPUs from > >>>>>>> removing page tables pages. Switching to assisted flushing avoided such > >>>>>>> IPIs, and thus can result in pages belonging to the page tables being > >>>>>>> removed (and possibly re-used) while __page_fault_type is being > >>>>>>> executed. > >>>>>>> > >>>>>>> Force some of the TLB flushes to use IPIs, thus avoiding the assisted > >>>>>>> TLB flush. Those selected flushes are the page type change (when > >>>>>>> switching from a page table type to a different one, ie: a page that > >>>>>>> has been removed as a page table) and page allocation. This sadly has > >>>>>>> a negative performance impact on the pvshim, as less assisted flushes > >>>>>>> can be used. > >>>>>>> > >>>>>>> Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush > >>>>>>> using an IPI (flush_tlb_mask_sync). Note that the flag is only > >>>>>>> meaningfully defined when the hypervisor supports PV mode, as > >>>>>>> otherwise translated domains are in charge of their page tables and > >>>>>>> won't share page tables with Xen, thus not influencing the result of > >>>>>>> page walks performed by the spurious fault handler. > >>>>>> > >>>>>> Is this true for shadow mode? If a page shadowing a guest one was > >>>>>> given back quickly enough to the allocator and then re-used, I think > >>>>>> the same situation could in principle arise. > >>>>> > >>>>> Hm, I think it's not applicable to HVM shadow mode at least, because > >>>>> CR3 is switched as part of vmentry/vmexit, and the page tables are not > >>>>> shared between Xen and the guest, so there's no way for a HVM shadow > >>>>> guest to modify the page-tables while Xen is walking them in > >>>>> spurious_page_fault (note spurious_page_fault is only called when the > >>>>> fault happens in non-guest context). > >>>> > >>>> I'm afraid I disagree, because of shadow's use of "linear page tables". > >>> > >>> You will have to bear with me, but I don't follow. > >>> > >>> Could you provide some pointers at how/where the shadow (I assume > >>> guest controlled) "linear page tables" are used while in Xen > >>> context? > >> > >> See config.h: > >> > >> /* Slot 258: linear page table (guest table). */ > >> #define LINEAR_PT_VIRT_START (PML4_ADDR(258)) > >> #define LINEAR_PT_VIRT_END (LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) > >> /* Slot 259: linear page table (shadow table). */ > >> #define SH_LINEAR_PT_VIRT_START (PML4_ADDR(259)) > >> #define SH_LINEAR_PT_VIRT_END (SH_LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) > >> > >> These linear page tables exist in the Xen page tables at basically > >> all times as long as a shadow guest's vCPU is in context. They're > >> there to limit the overhead of accessing guest page tables and > >> their shadows from inside Xen. > > > > Oh, I have to admit I know very little about all this, and I'm not > > able to find a description of how this is to be used. > > > > I think the shadow linear page tables should be per-pCPU, and hence > > they cannot be modified by the guest while a spurious page fault is > > being processed? (since the vCPU running on the pCPU is in Xen > > context). > > A guest would have for some linear address e.g. > > vCR3 -> G4 -> G3 -> G2 -> G1 > > visible to some random set of its CPUs (i.e. the same CR3 can be in > use by multiple vCPU-s). This will then have shadows like this: > > pCR3 -> S4 -> S3 -> S2 -> S1 > > The G4 page gets hooked up into LINEAR_PT (i.e. becomes an L3 page) > for all vCPU-s that have this very CR3 active. Same goes for S4 and > SH_LINEAR_PT respectively. Afaik shadows of guest page tables also > don't get created on a per-pCPU basis - a page table either has a > shadow, or it doesn't. > > Hence afaict page tables mapped through these facilities (and > reachable while in Xen) can very well be modified "behind our backs". Oh, I see. I'm still slightly puzzled because __hvm_copy seems to always map the guest page, and sh_gva_to_gfn also seems to just walk the guest page tables using the software implemented page table walker, and returns a gfn (not a mfn). I was expecting __hvm_copy to somehow make use of those shadow page tables when performing accesses to guest memory? Is shadow code using some of this internally then? Sorry I'm having trouble with all this, but I would like to fully understand. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 09:59:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 09:59:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnfiK-0000lL-Jh; Tue, 23 Jun 2020 09:59:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnfiH-0000kc-O2 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 09:59:34 +0000 X-Inumbo-ID: 397c5d9a-b538-11ea-8496-bc764e2007e4 Received: from forwardcorp1p.mail.yandex.net (unknown [2a02:6b8:0:1472:2741:0:8b6:217]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 397c5d9a-b538-11ea-8496-bc764e2007e4; Tue, 23 Jun 2020 09:59:28 +0000 (UTC) Received: from mxbackcorp1o.mail.yandex.net (mxbackcorp1o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::301]) by forwardcorp1p.mail.yandex.net (Yandex) with ESMTP id A8CB82E17B0; Tue, 23 Jun 2020 12:59:26 +0300 (MSK) Received: from localhost (localhost [::1]) by mxbackcorp1o.mail.yandex.net (mxbackcorp/Yandex) with ESMTP id GETtGuevOX-xHaiKNqk; Tue, 23 Jun 2020 12:59:26 +0300 Precedence: bulk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1592906366; bh=lq34GxPpe2c6C6ooW25hm9bZ9x+6Rh5Aa8JRJt82yb4=; h=Cc:Subject:Date:References:To:From:Message-Id; b=QTttHJxXJzB2mYT3Pe5fc4qZHJk70g2aurRDCoJkpwIKVMSgJtFLxE4OP1yoDxapX jGr++s7uTTPfWBKQUnA6NJM4gztQlonVdcXhnJBE+pSaWQJ5qxtFWm97VW+dc+uQTI SjPCejw0wPep6adeHAdhCzb3DEOm6oBahzLbH+TQ= Authentication-Results: mxbackcorp1o.mail.yandex.net; dkim=pass header.i=@yandex-team.ru X-Yandex-Sender-Uid: 1120000000161690 X-Yandex-Avir: 1 Received: from mxbackcorp1o.mail.yandex.net (localhost [::1]) by mxbackcorp1o.mail.yandex.net with LMTP id 1vFs6nmNIF-1upkCpTv for ; Tue, 23 Jun 2020 12:59:07 +0300 Received: by iva4-6d0ca09d92db.qloud-c.yandex.net with HTTP; Tue, 23 Jun 2020 12:59:07 +0300 From: Alexey Kirillov To: Markus Armbruster , Thomas Huth References: <20200304130656.16859-1-lekiravi@yandex-team.ru> <20200304130656.16859-2-lekiravi@yandex-team.ru> <87y2sff1qo.fsf@dusky.pond.sub.org> <1041781583412683@myt4-457577cc370d.qloud-c.yandex.net> Subject: Re: [PATCH v2 1/4] qapi: net: Add query-netdevs command MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 23 Jun 2020 12:59:17 +0300 Message-Id: <126621592905028@mail.yandex-team.ru> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Dmitry Fleytman , "Michael S. Tsirkin" , Jason Wang , "qemu-devel@nongnu.org" , Vincenzo Maffione , Gerd Hoffmann , "Edgar E. Iglesias" , Sven Schnelle , Rob Herring , Stefano Stabellini , Eric Blake , Paul Durrant , Joel Stanley , Anthony Perard , Samuel Thibault , Aleksandar Rikalo , Richard Henderson , Laurent Vivier , Jiri Pirko , Aleksandar Markovic , Stefan Weil , Alistair Francis , Beniamino Galvani , "qemu-arm@nongnu.org" , Peter Chubb , =?utf-8?B?Q8OpZHJpYyBMZSBHb2F0ZXI=?= , "xen-devel@lists.xenproject.org" , Giuseppe Lettieri , Luigi Rizzo , David Gibson , Andrew Jeffery , Michael Walle , "qemu-ppc@nongnu.org" , "yc-core@yandex-team.ru" , Paolo Bonzini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ping Sorry, I lost a point in discussion. As I wrote early, main reason for mix frontend and backend devices is for easy recreation of current state of network. As we have common structure for all netdevs (`struct NetClientState`), I think, that it'll be good idea to iterate using `net_clients`. There is no such trouble to split `query-netdevs` by two, for example, `query-front-netdevs` and `query-back-netdevs`, but in my opinion it'll break consistancy in getting links between netdevs. 05.03.2020, 17:26, "Alexey Kirillov" : > 05.03.2020, 15:03, "Markus Armbruster" : >>  Alexey Kirillov writes: >> >>>   Add a qmp command that provides information about currently attached >>>   network devices and their configuration. >> >>  Closes a gap in QMP; appreciated! >> >>>   Signed-off-by: Alexey Kirillov >> >>  [...] >>>   diff --git a/qapi/net.json b/qapi/net.json >>>   index 1cb9a7d782..4f329a1de0 100644 >>>   --- a/qapi/net.json >>>   +++ b/qapi/net.json >>>   @@ -750,3 +750,92 @@ >>>    ## >>>    { 'event': 'FAILOVER_NEGOTIATED', >>>      'data': {'device-id': 'str'} } >>>   + >>>   +## >>>   +# @NetdevInfo: >>>   +# >>>   +# Configuration of a network device. >>>   +# >>>   +# @id: Device identifier. >>>   +# >>>   +# @type: Specify the driver used for interpreting remaining arguments. >>>   +# >>>   +# @peer: Connected network device. >> >>  @peer is optional. I assume its present when the device is connected >>  (frontend to backend or vice versa). Correct? > > Yes, this field stores connected frontend/backend device @id. > >>>   +# >>>   +# @queues-count: Number of queues. >> >>  We use plain @queues elsewhere in the schema. > > It can conflict with fields inside Netdev*Options, isn't it? > >>>   +# >>>   +# @hub: hubid of hub, if connected to. >> >>  How @hub is related to @peer is not quite obvious to me. Can you give >>  an example where @hub is present? > > NetdevHubPortOptions has an option @hubid. @hub gives that id, if > netdev is connected to the hub via hubport. As example: > > HMP: > > hub 0 >  \ hub0port1: socket.0: index=0,type=socket, >  \ hub0port0: virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 > > QMP: > > [ >   { >     "peer": "hub0port0", >     "netdev": "hub0port0", >     "hub": 0, >     "model": "virtio-net-pci", >     "macaddr": "52:54:00:12:34:56", >     "type": "nic", >     "queues-count": 1, >     "id": "virtio-net-pci.0" >   }, >   { >     "peer": "hub0port1", >     "listen": "127.0.0.1:90", >     "hub": 0, >     "type": "socket", >     "queues-count": 1, >     "id": "socket.0" >   }, >   { >     "peer": "socket.0", >     "netdev": "socket.0", >     "hub": 0, >     "hubid": 0, >     "type": "hubport", >     "queues-count": 1, >     "id": "hub0port1" >   }, >   { >     "peer": "virtio-net-pci.0", >     "netdev": "virtio-net-pci.0", >     "hub": 0, >     "hubid": 0, >     "type": "hubport", >     "queues-count": 1, >     "id": "hub0port0" >   } > ] > >>>   +# >>>   +# @perm-mac: Original MAC address. >> >>  What does "perm-" mean? >> >>  It's optional. When exactly is it present? > > @perm-mac is the permanent (original) MAC address. It only used > for nic, because most of nic realizations can change MAC at > runtime and/or reset it to default (permanent) value. > >>>   +# >>>   +# Since: 5.0 >>>   +## >>>   +{ 'union': 'NetdevInfo', >>>   + 'base': { 'id': 'str', >>>   + 'type': 'NetClientDriver', >>>   + '*peer': 'str', >>>   + 'queues-count': 'int', >>>   + '*hub': 'int', >>>   + '*perm-mac': 'str' }, >>>   + 'discriminator': 'type', >>>   + 'data': { >>>   + 'nic': 'NetLegacyNicOptions', >>>   + 'user': 'NetdevUserOptions', >>>   + 'tap': 'NetdevTapOptions', >>>   + 'l2tpv3': 'NetdevL2TPv3Options', >>>   + 'socket': 'NetdevSocketOptions', >>>   + 'vde': 'NetdevVdeOptions', >>>   + 'bridge': 'NetdevBridgeOptions', >>>   + 'hubport': 'NetdevHubPortOptions', >>>   + 'netmap': 'NetdevNetmapOptions', >>>   + 'vhost-user': 'NetdevVhostUserOptions' } } >> >>  This is a copy of union 'Netdev' with a few additional common members >>  (@peer, @queues-count, @hub, @perm-mac). I can't see how to avoid the >>  duplication without adding nesting on the wire. >> >>>   + >>>   +## >>>   +# @query-netdevs: >>>   +# >>>   +# Get a list of @NetdevInfo for all virtual network devices. >>>   +# >>>   +# Returns: a list of @NetdevInfo describing each virtual network device. >>>   +# >>>   +# Since: 5.0 >>>   +# >>>   +# Example: >>>   +# >>>   +# -> { "execute": "query-netdevs" } >>>   +# <- { "return": [ >>>   +# { >>>   +# "peer": "netdev0", >>>   +# "netdev": "netdev0", >>>   +# "perm-mac": "52:54:00:12:34:56" >>>   +# "model": "virtio-net-pci", >>>   +# "macaddr": "52:54:00:12:34:56", >>>   +# "queues-count": 1, >>>   +# "type": "nic", >>>   +# "id": "net0" >>>   +# }, >>>   +# { >>>   +# "peer": "net0", >>>   +# "ipv6": true, >>>   +# "ipv4": true, >>>   +# "host": "10.0.2.2", >>>   +# "queues-count": 1, >>>   +# "ipv6-dns": "fec0::3", >>>   +# "ipv6-prefix": "fec0::", >>>   +# "net": "10.0.2.0/255.255.255.0", >>>   +# "ipv6-host": "fec0::2", >>>   +# "type": "user", >>>   +# "dns": "10.0.2.3", >>>   +# "hostfwd": [ >>>   +# { >>>   +# "str": "tcp::20004-:22" >>>   +# } >>>   +# ], >>>   +# "ipv6-prefixlen": 64, >>>   +# "id": "netdev0", >>>   +# "restrict": false >>>   +# } >>>   +# ] >>>   +# } >>>   +# >>>   +## >>>   +{ 'command': 'query-netdevs', 'returns': ['NetdevInfo'] } >> >>  Like HMP "info network" and -net, this mixes frontends ("type": "nic") >>  and backends. Unlike query-chardev and query-block. Hmm. >> >>  A long time ago, all we had was -net: "-net nic" for configuring >>  frontends, "-net none" for suppressing a default frontend + backend, and >>  "-net anything-else" for configuring backends. "info network" showed >>  the stuff set up with -net. >> >>  In v0.12, we got -device for configuring frontends, and -netdev for >>  backends. -netdev is like -net less "none", "nic", and the hub >>  weirdness. "info network" was extended to also show all this. >> >>  In v2.12, we got -nic, replacing -net nic. >> >>  Unless I'm missing something, -net is just for backward compatibility >>  now. >> >>  What's the use case for query-networks reporting frontends? > > In my vision, new QMP command is the replacement for old > HMP command. It must provide information about all > network devices, mainly for recreate similar net topology. > Currently, there are no differrence between fronted and > backend devices in context of my command, because > all of them use the same interface in NetClientState. > >> > > -- > Alexey Kirillov > Yandex.Cloud --  Alexey Kirillov Yandex.Cloud From xen-devel-bounces@lists.xenproject.org Tue Jun 23 10:14:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 10:14:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnfwy-0002YH-3H; Tue, 23 Jun 2020 10:14:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnfwx-0002YC-Cs for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 10:14:43 +0000 X-Inumbo-ID: 5a49e18a-b53a-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5a49e18a-b53a-11ea-b7bb-bc764e2007e4; Tue, 23 Jun 2020 10:14:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ja/tDz8VW8WvgOXt9Dqc8OWKc8RIce3+TtLLghG25os=; b=LM0ZAsRP8NEy/+xk2qmxUrDzR N762g7t9sklpC6r3Mqa2q6i1EBjMPihqdptxvaq4uAoelvnKZ91DGy1UpmhG0gM2fR8uOZIie4KHa mbj+rYFKMQh5vR754k+OV36dlu7T10MuGnnvyRCEtXAnvYg7CJwk/e+2NFarD5TRbEjSM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnfwv-0001LI-5R; Tue, 23 Jun 2020 10:14:41 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnfwu-00042C-Tt; Tue, 23 Jun 2020 10:14:40 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnfwu-0002ss-Sy; Tue, 23 Jun 2020 10:14:40 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151290: tolerable FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=fde76f895d0aa817a1207d844d793239c6639bc6 X-Osstest-Versions-That: xen=fde76f895d0aa817a1207d844d793239c6639bc6 From: osstest service owner Date: Tue, 23 Jun 2020 10:14:40 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151290 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151290/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail like 151245 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151273 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151273 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151273 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151273 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151273 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151273 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151273 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151273 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151273 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151273 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen fde76f895d0aa817a1207d844d793239c6639bc6 baseline version: xen fde76f895d0aa817a1207d844d793239c6639bc6 Last test of basis 151290 2020-06-22 09:55:25 Z 1 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 11:46:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 11:46:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhN2-0002Bo-0p; Tue, 23 Jun 2020 11:45:44 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhN0-0002Bj-Po for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 11:45:42 +0000 X-Inumbo-ID: 108adb0a-b547-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 108adb0a-b547-11ea-b7bb-bc764e2007e4; Tue, 23 Jun 2020 11:45:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 7A63AAF9C; Tue, 23 Jun 2020 11:45:40 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/tlb: fix assisted flush usage To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200618160403.35199-1-roger.pau@citrix.com> <0b6c900f-e2a6-c9b1-0e57-68c6898150a9@suse.com> <20200622093123.GI735@Air-de-Roger> <5ad66ef4-9406-f35a-5683-ac4608242dd7@suse.com> <20200622132410.GJ735@Air-de-Roger> <20200622145659.GL735@Air-de-Roger> <9848eebc-f904-cb2f-b5e1-499f5ce6994b@suse.com> <20200623092543.GQ735@Air-de-Roger> From: Jan Beulich Message-ID: <2e994ef6-eeb1-a3d7-2912-b4ab18b64edb@suse.com> Date: Tue, 23 Jun 2020 13:45:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623092543.GQ735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23.06.2020 11:25, Roger Pau Monné wrote: > On Mon, Jun 22, 2020 at 05:30:11PM +0200, Jan Beulich wrote: >> On 22.06.2020 16:56, Roger Pau Monné wrote: >>> On Mon, Jun 22, 2020 at 03:51:24PM +0200, Jan Beulich wrote: >>>> On 22.06.2020 15:24, Roger Pau Monné wrote: >>>>> On Mon, Jun 22, 2020 at 01:07:10PM +0200, Jan Beulich wrote: >>>>>> On 22.06.2020 11:31, Roger Pau Monné wrote: >>>>>>> On Fri, Jun 19, 2020 at 04:06:55PM +0200, Jan Beulich wrote: >>>>>>>> On 18.06.2020 18:04, Roger Pau Monne wrote: >>>>>>>>> Commit e9aca9470ed86 introduced a regression when avoiding sending >>>>>>>>> IPIs for certain flush operations. Xen page fault handler >>>>>>>>> (spurious_page_fault) relies on blocking interrupts in order to >>>>>>>>> prevent handling TLB flush IPIs and thus preventing other CPUs from >>>>>>>>> removing page tables pages. Switching to assisted flushing avoided such >>>>>>>>> IPIs, and thus can result in pages belonging to the page tables being >>>>>>>>> removed (and possibly re-used) while __page_fault_type is being >>>>>>>>> executed. >>>>>>>>> >>>>>>>>> Force some of the TLB flushes to use IPIs, thus avoiding the assisted >>>>>>>>> TLB flush. Those selected flushes are the page type change (when >>>>>>>>> switching from a page table type to a different one, ie: a page that >>>>>>>>> has been removed as a page table) and page allocation. This sadly has >>>>>>>>> a negative performance impact on the pvshim, as less assisted flushes >>>>>>>>> can be used. >>>>>>>>> >>>>>>>>> Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush >>>>>>>>> using an IPI (flush_tlb_mask_sync). Note that the flag is only >>>>>>>>> meaningfully defined when the hypervisor supports PV mode, as >>>>>>>>> otherwise translated domains are in charge of their page tables and >>>>>>>>> won't share page tables with Xen, thus not influencing the result of >>>>>>>>> page walks performed by the spurious fault handler. >>>>>>>> >>>>>>>> Is this true for shadow mode? If a page shadowing a guest one was >>>>>>>> given back quickly enough to the allocator and then re-used, I think >>>>>>>> the same situation could in principle arise. >>>>>>> >>>>>>> Hm, I think it's not applicable to HVM shadow mode at least, because >>>>>>> CR3 is switched as part of vmentry/vmexit, and the page tables are not >>>>>>> shared between Xen and the guest, so there's no way for a HVM shadow >>>>>>> guest to modify the page-tables while Xen is walking them in >>>>>>> spurious_page_fault (note spurious_page_fault is only called when the >>>>>>> fault happens in non-guest context). >>>>>> >>>>>> I'm afraid I disagree, because of shadow's use of "linear page tables". >>>>> >>>>> You will have to bear with me, but I don't follow. >>>>> >>>>> Could you provide some pointers at how/where the shadow (I assume >>>>> guest controlled) "linear page tables" are used while in Xen >>>>> context? >>>> >>>> See config.h: >>>> >>>> /* Slot 258: linear page table (guest table). */ >>>> #define LINEAR_PT_VIRT_START (PML4_ADDR(258)) >>>> #define LINEAR_PT_VIRT_END (LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) >>>> /* Slot 259: linear page table (shadow table). */ >>>> #define SH_LINEAR_PT_VIRT_START (PML4_ADDR(259)) >>>> #define SH_LINEAR_PT_VIRT_END (SH_LINEAR_PT_VIRT_START + PML4_ENTRY_BYTES) >>>> >>>> These linear page tables exist in the Xen page tables at basically >>>> all times as long as a shadow guest's vCPU is in context. They're >>>> there to limit the overhead of accessing guest page tables and >>>> their shadows from inside Xen. >>> >>> Oh, I have to admit I know very little about all this, and I'm not >>> able to find a description of how this is to be used. >>> >>> I think the shadow linear page tables should be per-pCPU, and hence >>> they cannot be modified by the guest while a spurious page fault is >>> being processed? (since the vCPU running on the pCPU is in Xen >>> context). >> >> A guest would have for some linear address e.g. >> >> vCR3 -> G4 -> G3 -> G2 -> G1 >> >> visible to some random set of its CPUs (i.e. the same CR3 can be in >> use by multiple vCPU-s). This will then have shadows like this: >> >> pCR3 -> S4 -> S3 -> S2 -> S1 >> >> The G4 page gets hooked up into LINEAR_PT (i.e. becomes an L3 page) >> for all vCPU-s that have this very CR3 active. Same goes for S4 and >> SH_LINEAR_PT respectively. Afaik shadows of guest page tables also >> don't get created on a per-pCPU basis - a page table either has a >> shadow, or it doesn't. >> >> Hence afaict page tables mapped through these facilities (and >> reachable while in Xen) can very well be modified "behind our backs". > > Oh, I see. I'm still slightly puzzled because __hvm_copy seems to > always map the guest page, and sh_gva_to_gfn also seems to just walk > the guest page tables using the software implemented page table > walker, and returns a gfn (not a mfn). I was expecting __hvm_copy to > somehow make use of those shadow page tables when performing accesses > to guest memory? No, that's using the guest page table walker plus the p2m table instead. > Is shadow code using some of this internally then? Yes. Just grep the shadow code for linear_l[1234]_table to find the uses. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 23 11:46:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 11:46:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhO6-0002Kf-Aq; Tue, 23 Jun 2020 11:46:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhO4-0002KA-O6 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 11:46:48 +0000 X-Inumbo-ID: 357e1652-b547-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x42d.google.com (unknown [2a00:1450:4864:20::42d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 357e1652-b547-11ea-bca7-bc764e2007e4; Tue, 23 Jun 2020 11:46:43 +0000 (UTC) Received: by mail-wr1-x42d.google.com with SMTP id s10so231442wrw.12 for ; Tue, 23 Jun 2020 04:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=nsQo9i+/CJZ1DjKvgOB2w05FjU4Aq8s2SwHPXUXQPgg=; b=MsCHTOexjRjW5Ra2id6IrAIs6x9apeOs3pvM6wBIOHmz9Bgvyb8N1EPeY/+7fpJEXd VgUKeiIytfAdKBBWU5C4gcQM8aSsV/8eSah2xD9oH8APwTceIVf5ivgk/gU7jvTn74u3 6YLi7ONi+eYQqTneyarVhpL+pWjT50sCSN7gaurewdm/2rEzLVKt+kgAk7rBnGG5imW2 703G9g5mp5bvUzLgSQxUElSefDOkrwYmMFapCRIKwFK6275ZUIQc6KACxJRODgQ3Jsgi /gOAEmvB8xiOa+DMAvvHDQTfMnua06XyOrlJ1tpgG6v6161+dDDIcxPIX2q2IBziY7rn 43vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=nsQo9i+/CJZ1DjKvgOB2w05FjU4Aq8s2SwHPXUXQPgg=; b=swS8vrCJBEeHp1digdDBsMW0/aF/c6IdcSkDYhkHF7DKE03rKF01KNa06EFmeaUFI1 J4sP0YyWUDPOfBje1hiM1JMBny4GXNCQFPc3UchSJO7YVibHGnX1SbFvmjAoo38HMvEf 7qmyPrg/cJqCt/t+NtTBbQYJaE8mJsiAiQM4gU+3KEc/5Jrlkpnyc738oZav8slqmSkl asa1k7KD2kMAiDVLAD0SN+B1Fq7alKqp0KIcY1q1Ktmz3VhhghHUGrCGjxU2j7XlykFg 7hHVgtH0wLkzYnmS2tvqwJi3FDdeQ6uagUhC+AsZmYGa7rTDoWa7sU8rzkySIGxFJln6 wpHQ== X-Gm-Message-State: AOAM533vAt07221bt9omDbocQ/dCW74wWXU7yUJpmZW2mkTIT9eLpvSy d7mVtSpH2lEsDtxhvCA7aY4= X-Google-Smtp-Source: ABdhPJzTJS7wzmG6kPQJ4+HLB04YWNFkLOXYkMd9lBnpM99UXIyjh8ly/AKBuLK5LYE1wp27n2CoFw== X-Received: by 2002:adf:d1a9:: with SMTP id w9mr22003597wrc.344.1592912802849; Tue, 23 Jun 2020 04:46:42 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id z9sm3373507wmi.7.2020.06.23.04.46.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 04:46:42 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Markus Armbruster'" , "'Jason Andryuk'" References: <87k0zykwdl.fsf@dusky.pond.sub.org> In-Reply-To: <87k0zykwdl.fsf@dusky.pond.sub.org> Subject: RE: sysbus failed assert for xen_sysdev Date: Tue, 23 Jun 2020 12:46:41 +0100 Message-ID: <000001d64953$f67a1f00$e36e5d00$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIJfv1jP4fCJU6d0eNUL65zTb1lhAKJjZPCAZLY/IEByWeHd6hQeooA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Anthony PERARD' , 'xen-devel' , 'Mark Cave-Ayland' , 'QEMU' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Markus Armbruster > Sent: 23 June 2020 09:41 > To: Jason Andryuk > Cc: Mark Cave-Ayland ; Anthony PERARD ; xen- > devel ; Paul Durrant ; QEMU > Subject: Re: sysbus failed assert for xen_sysdev > > Jason Andryuk writes: > > > On Mon, Jun 22, 2020 at 5:17 PM Mark Cave-Ayland > > wrote: > >> > >> On 22/06/2020 21:33, Jason Andryuk wrote: > >> > >> > Hi, > >> > > >> > Running qemu devel for a Xen VM is failing an assert after the recent > >> > "qdev: Rework how we plug into the parent bus" sysbus changes. > >> > > >> > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > >> > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > >> > failed. > >> > > >> > dc->bus_type is "xen-sysbus" and it's the > >> > `object_dynamic_cast(OBJECT(bus), dc->bus_type)` portion that fails > >> > the assert. bus seems to be "main-system-bus", I think: > >> > (gdb) p *bus > >> > $3 = {obj = {class = 0x55555636d780, free = 0x7ffff7c40db0 , > >> > properties = 0x5555563f7180, ref = 3, parent = 0x5555563fe980}, parent > >> > = 0x0, name = 0x5555563fec60 "main-system-bus", ... > >> > > >> > The call comes from hw/xen/xen-legacy-backend.c:706 > >> > sysbus_realize_and_unref(SYS_BUS_DEVICE(xen_sysdev), &error_fatal); > >> > > >> > Any pointers on what needs to be fixed? > >> > >> Hi Jason, > >> > >> My understanding is that the assert() is telling you that you're plugging a > >> TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. > >> TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. A quick look > > Correct. Let's review the assertion: > > assert(dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)); > > Context: we're supposted to plug @dev into @bus, and @dc is @dev's > DeviceClass. > > The assertion checks that > > 1. @dev plugs into a bus: dc->bus_type > > 2. @bus is an instance of the type of bus @dev plugs into: > object_dynamic_cast(OBJECT(bus), dc->bus_type) > > >> at the file in question suggests that you could try changing the parent class of > >> TYPE_XENSYSBUS from TYPE_BUS to TYPE_SYSTEM_BUS to see if that helps? > > > > Hi, Mark. > > > > Thanks, but unfortunately changing xensysbus_info .parent does not > > stop the assert. But it kinda pointed me in the right direction. > > > > xen-sysdev overrode the bus_type which was breaking sysbus_realize. > > So drop that: > > > > --- a/hw/xen/xen-legacy-backend.c > > +++ b/hw/xen/xen-legacy-backend.c > > @@ -824,7 +825,7 @@ static void xen_sysdev_class_init(ObjectClass > > *klass, void *data) > > DeviceClass *dc = DEVICE_CLASS(klass); > > > > device_class_set_props(dc, xen_sysdev_properties); > > - dc->bus_type = TYPE_XENSYSBUS; > > + //dc->bus_type = TYPE_XENSYSBUS; > > } > > Uff! > > Let me explain how things are supposed to work. > > Say we have FOO bus (QOM type TYPE_FOO_BUS), with FOO devices plugging > into it (abstract QOM type TYPE_FOO_DEVICE). One of them is SOME_FOO > (concrete QOM type TYPE_SOME_FOO). Code ties them together like this: > > static const TypeInfo pci_bus_info = { > .name = TYPE_PCI_BUS, > .parent = TYPE_BUS, > ... > }; > > static const TypeInfo foo_device_info = { > .name = TYPE_FOO_DEVICE, > .parent = TYPE_DEVICE, > .abstract = true, > .class_init = foo_device_class_init, > ... > }; > > static void foo_device_class_init(ObjectClass *oc, void *data) > { > DeviceClass *dc = DEVICE_CLASS(oc); > > dc->bus_type = TYPE_FOO_BUS; > ... > } > > static const TypeInfo some_foo_info = { > .name = TYPE_SOME_FOO, > .parent = TYPE_FOO_DEVICE, > ... > }; > > When you plug an instance of TYPE_SOME_FOO into a bus, the assertion > checks that the bus is an instance of TYPE_FOO_BUS. > > Note that subtypes of TYPE_FOO_DEVICE do not mess with dc->bus_type! > > TYPE_XENSYSDEV does mess with it: > > static void xen_sysdev_class_init(ObjectClass *klass, void *data) > { > DeviceClass *dc = DEVICE_CLASS(klass); > > device_class_set_props(dc, xen_sysdev_properties); > dc->bus_type = TYPE_XENSYSBUS; > } > > static const TypeInfo xensysdev_info = { > .name = TYPE_XENSYSDEV, > .parent = TYPE_SYS_BUS_DEVICE, > .instance_size = sizeof(SysBusDevice), > .class_init = xen_sysdev_class_init, > }; > > On the one hand, xensysdev_info.parent claims TYPE_XENSYSDEV is a > TYPE_SYS_BUS_DEVICE (and therefore should plug into a TYPE_SYSTEM_BUS). > On the other hand, its dc->bus_type is a TYPE_XENSYSBUS, which is *not* > a subtype of TYPE_SYSTEM_BUS: > > static const TypeInfo xensysbus_info = { > .name = TYPE_XENSYSBUS, > ---> .parent = TYPE_BUS, > .class_init = xen_sysbus_class_init, > .interfaces = (InterfaceInfo[]) { > { TYPE_HOTPLUG_HANDLER }, > { } > } > }; > > This is an inconsistent mess. > > Are TYPE_XENSYSDEV and TYPE_XENSYSBUS related to TYPE_SYS_BUS_DEVICE and > TYPE_SYSTEM_BUS? > > If no, then xensysbus_info.parent should not be TYPE_SYS_BUS_DEVICE, and > you must not pass instances of one kind to functions expecting the other > kind. > > If yes, how? If the former are specializations of the latter, consider > making the former subtypes of the latter. Both of them. Then a > TYPE_XENSYSDEV device can plug into a TYPE_XENSYSBUS bus, but not into a > TYPE_SYSTEM_BUS bus. > > A TYPE_SYS_BUS_DEVICE could still plug into TYPE_XENSYSBUS, because the > latter is also an instance of TYPE_SYSTEM_BUS. > > Questions? > > > > > static const TypeInfo xensysdev_info = { > > > > Then I had a different instance of the failed assert trying to attach > > xen-console-0 to xen-sysbus. So I made this change: > > --- a/hw/xen/xen-legacy-backend.c > > +++ b/hw/xen/xen-legacy-backend.c > > @@ -789,6 +789,7 @@ static void xendev_class_init(ObjectClass *klass, > > void *data) > > set_bit(DEVICE_CATEGORY_MISC, dc->categories); > > /* xen-backend devices can be plugged/unplugged dynamically */ > > dc->user_creatable = true; > > + dc->bus_type = TYPE_XENSYSBUS; > > } > > > > static const TypeInfo xendev_type_info = { > > > > Then it gets farther... until > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > > Assertion `dev->realized' failed. > > > > dev->id is NULL. The failing device is: > > (gdb) p *dev.parent_obj.class.type > > $12 = {name = 0x555556207770 "cfi.pflash01", > > Having commented out the call to xen_be_init() entirely (and xen_bus_init() for good measure) I also get this assertion failure, so I don't think is related. Paul From xen-devel-bounces@lists.xenproject.org Tue Jun 23 11:47:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 11:47:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhOX-0002Oe-NR; Tue, 23 Jun 2020 11:47:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhOW-0002OM-48 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 11:47:16 +0000 X-Inumbo-ID: 487d17bc-b547-11ea-bb8b-bc764e2007e4 Received: from mail-pg1-x541.google.com (unknown [2607:f8b0:4864:20::541]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 487d17bc-b547-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 11:47:15 +0000 (UTC) Received: by mail-pg1-x541.google.com with SMTP id e9so9744503pgo.9 for ; Tue, 23 Jun 2020 04:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=pDMz4GEEd1HrNqab3SFEgh4HTzshHqZlUT8h2DVo/0o=; b=O0f174T9zxECMIrMcBnJlVgKJZ6AF1eadIxgibscZl51LZvB8RJvrqMkRvOifJ1CI8 /NW27eFVBws4khf4Q2qK+/MggUcJwyAOfD1inExGIsaCdqPgaVcQI/lpgDRKhxW6DZ4c vHpAdYOFKt4Tw7nffVPHnQteL/omtnCI9D+PU6xJ/l+qW4gpxQVfVzLKgBp51y/iJeLb BhsNyPZiZimDHSuuF9JYkugBfFBkWTtmpsgF/s45n0Xfpkd5lBZaZNND2x/AZ06mD0dl fYUJBBGM0VrP/I2mSStcI2uddjS2oYMSuuaGhwQ3LJS5m1Stcz2Fnc79koTI+ITuoj4q Wxow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=pDMz4GEEd1HrNqab3SFEgh4HTzshHqZlUT8h2DVo/0o=; b=cj7tJ4skwdXFygLBfTvfkTPsZhYKFBCcH/JwEDrco61WKzz4GBHYcbE2Zk7MQ6v8Pt 5+PfwV6MftWI7qr71OPqzP56Ri9+29vfuI4eRNLhuL5f7naEypoADWY0xG7yBgizMINl 7sbka+GcUwjdA/wnFN+3DDeoelY6+zgjObEPnkMZ1Kv7mCokV37ExOyFZzlAKCWyTGeK cq4kYuqIPJAxFrpPLeKbQ0rIMQQgB+1r+ljOH2OAKMR8gTYoNCuQXAneTfiZOaRxvoFj O6o6cVyefBRxmj8YMHzCEgPwxUPOOFzUICVDhq1V777IrCFPn0GHLglSLAXfcdqPj8u3 OMYQ== X-Gm-Message-State: AOAM5317kgP2REZN+LiRAwrU4nCbquT7xewX2UF8zSyBslX4i1HFQ8Yx eWS2vCzT1A0Upd3Hn7/tYAM= X-Google-Smtp-Source: ABdhPJyoqH2qE0gyMJuzujXPkfwbJMIuJEyJhbRiulWkylIrNAE8lewKA/I7Fqiq7o7Uu7FIu8YohA== X-Received: by 2002:a63:6643:: with SMTP id a64mr14118116pgc.246.1592912834633; Tue, 23 Jun 2020 04:47:14 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC.domain.name ([122.179.62.127]) by smtp.gmail.com with ESMTPSA id w203sm6828258pfc.128.2020.06.23.04.47.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 04:47:13 -0700 (PDT) From: Souptick Joarder To: jgross@suse.com, boris.ostrovsky@oracle.com, sstabellini@kernel.org Subject: [RFC PATCH v2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() Date: Tue, 23 Jun 2020 17:25:28 +0530 Message-Id: <1592913328-15486-1-git-send-email-jrdr.linux@gmail.com> X-Mailer: git-send-email 1.9.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, John Hubbard , Souptick Joarder Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In 2019, we introduced pin_user_pages*() and now we are converting get_user_pages*() to the new API as appropriate. [1] & [2] could be referred for more information. This is case 5 as per document [1]. As discussed, pages need to be marked as dirty before unpinned it. Previously, if lock_pages() end up partially mapping pages, it used to return -ERRNO due to which unlock_pages() have to go through each pages[i] till *nr_pages* to validate them. This can be avoided by passing correct number partially mapped pages & -ERRNO separately while returning from lock_pages() due to error. With this fix unlock_pages() doesn't need to validate pages[i] till *nr_pages* for error scenario. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: Souptick Joarder Cc: John Hubbard Cc: Boris Ostrovsky --- drivers/xen/privcmd.c | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index a250d11..eea90cd 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -580,25 +580,30 @@ static long privcmd_ioctl_mmap_batch( static int lock_pages( struct privcmd_dm_op_buf kbufs[], unsigned int num, - struct page *pages[], unsigned int nr_pages) + struct page *pages[], unsigned int nr_pages, int *errno) { unsigned int i; + int pinned = 0, rc = 0; for (i = 0; i < num; i++) { unsigned int requested; - int pinned; + rc += pinned; requested = DIV_ROUND_UP( offset_in_page(kbufs[i].uptr) + kbufs[i].size, PAGE_SIZE); - if (requested > nr_pages) - return -ENOSPC; + if (requested > nr_pages) { + *errno = -ENOSPC; + return rc; + } - pinned = get_user_pages_fast( + pinned = pin_user_pages_fast( (unsigned long) kbufs[i].uptr, requested, FOLL_WRITE, pages); - if (pinned < 0) - return pinned; + if (pinned < 0) { + *errno = pinned; + return rc; + } nr_pages -= pinned; pages += pinned; @@ -613,11 +618,7 @@ static void unlock_pages(struct page *pages[], unsigned int nr_pages) if (!pages) return; - - for (i = 0; i < nr_pages; i++) { - if (pages[i]) - put_page(pages[i]); - } + unpin_user_pages_dirty_lock(pages, nr_pages, 1); } static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) @@ -630,6 +631,7 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) struct xen_dm_op_buf *xbufs = NULL; unsigned int i; long rc; + int errno = 0; if (copy_from_user(&kdata, udata, sizeof(kdata))) return -EFAULT; @@ -683,9 +685,12 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) goto out; } - rc = lock_pages(kbufs, kdata.num, pages, nr_pages); - if (rc) + rc = lock_pages(kbufs, kdata.num, pages, nr_pages, &errno); + if (errno < 0) { + nr_pages = rc; + rc = errno; goto out; + } for (i = 0; i < kdata.num; i++) { set_xen_guest_handle(xbufs[i].h, kbufs[i].uptr); -- 1.9.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 23 11:50:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 11:50:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhRC-0002gB-5U; Tue, 23 Jun 2020 11:50:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhRA-0002bp-Ux for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 11:50:00 +0000 X-Inumbo-ID: a9f5b1b6-b547-11ea-b7bb-bc764e2007e4 Received: from mail-pj1-x1041.google.com (unknown [2607:f8b0:4864:20::1041]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a9f5b1b6-b547-11ea-b7bb-bc764e2007e4; Tue, 23 Jun 2020 11:49:59 +0000 (UTC) Received: by mail-pj1-x1041.google.com with SMTP id d6so1446806pjs.3 for ; Tue, 23 Jun 2020 04:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=70/IVEhJ02HvpdsdNd9PlWVOivEwQQMsYQTKyuJVw5w=; b=MppwvfZJn8ecf5EIZhuRbEQ8l3NLLdTBNC06snahwn8RnuLn37zTW3Xh1tgQBJu5Vt zZyxaozNnvbmbkJvjzRixuvhZtfr9BzypqeE7l/aJ6+mEpn+h5IJNmHFc6l0ee/FvwOI Bl7TfpCpdRUnxhNvJmSg5FqkwoCFnVEYKOMeoe4LE1sLzSHyQqXCwHUCpL38FDtoPAOh E0mzT9Toou2nx99Ka5OdaBLolD3f2E9ypbp04kqP1nUuCWYyUKkhv/38fkxmjhwbUb0b pvjqBWy8ekO5F4RnkOQutCDq2i7behQUQ7VGXx3Sx0N6fwI8lTypVzf2fMihGCmML3cx 47wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=70/IVEhJ02HvpdsdNd9PlWVOivEwQQMsYQTKyuJVw5w=; b=J+OHUp7IyDZbKqYyd7/zV0K6b0Eb5ghxUys34xYxZ3Mw6rfaKQKxBDwzxr2OJrfVXO xH/5pg9tPV7fOTRuXc3p4I2p/a9/W4agGVdJ8K3dZFnIfu98EgjjVEesPKwFXlMHmsM+ IBOQ/giSNSKL9bWoQWtFofB9ZdTUic9qD5wjmIXmTDA1Nu/9JExjG2hyRQB9HI+AHdi/ dlLoS/czqykqI9XkCM0rmU1YBogmz23/iYEu8Ed2TH5S5W3JqRCF3IpxqZYhAgqsdyu3 x2RBk4p2MqzbM4Lyw4AaffZgM3Yw4qrQaGnLmxVhWSi340EvjU9tiWCSWPuzRVUU78R+ ajmg== X-Gm-Message-State: AOAM530ZGceG59eUPVe2DZ90JQmHn8BxK7kDq/AGm/UOfZ+BTujuwwc7 dQ4E2OBGFY/1MWiAeO+KjDA= X-Google-Smtp-Source: ABdhPJyStVCImaOd+pzTqmM89EzcHfoa9xSYUzHKMG+nb3a6hRmdLRowoxq6o0VzoGGzLOSJsnRG7w== X-Received: by 2002:a17:902:8b8a:: with SMTP id ay10mr10745807plb.235.1592912997980; Tue, 23 Jun 2020 04:49:57 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC.domain.name ([122.179.62.127]) by smtp.gmail.com with ESMTPSA id cm13sm2290720pjb.5.2020.06.23.04.49.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 04:49:57 -0700 (PDT) From: Souptick Joarder To: jgross@suse.com, boris.ostrovsky@oracle.com, sstabellini@kernel.org Subject: [RFC PATCH v2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() Date: Tue, 23 Jun 2020 17:28:19 +0530 Message-Id: <1592913499-15558-1-git-send-email-jrdr.linux@gmail.com> X-Mailer: git-send-email 1.9.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, John Hubbard , Souptick Joarder Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In 2019, we introduced pin_user_pages*() and now we are converting get_user_pages*() to the new API as appropriate. [1] & [2] could be referred for more information. This is case 5 as per document [1]. As discussed, pages need to be marked as dirty before unpinned it. Previously, if lock_pages() end up partially mapping pages, it used to return -ERRNO due to which unlock_pages() have to go through each pages[i] till *nr_pages* to validate them. This can be avoided by passing correct number partially mapped pages & -ERRNO separately while returning from lock_pages() due to error. With this fix unlock_pages() doesn't need to validate pages[i] till *nr_pages* for error scenario. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: Souptick Joarder Cc: John Hubbard Cc: Boris Ostrovsky --- drivers/xen/privcmd.c | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index a250d11..013d23b 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -580,25 +580,30 @@ static long privcmd_ioctl_mmap_batch( static int lock_pages( struct privcmd_dm_op_buf kbufs[], unsigned int num, - struct page *pages[], unsigned int nr_pages) + struct page *pages[], unsigned int nr_pages, int *errno) { unsigned int i; + int pinned = 0, rc = 0; for (i = 0; i < num; i++) { unsigned int requested; - int pinned; + rc += pinned; requested = DIV_ROUND_UP( offset_in_page(kbufs[i].uptr) + kbufs[i].size, PAGE_SIZE); - if (requested > nr_pages) - return -ENOSPC; + if (requested > nr_pages) { + *errno = -ENOSPC; + return rc; + } - pinned = get_user_pages_fast( + pinned = pin_user_pages_fast( (unsigned long) kbufs[i].uptr, requested, FOLL_WRITE, pages); - if (pinned < 0) - return pinned; + if (pinned < 0) { + *errno = pinned; + return rc; + } nr_pages -= pinned; pages += pinned; @@ -609,15 +614,10 @@ static int lock_pages( static void unlock_pages(struct page *pages[], unsigned int nr_pages) { - unsigned int i; - if (!pages) return; - for (i = 0; i < nr_pages; i++) { - if (pages[i]) - put_page(pages[i]); - } + unpin_user_pages_dirty_lock(pages, nr_pages, 1); } static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) @@ -630,6 +630,7 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) struct xen_dm_op_buf *xbufs = NULL; unsigned int i; long rc; + int errno = 0; if (copy_from_user(&kdata, udata, sizeof(kdata))) return -EFAULT; @@ -683,9 +684,12 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) goto out; } - rc = lock_pages(kbufs, kdata.num, pages, nr_pages); - if (rc) + rc = lock_pages(kbufs, kdata.num, pages, nr_pages, &errno); + if (errno < 0) { + nr_pages = rc; + rc = errno; goto out; + } for (i = 0; i < kdata.num; i++) { set_xen_guest_handle(xbufs[i].h, kbufs[i].uptr); -- 1.9.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 23 11:54:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 11:54:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhVm-0003Q5-Ov; Tue, 23 Jun 2020 11:54:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnhVl-0003Q0-MN for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 11:54:45 +0000 X-Inumbo-ID: 54144e50-b548-11ea-b7bb-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 54144e50-b548-11ea-b7bb-bc764e2007e4; Tue, 23 Jun 2020 11:54:44 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: XLlSU3pQl/MYc3+tBCe+j5CH+37hOvj+Tqpn0x2eRM8qQ0rwGEFzaTcTLB2PJYWqIygcJMa4mW y46DI6dvgeGSbdwqsyBVkDADzqDAR9ZqruxlE9MTuGKhD6zVQzY5MLiXWpF4slRHFRp62p+0/u C2WnuFXbn9Pcydrl9QSQ/+2eCKazZLFdujFzFa3n3eynK8ggPBiNOeYMhsChGgaXHZ6X9A3jA6 a3LWoeiwa4g+CIFuUid2SXLvVjAr5oVqj0rJNm6SPsT863Y+f8DAKIuislEkl3YjqLCxJ4bU59 VhA= X-SBRS: 2.7 X-MesageID: 20927654 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,271,1589256000"; d="scan'208";a="20927654" Subject: Re: [PATCH v3 4/7] x86/vmx: add do_vmtrace_op To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> <97440747.11443782.1592849498089.JavaMail.zimbra@cert.pl> From: Andrew Cooper Message-ID: <250cd39e-aa51-5397-93f9-b863e4f51269@citrix.com> Date: Tue, 23 Jun 2020 12:54:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <97440747.11443782.1592849498089.JavaMail.zimbra@cert.pl> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Tamas K Lengyel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22/06/2020 19:11, Michał Leszczyński wrote: > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index 5bb47583b3..5899df52c3 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -58,6 +58,7 @@ > #include > #include > #include > +#include You cannot include this header file, because... > #include > #include > #include > @@ -606,6 +607,57 @@ static int hvm_print_line( > return X86EMUL_OKAY; > } > > +static int vmtrace_alloc_buffers(struct vcpu *v, uint64_t size) > +{ > + struct page_info *pg; > + struct pt_state *pt; > + > + if ( size < PAGE_SIZE || size > GB(4) || (size & (size - 1)) ) > + { > + /* > + * We don't accept trace buffer size smaller than single page > + * and the upper bound is defined as 4GB in the specification. > + * The buffer size must be also a power of 2. > + */ > + return -EINVAL; > + } > + > + if ( vmx_add_host_load_msr(v, MSR_RTIT_CTL, 0) ) > + return -EFAULT; ... this will explode on AMD hardware, as will ... > + > + pg = alloc_domheap_pages(v->domain, get_order_from_bytes(size), > + MEMF_no_refcount); > + > + if ( !pg ) > + return -ENOMEM; > + > + pt = xzalloc(struct pt_state); > + > + if ( !pt ) > + return -ENOMEM; > + > + pt->output_base = page_to_maddr(pg); > + pt->output_mask.raw = size - 1; > + > + v->arch.hvm.vmx.pt_state = pt; ... this.  Both by reaching into the wrong half of the vmx/svm union.  (Also for the acquire resource in mm.c) > @@ -5101,6 +5265,10 @@ long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg) > rc = current->hcall_compat ? compat_altp2m_op(arg) : do_altp2m_op(arg); > break; > > + case HVMOP_vmtrace: > + rc = do_vmtrace_op(arg); > + break; In my feedback on v1, I specifically recommended domctl, because hvmop is incompatible with a future expansion to PV guests. > diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h > index 59bdc28c89..054892befe 100644 > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -92,6 +92,7 @@ struct xen_domctl_createdomain { > uint32_t max_evtchn_port; > int32_t max_grant_frames; > int32_t max_maptrack_frames; > + uint64_t vmtrace_pt_size; For now, we have very limited space (128 bytes total) for this structure.  This will change in the future with the tools ABI changes, but uint64_t is total overkill. Julien/Stefano: For ARM CoreSight, are the trace buffers required to be a power of two size, and/or is this a reasonable implementation restriction you'd be willing to live with? If so, we can get away with a uint8_t vmtrace_order, using 0 for "nothing", 1 for 8k, 2 for 16k etc.  (This does rule out allocating a 4k buffer, but shifting the number scheme to be order-1 is a no-go complexity wise, and the only other alternative is an explicit CDF flag for vmtrace). > diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h > index 0a91bfa749..22f6185e01 100644 > --- a/xen/include/public/hvm/params.h > +++ b/xen/include/public/hvm/params.h > @@ -300,6 +300,6 @@ > #define XEN_HVM_MCA_CAP_LMCE (xen_mk_ullong(1) << 0) > #define XEN_HVM_MCA_CAP_MASK XEN_HVM_MCA_CAP_LMCE > > -#define HVM_NR_PARAMS 39 > +#define HVM_NR_PARAMS 40 This hunk is now stale, and can be dropped. > > #endif /* __XEN_PUBLIC_HVM_PARAMS_H__ */ > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h > index dbd35305df..f823c784c3 100644 > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -620,6 +620,7 @@ struct xen_mem_acquire_resource { > > #define XENMEM_resource_ioreq_server 0 > #define XENMEM_resource_grant_table 1 > +#define XENMEM_resource_vmtrace_buf 2 > > /* > * IN - a type-specific resource identifier, which must be zero > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h > index ac53519d7f..48f0a61bbd 100644 > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -457,6 +457,10 @@ struct domain > unsigned pbuf_idx; > spinlock_t pbuf_lock; > > + /* Used by vmtrace features */ > + spinlock_t vmtrace_lock; > + uint64_t vmtrace_pt_size; Overall, the moving parts of this series needs to split out into rather more patches. First, in patch 3, the hvm_funcs.pt_supported isn't the place for that to live.  You want a global "bool vmtrace_supported" in common/domain.c which vmx_init_vmcs_config() sets, and the ARM code can set in the future when CoreSight is added. Next, you want a patch in isolation which adds vmtrace_pt_size (or whatever it ends up being) to createdomain, where all allocation/deallocation logic lives in common/domain.c.  The spinlock (if its needed, but I don't think it is) wants initialising early in domain_create(), alongside d->pbuf_lock, and you also need an extra clause in sanitise_domain_config() which rejects a vmtrace setting if vmtrace isn't supported.  You'll need to put the struct page_info * pointer to the memory allocation in struct vcpu, and adjust the vcpu create/destroy logic appropriately. Next, you want a patch doing the acquire resource logic for userspace to map the buffers. Next, you want a patch to introduce a domctl with the various runtime enable/disable settings which were in an hvmop here. Next, you want a patch to do the VMX plumbing, both at create, and runtime. This ought to lay the logic out in a way which is extendable to x86 PV guests and ARM CoreSight, and oughtn't to explode when creating guests on non-Intel hardware. Thanks, ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 23 12:57:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 12:57:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jniTz-0000Zc-3d; Tue, 23 Jun 2020 12:56:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jniTx-0000ZX-FQ for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 12:56:57 +0000 X-Inumbo-ID: 044f4970-b551-11ea-bca7-bc764e2007e4 Received: from mail-lj1-x243.google.com (unknown [2a00:1450:4864:20::243]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 044f4970-b551-11ea-bca7-bc764e2007e4; Tue, 23 Jun 2020 12:56:56 +0000 (UTC) Received: by mail-lj1-x243.google.com with SMTP id i3so23315994ljg.3 for ; Tue, 23 Jun 2020 05:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tmgHnnSd2AhlWUZqE+7+CsDcN51ZUIEGo1aJK/n/Weo=; b=l7Qh+igWjhF19vtDMdlg9w4aaLAglXbIa7Oora5BImo+Vclc+QT/p19Xhx2JL7C375 XDzBg1zGQn7YSEGbPvFAkAV++t1YXqPZhfFZitCY52h6flQcm+dQLNM2kPYl7HcYhxDW RnQBYQ26uPFiNr4Qz7JBcYdoFgVSuNa+pciaq+nvHRkHXLgwYFSJXjTJ+rw0vsT31vES AfrEZKWpQ0dU47hE0u4FF2wGabGlsaYL8l5dsWYcoOpR5Mzll3SoA2p/iLk+OhpAgZNR 9WdzGJ47zAk+3bpuahmY/smlElabvUu+q7Wnt0zsrxpNZHGx0Zqs+LMZqkp4UziBbfjg noAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tmgHnnSd2AhlWUZqE+7+CsDcN51ZUIEGo1aJK/n/Weo=; b=Sxa8Q+W8A79EaholMzxySkwDXYadRveRhKXfRvo6swwfTDlETLaXbFLpPkHkO28bbP CyIBdTDGesbFF+kH9RsHGervStmlsX0LQHESQE9QaYN8f1ZO+Z0ycmaqyvjXBBGXp/as 2/QqmvcFoBnwcxyrAKh3UnokRga+b7eTVxhTS+KummVxhNbhZVUGwRepG4u7xCO/zgvD XlcffOb6KKrwswRrEoa4KfUWlFeddocj17Ha5rbi6ZHI6+tgu0U13tnLb3DFc8Y8scAq Yqfo/vAWSaYNTYjMiX/fcDKCXhDwMS5T3A12J9rAbFVSYqh02hu9fEweSZBIqS8A4Ihn 8UFg== X-Gm-Message-State: AOAM532u+B2gXiuuiX/xIRRC+c0BFuXyCX4ybNM94kDFI92OKJ+BCvE0 j2Rvn3ehKCVZ1hYf2yuIOSvyzgZA0CTX9UOkCi8= X-Google-Smtp-Source: ABdhPJwIJTA5lJ4uvW7bRBluKVm8y8/7TchRhkHlA0g7a+1ldYD4TNrBKwSb0bL81yRwHF10467WzDyTPFQIMefqCOY= X-Received: by 2002:a2e:9a59:: with SMTP id k25mr11869856ljj.114.1592917015188; Tue, 23 Jun 2020 05:56:55 -0700 (PDT) MIME-Version: 1.0 References: <87k0zykwdl.fsf@dusky.pond.sub.org> In-Reply-To: <87k0zykwdl.fsf@dusky.pond.sub.org> From: Jason Andryuk Date: Tue, 23 Jun 2020 08:56:43 -0400 Message-ID: Subject: Re: sysbus failed assert for xen_sysdev To: Markus Armbruster Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , xen-devel , Mark Cave-Ayland , QEMU , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 4:41 AM Markus Armbruster wrote: > > Jason Andryuk writes: > > > On Mon, Jun 22, 2020 at 5:17 PM Mark Cave-Ayland > > wrote: > >> > >> On 22/06/2020 21:33, Jason Andryuk wrote: > >> > >> > Hi, > >> > > >> > Running qemu devel for a Xen VM is failing an assert after the recent > >> > "qdev: Rework how we plug into the parent bus" sysbus changes. > >> > > >> > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > >> > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > >> > failed. > >> > > >> > dc->bus_type is "xen-sysbus" and it's the > >> > `object_dynamic_cast(OBJECT(bus), dc->bus_type)` portion that fails > >> > the assert. bus seems to be "main-system-bus", I think: > >> > (gdb) p *bus > >> > $3 = {obj = {class = 0x55555636d780, free = 0x7ffff7c40db0 , > >> > properties = 0x5555563f7180, ref = 3, parent = 0x5555563fe980}, parent > >> > = 0x0, name = 0x5555563fec60 "main-system-bus", ... > >> > > >> > The call comes from hw/xen/xen-legacy-backend.c:706 > >> > sysbus_realize_and_unref(SYS_BUS_DEVICE(xen_sysdev), &error_fatal); > >> > > >> > Any pointers on what needs to be fixed? > >> > >> Hi Jason, > >> > >> My understanding is that the assert() is telling you that you're plugging a > >> TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. > >> TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. A quick look > > Correct. Let's review the assertion: > > assert(dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)); > > Context: we're supposted to plug @dev into @bus, and @dc is @dev's > DeviceClass. > > The assertion checks that > > 1. @dev plugs into a bus: dc->bus_type > > 2. @bus is an instance of the type of bus @dev plugs into: > object_dynamic_cast(OBJECT(bus), dc->bus_type) > > >> at the file in question suggests that you could try changing the parent class of > >> TYPE_XENSYSBUS from TYPE_BUS to TYPE_SYSTEM_BUS to see if that helps? > > > > Hi, Mark. > > > > Thanks, but unfortunately changing xensysbus_info .parent does not > > stop the assert. But it kinda pointed me in the right direction. > > > > xen-sysdev overrode the bus_type which was breaking sysbus_realize. > > So drop that: > > > > --- a/hw/xen/xen-legacy-backend.c > > +++ b/hw/xen/xen-legacy-backend.c > > @@ -824,7 +825,7 @@ static void xen_sysdev_class_init(ObjectClass > > *klass, void *data) > > DeviceClass *dc = DEVICE_CLASS(klass); > > > > device_class_set_props(dc, xen_sysdev_properties); > > - dc->bus_type = TYPE_XENSYSBUS; > > + //dc->bus_type = TYPE_XENSYSBUS; > > } > > Uff! > > Let me explain how things are supposed to work. > > Say we have FOO bus (QOM type TYPE_FOO_BUS), with FOO devices plugging > into it (abstract QOM type TYPE_FOO_DEVICE). One of them is SOME_FOO > (concrete QOM type TYPE_SOME_FOO). Code ties them together like this: > > static const TypeInfo pci_bus_info = { > .name = TYPE_PCI_BUS, > .parent = TYPE_BUS, > ... > }; > > static const TypeInfo foo_device_info = { > .name = TYPE_FOO_DEVICE, > .parent = TYPE_DEVICE, > .abstract = true, > .class_init = foo_device_class_init, > ... > }; > > static void foo_device_class_init(ObjectClass *oc, void *data) > { > DeviceClass *dc = DEVICE_CLASS(oc); > > dc->bus_type = TYPE_FOO_BUS; > ... > } > > static const TypeInfo some_foo_info = { > .name = TYPE_SOME_FOO, > .parent = TYPE_FOO_DEVICE, > ... > }; > > When you plug an instance of TYPE_SOME_FOO into a bus, the assertion > checks that the bus is an instance of TYPE_FOO_BUS. > > Note that subtypes of TYPE_FOO_DEVICE do not mess with dc->bus_type! > > TYPE_XENSYSDEV does mess with it: > > static void xen_sysdev_class_init(ObjectClass *klass, void *data) > { > DeviceClass *dc = DEVICE_CLASS(klass); > > device_class_set_props(dc, xen_sysdev_properties); > dc->bus_type = TYPE_XENSYSBUS; > } > > static const TypeInfo xensysdev_info = { > .name = TYPE_XENSYSDEV, > .parent = TYPE_SYS_BUS_DEVICE, > .instance_size = sizeof(SysBusDevice), > .class_init = xen_sysdev_class_init, > }; > > On the one hand, xensysdev_info.parent claims TYPE_XENSYSDEV is a > TYPE_SYS_BUS_DEVICE (and therefore should plug into a TYPE_SYSTEM_BUS). > On the other hand, its dc->bus_type is a TYPE_XENSYSBUS, which is *not* > a subtype of TYPE_SYSTEM_BUS: > > static const TypeInfo xensysbus_info = { > .name = TYPE_XENSYSBUS, > ---> .parent = TYPE_BUS, > .class_init = xen_sysbus_class_init, > .interfaces = (InterfaceInfo[]) { > { TYPE_HOTPLUG_HANDLER }, > { } > } > }; > > This is an inconsistent mess. > > Are TYPE_XENSYSDEV and TYPE_XENSYSBUS related to TYPE_SYS_BUS_DEVICE and > TYPE_SYSTEM_BUS? > > If no, then xensysbus_info.parent should not be TYPE_SYS_BUS_DEVICE, and > you must not pass instances of one kind to functions expecting the other > kind. > > If yes, how? If the former are specializations of the latter, consider > making the former subtypes of the latter. Both of them. Then a > TYPE_XENSYSDEV device can plug into a TYPE_XENSYSBUS bus, but not into a > TYPE_SYSTEM_BUS bus. > > A TYPE_SYS_BUS_DEVICE could still plug into TYPE_XENSYSBUS, because the > latter is also an instance of TYPE_SYSTEM_BUS. Thanks for your response, Markus. I didn't write it, but my understanding is as follows. TYPE_XENSYSDEV is a device on the system bus that provides the TYPE_XENSYSBUS bus. TYPE_XENBACKEND devices can then attach to TYPE_XENSYSBUS. That would make the qom-tree something like: /TYPE_XENSYSDEV /TYPE_XENSYSBUX /TYPE_XENBACKEND (I think today the TYPE_XENBACKEND devices ends up attached to the System bus.) I think TYPE_XENSYSDEV is correct - it is a device on the system bus. static const TypeInfo xensysdev_info = { .name = TYPE_XENSYSDEV, .parent = TYPE_SYS_BUS_DEVICE, ... } TYPE_XENSYSBUS is the xen-specific bus - provided by TYPE_XENSYSDEV - for attaching xendev. static const TypeInfo xensysbus_info = { .name = TYPE_XENSYSBUS, .parent = TYPE_BUS, ... } TYPE_XENBACKEND is a generic Xen device and it plugs into TYPE_XENSYSBUS. Maybe the .parent here is wrong and it should just be TYPE_DEVICE? static const TypeInfo xendev_type_info = { .name = TYPE_XENBACKEND, .parent = TYPE_XENSYSDEV, ... } So removing `bus_type = TYPE_XENSYSBUS` from TYPE_XENSYSDEV class_init and adding it to TYPE_XENBACKEND seems correct to me. Regards, Jason > Questions? > > > > > static const TypeInfo xensysdev_info = { > > > > Then I had a different instance of the failed assert trying to attach > > xen-console-0 to xen-sysbus. So I made this change: > > --- a/hw/xen/xen-legacy-backend.c > > +++ b/hw/xen/xen-legacy-backend.c > > @@ -789,6 +789,7 @@ static void xendev_class_init(ObjectClass *klass, > > void *data) > > set_bit(DEVICE_CATEGORY_MISC, dc->categories); > > /* xen-backend devices can be plugged/unplugged dynamically */ > > dc->user_creatable = true; > > + dc->bus_type = TYPE_XENSYSBUS; > > } > > > > static const TypeInfo xendev_type_info = { > > > > Then it gets farther... until > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > > Assertion `dev->realized' failed. > > > > dev->id is NULL. The failing device is: > > (gdb) p *dev.parent_obj.class.type > > $12 = {name = 0x555556207770 "cfi.pflash01", > > > > Is that right? > > > > I'm going to have to take a break from this now. > > > > Regards, > > Jason > From xen-devel-bounces@lists.xenproject.org Tue Jun 23 13:23:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 13:23:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnitA-0003Av-8g; Tue, 23 Jun 2020 13:23:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnit8-0003Aq-V8 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 13:22:59 +0000 X-Inumbo-ID: a6fc391e-b554-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x331.google.com (unknown [2a00:1450:4864:20::331]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a6fc391e-b554-11ea-b7bb-bc764e2007e4; Tue, 23 Jun 2020 13:22:57 +0000 (UTC) Received: by mail-wm1-x331.google.com with SMTP id q15so1326680wmj.2 for ; Tue, 23 Jun 2020 06:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=vIGEeWZ/DVd9Ibs07TWhRGb9A0+4o4egEkTtwP8/mEg=; b=LjDAtRteY8fo/Dm7K4nv316lDLC6HqeijvUUDZeSU+csoYPmhYG113Cwj6B4traz+x IgY6JZBXWzgbmfwhkEHp6NzHcAB8MjwWwQ28+sv6c37WEzSilfTVwmPUFw120k8wsuTg ok5GyvksuFQHSi2t61o58WQU3lUPDbf9B/mpn89NRVSfh04HDLNOBaihnS32aDn3uJd4 aQ47iqrhqdV7uDafZOEbFWi1xhxaOOJASLOFIXjHz+mCHLcjI9yQoZRbF5htTH6naw3W 26qFyiyapxARuPQ++t/BzUcv1B8Exhrcp0YB0EX59TiafQFsNyONTLaY6XzCxe2YJP5v 0KEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=vIGEeWZ/DVd9Ibs07TWhRGb9A0+4o4egEkTtwP8/mEg=; b=UcNUQMnf680PKA/hMf7tsvuup7SHR9PleI65NBAk3wqExeU7xE6J/VleOF8DEZksEl fktwHKT/Xc3rGDTijdPbyHWaWw/+VBhZ7PLx14rjoIDXqQdVwVwq0KuGqtVgjHqKnGEv akGGw01ZR28sPjrRyjiwBYXlUHH7Px9AaBXDxKxLRmGNbYl5M1/2nw4sjNpd8Cib6MVq cPXDyLpzVBdaD0x8p/F9/jS20Xx6V9ICMSLsbKlZYdDOvl+Z5TVEFNdpJvVtrAsE+YfR 3FSzvoCmFWTT8rpNnoPv30IZdK65T1+2jHa8GqMQDLvWAq/AbUjG5WOERIrk0oAiVhmp HSSw== X-Gm-Message-State: AOAM5319zCzPVfUEx5N+WOiG3CsOVZxQJGx4e1b1trZeEumrQxuX4vBr O6HEqERjDuCprk6XG65c5xk= X-Google-Smtp-Source: ABdhPJyrIF8yCBU+BQCn+xuPW6esvDwE9e7lES4JkEqmtABqvocaYgJ3qEe2pLJTMlMjP+pdmf2FZA== X-Received: by 2002:a7b:cb11:: with SMTP id u17mr24112181wmj.84.1592918576756; Tue, 23 Jun 2020 06:22:56 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-224.amazon.com. [54.240.197.224]) by smtp.gmail.com with ESMTPSA id u10sm3710648wml.29.2020.06.23.06.22.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 06:22:56 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jason Andryuk'" , "'Markus Armbruster'" References: <87k0zykwdl.fsf@dusky.pond.sub.org> In-Reply-To: Subject: RE: sysbus failed assert for xen_sysdev Date: Tue, 23 Jun 2020 14:22:54 +0100 Message-ID: <000101d64961$681c0350$385409f0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIJfv1jP4fCJU6d0eNUL65zTb1lhAKJjZPCAZLY/IEByWeHdwGvNa5pqEMcPwA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Anthony PERARD' , 'xen-devel' , 'Mark Cave-Ayland' , 'QEMU' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jason Andryuk > Sent: 23 June 2020 13:57 > To: Markus Armbruster > Cc: Mark Cave-Ayland ; Anthony PERARD ; xen- > devel ; Paul Durrant ; QEMU > Subject: Re: sysbus failed assert for xen_sysdev > > On Tue, Jun 23, 2020 at 4:41 AM Markus Armbruster wrote: > > > > Jason Andryuk writes: > > > > > On Mon, Jun 22, 2020 at 5:17 PM Mark Cave-Ayland > > > wrote: > > >> > > >> On 22/06/2020 21:33, Jason Andryuk wrote: > > >> > > >> > Hi, > > >> > > > >> > Running qemu devel for a Xen VM is failing an assert after the recent > > >> > "qdev: Rework how we plug into the parent bus" sysbus changes. > > >> > > > >> > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > > >> > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > > >> > failed. > > >> > > > >> > dc->bus_type is "xen-sysbus" and it's the > > >> > `object_dynamic_cast(OBJECT(bus), dc->bus_type)` portion that fails > > >> > the assert. bus seems to be "main-system-bus", I think: > > >> > (gdb) p *bus > > >> > $3 = {obj = {class = 0x55555636d780, free = 0x7ffff7c40db0 , > > >> > properties = 0x5555563f7180, ref = 3, parent = 0x5555563fe980}, parent > > >> > = 0x0, name = 0x5555563fec60 "main-system-bus", ... > > >> > > > >> > The call comes from hw/xen/xen-legacy-backend.c:706 > > >> > sysbus_realize_and_unref(SYS_BUS_DEVICE(xen_sysdev), &error_fatal); > > >> > > > >> > Any pointers on what needs to be fixed? > > >> > > >> Hi Jason, > > >> > > >> My understanding is that the assert() is telling you that you're plugging a > > >> TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. > > >> TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. A quick look > > > > Correct. Let's review the assertion: > > > > assert(dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)); > > > > Context: we're supposted to plug @dev into @bus, and @dc is @dev's > > DeviceClass. > > > > The assertion checks that > > > > 1. @dev plugs into a bus: dc->bus_type > > > > 2. @bus is an instance of the type of bus @dev plugs into: > > object_dynamic_cast(OBJECT(bus), dc->bus_type) > > > > >> at the file in question suggests that you could try changing the parent class of > > >> TYPE_XENSYSBUS from TYPE_BUS to TYPE_SYSTEM_BUS to see if that helps? > > > > > > Hi, Mark. > > > > > > Thanks, but unfortunately changing xensysbus_info .parent does not > > > stop the assert. But it kinda pointed me in the right direction. > > > > > > xen-sysdev overrode the bus_type which was breaking sysbus_realize. > > > So drop that: > > > > > > --- a/hw/xen/xen-legacy-backend.c > > > +++ b/hw/xen/xen-legacy-backend.c > > > @@ -824,7 +825,7 @@ static void xen_sysdev_class_init(ObjectClass > > > *klass, void *data) > > > DeviceClass *dc = DEVICE_CLASS(klass); > > > > > > device_class_set_props(dc, xen_sysdev_properties); > > > - dc->bus_type = TYPE_XENSYSBUS; > > > + //dc->bus_type = TYPE_XENSYSBUS; > > > } > > > > Uff! > > > > Let me explain how things are supposed to work. > > > > Say we have FOO bus (QOM type TYPE_FOO_BUS), with FOO devices plugging > > into it (abstract QOM type TYPE_FOO_DEVICE). One of them is SOME_FOO > > (concrete QOM type TYPE_SOME_FOO). Code ties them together like this: > > > > static const TypeInfo pci_bus_info = { > > .name = TYPE_PCI_BUS, > > .parent = TYPE_BUS, > > ... > > }; > > > > static const TypeInfo foo_device_info = { > > .name = TYPE_FOO_DEVICE, > > .parent = TYPE_DEVICE, > > .abstract = true, > > .class_init = foo_device_class_init, > > ... > > }; > > > > static void foo_device_class_init(ObjectClass *oc, void *data) > > { > > DeviceClass *dc = DEVICE_CLASS(oc); > > > > dc->bus_type = TYPE_FOO_BUS; > > ... > > } > > > > static const TypeInfo some_foo_info = { > > .name = TYPE_SOME_FOO, > > .parent = TYPE_FOO_DEVICE, > > ... > > }; > > > > When you plug an instance of TYPE_SOME_FOO into a bus, the assertion > > checks that the bus is an instance of TYPE_FOO_BUS. > > > > Note that subtypes of TYPE_FOO_DEVICE do not mess with dc->bus_type! > > > > TYPE_XENSYSDEV does mess with it: > > > > static void xen_sysdev_class_init(ObjectClass *klass, void *data) > > { > > DeviceClass *dc = DEVICE_CLASS(klass); > > > > device_class_set_props(dc, xen_sysdev_properties); > > dc->bus_type = TYPE_XENSYSBUS; > > } > > > > static const TypeInfo xensysdev_info = { > > .name = TYPE_XENSYSDEV, > > .parent = TYPE_SYS_BUS_DEVICE, > > .instance_size = sizeof(SysBusDevice), > > .class_init = xen_sysdev_class_init, > > }; > > > > On the one hand, xensysdev_info.parent claims TYPE_XENSYSDEV is a > > TYPE_SYS_BUS_DEVICE (and therefore should plug into a TYPE_SYSTEM_BUS). > > On the other hand, its dc->bus_type is a TYPE_XENSYSBUS, which is *not* > > a subtype of TYPE_SYSTEM_BUS: > > > > static const TypeInfo xensysbus_info = { > > .name = TYPE_XENSYSBUS, > > ---> .parent = TYPE_BUS, > > .class_init = xen_sysbus_class_init, > > .interfaces = (InterfaceInfo[]) { > > { TYPE_HOTPLUG_HANDLER }, > > { } > > } > > }; > > > > This is an inconsistent mess. > > > > Are TYPE_XENSYSDEV and TYPE_XENSYSBUS related to TYPE_SYS_BUS_DEVICE and > > TYPE_SYSTEM_BUS? > > > > If no, then xensysbus_info.parent should not be TYPE_SYS_BUS_DEVICE, and > > you must not pass instances of one kind to functions expecting the other > > kind. > > > > If yes, how? If the former are specializations of the latter, consider > > making the former subtypes of the latter. Both of them. Then a > > TYPE_XENSYSDEV device can plug into a TYPE_XENSYSBUS bus, but not into a > > TYPE_SYSTEM_BUS bus. > > > > A TYPE_SYS_BUS_DEVICE could still plug into TYPE_XENSYSBUS, because the > > latter is also an instance of TYPE_SYSTEM_BUS. > > Thanks for your response, Markus. > > I didn't write it, but my understanding is as follows. TYPE_XENSYSDEV > is a device on the system bus that provides the TYPE_XENSYSBUS bus. > TYPE_XENBACKEND devices can then attach to TYPE_XENSYSBUS. > > That would make the qom-tree something like: > /TYPE_XENSYSDEV > /TYPE_XENSYSBUX > /TYPE_XENBACKEND > > (I think today the TYPE_XENBACKEND devices ends up attached to the System bus.) > > I think TYPE_XENSYSDEV is correct - it is a device on the system bus. > static const TypeInfo xensysdev_info = { > .name = TYPE_XENSYSDEV, > .parent = TYPE_SYS_BUS_DEVICE, > ... > } > > TYPE_XENSYSBUS is the xen-specific bus - provided by TYPE_XENSYSDEV - > for attaching xendev. > static const TypeInfo xensysbus_info = { > .name = TYPE_XENSYSBUS, > .parent = TYPE_BUS, > ... > } > > TYPE_XENBACKEND is a generic Xen device and it plugs into > TYPE_XENSYSBUS. Maybe the .parent here is wrong and it should just be > TYPE_DEVICE? Yes, I think that is the problem leading to the assert. See the equivalent (non-legacy) code in xen-bus.c. Paul > static const TypeInfo xendev_type_info = { > .name = TYPE_XENBACKEND, > .parent = TYPE_XENSYSDEV, > ... > } > > So removing `bus_type = TYPE_XENSYSBUS` from TYPE_XENSYSDEV class_init > and adding it to TYPE_XENBACKEND seems correct to me. > > Regards, > Jason > > > Questions? > > > > > > > > static const TypeInfo xensysdev_info = { > > > > > > Then I had a different instance of the failed assert trying to attach > > > xen-console-0 to xen-sysbus. So I made this change: > > > --- a/hw/xen/xen-legacy-backend.c > > > +++ b/hw/xen/xen-legacy-backend.c > > > @@ -789,6 +789,7 @@ static void xendev_class_init(ObjectClass *klass, > > > void *data) > > > set_bit(DEVICE_CATEGORY_MISC, dc->categories); > > > /* xen-backend devices can be plugged/unplugged dynamically */ > > > dc->user_creatable = true; > > > + dc->bus_type = TYPE_XENSYSBUS; > > > } > > > > > > static const TypeInfo xendev_type_info = { > > > > > > Then it gets farther... until > > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > > > Assertion `dev->realized' failed. > > > > > > dev->id is NULL. The failing device is: > > > (gdb) p *dev.parent_obj.class.type > > > $12 = {name = 0x555556207770 "cfi.pflash01", > > > > > > Is that right? > > > > > > I'm going to have to take a break from this now. > > > > > > Regards, > > > Jason > > From xen-devel-bounces@lists.xenproject.org Tue Jun 23 13:31:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 13:31:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnj1m-00047V-5E; Tue, 23 Jun 2020 13:31:54 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnj1k-00047Q-IH for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 13:31:52 +0000 X-Inumbo-ID: e51977c4-b555-11ea-bf69-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e51977c4-b555-11ea-bf69-12813bfff9fa; Tue, 23 Jun 2020 13:31:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ijd+Fveth8imWAvlOuPD1VFNh4Y4ifIWJ3J6sUSMolc=; b=cbHBd2H5FeJ7eB2iQmhBNOeeHR /uUieutH8vfSsoFkPsGxJmUlrgnYCy3dCp1K7NwCSXzJM840Hq1bvDDOqUYPy9JQtulLvtgs9EKM9 2OpJd8x7YutWE/iwGdiN9/uE88SFlsIrnhVlCzMcqsMugxefrzTOxeWq1NtD75KuTbNU=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnj1i-0004zE-Eg; Tue, 23 Jun 2020 13:31:50 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnj1i-0008MI-8H; Tue, 23 Jun 2020 13:31:50 +0000 Subject: Re: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address To: Volodymyr Babchuk , Stefano Stabellini References: <20200619223332.438344-1-volodymyr_babchuk@epam.com> <20200619223332.438344-3-volodymyr_babchuk@epam.com> <87ftampkd7.fsf@epam.com> From: Julien Grall Message-ID: <2df789f3-e881-36a3-51f4-010b499990f5@xen.org> Date: Tue, 23 Jun 2020 14:31:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <87ftampkd7.fsf@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "pdurrant@amazon.com" , "op-tee@lists.trustedfirmware.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23/06/2020 03:49, Volodymyr Babchuk wrote: > > Hi Stefano, > > Stefano Stabellini writes: > >> On Fri, 19 Jun 2020, Volodymyr Babchuk wrote: >>> Trusted Applications use popular approach to determine required size >>> of buffer: client provides a memory reference with the NULL pointer to >>> a buffer. This is so called "Null memory reference". TA updates the >>> reference with the required size and returns it back to the >>> client. Then client allocates buffer of needed size and repeats the >>> operation. >>> >>> This behavior is described in TEE Client API Specification, paragraph >>> 3.2.5. Memory References. >>> >>> OP-TEE represents this null memory reference as a TMEM parameter with >>> buf_ptr = 0x0. This is the only case when we should allow TMEM >>> buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. This also the >>> special case for a buffer with OPTEE_MSG_ATTR_NONCONTIG flag. >>> >>> This could lead to a potential issue, because IPA 0x0 is a valid >>> address, but OP-TEE will treat it as a special case. So, care should >>> be taken when construction OP-TEE enabled guest to make sure that such >>> guest have no memory at IPA 0x0 and none of its memory is mapped at PA >>> 0x0. >>> >>> Signed-off-by: Volodymyr Babchuk >>> --- >>> >>> Changes from v1: >>> - Added comment with TODO about possible PA/IPA 0x0 issue >>> - The same is described in the commit message >>> - Added check in translate_noncontig() for the NULL ptr buffer >>> >>> --- >>> xen/arch/arm/tee/optee.c | 27 ++++++++++++++++++++++++--- >>> 1 file changed, 24 insertions(+), 3 deletions(-) >>> >>> diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c >>> index 6963238056..70bfef7e5f 100644 >>> --- a/xen/arch/arm/tee/optee.c >>> +++ b/xen/arch/arm/tee/optee.c >>> @@ -215,6 +215,15 @@ static bool optee_probe(void) >>> return true; >>> } >>> >>> +/* >>> + * TODO: There is a potential issue with guests that either have RAM >>> + * at IPA of 0x0 or some of theirs memory is mapped at PA 0x0. This is >> ^ their >> >>> + * because PA of 0x0 is considered as NULL pointer by OP-TEE. It will >>> + * not be able to map buffer with such pointer to TA address space, or >>> + * use such buffer for communication with the guest. We either need to >>> + * check that guest have no such mappings or ensure that OP-TEE >>> + * enabled guest will not be created with such mappings. >>> + */ >>> static int optee_domain_init(struct domain *d) >>> { >>> struct arm_smccc_res resp; >>> @@ -725,6 +734,15 @@ static int translate_noncontig(struct optee_domain *ctx, >>> uint64_t next_page_data; >>> } *guest_data, *xen_data; >>> >>> + /* >>> + * Special case: buffer with buf_ptr == 0x0 is considered as NULL >>> + * pointer by OP-TEE. No translation is needed. This can lead to >>> + * an issue as IPA 0x0 is a valid address for Xen. See the comment >>> + * near optee_domain_init() >>> + */ >>> + if ( !param->u.tmem.buf_ptr ) >>> + return 0; >> >> Given that today it is not possible for this to happen, it could even be >> an ASSERT. But I think I would just return an error, maybe -EINVAL? > > Hmm, looks like my comment is somewhat misleading :( How about the following comment: We don't want to translate NULL (0) as it can be used by the guest to fetch the size of the buffer to allocate. This behavior depends on TA, but there is a guarantee that OP-TEE will not try to map it (see more details on top of optee_domain_init()). > > What I mean, is that param->u.tmem.buf_ptr == 0 is the normal situation. > This is the special case, when OP-TEE treats this buffer as a NULL. So > we are doing nothing there. Thus, "return 0". > > But, as Julien pointed out, we can have machine where 0x0 is the valid > memory address and there is a chance, that some guest will use it as a > pointer to buffer. > >> Aside from this, and the small grammar issue, everything else looks fine >> to me. >> >> Let's wait for Julien's reply, but if this is the only thing I could fix >> on commit. I agree with Volodymyr, this is the normal case here. There are more work to prevent MFN 0 to be mapped in the guest but this shouldn't be an issue today. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 23 13:53:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 13:53:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnjMF-0005yb-03; Tue, 23 Jun 2020 13:53:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnjME-0005yW-2Z for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 13:53:02 +0000 X-Inumbo-ID: d9ab4310-b558-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d9ab4310-b558-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 13:53:00 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: cBI9K2iVkwAOJvtSEJkLc9vejSk4/GsGP1TPn9bvwCwuIWGAdwOJKhxKZd0ngnmSSA4RDETZ+I hI4RqxGleDqRGJ8gACnqEyXvvK5be1QUNAu/StJc0xq9UT7Y41L6DDOJrZjjyLjgZ46fSl1LBC U3wWMIusL9/Jareoxnu3/HGJbvec6QM8iAfAz4MTm8KKtALE3GcpbyrgoSsYPaqH5LsMtoP5Dj ck1DzT2FM3dXsuLWEolY6ve+Vov1WEN8LMlUGOVgYbMDiABG9PXWRbAwLwN9BWsBKtZBqdNchW pkA= X-SBRS: 2.7 X-MesageID: 20718358 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,271,1589256000"; d="scan'208";a="20718358" From: Roger Pau Monne To: Subject: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource Date: Tue, 23 Jun 2020 15:52:46 +0200 Message-ID: <20200623135246.66170-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" XENMEM_acquire_resource and it's related structure is currently inside a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the hypervisor or the toolstack only. This is wrong as the hypercall is already being used by the Linux kernel at least, and as such needs to be public. Also switch the usage of uint64_aligned_t to plain uint64_t, as uint64_aligned_t is only to be used by the toolstack. Note that the layout of the structure will be the same, as the field is already naturally aligned to a 8 byte boundary. No functional change expected. Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire guest resources') Signed-off-by: Roger Pau Monné --- Would be good to get this fixed before the release in order to avoid shipping bogus headers. Should also be backported. --- xen/include/public/memory.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index dbd35305df..1767d7d5f5 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -607,6 +607,8 @@ struct xen_reserved_device_memory_map { typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t; DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ + /* * Get the pages for a particular guest resource, so that they can be * mapped directly by a tools domain. @@ -645,7 +647,7 @@ struct xen_mem_acquire_resource { * IN - the index of the initial frame to be mapped. This parameter * is ignored if nr_frames is 0. */ - uint64_aligned_t frame; + uint64_t frame; #define XENMEM_resource_ioreq_server_frame_bufioreq 0 #define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n)) @@ -666,8 +668,6 @@ struct xen_mem_acquire_resource { typedef struct xen_mem_acquire_resource xen_mem_acquire_resource_t; DEFINE_XEN_GUEST_HANDLE(xen_mem_acquire_resource_t); -#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ - /* * XENMEM_get_vnumainfo used by guest to get * vNUMA topology from hypervisor. -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 23 14:00:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 14:00:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnjSu-0006Fu-O1; Tue, 23 Jun 2020 13:59:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnjSt-0006Fp-A0 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 13:59:55 +0000 X-Inumbo-ID: d056ad44-b559-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d056ad44-b559-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 13:59:54 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id l12so21720543ejn.10 for ; Tue, 23 Jun 2020 06:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Gb4NUvBy8Ph9fUEr6tjOnT5CVBwQHg6EKwdsE8jZlHI=; b=KIusJk/PNEedoAuvJiCt0JCS9KYU7S500X6vPJU32fvO22P7X6in5YpnLFfydYOPKS WOd68I236TknwkO7DSRHAywtSPHqYvLgLeO99YqUPKHz/hUOn2jKjc3jw6GqnTAjxND5 s1HZoxL5r4/acfqoZDyZbmR2TgZ8YVtKeyYQnV0JkiqIItI0zDcWlC+pXrqyPdv6fxgr 1IU81/+29LHb4FF3lJfgcgl5fpLtNZ+YEaRDp2o19HU5W/YOIVDkYZwZ4Ryr6tnqd/oS TA1SDGHjubDQuIH91iJH2MMIkr1TKZKHgoc2VRCYV21nHqwJR5egKjiDKVjAZMniekLa jBmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=Gb4NUvBy8Ph9fUEr6tjOnT5CVBwQHg6EKwdsE8jZlHI=; b=QKzQfleO2TIow8XKfSw5qZKAs5FGkAjL6leSLZlJj78bziYuH7MA0hZG1j6PzJleg8 F/a1CIOtTrxkXhVKhR+mN6m/IHGIgDovjjhWHknkdFWKaoDT7rXtTt2zcyWLwXhCvE27 jOjgI0oyDUk5a0PzPJQuV5W5TSsSqM0GKOe248FojBeJLDHJ9BMfqIngkE+EkFzn3ja+ 50yvHlH08xoGiZAY9P4ieZhYRx4POvC16K9V40+FyPlBYUWf15ECoLnETa4lheq667pG 3Y92UpcgWhnItWUGGnY5btVEidfz/AarxW/GTi5thDSw4Rz8q/cPdqf/fvNn0t91LGOc 3VPg== X-Gm-Message-State: AOAM5310TsLwAupa5bdVtt85lDUTaNUZQArqL05u87311LKXoT+PXXuc 1Ag25NwSH7AH6DeGgovnCYM= X-Google-Smtp-Source: ABdhPJzh05rjZKezVhzRfFRQY8mV1Aikv3riqynG4p9Gvyt9Q+Xp1b0IYAwzef6dsSb0tfgsrr+2FA== X-Received: by 2002:a17:906:434f:: with SMTP id z15mr19947384ejm.178.1592920793664; Tue, 23 Jun 2020 06:59:53 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-232.amazon.com. [54.240.197.232]) by smtp.gmail.com with ESMTPSA id k23sm13539600ejg.89.2020.06.23.06.59.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 06:59:53 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200623135246.66170-1-roger.pau@citrix.com> In-Reply-To: <20200623135246.66170-1-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource Date: Tue, 23 Jun 2020 14:59:51 +0100 Message-ID: <000301d64966$91885090$b498f1b0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJU5g6mkfXrDLlGsNt841F72IbClqfo/9Sw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 23 June 2020 14:53 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Andrew = Cooper ; > George Dunlap ; Ian Jackson = ; Jan Beulich > ; Julien Grall ; Stefano Stabellini = ; Wei > Liu > Subject: [PATCH for-4.14] mm: fix public declaration of struct = xen_mem_acquire_resource >=20 > XENMEM_acquire_resource and it's related structure is currently inside > a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > hypervisor or the toolstack only. This is wrong as the hypercall is > already being used by the Linux kernel at least, and as such needs to > be public. >=20 > Also switch the usage of uint64_aligned_t to plain uint64_t, as > uint64_aligned_t is only to be used by the toolstack. Note that the > layout of the structure will be the same, as the field is already > naturally aligned to a 8 byte boundary. >=20 > No functional change expected. >=20 > Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire = guest resources') > Signed-off-by: Roger Pau Monn=C3=A9 > --- > Would be good to get this fixed before the release in order to avoid > shipping bogus headers. Should also be backported. Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant > --- > xen/include/public/memory.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) >=20 > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h > index dbd35305df..1767d7d5f5 100644 > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -607,6 +607,8 @@ struct xen_reserved_device_memory_map { > typedef struct xen_reserved_device_memory_map = xen_reserved_device_memory_map_t; > DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); >=20 > +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ > + > /* > * Get the pages for a particular guest resource, so that they can be > * mapped directly by a tools domain. > @@ -645,7 +647,7 @@ struct xen_mem_acquire_resource { > * IN - the index of the initial frame to be mapped. This = parameter > * is ignored if nr_frames is 0. > */ > - uint64_aligned_t frame; > + uint64_t frame; >=20 > #define XENMEM_resource_ioreq_server_frame_bufioreq 0 > #define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n)) > @@ -666,8 +668,6 @@ struct xen_mem_acquire_resource { > typedef struct xen_mem_acquire_resource xen_mem_acquire_resource_t; > DEFINE_XEN_GUEST_HANDLE(xen_mem_acquire_resource_t); >=20 > -#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ > - > /* > * XENMEM_get_vnumainfo used by guest to get > * vNUMA topology from hypervisor. > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 23 14:27:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 14:27:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnjtn-0000Yt-VK; Tue, 23 Jun 2020 14:27:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnjtm-0000Yo-8E for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 14:27:42 +0000 X-Inumbo-ID: b1a68960-b55d-11ea-bf83-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b1a68960-b55d-11ea-bf83-12813bfff9fa; Tue, 23 Jun 2020 14:27:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=IURxG91sRzxVmW/MneK75Cz8yfMZIlpvgK+sa1F5nHA=; b=GKdLT7Y3MzXwpVURQITrQSZzQD Q5Un2GAx81Ii1T1tV/2nmLfztaZmbca149xIc0yXSjvLhvkMOa6INXAK/lVGWyQaue2HrGoZHRX1o 6dp0b/irjA4vE+bRjrhFmDlQg6aMc8u+vFwc8fTvso2ieO6sTzNey+MYPCdEqeKH0nL8=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnjti-00065n-82; Tue, 23 Jun 2020 14:27:38 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnjth-0002j2-VS; Tue, 23 Jun 2020 14:27:38 +0000 Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20200623135246.66170-1-roger.pau@citrix.com> From: Julien Grall Message-ID: Date: Tue, 23 Jun 2020 15:27:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623135246.66170-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23/06/2020 14:52, Roger Pau Monne wrote: > XENMEM_acquire_resource and it's related structure is currently inside > a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > hypervisor or the toolstack only. This is wrong as the hypercall is > already being used by the Linux kernel at least, and as such needs to > be public. > > Also switch the usage of uint64_aligned_t to plain uint64_t, as > uint64_aligned_t is only to be used by the toolstack. Note that the > layout of the structure will be the same, as the field is already > naturally aligned to a 8 byte boundary. > > No functional change expected. > > Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire guest resources') > Signed-off-by: Roger Pau Monné Reviewed-by: Julien Grall > --- > Would be good to get this fixed before the release in order to avoid > shipping bogus headers. Should also be backported. > --- > xen/include/public/memory.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h > index dbd35305df..1767d7d5f5 100644 > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -607,6 +607,8 @@ struct xen_reserved_device_memory_map { > typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t; > DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); > > +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ > + > /* > * Get the pages for a particular guest resource, so that they can be > * mapped directly by a tools domain. > @@ -645,7 +647,7 @@ struct xen_mem_acquire_resource { > * IN - the index of the initial frame to be mapped. This parameter > * is ignored if nr_frames is 0. > */ > - uint64_aligned_t frame; > + uint64_t frame; > > #define XENMEM_resource_ioreq_server_frame_bufioreq 0 > #define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n)) > @@ -666,8 +668,6 @@ struct xen_mem_acquire_resource { > typedef struct xen_mem_acquire_resource xen_mem_acquire_resource_t; > DEFINE_XEN_GUEST_HANDLE(xen_mem_acquire_resource_t); > > -#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ > - > /* > * XENMEM_get_vnumainfo used by guest to get > * vNUMA topology from hypervisor. > -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 23 14:50:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 14:50:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkFu-00034U-TF; Tue, 23 Jun 2020 14:50:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkFt-00034P-OS for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 14:50:33 +0000 X-Inumbo-ID: e33c3cb0-b560-11ea-bf95-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e33c3cb0-b560-11ea-bf95-12813bfff9fa; Tue, 23 Jun 2020 14:50:32 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: bcwLMcIj6TTlOhEnThpALzlm3WOZdDze10nc2384Hgqok2UEZwv32IVJtZC+TCDLG5ZTQh4NQ8 /lDGD342TMpTJ2oxVQW1qP6V11ISGLjjffJUgwx1FLQLvEzLbzl2Ww9Vhy+mKjshSCKonU+qel fQxye3MOtbK8+HNFUf+fjT+LaZ6PWH0lN1IuqAd8F4b1sbO5E+5M/MmZ3A7XLP9DXiLtxS8O8n irsvs+Yscc+dJ8f3xudRLK8UTuccLOHapOEtKjphHKmSQ4yRmjUmqjes5InjZp+tPy8HwC/llM ge4= X-SBRS: 2.7 X-MesageID: 21525805 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,271,1589256000"; d="scan'208";a="21525805" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v2] x86/tlb: fix assisted flush usage Date: Tue, 23 Jun 2020 16:50:06 +0200 Message-ID: <20200623145006.66723-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Volodymyr Babchuk , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Commit e9aca9470ed86 introduced a regression when avoiding sending IPIs for certain flush operations. Xen page fault handler (spurious_page_fault) relies on blocking interrupts in order to prevent handling TLB flush IPIs and thus preventing other CPUs from removing page tables pages. Switching to assisted flushing avoided such IPIs, and thus can result in pages belonging to the page tables being removed (and possibly re-used) while __page_fault_type is being executed. Force some of the TLB flushes to use IPIs, thus avoiding the assisted TLB flush. Those selected flushes are the page type change (when switching from a page table type to a different one, ie: a page that has been removed as a page table) and page allocation. This sadly has a negative performance impact on the pvshim, as less assisted flushes can be used. Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush using an IPI (flush_tlb_mask_sync). Note that the flag is only meaningfully defined when the hypervisor supports PV or shadow paging mode, as otherwise hardware assisted paging domains are in charge of their page tables and won't share page tables with Xen, thus not influencing the result of page walks performed by the spurious fault handler. Just passing this new flag when calling flush_area_mask prevents the usage of the assisted flush without any other side effects. Note the flag is not defined on Arm, and the introduced helper is just a dummy alias to the existing flush_tlb_mask. Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') Reported-by: Andrew Cooper Signed-off-by: Roger Pau Monné --- Changes since v1: - Add a comment describing the usage of FLUSH_FORCE_IPI (and why no modifications to flush_area_mask are required). - Use PGT_root_page_table instead of PGT_l4_page_table. - Also perform IPI flushes if configured with shadow paging support. - Use ifdef instead of if. --- xen/arch/x86/mm.c | 12 +++++++++++- xen/common/memory.c | 2 +- xen/common/page_alloc.c | 2 +- xen/include/asm-arm/flushtlb.h | 1 + xen/include/asm-x86/flushtlb.h | 18 ++++++++++++++++++ xen/include/xen/mm.h | 8 ++++++-- 6 files changed, 38 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index c294092f93..47872dccd0 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2894,7 +2894,17 @@ static int _get_page_type(struct page_info *page, unsigned long type, ((nx & PGT_type_mask) == PGT_writable_page)) ) { perfc_incr(need_flush_tlb_flush); - flush_tlb_mask(mask); + if ( (x & PGT_type_mask) && + (x & PGT_type_mask) <= PGT_root_page_table ) + /* + * If page was a page table make sure the flush is + * performed using an IPI in order to avoid changing + * the type of a page table page under the feet of + * spurious_page_fault. + */ + flush_tlb_mask_sync(mask); + else + flush_tlb_mask(mask); } /* We lose existing type and validity. */ diff --git a/xen/common/memory.c b/xen/common/memory.c index 714077c1e5..0d224d6675 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -278,7 +278,7 @@ static void populate_physmap(struct memop_args *a) out: if ( need_tlbflush ) - filtered_flush_tlb_mask(tlbflush_timestamp); + filtered_flush_tlb_mask(tlbflush_timestamp, false); if ( a->memflags & MEMF_no_icache_flush ) invalidate_icache(); diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 10b7aeca48..765f8d8e78 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1060,7 +1060,7 @@ static struct page_info *alloc_heap_pages( } if ( need_tlbflush ) - filtered_flush_tlb_mask(tlbflush_timestamp); + filtered_flush_tlb_mask(tlbflush_timestamp, true); return pg; } diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h index ab1aae5c90..7ae0543885 100644 --- a/xen/include/asm-arm/flushtlb.h +++ b/xen/include/asm-arm/flushtlb.h @@ -27,6 +27,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) /* Flush specified CPUs' TLBs */ void flush_tlb_mask(const cpumask_t *mask); +#define flush_tlb_mask_sync flush_tlb_mask /* * Flush a range of VA's hypervisor mappings from the TLB of the local diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h index 8639427cce..9e12844111 100644 --- a/xen/include/asm-x86/flushtlb.h +++ b/xen/include/asm-x86/flushtlb.h @@ -126,6 +126,16 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4); #else #define FLUSH_HVM_ASID_CORE 0 #endif +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING) +/* + * Force an IPI to be sent. Note that adding this to the flags passed to + * flush_area_mask will prevent using the assisted flush without having any + * other side effect. + */ +# define FLUSH_FORCE_IPI 0x8000 +#else +# define FLUSH_FORCE_IPI 0 +#endif /* Flush local TLBs/caches. */ unsigned int flush_area_local(const void *va, unsigned int flags); @@ -148,6 +158,14 @@ void flush_area_mask(const cpumask_t *, const void *va, unsigned int flags); /* Flush specified CPUs' TLBs */ #define flush_tlb_mask(mask) \ flush_mask(mask, FLUSH_TLB) +/* + * Flush specified CPUs' TLBs and force the usage of an IPI to do so. This is + * required for certain operations that rely on page tables themselves not + * being freed and reused when interrupts are blocked, as the flush IPI won't + * be fulfilled until exiting from that critical region. + */ +#define flush_tlb_mask_sync(mask) \ + flush_mask(mask, FLUSH_TLB | FLUSH_FORCE_IPI) #define flush_tlb_one_mask(mask,v) \ flush_area_mask(mask, (const void *)(v), FLUSH_TLB|FLUSH_ORDER(0)) diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 9b62087be1..f360166f00 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -639,7 +639,8 @@ static inline void accumulate_tlbflush(bool *need_tlbflush, } } -static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) +static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp, + bool sync) { cpumask_t mask; @@ -648,7 +649,10 @@ static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) if ( !cpumask_empty(&mask) ) { perfc_incr(need_flush_tlb_flush); - flush_tlb_mask(&mask); + if ( sync ) + flush_tlb_mask_sync(&mask); + else + flush_tlb_mask(&mask); } } -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Tue Jun 23 15:02:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 15:02:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkR5-00044O-VW; Tue, 23 Jun 2020 15:02:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkR5-00044J-B3 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 15:02:07 +0000 X-Inumbo-ID: 80a41418-b562-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 80a41418-b562-11ea-bca7-bc764e2007e4; Tue, 23 Jun 2020 15:02:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 05B5AAC12; Tue, 23 Jun 2020 15:02:05 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Roger Pau Monne References: <20200623135246.66170-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> Date: Tue, 23 Jun 2020 17:02:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623135246.66170-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23.06.2020 15:52, Roger Pau Monne wrote: > XENMEM_acquire_resource and it's related structure is currently inside > a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > hypervisor or the toolstack only. This is wrong as the hypercall is > already being used by the Linux kernel at least, and as such needs to > be public. > > Also switch the usage of uint64_aligned_t to plain uint64_t, as > uint64_aligned_t is only to be used by the toolstack. Note that the > layout of the structure will be the same, as the field is already > naturally aligned to a 8 byte boundary. I'm afraid it's more complicated, and hence ... > No functional change expected. ... this doesn't hold: As I notice only now the struct also wrongly (if it was meant to be a tools-only interface) failed to use XEN_GUEST_HANDLE_64(), which would in principle have been a problem for 32-bit callers (passing garbage in the upper half of a handle). It's not an actual problem because, unlike would typically be the case for tools-only interfaces, there is compat translation for this struct. With this, however, the problem of your change becomes noticeable: The structure's alignment for 32-bit x86, and with it the structure's sizeof(), both change. You should be able to see this by comparing xen/common/compat/memory.c's disassembly before and after your change - the number of bytes to copy by the respective copy_from_guest() ought to have changed. The question now is whether we're willing to accept such a (marginal) incompatibility. The chance of a 32-bit guest actually running into it shouldn't be very high, but with the right placement of an instance of the struct at the end of a page it would be possible to observe afaict. Or whether we go the alternative route and pad the struct suitably for 32-bit. > Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire guest resources') > Signed-off-by: Roger Pau Monné > --- > Would be good to get this fixed before the release in order to avoid > shipping bogus headers. Should also be backported. This was already part of 4.13, as you imply by requesting a backport. Hence the bogus header had already been shipped. > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -607,6 +607,8 @@ struct xen_reserved_device_memory_map { > typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t; > DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); > > +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ > + > /* > * Get the pages for a particular guest resource, so that they can be > * mapped directly by a tools domain. This comment is now stale. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 23 15:04:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 15:04:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkTq-0004DY-JE; Tue, 23 Jun 2020 15:04:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkTp-0004DS-Gl for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 15:04:57 +0000 X-Inumbo-ID: e5b54f20-b562-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e5b54f20-b562-11ea-bca7-bc764e2007e4; Tue, 23 Jun 2020 15:04:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9D609AE0E; Tue, 23 Jun 2020 15:04:54 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Roger Pau Monne References: <20200623135246.66170-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> Date: Tue, 23 Jun 2020 17:04:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623135246.66170-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23.06.2020 15:52, Roger Pau Monne wrote: > XENMEM_acquire_resource and it's related structure is currently inside > a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > hypervisor or the toolstack only. This is wrong as the hypercall is > already being used by the Linux kernel at least, and as such needs to > be public. Actually - how does this work for the Linux kernel, seeing rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); if ( rc ) return rc; rc = xsm_domain_resource_map(XSM_DM_PRIV, d); if ( rc ) goto out; in the function? Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 23 15:08:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 15:08:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkX0-0004S1-2H; Tue, 23 Jun 2020 15:08:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkWy-0004Rw-SD for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 15:08:12 +0000 X-Inumbo-ID: 5af3ab38-b563-11ea-bf99-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5af3ab38-b563-11ea-bf99-12813bfff9fa; Tue, 23 Jun 2020 15:08:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cPRmo1mTHJPuZL4boLttyAweNL6Vi593iEEQKc6eKl8=; b=A0yfbHsiogNj34NjOZdhmoILT1 tATf4CGtF2H85a+Z9bal3AGY0RCcKuKFZT2fw9ZFW6ZpKj3HEgfbVP76e2yORdz1o+HOtqiI82h8H Ll7VWsY5674ybwrE+XQnUoGYTjbPF357b9cV00NfMFZSeTc/VQSJjnpqD35pKfvTyU0k=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkWv-0006s2-6m; Tue, 23 Jun 2020 15:08:09 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnkWu-0004nd-W9; Tue, 23 Jun 2020 15:08:09 +0000 Subject: Re: [PATCH for-4.14 v2] x86/tlb: fix assisted flush usage To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20200623145006.66723-1-roger.pau@citrix.com> From: Julien Grall Message-ID: <741ff589-4366-1430-6639-13dc5f02fdfa@xen.org> Date: Tue, 23 Jun 2020 16:08:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623145006.66723-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Roger, On 23/06/2020 15:50, Roger Pau Monne wrote: > diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h > index 9b62087be1..f360166f00 100644 > --- a/xen/include/xen/mm.h > +++ b/xen/include/xen/mm.h > @@ -639,7 +639,8 @@ static inline void accumulate_tlbflush(bool *need_tlbflush, > } > } > > -static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) > +static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp, > + bool sync) I read the commit message and went through the code, but it is still not clear what "sync" means in a non-architectural way. As an Arm developper, I would assume this means we don't wait for the TLB flush to complete. But I am sure this would result to some unexpected behavior. So can you explain on non-x86 words what this really mean? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 23 15:15:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 15:15:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkeN-0005HU-Sf; Tue, 23 Jun 2020 15:15:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnkeN-0005HP-Cs for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 15:15:51 +0000 X-Inumbo-ID: 6bda982a-b564-11ea-bf9c-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6bda982a-b564-11ea-bf9c-12813bfff9fa; Tue, 23 Jun 2020 15:15:50 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: imf+8yrEZnrmNjn0kDn9noktt/xPRBYRPrTmXgyXBqcWXb7lf8KWD9AauBbSPIuy00dkUzouUM R08/Yh+irSFhFH2Dy+psZ5FmUf4gh9hU5lBg9gsOJOj/BCgBSDgq56ysSuKiSeT9VIEj5ka4Cm gPPfBuBqSsNyKkQG1imR1fIACyt4Sl2WIgwvKDPZ1cMAz5dByDDWbu/Md6bvsQAQL6lkW4TpOW uQYvcvW8F74Ej44anJi5BNVNXnB3tgCqfIRpf1mO/l2oJNLHnHyWiKmjy6qM90bH9Gh3c2sRR5 1Ls= X-SBRS: 2.7 X-MesageID: 20742011 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,271,1589256000"; d="scan'208";a="20742011" Date: Tue, 23 Jun 2020 17:15:42 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julien Grall Subject: Re: [PATCH for-4.14 v2] x86/tlb: fix assisted flush usage Message-ID: <20200623151542.GR735@Air-de-Roger> References: <20200623145006.66723-1-roger.pau@citrix.com> <741ff589-4366-1430-6639-13dc5f02fdfa@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <741ff589-4366-1430-6639-13dc5f02fdfa@xen.org> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 04:08:06PM +0100, Julien Grall wrote: > Hi Roger, > > On 23/06/2020 15:50, Roger Pau Monne wrote: > > diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h > > index 9b62087be1..f360166f00 100644 > > --- a/xen/include/xen/mm.h > > +++ b/xen/include/xen/mm.h > > @@ -639,7 +639,8 @@ static inline void accumulate_tlbflush(bool *need_tlbflush, > > } > > } > > -static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) > > +static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp, > > + bool sync) > > I read the commit message and went through the code, but it is still not > clear what "sync" means in a non-architectural way. > > As an Arm developper, I would assume this means we don't wait for the TLB > flush to complete. But I am sure this would result to some unexpected > behavior. No, when we return from filtered_flush_tlb_mask the flush has been performed (either with sync or without), but I understand the confusion given the parameter name. > So can you explain on non-x86 words what this really mean? sync (in this context) means to force the usage of an IPI (if built with PV or shadow paging support) in order to perform the flush. AFAICT on Arm you always avoid an IPI when performing a flush, and that's fine because you don't have PV or shadow, and then you don't require this. Also I'm not sure Arm has the concept of a spurious page fault. I could rename to force_ipi (or require_ipi) if that's better? Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 15:46:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 15:46:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnl89-00083V-Ae; Tue, 23 Jun 2020 15:46:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnl88-00083Q-1W for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 15:46:36 +0000 X-Inumbo-ID: b7903668-b568-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b7903668-b568-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 15:46:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=10fkYMFOBveJA9zTT6wsUzs7b/kffJbQ0JNTtZg9gEo=; b=rRM8xr07vemolnznjBxB9+ABEn cX0PGg3EB/qefJwZUXf1B4S9FQcf+rtnxLwY6cF2CNPcWUDjZRadKTkckz1KrXbYaQq/Ftf7CaGUK vyRTEyKEvZ5SwbhHXwdfB46yahr1PLcwCdjpk1K7/ctxUIA/iQcebvVXng4jMguXjR6k=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnl84-0007ZK-GJ; Tue, 23 Jun 2020 15:46:32 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnl84-0006Z1-9d; Tue, 23 Jun 2020 15:46:32 +0000 Subject: Re: [PATCH for-4.14 v2] x86/tlb: fix assisted flush usage To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623145006.66723-1-roger.pau@citrix.com> <741ff589-4366-1430-6639-13dc5f02fdfa@xen.org> <20200623151542.GR735@Air-de-Roger> From: Julien Grall Message-ID: Date: Tue, 23 Jun 2020 16:46:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623151542.GR735@Air-de-Roger> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23/06/2020 16:15, Roger Pau Monné wrote: > On Tue, Jun 23, 2020 at 04:08:06PM +0100, Julien Grall wrote: >> Hi Roger, >> >> On 23/06/2020 15:50, Roger Pau Monne wrote: >>> diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h >>> index 9b62087be1..f360166f00 100644 >>> --- a/xen/include/xen/mm.h >>> +++ b/xen/include/xen/mm.h >>> @@ -639,7 +639,8 @@ static inline void accumulate_tlbflush(bool *need_tlbflush, >>> } >>> } >>> -static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) >>> +static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp, >>> + bool sync) >> >> I read the commit message and went through the code, but it is still not >> clear what "sync" means in a non-architectural way. >> >> As an Arm developper, I would assume this means we don't wait for the TLB >> flush to complete. But I am sure this would result to some unexpected >> behavior. > > No, when we return from filtered_flush_tlb_mask the flush has been > performed (either with sync or without), but I understand the > confusion given the parameter name. > >> So can you explain on non-x86 words what this really mean? > > sync (in this context) means to force the usage of an IPI (if built > with PV or shadow paging support) in order to perform the flush. This is compare to? > AFAICT on Arm you always avoid an IPI when performing a flush, and > that's fine because you don't have PV or shadow, and then you don't > require this. Arm provides instructions to broadcast TLB flush, so by the time one of instruction is completed there is all the TLB entry associated to the translation doesn't exist. I don't think using PV or shadow would change anything here in the way we do the flush. > Also I'm not sure Arm has the concept of a spurious > page fault. So if I understand correctly, the HW may raise a fault even if the mapping was in the page-tables. Is it correct? We have a spurious page fault handler for stage-2 (aka EPT on x86) as we need to have an invalid mapping to transition for certain page-tables update (e.g. superpage shattering). We are using the same rwlock with the page fault handler and the page-table update, so there is no way the two can run concurrently. > > I could rename to force_ipi (or require_ipi) if that's better? Hmmm, based on what I wrote above, I don't think this name would be more suitable. However, regardless the name, it is not clear to me when a caller should use false or true. Have you considered a rwlock to synchronize the two? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 23 15:56:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 15:56:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnlHX-0000Xn-8r; Tue, 23 Jun 2020 15:56:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnlHW-0000Uu-7y for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 15:56:18 +0000 X-Inumbo-ID: 1266ca4c-b56a-11ea-b7bb-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1266ca4c-b56a-11ea-b7bb-bc764e2007e4; Tue, 23 Jun 2020 15:56:17 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ZrYUgC9oe99/cS3nlCxDl9xJgdVFXR0jbQjeP+4wYNVq+5IWhpnl5QyS/zezTklDnxzWl6qGRT j61uhY8DODaEea1kSElVPwgotru5tY87CVtLKKmcC1LvrMMfvwxnXbFtQZynQ4X0dVg38BokGT 4x4YLJUIxaltShzREDqe3R3tl2GdNXjdMSM3TQsDjRA+FV97xlGP37jbujHYSq6Ud1VgZU3Gm+ ajI7u91pdoyDppbZwk2dqtIfbONeAkn7cf/bqgteNjbA9kFLRRDcRnjs56M7pnuV/CcubrlKhW 4hM= X-SBRS: 2.7 X-MesageID: 20956298 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,271,1589256000"; d="scan'208";a="20956298" Date: Tue, 23 Jun 2020 17:56:09 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource Message-ID: <20200623155609.GS735@Air-de-Roger> References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 05:02:04PM +0200, Jan Beulich wrote: > On 23.06.2020 15:52, Roger Pau Monne wrote: > > XENMEM_acquire_resource and it's related structure is currently inside > > a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > > hypervisor or the toolstack only. This is wrong as the hypercall is > > already being used by the Linux kernel at least, and as such needs to > > be public. > > > > Also switch the usage of uint64_aligned_t to plain uint64_t, as > > uint64_aligned_t is only to be used by the toolstack. Note that the > > layout of the structure will be the same, as the field is already > > naturally aligned to a 8 byte boundary. > > I'm afraid it's more complicated, and hence ... > > > No functional change expected. > > ... this doesn't hold: As I notice only now the struct also wrongly > (if it was meant to be a tools-only interface) failed to use > XEN_GUEST_HANDLE_64(), which would in principle have been a problem > for 32-bit callers (passing garbage in the upper half of a handle). > It's not an actual problem because, unlike would typically be the > case for tools-only interfaces, there is compat translation for this > struct. Yes, there's already compat translation for the frame_list array. > With this, however, the problem of your change becomes noticeable: > The structure's alignment for 32-bit x86, and with it the structure's > sizeof(), both change. You should be able to see this by comparing > xen/common/compat/memory.c's disassembly before and after your > change - the number of bytes to copy by the respective > copy_from_guest() ought to have changed. Right, this is the layout with frame aligned to 8 bytes: struct xen_mem_acquire_resource { uint16_t domid; /* 0 2 */ uint16_t type; /* 2 2 */ uint32_t id; /* 4 4 */ uint32_t nr_frames; /* 8 4 */ uint32_t pad; /* 12 4 */ uint64_t frame; /* 16 8 */ long unsigned int * frame_list; /* 24 4 */ /* size: 32, cachelines: 1, members: 7 */ /* padding: 4 */ /* last cacheline: 32 bytes */ }; And this is without: struct xen_mem_acquire_resource { uint16_t domid; /* 0 2 */ uint16_t type; /* 2 2 */ uint32_t id; /* 4 4 */ uint32_t nr_frames; /* 8 4 */ uint32_t pad; /* 12 4 */ uint64_t frame; /* 16 8 */ long unsigned int * frame_list; /* 24 4 */ /* size: 28, cachelines: 1, members: 7 */ /* last cacheline: 28 bytes */ }; Note Xen has already been copying those extra 4 padding bytes from 32bit Linux kernels AFAICT, as the struct declaration in Linux has dropped the aligned attribute. > The question now is whether we're willing to accept such a (marginal) > incompatibility. The chance of a 32-bit guest actually running into > it shouldn't be very high, but with the right placement of an > instance of the struct at the end of a page it would be possible to > observe afaict. > > Or whether we go the alternative route and pad the struct suitably > for 32-bit. I guess we are trapped with what Linux has on it's headers now, so we should handle the struct size difference in Xen? I'm very tempted to just say switch the XEN_GUEST_HANDLE to XEN_GUEST_HANDLE_64, but I guess it's risky. I'm not sure how much people still run a toolstack from a 32bit domain however. > > Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire guest resources') > > Signed-off-by: Roger Pau Monné > > --- > > Would be good to get this fixed before the release in order to avoid > > shipping bogus headers. Should also be backported. > > This was already part of 4.13, as you imply by requesting a backport. > Hence the bogus header had already been shipped. Indeed. I would however try to prevent from shipping it in 4.14. > > --- a/xen/include/public/memory.h > > +++ b/xen/include/public/memory.h > > @@ -607,6 +607,8 @@ struct xen_reserved_device_memory_map { > > typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t; > > DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); > > > > +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ > > + > > /* > > * Get the pages for a particular guest resource, so that they can be > > * mapped directly by a tools domain. > > This comment is now stale. Hm, I'm not so sure. This is indeed used by Xen related tools (or emulators) and then those domains running such tools would also be tools domains? Anyway, I don't mind removing it, but I also don't think it's so off. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 16:17:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 16:17:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnlbQ-0002xe-Or; Tue, 23 Jun 2020 16:16:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnlbP-0002xY-M3 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 16:16:51 +0000 X-Inumbo-ID: f19edfcc-b56c-11ea-bfa7-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f19edfcc-b56c-11ea-bfa7-12813bfff9fa; Tue, 23 Jun 2020 16:16:50 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: h+kS0Md/dJ/O7jFwFjCqbFu92zkeLOY3Tdg1bcMcThuRkGf/ykPrACM+7IRmfMN7J+hx2kW+EK DsxtXDTTiit2RcYsHEPcI0CWGpMhEngebMwIZv92Ok6lOgtT71G/jNcpe2VrGhP+W5orsBm87X eyNG6MXuJvAvyJcYj/9hMqb+RWyG0oKqY5+sPD9YJ5EuggqaEMCYyOGledMnIW7wxh/WgDyuHM sgYcmLJ3UpQiVKwbnmu9oJGlnpuum/dYvOp5a7JITdUX0wX0oPJkNwvwJCcomaiQnJNc0NPmLL ymM= X-SBRS: 2.7 X-MesageID: 21536931 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,271,1589256000"; d="scan'208";a="21536931" Date: Tue, 23 Jun 2020 18:16:42 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julien Grall Subject: Re: [PATCH for-4.14 v2] x86/tlb: fix assisted flush usage Message-ID: <20200623161607.GT735@Air-de-Roger> References: <20200623145006.66723-1-roger.pau@citrix.com> <741ff589-4366-1430-6639-13dc5f02fdfa@xen.org> <20200623151542.GR735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 04:46:29PM +0100, Julien Grall wrote: > > > On 23/06/2020 16:15, Roger Pau Monné wrote: > > On Tue, Jun 23, 2020 at 04:08:06PM +0100, Julien Grall wrote: > > > Hi Roger, > > > > > > On 23/06/2020 15:50, Roger Pau Monne wrote: > > > > diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h > > > > index 9b62087be1..f360166f00 100644 > > > > --- a/xen/include/xen/mm.h > > > > +++ b/xen/include/xen/mm.h > > > > @@ -639,7 +639,8 @@ static inline void accumulate_tlbflush(bool *need_tlbflush, > > > > } > > > > } > > > > -static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) > > > > +static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp, > > > > + bool sync) > > > > > > I read the commit message and went through the code, but it is still not > > > clear what "sync" means in a non-architectural way. > > > > > > As an Arm developper, I would assume this means we don't wait for the TLB > > > flush to complete. But I am sure this would result to some unexpected > > > behavior. > > > > No, when we return from filtered_flush_tlb_mask the flush has been > > performed (either with sync or without), but I understand the > > confusion given the parameter name. > > > > > So can you explain on non-x86 words what this really mean? > > > > sync (in this context) means to force the usage of an IPI (if built > > with PV or shadow paging support) in order to perform the flush. > > This is compare to? Using assisted flushes, like you do on Arm, where you don't send an IPI in order to achieve a TLB flush on a remote pCPU. > > AFAICT on Arm you always avoid an IPI when performing a flush, and > > that's fine because you don't have PV or shadow, and then you don't > > require this. > > Arm provides instructions to broadcast TLB flush, so by the time one of > instruction is completed there is all the TLB entry associated to the > translation doesn't exist. > > I don't think using PV or shadow would change anything here in the way we do > the flush. TBH, I'm not sure how this applies to Arm. There's no PV or shadow implementation, so I have no idea whether this would apply or not. > > Also I'm not sure Arm has the concept of a spurious > > page fault. > > So if I understand correctly, the HW may raise a fault even if the mapping > was in the page-tables. Is it correct? Yes, this can happen when you promote the permission of a page table entry without doing a TLB flush AFAICT. Ie: you have a read-only page, which is promoted to writable, but you don't perform a TLB flush and just rely on getting a page fault that will clear the TLB entry and retry. > We have a spurious page fault handler for stage-2 (aka EPT on x86) as we > need to have an invalid mapping to transition for certain page-tables update > (e.g. superpage shattering). We are using the same rwlock with the page > fault handler and the page-table update, so there is no way the two can run > concurrently. This is slightly different as it's used by PV page tables, so the fault is triggered much more often than the fault handler you are referring to IMO. > > > > I could rename to force_ipi (or require_ipi) if that's better? > > Hmmm, based on what I wrote above, I don't think this name would be more > suitable. However, regardless the name, it is not clear to me when a caller > should use false or true. > > Have you considered a rwlock to synchronize the two? Yes, the performance drop is huge when I tried. I could try to refine, but I think there's always going to be a performance drop, as you then require mutual exclusion when modifying the page tables (you take the lock in write mode). Right now modification of the page tables can be done concurrently. FWIW Xen explicitly moved from using a lock into this model in 3203345bb13 apparently due to some deadlock situation. I'm not sure if that still holds. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 16:18:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 16:18:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnldR-00035R-9I; Tue, 23 Jun 2020 16:18:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnldP-00035J-Hc for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 16:18:55 +0000 X-Inumbo-ID: 3b3a84ce-b56d-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3b3a84ce-b56d-11ea-b7bb-bc764e2007e4; Tue, 23 Jun 2020 16:18:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 04F64AE54; Tue, 23 Jun 2020 16:18:53 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Tue, 23 Jun 2020 18:18:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623155609.GS735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23.06.2020 17:56, Roger Pau Monné wrote: > On Tue, Jun 23, 2020 at 05:02:04PM +0200, Jan Beulich wrote: >> On 23.06.2020 15:52, Roger Pau Monne wrote: >>> XENMEM_acquire_resource and it's related structure is currently inside >>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the >>> hypervisor or the toolstack only. This is wrong as the hypercall is >>> already being used by the Linux kernel at least, and as such needs to >>> be public. >>> >>> Also switch the usage of uint64_aligned_t to plain uint64_t, as >>> uint64_aligned_t is only to be used by the toolstack. Note that the >>> layout of the structure will be the same, as the field is already >>> naturally aligned to a 8 byte boundary. >> >> I'm afraid it's more complicated, and hence ... >> >>> No functional change expected. >> >> ... this doesn't hold: As I notice only now the struct also wrongly >> (if it was meant to be a tools-only interface) failed to use >> XEN_GUEST_HANDLE_64(), which would in principle have been a problem >> for 32-bit callers (passing garbage in the upper half of a handle). >> It's not an actual problem because, unlike would typically be the >> case for tools-only interfaces, there is compat translation for this >> struct. > > Yes, there's already compat translation for the frame_list array. > >> With this, however, the problem of your change becomes noticeable: >> The structure's alignment for 32-bit x86, and with it the structure's >> sizeof(), both change. You should be able to see this by comparing >> xen/common/compat/memory.c's disassembly before and after your >> change - the number of bytes to copy by the respective >> copy_from_guest() ought to have changed. > > Right, this is the layout with frame aligned to 8 bytes: > > struct xen_mem_acquire_resource { > uint16_t domid; /* 0 2 */ > uint16_t type; /* 2 2 */ > uint32_t id; /* 4 4 */ > uint32_t nr_frames; /* 8 4 */ > uint32_t pad; /* 12 4 */ > uint64_t frame; /* 16 8 */ > long unsigned int * frame_list; /* 24 4 */ > > /* size: 32, cachelines: 1, members: 7 */ > /* padding: 4 */ > /* last cacheline: 32 bytes */ > }; > > And this is without: > > struct xen_mem_acquire_resource { > uint16_t domid; /* 0 2 */ > uint16_t type; /* 2 2 */ > uint32_t id; /* 4 4 */ > uint32_t nr_frames; /* 8 4 */ > uint32_t pad; /* 12 4 */ > uint64_t frame; /* 16 8 */ > long unsigned int * frame_list; /* 24 4 */ > > /* size: 28, cachelines: 1, members: 7 */ > /* last cacheline: 28 bytes */ > }; > > Note Xen has already been copying those extra 4 padding bytes from > 32bit Linux kernels AFAICT, as the struct declaration in Linux has > dropped the aligned attribute. > >> The question now is whether we're willing to accept such a (marginal) >> incompatibility. The chance of a 32-bit guest actually running into >> it shouldn't be very high, but with the right placement of an >> instance of the struct at the end of a page it would be possible to >> observe afaict. >> >> Or whether we go the alternative route and pad the struct suitably >> for 32-bit. > > I guess we are trapped with what Linux has on it's headers now, so we > should handle the struct size difference in Xen? How do you mean to notice the difference in Xen? You don't know what the caller's environment's sizeof() would yield. > I'm very tempted to just say switch the XEN_GUEST_HANDLE to > XEN_GUEST_HANDLE_64, but I guess it's risky. Plus, like uint64_aligned_t, iirc it's a construct exposed through tool-stack-only interfaces, but not generally. >>> --- a/xen/include/public/memory.h >>> +++ b/xen/include/public/memory.h >>> @@ -607,6 +607,8 @@ struct xen_reserved_device_memory_map { >>> typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t; >>> DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); >>> >>> +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ >>> + >>> /* >>> * Get the pages for a particular guest resource, so that they can be >>> * mapped directly by a tools domain. >> >> This comment is now stale. > > Hm, I'm not so sure. This is indeed used by Xen related tools (or > emulators) and then those domains running such tools would also be > tools domains? > > Anyway, I don't mind removing it, but I also don't think it's so > off. Well - if this isn't a tool stack interface (see also my 2nd reply to your original patch), then the comment shouldn't suggest it is. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 23 16:32:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 16:32:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnlpy-0004jM-AO; Tue, 23 Jun 2020 16:31:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnlpw-0004j1-BD for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 16:31:52 +0000 X-Inumbo-ID: 071a9a88-b56f-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 071a9a88-b56f-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 16:31:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=evzt5fTDUfcQordr9/AgIsZaycZO/bj7OPZ3GSMkKd0=; b=mbUtMAw4RdusJ5eAEeMX0Km4A HFC2A8kDgNaP0c4Jafa37xsTBTQRPdJjuTHEGlcnP3sH8Vyu6K/J6GPxn4HiSSycw+JqTDD43ul8C gyvmW8nVuSw/LyszW72EZAdBOeYAoDypDZPwXpsLYv3B7auWTJE0jBMB8zaPkHX4hommE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnlpp-0000X3-2i; Tue, 23 Jun 2020 16:31:45 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnlpo-0007Kr-Og; Tue, 23 Jun 2020 16:31:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnlpo-0005Kr-N3; Tue, 23 Jun 2020 16:31:44 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151292: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=06760c2bf322cef4622b56bafee74fe93ae01630 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Tue, 23 Jun 2020 16:31:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151292 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151292/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 06760c2bf322cef4622b56bafee74fe93ae01630 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 40 days Failing since 150943 2020-06-09 17:06:00 Z 13 days 12 attempts Testing same since 151161 2020-06-15 22:27:38 Z 7 days 6 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 06760c2bf322cef4622b56bafee74fe93ae01630 Author: Andrew Cooper Date: Fri Jun 12 18:32:27 2020 +0100 tools/libxl: Fix memory leak in libxl_cpuid_set() xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to free() seeing as it discards the results. This is logically a backport of c/s b91825f628 "tools/libxc: Drop config_transformed parameter from xc_cpuid_set()" but rewritten as one caller of xc_cpuid_set() does use returned values. Signed-off-by: Andrew Cooper (cherry picked from commit c54de7d9df7718ea53bf21e1ff5bbd339602a704) commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 23 17:25:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 17:25:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnmf3-0000nH-Bk; Tue, 23 Jun 2020 17:24:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnmf1-0000nC-U1 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 17:24:39 +0000 X-Inumbo-ID: 6a359a30-b576-11ea-bca7-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6a359a30-b576-11ea-bca7-bc764e2007e4; Tue, 23 Jun 2020 17:24:38 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: qGqU+ORmdNNlrdaBALnYX+BZPBhA4kls0TSI1Zy93QGywZJt/F6XVRLVg3enf1km9xGGaxlKB/ HqTilHOlLKPY6sEABFHk7d5j6smghjXmk79ATGA4wrmo0xXmtwxSnXvlMOxllNk2AWQcArZ2D6 UazuAlkrpvPVhyppecjhGGH+C3f0Yy37ITKnP1HbKMeNREQUtcXnKRhPyeyMy5+YQdAc1Z/aCH l0v23xxGHI/plcqB3G+etuK35p2LPsx+3FdVdGXDFbYuD4spiWJ3K+FBN9glnCxMNR1mOn9sDq Rck= X-SBRS: 2.7 X-MesageID: 21544557 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,272,1589256000"; d="scan'208";a="21544557" Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: Jan Beulich , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> <901046162.11470361.1592874264410.JavaMail.zimbra@cert.pl> <32b7234b-dc64-a0ea-2c5c-448bcec44c34@suse.com> From: Andrew Cooper Message-ID: Date: Tue, 23 Jun 2020 18:24:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <32b7234b-dc64-a0ea-2c5c-448bcec44c34@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23/06/2020 09:51, Jan Beulich wrote: > On 23.06.2020 03:04, Michał Leszczyński wrote: >> ----- 22 cze 2020 o 18:16, Jan Beulich jbeulich@suse.com napisał(a): >> >>> On 22.06.2020 18:02, Michał Leszczyński wrote: >>>> ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisał(a): >>>>> On 22.06.2020 16:35, Michał Leszczyński wrote: >>>>>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisał(a): >>>>>>> Is any of what you do in this switch() actually legitimate without >>>>>>> hvm_set_vmtrace_pt_size() having got called for the guest? From >>>>>>> remarks elsewhere I imply you expect the param that you currently >>>>>>> use to be set upon domain creation time, but at the very least the >>>>>>> potentially big buffer should imo not get allocated up front, but >>>>>>> only when tracing is to actually be enabled. >>>>>> Wait... so you want to allocate these buffers in runtime? >>>>>> Previously we were talking that there is too much runtime logic >>>>>> and these enable/disable hypercalls should be stripped to absolute >>>>>> minimum. >>>>> Basic arrangements can be made at domain creation time. I don't >>>>> think though that it would be a good use of memory if you >>>>> allocated perhaps many gigabytes of memory just for possibly >>>>> wanting to enable tracing on a guest. >>>>> >>>> From our previous conversations I thought that you want to have >>>> as much logic moved to the domain creation as possible. >>>> >>>> Thus, a parameter "vmtrace_pt_size" was introduced. By default it's >>>> zero (= disabled), if you set it to a non-zero value, then trace buffers >>>> of given size will be allocated for the domain and you have possibility >>>> to use ipt_enable/ipt_disable at any moment. >>>> >>>> This way the runtime logic is as thin as possible. I assume user knows >>>> in advance whether he/she would want to use external monitoring with IPT >>>> or not. >>> Andrew - I think you requested movement to domain_create(). Could >>> you clarify if indeed you mean to also allocate the big buffers >>> this early? >> I would like to recall what Andrew wrote few days ago: >> >> ----- 16 cze 2020 o 22:16, Andrew Cooper andrew.cooper3@citrix.com wrote: >>> Xen has traditionally opted for a "and turn this extra thing on >>> dynamically" model, but this has caused no end of security issues and >>> broken corner cases. >>> >>> You can see this still existing in the difference between >>> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being >>> required to chose the number of vcpus for the domain) and we're making >>> good progress undoing this particular wart (before 4.13, it was >>> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by >>> issuing other hypercalls between these two). >>> >>> There is a lot of settings which should be immutable for the lifetime of >>> the domain, and external monitoring looks like another one of these. >>> Specifying it at createdomain time allows for far better runtime >>> behaviour (you are no longer in a situation where the first time you try >>> to turn tracing on, you end up with -ENOMEM because another VM booted in >>> the meantime and used the remaining memory), and it makes for rather >>> more simple code in Xen itself (at runtime, you can rely on it having >>> been set up properly, because a failure setting up will have killed the >>> domain already). >>> >>> ... >>> >>> ~Andrew >> according to this quote I've moved buffer allocation to the create_domain, >> the updated version was already sent to the list as patch v3. > I'd still like to see an explicit confirmation by him that this > use of memory is indeed what he has intended. There are much smaller > amounts of memory which we allocate on demand, just to avoid > allocating some without then ever using it. PT is a debug/diagnostic tool.  Its not something you'd run in production against a production VM. It's off by default (by virtue of having to explicitly ask to use it in the first place), and those who've asked for it don't want to be finding -ENOMEM after the domain has been running for a few seconds (or midway through the vcpus), when they inveterately want to map the rings. Those who request buffers in the first place and forget about them are not semantically different from those who ask for a silly shadow memory limit, or typo the guest memory and give it too much.  Its a admin error, not a safety/correctness issue. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 23 17:27:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 17:27:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnmhM-0000yp-QC; Tue, 23 Jun 2020 17:27:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnmhL-0000yk-1L for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 17:27:03 +0000 X-Inumbo-ID: bfa75832-b576-11ea-bb8b-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bfa75832-b576-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 17:27:01 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: QOJk8ArHs5azm1dSCwaWNDuXN00Cl8NwCNa064iX8LeVO08dlX3opI04EF/4ZuWp8kh0Sehf6I W9Nvq/T7bOcfPuLwhcuAc8nBmb49UHGLyIhnio649eXjWwZkLjVkc3dGvr9XMZlc/+djYuls1R 7aPwE89SK7L8U+LsaMGgOACZ5a4jabmhHaxn801rcNGVZCQ6oap6Xbrqb6FD0iY9l28a1JiL3g zs0RxzpahEvLGxPTLLcJneU7BtzYoSAeaq784qXeZ/NfFHgzhaUhP7dlD9lI7zYG8XfTfoa7bI tm0= X-SBRS: 2.7 X-MesageID: 21544775 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,272,1589256000"; d="scan'208";a="21544775" Date: Tue, 23 Jun 2020 19:26:52 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource Message-ID: <20200623172652.GU735@Air-de-Roger> References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 06:18:52PM +0200, Jan Beulich wrote: > On 23.06.2020 17:56, Roger Pau Monné wrote: > > On Tue, Jun 23, 2020 at 05:02:04PM +0200, Jan Beulich wrote: > >> On 23.06.2020 15:52, Roger Pau Monne wrote: > >>> XENMEM_acquire_resource and it's related structure is currently inside > >>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > >>> hypervisor or the toolstack only. This is wrong as the hypercall is > >>> already being used by the Linux kernel at least, and as such needs to > >>> be public. > >>> > >>> Also switch the usage of uint64_aligned_t to plain uint64_t, as > >>> uint64_aligned_t is only to be used by the toolstack. Note that the > >>> layout of the structure will be the same, as the field is already > >>> naturally aligned to a 8 byte boundary. > >> > >> I'm afraid it's more complicated, and hence ... > >> > >>> No functional change expected. > >> > >> ... this doesn't hold: As I notice only now the struct also wrongly > >> (if it was meant to be a tools-only interface) failed to use > >> XEN_GUEST_HANDLE_64(), which would in principle have been a problem > >> for 32-bit callers (passing garbage in the upper half of a handle). > >> It's not an actual problem because, unlike would typically be the > >> case for tools-only interfaces, there is compat translation for this > >> struct. > > > > Yes, there's already compat translation for the frame_list array. > > > >> With this, however, the problem of your change becomes noticeable: > >> The structure's alignment for 32-bit x86, and with it the structure's > >> sizeof(), both change. You should be able to see this by comparing > >> xen/common/compat/memory.c's disassembly before and after your > >> change - the number of bytes to copy by the respective > >> copy_from_guest() ought to have changed. > > > > Right, this is the layout with frame aligned to 8 bytes: > > > > struct xen_mem_acquire_resource { > > uint16_t domid; /* 0 2 */ > > uint16_t type; /* 2 2 */ > > uint32_t id; /* 4 4 */ > > uint32_t nr_frames; /* 8 4 */ > > uint32_t pad; /* 12 4 */ > > uint64_t frame; /* 16 8 */ > > long unsigned int * frame_list; /* 24 4 */ > > > > /* size: 32, cachelines: 1, members: 7 */ > > /* padding: 4 */ > > /* last cacheline: 32 bytes */ > > }; > > > > And this is without: > > > > struct xen_mem_acquire_resource { > > uint16_t domid; /* 0 2 */ > > uint16_t type; /* 2 2 */ > > uint32_t id; /* 4 4 */ > > uint32_t nr_frames; /* 8 4 */ > > uint32_t pad; /* 12 4 */ > > uint64_t frame; /* 16 8 */ > > long unsigned int * frame_list; /* 24 4 */ > > > > /* size: 28, cachelines: 1, members: 7 */ > > /* last cacheline: 28 bytes */ > > }; > > > > Note Xen has already been copying those extra 4 padding bytes from > > 32bit Linux kernels AFAICT, as the struct declaration in Linux has > > dropped the aligned attribute. > > > >> The question now is whether we're willing to accept such a (marginal) > >> incompatibility. The chance of a 32-bit guest actually running into > >> it shouldn't be very high, but with the right placement of an > >> instance of the struct at the end of a page it would be possible to > >> observe afaict. > >> > >> Or whether we go the alternative route and pad the struct suitably > >> for 32-bit. > > > > I guess we are trapped with what Linux has on it's headers now, so we > > should handle the struct size difference in Xen? > > How do you mean to notice the difference in Xen? You don't know > what the caller's environment's sizeof() would yield. I'm confused. Couldn't we switch from uint64_aligned_t to plain uint64_t (like it's currently on the Linux headers), and then use the compat layer in Xen to handle the size difference when called from 32bit environments? This would of course assume that no toolstack has implemented direct calls using this interface, which seems likely because it either returns mfns to be mapped in the PV case or require gfns to be provided for HVM. > > I'm very tempted to just say switch the XEN_GUEST_HANDLE to > > XEN_GUEST_HANDLE_64, but I guess it's risky. > > Plus, like uint64_aligned_t, iirc it's a construct exposed through > tool-stack-only interfaces, but not generally. Ack. > >>> --- a/xen/include/public/memory.h > >>> +++ b/xen/include/public/memory.h > >>> @@ -607,6 +607,8 @@ struct xen_reserved_device_memory_map { > >>> typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t; > >>> DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); > >>> > >>> +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ > >>> + > >>> /* > >>> * Get the pages for a particular guest resource, so that they can be > >>> * mapped directly by a tools domain. > >> > >> This comment is now stale. > > > > Hm, I'm not so sure. This is indeed used by Xen related tools (or > > emulators) and then those domains running such tools would also be > > tools domains? > > > > Anyway, I don't mind removing it, but I also don't think it's so > > off. > > Well - if this isn't a tool stack interface (see also my 2nd reply > to your original patch), then the comment shouldn't suggest it is. OK, let me take a look. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 17:32:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 17:32:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnmmq-0001p4-Et; Tue, 23 Jun 2020 17:32:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnmmp-0001oz-9b for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 17:32:43 +0000 X-Inumbo-ID: 8a53e80d-b577-11ea-bfc5-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8a53e80d-b577-11ea-bfc5-12813bfff9fa; Tue, 23 Jun 2020 17:32:42 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: KMqMGmiijij0OIAJMqHUOsU3FlHQIXg/ANNSXcGBJplcIpnAyFM/ThPUrvIn/X9HhLqGp0JN9Y z5IaRkDA0ScHIYV3UB7bqCyGdvtaKTYVsXCS1303S1xMBXkb8sQfS1ynl5y5Kmz2sHK2XMfSb+ AnTFue4mt52suyr7H665iBGC/Z2j95FfmFdcMiEiVgvblQ7li+Icc7/v98LyRnGmRpZX2MQC8f 3jdFRgo37F6FpoAHWocp8HeYcyNIVjhgQKofLhAzPcr5JZ1gyal27HCmbp7s3piRdlX5iFF2WM ivQ= X-SBRS: 2.7 X-MesageID: 21051973 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,272,1589256000"; d="scan'208";a="21051973" Date: Tue, 23 Jun 2020 19:32:34 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource Message-ID: <20200623173150.GV735@Air-de-Roger> References: <20200623135246.66170-1-roger.pau@citrix.com> <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote: > On 23.06.2020 15:52, Roger Pau Monne wrote: > > XENMEM_acquire_resource and it's related structure is currently inside > > a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > > hypervisor or the toolstack only. This is wrong as the hypercall is > > already being used by the Linux kernel at least, and as such needs to > > be public. > > Actually - how does this work for the Linux kernel, seeing > > rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); > if ( rc ) > return rc; > > rc = xsm_domain_resource_map(XSM_DM_PRIV, d); > if ( rc ) > goto out; > > in the function? It's my understanding (I haven't tried to use that hypercall yet on FreeBSD, so I cannot say I've tested it), that xmar.domid is the remote domain, which the functions locks and then uses xsm_domain_resource_map to check whether the current domain has permissions to do privileged operations against it. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 17:41:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 17:41:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnmvY-0002l5-Bb; Tue, 23 Jun 2020 17:41:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnmvW-0002l0-TV for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 17:41:42 +0000 X-Inumbo-ID: cba5eab7-b578-11ea-bfc6-12813bfff9fa Received: from userp2130.oracle.com (unknown [156.151.31.86]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cba5eab7-b578-11ea-bfc6-12813bfff9fa; Tue, 23 Jun 2020 17:41:41 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05NHMZjH015017; Tue, 23 Jun 2020 17:41:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=01fOHNPSwBjJzaf1P4ANrSZ8Ny4TlenXhzftmFd9g2g=; b=bkVSOuX30qAbfW7g3HvLuMU7Ad7ZK3klyHd2us52MT9T7CqCn+Rcvu6UsYQWLHvmFfHc NPSvyxic+lNg8dWMv2869qYiQsevVm9alH5rGdrL9NnvEQfB/rqPeGNvYOh3lHMxvCAR 8Q0q6YqQLc0FRy0g+6JkpanL2OORvIgNpkq8mLNm6JTKBg4zm7Prq3EF9IRgFHqVR3Rw WFiR5u/xuvUXvzR9h3UkmPL6WdpUSSifSc5wrsgc8UKsXjqDjKSf/9AIteBmin9VywLq UW4DOGhPCCP49YRH2ZXKZMie6j3upeVh3om3I0/d49dvlCT/LxK7iVzB6FlIdGn+YTtm 5A== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 31uk2rs9qv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 23 Jun 2020 17:41:39 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05NHNihx036985; Tue, 23 Jun 2020 17:41:38 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 31uk3chd01-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Jun 2020 17:41:38 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 05NHfaD7023654; Tue, 23 Jun 2020 17:41:36 GMT Received: from [10.39.252.55] (/10.39.252.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Jun 2020 17:41:36 +0000 Subject: Re: [RFC PATCH v2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Souptick Joarder , jgross@suse.com, sstabellini@kernel.org References: <1592913499-15558-1-git-send-email-jrdr.linux@gmail.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: Date: Tue, 23 Jun 2020 13:41:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1592913499-15558-1-git-send-email-jrdr.linux@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9661 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 phishscore=0 suspectscore=0 bulkscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006120000 definitions=main-2006230123 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9661 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 phishscore=0 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 bulkscore=0 mlxscore=0 spamscore=0 clxscore=1015 suspectscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006120000 definitions=main-2006230123 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, John Hubbard Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/23/20 7:58 AM, Souptick Joarder wrote: > In 2019, we introduced pin_user_pages*() and now we are converting > get_user_pages*() to the new API as appropriate. [1] & [2] could > be referred for more information. This is case 5 as per document [1]. > > As discussed, pages need to be marked as dirty before unpinned it. > > Previously, if lock_pages() end up partially mapping pages, it used > to return -ERRNO due to which unlock_pages() have to go through > each pages[i] till *nr_pages* to validate them. This can be avoided > by passing correct number partially mapped pages & -ERRNO separately > while returning from lock_pages() due to error. > With this fix unlock_pages() doesn't need to validate pages[i] till > *nr_pages* for error scenario. This should be split into two patches please. The first one will fix the return value bug (and will need to go to stable branches) and the second will use new routine to pin pages. > @@ -580,25 +580,30 @@ static long privcmd_ioctl_mmap_batch( > =20 > static int lock_pages( > struct privcmd_dm_op_buf kbufs[], unsigned int num, > - struct page *pages[], unsigned int nr_pages) > + struct page *pages[], unsigned int nr_pages, int *errno) I'd prefer if you used more traditional way of returning error code by the function, and pass the number of pinned pages as an argument. This will also make call site simpler. -boris From xen-devel-bounces@lists.xenproject.org Tue Jun 23 18:32:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 18:32:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnnin-0007F7-9a; Tue, 23 Jun 2020 18:32:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnnil-0007F2-Sy for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 18:32:35 +0000 X-Inumbo-ID: e7265b20-b57f-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e7265b20-b57f-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 18:32:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=v6R3whNgIdIPkuXSH7Jf9xL+8xKahZlSBDZ4rltXnh4=; b=sky0t8REiFnv6opXm6nb17Zc/ EM+bDS2gu6ganfpdPgmFLh6wlnzxfe/KG9U/dIzhewoB+dZ2EfZ1LWVI5usCain69xmoOML6H2Pqf apMbyQg4nRQ1uacL6inrUWkShvUDHE0g0wZx3IGR/B6HXN3N216j4RBV0yQmeJPe8hSQM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnnii-0002pA-N8; Tue, 23 Jun 2020 18:32:32 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnnii-0004bO-DB; Tue, 23 Jun 2020 18:32:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnnii-0006Ft-CP; Tue, 23 Jun 2020 18:32:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151295: regressions - FAIL X-Osstest-Failures: xen-4.11-testing:build-amd64-prev:xen-build:fail:regression xen-4.11-testing:build-i386-prev:xen-build:fail:regression xen-4.11-testing:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-4.11-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Tue, 23 Jun 2020 18:32:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151295 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151295/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-prev 6 xen-build fail in 151260 REGR. vs. 150040 build-i386-prev 6 xen-build fail in 151260 REGR. vs. 150040 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 151260 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked in 151260 n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked in 151260 n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 49 days Failing since 150942 2020-06-09 17:05:43 Z 14 days 14 attempts Testing same since 151061 2020-06-12 12:25:05 Z 11 days 9 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 2b77729888fb851ab96e7f77bc854122626b4861 Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 9be79927a6395f12c9e24afaccf6acbaf81d402e Author: Christopher Clark Date: Wed Jul 18 15:22:17 2018 -0700 tools/xentop : replace use of deprecated vwprintw gcc-8.1 complains: | xentop.c: In function 'print': | xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations] | vwprintw(stdscr, (curses_str_t)fmt, args); | ^~~~~~~~ vw_printw (note the underscore) is a non-deprecated alternative. Signed-off-by: Christopher Clark Acked-by: Wei Liu (cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62) commit b8d476a9eaee8877cd5ba2c9eb6dbc5412626d13 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 1c751c4146b9e1d8dd9b61ee6a01caa1b07463cc Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Tue Jun 23 20:51:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 20:51:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnpse-0002fe-GN; Tue, 23 Jun 2020 20:50:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnpsd-0002fZ-H0 for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 20:50:55 +0000 X-Inumbo-ID: 3a9ff262-b593-11ea-8496-bc764e2007e4 Received: from mail-ej1-x641.google.com (unknown [2a00:1450:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3a9ff262-b593-11ea-8496-bc764e2007e4; Tue, 23 Jun 2020 20:50:54 +0000 (UTC) Received: by mail-ej1-x641.google.com with SMTP id rk21so171087ejb.2 for ; Tue, 23 Jun 2020 13:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=olXzDIxg7DPSTwRADY40Q7k7wanWon/Ex1VZ+Ph7Lx8=; b=e2GvLRtgoPlq8bHrPoeTlRstt/S/Y0E2unfvKi56j1k+ojEHIRQP9A6+RhMVp1e0eE 3mSt/5OC5grQpFzT/osGXWfWSV78RUujdL47ACQEyae4Nyh7H7d/H/WHI6lBLh3wjt6F t11ynqBfHhO3ByTvWPa3UBqipDajSm8kOxnkGtwpyfukNBtD1WG0quosvT0UWHIGcnVP KhOF5+eVgXRIWPrgJZ9gJwv3YoMM6RjIigWq2b2u6GlsMlYPx8u/ydfNivGQvUeIxqPB uKJrqzeVVicVgpa3EoulvCKYhQduNTg+EXWv4aNo4zQ0gIQNUQRNb7L8tc5qB71vrhkj Om5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=olXzDIxg7DPSTwRADY40Q7k7wanWon/Ex1VZ+Ph7Lx8=; b=EM2puSt61pKy73fKAyDiCU+H47w5QGAeCpXS8EwpzkVb9BgeQAVtuMHZsfl+7eQUyr hK5pzK/T5U1v8XIKh/iBxOD6+eI1ZSsqRl1jTL7dLMcQqxYhtCoKEupJ2L2BNjYdmfeT Q7SU+iHThNzU33KP/1EUxqbkKdxPbxHE2AVsJubmEWveE4NM/PpWI3TyMB95CqnMX7+L 43npz/1djqEiAZvS+V5+hba0LtMJvkcf2Wyvb7yDE9rSWbiiAbkH4nerKBDwyTf6i5LN F7PvBaFre1e/pzyhO70qVXeG7OXqYvHuac47cMWBFbwX2/V0ShuawvgtDQPZ5kIBgocE pnvA== X-Gm-Message-State: AOAM530fW27lpHI4YnhcgCy6CUJdP8Wzo5SRE88DhaZenoLs6tA+7kU3 ZES7j3xDw8sGmZxS/zTAKKBzaF5BR1ORYXlV0XY= X-Google-Smtp-Source: ABdhPJy6hQP9zD6hUHx84zELkM+HK8eOOExLoE+eFi/D9IG4BGoapdT40RSIgxXLbc5Fiwq5W7SysAT1GQoPN7Nq9SI= X-Received: by 2002:a17:906:848b:: with SMTP id m11mr6086294ejx.10.1592945453219; Tue, 23 Jun 2020 13:50:53 -0700 (PDT) MIME-Version: 1.0 References: <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> In-Reply-To: From: CodeWiz2280 Date: Tue, 23 Jun 2020 16:50:37 -0400 Message-ID: Subject: Re: Keystone Issue To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , nd , Bertrand Marquis , xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Is it possible to passthrough PCI devices to domU on the 32-bit arm keystone? Any info is appreciated. I found some old information online that "gic-v2m" is required. I'm not sure if the GIC-400 on the K2E supports "gic_v2m". Based on the fact that there is no "gic-v2m-frame" tag in the K2E device tree i'm guessing that it does not. If it is possible, is there a good example for arm that I can follow? On Wed, Jun 17, 2020 at 7:52 PM CodeWiz2280 wrote: > > On Wed, Jun 17, 2020 at 2:46 PM Stefano Stabellini > wrote: > > > > On Wed, 17 Jun 2020, CodeWiz2280 wrote: > > > On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote: > > > > > > > > On 2020-06-16 19:13, CodeWiz2280 wrote: > > > > > On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: > > > > >> > > > > >> On 2020-06-15 20:14, CodeWiz2280 wrote: > > > > >> > > > > >> [...] > > > > >> > > > > >> > Also, the latest linux kernel still has the X-Gene storm distributor > > > > >> > address as "0x78010000" in the device tree, which is what the Xen code > > > > >> > considers a match with the old firmware. What were the addresses for > > > > >> > the device tree supposed to be changed to? > > > > >> > > > > >> We usually don't care, as the GIC address is provided by the > > > > >> bootloader, > > > > >> whether via DT or ACPI (this is certainly what happens on Mustang). > > > > >> Whatever is still in the kernel tree is just as dead as the platform > > > > >> it > > > > >> describes. > > > > >> > > > > >> > Is my understanding > > > > >> > correct that there is a different base address required to access the > > > > >> > "non-secure" region instead of the "secure" 0x78010000 region? I'm > > > > >> > trying to see if there are corresponding different addresses for the > > > > >> > keystone K2E, but haven't found them yet in the manuals. > > > > >> > > > > >> There is no such address. Think of the NS bit as an *address space* > > > > >> identifier. > > > > >> > > > > >> The only reason XGene presents the NS part of the GIC at a different > > > > >> address is because XGene is broken enough not to have EL3, hence no > > > > >> secure mode. To wire the GIC (and other standard ARM IPs) to the core, > > > > >> the designers simply used the CPU NS signal as an address bit. > > > > >> > > > > >> On your platform, the NS bit does exist. I strongly suppose that it > > > > >> isn't wired to the GIC. Please talk to your SoC vendor for whether iot > > > > >> is possible to work around this. > > > > >> > > > > > I do have a question about this out to TI, but at least this method > > > > > gives me something to work with in the meantime. I was just looking > > > > > to confirm that there wouldn't be any other undesirable side effects > > > > > with Dom0 or DomU when using it. Was there an actual FPGA for the > > > > > X-Gene that needed to be updated which controlled the GIC access? Or > > > > > by firmware do you mean the boot loader (e.g. uboot). Thanks for the > > > > > support so far to all. > > > > > > > > As I said, the specific case of XGene was just a matter of picking the > > > > right address, as the NS bit is used as an address bit on this platform. > > > > This was possible because this machine doesn't have any form of > > > > security. So no HW was changed, no FPGA reprogrammed. Only a firmware > > > > table was fixed to point to the right spot. Not even u-boot or EFI was > > > > changed. > > > Ok, thank you for clarifying. I have one more question if you don't > > > mind. I'm aware that dom0 can share physical memory with dom1 via > > > grant tables. > > > However, is it possible to reserve a chunk of contiguous physical > > > memory and directly allocate it only to dom1? > > > For example, if I wanted dom1 to have access to 8MB of contiguous > > > memory at 0x8200_0000 (in addition to whatever virtual memory Xen > > > gives it). > > > How would one go about doing this on ARM? Is there something in the > > > guest config or device tree that can be set? Thanks for you help. > > > > There isn't a "proper" way to do it, only a workaround. > > > > It is possible to do it by using the iomem option, which is meant for > > device MMIO regions. > > > > We have patches in the Xilinx Xen tree (not upstream) to allow for > > specifying the cacheability that you want for the iomem mapping so that > > you can map it as normal memory. This is the latest branch: > > > > https://github.com/Xilinx/xen.git xilinx/release-2020.1 > > > > The relevant commits are the ones from: > > https://github.com/Xilinx/xen/commit/a5c76ac1c5dc14d3e9ccedc5c1e7dd2ddc1397b6 > > to: > > https://github.com/Xilinx/xen/commit/b4b7e91c1524f9cf530b81b7ba95df2bf50c78e4 > > > > You might want to make sure that the page is not used by the normal > > memory allocator. This document explains how to something along those > > lines: > > > > https://github.com/Xilinx/xen/commit/35f72d9130448272e07466bd73cc30406f33135e > > Thank you. I appreciate it. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 21:09:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 21:09:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnqAl-0003rL-4C; Tue, 23 Jun 2020 21:09:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnqAk-0003rG-DM for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 21:09:38 +0000 X-Inumbo-ID: d87a9ac6-b595-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d87a9ac6-b595-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 21:09:37 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EBBB320702; Tue, 23 Jun 2020 21:09:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592946577; bh=7hujf2lotec8Cu1SgpMN9oVDoN3aKH0nMa9Mcnr1Hqg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=A9joj/6XnubA5K4QmAxR8Krh6IeCkNViU+b/F5tKdtsnEMB5JZS8VoFAI2jCfLqoT Qv6TMmrUwVGMoi97vqFvKyPFIc5FAz09bqhAsicW56ejpIf1CE/EzsfU+EsgjnO4ml LM41Xp1zGRNyQwga/jtq0z3jN1Tq68Q+WelhZAaA= Date: Tue, 23 Jun 2020 14:09:36 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address In-Reply-To: <2df789f3-e881-36a3-51f4-010b499990f5@xen.org> Message-ID: References: <20200619223332.438344-1-volodymyr_babchuk@epam.com> <20200619223332.438344-3-volodymyr_babchuk@epam.com> <87ftampkd7.fsf@epam.com> <2df789f3-e881-36a3-51f4-010b499990f5@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "pdurrant@amazon.com" , Stefano Stabellini , Volodymyr Babchuk , "op-tee@lists.trustedfirmware.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, 23 Jun 2020, Julien Grall wrote: > On 23/06/2020 03:49, Volodymyr Babchuk wrote: > > > > Hi Stefano, > > > > Stefano Stabellini writes: > > > > > On Fri, 19 Jun 2020, Volodymyr Babchuk wrote: > > > > Trusted Applications use popular approach to determine required size > > > > of buffer: client provides a memory reference with the NULL pointer to > > > > a buffer. This is so called "Null memory reference". TA updates the > > > > reference with the required size and returns it back to the > > > > client. Then client allocates buffer of needed size and repeats the > > > > operation. > > > > > > > > This behavior is described in TEE Client API Specification, paragraph > > > > 3.2.5. Memory References. > > > > > > > > OP-TEE represents this null memory reference as a TMEM parameter with > > > > buf_ptr = 0x0. This is the only case when we should allow TMEM > > > > buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. This also the > > > > special case for a buffer with OPTEE_MSG_ATTR_NONCONTIG flag. > > > > > > > > This could lead to a potential issue, because IPA 0x0 is a valid > > > > address, but OP-TEE will treat it as a special case. So, care should > > > > be taken when construction OP-TEE enabled guest to make sure that such > > > > guest have no memory at IPA 0x0 and none of its memory is mapped at PA > > > > 0x0. > > > > > > > > Signed-off-by: Volodymyr Babchuk > > > > --- > > > > > > > > Changes from v1: > > > > - Added comment with TODO about possible PA/IPA 0x0 issue > > > > - The same is described in the commit message > > > > - Added check in translate_noncontig() for the NULL ptr buffer > > > > > > > > --- > > > > xen/arch/arm/tee/optee.c | 27 ++++++++++++++++++++++++--- > > > > 1 file changed, 24 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > > > > index 6963238056..70bfef7e5f 100644 > > > > --- a/xen/arch/arm/tee/optee.c > > > > +++ b/xen/arch/arm/tee/optee.c > > > > @@ -215,6 +215,15 @@ static bool optee_probe(void) > > > > return true; > > > > } > > > > +/* > > > > + * TODO: There is a potential issue with guests that either have RAM > > > > + * at IPA of 0x0 or some of theirs memory is mapped at PA 0x0. This is > > > ^ their > > > > > > > + * because PA of 0x0 is considered as NULL pointer by OP-TEE. It will > > > > + * not be able to map buffer with such pointer to TA address space, or > > > > + * use such buffer for communication with the guest. We either need to > > > > + * check that guest have no such mappings or ensure that OP-TEE > > > > + * enabled guest will not be created with such mappings. > > > > + */ > > > > static int optee_domain_init(struct domain *d) > > > > { > > > > struct arm_smccc_res resp; > > > > @@ -725,6 +734,15 @@ static int translate_noncontig(struct optee_domain > > > > *ctx, > > > > uint64_t next_page_data; > > > > } *guest_data, *xen_data; > > > > + /* > > > > + * Special case: buffer with buf_ptr == 0x0 is considered as NULL > > > > + * pointer by OP-TEE. No translation is needed. This can lead to > > > > + * an issue as IPA 0x0 is a valid address for Xen. See the comment > > > > + * near optee_domain_init() > > > > + */ > > > > + if ( !param->u.tmem.buf_ptr ) > > > > + return 0; > > > > > > Given that today it is not possible for this to happen, it could even be > > > an ASSERT. But I think I would just return an error, maybe -EINVAL? > > > > Hmm, looks like my comment is somewhat misleading :( > > How about the following comment: > > We don't want to translate NULL (0) as it can be used by the guest to fetch > the size of the buffer to allocate. This behavior depends on TA, but there is > a guarantee that OP-TEE will not try to map it (see more details on top of > optee_domain_init()). > > > > > What I mean, is that param->u.tmem.buf_ptr == 0 is the normal situation. > > This is the special case, when OP-TEE treats this buffer as a NULL. So > > we are doing nothing there. Thus, "return 0". > > > > But, as Julien pointed out, we can have machine where 0x0 is the valid > > memory address and there is a chance, that some guest will use it as a > > pointer to buffer. > > > > > Aside from this, and the small grammar issue, everything else looks fine > > > to me. > > > > > > Let's wait for Julien's reply, but if this is the only thing I could fix > > > on commit. > > I agree with Volodymyr, this is the normal case here. There are more work to > prevent MFN 0 to be mapped in the guest but this shouldn't be an issue today. Let's put the MFN 0 issue aside for a moment. >From the commit message I thought that if the guest wanted to pass a NULL buffer ("Null memory reference") then it would also *not* set OPTEE_MSG_ATTR_NONCONTIG, which would be handled by the "else" statement also modified by this patch. Thus, I thought that reaching translate_noncontig with buf_ptr == NULL would always be an error. But re-reading the commit message and from both your answers it is not the case: a "Null memory reference" is allowed with OPTEE_MSG_ATTR_NONCONTIG set too. Thus, I have no further comments and the improvements on the in-code comment could be done on commit. From xen-devel-bounces@lists.xenproject.org Tue Jun 23 21:45:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 21:45:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnqjF-0007GT-VU; Tue, 23 Jun 2020 21:45:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnqjE-0007G7-CZ for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 21:45:16 +0000 X-Inumbo-ID: cfd25206-b59a-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cfd25206-b59a-11ea-bca7-bc764e2007e4; Tue, 23 Jun 2020 21:45:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/YI22NJpL2tV0QxO2pUEimfW+NZ+YOIwloLd77lMeV0=; b=nfhViENgoH5EylO2dSrfv3CYc faZpXwm9vTIyL2rKlns9vumtR3jrmSqsHUdX8jRFlJ0pDm1I5I0JMwJ57mlvYX/bwOMW9jyAQifFR 0MuNV9FcnW1MX0ZrVRA+61QHeFPMBOJqRxAK3gJ8Sv7A6/obLwbvmwLM3OuA7/pSVpJOc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnqj8-0006PP-6g; Tue, 23 Jun 2020 21:45:10 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnqj7-0006Qa-V7; Tue, 23 Jun 2020 21:45:10 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnqj7-0007ah-UV; Tue, 23 Jun 2020 21:45:09 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151303: all pass - PUSHED X-Osstest-Versions-This: ovmf=00b8bf7eda00fb6f0197d3968b6078cfdb4870fa X-Osstest-Versions-That: ovmf=322969adf1fb3d6cfbd613f35121315715aff2ed From: osstest service owner Date: Tue, 23 Jun 2020 21:45:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151303 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151303/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 00b8bf7eda00fb6f0197d3968b6078cfdb4870fa baseline version: ovmf 322969adf1fb3d6cfbd613f35121315715aff2ed Last test of basis 151249 2020-06-20 09:21:45 Z 3 days Testing same since 151303 2020-06-23 01:55:28 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Cole, Deric Deric Cole jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 322969adf1..00b8bf7eda 00b8bf7eda00fb6f0197d3968b6078cfdb4870fa -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Tue Jun 23 23:00:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 23 Jun 2020 23:00:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnrtV-0005BN-Kj; Tue, 23 Jun 2020 22:59:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnrtT-0005BI-Mw for xen-devel@lists.xenproject.org; Tue, 23 Jun 2020 22:59:55 +0000 X-Inumbo-ID: 40b6155c-b5a5-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 40b6155c-b5a5-11ea-bb8b-bc764e2007e4; Tue, 23 Jun 2020 22:59:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ucWI/h8qysrBMkmF1Xw45oFXgkc2cq3oKoy8b+N2iU4=; b=fcJR0C4H5MpKO8z+QOUHwHht/ P382L+k8SaKJ98SZbLI3uBXpwZf79b51vzB4CfDHyYl6+Bm4NVQPTnPp4Pw0bzW8pSntrirvXk1g6 tg9NALdmqtJXAboKv0SzqofkWISizqjci2eqGtL911PT2ly2hOhZKatjiPfOwJdFA6rYk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnrtS-0007jk-EK; Tue, 23 Jun 2020 22:59:54 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnrtS-00014d-1Y; Tue, 23 Jun 2020 22:59:54 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnrtS-0006bS-0w; Tue, 23 Jun 2020 22:59:54 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [examine test] 151315: regressions - trouble: fail/pass/starved X-Osstest-Failures: examine:examine-italia0:examine-iommu:fail:regression examine:examine-debina1:examine-iommu:fail:regression examine:examine-debina0:examine-iommu:fail:nonblocking examine:examine-fiano0:hosts-allocate:starved:nonblocking examine:examine-pinot1:hosts-allocate:starved:nonblocking examine:examine-chardonnay0:hosts-allocate:starved:nonblocking examine:examine-fiano1:hosts-allocate:starved:nonblocking examine:examine-huxelrebe1:hosts-allocate:starved:nonblocking examine:examine-elbling1:hosts-allocate:starved:nonblocking examine:examine-godello1:hosts-allocate:starved:nonblocking examine:examine-chardonnay1:hosts-allocate:starved:nonblocking examine:examine-elbling0:hosts-allocate:starved:nonblocking examine:examine-pinot0:hosts-allocate:starved:nonblocking examine:examine-huxelrebe0:hosts-allocate:starved:nonblocking examine:examine-godello0:hosts-allocate:starved:nonblocking examine:examine-rimava1:hosts-allocate:starved:nonblocking examine:examine-cubietruck-gleizes:hosts-allocate:starved:nonblocking examine:examine-albana0:hosts-allocate:starved:nonblocking examine:examine-albana1:hosts-allocate:starved:nonblocking X-Osstest-Versions-That: flight=150344 From: osstest service owner Date: Tue, 23 Jun 2020 22:59:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151315 examine real [real] http://logs.test-lab.xenproject.org/osstest/logs/151315/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: examine-italia0 13 examine-iommu fail REGR. vs. 150344 examine-debina1 13 examine-iommu fail REGR. vs. 150344 Tests which did not succeed, but are not blocking: examine-debina0 13 examine-iommu fail blocked in 150344 examine-fiano0 2 hosts-allocate starved n/a examine-pinot1 2 hosts-allocate starved n/a examine-chardonnay0 2 hosts-allocate starved n/a examine-fiano1 2 hosts-allocate starved n/a examine-huxelrebe1 2 hosts-allocate starved n/a examine-elbling1 2 hosts-allocate starved n/a examine-godello1 2 hosts-allocate starved n/a examine-chardonnay1 2 hosts-allocate starved n/a examine-elbling0 2 hosts-allocate starved n/a examine-pinot0 2 hosts-allocate starved n/a examine-huxelrebe0 2 hosts-allocate starved n/a examine-godello0 2 hosts-allocate starved n/a examine-rimava1 2 hosts-allocate starved n/a examine-cubietruck-gleizes 2 hosts-allocate starved n/a examine-albana0 2 hosts-allocate starved n/a examine-albana1 2 hosts-allocate starved n/a baseline version: flight 150344 jobs: examine-albana0 starved examine-albana1 starved examine-arndale-bluewater pass examine-cubietruck-braque pass examine-chardonnay0 starved examine-chardonnay1 starved examine-debina0 fail examine-debina1 fail examine-elbling0 starved examine-elbling1 starved examine-fiano0 starved examine-fiano1 starved examine-cubietruck-gleizes starved examine-godello0 starved examine-godello1 starved examine-huxelrebe0 starved examine-huxelrebe1 starved examine-italia0 fail examine-arndale-lakeside pass examine-laxton0 pass examine-laxton1 pass examine-arndale-metrocentre pass examine-cubietruck-metzinger pass examine-cubietruck-picasso pass examine-pinot0 starved examine-pinot1 starved examine-rimava1 starved examine-rochester0 pass examine-rochester1 pass examine-arndale-westfield pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Push not applicable. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 00:08:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 00:08:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnsx3-0003Vo-Cf; Wed, 24 Jun 2020 00:07:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnsx1-0003Vj-F8 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 00:07:39 +0000 X-Inumbo-ID: b592229a-b5ae-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b592229a-b5ae-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 00:07:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JVul1qmO1wdc24NkkouI2Q6JPDLNVVRTllVTuL3GO2o=; b=GMa6dbl/KgufMkyB+YeQEC838 yzCyv2O/fUoRxla2LzR5l5Nm4qmCCwRs2aX+8JM98P1u0Yfj2lPM7KjyVFo3CBWfYzyA/vGAcPXRE lmwa3U9KVPmu4dlDVEYPlc7nZ77LEQqBdqkzWsVyhHnu4epXvqPQSwhldFVYBkL/UkLX4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnswx-0001BV-RN; Wed, 24 Jun 2020 00:07:35 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnswx-0003B6-IT; Wed, 24 Jun 2020 00:07:35 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnswx-0002cq-HW; Wed, 24 Jun 2020 00:07:35 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151302: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-i386-libvirt-pair:xen-boot/dst_host:fail:regression linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=dd0d718152e4c65b173070d48ea9dfc06894c3e5 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Wed, 24 Jun 2020 00:07:35 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151302 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151302/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 151214 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 151214 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux dd0d718152e4c65b173070d48ea9dfc06894c3e5 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 5 days Failing since 151236 2020-06-19 19:10:35 Z 4 days 4 attempts Testing same since 151302 2020-06-23 00:11:53 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alex Deucher Alex Deucher Alexander Stein Alexey Budankov Andy Shevchenko Aneesh Kumar K.V Ard Biesheuvel Arnaldo Carvalho de Melo Arnd Bergmann Arvind Sankar Atish Patra Axel Lin Baolin Wang Barry Song Bartosz Golaszewski Charles Keepax Chen Zhou Chris Wilson Christian Zigotzky Christoph Hellwig Christophe Leroy Chunyan Zhang Coly Li Cornelia Huck Dan Carpenter Dan Williams Daniel Schaefer Daniel Vetter Dave Airlie Dave Martin David Howells Denis Efremov Dinghao Liu Dmitry Baryshkov Dmitry V. Levin Drew Fustini Eric Biggers Felix Kuehling Flavio Suligoi Gaurav Singh Geert Uytterhoeven Guenter Roeck Gustavo A. R. Silva Haibo Chen Heiko Carstens Heinrich Schuchardt Herbert Xu Hongbo Yao Ian Rogers Ilya Dryomov Imre Deak Ira Weiny Jack Wang Jan Kara Jason A. Donenfeld Jason Yan Jens Axboe Jens Thoms Toerring Jiri Olsa Jiri Olsa John Garry Joonas Lahtinen Julian Wiedmann Kai-Heng Feng Kaitao Cheng Kees Cook Kefeng Wang kernel test robot Keyur Patel Khaled Almahallawy Krzysztof Kozlowski Lee Jones Lingling Xu Linus Torvalds Linus Walleij Loic Poulain Lorenz Brun Luc Van Oostenryck Luis Chamberlain Manivannan Sadhasivam Mark Brown Mark Rutland Martin Fuzzey Martin K. Petersen Martin Schwidefsky Masahiro Yamada Masami Hiramatsu Masanari Iida Matti Vaittinen Mauricio Faria de Oliveira Michael Ellerman Miguel Ojeda Mike Rapoport Milian Wolff Nathan Chancellor Nathan Huckleberry Navid Emamdoost Nicholas Piggin Nick Desaulniers Nirmoy Das Palmer Dabbelt Patrice Chotard Paul Moore Pavel Begunkov Peter Zijlstra (Intel) Qing Zhang Qingqing Zhuo Randy Dunlap Robert Foss Robin Gong Rodrigo Siqueira Roman Gushchin Sami Tolvanen Sandeep Raghuraman Sedat Dilek Shuah Khan Shyam Thombre Sivaprakash Murugesan Stephan Mueller Stephan Müller Stephen Smalley Steven Rostedt (VMware) Sumanth Korikkar Sven Schnelle Tiezhu Yang Tom Lendacky Tom Rix Uma Shankar Vaibhav Jain Vamshi K Sthambamkadi Vandita Kulkarni Vasily Gorbik Vidya Sagar Vincenzo Frascino Vishal Verma Vladimir Oltean Wei Yang Weiping Zhang Will Deacon Wolfram Sang Wolfram Sang Xiaoguang Wang YangHui Yash Shah Ye Bin Zheng Bin Zhenzhong Duan Zhiqiang Liu Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6526 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 24 01:36:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 01:36:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnuKn-0003zD-Az; Wed, 24 Jun 2020 01:36:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnuKm-0003z8-Cn for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 01:36:16 +0000 X-Inumbo-ID: 1750faa4-b5bb-11ea-bca7-bc764e2007e4 Received: from mail-lj1-x242.google.com (unknown [2a00:1450:4864:20::242]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1750faa4-b5bb-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 01:36:14 +0000 (UTC) Received: by mail-lj1-x242.google.com with SMTP id n23so722912ljh.7 for ; Tue, 23 Jun 2020 18:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q7jjyfHFC9E96qUQNIK0iSzZnFmQnU7S2H0dsaVw/bw=; b=hK7Rt5VMB2G5gbaRdIV0Ca6lV0ZaRMz+RDV4xUL2XkVbCQIDEzOKm49gQBGCHYiOM5 01IoGspdppI0EkYYitQghqMlWYxjWXvA/+3qZbU0KlZVs+xj1BqcrcCEPMGKW5PZTm8B g9u75oDqyl7m46djbSPk/Yw7xqTFCNyLCpUbGbck/WRnJMui8c89yeFj96+8belvxbna M5SZyJJ+dcvDMGJTLw4H2SZPdurlPzX0BYo0XgITMwuMlw8TnsTwTgIriOt2Exj06PtJ StY//vwUk0msYU4UBdT8AfDX73f5umwrQ7ITct+uyRy9dil1w0CADNCuTewpgAaJdsVC dPDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q7jjyfHFC9E96qUQNIK0iSzZnFmQnU7S2H0dsaVw/bw=; b=fWgYz10U5xtVkVr9Xv+QKfh4ljcsNK9lAFeXemvlRKBSR33bHy9hivTmB135d/znjU wnNV0R7GemB1fY3MKZAWuecBefRKY+GpaXDP5aIlZQgf+0Ff9XI0dWf/N3ej9UM+b5eL LzqkBQCuobP8PGtaPPiQ8WECoknV2Hdxqn1Ultt91H4pSKoebTr6CWZxfodMuVN33iSJ IRs6mkWHKeFXSFg20yzRt6gH+92n4gyQyr5X0M6CHMRZg0JAFqIjyQoSk7JsX/vFoQ9d 7Q75wH9yyHEENiFYBLhYumg1CGv9aoZ0rmB3BMatV/YPsRe8ij7v4jcHvzUxulghCAIR C7NQ== X-Gm-Message-State: AOAM530+8+jChWkqAGccF0qUQUZmA9DOwpvPhXiwv2ehoYQmvcE8De4z dlFjayWLi+l6duVHI6wX8PdVlV9plGQeTGKcSUY= X-Google-Smtp-Source: ABdhPJzOqFFVqbyUclpMCMOSdJwxZz/i0ZJW9EZ9Y352Wdacz7Zh9xF7VmRJgb1LV8FRvn+GdRWFYPs8nErn9OhneVQ= X-Received: by 2002:a2e:b704:: with SMTP id j4mr13041345ljo.458.1592962573834; Tue, 23 Jun 2020 18:36:13 -0700 (PDT) MIME-Version: 1.0 References: <1592913499-15558-1-git-send-email-jrdr.linux@gmail.com> In-Reply-To: From: Souptick Joarder Date: Wed, 24 Jun 2020 07:06:01 +0530 Message-ID: Subject: Re: [RFC PATCH v2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Boris Ostrovsky Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , xen-devel@lists.xenproject.org, sstabellini@kernel.org, linux-kernel@vger.kernel.org, John Hubbard Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 11:11 PM Boris Ostrovsky wrote: > > On 6/23/20 7:58 AM, Souptick Joarder wrote: > > In 2019, we introduced pin_user_pages*() and now we are converting > > get_user_pages*() to the new API as appropriate. [1] & [2] could > > be referred for more information. This is case 5 as per document [1]. > > > > As discussed, pages need to be marked as dirty before unpinned it. > > > > Previously, if lock_pages() end up partially mapping pages, it used > > to return -ERRNO due to which unlock_pages() have to go through > > each pages[i] till *nr_pages* to validate them. This can be avoided > > by passing correct number partially mapped pages & -ERRNO separately > > while returning from lock_pages() due to error. > > With this fix unlock_pages() doesn't need to validate pages[i] till > > *nr_pages* for error scenario. > > > This should be split into two patches please. The first one will fix the > return value bug (and will need to go to stable branches) and the second > will use new routine to pin pages. Initially I split the patches into 2 commits. But at last moment I figure out that, this bug fix ( better to call coding error, doesn't looks like lead to any runtime bug) is tightly coupled to 2nd commit for pin_user_pages*() conversion, which means we don't need the bug fix patch if we are not converting the API to pin_user_pages*()/ unpin_user_pages_dirty_lock(). That's the reason to clubbed these two commits into a single one. If this looks unreasonable, will split it into 2 patches again. > > > > @@ -580,25 +580,30 @@ static long privcmd_ioctl_mmap_batch( > > > > static int lock_pages( > > struct privcmd_dm_op_buf kbufs[], unsigned int num, > > - struct page *pages[], unsigned int nr_pages) > > + struct page *pages[], unsigned int nr_pages, int *errno) > > > I'd prefer if you used more traditional way of returning error code by > the function, and pass the number of pinned pages as an argument. This > will also make call site simpler. Sure, Will do it. > > > -boris > From xen-devel-bounces@lists.xenproject.org Wed Jun 24 03:24:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 03:24:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnw1H-0005Wz-41; Wed, 24 Jun 2020 03:24:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnw1F-0005Wu-DZ for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 03:24:13 +0000 X-Inumbo-ID: 2c5ffa62-b5ca-11ea-8496-bc764e2007e4 Received: from mail-lj1-x22d.google.com (unknown [2a00:1450:4864:20::22d]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2c5ffa62-b5ca-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 03:24:12 +0000 (UTC) Received: by mail-lj1-x22d.google.com with SMTP id s9so913394ljm.11 for ; Tue, 23 Jun 2020 20:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zATyIOC89HCqUhnBoh+lwkWVcOVUh3I8uyFWbAFlEoM=; b=k/aYoqRJ6SpGM7scsWsZcHmoGIprlLyky0mNM0bxVvdwLKy7eXzAEQ9NkP3DtYw4nR TQdxap2VMFzlvJc7mxNU9NWuXuXo5x8vtFKx9/V4b3tNDZxagESQhGTJczG19Q8YY6pc uxKztahkcSYM4f6IttOB9q3iydH3d5QA7exX04t9tE3uHt0j4C3Kqcvsb55J4iaX+Qkk 4M0nebTMRqMXKY7ztHXRVnjgh5uRdSx151SPeFLRE4pWVpI1TIVl8Dgqd+1LqN4gCOjn u1NnUMYIC9EmRj03AjoXYn0652bEEFgYbrJQB/4DvvFy3zS7yBXHKheNulZi3P4nzlpd jz8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zATyIOC89HCqUhnBoh+lwkWVcOVUh3I8uyFWbAFlEoM=; b=DilgtoI/HCHSB7bx3sKXWwbCH4094dnTApo0+M6oCUczfQ+tIdArYxeOuXFliCvt0q 25KD81Kpwi0UWHxX4XAoQj91RD8YgNy7bzHErpyA2zae2bMFd8W2BKb1V2PLcy9/auvr liIHKaLSCn1O7SrrXrcY6+o/zPvQo1SpAquMOjJs/3fnIgRDrLlCF6Q9Q0+q8zAa+84D DztPoSoOFn6f3k8CK982DWu1Y/HacPjoK1baX8Z8uHX94oC0MVN8Xti7DQGrwh/qjV0T haK7Y8xNo53jecWZ5V6Av5JOyYuMZkzH23ZsEkSXNhGYZ+ASLP4Qpk6lKe+tv23NYEPG Bs9Q== X-Gm-Message-State: AOAM533FtArzv76b/fzVXkRQHVRW6xJqtaqeNJM7bIaRlYhMSA7ib1tM yGzJcDiFb1nWigPIGwWN2ubG4tj6Nvx+h8PVmIU= X-Google-Smtp-Source: ABdhPJy82cR6TDBLKeUrr7BsPQumqJX34a+ZGAf4Ewtmd6TzkP5ojuvgG5SLPlkHR12eACs2CaeuiXrWP9f+JXzNVZY= X-Received: by 2002:a2e:b8c2:: with SMTP id s2mr13599176ljp.368.1592969051504; Tue, 23 Jun 2020 20:24:11 -0700 (PDT) MIME-Version: 1.0 References: <87k0zykwdl.fsf@dusky.pond.sub.org> <000001d64953$f67a1f00$e36e5d00$@xen.org> In-Reply-To: <000001d64953$f67a1f00$e36e5d00$@xen.org> From: Jason Andryuk Date: Tue, 23 Jun 2020 23:23:59 -0400 Message-ID: Subject: Re: sysbus failed assert for xen_sysdev To: Paul Durrant Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , xen-devel , Mark Cave-Ayland , Markus Armbruster , QEMU Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 7:46 AM Paul Durrant wrote: > > > -----Original Message----- > > From: Markus Armbruster > > Sent: 23 June 2020 09:41 > > To: Jason Andryuk > > Cc: Mark Cave-Ayland ; Anthony PERARD ; xen- > > devel ; Paul Durrant ; QEMU > > Subject: Re: sysbus failed assert for xen_sysdev > > > > Jason Andryuk writes: > > > Then it gets farther... until > > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > > > Assertion `dev->realized' failed. > > > > > > dev->id is NULL. The failing device is: > > > (gdb) p *dev.parent_obj.class.type > > > $12 = {name = 0x555556207770 "cfi.pflash01", > > > > > Having commented out the call to xen_be_init() entirely (and xen_bus_init() for good measure) I also get this assertion failure, so > I don't think is related. Yes, this is something different. pc_pflash_create() calls qdev_new(TYPE_PFLASH_CFI01), but it is only realized in pc_system_flash_map()... and pc_system_flash_map() isn't called for Xen. Removing the call to pc_system_flash_create() from pc_machine_initfn() lets QEMU startup and run a Xen HVM again. xen_enabled() doesn't work there since accelerators have not been initialized yes, I guess? Regards, Jason From xen-devel-bounces@lists.xenproject.org Wed Jun 24 03:29:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 03:29:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnw5x-0005m5-OP; Wed, 24 Jun 2020 03:29:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnw5w-0005m0-JG for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 03:29:04 +0000 X-Inumbo-ID: d9f944b2-b5ca-11ea-bb8b-bc764e2007e4 Received: from mail-lj1-x235.google.com (unknown [2a00:1450:4864:20::235]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d9f944b2-b5ca-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 03:29:04 +0000 (UTC) Received: by mail-lj1-x235.google.com with SMTP id e4so965271ljn.4 for ; Tue, 23 Jun 2020 20:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jI17LQTN3+z4SiRVh3azK7/wsTn408ncZ2KjazB86gg=; b=PNrg8PWQ+ZG3a4BhsUtOd4Sq7oWFs3cxNHl0dA62wM+U8y4vm8wPgPzUH+gB5sH6h5 nX63MvzOgmV1Dm+eTjbFUVpLAnSkKc/c9kk4alc0Xe6e3FCjE5nNOXfMWZqKp2ebRil0 b3GuBQXYLsrEBy+7CsroblcxwHiSXzYD0hoUToAGL8eovfH3majYR7b6D0pk1+q+u8z0 NHfShoouJRtLTPNex1QYKFsEHIJHTwNkFiYtzfwfCkYKvsYkRgiP8oXVImlO0mgNw1JT h7kF6ZctSSLpcPE5YvDOx+7pbENUP0ySTZtA+qn+5POIinXib6Km0V5qtgh8kpRYr4LH lj2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jI17LQTN3+z4SiRVh3azK7/wsTn408ncZ2KjazB86gg=; b=ha2Hdn7QbpRHE/vrWK9s5WLTpChte+yZi4/K7RQlnT7VBZam9iV4rNRagjrrvbnF/1 WOXR4JdqlTIAzzZMhH07eyxN9BUEfOdcZVSChCd+Jj2PyBQfKUp5Bk8wsp/DTSq/WuPC OsmrlyZQUUuX/lgm4S8h/nbG4rUmkuYi1fPSNzzxhWOyeOAaxb76j/HtLJirfCAwGnDR klD8YlB4N98hV0mCDgsbCm/d3si5PHwqkOMt+mO2dNAG3wBWpTQ6apg5wITGxnFtF7Vv l17Pht4SgFyCvGT+sNIH5rMPQ2uHlc6YyXELlRW54LCYBhFNKXHSE2JyahV3kk9o68kR 7dww== X-Gm-Message-State: AOAM532nW0M6ZCed+vRI34zfPKx6apwkZqwE6uQ4rT+wHBWaAAMbExSS xkN4PZT9NQHIt6CzSbQQzXycVIs7StbY4NmOMgk= X-Google-Smtp-Source: ABdhPJyu1IksiHVFvTZLBipIeEqb+aQHEsVhvlrZa7kDEIWUxIvXB4tVHZ7iiQxaNvxnksFjwjNt5Jn4fyup9CPF4RM= X-Received: by 2002:a2e:9a59:: with SMTP id k25mr13583203ljj.114.1592969342938; Tue, 23 Jun 2020 20:29:02 -0700 (PDT) MIME-Version: 1.0 References: <87k0zykwdl.fsf@dusky.pond.sub.org> <000101d64961$681c0350$385409f0$@xen.org> In-Reply-To: <000101d64961$681c0350$385409f0$@xen.org> From: Jason Andryuk Date: Tue, 23 Jun 2020 23:28:51 -0400 Message-ID: Subject: Re: sysbus failed assert for xen_sysdev To: Paul Durrant Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , xen-devel , Mark Cave-Ayland , Markus Armbruster , QEMU Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 9:22 AM Paul Durrant wrote: > > > -----Original Message----- > > From: Jason Andryuk > > Sent: 23 June 2020 13:57 > > To: Markus Armbruster > > Cc: Mark Cave-Ayland ; Anthony PERARD ; xen- > > devel ; Paul Durrant ; QEMU > > Subject: Re: sysbus failed assert for xen_sysdev > > > > Thanks for your response, Markus. > > > > I didn't write it, but my understanding is as follows. TYPE_XENSYSDEV > > is a device on the system bus that provides the TYPE_XENSYSBUS bus. > > TYPE_XENBACKEND devices can then attach to TYPE_XENSYSBUS. > > > > That would make the qom-tree something like: > > /TYPE_XENSYSDEV > > /TYPE_XENSYSBUX > > /TYPE_XENBACKEND > > > > (I think today the TYPE_XENBACKEND devices ends up attached to the System bus.) > > > > I think TYPE_XENSYSDEV is correct - it is a device on the system bus. > > static const TypeInfo xensysdev_info = { > > .name = TYPE_XENSYSDEV, > > .parent = TYPE_SYS_BUS_DEVICE, > > ... > > } > > > > TYPE_XENSYSBUS is the xen-specific bus - provided by TYPE_XENSYSDEV - > > for attaching xendev. > > static const TypeInfo xensysbus_info = { > > .name = TYPE_XENSYSBUS, > > .parent = TYPE_BUS, > > ... > > } > > > > TYPE_XENBACKEND is a generic Xen device and it plugs into > > TYPE_XENSYSBUS. Maybe the .parent here is wrong and it should just be > > TYPE_DEVICE? > > Yes, I think that is the problem leading to the assert. See the equivalent (non-legacy) code in xen-bus.c. Yes, xen-bus.c looks correct, but the important change seems to be removing `dc->bus_type = TYPE_XENSYSBUS;` from xen_sysdev_class_init() and adding it to xendev_class_init(). That let QEMU get to the cfi.pflash01 assertion failure. Regards, Jason > Paul > > > static const TypeInfo xendev_type_info = { > > .name = TYPE_XENBACKEND, > > .parent = TYPE_XENSYSDEV, > > ... > > } > > > > So removing `bus_type = TYPE_XENSYSBUS` from TYPE_XENSYSDEV class_init > > and adding it to TYPE_XENBACKEND seems correct to me. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 04:15:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 04:15:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnwp0-0001gn-9R; Wed, 24 Jun 2020 04:15:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnwoz-0001gi-BH for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 04:15:37 +0000 X-Inumbo-ID: 58945aae-b5d1-11ea-804f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 58945aae-b5d1-11ea-804f-12813bfff9fa; Wed, 24 Jun 2020 04:15:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JHDOU6zqhAdjdkLJR1iFabbUcoX3Bh0Biw7ddPhiQ/s=; b=mzzNfVSOyQDNHk1GWwXvBrgTs 3Gw+ntvKnao8dYLpQQufjBtwBIgBoRwqCcBTKhws2MqrtEtBajNVMcda2ETCbUXpbmkvf4Y33PdUn Sm+8Scm88VXMz5K0q376uAebwcuYwjfTXE+F4ofYqIJUHNl1sOHjAc5eJgEiJxthuRlqw=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnwou-0007YJ-GX; Wed, 24 Jun 2020 04:15:32 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnwou-0006OX-74; Wed, 24 Jun 2020 04:15:32 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnwou-0004Lc-6P; Wed, 24 Jun 2020 04:15:32 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151304: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=171199f56f5f9bdf1e5d670d09ef1351d8f01bae X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Wed, 24 Jun 2020 04:15:32 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151304 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151304/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151065 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass version targeted for testing: qemuu 171199f56f5f9bdf1e5d670d09ef1351d8f01bae baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 11 days Failing since 151101 2020-06-14 08:32:51 Z 9 days 8 attempts Testing same since 151304 2020-06-23 02:23:49 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Anthony PERARD Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Geoffrey McRae Gerd Hoffmann Guenter Roeck Helge Deller Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jean-Christophe Dubois Jiaxun Yang John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marek Marczykowski-Górecki Markus Armbruster Masahiro Yamada Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Stefan Berger Stefan Hajnoczi Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 9142 lines long.) From xen-devel-bounces@lists.xenproject.org Wed Jun 24 04:31:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 04:31:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnx46-0003T7-Kg; Wed, 24 Jun 2020 04:31:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnx45-0003T2-DL for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 04:31:13 +0000 X-Inumbo-ID: 887b4186-b5d3-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x42f.google.com (unknown [2a00:1450:4864:20::42f]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 887b4186-b5d3-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 04:31:12 +0000 (UTC) Received: by mail-wr1-x42f.google.com with SMTP id k6so852425wrn.3 for ; Tue, 23 Jun 2020 21:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eqK1/S1BSPqTEtyBa/lwm0IqQTMCXrvmftiOVycrcDU=; b=I2dr29vFq0l2HgQvbr59hmpnZ0zgF3O4qDKo/3tzMs1Wl4MPALNgw9knIdc7myiqHN g50Fj4iuYCu/8qtv49q2nTwum0zkJvIvGphY3RkSgVmo/mV4b1F/ku0ceGt+4yHtS2YD ZyN6qyoeB/Tld0sTSlMHpkdz4xErOkMwAr1WnA+UvKPlviVEcuYsnzzuYG67BrpDrUf/ 6vgmkNkNk9QsCj6t4R3m5FuKsKX1x3h7G7PUdUlr0ikI6bgb5v4T441O+L3LVrBXm/0x bbfNZtHiQm7icNn69Sstd87xUQxp6zZkUCio2KifIEBCG+PeP2uSZJ10PE/W4wsXqasP l72Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eqK1/S1BSPqTEtyBa/lwm0IqQTMCXrvmftiOVycrcDU=; b=Ye7a542g6upl9wTP5tljiJldlcC4VXhoTAAv0Bb5FjLx+tXlzZZTmXW6Es+553EYme LHI4JiARehkEWEb00l2jey7r4be/w1J9tLc3ASdQ7+KtrpRPG7WvU2NWJ6er899eC0S+ qBiDuDY9KrxuHT8W5GIgr4GntgtEGx80odXpuUzjJWGsb+dvJNI6Bkqtr6rEMDfS79wy dio54f71hY/xFUbXcBje9Z3p9wHHDReWyorSVm6FPZiZVWLffQNNeEmcpOCCTBXgfVXY rjE8ZKwNw9+LNfIzPGVXxgb9t+8T/79fs26RN7zU45gAeMeFBjZMxcfOaWWBNwYqISHu CAVA== X-Gm-Message-State: AOAM533KA2YqREbnF3BW7V2pv0+omLLz/tAJ5wz+BTkhLv4blMZTA7eE 2JbFVQbk/AsN8+pa/v86fJGPpPsPLvAQmT2Qhts6kyAnp2c= X-Google-Smtp-Source: ABdhPJycYfgpxn36qnjaQazv81nIVMYqSkZDu4OryVgKr0DbG8As3C7/xCqaEM5od0yfCc6gdcTd5duz5ZcbPS58s6I= X-Received: by 2002:a5d:698e:: with SMTP id g14mr30826455wru.301.1592973071333; Tue, 23 Jun 2020 21:31:11 -0700 (PDT) MIME-Version: 1.0 From: Tamas K Lengyel Date: Tue, 23 Jun 2020 22:30:35 -0600 Message-ID: Subject: [TESTDAY] Test report 4.14-rc3 To: Xen-devel Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" * Hardware: i9-9900x * Guest operating systems: Ubuntu 20.04 * Functionality tested: domain create/save/restore, altp2m, vm_event, mem_access, mem_sharing, VM forking * Comments: also tested running nested in a VMware workstation VM, all above work fine in that setup as well albeit with some expected performance drop. Everything looks good from my end. Cheers, Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 24 05:31:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 05:31:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnxzq-0000zR-Jb; Wed, 24 Jun 2020 05:30:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnxzp-0000z4-5A for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 05:30:53 +0000 X-Inumbo-ID: da3c9aee-b5db-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id da3c9aee-b5db-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 05:30:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rcymPY35vkCY8cxa1TwX0vZgR1PF/LmfB3CG7/cDR8M=; b=x50E2yhn4ifBAECzoLJ07x0Y5 bA4DremgJVKZJxmk7A87IoF0Do6L6up1ViqtaoVmWzYgflzgCOzSl+PRZ53kpxS4JpNgoRLgy5N6O KFn0DP59joWxR9JQ+uL9PyDQJdxVRoGixcb9wBE9V5rdSYsUlt0YNmGVd7uh51FBJWdvg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnxzg-0000wm-Ts; Wed, 24 Jun 2020 05:30:44 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnxzg-0000pl-KP; Wed, 24 Jun 2020 05:30:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnxzg-000698-JR; Wed, 24 Jun 2020 05:30:44 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 151307: tolerable FAIL - PUSHED X-Osstest-Failures: linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=67cb016870e2fa9ffc8d34cf20db5331e6f2cf4d X-Osstest-Versions-That: linux=fd8cd8ac940c8b45b75474415291a3b941c865ab From: osstest service owner Date: Wed, 24 Jun 2020 05:30:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151307 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/151307/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 67cb016870e2fa9ffc8d34cf20db5331e6f2cf4d baseline version: linux fd8cd8ac940c8b45b75474415291a3b941c865ab Last test of basis 151232 2020-06-19 05:33:37 Z 4 days Testing same since 151288 2020-06-22 07:40:16 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Aaron Brown Adrian Hunter Al Viro Alan Maguire Alex Deucher Alexander Monakov Alexander Sverdlin Alexandre Belloni Alexei Starovoitov Alexey Malahov Anand Jain Anders Roxell Andrea Arcangeli Andrea Parri (Microsoft) Andrew Bowers Andrew Morton Andrii Nakryiko Andrzej Hajda Andy Shevchenko Anton Protopopov Ard Biesheuvel Arnaldo Carvalho de Melo Arnd Bergmann Arthur Kiyanovski Arvind Sankar Ashok Raj Ayush Sawal Bart van Assche Bhupesh Sharma Bingbu Cao Bjorn Andersson Bjorn Helgaas Bjorn Helgaas Bob Moore Bogdan Togorean Boris Brezillon Borislav Petkov Brad Love Brian Foster chen gong Chih-Min Chen Chris Chiu Christian König Christian Lamparter Christoph Hellwig Christophe JAILLET Christophe Leroy Chuhong Yuan Chun-Kuang Hu Colin Ian King Coly Li Corentin Labbe Dan Carpenter Daniel Axtens Daniel Borkmann Daniel Jordan Daniel Lezcano Daniel Thompson Darrel Goeddel Darrick J. Wong Dave Hansen Dave Jiang David Gow David Hildenbrand David S. Miller David Sterba David.Laight@aculab.com (big endian system concerns) Dejin Zheng Devulapally Shiva Krishna Dmitry Osipenko Doug Berger Douglas Anderson Eelco Chaudron Erez Shitrit Erhard F. Eric Biggers Erik Kaneda Evan Green Felix Fietkau Felix Kuehling Feng Tang Filipe Manana Finn Thain Florian Fainelli Ganapathi Bhat Gavin Shan Geert Uytterhoeven Geert Uytterhoeven Georgy Vlasov Govindaraj Saminathan Greg Kroah-Hartman Guenter Roeck Guoqing Jiang H. Nikolaus Schaller Haibo Chen Hans de Goede Hans Verkuil Hari Bathini Harshad Shirwadkar Herbert Xu Hsin-Yu Chao Huaixin Chang Ian Rogers Ingo Molnar Ioana Ciornei Ivan Kokshaysky J. Bruce Fields Jacob Keller Jaegeuk Kim Jaehoon Chung Jakub Sitnicki James Morris Jann Horn Jay Cornwall Jean-Philippe Brucker Jeff Kirsher Jeffle Xu Jens Axboe Jeremy Cline Jeremy Kerr Jernej Skrabec Jesper Dangaard Brouer Jia-Ju Bai Jiaxun Yang Jiri Olsa Jitao Shi Johan Hovold John Fastabend Jon Derrick Jon Doron Jonathan Bakker Josef Bacik Josh Poimboeuf Julien Thierry Juxin Gao Kai-Heng Feng Kaige Li Kalle Valo Kees Cook Kevin Buettner Kieran Bingham Kirill A. Shutemov Koba Ko Krzysztof Kozlowski Krzysztof Struczynski Larry Finger Laurent Pinchart Laurent Pinchart limingyu Linus Torvalds Linus Walleij Lorenzo Pieralisi Luca Coelho Ludovic Desroches Lukas Wunner Luke Nelson Luke Nelson Maharaja Kennadyrajan Marcel Holtmann Marcos Paulo de Souza Marcos Scriven Marek Szyprowski Mark Brown Mark Starovoytov Martin Blumenstingl Masahiro Yamada Masami Hiramatsu Matt Turner Mauro Carvalho Chehab Michael Ellerman Michael Ellerman (powerpc) Michal Hocko Michał Mirosław Mike Snitzer Mikulas Patocka Mimi Zohar Ming Lei Miquel Raynal Mordechay Goodstein Nathan Chancellor NeilBrown Nick Desaulniers Nickolai Kozachenko Nicolas Chauvet Nicolas Toromanoff Nikolay Borisov Omar Sandoval Pablo Neira Ayuso Pali Rohár Paolo Bonzini Paul Moore Pavel Tatashin Peter Zijlstra (Intel) Peter Zijlstra Punit Agrawal Qian Cai Qiushi Wu Qu Wenruo Rafael J. Wysocki Rajmohan Mani Rakesh Pillai Rob Herring Roberto Sassu Rui Miguel Silva Russell King Ryder Lee Saeed Mahameed Sagi Grimberg Sakari Ailus Sameeh Jubran Samuel Holland Sasha Levin Sean Young Sebastian Reichel Serge Semin Shaokun Zhang Sharon Simon Wunderlich Song Liu Stephane Eranian Stephen Boyd Surabhi Boob Sven Eckelmann Tejun Heo Theodore Ts'o Thierry Reding Thomas Bogendoerfer Tiezhu Yang Tobias Baumann <017623705678@o2online.de> Toke Høiland-Jørgensen Tom Lendacky Tomasz Figa Tomi Valkeinen Tomohito Esaki Tony Lindgren Tony Nguyen Toshiaki Makita Tuan Phan Ulf Hansson Veerabhadrarao Badiganti Venkateswara Naralasetty Vinod Koul Vladimir Zapolskiy Vlastimil Babka Wei Liu Wei Yongjun Weiping Zhang Weiyi Lu Wen Gong Will Deacon Xi Wang Xie XiuQi Yan-Hsuan Chuang Yazen Ghannam YuanJunQing Yunjian Wang zhoubinbin Álvaro Fernández Rojas jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git fd8cd8ac940c..67cb016870e2 67cb016870e2fa9ffc8d34cf20db5331e6f2cf4d -> tested/linux-5.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 24 05:55:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 05:55:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnyNU-0002uq-Kp; Wed, 24 Jun 2020 05:55:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnyNT-0002uP-K1 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 05:55:19 +0000 X-Inumbo-ID: 454de79a-b5df-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 454de79a-b5df-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 05:55:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QPkyDk3EDkwLp5X3/oMZEXL6qfhcQ1PuXn+sXULjTW0=; b=VnsBY9TifDqcQ/KQ5iYeXqRVb EY3/vOr71jyVbLKzq1G7KmRLQuo4qC99FI7IsPT2fvtphw06PreZji/megTo0/ibf5L4A76W3kJ0p 508CU9qIr6MCYYcxVEB8Z2gpz4u9dFaoZkgRYTTAfR0hD2UCp/p7RJiOxe1kRmR0WMYOM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnyNM-0001MX-Ow; Wed, 24 Jun 2020 05:55:12 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jnyNM-0001eG-FP; Wed, 24 Jun 2020 05:55:12 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jnyNM-0007HK-CO; Wed, 24 Jun 2020 05:55:12 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151308: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=597fdabbc0e7c256b61a6b5ffda64bebfddc3807 X-Osstest-Versions-That: libvirt=96a39aad705f8e37950109d11636085b212af790 From: osstest service owner Date: Wed, 24 Jun 2020 05:55:12 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151308 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151308/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151251 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151251 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 597fdabbc0e7c256b61a6b5ffda64bebfddc3807 baseline version: libvirt 96a39aad705f8e37950109d11636085b212af790 Last test of basis 151251 2020-06-20 10:00:44 Z 3 days Testing same since 151308 2020-06-23 04:19:04 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Daniel P. Berrangé Han Han Peter Krempa jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 96a39aad70..597fdabbc0 597fdabbc0e7c256b61a6b5ffda64bebfddc3807 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Wed Jun 24 06:15:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 06:15:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnyga-0004on-9c; Wed, 24 Jun 2020 06:15:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnygZ-0004oi-2T for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 06:15:03 +0000 X-Inumbo-ID: 094cf756-b5e2-11ea-b7bb-bc764e2007e4 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.72]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 094cf756-b5e2-11ea-b7bb-bc764e2007e4; Wed, 24 Jun 2020 06:15:01 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MzbDM3QElO+Ikkc/fnhTD5X3l3Zq4rK7BC77DzDuYNRofr1hnAs39v38yxY+YDisjUJkmgbilDO6K3vOrHkhOAfTK6tBgDGgeartADlKepPAkixtco1NaHTuPKG9fAQeru7ztnmkMAYGRPjYnScSJa9ok+GT588BwSSfjoulj9EbuQG8ZXzyJ4mD66XjNZajBV5IMvYmy1Ja8hNBhsr79o0XLIxV4npJJGhfg/wCJv3EnKQij809dDGY1prkMFbn4ocIGkaDqLAGydM0K7Dha9O6DX48oByu0K7n97q4y3QEmrJtUgr1gH5Sx1DXXZIh2w8DKD02tPL9Gg1uk/0WjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yYDigHQ3HAqzhpJzdmvnX1Bl/Qv0EPsXpcTULAtliHU=; b=Q5qbGT0rwBrfvLW2ZHOUaC0N4wvt9a9qJTiDUkPnVJg/ebL+fsWMu5b0cfyODK1tonXhazfyNyOe9+UFfujH1TyQBmoEWCmcDG9p/ksu3+c9SgSw4f/OPi+o/4+tmldu7EwIyyh/xPyRTONi0s45s3YSauyZvNIgx3VbHeMjLsFgZyEzwCSvFz/du+IjZIjMFyNu7YWqLSQESAKkNWdCTrjnUBqnDWu37t1mAP/bP7y54cCthu4dZOwwTplxWqzPW2QdATT3fLoP9k6pPd06G0GKBhe0uYVg6xlwwFs/DMOpcVezswsWZnGheCfUlkqYMplw0ZB/oZEbPMYd5LhA6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yYDigHQ3HAqzhpJzdmvnX1Bl/Qv0EPsXpcTULAtliHU=; b=LhWstnR+M4buCt/XKD4+R/TF1CB2IJ4GqhB8QDD5mcijfSXUblqg2FzIEFSfCB+z5xs4FrW8BL9U1UN5JRuGBnwzsUNcnzKX5XTEqPHmEXkj4ya/LUhDgXTO3iTPLpR11LRUj6Hquoxq+Yl8J7Vpha2+xa80rQzlvUq1HLJx15mjqODDcDnzAOf3hL8WHcDCq5/JXjsk2ntZ3Y3r2Gp9UHV9G/TRTft80n3oB+RNyL+avzXGaRjbvwJHAd7J851i96uZzLUO1FAx+YSCAAMqQuDNwsZrfUb8DJpk5cB6es9cKPhCYilr0ZX/n7M0W+E5M+Q5OMS21fgQIf3n8ygs7g== Received: from AM6PR03MB3991.eurprd03.prod.outlook.com (2603:10a6:20b:25::20) by AM6PR03MB4358.eurprd03.prod.outlook.com (2603:10a6:20b:4::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 24 Jun 2020 06:15:00 +0000 Received: from AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c]) by AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c%4]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 06:15:00 +0000 From: Oleksandr Andrushchenko To: Stefano Stabellini , Julien Grall Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAWPDgIAEUtgAgAAGgYCAAAHAgIAANpaAgAB+IgCAAEYyAIABnlyA Date: Wed, 24 Jun 2020 06:14:59 +0000 Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> In-Reply-To: <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b77a13db-7217-4560-ad94-08d81805ecf0 x-ms-traffictypediagnostic: AM6PR03MB4358: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a6RiKWuKIvPCoy2ZQ4qjftQurMMTNWYIG4sTOvzN1UmE0M8i8RD3+hwEO7UCNUf1dVEHkBJRvlDlaSOhKcIZsJSWjYpvZYipt9N1DQxm7+HmL4NATIJlg2u6LSAfD1qI7eMxQ3y/EXZ1axty0Y0iBgChpqsH+GssiGifsFyBCaPzj62CHYIzfDXQP3lVJ46QwwmOaaMoE52Kal0kNCv+ePuQf64FKXpznndJah31gtot2qqmlCodtp25CMnCzQzxO5iHfaXbaqC3kDnRtbMnnJClMMdBf7Co4TAXcK16CwyDo5kF9zQfv9vvgOs0f+ml0xM3BD8CHHEAxjCVHtVBSaA3YKAbklglzfZ/uek+o2Kuw443+5vFmS7PZb9drP7fFMPSmQecEQlBpIbaqJMmqA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR03MB3991.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(346002)(376002)(136003)(39860400002)(66946007)(71200400001)(54906003)(6506007)(8936002)(4326008)(26005)(2906002)(6512007)(8676002)(186003)(53546011)(6486002)(316002)(36756003)(7416002)(478600001)(966005)(5660300002)(76116006)(31696002)(83380400001)(64756008)(110136005)(66446008)(66476007)(66556008)(31686004)(86362001)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: U+fzMxNO4ejjfXLVCTtjkRp9YBrNcP4k6ObmUlL3CYO00rGaXTwf86s9ltQv0dEIRf+zW1nVLkHLIBq2t0OcdkXTTiHeJWbeZmVAbzXyeW1wU4NVrX9NAcbPYIH1Tcklm4QBNt4fw71A7isJKSW2qXzwkrLwf7FkVWy8ect9mg3kLC66+kE1T2h+miK8Dprc+yL2sEGwfi8/y3E51XGz58BydfHfrJk7vaHgTJsqG0aH8HPBmpCN8lPTI1mh563KG3j3yTDyrxPDBNMoju6kIahJsDUKlIC0AhgCkXs/2ADmotvHyLj9OtzOlz4FUaOV0DJbDGcg7PxqQsoq/jQXzPhlCETWBzijSV9GDWfY7mDXQTOQ63CBOXQK4nqhMyb66vU5wZwc3OgJMXYoKQ7hl03DHRh1kKAYDedLsp9b8mcuUsfKOVOYpU6GZOi/TxpveLSUyiXPjodRtx4Fzi3qjYbicrYs22crwax31jwK/3k= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: b77a13db-7217-4560-ad94-08d81805ecf0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 06:15:00.0505 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vo5p/9EMY+0kvyMzLOWq/OL0O7FvbZgxF8a8Q5BUaht0PpftE1wWzob8CpoaUHkkN9JbeEMyzZSDCJSbxPnGoZYgugg5EZlkiKKTZWzanaDwiA4j7ODhVl6EYASIOhJB X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB4358 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzIzLzIwIDg6MzEgQU0sIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPg0K PiBPbiA2LzIzLzIwIDQ6MjAgQU0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4+IE9uIE1v biwgMjIgSnVuIDIwMjAsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+Pj4+PiBGb3IgdGhlIGZpcnN0 IHBhcnQgKF9fWEVOX0lOVEVSRkFDRV9WRVJTSU9OX18pIEkgdGhpbmsgd2UgY2FuIHByb3ZpZGUg aXQNCj4+Pj4+PiB2aWENCj4+Pj4+Pg0KPj4+Pj4+IENGTEFHUyBvciBzb21ldGhpbmcuIFRoaXMg Y2FuIGFsc28gYmUgZG9uZSBmb3IgdGhlIGxvY2F0aW9uIG9mIFhlbg0KPj4+Pj4+IGhlYWRlcnMu DQo+Pj4+PiBfX1hFTl9JTlRFUkZBQ0VfVkVSU0lPTl9fIHNob3VsZCB3b3JrIHRocm91Z2ggdGhl IENGTEFHUy4gQW4gYWx0ZXJuYXRpdmUNCj4+Pj4+IHdvdWxkIGJlIHRvIGFsbG93IHRoZSB1c2Vy IHRvIHNwZWNpZnkgdGhyb3VnaCB0aGUgS2NvbmZpZy4NCj4+Pj4gWW91IG1lYW4gc3BlY2lmeWlu ZyB2aWEgS2NvbmZpZyBzb21ldGhpbmcgbGlrZSAiMHgwMDA0MGQwMCI/DQo+Pj4gUG9zc2libHkg eWVzLg0KPj4+DQo+Pj4+IEFuZCB3aGF0IGFib3V0IHRoZSBoZWFkZXJzPyBIb3cgd2lsbCB3ZSBw cm92aWRlIHRoZWlyIGxvY2F0aW9uIGlmIHdlIGRlY2lkZQ0KPj4+PiBub3QgdG8gaW5jbHVkZSB0 aG9zZQ0KPj4+Pg0KPj4+PiBpbiB0aGUgdHJlZT8NCj4+PiBJIHdvdWxkIGRvIHRocm91Z2ggS2Nv bmZpZyBhcyB3ZWxsLg0KPj4gSWYgd2Ugc3BlY2lmeSB0aGUgZXh0ZXJuYWwgbG9jYXRpb24gb2Yg dGhlIFhlbiBoZWFkZXJzIHZpYSBLY29uZmlnLCBpdA0KPj4gc2VlbXMgdG8gbWUgdGhhdCB3ZSBz aG91bGQgYmUgYWJsZSB0byBkZXRlY3QgdGhlIGludGVyZmFjZSB2ZXJzaW9uDQo+PiBhdXRvbWF0 aWNhbGx5IGZyb20gYW55IE1ha2VmaWxlIGFzIHBhcnQgb2YgdGhlIGJ1aWxkLiBObyBuZWVkIHRv IGFzayB0aGUNCj4+IHVzZXIuDQo+Pg0KPj4gSG93ZXZlciwgaWYgT2xla3NhbmRyIGlzIHRoaW5r aW5nIG9mIHVzaW5nIHRoZSBYZW4gaGVhZGVycyBmb3IgdGhlDQo+PiBoeXBlcmNhbGxzIGRlZmlu aXRpb25zLCB0aGVuIEkgdGhpbmsgd2UgbWlnaHQgbm90IG5lZWQgZXh0ZXJuYWwgaGVhZGVycw0K Pj4gYXQgYWxsIGJlY2F1c2UgdGhhdCBpcyBhIHN0YWJsZSBpbnRlcmZhY2UsIGFzIEp1bGllbiB3 cm90ZS4gV2UgY291bGQNCj4+IGp1c3QgZGVmaW5lIG91ciBvd24gZmV3IGhlYWRlcnMgZm9yIGp1 c3Qgd2hhdCB5b3UgbmVlZCBsaWtlIExpbnV4IGRvZXMuDQo+DQo+IFRoaXMgaXMgYSBnb29kIGlk ZWE6IEknbGwgdHJ5IHRvIGdldCB0aGUgbWluaW1hbCBzZXQgb2YgaGVhZGVycyBmcm9tIExpbnV4 DQo+DQo+IGluc3RlYWQgb2YgWGVuIGFzIHRob3NlIHNlZW0gdG8gYmUgd2VsbCBwcmVwYXJlZCBm b3Igc3VjaCBhIHVzZS1jYXNlLiBUaGlzDQo+DQo+IHdheSB3ZSdsbCBoYXZlIGhlYWRlcnMgaW4g VS1ib290IHRyZWUgYW5kIGd1YXJhbnRlZSB0aGF0IHdlIGhhdmUgYSBtaW5pbWFsDQo+DQo+IHN1 YnNldCB3aGljaCBpcyBlYXNpZXIgdG8gbWFpbnRhaW4uIEknbGwga2VlcCB5b3UgdXBkYXRlZCBv biB0aGUgcHJvZ3Jlc3MNCg0KV2UndmUgbWFuYWdlZCB0byBzdHJpcCB0aGUgaGVhZGVycyBhbmQg cmVtb3ZlIF9fWEVOX18gYW5kIHRoZSByZXN0IGRlZmluaXRpb25zDQoNCndlIHdlcmUgdGFsa2lu ZyBhYm91dC4gU28sIHRoZXNlIGFyZSBub3cgdGhlIG1pbmltYWwgcmVxdWlyZWQgc2V0IG9mIGhl YWRlcnMNCg0KdGhhdCBhbGxvd3MgVS1ib290IHRvIGJ1aWxkIHNlcmlhbCBhbmQgYmxvY2sgZHJp dmVycy4gUGxlYXNlIHRha2UgYSBsb29rIGF0IFsxXQ0KDQpQdWxsIHJlcXVlc3QgZm9yIGNvbW1l bnRzIGlzIGF0IFsyXQ0KDQo+DQo+Pg0KPj4gSWYgeW91IGNhbiBkbyB0aGF0LCBJIHRoaW5rIGl0 IHdvdWxkIGJlIGJldHRlciBiZWNhdXNlIHdlIGRlY291cGxlIHRoZQ0KPj4gVUJvb3QgYnVpbGQg ZnJvbSB0aGUgWGVuIGJ1aWxkIGNvbXBsZXRlbHkuIFdlIGRvbid0IGV2ZW4gbmVlZCB0aGUgWGVu DQo+PiB0cmVlIGNoZWNrZWQgb3V0IHRvIGJ1aWxkIFVCb290LiBJdCB3b3VsZCBiZSBhIGh1Z2Ug YWR2YW50YWdlIGJlY2F1c2UgaXQNCj4+IG1ha2VzIGl0IGZhciBlYXNpZXIgdG8gYnVpbGQtdGVz dCBjaGFuZ2VzIGZvciBvdGhlcnMgaW4gdGhlIGNvbW11bml0eQ0KPj4gdGhhdCBkb24ndCBrbm93 IGFib3V0IFhlbiBhbmQgYWxzbyBpdCBiZWNvbWVzIGZhciBlYXNpZXIgdG8gaW50ZWdyYXRlDQo+ PiBpbnRvIGFueSBidWlsZCBzeXN0ZW0uDQoNClsxXSBodHRwczovL2dpdGh1Yi5jb20vYW5kcjIw MDAvdS1ib290L3RyZWUvcHZibG9ja191cHN0cmVhbV92MQ0KDQpbMl0gaHR0cHM6Ly9naXRodWIu Y29tL3hlbi10cm9vcHMvdS1ib290L3B1bGwvMg0K From xen-devel-bounces@lists.xenproject.org Wed Jun 24 07:07:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 07:07:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnzVN-0000zd-A3; Wed, 24 Jun 2020 07:07:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnzVM-0000zY-5Z for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 07:07:32 +0000 X-Inumbo-ID: 5e04580a-b5e9-11ea-bb8b-bc764e2007e4 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.82]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5e04580a-b5e9-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 07:07:30 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B/DYzwdMnvJ2TPy+wic8LeTaaEdVhKVZjgfIDTRm3AgCDZ8e0bK7UtIstzj4VPdJHuCIEVxibAtCKMs8QN4XqivMbMehIGlUkHagVEAn65uqgMiAd+yF3RmRpBTNllzNV2jrzbXHiKh84vA9PamVG5vEu0iEah2VcEmtwD4SJGyG1Y3KV5EZJR1hkiVlwMkOhhADUVaxJzyn1r81cxAHcfW5jx7qXneMogeX0jYYOWdZ7rZEHjNQ0FutHoPRzAUAfc+HoYlwYqJ2rpRm/DzzvakG7JY8nKRX+zsJkRsx8tG0vZWT0fl38KA4l73eWz1qAvlEoJenIPSoR4rNw1s6ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XhVCZHsTYAQ2sHAe79K3MDMengfDLUcty7W8L0dBlC4=; b=jXdIvLQfI/OGSCOjFbB6OEoCnv1WVRe/+eOexceVzmett4dfRPRjMIDCSzyCI2X+UekcQgu6Ae+ZMUfAIG5dHK1/rkSo0sA5tJhc0Ho13ItYzl/d9WBvixdJuO3yBTB1FeSKCYAHqEE/sxFBVXP8wjcxmo4bfi85+58RnsQkLfsqQQlknAVW/SfuxHw1SsekTnHcA5OLEWZUmhBBpvtJN3+H30u0/mlfw4cnxpRD1iy4o6oCW/dZcmZP/nNEZgMFW8G/+cKOZiyDFahvzG8UmKwvNbjGYd2HqH1mph0aOqlE+HadG0Z4gVOpXy3VJnHVmfVNO6HF/AnS+Z7HGxHrfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XhVCZHsTYAQ2sHAe79K3MDMengfDLUcty7W8L0dBlC4=; b=EVlnsduajgQ0q1FLE3tajHZxdCWuiRDnhCCmLQjqQqUzRWw+qlXDSqkO0ggTwHwzjNz/H8j/vGyl+mbV/1UKa+er0DH66dAfg3BjWpyr499lZvlf0j1I8vthZGTQ0weaTHL8ww54kgmKQqJRiuU1yQr4nKUPDxyeGtFlImi46IY= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2872.eurprd04.prod.outlook.com (2603:10a6:4:98::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 24 Jun 2020 07:07:28 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 07:07:28 +0000 From: Peng Fan To: Oleksandr Andrushchenko , Stefano Stabellini , Julien Grall Subject: RE: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWN5exllox/cqJUUS0HFcLChNz8ajHt2rggADieACAAAFjAIAVVnEAgACes4CAAHgUgIAADcUAgAFjwoCABFLagIAABoCAgAABwICAADaWgIAAfiIAgABGNACAAZ5agIAADjmA Date: Wed, 24 Jun 2020 07:07:28 +0000 Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: epam.com; dkim=none (message not signed) header.d=none;epam.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 97110725-8bda-4bd0-b5f0-08d8180d4166 x-ms-traffictypediagnostic: DB6PR0402MB2872: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mThc62YMrQgp85/jKRdWrRoAk4HabB37fpGie+hkj9eU9n7IcQSmKhxo5dT14qlzFOWelWXfleJ16hDj6hL9jA/93RL1Zc6qn/6yocvtjG07EUYL0E8m9NDDn6V0bisE7xFS/EhKOF3zPfbp35MnRrcJsBuhfpqbMuEX/LnO9nS+qaBVRkHFwh3+aAUjXiALvFa5BfsR1zEiwz6DPsmIq9T7TGalhJ7QpG+IMjQIrxXPi79OVCqjqPDBuy1pBkCwkl4gb++y7Xzvn8OMZ8QC+jRImu6l/IxOi6v/b4Ybz+EzihpesWKvWnWCVFZeG7WWjH2z8NoYtSmA0UPBwiB4/ALkzhj2H5PuYKeQ5wbSONsPLgVZ7QHs0pWL8Y0DAvEOu7g4AG4FEJcZAHTZfLeVBw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(346002)(376002)(136003)(39860400002)(66556008)(66476007)(66946007)(64756008)(54906003)(33656002)(4326008)(26005)(7696005)(6506007)(186003)(53546011)(8676002)(8936002)(45080400002)(55016002)(316002)(83080400001)(478600001)(966005)(2906002)(52536014)(76116006)(83380400001)(9686003)(66446008)(7416002)(110136005)(71200400001)(5660300002)(86362001)(44832011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2j4jyMbYo3nBeBtPVJ5O2S7k14otNi7e8BY+LJ0p7DY2jhbQAfWIVq2WDSIZ1DXUjissH63twQgpQ991Dnte1s0fWL13cK9VI8IMwMBGdZdcPCtfq3XuIOUGCzuhy2d6LEOp2SpMjiQk0pRVCjk13iF5x00nPjUcscXmLsujnxaCuFMVM9x9CwNJZ9N6ih1DH5m99Go0A5+dN+sYqVzgzdGuJbMAtpAZbse9wQeNCYiJj3TI/WJTnKbfIfJbLaAbzFusKgXVH6FAJMmtB12TGY1AafItEXhER70fTMNZk3RGGayB/f2QZ52DVlnxc4TBwiaVGORo1McCqUF1u1D/pkgonSHVTXhOJH7lOyAjFrByuTC//Qx4KDetTFAf1IKyY6Kg9cHja21lDHTE7ZKK/RlzCifxlXjHEn0xyZnNuDtb5aNiYKRkjrqeS1aOKKP44y+ORl+idSdo0tB3iVvU/gDJqFR0eqIRgqbSFOWhea4HUU0evX7a1t0+0jVHbTjG x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97110725-8bda-4bd0-b5f0-08d8180d4166 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 07:07:28.3227 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QUrnNIBP6Lg2ZRoIrkKgZ6PuVKbkrZ29xq+HjiUVtR24Acq5MmlhRtBtSgrxTSniDMZHJw319JfR6vV69uxkeg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2872 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiBTdWJqZWN0OiBSZTogVUVGSSBzdXBwb3J0IGluIEFSTSBEb21Vcw0KPiANCj4gDQo+IE9uIDYv MjMvMjAgODozMSBBTSwgT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gd3JvdGU6DQo+ID4NCj4gPiBP biA2LzIzLzIwIDQ6MjAgQU0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4gPj4gT24gTW9u LCAyMiBKdW4gMjAyMCwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPiA+Pj4+Pj4gRm9yIHRoZSBmaXJz dCBwYXJ0IChfX1hFTl9JTlRFUkZBQ0VfVkVSU0lPTl9fKSBJIHRoaW5rIHdlIGNhbg0KPiA+Pj4+ Pj4gcHJvdmlkZSBpdCB2aWENCj4gPj4+Pj4+DQo+ID4+Pj4+PiBDRkxBR1Mgb3Igc29tZXRoaW5n LiBUaGlzIGNhbiBhbHNvIGJlIGRvbmUgZm9yIHRoZSBsb2NhdGlvbiBvZg0KPiA+Pj4+Pj4gWGVu IGhlYWRlcnMuDQo+ID4+Pj4+IF9fWEVOX0lOVEVSRkFDRV9WRVJTSU9OX18gc2hvdWxkIHdvcmsg dGhyb3VnaCB0aGUgQ0ZMQUdTLiBBbg0KPiA+Pj4+PiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBh bGxvdyB0aGUgdXNlciB0byBzcGVjaWZ5IHRocm91Z2ggdGhlIEtjb25maWcuDQo+ID4+Pj4gWW91 IG1lYW4gc3BlY2lmeWluZyB2aWEgS2NvbmZpZyBzb21ldGhpbmcgbGlrZSAiMHgwMDA0MGQwMCI/ DQo+ID4+PiBQb3NzaWJseSB5ZXMuDQo+ID4+Pg0KPiA+Pj4+IEFuZCB3aGF0IGFib3V0IHRoZSBo ZWFkZXJzPyBIb3cgd2lsbCB3ZSBwcm92aWRlIHRoZWlyIGxvY2F0aW9uIGlmDQo+ID4+Pj4gd2Ug ZGVjaWRlIG5vdCB0byBpbmNsdWRlIHRob3NlDQo+ID4+Pj4NCj4gPj4+PiBpbiB0aGUgdHJlZT8N Cj4gPj4+IEkgd291bGQgZG8gdGhyb3VnaCBLY29uZmlnIGFzIHdlbGwuDQo+ID4+IElmIHdlIHNw ZWNpZnkgdGhlIGV4dGVybmFsIGxvY2F0aW9uIG9mIHRoZSBYZW4gaGVhZGVycyB2aWEgS2NvbmZp ZywNCj4gPj4gaXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBzaG91bGQgYmUgYWJsZSB0byBkZXRlY3Qg dGhlIGludGVyZmFjZSB2ZXJzaW9uDQo+ID4+IGF1dG9tYXRpY2FsbHkgZnJvbSBhbnkgTWFrZWZp bGUgYXMgcGFydCBvZiB0aGUgYnVpbGQuIE5vIG5lZWQgdG8gYXNrDQo+ID4+IHRoZSB1c2VyLg0K PiA+Pg0KPiA+PiBIb3dldmVyLCBpZiBPbGVrc2FuZHIgaXMgdGhpbmtpbmcgb2YgdXNpbmcgdGhl IFhlbiBoZWFkZXJzIGZvciB0aGUNCj4gPj4gaHlwZXJjYWxscyBkZWZpbml0aW9ucywgdGhlbiBJ IHRoaW5rIHdlIG1pZ2h0IG5vdCBuZWVkIGV4dGVybmFsDQo+ID4+IGhlYWRlcnMgYXQgYWxsIGJl Y2F1c2UgdGhhdCBpcyBhIHN0YWJsZSBpbnRlcmZhY2UsIGFzIEp1bGllbiB3cm90ZS4NCj4gPj4g V2UgY291bGQganVzdCBkZWZpbmUgb3VyIG93biBmZXcgaGVhZGVycyBmb3IganVzdCB3aGF0IHlv dSBuZWVkIGxpa2UgTGludXgNCj4gZG9lcy4NCj4gPg0KPiA+IFRoaXMgaXMgYSBnb29kIGlkZWE6 IEknbGwgdHJ5IHRvIGdldCB0aGUgbWluaW1hbCBzZXQgb2YgaGVhZGVycyBmcm9tDQo+ID4gTGlu dXgNCj4gPg0KPiA+IGluc3RlYWQgb2YgWGVuIGFzIHRob3NlIHNlZW0gdG8gYmUgd2VsbCBwcmVw YXJlZCBmb3Igc3VjaCBhIHVzZS1jYXNlLg0KPiA+IFRoaXMNCj4gPg0KPiA+IHdheSB3ZSdsbCBo YXZlIGhlYWRlcnMgaW4gVS1ib290IHRyZWUgYW5kIGd1YXJhbnRlZSB0aGF0IHdlIGhhdmUgYQ0K PiA+IG1pbmltYWwNCj4gPg0KPiA+IHN1YnNldCB3aGljaCBpcyBlYXNpZXIgdG8gbWFpbnRhaW4u IEknbGwga2VlcCB5b3UgdXBkYXRlZCBvbiB0aGUNCj4gPiBwcm9ncmVzcw0KPiANCj4gV2UndmUg bWFuYWdlZCB0byBzdHJpcCB0aGUgaGVhZGVycyBhbmQgcmVtb3ZlIF9fWEVOX18gYW5kIHRoZSBy ZXN0DQo+IGRlZmluaXRpb25zDQo+IA0KPiB3ZSB3ZXJlIHRhbGtpbmcgYWJvdXQuIFNvLCB0aGVz ZSBhcmUgbm93IHRoZSBtaW5pbWFsIHJlcXVpcmVkIHNldCBvZiBoZWFkZXJzDQo+IA0KPiB0aGF0 IGFsbG93cyBVLWJvb3QgdG8gYnVpbGQgc2VyaWFsIGFuZCBibG9jayBkcml2ZXJzLiBQbGVhc2Ug dGFrZSBhIGxvb2sgYXQgWzFdDQo+IA0KPiBQdWxsIHJlcXVlc3QgZm9yIGNvbW1lbnRzIGlzIGF0 IFsyXQ0KDQpUaGUgVS1Cb290IG5ldyBtZXJnZSB3aW5kb3cgd2lsbCBiZSBvcGVuIGluIDIwMjAv Ny8xLCBzbyBJJ2Qgc3VnZ2VzdA0KdGhlIHBhdGNoc2V0IGdvZXMgdG8gVS1Cb290IG1haWwgbGlz dCBmb3IgZGlzY3Vzc2lvbiBpZiB5b3Ugd2FubmEgdGhlIHBhdGNoZXMNCmdvbm5hIG1lcmdlZCBz b29uLg0KDQpSZWdhcmRzLA0KUGVuZy4NCg0KPiANCj4gPg0KPiA+Pg0KPiA+PiBJZiB5b3UgY2Fu IGRvIHRoYXQsIEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIGJlY2F1c2Ugd2UgZGVjb3VwbGUN Cj4gPj4gdGhlIFVCb290IGJ1aWxkIGZyb20gdGhlIFhlbiBidWlsZCBjb21wbGV0ZWx5LiBXZSBk b24ndCBldmVuIG5lZWQgdGhlDQo+ID4+IFhlbiB0cmVlIGNoZWNrZWQgb3V0IHRvIGJ1aWxkIFVC b290LiBJdCB3b3VsZCBiZSBhIGh1Z2UgYWR2YW50YWdlDQo+ID4+IGJlY2F1c2UgaXQgbWFrZXMg aXQgZmFyIGVhc2llciB0byBidWlsZC10ZXN0IGNoYW5nZXMgZm9yIG90aGVycyBpbg0KPiA+PiB0 aGUgY29tbXVuaXR5IHRoYXQgZG9uJ3Qga25vdyBhYm91dCBYZW4gYW5kIGFsc28gaXQgYmVjb21l cyBmYXINCj4gPj4gZWFzaWVyIHRvIGludGVncmF0ZSBpbnRvIGFueSBidWlsZCBzeXN0ZW0uDQo+ IA0KPiBbMV0NCj4gaHR0cHM6Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLg0KPiBjb20lMkZhbmRyMjAwMCUyRnUtYm9vdCUy RnRyZWUlMkZwdmJsb2NrX3Vwc3RyZWFtX3YxJmFtcDtkYXRhPTANCj4gMiU3QzAxJTdDcGVuZy5m YW4lNDBueHAuY29tJTdDNDA3ZDhhZjI0YTM2NDgzZmJkY2UwOGQ4MTgwNWVkODgNCj4gJTdDNjg2 ZWExZDNiYzJiNGM2ZmE5MmNkOTljNWMzMDE2MzUlN0MwJTdDMCU3QzYzNzI4NTc2MTAyMTk3NQ0K PiAxNjQmYW1wO3NkYXRhPTV2V2ZCYkxTY0lDWFBaV1UlMkJVM2I3RHlPTmNneFQ4aUlDc3hyd1Vi T1JaWSUNCj4gM0QmYW1wO3Jlc2VydmVkPTANCj4gDQo+IFsyXQ0KPiBodHRwczovL2V1cjAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIu DQo+IGNvbSUyRnhlbi10cm9vcHMlMkZ1LWJvb3QlMkZwdWxsJTJGMiZhbXA7ZGF0YT0wMiU3QzAx JTdDcGVuZy5mYQ0KPiBuJTQwbnhwLmNvbSU3QzQwN2Q4YWYyNGEzNjQ4M2ZiZGNlMDhkODE4MDVl ZDg4JTdDNjg2ZWExZDNiYzJiNA0KPiBjNmZhOTJjZDk5YzVjMzAxNjM1JTdDMCU3QzAlN0M2Mzcy ODU3NjEwMjE5NzUxNjQmYW1wO3NkYXRhPSUyDQo+IEZtWGhlRXZLc3NMamphRktzSEJCYnFoJTJC NzJqSDN1UW5FN2NwTjBKM2s4SSUzRCZhbXA7cmVzZXJ2ZWQ9MA0K From xen-devel-bounces@lists.xenproject.org Wed Jun 24 07:17:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 07:17:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnzey-0001xZ-CY; Wed, 24 Jun 2020 07:17:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnzew-0001xT-Ed for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 07:17:26 +0000 X-Inumbo-ID: c095f5a4-b5ea-11ea-b7bb-bc764e2007e4 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (unknown [40.107.20.65]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c095f5a4-b5ea-11ea-b7bb-bc764e2007e4; Wed, 24 Jun 2020 07:17:25 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PldPYImNNoCKjmYHyiqk2QZUEKKNrzKBewMYaoK4Ur732uSULnhp9AhiBzvvuCQUPL4vkR8nOT8JgcXK2Sq9vJbZQorNuO86O9NcSWvcPEs5rNP3U5ROpf33G9CRQvzsnpfVmbVB7VI2evdBxY2PmW0rVWx2mJXndhsMaIJWeJnmK27EiyNFDvpUSYVydOXbNtLwxLLneh9+JlCzaMrG7ZeDLnD4cyu5XIDHxH/9KhXHVRQjqzIV5VghHomKKMMYdgfKwCjVJczz+7csFqpC3uF23nPzEn9+9UOmP2q5pkY+W0rL3HkF2WJjdskVWIJPkGXglFstsG09fHeQoVsKDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8Es/g0CUgP46QKaZoI9vtQkjg822tBACsUFYgrC9e0Y=; b=EbAM+btYXntppn87yvI1Qk0VeLuf4gt/p5s+5I3hafFaHDqWRvSBPTjCgWqY3RcO9Z/MpWRFRKczf0KzlqvS+6IckyAMyO5zhSUbzy7z0jYQW7OgZzkmc7gdVe4kPPrA7C5h0mNjywwANQD6MNNichALlooS2pRSZSkEQLM/JrDTU1B/7IDdZRDt83p1WmqOHbdsvNFSx7wDVUioEDtIn3Ho0zlCWfMRuaGGdod6SIzc32Bxts1lDl0/qujbzBW8p+puTaNhapaeUmQNDJx+nC77vQrb+PVBUOxMR9Fny99ovaUwzMYJ57Y7h97UfJKGorZgH3WssQhNJTt5MJ1FsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8Es/g0CUgP46QKaZoI9vtQkjg822tBACsUFYgrC9e0Y=; b=li/xYypteU6tcb3nxIlyvxFcFoBrv4EqYhwzm3p7Udjw21gykSbnVAfiTNIZm3xwNFZzH6MVPjTa6oCpcW2u15Nx/cPAQd1Lns7izRvUCoykO/zPxIdgQnYojN1Ye/0mFYL5jTk0VLZIrSo4GcBDtdn34HS/y1uVaGjF62yx8a3BC9x6Mu/RPytr8Bjh2U1qyF9jlm6N0TnItSHZTKgkoDS1j7F48153pW8y+pzuO30sQyjHISaOGmnQ8r90GYJ/HW3Bpo668CNHD++jM6xFradw5t4JysFHm008IruFqWn9CtrKn4nJPqk6rBzgqIgGUBBP+Py6Xs6vfEAqiivSKg== Received: from AM6PR03MB3991.eurprd03.prod.outlook.com (2603:10a6:20b:25::20) by AM6PR03MB3688.eurprd03.prod.outlook.com (2603:10a6:209:35::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 24 Jun 2020 07:17:23 +0000 Received: from AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c]) by AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c%4]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 07:17:23 +0000 From: Oleksandr Andrushchenko To: Peng Fan , Stefano Stabellini , Julien Grall Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAWPDgIAEUtgAgAAGgYCAAAHAgIAANpaAgAB+IgCAAEYyAIABnlyAgAAOqgCAAALEAA== Date: Wed, 24 Jun 2020 07:17:23 +0000 Message-ID: <273d5fe8-dac9-6375-77df-e24f56066cfe@epam.com> References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 32b1efd2-7f78-45c5-4828-08d8180ea430 x-ms-traffictypediagnostic: AM6PR03MB3688: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tnFlYr40TeU9N5+NW8CzqbweOhRJwKjBiewEOfV0KMHd8j1aOMdMczq/yUK+9CCA2rcLQwyOR5z+VaUSxX+zXZqT82JkVkuA4Z7dj/Sv639dBZfY7WEM+jhZKlsKs54ne2eUxJwDpcMQ8d/j49tOuPiIvtqjdCGHyrEz0exErWJTySHtj28ys8+xxlTI9alcddyew3qdjBF3eBH0+qd3htRSkce0IvgItzTu7Dnzk7MSNfZTowB0EFA1SB1cZax8m7VfG9rbjex0+oVmiIi5T4gx1zfcwm9ZuzwoLG5eDDGi3HlbpCpyQ7nxB/AaM8YxMdQKl8FF7aN2+qgJ5GFlOUYS8im5wIQSlgP9srVgeJFzMjTfhEg1MehC1N6N903uuSUdb7wRvh/CMlJfCa/MyA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR03MB3991.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(346002)(366004)(376002)(53546011)(2616005)(6506007)(186003)(86362001)(31696002)(5660300002)(76116006)(966005)(91956017)(66946007)(83380400001)(26005)(7416002)(66476007)(31686004)(64756008)(66556008)(110136005)(2906002)(54906003)(45080400002)(478600001)(66446008)(8936002)(4326008)(316002)(71200400001)(36756003)(6486002)(8676002)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: IZdgxaglixY+MUdUoQcOYTB4nkL2nmnJ4zLGKuwV8W+iOWhhMsNdzbrM9Fy7IH/QrOYw0c4wsqy9aj7c1Ucwdfy0qUam/iqZ02uwUqZHqgdK1p6xp6rG92nEN1llHIik7B3K0S8lVtddpgeDOMzF7Lcg7sd28mmiLwsismt3+FpT+xpOrquNlVCKK/d5yDhJWKryKPxLeoiXcNUhpVXQDAVCdzuIupQGfAThCFGp7lrHTxGbq1kdk1uGYUDwIJxVlet6Mcrh7v5ZQPaEvzo9L0AkX3YA5AJTew0q9vodT/Csb/RrUzTzR5frwv8pnx9ZTrqJTBS8dXCVQ2COaZnVOWAYhpbCT6qCeNi3Hs0fthFXn/KIC08Ur8vivjnv6Gdz0ZLx4KraU0dDIkEzw7wyhTp+epeMsVNtTHhwlsUqJQEnSYrsW385Ei/S/1cXkIuD6YHhnQAUL63Dq6q4wRnJ1o2wuXtJAAa4qtaImNbYYgg= Content-Type: text/plain; charset="utf-8" Content-ID: <396295CCE294DA43B8898190689BE266@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 32b1efd2-7f78-45c5-4828-08d8180ea430 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 07:17:23.5002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wVpEm/Sj32diK6ktOB7jfF8fxr0kZT6hHYXsnOB9L4yJ6VDsw50TwHa8ctf/iM9rrMbS8v0W0yM4mQ6hElkzRNSIXd0Jxn+Lk92t8VVdCN95bvSNBc5NLAo9kTWzi/MT X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB3688 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzI0LzIwIDEwOjA3IEFNLCBQZW5nIEZhbiB3cm90ZToNCj4+IFN1YmplY3Q6IFJlOiBV RUZJIHN1cHBvcnQgaW4gQVJNIERvbVVzDQo+Pg0KPj4NCj4+IE9uIDYvMjMvMjAgODozMSBBTSwg T2xla3NhbmRyIEFuZHJ1c2hjaGVua28gd3JvdGU6DQo+Pj4gT24gNi8yMy8yMCA0OjIwIEFNLCBT dGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+Pj4+IE9uIE1vbiwgMjIgSnVuIDIwMjAsIEp1bGll biBHcmFsbCB3cm90ZToNCj4+Pj4+Pj4+IEZvciB0aGUgZmlyc3QgcGFydCAoX19YRU5fSU5URVJG QUNFX1ZFUlNJT05fXykgSSB0aGluayB3ZSBjYW4NCj4+Pj4+Pj4+IHByb3ZpZGUgaXQgdmlhDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQ0ZMQUdTIG9yIHNvbWV0aGluZy4gVGhpcyBjYW4gYWxzbyBiZSBk b25lIGZvciB0aGUgbG9jYXRpb24gb2YNCj4+Pj4+Pj4+IFhlbiBoZWFkZXJzLg0KPj4+Pj4+PiBf X1hFTl9JTlRFUkZBQ0VfVkVSU0lPTl9fIHNob3VsZCB3b3JrIHRocm91Z2ggdGhlIENGTEFHUy4g QW4NCj4+Pj4+Pj4gYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gYWxsb3cgdGhlIHVzZXIgdG8gc3Bl Y2lmeSB0aHJvdWdoIHRoZSBLY29uZmlnLg0KPj4+Pj4+IFlvdSBtZWFuIHNwZWNpZnlpbmcgdmlh IEtjb25maWcgc29tZXRoaW5nIGxpa2UgIjB4MDAwNDBkMDAiPw0KPj4+Pj4gUG9zc2libHkgeWVz Lg0KPj4+Pj4NCj4+Pj4+PiBBbmQgd2hhdCBhYm91dCB0aGUgaGVhZGVycz8gSG93IHdpbGwgd2Ug cHJvdmlkZSB0aGVpciBsb2NhdGlvbiBpZg0KPj4+Pj4+IHdlIGRlY2lkZSBub3QgdG8gaW5jbHVk ZSB0aG9zZQ0KPj4+Pj4+DQo+Pj4+Pj4gaW4gdGhlIHRyZWU/DQo+Pj4+PiBJIHdvdWxkIGRvIHRo cm91Z2ggS2NvbmZpZyBhcyB3ZWxsLg0KPj4+PiBJZiB3ZSBzcGVjaWZ5IHRoZSBleHRlcm5hbCBs b2NhdGlvbiBvZiB0aGUgWGVuIGhlYWRlcnMgdmlhIEtjb25maWcsDQo+Pj4+IGl0IHNlZW1zIHRv IG1lIHRoYXQgd2Ugc2hvdWxkIGJlIGFibGUgdG8gZGV0ZWN0IHRoZSBpbnRlcmZhY2UgdmVyc2lv bg0KPj4+PiBhdXRvbWF0aWNhbGx5IGZyb20gYW55IE1ha2VmaWxlIGFzIHBhcnQgb2YgdGhlIGJ1 aWxkLiBObyBuZWVkIHRvIGFzaw0KPj4+PiB0aGUgdXNlci4NCj4+Pj4NCj4+Pj4gSG93ZXZlciwg aWYgT2xla3NhbmRyIGlzIHRoaW5raW5nIG9mIHVzaW5nIHRoZSBYZW4gaGVhZGVycyBmb3IgdGhl DQo+Pj4+IGh5cGVyY2FsbHMgZGVmaW5pdGlvbnMsIHRoZW4gSSB0aGluayB3ZSBtaWdodCBub3Qg bmVlZCBleHRlcm5hbA0KPj4+PiBoZWFkZXJzIGF0IGFsbCBiZWNhdXNlIHRoYXQgaXMgYSBzdGFi bGUgaW50ZXJmYWNlLCBhcyBKdWxpZW4gd3JvdGUuDQo+Pj4+IFdlIGNvdWxkIGp1c3QgZGVmaW5l IG91ciBvd24gZmV3IGhlYWRlcnMgZm9yIGp1c3Qgd2hhdCB5b3UgbmVlZCBsaWtlIExpbnV4DQo+ PiBkb2VzLg0KPj4+IFRoaXMgaXMgYSBnb29kIGlkZWE6IEknbGwgdHJ5IHRvIGdldCB0aGUgbWlu aW1hbCBzZXQgb2YgaGVhZGVycyBmcm9tDQo+Pj4gTGludXgNCj4+Pg0KPj4+IGluc3RlYWQgb2Yg WGVuIGFzIHRob3NlIHNlZW0gdG8gYmUgd2VsbCBwcmVwYXJlZCBmb3Igc3VjaCBhIHVzZS1jYXNl Lg0KPj4+IFRoaXMNCj4+Pg0KPj4+IHdheSB3ZSdsbCBoYXZlIGhlYWRlcnMgaW4gVS1ib290IHRy ZWUgYW5kIGd1YXJhbnRlZSB0aGF0IHdlIGhhdmUgYQ0KPj4+IG1pbmltYWwNCj4+Pg0KPj4+IHN1 YnNldCB3aGljaCBpcyBlYXNpZXIgdG8gbWFpbnRhaW4uIEknbGwga2VlcCB5b3UgdXBkYXRlZCBv biB0aGUNCj4+PiBwcm9ncmVzcw0KPj4gV2UndmUgbWFuYWdlZCB0byBzdHJpcCB0aGUgaGVhZGVy cyBhbmQgcmVtb3ZlIF9fWEVOX18gYW5kIHRoZSByZXN0DQo+PiBkZWZpbml0aW9ucw0KPj4NCj4+ IHdlIHdlcmUgdGFsa2luZyBhYm91dC4gU28sIHRoZXNlIGFyZSBub3cgdGhlIG1pbmltYWwgcmVx dWlyZWQgc2V0IG9mIGhlYWRlcnMNCj4+DQo+PiB0aGF0IGFsbG93cyBVLWJvb3QgdG8gYnVpbGQg c2VyaWFsIGFuZCBibG9jayBkcml2ZXJzLiBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgWzFdDQo+Pg0K Pj4gUHVsbCByZXF1ZXN0IGZvciBjb21tZW50cyBpcyBhdCBbMl0NCj4gVGhlIFUtQm9vdCBuZXcg bWVyZ2Ugd2luZG93IHdpbGwgYmUgb3BlbiBpbiAyMDIwLzcvMSwgc28gSSdkIHN1Z2dlc3QNCj4g dGhlIHBhdGNoc2V0IGdvZXMgdG8gVS1Cb290IG1haWwgbGlzdCBmb3IgZGlzY3Vzc2lvbiBpZiB5 b3Ugd2FubmEgdGhlIHBhdGNoZXMNCj4gZ29ubmEgbWVyZ2VkIHNvb24uDQoNCldlIGRlZmluaXRl bHkgd2FudCB0aGUgcGF0Y2hlcyB0byBiZSB1cHN0cmVhbWVkIGFuZCBtZXJnZWQsIGJ1dCBiZWZv cmUgdGhhdA0KDQp3ZSBhbHNvIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgWGVuIGNvbW11bml0eSBp cyBoYXBweSB3aXRoIHdoYXQgd2UgdXBzdHJlYW0NCg0KSSBiZWxpZXZlIHdlIHJlc29sdmVkIG1v c3Qgb2YgdGhlIGNvbmNlcm5zIHN1Y2ggYXMgaGVhZGVycywgUElFIGV0Yywgc28gdGhpcyBjYW4N Cg0KYmUgZG9uZS4NCg0KQlRXLCBQZW5nLCBkaWQgeW91IGhhdmUgYSBjaGFuY2UgdG8gdHJ5IHRo ZSBwdmJsb2NrIGRyaXZlciB5ZXQ/DQoNCj4NCj4gUmVnYXJkcywNCj4gUGVuZy4NCj4NCj4+Pj4g SWYgeW91IGNhbiBkbyB0aGF0LCBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciBiZWNhdXNlIHdl IGRlY291cGxlDQo+Pj4+IHRoZSBVQm9vdCBidWlsZCBmcm9tIHRoZSBYZW4gYnVpbGQgY29tcGxl dGVseS4gV2UgZG9uJ3QgZXZlbiBuZWVkIHRoZQ0KPj4+PiBYZW4gdHJlZSBjaGVja2VkIG91dCB0 byBidWlsZCBVQm9vdC4gSXQgd291bGQgYmUgYSBodWdlIGFkdmFudGFnZQ0KPj4+PiBiZWNhdXNl IGl0IG1ha2VzIGl0IGZhciBlYXNpZXIgdG8gYnVpbGQtdGVzdCBjaGFuZ2VzIGZvciBvdGhlcnMg aW4NCj4+Pj4gdGhlIGNvbW11bml0eSB0aGF0IGRvbid0IGtub3cgYWJvdXQgWGVuIGFuZCBhbHNv IGl0IGJlY29tZXMgZmFyDQo+Pj4+IGVhc2llciB0byBpbnRlZ3JhdGUgaW50byBhbnkgYnVpbGQg c3lzdGVtLg0KPj4gWzFdDQo+PiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9l dXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzKjNBKjJGKjJG Z2l0aHViX187SlNVbCEhR0ZfMjlkYmNRSVVCUEEhbXdpYjN1bjYtdllCRzY4ek1mdXJXNi0wTXV1 RVI1dE5tSnRPaXREcFZpSUNOa1gwbGhpZzhpUEhtWm9rdU0tQkxRWXBlS1lBR1EkIC4NCj4+IGNv bSUyRmFuZHIyMDAwJTJGdS1ib290JTJGdHJlZSUyRnB2YmxvY2tfdXBzdHJlYW1fdjEmYW1wO2Rh dGE9MA0KPj4gMiU3QzAxJTdDcGVuZy5mYW4lNDBueHAuY29tJTdDNDA3ZDhhZjI0YTM2NDgzZmJk Y2UwOGQ4MTgwNWVkODgNCj4+ICU3QzY4NmVhMWQzYmMyYjRjNmZhOTJjZDk5YzVjMzAxNjM1JTdD MCU3QzAlN0M2MzcyODU3NjEwMjE5NzUNCj4+IDE2NCZhbXA7c2RhdGE9NXZXZkJiTFNjSUNYUFpX VSUyQlUzYjdEeU9OY2d4VDhpSUNzeHJ3VWJPUlpZJQ0KPj4gM0QmYW1wO3Jlc2VydmVkPTANCj4+ DQo+PiBbMl0NCj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2V1cjAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMqM0EqMkYqMkZnaXRodWJf XztKU1VsISFHRl8yOWRiY1FJVUJQQSFtd2liM3VuNi12WUJHNjh6TWZ1clc2LTBNdXVFUjV0Tm1K dE9pdERwVmlJQ05rWDBsaGlnOGlQSG1ab2t1TS1CTFFZcGVLWUFHUSQgLg0KPj4gY29tJTJGeGVu LXRyb29wcyUyRnUtYm9vdCUyRnB1bGwlMkYyJmFtcDtkYXRhPTAyJTdDMDElN0NwZW5nLmZhDQo+ PiBuJTQwbnhwLmNvbSU3QzQwN2Q4YWYyNGEzNjQ4M2ZiZGNlMDhkODE4MDVlZDg4JTdDNjg2ZWEx ZDNiYzJiNA0KPj4gYzZmYTkyY2Q5OWM1YzMwMTYzNSU3QzAlN0MwJTdDNjM3Mjg1NzYxMDIxOTc1 MTY0JmFtcDtzZGF0YT0lMg0KPj4gRm1YaGVFdktzc0xqamFGS3NIQkJicWglMkI3MmpIM3VRbkU3 Y3BOMEozazhJJTNEJmFtcDtyZXNlcnZlZD0w From xen-devel-bounces@lists.xenproject.org Wed Jun 24 07:26:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 07:26:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnznX-0002sA-9M; Wed, 24 Jun 2020 07:26:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnznW-0002s5-Fm for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 07:26:18 +0000 X-Inumbo-ID: fd895978-b5eb-11ea-8496-bc764e2007e4 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.53]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fd895978-b5eb-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 07:26:17 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KaP83evpfiFrhQ7YndWhFzmexrdhzr/n3zFy5hL1wwczdRtI6AbzCT92Y4twMfhBwasc2kL95dXtHWiS6+iN8P7/2Vi+Wyjkuo3pYd0incrDn20qsA4+EpsWk7uW9qGLAQz2wI6VIqnWWF+SFWALRMNIJew9Eyp5eEaofpbF45SkEO4chfoQrvKdux6aOm6bs+uStjCDw+7Mvs8SZI4EL5SPLYPX4meMAJolfR0fFcxWYE9+PIVysmFLLy6HOXY7dur58qX9MmYaiX98VE1I5B3jpH4AFhbGqRXIYw/s/6I/P9iRyhsvoDXs2gDwFvS0ocjdYTC6Jr6HMLifDS9zqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XMMv61XXOQWfosc8Ey6sbPGilo1JimUvb19FuUx/t/Y=; b=goKMsCEV8kLlXLUoUzkJyMvgoAbGltBIQnrTP4clSQfXVB96zzzixAnYqhIrY4BHECs8dVs1xE1gYV6Kp6iwxLyudk24uAOUGHOj2QwkDPGsNfQEjdgG01KnYuZ+MlIPX6TKml8xL3U3+HwrbAk3rdqxII68XFYMZucZlWzrx6SYxzGiHefT2SPiaQR+lmgKvstYiFxDoZyOcuJBxv+FsPnVhZg7PtD030m3osfV9H1WSIV/1+7Dm8JRY1o9eYcKALodd+KVItO5KXiDp//pKUihJryXnABUI0GSyYumXBgpCSO+YpbzLR9ffv1QJepOpQq3NYubFdutE0iWoCR7TQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XMMv61XXOQWfosc8Ey6sbPGilo1JimUvb19FuUx/t/Y=; b=kZwU8ffjV/6uSA4XDElACvphJMRKdfVu7PA5Z94TH7fBa68/2T9cXFIEGCpNzL7/h+t++Eeg+0+v6V2zLHUJwwsoPHSTJgJXxWnH+fgQDntEEiB5njg9Sp/TZDAny+mEJR+zhvCSN+2lSnObbkQWVjk8fr3ra47yVEqVap7M7nQ= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2807.eurprd04.prod.outlook.com (2603:10a6:4:96::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 24 Jun 2020 07:26:15 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 07:26:15 +0000 From: Peng Fan To: Oleksandr Andrushchenko , Stefano Stabellini , Julien Grall Subject: RE: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWN5exllox/cqJUUS0HFcLChNz8ajHt2rggADieACAAAFjAIAVVnEAgACes4CAAHgUgIAADcUAgAFjwoCABFLagIAABoCAgAABwICAADaWgIAAfiIAgABGNACAAZ5agIAADjmAgAADNoCAAAB6UA== Date: Wed, 24 Jun 2020 07:26:15 +0000 Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> <273d5fe8-dac9-6375-77df-e24f56066cfe@epam.com> In-Reply-To: <273d5fe8-dac9-6375-77df-e24f56066cfe@epam.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: epam.com; dkim=none (message not signed) header.d=none;epam.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6a923628-bb00-4005-25fd-08d8180fe147 x-ms-traffictypediagnostic: DB6PR0402MB2807: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ieNsUU6/Yl10gii2ungivVojJgP8KGilGOjUwlpqINMYIDVClK/e6altj6YnBN94/R+kdhnMvjE4pBC7VHgOB8x5qj3BO2EKPO8U4q6OkSYwTsbhUNiDry5EwSiVCG5GwOi5RFYOFdNp0sIJQkCSAnYEDnItf4lPsgaLWzUIF8Dzn6O5r5TLjATRqrxPIZsRBtNItjrynmG5JQRpjMzinUULs1qm1vERYFV1+2bUGObxzs/ypNg/Z2jFS0A0wl96/lvUbMkXGB8ZT0vBt9zjsxWwC5OjxztqaCnKQCpnwVXiq0OGxtd/zuYJ259rAUzu/IbkX16WtZ21HdFjEuz+8qUT9KVrwpCXwg5jPhvliR8y1P8YKjUDcIOux6nWlPwLExtZdHcwUyHTfZJWXBqZFQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(376002)(136003)(396003)(366004)(53546011)(6506007)(9686003)(5660300002)(8676002)(66556008)(8936002)(86362001)(7416002)(66946007)(186003)(66476007)(26005)(66446008)(64756008)(2906002)(76116006)(55016002)(4326008)(7696005)(54906003)(83380400001)(110136005)(71200400001)(52536014)(33656002)(316002)(83080400001)(966005)(478600001)(45080400002)(44832011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: jZMVlZbzmsOcguGK5ZB3qRPWMo2lhCH/A3/iGQrrUAl1KWKHYVxOe1azdwVL2vq6MphUXXcOUIs4QchmxsSUdwq7Nkl/lBgeM+TAmzIdQhHlT22iCcWF41YlGfZPTsA9icXLHEKSiwkGMIRqum/oLDHmKFuCb0CMhuChMMSSnAswdWNgLYcLQMRR0PV4OtKtChBl5egNbwGr1dOYjr4RfcnQzhVqSClXScKzf6qHK/xRGORHovKXV2gWlpywDCkG1f9x2JLSyjJjjYdQLTtY90pFoMgv81yCuQ3KHw7DyxfVMs0W7y7F3us/Oc+2xwr6Xr3X0qRXNC5Lr02zVNoIV1/BCF6OJDnC9ovBnQ6fgDSyQ45qx9cr5tRF5VmKJk3wv/cK/VDn7lEk5l0vuIikCUhN5HMuLrqaDpFH6jnWvywtbZXkhhplbJhy5GZjHNaHniOEbPZwxYLnMrRqmWoeppyzcDEJG1I+cmIbPJgQ4uFDT0J9XTeAO04oQ3burOGu x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a923628-bb00-4005-25fd-08d8180fe147 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 07:26:15.4458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: n1tx57XG/21+TF69Zg5SRgd3aSFMHxSJKD+vDUrHtpXT/UHYr/Uxqqt84yOYh3nqgZfbG/nICPgXq0qO3ofqsg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2807 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" PiBTdWJqZWN0OiBSZTogVUVGSSBzdXBwb3J0IGluIEFSTSBEb21Vcw0KPiANCj4gDQo+IE9uIDYv MjQvMjAgMTA6MDcgQU0sIFBlbmcgRmFuIHdyb3RlOg0KPiA+PiBTdWJqZWN0OiBSZTogVUVGSSBz dXBwb3J0IGluIEFSTSBEb21Vcw0KPiA+Pg0KPiA+Pg0KPiA+PiBPbiA2LzIzLzIwIDg6MzEgQU0s IE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPiA+Pj4gT24gNi8yMy8yMCA0OjIwIEFN LCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+ID4+Pj4gT24gTW9uLCAyMiBKdW4gMjAyMCwg SnVsaWVuIEdyYWxsIHdyb3RlOg0KPiA+Pj4+Pj4+PiBGb3IgdGhlIGZpcnN0IHBhcnQgKF9fWEVO X0lOVEVSRkFDRV9WRVJTSU9OX18pIEkgdGhpbmsgd2UgY2FuDQo+ID4+Pj4+Pj4+IHByb3ZpZGUg aXQgdmlhDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IENGTEFHUyBvciBzb21ldGhpbmcuIFRoaXMg Y2FuIGFsc28gYmUgZG9uZSBmb3IgdGhlIGxvY2F0aW9uIG9mDQo+ID4+Pj4+Pj4+IFhlbiBoZWFk ZXJzLg0KPiA+Pj4+Pj4+IF9fWEVOX0lOVEVSRkFDRV9WRVJTSU9OX18gc2hvdWxkIHdvcmsgdGhy b3VnaCB0aGUgQ0ZMQUdTLg0KPiBBbg0KPiA+Pj4+Pj4+IGFsdGVybmF0aXZlIHdvdWxkIGJlIHRv IGFsbG93IHRoZSB1c2VyIHRvIHNwZWNpZnkgdGhyb3VnaCB0aGUNCj4gS2NvbmZpZy4NCj4gPj4+ Pj4+IFlvdSBtZWFuIHNwZWNpZnlpbmcgdmlhIEtjb25maWcgc29tZXRoaW5nIGxpa2UgIjB4MDAw NDBkMDAiPw0KPiA+Pj4+PiBQb3NzaWJseSB5ZXMuDQo+ID4+Pj4+DQo+ID4+Pj4+PiBBbmQgd2hh dCBhYm91dCB0aGUgaGVhZGVycz8gSG93IHdpbGwgd2UgcHJvdmlkZSB0aGVpciBsb2NhdGlvbiBp Zg0KPiA+Pj4+Pj4gd2UgZGVjaWRlIG5vdCB0byBpbmNsdWRlIHRob3NlDQo+ID4+Pj4+Pg0KPiA+ Pj4+Pj4gaW4gdGhlIHRyZWU/DQo+ID4+Pj4+IEkgd291bGQgZG8gdGhyb3VnaCBLY29uZmlnIGFz IHdlbGwuDQo+ID4+Pj4gSWYgd2Ugc3BlY2lmeSB0aGUgZXh0ZXJuYWwgbG9jYXRpb24gb2YgdGhl IFhlbiBoZWFkZXJzIHZpYSBLY29uZmlnLA0KPiA+Pj4+IGl0IHNlZW1zIHRvIG1lIHRoYXQgd2Ug c2hvdWxkIGJlIGFibGUgdG8gZGV0ZWN0IHRoZSBpbnRlcmZhY2UNCj4gPj4+PiB2ZXJzaW9uIGF1 dG9tYXRpY2FsbHkgZnJvbSBhbnkgTWFrZWZpbGUgYXMgcGFydCBvZiB0aGUgYnVpbGQuIE5vDQo+ ID4+Pj4gbmVlZCB0byBhc2sgdGhlIHVzZXIuDQo+ID4+Pj4NCj4gPj4+PiBIb3dldmVyLCBpZiBP bGVrc2FuZHIgaXMgdGhpbmtpbmcgb2YgdXNpbmcgdGhlIFhlbiBoZWFkZXJzIGZvciB0aGUNCj4g Pj4+PiBoeXBlcmNhbGxzIGRlZmluaXRpb25zLCB0aGVuIEkgdGhpbmsgd2UgbWlnaHQgbm90IG5l ZWQgZXh0ZXJuYWwNCj4gPj4+PiBoZWFkZXJzIGF0IGFsbCBiZWNhdXNlIHRoYXQgaXMgYSBzdGFi bGUgaW50ZXJmYWNlLCBhcyBKdWxpZW4gd3JvdGUuDQo+ID4+Pj4gV2UgY291bGQganVzdCBkZWZp bmUgb3VyIG93biBmZXcgaGVhZGVycyBmb3IganVzdCB3aGF0IHlvdSBuZWVkDQo+ID4+Pj4gbGlr ZSBMaW51eA0KPiA+PiBkb2VzLg0KPiA+Pj4gVGhpcyBpcyBhIGdvb2QgaWRlYTogSSdsbCB0cnkg dG8gZ2V0IHRoZSBtaW5pbWFsIHNldCBvZiBoZWFkZXJzIGZyb20NCj4gPj4+IExpbnV4DQo+ID4+ Pg0KPiA+Pj4gaW5zdGVhZCBvZiBYZW4gYXMgdGhvc2Ugc2VlbSB0byBiZSB3ZWxsIHByZXBhcmVk IGZvciBzdWNoIGEgdXNlLWNhc2UuDQo+ID4+PiBUaGlzDQo+ID4+Pg0KPiA+Pj4gd2F5IHdlJ2xs IGhhdmUgaGVhZGVycyBpbiBVLWJvb3QgdHJlZSBhbmQgZ3VhcmFudGVlIHRoYXQgd2UgaGF2ZSBh DQo+ID4+PiBtaW5pbWFsDQo+ID4+Pg0KPiA+Pj4gc3Vic2V0IHdoaWNoIGlzIGVhc2llciB0byBt YWludGFpbi4gSSdsbCBrZWVwIHlvdSB1cGRhdGVkIG9uIHRoZQ0KPiA+Pj4gcHJvZ3Jlc3MNCj4g Pj4gV2UndmUgbWFuYWdlZCB0byBzdHJpcCB0aGUgaGVhZGVycyBhbmQgcmVtb3ZlIF9fWEVOX18g YW5kIHRoZSByZXN0DQo+ID4+IGRlZmluaXRpb25zDQo+ID4+DQo+ID4+IHdlIHdlcmUgdGFsa2lu ZyBhYm91dC4gU28sIHRoZXNlIGFyZSBub3cgdGhlIG1pbmltYWwgcmVxdWlyZWQgc2V0IG9mDQo+ ID4+IGhlYWRlcnMNCj4gPj4NCj4gPj4gdGhhdCBhbGxvd3MgVS1ib290IHRvIGJ1aWxkIHNlcmlh bCBhbmQgYmxvY2sgZHJpdmVycy4gUGxlYXNlIHRha2UgYQ0KPiA+PiBsb29rIGF0IFsxXQ0KPiA+ Pg0KPiA+PiBQdWxsIHJlcXVlc3QgZm9yIGNvbW1lbnRzIGlzIGF0IFsyXQ0KPiA+IFRoZSBVLUJv b3QgbmV3IG1lcmdlIHdpbmRvdyB3aWxsIGJlIG9wZW4gaW4gMjAyMC83LzEsIHNvIEknZCBzdWdn ZXN0DQo+ID4gdGhlIHBhdGNoc2V0IGdvZXMgdG8gVS1Cb290IG1haWwgbGlzdCBmb3IgZGlzY3Vz c2lvbiBpZiB5b3Ugd2FubmEgdGhlDQo+ID4gcGF0Y2hlcyBnb25uYSBtZXJnZWQgc29vbi4NCj4g DQo+IFdlIGRlZmluaXRlbHkgd2FudCB0aGUgcGF0Y2hlcyB0byBiZSB1cHN0cmVhbWVkIGFuZCBt ZXJnZWQsIGJ1dCBiZWZvcmUNCj4gdGhhdA0KPiANCj4gd2UgYWxzbyB3YW50IHRvIG1ha2Ugc3Vy ZSB0aGF0IFhlbiBjb21tdW5pdHkgaXMgaGFwcHkgd2l0aCB3aGF0IHdlDQo+IHVwc3RyZWFtDQo+ IA0KPiBJIGJlbGlldmUgd2UgcmVzb2x2ZWQgbW9zdCBvZiB0aGUgY29uY2VybnMgc3VjaCBhcyBo ZWFkZXJzLCBQSUUgZXRjLCBzbyB0aGlzDQo+IGNhbg0KPiANCj4gYmUgZG9uZS4NCj4gDQo+IEJU VywgUGVuZywgZGlkIHlvdSBoYXZlIGEgY2hhbmNlIHRvIHRyeSB0aGUgcHZibG9jayBkcml2ZXIg eWV0Pw0KDQpOb3QgeWV0LiBJIGNvdWxkIGhhdmUgdGltZSB0byBnaXZlIGEgdGVzdCBuZXh0IE1v bmRheS4gSSB0aGluayB5b3Ugbm90DQplbmFibGUgU1BMLCByaWdodD8gU28gYW5kcm9pZCBkdWFs IGJvb3Rsb2FkZXIgZmVhdHVyZSBub3QgZW5hYmxlZC4NCkJ1dCBTUEwgbW9zdGx5IG5vdCBoYXZl IE1NVSBlbmFibGVkLi4NCg0KUmVnYXJkcywNClBlbmcuDQoNCj4gDQo+ID4NCj4gPiBSZWdhcmRz LA0KPiA+IFBlbmcuDQo+ID4NCj4gPj4+PiBJZiB5b3UgY2FuIGRvIHRoYXQsIEkgdGhpbmsgaXQg d291bGQgYmUgYmV0dGVyIGJlY2F1c2Ugd2UgZGVjb3VwbGUNCj4gPj4+PiB0aGUgVUJvb3QgYnVp bGQgZnJvbSB0aGUgWGVuIGJ1aWxkIGNvbXBsZXRlbHkuIFdlIGRvbid0IGV2ZW4gbmVlZA0KPiA+ Pj4+IHRoZSBYZW4gdHJlZSBjaGVja2VkIG91dCB0byBidWlsZCBVQm9vdC4gSXQgd291bGQgYmUg YSBodWdlDQo+ID4+Pj4gYWR2YW50YWdlIGJlY2F1c2UgaXQgbWFrZXMgaXQgZmFyIGVhc2llciB0 byBidWlsZC10ZXN0IGNoYW5nZXMgZm9yDQo+ID4+Pj4gb3RoZXJzIGluIHRoZSBjb21tdW5pdHkg dGhhdCBkb24ndCBrbm93IGFib3V0IFhlbiBhbmQgYWxzbyBpdA0KPiA+Pj4+IGJlY29tZXMgZmFy IGVhc2llciB0byBpbnRlZ3JhdGUgaW50byBhbnkgYnVpbGQgc3lzdGVtLg0KPiA+PiBbMV0NCj4g Pj4NCj4gaHR0cHM6Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGdXJsZGVmDQo+IGVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGJTJG ZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jDQo+IG9tJTJGJTNGdXJsJTNEaHR0 cHMqM0EqMkYqMkZnaXRodWJfXyUzQkpTVWwhIUdGXzI5ZGJjUUlVQlBBIW13aQ0KPiBiM3VuNi12 WUJHNjh6TWZ1clc2LTBNdXVFUjV0Tm1KdE9pdERwVmlJQ05rWDBsaGlnOGlQSG1ab2t1TS1CTFEN Cj4gWXBlS1lBR1ElMjQmYW1wO2RhdGE9MDIlN0MwMSU3Q3BlbmcuZmFuJTQwbnhwLmNvbSU3Qzk1 MGQ5YzBhDQo+IGRjNTE0OTI3Y2U4YjA4ZDgxODBlYTRlZiU3QzY4NmVhMWQzYmMyYjRjNmZhOTJj ZDk5YzVjMzAxNjM1JTdDDQo+IDAlN0MwJTdDNjM3Mjg1Nzk4NDYwNTYzOTE0JmFtcDtzZGF0YT1m TXJJJTJGUW90a25Dc1hWMGFtQzRCRmwNCj4gMUhnNHZQdzN6T01WZEFWaW0yV2NzJTNEJmFtcDty ZXNlcnZlZD0wIC4NCj4gPj4NCj4gY29tJTJGYW5kcjIwMDAlMkZ1LWJvb3QlMkZ0cmVlJTJGcHZi bG9ja191cHN0cmVhbV92MSZhbXA7ZGF0YT0wDQo+ID4+DQo+IDIlN0MwMSU3Q3BlbmcuZmFuJTQw bnhwLmNvbSU3QzQwN2Q4YWYyNGEzNjQ4M2ZiZGNlMDhkODE4MDVlZDg4DQo+ID4+ICU3QzY4NmVh MWQzYmMyYjRjNmZhOTJjZDk5YzVjMzAxNjM1JTdDMCU3QzAlN0M2MzcyODU3NjEwMjENCj4gOTc1 DQo+ID4+DQo+IDE2NCZhbXA7c2RhdGE9NXZXZkJiTFNjSUNYUFpXVSUyQlUzYjdEeU9OY2d4VDhp SUNzeHJ3VWJPUlpZJQ0KPiA+PiAzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiA+Pg0KPiA+PiBbMl0NCj4g Pj4NCj4gaHR0cHM6Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGdXJsZGVmDQo+IGVuc2UuY29tJTJGdjMlMkZfX2h0dHBzJTNBJTJGJTJG ZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jDQo+IG9tJTJGJTNGdXJsJTNEaHR0 cHMqM0EqMkYqMkZnaXRodWJfXyUzQkpTVWwhIUdGXzI5ZGJjUUlVQlBBIW13aQ0KPiBiM3VuNi12 WUJHNjh6TWZ1clc2LTBNdXVFUjV0Tm1KdE9pdERwVmlJQ05rWDBsaGlnOGlQSG1ab2t1TS1CTFEN Cj4gWXBlS1lBR1ElMjQmYW1wO2RhdGE9MDIlN0MwMSU3Q3BlbmcuZmFuJTQwbnhwLmNvbSU3Qzk1 MGQ5YzBhDQo+IGRjNTE0OTI3Y2U4YjA4ZDgxODBlYTRlZiU3QzY4NmVhMWQzYmMyYjRjNmZhOTJj ZDk5YzVjMzAxNjM1JTdDDQo+IDAlN0MwJTdDNjM3Mjg1Nzk4NDYwNTYzOTE0JmFtcDtzZGF0YT1m TXJJJTJGUW90a25Dc1hWMGFtQzRCRmwNCj4gMUhnNHZQdzN6T01WZEFWaW0yV2NzJTNEJmFtcDty ZXNlcnZlZD0wIC4NCj4gPj4NCj4gY29tJTJGeGVuLXRyb29wcyUyRnUtYm9vdCUyRnB1bGwlMkYy JmFtcDtkYXRhPTAyJTdDMDElN0NwZW5nLmZhDQo+ID4+DQo+IG4lNDBueHAuY29tJTdDNDA3ZDhh ZjI0YTM2NDgzZmJkY2UwOGQ4MTgwNWVkODglN0M2ODZlYTFkM2JjMmI0DQo+ID4+DQo+IGM2ZmE5 MmNkOTljNWMzMDE2MzUlN0MwJTdDMCU3QzYzNzI4NTc2MTAyMTk3NTE2NCZhbXA7c2RhdGE9JTIN Cj4gPj4NCj4gRm1YaGVFdktzc0xqamFGS3NIQkJicWglMkI3MmpIM3VRbkU3Y3BOMEozazhJJTNE JmFtcDtyZXNlcnZlZD0wDQo= From xen-devel-bounces@lists.xenproject.org Wed Jun 24 07:28:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 07:28:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnzpU-00031b-M2; Wed, 24 Jun 2020 07:28:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnzpT-00031W-9W for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 07:28:19 +0000 X-Inumbo-ID: 46205812-b5ec-11ea-bca7-bc764e2007e4 Received: from mail-ed1-x536.google.com (unknown [2a00:1450:4864:20::536]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 46205812-b5ec-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 07:28:18 +0000 (UTC) Received: by mail-ed1-x536.google.com with SMTP id m21so726200eds.13 for ; Wed, 24 Jun 2020 00:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=mqd/7p04C1qCsd6vy/md3TOoU2jST6kdL6xN2es983g=; b=h6Lb6nlI2bwDQXbM2vFvAb65K8+xei7Hp31MOnPx8/ql/g/03oGoWFyRkiwO1q0Ake Pso3OZRFmtPKfNdNARlE4s9jfAsB0ZtmJKGTSQYFjd6HJMBLmUmo3r7AryTt8sQI8lbA jsFOPVQpNxigE56ne/GPQuszjPhRsX+m2bs1/tZuS9BzDBDlHLGDeU2nWt13tP3GFj7N 8Y2fEoaCWGfVIfoylmdiSX23JMLkLg2+28IZ2clP/9m18PPkCWMQxVvVSIAnK8heWtwn nEkWEB+M1ldMcsTb7ek4Dn9+miZHMsotIKkzkatHAseVdNjIYOPFC46r2NyTNOaCMZdi hx2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=mqd/7p04C1qCsd6vy/md3TOoU2jST6kdL6xN2es983g=; b=mVipr9MLHhMTPhuIu26dRTBPKhUim0fnLCrtqNz/yOEdwWeU8POJFYiRSbwyotrRyc OxyDjWyFbGDCwTZEKgm59mn0x+xVOGGMzseei31TaGBWYKhRbA+2PPBbn78VyvyIuddo u9Gu1CeG6DcOaQvOi/oLSATs8aVkmGzs7kb6TvQnIwmqsATTU3QWk4rfa/nRKWZfIWHw J2LIrVjO1dYPlJniNDpSW43TPjRg64uQDie2R+u35/a/QGipXPKoqBBeyf9q9vdfhCFL ejcy1I7n4jgkgwE+ozYHnClrzCHSZlRZGdUlSeGJ1O1vOTaSIKl0wIDhyUqeKh4DVsGI Lqvw== X-Gm-Message-State: AOAM533sZ1oXmABh1g1apeuuuAiv6HphpPtFOJi5F6bBJdS2nRCwIEMK zB2z5pHRLWHIAsPOL205s4Y= X-Google-Smtp-Source: ABdhPJyFH1+nWEYGspwYRF08ORw1Wy3xiGOaGnCu0N5bj2tyD/hB4XM8TDdUq7v+72yPIQOvfHcb2g== X-Received: by 2002:aa7:c90a:: with SMTP id b10mr25765788edt.198.1592983697711; Wed, 24 Jun 2020 00:28:17 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id sd15sm7520640ejb.66.2020.06.24.00.28.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 00:28:17 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Tamas K Lengyel'" , "'Xen-devel'" References: In-Reply-To: Subject: RE: [TESTDAY] Test report 4.14-rc3 Date: Wed, 24 Jun 2020 08:28:16 +0100 Message-ID: <000401d649f9$07500f60$15f02e20$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIIYyge6r5azssVMxgX6L5yJBrNd6iDK6rg X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of Tamas K Lengyel > Sent: 24 June 2020 05:31 > To: Xen-devel > Subject: [TESTDAY] Test report 4.14-rc3 > > * Hardware: i9-9900x > > * Guest operating systems: Ubuntu 20.04 > > * Functionality tested: domain create/save/restore, altp2m, vm_event, > mem_access, mem_sharing, VM forking > > * Comments: also tested running nested in a VMware workstation VM, all > above work fine in that setup as well albeit with some expected > performance drop. > > Everything looks good from my end. > Thanks! Good to know. Paul From xen-devel-bounces@lists.xenproject.org Wed Jun 24 07:38:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 07:38:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnzzd-00040N-Q4; Wed, 24 Jun 2020 07:38:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jnzzc-00040I-J0 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 07:38:48 +0000 X-Inumbo-ID: bc23091e-b5ed-11ea-bb8b-bc764e2007e4 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown [40.107.7.58]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bc23091e-b5ed-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 07:38:46 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BlMYCRVTpZYZS70lF0PdFrDxP/JszeEJMUpVR5l90gd4k1ZoMewM7LQAJUzsR3FhPbxWZe8LbWbScf4Mvq1GRES6BNVH+a54aE1/o2/wgz9fJblycs46nDSyEWlPCNa1JezKFaDLb2IBFsdIVvrZr/FOBxobExs7wbXE3wtHLQ+igsFCmlXJwNrkN9f8hQ8ju4G4dpgxvZT2PoVd6tlhCoBGyBoT9tOV7cf6rVG6rDH1BlL3IdBKlHe3FFZ3JxXecvOs9DA8OjAGVkU8Yd3GU04IGLzm4/kXlhocf3cuJK/dUpBEhFD6MO7DG0fZAXFSTkmqCxM9ODlKvtDDdUwsKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oz1Q2ocq/uRC88smFmfIpZof01SF/ZKN9cts21k2DmA=; b=hYoZO1q+MZcA8AkKb+H5Zgd0NNe+3Q03EGfEXe3RSn/1FOFpamNr0X8hDKoIdwfEEQGSIS4k4j/pVXzrLA6cjPo6JR+M8Lfo7F2saj9YM2M+7H3T6zdztvZ/XwcUOxj4H3N1EbjEsxW+RVbzBB7aVadgQbarnYPWVYa+DPtNlYJA0E6PHsQDl4/QRZuaGiDIQZNBLoZ/nBDOpxGab0+ixJLJkYJrLA4HG978ck/kDinNoHXdctGb++JB5Tq9l5bBH+BjSTf4UVO1fh5KnhzQl4romTjRm9s/6km2aq1/Witb6yYRdsrCv9cRfAnNm/iojoXcbSMA4g41CmpZKO1PdQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Oz1Q2ocq/uRC88smFmfIpZof01SF/ZKN9cts21k2DmA=; b=4YRfrRFEm6Nb1bGnroMb2R8vUyVHDeklHBCdjnWe/u8xe5nO0+Wa8OIpvhcG9Z9aOJcJJsaOHoLKXmt3kWdKwtEjuMYKbN0VSjtQjTKmbo00fFTtypC86qonXlt64XWWB32lpFSSZoCo47c41MCNsOgJMm2bDrmcnkoWVSrCIfPVBxZPus36Gc1aTA7s2R2HDjduLD9QGGx/BuPeAriB6uuBYXv813zuNAoWRgOZzbxt7obHqXQEcXRdvjdODrLeGfT6JQU4E5OXSPjjGtFVPT+cxgPzX43bTX6h7PqVEa/TIJ5hn+1zdZ09fbb8xjazQkNsrezac28WyrikXouTnA== Received: from AM6PR03MB3991.eurprd03.prod.outlook.com (2603:10a6:20b:25::20) by AM6PR03MB4277.eurprd03.prod.outlook.com (2603:10a6:20b:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 24 Jun 2020 07:38:44 +0000 Received: from AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c]) by AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c%4]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 07:38:44 +0000 From: Oleksandr Andrushchenko To: Peng Fan , Stefano Stabellini , Julien Grall Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAWPDgIAEUtgAgAAGgYCAAAHAgIAANpaAgAB+IgCAAEYyAIABnlyAgAAOqgCAAALEAIAAAnuAgAADfIA= Date: Wed, 24 Jun 2020 07:38:44 +0000 Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> <273d5fe8-dac9-6375-77df-e24f56066cfe@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nxp.com; dkim=none (message not signed) header.d=none;nxp.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19814bb4-bf10-46c1-b1e6-08d818119f90 x-ms-traffictypediagnostic: AM6PR03MB4277: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FCsC+EZH2Dof+Q3ZAMJbMncLQZpJ7Ht0AGs9QDQq8vkuz/z+lYSFXGDFoZjAuZrchwYxxFCNfZ/x9ikUVmVGuMxIaJy6t8Jtc9Z4TIFUnUxDG3BPtG1NPqtqO6baUQdNJrdFDki2f0TD/e/R7f7YHJo1PtvIX4fjVfiaamna1uBmYCY+yjL3AhUc6bUceeMDzwuN+aYpIQarVxuynwgW6/BHD9kIKyNFbp8fZ39X9NCO6QrKJ4hppl2bKVWZtxNmmtzWyOwxzjWiBRmR6dobWHbOGelxRlMPv08eHA3MJZF+1y8JldrdILADohgdonf861k9Vu1mj5nL51tqFzwqaA4CodjZRjq45BIzGWyvv6zZxxqiJDf3dTpIXCHJ338AKeVd5cd97N0LptHmK7uJ3g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR03MB3991.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(376002)(346002)(366004)(136003)(7416002)(86362001)(2616005)(5660300002)(66476007)(66946007)(64756008)(66556008)(66446008)(31696002)(316002)(76116006)(6486002)(26005)(4326008)(31686004)(966005)(6512007)(45080400002)(478600001)(8936002)(186003)(36756003)(8676002)(6506007)(2906002)(110136005)(53546011)(71200400001)(83380400001)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ibmXI6EXbFyVh2PvqpQtKR1yWixzNmFwy5ChtCDOlpmef/X9rmQOAfpKZuIeaTSgzRuUxc500vqQthFYviQY1iruRcu7AdmsPmK4R8JTEbQ5Qf3xwjBBGMctWSEd/nuNr4G7rkTdp9BZeyBc2eWrsTBZ9mcvlyXMrEvuBhi4JeZn8mrNG/Dlnhms4zFlJ/hY0voxxI5SKYwW0NY1DBJpwKh5FZUzVVZftNWQCNnwvuMnLslRe1kYS9h5JSN/vQ0iZmuP7XMR83AEbvtxYJ+bpnhOKUylFjDHsJfv28/m/kEuJvHRU1WJX92V7tjtNYQUeDtEq01IDz4WQ+nHSXUY58iojfjClcuYZBtvNwbo6r1yVhQVYbNuIZeewIDpog1GSd/FJopfBDDm9YcDU5MzYNnInEdKFsevM3b+E9nqB7v+bSLQjFM4R6RcMqfvB1C8mxaMhmxJ8KTyeV7UwYVyt44Z4emGbhaYkMh61b0sd0g= Content-Type: text/plain; charset="utf-8" Content-ID: <6F194DBD00575249A82937BF70C94C59@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19814bb4-bf10-46c1-b1e6-08d818119f90 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 07:38:44.2546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: k/94m01EQap+0Hl4myEDzllBteJxt9HOVS403j4uWPIdV4QWoSg+Bz8Fx8cgZwlriJIP4bKeNnIgafx7/KJNh16FnCYJ6K7LgYGoDmi6ZfXebklkhj4Mk4pwhlmlJ3zA X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB4277 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQpPbiA2LzI0LzIwIDEwOjI2IEFNLCBQZW5nIEZhbiB3cm90ZToNCj4+IFN1YmplY3Q6IFJlOiBV RUZJIHN1cHBvcnQgaW4gQVJNIERvbVVzDQo+Pg0KPj4NCj4+IE9uIDYvMjQvMjAgMTA6MDcgQU0s IFBlbmcgRmFuIHdyb3RlOg0KPj4+PiBTdWJqZWN0OiBSZTogVUVGSSBzdXBwb3J0IGluIEFSTSBE b21Vcw0KPj4+Pg0KPj4+Pg0KPj4+PiBPbiA2LzIzLzIwIDg6MzEgQU0sIE9sZWtzYW5kciBBbmRy dXNoY2hlbmtvIHdyb3RlOg0KPj4+Pj4gT24gNi8yMy8yMCA0OjIwIEFNLCBTdGVmYW5vIFN0YWJl bGxpbmkgd3JvdGU6DQo+Pj4+Pj4gT24gTW9uLCAyMiBKdW4gMjAyMCwgSnVsaWVuIEdyYWxsIHdy b3RlOg0KPj4+Pj4+Pj4+PiBGb3IgdGhlIGZpcnN0IHBhcnQgKF9fWEVOX0lOVEVSRkFDRV9WRVJT SU9OX18pIEkgdGhpbmsgd2UgY2FuDQo+Pj4+Pj4+Pj4+IHByb3ZpZGUgaXQgdmlhDQo+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+IENGTEFHUyBvciBzb21ldGhpbmcuIFRoaXMgY2FuIGFsc28gYmUgZG9u ZSBmb3IgdGhlIGxvY2F0aW9uIG9mDQo+Pj4+Pj4+Pj4+IFhlbiBoZWFkZXJzLg0KPj4+Pj4+Pj4+ IF9fWEVOX0lOVEVSRkFDRV9WRVJTSU9OX18gc2hvdWxkIHdvcmsgdGhyb3VnaCB0aGUgQ0ZMQUdT Lg0KPj4gQW4NCj4+Pj4+Pj4+PiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBhbGxvdyB0aGUgdXNl ciB0byBzcGVjaWZ5IHRocm91Z2ggdGhlDQo+PiBLY29uZmlnLg0KPj4+Pj4+Pj4gWW91IG1lYW4g c3BlY2lmeWluZyB2aWEgS2NvbmZpZyBzb21ldGhpbmcgbGlrZSAiMHgwMDA0MGQwMCI/DQo+Pj4+ Pj4+IFBvc3NpYmx5IHllcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IEFuZCB3aGF0IGFib3V0IHRoZSBo ZWFkZXJzPyBIb3cgd2lsbCB3ZSBwcm92aWRlIHRoZWlyIGxvY2F0aW9uIGlmDQo+Pj4+Pj4+PiB3 ZSBkZWNpZGUgbm90IHRvIGluY2x1ZGUgdGhvc2UNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBpbiB0aGUg dHJlZT8NCj4+Pj4+Pj4gSSB3b3VsZCBkbyB0aHJvdWdoIEtjb25maWcgYXMgd2VsbC4NCj4+Pj4+ PiBJZiB3ZSBzcGVjaWZ5IHRoZSBleHRlcm5hbCBsb2NhdGlvbiBvZiB0aGUgWGVuIGhlYWRlcnMg dmlhIEtjb25maWcsDQo+Pj4+Pj4gaXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBzaG91bGQgYmUgYWJs ZSB0byBkZXRlY3QgdGhlIGludGVyZmFjZQ0KPj4+Pj4+IHZlcnNpb24gYXV0b21hdGljYWxseSBm cm9tIGFueSBNYWtlZmlsZSBhcyBwYXJ0IG9mIHRoZSBidWlsZC4gTm8NCj4+Pj4+PiBuZWVkIHRv IGFzayB0aGUgdXNlci4NCj4+Pj4+Pg0KPj4+Pj4+IEhvd2V2ZXIsIGlmIE9sZWtzYW5kciBpcyB0 aGlua2luZyBvZiB1c2luZyB0aGUgWGVuIGhlYWRlcnMgZm9yIHRoZQ0KPj4+Pj4+IGh5cGVyY2Fs bHMgZGVmaW5pdGlvbnMsIHRoZW4gSSB0aGluayB3ZSBtaWdodCBub3QgbmVlZCBleHRlcm5hbA0K Pj4+Pj4+IGhlYWRlcnMgYXQgYWxsIGJlY2F1c2UgdGhhdCBpcyBhIHN0YWJsZSBpbnRlcmZhY2Us IGFzIEp1bGllbiB3cm90ZS4NCj4+Pj4+PiBXZSBjb3VsZCBqdXN0IGRlZmluZSBvdXIgb3duIGZl dyBoZWFkZXJzIGZvciBqdXN0IHdoYXQgeW91IG5lZWQNCj4+Pj4+PiBsaWtlIExpbnV4DQo+Pj4+ IGRvZXMuDQo+Pj4+PiBUaGlzIGlzIGEgZ29vZCBpZGVhOiBJJ2xsIHRyeSB0byBnZXQgdGhlIG1p bmltYWwgc2V0IG9mIGhlYWRlcnMgZnJvbQ0KPj4+Pj4gTGludXgNCj4+Pj4+DQo+Pj4+PiBpbnN0 ZWFkIG9mIFhlbiBhcyB0aG9zZSBzZWVtIHRvIGJlIHdlbGwgcHJlcGFyZWQgZm9yIHN1Y2ggYSB1 c2UtY2FzZS4NCj4+Pj4+IFRoaXMNCj4+Pj4+DQo+Pj4+PiB3YXkgd2UnbGwgaGF2ZSBoZWFkZXJz IGluIFUtYm9vdCB0cmVlIGFuZCBndWFyYW50ZWUgdGhhdCB3ZSBoYXZlIGENCj4+Pj4+IG1pbmlt YWwNCj4+Pj4+DQo+Pj4+PiBzdWJzZXQgd2hpY2ggaXMgZWFzaWVyIHRvIG1haW50YWluLiBJJ2xs IGtlZXAgeW91IHVwZGF0ZWQgb24gdGhlDQo+Pj4+PiBwcm9ncmVzcw0KPj4+PiBXZSd2ZSBtYW5h Z2VkIHRvIHN0cmlwIHRoZSBoZWFkZXJzIGFuZCByZW1vdmUgX19YRU5fXyBhbmQgdGhlIHJlc3QN Cj4+Pj4gZGVmaW5pdGlvbnMNCj4+Pj4NCj4+Pj4gd2Ugd2VyZSB0YWxraW5nIGFib3V0LiBTbywg dGhlc2UgYXJlIG5vdyB0aGUgbWluaW1hbCByZXF1aXJlZCBzZXQgb2YNCj4+Pj4gaGVhZGVycw0K Pj4+Pg0KPj4+PiB0aGF0IGFsbG93cyBVLWJvb3QgdG8gYnVpbGQgc2VyaWFsIGFuZCBibG9jayBk cml2ZXJzLiBQbGVhc2UgdGFrZSBhDQo+Pj4+IGxvb2sgYXQgWzFdDQo+Pj4+DQo+Pj4+IFB1bGwg cmVxdWVzdCBmb3IgY29tbWVudHMgaXMgYXQgWzJdDQo+Pj4gVGhlIFUtQm9vdCBuZXcgbWVyZ2Ug d2luZG93IHdpbGwgYmUgb3BlbiBpbiAyMDIwLzcvMSwgc28gSSdkIHN1Z2dlc3QNCj4+PiB0aGUg cGF0Y2hzZXQgZ29lcyB0byBVLUJvb3QgbWFpbCBsaXN0IGZvciBkaXNjdXNzaW9uIGlmIHlvdSB3 YW5uYSB0aGUNCj4+PiBwYXRjaGVzIGdvbm5hIG1lcmdlZCBzb29uLg0KPj4gV2UgZGVmaW5pdGVs eSB3YW50IHRoZSBwYXRjaGVzIHRvIGJlIHVwc3RyZWFtZWQgYW5kIG1lcmdlZCwgYnV0IGJlZm9y ZQ0KPj4gdGhhdA0KPj4NCj4+IHdlIGFsc28gd2FudCB0byBtYWtlIHN1cmUgdGhhdCBYZW4gY29t bXVuaXR5IGlzIGhhcHB5IHdpdGggd2hhdCB3ZQ0KPj4gdXBzdHJlYW0NCj4+DQo+PiBJIGJlbGll dmUgd2UgcmVzb2x2ZWQgbW9zdCBvZiB0aGUgY29uY2VybnMgc3VjaCBhcyBoZWFkZXJzLCBQSUUg ZXRjLCBzbyB0aGlzDQo+PiBjYW4NCj4+DQo+PiBiZSBkb25lLg0KPj4NCj4+IEJUVywgUGVuZywg ZGlkIHlvdSBoYXZlIGEgY2hhbmNlIHRvIHRyeSB0aGUgcHZibG9jayBkcml2ZXIgeWV0Pw0KPiBO b3QgeWV0LiBJIGNvdWxkIGhhdmUgdGltZSB0byBnaXZlIGEgdGVzdCBuZXh0IE1vbmRheS4gSSB0 aGluayB5b3Ugbm90DQo+IGVuYWJsZSBTUEwsIHJpZ2h0Pw0KDQpObywgd2UgZGVjaWRlZCB0aGF0 IHdlIGNhbiBydW4gd2l0aCBVLWJvb3QgcHJvcGVyLCBzbyB3ZSBjYW4gaGF2ZSBtb3JlDQoNCmZs ZXhpYmlsaXR5IGNvbXBhcmluZyB0byB3aGF0IHdlIGhhdmUgaW4gU1BMLiBJdCBzZWVtcyB0aGF0 IHdhcyB0aGUgcmlnaHQNCg0KYXBwcm9hY2g6IHlvdSBjYW4ganVtcCB0byBMaW51eCBvciB5b3Ug Y2FuIGp1bXAgdG8gdGhlIFUtYm9vdCBwcm92aWRlZA0KDQpieSBBbmRyb2lkIGFueXdheSwgd2hh dGV2ZXIgeW91ciBzZXR1cA0KDQo+ICAgU28gYW5kcm9pZCBkdWFsIGJvb3Rsb2FkZXIgZmVhdHVy ZSBub3QgZW5hYmxlZC4NCg0KSSB0aGluayB0aGlzIHN0ZXAgd2lsbCBkZXBlbmQgb24gdGhlIHVz ZS1jYXNlIHlvdSBoYXZlOiBhdCB0aGUgbW9tZW50IHdlIGhhdmUNCg0KYSBiYXNlIGJ1aWxkIGNh cGFibGUgb2YgYm9vdGluZyBMaW51eCBrZXJuZWwsIGJ1dCB0aGlzIGNhbiBlYXNpbHkgYmUgZXh0 ZW5kZWQgd2l0aA0KDQpzcGVjaWZpYyBkZWZjb25maWcgdG8gYnVpbGQgaW4gYm9vdGEgY29tbWFu ZCBvciB3aGF0ZXZlciBlbHNlIGlzIHJlcXVpcmVkLg0KDQo+IEJ1dCBTUEwgbW9zdGx5IG5vdCBo YXZlIE1NVSBlbmFibGVkLi4NCj4NCj4gUmVnYXJkcywNCj4gUGVuZy4NCj4NCj4+PiBSZWdhcmRz LA0KPj4+IFBlbmcuDQo+Pj4NCj4+Pj4+PiBJZiB5b3UgY2FuIGRvIHRoYXQsIEkgdGhpbmsgaXQg d291bGQgYmUgYmV0dGVyIGJlY2F1c2Ugd2UgZGVjb3VwbGUNCj4+Pj4+PiB0aGUgVUJvb3QgYnVp bGQgZnJvbSB0aGUgWGVuIGJ1aWxkIGNvbXBsZXRlbHkuIFdlIGRvbid0IGV2ZW4gbmVlZA0KPj4+ Pj4+IHRoZSBYZW4gdHJlZSBjaGVja2VkIG91dCB0byBidWlsZCBVQm9vdC4gSXQgd291bGQgYmUg YSBodWdlDQo+Pj4+Pj4gYWR2YW50YWdlIGJlY2F1c2UgaXQgbWFrZXMgaXQgZmFyIGVhc2llciB0 byBidWlsZC10ZXN0IGNoYW5nZXMgZm9yDQo+Pj4+Pj4gb3RoZXJzIGluIHRoZSBjb21tdW5pdHkg dGhhdCBkb24ndCBrbm93IGFib3V0IFhlbiBhbmQgYWxzbyBpdA0KPj4+Pj4+IGJlY29tZXMgZmFy IGVhc2llciB0byBpbnRlZ3JhdGUgaW50byBhbnkgYnVpbGQgc3lzdGVtLg0KPj4+PiBbMV0NCj4+ Pj4NCj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2V1cjAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMqM0EqMkYqMkZ1cmxkZWZfXztKU1Vs ISFHRl8yOWRiY1FJVUJQQSFrSmhXRnI1Wk9fVVduMm9EX0k5cERmbm42NHBaWHcxWkJ0QVNzeFM5 QVp3Ykc2NTA5M1p5ZHRsVlB5NmJhUHk0b2VGOTU3R0JOQSQNCj4+IGVuc2UuY29tJTJGdjMlMkZf X2h0dHBzJTNBJTJGJTJGZXVyMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jDQo+PiBv bSUyRiUzRnVybCUzRGh0dHBzKjNBKjJGKjJGZ2l0aHViX18lM0JKU1VsISFHRl8yOWRiY1FJVUJQ QSFtd2kNCj4+IGIzdW42LXZZQkc2OHpNZnVyVzYtME11dUVSNXRObUp0T2l0RHBWaUlDTmtYMGxo aWc4aVBIbVpva3VNLUJMUQ0KPj4gWXBlS1lBR1ElMjQmYW1wO2RhdGE9MDIlN0MwMSU3Q3Blbmcu ZmFuJTQwbnhwLmNvbSU3Qzk1MGQ5YzBhDQo+PiBkYzUxNDkyN2NlOGIwOGQ4MTgwZWE0ZWYlN0M2 ODZlYTFkM2JjMmI0YzZmYTkyY2Q5OWM1YzMwMTYzNSU3Qw0KPj4gMCU3QzAlN0M2MzcyODU3OTg0 NjA1NjM5MTQmYW1wO3NkYXRhPWZNckklMkZRb3RrbkNzWFYwYW1DNEJGbA0KPj4gMUhnNHZQdzN6 T01WZEFWaW0yV2NzJTNEJmFtcDtyZXNlcnZlZD0wIC4NCj4+IGNvbSUyRmFuZHIyMDAwJTJGdS1i b290JTJGdHJlZSUyRnB2YmxvY2tfdXBzdHJlYW1fdjEmYW1wO2RhdGE9MA0KPj4gMiU3QzAxJTdD cGVuZy5mYW4lNDBueHAuY29tJTdDNDA3ZDhhZjI0YTM2NDgzZmJkY2UwOGQ4MTgwNWVkODgNCj4+ Pj4gJTdDNjg2ZWExZDNiYzJiNGM2ZmE5MmNkOTljNWMzMDE2MzUlN0MwJTdDMCU3QzYzNzI4NTc2 MTAyMQ0KPj4gOTc1DQo+PiAxNjQmYW1wO3NkYXRhPTV2V2ZCYkxTY0lDWFBaV1UlMkJVM2I3RHlP TmNneFQ4aUlDc3hyd1ViT1JaWSUNCj4+Pj4gM0QmYW1wO3Jlc2VydmVkPTANCj4+Pj4NCj4+Pj4g WzJdDQo+Pj4+DQo+PiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9ldXIwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzKjNBKjJGKjJGdXJsZGVm X187SlNVbCEhR0ZfMjlkYmNRSVVCUEEha0poV0ZyNVpPX1VXbjJvRF9JOXBEZm5uNjRwWlh3MVpC dEFTc3hTOUFad2JHNjUwOTNaeWR0bFZQeTZiYVB5NG9lRjk1N0dCTkEkDQo+PiBlbnNlLmNvbSUy RnYzJTJGX19odHRwcyUzQSUyRiUyRmV1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Yw0KPj4gb20lMkYlM0Z1cmwlM0RodHRwcyozQSoyRioyRmdpdGh1Yl9fJTNCSlNVbCEhR0ZfMjlk YmNRSVVCUEEhbXdpDQo+PiBiM3VuNi12WUJHNjh6TWZ1clc2LTBNdXVFUjV0Tm1KdE9pdERwVmlJ Q05rWDBsaGlnOGlQSG1ab2t1TS1CTFENCj4+IFlwZUtZQUdRJTI0JmFtcDtkYXRhPTAyJTdDMDEl N0NwZW5nLmZhbiU0MG54cC5jb20lN0M5NTBkOWMwYQ0KPj4gZGM1MTQ5MjdjZThiMDhkODE4MGVh NGVmJTdDNjg2ZWExZDNiYzJiNGM2ZmE5MmNkOTljNWMzMDE2MzUlN0MNCj4+IDAlN0MwJTdDNjM3 Mjg1Nzk4NDYwNTYzOTE0JmFtcDtzZGF0YT1mTXJJJTJGUW90a25Dc1hWMGFtQzRCRmwNCj4+IDFI ZzR2UHczek9NVmRBVmltMldjcyUzRCZhbXA7cmVzZXJ2ZWQ9MCAuDQo+PiBjb20lMkZ4ZW4tdHJv b3BzJTJGdS1ib290JTJGcHVsbCUyRjImYW1wO2RhdGE9MDIlN0MwMSU3Q3BlbmcuZmENCj4+IG4l NDBueHAuY29tJTdDNDA3ZDhhZjI0YTM2NDgzZmJkY2UwOGQ4MTgwNWVkODglN0M2ODZlYTFkM2Jj MmI0DQo+PiBjNmZhOTJjZDk5YzVjMzAxNjM1JTdDMCU3QzAlN0M2MzcyODU3NjEwMjE5NzUxNjQm YW1wO3NkYXRhPSUyDQo+PiBGbVhoZUV2S3NzTGpqYUZLc0hCQmJxaCUyQjcyakgzdVFuRTdjcE4w SjNrOEklM0QmYW1wO3Jlc2VydmVkPTA= From xen-devel-bounces@lists.xenproject.org Wed Jun 24 07:51:03 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 07:51:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo0BI-0005cJ-UI; Wed, 24 Jun 2020 07:50:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo0BH-0005cE-SW for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 07:50:52 +0000 X-Inumbo-ID: 6bfb708c-b5ef-11ea-8496-bc764e2007e4 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (unknown [40.107.6.89]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6bfb708c-b5ef-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 07:50:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QAGZhfwWxrbZVNblOko23k/JqL0LSOXxaHHpeax+ZM4=; b=kpwSs6VDo19CwtteemfI9+r68tGoI4wseJpflo73ngX/p6OAcnkiKmNbkP0N4L04UzHknf4KvhD+ovzPGXI8o191JG7RVPUdclI52B5VNlvXAIQi55cz6PJ0jizpLoMf+UmmWH4ZcZ8AOv2Ik51WgdtXhlKMIn+8teVmYRyDC50= Received: from AM6PR10CA0094.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:8c::35) by DB6PR0801MB1943.eurprd08.prod.outlook.com (2603:10a6:4:74::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 24 Jun 2020 07:50:48 +0000 Received: from VE1EUR03FT035.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8c:cafe::69) by AM6PR10CA0094.outlook.office365.com (2603:10a6:209:8c::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend Transport; Wed, 24 Jun 2020 07:50:48 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT035.mail.protection.outlook.com (10.152.18.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Wed, 24 Jun 2020 07:50:47 +0000 Received: ("Tessian outbound 217a52b9caed:v59"); Wed, 24 Jun 2020 07:50:47 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 399724d274a5de18 X-CR-MTA-TID: 64aa7808 Received: from 3ace6fa6619b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8D2ED595-65AD-455C-8476-478651044171.1; Wed, 24 Jun 2020 07:50:41 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 3ace6fa6619b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 24 Jun 2020 07:50:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=adsJCG6A7MNkAE4cxbtKOeuBO0x5tVNDVCnJN6/iHdklsSajqwuPd3bDbCve3Tapg6fOCn/iLYZtYJ8drXVfAASxm0mPO1BtBR1oknBeHnzjb426LH9ufOsi0/tcenlGrnUSCgn93OVJ97N7zdlvGZdMJPYgzznrD8z/NbgC5PEyIHJ8JrnYssvD3XWQNW3hT8pehHb9587g/wgwDSVUJqrxcHI3+Xi4xq7Q/ccQ3d4/mGqhewb5Kg6Y4hLUXNrvB5Qg4jPg8mOczX2RGiQ7doCr2OL8BlFxyugQ0lwtyI20tclqbYFg894CvuS8QcjGlo8yUVKSzGrvQsNDJehtIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QAGZhfwWxrbZVNblOko23k/JqL0LSOXxaHHpeax+ZM4=; b=hp4Qx43sxyG6bRr+zCmFpkrUcxQ0HRMvn/CHZWj5eFSsz49BFiK457JTHLweekA2FikivMMVeBP9nNYCmNjmEDbiRVW1JcwNdxqApzhwc98qImNliCj/LG2ktgfxuNFKctsFssNV/wWPap6InGHOXt96WZzmzGjtD7LPWYsD8ZI/Qi82aV3R7g+nfEGHWDfrmLZdNPoaE52kix99bJMmr1UN6Jnd5bjzqmoiJpCjE8dzWugxFkTld2lplWhHA7MoZ/Auyq9HAVfChT0/gl4sDqy+OEOwiq6NFYLTN6RCjqwoRka2fs0+MviMR0Kc+XlsH5hPPDhmXpg0YIj6/4Yl4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QAGZhfwWxrbZVNblOko23k/JqL0LSOXxaHHpeax+ZM4=; b=kpwSs6VDo19CwtteemfI9+r68tGoI4wseJpflo73ngX/p6OAcnkiKmNbkP0N4L04UzHknf4KvhD+ovzPGXI8o191JG7RVPUdclI52B5VNlvXAIQi55cz6PJ0jizpLoMf+UmmWH4ZcZ8AOv2Ik51WgdtXhlKMIn+8teVmYRyDC50= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3913.eurprd08.prod.outlook.com (2603:10a6:10:7c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.21; Wed, 24 Jun 2020 07:50:39 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 07:50:38 +0000 From: Bertrand Marquis To: CodeWiz2280 Subject: Re: Keystone Issue Thread-Topic: Keystone Issue Thread-Index: AQHWOBaIAfEL/lLkK0WiNSn4kZcZc6jDwRQAgAAfVYCAACZwgIACvmKAgABfPYCAAA+JgIAA6NEAgAAP9wCAAAJxgIAAEuGAgAAfEwCAAGmFAIAAh2UAgABV34CAAFCtAIAAAUSAgAADZQCAAAGKgIAAJpOAgABE7QCABAZcAIAAQRIAgAA9oACAAXYtAIAAD3sAgAAFaoCAABUzgIAAB/uAgAAD1ICAAdWTgIAHsRIAgADZKACAAKhTgIAAArOAgAFVYICAAENqAIAAVYQAgAk7HYCAALhoAA== Date: Wed, 24 Jun 2020 07:50:38 +0000 Message-ID: <30ACA5A7-089F-45E2-9A9B-A6BC4EBBC78B@arm.com> References: <99E77330-049F-4471-ABF9-13F9AB4E95B5@arm.com> <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a3dd94ab-b70f-4887-ac4c-08d818134e8c x-ms-traffictypediagnostic: DB7PR08MB3913:|DB6PR0801MB1943: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0444EB1997 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: uHX+B4gNNcr9nvm3jTSFWUBPjYz2mTUeoMHTxpwuAH6FlQ8ZQZlTeRSU8xjEISJqxr65gTsX9Kt33+fneJTJNg8UpspSiTe+c0oyj8WmE5O/OwDwtyWN5n1Ve0S5sWlGZ5X57r7VH+Ue9oBokgY63TzZZn9bE9BBiIan1bc1kLkAOzfPvyzfBC2i+sacFjh96rTeQoUF0Kef2z3Knsz4sdgTZf1cuW4440W46KFD5LhQo+/+0d586kNh5BTPLOEdcr7aejIzFb5IXZAUJq+kgdPbijCGMd9wpzDURIl+Bp4lDBzLP6uM9MmrH8lEpwi0Mvj9DrUdnastzF3l1L52shsec3I1o/qOetZhWEy71DjEudRXzW6WiQhWd58ivl7/fZRvGxi1RgS2X+j08J+1cQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39850400004)(366004)(396003)(136003)(376002)(66446008)(66476007)(64756008)(66556008)(186003)(7116003)(33656002)(6486002)(36756003)(2906002)(71200400001)(54906003)(2616005)(91956017)(76116006)(3480700007)(66946007)(316002)(6512007)(86362001)(8676002)(5660300002)(83380400001)(966005)(26005)(6506007)(53546011)(6916009)(478600001)(8936002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: QI8AUmen+XPTPw3fGHacv7nzn2E1H/ng2czuRneTr9QQ30hxVkZiQ7Uroul8aGqd28eMnCI7Hl/OgHXpwzIRuOpMxoxcZQBagYTOs+DZ4h/XLAz3jG4sgN4+0yKU1pFFdllEhLt1fhEoXgf4vgjvsjKlAe+0iN5K+oAj2k6kocH1JUQ/Evut2z4NslJOHC5mwz0j+26Fxc5U4Qrgop0ISZPVz4iL2RFNU9oYcH5AutRfDJ8qvgl3w5C4MEyi0HpgijGBdOROFtT0wsup6HJTeyYXqGfRb8HroYgezU/TsB0FtggBKUqgaoICLBv2pm1fdfQqxr05p06nLc2L2IxjQOKvLKqs+Wvy93mnYBYOVZAWKkTKOczdMXc2lcsy9UAV8mPistQ+bQgljWNyHIF68xM0ljfQzDBw57tjD+RRADVQ7oofZxY/frh7lTIVHX9WAhP1xIslexjbpsbg8WIAWW/RP+N25HPmkR6pHkNJpWQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <7B01395B3708C94CA289C3AC8B445C30@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3913 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT035.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(396003)(39850400004)(376002)(46966005)(82740400003)(54906003)(2906002)(966005)(336012)(6862004)(5660300002)(6512007)(70206006)(70586007)(33656002)(83380400001)(3480700007)(4326008)(8676002)(6486002)(36756003)(86362001)(186003)(26005)(6506007)(47076004)(478600001)(53546011)(7116003)(316002)(82310400002)(2616005)(81166007)(8936002)(356005)(36906005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: cef31353-286d-4a50-b06e-08d818134981 X-Forefront-PRVS: 0444EB1997 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cLQEQ8BdQsD2iwHpKi9uz2oEFtNbFiFtFuRXtJZEpqAakfAzK7JDddgkOqESN0mA5tTK8fmWK2Yq5sRi3BXgyvVng4onStZH5H0FeGVAnKSk9uYx1+k54Nns+eSvqK5i+59liephZo3bnBMdtggMqqskUhIn77zPTOWQPVl5H1v4jzCB0Djmpu7t2w3Cbanzbt3vjZDrIu1knpEDb6Y/G3PsNnVk0TFlw7MLEYKvmITqj8G67lZjpuCtwGmJs6/uv6ZL4EkHBhTMCnjXg54XE5D4Qn2ZPCftaYaffn6GuxoXao+REMJ6JlmsKzlAy360Uld5flGTUeQRYmZG4lcuUq8T5HcbNpRqJecAWeKUxvGYm/R/DujA+iBtWBRaknmo/tYd12SwYA3l+iCPBM7CG1GlPj479sokTCUVm7im3qBNQGA5A5d4m0Czh1qFekReby/i0I0qdQRQ143tIzHplii3YwVfhTdt6S+XL+4Iwsk= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2020 07:50:47.3102 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a3dd94ab-b70f-4887-ac4c-08d818134e8c X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1943 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , nd , Stefano Stabellini , xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On 23 Jun 2020, at 21:50, CodeWiz2280 wrote: >=20 > Is it possible to passthrough PCI devices to domU on the 32-bit arm > keystone? Any info is appreciated. >=20 > I found some old information online that "gic-v2m" is required. I'm > not sure if the GIC-400 on the K2E supports "gic_v2m". Based on the > fact that there is no "gic-v2m-frame" tag in the K2E device tree i'm > guessing that it does not. >=20 > If it is possible, is there a good example for arm that I can follow? There is no PCI passthrough support on Arm for now in Xen. This is something I am working on and I will present something on this subj= ect at the Xen summit. But we are not targeting arm32 for now. The only thing possible for now is to have PCI devices handled by Dom0 and = using xen virtual drivers to pass the functionalities (ethernet, block or o= thers). Regards Bertrand >=20 > On Wed, Jun 17, 2020 at 7:52 PM CodeWiz2280 wrote= : >>=20 >> On Wed, Jun 17, 2020 at 2:46 PM Stefano Stabellini >> wrote: >>>=20 >>> On Wed, 17 Jun 2020, CodeWiz2280 wrote: >>>> On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote: >>>>>=20 >>>>> On 2020-06-16 19:13, CodeWiz2280 wrote: >>>>>> On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: >>>>>>>=20 >>>>>>> On 2020-06-15 20:14, CodeWiz2280 wrote: >>>>>>>=20 >>>>>>> [...] >>>>>>>=20 >>>>>>>> Also, the latest linux kernel still has the X-Gene storm distribut= or >>>>>>>> address as "0x78010000" in the device tree, which is what the Xen = code >>>>>>>> considers a match with the old firmware. What were the addresses = for >>>>>>>> the device tree supposed to be changed to? >>>>>>>=20 >>>>>>> We usually don't care, as the GIC address is provided by the >>>>>>> bootloader, >>>>>>> whether via DT or ACPI (this is certainly what happens on Mustang). >>>>>>> Whatever is still in the kernel tree is just as dead as the platfor= m >>>>>>> it >>>>>>> describes. >>>>>>>=20 >>>>>>>> Is my understanding >>>>>>>> correct that there is a different base address required to access = the >>>>>>>> "non-secure" region instead of the "secure" 0x78010000 region? I'= m >>>>>>>> trying to see if there are corresponding different addresses for t= he >>>>>>>> keystone K2E, but haven't found them yet in the manuals. >>>>>>>=20 >>>>>>> There is no such address. Think of the NS bit as an *address space* >>>>>>> identifier. >>>>>>>=20 >>>>>>> The only reason XGene presents the NS part of the GIC at a differen= t >>>>>>> address is because XGene is broken enough not to have EL3, hence no >>>>>>> secure mode. To wire the GIC (and other standard ARM IPs) to the co= re, >>>>>>> the designers simply used the CPU NS signal as an address bit. >>>>>>>=20 >>>>>>> On your platform, the NS bit does exist. I strongly suppose that it >>>>>>> isn't wired to the GIC. Please talk to your SoC vendor for whether = iot >>>>>>> is possible to work around this. >>>>>>>=20 >>>>>> I do have a question about this out to TI, but at least this method >>>>>> gives me something to work with in the meantime. I was just looking >>>>>> to confirm that there wouldn't be any other undesirable side effects >>>>>> with Dom0 or DomU when using it. Was there an actual FPGA for the >>>>>> X-Gene that needed to be updated which controlled the GIC access? O= r >>>>>> by firmware do you mean the boot loader (e.g. uboot). Thanks for th= e >>>>>> support so far to all. >>>>>=20 >>>>> As I said, the specific case of XGene was just a matter of picking th= e >>>>> right address, as the NS bit is used as an address bit on this platfo= rm. >>>>> This was possible because this machine doesn't have any form of >>>>> security. So no HW was changed, no FPGA reprogrammed. Only a firmware >>>>> table was fixed to point to the right spot. Not even u-boot or EFI wa= s >>>>> changed. >>>> Ok, thank you for clarifying. I have one more question if you don't >>>> mind. I'm aware that dom0 can share physical memory with dom1 via >>>> grant tables. >>>> However, is it possible to reserve a chunk of contiguous physical >>>> memory and directly allocate it only to dom1? >>>> For example, if I wanted dom1 to have access to 8MB of contiguous >>>> memory at 0x8200_0000 (in addition to whatever virtual memory Xen >>>> gives it). >>>> How would one go about doing this on ARM? Is there something in the >>>> guest config or device tree that can be set? Thanks for you help. >>>=20 >>> There isn't a "proper" way to do it, only a workaround. >>>=20 >>> It is possible to do it by using the iomem option, which is meant for >>> device MMIO regions. >>>=20 >>> We have patches in the Xilinx Xen tree (not upstream) to allow for >>> specifying the cacheability that you want for the iomem mapping so that >>> you can map it as normal memory. This is the latest branch: >>>=20 >>> https://github.com/Xilinx/xen.git xilinx/release-2020.1 >>>=20 >>> The relevant commits are the ones from: >>> https://github.com/Xilinx/xen/commit/a5c76ac1c5dc14d3e9ccedc5c1e7dd2ddc= 1397b6 >>> to: >>> https://github.com/Xilinx/xen/commit/b4b7e91c1524f9cf530b81b7ba95df2bf5= 0c78e4 >>>=20 >>> You might want to make sure that the page is not used by the normal >>> memory allocator. This document explains how to something along those >>> lines: >>>=20 >>> https://github.com/Xilinx/xen/commit/35f72d9130448272e07466bd73cc30406f= 33135e >>=20 >> Thank you. I appreciate it. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 08:53:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 08:53:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo19y-0003hF-3E; Wed, 24 Jun 2020 08:53:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo19x-0003hA-5e for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 08:53:33 +0000 X-Inumbo-ID: 2daee40e-b5f8-11ea-bca7-bc764e2007e4 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown [2a01:111:f400:fe0d::616]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2daee40e-b5f8-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 08:53:32 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mhBCJlFL0qCYPofSqUZjCuASsIY8SNhmxd0XoBAGdPXScd8pybfZAZgWBdjNbb6kBnDCIoOnB4fgP/JXNJIraRuVQdEDZbO6BlxQeKwpo/ztlNIXNpB4xnT2gwSYy35be+np8/Ky9UzapjMPHY6/4tI850YiKkdUI45pSYaQqM9YV74z+7aWGZYlHobIlxmZnsQvQfKksNZ05rRiHocRmI5h0WbhBmGarXCyb+UKh0dJpQ5sVJC8gkXoOjJlfpClPFkzUyvQwETLO/qZGCkBsFFcyWstFBkC4nWxiKhdQVRVI9A2SaEDgjlQEiW3qc9NZs5tJD/mq865VWlnXGpmLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3P0H34ZpXj3sa+FcMN/vj5YDCEarbvC4lpBt0odIAMc=; b=aBHplI/p8ECd7vw/0CR2lGXkSXPd/K2Pi/OfYdbK+b60WCIgYBQmbZN8NQ/UKyMmhYHOpwpMKDLViUsQ7Q0iLq/gcr3UiXGqPFKafO6ypjLSVv09NUD6VzUC+F2dEw/AT1b0X9mfuWmbhyuSS0snN3JIbYQ3QucUSQuUPeasysQWAEpd+3E27QH/Vc1i7o3G6BQP4TFaGuXcMp87tKJPzj5CnCUuW8T7YUmdt646F10EWryTnEK/JVw5b/F6/HcRV89FWhoGgIr99afKeKiXJiy9+S2juXflzDfNKWLXVoL/gbzitJQJe2TWIFqQKDdVGYnyuWw0i0/Bc7ClCCdqaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3P0H34ZpXj3sa+FcMN/vj5YDCEarbvC4lpBt0odIAMc=; b=Y8FEFl+xC3Vd+34xiqj3CGCsjpoqTWfFYnpZX34Sjy+fJa2jaEguECPvWREM6rWNn0XyfaxeE0D2cofLpWHP0mcmbllQG84DLZ2BaumeYa9g0kZLjQtmsw7TuOayD3OE+Jfz2zrPopJXq/KCTt1UG0qdQ6/uA/psHixhIIBNd5U= Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=nxp.com; Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2712.eurprd04.prod.outlook.com (2603:10a6:4:99::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Wed, 24 Jun 2020 08:53:29 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 08:53:29 +0000 From: Peng Fan To: sstabellini@kernel.org, boris.ostrovsky@oracle.com, jgross@suse.com, konrad.wilk@oracle.com, mst@redhat.com, jasowang@redhat.com Subject: [PATCH] xen: introduce xen_vring_use_dma Date: Wed, 24 Jun 2020 17:17:32 +0800 Message-Id: <20200624091732.23944-1-peng.fan@nxp.com> X-Mailer: git-send-email 2.16.4 Content-Type: text/plain X-ClientProxiedBy: SG2PR06CA0246.apcprd06.prod.outlook.com (2603:1096:4:ac::30) To DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from linux-1xn6.ap.freescale.net (119.31.174.71) by SG2PR06CA0246.apcprd06.prod.outlook.com (2603:1096:4:ac::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend Transport; Wed, 24 Jun 2020 08:53:25 +0000 X-Mailer: git-send-email 2.16.4 X-Originating-IP: [119.31.174.71] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b1363182-65a2-4f59-943f-08d8181c10b1 X-MS-TrafficTypeDiagnostic: DB6PR0402MB2712: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0444EB1997 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9mpAvUN3MAvpE2dBNOq1hIK19nSFJtezhFUd0V3Z/4upNlCblRi6Wl0e+TsYY+0bcpel05AhPBC40biYbeksMfGUZ7ylBlnVj/+dwpz+mw1yIsyVE+JV5Q6e/wcqqMBaSHtpXuEAxSuy87MNi/vUXcoL6B69Xeo08zkDX/vPaUTEKDZxxpnYueXjkPI5scjccjkMgso8/h34PDNQdE+voqiSduplvtLrrt03kI8pepZn9ZXUGBK1YDzjv038Z2SI95EYzxWguf14NoJbXQ0g6HlLQhl/AkHtmkbiXWOec9GUDUkArn5wSmWik8cMsoJu5Q5fIM6NpnFZp8ynJ5YVHMPCHnrbBasCbfsI5CwmXpB2a5dkGw67yD6QB1fpC4IMw7CCZYeaNmpzyl1MHm7ZcmUWqia3ltq1nFXhLt5XNpJfAEQV8SB/UMmToq2JMaF9jdhpL7vlkebimVzk22Z85w== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(396003)(366004)(346002)(6506007)(8936002)(26005)(6486002)(956004)(1076003)(6666004)(478600001)(5660300002)(4326008)(186003)(316002)(16526019)(52116002)(66946007)(6512007)(7416002)(2616005)(2906002)(83380400001)(66476007)(66556008)(86362001)(44832011)(36756003)(8676002)(966005)(309714004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: OG8lcvpOfKsePRZSpoqPiKfOjSlfZR+WMFE/egKtYI2yfBBl+8ol0HEjayqHDHtp+KkCYMoGVThhpiOL3IfBJIY6oA2IH6mFpajCzEFm2q5Lhr3MyEw4EL3V5qGE0y2tBMh6eXqc/20VXATJ8R6HoRM9yubs4tsuDB17UfcFKNBE5pSAhXR7+rYw79VOkUFVs+FeeWRnheHkvvDYffaWxm3/ROFVmM2G802KEITO2U8dK27em+C6QX8o1W4te8lKcZ3nfFB+L0si/9u6oQRHHx0eSgUE/8zRumRyNlc9dIXjeDDxqceDTTZb1QuhbDEx5/fSBKjgZJdtYuveMNif3uIZxwD4kp3uxquQUYxhPqfQuwrU3rGIo7iiwR9ADrJRZ1xV42hf5seolGQPXIyEGMYLn5j9ZbW203l6Q0My3YSLJS5lcYZzrjdWxtIl2+HgbHMPP/nfqQN57SoV+uY2U5DcEk290bT9B2kpif/8je8Xj/hpsS2jEe4oF8BC9Hpr X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-Network-Message-Id: b1363182-65a2-4f59-943f-08d8181c10b1 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2020 08:53:29.3458 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: brJo6ak5M+QkoxRVepy34lWLh9fsrJGapTz3/dUz1YVi14IcgHD4cB3AmBsLTLXbtydlTOyte1wX94/BlqOoFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2712 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peng Fan , x86@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, linux-imx@nxp.com, xen-devel@lists.xenproject.org, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Export xen_swiotlb for all platforms using xen swiotlb Use xen_swiotlb to determine when vring should use dma APIs to map the ring: when xen_swiotlb is enabled the dma API is required. When it is disabled, it is not required. Signed-off-by: Peng Fan --- V2: This is a modified version from Stefano's patch https://lore.kernel.org/patchwork/patch/1033801/#1222404 Note: This is not to address rpmsg virtio issue, this is to let DomU virtio not using xen swiotlb could use non dma vring on ARM64 platforms. arch/arm/xen/mm.c | 1 + arch/x86/include/asm/xen/swiotlb-xen.h | 2 -- arch/x86/xen/pci-swiotlb-xen.c | 2 -- drivers/virtio/virtio_ring.c | 2 +- drivers/xen/swiotlb-xen.c | 3 +++ include/xen/swiotlb-xen.h | 6 ++++++ include/xen/xen.h | 6 ++++++ 7 files changed, 17 insertions(+), 5 deletions(-) diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c index d40e9e5fc52b..6a493ea087f0 100644 --- a/arch/arm/xen/mm.c +++ b/arch/arm/xen/mm.c @@ -139,6 +139,7 @@ static int __init xen_mm_init(void) struct gnttab_cache_flush cflush; if (!xen_initial_domain()) return 0; + xen_swiotlb = 1; xen_swiotlb_init(1, false); cflush.op = 0; diff --git a/arch/x86/include/asm/xen/swiotlb-xen.h b/arch/x86/include/asm/xen/swiotlb-xen.h index 6b56d0d45d15..bb5ce02b4e20 100644 --- a/arch/x86/include/asm/xen/swiotlb-xen.h +++ b/arch/x86/include/asm/xen/swiotlb-xen.h @@ -3,12 +3,10 @@ #define _ASM_X86_SWIOTLB_XEN_H #ifdef CONFIG_SWIOTLB_XEN -extern int xen_swiotlb; extern int __init pci_xen_swiotlb_detect(void); extern void __init pci_xen_swiotlb_init(void); extern int pci_xen_swiotlb_init_late(void); #else -#define xen_swiotlb (0) static inline int __init pci_xen_swiotlb_detect(void) { return 0; } static inline void __init pci_xen_swiotlb_init(void) { } static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; } diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c index 33293ce01d8d..071fbe0e1a91 100644 --- a/arch/x86/xen/pci-swiotlb-xen.c +++ b/arch/x86/xen/pci-swiotlb-xen.c @@ -18,8 +18,6 @@ #endif #include -int xen_swiotlb __read_mostly; - /* * pci_xen_swiotlb_detect - set xen_swiotlb to 1 if necessary * diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index a2de775801af..768afd79f67a 100644 --- a/drivers/virtio/virtio_ring.c +++ b/drivers/virtio/virtio_ring.c @@ -252,7 +252,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev) * the DMA API if we're a Xen guest, which at least allows * all of the sensible Xen configurations to work correctly. */ - if (xen_domain()) + if (xen_vring_use_dma()) return true; return false; diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c index b6d27762c6f8..25747e72e6fe 100644 --- a/drivers/xen/swiotlb-xen.c +++ b/drivers/xen/swiotlb-xen.c @@ -40,6 +40,9 @@ #include #define MAX_DMA_BITS 32 + +int xen_swiotlb __read_mostly; + /* * Used to do a quick range check in swiotlb_tbl_unmap_single and * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by this diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h index ffc0d3902b71..235babcde848 100644 --- a/include/xen/swiotlb-xen.h +++ b/include/xen/swiotlb-xen.h @@ -12,4 +12,10 @@ void xen_dma_sync_for_device(dma_addr_t handle, phys_addr_t paddr, size_t size, extern int xen_swiotlb_init(int verbose, bool early); extern const struct dma_map_ops xen_swiotlb_dma_ops; +#ifdef CONFIG_SWIOTLB_XEN +extern int xen_swiotlb; +#else +#define xen_swiotlb (0) +#endif + #endif /* __LINUX_SWIOTLB_XEN_H */ diff --git a/include/xen/xen.h b/include/xen/xen.h index 19a72f591e2b..c51c46f5d739 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -52,4 +52,10 @@ bool xen_biovec_phys_mergeable(const struct bio_vec *vec1, extern u64 xen_saved_max_mem_size; #endif +#include +static inline int xen_vring_use_dma(void) +{ + return !!xen_swiotlb; +} + #endif /* _XEN_XEN_H */ -- 2.16.4 From xen-devel-bounces@lists.xenproject.org Wed Jun 24 09:07:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 09:07:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo1Mx-0004o2-CX; Wed, 24 Jun 2020 09:06:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo1Mv-0004nx-I5 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 09:06:57 +0000 X-Inumbo-ID: 0d7bce02-b5fa-11ea-8496-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 0d7bce02-b5fa-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 09:06:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592989615; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BWweQzpvz5qRvsYocQLFZ/CEELAJfUtNzgc7NW2oHMc=; b=CGhN7dyV+qMddUF4oBDwNhIkVao2HbnxaoePCr1VSfgO7bHrW/RfIy1dolC+IMQoYJpN/F xTj/RKsjY1TxQiMhxaj8IoJZ1zmGBJ4RwuOdkshKlKvtM5M3Qc5cxCTEUTPWUbMeHiJcDk ptgr8/KgF45U0nr2HI0tuFwQDy/wLFA= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-458-qxNUxnGHObmsdMbvfjqgcw-1; Wed, 24 Jun 2020 05:06:54 -0400 X-MC-Unique: qxNUxnGHObmsdMbvfjqgcw-1 Received: by mail-wr1-f72.google.com with SMTP id a6so2292773wrq.3 for ; Wed, 24 Jun 2020 02:06:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BWweQzpvz5qRvsYocQLFZ/CEELAJfUtNzgc7NW2oHMc=; b=M5dtTT2qu3QgcuCMr15YR8RTlZ/FpqLZcjTrvn6kdmNMfNyXTvNv60s8nw5hCqlsZn MrL7s6FnntBYqmrpQPlhJ0tOKv1o81OpgPGRT5uz92+e3aiD+eygSefLsj+9OIFJmOR+ JUX8TS8ZmWZ12oWfA6O9jy7dBhlXftl8jXdk/soZTn53dsvqHW4CbU58g6X0DDbWqEir 8D8UNzVc3i4NS0QmMYZ/o5nD3fpXA/97Sd5lQPeSYlKySglM6/3M7tUgOrdENkcpGOAG BoH0pAajinsO6zAIbElvph6MKJPJMEusDQ1vVu6MkSlSJX0B0q5Bgg7aHLxW+Gq5mpgV fB2Q== X-Gm-Message-State: AOAM533a2Hw0HbOzStfZM71edmHNhHEf6iZO9stTItppGbYkqJZuue5i bwdIKPX4knIl2Zwg2rjLCaHcsT1REkieF85Cq2/n+XAqdkVzViUjSdJ07G8MQrWAvJbi2CsEcTk ROg2lvE+Q00DJLRxoBy1voNnikCE= X-Received: by 2002:a7b:c4d6:: with SMTP id g22mr276000wmk.170.1592989612933; Wed, 24 Jun 2020 02:06:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCjnIRq0GLGlJ0yYJ0oEVhHQJi+H1TnyLeWn06GTYZrPy1eSbfHNnWW2xTl+/KbPsMMBv1Rw== X-Received: by 2002:a7b:c4d6:: with SMTP id g22mr275986wmk.170.1592989612754; Wed, 24 Jun 2020 02:06:52 -0700 (PDT) Received: from redhat.com ([82.166.20.53]) by smtp.gmail.com with ESMTPSA id n189sm7181712wmb.43.2020.06.24.02.06.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 02:06:51 -0700 (PDT) Date: Wed, 24 Jun 2020 05:06:48 -0400 From: "Michael S. Tsirkin" To: Peng Fan Subject: Re: [PATCH] xen: introduce xen_vring_use_dma Message-ID: <20200624050355-mutt-send-email-mst@kernel.org> References: <20200624091732.23944-1-peng.fan@nxp.com> MIME-Version: 1.0 In-Reply-To: <20200624091732.23944-1-peng.fan@nxp.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, sstabellini@kernel.org, konrad.wilk@oracle.com, jasowang@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, linux-imx@nxp.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > Export xen_swiotlb for all platforms using xen swiotlb > > Use xen_swiotlb to determine when vring should use dma APIs to map the > ring: when xen_swiotlb is enabled the dma API is required. When it is > disabled, it is not required. > > Signed-off-by: Peng Fan Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? Xen was there first, but everyone else is using that now. > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > index a2de775801af..768afd79f67a 100644 > --- a/drivers/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -252,7 +252,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev) > * the DMA API if we're a Xen guest, which at least allows > * all of the sensible Xen configurations to work correctly. > */ > - if (xen_domain()) > + if (xen_vring_use_dma()) > return true; > > return false; The comment above this should probably be fixed. -- MST From xen-devel-bounces@lists.xenproject.org Wed Jun 24 10:01:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 10:01:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2DR-0001ai-Ku; Wed, 24 Jun 2020 10:01:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2DQ-0001ad-T2 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 10:01:12 +0000 X-Inumbo-ID: a0590198-b601-11ea-8090-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a0590198-b601-11ea-8090-12813bfff9fa; Wed, 24 Jun 2020 10:01:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 48E51AD25; Wed, 24 Jun 2020 10:01:08 +0000 (UTC) Subject: Re: [xen-4.11-testing test] 151295: regressions - FAIL To: osstest service owner References: From: Jan Beulich Message-ID: Date: Wed, 24 Jun 2020 12:01:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23.06.2020 20:32, osstest service owner wrote: > flight 151295 xen-4.11-testing real [real] > http://logs.test-lab.xenproject.org/osstest/logs/151295/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-amd64-prev 6 xen-build fail in 151260 REGR. vs. 150040 > build-i386-prev 6 xen-build fail in 151260 REGR. vs. 150040 > > Tests which are failing intermittently (not blocking): > test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 151260 > > Tests which did not succeed, but are not blocking: I'm once again struggling to see why there was no push here: The latter two groups both say "not blocking", and the two build-*-prev didn't actually fail here, but in an earlier flight. Without understanding the reason here I'm hesitant to suggest a force push, though. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 10:03:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 10:03:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2FQ-0001hE-0r; Wed, 24 Jun 2020 10:03:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2FP-0001h7-2x for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 10:03:15 +0000 X-Inumbo-ID: eabf84b4-b601-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eabf84b4-b601-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 10:03:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 184CCAD25; Wed, 24 Jun 2020 10:03:13 +0000 (UTC) Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: Andrew Cooper References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> <901046162.11470361.1592874264410.JavaMail.zimbra@cert.pl> <32b7234b-dc64-a0ea-2c5c-448bcec44c34@suse.com> From: Jan Beulich Message-ID: Date: Wed, 24 Jun 2020 12:03:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Tamas K Lengyel , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23.06.2020 19:24, Andrew Cooper wrote: > On 23/06/2020 09:51, Jan Beulich wrote: >> On 23.06.2020 03:04, Michał Leszczyński wrote: >>> ----- 22 cze 2020 o 18:16, Jan Beulich jbeulich@suse.com napisał(a): >>> >>>> On 22.06.2020 18:02, Michał Leszczyński wrote: >>>>> ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisał(a): >>>>>> On 22.06.2020 16:35, Michał Leszczyński wrote: >>>>>>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisał(a): >>>>>>>> Is any of what you do in this switch() actually legitimate without >>>>>>>> hvm_set_vmtrace_pt_size() having got called for the guest? From >>>>>>>> remarks elsewhere I imply you expect the param that you currently >>>>>>>> use to be set upon domain creation time, but at the very least the >>>>>>>> potentially big buffer should imo not get allocated up front, but >>>>>>>> only when tracing is to actually be enabled. >>>>>>> Wait... so you want to allocate these buffers in runtime? >>>>>>> Previously we were talking that there is too much runtime logic >>>>>>> and these enable/disable hypercalls should be stripped to absolute >>>>>>> minimum. >>>>>> Basic arrangements can be made at domain creation time. I don't >>>>>> think though that it would be a good use of memory if you >>>>>> allocated perhaps many gigabytes of memory just for possibly >>>>>> wanting to enable tracing on a guest. >>>>>> >>>>> From our previous conversations I thought that you want to have >>>>> as much logic moved to the domain creation as possible. >>>>> >>>>> Thus, a parameter "vmtrace_pt_size" was introduced. By default it's >>>>> zero (= disabled), if you set it to a non-zero value, then trace buffers >>>>> of given size will be allocated for the domain and you have possibility >>>>> to use ipt_enable/ipt_disable at any moment. >>>>> >>>>> This way the runtime logic is as thin as possible. I assume user knows >>>>> in advance whether he/she would want to use external monitoring with IPT >>>>> or not. >>>> Andrew - I think you requested movement to domain_create(). Could >>>> you clarify if indeed you mean to also allocate the big buffers >>>> this early? >>> I would like to recall what Andrew wrote few days ago: >>> >>> ----- 16 cze 2020 o 22:16, Andrew Cooper andrew.cooper3@citrix.com wrote: >>>> Xen has traditionally opted for a "and turn this extra thing on >>>> dynamically" model, but this has caused no end of security issues and >>>> broken corner cases. >>>> >>>> You can see this still existing in the difference between >>>> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being >>>> required to chose the number of vcpus for the domain) and we're making >>>> good progress undoing this particular wart (before 4.13, it was >>>> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by >>>> issuing other hypercalls between these two). >>>> >>>> There is a lot of settings which should be immutable for the lifetime of >>>> the domain, and external monitoring looks like another one of these. >>>> Specifying it at createdomain time allows for far better runtime >>>> behaviour (you are no longer in a situation where the first time you try >>>> to turn tracing on, you end up with -ENOMEM because another VM booted in >>>> the meantime and used the remaining memory), and it makes for rather >>>> more simple code in Xen itself (at runtime, you can rely on it having >>>> been set up properly, because a failure setting up will have killed the >>>> domain already). >>>> >>>> ... >>>> >>>> ~Andrew >>> according to this quote I've moved buffer allocation to the create_domain, >>> the updated version was already sent to the list as patch v3. >> I'd still like to see an explicit confirmation by him that this >> use of memory is indeed what he has intended. There are much smaller >> amounts of memory which we allocate on demand, just to avoid >> allocating some without then ever using it. > > PT is a debug/diagnostic tool.  Its not something you'd run in > production against a production VM. Well, the suggested use with introspection made me assume differently. If this is (now and forever) truly debug/diag only, so be it then. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 10:05:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 10:05:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2HW-0001om-Ee; Wed, 24 Jun 2020 10:05:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2HV-0001od-0G for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 10:05:25 +0000 X-Inumbo-ID: 38689444-b602-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 38689444-b602-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 10:05:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id ADEDDAE2B; Wed, 24 Jun 2020 10:05:22 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623135246.66170-1-roger.pau@citrix.com> <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> <20200623173150.GV735@Air-de-Roger> From: Jan Beulich Message-ID: <3ea0ff91-8e5c-701c-ee31-4140b247f3c9@suse.com> Date: Wed, 24 Jun 2020 12:05:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623173150.GV735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23.06.2020 19:32, Roger Pau Monné wrote: > On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote: >> On 23.06.2020 15:52, Roger Pau Monne wrote: >>> XENMEM_acquire_resource and it's related structure is currently inside >>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the >>> hypervisor or the toolstack only. This is wrong as the hypercall is >>> already being used by the Linux kernel at least, and as such needs to >>> be public. >> >> Actually - how does this work for the Linux kernel, seeing >> >> rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); >> if ( rc ) >> return rc; >> >> rc = xsm_domain_resource_map(XSM_DM_PRIV, d); >> if ( rc ) >> goto out; >> >> in the function? > > It's my understanding (I haven't tried to use that hypercall yet on > FreeBSD, so I cannot say I've tested it), that xmar.domid is the > remote domain, which the functions locks and then uses > xsm_domain_resource_map to check whether the current domain has > permissions to do privileged operations against it. Yes, but that's a tool stack operation, not something the kernel would do all by itself. The kernel would only ever pass DOMID_SELF (or the actual local domain ID), I would think. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 10:12:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 10:12:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2O3-0002k4-74; Wed, 24 Jun 2020 10:12:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2O2-0002jz-5f for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 10:12:10 +0000 X-Inumbo-ID: 2984648e-b603-11ea-8093-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2984648e-b603-11ea-8093-12813bfff9fa; Wed, 24 Jun 2020 10:12:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D8427AE2E; Wed, 24 Jun 2020 10:12:07 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> From: Jan Beulich Message-ID: <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> Date: Wed, 24 Jun 2020 12:12:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623172652.GU735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 23.06.2020 19:26, Roger Pau Monné wrote: > On Tue, Jun 23, 2020 at 06:18:52PM +0200, Jan Beulich wrote: >> On 23.06.2020 17:56, Roger Pau Monné wrote: >>> On Tue, Jun 23, 2020 at 05:02:04PM +0200, Jan Beulich wrote: >>>> On 23.06.2020 15:52, Roger Pau Monne wrote: >>>>> XENMEM_acquire_resource and it's related structure is currently inside >>>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the >>>>> hypervisor or the toolstack only. This is wrong as the hypercall is >>>>> already being used by the Linux kernel at least, and as such needs to >>>>> be public. >>>>> >>>>> Also switch the usage of uint64_aligned_t to plain uint64_t, as >>>>> uint64_aligned_t is only to be used by the toolstack. Note that the >>>>> layout of the structure will be the same, as the field is already >>>>> naturally aligned to a 8 byte boundary. >>>> >>>> I'm afraid it's more complicated, and hence ... >>>> >>>>> No functional change expected. >>>> >>>> ... this doesn't hold: As I notice only now the struct also wrongly >>>> (if it was meant to be a tools-only interface) failed to use >>>> XEN_GUEST_HANDLE_64(), which would in principle have been a problem >>>> for 32-bit callers (passing garbage in the upper half of a handle). >>>> It's not an actual problem because, unlike would typically be the >>>> case for tools-only interfaces, there is compat translation for this >>>> struct. >>> >>> Yes, there's already compat translation for the frame_list array. >>> >>>> With this, however, the problem of your change becomes noticeable: >>>> The structure's alignment for 32-bit x86, and with it the structure's >>>> sizeof(), both change. You should be able to see this by comparing >>>> xen/common/compat/memory.c's disassembly before and after your >>>> change - the number of bytes to copy by the respective >>>> copy_from_guest() ought to have changed. >>> >>> Right, this is the layout with frame aligned to 8 bytes: >>> >>> struct xen_mem_acquire_resource { >>> uint16_t domid; /* 0 2 */ >>> uint16_t type; /* 2 2 */ >>> uint32_t id; /* 4 4 */ >>> uint32_t nr_frames; /* 8 4 */ >>> uint32_t pad; /* 12 4 */ >>> uint64_t frame; /* 16 8 */ >>> long unsigned int * frame_list; /* 24 4 */ >>> >>> /* size: 32, cachelines: 1, members: 7 */ >>> /* padding: 4 */ >>> /* last cacheline: 32 bytes */ >>> }; >>> >>> And this is without: >>> >>> struct xen_mem_acquire_resource { >>> uint16_t domid; /* 0 2 */ >>> uint16_t type; /* 2 2 */ >>> uint32_t id; /* 4 4 */ >>> uint32_t nr_frames; /* 8 4 */ >>> uint32_t pad; /* 12 4 */ >>> uint64_t frame; /* 16 8 */ >>> long unsigned int * frame_list; /* 24 4 */ >>> >>> /* size: 28, cachelines: 1, members: 7 */ >>> /* last cacheline: 28 bytes */ >>> }; >>> >>> Note Xen has already been copying those extra 4 padding bytes from >>> 32bit Linux kernels AFAICT, as the struct declaration in Linux has >>> dropped the aligned attribute. >>> >>>> The question now is whether we're willing to accept such a (marginal) >>>> incompatibility. The chance of a 32-bit guest actually running into >>>> it shouldn't be very high, but with the right placement of an >>>> instance of the struct at the end of a page it would be possible to >>>> observe afaict. >>>> >>>> Or whether we go the alternative route and pad the struct suitably >>>> for 32-bit. >>> >>> I guess we are trapped with what Linux has on it's headers now, so we >>> should handle the struct size difference in Xen? >> >> How do you mean to notice the difference in Xen? You don't know >> what the caller's environment's sizeof() would yield. > > I'm confused. Couldn't we switch from uint64_aligned_t to plain > uint64_t (like it's currently on the Linux headers), and then use the > compat layer in Xen to handle the size difference when called from > 32bit environments? And which size would we use there? The old or the new one (breaking future or existing callers respectively)? Meanwhile I think that if this indeed needs to not be tools-only (which I still question), then our only possible route is to add explicit padding for the 32-bit case alongside the change you're already making. > This would of course assume that no toolstack has implemented direct > calls using this interface, which seems likely because it either > returns mfns to be mapped in the PV case or require gfns to be > provided for HVM. What are "direct calls" in the case here? We aren't talking about a dmop interface, but a memop one here, are we? It's merely an interface that an ioreq server implementation ought to use to get hold of the ring pages (i.e. there's only a weak connection to dmop). Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 10:29:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 10:29:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2ey-0003vM-SP; Wed, 24 Jun 2020 10:29:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2ex-0003vH-Q0 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 10:29:39 +0000 X-Inumbo-ID: 9b4ff9dc-b605-11ea-8496-bc764e2007e4 Received: from mail-wr1-x435.google.com (unknown [2a00:1450:4864:20::435]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9b4ff9dc-b605-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 10:29:39 +0000 (UTC) Received: by mail-wr1-x435.google.com with SMTP id v3so1755993wrc.1 for ; Wed, 24 Jun 2020 03:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=L/M44pw6Sj0jQWJNPY8bz6QSJKszKrTbkOfiJgdRQek=; b=hyMZa9g2LwQq2bNyRHjHVcBMtvyxaNClreQTHyu0tZWF91VEgE6oZmacss4GjgSkY+ u39aWTKO7HGT8igc6iob4PPqflkB54QBBF9iS9fWfM4UJsUFIXzGARc/wQOfR+UEFLTP ljNLB0/A+sRqJQui5OcDuXf1tRGz5vg0r6lK01qiZAzfbBB2YivPRYCTsbyx/79sE4/+ PKOa9KfLumpomoYN7ciSDWHpasR8L/AA+3eX0I9dt48zAyyiKGn+/v0IDINHy0blMIhg bPE6UMiNocQBNzwsZpVfqq6GwIxFBYGGI2tTgC6KlxQ1nxyE1e/d1emwEVWhqBiuTDEr BGcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=L/M44pw6Sj0jQWJNPY8bz6QSJKszKrTbkOfiJgdRQek=; b=hmD9nnYzqnESplQ99REDZtWFMhCKWK6w9KmUR96qAtQotZTRMW6P7x664pthUzrTdo +PgrwEg8+9G/1HIWDR3fCDGch534gLIzbFf1w61QCtESO9YL0jcHKy3udsdJ8phyaZsM OyTfHcZNJWHmAy9YbF3CFu555nkfIe0fYaJkv2QPhCxSXn0+kUFYlxq2y0tguWqyzZ/1 8oa2F8t0L2Gqfcih98ju/PqJNvPyFWf7Oe34IABP3f320eirdkuK6UBc+OhoZpAl/8Is WgGss/Xw1ovPfOG/7by72h5sSL5PX40iCLMc2eDfP6U5PwYzYqZedZCNdQqsqzUHSYM0 LW/A== X-Gm-Message-State: AOAM533pmr3WuFM7tPlho+sL3NHezjw5wrowt7vmDw4bjsnKLYxre0ew SL21T6ck+FYjiMeIqGOrWv0= X-Google-Smtp-Source: ABdhPJxE9feSwol6Kklwvh3VZkAguHITTU8sBNe2WESkl417qGR/iAhk29Jn3pdBYy/8JQSBkI1htg== X-Received: by 2002:adf:f350:: with SMTP id e16mr27815906wrp.43.1592994578119; Wed, 24 Jun 2020 03:29:38 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id e5sm24855173wrs.33.2020.06.24.03.29.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 03:29:37 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jason Andryuk'" References: <87k0zykwdl.fsf@dusky.pond.sub.org> <000001d64953$f67a1f00$e36e5d00$@xen.org> In-Reply-To: Subject: RE: sysbus failed assert for xen_sysdev Date: Wed, 24 Jun 2020 11:29:36 +0100 Message-ID: <000801d64a12$5c7c11f0$157435d0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIJfv1jP4fCJU6d0eNUL65zTb1lhAKJjZPCAZLY/IEByWeHdwFU8pWtAkUeRcOoNSQ3UA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Anthony PERARD' , 'xen-devel' , 'Mark Cave-Ayland' , 'Markus Armbruster' , 'QEMU' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jason Andryuk > Sent: 24 June 2020 04:24 > To: Paul Durrant > Cc: Markus Armbruster ; Mark Cave-Ayland ; Anthony > PERARD ; xen-devel ; QEMU devel@nongnu.org> > Subject: Re: sysbus failed assert for xen_sysdev > > On Tue, Jun 23, 2020 at 7:46 AM Paul Durrant wrote: > > > > > -----Original Message----- > > > From: Markus Armbruster > > > Sent: 23 June 2020 09:41 > > > To: Jason Andryuk > > > Cc: Mark Cave-Ayland ; Anthony PERARD ; > xen- > > > devel ; Paul Durrant ; QEMU > > > Subject: Re: sysbus failed assert for xen_sysdev > > > > > > Jason Andryuk writes: > > > > Then it gets farther... until > > > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > > > > Assertion `dev->realized' failed. > > > > > > > > dev->id is NULL. The failing device is: > > > > (gdb) p *dev.parent_obj.class.type > > > > $12 = {name = 0x555556207770 "cfi.pflash01", > > > > > > > > Having commented out the call to xen_be_init() entirely (and xen_bus_init() for good measure) I also > get this assertion failure, so > > I don't think is related. > > Yes, this is something different. pc_pflash_create() calls > qdev_new(TYPE_PFLASH_CFI01), but it is only realized in > pc_system_flash_map()... and pc_system_flash_map() isn't called for > Xen. > > Removing the call to pc_system_flash_create() from pc_machine_initfn() > lets QEMU startup and run a Xen HVM again. xen_enabled() doesn't work > there since accelerators have not been initialized yes, I guess? Looks like it can be worked round by the following: diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 1497d0e4ae..977d40afb8 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -186,9 +186,12 @@ static void pc_init1(MachineState *machine, if (!xen_enabled()) { pc_memory_init(pcms, system_memory, rom_memory, &ram_memory); - } else if (machine->kernel_filename != NULL) { - /* For xen HVM direct kernel boot, load linux here */ - xen_load_linux(pcms); + } else { + pc_system_flash_cleanup_unused(pcms); + if (machine->kernel_filename != NULL) { + /* For xen HVM direct kernel boot, load linux here */ + xen_load_linux(pcms); + } } gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled); diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c index ec2a3b3e7e..0ff47a4b59 100644 --- a/hw/i386/pc_sysfw.c +++ b/hw/i386/pc_sysfw.c @@ -108,7 +108,7 @@ void pc_system_flash_create(PCMachineState *pcms) } } -static void pc_system_flash_cleanup_unused(PCMachineState *pcms) +void pc_system_flash_cleanup_unused(PCMachineState *pcms) { char *prop_name; int i; diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h index e6135c34d6..497f2b7ab7 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -187,6 +187,7 @@ int cmos_get_fd_drive_type(FloppyDriveType fd0); /* pc_sysfw.c */ void pc_system_flash_create(PCMachineState *pcms); +void pc_system_flash_cleanup_unused(PCMachineState *pcms); void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory); /* acpi-build.c */ > > Regards, > Jason From xen-devel-bounces@lists.xenproject.org Wed Jun 24 10:35:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 10:35:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2kk-0004jX-HV; Wed, 24 Jun 2020 10:35:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo2kj-0004jS-UV for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 10:35:37 +0000 X-Inumbo-ID: 7065a90a-b606-11ea-8496-bc764e2007e4 Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7065a90a-b606-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 10:35:36 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: BSMsCqpUMqBviCsQF6Rld13Ftzteb5PskJVW3gchlDwuDGHxsRaS6YW9RvTkSWQ5m1UW7CAbeT N756ZKRmHNDMzuZ5h8yUKgGoY6d0hErfcC1e19PTZZ7EBmByUughjc4k2Xsi7OXZArS1wX11IN EC69UqdEbP8B2JZsteePA1qf+F3VggUL+LbieUXGrPliv5KdrtRP36Ztx+EwF6zXnyAfzFODtO NGCs9ocmFotRNsA7x1PCj5LO9cXJ739D4Mq2OPFwTO7fAEi3fipKPJqYPIc45vFP7bMNZ4+6BH UQ0= X-SBRS: 2.7 X-MesageID: 21605881 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,275,1589256000"; d="scan'208";a="21605881" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24307.11381.75189.206321@mariner.uk.xensource.com> Date: Wed, 24 Jun 2020 11:35:33 +0100 To: Jan Beulich Subject: Re: [xen-4.11-testing test] 151295: regressions - FAIL In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jan Beulich writes ("Re: [xen-4.11-testing test] 151295: regressions - FAIL"): > On 23.06.2020 20:32, osstest service owner wrote: > > flight 151295 xen-4.11-testing real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/151295/ > > > > Regressions :-( > > > > Tests which did not succeed and are blocking, > > including tests which could not be run: > > build-amd64-prev 6 xen-build fail in 151260 REGR. vs. 150040 > > build-i386-prev 6 xen-build fail in 151260 REGR. vs. 150040 > > > > Tests which are failing intermittently (not blocking): > > test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail pass in 151260 > > > > Tests which did not succeed, but are not blocking: > > I'm once again struggling to see why there was no push here: The > latter two groups both say "not blocking", and the two build-*-prev > didn't actually fail here, but in an earlier flight. Without > understanding the reason here I'm hesitant to suggest a force push, > though. osstest is using the earlier flight (151260) to justify considering pushing despite test-amd64-amd64-xl-qemut-debianhvm-i386-xsm but that means it wants a justification for all the failures in 151260 too. Broadly speaking, this logic is necessary because failed tests can block other tests. I think this will succeed on the next run. Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 10:53:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 10:53:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo31T-0006W5-Uf; Wed, 24 Jun 2020 10:52:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo31S-0006W0-MP for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 10:52:54 +0000 X-Inumbo-ID: d95d8750-b608-11ea-8098-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d95d8750-b608-11ea-8098-12813bfff9fa; Wed, 24 Jun 2020 10:52:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nATr8y40Hr5eNgzGNrrvnInLUyN2fGGQvbWdU1iGVTo=; b=OpeEbhwESls5JjtKoJr2Ggzg9O BRlnbV9wFG1q4Cbu/6BvKZQjpPsQGf3FkSR9e9rYOYPV/dnuyWf781XQL+WTl9nko9nZIG0vsDZsF qPYP6onQKFTxWfNq24JA1DUGJTDfVtRXApW7e6tqx+clNPB7ICKh0DjaiYSey3SuR05s=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo31N-0007UU-Hs; Wed, 24 Jun 2020 10:52:49 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jo31N-0001P8-B2; Wed, 24 Jun 2020 10:52:49 +0000 Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623135246.66170-1-roger.pau@citrix.com> <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> <20200623173150.GV735@Air-de-Roger> <3ea0ff91-8e5c-701c-ee31-4140b247f3c9@suse.com> From: Julien Grall Message-ID: <4651b23b-ca82-a478-debd-c20cdcd3facd@xen.org> Date: Wed, 24 Jun 2020 11:52:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <3ea0ff91-8e5c-701c-ee31-4140b247f3c9@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Jan, On 24/06/2020 11:05, Jan Beulich wrote: > On 23.06.2020 19:32, Roger Pau Monné wrote: >> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote: >>> On 23.06.2020 15:52, Roger Pau Monne wrote: >>>> XENMEM_acquire_resource and it's related structure is currently inside >>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the >>>> hypervisor or the toolstack only. This is wrong as the hypercall is >>>> already being used by the Linux kernel at least, and as such needs to >>>> be public. >>> >>> Actually - how does this work for the Linux kernel, seeing >>> >>> rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); >>> if ( rc ) >>> return rc; >>> >>> rc = xsm_domain_resource_map(XSM_DM_PRIV, d); >>> if ( rc ) >>> goto out; >>> >>> in the function? >> >> It's my understanding (I haven't tried to use that hypercall yet on >> FreeBSD, so I cannot say I've tested it), that xmar.domid is the >> remote domain, which the functions locks and then uses >> xsm_domain_resource_map to check whether the current domain has >> permissions to do privileged operations against it. > > Yes, but that's a tool stack operation, not something the kernel > would do all by itself. The kernel would only ever pass DOMID_SELF > (or the actual local domain ID), I would think. You can't issue that hypercall directly from userspace because you need to map the page in the physical address space of the toolstack domain. So the kernel has to act as the proxy for the hypercall. This is implemented as mmap() in Linux. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 24 11:11:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 11:11:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo3Ir-0008Mf-Ez; Wed, 24 Jun 2020 11:10:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo3Iq-0008Ma-4D for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 11:10:52 +0000 X-Inumbo-ID: 5d367c60-b60b-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5d367c60-b60b-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 11:10:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=IVtI968zP5h1FRwwueFx/lewWfrfbMMK2WW89QgSsKo=; b=bvhznejiG5aUmUea4RRuRatfnw oS/ntUJsYn0MMgKhTotoIvd/xAf49UjSCqrJpCywVVbwzN5glbMUPcf/DCI/BzLFtL9q9pV7sNFkv jp1yCPzUxvgg2DjYroEpeQ+VWnvmBAPtfSAS5Y/EdprySRzAY2n6tk4OKU9Xw6SA0atQ=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo3Im-0007qb-7b; Wed, 24 Jun 2020 11:10:48 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jo3Il-0002Lf-Tt; Wed, 24 Jun 2020 11:10:48 +0000 From: Julien Grall Subject: Re: [PATCH for-4.14 v2] x86/tlb: fix assisted flush usage To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623145006.66723-1-roger.pau@citrix.com> <741ff589-4366-1430-6639-13dc5f02fdfa@xen.org> <20200623151542.GR735@Air-de-Roger> <20200623161607.GT735@Air-de-Roger> Message-ID: Date: Wed, 24 Jun 2020 12:10:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200623161607.GT735@Air-de-Roger> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Roger, On 23/06/2020 17:16, Roger Pau Monné wrote: > On Tue, Jun 23, 2020 at 04:46:29PM +0100, Julien Grall wrote: >> >> >> On 23/06/2020 16:15, Roger Pau Monné wrote: >>> On Tue, Jun 23, 2020 at 04:08:06PM +0100, Julien Grall wrote: >>>> Hi Roger, >>>> >>>> On 23/06/2020 15:50, Roger Pau Monne wrote: >>>>> diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h >>>>> index 9b62087be1..f360166f00 100644 >>>>> --- a/xen/include/xen/mm.h >>>>> +++ b/xen/include/xen/mm.h >>>>> @@ -639,7 +639,8 @@ static inline void accumulate_tlbflush(bool *need_tlbflush, >>>>> } >>>>> } >>>>> -static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) >>>>> +static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp, >>>>> + bool sync) >>>> >>>> I read the commit message and went through the code, but it is still not >>>> clear what "sync" means in a non-architectural way. >>>> >>>> As an Arm developper, I would assume this means we don't wait for the TLB >>>> flush to complete. But I am sure this would result to some unexpected >>>> behavior. >>> >>> No, when we return from filtered_flush_tlb_mask the flush has been >>> performed (either with sync or without), but I understand the >>> confusion given the parameter name. >>> >>>> So can you explain on non-x86 words what this really mean? >>> >>> sync (in this context) means to force the usage of an IPI (if built >>> with PV or shadow paging support) in order to perform the flush. >> >> This is compare to? > > Using assisted flushes, like you do on Arm, where you don't send an > IPI in order to achieve a TLB flush on a remote pCPU. AFAICT, the assisted flushes only happen when running a nested Xen. Is that correct? > >>> AFAICT on Arm you always avoid an IPI when performing a flush, and >>> that's fine because you don't have PV or shadow, and then you don't >>> require this. >> >> Arm provides instructions to broadcast TLB flush, so by the time one of >> instruction is completed there is all the TLB entry associated to the >> translation doesn't exist. >> >> I don't think using PV or shadow would change anything here in the way we do >> the flush. > > TBH, I'm not sure how this applies to Arm. There's no PV or shadow > implementation, so I have no idea whether this would apply or not. Yes there is none. However, my point was that if we had to implement PV/shadow on Arm then an IPI would definitely be my last choice. >>> >>> I could rename to force_ipi (or require_ipi) if that's better? >> >> Hmmm, based on what I wrote above, I don't think this name would be more >> suitable. However, regardless the name, it is not clear to me when a caller >> should use false or true. >> >> Have you considered a rwlock to synchronize the two? > > Yes, the performance drop is huge when I tried. I could try to refine, > but I think there's always going to be a performance drop, as you then > require mutual exclusion when modifying the page tables (you take the > lock in write mode). Right now modification of the page tables can be > done concurrently. Fair enough. I will scratch that suggestion then. Thanks for the explanation! So now getting back to filtered_flush_tlb(). AFAICT, the only two callers are in common code. The two are used for allocation purpose, so may I ask why they need to use different kind of flush? > > FWIW Xen explicitly moved from using a lock into this model in > 3203345bb13 apparently due to some deadlock situation. I'm not sure > if that still holds. The old classic major change with limited explanation :/. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 24 11:29:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 11:29:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo3bC-00016i-3u; Wed, 24 Jun 2020 11:29:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo3bA-00016d-OZ for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 11:29:48 +0000 X-Inumbo-ID: 0229ab82-b60e-11ea-80a0-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0229ab82-b60e-11ea-80a0-12813bfff9fa; Wed, 24 Jun 2020 11:29:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jxrqvPQcQTqxloYNyiAHBubQgck/QE2PPCyDRQMYLYA=; b=cx3b++vm/zyC6O7qC5a4KvEsJC yZGBuKvomIiArf2C7sm/L3i9v6xaj71+Bqh5vf5SDguEPYTu7ZpQnAPKXy2uet3bzkXKX6EKcwu6w 5zfQlgD9GGicvopiSXGnIUuikIr+NWy+W1ppKbdDajg16xpOKVjnZCgpM5JYo00qp4Ps=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo3b3-0008Az-HA; Wed, 24 Jun 2020 11:29:41 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jo3b3-00038G-6B; Wed, 24 Jun 2020 11:29:41 +0000 Subject: Re: [INPUT REQUESTED][PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Stefano Stabellini , Julien Grall , "committers@xenproject.org" References: <20200613184132.11880-1-julien@xen.org> <35c8373f-b691-d95e-17de-021c72faf216@xen.org> From: Julien Grall Message-ID: <691258d9-a0e7-ab72-74a3-5c5f6026a7e9@xen.org> Date: Wed, 24 Jun 2020 12:29:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , Paul Durrant , Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich , xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Gentle ping. It would be good to get this resolved for Xen 4.14. On 18/06/2020 16:00, Julien Grall wrote: > (+ Committers) > > On 18/06/2020 02:34, Stefano Stabellini wrote: >> On Tue, 16 Jun 2020, Julien Grall wrote: >>> On Tue, 16 Jun 2020 at 21:57, Stefano Stabellini >>> wrote: >>>> >>>> On Tue, 16 Jun 2020, Julien Grall wrote: >>>>> On 16/06/2020 02:00, Stefano Stabellini wrote: >>>>>> On Sat, 13 Jun 2020, Julien Grall wrote: >>>>>>> From: Julien Grall >>>>>>> >>>>>>> The documentation of pvcalls suggests there is padding for 32-bit >>>>>>> x86 >>>>>>> at the end of most the structure. However, they are not described in >>>>>>> in the public header. >>>>>>> >>>>>>> Because of that all the structures would be 32-bit aligned and not >>>>>>> 64-bit aligned for 32-bit x86. >>>>>>> >>>>>>> For all the other architectures supported (Arm and 64-bit x86), the >>>>>>> structure are aligned to 64-bit because they contain uint64_t field. >>>>>>> Therefore all the structures contain implicit padding. >>>>>>> >>>>>>> The paddings are now corrected for 32-bit x86 and written >>>>>>> explicitly for >>>>>>> all the architectures. >>>>>>> >>>>>>> While the structure size between 32-bit and 64-bit x86 is >>>>>>> different, it >>>>>>> shouldn't cause any incompatibility between a 32-bit and 64-bit >>>>>>> frontend/backend because the commands are always 56 bits and the >>>>>>> padding >>>>>>> are at the end of the structure. >>>>>>> >>>>>>> As an aside, the padding sadly cannot be mandated to be 0 as they >>>>>>> are >>>>>>> already present. So it is not going to be possible to use the >>>>>>> padding >>>>>>> for extending a command in the future. >>>>>>> >>>>>>> Signed-off-by: Julien Grall >>>>>>> >>>>>>> --- >>>>>>>       Changes in v3: >>>>>>>           - Use __i386__ rather than CONFIG_X86_32 >>>>>>> >>>>>>>       Changes in v2: >>>>>>>           - It is not possible to use the same padding for 32-bit >>>>>>> x86 and >>>>>>>           all the other supported architectures. >>>>>>> --- >>>>>>>    docs/misc/pvcalls.pandoc        | 18 ++++++++++-------- >>>>>>>    xen/include/public/io/pvcalls.h | 14 ++++++++++++++ >>>>>>>    2 files changed, 24 insertions(+), 8 deletions(-) >>>>>>> >>>>>>> diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc >>>>>>> index 665dad556c39..caa71b36d78b 100644 >>>>>>> --- a/docs/misc/pvcalls.pandoc >>>>>>> +++ b/docs/misc/pvcalls.pandoc >>>>>>> @@ -246,9 +246,9 @@ The format is defined as follows: >>>>>>>                            uint32_t domain; >>>>>>>                            uint32_t type; >>>>>>>                            uint32_t protocol; >>>>>>> -                         #ifdef CONFIG_X86_32 >>>>>>> +                 #ifndef __i386__ >>>>>>>                            uint8_t pad[4]; >>>>>>> -                         #endif >>>>>>> +                 #endif >>>>>> >>>>>> >>>>>> Hi Julien, >>>>>> >>>>>> Thank you for doing this, and sorry for having missed v2 of this >>>>>> patch, I >>>>>> should have replied earlier. >>>>>> >>>>>> The intention of the #ifdef blocks like: >>>>>> >>>>>>     #ifdef CONFIG_X86_32 >>>>>>       uint8_t pad[4]; >>>>>>     #endif >>>>>> >>>>>> in pvcalls.pandoc was to make sure that these structs would be 64bit >>>>>> aligned on x86_32 too. >>>>>> >>>>>> I realize that the public header doesn't match, but the spec is the >>>>>> "master copy". >>>>> >>>>> So far, the public headers are the defacto official ABI. So did you >>>>> mark the >>>>> pvcall header as just a reference? >>>> >>>> No, there is no document that says that the canonical copy of the >>>> interface is pvcalls.pandoc. However, it was clearly spelled out from >>>> the start on xen-devel (see below.) >>>> In fact, if you notice, this is the >>>> first document under docs/misc that goes into this level of details in >>>> describing a new PV protocol. Also note the title of the document which >>>> is "PV Calls Protocol version 1". >>> >>> While I understand this may have been the original intention, you >>> can't expect a developer to go through the archive to check whether >>> he/she should trust the header of the document. >>> >>>> >>>> >>>> In reply to Jan: >>>>> A public header can't be "fixed" if it may already be in use by >>>>> anyone. We can only do as Andrew and you suggest (mandate textual >>>>> descriptions to be "the ABI") when we do so for _new_ interfaces from >>>>> the very beginning, making clear that the public header (if any) >>>>> exists just for reference. >>>> >>>> What if somebody took the specification of the interface from >>>> pvcalls.pandoc and wrote their own headers and code? It is definitely >>>> possible. >>> >>> As it is possible for someone to have picked the headers from Xen as >>> in the past public/ has always been the authority. >> >> We never had documents under docs/ before specifying the interfaces >> before pvcalls. It is not written anywhere that the headers under >> public/ are the authoritative interfaces either, it is just that it was >> the only thing available before. If you are new to the project you might >> go to docs/ first. >> >> >>>> At the time, it was clarified that the purpose of writing such >>>> a detailed specification document was that the document was the >>>> specification :-) >>> >>> At the risk of being pedantic, if it is not written in xen.git it >>> doesn't exist ;). >>> >>> Anyway, no matter the decision you take here, you are going to >>> potentially break one set of the users. >>> >>> I am leaning towards the header as authoritative because this has >>> always been the case in the past and nothing in xen.git says >>> otherwise. However I am not a user of pvcalls, so I don't really have >>> any big incentive to go either way. >> >> Yeah, we are risking breaking one set of users either way :-/ >> In reality, we are using pvcalls on arm64 in a new project (but it is >> still very green). I am not aware of anybody using pvcalls on x86 >> (especially x86_32). >> >> I would prefer to honor the pvcalls.pandoc specification because that is >> what it was meant to be, and also leads to a better protocol >> specification. > > As Jan and you disagree on the approach, I would like to get more input. > > To summarize the discussion, the document for PV calls and the public > headers don't match when describing the padding. There is a disagreement > on which of the two are the authority and therefore which one to fix. > > Does anyone else have a preference on the approach? > >> >> >>> For the future, I would highly suggest writing down the support >>> decision in xen.git. This would avoid such debate on what is the >>> authority... >> >> Yes that's the way to go >> > -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:04:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:04:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo48o-0004ej-7a; Wed, 24 Jun 2020 12:04:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo48m-0004ee-KP for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:04:32 +0000 X-Inumbo-ID: dc8028c0-b612-11ea-bca7-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dc8028c0-b612-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 12:04:31 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: cv1J7JsxQH6wgFPVSyUdMst97wmPFW0i2kowllzuONv2IzsWniv5e4SOiDJXEOybb8JLW7aw5U IMNNIBb3Dr4zuKqVWFtJgYnvTSSRugnyBibEeIyjun25260emzoZvL/Xoji84cCW33RpM2OTi/ 1LnleDf7yNVo71MVQv8rkQZzTt5xgJcWNhc/YMcsLxTXGR2po5x/EnYOj79gPfaMQJhrwt8cOV GsCPsppBgK7xgCGxOhKyVw4MZ/ntFy9ddsfGJt5MU0MwRw8AtfqsOf09Peb7Bk1Q6C97NE+Nyd uvg= X-SBRS: 2.7 X-MesageID: 21032175 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,275,1589256000"; d="scan'208";a="21032175" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24307.16713.764272.855818@mariner.uk.xensource.com> Date: Wed, 24 Jun 2020 13:04:25 +0100 To: Julien Grall Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches In-Reply-To: References: <20200613184132.11880-1-julien@xen.org> <35c8373f-b691-d95e-17de-021c72faf216@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , Paul Durrant , Andrew Cooper , Julien Grall , George Dunlap , "committers@xenproject.org" , Jan Beulich , xen-devel , Roger Pau Monne , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Julien Grall writes ("Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches"): > (+ Committers) ... > As Jan and you disagree on the approach, I would like to get more input. > > To summarize the discussion, the document for PV calls and the public > headers don't match when describing the padding. There is a disagreement > on which of the two are the authority and therefore which one to fix. > > Does anyone else have a preference on the approach? Hi. >[Jan:] >> I am leaning towards the header as authoritative because this has >> always been the case in the past and nothing in xen.git says >> otherwise. However I am not a user of pvcalls, so I don't really have >> any big incentive to go either way. I think the practice of using headers as protocol specs is not a particularly good one. Certainly my expectations anywhere outside the Xen Project is that if there's a doc, that is at the very least on par with any header file. Of course there are possible compatibility implications: > Yeah, we are risking breaking one set of users either way :-/ > In reality, we are using pvcalls on arm64 in a new project (but it is > still very green). I am not aware of anybody using pvcalls on x86 > (especially x86_32). > > I would prefer to honor the pvcalls.pandoc specification because that is > what it was meant to be, and also leads to a better protocol > specification. pvcalls in Linux is Tech Preview / Experimental AFAICT ? I think that means we can de jure change things like this. And it seems that we don't think there are any actual users who would experience compatibility problems. So I don't think the compatibility concerns are a reason not to change the header rather than the document. So I think my conclusion is the same as Julien's: we should change the header to match the doc. > >> For the future, I would highly suggest writing down the support > >> decision in xen.git. This would avoid such debate on what is the > >> authority... > > > > Yes that's the way to go Maybe it would be worth putting a note somewhere in the headers saying the headers are provided for convenience but that the ABIs and protocols are as specified in the docs (at least where docs exist). Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:05:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:05:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo49M-0004gb-G4; Wed, 24 Jun 2020 12:05:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo49L-0004gU-HG for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:05:07 +0000 X-Inumbo-ID: f14f7a13-b612-11ea-80a4-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f14f7a13-b612-11ea-80a4-12813bfff9fa; Wed, 24 Jun 2020 12:05:06 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: YSAQ+V6Rmln6w4lLe3tMLNONSDP0o0jCzGk+ZbVjrT2K3UTGt9nduQD7kfx35Q+i/fR1Fcf/DF kUrAFDRgmECQeKgWjGlMAz81z0awijQYvKLG7xZrfgCrl72SLbaehsviJkmIKMFRtPpN6acmZB 5YPYdEce3B2oICaLl7HCttn6D/CR19RzsPndNKJLOdaGt3MaTF71/d0m4XpBidWekiXwYF1btu 4qC8wS8KRBLtlS/iHWtdhGoNY+Vban5Alu8hhRW4ULOifgaIgb6AGZ2l8d96keZw8agN/QH2/k D+0= X-SBRS: 2.7 X-MesageID: 21611800 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,275,1589256000"; d="scan'208";a="21611800" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24307.16749.664567.685628@mariner.uk.xensource.com> Date: Wed, 24 Jun 2020 13:05:01 +0100 To: Julien Grall Subject: Re: [INPUT REQUESTED][PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches In-Reply-To: <691258d9-a0e7-ab72-74a3-5c5f6026a7e9@xen.org> References: <20200613184132.11880-1-julien@xen.org> <35c8373f-b691-d95e-17de-021c72faf216@xen.org> <691258d9-a0e7-ab72-74a3-5c5f6026a7e9@xen.org> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , Paul Durrant , Andrew Cooper , Julien Grall , George Dunlap , "committers@xenproject.org" , Jan Beulich , xen-devel , Roger Pau Monne , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Julien Grall writes ("Re: [INPUT REQUESTED][PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches"): > Gentle ping. It would be good to get this resolved for Xen 4.14. Oh and I agree that this should be changed for 4.14. Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:08:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:08:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4Cx-0004yz-2f; Wed, 24 Jun 2020 12:08:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4Cw-0004yu-Os for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:08:50 +0000 X-Inumbo-ID: 769b94e4-b613-11ea-80a4-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 769b94e4-b613-11ea-80a4-12813bfff9fa; Wed, 24 Jun 2020 12:08:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 21E28AED7; Wed, 24 Jun 2020 12:08:49 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Julien Grall References: <20200623135246.66170-1-roger.pau@citrix.com> <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> <20200623173150.GV735@Air-de-Roger> <3ea0ff91-8e5c-701c-ee31-4140b247f3c9@suse.com> <4651b23b-ca82-a478-debd-c20cdcd3facd@xen.org> From: Jan Beulich Message-ID: Date: Wed, 24 Jun 2020 14:08:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <4651b23b-ca82-a478-debd-c20cdcd3facd@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 24.06.2020 12:52, Julien Grall wrote: > Hi Jan, > > On 24/06/2020 11:05, Jan Beulich wrote: >> On 23.06.2020 19:32, Roger Pau Monné wrote: >>> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote: >>>> On 23.06.2020 15:52, Roger Pau Monne wrote: >>>>> XENMEM_acquire_resource and it's related structure is currently inside >>>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the >>>>> hypervisor or the toolstack only. This is wrong as the hypercall is >>>>> already being used by the Linux kernel at least, and as such needs to >>>>> be public. >>>> >>>> Actually - how does this work for the Linux kernel, seeing >>>> >>>> rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); >>>> if ( rc ) >>>> return rc; >>>> >>>> rc = xsm_domain_resource_map(XSM_DM_PRIV, d); >>>> if ( rc ) >>>> goto out; >>>> >>>> in the function? >>> >>> It's my understanding (I haven't tried to use that hypercall yet on >>> FreeBSD, so I cannot say I've tested it), that xmar.domid is the >>> remote domain, which the functions locks and then uses >>> xsm_domain_resource_map to check whether the current domain has >>> permissions to do privileged operations against it. >> >> Yes, but that's a tool stack operation, not something the kernel >> would do all by itself. The kernel would only ever pass DOMID_SELF >> (or the actual local domain ID), I would think. > > You can't issue that hypercall directly from userspace because you need > to map the page in the physical address space of the toolstack domain. > > So the kernel has to act as the proxy for the hypercall. This is > implemented as mmap() in Linux. Oh, and there's no generic wrapping available here, unlike for dmop. Makes me wonder whether, for this purpose, there should be (have been) a new dmop with identical functionality, to allow such funneling. Janan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:15:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:15:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4J2-0005nL-P8; Wed, 24 Jun 2020 12:15:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4J1-0005nG-IO for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:15:07 +0000 X-Inumbo-ID: 56c4c32e-b614-11ea-bb8b-bc764e2007e4 Received: from mail-lj1-x22c.google.com (unknown [2a00:1450:4864:20::22c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 56c4c32e-b614-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 12:15:06 +0000 (UTC) Received: by mail-lj1-x22c.google.com with SMTP id 9so2284448ljv.5 for ; Wed, 24 Jun 2020 05:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kaKwEbbW2ztK3RuQ9ZWn5mPfX2K56o8rjEZmfwyk68E=; b=dXqhFVwms8+gi2fAP1LxsWG3dRdUzKeFnqAPEPeIr6dj7oyOg9pUd+6YuZ3K6ZJgXC omF+5RpQT2YrRuLHyfNTx5xFTjC3XN0bFYheKW860ww1zoShtM2k6PoB/sfGWjOVRnsd vRiHZsRD75JaqCirdZp7owWTGC8aZF5Q6PFmjCdlK9xu1VAYbigpb5EG8tr2fDWQAvcf TVmF8B8HAtHbZvGcnJDFWRsnMB/jFd6g/N/uOM4/mD0iYIl82hj+gE+z68Oflggy2n2h ZmofK49lCLwbd9MBGgzrXhoTiGw2mQcy3z87D3XOL76RrfrVN8MFijD2Q94zWNn0sye6 RQkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kaKwEbbW2ztK3RuQ9ZWn5mPfX2K56o8rjEZmfwyk68E=; b=HNYeU9uC4k/mwH0RP2PsXqLoYqjG6KW5giF/F7wegKH3x+yCyqL0wdnydmbYGbjCR5 qemzx6jCMYAJBX0Kl331CDapZDUyrTftqynE7jr6wvgocAkjt2Z9T1zWGws5AN4faj2W 05VQd0/Blrycm2zwBkSyhJThdAfgIKhNsAAayVgo20xJLN8e115TqnrYwBpFQPzb5oXE r2e/5Q0i344PC4VdwNLjeufOG24S2jla/X+UV1Q7rStXzvuaq9X/qCxy4LvNelvpzZHA EZNWFnQ5wD/TguAcavmVU1p7S/dIf5rujUnnTPAxUEYtnmbhz8XstUclP/7t8pBO1Gyq 9gYA== X-Gm-Message-State: AOAM530szTNIqn1w0V7jaEzt15KGl/KBU9+KCjjXSxGazbE3PbK6aWT9 WHNalqoA/u5pVA9+BxIACSoMh+XIPIhQjD5T7jY= X-Google-Smtp-Source: ABdhPJzv+dxluygLYzvno2zQmxR0eAl/LJiIqxaDyEk6jVFzBgLoeGygE/iHVSLRaJhdrSrCb4hl8fAe21SwXUXFwsw= X-Received: by 2002:a2e:9141:: with SMTP id q1mr13191750ljg.196.1593000905453; Wed, 24 Jun 2020 05:15:05 -0700 (PDT) MIME-Version: 1.0 References: <87k0zykwdl.fsf@dusky.pond.sub.org> <000001d64953$f67a1f00$e36e5d00$@xen.org> <000801d64a12$5c7c11f0$157435d0$@xen.org> In-Reply-To: <000801d64a12$5c7c11f0$157435d0$@xen.org> From: Jason Andryuk Date: Wed, 24 Jun 2020 08:14:53 -0400 Message-ID: Subject: Re: sysbus failed assert for xen_sysdev To: Paul Durrant Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony PERARD , xen-devel , Mark Cave-Ayland , Markus Armbruster , QEMU Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 6:29 AM Paul Durrant wrote: > > > -----Original Message----- > > From: Jason Andryuk > > Sent: 24 June 2020 04:24 > > To: Paul Durrant > > Cc: Markus Armbruster ; Mark Cave-Ayland ; Anthony > > PERARD ; xen-devel ; QEMU > devel@nongnu.org> > > Subject: Re: sysbus failed assert for xen_sysdev > > > > On Tue, Jun 23, 2020 at 7:46 AM Paul Durrant wrote: > > > > > > > -----Original Message----- > > > > From: Markus Armbruster > > > > Sent: 23 June 2020 09:41 > > > > To: Jason Andryuk > > > > Cc: Mark Cave-Ayland ; Anthony PERARD ; > > xen- > > > > devel ; Paul Durrant ; QEMU > > > > Subject: Re: sysbus failed assert for xen_sysdev > > > > > > > > Jason Andryuk writes: > > > > > Then it gets farther... until > > > > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > > > > > Assertion `dev->realized' failed. > > > > > > > > > > dev->id is NULL. The failing device is: > > > > > (gdb) p *dev.parent_obj.class.type > > > > > $12 = {name = 0x555556207770 "cfi.pflash01", > > > > > > > > > > > Having commented out the call to xen_be_init() entirely (and xen_bus_init() for good measure) I also > > get this assertion failure, so > > > I don't think is related. > > > > Yes, this is something different. pc_pflash_create() calls > > qdev_new(TYPE_PFLASH_CFI01), but it is only realized in > > pc_system_flash_map()... and pc_system_flash_map() isn't called for > > Xen. > > > > Removing the call to pc_system_flash_create() from pc_machine_initfn() > > lets QEMU startup and run a Xen HVM again. xen_enabled() doesn't work > > there since accelerators have not been initialized yes, I guess? > > Looks like it can be worked round by the following: Yes, thank you. Tested-by: Jason Andryuk > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > index 1497d0e4ae..977d40afb8 100644 > --- a/hw/i386/pc_piix.c > +++ b/hw/i386/pc_piix.c > @@ -186,9 +186,12 @@ static void pc_init1(MachineState *machine, > if (!xen_enabled()) { > pc_memory_init(pcms, system_memory, > rom_memory, &ram_memory); > - } else if (machine->kernel_filename != NULL) { > - /* For xen HVM direct kernel boot, load linux here */ > - xen_load_linux(pcms); > + } else { > + pc_system_flash_cleanup_unused(pcms); > + if (machine->kernel_filename != NULL) { > + /* For xen HVM direct kernel boot, load linux here */ > + xen_load_linux(pcms); > + } > } > > gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled); > diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c > index ec2a3b3e7e..0ff47a4b59 100644 > --- a/hw/i386/pc_sysfw.c > +++ b/hw/i386/pc_sysfw.c > @@ -108,7 +108,7 @@ void pc_system_flash_create(PCMachineState *pcms) > } > } > > -static void pc_system_flash_cleanup_unused(PCMachineState *pcms) > +void pc_system_flash_cleanup_unused(PCMachineState *pcms) > { > char *prop_name; > int i; > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h > index e6135c34d6..497f2b7ab7 100644 > --- a/include/hw/i386/pc.h > +++ b/include/hw/i386/pc.h > @@ -187,6 +187,7 @@ int cmos_get_fd_drive_type(FloppyDriveType fd0); > > /* pc_sysfw.c */ > void pc_system_flash_create(PCMachineState *pcms); > +void pc_system_flash_cleanup_unused(PCMachineState *pcms); > void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory); > > /* acpi-build.c */ > > > > > > Regards, > > Jason > From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:15:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:15:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4Jj-0005pq-2M; Wed, 24 Jun 2020 12:15:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4Jh-0005pf-ID for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:15:49 +0000 X-Inumbo-ID: 700b292c-b614-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x42a.google.com (unknown [2a00:1450:4864:20::42a]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 700b292c-b614-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 12:15:48 +0000 (UTC) Received: by mail-wr1-x42a.google.com with SMTP id r12so2015635wrj.13 for ; Wed, 24 Jun 2020 05:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=BDCOUA8lXgFf9Ik42jo2Wjj2xjKI1F5MCW1BsXE9qF8=; b=Y4NFK/uTJO3jFMyfCqBeXeZdEHMdUdnP6eMVgdpGiLXrxeF+CJJVFSYEE9wpNrhhTK sF4U6ojnPDgHRPBc3OIZiGMHAZ0BGq+nB72tGpzHYrKOGg9q+P4D+vIxDkZ3c4ekyVAV bRxUc9h9RUYK/yuz+Rcz4+X6XwzQDSHWoVDFuIZ6BnFMSHWUuahsBAdP6xT2+ivQkuJo ToIC99UrONcQotGAwuW8JvlCGBOr88QnuXyTdaJYVQ+t7xMdh0Jk8SQDWBRaLKY+xz+9 IGlIZ4Aq4IPuAyGVCeWzxV1RbmAhwRPKF5eK/K6KlkZseNS4SO3FssOFtq3yeVr2qhrR mZ4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=BDCOUA8lXgFf9Ik42jo2Wjj2xjKI1F5MCW1BsXE9qF8=; b=j/U5yLg0IIy/dCgBEmgOh/rwXpFIre1F529+hLcQJnr0u/FjTyZz4YZfDo79o9Fz85 XA58Yge9Kf0kN3CatoX0akmvJVaK8hxM5r5DNgRxNOhjXiKVYdahyKP3oFioA8B2bbKg cI1hFuI6+2ICwDS01WpC5u2qbRrhXMa0m18OOXEahpVi7Pa+vQtm/Q6m3ljwg4EWF2Ns d9tLKGCcDyM/65YdIVwwADsf6RxO/+R8r3FOWImkwzwKQk4QzSHJLmE0wGQ75PFfMLkA ZZXvVqt1uV4YE8L1BXmiPAJD9oWlCEHZPEhMJL+jMbv22dgVA70/c9fy4NVcyg4+YeTf 2o1Q== X-Gm-Message-State: AOAM532HGGQKboGxpyQ+Tq5hAhzPamQZYz2nqB51h+2lxLVopVvSGQ8C lhn8VFMl/PmoYHo7vRr2LnM= X-Google-Smtp-Source: ABdhPJyQV/imfl+aT98W+0hyLyKXnzDmyRDkDGc+Dyi/80nZOQB/fGKpFEtu2vdTemIrvrzQO4jZlg== X-Received: by 2002:adf:f350:: with SMTP id e16mr28275829wrp.43.1593000947877; Wed, 24 Jun 2020 05:15:47 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id a2sm12468558wrn.68.2020.06.24.05.15.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 05:15:47 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jason Andryuk'" References: <87k0zykwdl.fsf@dusky.pond.sub.org> <000001d64953$f67a1f00$e36e5d00$@xen.org> <000801d64a12$5c7c11f0$157435d0$@xen.org> In-Reply-To: Subject: RE: sysbus failed assert for xen_sysdev Date: Wed, 24 Jun 2020 13:15:46 +0100 Message-ID: <000901d64a21$311a4630$934ed290$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIJfv1jP4fCJU6d0eNUL65zTb1lhAKJjZPCAZLY/IEByWeHdwFU8pWtAkUeRcMCDTlHOQHM4CJrqBZ0jpA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Anthony PERARD' , 'xen-devel' , 'Mark Cave-Ayland' , 'Markus Armbruster' , 'QEMU' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jason Andryuk > Sent: 24 June 2020 13:15 > To: Paul Durrant > Cc: Markus Armbruster ; Mark Cave-Ayland ; Anthony > PERARD ; xen-devel ; QEMU devel@nongnu.org> > Subject: Re: sysbus failed assert for xen_sysdev > > On Wed, Jun 24, 2020 at 6:29 AM Paul Durrant wrote: > > > > > -----Original Message----- > > > From: Jason Andryuk > > > Sent: 24 June 2020 04:24 > > > To: Paul Durrant > > > Cc: Markus Armbruster ; Mark Cave-Ayland ; > Anthony > > > PERARD ; xen-devel ; QEMU > > devel@nongnu.org> > > > Subject: Re: sysbus failed assert for xen_sysdev > > > > > > On Tue, Jun 23, 2020 at 7:46 AM Paul Durrant wrote: > > > > > > > > > -----Original Message----- > > > > > From: Markus Armbruster > > > > > Sent: 23 June 2020 09:41 > > > > > To: Jason Andryuk > > > > > Cc: Mark Cave-Ayland ; Anthony PERARD > ; > > > xen- > > > > > devel ; Paul Durrant ; QEMU devel@nongnu.org> > > > > > Subject: Re: sysbus failed assert for xen_sysdev > > > > > > > > > > Jason Andryuk writes: > > > > > > Then it gets farther... until > > > > > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > > > > > > Assertion `dev->realized' failed. > > > > > > > > > > > > dev->id is NULL. The failing device is: > > > > > > (gdb) p *dev.parent_obj.class.type > > > > > > $12 = {name = 0x555556207770 "cfi.pflash01", > > > > > > > > > > > > > > Having commented out the call to xen_be_init() entirely (and xen_bus_init() for good measure) I > also > > > get this assertion failure, so > > > > I don't think is related. > > > > > > Yes, this is something different. pc_pflash_create() calls > > > qdev_new(TYPE_PFLASH_CFI01), but it is only realized in > > > pc_system_flash_map()... and pc_system_flash_map() isn't called for > > > Xen. > > > > > > Removing the call to pc_system_flash_create() from pc_machine_initfn() > > > lets QEMU startup and run a Xen HVM again. xen_enabled() doesn't work > > > there since accelerators have not been initialized yes, I guess? > > > > Looks like it can be worked round by the following: > > Yes, thank you. > > Tested-by: Jason Andryuk Thanks. Paul > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > > index 1497d0e4ae..977d40afb8 100644 > > --- a/hw/i386/pc_piix.c > > +++ b/hw/i386/pc_piix.c > > @@ -186,9 +186,12 @@ static void pc_init1(MachineState *machine, > > if (!xen_enabled()) { > > pc_memory_init(pcms, system_memory, > > rom_memory, &ram_memory); > > - } else if (machine->kernel_filename != NULL) { > > - /* For xen HVM direct kernel boot, load linux here */ > > - xen_load_linux(pcms); > > + } else { > > + pc_system_flash_cleanup_unused(pcms); > > + if (machine->kernel_filename != NULL) { > > + /* For xen HVM direct kernel boot, load linux here */ > > + xen_load_linux(pcms); > > + } > > } > > > > gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled); > > diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c > > index ec2a3b3e7e..0ff47a4b59 100644 > > --- a/hw/i386/pc_sysfw.c > > +++ b/hw/i386/pc_sysfw.c > > @@ -108,7 +108,7 @@ void pc_system_flash_create(PCMachineState *pcms) > > } > > } > > > > -static void pc_system_flash_cleanup_unused(PCMachineState *pcms) > > +void pc_system_flash_cleanup_unused(PCMachineState *pcms) > > { > > char *prop_name; > > int i; > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h > > index e6135c34d6..497f2b7ab7 100644 > > --- a/include/hw/i386/pc.h > > +++ b/include/hw/i386/pc.h > > @@ -187,6 +187,7 @@ int cmos_get_fd_drive_type(FloppyDriveType fd0); > > > > /* pc_sysfw.c */ > > void pc_system_flash_create(PCMachineState *pcms); > > +void pc_system_flash_cleanup_unused(PCMachineState *pcms); > > void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory); > > > > /* acpi-build.c */ > > > > > > > > > > Regards, > > > Jason > > From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:18:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:18:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4MY-00066w-GO; Wed, 24 Jun 2020 12:18:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4MW-00066p-VV for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:18:45 +0000 X-Inumbo-ID: d90c4848-b614-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d90c4848-b614-11ea-b7bb-bc764e2007e4; Wed, 24 Jun 2020 12:18:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date: Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zRTBeYXTSwlmZB/k4eGzkfc2asK1YgI6BdQ2WNKm/8A=; b=QSZD9KM0BvHwUs7/kFXiG4Dxyx ncWAyDnn0bX1HmOIvII3iyDAzHfGs3sqfJAAo/KPNTiOUvdk93iZFskhETuXDupiHhfvS6gln1AxH PJA+r+ldLXPnb8G8n2G5FSf5P/AA/+N30yxTtDaWitT1Yb6vTM3/8xdzcn0yXTJ0VBVs=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4MW-0000g8-5m; Wed, 24 Jun 2020 12:18:44 +0000 Received: from 54-240-197-224.amazon.com ([54.240.197.224] helo=u2f063a87eabd5f.cbg10.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jo4MV-0005fi-Sx; Wed, 24 Jun 2020 12:18:44 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org, qemu-devel@nongnu.org Subject: [PATCH 0/2] fix assertion failures when using Xen Date: Wed, 24 Jun 2020 13:18:39 +0100 Message-Id: <20200624121841.17971-1-paul@xen.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Paul Durrant Paul Durrant (2): xen: fix legacy 'xen-sysdev' and 'xen-backend' bus types xen: cleanup unrealized flash devices hw/i386/pc_piix.c | 9 ++++++--- hw/i386/pc_sysfw.c | 2 +- hw/xen/xen-legacy-backend.c | 4 ++-- include/hw/i386/pc.h | 1 + 4 files changed, 10 insertions(+), 6 deletions(-) -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:18:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:18:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4Mb-00067y-SG; Wed, 24 Jun 2020 12:18:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4MZ-00067X-VR for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:18:48 +0000 X-Inumbo-ID: d9cd1730-b614-11ea-80a5-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d9cd1730-b614-11ea-80a5-12813bfff9fa; Wed, 24 Jun 2020 12:18:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References: In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=N/I4v8ZDmbVyJ5v5uM4VjOF7rLFaxzrV35vC/IJzksA=; b=lLt2C+uuKQnj7hdrvVOUwqTmOc 6mvivoKpj2mcC21dDbNQfw4TWLRKSULpTUGgzd25DC8kwHlqRizrzV3HUR9DbL5N4J3sjdFzS7+Rl cRCyHUZbwb3LjveMQRyODxZQ2B1ueU6ynTq2P9rKxbofMWbp9V8guYfzhYMH+HyZu39s=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4MX-0000gD-A9; Wed, 24 Jun 2020 12:18:45 +0000 Received: from 54-240-197-224.amazon.com ([54.240.197.224] helo=u2f063a87eabd5f.cbg10.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jo4MX-0005fi-17; Wed, 24 Jun 2020 12:18:45 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org, qemu-devel@nongnu.org Subject: [PATCH 1/2] xen: fix legacy 'xen-sysdev' and 'xen-backend' bus types Date: Wed, 24 Jun 2020 13:18:40 +0100 Message-Id: <20200624121841.17971-2-paul@xen.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200624121841.17971-1-paul@xen.org> References: <20200624121841.17971-1-paul@xen.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , Paul Durrant , Stefano Stabellini , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Paul Durrant 'xen-sysdev' plugs into the 'System' bus type, not 'xen-sysbus. That bus type is what 'xen-backend' plugs into. 'xen-sysdev' is drived form 'sys-bus-device' so the bus type need not be overridden. 'xen-backend' is derived from 'device', which plugs into the generic 'bus' type, so its bus type should be overridden to 'xen-sysbus'. Without this patch, the following assertion will fail: qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' failed. Reported-by: Jason Andryuk Fixes: 81cb05732efb ("qdev: Assert devices are plugged into a bus that can take them") Signed-off-by: Paul Durrant --- Cc: Stefano Stabellini Cc: Anthony Perard --- hw/xen/xen-legacy-backend.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c index 2335ee2e65..c5c75c0064 100644 --- a/hw/xen/xen-legacy-backend.c +++ b/hw/xen/xen-legacy-backend.c @@ -789,11 +789,12 @@ static void xendev_class_init(ObjectClass *klass, void *data) set_bit(DEVICE_CATEGORY_MISC, dc->categories); /* xen-backend devices can be plugged/unplugged dynamically */ dc->user_creatable = true; + dc->bus_type = TYPE_XENSYSBUS; } static const TypeInfo xendev_type_info = { .name = TYPE_XENBACKEND, - .parent = TYPE_XENSYSDEV, + .parent = TYPE_DEVICE, .class_init = xendev_class_init, .instance_size = sizeof(struct XenLegacyDevice), }; @@ -824,7 +825,6 @@ static void xen_sysdev_class_init(ObjectClass *klass, void *data) DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_props(dc, xen_sysdev_properties); - dc->bus_type = TYPE_XENSYSBUS; } static const TypeInfo xensysdev_info = { -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:18:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:18:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4Mg-00069Z-4H; Wed, 24 Jun 2020 12:18:54 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4Me-00067X-Tn for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:18:52 +0000 X-Inumbo-ID: dab1d4f6-b614-11ea-80a5-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dab1d4f6-b614-11ea-80a5-12813bfff9fa; Wed, 24 Jun 2020 12:18:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:MIME-Version:References: In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WmkzEFnsGIT7sjSL+1trW0fIwoGyCpkoOnXxvyuh+2I=; b=IMWSEnAp8h0F/2AJelrjK/lD5Y XytjbgEbImgRnLyGQ1m8zFKYjRqaaP1EodKbhHxbGcHS3a6n26wzRt057a6vY5aGHuLNVPhaWrr58 DzqCQmQuICWD58fsq5dry+Lf4PBdal4NM1X+u+cyrn22+nVRmKBWVY0Ggj1hrWaINn34=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4MY-0000gH-PN; Wed, 24 Jun 2020 12:18:46 +0000 Received: from 54-240-197-224.amazon.com ([54.240.197.224] helo=u2f063a87eabd5f.cbg10.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jo4MY-0005fi-Gg; Wed, 24 Jun 2020 12:18:46 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org, qemu-devel@nongnu.org Subject: [PATCH 2/2] xen: cleanup unrealized flash devices Date: Wed, 24 Jun 2020 13:18:41 +0100 Message-Id: <20200624121841.17971-3-paul@xen.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200624121841.17971-1-paul@xen.org> References: <20200624121841.17971-1-paul@xen.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Eduardo Habkost , "Michael S. Tsirkin" , Paul Durrant , Jason Andryuk , Marcel Apfelbaum , Paolo Bonzini , Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Paul Durrant The generic pc_machine_initfn() calls pc_system_flash_create() which creates 'system.flash0' and 'system.flash1' devices. These devices are then realized by pc_system_flash_map() which is called from pc_system_firmware_init() which itself is called via pc_memory_init(). The latter however is not called when xen_enable() is true and hence the following assertion fails: qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: Assertion `dev->realized' failed These flash devices are unneeded when using Xen so this patch avoids the assertion by simply removing them using pc_system_flash_cleanup_unused(). Reported-by: Jason Andryuk Fixes: ebc29e1beab0 ("pc: Support firmware configuration with -blockdev") Signed-off-by: Paul Durrant Tested-by: Jason Andryuk --- Cc: Paolo Bonzini Cc: Richard Henderson Cc: Eduardo Habkost Cc: "Michael S. Tsirkin" Cc: Marcel Apfelbaum --- hw/i386/pc_piix.c | 9 ++++++--- hw/i386/pc_sysfw.c | 2 +- include/hw/i386/pc.h | 1 + 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 1497d0e4ae..977d40afb8 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -186,9 +186,12 @@ static void pc_init1(MachineState *machine, if (!xen_enabled()) { pc_memory_init(pcms, system_memory, rom_memory, &ram_memory); - } else if (machine->kernel_filename != NULL) { - /* For xen HVM direct kernel boot, load linux here */ - xen_load_linux(pcms); + } else { + pc_system_flash_cleanup_unused(pcms); + if (machine->kernel_filename != NULL) { + /* For xen HVM direct kernel boot, load linux here */ + xen_load_linux(pcms); + } } gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled); diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c index ec2a3b3e7e..0ff47a4b59 100644 --- a/hw/i386/pc_sysfw.c +++ b/hw/i386/pc_sysfw.c @@ -108,7 +108,7 @@ void pc_system_flash_create(PCMachineState *pcms) } } -static void pc_system_flash_cleanup_unused(PCMachineState *pcms) +void pc_system_flash_cleanup_unused(PCMachineState *pcms) { char *prop_name; int i; diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h index e6135c34d6..497f2b7ab7 100644 --- a/include/hw/i386/pc.h +++ b/include/hw/i386/pc.h @@ -187,6 +187,7 @@ int cmos_get_fd_drive_type(FloppyDriveType fd0); /* pc_sysfw.c */ void pc_system_flash_create(PCMachineState *pcms); +void pc_system_flash_cleanup_unused(PCMachineState *pcms); void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory); /* acpi-build.c */ -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:19:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:19:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4Nf-0006L9-FP; Wed, 24 Jun 2020 12:19:55 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4Ne-0006Kw-66 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:19:54 +0000 X-Inumbo-ID: 0241d7f0-b615-11ea-bb8b-bc764e2007e4 Received: from mail-qk1-x742.google.com (unknown [2607:f8b0:4864:20::742]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0241d7f0-b615-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 12:19:53 +0000 (UTC) Received: by mail-qk1-x742.google.com with SMTP id e13so1553270qkg.5 for ; Wed, 24 Jun 2020 05:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=JeHrzBkl0W7YnFDNGzpK6Omqdh1SbNjh/JeqkFtYTYM=; b=bHiigOlfRJSOsDQUtI5OujwKxFy5ZwqLJpXGvaYBK5AXFjeFbyHjglZbPkR19/LD7K h8CxXew/iIM3amWTrmT8GzthWz80A4LojXAoLSAoYRfa/o4CTcMsaQ2MqCrcMmFyhmh3 d65C6+bnnMFHZZUPCaKXHD8xuou/AYrpxpUHIZa4MUJAlOttRnvcUjqEMH2Azqysu6bY TrHvRBr4AOZ6qj8jPD4cTiibdikz02cW95d1+1iV6+6F0gl4CxgTZ/isKtni95qDKvs8 hvmgb3+i7qzDkgRzLqAXFCJLilOQw7Y8u8kX0+9KDGdInvcMVCtQ7P0FjE9jy1kZkcpR aIkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=JeHrzBkl0W7YnFDNGzpK6Omqdh1SbNjh/JeqkFtYTYM=; b=fgpICnP8xTOr1XZCaKdV/QS+oFyGY1SWC0DOiTO3xtgA7I28WvY1I8AVf0BZJV10lT 76XyrYNAcHejClKF+NPaW4ha/STYPuq9G61MfrM4cpH/7V0V7+XHHMKSiV8AeUTiVDCv YmNNgsnWrJHTJRGrEb+ZgrLcO2EgQwdwC2539Kx4jAD3V86ABYjDATZh3IxpwRXUcBiT /6M4Qtp/x/jOfk+abGjqxHbOrR8LsXMeY75K3r+kCACCu4kN88k33GyvrIKU+MOCNQad YHsyU93fJDFzJymMksAODq+CaVNFK6of00Su6PSfLMbh3g0AZ/6n3yfm0yn5G+LAe8ok BnYQ== X-Gm-Message-State: AOAM530U5V+xI/nmM5lwSWCHRKjyNAsM//MUp3+AGFwQjoGOdPIwBPs3 Dj5rvx444QNaxZXWEzSoa0o= X-Google-Smtp-Source: ABdhPJx3ZT4gYwkDD4T3fNbH4/7YMHFKibhaBWBHBCSo0bX+lInlvhxyUp1HwIUySWDeId8zj6gV/Q== X-Received: by 2002:a37:451:: with SMTP id 78mr16239725qke.117.1593001193342; Wed, 24 Jun 2020 05:19:53 -0700 (PDT) Received: from shine.lan ([2001:470:8:67e:ad7b:336a:2d40:4130]) by smtp.gmail.com with ESMTPSA id x4sm3685635qtj.50.2020.06.24.05.19.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 05:19:52 -0700 (PDT) From: Jason Andryuk To: Stefano Stabellini , Anthony Perard , Paul Durrant , xen-devel@lists.xenproject.org Subject: [PATCH] xen: Fix xen-legacy-backend qdev types Date: Wed, 24 Jun 2020 08:19:39 -0400 Message-Id: <20200624121939.10282-1-jandryuk@gmail.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: qemu-devel@nongnu.org, Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" xen-sysdev is a TYPE_SYS_BUS_DEVICE. bus_type should not be changed so that it can plug into the System bus. Otherwise this assert triggers: qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' failed. TYPE_XENBACKEND attaches to TYPE_XENSYSBUS, so its class_init needs to be set accordingly to attach the qdev. Otherwise the following assert triggers: qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' failed. TYPE_XENBACKEND is not a subclass of XEN_XENSYSDEV, so it's parent is just TYPE_DEVICE. Change that. Signed-off-by: Jason Andryuk --- hw/xen/xen-legacy-backend.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c index 2335ee2e65..c5c75c0064 100644 --- a/hw/xen/xen-legacy-backend.c +++ b/hw/xen/xen-legacy-backend.c @@ -789,11 +789,12 @@ static void xendev_class_init(ObjectClass *klass, void *data) set_bit(DEVICE_CATEGORY_MISC, dc->categories); /* xen-backend devices can be plugged/unplugged dynamically */ dc->user_creatable = true; + dc->bus_type = TYPE_XENSYSBUS; } static const TypeInfo xendev_type_info = { .name = TYPE_XENBACKEND, - .parent = TYPE_XENSYSDEV, + .parent = TYPE_DEVICE, .class_init = xendev_class_init, .instance_size = sizeof(struct XenLegacyDevice), }; @@ -824,7 +825,6 @@ static void xen_sysdev_class_init(ObjectClass *klass, void *data) DeviceClass *dc = DEVICE_CLASS(klass); device_class_set_props(dc, xen_sysdev_properties); - dc->bus_type = TYPE_XENSYSBUS; } static const TypeInfo xensysdev_info = { -- 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:24:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:24:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4SH-0007Cw-1k; Wed, 24 Jun 2020 12:24:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4SF-0007Cr-Uj for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:24:39 +0000 X-Inumbo-ID: abca6a3a-b615-11ea-80a9-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id abca6a3a-b615-11ea-80a9-12813bfff9fa; Wed, 24 Jun 2020 12:24:38 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id A3DD9A2520; Wed, 24 Jun 2020 14:24:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 8C5FFA213C; Wed, 24 Jun 2020 14:24:36 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id w_BX55rURejH; Wed, 24 Jun 2020 14:24:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id CD808A2520; Wed, 24 Jun 2020 14:24:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YMxNNB2yH312; Wed, 24 Jun 2020 14:24:35 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9D42FA213C; Wed, 24 Jun 2020 14:24:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 838F021A16; Wed, 24 Jun 2020 14:24:05 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id IBS4fOvqu9RR; Wed, 24 Jun 2020 14:24:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 12813201EB; Wed, 24 Jun 2020 14:24:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DBzudGtVUnH9; Wed, 24 Jun 2020 14:23:59 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id E5782200F2; Wed, 24 Jun 2020 14:23:59 +0200 (CEST) Date: Wed, 24 Jun 2020 14:23:59 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Andrew Cooper Message-ID: <1353594139.12442277.1593001439838.JavaMail.zimbra@cert.pl> In-Reply-To: References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> <901046162.11470361.1592874264410.JavaMail.zimbra@cert.pl> <32b7234b-dc64-a0ea-2c5c-448bcec44c34@suse.com> Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: o6iyDlCcFKtukIq7gCjwJRc2Z2TpEA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Xen-devel , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 23 cze 2020 o 19:24, Andrew Cooper andrew.cooper3@citrix.com napisa= =C5=82(a): > On 23/06/2020 09:51, Jan Beulich wrote: >> I'd still like to see an explicit confirmation by him that this >> use of memory is indeed what he has intended. There are much smaller >> amounts of memory which we allocate on demand, just to avoid >> allocating some without then ever using it. >=20 > PT is a debug/diagnostic tool.=C2=A0 Its not something you'd run in > production against a production VM. >=20 > It's off by default (by virtue of having to explicitly ask to use it in > the first place), and those who've asked for it don't want to be finding > -ENOMEM after the domain has been running for a few seconds (or midway > through the vcpus), when they inveterately want to map the rings. >=20 > Those who request buffers in the first place and forget about them are > not semantically different from those who ask for a silly shadow memory > limit, or typo the guest memory and give it too much.=C2=A0 Its a admin > error, not a safety/correctness issue. >=20 > ~Andrew Absolutely +1. Assuming that somebody wants to perform some advanced scenario and is tryin= g to run many domains (e.g. 20), it's much better to have 19 domains working fine and 1 prematurely crashing because of -ENOMEM, rather than have all 20 domains randomly crashing in runtime because it turned out there is a shortage of memory. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:30:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:30:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4YG-00087H-Ot; Wed, 24 Jun 2020 12:30:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4YE-00087C-RY for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:30:50 +0000 X-Inumbo-ID: 893f9d40-b616-11ea-8496-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 893f9d40-b616-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 12:30:50 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id l10so2089852wrr.10 for ; Wed, 24 Jun 2020 05:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=d+a2gUl07F0ZUgzubj1rIDmfWgWm8vAiCo/wzafStfg=; b=uqHXuvYP10Vfc0poUxXhoAxEgjcIOEKhkTloMAvbcLBCZNNqTkYtQMPApfgO18u3cB /CjHFcGhlH+WNzJ3gTBlXdS3cPgBlS5znOzL0sFYoI1hpB+nruuUTli5CY1+Wqj9cE4l dGsUywTZtDFutOSW/aUsKBBfda+WAVvTuGjwoQCthysU8PAMstXG20v6Qi7Y758jkNzY SkK1ylLYAY2UZbAgwnodHtBMDNBrVObeYksrROuZ5N1k10QiQs45SMGqb6YUsWIWszUh 0KgEZlsC4evnsw7QLCNOUs2i7fLJZIjQ0Kpa33u8xYDgfk0M5g+ye5AzynukYUjfcEW6 Bkfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=d+a2gUl07F0ZUgzubj1rIDmfWgWm8vAiCo/wzafStfg=; b=JfKRKMobiE7ztC9Uz6yUw2yLMk80HpzdqyNxihfLoWiBWmtox+HKQoTYDt02WiGXny 7mpjPJfL9uQu+jPkIq2vQ32QkShUU3zTX9KcIrFCOGhRidgBDTCmgP65s2es0S63wEwm zRcg4ysthFonwZL9v0ZUhjQwDS19taIdOsgBm/xeDDjfNNx/KO3aXI/kIDvEf+F4gn2c 1ChzZtswPqvlViFv1UCHpRlgfKDTVeVbGZ3aLe1v7/NYjQw9i5FUw4vRmMS61YyS6S9+ 9SQsg340gDd2e/sRerALjVfYXk4x9l6bD5zq8pxM9zDAiaynsqLcIdzd8Rs91nc24PDW VGEQ== X-Gm-Message-State: AOAM532neGwUACAWWkZNRFZ40Pjnd2VMgxXMdxsaWfkTUiYJ4Z1z/HgA 6GB7jnBAQN1lc4hkwou++IQ= X-Google-Smtp-Source: ABdhPJwdWkiuvxZQhBc8cWxD+knonuDTYnM/NcsBtM505tCqOyS8b6fo/jwqWpAgEy4bxAdZstRHzA== X-Received: by 2002:adf:e6cb:: with SMTP id y11mr25769251wrm.282.1593001849266; Wed, 24 Jun 2020 05:30:49 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id f14sm9612823wro.90.2020.06.24.05.30.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 05:30:48 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jason Andryuk'" , "'Stefano Stabellini'" , "'Anthony Perard'" , References: <20200624121939.10282-1-jandryuk@gmail.com> In-Reply-To: <20200624121939.10282-1-jandryuk@gmail.com> Subject: RE: [PATCH] xen: Fix xen-legacy-backend qdev types Date: Wed, 24 Jun 2020 13:30:47 +0100 Message-ID: <000a01d64a23$4a595e90$df0c1bb0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJVIeVpfNhOuJ/7wV1uDlt3SOiQn6fqAo/Q X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: qemu-devel@nongnu.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jason Andryuk > Sent: 24 June 2020 13:20 > To: Stefano Stabellini ; Anthony Perard ; Paul > Durrant ; xen-devel@lists.xenproject.org > Cc: Jason Andryuk ; qemu-devel@nongnu.org > Subject: [PATCH] xen: Fix xen-legacy-backend qdev types > > xen-sysdev is a TYPE_SYS_BUS_DEVICE. bus_type should not be changed so > that it can plug into the System bus. Otherwise this assert triggers: > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > failed. > > TYPE_XENBACKEND attaches to TYPE_XENSYSBUS, so its class_init needs to > be set accordingly to attach the qdev. Otherwise the following assert > triggers: > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > failed. > > TYPE_XENBACKEND is not a subclass of XEN_XENSYSDEV, so it's parent > is just TYPE_DEVICE. Change that. > > Signed-off-by: Jason Andryuk Clearly we raced. This patch and my patch #1 are identical so I'm happy to give my ack to this. Paul > --- > hw/xen/xen-legacy-backend.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c > index 2335ee2e65..c5c75c0064 100644 > --- a/hw/xen/xen-legacy-backend.c > +++ b/hw/xen/xen-legacy-backend.c > @@ -789,11 +789,12 @@ static void xendev_class_init(ObjectClass *klass, void *data) > set_bit(DEVICE_CATEGORY_MISC, dc->categories); > /* xen-backend devices can be plugged/unplugged dynamically */ > dc->user_creatable = true; > + dc->bus_type = TYPE_XENSYSBUS; > } > > static const TypeInfo xendev_type_info = { > .name = TYPE_XENBACKEND, > - .parent = TYPE_XENSYSDEV, > + .parent = TYPE_DEVICE, > .class_init = xendev_class_init, > .instance_size = sizeof(struct XenLegacyDevice), > }; > @@ -824,7 +825,6 @@ static void xen_sysdev_class_init(ObjectClass *klass, void *data) > DeviceClass *dc = DEVICE_CLASS(klass); > > device_class_set_props(dc, xen_sysdev_properties); > - dc->bus_type = TYPE_XENSYSBUS; > } > > static const TypeInfo xensysdev_info = { > -- > 2.25.1 From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:41:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:41:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4i2-0000eM-Nb; Wed, 24 Jun 2020 12:40:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4i1-0000eH-Nq for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:40:57 +0000 X-Inumbo-ID: f2a95fb8-b617-11ea-bca7-bc764e2007e4 Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f2a95fb8-b617-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 12:40:56 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ki1RHALmCId7WRLkWqIL9/44I5p6KozHqU9xMPCbzGj4A3pKi+tkPxyPm5hBtNap71jkUAT8S/ jXUw8AOLUAhf1ElAb89qDH8+OsQOKa0mAZyeF+qBt1MUUs+WFT/amTA/nFuB9TJlgMb7DRP1mK +OdsHNRuxWWk/4eFIjsDazyoZUjRi1qVnHHovzJvDsWQDrEc1zKGWKXFd86i68EWIMEyNZeXUT hDnXY5zNbG/N2STU7rDJP5vNYvFJgqEEuoJswdI4V7EOi8tMCaEHBOGG/tR9PdTDhD8Fvc8q3q 9e4= X-SBRS: 2.7 X-MesageID: 21036602 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,275,1589256000"; d="scan'208";a="21036602" Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: Jan Beulich References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> <901046162.11470361.1592874264410.JavaMail.zimbra@cert.pl> <32b7234b-dc64-a0ea-2c5c-448bcec44c34@suse.com> From: Andrew Cooper Message-ID: Date: Wed, 24 Jun 2020 13:40:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Wei Liu , Tamas K Lengyel , =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Ian Jackson , George Dunlap , "Kang, Luwei" , Jun Nakajima , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 24/06/2020 11:03, Jan Beulich wrote: > On 23.06.2020 19:24, Andrew Cooper wrote: >> On 23/06/2020 09:51, Jan Beulich wrote: >>> On 23.06.2020 03:04, Michał Leszczyński wrote: >>>> ----- 22 cze 2020 o 18:16, Jan Beulich jbeulich@suse.com napisał(a): >>>> >>>>> On 22.06.2020 18:02, Michał Leszczyński wrote: >>>>>> ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisał(a): >>>>>>> On 22.06.2020 16:35, Michał Leszczyński wrote: >>>>>>>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisał(a): >>>>>>>>> Is any of what you do in this switch() actually legitimate without >>>>>>>>> hvm_set_vmtrace_pt_size() having got called for the guest? From >>>>>>>>> remarks elsewhere I imply you expect the param that you currently >>>>>>>>> use to be set upon domain creation time, but at the very least the >>>>>>>>> potentially big buffer should imo not get allocated up front, but >>>>>>>>> only when tracing is to actually be enabled. >>>>>>>> Wait... so you want to allocate these buffers in runtime? >>>>>>>> Previously we were talking that there is too much runtime logic >>>>>>>> and these enable/disable hypercalls should be stripped to absolute >>>>>>>> minimum. >>>>>>> Basic arrangements can be made at domain creation time. I don't >>>>>>> think though that it would be a good use of memory if you >>>>>>> allocated perhaps many gigabytes of memory just for possibly >>>>>>> wanting to enable tracing on a guest. >>>>>>> >>>>>> From our previous conversations I thought that you want to have >>>>>> as much logic moved to the domain creation as possible. >>>>>> >>>>>> Thus, a parameter "vmtrace_pt_size" was introduced. By default it's >>>>>> zero (= disabled), if you set it to a non-zero value, then trace buffers >>>>>> of given size will be allocated for the domain and you have possibility >>>>>> to use ipt_enable/ipt_disable at any moment. >>>>>> >>>>>> This way the runtime logic is as thin as possible. I assume user knows >>>>>> in advance whether he/she would want to use external monitoring with IPT >>>>>> or not. >>>>> Andrew - I think you requested movement to domain_create(). Could >>>>> you clarify if indeed you mean to also allocate the big buffers >>>>> this early? >>>> I would like to recall what Andrew wrote few days ago: >>>> >>>> ----- 16 cze 2020 o 22:16, Andrew Cooper andrew.cooper3@citrix.com wrote: >>>>> Xen has traditionally opted for a "and turn this extra thing on >>>>> dynamically" model, but this has caused no end of security issues and >>>>> broken corner cases. >>>>> >>>>> You can see this still existing in the difference between >>>>> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being >>>>> required to chose the number of vcpus for the domain) and we're making >>>>> good progress undoing this particular wart (before 4.13, it was >>>>> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by >>>>> issuing other hypercalls between these two). >>>>> >>>>> There is a lot of settings which should be immutable for the lifetime of >>>>> the domain, and external monitoring looks like another one of these. >>>>> Specifying it at createdomain time allows for far better runtime >>>>> behaviour (you are no longer in a situation where the first time you try >>>>> to turn tracing on, you end up with -ENOMEM because another VM booted in >>>>> the meantime and used the remaining memory), and it makes for rather >>>>> more simple code in Xen itself (at runtime, you can rely on it having >>>>> been set up properly, because a failure setting up will have killed the >>>>> domain already). >>>>> >>>>> ... >>>>> >>>>> ~Andrew >>>> according to this quote I've moved buffer allocation to the create_domain, >>>> the updated version was already sent to the list as patch v3. >>> I'd still like to see an explicit confirmation by him that this >>> use of memory is indeed what he has intended. There are much smaller >>> amounts of memory which we allocate on demand, just to avoid >>> allocating some without then ever using it. >> PT is a debug/diagnostic tool.  Its not something you'd run in >> production against a production VM. > Well, the suggested use with introspection made me assume differently. > If this is (now and forever) truly debug/diag only, so be it then. At the end of the day, it is a fine grain profiling tool, meaning that it is not used in the common case. The usecase presented is for fuzzing, using the execution trace generated by the CPU, rather than the current scheme which allegedly involves shuffling breakpoints around. There is a big disclaimer with PT saying "there is a perf hit from using this".  This is a consequence of the core suddenly becoming far more memory bound, and almost certainly being capable of generating trace data faster than can be written out. Even if it does find its way into some fairly custom production scenarios (fuzzing as a service?), we're still in the position where the only people who enable this will be the people intending to use it. ~Andrew From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:42:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:42:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4jO-0000kh-6Y; Wed, 24 Jun 2020 12:42:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4jN-0000kb-DE for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:42:21 +0000 X-Inumbo-ID: 24ce32ca-b618-11ea-80af-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 24ce32ca-b618-11ea-80af-12813bfff9fa; Wed, 24 Jun 2020 12:42:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=tpA2qE2c73mDj0Mv3lwin1XOqfoBY5NwoKN1J8X2oSQ=; b=kKhNOCDo4gYuFUh4ZMY0muRuNv 5lRceRbowRS/Gl1lTc5Ova0ZW98rlKLHwznBsOdLJV2R24CN5gBMbJx/BMBTZ1hf8Qpr0j8kLMmp5 hQQjshf4ObpyzfAdVT/TkZm1dFDBdNTar+E+mY1UslNvqLNQfX0X0hREDsFT6H+TKOew=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4jK-00017x-Rd; Wed, 24 Jun 2020 12:42:18 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jo4jK-0006rH-K6; Wed, 24 Jun 2020 12:42:18 +0000 Subject: Re: ARM - Successful install on RockPro64 To: Richard Simpson , Bertrand Marquis References: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> <8013f2db-3732-0679-81f6-7b274b39c44f@xen.org> <49e5b539-145a-726a-fb80-a93e65e44ca0@huskydog.org.uk> From: Julien Grall Message-ID: Date: Wed, 24 Jun 2020 13:42:16 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <49e5b539-145a-726a-fb80-a93e65e44ca0@huskydog.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini , "ian.jackson@eu.citrix.com" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 17/06/2020 23:28, Richard Simpson wrote: > Hello Julien, Hello Richard, Apologies for the late answer. > I have just tried 4.14-rc2 and it seems to work fine. Glad to hear that. Thank you for the testing! > I think that the most useful page regarding the board is the one for the > Ibox3399 since this refers to the RK3399 chip which the RockPro64 uses > (shouldn't the page actually be called RK3399 to make it more generic). I agree with the renaming here. > Perhaps I can most usefully record what I did by updating that page and > making sure that the instructions work correctly. If there is additional > stuff relevant to the RockPro64 over and above the generic RK3399 info > then I'll give some thought to how to best record it.  I will eventually > be writing a fuller report on my progress on my blog at > funfoodfreedom.huskydog.org.uk. Any additional content on the wiki will be greatly appreciated. By default new wiki account doesn't have write permission, but we can enable it for you if you provide us your username. > > I now need to finish automating the boot process (still requires manual > u-boot command) and figure out how to get the console log to work. I wrote a small u-boot script in the past to try to automate the boot (see [2]). I vaguely remember some quoting issue and missing 0x in front of values depending on the U-boot configuration you use. So you may have to tweak it a bit. > Currently I can either see the xen and linux kernel boot messages OR see > the dom0 console, but not both. Can you provide the kernel/xen command lines you use in the two cases? As an aside, I know that on some setup Linux will try to disable the clock of the UART used by Xen. One of the symptoms is the UART is becoming completely unusable half way through Linux boot. You may want to try to pass clk_ignored_unused to see if it helps. > On one more related note:  I suspect that Xen would run on the > PineBookPro as well as I get the impression that it uses very similar > hardware.  Of course that would rely on the GPU etc which I haven't > tested at all as I am using the serial console. I wouldn't expect any issue to use the GPU in dom0 at least if you don't have an IOMMU on the platform. The trouble may be more with the bootloader if it doesn't drop you in hypervisor mode. > > Finally, when I joined this mailing list I asked for a daily digest. > However I seem to be getting a new digest every hour or so.  Is this right? I haven't used the digest myself. I CC Ian Jackson who may be able to help you. Cheers, [2] https://xenbits.xen.org/people/julieng/load-xen-tftp.scr.txt -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:44:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:44:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4lF-0000t8-Ix; Wed, 24 Jun 2020 12:44:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4lD-0000t0-UA for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:44:15 +0000 X-Inumbo-ID: 65c7ce80-b618-11ea-80af-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 65c7ce80-b618-11ea-80af-12813bfff9fa; Wed, 24 Jun 2020 12:44:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HgpuRr6zKH6ncD+tn1O70CQt6nCwoQMeuv92rhTNREo=; b=2jnqv760Oeo43NpFM+aqoWGlc NbV9r4cKtCq1kZhFqiS1c2S6tcevSAPvrni94jb8qgfLxBpXUcYObOBknpwmZQcE60uTBuG18jThI Zd/h3rq8useDB4VeozRQQN0rETNcPZYJChZn+EXxS/03ONURduA/wX2qYptUaT2jItmZM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4l6-0001A6-RU; Wed, 24 Jun 2020 12:44:08 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jo4l6-0006YR-FQ; Wed, 24 Jun 2020 12:44:08 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jo4l6-00061e-Ej; Wed, 24 Jun 2020 12:44:08 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151311: tolerable FAIL X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=fde76f895d0aa817a1207d844d793239c6639bc6 X-Osstest-Versions-That: xen=fde76f895d0aa817a1207d844d793239c6639bc6 From: osstest service owner Date: Wed, 24 Jun 2020 12:44:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151311 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151311/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151290 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151290 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151290 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151290 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151290 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151290 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151290 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151290 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151290 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151290 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen fde76f895d0aa817a1207d844d793239c6639bc6 baseline version: xen fde76f895d0aa817a1207d844d793239c6639bc6 Last test of basis 151311 2020-06-23 10:16:25 Z 1 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:47:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:47:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4oM-00017H-27; Wed, 24 Jun 2020 12:47:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4oK-00017B-I3 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:47:28 +0000 X-Inumbo-ID: dc0d548e-b618-11ea-80af-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dc0d548e-b618-11ea-80af-12813bfff9fa; Wed, 24 Jun 2020 12:47:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zFDHlQbWHatr6tvqmfH4BGGnAI8AYH7lG2s2IXhTm7c=; b=ztFA2DlhOmT/RWhd/hofe/8WbA W9Ry+CjWmYn6fknfNPwakDSt3HKsNiMjeL0vR3TiEgR+rI2Nv4022oZNkKgc3BtqEb6jOTYhn+fB7 zCWy1jZe6hX44HNH3FjfWiHkI0NGjMzSK38kN0yDWKtVKKD0TfzXs+kDB7xiVGZTxjZE=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4oH-0001EH-UZ; Wed, 24 Jun 2020 12:47:25 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jo4oH-0007Ro-NH; Wed, 24 Jun 2020 12:47:25 +0000 Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Jan Beulich References: <20200623135246.66170-1-roger.pau@citrix.com> <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> <20200623173150.GV735@Air-de-Roger> <3ea0ff91-8e5c-701c-ee31-4140b247f3c9@suse.com> <4651b23b-ca82-a478-debd-c20cdcd3facd@xen.org> From: Julien Grall Message-ID: <6195142d-6fa3-474d-3070-f43105742e79@xen.org> Date: Wed, 24 Jun 2020 13:47:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, On 24/06/2020 13:08, Jan Beulich wrote: > On 24.06.2020 12:52, Julien Grall wrote: >> Hi Jan, >> >> On 24/06/2020 11:05, Jan Beulich wrote: >>> On 23.06.2020 19:32, Roger Pau Monné wrote: >>>> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote: >>>>> On 23.06.2020 15:52, Roger Pau Monne wrote: >>>>>> XENMEM_acquire_resource and it's related structure is currently inside >>>>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the >>>>>> hypervisor or the toolstack only. This is wrong as the hypercall is >>>>>> already being used by the Linux kernel at least, and as such needs to >>>>>> be public. >>>>> >>>>> Actually - how does this work for the Linux kernel, seeing >>>>> >>>>> rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); >>>>> if ( rc ) >>>>> return rc; >>>>> >>>>> rc = xsm_domain_resource_map(XSM_DM_PRIV, d); >>>>> if ( rc ) >>>>> goto out; >>>>> >>>>> in the function? >>>> >>>> It's my understanding (I haven't tried to use that hypercall yet on >>>> FreeBSD, so I cannot say I've tested it), that xmar.domid is the >>>> remote domain, which the functions locks and then uses >>>> xsm_domain_resource_map to check whether the current domain has >>>> permissions to do privileged operations against it. >>> >>> Yes, but that's a tool stack operation, not something the kernel >>> would do all by itself. The kernel would only ever pass DOMID_SELF >>> (or the actual local domain ID), I would think. >> >> You can't issue that hypercall directly from userspace because you need >> to map the page in the physical address space of the toolstack domain. >> >> So the kernel has to act as the proxy for the hypercall. This is >> implemented as mmap() in Linux. > > Oh, and there's no generic wrapping available here, unlike for > dmop. It is not clear to me the sort of generic wrapping you are referring to. Are you referring to a stable interface for an application? > Makes me wonder whether, for this purpose, there should > be (have been) a new dmop with identical functionality, to > allow such funneling. I am not sure how using DMOP will allow us to implement it fully in userspace. Do you mind expanding it? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:52:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:52:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4su-0001va-Ph; Wed, 24 Jun 2020 12:52:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4st-0001vS-JE for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:52:11 +0000 X-Inumbo-ID: 84a97c26-b619-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 84a97c26-b619-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 12:52:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B1FE1ACED; Wed, 24 Jun 2020 12:52:09 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Julien Grall References: <20200623135246.66170-1-roger.pau@citrix.com> <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> <20200623173150.GV735@Air-de-Roger> <3ea0ff91-8e5c-701c-ee31-4140b247f3c9@suse.com> <4651b23b-ca82-a478-debd-c20cdcd3facd@xen.org> <6195142d-6fa3-474d-3070-f43105742e79@xen.org> From: Jan Beulich Message-ID: <5193dc6d-0a4c-4e1b-d089-9ba359c19e3e@suse.com> Date: Wed, 24 Jun 2020 14:52:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <6195142d-6fa3-474d-3070-f43105742e79@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 24.06.2020 14:47, Julien Grall wrote: > Hi, > > On 24/06/2020 13:08, Jan Beulich wrote: >> On 24.06.2020 12:52, Julien Grall wrote: >>> Hi Jan, >>> >>> On 24/06/2020 11:05, Jan Beulich wrote: >>>> On 23.06.2020 19:32, Roger Pau Monné wrote: >>>>> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote: >>>>>> On 23.06.2020 15:52, Roger Pau Monne wrote: >>>>>>> XENMEM_acquire_resource and it's related structure is currently inside >>>>>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the >>>>>>> hypervisor or the toolstack only. This is wrong as the hypercall is >>>>>>> already being used by the Linux kernel at least, and as such needs to >>>>>>> be public. >>>>>> >>>>>> Actually - how does this work for the Linux kernel, seeing >>>>>> >>>>>> rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); >>>>>> if ( rc ) >>>>>> return rc; >>>>>> >>>>>> rc = xsm_domain_resource_map(XSM_DM_PRIV, d); >>>>>> if ( rc ) >>>>>> goto out; >>>>>> >>>>>> in the function? >>>>> >>>>> It's my understanding (I haven't tried to use that hypercall yet on >>>>> FreeBSD, so I cannot say I've tested it), that xmar.domid is the >>>>> remote domain, which the functions locks and then uses >>>>> xsm_domain_resource_map to check whether the current domain has >>>>> permissions to do privileged operations against it. >>>> >>>> Yes, but that's a tool stack operation, not something the kernel >>>> would do all by itself. The kernel would only ever pass DOMID_SELF >>>> (or the actual local domain ID), I would think. >>> >>> You can't issue that hypercall directly from userspace because you need >>> to map the page in the physical address space of the toolstack domain. >>> >>> So the kernel has to act as the proxy for the hypercall. This is >>> implemented as mmap() in Linux. >> >> Oh, and there's no generic wrapping available here, unlike for >> dmop. > > It is not clear to me the sort of generic wrapping you are referring to. > Are you referring to a stable interface for an application? > >> Makes me wonder whether, for this purpose, there should >> be (have been) a new dmop with identical functionality, to >> allow such funneling. > > I am not sure how using DMOP will allow us to implement it fully in > userspace. Do you mind expanding it? dmop was designed so that a kernel proxying requests wouldn't need updating for every new request added to the interface. If the request here was made through a new dmop, the kernel would never have had a need to know of an interface structure that's of no interest to it, but only to the tool stack. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:53:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:53:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4tf-0001zo-3K; Wed, 24 Jun 2020 12:52:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4td-0001zc-Q7 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:52:57 +0000 X-Inumbo-ID: a02ce316-b619-11ea-bb8b-bc764e2007e4 Received: from mail-lj1-x243.google.com (unknown [2a00:1450:4864:20::243]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a02ce316-b619-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 12:52:57 +0000 (UTC) Received: by mail-lj1-x243.google.com with SMTP id h19so2365223ljg.13 for ; Wed, 24 Jun 2020 05:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L2VfXr+wrRkLpcYiMpgSJbGnKK49VpSgllN39LKBgUE=; b=moJpyLkWwhBSb97Itz2uOmKHAMBB6Shej3HOy3IyJQvTM53KA9KJhMHnL8FYt+zjuA nIbGXg9dMF2oENgkDQ+3pX5Z1CScve4fPLZn9mlVnNuYz5BroRrDm2sGdQbqMx0aBzoG +WgXWUeGIFcnNAoyk+pqzBmM0GxGq84p2OKqR/PmnVjUQw7iahHZmPfrhyJ7nRnUr/vV 2TupTloIhqaJXHtUSvZTVGyCPCK5+X5mifUMSUJjZNQq5eOzPJqS8KJLhIFhbjfmmepB TJmbG2tRZh/rHWnArCMYPwUMHbjw5ZFKu8UjcK5UlWOHEy8PdKF3jQn+u33ukIwJ/zCz zU4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L2VfXr+wrRkLpcYiMpgSJbGnKK49VpSgllN39LKBgUE=; b=hvScFf6mPYVh8wC9yPyjZ+iq5yN5/v8p7WAkdwvyk3sRJp45JHPHeT2vyr7GWQDE8m cAeMqxjCEDJX0rgtAUv9ZgvK6jCGNMGHH1cKHVQqiI6ArT1GorqoK19OJGW7T0O0QvoK hX9brIS4y/bqSXlEMSALt8hpx1gAULSNF5KeyVdvg/tUF10ersLTfgnLJZuYmHukfSwU Qgv4lrS/zuqxg6urYv+XEW55o6co3bBvoUec2FFsOjRWBF1XzcfJZh3dGqvTSZlxJXVC PkujWGYScO+TfN1Xwz98KXs12xrWrLoPkpmwxUgz7qbWEMt5EDxpjpjTLXz/Itq7yFzu QCZA== X-Gm-Message-State: AOAM530UfqnB7JzqvJ2+S+CHk+PEREHmNHO+qdLVXFEv3uncCsukEf1b 3HtpWc88ASEdFX1OW3OVhNaTLUxS7UqKS0c1cfM= X-Google-Smtp-Source: ABdhPJyIxbtadZc95+Z5PRSpPgsxAcE1qBgoXjjgpynlW/K8aJOqdQu1yqcI78stkMCEvVZ69GuBZqLEw98bdJ76kdI= X-Received: by 2002:a2e:b8c2:: with SMTP id s2mr14830277ljp.368.1593003176111; Wed, 24 Jun 2020 05:52:56 -0700 (PDT) MIME-Version: 1.0 References: <20200624121939.10282-1-jandryuk@gmail.com> <000a01d64a23$4a595e90$df0c1bb0$@xen.org> In-Reply-To: <000a01d64a23$4a595e90$df0c1bb0$@xen.org> From: Jason Andryuk Date: Wed, 24 Jun 2020 08:52:44 -0400 Message-ID: Subject: Re: [PATCH] xen: Fix xen-legacy-backend qdev types To: Paul Durrant Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , xen-devel , Stefano Stabellini , QEMU Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 8:30 AM Paul Durrant wrote: > > > -----Original Message----- > > From: Jason Andryuk > > Sent: 24 June 2020 13:20 > > To: Stefano Stabellini ; Anthony Perard ; Paul > > Durrant ; xen-devel@lists.xenproject.org > > Cc: Jason Andryuk ; qemu-devel@nongnu.org > > Subject: [PATCH] xen: Fix xen-legacy-backend qdev types > > > > xen-sysdev is a TYPE_SYS_BUS_DEVICE. bus_type should not be changed so > > that it can plug into the System bus. Otherwise this assert triggers: > > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > > failed. > > > > TYPE_XENBACKEND attaches to TYPE_XENSYSBUS, so its class_init needs to > > be set accordingly to attach the qdev. Otherwise the following assert > > triggers: > > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > > failed. > > > > TYPE_XENBACKEND is not a subclass of XEN_XENSYSDEV, so it's parent > > is just TYPE_DEVICE. Change that. > > > > Signed-off-by: Jason Andryuk > > Clearly we raced. This patch and my patch #1 are identical so I'm happy to give my ack to this. Yeah, looks like you beat me by a hair :) Either way it gets fixed is fine by me. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:53:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:53:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4tz-00023p-Bd; Wed, 24 Jun 2020 12:53:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4tx-00023Y-RV for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:53:17 +0000 X-Inumbo-ID: ac0a6550-b619-11ea-8496-bc764e2007e4 Received: from mail-wr1-x441.google.com (unknown [2a00:1450:4864:20::441]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ac0a6550-b619-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 12:53:17 +0000 (UTC) Received: by mail-wr1-x441.google.com with SMTP id a6so2181660wrm.4 for ; Wed, 24 Jun 2020 05:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=erJri2IUc1afPi5W9caFzfb9aRxEdZUWLTxuf4CtQkw=; b=kEUHQYow9kKir4HNF8IYSdtmgawte+egcY3TevRLt1W/9f9rrlbKAuEhMpzgtUklKO DGC0qmKdq3dT+tREc6lic0R1NtJa+8OD3qSZKYD9fMRkTudBMyrK5gRJmMIC9hLozvTm fgR8b/diZSY99jyd+wOtcv67SzODaao6f1gnQG6R5FoWfMu4ef8TsHi5h9ODUQq7jzcA p10YfbDUvD5kBsD0gab+G9btUhqYFwzp2n003WfMZK2g9qjMqvJ4l57Cehsj1Jcl+CZ/ +OOMnUXN67jxbSs2TPLqXLDuX/RmslTRaxUXnfYEybH+6o9FUiN66VUer6k8hjs8JJQ7 1tTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=erJri2IUc1afPi5W9caFzfb9aRxEdZUWLTxuf4CtQkw=; b=Ix78L036PrujqQrIS9wEPi/YH7tXAopFpguVURXVLqUru0LaFMRQaTY0W5XzIYomOF 2eB+rw/Qppuo2uLBinIiVWJI0Yc4fonioBiU7uLsIEbCuKClNr2NlqGW+cg67rjzQjKu mznIYOUwMduWJNE66dHmtPrYh+rgNthmye75wa1uuafXyB6u1GHc9KX3i75UcW7wH6O9 Sy9VY2oou/KH5wpqdCcT2RtOpmHACT/13ImjvQMAUpRzZOml2RpysS++SU8yCzCLZotU 66i2hCQCBPfrx93FW6IboKFJEc7qeN7aBtlMFV3unV11Q9mTXlLmTc9nwfN/JINiz/dm fiaw== X-Gm-Message-State: AOAM5307IxvXMh/N9eHpxQ8kb8BtnLJwdJlT+80BcT3124iGTA4eotdK StcgztmJ0k9zBIVYrDUNT5myfV66zK/g1VcqvU4= X-Google-Smtp-Source: ABdhPJyYZjpyarrBmuEOQEoSXgv0/j0u4MKq4eiYYARiftGnLceMfY2jZQwxLUpHIEM0C69qzqVH7XMR5hNIOccpnTg= X-Received: by 2002:a5d:44d1:: with SMTP id z17mr26139887wrr.259.1593003195949; Wed, 24 Jun 2020 05:53:15 -0700 (PDT) MIME-Version: 1.0 References: <122238637.9820857.1592523264685.JavaMail.zimbra@cert.pl> <1005194077.9820950.1592523663199.JavaMail.zimbra@cert.pl> <4e040500-0532-2231-f5b7-c61e97a0a0c5@suse.com> <800738193.11403725.1592836530558.JavaMail.zimbra@cert.pl> <87576264-e7df-2590-f141-351d76baac7a@suse.com> <1130937743.11428389.1592841763323.JavaMail.zimbra@cert.pl> <5b7dd58f-2dc1-32bc-3add-d896631734a4@suse.com> <901046162.11470361.1592874264410.JavaMail.zimbra@cert.pl> <32b7234b-dc64-a0ea-2c5c-448bcec44c34@suse.com> In-Reply-To: From: Tamas K Lengyel Date: Wed, 24 Jun 2020 06:52:39 -0600 Message-ID: Subject: Re: [PATCH v2 4/7] x86/vmx: add do_vmtrace_op To: Andrew Cooper Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 6:40 AM Andrew Cooper w= rote: > > On 24/06/2020 11:03, Jan Beulich wrote: > > On 23.06.2020 19:24, Andrew Cooper wrote: > >> On 23/06/2020 09:51, Jan Beulich wrote: > >>> On 23.06.2020 03:04, Micha=C5=82 Leszczy=C5=84ski wrote: > >>>> ----- 22 cze 2020 o 18:16, Jan Beulich jbeulich@suse.com napisa=C5= =82(a): > >>>> > >>>>> On 22.06.2020 18:02, Micha=C5=82 Leszczy=C5=84ski wrote: > >>>>>> ----- 22 cze 2020 o 17:22, Jan Beulich jbeulich@suse.com napisa=C5= =82(a): > >>>>>>> On 22.06.2020 16:35, Micha=C5=82 Leszczy=C5=84ski wrote: > >>>>>>>> ----- 22 cze 2020 o 15:25, Jan Beulich jbeulich@suse.com napisa= =C5=82(a): > >>>>>>>>> Is any of what you do in this switch() actually legitimate with= out > >>>>>>>>> hvm_set_vmtrace_pt_size() having got called for the guest? From > >>>>>>>>> remarks elsewhere I imply you expect the param that you current= ly > >>>>>>>>> use to be set upon domain creation time, but at the very least = the > >>>>>>>>> potentially big buffer should imo not get allocated up front, b= ut > >>>>>>>>> only when tracing is to actually be enabled. > >>>>>>>> Wait... so you want to allocate these buffers in runtime? > >>>>>>>> Previously we were talking that there is too much runtime logic > >>>>>>>> and these enable/disable hypercalls should be stripped to absolu= te > >>>>>>>> minimum. > >>>>>>> Basic arrangements can be made at domain creation time. I don't > >>>>>>> think though that it would be a good use of memory if you > >>>>>>> allocated perhaps many gigabytes of memory just for possibly > >>>>>>> wanting to enable tracing on a guest. > >>>>>>> > >>>>>> From our previous conversations I thought that you want to have > >>>>>> as much logic moved to the domain creation as possible. > >>>>>> > >>>>>> Thus, a parameter "vmtrace_pt_size" was introduced. By default it'= s > >>>>>> zero (=3D disabled), if you set it to a non-zero value, then trace= buffers > >>>>>> of given size will be allocated for the domain and you have possib= ility > >>>>>> to use ipt_enable/ipt_disable at any moment. > >>>>>> > >>>>>> This way the runtime logic is as thin as possible. I assume user k= nows > >>>>>> in advance whether he/she would want to use external monitoring wi= th IPT > >>>>>> or not. > >>>>> Andrew - I think you requested movement to domain_create(). Could > >>>>> you clarify if indeed you mean to also allocate the big buffers > >>>>> this early? > >>>> I would like to recall what Andrew wrote few days ago: > >>>> > >>>> ----- 16 cze 2020 o 22:16, Andrew Cooper andrew.cooper3@citrix.com w= rote: > >>>>> Xen has traditionally opted for a "and turn this extra thing on > >>>>> dynamically" model, but this has caused no end of security issues a= nd > >>>>> broken corner cases. > >>>>> > >>>>> You can see this still existing in the difference between > >>>>> XEN_DOMCTL_createdomain and XEN_DOMCTL_max_vcpus, (the latter being > >>>>> required to chose the number of vcpus for the domain) and we're mak= ing > >>>>> good progress undoing this particular wart (before 4.13, it was > >>>>> concerning easy to get Xen to fall over a NULL d->vcpu[] pointer by > >>>>> issuing other hypercalls between these two). > >>>>> > >>>>> There is a lot of settings which should be immutable for the lifeti= me of > >>>>> the domain, and external monitoring looks like another one of these= . > >>>>> Specifying it at createdomain time allows for far better runtime > >>>>> behaviour (you are no longer in a situation where the first time yo= u try > >>>>> to turn tracing on, you end up with -ENOMEM because another VM boot= ed in > >>>>> the meantime and used the remaining memory), and it makes for rathe= r > >>>>> more simple code in Xen itself (at runtime, you can rely on it havi= ng > >>>>> been set up properly, because a failure setting up will have killed= the > >>>>> domain already). > >>>>> > >>>>> ... > >>>>> > >>>>> ~Andrew > >>>> according to this quote I've moved buffer allocation to the create_d= omain, > >>>> the updated version was already sent to the list as patch v3. > >>> I'd still like to see an explicit confirmation by him that this > >>> use of memory is indeed what he has intended. There are much smaller > >>> amounts of memory which we allocate on demand, just to avoid > >>> allocating some without then ever using it. > >> PT is a debug/diagnostic tool. Its not something you'd run in > >> production against a production VM. > > Well, the suggested use with introspection made me assume differently. > > If this is (now and forever) truly debug/diag only, so be it then. > > At the end of the day, it is a fine grain profiling tool, meaning that > it is not used in the common case. > > The usecase presented is for fuzzing, using the execution trace > generated by the CPU, rather than the current scheme which allegedly > involves shuffling breakpoints around. That's indeed the usecase we are looking to use it for. But there is also some experimental malware analysis scenarios it is targeted for which is what I believe the CERT folks are mostly interested in, like https://www.vmray.com/cyber-security-blog/back-to-the-past-using-intels-pro= cessor-trace-for-enhanced-analysis. I could also imagine this to be useful for IDS/IPS solutions like what Bitdefender is building but I'm just speculating since the overhead might be prohibitive for that use-case. I would consider all these scenarios experimental at this point and absolutely not something to enable by default. If someone presents a need for this to be supported on production VMs that require turning it on/off at runtime not knowing whether the feature will be used when the domain is created we can certainly revisit the topic. But I don't expect that to happen any time soon, if at all. Tamas From xen-devel-bounces@lists.xenproject.org Wed Jun 24 12:53:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 12:53:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4uL-00027o-KD; Wed, 24 Jun 2020 12:53:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo4uK-00027e-F4 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 12:53:40 +0000 X-Inumbo-ID: b995b67a-b619-11ea-bb8b-bc764e2007e4 Received: from mail-ej1-x644.google.com (unknown [2a00:1450:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b995b67a-b619-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 12:53:39 +0000 (UTC) Received: by mail-ej1-x644.google.com with SMTP id q19so2325041eja.7 for ; Wed, 24 Jun 2020 05:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=vyVAL48RnupCHLHRT6ZRkkhf9C+oMNXsUB9p67p/yAI=; b=Ifpt5u8EnUwIyONleLlEdx3xjRDuRDA3X9pGVyAKX970WS1NHchXayju+QhtlBkK8Y wa5L4gPtnjboPQcX3Wqj6N5EV+xbaIauZFmS7Z4ZTjs7B7TiPHXffE7x/h5HHEonJkF6 yl+EUPyzMbsj+H8ibCExZF6ma5BVdpTciSKu2QxAlFVqq4LXxrLUvfSxsMwV4JKWBNii KEOLEz8LkKxVdZPoL3CTbYySnTGtWpOqeUgGJRL8C1tnLoj8Nvan2l/1/p5T/cmGSECI qrBSmLCaoTT17sq/3TlfE9z4iwtfVU1uBeS+1SXg4P/zxvekIICsCKkAVFApc3onp42O 8Ghw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=vyVAL48RnupCHLHRT6ZRkkhf9C+oMNXsUB9p67p/yAI=; b=cXaCTv4AWZyZuEqxyKsHLKhTI6HNxYGWuoEDaKyEF0e6kzi9jcy/k/XvuiIa/uXFHJ FVgflrmFp1BLgDeYA7LZ2jZdh3nP/O4OdGiUFwchKYeB95XDrkU/oqdcswWNM8kO+Ek4 4SYPtYovxUxjCdsuoyCCyoTu05UDdLNytxUfbRyd2/qarD5oDdfn85lymZyhsVe5xHZ4 PDYkS8v0xkpipW0kvkmwT3vxBX8IAuaIIuyGnk+6hL+V/V8DLMW8xqhd+08pBRmu0Mmo JVhU3S0GS04z6n/wFVdFbMXNLzlkkL55mExXKCHfNKz6HHC2LPs4ZPjLAurbMR9TRzki 8oPQ== X-Gm-Message-State: AOAM533gDGhVaUJBWtL67Nke3qoxtir8WKUgbhg+C0TOpoX3ibvdAjyo 5CHYtJu1pP1l/Hq6E5xF8cg= X-Google-Smtp-Source: ABdhPJzq8f1yFiZgimYjAXlmWVdkv9I+EoR2QaHjKoznGfRot8xlkTiizL3Znd2qxyYiucraoJzOIQ== X-Received: by 2002:a17:906:8392:: with SMTP id p18mr15846296ejx.24.1593003218882; Wed, 24 Jun 2020 05:53:38 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id q3sm16667175eds.0.2020.06.24.05.53.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 05:53:38 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , "'Julien Grall'" References: <20200623135246.66170-1-roger.pau@citrix.com> <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> <20200623173150.GV735@Air-de-Roger> <3ea0ff91-8e5c-701c-ee31-4140b247f3c9@suse.com> <4651b23b-ca82-a478-debd-c20cdcd3facd@xen.org> <6195142d-6fa3-474d-3070-f43105742e79@xen.org> <5193dc6d-0a4c-4e1b-d089-9ba359c19e3e@suse.com> In-Reply-To: <5193dc6d-0a4c-4e1b-d089-9ba359c19e3e@suse.com> Subject: RE: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource Date: Wed, 24 Jun 2020 13:53:37 +0100 Message-ID: <000b01d64a26$7aacb580$70062080$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJU5g6mkfXrDLlGsNt841F72IbClgGrea6PAfx/VmoCRJsRMgEBRCcgApo72pAB5Qr3iwGBPLtyp4MNv4A= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , xen-devel@lists.xenproject.org, =?UTF-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 24 June 2020 13:52 > To: Julien Grall > Cc: Roger Pau Monn=C3=A9 ; = xen-devel@lists.xenproject.org; paul@xen.org; Andrew > Cooper ; George Dunlap = ; Ian Jackson > ; Stefano Stabellini = ; Wei Liu > Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct = xen_mem_acquire_resource >=20 > On 24.06.2020 14:47, Julien Grall wrote: > > Hi, > > > > On 24/06/2020 13:08, Jan Beulich wrote: > >> On 24.06.2020 12:52, Julien Grall wrote: > >>> Hi Jan, > >>> > >>> On 24/06/2020 11:05, Jan Beulich wrote: > >>>> On 23.06.2020 19:32, Roger Pau Monn=C3=A9 wrote: > >>>>> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote: > >>>>>> On 23.06.2020 15:52, Roger Pau Monne wrote: > >>>>>>> XENMEM_acquire_resource and it's related structure is = currently inside > >>>>>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope = to the > >>>>>>> hypervisor or the toolstack only. This is wrong as the = hypercall is > >>>>>>> already being used by the Linux kernel at least, and as such = needs to > >>>>>>> be public. > >>>>>> > >>>>>> Actually - how does this work for the Linux kernel, seeing > >>>>>> > >>>>>> rc =3D rcu_lock_remote_domain_by_id(xmar.domid, &d); > >>>>>> if ( rc ) > >>>>>> return rc; > >>>>>> > >>>>>> rc =3D xsm_domain_resource_map(XSM_DM_PRIV, d); > >>>>>> if ( rc ) > >>>>>> goto out; > >>>>>> > >>>>>> in the function? > >>>>> > >>>>> It's my understanding (I haven't tried to use that hypercall yet = on > >>>>> FreeBSD, so I cannot say I've tested it), that xmar.domid is the > >>>>> remote domain, which the functions locks and then uses > >>>>> xsm_domain_resource_map to check whether the current domain has > >>>>> permissions to do privileged operations against it. > >>>> > >>>> Yes, but that's a tool stack operation, not something the kernel > >>>> would do all by itself. The kernel would only ever pass = DOMID_SELF > >>>> (or the actual local domain ID), I would think. > >>> > >>> You can't issue that hypercall directly from userspace because you = need > >>> to map the page in the physical address space of the toolstack = domain. > >>> > >>> So the kernel has to act as the proxy for the hypercall. This is > >>> implemented as mmap() in Linux. > >> > >> Oh, and there's no generic wrapping available here, unlike for > >> dmop. > > > > It is not clear to me the sort of generic wrapping you are referring = to. > > Are you referring to a stable interface for an application? > > > >> Makes me wonder whether, for this purpose, there should > >> be (have been) a new dmop with identical functionality, to > >> allow such funneling. > > > > I am not sure how using DMOP will allow us to implement it fully in > > userspace. Do you mind expanding it? >=20 > dmop was designed so that a kernel proxying requests wouldn't need > updating for every new request added to the interface. If the > request here was made through a new dmop, the kernel would never > have had a need to know of an interface structure that's of no > interest to it, but only to the tool stack. How would the pages get mapped into process address space if the kernel = doesn't know what's being done? Paul >=20 > Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 13:07:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 13:07:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo57c-0003OB-TH; Wed, 24 Jun 2020 13:07:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo57b-0003O6-PD for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 13:07:23 +0000 X-Inumbo-ID: a451ba14-b61b-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a451ba14-b61b-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 13:07:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CAA42AEFE; Wed, 24 Jun 2020 13:07:21 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: paul@xen.org References: <20200623135246.66170-1-roger.pau@citrix.com> <044c278b-e0df-e389-b21a-66c7307997c4@suse.com> <20200623173150.GV735@Air-de-Roger> <3ea0ff91-8e5c-701c-ee31-4140b247f3c9@suse.com> <4651b23b-ca82-a478-debd-c20cdcd3facd@xen.org> <6195142d-6fa3-474d-3070-f43105742e79@xen.org> <5193dc6d-0a4c-4e1b-d089-9ba359c19e3e@suse.com> <000b01d64a26$7aacb580$70062080$@xen.org> From: Jan Beulich Message-ID: <2bcda30f-fa95-adea-d19a-4d9a4c00d130@suse.com> Date: Wed, 24 Jun 2020 15:07:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <000b01d64a26$7aacb580$70062080$@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , xen-devel@lists.xenproject.org, =?UTF-8?B?J1JvZ2VyIFBhdSBNb25uw6kn?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 24.06.2020 14:53, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 24 June 2020 13:52 >> To: Julien Grall >> Cc: Roger Pau Monné ; xen-devel@lists.xenproject.org; paul@xen.org; Andrew >> Cooper ; George Dunlap ; Ian Jackson >> ; Stefano Stabellini ; Wei Liu >> Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource >> >> On 24.06.2020 14:47, Julien Grall wrote: >>> Hi, >>> >>> On 24/06/2020 13:08, Jan Beulich wrote: >>>> On 24.06.2020 12:52, Julien Grall wrote: >>>>> Hi Jan, >>>>> >>>>> On 24/06/2020 11:05, Jan Beulich wrote: >>>>>> On 23.06.2020 19:32, Roger Pau Monné wrote: >>>>>>> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote: >>>>>>>> On 23.06.2020 15:52, Roger Pau Monne wrote: >>>>>>>>> XENMEM_acquire_resource and it's related structure is currently inside >>>>>>>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the >>>>>>>>> hypervisor or the toolstack only. This is wrong as the hypercall is >>>>>>>>> already being used by the Linux kernel at least, and as such needs to >>>>>>>>> be public. >>>>>>>> >>>>>>>> Actually - how does this work for the Linux kernel, seeing >>>>>>>> >>>>>>>> rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); >>>>>>>> if ( rc ) >>>>>>>> return rc; >>>>>>>> >>>>>>>> rc = xsm_domain_resource_map(XSM_DM_PRIV, d); >>>>>>>> if ( rc ) >>>>>>>> goto out; >>>>>>>> >>>>>>>> in the function? >>>>>>> >>>>>>> It's my understanding (I haven't tried to use that hypercall yet on >>>>>>> FreeBSD, so I cannot say I've tested it), that xmar.domid is the >>>>>>> remote domain, which the functions locks and then uses >>>>>>> xsm_domain_resource_map to check whether the current domain has >>>>>>> permissions to do privileged operations against it. >>>>>> >>>>>> Yes, but that's a tool stack operation, not something the kernel >>>>>> would do all by itself. The kernel would only ever pass DOMID_SELF >>>>>> (or the actual local domain ID), I would think. >>>>> >>>>> You can't issue that hypercall directly from userspace because you need >>>>> to map the page in the physical address space of the toolstack domain. >>>>> >>>>> So the kernel has to act as the proxy for the hypercall. This is >>>>> implemented as mmap() in Linux. >>>> >>>> Oh, and there's no generic wrapping available here, unlike for >>>> dmop. >>> >>> It is not clear to me the sort of generic wrapping you are referring to. >>> Are you referring to a stable interface for an application? >>> >>>> Makes me wonder whether, for this purpose, there should >>>> be (have been) a new dmop with identical functionality, to >>>> allow such funneling. >>> >>> I am not sure how using DMOP will allow us to implement it fully in >>> userspace. Do you mind expanding it? >> >> dmop was designed so that a kernel proxying requests wouldn't need >> updating for every new request added to the interface. If the >> request here was made through a new dmop, the kernel would never >> have had a need to know of an interface structure that's of no >> interest to it, but only to the tool stack. > > How would the pages get mapped into process address space if the > kernel doesn't know what's being done? Urgh, yes, silly me. Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 13:29:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 13:29:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo5SK-0005IA-RV; Wed, 24 Jun 2020 13:28:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo5SJ-0005I5-K1 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 13:28:47 +0000 X-Inumbo-ID: a16fa290-b61e-11ea-8496-bc764e2007e4 Received: from mail-lj1-x233.google.com (unknown [2a00:1450:4864:20::233]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a16fa290-b61e-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 13:28:46 +0000 (UTC) Received: by mail-lj1-x233.google.com with SMTP id q19so2567304lji.2 for ; Wed, 24 Jun 2020 06:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nUrO1UmohK9ah4PTXz60cWnuU3BQE5TYlbAsoayD3rs=; b=j1qdfIIZ/q1NnGEj8rl1xpFjrLO16wTKUdJwWNBQqs/KEhL2zgL4G9Wuctl4moJ8L8 p4QD4qRv+Jxfb3+f3s7wl4Zd3HVNUHUfLz5v/chtPrx2T9XWvEXr6GmUGONf8WQLq4BW 6m+SjU0Ndjxhap5GK2lRLh4Uq574Av38crJK56x1R/5NmS/M3wZfhD0jPcgUB5YDesge 1PUPooOkLnVqkckEFq6tB7UrB+I4SGRviggewzrNWeK1onAWEH1IUxSRhwJIqMhRGmLK HmIn7mwpJ6+6YvbNXqsbNTDDBBKInK+XtlISN/Tt0BzD4Z4K5VNdaI5FTtQ6H4aTej4k 4f0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nUrO1UmohK9ah4PTXz60cWnuU3BQE5TYlbAsoayD3rs=; b=s0De5d2lQxpVlsxhe+HlK5A+I+NM6X41gqczvJmXv50FHKvvmkOBgWrbIfIEymkl1f q34kgL5PYDdtWDzMB4oIJF5VzgmdEh2jwmE3Y7oKz12PO1tu0p56u6tI15zGeTp0rjzv n0m2qk6QuFwLbGejgQrS1rdXr7JxLMNOPzXA6Okk5e5Osnhhwigdf+2sgLs1CAKAQ9WB AHpdPBVVv1ypFdhWU5RdsWbUKdLCAjD43UgArTeRBjn7EcHBuW0UynM90Y6dfRQOsO00 2lBA9CFPew5C8vw9dn3ZIpIleuva0ZpZMbHNom/rkyEWkZldKym5LM2X3qfV75SM+40F oeSw== X-Gm-Message-State: AOAM533rrITRnxYHr/5OHPAMmZzn8pKJ74wnuoNhDHj7dcq8qVph/G52 k59QOKexRYNmvHX5u+lARUFckhQRnCDdyroQLBQ= X-Google-Smtp-Source: ABdhPJx7vdw407d2wlLmqmq7qPN+YgmYyWzZLeZti3qgdfxdqAyoP7/KyEKrMYgsteU0k3JGc7eosC0VKWXGiyAxTcE= X-Received: by 2002:a2e:9a59:: with SMTP id k25mr14877859ljj.114.1593005325745; Wed, 24 Jun 2020 06:28:45 -0700 (PDT) MIME-Version: 1.0 From: Jason Andryuk Date: Wed, 24 Jun 2020 09:28:34 -0400 Message-ID: Subject: Migration vmdesc and xen-save-devices-state To: QEMU , xen-devel , zhang.zhanghailiang@huawei.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi, At some point, QEMU changed to add a json VM description (vmdesc) after the migration data. The vmdesc is not needed to restore the migration data, but qemu_loadvm_state() will read and discard the vmdesc to clear the stream when should_send_vmdesc() is true. xen-save-devices-state generates its migration data without a vmdesc. xen-load-devices-state in turn calls qemu_loadvm_state() which tries to load vmdesc since should_send_vmdesc is true for xen. When restoring from a file, this is fine since it'll return EOF, print "Expected vmdescription section, but got 0" and end the restore successfully. Linux stubdoms load their migration data over a console, so they don't hit the EOF and end up waiting. There does seem to be a timeout though and restore continues after a delay, but we'd like to eliminate the delay. Two options to address this are to either: 1) set suppress_vmdesc for the Xen machines to bypass the should_send_vmdesc() check. or 2) just send the vmdesc data. Since vmdesc is just discarded, maybe #1 should be followed. If going with #2, qemu_save_device_state() needs to generate the vmdesc data. Looking at qemu_save_device_state() and qemu_savevm_state_complete_precopy_non_iterable(), they are both very similar and could seemingly be merged. qmp_xen_save_devices_state() could even leverage the bdrv_inactivate_all() call in qemu_savevm_state_complete_precopy_non_iterable(). The would make qemu_save_device_state a little more heavywight, which could impact COLO. I'm not sure how performance sensitive the COLO code is, and I haven't measured anything. Does anyone have thoughts or opinions on the subject? Thanks, Jason From xen-devel-bounces@lists.xenproject.org Wed Jun 24 13:41:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 13:41:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo5el-0006wA-Vz; Wed, 24 Jun 2020 13:41:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo5ek-0006w5-QS for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 13:41:38 +0000 X-Inumbo-ID: 6d3abba2-b620-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6d3abba2-b620-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 13:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=PEabN3Vy57eNWCN+D2V2wK79SV2PBPWtL3087PnVobQ=; b=ZaEMY09WqTJvGtsiFlf5PerDnr NXvd1PFX4E423wjKaeNq9pDvVD8BLkY0hyy9ZZGB8xfBk/yMN/UbUDdQnkV57UmVwzan3I2itWMcq Tqy8oNKlTh6HqLjHqiXCjemIXEAg+xmcAqwv6uR48wjYir1xbasJpJghOtbZLBUIo4+Y=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo5ei-0002EX-CF; Wed, 24 Jun 2020 13:41:36 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jo5ei-0001Yy-0y; Wed, 24 Jun 2020 13:41:36 +0000 Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> From: Julien Grall Message-ID: <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> Date: Wed, 24 Jun 2020 14:41:33 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Jan, On 24/06/2020 11:12, Jan Beulich wrote: > On 23.06.2020 19:26, Roger Pau Monné wrote: >> On Tue, Jun 23, 2020 at 06:18:52PM +0200, Jan Beulich wrote: >>> On 23.06.2020 17:56, Roger Pau Monné wrote: >>>> On Tue, Jun 23, 2020 at 05:02:04PM +0200, Jan Beulich wrote: >>>>> On 23.06.2020 15:52, Roger Pau Monne wrote: >>>>>> XENMEM_acquire_resource and it's related structure is currently inside >>>>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the >>>>>> hypervisor or the toolstack only. This is wrong as the hypercall is >>>>>> already being used by the Linux kernel at least, and as such needs to >>>>>> be public. >>>>>> >>>>>> Also switch the usage of uint64_aligned_t to plain uint64_t, as >>>>>> uint64_aligned_t is only to be used by the toolstack. Note that the >>>>>> layout of the structure will be the same, as the field is already >>>>>> naturally aligned to a 8 byte boundary. >>>>> >>>>> I'm afraid it's more complicated, and hence ... >>>>> >>>>>> No functional change expected. >>>>> >>>>> ... this doesn't hold: As I notice only now the struct also wrongly >>>>> (if it was meant to be a tools-only interface) failed to use >>>>> XEN_GUEST_HANDLE_64(), which would in principle have been a problem >>>>> for 32-bit callers (passing garbage in the upper half of a handle). >>>>> It's not an actual problem because, unlike would typically be the >>>>> case for tools-only interfaces, there is compat translation for this >>>>> struct. >>>> >>>> Yes, there's already compat translation for the frame_list array. >>>> >>>>> With this, however, the problem of your change becomes noticeable: >>>>> The structure's alignment for 32-bit x86, and with it the structure's >>>>> sizeof(), both change. You should be able to see this by comparing >>>>> xen/common/compat/memory.c's disassembly before and after your >>>>> change - the number of bytes to copy by the respective >>>>> copy_from_guest() ought to have changed. >>>> >>>> Right, this is the layout with frame aligned to 8 bytes: >>>> >>>> struct xen_mem_acquire_resource { >>>> uint16_t domid; /* 0 2 */ >>>> uint16_t type; /* 2 2 */ >>>> uint32_t id; /* 4 4 */ >>>> uint32_t nr_frames; /* 8 4 */ >>>> uint32_t pad; /* 12 4 */ >>>> uint64_t frame; /* 16 8 */ >>>> long unsigned int * frame_list; /* 24 4 */ >>>> >>>> /* size: 32, cachelines: 1, members: 7 */ >>>> /* padding: 4 */ >>>> /* last cacheline: 32 bytes */ >>>> }; >>>> >>>> And this is without: >>>> >>>> struct xen_mem_acquire_resource { >>>> uint16_t domid; /* 0 2 */ >>>> uint16_t type; /* 2 2 */ >>>> uint32_t id; /* 4 4 */ >>>> uint32_t nr_frames; /* 8 4 */ >>>> uint32_t pad; /* 12 4 */ >>>> uint64_t frame; /* 16 8 */ >>>> long unsigned int * frame_list; /* 24 4 */ >>>> >>>> /* size: 28, cachelines: 1, members: 7 */ >>>> /* last cacheline: 28 bytes */ >>>> }; >>>> >>>> Note Xen has already been copying those extra 4 padding bytes from >>>> 32bit Linux kernels AFAICT, as the struct declaration in Linux has >>>> dropped the aligned attribute. >>>> >>>>> The question now is whether we're willing to accept such a (marginal) >>>>> incompatibility. The chance of a 32-bit guest actually running into >>>>> it shouldn't be very high, but with the right placement of an >>>>> instance of the struct at the end of a page it would be possible to >>>>> observe afaict. >>>>> >>>>> Or whether we go the alternative route and pad the struct suitably >>>>> for 32-bit. >>>> >>>> I guess we are trapped with what Linux has on it's headers now, so we >>>> should handle the struct size difference in Xen? >>> >>> How do you mean to notice the difference in Xen? You don't know >>> what the caller's environment's sizeof() would yield. >> >> I'm confused. Couldn't we switch from uint64_aligned_t to plain >> uint64_t (like it's currently on the Linux headers), and then use the >> compat layer in Xen to handle the size difference when called from >> 32bit environments? > > And which size would we use there? The old or the new one (breaking > future or existing callers respectively)? Meanwhile I think that if > this indeed needs to not be tools-only (which I still question), I think we now agreed on a subthread that the kernel needs to know the layout of the hypercall. > then our only possible route is to add explicit padding for the > 32-bit case alongside the change you're already making. AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make incompatible the two incompatible? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Wed Jun 24 14:01:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 14:01:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo5yF-0000Qv-Lu; Wed, 24 Jun 2020 14:01:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo5yE-0000Qq-D6 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 14:01:46 +0000 X-Inumbo-ID: 3d0b08d0-b623-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3d0b08d0-b623-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 14:01:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 83F8DACA7; Wed, 24 Jun 2020 14:01:44 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Julien Grall References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> From: Jan Beulich Message-ID: <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> Date: Wed, 24 Jun 2020 16:01:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 24.06.2020 15:41, Julien Grall wrote: > On 24/06/2020 11:12, Jan Beulich wrote: >> On 23.06.2020 19:26, Roger Pau Monné wrote: >>> I'm confused. Couldn't we switch from uint64_aligned_t to plain >>> uint64_t (like it's currently on the Linux headers), and then use the >>> compat layer in Xen to handle the size difference when called from >>> 32bit environments? >> >> And which size would we use there? The old or the new one (breaking >> future or existing callers respectively)? Meanwhile I think that if >> this indeed needs to not be tools-only (which I still question), > > I think we now agreed on a subthread that the kernel needs to know the > layout of the hypercall. > >> then our only possible route is to add explicit padding for the >> 32-bit case alongside the change you're already making. > > AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make > incompatible the two incompatible? In principle yes. But they're putting the structure instance on the stack, so there's not risk from Xen reading 4 bytes too many. I'd prefer keeping the interface as is (i.e. with the previously implicit padding made explicit) to avoid risking to break other possible callers. But that's just my view on it, anyway ... Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 15:32:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 15:32:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7Na-000166-92; Wed, 24 Jun 2020 15:32:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7NZ-000161-7I for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 15:32:01 +0000 X-Inumbo-ID: d86be108-b62f-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d86be108-b62f-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 15:32:00 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CD65DAD1F; Wed, 24 Jun 2020 15:31:58 +0000 (UTC) Subject: Ping: [PATCH v3 1/1] x86/acpi: Use FADT flags to determine the PMTMR width From: Jan Beulich To: Paul Durrant References: <5993e716-d71d-cbc0-a186-5325e2bdeba4@suse.com> Message-ID: <2c3e8cd2-b74f-52b6-4df8-057e8d000455@suse.com> Date: Wed, 24 Jun 2020 17:31:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <5993e716-d71d-cbc0-a186-5325e2bdeba4@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , jakub@bartmin.ski, Andrew Cooper , marmarek@invisiblethingslab.com, Grzegorz Uriasz , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 10:49, Jan Beulich wrote: > On 20.06.2020 00:00, Grzegorz Uriasz wrote: >> @@ -490,8 +497,12 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) >> */ >> if (!pmtmr_ioport) { >> pmtmr_ioport = fadt->pm_timer_block; >> - pmtmr_width = fadt->pm_timer_length == 4 ? 24 : 0; >> + pmtmr_width = fadt->pm_timer_length == 4 ? 32 : 0; >> } >> + if (pmtmr_width < 32 && fadt->flags & ACPI_FADT_32BIT_TIMER) >> + printk(KERN_WARNING PREFIX "PM-Timer is too short\n"); > > Indentation is screwed up here. > >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -457,16 +457,13 @@ static u64 read_pmtimer_count(void) >> static s64 __init init_pmtimer(struct platform_timesource *pts) >> { >> u64 start; >> - u32 count, target, mask = 0xffffff; >> + u32 count, target, mask; >> >> - if ( !pmtmr_ioport || !pmtmr_width ) >> + if ( !pmtmr_ioport || (pmtmr_width != 24 && pmtmr_width != 32) ) >> return 0; >> >> - if ( pmtmr_width == 32 ) >> - { >> - pts->counter_bits = 32; >> - mask = 0xffffffff; >> - } >> + pts->counter_bits = pmtmr_width; >> + mask = (1ull << pmtmr_width) - 1; > > "mask" being of "u32" type, the use of 1ull is certainly a little odd > here, and one of the reasons why I think this extra "cleanup" would > better go in a separate patch. > > Seeing that besides cosmetic aspects the patch looks okay now, I'd be > willing to leave the bigger adjustment mostly as is, albeit I'd > prefer the 1ull to go away, by instead switching to e.g. > > mask = 0xffffffff >> (32 - pmtmr_width); > > With the adjustments (which I'd be happy to make while committing, > provided you agree) > Reviewed-by: Jan Beulich > > Also Cc-ing Paul for a possible release ack (considering this is a > backporting candidate). Paul? Thanks, Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 15:32:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 15:32:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7OH-000190-Ip; Wed, 24 Jun 2020 15:32:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7OG-00018o-DH for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 15:32:44 +0000 X-Inumbo-ID: f25ea410-b62f-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f25ea410-b62f-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 15:32:43 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C0CDCAC12; Wed, 24 Jun 2020 15:32:42 +0000 (UTC) Subject: Ping: [PATCH] x86/CPUID: fill all fields in x86_cpuid_policy_fill_native() To: Andrew Cooper References: <41177396-9944-0bbd-66d2-8b4f2bd063f0@suse.com> From: Jan Beulich Message-ID: <8ff998a1-3d3a-3ffb-8f65-4ef13fb50c52@suse.com> Date: Wed, 24 Jun 2020 17:32:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 22.06.2020 14:39, Andrew Cooper wrote: > On 22/06/2020 13:09, Jan Beulich wrote: >> Coverity validly complains that the new call from >> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves >> two fields uninitialized, yet they get then consumed by >> x86_cpuid_copy_to_buffer(). (All other present callers of the function >> pass a pointer to a static - and hence initialized - buffer.) >> >> Coverity-ID: 1464809 >> Fixes: c22ced93e167 ("tests/cpu-policy: Confirm that CPUID serialisation is sorted") >> Signed-off-by: Jan Beulich >> >> --- a/xen/lib/x86/cpuid.c >> +++ b/xen/lib/x86/cpuid.c >> @@ -176,6 +176,10 @@ void x86_cpuid_policy_fill_native(struct >> ARRAY_SIZE(p->extd.raw) - 1); ++i ) >> cpuid_leaf(0x80000000 + i, &p->extd.raw[i]); >> >> + /* Don't report leaves from possible lower level hypervisor. */ > > ", for now." > > This will change in the future. > > With this, Reviewed-by: Andrew Cooper Paul? Thanks, Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 15:35:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 15:35:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7RN-0001KJ-1m; Wed, 24 Jun 2020 15:35:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7RL-0001KD-Gd for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 15:35:55 +0000 X-Inumbo-ID: 63dd8783-b630-11ea-80f1-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 63dd8783-b630-11ea-80f1-12813bfff9fa; Wed, 24 Jun 2020 15:35:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3003FAC40; Wed, 24 Jun 2020 15:35:53 +0000 (UTC) From: Jan Beulich Subject: Ping: [PATCH] x86/CPUID: fill all fields in x86_cpuid_policy_fill_native() To: Paul Durrant References: <41177396-9944-0bbd-66d2-8b4f2bd063f0@suse.com> Message-ID: Date: Wed, 24 Jun 2020 17:35:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Wei Liu , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" (sorry, re-sending with To and Cc corrected) On 22.06.2020 14:39, Andrew Cooper wrote: > On 22/06/2020 13:09, Jan Beulich wrote: >> Coverity validly complains that the new call from >> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves >> two fields uninitialized, yet they get then consumed by >> x86_cpuid_copy_to_buffer(). (All other present callers of the function >> pass a pointer to a static - and hence initialized - buffer.) >> >> Coverity-ID: 1464809 >> Fixes: c22ced93e167 ("tests/cpu-policy: Confirm that CPUID serialisation is sorted") >> Signed-off-by: Jan Beulich >> >> --- a/xen/lib/x86/cpuid.c >> +++ b/xen/lib/x86/cpuid.c >> @@ -176,6 +176,10 @@ void x86_cpuid_policy_fill_native(struct >> ARRAY_SIZE(p->extd.raw) - 1); ++i ) >> cpuid_leaf(0x80000000 + i, &p->extd.raw[i]); >> >> + /* Don't report leaves from possible lower level hypervisor. */ > > ", for now." > > This will change in the future. > > With this, Reviewed-by: Andrew Cooper Paul? Thanks, Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 15:37:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 15:37:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7Sn-0001Y2-Cu; Wed, 24 Jun 2020 15:37:25 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7Sl-0001Xv-NB for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 15:37:23 +0000 X-Inumbo-ID: 98e4c5e4-b630-11ea-80f1-12813bfff9fa Received: from userp2120.oracle.com (unknown [156.151.31.85]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 98e4c5e4-b630-11ea-80f1-12813bfff9fa; Wed, 24 Jun 2020 15:37:23 +0000 (UTC) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05OFLnBl126068; Wed, 24 Jun 2020 15:37:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=n0FH3RoDahVRFMHA+rYK1/GWNWDObYYkGLFnqRU/SIA=; b=Icaq77LfXnWXNh8KHl/5g7o72BKXs18JWK+Y0Jknvx0gHJX3KN521znZkX/btUTEnS2l EVqwKoyZqx1S3JP+8TgxZLRB6nscS/jWoel38Dzng6f2yDNVRzTjBuxW6Sz61dGEU5ug BVmo222ft/ZF3MxAaasaVSMtZjd6gvxIVrK2A6D+iki7HnP17w5VBUDC6x3flxOTypdI bWHiX8ZFzvSl2pbhcYAEB3IDg9chOhi9RnS3a6qrDYZUg9IG5Ep49dq0ysWIhWdIPdNt YrNe6bOXLd4+iM4aXkNpYrJlTfDtEgP0/3w1PIDD8R5MhGHokr2pYkvNA8k3+bwBvQ9t Lg== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 31uustkm0g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 24 Jun 2020 15:37:20 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05OFOBMa067668; Wed, 24 Jun 2020 15:37:19 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 31uur6p3wk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Jun 2020 15:37:19 +0000 Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 05OFbGbc002880; Wed, 24 Jun 2020 15:37:18 GMT Received: from [10.39.255.162] (/10.39.255.162) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Jun 2020 15:37:15 +0000 Subject: Re: [RFC PATCH v2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Souptick Joarder References: <1592913499-15558-1-git-send-email-jrdr.linux@gmail.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: Date: Wed, 24 Jun 2020 11:37:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9662 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 adultscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006240108 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9662 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 cotscore=-2147483648 adultscore=0 bulkscore=0 spamscore=0 phishscore=0 suspectscore=0 priorityscore=1501 lowpriorityscore=0 clxscore=1015 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006240108 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, paul@xen.org, John Hubbard , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/23/20 9:36 PM, Souptick Joarder wrote: > On Tue, Jun 23, 2020 at 11:11 PM Boris Ostrovsky > wrote: >> On 6/23/20 7:58 AM, Souptick Joarder wrote: >>> In 2019, we introduced pin_user_pages*() and now we are converting >>> get_user_pages*() to the new API as appropriate. [1] & [2] could >>> be referred for more information. This is case 5 as per document [1].= >>> >>> As discussed, pages need to be marked as dirty before unpinned it. >>> >>> Previously, if lock_pages() end up partially mapping pages, it used >>> to return -ERRNO due to which unlock_pages() have to go through >>> each pages[i] till *nr_pages* to validate them. This can be avoided >>> by passing correct number partially mapped pages & -ERRNO separately >>> while returning from lock_pages() due to error. >>> With this fix unlock_pages() doesn't need to validate pages[i] till >>> *nr_pages* for error scenario. >> >> This should be split into two patches please. The first one will fix t= he >> return value bug (and will need to go to stable branches) and the seco= nd >> will use new routine to pin pages. > Initially I split the patches into 2 commits. But at last moment I > figure out that, > this bug fix ( better to call coding error, doesn't looks like lead to > any runtime bug) is tightly coupled to 2nd commit for > pin_user_pages*() conversion, > which means we don't need the bug fix patch if we are not converting th= e API to > pin_user_pages*()/ unpin_user_pages_dirty_lock(). That's the reason to > clubbed these two > commits into a single one. I am not sure I understand why the two issues are connected. Failure of either get_user_pages_fast() or pin_user_pages() will result in the same kind of overall ioctl failure, won't it? One concern though is that we are changing how user will see this error. Currently Xen devicemodel (which AFAIK is the only caller) ignores it, which is I think is wrong. So another option would be to fix this in Xen and continue returning positive number here. I guess it's back to Paul again. -boris From xen-devel-bounces@lists.xenproject.org Wed Jun 24 15:55:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 15:55:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7k9-0003Jy-2J; Wed, 24 Jun 2020 15:55:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo7k8-0003JS-BM for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 15:55:20 +0000 X-Inumbo-ID: 1a44e360-b633-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1a44e360-b633-11ea-b7bb-bc764e2007e4; Wed, 24 Jun 2020 15:55:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 2633EAD20; Wed, 24 Jun 2020 15:55:18 +0000 (UTC) Subject: Ping: use of "stat -" From: Jan Beulich To: Ian Jackson References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> Message-ID: <4baa4ff6-aab6-63c6-16f0-96e71f567af4@suse.com> Date: Wed, 24 Jun 2020 17:55:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jason Andryuk , Andrew Cooper , Paul Durrant , Elliott Mitchell , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 18.05.2020 12:34, Jan Beulich wrote: > On 14.05.2020 13:02, Ian Jackson wrote: >> I've read this thread. Jan, I'm sorry that this causes you >> inconvenience. I'm hoping it won't come down to a choice between >> supporting people who want to ship a dom0 without perl, and people who >> want a dom0 using more-than-a-decade-old coreutils. >> >> Jan, can you tell me what the output is of this on your ancient >> system: >> >> $ rm -f t >> $ >t >> $ exec 3> $ stat -L -c '%F %i' /dev/stdin <&3 >> regular empty file 393549 >> $ rm t >> $ stat -L -c '%F %i' /dev/stdin <&3 >> regular empty file 393549 >> $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 >> $ > > $ rm -f t > $ >t > $ exec 3 $ stat -L -c '%F %i' /dev/stdin <&3 > regular empty file 3380369 > $ rm t > $ stat -L -c '%F %i' /dev/stdin <&3 > regular empty file 3380369 > $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 > regular empty file 3380369 > >> Also, the contents of the file "u" afterwards, please. > > Attached. > > Thanks for looking into this, Jan Is there (still) a plan to get this addressed for 4.14? Apologies if I missed something having been posted / committed... Jan From xen-devel-bounces@lists.xenproject.org Wed Jun 24 16:13:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 16:13:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo81T-0005gb-LT; Wed, 24 Jun 2020 16:13:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo81S-0005gW-Gb for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 16:13:14 +0000 X-Inumbo-ID: 9a40cc1c-b635-11ea-bca7-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9a40cc1c-b635-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 16:13:13 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 3q/Y9jAAVV94qTQ8qYScgwfyCTY592c/gOfCIodNB6Gi3DckVJY7YfWRIsLw2J/rJYKqFKxiQM BB32XvysFofVEJypKSwwg7v9hy3+wVHwn25HAVKyvnpRMQ6jt+4CB6r5Rl3grwJszGRkQVlDdw CnQX9o8yL/PBTZUB/oO6Vkq1ea/gM2vCXlt/4kZu4H566ixqmgs8AZtXXCzonAA6Jl0GY6fS9R kxC+kR27/KopK7FJ9vlSqUpvexwN0EZ0i//lR8MRn6Wnl/Vva/2jpyZYqzyM1+z2bbRB92urFq Mls= X-SBRS: 2.7 X-MesageID: 21146182 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,275,1589256000"; d="scan'208";a="21146182" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24307.31637.214096.240023@mariner.uk.xensource.com> Date: Wed, 24 Jun 2020 17:13:09 +0100 To: Subject: Proposal: rename xen.git#master (to #trunk, perhaps) X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: committers@xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" I think it would be a good idea to rename this branch name. This name has unfortunate associations[1], even if it can be argued[2] that the etymology is not as bad as in some uses of the word. This is relativity straightforward on a technical level and will involve a minimum of inconvenience. Since only osstest ever pushes to xen.git#master, we could easily make a new branch name and also keep #master for compatibility as long as we like. The effects[1] would be: Users who did "git clone https://xenbits.xen.org/git-http/xen.git"" would find themselves on a branch called "trunk" which tracked "origin/trunk", by default. (Some users with old versions of git using old protocols would still end up on "master".) Everyone who currently tracks "master" would be able to switch to tracking "trunk" at their leisure. Presumably at some future point (a year or two from now, say) we would abolish the name "master". Comments ? In particular, comments on: 1. What the new branch name should be called. Suggestions I have seen include "trunk" and "main". I suggest "trunk" because this was used by SVN, CVS, RCS, CSSC (and therefore probably SCCS) for this same purpose. 2. Do we want to set a time now when the old name will be removed ? I think 12 months would be good but I am open to arguments. In any case in my capacity as osstest maintainer I plan to do something like this. The starting point is rather different. There will have to be an announcement about that, but I thought I would see what people thought about xen.git before pressing ahead there. Thanks, Ian. [1] It seems that for a significant number of people the word reminds them of human slavery. This seems undesirable if we can easily avoid it, if we can. [2] The precise etymology of "master" in this context is unclear. It appears to have come from BitKeeper originally. In any case the etymology is less important than the connotations. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 16:19:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 16:19:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo87j-0005xs-Bw; Wed, 24 Jun 2020 16:19:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo87i-0005xn-1C for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 16:19:42 +0000 X-Inumbo-ID: 818c1964-b636-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 818c1964-b636-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 16:19:41 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: uas/xXVt+4AcmAKP1VNu1dvnjXMglspU4h6VpuY1tkC+ehM7mbzL4UeCZugdtid4QOath1VofJ w9SCIoKFek7dak6ftHRFg4Bu6QD9LsA2JY7O99MU2QGel9HHZ1AK5+ytq0CHosma1sQak2p+Oc aZb8gTwCHsAYIEpbT0bgX2Bgikf3hzpM85ofnLf34k6B1eboMOuKX2f69cIr9qLarGgqT6fxjl sletYTA23AHMQG4LEjurfsp/B9hQzoJYAoDanRnhf8cDvi3kvB/W2yX822lu2Q63xG6aJjSRie V7Q= X-SBRS: 2.7 X-MesageID: 20841141 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,275,1589256000"; d="scan'208";a="20841141" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24307.32018.502303.817846@mariner.uk.xensource.com> Date: Wed, 24 Jun 2020 17:19:30 +0100 To: Jan Beulich Subject: [XEN RFC for-4.14] Re: use of "stat -" In-Reply-To: <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jason Andryuk , Elliott Mitchell , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jan Beulich writes ("Re: use of "stat -""): > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments unless you have verified the sender and know the content is safe. > On 14.05.2020 13:02, Ian Jackson wrote: > > I've read this thread. Jan, I'm sorry that this causes you > > inconvenience. I'm hoping it won't come down to a choice between > > supporting people who want to ship a dom0 without perl, and people who > > want a dom0 using more-than-a-decade-old coreutils. > > > > Jan, can you tell me what the output is of this on your ancient > > system: > > > > $ rm -f t > > $ >t > > $ exec 3 > $ stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 393549 > > $ rm t > > $ stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 393549 > > $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 > > $ > > $ rm -f t > $ >t > $ exec 3 $ stat -L -c '%F %i' /dev/stdin <&3 > regular empty file 3380369 > $ rm t > $ stat -L -c '%F %i' /dev/stdin <&3 > regular empty file 3380369 > $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 > regular empty file 3380369 > > > Also, the contents of the file "u" afterwards, please. > > Attached. Thanks. I think this means that `stat -' can be replaced by `stat /dev/stdin'. This script is only run on Linux where /dev/stdin has existed basically forever. The strace output shows stat("/dev/stdin", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 and the transcript shows that your stat(1) behaves as I hope. Jan, will you send a patch ? It is best if someone else but me writes it and tests it because then I am a "clean" reviewer. Paul, supposing I review such a patch and say it is low risk, and we commit it by Friday, can it have a release-ack ? Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 16:32:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 16:32:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8K8-0007bP-HU; Wed, 24 Jun 2020 16:32:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8K6-0007bK-Ru for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 16:32:30 +0000 X-Inumbo-ID: 4acca374-b638-11ea-8107-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 4acca374-b638-11ea-8107-12813bfff9fa; Wed, 24 Jun 2020 16:32:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EL1iU1l+KKz6CyMGnWxoKqlxFtC1zkRlDmFuURFPsLw=; b=gzeyvXs1GGwow8o6/YwPJLyfF uGzdUuQSC3MITxuS3sTZ5RPyMu0BeRB34s6+y8XoXp2x5u6iAIg0xhFR5PVcfIcNHUTOVZ5SbZoQZ Xm1asU8yYwtYHVY0gw20c1JAQ2YjwVE3i3d3LvogGkHWReixDR1RPA2CNxGQF2MKOi4xs=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8K3-00063N-CQ; Wed, 24 Jun 2020 16:32:27 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jo8K3-0002BM-3a; Wed, 24 Jun 2020 16:32:27 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jo8K3-0007X5-2w; Wed, 24 Jun 2020 16:32:27 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151316: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=06760c2bf322cef4622b56bafee74fe93ae01630 X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Wed, 24 Jun 2020 16:32:27 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151316 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151316/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 Tests which did not succeed, but are not blocking: test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 06760c2bf322cef4622b56bafee74fe93ae01630 baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 41 days Failing since 150943 2020-06-09 17:06:00 Z 14 days 13 attempts Testing same since 151161 2020-06-15 22:27:38 Z 8 days 7 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Julien Grall Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 06760c2bf322cef4622b56bafee74fe93ae01630 Author: Andrew Cooper Date: Fri Jun 12 18:32:27 2020 +0100 tools/libxl: Fix memory leak in libxl_cpuid_set() xc_cpuid_set() returns allocated memory via cpuid_res, which libxl needs to free() seeing as it discards the results. This is logically a backport of c/s b91825f628 "tools/libxc: Drop config_transformed parameter from xc_cpuid_set()" but rewritten as one caller of xc_cpuid_set() does use returned values. Signed-off-by: Andrew Cooper (cherry picked from commit c54de7d9df7718ea53bf21e1ff5bbd339602a704) commit d58c48df8c6ca819f5e6e6f1740bb114f24f024f Author: Andrew Cooper Date: Wed Jun 10 18:57:00 2020 +0100 x86/spec-ctrl: Allow the RDRAND/RDSEED features to be hidden RDRAND/RDSEED can be hidden using cpuid= to mitigate SRBDS if microcode isn't available. This is part of XSA-320 / CVE-2020-0543. Signed-off-by: Andrew Cooper Acked-by: Julien Grall (cherry picked from commit 7028534d8482d25860c4d1aa8e45f0b911abfc5a) commit 199ae1f15894bd1bdefdf7c3e44688127be3ba19 Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel See patch documentation and comments. This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich (cherry picked from commit 6a49b9a7920c82015381740905582b666160d955) commit 9dc284294017c7206bd09223090d49003f6c71db Author: Andrew Cooper Date: Wed Jan 8 19:47:46 2020 +0000 x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling This is part of XSA-320 / CVE-2020-0543 Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Acked-by: Wei Liu (cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3) (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Wed Jun 24 16:41:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 16:41:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8Sh-00008Z-JO; Wed, 24 Jun 2020 16:41:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8Sg-00008U-QV for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 16:41:22 +0000 X-Inumbo-ID: 886e4a1a-b639-11ea-bb8b-bc764e2007e4 Received: from mail-lf1-x142.google.com (unknown [2a00:1450:4864:20::142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 886e4a1a-b639-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 16:41:21 +0000 (UTC) Received: by mail-lf1-x142.google.com with SMTP id d21so1629700lfb.6 for ; Wed, 24 Jun 2020 09:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B/MCASNnVi/ALzgM3WNJvUmY0h2sFHWtkBBpH4Al5bc=; b=SUGYdJZr+bMHYsVax8gJ9zldqlptd5kT4BBRGeENSZ+lBC2aiViK4YZ21YlKWckWtj 78rogfijxVPK+wCfNKOEsnWws25VJFVUqOMZ74hBCT/b+V7//3IX5LmoPpT73wLr6UyE f9Or3PmrEO4tzctBFixp7xguO8JiV1I21ldwJUXWqgFRU9s9sRiMnelghsFX1qj5r387 qN9gkK0f6h9/H7ZwGB2j0IMzDyJcMQ2UZMPvL9SCVasAlSKcpc1EoVJgatnaPih5GTGW xFlpqTdOrQIDUPF3HBr4SWcJYM9EzzINKaFEIKuenUhJwTGpyHMkKavREhDOlpHEHyfo O63A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B/MCASNnVi/ALzgM3WNJvUmY0h2sFHWtkBBpH4Al5bc=; b=UN7V1Zolw31Iydn5Ugpu1PxKmYY0Vfcu9G9Ho7t9pf7nFcudCANAmhW/uHIw6elxqd 78Oe7B6/q5RXyFHfT2k8HduxcKgGxfU2hUhhiqxdreEI9955cOsmQECHjHOJ98FLPF6m qsLls4kFc9LT5JHQG1DqXUX61hDArHHGy9u0k2aCDLWRBbtVLafQWNuo8wsh8anhmIRB lteQ2Z8cfwI8cnRFNgWDQCuP6uOBPhJbNG6H+irpf2ua0YOD7bkUdfSrLagz6CjkmfLO syexdTxq+AHtdmRaH6hoKNjJO13VM8xtYZfBz21GuPkVJ7w21AO869eAjw288TsO1qY9 QC/Q== X-Gm-Message-State: AOAM532e4otPrXRfHksrCII5qom4rS+pkJ8JKsVZVPWeI6DIvF0wvvKc xX07QKU5rzeCS3qdWtmRIhqz1RAzfmZ94W53noc= X-Google-Smtp-Source: ABdhPJyuFuqWzMzN0VCDv0hj3tUOZeuC5C7P9H6qKjUhTu9qMY0DiAXyK0/rc0u9PDV26qXkjvqHI3MZ8FO+htkdFHg= X-Received: by 2002:a19:6c6:: with SMTP id 189mr15947269lfg.94.1593016880059; Wed, 24 Jun 2020 09:41:20 -0700 (PDT) MIME-Version: 1.0 References: <1592913499-15558-1-git-send-email-jrdr.linux@gmail.com> In-Reply-To: From: Souptick Joarder Date: Wed, 24 Jun 2020 22:11:08 +0530 Message-ID: Subject: Re: [RFC PATCH v2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Boris Ostrovsky Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, paul@xen.org, John Hubbard , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 9:07 PM Boris Ostrovsky wrote: > > On 6/23/20 9:36 PM, Souptick Joarder wrote: > > On Tue, Jun 23, 2020 at 11:11 PM Boris Ostrovsky > > wrote: > >> On 6/23/20 7:58 AM, Souptick Joarder wrote: > >>> In 2019, we introduced pin_user_pages*() and now we are converting > >>> get_user_pages*() to the new API as appropriate. [1] & [2] could > >>> be referred for more information. This is case 5 as per document [1]. > >>> > >>> As discussed, pages need to be marked as dirty before unpinned it. > >>> > >>> Previously, if lock_pages() end up partially mapping pages, it used > >>> to return -ERRNO due to which unlock_pages() have to go through > >>> each pages[i] till *nr_pages* to validate them. This can be avoided > >>> by passing correct number partially mapped pages & -ERRNO separately > >>> while returning from lock_pages() due to error. > >>> With this fix unlock_pages() doesn't need to validate pages[i] till > >>> *nr_pages* for error scenario. > >> > >> This should be split into two patches please. The first one will fix the > >> return value bug (and will need to go to stable branches) and the second > >> will use new routine to pin pages. > > Initially I split the patches into 2 commits. But at last moment I > > figure out that, > > this bug fix ( better to call coding error, doesn't looks like lead to > > any runtime bug) is tightly coupled to 2nd commit for > > pin_user_pages*() conversion, > > which means we don't need the bug fix patch if we are not converting the API to > > pin_user_pages*()/ unpin_user_pages_dirty_lock(). That's the reason to > > clubbed these two > > commits into a single one. > > > I am not sure I understand why the two issues are connected. Failure of > either get_user_pages_fast() or pin_user_pages() will result in the same > kind of overall ioctl failure, won't it? > Sorry, I think, I need to go through the bug again for my clarity. My understanding is -> First, In case of success lock_pages() returns 0, so what privcmd_ioctl_dm_op() will return to user is depend on the return value of HYPERVISOR_dm_op() and at last all the pages are unpinned. At present I am not clear about the return value of HYPERVISOR_dm_op(). But this path of code looks to be correct. second, incase of failure from lock_pages() will return either -ENOSPC / -ERRNO receive from {get|pin|_user_pages_fast() inside for loop. (at that point there might be some partially mapped pages as it is mapping inside the loop). Upon receiving -ERRNO privcmd_ioctl_dm_op() will pass the same -ERRNO to user (not the partial mapped page count). This looks to be correct behaviour from user space. The problem I was trying to address is, in the second scenario when lock_pages() returns -ERRNO and there are already existing mapped pages. In this scenario, when unlcok_pages() is called it will iterate till *nr_pages* to validate and unmap the pages. But it is supposed to unmap only the mapped pages which I am trying to address as part of bug fix. Let me know if I am able to be in sync with what you are expecting ? > One concern though is that we are changing how user will see this error. My understanding from above is user will always see right -ERRNO and will not be impacted. Another scenario I was thinking, if {get|pin|_user_pages_fast() return number of pages pinned which may be fewer than the number requested. Then lock_pages() returns 0 to caller and caller/user space will continue with the assumption that all pages are pinned correctly. Is this an expected behaviour as per current code ? > Currently Xen devicemodel (which AFAIK is the only caller) ignores it, > which is I think is wrong. So another option would be to fix this in Xen > and continue returning positive number here. I guess it's back to Paul > again. > > > -boris > > From xen-devel-bounces@lists.xenproject.org Wed Jun 24 16:53:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 16:53:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8eK-00019z-PR; Wed, 24 Jun 2020 16:53:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8eJ-00019t-2f for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 16:53:23 +0000 X-Inumbo-ID: 36007e40-b63b-11ea-b7bb-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 36007e40-b63b-11ea-b7bb-bc764e2007e4; Wed, 24 Jun 2020 16:53:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593017601; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WvZEfGLkbje2PmwPmlxywRP8vofYtAWH0NIC79T30BQ=; b=T5u8+bJK7xVfhUp6hnp3J648p9aPi81ToJQuwMR6b1Y9KikBdmb6EJ9UqvLnVJDtMg4481 aZC71YfLPLQbGDUhDK4mmC8PqHahtvdQZKgaVI81+f/RbeKJBs59lcSU+9bIKo9fYY9eUZ d+pIqQ2QsVkoszLakIPL5G42dYF0y04= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-154-fhQgBarZM0CRByrgSGD7Rg-1; Wed, 24 Jun 2020 12:53:17 -0400 X-MC-Unique: fhQgBarZM0CRByrgSGD7Rg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0E474107ACCD; Wed, 24 Jun 2020 16:53:15 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-112-121.ams2.redhat.com [10.36.112.121]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 375B65C66E; Wed, 24 Jun 2020 16:53:07 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id B781A11384D4; Wed, 24 Jun 2020 18:53:05 +0200 (CEST) From: Markus Armbruster To: Greg Kurz Subject: Re: [PATCH v10 1/9] error: auto propagated local_err References: <20200317151625.20797-1-vsementsov@virtuozzo.com> <20200317151625.20797-2-vsementsov@virtuozzo.com> <20200610163921.28d824aa@bahia.lan> <877dw8dhvk.fsf@dusky.pond.sub.org> <20200615083835.54e3fcb1@bahia.lan> Date: Wed, 24 Jun 2020 18:53:05 +0200 In-Reply-To: <20200615083835.54e3fcb1@bahia.lan> (Greg Kurz's message of "Mon, 15 Jun 2020 08:38:35 +0200") Message-ID: <87k0zw8ky6.fsf@dusky.pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Vladimir Sementsov-Ogievskiy , qemu-block@nongnu.org, Paul Durrant , Laszlo Ersek , Christian Schoenebeck , Michael Roth , qemu-devel@nongnu.org, Stefano Stabellini , Gerd Hoffmann , Stefan Hajnoczi , Anthony Perard , xen-devel@lists.xenproject.org, Max Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Stefan Berger Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Greg Kurz writes: > On Mon, 15 Jun 2020 07:21:03 +0200 > Markus Armbruster wrote: > >> Greg Kurz writes: >> >> > On Tue, 17 Mar 2020 18:16:17 +0300 >> > Vladimir Sementsov-Ogievskiy wrote: >> > >> >> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of >> >> functions with an errp OUT parameter. >> >> >> >> It has three goals: >> >> >> >> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user >> >> can't see this additional information, because exit() happens in >> >> error_setg earlier than information is added. [Reported by Greg Kurz] >> >> >> > >> > I have more of these coming and I'd really like to use ERRP_AUTO_PROPAGATE. >> > >> > It seems we have a consensus on the macro itself but this series is gated >> > by the conversion of the existing code base. >> > >> > What about merging this patch separately so that people can start using >> > it at least ? >> >> Please give me a few more days to finish the work I feel should go in >> before the conversion. With any luck, Vladimir can then rebase / >> recreate the conversion easily, and you can finally use the macro for >> your own work. >> > > Sure. Thanks. Just posted "[PATCH 00/46] Less clumsy error checking". The sheer size of the thing and the length of its dependency chain explains why it took me so long. I feel bad about delaying you all the same. Apologies! I hope we can converge quickly enough to get Vladimir's work on top ready in time for the soft freeze. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 17:05:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 17:05:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8ps-0002BO-Un; Wed, 24 Jun 2020 17:05:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8pr-0002BJ-H3 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 17:05:19 +0000 X-Inumbo-ID: e1570683-b63c-11ea-8110-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e1570683-b63c-11ea-8110-12813bfff9fa; Wed, 24 Jun 2020 17:05:18 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A570F20578; Wed, 24 Jun 2020 17:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593018318; bh=/UnoLMxQONCLkO5gVNRqe1RRYpEGc4XdR1M7cDuR7wU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=eziwITDIF+H1hXY9h2BK/lfMeYS1S49w7sbf7HlS/Du8UZVzKP1an8MAbwK2CTiNz BbnVzGxbJ4AZ27KNCUpsGE7xkBTAOVaJC8SBsNRLI/JZjxNyfhZeyegqqAeDqawpOP 94fWFUQAE27WOIBUiCH9Y/WSyBtbWZsC8Yyp4RFk= Date: Wed, 24 Jun 2020 10:05:17 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Oleksandr Andrushchenko Subject: Re: UEFI support in ARM DomUs In-Reply-To: Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Stefano Stabellini , Julien Grall , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote: > On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote: > > > > On 6/23/20 4:20 AM, Stefano Stabellini wrote: > >> On Mon, 22 Jun 2020, Julien Grall wrote: > >>>>>> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it > >>>>>> via > >>>>>> > >>>>>> CFLAGS or something. This can also be done for the location of Xen > >>>>>> headers. > >>>>> __XEN_INTERFACE_VERSION__ should work through the CFLAGS. An alternative > >>>>> would be to allow the user to specify through the Kconfig. > >>>> You mean specifying via Kconfig something like "0x00040d00"? > >>> Possibly yes. > >>> > >>>> And what about the headers? How will we provide their location if we decide > >>>> not to include those > >>>> > >>>> in the tree? > >>> I would do through Kconfig as well. > >> If we specify the external location of the Xen headers via Kconfig, it > >> seems to me that we should be able to detect the interface version > >> automatically from any Makefile as part of the build. No need to ask the > >> user. > >> > >> However, if Oleksandr is thinking of using the Xen headers for the > >> hypercalls definitions, then I think we might not need external headers > >> at all because that is a stable interface, as Julien wrote. We could > >> just define our own few headers for just what you need like Linux does. > > > > This is a good idea: I'll try to get the minimal set of headers from Linux > > > > instead of Xen as those seem to be well prepared for such a use-case. This > > > > way we'll have headers in U-boot tree and guarantee that we have a minimal > > > > subset which is easier to maintain. I'll keep you updated on the progress > > We've managed to strip the headers and remove __XEN__ and the rest definitions > > we were talking about. So, these are now the minimal required set of headers > > that allows U-boot to build serial and block drivers. Please take a look at [1] > > Pull request for comments is at [2] I think this is the right approach. There is no build-dependency on Xen anymore, is that correct? From xen-devel-bounces@lists.xenproject.org Wed Jun 24 17:29:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 17:29:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo9Cp-0004DI-Pk; Wed, 24 Jun 2020 17:29:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo9Cn-0004DD-Ow for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 17:29:01 +0000 X-Inumbo-ID: 3145f9ca-b640-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3145f9ca-b640-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 17:29:01 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 45E872078D; Wed, 24 Jun 2020 17:29:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593019740; bh=VQBPgH331hw6VJmPWcybMgyEHppdU/GjfLhtKGyKFBU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=kqwT8GSK6zkaZ2rwPbU7buMudcQZyfi06sTZb8a7M52z7V40+iZzni0Od3Zm8Jm65 dLsEcUoiBQ4V5jXd1+NmDbbZur05SRcVvviMioDzQsWbhq5bRvq6E+ps+QFB2qOCkh sfagmcy2SK3XRc5ffbUKEeeYnDXxUCvDVzGzQu3U= Date: Wed, 24 Jun 2020 10:28:59 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Bertrand Marquis Subject: Re: Keystone Issue In-Reply-To: <30ACA5A7-089F-45E2-9A9B-A6BC4EBBC78B@arm.com> Message-ID: References: <363A05E0-61C6-4AE4-9C84-EEAC466989D8@arm.com> <03607739-A4FF-486A-899A-F5F36870225A@arm.com> <2ec6255c-9d28-92e7-bd0a-59edb9fc078a@xen.org> <6033f9cecbf10f50f4a713ce52105426@kernel.org> <4bab90465acfddae5868ce2311bd9889@kernel.org> <30ACA5A7-089F-45E2-9A9B-A6BC4EBBC78B@arm.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Marc Zyngier , CodeWiz2280 , xen-devel , nd , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 24 Jun 2020, Bertrand Marquis wrote: > > On 23 Jun 2020, at 21:50, CodeWiz2280 wrote: > > > > Is it possible to passthrough PCI devices to domU on the 32-bit arm > > keystone? Any info is appreciated. > > > > I found some old information online that "gic-v2m" is required. I'm > > not sure if the GIC-400 on the K2E supports "gic_v2m". Based on the > > fact that there is no "gic-v2m-frame" tag in the K2E device tree i'm > > guessing that it does not. > > > > If it is possible, is there a good example for arm that I can follow? > > There is no PCI passthrough support on Arm for now in Xen. > > This is something I am working on and I will present something on this subject at the Xen summit. > But we are not targeting arm32 for now. > > The only thing possible for now is to have PCI devices handled by Dom0 and using xen virtual drivers to pass the functionalities (ethernet, block or others). It should also possible to pass the entire PCI controller, together with the whole aperture and all interrupts to a domU. The domU would get all PCI devices this way, not just one. > > On Wed, Jun 17, 2020 at 7:52 PM CodeWiz2280 wrote: > >> > >> On Wed, Jun 17, 2020 at 2:46 PM Stefano Stabellini > >> wrote: > >>> > >>> On Wed, 17 Jun 2020, CodeWiz2280 wrote: > >>>> On Tue, Jun 16, 2020 at 2:23 PM Marc Zyngier wrote: > >>>>> > >>>>> On 2020-06-16 19:13, CodeWiz2280 wrote: > >>>>>> On Tue, Jun 16, 2020 at 4:11 AM Marc Zyngier wrote: > >>>>>>> > >>>>>>> On 2020-06-15 20:14, CodeWiz2280 wrote: > >>>>>>> > >>>>>>> [...] > >>>>>>> > >>>>>>>> Also, the latest linux kernel still has the X-Gene storm distributor > >>>>>>>> address as "0x78010000" in the device tree, which is what the Xen code > >>>>>>>> considers a match with the old firmware. What were the addresses for > >>>>>>>> the device tree supposed to be changed to? > >>>>>>> > >>>>>>> We usually don't care, as the GIC address is provided by the > >>>>>>> bootloader, > >>>>>>> whether via DT or ACPI (this is certainly what happens on Mustang). > >>>>>>> Whatever is still in the kernel tree is just as dead as the platform > >>>>>>> it > >>>>>>> describes. > >>>>>>> > >>>>>>>> Is my understanding > >>>>>>>> correct that there is a different base address required to access the > >>>>>>>> "non-secure" region instead of the "secure" 0x78010000 region? I'm > >>>>>>>> trying to see if there are corresponding different addresses for the > >>>>>>>> keystone K2E, but haven't found them yet in the manuals. > >>>>>>> > >>>>>>> There is no such address. Think of the NS bit as an *address space* > >>>>>>> identifier. > >>>>>>> > >>>>>>> The only reason XGene presents the NS part of the GIC at a different > >>>>>>> address is because XGene is broken enough not to have EL3, hence no > >>>>>>> secure mode. To wire the GIC (and other standard ARM IPs) to the core, > >>>>>>> the designers simply used the CPU NS signal as an address bit. > >>>>>>> > >>>>>>> On your platform, the NS bit does exist. I strongly suppose that it > >>>>>>> isn't wired to the GIC. Please talk to your SoC vendor for whether iot > >>>>>>> is possible to work around this. > >>>>>>> > >>>>>> I do have a question about this out to TI, but at least this method > >>>>>> gives me something to work with in the meantime. I was just looking > >>>>>> to confirm that there wouldn't be any other undesirable side effects > >>>>>> with Dom0 or DomU when using it. Was there an actual FPGA for the > >>>>>> X-Gene that needed to be updated which controlled the GIC access? Or > >>>>>> by firmware do you mean the boot loader (e.g. uboot). Thanks for the > >>>>>> support so far to all. > >>>>> > >>>>> As I said, the specific case of XGene was just a matter of picking the > >>>>> right address, as the NS bit is used as an address bit on this platform. > >>>>> This was possible because this machine doesn't have any form of > >>>>> security. So no HW was changed, no FPGA reprogrammed. Only a firmware > >>>>> table was fixed to point to the right spot. Not even u-boot or EFI was > >>>>> changed. > >>>> Ok, thank you for clarifying. I have one more question if you don't > >>>> mind. I'm aware that dom0 can share physical memory with dom1 via > >>>> grant tables. > >>>> However, is it possible to reserve a chunk of contiguous physical > >>>> memory and directly allocate it only to dom1? > >>>> For example, if I wanted dom1 to have access to 8MB of contiguous > >>>> memory at 0x8200_0000 (in addition to whatever virtual memory Xen > >>>> gives it). > >>>> How would one go about doing this on ARM? Is there something in the > >>>> guest config or device tree that can be set? Thanks for you help. > >>> > >>> There isn't a "proper" way to do it, only a workaround. > >>> > >>> It is possible to do it by using the iomem option, which is meant for > >>> device MMIO regions. > >>> > >>> We have patches in the Xilinx Xen tree (not upstream) to allow for > >>> specifying the cacheability that you want for the iomem mapping so that > >>> you can map it as normal memory. This is the latest branch: > >>> > >>> https://github.com/Xilinx/xen.git xilinx/release-2020.1 > >>> > >>> The relevant commits are the ones from: > >>> https://github.com/Xilinx/xen/commit/a5c76ac1c5dc14d3e9ccedc5c1e7dd2ddc1397b6 > >>> to: > >>> https://github.com/Xilinx/xen/commit/b4b7e91c1524f9cf530b81b7ba95df2bf50c78e4 > >>> > >>> You might want to make sure that the page is not used by the normal > >>> memory allocator. This document explains how to something along those > >>> lines: > >>> > >>> https://github.com/Xilinx/xen/commit/35f72d9130448272e07466bd73cc30406f33135e > >> > >> Thank you. I appreciate it. > From xen-devel-bounces@lists.xenproject.org Wed Jun 24 17:39:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 17:39:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo9MM-0005Bd-P5; Wed, 24 Jun 2020 17:38:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo9MM-0005BY-FD for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 17:38:54 +0000 X-Inumbo-ID: 929f6372-b641-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 929f6372-b641-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 17:38:54 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 482A020738; Wed, 24 Jun 2020 17:38:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593020333; bh=WuhI4uKb4526KIgvM6MGTVfy4+zQ6hMQVJdu/Dc1vSs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=L3osd+1hh+35SpgbB4I+oxd7To+GfbeBMdU7KSmdZ4An5bM4izXAHTtxJW8UnTfiS HD6fWVfgJSIFFj3GaI2go3Z93tFmc2jkbgU3BDd2grRHax92dG0tNqAEyoTqZ9j8Oy L/j4ZCYgLM/urX3RHtL7lsQWRWd3WvUkz2M9OI+E= Date: Wed, 24 Jun 2020 10:38:52 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Ian Jackson Subject: Re: Proposal: rename xen.git#master (to #trunk, perhaps) In-Reply-To: <24307.31637.214096.240023@mariner.uk.xensource.com> Message-ID: References: <24307.31637.214096.240023@mariner.uk.xensource.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, committers@xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 24 Jun 2020, Ian Jackson wrote: > I think it would be a good idea to rename this branch name. This name > has unfortunate associations[1], even if it can be argued[2] that the > etymology is not as bad as in some uses of the word. > > This is relativity straightforward on a technical level and will > involve a minimum of inconvenience. Since only osstest ever pushes to > xen.git#master, we could easily make a new branch name and also keep > #master for compatibility as long as we like. > > The effects[1] would be: > > Users who did "git clone https://xenbits.xen.org/git-http/xen.git"" > would find themselves on a branch called "trunk" which tracked > "origin/trunk", by default. (Some users with old versions of git > using old protocols would still end up on "master".) > > Everyone who currently tracks "master" would be able to switch to > tracking "trunk" at their leisure. > > Presumably at some future point (a year or two from now, say) we would > abolish the name "master". > > Comments ? In particular, comments on: > > 1. What the new branch name should be called. Suggestions I have seen > include "trunk" and "main". I suggest "trunk" because this was used > by SVN, CVS, RCS, CSSC (and therefore probably SCCS) for this same > purpose. Github seems to be about to make a similar change. I wonder if we should wait just a couple of weeks to see what name they are going to choose. https://www.theregister.com/2020/06/15/github_replaces_master_with_main/ Of course I don't particulalry care one way or the other, but it would be good if we end up using the same name as everybody else. It is not that we have to choose the name Github is going to choose, but their user base is massive -- whatever they are going to pick is very likely going to stick. > 2. Do we want to set a time now when the old name will be removed ? > I think 12 months would be good but I am open to arguments. > > In any case in my capacity as osstest maintainer I plan to do > something like this. The starting point is rather different. There > will have to be an announcement about that, but I thought I would see > what people thought about xen.git before pressing ahead there. > > Thanks, > Ian. > > [1] It seems that for a significant number of people the word reminds > them of human slavery. This seems undesirable if we can easily avoid > it, if we can. > > [2] The precise etymology of "master" in this context is unclear. It > appears to have come from BitKeeper originally. In any case the > etymology is less important than the connotations. > From xen-devel-bounces@lists.xenproject.org Wed Jun 24 17:57:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 17:57:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo9dx-00072A-RQ; Wed, 24 Jun 2020 17:57:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo9dw-000723-Nz for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 17:57:04 +0000 X-Inumbo-ID: 1bca9e30-b644-11ea-8117-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.81]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 1bca9e30-b644-11ea-8117-12813bfff9fa; Wed, 24 Jun 2020 17:57:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593021422; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PEjyCUyE3sWVZkGYeKg9uWZfDhdSTHNNM4bGtfd+Xg4=; b=agotZ85QLqSCJ/gvIcYNGyJI3gaLcXC1uiZTRNXtgwHsyEvUfE797knzrK6gh4NQfmdXd/ Y/eJYvz60PmimnR75qsd4mt6Qo8JZzoxCTpiKQhkfO46OHIWABjIeixX8wbuJTodJcpQ9P axEpQN55meAbXjqmY+c5bI+bSCEtU2A= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-63-DH3F2a6MOI6snMh9HIjN3A-1; Wed, 24 Jun 2020 13:56:58 -0400 X-MC-Unique: DH3F2a6MOI6snMh9HIjN3A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 11116800C64; Wed, 24 Jun 2020 17:56:57 +0000 (UTC) Received: from work-vm (ovpn-112-192.ams2.redhat.com [10.36.112.192]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C03715C557; Wed, 24 Jun 2020 17:56:55 +0000 (UTC) Date: Wed, 24 Jun 2020 18:56:53 +0100 From: "Dr. David Alan Gilbert" To: Jason Andryuk Subject: Re: Migration vmdesc and xen-save-devices-state Message-ID: <20200624175653.GA49433@work-vm> References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.14.3 (2020-06-14) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dgilbert@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , QEMU , zhang.zhanghailiang@huawei.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" * Jason Andryuk (jandryuk@gmail.com) wrote: > Hi, > > At some point, QEMU changed to add a json VM description (vmdesc) > after the migration data. The vmdesc is not needed to restore the > migration data, but qemu_loadvm_state() will read and discard the > vmdesc to clear the stream when should_send_vmdesc() is true. About 5 years ago :-) > xen-save-devices-state generates its migration data without a vmdesc. > xen-load-devices-state in turn calls qemu_loadvm_state() which tries > to load vmdesc since should_send_vmdesc is true for xen. When > restoring from a file, this is fine since it'll return EOF, print > "Expected vmdescription section, but got 0" and end the restore > successfully. > > Linux stubdoms load their migration data over a console, so they don't > hit the EOF and end up waiting. There does seem to be a timeout > though and restore continues after a delay, but we'd like to eliminate > the delay. > > Two options to address this are to either: > 1) set suppress_vmdesc for the Xen machines to bypass the > should_send_vmdesc() check. > or > 2) just send the vmdesc data. > > Since vmdesc is just discarded, maybe #1 should be followed. #1 does sound simple! > If going with #2, qemu_save_device_state() needs to generate the > vmdesc data. Looking at qemu_save_device_state() and > qemu_savevm_state_complete_precopy_non_iterable(), they are both very > similar and could seemingly be merged. qmp_xen_save_devices_state() > could even leverage the bdrv_inactivate_all() call in > qemu_savevm_state_complete_precopy_non_iterable(). > > The would make qemu_save_device_state a little more heavywight, which > could impact COLO. I'm not sure how performance sensitive the COLO > code is, and I haven't measured anything. COLO snapshots are potentially quite sensitive; although we've got a load of other things we could do with speeding up, we could do without making them noticably heavier. Dave > Does anyone have thoughts or opinions on the subject? > > Thanks, > Jason > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK From xen-devel-bounces@lists.xenproject.org Wed Jun 24 17:59:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 17:59:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo9gd-0007Eb-A2; Wed, 24 Jun 2020 17:59:51 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jo9gc-0007EV-13 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 17:59:50 +0000 X-Inumbo-ID: 7eef0064-b644-11ea-8117-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7eef0064-b644-11ea-8117-12813bfff9fa; Wed, 24 Jun 2020 17:59:49 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 47F00207DD; Wed, 24 Jun 2020 17:59:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593021588; bh=lqF4UvFTuSVPWPvYKcQ8+owOKSTEFacagpA6y42+2I4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2OyEwIQ2W+yC8MeIiJn+zg6EpblYaMgeW1W2KIyhIYSiWBv27LoWjQc7whL/xeVKv y88icKjpG7HCb5h5QohX0bjtTPKL9DqECdzfBD8KC9GTdN07U3EonUUVOnBxKcXHUo yqYasuZpBgXc5lZj44gwka4tdlhLxCPXuN8CH3H4= Date: Wed, 24 Jun 2020 10:59:47 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: "Michael S. Tsirkin" Subject: Re: [PATCH] xen: introduce xen_vring_use_dma In-Reply-To: <20200624050355-mutt-send-email-mst@kernel.org> Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Peng Fan , sstabellini@kernel.org, konrad.wilk@oracle.com, jasowang@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, linux-imx@nxp.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > Export xen_swiotlb for all platforms using xen swiotlb > > > > Use xen_swiotlb to determine when vring should use dma APIs to map the > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > disabled, it is not required. > > > > Signed-off-by: Peng Fan > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > Xen was there first, but everyone else is using that now. Unfortunately it is complicated and it is not related to VIRTIO_F_IOMMU_PLATFORM :-( The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate foreign mappings (memory coming from other VMs) to physical addresses. On x86, it also uses dma_ops to translate Linux's idea of a physical address into a real physical address (this is unneeded on ARM.) So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 always and on Xen/ARM if Linux is Dom0 (because it has foreign mappings.) That is why we have the if (xen_domain) return true; in vring_use_dma_api. You might have noticed that I missed one possible case above: Xen/ARM DomU :-) Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if (xen_domain) return true; would give the wrong answer in that case. Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and the "normal" dma_ops fail. The solution I suggested was to make the check in vring_use_dma_api more flexible by returning true if the swiotlb_xen is supposed to be used, not in general for all Xen domains, because that is what the check was really meant to do. In this regards I have two more comments: - the comment on top of the check in vring_use_dma_api is still valid - the patch looks broken on x86: it should always return true, but it returns false instead > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > index a2de775801af..768afd79f67a 100644 > > --- a/drivers/virtio/virtio_ring.c > > +++ b/drivers/virtio/virtio_ring.c > > @@ -252,7 +252,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev) > > * the DMA API if we're a Xen guest, which at least allows > > * all of the sensible Xen configurations to work correctly. > > */ > > - if (xen_domain()) > > + if (xen_vring_use_dma()) > > return true; > > > > return false; > > > The comment above this should probably be fixed. > From xen-devel-bounces@lists.xenproject.org Wed Jun 24 18:40:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 18:40:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joAJl-0003Po-U1; Wed, 24 Jun 2020 18:40:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joAJk-0003Pg-Ei for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 18:40:16 +0000 X-Inumbo-ID: 255ab696-b64a-11ea-bb8b-bc764e2007e4 Received: from mail-qt1-x842.google.com (unknown [2607:f8b0:4864:20::842]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 255ab696-b64a-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 18:40:15 +0000 (UTC) Received: by mail-qt1-x842.google.com with SMTP id z2so2531938qts.5 for ; Wed, 24 Jun 2020 11:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zededa.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VoEjUlJkS7K4ydt2Ps92mPD1TlivKF5y/ZjyuI5GKLU=; b=NstNfqfwjXF7T67cFXATN4XVyVAZrt7GkME+th9bzJVEM0bsZ0fvVuY3EYWInBiNe0 7hGHKVPeyDgEdiX3D3g8wVHePDlfSFXmZFR2T/wD0RX03fU5Tm46YIdYBazlLihst7Rs Otvsbx/ukDqSjHVaD4gR6PKym1cMI3Iof71CXbdYC0RRzOeBnNrPdsvOv9oTjqZxv0GH 6Y1vOuNg1QYKVRc9MucnyGAVPm1htFbPfxbMkWyToJHIBmXA66hA5uO4obrmLtEfbjPs ziaQ10+WjgMOhOw7jPBVKh3qezgBssCAZZJPR5Pk8VsU8UxoYyKEw7zZLMVNCX0WskFe HLHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VoEjUlJkS7K4ydt2Ps92mPD1TlivKF5y/ZjyuI5GKLU=; b=aQT/BuXJdrlOOhKP37ctkrClBP33pcwXebIgEiEyRuyACQ635PG3Z7y+mGCBh/TLxX zFJ39FOUibjffzTMvLWNc/0WM6SLbxRt+o1wI5owqgchh+U98/7f77eQZWm7/DAXmbsy YOFLDcd7brD1PTkHmnPmww5oU6ftsB/VLca0raoCNXWMEvDjdkv/g4qhaCJCUaiVeHzc sN6yz/1uwhjLjD8WLZp4aARzURuiuiIZ3tJEX0t+LW4CV7g1+EXsAvePp1hDAY+E2ubh M+Aonl2vyv+g29Ox8XAasYV8urAV7YQE+llfuwpwo3guABgRppQ+JwIv7P5ftH+TOGdj Rftg== X-Gm-Message-State: AOAM532VPiy8C2lxn2xbD6o7dPB3z/Ql8DyAdAmtivyMJfbarZ8+vxsu 352IwhUoJWLhX6Yv6QvxRP48Tkd7uZ1g3EJoaHVDew== X-Google-Smtp-Source: ABdhPJzH77jNmTePzO35cS43Um/S9NGkiCLFpDnxXb6EoXT0HL2PIpESw5+WyFZ6k3XILG8DW1Mt2ySJ988kYksUHmc= X-Received: by 2002:aed:3883:: with SMTP id k3mr13168924qte.365.1593024015547; Wed, 24 Jun 2020 11:40:15 -0700 (PDT) MIME-Version: 1.0 References: <24307.31637.214096.240023@mariner.uk.xensource.com> In-Reply-To: From: Roman Shaposhnik Date: Wed, 24 Jun 2020 11:40:04 -0700 Message-ID: Subject: Re: Proposal: rename xen.git#master (to #trunk, perhaps) To: Stefano Stabellini Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , committers@xenproject.org, Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 10:39 AM Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Ian Jackson wrote: > > I think it would be a good idea to rename this branch name. This name > > has unfortunate associations[1], even if it can be argued[2] that the > > etymology is not as bad as in some uses of the word. > > > > This is relativity straightforward on a technical level and will > > involve a minimum of inconvenience. Since only osstest ever pushes to > > xen.git#master, we could easily make a new branch name and also keep > > #master for compatibility as long as we like. > > > > The effects[1] would be: > > > > Users who did "git clone https://xenbits.xen.org/git-http/xen.git"" > > would find themselves on a branch called "trunk" which tracked > > "origin/trunk", by default. (Some users with old versions of git > > using old protocols would still end up on "master".) > > > > Everyone who currently tracks "master" would be able to switch to > > tracking "trunk" at their leisure. > > > > Presumably at some future point (a year or two from now, say) we would > > abolish the name "master". > > > > Comments ? In particular, comments on: > > > > 1. What the new branch name should be called. Suggestions I have seen > > include "trunk" and "main". I suggest "trunk" because this was used > > by SVN, CVS, RCS, CSSC (and therefore probably SCCS) for this same > > purpose. > > Github seems to be about to make a similar change. I wonder if we should > wait just a couple of weeks to see what name they are going to choose. > > https://www.theregister.com/2020/06/15/github_replaces_master_with_main/ > > > Of course I don't particulalry care one way or the other, but it would > be good if we end up using the same name as everybody else. It is not > that we have to choose the name Github is going to choose, but their > user base is massive -- whatever they are going to pick is very likely > going to stick. +1 to Stefano's way of thinking here -- that's exactly what we're doing in some of the other LF projects I'm involved in. Of course all the master/slave terminology has to be addresses at the project level -- but I haven't come across much of that in my Xen hacking Thanks, Roman. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 19:31:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 19:31:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joB7Q-00088Q-UT; Wed, 24 Jun 2020 19:31:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joB7P-00088L-BW for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 19:31:35 +0000 X-Inumbo-ID: 4fd455ba-b651-11ea-bb8b-bc764e2007e4 Received: from EUR05-VI1-obe.outbound.protection.outlook.com (unknown [40.107.21.77]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4fd455ba-b651-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 19:31:34 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nSuxsUBgIt/hxzgPqI0PW4EXiltUo8+oDWUSHr/Zec/b1ZYAMXLrO3U4NRXOw80yq7sqwU0t6iBC4Egq6E5to1kr+7sd4KXh2L0DB0LloP9P6Kg55HMiBZpVI8fGTZDEEj5iFDKD08woLwWzitsNs7zXNJU+QjtQErmRKjsADeOqn7SSx1gXKPAfc9M6hiOp33hoTePp3e4kmnXRHpS3Lh9hEj7lJOQfD0lWls2NgMf5X7BmGth2gTepzclh1Nq/9nwcM9JA8Kb3QMITh8FWdYDrZ7Ar9K+p8241DZHH8784VzORyJljoacwsBC4ethc/aIpzVRPg+/TauTMFnirlA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bBX2+fpeC/ugVAt5hiuQeME+Rge+yTxCGULaNRegUf4=; b=CBCiH7xNAPA1RD9QmDjhQAGleUQW24gNRx1T3hR2SFv8qRgrD5HU0eU85rmqdsJQWX0tQkMSHu7HiM2GCO1T2lg/QOgzZibcgU+2EJjKivZjexLiS5LI1VUIwNLwlF0JjZ+hRhwXZN1zT1kmOtxS4q2cPfYnTYO0MAxgHq3NVlGjWaJrXn+UQA1Jg1ERCM2Sp0UG9/NdYwizQLMD/mN9K1Tj0pbGyB3xnM0yrPf/QuLj7t6iJZ6HLpVv4UVdeolHMlfg7A+YMEqu3jxmgXsrQozGsYuEIOzq4Klo8rk0BfuIgx4OvhLOqWSPS30HXb4lZOpWk4wWrpzyZGNrsPNzkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bBX2+fpeC/ugVAt5hiuQeME+Rge+yTxCGULaNRegUf4=; b=ygLZohI+E2plDGCHq3I7tHeaSiBQ6jnA/gtyxMzZGCg+PghbdOZUe1+ckhIZbsY26hSlzSrDZX2AIY74Z91oLJHED7nhJHXInX6DkWXWgOTovSPLEYiJ4KPvXTf7QXiwnL1vQbN0E6x2jR+z/gAWNUp0YXeC8RsxTXtsqwaxnPyV1crrSJJtjsy2clf+0jNp358vZKUhe02wnHb3Bg0Cj0ClziG6pncuD0rYxUIpxAyc0bBccf7tC0bvGm9dFgFOhFXC7kmkwzdXpS9/ztNxDLsipKRBEev9K46LwdVPbS/A4bDoq0xNB4Tio/jW0N8ePieImY6BbCADQHck7rRABQ== Received: from AM6PR03MB3991.eurprd03.prod.outlook.com (2603:10a6:20b:25::20) by AM6PR03MB4951.eurprd03.prod.outlook.com (2603:10a6:20b:82::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Wed, 24 Jun 2020 19:31:32 +0000 Received: from AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c]) by AM6PR03MB3991.eurprd03.prod.outlook.com ([fe80::b015:38c7:355d:1c1c%4]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 19:31:32 +0000 From: Oleksandr Andrushchenko To: Stefano Stabellini Subject: Re: UEFI support in ARM DomUs Thread-Topic: UEFI support in ARM DomUs Thread-Index: AQHWOoSI1wnhumD+IkWBnAQX9mudyajIlWsAgBVWbwCAAJ62gIAAeBOAgAANxQCAAWPDgIAEUtgAgAAGgYCAAAHAgIAANpaAgAB+IgCAAEYyAIABnlyAgAC1sYCAACjZgA== Date: Wed, 24 Jun 2020 19:31:31 +0000 Message-ID: <473beeda-15e6-dd69-e140-b4084bea3ead@epam.com> References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1167a4e3-362d-430f-3447-08d818753315 x-ms-traffictypediagnostic: AM6PR03MB4951: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ARA1NmlOkIZFI7g3VeJ96y1yKIzkZZ5xmFeIAg9xbwLB83RoONIxeLLCc/s+LkifUeoGGOX5fgrG52v5TINjpE2KrRQzanjEadGQBrTfxHJfAhtbQpwBDEDBZ7uHmfBMBJO3LrXs6ERL/F8gTk8ugt1uOeBKYCjz60h9v516WQ6ZRRNaOWR79pBCAh0yxt2CV3VLKYRmAg2imMdED9q8Nvtrd/WimEq/WES4oN49JpsbGoCeWdIU+SheNYHEVOOefvc+HSlCTW1wMvcyy7/dQQUxELRXBfLOk69kfIzd/ao8/yOcTJUgV/PhydWc7dIVI8kBA3/TuCmWjzWIHLkzHw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR03MB3991.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(376002)(396003)(136003)(39860400002)(478600001)(2906002)(6512007)(54906003)(86362001)(31696002)(36756003)(6506007)(31686004)(53546011)(2616005)(4326008)(316002)(186003)(26005)(71200400001)(7416002)(66446008)(66556008)(66476007)(6486002)(8676002)(5660300002)(66946007)(76116006)(83380400001)(8936002)(6916009)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2A0xCrVB5gIT1XIxsrbn/S2ij26u9jwRcj+0aUKneRMT9wWqN4lA7KruRaF7cRQskcshZkR2Jchk52UPkETZHAWDgpNoDxRK4e/WdejF3H+po6zskTF3MDYC2IfnMh8n4PM5+uEc+YAM5zQDoemnPocPU36Vg9TQXzva2aCPhy9F7oPn6V+9jrik6dMFDDSwuGV7YF9HwJo5rtq0d4z265tTd0UZosCGaCloAlYXM2DWp9vaEikUDJ2HK2NySMqh7AQwA+g8WpkSZ716gQ/cs1PFWqiOTadc6hEMo1n4ZtZWA4pTjDmnhrOxOQNQK3Wi35TJllMzlggciTWrO8E4/eriP6Fx3nIU2MR1q+xy4Vdpp7KQ38ehtxk5PWaP/CJ0F2JXReJMZV9RBYYrPihyiT2fpd48GWucllBwHgLFvEbF8K60HTJAcvP5ebNX+tTrGlbi/XYSc4Jixi5EopR+Gzf3QF4PJ/uQLi4N0KCtSYA= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM6PR03MB3991.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1167a4e3-362d-430f-3447-08d818753315 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 19:31:31.8524 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Zsx3E+/xgon608qoHXzW7bS0opbf/xS8J2ObQLsKE1oE78Yr7mWh0ptuutTWIG+2itKUrrd88VtKQkJVHU3bDKRJloO3lnReuB3LuBNFVbfG0Y5qLR1//uJgZMfk42Zz X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR03MB4951 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Julien Grall , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gNi8yNC8yMCA4OjA1IFBNLCBTdGVmYW5vIFN0YWJlbGxpbmkgd3JvdGU6DQo+IE9uIFdlZCwg MjQgSnVuIDIwMjAsIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPj4gT24gNi8yMy8y MCA4OjMxIEFNLCBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbyB3cm90ZToNCj4+PiBPbiA2LzIzLzIw IDQ6MjAgQU0sIFN0ZWZhbm8gU3RhYmVsbGluaSB3cm90ZToNCj4+Pj4gT24gTW9uLCAyMiBKdW4g MjAyMCwgSnVsaWVuIEdyYWxsIHdyb3RlOg0KPj4+Pj4+Pj4gRm9yIHRoZSBmaXJzdCBwYXJ0IChf X1hFTl9JTlRFUkZBQ0VfVkVSU0lPTl9fKSBJIHRoaW5rIHdlIGNhbiBwcm92aWRlIGl0DQo+Pj4+ Pj4+PiB2aWENCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBDRkxBR1Mgb3Igc29tZXRoaW5nLiBUaGlzIGNh biBhbHNvIGJlIGRvbmUgZm9yIHRoZSBsb2NhdGlvbiBvZiBYZW4NCj4+Pj4+Pj4+IGhlYWRlcnMu DQo+Pj4+Pj4+IF9fWEVOX0lOVEVSRkFDRV9WRVJTSU9OX18gc2hvdWxkIHdvcmsgdGhyb3VnaCB0 aGUgQ0ZMQUdTLiBBbiBhbHRlcm5hdGl2ZQ0KPj4+Pj4+PiB3b3VsZCBiZSB0byBhbGxvdyB0aGUg dXNlciB0byBzcGVjaWZ5IHRocm91Z2ggdGhlIEtjb25maWcuDQo+Pj4+Pj4gWW91IG1lYW4gc3Bl Y2lmeWluZyB2aWEgS2NvbmZpZyBzb21ldGhpbmcgbGlrZSAiMHgwMDA0MGQwMCI/DQo+Pj4+PiBQ b3NzaWJseSB5ZXMuDQo+Pj4+Pg0KPj4+Pj4+IEFuZCB3aGF0IGFib3V0IHRoZSBoZWFkZXJzPyBI b3cgd2lsbCB3ZSBwcm92aWRlIHRoZWlyIGxvY2F0aW9uIGlmIHdlIGRlY2lkZQ0KPj4+Pj4+IG5v dCB0byBpbmNsdWRlIHRob3NlDQo+Pj4+Pj4NCj4+Pj4+PiBpbiB0aGUgdHJlZT8NCj4+Pj4+IEkg d291bGQgZG8gdGhyb3VnaCBLY29uZmlnIGFzIHdlbGwuDQo+Pj4+IElmIHdlIHNwZWNpZnkgdGhl IGV4dGVybmFsIGxvY2F0aW9uIG9mIHRoZSBYZW4gaGVhZGVycyB2aWEgS2NvbmZpZywgaXQNCj4+ Pj4gc2VlbXMgdG8gbWUgdGhhdCB3ZSBzaG91bGQgYmUgYWJsZSB0byBkZXRlY3QgdGhlIGludGVy ZmFjZSB2ZXJzaW9uDQo+Pj4+IGF1dG9tYXRpY2FsbHkgZnJvbSBhbnkgTWFrZWZpbGUgYXMgcGFy dCBvZiB0aGUgYnVpbGQuIE5vIG5lZWQgdG8gYXNrIHRoZQ0KPj4+PiB1c2VyLg0KPj4+Pg0KPj4+ PiBIb3dldmVyLCBpZiBPbGVrc2FuZHIgaXMgdGhpbmtpbmcgb2YgdXNpbmcgdGhlIFhlbiBoZWFk ZXJzIGZvciB0aGUNCj4+Pj4gaHlwZXJjYWxscyBkZWZpbml0aW9ucywgdGhlbiBJIHRoaW5rIHdl IG1pZ2h0IG5vdCBuZWVkIGV4dGVybmFsIGhlYWRlcnMNCj4+Pj4gYXQgYWxsIGJlY2F1c2UgdGhh dCBpcyBhIHN0YWJsZSBpbnRlcmZhY2UsIGFzIEp1bGllbiB3cm90ZS4gV2UgY291bGQNCj4+Pj4g anVzdCBkZWZpbmUgb3VyIG93biBmZXcgaGVhZGVycyBmb3IganVzdCB3aGF0IHlvdSBuZWVkIGxp a2UgTGludXggZG9lcy4NCj4+PiBUaGlzIGlzIGEgZ29vZCBpZGVhOiBJJ2xsIHRyeSB0byBnZXQg dGhlIG1pbmltYWwgc2V0IG9mIGhlYWRlcnMgZnJvbSBMaW51eA0KPj4+DQo+Pj4gaW5zdGVhZCBv ZiBYZW4gYXMgdGhvc2Ugc2VlbSB0byBiZSB3ZWxsIHByZXBhcmVkIGZvciBzdWNoIGEgdXNlLWNh c2UuIFRoaXMNCj4+Pg0KPj4+IHdheSB3ZSdsbCBoYXZlIGhlYWRlcnMgaW4gVS1ib290IHRyZWUg YW5kIGd1YXJhbnRlZSB0aGF0IHdlIGhhdmUgYSBtaW5pbWFsDQo+Pj4NCj4+PiBzdWJzZXQgd2hp Y2ggaXMgZWFzaWVyIHRvIG1haW50YWluLiBJJ2xsIGtlZXAgeW91IHVwZGF0ZWQgb24gdGhlIHBy b2dyZXNzDQo+PiBXZSd2ZSBtYW5hZ2VkIHRvIHN0cmlwIHRoZSBoZWFkZXJzIGFuZCByZW1vdmUg X19YRU5fXyBhbmQgdGhlIHJlc3QgZGVmaW5pdGlvbnMNCj4+DQo+PiB3ZSB3ZXJlIHRhbGtpbmcg YWJvdXQuIFNvLCB0aGVzZSBhcmUgbm93IHRoZSBtaW5pbWFsIHJlcXVpcmVkIHNldCBvZiBoZWFk ZXJzDQo+Pg0KPj4gdGhhdCBhbGxvd3MgVS1ib290IHRvIGJ1aWxkIHNlcmlhbCBhbmQgYmxvY2sg ZHJpdmVycy4gUGxlYXNlIHRha2UgYSBsb29rIGF0IFsxXQ0KPj4NCj4+IFB1bGwgcmVxdWVzdCBm b3IgY29tbWVudHMgaXMgYXQgWzJdDQo+IEkgdGhpbmsgdGhpcyBpcyB0aGUgcmlnaHQgYXBwcm9h Y2guIFRoZXJlIGlzIG5vIGJ1aWxkLWRlcGVuZGVuY3kgb24gWGVuDQo+IGFueW1vcmUsIGlzIHRo YXQgY29ycmVjdD8NCk5vIGRlcGVuZGVuY3k= From xen-devel-bounces@lists.xenproject.org Wed Jun 24 19:47:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 19:47:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joBMu-0000sQ-Dd; Wed, 24 Jun 2020 19:47:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joBMt-0000sL-Ne for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 19:47:35 +0000 X-Inumbo-ID: 8c9edffe-b653-11ea-8135-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8c9edffe-b653-11ea-8135-12813bfff9fa; Wed, 24 Jun 2020 19:47:35 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CAEDF2077D; Wed, 24 Jun 2020 19:47:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593028054; bh=NOgQrDFdeF9VVQe8qfEGZAUE9YhmFpPlPbe+DFvvKiA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=1Dddk7Djth11RdmvLKWQj9ZvWq7QJuAYOQxXnNv81dGGx5j0vr5QY4RMd1hdnwkBr cCDfsQ2k0vLqdSZigTUnyyXZvaX6Gsgl+hRonOXJ+5WuwtLfKljldSWBdU62uABjry TgrwqpBRJSu6q2KDyFSx+mdC+KpC11A9/29okNg8= Date: Wed, 24 Jun 2020 12:47:33 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Oleksandr Andrushchenko Subject: Re: UEFI support in ARM DomUs In-Reply-To: <473beeda-15e6-dd69-e140-b4084bea3ead@epam.com> Message-ID: References: <54dcfce1-c401-0581-8620-dc8790209a87@xen.org> <94bfe57c-c1be-62b4-3799-b90415264487@xen.org> <4ece84cf-dd68-6eb4-a0e2-e9008d264ba5@epam.com> <1a44c645-8c9a-93ce-8466-35c87eb4fca5@xen.org> <271a4db0-5ce5-ba25-65e7-107c040f5069@epam.com> <473beeda-15e6-dd69-e140-b4084bea3ead@epam.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anastasiia Lukianenko , Juergen Gross , Peng Fan , Stefano Stabellini , Julien Grall , Oleksandr Andrushchenko , Roman Shaposhnik , Bertrand Marquis , Nataliya Korovkina , Xen-devel , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote: > On 6/24/20 8:05 PM, Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Oleksandr Andrushchenko wrote: > >> On 6/23/20 8:31 AM, Oleksandr Andrushchenko wrote: > >>> On 6/23/20 4:20 AM, Stefano Stabellini wrote: > >>>> On Mon, 22 Jun 2020, Julien Grall wrote: > >>>>>>>> For the first part (__XEN_INTERFACE_VERSION__) I think we can provide it > >>>>>>>> via > >>>>>>>> > >>>>>>>> CFLAGS or something. This can also be done for the location of Xen > >>>>>>>> headers. > >>>>>>> __XEN_INTERFACE_VERSION__ should work through the CFLAGS. An alternative > >>>>>>> would be to allow the user to specify through the Kconfig. > >>>>>> You mean specifying via Kconfig something like "0x00040d00"? > >>>>> Possibly yes. > >>>>> > >>>>>> And what about the headers? How will we provide their location if we decide > >>>>>> not to include those > >>>>>> > >>>>>> in the tree? > >>>>> I would do through Kconfig as well. > >>>> If we specify the external location of the Xen headers via Kconfig, it > >>>> seems to me that we should be able to detect the interface version > >>>> automatically from any Makefile as part of the build. No need to ask the > >>>> user. > >>>> > >>>> However, if Oleksandr is thinking of using the Xen headers for the > >>>> hypercalls definitions, then I think we might not need external headers > >>>> at all because that is a stable interface, as Julien wrote. We could > >>>> just define our own few headers for just what you need like Linux does. > >>> This is a good idea: I'll try to get the minimal set of headers from Linux > >>> > >>> instead of Xen as those seem to be well prepared for such a use-case. This > >>> > >>> way we'll have headers in U-boot tree and guarantee that we have a minimal > >>> > >>> subset which is easier to maintain. I'll keep you updated on the progress > >> We've managed to strip the headers and remove __XEN__ and the rest definitions > >> > >> we were talking about. So, these are now the minimal required set of headers > >> > >> that allows U-boot to build serial and block drivers. Please take a look at [1] > >> > >> Pull request for comments is at [2] > > I think this is the right approach. There is no build-dependency on Xen > > anymore, is that correct? > > No dependency Great! From xen-devel-bounces@lists.xenproject.org Wed Jun 24 19:48:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 19:48:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joBNz-0000yH-RS; Wed, 24 Jun 2020 19:48:43 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joBNy-0000yA-Pd for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 19:48:42 +0000 X-Inumbo-ID: b46648e2-b653-11ea-8135-12813bfff9fa Received: from 4.mo177.mail-out.ovh.net (unknown [46.105.37.72]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b46648e2-b653-11ea-8135-12813bfff9fa; Wed, 24 Jun 2020 19:48:41 +0000 (UTC) Received: from player694.ha.ovh.net (unknown [10.110.208.202]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id EE1C3138AB8 for ; Wed, 24 Jun 2020 21:48:40 +0200 (CEST) Received: from kaod.org (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player694.ha.ovh.net (Postfix) with ESMTPSA id 930B213A32DC1; Wed, 24 Jun 2020 19:48:20 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-99G0038a5f312c-448d-4468-8c63-ccc9116a4c59,C444FAC41FF2550221413609A00B1E8A3B07177F) smtp.auth=groug@kaod.org Date: Wed, 24 Jun 2020 21:48:18 +0200 From: Greg Kurz To: Markus Armbruster Subject: Re: [PATCH v10 1/9] error: auto propagated local_err Message-ID: <20200624214818.2f7d7eda@bahia.lan> In-Reply-To: <87k0zw8ky6.fsf@dusky.pond.sub.org> References: <20200317151625.20797-1-vsementsov@virtuozzo.com> <20200317151625.20797-2-vsementsov@virtuozzo.com> <20200610163921.28d824aa@bahia.lan> <877dw8dhvk.fsf@dusky.pond.sub.org> <20200615083835.54e3fcb1@bahia.lan> <87k0zw8ky6.fsf@dusky.pond.sub.org> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 12544776764479609230 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudekjedgudefjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkjghfofggtgfgsehtjeertdertddvnecuhfhrohhmpefirhgvghcumfhurhiiuceoghhrohhugheskhgrohgurdhorhhgqeenucggtffrrghtthgvrhhnpeehkefhtdehgeehheejledufeekhfdvleefvdeihefhkefhudffhfeuuedvffdthfenucfkpheptddrtddrtddrtddpkedvrddvheefrddvtdekrddvgeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrieelgedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehgrhhouhhgsehkrghougdrohhrghdprhgtphhtthhopeigvghnqdguvghvvghlsehlihhsthhsrdigvghnphhrohhjvggtthdrohhrgh X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Vladimir Sementsov-Ogievskiy , qemu-block@nongnu.org, Paul Durrant , Laszlo Ersek , Christian Schoenebeck , Michael Roth , qemu-devel@nongnu.org, Stefano Stabellini , Gerd Hoffmann , Stefan Hajnoczi , Anthony Perard , xen-devel@lists.xenproject.org, Max Reitz , Philippe =?UTF-8?B?TWF0aGlldS1EYXVkw6k=?= , Stefan Berger Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 24 Jun 2020 18:53:05 +0200 Markus Armbruster wrote: > Greg Kurz writes: > > > On Mon, 15 Jun 2020 07:21:03 +0200 > > Markus Armbruster wrote: > > > >> Greg Kurz writes: > >> > >> > On Tue, 17 Mar 2020 18:16:17 +0300 > >> > Vladimir Sementsov-Ogievskiy wrote: > >> > > >> >> Introduce a new ERRP_AUTO_PROPAGATE macro, to be used at start of > >> >> functions with an errp OUT parameter. > >> >> > >> >> It has three goals: > >> >> > >> >> 1. Fix issue with error_fatal and error_prepend/error_append_hint: user > >> >> can't see this additional information, because exit() happens in > >> >> error_setg earlier than information is added. [Reported by Greg Kurz] > >> >> > >> > > >> > I have more of these coming and I'd really like to use ERRP_AUTO_PROPAGATE. > >> > > >> > It seems we have a consensus on the macro itself but this series is gated > >> > by the conversion of the existing code base. > >> > > >> > What about merging this patch separately so that people can start using > >> > it at least ? > >> > >> Please give me a few more days to finish the work I feel should go in > >> before the conversion. With any luck, Vladimir can then rebase / > >> recreate the conversion easily, and you can finally use the macro for > >> your own work. > >> > > > > Sure. Thanks. > > Just posted "[PATCH 00/46] Less clumsy error checking". The sheer size > of the thing and the length of its dependency chain explains why it took > me so long. I feel bad about delaying you all the same. Apologies! > No problem. This series of yours is impressive. Putting an end to the highjacking of the Error ** argument is really a beneficial move. > I hope we can converge quickly enough to get Vladimir's work on top > ready in time for the soft freeze. > I'll find some cycles for reviewing. Cheers, -- Greg From xen-devel-bounces@lists.xenproject.org Wed Jun 24 19:52:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 19:52:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joBRa-0001mJ-D7; Wed, 24 Jun 2020 19:52:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joBRY-0001lz-Vt for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 19:52:25 +0000 X-Inumbo-ID: 363a5598-b654-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 363a5598-b654-11ea-bca7-bc764e2007e4; Wed, 24 Jun 2020 19:52:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+XiPqnh9NN0+rSpFl3doXTnKpHODje0LatmIO5WxocI=; b=FCXS8yGtXL1oaWtGBEoIGWfQy omcenS2ch956gDQcBg4Rp6tbheeSUEaN0LKieNQneGI9OM1rHhUdQbxMtJLVIiXb56t0y/G19J6B0 o54mVh8OehRIt0EH9IkoM9TQ70Y+V0QCwaQWtMIxpi5UHUsd5ZQggB+7dt4ujIoJeqP4s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joBRS-0001Mh-Ty; Wed, 24 Jun 2020 19:52:18 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joBRS-0004lD-In; Wed, 24 Jun 2020 19:52:18 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joBRS-0001iq-I8; Wed, 24 Jun 2020 19:52:18 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151320: all pass - PUSHED X-Osstest-Versions-This: ovmf=1a992030522622c42aa063788b3276789c56c1e1 X-Osstest-Versions-That: ovmf=00b8bf7eda00fb6f0197d3968b6078cfdb4870fa From: osstest service owner Date: Wed, 24 Jun 2020 19:52:18 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151320 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151320/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 1a992030522622c42aa063788b3276789c56c1e1 baseline version: ovmf 00b8bf7eda00fb6f0197d3968b6078cfdb4870fa Last test of basis 151303 2020-06-23 01:55:28 Z 1 days Testing same since 151320 2020-06-23 22:10:13 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Chasel Chiu jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 00b8bf7eda..1a99203052 1a992030522622c42aa063788b3276789c56c1e1 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Wed Jun 24 20:35:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 20:35:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joC7A-0005ev-TG; Wed, 24 Jun 2020 20:35:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joC79-0005eb-UO for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 20:35:23 +0000 X-Inumbo-ID: 36dff362-b65a-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 36dff362-b65a-11ea-bb8b-bc764e2007e4; Wed, 24 Jun 2020 20:35:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/pIkysmQeF2PX+SUdKB1aZUVV/qXiFtt0yw+B23qiSs=; b=UxE0y26ws/C7PzY3wyKcm5z2/ ETqRrvzuwSBE0QIUw1qv2xJdDdqzOhKKIqh6TBE2bkXj+KyFTYfv1zxhWi6O08ZsKxEk/YMAPXXwO vm7YB1tvy68uuw0lHAw2pH8QST8js5weseNZS9eW1jB8MRDgD8Se3FERCGv1FifKN4rMc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joC72-0002Ep-Ot; Wed, 24 Jun 2020 20:35:16 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joC72-0006qc-Cp; Wed, 24 Jun 2020 20:35:16 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joC72-0002Lt-C9; Wed, 24 Jun 2020 20:35:16 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.11-testing test] 151318: tolerable FAIL - PUSHED X-Osstest-Failures: xen-4.11-testing:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.11-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.11-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.11-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=2b77729888fb851ab96e7f77bc854122626b4861 X-Osstest-Versions-That: xen=7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab From: osstest service owner Date: Wed, 24 Jun 2020 20:35:16 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151318 xen-4.11-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151318/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 2b77729888fb851ab96e7f77bc854122626b4861 baseline version: xen 7dd2ac39e40f0afe1cc6d879bfe65cbf19520cab Last test of basis 150040 2020-05-05 16:06:51 Z 50 days Failing since 150942 2020-06-09 17:05:43 Z 15 days 15 attempts Testing same since 151061 2020-06-12 12:25:05 Z 12 days 10 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Christopher Clark Christopher Clark Julien Grall Wei Liu Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 7dd2ac39e4..2b77729888 2b77729888fb851ab96e7f77bc854122626b4861 -> stable-4.11 From xen-devel-bounces@lists.xenproject.org Wed Jun 24 20:47:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 20:47:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joCIt-0006nE-51; Wed, 24 Jun 2020 20:47:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joCIs-0006n9-43 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 20:47:30 +0000 X-Inumbo-ID: ea736728-b65b-11ea-8496-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id ea736728-b65b-11ea-8496-bc764e2007e4; Wed, 24 Jun 2020 20:47:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593031647; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=O1reBoQYH57HQ1CEDrheXYLt8D4SLeQ87NHH75QUkc8=; b=NF2dsNPSLYo7W0d3DNoeyIVdLTNNbaMA60M8XYx9HQ+l98H+WW5j1NEUuXmPPwVryAFma9 dm4dNs7ngtCk+zwxM4GDgSyjQsyqEED1UWYl564Lch1lZ7Ua6sEgexuTCYciYjqWPPlCm6 ivgeAbpDdfyneMU3i0RbZJc31rRxL1g= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-434-PBdWqiTNO2W9O7miJpL7hg-1; Wed, 24 Jun 2020 16:47:25 -0400 X-MC-Unique: PBdWqiTNO2W9O7miJpL7hg-1 Received: by mail-wm1-f72.google.com with SMTP id a21so3877285wmd.0 for ; Wed, 24 Jun 2020 13:47:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=O1reBoQYH57HQ1CEDrheXYLt8D4SLeQ87NHH75QUkc8=; b=WZ7z9RehiMnRcNWXNGkZd7saunRaT4tn5huvb1mW8c/0D+jLSWdPuIJu+kXQWgGas2 giNSngzEyG8JWH4tdoYP8dz+7PRYO0cDuM9OA5AswVOBUthzDFrakEl+5fGHeIfnOhbX k4gyJcN7slSMRpJTE4rINIPcXrCsG5h6J4Lbjmc0vLvzPYE4q9w1uXYUgnKzHKkVJv2f X/hXSK7g9psVVnWJSX0muoDPRCsxfJhTQ025KkmbDX/uOcPe80khMK/11MESSztBFnIb qiAMovFZQkcTZi3vVZbU534I3rTA2qSNdEXOaKws6XDDfLK4onHIkEuPnz6UqoSHxEZX GOVQ== X-Gm-Message-State: AOAM532HTtI4+bcPobx6wo4cAoJLn5EBddo6nN6lULUGhAv23i4n3uAo ifB1GoNCSrncNYMbW72Q+Ii7N+2oskRPGEAbj8mAMbK8y9bKmq68k2TAgc7v4zVyanR2Ld/oFvQ YgIvZM2Is12M6uj8UxBHHqyHozg4= X-Received: by 2002:adf:ed47:: with SMTP id u7mr30096011wro.201.1593031644702; Wed, 24 Jun 2020 13:47:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxPnaDNUPfot+ph5kW9eA3bmRXVnTYtGfhIgsVyoq9C+ZHJySjaF/DLGkUFrdWo8f0RjJM2sQ== X-Received: by 2002:adf:ed47:: with SMTP id u7mr30096000wro.201.1593031644489; Wed, 24 Jun 2020 13:47:24 -0700 (PDT) Received: from redhat.com (bzq-79-182-31-92.red.bezeqint.net. [79.182.31.92]) by smtp.gmail.com with ESMTPSA id v7sm28870842wrp.45.2020.06.24.13.47.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 13:47:23 -0700 (PDT) Date: Wed, 24 Jun 2020 16:47:20 -0400 From: "Michael S. Tsirkin" To: Stefano Stabellini Subject: Re: [PATCH] xen: introduce xen_vring_use_dma Message-ID: <20200624163940-mutt-send-email-mst@kernel.org> References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Peng Fan , konrad.wilk@oracle.com, jasowang@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, linux-imx@nxp.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > Use xen_swiotlb to determine when vring should use dma APIs to map the > > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > > disabled, it is not required. > > > > > > Signed-off-by: Peng Fan > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > Xen was there first, but everyone else is using that now. > > Unfortunately it is complicated and it is not related to > VIRTIO_F_IOMMU_PLATFORM :-( > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate > foreign mappings (memory coming from other VMs) to physical addresses. > On x86, it also uses dma_ops to translate Linux's idea of a physical > address into a real physical address (this is unneeded on ARM.) > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > always and on Xen/ARM if Linux is Dom0 (because it has foreign > mappings.) That is why we have the if (xen_domain) return true; in > vring_use_dma_api. VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. Unfortunately as a result Xen never got around to properly setting VIRTIO_F_IOMMU_PLATFORM. I would like to make Xen do what everyone else is doing which is just set VIRTIO_F_IOMMU_PLATFORM and then put platform specific hacks inside DMA API. Then we can think about deprecating the Xen hack in a distance future, or hiding it behind a static branch, or something like this. > You might have noticed that I missed one possible case above: Xen/ARM > DomU :-) > > Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if > (xen_domain) return true; would give the wrong answer in that case. > Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and > the "normal" dma_ops fail. > > > The solution I suggested was to make the check in vring_use_dma_api more > flexible by returning true if the swiotlb_xen is supposed to be used, > not in general for all Xen domains, because that is what the check was > really meant to do. Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is wrong with that? > > In this regards I have two more comments: > > - the comment on top of the check in vring_use_dma_api is still valid > - the patch looks broken on x86: it should always return true, but it > returns false instead > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > index a2de775801af..768afd79f67a 100644 > > > --- a/drivers/virtio/virtio_ring.c > > > +++ b/drivers/virtio/virtio_ring.c > > > @@ -252,7 +252,7 @@ static bool vring_use_dma_api(struct virtio_device *vdev) > > > * the DMA API if we're a Xen guest, which at least allows > > > * all of the sensible Xen configurations to work correctly. > > > */ > > > - if (xen_domain()) > > > + if (xen_vring_use_dma()) > > > return true; > > > > > > return false; > > > > > > The comment above this should probably be fixed. > > > From xen-devel-bounces@lists.xenproject.org Wed Jun 24 21:54:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 21:54:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joDLE-0004aq-4Z; Wed, 24 Jun 2020 21:54:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joDLC-0004ag-2a for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 21:53:58 +0000 X-Inumbo-ID: 33c2247e-b665-11ea-814f-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 33c2247e-b665-11ea-814f-12813bfff9fa; Wed, 24 Jun 2020 21:53:56 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 821A020768; Wed, 24 Jun 2020 21:53:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593035636; bh=w8qZARSGOA9g1xMGYuTx8OCS70r3EMod3YbhLs/CK34=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XDuUefEB+KZjHyuyMUCNlxMM+3yqNwPecpJYixRBsMh9/2+yUYJvXu9AqKwlHhEhW nl7+1WfJ7OnhAhI8J5EkDPKX5Gncbb5rfv6iU3kQ8YdXx/F0D6ovpmBgoHLucdQ7/I 8F2Ziv5A/NwB7a2krphKC0K5P0pGFIklTTA1uS2k= Date: Wed, 24 Jun 2020 14:53:54 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: "Michael S. Tsirkin" Subject: Re: [PATCH] xen: introduce xen_vring_use_dma In-Reply-To: <20200624163940-mutt-send-email-mst@kernel.org> Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Peng Fan , Stefano Stabellini , konrad.wilk@oracle.com, jasowang@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, linux-imx@nxp.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > Use xen_swiotlb to determine when vring should use dma APIs to map the > > > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > > > disabled, it is not required. > > > > > > > > Signed-off-by: Peng Fan > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > Xen was there first, but everyone else is using that now. > > > > Unfortunately it is complicated and it is not related to > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate > > foreign mappings (memory coming from other VMs) to physical addresses. > > On x86, it also uses dma_ops to translate Linux's idea of a physical > > address into a real physical address (this is unneeded on ARM.) > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > > always and on Xen/ARM if Linux is Dom0 (because it has foreign > > mappings.) That is why we have the if (xen_domain) return true; in > > vring_use_dma_api. > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > Unfortunately as a result Xen never got around to > properly setting VIRTIO_F_IOMMU_PLATFORM. I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this because the usage of swiotlb_xen is not a property of virtio, it is a detail of the way Linux does Xen address translations. swiotlb-xen is used to do these translations and it is hooked into the dma_ops framework. It would be possible to have a device in hardware that is virtio-compatible and doesn't set VIRTIO_F_IOMMU_PLATFORM. The device could be directly assigned (passthrough) to a DomU. We would still have to use swiotlb_xen if Xen is running. You should think of swiotlb-xen as only internal to Linux and not related to whether the (virtual or non-virtual) hardware comes with an IOMMU or not. > > You might have noticed that I missed one possible case above: Xen/ARM > > DomU :-) > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if > > (xen_domain) return true; would give the wrong answer in that case. > > Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and > > the "normal" dma_ops fail. > > > > > > The solution I suggested was to make the check in vring_use_dma_api more > > flexible by returning true if the swiotlb_xen is supposed to be used, > > not in general for all Xen domains, because that is what the check was > > really meant to do. > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is wrong with that? swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops are the ones that are used. So you are saying, why don't we fix the default dma_ops to work with virtio? It is bad that the default dma_ops crash with virtio, so yes I think it would be good to fix that. However, even if we fixed that, the if (xen_domain()) check in vring_use_dma_api is still a problem. Alternatively we could try to work-around it from swiotlb-xen. We could enable swiotlb-xen for Xen/ARM DomUs with a different implementation so that we could leave the vring_use_dma_api check unmodified. It would be ugly because we would have to figure out from the new swiotlb-xen functions if the device is a normal device, so we have to call the regular dma_ops functions, or if the device is a virtio device, in which case there is nothing to do. I think it is undesirable but could probably be made to work. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 22:16:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 22:16:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joDh8-0006p1-Dd; Wed, 24 Jun 2020 22:16:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joDh6-0006ow-06 for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 22:16:36 +0000 X-Inumbo-ID: 5cca07bd-b668-11ea-8150-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 5cca07bd-b668-11ea-8150-12813bfff9fa; Wed, 24 Jun 2020 22:16:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593036994; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wYBrrjiMl0OQwY7HbHO2EuoBSyetaNO9eIfsg2bUWrc=; b=fY5LaNQdIs2nd5oru1s9OMvRYBNKgaTTvuS9bSBX1LSFy1ty0osDXipmxuS5M++OvsmWfQ vjHVuhxVPgPHKlj/cxk9kJez0jWWljsf9afW6AhefSk1KZP4lqbHKyMvLgVH6z2QYHggJw lzbc2Z/roXvn47G/GedODggeP73s7XQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-454-0DpC1zI_OieggqkT2pZUug-1; Wed, 24 Jun 2020 18:16:32 -0400 X-MC-Unique: 0DpC1zI_OieggqkT2pZUug-1 Received: by mail-wm1-f70.google.com with SMTP id b13so2427073wme.9 for ; Wed, 24 Jun 2020 15:16:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wYBrrjiMl0OQwY7HbHO2EuoBSyetaNO9eIfsg2bUWrc=; b=LgP/v415/LADR3p33Amb6Vw3EnYUEtfAbkTbj6R3nyMXG+iK+xSzUo0jWO5QzONNK+ 892Pyo5sXVE16YJ7dYWZQ0JEFNqJSYmOyGCq6NPIbeHZHktFwHyq3h9Y/N7NDshkk6Ir VV2Sd1CVXcc28FVmempratQN9e7xVstpnmJtecdxnCWDT4QW1asF6MPE/g/WSdXBGQgl tuCC5bEINPKQ8h43rRCerA5POJ80owEf+bQKcHtrkZlpBBd/wPiqwu/VzDMbJh7Bo5Ut kQK29wK9AEP28XG6lyQQ27OIR8v3tvmdojzs7kl3MJj/b+wJUEZxdb+vmRLKlbn+fIkX EayQ== X-Gm-Message-State: AOAM532ZEccRbjOD/wpU4ChWjor9kyaUrplfDIgE4c6YUlPgIx7pDcji VY32RjLwCk97IU6YV9Jj2AfEMit1M7NNg0nJ0lwbIRqVhQtj+26Yz+crgx3QeevP/3WsyFKJ8jp vSyCiLw7+QomZYp5e0XYWgdaiQok= X-Received: by 2002:a5d:630d:: with SMTP id i13mr29616357wru.208.1593036991413; Wed, 24 Jun 2020 15:16:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyoZZ/QqNAP1QypcHjt3mv7sAp97QrEj/Mw3Cz3gd3OBPJIW+fGMGO1Vs/5O0ZnQg6aHPyOeQ== X-Received: by 2002:a5d:630d:: with SMTP id i13mr29616327wru.208.1593036991077; Wed, 24 Jun 2020 15:16:31 -0700 (PDT) Received: from redhat.com (bzq-79-182-31-92.red.bezeqint.net. [79.182.31.92]) by smtp.gmail.com with ESMTPSA id e8sm26368886wrv.24.2020.06.24.15.16.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 15:16:30 -0700 (PDT) Date: Wed, 24 Jun 2020 18:16:26 -0400 From: "Michael S. Tsirkin" To: Stefano Stabellini Subject: Re: [PATCH] xen: introduce xen_vring_use_dma Message-ID: <20200624181026-mutt-send-email-mst@kernel.org> References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Peng Fan , konrad.wilk@oracle.com, jasowang@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, linux-imx@nxp.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote: > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma APIs to map the > > > > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > > > > disabled, it is not required. > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > > Xen was there first, but everyone else is using that now. > > > > > > Unfortunately it is complicated and it is not related to > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate > > > foreign mappings (memory coming from other VMs) to physical addresses. > > > On x86, it also uses dma_ops to translate Linux's idea of a physical > > > address into a real physical address (this is unneeded on ARM.) > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > > > always and on Xen/ARM if Linux is Dom0 (because it has foreign > > > mappings.) That is why we have the if (xen_domain) return true; in > > > vring_use_dma_api. > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > Unfortunately as a result Xen never got around to > > properly setting VIRTIO_F_IOMMU_PLATFORM. > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this because > the usage of swiotlb_xen is not a property of virtio, Basically any device without VIRTIO_F_ACCESS_PLATFORM (that is it's name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is what linux calls it) is declared as "special, don't follow normal rules for access". So yes swiotlb_xen is not a property of virtio, but what *is* a property of virtio is that it's not special, just a regular device from DMA POV. > it is a detail of > the way Linux does Xen address translations. swiotlb-xen is used to do > these translations and it is hooked into the dma_ops framework. > > It would be possible to have a device in hardware that is > virtio-compatible and doesn't set VIRTIO_F_IOMMU_PLATFORM. That device would be basically broken, since hardware can't know whether it can access all memory or not. > The device > could be directly assigned (passthrough) to a DomU. We would still > have to use swiotlb_xen if Xen is running. > > You should think of swiotlb-xen as only internal to Linux and not > related to whether the (virtual or non-virtual) hardware comes with an > IOMMU or not. IOMMU is a misnomer here. Virtio spec now calls this bit VIRTIO_F_ACCESS_PLATFORM. We should have done the same a while ago - I'll send a patch. > > > > You might have noticed that I missed one possible case above: Xen/ARM > > > DomU :-) > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if > > > (xen_domain) return true; would give the wrong answer in that case. > > > Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and > > > the "normal" dma_ops fail. > > > > > > > > > The solution I suggested was to make the check in vring_use_dma_api more > > > flexible by returning true if the swiotlb_xen is supposed to be used, > > > not in general for all Xen domains, because that is what the check was > > > really meant to do. > > > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is wrong with that? > > swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops are the > ones that are used. So you are saying, why don't we fix the default > dma_ops to work with virtio? > > It is bad that the default dma_ops crash with virtio, so yes I think it > would be good to fix that. However, even if we fixed that, the if > (xen_domain()) check in vring_use_dma_api is still a problem. Why is it a problem? It just makes virtio use DMA API. If that in turn works, problem solved. > > Alternatively we could try to work-around it from swiotlb-xen. We could > enable swiotlb-xen for Xen/ARM DomUs with a different implementation so > that we could leave the vring_use_dma_api check unmodified. > > It would be ugly because we would have to figure out from the new > swiotlb-xen functions if the device is a normal device, so we have to > call the regular dma_ops functions, or if the device is a virtio device, > in which case there is nothing to do. I think it is undesirable but > could probably be made to work. From xen-devel-bounces@lists.xenproject.org Wed Jun 24 22:34:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 22:34:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joDxp-00005v-TU; Wed, 24 Jun 2020 22:33:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joDxo-00005q-Ha for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 22:33:52 +0000 X-Inumbo-ID: c6872980-b66a-11ea-8152-12813bfff9fa Received: from userp2130.oracle.com (unknown [156.151.31.86]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c6872980-b66a-11ea-8152-12813bfff9fa; Wed, 24 Jun 2020 22:33:50 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05OMX4Zx189956; Wed, 24 Jun 2020 22:33:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=LrRRP1uISqiOLZ3r9hh9xnytMH0TB9dvWbVtsNJaXR0=; b=jbaIjS5QSNbrN7SvoxsqJAL5jAzjAm0l1p+vo0ETbc9mh4N2cpyMEf3JXf4IGZ95UZFc G6u4IyA2euN4GYgtfmdmQEWzwlwSjwy7/F8vOE4hhjm9TH8Tbd7ENL1huiSrfUXwQV2C V96vMXhjZqBKAcRSE2Lva3sqiXCAjIH6RBjsvL/g5W+v0UomgYYbaHBDS8rAbDgKhKqy 9Y9gquECazI5rK2oOJqwEWXzUXsAu4CXiUYrbztKUhBnbRNOh1qX8C+oQJVMyy12BpRQ v/Bk6PehnoDVMg3oB276FUXPGHJJo18mfRniCH4Xib+IZMuGuK+E/1Wd8K8NgFi/LNlv +Q== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 31uut5nfdd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 24 Jun 2020 22:33:47 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05OMOBkC085267; Wed, 24 Jun 2020 22:31:47 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 31uur7gnap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Jun 2020 22:31:46 +0000 Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 05OMVjS5031279; Wed, 24 Jun 2020 22:31:45 GMT Received: from [10.39.255.162] (/10.39.255.162) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Jun 2020 22:31:44 +0000 Subject: Re: [RFC PATCH v2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Souptick Joarder References: <1592913499-15558-1-git-send-email-jrdr.linux@gmail.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <1632d980-94a7-0f3b-0010-dee3a88a0a11@oracle.com> Date: Wed, 24 Jun 2020 18:31:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9662 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 adultscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006240143 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9662 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 clxscore=1015 lowpriorityscore=0 bulkscore=0 adultscore=0 spamscore=0 suspectscore=0 phishscore=0 impostorscore=0 cotscore=-2147483648 priorityscore=1501 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006240144 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, paul@xen.org, John Hubbard , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/24/20 12:41 PM, Souptick Joarder wrote: > On Wed, Jun 24, 2020 at 9:07 PM Boris Ostrovsky > wrote: >> On 6/23/20 9:36 PM, Souptick Joarder wrote: >>> On Tue, Jun 23, 2020 at 11:11 PM Boris Ostrovsky >>> wrote: >>>> On 6/23/20 7:58 AM, Souptick Joarder wrote: >>>>> In 2019, we introduced pin_user_pages*() and now we are converting >>>>> get_user_pages*() to the new API as appropriate. [1] & [2] could >>>>> be referred for more information. This is case 5 as per document [1= ]. >>>>> >>>>> As discussed, pages need to be marked as dirty before unpinned it. >>>>> >>>>> Previously, if lock_pages() end up partially mapping pages, it used= >>>>> to return -ERRNO due to which unlock_pages() have to go through >>>>> each pages[i] till *nr_pages* to validate them. This can be avoided= >>>>> by passing correct number partially mapped pages & -ERRNO separatel= y >>>>> while returning from lock_pages() due to error. >>>>> With this fix unlock_pages() doesn't need to validate pages[i] till= >>>>> *nr_pages* for error scenario. >>>> This should be split into two patches please. The first one will fix= the >>>> return value bug (and will need to go to stable branches) and the se= cond >>>> will use new routine to pin pages. >>> Initially I split the patches into 2 commits. But at last moment I >>> figure out that, >>> this bug fix ( better to call coding error, doesn't looks like lead t= o >>> any runtime bug) is tightly coupled to 2nd commit for >>> pin_user_pages*() conversion, >>> which means we don't need the bug fix patch if we are not converting = the API to >>> pin_user_pages*()/ unpin_user_pages_dirty_lock(). That's the reason t= o >>> clubbed these two >>> commits into a single one. >> >> I am not sure I understand why the two issues are connected. Failure o= f >> either get_user_pages_fast() or pin_user_pages() will result in the sa= me >> kind of overall ioctl failure, won't it? >> > Sorry, I think, I need to go through the bug again for my clarity. > > My understanding is -> > > First, In case of success lock_pages() returns 0, so what privcmd_ioctl= _dm_op() > will return to user is depend on the return value of HYPERVISOR_dm_op()= > and at last all the pages are unpinned. At present I am not clear about= the > return value of HYPERVISOR_dm_op(). But this path of code looks to be c= orrect. > > second, incase of failure from lock_pages() will return either -ENOSPC = / -ERRNO > receive from {get|pin|_user_pages_fast() inside for loop. (at that > point there might > be some partially mapped pages as it is mapping inside the loop). Upon > receiving > -ERRNO privcmd_ioctl_dm_op() will pass the same -ERRNO to user (not the= partial > mapped page count). This looks to be correct behaviour from user space.= Sigh...=C2=A0 I am sorry, you are absolutely correct. It does return -err= no on get_user_pages_fast() failure. I don't know what (or whether) I was thinking. (And so Paul, ignore my question) -boris > > The problem I was trying to address is, in the second scenario when > lock_pages() returns > -ERRNO and there are already existing mapped pages. In this scenario, > when unlcok_pages() > is called it will iterate till *nr_pages* to validate and unmap the > pages. But it is supposed to > unmap only the mapped pages which I am trying to address as part of bug= fix. > > Let me know if I am able to be in sync with what you are expecting ? > > >> One concern though is that we are changing how user will see this erro= r. > My understanding from above is user will always see right -ERRNO and > will not be impacted. > > Another scenario I was thinking, if {get|pin|_user_pages_fast() return > number of pages pinned > which may be fewer than the number requested. Then lock_pages() > returns 0 to caller > and caller/user space will continue with the assumption that all pages > are pinned correctly. > Is this an expected behaviour as per current code ? > > >> Currently Xen devicemodel (which AFAIK is the only caller) ignores it,= >> which is I think is wrong. So another option would be to fix this in X= en >> and continue returning positive number here. I guess it's back to Paul= >> again. >> >> >> -boris >> >> From xen-devel-bounces@lists.xenproject.org Wed Jun 24 23:10:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 24 Jun 2020 23:10:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joEXE-00046Q-Iu; Wed, 24 Jun 2020 23:10:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joEXD-00046L-Ai for xen-devel@lists.xenproject.org; Wed, 24 Jun 2020 23:10:27 +0000 X-Inumbo-ID: e34d0fee-b66f-11ea-b7bb-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e34d0fee-b66f-11ea-b7bb-bc764e2007e4; Wed, 24 Jun 2020 23:10:26 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /J611AyS5qmt/BkGf4dxIg6ZJ0b8Uc8mBBSzpBv+L/0GdcTlmJbVOqTuYERMweHA3s9HK4IgMf 6YLUNXtcFW/ijHSSLIvdM7lNtZvrHKd4jzvdfBi93aIWuFCsj+XLzLXi1uvxOynOcJuWNf31GJ 8hVmxVwSwmXqYvTlY6SitV/NBrp8pa17dHU0rt9vKG6xaYuArp+6513bUisIQKshkjyUe5JVg0 mC1ICDtMf7p3hbjgecJtBAD7FtO5Ql9KuzzOT/iTmJ8GxrqUqLsOK6/0fS0L0kAVY7uc75YR7q gtA= X-SBRS: 2.7 X-MesageID: 20883596 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,276,1589256000"; d="scan'208";a="20883596" Subject: Re: Proposal: rename xen.git#master (to #trunk, perhaps) To: Ian Jackson , References: <24307.31637.214096.240023@mariner.uk.xensource.com> From: Andrew Cooper Message-ID: Date: Thu, 25 Jun 2020 00:10:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <24307.31637.214096.240023@mariner.uk.xensource.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: committers@xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 24/06/2020 17:13, Ian Jackson wrote: > I think it would be a good idea to rename this branch name. The tech industry does use some problematic terms, and I fully agree with taking steps to reduce their use.  However, I disagree that this is a problematic context. In the English language, context is paramount. Terms such as master/slave have an obvious inequality bias in the context in which they are used.  There are alternatives to these terms, probably one of which is more suited to the specific scenario in question. However, the word master is a very overloaded word in terms of its different meanings. Describing someone as a "master of their trade/skill/other", is a totally different context, and it would be excessive to suggest changing the language used in this way.  So too, in my opinion, is master as in "master copy", a different context and connotation to master as in master/slave. A much more meaningful use of time would be to address: xen.git$ git grep -i -e slave -e whitelist -e blacklist | wc -l 194 two thirds of which look fairly easy to address, and one third fairly complicated due to external dependencies. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Jun 25 02:13:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 02:13:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joHNp-0004Yo-00; Thu, 25 Jun 2020 02:12:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joHNo-0004Yj-HK for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 02:12:56 +0000 X-Inumbo-ID: 60aaa8ac-b689-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 60aaa8ac-b689-11ea-8496-bc764e2007e4; Thu, 25 Jun 2020 02:12:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jv6Hn6oXbGqOY30asEod2hhy1A0FsHZq+YrbF16zfs4=; b=LG1jbR6gr63SLJHEZ56OBfKC6 CN2DyxUBcEGdaKfZMxqhB3wONWq1HJpNfryOwWDh9o/S0W22TjK9G/p8tnWGlp7W4I9udsmRD5Ne2 hEzJb7yrRSQxRMOBlDb6ZprbKW6SlK7ILPZV/MrvSQAS0OSiUWL+HV3mlPqwxi6Z1Ar4s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joHNl-0002Jy-3l; Thu, 25 Jun 2020 02:12:53 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joHNk-0004HC-Pe; Thu, 25 Jun 2020 02:12:52 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joHNk-0008LZ-Od; Thu, 25 Jun 2020 02:12:52 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151323: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=3e08a95294a4fb3702bb3d35ed08028433c37fe6 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Thu, 25 Jun 2020 02:12:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151323 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151323/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 3e08a95294a4fb3702bb3d35ed08028433c37fe6 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 6 days Failing since 151236 2020-06-19 19:10:35 Z 5 days 5 attempts Testing same since 151323 2020-06-24 00:10:00 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alex Deucher Alex Deucher Alexander Stein Alexey Budankov Andy Shevchenko Aneesh Kumar K.V Ard Biesheuvel Arnaldo Carvalho de Melo Arnd Bergmann Arvind Sankar Atish Patra Axel Lin Baolin Wang Barry Song Bartosz Golaszewski Charles Keepax Chen Zhou Chris Wilson Christian Zigotzky Christoph Hellwig Christophe Leroy Chunyan Zhang Coly Li Cornelia Huck Dan Carpenter Dan Williams Daniel Schaefer Daniel Vetter Dave Airlie Dave Martin David Howells David Sterba Denis Efremov Dinghao Liu Dmitry Baryshkov Dmitry V. Levin Drew Fustini Eric Biggers Felix Kuehling Filipe Manana Flavio Suligoi Gaurav Singh Geert Uytterhoeven Guenter Roeck Gustavo A. R. Silva Haibo Chen Heiko Carstens Heinrich Schuchardt Herbert Xu Hongbo Yao Ian Rogers Ilya Dryomov Imre Deak Ira Weiny Jack Wang Jan Kara Jason A. Donenfeld Jason Yan Jens Axboe Jens Thoms Toerring Jiri Olsa Jiri Olsa John Garry Joonas Lahtinen Julian Wiedmann Kai-Heng Feng Kaitao Cheng Kees Cook Kefeng Wang kernel test robot Keyur Patel Khaled Almahallawy Krzysztof Kozlowski Lee Jones Lingling Xu Linus Torvalds Linus Walleij Loic Poulain Lorenz Brun Luc Van Oostenryck Luis Chamberlain Manivannan Sadhasivam Mark Brown Mark Rutland Martin Fuzzey Martin K. Petersen Martin Schwidefsky Masahiro Yamada Masami Hiramatsu Masanari Iida Matti Vaittinen Mauricio Faria de Oliveira Michael Ellerman Miguel Ojeda Mike Rapoport Milian Wolff Nathan Chancellor Nathan Huckleberry Navid Emamdoost Nicholas Piggin Nick Desaulniers Nirmoy Das Palmer Dabbelt Patrice Chotard Paul Moore Pavel Begunkov Peter Zijlstra (Intel) Qing Zhang Qingqing Zhuo Randy Dunlap Robert Foss Robin Gong Rodrigo Siqueira Roman Gushchin Sami Tolvanen Sandeep Raghuraman Sedat Dilek Shuah Khan Shyam Thombre Sivaprakash Murugesan Stephan Mueller Stephan Müller Stephen Smalley Steven Rostedt (VMware) Sumanth Korikkar Sven Schnelle Tiezhu Yang Tom Lendacky Tom Rix Uma Shankar Vaibhav Jain Vamshi K Sthambamkadi Vandita Kulkarni Vasily Gorbik Vidya Sagar Vincenzo Frascino Vishal Verma Vladimir Oltean Waiman Long Wei Yang Weiping Zhang Will Deacon Wolfram Sang Wolfram Sang Xiaoguang Wang YangHui Yash Shah Ye Bin Zheng Bin Zhenzhong Duan Zhiqiang Liu Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7239 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 25 02:38:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 02:38:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joHmJ-0006Wi-Jg; Thu, 25 Jun 2020 02:38:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joHmH-0006Wc-RV for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 02:38:13 +0000 X-Inumbo-ID: e9e04f8e-b68c-11ea-bca7-bc764e2007e4 Received: from mail-lj1-x244.google.com (unknown [2a00:1450:4864:20::244]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e9e04f8e-b68c-11ea-bca7-bc764e2007e4; Thu, 25 Jun 2020 02:38:13 +0000 (UTC) Received: by mail-lj1-x244.google.com with SMTP id 9so4787169ljv.5 for ; Wed, 24 Jun 2020 19:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h0aax/W+hPyh1wto9kh47ORvApsOtay8uUSNvlfQm5c=; b=OoKbiIiyeix93l2WqzTKQ5Naay5CV/aSOvgTRB50yJQOAjz7Rrko5wq38ijI1njEw9 sKP8ESdLTmQqcNQ8tSrKwzJTlEzMM6NWG+SinmVPSNrI73TpkNk7pgLVy1C31exoUD9e EkUDxGJs1DvgqYjYlh5ByJkqUltV4p330Co3ZR2FWCQh3aT+OeHCHmnuhsiCWxx9jRoJ fMwGyScncIMKBZjHNntX60Bznj0nnS2g2cW8NJ/F8BksMXSDuGQ8m1PtMM8xv67EIEWv w4QQ3nsWcvNnp4DPQc13D+PM3LaZG7BvNhn3EH02kKbQ1nn+qAsTUBWOfHH2VoGwnDxV ZXTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h0aax/W+hPyh1wto9kh47ORvApsOtay8uUSNvlfQm5c=; b=gLwH1pZcmSdfKzVcoWLwIRO3v26B9So563zdIPW+zqzt7flmCn9fAR+XbRXHOacn26 GuL7qv4AdlTZrrcSGYbEMYbaz5vvEnyGFQ9Px0u/SfKZE1NSisFONDul2sfsakKRzGc/ tmLAvEloXAD1ZwubeAb2h/L9Uyj3JslYMckLypsDEKsU04cOkazx2luLvXBmAn5q7BIi FBGa31m0AC/jnnySG/hm7pqD+niHIafOEAKPU37raf4w0hZU8Mk6BXRNz8xW4mLAWwD5 CdfXm8aghBxI07Lzb1LNQ0TXieu4sLBDOeN2I+IaLYorLHqMQi1OqSWbhcZ/UjBaXzo8 tYPA== X-Gm-Message-State: AOAM532uPVWOehsx79L3bLlALspAq3lZWvcLxq9OuPOErB1SowMZUame otguznh4P0scttW9mKhp3OvASnOcxqSPwhtHdLU= X-Google-Smtp-Source: ABdhPJw41r6Hj8uhqS/iUICTysk3gLFkOcYY7waiJe6R75sR4fpwPf8XaOK7+6tG59wIupxd8FNjV74lOTVd7c5NhlM= X-Received: by 2002:a2e:9141:: with SMTP id q1mr14768939ljg.196.1593052691722; Wed, 24 Jun 2020 19:38:11 -0700 (PDT) MIME-Version: 1.0 References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> In-Reply-To: <24307.32018.502303.817846@mariner.uk.xensource.com> From: Jason Andryuk Date: Wed, 24 Jun 2020 22:37:59 -0400 Message-ID: Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" To: Ian Jackson Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Jan Beulich , Wei Liu , Paul Durrant , Andrew Cooper , Elliott Mitchell , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 12:19 PM Ian Jackson wrote: > > Jan Beulich writes ("Re: use of "stat -""): > > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments unless you have verified the sender and know the content is safe. > > On 14.05.2020 13:02, Ian Jackson wrote: > > > I've read this thread. Jan, I'm sorry that this causes you > > > inconvenience. I'm hoping it won't come down to a choice between > > > supporting people who want to ship a dom0 without perl, and people who > > > want a dom0 using more-than-a-decade-old coreutils. > > > > > > Jan, can you tell me what the output is of this on your ancient > > > system: > > > > > > $ rm -f t > > > $ >t > > > $ exec 3 > > $ stat -L -c '%F %i' /dev/stdin <&3 > > > regular empty file 393549 > > > $ rm t > > > $ stat -L -c '%F %i' /dev/stdin <&3 > > > regular empty file 393549 > > > $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 > > > $ > > > > $ rm -f t > > $ >t > > $ exec 3 > $ stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 3380369 > > $ rm t > > $ stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 3380369 > > $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 3380369 > > > > > Also, the contents of the file "u" afterwards, please. > > > > Attached. > > Thanks. > > I think this means that `stat -' can be replaced by `stat /dev/stdin'. > > This script is only run on Linux where /dev/stdin has existed > basically forever. The strace output shows > stat("/dev/stdin", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > and the transcript shows that your stat(1) behaves as I hope. > > Jan, will you send a patch ? It is best if someone else but me writes > it and tests it because then I am a "clean" reviewer. > > Paul, supposing I review such a patch and say it is low risk, and we > commit it by Friday, can it have a release-ack ? I was going to just write a patch to replace - with /dev/stdin and ask Jan to test it. When I opened the script, this comment was staring at me: # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or # use bash's test -ef because those all go through what is # actually a synthetic symlink in /proc and we aren't # guaranteed that our stat(2) won't lose the race with an # rm(1) between reading the synthetic link and traversing the # file system to find the inum. On my system: $ ls -l /dev/stdin lrwxrwxrwx 1 root root 15 Jun 24 21:13 /dev/stdin -> /proc/self/fd/0 $ ls -l /proc/self/fd/0 0 /home/jason/lockfile stat /dev/stdin will work around the lack of `stat -` support, but it doesn't address the race in the comment. Is the comment valid? How would we prove there is no race for /dev/stdin? And as a refresher, `stat -` does an fstat(0), so there is no symlink lookup. Or is there no race since `stat /proc/self/fd/0` isn't a symlink lookup but just accessing the already open fd via the proc special file? i.e. equivalent to fstat. I've mentioned it before, but maybe we should just use the Qubes patch. It leaves the lockfile even when no-one is holding the lock, but it simplifies the code and sidesteps the issues we are discussing here. https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.13/patch-tools-hotplug-drop-perl-usage-in-locking-mechanism.patch Regards, Jason From xen-devel-bounces@lists.xenproject.org Thu Jun 25 02:44:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 02:44:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joHs7-0007PR-Cy; Thu, 25 Jun 2020 02:44:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joHs6-0007PM-Ts for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 02:44:14 +0000 X-Inumbo-ID: c12253e8-b68d-11ea-b7bb-bc764e2007e4 Received: from mail-lj1-x232.google.com (unknown [2a00:1450:4864:20::232]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c12253e8-b68d-11ea-b7bb-bc764e2007e4; Thu, 25 Jun 2020 02:44:14 +0000 (UTC) Received: by mail-lj1-x232.google.com with SMTP id t25so233885lji.12 for ; Wed, 24 Jun 2020 19:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ijxYOypE8JXmxPV7oqzpPRU34Arl5A/6UxXyzebkzTE=; b=aJrRcOqcB6m7AtN2HWtoifTfn5MvNxminS0EWt/BO2jobOhDpWEwVAh/U4We2yzNwi j8G1/OVA6ztA3TYFz6vw79ki0ePUwKugeodA+6ZC5m4TrhDif/lLjZv97BxEUlzKD/sw qYCYbTmHp/wWihFbMiPIHYRmUG8f+zJTNWl0GXQKm/DEh3FmT0F40a5jz8dPXFJ8hDnO D1k2Jln0hRIfu6HSRvUR+ci8Uoc5yAKuKgpdji+y83Jo3RuBX93j59VLcI30QvucAgje CRX4Yd3NAu/q9n2ILMvaPz/nS9rDTC5XLXhew4elue1ZfiuKKQwF0/ainIbLNu+WGMjY pCMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ijxYOypE8JXmxPV7oqzpPRU34Arl5A/6UxXyzebkzTE=; b=UqI+57ZE2XLWvOSWU0GIDle0fEngL8v1wD+56z0WKTMKRJuVmn8QeJfigt3q2fUQSq CidyyytJk2JyPTggEHO0QOzlMrb7yH2iziP1QDX/7wvUYz2y4cNWkfLn3RRzfFrxGlSG kYdQaZzF5YQwSLywrUiXzB6nFeV1qDZMiexF8iSq05o0lugOtSZ0pdBixHiJofIjxhvV pn+TYJ/K8NhhzxLhnu8YYPYodi483qSSuBPAPU9e4XPweZR1yrXgzyFm+PDtjydPdO12 Kiw4TX7jTtTIlRDLFgNjeDCg8Owa2jz3UsAmBBnATI1/9U6WBgXrFYcSZ/rJO0e946t6 F2WA== X-Gm-Message-State: AOAM531pylrmLbhcQWGqNUyuGdaiDQSBwaC0ruWUfkFfr1wSCGW7AisP vDoDsdYgf9d/Y63mBL17MEl+JrslhrTOyebHGzc= X-Google-Smtp-Source: ABdhPJyuLSZ/XCaBa1ABWU/XsMuIcc8TqjQSUuD8XEgjbvwas8KZop8+H2BeD4OCm3fYLTHkJ/qjr/24fQvYc3CNdBg= X-Received: by 2002:a2e:978b:: with SMTP id y11mr3907624lji.399.1593053053018; Wed, 24 Jun 2020 19:44:13 -0700 (PDT) MIME-Version: 1.0 References: <20200624175653.GA49433@work-vm> In-Reply-To: <20200624175653.GA49433@work-vm> From: Jason Andryuk Date: Wed, 24 Jun 2020 22:44:00 -0400 Message-ID: Subject: Re: Migration vmdesc and xen-save-devices-state To: "Dr. David Alan Gilbert" Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , QEMU , zhang.zhanghailiang@huawei.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 1:57 PM Dr. David Alan Gilbert wrote: > > * Jason Andryuk (jandryuk@gmail.com) wrote: > > Hi, > > > > At some point, QEMU changed to add a json VM description (vmdesc) > > after the migration data. The vmdesc is not needed to restore the > > migration data, but qemu_loadvm_state() will read and discard the > > vmdesc to clear the stream when should_send_vmdesc() is true. > > About 5 years ago :-) :) > > xen-save-devices-state generates its migration data without a vmdesc. > > xen-load-devices-state in turn calls qemu_loadvm_state() which tries > > to load vmdesc since should_send_vmdesc is true for xen. When > > restoring from a file, this is fine since it'll return EOF, print > > "Expected vmdescription section, but got 0" and end the restore > > successfully. > > > > Linux stubdoms load their migration data over a console, so they don't > > hit the EOF and end up waiting. There does seem to be a timeout > > though and restore continues after a delay, but we'd like to eliminate > > the delay. > > > > Two options to address this are to either: > > 1) set suppress_vmdesc for the Xen machines to bypass the > > should_send_vmdesc() check. > > or > > 2) just send the vmdesc data. > > > > Since vmdesc is just discarded, maybe #1 should be followed. > > #1 does sound simple! > > > If going with #2, qemu_save_device_state() needs to generate the > > vmdesc data. Looking at qemu_save_device_state() and > > qemu_savevm_state_complete_precopy_non_iterable(), they are both very > > similar and could seemingly be merged. qmp_xen_save_devices_state() > > could even leverage the bdrv_inactivate_all() call in > > qemu_savevm_state_complete_precopy_non_iterable(). > > > > The would make qemu_save_device_state a little more heavywight, which > > could impact COLO. I'm not sure how performance sensitive the COLO > > code is, and I haven't measured anything. > > COLO snapshots are potentially quite sensitive; although we've got a > load of other things we could do with speeding up, we could do without > making them noticably heavier. qemu_savevm_state_complete_precopy_non_iterable() generates the vmdesc json and just discards it if not needed. How much overhead that adds is the question. Thanks, Jason From xen-devel-bounces@lists.xenproject.org Thu Jun 25 02:55:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 02:55:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joI2P-0008Kx-D7; Thu, 25 Jun 2020 02:54:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joI2O-0008Ks-Dw for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 02:54:52 +0000 X-Inumbo-ID: 3d4ae06a-b68f-11ea-8496-bc764e2007e4 Received: from mail-pg1-x544.google.com (unknown [2607:f8b0:4864:20::544]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3d4ae06a-b68f-11ea-8496-bc764e2007e4; Thu, 25 Jun 2020 02:54:51 +0000 (UTC) Received: by mail-pg1-x544.google.com with SMTP id u128so2585693pgu.13 for ; Wed, 24 Jun 2020 19:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=fAhw99hSHSp4oWrS0namYNm6Go3NsuSaLTMdS2js2yg=; b=tGJIN5xGsgN1is4VPvkWyDq1pQcJK/f4mEt+aWjJHg7bZ3RJcDogKlmQ0OSbuVj4dk m8f1/44VpRJ3kiSvogq4WXlZ3AY6U2bU3iwIhwsi9/432OcHSqoK785PT1o24waKPk3y JkpBWrh9BmojPyt6eC9QUQqiXQK5t8N4VSGy8DmuPGEt9bR/ONK3zzbAggeOqH7PR7UW TlCDWeZoRDnx4wuJN4Y2p4v0QoXAKAgzmw1+ZZV1tyk93pdcs1CcjpKikxhpATOSO5Lc RsNnXAUUon3g9H+ZafgA/DX3BsvOxBOIRnnzmEgwjDKYQudXSSRn33PYSWi6eyNCcZWx whGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=fAhw99hSHSp4oWrS0namYNm6Go3NsuSaLTMdS2js2yg=; b=twqJFTeEEX4fxsGgAzm7a/HLzE0I9/p1j0AkZJ0+XJ9R/HG0n7mFvLKhHUqibuL/8H ezw6yPC3QwvpcLQ/sWgjTmupOELc7dmudyRWAu4fmb2Z2RYV173LfzVho+anGoV4Auw0 yhIewnVZtC5tvcOX6Os49U93YvdEay3/wOpaE1EWP3c32+WYyY0rEstGr7c2LV/WQ9sW Evfe576gy/Cy8xW69CETs4Xz/I+ODVv7BabqcQ1jbTvXPlAWgtpBR0s/rPCY/hYqrY21 pUKfJPZIuKAazx4/RWHq4O9/7jkHA6A2lCc1ekCDzD8+jKA4DCGIXxGqIx64M7uhepRV r9Pw== X-Gm-Message-State: AOAM532557qhAnWC22FJoGCiZnyd92ZpUL8UjdGnG7FWlARkUNhYTmQ3 xlsM5DmimG5DlNarOVgaf6Y= X-Google-Smtp-Source: ABdhPJypIwr6XPQgemt6CJF4aVOuSE9P8rFDuFGhKBDr+zcFrzEKlnZEEU3wYydNz5mYaZJaYnAkvg== X-Received: by 2002:a63:de18:: with SMTP id f24mr23694179pgg.415.1593053690835; Wed, 24 Jun 2020 19:54:50 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC.domain.name ([122.182.254.114]) by smtp.gmail.com with ESMTPSA id y10sm18593000pgi.54.2020.06.24.19.54.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 19:54:50 -0700 (PDT) From: Souptick Joarder To: boris.ostrovsky@oracle.com, jgross@suse.com, sstabellini@kernel.org Subject: [PATCH 1/2] xen/privcmd: Corrected error handling path and mark pages dirty Date: Thu, 25 Jun 2020 08:32:39 +0530 Message-Id: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> X-Mailer: git-send-email 1.9.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Paul Durrant , linux-kernel@vger.kernel.org, John Hubbard , Souptick Joarder Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Previously, if lock_pages() end up partially mapping pages, it used to return -ERRNO due to which unlock_pages() have to go through each pages[i] till *nr_pages* to validate them. This can be avoided by passing correct number of partially mapped pages & -ERRNO separately, while returning from lock_pages() due to error. With this fix unlock_pages() doesn't need to validate pages[i] till *nr_pages* for error scenario and few condition checks can be ignored. As discussed, pages need to be marked as dirty before unpinned it in unlock_pages() which was oversight. Signed-off-by: Souptick Joarder Cc: John Hubbard Cc: Boris Ostrovsky Cc: Paul Durrant --- Hi, I'm compile tested this, but unable to run-time test, so any testing help is much appriciated. drivers/xen/privcmd.c | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index a250d11..0da417c 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -580,43 +580,44 @@ static long privcmd_ioctl_mmap_batch( static int lock_pages( struct privcmd_dm_op_buf kbufs[], unsigned int num, - struct page *pages[], unsigned int nr_pages) + struct page *pages[], unsigned int nr_pages, int *pinned) { unsigned int i; + int errno = 0, page_count = 0; for (i = 0; i < num; i++) { unsigned int requested; - int pinned; + *pinned += page_count; requested = DIV_ROUND_UP( offset_in_page(kbufs[i].uptr) + kbufs[i].size, PAGE_SIZE); if (requested > nr_pages) return -ENOSPC; - pinned = get_user_pages_fast( + page_count = get_user_pages_fast( (unsigned long) kbufs[i].uptr, requested, FOLL_WRITE, pages); - if (pinned < 0) - return pinned; + if (page_count < 0) { + errno = page_count; + return errno; + } - nr_pages -= pinned; - pages += pinned; + nr_pages -= page_count; + pages += page_count; } - return 0; + return errno; } static void unlock_pages(struct page *pages[], unsigned int nr_pages) { unsigned int i; - if (!pages) - return; - for (i = 0; i < nr_pages; i++) { - if (pages[i]) - put_page(pages[i]); + if (!PageDirty(page)) + set_page_dirty_lock(page); + put_page(pages[i]); } } @@ -630,6 +631,7 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) struct xen_dm_op_buf *xbufs = NULL; unsigned int i; long rc; + int pinned = 0; if (copy_from_user(&kdata, udata, sizeof(kdata))) return -EFAULT; @@ -683,9 +685,11 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) goto out; } - rc = lock_pages(kbufs, kdata.num, pages, nr_pages); - if (rc) + rc = lock_pages(kbufs, kdata.num, pages, nr_pages, &pinned); + if (rc < 0) { + nr_pages = pinned; goto out; + } for (i = 0; i < kdata.num; i++) { set_xen_guest_handle(xbufs[i].h, kbufs[i].uptr); -- 1.9.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 25 02:55:00 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 02:55:00 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joI2U-0008LG-L0; Thu, 25 Jun 2020 02:54:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joI2T-0008Ks-9V for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 02:54:57 +0000 X-Inumbo-ID: 40420b68-b68f-11ea-bb8b-bc764e2007e4 Received: from mail-pg1-x544.google.com (unknown [2607:f8b0:4864:20::544]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 40420b68-b68f-11ea-bb8b-bc764e2007e4; Thu, 25 Jun 2020 02:54:56 +0000 (UTC) Received: by mail-pg1-x544.google.com with SMTP id e18so2603444pgn.7 for ; Wed, 24 Jun 2020 19:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=zp4npQcgeZMS0pGjybddj8LwS3fxPZyTX8wZXmAxxq8=; b=Az91tkePwm/xh44txinQdcyBs/2AMx7g4pZmjPtGWK2i06v/4LoR+m3rR1QuJD/JYK Y07aw6vQOY6UupyMDXeuqqdgCerrwRSuFxZtNWPAPsSK2Y15Evu3u62oyDGJ1KInb3el y5pMfE7BF0nslx1d99ZO6inoSdV3sUcwB6LgDAXB1/vu8DHwlQRoJ97hfxqp2p6jflU5 /jWTggLrwFX55TkRA9aPLeK2NvVdv2e/C/QwsxlOdQfBx43RxEDhMzgLpySzJZSu9EBS SbwThB3OXl8kBaxZVNhPp/UoUv1pyGsWBPayAXzR89WKZBIvUPbBq8KY7bFm22h8giPj NNYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=zp4npQcgeZMS0pGjybddj8LwS3fxPZyTX8wZXmAxxq8=; b=n7/WZGrLqHpaXjQk/uBwj7vzxkKe2j1P3qGvHVY/YQynpBcMoDkMsv7uQmsdCrTCsa 3mmipDt9aCMajniUzCVkCCXT7CAsshgXrbaeCqrncAKcg+dpX2kSRtZBy6TDZvNVFNYI 3jRIOKcjYGN5jUpzMzFe6ZGfVwTZOAYWVGGcY1Pb99DA9ifg/vbzpVZGeqFxcPwaq0bE Cu0AetYhVPjJsIn3Tx2miiujGnYcKmQvf1rkaUUcYDhu9bFatAYfXajuihIfdQfPtEtW zJt46s13X4HI8umuTLOJqTCQnHNUUiQ4S9p/Wn2fg47z2nBGIxYct1UDAYIzwKR8Sc4s YW2A== X-Gm-Message-State: AOAM532hWPpd42Ncc3wTYHp3szxzeNwi6P/lNSuQJcVDwk57H9NguI8H vXgYJGepOoa36vsYzgn0D+s= X-Google-Smtp-Source: ABdhPJxabE67+Alwujp7u9O15q0niQ7itBEEzErE0Ls5oHuYwsqVsBmpiuxlji26MFkmaJ/GNds1hA== X-Received: by 2002:a62:60c7:: with SMTP id u190mr30255128pfb.240.1593053695830; Wed, 24 Jun 2020 19:54:55 -0700 (PDT) Received: from jordon-HP-15-Notebook-PC.domain.name ([122.182.254.114]) by smtp.gmail.com with ESMTPSA id y10sm18593000pgi.54.2020.06.24.19.54.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 19:54:55 -0700 (PDT) From: Souptick Joarder To: boris.ostrovsky@oracle.com, jgross@suse.com, sstabellini@kernel.org Subject: [PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() Date: Thu, 25 Jun 2020 08:32:40 +0530 Message-Id: <1593054160-12628-2-git-send-email-jrdr.linux@gmail.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> References: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Paul Durrant , linux-kernel@vger.kernel.org, John Hubbard , Souptick Joarder Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In 2019, we introduced pin_user_pages*() and now we are converting get_user_pages*() to the new API as appropriate. [1] & [2] could be referred for more information. This is case 5 as per document [1]. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Signed-off-by: Souptick Joarder Cc: John Hubbard Cc: Boris Ostrovsky Cc: Paul Durrant --- Hi, I'm compile tested this, but unable to run-time test, so any testing help is much appriciated. drivers/xen/privcmd.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 0da417c..eb05254 100644 --- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -595,7 +595,7 @@ static int lock_pages( if (requested > nr_pages) return -ENOSPC; - page_count = get_user_pages_fast( + page_count = pin_user_pages_fast( (unsigned long) kbufs[i].uptr, requested, FOLL_WRITE, pages); if (page_count < 0) { @@ -612,13 +612,7 @@ static int lock_pages( static void unlock_pages(struct page *pages[], unsigned int nr_pages) { - unsigned int i; - - for (i = 0; i < nr_pages; i++) { - if (!PageDirty(page)) - set_page_dirty_lock(page); - put_page(pages[i]); - } + unpin_user_pages_dirty_lock(pages, nr_pages, 1); } static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) -- 1.9.1 From xen-devel-bounces@lists.xenproject.org Thu Jun 25 03:11:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 03:11:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joIHz-0001g0-1O; Thu, 25 Jun 2020 03:10:59 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joIHx-0001fa-Re for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 03:10:57 +0000 X-Inumbo-ID: 78ec9940-b691-11ea-8173-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 78ec9940-b691-11ea-8173-12813bfff9fa; Thu, 25 Jun 2020 03:10:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MjW3U0FkopEp5KXseyKUXUotrLObLulzz0vygDuwt2Q=; b=ZjbPOm1nT8ReDJIuahL/OGNow 4l7d4OLEdyuVMdqW3C9qA4qzDUsokb2ymMugfXbx6a4z3JL7BfLHt8CP60BMdG3xwWM0/9yS/E4BZ rHPVvqGmOLewEUwNuOVPi6mhe9GXk6ecrZJ1mGoC7LMNPeMDxK5tz1IqrXThRGdPJ87E4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joIHq-0003OL-3s; Thu, 25 Jun 2020 03:10:50 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joIHp-0006cK-QQ; Thu, 25 Jun 2020 03:10:49 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joIHp-0004hv-Pp; Thu, 25 Jun 2020 03:10:49 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151330: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=c5815b31976f3982d18c7f6c1367ab6e403eb7eb X-Osstest-Versions-That: libvirt=597fdabbc0e7c256b61a6b5ffda64bebfddc3807 From: osstest service owner Date: Thu, 25 Jun 2020 03:10:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151330 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151330/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151308 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151308 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt c5815b31976f3982d18c7f6c1367ab6e403eb7eb baseline version: libvirt 597fdabbc0e7c256b61a6b5ffda64bebfddc3807 Last test of basis 151308 2020-06-23 04:19:04 Z 1 days Testing same since 151330 2020-06-24 05:57:45 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Daniel Henrique Barboza Daniel P. Berrangé Dmitry Nesterenko Jonathon Jongsma Ján Tomko Liao Pingfang Menno Lageman Michal Privoznik Peter Krempa Satheesh Rajendran jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 597fdabbc0..c5815b3197 c5815b31976f3982d18c7f6c1367ab6e403eb7eb -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Thu Jun 25 05:28:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 05:28:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joKR0-0004F1-0i; Thu, 25 Jun 2020 05:28:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joKQy-0004Ed-Iy for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 05:28:24 +0000 X-Inumbo-ID: ace4cb74-b6a4-11ea-8175-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ace4cb74-b6a4-11ea-8175-12813bfff9fa; Thu, 25 Jun 2020 05:28:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=10ACGA9/fuOmaw93gPfnjrld7q29n2iJx+1VOdeJOow=; b=NB2TX1OPPyaagNmBX3tYNOtJc Gv4YlHE+r691kEOrLDrKl8n93IegnKkUJQASADU6uZY1xFA8k5Nzeq+oZJgDqxlb1MvI5P/PtPpiU qB7kc/dL1p6LmJVUxe+UI3gdgS4787vyR558EYJiAmoRY64N9L/OYMB9pwb4bQ3f/ACnM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joKQr-0006NT-IT; Thu, 25 Jun 2020 05:28:17 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joKQr-0005HH-BX; Thu, 25 Jun 2020 05:28:17 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joKQr-0002il-88; Thu, 25 Jun 2020 05:28:17 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151328: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=d88d5a3806d78dcfca648c62dae9d88d3e803bd2 X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Thu, 25 Jun 2020 05:28:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151328 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151328/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151065 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass version targeted for testing: qemuu d88d5a3806d78dcfca648c62dae9d88d3e803bd2 baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 12 days Failing since 151101 2020-06-14 08:32:51 Z 10 days 9 attempts Testing same since 151328 2020-06-24 04:17:13 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Anthony PERARD Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Cleber Rosa Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Geoffrey McRae Gerd Hoffmann Guenter Roeck Helge Deller Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jean-Christophe Dubois Jiaxun Yang John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marek Marczykowski-Górecki Markus Armbruster Masahiro Yamada Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Stefan Berger Stefan Hajnoczi Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 9685 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Jun 25 05:49:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 05:49:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joKl0-0005vR-TV; Thu, 25 Jun 2020 05:49:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joKkz-0005vM-9f for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 05:49:05 +0000 X-Inumbo-ID: 939f6a2c-b6a7-11ea-b7bb-bc764e2007e4 Received: from hqnvemgate25.nvidia.com (unknown [216.228.121.64]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 939f6a2c-b6a7-11ea-b7bb-bc764e2007e4; Thu, 25 Jun 2020 05:49:04 +0000 (UTC) Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Wed, 24 Jun 2020 22:48:17 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Wed, 24 Jun 2020 22:49:03 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Wed, 24 Jun 2020 22:49:03 -0700 Received: from [10.2.59.206] (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 25 Jun 2020 05:49:02 +0000 Subject: Re: [PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Souptick Joarder , , , References: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> <1593054160-12628-2-git-send-email-jrdr.linux@gmail.com> From: John Hubbard Message-ID: <59afe2fe-3718-85aa-f3b5-83ca0b9df577@nvidia.com> Date: Wed, 24 Jun 2020 22:49:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <1593054160-12628-2-git-send-email-jrdr.linux@gmail.com> X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1593064097; bh=hWnF3N0wCKATLkkSfY0YFbwq7TYcYG70FRiPZLz+TCA=; h=X-PGP-Universal:Subject:To:CC:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:X-Originating-IP: X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=Ou2+hLOaCBz5atm+9GHKtzk2bsBzKjQpsnvnwY2SlNbHVBzzL+/gQ3IF+qLThXkSb u4uehwdHRm+7H+ISGqx9LuSs62EgWyvSOnyTPq8gAuSVnA/OmC6ysPb59sBzr2usdn aEnDnmC1GhNwFrZOk7VLroiVZqtLYB/tiUXMSSh+8+G09UySSwK17c44IFFvw+C4jE YokJFSjzFST3CpV1TMAJWqlA8A1sPBaZzZBJ1cjuOYLmTIlxudkBQePekA1XbpiYMy yiKYBAWwKB7/h5LGmYbn844WExZQR3Zep0YtJkMbmQg5w/QxcCBpmdh/1Epgu/kxJ1 H2nDpVqD51F+A== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-24 20:02, Souptick Joarder wrote: > In 2019, we introduced pin_user_pages*() and now we are converting > get_user_pages*() to the new API as appropriate. [1] & [2] could > be referred for more information. This is case 5 as per document [1]. > > [1] Documentation/core-api/pin_user_pages.rst > > [2] "Explicit pinning of user-space pages": > https://lwn.net/Articles/807108/ > > Signed-off-by: Souptick Joarder > Cc: John Hubbard > Cc: Boris Ostrovsky > Cc: Paul Durrant > --- > Hi, > > I'm compile tested this, but unable to run-time test, so any testing > help is much appriciated. > > drivers/xen/privcmd.c | 10 ++-------- > 1 file changed, 2 insertions(+), 8 deletions(-) > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index 0da417c..eb05254 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -595,7 +595,7 @@ static int lock_pages( > if (requested > nr_pages) > return -ENOSPC; > > - page_count = get_user_pages_fast( > + page_count = pin_user_pages_fast( > (unsigned long) kbufs[i].uptr, > requested, FOLL_WRITE, pages); > if (page_count < 0) { > @@ -612,13 +612,7 @@ static int lock_pages( > > static void unlock_pages(struct page *pages[], unsigned int nr_pages) > { > - unsigned int i; > - > - for (i = 0; i < nr_pages; i++) { > - if (!PageDirty(page)) > - set_page_dirty_lock(page); > - put_page(pages[i]); > - } > + unpin_user_pages_dirty_lock(pages, nr_pages, 1); "true", not "1", is the correct way to call that function. Also, this approach changes the behavior slightly, but I think it's reasonable to just set_page_dirty_lock() on the whole range--hard to see much benefit in checking PageDirty first. > } > > static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) > thanks, -- John Hubbard NVIDIA From xen-devel-bounces@lists.xenproject.org Thu Jun 25 06:15:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 06:15:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLAL-0008Oa-0N; Thu, 25 Jun 2020 06:15:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLAJ-0008OV-54 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 06:15:15 +0000 X-Inumbo-ID: 3b7e9b8e-b6ab-11ea-8496-bc764e2007e4 Received: from mail-ot1-x341.google.com (unknown [2607:f8b0:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3b7e9b8e-b6ab-11ea-8496-bc764e2007e4; Thu, 25 Jun 2020 06:15:14 +0000 (UTC) Received: by mail-ot1-x341.google.com with SMTP id 72so4241823otc.3 for ; Wed, 24 Jun 2020 23:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L3nkNUv0AI8kinjFbObpy88tHlaSp8Q2pJ4IM2vuMno=; b=KixfC0RsXhSGUC0PgQR55XcqRvpZ1UbEXp1nNAZxcLSjwxStUuZWz5+7AuJsvXcGZc vpTIE7yCi6/2tl01hn67G3ThAXFfAxRx+4YreGPCM/2FRJcYjVZZ5Vd26phn6tkd5rq6 2urxxkRKYIhe7yHopQwN1EGwYn4DfTltIsNyBGGDCc72Ep5Zq773Pp6gQ4YQQtTq+ki5 4at2y7KtY9AInSRLAJPiwxce2ov8Wv52dyKbuTJWAKUw2PPSYdBs9gaBdLYK746ae09E zWVkMCmDiYJNIq3EVmI4xuxKQ+yRfUlk8wpiq92DR5bCtwv9C5rN6VepLvWbnZqEv+TG ErcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L3nkNUv0AI8kinjFbObpy88tHlaSp8Q2pJ4IM2vuMno=; b=CFWrVJ2C2/uY4BGg3+aepufTH4Bejz05CZp+CLYmZhMCChpt8gRqWHr2LtjEUKgJ/2 uGP2XWhkf1oqd2tGiTnfoKXxjlPikCYWgDNU1Lj+Vhms1lIY2Ug9wOOpfMdbH1tUQ8a1 eTyniLXfOn2YsWpnF86mcpadT3hcH0bEZziROE++fT/uIJmelG9PljJ6bdyh+2ALCVHr 5QE21KeoGbQwoaKutlW6X7DuCJ5l4MpY8mtIBltBXoB0+pBp5EBXGTeM5WjdjjWdBWGo /EseXFtA1NY/SqzM310KFNIgzYdTYO2bZnnCvkxelV2yw5/pW3OPpqxGIvCiQdQ0A6gK hMuA== X-Gm-Message-State: AOAM5335Jekm0yEGBQ2kz4ELGORsd/smA9Zp4gDk1kiJMEaxvobWIaEs asVkPD+NaPKbWJ9v7IpfI2xiwy8ioUUEqWLY6bk= X-Google-Smtp-Source: ABdhPJywri45Jqh9e3FSTIJRfKhHxBuoPZK66FF2fhz/9DoXhp7JOUEUyuQExTlFGeTy9jumu5WhitmB/ocxqkM6jQU= X-Received: by 2002:a05:6830:3104:: with SMTP id b4mr26009100ots.192.1593065713823; Wed, 24 Jun 2020 23:15:13 -0700 (PDT) MIME-Version: 1.0 References: <20200610185415.GG7231@minyard.net> <20200616010252.GC3113@minyard.net> <20200616014513.GD3113@minyard.net> In-Reply-To: From: Christopher Clark Date: Wed, 24 Jun 2020 23:15:02 -0700 Message-ID: Subject: Re: Xen on Pi4: Xen doesn't work with overlays from Raspberry Pi 5.4 kernel To: Roman Shaposhnik Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Corey Minyard , Stefano Stabellini , Julien Grall , tamas@tklengyel.com, Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 6:49 PM Roman Shaposhnik wrote: > > On Mon, Jun 15, 2020 at 6:45 PM Corey Minyard wrote: > > > > On Mon, Jun 15, 2020 at 06:05:57PM -0700, Roman Shaposhnik wrote: > > > On Mon, Jun 15, 2020 at 6:02 PM Corey Minyard wrote: > > > > > > > > On Mon, Jun 15, 2020 at 05:14:21PM -0700, Stefano Stabellini wrote: > > > > > On Mon, 15 Jun 2020, Christopher Clark wrote: > > > > > > On Wed, Jun 10, 2020 at 7:21 PM Roman Shaposhnik wrote: > > > > > > > > > > > > > > On Wed, Jun 10, 2020 at 11:54 AM Corey Minyard wrote: > > > > > > > > > > > > > > > > I had been working on Xen on the Pi4 by throwing kernels I compiled onto > > > > > > > > existing sd cards, and this was working fine. I finally got to a full > > > > > > > > yocto build of the system, and it didn't boot. > > > > > > > > > > > > > > > > In fact, Xen didn't print anything at all, and nothing happens that > > > > > > > > might suggest it's booting without any console output. > > > > > > > > > > > > I've reproduced this. Linux 4.19 from the Raspberry Pi kernel branch > > > > > > works fine, whereas I see no console output from the kernel once Xen > > > > > > tries to hand off to dom0 with either a 5.4 or 5.6 kernel. > > > > > > > > > > > > > > I traced the issue down to the vc4-fkms-v3d dtoverly. With everything > > > > > > > > else the same, the 4.19 version of that overlay works, and the 5.4 > > > > > > > > version does not work. It also didn't work if I completely removed the > > > > > > > > overlay. The base device trees are the same between the two kernels. > > > > > > > > > > > > > > > > Looking at the overlay changes between the versions and Xen source, I > > > > > > > > can't trace down anything that would cause an issue. Has anyone seen > > > > > > > > this issue of have any ideas? > > > > > > > > > > > > Seen it: yes, but no progress on resolving it to report at this point. > > > > > > > > > > > > > FWIW: I ran into very similar issues, ditched 5.4 kernel and moved to 5.6.x: > > > > > > > https://github.com/raspberrypi/linux/tree/rpi-5.6.y > > > > > > > > > > > > > > The 5.6.14 seems to be working quite nicely with Xen for me (and Stefano). > > > > > > > > > > > > Hi Roman - is there a specific commit in that rpi-5.6.y branch that > > > > > > you guys have working ok? > > > > > > It looks like the bcm2711_defconfig file wasn't included in the kernel > > > > > > source tree of that branch at the point the kernel version was bumped > > > > > > up to 5.6.14, so is there somewhere else to look for a matching kernel > > > > > > config? > > > > > > > > > > I don't know if that is the issue but beware that some device trees > > > > > invert serial0 with serial1. Make sure to use /soc/serial@7e215040. You > > > > > can do that by passing dtuart=/soc/serial@7e215040 to the Xen command > > > > > line. > > > > > > > > I already have that set as part of the boot process, but it still > > > > doesn't print anything out once Xen is started. > > > > > > > > I tried the 5.6 device tree, and no help there, eithers. I'm wondering > > > > if everyone is still running with the 4.19 device trees. > > > > > > As I pointed out in the EVE link above -- we're very happily running > > > with 5.6 device trees. They are, of course, taken from RPI kernel > > > tree. > > > > Ok, what version of Xen are you running? I'm using 4.13 with the Pi > > patches, but I have not tried the master branch. > > We're running 4.14 + additional patches (not sure which ones will make > it into 4.14 proper yet): > https://github.com/lf-edge/eve/tree/master/pkg/xen/arch/aarch64 > > FWIW: the first patch is basically the delta between 4.13 and 4.14 Corey: try adding these to your u-boot script: # Define the size and address cells fdt set /chosen '#size-cells' <1> fdt set /chosen '#address-cells' <1> It looks like the 4.19 kernel device tree has those nodes set by the time the u-boot script picks up after the GPU's work on the device tree, but the more recent 5.4 and 5.6 kernels do not. Adding those in within the u-boot script, I've been able to successfully boot the Linux 5.4 and 5.6 kernels from meta-raspberrypi as well as a local build of the Eve 5.6 kernel. Stefano has a patch to do something similar in the Eve series here: https://github.com/lf-edge/eve/blob/master/pkg/new-kernel/patches-5.6.x/0013-adding-stdout-path-overlay.patch I've just posted an updated series to meta-virt to enable Xen on Rpi4 with Linux 5.4 (the current Yocto kernel version) here: https://lists.yoctoproject.org/g/meta-virtualization/message/5449 Christopher From xen-devel-bounces@lists.xenproject.org Thu Jun 25 06:56:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 06:56:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLnZ-0003Eg-6j; Thu, 25 Jun 2020 06:55:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLnY-0003Eb-2e for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 06:55:48 +0000 X-Inumbo-ID: e53fc882-b6b0-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x343.google.com (unknown [2a00:1450:4864:20::343]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e53fc882-b6b0-11ea-bca7-bc764e2007e4; Thu, 25 Jun 2020 06:55:47 +0000 (UTC) Received: by mail-wm1-x343.google.com with SMTP id a6so6000672wmm.0 for ; Wed, 24 Jun 2020 23:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=AcJhJWPg9ILmTg2qesw42RsvWT7rg9x8dkf0LUZBteE=; b=WlVvGyoNRncnsSk+dobJfK3f2/ZNIKCr1WezZR3PM5U9DmL9pzb03igSMwv2GM8Dsa /yYXvV2CZspI9U8Dv/Bt8mpIXwQaitylA7d6RRCDXDZJXTtMadfi0jtixA4pkDnnYnap HuiMLAEa6oUsH4NO4hLkdtvL+KYsmtlI9EuCfVMd4XSKIW6SBPArdQl3Rd2PISSLRUAN j8tzIerIgDJMplvcQ7k6VLdgJElMToVKsQNP/VKYRZ6yv8MOm8Dv9KISpaTOrFZZ65UD T3v1fKbAVtZu7v5Ta7lqT75bAW5YDn4sCE9llxx3vt1nT4WzKl74y6L60g6Pb6QQyj53 Ytow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=AcJhJWPg9ILmTg2qesw42RsvWT7rg9x8dkf0LUZBteE=; b=hlZeGZHKTFQF8W7iy1wSHR7PRSRREbKtumZH9Ms39iE/nZd7iXXr5elgetOQPPKSYw VxCwG1xfZUQofk3kqefadbViU758otm++1qjCiy/ZA5bO6Ui9Dcr2ooidI4ZVf9TszWZ Jn6MGIu1EV82NUXRn9UYA6al2fBCPB6T/y/VM97FE24Lc1JnlkTaMi07TK3rBJHfzJnb m8qNsZ3wePTOeChGBrsF/bQIbTkBKgjTYlqewN1OwgLcCR4qUwyJB3LhCE3IJFp618rr RFjxufilG6WNJlPkXTjn+kNvXHQizgB9N3W4d8DFM/0zhd8/eqGQgUcf+k5GBWDKb+6w /+wg== X-Gm-Message-State: AOAM531MgOIoiZ9V64soefAV2g3wgKCfz7lrntuufwQP+aoD/XrqxRDh cN+nm+9EocG109ij2n0lur0= X-Google-Smtp-Source: ABdhPJxRemy6vIC4cLmw7UJQEJQ3V73AMdEP0/wk4hJ1tsZ6r/3ULJ644b5vAvRtJbdkLPATIbKmUQ== X-Received: by 2002:a1c:9cd0:: with SMTP id f199mr1666878wme.94.1593068146103; Wed, 24 Jun 2020 23:55:46 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-239.amazon.com. [54.240.197.239]) by smtp.gmail.com with ESMTPSA id 63sm32509045wra.86.2020.06.24.23.55.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 23:55:45 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <5993e716-d71d-cbc0-a186-5325e2bdeba4@suse.com> <2c3e8cd2-b74f-52b6-4df8-057e8d000455@suse.com> In-Reply-To: <2c3e8cd2-b74f-52b6-4df8-057e8d000455@suse.com> Subject: RE: Ping: [PATCH v3 1/1] x86/acpi: Use FADT flags to determine the PMTMR width Date: Thu, 25 Jun 2020 07:55:44 +0100 Message-ID: <000001d64abd$a676b480$f3641d80$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJVMUHmkHGgErqW4WJrIi3D08QvIAHMqz2XAToNZ2MAiKHvDKfOnXqA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Wei Liu' , jakub@bartmin.ski, 'Andrew Cooper' , marmarek@invisiblethingslab.com, 'Grzegorz Uriasz' , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl, =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 24 June 2020 16:32 > To: Paul Durrant > Cc: Grzegorz Uriasz ; Wei Liu ; = jakub@bartmin.ski; Andrew Cooper > ; marmarek@invisiblethingslab.com; = j.nowak26@student.uw.edu.pl; xen- > devel@lists.xenproject.org; contact@puzio.waw.pl; Roger Pau Monn=C3=A9 = > Subject: Ping: [PATCH v3 1/1] x86/acpi: Use FADT flags to determine = the PMTMR width >=20 > On 22.06.2020 10:49, Jan Beulich wrote: > > On 20.06.2020 00:00, Grzegorz Uriasz wrote: > >> @@ -490,8 +497,12 @@ static int __init acpi_parse_fadt(struct = acpi_table_header *table) > >> */ > >> if (!pmtmr_ioport) { > >> pmtmr_ioport =3D fadt->pm_timer_block; > >> - pmtmr_width =3D fadt->pm_timer_length =3D=3D 4 ? 24 : 0; > >> + pmtmr_width =3D fadt->pm_timer_length =3D=3D 4 ? 32 : 0; > >> } > >> + if (pmtmr_width < 32 && fadt->flags & ACPI_FADT_32BIT_TIMER) > >> + printk(KERN_WARNING PREFIX "PM-Timer is too short\n"); > > > > Indentation is screwed up here. > > > >> --- a/xen/arch/x86/time.c > >> +++ b/xen/arch/x86/time.c > >> @@ -457,16 +457,13 @@ static u64 read_pmtimer_count(void) > >> static s64 __init init_pmtimer(struct platform_timesource *pts) > >> { > >> u64 start; > >> - u32 count, target, mask =3D 0xffffff; > >> + u32 count, target, mask; > >> > >> - if ( !pmtmr_ioport || !pmtmr_width ) > >> + if ( !pmtmr_ioport || (pmtmr_width !=3D 24 && pmtmr_width !=3D = 32) ) > >> return 0; > >> > >> - if ( pmtmr_width =3D=3D 32 ) > >> - { > >> - pts->counter_bits =3D 32; > >> - mask =3D 0xffffffff; > >> - } > >> + pts->counter_bits =3D pmtmr_width; > >> + mask =3D (1ull << pmtmr_width) - 1; > > > > "mask" being of "u32" type, the use of 1ull is certainly a little = odd > > here, and one of the reasons why I think this extra "cleanup" would > > better go in a separate patch. > > > > Seeing that besides cosmetic aspects the patch looks okay now, I'd = be > > willing to leave the bigger adjustment mostly as is, albeit I'd > > prefer the 1ull to go away, by instead switching to e.g. > > > > mask =3D 0xffffffff >> (32 - pmtmr_width); > > > > With the adjustments (which I'd be happy to make while committing, > > provided you agree) > > Reviewed-by: Jan Beulich > > > > Also Cc-ing Paul for a possible release ack (considering this is a > > backporting candidate). >=20 > Paul? >=20 Looks ok. Release-acked-by: Paul Durrant > Thanks, Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 25 06:57:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 06:57:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLpC-0003JY-IR; Thu, 25 Jun 2020 06:57:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLpB-0003JS-PT for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 06:57:29 +0000 X-Inumbo-ID: 222badd8-b6b1-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 222badd8-b6b1-11ea-bb8b-bc764e2007e4; Thu, 25 Jun 2020 06:57:29 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id k6so4645118wrn.3 for ; Wed, 24 Jun 2020 23:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=szCiaWbBc/QLQKscU+Ab67r+h00I2UsP7dR/oAh2Bsc=; b=mUAPzUbHpsUaO3D1zWtKMa0040E0TSkEnaUDosIRai6z7sIS49QJsbbwPRAGG3qzWK e0VeLHFKq7TQwLCblBp96hpy/6i1IMvrPUy7aDplB01sJl4NzERHEo7qzlqDX+qpdn70 rRtdCMXq0/t3md6Ib6bw1wusek7laLT4yFH22NHHJ68mYalRQrdZQxdk6J48TN6dbBDL eAc41kUrQu36LRLUgPJvSH1BCFWXNuNlmmW+hcNTk4ED5tqbzFBG+8069fG5BAmhPkgH +gN6LXf6PA5JPshOiWKdvuDj7H9Fm89O+r2IxECNnDywOD+Ub67yYPj3gvLuqdFySFT+ 7R6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=szCiaWbBc/QLQKscU+Ab67r+h00I2UsP7dR/oAh2Bsc=; b=anP+I5m+PFmpdgDcPwavTS8VXpvR2whYYOVvWF7rMSJDQ1htLYw2LJVfVFTe+uqls7 a12Z+raHLEpB00gkY0GS01thVW/mo80U0TVtZ+srtf+4cHhdp2Mfrg9z/zDIBK0E9UNg 6l0sUOqMin6VEELLI5TycBnK6epQrsT0/Gd9YQSByh4ke3sl2vI687d4zRCdA+KLNmCr MEB6OXiiRln0Vs/tGrf1VNREW2tbH+iL1wyPxEYylwow1TMroCks7SczYjHQS+oggAIE GhacjXZNz93ImnQKkvV7Lyf0vyrUqjQ5BLzmmzFS3AWJtEEEdrxTt7Jn/UOIEbMxxozh D0CA== X-Gm-Message-State: AOAM531GZAInt0g1k3tVUYef2xsILBhXHOF8hWRqtGcKi2C/weo8WDE2 2as3nBHFKT9z/lhtn2314nE= X-Google-Smtp-Source: ABdhPJyEWIqLdTLRBO9eswaBz0H1p+Qzd3rhtUZ/THAzBr0kjvhEe1LR/i4ZkzI4IWxcb25h5DZWog== X-Received: by 2002:adf:e749:: with SMTP id c9mr37860167wrn.25.1593068248354; Wed, 24 Jun 2020 23:57:28 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-239.amazon.com. [54.240.197.239]) by smtp.gmail.com with ESMTPSA id c20sm27289994wrb.65.2020.06.24.23.57.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2020 23:57:27 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" References: <41177396-9944-0bbd-66d2-8b4f2bd063f0@suse.com> In-Reply-To: Subject: RE: Ping: [PATCH] x86/CPUID: fill all fields in x86_cpuid_policy_fill_native() Date: Thu, 25 Jun 2020 07:57:27 +0100 Message-ID: <000101d64abd$e376b3d0$aa641b70$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFLSWsOaDQxr3vkX7lc5kkKH9cReQClPCHVAeSkPHCp6pnN4A== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= , 'Wei Liu' , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 24 June 2020 16:36 > To: Paul Durrant > Cc: Andrew Cooper ; = xen-devel@lists.xenproject.org; Wei Liu ; > Roger Pau Monn=C3=A9 > Subject: Ping: [PATCH] x86/CPUID: fill all fields in = x86_cpuid_policy_fill_native() >=20 > (sorry, re-sending with To and Cc corrected) >=20 > On 22.06.2020 14:39, Andrew Cooper wrote: > > On 22/06/2020 13:09, Jan Beulich wrote: > >> Coverity validly complains that the new call from > >> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() = leaves > >> two fields uninitialized, yet they get then consumed by > >> x86_cpuid_copy_to_buffer(). (All other present callers of the = function > >> pass a pointer to a static - and hence initialized - buffer.) > >> > >> Coverity-ID: 1464809 > >> Fixes: c22ced93e167 ("tests/cpu-policy: Confirm that CPUID = serialisation is sorted") > >> Signed-off-by: Jan Beulich > >> > >> --- a/xen/lib/x86/cpuid.c > >> +++ b/xen/lib/x86/cpuid.c > >> @@ -176,6 +176,10 @@ void x86_cpuid_policy_fill_native(struct > >> ARRAY_SIZE(p->extd.raw) - 1); ++i ) > >> cpuid_leaf(0x80000000 + i, &p->extd.raw[i]); > >> > >> + /* Don't report leaves from possible lower level hypervisor. = */ > > > > ", for now." > > > > This will change in the future. > > > > With this, Reviewed-by: Andrew Cooper >=20 > Paul? Release-acked-by: Paul Durrant >=20 > Thanks, Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 25 07:03:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 07:03:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLus-0004Df-70; Thu, 25 Jun 2020 07:03:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLur-0004Da-3s for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 07:03:21 +0000 X-Inumbo-ID: f38b0644-b6b1-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f38b0644-b6b1-11ea-bca7-bc764e2007e4; Thu, 25 Jun 2020 07:03:20 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id j18so4451918wmi.3 for ; Thu, 25 Jun 2020 00:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Ffp6vk9DWgyyb4JWQlJnOhmIiqEep57Li3Os6i2clXI=; b=gip3A8czL1UymoXE96iV0phAm0/m0iqBwYNf4u+EFtQ9+z4TwcbG/QQY9TDiQSFOa4 3fCtkRb3Esz+d6AeX0JgLMnKWfazhfH9BQx1GSjeBFqi4FI4gwdhFxxqACkdHczqyImb MKm4aAVHNQ6P/0CXaIvSWmpxPq/SMSTEFm718NWGOmFJeg0qiZxQvR/4qu4u7O+No9MW sgidJEbHBsvPzQPYAXLJLhoxnFPsO5JBAUgTFKMfKN/LaiWExxYd+2I42YHAAe2rYjyN dnDj+NZgHfdYiGgkFNSs2GMKVC9bUij3iADE8RJfv1AHXLkkmP7NGHhlvGeF8gDjVNj6 5htg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=Ffp6vk9DWgyyb4JWQlJnOhmIiqEep57Li3Os6i2clXI=; b=uZ3HHjQSTnJ5Kn+F96erCav04yneFO8wE0K+zdTZCMUYDoTAe3NbCUcBD2yv7bIYx5 Qg/qAydm+cDZP2G6rG7DhkbYY/Uds9Wiez0vL/dVn9xoFcaHHxfzJDkn4AUYnErp9qUS yjtTr5ffYcPKyelCgDBQXkFlg5PeP0l+qL+Ogw9OSZnkY8c6WQNVXuQyoQqQ6mVtZ9Is nEpn/XkODljI4Jf2o8RO+iAioJNryGcA/0PyrXTERJy4t5v31Ar4vnHTqsri8iaj9npw DHbVyEn/8ycXlAESfmTaoGCgqXrAXRCTxmLjxiuwtVFI60ptqJZf81EBKc5E6hdGqahY 5wlQ== X-Gm-Message-State: AOAM531yYd/Gdkkc0NBIGGmC55WC0pYfXmvFRP6OKplJTEhSfYxfHqRn U0O5NGbODvPrlYzEOknc3/I= X-Google-Smtp-Source: ABdhPJxLR87+GuFn6T6t7fpAoLDZCtIAFt/+DaCbFEQ8p/TinVIq+lPIJCT+mkQQEKjpzlLEQdzwQw== X-Received: by 2002:a7b:c952:: with SMTP id i18mr1830017wml.65.1593068599553; Thu, 25 Jun 2020 00:03:19 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-231.amazon.com. [54.240.197.231]) by smtp.gmail.com with ESMTPSA id n8sm27072610wrj.44.2020.06.25.00.03.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jun 2020 00:03:18 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Jan Beulich'" References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> In-Reply-To: <24307.32018.502303.817846@mariner.uk.xensource.com> Subject: RE: [XEN RFC for-4.14] Re: use of "stat -" Date: Thu, 25 Jun 2020 08:03:17 +0100 Message-ID: <000201d64abe$b4ab86b0$1e029410$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQD9L7QdWbiS7yjvIZuWryR1qUi3DAIffsZsAXaO/qwBr8ysOQGBdD/EAyVLdE8CJhcjaQKGFSQfAwf2ZywCggq8zwIiPKyoAIo7x5+p5KOqMA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , xen-devel@lists.xenproject.org, 'Wei Liu' , 'Elliott Mitchell' , 'Jason Andryuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 24 June 2020 17:20 > To: Jan Beulich > Cc: Elliott Mitchell ; Andrew Cooper ; Jason Andryuk > ; Paul Durrant ; Wei Liu ; xen- > devel@lists.xenproject.org > Subject: [XEN RFC for-4.14] Re: use of "stat -" > > Jan Beulich writes ("Re: use of "stat -""): > > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments unless you have verified > the sender and know the content is safe. > > On 14.05.2020 13:02, Ian Jackson wrote: > > > I've read this thread. Jan, I'm sorry that this causes you > > > inconvenience. I'm hoping it won't come down to a choice between > > > supporting people who want to ship a dom0 without perl, and people who > > > want a dom0 using more-than-a-decade-old coreutils. > > > > > > Jan, can you tell me what the output is of this on your ancient > > > system: > > > > > > $ rm -f t > > > $ >t > > > $ exec 3 > > $ stat -L -c '%F %i' /dev/stdin <&3 > > > regular empty file 393549 > > > $ rm t > > > $ stat -L -c '%F %i' /dev/stdin <&3 > > > regular empty file 393549 > > > $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 > > > $ > > > > $ rm -f t > > $ >t > > $ exec 3 > $ stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 3380369 > > $ rm t > > $ stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 3380369 > > $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 3380369 > > > > > Also, the contents of the file "u" afterwards, please. > > > > Attached. > > Thanks. > > I think this means that `stat -' can be replaced by `stat /dev/stdin'. > > This script is only run on Linux where /dev/stdin has existed > basically forever. The strace output shows > stat("/dev/stdin", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > and the transcript shows that your stat(1) behaves as I hope. > > Jan, will you send a patch ? It is best if someone else but me writes > it and tests it because then I am a "clean" reviewer. > > Paul, supposing I review such a patch and say it is low risk, and we > commit it by Friday, can it have a release-ack ? > In principle yes but, given Jason's response, it doesn't sound like we have agreement on what the final patch will look like yet. Paul > Thanks, > Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 07:05:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 07:05:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLwy-0004Ks-Nl; Thu, 25 Jun 2020 07:05:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joLwx-0004Kk-FG for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 07:05:31 +0000 X-Inumbo-ID: 41291116-b6b2-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 41291116-b6b2-11ea-b7bb-bc764e2007e4; Thu, 25 Jun 2020 07:05:30 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 766B7AF23; Thu, 25 Jun 2020 07:05:29 +0000 (UTC) Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" To: Jason Andryuk , Ian Jackson References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> From: Jan Beulich Message-ID: <6cd9c568-84b9-8304-d56f-99d628d945a1@suse.com> Date: Thu, 25 Jun 2020 09:05:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , "xen-devel@lists.xenproject.org" , Wei Liu , Elliott Mitchell , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 25.06.2020 04:37, Jason Andryuk wrote: > On Wed, Jun 24, 2020 at 12:19 PM Ian Jackson wrote: >> >> Jan Beulich writes ("Re: use of "stat -""): >>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments unless you have verified the sender and know the content is safe. >>> On 14.05.2020 13:02, Ian Jackson wrote: >>>> I've read this thread. Jan, I'm sorry that this causes you >>>> inconvenience. I'm hoping it won't come down to a choice between >>>> supporting people who want to ship a dom0 without perl, and people who >>>> want a dom0 using more-than-a-decade-old coreutils. >>>> >>>> Jan, can you tell me what the output is of this on your ancient >>>> system: >>>> >>>> $ rm -f t >>>> $ >t >>>> $ exec 3>>> $ stat -L -c '%F %i' /dev/stdin <&3 >>>> regular empty file 393549 >>>> $ rm t >>>> $ stat -L -c '%F %i' /dev/stdin <&3 >>>> regular empty file 393549 >>>> $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 >>>> $ >>> >>> $ rm -f t >>> $ >t >>> $ exec 3>> $ stat -L -c '%F %i' /dev/stdin <&3 >>> regular empty file 3380369 >>> $ rm t >>> $ stat -L -c '%F %i' /dev/stdin <&3 >>> regular empty file 3380369 >>> $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 >>> regular empty file 3380369 >>> >>>> Also, the contents of the file "u" afterwards, please. >>> >>> Attached. >> >> Thanks. >> >> I think this means that `stat -' can be replaced by `stat /dev/stdin'. >> >> This script is only run on Linux where /dev/stdin has existed >> basically forever. The strace output shows >> stat("/dev/stdin", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 >> and the transcript shows that your stat(1) behaves as I hope. >> >> Jan, will you send a patch ? It is best if someone else but me writes >> it and tests it because then I am a "clean" reviewer. I was about to, when I saw this reply from Jason. >> Paul, supposing I review such a patch and say it is low risk, and we >> commit it by Friday, can it have a release-ack ? > > I was going to just write a patch to replace - with /dev/stdin and ask > Jan to test it. When I opened the script, this comment was staring at > me: > # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or > # use bash's test -ef because those all go through what is > # actually a synthetic symlink in /proc and we aren't > # guaranteed that our stat(2) won't lose the race with an > # rm(1) between reading the synthetic link and traversing the > # file system to find the inum. > > On my system: > $ ls -l /dev/stdin > lrwxrwxrwx 1 root root 15 Jun 24 21:13 /dev/stdin -> /proc/self/fd/0 > $ ls -l /proc/self/fd/0 0 lrwx------ 1 jason jason 64 Jun 24 21:26 /proc/self/fd/0 -> /home/jason/lockfile > > stat /dev/stdin will work around the lack of `stat -` support, but it > doesn't address the race in the comment. Is the comment valid? How > would we prove there is no race for /dev/stdin? And as a refresher, > `stat -` does an fstat(0), so there is no symlink lookup. Or is there > no race since `stat /proc/self/fd/0` isn't a symlink lookup but just > accessing the already open fd via the proc special file? i.e. > equivalent to fstat. Looking at vfs_statx() in the kernel, I can't see any provisions to get at the data without traversing the specified path. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 25 07:27:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 07:27:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joMIJ-00063u-Hp; Thu, 25 Jun 2020 07:27:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joMII-00063p-P8 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 07:27:34 +0000 X-Inumbo-ID: 5638fa82-b6b5-11ea-8496-bc764e2007e4 Received: from mail-qt1-x843.google.com (unknown [2607:f8b0:4864:20::843]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5638fa82-b6b5-11ea-8496-bc764e2007e4; Thu, 25 Jun 2020 07:27:34 +0000 (UTC) Received: by mail-qt1-x843.google.com with SMTP id d27so3901141qtg.4 for ; Thu, 25 Jun 2020 00:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=eEZh0tTaT8zh5LL7N/hn9RvEV8NMH79zD1VRD/2Jbbw=; b=a7UwVx7WYGVzQyi5Hhk8M4DYU2kStSPTaeFf3iil0fkV5B6MyjeeVVYX9BlmbojEcc n/aRI0cHRhjpxZS1EagCkhDj2uS5ZisK6k/xg3ineSMdK6o6ScqR89yOTpVEpauhhOBd KGwpSIsEn2IBrXEPM5dEAGt4eMvX9GSh+XxdMHh3AW7fpQLZU0REmV3+TkNSkKWIgnN0 VB8QID3QcpuC3OkdD+2KhC/c2Fb9G425sqltJ/Tdm+faX/cNnKDshgTiGnjwlDSh0hoT DQbNndO7UlcrSvp+uK4D0QqnaV/4Wp0ye+9CTcKat7lRL+Lv8cFxcgF3PTG7EQuXgO/J g1rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=eEZh0tTaT8zh5LL7N/hn9RvEV8NMH79zD1VRD/2Jbbw=; b=aeq/sRyIaTydk7pCy4/jW8Pe1cxAcmgDR3RGkABkiBwQY70bN8g+ZEAt4BkhtSYgBS 3MDmLWvXxJ7Rye7TNOrplTpGgyb44EQixcwAPidBMd1yK7HXgpPKu+/joraEE1g7ozCH mdt6RMVlHDa/t7s/Uj5oMI9d3+Rv1mruZB1FLN+0qnHzBWok3oLkb5Swq8X5AAqPyP9N d0Jrf4eIrWlaRTrJ4oNHTwhW8YFxgOZHJbH1ikgycNfqf6KlkSSXqprhZEXDYfWTNLLS jMXyEjI/UCL8lYJ+v9zdsrq+H1TsV30uhvKv1W9YyT8dO5ujMsPvzqEpk9wZ9YOS69Hl zEyA== X-Gm-Message-State: AOAM5330cIxUkvdzFUfnoN+YVATbLNb9dmuejo2jhRvfHGzo7AxGVNO+ aqkwYUYH3f198wZA4aTWpmY= X-Google-Smtp-Source: ABdhPJyJyAn/vGNlypE6poVXGWQBftOZ9JkatcsvllRbhBckUmpXv1zurNoWnMAGiQzC/suVNhrBHA== X-Received: by 2002:ac8:8a4:: with SMTP id v33mr21911252qth.392.1593070053657; Thu, 25 Jun 2020 00:27:33 -0700 (PDT) Received: from ?IPv6:2607:fb90:e854:3fa:dec:cecd:b019:e1d1? ([2607:fb90:e854:3fa:dec:cecd:b019:e1d1]) by smtp.gmail.com with ESMTPSA id n63sm5326271qkn.104.2020.06.25.00.27.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Jun 2020 00:27:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Rich Persaud Mime-Version: 1.0 (1.0) Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" Date: Thu, 25 Jun 2020 03:27:31 -0400 Message-Id: References: In-Reply-To: To: Jason Andryuk , Ian Jackson , =?utf-8?Q?Marek_Marczykowski-G=C3=B3recki?= , Jan Beulich X-Mailer: iPhone Mail (17F75) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , "xen-devel@lists.xenproject.org" , Elliott Mitchell , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Jun 24, 2020, at 22:39, Jason Andryuk wrote: >=20 > =EF=BB=BFOn Wed, Jun 24, 2020 at 12:19 PM Ian Jackson wrote: >>=20 >> Jan Beulich writes ("Re: use of "stat -""): >>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachment= s unless you have verified the sender and know the content is safe. >>>> On 14.05.2020 13:02, Ian Jackson wrote: >>>>> I've read this thread. Jan, I'm sorry that this causes you >>>>> inconvenience. I'm hoping it won't come down to a choice between >>>>> supporting people who want to ship a dom0 without perl, and people who= >>>>> want a dom0 using more-than-a-decade-old coreutils. >>>>>=20 >>>>> Jan, can you tell me what the output is of this on your ancient >>>>> system: >>>>>=20 >>>>> $ rm -f t >>>>> $ >t >>>>> $ exec 3>>>> $ stat -L -c '%F %i' /dev/stdin <&3 >>>>> regular empty file 393549 >>>>> $ rm t >>>>> $ stat -L -c '%F %i' /dev/stdin <&3 >>>>> regular empty file 393549 >>>>> $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 >>>>> $ >>>=20 >>> $ rm -f t >>> $ >t >>> $ exec 3>> $ stat -L -c '%F %i' /dev/stdin <&3 >>> regular empty file 3380369 >>> $ rm t >>> $ stat -L -c '%F %i' /dev/stdin <&3 >>> regular empty file 3380369 >>> $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 >>> regular empty file 3380369 >>>=20 >>>> Also, the contents of the file "u" afterwards, please. >>>=20 >>> Attached. >>=20 >> Thanks. >>=20 >> I think this means that `stat -' can be replaced by `stat /dev/stdin'. >>=20 >> This script is only run on Linux where /dev/stdin has existed >> basically forever. The strace output shows >> stat("/dev/stdin", {st_mode=3DS_IFREG|0644, st_size=3D0, ...}) =3D 0 >> and the transcript shows that your stat(1) behaves as I hope. >>=20 >> Jan, will you send a patch ? It is best if someone else but me writes >> it and tests it because then I am a "clean" reviewer. >>=20 >> Paul, supposing I review such a patch and say it is low risk, and we >> commit it by Friday, can it have a release-ack ? >=20 > I was going to just write a patch to replace - with /dev/stdin and ask > Jan to test it. When I opened the script, this comment was staring at > me: > # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or > # use bash's test -ef because those all go through what is > # actually a synthetic symlink in /proc and we aren't > # guaranteed that our stat(2) won't lose the race with an > # rm(1) between reading the synthetic link and traversing the > # file system to find the inum. >=20 > On my system: > $ ls -l /dev/stdin > lrwxrwxrwx 1 root root 15 Jun 24 21:13 /dev/stdin -> /proc/self/fd/0 > $ ls -l /proc/self/fd/0 0 lrwx------ 1 jason jason 64 Jun 24 21:26 /proc/self/fd/0 -> /home/jason/lo= ckfile >=20 > stat /dev/stdin will work around the lack of `stat -` support, but it > doesn't address the race in the comment. Is the comment valid? How > would we prove there is no race for /dev/stdin? And as a refresher, > `stat -` does an fstat(0), so there is no symlink lookup. Or is there > no race since `stat /proc/self/fd/0` isn't a symlink lookup but just > accessing the already open fd via the proc special file? i.e. > equivalent to fstat. >=20 > I've mentioned it before, but maybe we should just use the Qubes > patch. It leaves the lockfile even when no-one is holding the lock, > but it simplifies the code and sidesteps the issues we are discussing > here. > https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.13/patch-tools-hotplug= -drop-perl-usage-in-locking-mechanism.patch Is there any practical downside to the Qubes patch, which is already deploye= d on production systems? The complexity of other approaches has been reflec= ted in code and prior discussion. If needed, the comments in the Qubes patc= h could be expanded, when merging that well-tested code into 4.14. Rich= From xen-devel-bounces@lists.xenproject.org Thu Jun 25 08:14:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 08:14:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joN1h-0002Bc-I4; Thu, 25 Jun 2020 08:14:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joN1g-0002BW-DW for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 08:14:28 +0000 X-Inumbo-ID: e2aeaef2-b6bb-11ea-8184-12813bfff9fa Received: from EUR01-VE1-obe.outbound.protection.outlook.com (unknown [40.107.14.49]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e2aeaef2-b6bb-11ea-8184-12813bfff9fa; Thu, 25 Jun 2020 08:14:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fr/XeToECV2dwSWdbXEo2mKcFRRFHdG64R4BebP1dMY=; b=Lzj11QbhbeiZT53IzxpoFv6BER1AbKq08WIQ9VdkT8bGueLpU7kiNkZ5DfblDorIL2Mqgidt0yT8rcfq0feq0/Ni++QhQJhivNDBKvLzOF1MeYrk78q8AEJ128qDTdG2nsEvMKOnKSsCBZhDZH7YHGO+WeOy6Srs6cuMJQNCMFY= Received: from DB3PR08CA0019.eurprd08.prod.outlook.com (2603:10a6:8::32) by VI1PR08MB4111.eurprd08.prod.outlook.com (2603:10a6:803:ed::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Thu, 25 Jun 2020 08:14:24 +0000 Received: from DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com (2603:10a6:8:0:cafe::f1) by DB3PR08CA0019.outlook.office365.com (2603:10a6:8::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend Transport; Thu, 25 Jun 2020 08:14:24 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT060.mail.protection.outlook.com (10.152.21.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Thu, 25 Jun 2020 08:14:24 +0000 Received: ("Tessian outbound da41658aa5d4:v59"); Thu, 25 Jun 2020 08:14:24 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: f13a4b04593570c9 X-CR-MTA-TID: 64aa7808 Received: from 64c281aa9bed.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D2F03F1F-506D-4B09-8437-49D1247F77EE.1; Thu, 25 Jun 2020 08:14:18 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 64c281aa9bed.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 25 Jun 2020 08:14:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U3IKsqnmiI2nXiSz3Lhg+V8eq842aMiHJ6+HBahRPtS1WjEG7BhAMwZb5KZWGWmeNF9DTVGHYzX3BpYT/UE+EgQ0gyPB48LUgt6xcZ9oVYknVgYUuRk3KVcvd8CbibwnPiqdaMsPP2tnjkt1fnR+pFlOe5cqC0/SK8XV6n5aSPlYvC2LAXNkwUvXOjxrM5wE2prInBxqaaZw1R993X413i00C5ld7q+3S2LTRLgnJ+K2Tvj/Q5Kt1RyEbc4xdl7YSFBOFmLIPRS6ku1H8Y+Sgq5npjJC1AMgsj+aAJLcetFd5YdST2MTJz8gGIJJo9ES5hkymSLbyARdpPq+5B7vPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fr/XeToECV2dwSWdbXEo2mKcFRRFHdG64R4BebP1dMY=; b=jSsGbzTwb4xrtSOLYU9VaDSnVr3HQQ5FWgi9UhUL6c2Il00Tp1AC18qqcwBS9+ZAaUSK1xF0VecTFOz5IkXcSMwtp2WZd1JV62F/pd6DgDewZ4y0PZGxxc7owaju+Ob5H1oTChmbP+MmTdP4ynTWjrvRbOaG/GdRFyR6j9yexhFSJrFCGedisKxjtR4OgExzBfuGFuPdQ/MuwwEiiGDXBmNvTbgcEU6sUjo1qFXRGfXDf8aXz078bkbKSNYSrR0tQPrJo32o1oNJ6hJbeRMvEX9/uE7jWFEYaRLyMQRw7iXMYvPI45UUa2//+UJ1Lcu1p4Kzk/bOt5yeuECTvY+b4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fr/XeToECV2dwSWdbXEo2mKcFRRFHdG64R4BebP1dMY=; b=Lzj11QbhbeiZT53IzxpoFv6BER1AbKq08WIQ9VdkT8bGueLpU7kiNkZ5DfblDorIL2Mqgidt0yT8rcfq0feq0/Ni++QhQJhivNDBKvLzOF1MeYrk78q8AEJ128qDTdG2nsEvMKOnKSsCBZhDZH7YHGO+WeOy6Srs6cuMJQNCMFY= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB7PR08MB3849.eurprd08.prod.outlook.com (2603:10a6:10:79::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Thu, 25 Jun 2020 08:14:16 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3131.023; Thu, 25 Jun 2020 08:14:16 +0000 From: Bertrand Marquis To: Stefano Stabellini Subject: Re: Proposal: rename xen.git#master (to #trunk, perhaps) Thread-Topic: Proposal: rename xen.git#master (to #trunk, perhaps) Thread-Index: AQHWSkKdIKK1EWuhmkmnd7oeEQV+hajoCCEAgAD0lIA= Date: Thu, 25 Jun 2020 08:14:16 +0000 Message-ID: References: <24307.31637.214096.240023@mariner.uk.xensource.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: ccc7c216-6c5b-4836-e0e5-08d818dfc55f x-ms-traffictypediagnostic: DB7PR08MB3849:|VI1PR08MB4111: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0445A82F82 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: WZOIAy7f3W6zlzcgKP1bWocpG66GI1GFNYtusBpLMBRQuEHoui4AbHaNESKfooBT72+26b32NpUDwKYRiIKH3yC9rEpOJzJQX53hmUkb3teraNGWnFr4SfMBulD/G7CTCSkX+u3P1MJWnI/SSN0gFvEoQXkuHnZvNQfxL8HogKmUKDfTmk8O3vd92Vw3cfX/4A3VsfaHCWLtRgoL2hjp51cLppW/AV2bSZrQnCXwriMHACzWUWt9usXA8NR7OLVaweEAu5lm6xIbmQqhfb8fyXrL5GEjTc2pqPfwnbfn8MzsTGyZykxv4hY6IvVH60arnVVeRb0FrtC/Y46u5tz90K9scHcPx+gsrS6yjXt91ulxEsicAvZOyzYS96yHzzmoWNSNPFdmT5GHTWVpilydMA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(366004)(376002)(346002)(86362001)(6486002)(5660300002)(6916009)(26005)(8936002)(33656002)(54906003)(36756003)(91956017)(66446008)(71200400001)(186003)(64756008)(66946007)(4326008)(76116006)(66556008)(66476007)(316002)(478600001)(53546011)(2616005)(966005)(2906002)(6506007)(8676002)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: mE8N5tmnBaTZYCPH5HGPznavJ+M7/YxT4NCo5+2djwFNRYvqoNn/Efii/+djcUyNBPnNTOPZFH6TnRYp9J0z/fxwp5wNzhSmIS1KAcqS9I04uYe8ATlvof2n/85x2Us83ykEZqpkMwQyRmu9edAB5zAjGdkBYRlt1+qithLn5MvpT4NEKeXxvK+X5lllCwW0TnXUI3atKMoFstFiXDTBsRwkuMiDaQy1WNyPKs/XTUyoFuhoNN3GXWQZDB7CMA4o40yhItwFk8HkvFmX0HWLsEgK8KhcsusyDZPJpOQt2uf54C+PMUhBrtp7JbBlTfiSyALQAvgvxB32TVcvDyV1xJqCIESE0ND3E7UymrfdkypYFHVxQNo2wghi+zhB2vBfESaEEYNOPyf6dpElX2Zr6WmDW6fl92bk3ItbRnDeOvwkHk4jZn+JKntuOVU68p2BNp9B1Bat+KdvoPHCNtMFFw3DlezImxhD4OmaUTPj45o= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <80823069153A3F438DC0F68A531D57E1@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3849 Original-Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(39860400002)(396003)(46966005)(70586007)(36756003)(5660300002)(2906002)(70206006)(478600001)(33656002)(6862004)(6512007)(6486002)(4326008)(186003)(86362001)(26005)(336012)(82740400003)(81166007)(47076004)(356005)(2616005)(316002)(82310400002)(6506007)(53546011)(966005)(8936002)(8676002)(54906003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: d1abd0e9-ccaf-4d82-247e-08d818dfc0a4 X-Forefront-PRVS: 0445A82F82 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: x9kVtMVERHdr2n4T3lNquK0j4oMYxGVLFy0GRACoo7CuLkOXd+KRQTky8sq+2yBNEZrjlTPfwqwDB/bNnE2KCm6VxZLl7O1JxHtEXhOwp/O6cLG4E/FGK+9zUwRMBz1m2E5EEACzwTiimjeiT5GAuPWWwLCIOC/dXp8HGAFMpKGXScK2dfchA58tbvDZVYIp2wlR/t2w1ZNHaHBk7JIdpUQlGGalmMauPSaJygBNlvy0oF5LgVmSox0T2cWfCto1tBe8+0HPeXxUJc8GWnzjt9pDi31nf7h5HwJheEcDuecof/RXzDYNGN7/GeQfYNBteDKtguWmvtsYe2i4An76oKytWanH30OAykQ6V4QytSg9NaBGAVsWJ2urTLpEbUlJPOKBL4sdYEymYEcYW38ZQlP25idV5Pn9Lvr4pMGAkXIs4z+tyztZ6XRO8fMgKW+jYOfokMTxTyvf2AJ4k1rEhRTrbfe0b+E6LoTx5RTzST0= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jun 2020 08:14:24.1013 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ccc7c216-6c5b-4836-e0e5-08d818dfc55f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB4111 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , nd , "committers@xenproject.org" , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > On 24 Jun 2020, at 18:38, Stefano Stabellini wro= te: >=20 > On Wed, 24 Jun 2020, Ian Jackson wrote: >> I think it would be a good idea to rename this branch name. This name >> has unfortunate associations[1], even if it can be argued[2] that the >> etymology is not as bad as in some uses of the word. >>=20 >> This is relativity straightforward on a technical level and will >> involve a minimum of inconvenience. Since only osstest ever pushes to >> xen.git#master, we could easily make a new branch name and also keep >> #master for compatibility as long as we like. >>=20 >> The effects[1] would be: >>=20 >> Users who did "git clone https://xenbits.xen.org/git-http/xen.git"" >> would find themselves on a branch called "trunk" which tracked >> "origin/trunk", by default. (Some users with old versions of git >> using old protocols would still end up on "master".) >>=20 >> Everyone who currently tracks "master" would be able to switch to >> tracking "trunk" at their leisure. >>=20 >> Presumably at some future point (a year or two from now, say) we would >> abolish the name "master". >>=20 >> Comments ? In particular, comments on: >>=20 >> 1. What the new branch name should be called. Suggestions I have seen >> include "trunk" and "main". I suggest "trunk" because this was used >> by SVN, CVS, RCS, CSSC (and therefore probably SCCS) for this same >> purpose. >=20 > Github seems to be about to make a similar change. I wonder if we should > wait just a couple of weeks to see what name they are going to choose. >=20 > https://www.theregister.com/2020/06/15/github_replaces_master_with_main/ >=20 >=20 > Of course I don't particulalry care one way or the other, but it would > be good if we end up using the same name as everybody else. It is not > that we have to choose the name Github is going to choose, but their > user base is massive -- whatever they are going to pick is very likely > going to stick. +1 to stefano Whatever choice is made here it would be better to follow standards to prev= ent user from being lost. And github is definitely a bit actor :-) Bertrand >=20 >=20 >=20 >> 2. Do we want to set a time now when the old name will be removed ? >> I think 12 months would be good but I am open to arguments. >>=20 >> In any case in my capacity as osstest maintainer I plan to do >> something like this. The starting point is rather different. There >> will have to be an announcement about that, but I thought I would see >> what people thought about xen.git before pressing ahead there. >>=20 >> Thanks, >> Ian. >>=20 >> [1] It seems that for a significant number of people the word reminds >> them of human slavery. This seems undesirable if we can easily avoid >> it, if we can. >>=20 >> [2] The precise etymology of "master" in this context is unclear. It >> appears to have come from BitKeeper originally. In any case the >> etymology is less important than the connotations. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 09:06:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 09:06:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joNph-0006Fg-GJ; Thu, 25 Jun 2020 09:06:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joNpg-0006Fb-Gu for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 09:06:08 +0000 X-Inumbo-ID: 16aaeb38-b6c3-11ea-bb8b-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 16aaeb38-b6c3-11ea-bb8b-bc764e2007e4; Thu, 25 Jun 2020 09:06:01 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: NpTbVswjo87d4caBxN9k+22+xmt/dGD2e+OOGemKXq5UnATBigsn9aqNzbgmARQ7/NZ1wzWgmM 681gYm76hdW8A1FxFmu6PUFIDlzY58IkHs5qkPuloyqIgoxXABYoWFyemp3cGlyLkZUTAURSkm aXBIneIttUtTvdlExngsVZpD7++5F0plLZcI9UtgGn+xzGr89iaK/bom22sOjnwu8Crd4LUcuO DW4KYScaA4G8Z2gH1YRHyybqaEudg3PM848kJX6IYS81NE396MYljv7yrnNKAhlIjXl8+h3ku3 WJg= X-SBRS: 2.7 X-MesageID: 20910537 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,278,1589256000"; d="scan'208";a="20910537" Date: Thu, 25 Jun 2020 11:05:52 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource Message-ID: <20200625090552.GW735@Air-de-Roger> References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 04:01:44PM +0200, Jan Beulich wrote: > On 24.06.2020 15:41, Julien Grall wrote: > > On 24/06/2020 11:12, Jan Beulich wrote: > >> On 23.06.2020 19:26, Roger Pau Monné wrote: > >>> I'm confused. Couldn't we switch from uint64_aligned_t to plain > >>> uint64_t (like it's currently on the Linux headers), and then use the > >>> compat layer in Xen to handle the size difference when called from > >>> 32bit environments? > >> > >> And which size would we use there? The old or the new one (breaking > >> future or existing callers respectively)? Meanwhile I think that if > >> this indeed needs to not be tools-only (which I still question), > > > > I think we now agreed on a subthread that the kernel needs to know the > > layout of the hypercall. > > > >> then our only possible route is to add explicit padding for the > >> 32-bit case alongside the change you're already making. > > > > AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make > > incompatible the two incompatible? > > In principle yes. But they're putting the structure instance on the > stack, so there's not risk from Xen reading 4 bytes too many. I'd > prefer keeping the interface as is (i.e. with the previously > implicit padding made explicit) to avoid risking to break other > possible callers. But that's just my view on it, anyway ... Adding the padding is cleaner because we don't need any compat stuff in order to access the structure from the caller, and we also keep the original layout currently present on Xen headers. I can prepare a fix for the Linux kernel, if this approach is fine. Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 09:25:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 09:25:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joO7o-0007ve-5o; Thu, 25 Jun 2020 09:24:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joO7n-0007vZ-Cg for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 09:24:51 +0000 X-Inumbo-ID: b86fbe06-b6c5-11ea-818b-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b86fbe06-b6c5-11ea-818b-12813bfff9fa; Thu, 25 Jun 2020 09:24:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uT8yp1vueWRxG+AUh0WvEoJgInnLT9zSJamoBslAAjo=; b=P8PuKnNF7A7p9UXvZKI/BUGisq 1FX7DwSJSjkG8tWGu+ox2znjZhRbhF46kkfx+JWEnPPtDaJ4pNDv1ad3ZJqM1YKMoKznP/e9TB1BY LcO1ZHhmDmlrs+rlQKOQy/JLPdkTfbbje7MFS0KtiBcd/GLRNrZp/zplG0vkmndG45pc=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joO7k-0002sm-RQ; Thu, 25 Jun 2020 09:24:48 +0000 Received: from [54.239.6.186] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1joO7k-0006rT-KJ; Thu, 25 Jun 2020 09:24:48 +0000 Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: Jan Beulich References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> From: Julien Grall Message-ID: Date: Thu, 25 Jun 2020 10:24:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Jan, On 24/06/2020 15:01, Jan Beulich wrote: > On 24.06.2020 15:41, Julien Grall wrote: >> On 24/06/2020 11:12, Jan Beulich wrote: >>> On 23.06.2020 19:26, Roger Pau Monné wrote: >>>> I'm confused. Couldn't we switch from uint64_aligned_t to plain >>>> uint64_t (like it's currently on the Linux headers), and then use the >>>> compat layer in Xen to handle the size difference when called from >>>> 32bit environments? >>> >>> And which size would we use there? The old or the new one (breaking >>> future or existing callers respectively)? Meanwhile I think that if >>> this indeed needs to not be tools-only (which I still question), >> >> I think we now agreed on a subthread that the kernel needs to know the >> layout of the hypercall. >> >>> then our only possible route is to add explicit padding for the >>> 32-bit case alongside the change you're already making. >> >> AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make >> incompatible the two incompatible? > > In principle yes. But they're putting the structure instance on the > stack, so there's not risk from Xen reading 4 bytes too many. I'd > prefer keeping the interface as is (i.e. with the previously > implicit padding made explicit) to avoid risking to break other > possible callers. But that's just my view on it, anyway ... It makes sense to me. As Roger said, we would also want to update the Linux kernel header for future release. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Jun 25 09:33:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 09:33:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joOG0-0000MB-1d; Thu, 25 Jun 2020 09:33:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joOFy-0000M6-O8 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 09:33:18 +0000 X-Inumbo-ID: e5a8ab66-b6c6-11ea-818c-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e5a8ab66-b6c6-11ea-818c-12813bfff9fa; Thu, 25 Jun 2020 09:33:16 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: z9KMsgTj9i2pS/wFcP+GLTq7gByjR0h799ge7osmNSL4vrk9VAuIy9lz7Or6qcqbNhdBnzCNFV iv3JOuBntz7hTpS3jUADoeclLRjkE5yNV2H4M2P4FMOYzdKKep0ZkulUgdJzpifdxBll1vwQcK iQOlkQ8W3gNIKQQj5JHHmbGg66EHE8DQecENTH+TVO/OIY8wlXKuGPQWUiRR4ovCbCzQkSli4d xLhPhli1wUKlxCbHrflluKfOzuYJVEYo+E54Dko2wfugKh590wywbuxqdslanf+fHPYtTqMAP+ 35E= X-SBRS: 2.7 X-MesageID: 20911906 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,278,1589256000"; d="scan'208";a="20911906" Date: Thu, 25 Jun 2020 11:33:09 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julien Grall Subject: Re: [PATCH for-4.14 v2] x86/tlb: fix assisted flush usage Message-ID: <20200625093309.GX735@Air-de-Roger> References: <20200623145006.66723-1-roger.pau@citrix.com> <741ff589-4366-1430-6639-13dc5f02fdfa@xen.org> <20200623151542.GR735@Air-de-Roger> <20200623161607.GT735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 12:10:45PM +0100, Julien Grall wrote: > Hi Roger, > > On 23/06/2020 17:16, Roger Pau Monné wrote: > > On Tue, Jun 23, 2020 at 04:46:29PM +0100, Julien Grall wrote: > > > > > > > > > On 23/06/2020 16:15, Roger Pau Monné wrote: > > > > On Tue, Jun 23, 2020 at 04:08:06PM +0100, Julien Grall wrote: > > > > > Hi Roger, > > > > > > > > > > On 23/06/2020 15:50, Roger Pau Monne wrote: > > > > > > diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h > > > > > > index 9b62087be1..f360166f00 100644 > > > > > > --- a/xen/include/xen/mm.h > > > > > > +++ b/xen/include/xen/mm.h > > > > > > @@ -639,7 +639,8 @@ static inline void accumulate_tlbflush(bool *need_tlbflush, > > > > > > } > > > > > > } > > > > > > -static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) > > > > > > +static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp, > > > > > > + bool sync) > > > > > > > > > > I read the commit message and went through the code, but it is still not > > > > > clear what "sync" means in a non-architectural way. > > > > > > > > > > As an Arm developper, I would assume this means we don't wait for the TLB > > > > > flush to complete. But I am sure this would result to some unexpected > > > > > behavior. > > > > > > > > No, when we return from filtered_flush_tlb_mask the flush has been > > > > performed (either with sync or without), but I understand the > > > > confusion given the parameter name. > > > > > > > > > So can you explain on non-x86 words what this really mean? > > > > > > > > sync (in this context) means to force the usage of an IPI (if built > > > > with PV or shadow paging support) in order to perform the flush. > > > > > > This is compare to? > > > > Using assisted flushes, like you do on Arm, where you don't send an > > IPI in order to achieve a TLB flush on a remote pCPU. > > AFAICT, the assisted flushes only happen when running a nested Xen. Is that > correct? ATM yes, we don't have support for the newly introduced AMD INVLPGB instruction yet, which provides such functionality on bare metal. > > > > > > AFAICT on Arm you always avoid an IPI when performing a flush, and > > > > that's fine because you don't have PV or shadow, and then you don't > > > > require this. > > > > > > Arm provides instructions to broadcast TLB flush, so by the time one of > > > instruction is completed there is all the TLB entry associated to the > > > translation doesn't exist. > > > > > > I don't think using PV or shadow would change anything here in the way we do > > > the flush. > > > > TBH, I'm not sure how this applies to Arm. There's no PV or shadow > > implementation, so I have no idea whether this would apply or not. > > Yes there is none. However, my point was that if we had to implement > PV/shadow on Arm then an IPI would definitely be my last choice. Right, this mostly depends on how you perform page table modifications and whether you have to handle spurious faults like x86 does. > > > > > > > > I could rename to force_ipi (or require_ipi) if that's better? > > > > > > Hmmm, based on what I wrote above, I don't think this name would be more > > > suitable. However, regardless the name, it is not clear to me when a caller > > > should use false or true. > > > > > > Have you considered a rwlock to synchronize the two? > > > > Yes, the performance drop is huge when I tried. I could try to refine, > > but I think there's always going to be a performance drop, as you then > > require mutual exclusion when modifying the page tables (you take the > > lock in write mode). Right now modification of the page tables can be > > done concurrently. > > Fair enough. I will scratch that suggestion then. Thanks for the > explanation! > > So now getting back to filtered_flush_tlb(). AFAICT, the only two callers > are in common code. The two are used for allocation purpose, so may I ask > why they need to use different kind of flush? Looking at it again, this is wrong. I've just realized that populate_physmap will, depending on the situation, use the MEMF_no_tlbflush flag, and so it needs to perform the flush by itself (and that's why filtered_flush_tlb_mask is used). I guess you will be fine with removing the sync parameter then, and on x86 force filtered_flush_tlb_mask to always use physical IPIs in order to perform the flush? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 10:53:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 10:53:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joPUv-0006mv-3h; Thu, 25 Jun 2020 10:52:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joPUu-0006mS-3U for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 10:52:48 +0000 X-Inumbo-ID: fde40206-b6d1-11ea-8199-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fde40206-b6d1-11ea-8199-12813bfff9fa; Thu, 25 Jun 2020 10:52:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=b5mjuMzLCSlHL0KOS1qhO9nz1R7PVEAAx9bSM7nSIHs=; b=HbFVIWlSA5MbFuGnmxDbZGtEX f7DTi8VqafpDGueywz7X2eJ55UmQeN6jmg2Wj/2bX8tQWtGTj2cyw13oDBD1y3nl9w/oSxI0EaoRc +QVbzlyn+5QJ7xd576EQvl8F+jh3r9LwyeMon5V36md308XIwL3oiGOkzZ+tIIYm+v+WY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joPUm-0004ZY-O0; Thu, 25 Jun 2020 10:52:40 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joPUm-0006HP-GB; Thu, 25 Jun 2020 10:52:40 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joPUm-0000ki-FP; Thu, 25 Jun 2020 10:52:40 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151334: tolerable FAIL X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=fde76f895d0aa817a1207d844d793239c6639bc6 X-Osstest-Versions-That: xen=fde76f895d0aa817a1207d844d793239c6639bc6 From: osstest service owner Date: Thu, 25 Jun 2020 10:52:40 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151334 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151334/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151311 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151311 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151311 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151311 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151311 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151311 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151311 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151311 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151311 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen fde76f895d0aa817a1207d844d793239c6639bc6 baseline version: xen fde76f895d0aa817a1207d844d793239c6639bc6 Last test of basis 151334 2020-06-24 12:46:34 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 11:12:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 11:12:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joPnQ-0008Vc-Ou; Thu, 25 Jun 2020 11:11:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joPnP-0008VX-4R for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 11:11:55 +0000 X-Inumbo-ID: ac7f9350-b6d4-11ea-b7bb-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ac7f9350-b6d4-11ea-b7bb-bc764e2007e4; Thu, 25 Jun 2020 11:11:53 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 02LIdh77llNrgX3dSS0DEhchYIxzXcwH9bGbeso60Fy5irI5B4bDYroi+NYsrcyQHFbSS+jhKH jAo7CEndviVCKXy4wAQIw9bULCXJO3JIBTiGYED3i9PRoeXVAgAxBjQXNFPrJ7+3S4CGpiGLKF mkXSOeZnVKkjOLEeHaMX84ed9WEbjSapLAw/mkui5xIOUaIBux0/GqobcKPMZncZQmp5cXsxxF jHCFv/5mjX4lFsX2UrKozDEor1tNiFbva3WAPXFENPeKVLrdX+4neP0GJ5bxqEtsgYcgj8HkE1 QvQ= X-SBRS: 2.7 X-MesageID: 21213210 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="21213210" From: George Dunlap To: Andrew Cooper Subject: Re: Proposal: rename xen.git#master (to #trunk, perhaps) Thread-Topic: Proposal: rename xen.git#master (to #trunk, perhaps) Thread-Index: AQHWSkJf/KcO8yZ8r0St6dLs7upI+ajoQziAgADJk4A= Date: Thu, 25 Jun 2020 11:11:49 +0000 Message-ID: References: <24307.31637.214096.240023@mariner.uk.xensource.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <547B57430786C845A83E38BDE1F9DB8E@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , "committers@xenproject.org" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" DQoNCj4gT24gSnVuIDI1LCAyMDIwLCBhdCAxMjoxMCBBTSwgQW5kcmV3IENvb3BlciA8YW5kcmV3 LmNvb3BlcjNAY2l0cml4LmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAyNC8wNi8yMDIwIDE3OjEzLCBJ YW4gSmFja3NvbiB3cm90ZToNCj4+IEkgdGhpbmsgaXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8g cmVuYW1lIHRoaXMgYnJhbmNoIG5hbWUuDQoNCltzbmlwXQ0KDQo+IERlc2NyaWJpbmcgc29tZW9u ZSBhcyBhICJtYXN0ZXIgb2YgdGhlaXIgdHJhZGUvc2tpbGwvb3RoZXIiLCBpcyBhDQo+IHRvdGFs bHkgZGlmZmVyZW50IGNvbnRleHQsIGFuZCBpdCB3b3VsZCBiZSBleGNlc3NpdmUgdG8gc3VnZ2Vz dCBjaGFuZ2luZw0KPiB0aGUgbGFuZ3VhZ2UgdXNlZCBpbiB0aGlzIHdheS4gIFNvIHRvbywgaW4g bXkgb3BpbmlvbiwgaXMgbWFzdGVyIGFzIGluDQo+ICJtYXN0ZXIgY29weSIsIGEgZGlmZmVyZW50 IGNvbnRleHQgYW5kIGNvbm5vdGF0aW9uIHRvIG1hc3RlciBhcyBpbg0KPiBtYXN0ZXIvc2xhdmUu DQoNCklhbiBhbHJlYWR5IG5vdGVkIHRoYXQgdGhlcmUgd2FzIGEgcXVlc3Rpb24gYWJvdXQgdGhl IGV0eW1vbG9neSBvZiB0aGUgbmFtZSwgYnV0IGFyZ3VlZCB0aGF0IHdlIHNob3VsZCBjaGFuZ2Ug dGhlIG5hbWUgYW55d2F5LiAgV2l0aCBteSBjb21taXR0ZXIgaGF0IG9uLCBJIGFncmVlLg0KDQpX ZSBjb3VsZCBoYXZlIGEgbG9uZyBkaXNjdXNzaW9uIGFib3V0IHRoZSBvcmlnaW4gb2YgdmFyaW91 cyB0ZXJtcywgYW5kIGhvdyB3ZWxsIGVhY2ggb25lIGFwcGxpZXMgdG8gb3VyIG1haW4gZGV2ZWxv cG1lbnQgYnJhbmNoLiAgKEZvciBpbnN0YW5jZSwgaWYg4oCcbWFzdGVyIC9jb3B54oCdIGlzIHRo ZSByZWFsIGV0eW1vbG9neSBvZiB0aGUgZ2l0IG1hc3RlciBicmFuY2gsIEkgd291bGQgYXJndWUg dGhhdCBpdCB3YXMgdXNlZCBpbmFwcHJvcHJpYXRlbHk6IOKAnG1hc3RlciAvIGNvcHnigJ0gaXMg bW9zdCBhcHByb3ByaWF0ZSBpbiBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgdGhpbmcgYmVpbmcgY29w aWVkIGlzIG5lYXJseSBwZXJmZWN0IGFuZCBpcyByYXJlbHkgY2hhbmdlZC4gIFRoYXTigJlzIGNl cnRhaW5seSBub3QgdHJ1ZSBvZiBvdXIgbWFzdGVyIGJyYW5jaC4pDQoNCkJ1dCByZWFkaW5nIHRo ZSB3ZWF0aGVyLCBJIGhhdmUgdG8gY29uY2x1ZGUgdGhhdCBvdXIgaW5kdXN0cnkgaXMgZ29pbmcg aW4gdGhpcyBkaXJlY3Rpb24sIHdoZXRoZXIgd2UgbGlrZSBpdCBvciBub3QuICAoU2VlIGZvciBp bnN0YW5jZSBKb25hdGhhbiBDb3JiZXTigJlzIG9waW5pb24gcGllY2Ugb24gdGhlIHN1YmplY3Qg WzFdLCBhbmQgdGhlIHN1YnNlcXVlbnQgZGlzY3Vzc2lvbi4pICBBdCB0aGF0IHBvaW50LCB0aGUg Y29udGludWVkIHVzZSBvZiB0aGUgd29yZCDigJhtYXN0ZXLigJkgaXMgbm8gbG9uZ2VyIG5ldXRy YWw6IGl0IHdpbGwgYmVjb21lIGEgZGVsaWJlcmF0ZSBjaG9pY2Ugd2hpY2ggd2lsbCBiZWdpbiB0 byBjb21tdW5pY2F0ZSBzb21ldGhpbmcgd2hpY2ggd2UgZG9u4oCZdCB3YW50IHRvIGNvbW11bmlj YXRlLg0KDQpUaGVyZSBhcmUgdGltZXMgd2hlbiBzdGFuZGluZyBhZ2FpbnN0IHRoZSB0aWRlIGlz IHRoZSByaWdodCB0aGluZyB0byBkbzsgYnV0IEkgZG9u4oCZdCB0aGluayB0aGlzIGlzIG9uZSBv ZiB0aGVtLg0KDQpbMV0gaHR0cHM6Ly9sd24ubmV0L0FydGljbGVzLzgyMzIyNC8NCg0KPiBBIG11 Y2ggbW9yZSBtZWFuaW5nZnVsIHVzZSBvZiB0aW1lIHdvdWxkIGJlIHRvIGFkZHJlc3M6DQo+IA0K PiB4ZW4uZ2l0JCBnaXQgZ3JlcCAtaSAtZSBzbGF2ZSAtZSB3aGl0ZWxpc3QgLWUgYmxhY2tsaXN0 IHwgd2MgLWwNCj4gMTk0DQoNCldlbGwsIGFuIGV2ZW4gKm1vcmUqIG1lYW5pbmdmdWwgdXNlIG9m IG91ciB0aW1lIG1pZ2h0IGJlIGZvciBlYWNoIG9mIHVzIHRvIGxvb2sgaW50byB0aGUgYmVoYXZp b3Igb2YgdGhlIHBvbGljZSBmb3JjZXMgb3ZlciB3aGljaCB3ZSBoYXZlIGluZmx1ZW5jZSwgYW5k IGNvbnNpZGVyIHdoZXRoZXIgd2UgbmVlZCB0byBhZHZvY2F0ZSBmb3IgYW55IHN5c3RlbWF0aWMg Y2hhbmdlcyBpbiB0aGUgd2F5IHRoZXnigJlyZSBydW4uDQoNCkx1Y2tpbHksIHdlIGRvbuKAmXQg aGF2ZSB0byBjaG9vc2Ug4oCUIHdlIGNhbiBkbyBhbGwgb2YgdGhlbS4gOi0pDQoNCiAtR2Vvcmdl From xen-devel-bounces@lists.xenproject.org Thu Jun 25 11:12:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 11:12:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joPoP-00008Y-2Q; Thu, 25 Jun 2020 11:12:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joPoO-00008R-JE for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 11:12:56 +0000 X-Inumbo-ID: cfd7d471-b6d4-11ea-8199-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cfd7d471-b6d4-11ea-8199-12813bfff9fa; Thu, 25 Jun 2020 11:12:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xt43n1R1rHyZJcnajano8qGE72PtoiX6LYMOH7aDyuU=; b=tQ2KYuWY0FUXBWxzFiyYKWs3E LyM8tx/qrhogkFJY7et3w41ELFQ1R825PdMER9KrA6GY9XQtX2ZtxQsCnPk7QFbyBzjZvVT9T9uJp AiWiPUZwfAPa3UeYkg7DAmWhay1+duQdmODYkKF3WVwaNkUYWfr2l2NiQsmvG5koGobr4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joPoK-0004ya-F5; Thu, 25 Jun 2020 11:12:52 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joPoK-0007UK-4N; Thu, 25 Jun 2020 11:12:52 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joPoK-0000bi-3i; Thu, 25 Jun 2020 11:12:52 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151356: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=e4d2207165b379ec13c8b512936f63982af62d13 X-Osstest-Versions-That: xen=fde76f895d0aa817a1207d844d793239c6639bc6 From: osstest service owner Date: Thu, 25 Jun 2020 11:12:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151356 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151356/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen e4d2207165b379ec13c8b512936f63982af62d13 baseline version: xen fde76f895d0aa817a1207d844d793239c6639bc6 Last test of basis 151237 2020-06-19 20:00:46 Z 5 days Testing same since 151356 2020-06-25 08:07:44 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Grzegorz Uriasz Jan Beulich jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git fde76f895d..e4d2207165 e4d2207165b379ec13c8b512936f63982af62d13 -> smoke From xen-devel-bounces@lists.xenproject.org Thu Jun 25 11:31:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 11:31:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joQ5s-0001ou-Hc; Thu, 25 Jun 2020 11:31:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joQ5r-0001op-KO for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 11:30:59 +0000 X-Inumbo-ID: 56e83a20-b6d7-11ea-819a-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 56e83a20-b6d7-11ea-819a-12813bfff9fa; Thu, 25 Jun 2020 11:30:58 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 6dY+MD5GbwV4CJYygIyrGt9DfL42Bo4dTC6QT3utmJkxBIrQr/jN1SOk6JTkfEbAvKlqxt7Bv2 v+9HFoK2eIkG9qVyq6FKT2/eh0mvkJRwdKTHxyv2eS5XfDUiW9IP5WK5rpSfJb0fklh3CnmZp2 DQFXuIleCEL8IiRryEVbo7skaJ7u7EkXbETJdwXqLSgnEmrDusu3ZwKG6IHmUTgrv06KmHvPM6 RL7sZbP7rqpDhi8CM4xqpUd0rAZ2MW0C3QEUlGFzLdQocoKSWdKsoCGiisocY5NKuVYGapNE2U kFI= X-SBRS: 2.7 X-MesageID: 21214721 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="21214721" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage Date: Thu, 25 Jun 2020 13:30:41 +0200 Message-ID: <20200625113041.81507-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Volodymyr Babchuk , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Commit e9aca9470ed86 introduced a regression when avoiding sending IPIs for certain flush operations. Xen page fault handler (spurious_page_fault) relies on blocking interrupts in order to prevent handling TLB flush IPIs and thus preventing other CPUs from removing page tables pages. Switching to assisted flushing avoided such IPIs, and thus can result in pages belonging to the page tables being removed (and possibly re-used) while __page_fault_type is being executed. Force some of the TLB flushes to use IPIs, thus avoiding the assisted TLB flush. Those selected flushes are the page type change (when switching from a page table type to a different one, ie: a page that has been removed as a page table) and page allocation. This sadly has a negative performance impact on the pvshim, as less assisted flushes can be used. Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush using an IPI (flush_tlb_mask_sync). Note that the flag is only meaningfully defined when the hypervisor supports PV or shadow paging mode, as otherwise hardware assisted paging domains are in charge of their page tables and won't share page tables with Xen, thus not influencing the result of page walks performed by the spurious fault handler. Just passing this new flag when calling flush_area_mask prevents the usage of the assisted flush without any other side effects. Note the flag is not defined on Arm, and the introduced helper is just a dummy alias to the existing flush_tlb_mask. Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') Reported-by: Andrew Cooper Signed-off-by: Roger Pau Monné --- Changes since v2: - Always do a physical IPI triggered flush in filtered_flush_tlb_mask, since it's always required by the current callers of the function. Changes since v1: - Add a comment describing the usage of FLUSH_FORCE_IPI (and why no modifications to flush_area_mask are required). - Use PGT_root_page_table instead of PGT_l4_page_table. - Also perform IPI flushes if configured with shadow paging support. - Use ifdef instead of if. --- xen/arch/x86/mm.c | 12 +++++++++++- xen/include/asm-arm/flushtlb.h | 1 + xen/include/asm-x86/flushtlb.h | 18 ++++++++++++++++++ xen/include/xen/mm.h | 2 +- 4 files changed, 31 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index c294092f93..47872dccd0 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2894,7 +2894,17 @@ static int _get_page_type(struct page_info *page, unsigned long type, ((nx & PGT_type_mask) == PGT_writable_page)) ) { perfc_incr(need_flush_tlb_flush); - flush_tlb_mask(mask); + if ( (x & PGT_type_mask) && + (x & PGT_type_mask) <= PGT_root_page_table ) + /* + * If page was a page table make sure the flush is + * performed using an IPI in order to avoid changing + * the type of a page table page under the feet of + * spurious_page_fault. + */ + flush_tlb_mask_sync(mask); + else + flush_tlb_mask(mask); } /* We lose existing type and validity. */ diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h index ab1aae5c90..7ae0543885 100644 --- a/xen/include/asm-arm/flushtlb.h +++ b/xen/include/asm-arm/flushtlb.h @@ -27,6 +27,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) /* Flush specified CPUs' TLBs */ void flush_tlb_mask(const cpumask_t *mask); +#define flush_tlb_mask_sync flush_tlb_mask /* * Flush a range of VA's hypervisor mappings from the TLB of the local diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h index 8639427cce..2444aee112 100644 --- a/xen/include/asm-x86/flushtlb.h +++ b/xen/include/asm-x86/flushtlb.h @@ -126,6 +126,16 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4); #else #define FLUSH_HVM_ASID_CORE 0 #endif +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING) +/* + * Force an IPI to be sent. Note that adding this to the flags passed to + * flush_area_mask will prevent using the assisted flush without having any + * other side effect. + */ +# define FLUSH_FORCE_IPI 0x8000 +#else +# define FLUSH_FORCE_IPI 0 +#endif /* Flush local TLBs/caches. */ unsigned int flush_area_local(const void *va, unsigned int flags); @@ -148,6 +158,14 @@ void flush_area_mask(const cpumask_t *, const void *va, unsigned int flags); /* Flush specified CPUs' TLBs */ #define flush_tlb_mask(mask) \ flush_mask(mask, FLUSH_TLB) +/* + * Flush specified CPUs' TLBs and force the usage of an IPI to do so. This is + * required for certain operations that rely on page tables themselves not + * being freed and reused when interrupts are blocked, as the flush IPI won't + * be fulfilled until exiting from that critical region. + */ +#define flush_tlb_mask_sync(mask) \ + flush_mask(mask, FLUSH_TLB | FLUSH_FORCE_IPI) #define flush_tlb_one_mask(mask,v) \ flush_area_mask(mask, (const void *)(v), FLUSH_TLB|FLUSH_ORDER(0)) diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 9b62087be1..2e86bf66af 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -648,7 +648,7 @@ static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) if ( !cpumask_empty(&mask) ) { perfc_incr(need_flush_tlb_flush); - flush_tlb_mask(&mask); + flush_tlb_mask_sync(&mask); } } -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Thu Jun 25 12:05:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 12:05:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joQco-0004QT-Rq; Thu, 25 Jun 2020 12:05:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joQcn-0004QO-Rj for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 12:05:02 +0000 X-Inumbo-ID: 182eb868-b6dc-11ea-8496-bc764e2007e4 Received: from mail-lf1-x144.google.com (unknown [2a00:1450:4864:20::144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 182eb868-b6dc-11ea-8496-bc764e2007e4; Thu, 25 Jun 2020 12:05:01 +0000 (UTC) Received: by mail-lf1-x144.google.com with SMTP id g2so3083038lfb.0 for ; Thu, 25 Jun 2020 05:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TGe16ZbfddTf3KRBM/WlXgxyF2K+cWOwBxXn1q46L40=; b=uN4w6K85y3Mwq+2CuXJ5S/LmkwLXFkRQcqwpjCdFkTWkM+4flilBBGXx1P4IL7fzTi DJvcJiIWohJ9fHcYcm0sptr354UGbWzVOpZFJ3Fixa2R6hVh/0Dn/Mdbii9z4NrH2g47 teNkR8QqkuWtCdLyuWJegaxyRZLjAov+3SfllCsTjo1CnRn4a4t0tuBLazDcdI8gQLbN y3Gwg7xOwgmac1t6iYEuaacrTgxVWsOzJQ8fT//9H5S+CM2imECKHN2OTgH7jPGOPOLh 008xoT2h3nfoTvo6uZrw8KEem/lNUGwfu3XmdtI1vB7lwyEoyrWwkJqD6s81QbHoYu4k hGHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TGe16ZbfddTf3KRBM/WlXgxyF2K+cWOwBxXn1q46L40=; b=TonJWzM3m4wD+RWnXKEWXdIP3mtlmyLY0GuxxJNTjC37erHv739s4ocJaD7k+2ftzj OQLEgSBOdmJYmkvLvrDxG3y/Out/U1uGhtV8KbeHhHePDY+Oi2HM669COPyU+CtRfeEj 2dr/DVh74t6qIucSdJlz3bY+5UtjTET808Gv8D4+mnllMmTf8u1XmDBxQsW8TuLcIvtY dnfTr/GW3scxuAmJ7j9S1qC+wMYOFeVxm2ksONVoT8apmnS6C90eD/jFGlJXs3feNrkC OBoESjko3meKLBvBjlRMz77tv2E5L4bOEbjfOWx+vgd/X0IIgrk+Hfav3OtkE6hg9RwE mkQQ== X-Gm-Message-State: AOAM531Nv8EASbA8pUcS34saZi+hUE4ho1Zeo6tEMAzXHtzbrbjNO0Nk 8XysNVoem2aJu7JjT8nyqMzvezYtw6UKc9rULH0= X-Google-Smtp-Source: ABdhPJwQzWTmtHsT59xsPnwoyi/L/UC2u4L84f57b3bPrvOuJ4jiGDu92IBZqhGpOKim+VbqoDrNBZuKdCGBfZwKEck= X-Received: by 2002:a19:7111:: with SMTP id m17mr13008468lfc.156.1593086699767; Thu, 25 Jun 2020 05:04:59 -0700 (PDT) MIME-Version: 1.0 References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> <6cd9c568-84b9-8304-d56f-99d628d945a1@suse.com> In-Reply-To: <6cd9c568-84b9-8304-d56f-99d628d945a1@suse.com> From: Jason Andryuk Date: Thu, 25 Jun 2020 08:04:48 -0400 Message-ID: Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Elliott Mitchell , "xen-devel@lists.xenproject.org" , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 25, 2020 at 3:05 AM Jan Beulich wrote: > > On 25.06.2020 04:37, Jason Andryuk wrote: > > On Wed, Jun 24, 2020 at 12:19 PM Ian Jackson wrote: > >> > >> Jan Beulich writes ("Re: use of "stat -""): > >>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments unless you have verified the sender and know the content is safe. > >>> On 14.05.2020 13:02, Ian Jackson wrote: > >>>> I've read this thread. Jan, I'm sorry that this causes you > >>>> inconvenience. I'm hoping it won't come down to a choice between > >>>> supporting people who want to ship a dom0 without perl, and people who > >>>> want a dom0 using more-than-a-decade-old coreutils. > >>>> > >>>> Jan, can you tell me what the output is of this on your ancient > >>>> system: > >>>> > >>>> $ rm -f t > >>>> $ >t > >>>> $ exec 3 >>>> $ stat -L -c '%F %i' /dev/stdin <&3 > >>>> regular empty file 393549 > >>>> $ rm t > >>>> $ stat -L -c '%F %i' /dev/stdin <&3 > >>>> regular empty file 393549 > >>>> $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 > >>>> $ > >>> > >>> $ rm -f t > >>> $ >t > >>> $ exec 3 >>> $ stat -L -c '%F %i' /dev/stdin <&3 > >>> regular empty file 3380369 > >>> $ rm t > >>> $ stat -L -c '%F %i' /dev/stdin <&3 > >>> regular empty file 3380369 > >>> $ strace -ou stat -L -c '%F %i' /dev/stdin <&3 > >>> regular empty file 3380369 > >>> > >>>> Also, the contents of the file "u" afterwards, please. > >>> > >>> Attached. > >> > >> Thanks. > >> > >> I think this means that `stat -' can be replaced by `stat /dev/stdin'. > >> > >> This script is only run on Linux where /dev/stdin has existed > >> basically forever. The strace output shows > >> stat("/dev/stdin", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 > >> and the transcript shows that your stat(1) behaves as I hope. > >> > >> Jan, will you send a patch ? It is best if someone else but me writes > >> it and tests it because then I am a "clean" reviewer. > > I was about to, when I saw this reply from Jason. > > >> Paul, supposing I review such a patch and say it is low risk, and we > >> commit it by Friday, can it have a release-ack ? > > > > I was going to just write a patch to replace - with /dev/stdin and ask > > Jan to test it. When I opened the script, this comment was staring at > > me: > > # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or > > # use bash's test -ef because those all go through what is > > # actually a synthetic symlink in /proc and we aren't > > # guaranteed that our stat(2) won't lose the race with an > > # rm(1) between reading the synthetic link and traversing the > > # file system to find the inum. > > > > On my system: > > $ ls -l /dev/stdin > > lrwxrwxrwx 1 root root 15 Jun 24 21:13 /dev/stdin -> /proc/self/fd/0 > > $ ls -l /proc/self/fd/0 0 > lrwx------ 1 jason jason 64 Jun 24 21:26 /proc/self/fd/0 -> /home/jason/lockfile > > > > stat /dev/stdin will work around the lack of `stat -` support, but it > > doesn't address the race in the comment. Is the comment valid? How > > would we prove there is no race for /dev/stdin? And as a refresher, > > `stat -` does an fstat(0), so there is no symlink lookup. Or is there > > no race since `stat /proc/self/fd/0` isn't a symlink lookup but just > > accessing the already open fd via the proc special file? i.e. > > equivalent to fstat. > > Looking at vfs_statx() in the kernel, I can't see any provisions to > get at the data without traversing the specified path. Ian, you wrote the comment originally. Would you please clarify the scenario where there is a race? Only the lock holder is allowed to rm the lockfile, so how is there a race between rm and stat? Regards, Jason From xen-devel-bounces@lists.xenproject.org Thu Jun 25 13:19:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 13:19:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joRmZ-0001if-7U; Thu, 25 Jun 2020 13:19:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joRmY-0001iL-DL for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 13:19:10 +0000 X-Inumbo-ID: 6ff4d262-b6e6-11ea-81b3-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6ff4d262-b6e6-11ea-81b3-12813bfff9fa; Thu, 25 Jun 2020 13:19:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=k2Jhs5r0n/D2JL6ALgYsjD94jK7htXPlrsPBNqKQxaU=; b=rbjsaI6OtA3M/Vqf7u9EHGsT3 DsWCbu7YiJ7zIVxWSfPhEIXkn/3qqPhZIhczUcHQraK2pQj7Ql2lp1jkyjyyFRnd8seYWXMnuA6DV ZK1NkyTI2kWnu+9oCyyVPjITJURrzWotINVitfdoWp7lJeFbCBgYi1MhSTfMqCSwmWUoM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joRmQ-0007Hh-1Q; Thu, 25 Jun 2020 13:19:02 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joRmP-0004PB-Hm; Thu, 25 Jun 2020 13:19:01 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joRmP-0005UG-Gp; Thu, 25 Jun 2020 13:19:01 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.13-testing test] 151337: tolerable FAIL - PUSHED X-Osstest-Failures: xen-4.13-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.13-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.13-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.13-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: xen=9f7e8bac4ca279b3bfccb5f3730fb2e5398c95ab X-Osstest-Versions-That: xen=c54de7d9df7718ea53bf21e1ff5bbd339602a704 From: osstest service owner Date: Thu, 25 Jun 2020 13:19:01 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151337 xen-4.13-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151337/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: xen 9f7e8bac4ca279b3bfccb5f3730fb2e5398c95ab baseline version: xen c54de7d9df7718ea53bf21e1ff5bbd339602a704 Last test of basis 151153 2020-06-15 15:06:03 Z 9 days Testing same since 151337 2020-06-24 15:14:15 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Dario Faggioli Igor Druzhinin Jan Beulich Jason Andryuk Juergen Gross Julien Grall Paul Durrant Roger Pau Monné Sergey Dyasli jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git c54de7d9df..9f7e8bac4c 9f7e8bac4ca279b3bfccb5f3730fb2e5398c95ab -> stable-4.13 From xen-devel-bounces@lists.xenproject.org Thu Jun 25 13:27:50 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 13:27:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joRus-00038o-Kq; Thu, 25 Jun 2020 13:27:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joRur-00038d-Hs for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 13:27:45 +0000 X-Inumbo-ID: a6d72c52-b6e7-11ea-81b8-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a6d72c52-b6e7-11ea-81b8-12813bfff9fa; Thu, 25 Jun 2020 13:27:44 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: SWtdBJRQAudwXIRNa0FPay5Mh7nIrZFc4DeCcEhl7mIaI1gZ6V/h1YGQ7y6UV71voheIS/lmrZ Zj6oJh6T5ACJq0NUWkAwNDb5yKCMn169xBZJTIt9f57nqU96LkKasmqvsYEVUJ1I6HNTlgbl4D dUc+d0NXRkLcnXv4qQ5T0u+wVhNbF+kWwZxz1YNS2H7Pr0HLH/Pe4zWBflT6zn7K5r7TQZH8kU E6wkuEhlj3cJQpavht/686f58pLSVqTnV2gnVZRF6LxTAEDbmt5IgDmBy7vNsiS04SFwaZjtR/ ixc= X-SBRS: 2.7 X-MesageID: 20917201 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="20917201" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24308.42571.430322.191817@mariner.uk.xensource.com> Date: Thu, 25 Jun 2020 14:27:39 +0100 To: Jason Andryuk Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" In-Reply-To: References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Jan Beulich , Wei Liu , Paul Durrant , Andrew Cooper , Elliott Mitchell , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jason Andryuk writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""): > I was going to just write a patch to replace - with /dev/stdin and ask > Jan to test it. When I opened the script, this comment was staring at > me: > # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or > # use bash's test -ef because those all go through what is > # actually a synthetic symlink in /proc and we aren't > # guaranteed that our stat(2) won't lose the race with an > # rm(1) between reading the synthetic link and traversing the > # file system to find the inum. > > On my system: > $ ls -l /dev/stdin > lrwxrwxrwx 1 root root 15 Jun 24 21:13 /dev/stdin -> /proc/self/fd/0 > $ ls -l /proc/self/fd/0 0 lrwx------ 1 jason jason 64 Jun 24 21:26 /proc/self/fd/0 -> /home/jason/lockfile > > stat /dev/stdin will work around the lack of `stat -` support, but it > doesn't address the race in the comment. Is the comment valid? Thanks, but: The tests in my transcript show that the comment (which I wrote) is false. It shows that stat /dev/stdin works on deleted files, and stats the right file even if the name has been rused. > How would we prove there is no race for /dev/stdin? It is easy to create the "bad" situation by hand, without racing. The transcript shows that the output from readlink(2) is a fiction and that stat works to stat the actual open-file. > I've mentioned it before, but maybe we should just use the Qubes > patch. It leaves the lockfile even when no-one is holding the lock, > but it simplifies the code and sidesteps the issues we are discussing > here. > https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.13/patch-tools-hotplug-drop-perl-usage-in-locking-mechanism.patch I don't like that because this locking code might be reused (or maybe already is used) in contexts with a varying lockfile filename, leaving many lockfiles. And because having lockfiles lying about might confuse sysadmins who are used to programs which use (the broken) LOCK_EX-style locking paradigm. So tl;dr: yes, we need that patch to replace - with /dev/stdin. Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 13:31:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 13:31:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joRyq-0003ws-D4; Thu, 25 Jun 2020 13:31:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joRyp-0003wn-7S for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 13:31:51 +0000 X-Inumbo-ID: 388a4be9-b6e8-11ea-81bb-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 388a4be9-b6e8-11ea-81bb-12813bfff9fa; Thu, 25 Jun 2020 13:31:50 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 2Sm0EvpiK5Tkj0AFgopW6war/Q4KNZHaSM2WvtL+W5jp5CFb77A/GvIT0TYvt2tCXaa6SjiNFd BgUuFgfP5841CDNB+WZiyYm0gJRpEwbL0tPlPcxvPXkzH/Fcxj+SiLjFunn3CPXdOO5c++C/5S PBtvKvtmKb7KkHjyf91klbrbdaWWVdKRaG1Eo/RcOPm2/ehII+AQYZpnRMRMDRVU+BJA/nvkmk bfA8Rw36KSnt5tHJzV4EuLb53G5vi9Oxb6lSTSMcb4qzfLCi1aNTppSTO+H3ZQUAKUgWExTksi mFI= X-SBRS: 2.7 X-MesageID: 20932206 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="20932206" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24308.42811.393047.88416@mariner.uk.xensource.com> Date: Thu, 25 Jun 2020 14:31:39 +0100 To: Jan Beulich Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" In-Reply-To: <6cd9c568-84b9-8304-d56f-99d628d945a1@suse.com> References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> <6cd9c568-84b9-8304-d56f-99d628d945a1@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jason Andryuk , Elliott Mitchell , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jan Beulich writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""): > Looking at vfs_statx() in the kernel, I can't see any provisions to > get at the data without traversing the specified path. The question is what "traversing the path" means. How do you explain this ? $ >t $ exec 3>t $ stat -L -c '%F %i' /dev/stdin <&3 regular empty file 421124 $ ll /dev/stdin <&3 lrwxrwxrwx 1 root root 15 Jun 7 02:01 /dev/stdin -> /proc/self/fd/0 $ ll /proc/self/fd/0 <&3 l-wx------ 1 ian ian 64 Jun 25 14:29 /proc/self/fd/0 -> /home/ian/t $ mv t u $ ll /proc/self/fd/0 <&3 l-wx------ 1 ian ian 64 Jun 25 14:29 /proc/self/fd/0 -> /home/ian/u $ rm u $ ll /proc/self/fd/0 <&3 l-wx------ 1 ian ian 64 Jun 25 14:29 /proc/self/fd/0 -> '/home/ian/u (deleted)' $ stat -L -c '%F %i' /dev/stdin <&3 regular empty file 421124 $ ll -Li /dev/stdin <&3 421124 -rw-rw-r-- 0 ian ian 0 Jun 25 14:28 /dev/stdin $ Clearly it isn't actually following this synthetic symlink to "/home/ian/u (deleted)". Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 13:48:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 13:48:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSEV-0004wC-S4; Thu, 25 Jun 2020 13:48:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSEV-0004w7-22 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 13:48:03 +0000 X-Inumbo-ID: 7c9ae872-b6ea-11ea-81c3-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7c9ae872-b6ea-11ea-81c3-12813bfff9fa; Thu, 25 Jun 2020 13:48:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0E49EAEF7; Thu, 25 Jun 2020 13:48:01 +0000 (UTC) Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" To: Ian Jackson References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> <6cd9c568-84b9-8304-d56f-99d628d945a1@suse.com> <24308.42811.393047.88416@mariner.uk.xensource.com> From: Jan Beulich Message-ID: <810ea6c8-1ae4-3ecc-3559-fde819f366fe@suse.com> Date: Thu, 25 Jun 2020 15:48:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24308.42811.393047.88416@mariner.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jason Andryuk , Elliott Mitchell , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 25.06.2020 15:31, Ian Jackson wrote: > Jan Beulich writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""): >> Looking at vfs_statx() in the kernel, I can't see any provisions to >> get at the data without traversing the specified path. > > The question is what "traversing the path" means. > > How do you explain this ? > > $ >t > $ exec 3>t > $ stat -L -c '%F %i' /dev/stdin <&3 > regular empty file 421124 > $ ll /dev/stdin <&3 > lrwxrwxrwx 1 root root 15 Jun 7 02:01 /dev/stdin -> /proc/self/fd/0 > $ ll /proc/self/fd/0 <&3 > l-wx------ 1 ian ian 64 Jun 25 14:29 /proc/self/fd/0 -> /home/ian/t > $ mv t u > $ ll /proc/self/fd/0 <&3 > l-wx------ 1 ian ian 64 Jun 25 14:29 /proc/self/fd/0 -> /home/ian/u > $ rm u > $ ll /proc/self/fd/0 <&3 > l-wx------ 1 ian ian 64 Jun 25 14:29 /proc/self/fd/0 -> '/home/ian/u (deleted)' > $ stat -L -c '%F %i' /dev/stdin <&3 > regular empty file 421124 > $ ll -Li /dev/stdin <&3 > 421124 -rw-rw-r-- 0 ian ian 0 Jun 25 14:28 /dev/stdin > $ > > Clearly it isn't actually following this synthetic symlink to > "/home/ian/u (deleted)". Okay, so there's clearly some trickery then which don't know where to find. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 25 14:08:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 14:08:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSYQ-0006hQ-1f; Thu, 25 Jun 2020 14:08:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSYO-0006hI-9f for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 14:08:36 +0000 X-Inumbo-ID: 5bc28788-b6ed-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5bc28788-b6ed-11ea-bb8b-bc764e2007e4; Thu, 25 Jun 2020 14:08:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 72C5DAE93; Thu, 25 Jun 2020 14:08:34 +0000 (UTC) Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" To: Ian Jackson References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> <24308.42571.430322.191817@mariner.uk.xensource.com> From: Jan Beulich Message-ID: <7abcae45-6a58-ea7a-be8b-64be50b080a6@suse.com> Date: Thu, 25 Jun 2020 16:08:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24308.42571.430322.191817@mariner.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jason Andryuk , Elliott Mitchell , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 25.06.2020 15:27, Ian Jackson wrote: > Jason Andryuk writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""): >> I was going to just write a patch to replace - with /dev/stdin and ask >> Jan to test it. When I opened the script, this comment was staring at >> me: >> # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or >> # use bash's test -ef because those all go through what is >> # actually a synthetic symlink in /proc and we aren't >> # guaranteed that our stat(2) won't lose the race with an >> # rm(1) between reading the synthetic link and traversing the >> # file system to find the inum. >> >> On my system: >> $ ls -l /dev/stdin >> lrwxrwxrwx 1 root root 15 Jun 24 21:13 /dev/stdin -> /proc/self/fd/0 >> $ ls -l /proc/self/fd/0 0> lrwx------ 1 jason jason 64 Jun 24 21:26 /proc/self/fd/0 -> /home/jason/lockfile >> >> stat /dev/stdin will work around the lack of `stat -` support, but it >> doesn't address the race in the comment. Is the comment valid? > > Thanks, but: > > The tests in my transcript show that the comment (which I wrote) is > false. It shows that stat /dev/stdin works on deleted files, and > stats the right file even if the name has been rused. > >> How would we prove there is no race for /dev/stdin? > > It is easy to create the "bad" situation by hand, without racing. > > The transcript shows that the output from readlink(2) is a fiction and > that stat works to stat the actual open-file. > >> I've mentioned it before, but maybe we should just use the Qubes >> patch. It leaves the lockfile even when no-one is holding the lock, >> but it simplifies the code and sidesteps the issues we are discussing >> here. >> https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.13/patch-tools-hotplug-drop-perl-usage-in-locking-mechanism.patch > > I don't like that because this locking code might be reused (or maybe > already is used) in contexts with a varying lockfile filename, leaving > many lockfiles. And because having lockfiles lying about might > confuse sysadmins who are used to programs which use (the broken) > LOCK_EX-style locking paradigm. > > So tl;dr: yes, we need that patch to replace - with /dev/stdin. I'm about to test this then, but to be honest I have no idea what to do with the comment. I don't think I could properly justify its deletion in the description (beyond saying it's not really true), nor would I be certain whether to e.g. leave the test -ef part there. Also is there any reason to go through two symlinks then, rather than using /proc/self/fd/$_lockfd directly? Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 25 14:16:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 14:16:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSgH-0007hr-SD; Thu, 25 Jun 2020 14:16:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSgG-0007hm-Tp for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 14:16:45 +0000 X-Inumbo-ID: 7ebeb67a-b6ee-11ea-bb8b-bc764e2007e4 Received: from mail-lj1-x241.google.com (unknown [2a00:1450:4864:20::241]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7ebeb67a-b6ee-11ea-bb8b-bc764e2007e4; Thu, 25 Jun 2020 14:16:44 +0000 (UTC) Received: by mail-lj1-x241.google.com with SMTP id 9so6705973ljv.5 for ; Thu, 25 Jun 2020 07:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/9t7dRTd26Cj0mD+rcWjzqKsb1g6xpQenNsIlbETbYA=; b=Yl4IOKZNey4JdB2Y+sia7EKy48PihvaxkjN2VOQqsGrb9F4OsoqujtUdZe0vK8y7Gw cADh/kfNFWKeYEAWOjImd3kBmXf8zkD9VHr0QxoArr3ZvKdXexlDUB0u6lrErpD4HIEX 81rUsSkAtfE1OVeES0Qdr3/X9vs+2p2s4P+qggIf57tzfrrWyqKzYVWMRhKsw1vtfnAm 60gNG+MghxE+vZHOjSbLVEFP2LCkg6InwmUDuSOVM6T9devy7KAjkIYdQpmNA9S+vea/ 6rN0x55vcPHMDL98aQamFdpqMRBwZa0t099YEz9Yw6koOCfSToJJB4/deOxSOc3BptXD pTMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/9t7dRTd26Cj0mD+rcWjzqKsb1g6xpQenNsIlbETbYA=; b=kaz72DtQ/jPmqn8LeuncQMaDiWqbA8MNs3DNGlloR88VPBXRGOTA63bbmVcHDa4vHa aqCMKKMkaWx/2OVkq6eCf31bmRYynD82l9BpK8GVejHA8EUyZs5mbY0XU6EYQQ7wsqAI sH09YCd2fAcjHohGfV8e0pHcNCMOlqZeUeQBW6UNKVM/+zuWJ7qw36oc+J8uWXMNPocJ I5NQbSVqo+2Z2+lRkb5jnctzhwGdYLv8Spn/7a85EjyqraT9M2Sz6mk9pHljGZE+SJMD eMw9f6OWNcweR/WxDCIqNu6wln3u8/UwC1yU7i6xloDfFqy0KHvib1A9d/8JLSJBF5X6 FlcQ== X-Gm-Message-State: AOAM532xbvscvGIXhbB2CaWJRARsueK/LZ/ZwJEQIZSz27ZF/BV/77MT +r6Mx8WVsF/uHWvZzCeKirUPnXwfa3zhQ7ercSM= X-Google-Smtp-Source: ABdhPJwCJniiKhezzR7ZTc+wMlYcH7mWg7EZRBm3g7B8IQnEZSdk4AF5GbINFUg2+Mbx5GoF4cXpFlFl8i2YMneDqzE= X-Received: by 2002:a2e:b8c2:: with SMTP id s2mr17958993ljp.368.1593094602877; Thu, 25 Jun 2020 07:16:42 -0700 (PDT) MIME-Version: 1.0 References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> <6cd9c568-84b9-8304-d56f-99d628d945a1@suse.com> <24308.42811.393047.88416@mariner.uk.xensource.com> <810ea6c8-1ae4-3ecc-3559-fde819f366fe@suse.com> In-Reply-To: <810ea6c8-1ae4-3ecc-3559-fde819f366fe@suse.com> From: Jason Andryuk Date: Thu, 25 Jun 2020 10:16:29 -0400 Message-ID: Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Elliott Mitchell , "xen-devel@lists.xenproject.org" , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 25, 2020 at 9:48 AM Jan Beulich wrote: > > On 25.06.2020 15:31, Ian Jackson wrote: > > Jan Beulich writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""): > >> Looking at vfs_statx() in the kernel, I can't see any provisions to > >> get at the data without traversing the specified path. > > > > The question is what "traversing the path" means. > > > > How do you explain this ? > > > > $ >t > > $ exec 3>t > > $ stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 421124 > > $ ll /dev/stdin <&3 > > lrwxrwxrwx 1 root root 15 Jun 7 02:01 /dev/stdin -> /proc/self/fd/0 > > $ ll /proc/self/fd/0 <&3 > > l-wx------ 1 ian ian 64 Jun 25 14:29 /proc/self/fd/0 -> /home/ian/t > > $ mv t u > > $ ll /proc/self/fd/0 <&3 > > l-wx------ 1 ian ian 64 Jun 25 14:29 /proc/self/fd/0 -> /home/ian/u > > $ rm u > > $ ll /proc/self/fd/0 <&3 > > l-wx------ 1 ian ian 64 Jun 25 14:29 /proc/self/fd/0 -> '/home/ian/u (deleted)' > > $ stat -L -c '%F %i' /dev/stdin <&3 > > regular empty file 421124 > > $ ll -Li /dev/stdin <&3 > > 421124 -rw-rw-r-- 0 ian ian 0 Jun 25 14:28 /dev/stdin > > $ > > > > Clearly it isn't actually following this synthetic symlink to > > "/home/ian/u (deleted)". > > Okay, so there's clearly some trickery then which don't know where > to find. I can't say I've taken the time to read and understand all this, but the code in here https://elixir.bootlin.com/linux/latest/source/fs/proc/fd.c#L147 seems to lookup FDs to existing structs. -Jason From xen-devel-bounces@lists.xenproject.org Thu Jun 25 14:17:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 14:17:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSgX-0007jt-4P; Thu, 25 Jun 2020 14:17:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSgV-0007jg-Vs for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 14:17:00 +0000 X-Inumbo-ID: 87646b58-b6ee-11ea-81cf-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 87646b58-b6ee-11ea-81cf-12813bfff9fa; Thu, 25 Jun 2020 14:16:58 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: EqW+1j5bkr9fnOD2kB1so+dXq6NAG8gpKPl7tJHqY3zrRXb9WZ63oKOlAOV5E6CbaldIP/UBWy ZWWkWBcI60A7fct9aS1b77grPoYM5x5mPXKxR9AGxqw/yqjsl2RPny6SJo/GHexFpucJrG4jr4 bfE1Bf5UhT8u01/YHFSJF37aUxblWZfyNiCSPNstE+9K6t1gmyk2u6zdkiwgIJnbXPkcB6Fyp1 kMwddKqVP6+e8L/teeDfroCResPyR74rVAakkwBJnIeB0ujQkvI62VlmwKvvCK0hMVTxHWACYe vGg= X-SBRS: 2.7 X-MesageID: 21232246 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="21232246" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v2] mm: fix public declaration of struct xen_mem_acquire_resource Date: Thu, 25 Jun 2020 16:16:43 +0200 Message-ID: <20200625141643.82822-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" XENMEM_acquire_resource and it's related structure is currently inside a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the hypervisor or the toolstack only. This is wrong as the hypercall is already being used by the Linux kernel at least, and as such needs to be public. Also switch the usage of uint64_aligned_t to plain uint64_t, as uint64_aligned_t is only to be used by the toolstack. Note that a padding field is added on 32bit x86, so that the size of the structure is the same. No layout structure change. The structure doesn't need to be adjusted on 32bit Arm, because guest handlers are already expanded to 64bits. Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire guest resources') Signed-off-by: Roger Pau Monné --- Should also be backported. --- Changes since v1: - Add padding on 32bits so structure size matches between arches and the previous layout is kept. --- xen/include/public/memory.h | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index dbd35305df..b6d3587cfa 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -607,6 +607,8 @@ struct xen_reserved_device_memory_map { typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t; DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ + /* * Get the pages for a particular guest resource, so that they can be * mapped directly by a tools domain. @@ -645,7 +647,7 @@ struct xen_mem_acquire_resource { * IN - the index of the initial frame to be mapped. This parameter * is ignored if nr_frames is 0. */ - uint64_aligned_t frame; + uint64_t frame; #define XENMEM_resource_ioreq_server_frame_bufioreq 0 #define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n)) @@ -662,12 +664,14 @@ struct xen_mem_acquire_resource { * This parameter may be NULL if nr_frames is 0. */ XEN_GUEST_HANDLE(xen_pfn_t) frame_list; + +#ifdef __i386__ + uint32_t pad2; +#endif }; typedef struct xen_mem_acquire_resource xen_mem_acquire_resource_t; DEFINE_XEN_GUEST_HANDLE(xen_mem_acquire_resource_t); -#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ - /* * XENMEM_get_vnumainfo used by guest to get * vNUMA topology from hypervisor. -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Thu Jun 25 14:18:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 14:18:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joShz-0007uY-Fr; Thu, 25 Jun 2020 14:18:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joShy-0007uL-98 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 14:18:30 +0000 X-Inumbo-ID: bd8c3dbe-b6ee-11ea-b7bb-bc764e2007e4 Received: from mail-lj1-x243.google.com (unknown [2a00:1450:4864:20::243]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bd8c3dbe-b6ee-11ea-b7bb-bc764e2007e4; Thu, 25 Jun 2020 14:18:29 +0000 (UTC) Received: by mail-lj1-x243.google.com with SMTP id i3so6733278ljg.3 for ; Thu, 25 Jun 2020 07:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FPtuhlLqpCXq8vallQn3u4hk6PZ4QahAsJ6CAsStr8k=; b=aUR5NaQO7RaXMr8qBlYWYcxCLD1kH+WkJS+sT0Soq63FN+qsWzS8MuhrxZDFXOZSJk TxOmUYlUM+5mCZ+niY0D+CsW4TAOg0ki8+iL4HgkX+wIxwHt78Y2cgvaU5wHEzp2jVcZ y4QY30sLBI0O8barXzfm8benI5NcpXow+bcSnbUHw9GaKVHFV0VoishSooUvIl3Et2uJ I4k01XgW+pV1gL1xp/kul9Fow1+2bxmmQwwrtnDMwieEhK74mzJu1cSQorozSihjkAev pz1z3LaGw8qlrwdiCNLiwW/8EmPmCYrgmPB4C0+4txypwaUYxiV+NHaonblCCYtj88p4 4TPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FPtuhlLqpCXq8vallQn3u4hk6PZ4QahAsJ6CAsStr8k=; b=r5lQu7jb18aRya3WTNvZRvfUJGkypAxf7X3RabEQ5Bi1VCQQ7mBi7BBd9LX5R4z09Y scANUNL086vscnKLW5UUenM76BtCUvQJbc1z90ZFxW/HtAJFm+8Z1mVQTsNqqS51VNi6 CBTPgVASNvEWvcZsU4yMB3/Rxu73wxd3/MQ5y+YHRFviKSim0AlhhakL65vxheEd2lq2 VG7cRdOqx9ogMN2Xqjd4ZcERbRe9Axn7YcnSs9p7yRWnp/F64ks1iXgWG8yc+pp8zhQD HXNdpZcFeiXxLP9UbXmZtbXApll2SXdowNpUZrIooUMJB4M2VavYmLAD6kY3Mip2/zOS ZUwA== X-Gm-Message-State: AOAM5317riev3QmIW0u9BOpuBmzMOxr7HaZhMSkUSfwbSFNvfFrtuz19 UGQfLA1E/QnlX643dvzCvarsDxjoQoYe28YYR7g= X-Google-Smtp-Source: ABdhPJzDGTsxOdELoHsJOv2N4JntIdwuWfglI87R9RRPFc19U1+snNJ8aTO0LGCG3Brp5Z5CfR8sGk5ObWg4vv90Sss= X-Received: by 2002:a2e:b88c:: with SMTP id r12mr16616416ljp.266.1593094708214; Thu, 25 Jun 2020 07:18:28 -0700 (PDT) MIME-Version: 1.0 References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> <24308.42571.430322.191817@mariner.uk.xensource.com> <7abcae45-6a58-ea7a-be8b-64be50b080a6@suse.com> In-Reply-To: <7abcae45-6a58-ea7a-be8b-64be50b080a6@suse.com> From: Jason Andryuk Date: Thu, 25 Jun 2020 10:18:16 -0400 Message-ID: Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Elliott Mitchell , "xen-devel@lists.xenproject.org" , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 25, 2020 at 10:08 AM Jan Beulich wrote: > > On 25.06.2020 15:27, Ian Jackson wrote: > > Jason Andryuk writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""): > >> I was going to just write a patch to replace - with /dev/stdin and ask > >> Jan to test it. When I opened the script, this comment was staring at > >> me: > >> # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or > >> # use bash's test -ef because those all go through what is > >> # actually a synthetic symlink in /proc and we aren't > >> # guaranteed that our stat(2) won't lose the race with an > >> # rm(1) between reading the synthetic link and traversing the > >> # file system to find the inum. > >> > >> On my system: > >> $ ls -l /dev/stdin > >> lrwxrwxrwx 1 root root 15 Jun 24 21:13 /dev/stdin -> /proc/self/fd/0 > >> $ ls -l /proc/self/fd/0 0 >> lrwx------ 1 jason jason 64 Jun 24 21:26 /proc/self/fd/0 -> /home/jason/lockfile > >> > >> stat /dev/stdin will work around the lack of `stat -` support, but it > >> doesn't address the race in the comment. Is the comment valid? > > > > Thanks, but: > > > > The tests in my transcript show that the comment (which I wrote) is > > false. It shows that stat /dev/stdin works on deleted files, and > > stats the right file even if the name has been rused. > > > >> How would we prove there is no race for /dev/stdin? > > > > It is easy to create the "bad" situation by hand, without racing. > > > > The transcript shows that the output from readlink(2) is a fiction and > > that stat works to stat the actual open-file. > > > >> I've mentioned it before, but maybe we should just use the Qubes > >> patch. It leaves the lockfile even when no-one is holding the lock, > >> but it simplifies the code and sidesteps the issues we are discussing > >> here. > >> https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.13/patch-tools-hotplug-drop-perl-usage-in-locking-mechanism.patch > > > > I don't like that because this locking code might be reused (or maybe > > already is used) in contexts with a varying lockfile filename, leaving > > many lockfiles. And because having lockfiles lying about might > > confuse sysadmins who are used to programs which use (the broken) > > LOCK_EX-style locking paradigm. > > > > So tl;dr: yes, we need that patch to replace - with /dev/stdin. > > I'm about to test this then, but to be honest I have no idea what > to do with the comment. I don't think I could properly justify its > deletion in the description (beyond saying it's not really true), > nor would I be certain whether to e.g. leave the test -ef part > there. Yes, this is what made me pause yesterday. Also, I'm not sure how test -ef would be used to check the file & FD. > Also is there any reason to go through two symlinks then, rather > than using /proc/self/fd/$_lockfd directly? I think /proc/self/fd/$_lockfd should just be used to avoid playing unnecessary FD games. Regards, Jason From xen-devel-bounces@lists.xenproject.org Thu Jun 25 14:19:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 14:19:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSih-000810-Ty; Thu, 25 Jun 2020 14:19:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSig-00080r-9y for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 14:19:14 +0000 X-Inumbo-ID: d8014360-b6ee-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d8014360-b6ee-11ea-bb8b-bc764e2007e4; Thu, 25 Jun 2020 14:19:13 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: XQR5bV0GV/uKdCPmhTSFGjnXxOyqYpcmr2Cdiqy7pdyLXETKlL2TPSQJvhrGtHuGiLblpvQqVP JCIlCZQI8Yu3be2QrJwoAhK0L8bJUlbxMTs+R+1dvw6SRh9SISgsERSV2GG9E0mVD9A1iWoJLG aXDCAKnkRKTwkekNVnoSk/4tSzFnrOEQBZDfrjEdTvL2DBVf8FAKV+hMWE4W0vRFV1h5iOOm5j n5RRpSaR4Y5XG2ZCcQTX8g5Se0WWSdsAGHDs+J8G2JUYQibxKCVdZy5pk/lu8yiQRfoyh2Wm0H grQ= X-SBRS: 2.7 X-MesageID: 20923418 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="20923418" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24308.45659.314018.214428@mariner.uk.xensource.com> Date: Thu, 25 Jun 2020 15:19:07 +0100 To: Jan Beulich Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" In-Reply-To: <7abcae45-6a58-ea7a-be8b-64be50b080a6@suse.com> References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> <24308.42571.430322.191817@mariner.uk.xensource.com> <7abcae45-6a58-ea7a-be8b-64be50b080a6@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , Jason Andryuk , Elliott Mitchell , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jan Beulich writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""): > I'm about to test this then, but to be honest I have no idea what > to do with the comment. I don't think I could properly justify its > deletion in the description (beyond saying it's not really true), > nor would I be certain whether to e.g. leave the test -ef part > there. You should delete the comment. You could replace it with its opposite. Something like: # Although /dev/stdin (ie /proc/self/fd/0) looks like a symlink, # stat(2) bypasses the synthetic symlink and directly accesses the # underlying open-file. So this works correctly even if the file # has been renamed or unlinked. > Also is there any reason to go through two symlinks then, rather > than using /proc/self/fd/$_lockfd directly? /dev/stdin is clearer, to my mind. (The tiny performence difference is not relevant here. It's also possible that at some point stat(1) might handle it specially.) Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 14:27:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 14:27:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSqg-0000V8-PM; Thu, 25 Jun 2020 14:27:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joSqf-0000V1-Le for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 14:27:29 +0000 X-Inumbo-ID: ff3b51c2-b6ef-11ea-bca7-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ff3b51c2-b6ef-11ea-bca7-bc764e2007e4; Thu, 25 Jun 2020 14:27:28 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 5+QvFqiIpiPeFQfY+KcNIO7AnAvDFlv58lI3+MJ2i+EwlOAT5dS8doRKOxian+9FvJ54dkL6l1 n3JSeBp88g0q6t3/qzmQlBC8DmYVvilhcgHBecxvlmDC2DjPOUtbk+Davpckrm69EhTwrWqrTK U2nH34nowDBZ1xJiHLPhRxQG0R+u10Z18Ap+SiPCT29gfEq/1aVYoB2CoF36xdLnDK3m3/4Y75 28+hmCnZSohwYbJCAqL1TxG36Ng2Ruvbj/rg2RGRSi84/91EA246gbnvpaRoCwnrNc1KxM2Afz Y4Y= X-SBRS: 2.7 X-MesageID: 20938600 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="20938600" Date: Thu, 25 Jun 2020 16:27:21 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Subject: Re: [PATCH for-4.14 v2] mm: fix public declaration of struct xen_mem_acquire_resource Message-ID: <20200625142721.GY735@Air-de-Roger> References: <20200625141643.82822-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200625141643.82822-1-roger.pau@citrix.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 25, 2020 at 04:16:43PM +0200, Roger Pau Monne wrote: > XENMEM_acquire_resource and it's related structure is currently inside > a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > hypervisor or the toolstack only. This is wrong as the hypercall is > already being used by the Linux kernel at least, and as such needs to > be public. > > Also switch the usage of uint64_aligned_t to plain uint64_t, as > uint64_aligned_t is only to be used by the toolstack. Note that a > padding field is added on 32bit x86, so that the size of the structure > is the same. > > No layout structure change. The structure doesn't need to be adjusted > on 32bit Arm, because guest handlers are already expanded to 64bits. > > Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire guest resources') > Signed-off-by: Roger Pau Monné > --- > Should also be backported. > --- > Changes since v1: > - Add padding on 32bits so structure size matches between arches and > the previous layout is kept. This is bogus, will send a proper version. Sorry for the noise, Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 14:37:35 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 14:37:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joT0J-0001NS-Jl; Thu, 25 Jun 2020 14:37:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joT0I-0001NN-C8 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 14:37:26 +0000 X-Inumbo-ID: 629eaec1-b6f1-11ea-81dc-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 629eaec1-b6f1-11ea-81dc-12813bfff9fa; Thu, 25 Jun 2020 14:37:25 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: HbuEhbJYFAXxxZSmJl9qBVoDdOXE1HTXeuH6bAy4P1kiA3E3nePJglTntCkGa95oxECF5dSQD2 fakCXqtQJzLYiuhJAPlWrGZgFNxUQ1MFgV7RJkfAm3J8xbB6QhJT1hwaTYH9GYv//PU6d6Z2cB EYzqznh44f0PedVAPph1SI2kG2tkD7fRdEOVXlEd0DlakyuJbAL1jWQE68YP/MJk7dWnfmh07u qCwRedfPLAZkpMhW+xBsLtzkTJi09SCq5zSaYIOs2kcfLwu8Z/NNddgXPXPrudQWotLOd9oUtI 3iE= X-SBRS: 2.7 X-MesageID: 20939691 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="20939691" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24308.46751.24955.702652@mariner.uk.xensource.com> Date: Thu, 25 Jun 2020 15:37:19 +0100 To: Jason Andryuk Subject: Re: [XEN RFC for-4.14] Re: use of "stat -" In-Reply-To: References: <3bfd6384-fcaf-c74a-e560-a35aafa06a43@suse.com> <20200512141947.yqx4gmbvqs4grx5g@liuwe-devbox-debian-v2.j3c5onc20sse1dnehy4noqpfcg.zx.internal.cloudapp.net> <4b90b635-84bb-e827-d52e-dfe1ebdb4e4d@citrix.com> <814db557-4f6a-020d-9f71-4ee3724981e3@suse.com> <20200512195005.GA96154@mattapan.m5p.com> <049e0022-f9c1-6dc9-3360-d25d88eeb97f@citrix.com> <20200512225458.GA1530@mattapan.m5p.com> <24253.9543.974853.499775@mariner.uk.xensource.com> <0b449d5a-9629-8e41-5354-b985a063eba4@suse.com> <24307.32018.502303.817846@mariner.uk.xensource.com> <24308.42571.430322.191817@mariner.uk.xensource.com> <7abcae45-6a58-ea7a-be8b-64be50b080a6@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Jan Beulich , Wei Liu , Paul Durrant , Andrew Cooper , Elliott Mitchell , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jason Andryuk writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""): > On Thu, Jun 25, 2020 at 10:08 AM Jan Beulich wrote: > > I'm about to test this then, but to be honest I have no idea what > > to do with the comment. I don't think I could properly justify its > > deletion in the description (beyond saying it's not really true), > > nor would I be certain whether to e.g. leave the test -ef part > > there. > > Yes, this is what made me pause yesterday. Also, I'm not sure how > test -ef would be used to check the file & FD. $ >t $ exec 3>t $ rm u rm: cannot remove 'u': No such file or directory $ ln t u $ test t -ef u && echo y y $ test /dev/stdin <&3 -ef u && echo y y $ mv t v $ test /dev/stdin <&3 -ef u && echo y y $ rm v $ test /dev/stdin <&3 -ef u && echo y y $ This appears to work. In principle we could switch to this, but (i) we would want to check that all (recent?) versions of bash do the sensible thing (ii) we are in a release freeze. > > Also is there any reason to go through two symlinks then, rather > > than using /proc/self/fd/$_lockfd directly? > > I think /proc/self/fd/$_lockfd should just be used to avoid playing > unnecessary FD games. Xen is frozen at the moment. Can we please make the minimal change, rather than the change which cleans the code up the most ? That does imply some technical debt, but has the lowest risk for the release. If you like, combine it with a second patch that changes things to use test -ef, for post-4.14 ? Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 15:16:16 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 15:16:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joTbh-0004eA-Oi; Thu, 25 Jun 2020 15:16:05 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joTbg-0004e5-P0 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 15:16:04 +0000 X-Inumbo-ID: c75a6138-b6f6-11ea-81ed-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c75a6138-b6f6-11ea-81ed-12813bfff9fa; Thu, 25 Jun 2020 15:16:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 73E21AF49; Thu, 25 Jun 2020 15:16:00 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: Jan Beulich Subject: [PATCH] scripts: don't rely on "stat -" support Message-ID: <691aebb4-87af-60df-b6ad-07cb6fef4167@suse.com> Date: Thu, 25 Jun 2020 17:16:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Paul Durrant , Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" While commit b72682c602b8 ("scripts: Use stat to check lock claim") validly indicates that stat has gained support for the special "-" command line option in 2009, we should still try to avoid breaking being able to run on even older distros. As it has been determined, contary to the comment in the script using /dev/stdin (/proc/self/fd/$_lockfd) is fine here, as Linux specially treats these /proc inodes. Suggested-by: Ian Jackson Signed-off-by: Jan Beulich --- a/tools/hotplug/Linux/locking.sh +++ b/tools/hotplug/Linux/locking.sh @@ -45,18 +45,14 @@ claim_lock() while true; do eval "exec $_lockfd<>$_lockfile" flock -x $_lockfd || return $? - # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or - # use bash's test -ef because those all go through what is - # actually a synthetic symlink in /proc and we aren't - # guaranteed that our stat(2) won't lose the race with an - # rm(1) between reading the synthetic link and traversing the - # file system to find the inum. stat(1) translates '-' into an - # fstat(2) of FD 0. So we just need to arrange the FDs properly - # to get the fstat(2) we need. stat will output two lines like: + # Although /dev/stdin (i.e. /proc/self/fd/0) looks like a symlink, + # stat(2) bypasses the synthetic symlink and directly accesses the + # underlying open-file. So this works correctly even if the file + # has been renamed or unlinked. stat will output two lines like: # WW.XXX # YY.ZZZ # which need to be separated and compared. - if stat=$( stat -L -c '%D.%i' - $_lockfile 0<&$_lockfd 2>/dev/null ) + if stat=$( stat -L -c '%D.%i' /dev/stdin $_lockfile 0<&$_lockfd 2>/dev/null ) then local file_stat local fd_stat From xen-devel-bounces@lists.xenproject.org Thu Jun 25 15:45:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 15:45:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joU4B-0007JA-FK; Thu, 25 Jun 2020 15:45:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joU4A-0007J5-DR for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 15:45:30 +0000 X-Inumbo-ID: e532f3d8-b6fa-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e532f3d8-b6fa-11ea-bb8b-bc764e2007e4; Thu, 25 Jun 2020 15:45:29 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: DKvuOglGO83TJI2Q/JrA8/EJnTKSexL7veK/gVm/II30nhPkPJB8L1z6gAolkWNScz3y8n/f8g XHaza5QyNE4PJPH9FgFRva7HWXRkVdpLNRZtTWNSLDaBssPOgxbuH1qKrJUaaHx6okVLYH9N8n XDUFDP5PTfgg7e8WaMxGqpZkrLlA50RXGdD6hY9ZHkcUH6N9iizB0omS57X4kLnLbh1Ok+etOK ppOwKzLU3p0jlvS90Le07mwcWZW5l7ids+gWIKUz8aozgYVTkTJ2CgEBa67zojsEndx9jzMlmP 5pI= X-SBRS: 2.7 X-MesageID: 21281166 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="21281166" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24308.50838.149966.847431@mariner.uk.xensource.com> Date: Thu, 25 Jun 2020 16:45:26 +0100 To: Jan Beulich , Paul Durrant Subject: Re: [PATCH] scripts: don't rely on "stat -" support In-Reply-To: <691aebb4-87af-60df-b6ad-07cb6fef4167@suse.com> References: <691aebb4-87af-60df-b6ad-07cb6fef4167@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jan Beulich writes ("[PATCH] scripts: don't rely on "stat -" support"): > While commit b72682c602b8 ("scripts: Use stat to check lock claim") > validly indicates that stat has gained support for the special "-" > command line option in 2009, we should still try to avoid breaking being > able to run on even older distros. As it has been determined, contary to > the comment in the script using /dev/stdin (/proc/self/fd/$_lockfd) is > fine here, as Linux specially treats these /proc inodes. > > Suggested-by: Ian Jackson > Signed-off-by: Jan Beulich Thanks. The only code change here is this: > --- a/tools/hotplug/Linux/locking.sh > +++ b/tools/hotplug/Linux/locking.sh > @@ -45,18 +45,14 @@ claim_lock() > - if stat=$( stat -L -c '%D.%i' - $_lockfile 0<&$_lockfd 2>/dev/null ) > + if stat=$( stat -L -c '%D.%i' /dev/stdin $_lockfile 0<&$_lockfd 2>/dev/null ) Reviewed-by: Ian Jackson Has anyone executed this ? Paul, can we have a release-ack ? Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 15:47:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 15:47:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joU64-0007R7-7F; Thu, 25 Jun 2020 15:47:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joU63-0007Qz-37 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 15:47:27 +0000 X-Inumbo-ID: 29b8e56d-b6fb-11ea-81f9-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 29b8e56d-b6fb-11ea-81f9-12813bfff9fa; Thu, 25 Jun 2020 15:47:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 28502B0B7; Thu, 25 Jun 2020 15:47:25 +0000 (UTC) Subject: Re: [PATCH] scripts: don't rely on "stat -" support To: Ian Jackson References: <691aebb4-87af-60df-b6ad-07cb6fef4167@suse.com> <24308.50838.149966.847431@mariner.uk.xensource.com> From: Jan Beulich Message-ID: <64c6a187-bf90-ae69-793b-0651bedd4f88@suse.com> Date: Thu, 25 Jun 2020 17:47:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24308.50838.149966.847431@mariner.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Jason Andryuk , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 25.06.2020 17:45, Ian Jackson wrote: > Jan Beulich writes ("[PATCH] scripts: don't rely on "stat -" support"): >> While commit b72682c602b8 ("scripts: Use stat to check lock claim") >> validly indicates that stat has gained support for the special "-" >> command line option in 2009, we should still try to avoid breaking being >> able to run on even older distros. As it has been determined, contary to >> the comment in the script using /dev/stdin (/proc/self/fd/$_lockfd) is >> fine here, as Linux specially treats these /proc inodes. >> >> Suggested-by: Ian Jackson >> Signed-off-by: Jan Beulich > > Thanks. > > The only code change here is this: > >> --- a/tools/hotplug/Linux/locking.sh >> +++ b/tools/hotplug/Linux/locking.sh >> @@ -45,18 +45,14 @@ claim_lock() >> - if stat=$( stat -L -c '%D.%i' - $_lockfile 0<&$_lockfd 2>/dev/null ) >> + if stat=$( stat -L -c '%D.%i' /dev/stdin $_lockfile 0<&$_lockfd 2>/dev/null ) > > Reviewed-by: Ian Jackson > > Has anyone executed this ? I have, of course, to confirm this fixes my issue. But I'm not sure that's what you've meant to ask - you may have wanted assurance that someone else has also tried it. Jan From xen-devel-bounces@lists.xenproject.org Thu Jun 25 16:10:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 16:10:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joUS3-0002Fs-Em; Thu, 25 Jun 2020 16:10:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joUS2-0002Fn-8t for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 16:10:10 +0000 X-Inumbo-ID: 572b6ddc-b6fe-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 572b6ddc-b6fe-11ea-bca7-bc764e2007e4; Thu, 25 Jun 2020 16:10:09 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: eiuNYBHtZmFNBY1n5+KpUwOir1+xn3vYmtVD6tm0FISPBas3SV1Says33mO++aOuMZtpqkg2fO UZdBIbXJuRP5gh1fWVnv4YCR9I9LgedfV9iWM+xJ+XErT6NxuDCkm+9ZGYWAXYAv4uOShTyOWB qmfWVc8/NblhRpNcc6VUvMhUrWhrKQH+sP0rk7LJHw1yxTIyI+DMuavYLII9/heMRwpqoLCNvU fn5F2KsA2V867ZSNHT0x+jH3s97LLnXtZm5PNf/hgKBb1ySZo917W6n+0WE+muJ/qNLCVM2UgI qkE= X-SBRS: 2.7 X-MesageID: 21284329 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,279,1589256000"; d="scan'208";a="21284329" Date: Thu, 25 Jun 2020 18:10:02 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource Message-ID: <20200625161002.GZ735@Air-de-Roger> References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> <20200625090552.GW735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200625090552.GW735@Air-de-Roger> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 25, 2020 at 11:05:52AM +0200, Roger Pau Monné wrote: > On Wed, Jun 24, 2020 at 04:01:44PM +0200, Jan Beulich wrote: > > On 24.06.2020 15:41, Julien Grall wrote: > > > On 24/06/2020 11:12, Jan Beulich wrote: > > >> On 23.06.2020 19:26, Roger Pau Monné wrote: > > >>> I'm confused. Couldn't we switch from uint64_aligned_t to plain > > >>> uint64_t (like it's currently on the Linux headers), and then use the > > >>> compat layer in Xen to handle the size difference when called from > > >>> 32bit environments? > > >> > > >> And which size would we use there? The old or the new one (breaking > > >> future or existing callers respectively)? Meanwhile I think that if > > >> this indeed needs to not be tools-only (which I still question), > > > > > > I think we now agreed on a subthread that the kernel needs to know the > > > layout of the hypercall. > > > > > >> then our only possible route is to add explicit padding for the > > >> 32-bit case alongside the change you're already making. > > > > > > AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make > > > incompatible the two incompatible? > > > > In principle yes. But they're putting the structure instance on the > > stack, so there's not risk from Xen reading 4 bytes too many. I'd > > prefer keeping the interface as is (i.e. with the previously > > implicit padding made explicit) to avoid risking to break other > > possible callers. But that's just my view on it, anyway ... > > Adding the padding is cleaner because we don't need any compat stuff > in order to access the structure from the caller, and we also keep the > original layout currently present on Xen headers. > > I can prepare a fix for the Linux kernel, if this approach is fine. So I went over this, and I'm not sure the point of adding the padding field at the end of the structure for 32bit x86. The current situation is the following: - Linux will use a struct on 32bit x86 that doesn't have the 4byte padding at the end. - Xen will copy 4bytes of garbage in that case, since the struct on Linux is allocated on the stack. So I suggest we take the approach found on this patch, that is remove the 8byte alignment from the frame field, which will in turn remove 4bytes of padding from the tail of the structure on 32bit x86. That would leave the following scenario: - The struct layout in Linux headers would be correct. - Xen already handles the struct size difference on x86 32bit vs 64bit, as the compat layer is currently doing the copy in compat_memory_op taking into account the size of the compat structure. - Removing the padding will work for all use cases: Linux will already be using the correct layout on x86 32bits, so no change will be required there. Any consumers using the tail padded structure will continue to work without issues, as Xen simply won't copy the tailing 4bytes. So I think the solution proposed in this patch is the correct one: switch uint64_aligned_t to uint64_t, no tail padding added on x86 32bits. I will adjust the commit message and resubmit if that's fine. Roger. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 16:23:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 16:23:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joUet-0003C1-MN; Thu, 25 Jun 2020 16:23:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joUes-0003Bw-9l for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 16:23:26 +0000 X-Inumbo-ID: 31a7c4f0-b700-11ea-8496-bc764e2007e4 Received: from mail-lj1-x242.google.com (unknown [2a00:1450:4864:20::242]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 31a7c4f0-b700-11ea-8496-bc764e2007e4; Thu, 25 Jun 2020 16:23:25 +0000 (UTC) Received: by mail-lj1-x242.google.com with SMTP id s1so7216793ljo.0 for ; Thu, 25 Jun 2020 09:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sbUpMJu7wKx3GgZhXQwM/K1fCpQIiCjnv9/o9CjARH8=; b=sk18Ju7lYnQVIeELxd+cAZ3es0sEqheEYrrha4+WDThUwMlB+ynm6VG6kjld4an6vD 2CLrZA1NcQktaCkN/Zofq/EQCBlUxkV7GTgdKun/FZMpmfF4wrz5eP2rb9khcAhaBpom nUwzMdhVpSNBcPQhPBOsAZ7eBzP8YK8F90MbcSrus46B099TutXViV8/644TqX5u25rf LR/zMVYTgaPVO55GajeZDR0LJ7YXSMOao7LWeyr+f7KJs/f8RQM9F2QullBGOnu1rReE A16wJr/qusYhJrcojUBM17cHny3HUQqyU51c3ujZZNqf36F4/BEc+5o9Y3pct6zpSXUF wL4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sbUpMJu7wKx3GgZhXQwM/K1fCpQIiCjnv9/o9CjARH8=; b=ZnDGBpSzzlSVPxNcbeyMqKpVKs9ZIAjBD78gIPDRaswVr3WDRBZiL/GvzPQVbr2N6z NISAxWwIfmdmOUmEE1kJ1FbaNIt7YoLLUtKfUE5v2bhHbRLvIg+t9PbRybC5QtYSyaAP 4CuOG9rEwCBFV4QrRnwkrvGC2yOTFgR95jK9bksI/7G+wad6LP9BwuEcC3bStT47gZqS eZcSM8tve4NJdhAlX7j7n+Lrrh43qTzxAEOolfXLTa28h3HcyQhiGZynuKF3e5FJWsjB rC+HhsxDP0+yl5Iu1JMs8h2KfVNIxGxXmHYZjqai6zEehu0ZB3EVKaVpmgvXuUhL1ZL/ +UjA== X-Gm-Message-State: AOAM533rOJJ09Y0rEZQvYwn6Hid+lZhsD5c+U6Vdwt0cEMnw+8vpbYyT vDsj+PCzl0XxYWSosy25w+ZwVKCBmPD2fGKyowY= X-Google-Smtp-Source: ABdhPJzPaM+xb35QUSEv4sop2AAPMHot1YlPR+T6V06iMGVzFmai9+P3uwzSHOS6S3CFG9I2KsVvoXegEd1sDjv8uwE= X-Received: by 2002:a2e:978b:: with SMTP id y11mr5423533lji.399.1593102204351; Thu, 25 Jun 2020 09:23:24 -0700 (PDT) MIME-Version: 1.0 References: <691aebb4-87af-60df-b6ad-07cb6fef4167@suse.com> <24308.50838.149966.847431@mariner.uk.xensource.com> <64c6a187-bf90-ae69-793b-0651bedd4f88@suse.com> In-Reply-To: <64c6a187-bf90-ae69-793b-0651bedd4f88@suse.com> From: Jason Andryuk Date: Thu, 25 Jun 2020 12:23:12 -0400 Message-ID: Subject: Re: [PATCH] scripts: don't rely on "stat -" support To: Jan Beulich Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Ian Jackson , "xen-devel@lists.xenproject.org" , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 25, 2020 at 11:47 AM Jan Beulich wrote: > > On 25.06.2020 17:45, Ian Jackson wrote: > > Jan Beulich writes ("[PATCH] scripts: don't rely on "stat -" support"): > >> While commit b72682c602b8 ("scripts: Use stat to check lock claim") > >> validly indicates that stat has gained support for the special "-" > >> command line option in 2009, we should still try to avoid breaking being > >> able to run on even older distros. As it has been determined, contary to > >> the comment in the script using /dev/stdin (/proc/self/fd/$_lockfd) is > >> fine here, as Linux specially treats these /proc inodes. > >> > >> Suggested-by: Ian Jackson > >> Signed-off-by: Jan Beulich > > > > Thanks. > > > > The only code change here is this: > > > >> --- a/tools/hotplug/Linux/locking.sh > >> +++ b/tools/hotplug/Linux/locking.sh > >> @@ -45,18 +45,14 @@ claim_lock() > >> - if stat=$( stat -L -c '%D.%i' - $_lockfile 0<&$_lockfd 2>/dev/null ) > >> + if stat=$( stat -L -c '%D.%i' /dev/stdin $_lockfile 0<&$_lockfd 2>/dev/null ) > > > > Reviewed-by: Ian Jackson > > > > Has anyone executed this ? > > I have, of course, to confirm this fixes my issue. But I'm not sure > that's what you've meant to ask - you may have wanted assurance > that someone else has also tried it. Tested-by: Jason Andryuk Reviewed-by: Jason Andryuk From xen-devel-bounces@lists.xenproject.org Thu Jun 25 16:35:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 16:35:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joUqo-00046k-TM; Thu, 25 Jun 2020 16:35:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joUqn-00046f-RG for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 16:35:45 +0000 X-Inumbo-ID: ea1ac5e0-b701-11ea-8206-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ea1ac5e0-b701-11ea-8206-12813bfff9fa; Thu, 25 Jun 2020 16:35:44 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: e9fzRMj/o4Fb/tv2uOXovEqPKGrjRfdWcLhgSbiRFHtGGH/ZpgjD2h0syg+5T4IwGfrWO9LXhy BsdxTTO0L+3aLycimaihhQOkNjfZXcN37QIYG2cwNsAaY0Oc0YMNuSFA4S7zWb04hSd76vVc2z Y5LmI8FDDncYhMroruH8EHUeCGYgIKREbzEbOBI2gA50riEzaLXPpz0/481iWzZfw14IwfiIJ+ T+U9tPsQRGT/z/PT0IJ0qvLoasBQZ0wyuXGyI8LbIu3mI29a5QcOmAUBb0lXdvDnk5qXZ4ySvB lIM= X-SBRS: 2.7 X-MesageID: 21287700 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,280,1589256000"; d="scan'208";a="21287700" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24308.53852.871947.61151@mariner.uk.xensource.com> Date: Thu, 25 Jun 2020 17:35:40 +0100 To: Jason Andryuk Subject: Re: [PATCH] scripts: don't rely on "stat -" support In-Reply-To: References: <691aebb4-87af-60df-b6ad-07cb6fef4167@suse.com> <24308.50838.149966.847431@mariner.uk.xensource.com> <64c6a187-bf90-ae69-793b-0651bedd4f88@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , Wei Liu , Jan Beulich , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jason Andryuk writes ("Re: [PATCH] scripts: don't rely on "stat -" support"): > On Thu, Jun 25, 2020 at 11:47 AM Jan Beulich wrote: > > > > On 25.06.2020 17:45, Ian Jackson wrote: > > > Jan Beulich writes ("[PATCH] scripts: don't rely on "stat -" support"): > > >> While commit b72682c602b8 ("scripts: Use stat to check lock claim") > > >> validly indicates that stat has gained support for the special "-" > > >> command line option in 2009, we should still try to avoid breaking being > > >> able to run on even older distros. As it has been determined, contary to > > >> the comment in the script using /dev/stdin (/proc/self/fd/$_lockfd) is > > >> fine here, as Linux specially treats these /proc inodes. > > >> > > >> Suggested-by: Ian Jackson > > >> Signed-off-by: Jan Beulich > > > > > > Thanks. > > > > > > The only code change here is this: > > > > > >> --- a/tools/hotplug/Linux/locking.sh > > >> +++ b/tools/hotplug/Linux/locking.sh > > >> @@ -45,18 +45,14 @@ claim_lock() > > >> - if stat=$( stat -L -c '%D.%i' - $_lockfile 0<&$_lockfd 2>/dev/null ) > > >> + if stat=$( stat -L -c '%D.%i' /dev/stdin $_lockfile 0<&$_lockfd 2>/dev/null ) > > > > > > Reviewed-by: Ian Jackson > > > > > > Has anyone executed this ? > > > > I have, of course, to confirm this fixes my issue. But I'm not sure > > that's what you've meant to ask - you may have wanted assurance > > that someone else has also tried it. > > Tested-by: Jason Andryuk > Reviewed-by: Jason Andryuk :-). Thanks, Ian. From xen-devel-bounces@lists.xenproject.org Thu Jun 25 17:31:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 17:31:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joVik-0000jW-Bk; Thu, 25 Jun 2020 17:31:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joVij-0000jR-W3 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 17:31:30 +0000 X-Inumbo-ID: b3e3bd62-b709-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b3e3bd62-b709-11ea-b7bb-bc764e2007e4; Thu, 25 Jun 2020 17:31:29 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0FEDB20789; Thu, 25 Jun 2020 17:31:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593106288; bh=WhqBDPdOBNk4Nn0nlm/U/FBDprV3efhSWtdS+mTEZhI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=KNaQ/3jj9TpuSnPt+fOmTGLlW7zN97Hc5nMeEhGWFn3RY4Vu5yOi/rL1784qarDyK p9hWwTE8sLerEFX9rM+jYpsgztP56cS6phku8LqLBrkd8JcN8KNPpoVQD+Ru6HllCU KTeOrcYXJqrOnQ00srcPg/hv/0Q/e8ghv8knwqvk= Date: Thu, 25 Jun 2020 10:31:27 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: "Michael S. Tsirkin" Subject: Re: [PATCH] xen: introduce xen_vring_use_dma In-Reply-To: <20200624181026-mutt-send-email-mst@kernel.org> Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Peng Fan , Stefano Stabellini , konrad.wilk@oracle.com, jasowang@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, linux-imx@nxp.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma APIs to map the > > > > > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > > > > > disabled, it is not required. > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > Unfortunately it is complicated and it is not related to > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate > > > > foreign mappings (memory coming from other VMs) to physical addresses. > > > > On x86, it also uses dma_ops to translate Linux's idea of a physical > > > > address into a real physical address (this is unneeded on ARM.) > > > > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > > > > always and on Xen/ARM if Linux is Dom0 (because it has foreign > > > > mappings.) That is why we have the if (xen_domain) return true; in > > > > vring_use_dma_api. > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > > > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > Unfortunately as a result Xen never got around to > > > properly setting VIRTIO_F_IOMMU_PLATFORM. > > > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this because > > the usage of swiotlb_xen is not a property of virtio, > > > Basically any device without VIRTIO_F_ACCESS_PLATFORM > (that is it's name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is > what linux calls it) is declared as "special, don't follow normal rules > for access". > > So yes swiotlb_xen is not a property of virtio, but what *is* a property > of virtio is that it's not special, just a regular device from DMA POV. I am trying to understand what you meant but I think I am missing something. Are you saying that modern virtio should always have VIRTIO_F_ACCESS_PLATFORM, hence use normal dma_ops as any other devices? If that is the case, how is it possible that virtio breaks on ARM using the default dma_ops? The breakage is not Xen related (except that Xen turns dma_ops on). The original message from Peng was: vring_map_one_sg -> vring_use_dma_api -> dma_map_page -> __swiotlb_map_page ->swiotlb_map_page ->__dma_map_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir); However we are using per device dma area for rpmsg, phys_to_virt could not return a correct virtual address for virtual address in vmalloc area. Then kernel panic. I must be missing something. Maybe it is because it has to do with RPMesg? > > > > You might have noticed that I missed one possible case above: Xen/ARM > > > > DomU :-) > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if > > > > (xen_domain) return true; would give the wrong answer in that case. > > > > Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and > > > > the "normal" dma_ops fail. > > > > > > > > > > > > The solution I suggested was to make the check in vring_use_dma_api more > > > > flexible by returning true if the swiotlb_xen is supposed to be used, > > > > not in general for all Xen domains, because that is what the check was > > > > really meant to do. > > > > > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is wrong with that? > > > > swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops are the > > ones that are used. So you are saying, why don't we fix the default > > dma_ops to work with virtio? > > > > It is bad that the default dma_ops crash with virtio, so yes I think it > > would be good to fix that. However, even if we fixed that, the if > > (xen_domain()) check in vring_use_dma_api is still a problem. > > Why is it a problem? It just makes virtio use DMA API. > If that in turn works, problem solved. You are correct in the sense that it would work. However I do think it is wrong for vring_use_dma_api to enable dma_ops/swiotlb-xen for Xen/ARM DomUs that don't need it. There are many different types of Xen guests, Xen x86 is drastically different from Xen ARM, it seems wrong to treat them the same way. Anyway, re-reading the last messages of the original thread [1], it looks like Peng had a clear idea on how to fix the general issue. Peng, what happened with that? [1] https://lore.kernel.org/patchwork/patch/1033801/#1222404 From xen-devel-bounces@lists.xenproject.org Thu Jun 25 18:03:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 18:03:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joWDh-0003L0-06; Thu, 25 Jun 2020 18:03:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joWDf-0003Kd-T3 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 18:03:27 +0000 X-Inumbo-ID: 26f85a34-b70e-11ea-8214-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 26f85a34-b70e-11ea-8214-12813bfff9fa; Thu, 25 Jun 2020 18:03:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PN4vSdMCvpZaWpkPZZhRFg0htfdAiwswyyVQxp3z1PI=; b=xc6SbnOXXTY1np9zX0uQ2sUvF pJ67aFBgwKJG1Mphxxm4ayZALItaaDqrvsf6+drK2G9KuQHX9Xb+YTPwcjPsoC/LlUcgnNYnu5w+3 JUQbhLHV5cKFY7/waZXkLN6fDuL9WX4pxxWn4N5Cz8eF8OnVCos4EcX0qFS7q9JzNN7Xc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joWDX-0004sY-Ko; Thu, 25 Jun 2020 18:03:19 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joWDX-0003uL-1h; Thu, 25 Jun 2020 18:03:19 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joWDX-0003Jg-13; Thu, 25 Jun 2020 18:03:19 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-5.4 test] 151339: tolerable FAIL - PUSHED X-Osstest-Failures: linux-5.4:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:allowable linux-5.4:test-armhf-armhf-xl-rtds:guest-start:fail:allowable linux-5.4:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-5.4:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-5.4:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-5.4:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-5.4:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: linux=4e9688ad3d36e8f73c73e435f53da5ae1cd91a70 X-Osstest-Versions-That: linux=67cb016870e2fa9ffc8d34cf20db5331e6f2cf4d From: osstest service owner Date: Thu, 25 Jun 2020 18:03:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151339 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/151339/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 151307 test-armhf-armhf-xl-rtds 12 guest-start fail REGR. vs. 151307 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: linux 4e9688ad3d36e8f73c73e435f53da5ae1cd91a70 baseline version: linux 67cb016870e2fa9ffc8d34cf20db5331e6f2cf4d Last test of basis 151307 2020-06-23 04:05:50 Z 2 days Testing same since 151339 2020-06-24 16:09:27 Z 1 days 1 attempts ------------------------------------------------------------ 339 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds fail test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : hint: The 'hooks/update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-receive' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. hint: The 'hooks/post-update' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false`. To xenbits.xen.org:/home/xen/git/linux-pvops.git 67cb016870e2..4e9688ad3d36 4e9688ad3d36e8f73c73e435f53da5ae1cd91a70 -> tested/linux-5.4 From xen-devel-bounces@lists.xenproject.org Thu Jun 25 18:37:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 18:37:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joWkZ-0005un-OV; Thu, 25 Jun 2020 18:37:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joWkY-0005ui-20 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 18:37:26 +0000 X-Inumbo-ID: e9afe4b2-b712-11ea-821c-12813bfff9fa Received: from smtp-fw-6001.amazon.com (unknown [52.95.48.154]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e9afe4b2-b712-11ea-821c-12813bfff9fa; Thu, 25 Jun 2020 18:37:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1593110245; x=1624646245; h=date:from:to:cc:message-id:references:mime-version: content-transfer-encoding:in-reply-to:subject; bh=qlB2s4Wgnet0CN8ARSsKtfvhK92eox5FVS24rLtb+rU=; b=kFtqkyeNwhEqE38hIe+57b4QZWtp14cCjwhcqK2DQqZ7FKNZxuY7+ODT 5Jce2KqbmcSzaQPv9Zp8oR1nhQelujAR2lA+8+g1M6a0LkzS0FEcAMzcl s4rsz6leNCFFJUPPK/jpywF+NUwH3XgI9fAMcS5nHFH6qqiM+MYtDPZdW M=; IronPort-SDR: SCR/aF+rX11ye4y2opWfGY1ClwptB+a+zTCNmAF+d6fCjJf+qsOh77GBJkosreSA4gZmk3KUZB UVvuNlnLGzMQ== X-IronPort-AV: E=Sophos;i="5.75,280,1589241600"; d="scan'208";a="39889028" Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1a-7d76a15f.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP; 25 Jun 2020 18:37:25 +0000 Received: from EX13MTAUWB001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-7d76a15f.us-east-1.amazon.com (Postfix) with ESMTPS id E128AA275E; Thu, 25 Jun 2020 18:37:16 +0000 (UTC) Received: from EX13D05UWB001.ant.amazon.com (10.43.161.181) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 25 Jun 2020 18:36:59 +0000 Received: from EX13MTAUWB001.ant.amazon.com (10.43.161.207) by EX13D05UWB001.ant.amazon.com (10.43.161.181) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 25 Jun 2020 18:36:59 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.161.249) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 25 Jun 2020 18:36:59 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 66FC940359; Thu, 25 Jun 2020 18:36:59 +0000 (UTC) Date: Thu, 25 Jun 2020 18:36:59 +0000 From: Anchal Agarwal To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20200625183659.GA26586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200617083528.GW735@Air-de-Roger> <20200619234312.GA24846@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200622083846.GF735@Air-de-Roger> <20200623004314.GA28586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200623081903.GP735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200623081903.GP735@Air-de-Roger> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 23, 2020 at 10:19:03AM +0200, Roger Pau Monn wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On Tue, Jun 23, 2020 at 12:43:14AM +0000, Anchal Agarwal wrote: > > On Mon, Jun 22, 2020 at 10:38:46AM +0200, Roger Pau Monn wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > On Fri, Jun 19, 2020 at 11:43:12PM +0000, Anchal Agarwal wrote: > > > > On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monn wrote: > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > > > > > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monn wrote: > > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > > > > > > + "the device may become inconsistent state"); > > > > > > > > > > > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > > > > > > state and with the queues frozen. You should make an attempt to > > > > > > > > restore things to a working state. > > > > > > > > > > > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > > > > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > > > > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > > > > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > > > > > > > > > > > You can manually force this state, and then check that it will behave > > > > > > > correctly. I would expect that on a failure to disconnect from the > > > > > > > backend you should switch the frontend to the 'Init' state in order to > > > > > > > try to reconnect to the backend when possible. > > > > > > > > > > > > > From what I understand forcing manually is, failing the freeze without > > > > > > disconnect and try to revive the connection by unfreezing the > > > > > > queues->reconnecting to backend [which never got diconnected]. May be even > > > > > > tearing down things manually because I am not sure what state will frontend > > > > > > see if backend fails to to disconnect at any point in time. I assumed connected. > > > > > > Then again if its "CONNECTED" I may not need to tear down everything and start > > > > > > from Initialising state because that may not work. > > > > > > > > > > > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > > > > > > I don't see it getting handled in the backend then what will be backend's state? > > > > > > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > > > > > > if it tries to read backend's state through xenbus_read_driver_state ? > > > > > > > > > > > > So the flow be like: > > > > > > Front end marks XenbusStateClosing > > > > > > Backend marks its state as XenbusStateClosing > > > > > > Frontend marks XenbusStateClosed > > > > > > Backend disconnects calls xen_blkif_disconnect > > > > > > Backend fails to disconnect, the above function returns EBUSY > > > > > > What will be state of backend here? > > > > > > > > > > Backend should stay in state 'Closing' then, until it can finish > > > > > tearing down. > > > > > > > > > It disconnects the ring after switching to connected state too. > > > > > > Frontend did not tear down the rings if backend does not switches the > > > > > > state to 'Closed' in case of failure. > > > > > > > > > > > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend > > > > > > > > > > Backend will stay in state 'Closing' I think. > > > > > > > > > > > won't be calling connect(). {From reading code in frontend_changed} > > > > > > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > > > > > > we did not tear down anything so calling talk_to_blkback may not be needed > > > > > > > > > > > > Does that sound correct? > > > > > > > > > > I think switching to the initial state in order to try to attempt a > > > > > reconnection would be our best bet here. > > > > > > > > > It does not seems to work correctly, I get hung tasks all over and all the > > > > requests to filesystem gets stuck. Backend does shows the state as connected > > > > after xenbus_dev_suspend fails but I think there may be something missing. > > > > I don't seem to get IO interrupts thereafter i.e hitting the function blkif_interrupts. > > > > I think just marking it initialised may not be the only thing. > > > > Here is a short description of what I am trying to do: > > > > So, on timeout: > > > > Switch XenBusState to "Initialized" > > > > unquiesce/unfreeze the queues and return > > > > mark info->connected = BLKIF_STATE_CONNECTED > > > > > > If xenbus state is Initialized isn't it wrong to set info->connected > > > == CONNECTED? > > > > > Yes, you are right earlier I was marking it explicitly but that was not right, > > the connect path for blkfront will do that. > > > You should tear down all the internal state (like a proper close)? > > > > > Isn't that similar to disconnecting in the first place that failed during > > freeze? Do you mean re-try to close but this time re-connect after close > > basically do everything you would at "restore"? > > Last time I checked blkfront supported reconnections (ie: disconnect > from a backend and connect again). I was assuming we could apply the > same here on timeout, and just follow the same path where the frontend > waits indefinitely for the backend to close and then attempts to > reconnect. > > > Also, I experimented with that and it works intermittently. I want to take a > > step back on this issue and ask few questions here: > > 1. Is fixing this recovery a blocker for me sending in a V2 version? > > At the end of day it's your feature. I would certainly prefer for it > to work as good as possible, this being a recovery in case of failure > just make sure it does something sane (ie: crash/close the frontend) > and add a TODO note. > > > 2. In our 2-3 years of supporting this feature at large scale we haven't seen this issue > > where backend fails to disconnect. What we are trying to do here is create a > > hypothetical situation where we leave backend in Closing state and try and see how it > > recovers. The reason why I think it "may not" occur and the timeout of 5HZ is > > sufficient is because we haven't come across even a single use-case where it > > caused hibernation to fail. > > The reason why I think "it may" occur is if we are running a really memory > > intensive workload and ring is busy and is unable to complete all the requests > > in the given timeout. This is very unlikely though. > > As said above I would generally prefer for code to handle possible > failures the best way, and hence I think here it would be nice to > fallback to the normal disconnect path and just wait for the backend > to close. > Do you mind throwing some light in here, what that path may be, if its straight forward to fix I would like to debug it a bit more. May be I am missing some of the context here. I was of the view we may just want to mark frontend closed which should do the job of freeing resources and then following the same flow as blkfront_restore. That does not seems to work correctly 100% of the time. > You likely have this very well tuned to your own environment and > workloads, since this will now be upstream others might have more > contended systems where it could start to fail. > I agree, however, this is also from the testing I did with 100 of runs outside of EC2 running few tests of my own. > > 3) Also, I do not think this may be straight forward to fix and expect > > hibernation to work flawlessly in subsequent invocations. I am open to > > all suggestions. > > Right, adding a TODO would seem appropriate then. > Just to double check, I will send in a V2 with this marked as TO-DO? > Roger. Thanks, Anchal From xen-devel-bounces@lists.xenproject.org Thu Jun 25 19:03:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 19:03:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joX9Z-0008Nu-Sn; Thu, 25 Jun 2020 19:03:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joX9Z-0008NY-0Z for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 19:03:17 +0000 X-Inumbo-ID: 836ee9ba-b716-11ea-8224-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 836ee9ba-b716-11ea-8224-12813bfff9fa; Thu, 25 Jun 2020 19:03:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+9qi2+HKJBtb/EluMuwP84nDyFiJ0GTeinpb+JkbW4I=; b=VTZ/u2sP+Ckv50rEbVFQpT9p2 33WpDn/zIxB9XdU2Q53tzM/w6pMfoHWME6adS7f8NX1v4JqXv9oaPxUD5ZRXhMVASoKYwOv1FS/bw /4h7qAhP+8npwIMuV9Xl+mdAUDMgIs6jnhtXss/ETdS+k4cp6TcxL2HZSmoyQDw67BAeY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joX9S-0005zG-KB; Thu, 25 Jun 2020 19:03:10 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joX9S-0006ek-9X; Thu, 25 Jun 2020 19:03:10 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joX9S-00008O-8y; Thu, 25 Jun 2020 19:03:10 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [seabios test] 151340: tolerable FAIL - PUSHED X-Osstest-Failures: seabios:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking seabios:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking seabios:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: seabios=dd6a7e99b1c32ca66048673442cc7152efd08d2d X-Osstest-Versions-That: seabios=2e3de6253422112ae43e608661ba94ea6b345694 From: osstest service owner Date: Thu, 25 Jun 2020 19:03:10 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151340 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/151340/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 150375 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 150375 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 150375 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 150375 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: seabios dd6a7e99b1c32ca66048673442cc7152efd08d2d baseline version: seabios 2e3de6253422112ae43e608661ba94ea6b345694 Last test of basis 150375 2020-05-26 06:51:50 Z 30 days Testing same since 151340 2020-06-24 16:10:05 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Jason Andryuk jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/seabios.git 2e3de62..dd6a7e9 dd6a7e99b1c32ca66048673442cc7152efd08d2d -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Thu Jun 25 22:59:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 22:59:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joapo-0001qM-1Z; Thu, 25 Jun 2020 22:59:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joapm-0001q2-BY for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 22:59:06 +0000 X-Inumbo-ID: 753fda18-b737-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 753fda18-b737-11ea-bb8b-bc764e2007e4; Thu, 25 Jun 2020 22:59:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xiBsiCjBvzXjq8ajQa26fPq0g0buwfW3OVR1z2/N3zQ=; b=QcFDgPd25F+6hCL8agZH1Ybs+ YaNcxnkalTv7sWtiwYLPUrsemRNuK5Zq1JZ3bG+Yi8QjO6LQ4r9ri3/8GfhXMM9vKCLswIuyOjLb1 fC6sg6Pc6QJb8hDMdFtgVC1CoqKORPd8iBMlD+GLpoXFBmyXnlX3o85hge16IbQl1Hhzk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joapg-0001rn-Gj; Thu, 25 Jun 2020 22:59:00 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joapg-0001UG-8e; Thu, 25 Jun 2020 22:59:00 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joapg-0003D3-5j; Thu, 25 Jun 2020 22:59:00 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151347: all pass - PUSHED X-Osstest-Versions-This: ovmf=a4a2258a1fec66665481b0bd929b049921cb07a0 X-Osstest-Versions-That: ovmf=1a992030522622c42aa063788b3276789c56c1e1 From: osstest service owner Date: Thu, 25 Jun 2020 22:59:00 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151347 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151347/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf a4a2258a1fec66665481b0bd929b049921cb07a0 baseline version: ovmf 1a992030522622c42aa063788b3276789c56c1e1 Last test of basis 151320 2020-06-23 22:10:13 Z 2 days Testing same since 151347 2020-06-24 19:53:27 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Abner Chang Ard Biesheuvel Ray Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 1a99203052..a4a2258a1f a4a2258a1fec66665481b0bd929b049921cb07a0 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Thu Jun 25 23:31:52 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 25 Jun 2020 23:31:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jobLM-00052J-Ms; Thu, 25 Jun 2020 23:31:44 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jobLL-00052E-H8 for xen-devel@lists.xenproject.org; Thu, 25 Jun 2020 23:31:43 +0000 X-Inumbo-ID: 05b64c0e-b73c-11ea-8260-12813bfff9fa Received: from aserp2120.oracle.com (unknown [141.146.126.78]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 05b64c0e-b73c-11ea-8260-12813bfff9fa; Thu, 25 Jun 2020 23:31:41 +0000 (UTC) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05PNS37G151842; Thu, 25 Jun 2020 23:31:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=hp4NW8K0tE7ZTsvZygUaBifULzCN75O89Z8WIkYZ71k=; b=HlSyY2B32/reyijvbdF0OOu4sFXA4uHCB1oM5Nh4VKjswd10hUyABcZt5MHKS20ET1rD BdfqjUtC76iGL+hMxdO4dbR/ZvcfkUGtxYjpcoDSyP+ii2siPzYgzf4NGbDxF9jmr3cD ONcnokZ/Y1M7Fbdg+ioQ76+LqGq10lj1rAYqigCkQNodwJ6sd7bJsQZ+Xjs1xkEdb54o EeyPIKh+9epM8hmi/f196N6svvLcOqB20rfS9QViyExxERLn+lQcNu+0F0eX1ypHE2pQ q35PdHP8gH+0aBoQW48bfgmCv1MmtGs/gqRUadlDJce44pG71Ic6PzWY+btBe22EXnzH +A== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 31uusu3aft-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 25 Jun 2020 23:31:38 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05PNRS59015525; Thu, 25 Jun 2020 23:31:37 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 31uurt9mtc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jun 2020 23:31:37 +0000 Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 05PNVZsS017903; Thu, 25 Jun 2020 23:31:36 GMT Received: from [10.39.193.141] (/10.39.193.141) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Jun 2020 23:31:35 +0000 Subject: Re: [PATCH 1/2] xen/privcmd: Corrected error handling path and mark pages dirty To: Souptick Joarder , jgross@suse.com, sstabellini@kernel.org References: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: Date: Thu, 25 Jun 2020 19:31:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9663 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006250136 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9663 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 cotscore=-2147483648 malwarescore=0 mlxscore=0 clxscore=1011 lowpriorityscore=0 mlxlogscore=999 phishscore=0 priorityscore=1501 spamscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006250136 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Paul Durrant , John Hubbard Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/24/20 11:02 PM, Souptick Joarder wrote: > Previously, if lock_pages() end up partially mapping pages, it used > to return -ERRNO due to which unlock_pages() have to go through > each pages[i] till *nr_pages* to validate them. This can be avoided > by passing correct number of partially mapped pages & -ERRNO separately= , > while returning from lock_pages() due to error. > > With this fix unlock_pages() doesn't need to validate pages[i] till > *nr_pages* for error scenario and few condition checks can be ignored. > > As discussed, pages need to be marked as dirty before unpinned it in > unlock_pages() which was oversight. There are two unrelated changes here (improving error path and marking pages dirty), they should be handled by separate patches. (I assume marking pages dirty is something you want to go to stable tree since otherwise there is no reason for making this change) > > Signed-off-by: Souptick Joarder > Cc: John Hubbard > Cc: Boris Ostrovsky > Cc: Paul Durrant > --- > Hi, > > I'm compile tested this, I don't think so. > but unable to run-time test, so any testing > help is much appriciated. > > drivers/xen/privcmd.c | 34 +++++++++++++++++++--------------- > 1 file changed, 19 insertions(+), 15 deletions(-) > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index a250d11..0da417c 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -580,43 +580,44 @@ static long privcmd_ioctl_mmap_batch( > =20 > static int lock_pages( > struct privcmd_dm_op_buf kbufs[], unsigned int num, > - struct page *pages[], unsigned int nr_pages) > + struct page *pages[], unsigned int nr_pages, int *pinned) > { > unsigned int i; > + int errno =3D 0, page_count =3D 0; No need for error, really --- you can return the value immediately. > =20 > for (i =3D 0; i < num; i++) { > unsigned int requested; > - int pinned; > =20 > + *pinned +=3D page_count; I'd move this lower, after a successful call to get_user_pages_fast() (and then you won't need to initialize it) > requested =3D DIV_ROUND_UP( > offset_in_page(kbufs[i].uptr) + kbufs[i].size, > PAGE_SIZE); > if (requested > nr_pages) > return -ENOSPC; > =20 > - pinned =3D get_user_pages_fast( > + page_count =3D get_user_pages_fast( > (unsigned long) kbufs[i].uptr, > requested, FOLL_WRITE, pages); > - if (pinned < 0) > - return pinned; > + if (page_count < 0) { > + errno =3D page_count; > + return errno; > + } > =20 > - nr_pages -=3D pinned; > - pages +=3D pinned; > + nr_pages -=3D page_count; > + pages +=3D page_count; > } > =20 > - return 0; > + return errno; > } > =20 > static void unlock_pages(struct page *pages[], unsigned int nr_pages) > { > unsigned int i; > =20 > - if (!pages) > - return; > - > for (i =3D 0; i < nr_pages; i++) { > - if (pages[i]) > - put_page(pages[i]); > + if (!PageDirty(page)) > + set_page_dirty_lock(page); > + put_page(pages[i]); > } This won't compile. -boris From xen-devel-bounces@lists.xenproject.org Fri Jun 26 01:27:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 01:27:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jod8c-0007E0-5z; Fri, 26 Jun 2020 01:26:42 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jod8b-0007Dv-81 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 01:26:41 +0000 X-Inumbo-ID: 14e9b4e4-b74c-11ea-826b-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 14e9b4e4-b74c-11ea-826b-12813bfff9fa; Fri, 26 Jun 2020 01:26:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HYXf60jCqKIIefgrDH4qnuRhJNeDPx9Y45XrSz0VNYk=; b=W9YOTYwadJq8fqsYxb1On2Bnl MrXeU4ZFLM1dy2O/sd/0oDs4FmJVxU4b5jBCf9roXqQW+GcAAnoiEsEkrFby2zNFYH5D3bDX4K+LB mUUpvPUDT0A6f3vHDR4fUP57bu/EGOn4Dzbt9BjnIonyF7UzIgS6AabmS/fnhJk4u241w=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jod8X-0006VV-QY; Fri, 26 Jun 2020 01:26:37 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jod8X-0000BT-Hh; Fri, 26 Jun 2020 01:26:37 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jod8X-0001DQ-H2; Fri, 26 Jun 2020 01:26:37 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151341: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-i386-xl-raw:guest-localmigrate/x10:fail:regression xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=050fe48dc981e0488de1f6c6c07d8110f3b7523b X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Fri, 26 Jun 2020 01:26:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151341 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151341/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail REGR. vs. 150176 build-amd64-prev 6 xen-build fail REGR. vs. 150176 test-amd64-i386-xl-raw 17 guest-localmigrate/x10 fail REGR. vs. 150176 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 050fe48dc981e0488de1f6c6c07d8110f3b7523b baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 42 days Failing since 150943 2020-06-09 17:06:00 Z 16 days 14 attempts Testing same since 151341 2020-06-24 16:34:12 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Igor Druzhinin Jan Beulich Jason Andryuk Julien Grall Paul Durrant Roger Pau Monné Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev fail build-i386-prev fail build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade blocked test-amd64-i386-migrupgrade blocked test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw fail test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 587 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 26 03:11:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 03:11:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joem0-0007uR-3S; Fri, 26 Jun 2020 03:11:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joelz-0007uM-EE for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 03:11:27 +0000 X-Inumbo-ID: b751d6fe-b75a-11ea-8273-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b751d6fe-b75a-11ea-8273-12813bfff9fa; Fri, 26 Jun 2020 03:11:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Message-Id:Subject:To:Sender: Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=pgWpzwVbMMCYNIbsbfRIZWGpSGG/MuIgXQWW0OTka20=; b=EW9LW6x90oxy3HIrstZW7nD6DP F8751OWUaLQ0vA7phnhzU0Tw553Fle+THF0eAJAQLR0Bjx0RDlVXkrHNTfuc7L/iaND2C5i6Vt1FV CRYP9d4bA+AdL76UiXHOU9VNCJxz7u9ABBvl4xoyR3zlVNeCRw1veE+az/quroqySI/0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joelv-0000P3-JO; Fri, 26 Jun 2020 03:11:23 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joelv-00059q-8U; Fri, 26 Jun 2020 03:11:23 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joelv-000198-7p; Fri, 26 Jun 2020 03:11:23 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Subject: [qemu-mainline bisection] complete test-amd64-i386-libvirt-pair Message-Id: From: osstest service owner Date: Fri, 26 Jun 2020 03:11:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" branch xen-unstable xenbranch xen-unstable job test-amd64-i386-libvirt-pair testid guest-start/debian Tree: libvirt git://xenbits.xen.org/libvirt.git Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 81cb05732efb36971901c515b007869cc1d3a532 Bug not present: d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/151366/ commit 81cb05732efb36971901c515b007869cc1d3a532 Author: Markus Armbruster Date: Tue Jun 9 14:23:37 2020 +0200 qdev: Assert devices are plugged into a bus that can take them This would have caught some of the bugs I just fixed. Signed-off-by: Markus Armbruster Reviewed-by: Mark Cave-Ayland Message-Id: <20200609122339.937862-23-armbru@redhat.com> For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-i386-libvirt-pair.guest-start--debian.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Running cs-bisection-step --graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-i386-libvirt-pair.guest-start--debian --summary-out=tmp/151366.bisection-summary --basis-template=151065 --blessings=real,real-bisect qemu-mainline test-amd64-i386-libvirt-pair guest-start/debian Searching for failure / basis pass: 151328 fail [dst_host=albana1,src_host=albana0] / 151149 [dst_host=huxelrebe0,src_host=huxelrebe1] 151101 [dst_host=fiano1,src_host=fiano0] 151065 [dst_host=pinot0,src_host=pinot1] 151047 [dst_host=chardonnay0,src_host=chardonnay1] 150970 [dst_host=pinot1,src_host=pinot0] 150930 [dst_host=albana0,src_host=albana1] 150916 [dst_host=huxelrebe1,src_host=huxelrebe0] 150909 [dst_host=elbling1,src_host=elbling0] 150895 [dst_host=huxelrebe0,src_host=huxelrebe1] 150831 [dst_host=chardonnay1,src_host=ch\ ardonnay0] 150694 [dst_host=fiano0,src_host=fiano1] 150631 ok. Failure / basis pass flights: 151328 / 150631 (tree with no url: minios) (tree in basispass but not in latest: libvirt_gnulib) Tree: libvirt git://xenbits.xen.org/libvirt.git Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest 96a39aad705f8e37950109d11636085b212af790 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 00b8bf7eda00fb6f0197d3968b6078cfdb4870fa 3c659044118e34603161457db9934a34f816d78b d88d5a3806d78dcfca648c62dae9d88d3e803bd2 2e3de6253422112ae43e608661ba94ea6b345694 fde76f895d0aa817a1207d844d793239c6639bc6 Basis pass a1cd25b919509be2645dbe6f952d5263e0d4e4e5 317d3eeb963a515e15a63fa356d8ebcda7041a51 c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/libvirt.git#a1cd25b919509be2645dbe6f952d5263e0d4e4e5-96a39aad705f8e37950109d11636085b212af790 https://gitlab.com/keycodemap/keycodemapdb.git#317d3eeb963a515e15a63fa356d8ebcda7041a51-27acf0ef828bf719b2053ba398b195829413dbdd git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0\ dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9-00b8bf7eda00fb6f0197d3968b6078cfdb4870fa git://xenbits.xen.org/qemu-xen-traditional.git#3c659044118e34603161457db9934a34f816d78b-3c659044118e34603161457db9934a34f816d78b git://git.qemu.org/qemu.git#5cc7a54c2e91d82cb6a52e4921325c511fd90712-d88d5a3806d78dcfca648c62dae9d88d3e803bd2 git://xenbits.xen.org/osstest/seabios.git#2e3de6253422112ae43e608661ba94ea6b345694-2e3de62\ 53422112ae43e608661ba94ea6b345694 git://xenbits.xen.org/xen.git#1497e78068421d83956f8e82fb6e1bf1fc3b1199-fde76f895d0aa817a1207d844d793239c6639bc6 Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. error: The last gc run reported the following. Please correct the root cause and remove gc.log. Automatic cleanup will not be performed until the file is removed. warning: There are too many unreachable loose objects; run 'git prune' to remove them. Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. error: The last gc run reported the following. Please correct the root cause and remove gc.log. Automatic cleanup will not be performed until the file is removed. warning: There are too many unreachable loose objects; run 'git prune' to remove them. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Loaded 135201 nodes in revision graph Searching for test results: 150631 pass a1cd25b919509be2645dbe6f952d5263e0d4e4e5 317d3eeb963a515e15a63fa356d8ebcda7041a51 c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 150694 [dst_host=fiano0,src_host=fiano1] 150831 [dst_host=chardonnay1,src_host=chardonnay0] 150909 [dst_host=elbling1,src_host=elbling0] 150930 [dst_host=albana0,src_host=albana1] 150916 [dst_host=huxelrebe1,src_host=huxelrebe0] 150895 [dst_host=huxelrebe0,src_host=huxelrebe1] 150899 [] 150970 [dst_host=pinot1,src_host=pinot0] 151047 [dst_host=chardonnay0,src_host=chardonnay1] 151101 [dst_host=fiano1,src_host=fiano0] 151065 [dst_host=pinot0,src_host=pinot1] 151149 [dst_host=huxelrebe0,src_host=huxelrebe1] 151221 fail irrelevant 151175 fail irrelevant 151241 fail irrelevant 151342 blocked 6f60d2a8503ce8c624bce6b53bf7b68476f5056f 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 3351acaee706b8e238b031a456bf181f97f167c3 151317 fail 1eabe312ea4fa80922443ad73a950857c1f87786 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 9fc7fc4d3909817555ce0af6bcb69dff1606140d 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151299 pass a1cd25b919509be2645dbe6f952d5263e0d4e4e5 317d3eeb963a515e15a63fa356d8ebcda7041a51 c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151331 pass b934d5f42f29764277bc6f0f1cae19ada6f85e74 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 3c659044118e34603161457db9934a34f816d78b 86e8c353f705f14f2f2fd7a6195cefa431aa24d9 2e3de6253422112ae43e608661ba94ea6b345694 058023b343d4e366864831db46e9b438e9e3a178 151300 fail irrelevant 151286 fail irrelevant 151332 pass 63d08bec0b2dace2fcefffb23a1fa5b14c473d67 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 567bc4b4ae8a975791382dd30ac413bc0d3ce88c 3c659044118e34603161457db9934a34f816d78b 3575b0aea983ad57804c9af739ed8ff7bc168393 2e3de6253422112ae43e608661ba94ea6b345694 b91825f628c9a62cf2a3a0d972ea81484a8b7fce 151301 fail irrelevant 151269 fail irrelevant 151319 pass 63d08bec0b2dace2fcefffb23a1fa5b14c473d67 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3ee4f6cb360a877d171f2f9bb76b0d46d2cfa985 3c659044118e34603161457db9934a34f816d78b 9f1f264edbdf5516d6f208497310b3eedbc7b74c 2e3de6253422112ae43e608661ba94ea6b345694 2995d0afdf2d3fb44d07eada088db3613741db1e 151343 blocked a03738cee469f05d4059b67bdec3da6b8196da4d 317d3eeb963a515e15a63fa356d8ebcda7041a51 c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151333 pass f45735786a3d9bee622f80eab75131b0da485798 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 3c659044118e34603161457db9934a34f816d78b 49ee11555262a256afec592dfed7c5902d5eefd2 2e3de6253422112ae43e608661ba94ea6b345694 726c78d14dfe6ec76f5e4c7756821a91f0a04b34 151328 fail 96a39aad705f8e37950109d11636085b212af790 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 00b8bf7eda00fb6f0197d3968b6078cfdb4870fa 3c659044118e34603161457db9934a34f816d78b d88d5a3806d78dcfca648c62dae9d88d3e803bd2 2e3de6253422112ae43e608661ba94ea6b345694 fde76f895d0aa817a1207d844d793239c6639bc6 151305 fail irrelevant 151359 fail 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 9940b2cfbc05cdffdf6b42227a80cb1e6d2a85c2 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151349 pass 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 5e769ecf509089c053bb247ae48a360ef8e87d66 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151309 fail irrelevant 151344 blocked d3d87e0cefd7144c559dd23fef789e7e37f74e76 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151310 fail 6f28865223292a816f1bfde589901a00156cf8a1 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 58ae92a993687d913aa6dd00ef3497a1bc5f6c40 3c659044118e34603161457db9934a34f816d78b 54cdfe511219b8051046be55a6e156c4f08ff7ff 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151322 pass 9170b0ee6f867d2be1165e83c80910b0e0ac952d 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 e1d24410da356731da70b3334f86343e11e207d2 3c659044118e34603161457db9934a34f816d78b 470dd165d152ff7ceac61c7b71c2b89220b3aad7 2e3de6253422112ae43e608661ba94ea6b345694 6a49b9a7920c82015381740905582b666160d955 151312 fail 3a58613b0cf6a29960b909e6fd7420639ff794bd 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a2433243fbe471c250d7eddc2c7da325d91265fd 3c659044118e34603161457db9934a34f816d78b 6675a653d2e57ab09c32c0ea7b44a1d6c40a7f58 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151335 pass f45735786a3d9bee622f80eab75131b0da485798 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae 3c659044118e34603161457db9934a34f816d78b 5d2f557b47dfbf8f23277a5bdd8473d4607c681a 2e3de6253422112ae43e608661ba94ea6b345694 51ca66c37371b10b378513af126646de22eddb17 151313 pass cf9e7726b38bc93a2728638d435199297d2b3aaa 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 53550e81e2cafe7c03a39526b95cd21b5194d9b1 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151304 fail 96a39aad705f8e37950109d11636085b212af790 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 322969adf1fb3d6cfbd613f35121315715aff2ed 3c659044118e34603161457db9934a34f816d78b 171199f56f5f9bdf1e5d670d09ef1351d8f01bae 2e3de6253422112ae43e608661ba94ea6b345694 fde76f895d0aa817a1207d844d793239c6639bc6 151325 pass 63d08bec0b2dace2fcefffb23a1fa5b14c473d67 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 567bc4b4ae8a975791382dd30ac413bc0d3ce88c 3c659044118e34603161457db9934a34f816d78b eea8f5df4ecc607d64f091b8d916fcc11a697541 2e3de6253422112ae43e608661ba94ea6b345694 2995d0afdf2d3fb44d07eada088db3613741db1e 151314 pass cf9e7726b38bc93a2728638d435199297d2b3aaa 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a2433243fbe471c250d7eddc2c7da325d91265fd 3c659044118e34603161457db9934a34f816d78b 250bc43a406f7d46e319abe87c19548d4f027828 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151345 blocked 8400b6c1983dd1e4504fe19d3421fff0e5866091 317d3eeb963a515e15a63fa356d8ebcda7041a51 c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151336 blocked bc85c34ea91c46588423fa24e56e09ca5aab31dd 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae 3c659044118e34603161457db9934a34f816d78b 7d2410cea154bf915fb30179ebda3b17ac36e70e 2e3de6253422112ae43e608661ba94ea6b345694 780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 151326 pass a1cd25b919509be2645dbe6f952d5263e0d4e4e5 317d3eeb963a515e15a63fa356d8ebcda7041a51 c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151329 fail 96a39aad705f8e37950109d11636085b212af790 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 322969adf1fb3d6cfbd613f35121315715aff2ed 3c659044118e34603161457db9934a34f816d78b 171199f56f5f9bdf1e5d670d09ef1351d8f01bae 2e3de6253422112ae43e608661ba94ea6b345694 fde76f895d0aa817a1207d844d793239c6639bc6 151364 fail 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151355 fail 1eabe312ea4fa80922443ad73a950857c1f87786 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 3e80f6902c13f6edb6675c0f33edcbbf0163ec32 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151338 blocked 611e03127fcc84c7cd64b1da30140ca3b8fa1269 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bb78cfbec07eda45118b630a09b0af549b43a135 3c659044118e34603161457db9934a34f816d78b fe0fe4735e798578097758781166cc221319b93d 2e3de6253422112ae43e608661ba94ea6b345694 d9f58cd54fe2f05e1f05e2fe254684bd1840de8e 151346 pass 2a372a5ad5fab3bf26fb9bea019d38fa04ba8b34 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 3c659044118e34603161457db9934a34f816d78b 49ee11555262a256afec592dfed7c5902d5eefd2 2e3de6253422112ae43e608661ba94ea6b345694 835d8d69d96aa7feb52ef7b3dd8ecf43f0807578 151360 fail 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b dfe8c79c44680e34eac2e8abd0d0c885ce01aa55 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151348 pass 63d08bec0b2dace2fcefffb23a1fa5b14c473d67 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 567bc4b4ae8a975791382dd30ac413bc0d3ce88c 3c659044118e34603161457db9934a34f816d78b f1aeb14b0809e313c74244d838645ed25e85ea63 2e3de6253422112ae43e608661ba94ea6b345694 2995d0afdf2d3fb44d07eada088db3613741db1e 151351 pass a1cd25b919509be2645dbe6f952d5263e0d4e4e5 317d3eeb963a515e15a63fa356d8ebcda7041a51 c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9 3c659044118e34603161457db9934a34f816d78b 5cc7a54c2e91d82cb6a52e4921325c511fd90712 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151354 fail 96a39aad705f8e37950109d11636085b212af790 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 00b8bf7eda00fb6f0197d3968b6078cfdb4870fa 3c659044118e34603161457db9934a34f816d78b d88d5a3806d78dcfca648c62dae9d88d3e803bd2 2e3de6253422112ae43e608661ba94ea6b345694 fde76f895d0aa817a1207d844d793239c6639bc6 151357 pass 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151362 pass 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151361 fail 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151366 fail 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151365 pass 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 Searching for interesting versions Result found: flight 150631 (pass), for basis pass Result found: flight 151328 (fail), for basis failure Repro found: flight 151351 (pass), for basis pass Repro found: flight 151354 (fail), for basis failure 0 revisions at 8a4f331e8cb662d787a310df07fefd080879abde 27acf0ef828bf719b2053ba398b195829413dbdd c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 No revisions left to test, checking graph state. Result found: flight 151357 (pass), for last pass Result found: flight 151361 (fail), for first failure Repro found: flight 151362 (pass), for last pass Repro found: flight 151364 (fail), for first failure Repro found: flight 151365 (pass), for last pass Repro found: flight 151366 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 81cb05732efb36971901c515b007869cc1d3a532 Bug not present: d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/151366/ commit 81cb05732efb36971901c515b007869cc1d3a532 Author: Markus Armbruster Date: Tue Jun 9 14:23:37 2020 +0200 qdev: Assert devices are plugged into a bus that can take them This would have caught some of the bugs I just fixed. Signed-off-by: Markus Armbruster Reviewed-by: Mark Cave-Ayland Message-Id: <20200609122339.937862-23-armbru@redhat.com> dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.273455 to fit pnmtopng: 136 colors found Revision graph left in /home/logs/results/bisect/qemu-mainline/test-amd64-i386-libvirt-pair.guest-start--debian.{dot,ps,png,html,svg}. ---------------------------------------- 151366: tolerable FAIL flight 151366 qemu-mainline real-bisect [real] http://logs.test-lab.xenproject.org/osstest/logs/151366/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-i386-libvirt-pair 21 guest-start/debian fail baseline untested jobs: build-i386-libvirt pass test-amd64-i386-libvirt-pair fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary From xen-devel-bounces@lists.xenproject.org Fri Jun 26 03:53:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 03:53:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jofQO-0002nH-Hs; Fri, 26 Jun 2020 03:53:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jofQN-0002m3-0q for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 03:53:11 +0000 X-Inumbo-ID: 8a17e218-b760-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8a17e218-b760-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 03:53:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6xBBj/ZXf7Y1VG7EsWP2cuHASiygp6oFfSw7RzzQCJQ=; b=0UHmynZ1xDJHAG6U5TADROwzV hNAfhBS9QoH6UzplMHiySpcJK6cy5MrXf5S6UN+RjntWUHdnGGulXH4xckHiiyArQVERsPdQTe+gC qLUo4kQss/2M19XjRkCeQw3IDOK0KyTWgj9LFJkV/Sh+v3lmI634Pmksv+7pzt3eqrdW8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jofQG-00018E-H0; Fri, 26 Jun 2020 03:53:04 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jofQG-0007Df-5q; Fri, 26 Jun 2020 03:53:04 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jofQG-0005pd-5G; Fri, 26 Jun 2020 03:53:04 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151352: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=8c6dba054b012ad3d71bccc5b25cf297681d81d3 X-Osstest-Versions-That: libvirt=c5815b31976f3982d18c7f6c1367ab6e403eb7eb From: osstest service owner Date: Fri, 26 Jun 2020 03:53:04 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151352 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151352/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151330 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151330 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 8c6dba054b012ad3d71bccc5b25cf297681d81d3 baseline version: libvirt c5815b31976f3982d18c7f6c1367ab6e403eb7eb Last test of basis 151330 2020-06-24 05:57:45 Z 1 days Testing same since 151352 2020-06-25 04:18:49 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Daniel P. Berrangé Han Han Ján Tomko Laine Stump Michal Privoznik Prathamesh Chavan jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git c5815b3197..8c6dba054b 8c6dba054b012ad3d71bccc5b25cf297681d81d3 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Fri Jun 26 05:27:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 05:27:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jogtJ-0002AL-BB; Fri, 26 Jun 2020 05:27:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jogtH-0002AG-Er for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 05:27:07 +0000 X-Inumbo-ID: ac3644ae-b76d-11ea-bb8b-bc764e2007e4 Received: from mail-lj1-x244.google.com (unknown [2a00:1450:4864:20::244]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ac3644ae-b76d-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 05:27:06 +0000 (UTC) Received: by mail-lj1-x244.google.com with SMTP id h22so1831133lji.9 for ; Thu, 25 Jun 2020 22:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VuCEJOiQoqa0Rytop5ZoclTGnejYAU1zTtQWpgV+XJk=; b=tRZemnxbVY6+6epMlhA+YSEtiuBGPEfAgB7O3fyn6uOiRsNkYm8inikyYy99XChNgC IjyB5mPxS+WDnHZLaTELQk0or68E/i08k+5eQ3qHN3hKJ1lSGExWo7fLmnSljN8CSPZs 3aotvq09CnSbdrOE4Qao5qky74s3HwM8Lhtc8h6mzIfbma4aaEyH8/pfiNoqDA0cMX7m Hua8P47pfUW94Ms5WNu2oeE2qYHV5+np7uwKMXTbrBkfI6BepiAUIbwVtsafO2aWaVhP ZEYnQCUjJEmgnL+8WiH40CxOdIE5lltvkb7bOjS9g6lRMmYGAfsqdBfeGs60h3rO6SNw RTrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VuCEJOiQoqa0Rytop5ZoclTGnejYAU1zTtQWpgV+XJk=; b=YuzMbkNxWSeN5MarjmC6bKElZU8UaAUMfmdlmnbncIWdAqDA4m2XKbccxYENlkxMs9 VnUKiTwCrpPXWjANG0LGVwSDSRFQUxqpwZjIuhKwRgOs24np5NCKqjMSFNYLZCXRWRc2 C+p9hzgC2x0c5KmcxpSlu4KMVQO6id/YuK2wJVKYzMQpT8r3zvpJzl55Y+INhQflS8ZG BWB/VRVnVrkq5N2L9OsNyBWOpTyKlxfon4Qg0majey6EiQzAj/3/dUg9opjuVSwhkXzE RE+824IvJYT3VX/XZboC/Amup1j1x7PhPL9sRxgBF5gXAyqP6Oe7sbkN5HNXDzpvDSa4 vB6Q== X-Gm-Message-State: AOAM530ji8tMKNyD8vNvm8MRorDGvSljsB5epED+nNu/gPfAnWG72hhc TyDDdv6uKSKBz/T4QjQ+TNnG5v8GHHay8cFoPBE= X-Google-Smtp-Source: ABdhPJympWOSvfCz5C0Bh0T+ZGbmTwsB4TIChwXQNXDAd0cIBhtJwVxJLh3CgynI4lIIQS2Vw2jHrcfucD0IFOhz1vE= X-Received: by 2002:a2e:b704:: with SMTP id j4mr593539ljo.458.1593149225080; Thu, 25 Jun 2020 22:27:05 -0700 (PDT) MIME-Version: 1.0 References: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> <1593054160-12628-2-git-send-email-jrdr.linux@gmail.com> <59afe2fe-3718-85aa-f3b5-83ca0b9df577@nvidia.com> In-Reply-To: <59afe2fe-3718-85aa-f3b5-83ca0b9df577@nvidia.com> From: Souptick Joarder Date: Fri, 26 Jun 2020 10:56:53 +0530 Message-ID: Subject: Re: [PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: John Hubbard Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, linux-kernel@vger.kernel.org, Paul Durrant , xen-devel@lists.xenproject.org, Boris Ostrovsky Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 25, 2020 at 11:19 AM John Hubbard wrote: > > On 2020-06-24 20:02, Souptick Joarder wrote: > > In 2019, we introduced pin_user_pages*() and now we are converting > > get_user_pages*() to the new API as appropriate. [1] & [2] could > > be referred for more information. This is case 5 as per document [1]. > > > > [1] Documentation/core-api/pin_user_pages.rst > > > > [2] "Explicit pinning of user-space pages": > > https://lwn.net/Articles/807108/ > > > > Signed-off-by: Souptick Joarder > > Cc: John Hubbard > > Cc: Boris Ostrovsky > > Cc: Paul Durrant > > --- > > Hi, > > > > I'm compile tested this, but unable to run-time test, so any testing > > help is much appriciated. > > > > drivers/xen/privcmd.c | 10 ++-------- > > 1 file changed, 2 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > > index 0da417c..eb05254 100644 > > --- a/drivers/xen/privcmd.c > > +++ b/drivers/xen/privcmd.c > > @@ -595,7 +595,7 @@ static int lock_pages( > > if (requested > nr_pages) > > return -ENOSPC; > > > > - page_count = get_user_pages_fast( > > + page_count = pin_user_pages_fast( > > (unsigned long) kbufs[i].uptr, > > requested, FOLL_WRITE, pages); > > if (page_count < 0) { > > @@ -612,13 +612,7 @@ static int lock_pages( > > > > static void unlock_pages(struct page *pages[], unsigned int nr_pages) > > { > > - unsigned int i; > > - > > - for (i = 0; i < nr_pages; i++) { > > - if (!PageDirty(page)) > > - set_page_dirty_lock(page); > > - put_page(pages[i]); > > - } > > + unpin_user_pages_dirty_lock(pages, nr_pages, 1); > > "true", not "1", is the correct way to call that function. Ok. > > Also, this approach changes the behavior slightly, but I think it's > reasonable to just set_page_dirty_lock() on the whole range--hard to > see much benefit in checking PageDirty first. unpin_user_pages_dirty_lock() internally will do the same check after patch [2/2] So I thought to keep old and new code in sync. Shall we avoid this check ? > > > > } > > > > static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) > > > > thanks, > -- > John Hubbard > NVIDIA From xen-devel-bounces@lists.xenproject.org Fri Jun 26 05:36:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 05:36:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joh2N-00032M-8v; Fri, 26 Jun 2020 05:36:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joh2M-00032H-Gv for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 05:36:30 +0000 X-Inumbo-ID: fbfb0f96-b76e-11ea-b7bb-bc764e2007e4 Received: from mail-lj1-x243.google.com (unknown [2a00:1450:4864:20::243]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fbfb0f96-b76e-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 05:36:29 +0000 (UTC) Received: by mail-lj1-x243.google.com with SMTP id h22so1847813lji.9 for ; Thu, 25 Jun 2020 22:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V+l+muZt/sw8G/XSlHsPuBLXnNDdXq2H/AVjO/IHBoc=; b=K5UV7DHm9sm3s0sHYb6ba/xN6yhjka7U9GIVRvzcWhmYHefr1XG5DjTflYuMoeUMSq TUAn/RBtSxiX3HJvfVtUk9kCwiQmGcHx/xCyazjugjCJln4lJo5EjMf8spOFgpo0T5+N TRYQ6oLyMEmgzyYAjoUipGDHORX2lcIkK4ubblOYSITS0iDoK2UpHWGivXGOyqJQSgLs m/7M1p1kk233506tloZkznzt9JpH7aJ4qt/pW3GsFC699uzoZUruaZJJpnl04B+wQUcM V0UlqtGFtm0T2l2ovrVzXP8pqGkyWo7CGCtTYMnXKAMz4D0ityGEf68qvnJ7rktsoQbh FyZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V+l+muZt/sw8G/XSlHsPuBLXnNDdXq2H/AVjO/IHBoc=; b=j28oHz0Q0CSYVXI7sIWuU65+u7EJmb7vdipni6K9xb76U6Do3UE6Ee0nW47TAduwNF pVNxnoc9iO0Apj6d/6mHcFEEnjHO6uliG5kA23Cc6ea7b+ZmGwht/962LP9gGGHLi+KQ +1IW+LQ+UQ8rmfYbQ6704DzIRxo3pQQ0s7z3l2PPR4AKXTj1w5tCSGKe9UFhaZTMMbys q0V0DjypPN25XTgEU5ubLGBROlZyz60SZSiivclm+7N/PcW7jrzK6lSe0tAigyMgEDjy Isi9dx8pT7DIprZaMIpxIUnXOpdhqg0/IxqKDfWxLmGrSzC6Q6lcautxVo3FJWnTCVOf eG/Q== X-Gm-Message-State: AOAM530YjhXOFUp6sEJ4+crj8efKp7S77V4rbGDppIQTvEM7DzO1DeZE QvrhhcjrwMLIbNw4yA2TRdYRhk1NBu7PNBVIUuE= X-Google-Smtp-Source: ABdhPJzIUFNuOxJQ0Aijnx2p4E9Vz6x+8sGaNXNn5drRq5ZePW0EA4mQt/9xzTyw4YiwM8MaovWxJOaFTbifklgsRNA= X-Received: by 2002:a2e:7208:: with SMTP id n8mr516027ljc.315.1593149788481; Thu, 25 Jun 2020 22:36:28 -0700 (PDT) MIME-Version: 1.0 References: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> In-Reply-To: From: Souptick Joarder Date: Fri, 26 Jun 2020 11:06:17 +0530 Message-ID: Subject: Re: [PATCH 1/2] xen/privcmd: Corrected error handling path and mark pages dirty To: Boris Ostrovsky Content-Type: text/plain; charset="UTF-8" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, John Hubbard , linux-kernel@vger.kernel.org, Paul Durrant , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 5:01 AM Boris Ostrovsky wrote: > > On 6/24/20 11:02 PM, Souptick Joarder wrote: > > Previously, if lock_pages() end up partially mapping pages, it used > > to return -ERRNO due to which unlock_pages() have to go through > > each pages[i] till *nr_pages* to validate them. This can be avoided > > by passing correct number of partially mapped pages & -ERRNO separately, > > while returning from lock_pages() due to error. > > > > With this fix unlock_pages() doesn't need to validate pages[i] till > > *nr_pages* for error scenario and few condition checks can be ignored. > > > > As discussed, pages need to be marked as dirty before unpinned it in > > unlock_pages() which was oversight. > > > There are two unrelated changes here (improving error path and marking > pages dirty), they should be handled by separate patches. Sure, will do it in v2. > > > (I assume marking pages dirty is something you want to go to stable tree > since otherwise there is no reason for making this change) > > > > > > Signed-off-by: Souptick Joarder > > Cc: John Hubbard > > Cc: Boris Ostrovsky > > Cc: Paul Durrant > > --- > > Hi, > > > > I'm compile tested this, > > > I don't think so. I compile test it against ARM and it was fine. Against which ARCH is it failing ? > > > > but unable to run-time test, so any testing > > help is much appriciated. > > > > drivers/xen/privcmd.c | 34 +++++++++++++++++++--------------- > > 1 file changed, 19 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > > index a250d11..0da417c 100644 > > --- a/drivers/xen/privcmd.c > > +++ b/drivers/xen/privcmd.c > > @@ -580,43 +580,44 @@ static long privcmd_ioctl_mmap_batch( > > > > static int lock_pages( > > struct privcmd_dm_op_buf kbufs[], unsigned int num, > > - struct page *pages[], unsigned int nr_pages) > > + struct page *pages[], unsigned int nr_pages, int *pinned) > > { > > unsigned int i; > > + int errno = 0, page_count = 0; > > > No need for error, really --- you can return the value immediately. yes, this is unnecessary. > > > > > > for (i = 0; i < num; i++) { > > unsigned int requested; > > - int pinned; > > > > + *pinned += page_count; > > > I'd move this lower, after a successful call to get_user_pages_fast() > (and then you won't need to initialize it) Ok. > > > > requested = DIV_ROUND_UP( > > offset_in_page(kbufs[i].uptr) + kbufs[i].size, > > PAGE_SIZE); > > if (requested > nr_pages) > > return -ENOSPC; > > > > - pinned = get_user_pages_fast( > > + page_count = get_user_pages_fast( > > (unsigned long) kbufs[i].uptr, > > requested, FOLL_WRITE, pages); > > - if (pinned < 0) > > - return pinned; > > + if (page_count < 0) { > > + errno = page_count; > > + return errno; > > + } > > > > - nr_pages -= pinned; > > - pages += pinned; > > + nr_pages -= page_count; > > + pages += page_count; > > } > > > > - return 0; > > + return errno; > > } > > > > static void unlock_pages(struct page *pages[], unsigned int nr_pages) > > { > > unsigned int i; > > > > - if (!pages) > > - return; > > - > > for (i = 0; i < nr_pages; i++) { > > - if (pages[i]) > > - put_page(pages[i]); > > + if (!PageDirty(page)) > > + set_page_dirty_lock(page); > > + put_page(pages[i]); > > } > > > This won't compile. > > > -boris > > > From xen-devel-bounces@lists.xenproject.org Fri Jun 26 05:52:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 05:52:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1johHi-0004dX-FB; Fri, 26 Jun 2020 05:52:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1johHh-0004dR-8n for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 05:52:21 +0000 X-Inumbo-ID: 32af7cb4-b771-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 32af7cb4-b771-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 05:52:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 28A75AAC3; Fri, 26 Jun 2020 05:52:19 +0000 (UTC) Subject: Re: [PATCH 1/2] xen/privcmd: Corrected error handling path and mark pages dirty To: Souptick Joarder , boris.ostrovsky@oracle.com, sstabellini@kernel.org References: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <9ff52733-6ce0-6bda-8e49-a6908b4ff7dc@suse.com> Date: Fri, 26 Jun 2020 07:52:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, Paul Durrant , John Hubbard Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 25.06.20 05:02, Souptick Joarder wrote: > Previously, if lock_pages() end up partially mapping pages, it used > to return -ERRNO due to which unlock_pages() have to go through > each pages[i] till *nr_pages* to validate them. This can be avoided > by passing correct number of partially mapped pages & -ERRNO separately, > while returning from lock_pages() due to error. > > With this fix unlock_pages() doesn't need to validate pages[i] till > *nr_pages* for error scenario and few condition checks can be ignored. > > As discussed, pages need to be marked as dirty before unpinned it in > unlock_pages() which was oversight. > > Signed-off-by: Souptick Joarder > Cc: John Hubbard > Cc: Boris Ostrovsky > Cc: Paul Durrant > --- > Hi, > > I'm compile tested this, but unable to run-time test, so any testing > help is much appriciated. > > drivers/xen/privcmd.c | 34 +++++++++++++++++++--------------- > 1 file changed, 19 insertions(+), 15 deletions(-) > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > index a250d11..0da417c 100644 > --- a/drivers/xen/privcmd.c > +++ b/drivers/xen/privcmd.c > @@ -580,43 +580,44 @@ static long privcmd_ioctl_mmap_batch( > > static int lock_pages( > struct privcmd_dm_op_buf kbufs[], unsigned int num, > - struct page *pages[], unsigned int nr_pages) > + struct page *pages[], unsigned int nr_pages, int *pinned) unsigned int *pinned, please. > { > unsigned int i; > + int errno = 0, page_count = 0; Please drop the errno variable. It is misnamed (you never assign an errno value to it) and not needed, as you can ... > > for (i = 0; i < num; i++) { > unsigned int requested; > - int pinned; > > + *pinned += page_count; > requested = DIV_ROUND_UP( > offset_in_page(kbufs[i].uptr) + kbufs[i].size, > PAGE_SIZE); > if (requested > nr_pages) > return -ENOSPC; > > - pinned = get_user_pages_fast( > + page_count = get_user_pages_fast( > (unsigned long) kbufs[i].uptr, > requested, FOLL_WRITE, pages); > - if (pinned < 0) > - return pinned; > + if (page_count < 0) { > + errno = page_count; > + return errno; ... just return page_count her, and ... > + } > > - nr_pages -= pinned; > - pages += pinned; > + nr_pages -= page_count; > + pages += page_count; > } > > - return 0; > + return errno; ... leave this as it was. > } > > static void unlock_pages(struct page *pages[], unsigned int nr_pages) > { > unsigned int i; > > - if (!pages) > - return; > - > for (i = 0; i < nr_pages; i++) { > - if (pages[i]) > - put_page(pages[i]); > + if (!PageDirty(page)) > + set_page_dirty_lock(page); page? Not pages[i]? > + put_page(pages[i]); > } > } > > @@ -630,6 +631,7 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) > struct xen_dm_op_buf *xbufs = NULL; > unsigned int i; > long rc; > + int pinned = 0; > > if (copy_from_user(&kdata, udata, sizeof(kdata))) > return -EFAULT; > @@ -683,9 +685,11 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata) > goto out; > } > > - rc = lock_pages(kbufs, kdata.num, pages, nr_pages); > - if (rc) > + rc = lock_pages(kbufs, kdata.num, pages, nr_pages, &pinned); > + if (rc < 0) { > + nr_pages = pinned; > goto out; > + } > > for (i = 0; i < kdata.num; i++) { > set_xen_guest_handle(xbufs[i].h, kbufs[i].uptr); > Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 26 05:58:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 05:58:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1johNY-0004pO-3X; Fri, 26 Jun 2020 05:58:24 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1johNX-0004pJ-78 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 05:58:23 +0000 X-Inumbo-ID: 0a9e5370-b772-11ea-827b-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0a9e5370-b772-11ea-827b-12813bfff9fa; Fri, 26 Jun 2020 05:58:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GH8rXCk1vG3D4tRl0EKcBm0sKOvitAVTD8fKfOxA+jg=; b=CSSVlyEqcNSeoTqVt1p5R3JxM qMV0y2sjHjqGTww6yN0mKL0cNu7Bwuhu9JRm3rqzSRNcq4RWxxezkAG3VTtcjmXF6qfn05+UdXha3 174YeOcJ01dXYBFCWbjx8iFif7EYWfJf15sCz8jjBZ9f2hbKBM6X7KLY/vLKTRKb3/GTU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1johNV-0003tS-Ln; Fri, 26 Jun 2020 05:58:21 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1johNV-00039Y-7H; Fri, 26 Jun 2020 05:58:21 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1johNV-0002lf-6K; Fri, 26 Jun 2020 05:58:21 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151350: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=8be3a53e18e0e1a98f288f6c7f5e9da3adbe9c49 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Fri, 26 Jun 2020 05:58:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151350 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151350/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 8be3a53e18e0e1a98f288f6c7f5e9da3adbe9c49 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 8 days Failing since 151236 2020-06-19 19:10:35 Z 6 days 6 attempts Testing same since 151350 2020-06-25 02:15:25 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alex Deucher Alex Deucher Alexander Stein Alexey Budankov Andy Shevchenko Aneesh Kumar K.V Ard Biesheuvel Arnaldo Carvalho de Melo Arnd Bergmann Arvind Sankar Atish Patra Axel Lin Baolin Wang Barry Song Bartosz Golaszewski Charles Keepax Chen Zhou Chris Wilson Christian Brauner Christian Zigotzky Christoph Hellwig Christophe Leroy Chunyan Zhang Coly Li Cornelia Huck Dan Carpenter Dan Williams Daniel Schaefer Daniel Vetter Dave Airlie Dave Martin David Hildenbrand David Howells David Sterba Denis Efremov Dinghao Liu Dmitry Baryshkov Dmitry V. Levin Drew Fustini Eric Biggers Eugenio Pérez Felix Kuehling Filipe Manana Flavio Suligoi Gao Xiang Gaurav Singh Geert Uytterhoeven Guenter Roeck Gustavo A. R. Silva Haibo Chen Heiko Carstens Heinrich Schuchardt Herbert Xu Hongbo Yao Huacai Chen Ian Rogers Igor Mammedov Ilya Dryomov Imre Deak Ira Weiny Jack Wang Jan Kara Jason A. Donenfeld Jason Wang Jason Yan Jens Axboe Jens Thoms Toerring Jiri Olsa Jiri Olsa John Garry Joonas Lahtinen Julian Wiedmann Kai-Heng Feng Kaitao Cheng Kees Cook Kefeng Wang kernel test robot Keyur Patel Khaled Almahallawy Krzysztof Kozlowski Lee Jones Lingling Xu Linus Torvalds Linus Walleij Loic Poulain Lorenz Brun Luc Van Oostenryck Luis Chamberlain Manivannan Sadhasivam Marcelo Tosatti Mark Brown Mark Rutland Martin Fuzzey Martin K. Petersen Martin Schwidefsky Masahiro Yamada Masami Hiramatsu Masanari Iida Matti Vaittinen Mauricio Faria de Oliveira Michael Ellerman Michael S. Tsirkin Miguel Ojeda Mike Rapoport Milian Wolff Nathan Chancellor Nathan Huckleberry Navid Emamdoost Nicholas Piggin Nick Desaulniers Nirmoy Das Palmer Dabbelt Paolo Bonzini Patrice Chotard Paul Moore Pavel Begunkov Peter Zijlstra (Intel) Qian Cai Qing Zhang Qingqing Zhuo Randy Dunlap Robert Foss Robin Gong Rodrigo Siqueira Roman Gushchin Sami Tolvanen Sandeep Raghuraman Sean Christopherson Sedat Dilek Shuah Khan Shyam Thombre Sivaprakash Murugesan Stephan Mueller Stephan Müller Stephen Smalley Steven Rostedt (VMware) Sumanth Korikkar Sven Schnelle Tiezhu Yang Tom Lendacky Tom Rix Uma Shankar Vaibhav Jain Vamshi K Sthambamkadi Vandita Kulkarni Vasily Gorbik Vidya Sagar Vincenzo Frascino Vishal Verma Vitaly Kuznetsov Vladimir Oltean Waiman Long Wei Yang Weiping Zhang Will Deacon Wolfram Sang Wolfram Sang Xiaoguang Wang Xiaoyao Li YangHui Yash Shah Ye Bin Zheng Bin Zhenzhong Duan Zhiqiang Liu Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 7893 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 26 06:48:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 06:48:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joiA9-0000ZS-SR; Fri, 26 Jun 2020 06:48:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joiA9-0000ZN-1U for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 06:48:37 +0000 X-Inumbo-ID: 0ecb8844-b779-11ea-8496-bc764e2007e4 Received: from mail-lj1-x241.google.com (unknown [2a00:1450:4864:20::241]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0ecb8844-b779-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 06:48:36 +0000 (UTC) Received: by mail-lj1-x241.google.com with SMTP id n23so9166972ljh.7 for ; Thu, 25 Jun 2020 23:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tAiutF2JVV2jVzi4JN5lKA5pAFxBJvB1zS7W+zLCNGU=; b=Jz68M9cZSFRsa1lfuYI3fBa8wMImUyWpZmFLLZbO40bbGfouXOj3N6vDdnVrcVqqTX Lbi15a+HZlQXw04tJgZx7ZXkGgXgQERKqgR7Z/sv2m7ETVW9mami6HmOgwYPMhOdUecQ wvzjWm6VbFP3Jly0snbok9qhBxmvxgclwE3n0J0kwGzahrDuDGL9ZhVzLJyH8Znv3FDx lqoAb4K+DUnybEjiQ7y3HXXOpNX9vwZL5Ce+k22vvFszcQcxlNO+rRwx5WziQwbbXVhq my1X1ocgZrIQp7b2Leqc5DRVI+4Qf/008okO2tVZ1QGMj84x5Tj6SYrNxSBZ8/fqkyq0 thCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tAiutF2JVV2jVzi4JN5lKA5pAFxBJvB1zS7W+zLCNGU=; b=D00zSUekBKiyMsk2I58WysvJxsnifaB1SHTiQQ20u7Kv/xF4EEjTXQUi1sK8U/Boyb 67o0KuKmCLvAHmVsDmc08OBRmcefftQv/Ejcfcgt83H+9sgDUe42CiiM0vrv3uIwsKtW 9vZfS8AKjJFCAIqEg/81zaObDdc6wlRYlz15fzj3rKt/2/9rLhFPS9aFsmbsHX9a4Cd1 T5263ntZDm5psy5SNKUt/zqzlYe/kF3W+8Hhir8gF4dCH1xlDKmRG3Weq6lmvTDRT6d/ Fadwb+h6yLMd/mw0+u0JqhHl9kGReCMWCAUhMAoFUqAHFWoOBJawxqxiellrh+fgV55A 9btQ== X-Gm-Message-State: AOAM531uSnMnBIocf0A+yauIn1IrnHzsnTN55EMt2AJhOlfO7RAF+jlD gzqRp8XeESypzBQ4U8ObGtP2B9pKVIQwc1pnflk= X-Google-Smtp-Source: ABdhPJwywRiIDFcdW8SgEjZ9w6GKNMQWagCVc2TIKPv5IsPXc4jb6x5KjKPF+JpzzRyAUIZFamnEc6LM3RArfv1S/9I= X-Received: by 2002:a2e:5d8:: with SMTP id 207mr551883ljf.257.1593154114931; Thu, 25 Jun 2020 23:48:34 -0700 (PDT) MIME-Version: 1.0 References: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> <9ff52733-6ce0-6bda-8e49-a6908b4ff7dc@suse.com> In-Reply-To: <9ff52733-6ce0-6bda-8e49-a6908b4ff7dc@suse.com> From: Souptick Joarder Date: Fri, 26 Jun 2020 12:18:23 +0530 Message-ID: Subject: Re: [PATCH 1/2] xen/privcmd: Corrected error handling path and mark pages dirty To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: sstabellini@kernel.org, John Hubbard , linux-kernel@vger.kernel.org, Paul Durrant , xen-devel@lists.xenproject.org, Boris Ostrovsky Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 11:22 AM J=C3=BCrgen Gro=C3=9F wr= ote: > > On 25.06.20 05:02, Souptick Joarder wrote: > > Previously, if lock_pages() end up partially mapping pages, it used > > to return -ERRNO due to which unlock_pages() have to go through > > each pages[i] till *nr_pages* to validate them. This can be avoided > > by passing correct number of partially mapped pages & -ERRNO separately= , > > while returning from lock_pages() due to error. > > > > With this fix unlock_pages() doesn't need to validate pages[i] till > > *nr_pages* for error scenario and few condition checks can be ignored. > > > > As discussed, pages need to be marked as dirty before unpinned it in > > unlock_pages() which was oversight. > > > > Signed-off-by: Souptick Joarder > > Cc: John Hubbard > > Cc: Boris Ostrovsky > > Cc: Paul Durrant > > --- > > Hi, > > > > I'm compile tested this, but unable to run-time test, so any testing > > help is much appriciated. > > > > drivers/xen/privcmd.c | 34 +++++++++++++++++++--------------- > > 1 file changed, 19 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c > > index a250d11..0da417c 100644 > > --- a/drivers/xen/privcmd.c > > +++ b/drivers/xen/privcmd.c > > @@ -580,43 +580,44 @@ static long privcmd_ioctl_mmap_batch( > > > > static int lock_pages( > > struct privcmd_dm_op_buf kbufs[], unsigned int num, > > - struct page *pages[], unsigned int nr_pages) > > + struct page *pages[], unsigned int nr_pages, int *pinned) > > unsigned int *pinned, please. > > > { > > unsigned int i; > > + int errno =3D 0, page_count =3D 0; > > Please drop the errno variable. It is misnamed (you never assign an > errno value to it) and not needed, as you can ... > > > > > for (i =3D 0; i < num; i++) { > > unsigned int requested; > > - int pinned; > > > > + *pinned +=3D page_count; > > requested =3D DIV_ROUND_UP( > > offset_in_page(kbufs[i].uptr) + kbufs[i].size, > > PAGE_SIZE); > > if (requested > nr_pages) > > return -ENOSPC; > > > > - pinned =3D get_user_pages_fast( > > + page_count =3D get_user_pages_fast( > > (unsigned long) kbufs[i].uptr, > > requested, FOLL_WRITE, pages); > > - if (pinned < 0) > > - return pinned; > > + if (page_count < 0) { > > + errno =3D page_count; > > + return errno; > > ... just return page_count her, and ... > > > + } > > > > - nr_pages -=3D pinned; > > - pages +=3D pinned; > > + nr_pages -=3D page_count; > > + pages +=3D page_count; > > } > > > > - return 0; > > + return errno; > > ... leave this as it was. > > > } > > > > static void unlock_pages(struct page *pages[], unsigned int nr_pages) > > { > > unsigned int i; > > > > - if (!pages) > > - return; > > - > > for (i =3D 0; i < nr_pages; i++) { > > - if (pages[i]) > > - put_page(pages[i]); > > + if (!PageDirty(page)) > > + set_page_dirty_lock(page); > > page? Not pages[i]? I fixed it in compile branch, but missed it in patch creation work space at the time of posting. I think, this is the compile error Boris was pointing to. Sorry about it. I will fix it and post the v2. > > > + put_page(pages[i]); > > } > > } > > > > @@ -630,6 +631,7 @@ static long privcmd_ioctl_dm_op(struct file *file, = void __user *udata) > > struct xen_dm_op_buf *xbufs =3D NULL; > > unsigned int i; > > long rc; > > + int pinned =3D 0; > > > > if (copy_from_user(&kdata, udata, sizeof(kdata))) > > return -EFAULT; > > @@ -683,9 +685,11 @@ static long privcmd_ioctl_dm_op(struct file *file,= void __user *udata) > > goto out; > > } > > > > - rc =3D lock_pages(kbufs, kdata.num, pages, nr_pages); > > - if (rc) > > + rc =3D lock_pages(kbufs, kdata.num, pages, nr_pages, &pinned); > > + if (rc < 0) { > > + nr_pages =3D pinned; > > goto out; > > + } > > > > for (i =3D 0; i < kdata.num; i++) { > > set_xen_guest_handle(xbufs[i].h, kbufs[i].uptr); > > > > > Juergen From xen-devel-bounces@lists.xenproject.org Fri Jun 26 06:54:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 06:54:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joiFt-0001NZ-HN; Fri, 26 Jun 2020 06:54:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joiFr-0001NU-Qq for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 06:54:31 +0000 X-Inumbo-ID: e27a77d6-b779-11ea-8280-12813bfff9fa Received: from hqnvemgate24.nvidia.com (unknown [216.228.121.143]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e27a77d6-b779-11ea-8280-12813bfff9fa; Fri, 26 Jun 2020 06:54:31 +0000 (UTC) Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Thu, 25 Jun 2020 23:52:55 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Thu, 25 Jun 2020 23:54:29 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Thu, 25 Jun 2020 23:54:29 -0700 Received: from [10.2.63.78] (172.20.13.39) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 26 Jun 2020 06:54:29 +0000 Subject: Re: [PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*() To: Souptick Joarder References: <1593054160-12628-1-git-send-email-jrdr.linux@gmail.com> <1593054160-12628-2-git-send-email-jrdr.linux@gmail.com> <59afe2fe-3718-85aa-f3b5-83ca0b9df577@nvidia.com> From: John Hubbard Message-ID: Date: Thu, 25 Jun 2020 23:54:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [172.20.13.39] X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To HQMAIL107.nvidia.com (172.20.187.13) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1593154375; bh=Q41CWEP5r3Ufe0JNWhziz/qb4o51XvJxncTjiFALTd8=; h=X-PGP-Universal:Subject:To:CC:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:X-Originating-IP: X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=KztnXTTdUvCLh7PVjhgdEdJjQLzOZ+aiFMqOIGgtqGoF0ODBvP087ugRo3NmzGeBU spIKPTrXPydpzoSH1PEByxRFPLmch6g1j9Ts6UuzwLBNdRsplAxU00Upc7Fn73AN1A jAyupSo+0x5EY6DMJiyuNm2cl96pczadN10iObrRoix9yShwNmNk3XQt6Iv/81P+LG mk3cyuVI9pY9kgOqNBpI6MQ+1VJ6WXJc//TcPdFrEQzi1gNw4aT0k/nJFwrpuKvCVH 727IJiaCE++NmKS8Na8++JuQCfdG9BKYQb2yCQ5DMKW+xnzb9QSzraquFoe866bI1i xyboQkZZz52hA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , sstabellini@kernel.org, linux-kernel@vger.kernel.org, Paul Durrant , xen-devel@lists.xenproject.org, Boris Ostrovsky Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-25 22:26, Souptick Joarder wrote: > On Thu, Jun 25, 2020 at 11:19 AM John Hubbard wrote: >> On 2020-06-24 20:02, Souptick Joarder wrote: ... >>> @@ -612,13 +612,7 @@ static int lock_pages( >>> >>> static void unlock_pages(struct page *pages[], unsigned int nr_pages) >>> { >>> - unsigned int i; >>> - >>> - for (i = 0; i < nr_pages; i++) { >>> - if (!PageDirty(page)) >>> - set_page_dirty_lock(page); >>> - put_page(pages[i]); >>> - } >>> + unpin_user_pages_dirty_lock(pages, nr_pages, 1); >> >> "true", not "1", is the correct way to call that function. > > Ok. > >> >> Also, this approach changes the behavior slightly, but I think it's Correction, I forgot that I put that same if(!PageDirty(page)) check into unpin_user_pages_dirty_lock(). So it doesn't change behavior. That's good. >> reasonable to just set_page_dirty_lock() on the whole range--hard to >> see much benefit in checking PageDirty first. > > unpin_user_pages_dirty_lock() internally will do the same check after > patch [2/2] > So I thought to keep old and new code in sync. Shall we avoid this check ? > Just leave it as you have it, but of course use "true" instead of 1, please. thanks, -- John Hubbard NVIDIA From xen-devel-bounces@lists.xenproject.org Fri Jun 26 07:36:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 07:36:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joiu2-0004g0-Q9; Fri, 26 Jun 2020 07:36:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joiu2-0004fv-22 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 07:36:02 +0000 X-Inumbo-ID: aea68890-b77f-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id aea68890-b77f-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 07:36:01 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id t194so8397610wmt.4 for ; Fri, 26 Jun 2020 00:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=CETvD1BVCb9PYKbxPYDHyrBKH39clrmwIBRG5ovO63c=; b=N+dBt36exrfHqWQw+QtXkHpvkeYCwgTmzgXE16kXfgvci7hZ+I0hvX19V3m8RfDdCI 2Z2qIrDUE0+dP21lkqBevUjyY0XcWa21kkE6juuGKHYKKKbsWXnHoTP/eGIHu6njzdFd zmFe/HQzIzaxCyi2to/fcBwkMib19MghkfcOFoNNUvUQn1PtRZ6whPd43rHsRw2RqiA+ etJ/yCKO43zHhmTFb8XNcvw71qdhWwRgrIfPaBeU6hrRwOGgAJfVmoC9zob+iOW/FXL9 yNi4ShauLilM76BohGM7DFzDkfRIlmeDqYC/Tis85kvbmvgrFbJnnonxQm9l1bXcwtwI TUmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=CETvD1BVCb9PYKbxPYDHyrBKH39clrmwIBRG5ovO63c=; b=QgtQjnvR7ilociRyThXL4C1sPNkHAE20nMT8TYJosSyHqe9lpf7GhGjKDxyxyYc3Hn sG7HtOkR6WXPi3Kn9GpVhYavDYvLjl8f4iT2qWzz9TDYH7x5rYUaPAZx3rd/T/9GWDSF VmZB8W3coCXgGyuySZrJF0bMInlyIG3tvHYwv2ugXs1sAO41eURJADIFRiQBW2aNqqbf cXLnzg9lgR4VCCs8GKYIqXyZb78s/XpNsFPeq8wm0SlVlBvxJpT2QZio7Naa/6eOoQYs YoSTkVo4PAqi99i+2gU62xiEq0ocT7nyjZGBgbNuWSJbbS3VyenO2ulyemx26bs7e2/5 uZjg== X-Gm-Message-State: AOAM531yItNl9wQ2tgEaSBKKN5C3B7y6rTNPE9m88oXUmoJAqPNosdFU F/+yvKynT1BlkgCKk1qX09o= X-Google-Smtp-Source: ABdhPJzvrywodPf1EIrM7e6rsCey4b2r6rayff/RvVF0SWLE0p5lY5Dv9ETKfn+vh2Zfso/ZGgW/Bw== X-Received: by 2002:a1c:1d46:: with SMTP id d67mr2084783wmd.152.1593156960321; Fri, 26 Jun 2020 00:36:00 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id 92sm28852929wrr.96.2020.06.26.00.35.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 00:35:59 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Ian Jackson'" , "'Jason Andryuk'" References: <691aebb4-87af-60df-b6ad-07cb6fef4167@suse.com> <24308.50838.149966.847431@mariner.uk.xensource.com> <64c6a187-bf90-ae69-793b-0651bedd4f88@suse.com> <24308.53852.871947.61151@mariner.uk.xensource.com> In-Reply-To: <24308.53852.871947.61151@mariner.uk.xensource.com> Subject: RE: [PATCH] scripts: don't rely on "stat -" support Date: Fri, 26 Jun 2020 08:35:58 +0100 Message-ID: <000301d64b8c$6fd987c0$4f8c9740$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHcg0OOtNH1/o2UTx36U3QnAmwfsQFzhIFdAhU3WrgCrYBjdgHUyarnqJ257BA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Wei Liu' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Ian Jackson > Sent: 25 June 2020 17:36 > To: Jason Andryuk > Cc: Jan Beulich ; Paul Durrant ; xen-devel@lists.xenproject.org; Wei > Liu > Subject: Re: [PATCH] scripts: don't rely on "stat -" support > > Jason Andryuk writes ("Re: [PATCH] scripts: don't rely on "stat -" support"): > > On Thu, Jun 25, 2020 at 11:47 AM Jan Beulich wrote: > > > > > > On 25.06.2020 17:45, Ian Jackson wrote: > > > > Jan Beulich writes ("[PATCH] scripts: don't rely on "stat -" support"): > > > >> While commit b72682c602b8 ("scripts: Use stat to check lock claim") > > > >> validly indicates that stat has gained support for the special "-" > > > >> command line option in 2009, we should still try to avoid breaking being > > > >> able to run on even older distros. As it has been determined, contary to > > > >> the comment in the script using /dev/stdin (/proc/self/fd/$_lockfd) is > > > >> fine here, as Linux specially treats these /proc inodes. > > > >> > > > >> Suggested-by: Ian Jackson > > > >> Signed-off-by: Jan Beulich > > > > > > > > Thanks. > > > > > > > > The only code change here is this: > > > > > > > >> --- a/tools/hotplug/Linux/locking.sh > > > >> +++ b/tools/hotplug/Linux/locking.sh > > > >> @@ -45,18 +45,14 @@ claim_lock() > > > >> - if stat=$( stat -L -c '%D.%i' - $_lockfile 0<&$_lockfd 2>/dev/null ) > > > >> + if stat=$( stat -L -c '%D.%i' /dev/stdin $_lockfile 0<&$_lockfd 2>/dev/null ) > > > > > > > > Reviewed-by: Ian Jackson > > > > > > > > Has anyone executed this ? > > > > > > I have, of course, to confirm this fixes my issue. But I'm not sure > > > that's what you've meant to ask - you may have wanted assurance > > > that someone else has also tried it. > > > > Tested-by: Jason Andryuk > > Reviewed-by: Jason Andryuk > > :-). > In which case... Release-acked-by: Paul Durrant > Thanks, > Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 09:13:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 09:13:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jokPt-00055K-4N; Fri, 26 Jun 2020 09:13:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jokPs-00055A-EE for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 09:13:00 +0000 X-Inumbo-ID: 3ab934a6-b78d-11ea-8289-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3ab934a6-b78d-11ea-8289-12813bfff9fa; Fri, 26 Jun 2020 09:12:59 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: T38r9SNgToIC/w7aDuAM7EkY+pgK9okoEH0+lTSUJx07CqgWIROtb49rxOQRiXXPaeR6ZVZAGe StGKMh2imfI2uuyLlp3OGlC5nDgFxMKtx5pIVhpU3XlrJF0ZxKoJjUu+mxvKfsjopB5rUF3lff 2pwoaqIcMFJJG1jo2L4B6VpoibYfqee8fD8v+Oht/J1BEzkTqaoOvmUJaw5xhWN2jM7f74uyD+ Ln8OyB8paYUUr8zh+f8v799e4f5+l+Drl9NZqdD96XIitldvVaKU3Qv9lxaj1fFBR+HkW8UWif 1X8= X-SBRS: 2.7 X-MesageID: 21014931 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,283,1589256000"; d="scan'208";a="21014931" Date: Fri, 26 Jun 2020 11:12:39 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Anchal Agarwal Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Message-ID: <20200626091239.GA735@Air-de-Roger> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200617083528.GW735@Air-de-Roger> <20200619234312.GA24846@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200622083846.GF735@Air-de-Roger> <20200623004314.GA28586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200623081903.GP735@Air-de-Roger> <20200625183659.GA26586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200625183659.GA26586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 25, 2020 at 06:36:59PM +0000, Anchal Agarwal wrote: > On Tue, Jun 23, 2020 at 10:19:03AM +0200, Roger Pau Monné wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > On Tue, Jun 23, 2020 at 12:43:14AM +0000, Anchal Agarwal wrote: > > > On Mon, Jun 22, 2020 at 10:38:46AM +0200, Roger Pau Monné wrote: > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > > > > > On Fri, Jun 19, 2020 at 11:43:12PM +0000, Anchal Agarwal wrote: > > > > > On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monné wrote: > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > > > > > > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monné wrote: > > > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > > > > > > > + "the device may become inconsistent state"); > > > > > > > > > > > > > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > > > > > > > state and with the queues frozen. You should make an attempt to > > > > > > > > > restore things to a working state. > > > > > > > > > > > > > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > > > > > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > > > > > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > > > > > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > > > > > > > > > > > > > You can manually force this state, and then check that it will behave > > > > > > > > correctly. I would expect that on a failure to disconnect from the > > > > > > > > backend you should switch the frontend to the 'Init' state in order to > > > > > > > > try to reconnect to the backend when possible. > > > > > > > > > > > > > > > From what I understand forcing manually is, failing the freeze without > > > > > > > disconnect and try to revive the connection by unfreezing the > > > > > > > queues->reconnecting to backend [which never got diconnected]. May be even > > > > > > > tearing down things manually because I am not sure what state will frontend > > > > > > > see if backend fails to to disconnect at any point in time. I assumed connected. > > > > > > > Then again if its "CONNECTED" I may not need to tear down everything and start > > > > > > > from Initialising state because that may not work. > > > > > > > > > > > > > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > > > > > > > I don't see it getting handled in the backend then what will be backend's state? > > > > > > > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > > > > > > > if it tries to read backend's state through xenbus_read_driver_state ? > > > > > > > > > > > > > > So the flow be like: > > > > > > > Front end marks XenbusStateClosing > > > > > > > Backend marks its state as XenbusStateClosing > > > > > > > Frontend marks XenbusStateClosed > > > > > > > Backend disconnects calls xen_blkif_disconnect > > > > > > > Backend fails to disconnect, the above function returns EBUSY > > > > > > > What will be state of backend here? > > > > > > > > > > > > Backend should stay in state 'Closing' then, until it can finish > > > > > > tearing down. > > > > > > > > > > > It disconnects the ring after switching to connected state too. > > > > > > > Frontend did not tear down the rings if backend does not switches the > > > > > > > state to 'Closed' in case of failure. > > > > > > > > > > > > > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend > > > > > > > > > > > > Backend will stay in state 'Closing' I think. > > > > > > > > > > > > > won't be calling connect(). {From reading code in frontend_changed} > > > > > > > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > > > > > > > we did not tear down anything so calling talk_to_blkback may not be needed > > > > > > > > > > > > > > Does that sound correct? > > > > > > > > > > > > I think switching to the initial state in order to try to attempt a > > > > > > reconnection would be our best bet here. > > > > > > > > > > > It does not seems to work correctly, I get hung tasks all over and all the > > > > > requests to filesystem gets stuck. Backend does shows the state as connected > > > > > after xenbus_dev_suspend fails but I think there may be something missing. > > > > > I don't seem to get IO interrupts thereafter i.e hitting the function blkif_interrupts. > > > > > I think just marking it initialised may not be the only thing. > > > > > Here is a short description of what I am trying to do: > > > > > So, on timeout: > > > > > Switch XenBusState to "Initialized" > > > > > unquiesce/unfreeze the queues and return > > > > > mark info->connected = BLKIF_STATE_CONNECTED > > > > > > > > If xenbus state is Initialized isn't it wrong to set info->connected > > > > == CONNECTED? > > > > > > > Yes, you are right earlier I was marking it explicitly but that was not right, > > > the connect path for blkfront will do that. > > > > You should tear down all the internal state (like a proper close)? > > > > > > > Isn't that similar to disconnecting in the first place that failed during > > > freeze? Do you mean re-try to close but this time re-connect after close > > > basically do everything you would at "restore"? > > > > Last time I checked blkfront supported reconnections (ie: disconnect > > from a backend and connect again). I was assuming we could apply the > > same here on timeout, and just follow the same path where the frontend > > waits indefinitely for the backend to close and then attempts to > > reconnect. > > > > > Also, I experimented with that and it works intermittently. I want to take a > > > step back on this issue and ask few questions here: > > > 1. Is fixing this recovery a blocker for me sending in a V2 version? > > > > At the end of day it's your feature. I would certainly prefer for it > > to work as good as possible, this being a recovery in case of failure > > just make sure it does something sane (ie: crash/close the frontend) > > and add a TODO note. > > > > > 2. In our 2-3 years of supporting this feature at large scale we haven't seen this issue > > > where backend fails to disconnect. What we are trying to do here is create a > > > hypothetical situation where we leave backend in Closing state and try and see how it > > > recovers. The reason why I think it "may not" occur and the timeout of 5HZ is > > > sufficient is because we haven't come across even a single use-case where it > > > caused hibernation to fail. > > > The reason why I think "it may" occur is if we are running a really memory > > > intensive workload and ring is busy and is unable to complete all the requests > > > in the given timeout. This is very unlikely though. > > > > As said above I would generally prefer for code to handle possible > > failures the best way, and hence I think here it would be nice to > > fallback to the normal disconnect path and just wait for the backend > > to close. > > > Do you mind throwing some light in here, what that path may be, if its > straight forward to fix I would like to debug it a bit more. May be I am > missing some of the context here. So the frontend should do: - Switch to Closed state (and cleanup everything required). - Wait for backend to switch to Closed state (must be done asynchronously, handled in blkback_changed). - Switch frontend to XenbusStateInitialising, that will in turn force the backend to switch to XenbusStateInitWait. - After that it should just follow the normal connection procedure. I think the part that's missing is the frontend doing the state change to XenbusStateInitialising when the backend switches to the Closed state. > I was of the view we may just want to mark frontend closed which should do > the job of freeing resources and then following the same flow as > blkfront_restore. That does not seems to work correctly 100% of the time. I think the missing part is that you must wait for the backend to switch to the Closed state, or else the switch to XenbusStateInitialising won't be picked up correctly by the backend (because it's still doing it's cleanup). Using blkfront_restore might be an option, but you need to assert the backend is in the initial state before using that path. > > You likely have this very well tuned to your own environment and > > workloads, since this will now be upstream others might have more > > contended systems where it could start to fail. > > > I agree, however, this is also from the testing I did with 100 of runs > outside of EC2 running few tests of my own. > > > 3) Also, I do not think this may be straight forward to fix and expect > > > hibernation to work flawlessly in subsequent invocations. I am open to > > > all suggestions. > > > > Right, adding a TODO would seem appropriate then. > > > Just to double check, I will send in a V2 with this marked as TO-DO? I think that's fine. Please clearly describe what's missing, so others know what they might have to implement. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 09:38:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 09:38:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jokoN-0006r2-BH; Fri, 26 Jun 2020 09:38:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jokoM-0006qx-6z for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 09:38:18 +0000 X-Inumbo-ID: c3881574-b790-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c3881574-b790-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 09:38:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=DPK+LkiwuKek1QGGWTtwaOZJRuOtvbHMghsNq8TMJIE=; b=idhtSTKoCD4HMwVvmhJ0kQ8jgE Z/7b95zL3vNXgi0DtX2XcGipGdhn4BvleuQjO9BVKrhPS9JNpX33hIe6xCdPk7bVGD9Ksjemglw/K Tvy4CgpeXx92W0EpFO1XqLbC62BTx1Yb/wroLhc46BlHGLc0TPk2PAIyS5F5UDn6Jglg=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jokoH-000059-PS; Fri, 26 Jun 2020 09:38:13 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jokoH-0005H1-Hw; Fri, 26 Jun 2020 09:38:13 +0000 Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20200625113041.81507-1-roger.pau@citrix.com> From: Julien Grall Message-ID: <551387c6-f45d-bf6c-a41e-b0920425db9f@xen.org> Date: Fri, 26 Jun 2020 10:38:11 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200625113041.81507-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Roger, Sorry I didn't manage to answer to your question before you sent v3. On 25/06/2020 12:30, Roger Pau Monne wrote: > diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h > index ab1aae5c90..7ae0543885 100644 > --- a/xen/include/asm-arm/flushtlb.h > +++ b/xen/include/asm-arm/flushtlb.h > @@ -27,6 +27,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) > > /* Flush specified CPUs' TLBs */ > void flush_tlb_mask(const cpumask_t *mask); > +#define flush_tlb_mask_sync flush_tlb_mask Dropping the parameter 'sync' from filtered_flush_tlb_mask() is a nice improvement, but it unfortunately doesn't fully address my concern. After this patch there is exactly one use of flush_tlb_mask() in common code (see grant_table.c). But without looking at the x86 code, it is not clear why this requires a different flush compare to the two other sites. IOW, if I want to modify the common code in the future, how do I know which flush to call? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 26 10:08:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 10:08:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolHF-0000zr-Lw; Fri, 26 Jun 2020 10:08:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolHD-0000zm-UI for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 10:08:07 +0000 X-Inumbo-ID: eb0cff34-b794-11ea-8290-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id eb0cff34-b794-11ea-8290-12813bfff9fa; Fri, 26 Jun 2020 10:08:02 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ktY2q2Gx0g+BeTZoRkAIOFKciZwyBg37LkMpxKT+KwLR0Ct27kV1NX/IzoFVnjNeXu+Huyr6wF KP+QIj22db/tLsfs1jUUG1cZwFgenUdoQpudkjgq9+lv8uY7gldkdQCNB7RfHSVQ22YlLO7tqr AgpKCfJ08bY7fs+1+IL3Nj73brjsiW3/KHGl1v3P1uP0CrTN9oD0JSAnXQCVCPFjK3wMyGyndz +c4LqSsRlOM5IvY09WKBGSZuZXsZRPmjIBW7ZNub1eLQhxsth4Ey2MofxKzTKArdbdcziZK0RW K9I= X-SBRS: 2.7 X-MesageID: 21811658 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,283,1589256000"; d="scan'208";a="21811658" Date: Fri, 26 Jun 2020 12:07:45 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julien Grall Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage Message-ID: <20200626100745.GB735@Air-de-Roger> References: <20200625113041.81507-1-roger.pau@citrix.com> <551387c6-f45d-bf6c-a41e-b0920425db9f@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <551387c6-f45d-bf6c-a41e-b0920425db9f@xen.org> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 10:38:11AM +0100, Julien Grall wrote: > Hi Roger, > > Sorry I didn't manage to answer to your question before you sent v3. > > On 25/06/2020 12:30, Roger Pau Monne wrote: > > diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h > > index ab1aae5c90..7ae0543885 100644 > > --- a/xen/include/asm-arm/flushtlb.h > > +++ b/xen/include/asm-arm/flushtlb.h > > @@ -27,6 +27,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) > > /* Flush specified CPUs' TLBs */ > > void flush_tlb_mask(const cpumask_t *mask); > > +#define flush_tlb_mask_sync flush_tlb_mask > > Dropping the parameter 'sync' from filtered_flush_tlb_mask() is a nice > improvement, but it unfortunately doesn't fully address my concern. > > After this patch there is exactly one use of flush_tlb_mask() in common code > (see grant_table.c). But without looking at the x86 code, it is not clear > why this requires a different flush compare to the two other sites. It's not dealing with page allocation or page type changes directly, and hence doesn't need to use an IPI in order to prevent races with spurious_page_fault. > IOW, if I want to modify the common code in the future, how do I know which > flush to call? Unless you modify one of the specific areas mentioned above (page allocation or page type changes) you should use flush_tlb_mask. This is not ideal, and my aim will be to be able to use the assisted flush everywhere if possible, so I would really like to get rid of the interrupt disabling done in spurious_page_fault and this model where x86 relies on blocking interrupts in order to prevent page type changes or page freeing. Such change however doesn't feel appropriate for a release freeze period, and hence went with something smaller that restores the previous behavior. Another option is to just disable assisted flushes for the time being and re-enable them when a suitable solution is found. Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 10:18:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 10:18:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolQy-0001tP-Os; Fri, 26 Jun 2020 10:18:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolQx-0001tK-Qd for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 10:18:11 +0000 X-Inumbo-ID: 561945f2-b796-11ea-8496-bc764e2007e4 Received: from mail-wr1-f66.google.com (unknown [209.85.221.66]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 561945f2-b796-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 10:18:11 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id r12so8887920wrj.13 for ; Fri, 26 Jun 2020 03:18:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=of9h1NRjUJ18XWncnHmChowLD1aeWLqQRvW9jUzW09g=; b=iXC+fnnk7RGdRdxzFXNpEJS9YgWaBwkD3Nh0tqXzrOXNQEd0Kv4QoDAYEloYDmb2/e MmMYU0H8/56y+vOBLtdHyIgz2n1hwlp6B/jzcnFJ+PcMjLckL6FF99HpRRvOo+5JdKWN 5lwPV6xmZCLxFP4MB48i+N7uel0dRTMFD+Su+Ibm8b+x7dyyD6XRitQCFsAIQQ+/IvdO SfV31KvQGjDq3SaQCRpdwjhMTXAM9WxVDOr+ESOu3wIqP53dP65IKcs6E3vftcY/62bR wtoqtVG/fsGFgkvOiY3iqoN0w2fZ3S+ieZ9DynWk/qGOFH4dMa0ySFMdXhrU5nCsYNBX Taxg== X-Gm-Message-State: AOAM531lgvH7lTXq70e9/9gl8RdTGjomAi0bWIxsXbEgJlQ//nfRJJXX gW9zO1EAxLoMkCHGrwp11Ys= X-Google-Smtp-Source: ABdhPJwArNzAXXiebnwjAp8s2NlujCinOyfLLMjqtdNZpgi6q2WyNY2b3B5Juk8KaeS2peSffeLuCA== X-Received: by 2002:a05:6000:1107:: with SMTP id z7mr2850448wrw.355.1593166690104; Fri, 26 Jun 2020 03:18:10 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id p17sm16150338wma.47.2020.06.26.03.18.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 03:18:09 -0700 (PDT) Date: Fri, 26 Jun 2020 10:18:07 +0000 From: Wei Liu To: Jason Andryuk Subject: Re: [PATCH v2 00/10] Coverity fixes for vchan-socket-proxy Message-ID: <20200626101807.za6arkdlah7zsjzc@liuwe-devbox-debian-v2> References: <20200611032936.350657-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200611032936.350657-1-jandryuk@gmail.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Ian Jackson , marmarek@invisiblethingslab.com, Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 10, 2020 at 11:29:26PM -0400, Jason Andryuk wrote: > This series addresses some Coverity reports. To handle closing FDs, a > state struct is introduced to track FDs closed in both main() and > data_loop(). > > v2 changes "Ensure UNIX path NUL terminated" to avoid a warning with > gcc-10. Also, "Move perror() into listen_socket" and "Move perror() > into connect_socket" are new. > > Jason Andryuk (10): > vchan-socket-proxy: Ensure UNIX path NUL terminated > vchan-socket-proxy: Move perror() into listen_socket > vchan-socket-proxy: Move perror() into connect_socket > vchan-socket-proxy: Check xs_watch return value > vchan-socket-proxy: Unify main return value > vchan-socket-proxy: Use a struct to store state > vchan-socket-proxy: Switch data_loop() to take state > vchan-socket-proxy: Set closed FDs to -1 > vchan-socket-proxy: Cleanup resources on exit > vchan-socket-proxy: Handle closing shared input/output_fd Acked-by: Wei Liu Cc Paul. V1 of this series was posted back in May. I consider this series bug fixes, so they should be applied for 4.14. The risk is low because vchan-socket-proxy is a small utility used by a small number of users. Marek, you gave Review tags in v1. Do they still apply here? > > tools/libvchan/vchan-socket-proxy.c | 183 ++++++++++++++++++---------- > 1 file changed, 119 insertions(+), 64 deletions(-) > > -- > 2.25.1 > From xen-devel-bounces@lists.xenproject.org Fri Jun 26 10:27:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 10:27:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolZS-0002jO-Kq; Fri, 26 Jun 2020 10:26:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolZR-0002jJ-Qg for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 10:26:57 +0000 X-Inumbo-ID: 8fa984e8-b797-11ea-8293-12813bfff9fa Received: from mail-wr1-f67.google.com (unknown [209.85.221.67]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8fa984e8-b797-11ea-8293-12813bfff9fa; Fri, 26 Jun 2020 10:26:57 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id b6so8948564wrs.11 for ; Fri, 26 Jun 2020 03:26:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=i4yNifU9+jLLB/Li+CpkaCtqyDqd7tC6EGbwujm7ksM=; b=igFVbPBPhsW1YNRQgBvAeEnYWLv06lsvygD1qLxr3hRXIVHan7v3a0J+4GYMjKDVrF vy5F/JAMmXKbVkuF7VPKRrjiyLe3dmWIMZydR5ql3xUCN+8o/rEUMVNBxk74ZqxDYsC5 9+ixQ0fXa+nIDGjR35+d4VhKI4TDvJzpvLxZ0yNVL64/7vyjD31eUZjVIs4JGnJuLG/e 351mqFfkUt2Lm3AxUm+km37Cv5gWROcVnr9aWrZP7hLV4ImayWaMWm0V7DsqY9uSoV0g V1lWLQWTIDxcZTnVnZYhLotCiUvIQwj7YKT3KTLiP1WYhcV2UIewSKKpmR81SEVtDXBS WyKw== X-Gm-Message-State: AOAM531zNeWVW/ihT0ZzH7U/Cgj+CFTMyV+WauV2lIE578VrOsta9TJ+ NQHMfVcS8ROQ0HxbmhmdRcM= X-Google-Smtp-Source: ABdhPJwKfyOORHJJeiiFV6qUkepqzr5IfhGS6xzCP/zYdfmzMjBw44MK7Y/5z200PjK1/DS8rZyh3A== X-Received: by 2002:adf:e40e:: with SMTP id g14mr3170479wrm.271.1593167216353; Fri, 26 Jun 2020 03:26:56 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id 1sm16269782wmf.21.2020.06.26.03.26.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 03:26:55 -0700 (PDT) Date: Fri, 26 Jun 2020 10:26:54 +0000 From: Wei Liu To: paul@xen.org Subject: Re: [PATCH v1] kdd: remove zero-length arrays Message-ID: <20200626102654.e6ygxgnd37ptxosb@liuwe-devbox-debian-v2> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> <20200609152233.039cfc86.olaf@aepfle.de> <20200610191657.GA69414@deinos.phlegethon.org> <20200611211004.11e38f8f.olaf@aepfle.de> <005a01d64480$49ce0730$dd6a1590$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005a01d64480$49ce0730$dd6a1590$@xen.org> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Olaf Hering' , 'Wei Liu' , 'Tim Deegan' , 'Ian Jackson' , 'Christopher Clark' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 17, 2020 at 09:21:22AM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Christopher Clark > > Sent: 16 June 2020 21:50 > > To: Olaf Hering > > Cc: Tim Deegan ; xen-devel ; Ian Jackson > > ; Wei Liu ; paul@xen.org > > Subject: Re: [PATCH v1] kdd: remove zero-length arrays > > > > On Thu, Jun 11, 2020 at 12:12 PM Olaf Hering wrote: > > > > > > Am Wed, 10 Jun 2020 20:16:57 +0100 > > > schrieb Tim Deegan : > > > > > > > How tedious. > > > > > > Indeed. This compiles for me as well: > > > > just a nudge on this; it would be nice to get a patch into the tree > > since the build failure affects master builds of Xen in OpenEmbedded > > now. > > > > I'd be happy to take a patch into 4.14 if someone can provide one with a suitable maintainer ack. Tim is the maintainer of KDD. :-) I take it you're happy with me committing his patch then? Wei. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 10:31:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 10:31:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joleD-0003XM-7i; Fri, 26 Jun 2020 10:31:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joleB-0003XH-UJ for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 10:31:52 +0000 X-Inumbo-ID: 3f0449fa-b798-11ea-bb8b-bc764e2007e4 Received: from mail-wm1-x332.google.com (unknown [2a00:1450:4864:20::332]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3f0449fa-b798-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 10:31:51 +0000 (UTC) Received: by mail-wm1-x332.google.com with SMTP id a6so8588130wmm.0 for ; Fri, 26 Jun 2020 03:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=LJEpAjSLljoBnYDsCeysKW8fEHIzvuxKijSSjGWcaec=; b=kZ16ojR1Ej6/gKOPE86Kli4j4w1H7jPW7VPwrxwYtEB8o6y1x/gWKVpVWbSCXHYjf0 upGV63PGPj0rgfQxB03G6ONrbmMCeGpCYo7uCJXnLFXwm4ICK0pVtg3pPIIsuT/jWQ4Z aI6xJAnV7Rfxcg1pKKn3q2Cz+Uj4h7+Jqt+wXLSNwlLpfATXFWnM/e2ZioFogyDSQvtW y0bd+MZELaByWhOwuIjBbmUgPPkq81sn404bzA++2CEksrzUq04k04FBcy2mKeoEqzvt yGabtKzA7+ySouUpiNevT8weMOELGKFRH5b8X3sjGx+2hjfZCn9Bznf9nVgq+98jat4y 3jhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=LJEpAjSLljoBnYDsCeysKW8fEHIzvuxKijSSjGWcaec=; b=bSuXK44qw5nej5+y4+ejzTOBDAGjw9L86J3pb+gF+vfuKcsoBhqgycaogz5c2wu1ax JjZ6QsXFyDtGt/fUU9e/aG3zlwCX7PzcJlebwiR5Tm3+BU85ln33UbWUYfH+1nHuRtRM N0XyCyupoLg3oL0Zh2Tdl9cEZmc/3CQhDqt69Qdc68WQZ/SWtt5cRGbu6dzZ4v0znF6p Zy9iev3D/mn+cLYHtncB/idsyJdik3pCovQo/2BNN5rmWRPr/Ynlpc+Vtv3/nn2nxCZG Lt1yNqzx+5FqoZGni0zHA5tFcg7qG3px8uLgf2RAwXe0o4ffTGOi4OkYjjnj3Hw4DexO 8SMQ== X-Gm-Message-State: AOAM530ZyKKli9xVuzuV0g4ED4BUwWs18Ja/6NJqz6PmmJnIA7qfrscA MaoqDxGNuXtyXt50DZ0+wqg= X-Google-Smtp-Source: ABdhPJzAFTF6wm9hmshIdyRLcFETZJ8tTV61MZ/b1Z4BKAfRh09F87AaU2EfUy7mjDC8FvY7mqcuuQ== X-Received: by 2002:a1c:2049:: with SMTP id g70mr2821842wmg.90.1593167510493; Fri, 26 Jun 2020 03:31:50 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id r1sm27444171wrt.73.2020.06.26.03.31.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 03:31:49 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Wei Liu'" References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> <20200609152233.039cfc86.olaf@aepfle.de> <20200610191657.GA69414@deinos.phlegethon.org> <20200611211004.11e38f8f.olaf@aepfle.de> <005a01d64480$49ce0730$dd6a1590$@xen.org> <20200626102654.e6ygxgnd37ptxosb@liuwe-devbox-debian-v2> In-Reply-To: <20200626102654.e6ygxgnd37ptxosb@liuwe-devbox-debian-v2> Subject: RE: [PATCH v1] kdd: remove zero-length arrays Date: Fri, 26 Jun 2020 11:31:48 +0100 Message-ID: <000401d64ba5$00424b40$00c6e1c0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIqIZk/Qusa7Qsu5bkjM27jAUAPHgHVoA+LAfW9KPcCU2XTcQH8d5RuAcV3opsCrD1gbAGQYJk7ArIm6eOnvIq74A== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Ian Jackson' , 'xen-devel' , 'Olaf Hering' , 'Tim Deegan' , 'Christopher Clark' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Wei Liu > Sent: 26 June 2020 11:27 > To: paul@xen.org > Cc: 'Christopher Clark' ; 'Olaf Hering' ; 'Tim Deegan' > ; 'xen-devel' ; 'Ian Jackson' > ; 'Wei Liu' > Subject: Re: [PATCH v1] kdd: remove zero-length arrays > > On Wed, Jun 17, 2020 at 09:21:22AM +0100, Paul Durrant wrote: > > > -----Original Message----- > > > From: Christopher Clark > > > Sent: 16 June 2020 21:50 > > > To: Olaf Hering > > > Cc: Tim Deegan ; xen-devel ; Ian Jackson > > > ; Wei Liu ; paul@xen.org > > > Subject: Re: [PATCH v1] kdd: remove zero-length arrays > > > > > > On Thu, Jun 11, 2020 at 12:12 PM Olaf Hering wrote: > > > > > > > > Am Wed, 10 Jun 2020 20:16:57 +0100 > > > > schrieb Tim Deegan : > > > > > > > > > How tedious. > > > > > > > > Indeed. This compiles for me as well: > > > > > > just a nudge on this; it would be nice to get a patch into the tree > > > since the build failure affects master builds of Xen in OpenEmbedded > > > now. > > > > > > > I'd be happy to take a patch into 4.14 if someone can provide one with a suitable maintainer ack. > > Tim is the maintainer of KDD. :-) > > I take it you're happy with me committing his patch then? > I'm happy, but ought it not have an ack from 'the rest' since Tim submitted the patch? Release-acked-by: Paul Durrant > Wei. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 10:33:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 10:33:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolfd-0003dP-IV; Fri, 26 Jun 2020 10:33:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolfb-0003dI-NH for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 10:33:19 +0000 X-Inumbo-ID: 735b2be2-b798-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-f68.google.com (unknown [209.85.128.68]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 735b2be2-b798-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 10:33:19 +0000 (UTC) Received: by mail-wm1-f68.google.com with SMTP id f18so8897124wml.3 for ; Fri, 26 Jun 2020 03:33:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PITXihdp2Xt6NNW2tpgV1RVRNn4jiXT1dHTY0wmfecY=; b=eOJn4D9gnZjWnVq4ORVy5NU1lcCFOVbx9vSJLi0ukYlFwO9T3uA2L6KW7Rpsok9axh /Tf8TGYvvBcfRksgF/89+iddOSUdMGSan/uorsREnTWf2EougtZvM1KqcSlqPntHrlyW 8z2LmANW2aCD4g3wlvhZhakOAG5qhSd8cjL8F4yAuVqYAvPULdF9f/aS0Fgyb/bTKtkC Cz9DkBfMyrP6TShw/WC9oDf2UCKUfZZQ1GCCXozyRoVlvvH6B8svpsuA6GyCiq1VH3F5 QBx+CQUc4MXkgYz95aF95cg5L+U+cNki/Igm4XLkwqNbSqM0npP565kP5KvoRVC3ZA3E T6SQ== X-Gm-Message-State: AOAM533rx8nT23aEPhxWp5dodClFYCKRdw8ns+woCMBlr/XBAHGgcS3f 4zKxS2ftaggTaE8DBk89jpc= X-Google-Smtp-Source: ABdhPJyxenN8GGMWfsJSbxo1xAJlSo/qj3C5T+o9NaXfHcLt5RXJWYmvTCG7fs9tmOQfLThdKxhR5w== X-Received: by 2002:a1c:acc3:: with SMTP id v186mr2793556wme.79.1593167598355; Fri, 26 Jun 2020 03:33:18 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id p13sm25868337wrn.0.2020.06.26.03.33.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 03:33:17 -0700 (PDT) Date: Fri, 26 Jun 2020 10:33:16 +0000 From: Wei Liu To: paul@xen.org Subject: Re: [PATCH v1] kdd: remove zero-length arrays Message-ID: <20200626103316.gznsycu4cuqxwvdw@liuwe-devbox-debian-v2> References: <20200608203849.18341-1-olaf@aepfle.de> <005001d63e3b$c85059f0$58f10dd0$@xen.org> <20200609121549.GA90841@deinos.phlegethon.org> <20200609152233.039cfc86.olaf@aepfle.de> <20200610191657.GA69414@deinos.phlegethon.org> <20200611211004.11e38f8f.olaf@aepfle.de> <005a01d64480$49ce0730$dd6a1590$@xen.org> <20200626102654.e6ygxgnd37ptxosb@liuwe-devbox-debian-v2> <000401d64ba5$00424b40$00c6e1c0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401d64ba5$00424b40$00c6e1c0$@xen.org> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Olaf Hering' , 'Wei Liu' , 'Tim Deegan' , 'Ian Jackson' , 'Christopher Clark' , 'xen-devel' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 11:31:48AM +0100, Paul Durrant wrote: > > -----Original Message----- > > From: Wei Liu > > Sent: 26 June 2020 11:27 > > To: paul@xen.org > > Cc: 'Christopher Clark' ; 'Olaf Hering' ; 'Tim Deegan' > > ; 'xen-devel' ; 'Ian Jackson' > > ; 'Wei Liu' > > Subject: Re: [PATCH v1] kdd: remove zero-length arrays > > > > On Wed, Jun 17, 2020 at 09:21:22AM +0100, Paul Durrant wrote: > > > > -----Original Message----- > > > > From: Christopher Clark > > > > Sent: 16 June 2020 21:50 > > > > To: Olaf Hering > > > > Cc: Tim Deegan ; xen-devel ; Ian Jackson > > > > ; Wei Liu ; paul@xen.org > > > > Subject: Re: [PATCH v1] kdd: remove zero-length arrays > > > > > > > > On Thu, Jun 11, 2020 at 12:12 PM Olaf Hering wrote: > > > > > > > > > > Am Wed, 10 Jun 2020 20:16:57 +0100 > > > > > schrieb Tim Deegan : > > > > > > > > > > > How tedious. > > > > > > > > > > Indeed. This compiles for me as well: > > > > > > > > just a nudge on this; it would be nice to get a patch into the tree > > > > since the build failure affects master builds of Xen in OpenEmbedded > > > > now. > > > > > > > > > > I'd be happy to take a patch into 4.14 if someone can provide one with a suitable maintainer ack. > > > > Tim is the maintainer of KDD. :-) > > > > I take it you're happy with me committing his patch then? > > > > I'm happy, but ought it not have an ack from 'the rest' since Tim submitted the patch? Alright. FWIW: Acked-by: Wei Liu > > Release-acked-by: Paul Durrant Thanks. Wei. > > > Wei. > From xen-devel-bounces@lists.xenproject.org Fri Jun 26 10:41:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 10:41:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolnH-0004Ug-De; Fri, 26 Jun 2020 10:41:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolnG-0004Ub-Fv for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 10:41:14 +0000 X-Inumbo-ID: 8e4c8a08-b799-11ea-8496-bc764e2007e4 Received: from mail-wr1-x431.google.com (unknown [2a00:1450:4864:20::431]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8e4c8a08-b799-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 10:41:13 +0000 (UTC) Received: by mail-wr1-x431.google.com with SMTP id g18so9052472wrm.2 for ; Fri, 26 Jun 2020 03:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=hrZx328xFMdqRk3GEzuNDkIS4cmTBPvBlwK6wnYbx/Q=; b=s0XsWscjF6IL2OxcvbGnbl2/251Nm2z0aL+0V1SW3ULwaaG9CXWJvOT+xHfdMEV/hw gDOoxyR1hdntTGjzS/OQfeSAwmlGiiblu1jyD9bC6RFrdqR0cXwN93XEUVbnxi8U5Cw/ rz3HP2zP7oWop19eEVSXG+w5eGiNVaSl2I8EWExcOtf7fMEskXSFUHZJy8tCWBP6Vhxd WtBxV+NYMduZ1U4PBI2BxhvsAgk1nrjvcG8Ldt1FkBBT3y27jfP27KqAoRug36YDTAYm o4HF0+J12YSHBnLutEXdMHx6idI4mdwLYqZ88DP4QhjfsUmF5aOGAnKmF63/hmKwNDhn BRCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=hrZx328xFMdqRk3GEzuNDkIS4cmTBPvBlwK6wnYbx/Q=; b=IuWXGP5voM75ZSghwqZMuu7x9wOIL226Ia01Ivhp8DIXDRSNUGah8wtuk2Y7poTYpo RpZH4vCZ2z2FIdbnw2TszdiIGdVg86oGKTkC13WLCdxmrxkt0n+TJad/4W1Atlcde5Ej W/4MRFGNg6SINCLxryl1cL7qrUml/C3VDkZkhN5+OYyQlgEWp0LZhb+kzSuVttIL7pm4 M5q/nc+J09XxMJ1M8DS09AELS8NtqB9GYdT34AEWDLFucjK6k9oMnxHCMQQu84D7CJ/n lEXXJMSObsdCMIzRu8KFwW7f/Wfl9/vlm6/4q20YaEHHSusmW4plDrd46V0tq0chK0GL 43Kg== X-Gm-Message-State: AOAM532QL4rxqmcw9OGUGUNsVAlBOBnP+xmytb2/bCi4ECLbYyXpyVXJ XJioyFT9h6F1UomDalxoWj0= X-Google-Smtp-Source: ABdhPJxLwspoXfM05fKDAJjGrgJk/lNl9mFqyUZOSnEVwg+LnZWVlVCcVy4z8vIdWiWqu4JkQ+R5aw== X-Received: by 2002:adf:c404:: with SMTP id v4mr2911572wrf.85.1593168073051; Fri, 26 Jun 2020 03:41:13 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id a22sm17026455wmj.9.2020.06.26.03.41.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 03:41:12 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Wei Liu'" , "'Jason Andryuk'" References: <20200611032936.350657-1-jandryuk@gmail.com> <20200626101807.za6arkdlah7zsjzc@liuwe-devbox-debian-v2> In-Reply-To: <20200626101807.za6arkdlah7zsjzc@liuwe-devbox-debian-v2> Subject: RE: [PATCH v2 00/10] Coverity fixes for vchan-socket-proxy Date: Fri, 26 Jun 2020 11:41:11 +0100 Message-ID: <000501d64ba6$4f8d8f60$eea8ae20$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQLDGQiei5IbGzqMSAjg0ij1F+BV+gLqYT69pvnHS1A= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, 'Ian Jackson' , marmarek@invisiblethingslab.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Wei Liu > Sent: 26 June 2020 11:18 > To: Jason Andryuk > Cc: xen-devel@lists.xenproject.org; Ian Jackson ; Wei Liu ; > Paul Durrant ; marmarek@invisiblethingslab.com > Subject: Re: [PATCH v2 00/10] Coverity fixes for vchan-socket-proxy > > On Wed, Jun 10, 2020 at 11:29:26PM -0400, Jason Andryuk wrote: > > This series addresses some Coverity reports. To handle closing FDs, a > > state struct is introduced to track FDs closed in both main() and > > data_loop(). > > > > v2 changes "Ensure UNIX path NUL terminated" to avoid a warning with > > gcc-10. Also, "Move perror() into listen_socket" and "Move perror() > > into connect_socket" are new. > > > > Jason Andryuk (10): > > vchan-socket-proxy: Ensure UNIX path NUL terminated > > vchan-socket-proxy: Move perror() into listen_socket > > vchan-socket-proxy: Move perror() into connect_socket > > vchan-socket-proxy: Check xs_watch return value > > vchan-socket-proxy: Unify main return value > > vchan-socket-proxy: Use a struct to store state > > vchan-socket-proxy: Switch data_loop() to take state > > vchan-socket-proxy: Set closed FDs to -1 > > vchan-socket-proxy: Cleanup resources on exit > > vchan-socket-proxy: Handle closing shared input/output_fd > > Acked-by: Wei Liu > > Cc Paul. V1 of this series was posted back in May. I consider this > series bug fixes, so they should be applied for 4.14. The risk is low > because vchan-socket-proxy is a small utility used by a small number of > users. > Agreed. Series... Release-acked-by: Paul Durrant > Marek, you gave Review tags in v1. Do they still apply here? > > > > > tools/libvchan/vchan-socket-proxy.c | 183 ++++++++++++++++++---------- > > 1 file changed, 119 insertions(+), 64 deletions(-) > > > > -- > > 2.25.1 > > From xen-devel-bounces@lists.xenproject.org Fri Jun 26 10:44:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 10:44:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolqZ-0004eK-1r; Fri, 26 Jun 2020 10:44:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jolqX-0004eE-Ic for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 10:44:37 +0000 X-Inumbo-ID: 077726f4-b79a-11ea-8496-bc764e2007e4 Received: from mail-wr1-f65.google.com (unknown [209.85.221.65]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 077726f4-b79a-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 10:44:37 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id h5so9017500wrc.7 for ; Fri, 26 Jun 2020 03:44:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0tX4dZH8P8w6nTw31UlgtFloieHoONE4phc8XP5+2FI=; b=ksE9J+qLw4Twp89ck2K6vdhnOX7JxRtIUeGJl49vh4r8ymQXroC+J+kTzS/d9Bl6ge a4bM+Sc3RHkJdZUPN8ZoqK6ljTn7V2mx3u7P9M+U9uM/LvXlN+wEJRk/PS0Af6MCyErj jZFWqvl4hMeCpED1UHk7r9pzIJCZkc6yVM/B/3PFTFmY0Xu8ve85j7LMgAAuicxwxoTD cft5GGBzBE/f2Tf+ayoY/k/JwqSKYW/AdyOFpvfkmBGI1k0z11+o5/RoopmIyRhOfnxw 0KMHIX/DuaBrOsbKk9PEsaKh2+1ZxoUAh4W03vKlPK9XRPWg2FvjjHfqsijmVJZzRt0p 0cJA== X-Gm-Message-State: AOAM532Su/B4W5YOd1CCdmuR1HoRdAhrwJ8YjMxonpZsZiAHoJaSoCRS G7093vmQcLzerfgMKAkx2FE= X-Google-Smtp-Source: ABdhPJy6wwCKObrqB99PkW8bKZqK4xO3CDcOxQhCt6zMulfjrUmptrlZcA7thEoNoExnRRHe1lddlA== X-Received: by 2002:a5d:6a46:: with SMTP id t6mr3138942wrw.374.1593168276368; Fri, 26 Jun 2020 03:44:36 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id b62sm6365307wmh.38.2020.06.26.03.44.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 03:44:35 -0700 (PDT) Date: Fri, 26 Jun 2020 10:44:34 +0000 From: Wei Liu To: Roger Pau Monne Subject: Re: [PATCH for-4.14 v2 2/2] x86/passthrough: introduce a flag for GSIs not requiring an EOI or unmask Message-ID: <20200626104434.yd6lplwcwpclli2n@liuwe-devbox-debian-v2> References: <20200610142923.9074-1-roger.pau@citrix.com> <20200610142923.9074-3-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200610142923.9074-3-roger.pau@citrix.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Wei Liu , Jan Beulich , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 10, 2020 at 04:29:23PM +0200, Roger Pau Monne wrote: > There's no need to setup a timer for GSIs that are edge triggered, > since those don't require any EIO or unmask, and hence couldn't block One small nit. I think you meant "EOI" here. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:08:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:08:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomDR-0006P5-W6; Fri, 26 Jun 2020 11:08:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomDQ-0006P0-35 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:08:16 +0000 X-Inumbo-ID: 54d2034e-b79d-11ea-8496-bc764e2007e4 Received: from mail-wr1-f65.google.com (unknown [209.85.221.65]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 54d2034e-b79d-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 11:08:15 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id s10so9055888wrw.12 for ; Fri, 26 Jun 2020 04:08:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=c9WaCIqQZhKW2/Inw15yclaIY5xNEd79NUySjO/b4CA=; b=FdIs4UlDH2QpZc74pXA3H1JPy7KpavDu+bkIs1CKjPLJMXccGuKq8pEAA4OUYiI3YR /Dv9pIXmENJiKTs9HM/AnvEC6HxQkIiLKlUBgBvt5H/4xeufu3fQib6juaCHimUD+/Y1 PwxEPcl+0OfQYWftBjpOYCFC0C2uZEp0B8jZ5YhwnTtQJ8iWk5LfHQSQZMdtffKlsyLE alMcDZaXVhk7QLO3PRgRysKY2TgXlovzyhfJ6M9lZPXzoMSoDdHNZqaAjlwNdi6jeBrT cJXddmcubVdjlR7n8QJe0gc1TmYzc6kVDAXICxFXCbV8FTmAHSJNYQoD0UNTAVVEnMd9 JaBw== X-Gm-Message-State: AOAM530WRphPRaRAuq1vuV1DMt0ypwQJnmCQehtf/PsX+7o3PjO24UXU IWwM0vzHUKyKlwc1jW/Pj+A= X-Google-Smtp-Source: ABdhPJwAvP6F5WCx5gH/bFwla90A95Nm/gGCusSuy0VtDnFqqcUfMkIn2iajc5bLukaCsPaR+8KUEQ== X-Received: by 2002:adf:f889:: with SMTP id u9mr3448372wrp.149.1593169694533; Fri, 26 Jun 2020 04:08:14 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id 65sm17456407wma.48.2020.06.26.04.08.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 04:08:13 -0700 (PDT) Date: Fri, 26 Jun 2020 11:08:12 +0000 From: Wei Liu To: Julien Grall Subject: Re: Kexec and libxenctlr.so Message-ID: <20200626110812.hxeoomagamkdceu7@liuwe-devbox-debian-v2> References: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7a88218d-981e-6583-15a5-3fcaffb05294@amazon.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "wl@xen.org" , "paul@xen.org" , "andrew.cooper3@citrix.com" , daniel.kiper@oracle.com, "ian.jackson@eu.citrix.com" , Anthony Perard , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 11, 2020 at 03:57:37PM +0100, Julien Grall wrote: > Hi all, > > kexec-tools has an option to load dynamically libxenctlr.so (not .so.4.x) > (see [1]). > > Given that the library has never been considered stable, it is probably a > disaster that is waiting to happen. > > Looking at the tree kexec is using the follow libxc functions: > - xc_kexec_get_range() > - xc_kexec_load() > - xc_kexec_unload() > - xc_kexec_status() > - xc_kexec_exec() > - xc_version() > - xc_interface_open() > - xc_interface_close() > - xc_get_max_cpus() > - xc_get_machine_memory_map() > > I think it is uncontroversial that we want a new stable library for all the > xc_kexec_* functions (maybe libxenexec)? That sounds fine to me. Looking at the list of functions, all the xc_kexec_* ones are probably already rather stable. For xc_interface_open / close, they are perhaps used only to obtain an xc handle such that it can be used to make hypercalls. You new kexec library is going to expose its own handle with a xencall handle wrapped inside, so you can do away with an xc handle. > > However I am not entirely sure where to put the others. > > I am thinking to introduce libxensysctl for xc_get_max_cpus() as it is a > XEN_SYSCTL. We could possibly include xc_get_machine_memory_map() (despite > it is a XENMEM_). > Introducing an libxensysctl before we stabilise sysctl interface seems wrong to me. We can bury the call inside libxenkexec itself for the time being. > For xc_version(), I am thinking to extend libxentoolcore to also include > "stable xen API". > If you can do without an xc handle, do you still need to call xc_version? Wei. > Any opinion on the approach? > > Cheers, > > > [1] https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=894bea9335f57b62cbded7b02ab7d58308b647d8 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:12:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:12:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomHB-0007Ak-GV; Fri, 26 Jun 2020 11:12:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomHA-0007Ae-2Y for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:12:08 +0000 X-Inumbo-ID: df72e8a6-b79d-11ea-b7bb-bc764e2007e4 Received: from out5-smtp.messagingengine.com (unknown [66.111.4.29]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id df72e8a6-b79d-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 11:12:07 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 645205C00AC; Fri, 26 Jun 2020 07:12:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Fri, 26 Jun 2020 07:12:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=o93Cjd 24FOiNLrFwfmBe4LZpL/SrHS+PzUttJQ7s0Lw=; b=GpkJ16hNdCcRf50jEbczC1 PU3RTWEMXSzJk3CGloipMve1OwNWvGEHeOOG0Cc8cNhbn4pY8t2Of6KBt51PQnCW Q9ANI4B/TdNCH9XmPbApLG78yNKlyYXJjJvBEI/6GIQucNCL0bbeLE1n+FF7S3nD jt/6KSwHBWPLxuuqkFmKVB58q1FSGehJ1CSA92ZwbArph87DNfgwa/esRCF0zwYP BhKqefg/ahedGOgRRRGgZCNhz6K5CKnl2xGPHbcfs+wBfLwZr0uRExo112EbVvO0 wh4Kr/FoGg3guUh6XMUDDlg9KOD2rsK7I8MDRZzLwdoWNYONUT5Ml0kBizIHezLw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeluddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehgtderredttdejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihdqifpkrhgvtghkihcuoehmrghrmhgrrhgvkhesihhnvh hishhisghlvghthhhinhhgshhlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpeetveff iefghfekhffggeeffffhgeevieektedthfehveeiheeiiedtudegfeetffenucfkpheple durdeihedrfeegrdeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthhhinhhgshhlrggsrd gtohhm X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 65CB33067902; Fri, 26 Jun 2020 07:12:06 -0400 (EDT) Date: Fri, 26 Jun 2020 13:12:01 +0200 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= To: Wei Liu Subject: Re: [PATCH v2 00/10] Coverity fixes for vchan-socket-proxy Message-ID: <20200626111201.GS1197@mail-itl> References: <20200611032936.350657-1-jandryuk@gmail.com> <20200626101807.za6arkdlah7zsjzc@liuwe-devbox-debian-v2> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Zs/RYxT/hKAHzkfQ" Content-Disposition: inline In-Reply-To: <20200626101807.za6arkdlah7zsjzc@liuwe-devbox-debian-v2> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Paul Durrant , Ian Jackson , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --Zs/RYxT/hKAHzkfQ Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v2 00/10] Coverity fixes for vchan-socket-proxy On Fri, Jun 26, 2020 at 10:18:07AM +0000, Wei Liu wrote: > On Wed, Jun 10, 2020 at 11:29:26PM -0400, Jason Andryuk wrote: > > This series addresses some Coverity reports. To handle closing FDs, a > > state struct is introduced to track FDs closed in both main() and > > data_loop(). > >=20 > > v2 changes "Ensure UNIX path NUL terminated" to avoid a warning with > > gcc-10. Also, "Move perror() into listen_socket" and "Move perror() > > into connect_socket" are new. > >=20 > > Jason Andryuk (10): > > vchan-socket-proxy: Ensure UNIX path NUL terminated > > vchan-socket-proxy: Move perror() into listen_socket > > vchan-socket-proxy: Move perror() into connect_socket > > vchan-socket-proxy: Check xs_watch return value > > vchan-socket-proxy: Unify main return value > > vchan-socket-proxy: Use a struct to store state > > vchan-socket-proxy: Switch data_loop() to take state > > vchan-socket-proxy: Set closed FDs to -1 > > vchan-socket-proxy: Cleanup resources on exit > > vchan-socket-proxy: Handle closing shared input/output_fd >=20 > Acked-by: Wei Liu >=20 > Cc Paul. V1 of this series was posted back in May. I consider this > series bug fixes, so they should be applied for 4.14. The risk is low > because vchan-socket-proxy is a small utility used by a small number of > users. >=20 > Marek, you gave Review tags in v1. Do they still apply here? Yes. And also for the new patches 2-3. I thought I've posted it here, but must have missed clicking "send"... > >=20 > > tools/libvchan/vchan-socket-proxy.c | 183 ++++++++++++++++++---------- > > 1 file changed, 119 insertions(+), 64 deletions(-) > >=20 > > --=20 > > 2.25.1 > >=20 --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --Zs/RYxT/hKAHzkfQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl712AAACgkQ24/THMrX 1yyhigf+NrwGQmd536KPduBKmiC1fSlzBl2dSFnPRaaN6lHsszY4+OC+lcqyoJpo +A9q+YLfY0vZg3VFusksP24bkW0xp/Fn7yOyvTGOnGiYWFZHZa6b5K3NKGaL+7hv dqCChkzzpLSeX+LvBg4vypAiYuILGotqDFyQThuv4/mMrHU2HQfFAwthzlC6bOVR 8fF2tDH3Y/dhjTWTmM2wCLWs9Jin4luwwnEiFvEtowWLNIbjc6x5I0H0MajI7uN0 hDn2wVkIrMDJGDVLww+JS95RjSwPyPfEIQ52VuTQnrDa+25+fIYdDgoqrOVd0X0j 4+X+rrhOPFCNnDnpDiCXmSyKPGuMXA== =k63E -----END PGP SIGNATURE----- --Zs/RYxT/hKAHzkfQ-- From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:22:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:22:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomQz-00084A-Gs; Fri, 26 Jun 2020 11:22:17 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomQy-00083b-Aw for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:22:16 +0000 X-Inumbo-ID: 45a70b88-b79f-11ea-829c-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 45a70b88-b79f-11ea-829c-12813bfff9fa; Fri, 26 Jun 2020 11:22:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YEeC74DJ1hswoO8JWk9dkEMg0vtyAmbw2A085GDKzzs=; b=V5zD7sSKRS2i2Rzz+PKRKULeB 6vsPb/c5tjv30Dx5c5MNCuDmkqS8ALmshISn48tpbnR23fyq2qR1wEWJWJNuFVBIlOd14R1d0Odg6 jHzqOdAeY67MlaaAdOe2DR99KiVUvmkceCpxCScRoMhZCKGaYCfHQ+6z+IOSjzlEr3gLA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomQq-000275-20; Fri, 26 Jun 2020 11:22:08 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jomQp-0000fa-R0; Fri, 26 Jun 2020 11:22:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jomQp-0006GN-Nt; Fri, 26 Jun 2020 11:22:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151353: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-credit2:guest-localmigrate/x10:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=d4b78317b7cf8c0c635b70086503813f79ff21ec X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Fri, 26 Jun 2020 11:22:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151353 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151353/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-credit2 18 guest-localmigrate/x10 fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151065 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass version targeted for testing: qemuu d4b78317b7cf8c0c635b70086503813f79ff21ec baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 13 days Failing since 151101 2020-06-14 08:32:51 Z 12 days 10 attempts Testing same since 151353 2020-06-25 05:31:29 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Andrew Jones Anthony PERARD Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Cleber Rosa Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Geoffrey McRae Gerd Hoffmann Guenter Roeck Helge Deller Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jean-Christophe Dubois Jiaxun Yang John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marek Marczykowski-Górecki Markus Armbruster Masahiro Yamada Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Shameer Kolothum Stefan Berger Stefan Hajnoczi Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 fail test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 10427 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:25:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:25:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomU4-0008Df-4K; Fri, 26 Jun 2020 11:25:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomU2-0008Cv-Qo for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:25:26 +0000 X-Inumbo-ID: bb577b6a-b79f-11ea-829d-12813bfff9fa Received: from mail-wr1-f66.google.com (unknown [209.85.221.66]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bb577b6a-b79f-11ea-829d-12813bfff9fa; Fri, 26 Jun 2020 11:25:26 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id b6so9118403wrs.11 for ; Fri, 26 Jun 2020 04:25:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=5RoWnMEQoBsQtGSmLTmDOSjXffsN41Q/8Po4tZ9y+rY=; b=UunrN0KXeXsGeykAvDCRoJn6AsWwPdmn5Ev6v4BnMJjC8e/CEoOL2ulkMBjI5/RgHE JdgInuRQGcQDzpUKrx8hIG/vUWcFznUzW4bTBzzkEv8vsd9cAN6mIuG3VrT/kunGi/yG SpcVGZeCBsxvUOdSK+vd1jZlp3KUm7Htv6kRgG/VrtmnDfAKm8cSmwP6Rp9c2RXDnW2Z g89/8tHIxmOIRKxNJVQjfkxbAZTepEH2TcyD7l+stIBM9C8s7vI4VGTJtZojgX1qFp1k BuDQsI6SUHMFPemdpGj5ea7L+c46K5x4JrA7H3yVLfx4jWmEqO2SSdfW7tPRTeQ25i+B /GlQ== X-Gm-Message-State: AOAM532PmEZcbLJdNJL4XuVrLhp1/WEoxJwDUHOpFqq4X7/h4Sdrpki9 yzFFjP7sL8SKgIMRCZ27nrQ= X-Google-Smtp-Source: ABdhPJzE7sapxi+Pv4GO7PCG+FtBVNWb4w29lKTwJXMeKjH7ma8+14DWyO9ChgNifMSDi0Nxf7zZNg== X-Received: by 2002:adf:ef4d:: with SMTP id c13mr3141167wrp.315.1593170725600; Fri, 26 Jun 2020 04:25:25 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id 138sm18124773wma.23.2020.06.26.04.25.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 04:25:25 -0700 (PDT) Date: Fri, 26 Jun 2020 11:25:23 +0000 From: Wei Liu To: Ian Jackson Subject: Re: [PATCH] libxl: tooling expects wrong errno Message-ID: <20200626112523.eh6lpm5hudkjmg4l@liuwe-devbox-debian-v2> References: <24295.36070.945693.791220@mariner.uk.xensource.com> <20200615155646.GI735@Air-de-Roger> <24295.41945.883230.966002@mariner.uk.xensource.com> <003401d64337$f43c1990$dcb44cb0$@xen.org> <24295.45650.388910.186169@mariner.uk.xensource.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24295.45650.388910.186169@mariner.uk.xensource.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , 'Wei Liu' , "paul@xen.org" , "jakub@bartmin.ski" , Andrew Cooper , "marmarek@invisiblethingslab.com" , 'Grzegorz Uriasz' , Anthony Perard , 'Jan Beulich' , "j.nowak26@student.uw.edu.pl" , "xen-devel@lists.xenproject.org" , "contact@puzio.waw.pl" , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 15, 2020 at 06:39:30PM +0100, Ian Jackson wrote: > Paul Durrant writes ("RE: [PATCH] libxl: tooling expects wrong errno"): > > > -----Original Message----- > > > From: Ian Jackson > > > Thanks for the analysis. So: > > > > > > Acked-by: Ian Jackson > > > > > > This would seem to be a backport candidate. AFAICT check has been > > > there, looking for ENOSYS, since this code was introduced in > > > 826eb17271d3c647516d9944c47b0779afedea25 > > > libxl: suppress device assignment to HVM guest when there is no IOMMU > > > ? > > > > > > But that commit has a Tested-by. Maybe Xen changed its error return > > > at some point ? > > > > > > > Yes, it happened in 71e617a6b8f69849c70eda1b3c58f1ff6b244e5a > > use is_iommu_enabled() where appropriate... > > So, > > Backport: 4.13 > > Thanks! This is not yet committed. Paul, can I get a release ack from you? Wei. > > Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:28:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:28:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomWo-0008M2-If; Fri, 26 Jun 2020 11:28:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomWn-0008Lv-0t for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:28:17 +0000 X-Inumbo-ID: 20997f0a-b7a0-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 20997f0a-b7a0-11ea-bca7-bc764e2007e4; Fri, 26 Jun 2020 11:28:16 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id z13so9155409wrw.5 for ; Fri, 26 Jun 2020 04:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=0A7365tN2dnp2+z5BYZNMahPAbsFD0WtG7o+kA977BY=; b=fORFYXQVXOqnxSZO/OHvz4yOy4R49VDonoriO2pCwODMeShB4222flOHQMoXa+RrfY OsHSsUD4h4/g9y18m8wVoJC/Wy8+VADoF8yltUDK0XnAaaTymRWh6OBJjlp6be/tSxVX Cnzef+UaOYMH/nZDg1b36ZCY3UP+XBXVJO0bw3PCCJzm1dr6HuqUroSxwEFoa60Y5zkz 7xUyOxte7NOAoaMEuvMNRUl6ONtHEXNqvBBDeu3iCpk08+3yyhrgFTuRUFzNqu7j1QQG 9FSKaT2t8HSDOMQrMmUmnNFIuDKGPrCuiLZisrtosSfmn+xd7owkVH9anXTBPhrBbsSL WDhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=0A7365tN2dnp2+z5BYZNMahPAbsFD0WtG7o+kA977BY=; b=a7w16cowLQqE+n/BEg6zbJqxRV83qkqLHd48bLV8uCMxFdXb5tOwwJajGaW9TDX++g Cb/43WwRge7bqjfEqRoMzFhsu5NM7BwQT5x8A1OXKaq5MFUlrHXgN0emQoJUuYi5PLR8 3IdDf+UfLDOwfY+lPTeKIkTmOWX79cQKVvNZ4FkSMFsH/q5TR20XZyIbq5X8/zVgOJnd 8mTdvbuMaxHf8yS/XV+5+DkSRynAWQX/q5Np2wdRBf15OZVhfTrJ7R+rmOg9fDOj+Jk+ hQHvv/7x7KnUUYyi/QzVto/Mz4e1iC+gAZoNiJJ0wt+4YOQ4+taE3+lYT3WHcVEFowjk Jihg== X-Gm-Message-State: AOAM531gV97v5J+MxMOsLNftt1LVIBDM7Qh9cGGjBjH4y91GxZkwel7x IAvn6KcOWRHRUFMGa3HUgQE= X-Google-Smtp-Source: ABdhPJwNJpRU2/Oz65xkWCSTRZAaGZUcA0Wh36182wY0eTM20lws3DuykHfL3J3UzJYpdnet2aoplg== X-Received: by 2002:adf:c986:: with SMTP id f6mr3343956wrh.168.1593170895417; Fri, 26 Jun 2020 04:28:15 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id d28sm39384548wrc.50.2020.06.26.04.28.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 04:28:14 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Wei Liu'" , "'Ian Jackson'" References: <24295.36070.945693.791220@mariner.uk.xensource.com> <20200615155646.GI735@Air-de-Roger> <24295.41945.883230.966002@mariner.uk.xensource.com> <003401d64337$f43c1990$dcb44cb0$@xen.org> <24295.45650.388910.186169@mariner.uk.xensource.com> <20200626112523.eh6lpm5hudkjmg4l@liuwe-devbox-debian-v2> In-Reply-To: <20200626112523.eh6lpm5hudkjmg4l@liuwe-devbox-debian-v2> Subject: RE: [PATCH] libxl: tooling expects wrong errno Date: Fri, 26 Jun 2020 12:28:13 +0100 Message-ID: <000701d64bac$e1d689c0$a5839d40$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQJRrVmR5Atw2cuOlpDTe0mFV6HHUQIpYa7PAtS50FEBvgZ2vQGhrmapAf99wXUBUCvbQKeWkvtg X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Kevin Tian' , jakub@bartmin.ski, 'Andrew Cooper' , marmarek@invisiblethingslab.com, 'Grzegorz Uriasz' , 'Anthony Perard' , 'Jan Beulich' , j.nowak26@student.uw.edu.pl, xen-devel@lists.xenproject.org, contact@puzio.waw.pl, 'Roger Pau Monne' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Wei Liu > Sent: 26 June 2020 12:25 > To: Ian Jackson > Cc: paul@xen.org; Roger Pau Monne ; 'Grzegorz Uriasz' ; 'Jan > Beulich' ; Andrew Cooper ; Kevin Tian > ; 'Wei Liu' ; jakub@bartmin.ski; marmarek@invisiblethingslab.com; > j.nowak26@student.uw.edu.pl; Anthony Perard ; xen- > devel@lists.xenproject.org; contact@puzio.waw.pl > Subject: Re: [PATCH] libxl: tooling expects wrong errno > > On Mon, Jun 15, 2020 at 06:39:30PM +0100, Ian Jackson wrote: > > Paul Durrant writes ("RE: [PATCH] libxl: tooling expects wrong errno"): > > > > -----Original Message----- > > > > From: Ian Jackson > > > > Thanks for the analysis. So: > > > > > > > > Acked-by: Ian Jackson > > > > > > > > This would seem to be a backport candidate. AFAICT check has been > > > > there, looking for ENOSYS, since this code was introduced in > > > > 826eb17271d3c647516d9944c47b0779afedea25 > > > > libxl: suppress device assignment to HVM guest when there is no IOMMU > > > > ? > > > > > > > > But that commit has a Tested-by. Maybe Xen changed its error return > > > > at some point ? > > > > > > > > > > Yes, it happened in 71e617a6b8f69849c70eda1b3c58f1ff6b244e5a > > > use is_iommu_enabled() where appropriate... > > > > So, > > > > Backport: 4.13 > > > > Thanks! > > This is not yet committed. Paul, can I get a release ack from you? > > Wei. Yes. Release-acked-by: Paul Durrant > > > > > Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:30:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:30:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomYa-0000fn-Ue; Fri, 26 Jun 2020 11:30:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomYZ-0000c7-1Y for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:30:07 +0000 X-Inumbo-ID: 61b08038-b7a0-11ea-829e-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 61b08038-b7a0-11ea-829e-12813bfff9fa; Fri, 26 Jun 2020 11:30:05 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: bmfq5zgr6iP/e894/CV63QDhzVEZF4CwjrfzaG/Bd9Z35cf2ZOvIsIyFNkVgwhQOe0+xbMXZev 4/Q88zcNtCpacmZeA45/l+dGy64UZ/N9nU2wtHExLcfNVwN1AGR8tL8uapaTAIRZ28WFUIi/oS wcjUQFAwoRzuN0aK0MBad4xZs5HXaEsNwDpg8fIN/OYU5PstDzm8KbR74DV1p8Aq2mQcmpBCa/ MNiv8owfGAfvCcfGIojCDmjjOnG/cIzRrrJ6gc5U8Lt32Y7SDta8taohxEeCKw3DdLTP7Nr6mD RlE= X-SBRS: 2.7 X-MesageID: 21357179 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,283,1589256000"; d="scan'208";a="21357179" From: Andrew Cooper To: Xen-devel Subject: [PATCH v2 for-4.14] x86/msr: Disallow access to Processor Trace MSRs Date: Fri, 26 Jun 2020 12:29:37 +0100 Message-ID: <20200626112937.919-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Andrew Cooper , =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" We do not expose the feature to guests, so should disallow access to the respective MSRs. For simplicity, drop the entire block of MSRs, not just the subset which have been specified thus far. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant CC: Michał Leszczyński Paul: For 4.14. This needs backporting to older trees as well. v2: * Drop the whole 0x560 => 0x58f block. --- xen/arch/x86/msr.c | 2 ++ xen/include/asm-x86/msr-index.h | 8 ++++++++ 2 files changed, 10 insertions(+) diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index 0bfb5839b2..22f921cc71 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -168,6 +168,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) case MSR_TSX_FORCE_ABORT: case MSR_TSX_CTRL: case MSR_MCU_OPT_CTRL: + case MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7): case MSR_U_CET: case MSR_S_CET: case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE: @@ -329,6 +330,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val) case MSR_TSX_FORCE_ABORT: case MSR_TSX_CTRL: case MSR_MCU_OPT_CTRL: + case MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7): case MSR_U_CET: case MSR_S_CET: case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE: diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h index b328a47ed8..0fe98af923 100644 --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -69,6 +69,14 @@ #define MSR_MCU_OPT_CTRL 0x00000123 #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) +#define MSR_RTIT_OUTPUT_BASE 0x00000560 +#define MSR_RTIT_OUTPUT_MASK 0x00000561 +#define MSR_RTIT_CTL 0x00000570 +#define MSR_RTIT_STATUS 0x00000571 +#define MSR_RTIT_CR3_MATCH 0x00000572 +#define MSR_RTIT_ADDR_A(n) (0x00000580 + (n) * 2) +#define MSR_RTIT_ADDR_B(n) (0x00000581 + (n) * 2) + #define MSR_U_CET 0x000006a0 #define MSR_S_CET 0x000006a2 #define CET_SHSTK_EN (_AC(1, ULL) << 0) -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:31:27 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:31:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomZq-0000lB-9Y; Fri, 26 Jun 2020 11:31:26 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomZp-0000l6-LM for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:31:25 +0000 X-Inumbo-ID: 8ed308c4-b7a0-11ea-829e-12813bfff9fa Received: from mail-wr1-f65.google.com (unknown [209.85.221.65]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8ed308c4-b7a0-11ea-829e-12813bfff9fa; Fri, 26 Jun 2020 11:31:21 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id k6so9172546wrn.3 for ; Fri, 26 Jun 2020 04:31:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=TAHuT5hcvLzaJ5Ysz01dahZq5ZvGfdGPpHLiq1hDhOU=; b=Zacj0Ep/Mmj6C9EygnX/V8/DlpzyCuNzDTBiO0UkMTpQLlSmaiJ2TmWNQmVhvg7YcY fdJdM8Huhxbc93m+TgDARkHQJmrbTV+uahx4Ker1JBtVIOhg9gLlUjIt10gMAIYYpNR4 P1PpiQgXbNa8AB2mmyTY2bvmoIEHzS6C4HLNiprd4XJKmHUeA3cdpDnhj6KT08S2tJxv qt8zkcVo2j6B+44AKm+amMLBadaYMybAHWB3b47+KToo3Zq597q1EnF8ZWa/yRLLcdXZ zKUqSr1jUMoZ03zd5143HBFZgcNreHwXrqo/Z6qiSs8qSENMmQmC8JJmb2KkvbaxloBL 4a4w== X-Gm-Message-State: AOAM5301k163+j4wk61bq+PEJhtbkP0obU7Rl0pl/zt10LO3Hd/lxnbx xxWB1PxVXnZQHREjaGAQw2s= X-Google-Smtp-Source: ABdhPJx34nqIoPH1d9qU9+k9g2ymS0HEOlvhtYRrZGNbfBRULICdB117CQgZL/EibK3v++pY4q0uqQ== X-Received: by 2002:a5d:6749:: with SMTP id l9mr3215344wrw.63.1593171080313; Fri, 26 Jun 2020 04:31:20 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id c65sm16631702wme.8.2020.06.26.04.31.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 04:31:19 -0700 (PDT) Date: Fri, 26 Jun 2020 11:31:18 +0000 From: Wei Liu To: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Re: [PATCH v2 00/10] Coverity fixes for vchan-socket-proxy Message-ID: <20200626113118.mk3dsarodglerfck@liuwe-devbox-debian-v2> References: <20200611032936.350657-1-jandryuk@gmail.com> <20200626101807.za6arkdlah7zsjzc@liuwe-devbox-debian-v2> <20200626111201.GS1197@mail-itl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200626111201.GS1197@mail-itl> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Paul Durrant , Ian Jackson , Wei Liu , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 01:12:01PM +0200, Marek Marczykowski-Grecki wrote: > On Fri, Jun 26, 2020 at 10:18:07AM +0000, Wei Liu wrote: > > On Wed, Jun 10, 2020 at 11:29:26PM -0400, Jason Andryuk wrote: > > > This series addresses some Coverity reports. To handle closing FDs, a > > > state struct is introduced to track FDs closed in both main() and > > > data_loop(). > > > > > > v2 changes "Ensure UNIX path NUL terminated" to avoid a warning with > > > gcc-10. Also, "Move perror() into listen_socket" and "Move perror() > > > into connect_socket" are new. > > > > > > Jason Andryuk (10): > > > vchan-socket-proxy: Ensure UNIX path NUL terminated > > > vchan-socket-proxy: Move perror() into listen_socket > > > vchan-socket-proxy: Move perror() into connect_socket > > > vchan-socket-proxy: Check xs_watch return value > > > vchan-socket-proxy: Unify main return value > > > vchan-socket-proxy: Use a struct to store state > > > vchan-socket-proxy: Switch data_loop() to take state > > > vchan-socket-proxy: Set closed FDs to -1 > > > vchan-socket-proxy: Cleanup resources on exit > > > vchan-socket-proxy: Handle closing shared input/output_fd > > > > Acked-by: Wei Liu > > > > Cc Paul. V1 of this series was posted back in May. I consider this > > series bug fixes, so they should be applied for 4.14. The risk is low > > because vchan-socket-proxy is a small utility used by a small number of > > users. > > > > Marek, you gave Review tags in v1. Do they still apply here? > > Yes. And also for the new patches 2-3. I thought I've posted it here, > but must have missed clicking "send"... Thanks for confirming. Wei. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:32:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:32:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomb1-0000sh-M6; Fri, 26 Jun 2020 11:32:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomb0-0000sY-8o for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:32:38 +0000 X-Inumbo-ID: bc64fca2-b7a0-11ea-bb8b-bc764e2007e4 Received: from mail-wm1-x342.google.com (unknown [2a00:1450:4864:20::342]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bc64fca2-b7a0-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 11:32:37 +0000 (UTC) Received: by mail-wm1-x342.google.com with SMTP id g75so8500809wme.5 for ; Fri, 26 Jun 2020 04:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=wGNOGSdFb+vuii9abQIYL/oVZwugiFPwX3yapdXkByg=; b=YdfulbR6UaCJVHBQV970kmcm++I1qy1YmR02GyNHJAHcLeJ1Ksl3AlwujBtEPq1ECL Cs6HmEHeSagss9mqkzn8IGLy/yT13WjPrqWn9e4ZfMJvTvKftigXfb3jOqylj8rWi5Bq jKX0n+h324dbVUUszxZxawdVCrwetGycKDYoajsjlG9e2erMI6MSKLHCkzX1vUhYMf+C Cx8QYxVEklzj9w7TfNqKesjgtvY0/kXFvRPHt2oWUo4w1cxQsAW1e2RNXpqbrVi1/Cde zBL10wjzPkxZjI21R9e6PDRbiVch9GljGsaH/fkWKREyYinIbbBx+sU9wW7k7Bg/jKkr BrlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=wGNOGSdFb+vuii9abQIYL/oVZwugiFPwX3yapdXkByg=; b=nWM36Il0M3/MxhwXwCn7FfWJPrEeCxHvlwMrEyLZZi7wjGZLUCOg9lDHwpu57OVkLy e/MLzFUIqubyqhg9x+NmLbcVJgvI+yIvJxMD1qUejd2LaWJatJQZPXfPDjXAGScHaCzD Iv7NnpelsEcTkC62xr7WzCVRkDsUHfhCMmGuQFbBq/HQEUqPBFwTG4qunLl1zTLNPs2g z35YWM8yIINTOPtyvqEUXN2ktvPVv+TjKj5UZRAZBFkumixlr8SQlUnp9qotywE4Robk e68yqEnGw13SAmMLPS4PbLhb1CtNgerStcanrmKqh9HA7COHPvsh+vQ4yw+JccovCXOl tJQg== X-Gm-Message-State: AOAM5338Zg7nD3pRQkEXENjfPkVIpCWUUSRJsdnHFVV4M6qfwPHxdX6e IPYU5oxrJNq86OEmDKi+W+k= X-Google-Smtp-Source: ABdhPJzvN5hE9na42/fWZo8IBA72u6c2sIUZF29ixkQODJRKZoxYtHtvLY2yyc2fZexZ8rBPnTjMxA== X-Received: by 2002:a1c:4408:: with SMTP id r8mr2955751wma.100.1593171156606; Fri, 26 Jun 2020 04:32:36 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id 65sm17562247wma.48.2020.06.26.04.32.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 04:32:36 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200626112937.919-1-andrew.cooper3@citrix.com> In-Reply-To: <20200626112937.919-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH v2 for-4.14] x86/msr: Disallow access to Processor Trace MSRs Date: Fri, 26 Jun 2020 12:32:35 +0100 Message-ID: <000901d64bad$7d86f3f0$7894dbd0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQH2K7Qshipg+dBwwv0Oi6OatfdfEqirA1wQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: =?utf-8?Q?'Micha=C5=82_Leszczy=C5=84ski'?= , 'Wei Liu' , 'Jan Beulich' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 26 June 2020 12:30 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich = ; Wei Liu ; > Roger Pau Monn=C3=A9 ; Paul Durrant = ; Micha=C5=82 Leszczy=C5=84ski > > Subject: [PATCH v2 for-4.14] x86/msr: Disallow access to Processor = Trace MSRs >=20 > We do not expose the feature to guests, so should disallow access to = the > respective MSRs. For simplicity, drop the entire block of MSRs, not = just the > subset which have been specified thus far. >=20 > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monn=C3=A9 > CC: Paul Durrant > CC: Micha=C5=82 Leszczy=C5=84ski >=20 > Paul: For 4.14. This needs backporting to older trees as well. >=20 > v2: > * Drop the whole 0x560 =3D> 0x58f block. Looks ok to me. Release-acked-by: Paul Durrant > --- > xen/arch/x86/msr.c | 2 ++ > xen/include/asm-x86/msr-index.h | 8 ++++++++ > 2 files changed, 10 insertions(+) >=20 > diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c > index 0bfb5839b2..22f921cc71 100644 > --- a/xen/arch/x86/msr.c > +++ b/xen/arch/x86/msr.c > @@ -168,6 +168,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, = uint64_t *val) > case MSR_TSX_FORCE_ABORT: > case MSR_TSX_CTRL: > case MSR_MCU_OPT_CTRL: > + case MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7): > case MSR_U_CET: > case MSR_S_CET: > case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE: > @@ -329,6 +330,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, = uint64_t val) > case MSR_TSX_FORCE_ABORT: > case MSR_TSX_CTRL: > case MSR_MCU_OPT_CTRL: > + case MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7): > case MSR_U_CET: > case MSR_S_CET: > case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE: > diff --git a/xen/include/asm-x86/msr-index.h = b/xen/include/asm-x86/msr-index.h > index b328a47ed8..0fe98af923 100644 > --- a/xen/include/asm-x86/msr-index.h > +++ b/xen/include/asm-x86/msr-index.h > @@ -69,6 +69,14 @@ > #define MSR_MCU_OPT_CTRL 0x00000123 > #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) >=20 > +#define MSR_RTIT_OUTPUT_BASE 0x00000560 > +#define MSR_RTIT_OUTPUT_MASK 0x00000561 > +#define MSR_RTIT_CTL 0x00000570 > +#define MSR_RTIT_STATUS 0x00000571 > +#define MSR_RTIT_CR3_MATCH 0x00000572 > +#define MSR_RTIT_ADDR_A(n) (0x00000580 + (n) * 2) > +#define MSR_RTIT_ADDR_B(n) (0x00000581 + (n) * 2) > + > #define MSR_U_CET 0x000006a0 > #define MSR_S_CET 0x000006a2 > #define CET_SHSTK_EN (_AC(1, ULL) << 0) > -- > 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:35:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:35:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomdd-00011Z-3C; Fri, 26 Jun 2020 11:35:21 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomdb-00011T-CF for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:35:19 +0000 X-Inumbo-ID: 1c022f68-b7a1-11ea-82a4-12813bfff9fa Received: from mail-wm1-f67.google.com (unknown [209.85.128.67]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1c022f68-b7a1-11ea-82a4-12813bfff9fa; Fri, 26 Jun 2020 11:35:18 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id 17so9062026wmo.1 for ; Fri, 26 Jun 2020 04:35:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=d7U+YA59uSygIA3iiTRXVXEJD5qkA9ZYnnSsOLzLJtw=; b=lVHWx+lnR0VUOf92PCWH3iw2xFXD3ffYWb4EItZb9db/uank2nSbN94HbWVpXRllsi a1nuRXVp4ybUr/iOmeoB+xvJkV89Zlc2gi+2mIvyaJj15VaWrp1JRjxRVSz9que1l/tz j1AdaPlh5boRKMoLaupDWsqu/3j/lijo2QktdpMcCjJt8MOhMQF/WcnzkcP+lsgeamHO DPZgpsrPwdlEfvJ7nguicQbDLQWg/8Tiz6MnQHgnAgIa/vbdkgTcXBSotsTl97w/XQuh CeIDx6k9yd2iukj/vOz0LwwaRLkdZZ0+XO14WBPYuZm60Cd6hGjaHPT0T8tiIlFIeldl REaw== X-Gm-Message-State: AOAM532ZDjktt2K/d5QU9PbsUMZhcIXH/9flY6QxpcB5pYoiI3BZnSgu 3jOwUV8ltiQkTGfjdxZMuI72lFCq X-Google-Smtp-Source: ABdhPJyzdw9qagh+dUsvSz75mc9LqRSyqKoWUzuLAe1fxsOkfvvDNCNvpdYrZ58MuImTLb03HjtI9Q== X-Received: by 2002:a1c:bcd4:: with SMTP id m203mr2937021wmf.124.1593171317255; Fri, 26 Jun 2020 04:35:17 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id p8sm449954wrq.29.2020.06.26.04.35.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 04:35:16 -0700 (PDT) Date: Fri, 26 Jun 2020 11:35:15 +0000 From: Wei Liu To: Andrew Cooper Subject: Re: [PATCH v2 for-4.14] x86/msr: Disallow access to Processor Trace MSRs Message-ID: <20200626113515.hqoa4ppt6bcnr4wj@liuwe-devbox-debian-v2> References: <20200626112937.919-1-andrew.cooper3@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200626112937.919-1-andrew.cooper3@citrix.com> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= , Jan Beulich , Xen-devel , Roger Pau =?utf-8?B?TW9ubsOp?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 12:29:37PM +0100, Andrew Cooper wrote: > We do not expose the feature to guests, so should disallow access to the > respective MSRs. For simplicity, drop the entire block of MSRs, not just the > subset which have been specified thus far. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monné > CC: Paul Durrant > CC: Michał Leszczyński > > Paul: For 4.14. This needs backporting to older trees as well. > > v2: > * Drop the whole 0x560 => 0x58f block. Reviewed-by: Wei Liu I have not checked the MSR values against the manual, but the modifications to guest_{rd,wr}msr look correct to me. Wei. > --- > xen/arch/x86/msr.c | 2 ++ > xen/include/asm-x86/msr-index.h | 8 ++++++++ > 2 files changed, 10 insertions(+) > > diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c > index 0bfb5839b2..22f921cc71 100644 > --- a/xen/arch/x86/msr.c > +++ b/xen/arch/x86/msr.c > @@ -168,6 +168,7 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val) > case MSR_TSX_FORCE_ABORT: > case MSR_TSX_CTRL: > case MSR_MCU_OPT_CTRL: > + case MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7): > case MSR_U_CET: > case MSR_S_CET: > case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE: > @@ -329,6 +330,7 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t val) > case MSR_TSX_FORCE_ABORT: > case MSR_TSX_CTRL: > case MSR_MCU_OPT_CTRL: > + case MSR_RTIT_OUTPUT_BASE ... MSR_RTIT_ADDR_B(7): > case MSR_U_CET: > case MSR_S_CET: > case MSR_PL0_SSP ... MSR_INTERRUPT_SSP_TABLE: > diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h > index b328a47ed8..0fe98af923 100644 > --- a/xen/include/asm-x86/msr-index.h > +++ b/xen/include/asm-x86/msr-index.h > @@ -69,6 +69,14 @@ > #define MSR_MCU_OPT_CTRL 0x00000123 > #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) > > +#define MSR_RTIT_OUTPUT_BASE 0x00000560 > +#define MSR_RTIT_OUTPUT_MASK 0x00000561 > +#define MSR_RTIT_CTL 0x00000570 > +#define MSR_RTIT_STATUS 0x00000571 > +#define MSR_RTIT_CR3_MATCH 0x00000572 > +#define MSR_RTIT_ADDR_A(n) (0x00000580 + (n) * 2) > +#define MSR_RTIT_ADDR_B(n) (0x00000581 + (n) * 2) > + > #define MSR_U_CET 0x000006a0 > #define MSR_S_CET 0x000006a2 > #define CET_SHSTK_EN (_AC(1, ULL) << 0) > -- > 2.11.0 > From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:48:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:48:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomqM-0001yy-Db; Fri, 26 Jun 2020 11:48:30 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomqK-0001yt-Oj for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:48:28 +0000 X-Inumbo-ID: f2e892b4-b7a2-11ea-82a6-12813bfff9fa Received: from mail-wm1-f53.google.com (unknown [209.85.128.53]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f2e892b4-b7a2-11ea-82a6-12813bfff9fa; Fri, 26 Jun 2020 11:48:28 +0000 (UTC) Received: by mail-wm1-f53.google.com with SMTP id q15so8556419wmj.2 for ; Fri, 26 Jun 2020 04:48:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=qqMW8S7YzpDyHslkjYwg4S5kq202QeSPCMBzFbL9qyE=; b=V5MY2g+9a4ZrhQqI4vbNiY2bNYIh6YsRdRAOVXcGLOcnzNHOlIqslR26wOUkulod5n aYANue49VOQCyfVvMwIUc2/BnCUKe19sH9VhBmmY23+nJppHk2rqEWt5rOjL7DZAl2cX pIOIrsTSx7mcOTFOKKcGKGLLwcvQFR/fxPsPQziZhiZ41634OTxu1Uj8cVtPiGuZkxKi NeicEAciokM9tuWO5zA5is7ODXipgoch21kd58/gQ6jcD2fU+RsHdXji2+Vwfbs2MnA6 nlhZhEVSDry9mg4ieDwiIrC17i0d7gHil9oQnlyfDJH5hpDJoxLwCuVQneriweAQJJO3 FXYg== X-Gm-Message-State: AOAM531mKwxO/7Gxh3D2MgiivsSdQI1AAwT85yjksqrWyNK1+3wSc/Of mhDjxgN6oF+/5kwle2Z4FS8= X-Google-Smtp-Source: ABdhPJwoMMGPeN6l+tzU9JAYSeL94msfyy4A5ullbe7ES85FS5t9YSSpf32qdG3uHSO1VWYbOKTCWw== X-Received: by 2002:a7b:cb98:: with SMTP id m24mr3020315wmi.98.1593172106775; Fri, 26 Jun 2020 04:48:26 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id q188sm14260780wma.46.2020.06.26.04.48.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 04:48:25 -0700 (PDT) Date: Fri, 26 Jun 2020 11:48:24 +0000 From: Wei Liu To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v3 7/7] tools/proctrace: add proctrace tool Message-ID: <20200626114824.mt2zsbwdbed5dtwj@liuwe-devbox-debian-v2> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> <1786138246.11444015.1592849576272.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1786138246.11444015.1592849576272.JavaMail.zimbra@cert.pl> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Wei Liu , Tamas K Lengyel , Ian Jackson , "Kang, Luwei" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 08:12:56PM +0200, Michał Leszczyński wrote: > Add an demonstration tool that uses xc_vmtrace_* calls in order > to manage external IPT monitoring for DomU. > > Signed-off-by: Michal Leszczynski > --- > tools/proctrace/COPYING | 339 ++++++++++++++++++++++++++++++++++++ > tools/proctrace/Makefile | 50 ++++++ > tools/proctrace/proctrace.c | 158 +++++++++++++++++ > 3 files changed, 547 insertions(+) > create mode 100644 tools/proctrace/COPYING > create mode 100644 tools/proctrace/Makefile > create mode 100644 tools/proctrace/proctrace.c > > diff --git a/tools/proctrace/COPYING b/tools/proctrace/COPYING > new file mode 100644 > index 0000000000..c0a841112c > --- /dev/null > +++ b/tools/proctrace/COPYING > @@ -0,0 +1,339 @@ > + GNU GENERAL PUBLIC LICENSE > + Version 2, June 1991 > + > + Copyright (C) 1989, 1991 Free Software Foundation, Inc. > + 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + Everyone is permitted to copy and distribute verbatim copies > + of this license document, but changing it is not allowed. > + > + Preamble > + > + The licenses for most software are designed to take away your > +freedom to share and change it. By contrast, the GNU General Public > +License is intended to guarantee your freedom to share and change free > +software--to make sure the software is free for all its users. This > +General Public License applies to most of the Free Software > +Foundation's software and to any other program whose authors commit to > +using it. (Some other Free Software Foundation software is covered by > +the GNU Library General Public License instead.) You can apply it to > +your programs, too. > + > + When we speak of free software, we are referring to freedom, not > +price. Our General Public Licenses are designed to make sure that you > +have the freedom to distribute copies of free software (and charge for > +this service if you wish), that you receive source code or can get it > +if you want it, that you can change the software or use pieces of it > +in new free programs; and that you know you can do these things. > + > + To protect your rights, we need to make restrictions that forbid > +anyone to deny you these rights or to ask you to surrender the rights. > +These restrictions translate to certain responsibilities for you if you > +distribute copies of the software, or if you modify it. > + > + For example, if you distribute copies of such a program, whether > +gratis or for a fee, you must give the recipients all the rights that > +you have. You must make sure that they, too, receive or can get the > +source code. And you must show them these terms so they know their > +rights. > + > + We protect your rights with two steps: (1) copyright the software, and > +(2) offer you this license which gives you legal permission to copy, > +distribute and/or modify the software. > + > + Also, for each author's protection and ours, we want to make certain > +that everyone understands that there is no warranty for this free > +software. If the software is modified by someone else and passed on, we > +want its recipients to know that what they have is not the original, so > +that any problems introduced by others will not reflect on the original > +authors' reputations. > + > + Finally, any free program is threatened constantly by software > +patents. We wish to avoid the danger that redistributors of a free > +program will individually obtain patent licenses, in effect making the > +program proprietary. To prevent this, we have made it clear that any > +patent must be licensed for everyone's free use or not licensed at all. > + > + The precise terms and conditions for copying, distribution and > +modification follow. > + > + GNU GENERAL PUBLIC LICENSE > + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION > + > + 0. This License applies to any program or other work which contains > +a notice placed by the copyright holder saying it may be distributed > +under the terms of this General Public License. The "Program", below, > +refers to any such program or work, and a "work based on the Program" > +means either the Program or any derivative work under copyright law: > +that is to say, a work containing the Program or a portion of it, > +either verbatim or with modifications and/or translated into another > +language. (Hereinafter, translation is included without limitation in > +the term "modification".) Each licensee is addressed as "you". > + > +Activities other than copying, distribution and modification are not > +covered by this License; they are outside its scope. The act of > +running the Program is not restricted, and the output from the Program > +is covered only if its contents constitute a work based on the > +Program (independent of having been made by running the Program). > +Whether that is true depends on what the Program does. > + > + 1. You may copy and distribute verbatim copies of the Program's > +source code as you receive it, in any medium, provided that you > +conspicuously and appropriately publish on each copy an appropriate > +copyright notice and disclaimer of warranty; keep intact all the > +notices that refer to this License and to the absence of any warranty; > +and give any other recipients of the Program a copy of this License > +along with the Program. > + > +You may charge a fee for the physical act of transferring a copy, and > +you may at your option offer warranty protection in exchange for a fee. > + > + 2. You may modify your copy or copies of the Program or any portion > +of it, thus forming a work based on the Program, and copy and > +distribute such modifications or work under the terms of Section 1 > +above, provided that you also meet all of these conditions: > + > + a) You must cause the modified files to carry prominent notices > + stating that you changed the files and the date of any change. > + > + b) You must cause any work that you distribute or publish, that in > + whole or in part contains or is derived from the Program or any > + part thereof, to be licensed as a whole at no charge to all third > + parties under the terms of this License. > + > + c) If the modified program normally reads commands interactively > + when run, you must cause it, when started running for such > + interactive use in the most ordinary way, to print or display an > + announcement including an appropriate copyright notice and a > + notice that there is no warranty (or else, saying that you provide > + a warranty) and that users may redistribute the program under > + these conditions, and telling the user how to view a copy of this > + License. (Exception: if the Program itself is interactive but > + does not normally print such an announcement, your work based on > + the Program is not required to print an announcement.) > + > +These requirements apply to the modified work as a whole. If > +identifiable sections of that work are not derived from the Program, > +and can be reasonably considered independent and separate works in > +themselves, then this License, and its terms, do not apply to those > +sections when you distribute them as separate works. But when you > +distribute the same sections as part of a whole which is a work based > +on the Program, the distribution of the whole must be on the terms of > +this License, whose permissions for other licensees extend to the > +entire whole, and thus to each and every part regardless of who wrote it. > + > +Thus, it is not the intent of this section to claim rights or contest > +your rights to work written entirely by you; rather, the intent is to > +exercise the right to control the distribution of derivative or > +collective works based on the Program. > + > +In addition, mere aggregation of another work not based on the Program > +with the Program (or with a work based on the Program) on a volume of > +a storage or distribution medium does not bring the other work under > +the scope of this License. > + > + 3. You may copy and distribute the Program (or a work based on it, > +under Section 2) in object code or executable form under the terms of > +Sections 1 and 2 above provided that you also do one of the following: > + > + a) Accompany it with the complete corresponding machine-readable > + source code, which must be distributed under the terms of Sections > + 1 and 2 above on a medium customarily used for software interchange; or, > + > + b) Accompany it with a written offer, valid for at least three > + years, to give any third party, for a charge no more than your > + cost of physically performing source distribution, a complete > + machine-readable copy of the corresponding source code, to be > + distributed under the terms of Sections 1 and 2 above on a medium > + customarily used for software interchange; or, > + > + c) Accompany it with the information you received as to the offer > + to distribute corresponding source code. (This alternative is > + allowed only for noncommercial distribution and only if you > + received the program in object code or executable form with such > + an offer, in accord with Subsection b above.) > + > +The source code for a work means the preferred form of the work for > +making modifications to it. For an executable work, complete source > +code means all the source code for all modules it contains, plus any > +associated interface definition files, plus the scripts used to > +control compilation and installation of the executable. However, as a > +special exception, the source code distributed need not include > +anything that is normally distributed (in either source or binary > +form) with the major components (compiler, kernel, and so on) of the > +operating system on which the executable runs, unless that component > +itself accompanies the executable. > + > +If distribution of executable or object code is made by offering > +access to copy from a designated place, then offering equivalent > +access to copy the source code from the same place counts as > +distribution of the source code, even though third parties are not > +compelled to copy the source along with the object code. > + > + 4. You may not copy, modify, sublicense, or distribute the Program > +except as expressly provided under this License. Any attempt > +otherwise to copy, modify, sublicense or distribute the Program is > +void, and will automatically terminate your rights under this License. > +However, parties who have received copies, or rights, from you under > +this License will not have their licenses terminated so long as such > +parties remain in full compliance. > + > + 5. You are not required to accept this License, since you have not > +signed it. However, nothing else grants you permission to modify or > +distribute the Program or its derivative works. These actions are > +prohibited by law if you do not accept this License. Therefore, by > +modifying or distributing the Program (or any work based on the > +Program), you indicate your acceptance of this License to do so, and > +all its terms and conditions for copying, distributing or modifying > +the Program or works based on it. > + > + 6. Each time you redistribute the Program (or any work based on the > +Program), the recipient automatically receives a license from the > +original licensor to copy, distribute or modify the Program subject to > +these terms and conditions. You may not impose any further > +restrictions on the recipients' exercise of the rights granted herein. > +You are not responsible for enforcing compliance by third parties to > +this License. > + > + 7. If, as a consequence of a court judgment or allegation of patent > +infringement or for any other reason (not limited to patent issues), > +conditions are imposed on you (whether by court order, agreement or > +otherwise) that contradict the conditions of this License, they do not > +excuse you from the conditions of this License. If you cannot > +distribute so as to satisfy simultaneously your obligations under this > +License and any other pertinent obligations, then as a consequence you > +may not distribute the Program at all. For example, if a patent > +license would not permit royalty-free redistribution of the Program by > +all those who receive copies directly or indirectly through you, then > +the only way you could satisfy both it and this License would be to > +refrain entirely from distribution of the Program. > + > +If any portion of this section is held invalid or unenforceable under > +any particular circumstance, the balance of the section is intended to > +apply and the section as a whole is intended to apply in other > +circumstances. > + > +It is not the purpose of this section to induce you to infringe any > +patents or other property right claims or to contest validity of any > +such claims; this section has the sole purpose of protecting the > +integrity of the free software distribution system, which is > +implemented by public license practices. Many people have made > +generous contributions to the wide range of software distributed > +through that system in reliance on consistent application of that > +system; it is up to the author/donor to decide if he or she is willing > +to distribute software through any other system and a licensee cannot > +impose that choice. > + > +This section is intended to make thoroughly clear what is believed to > +be a consequence of the rest of this License. > + > + 8. If the distribution and/or use of the Program is restricted in > +certain countries either by patents or by copyrighted interfaces, the > +original copyright holder who places the Program under this License > +may add an explicit geographical distribution limitation excluding > +those countries, so that distribution is permitted only in or among > +countries not thus excluded. In such case, this License incorporates > +the limitation as if written in the body of this License. > + > + 9. The Free Software Foundation may publish revised and/or new versions > +of the General Public License from time to time. Such new versions will > +be similar in spirit to the present version, but may differ in detail to > +address new problems or concerns. > + > +Each version is given a distinguishing version number. If the Program > +specifies a version number of this License which applies to it and "any > +later version", you have the option of following the terms and conditions > +either of that version or of any later version published by the Free > +Software Foundation. If the Program does not specify a version number of > +this License, you may choose any version ever published by the Free Software > +Foundation. > + > + 10. If you wish to incorporate parts of the Program into other free > +programs whose distribution conditions are different, write to the author > +to ask for permission. For software which is copyrighted by the Free > +Software Foundation, write to the Free Software Foundation; we sometimes > +make exceptions for this. Our decision will be guided by the two goals > +of preserving the free status of all derivatives of our free software and > +of promoting the sharing and reuse of software generally. > + > + NO WARRANTY > + > + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY > +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN > +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES > +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED > +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF > +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS > +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE > +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, > +REPAIR OR CORRECTION. > + > + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING > +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR > +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, > +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING > +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED > +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY > +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER > +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE > +POSSIBILITY OF SUCH DAMAGES. > + > + END OF TERMS AND CONDITIONS > + > + How to Apply These Terms to Your New Programs > + > + If you develop a new program, and you want it to be of the greatest > +possible use to the public, the best way to achieve this is to make it > +free software which everyone can redistribute and change under these terms. > + > + To do so, attach the following notices to the program. It is safest > +to attach them to the start of each source file to most effectively > +convey the exclusion of warranty; and each file should have at least > +the "copyright" line and a pointer to where the full notice is found. > + > + > + Copyright (C) > + > + This program is free software; you can redistribute it and/or modify > + it under the terms of the GNU General Public License as published by > + the Free Software Foundation; either version 2 of the License, or > + (at your option) any later version. > + > + This program is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + GNU General Public License for more details. > + > + You should have received a copy of the GNU General Public License > + along with this program; If not, see . > + > + > +Also add information on how to contact you by electronic and paper mail. > + > +If the program is interactive, make it output a short notice like this > +when it starts in an interactive mode: > + > + Gnomovision version 69, Copyright (C) year name of author > + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. > + This is free software, and you are welcome to redistribute it > + under certain conditions; type `show c' for details. > + > +The hypothetical commands `show w' and `show c' should show the appropriate > +parts of the General Public License. Of course, the commands you use may > +be called something other than `show w' and `show c'; they could even be > +mouse-clicks or menu items--whatever suits your program. > + > +You should also get your employer (if you work as a programmer) or your > +school, if any, to sign a "copyright disclaimer" for the program, if > +necessary. Here is a sample; alter the names: > + > + Yoyodyne, Inc., hereby disclaims all copyright interest in the program > + `Gnomovision' (which makes passes at compilers) written by James Hacker. > + > + , 1 April 1989 > + Ty Coon, President of Vice > + > +This General Public License does not permit incorporating your program into > +proprietary programs. If your program is a subroutine library, you may > +consider it more useful to permit linking proprietary applications with the > +library. If this is what you want to do, use the GNU Library General > +Public License instead of this License. > diff --git a/tools/proctrace/Makefile b/tools/proctrace/Makefile > new file mode 100644 > index 0000000000..76d7387a64 > --- /dev/null > +++ b/tools/proctrace/Makefile > @@ -0,0 +1,50 @@ > +# Copyright (C) CERT Polska - NASK PIB > +# Author: Michał Leszczyński > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; under version 2 of the License. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > + > +XEN_ROOT=$(CURDIR)/../.. > +include $(XEN_ROOT)/tools/Rules.mk > + > +CFLAGS += -Werror > +CFLAGS += $(CFLAGS_libxenevtchn) > +CFLAGS += $(CFLAGS_libxenctrl) > +LDLIBS += $(LDLIBS_libxenctrl) > +LDLIBS += $(LDLIBS_libxenevtchn) > +LDLIBS += $(LDLIBS_libxenforeignmemory) > + > +# SCRIPTS = xenmon.py > + Please drop this line. > +.PHONY: all > +all: build > + > +.PHONY: build > +build: proctrace > + > +.PHONY: install > +install: build > + $(INSTALL_DIR) $(DESTDIR)$(sbindir) > + $(INSTALL_PROG) proctrace $(DESTDIR)$(sbindir)/proctrace > + > +.PHONY: uninstall > +uninstall: > + rm -f $(DESTDIR)$(sbindir)/proctrace > + > +.PHONY: clean > +clean: > + $(RM) -f $(DEPS_RM) > + > +.PHONY: distclean > +distclean: clean > + > +iptlive: iptlive.o Makefile > + $(CC) $(LDFLAGS) $< -o $@ $(LDLIBS) $(APPEND_LDFLAGS) > + > +-include $(DEPS_INCLUDE) > diff --git a/tools/proctrace/proctrace.c b/tools/proctrace/proctrace.c > new file mode 100644 > index 0000000000..dddc6515f8 > --- /dev/null > +++ b/tools/proctrace/proctrace.c > @@ -0,0 +1,158 @@ > +/****************************************************************************** > + * tools/proctrace.c > + * > + * Demonstrative tool for collecting Intel Processor Trace data from Xen. > + * Could be used to externally monitor a given vCPU in given DomU. > + * > + * Copyright (C) 2020 by CERT Polska - NASK PIB > + * > + * Authors: Michał Leszczyński, michal.leszczynski@cert.pl > + * Date: June, 2020 > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; under version 2 of the License. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; If not, see . > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + Do yo really need so many headers? For one, I don't think you used getopt anywhere. > +#include > +#include > +#include > +#define XC_WANT_COMPAT_MAP_FOREIGN_API Would be nice if you don't use the compat API. They are for compatibility with old code. Since you're writing new code, the non-compat APIs are preferred. This is something for you to consider. For simple programs like this I won't insist. > +#include > +#include > + > +#define BUF_SIZE 16384 * 4096 > + #define BUF_SIZE (16384 * 4096) > +volatile int interrupted = 0; > + > +void term_handler(int signum) { > + interrupted = 1; > +} > + > +int main(int argc, char* argv[]) { > + xc_interface *xc; > + uint32_t domid; > + uint32_t vcpu_id; > + > + int rc = -1; > + uint8_t *buf = NULL; > + uint64_t last_offset = 0; > + > + xenforeignmemory_handle* fmem; Please put * before fmem to be consistent. > + xenforeignmemory_resource_handle *fres; > + > + signal(SIGINT, term_handler); You should perhaps check the return value of signal here. > + > + if (argc != 3) { > + fprintf(stderr, "Usage: %s \n", argv[0]); > + fprintf(stderr, "It's recommended to redirect this" > + "program's output to file\n"); > + fprintf(stderr, "or to pipe it's output to xxd or other program.\n"); > + return 1; > + } > + > + domid = atoi(argv[1]); > + vcpu_id = atoi(argv[2]); > + > + xc = xc_interface_open(0, 0, 0); > + > + fmem = xenforeignmemory_open(0, 0); > + > + if (!xc) { > + fprintf(stderr, "Failed to open xc interface\n"); > + return 1; > + } > + > + rc = xc_vmtrace_pt_enable(xc, domid, vcpu_id); > + > + if (rc) { > + fprintf(stderr, "Failed to call xc_vmtrace_pt_enable\n"); > + return 1; > + } > + > + fres = xenforeignmemory_map_resource( > + fmem, domid, XENMEM_resource_vmtrace_buf, > + /* vcpu: */ vcpu_id, > + /* frame: */ 0, > + /* num_frames: */ BUF_SIZE >> XC_PAGE_SHIFT, > + (void **)&buf, > + PROT_READ, 0); > + > + if (!buf) { > + fprintf(stderr, "Failed to map trace buffer\n"); > + return 1; > + } > + > + while (!interrupted) { > + uint64_t offset; > + rc = xc_vmtrace_pt_get_offset(xc, domid, vcpu_id, &offset); > + > + if (rc) { > + fprintf(stderr, "Failed to call xc_vmtrace_pt_get_offset\n"); > + return 1; > + } > + > + if (offset > last_offset) > + { > + fwrite(buf + last_offset, offset - last_offset, 1, stdout); > + } > + else if (offset < last_offset) > + { > + // buffer wrapped > + fwrite(buf + last_offset, BUF_SIZE - last_offset, 1, stdout); > + fwrite(buf, offset, 1, stdout); > + } > + > + last_offset = offset; > + usleep(1000 * 100); > + } > + > + rc = xenforeignmemory_unmap_resource(fmem, fres); > + > + if (rc) { > + fprintf(stderr, "Failed to unmap resource\n"); > + return 1; > + } > + > + rc = xc_vmtrace_pt_disable(xc, domid, vcpu_id); > + > + if (rc) { > + fprintf(stderr, "Failed to call xc_vmtrace_pt_disable\n"); > + return 1; > + } > + You should close fmem and xc in the exit path. Wei. > + return 0; > +} > + > +/* > + * Local variables: > + * mode: C > + * c-file-style: "BSD" > + * c-basic-offset: 4 > + * tab-width: 4 > + * indent-tabs-mode: nil > + * End: > + */ > -- > 2.20.1 > > From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:50:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:50:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomsj-0002im-RK; Fri, 26 Jun 2020 11:50:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomsj-0002if-4M for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:50:57 +0000 X-Inumbo-ID: 4b556abc-b7a3-11ea-bb8b-bc764e2007e4 Received: from mail-wm1-f65.google.com (unknown [209.85.128.65]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4b556abc-b7a3-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 11:50:56 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id a6so8726694wmm.0 for ; Fri, 26 Jun 2020 04:50:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=4NJZpymAfpFAgCWr9gUb+oM6L0GUKtNoFK72YNX8rV0=; b=RXke+fAmjc/dfZ3jYsRG9U8NrFELQlUZ1rGNjSlXFNRTDBTfNMqt+iYmz9H634Mjms TVJH6rAkGKGucZWveqQvRaYAJIY49mZmhsdVR7/egQxpTusuY6v+H13DNLHPdHvUVa1l jT2fWelmM7MBbKKj3HYsYKjObEbtJmGVP80P3lTKLs/+8jiPg1jOmZKdV/fkLsnvnmjI CLwXU/m4j+8ocyW4xvWRb0HuKVq5C4ZDKg52XDozNjSyCw1JIk5cjA6SLxLgNe+f9BqV hFf9sssVYDmFin6okvwY8YN0tEIlI1h0Sboq8CnYzuMeoI9DO6foK1kHYuTZsdao6Iue xbdA== X-Gm-Message-State: AOAM532/afCx38MF7SJ8ZMxLw3WCVnKKxH7diJcmcC7H+A+vZ5b6ud0L +QYjSzDUa12TtGOFBOtMkxY= X-Google-Smtp-Source: ABdhPJzb8L2eVl5EThx2cNUh/2m0xjSUjkf7/Csj4TO0qsGKms60PqrjJyKoxgd4Gtu3DBiEcnBEZQ== X-Received: by 2002:a1c:c3c5:: with SMTP id t188mr3161863wmf.53.1593172255660; Fri, 26 Jun 2020 04:50:55 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id z16sm26598818wrr.35.2020.06.26.04.50.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 04:50:55 -0700 (PDT) Date: Fri, 26 Jun 2020 11:50:53 +0000 From: Wei Liu To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v3 5/7] tools/libxc: add xc_vmtrace_* functions Message-ID: <20200626115053.aaugxnmb5wgh7wb4@liuwe-devbox-debian-v2> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> <1478140470.11443872.1592849522947.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1478140470.11443872.1592849522947.JavaMail.zimbra@cert.pl> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, Tamas K Lengyel , Ian Jackson , "Kang, Luwei" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 08:12:02PM +0200, Michał Leszczyński wrote: > Add functions in libxc that use the new HVMOP_vmtrace interface. > > Signed-off-by: Michal Leszczynski They look to be simple wrappers for hypercalls, so their acceptance will be dependent on the hypervisor side code. Wei. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:52:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:52:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomub-0002qi-Ac; Fri, 26 Jun 2020 11:52:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomuZ-0002qd-RJ for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:52:51 +0000 X-Inumbo-ID: 8f78cd42-b7a3-11ea-82a7-12813bfff9fa Received: from mail-wr1-f66.google.com (unknown [209.85.221.66]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8f78cd42-b7a3-11ea-82a7-12813bfff9fa; Fri, 26 Jun 2020 11:52:50 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id a6so9222377wrm.4 for ; Fri, 26 Jun 2020 04:52:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=EkhxY+ao3nRfJJXmQYt+sSP5pxPXEoEkVsAek7Jpfco=; b=nguc++Aa0v4HcB0eqXcfDng5M1a0FTs1VWrjPWQZaeGMpRzRSGtrpaqKn3Y2cXFlTP bGn91KH/dxEn/MDwWkP4Kf2BVj2ajRZjOEFzmgpZhT0ph0rKUmd9uwUmw9FSYlPy5d2V Y/9tWyd84uiLUCP/szz+QaOGJVgumL5lf+K84urnfABE3XRh8ybYydy0SCeXPui35pRp A4Dpv+V1y97vJl9mN8Hi1FT+PZYSoDNxtz++X462i5Uf96gsDEaDzjB6gcacLHmxccrZ U0yfjvQFKc0ap270Y1FOYTEdm8+n3vuy0EXF38MISif8MxX71P2J1Kti2wNTD6zyJ+Xx U3wA== X-Gm-Message-State: AOAM531m6z5l4JcqFNMdChENvkiZY0Ivplmc0YoGsOMsMyYU9vc9rcaI uCQzR9bgPTHcDxZEH0LQDLc= X-Google-Smtp-Source: ABdhPJwFKfgVn8dvuxZ38kkydxqedFEFWzNdLmdI1V6L/7zpM7qjAA84fEvolQzyU55LdEnD130aDQ== X-Received: by 2002:a5d:40cf:: with SMTP id b15mr3271179wrq.319.1593172369858; Fri, 26 Jun 2020 04:52:49 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id s8sm30438524wru.38.2020.06.26.04.52.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 04:52:49 -0700 (PDT) Date: Fri, 26 Jun 2020 11:52:47 +0000 From: Wei Liu To: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= Subject: Re: [PATCH v3 6/7] tools/libxl: add vmtrace_pt_size parameter Message-ID: <20200626115247.rbk74px33iapenzm@liuwe-devbox-debian-v2> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> <192922589.11444004.1592849546858.JavaMail.zimbra@cert.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <192922589.11444004.1592849546858.JavaMail.zimbra@cert.pl> User-Agent: NeoMutt/20180716 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Ian Jackson , George Dunlap , "Kang, Luwei" , Anthony PERARD , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 08:12:26PM +0200, Michał Leszczyński wrote: > Allow to specify the size of per-vCPU trace buffer upon > domain creation. This is zero by default (meaning: not enabled). > > Signed-off-by: Michal Leszczynski > --- > docs/man/xl.cfg.5.pod.in | 10 ++++++++++ > tools/golang/xenlight/helpers.gen.go | 2 ++ > tools/golang/xenlight/types.gen.go | 1 + > tools/libxl/libxl_create.c | 1 + > tools/libxl/libxl_types.idl | 2 ++ > tools/xl/xl_parse.c | 4 ++++ > 6 files changed, 20 insertions(+) > > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index 0532739c1f..78f434b722 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -278,6 +278,16 @@ memory=8096 will report significantly less memory available for use > than a system with maxmem=8096 memory=8096 due to the memory overhead > of having to track the unused pages. > > +=item B > + > +Specifies the size of processor trace buffer that would be allocated > +for each vCPU belonging to this domain. Disabled (i.e. B > +by default. This must be set to non-zero value in order to be able to > +use processor tracing features with this domain. > + > +B: The size value must be between 4 kB and 4 GB and it must > +be also a power of 2. > + Is this restriction enforced anywhere? I don't see it in this patch. > =back > > =head3 Guest Virtual NUMA Configuration > diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go > index 935d3bc50a..986ebbd681 100644 > --- a/tools/golang/xenlight/helpers.gen.go > +++ b/tools/golang/xenlight/helpers.gen.go > @@ -1117,6 +1117,7 @@ return fmt.Errorf("invalid union key '%v'", x.Type)} > x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version) > x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart) > x.Altp2M = Altp2MMode(xc.altp2m) > +x.VmtracePtSize = int(xc.vmtrace_pt_size) > > return nil} > > @@ -1592,6 +1593,7 @@ return fmt.Errorf("invalid union key '%v'", x.Type)} > xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion) > xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart) > xc.altp2m = C.libxl_altp2m_mode(x.Altp2M) > +xc.vmtrace_pt_size = C.int(x.VmtracePtSize) > > return nil > } > diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go > index 663c1e86b4..41ec7cdd32 100644 > --- a/tools/golang/xenlight/types.gen.go > +++ b/tools/golang/xenlight/types.gen.go > @@ -516,6 +516,7 @@ GicVersion GicVersion > Vuart VuartType > } > Altp2M Altp2MMode > +VmtracePtSize int > } > > type domainBuildInfoTypeUnion interface { > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > index 75862dc6ed..32204b83b0 100644 > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -608,6 +608,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, > .max_evtchn_port = b_info->event_channels, > .max_grant_frames = b_info->max_grant_frames, > .max_maptrack_frames = b_info->max_maptrack_frames, > + .vmtrace_pt_size = b_info->vmtrace_pt_size, > }; > > if (info->type != LIBXL_DOMAIN_TYPE_PV) { > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl > index 9d3f05f399..04c1704b72 100644 > --- a/tools/libxl/libxl_types.idl > +++ b/tools/libxl/libxl_types.idl > @@ -645,6 +645,8 @@ libxl_domain_build_info = Struct("domain_build_info",[ > # supported by x86 HVM and ARM support is planned. > ("altp2m", libxl_altp2m_mode), > > + ("vmtrace_pt_size", integer), When you add a new field please also add a LIBXL_HAVE macro to libxl.h. > + > ], dir=DIR_IN, > copy_deprecated_fn="libxl__domain_build_info_copy_deprecated", > ) > diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c > index 61b4ef7b7e..6ab98dda55 100644 > --- a/tools/xl/xl_parse.c > +++ b/tools/xl/xl_parse.c > @@ -1861,6 +1861,10 @@ void parse_config_data(const char *config_source, > } > } > > + if (!xlu_cfg_get_long(config, "vmtrace_pt_size", &l, 1)) { > + b_info->vmtrace_pt_size = l; > + } > + > if (!xlu_cfg_get_list(config, "ioports", &ioports, &num_ioports, 0)) { > b_info->num_ioports = num_ioports; > b_info->ioports = calloc(num_ioports, sizeof(*b_info->ioports)); > -- > 2.20.1 > > From xen-devel-bounces@lists.xenproject.org Fri Jun 26 11:56:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 11:56:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomyB-00030W-Qq; Fri, 26 Jun 2020 11:56:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jomyA-00030R-PJ for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 11:56:34 +0000 X-Inumbo-ID: 145e7dae-b7a4-11ea-82a7-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 145e7dae-b7a4-11ea-82a7-12813bfff9fa; Fri, 26 Jun 2020 11:56:33 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: tyUtj61jX4bdVkTmDqu4HNLaPYwMZVTG9iOeaExSB4PTRMOiBxVOWXovZ7JDwHlaVj5vztjmx3 VP/5BH1yS0/beGMKAZO1rofB2ZDAyRRDsS1XGuaFEKu56v3lcz3Z1bNEQwsSLZ4E1Ky6Wih1v0 NtjjQGxobMbtQDAG/trhQlP3/O46Uq5GUa2dGRirJ1JveWhWjWN5BLm00cVv0TlbFUidaOcfCv n8ZASLt+95h03tZsfBOf8qx2/KJjDMtXfHpU95nPM+eDnWZJgn3/px4Iz4JhywJSg/FhgOUB4I VH0= X-SBRS: 2.7 X-MesageID: 21024998 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,283,1589256000"; d="scan'208";a="21024998" Subject: Re: [PATCH for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Jan Beulich References: <20200608200259.17681-1-andrew.cooper3@citrix.com> <620e5f66-2802-24e7-bb6e-285e99f12975@suse.com> <6e353c85-b957-bdbe-6428-737b5bc8e801@citrix.com> From: Andrew Cooper Message-ID: Date: Fri, 26 Jun 2020 12:56:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Konrad Rzeszutek Wilk , Ross Lagerwall , Paul Durrant , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 15/06/2020 16:16, Jan Beulich wrote: >>>> @@ -58,6 +59,10 @@ int arch_livepatch_safety_check(void) >>>> >>>> int arch_livepatch_quiesce(void) >>>> { >>>> + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ >>>> + if ( cpu_has_xen_shstk ) >>>> + write_cr4(read_cr4() & ~X86_CR4_CET); >>>> + >>>> /* Disable WP to allow changes to read-only pages. */ >>>> write_cr0(read_cr0() & ~X86_CR0_WP); >>>> >>>> @@ -68,6 +73,29 @@ void arch_livepatch_revive(void) >>>> { >>>> /* Reinstate WP. */ >>>> write_cr0(read_cr0() | X86_CR0_WP); >>>> + >>>> + /* Clobber dirty bits and reinstate CET, if applicable. */ >>>> + if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) >>>> + { >>>> + unsigned long tmp; >>>> + >>>> + reset_virtual_region_perms(); >>>> + >>>> + write_cr4(read_cr4() | X86_CR4_CET); >>>> + >>>> + /* >>>> + * Fix up the return address on the shadow stack, which currently >>>> + * points at arch_livepatch_quiesce()'s caller. >>>> + * >>>> + * Note: this is somewhat fragile, and depends on both >>>> + * arch_livepatch_{quiesce,revive}() being called from the same >>>> + * function, which is currently the case. >>>> + */ >>>> + asm volatile ("rdsspq %[ssp];" >>>> + "wrssq %[addr], (%[ssp]);" >>>> + : [ssp] "=&r" (tmp) >>>> + : [addr] "r" (__builtin_return_address(0))); >>>> + } >>> To be safe against LTO I think this wants accompanying with making >>> both functions noinline. >> Hmm true. >> >>> As to the fragility - how about arch_livepatch_quiesce() returning >>> __builtin_return_address(0) to its caller, for passing into here >>> for verification? This would also make more noticeable that the >>> two should be be called from the same function (or else the "token" >>> would need passing further around). >> This I'm less certain about, as its fairly invasive to common code, just >> to bodge around something I don't expect to last very long into the 4.15 >> timeframe. > I don't see it being invasive - there's a new local variable needed > in both of apply_payload() and revert_payload(), and of course the > call sites would need adjustment. Exactly - the call site adjustment is what makes it invasive in common code, and all other architectures. Any getting this wrong will die with #CP[near ret] anyway. The only thing passing that value around would do is let you tweak the error message slightly before we crash out. >>>> @@ -91,6 +92,18 @@ void unregister_virtual_region(struct virtual_region *r) >>>> remove_virtual_region(r); >>>> } >>>> >>>> +void reset_virtual_region_perms(void) >>>> +{ >>>> + const struct virtual_region *region; >>>> + >>>> + rcu_read_lock(&rcu_virtual_region_lock); >>>> + list_for_each_entry_rcu( region, &virtual_region_list, list ) >>>> + modify_xen_mappings((unsigned long)region->start, >>>> + ROUNDUP((unsigned long)region->end, PAGE_SIZE), >>>> + PAGE_HYPERVISOR_RX); >>>> + rcu_read_unlock(&rcu_virtual_region_lock); >>>> +} >>> Doesn't this result in shattering the trailing (and currently still >>> only) 2Mb page mapping .text in the xen.efi case? >> Not any more or less than its already clobbered by this logic in the >> alternatives path, I think? > Not afaict, there we have > > if ( cpu_has_xen_shstk ) > modify_xen_mappings(XEN_VIRT_START + MB(2), > (unsigned long)&__2M_text_end, > PAGE_HYPERVISOR_RX); Hmm ok.  I'll make a note. >>> With the >>> expectation of the approach changing in 4.15 this may not need >>> addressing, but should imo be mentioned as a shortcoming in the >>> description then. >>> >>> Also - how about "restore" instead of "reset"? >> Why?  We're not passing some state sideways into the new mappings - >> we're resetting them to their expected values. > To me as a non-native speaker "reset" means more like some initial > state, whereas "restore" means more like "to some intended state". I feel that is a very subjective interpretation, but even if we go with it, the fact the function is void distinguishes the two. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 26 12:25:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 12:25:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jonPM-0005l5-5f; Fri, 26 Jun 2020 12:24:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jonPL-0005kz-09 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 12:24:39 +0000 X-Inumbo-ID: 00242e66-b7a8-11ea-82ac-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 00242e66-b7a8-11ea-82ac-12813bfff9fa; Fri, 26 Jun 2020 12:24:37 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: YNOnRxIV8JqcqbvcQC1FHLkfIUXUMG/6bZiLkUpJrtE9jva1jmW3K2EO4VI73Y2IxVPqkAjKhJ jtL8rsQ19CZ/b+Z7w2ZdkSVbiNbZZ1jTSJKHIe5oYQ+4oAR6WBi+oiZakSQ8JUF/SYfR+0OgMx +1x8/3Gk/hS5LPuCYKIFsf3ouruxDV2wRIIbX/wVQkm+OYW+AftlZffcy31jkCtrTXbNJjXQPw 4+g/11kMmhpW6Pon6tltLeD5urm0IkLVvN8hk2QWUNwDGTGl4kU+fe+xEDVBjPfkRzXKjL4c/o SPY= X-SBRS: 2.7 X-MesageID: 21820672 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,283,1589256000"; d="scan'208";a="21820672" From: Andrew Cooper To: Xen-devel Subject: [PATCH v2 for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks Date: Fri, 26 Jun 2020 13:24:08 +0100 Message-ID: <20200626122408.19151-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Konrad Rzeszutek Wilk , Andrew Cooper , Pawel Wieczorkiewicz , Paul Durrant , Ross Lagerwall , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Just like the alternatives infrastructure, the livepatch infrastructure disables CR0.WP to perform patching, which is not permitted with CET active. Modify arch_livepatch_{quiesce,revive}() to disable CET before disabling WP, and reset the dirty bits on all virtual regions before re-enabling CET. One complication is that arch_livepatch_revive() has to fix up the top of the shadow stack. This depends on the functions not being inlined, even under LTO. Another limitation is that reset_virtual_region_perms() may shatter the final superpage of .text depending on alignment. This logic, and its downsides, are temporary until the patching infrastructure can be adjusted to not use CR0.WP. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Konrad Rzeszutek Wilk CC: Ross Lagerwall CC: Pawel Wieczorkiewicz CC: Paul Durrant For 4.14. This is a bug in a 4.14 feature, with a very low risk to non-CET usecases. v2: * nolinline, and extra ifdefary * Expand comments --- xen/arch/x86/livepatch.c | 35 +++++++++++++++++++++++++++++++++-- xen/common/virtual_region.c | 15 +++++++++++++++ xen/include/xen/virtual_region.h | 1 + 3 files changed, 49 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c index 901fad96bf..49f0d902e5 100644 --- a/xen/arch/x86/livepatch.c +++ b/xen/arch/x86/livepatch.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include @@ -56,18 +57,48 @@ int arch_livepatch_safety_check(void) return -EBUSY; } -int arch_livepatch_quiesce(void) +int noinline arch_livepatch_quiesce(void) { + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ + if ( cpu_has_xen_shstk ) + write_cr4(read_cr4() & ~X86_CR4_CET); + /* Disable WP to allow changes to read-only pages. */ write_cr0(read_cr0() & ~X86_CR0_WP); return 0; } -void arch_livepatch_revive(void) +void noinline arch_livepatch_revive(void) { /* Reinstate WP. */ write_cr0(read_cr0() | X86_CR0_WP); + + /* Clobber dirty bits and reinstate CET, if applicable. */ + if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) + { + unsigned long tmp; + + reset_virtual_region_perms(); + + write_cr4(read_cr4() | X86_CR4_CET); + + /* + * Fix up the return address on the shadow stack, which currently + * points at arch_livepatch_quiesce()'s caller. + * + * Note: this is somewhat fragile, and depends on both + * arch_livepatch_{quiesce,revive}() being called from the same + * function, which is currently the case. + * + * Any error will result in Xen dying with #CP, and its too late to + * recover in any way. + */ + asm volatile ("rdsspq %[ssp];" + "wrssq %[addr], (%[ssp]);" + : [ssp] "=&r" (tmp) + : [addr] "r" (__builtin_return_address(0))); + } } int arch_livepatch_verify_func(const struct livepatch_func *func) diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c index aa23918bce..4fbc02e35a 100644 --- a/xen/common/virtual_region.c +++ b/xen/common/virtual_region.c @@ -4,6 +4,7 @@ #include #include +#include #include #include #include @@ -91,6 +92,20 @@ void unregister_virtual_region(struct virtual_region *r) remove_virtual_region(r); } +#if defined(CONFIG_LIVEPATCH) && defined(CONFIG_XEN_SHSTK) +void reset_virtual_region_perms(void) +{ + const struct virtual_region *region; + + rcu_read_lock(&rcu_virtual_region_lock); + list_for_each_entry_rcu( region, &virtual_region_list, list ) + modify_xen_mappings((unsigned long)region->start, + ROUNDUP((unsigned long)region->end, PAGE_SIZE), + PAGE_HYPERVISOR_RX); + rcu_read_unlock(&rcu_virtual_region_lock); +} +#endif + void __init unregister_init_virtual_region(void) { BUG_ON(system_state != SYS_STATE_active); diff --git a/xen/include/xen/virtual_region.h b/xen/include/xen/virtual_region.h index e5e58ed96b..ba408eb87a 100644 --- a/xen/include/xen/virtual_region.h +++ b/xen/include/xen/virtual_region.h @@ -33,6 +33,7 @@ void setup_virtual_regions(const struct exception_table_entry *start, void unregister_init_virtual_region(void); void register_virtual_region(struct virtual_region *r); void unregister_virtual_region(struct virtual_region *r); +void reset_virtual_region_perms(void); #endif /* __XEN_VIRTUAL_REGION_H__ */ -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:00:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:00:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jony8-0000Zj-Vx; Fri, 26 Jun 2020 13:00:36 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jony7-0000Ze-8Y for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:00:35 +0000 X-Inumbo-ID: 058afb5a-b7ad-11ea-82ba-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 058afb5a-b7ad-11ea-82ba-12813bfff9fa; Fri, 26 Jun 2020 13:00:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3C0EFAAC3; Fri, 26 Jun 2020 13:00:33 +0000 (UTC) Subject: Re: [PATCH for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Andrew Cooper References: <20200608200259.17681-1-andrew.cooper3@citrix.com> <620e5f66-2802-24e7-bb6e-285e99f12975@suse.com> <6e353c85-b957-bdbe-6428-737b5bc8e801@citrix.com> From: Jan Beulich Message-ID: <8c4159dc-45c8-51c2-4e30-5a17bfca87bb@suse.com> Date: Fri, 26 Jun 2020 15:00:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Konrad Rzeszutek Wilk , Ross Lagerwall , Paul Durrant , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 13:56, Andrew Cooper wrote: > On 15/06/2020 16:16, Jan Beulich wrote: >>>>> @@ -58,6 +59,10 @@ int arch_livepatch_safety_check(void) >>>>> >>>>> int arch_livepatch_quiesce(void) >>>>> { >>>>> + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ >>>>> + if ( cpu_has_xen_shstk ) >>>>> + write_cr4(read_cr4() & ~X86_CR4_CET); >>>>> + >>>>> /* Disable WP to allow changes to read-only pages. */ >>>>> write_cr0(read_cr0() & ~X86_CR0_WP); >>>>> >>>>> @@ -68,6 +73,29 @@ void arch_livepatch_revive(void) >>>>> { >>>>> /* Reinstate WP. */ >>>>> write_cr0(read_cr0() | X86_CR0_WP); >>>>> + >>>>> + /* Clobber dirty bits and reinstate CET, if applicable. */ >>>>> + if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) >>>>> + { >>>>> + unsigned long tmp; >>>>> + >>>>> + reset_virtual_region_perms(); >>>>> + >>>>> + write_cr4(read_cr4() | X86_CR4_CET); >>>>> + >>>>> + /* >>>>> + * Fix up the return address on the shadow stack, which currently >>>>> + * points at arch_livepatch_quiesce()'s caller. >>>>> + * >>>>> + * Note: this is somewhat fragile, and depends on both >>>>> + * arch_livepatch_{quiesce,revive}() being called from the same >>>>> + * function, which is currently the case. >>>>> + */ >>>>> + asm volatile ("rdsspq %[ssp];" >>>>> + "wrssq %[addr], (%[ssp]);" >>>>> + : [ssp] "=&r" (tmp) >>>>> + : [addr] "r" (__builtin_return_address(0))); >>>>> + } >>>> To be safe against LTO I think this wants accompanying with making >>>> both functions noinline. >>> Hmm true. >>> >>>> As to the fragility - how about arch_livepatch_quiesce() returning >>>> __builtin_return_address(0) to its caller, for passing into here >>>> for verification? This would also make more noticeable that the >>>> two should be be called from the same function (or else the "token" >>>> would need passing further around). >>> This I'm less certain about, as its fairly invasive to common code, just >>> to bodge around something I don't expect to last very long into the 4.15 >>> timeframe. >> I don't see it being invasive - there's a new local variable needed >> in both of apply_payload() and revert_payload(), and of course the >> call sites would need adjustment. > > Exactly - the call site adjustment is what makes it invasive in common > code, and all other architectures. > > Any getting this wrong will die with #CP[near ret] anyway. > > The only thing passing that value around would do is let you tweak the > error message slightly before we crash out. Well, okay - I'm not a maintainer of that part of the code anyway. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:08:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:08:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joo5L-0000m6-Oi; Fri, 26 Jun 2020 13:08:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joo5L-0000m1-1c for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:08:03 +0000 X-Inumbo-ID: 1055a0f3-b7ae-11ea-82ba-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1055a0f3-b7ae-11ea-82ba-12813bfff9fa; Fri, 26 Jun 2020 13:08:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8252EAC85; Fri, 26 Jun 2020 13:08:01 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14] x86/msr: Disallow access to Processor Trace MSRs To: Andrew Cooper References: <20200626112937.919-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: Date: Fri, 26 Jun 2020 15:08:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626112937.919-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 13:29, Andrew Cooper wrote: > We do not expose the feature to guests, so should disallow access to the > respective MSRs. For simplicity, drop the entire block of MSRs, not just the > subset which have been specified thus far. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:11:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:11:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joo8Q-0001Xx-7A; Fri, 26 Jun 2020 13:11:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joo8O-0001Xr-Td for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:11:12 +0000 X-Inumbo-ID: 81c5d716-b7ae-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 81c5d716-b7ae-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 13:11:12 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 35D0FAC85; Fri, 26 Jun 2020 13:11:11 +0000 (UTC) Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , paul@xen.org, Andrew Cooper References: <20200625113041.81507-1-roger.pau@citrix.com> <551387c6-f45d-bf6c-a41e-b0920425db9f@xen.org> <20200626100745.GB735@Air-de-Roger> From: Jan Beulich Message-ID: <5586cae5-8929-0c53-7a35-5dd6116c77c2@suse.com> Date: Fri, 26 Jun 2020 15:11:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626100745.GB735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 12:07, Roger Pau Monné wrote: > On Fri, Jun 26, 2020 at 10:38:11AM +0100, Julien Grall wrote: >> Hi Roger, >> >> Sorry I didn't manage to answer to your question before you sent v3. >> >> On 25/06/2020 12:30, Roger Pau Monne wrote: >>> diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h >>> index ab1aae5c90..7ae0543885 100644 >>> --- a/xen/include/asm-arm/flushtlb.h >>> +++ b/xen/include/asm-arm/flushtlb.h >>> @@ -27,6 +27,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) >>> /* Flush specified CPUs' TLBs */ >>> void flush_tlb_mask(const cpumask_t *mask); >>> +#define flush_tlb_mask_sync flush_tlb_mask >> >> Dropping the parameter 'sync' from filtered_flush_tlb_mask() is a nice >> improvement, but it unfortunately doesn't fully address my concern. >> >> After this patch there is exactly one use of flush_tlb_mask() in common code >> (see grant_table.c). But without looking at the x86 code, it is not clear >> why this requires a different flush compare to the two other sites. > > It's not dealing with page allocation or page type changes directly, > and hence doesn't need to use an IPI in order to prevent races with > spurious_page_fault. > >> IOW, if I want to modify the common code in the future, how do I know which >> flush to call? > > Unless you modify one of the specific areas mentioned above (page > allocation or page type changes) you should use flush_tlb_mask. > > This is not ideal, and my aim will be to be able to use the assisted > flush everywhere if possible, so I would really like to get rid of the > interrupt disabling done in spurious_page_fault and this model where > x86 relies on blocking interrupts in order to prevent page type > changes or page freeing. > > Such change however doesn't feel appropriate for a release freeze > period, and hence went with something smaller that restores the > previous behavior. Another option is to just disable assisted flushes > for the time being and re-enable them when a suitable solution is > found. As I can understand Julien's concern, maybe this would indeed be the better approach for now? Andrew, Paul - thoughts? Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:13:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:13:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooAW-0001fU-K2; Fri, 26 Jun 2020 13:13:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooAV-0001fP-M4 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:13:23 +0000 X-Inumbo-ID: cfe6f8f8-b7ae-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cfe6f8f8-b7ae-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 13:13:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ELwGTR9ZAfxCOcjiNvgl/LdmT9KK6TVt0zj8TzDIbQY=; b=Wr80gBN6BrBPkfJz6xuNEdzLx vmiBc9SDm0xzTeoCZx2REpbgXY0xPORNJk3MbrQ4I+KU272O5U7OoUeLsQ8fzL1Em2jPFz5o3YlT0 k47PhEIGOlq4PlNqTGX3o7pO15UNbndJ16Z0tOmlZirnGKXTGXUduXNXOJBZ0rs5d5djA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooAU-0004EN-Ig; Fri, 26 Jun 2020 13:13:22 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jooAT-0006cJ-VF; Fri, 26 Jun 2020 13:13:22 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jooAT-00035B-Uf; Fri, 26 Jun 2020 13:13:21 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151376: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=d3688bf60f798074bf38d712a3e15c88cfb81ed4 X-Osstest-Versions-That: xen=e4d2207165b379ec13c8b512936f63982af62d13 From: osstest service owner Date: Fri, 26 Jun 2020 13:13:21 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151376 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151376/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen d3688bf60f798074bf38d712a3e15c88cfb81ed4 baseline version: xen e4d2207165b379ec13c8b512936f63982af62d13 Last test of basis 151356 2020-06-25 08:07:44 Z 1 days Testing same since 151376 2020-06-26 11:00:34 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Jan Beulich Jason Andryuk jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git e4d2207165..d3688bf60f d3688bf60f798074bf38d712a3e15c88cfb81ed4 -> smoke From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:14:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:14:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooBh-0001lE-VC; Fri, 26 Jun 2020 13:14:37 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooBg-0001l6-HX for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:14:36 +0000 X-Inumbo-ID: fb163750-b7ae-11ea-82bb-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fb163750-b7ae-11ea-82bb-12813bfff9fa; Fri, 26 Jun 2020 13:14:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id AC611AC85; Fri, 26 Jun 2020 13:14:34 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Andrew Cooper References: <20200626122408.19151-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: Date: Fri, 26 Jun 2020 15:14:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626122408.19151-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Konrad Rzeszutek Wilk , Ross Lagerwall , Paul Durrant , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 14:24, Andrew Cooper wrote: > Just like the alternatives infrastructure, the livepatch infrastructure > disables CR0.WP to perform patching, which is not permitted with CET active. > > Modify arch_livepatch_{quiesce,revive}() to disable CET before disabling WP, > and reset the dirty bits on all virtual regions before re-enabling CET. > > One complication is that arch_livepatch_revive() has to fix up the top of the > shadow stack. This depends on the functions not being inlined, even under > LTO. Another limitation is that reset_virtual_region_perms() may shatter the > final superpage of .text depending on alignment. > > This logic, and its downsides, are temporary until the patching infrastructure > can be adjusted to not use CR0.WP. In particular on this basis ... > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:21:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:21:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooI4-0002bD-MJ; Fri, 26 Jun 2020 13:21:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooI3-0002b8-3c for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:21:11 +0000 X-Inumbo-ID: e644d10a-b7af-11ea-8496-bc764e2007e4 Received: from mail-ej1-x642.google.com (unknown [2a00:1450:4864:20::642]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e644d10a-b7af-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 13:21:10 +0000 (UTC) Received: by mail-ej1-x642.google.com with SMTP id w6so9358561ejq.6 for ; Fri, 26 Jun 2020 06:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=/glpYqJjB3H2gbyEz5BKgq+AYHbboaAwV4vLceAFtB4=; b=vAGlhYEvJ7e7GUl4o+gtTlD/9/x9CXnRaO34qvwE7B+SEMDFHxP+w/5wJPHP1etBaG TL/5rQkf0CTPZygYItAjWYNKzG9ETo1fjcn6LPHc8igHNBn+fjzXVxc09oFc4x0JVBVf IhkKyyHdbe5Q1vaTv3e/0KAA+fWkZX1PjJHiNE+ipQKX39YdUuDxiB7eyLYsHtsVri3V D5hRvYztim6i6yHpwJdTqwNPC2cKfqpvx9ETS57aO+tji0HA68M6we7eEnE0GLtCpZ9X TivDy3ly+fr88iQAn6l2lpjBJLp/LbnfQAsWgo5r4sgcoL6Vsf5B8sIKuwzN84K5zV5G Wkxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=/glpYqJjB3H2gbyEz5BKgq+AYHbboaAwV4vLceAFtB4=; b=ZWCIt8YxfhdzEuG3qsnRXZex5vnRzS3+gOmqbrPkRc3ncaAvVqLgOUp7yLLJuAlmca 0VIB7Gz4+xqPedoZY6vh4A4U/XkpItJ/UbaaANu/9CfLBSdsWkslsktdLk4MSpqygWoX US3+eV9v4RaiKR6cyNIMLk/yK0ztLbbW+eLndb95dGR0TnuQbbatGy5YKEZSjEci44iU 8Zhz3L/wwDualLEiHyMedzGjq0vju20PbLdOv3nn7QnL+x0W78Isq5HOSUyP6ofWLLvZ 892ZIKBsr7ZVUjIzo72ptxu1IDjwqWRx9RRyHWZcE+Lj4d7hjagmXXQxMHA0IhH38b6p pZew== X-Gm-Message-State: AOAM530Ue+dHiducBX/IllBStdj6OPUlUum5eINskh4s9g7DgTwiQWYF 78BDPLTanBQY3khuWTq5u+s= X-Google-Smtp-Source: ABdhPJytLH5i9SYvmviv3AECVdSnQPng3uZgGMAFtlWiHOD3uqyTvmxsscxR6SW1SzoYh74iSM9+Lg== X-Received: by 2002:a17:906:c53:: with SMTP id t19mr2677866ejf.143.1593177669527; Fri, 26 Jun 2020 06:21:09 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id f17sm6806116ejr.71.2020.06.26.06.21.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 06:21:09 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= , "'Andrew Cooper'" References: <20200625113041.81507-1-roger.pau@citrix.com> <551387c6-f45d-bf6c-a41e-b0920425db9f@xen.org> <20200626100745.GB735@Air-de-Roger> <5586cae5-8929-0c53-7a35-5dd6116c77c2@suse.com> In-Reply-To: <5586cae5-8929-0c53-7a35-5dd6116c77c2@suse.com> Subject: RE: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage Date: Fri, 26 Jun 2020 14:21:07 +0100 Message-ID: <000b01d64bbc$a7822f30$f6868d90$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQNtfAT0oM7SsXX048OvW1r6oGCP7gGm0OfKAaiO/jIBsc/uaKWUdwhA X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Ian Jackson' , 'George Dunlap' , xen-devel@lists.xenproject.org, 'Volodymyr Babchuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 26 June 2020 14:11 > To: Roger Pau Monn=C3=A9 ; paul@xen.org; Andrew = Cooper > Cc: Julien Grall ; xen-devel@lists.xenproject.org; Wei = Liu ; George Dunlap > ; Ian Jackson ; = Stefano Stabellini > ; Volodymyr Babchuk = > Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage >=20 > On 26.06.2020 12:07, Roger Pau Monn=C3=A9 wrote: > > On Fri, Jun 26, 2020 at 10:38:11AM +0100, Julien Grall wrote: > >> Hi Roger, > >> > >> Sorry I didn't manage to answer to your question before you sent = v3. > >> > >> On 25/06/2020 12:30, Roger Pau Monne wrote: > >>> diff --git a/xen/include/asm-arm/flushtlb.h = b/xen/include/asm-arm/flushtlb.h > >>> index ab1aae5c90..7ae0543885 100644 > >>> --- a/xen/include/asm-arm/flushtlb.h > >>> +++ b/xen/include/asm-arm/flushtlb.h > >>> @@ -27,6 +27,7 @@ static inline void = page_set_tlbflush_timestamp(struct page_info *page) > >>> /* Flush specified CPUs' TLBs */ > >>> void flush_tlb_mask(const cpumask_t *mask); > >>> +#define flush_tlb_mask_sync flush_tlb_mask > >> > >> Dropping the parameter 'sync' from filtered_flush_tlb_mask() is a = nice > >> improvement, but it unfortunately doesn't fully address my concern. > >> > >> After this patch there is exactly one use of flush_tlb_mask() in = common code > >> (see grant_table.c). But without looking at the x86 code, it is not = clear > >> why this requires a different flush compare to the two other sites. > > > > It's not dealing with page allocation or page type changes directly, > > and hence doesn't need to use an IPI in order to prevent races with > > spurious_page_fault. > > > >> IOW, if I want to modify the common code in the future, how do I = know which > >> flush to call? > > > > Unless you modify one of the specific areas mentioned above (page > > allocation or page type changes) you should use flush_tlb_mask. > > > > This is not ideal, and my aim will be to be able to use the assisted > > flush everywhere if possible, so I would really like to get rid of = the > > interrupt disabling done in spurious_page_fault and this model where > > x86 relies on blocking interrupts in order to prevent page type > > changes or page freeing. > > > > Such change however doesn't feel appropriate for a release freeze > > period, and hence went with something smaller that restores the > > previous behavior. Another option is to just disable assisted = flushes > > for the time being and re-enable them when a suitable solution is > > found. >=20 > As I can understand Julien's concern, maybe this would indeed be > the better approach for now? Andrew, Paul - thoughts? >=20 Julien's concern seems to be about long term usage whereas IIUC this = patch does fix the issue at hand, so can we put this patch in now on the = basis that Roger will do the re-work described after 4.14 (which I think = will address Julien's concern)? Paul > Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:22:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:22:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooIq-0002f9-3e; Fri, 26 Jun 2020 13:22:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooIp-0002f3-7n for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:21:59 +0000 X-Inumbo-ID: 02bca416-b7b0-11ea-bca7-bc764e2007e4 Received: from mail-ej1-x635.google.com (unknown [2a00:1450:4864:20::635]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 02bca416-b7b0-11ea-bca7-bc764e2007e4; Fri, 26 Jun 2020 13:21:58 +0000 (UTC) Received: by mail-ej1-x635.google.com with SMTP id a1so9326719ejg.12 for ; Fri, 26 Jun 2020 06:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=35nElVfO4ruHe/my6OtnItaNY19Zq7OZe2sq8RVEalA=; b=b9Q7/sDzyTSOfvmKO2nLSsd19jiQxMb9W6PcT7xVJG2j2pTPdQuwBCOoaYtS0yVdDL tjC8NlkDeBmx3L0p97lu/sp3iw1r/lJHgU2+kqYCSBmVHfd7XBnhIiiQxwOLb7Uo1yv3 b7LJZ0dJHvMQUmOWanKOyWnCaYGmW8kTnuqHqQ/axyhca6FHPg61B9KiClpO37x4ZifD c5/YwsqDELmlEc54ykYCeAtKnNJsO9HDpMJEuv6ZIOMLdr5Mohx+xMQWlIaywNtZNDZu qXdo0ma0whoHqahnyysiGjBUTECvYU1d76YIQMlgZrMKGMkXtPgzUbs8oTdhqkpX3r8D mUbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=35nElVfO4ruHe/my6OtnItaNY19Zq7OZe2sq8RVEalA=; b=g4MozpBTmsvqXab9/zjHNO3GrsFWn19TnGOM5YzodrPV3DcCreXI7MJ/c46byVuMBy otmhjI7hs3NUSZ6CUzrxiTUJDbRe35OU5h6/nwLuokng6163zASa7ryBQrH7f/LzJ7LJ /KbWsXVW3jg1TaD1axcSxbYEkMkrAt16EfZLcpArXpTh9Gnt8RuJ2HK+tiAAyqt05wAG Lt9Wgbj+ErbwUtzdgnzvPYtaWbcgSug9z5mSDexVefvU3bTlIqBHECg1W8Z188MuoeoQ 8lHaMngmXDBy5s3+ZovNd6vrA0BikRFxfhPLwMolskYzDNybiisCkIFDdj972Fcrhd2k LF8Q== X-Gm-Message-State: AOAM531VV2QZj7vIa+AYJ/WqnZfC/CtNgKy3eRCjfcDGQayTrvnz8AgG +gDV8WXgZ7+uM8ZoeKoz+1g= X-Google-Smtp-Source: ABdhPJwKed8mGY3+lJBzy831qAcDxGDZNnONnWWAIIyVanWbqwreTXOLPZ93/1rmppbN2vQUrUPp5Q== X-Received: by 2002:a17:907:b03:: with SMTP id h3mr2665047ejl.367.1593177717324; Fri, 26 Jun 2020 06:21:57 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id bz14sm18770473ejc.100.2020.06.26.06.21.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 06:21:56 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , "'Andrew Cooper'" References: <20200626122408.19151-1-andrew.cooper3@citrix.com> In-Reply-To: Subject: RE: [PATCH v2 for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks Date: Fri, 26 Jun 2020 14:21:55 +0100 Message-ID: <000c01d64bbc$c3f75730$4be60590$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFni0xM86WbiVrPLWulsmYIT6MTPgHnaHqAqbknfuA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Wei Liu' , 'Konrad Rzeszutek Wilk' , 'Ross Lagerwall' , 'Pawel Wieczorkiewicz' , 'Xen-devel' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Jan Beulich > Sent: 26 June 2020 14:15 > To: Andrew Cooper > Cc: Xen-devel ; Wei Liu ; = Roger Pau Monn=C3=A9 > ; Konrad Rzeszutek Wilk = ; Ross Lagerwall > ; Pawel Wieczorkiewicz ; = Paul Durrant > Subject: Re: [PATCH v2 for-4.14] x86/livepatch: Make livepatching = compatible with CET Shadow Stacks >=20 > On 26.06.2020 14:24, Andrew Cooper wrote: > > Just like the alternatives infrastructure, the livepatch = infrastructure > > disables CR0.WP to perform patching, which is not permitted with CET = active. > > > > Modify arch_livepatch_{quiesce,revive}() to disable CET before = disabling WP, > > and reset the dirty bits on all virtual regions before re-enabling = CET. > > > > One complication is that arch_livepatch_revive() has to fix up the = top of the > > shadow stack. This depends on the functions not being inlined, even = under > > LTO. Another limitation is that reset_virtual_region_perms() may = shatter the > > final superpage of .text depending on alignment. > > > > This logic, and its downsides, are temporary until the patching = infrastructure > > can be adjusted to not use CR0.WP. >=20 > In particular on this basis ... >=20 > > Signed-off-by: Andrew Cooper >=20 > Reviewed-by: Jan Beulich Release-acked-by: Paul Durrant >=20 > Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:25:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:25:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooLh-0002qa-Iv; Fri, 26 Jun 2020 13:24:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooLg-0002qT-H4 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:24:56 +0000 X-Inumbo-ID: 6c715640-b7b0-11ea-82bb-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 6c715640-b7b0-11ea-82bb-12813bfff9fa; Fri, 26 Jun 2020 13:24:55 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: XXeK9ztN8Q4G5Q+vpgZIaNeqdGGaj44a4E3h5jgkHVJ69nRZwP2rEGKj/Qw0GF6TwZpBcuZvOk v1nqrrF9RuSwOtsJJYDbBycB6DiLEQnEi8ZPWojZ2TFDeGKZoGy7DsPzAzMOyE01qLkrmKkViI 9yTgtnz6hSM1FFEcZyQ0/VNNIXT08JgEQMHv1dAaxZs0fHmfUPyRs6BctieVJxg9vMC5Kq/9g/ OX8p6nohivV5opyEadARG0mzBACytNklgWVRoyJqoQ66p6AwGjTXjlfP3Wjvgk6i4bujh1XOK8 P+I= X-SBRS: 2.7 X-MesageID: 21032529 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,283,1589256000"; d="scan'208";a="21032529" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit Message-ID: <24309.63267.596889.412833@mariner.uk.xensource.com> Date: Fri, 26 Jun 2020 14:24:51 +0100 To: Wei Liu Subject: Re: [PATCH v3 7/7] tools/proctrace: add proctrace tool In-Reply-To: <20200626114824.mt2zsbwdbed5dtwj@liuwe-devbox-debian-v2> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> <1786138246.11444015.1592849576272.JavaMail.zimbra@cert.pl> <20200626114824.mt2zsbwdbed5dtwj@liuwe-devbox-debian-v2> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , =?iso-8859-2?Q?Micha=B3_Leszczy=F1ski?= , Tamas K Lengyel , "Kang, Luwei" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Wei Liu writes ("Re: [PATCH v3 7/7] tools/proctrace: add proctrace tool"): > On Mon, Jun 22, 2020 at 08:12:56PM +0200, Micha Leszczyski wrote: > > Add an demonstration tool that uses xc_vmtrace_* calls in order > > to manage external IPT monitoring for DomU. ... > > + if (rc) { > > + fprintf(stderr, "Failed to call xc_vmtrace_pt_disable\n"); > > + return 1; > > + } > > + > > You should close fmem and xc in the exit path. Thanks for reviewing this. I agree with your comments. But I disagree with this one. This is in main(). When the program exits, the xc handle and memory mappings will go away as the kernel tears down the process. Leaving out this kind of cleanup in standalone command-line programs is fine, I think. It can make the code simpler - and it avoids the risk of doing it wrong, which can turn errors into crashes. Ian. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:40:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:40:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooan-0004Rc-UL; Fri, 26 Jun 2020 13:40:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jooam-0004RX-Or for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:40:32 +0000 X-Inumbo-ID: 994cb92a-b7b2-11ea-82bc-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 994cb92a-b7b2-11ea-82bc-12813bfff9fa; Fri, 26 Jun 2020 13:40:31 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0B11AAC85; Fri, 26 Jun 2020 13:40:30 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> <20200625090552.GW735@Air-de-Roger> <20200625161002.GZ735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Fri, 26 Jun 2020 15:40:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200625161002.GZ735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 25.06.2020 18:10, Roger Pau Monné wrote: > On Thu, Jun 25, 2020 at 11:05:52AM +0200, Roger Pau Monné wrote: >> On Wed, Jun 24, 2020 at 04:01:44PM +0200, Jan Beulich wrote: >>> On 24.06.2020 15:41, Julien Grall wrote: >>>> On 24/06/2020 11:12, Jan Beulich wrote: >>>>> On 23.06.2020 19:26, Roger Pau Monné wrote: >>>>>> I'm confused. Couldn't we switch from uint64_aligned_t to plain >>>>>> uint64_t (like it's currently on the Linux headers), and then use the >>>>>> compat layer in Xen to handle the size difference when called from >>>>>> 32bit environments? >>>>> >>>>> And which size would we use there? The old or the new one (breaking >>>>> future or existing callers respectively)? Meanwhile I think that if >>>>> this indeed needs to not be tools-only (which I still question), >>>> >>>> I think we now agreed on a subthread that the kernel needs to know the >>>> layout of the hypercall. >>>> >>>>> then our only possible route is to add explicit padding for the >>>>> 32-bit case alongside the change you're already making. >>>> >>>> AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make >>>> incompatible the two incompatible? >>> >>> In principle yes. But they're putting the structure instance on the >>> stack, so there's not risk from Xen reading 4 bytes too many. I'd >>> prefer keeping the interface as is (i.e. with the previously >>> implicit padding made explicit) to avoid risking to break other >>> possible callers. But that's just my view on it, anyway ... >> >> Adding the padding is cleaner because we don't need any compat stuff >> in order to access the structure from the caller, and we also keep the >> original layout currently present on Xen headers. >> >> I can prepare a fix for the Linux kernel, if this approach is fine. > > So I went over this, and I'm not sure the point of adding the padding > field at the end of the structure for 32bit x86. > > The current situation is the following: > > - Linux will use a struct on 32bit x86 that doesn't have the 4byte > padding at the end. > - Xen will copy 4bytes of garbage in that case, since the struct on > Linux is allocated on the stack. > > So I suggest we take the approach found on this patch, that is remove > the 8byte alignment from the frame field, which will in turn remove > 4bytes of padding from the tail of the structure on 32bit x86. > > That would leave the following scenario: > > - The struct layout in Linux headers would be correct. > - Xen already handles the struct size difference on x86 32bit vs > 64bit, as the compat layer is currently doing the copy in > compat_memory_op taking into account the size of the compat > structure. Hmm, I didn't even notice this until now - it looks to do so indeed, but apparently because of a bug: The original uint64_aligned_t gets translated to mere uint64_t in the compat header, whereas it should have been retained. This means that my concern of ... > - Removing the padding will work for all use cases: Linux will > already be using the correct layout on x86 32bits, so no change > will be required there. Any consumers using the tail padded > structure will continue to work without issues, as Xen simply won't > copy the tailing 4bytes. ... code using the new definition then potentially not working correctly on 4.13, at least on versions not having this backported, was not actually true. I'll try to sort out this other bug then ... > So I think the solution proposed in this patch is the correct one: > switch uint64_aligned_t to uint64_t, no tail padding added on x86 > 32bits. I will adjust the commit message and resubmit if that's fine. I think it is indeed. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:58:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:58:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joos9-0005Rs-FH; Fri, 26 Jun 2020 13:58:29 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joos7-0005Rn-Uy for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:58:27 +0000 X-Inumbo-ID: 1bd7194a-b7b5-11ea-82bf-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1bd7194a-b7b5-11ea-82bf-12813bfff9fa; Fri, 26 Jun 2020 13:58:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cmmX2V517G5NWSLWeeRRM3CDdNr+ggcg4bXhX6qGFLU=; b=j8y+xs0EXFMTbefCaxO1qYLVWl nMetC89gfStWYuzP6bTac24k53z76uLZ4pcc7E0f9SyYyyG8IRe+am8ttPfRha0YZWXxKRSSLyAxx IupQXou3alRzLhZ1i1LyhqupP1H2B34smzHvFQnTy9NnbAvzUlzmUbCPNGC/gwlMqlDE=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joos4-00052X-A2; Fri, 26 Jun 2020 13:58:24 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1joos4-0002v9-2w; Fri, 26 Jun 2020 13:58:24 +0000 Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage To: paul@xen.org, 'Jan Beulich' , =?UTF-8?B?J1JvZ2VyIFBhdSBNb25uw6kn?= , 'Andrew Cooper' References: <20200625113041.81507-1-roger.pau@citrix.com> <551387c6-f45d-bf6c-a41e-b0920425db9f@xen.org> <20200626100745.GB735@Air-de-Roger> <5586cae5-8929-0c53-7a35-5dd6116c77c2@suse.com> <000b01d64bbc$a7822f30$f6868d90$@xen.org> From: Julien Grall Message-ID: Date: Fri, 26 Jun 2020 14:58:21 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <000b01d64bbc$a7822f30$f6868d90$@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Stefano Stabellini' , 'Wei Liu' , 'Ian Jackson' , 'George Dunlap' , xen-devel@lists.xenproject.org, 'Volodymyr Babchuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26/06/2020 14:21, Paul Durrant wrote: >> -----Original Message----- >> From: Jan Beulich >> Sent: 26 June 2020 14:11 >> To: Roger Pau Monné ; paul@xen.org; Andrew Cooper >> Cc: Julien Grall ; xen-devel@lists.xenproject.org; Wei Liu ; George Dunlap >> ; Ian Jackson ; Stefano Stabellini >> ; Volodymyr Babchuk >> Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage >> >> On 26.06.2020 12:07, Roger Pau Monné wrote: >>> On Fri, Jun 26, 2020 at 10:38:11AM +0100, Julien Grall wrote: >>>> Hi Roger, >>>> >>>> Sorry I didn't manage to answer to your question before you sent v3. >>>> >>>> On 25/06/2020 12:30, Roger Pau Monne wrote: >>>>> diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h >>>>> index ab1aae5c90..7ae0543885 100644 >>>>> --- a/xen/include/asm-arm/flushtlb.h >>>>> +++ b/xen/include/asm-arm/flushtlb.h >>>>> @@ -27,6 +27,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) >>>>> /* Flush specified CPUs' TLBs */ >>>>> void flush_tlb_mask(const cpumask_t *mask); >>>>> +#define flush_tlb_mask_sync flush_tlb_mask >>>> >>>> Dropping the parameter 'sync' from filtered_flush_tlb_mask() is a nice >>>> improvement, but it unfortunately doesn't fully address my concern. >>>> >>>> After this patch there is exactly one use of flush_tlb_mask() in common code >>>> (see grant_table.c). But without looking at the x86 code, it is not clear >>>> why this requires a different flush compare to the two other sites. >>> >>> It's not dealing with page allocation or page type changes directly, >>> and hence doesn't need to use an IPI in order to prevent races with >>> spurious_page_fault. >>> >>>> IOW, if I want to modify the common code in the future, how do I know which >>>> flush to call? >>> >>> Unless you modify one of the specific areas mentioned above (page >>> allocation or page type changes) you should use flush_tlb_mask. >>> >>> This is not ideal, and my aim will be to be able to use the assisted >>> flush everywhere if possible, so I would really like to get rid of the >>> interrupt disabling done in spurious_page_fault and this model where >>> x86 relies on blocking interrupts in order to prevent page type >>> changes or page freeing. >>> >>> Such change however doesn't feel appropriate for a release freeze >>> period, and hence went with something smaller that restores the >>> previous behavior. Another option is to just disable assisted flushes >>> for the time being and re-enable them when a suitable solution is >>> found. >> >> As I can understand Julien's concern, maybe this would indeed be >> the better approach for now? Andrew, Paul - thoughts? >> > > Julien's concern seems to be about long term usage whereas IIUC this patch does fix the issue at hand, so can we put this patch in now on the basis that Roger will do the re-work described after 4.14 (which I think will address Julien's concern)? Bear in mind that while this may be properly fixed in the next release, the hack will stay forever in Xen 4.14. While I understand that disabling assisted flush is going to have a performance impact, we also need to make sure the interface make senses. From a generic perspective, a TLB flush should have the exact same guarantee regardless where we call it in common/. So I would still strongly prefer if we have a single helper. Is it possible to consider to replace all the flush_tlb_mask() in common code by arch_flush_tlb_mask()? On Arm, this would just be a rename. On x86, this would be an alias to flush_tlb_mask_sync()? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 26 13:59:49 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 13:59:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jootQ-0005Wg-QB; Fri, 26 Jun 2020 13:59:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jootP-0005WN-Jd for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 13:59:47 +0000 X-Inumbo-ID: 486696a2-b7b5-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 486696a2-b7b5-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 13:59:42 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ZNuWgLPMMUTnT0OoOhqZyb3JoJIG4atSQTUbivGxxO8y6N5ftTaM2IC3OKvawKfbyOdYBUT+Ri VZ8aIBxgoKJ0xkn5Zb+oZjfAORb2OpFEOjOULa7tD2k4O2tyvgfuK17h1390SYsa0Lbeu92U00 rWBuRMBBa8kJZBhBVH/fkby60Dec9XVP2OyUo1gol1dc24ehy0We2/nTKTnVEOxgDNjmL3Inrp ftPbM7NGjyAznR4JdRHYp24pTHpMaqFrP+iJ+yhbkIgs5EjkoqO0vbdubxrTEGtJGFH939Bp8G QA4= X-SBRS: 2.7 X-MesageID: 21369468 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,283,1589256000"; d="scan'208";a="21369468" Subject: Re: [PATCH v2 for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Andrew Cooper , Xen-devel References: <20200626122408.19151-1-andrew.cooper3@citrix.com> From: Ross Lagerwall Message-ID: <4bd8ab3e-37d0-fde9-10a3-b6b2f9ca4da6@citrix.com> Date: Fri, 26 Jun 2020 14:59:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626122408.19151-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Konrad Rzeszutek Wilk , Pawel Wieczorkiewicz , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-26 13:24, Andrew Cooper wrote: > Just like the alternatives infrastructure, the livepatch infrastructure > disables CR0.WP to perform patching, which is not permitted with CET active. > > Modify arch_livepatch_{quiesce,revive}() to disable CET before disabling WP, > and reset the dirty bits on all virtual regions before re-enabling CET. > > One complication is that arch_livepatch_revive() has to fix up the top of the > shadow stack. This depends on the functions not being inlined, even under > LTO. Another limitation is that reset_virtual_region_perms() may shatter the > final superpage of .text depending on alignment. > > This logic, and its downsides, are temporary until the patching infrastructure > can be adjusted to not use CR0.WP. > > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monné > CC: Konrad Rzeszutek Wilk > CC: Ross Lagerwall > CC: Pawel Wieczorkiewicz > CC: Paul Durrant > > For 4.14. This is a bug in a 4.14 feature, with a very low risk to non-CET > usecases. > > v2: > * nolinline, and extra ifdefary > * Expand comments > --- > xen/arch/x86/livepatch.c | 35 +++++++++++++++++++++++++++++++++-- > xen/common/virtual_region.c | 15 +++++++++++++++ > xen/include/xen/virtual_region.h | 1 + > 3 files changed, 49 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c > index 901fad96bf..49f0d902e5 100644 > --- a/xen/arch/x86/livepatch.c > +++ b/xen/arch/x86/livepatch.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -56,18 +57,48 @@ int arch_livepatch_safety_check(void) > return -EBUSY; > } > > -int arch_livepatch_quiesce(void) > +int noinline arch_livepatch_quiesce(void) > { > + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ > + if ( cpu_has_xen_shstk ) Should this be: if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) to match arch_livepatch_revive? Ross From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:17:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:17:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopAB-0007GE-EJ; Fri, 26 Jun 2020 14:17:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopAA-0007G9-6F for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:17:06 +0000 X-Inumbo-ID: b5e1c43e-b7b7-11ea-8496-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b5e1c43e-b7b7-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 14:17:05 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: U+C7AUTwewX4QFv6J22n3BMoAsv62KbOnDYUSRmS/h8iZ3xEAK1wUPj+fY/a6hCI8RbebRHvEX NnbiEbjxc+cHvaDoy4SsM5tlDLjDYywpnkKc5vHF1nlOvnvaCxOIRAhiVGf7H/LjSmQ7GlTosN RKP3jaeC3F8J/tmscjl+VDyFpXxloeiQpPL06MRxUTmKIV6uiXgvKrrQEODqOmwgIBgV7fWSFZ cc50W9FuISa9nb2D9/YAg93QmCgmFnt/Eqq+4bjafW8kXYA/GrzA7KF/voL4HDYlrdTzxef3cB SXo= X-SBRS: 2.7 X-MesageID: 21334863 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,283,1589256000"; d="scan'208";a="21334863" Date: Fri, 26 Jun 2020 16:16:56 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Julien Grall Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage Message-ID: <20200626141656.GC735@Air-de-Roger> References: <20200625113041.81507-1-roger.pau@citrix.com> <551387c6-f45d-bf6c-a41e-b0920425db9f@xen.org> <20200626100745.GB735@Air-de-Roger> <5586cae5-8929-0c53-7a35-5dd6116c77c2@suse.com> <000b01d64bbc$a7822f30$f6868d90$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Stefano Stabellini' , 'Wei Liu' , paul@xen.org, 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' , xen-devel@lists.xenproject.org, 'Volodymyr Babchuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 02:58:21PM +0100, Julien Grall wrote: > On 26/06/2020 14:21, Paul Durrant wrote: > > > -----Original Message----- > > > From: Jan Beulich > > > Sent: 26 June 2020 14:11 > > > To: Roger Pau Monné ; paul@xen.org; Andrew Cooper > > > Cc: Julien Grall ; xen-devel@lists.xenproject.org; Wei Liu ; George Dunlap > > > ; Ian Jackson ; Stefano Stabellini > > > ; Volodymyr Babchuk > > > Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage > > > > > > On 26.06.2020 12:07, Roger Pau Monné wrote: > > > > On Fri, Jun 26, 2020 at 10:38:11AM +0100, Julien Grall wrote: > > > > > Hi Roger, > > > > > > > > > > Sorry I didn't manage to answer to your question before you sent v3. > > > > > > > > > > On 25/06/2020 12:30, Roger Pau Monne wrote: > > > > > > diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h > > > > > > index ab1aae5c90..7ae0543885 100644 > > > > > > --- a/xen/include/asm-arm/flushtlb.h > > > > > > +++ b/xen/include/asm-arm/flushtlb.h > > > > > > @@ -27,6 +27,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) > > > > > > /* Flush specified CPUs' TLBs */ > > > > > > void flush_tlb_mask(const cpumask_t *mask); > > > > > > +#define flush_tlb_mask_sync flush_tlb_mask > > > > > > > > > > Dropping the parameter 'sync' from filtered_flush_tlb_mask() is a nice > > > > > improvement, but it unfortunately doesn't fully address my concern. > > > > > > > > > > After this patch there is exactly one use of flush_tlb_mask() in common code > > > > > (see grant_table.c). But without looking at the x86 code, it is not clear > > > > > why this requires a different flush compare to the two other sites. > > > > > > > > It's not dealing with page allocation or page type changes directly, > > > > and hence doesn't need to use an IPI in order to prevent races with > > > > spurious_page_fault. > > > > > > > > > IOW, if I want to modify the common code in the future, how do I know which > > > > > flush to call? > > > > > > > > Unless you modify one of the specific areas mentioned above (page > > > > allocation or page type changes) you should use flush_tlb_mask. > > > > > > > > This is not ideal, and my aim will be to be able to use the assisted > > > > flush everywhere if possible, so I would really like to get rid of the > > > > interrupt disabling done in spurious_page_fault and this model where > > > > x86 relies on blocking interrupts in order to prevent page type > > > > changes or page freeing. > > > > > > > > Such change however doesn't feel appropriate for a release freeze > > > > period, and hence went with something smaller that restores the > > > > previous behavior. Another option is to just disable assisted flushes > > > > for the time being and re-enable them when a suitable solution is > > > > found. > > > > > > As I can understand Julien's concern, maybe this would indeed be > > > the better approach for now? Andrew, Paul - thoughts? > > > > > > > Julien's concern seems to be about long term usage whereas IIUC this patch does fix the issue at hand, so can we put this patch in now on the basis that Roger will do the re-work described after 4.14 (which I think will address Julien's concern)? > Bear in mind that while this may be properly fixed in the next release, the > hack will stay forever in Xen 4.14. > > While I understand that disabling assisted flush is going to have a > performance impact, we also need to make sure the interface make senses. > > From a generic perspective, a TLB flush should have the exact same guarantee > regardless where we call it in common/. So I would still strongly prefer if > we have a single helper. > > Is it possible to consider to replace all the flush_tlb_mask() in common > code by arch_flush_tlb_mask()? On Arm, this would just be a rename. On x86, > this would be an alias to flush_tlb_mask_sync()? The TLB flush call in grant_table.c could still use a flush_tlb_mask, but it will also work fine with a flush_tlb_mask_sync. I can prepare a patch if that's acceptable, I guess it would be slightly better than fully disabling assisted flush. Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:19:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:19:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopCb-0007PC-VK; Fri, 26 Jun 2020 14:19:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopCa-0007P7-MF for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:19:36 +0000 X-Inumbo-ID: 0fbe310e-b7b8-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0fbe310e-b7b8-11ea-bca7-bc764e2007e4; Fri, 26 Jun 2020 14:19:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id BE301AC50; Fri, 26 Jun 2020 14:19:34 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource From: Jan Beulich To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623135246.66170-1-roger.pau@citrix.com> <50e25ef7-e7a7-d2c1-5f78-ce32cae35f38@suse.com> <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> <20200625090552.GW735@Air-de-Roger> <20200625161002.GZ735@Air-de-Roger> Message-ID: <0666afab-2694-a8a5-d4fd-5e0d88805065@suse.com> Date: Fri, 26 Jun 2020 16:19:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 15:40, Jan Beulich wrote: > On 25.06.2020 18:10, Roger Pau Monné wrote: >> On Thu, Jun 25, 2020 at 11:05:52AM +0200, Roger Pau Monné wrote: >>> On Wed, Jun 24, 2020 at 04:01:44PM +0200, Jan Beulich wrote: >>>> On 24.06.2020 15:41, Julien Grall wrote: >>>>> On 24/06/2020 11:12, Jan Beulich wrote: >>>>>> On 23.06.2020 19:26, Roger Pau Monné wrote: >>>>>>> I'm confused. Couldn't we switch from uint64_aligned_t to plain >>>>>>> uint64_t (like it's currently on the Linux headers), and then use the >>>>>>> compat layer in Xen to handle the size difference when called from >>>>>>> 32bit environments? >>>>>> >>>>>> And which size would we use there? The old or the new one (breaking >>>>>> future or existing callers respectively)? Meanwhile I think that if >>>>>> this indeed needs to not be tools-only (which I still question), >>>>> >>>>> I think we now agreed on a subthread that the kernel needs to know the >>>>> layout of the hypercall. >>>>> >>>>>> then our only possible route is to add explicit padding for the >>>>>> 32-bit case alongside the change you're already making. >>>>> >>>>> AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make >>>>> incompatible the two incompatible? >>>> >>>> In principle yes. But they're putting the structure instance on the >>>> stack, so there's not risk from Xen reading 4 bytes too many. I'd >>>> prefer keeping the interface as is (i.e. with the previously >>>> implicit padding made explicit) to avoid risking to break other >>>> possible callers. But that's just my view on it, anyway ... >>> >>> Adding the padding is cleaner because we don't need any compat stuff >>> in order to access the structure from the caller, and we also keep the >>> original layout currently present on Xen headers. >>> >>> I can prepare a fix for the Linux kernel, if this approach is fine. >> >> So I went over this, and I'm not sure the point of adding the padding >> field at the end of the structure for 32bit x86. >> >> The current situation is the following: >> >> - Linux will use a struct on 32bit x86 that doesn't have the 4byte >> padding at the end. >> - Xen will copy 4bytes of garbage in that case, since the struct on >> Linux is allocated on the stack. >> >> So I suggest we take the approach found on this patch, that is remove >> the 8byte alignment from the frame field, which will in turn remove >> 4bytes of padding from the tail of the structure on 32bit x86. >> >> That would leave the following scenario: >> >> - The struct layout in Linux headers would be correct. >> - Xen already handles the struct size difference on x86 32bit vs >> 64bit, as the compat layer is currently doing the copy in >> compat_memory_op taking into account the size of the compat >> structure. > > Hmm, I didn't even notice this until now - it looks to do so > indeed, but apparently because of a bug: The original > uint64_aligned_t gets translated to mere uint64_t in the > compat header, whereas it should have been retained. This > means that my concern of ... > >> - Removing the padding will work for all use cases: Linux will >> already be using the correct layout on x86 32bits, so no change >> will be required there. Any consumers using the tail padded >> structure will continue to work without issues, as Xen simply won't >> copy the tailing 4bytes. > > ... code using the new definition then potentially not working > correctly on 4.13, at least on versions not having this > backported, was not actually true. > > I'll try to sort out this other bug then ... I was wrong, there is no bug - translating uint64_aligned_t to uint64_t is fine, as these are seen only by 64-bit code, where both are identical anyway. Hence there still is the concern that code working fine on the supposed 4.14 might then not work on unfixed 4.13, due to 4.13 copying 4 extra bytes. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:24:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:24:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopHg-0008EG-IW; Fri, 26 Jun 2020 14:24:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopHf-0008EA-5z for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:24:51 +0000 X-Inumbo-ID: cb28f4ec-b7b8-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cb28f4ec-b7b8-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 14:24:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 274EDAE2E; Fri, 26 Jun 2020 14:24:49 +0000 (UTC) Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200625113041.81507-1-roger.pau@citrix.com> <551387c6-f45d-bf6c-a41e-b0920425db9f@xen.org> <20200626100745.GB735@Air-de-Roger> <5586cae5-8929-0c53-7a35-5dd6116c77c2@suse.com> <000b01d64bbc$a7822f30$f6868d90$@xen.org> <20200626141656.GC735@Air-de-Roger> From: Jan Beulich Message-ID: Date: Fri, 26 Jun 2020 16:24:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626141656.GC735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Stefano Stabellini' , Julien Grall , 'Wei Liu' , paul@xen.org, 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , xen-devel@lists.xenproject.org, 'Volodymyr Babchuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 16:16, Roger Pau Monné wrote: > On Fri, Jun 26, 2020 at 02:58:21PM +0100, Julien Grall wrote: >> On 26/06/2020 14:21, Paul Durrant wrote: >>>> -----Original Message----- >>>> From: Jan Beulich >>>> Sent: 26 June 2020 14:11 >>>> To: Roger Pau Monné ; paul@xen.org; Andrew Cooper >>>> Cc: Julien Grall ; xen-devel@lists.xenproject.org; Wei Liu ; George Dunlap >>>> ; Ian Jackson ; Stefano Stabellini >>>> ; Volodymyr Babchuk >>>> Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage >>>> >>>> On 26.06.2020 12:07, Roger Pau Monné wrote: >>>>> On Fri, Jun 26, 2020 at 10:38:11AM +0100, Julien Grall wrote: >>>>>> Hi Roger, >>>>>> >>>>>> Sorry I didn't manage to answer to your question before you sent v3. >>>>>> >>>>>> On 25/06/2020 12:30, Roger Pau Monne wrote: >>>>>>> diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h >>>>>>> index ab1aae5c90..7ae0543885 100644 >>>>>>> --- a/xen/include/asm-arm/flushtlb.h >>>>>>> +++ b/xen/include/asm-arm/flushtlb.h >>>>>>> @@ -27,6 +27,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) >>>>>>> /* Flush specified CPUs' TLBs */ >>>>>>> void flush_tlb_mask(const cpumask_t *mask); >>>>>>> +#define flush_tlb_mask_sync flush_tlb_mask >>>>>> >>>>>> Dropping the parameter 'sync' from filtered_flush_tlb_mask() is a nice >>>>>> improvement, but it unfortunately doesn't fully address my concern. >>>>>> >>>>>> After this patch there is exactly one use of flush_tlb_mask() in common code >>>>>> (see grant_table.c). But without looking at the x86 code, it is not clear >>>>>> why this requires a different flush compare to the two other sites. >>>>> >>>>> It's not dealing with page allocation or page type changes directly, >>>>> and hence doesn't need to use an IPI in order to prevent races with >>>>> spurious_page_fault. >>>>> >>>>>> IOW, if I want to modify the common code in the future, how do I know which >>>>>> flush to call? >>>>> >>>>> Unless you modify one of the specific areas mentioned above (page >>>>> allocation or page type changes) you should use flush_tlb_mask. >>>>> >>>>> This is not ideal, and my aim will be to be able to use the assisted >>>>> flush everywhere if possible, so I would really like to get rid of the >>>>> interrupt disabling done in spurious_page_fault and this model where >>>>> x86 relies on blocking interrupts in order to prevent page type >>>>> changes or page freeing. >>>>> >>>>> Such change however doesn't feel appropriate for a release freeze >>>>> period, and hence went with something smaller that restores the >>>>> previous behavior. Another option is to just disable assisted flushes >>>>> for the time being and re-enable them when a suitable solution is >>>>> found. >>>> >>>> As I can understand Julien's concern, maybe this would indeed be >>>> the better approach for now? Andrew, Paul - thoughts? >>>> >>> >>> Julien's concern seems to be about long term usage whereas IIUC this patch does fix the issue at hand, so can we put this patch in now on the basis that Roger will do the re-work described after 4.14 (which I think will address Julien's concern)? >> Bear in mind that while this may be properly fixed in the next release, the >> hack will stay forever in Xen 4.14. >> >> While I understand that disabling assisted flush is going to have a >> performance impact, we also need to make sure the interface make senses. >> >> From a generic perspective, a TLB flush should have the exact same guarantee >> regardless where we call it in common/. So I would still strongly prefer if >> we have a single helper. >> >> Is it possible to consider to replace all the flush_tlb_mask() in common >> code by arch_flush_tlb_mask()? On Arm, this would just be a rename. On x86, >> this would be an alias to flush_tlb_mask_sync()? > > The TLB flush call in grant_table.c could still use a flush_tlb_mask, > but it will also work fine with a flush_tlb_mask_sync. > > I can prepare a patch if that's acceptable, I guess it would be > slightly better than fully disabling assisted flush. Fine with me, fwiw. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:26:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:26:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopJ7-0008KJ-UB; Fri, 26 Jun 2020 14:26:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopJ7-0008K8-Av for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:26:21 +0000 X-Inumbo-ID: 01298408-b7b9-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 01298408-b7b9-11ea-bca7-bc764e2007e4; Fri, 26 Jun 2020 14:26:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id E0554AC50; Fri, 26 Jun 2020 14:26:19 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Ross Lagerwall References: <20200626122408.19151-1-andrew.cooper3@citrix.com> <4bd8ab3e-37d0-fde9-10a3-b6b2f9ca4da6@citrix.com> From: Jan Beulich Message-ID: <29ae3614-a73e-de01-f10f-8f3a32c3372a@suse.com> Date: Fri, 26 Jun 2020 16:26:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <4bd8ab3e-37d0-fde9-10a3-b6b2f9ca4da6@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Konrad Rzeszutek Wilk , Andrew Cooper , Paul Durrant , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 15:59, Ross Lagerwall wrote: > On 2020-06-26 13:24, Andrew Cooper wrote: >> @@ -56,18 +57,48 @@ int arch_livepatch_safety_check(void) >> return -EBUSY; >> } >> >> -int arch_livepatch_quiesce(void) >> +int noinline arch_livepatch_quiesce(void) >> { >> + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ >> + if ( cpu_has_xen_shstk ) > > Should this be: > if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) > > to match arch_livepatch_revive? While it may look a little asymmetric, I think it's preferable to is IS_ENABLED() only where really needed, i.e. here it guarding code that otherwise may not build. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:28:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:28:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopKr-0008SB-9t; Fri, 26 Jun 2020 14:28:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopKq-0008S4-6F for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:28:08 +0000 X-Inumbo-ID: 409b1912-b7b9-11ea-8496-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 409b1912-b7b9-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 14:28:07 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id q15so9014834wmj.2 for ; Fri, 26 Jun 2020 07:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=OoeejaLMxncODdjhoeVUGrwaLbu1DfR66opU0iNtCIg=; b=BvEUCHlg9h/89/ZVp8+2mOA7gWTsngnGn+y2TucQdEv1j9wP6MDjqfM7qOy6+djPmE QnGnfYs/hZS0NgPotHJj+kT8Kxpi2Jutl6PLO7CMT15TAZcKVXSo8HCNF8dzF64H2TBO j98GBoCRjYWZAvqhNNNU1RkzmS581M3/ZCpk7hIDqANoevEncxvFQjn2aQHyqAUVAvO7 4kYSU30AGbhztgphC7or1/ew6h7RWQiqpy5SYtMNi9aAal2zQEizOSdbNDefTp+fXsjR 9xhjtt3/n1vzO/lJOQXbHmI7hOAu9hkG9cGzT1CqOW8eZgOsKQ5Y1DitU9Bz5DKWrkwV DEzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=OoeejaLMxncODdjhoeVUGrwaLbu1DfR66opU0iNtCIg=; b=VOBb3uZAC5RV6sgDFXXe1FNKr9x4OjR6Vo2JmRckb78WpOnhimr/jUIJ1dptM999P+ uS4e0VkC+jwvY7BBzjJILRP36ijnVJWcmCsZk85enXPSQK60u1cP5YKqe4QzBCpv/L8d NyithOygl+rZRub1xPx3zLrCpkqdYFzMNf3ZkkogfR6KYcZ3uYvFx676TTNO/J0KQKro hKSqbhGeo4iCVD4uhgXkPDQCpFEOT/KjAUNRL2ltWSYkGb8wqs1NolrVYFOslk3va5kr E6Z9hnGCy9NpNnojO+50vkCl5/YKhRvly77VMCAMwgB/B3gEJbCc1pnODcR3Wn/Deiam 0Myw== X-Gm-Message-State: AOAM5302LfpcH86xcVjiy0rIMeuPRf7eqibFJmxigWhZtF4sFiQf8UPR +1U2vwvdBjPf2SBPhA+Ufl4= X-Google-Smtp-Source: ABdhPJx+6HFP0WgHunbKIM5pbcRyn4kpp0KXi4A3Px66JXiYPiJ09A84QG6iztIFjOyJ6NY8tmKLyA== X-Received: by 2002:a05:600c:c1:: with SMTP id u1mr3881281wmm.48.1593181686560; Fri, 26 Jun 2020 07:28:06 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id m10sm17892773wru.4.2020.06.26.07.28.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 07:28:06 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= , "'Julien Grall'" References: <20200625113041.81507-1-roger.pau@citrix.com> <551387c6-f45d-bf6c-a41e-b0920425db9f@xen.org> <20200626100745.GB735@Air-de-Roger> <5586cae5-8929-0c53-7a35-5dd6116c77c2@suse.com> <000b01d64bbc$a7822f30$f6868d90$@xen.org> <20200626141656.GC735@Air-de-Roger> In-Reply-To: <20200626141656.GC735@Air-de-Roger> Subject: RE: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage Date: Fri, 26 Jun 2020 15:28:04 +0100 Message-ID: <000d01d64bc6$01dbacf0$059306d0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQNtfAT0oM7SsXX048OvW1r6oGCP7gGm0OfKAaiO/jIBsc/uaAIhC8ICAv8Ymn8CUdcdGqVY+olw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' , xen-devel@lists.xenproject.org, 'Volodymyr Babchuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monn=C3=A9 > Sent: 26 June 2020 15:17 > To: Julien Grall > Cc: paul@xen.org; 'Jan Beulich' ; 'Andrew Cooper' = ; xen- > devel@lists.xenproject.org; 'Wei Liu' ; 'George Dunlap' = ; 'Ian > Jackson' ; 'Stefano Stabellini' = ; 'Volodymyr > Babchuk' > Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush usage >=20 > On Fri, Jun 26, 2020 at 02:58:21PM +0100, Julien Grall wrote: > > On 26/06/2020 14:21, Paul Durrant wrote: > > > > -----Original Message----- > > > > From: Jan Beulich > > > > Sent: 26 June 2020 14:11 > > > > To: Roger Pau Monn=C3=A9 ; paul@xen.org; = Andrew Cooper > > > > > Cc: Julien Grall ; = xen-devel@lists.xenproject.org; Wei Liu ; George > Dunlap > > > > ; Ian Jackson = ; Stefano Stabellini > > > > ; Volodymyr Babchuk = > > > > Subject: Re: [PATCH for-4.14 v3] x86/tlb: fix assisted flush = usage > > > > > > > > On 26.06.2020 12:07, Roger Pau Monn=C3=A9 wrote: > > > > > On Fri, Jun 26, 2020 at 10:38:11AM +0100, Julien Grall wrote: > > > > > > Hi Roger, > > > > > > > > > > > > Sorry I didn't manage to answer to your question before you = sent v3. > > > > > > > > > > > > On 25/06/2020 12:30, Roger Pau Monne wrote: > > > > > > > diff --git a/xen/include/asm-arm/flushtlb.h = b/xen/include/asm-arm/flushtlb.h > > > > > > > index ab1aae5c90..7ae0543885 100644 > > > > > > > --- a/xen/include/asm-arm/flushtlb.h > > > > > > > +++ b/xen/include/asm-arm/flushtlb.h > > > > > > > @@ -27,6 +27,7 @@ static inline void = page_set_tlbflush_timestamp(struct page_info *page) > > > > > > > /* Flush specified CPUs' TLBs */ > > > > > > > void flush_tlb_mask(const cpumask_t *mask); > > > > > > > +#define flush_tlb_mask_sync flush_tlb_mask > > > > > > > > > > > > Dropping the parameter 'sync' from filtered_flush_tlb_mask() = is a nice > > > > > > improvement, but it unfortunately doesn't fully address my = concern. > > > > > > > > > > > > After this patch there is exactly one use of = flush_tlb_mask() in common code > > > > > > (see grant_table.c). But without looking at the x86 code, it = is not clear > > > > > > why this requires a different flush compare to the two other = sites. > > > > > > > > > > It's not dealing with page allocation or page type changes = directly, > > > > > and hence doesn't need to use an IPI in order to prevent races = with > > > > > spurious_page_fault. > > > > > > > > > > > IOW, if I want to modify the common code in the future, how = do I know which > > > > > > flush to call? > > > > > > > > > > Unless you modify one of the specific areas mentioned above = (page > > > > > allocation or page type changes) you should use = flush_tlb_mask. > > > > > > > > > > This is not ideal, and my aim will be to be able to use the = assisted > > > > > flush everywhere if possible, so I would really like to get = rid of the > > > > > interrupt disabling done in spurious_page_fault and this model = where > > > > > x86 relies on blocking interrupts in order to prevent page = type > > > > > changes or page freeing. > > > > > > > > > > Such change however doesn't feel appropriate for a release = freeze > > > > > period, and hence went with something smaller that restores = the > > > > > previous behavior. Another option is to just disable assisted = flushes > > > > > for the time being and re-enable them when a suitable solution = is > > > > > found. > > > > > > > > As I can understand Julien's concern, maybe this would indeed be > > > > the better approach for now? Andrew, Paul - thoughts? > > > > > > > > > > Julien's concern seems to be about long term usage whereas IIUC = this patch does fix the issue at > hand, so can we put this patch in now on the basis that Roger will do = the re-work described after 4.14 > (which I think will address Julien's concern)? > > Bear in mind that while this may be properly fixed in the next = release, the > > hack will stay forever in Xen 4.14. > > > > While I understand that disabling assisted flush is going to have a > > performance impact, we also need to make sure the interface make = senses. > > > > From a generic perspective, a TLB flush should have the exact same = guarantee > > regardless where we call it in common/. So I would still strongly = prefer if > > we have a single helper. > > > > Is it possible to consider to replace all the flush_tlb_mask() in = common > > code by arch_flush_tlb_mask()? On Arm, this would just be a rename. = On x86, > > this would be an alias to flush_tlb_mask_sync()? >=20 > The TLB flush call in grant_table.c could still use a flush_tlb_mask, > but it will also work fine with a flush_tlb_mask_sync. >=20 > I can prepare a patch if that's acceptable, I guess it would be > slightly better than fully disabling assisted flush. >=20 Sounds like a reasonable plan. Paul > Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:38:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:38:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopUO-0000uY-8W; Fri, 26 Jun 2020 14:38:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopUN-0000uT-25 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:37:59 +0000 X-Inumbo-ID: a067d4a6-b7ba-11ea-bca7-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a067d4a6-b7ba-11ea-bca7-bc764e2007e4; Fri, 26 Jun 2020 14:37:57 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: kHOFdFhBmHfCGWRLYS/vQC+VRpk9pvNHFMdXy+26e5/Hr5kIopiiSW9AtoA06h1jCoMeofpkeB 1fZ3OEQ2pp9G0VBT+BYC6ScJWAXhTXimy+rTfgvt1yjM2l+DtMAigs+SU2UsURGp+rT5xu7ur4 BvNuj4JTpEXCkUVmY0/b6tCUnLvb9QirAsV2LjfmiLM2yO3FiB5vESX5RM/x7tJPIQz2O3/Iqb lLADvuAeSA+5QWfqC2pofKvt/qK+xTo1fkhF9ym45+9rPB/ZXXkC94hiJ9dhUtVZV6uICaIoAq IjE= X-SBRS: 2.7 X-MesageID: 21336657 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21336657" From: Andrew Cooper To: Xen-devel Subject: [PATCH for-4.14] changelog: Add notes about CET and Migration changes Date: Fri, 26 Jun 2020 15:37:38 +0100 Message-ID: <20200626143738.1525-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Paul Durrant , Jan Beulich , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Ian Jackson CC: Jan Beulich CC: Konrad Rzeszutek Wilk CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall CC: Paul Durrant --- CHANGELOG.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 43fd260156..5c3d3c791d 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -21,6 +21,15 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) - New 'domid_policy', allowing domain-ids to be randomly chosen. - Option to preserve domain-id across migrate or save+restore. - Support in kdd for initial KD protocol handshake for Win 7, 8 and 10 (64 bit). + - Tech preview support for Control-flow Execution Technology, with Xen using + Supervisor Shadow Stacks for its own protection. + +### Changed + - The CPUID data seen by a guest on boot is now moved in the migration + stream. A guest migrating between non-identical hardware will now no + longer observe details such as Family/Model/Stepping, Cache, etc changing. + An administrator still needs to take care to ensure the features visible to + the guest at boot are compatible with anywhere it might migrate. ## [4.13.0](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.13.0) - 2019-12-17 -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:43:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:43:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopZb-0001ix-UD; Fri, 26 Jun 2020 14:43:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopZZ-0001is-QU for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:43:21 +0000 X-Inumbo-ID: 612767b0-b7bb-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x334.google.com (unknown [2a00:1450:4864:20::334]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 612767b0-b7bb-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 14:43:21 +0000 (UTC) Received: by mail-wm1-x334.google.com with SMTP id j18so9061238wmi.3 for ; Fri, 26 Jun 2020 07:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=VNi0skosebjyIppHSOJfiiPcBm9z+1fKzOIjWKvVeCg=; b=KKyNBdmHEJFLFmbbuZn4Vu+9kIlbH3Hl+817ej4KULED+Zi23g14jiWqXdPUeaZeai IqTnrt6KTTsnU+tGKK4qWfBpdW3FLsV+YGN3qndku+/21ZyjlZKg51PCBOLpiOtIrVrx G/zYLLcRWcJCixJ2WS6w1I1mUGW6HslrOOCWt7/ZRGtA4u/DxMpi4GgKgPFgtnHUZNxb OQ3hQfKmWTFOujd4+/4AJfenheQdFJJ6E5PPCLV2Edw0jnPsan0ACNEawBcLaCPbWg56 7r4tnopgwKRl2STatGWxfke6a5mKpnBNjZGKddEh2FrTP/uTUO/PVkIygMBX1AVYP/iJ vNnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=VNi0skosebjyIppHSOJfiiPcBm9z+1fKzOIjWKvVeCg=; b=lvIH+1Fyi27GG6tJLed7PXSgSF28Ob/FRaPtG7hfK9YWgsvxTTWE7T6qP9UWEHogvv wBEKjTL3e79lQmYvWjX7g4bEooeiRd0qie8gT0BdVnsuJGPAjX1wBq84k0kpJkJbXVIA srNbahJ2hXV4wvKw61afKBkQhfBgPOF9JQ7K7Xu82pggFgBu6UMsUPvmMpOKB/0e3/6T atPVaJApqOqF8T7+Lqe/gGZhzimhGkCH29pYR2og3O/N9PvFn0+MxEyErPN+IMxoAI3L nk56tJnqpWiuAQRM3kNQEkeSISlHfkRPRTsKmDmYKFIlnhDpZop9Jr8xkKYdRnqVdtJI vSFQ== X-Gm-Message-State: AOAM533oaxdtEbRfyXlKkzhHQ8oqRwasM1jIlcgdVgYNwltDqVrGZN76 QPhNKEkFPypvVck1eQswOJ0= X-Google-Smtp-Source: ABdhPJwn7zjvIyCnqcHy4w0AYUEL2f700A25RbqyMaY3AeDQSnM2cj9JyE/W7Zk2tKRLqNYI7PlhqA== X-Received: by 2002:a1c:b686:: with SMTP id g128mr3984668wmf.145.1593182600025; Fri, 26 Jun 2020 07:43:20 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id 1sm17376911wmf.0.2020.06.26.07.43.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 07:43:19 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200626143738.1525-1-andrew.cooper3@citrix.com> In-Reply-To: <20200626143738.1525-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH for-4.14] changelog: Add notes about CET and Migration changes Date: Fri, 26 Jun 2020 15:43:18 +0100 Message-ID: <000e01d64bc8$225470f0$66fd52d0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQKMC0NhwedNQpKXt7bFC8BNw1etxKd/eY8Q X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Konrad Rzeszutek Wilk' , 'George Dunlap' , 'Jan Beulich' , 'Ian Jackson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 26 June 2020 15:38 > To: Xen-devel > Cc: Andrew Cooper ; George Dunlap ; Ian > Jackson ; Jan Beulich ; Konrad Rzeszutek Wilk > ; Stefano Stabellini ; Wei Liu ; Julien > Grall ; Paul Durrant > Subject: [PATCH for-4.14] changelog: Add notes about CET and Migration changes > > Signed-off-by: Andrew Cooper Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant > --- > CC: George Dunlap > CC: Ian Jackson > CC: Jan Beulich > CC: Konrad Rzeszutek Wilk > CC: Stefano Stabellini > CC: Wei Liu > CC: Julien Grall > CC: Paul Durrant > --- > CHANGELOG.md | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 43fd260156..5c3d3c791d 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -21,6 +21,15 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) > - New 'domid_policy', allowing domain-ids to be randomly chosen. > - Option to preserve domain-id across migrate or save+restore. > - Support in kdd for initial KD protocol handshake for Win 7, 8 and 10 (64 bit). > + - Tech preview support for Control-flow Execution Technology, with Xen using > + Supervisor Shadow Stacks for its own protection. > + > +### Changed > + - The CPUID data seen by a guest on boot is now moved in the migration > + stream. A guest migrating between non-identical hardware will now no > + longer observe details such as Family/Model/Stepping, Cache, etc changing. > + An administrator still needs to take care to ensure the features visible to > + the guest at boot are compatible with anywhere it might migrate. > > ## [4.13.0](https://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=RELEASE-4.13.0) - 2019-12-17 > > -- > 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:46:19 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:46:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopcQ-0001rT-GR; Fri, 26 Jun 2020 14:46:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopcQ-0001rO-4E for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:46:18 +0000 X-Inumbo-ID: c9a5d966-b7bb-11ea-b7bb-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c9a5d966-b7bb-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 14:46:16 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: bUFHq1LnhwQU5oif03q5KuADDlgQaaaQ23BYdHvfugd/oRHKtcMGNNl9S/aNHs9PiJ3oWir00j QYo7NRCSMSDXPMg2Vddp5Ck3AvNJC/LQcbocQxLUgCQs5b1OWCI4P16+dWYUUfhW37bgsxnRnX AJkwf7rsyuMagpLpFROs/ZX9Ur9/qXBNagJU2nXtDqlIWiXxPcAs/DlzMPX4Mp07q3lWGKvPtm e8Sum32ng+lRbK/WhmTpFo9ZCxsgI65WXMvBOr1nmwywKpjSDcNCy5qPzvLAv6Pl90OohHY6Pk yJ8= X-SBRS: 2.7 X-MesageID: 21040981 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21040981" Subject: Re: [PATCH v2 for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Jan Beulich , Ross Lagerwall References: <20200626122408.19151-1-andrew.cooper3@citrix.com> <4bd8ab3e-37d0-fde9-10a3-b6b2f9ca4da6@citrix.com> <29ae3614-a73e-de01-f10f-8f3a32c3372a@suse.com> From: Andrew Cooper Message-ID: <5756a404-2d0a-3146-0682-dc89ad4a3c61@citrix.com> Date: Fri, 26 Jun 2020 15:46:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <29ae3614-a73e-de01-f10f-8f3a32c3372a@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Konrad Rzeszutek Wilk , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26/06/2020 15:26, Jan Beulich wrote: > On 26.06.2020 15:59, Ross Lagerwall wrote: >> On 2020-06-26 13:24, Andrew Cooper wrote: >>> @@ -56,18 +57,48 @@ int arch_livepatch_safety_check(void) >>> return -EBUSY; >>> } >>> >>> -int arch_livepatch_quiesce(void) >>> +int noinline arch_livepatch_quiesce(void) >>> { >>> + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ >>> + if ( cpu_has_xen_shstk ) >> Should this be: >> if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) >> >> to match arch_livepatch_revive? > While it may look a little asymmetric, I think it's preferable > to is IS_ENABLED() only where really needed, i.e. here it > guarding code that otherwise may not build. The reason for the asymmetry is because of the asm() block, which needs compiling out when we detect that we don't have a compatible assembler. I was wondering whether I should make cpu_has_xen_shstk be false for !CONFIG_XEN_SHSTK, but that would be 4.15 work at this point. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:47:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:47:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopdk-0001xi-RZ; Fri, 26 Jun 2020 14:47:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopdj-0001xb-Kl for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:47:39 +0000 X-Inumbo-ID: fb1643c8-b7bb-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fb1643c8-b7bb-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 14:47:39 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 26724ABE2; Fri, 26 Jun 2020 14:47:38 +0000 (UTC) Subject: Re: [PATCH for-4.14] changelog: Add notes about CET and Migration changes To: Andrew Cooper References: <20200626143738.1525-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <3f418561-440a-20fc-fe79-695e894e2184@suse.com> Date: Fri, 26 Jun 2020 16:47:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626143738.1525-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Paul Durrant , Ian Jackson , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 16:37, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper In case wanted / needed: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 14:49:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 14:49:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopf7-00024R-6u; Fri, 26 Jun 2020 14:49:05 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopf6-00024H-D3 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 14:49:04 +0000 X-Inumbo-ID: 2c96e88a-b7bc-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 2c96e88a-b7bc-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 14:49:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3D8C5AAE8; Fri, 26 Jun 2020 14:49:01 +0000 (UTC) Subject: Re: [PATCH v2 for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Andrew Cooper , Ross Lagerwall References: <20200626122408.19151-1-andrew.cooper3@citrix.com> <4bd8ab3e-37d0-fde9-10a3-b6b2f9ca4da6@citrix.com> <29ae3614-a73e-de01-f10f-8f3a32c3372a@suse.com> <5756a404-2d0a-3146-0682-dc89ad4a3c61@citrix.com> From: Jan Beulich Message-ID: <5a1e12b9-5af9-f393-47bb-153c62ca51f3@suse.com> Date: Fri, 26 Jun 2020 16:49:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <5756a404-2d0a-3146-0682-dc89ad4a3c61@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Konrad Rzeszutek Wilk , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 16:46, Andrew Cooper wrote: > On 26/06/2020 15:26, Jan Beulich wrote: >> On 26.06.2020 15:59, Ross Lagerwall wrote: >>> On 2020-06-26 13:24, Andrew Cooper wrote: >>>> @@ -56,18 +57,48 @@ int arch_livepatch_safety_check(void) >>>> return -EBUSY; >>>> } >>>> >>>> -int arch_livepatch_quiesce(void) >>>> +int noinline arch_livepatch_quiesce(void) >>>> { >>>> + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ >>>> + if ( cpu_has_xen_shstk ) >>> Should this be: >>> if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) >>> >>> to match arch_livepatch_revive? >> While it may look a little asymmetric, I think it's preferable >> to is IS_ENABLED() only where really needed, i.e. here it >> guarding code that otherwise may not build. > > The reason for the asymmetry is because of the asm() block, which needs > compiling out when we detect that we don't have a compatible assembler. > > I was wondering whether I should make cpu_has_xen_shstk be false for > !CONFIG_XEN_SHSTK, but that would be 4.15 work at this point. Ah yes, this might then help with other code as well. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:02:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:02:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jops8-0003fP-ED; Fri, 26 Jun 2020 15:02:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jops6-0003fK-Tj for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:02:30 +0000 X-Inumbo-ID: 0dea3da4-b7be-11ea-82ce-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0dea3da4-b7be-11ea-82ce-12813bfff9fa; Fri, 26 Jun 2020 15:02:29 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A5F91AC46; Fri, 26 Jun 2020 15:02:28 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: Jan Beulich Subject: [PATCH] build: tweak variable exporting for make 3.82 Message-ID: <0677fe2a-9ea1-7b3c-e212-4a2478537459@suse.com> Date: Fri, 26 Jun 2020 17:02:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , George Dunlap , Andrew Cooper , Anthony Perard , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" While I've been running into an issue here only because of an additional local change I'm carrying, to be able to override just the compiler in $(XEN_ROOT)/.config (rather than the whole tool chain), in config/StdGNU.mk: ifeq ($(filter-out default undefined,$(origin CC)),) I'd like to propose to nevertheless correct the underlying issue: Exporting an unset variable changes its origin from "undefined" to "file". This comes into effect because of our adding of -rR to MAKEFLAGS, which make 3.82 wrongly applies also upon re-invoking itself after having updated auto.conf{,.cmd}. Move the export statement past $(XEN_ROOT)/config/$(XEN_OS).mk inclusion such that the variables already have their designated values at that point, while retaining their initial origin up to the point they get defined. Signed-off-by: Jan Beulich --- a/xen/Makefile +++ b/xen/Makefile @@ -17,8 +17,6 @@ export XEN_BUILD_HOST ?= $(shell hostnam PYTHON_INTERPRETER := $(word 1,$(shell which python3 python python2 2>/dev/null) python) export PYTHON ?= $(PYTHON_INTERPRETER) -export CC CXX LD - export BASEDIR := $(CURDIR) export XEN_ROOT := $(BASEDIR)/.. @@ -42,6 +40,8 @@ export TARGET_ARCH := $(shell echo $ # Allow someone to change their config file export KCONFIG_CONFIG ?= .config +export CC CXX LD + .PHONY: default default: build From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:04:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:04:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joptb-0003lT-Pf; Fri, 26 Jun 2020 15:04:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopta-0003lM-ID for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:04:02 +0000 X-Inumbo-ID: 437fe934-b7be-11ea-82ce-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 437fe934-b7be-11ea-82ce-12813bfff9fa; Fri, 26 Jun 2020 15:04:01 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: YBpiOp/SCiu/WzsnvhLxcMZZDFNThZnEF7sAmp00qyouC31xNg8sEnEQ4JoUAqlvm5NMBspECS Usxa9oa9m3ktfCPdkHpJ97hi9SjCV+6KWWn/fBqC7hI1bz94fSsgHdtgOVv2ga8GOYXjhhHt0V lxkAMic/AWkP4hbHI0cRFkHlTrsIc9jZs0YN46H4NLhTW5fKa7+Mq/EQbHQUEdOkK9npWLSsmm JsUk0Y2bk9lzMl/b/dfQzfC24kPHiybbfZ0uhJ6t4mUk18u4dLQYoL6GypUxhSURj5ijAijg5k Kqs= X-SBRS: 2.7 X-MesageID: 21249824 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21249824" Date: Fri, 26 Jun 2020 17:03:53 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource Message-ID: <20200626150353.GD735@Air-de-Roger> References: <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> <20200625090552.GW735@Air-de-Roger> <20200625161002.GZ735@Air-de-Roger> <0666afab-2694-a8a5-d4fd-5e0d88805065@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0666afab-2694-a8a5-d4fd-5e0d88805065@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 04:19:36PM +0200, Jan Beulich wrote: > On 26.06.2020 15:40, Jan Beulich wrote: > > On 25.06.2020 18:10, Roger Pau Monné wrote: > >> On Thu, Jun 25, 2020 at 11:05:52AM +0200, Roger Pau Monné wrote: > >>> On Wed, Jun 24, 2020 at 04:01:44PM +0200, Jan Beulich wrote: > >>>> On 24.06.2020 15:41, Julien Grall wrote: > >>>>> On 24/06/2020 11:12, Jan Beulich wrote: > >>>>>> On 23.06.2020 19:26, Roger Pau Monné wrote: > >>>>>>> I'm confused. Couldn't we switch from uint64_aligned_t to plain > >>>>>>> uint64_t (like it's currently on the Linux headers), and then use the > >>>>>>> compat layer in Xen to handle the size difference when called from > >>>>>>> 32bit environments? > >>>>>> > >>>>>> And which size would we use there? The old or the new one (breaking > >>>>>> future or existing callers respectively)? Meanwhile I think that if > >>>>>> this indeed needs to not be tools-only (which I still question), > >>>>> > >>>>> I think we now agreed on a subthread that the kernel needs to know the > >>>>> layout of the hypercall. > >>>>> > >>>>>> then our only possible route is to add explicit padding for the > >>>>>> 32-bit case alongside the change you're already making. > >>>>> > >>>>> AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make > >>>>> incompatible the two incompatible? > >>>> > >>>> In principle yes. But they're putting the structure instance on the > >>>> stack, so there's not risk from Xen reading 4 bytes too many. I'd > >>>> prefer keeping the interface as is (i.e. with the previously > >>>> implicit padding made explicit) to avoid risking to break other > >>>> possible callers. But that's just my view on it, anyway ... > >>> > >>> Adding the padding is cleaner because we don't need any compat stuff > >>> in order to access the structure from the caller, and we also keep the > >>> original layout currently present on Xen headers. > >>> > >>> I can prepare a fix for the Linux kernel, if this approach is fine. > >> > >> So I went over this, and I'm not sure the point of adding the padding > >> field at the end of the structure for 32bit x86. > >> > >> The current situation is the following: > >> > >> - Linux will use a struct on 32bit x86 that doesn't have the 4byte > >> padding at the end. > >> - Xen will copy 4bytes of garbage in that case, since the struct on > >> Linux is allocated on the stack. > >> > >> So I suggest we take the approach found on this patch, that is remove > >> the 8byte alignment from the frame field, which will in turn remove > >> 4bytes of padding from the tail of the structure on 32bit x86. > >> > >> That would leave the following scenario: > >> > >> - The struct layout in Linux headers would be correct. > >> - Xen already handles the struct size difference on x86 32bit vs > >> 64bit, as the compat layer is currently doing the copy in > >> compat_memory_op taking into account the size of the compat > >> structure. > > > > Hmm, I didn't even notice this until now - it looks to do so > > indeed, but apparently because of a bug: The original > > uint64_aligned_t gets translated to mere uint64_t in the > > compat header, whereas it should have been retained. This > > means that my concern of ... > > > >> - Removing the padding will work for all use cases: Linux will > >> already be using the correct layout on x86 32bits, so no change > >> will be required there. Any consumers using the tail padded > >> structure will continue to work without issues, as Xen simply won't > >> copy the tailing 4bytes. > > > > ... code using the new definition then potentially not working > > correctly on 4.13, at least on versions not having this > > backported, was not actually true. > > > > I'll try to sort out this other bug then ... > > I was wrong, there is no bug - translating uint64_aligned_t to > uint64_t is fine, as these are seen only by 64-bit code, where > both are identical anyway. Hence there still is the concern that > code working fine on the supposed 4.14 might then not work on > unfixed 4.13, due to 4.13 copying 4 extra bytes. So here are the structures on 64bit x86 according to pahole against xen-syms: struct xen_mem_acquire_resource { domid_t domid; /* 0 2 */ uint16_t type; /* 2 2 */ uint32_t id; /* 4 4 */ uint32_t nr_frames; /* 8 4 */ uint32_t pad; /* 12 4 */ uint64_t frame; /* 16 8 */ __guest_handle_xen_pfn_t frame_list; /* 24 8 */ /* size: 32, cachelines: 1, members: 7 */ /* last cacheline: 32 bytes */ }; struct compat_mem_acquire_resource { domid_compat_t domid; /* 0 2 */ uint16_t type; /* 2 2 */ uint32_t id; /* 4 4 */ uint32_t nr_frames; /* 8 4 */ uint32_t pad; /* 12 4 */ uint64_t frame; /* 16 8 */ __compat_handle_compat_pfn_t frame_list; /* 24 4 */ /* size: 28, cachelines: 1, members: 7 */ /* last cacheline: 28 bytes */ }; There's no tailing padding on the compat struct ATM, and hence the current code will behave correctly when used against a compat structure without the tailing padding (as it's already ignored). There's a #pragma pack(4) at the top of compat/memory.h which forces this AFAICT. So I think the suggested approach is fine and will avoid any breakage. Roger. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:08:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:08:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopxN-0003vo-Aa; Fri, 26 Jun 2020 15:07:57 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopxL-0003vj-RB for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:07:55 +0000 X-Inumbo-ID: cfc8d188-b7be-11ea-82ce-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cfc8d188-b7be-11ea-82ce-12813bfff9fa; Fri, 26 Jun 2020 15:07:55 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: bfqrn94nP2go7apZzwt9TQE+Uacg+I/K53KWJkcnA7d6kHo0kELQVuHjMvy6bL6mwiLQf8l0Rd cLufiwfoBqBsf42vtQAJo3bdd9VOn2GIU0Dyv+SspCJ3FR4eXddEBW2D2s9VbNdsIivfS3v+RQ Ex0KbZKJCY2cVw+TT4ssfnEucVOUIDoTUpJqTjGfDp7cDmxqekC16e506+qcx7TcTMc61mXP5h KIDS7REjdzRwmBgoUpUlYEXBPinmwanFvBsuqGiAI9g4b1CL83K1h8KAL6Xsf0UI3BMbDpZjS1 lYA= X-SBRS: 2.7 X-MesageID: 21250307 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21250307" Subject: Re: [PATCH v2 for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Andrew Cooper , Jan Beulich References: <20200626122408.19151-1-andrew.cooper3@citrix.com> <4bd8ab3e-37d0-fde9-10a3-b6b2f9ca4da6@citrix.com> <29ae3614-a73e-de01-f10f-8f3a32c3372a@suse.com> <5756a404-2d0a-3146-0682-dc89ad4a3c61@citrix.com> From: Ross Lagerwall Message-ID: <2e0f93a1-29da-9457-a548-41e2c51ce75b@citrix.com> Date: Fri, 26 Jun 2020 16:07:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <5756a404-2d0a-3146-0682-dc89ad4a3c61@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Konrad Rzeszutek Wilk , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 2020-06-26 15:46, Andrew Cooper wrote: > On 26/06/2020 15:26, Jan Beulich wrote: >> On 26.06.2020 15:59, Ross Lagerwall wrote: >>> On 2020-06-26 13:24, Andrew Cooper wrote: >>>> @@ -56,18 +57,48 @@ int arch_livepatch_safety_check(void) >>>> return -EBUSY; >>>> } >>>> >>>> -int arch_livepatch_quiesce(void) >>>> +int noinline arch_livepatch_quiesce(void) >>>> { >>>> + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ >>>> + if ( cpu_has_xen_shstk ) >>> Should this be: >>> if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) >>> >>> to match arch_livepatch_revive? >> While it may look a little asymmetric, I think it's preferable >> to is IS_ENABLED() only where really needed, i.e. here it >> guarding code that otherwise may not build. > > The reason for the asymmetry is because of the asm() block, which needs > compiling out when we detect that we don't have a compatible assembler. > In that case, Reviewed-by: Ross Lagerwall Thanks From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:08:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:08:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopyK-00040f-KQ; Fri, 26 Jun 2020 15:08:56 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jopyJ-00040Y-Qt for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:08:55 +0000 X-Inumbo-ID: f3a1576a-b7be-11ea-82cf-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f3a1576a-b7be-11ea-82cf-12813bfff9fa; Fri, 26 Jun 2020 15:08:55 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: KMAP5/iI7KGQCDicV0q8qkboU0msafPKyb4nfgXGC33TfWdFltZwZOxT6YmjI/3ACs5e8CKQbQ gHlzfm/rAS65StxHRdwjXCWxyuKrxWOAB1tfJdyLbJEWjO4O9Py05rzm5q9TNzdBKOohwoI/q8 wfmrKqUMhenhumtwbGZlzm6jl+CA2hL8i5iR0OFYDa14Gfty+0CZEbq0T5aLciZg6ghMDH9OjR riIh4OmolRQslEAvEsBQtlYTusfSGLFUMd1q4aiZ2PEAnFNWXrlZ2N0qNP12H98dwCMR0bcG+P rZk= X-SBRS: 2.7 X-MesageID: 21043473 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21043473" Subject: Re: [PATCH v2 for-4.14] x86/livepatch: Make livepatching compatible with CET Shadow Stacks To: Ross Lagerwall , Jan Beulich References: <20200626122408.19151-1-andrew.cooper3@citrix.com> <4bd8ab3e-37d0-fde9-10a3-b6b2f9ca4da6@citrix.com> <29ae3614-a73e-de01-f10f-8f3a32c3372a@suse.com> <5756a404-2d0a-3146-0682-dc89ad4a3c61@citrix.com> <2e0f93a1-29da-9457-a548-41e2c51ce75b@citrix.com> From: Andrew Cooper Message-ID: Date: Fri, 26 Jun 2020 16:08:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <2e0f93a1-29da-9457-a548-41e2c51ce75b@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Paul Durrant , Konrad Rzeszutek Wilk , Pawel Wieczorkiewicz , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26/06/2020 16:07, Ross Lagerwall wrote: > On 2020-06-26 15:46, Andrew Cooper wrote: >> On 26/06/2020 15:26, Jan Beulich wrote: >>> On 26.06.2020 15:59, Ross Lagerwall wrote: >>>> On 2020-06-26 13:24, Andrew Cooper wrote: >>>>> @@ -56,18 +57,48 @@ int arch_livepatch_safety_check(void) >>>>> return -EBUSY; >>>>> } >>>>> >>>>> -int arch_livepatch_quiesce(void) >>>>> +int noinline arch_livepatch_quiesce(void) >>>>> { >>>>> + /* If Shadow Stacks are in use, disable CR4.CET so we can modify CR0.WP. */ >>>>> + if ( cpu_has_xen_shstk ) >>>> Should this be: >>>> if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) >>>> >>>> to match arch_livepatch_revive? >>> While it may look a little asymmetric, I think it's preferable >>> to is IS_ENABLED() only where really needed, i.e. here it >>> guarding code that otherwise may not build. >> The reason for the asymmetry is because of the asm() block, which needs >> compiling out when we detect that we don't have a compatible assembler. >> > In that case, > > Reviewed-by: Ross Lagerwall Thanks.  I've decided to clean this up in the (growing) series of 4.15 changes. ~Andrew From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:25:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:25:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqEB-0005ek-1Q; Fri, 26 Jun 2020 15:25:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqEA-0005ef-2y for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:25:18 +0000 X-Inumbo-ID: 3cc0e85a-b7c1-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3cc0e85a-b7c1-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 15:25:16 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C8AC8AC49; Fri, 26 Jun 2020 15:25:15 +0000 (UTC) Subject: Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200623155609.GS735@Air-de-Roger> <20200623172652.GU735@Air-de-Roger> <24d35c4d-e2b3-1f58-4c6e-71072de01b74@suse.com> <04410978-33bf-dedf-7401-248b1a038a9c@xen.org> <60ac0a67-1448-4b39-4489-42dc008b6355@suse.com> <20200625090552.GW735@Air-de-Roger> <20200625161002.GZ735@Air-de-Roger> <0666afab-2694-a8a5-d4fd-5e0d88805065@suse.com> <20200626150353.GD735@Air-de-Roger> From: Jan Beulich Message-ID: <0858d89e-dd57-7a22-0589-e046c183aef5@suse.com> Date: Fri, 26 Jun 2020 17:25:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626150353.GD735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 17:03, Roger Pau Monné wrote: > On Fri, Jun 26, 2020 at 04:19:36PM +0200, Jan Beulich wrote: >> On 26.06.2020 15:40, Jan Beulich wrote: >>> On 25.06.2020 18:10, Roger Pau Monné wrote: >>>> On Thu, Jun 25, 2020 at 11:05:52AM +0200, Roger Pau Monné wrote: >>>>> On Wed, Jun 24, 2020 at 04:01:44PM +0200, Jan Beulich wrote: >>>>>> On 24.06.2020 15:41, Julien Grall wrote: >>>>>>> On 24/06/2020 11:12, Jan Beulich wrote: >>>>>>>> On 23.06.2020 19:26, Roger Pau Monné wrote: >>>>>>>>> I'm confused. Couldn't we switch from uint64_aligned_t to plain >>>>>>>>> uint64_t (like it's currently on the Linux headers), and then use the >>>>>>>>> compat layer in Xen to handle the size difference when called from >>>>>>>>> 32bit environments? >>>>>>>> >>>>>>>> And which size would we use there? The old or the new one (breaking >>>>>>>> future or existing callers respectively)? Meanwhile I think that if >>>>>>>> this indeed needs to not be tools-only (which I still question), >>>>>>> >>>>>>> I think we now agreed on a subthread that the kernel needs to know the >>>>>>> layout of the hypercall. >>>>>>> >>>>>>>> then our only possible route is to add explicit padding for the >>>>>>>> 32-bit case alongside the change you're already making. >>>>>>> >>>>>>> AFAICT Linux 32-bit doesn't have this padding. So wouldn't it make >>>>>>> incompatible the two incompatible? >>>>>> >>>>>> In principle yes. But they're putting the structure instance on the >>>>>> stack, so there's not risk from Xen reading 4 bytes too many. I'd >>>>>> prefer keeping the interface as is (i.e. with the previously >>>>>> implicit padding made explicit) to avoid risking to break other >>>>>> possible callers. But that's just my view on it, anyway ... >>>>> >>>>> Adding the padding is cleaner because we don't need any compat stuff >>>>> in order to access the structure from the caller, and we also keep the >>>>> original layout currently present on Xen headers. >>>>> >>>>> I can prepare a fix for the Linux kernel, if this approach is fine. >>>> >>>> So I went over this, and I'm not sure the point of adding the padding >>>> field at the end of the structure for 32bit x86. >>>> >>>> The current situation is the following: >>>> >>>> - Linux will use a struct on 32bit x86 that doesn't have the 4byte >>>> padding at the end. >>>> - Xen will copy 4bytes of garbage in that case, since the struct on >>>> Linux is allocated on the stack. >>>> >>>> So I suggest we take the approach found on this patch, that is remove >>>> the 8byte alignment from the frame field, which will in turn remove >>>> 4bytes of padding from the tail of the structure on 32bit x86. >>>> >>>> That would leave the following scenario: >>>> >>>> - The struct layout in Linux headers would be correct. >>>> - Xen already handles the struct size difference on x86 32bit vs >>>> 64bit, as the compat layer is currently doing the copy in >>>> compat_memory_op taking into account the size of the compat >>>> structure. >>> >>> Hmm, I didn't even notice this until now - it looks to do so >>> indeed, but apparently because of a bug: The original >>> uint64_aligned_t gets translated to mere uint64_t in the >>> compat header, whereas it should have been retained. This >>> means that my concern of ... >>> >>>> - Removing the padding will work for all use cases: Linux will >>>> already be using the correct layout on x86 32bits, so no change >>>> will be required there. Any consumers using the tail padded >>>> structure will continue to work without issues, as Xen simply won't >>>> copy the tailing 4bytes. >>> >>> ... code using the new definition then potentially not working >>> correctly on 4.13, at least on versions not having this >>> backported, was not actually true. >>> >>> I'll try to sort out this other bug then ... >> >> I was wrong, there is no bug - translating uint64_aligned_t to >> uint64_t is fine, as these are seen only by 64-bit code, where >> both are identical anyway. Hence there still is the concern that >> code working fine on the supposed 4.14 might then not work on >> unfixed 4.13, due to 4.13 copying 4 extra bytes. > > So here are the structures on 64bit x86 according to pahole against > xen-syms: > > struct xen_mem_acquire_resource { > domid_t domid; /* 0 2 */ > uint16_t type; /* 2 2 */ > uint32_t id; /* 4 4 */ > uint32_t nr_frames; /* 8 4 */ > uint32_t pad; /* 12 4 */ > uint64_t frame; /* 16 8 */ > __guest_handle_xen_pfn_t frame_list; /* 24 8 */ > > /* size: 32, cachelines: 1, members: 7 */ > /* last cacheline: 32 bytes */ > }; > > struct compat_mem_acquire_resource { > domid_compat_t domid; /* 0 2 */ > uint16_t type; /* 2 2 */ > uint32_t id; /* 4 4 */ > uint32_t nr_frames; /* 8 4 */ > uint32_t pad; /* 12 4 */ > uint64_t frame; /* 16 8 */ > __compat_handle_compat_pfn_t frame_list; /* 24 4 */ > > /* size: 28, cachelines: 1, members: 7 */ > /* last cacheline: 28 bytes */ > }; > > There's no tailing padding on the compat struct ATM, and hence the > current code will behave correctly when used against a compat > structure without the tailing padding (as it's already ignored). > > There's a #pragma pack(4) at the top of compat/memory.h which forces > this AFAICT. So I think the suggested approach is fine and will avoid > any breakage. Oh, so I was mislead to believe there's no bug with the uint64_aligned_t handling because, after having it made survive the compat header generation, the generated code didn't change. But that's only because the aligned() attribute has no effect in a #pragma pack() region, not because things work as intended. So indeed, another 180° turn later, I again agree your change - with an extended description - ought to be fine. The bug we'll have to deal with has become more difficult now, though: We can't use #pragma pack() then, but we also can't attach packed attributes to the structs and unions, as that would force 1-byte packing instead of 4-byte one. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:33:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:33:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqLW-0006V7-Ty; Fri, 26 Jun 2020 15:32:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqLV-0006V2-ET for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:32:53 +0000 X-Inumbo-ID: 4b95307e-b7c2-11ea-bb8b-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.81]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 4b95307e-b7c2-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 15:32:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593185570; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RTWe4soL1srkDL8PEEfq928W6GWa5t1pS8aCmfU8LHE=; b=NWi7+XgbhSCSK/wUfpqjFdV1YJFwxlJVxR/Myy/rufNo6jwZ5OZNxhsUv4yrvVQH8JtLx4 alR3Jm0vQgOXdc98glkWdTOP6Kt0ma7joFXjZQcoH8SizrS481WnGA6huSziR/aGfNIxkN Y/z8ohnJKJXXSXjvxTOggDRu+gid3ng= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-321-pC9Pyyy7MDugmDxvhj-VYw-1; Fri, 26 Jun 2020 11:32:48 -0400 X-MC-Unique: pC9Pyyy7MDugmDxvhj-VYw-1 Received: by mail-wm1-f71.google.com with SMTP id v24so11736402wmh.3 for ; Fri, 26 Jun 2020 08:32:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RTWe4soL1srkDL8PEEfq928W6GWa5t1pS8aCmfU8LHE=; b=sp98Xf8wl89+oimxBAtLhZ/SASjSJZBg92IrtaiL74U+WqZ+3fZ4CzwZiCP8BTVvfm YEUsSKAMfXlyVDovOtKjitRQrfLNYnDCBjO2qSg3EKG+vKzzGH1YY5B3LHIuom7REC5+ draqtlNTmbDXv4W61qyZTUggM8oDDXTPtETDS4YqvBERAVH3UgvG2FXsnkLSAKfihNt8 PeCu+rLADJgDLDq9qhDcnBj5OElqesreElm98MbVSI0zlaDRzFY2OUOFKEA253lgCIvq Tc5+4ljSSV8RWpVAqZuqel2xzW9i6of3yN7+5hq+IL5pheuCYGnqtJEBHDt2ry2miNKw qXMQ== X-Gm-Message-State: AOAM533w5xF6hQTBeXZBhsLTDVsJ60eigPUGzkCqsbAyoZZudi1Vhqyi EkjwOsdY3+UlxJrsoAVhxgLuU/yQxG8rCdF9cOKTUArXDAVzELG1j3jiTXDXc6Sstpo4aoAaKtC N2UHv42aOv/l/oNTeuJZN1fHbV1o= X-Received: by 2002:a5d:55cb:: with SMTP id i11mr4167955wrw.28.1593185566631; Fri, 26 Jun 2020 08:32:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKcm6jtqvubhG72TQoDWqW1duiFh/JDhCCKL54qZ+AftyQ9QDCAEubqgx6Fkb+6w/6lcA4Aw== X-Received: by 2002:a5d:55cb:: with SMTP id i11mr4167932wrw.28.1593185566346; Fri, 26 Jun 2020 08:32:46 -0700 (PDT) Received: from redhat.com (bzq-79-182-31-92.red.bezeqint.net. [79.182.31.92]) by smtp.gmail.com with ESMTPSA id 65sm18427582wma.48.2020.06.26.08.32.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 08:32:45 -0700 (PDT) Date: Fri, 26 Jun 2020 11:32:41 -0400 From: "Michael S. Tsirkin" To: Stefano Stabellini Subject: Re: [PATCH] xen: introduce xen_vring_use_dma Message-ID: <20200626110629-mutt-send-email-mst@kernel.org> References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Peng Fan , konrad.wilk@oracle.com, jasowang@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, linux-imx@nxp.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote: > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote: > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma APIs to map the > > > > > > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > > > > > > disabled, it is not required. > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate > > > > > foreign mappings (memory coming from other VMs) to physical addresses. > > > > > On x86, it also uses dma_ops to translate Linux's idea of a physical > > > > > address into a real physical address (this is unneeded on ARM.) > > > > > > > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > > > > > always and on Xen/ARM if Linux is Dom0 (because it has foreign > > > > > mappings.) That is why we have the if (xen_domain) return true; in > > > > > vring_use_dma_api. > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > > > > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > > > Unfortunately as a result Xen never got around to > > > > properly setting VIRTIO_F_IOMMU_PLATFORM. > > > > > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this because > > > the usage of swiotlb_xen is not a property of virtio, > > > > > > Basically any device without VIRTIO_F_ACCESS_PLATFORM > > (that is it's name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is > > what linux calls it) is declared as "special, don't follow normal rules > > for access". > > > > So yes swiotlb_xen is not a property of virtio, but what *is* a property > > of virtio is that it's not special, just a regular device from DMA POV. > > I am trying to understand what you meant but I think I am missing > something. > > Are you saying that modern virtio should always have > VIRTIO_F_ACCESS_PLATFORM, hence use normal dma_ops as any other devices? I am saying it's a safe default. Clear VIRTIO_F_ACCESS_PLATFORM if you have some special needs e.g. you are very sure it's ok to bypass DMA ops, or you need to support a legacy guest (produced in the window between virtio 1 support in 2014 and support for VIRTIO_F_ACCESS_PLATFORM in 2016). > If that is the case, how is it possible that virtio breaks on ARM using > the default dma_ops? The breakage is not Xen related (except that Xen > turns dma_ops on). The original message from Peng was: > > vring_map_one_sg -> vring_use_dma_api > -> dma_map_page > -> __swiotlb_map_page > ->swiotlb_map_page > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, dev_addr)), size, dir); > However we are using per device dma area for rpmsg, phys_to_virt > could not return a correct virtual address for virtual address in > vmalloc area. Then kernel panic. > > I must be missing something. Maybe it is because it has to do with RPMesg? I think it's an RPMesg bug, yes. > > > > > > You might have noticed that I missed one possible case above: Xen/ARM > > > > > DomU :-) > > > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if > > > > > (xen_domain) return true; would give the wrong answer in that case. > > > > > Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and > > > > > the "normal" dma_ops fail. > > > > > > > > > > > > > > > The solution I suggested was to make the check in vring_use_dma_api more > > > > > flexible by returning true if the swiotlb_xen is supposed to be used, > > > > > not in general for all Xen domains, because that is what the check was > > > > > really meant to do. > > > > > > > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is wrong with that? > > > > > > swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops are the > > > ones that are used. So you are saying, why don't we fix the default > > > dma_ops to work with virtio? > > > > > > It is bad that the default dma_ops crash with virtio, so yes I think it > > > would be good to fix that. However, even if we fixed that, the if > > > (xen_domain()) check in vring_use_dma_api is still a problem. > > > > Why is it a problem? It just makes virtio use DMA API. > > If that in turn works, problem solved. > > You are correct in the sense that it would work. However I do think it > is wrong for vring_use_dma_api to enable dma_ops/swiotlb-xen for Xen/ARM > DomUs that don't need it. There are many different types of Xen guests, > Xen x86 is drastically different from Xen ARM, it seems wrong to treat > them the same way. I could imagine some future Xen hosts setting a flag somewhere in the platform capability saying "no xen specific flag, rely on "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU. How about that? > > > Anyway, re-reading the last messages of the original thread [1], it > looks like Peng had a clear idea on how to fix the general issue. Peng, > what happened with that? > > > [1] https://lore.kernel.org/patchwork/patch/1033801/#1222404 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:33:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:33:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqLb-0006VL-5c; Fri, 26 Jun 2020 15:32:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqLa-0006V2-8x for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:32:58 +0000 X-Inumbo-ID: 4d41e4ee-b7c2-11ea-bb8b-bc764e2007e4 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (unknown [40.107.3.58]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4d41e4ee-b7c2-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 15:32:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0mj838u9ouUx0Gl/m9ATFQDzRi6gcd/SQw8RLH6xw2U=; b=WbNorJr5LRjfG7mYpQK5L4JDt2oqndO8v7zRPhDXWe++Ev4FTZvmPlnpbFfawdL6B1hjI5dyaQhHVGiWNAkMgOzjEoMqt7a1xtgUEoYwufTkIAS3HHhZ1k+TrS+LB/ijinWlEZIlRGsuMFqd348EI8L5mNt3YdVKLG07g4vPL84= Received: from DB3PR08CA0020.eurprd08.prod.outlook.com (2603:10a6:8::33) by DB6PR0801MB2008.eurprd08.prod.outlook.com (2603:10a6:4:77::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Fri, 26 Jun 2020 15:32:52 +0000 Received: from DB5EUR03FT048.eop-EUR03.prod.protection.outlook.com (2603:10a6:8:0:cafe::3a) by DB3PR08CA0020.outlook.office365.com (2603:10a6:8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend Transport; Fri, 26 Jun 2020 15:32:52 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; lists.xenproject.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;lists.xenproject.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT048.mail.protection.outlook.com (10.152.21.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Fri, 26 Jun 2020 15:32:52 +0000 Received: ("Tessian outbound 1e00bf306733:v60"); Fri, 26 Jun 2020 15:32:52 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 1e4ac0d027b81c41 X-CR-MTA-TID: 64aa7808 Received: from 5779f0dc0236.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8CA2335C-68CC-4D9E-A275-FBACBC9EB87B.1; Fri, 26 Jun 2020 15:32:47 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5779f0dc0236.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 26 Jun 2020 15:32:47 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+AyDN8GdwN8/e2yb0KntjUfxJkjzn7tl00eeIrkPK/EJn48IdcUO6oooMWLL+YBT+77jp5M/IJMxVTXEBuUd4ZMSu1e+5o50HStmhG8YNuDmBVGmz2rgN1Jq95xB5IjLt6vVatno8vEqk8g83LQ2aer1Hy/2Xrh7oIxIKFIfWYxOLNmV3fYXGKmKNgtMpaHp2u62pMAyO//2sD5f3a+0me7ez0DCZM2LL1so39Qmad1OLaGI6DTFr6n2zwIZMJ7Bjfpk0LsbC5hy4Xn0Fwr8zulVdgjtG0RIbX4yznL+x8XEavJG7Z6IN3Wc6CoW1ncFChIYq2bIhYh/kXsZ8up3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0mj838u9ouUx0Gl/m9ATFQDzRi6gcd/SQw8RLH6xw2U=; b=U+00w6qcfyqms4uXPoOWzWcy1aj0GIN8DAQrAkYwtHWgz/pqwcmBP4I4NpX+5rkC4eFS/SN1Eo3jzJ0N7B5bd4ruaHtQh08pDz+BNY1HjZ7bVWjF40tD614s284YAIiNK+h1fcjR7BO6Ml1BtRii8GKl8dxbcKilCAFPzQguDd/GpI9M2nu4xdymXMVTu7HDaekw7c4m4MBRACt+pI+zstRm39aQ2n0/2/NBOexmLXRDZToZDJ+OVh7ZKKoImqyaNjaoGsp0YcDB0AidrXzLVhrAVcMWCsEgS9oQjWF9SU8Eu8EPxhi+2d+HzRu7Is5BUaiVw9YGVMwojEw8XGJ47g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0mj838u9ouUx0Gl/m9ATFQDzRi6gcd/SQw8RLH6xw2U=; b=WbNorJr5LRjfG7mYpQK5L4JDt2oqndO8v7zRPhDXWe++Ev4FTZvmPlnpbFfawdL6B1hjI5dyaQhHVGiWNAkMgOzjEoMqt7a1xtgUEoYwufTkIAS3HHhZ1k+TrS+LB/ijinWlEZIlRGsuMFqd348EI8L5mNt3YdVKLG07g4vPL84= Received: from DB7PR08MB3689.eurprd08.prod.outlook.com (2603:10a6:10:79::16) by DB6PR0801MB1798.eurprd08.prod.outlook.com (2603:10a6:4:3c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.23; Fri, 26 Jun 2020 15:32:45 +0000 Received: from DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8]) by DB7PR08MB3689.eurprd08.prod.outlook.com ([fe80::4001:43ad:d113:46a8%5]) with mapi id 15.20.3131.023; Fri, 26 Jun 2020 15:32:44 +0000 From: Bertrand Marquis To: Jan Beulich Subject: Re: [PATCH] build: tweak variable exporting for make 3.82 Thread-Topic: [PATCH] build: tweak variable exporting for make 3.82 Thread-Index: AQHWS8ssTlAGR1rYpUSLc7qQddQ2bajrBnwA Date: Fri, 26 Jun 2020 15:32:44 +0000 Message-ID: <7736F1FB-A564-419A-9F49-8860502C5A2A@arm.com> References: <0677fe2a-9ea1-7b3c-e212-4a2478537459@suse.com> In-Reply-To: <0677fe2a-9ea1-7b3c-e212-4a2478537459@suse.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.24.250.194] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 6acf955d-b15c-49b8-790c-08d819e630be x-ms-traffictypediagnostic: DB6PR0801MB1798:|DB6PR0801MB2008: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0446F0FCE1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: jlzQ2NVkD2MJhqiqbaUm4Mtsn2lSU3WeabJ48aajCURQOfb0Qd3Jyh9ZV7VGffW8xRXlyRbof6KAx1c+f1aeKiNfSmXQtBl5J5Hv9HoFJ2jqZW0jdaYHQT3rS09jvhMlrzc2aKkuecJ1vZiZAMl0j5soLbLUmXRbzxJVYi8bVNucvM6TB/LNaUEHOXAmAx9dHSGZpOST8PABgFirGXvKQCvuqV4qQatpwa5cEvFZF/WYjLLXQXYCEa5h9pNT0CT9W/t/VA4Clnvy2FFU8v/w8KWbGNn+8hnDZCKb6zqaRNy/RG1xLvMP74VnLJ2UIGK7SkP9x17QWQLddUKFJk8/2A== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3689.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(376002)(346002)(136003)(39860400002)(54906003)(66556008)(66446008)(64756008)(86362001)(91956017)(76116006)(71200400001)(66946007)(6512007)(66476007)(316002)(6486002)(53546011)(2616005)(6506007)(26005)(4326008)(186003)(6916009)(7416002)(36756003)(478600001)(5660300002)(2906002)(8936002)(8676002)(33656002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: uc6EZ5ovZg5Cj0VElH2JaCexdIHzyAN+cUVmtTEBGOuH365fhxNtz6aL2EUAiYEftSA6lsMo1P8SSoFvzy4jz+VcNhZdyqp/XjOt4YHKscxIXiRWj1RT5DudW6j+5LgflCchCfrU5/GKSEY+Ay2KoBqd9VhOLXqkzPj3ZsG3fykq4veSk5V/EUB90sSzedx0/+E+S3HImovy+7htvd+R7VrSYQRIbbbAkdy9maOykNc7lQeRrCi3fFjSfFloaBsjIIz01tp4LckdnjUQiw1XjdyBtTaZosL3ow+jzS7kPsxffcImW97HtsFn4SEkslyJ+tPu2Z0W24oAmn1JNr0QSreN/iNZ6Z96/Wr5zFtfMCVlCoPjlmTjHAVkSlA3crKCCgFC7CtZbiPwuctnah6HwXTAD7flxwaVwKPRagSKBBNswAJdYvDMBHGgiP11R9bO1v8eaAraBNjfNVr2vkQ9LO76QJB3whQ2Yk4oiyd9IHM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: <9027C811AA7D764BBCFD0BABD16A12B8@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1798 Original-Authentication-Results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT048.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(346002)(396003)(376002)(46966005)(82740400003)(81166007)(53546011)(8936002)(6506007)(2906002)(316002)(70206006)(33656002)(70586007)(83380400001)(4326008)(2616005)(186003)(26005)(6862004)(54906003)(86362001)(47076004)(336012)(6512007)(36756003)(6486002)(356005)(8676002)(82310400002)(5660300002)(478600001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: f63ee55c-4741-4852-4d08-08d819e62c53 X-Forefront-PRVS: 0446F0FCE1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fXL9HINAnQpNiga49XSnRHaorMokk9IwcrgalnOA10nIIh8NmI9jxSD5KZqIMcFO+usUbYrqkL931cLl5syTsG6EGW1nFhvS6IfvpODGcQh4sUiV4dzQLpQiB5XRAnKLZa/+b/qG3vn/3NMAHkT8HmiHtWjDKUvSH5DR8pR83pwUO10qYrabd6Y63DCja5qcpKdpAOMIGwEntsc+iCQVcsfUrurAWh+z7wp1w1oLC8OHpfNN7WHL5RuyP9Gv2BAMjf7hl7/HL+3PgZ/Os1eQVRG4ltBRfS+CD1vQ23fD6NKiQc6+ovUO32Em7I/wqiIU5/hRTx+RP4UOdqK/qMzDjVCH/CFvz5MRk9akitiorPxeIpHQULA0wHSKU/C0N8K+cdqNj8IpWcSbt2HXj3yZMA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jun 2020 15:32:52.3816 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6acf955d-b15c-49b8-790c-08d819e630be X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT048.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB2008 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , George Dunlap , Andrew Cooper , Ian Jackson , Anthony Perard , "xen-devel@lists.xenproject.org" , nd Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Jan, > On 26 Jun 2020, at 16:02, Jan Beulich wrote: >=20 > While I've been running into an issue here only because of an additional > local change I'm carrying, to be able to override just the compiler in > $(XEN_ROOT)/.config (rather than the whole tool chain), in > config/StdGNU.mk: >=20 > ifeq ($(filter-out default undefined,$(origin CC)),) >=20 > I'd like to propose to nevertheless correct the underlying issue: > Exporting an unset variable changes its origin from "undefined" to > "file". This comes into effect because of our adding of -rR to > MAKEFLAGS, which make 3.82 wrongly applies also upon re-invoking itself > after having updated auto.conf{,.cmd}. >=20 > Move the export statement past $(XEN_ROOT)/config/$(XEN_OS).mk inclusion > such that the variables already have their designated values at that > point, while retaining their initial origin up to the point they get > defined. If I understand correctly you actually need this to be after=20 include $(XEN_ROOT)/Config.mk Which actually includes the .config and the StdGNU.mk Maybe you could say this as $(XEN_ROOT)/config/$(XEN_OS).mk is not actually= included directly in the Makefile itself ? I tested the patch and it works on arm and x86 on my side. >=20 > Signed-off-by: Jan Beulich Tested-by: Bertrand Marquis >=20 > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -17,8 +17,6 @@ export XEN_BUILD_HOST ?=3D $(shell hostnam > PYTHON_INTERPRETER :=3D $(word 1,$(shell which python3 python python2 2>/= dev/null) python) > export PYTHON ?=3D $(PYTHON_INTERPRETER) >=20 > -export CC CXX LD > - > export BASEDIR :=3D $(CURDIR) > export XEN_ROOT :=3D $(BASEDIR)/.. >=20 > @@ -42,6 +40,8 @@ export TARGET_ARCH :=3D $(shell echo $ > # Allow someone to change their config file > export KCONFIG_CONFIG ?=3D .config >=20 > +export CC CXX LD > + > .PHONY: default > default: build >=20 >=20 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:37:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:37:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqPT-0006kH-Oi; Fri, 26 Jun 2020 15:36:59 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqPS-0006jr-Q8 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:36:58 +0000 X-Inumbo-ID: db6fe338-b7c2-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id db6fe338-b7c2-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 15:36:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EIe2AnPWPaUfBTn0PurlGUJwREOLxiDfdL/Cu5+TIV8=; b=SXzfjTkkXAwhBVlrlGD8AFflM t9+93YJyzeuoQWxOOq+gg6oq3PMNl2QhTMR6kaWm5XUFJNa34MhWox/ixt/4DuksLoW0dXb8kQD4a nbTqKiFseZ9tv+MmTICzE31TJgET3KwXIlFvO+TO2lPQXfc3e7gW6D64wsL+A0mZRmgP8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqPL-0006yQ-VC; Fri, 26 Jun 2020 15:36:52 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joqPL-0007XI-KX; Fri, 26 Jun 2020 15:36:51 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joqPL-00042I-Jp; Fri, 26 Jun 2020 15:36:51 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151358: tolerable FAIL X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-vhd:guest-start/debian.repeat:fail:heisenbug xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=fde76f895d0aa817a1207d844d793239c6639bc6 X-Osstest-Versions-That: xen=fde76f895d0aa817a1207d844d793239c6639bc6 From: osstest service owner Date: Fri, 26 Jun 2020 15:36:51 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151358 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151358/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail pass in 151334 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151334 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151334 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151334 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151334 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151334 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151334 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151334 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151334 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151334 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen fde76f895d0aa817a1207d844d793239c6639bc6 baseline version: xen fde76f895d0aa817a1207d844d793239c6639bc6 Last test of basis 151358 2020-06-25 10:54:19 Z 1 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:40:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:40:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqSY-0007YA-C3; Fri, 26 Jun 2020 15:40:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqSW-0007Y4-Rg for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:40:08 +0000 X-Inumbo-ID: 4fb8982a-b7c3-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 4fb8982a-b7c3-11ea-bca7-bc764e2007e4; Fri, 26 Jun 2020 15:40:07 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: /5VOdIWJ0MeIXeWPlncNGlg2m0KLFGjmtBDH4eRiW3TJeFGSGFz7nnYQdJlNXA89nwZZ8hwx4R fpWnGtnJx9Zq128WdeIli8yJr3SSUDjF6IHCpOBJng5nrApvWbaRcI9nyOuywyTZobFcO9yKwl IzTCButeBh3cThHU6s1ZsRH028/Din4D53VtcAIfe+855VbHpvjh3zh4NU49YneKn0HIREK3hr lFpPPyVqoulex0hCys6+Og1VLAbGSmLmSYQw6MsBDYn7ZC7cuhYZaCvebvm679lJ4+fMNK8GiF 5IY= X-SBRS: 2.7 X-MesageID: 21380212 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21380212" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v3] mm: fix public declaration of struct xen_mem_acquire_resource Date: Fri, 26 Jun 2020 17:39:51 +0200 Message-ID: <20200626153951.91301-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" XENMEM_acquire_resource and it's related structure is currently inside a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the hypervisor or the toolstack only. This is wrong as the hypercall is already being used by the Linux kernel at least, and as such needs to be public. Also switch the usage of uint64_aligned_t to plain uint64_t, as uint64_aligned_t is only to be used by the toolstack. Doing such change will reduce the size of the structure on 32bit x86 by 4bytes, since there will be no padding added after the frame_list handle. This is fine, as users of the previous layout will allocate 4bytes of padding that won't be read by Xen, and users of the new layout won't allocate those, which is also fine since Xen won't try to access them. Note that the structure already has compat handling, and such handling will take care of copying the right size (ie: minus the padding) when called from a 32bit x86 context. This is true for the compat code both before and after this patch, since the structures in the memory.h compat header are subject to a pragma pack(4), which already removed the trailing padding that would otherwise be introduced by the alignment of the frame field to 8 bytes. Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire guest resources') Signed-off-by: Roger Pau Monné --- Should also be backported. --- Changes since v2: - Remove the tail padding. - Expand commit message. Changes since v1: - Add padding on 32bits so structure size matches between arches and the previous layout is kept. --- xen/include/public/memory.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index 850bd72c52..21057ed78e 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -610,6 +610,8 @@ struct xen_reserved_device_memory_map { typedef struct xen_reserved_device_memory_map xen_reserved_device_memory_map_t; DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ + /* * Get the pages for a particular guest resource, so that they can be * mapped directly by a tools domain. @@ -648,7 +650,7 @@ struct xen_mem_acquire_resource { * IN - the index of the initial frame to be mapped. This parameter * is ignored if nr_frames is 0. */ - uint64_aligned_t frame; + uint64_t frame; #define XENMEM_resource_ioreq_server_frame_bufioreq 0 #define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n)) @@ -669,8 +671,6 @@ struct xen_mem_acquire_resource { typedef struct xen_mem_acquire_resource xen_mem_acquire_resource_t; DEFINE_XEN_GUEST_HANDLE(xen_mem_acquire_resource_t); -#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ - /* * XENMEM_get_vnumainfo used by guest to get * vNUMA topology from hypervisor. -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:41:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:41:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqTn-0007dY-NQ; Fri, 26 Jun 2020 15:41:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqTl-0007dR-Vd for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:41:26 +0000 X-Inumbo-ID: 7df3be4a-b7c3-11ea-8496-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7df3be4a-b7c3-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 15:41:25 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id t194so9786927wmt.4 for ; Fri, 26 Jun 2020 08:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=BeD/NHdZkIwfRDP6Mg2PFeXR7Ht20SKficQIwODTwKE=; b=juIx2IErCdzA58VHHhTYRcHusmxp0wr25UXxy9cAZJPLes69Pi98I4cyTwlgeU8kDO jD9lJWib/6jkKFoaGk5md96DVDUvE4P+YzwSW12/KX9y4rMhjd5kEyUYviBDsFe65F9X vJO8RBF+hpQhnYHOPyWrIOOCnHuN1LbXfStAg3rUnSN0g5o0JQIFB+8r0daWLgjdSjUT HrcJBGbFEUHZ/r5ewtPz54Au/dQ+SPGu6vn2wqs9yYiNzPJ3bBN1293Z0JFa3wQNjdh1 /ZHQVv82QQtTqgd67O3F3m/lLKpo87LHdEPllQGDIlkw6M63YlmcfiHrfNBDnWKiDkqM xr0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=BeD/NHdZkIwfRDP6Mg2PFeXR7Ht20SKficQIwODTwKE=; b=shb1tFPX8+07Be+JdphvzK3/yw5QTpazwyv7fVqnlLbpm6lI5Wo6/gzgEmPcSD2aQ5 iBnHmrjtoW5cY+23PW3+rgY0YdiBgV3CccOLPmC1xtEcLKwe4G+KxpGL1eciYDEM2McJ k91+DFoGCii7oYXTHOAEeD7Jqvn8ihrG80kbJRqr+d+YQgyV0f97Erh6Xkoxyr4OMnFj /ltmk5F4tXUDUe7ADn6BDJvkYlDSGrv01TLkkmZADx4rH1H1nWBUD/Xppj0zl+x/Oyqj CFrqkHEnF70y4KUcdIs+eoT3j3F3J8VZegqE49S9o+ioBY142CDvUFJOIZvNC0haXs2w kDUQ== X-Gm-Message-State: AOAM531iw2NOI0jtfFm+8M3u4t+LZDPlXSR0VPTNn0NROw7BcdDx2Tvf 9zg5LNuoAnrSO872yKul3Wo= X-Google-Smtp-Source: ABdhPJzVdH4frkVQdmuGgxYwMnxlrU3VGxHCZ5OOXBRHbvC7WBt0Ub/d6aV5aLGjKXCugiiJCkz4gg== X-Received: by 2002:a1c:2157:: with SMTP id h84mr3999191wmh.35.1593186084475; Fri, 26 Jun 2020 08:41:24 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-236.amazon.com. [54.240.197.236]) by smtp.gmail.com with ESMTPSA id b62sm7393080wmh.38.2020.06.26.08.41.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 08:41:24 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Roger Pau Monne'" , References: <20200626153951.91301-1-roger.pau@citrix.com> In-Reply-To: <20200626153951.91301-1-roger.pau@citrix.com> Subject: RE: [PATCH for-4.14 v3] mm: fix public declaration of struct xen_mem_acquire_resource Date: Fri, 26 Jun 2020 16:41:22 +0100 Message-ID: <000f01d64bd0$3f3c5e50$bdb51af0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIIgSIxQb0hh/+C7e70wUGvND+TKaiGnhrQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Roger Pau Monne > Sent: 26 June 2020 16:40 > To: xen-devel@lists.xenproject.org > Cc: paul@xen.org; Roger Pau Monne ; Andrew = Cooper ; > George Dunlap ; Ian Jackson = ; Jan Beulich > ; Julien Grall ; Stefano Stabellini = ; Wei > Liu > Subject: [PATCH for-4.14 v3] mm: fix public declaration of struct = xen_mem_acquire_resource >=20 > XENMEM_acquire_resource and it's related structure is currently inside > a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > hypervisor or the toolstack only. This is wrong as the hypercall is > already being used by the Linux kernel at least, and as such needs to > be public. >=20 > Also switch the usage of uint64_aligned_t to plain uint64_t, as > uint64_aligned_t is only to be used by the toolstack. Doing such > change will reduce the size of the structure on 32bit x86 by 4bytes, > since there will be no padding added after the frame_list handle. >=20 > This is fine, as users of the previous layout will allocate 4bytes of > padding that won't be read by Xen, and users of the new layout won't > allocate those, which is also fine since Xen won't try to access them. >=20 > Note that the structure already has compat handling, and such handling > will take care of copying the right size (ie: minus the padding) when > called from a 32bit x86 context. This is true for the compat code both > before and after this patch, since the structures in the memory.h > compat header are subject to a pragma pack(4), which already removed > the trailing padding that would otherwise be introduced by the > alignment of the frame field to 8 bytes. >=20 > Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire = guest resources') > Signed-off-by: Roger Pau Monn=C3=A9 Release-acked-by: Paul Durrant > --- > Should also be backported. > --- > Changes since v2: > - Remove the tail padding. > - Expand commit message. >=20 > Changes since v1: > - Add padding on 32bits so structure size matches between arches and > the previous layout is kept. > --- > xen/include/public/memory.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) >=20 > diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h > index 850bd72c52..21057ed78e 100644 > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -610,6 +610,8 @@ struct xen_reserved_device_memory_map { > typedef struct xen_reserved_device_memory_map = xen_reserved_device_memory_map_t; > DEFINE_XEN_GUEST_HANDLE(xen_reserved_device_memory_map_t); >=20 > +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ > + > /* > * Get the pages for a particular guest resource, so that they can be > * mapped directly by a tools domain. > @@ -648,7 +650,7 @@ struct xen_mem_acquire_resource { > * IN - the index of the initial frame to be mapped. This = parameter > * is ignored if nr_frames is 0. > */ > - uint64_aligned_t frame; > + uint64_t frame; >=20 > #define XENMEM_resource_ioreq_server_frame_bufioreq 0 > #define XENMEM_resource_ioreq_server_frame_ioreq(n) (1 + (n)) > @@ -669,8 +671,6 @@ struct xen_mem_acquire_resource { > typedef struct xen_mem_acquire_resource xen_mem_acquire_resource_t; > DEFINE_XEN_GUEST_HANDLE(xen_mem_acquire_resource_t); >=20 > -#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ > - > /* > * XENMEM_get_vnumainfo used by guest to get > * vNUMA topology from hypervisor. > -- > 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:52:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:52:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqdy-00008x-Rj; Fri, 26 Jun 2020 15:51:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqdx-00008s-Jw for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:51:57 +0000 X-Inumbo-ID: f63758fc-b7c4-11ea-bb8b-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f63758fc-b7c4-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 15:51:56 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 0lJSrdaqXpMSmFm373tlAlZB61UMvm0lLwD59tjYgbwC/7o4KSGQ61FJ9VF/+lfxSqoi/cQ2Vi HFLNWc6njcB32zKO9MHIWmrwzaQ/y6pQHWzM5I8X+nC3iKK1lLZJsQnBGYeWeAAradqEEZrifT ahISBU+9wxn7Ar3e2OcJz7ehlLn+G5jAGzDOpYf1XoBH8S0gBTjus5tppr3DwOIVn+nlXIolfW 3g7sgoRpyE8BKgCgq83TCVRWWnfJJjoDoYIN68Mb+aEZx3BRJwtxWurdPGgcx11cNmWoUQAo0k lMc= X-SBRS: 2.7 X-MesageID: 21047880 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21047880" From: George Dunlap To: xen-devel Subject: Preparing for the virtual XenSummit Thread-Topic: Preparing for the virtual XenSummit Thread-Index: AQHWS9G2nsaD3ksTdkWObqenNi29cw== Date: Fri, 26 Jun 2020 15:51:53 +0000 Message-ID: <94B7B6C8-C6CB-48A0-872F-90D4E1423528@citrix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <27D7CF6C0C0D034FB2D23CEED6623DFA@citrix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SGV5IGFsbCwNCg0KVGhlIHZpcnR1YWwgU3VtbWl0IHRoaXMgeWVhciB3aWxsIGJlIHNpZ25pZmlj YW50bHkgZGlmZmVyZW50IHRoYW4gYW4gaW4tcGVyc29uIGNvbmZlcmVuY2UuICBJbiBhbiBlZmZv cnQgdG8gbWFrZSB0aGUgZXZlbnQgYXMgdXNlZnVsIGFzIHBvc3NpYmxlLCBJ4oCZbSBpbnZpdGlu ZyBwZW9wbGUgdG8gam9pbiBtZSBmb3IgYSBicmFpbnN0b3JtaW5nIHNlc3Npb24gb24gTW9uZGF5 LCAyOSBKdW5lLCBhdCAzcG0gQlNULiAgVGhlIHB1cnBvc2Ugd291bGQgYmUgdG8gYnJhaW5zdG9y bSBob3cgd2UgY2FuIGVuY291cmFnZSB0aGUgc29ydHMgb2YgbWl4aW5nIC8gaGFsbHdheSBkaXNj dXNzaW9ucyAvIHJlbGF0aW9uc2hpcC1mb3JtaW5nIHRoYXQgaGFwcGVucyBhdCBhIG5vcm1hbCBp bi1wZXJzb24gc2Vzc2lvbi4gIFRoaXMgd291bGQgYmUgaWRlYWxseSBhIHNtYWxsZXIgbWVldGlu ZywgaGVsZCBvbiB0aGUgQkJCIGNvbmZlcmVuY2luZyBzb2Z0d2FyZSwgd2hlcmUgd2UgY2FuIGRp c2N1c3MgaWRlYXMgYW5kIHBvdGVudGlhbGx5IGV4cGVyaW1lbnQgd2l0aCB0aGUgZnVuY3Rpb25h bGl0eS4NCg0KSWYgeW914oCZcmUgaW50ZXJlc3RlZCwgZW1haWwgbWUgcHJpdmF0ZWx5IGFuZCBJ 4oCZbGwgc2VuZCB5b3UgYSBsaW5rIHRvIHRoZSByb29tIGJlZm9yZSB0aGUgc2Vzc2lvbiB0aW1l Lg0KDQpXZSBtYXkgYWxzbyBoYXZlIGEgbGFyZ2VyIOKAnHN0cmVzcy10ZXN04oCdIG9mIHRoZSBz eXN0ZW0gbGF0ZXIgdGhhdCB3ZWVrOyBzdGF5IHR1bmVkIGZvciBkZXRhaWxzLg0KDQogLUdlb3Jn ZQ== From xen-devel-bounces@lists.xenproject.org Fri Jun 26 15:57:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 15:57:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqjO-0000Jc-FH; Fri, 26 Jun 2020 15:57:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqjM-0000JX-Ru for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 15:57:32 +0000 X-Inumbo-ID: bd824f0d-b7c5-11ea-82d9-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bd824f0d-b7c5-11ea-82d9-12813bfff9fa; Fri, 26 Jun 2020 15:57:31 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: NbxHtEEkbYRjSxsaWR38jTk6lww7B8//41qY6kd6S13uNNPoQSX3fNmAf1/89F42zJJFzc++ED jV0Shb0Nwv/J0BC3mRIQwX74B1Uv3iRwPbuQ85+fXc5/GBDVyKfV8Q7LVHqgJ1viQllDrcWRDe pxYdZdDs7E/ILD7pRGeDkp6exf5XNXB0mPkNH7qw+Dq5sv8idPD3D4oviTjg8Jl6J1s1GsjhHJ 6heInIqUhEEasv4N6w4RzqRFIRfncvxlOem0OervtZHx81KvL1v4k7Plb9YnEteXmxpWNFIvSd G8c= X-SBRS: 2.7 X-MesageID: 21381968 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21381968" From: Roger Pau Monne To: Subject: [PATCH for-4.14 v4] x86/tlb: fix assisted flush usage Date: Fri, 26 Jun 2020 17:57:23 +0200 Message-ID: <20200626155723.91558-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Volodymyr Babchuk , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Commit e9aca9470ed86 introduced a regression when avoiding sending IPIs for certain flush operations. Xen page fault handler (spurious_page_fault) relies on blocking interrupts in order to prevent handling TLB flush IPIs and thus preventing other CPUs from removing page tables pages. Switching to assisted flushing avoided such IPIs, and thus can result in pages belonging to the page tables being removed (and possibly re-used) while __page_fault_type is being executed. Force some of the TLB flushes to use IPIs, thus avoiding the assisted TLB flush. Those selected flushes are the page type change (when switching from a page table type to a different one, ie: a page that has been removed as a page table) and page allocation. This sadly has a negative performance impact on the pvshim, as less assisted flushes can be used. Note the flush in grant-table code is also switched to use an IPI even when not strictly needed. This is done so that a common arch_flush_tlb_mask can be introduced and always used in common code. Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush using an IPI (flush_tlb_mask_sync, x86 only). Note that the flag is only meaningfully defined when the hypervisor supports PV or shadow paging mode, as otherwise hardware assisted paging domains are in charge of their page tables and won't share page tables with Xen, thus not influencing the result of page walks performed by the spurious fault handler. Just passing this new flag when calling flush_area_mask prevents the usage of the assisted flush without any other side effects. Note the flag is not defined on Arm. Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') Reported-by: Andrew Cooper Signed-off-by: Roger Pau Monné --- Changes since v3: - Introduce arch_flush_tlb_mask. Changes since v2: - Always do a physical IPI triggered flush in filtered_flush_tlb_mask, since it's always required by the current callers of the function. Changes since v1: - Add a comment describing the usage of FLUSH_FORCE_IPI (and why no modifications to flush_area_mask are required). - Use PGT_root_page_table instead of PGT_l4_page_table. - Also perform IPI flushes if configured with shadow paging support. - Use ifdef instead of if. --- xen/arch/arm/smp.c | 2 +- xen/arch/x86/mm.c | 12 +++++++++++- xen/common/grant_table.c | 2 +- xen/include/asm-arm/flushtlb.h | 2 +- xen/include/asm-x86/flushtlb.h | 25 +++++++++++++++++++++++++ xen/include/xen/mm.h | 2 +- 6 files changed, 40 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c index ce1fcc8ef9..5823a69d3e 100644 --- a/xen/arch/arm/smp.c +++ b/xen/arch/arm/smp.c @@ -5,7 +5,7 @@ #include #include -void flush_tlb_mask(const cpumask_t *mask) +void arch_flush_tlb_mask(const cpumask_t *mask) { /* No need to IPI other processors on ARM, the processor takes care of it. */ flush_all_guests_tlb(); diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e376fc7e8f..a0568a9346 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -2894,7 +2894,17 @@ static int _get_page_type(struct page_info *page, unsigned long type, ((nx & PGT_type_mask) == PGT_writable_page)) ) { perfc_incr(need_flush_tlb_flush); - flush_tlb_mask(mask); + if ( (x & PGT_type_mask) && + (x & PGT_type_mask) <= PGT_root_page_table ) + /* + * If page was a page table make sure the flush is + * performed using an IPI in order to avoid changing + * the type of a page table page under the feet of + * spurious_page_fault. + */ + flush_tlb_mask_sync(mask); + else + flush_tlb_mask(mask); } /* We lose existing type and validity. */ diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c index ece670e484..9f0cae52c0 100644 --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@ -393,7 +393,7 @@ static inline void grant_write_unlock(struct grant_table *gt) static inline void gnttab_flush_tlb(const struct domain *d) { if ( !paging_mode_external(d) ) - flush_tlb_mask(d->dirty_cpumask); + arch_flush_tlb_mask(d->dirty_cpumask); } static inline unsigned int diff --git a/xen/include/asm-arm/flushtlb.h b/xen/include/asm-arm/flushtlb.h index ab1aae5c90..125a141975 100644 --- a/xen/include/asm-arm/flushtlb.h +++ b/xen/include/asm-arm/flushtlb.h @@ -26,7 +26,7 @@ static inline void page_set_tlbflush_timestamp(struct page_info *page) #endif /* Flush specified CPUs' TLBs */ -void flush_tlb_mask(const cpumask_t *mask); +void arch_flush_tlb_mask(const cpumask_t *mask); /* * Flush a range of VA's hypervisor mappings from the TLB of the local diff --git a/xen/include/asm-x86/flushtlb.h b/xen/include/asm-x86/flushtlb.h index 8639427cce..6a107470e5 100644 --- a/xen/include/asm-x86/flushtlb.h +++ b/xen/include/asm-x86/flushtlb.h @@ -126,6 +126,16 @@ void switch_cr3_cr4(unsigned long cr3, unsigned long cr4); #else #define FLUSH_HVM_ASID_CORE 0 #endif +#if defined(CONFIG_PV) || defined(CONFIG_SHADOW_PAGING) +/* + * Force an IPI to be sent. Note that adding this to the flags passed to + * flush_area_mask will prevent using the assisted flush without having any + * other side effect. + */ +# define FLUSH_FORCE_IPI 0x8000 +#else +# define FLUSH_FORCE_IPI 0 +#endif /* Flush local TLBs/caches. */ unsigned int flush_area_local(const void *va, unsigned int flags); @@ -148,9 +158,24 @@ void flush_area_mask(const cpumask_t *, const void *va, unsigned int flags); /* Flush specified CPUs' TLBs */ #define flush_tlb_mask(mask) \ flush_mask(mask, FLUSH_TLB) +/* + * Flush specified CPUs' TLBs and force the usage of an IPI to do so. This is + * required for certain operations that rely on page tables themselves not + * being freed and reused when interrupts are blocked, as the flush IPI won't + * be fulfilled until exiting from that critical region. + */ +#define flush_tlb_mask_sync(mask) \ + flush_mask(mask, FLUSH_TLB | FLUSH_FORCE_IPI) #define flush_tlb_one_mask(mask,v) \ flush_area_mask(mask, (const void *)(v), FLUSH_TLB|FLUSH_ORDER(0)) +/* + * Alias the common code TLB flush helper to the sync one in order to be on the + * safe side. Note that not all calls from common code strictly require the + * _sync variant. + */ +#define arch_flush_tlb_mask flush_tlb_mask_sync + /* Flush all CPUs' TLBs */ #define flush_tlb_all() \ flush_tlb_mask(&cpu_online_map) diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index 9b62087be1..1061765bcd 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -648,7 +648,7 @@ static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp) if ( !cpumask_empty(&mask) ) { perfc_incr(need_flush_tlb_flush); - flush_tlb_mask(&mask); + arch_flush_tlb_mask(&mask); } } -- 2.26.2 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 16:02:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 16:02:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqoU-0001fC-33; Fri, 26 Jun 2020 16:02:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqoS-0001f7-WB for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 16:02:49 +0000 X-Inumbo-ID: 7ac44cdc-b7c6-11ea-82d9-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7ac44cdc-b7c6-11ea-82d9-12813bfff9fa; Fri, 26 Jun 2020 16:02:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RFOFVTcEa8tAypmAG7lbjo4Ee19rDpax2COry9cM/L0=; b=vHPWIqyKotMv7SnXlLvc0JFag XocxQtWgbodIzWSyZOtjuhIjpm57fiWXm3Eso1nIFBtQsVcG2WMgBkTyujvp86BIj/CjjY3STy/LF 96O33/6iRrT5Cx7+fqGwZ+ZnXVMyhZ7cW1leo8wsUqM5AAFAIy7bxjzxtEm2o0NOuc9w8=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqoR-00080b-QW; Fri, 26 Jun 2020 16:02:47 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joqoR-0000RO-6V; Fri, 26 Jun 2020 16:02:47 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joqoR-0007bM-5w; Fri, 26 Jun 2020 16:02:47 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [seabios test] 151363: tolerable FAIL - PUSHED X-Osstest-Failures: seabios:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking seabios:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking seabios:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: seabios=d11c75185276ded944f2ea0277532b7fee849bbc X-Osstest-Versions-That: seabios=dd6a7e99b1c32ca66048673442cc7152efd08d2d From: osstest service owner Date: Fri, 26 Jun 2020 16:02:47 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151363 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/151363/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151340 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151340 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151340 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151340 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: seabios d11c75185276ded944f2ea0277532b7fee849bbc baseline version: seabios dd6a7e99b1c32ca66048673442cc7152efd08d2d Last test of basis 151340 2020-06-24 16:10:05 Z 1 days Testing same since 151363 2020-06-25 19:05:11 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Gerd Hoffmann jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/seabios.git dd6a7e9..d11c751 d11c75185276ded944f2ea0277532b7fee849bbc -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Fri Jun 26 16:13:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 16:13:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqym-0002Zh-4V; Fri, 26 Jun 2020 16:13:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joqyk-0002Zc-7D for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 16:13:26 +0000 X-Inumbo-ID: f665bed8-b7c7-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f665bed8-b7c7-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 16:13:25 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3F800AF09; Fri, 26 Jun 2020 16:13:24 +0000 (UTC) Subject: Re: [PATCH] build: tweak variable exporting for make 3.82 To: Bertrand Marquis References: <0677fe2a-9ea1-7b3c-e212-4a2478537459@suse.com> <7736F1FB-A564-419A-9F49-8860502C5A2A@arm.com> From: Jan Beulich Message-ID: <297d1631-1379-1650-2363-8ea838384794@suse.com> Date: Fri, 26 Jun 2020 18:13:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <7736F1FB-A564-419A-9F49-8860502C5A2A@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , George Dunlap , Andrew Cooper , Ian Jackson , Anthony Perard , "xen-devel@lists.xenproject.org" , nd Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 17:32, Bertrand Marquis wrote: > Hi Jan, > >> On 26 Jun 2020, at 16:02, Jan Beulich wrote: >> >> While I've been running into an issue here only because of an additional >> local change I'm carrying, to be able to override just the compiler in >> $(XEN_ROOT)/.config (rather than the whole tool chain), in >> config/StdGNU.mk: >> >> ifeq ($(filter-out default undefined,$(origin CC)),) >> >> I'd like to propose to nevertheless correct the underlying issue: >> Exporting an unset variable changes its origin from "undefined" to >> "file". This comes into effect because of our adding of -rR to >> MAKEFLAGS, which make 3.82 wrongly applies also upon re-invoking itself >> after having updated auto.conf{,.cmd}. >> >> Move the export statement past $(XEN_ROOT)/config/$(XEN_OS).mk inclusion >> such that the variables already have their designated values at that >> point, while retaining their initial origin up to the point they get >> defined. > > If I understand correctly you actually need this to be after > include $(XEN_ROOT)/Config.mk > > Which actually includes the .config and the StdGNU.mk > Maybe you could say this as $(XEN_ROOT)/config/$(XEN_OS).mk is not > actually included directly in the Makefile itself ? I thought it would be obvious enough, but since you ask, I've added half a sentence. > I tested the patch and it works on arm and x86 on my side. > >> >> Signed-off-by: Jan Beulich > Tested-by: Bertrand Marquis Thanks much. Jan From xen-devel-bounces@lists.xenproject.org Fri Jun 26 17:01:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 17:01:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jorix-0006aB-U3; Fri, 26 Jun 2020 17:01:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joriw-0006a6-T8 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 17:01:10 +0000 X-Inumbo-ID: 9ff9bac0-b7ce-11ea-82ea-12813bfff9fa Received: from esa4.hc3370-68.iphmx.com (unknown [216.71.155.144]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9ff9bac0-b7ce-11ea-82ea-12813bfff9fa; Fri, 26 Jun 2020 17:01:07 +0000 (UTC) Authentication-Results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: ufexKxUoVzvf+iyp1rZjws5MHRIic1rcqUOdYgK0oKna6f6Lu7L94d9dRxKlNeKNrpjFlNt7iM udE3nwUWDd5g9ttBJpXWiY4ZnJW0HxMKqlVEYqKBQRakMl6g77wGHxkZxXCffTBqDVaPAqhqbG 7OMKXitkjm7iD2mxc3xTgF/FtGo+qbh+rKWyhq8UavQWV/RAB5BCaTWjadNUkX1kZDwZICL+VR SurNmuXTcCH7rEqt6XB6m4j3kcI0DLm2MdeeKTyRBVGNufF4iTFRxsJpApcgOoTgzEk8mUG/5X APs= X-SBRS: 2.7 X-MesageID: 21848203 X-Ironport-Server: esa4.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21848203" From: Andrew Cooper To: Xen-devel Subject: [PATCH] tools/configure: drop BASH configure variable Date: Fri, 26 Jun 2020 18:00:38 +0100 Message-ID: <20200626170038.27650-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Daniel De Graaf , Paul Durrant , Wei Liu , Ian Jackson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" This is a weird variable to have in the first place. The only user of it is XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only two scripts run with this are shebang sh anyway, so don't need bash in the first place. Make the mkflask.sh and mkaccess_vector.sh scripts executable, drop the CONFIG_SHELL, and drop the $BASH variable to prevent further use. Signed-off-by: Andrew Cooper --- CC: Ian Jackson CC: Wei Liu CC: Daniel De Graaf CC: Paul Durrant ./autogen.sh needs rerunning on commit. RFC for 4.14. This is a cleanup to the build system. There is a separate check for [BASH] in the configure script, which is checking the requirement for the Linux hotplug scripts. Really, that is a runtime requirement not a build time requirement, and it is rude to require bash in a build environment on this basis. IMO, that check wants dropping as well. --- config/Tools.mk.in | 1 - tools/configure.ac | 1 - xen/xsm/flask/Makefile | 8 ++------ xen/xsm/flask/policy/mkaccess_vector.sh | 0 xen/xsm/flask/policy/mkflask.sh | 0 5 files changed, 2 insertions(+), 8 deletions(-) mode change 100644 => 100755 xen/xsm/flask/policy/mkaccess_vector.sh mode change 100644 => 100755 xen/xsm/flask/policy/mkflask.sh diff --git a/config/Tools.mk.in b/config/Tools.mk.in index 23df47af8d..48bd9ab731 100644 --- a/config/Tools.mk.in +++ b/config/Tools.mk.in @@ -12,7 +12,6 @@ PYTHON := @PYTHON@ PYTHON_PATH := @PYTHONPATH@ PY_NOOPT_CFLAGS := @PY_NOOPT_CFLAGS@ PERL := @PERL@ -BASH := @BASH@ XGETTTEXT := @XGETTEXT@ AS86 := @AS86@ LD86 := @LD86@ diff --git a/tools/configure.ac b/tools/configure.ac index 9d126b7a14..6614a4f130 100644 --- a/tools/configure.ac +++ b/tools/configure.ac @@ -297,7 +297,6 @@ AC_ARG_VAR([PYTHON], [Path to the Python parser]) AC_ARG_VAR([PERL], [Path to Perl parser]) AC_ARG_VAR([BISON], [Path to Bison parser generator]) AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator]) -AC_ARG_VAR([BASH], [Path to bash shell]) AC_ARG_VAR([XGETTEXT], [Path to xgetttext tool]) AC_ARG_VAR([AS86], [Path to as86 tool]) AC_ARG_VAR([LD86], [Path to ld86 tool]) diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile index 07f36d075d..ba8f31a02c 100644 --- a/xen/xsm/flask/Makefile +++ b/xen/xsm/flask/Makefile @@ -8,10 +8,6 @@ CFLAGS-y += -I./include AWK = awk -CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ - else if [ -x /bin/bash ]; then echo /bin/bash; \ - else echo sh; fi ; fi) - FLASK_H_DEPEND = policy/security_classes policy/initial_sids AV_H_DEPEND = policy/access_vectors @@ -24,14 +20,14 @@ extra-y += $(ALL_H_FILES) mkflask := policy/mkflask.sh quiet_cmd_mkflask = MKFLASK $@ -cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND) +cmd_mkflask = $(mkflask) $(AWK) include $(FLASK_H_DEPEND) $(subst include/,%/,$(FLASK_H_FILES)): $(FLASK_H_DEPEND) $(mkflask) FORCE $(call if_changed,mkflask) mkaccess := policy/mkaccess_vector.sh quiet_cmd_mkaccess = MKACCESS VECTOR $@ -cmd_mkaccess = $(CONFIG_SHELL) $(mkaccess) $(AWK) $(AV_H_DEPEND) +cmd_mkaccess = $(mkaccess) $(AWK) $(AV_H_DEPEND) $(subst include/,%/,$(AV_H_FILES)): $(AV_H_DEPEND) $(mkaccess) FORCE $(call if_changed,mkaccess) diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh old mode 100644 new mode 100755 diff --git a/xen/xsm/flask/policy/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh old mode 100644 new mode 100755 -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 17:02:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 17:02:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jorkb-0006ep-9s; Fri, 26 Jun 2020 17:02:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jorka-0006ei-Bn for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 17:02:52 +0000 X-Inumbo-ID: de75f3a4-b7ce-11ea-82ea-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id de75f3a4-b7ce-11ea-82ea-12813bfff9fa; Fri, 26 Jun 2020 17:02:51 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: xvmKTUa21lqY9QLcL0hMCRDF2atr988/LpDLTxyQP2S0KJBFFFSQHLGCCcCWwoQUdlUXWEaEdW MveqOi/X307eP8TbVINFEE8SnYySjvUokFoxmeo5OpQ/v1jj3xllYDlYvCXzcK7rx5Viq6JRQR ce8BZcedU6p+6E0kLA10/bDCb2Jb5ah9tfGu0iDDp1Saljt4CYGzYOWvBICQcP91z85/85Lchz dNdyroIO27YHygVNf+/JmBcW7vOwUK949Y/zyp3KZ92B8RfyOQcjEJI+GMyetE2afSz8SPjgCL i84= X-SBRS: 2.7 X-MesageID: 21041803 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,284,1589256000"; d="scan'208";a="21041803" From: Andrew Cooper To: Xen-devel Subject: [PATCH] xsm: Drop trailing whitespace from build scripts Date: Fri, 26 Jun 2020 18:02:21 +0100 Message-ID: <20200626170221.28534-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Signed-off-by: Andrew Cooper --- CC: Daniel De Graaf --- xen/xsm/flask/policy/mkaccess_vector.sh | 26 +++++++++++++------------- xen/xsm/flask/policy/mkflask.sh | 32 ++++++++++++++++---------------- 2 files changed, 29 insertions(+), 29 deletions(-) diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh index 7fa4aaf638..942ede4713 100755 --- a/xen/xsm/flask/policy/mkaccess_vector.sh +++ b/xen/xsm/flask/policy/mkaccess_vector.sh @@ -22,7 +22,7 @@ BEGIN { printf("/* This file is automatically generated. Do not edit. */\n") > avpermfile; ; } -/^[ \t]*#/ { +/^[ \t]*#/ { next; } $1 == "class" { @@ -30,7 +30,7 @@ $1 == "class" { nextstate != "CLASS_OR_CLASS-OPENBRACKET") { printf("Parse error: Unexpected class definition on line %d\n", NR); - next; + next; } tclass = $2; @@ -39,7 +39,7 @@ $1 == "class" { { printf("Duplicate access vector definition for %s on line %d\n", tclass, NR); next; - } + } av_defined[tclass] = 1; permission = 0; @@ -47,7 +47,7 @@ $1 == "class" { nextstate = "INHERITS_OR_CLASS-OPENBRACKET"; next; } -$1 == "{" { +$1 == "{" { if (nextstate != "INHERITS_OR_CLASS-OPENBRACKET" && nextstate != "CLASS_OR_CLASS-OPENBRACKET" && nextstate != "COMMON-OPENBRACKET") @@ -69,7 +69,7 @@ $1 == "{" { if (nextstate != "COMMON-CLOSEBRACKET" && nextstate != "CLASS-CLOSEBRACKET") { - printf("Parse error: Unexpected symbol %s on line %d\n", $1, NR); + printf("Parse error: Unexpected symbol %s on line %d\n", $1, NR); next; } @@ -83,7 +83,7 @@ $1 == "{" { common_perms[common_name,$1] = permission; - printf("#define COMMON_%s__%s", toupper(common_name), toupper($1)) > outfile; + printf("#define COMMON_%s__%s", toupper(common_name), toupper($1)) > outfile; printf(" S_(\"%s\")\n", $1) > cpermfile; } @@ -96,23 +96,23 @@ $1 == "{" { } av_perms[tclass,$1] = permission; - - printf("#define %s__%s", toupper(tclass), toupper($1)) > outfile; - printf(" S_(SECCLASS_%s, %s__%s, \"%s\")\n", toupper(tclass), toupper(tclass), toupper($1), $1) > avpermfile; + printf("#define %s__%s", toupper(tclass), toupper($1)) > outfile; + + printf(" S_(SECCLASS_%s, %s__%s, \"%s\")\n", toupper(tclass), toupper(tclass), toupper($1), $1) > avpermfile; } spaces = 40 - (length($1) + length(tclass)); if (spaces < 1) spaces = 1; - for (i = 0; i < spaces; i++) - printf(" ") > outfile; + for (i = 0; i < spaces; i++) + printf(" ") > outfile; printf("(1UL << %u)\n", permission) > outfile; permission = permission + 1; } $1 == "}" { - if (nextstate != "CLASS-CLOSEBRACKET" && + if (nextstate != "CLASS-CLOSEBRACKET" && nextstate != "COMMON-CLOSEBRACKET") { printf("Parse error: Unexpected } on line %d\n", NR); @@ -122,7 +122,7 @@ $1 == "}" { if (nextstate == "COMMON-CLOSEBRACKET") { common_base[common_name] = permission; - printf("TE_(common_%s_perm_to_string)\n\n", common_name) > cpermfile; + printf("TE_(common_%s_perm_to_string)\n\n", common_name) > cpermfile; } printf("\n") > outfile; diff --git a/xen/xsm/flask/policy/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh index 989a323b80..591ce832a1 100755 --- a/xen/xsm/flask/policy/mkflask.sh +++ b/xen/xsm/flask/policy/mkflask.sh @@ -37,51 +37,51 @@ BEGIN { printf("static char *initial_sid_to_string[] =\n{\n") > debugfile2; printf(" \"null\",\n") > debugfile2; } -/^[ \t]*#/ { +/^[ \t]*#/ { next; } -$1 == "class" { +$1 == "class" { if (nextstate != "CLASS") { printf("Parse error: Unexpected class definition on line %d\n", NR); - next; + next; } if ($2 in class_found) { printf("Duplicate class definition for %s on line %d.\n", $2, NR); next; - } + } class_found[$2] = 1; class_value++; printf("#define SECCLASS_%s", toupper($2)) > outfile; - for (i = 0; i < 40 - length($2); i++) - printf(" ") > outfile; - printf("%d\n", class_value) > outfile; + for (i = 0; i < 40 - length($2); i++) + printf(" ") > outfile; + printf("%d\n", class_value) > outfile; printf(" S_(\"%s\")\n", $2) > debugfile; } -$1 == "sid" { +$1 == "sid" { if (nextstate == "CLASS") { nextstate = "SID"; - printf("\n/*\n * Security identifier indices for initial entities\n */\n") > outfile; + printf("\n/*\n * Security identifier indices for initial entities\n */\n") > outfile; } if ($2 in sid_found) { printf("Duplicate SID definition for %s on line %d.\n", $2, NR); next; - } + } sid_found[$2] = 1; sid_value++; printf("#define SECINITSID_%s", toupper($2)) > outfile; - for (i = 0; i < 37 - length($2); i++) - printf(" ") > outfile; - printf("%d\n", sid_value) > outfile; + for (i = 0; i < 37 - length($2); i++) + printf(" ") > outfile; + printf("%d\n", sid_value) > outfile; printf(" \"%s\",\n", $2) > debugfile2; } END { @@ -89,9 +89,9 @@ END { printf("Parse error: Unexpected end of file\n"); printf("\n#define SECINITSID_NUM") > outfile; - for (i = 0; i < 34; i++) - printf(" ") > outfile; - printf("%d\n", sid_value) > outfile; + for (i = 0; i < 34; i++) + printf(" ") > outfile; + printf("%d\n", sid_value) > outfile; printf("\n#endif /* __XEN__ || __XEN_TOOLS__ */\n") > outfile; printf("\n#endif\n") > outfile; printf("};\n\n") > debugfile2; -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 17:17:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 17:17:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joryI-0007eJ-Ja; Fri, 26 Jun 2020 17:17:02 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joryH-0007dz-0C for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 17:17:01 +0000 X-Inumbo-ID: d56a7f6c-b7d0-11ea-82eb-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d56a7f6c-b7d0-11ea-82eb-12813bfff9fa; Fri, 26 Jun 2020 17:16:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=byKoBzKo3oDDOnyCLGYOD82lVWyr2UiSOmP8zoxmZZA=; b=M8E0AsVMCYpPsY8I9v7bR4kbt uknjbGsqvMyVMYfs1b3/JJ+lCUwBlMB2P7eWVmnS4ZJJ/lqMpjZ8mjiZKI/4PBBVE9CurA13DarMq hwCTQij5CppkIo2Dxkvn1NDVkgrzhT2QZx/9aGeay7+sIzdaDbXax85X6+wvZnKYF+km4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joryA-0000y3-Ii; Fri, 26 Jun 2020 17:16:54 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1joryA-0003Ob-77; Fri, 26 Jun 2020 17:16:54 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1joryA-0001sB-6U; Fri, 26 Jun 2020 17:16:54 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151380: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=40b532fbdcb2095da7152a1d08d9f0288524c223 X-Osstest-Versions-That: xen=d3688bf60f798074bf38d712a3e15c88cfb81ed4 From: osstest service owner Date: Fri, 26 Jun 2020 17:16:54 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151380 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151380/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 40b532fbdcb2095da7152a1d08d9f0288524c223 baseline version: xen d3688bf60f798074bf38d712a3e15c88cfb81ed4 Last test of basis 151376 2020-06-26 11:00:34 Z 0 days Testing same since 151380 2020-06-26 14:09:54 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Grzegorz Uriasz Ian Jackson Jason Andryuk Tim Deegan Wei Liu jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git d3688bf60f..40b532fbdc 40b532fbdcb2095da7152a1d08d9f0288524c223 -> smoke From xen-devel-bounces@lists.xenproject.org Fri Jun 26 17:21:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 17:21:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jos2W-0008Rc-5j; Fri, 26 Jun 2020 17:21:24 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jos2U-0008RX-VF for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 17:21:22 +0000 X-Inumbo-ID: 74b60410-b7d1-11ea-bca7-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 74b60410-b7d1-11ea-bca7-bc764e2007e4; Fri, 26 Jun 2020 17:21:22 +0000 (UTC) Received: from localhost (c-67-180-165-146.hsd1.ca.comcast.net [67.180.165.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D074E2089D; Fri, 26 Jun 2020 17:21:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593192082; bh=IsZUG4DWzvA5uLxr8FPqPjPY/G30t4PJ9fenQs+LjGI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YNevlYfKxY6uu/Gi8TBzCE+XdVn7T4ndq5e8PG6MZ1JZcGyH+KFUJidzhoRiEFFyA 1FTh6R0hLZFEDWjIodr7Gi7GPhdVRkX6rW/ZkwkQQpcldZroFSZy4bdbKaLxN0V/tt PRMvw9o6LitoJQo3F5w2IZMseo9jF5Nv/gz7qhrk= From: Andy Lutomirski To: x86@kernel.org Subject: [PATCH 3/6] x86/entry/64/compat: Fix Xen PV SYSENTER frame setup Date: Fri, 26 Jun 2020 10:21:13 -0700 Message-Id: <947880c41ade688ff4836f665d0c9fcaa9bd1201.1593191971.git.luto@kernel.org> X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Andrew Cooper , linux-kernel@vger.kernel.org, Andy Lutomirski , xen-devel@lists.xenproject.org, Boris Ostrovsky Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The SYSENTER frame setup was nonsense. It worked by accident because the normal code into which the Xen asm jumped (entry_SYSENTER_32/compat) threw away SP without touching the stack. entry_SYSENTER_compat was recently modified such that it relied on having a valid stack pointer, so now the Xen asm needs to invoke it with a valid stack. Fix it up like SYSCALL: use the Xen-provided frame and skip the bare metal prologue. Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: xen-devel@lists.xenproject.org Fixes: 1c3e5d3f60e2 ("x86/entry: Make entry_64_compat.S objtool clean") Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_64_compat.S | 1 + arch/x86/xen/xen-asm_64.S | 20 ++++++++++++++++---- 2 files changed, 17 insertions(+), 4 deletions(-) diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index 7b9d8150f652..381a6de7de9c 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -79,6 +79,7 @@ SYM_CODE_START(entry_SYSENTER_compat) pushfq /* pt_regs->flags (except IF = 0) */ pushq $__USER32_CS /* pt_regs->cs */ pushq $0 /* pt_regs->ip = 0 (placeholder) */ +SYM_INNER_LABEL(entry_SYSENTER_compat_after_hwframe, SYM_L_GLOBAL) pushq %rax /* pt_regs->orig_ax */ pushq %rdi /* pt_regs->di */ pushq %rsi /* pt_regs->si */ diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S index 5d252aaeade8..e1e1c7eafa60 100644 --- a/arch/x86/xen/xen-asm_64.S +++ b/arch/x86/xen/xen-asm_64.S @@ -161,10 +161,22 @@ SYM_FUNC_END(xen_syscall32_target) /* 32-bit compat sysenter target */ SYM_FUNC_START(xen_sysenter_target) - mov 0*8(%rsp), %rcx - mov 1*8(%rsp), %r11 - mov 5*8(%rsp), %rsp - jmp entry_SYSENTER_compat + /* + * NB: Xen is polite and clears TF from EFLAGS for us. This means + * that we don't need to guard against single step exceptions here. + */ + popq %rcx + popq %r11 + + /* + * Neither Xen nor the kernel really knows what the old SS and + * CS were. The kernel expects __USER32_DS and __USER32_CS, so + * report those values even though Xen will guess its own values. + */ + movq $__USER32_DS, 4*8(%rsp) + movq $__USER32_CS, 1*8(%rsp) + + jmp entry_SYSENTER_compat_after_hwframe SYM_FUNC_END(xen_sysenter_target) #else /* !CONFIG_IA32_EMULATION */ -- 2.25.4 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 17:24:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 17:24:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jos5c-00008l-LB; Fri, 26 Jun 2020 17:24:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jos5c-00008g-4U for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 17:24:36 +0000 X-Inumbo-ID: e7dfbe68-b7d1-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e7dfbe68-b7d1-11ea-b7bb-bc764e2007e4; Fri, 26 Jun 2020 17:24:35 +0000 (UTC) Received: from localhost (c-67-180-165-146.hsd1.ca.comcast.net [67.180.165.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 219F620836; Fri, 26 Jun 2020 17:24:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593192275; bh=F/VWExg6XQ5+v2BiFiVfoHATO51UpO4eHrdk+RYhIUU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tFtDTtZ/LsvC48ct+GASS5dYzV+oh45HDZLwn8W3k1fWIUdg+T/tBuo9ctlvzon06 Gah/UFGCtmQKCa6W/wCzF1ENDGCXIKWCG8g/1NtKm0BUJ/I2JBiOlahJe7oBNreGSc Xks4oexOZg3SXRO/rGaWduGPDomsDDOCo7x4YXBU= From: Andy Lutomirski To: x86@kernel.org Subject: [PATCH fsgsbase v2 4/4] x86/fsgsbase: Fix Xen PV support Date: Fri, 26 Jun 2020 10:24:30 -0700 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Sasha Levin , Juergen Gross , Stefano Stabellini , Andrew Cooper , linux-kernel@vger.kernel.org, Andy Lutomirski , xen-devel@lists.xenproject.org, Boris Ostrovsky Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Xen PV, SWAPGS doesn't work. Teach __rdfsbase_inactive() and __wrgsbase_inactive() to use rdmsrl()/wrmsrl() on Xen PV. The Xen pvop code will understand this and issue the correct hypercalls. Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: xen-devel@lists.xenproject.org Signed-off-by: Andy Lutomirski --- arch/x86/kernel/process_64.c | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index cb8e37d3acaa..457d02aa10d8 100644 --- a/arch/x86/kernel/process_64.c +++ b/arch/x86/kernel/process_64.c @@ -163,9 +163,13 @@ static noinstr unsigned long __rdgsbase_inactive(void) lockdep_assert_irqs_disabled(); - native_swapgs(); - gsbase = rdgsbase(); - native_swapgs(); + if (!static_cpu_has(X86_FEATURE_XENPV)) { + native_swapgs(); + gsbase = rdgsbase(); + native_swapgs(); + } else { + rdmsrl(MSR_KERNEL_GS_BASE, gsbase); + } return gsbase; } @@ -182,9 +186,13 @@ static noinstr void __wrgsbase_inactive(unsigned long gsbase) { lockdep_assert_irqs_disabled(); - native_swapgs(); - wrgsbase(gsbase); - native_swapgs(); + if (!static_cpu_has(X86_FEATURE_XENPV)) { + native_swapgs(); + wrgsbase(gsbase); + native_swapgs(); + } else { + wrmsrl(MSR_KERNEL_GS_BASE, gsbase); + } } /* -- 2.25.4 From xen-devel-bounces@lists.xenproject.org Fri Jun 26 17:46:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 17:46:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1josQh-0001rW-Kt; Fri, 26 Jun 2020 17:46:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1josQg-0001rP-4I for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 17:46:22 +0000 X-Inumbo-ID: f24575ca-b7d4-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id f24575ca-b7d4-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 17:46:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jt4yZmJG7KXUCRdT6sM646MFKXBc143aigS0EWKAcCw=; b=aEVIYnOCu7+qUj+0Ji7n3Y1OxN aQWQKi8N4hudQQRVKHs+pzMSvT2JbKJLvaRRzh6Csxelgs4IMQvMUt5c53gCW/RXxVIetzJHRn7UR UCrBiwEEwJy951V7a5UueEqqKlI9+dRE7mk3j+s6zQd9AhTcfIdxCRkrPwCWLaefXapg=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1josQZ-0001Ud-Ex; Fri, 26 Jun 2020 17:46:15 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1josQZ-0002LT-7a; Fri, 26 Jun 2020 17:46:15 +0000 Subject: Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches To: Ian Jackson References: <20200613184132.11880-1-julien@xen.org> <35c8373f-b691-d95e-17de-021c72faf216@xen.org> <24307.16713.764272.855818@mariner.uk.xensource.com> From: Julien Grall Message-ID: <8335fa07-7610-2a40-36fc-49d6f900026c@xen.org> Date: Fri, 26 Jun 2020 18:46:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24307.16713.764272.855818@mariner.uk.xensource.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , Paul Durrant , Andrew Cooper , Julien Grall , George Dunlap , "committers@xenproject.org" , Jan Beulich , xen-devel , Roger Pau Monne , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Ian, Thank you for your input! On 24/06/2020 13:04, Ian Jackson wrote: > Julien Grall writes ("Re: [PATCH v3 for-4.14] pvcalls: Document correctly and explicitely the padding for all arches"): >> (+ Committers) > ... >> As Jan and you disagree on the approach, I would like to get more input. >> >> To summarize the discussion, the document for PV calls and the public >> headers don't match when describing the padding. There is a disagreement >> on which of the two are the authority and therefore which one to fix. >> >> Does anyone else have a preference on the approach? > > Hi. > >> [Jan:] >>> I am leaning towards the header as authoritative because this has >>> always been the case in the past and nothing in xen.git says >>> otherwise. However I am not a user of pvcalls, so I don't really have >>> any big incentive to go either way. > > I think the practice of using headers as protocol specs is not a > particularly good one. Certainly my expectations anywhere outside the > Xen Project is that if there's a doc, that is at the very least on par > with any header file. Of course there are possible compatibility > implications: > >> Yeah, we are risking breaking one set of users either way :-/ >> In reality, we are using pvcalls on arm64 in a new project (but it is >> still very green). I am not aware of anybody using pvcalls on x86 >> (especially x86_32). >> >> I would prefer to honor the pvcalls.pandoc specification because that is >> what it was meant to be, and also leads to a better protocol >> specification. > > pvcalls in Linux is Tech Preview / Experimental AFAICT ? I think that > means we can de jure change things like this. SUPPORT.md suggests this is a Tech Preview, so I agree that we could still change the interface. > > And it seems that we don't think there are any actual users who would > experience compatibility problems. Right, that's what Stefano suggested. > > So I don't think the compatibility concerns are a reason not to change > the header rather than the document. > > So I think my conclusion is the same as Julien's: we should change the > header to match the doc. Ok, so you are on the same page as Stefano. I will revert to the v1 change and rework the commit message then. > >>>> For the future, I would highly suggest writing down the support >>>> decision in xen.git. This would avoid such debate on what is the >>>> authority... >>> >>> Yes that's the way to go > > Maybe it would be worth putting a note somewhere in the headers saying > the headers are provided for convenience but that the ABIs and > protocols are as specified in the docs (at least where docs exist). I will write a patch for it. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 26 17:54:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 17:54:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1josYW-0002i3-F4; Fri, 26 Jun 2020 17:54:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1josYV-0002hs-B9 for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 17:54:27 +0000 X-Inumbo-ID: 13651bec-b7d6-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 13651bec-b7d6-11ea-8496-bc764e2007e4; Fri, 26 Jun 2020 17:54:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=XyYKLldYnIb+Zo6QDJ7iUxVABkqbSz9KssSn408orSQ=; b=4ehXGvchdRnPa2x2qFbjRfoQha im5v4meEBdxOSoGNILbjpTKXitzRQZFpZyS+HC/yudWy2eyfBAxdoanwIwq959pa4ke3pVsQu2w5H 4K4BjtI5+mDbUhcGlb7T0pVmPIWIvFDVZ7UAKeGFJEY6AXK2PJ2iEXi2vRFey8I8yYz8=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1josYT-0001dk-PS; Fri, 26 Jun 2020 17:54:25 +0000 Received: from [54.239.6.185] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1josYT-0002uR-EL; Fri, 26 Jun 2020 17:54:25 +0000 Subject: Re: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address To: Stefano Stabellini , "paul@xen.org" References: <20200619223332.438344-1-volodymyr_babchuk@epam.com> <20200619223332.438344-3-volodymyr_babchuk@epam.com> <87ftampkd7.fsf@epam.com> <2df789f3-e881-36a3-51f4-010b499990f5@xen.org> From: Julien Grall Message-ID: Date: Fri, 26 Jun 2020 18:54:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , "op-tee@lists.trustedfirmware.org" , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" (using paul xen.org's email) Hi, Apologies for the late answer. On 23/06/2020 22:09, Stefano Stabellini wrote: > On Tue, 23 Jun 2020, Julien Grall wrote: >> On 23/06/2020 03:49, Volodymyr Babchuk wrote: >>> >>> Hi Stefano, >>> >>> Stefano Stabellini writes: >>> >>>> On Fri, 19 Jun 2020, Volodymyr Babchuk wrote: >>>>> Trusted Applications use popular approach to determine required size >>>>> of buffer: client provides a memory reference with the NULL pointer to >>>>> a buffer. This is so called "Null memory reference". TA updates the >>>>> reference with the required size and returns it back to the >>>>> client. Then client allocates buffer of needed size and repeats the >>>>> operation. >>>>> >>>>> This behavior is described in TEE Client API Specification, paragraph >>>>> 3.2.5. Memory References. >>>>> >>>>> OP-TEE represents this null memory reference as a TMEM parameter with >>>>> buf_ptr = 0x0. This is the only case when we should allow TMEM >>>>> buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. This also the >>>>> special case for a buffer with OPTEE_MSG_ATTR_NONCONTIG flag. >>>>> >>>>> This could lead to a potential issue, because IPA 0x0 is a valid >>>>> address, but OP-TEE will treat it as a special case. So, care should >>>>> be taken when construction OP-TEE enabled guest to make sure that such >>>>> guest have no memory at IPA 0x0 and none of its memory is mapped at PA >>>>> 0x0. >>>>> >>>>> Signed-off-by: Volodymyr Babchuk >>>>> --- >>>>> >>>>> Changes from v1: >>>>> - Added comment with TODO about possible PA/IPA 0x0 issue >>>>> - The same is described in the commit message >>>>> - Added check in translate_noncontig() for the NULL ptr buffer >>>>> >>>>> --- >>>>> xen/arch/arm/tee/optee.c | 27 ++++++++++++++++++++++++--- >>>>> 1 file changed, 24 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c >>>>> index 6963238056..70bfef7e5f 100644 >>>>> --- a/xen/arch/arm/tee/optee.c >>>>> +++ b/xen/arch/arm/tee/optee.c >>>>> @@ -215,6 +215,15 @@ static bool optee_probe(void) >>>>> return true; >>>>> } >>>>> +/* >>>>> + * TODO: There is a potential issue with guests that either have RAM >>>>> + * at IPA of 0x0 or some of theirs memory is mapped at PA 0x0. This is >>>> ^ their >>>> >>>>> + * because PA of 0x0 is considered as NULL pointer by OP-TEE. It will >>>>> + * not be able to map buffer with such pointer to TA address space, or >>>>> + * use such buffer for communication with the guest. We either need to >>>>> + * check that guest have no such mappings or ensure that OP-TEE >>>>> + * enabled guest will not be created with such mappings. >>>>> + */ >>>>> static int optee_domain_init(struct domain *d) >>>>> { >>>>> struct arm_smccc_res resp; >>>>> @@ -725,6 +734,15 @@ static int translate_noncontig(struct optee_domain >>>>> *ctx, >>>>> uint64_t next_page_data; >>>>> } *guest_data, *xen_data; >>>>> + /* >>>>> + * Special case: buffer with buf_ptr == 0x0 is considered as NULL >>>>> + * pointer by OP-TEE. No translation is needed. This can lead to >>>>> + * an issue as IPA 0x0 is a valid address for Xen. See the comment >>>>> + * near optee_domain_init() >>>>> + */ >>>>> + if ( !param->u.tmem.buf_ptr ) >>>>> + return 0; >>>> >>>> Given that today it is not possible for this to happen, it could even be >>>> an ASSERT. But I think I would just return an error, maybe -EINVAL? >>> >>> Hmm, looks like my comment is somewhat misleading :( >> >> How about the following comment: >> >> We don't want to translate NULL (0) as it can be used by the guest to fetch >> the size of the buffer to allocate. This behavior depends on TA, but there is >> a guarantee that OP-TEE will not try to map it (see more details on top of >> optee_domain_init()). >> >>> >>> What I mean, is that param->u.tmem.buf_ptr == 0 is the normal situation. >>> This is the special case, when OP-TEE treats this buffer as a NULL. So >>> we are doing nothing there. Thus, "return 0". >>> >>> But, as Julien pointed out, we can have machine where 0x0 is the valid >>> memory address and there is a chance, that some guest will use it as a >>> pointer to buffer. >>> >>>> Aside from this, and the small grammar issue, everything else looks fine >>>> to me. >>>> >>>> Let's wait for Julien's reply, but if this is the only thing I could fix >>>> on commit. >> >> I agree with Volodymyr, this is the normal case here. There are more work to >> prevent MFN 0 to be mapped in the guest but this shouldn't be an issue today. > > Let's put the MFN 0 issue aside for a moment. > > From the commit message I thought that if the guest wanted to pass a > NULL buffer ("Null memory reference") then it would also *not* set > OPTEE_MSG_ATTR_NONCONTIG, which would be handled by the "else" statement > also modified by this patch. Thus, I thought that reaching > translate_noncontig with buf_ptr == NULL would always be an error. > > But re-reading the commit message and from both your answers it is not > the case: a "Null memory reference" is allowed with > OPTEE_MSG_ATTR_NONCONTIG set too. > > Thus, I have no further comments and the improvements on the in-code > comment could be done on commit. Good :). IIRC Paul gave a provisional RaB for this series. @Paul, now that we are settled, could we get a formal one? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Fri Jun 26 18:51:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 18:51:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jotR1-0007Wf-V8; Fri, 26 Jun 2020 18:50:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jotR0-0007WD-NJ for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 18:50:46 +0000 X-Inumbo-ID: edf216f0-b7dd-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id edf216f0-b7dd-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 18:50:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zwiVX5rBIPMmgmdsQo4uFDzyFMraqhUmkmOQa97YBUQ=; b=3gKZIWheAWEROh9aRILPBq05P TMsgmlXilQ2HIPQh8KFbc3ZkJL8MsSaOg6RDR3WEZ77aYsMqVsK261emFMM0Nz1UFfdRiIvfXudAu OvIblvAcRgZgJDrkiKzJjnE72bl+9+PdhSev+yieFUhlmcS7VCSq3EU/fpR0o0cbS7+L0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jotQt-0002k2-3P; Fri, 26 Jun 2020 18:50:39 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jotQs-00004v-PD; Fri, 26 Jun 2020 18:50:38 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jotQs-0001Sb-Iq; Fri, 26 Jun 2020 18:50:38 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151367: regressions - FAIL X-Osstest-Failures: xen-4.12-testing:build-i386-prev:xen-build:fail:regression xen-4.12-testing:build-amd64-prev:xen-build:fail:regression xen-4.12-testing:test-amd64-i386-xl-raw:guest-localmigrate/x10:fail:heisenbug xen-4.12-testing:test-arm64-arm64-xl-thunderx:xen-boot:fail:heisenbug xen-4.12-testing:test-amd64-i386-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-amd64-amd64-migrupgrade:build-check(1):blocked:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=050fe48dc981e0488de1f6c6c07d8110f3b7523b X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Fri, 26 Jun 2020 18:50:38 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151367 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151367/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 6 xen-build fail in 151341 REGR. vs. 150176 build-amd64-prev 6 xen-build fail in 151341 REGR. vs. 150176 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-raw 17 guest-localmigrate/x10 fail in 151341 pass in 151367 test-arm64-arm64-xl-thunderx 7 xen-boot fail pass in 151341 Tests which did not succeed, but are not blocking: test-amd64-i386-migrupgrade 1 build-check(1) blocked in 151341 n/a test-amd64-amd64-migrupgrade 1 build-check(1) blocked in 151341 n/a test-arm64-arm64-xl-thunderx 13 migrate-support-check fail in 151341 never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail in 151341 never pass test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 050fe48dc981e0488de1f6c6c07d8110f3b7523b baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 43 days Failing since 150943 2020-06-09 17:06:00 Z 17 days 15 attempts Testing same since 151341 2020-06-24 16:34:12 Z 2 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Igor Druzhinin Jan Beulich Jason Andryuk Julien Grall Paul Durrant Roger Pau Monné Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx fail test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 587 lines long.) From xen-devel-bounces@lists.xenproject.org Fri Jun 26 19:15:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 19:15:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jotpE-0000sq-46; Fri, 26 Jun 2020 19:15:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jotpC-0000sl-Rf for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 19:15:46 +0000 X-Inumbo-ID: 6fa612ac-b7e1-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6fa612ac-b7e1-11ea-bca7-bc764e2007e4; Fri, 26 Jun 2020 19:15:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ut0EgzZkAg1g+JR69UfJsrN2KvDUdlNxjprbkyxYH0k=; b=Y48JrJQ2/lVEs9roXIckyIUB9 ezV/xY6fAeYBtndDAb9FtJVrBnSXpDO+Q0uReviI0mqxUmraUzfCaTXjtdbgj8UNp25YXm5ScRJvk y+0hJg0CxV8sEM6uYx0+GtZP1JmeSgAdDYEulPDe5RT1WB6oX801ZxwPoSdr9Uax6jJMk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jotpB-0003Dx-7k; Fri, 26 Jun 2020 19:15:45 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jotpA-00018Y-TK; Fri, 26 Jun 2020 19:15:44 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jotpA-0004Fp-Se; Fri, 26 Jun 2020 19:15:44 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151370: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=bac096fff0bf3414ebeb4306a32ad4dab20ccfdf X-Osstest-Versions-That: libvirt=8c6dba054b012ad3d71bccc5b25cf297681d81d3 From: osstest service owner Date: Fri, 26 Jun 2020 19:15:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151370 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151370/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151352 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151352 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt bac096fff0bf3414ebeb4306a32ad4dab20ccfdf baseline version: libvirt 8c6dba054b012ad3d71bccc5b25cf297681d81d3 Last test of basis 151352 2020-06-25 04:18:49 Z 1 days Testing same since 151370 2020-06-26 04:20:29 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Jonathon Jongsma Michal Privoznik Peter Krempa jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git 8c6dba054b..bac096fff0 bac096fff0bf3414ebeb4306a32ad4dab20ccfdf -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Fri Jun 26 20:58:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 20:58:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jovQI-0000jC-EX; Fri, 26 Jun 2020 20:58:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jovQH-0000i0-Sg for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 20:58:09 +0000 X-Inumbo-ID: baa13c38-b7ef-11ea-8316-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id baa13c38-b7ef-11ea-8316-12813bfff9fa; Fri, 26 Jun 2020 20:58:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=blaqOsrUapv7t9CpcupWuVeEl/Ia8hxipKskuVNlAlU=; b=y9TuFfzwAGFDWNo6m66H6BNoh 5Fn53AAAu3dUNWQ/tBQn9V7WCfR2+m8sVrRorqbJrhkmYW1TXvZZJiiclVxTuMsZ+oOGta3ZeLY7p qrH++xTm4DTDLclEB8icAfJ0qHrQ2hXmCxQKwmOL1y/xurDoKwRFwSCSWcXfEbdmbbYg0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jovQB-00058x-Ut; Fri, 26 Jun 2020 20:58:03 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jovQB-0004dH-L9; Fri, 26 Jun 2020 20:58:03 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jovQB-0002B2-Kd; Fri, 26 Jun 2020 20:58:03 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151385: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=88cfd062e8318dfeb67c7d2eb50b6cd224b0738a X-Osstest-Versions-That: xen=40b532fbdcb2095da7152a1d08d9f0288524c223 From: osstest service owner Date: Fri, 26 Jun 2020 20:58:03 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151385 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151385/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a baseline version: xen 40b532fbdcb2095da7152a1d08d9f0288524c223 Last test of basis 151380 2020-06-26 14:09:54 Z 0 days Testing same since 151385 2020-06-26 18:00:39 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 40b532fbdc..88cfd062e8 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a -> smoke From xen-devel-bounces@lists.xenproject.org Fri Jun 26 23:02:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 26 Jun 2020 23:02:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joxML-0002ay-V3; Fri, 26 Jun 2020 23:02:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1joxMK-0002ap-MX for xen-devel@lists.xenproject.org; Fri, 26 Jun 2020 23:02:12 +0000 X-Inumbo-ID: 111bceb4-b801-11ea-bb8b-bc764e2007e4 Received: from gordon.huskydog.org.uk (unknown [81.187.95.156]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 111bceb4-b801-11ea-bb8b-bc764e2007e4; Fri, 26 Jun 2020 23:02:11 +0000 (UTC) Received: from [10.137.3.12] (percyq.huskydog.org.uk [10.42.42.111]) by gordon.huskydog.org.uk (Postfix) with ESMTP id 1D0A72467; Sat, 27 Jun 2020 00:02:10 +0100 (BST) Subject: Re: ARM - Successful install on RockPro64 To: Julien Grall , Bertrand Marquis References: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> <8013f2db-3732-0679-81f6-7b274b39c44f@xen.org> <49e5b539-145a-726a-fb80-a93e65e44ca0@huskydog.org.uk> From: Richard Simpson Message-ID: Date: Sat, 27 Jun 2020 00:02:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello Julien, I also have been busy and unable to reply. On 6/24/20 1:42 PM, Julien Grall wrote: > > > On 17/06/2020 23:28, Richard Simpson wrote: >> Hello Julien, > > Hello Richard, > > Apologies for the late answer. > >> I have just tried 4.14-rc2 and it seems to work fine. > > Glad to hear that. Thank you for the testing! > >> I think that the most useful page regarding the board is the one for >> the Ibox3399 since this refers to the RK3399 chip which the RockPro64 >> uses (shouldn't the page actually be called RK3399 to make it more >> generic). > > I agree with the renaming here. > >> Perhaps I can most usefully record what I did by updating that page >> and making sure that the instructions work correctly. If there is >> additional stuff relevant to the RockPro64 over and above the generic >> RK3399 info then I'll give some thought to how to best record it.  I >> will eventually be writing a fuller report on my progress on my blog >> at funfoodfreedom.huskydog.org.uk. > > Any additional content on the wiki will be greatly appreciated. By > default new wiki account doesn't have write permission, but we can > enable it for you if you provide us your username. I now have editor access on the Wiki and have made a small test edit in the hardware section.  I will now try to make other changes as I learn more whilst trying very hard not to break anything! >> >> I now need to finish automating the boot process (still requires >> manual u-boot command) and figure out how to get the console log to >> work. > > I wrote a small u-boot script in the past to try to automate the boot > (see [2]). > > I vaguely remember some quoting issue and missing 0x in front of > values depending on the U-boot configuration you use. So you may have > to tweak it a bit. I now have a boot script that seems to automate the boot OK.  I am sure it could be better and I would like to add a boot menu but these are refinements I can do later.  I will see what I can learn from your example. > >> Currently I can either see the xen and linux kernel boot messages OR >> see the dom0 console, but not both. > > Can you provide the kernel/xen command lines you use in the two cases? > > As an aside, I know that on some setup Linux will try to disable the > clock of the UART used by Xen. One of the symptoms is the UART is > becoming completely unusable half way through Linux boot. > > You may want to try to pass clk_ignored_unused to see if it helps. I still haven't fixed the boot message problem but I got very confused about what changes were having which effect.  Hopefully this weekend I will systematically try the various xen and Linux options and produce a table of what the effect is each time.  I'll also try your clk_ignored suggestion.  If I don't find a working combination then I'll post a question and I guess this should be on the users list rather than this one. > >> On one more related note:  I suspect that Xen would run on the >> PineBookPro as well as I get the impression that it uses very similar >> hardware.  Of course that would rely on the GPU etc which I haven't >> tested at all as I am using the serial console. > I wouldn't expect any issue to use the GPU in dom0 at least if you > don't have an IOMMU on the platform. The trouble may be more with the > bootloader if it doesn't drop you in hypervisor mode. > >> >> Finally, when I joined this mailing list I asked for a daily digest. >> However I seem to be getting a new digest every hour or so.  Is this >> right? > > I haven't used the digest myself. I CC Ian Jackson who may be able to > help you. > > Cheers, > > [2] https://xenbits.xen.org/people/julieng/load-xen-tftp.scr.txt > From xen-devel-bounces@lists.xenproject.org Sat Jun 27 02:25:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 02:25:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp0Wa-0003b0-Vh; Sat, 27 Jun 2020 02:25:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp0WZ-0003av-32 for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 02:24:59 +0000 X-Inumbo-ID: 63ef8be6-b81d-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 63ef8be6-b81d-11ea-bb8b-bc764e2007e4; Sat, 27 Jun 2020 02:24:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=epTIo5pNTw82MFn2SofLbZHhNdh9MMugZZnKfYnDxw0=; b=CfPUslm87R3fmOfuYIt4Vxijc NkVx+vlGj/ltbNMbJSskBQwtrsjtDkcq5N3GmfL5nERtdwHuqE8X4Zuf4boF2nci+5Ya58PHmC4NT zAQUvXr/cDcp71I/HsvdeNONmAfChk7HLbeEZgEAbkvijYYy64lRjbFVtdz3LnIGkbiCk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp0WV-00051O-Ha; Sat, 27 Jun 2020 02:24:55 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jp0WV-0001wX-9R; Sat, 27 Jun 2020 02:24:55 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jp0WV-00022O-8i; Sat, 27 Jun 2020 02:24:55 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151372: regressions - FAIL X-Osstest-Failures: linux-linus:test-amd64-i386-freebsd10-amd64:xen-boot:fail:regression linux-linus:test-arm64-arm64-libvirt-xsm:guest-start.2:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start.2:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=4a21185cda0fbb860580eeeb4f1a70a9cda332a4 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Sat, 27 Jun 2020 02:24:55 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151372 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151372/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 7 xen-boot fail REGR. vs. 151214 test-arm64-arm64-libvirt-xsm 17 guest-start.2 fail REGR. vs. 151214 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 17 guest-start.2 fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 4a21185cda0fbb860580eeeb4f1a70a9cda332a4 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 8 days Failing since 151236 2020-06-19 19:10:35 Z 7 days 7 attempts Testing same since 151372 2020-06-26 06:07:53 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aaron Ma Aaron Plattner Aditya Pakki Aiden Leong Alex Deucher Alex Deucher Alexander Lobakin Alexander Lobakin Alexander Stein Alexei Starovoitov Alexey Budankov Andrew Bowers Andrew Lunn Andrii Nakryiko Andy Shevchenko Aneesh Kumar K.V Antoine Tenart Ard Biesheuvel Ariel Elior Arnaldo Carvalho de Melo Arnd Bergmann Arvind Sankar Atish Patra Axel Lin Baolin Wang Barry Song Bartosz Golaszewski Björn Töpel Brent Lu Briana Oursler Charles Keepax Chen Zhou Chihhao Chen Chris Wilson Christian Borntraeger Christian Brauner Christian Zigotzky Christoffer Nielsen Christoph Hellwig Christophe Leroy Christopher Swenson Chunyan Zhang Ciara Loftus Claudiu Beznea Claudiu Manoil Colin Ian King Coly Li Corey Minyard Cornelia Huck Dan Carpenter Dan Williams Daniel Borkmann Daniel Mack Daniel Schaefer Daniel Vetter Dany Madden Dave Airlie Dave Martin David Christensen David Hildenbrand David Howells David S. Miller David Sterba David Wilder Davide Caratti Dejin Zheng Denis Efremov Denis Kirjanov Denis Kirjanov Dennis Dalessandro derek.fang Dinghao Liu Dmitry Baryshkov Dmitry V. Levin Doug Berger Drew Fustini Edward Cree Eric Biggers Eric Dumazet Eugenio Pérez Fan Guo Felix Fietkau Felix Kuehling Filipe Manana Flavio Suligoi Florian Fainelli Florian Westphal Frank Werner-Krippendorf Gal Pressman Gao Xiang Gaurav Singh Geert Uytterhoeven Geliang Tang Guenter Roeck guodeqing Gustavo A. R. Silva Haibo Chen Hangbin Liu Heiko Carstens Heiner Kallweit Heinrich Schuchardt Herbert Xu Hongbo Yao Horatiu Vultur Huacai Chen Huy Nguyen Ian Rogers Ido Schimmel Igor Mammedov Igor Russkikh Ilya Dryomov Ilya Ponetayev Imre Deak Ira Weiny Jack Wang Jack Yu Jakub Kicinski Jan Kara Jason A. Donenfeld Jason Gunthorpe Jason Gunthorpe Jason Wang Jason Yan Jeff Kirsher Jens Axboe Jens Thoms Toerring Jeremy Kerr Jesper Dangaard Brouer Jiri Olsa Jiri Olsa Jisheng Zhang John Fastabend John Garry John Stultz Jonathan Toppins Joonas Lahtinen Jozsef Kadlecsik Julian Wiedmann Kai-Heng Feng Kaike Wan Kaitao Cheng Kees Cook Kefeng Wang kernel test robot Keyur Patel Khaled Almahallawy Kieran Bingham Krzysztof Kozlowski Laurence Tratt Lee Jones Leon Romanovsky Lingling Xu Linus Torvalds Linus Walleij Loic Poulain Lorenz Brun Lorenzo Bianconi Luc Van Oostenryck Luis Chamberlain Macpaul Lin Manivannan Sadhasivam Maor Gottlieb Marcelo Ricardo Leitner Marcelo Tosatti Mark Brown Mark Rutland Mark Zhang Martin Martin Fuzzey Martin K. Petersen Martin Schwidefsky Masahiro Yamada Masami Hiramatsu Masanari Iida Matti Vaittinen Mauricio Faria de Oliveira Max Gurtovoy Maximilian Werner Mel Gorman Michael Chan Michael Ellerman Michael S. Tsirkin Michal Kalderon Michal Kubecek Miguel Ojeda Mike Marciniszyn Mike Rapoport Milian Wolff Nathan Chancellor Nathan Huckleberry Navid Emamdoost Neal Cardwell Nicholas Piggin Nick Desaulniers Nicolas Ferre Nikolay Aleksandrov Nirmoy Das Pablo Neira Ayuso Palmer Dabbelt Paolo Abeni Paolo Bonzini Patrice Chotard Paul Moore Pavel Begunkov Peter Zijlstra (Intel) Pierre-Louis Bossart Qian Cai Qing Zhang Qingqing Zhuo Qiushi Wu Rahul Lakkireddy Randy Dunlap Rao Shoaib Ravulapati Vishnu vardhan rao Rob Gill Robert Foss Robin Gong Rodrigo Siqueira Roman Gushchin Roopa Prabhu Russell King Sabrina Dubroca Sami Tolvanen Sandeep Raghuraman Sascha Hauer Sascha Ortmann Sean Christopherson Sedat Dilek Shannon Nelson Shay Drory Shengjiu Wang Shuah Khan Shyam Thombre Sivaprakash Murugesan Soheil Hassas Yeganeh Somasundaram Krishnasamy Srinivas Kandagatla Stanislav Fomichev Stefan Schmidt Steffen Klassert Stephan Mueller Stephan Müller Stephen Rothwell Stephen Smalley Steve Lee Steven Rostedt (VMware) Sumanth Korikkar Sven Schnelle Taehee Yoo Takashi Iwai Tariq Toukan Thomas Falcon Thomas Martitz Tiezhu Yang Tobias Klauser Toke Høiland-Jørgensen Tom Lendacky Tom Rix Tom Seewald Tuomas Tynkkynen Uma Shankar Vaibhav Jain Vamshi K Sthambamkadi Vandita Kulkarni Vasily Gorbik Vasundhara Volam Vidya Sagar Vincenzo Frascino Vishal Verma Vitaly Kuznetsov Vladimir Oltean Waiman Long Wei Yang Weihang Li Weiping Zhang wenxu Will Deacon Willem de Bruijn Wolfram Sang Wolfram Sang Xiaoguang Wang Xiaoyao Li Yang Yingliang YangHui Yangyang Li Yash Shah Ye Bin Yick W. Tse Zheng Bin Zhenzhong Duan Zhiqiang Liu Zou Wei jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 14066 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 27 08:22:59 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 08:22:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp66b-00082Z-23; Sat, 27 Jun 2020 08:22:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp66a-00082E-6x for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 08:22:32 +0000 X-Inumbo-ID: 5410891e-b84f-11ea-834d-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5410891e-b84f-11ea-834d-12813bfff9fa; Sat, 27 Jun 2020 08:22:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fHUJSaTA6TXLgOZEWLJqInBqUcVKN4mxFUaaHzX6DSA=; b=yLw8jh3yrB9omKhQv9xCReNob EoYYDGe8ZIexEEWOuNoIjrq3Kee79tJEAPyQF45cT9GbOu54gMaQFPUipNkOd8mi+2OqbzSLlrvD3 pl9byP8l3kCs7W8ayS3PB5/y5uJBDJuA11wrWaTGnWq8eDUKAB/0KGUIN6WoZl90XxtuM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp66R-0004AA-MZ; Sat, 27 Jun 2020 08:22:23 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jp66R-0004H2-Bz; Sat, 27 Jun 2020 08:22:23 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jp66R-0004fC-BE; Sat, 27 Jun 2020 08:22:23 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151377: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=611ac63305ff577604e2a7bacf4f204568e08bef X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Sat, 27 Jun 2020 08:22:23 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151377 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151377/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151065 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass version targeted for testing: qemuu 611ac63305ff577604e2a7bacf4f204568e08bef baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 14 days Failing since 151101 2020-06-14 08:32:51 Z 12 days 11 attempts Testing same since 151377 2020-06-26 11:23:35 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Andrew Jones Ani Sinha Anthony PERARD Ard Biesheuvel Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Cleber Rosa Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Geoffrey McRae Gerd Hoffmann Greg Kurz Guenter Roeck Gustavo Romero Helge Deller Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jean-Christophe Dubois Jiaxun Yang John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marek Marczykowski-Górecki Markus Armbruster Masahiro Yamada Max Filippov Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Raphael Norwitz Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Shameer Kolothum Stefan Berger Stefan Berger Stefan Hajnoczi Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 11789 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 27 08:35:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 08:35:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp6JA-0000XJ-9L; Sat, 27 Jun 2020 08:35:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp6J8-0000XE-7t for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 08:35:30 +0000 X-Inumbo-ID: 27cb9dc4-b851-11ea-b7bb-bc764e2007e4 Received: from mail-lj1-x230.google.com (unknown [2a00:1450:4864:20::230]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 27cb9dc4-b851-11ea-b7bb-bc764e2007e4; Sat, 27 Jun 2020 08:35:29 +0000 (UTC) Received: by mail-lj1-x230.google.com with SMTP id t25so8125436lji.12 for ; Sat, 27 Jun 2020 01:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yubico.com; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=q/D1jQVc/yvqJDcGR/5pp8VpYBedOlbFNiJGMXBwOUw=; b=hZaLJ8N/6npvDu7AySS9A/5x4VnPKS1PhWTFyGIG4i4ZWoneQIrqIz1dRHmj4lws14 BZ/tFNrxnepdS3sx1wUCIsTyQlz5+DJA6vgqAccfAR1sDHEXmhD/fEA2Xu4WRcZvqKwz b4+HgIBLtkLHwlTdSAPwAHlK+iDKhxg7gmlMlcDzxfkMeFHRQUsGNQEiuBzgEule5Uit RdNhpSaenGjq8roPu3BlLXVA52jbGRcpdXBJFzEcO4vOqU03EmuESYpJtwuzD78DsusY sLF/6pYTS4O8od5wp1WflQPerVllz6IM00zioys8mTTRNi+Oxq/DaYcHnj3KkAwOrEu3 st8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=q/D1jQVc/yvqJDcGR/5pp8VpYBedOlbFNiJGMXBwOUw=; b=AS9Zqiew2t4Vn1J8Tboz/hG3Yyj79DnQC3zHSso63nx5W8uIwy2lXudUtJFk13NUnl yRMqZuALlITBHf6xmTRpAAMHkhvQLfPjIatoHg7JKS9ZKxdMT4MeNOFQSaT7+6EKpr8b BFFb+SfJLgKS5w+CkGTqcJUev/B75wMsrIopAyoyqrJr4mYDm9rwbXkTJowJgUlbZDFb wJcW0OscWXdTB7ia7zENIfVvbZYJD0cXfe4PKr8OKT3F3bG5wlvKfN5J254yGPCaEbi8 PbeCf5IVJNGTRkrEHjMdDey+vLgfLaaQiEo0UbJBk/drBNuNLiEAOzmC3NK6e+kc88ZA zt9A== X-Gm-Message-State: AOAM531X7fYzJyMYO75bzYrywx2k8A5ETwbs8JJxsL3AEa6W/bY5Av6C r7qn8JRBLq5/Dlnt132ObRwsHMbWHNWEstZsLEFMkj/M2C5UBJYy+QJMFcgne4iUlnAUA8UGGyb Ns4lK2gD0tVdCX9eRN5p+EgG5TH1CqTkbxkiqAkjZjlm/exD/m77c9QUvtmWHH2C0gPe+7NeROw == X-Google-Smtp-Source: ABdhPJzlc03rNshWI1PMO0QrGHhuSnwqn0M5njsCoh/vlOcJpL+nr3ya+1aQXlhYqZFc2ysH6BLEuQ== X-Received: by 2002:a2e:9618:: with SMTP id v24mr3709264ljh.303.1593246927799; Sat, 27 Jun 2020 01:35:27 -0700 (PDT) Received: from apple-IIe.local (c188-151-193-98.bredband.comhem.se. [188.151.193.98]) by smtp.gmail.com with ESMTPSA id s62sm5577789lja.100.2020.06.27.01.35.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Jun 2020 01:35:27 -0700 (PDT) To: xen-devel@lists.xenproject.org From: Trevor Bentley Subject: Suspend/hibernate not working on Dell XPS 15 9500 laptop Message-ID: Date: Sat, 27 Jun 2020 08:35:27 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:75.0) Gecko/20100101 Thunderbird/75.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" I asked on #xen on Freenode and was requested to post here. Summary: Under Xen, both suspend and hibernate operations put the laptop into some sort of unrecoverable low-power mode, and a force power-off is required. Environment: - Dell XPS 15 9500, BIOS 1.0.1 (this is a new 2020 model) - Intel i7-10750H - Intel i915 + Nvidia GTX 1650 Ti Mobile - Arch linux (clean install) - Linux kernels 5.7.5, 5.7.6 tested - i915 driver loaded, no nvidia drivers loaded (nouveau blacklisted) - Xen 4.13.1, 4.14.0-rc3 tested - UEFI, GRUB2 bootloader, LUKS-encrypted /boot, /root, and swap (unencrypted /efi with GRUB stub loader) My Xen was built from this Arch AUR: https://aur.archlinux.org/packages/xen/ With these small patches to bump to 4.13.1 using gcc 10: https://github.com/sl4mmy/docker-aur-xen And the same patches manually applied to a git checkout to bump to 4.14.0-rc3. In non-Xen boots, both suspend and hibernate work (using 's2idle' for mem, unsure about 'deep'). In Xen, with no guests configured, both suspend and hibernate in Dom0 power down the screen, fans, and keyboard backlight. Once suspended, nothing awakens it. I tried every combination of /sys/power/pm_test (freezer/devices/platform with s2idle and core/processors/platform/devices/freezer with deep), and all pm tests *succeed*. It goes into whichever low power mode, waits 5 seconds, and fully recovers. I'm unable to interpret the results when /sys/power/pm_trace is enabled. "hash matches" is printed in the dmesg log, seemingly always in a different place/format. /sys/power/pm_trace_dev_match just reported "acpi" the few times I checked it. Please let me know if you have any suggestions to try, or if you need any extra information for debugging. Thanks, Trevor From xen-devel-bounces@lists.xenproject.org Sat Jun 27 09:36:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 09:36:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7FU-0005Lt-OV; Sat, 27 Jun 2020 09:35:48 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7FT-0005Lo-EN for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 09:35:47 +0000 X-Inumbo-ID: 93dd87ea-b859-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 93dd87ea-b859-11ea-b7bb-bc764e2007e4; Sat, 27 Jun 2020 09:35:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vwWtlsXpAj59i1KO8dTOKYC69Dhqn1VPHKeyQnQhr4U=; b=s+4mJs6hJMHxBwzyfPCYxE2cI XurA2vbsKb6BlqvxZGkCKZUPD4I3AKlx2ZYkc9VjrT5Yoy5sQJsRZ4zlwaNJXdCeXFwtdt4OFfHMw 2sutOXTG5fP+mbW/I3zVxi3scHsoRsqSPMZSdERfGeMRMxXK6Fh4HkxmO6qx0iKOFpeNI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7FR-0005TL-NU; Sat, 27 Jun 2020 09:35:45 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jp7FR-0008Ma-Fd; Sat, 27 Jun 2020 09:35:45 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jp7FR-0003uK-F2; Sat, 27 Jun 2020 09:35:45 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [seabios test] 151387: tolerable FAIL - PUSHED X-Osstest-Failures: seabios:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking seabios:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking seabios:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking seabios:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking seabios:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: seabios=88ab0c15525ced2eefe39220742efe4769089ad8 X-Osstest-Versions-That: seabios=d11c75185276ded944f2ea0277532b7fee849bbc From: osstest service owner Date: Sat, 27 Jun 2020 09:35:45 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151387 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/151387/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151363 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151363 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151363 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151363 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: seabios 88ab0c15525ced2eefe39220742efe4769089ad8 baseline version: seabios d11c75185276ded944f2ea0277532b7fee849bbc Last test of basis 151363 2020-06-25 19:05:11 Z 1 days Testing same since 151387 2020-06-26 18:45:26 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Roman Bolshakov jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/seabios.git d11c751..88ab0c1 88ab0c15525ced2eefe39220742efe4769089ad8 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Jun 27 09:55:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 09:55:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7Yh-00071n-GH; Sat, 27 Jun 2020 09:55:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7Yg-00071i-CN for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 09:55:38 +0000 X-Inumbo-ID: 5a2dc89a-b85c-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5a2dc89a-b85c-11ea-bca7-bc764e2007e4; Sat, 27 Jun 2020 09:55:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eTlQ0etwk8SLmWkjWs4iLvynA1H72wix6KqE6Ac6qr8=; b=Dm0XF7tjXr7hMvKpm71zQ1WMNx DNVy4MC2aLk57DJXpi7pST+WTNCpHi5MYgVBay6rqUSOE9lvuae/cBNLwqfyrMj64Nssa08IZcaWh kFuCGaKVIH5oCOjBRmcYQt54xt7TnUEg8C9P+IrzC1r5wWR7obc9SyRE0eJjH11oTIzo=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7Ye-0005pG-Pv; Sat, 27 Jun 2020 09:55:36 +0000 Received: from 54-240-197-227.amazon.com ([54.240.197.227] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jp7Ye-00017R-Eb; Sat, 27 Jun 2020 09:55:36 +0000 From: Julien Grall To: xen-devel@lists.xenproject.org Subject: [PATCH v4 for-4.14 0/2] pvcalls: Reconciliate the spec and the Date: Sat, 27 Jun 2020 10:55:31 +0100 Message-Id: <20200627095533.14145-1-julien@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Julien Grall Hi all, This is v4 to try to reconciliate the pvcalls spec and the header. The series gain an extra patch (#1) to make clear the header is just a reference. This series is candidate for 4.14 to avoid continuing to ship wrong header even they are just a reference. For all the changes see in each patch. Best regards, Julien Grall (2): pvcalls: Clearly spell out that the header is just a reference pvcalls: Document correctly and explicitely the padding for all arches docs/misc/pvcalls.pandoc | 8 -------- xen/include/public/io/pvcalls.h | 7 +++++++ 2 files changed, 7 insertions(+), 8 deletions(-) -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Sat Jun 27 09:55:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 09:55:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7Yn-00072Q-06; Sat, 27 Jun 2020 09:55:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7Yl-00071i-7W for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 09:55:43 +0000 X-Inumbo-ID: 5b952b42-b85c-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5b952b42-b85c-11ea-bca7-bc764e2007e4; Sat, 27 Jun 2020 09:55:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ToWAhOBizK7AhT+LuF1MG0+z4Ou3oX83o1ykrw66Sw8=; b=aFNlYAfDwg9xx6gyCp3FpqEA1c /BkSNm2k9jy+KiZ58TVbt8HJ43i2+l8Ktp14blO3XovY8HAPgKRdE+usRG0n5gChvHCuaY3RdxpJw xmOiW8j+/LhmrmYkyzumzSrSMYfE9flTbAm9+1/3E5F3bcDfhUKhsOoyRaLF2tzpgBmw=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7Yh-0005pb-EW; Sat, 27 Jun 2020 09:55:39 +0000 Received: from 54-240-197-227.amazon.com ([54.240.197.227] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jp7Yh-00017R-55; Sat, 27 Jun 2020 09:55:39 +0000 From: Julien Grall To: xen-devel@lists.xenproject.org Subject: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches Date: Sat, 27 Jun 2020 10:55:33 +0100 Message-Id: <20200627095533.14145-3-julien@xen.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200627095533.14145-1-julien@xen.org> References: <20200627095533.14145-1-julien@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Julien Grall The specification of pvcalls suggests there is padding for 32-bit x86 at the end of most the structure. However, they are not described in in the public header. Because of that all the structures would be 32-bit aligned and not 64-bit aligned for 32-bit x86. For all the other architectures supported (Arm and 64-bit x86), the structure are aligned to 64-bit because they contain uint64_t field. Therefore all the structures contain implicit padding. Given the specification is authoriitative, the padding will the same for the all architectures. The potential breakage of compatibility is ought to be fine as pvcalls is still a tech preview. As an aside, the padding sadly cannot be mandated to be 0 as they are already present. So it is not going to be possible to use the padding for extending a command in the future. Signed-off-by: Julien Grall --- This wants to be included in Xen 4.14 to avoid more users to rely on wrong public headers. Changes in v4: - Revert back to v1 for the patch and expand the commit message Changes in v3: - Use __i386__ rather than CONFIG_X86_32 Changes in v2: - It is not possible to use the same padding for 32-bit x86 and all the other supported architectures. --- docs/misc/pvcalls.pandoc | 8 -------- xen/include/public/io/pvcalls.h | 4 ++++ 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc index 665dad556c39..971cd8f4b122 100644 --- a/docs/misc/pvcalls.pandoc +++ b/docs/misc/pvcalls.pandoc @@ -246,9 +246,7 @@ The format is defined as follows: uint32_t domain; uint32_t type; uint32_t protocol; - #ifdef CONFIG_X86_32 uint8_t pad[4]; - #endif } socket; struct xen_pvcalls_connect { uint64_t id; @@ -257,16 +255,12 @@ The format is defined as follows: uint32_t flags; grant_ref_t ref; uint32_t evtchn; - #ifdef CONFIG_X86_32 uint8_t pad[4]; - #endif } connect; struct xen_pvcalls_release { uint64_t id; uint8_t reuse; - #ifdef CONFIG_X86_32 uint8_t pad[7]; - #endif } release; struct xen_pvcalls_bind { uint64_t id; @@ -276,9 +270,7 @@ The format is defined as follows: struct xen_pvcalls_listen { uint64_t id; uint32_t backlog; - #ifdef CONFIG_X86_32 uint8_t pad[4]; - #endif } listen; struct xen_pvcalls_accept { uint64_t id; diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h index 905880735dda..6da6b5533a10 100644 --- a/xen/include/public/io/pvcalls.h +++ b/xen/include/public/io/pvcalls.h @@ -68,6 +68,7 @@ struct xen_pvcalls_request { uint32_t domain; uint32_t type; uint32_t protocol; + uint8_t pad[4]; } socket; struct xen_pvcalls_connect { uint64_t id; @@ -76,10 +77,12 @@ struct xen_pvcalls_request { uint32_t flags; grant_ref_t ref; uint32_t evtchn; + uint8_t pad[4]; } connect; struct xen_pvcalls_release { uint64_t id; uint8_t reuse; + uint8_t pad[7]; } release; struct xen_pvcalls_bind { uint64_t id; @@ -89,6 +92,7 @@ struct xen_pvcalls_request { struct xen_pvcalls_listen { uint64_t id; uint32_t backlog; + uint8_t pad[4]; } listen; struct xen_pvcalls_accept { uint64_t id; -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Sat Jun 27 09:55:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 09:55:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7Yi-00071y-OO; Sat, 27 Jun 2020 09:55:40 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7Yh-00071t-Uf for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 09:55:39 +0000 X-Inumbo-ID: 5a612ae6-b85c-11ea-8353-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5a612ae6-b85c-11ea-8353-12813bfff9fa; Sat, 27 Jun 2020 09:55:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=xjeUBoQCrN/DHWvdaE0IKA8sH/SoZ4DdwjG9sdN1ffY=; b=F8a+xmakUaJqm0pG+6tDocgp3j h4DDInQ9XU5v+VKtqBc6Lr0O9g/h5HLTpbUlXhyxXSfogJ51+vTfN1nK3eoXq0ubrXGK8+pQXIvzA SZIIWUJVgCKlhzYqqm25Iqsw/IdzuY8i+I8voW/jxZgzQatwZITHrktmXdjLIaAV9Kpw=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7Yf-0005pP-MZ; Sat, 27 Jun 2020 09:55:37 +0000 Received: from 54-240-197-227.amazon.com ([54.240.197.227] helo=ufe34d9ed68d054.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jp7Yf-00017R-Dg; Sat, 27 Jun 2020 09:55:37 +0000 From: Julien Grall To: xen-devel@lists.xenproject.org Subject: [PATCH v4 for-4.14 1/2] pvcalls: Clearly spell out that the header is just a reference Date: Sat, 27 Jun 2020 10:55:32 +0100 Message-Id: <20200627095533.14145-2-julien@xen.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200627095533.14145-1-julien@xen.org> References: <20200627095533.14145-1-julien@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Julien Grall , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Julien Grall A recent thread on xen-devel [1] pointed out that the header was provided as a reference for the specification. Unfortunately, this was never written down in xen.git so for an external user (or a reviewer) it is not clear whether the spec or the header shoudl be followed when there is a conflict. To avoid more confusion, a paragraph is added at the top of the header to clearly spell out it is only provided for reference. [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.21.2006151343430.9074@sstabellini-ThinkPad-T480s/ Signed-off-by: Julien Grall --- Changes in v4: - New patch --- xen/include/public/io/pvcalls.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h index cb8171275c13..905880735dda 100644 --- a/xen/include/public/io/pvcalls.h +++ b/xen/include/public/io/pvcalls.h @@ -3,6 +3,9 @@ * * Refer to docs/misc/pvcalls.markdown for the specification * + * The header is provided as a C reference for the specification. In + * case of conflict, the specification is authoritative. + * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to * deal in the Software without restriction, including without limitation the -- 2.17.1 From xen-devel-bounces@lists.xenproject.org Sat Jun 27 10:15:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 10:15:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7rw-0000WJ-ML; Sat, 27 Jun 2020 10:15:32 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7ru-0000WE-OP for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 10:15:30 +0000 X-Inumbo-ID: 203cf158-b85f-11ea-8354-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 203cf158-b85f-11ea-8354-12813bfff9fa; Sat, 27 Jun 2020 10:15:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GOATMcgjbhsde6qRrkOkK6+w7WpG0AYb/3jBxzIFUEM=; b=KM7L9qeqSSon3rSGLRsdMC5Mq 6kB02HNLGkR7ljcQzTeAM6+xGlImG5mFbWPVm0qOIozlh3TURHIwWb4MorHDpyrBh52f1t8cRhFuZ Y4yuK5t9n7RDOIP7vMTglkXm5PROBloZkZ9HJxg8kGKNX3qncO+0HmLXibHwZA31RsSTI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp7rs-0006H7-EC; Sat, 27 Jun 2020 10:15:28 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jp7rs-00024x-22; Sat, 27 Jun 2020 10:15:28 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jp7rs-000693-1R; Sat, 27 Jun 2020 10:15:28 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151382: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=d3688bf60f798074bf38d712a3e15c88cfb81ed4 X-Osstest-Versions-That: xen=fde76f895d0aa817a1207d844d793239c6639bc6 From: osstest service owner Date: Sat, 27 Jun 2020 10:15:28 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151382 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151382/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151311 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151358 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151358 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151358 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151358 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151358 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151358 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151358 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151358 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151358 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen d3688bf60f798074bf38d712a3e15c88cfb81ed4 baseline version: xen fde76f895d0aa817a1207d844d793239c6639bc6 Last test of basis 151358 2020-06-25 10:54:19 Z 1 days Testing same since 151382 2020-06-26 15:39:39 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Grzegorz Uriasz Jan Beulich Jason Andryuk jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git fde76f895d..d3688bf60f d3688bf60f798074bf38d712a3e15c88cfb81ed4 -> master From xen-devel-bounces@lists.xenproject.org Sat Jun 27 11:54:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 11:54:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp9P4-00004r-Dp; Sat, 27 Jun 2020 11:53:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp9P3-0008WS-UF for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 11:53:49 +0000 X-Inumbo-ID: dce82144-b86c-11ea-8369-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id dce82144-b86c-11ea-8369-12813bfff9fa; Sat, 27 Jun 2020 11:53:49 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 7AA93AF34; Sat, 27 Jun 2020 11:53:48 +0000 (UTC) Subject: Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches To: Julien Grall , xen-devel@lists.xenproject.org References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-3-julien@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <82c445c0-f7fc-176f-fdac-386228cc17f5@suse.com> Date: Sat, 27 Jun 2020 13:53:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200627095533.14145-3-julien@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 27.06.20 11:55, Julien Grall wrote: > From: Julien Grall > > The specification of pvcalls suggests there is padding for 32-bit x86 > at the end of most the structure. However, they are not described in > in the public header. > > Because of that all the structures would be 32-bit aligned and not > 64-bit aligned for 32-bit x86. > > For all the other architectures supported (Arm and 64-bit x86), the > structure are aligned to 64-bit because they contain uint64_t field. > Therefore all the structures contain implicit padding. > > Given the specification is authoriitative, the padding will the same for s/authoriitative/authoritative/ > the all architectures. The potential breakage of compatibility is ought s/the// > to be fine as pvcalls is still a tech preview. > > As an aside, the padding sadly cannot be mandated to be 0 as they are > already present. So it is not going to be possible to use the padding > for extending a command in the future. > > Signed-off-by: Julien Grall With above fixed: Reviewed-by: Juergen Gross Juergen From xen-devel-bounces@lists.xenproject.org Sat Jun 27 11:55:42 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 11:55:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp9Qr-0000AM-QW; Sat, 27 Jun 2020 11:55:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jp9Qq-0000AB-DH for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 11:55:40 +0000 X-Inumbo-ID: 12d4fd4a-b86d-11ea-836a-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 12d4fd4a-b86d-11ea-836a-12813bfff9fa; Sat, 27 Jun 2020 11:55:20 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0AF2BAF34; Sat, 27 Jun 2020 11:55:19 +0000 (UTC) Subject: Re: [PATCH v4 for-4.14 1/2] pvcalls: Clearly spell out that the header is just a reference To: Julien Grall , xen-devel@lists.xenproject.org References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-2-julien@xen.org> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Sat, 27 Jun 2020 13:55:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200627095533.14145-2-julien@xen.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 27.06.20 11:55, Julien Grall wrote: > From: Julien Grall > > A recent thread on xen-devel [1] pointed out that the header was > provided as a reference for the specification. > > Unfortunately, this was never written down in xen.git so for an external > user (or a reviewer) it is not clear whether the spec or the header > shoudl be followed when there is a conflict. should > > To avoid more confusion, a paragraph is added at the top of the header > to clearly spell out it is only provided for reference. > > [1] https://lore.kernel.org/xen-devel/alpine.DEB.2.21.2006151343430.9074@sstabellini-ThinkPad-T480s/ > > Signed-off-by: Julien Grall Reviewed-by: Juergen Gross Juergen From xen-devel-bounces@lists.xenproject.org Sat Jun 27 14:52:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 14:52:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpCC2-000691-15; Sat, 27 Jun 2020 14:52:34 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpCC1-00068h-GD for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 14:52:33 +0000 X-Inumbo-ID: d11c966a-b885-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d11c966a-b885-11ea-bb8b-bc764e2007e4; Sat, 27 Jun 2020 14:52:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sINGFaDrP3DnNMtngMC0i9LcuStNFuhj72NUBhjvmMo=; b=ovcjdwOLbfsWAF6RO06P4t6qu 50D2wMPxJDfuHEFmHtx53sMYsJN5qBFuwuTD/Gy0sF92ylVfJpT9nLK43Jbr4lPKjjnvRX8nyiPQD 43YXs8TmwonQRvSRpHcpwDN7kVF6V9VfugJoiPjSof+hQ4kRYPslrSdEijQNuea8Lhgag=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpCBu-0002v2-1p; Sat, 27 Jun 2020 14:52:26 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpCBt-0008Hy-L7; Sat, 27 Jun 2020 14:52:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpCBt-0008Hl-KQ; Sat, 27 Jun 2020 14:52:25 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-4.12-testing test] 151388: tolerable FAIL - PUSHED X-Osstest-Failures: xen-4.12-testing:test-amd64-amd64-xl-qcow2:guest-localmigrate/x10:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-4.12-testing:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-4.12-testing:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-4.12-testing:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-4.12-testing:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=050fe48dc981e0488de1f6c6c07d8110f3b7523b X-Osstest-Versions-That: xen=09b61126b4d1e9d372fd2e24b702be10a358da9d From: osstest service owner Date: Sat, 27 Jun 2020 14:52:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151388 xen-4.12-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/151388/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail like 150176 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 050fe48dc981e0488de1f6c6c07d8110f3b7523b baseline version: xen 09b61126b4d1e9d372fd2e24b702be10a358da9d Last test of basis 150176 2020-05-14 12:36:34 Z 44 days Failing since 150943 2020-06-09 17:06:00 Z 17 days 16 attempts Testing same since 151341 2020-06-24 16:34:12 Z 2 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Igor Druzhinin Jan Beulich Jason Andryuk Julien Grall Paul Durrant Roger Pau Monné Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 09b61126b4..050fe48dc9 050fe48dc981e0488de1f6c6c07d8110f3b7523b -> stable-4.12 From xen-devel-bounces@lists.xenproject.org Sat Jun 27 18:57:37 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 18:57:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpG0p-0001Hk-WE; Sat, 27 Jun 2020 18:57:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpG0p-0001HM-8M for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 18:57:15 +0000 X-Inumbo-ID: 003be1cc-b8a8-11ea-83f0-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 003be1cc-b8a8-11ea-83f0-12813bfff9fa; Sat, 27 Jun 2020 18:57:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7gM3TngD6tdX2QtXxeOQ/8+8MBsvKV50pRKJVnsNaOM=; b=lIvQu2o+308UL7NLnkQNV/UmU v3BoQJ33bJFFJfttV5y3PGmeIEIDl63BM/zON+SFQe/fztWmZCamDZBUG1bBDgvPsH1bGdQQSYnwC GjVdN9D2RBbSbXyxr/ScXOtouYCMdH1FZjDtxBf6kSW9q0vA1V3iEHXK/rgRHtSK0f/HY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpG0h-0007z2-OG; Sat, 27 Jun 2020 18:57:07 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpG0h-0002Ev-Br; Sat, 27 Jun 2020 18:57:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpG0h-00065R-AM; Sat, 27 Jun 2020 18:57:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151396: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=f6f745297d884453ef4ed65643d267069f778517 X-Osstest-Versions-That: libvirt=bac096fff0bf3414ebeb4306a32ad4dab20ccfdf From: osstest service owner Date: Sat, 27 Jun 2020 18:57:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151396 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151396/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151370 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151370 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt f6f745297d884453ef4ed65643d267069f778517 baseline version: libvirt bac096fff0bf3414ebeb4306a32ad4dab20ccfdf Last test of basis 151370 2020-06-26 04:20:29 Z 1 days Testing same since 151396 2020-06-27 04:19:57 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Bjoern Walk Boris Fiuczynski Daniel P. Berrangé Jonathon Jongsma Michal Privoznik Shalini Chellathurai Saroja jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git bac096fff0..f6f745297d f6f745297d884453ef4ed65643d267069f778517 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Jun 27 20:09:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 20:09:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpH8h-00071b-Ba; Sat, 27 Jun 2020 20:09:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpH8f-00071B-PJ for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 20:09:25 +0000 X-Inumbo-ID: 13b60962-b8b2-11ea-83fa-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 13b60962-b8b2-11ea-83fa-12813bfff9fa; Sat, 27 Jun 2020 20:09:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IzojZPxEFFv0KxK4F5g+1HcF6t8rpuuD76P6kiyn5rQ=; b=t1n0wOjR2QOjTY0Ki8h8Mn2F5 HydLt37C+earCLTwmDGKAywH8iHVg7/0lyr6+f4nh1U4s6kUilX9FRYN+vFSYQV/QjJNAEAhIq4kq /Uakh7kvnUOH0ad7T4nl4Z0todQD+KacxcXdNNbPJFcNQPpxpiJNugXuCFw9mtEJTIfaE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpH8V-0000x2-LK; Sat, 27 Jun 2020 20:09:15 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpH8V-0004Hw-9X; Sat, 27 Jun 2020 20:09:15 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpH8V-00011V-8u; Sat, 27 Jun 2020 20:09:15 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151394: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=1590a2e1c681b0991bd42c992cabfd380e0338f2 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Sat, 27 Jun 2020 20:09:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151394 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151394/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 1590a2e1c681b0991bd42c992cabfd380e0338f2 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 9 days Failing since 151236 2020-06-19 19:10:35 Z 8 days 8 attempts Testing same since 151394 2020-06-27 02:27:18 Z 0 days 1 attempts ------------------------------------------------------------ 344 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 16247 lines long.) From xen-devel-bounces@lists.xenproject.org Sat Jun 27 20:42:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 20:42:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpHeQ-0001lf-6K; Sat, 27 Jun 2020 20:42:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpHeP-0001lB-Ep for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 20:42:13 +0000 X-Inumbo-ID: aa0409b0-b8b6-11ea-8401-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id aa0409b0-b8b6-11ea-8401-12813bfff9fa; Sat, 27 Jun 2020 20:42:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KiGwJGBNx6cXuCesB7Ipkvq+DcEDtPfqYnJYnW/CR1I=; b=NU6lfVy0ZrPQPXWjMbuqgBx2C xfI21b93a0Rftj7VeGna3VZy0Z6xkrbjldpww5f/5a+QwXdzdgcJgyzMmGwzWurJyuur6sR97q3Hd ha4tnxHtpawKu+w3VZo2EaE1MPIeVCnG7jV9QuH5QjBVyNW6HjHA1ETP8AWopT/PcFSz4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpHeH-0001ZY-Nd; Sat, 27 Jun 2020 20:42:05 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpHeH-0005Ae-Dp; Sat, 27 Jun 2020 20:42:05 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpHeH-0005UG-Cm; Sat, 27 Jun 2020 20:42:05 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151401: all pass - PUSHED X-Osstest-Versions-This: ovmf=654dc3ed852aafa126e9d539b7002db348dd6eb0 X-Osstest-Versions-That: ovmf=a4a2258a1fec66665481b0bd929b049921cb07a0 From: osstest service owner Date: Sat, 27 Jun 2020 20:42:05 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151401 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151401/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 654dc3ed852aafa126e9d539b7002db348dd6eb0 baseline version: ovmf a4a2258a1fec66665481b0bd929b049921cb07a0 Last test of basis 151347 2020-06-24 19:53:27 Z 3 days Testing same since 151401 2020-06-27 09:09:22 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Pierre Gondois jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git a4a2258a1f..654dc3ed85 654dc3ed852aafa126e9d539b7002db348dd6eb0 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sat Jun 27 20:58:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 27 Jun 2020 20:58:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpHuR-0002kP-IL; Sat, 27 Jun 2020 20:58:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpHuQ-0002kK-Ok for xen-devel@lists.xenproject.org; Sat, 27 Jun 2020 20:58:46 +0000 X-Inumbo-ID: fcfc6084-b8b8-11ea-8402-12813bfff9fa Received: from gordon.huskydog.org.uk (unknown [81.187.95.156]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id fcfc6084-b8b8-11ea-8402-12813bfff9fa; Sat, 27 Jun 2020 20:58:44 +0000 (UTC) Received: from [10.137.3.12] (percyq.huskydog.org.uk [10.42.42.111]) by gordon.huskydog.org.uk (Postfix) with ESMTP id 82B783E45; Sat, 27 Jun 2020 21:58:43 +0100 (BST) Subject: Re: ARM - Successful install on RockPro64 To: Julien Grall , Bertrand Marquis References: <46497134-fb7c-3d1f-6414-539138856480@huskydog.org.uk> <6AB44468-BD6A-4140-B0EF-3D2E5EDC99A0@arm.com> <8013f2db-3732-0679-81f6-7b274b39c44f@xen.org> <49e5b539-145a-726a-fb80-a93e65e44ca0@huskydog.org.uk> From: Richard Simpson Message-ID: Date: Sat, 27 Jun 2020 21:58:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , nd , Stefano Stabellini Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello Julien, yes the clk_ignored_unused option fixed the boot message problem.  I would never have worked that out for myself. The relevant lines now read: Xen: console=dtuart dtuart=serial2 Linux: console=hvc0 earlyprintk=xen clk_ignore_unused inittab: h0:12345:respawn:/sbin/agetty 1500000 hvc0 vt100 I have added a note to the Xen Serial Console Wiki page which - I was shocked to observe - hadn't been updated since 2014.  I'll add it to my list of pages to refresh, noting that I only have Xen on this one ARM SBC (excluding my QubesOS laptop) so I can only check anything I write relative to that. Regards,     Richard On 6/24/20 1:42 PM, Julien Grall wrote: > > > On 17/06/2020 23:28, Richard Simpson wrote: >> Hello Julien, > > Hello Richard, > > Apologies for the late answer. > >> I have just tried 4.14-rc2 and it seems to work fine. > > Glad to hear that. Thank you for the testing! > >> I think that the most useful page regarding the board is the one for >> the Ibox3399 since this refers to the RK3399 chip which the RockPro64 >> uses (shouldn't the page actually be called RK3399 to make it more >> generic). > > I agree with the renaming here. > >> Perhaps I can most usefully record what I did by updating that page >> and making sure that the instructions work correctly. If there is >> additional stuff relevant to the RockPro64 over and above the generic >> RK3399 info then I'll give some thought to how to best record it.  I >> will eventually be writing a fuller report on my progress on my blog >> at funfoodfreedom.huskydog.org.uk. > > Any additional content on the wiki will be greatly appreciated. By > default new wiki account doesn't have write permission, but we can > enable it for you if you provide us your username. > >> >> I now need to finish automating the boot process (still requires >> manual u-boot command) and figure out how to get the console log to >> work. > > I wrote a small u-boot script in the past to try to automate the boot > (see [2]). > > I vaguely remember some quoting issue and missing 0x in front of > values depending on the U-boot configuration you use. So you may have > to tweak it a bit. > >> Currently I can either see the xen and linux kernel boot messages OR >> see the dom0 console, but not both. > > Can you provide the kernel/xen command lines you use in the two cases? > > As an aside, I know that on some setup Linux will try to disable the > clock of the UART used by Xen. One of the symptoms is the UART is > becoming completely unusable half way through Linux boot. > > You may want to try to pass clk_ignored_unused to see if it helps. > >> On one more related note:  I suspect that Xen would run on the >> PineBookPro as well as I get the impression that it uses very similar >> hardware.  Of course that would rely on the GPU etc which I haven't >> tested at all as I am using the serial console. > I wouldn't expect any issue to use the GPU in dom0 at least if you > don't have an IOMMU on the platform. The trouble may be more with the > bootloader if it doesn't drop you in hypervisor mode. > >> >> Finally, when I joined this mailing list I asked for a daily digest. >> However I seem to be getting a new digest every hour or so.  Is this >> right? > > I haven't used the digest myself. I CC Ian Jackson who may be able to > help you. > > Cheers, > > [2] https://xenbits.xen.org/people/julieng/load-xen-tftp.scr.txt > From xen-devel-bounces@lists.xenproject.org Sun Jun 28 01:44:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 01:44:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpMMM-00023T-2o; Sun, 28 Jun 2020 01:43:54 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpMMK-00023O-A7 for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 01:43:52 +0000 X-Inumbo-ID: cfd4c876-b8e0-11ea-8428-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cfd4c876-b8e0-11ea-8428-12813bfff9fa; Sun, 28 Jun 2020 01:43:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WRTkmnoaMNHa6tThXtigTpRq8I6UFHCk/W1cvDUFq9s=; b=DplA4INeY/GI9rRPWTrk/4Prk XP95fULW03+9Oj7xAAubhpmKRdX3YvIxwoX6Y33rbDh4hDv+yz7I+HGJSmaB8VMT2Jt3CqY1mzNRI Lk6/GLGDST5+0XLyuhnYAEBxCcDXX0DjHypPHudUk1lGlC+5dliIApTQlDhXlSRlfd++0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpMMG-0000cw-GP; Sun, 28 Jun 2020 01:43:48 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpMMG-0003Us-2f; Sun, 28 Jun 2020 01:43:48 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpMMG-0008Ep-1J; Sun, 28 Jun 2020 01:43:48 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151399: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=553cf5d7c47bee05a3dec9461c1f8430316d516b X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Sun, 28 Jun 2020 01:43:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151399 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151399/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass version targeted for testing: qemuu 553cf5d7c47bee05a3dec9461c1f8430316d516b baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 15 days Failing since 151101 2020-06-14 08:32:51 Z 13 days 12 attempts Testing same since 151399 2020-06-27 08:25:20 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Andrew Jones Ani Sinha Anthony PERARD Ard Biesheuvel Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Cleber Rosa Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé Daniele Buono David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Finn Thain Geoffrey McRae Gerd Hoffmann Greg Kurz Guenter Roeck Gustavo Romero Helge Deller Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jay Zhou Jean-Christophe Dubois Jiaxun Yang Jingqi Liu John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Liao Pingfang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marcelo Tosatti Marek Marczykowski-Górecki Mark Cave-Ayland Markus Armbruster Masahiro Yamada Max Filippov Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Raphael Norwitz Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Shameer Kolothum Stefan Berger Stefan Berger Stefan Hajnoczi Tao Xu Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 14163 lines long.) From xen-devel-bounces@lists.xenproject.org Sun Jun 28 02:47:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 02:47:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpNM0-0007I6-Ah; Sun, 28 Jun 2020 02:47:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpNLy-0007I1-Kj for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 02:47:34 +0000 X-Inumbo-ID: b770acc4-b8e9-11ea-bb8b-bc764e2007e4 Received: from userp2130.oracle.com (unknown [156.151.31.86]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b770acc4-b8e9-11ea-bb8b-bc764e2007e4; Sun, 28 Jun 2020 02:47:33 +0000 (UTC) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05S2lU3f173859; Sun, 28 Jun 2020 02:47:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=6EJhz6O6XJXhJjjPc5dAnrqgtTqh0qQdNNeE1PB8UkY=; b=DD67jKf97gMgDGxtE7AHV3jBNkuOyrtkm7zmJVYNaK3LhIhuFDsiLtGK7sdcuD69YsZj 4UCl+DlWaXK+WACCaknqeueeqOvuAjny89go1E/TMuNQP0mRGNPZweTiFqZY+bbYiCK1 8hnU+4GU4/fGe+h1ACt/p0FsPVeWdpMbPEyLN6bJxNp0pTtq8NXicZl0N2pjtFOnBzPR ZPXGugg00SdzY2Ta1pOcs7XulbjKpxYhhHWQjNLcO/Et7WwqQdLirTSNW1M8t9lh44Mt EmnCxxivpQoqqvMWoerDuSpyosobnBRQRxWNb9ENzAKQPC/Gb/F8Og8kDuvbeQHKnA2z Qw== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 31wwhr9ynr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 28 Jun 2020 02:47:30 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05S2iGR9179928; Sun, 28 Jun 2020 02:47:30 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 31xfpjbcf8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Jun 2020 02:47:29 +0000 Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 05S2lQQX027841; Sun, 28 Jun 2020 02:47:26 GMT Received: from [10.39.250.213] (/10.39.250.213) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 28 Jun 2020 02:47:23 +0000 Subject: Re: [PATCH 3/6] x86/entry/64/compat: Fix Xen PV SYSENTER frame setup To: Andy Lutomirski , x86@kernel.org References: <947880c41ade688ff4836f665d0c9fcaa9bd1201.1593191971.git.luto@kernel.org> From: Boris Ostrovsky Autocrypt: addr=boris.ostrovsky@oracle.com; keydata= xsFNBFH8CgsBEAC0KiOi9siOvlXatK2xX99e/J3OvApoYWjieVQ9232Eb7GzCWrItCzP8FUV PQg8rMsSd0OzIvvjbEAvaWLlbs8wa3MtVLysHY/DfqRK9Zvr/RgrsYC6ukOB7igy2PGqZd+M MDnSmVzik0sPvB6xPV7QyFsykEgpnHbvdZAUy/vyys8xgT0PVYR5hyvhyf6VIfGuvqIsvJw5 C8+P71CHI+U/IhsKrLrsiYHpAhQkw+Zvyeml6XSi5w4LXDbF+3oholKYCkPwxmGdK8MUIdkM d7iYdKqiP4W6FKQou/lC3jvOceGupEoDV9botSWEIIlKdtm6C4GfL45RD8V4B9iy24JHPlom woVWc0xBZboQguhauQqrBFooHO3roEeM1pxXjLUbDtH4t3SAI3gt4dpSyT3EvzhyNQVVIxj2 FXnIChrYxR6S0ijSqUKO0cAduenhBrpYbz9qFcB/GyxD+ZWY7OgQKHUZMWapx5bHGQ8bUZz2 SfjZwK+GETGhfkvNMf6zXbZkDq4kKB/ywaKvVPodS1Poa44+B9sxbUp1jMfFtlOJ3AYB0WDS Op3d7F2ry20CIf1Ifh0nIxkQPkTX7aX5rI92oZeu5u038dHUu/dO2EcuCjl1eDMGm5PLHDSP 0QUw5xzk1Y8MG1JQ56PtqReO33inBXG63yTIikJmUXFTw6lLJwARAQABzTNCb3JpcyBPc3Ry b3Zza3kgKFdvcmspIDxib3Jpcy5vc3Ryb3Zza3lAb3JhY2xlLmNvbT7CwXgEEwECACIFAlH8 CgsCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEIredpCGysGyasEP/j5xApopUf4g 9Fl3UxZuBx+oduuw3JHqgbGZ2siA3EA4bKwtKq8eT7ekpApn4c0HA8TWTDtgZtLSV5IdH+9z JimBDrhLkDI3Zsx2CafL4pMJvpUavhc5mEU8myp4dWCuIylHiWG65agvUeFZYK4P33fGqoaS VGx3tsQIAr7MsQxilMfRiTEoYH0WWthhE0YVQzV6kx4wj4yLGYPPBtFqnrapKKC8yFTpgjaK jImqWhU9CSUAXdNEs/oKVR1XlkDpMCFDl88vKAuJwugnixjbPFTVPyoC7+4Bm/FnL3iwlJVE qIGQRspt09r+datFzPqSbp5Fo/9m4JSvgtPp2X2+gIGgLPWp2ft1NXHHVWP19sPgEsEJXSr9 tskM8ScxEkqAUuDs6+x/ISX8wa5Pvmo65drN+JWA8EqKOHQG6LUsUdJolFM2i4Z0k40BnFU/ kjTARjrXW94LwokVy4x+ZYgImrnKWeKac6fMfMwH2aKpCQLlVxdO4qvJkv92SzZz4538az1T m+3ekJAimou89cXwXHCFb5WqJcyjDfdQF857vTn1z4qu7udYCuuV/4xDEhslUq1+GcNDjAhB nNYPzD+SvhWEsrjuXv+fDONdJtmLUpKs4Jtak3smGGhZsqpcNv8nQzUGDQZjuCSmDqW8vn2o hWwveNeRTkxh+2x1Qb3GT46uzsFNBFH8CgsBEADGC/yx5ctcLQlB9hbq7KNqCDyZNoYu1HAB Hal3MuxPfoGKObEktawQPQaSTB5vNlDxKihezLnlT/PKjcXC2R1OjSDinlu5XNGc6mnky03q yymUPyiMtWhBBftezTRxWRslPaFWlg/h/Y1iDuOcklhpr7K1h1jRPCrf1yIoxbIpDbffnuyz kuto4AahRvBU4Js4sU7f/btU+h+e0AcLVzIhTVPIz7PM+Gk2LNzZ3/on4dnEc/qd+ZZFlOQ4 KDN/hPqlwA/YJsKzAPX51L6Vv344pqTm6Z0f9M7YALB/11FO2nBB7zw7HAUYqJeHutCwxm7i BDNt0g9fhviNcJzagqJ1R7aPjtjBoYvKkbwNu5sWDpQ4idnsnck4YT6ctzN4I+6lfkU8zMzC gM2R4qqUXmxFIS4Bee+gnJi0Pc3KcBYBZsDK44FtM//5Cp9DrxRQOh19kNHBlxkmEb8kL/pw XIDcEq8MXzPBbxwHKJ3QRWRe5jPNpf8HCjnZz0XyJV0/4M1JvOua7IZftOttQ6KnM4m6WNIZ 2ydg7dBhDa6iv1oKdL7wdp/rCulVWn8R7+3cRK95SnWiJ0qKDlMbIN8oGMhHdin8cSRYdmHK kTnvSGJNlkis5a+048o0C6jI3LozQYD/W9wq7MvgChgVQw1iEOB4u/3FXDEGulRVko6xCBU4 SQARAQABwsFfBBgBAgAJBQJR/AoLAhsMAAoJEIredpCGysGyfvMQAIywR6jTqix6/fL0Ip8G jpt3uk//QNxGJE3ZkUNLX6N786vnEJvc1beCu6EwqD1ezG9fJKMl7F3SEgpYaiKEcHfoKGdh 30B3Hsq44vOoxR6zxw2B/giADjhmWTP5tWQ9548N4VhIZMYQMQCkdqaueSL+8asp8tBNP+TJ PAIIANYvJaD8xA7sYUXGTzOXDh2THWSvmEWWmzok8er/u6ZKdS1YmZkUy8cfzrll/9hiGCTj u3qcaOM6i/m4hqtvsI1cOORMVwjJF4+IkC5ZBoeRs/xW5zIBdSUoC8L+OCyj5JETWTt40+lu qoqAF/AEGsNZTrwHJYu9rbHH260C0KYCNqmxDdcROUqIzJdzDKOrDmebkEVnxVeLJBIhYZUd t3Iq9hdjpU50TA6sQ3mZxzBdfRgg+vaj2DsJqI5Xla9QGKD+xNT6v14cZuIMZzO7w0DoojM4 ByrabFsOQxGvE0w9Dch2BDSI2Xyk1zjPKxG1VNBQVx3flH37QDWpL2zlJikW29Ws86PHdthh Fm5PY8YtX576DchSP6qJC57/eAAe/9ztZdVAdesQwGb9hZHJc75B+VNm4xrh/PJO6c1THqdQ 19WVJ+7rDx3PhVncGlbAOiiiE3NOFPJ1OQYxPKtpBUukAlOTnkKE6QcA4zckFepUkfmBV1wM Jg6OxFYd01z+a+oL Message-ID: <5056e7ad-715c-23cc-c0e5-9a9ae5a3d61c@oracle.com> Date: Sat, 27 Jun 2020 22:47:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <947880c41ade688ff4836f665d0c9fcaa9bd1201.1593191971.git.luto@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9665 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 suspectscore=0 mlxscore=0 phishscore=0 bulkscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006280019 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9665 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 phishscore=0 priorityscore=1501 clxscore=1011 cotscore=-2147483648 mlxscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 bulkscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006280020 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Andrew Cooper , Stefano Stabellini , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/26/20 1:21 PM, Andy Lutomirski wrote: > The SYSENTER frame setup was nonsense. It worked by accident > because the normal code into which the Xen asm jumped > (entry_SYSENTER_32/compat) threw away SP without touching the stack. > entry_SYSENTER_compat was recently modified such that it relied on > having a valid stack pointer, so now the Xen asm needs to invoke it > with a valid stack. > > Fix it up like SYSCALL: use the Xen-provided frame and skip the bare > metal prologue. > > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: Stefano Stabellini > Cc: xen-devel@lists.xenproject.org > Fixes: 1c3e5d3f60e2 ("x86/entry: Make entry_64_compat.S objtool clean") > Signed-off-by: Andy Lutomirski Reviewed-by: Boris Ostrovsky From xen-devel-bounces@lists.xenproject.org Sun Jun 28 04:15:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 04:15:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpOid-0006GM-35; Sun, 28 Jun 2020 04:15:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpOic-0006Fv-3h for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 04:15:02 +0000 X-Inumbo-ID: eb1ed486-b8f5-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eb1ed486-b8f5-11ea-bca7-bc764e2007e4; Sun, 28 Jun 2020 04:14:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ripyVfW6CKG7aPxJHoWXOyW7+IwHyrnbZN+RfwerVUc=; b=0jbHRPCQK4IyzMAJahOp2MI9a SNQtdtadMqpih1BCpHZdbUVjR9eNpdSr04Ne6G6C8UiozOL548pytuTe/3halCq4RAMgmKG5f+6Vs uMM48qoiCCm5+kWg8q3w/RR4PMgj75pNAHywsyYW/NiABebkIcy3QnMIJmOhF2yWwq7TA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpOiS-0003rw-Sl; Sun, 28 Jun 2020 04:14:52 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpOiS-0000ks-FJ; Sun, 28 Jun 2020 04:14:52 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpOiS-0003el-ET; Sun, 28 Jun 2020 04:14:52 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151402: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:regression xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=88cfd062e8318dfeb67c7d2eb50b6cd224b0738a X-Osstest-Versions-That: xen=d3688bf60f798074bf38d712a3e15c88cfb81ed4 From: osstest service owner Date: Sun, 28 Jun 2020 04:14:52 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151402 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151402/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 151382 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151382 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 151382 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151382 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151382 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151382 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151382 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a baseline version: xen d3688bf60f798074bf38d712a3e15c88cfb81ed4 Last test of basis 151382 2020-06-26 15:39:39 Z 1 days Testing same since 151402 2020-06-27 10:19:44 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Grzegorz Uriasz Ian Jackson Jan Beulich Jason Andryuk Tim Deegan Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a Author: Andrew Cooper Date: Fri Jun 26 15:35:27 2020 +0100 changelog: Add notes about CET and Migration changes Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant commit 92167e9430c010df410336f2b68cc4e30b7872d9 Author: Andrew Cooper Date: Mon Jun 8 18:47:58 2020 +0100 x86/livepatch: Make livepatching compatible with CET Shadow Stacks Just like the alternatives infrastructure, the livepatch infrastructure disables CR0.WP to perform patching, which is not permitted with CET active. Modify arch_livepatch_{quiesce,revive}() to disable CET before disabling WP, and reset the dirty bits on all virtual regions before re-enabling CET. One complication is that arch_livepatch_revive() has to fix up the top of the shadow stack. This depends on the functions not being inlined, even under LTO. Another limitation is that reset_virtual_region_perms() may shatter the final superpage of .text depending on alignment. This logic, and its downsides, are temporary until the patching infrastructure can be adjusted to not use CR0.WP. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Reviewed-by: Ross Lagerwall Release-acked-by: Paul Durrant commit bcdfbb70fca579baa04f212c0936b77919bdae11 Author: Andrew Cooper Date: Fri Jun 19 12:14:32 2020 +0100 x86/msr: Disallow access to Processor Trace MSRs We do not expose the feature to guests, so should disallow access to the respective MSRs. For simplicity, drop the entire block of MSRs, not just the subset which have been specified thus far. Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Jan Beulich Release-acked-by: Paul Durrant commit 40b532fbdcb2095da7152a1d08d9f0288524c223 Author: Jason Andryuk Date: Wed Jun 10 23:29:36 2020 -0400 vchan-socket-proxy: Handle closing shared input/output_fd input_fd & output_fd may be the same FD. In that case, mark both as -1 when closing one. That avoids a dangling FD reference. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit d20c0f1a7864a38b6c26d11d0e44467fba118625 Author: Jason Andryuk Date: Wed Jun 10 23:29:35 2020 -0400 vchan-socket-proxy: Cleanup resources on exit Close open FDs and close th vchan connection when exiting the program. This addresses some Coverity findings about leaking file descriptors. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 620225c48573396dc2394f59080a2d704a566c9d Author: Jason Andryuk Date: Wed Jun 10 23:29:34 2020 -0400 vchan-socket-proxy: Set closed FDs to -1 These FDs are closed, so set them to -1 so they are no longer valid. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit bfb310ee686bc36c9a8f9c15c42f97f96206cd29 Author: Jason Andryuk Date: Wed Jun 10 23:29:33 2020 -0400 vchan-socket-proxy: Switch data_loop() to take state Switch data_loop to take a pointer to vchan_proxy_state. No functional change. This removes a dead store to input_fd identified by Coverity. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit ace450ebdf120c081e02b40896dc719646708046 Author: Jason Andryuk Date: Wed Jun 10 23:29:32 2020 -0400 vchan-socket-proxy: Use a struct to store state Use a struct to group the vchan ctrl and FDs. This will facilite tracking the state of open and closed FDs and ctrl in data_loop(). Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 2b1a2188111ec3f39de1c6e6ff834e6894d1e05a Author: Jason Andryuk Date: Wed Jun 10 23:29:31 2020 -0400 vchan-socket-proxy: Unify main return value Introduce 'ret' for main's return value and remove direct returns. This is in preparation for a unified exit path with resource cleanup. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 20b65c15a38d98f31f212925a3e5a733dce5b477 Author: Jason Andryuk Date: Wed Jun 10 23:29:30 2020 -0400 vchan-socket-proxy: Check xs_watch return value Check the return value of xs_watch and error out on failure. This was found by Citrix's Coverity. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit fbdf181fe36516d74b77217207565e87511bf805 Author: Jason Andryuk Date: Wed Jun 10 23:29:29 2020 -0400 vchan-socket-proxy: Move perror() into connect_socket errno is reset by subsequent system & library calls, so it may be inaccurate by the time connect_socket returns. Call perror immediately after failing system calls to print the proper message. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 01b9a28e7d1dc54968d5081bdc089449052df939 Author: Jason Andryuk Date: Wed Jun 10 23:29:28 2020 -0400 vchan-socket-proxy: Move perror() into listen_socket The use of perror on the return from listen_socket can produce misleading results like: UNIX socket path "/tmp/aa....aa" too long (156 >= 108) listen socket: Success errno is reset by subsequent system & library calls, so it may be inaccurate by the time listen_socket returns. Call perror immediately after failing system calls to print the proper message. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 2c8ac47d4e780389842f812bb6b2f95fa673add5 Author: Jason Andryuk Date: Wed Jun 10 23:29:27 2020 -0400 vchan-socket-proxy: Ensure UNIX path NUL terminated Check the socket path length to ensure sun_path is NUL terminated. This was spotted by Citrix's Coverity. Also use strcpy to avoid a warning "'__builtin_strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation]" flagged by gcc 10. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit ed69c2ecaf3a6745b7c5a10cf2482e3c49cb8c4f Author: Grzegorz Uriasz Date: Sun Jun 14 16:17:08 2020 +0000 libxl: tooling expects wrong errno When iommu is not enabled for a given domain then pci passthrough hypercalls such as xc_test_assign_device return EOPNOTSUPP. The code responsible for this is in "iommu_do_domctl" inside xen/drivers/passthrough/iommu.c This patch fixes the error message reported by libxl when assigning pci devices to domains without iommu. Signed-off-by: Grzegorz Uriasz Tested-by: Grzegorz Uriasz Backport: 4.13 Acked-by: Ian Jackson Release-acked-by: Paul Durrant commit 3471cafbdda35eacf04670881dd2aee2558b4f08 Author: Tim Deegan Date: Fri Jun 26 10:40:44 2020 +0000 kdd: stop using [0] arrays to access packet contents GCC 10 is unhappy about this, and we already use 64k buffers in the only places where packets are allocated, so move the 64k size into the packet definition. Reported-by: Olaf Hering Signed-off-by: Tim Deegan Acked-by: Wei Liu Release-acked-by: Paul Durrant commit f91d103e74d4c2efa60fb42b6e9d530a92838f8e Author: Andrew Cooper Date: Wed Jun 10 12:40:04 2020 +0100 tools: fix error path of xendevicemodel_open() c/s 6902cb00e03 "tools/libxendevicemodel: extract functions and add a compat layer" introduced calls to both xencall_open() and osdep_xendevicemodel_open() but failed to fix up the error path. c/s f68c7c618a3 "libs/devicemodel: free xencall handle in error path in _open()" fixed up the xencall_open() aspect of the error path (missing the osdep_xendevicemodel_open() aspect), but positioned the xencall_close() incorrectly, creating the same pattern proved to be problematic by c/s 30a72f02870 "tools: fix error path of xenhypfs_open()". Reposition xtl_logger_destroy(), and introduce the missing osdep_xendevicemodel_close(). Fixes: 6902cb00e03 ("tools/libxendevicemodel: extract functions and add a compat layer") Fixes: f68c7c618a3 ("libs/devicemodel: free xencall handle in error path in _open()") Backport: 4.9+ Signed-off-by: Andrew Cooper Reviewed-by: Juergen Gross Release-acked-by: Paul Durrant Reviewed-by: Ian Jackson (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Jun 28 04:41:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 04:41:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpP8T-0000EM-Ft; Sun, 28 Jun 2020 04:41:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpLf7-0005Vm-60 for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 00:59:13 +0000 X-Inumbo-ID: 9206cefa-b8da-11ea-8425-12813bfff9fa Received: from huawei.com (unknown [45.249.212.190]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9206cefa-b8da-11ea-8425-12813bfff9fa; Sun, 28 Jun 2020 00:59:10 +0000 (UTC) Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 8ECEB9B8377CC198B1C8; Sun, 28 Jun 2020 08:59:06 +0800 (CST) Received: from localhost.localdomain (10.69.192.56) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.487.0; Sun, 28 Jun 2020 08:58:56 +0800 From: Xiaofei Tan To: , , , , Subject: [PATCH] arm/xen: remove the unused macro GRANT_TABLE_PHYSADDR Date: Sun, 28 Jun 2020 08:57:06 +0800 Message-ID: <1593305826-28279-1-git-send-email-tanxiaofei@huawei.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.69.192.56] X-CFilter-Loop: Reflected X-Mailman-Approved-At: Sun, 28 Jun 2020 04:41:44 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xiaofei Tan , linuxarm@huawei.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Fix the following sparse warning: arch/arm64/xen/../../arm/xen/enlighten.c:244: warning: macro "GRANT_TABLE_PHYSADDR" is not used [-Wunused-macros] It is an isolated macro, and should be removed when its last user was deleted in the following commit 3cf4095d7446 ("arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table") Signed-off-by: Xiaofei Tan --- arch/arm/xen/enlighten.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c index fd4e1ce1..e93145d 100644 --- a/arch/arm/xen/enlighten.c +++ b/arch/arm/xen/enlighten.c @@ -241,7 +241,6 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname, * see Documentation/devicetree/bindings/arm/xen.txt for the * documentation of the Xen Device Tree format. */ -#define GRANT_TABLE_PHYSADDR 0 void __init xen_early_init(void) { of_scan_flat_dt(fdt_find_hyper_node, NULL); -- 2.7.4 From xen-devel-bounces@lists.xenproject.org Sun Jun 28 06:58:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 06:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpRGc-0002jF-Su; Sun, 28 Jun 2020 06:58:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpRGb-0002jA-Vt for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 06:58:18 +0000 X-Inumbo-ID: bd4ebb4a-b90c-11ea-8446-12813bfff9fa Received: from mout.web.de (unknown [217.72.192.78]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id bd4ebb4a-b90c-11ea-8446-12813bfff9fa; Sun, 28 Jun 2020 06:58:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1593327495; bh=NNIfy6Qb51fWZFOY6Z5CwNKi4EfIAC0oBskgu1FU4CI=; h=X-UI-Sender-Class:From:To:Subject:Date; b=bAK/1+f11BYYEN1C6Fmj9Fh1C8QPhSsK3CCmZ22V8tpPVBCmaUG7LJ49x9d7teoif kMuGL56SpPwPeqWpiijrLNiDXBTHedPGsbjeRHdDBsqe7/NhQsAafnU38IlOo5aKpD rhNsSRpSA4quxqrlOxf+SxxCTddy6YdArt9N+KxM= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [79.201.93.129] ([79.201.93.129]) by web-mail.web.de (3c-app-webde-bap42.server.lan [172.19.172.42]) (via HTTP); Sun, 28 Jun 2020 08:58:14 +0200 MIME-Version: 1.0 Message-ID: From: joshua_peter@web.de To: xen-devel@lists.xenproject.org Subject: Questions about PVH memory layout Content-Type: text/plain; charset=UTF-8 Date: Sun, 28 Jun 2020 08:58:14 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K1:7h398uufS1yhCrfUDVXaGb22eEZs85FklJoX48vabYF039MQFdN90wtHygqryUOSi5Wqz qm53L4awRDp/YjNZ7tmfMOInppRkB5JNOjURXL9+n7woxm4d0ZGx1X6wd7g6fks/Yngm4MoEjhYO CtLv1Dx7m7hKOzS5RpHAgy9zRM/Trnkzquq+nt8K0jtHG9is367Gza/sKC+g8LhWKOHsXjQnIcbR vlk3DsFDkUgRjeLU8p8LqoDsCjQyCjzyL/0hG1t0owGbLCa2zGGCcvrwvikkUnNBDRwUa8Tk0paD u0= X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:ppMOxAhQmlc=:ljL1d8ae0i+aSvUMuk9m0E YnyJXOgXinCxIpwrNGOzCkYVp74e7pNQ2mCbz+iSh/kwRTsaOONjzTpoh7xSI43l6SZp+g4xy pmKrdUfK1AGgWPrabkoKRcNf4M2EyB4hSc4FwhOIGhTLq53Xxel40p3yxGlCOB7nhb1u2dc8P IFUO5/V8FIP3A5Bt9U4dEkUdZJOflAPENOSDaOM+tZUixmyDVEUrKiAGWdqNEWNC+reHLA6VN BmaODpRVcufmLu0knX0aeuTGjkD4MX2gskOAINwuSs8D0LG3llKJ/E8tyIxW+N5VYoq67xBVX nk5dSRyZrZGbxHhCPYODAhe8aUvKpwvYAJlyFLh7rSWGwSffdG1L8/O28j2mnV0wlvipvwdvw vfQskmPp85+C0ksMqDEUuo5dYjdf0BIidj3VjOLBSY+znaCIU11XLZwvdSUzLF28wIvQipV7n Ka2WquytDjgLdjQ/gRdvkJQNTdCSOb8bubPICkO5hLPEVmzluQvPh69rxtRXD2SN3CpyGRQ6P RbvaQ1NK7cQr2diEVqj3WgHgK/crYgzcSY9f9ogfyLmzRJaySK9tA7SXiMKz8WNdbuqvHIkjq Ya3OztyEGsW+ZZmJVZLR2ztr4bzF0QY2N+mU1FkRewzY8uB4WEhBvKORcyvOaYaIlg5wlIO5c Rs6RjBULYY+01FzlZbPDKZuca8vpOT4QjQ869xLF0H6LuP0Y6IEM2FwnYCCJLgoVQXw8= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hello everyone, I hope this is the right forum for these kinds of questions (the website states no "technical support queries"; I'm not sure if this qualifies). If not, sorry for the disturbance; just simply direct me elsewhere then. Anyway, I'm currently trying to get into how Xen works in detail, so for one I've been reading a lot of code, but also I dumped the P2M table of my PVH guest to get a feel for how things are layed out in memory. I mean there is the usual stuff, such as lots of RAM, and the APIC is mapped at 0xFEE00000 and the APCI tables at 0xFC000000 onwards. But two things stuck out to me, which for the life of me I couldn't figure out from just reading the code. The first one is, there are a few pages at the end of the 32bit address space (from 0xFEFF8000 to 0xFEFFF000), which according to the E820 is declared simply as "reserved". The other thing is, the first 512 pages at the beginning of the address space are mapped linearly, which usually leads to them being mapped as a single 2MB pages. But there is this one page at 0x00001000 that sticks out completely. By that I mean (to make things more concrete), in my PVH guest the page at 0x00000000 maps to 0x13C200000, 0x00002000 maps to 0x13C202000, 0x00003000 maps to 0x13C203000, etc. But 0x00001000 maps to 0xB8DBD000, which seems very odd to me (at least from simply looking at the addresses). My initial guess was that this is some bootloader related stuff, but Google didn't show up any info related to that memory area, and most of the x86/PC boot stuff seems to happen below the 0x1000 mark. Would someone be so kind to tell me what those two things are? Many thanks in advance. (Btw. I'm running Xen 4.13.1 on Intel x64, booting my PVH guest with PyGRUB, if it's relevant.) Best regards, Peter From xen-devel-bounces@lists.xenproject.org Sun Jun 28 08:50:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 08:50:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpT0y-0004Ih-VJ; Sun, 28 Jun 2020 08:50:16 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpT0x-0004Ic-K1 for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 08:50:15 +0000 X-Inumbo-ID: 61285834-b91c-11ea-8456-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 61285834-b91c-11ea-8456-12813bfff9fa; Sun, 28 Jun 2020 08:50:13 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 554A2B133; Sun, 28 Jun 2020 08:50:12 +0000 (UTC) Subject: Re: [PATCH] efi: avoid error message when booting under Xen To: xen-devel@lists.xenproject.org, linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20200610141052.13258-1-jgross@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <094be567-2c82-7d5b-e432-288286c6c3fb@suse.com> Date: Sun, 28 Jun 2020 10:50:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200610141052.13258-1-jgross@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Peter Jones , Bartlomiej Zolnierkiewicz Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Ping? On 10.06.20 16:10, Juergen Gross wrote: > efifb_probe() will issue an error message in case the kernel is booted > as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid > that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT > isn't set. > > Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB") > Signed-off-by: Juergen Gross > --- > drivers/video/fbdev/efifb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > index 65491ae74808..f5eccd1373e9 100644 > --- a/drivers/video/fbdev/efifb.c > +++ b/drivers/video/fbdev/efifb.c > @@ -453,7 +453,7 @@ static int efifb_probe(struct platform_device *dev) > info->apertures->ranges[0].base = efifb_fix.smem_start; > info->apertures->ranges[0].size = size_remap; > > - if (efi_enabled(EFI_BOOT) && > + if (efi_enabled(EFI_BOOT) && !efi_enabled(EFI_PARAVIRT) && > !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) { > if ((efifb_fix.smem_start + efifb_fix.smem_len) > > (md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) { > From xen-devel-bounces@lists.xenproject.org Sun Jun 28 09:38:43 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 09:38:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpTlh-0007ff-Ql; Sun, 28 Jun 2020 09:38:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpTlg-0007fL-Lq for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 09:38:32 +0000 X-Inumbo-ID: 1d7c9d14-b923-11ea-845a-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1d7c9d14-b923-11ea-845a-12813bfff9fa; Sun, 28 Jun 2020 09:38:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ka+Of0laYzeH62TfxDc6mADB5Rf+d8ZlIdv7wlxNOEY=; b=WarlliHIDgQ209xKn+hW8fRJh SU/4doXNOSQh97B9sEG3jyY+8DsABMsw6Jq+5ziG6l5L3yIdNW/tSn1c5e2p3LQ3TfzXqVTVOGcU1 Fw44s6vbDS4KuWtu7/QN8fysek9BJ/5J/iQbZr+ytrCPkWT1yEAgL8dlwYjWjlZobGY+s=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpTlZ-0002MK-B8; Sun, 28 Jun 2020 09:38:25 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpTlZ-0006Rg-04; Sun, 28 Jun 2020 09:38:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpTlY-0007a0-VL; Sun, 28 Jun 2020 09:38:24 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151410: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-amd64-examine:memdisk-try-append:fail:regression linux-linus:test-armhf-armhf-libvirt:xen-boot:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=42afe7d1c6ef77212250af3459e549d1a944cc8a X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Sun, 28 Jun 2020 09:38:24 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151410 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151410/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 151214 test-armhf-armhf-libvirt 7 xen-boot fail REGR. vs. 151214 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 42afe7d1c6ef77212250af3459e549d1a944cc8a baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 10 days Failing since 151236 2020-06-19 19:10:35 Z 8 days 9 attempts Testing same since 151410 2020-06-27 20:39:04 Z 0 days 1 attempts ------------------------------------------------------------ 410 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt fail test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 19252 lines long.) From xen-devel-bounces@lists.xenproject.org Sun Jun 28 10:16:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 10:16:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpULp-0002Wf-Tu; Sun, 28 Jun 2020 10:15:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpULo-0002WZ-7B for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 10:15:52 +0000 X-Inumbo-ID: 57e0b846-b928-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 57e0b846-b928-11ea-bca7-bc764e2007e4; Sun, 28 Jun 2020 10:15:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oIJsDNDRnNkJXzrWVLMXS1L8SqJ0WMrdrc2ScV5WADg=; b=6BOuBLuacgrkG6g2xanP40UFy kh65EdltjP3y2aE/bpb5a2Tu+UjA1NFScMpn+eNG/Avj1ZVk47pd+X0ZRDekpxD34RqIDlu1zx+Te bVULgx4JOcHkjIv1vGQZgKyWdtEmWUIAGcWSexzRz8aM2rHXgs9e6J6L/jHIZ2eYWuwHU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpULm-00037e-RC; Sun, 28 Jun 2020 10:15:50 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpULm-000894-ER; Sun, 28 Jun 2020 10:15:50 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpULm-00072z-Dh; Sun, 28 Jun 2020 10:15:50 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-coverity test] 151428: all pass - PUSHED X-Osstest-Versions-This: xen=88cfd062e8318dfeb67c7d2eb50b6cd224b0738a X-Osstest-Versions-That: xen=fde76f895d0aa817a1207d844d793239c6639bc6 From: osstest service owner Date: Sun, 28 Jun 2020 10:15:50 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151428 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/151428/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a baseline version: xen fde76f895d0aa817a1207d844d793239c6639bc6 Last test of basis 151271 2020-06-21 09:18:26 Z 7 days Testing same since 151428 2020-06-28 09:23:57 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Grzegorz Uriasz Ian Jackson Jan Beulich Jason Andryuk Tim Deegan Wei Liu jobs: coverity-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git fde76f895d..88cfd062e8 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a -> coverity-tested/smoke From xen-devel-bounces@lists.xenproject.org Sun Jun 28 12:29:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 12:29:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpWQZ-0004bx-3i; Sun, 28 Jun 2020 12:28:55 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpWQX-0004bs-BF for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 12:28:53 +0000 X-Inumbo-ID: ea2e8162-b93a-11ea-8480-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ea2e8162-b93a-11ea-8480-12813bfff9fa; Sun, 28 Jun 2020 12:28:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Message-Id:Subject:To:Sender: Reply-To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2mzrHwzfIqLHUs5p9uQq4HMGy/BAqBHVbe1YXe4W038=; b=VvsaKS6GeT8YgC6QBWn3AcjYWb Of36xFAV5GR2V2S65j1Q2RuxFsl5sKzfTYbEdUUSsoBSFeHUHO7NT5u8Ty/3v7tKTTFhRmQQNaNYo btS5QbgYpwJEa0GDWNIvit0Bvqi3m70606qVKHMdLZ9YYA3FgcFsTF8eOPGRoXd2rdCY=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpWQQ-0005Vg-Nc; Sun, 28 Jun 2020 12:28:46 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpWQQ-0005nU-ER; Sun, 28 Jun 2020 12:28:46 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpWQQ-0007Vh-Dn; Sun, 28 Jun 2020 12:28:46 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Subject: [qemu-mainline bisection] complete test-amd64-i386-qemuu-rhel6hvm-intel Message-Id: From: osstest service owner Date: Sun, 28 Jun 2020 12:28:46 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" branch xen-unstable xenbranch xen-unstable job test-amd64-i386-qemuu-rhel6hvm-intel testid redhat-install Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 81cb05732efb36971901c515b007869cc1d3a532 Bug not present: d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/151431/ commit 81cb05732efb36971901c515b007869cc1d3a532 Author: Markus Armbruster Date: Tue Jun 9 14:23:37 2020 +0200 qdev: Assert devices are plugged into a bus that can take them This would have caught some of the bugs I just fixed. Signed-off-by: Markus Armbruster Reviewed-by: Mark Cave-Ayland Message-Id: <20200609122339.937862-23-armbru@redhat.com> For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Running cs-bisection-step --graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install --summary-out=tmp/151431.bisection-summary --basis-template=151065 --blessings=real,real-bisect qemu-mainline test-amd64-i386-qemuu-rhel6hvm-intel redhat-install Searching for failure / basis pass: 151399 fail [host=chardonnay0] / 151149 [host=huxelrebe0] 151101 [host=albana1] 151065 [host=albana0] 151047 [host=huxelrebe1] 150970 [host=huxelrebe0] 150930 [host=elbling0] 150916 [host=elbling1] 150909 [host=italia0] 150895 [host=fiano0] 150831 [host=fiano1] 150694 ok. Failure / basis pass flights: 151399 / 150694 (tree with no url: minios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://git.qemu.org/qemu.git Tree: seabios git://xenbits.xen.org/osstest/seabios.git Tree: xen git://xenbits.xen.org/xen.git Latest c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a4a2258a1fec66665481b0bd929b049921cb07a0 3c659044118e34603161457db9934a34f816d78b 553cf5d7c47bee05a3dec9461c1f8430316d516b d11c75185276ded944f2ea0277532b7fee849bbc fde76f895d0aa817a1207d844d793239c6639bc6 Basis pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bb78cfbec07eda45118b630a09b0af549b43a135 3c659044118e34603161457db9934a34f816d78b 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 Generating revisions with ./adhoc-revtuple-generator git://xenbits.xen.org/linux-pvops.git#c3038e718a19fc596f7b1baba0f83d5146dc7784-c3038e718a19fc596f7b1baba0f83d5146dc7784 git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/osstest/ovmf.git#bb78cfbec07eda45118b630a09b0af549b43a135-a4a2258a1fec66665481b0bd929b049921cb07a0 git://xenbits.xen.org/qemu-xen-traditional.git#3c659044118e34603161457db99\ 34a34f816d78b-3c659044118e34603161457db9934a34f816d78b git://git.qemu.org/qemu.git#66234fee9c2d37bfbc523aa8d0ae5300a14cc10e-553cf5d7c47bee05a3dec9461c1f8430316d516b git://xenbits.xen.org/osstest/seabios.git#2e3de6253422112ae43e608661ba94ea6b345694-d11c75185276ded944f2ea0277532b7fee849bbc git://xenbits.xen.org/xen.git#1497e78068421d83956f8e82fb6e1bf1fc3b1199-fde76f895d0aa817a1207d844d793239c6639bc6 Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Use of uninitialized value $parents in array dereference at ./adhoc-revtuple-generator line 465. Use of uninitialized value in concatenation (.) or string at ./adhoc-revtuple-generator line 465. Loaded 55319 nodes in revision graph Searching for test results: 150694 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bb78cfbec07eda45118b630a09b0af549b43a135 3c659044118e34603161457db9934a34f816d78b 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 150831 [host=fiano1] 150909 [host=italia0] 150930 [host=elbling0] 150916 [host=elbling1] 150895 [host=fiano0] 150899 [] 150970 [host=huxelrebe0] 151047 [host=huxelrebe1] 151101 [host=albana1] 151065 [host=albana0] 151149 [host=huxelrebe0] 151221 fail irrelevant 151175 fail irrelevant 151241 fail irrelevant 151286 fail irrelevant 151269 fail irrelevant 151328 fail irrelevant 151304 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 322969adf1fb3d6cfbd613f35121315715aff2ed 3c659044118e34603161457db9934a34f816d78b 171199f56f5f9bdf1e5d670d09ef1351d8f01bae 2e3de6253422112ae43e608661ba94ea6b345694 fde76f895d0aa817a1207d844d793239c6639bc6 151371 fail irrelevant 151369 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bb78cfbec07eda45118b630a09b0af549b43a135 3c659044118e34603161457db9934a34f816d78b 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151374 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 239b50a863704f7960525799eda82de061c7c458 3c659044118e34603161457db9934a34f816d78b 3f429a3400822141651486193d6af625eeab05a5 2e3de6253422112ae43e608661ba94ea6b345694 71ca0e0ad000e690899936327eb09709ab182ade 151373 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 239b50a863704f7960525799eda82de061c7c458 3c659044118e34603161457db9934a34f816d78b eefe34ea4b82c2b47abe28af4cc7247d51553626 2e3de6253422112ae43e608661ba94ea6b345694 25636ed707cf1211ce846c7ec58f8643e435d7a7 151377 fail irrelevant 151353 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 1a992030522622c42aa063788b3276789c56c1e1 3c659044118e34603161457db9934a34f816d78b d4b78317b7cf8c0c635b70086503813f79ff21ec 2e3de6253422112ae43e608661ba94ea6b345694 fde76f895d0aa817a1207d844d793239c6639bc6 151375 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 1a992030522622c42aa063788b3276789c56c1e1 3c659044118e34603161457db9934a34f816d78b d4b78317b7cf8c0c635b70086503813f79ff21ec 2e3de6253422112ae43e608661ba94ea6b345694 fde76f895d0aa817a1207d844d793239c6639bc6 151378 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 58ae92a993687d913aa6dd00ef3497a1bc5f6c40 3c659044118e34603161457db9934a34f816d78b 54cdfe511219b8051046be55a6e156c4f08ff7ff 2e3de6253422112ae43e608661ba94ea6b345694 71ca0e0ad000e690899936327eb09709ab182ade 151379 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a2433243fbe471c250d7eddc2c7da325d91265fd 3c659044118e34603161457db9934a34f816d78b 6675a653d2e57ab09c32c0ea7b44a1d6c40a7f58 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151430 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151409 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 9354eaaf16fdb98651574f131ff66ad974e50bba 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151383 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 53550e81e2cafe7c03a39526b95cd21b5194d9b1 2e3de6253422112ae43e608661ba94ea6b345694 3625b04991b4d6affadd99d377ab84bac48dfff4 151411 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 75a6ed875ff0a2eb6b2971ae2098ed09963d7329 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151384 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 250bc43a406f7d46e319abe87c19548d4f027828 2e3de6253422112ae43e608661ba94ea6b345694 3371ced37ced359167b5a71abee2062854371323 151399 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a4a2258a1fec66665481b0bd929b049921cb07a0 3c659044118e34603161457db9934a34f816d78b 553cf5d7c47bee05a3dec9461c1f8430316d516b d11c75185276ded944f2ea0277532b7fee849bbc fde76f895d0aa817a1207d844d793239c6639bc6 151431 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151412 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 589b1be07c060e583d9f758ff0cb10e0f1ff242f 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151386 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 3ee4f6cb360a877d171f2f9bb76b0d46d2cfa985 3c659044118e34603161457db9934a34f816d78b 9f1f264edbdf5516d6f208497310b3eedbc7b74c 2e3de6253422112ae43e608661ba94ea6b345694 2995d0afdf2d3fb44d07eada088db3613741db1e 151389 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 e1d24410da356731da70b3334f86343e11e207d2 3c659044118e34603161457db9934a34f816d78b 470dd165d152ff7ceac61c7b71c2b89220b3aad7 2e3de6253422112ae43e608661ba94ea6b345694 6a49b9a7920c82015381740905582b666160d955 151390 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 567bc4b4ae8a975791382dd30ac413bc0d3ce88c 3c659044118e34603161457db9934a34f816d78b eea8f5df4ecc607d64f091b8d916fcc11a697541 2e3de6253422112ae43e608661ba94ea6b345694 2995d0afdf2d3fb44d07eada088db3613741db1e 151413 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bb78cfbec07eda45118b630a09b0af549b43a135 3c659044118e34603161457db9934a34f816d78b 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151391 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 3c659044118e34603161457db9934a34f816d78b 86e8c353f705f14f2f2fd7a6195cefa431aa24d9 2e3de6253422112ae43e608661ba94ea6b345694 058023b343d4e366864831db46e9b438e9e3a178 151392 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 567bc4b4ae8a975791382dd30ac413bc0d3ce88c 3c659044118e34603161457db9934a34f816d78b 3575b0aea983ad57804c9af739ed8ff7bc168393 2e3de6253422112ae43e608661ba94ea6b345694 b91825f628c9a62cf2a3a0d972ea81484a8b7fce 151393 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 3c659044118e34603161457db9934a34f816d78b 49ee11555262a256afec592dfed7c5902d5eefd2 2e3de6253422112ae43e608661ba94ea6b345694 726c78d14dfe6ec76f5e4c7756821a91f0a04b34 151395 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae 3c659044118e34603161457db9934a34f816d78b 175198ad91d8bac540159705873b4ffe4fb94eab 2e3de6253422112ae43e608661ba94ea6b345694 51ca66c37371b10b378513af126646de22eddb17 151397 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8035edbe12f0f2a58e8fa9b06d05c8ee1c69ffae 3c659044118e34603161457db9934a34f816d78b b489f015fbe2bd59d409211f79ea0a8ac5d2a66d 2e3de6253422112ae43e608661ba94ea6b345694 780aba2779b834f19b2a6f0dcdea0e7e0b5e1622 151415 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a4a2258a1fec66665481b0bd929b049921cb07a0 3c659044118e34603161457db9934a34f816d78b 553cf5d7c47bee05a3dec9461c1f8430316d516b d11c75185276ded944f2ea0277532b7fee849bbc fde76f895d0aa817a1207d844d793239c6639bc6 151398 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bb78cfbec07eda45118b630a09b0af549b43a135 3c659044118e34603161457db9934a34f816d78b 66234fee9c2d37bfbc523aa8d0ae5300a14cc10e 2e3de6253422112ae43e608661ba94ea6b345694 1497e78068421d83956f8e82fb6e1bf1fc3b1199 151400 fail irrelevant 151403 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 6ff7c838d09224dd4e4c9b5b93152d8db1b19740 3c659044118e34603161457db9934a34f816d78b bab16ab33012cdae36246d2994b4a5ed9ac441f0 2e3de6253422112ae43e608661ba94ea6b345694 6a49b9a7920c82015381740905582b666160d955 151404 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 2fb1f7d29932db2908bdaad0f03c326e800d5e62 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151405 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 a4cfb842fca9693a330cb5435284c1ee8bfbbace 3c659044118e34603161457db9934a34f816d78b 23374a84c5f08e20ec2506a6322330d51f9134c5 2e3de6253422112ae43e608661ba94ea6b345694 2995d0afdf2d3fb44d07eada088db3613741db1e 151419 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151406 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b c23e05614e54e11f54961fbf086193ccb4cf8aa5 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151407 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151408 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b efa0559547e7e2c10dee16a78066176c1ea75e97 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151423 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151426 pass c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 151427 fail c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b 81cb05732efb36971901c515b007869cc1d3a532 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 Searching for interesting versions Result found: flight 150694 (pass), for basis pass Result found: flight 151399 (fail), for basis failure Repro found: flight 151413 (pass), for basis pass Repro found: flight 151415 (fail), for basis failure 0 revisions at c3038e718a19fc596f7b1baba0f83d5146dc7784 c530a75c1e6a472b0eb9558310b518f0dfcd8860 8927e2777786a43cddfaa328b0f4c41a09c629c9 3c659044118e34603161457db9934a34f816d78b d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a 2e3de6253422112ae43e608661ba94ea6b345694 1251402caf8685f45d9d580f01583370f7e2d272 No revisions left to test, checking graph state. Result found: flight 151419 (pass), for last pass Result found: flight 151423 (fail), for first failure Repro found: flight 151426 (pass), for last pass Repro found: flight 151427 (fail), for first failure Repro found: flight 151430 (pass), for last pass Repro found: flight 151431 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: qemuu git://git.qemu.org/qemu.git Bug introduced: 81cb05732efb36971901c515b007869cc1d3a532 Bug not present: d6b78ac8ecf94f56dbfbecc23fb4365d8772a41a Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/151431/ commit 81cb05732efb36971901c515b007869cc1d3a532 Author: Markus Armbruster Date: Tue Jun 9 14:23:37 2020 +0200 qdev: Assert devices are plugged into a bus that can take them This would have caught some of the bugs I just fixed. Signed-off-by: Markus Armbruster Reviewed-by: Mark Cave-Ayland Message-Id: <20200609122339.937862-23-armbru@redhat.com> dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.814795 to fit pnmtopng: 213 colors found Revision graph left in /home/logs/results/bisect/qemu-mainline/test-amd64-i386-qemuu-rhel6hvm-intel.redhat-install.{dot,ps,png,html,svg}. ---------------------------------------- 151431: tolerable ALL FAIL flight 151431 qemu-mainline real-bisect [real] http://logs.test-lab.xenproject.org/osstest/logs/151431/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail baseline untested jobs: test-amd64-i386-qemuu-rhel6hvm-intel fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary From xen-devel-bounces@lists.xenproject.org Sun Jun 28 15:08:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 15:08:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpYuX-0000dd-W6; Sun, 28 Jun 2020 15:08:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpYuW-0000dT-U5 for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 15:08:00 +0000 X-Inumbo-ID: 27d329e4-b951-11ea-849e-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 27d329e4-b951-11ea-849e-12813bfff9fa; Sun, 28 Jun 2020 15:08:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=o28ndcAH6BXWxEDb8ufz+ZTgRibXbiR9IczsfrMO4Bo=; b=fMKSShSd7cITloJgRwiOreYNJ q4sk7DJ146gVjLz+9gWs83nKmrjPOASQyM6/lGKiSjdMVysXvq9EuoACUUVuxYPOvUm6Fgj5ck0Qk 7sHACM07a3+y/QtySN00FTku2z3GTP8XDmzOZFl/p2kIJ3i471p79DM6gvV4PVyC8hFgM=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpYuV-0008Sv-F6; Sun, 28 Jun 2020 15:07:59 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpYuV-0004rB-5I; Sun, 28 Jun 2020 15:07:59 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpYuV-0007UV-4g; Sun, 28 Jun 2020 15:07:59 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151414: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=553cf5d7c47bee05a3dec9461c1f8430316d516b X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Sun, 28 Jun 2020 15:07:59 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151414 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151414/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: qemuu 553cf5d7c47bee05a3dec9461c1f8430316d516b baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 15 days Failing since 151101 2020-06-14 08:32:51 Z 14 days 13 attempts Testing same since 151399 2020-06-27 08:25:20 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Andrew Jones Ani Sinha Anthony PERARD Ard Biesheuvel Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Cleber Rosa Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé Daniele Buono David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Finn Thain Geoffrey McRae Gerd Hoffmann Greg Kurz Guenter Roeck Gustavo Romero Helge Deller Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jay Zhou Jean-Christophe Dubois Jiaxun Yang Jingqi Liu John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Liao Pingfang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marcelo Tosatti Marek Marczykowski-Górecki Mark Cave-Ayland Markus Armbruster Masahiro Yamada Max Filippov Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Raphael Norwitz Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Shameer Kolothum Stefan Berger Stefan Berger Stefan Hajnoczi Tao Xu Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 14163 lines long.) From xen-devel-bounces@lists.xenproject.org Sun Jun 28 16:47:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 16:47:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpaS5-0000mS-IZ; Sun, 28 Jun 2020 16:46:45 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpaS3-0000m8-W2 for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 16:46:44 +0000 X-Inumbo-ID: ef51d9b8-b95e-11ea-84ab-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id ef51d9b8-b95e-11ea-84ab-12813bfff9fa; Sun, 28 Jun 2020 16:46:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OVPtR+KiljdjTwl0aqpC8UNnr8b+rTGK7F8v9eEc+XU=; b=ry4ZpztT/p4apP7SIrPRW/T8V HGlHDbbRldZGdUksBoZcrCno+W12DKQj01SwAVzm2CgrJou58OZ10JW0GOEY7tGNiffAgzOMyrHOP 1AMbWTXAMLRcLCMVcMt9alnTq10jbzn8OT8vDLB7tw5qhWG0f/AqLgC02J6rYvJ1VONq0=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpaRx-0002Ii-LD; Sun, 28 Jun 2020 16:46:37 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpaRx-0001iS-6n; Sun, 28 Jun 2020 16:46:37 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpaRx-0003No-6D; Sun, 28 Jun 2020 16:46:37 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151417: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=d482cf6bef484e697f1dbb99f2504e7d67b149e7 X-Osstest-Versions-That: libvirt=f6f745297d884453ef4ed65643d267069f778517 From: osstest service owner Date: Sun, 28 Jun 2020 16:46:37 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151417 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151417/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151396 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151396 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt d482cf6bef484e697f1dbb99f2504e7d67b149e7 baseline version: libvirt f6f745297d884453ef4ed65643d267069f778517 Last test of basis 151396 2020-06-27 04:19:57 Z 1 days Testing same since 151417 2020-06-28 04:19:04 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Daniel Henrique Barboza jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git f6f745297d..d482cf6bef d482cf6bef484e697f1dbb99f2504e7d67b149e7 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Sun Jun 28 18:25:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 18:25:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpbys-0000O8-2K; Sun, 28 Jun 2020 18:24:42 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpbyq-0000Nh-T7 for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 18:24:40 +0000 X-Inumbo-ID: 9c90a304-b96c-11ea-84bb-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9c90a304-b96c-11ea-84bb-12813bfff9fa; Sun, 28 Jun 2020 18:24:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CSd+VxUtKkt/IqTz27/cGqddOd9rLbEduV+aDTL/Dcs=; b=th2knNZvWDIATcKX1VsVSeIaq wTNiVs62y03PhtTkSEx++rZevhf9yXzhfgfOW+9zb9/Egiuw5kyviVD8DJqvToSYmLdpUEYP2EsQA st/GnvJ3XFAtr6m2WgctzG9+sLUhTaoiJHI9A1M9Q9BE5frPHKiXiWaAF/zIGJyvG5C9Y=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpbyh-00047O-Kx; Sun, 28 Jun 2020 18:24:31 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpbyh-000549-DK; Sun, 28 Jun 2020 18:24:31 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpbyh-0000Oc-CK; Sun, 28 Jun 2020 18:24:31 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151416: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-examine:memdisk-try-append:fail:regression xen-unstable:test-armhf-armhf-xl-multivcpu:xen-boot:fail:heisenbug xen-unstable:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=88cfd062e8318dfeb67c7d2eb50b6cd224b0738a X-Osstest-Versions-That: xen=d3688bf60f798074bf38d712a3e15c88cfb81ed4 From: osstest service owner Date: Sun, 28 Jun 2020 18:24:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151416 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151416/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 151382 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-multivcpu 7 xen-boot fail pass in 151402 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 151402 like 151382 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 151402 never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 151402 never pass test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151382 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151382 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151382 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151382 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151382 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a baseline version: xen d3688bf60f798074bf38d712a3e15c88cfb81ed4 Last test of basis 151382 2020-06-26 15:39:39 Z 2 days Testing same since 151402 2020-06-27 10:19:44 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Grzegorz Uriasz Ian Jackson Jan Beulich Jason Andryuk Tim Deegan Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a Author: Andrew Cooper Date: Fri Jun 26 15:35:27 2020 +0100 changelog: Add notes about CET and Migration changes Signed-off-by: Andrew Cooper Acked-by: Jan Beulich Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant commit 92167e9430c010df410336f2b68cc4e30b7872d9 Author: Andrew Cooper Date: Mon Jun 8 18:47:58 2020 +0100 x86/livepatch: Make livepatching compatible with CET Shadow Stacks Just like the alternatives infrastructure, the livepatch infrastructure disables CR0.WP to perform patching, which is not permitted with CET active. Modify arch_livepatch_{quiesce,revive}() to disable CET before disabling WP, and reset the dirty bits on all virtual regions before re-enabling CET. One complication is that arch_livepatch_revive() has to fix up the top of the shadow stack. This depends on the functions not being inlined, even under LTO. Another limitation is that reset_virtual_region_perms() may shatter the final superpage of .text depending on alignment. This logic, and its downsides, are temporary until the patching infrastructure can be adjusted to not use CR0.WP. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Reviewed-by: Ross Lagerwall Release-acked-by: Paul Durrant commit bcdfbb70fca579baa04f212c0936b77919bdae11 Author: Andrew Cooper Date: Fri Jun 19 12:14:32 2020 +0100 x86/msr: Disallow access to Processor Trace MSRs We do not expose the feature to guests, so should disallow access to the respective MSRs. For simplicity, drop the entire block of MSRs, not just the subset which have been specified thus far. Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Jan Beulich Release-acked-by: Paul Durrant commit 40b532fbdcb2095da7152a1d08d9f0288524c223 Author: Jason Andryuk Date: Wed Jun 10 23:29:36 2020 -0400 vchan-socket-proxy: Handle closing shared input/output_fd input_fd & output_fd may be the same FD. In that case, mark both as -1 when closing one. That avoids a dangling FD reference. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit d20c0f1a7864a38b6c26d11d0e44467fba118625 Author: Jason Andryuk Date: Wed Jun 10 23:29:35 2020 -0400 vchan-socket-proxy: Cleanup resources on exit Close open FDs and close th vchan connection when exiting the program. This addresses some Coverity findings about leaking file descriptors. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 620225c48573396dc2394f59080a2d704a566c9d Author: Jason Andryuk Date: Wed Jun 10 23:29:34 2020 -0400 vchan-socket-proxy: Set closed FDs to -1 These FDs are closed, so set them to -1 so they are no longer valid. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit bfb310ee686bc36c9a8f9c15c42f97f96206cd29 Author: Jason Andryuk Date: Wed Jun 10 23:29:33 2020 -0400 vchan-socket-proxy: Switch data_loop() to take state Switch data_loop to take a pointer to vchan_proxy_state. No functional change. This removes a dead store to input_fd identified by Coverity. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit ace450ebdf120c081e02b40896dc719646708046 Author: Jason Andryuk Date: Wed Jun 10 23:29:32 2020 -0400 vchan-socket-proxy: Use a struct to store state Use a struct to group the vchan ctrl and FDs. This will facilite tracking the state of open and closed FDs and ctrl in data_loop(). Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 2b1a2188111ec3f39de1c6e6ff834e6894d1e05a Author: Jason Andryuk Date: Wed Jun 10 23:29:31 2020 -0400 vchan-socket-proxy: Unify main return value Introduce 'ret' for main's return value and remove direct returns. This is in preparation for a unified exit path with resource cleanup. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 20b65c15a38d98f31f212925a3e5a733dce5b477 Author: Jason Andryuk Date: Wed Jun 10 23:29:30 2020 -0400 vchan-socket-proxy: Check xs_watch return value Check the return value of xs_watch and error out on failure. This was found by Citrix's Coverity. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit fbdf181fe36516d74b77217207565e87511bf805 Author: Jason Andryuk Date: Wed Jun 10 23:29:29 2020 -0400 vchan-socket-proxy: Move perror() into connect_socket errno is reset by subsequent system & library calls, so it may be inaccurate by the time connect_socket returns. Call perror immediately after failing system calls to print the proper message. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 01b9a28e7d1dc54968d5081bdc089449052df939 Author: Jason Andryuk Date: Wed Jun 10 23:29:28 2020 -0400 vchan-socket-proxy: Move perror() into listen_socket The use of perror on the return from listen_socket can produce misleading results like: UNIX socket path "/tmp/aa....aa" too long (156 >= 108) listen socket: Success errno is reset by subsequent system & library calls, so it may be inaccurate by the time listen_socket returns. Call perror immediately after failing system calls to print the proper message. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit 2c8ac47d4e780389842f812bb6b2f95fa673add5 Author: Jason Andryuk Date: Wed Jun 10 23:29:27 2020 -0400 vchan-socket-proxy: Ensure UNIX path NUL terminated Check the socket path length to ensure sun_path is NUL terminated. This was spotted by Citrix's Coverity. Also use strcpy to avoid a warning "'__builtin_strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation]" flagged by gcc 10. Signed-off-by: Jason Andryuk Acked-by: Wei Liu Reviewed-by: Marek Marczykowski-Górecki Release-acked-by: Paul Durrant commit ed69c2ecaf3a6745b7c5a10cf2482e3c49cb8c4f Author: Grzegorz Uriasz Date: Sun Jun 14 16:17:08 2020 +0000 libxl: tooling expects wrong errno When iommu is not enabled for a given domain then pci passthrough hypercalls such as xc_test_assign_device return EOPNOTSUPP. The code responsible for this is in "iommu_do_domctl" inside xen/drivers/passthrough/iommu.c This patch fixes the error message reported by libxl when assigning pci devices to domains without iommu. Signed-off-by: Grzegorz Uriasz Tested-by: Grzegorz Uriasz Backport: 4.13 Acked-by: Ian Jackson Release-acked-by: Paul Durrant commit 3471cafbdda35eacf04670881dd2aee2558b4f08 Author: Tim Deegan Date: Fri Jun 26 10:40:44 2020 +0000 kdd: stop using [0] arrays to access packet contents GCC 10 is unhappy about this, and we already use 64k buffers in the only places where packets are allocated, so move the 64k size into the packet definition. Reported-by: Olaf Hering Signed-off-by: Tim Deegan Acked-by: Wei Liu Release-acked-by: Paul Durrant commit f91d103e74d4c2efa60fb42b6e9d530a92838f8e Author: Andrew Cooper Date: Wed Jun 10 12:40:04 2020 +0100 tools: fix error path of xendevicemodel_open() c/s 6902cb00e03 "tools/libxendevicemodel: extract functions and add a compat layer" introduced calls to both xencall_open() and osdep_xendevicemodel_open() but failed to fix up the error path. c/s f68c7c618a3 "libs/devicemodel: free xencall handle in error path in _open()" fixed up the xencall_open() aspect of the error path (missing the osdep_xendevicemodel_open() aspect), but positioned the xencall_close() incorrectly, creating the same pattern proved to be problematic by c/s 30a72f02870 "tools: fix error path of xenhypfs_open()". Reposition xtl_logger_destroy(), and introduce the missing osdep_xendevicemodel_close(). Fixes: 6902cb00e03 ("tools/libxendevicemodel: extract functions and add a compat layer") Fixes: f68c7c618a3 ("libs/devicemodel: free xencall handle in error path in _open()") Backport: 4.9+ Signed-off-by: Andrew Cooper Reviewed-by: Juergen Gross Release-acked-by: Paul Durrant Reviewed-by: Ian Jackson (qemu changes not included) From xen-devel-bounces@lists.xenproject.org Sun Jun 28 23:24:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 28 Jun 2020 23:24:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpgeL-0007OG-MP; Sun, 28 Jun 2020 23:23:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpgeK-0007Nw-Ia for xen-devel@lists.xenproject.org; Sun, 28 Jun 2020 23:23:48 +0000 X-Inumbo-ID: 67178df8-b996-11ea-84f7-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 67178df8-b996-11ea-84f7-12813bfff9fa; Sun, 28 Jun 2020 23:23:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iLuZ5o9XTj6KBeTxrNtbP4taYJLFLfHv8cNh/l66gAI=; b=6dy0eDiQs+5zMrMCTxVS+c5CM QkQf280oodPFFpH5k0npFvPbwBj5REtZlTF71p16kuHyYdimCTD2HxFEaKRqi40XnbW6B1EagPGsg vSrD6BAsggDHEYUFi927k5L9hPWoOvNc1QMSlk3bSxzSlq8kkK/VhfWg4PhQBMaRTYpAo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpgeC-0001Bh-L3; Sun, 28 Jun 2020 23:23:40 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpgeC-0002NE-C6; Sun, 28 Jun 2020 23:23:40 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpgeC-00008e-BP; Sun, 28 Jun 2020 23:23:40 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151429: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-armhf-armhf-xl-rtds:guest-start/debian.repeat:fail:allowable linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=719fdd32921fb7e3208db8832d32ae1c2d68900f X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Sun, 28 Jun 2020 23:23:40 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151429 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151429/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 719fdd32921fb7e3208db8832d32ae1c2d68900f baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 10 days Failing since 151236 2020-06-19 19:10:35 Z 9 days 10 attempts Testing same since 151429 2020-06-28 09:40:49 Z 0 days 1 attempts ------------------------------------------------------------ 424 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 19897 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 29 03:00:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 03:00:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpk1o-0001xw-6V; Mon, 29 Jun 2020 03:00:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpk1m-0001xq-IT for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 03:00:14 +0000 X-Inumbo-ID: a5820122-b9b4-11ea-bca7-bc764e2007e4 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.77]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a5820122-b9b4-11ea-bca7-bc764e2007e4; Mon, 29 Jun 2020 03:00:11 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aL8wxT8ULA7WFH5G8xcDuoZtllx95ZG8Oou7/uyLlz7QcdOC7lbr7W7V1ZP73APB3dvcmO6hnkfAUeJGPJbyY76CYHHkmyNMaREEdofUgQeQHhP+Us1mkLiOOSwpMHfjPfDi87TWoop0lZCa5ArAhGDevbh/tYjL1QNj/4HuthNinoNXoEh4DIeaoOc6ihKT5vWdroiB5S7Fjd5rupkSv9e8xR2Sts3c4zgpfClvxTjm9ky0hbveLMNoa0+6apM4C3JUZS14nj7vmuVBxxR2YsPDbWwDIuw/bHjMRZ+xGoGaU1+Ot+csSyXlo/wcB0PWAZZbEOBs3n3Gtfe30hu8Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cEkYM3WrGoh9CXGo+3w9YCuBPjOjwUC6rQ5FN+BYd+Q=; b=aqKrKDEyOEfrZou1eB6GvbcYHaUFHQBdaRnV8JcR08eIOh4h82jzISYZ1zAsor5P7TzitKfWzZrpZz3P7buieHZM+HnsLJF4oqYm3jkT1hg7F7VpI6dtA9IS1UmLtQHs4JGeaXtfHYItRDM7LzIzMF4i1Vd2brIfGqCdg//K+V7L8eBCyQWycbIarWouMR95rNdDd2mHojsToSsUSovB4YVCtJReqW0Xa03umPbNcVbwpQRwMfghG7ck4+2m9agBVcYx5zzl9d82FB3GK6C+VggygChY6DC2NK49/Zo0f6U2Zb5WapPiLGIT2U2s15cUYqb+CFNFTygvOp7uokgtWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cEkYM3WrGoh9CXGo+3w9YCuBPjOjwUC6rQ5FN+BYd+Q=; b=qmk4pcuEisqTd4+4+dH8ia2k/C7g9J8/LFQncpSN9+AZLiY4QhGQRjB7jSW9SfDx4QOJDHH4V9Ag7Q+1Di5BK6YnWPt9PSDUiq1GY4bYLa9SksOItQAdNHUwpHnV4Y2Pdsw/5cLz2900b4ef4bDRTmRseKO2dMm/udvcOt+dCU0= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2933.eurprd04.prod.outlook.com (2603:10a6:4:9c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.26; Mon, 29 Jun 2020 03:00:08 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 03:00:08 +0000 From: Peng Fan To: Stefano Stabellini , "Michael S. Tsirkin" Subject: RE: [PATCH] xen: introduce xen_vring_use_dma Thread-Topic: [PATCH] xen: introduce xen_vring_use_dma Thread-Index: AQHWSgTusARd8c8cRkWwDit233DtZajneYoAgACU6oCAAC7QAIAAEpoAgAAGSwCAAUK2gIAFVRgQ Date: Mon, 29 Jun 2020 03:00:08 +0000 Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 13ba3640-e9ad-4e19-0273-08d81bd88847 x-ms-traffictypediagnostic: DB6PR0402MB2933: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q15QAvPQSN0Timky4oDpoQS5EjdrqXyUR1t7gIHO5/lII+2gdPQVQdSXSXhZlqnIolxDskOU3zxxiut6WJYFzfMoEOWmyXxCCkrmkJUDu4RPemXo/DT+xmilbdL2bDtr1mK4zk0D+ZBfixO0e+3oi3FEGBWy6wIJdve3no6VbjcKt3xeaNgMSMcObV3TcVbe34A9rMQTAwW13OGg+pSU3bcOhcaP618ZDtTdibEE/WKv1LdNtyKkrxUQUHUIsQfbq/lap48+BOfN27XzbUlcDnoJtTg0OROcVqPHqy+KtiYaAlSAN578MUzdINBTKV/2DX/+wnQyYNL/yAU/SX7fAV1ESIK6Jd+4o+cK8hCyWeLJDGotGeePClJRbt7UXruSXxt+pRzoLXiKAhVsVNm+qw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(136003)(366004)(39860400002)(316002)(76116006)(966005)(52536014)(66476007)(54906003)(66946007)(6506007)(66446008)(64756008)(66556008)(7416002)(4326008)(186003)(26005)(7696005)(2906002)(33656002)(86362001)(110136005)(45080400002)(8676002)(83080400001)(8936002)(71200400001)(83380400001)(9686003)(478600001)(44832011)(55016002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rIh4hpyZRlq1oXv0Jp5uXtz/ZBRmR5fCy7P/DPCVKSUc/ZUSfpco3e197h5zPE5YrX0mUvrKaBvhrFyzRq+9kYsTkXIrfhrFiaxdUUMTeNk1AxnwEzDWrTwrDVUsqYfeb39VGV2HX6MlChnzz1Sfssl23UkXqLY4EpkUHniCtEbQqB+PbqHtC0h3po7KQdmlp8juiiCFoWhyEjahToeZhOejGxGZaMbO3PjO7gkzxgj2Vuv77kLSNTKpk8qtWRSdhboted7dHYzWMtS8oQEnkQM9QJn6kKvKlXDsVyn3kzuPDJnY/wQoNuT7r9jgj2GdeH6z+JZTztjeIrjiupnElYwagCedNMcPOXx2mTRYyv+coPNroPMnopkCFQwRGSIYdYz6BuuHHzVrl03FUD2loYS1doMczk0yWXrj+QCtwHItMAxJFbBQcPHSIS0IiLZDLGkEPYO8W9aGAfCSigmp+B+Ts5tbl3mtHZFDIytzrMb6UyVZ+IpG9Pt+WLI5COp6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB6PR0402MB2760.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13ba3640-e9ad-4e19-0273-08d81bd88847 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 03:00:08.4686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WFb8Yle0owm/sFCkI7lJMnCMp8RzUFPNAIHnY7sAQRRBmHrab9Fa7cCfi1CtCu1BSYp+Oj2wBJAQ58CduENUEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2933 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "linux-arm-kernel@lists.infradead.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma >=20 > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote: > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma APIs > > > > > > > to map the > > > > > > > ring: when xen_swiotlb is enabled the dma API is required. > > > > > > > When it is disabled, it is not required. > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to > > > > > translate foreign mappings (memory coming from other VMs) to > physical addresses. > > > > > On x86, it also uses dma_ops to translate Linux's idea of a > > > > > physical address into a real physical address (this is unneeded > > > > > on ARM.) > > > > > > > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be > used > > > > > on Xen/x86 always and on Xen/ARM if Linux is Dom0 (because it > > > > > has foreign > > > > > mappings.) That is why we have the if (xen_domain) return true; > > > > > in vring_use_dma_api. > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* forces > DMA > > > > ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > > > Unfortunately as a result Xen never got around to properly setting > > > > VIRTIO_F_IOMMU_PLATFORM. > > > > > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this > > > because the usage of swiotlb_xen is not a property of virtio, > > > > > > Basically any device without VIRTIO_F_ACCESS_PLATFORM (that is it's > > name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is what linux > > calls it) is declared as "special, don't follow normal rules for > > access". > > > > So yes swiotlb_xen is not a property of virtio, but what *is* a > > property of virtio is that it's not special, just a regular device from= DMA POV. >=20 > I am trying to understand what you meant but I think I am missing somethi= ng. >=20 > Are you saying that modern virtio should always have > VIRTIO_F_ACCESS_PLATFORM, hence use normal dma_ops as any other > devices? >=20 > If that is the case, how is it possible that virtio breaks on ARM using t= he > default dma_ops? The breakage is not Xen related (except that Xen turns > dma_ops on). The original message from Peng was: >=20 > vring_map_one_sg -> vring_use_dma_api > -> dma_map_page > -> __swiotlb_map_page > ->swiotlb_map_page > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > dev_addr)), size, dir); > However we are using per device dma area for rpmsg, phys_to_virt > could not return a correct virtual address for virtual address in > vmalloc area. Then kernel panic. >=20 > I must be missing something. Maybe it is because it has to do with RPMesg= ? I am not going to fix the rpmsg issue with this patch. It is when ARM DomU Android os communicate with secure world trusty os using virtio, the vring_use_dma_api will return true for xen domu, but I no need it return true and fall into swiotlb. Thanks, Peng. >=20 >=20 > > > > > You might have noticed that I missed one possible case above: > > > > > Xen/ARM DomU :-) > > > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even > > > > > initialized. So if > > > > > (xen_domain) return true; would give the wrong answer in that cas= e. > > > > > Linux would end up calling the "normal" dma_ops, not > > > > > swiotlb-xen, and the "normal" dma_ops fail. > > > > > > > > > > > > > > > The solution I suggested was to make the check in > > > > > vring_use_dma_api more flexible by returning true if the > > > > > swiotlb_xen is supposed to be used, not in general for all Xen > > > > > domains, because that is what the check was really meant to do. > > > > > > > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is > wrong with that? > > > > > > swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops are the > > > ones that are used. So you are saying, why don't we fix the default > > > dma_ops to work with virtio? > > > > > > It is bad that the default dma_ops crash with virtio, so yes I think > > > it would be good to fix that. However, even if we fixed that, the if > > > (xen_domain()) check in vring_use_dma_api is still a problem. > > > > Why is it a problem? It just makes virtio use DMA API. > > If that in turn works, problem solved. >=20 > You are correct in the sense that it would work. However I do think it is= wrong > for vring_use_dma_api to enable dma_ops/swiotlb-xen for Xen/ARM DomUs > that don't need it. There are many different types of Xen guests, Xen x86= is > drastically different from Xen ARM, it seems wrong to treat them the same > way. >=20 >=20 >=20 > Anyway, re-reading the last messages of the original thread [1], it looks= like > Peng had a clear idea on how to fix the general issue. Peng, what happene= d > with that? >=20 >=20 > [1] > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flore.= ke > rnel.org%2Fpatchwork%2Fpatch%2F1033801%2F%231222404&data=3D02 > %7C01%7Cpeng.fan%40nxp.com%7C27edb29c11da49a2249008d8192d98cc > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637287030912707 > 092&sdata=3DMsF%2FLmBmJ1V%2BoOQ%2FmdhEJ3PFzH55DaSNvorRUU > QvBvQ%3D&reserved=3D0 From xen-devel-bounces@lists.xenproject.org Mon Jun 29 03:05:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 03:05:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpk6l-00028w-Vl; Mon, 29 Jun 2020 03:05:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpk6l-00028r-4s for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 03:05:23 +0000 X-Inumbo-ID: 5e8f247e-b9b5-11ea-8513-12813bfff9fa Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.40]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5e8f247e-b9b5-11ea-8513-12813bfff9fa; Mon, 29 Jun 2020 03:05:22 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CAju7QkmIqavZdt5fklpB5P8nx32l78YlYIUjuOtva1cpgRWFgTx4Ru70tRBAicVzVXZPc2F3PcBqW9rC/5310CaXgcmAPDGmv2BRUlqHUkFMA4W+zuCVnNmG9gOYgZNzVDHp4qCK7VodlQR/gqSJEQzxlmAY77b7imi6upMjSOyJhVGHEvW996UPW17tqtne41xo3R9a1pFuDpeDJxXOIwPDSpEqkJzcDP4ipwWVJuAEoeVVD8IpUyucoKWyVwmRCZlnMXE6qpL6RjOwQHx+55csMaopEsSdEcd/fmxAljoPHQ58Wqm8BlV7C9fpuBbBu6SO38Q8ayr7zC3/btcWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jHC9agWnkRQL6YKDpHO0raw87xRJpkm4NgZPrmUrEjE=; b=GB8WYhZ1G56lWETW7Bp9s/Qi65suSemhiFFHKe376kCVD26VqQcUZE7Vvl1Z12seUUeoZgcAKzo1HjJ9ZvLQRPmkvNjl2U+/c1PD+6DrSkL4NaSvdQqCBC5nVgKk/3BHMH8/Uq71qKHdVdSwMOcCKpNAaPamAFl9PWxVY2VePTmWhHK70scIN+5PYFdA6VmmhWgobaC6gVAFP3EuMjbhXfC+RihePSaIH80vjpdabl4FOQUDnIlerdBQgMI6yNoJz/tDp9DvpOVG1aa7Zww3I/CP3qGpGBlywTTnOB7Xj7YMMSRGfiibcchdKaNz1JK0SHU1Td1PVDa8jZm65rVIxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jHC9agWnkRQL6YKDpHO0raw87xRJpkm4NgZPrmUrEjE=; b=XlugPnNkJ7QMVLOGY9QfTZ8l8uYrqd0CuDpPnN9SlEgfaBvquN0xSzT8uZy0cAwMudIzb5JvraBK8unIUiU8+pWvNk4+k/35KQ3A7P31SeWD2MYiDBtM29tOpyNHR8lMEvM8gWaA7AZ4D8HTY3pcBiHYKsNddOArp/pGMuS7OB8= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB6PR0402MB2933.eurprd04.prod.outlook.com (2603:10a6:4:9c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.26; Mon, 29 Jun 2020 03:05:20 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 03:05:20 +0000 From: Peng Fan To: "Michael S. Tsirkin" , Stefano Stabellini Subject: RE: [PATCH] xen: introduce xen_vring_use_dma Thread-Topic: [PATCH] xen: introduce xen_vring_use_dma Thread-Index: AQHWSgTusARd8c8cRkWwDit233DtZajneYoAgACU6oCAAC7QAIAAEpoAgAAGSwCAAUK2gIABcSaAgAPk6cA= Date: Mon, 29 Jun 2020 03:05:19 +0000 Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> In-Reply-To: <20200626110629-mutt-send-email-mst@kernel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e4627fe8-c273-417e-dc11-08d81bd941eb x-ms-traffictypediagnostic: DB6PR0402MB2933: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SGLlBJ14DOlZsO6cfOCwf1VwZjcXlSn7QXMS4gPARB17nMzg0E5w2eRe9Z5KG9LDR9pwq1m2CDbrEZyFtFjhgMcxzxDOcxTKD6JOuKVrHre4M5Ix+ujQlnDKvPIY6m2SfW5i9/oakGWUqVULHs8JLoZL15ppxgEAo/SR3mdLV2XgiOuVIgtqjmpyu2k9f6nPI/7ZtoBqtei5NwZaN9UnHS26pqeMT5IF7J7H5zhft49TfP2AgLAFUBn4iPUoiGzoNVaXG8FMFVM6Pv2NVRGd6FBnbNdSEgCH5WKI3bGSBtfa1nbsQNYJ3e0oI8JQFoW1T/0ekjEyd+X3Zk2zKgVA8CK34ssxf7cylRFNYhsvb1eXWMVc1vU4bf6F2vbFcH3+DZjvjEkAyIgCV1EXl+kr0A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(136003)(366004)(39860400002)(316002)(76116006)(966005)(52536014)(66476007)(54906003)(66946007)(6506007)(66446008)(64756008)(66556008)(7416002)(4326008)(186003)(26005)(7696005)(2906002)(33656002)(86362001)(110136005)(45080400002)(8676002)(83080400001)(8936002)(71200400001)(83380400001)(9686003)(478600001)(44832011)(55016002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AdrLq00p9SnFdn6T/UB84F0UuMDuKcDqX4wVbG0TzQE8iWa+quN1yYAYEDv2D61QYzfQaZM8lfCXCMwfzCLYyclkxLPIjg/dBWy5rZ4sglHOslW2BiHkmxtmGwFFnXAH4ytrGciqeRzqMrq5kwDS/wxOZRyhyZs28xIG5n1gUzfMeaSpyeRDY9IPKCyYPKg7rQYkx89BR13d1/pQCpy/uY4UXSsei9UC9YHhOMobAubSyCI9UCDa3smpR3YCfI+1aBhrseq7V+F6wVXJNRW/GfhMF/a9m6ToLnk46JdtFkughy4gDfBz/hklRMk+3GlHGCmX360//eo/XzSiENCVs9WOlxfzpNcbNyXCfmuGFygOOuNdcQWIcmlf+jmJKld9juBuamXEsmPy2yYPiD+HgbRe9Vnl+WZBBs4/ijwdXmKlWe4iGOp+JyBxmV33IxAB8XTbsf+83L9JkExegBIdaqb92nc6/972SlbuzmMfEitNF98Ja/5FrGxaGxhgiMBG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB6PR0402MB2760.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e4627fe8-c273-417e-dc11-08d81bd941eb X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 03:05:19.9955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nLUWl126tEwvqG2M6AzqcPSNNQzGMUhXUv+d03nNwH160kKxQNe6leKCutFo96Ko2NSt//fglX7CwaAU/BU6Eg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0402MB2933 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "linux-arm-kernel@lists.infradead.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma >=20 > On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote: > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrot= e: > > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma > > > > > > > > APIs to map the > > > > > > > > ring: when xen_swiotlb is enabled the dma API is required. > > > > > > > > When it is disabled, it is not required. > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for > this? > > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to > > > > > > translate foreign mappings (memory coming from other VMs) to > physical addresses. > > > > > > On x86, it also uses dma_ops to translate Linux's idea of a > > > > > > physical address into a real physical address (this is > > > > > > unneeded on ARM.) > > > > > > > > > > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be > > > > > > used on Xen/x86 always and on Xen/ARM if Linux is Dom0 > > > > > > (because it has foreign > > > > > > mappings.) That is why we have the if (xen_domain) return > > > > > > true; in vring_use_dma_api. > > > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* forces > > > > > DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > > > > > Unfortunately as a result Xen never got around to properly > > > > > setting VIRTIO_F_IOMMU_PLATFORM. > > > > > > > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this > > > > because the usage of swiotlb_xen is not a property of virtio, > > > > > > > > > Basically any device without VIRTIO_F_ACCESS_PLATFORM (that is it's > > > name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is what linux > > > calls it) is declared as "special, don't follow normal rules for > > > access". > > > > > > So yes swiotlb_xen is not a property of virtio, but what *is* a > > > property of virtio is that it's not special, just a regular device fr= om DMA > POV. > > > > I am trying to understand what you meant but I think I am missing > > something. > > > > Are you saying that modern virtio should always have > > VIRTIO_F_ACCESS_PLATFORM, hence use normal dma_ops as any other > devices? >=20 > I am saying it's a safe default. Clear VIRTIO_F_ACCESS_PLATFORM if you ha= ve > some special needs e.g. you are very sure it's ok to bypass DMA ops, or y= ou > need to support a legacy guest (produced in the window between virtio 1 > support in 2014 and support for VIRTIO_F_ACCESS_PLATFORM in 2016). >=20 >=20 > > If that is the case, how is it possible that virtio breaks on ARM > > using the default dma_ops? The breakage is not Xen related (except > > that Xen turns dma_ops on). The original message from Peng was: > > > > vring_map_one_sg -> vring_use_dma_api > > -> dma_map_page > > -> __swiotlb_map_page > > ->swiotlb_map_page > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > dev_addr)), size, dir); > > However we are using per device dma area for rpmsg, phys_to_virt > > could not return a correct virtual address for virtual address in > > vmalloc area. Then kernel panic. > > > > I must be missing something. Maybe it is because it has to do with RPMe= sg? >=20 > I think it's an RPMesg bug, yes rpmsg bug is another issue, it should not use dma_alloc_coherent for reserv= ed area, and use vmalloc_to_page. Anyway here using dma api will also trigger issue. >=20 > > > > > > > > You might have noticed that I missed one possible case above: > > > > > > Xen/ARM DomU :-) > > > > > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even > > > > > > initialized. So if > > > > > > (xen_domain) return true; would give the wrong answer in that c= ase. > > > > > > Linux would end up calling the "normal" dma_ops, not > > > > > > swiotlb-xen, and the "normal" dma_ops fail. > > > > > > > > > > > > > > > > > > The solution I suggested was to make the check in > > > > > > vring_use_dma_api more flexible by returning true if the > > > > > > swiotlb_xen is supposed to be used, not in general for all Xen > > > > > > domains, because that is what the check was really meant to do. > > > > > > > > > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is > wrong with that? > > > > > > > > swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops are > > > > the ones that are used. So you are saying, why don't we fix the > > > > default dma_ops to work with virtio? > > > > > > > > It is bad that the default dma_ops crash with virtio, so yes I > > > > think it would be good to fix that. However, even if we fixed > > > > that, the if > > > > (xen_domain()) check in vring_use_dma_api is still a problem. > > > > > > Why is it a problem? It just makes virtio use DMA API. > > > If that in turn works, problem solved. > > > > You are correct in the sense that it would work. However I do think it > > is wrong for vring_use_dma_api to enable dma_ops/swiotlb-xen for > > Xen/ARM DomUs that don't need it. There are many different types of > > Xen guests, Xen x86 is drastically different from Xen ARM, it seems > > wrong to treat them the same way. >=20 > I could imagine some future Xen hosts setting a flag somewhere in the > platform capability saying "no xen specific flag, rely on > "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU. > How about that? >=20 Michael, Stefano, So what's your suggestion here, that we could avoid similar issue for virtio drivers in ARM DomU? Thanks, Peng. >=20 > > > > > > Anyway, re-reading the last messages of the original thread [1], it > > looks like Peng had a clear idea on how to fix the general issue. > > Peng, what happened with that? We shrinked the rpmsg reserved area to workaround the issue. So still use the dma apis in rpmsg. But here I am going to address domu android trusty issue using virtio. > > > > > > [1] > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flor= e > > .kernel.org%2Fpatchwork%2Fpatch%2F1033801%2F%231222404&dat > a=3D02%7C0 > > > 1%7Cpeng.fan%40nxp.com%7C08ba48d3b3d54e775a8108d819e62fd0%7C68 > 6ea1d3bc > > > 2b4c6fa92cd99c5c301635%7C0%7C0%7C637287823721994475&sdata > =3DCw4FHWrH > > uVKBCn3%2BKS2VM7cWuGoTI6R7SHJrJSLY5Io%3D&reserved=3D0 From xen-devel-bounces@lists.xenproject.org Mon Jun 29 03:46:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 03:46:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpkkO-0005Ni-4y; Mon, 29 Jun 2020 03:46:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpkkM-0005N8-Fr for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 03:46:18 +0000 X-Inumbo-ID: 116cbe12-b9bb-11ea-8518-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 116cbe12-b9bb-11ea-8518-12813bfff9fa; Mon, 29 Jun 2020 03:46:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NleAp2cGNQcGqWDNEZpLYWdVkQDz0VQOx1EYmpfLM5Q=; b=6Q/e+3svX9f9ZONZf4xgh04CW 35DLnCo7e16DxvIFb3xaUCz2curJShL1/hr6L8SAuMxFw4lfgjga6nBZHN/zJvttpBx+M7d82uYmi U4iguM9sMFMd23fX4yTRngQT7a+minsAYrJ/J5P1jgkre2Qfddem6aLOT6NFzo4hswthE=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpkkC-0000OF-Ow; Mon, 29 Jun 2020 03:46:08 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpkkC-0007ed-Hs; Mon, 29 Jun 2020 03:46:08 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpkkC-0000uV-H3; Mon, 29 Jun 2020 03:46:08 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151435: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-arm64-arm64-xl-seattle:xen-boot:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-xl-rtds:guest-start.2:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=e7651153a8801dad6805d450ea8bef9b46c1adf5 X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Mon, 29 Jun 2020 03:46:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151435 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151435/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-arm64-arm64-xl-seattle 7 xen-boot fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 17 guest-start.2 fail blocked in 151065 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: qemuu e7651153a8801dad6805d450ea8bef9b46c1adf5 baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 16 days Failing since 151101 2020-06-14 08:32:51 Z 14 days 14 attempts Testing same since 151435 2020-06-28 15:39:59 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ahmed Karaman Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Andrew Jones Ani Sinha Anthony PERARD Ard Biesheuvel Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Cleber Rosa Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé Daniele Buono David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Finn Thain Geoffrey McRae Gerd Hoffmann Greg Kurz Guenter Roeck Gustavo Romero Helge Deller Huacai Chen Huacai Chen Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jay Zhou Jean-Christophe Dubois Jiaxun Yang Jingqi Liu John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Liao Pingfang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marcelo Tosatti Marek Marczykowski-Górecki Mark Cave-Ayland Markus Armbruster Masahiro Yamada Max Filippov Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Raphael Norwitz Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Shameer Kolothum Stefan Berger Stefan Berger Stefan Hajnoczi Tao Xu Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds fail test-arm64-arm64-xl-seattle fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 14356 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 29 05:17:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 05:17:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpmAY-0004hY-6u; Mon, 29 Jun 2020 05:17:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpmAW-0004hT-5j for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 05:17:24 +0000 X-Inumbo-ID: cfed52a0-b9c7-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id cfed52a0-b9c7-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 05:17:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 326E3AD76; Mon, 29 Jun 2020 05:17:22 +0000 (UTC) Subject: Re: [PATCH fsgsbase v2 4/4] x86/fsgsbase: Fix Xen PV support To: Andy Lutomirski , x86@kernel.org References: From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <714d4c04-5907-885f-e23b-baef662f1080@suse.com> Date: Mon, 29 Jun 2020 07:17:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Sasha Levin , Stefano Stabellini , Andrew Cooper , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Boris Ostrovsky Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.20 19:24, Andy Lutomirski wrote: > On Xen PV, SWAPGS doesn't work. Teach __rdfsbase_inactive() and > __wrgsbase_inactive() to use rdmsrl()/wrmsrl() on Xen PV. The Xen > pvop code will understand this and issue the correct hypercalls. > > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: Stefano Stabellini > Cc: xen-devel@lists.xenproject.org > Signed-off-by: Andy Lutomirski > --- > arch/x86/kernel/process_64.c | 20 ++++++++++++++------ > 1 file changed, 14 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c > index cb8e37d3acaa..457d02aa10d8 100644 > --- a/arch/x86/kernel/process_64.c > +++ b/arch/x86/kernel/process_64.c > @@ -163,9 +163,13 @@ static noinstr unsigned long __rdgsbase_inactive(void) > > lockdep_assert_irqs_disabled(); > > - native_swapgs(); > - gsbase = rdgsbase(); > - native_swapgs(); > + if (!static_cpu_has(X86_FEATURE_XENPV)) { > + native_swapgs(); > + gsbase = rdgsbase(); > + native_swapgs(); > + } else { > + rdmsrl(MSR_KERNEL_GS_BASE, gsbase); > + } > > return gsbase; > } > @@ -182,9 +186,13 @@ static noinstr void __wrgsbase_inactive(unsigned long gsbase) > { > lockdep_assert_irqs_disabled(); > > - native_swapgs(); > - wrgsbase(gsbase); > - native_swapgs(); > + if (!static_cpu_has(X86_FEATURE_XENPV)) { > + native_swapgs(); > + wrgsbase(gsbase); > + native_swapgs(); > + } else { > + wrmsrl(MSR_KERNEL_GS_BASE, gsbase); > + } > } > > /* > Another possibility would be to just do (I'm fine either way): diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c index acc49fa6a097..b78dd373adbf 100644 --- a/arch/x86/xen/enlighten_pv.c +++ b/arch/x86/xen/enlighten_pv.c @@ -318,6 +318,8 @@ static void __init xen_init_capabilities(void) setup_clear_cpu_cap(X86_FEATURE_XSAVE); setup_clear_cpu_cap(X86_FEATURE_OSXSAVE); } + + setup_clear_cpu_cap(X86_FEATURE_FSGSBASE); } static void xen_set_debugreg(int reg, unsigned long val) Juergen From xen-devel-bounces@lists.xenproject.org Mon Jun 29 06:22:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 06:22:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnB4-0001qo-9h; Mon, 29 Jun 2020 06:22:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnB2-0001qj-NE for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 06:22:00 +0000 X-Inumbo-ID: d60cb50a-b9d0-11ea-8496-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [205.139.110.61]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id d60cb50a-b9d0-11ea-8496-bc764e2007e4; Mon, 29 Jun 2020 06:21:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593411718; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CH00j3xLGgY5MCOHoqIWuWnauDKW7cEZeJtWO3pCrfs=; b=GoWxgzxC7ls5HNIMuUKoFJIxG4LSomud0qNsflYKfJYFEN/+gAYnZ5nji6GBYy83DAm6A2 qjymKMEPhmfZ9/hWEVaDLPcVYcqwD8t2NjiBESjlzqqTyLb7TWXOPxQSxulE3RXXpnU80a rocYJmHFRHnCnBfV00Hp+w6LuBFCuc0= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-468-wCiyD2LBPAKZSL09-8w2uA-1; Mon, 29 Jun 2020 02:21:55 -0400 X-MC-Unique: wCiyD2LBPAKZSL09-8w2uA-1 Received: by mail-wr1-f72.google.com with SMTP id i10so16078420wrn.21 for ; Sun, 28 Jun 2020 23:21:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CH00j3xLGgY5MCOHoqIWuWnauDKW7cEZeJtWO3pCrfs=; b=eLFqwwFURRz31blDH0++/KwtZwcGx2QMNZ7KRWEB3x0lKd6reT292+jtw3IYY7a8+u kfUIjqqq6x1TjcA7qnikX/B+Ri9dE9fTexoD0GOz1tEhDPzGLuyYlFbvvyiaRPRMLRAC 2JAvjTpILqLGQmWWStuHfyUQuVzMloquo8MRKDaSH8g0/wvuCm+WzVY9NuK//XRUzSyR y2dv/g3beloZSHU17YJ6c0WuOo9yCPEKyxEs08jdevAWpO00qb97g6Mg1dhAejcmKgFs Mr31DBNoAzV9/ua/J3FL1qsR6BPJoCuxPCB70GKKRoAMePZNIWc+UGZ9y78gaflSBPFx OgRA== X-Gm-Message-State: AOAM533CIQbS6+28HRQrO9LHchYkFfz8jq3uZ+Ufzg2RtoqYcqY/XEkp XvjRyuYMj0QIUlYwoAwDnnRSfy4PKcDNRQBSwPMCuUKAeMkZS20AmkIdSnhWcpsO3TUsxzbBpcO s9EFX5Rmo8xsWyodg7l5D7BNrVlU= X-Received: by 2002:a1c:2842:: with SMTP id o63mr213023wmo.169.1593411713730; Sun, 28 Jun 2020 23:21:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzKYcxmqMsT/1ldFS1WC1gydKg7IfQlagc8Qi0Jdy4z5P71txG/ryJ4wq5phGebg35mwOxHnw== X-Received: by 2002:a1c:2842:: with SMTP id o63mr213007wmo.169.1593411713418; Sun, 28 Jun 2020 23:21:53 -0700 (PDT) Received: from redhat.com (bzq-79-182-31-92.red.bezeqint.net. [79.182.31.92]) by smtp.gmail.com with ESMTPSA id k126sm22276200wme.17.2020.06.28.23.21.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jun 2020 23:21:52 -0700 (PDT) Date: Mon, 29 Jun 2020 02:21:48 -0400 From: "Michael S. Tsirkin" To: Peng Fan Subject: Re: [PATCH] xen: introduce xen_vring_use_dma Message-ID: <20200629022124-mutt-send-email-mst@kernel.org> References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , Stefano Stabellini , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "linux-arm-kernel@lists.infradead.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 29, 2020 at 03:05:19AM +0000, Peng Fan wrote: > > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma > > > > On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote: > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote: > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma > > > > > > > > > APIs to map the > > > > > > > > > ring: when xen_swiotlb is enabled the dma API is required. > > > > > > > > > When it is disabled, it is not required. > > > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for > > this? > > > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > > > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to > > > > > > > translate foreign mappings (memory coming from other VMs) to > > physical addresses. > > > > > > > On x86, it also uses dma_ops to translate Linux's idea of a > > > > > > > physical address into a real physical address (this is > > > > > > > unneeded on ARM.) > > > > > > > > > > > > > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be > > > > > > > used on Xen/x86 always and on Xen/ARM if Linux is Dom0 > > > > > > > (because it has foreign > > > > > > > mappings.) That is why we have the if (xen_domain) return > > > > > > > true; in vring_use_dma_api. > > > > > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* forces > > > > > > DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > > > > > > > Unfortunately as a result Xen never got around to properly > > > > > > setting VIRTIO_F_IOMMU_PLATFORM. > > > > > > > > > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this > > > > > because the usage of swiotlb_xen is not a property of virtio, > > > > > > > > > > > > Basically any device without VIRTIO_F_ACCESS_PLATFORM (that is it's > > > > name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is what linux > > > > calls it) is declared as "special, don't follow normal rules for > > > > access". > > > > > > > > So yes swiotlb_xen is not a property of virtio, but what *is* a > > > > property of virtio is that it's not special, just a regular device from DMA > > POV. > > > > > > I am trying to understand what you meant but I think I am missing > > > something. > > > > > > Are you saying that modern virtio should always have > > > VIRTIO_F_ACCESS_PLATFORM, hence use normal dma_ops as any other > > devices? > > > > I am saying it's a safe default. Clear VIRTIO_F_ACCESS_PLATFORM if you have > > some special needs e.g. you are very sure it's ok to bypass DMA ops, or you > > need to support a legacy guest (produced in the window between virtio 1 > > support in 2014 and support for VIRTIO_F_ACCESS_PLATFORM in 2016). > > > > > > > If that is the case, how is it possible that virtio breaks on ARM > > > using the default dma_ops? The breakage is not Xen related (except > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. > > > > > > > > > > > > > You might have noticed that I missed one possible case above: > > > > > > > Xen/ARM DomU :-) > > > > > > > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even > > > > > > > initialized. So if > > > > > > > (xen_domain) return true; would give the wrong answer in that case. > > > > > > > Linux would end up calling the "normal" dma_ops, not > > > > > > > swiotlb-xen, and the "normal" dma_ops fail. > > > > > > > > > > > > > > > > > > > > > The solution I suggested was to make the check in > > > > > > > vring_use_dma_api more flexible by returning true if the > > > > > > > swiotlb_xen is supposed to be used, not in general for all Xen > > > > > > > domains, because that is what the check was really meant to do. > > > > > > > > > > > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is > > wrong with that? > > > > > > > > > > swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops are > > > > > the ones that are used. So you are saying, why don't we fix the > > > > > default dma_ops to work with virtio? > > > > > > > > > > It is bad that the default dma_ops crash with virtio, so yes I > > > > > think it would be good to fix that. However, even if we fixed > > > > > that, the if > > > > > (xen_domain()) check in vring_use_dma_api is still a problem. > > > > > > > > Why is it a problem? It just makes virtio use DMA API. > > > > If that in turn works, problem solved. > > > > > > You are correct in the sense that it would work. However I do think it > > > is wrong for vring_use_dma_api to enable dma_ops/swiotlb-xen for > > > Xen/ARM DomUs that don't need it. There are many different types of > > > Xen guests, Xen x86 is drastically different from Xen ARM, it seems > > > wrong to treat them the same way. > > > > I could imagine some future Xen hosts setting a flag somewhere in the > > platform capability saying "no xen specific flag, rely on > > "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU. > > How about that? > > > > Michael, Stefano, > > So what's your suggestion here, that we could avoid similar issue > for virtio drivers in ARM DomU? > > Thanks, > Peng. > > > > > > > > > > > > Anyway, re-reading the last messages of the original thread [1], it > > > looks like Peng had a clear idea on how to fix the general issue. > > > Peng, what happened with that? > > We shrinked the rpmsg reserved area to workaround the issue. > So still use the dma apis in rpmsg. > > But here I am going to address domu android trusty issue using > virtio. My suggestion is to first of all fix DMA API so it works properly. > > > > > > > > > [1] > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > > .kernel.org%2Fpatchwork%2Fpatch%2F1033801%2F%231222404&dat > > a=02%7C0 > > > > > 1%7Cpeng.fan%40nxp.com%7C08ba48d3b3d54e775a8108d819e62fd0%7C68 > > 6ea1d3bc > > > > > 2b4c6fa92cd99c5c301635%7C0%7C0%7C637287823721994475&sdata > > =Cw4FHWrH > > > uVKBCn3%2BKS2VM7cWuGoTI6R7SHJrJSLY5Io%3D&reserved=0 From xen-devel-bounces@lists.xenproject.org Mon Jun 29 06:25:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 06:25:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnEh-0001zP-Ps; Mon, 29 Jun 2020 06:25:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnEf-0001zK-NY for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 06:25:45 +0000 X-Inumbo-ID: 5bf9e8e0-b9d1-11ea-852e-12813bfff9fa Received: from EUR02-AM5-obe.outbound.protection.outlook.com (unknown [40.107.0.41]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5bf9e8e0-b9d1-11ea-852e-12813bfff9fa; Mon, 29 Jun 2020 06:25:43 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ffb0tryf3+WMusuxriFspTuyCD0jR5nujp/rzdzc6JR92rJsWlAVE8I313MSQBTprU4nobwvSXgu8vR4rC/9MeFgvPh//pXnseXz3XbJJeHjIQvsLIahqtiVa8KEaN9fHGnvZSy0Qr2bIC0t8RsRIlKBpkSTaXkMpmqT4lBXcrwyiy3yRA56Fu5tl5PlYR3gujgCm468frMy1aWF1CvKp2yVN54FRB03txEI8SJjwDXXSKDDSXjfCX+wrBVk/Q/ZEKZ4SrwGQolzsfMcR1OnB2Har2Lpfb/Ija4WBx086MLPPMNYBJ7IIQGt86NYaNEcT872f7hEX+HmJhFpUXIotg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZVinsJJnviT21i7XI0KnA6+56MrUkVoRCxqh0lP/y9s=; b=hhaBE5XukKYUuZPClQoZo29++2XadgB3N0uZbP+RCVP7EAwcu+hbgCHnj3aXOesCe+pkNU7XRSV8Ou/voG/N+htBPj3/yP+oH2Yaopp9jCu5sfSbGNirApS0dBqcGjopmO6lqSmhxcAPk4la3xmEWlDpfcoKaVM1sIcSBLhitZ8EooVWcd8K5aJ2K7WUjGESlCyvEBgwabFwCl32r9iD+JQ8DLt6kQGyiRPbQcvFmL+M9zrsuF4/j0tG2aVNLogbhNBb8oQA1iD08zMf505DtilMBXEcq6hEj/dCBKYAiRfxkVVUkn/3qlyRE8tn5V0wigeEriicm7ltAw0eBkVfLw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZVinsJJnviT21i7XI0KnA6+56MrUkVoRCxqh0lP/y9s=; b=L1zcjV0CGehZeD7cB6ZqeDkIn8Wkfl30zMXdjW2xafn6zwlvwrzgTksmnOEBJzLvcWyZ6S5jRwc2qF+4dQcok7dMBsqvuQZeQcu1Nq4ClyFRoPBTAzyYPCluwfjmtoQeVQDqjbDH5VaFL36TLFhMmuaD6uecdAr6PLacwaycXQs= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB8PR04MB6715.eurprd04.prod.outlook.com (2603:10a6:10:10d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Mon, 29 Jun 2020 06:25:41 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 06:25:41 +0000 From: Peng Fan To: "Michael S. Tsirkin" Subject: RE: [PATCH] xen: introduce xen_vring_use_dma Thread-Topic: [PATCH] xen: introduce xen_vring_use_dma Thread-Index: AQHWSgTusARd8c8cRkWwDit233DtZajneYoAgACU6oCAAC7QAIAAEpoAgAAGSwCAAUK2gIABcSaAgAPk6cCAADgrAIAAAH5w Date: Mon, 29 Jun 2020 06:25:41 +0000 Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> <20200629022124-mutt-send-email-mst@kernel.org> In-Reply-To: <20200629022124-mutt-send-email-mst@kernel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a5e1c4cb-0c5f-447d-9984-08d81bf53f1b x-ms-traffictypediagnostic: DB8PR04MB6715: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZcomgzT8z0TV8AdfcgQXBFI1wdcxYJJGw2fCPEYYV2HF5Asq2udSyAxCqG2x424rMSoSB19NYDH2/cltuOnvwJewUKeUap9q6OxMr5rpTs8qTvM0LWCCHaMxslX2x5Kw4P7LsAUS1MV7Kq4NCH8IeoHXVqZKXLZibUu8OQX77pe7RD8Uehe92lYOxg0IIjmPTpaHPU0xUSv/747T7V1t3n1n48YZVipEAlJ36w5LfLqcdQ+tM+iQSH4ToueQp8TeBuAY6VX0Q58g6J0FYF2UT9WNDIgd/mcTxuqk9BIhCZLzlEi3VhJVXiwxs91dLexhPfI0y1+TDhStDySFnLh6ldmQZIVSnILpem5NP3bMP+iYGcSEJHYXGraspfUuTcmgpiGqfDQUzCt4h/o1602WSQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(346002)(376002)(396003)(366004)(6916009)(186003)(86362001)(9686003)(76116006)(66446008)(45080400002)(7696005)(55016002)(5660300002)(66946007)(26005)(83380400001)(71200400001)(66476007)(66556008)(64756008)(33656002)(7416002)(52536014)(4326008)(6506007)(54906003)(478600001)(44832011)(8676002)(316002)(966005)(8936002)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yAnM0ejSbejlrSnR31b9U9qBdkL0+lYs1XiRprTYLdv0aTF4h/fK7BMlL9j5/Efdh2jIQq3P9IpIsXCvMJ2nZp+QjeRsYQm1Vi/g0bWtsGrlC3mbi/7RplbNGBRgqLxfttNrsnazacGBy45PpLP3jDu0ITIVyZpFgmxR9zw17h9ODKv0sZaBHTyCbDQFt089cdMTCluY+rur3KLU5ty7nI5NdQGto4tY2Dm2oF8USaJ6t4OF7YAV14XQTV+CudulV3zH9eqWt3wcc/hymm1fdv8dvk37aNah9MbPftxJ3VGKSXDRLYm9jStQZqeUX2riVQHl8UGnTJ7DGJf7NAr7RPRjlBJvG7/F8Ty57bgrPoIR6Ll9jJIp+nvIt8VTBbHf0wF8y6qy/ahygmI8ZyXSTe1b1nScNRKRQcKU08ce8oglUa3Zte1r/wHFyA33zb/H9JbBjaOotRYHXU476nK0MAbxPyhdWD/HfkU3sQuzjtH5XhTNtJJYQGeDjUZzm5OK Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB6PR0402MB2760.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5e1c4cb-0c5f-447d-9984-08d81bf53f1b X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 06:25:41.1516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jlca2JAB/hh8X/P93HXsVW0tsA8+sgSQYIkgLQ2VlEVRDYpq8IaCerlyTe74kscdoLfBrQC2fq3z4lL2GPh/QQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR04MB6715 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , Stefano Stabellini , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "linux-arm-kernel@lists.infradead.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma >=20 > On Mon, Jun 29, 2020 at 03:05:19AM +0000, Peng Fan wrote: > > > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma > > > > > > On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote: > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrot= e: > > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini > wrote: > > > > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma > > > > > > > > > > APIs to map the > > > > > > > > > > ring: when xen_swiotlb is enabled the dma API is requir= ed. > > > > > > > > > > When it is disabled, it is not required. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for > > > this? > > > > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > > > > > > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to > > > > > > > > translate foreign mappings (memory coming from other VMs) > > > > > > > > to > > > physical addresses. > > > > > > > > On x86, it also uses dma_ops to translate Linux's idea of > > > > > > > > a physical address into a real physical address (this is > > > > > > > > unneeded on ARM.) > > > > > > > > > > > > > > > > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should > > > > > > > > be used on Xen/x86 always and on Xen/ARM if Linux is Dom0 > > > > > > > > (because it has foreign > > > > > > > > mappings.) That is why we have the if (xen_domain) return > > > > > > > > true; in vring_use_dma_api. > > > > > > > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > > > > > > > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > > > > > > > > > Unfortunately as a result Xen never got around to properly > > > > > > > setting VIRTIO_F_IOMMU_PLATFORM. > > > > > > > > > > > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for > > > > > > this because the usage of swiotlb_xen is not a property of > > > > > > virtio, > > > > > > > > > > > > > > > Basically any device without VIRTIO_F_ACCESS_PLATFORM (that is > > > > > it's name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is what > > > > > linux calls it) is declared as "special, don't follow normal > > > > > rules for access". > > > > > > > > > > So yes swiotlb_xen is not a property of virtio, but what *is* a > > > > > property of virtio is that it's not special, just a regular > > > > > device from DMA > > > POV. > > > > > > > > I am trying to understand what you meant but I think I am missing > > > > something. > > > > > > > > Are you saying that modern virtio should always have > > > > VIRTIO_F_ACCESS_PLATFORM, hence use normal dma_ops as any other > > > devices? > > > > > > I am saying it's a safe default. Clear VIRTIO_F_ACCESS_PLATFORM if > > > you have some special needs e.g. you are very sure it's ok to bypass > > > DMA ops, or you need to support a legacy guest (produced in the > > > window between virtio 1 support in 2014 and support for > VIRTIO_F_ACCESS_PLATFORM in 2016). > > > > > > > > > > If that is the case, how is it possible that virtio breaks on ARM > > > > using the default dma_ops? The breakage is not Xen related (except > > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > > > vring_map_one_sg -> vring_use_dma_api > > > > -> dma_map_page > > > > -> __swiotlb_map_page > > > > ->swiotlb_map_page > > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > > dev_addr)), size, dir); > > > > However we are using per device dma area for rpmsg, phys_to_virt > > > > could not return a correct virtual address for virtual address in > > > > vmalloc area. Then kernel panic. > > > > > > > > I must be missing something. Maybe it is because it has to do with > RPMesg? > > > > > > I think it's an RPMesg bug, yes > > > > rpmsg bug is another issue, it should not use dma_alloc_coherent for > > reserved area, and use vmalloc_to_page. > > > > Anyway here using dma api will also trigger issue. > > > > > > > > > > > > > > > > > You might have noticed that I missed one possible case abov= e: > > > > > > > > Xen/ARM DomU :-) > > > > > > > > > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even > > > > > > > > initialized. So if > > > > > > > > (xen_domain) return true; would give the wrong answer in th= at > case. > > > > > > > > Linux would end up calling the "normal" dma_ops, not > > > > > > > > swiotlb-xen, and the "normal" dma_ops fail. > > > > > > > > > > > > > > > > > > > > > > > > The solution I suggested was to make the check in > > > > > > > > vring_use_dma_api more flexible by returning true if the > > > > > > > > swiotlb_xen is supposed to be used, not in general for all > > > > > > > > Xen domains, because that is what the check was really mean= t to > do. > > > > > > > > > > > > > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? > What > > > > > > > is > > > wrong with that? > > > > > > > > > > > > swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops > > > > > > are the ones that are used. So you are saying, why don't we > > > > > > fix the default dma_ops to work with virtio? > > > > > > > > > > > > It is bad that the default dma_ops crash with virtio, so yes I > > > > > > think it would be good to fix that. However, even if we fixed > > > > > > that, the if > > > > > > (xen_domain()) check in vring_use_dma_api is still a problem. > > > > > > > > > > Why is it a problem? It just makes virtio use DMA API. > > > > > If that in turn works, problem solved. > > > > > > > > You are correct in the sense that it would work. However I do > > > > think it is wrong for vring_use_dma_api to enable > > > > dma_ops/swiotlb-xen for Xen/ARM DomUs that don't need it. There > > > > are many different types of Xen guests, Xen x86 is drastically > > > > different from Xen ARM, it seems wrong to treat them the same way. > > > > > > I could imagine some future Xen hosts setting a flag somewhere in > > > the platform capability saying "no xen specific flag, rely on > > > "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU. > > > How about that? > > > > > > > Michael, Stefano, > > > > So what's your suggestion here, that we could avoid similar issue for > > virtio drivers in ARM DomU? > > > > Thanks, > > Peng. > > > > > > > > > > > > > > > > > Anyway, re-reading the last messages of the original thread [1], > > > > it looks like Peng had a clear idea on how to fix the general issue= . > > > > Peng, what happened with that? > > > > We shrinked the rpmsg reserved area to workaround the issue. > > So still use the dma apis in rpmsg. > > > > But here I am going to address domu android trusty issue using virtio. >=20 > My suggestion is to first of all fix DMA API so it works properly. Could you please elaborate more details? You mean the DMA API usage of rpmsg? Or xen domu dma_ops? Thanks, Peng.=20 >=20 > > > > > > > > > > > > [1] > > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= F > > > > lore > > > > .kernel.org%2Fpatchwork%2Fpatch%2F1033801%2F%231222404& > dat > > > a=3D02%7C0 > > > > > > > > 1%7Cpeng.fan%40nxp.com%7C08ba48d3b3d54e775a8108d819e62fd0%7C68 > > > 6ea1d3bc > > > > > > > > 2b4c6fa92cd99c5c301635%7C0%7C0%7C637287823721994475&sdata > > > =3DCw4FHWrH > > > > uVKBCn3%2BKS2VM7cWuGoTI6R7SHJrJSLY5Io%3D&reserved=3D0 From xen-devel-bounces@lists.xenproject.org Mon Jun 29 06:26:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 06:26:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnF5-00021u-5l; Mon, 29 Jun 2020 06:26:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnF3-00021g-Mi for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 06:26:09 +0000 X-Inumbo-ID: 6aca24e8-b9d1-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6aca24e8-b9d1-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 06:26:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gvUw/HgM4gdXb//Vy9tmxy0UiLi2IUZoBajYtS0FbZ8=; b=fFfTLHE1Fra1GwD7ap95gYthe f9doMxB2J2OsF44aoiFad7sbWco7Tc9VvmMcXGzlgP7r39fT/b6f0G8Y4oX+aZmzo0ZC70Ty70mKL /9qxx8ag9O8wBCek8zZf0DQdpcWRKdAFqjQtJ+IEr1xylzxjI5+mOv9qFE4bDFDr9vq/c=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnF1-0003sX-Ax; Mon, 29 Jun 2020 06:26:07 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpnF1-0005Mu-0a; Mon, 29 Jun 2020 06:26:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpnF0-0003Mi-WE; Mon, 29 Jun 2020 06:26:06 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151437: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=88cfd062e8318dfeb67c7d2eb50b6cd224b0738a X-Osstest-Versions-That: xen=d3688bf60f798074bf38d712a3e15c88cfb81ed4 From: osstest service owner Date: Mon, 29 Jun 2020 06:26:06 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151437 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151437/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151382 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151382 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151382 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151382 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151382 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151382 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a baseline version: xen d3688bf60f798074bf38d712a3e15c88cfb81ed4 Last test of basis 151382 2020-06-26 15:39:39 Z 2 days Testing same since 151402 2020-06-27 10:19:44 Z 1 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Grzegorz Uriasz Ian Jackson Jan Beulich Jason Andryuk Tim Deegan Wei Liu jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git d3688bf60f..88cfd062e8 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a -> master From xen-devel-bounces@lists.xenproject.org Mon Jun 29 06:33:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 06:33:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnMW-00032L-6n; Mon, 29 Jun 2020 06:33:52 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnMU-00032C-NW for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 06:33:50 +0000 X-Inumbo-ID: 7da499da-b9d2-11ea-852f-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 7da499da-b9d2-11ea-852f-12813bfff9fa; Mon, 29 Jun 2020 06:33:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593412428; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Iiom3LNVi9ET0XgfPNiU1I3DflByt3ZNInrS8hmdp2U=; b=RvTva7yvWQJRqvtjLrnc/EM+idCCJEHhG9hgfioileljWjAEPy856c65mhWJCfuOmXs9e9 OGXr2wScFqvevQWvWrrh5xDvzlgKdMnIO/IQPEkBgNn2g9yq2yG8tMvII9ABOJLEUQn9jv HbblSDoldsoqs73nUBpU7Aoazs5mAQE= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-467-b50L4kajPHCmY-RS_aIIJw-1; Mon, 29 Jun 2020 02:33:44 -0400 X-MC-Unique: b50L4kajPHCmY-RS_aIIJw-1 Received: by mail-wr1-f72.google.com with SMTP id o12so16037048wrj.23 for ; Sun, 28 Jun 2020 23:33:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Iiom3LNVi9ET0XgfPNiU1I3DflByt3ZNInrS8hmdp2U=; b=th7vwagxDxtzj7KAAM2SX7uduko0h6/SzmOzhmvhj3I4XyMNwtCc7Ts/eV+gFs+Ix4 HLHol4FFjCDaTeyEk2IcdOdzo81jserP+y6Cqi8ptjTP5K8L1jPTu/R2oZ6Krqz7tkcp RfWXtInIjFVedooW6/EAny9U+SlCS32u2Depq6s+T1oqYjVFUnqDiWQ3aX4FGkUF43cP PWAGtWCDcpVuKRJXcR2QpgppO72ySdfMnxkPRLHXiQIuPU8EvosWkJvvj5tYo2M01T+N UKPQnPda1a7tzdVeBL4ol+2+Os8mLIKWZD2ZcYqhg/DF9KTDwngIkbkcgEfmp6SqD4HG V+wQ== X-Gm-Message-State: AOAM533hH59x9BDMP9YzS/777sbRHQW7jMcHamZloZHBknk331N5mW66 jkPWM3y9RUuy2A/gYIqdqgVxMxzd0r54Hb+hevjoPiTCaMOWeNork9YPf9Vds7QnVosI1bNBR9c lq0h8s4XjAbxQcVbc6b/o2SfdxBc= X-Received: by 2002:adf:8067:: with SMTP id 94mr14821908wrk.427.1593412423678; Sun, 28 Jun 2020 23:33:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxfYJ1M6jIB+Bt9+iuqmCS+1/JuHYbah8AxWL9RwY6izIKRHTcVkotYUsuHjo+DZqHXAwCswQ== X-Received: by 2002:adf:8067:: with SMTP id 94mr14821888wrk.427.1593412423531; Sun, 28 Jun 2020 23:33:43 -0700 (PDT) Received: from redhat.com (bzq-79-182-31-92.red.bezeqint.net. [79.182.31.92]) by smtp.gmail.com with ESMTPSA id s8sm41059111wru.38.2020.06.28.23.33.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jun 2020 23:33:42 -0700 (PDT) Date: Mon, 29 Jun 2020 02:33:39 -0400 From: "Michael S. Tsirkin" To: Peng Fan Subject: Re: [PATCH] xen: introduce xen_vring_use_dma Message-ID: <20200629023225-mutt-send-email-mst@kernel.org> References: <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> <20200629022124-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , Stefano Stabellini , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "linux-arm-kernel@lists.infradead.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 29, 2020 at 06:25:41AM +0000, Peng Fan wrote: > > > > > Anyway, re-reading the last messages of the original thread [1], > > > > > it looks like Peng had a clear idea on how to fix the general issue. > > > > > Peng, what happened with that? > > > > > > We shrinked the rpmsg reserved area to workaround the issue. > > > So still use the dma apis in rpmsg. > > > > > > But here I am going to address domu android trusty issue using virtio. > > > > My suggestion is to first of all fix DMA API so it works properly. > > Could you please elaborate more details? > > You mean the DMA API usage of rpmsg? Or xen domu dma_ops? > > Thanks, > Peng. Not 100% sure but I think xen dma ops. -- MST From xen-devel-bounces@lists.xenproject.org Mon Jun 29 06:35:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 06:35:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnOT-0003KV-5L; Mon, 29 Jun 2020 06:35:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnOS-0003KQ-DK for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 06:35:52 +0000 X-Inumbo-ID: c5b9871c-b9d2-11ea-852f-12813bfff9fa Received: from EUR04-VI1-obe.outbound.protection.outlook.com (unknown [40.107.8.43]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id c5b9871c-b9d2-11ea-852f-12813bfff9fa; Mon, 29 Jun 2020 06:35:50 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gzr/k4oCbcvEW7AiZGYcqOtnZAuZ87sdUvtk2U1+45np+2XqI2wkn+fFSSxJpPvBzvIfY95CTvIOq74St4++o8KZSmmblZNTye/HXpATwTRNThRGDatoR7ljUseNIFLWjftAAYrgrzzhTocZ/TiG3sCYqAeB1r2A0QBTr/A1BuQsislJYxR8T/fhQB79nJpgE5K96HOZEwU801Bn2jlsjNAYE4K+uG3LRDRjpBayLVgvveyp4ZZSzCLH0nB8khiVoZOn2Ld67ikv6ce9mfoHwXG40rdyS7MF+wCGem4kduqbS3hMeLpWkcEFDTQUvYhDSTh8Df04Ob2TLaJwJ8gtaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jt9aKkcohM+VBBAMcQ1zSn0OzkcLoXfaQdNHqrsc8go=; b=I19SIRA9E+ml4KlImtDM2f6dT2GjHOpm/8bQAdGCULUf7DUSebu1q6C/JEQQ0ZoD5czHKgShajRH6E8quwskYdXQrzJfn+BWOHsgk/ylOAEslvjCLUXnqiYfrr31rvAWJsumKBYEoB53GLwvctI0j8ms0CZg5nttGNUPix2ZLACLyf8/jdtFuC95JbVqXotqdhbEoV0cgmf+v07H7UuHofCgk1ft3b8hZnXEyEeIUp23T10ZYTN/LgLHpL7WsN/+yuJc5e+M2O/sjq6bnvSKohrrNhgmA8xyXA7NlZAZkvgt3wCT/sr95qbheSpOaRlE434mT7ymF9kj/VMpYltmvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jt9aKkcohM+VBBAMcQ1zSn0OzkcLoXfaQdNHqrsc8go=; b=AmBn7Z1Vgx95lJz5b3JxDQb7dpR0/wYgFEuq3Qzew0A79iEejI01TsVFHzD149IWXAhzENJq8qJnyaImapEQolKWf0QRGEawwdDBkZNk1rzw+FT+BwyKqToGmCXB7v+rtFqIIzKTJNTMt9LLg+JmWqc28jUbdUiyQym7kw7s8VU= Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com (2603:10a6:4:a1::14) by DB7PR04MB4764.eurprd04.prod.outlook.com (2603:10a6:10:15::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Mon, 29 Jun 2020 06:35:48 +0000 Received: from DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701]) by DB6PR0402MB2760.eurprd04.prod.outlook.com ([fe80::2d36:b569:17c:7701%4]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 06:35:48 +0000 From: Peng Fan To: "Michael S. Tsirkin" Subject: RE: [PATCH] xen: introduce xen_vring_use_dma Thread-Topic: [PATCH] xen: introduce xen_vring_use_dma Thread-Index: AQHWSgTusARd8c8cRkWwDit233DtZajneYoAgACU6oCAAC7QAIAAEpoAgAAGSwCAAUK2gIABcSaAgAPk6cCAADgrAIAAAH5wgAAC0YCAAABHUA== Date: Mon, 29 Jun 2020 06:35:48 +0000 Message-ID: References: <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> <20200629022124-mutt-send-email-mst@kernel.org> <20200629023225-mutt-send-email-mst@kernel.org> In-Reply-To: <20200629023225-mutt-send-email-mst@kernel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e07dc2d3-9155-49ce-2410-08d81bf6a91d x-ms-traffictypediagnostic: DB7PR04MB4764: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fK08amyxZaUi4JckED6/kpeUqMMw5buBVlalapbUcm+JSQK4QI84PEPgIYnkjkipS0xD9ABwB8ZcXtU/h/Y1OsDKtAVt4k4y7yMsyjn1Oa5BSHHepcIY7m4GIwnbEVNJJuthC4iVCMt+doQZU+ZAh26iGubJ/DeuGuOOXyNv4oM6PLJurQOiHffS1g7sdTacZiTsr+zppsy1C/3VBuisiyRVGG4KfeS0ux+2g8v3UsA7a2J/kgVZnBPHi2P5+10HIdKRjvpPPZ6yxmJFe43F3T3WeOuT1xkhR6Zi6ivDSCaAWVO+op7BLHTy95nrWHskMjgKfYQDmudAalEtAL7cIA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0402MB2760.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(346002)(376002)(136003)(39860400002)(66946007)(8936002)(8676002)(7416002)(9686003)(83380400001)(86362001)(44832011)(26005)(64756008)(2906002)(66556008)(6916009)(4326008)(66476007)(6506007)(66446008)(186003)(76116006)(4744005)(71200400001)(5660300002)(33656002)(478600001)(55016002)(316002)(7696005)(52536014)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 63k2owGulhusPRazW46hh/2a+efDxnw5Ak9iGbwd161buaq9mmMSZvvaGZMS87V5f2GDrg3WF4Oh7JXqPRgBE5SUGQmUoXnhTBOO19GPSMYZt+Lrlj0OpzO0Jql3BMWWSQplbol/Q+Z80+e4LL7EIQWzIhSBfPZjbEjV39ucPFLEIFEwTFsCsyK+6WFjKMeIrepcXL+MG+tAEIdcaugN7F9Y6LGblmbsvcCe/CTmqDsMDIq57bI+0chNC+fJQj24C3V+DPYtwKLJHwkrD0Wc90v8IQhcMJg4hjUp3lDEDbgI6vqOpEIfN4t2Zpxl16NFJ9+EvD5RN4ilnaa84iCF5iOkD+KQIlMPB5ex8az2GvDte+xkV4Mzg2p3SWTOKf0qsk3HKvh74vTDX2Bk1B+Zqsz+Z1harUbTpuDLx2jAEA5kih/aoXOqjQRM5mrc1peNTAo9qYuTNWsaSiK1sRsVD0Qc9Nun+TWq/L5HOWc68O5MhgpgJvac9kppMJ+CTTA4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB6PR0402MB2760.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e07dc2d3-9155-49ce-2410-08d81bf6a91d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 06:35:48.4429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NmRyPfTWtT9tmgZRVPpOrkiU+mkQIwuldVriqMockyAX0T7RoLpPgZZtv1zNbSJXKaVO8ByTSQcBW7CQ4G2crw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR04MB4764 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , Stefano Stabellini , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "linux-arm-kernel@lists.infradead.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > Subject: Re: [PATCH] xen: introduce xen_vring_use_dma >=20 > On Mon, Jun 29, 2020 at 06:25:41AM +0000, Peng Fan wrote: > > > > > > Anyway, re-reading the last messages of the original thread > > > > > > [1], it looks like Peng had a clear idea on how to fix the gene= ral issue. > > > > > > Peng, what happened with that? > > > > > > > > We shrinked the rpmsg reserved area to workaround the issue. > > > > So still use the dma apis in rpmsg. > > > > > > > > But here I am going to address domu android trusty issue using virt= io. > > > > > > My suggestion is to first of all fix DMA API so it works properly. > > > > Could you please elaborate more details? > > > > You mean the DMA API usage of rpmsg? Or xen domu dma_ops? > > > > Thanks, > > Peng. >=20 > Not 100% sure but I think xen dma ops. Sorry to ask again, could you explain more details about what issues do you see of current xen ARM domu dma_ops?=20 Or Dom0 swiotlb xen dma_ops? Thanks, Pen.g >=20 > -- > MST From xen-devel-bounces@lists.xenproject.org Mon Jun 29 07:01:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 07:01:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnnL-0005mn-ER; Mon, 29 Jun 2020 07:01:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnnJ-0005mi-Td for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 07:01:33 +0000 X-Inumbo-ID: 5cf7f66a-b9d6-11ea-8531-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5cf7f66a-b9d6-11ea-8531-12813bfff9fa; Mon, 29 Jun 2020 07:01:32 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C235FAE68; Mon, 29 Jun 2020 07:01:31 +0000 (UTC) Subject: Re: [PATCH for-4.14 v3] mm: fix public declaration of struct xen_mem_acquire_resource To: Roger Pau Monne References: <20200626153951.91301-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: <90d0e26c-ff34-9439-441b-32c68d0a1887@suse.com> Date: Mon, 29 Jun 2020 09:01:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626153951.91301-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 17:39, Roger Pau Monne wrote: > XENMEM_acquire_resource and it's related structure is currently inside > a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the > hypervisor or the toolstack only. This is wrong as the hypercall is > already being used by the Linux kernel at least, and as such needs to > be public. > > Also switch the usage of uint64_aligned_t to plain uint64_t, as > uint64_aligned_t is only to be used by the toolstack. Doing such > change will reduce the size of the structure on 32bit x86 by 4bytes, > since there will be no padding added after the frame_list handle. > > This is fine, as users of the previous layout will allocate 4bytes of > padding that won't be read by Xen, and users of the new layout won't > allocate those, which is also fine since Xen won't try to access them. > > Note that the structure already has compat handling, and such handling > will take care of copying the right size (ie: minus the padding) when > called from a 32bit x86 context. This is true for the compat code both > before and after this patch, since the structures in the memory.h > compat header are subject to a pragma pack(4), which already removed > the trailing padding that would otherwise be introduced by the > alignment of the frame field to 8 bytes. > > Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire guest resources') > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Jun 29 07:02:06 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 07:02:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnnq-0005oR-ND; Mon, 29 Jun 2020 07:02:06 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpnnp-0005oG-1E for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 07:02:05 +0000 X-Inumbo-ID: 6fc2f826-b9d6-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6fc2f826-b9d6-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 07:02:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5A145AE68; Mon, 29 Jun 2020 07:02:03 +0000 (UTC) Subject: Re: [PATCH 1/2] xen/displif: Protocol version 2 To: Oleksandr Andrushchenko , xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com, wei.liu2@citrix.com, konrad.wilk@oracle.com References: <20200520090425.28558-1-andr2000@gmail.com> <20200520090425.28558-2-andr2000@gmail.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <84d975e3-0cea-becb-f505-856368a63fb7@suse.com> Date: Mon, 29 Jun 2020 09:02:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200520090425.28558-2-andr2000@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Oleksandr Andrushchenko Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 20.05.20 11:04, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > 1. Change protocol version from string to integer > > Version string, which is in fact an integer, is hard to handle in the > code that supports different protocol versions. To simplify that > make the version an integer. > > 2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE > > There are cases when display data buffer is created with non-zero > offset to the data start. Handle such cases and provide that offset > while creating a display buffer. > > 3. Add XENDISPL_OP_GET_EDID command > > Add an optional request for reading Extended Display Identification > Data (EDID) structure which allows better configuration of the > display connectors over the configuration set in XenStore. > With this change connectors may have multiple resolutions defined > with respect to detailed timing definitions and additional properties > normally provided by displays. > > If this request is not supported by the backend then visible area > is defined by the relevant XenStore's "resolution" property. > > If backend provides extended display identification data (EDID) with > XENDISPL_OP_GET_EDID request then EDID values must take precedence > over the resolutions defined in XenStore. > > 4. Bump protocol version to 2. > > Signed-off-by: Oleksandr Andrushchenko > --- > xen/include/public/io/displif.h | 83 +++++++++++++++++++++++++++++++-- > 1 file changed, 80 insertions(+), 3 deletions(-) > > diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h > index cc5de9cb1f35..4d43ba5078c8 100644 > --- a/xen/include/public/io/displif.h > +++ b/xen/include/public/io/displif.h > @@ -38,7 +38,7 @@ > * Protocol version > ****************************************************************************** > */ > -#define XENDISPL_PROTOCOL_VERSION "1" > +#define XENDISPL_PROTOCOL_VERSION 2 This is not very nice regarding compatibility. Can't you add a new macro for the integer value? And please add comments further down which additions are related to the new version. Juergen From xen-devel-bounces@lists.xenproject.org Mon Jun 29 07:38:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 07:38:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoMT-0008ON-IQ; Mon, 29 Jun 2020 07:37:53 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoMS-0008OI-NV for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 07:37:52 +0000 X-Inumbo-ID: 6fc3c5f8-b9db-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x443.google.com (unknown [2a00:1450:4864:20::443]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6fc3c5f8-b9db-11ea-bca7-bc764e2007e4; Mon, 29 Jun 2020 07:37:51 +0000 (UTC) Received: by mail-wr1-x443.google.com with SMTP id g18so15491394wrm.2 for ; Mon, 29 Jun 2020 00:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=2fwn6pIqS5z7HIEO057khAR+BqVUuqXv4UaASW9OBtA=; b=nhCQNleSGGSYdz2iY8qWzdX0G1oFYsDQBA4/lXVNsE4uD5bsdt3JO3aK+vCi3mhFPS NNJLeAUMyFFn0RP+nuFGgsMJIHX8U8XGZFjVEyHBZf8C1Ir5gdVQYxgrA/k2q0PHOP1b jhe1OUfqeDaJ9odq6JtwQMzqcSLXiyjeSK6TB1eWHcGDFBX+WsES8lVeUsCIXLJcJcXZ UTFGmHphGTVXVw73j6FrAI3+rFA4wrPgvfJdRc+hG+TMNw4TN4cu9wohTqgSihuSJB7O KS+0XqaBopuwvlogbL8Py0mChG5mQUOC2VuNVZ1JTUjWs41rMnWLRkQYxhG9OZb9Xf+d DhCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=2fwn6pIqS5z7HIEO057khAR+BqVUuqXv4UaASW9OBtA=; b=WTsFiRygc0YPA3Wq9MHAYubTc7t/wOQEm/nOCO7Y4lO8QHdMFqkeagap4uCXrnCFon N2B/bB1gaG3AZ5m19+a9LflctYGGzQFo5VzbgAo16SsfU3NNngc8bxruM1bMJqIcJroU 7Doa2fwqcJK6wR/0W9F1sfBFKc9gOzNikBH8bhg2CDKIjRLHRiAQzJo2sqRroR1SXX45 2LImKids/Z24YjO1ZX5/lGQO176JtHn4fqGLzqfI2qFYDH8PRSX9q+fctTsOL5+D/plo 52F49PihTcGdcg8gW9vh8zt1kh/vNvfpNwKyRuM6JrmxUGMbv5UBQ0Yddc3rZSNiIWT0 k7lg== X-Gm-Message-State: AOAM532Oz0HhcX0h0aMiW7O52iGFLZl4URgIHLadhp8vrb/ibl9haaJN DsNM8afWopPUeAfALHQw/GQ= X-Google-Smtp-Source: ABdhPJxrUKPrzjNieTfhQ89HLIGViTHGrRTLE3ngdgJj8kxwuzBkdxh9IIvjiidLZZ3tfR3Tf85eqQ== X-Received: by 2002:adf:ed4f:: with SMTP id u15mr15360789wro.318.1593416270929; Mon, 29 Jun 2020 00:37:50 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-233.amazon.com. [54.240.197.233]) by smtp.gmail.com with ESMTPSA id r12sm46906288wrc.22.2020.06.29.00.37.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 00:37:50 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= , "'Julien Grall'" , References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-3-julien@xen.org> <82c445c0-f7fc-176f-fdac-386228cc17f5@suse.com> In-Reply-To: <82c445c0-f7fc-176f-fdac-386228cc17f5@suse.com> Subject: RE: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches Date: Mon, 29 Jun 2020 08:37:49 +0100 Message-ID: <000001d64de8$31028b10$9307a130$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGCK99Cn3HYUOxaNEXy0vUgpkd+jQFSczG1Aiw0Rw2pe4NCoA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Wei Liu' , 'Andrew Cooper' , 'Julien Grall' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: J=C3=BCrgen Gro=C3=9F > Sent: 27 June 2020 12:54 > To: Julien Grall ; xen-devel@lists.xenproject.org > Cc: paul@xen.org; Julien Grall ; Andrew Cooper = ; George > Dunlap ; Ian Jackson = ; Jan Beulich > ; Stefano Stabellini ; Wei = Liu > Subject: Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and = explicitely the padding for all > arches >=20 > On 27.06.20 11:55, Julien Grall wrote: > > From: Julien Grall > > > > The specification of pvcalls suggests there is padding for 32-bit = x86 > > at the end of most the structure. However, they are not described in > > in the public header. > > > > Because of that all the structures would be 32-bit aligned and not > > 64-bit aligned for 32-bit x86. > > > > For all the other architectures supported (Arm and 64-bit x86), the > > structure are aligned to 64-bit because they contain uint64_t field. > > Therefore all the structures contain implicit padding. > > > > Given the specification is authoriitative, the padding will the same = for >=20 > s/authoriitative/authoritative/ >=20 > > the all architectures. The potential breakage of compatibility is = ought >=20 > s/the// >=20 > > to be fine as pvcalls is still a tech preview. > > > > As an aside, the padding sadly cannot be mandated to be 0 as they = are > > already present. So it is not going to be possible to use the = padding > > for extending a command in the future. > > > > Signed-off-by: Julien Grall >=20 > With above fixed: >=20 > Reviewed-by: Juergen Gross >=20 Release-acked-by: Paul Durrant >=20 > Juergen From xen-devel-bounces@lists.xenproject.org Mon Jun 29 07:38:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 07:38:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoMo-0008QY-Qo; Mon, 29 Jun 2020 07:38:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoMo-0008QQ-9N for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 07:38:14 +0000 X-Inumbo-ID: 7ceef572-b9db-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x442.google.com (unknown [2a00:1450:4864:20::442]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7ceef572-b9db-11ea-bca7-bc764e2007e4; Mon, 29 Jun 2020 07:38:13 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id b6so15436726wrs.11 for ; Mon, 29 Jun 2020 00:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=ThtpoKw1x1EDOR8zDEy2fkpLsaLUgF2xKKKJKpZT2gc=; b=WzlsLD67+BjVSzeig1JBDhmPHqPczMlYvSNcFit4PK4hHi8YnNhSTaeR+41dnE1CbM jhUXGguMtwaCRY2klBms7nqL6Ch/O78/rB5xtqHsYx240kzQDZ8zXaymJLA9kDV0VUiP 4E0Vowzvfi945TOvbGfr9zJ47bl6UHGL7Byst9GSmCJibRjnyCHk7k1qInHgbnU1U1R0 N9tAKPLH6SEBq9WAzm3D5A4REMY5/MfXN1ur5HeQVIGPV9GtYKn1NvANn8xCjRehx5WK 69Al0K5De7hXaj47VDWwc3Tdoq7fBKwZlkrB5INiad50/G8EOUFk1NcEyouJqo4+XSse /hBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=ThtpoKw1x1EDOR8zDEy2fkpLsaLUgF2xKKKJKpZT2gc=; b=tPhvZMllPnNMO5mw7b1Kz9gSWT5f8aINISl16ww2ZRHjBBScmzip1ye8JepmxIxMLe D2DpCoViMwfv/T+Zt/eZ7rseT9Cu6hbbS6RieYKFwye03fWGd4RGLtNhBh+CeaKrluVD 6hvPbHtvmxZlHDDpNY731mdXd4GlG+LUke3BnJbzGU/0XFp79Tkx5y2sfVdcs7wdwXeK SC/630PtpsIfH6CVCjiPM/IV72ox0Jri49nxVHSRgi2WA6NTTIsMMjMONkjPpCQKA0su 4AQhoabHi2p5ZNwxiMWOqpDFhVxvjj4NKrggqfbI1AumaWbBLHR4EQytaATxzB8ZP/Oq mKaw== X-Gm-Message-State: AOAM531MOQdA60awDNaCaki512uP+AedRRMLkOomWCGpfntc6QAEbES2 hhobH/LOgwZzFS51YtXSZRo= X-Google-Smtp-Source: ABdhPJwU2fBCQQWvVVW7kGBWvjRWuBetHO3xdqLHeub6HRdJtys6st+Yk1JI5HgynxbP0NFJ0GgNrw== X-Received: by 2002:a5d:5607:: with SMTP id l7mr15312294wrv.261.1593416293067; Mon, 29 Jun 2020 00:38:13 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-225.amazon.com. [54.240.197.225]) by smtp.gmail.com with ESMTPSA id g3sm52911285wrb.46.2020.06.29.00.38.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 00:38:12 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'J=C3=BCrgen_Gro=C3=9F'?= , "'Julien Grall'" , References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-2-julien@xen.org> In-Reply-To: Subject: RE: [PATCH v4 for-4.14 1/2] pvcalls: Clearly spell out that the header is just a reference Date: Mon, 29 Jun 2020 08:38:11 +0100 Message-ID: <000101d64de8$3e3e25a0$baba70e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQGCK99Cn3HYUOxaNEXy0vUgpkd+jQHxehugAhWOP2ipd0BgsA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Julien Grall' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: J=C3=BCrgen Gro=C3=9F > Sent: 27 June 2020 12:55 > To: Julien Grall ; xen-devel@lists.xenproject.org > Cc: paul@xen.org; Julien Grall > Subject: Re: [PATCH v4 for-4.14 1/2] pvcalls: Clearly spell out that = the header is just a reference >=20 > On 27.06.20 11:55, Julien Grall wrote: > > From: Julien Grall > > > > A recent thread on xen-devel [1] pointed out that the header was > > provided as a reference for the specification. > > > > Unfortunately, this was never written down in xen.git so for an = external > > user (or a reviewer) it is not clear whether the spec or the header > > shoudl be followed when there is a conflict. >=20 > should >=20 > > > > To avoid more confusion, a paragraph is added at the top of the = header > > to clearly spell out it is only provided for reference. > > > > [1] = https://lore.kernel.org/xen-devel/alpine.DEB.2.21.2006151343430.9074@ssta= bellini-ThinkPad-T480s/ > > > > Signed-off-by: Julien Grall >=20 > Reviewed-by: Juergen Gross >=20 Release-acked-by: Paul Durrant >=20 > Juergen From xen-devel-bounces@lists.xenproject.org Mon Jun 29 07:41:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 07:41:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoPd-0000oX-93; Mon, 29 Jun 2020 07:41:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoPc-0000oS-1F for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 07:41:08 +0000 X-Inumbo-ID: e456b20e-b9db-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x42b.google.com (unknown [2a00:1450:4864:20::42b]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e456b20e-b9db-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 07:41:07 +0000 (UTC) Received: by mail-wr1-x42b.google.com with SMTP id r12so15409359wrj.13 for ; Mon, 29 Jun 2020 00:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=tphsBSB9nwEvETHetQs2071qRWmYmER5CGxR2YJlEuw=; b=KyPOB888QelFaNxi35T4PuLciP5paRHbrElKGKGolczyPAxHyo+AXE6qxtS37jOz5B KqCMN+I/vFbeYrYVTPjDBvmjxbbLtrFyUrjwgRcrLzmZ1J+NN92PQR1/gsfO18F7V1yJ 9gYwmxQMdXutj8uvDE+h82+Blk7rJTQKzCG6HibX90EvNPbRWEYIRh8velD5UVLQ7yA5 TUaViN1oRPnPuH7kOqmhzUAKIlk4g9pyww3lftnvYonAgVqfiimyz2MdO46DAypynFex vF8QU2cDLV/QG3acxP67f6ifGu5tWelK5vgM1KUn3/SRyOmGJXroyoRRHlKYUcdZTq1P NDQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=tphsBSB9nwEvETHetQs2071qRWmYmER5CGxR2YJlEuw=; b=gObB+9P74jvrF5ajK5jfsx74H2hWhjzdzYCbzQLa0pm2hQ0yrvRaOzZgz+gfd5FxdR ki3CFs62d42sjJdeITx6Iw9/d1kQ8vRnhMiBfgpOTZK27wOUETUkYklWW3t/VETuc2L2 1LN75h4ne8SW0wuXeT5ruD14d4J8e9iAfG3IfzocJ8OG7gjlG0emmO/x/5SGHSqDFUKX Jh7IJSEbsVUPRPjC/kmcT4ZhMxkl5AVcIIQwthsSd2q0fTg4swXcfk28sGS60A+mwfgw 9b9g2JMK2MR+1gs/yN7bPUwnYq8Mlru3a0DCy7GJmt34X0mJzE/uLeVgoDjxshvMAzNh loeA== X-Gm-Message-State: AOAM5331b95F8MvU72u8y2N5F4/9CAKZ8+KsCmN4o5Us6dD7rbP46ued DYVtCdAP1uWHv8sODJev4wI= X-Google-Smtp-Source: ABdhPJwsIWeKp3D+/hy1YeBAVDTJjdswHh06TxviF5wLJ1d/LpfWGlV5fDog720o9tlo2KvVUbUP6w== X-Received: by 2002:a5d:6045:: with SMTP id j5mr15467570wrt.209.1593416466457; Mon, 29 Jun 2020 00:41:06 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-225.amazon.com. [54.240.197.225]) by smtp.gmail.com with ESMTPSA id w7sm28677309wmc.32.2020.06.29.00.41.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 00:41:06 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200626170038.27650-1-andrew.cooper3@citrix.com> In-Reply-To: <20200626170038.27650-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH] tools/configure: drop BASH configure variable Date: Mon, 29 Jun 2020 08:41:05 +0100 Message-ID: <000201d64de8$a5938bf0$f0baa3d0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQG/+PmFeHEa0PFXsi/qRsJidKaVMqkb3yeQ X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Ian Jackson' , 'Daniel De Graaf' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 26 June 2020 18:01 > To: Xen-devel > Cc: Andrew Cooper ; Ian Jackson ; Wei Liu > ; Daniel De Graaf ; Paul Durrant > Subject: [PATCH] tools/configure: drop BASH configure variable > > This is a weird variable to have in the first place. The only user of it is > XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only two scripts > run with this are shebang sh anyway, so don't need bash in the first place. > > Make the mkflask.sh and mkaccess_vector.sh scripts executable, drop the > CONFIG_SHELL, and drop the $BASH variable to prevent further use. > > Signed-off-by: Andrew Cooper > --- > CC: Ian Jackson > CC: Wei Liu > CC: Daniel De Graaf > CC: Paul Durrant > > ./autogen.sh needs rerunning on commit. > > RFC for 4.14. This is a cleanup to the build system. > > There is a separate check for [BASH] in the configure script, which is > checking the requirement for the Linux hotplug scripts. Really, that is a > runtime requirement not a build time requirement, and it is rude to require > bash in a build environment on this basis. IMO, that check wants dropping as > well. That sounds quite reasonable. Release-acked-by: Paul Durrant > --- > config/Tools.mk.in | 1 - > tools/configure.ac | 1 - > xen/xsm/flask/Makefile | 8 ++------ > xen/xsm/flask/policy/mkaccess_vector.sh | 0 > xen/xsm/flask/policy/mkflask.sh | 0 > 5 files changed, 2 insertions(+), 8 deletions(-) > mode change 100644 => 100755 xen/xsm/flask/policy/mkaccess_vector.sh > mode change 100644 => 100755 xen/xsm/flask/policy/mkflask.sh > > diff --git a/config/Tools.mk.in b/config/Tools.mk.in > index 23df47af8d..48bd9ab731 100644 > --- a/config/Tools.mk.in > +++ b/config/Tools.mk.in > @@ -12,7 +12,6 @@ PYTHON := @PYTHON@ > PYTHON_PATH := @PYTHONPATH@ > PY_NOOPT_CFLAGS := @PY_NOOPT_CFLAGS@ > PERL := @PERL@ > -BASH := @BASH@ > XGETTTEXT := @XGETTEXT@ > AS86 := @AS86@ > LD86 := @LD86@ > diff --git a/tools/configure.ac b/tools/configure.ac > index 9d126b7a14..6614a4f130 100644 > --- a/tools/configure.ac > +++ b/tools/configure.ac > @@ -297,7 +297,6 @@ AC_ARG_VAR([PYTHON], [Path to the Python parser]) > AC_ARG_VAR([PERL], [Path to Perl parser]) > AC_ARG_VAR([BISON], [Path to Bison parser generator]) > AC_ARG_VAR([FLEX], [Path to Flex lexical analyser generator]) > -AC_ARG_VAR([BASH], [Path to bash shell]) > AC_ARG_VAR([XGETTEXT], [Path to xgetttext tool]) > AC_ARG_VAR([AS86], [Path to as86 tool]) > AC_ARG_VAR([LD86], [Path to ld86 tool]) > diff --git a/xen/xsm/flask/Makefile b/xen/xsm/flask/Makefile > index 07f36d075d..ba8f31a02c 100644 > --- a/xen/xsm/flask/Makefile > +++ b/xen/xsm/flask/Makefile > @@ -8,10 +8,6 @@ CFLAGS-y += -I./include > > AWK = awk > > -CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ > - else if [ -x /bin/bash ]; then echo /bin/bash; \ > - else echo sh; fi ; fi) > - > FLASK_H_DEPEND = policy/security_classes policy/initial_sids > AV_H_DEPEND = policy/access_vectors > > @@ -24,14 +20,14 @@ extra-y += $(ALL_H_FILES) > > mkflask := policy/mkflask.sh > quiet_cmd_mkflask = MKFLASK $@ > -cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND) > +cmd_mkflask = $(mkflask) $(AWK) include $(FLASK_H_DEPEND) > > $(subst include/,%/,$(FLASK_H_FILES)): $(FLASK_H_DEPEND) $(mkflask) FORCE > $(call if_changed,mkflask) > > mkaccess := policy/mkaccess_vector.sh > quiet_cmd_mkaccess = MKACCESS VECTOR $@ > -cmd_mkaccess = $(CONFIG_SHELL) $(mkaccess) $(AWK) $(AV_H_DEPEND) > +cmd_mkaccess = $(mkaccess) $(AWK) $(AV_H_DEPEND) > > $(subst include/,%/,$(AV_H_FILES)): $(AV_H_DEPEND) $(mkaccess) FORCE > $(call if_changed,mkaccess) > diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh > old mode 100644 > new mode 100755 > diff --git a/xen/xsm/flask/policy/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh > old mode 100644 > new mode 100755 > -- > 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 29 07:42:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 07:42:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoQp-0000uW-JF; Mon, 29 Jun 2020 07:42:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoQo-0000uR-5V for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 07:42:22 +0000 X-Inumbo-ID: 10797e02-b9dc-11ea-bca7-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 10797e02-b9dc-11ea-bca7-bc764e2007e4; Mon, 29 Jun 2020 07:42:21 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id a6so15479106wrm.4 for ; Mon, 29 Jun 2020 00:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=G8h4srgt/O2LGLuQVDIDxdaXLHaIRe/uLhzvy6b+R8Q=; b=glQkoH9IppBkTxvjGWREd6jau8JYPOReycuVYck6AMb71Dc6VQjbSn+2b2eo498kj7 56IF2BqbZHODZnqV9BVJk2C9uH1DT2mhAFB2KlW9UUitaooX5jwexng6C/cp4Fe7YQC8 TGcpwZzAwsHr+eNrAtQV2Km9wbCitO5Bp/3RExPgVmB0qp2kfEiQn8EcdK1UWXRFpCKV Sn976oVI8fOkfbtGvwSFcqqw7kudfRSypbhMhFcEPP9RIuXcNZ36gVNSXfhj+Khj78aE QNzMxNoffMS6YuIA9cYEfLaWZjvk6JbdoTPQ4KBm/2wy2BObfMTLJJ6ACJQaZXZXcMe7 Jz4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=G8h4srgt/O2LGLuQVDIDxdaXLHaIRe/uLhzvy6b+R8Q=; b=jEnOGrFxaSIgk5d/ZP7VtUe2/CZpxP4VaSjrrXURuC1gB3sJzuvCRyviZ7cHV2Iszu q8/0Bk48Tx/dgJixa7LdASyo3H627CzJp6jjFwNKevSQo0XWIzFRampooNfHUYv+jta+ zmVzexEE3UPZBXJcSxETgRQnvQYI3hqJoP40qWG8JfXx1GYHVck7UfMQMe1bEhHb9fbO qO2iI9ahm6Lt1Nx8rmTCjooENXfSK0+J7w4sLvdoPbBTrvCzEoiC+MIqQkazqHIafZiy Z+uA7MBHAtTv5WFJx2/qoSFoyzyb34evbNzse683kD4JL4yThSuDTtWw325CbSsxBSiM O4Lg== X-Gm-Message-State: AOAM533R4ScnmzxYRAMlJH2sPDgIiypuBl3wCP4437ji1VRU9alcMKdj TXOG1kWSoG04r3LFemhu2Lo= X-Google-Smtp-Source: ABdhPJzyAp8n8/vzQI1N7/ffyGNbLDtVc0xx6JoIvG8U/ODKw5lwTtdj5CusiITL1oL9x6hN5vcYZg== X-Received: by 2002:adf:dd4a:: with SMTP id u10mr15636976wrm.169.1593416540478; Mon, 29 Jun 2020 00:42:20 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-233.amazon.com. [54.240.197.233]) by smtp.gmail.com with ESMTPSA id 33sm41252858wri.16.2020.06.29.00.42.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 00:42:19 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Julien Grall'" , "'Stefano Stabellini'" References: <20200619223332.438344-1-volodymyr_babchuk@epam.com> <20200619223332.438344-3-volodymyr_babchuk@epam.com> <87ftampkd7.fsf@epam.com> <2df789f3-e881-36a3-51f4-010b499990f5@xen.org> In-Reply-To: Subject: RE: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address Date: Mon, 29 Jun 2020 08:42:18 +0100 Message-ID: <000301d64de8$d1811f20$74835d60$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQF8aMotKGFAAmO8nEfAR6Jir94dVQJSzqciAe2X8UkCbENBnAId7rd6AcYXkBoCj8igFKk5/Aqw X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: xen-devel@lists.xenproject.org, op-tee@lists.trustedfirmware.org, 'Volodymyr Babchuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Julien Grall > Sent: 26 June 2020 18:54 > To: Stefano Stabellini ; paul@xen.org > Cc: Volodymyr Babchuk ; xen-devel@lists.xenproject.org; op- > tee@lists.trustedfirmware.org > Subject: Re: [PATCH v2 2/2] optee: allow plain TMEM buffers with NULL address > > (using paul xen.org's email) > Thanks. Avoids annoying warning banners :-) > Hi, > > Apologies for the late answer. > > On 23/06/2020 22:09, Stefano Stabellini wrote: > > On Tue, 23 Jun 2020, Julien Grall wrote: > >> On 23/06/2020 03:49, Volodymyr Babchuk wrote: > >>> > >>> Hi Stefano, > >>> > >>> Stefano Stabellini writes: > >>> > >>>> On Fri, 19 Jun 2020, Volodymyr Babchuk wrote: > >>>>> Trusted Applications use popular approach to determine required size > >>>>> of buffer: client provides a memory reference with the NULL pointer to > >>>>> a buffer. This is so called "Null memory reference". TA updates the > >>>>> reference with the required size and returns it back to the > >>>>> client. Then client allocates buffer of needed size and repeats the > >>>>> operation. > >>>>> > >>>>> This behavior is described in TEE Client API Specification, paragraph > >>>>> 3.2.5. Memory References. > >>>>> > >>>>> OP-TEE represents this null memory reference as a TMEM parameter with > >>>>> buf_ptr = 0x0. This is the only case when we should allow TMEM > >>>>> buffer without the OPTEE_MSG_ATTR_NONCONTIG flag. This also the > >>>>> special case for a buffer with OPTEE_MSG_ATTR_NONCONTIG flag. > >>>>> > >>>>> This could lead to a potential issue, because IPA 0x0 is a valid > >>>>> address, but OP-TEE will treat it as a special case. So, care should > >>>>> be taken when construction OP-TEE enabled guest to make sure that such > >>>>> guest have no memory at IPA 0x0 and none of its memory is mapped at PA > >>>>> 0x0. > >>>>> > >>>>> Signed-off-by: Volodymyr Babchuk > >>>>> --- > >>>>> > >>>>> Changes from v1: > >>>>> - Added comment with TODO about possible PA/IPA 0x0 issue > >>>>> - The same is described in the commit message > >>>>> - Added check in translate_noncontig() for the NULL ptr buffer > >>>>> > >>>>> --- > >>>>> xen/arch/arm/tee/optee.c | 27 ++++++++++++++++++++++++--- > >>>>> 1 file changed, 24 insertions(+), 3 deletions(-) > >>>>> > >>>>> diff --git a/xen/arch/arm/tee/optee.c b/xen/arch/arm/tee/optee.c > >>>>> index 6963238056..70bfef7e5f 100644 > >>>>> --- a/xen/arch/arm/tee/optee.c > >>>>> +++ b/xen/arch/arm/tee/optee.c > >>>>> @@ -215,6 +215,15 @@ static bool optee_probe(void) > >>>>> return true; > >>>>> } > >>>>> +/* > >>>>> + * TODO: There is a potential issue with guests that either have RAM > >>>>> + * at IPA of 0x0 or some of theirs memory is mapped at PA 0x0. This is > >>>> ^ their > >>>> > >>>>> + * because PA of 0x0 is considered as NULL pointer by OP-TEE. It will > >>>>> + * not be able to map buffer with such pointer to TA address space, or > >>>>> + * use such buffer for communication with the guest. We either need to > >>>>> + * check that guest have no such mappings or ensure that OP-TEE > >>>>> + * enabled guest will not be created with such mappings. > >>>>> + */ > >>>>> static int optee_domain_init(struct domain *d) > >>>>> { > >>>>> struct arm_smccc_res resp; > >>>>> @@ -725,6 +734,15 @@ static int translate_noncontig(struct optee_domain > >>>>> *ctx, > >>>>> uint64_t next_page_data; > >>>>> } *guest_data, *xen_data; > >>>>> + /* > >>>>> + * Special case: buffer with buf_ptr == 0x0 is considered as NULL > >>>>> + * pointer by OP-TEE. No translation is needed. This can lead to > >>>>> + * an issue as IPA 0x0 is a valid address for Xen. See the comment > >>>>> + * near optee_domain_init() > >>>>> + */ > >>>>> + if ( !param->u.tmem.buf_ptr ) > >>>>> + return 0; > >>>> > >>>> Given that today it is not possible for this to happen, it could even be > >>>> an ASSERT. But I think I would just return an error, maybe -EINVAL? > >>> > >>> Hmm, looks like my comment is somewhat misleading :( > >> > >> How about the following comment: > >> > >> We don't want to translate NULL (0) as it can be used by the guest to fetch > >> the size of the buffer to allocate. This behavior depends on TA, but there is > >> a guarantee that OP-TEE will not try to map it (see more details on top of > >> optee_domain_init()). > >> > >>> > >>> What I mean, is that param->u.tmem.buf_ptr == 0 is the normal situation. > >>> This is the special case, when OP-TEE treats this buffer as a NULL. So > >>> we are doing nothing there. Thus, "return 0". > >>> > >>> But, as Julien pointed out, we can have machine where 0x0 is the valid > >>> memory address and there is a chance, that some guest will use it as a > >>> pointer to buffer. > >>> > >>>> Aside from this, and the small grammar issue, everything else looks fine > >>>> to me. > >>>> > >>>> Let's wait for Julien's reply, but if this is the only thing I could fix > >>>> on commit. > >> > >> I agree with Volodymyr, this is the normal case here. There are more work to > >> prevent MFN 0 to be mapped in the guest but this shouldn't be an issue today. > > > > Let's put the MFN 0 issue aside for a moment. > > > > From the commit message I thought that if the guest wanted to pass a > > NULL buffer ("Null memory reference") then it would also *not* set > > OPTEE_MSG_ATTR_NONCONTIG, which would be handled by the "else" statement > > also modified by this patch. Thus, I thought that reaching > > translate_noncontig with buf_ptr == NULL would always be an error. > > > > But re-reading the commit message and from both your answers it is not > > the case: a "Null memory reference" is allowed with > > OPTEE_MSG_ATTR_NONCONTIG set too. > > > > Thus, I have no further comments and the improvements on the in-code > > comment could be done on commit. > > Good :). IIRC Paul gave a provisional RaB for this series. @Paul, now > that we are settled, could we get a formal one? Sure. Release-acked-by: Paul Durrant > > Cheers, > > -- > Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jun 29 07:43:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 07:43:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoSD-00012m-1G; Mon, 29 Jun 2020 07:43:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpoSB-00012g-NC for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 07:43:47 +0000 X-Inumbo-ID: 42669efe-b9dc-11ea-b7bb-bc764e2007e4 Received: from mail2.tttech.com (unknown [217.19.35.52]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 42669efe-b9dc-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 07:43:45 +0000 (UTC) IronPort-SDR: Yw7sN+iHvdrIz5h4UG1DMyC2gXGNpLOxzQSz+5Bf2nf/yz8DBUQVfzKZXEKEbzH/wNTUCFkw14 R4pqTEDxPIpT1GeMK/ETE2lBJggDSou4JxQRI+LgmXC/ZaYGV2DGwUjUttn3LHD7m+2EWe7wBD dJZbYjPLYvfhi5b6CveRgmc13JGpyKUwhZD7GNjGXTIaPsVCeHBcqPql+jV2x8ZncbEYVhXEIR snTJyco5kA6Ak3CE9A2Pg6UGt5Fk0O2YDZfDkXfmb/hGm3Ff3XtL7lcxGYLQWFIPHiHY5NKkSP nok= X-IronPort-AV: E=Sophos;i="5.75,294,1589234400"; d="scan'208,217";a="4641899" Received: from unknown (HELO mail.tttech.com) ([10.108.0.226]) by mail2-int.tttech.com with ESMTP; 29 Jun 2020 09:43:44 +0200 Received: from EXVIE02.ds1.internal (10.108.0.226) by EXVIE02.ds1.internal (10.108.0.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 29 Jun 2020 09:43:43 +0200 Received: from EXVIE02.ds1.internal ([fe80::4ccf:d313:b2a8:c054]) by EXVIE02.ds1.internal ([fe80::4ccf:d313:b2a8:c054%6]) with mapi id 15.01.1913.007; Mon, 29 Jun 2020 09:43:43 +0200 From: Jan Ruh To: "xen-devel@lists.xenproject.org" Subject: Kernel requires x86-64 CPU, after modifying arch_shared_info struct Thread-Topic: Kernel requires x86-64 CPU, after modifying arch_shared_info struct Thread-Index: AQHWTehUS5L/6eMJQEyE2773H88H5A== Date: Mon, 29 Jun 2020 07:43:43 +0000 Message-ID: <6f88fc3e2795436fa1f30dd026dd8eda@tttech.com> Accept-Language: de-DE, en-GB, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.102.6.20] Content-Type: multipart/alternative; boundary="_000_6f88fc3e2795436fa1f30dd026dd8edatttechcom_" MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --_000_6f88fc3e2795436fa1f30dd026dd8edatttechcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Xen Dev Community, I ran into an issue when implementing a prototype for a new paravirtualized= clock for x86-64 hosts. I extended the arch_shared_info struct by 6 fields= totaling at 36 bytes. I updated the xen-foreign/references.size to represe= nt the new size of the arch_shared_info struct. The fields are correctly up= dated in Xen and I am also able to read the correct information stored from= dom0. However, if I try to start a hvm VM with pvh extensions it does not = boot telling me that "This kernel requires an x86-64 CPU, but only detected= an i686 CPU.". I have rebuild my Linux domU kernel just as the dom0 kernel= and everything should be compatible. To me this looks like Xen or libxc do= es some compatibility checks before booting up my HVM domU and decides to d= owngrade the detectable CPU due to some issue that I am not aware of. Do I = miss something? Is my approach to extend the arch_shared_info wrong in the = first place? I am really thankful for some advice or pointers what is happe= ning here. Best Jan CONFIDENTIALITY: The contents of this e-mail are confidential and intended = only for the above addressee(s). If you are not the intended recipient, or = the person responsible for delivering it to the intended recipient, copying= or delivering it to anyone else or using it in any unauthorized manner is = prohibited and may be unlawful. If you receive this e-mail by mistake, plea= se notify the sender and the systems administrator at straymail@tttech.com = immediately. --_000_6f88fc3e2795436fa1f30dd026dd8edatttechcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Xen Dev Community,


I ran into an issue when implementing a prototype for a new paravirtuali= zed clock for x86-64 hosts. I extended the arch_shared_info struct by 6 fie= lds totaling at 36 bytes. I updated the xen-foreign/references.size to= represent the new size of the arch_shared_info struct. The fields are correctly updated in Xen and I am also able to read= the correct information stored from dom0. However, if I try to start a hvm= VM with pvh extensions it does not boot telling me that "This kernel = requires an x86-64 CPU, but only detected an i686 CPU.". I have rebuild my Linux domU kernel just as the dom0 k= ernel and everything should be compatible. To me this looks like Xen or lib= xc does some compatibility checks before booting up my HVM domU and decides= to downgrade the detectable CPU due to some issue that I am not aware of. Do I miss something? Is my approach = to extend the arch_shared_info wrong in the first place? I am really thankf= ul for some advice or pointers what is happening here.


Best


Jan

CONFIDENTIALITY: The contents of this e-mail are confidential and intended = only for the above addressee(s). If you are not the intended recipient, or = the person responsible for delivering it to the intended recipient, copying= or delivering it to anyone else or using it in any unauthorized manner is prohibited and may be unlawful. = If you receive this e-mail by mistake, please notify the sender and the sys= tems administrator at straymail@tttech.com immediately. --_000_6f88fc3e2795436fa1f30dd026dd8edatttechcom_-- From xen-devel-bounces@lists.xenproject.org Mon Jun 29 08:21:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 08:21:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpp2y-0004sF-FO; Mon, 29 Jun 2020 08:21:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpp2w-0004s8-Ry for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 08:21:46 +0000 X-Inumbo-ID: 91d5389c-b9e1-11ea-853f-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 91d5389c-b9e1-11ea-853f-12813bfff9fa; Mon, 29 Jun 2020 08:21:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id EDCA4AC9F; Mon, 29 Jun 2020 08:21:44 +0000 (UTC) Subject: Re: [PATCH] xsm: Drop trailing whitespace from build scripts To: Andrew Cooper References: <20200626170221.28534-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <9822c557-655b-67cb-c513-60039dbe0d8d@suse.com> Date: Mon, 29 Jun 2020 10:21:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626170221.28534-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Daniel De Graaf Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 19:02, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper > --- > CC: Daniel De Graaf Since we've not heard anything from Daniel in quite a while, just in case: Acked-by: Jan Beulich Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 29 08:25:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 08:25:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpp6u-00051F-0C; Mon, 29 Jun 2020 08:25:52 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpp6s-000519-Bn for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 08:25:50 +0000 X-Inumbo-ID: 233d1aa2-b9e2-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x32c.google.com (unknown [2a00:1450:4864:20::32c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 233d1aa2-b9e2-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 08:25:49 +0000 (UTC) Received: by mail-wm1-x32c.google.com with SMTP id g10so1782847wmc.1 for ; Mon, 29 Jun 2020 01:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=AuJlaHKuyVu7EKYDjhJnZAYNsBzoL+I5XdtiyNwUB54=; b=tT/0o2b122Uo6c7myzyj7sFTEQtQ9rgp2F3Gdh6jdtfmPqpsLWalsGD0lwq8Si2sRI CPFHU6qDBg9Trc2OlwlH9/0tvFaaWxiaVNljQPj/+dJqUd/1MLBLZSpLmlkYrIgs5YQx l1EHVglLSWu91VcQCtG3sv03Gmh9yWUTznEyMM4wxakUoigdG9yCUE2Gzl//KuAukovd vj/VYfDBdiBepDg2KD7Xd1Mp983rlIFQMikUZlUVBsP5ms0VvDJhjM6bJJ2aI1CArr8K TXOv9Y7Ozjr6olxG4zD+r4IFKUkLqmgmeW39pA1JR4N3Mo7YQCEMRpTqBkxuBXA/Srnd 1Xmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=AuJlaHKuyVu7EKYDjhJnZAYNsBzoL+I5XdtiyNwUB54=; b=e3yU/N6L+0KYxe2n3wcpVVWmiNkJRC+SFsxZN6IxFus2lYoCTune3CuNPtLXFViyEr C8qEvXhETUbw9tU68iESy7WI+1+hELvY/ZepzYxU9lpiLsLthlLz12hz/tnNd9bd/Ey5 kj4f8PdrKbZAqVOZXN2CXgVdZ5l05IYnSR6Jic4ZkLsEX+FkwKMBvRLumyNjsaQ3s+d0 bPbqTxlWe9JR8opHvCCC+QN/0outEa5ee7Gl8On3JwQwClJ0TMAF+i76ExnfVowb6yNB YfGfC0az4IfIrG/QsutQGOjlgi6mnxkwvRp8zi0dX2vj84CHhQCLKsX+Okh6cJ0ofZds x/1Q== X-Gm-Message-State: AOAM530Bi79A7ujI+f6bUZdzVkT7SSoJalgVNl+eRBBzInAi4g5wVxEX GJ130+KkMFV9JLXO3/x+kBM= X-Google-Smtp-Source: ABdhPJyg1kTuazyv0gYP9JVDRkJR66fclJil4yhXsDYiTCoujxLiWZnlwxNtnXGyZDr1BBxwQ+EKgw== X-Received: by 2002:a1c:a304:: with SMTP id m4mr16536385wme.49.1593419148990; Mon, 29 Jun 2020 01:25:48 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-225.amazon.com. [54.240.197.225]) by smtp.gmail.com with ESMTPSA id g14sm14625647wrm.93.2020.06.29.01.25.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 01:25:48 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Jan Beulich'" , "'Andrew Cooper'" References: <20200626170221.28534-1-andrew.cooper3@citrix.com> <9822c557-655b-67cb-c513-60039dbe0d8d@suse.com> In-Reply-To: <9822c557-655b-67cb-c513-60039dbe0d8d@suse.com> Subject: RE: [PATCH] xsm: Drop trailing whitespace from build scripts Date: Mon, 29 Jun 2020 09:25:47 +0100 Message-ID: <000601d64dee$e47b2840$ad7178c0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQIxqs/FMOzqZHKIY0/vJ+L/6kqMnQGJHYPCqCw+/UA= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Xen-devel' , 'Daniel De Graaf' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of Jan Beulich > Sent: 29 June 2020 09:22 > To: Andrew Cooper > Cc: Xen-devel ; Daniel De Graaf > Subject: Re: [PATCH] xsm: Drop trailing whitespace from build scripts > > On 26.06.2020 19:02, Andrew Cooper wrote: > > Signed-off-by: Andrew Cooper > > --- > > CC: Daniel De Graaf > > Since we've not heard anything from Daniel in quite a while, just > in case: > Acked-by: Jan Beulich > This is pretty trivial cleanup so, if you want to put it in 4.14 consider it... Release-acked-by: Paul Durrant > > Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 29 08:28:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 08:28:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpp9W-00059f-Dt; Mon, 29 Jun 2020 08:28:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpp9V-00059Z-2q for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 08:28:33 +0000 X-Inumbo-ID: 8379dac2-b9e2-11ea-853f-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8379dac2-b9e2-11ea-853f-12813bfff9fa; Mon, 29 Jun 2020 08:28:31 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 55437AC9F; Mon, 29 Jun 2020 08:28:30 +0000 (UTC) Subject: Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches To: Julien Grall References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-3-julien@xen.org> From: Jan Beulich Message-ID: <9fc81bbe-6c30-e848-ceae-1356ec30a8f8@suse.com> Date: Mon, 29 Jun 2020 10:28:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200627095533.14145-3-julien@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 27.06.2020 11:55, Julien Grall wrote: > From: Julien Grall > > The specification of pvcalls suggests there is padding for 32-bit x86 > at the end of most the structure. However, they are not described in > in the public header. > > Because of that all the structures would be 32-bit aligned and not > 64-bit aligned for 32-bit x86. The added padding doesn't change the alignment. It's sizeof() which gets corrected this way. > For all the other architectures supported (Arm and 64-bit x86), the > structure are aligned to 64-bit because they contain uint64_t field. > Therefore all the structures contain implicit padding. > > Given the specification is authoriitative, the padding will the same for Nit: ... will be the same ... > the all architectures. The potential breakage of compatibility is ought Nit: Drop "is". > to be fine as pvcalls is still a tech preview. > > As an aside, the padding sadly cannot be mandated to be 0 as they are > already present. So it is not going to be possible to use the padding > for extending a command in the future. Why is the other adjustment fine to make due to still being tech preview, but this one wouldn't be for the same reason? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 29 08:32:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 08:32:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jppDd-0005va-Vv; Mon, 29 Jun 2020 08:32:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jppDc-0005vV-Q5 for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 08:32:48 +0000 X-Inumbo-ID: 1cb5d5ce-b9e3-11ea-853f-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1cb5d5ce-b9e3-11ea-853f-12813bfff9fa; Mon, 29 Jun 2020 08:32:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 7D668AB89; Mon, 29 Jun 2020 08:32:47 +0000 (UTC) Subject: Re: Suspend/hibernate not working on Dell XPS 15 9500 laptop To: Trevor Bentley References: From: Jan Beulich Message-ID: <3d49bf4a-d82d-36d3-863c-e954d751b959@suse.com> Date: Mon, 29 Jun 2020 10:32:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 27.06.2020 10:35, Trevor Bentley wrote: > Please let me know if you have any suggestions to try, or if you need > any extra information for debugging. I don't suppose you have a serial port on this laptop? I ask because the serial log (and the possibility to issue debug keys) are about the only thing debugging-wise that may help here, short of someone noticing the underlying problem by code inspection. Do you have any indication of the laptop at least partly waking up again, e.g. from some LED or other indicator activity? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 29 08:42:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 08:42:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jppMW-0006my-T7; Mon, 29 Jun 2020 08:42:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jppMW-0006mt-3U for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 08:42:00 +0000 X-Inumbo-ID: 64ed8458-b9e4-11ea-853f-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 64ed8458-b9e4-11ea-853f-12813bfff9fa; Mon, 29 Jun 2020 08:41:59 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 19471AB89; Mon, 29 Jun 2020 08:41:58 +0000 (UTC) Subject: Re: [PATCH] tools/configure: drop BASH configure variable To: Andrew Cooper References: <20200626170038.27650-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <880fcc83-875c-c030-bfac-c64477aa3254@suse.com> Date: Mon, 29 Jun 2020 10:41:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626170038.27650-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Daniel De Graaf , Ian Jackson , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 19:00, Andrew Cooper wrote: > @@ -24,14 +20,14 @@ extra-y += $(ALL_H_FILES) > > mkflask := policy/mkflask.sh > quiet_cmd_mkflask = MKFLASK $@ > -cmd_mkflask = $(CONFIG_SHELL) $(mkflask) $(AWK) include $(FLASK_H_DEPEND) > +cmd_mkflask = $(mkflask) $(AWK) include $(FLASK_H_DEPEND) This and ... > $(subst include/,%/,$(FLASK_H_FILES)): $(FLASK_H_DEPEND) $(mkflask) FORCE > $(call if_changed,mkflask) > > mkaccess := policy/mkaccess_vector.sh > quiet_cmd_mkaccess = MKACCESS VECTOR $@ > -cmd_mkaccess = $(CONFIG_SHELL) $(mkaccess) $(AWK) $(AV_H_DEPEND) > +cmd_mkaccess = $(mkaccess) $(AWK) $(AV_H_DEPEND) ... this should still use $(SHELL) though, as ... > diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh > old mode 100644 > new mode 100755 > diff --git a/xen/xsm/flask/policy/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh > old mode 100644 > new mode 100755 ... this may or may not take effect on the file system the sources are stored on. Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 29 08:58:24 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 08:58:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jppcB-0007lG-6z; Mon, 29 Jun 2020 08:58:11 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jppcA-0007lB-1G for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 08:58:10 +0000 X-Inumbo-ID: a6f57804-b9e6-11ea-853f-12813bfff9fa Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a6f57804-b9e6-11ea-853f-12813bfff9fa; Mon, 29 Jun 2020 08:58:08 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 3DotGuMn/L7lm8Q1knDxCNoI48VWkEGWZcfryKJjpGWnUTCxIbLWKGK+WAnlmsiZCL7xXE6QwF xBAfYX1ZgRy1LrF/uvKYfQPtodcKw0PagJkmg2W/ZxDkAXpFnhW5HUeVJ4zGXq45Q5X5PsPWbP vTSyrGj9VQQ9DD4hTgtv54zUN+UYZ7J9TrF6XFdrZT1bPHe4Cmvilw5l2qIVxvj5h+Tdy6Hn1v 8qoR+fCD0NAQoBaiRUKeS73t7bu4/hcp5zW2TMf2xpou5gwbWZwnW7c+tMbrwVitSsDb//tATA Y70= X-SBRS: 2.7 X-MesageID: 21497432 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21497432" Date: Mon, 29 Jun 2020 10:57:58 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Subject: Re: Questions about PVH memory layout Message-ID: <20200629085758.GE735@Air-de-Roger> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sun, Jun 28, 2020 at 08:58:14AM +0200, joshua_peter@web.de wrote: > Hello everyone, > > I hope this is the right forum for these kinds of questions (the website > states no "technical support queries"; I'm not sure if this qualifies). > If not, sorry for the disturbance; just simply direct me elsewhere then. > > Anyway, I'm currently trying to get into how Xen works in detail, so > for one I've been reading a lot of code, but also I dumped the P2M table > of my PVH guest to get a feel for how things are layed out in memory. I > mean there is the usual stuff, such as lots of RAM, and the APIC is > mapped at 0xFEE00000 and the APCI tables at 0xFC000000 onwards. But two > things stuck out to me, which for the life of me I couldn't figure out > from just reading the code. The first one is, there are a few pages at > the end of the 32bit address space (from 0xFEFF8000 to 0xFEFFF000), > which according to the E820 is declared simply as "reserved". Those are the HVM special pages, which are used for various Xen specific things, like the shared memory ring for the PV console. They are setup in tools/libxc/xc_dom_x86.c (see SPECIALPAGE_*). > The other > thing is, the first 512 pages at the beginning of the address space are > mapped linearly, which usually leads to them being mapped as a single > 2MB pages. But there is this one page at 0x00001000 that sticks out > completely. By that I mean (to make things more concrete), in my PVH > guest the page at 0x00000000 maps to 0x13C200000, 0x00002000 maps to > 0x13C202000, 0x00003000 maps to 0x13C203000, etc. But 0x00001000 maps > to 0xB8DBD000, which seems very odd to me (at least from simply looking > at the addresses). Are you booting some OS on the guest before dumping the memory map? Keep in mind guest have the ability to modify the physmap, either by mapping Xen shared areas (like the shared info page) or just by using ballooning in order to poke holes into it (which can be populated later). It's either that or some kind of bug/missoptimization in meminit_hvm (also part of tools/libxc/xc_dom_x86.c). Can you check if this 'weird' mapping at 0x1000 is also present if you boot the guest with 'xl create -p foo.cfg'? (that will prevent the guests from running, so that you can get the memory map before the guest has modified it in any way). > My initial guess was that this is some bootloader > related stuff, but Google didn't show up any info related to that > memory area, and most of the x86/PC boot stuff seems to happen below > the 0x1000 mark. If you are booting with pygrub there's no bootloader at all, so whatever is happening is either done by the toolstack or the OS you are loading. Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 09:18:39 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 09:18:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jppvs-000121-Sm; Mon, 29 Jun 2020 09:18:32 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jppvr-00011w-Qo for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 09:18:31 +0000 X-Inumbo-ID: 7f5f88cc-b9e9-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7f5f88cc-b9e9-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 09:18:30 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: Gops3C6MoK9J4gyVt+TOqkXzFtEi5y8r6+SMR7bjP+umfku0oy+dntbembZZIkF5JWhiCXnfbG yk58cnbnxrSsQAx3U3idyNz0eMy1Fwu2hUreU1krbTWtLxk0Bi4qvaC7EMbI+9nr6uRbWPBfux Dwda0DiI20CI4suE2DznoAE/DgMh18voaRrEndgV/7wiXncxpC5JpYgS2WzUOu5mQ/mdJ+auVb CaFI25F1RXJAAb8Xxa2MUpC3s8H0d1vjzxaYcJD8xfI33Xkuj58d7uQUpnLWGb0booepDXM503 VTE= X-SBRS: 2.7 X-MesageID: 21149344 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21149344" Date: Mon, 29 Jun 2020 11:18:23 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Ruh Subject: Re: Kernel requires x86-64 CPU, after modifying arch_shared_info struct Message-ID: <20200629091823.GF735@Air-de-Roger> References: <6f88fc3e2795436fa1f30dd026dd8eda@tttech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <6f88fc3e2795436fa1f30dd026dd8eda@tttech.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 29, 2020 at 07:43:43AM +0000, Jan Ruh wrote: > Hi Xen Dev Community, > > > I ran into an issue when implementing a prototype for a new > paravirtualized clock for x86-64 hosts. I extended the > arch_shared_info struct by 6 fields totaling at 36 bytes. I updated > the xen-foreign/references.size to represent the new size of the > arch_shared_info struct. The fields are correctly updated in Xen and > I am also able to read the correct information stored from dom0. > However, if I try to start a hvm VM with pvh extensions it does not > boot telling me that "This kernel requires an x86-64 CPU, but only > detected an i686 CPU.". Did you try backing up your changes and seeing if the same happens? Did you rebuild both the Xen hypervisor and the tools? > I have rebuild my Linux domU kernel just as > the dom0 kernel and everything should be compatible. To me this > looks like Xen or libxc does some compatibility checks before > booting up my HVM domU and decides to downgrade the detectable CPU > due to some issue that I am not aware of. Do I miss something? Pasting your xl config file would be helpful in order to help debug. > Is my > approach to extend the arch_shared_info wrong in the first place? Doesn't look directly related to a change in arch_shared_info IMO, but it's hard to tell without having more info. Posting your changes might also help spot something wonky. > CONFIDENTIALITY: The contents of this e-mail are confidential and > intended only for the above addressee(s). If you are not the > intended recipient, or the person responsible for delivering it to > the intended recipient, copying or delivering it to anyone else or > using it in any unauthorized manner is prohibited and may be > unlawful. If you receive this e-mail by mistake, please notify the > sender and the systems administrator at straymail@tttech.com > immediately. Nit: posting confidentiality banners to a public mailing lists messages is kind of award, as the emails are publicly available for anyone to read, even those that are not recipients of xen-devel, ie: https://lists.xenproject.org/archives/html/xen-devel/2020-06/msg01868.html Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 09:32:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 09:32:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpq9g-0002cQ-9i; Mon, 29 Jun 2020 09:32:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpq9e-0002cL-Py for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 09:32:46 +0000 X-Inumbo-ID: 7d32c12a-b9eb-11ea-8547-12813bfff9fa Received: from esa5.hc3370-68.iphmx.com (unknown [216.71.155.168]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 7d32c12a-b9eb-11ea-8547-12813bfff9fa; Mon, 29 Jun 2020 09:32:46 +0000 (UTC) Authentication-Results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 7f2vnpZmjRwk/HVS9W+BG0B0Tq+jpbz9Prj9My3XhZae0f8a3E9rAmqo62Z2TF/P6VIUHZaQ02 bL1yD21I1aY6Hu5ZCaNGye9c7qEMmbrS8B/zTEinjLgzrzpj19Pyb12WWyL4wGRxINeLUtDhuK WjPLXsARwtpXWTtNvdrgp3qLQdpAk33tyByjheW7ZHpWIJxxYh7X7YHdiM4jZ73LM9CxxqZGqg 4+OQPQ3Ei/g1hQQ4oRb6r8pJ8thfqamPDErCxdKvFmUDmquQvEFUjukWEATjyBHZNW+nMP/zBR vuI= X-SBRS: 2.7 X-MesageID: 21370894 X-Ironport-Server: esa5.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21370894" Date: Mon, 29 Jun 2020 11:32:39 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Trevor Bentley Subject: Re: Suspend/hibernate not working on Dell XPS 15 9500 laptop Message-ID: <20200629093239.GG735@Air-de-Roger> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sat, Jun 27, 2020 at 08:35:27AM +0000, Trevor Bentley wrote: > I asked on #xen on Freenode and was requested to post here. > > Summary: Under Xen, both suspend and hibernate operations put the laptop > into some sort of unrecoverable low-power mode, and a force power-off is > required. > > Environment: > - Dell XPS 15 9500, BIOS 1.0.1 (this is a new 2020 model) > - Intel i7-10750H > - Intel i915 + Nvidia GTX 1650 Ti Mobile > - Arch linux (clean install) > - Linux kernels 5.7.5, 5.7.6 tested > - i915 driver loaded, no nvidia drivers loaded (nouveau blacklisted) > - Xen 4.13.1, 4.14.0-rc3 tested > - UEFI, GRUB2 bootloader, LUKS-encrypted /boot, /root, and swap > (unencrypted /efi with GRUB stub loader) Completely a shot in the dark, but have you tried with legacy boot (BIOS) instead of UEFI? To try to rule out what might cause the issues. Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 09:40:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 09:40:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqGw-0003TV-35; Mon, 29 Jun 2020 09:40:18 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqGu-0003Sh-Fz for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 09:40:16 +0000 X-Inumbo-ID: 864ab9e2-b9ec-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 864ab9e2-b9ec-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 09:40:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mLaUlBOyC8XzeSahLQNWisU8sIm0qqyJPJdmoFomgo4=; b=lXNfx3Cxxq63gGYfAhtlOsBTs gT3FUN1u601WImtn5XvN7cEoMD10AgxkszVLPOPMU2nirvYOEhMnobT/M5ecopUvL18Ko+C68u4mO bGi5H+jkKEunmY70k96I8i2QfaCm1kyntXcq1a6hANMkoKeSqCVPeDGWED6FRC8nXVd5g=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqGn-00081c-Vq; Mon, 29 Jun 2020 09:40:10 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpqGn-0007Qw-Mj; Mon, 29 Jun 2020 09:40:09 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpqGn-0001Oq-Lm; Mon, 29 Jun 2020 09:40:09 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151444: all pass - PUSHED X-Osstest-Versions-This: ovmf=0060e0a694f3f249c3ec081b0e61287c36f64ebb X-Osstest-Versions-That: ovmf=654dc3ed852aafa126e9d539b7002db348dd6eb0 From: osstest service owner Date: Mon, 29 Jun 2020 09:40:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151444 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151444/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0060e0a694f3f249c3ec081b0e61287c36f64ebb baseline version: ovmf 654dc3ed852aafa126e9d539b7002db348dd6eb0 Last test of basis 151401 2020-06-27 09:09:22 Z 2 days Testing same since 151444 2020-06-29 02:39:29 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Dong, Eric Eric Dong jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 654dc3ed85..0060e0a694 0060e0a694f3f249c3ec081b0e61287c36f64ebb -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Mon Jun 29 09:42:01 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 09:42:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqIa-0003Yd-EL; Mon, 29 Jun 2020 09:42:00 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqIZ-0003YU-B9 for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 09:41:59 +0000 X-Inumbo-ID: c6704582-b9ec-11ea-8496-bc764e2007e4 Received: from mail-lj1-x231.google.com (unknown [2a00:1450:4864:20::231]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c6704582-b9ec-11ea-8496-bc764e2007e4; Mon, 29 Jun 2020 09:41:58 +0000 (UTC) Received: by mail-lj1-x231.google.com with SMTP id 9so17254031ljc.8 for ; Mon, 29 Jun 2020 02:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yubico.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wNrpK7hVjJqj+NTq27Ygcyi06KkXeW4tOpFnlf1BjXs=; b=fRCmhhWjVYKIqVJj4tazme91amg+JXim7J6Ifsn0BhWyEstV9tof79cBxTd99xpDdi qR2ZzXzMPEtc0b3fS+1dnyIGt1fqF0bUZp0idfCSxZTxXmkbSAFTFkUkgBS1tKTmdFOK ZcF3yUo3+0El33BsYXkPMZuBv1CHFPB9VbO+FCgMUYTabqTH4vpGOaAdKSPjQ1z/1a1S 5zKrhk/vIQo+cvvDYtvNqw3vg3x7LUEycoMsXY2iwqOtpPPs7HDkqzAmodUYxppplF9r lr0UUfrCetwMg6QcpqFaFftLN8ZKy0sIKAJZEtZf73c6CANEfzrTnEUjL/AQV6Y2DvJb nbEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=wNrpK7hVjJqj+NTq27Ygcyi06KkXeW4tOpFnlf1BjXs=; b=ljVENrfmgD9VXz/yMC4HuDOuXeJ6ubpqyv5C56Cd0mXYcNK7PRczbr10DVylzVzERb lNMhSca/i3IWab/AHmkOzV/CtoohxFB/Uq/OwFJVAinsrW6ogW2zA7bEKBXsHa3c2Jbt P1FO4dOGuNxH9mkTrnpl7ViW+5mFbzMwPt0Mn0BydV72tee8ZSP6AFB7uygSbE3misXT cG9eCUHiaC4eBN1hcbvyXr2EG/KNaf5i5SjrQPTfkCLgFjtWgXqaPjWqRkITukoNaT5C OStWLyPqhCS6zUa7lFPxrzJDoLSPRTx2Q2/I83LRmyEVfzglQVXf4E4vWIEKG/MomK2W wVFA== X-Gm-Message-State: AOAM5333h6+UesTrxXlGV+YqGOp23YVUo56rY7eYCh5Sk2uQgJTOanMx Ycu3FzEQD4l0aZDeuQvL2gKLAVFOCmai/H4eBYHdUt4n047cy9VFsnEZ+p5vDlHOpS11TlsJVuj c2ClVAFnjN4P3tG9LhkN1vu8b8nWhCgPyxoS7AoNQAhUvP3uTVZ+7rleo2ChJE8AE7WyRjTSZJg == X-Google-Smtp-Source: ABdhPJyrdtYXJJJKT2H9qdGWiFqoh3E3gg1jZhN4dSa76Qcsxk8GtHTY7YXV9Fm9Q8g1akTYByblPw== X-Received: by 2002:a2e:97d8:: with SMTP id m24mr7740949ljj.166.1593423717266; Mon, 29 Jun 2020 02:41:57 -0700 (PDT) Received: from apple-IIe.local (c188-151-193-98.bredband.comhem.se. [188.151.193.98]) by smtp.gmail.com with ESMTPSA id 132sm9007023lfl.37.2020.06.29.02.41.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2020 02:41:56 -0700 (PDT) Subject: Re: Suspend/hibernate not working on Dell XPS 15 9500 laptop To: Jan Beulich References: <3d49bf4a-d82d-36d3-863c-e954d751b959@suse.com> From: Trevor Bentley Message-ID: <145d7f2e-cc62-740e-7f90-cd759c2aa76b@yubico.com> Date: Mon, 29 Jun 2020 11:41:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:75.0) Gecko/20100101 Thunderbird/75.0 MIME-Version: 1.0 In-Reply-To: <3d49bf4a-d82d-36d3-863c-e954d751b959@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > I don't suppose you have a serial port on this laptop? I ask because > the serial log (and the possibility to issue debug keys) are about > the only thing debugging-wise that may help here, short of someone > noticing the underlying problem by code inspection. Afraid not, it's hyper-modern; just 3 USB-C ports. It looks like identical hardware in the Dell Precision 5550 model, in case anybody gets access to either and wants to test. > Do you have any indication of the laptop at least partly waking up > again, e.g. from some LED or other indicator activity? None at all, no. Could be missing the keyboard events entirely, or getting them and failing to wake. I've tried built-in keyboard, external keyboard, and closing/opening the lid. When using the /sys/power/pm_test commands, does that actually do anything in a Xen environment, or is that being consumed by dom0 and not triggering the real VMM low-power paths? Is there any similar debug mechanism for the hypervisor? Let me know if there is any useful information I can extract. I'm happy to build patched kernels if it will help. Thanks, -Trevor From xen-devel-bounces@lists.xenproject.org Mon Jun 29 09:43:58 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 09:43:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqKI-0003go-Q9; Mon, 29 Jun 2020 09:43:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqKG-0003gg-Mo for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 09:43:44 +0000 X-Inumbo-ID: 054af5ea-b9ed-11ea-b7bb-bc764e2007e4 Received: from mail-lf1-x12c.google.com (unknown [2a00:1450:4864:20::12c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 054af5ea-b9ed-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 09:43:44 +0000 (UTC) Received: by mail-lf1-x12c.google.com with SMTP id c11so8698262lfh.8 for ; Mon, 29 Jun 2020 02:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yubico.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rvG7s+jucVSNCaXdvIkIcodl8tXal4e6UXtqml8xF4c=; b=lirGeECQnn9CHcXsCZI+WDUP0yZZ1PM5dHOvZc3tSYXbYvM48Q9PwsGoThIQ+/MjFY OVtAu9tIoUU0BPkZGAfoM3dWPda6KXAppMoTMregZCuUvlbInGej62Tl6hH+/xFW3nM3 DNZfafwyafHg9owiZ1ZJpkd7JBmq6nL+vdXqZ7WYJRgV4rmCQCm24VxrenNsVb3Wk4SX EBSw2gzcaLzMpHg+wPQGoDX/FTX+cjFR5dr/XBzzJL1yuYT3fjO3HriZl/4VN7oO095e /9gOXKCr7z/r8f/X/5GHIHsfNeexRxE+15wBP0sx2x0TOWttb7EPoA1mChpXBLzNjpU3 Snng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rvG7s+jucVSNCaXdvIkIcodl8tXal4e6UXtqml8xF4c=; b=fG9zK7vCLXmGQxPWb9D1GDXor6RNbUBz700g30O4E8NmwIJ5TW0nfNuLMgTknrV1ug FIM2L0lK9tZLJ4b5TzNCmapoxu2FonJPTZ1YdbxU6gEMfW3Sb9OEvZ1f7XjhfS9LkT8p 0Rk4IbufW2znK5yIioAQcpDvRVZE1YQdjQUKu7cWpjiNs1bwtbxcly+9M+qFaHZF2kug 4qj5+uOO/JIj9vyvf2xPiLrrGq6KOUhLVupoj12RssVTxNqxNM1ALCpNON7Beq7YSCKN /eJRy7N9QLYA3fgyTBlHX8TnKyXCze35adU1b8JorJ9slSGWvxa/Ma7c4Hm5Vb9WdzE7 2u3g== X-Gm-Message-State: AOAM531grCn9fgErDEwm9YTAyfS1bBiPadcXek635nr8FSkixullz395 G+2cVOzzwlRcDiWG3YKUuRB1TnkLgi4V5Da4U9g+h46CPxW4TyC1Px6o0z9MCRrTqCB51d3Zbex baaDmw8EdzZ7b25R4pSF5Oi0EUGphlAdTPbYV+lLg/+Sl1g0b3q6I1wdQwpxfvKQjEWjqnPCvQQ == X-Google-Smtp-Source: ABdhPJwYUw+TD24ZDIdLkunOi4TucBqziHpLfZLla8iE4gPbIWui8B1rafwFVfl69cleARz3CX4rEw== X-Received: by 2002:ac2:5f0b:: with SMTP id 11mr8749749lfq.201.1593423822940; Mon, 29 Jun 2020 02:43:42 -0700 (PDT) Received: from apple-IIe.local (c188-151-193-98.bredband.comhem.se. [188.151.193.98]) by smtp.gmail.com with ESMTPSA id v19sm2688739lfi.65.2020.06.29.02.43.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2020 02:43:42 -0700 (PDT) Subject: Re: Suspend/hibernate not working on Dell XPS 15 9500 laptop To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <20200629093239.GG735@Air-de-Roger> From: Trevor Bentley Message-ID: <774fff18-55a5-259a-0fbf-fefb2f8969fc@yubico.com> Date: Mon, 29 Jun 2020 11:43:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:75.0) Gecko/20100101 Thunderbird/75.0 MIME-Version: 1.0 In-Reply-To: <20200629093239.GG735@Air-de-Roger> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > Completely a shot in the dark, but have you tried with legacy boot > (BIOS) instead of UEFI? To try to rule out what might cause the > issues. From the BIOS: "Legacy Boot mode is not supported on this platform." This is my punishment for buying a brand new laptop model for Linux... -Trevor From xen-devel-bounces@lists.xenproject.org Mon Jun 29 09:53:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 09:53:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqTb-0004Zu-O5; Mon, 29 Jun 2020 09:53:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqTa-0004Zp-Sj for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 09:53:22 +0000 X-Inumbo-ID: 5b1f4fce-b9ee-11ea-854b-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 5b1f4fce-b9ee-11ea-854b-12813bfff9fa; Mon, 29 Jun 2020 09:53:17 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 6A2DAA32E7; Mon, 29 Jun 2020 11:53:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 54AB9A32ED; Mon, 29 Jun 2020 11:53:15 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CDJxFrooTXtx; Mon, 29 Jun 2020 11:53:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id C950CA331E; Mon, 29 Jun 2020 11:53:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OvJY6IZn5EmD; Mon, 29 Jun 2020 11:53:14 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 9CC2DA32F7; Mon, 29 Jun 2020 11:53:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 86A1B217A8; Mon, 29 Jun 2020 11:52:44 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id VgWou8LoNQDX; Mon, 29 Jun 2020 11:52:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 1192C22384; Mon, 29 Jun 2020 11:52:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YAP54UhC_FmH; Mon, 29 Jun 2020 11:52:38 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id DE19322200; Mon, 29 Jun 2020 11:52:38 +0200 (CEST) Date: Mon, 29 Jun 2020 11:52:38 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Andrew Cooper Message-ID: <1499783228.15242029.1593424358779.JavaMail.zimbra@cert.pl> In-Reply-To: <250cd39e-aa51-5397-93f9-b863e4f51269@citrix.com> References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> <97440747.11443782.1592849498089.JavaMail.zimbra@cert.pl> <250cd39e-aa51-5397-93f9-b863e4f51269@citrix.com> Subject: Re: [PATCH v3 4/7] x86/vmx: add do_vmtrace_op MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add do_vmtrace_op Thread-Index: AjJbiO0gwAzlAbg4i2xQMtSXSUVSjA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , Julien Grall , Jun Nakajima , Wei Liu , Tamas K Lengyel , Ian Jackson , George Dunlap , "Kang, Luwei" , Jan Beulich , xen-devel@lists.xenproject.org, Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 23 cze 2020 o 13:54, Andrew Cooper andrew.cooper3@citrix.com napisa= =C5=82(a): > Overall, the moving parts of this series needs to split out into rather > more patches. >=20 > First, in patch 3, the hvm_funcs.pt_supported isn't the place for that > to live.=C2=A0 You want a global "bool vmtrace_supported" in common/domai= n.c > which vmx_init_vmcs_config() sets, and the ARM code can set in the > future when CoreSight is added. >=20 > Next, you want a patch in isolation which adds vmtrace_pt_size (or > whatever it ends up being) to createdomain, where all > allocation/deallocation logic lives in common/domain.c.=C2=A0 The spinloc= k > (if its needed, but I don't think it is) wants initialising early in > domain_create(), alongside d->pbuf_lock, and you also need an extra > clause in sanitise_domain_config() which rejects a vmtrace setting if > vmtrace isn't supported.=C2=A0 You'll need to put the struct page_info * > pointer to the memory allocation in struct vcpu, and adjust the vcpu > create/destroy logic appropriately. >=20 > Next, you want a patch doing the acquire resource logic for userspace to > map the buffers. >=20 > Next, you want a patch to introduce a domctl with the various runtime > enable/disable settings which were in an hvmop here. >=20 > Next, you want a patch to do the VMX plumbing, both at create, and runtim= e. >=20 > This ought to lay the logic out in a way which is extendable to x86 PV > guests and ARM CoreSight, and oughtn't to explode when creating guests > on non-Intel hardware. >=20 > Thanks, >=20 > ~Andrew Thanks for your review, I'm almost done addressing all these remarks. I've converted HVMOP to DOMCTL and splitted patches to smaller pieces. I will send v4 soon. Best regards, Micha=C5=82 Leszczy=C5=84ski From xen-devel-bounces@lists.xenproject.org Mon Jun 29 09:56:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 09:56:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqWw-0004iG-80; Mon, 29 Jun 2020 09:56:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqWv-0004iA-30 for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 09:56:49 +0000 X-Inumbo-ID: d6ac513c-b9ee-11ea-854b-12813bfff9fa Received: from mail.tttech.com (unknown [217.19.35.52]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d6ac513c-b9ee-11ea-854b-12813bfff9fa; Mon, 29 Jun 2020 09:56:45 +0000 (UTC) IronPort-SDR: 8jW9NScFxqx3q9NYF46JfkCa2W12ZRogXHWjHoTGxN5/f0RUMbst2Gq2dMf2PF5lTNuW07dpSV 6+J201Dp43Kz1ij9SwR4YpNztK883DnFNzC8UMEz+snGrrfpNM/ohTBrT3vhFbM3f9HOrB9+Zb 5PYdRNQWkXyyICn/ldWr0+4iR6m7eNyuQUDlCkoC50pdULKEYiPl4AC8/phASsxYmYQw9YbeJ+ ED/BIqGT5sge/UTxtUR/cx50PQPkAQOCdUevW2xeEFHIHde0FKLUmVOkImopVznGLY8LClqvqg 9go= X-IronPort-AV: E=Sophos;i="5.75,294,1589234400"; d="scan'208";a="9449211" Received: from unknown (HELO mail.tttech.com) ([10.108.0.226]) by mail-int.tttech.com with ESMTP; 29 Jun 2020 11:56:44 +0200 Received: from EXVIE02.ds1.internal (10.108.0.226) by EXVIE02.ds1.internal (10.108.0.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 29 Jun 2020 11:56:43 +0200 Received: from EXVIE02.ds1.internal ([fe80::4ccf:d313:b2a8:c054]) by EXVIE02.ds1.internal ([fe80::4ccf:d313:b2a8:c054%6]) with mapi id 15.01.1913.007; Mon, 29 Jun 2020 11:56:43 +0200 From: Jan Ruh To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: AW: Kernel requires x86-64 CPU, after modifying arch_shared_info struct Thread-Topic: Kernel requires x86-64 CPU, after modifying arch_shared_info struct Thread-Index: AQHWTehUS5L/6eMJQEyE2773H88H5KjvLyGAgAAjyHY= Sensitivity: personal Date: Mon, 29 Jun 2020 09:56:43 +0000 Message-ID: References: <6f88fc3e2795436fa1f30dd026dd8eda@tttech.com>, <20200629091823.GF735@Air-de-Roger> In-Reply-To: <20200629091823.GF735@Air-de-Roger> Accept-Language: de-DE, en-GB, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.102.6.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > Did you try backing up your changes and seeing if the same happens? If backing up my changes everything works as expected. > Did you rebuild both the Xen hypervisor and the tools? Yes, I rebuild both Xen hypervisor and the tools. > Pasting your xl config file would be helpful in order to help debug. As requested my xl config: type=3D"hvm"; extra=3D"console=3Dhvc0 earlyprintk=3Dxen"; kernel=3D"/usr/lib/kernel/vmlinuz-domu"; ramdisk=3D"/usr/lib/kernel/initrd.img-domu"; root=3D"/dev/xvda2 ro"; memory=3D1024; autoballoon=3D"off"; xen_platform_pci=3D1; pae=3D1; acpi=3D1; apic=3D1; vcpus=3D1; name=3D"vm1"; disk=3D["file:domu.img,hda,w"]; vif=3D["bridge=3Dxenbr0"]; vfb=3D["type=3Dvnc,keymap=3Dde"]; vnclisten=3D"192.168.2.4:0"; boot=3D"c";' > Posting your changes might also help spot something wonky. diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x8= 6/xen.h index 629cb2ba40..61c46504a5 100644 --- a/xen/include/public/arch-x86/xen.h +++ b/xen/include/public/arch-x86/xen.h @@ -265,6 +265,14 @@ struct arch_shared_info { /* There's no room for this field in the generic structure. */ uint32_t wc_sec_hi; #endif + + uint32_t st_version; + uint64_t time_sec; + uint64_t time_nsec; + uint64_t cycle_last; + uint32_t mult; + uint32_t shift; + }; typedef struct arch_shared_info arch_shared_info_t; diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c index c39fbe50a0..2782cb5127 100644 --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -1254,15 +1254,15 @@ void update_domain_synctime(struct domain *d) { uint32_t *st_version; + st_version =3D &shared_info(d, arch.st_version); *st_version =3D version_update_begin(*st_version); smp_wmb(); + shared_info(d, arch.mult) =3D global_time.mult; + shared_info(d, arch.shift) =3D global_time.shift; + shared_info(d, arch.cycle_last) =3D global_time.cycle_last; + shared_info(d, arch.time_sec) =3D global_time.time_sec; + shared_info(d, arch.time_nsec) =3D global_time.time_nsec; smp_wmb(); *st_version =3D version_update_end(*st_version); diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index 72e7d33708..4b9ad0261b 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -503,22 +503,22 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u= _sysctl) } case XEN_SYSCTL_adjust_gtime: { + struct adjust_gtime *adjust_gtime =3D (struct adjust_gtime*) &op->= u.adjust_gtime; + ret =3D do_adj_gtime(adjust_gtime); + copyback =3D 1; break; diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-f= oreign/reference.size index bb2ada32fb..9afd11e5fa 100644 --- a/tools/include/xen-foreign/reference.size +++ b/tools/include/xen-foreign/reference.size @@ -9,6 +9,6 @@ vcpu_guest_context | 344 344 2800 5168 arch_vcpu_info | 0 0 24 16 vcpu_time_info | 32 32 32 32 vcpu_info | 48 48 64 64 -arch_shared_info | 0 0 28 48 +arch_shared_info | 0 0 64 88 global_time is a static struct in time.c, no existing Xen code is changed, = just functions added that are being called from the sysctl adjust_gtime. Further tests show that in /tools/libxc/xc_dom_binloader.c: xc_dom_parse_bi= n_kernel xc sets the dom->guest_type to "xen-3.0-x86_32" instead of "xen-3.= 0-x86_64". I also cannot see though how it can be connected to my change to= arch_shared_info. Sorry for the banner, I always forget that the mail client adds that thing,= I hope it doesn't do it again. Jan CONFIDENTIALITY: The contents of this e-mail are confidential and intended = only for the above addressee(s). If you are not the intended recipient, or = the person responsible for delivering it to the intended recipient, copying= or delivering it to anyone else or using it in any unauthorized manner is = prohibited and may be unlawful. If you receive this e-mail by mistake, plea= se notify the sender and the systems administrator at straymail@tttech.com = immediately. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 09:57:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 09:57:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqXr-0004nD-LP; Mon, 29 Jun 2020 09:57:47 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqXq-0004n8-Fn for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 09:57:46 +0000 X-Inumbo-ID: fa9246ec-b9ee-11ea-bb8b-bc764e2007e4 Received: from mout.web.de (unknown [212.227.15.3]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fa9246ec-b9ee-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 09:57:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1593424664; bh=ZQbDvPXnFTZF0piKJJKk8yHV984e1gtyOn4pTVggaLk=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=LBE88t96i/Gk0zueBGtg3yZtEBlhtpEgz4b/dG6ZeXOurcppLL6J2fWE5gA/s0uel KbEoDZEkmq/EjN9NmSBC02uSkMR9pnvmZnJRLaKkdkXe6K0FG7/BYnA0dvbix8SLm8 76LMCuSXZsE0ZKpTilqCYDU6Eip+J8Ux4kA49xUg= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [79.201.81.46] ([79.201.81.46]) by web-mail.web.de (3c-app-webde-bs30.server.lan [172.19.170.30]) (via HTTP); Mon, 29 Jun 2020 11:57:43 +0200 MIME-Version: 1.0 Message-ID: From: joshua_peter@web.de To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Subject: Aw: Re: Questions about PVH memory layout Content-Type: text/plain; charset=UTF-8 Date: Mon, 29 Jun 2020 11:57:43 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <20200629085758.GE735@Air-de-Roger> References: <20200629085758.GE735@Air-de-Roger> Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:wHaBkn4x47uyB+TSXlHaBfdcH/o41086w8iOhSpoxSLCqkO4FmqrVWeu4IOQFfeI1q1x/ XDxppZ6R+2uitgMnkJJUZClhlHpVH9ZMoDjHjC7LzDw42Zm4aKaAtB5WoSPCkvQaVfVjkqX5r3WQ 5vIVxW0Xk61ScduwA55/i/+9s+FIVhjtM2G20NX/fAclPsNyDurEj4UcnAl9nuq0lI0Aqu7EBsm6 +favt9GJfwlcx0n5uMx4LbQBdjALJr0sHbOLUD/2+PjZ/bV7E/RG25EjLRBeyHQfE6KSlD4NLxQR ZI= X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:SLQln+3Toao=:2rlSCgt25VFEwEDSPIr4VC 6a6cBrYNz86IpCofQpsIThgzVsDrwNOAoPv2hFtlWevm7W0BmPBNCuS8fDjKUhMsxLPWhEeBV KqSNegLGG4K0ih0wAU6zfgTsIuNuYBh4fzQBHM3FN7apRXOwECrAy8AfHYAN4EAqqZ+xc4dPU 2evCJLAUGHBDY1TOENWP6UA3d4t12rjch6rx8aqwlz2PWrM3np3zE8fXLLETamhYtWeC4lKCl E8jGZ6ZQ1pm42aEYvvOl+oUabml52kTQX7LCwR9uwWRAzFKGGbnEiV3Oe6+QClRcKCFIm+eIp WjoPbxxDump0JbKG++avMF+MTzpZbCO7MTZgJ54EHIVKMuv9zJovtNaFKCLHXUvvOk30EIx/7 6YCBHASj/Y6uUzlZPpXyo9DCnQgHqXjNOmvBYkdWlC/kyuKVSgFhV84TPt5M7f9/9nlmprTTZ pSzGe1D681V1c9UyYCEsOuhEoNROsPAe0dEGw/0N1tH5pRZNIpwqln37eE7JcHAeo25UK+M3J SSBNvfZJUFgCzK7AGawvIhgOX+7geXw2m3UjPQ+ozVfVEGqMR/8FTLwxDBHaYdidcuMGQRfnj 4wcI6D2OQwhso2u4rkXId+iHollGgLUIkQE7/DL0vDNC1J2/Qw9Pye0ZX3/9U0se4mIFo4/hM 6QoDY0O4RyjPC3oadmCKj1RpGCjpDRlskosGuBjkbhQCXU2AR0d1fPfNkR/xaJ5AKugo= X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Roger, thank you very much for your help=2E Further replies are inline=2E > Gesendet: Montag, 29=2E Juni 2020 um 10:57 Uhr > Von: "Roger Pau Monn=C3=A9" > An: joshua_peter@web=2Ede > Cc: xen-devel@lists=2Exenproject=2Eorg > Betreff: Re: Questions about PVH memory layout > > > The other > > thing is, the first 512 pages at the beginning of the address space ar= e > > mapped linearly, which usually leads to them being mapped as a single > > 2MB pages=2E But there is this one page at 0x00001000 that sticks out > > completely=2E By that I mean (to make things more concrete), in my PVH > > guest the page at 0x00000000 maps to 0x13C200000, 0x00002000 maps to > > 0x13C202000, 0x00003000 maps to 0x13C203000, etc=2E But 0x00001000 map= s > > to 0xB8DBD000, which seems very odd to me (at least from simply lookin= g > > at the addresses)=2E >=20 > Are you booting some OS on the guest before dumping the memory map? > Keep in mind guest have the ability to modify the physmap, either by > mapping Xen shared areas (like the shared info page) or just by using > ballooning in order to poke holes into it (which can be populated > later)=2E It's either that or some kind of bug/missoptimization in > meminit_hvm (also part of tools/libxc/xc_dom_x86=2Ec)=2E Yes, my bad=2E I'm booting into Arch Linux=2E This must have been lost whi= le I was editing my e-mail=2E > Can you check if this 'weird' mapping at 0x1000 is also present if you > boot the guest with 'xl create -p foo=2Ecfg'? (that will prevent the > guests from running, so that you can get the memory map before the > guest has modified it in any way)=2E Yeah, starting with the "-p" flag does get rid of this 'weird' mapping=2E Thank you again=2E This cleared up a bunch of things=2E Best regards, Peter From xen-devel-bounces@lists.xenproject.org Mon Jun 29 10:03:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 10:03:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqdH-0005jl-A6; Mon, 29 Jun 2020 10:03:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqdF-0005jg-Pj for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 10:03:21 +0000 X-Inumbo-ID: c321ac2e-b9ef-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c321ac2e-b9ef-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 10:03:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=BQCbqN241aUGsgEpIIA3+aoPRYMEiJtybB+TOdPY77Y=; b=fXinA4+9+Axz3zZ95lwNQ6bb7B NkAxzJOPihD3pvaupiz3erPZMN4mZCFHrffFg1pcLmwKMCZEuxKmsdbvT9BBQF7E4YSgVXQN+Rd1C ssGP833xAMeeY1+DQkiydHevRnO2dryfhQCBjZGhuY7yucJpZNGSPR9eHzQlgM8CB8GI=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqdD-00006S-3q; Mon, 29 Jun 2020 10:03:19 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jpqdC-0006Au-SJ; Mon, 29 Jun 2020 10:03:19 +0000 Subject: Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches To: Jan Beulich References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-3-julien@xen.org> <9fc81bbe-6c30-e848-ceae-1356ec30a8f8@suse.com> From: Julien Grall Message-ID: <11dad2fc-b1ec-3279-1a99-920a5f67456a@xen.org> Date: Mon, 29 Jun 2020 11:03:16 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <9fc81bbe-6c30-e848-ceae-1356ec30a8f8@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Jan, On 29/06/2020 09:28, Jan Beulich wrote: > On 27.06.2020 11:55, Julien Grall wrote: >> From: Julien Grall >> >> The specification of pvcalls suggests there is padding for 32-bit x86 >> at the end of most the structure. However, they are not described in >> in the public header. >> >> Because of that all the structures would be 32-bit aligned and not >> 64-bit aligned for 32-bit x86. > > The added padding doesn't change the alignment. It's sizeof() which > gets corrected this way. I will update the commit message. > >> For all the other architectures supported (Arm and 64-bit x86), the >> structure are aligned to 64-bit because they contain uint64_t field. >> Therefore all the structures contain implicit padding. >> >> Given the specification is authoriitative, the padding will the same for > > Nit: ... will be the same ... Ok. > >> the all architectures. The potential breakage of compatibility is ought > > Nit: Drop "is". Ok. >> to be fine as pvcalls is still a tech preview. >> >> As an aside, the padding sadly cannot be mandated to be 0 as they are >> already present. So it is not going to be possible to use the padding >> for extending a command in the future. > > Why is the other adjustment fine to make due to still being tech > preview, but this one wouldn't be for the same reason? This is mostly a left-over of the previous message. Although, I am not really inclined to address this myself any time soon. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jun 29 10:17:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 10:17:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqr4-0006g8-MT; Mon, 29 Jun 2020 10:17:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpqr3-0006g3-Eg for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 10:17:37 +0000 X-Inumbo-ID: c096cbe0-b9f1-11ea-8496-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c096cbe0-b9f1-11ea-8496-bc764e2007e4; Mon, 29 Jun 2020 10:17:36 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: FiMoakWGtd8Kau2qdBzZ1DZ2/uaSVxaB/dldtcmzNM4fC/HmhRFrhCr97QKZaNJblbdknTmebK BC4F8Y6QET5LuP4VuTbTG5Q6mIw8SoWPYJeVols0bNnxiVvzBDxvL3JRJqnEv5evdzqHzBC0Rt HQFXMO3DbPvLFmv4mZgSeEyHiBLJMPVQZwKYza2jP72rf7SerL0hWfdAhVp6canC0MEkjZR2tu 1fyFEuCQpNZTTS7xetcCM+cWUe+2H5ubRIBDrWZI42ARNwPequzFj3B16PMJ2YVcpuD7Rozf4/ gqg= X-SBRS: 2.7 X-MesageID: 21153121 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21153121" Date: Mon, 29 Jun 2020 12:17:28 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Ruh Subject: Re: Kernel requires x86-64 CPU, after modifying arch_shared_info struct Message-ID: <20200629101728.GH735@Air-de-Roger> References: <6f88fc3e2795436fa1f30dd026dd8eda@tttech.com> <20200629091823.GF735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 29, 2020 at 09:56:43AM +0000, Jan Ruh wrote: > > Did you try backing up your changes and seeing if the same happens? > > If backing up my changes everything works as expected. > > > Did you rebuild both the Xen hypervisor and the tools? > > Yes, I rebuild both Xen hypervisor and the tools. > > > Pasting your xl config file would be helpful in order to help debug. > > As requested my xl config: xl parser will just ignore the ';', you can remove them. > type="hvm"; extra="console=hvc0 earlyprintk=xen"; > kernel="/usr/lib/kernel/vmlinuz-domu"; > ramdisk="/usr/lib/kernel/initrd.img-domu"; > root="/dev/xvda2 ro"; > memory=1024; > autoballoon="off"; autoballoon is not a xl.cfg option. > xen_platform_pci=1; > pae=1; acpi=1; apic=1; All those are already enabled by default, no need to specify them here. > vcpus=1; > name="vm1"; > disk=["file:domu.img,hda,w"]; > vif=["bridge=xenbr0"]; > vfb=["type=vnc,keymap=de"]; > vnclisten="192.168.2.4:0"; > boot="c";' > > > Posting your changes might also help spot something wonky. > > diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h > index 629cb2ba40..61c46504a5 100644 > --- a/xen/include/public/arch-x86/xen.h > +++ b/xen/include/public/arch-x86/xen.h > @@ -265,6 +265,14 @@ struct arch_shared_info { > /* There's no room for this field in the generic structure. */ > uint32_t wc_sec_hi; > #endif > + > + uint32_t st_version; > + uint64_t time_sec; > + uint64_t time_nsec; > + uint64_t cycle_last; > + uint32_t mult; > + uint32_t shift; > + > }; > typedef struct arch_shared_info arch_shared_info_t; > > diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c > index c39fbe50a0..2782cb5127 100644 > --- a/xen/arch/x86/time.c > +++ b/xen/arch/x86/time.c > @@ -1254,15 +1254,15 @@ void update_domain_synctime(struct domain *d) This doesn't seem to exist in current Xen code, so I guess there are further changes applied here? > { > uint32_t *st_version; > > + st_version = &shared_info(d, arch.st_version); > *st_version = version_update_begin(*st_version); > smp_wmb(); > > + shared_info(d, arch.mult) = global_time.mult; > + shared_info(d, arch.shift) = global_time.shift; > + shared_info(d, arch.cycle_last) = global_time.cycle_last; > + shared_info(d, arch.time_sec) = global_time.time_sec; > + shared_info(d, arch.time_nsec) = global_time.time_nsec; > > smp_wmb(); > *st_version = version_update_end(*st_version); > > diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c > index 72e7d33708..4b9ad0261b 100644 > --- a/xen/common/sysctl.c > +++ b/xen/common/sysctl.c > @@ -503,22 +503,22 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) > } > case XEN_SYSCTL_adjust_gtime: > { > + struct adjust_gtime *adjust_gtime = (struct adjust_gtime*) &op->u.adjust_gtime; > > + ret = do_adj_gtime(adjust_gtime); Same with do_adj_gtime, I cannot find it in the current code, hence I'm afraid it's impossible to tell what it's actually doing. > + > copyback = 1; > > break; > > diff --git a/tools/include/xen-foreign/reference.size b/tools/include/xen-foreign/reference.size > index bb2ada32fb..9afd11e5fa 100644 > --- a/tools/include/xen-foreign/reference.size > +++ b/tools/include/xen-foreign/reference.size > @@ -9,6 +9,6 @@ vcpu_guest_context | 344 344 2800 5168 > arch_vcpu_info | 0 0 24 16 > vcpu_time_info | 32 32 32 32 > vcpu_info | 48 48 64 64 > -arch_shared_info | 0 0 28 48 > +arch_shared_info | 0 0 64 88 Aren't you missing a line below that contains the shared_info size, and that also need to be updated (since arch_shared_info is contained in shared_info)? > > > global_time is a static struct in time.c, no existing Xen code is changed, just functions added that are being called from the sysctl adjust_gtime. > > Further tests show that in /tools/libxc/xc_dom_binloader.c: xc_dom_parse_bin_kernel xc sets the dom->guest_type to "xen-3.0-x86_32" instead of "xen-3.0-x86_64". I also cannot see though how it can be connected to my change to arch_shared_info. Hm, I think guest type should be hvm-3.0-x86_32, as xen-* are PV guest types, and you are trying to boot a HVM guest. Anyway I'm not familiar with HVM direct kernel boot, so this might have no effect here. Are you sure the type is set to "xen-3.0-x86_64" prior to your changes? Maybe it would be worth to also paste the output of 'xl -vvv create ...'. > Sorry for the banner, I always forget that the mail client adds that thing, I hope it doesn't do it again. I'm afraid it's still appended to this email, see below. Roger. > CONFIDENTIALITY: The contents of this e-mail are confidential and > intended only for the above addressee(s). If you are not the > intended recipient, or the person responsible for delivering it to > the intended recipient, copying or delivering it to anyone else or > using it in any unauthorized manner is prohibited and may be > unlawful. If you receive this e-mail by mistake, please notify the > sender and the systems administrator at straymail@tttech.com > immediately. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 10:31:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 10:31:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpr4Y-0008Fx-Nv; Mon, 29 Jun 2020 10:31:34 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpr4X-0008Fs-Nh for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 10:31:33 +0000 X-Inumbo-ID: b34dd8e6-b9f3-11ea-854d-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b34dd8e6-b9f3-11ea-854d-12813bfff9fa; Mon, 29 Jun 2020 10:31:33 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: kCUloU30hnj9oHyFqiiI365g2eomIco5GQ9CRLHeuvAPmCpv65HJlZQthcNXRP2k2l3t2t6fAh sahjJxurJ9MDctR8NuvT78UcnY/dqrliDIfeTGlmrJ7oGEdQQFrH9SyC5lTrX9sEhKz99dyyQj gjAzntWnsh5jaqHRDxEbiPMc9l6f9c9KU1CFfuspNLgXOrcjS8P10qcAJSPMOxR/y3JctZq8ro 3+WNG42GU6UG9NdZjoSpoTReGykUb7LBPL/EK/My/PLblkbM+zMLq+n9v5wZxZbXOnkZ+h9SIG jE0= X-SBRS: 2.7 X-MesageID: 21467703 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21467703" From: Andrew Cooper To: Xen-devel Subject: [PATCH] x86/boot: Don't disable PV32 when XEN_SHSTK is compiled out Date: Mon, 29 Jun 2020 11:31:13 +0100 Message-ID: <20200629103113.9328-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Paul Durrant , Wei Liu , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" There is no need to automatically disable PV32 support on SHSTK-capable hardware if Xen isn't actually using the feature. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Wei Liu CC: Roger Pau Monné CC: Paul Durrant For 4.14. Minor bugfix. --- xen/arch/x86/setup.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index 2aa1cd50b8..c9b6af826d 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -95,7 +95,11 @@ unsigned long __initdata highmem_start; size_param("highmem-start", highmem_start); #endif +#ifdef CONFIG_XEN_SHSTK static bool __initdata opt_xen_shstk = true; +#else +#define opt_xen_shstk false +#endif static int __init parse_cet(const char *s) { -- 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 29 11:07:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 11:07:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprd1-0002QD-Dn; Mon, 29 Jun 2020 11:07:11 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprd0-0002Q8-HZ for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 11:07:10 +0000 X-Inumbo-ID: ac6f45f0-b9f8-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ac6f45f0-b9f8-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 11:07:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vkYybaPkHQh/pB4i/ZzXD8bkSxRjUd0R9BeTdRiCdPE=; b=ITqq+A7U6gCq30aJ60KqB/3NK ruUx4RqxZKNRrpvh52jzxoRQIak8uZHC2pA5aQLiHyrDovZ9jGZ+cqz8WShibhSKAPDyc5EzlnFsA LIsUzO1fv8GUWHWdAA7atYkUxW+oUtcNIc3sGmg5Fzn0In6il2Fv2l32SaqU+ChntpIec=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprcy-0001HM-4X; Mon, 29 Jun 2020 11:07:08 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jprcx-0001p5-RS; Mon, 29 Jun 2020 11:07:07 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jprcx-0004la-OX; Mon, 29 Jun 2020 11:07:07 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151441: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Mon, 29 Jun 2020 11:07:07 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151441 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151441/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 11 days Failing since 151236 2020-06-19 19:10:35 Z 9 days 11 attempts Testing same since 151441 2020-06-28 23:39:48 Z 0 days 1 attempts ------------------------------------------------------------ 468 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 22365 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 29 11:08:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 11:08:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprdw-0002Vm-RV; Mon, 29 Jun 2020 11:08:08 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprdv-0002UR-Ce for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 11:08:07 +0000 X-Inumbo-ID: cb96f734-b9f8-11ea-8550-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id cb96f734-b9f8-11ea-8550-12813bfff9fa; Mon, 29 Jun 2020 11:08:01 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: jRfbOdaUpIV5NuTDp9xgStPlFJ7H7FU9MkvbzFpf6SC+gjm1TCq/JlRMLcrC7UJAyIMPw89gJS eVqG7hgGVyCXEhehd/EmuVIEnOji1laX9+U6DlPOHnWFpCDzpSpeyOH0d8zzrcIGvO7xQHwgsP gi2SrcUOyubaHunpUUz+FhFEs966VAB/WiHbNGUCfdnOxx+HefctRE9q9UD7ZO7H7bgwYWaDMm N4lJ50WCn4F60J6BG2F2i+5cvSz64wE5F03LZqxfUBuFeQbFgaruwG+fYamMknztCeLiExj6Jt dMw= X-SBRS: 2.7 X-MesageID: 21469946 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21469946" Subject: Re: [PATCH fsgsbase v2 4/4] x86/fsgsbase: Fix Xen PV support To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Andy Lutomirski , References: <714d4c04-5907-885f-e23b-baef662f1080@suse.com> From: Andrew Cooper Message-ID: <9740c5ee-9072-b4f6-5b20-b609d42bf8bb@citrix.com> Date: Mon, 29 Jun 2020 12:07:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <714d4c04-5907-885f-e23b-baef662f1080@suse.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Sasha Levin , xen-devel@lists.xenproject.org, Boris Ostrovsky , Stefano Stabellini , linux-kernel@vger.kernel.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29/06/2020 06:17, Jürgen Groß wrote: > On 26.06.20 19:24, Andy Lutomirski wrote: >> On Xen PV, SWAPGS doesn't work.  Teach __rdfsbase_inactive() and >> __wrgsbase_inactive() to use rdmsrl()/wrmsrl() on Xen PV.  The Xen >> pvop code will understand this and issue the correct hypercalls. >> >> Cc: Boris Ostrovsky >> Cc: Juergen Gross >> Cc: Stefano Stabellini >> Cc: xen-devel@lists.xenproject.org >> Signed-off-by: Andy Lutomirski >> --- >>   arch/x86/kernel/process_64.c | 20 ++++++++++++++------ >>   1 file changed, 14 insertions(+), 6 deletions(-) >> >> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c >> index cb8e37d3acaa..457d02aa10d8 100644 >> --- a/arch/x86/kernel/process_64.c >> +++ b/arch/x86/kernel/process_64.c >> @@ -163,9 +163,13 @@ static noinstr unsigned long >> __rdgsbase_inactive(void) >>         lockdep_assert_irqs_disabled(); >>   -    native_swapgs(); >> -    gsbase = rdgsbase(); >> -    native_swapgs(); >> +    if (!static_cpu_has(X86_FEATURE_XENPV)) { >> +        native_swapgs(); >> +        gsbase = rdgsbase(); >> +        native_swapgs(); >> +    } else { >> +        rdmsrl(MSR_KERNEL_GS_BASE, gsbase); >> +    } >>         return gsbase; >>   } >> @@ -182,9 +186,13 @@ static noinstr void __wrgsbase_inactive(unsigned >> long gsbase) >>   { >>       lockdep_assert_irqs_disabled(); >>   -    native_swapgs(); >> -    wrgsbase(gsbase); >> -    native_swapgs(); >> +    if (!static_cpu_has(X86_FEATURE_XENPV)) { >> +        native_swapgs(); >> +        wrgsbase(gsbase); >> +        native_swapgs(); >> +    } else { >> +        wrmsrl(MSR_KERNEL_GS_BASE, gsbase); >> +    } >>   } >>     /* >> > > Another possibility would be to just do (I'm fine either way): > > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c > index acc49fa6a097..b78dd373adbf 100644 > --- a/arch/x86/xen/enlighten_pv.c > +++ b/arch/x86/xen/enlighten_pv.c > @@ -318,6 +318,8 @@ static void __init xen_init_capabilities(void) >          setup_clear_cpu_cap(X86_FEATURE_XSAVE); >          setup_clear_cpu_cap(X86_FEATURE_OSXSAVE); >      } > + > +    setup_clear_cpu_cap(X86_FEATURE_FSGSBASE); That will stop both userspace and Xen (side effect of the guest kernel's CR4 choice) from using the instructions. Even when the kernel is using the paravirt fastpath, its still Xen actually taking the hit.  MSR_{FS,GS}_BASE/SHADOW are thousands of cycles to access, whereas {RD,WR}{FS,GS}BASE are a handful. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 29 11:22:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 11:22:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprrQ-00047B-3j; Mon, 29 Jun 2020 11:22:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprrO-000474-Uy for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 11:22:02 +0000 X-Inumbo-ID: c0f657be-b9fa-11ea-b7bb-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c0f657be-b9fa-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 11:22:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5C4CAAD5D; Mon, 29 Jun 2020 11:22:01 +0000 (UTC) Subject: Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches To: Julien Grall References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-3-julien@xen.org> <9fc81bbe-6c30-e848-ceae-1356ec30a8f8@suse.com> <11dad2fc-b1ec-3279-1a99-920a5f67456a@xen.org> From: Jan Beulich Message-ID: <37362d94-053d-5eb9-d2fa-9d30690313f0@suse.com> Date: Mon, 29 Jun 2020 13:22:00 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <11dad2fc-b1ec-3279-1a99-920a5f67456a@xen.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.06.2020 12:03, Julien Grall wrote: > On 29/06/2020 09:28, Jan Beulich wrote: >> On 27.06.2020 11:55, Julien Grall wrote: >>> As an aside, the padding sadly cannot be mandated to be 0 as they are >>> already present. So it is not going to be possible to use the padding >>> for extending a command in the future. >> >> Why is the other adjustment fine to make due to still being tech >> preview, but this one wouldn't be for the same reason? > > This is mostly a left-over of the previous message. Although, I am not > really inclined to address this myself any time soon. Sure, I didn't mean to indicate I might expect you to. But perhaps here the wording could be slightly changed as well? Jan From xen-devel-bounces@lists.xenproject.org Mon Jun 29 11:24:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 11:24:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprtc-0004F4-GO; Mon, 29 Jun 2020 11:24:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprta-0004EX-Dx for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 11:24:18 +0000 X-Inumbo-ID: 11f81422-b9fb-11ea-8558-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 11f81422-b9fb-11ea-8558-12813bfff9fa; Mon, 29 Jun 2020 11:24:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qBXwwFNpTJo650Yvu6M04pDVZ8TiiNlPlGjOy9+EJ3s=; b=KvK1rxCHjQibAbNKDWkRFhqjCG sq36MdcvyPQm6+tMCaGXjHRFrjD/fUstkS5sdmxgWI3L6kFx/kTOlmzsdNxQ82EJFZvCxnPrp8UVy uKhDGFJi4reRdeLmFBVRUU86AVKdS5qgjUebwwi/o+mZTP8Z1OHP3m+8sQi7PW0MuABM=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprtX-0001ak-Co; Mon, 29 Jun 2020 11:24:15 +0000 Received: from [54.239.6.188] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jprtX-0002M2-5m; Mon, 29 Jun 2020 11:24:15 +0000 Subject: Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches To: Jan Beulich References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-3-julien@xen.org> <9fc81bbe-6c30-e848-ceae-1356ec30a8f8@suse.com> <11dad2fc-b1ec-3279-1a99-920a5f67456a@xen.org> <37362d94-053d-5eb9-d2fa-9d30690313f0@suse.com> From: Julien Grall Message-ID: <0c03797c-33c2-8f56-fb0e-b578712cf681@xen.org> Date: Mon, 29 Jun 2020 12:24:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <37362d94-053d-5eb9-d2fa-9d30690313f0@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29/06/2020 12:22, Jan Beulich wrote: > On 29.06.2020 12:03, Julien Grall wrote: >> On 29/06/2020 09:28, Jan Beulich wrote: >>> On 27.06.2020 11:55, Julien Grall wrote: >>>> As an aside, the padding sadly cannot be mandated to be 0 as they are >>>> already present. So it is not going to be possible to use the padding >>>> for extending a command in the future. >>> >>> Why is the other adjustment fine to make due to still being tech >>> preview, but this one wouldn't be for the same reason? >> >> This is mostly a left-over of the previous message. Although, I am not >> really inclined to address this myself any time soon. > > Sure, I didn't mean to indicate I might expect you to. But perhaps > here the wording could be slightly changed as well? I am planning to remove the paragraph completely. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Mon Jun 29 11:28:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 11:28:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprxJ-0004Ov-0w; Mon, 29 Jun 2020 11:28:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jprxH-0004Oq-Tu for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 11:28:07 +0000 X-Inumbo-ID: 99f1b717-b9fb-11ea-8558-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 99f1b717-b9fb-11ea-8558-12813bfff9fa; Mon, 29 Jun 2020 11:28:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 7B369ADC5; Mon, 29 Jun 2020 11:28:05 +0000 (UTC) Subject: Re: [PATCH] x86/boot: Don't disable PV32 when XEN_SHSTK is compiled out To: Andrew Cooper References: <20200629103113.9328-1-andrew.cooper3@citrix.com> From: Jan Beulich Message-ID: <9eedf008-75f8-02e3-ecb5-ea089e1fa21d@suse.com> Date: Mon, 29 Jun 2020 13:28:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200629103113.9328-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Paul Durrant , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.06.2020 12:31, Andrew Cooper wrote: > There is no need to automatically disable PV32 support on SHSTK-capable > hardware if Xen isn't actually using the feature. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Mon Jun 29 11:49:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 11:49:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpsIA-00066X-R7; Mon, 29 Jun 2020 11:49:42 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpsIA-00066S-1Y for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 11:49:42 +0000 X-Inumbo-ID: 9de5d110-b9fe-11ea-8496-bc764e2007e4 Received: from mail-wr1-x444.google.com (unknown [2a00:1450:4864:20::444]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9de5d110-b9fe-11ea-8496-bc764e2007e4; Mon, 29 Jun 2020 11:49:41 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id g18so16265377wrm.2 for ; Mon, 29 Jun 2020 04:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=81RmdWf3FIrFu6KuRBwVUJPkgQUjijKfVyCOBzVOIYo=; b=vX+10zpVYSOeBxnrbL33b9MZk4xc9wS0LxPofOkiLM0L+ZcAFfK9t77nhcMF5rPZg6 97I3uJR4b10VzCvEyhOuM5zKT6Lh1lLuI3TgXSvXBNfwnEDJYdti/Y5mF9mu9MRgC3r2 fEAOG490uC/z+8aQDaJZL6tqdmRPvPPBdPENWBt/lKAGvtfoI1T6tJ0BHROzQg3ywu2d nLa54hKQbHwf+W5e3GoYyyV5sIjSt0ffVyu0D3L3YMSm2UpLcDHV34OUeW19ymBFcvHm PX/PgITiVczzwYK5Pdof3lCqkRh8aEGR85QGIolIEUcnVDXLCU1h+cUR1UgORWm2bvdd EYeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=81RmdWf3FIrFu6KuRBwVUJPkgQUjijKfVyCOBzVOIYo=; b=dLxjZAilFTsF+9lYXFVRvEP4fsWnfDRdaJ9q3ZWKsmKA+R9JqqsSfd/TPxWShJUiIm NtE37Uw+CRmxBtUCdO/ypz2G16eUbUFZc7BCrdNrjkXToTL209CzKUsXMQxnLYDobxUM EbvZ3EEmyiyYCVOTYAtvff0Sc6pzAQ2/tPG4u3m9w/DP9FOacTTMrl+hsOPYpXMUBwNQ 3st90NX2dvmQDjSEDwpYmtlZP+eDO1x78Hu+0FktmdR0ywU9uWXBl0q7koVjgcgo9rXS NWVQGqh9AyxcKwjhdufpQzRrUL+wzKAgoxv9YOkqoAVEUfPDsf8u11KhnP5mMllrToXn Armg== X-Gm-Message-State: AOAM5312uc0WEBDmWQuDQq898bzfv56S3Ce/JLIf44T4zyB9Pl1vt0bW v0ny9022OjXqXQvYQcw7ccA= X-Google-Smtp-Source: ABdhPJxVyUMLyoFhGN4r8M2n1tDkCdscRNgD+sb3fPNVautRgNuH+gKXihutk+llRWuz9rUt9YSxPg== X-Received: by 2002:adf:f34e:: with SMTP id e14mr16543308wrp.299.1593431380651; Mon, 29 Jun 2020 04:49:40 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-233.amazon.com. [54.240.197.233]) by smtp.gmail.com with ESMTPSA id y16sm48327027wro.71.2020.06.29.04.49.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 04:49:40 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Xen-devel'" References: <20200629103113.9328-1-andrew.cooper3@citrix.com> In-Reply-To: <20200629103113.9328-1-andrew.cooper3@citrix.com> Subject: RE: [PATCH] x86/boot: Don't disable PV32 when XEN_SHSTK is compiled out Date: Mon, 29 Jun 2020 12:49:38 +0100 Message-ID: <000701d64e0b$5f0c59a0$1d250ce0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQFLqu8eC5z5XvXfLQMJf8ab2IBDd6oEwKug X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Wei Liu' , 'Jan Beulich' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 29 June 2020 11:31 > To: Xen-devel > Cc: Andrew Cooper ; Jan Beulich = ; Wei Liu ; > Roger Pau Monn=C3=A9 ; Paul Durrant = > Subject: [PATCH] x86/boot: Don't disable PV32 when XEN_SHSTK is = compiled out >=20 > There is no need to automatically disable PV32 support on = SHSTK-capable > hardware if Xen isn't actually using the feature. >=20 > Signed-off-by: Andrew Cooper > --- > CC: Jan Beulich > CC: Wei Liu > CC: Roger Pau Monn=C3=A9 > CC: Paul Durrant >=20 > For 4.14. Minor bugfix. Release-acked-by: Paul Durrant > --- > xen/arch/x86/setup.c | 4 ++++ > 1 file changed, 4 insertions(+) >=20 > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c > index 2aa1cd50b8..c9b6af826d 100644 > --- a/xen/arch/x86/setup.c > +++ b/xen/arch/x86/setup.c > @@ -95,7 +95,11 @@ unsigned long __initdata highmem_start; > size_param("highmem-start", highmem_start); > #endif >=20 > +#ifdef CONFIG_XEN_SHSTK > static bool __initdata opt_xen_shstk =3D true; > +#else > +#define opt_xen_shstk false > +#endif >=20 > static int __init parse_cet(const char *s) > { > -- > 2.11.0 From xen-devel-bounces@lists.xenproject.org Mon Jun 29 12:06:13 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 12:06:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpsY0-0007lA-HV; Mon, 29 Jun 2020 12:06:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpsXy-0007l5-EG for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 12:06:02 +0000 X-Inumbo-ID: e5e5ebce-ba00-11ea-b7bb-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e5e5ebce-ba00-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 12:06:01 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: rf575NL4JziItKVrn0RKJZthvbssvZoBKB7Q5ALaCkfRShDKGCFeq6Sdd9lY/IjOQ68eJ6EBCN zyEhj2LGifiVKNLLNRox2VRpWtdXgkBSGH+0cfYqeKdwTflEjdSv4qwLqNKAsOYn8QxjyXeat5 dp2omnX9eCYmXEMLfhigxvJreQYuKor4I9OwbGrrHEyhK4CNP7zzOmSXcsFpooPMoO5TGVuRNB DObiD2D6M11RldR7/ERjpTIEsumrxLbZlwePF50x7XI8jFO6LTT8zkLATSiWT0GW9Q2SFPsfzK fHI= X-SBRS: 2.7 X-MesageID: 21508118 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21508118" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24313.55588.61431.336617@mariner.uk.xensource.com> Date: Mon, 29 Jun 2020 13:05:56 +0100 To: Jan Beulich Subject: Re: [PATCH] tools/configure: drop BASH configure variable In-Reply-To: <880fcc83-875c-c030-bfac-c64477aa3254@suse.com> References: <20200626170038.27650-1-andrew.cooper3@citrix.com> <880fcc83-875c-c030-bfac-c64477aa3254@suse.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Daniel De Graaf , Paul Durrant , Wei Liu , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure variable"): > On 26.06.2020 19:00, Andrew Cooper wrote: > > diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh > > old mode 100644 > > new mode 100755 > > diff --git a/xen/xsm/flask/policy/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh > > old mode 100644 > > new mode 100755 > > ... this may or may not take effect on the file system the sources > are stored on. In what circumstances might this not take effect ? IME all changes to files are properly replicated by git. Tarball distributions replicate the permissions of course. The only difficulty would be if this change were to be carried as a patch somewhere, by a downstream, but that seems unlikely, and can be avoided by that downstream not taking this patch. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 12:51:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 12:51:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jptFX-0003Og-3z; Mon, 29 Jun 2020 12:51:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jptFW-0003Ob-Mj for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 12:51:02 +0000 X-Inumbo-ID: 2f0ab37e-ba07-11ea-8561-12813bfff9fa Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2f0ab37e-ba07-11ea-8561-12813bfff9fa; Mon, 29 Jun 2020 12:51:01 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: hOggAfmDbsi8FS5GTKvxaQStBB3UF3WLpR+RR8dT2pNl0yMIUbmW/qF2LyEKc1sRs3+apTmFNV YGQ8CeMXbKEToL5JksFACqJLkXELXK4UMeTZ2SGfMi2DsMvYxR8m/gcpa+g6nbBNZr4a/x4km1 4znaw2+gQlXFYzBuZNlFNsjI7w3ZPF90n1kcaBCVBTzZPbSq3Dw7UOELbg1IhadfaANBkvr2Wq 3PLGd45SrBc7UsjqxUuDBK8BmaZD7ypafvmoqf+4G3h76AZ3WGvGI66tZlIM2SCKB3uOkjCdSQ w8g= X-SBRS: 2.7 X-MesageID: 21477854 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21477854" Subject: Re: [PATCH] xsm: Drop trailing whitespace from build scripts To: , 'Jan Beulich' References: <20200626170221.28534-1-andrew.cooper3@citrix.com> <9822c557-655b-67cb-c513-60039dbe0d8d@suse.com> <000601d64dee$e47b2840$ad7178c0$@xen.org> From: Andrew Cooper Message-ID: <257c6ec8-8f0f-c765-d876-803b90832b01@citrix.com> Date: Mon, 29 Jun 2020 13:50:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <000601d64dee$e47b2840$ad7178c0$@xen.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Xen-devel' , 'Daniel De Graaf' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29/06/2020 09:25, Paul Durrant wrote: >> -----Original Message----- >> From: Xen-devel On Behalf Of Jan Beulich >> Sent: 29 June 2020 09:22 >> To: Andrew Cooper >> Cc: Xen-devel ; Daniel De Graaf >> Subject: Re: [PATCH] xsm: Drop trailing whitespace from build scripts >> >> On 26.06.2020 19:02, Andrew Cooper wrote: >>> Signed-off-by: Andrew Cooper >>> --- >>> CC: Daniel De Graaf >> Since we've not heard anything from Daniel in quite a while, just >> in case: >> Acked-by: Jan Beulich >> > This is pretty trivial cleanup so, if you want to put it in 4.14 consider it... > > Release-acked-by: Paul Durrant Ok.  In it goes. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 29 13:34:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 13:34:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jptva-0006lH-8u; Mon, 29 Jun 2020 13:34:30 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jptvZ-0006lC-It for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 13:34:29 +0000 X-Inumbo-ID: 411fbbda-ba0d-11ea-bb8b-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 411fbbda-ba0d-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 13:34:28 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: 2mQVr80Hqteu/U4L0F00N2/ZXrAA1kSi7Vfl8ESmr15CM8oJ5WIsJzxs4mF5AluKPB1icZZPNL eIswkUW/5mxZ01J3Zso5qQHusmNJX3U6acsUHqCPMqWk7dDLyO+dPu8MJqZG91H9a4gACOANl/ ENMPsa3xCc/8rimKeIGEeMILi8iXuZ/0kQMghzK6LP+imVcvjUy/Es5Iz5tq0AGo6fKQxNOykq YHnOfXeKiTevRW0W2VIX0IIoJ6cF0GHWf1x5V3veMr9wFYAg1iyAS+jNB4r7ujb3dyzzR6GckT BwY= X-SBRS: 2.7 X-MesageID: 21168238 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21168238" From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <24313.60895.220354.223207@mariner.uk.xensource.com> Date: Mon, 29 Jun 2020 14:34:23 +0100 To: Andrew Cooper Subject: [PATCH] tools/configure: drop BASH configure variable In-Reply-To: <20200626170038.27650-1-andrew.cooper3@citrix.com> References: <20200626170038.27650-1-andrew.cooper3@citrix.com> X-Mailer: VM 8.2.0b under 24.5.1 (i686-pc-linux-gnu) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Daniel De Graaf , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Andrew Cooper writes ("[PATCH] tools/configure: drop BASH configure variable"): > This is a weird variable to have in the first place. The only user of it is > XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only two scripts > run with this are shebang sh anyway, so don't need bash in the first place. Thanks for this cleanup. I agree with the basic idea. However, did you run these scripts with dash, or review them, to check for bashisms ? It is not unusual to find scripts which need bash but which mistaken have #!/bin/sh - especially if the usual arrangements for running them always use bash anyway. So the presence of the #!/bin/sh is only rather weak evidence that these scripts will be fine when run with sh. > Make the mkflask.sh and mkaccess_vector.sh scripts executable, drop the > CONFIG_SHELL, and drop the $BASH variable to prevent further use. Since the build currently uses bash for these, a more neutral change would be to change to #!/bin/bash at the same time. > RFC for 4.14. This is a cleanup to the build system. I see this already has a release-ack. However, I would not have recommended granting one at least on the basis of the description above. I agree that this is cleanup. But the current situation is not buggy. I'm not sure exactly what the release criteria are but ISTM that this patch adds risk to the release rather than removing it. Thanks for your attention. Ian. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 13:51:31 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 13:51:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpuBk-0008Nm-Nx; Mon, 29 Jun 2020 13:51:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpuBj-0008Nh-BY for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 13:51:11 +0000 X-Inumbo-ID: 9688f922-ba0f-11ea-bca7-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9688f922-ba0f-11ea-bca7-bc764e2007e4; Mon, 29 Jun 2020 13:51:10 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: olhtQNkxxzVsjqWXNDwG1Ru67t2OnFClDj56q+owXhZbScbVBvbsZLEodpZLrL8h/JZS7OmJyd Gdlr8AQVvv06A9a79YJNhjmn3Ko5MWWsEAD2TEyN99VSpdAr0sQUQp0YDBqKxS0cZzq1JBEwo0 YfbYWhYr6yy0FrbdTUkFjxeT/lc2KslCeKcn8S71mYNM8546819yeaApsrDvizAPReOpPSQC+7 ALcZ6U+JFiTJJn+GKTYqXKTlayTIhVXKwfVMyXBu0ooVSRtuP/UWI7FT7grcQ+YfC7FMI9TmLi dWo= X-SBRS: 2.7 X-MesageID: 21518647 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,294,1589256000"; d="scan'208";a="21518647" Subject: Re: [PATCH] tools/configure: drop BASH configure variable To: Ian Jackson References: <20200626170038.27650-1-andrew.cooper3@citrix.com> <24313.60895.220354.223207@mariner.uk.xensource.com> From: Andrew Cooper Message-ID: <9838e494-6372-a456-9ff6-95b2b8f7381f@citrix.com> Date: Mon, 29 Jun 2020 14:51:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <24313.60895.220354.223207@mariner.uk.xensource.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Xen-devel , Daniel De Graaf , Wei Liu , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29/06/2020 14:34, Ian Jackson wrote: > Andrew Cooper writes ("[PATCH] tools/configure: drop BASH configure variable"): >> This is a weird variable to have in the first place. The only user of it is >> XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only two scripts >> run with this are shebang sh anyway, so don't need bash in the first place. > Thanks for this cleanup. I agree with the basic idea. > > However, did you run these scripts with dash, or review them, to check > for bashisms ? Yes, to all of the above. They are both very thin wrappers (doing some argument shuffling) around large AWK scripts. >> Make the mkflask.sh and mkaccess_vector.sh scripts executable, drop the >> CONFIG_SHELL, and drop the $BASH variable to prevent further use. > Since the build currently uses bash for these, a more neutral change > would be to change to #!/bin/bash at the same time. That will break FreeBSD, which has no `bash` in sight. >> RFC for 4.14. This is a cleanup to the build system. > I see this already has a release-ack. However, I would not have > recommended granting one at least on the basis of the description > above. > > I agree that this is cleanup. But the current situation is not buggy. > I'm not sure exactly what the release criteria are but ISTM that this > patch adds risk to the release rather than removing it. I agree that the current state of play isn't a major issue, but having ./configure check for bash is buggy for both uses. ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 29 14:00:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 14:00:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpuKS-0000uY-Lf; Mon, 29 Jun 2020 14:00:12 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpuKS-0000uT-31 for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 14:00:12 +0000 X-Inumbo-ID: d8cf4bc8-ba10-11ea-b7bb-bc764e2007e4 Received: from mail-wr1-x436.google.com (unknown [2a00:1450:4864:20::436]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d8cf4bc8-ba10-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 14:00:11 +0000 (UTC) Received: by mail-wr1-x436.google.com with SMTP id q5so16650418wru.6 for ; Mon, 29 Jun 2020 07:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=5SxzAMmNmjXpTpTWYdx1hWVU4CseMcqm45bhhP+oHL0=; b=RM81d4eGGi788tNTSZLdjcBQo81xmtLprOQu2IKDg8kwovZq7wDV1J2FcFfKOwHBRk 6rcu7fUjibAa9mNHEkYU9kN6DfFiRXtu9xAXkVETzvaYbhFjvuGPEYtwR1jto288XtNx i2XD/n7egnwov00fAMLIxAF99AUr8DUHi/IbOwpOEEIIVDXo8UoBmtlkaM3mA4LCmO/Y U4XwYvllJczXDdjTQVxG0zwntVR1vWLqKK8oGyod13NniI08g0Rppo6OujJAspngG7SC 95sMu+kfIplkv0kPKQM1Cq1PzkXj+OPnc74a+86Ka8HMjzjoyL9uCfKyfZI3TuODEvZz jXuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :content-language:thread-index; bh=5SxzAMmNmjXpTpTWYdx1hWVU4CseMcqm45bhhP+oHL0=; b=Xvewq8uMARmYbz6SdMvLjEZUTRVKuHkrCglOy6gG53UUz2sl0/Xa3kx2WbItqXWbHc sbCGX3N+UiKaI+eQEL6re+IJfN3HdxQ/OSY0f4S+QYmYTL5tmyJOQZ4R246lGMLQCfzL hpQSiyAVqG5F4aZCrwN4qe8mOXTZye5wAy/0syJAPL+M7Kak/9Ul2pMtbQ6csogCWLTP v9ABNCfxM22RpB6QCyUPa6F+EdAL3I+BF35rk+x80h4Mh93sgLPAP510Hm/F5vgcjyQ/ 1y0FkEz6z3ZZ7dg4x9SiUhJQ3GcYKEDBaxNVeLb9E+xb0iiFBFUevOqXAywiHelVlCiQ f5dg== X-Gm-Message-State: AOAM532tMWBcM/206t/weOiFhdDEuNcbZXZgPdSSAoRMiiv2YVAJYafx ir0PR2FnfNssAxPNNizB2MM= X-Google-Smtp-Source: ABdhPJztl9nRde4lzAuYtu4CX141s6gX54JV5/6kEyyfZdeJ0MdEX75/PJ2HNz+J2n72tKd5aQ+Q+g== X-Received: by 2002:adf:c44d:: with SMTP id a13mr17606294wrg.205.1593439210482; Mon, 29 Jun 2020 07:00:10 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-233.amazon.com. [54.240.197.233]) by smtp.gmail.com with ESMTPSA id m10sm28542727wru.4.2020.06.29.07.00.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jun 2020 07:00:10 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Andrew Cooper'" , "'Ian Jackson'" References: <20200626170038.27650-1-andrew.cooper3@citrix.com> <24313.60895.220354.223207@mariner.uk.xensource.com> <9838e494-6372-a456-9ff6-95b2b8f7381f@citrix.com> In-Reply-To: <9838e494-6372-a456-9ff6-95b2b8f7381f@citrix.com> Subject: RE: [PATCH] tools/configure: drop BASH configure variable Date: Mon, 29 Jun 2020 15:00:09 +0100 Message-ID: <000001d64e1d$9a0d4f70$ce27ee50$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQG/+PmFeHEa0PFXsi/qRsJidKaVMgG5Jh8tATM+KJ6pBOWfIA== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Xen-devel' , 'Daniel De Graaf' , 'Wei Liu' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Andrew Cooper > Sent: 29 June 2020 14:51 > To: Ian Jackson > Cc: Xen-devel ; Wei Liu ; = Daniel De Graaf > ; Paul Durrant > Subject: Re: [PATCH] tools/configure: drop BASH configure variable >=20 > On 29/06/2020 14:34, Ian Jackson wrote: > > Andrew Cooper writes ("[PATCH] tools/configure: drop BASH configure = variable"): > >> This is a weird variable to have in the first place. The only user = of it is > >> XSM's CONFIG_SHELL, which opencodes a fallback to sh, and the only = two scripts > >> run with this are shebang sh anyway, so don't need bash in the = first place. > > Thanks for this cleanup. I agree with the basic idea. > > > > However, did you run these scripts with dash, or review them, to = check > > for bashisms ? >=20 > Yes, to all of the above. >=20 > They are both very thin wrappers (doing some argument shuffling) = around > large AWK scripts. >=20 > >> Make the mkflask.sh and mkaccess_vector.sh scripts executable, drop = the > >> CONFIG_SHELL, and drop the $BASH variable to prevent further use. > > Since the build currently uses bash for these, a more neutral change > > would be to change to #!/bin/bash at the same time. >=20 > That will break FreeBSD, which has no `bash` in sight. >=20 > >> RFC for 4.14. This is a cleanup to the build system. > > I see this already has a release-ack. However, I would not have > > recommended granting one at least on the basis of the description > > above. > > > > I agree that this is cleanup. But the current situation is not = buggy. > > I'm not sure exactly what the release criteria are but ISTM that = this > > patch adds risk to the release rather than removing it. >=20 > I agree that the current state of play isn't a major issue, but having > ./configure check for bash is buggy for both uses. >=20 Even if it is not buggy, it is pointless complexity since FreeBSD would = clearly have been broken all this time had there been bash-isms in the = scripts. Paul > ~Andrew From xen-devel-bounces@lists.xenproject.org Mon Jun 29 14:38:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 14:38:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpuvb-0003uz-TI; Mon, 29 Jun 2020 14:38:35 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpuvb-0003uu-5q for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 14:38:35 +0000 X-Inumbo-ID: 35adadee-ba16-11ea-bb8b-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 35adadee-ba16-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 14:38:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A507DAD17; Mon, 29 Jun 2020 14:38:33 +0000 (UTC) Subject: Re: [PATCH] tools/configure: drop BASH configure variable To: Ian Jackson References: <20200626170038.27650-1-andrew.cooper3@citrix.com> <880fcc83-875c-c030-bfac-c64477aa3254@suse.com> <24313.55588.61431.336617@mariner.uk.xensource.com> From: Jan Beulich Message-ID: <2c202733-cbff-74e0-30c6-4cba227e7969@suse.com> Date: Mon, 29 Jun 2020 16:38:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24313.55588.61431.336617@mariner.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Daniel De Graaf , Paul Durrant , Wei Liu , Xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 29.06.2020 14:05, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH] tools/configure: drop BASH configure variable"): >> On 26.06.2020 19:00, Andrew Cooper wrote: >>> diff --git a/xen/xsm/flask/policy/mkaccess_vector.sh b/xen/xsm/flask/policy/mkaccess_vector.sh >>> old mode 100644 >>> new mode 100755 >>> diff --git a/xen/xsm/flask/policy/mkflask.sh b/xen/xsm/flask/policy/mkflask.sh >>> old mode 100644 >>> new mode 100755 >> >> ... this may or may not take effect on the file system the sources >> are stored on. > > In what circumstances might this not take effect ? When the file system is incapable of recording execute permissions? It has been a common workaround for this in various projects that I've worked with to use $(SHELL) to account for that, so the actual permissions from the fs don't matter. (There may be mount options to make everything executable on such file systems, but people may be hesitant to use them.) Jan > IME all changes to files are properly replicated by git. Tarball > distributions replicate the permissions of course. > > The only difficulty would be if this change were to be carried as a > patch somewhere, by a downstream, but that seems unlikely, and can be > avoided by that downstream not taking this patch. > > Ian. > From xen-devel-bounces@lists.xenproject.org Mon Jun 29 14:46:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 14:46:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpv3R-0004vK-MJ; Mon, 29 Jun 2020 14:46:41 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpv3Q-0004vD-8W for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 14:46:40 +0000 X-Inumbo-ID: 56df2604-ba17-11ea-857e-12813bfff9fa Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 56df2604-ba17-11ea-857e-12813bfff9fa; Mon, 29 Jun 2020 14:46:39 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: NUIbpoPidLvbe6vd9Hw53G5sKnXaPO9SlrVG3ivZgrzxmTubZlXaYt+Ue0l8qxl1t7rkNYRokF B0RItiOwfDndvqCl/JGAn2GDumgPrFC6SMpbUTBNNZqdwe+W5PHV/XmtCYUCaVJ7MWFjqwEmXu o0GIuGeCRUSVUzG56d+AgWCIaF/FHMjinkC49eTlPVHZtX3rObNu3SDO084muEpPMUKPcykXVd Rmeety77IJaT5eXYl71H7ynqtAPm5yy5y8fY0UC0S3vrb45eV4ZXMygI31Kc4fiT99/+OFGJry rJI= X-SBRS: 2.7 X-MesageID: 21177427 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,295,1589256000"; d="scan'208";a="21177427" Date: Mon, 29 Jun 2020 16:46:32 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 8/8] x86/hvm: enable emulated PIT for PVH dom0 Message-ID: <20200629144632.GI735@Air-de-Roger> References: <20200612155640.4101-1-roger.pau@citrix.com> <20200612155640.4101-9-roger.pau@citrix.com> <88a91a26-1ad8-bf85-d55e-4fc29afaf554@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <88a91a26-1ad8-bf85-d55e-4fc29afaf554@suse.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel@lists.xenproject.org, paul@xen.org, Wei Liu , Andrew Cooper Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Thu, Jun 18, 2020 at 06:05:21PM +0200, Jan Beulich wrote: > On 12.06.2020 17:56, Roger Pau Monne wrote: > > Some video BIOS require a PIT in order to work properly, hence classic > > PV dom0 gets partial access to the physical PIT as long as it's not in > > use by Xen. > > > > Since PVH dom0 is built on top of HVM support, there's already an > > emulated PIT implementation available for use. Tweak the emulated PIT > > code so it injects interrupts directly into the vIO-APIC if the legacy > > PIC (i8259) is disabled. Make sure the GSI used matches the ISA IRQ 0 > > in the likely case there's an interrupt overwrite in the MADT ACPI > > Same nit again as for the earlier patch (also applicable to a code > comment below). > > > @@ -578,7 +579,7 @@ int arch_domain_create(struct domain *d, > > > > emflags = config->arch.emulation_flags; > > > > - if ( is_hardware_domain(d) && is_pv_domain(d) ) > > + if ( is_hardware_domain(d) ) > > emflags |= XEN_X86_EMU_PIT; > > Wouldn't this better go into create_dom0(), where all the other > flags get set? Or otherwise all of that be moved here (to cover > the late-hwdom case)? I've just moved all setting of the emulation_flags to arch_domain_create so it's done at the same place for PV and PVH. > > --- a/xen/arch/x86/hvm/vioapic.c > > +++ b/xen/arch/x86/hvm/vioapic.c > > @@ -268,7 +268,14 @@ static void vioapic_write_redirent( > > > > spin_unlock(&d->arch.hvm.irq_lock); > > > > - if ( is_hardware_domain(d) && unmasked ) > > + if ( is_hardware_domain(d) && unmasked && > > + /* > > + * A PVH dom0 can have an emulated PIT that should respect any > > + * interrupt overwrites found in the ACPI MADT table, so we need to > > + * check to which GSI the ISA IRQ 0 is mapped in order to prevent > > + * identity mapping it. > > + */ > > + (!has_vpit(d) || gsi != hvm_isa_irq_to_gsi(d, 0)) ) > > Isn't has_vpit() true now for Dom0, and hence that part of the > condition is kind of pointless? Well, yes, but I think we should strive for the code to be prepared to deal with both vPIT enabled or disabled, and hence shouldn't make assumptions. > And shouldn't Dom0 never have seen > physical IRQ 0 in the first place (we don't allow PV Dom0 to use > that IRQ either, after all)? Yes, that will fail in map_domain_pirq, so a PVH dom0 won't be able to bind IRQ 0 anyway. Roger. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 15:16:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 15:16:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpvW1-0007ZU-4v; Mon, 29 Jun 2020 15:16:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpvVz-0007ZP-8C for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 15:16:11 +0000 X-Inumbo-ID: 761af954-ba1b-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 761af954-ba1b-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 15:16:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vZsbZn5V8qnLRpUgO2EhXVDpqMhy8dMKL4qExo10jKw=; b=VIYfcdctUyzmIyGviz/AZutyp ouxBVfNp5vb0C+t+e4AwwrfkACRzmShbBA42Tc1baU64DEAJZp4VJ40LTKtiY0aHCD6Kyx7Ty+wN7 kJXGj7BGIpkrh/W05A+flE5gZ6N3Tcw+mBQNgUF0K3VXlpIY0YnWtoJ+8JcNBFSsg3m8M=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpvVx-0005vH-FB; Mon, 29 Jun 2020 15:16:09 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpvVw-0004ep-Rv; Mon, 29 Jun 2020 15:16:09 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpvVw-0002PI-RQ; Mon, 29 Jun 2020 15:16:08 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151454: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=da53345dd5ff7d3a34e83587fd375c0b7722f46c X-Osstest-Versions-That: xen=88cfd062e8318dfeb67c7d2eb50b6cd224b0738a From: osstest service owner Date: Mon, 29 Jun 2020 15:16:08 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151454 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151454/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen da53345dd5ff7d3a34e83587fd375c0b7722f46c baseline version: xen 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a Last test of basis 151385 2020-06-26 18:00:39 Z 2 days Testing same since 151454 2020-06-29 13:01:35 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 88cfd062e8..da53345dd5 da53345dd5ff7d3a34e83587fd375c0b7722f46c -> smoke From xen-devel-bounces@lists.xenproject.org Mon Jun 29 15:28:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 15:28:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpvhd-0000CU-Cb; Mon, 29 Jun 2020 15:28:13 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpvhc-0000CP-DQ for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 15:28:12 +0000 X-Inumbo-ID: 243aa470-ba1d-11ea-bca7-bc764e2007e4 Received: from mail-wm1-x341.google.com (unknown [2a00:1450:4864:20::341]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 243aa470-ba1d-11ea-bca7-bc764e2007e4; Mon, 29 Jun 2020 15:28:11 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id g75so15777809wme.5 for ; Mon, 29 Jun 2020 08:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=khkhbBVlcOb2HLOWDZBBJqUA7a5qRZ07CmJjZNbLNqo=; b=QeN255AHmxSrQpsrB6NwGoG9YKZP9cVBVqKB/puDYkHAN3IhWYvnzWXXsEynpbnW2k Zod6kYffa3DvE9qQ5XbOxATKV/z3b9GioYa8m6OeZhgwS33xTxADVKgvjPrUeWJzzeYw NZGUbHmNeqZvOk4iZi5Lx//jBZIuzr0QfsZ8bPb0b+0GHVsNC/jC3nZpFTQW+TOXF2mo yikK47OKB+FTOQoUorFXBQFdh+PV+lJirgAKdgqxsWzMsv75d8A1yqAq8MEboOIGB1Tl D20J4whC5fIRQudhY+HJgxLz1DKbIedH/Cea9s+ibMtYg5K6sf+eHnnntD93fW5X12+L IbXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=khkhbBVlcOb2HLOWDZBBJqUA7a5qRZ07CmJjZNbLNqo=; b=T14HrLZL473HMdH78BvorQFrt3WNI0wFcGoaZSi0A1qrPWoa2lPoar6nOx8Cl1xKSh P8h0zjUn/hHRn0npmGuZgHx6S6p+kfY5WfKpeH9j98pzrDad/o20o2wu9GCDS3YDgGUG 0uXKJzTwCbOG6ixqw981MsO0wdM5oxXvEryO80EbO+SZyP/gZTxXHgcU9Czr8cFlw/2O AX6GHP4BOKTHIj8Xu25FUdJn23WIbHqpxU3atMdpYqhy6TrerMFYA5JSZfe1S+EjbMpX 3Bwnh8tcGIENkQxVr3k05Y+a+wes8FoiFCQ0xOjOvfG1VQgnrGEGXNOH2ruujNemugB5 TDMw== X-Gm-Message-State: AOAM531fR2xXopQT8kSM7x+Vk7d939miDRxNadzAUk3kXV9uKc6dTns/ rQMko0gTBqSTmIwg8eFcFem9aPbWmOWkAnVqshY= X-Google-Smtp-Source: ABdhPJy1fcIKKd+ndv8TKbYBlOO/yJYfRoWoHQLtNu4hmVjjevp5vBS587f/wmWXmq8gO450qjSJ+OoQNN9Kc0NSwJw= X-Received: by 2002:a1c:b103:: with SMTP id a3mr17033456wmf.186.1593444490851; Mon, 29 Jun 2020 08:28:10 -0700 (PDT) MIME-Version: 1.0 References: <1617453791.11443328.1592849168658.JavaMail.zimbra@cert.pl> <1786138246.11444015.1592849576272.JavaMail.zimbra@cert.pl> <20200626114824.mt2zsbwdbed5dtwj@liuwe-devbox-debian-v2> <24309.63267.596889.412833@mariner.uk.xensource.com> In-Reply-To: <24309.63267.596889.412833@mariner.uk.xensource.com> From: Tamas K Lengyel Date: Mon, 29 Jun 2020 09:27:34 -0600 Message-ID: Subject: Re: [PATCH v3 7/7] tools/proctrace: add proctrace tool To: Ian Jackson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" , =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , Tamas K Lengyel , "Kang, Luwei" , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 7:26 AM Ian Jackson wrote: > > Wei Liu writes ("Re: [PATCH v3 7/7] tools/proctrace: add proctrace tool")= : > > On Mon, Jun 22, 2020 at 08:12:56PM +0200, Micha=C5=82 Leszczy=C5=84ski = wrote: > > > Add an demonstration tool that uses xc_vmtrace_* calls in order > > > to manage external IPT monitoring for DomU. > ... > > > + if (rc) { > > > + fprintf(stderr, "Failed to call xc_vmtrace_pt_disable\n"); > > > + return 1; > > > + } > > > + > > > > You should close fmem and xc in the exit path. > > Thanks for reviewing this. I agree with your comments. But I > disagree with this one. > > This is in main(). When the program exits, the xc handle and memory > mappings will go away as the kernel tears down the process. > > Leaving out this kind of cleanup in standalone command-line programs > is fine, I think. It can make the code simpler - and it avoids the > risk of doing it wrong, which can turn errors into crashes. Hi Ian, while I agree that this particular code would not be an issue, consider that these tools are often taken as sample codes to be reused in other contexts as well. As such, I think it should include the close bits as well and exhibit all the "best practices" we would like to see anyone else building tools for Xen. Cheers, Tamas From xen-devel-bounces@lists.xenproject.org Mon Jun 29 15:41:34 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 15:41:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpvuP-0001wf-UQ; Mon, 29 Jun 2020 15:41:25 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpvuN-0001vv-Sg for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 15:41:23 +0000 X-Inumbo-ID: fc32d9e6-ba1e-11ea-bb8b-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id fc32d9e6-ba1e-11ea-bb8b-bc764e2007e4; Mon, 29 Jun 2020 15:41:23 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 72D94253B7; Mon, 29 Jun 2020 15:41:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593445282; bh=v4o/sTBPFwFPeWTSIwtW+Aupixd+ozXq8yjf4Q0efkM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=YGzYArGbcosRmEvHAhRENWfXUa/41gJFqQKWFNl+Uo24zpv6gfAq1pwfew7c/Da/c vOMGeVrqUWjphdVHn2Ahrubcb12el3zGYx6i+BOfnEbgy/39lzvXAxIE1vcN1q7LEx HTsU2Nrv3Oqmt3ligFXt6y5ULF3h2qSSJDqWENlU= Date: Mon, 29 Jun 2020 08:41:21 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches In-Reply-To: <20200627095533.14145-3-julien@xen.org> Message-ID: References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-3-julien@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sat, 27 Jun 2020, Julien Grall wrote: > From: Julien Grall > > The specification of pvcalls suggests there is padding for 32-bit x86 > at the end of most the structure. However, they are not described in > in the public header. > > Because of that all the structures would be 32-bit aligned and not > 64-bit aligned for 32-bit x86. > > For all the other architectures supported (Arm and 64-bit x86), the > structure are aligned to 64-bit because they contain uint64_t field. > Therefore all the structures contain implicit padding. > > Given the specification is authoriitative, the padding will the same for > the all architectures. The potential breakage of compatibility is ought > to be fine as pvcalls is still a tech preview. > > As an aside, the padding sadly cannot be mandated to be 0 as they are > already present. So it is not going to be possible to use the padding > for extending a command in the future. > > Signed-off-by: Julien Grall Aside from typos other mentioned: Reviewed-by: Stefano Stabellini > --- > This wants to be included in Xen 4.14 to avoid more users to rely on > wrong public headers. > > Changes in v4: > - Revert back to v1 for the patch and expand the commit message > > Changes in v3: > - Use __i386__ rather than CONFIG_X86_32 > > Changes in v2: > - It is not possible to use the same padding for 32-bit x86 and > all the other supported architectures. > --- > docs/misc/pvcalls.pandoc | 8 -------- > xen/include/public/io/pvcalls.h | 4 ++++ > 2 files changed, 4 insertions(+), 8 deletions(-) > > diff --git a/docs/misc/pvcalls.pandoc b/docs/misc/pvcalls.pandoc > index 665dad556c39..971cd8f4b122 100644 > --- a/docs/misc/pvcalls.pandoc > +++ b/docs/misc/pvcalls.pandoc > @@ -246,9 +246,7 @@ The format is defined as follows: > uint32_t domain; > uint32_t type; > uint32_t protocol; > - #ifdef CONFIG_X86_32 > uint8_t pad[4]; > - #endif > } socket; > struct xen_pvcalls_connect { > uint64_t id; > @@ -257,16 +255,12 @@ The format is defined as follows: > uint32_t flags; > grant_ref_t ref; > uint32_t evtchn; > - #ifdef CONFIG_X86_32 > uint8_t pad[4]; > - #endif > } connect; > struct xen_pvcalls_release { > uint64_t id; > uint8_t reuse; > - #ifdef CONFIG_X86_32 > uint8_t pad[7]; > - #endif > } release; > struct xen_pvcalls_bind { > uint64_t id; > @@ -276,9 +270,7 @@ The format is defined as follows: > struct xen_pvcalls_listen { > uint64_t id; > uint32_t backlog; > - #ifdef CONFIG_X86_32 > uint8_t pad[4]; > - #endif > } listen; > struct xen_pvcalls_accept { > uint64_t id; > diff --git a/xen/include/public/io/pvcalls.h b/xen/include/public/io/pvcalls.h > index 905880735dda..6da6b5533a10 100644 > --- a/xen/include/public/io/pvcalls.h > +++ b/xen/include/public/io/pvcalls.h > @@ -68,6 +68,7 @@ struct xen_pvcalls_request { > uint32_t domain; > uint32_t type; > uint32_t protocol; > + uint8_t pad[4]; > } socket; > struct xen_pvcalls_connect { > uint64_t id; > @@ -76,10 +77,12 @@ struct xen_pvcalls_request { > uint32_t flags; > grant_ref_t ref; > uint32_t evtchn; > + uint8_t pad[4]; > } connect; > struct xen_pvcalls_release { > uint64_t id; > uint8_t reuse; > + uint8_t pad[7]; > } release; > struct xen_pvcalls_bind { > uint64_t id; > @@ -89,6 +92,7 @@ struct xen_pvcalls_request { > struct xen_pvcalls_listen { > uint64_t id; > uint32_t backlog; > + uint8_t pad[4]; > } listen; > struct xen_pvcalls_accept { > uint64_t id; > -- > 2.17.1 > From xen-devel-bounces@lists.xenproject.org Mon Jun 29 15:51:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 15:51:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpw3j-0002tZ-Re; Mon, 29 Jun 2020 15:51:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpw3i-0002tU-Qm for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 15:51:02 +0000 X-Inumbo-ID: 54e09cbc-ba20-11ea-8587-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 54e09cbc-ba20-11ea-8587-12813bfff9fa; Mon, 29 Jun 2020 15:51:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id F0241AD26; Mon, 29 Jun 2020 15:51:00 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: Jan Beulich Subject: [PATCH] x86: fix compat header generation Message-ID: <0e617191-d61f-08e2-eaa9-b324cd6501f0@suse.com> Date: Mon, 29 Jun 2020 17:50:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , George Dunlap , Andrew Cooper , Ian Jackson , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" As was pointed out by "mm: fix public declaration of struct xen_mem_acquire_resource", we're not currently handling structs correctly that has uint64_aligned_t fields. #pragma pack(4) suppresses the necessary alignment even if the type did properly survive (which it also didn't) in the process of generating the headers. Overall, with the above mentioned change applied, there's only a latent issue here afaict, i.e. no other of our interface structs is currently affected. As a result it is clear that using #pragma pack(4) is not an option. Drop all uses from compat header generation. Make sure {,u}int64_aligned_t actually survives, such that explicitly aligned fields will remain aligned. Arrange for {,u}int64_t to be transformed into a type that's 64 bits wide and 4-byte aligned, by utilizing that in typedef-s the "aligned" attribute can be used to reduce alignment. Note that this changes alignment (but not size) of certain compat structures, when one or more of their fields use a non-translated struct as their type(s). This isn't correct, and hence applying alignof() to such fields requires care, but the prior situation was even worse. There's one change to generated code according to my observations: In arch_compat_vcpu_op() the runstate area "area" variable would previously have been put in a just 4-byte aligned stack slot (despite being 8 bytes in size), whereas now it gets put in an 8-byte aligned location. Signed-off-by: Jan Beulich --- a/xen/include/Makefile +++ b/xen/include/Makefile @@ -34,15 +34,6 @@ headers-$(CONFIG_XSM_FLASK) += compat/xs cppflags-y := -include public/xen-compat.h -DXEN_GENERATING_COMPAT_HEADERS cppflags-$(CONFIG_X86) += -m32 -# 8-byte types are 4-byte aligned on x86_32 ... -ifeq ($(CONFIG_CC_IS_CLANG),y) -prefix-$(CONFIG_X86) := \#pragma pack(push, 4) -suffix-$(CONFIG_X86) := \#pragma pack(pop) -else -prefix-$(CONFIG_X86) := \#pragma pack(4) -suffix-$(CONFIG_X86) := \#pragma pack() -endif - endif public-$(CONFIG_X86) := $(wildcard public/arch-x86/*.h public/arch-x86/*/*.h) @@ -57,16 +48,16 @@ compat/%.h: compat/%.i Makefile $(BASEDI echo "#define $$id" >>$@.new; \ echo "#include " >>$@.new; \ $(if $(filter-out compat/arch-%.h,$@),echo "#include <$(patsubst compat/%,public/%,$@)>" >>$@.new;) \ - $(if $(prefix-y),echo "$(prefix-y)" >>$@.new;) \ grep -v '^# [0-9]' $< | \ $(PYTHON) $(BASEDIR)/tools/compat-build-header.py | uniq >>$@.new; \ - $(if $(suffix-y),echo "$(suffix-y)" >>$@.new;) \ echo "#endif /* $$id */" >>$@.new mv -f $@.new $@ +.PRECIOUS: compat/%.i compat/%.i: compat/%.c Makefile $(CPP) $(filter-out -Wa$(comma)% -include %/include/xen/config.h,$(XEN_CFLAGS)) $(cppflags-y) -o $@ $< +.PRECIOUS: compat/%.c compat/%.c: public/%.h xlat.lst Makefile $(BASEDIR)/tools/compat-build-source.py mkdir -p $(@D) grep -v 'DEFINE_XEN_GUEST_HANDLE(long)' $< | \ --- a/xen/tools/compat-build-header.py +++ b/xen/tools/compat-build-header.py @@ -3,7 +3,7 @@ import re,sys pats = [ - [ r"__InClUdE__(.*)", r"#include\1\n#pragma pack(4)" ], + [ r"__InClUdE__(.*)", r"#include\1" ], [ r"__IfDeF__ (XEN_HAVE.*)", r"#ifdef \1" ], [ r"__ElSe__", r"#else" ], [ r"__EnDif__", r"#endif" ], @@ -13,7 +13,8 @@ pats = [ [ r"(struct|union|enum)\s+(xen_?)?(\w)", r"\1 compat_\3" ], [ r"@KeeP@", r"" ], [ r"_t([^\w]|$)", r"_compat_t\1" ], - [ r"(8|16|32|64)_compat_t([^\w]|$)", r"\1_t\2" ], + [ r"(8|16|32|64_aligned)_compat_t([^\w]|$)", r"\1_t\2" ], + [ r"(\su?int64(_compat)?)_T([^\w]|$)", r"\1_t\3" ], [ r"(^|[^\w])xen_?(\w*)_compat_t([^\w]|$$)", r"\1compat_\2_t\3" ], [ r"(^|[^\w])XEN_?", r"\1COMPAT_" ], [ r"(^|[^\w])Xen_?", r"\1Compat_" ], --- a/xen/tools/compat-build-source.py +++ b/xen/tools/compat-build-source.py @@ -9,6 +9,7 @@ pats = [ [ r"^\s*#\s*endif /\* (XEN_HAVE.*) \*/\s+", r"__EnDif__" ], [ r"^\s*#\s*define\s+([A-Z_]*_GUEST_HANDLE)", r"#define HIDE_\1" ], [ r"^\s*#\s*define\s+([a-z_]*_guest_handle)", r"#define hide_\1" ], + [ r"^\s*#\s*define\s+(u?int64)_aligned_t\s.*", r"typedef \1_T __attribute__((aligned(4))) \1_compat_T;" ], [ r"XEN_GUEST_HANDLE(_[0-9A-Fa-f]+)?", r"COMPAT_HANDLE" ], ]; From xen-devel-bounces@lists.xenproject.org Mon Jun 29 16:30:55 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 16:30:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpwg0-0006kx-T3; Mon, 29 Jun 2020 16:30:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpwfz-0006ks-Ay for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 16:30:35 +0000 X-Inumbo-ID: dac22ff8-ba25-11ea-8496-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id dac22ff8-ba25-11ea-8496-bc764e2007e4; Mon, 29 Jun 2020 16:30:34 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: +ca87G5nQzXjBgntDua5wuz/qXSNgB2xWerTUwT5wd9htlNDZKzCaCpXkpW+nwvfdt8z2ZXe6W 8obzO21ykElma7LwgMf8A8BGT1aS/8yARGIgQL+PlQnh424gQKS2AhC96reOZkr0SLbgoOVtM4 j2UCIEmaHCmu1iJE3dwdpYoiys9TuPZgaHW0pv3Yt/NNXVN7cZTJNdoAO428R7WDS7rmH/N5tW efYn23cwUb3HuW/I1uytI+/KCa6WgbC17YnEmUGFrvQ4RX4ziMhHeqXPDbBD9NyzT4ehu6r4Qm Coo= X-SBRS: 2.7 X-MesageID: 21504044 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,295,1589256000"; d="scan'208";a="21504044" Date: Mon, 29 Jun 2020 17:30:27 +0100 From: Anthony PERARD To: Jan Beulich Subject: Re: [PATCH] build: tweak variable exporting for make 3.82 Message-ID: <20200629163027.GA2030@perard.uk.xensource.com> References: <0677fe2a-9ea1-7b3c-e212-4a2478537459@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <0677fe2a-9ea1-7b3c-e212-4a2478537459@suse.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , George Dunlap , Andrew Cooper , Ian Jackson , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 05:02:30PM +0200, Jan Beulich wrote: > While I've been running into an issue here only because of an additional > local change I'm carrying, to be able to override just the compiler in > $(XEN_ROOT)/.config (rather than the whole tool chain), in > config/StdGNU.mk: > > ifeq ($(filter-out default undefined,$(origin CC)),) > > I'd like to propose to nevertheless correct the underlying issue: > Exporting an unset variable changes its origin from "undefined" to > "file". This comes into effect because of our adding of -rR to > MAKEFLAGS, which make 3.82 wrongly applies also upon re-invoking itself > after having updated auto.conf{,.cmd}. > > Move the export statement past $(XEN_ROOT)/config/$(XEN_OS).mk inclusion > such that the variables already have their designated values at that > point, while retaining their initial origin up to the point they get > defined. > > Signed-off-by: Jan Beulich > > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -17,8 +17,6 @@ export XEN_BUILD_HOST ?= $(shell hostnam > PYTHON_INTERPRETER := $(word 1,$(shell which python3 python python2 2>/dev/null) python) > export PYTHON ?= $(PYTHON_INTERPRETER) > > -export CC CXX LD > - > export BASEDIR := $(CURDIR) > export XEN_ROOT := $(BASEDIR)/.. > > @@ -42,6 +40,8 @@ export TARGET_ARCH := $(shell echo $ > # Allow someone to change their config file > export KCONFIG_CONFIG ?= .config > > +export CC CXX LD > + > .PHONY: default > default: build That patch is fine and it is probably better to export a variable that has a value rather than before the variable is set. Reviewed-by: Anthony PERARD Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Mon Jun 29 17:32:02 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 17:32:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpxd7-0003FN-Jb; Mon, 29 Jun 2020 17:31:41 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpxd5-0003FI-Pr for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 17:31:39 +0000 X-Inumbo-ID: 632c20f8-ba2e-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 632c20f8-ba2e-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 17:31:38 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 973D423A9E; Mon, 29 Jun 2020 17:31:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593451898; bh=pZLE0/dEHdwtp1oF+MjAXEqXTqNgCVHIaSv2gtI5f9s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=f8qUjanzM6fLEdaY60FSVA2CwIpF7kO3WkjuSqnlYh2jAqvKu+o1wsZn6UNERVwIF d5ckFCxNes91ngGOaJMu6uCEBfCbVaipt8RQGri9T2gF+zuWrwVtmqNzy7jmm4wNgB LkU2C0N/4opuiae+izYpmAUFEmj7mr1ZBpWbIpd4= Date: Mon, 29 Jun 2020 10:31:37 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Xiaofei Tan Subject: Re: [PATCH] arm/xen: remove the unused macro GRANT_TABLE_PHYSADDR In-Reply-To: <1593305826-28279-1-git-send-email-tanxiaofei@huawei.com> Message-ID: References: <1593305826-28279-1-git-send-email-tanxiaofei@huawei.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, sstabellini@kernel.org, linux-kernel@vger.kernel.org, linuxarm@huawei.com, linux@armlinux.org.uk, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Sun, 28 Jun 2020, Xiaofei Tan wrote: > Fix the following sparse warning: > > arch/arm64/xen/../../arm/xen/enlighten.c:244: warning: macro > "GRANT_TABLE_PHYSADDR" is not used [-Wunused-macros] > > It is an isolated macro, and should be removed when its last user > was deleted in the following commit 3cf4095d7446 ("arm/xen: Use > xen_xlate_map_ballooned_pages to setup grant table") > > Signed-off-by: Xiaofei Tan Reviewed-by: Stefano Stabellini > --- > arch/arm/xen/enlighten.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c > index fd4e1ce1..e93145d 100644 > --- a/arch/arm/xen/enlighten.c > +++ b/arch/arm/xen/enlighten.c > @@ -241,7 +241,6 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname, > * see Documentation/devicetree/bindings/arm/xen.txt for the > * documentation of the Xen Device Tree format. > */ > -#define GRANT_TABLE_PHYSADDR 0 > void __init xen_early_init(void) > { > of_scan_flat_dt(fdt_find_hyper_node, NULL); > -- > 2.7.4 > From xen-devel-bounces@lists.xenproject.org Mon Jun 29 17:45:56 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 17:45:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpxqo-0004Bs-Su; Mon, 29 Jun 2020 17:45:50 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpxqn-0004BW-Pq for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 17:45:49 +0000 X-Inumbo-ID: 5b435a80-ba30-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 5b435a80-ba30-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 17:45:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kI+dr4nXpJzzq1M641ow/vAnN/4S/42KIdrN09v8UnU=; b=IE0VLPZmbnM93wJj+75WF56U4 MeySuRYTCPBW8acD7IjhPqcq1Dr7Q6Wtv+Do5Y0b+yZRKf3k2cUueNYzTcV9jtaKOlzwcLKW864kw 86SgyOFPUZiWpFpJDFAYmBaZEhUoeHSCHea1uItHmfH1Iez4o6NmxWorMprdzlKhMy3Qo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpxqh-0000io-Ks; Mon, 29 Jun 2020 17:45:43 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpxqh-0003b8-88; Mon, 29 Jun 2020 17:45:43 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpxqh-0001po-7Y; Mon, 29 Jun 2020 17:45:43 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151451: all pass - PUSHED X-Osstest-Versions-This: ovmf=0f01cec52f4794777feb067e4fa0bfcedfdc124e X-Osstest-Versions-That: ovmf=0060e0a694f3f249c3ec081b0e61287c36f64ebb From: osstest service owner Date: Mon, 29 Jun 2020 17:45:43 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151451 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151451/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 0f01cec52f4794777feb067e4fa0bfcedfdc124e baseline version: ovmf 0060e0a694f3f249c3ec081b0e61287c36f64ebb Last test of basis 151444 2020-06-29 02:39:29 Z 0 days Testing same since 151451 2020-06-29 10:12:21 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Zhichao Gao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 0060e0a694..0f01cec52f 0f01cec52f4794777feb067e4fa0bfcedfdc124e -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Mon Jun 29 18:47:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 18:47:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpyny-0000iS-Pd; Mon, 29 Jun 2020 18:46:58 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpynx-0000i8-7H for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 18:46:57 +0000 X-Inumbo-ID: e3d28648-ba38-11ea-858f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e3d28648-ba38-11ea-858f-12813bfff9fa; Mon, 29 Jun 2020 18:46:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=chMBMVKlJ55mG+7gBUdsA+8VrmRnC/avpgQ5DlQ/dus=; b=ICVUO2ipKBKKGpGWEAbhOjj4M MCupm+TftcXNInkCpuG+zQkjgcmlbzpnfBfA8sgASpfnm/ITot1a79tLhfRajNvrb7R5Re7Ji6BD1 C2YqINSJHgjAf1/2ZwEL6+1LBAixIGOCAPr860MDTpYp8SAlxhIevvpJ76uFrvGmyyraw=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpyno-0001t7-L9; Mon, 29 Jun 2020 18:46:48 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpyno-0006MK-9r; Mon, 29 Jun 2020 18:46:48 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpyno-0004xc-90; Mon, 29 Jun 2020 18:46:48 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151445: regressions - trouble: broken/fail/pass X-Osstest-Failures: qemu-mainline:test-armhf-armhf-xl-credit1::broken:regression qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-armhf-armhf-xl-credit1:host-install(4):broken:heisenbug qemu-mainline:test-arm64-arm64-xl-seattle:xen-boot:fail:heisenbug qemu-mainline:test-armhf-armhf-xl-rtds:guest-start.2:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=e7651153a8801dad6805d450ea8bef9b46c1adf5 X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Mon, 29 Jun 2020 18:46:48 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151445 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151445/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit1 broken test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit1 4 host-install(4) broken pass in 151435 test-arm64-arm64-xl-seattle 7 xen-boot fail in 151435 pass in 151445 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds 17 guest-start.2 fail in 151435 blocked in 151065 test-armhf-armhf-xl-credit1 13 migrate-support-check fail in 151435 never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail in 151435 never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: qemuu e7651153a8801dad6805d450ea8bef9b46c1adf5 baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 16 days Failing since 151101 2020-06-14 08:32:51 Z 15 days 15 attempts Testing same since 151435 2020-06-28 15:39:59 Z 1 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Ahmed Karaman Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Andrew Jones Ani Sinha Anthony PERARD Ard Biesheuvel Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Cleber Rosa Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé Daniele Buono David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Finn Thain Geoffrey McRae Gerd Hoffmann Greg Kurz Guenter Roeck Gustavo Romero Helge Deller Huacai Chen Huacai Chen Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jay Zhou Jean-Christophe Dubois Jiaxun Yang Jingqi Liu John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Liao Pingfang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marcelo Tosatti Marek Marczykowski-Górecki Mark Cave-Ayland Markus Armbruster Masahiro Yamada Max Filippov Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Raphael Norwitz Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Shameer Kolothum Stefan Berger Stefan Berger Stefan Hajnoczi Tao Xu Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 broken test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary broken-job test-armhf-armhf-xl-credit1 broken broken-step test-armhf-armhf-xl-credit1 host-install(4) Not pushing. (No revision log; it would be 14356 lines long.) From xen-devel-bounces@lists.xenproject.org Mon Jun 29 19:21:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 19:21:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpzLA-0003vh-H3; Mon, 29 Jun 2020 19:21:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpzL9-0003vc-Hf for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 19:21:15 +0000 X-Inumbo-ID: b1f63214-ba3d-11ea-b7bb-bc764e2007e4 Received: from smtp-fw-33001.amazon.com (unknown [207.171.190.10]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b1f63214-ba3d-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 19:21:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1593458474; x=1624994474; h=date:from:to:cc:message-id:references:mime-version: content-transfer-encoding:in-reply-to:subject; bh=kLlA5RN03Xc0rLgTC7sQtfZJgq55+f+4l+tD0cUCuiI=; b=TQrtjf2twU9L2fFI780jIm7e8B9dsvfahcSTtyBGmo8s5kfNbNlQa8py SS6EuXoFnbUEaltepowZ89rKkG4DrBrAoXqcz7q+Lm0EQ+qUcUe38tANL 6mkKl6tGyhMPcRbKPNzrTUPwu1dN1hv/Tbg7Qotxpj2E1ph7UViC7vcTE w=; IronPort-SDR: TFk9Ap13BSopn0WzM+ofsaWep3goJJ1oYevrRH/gIxCL0UUWZBH5DxVgfAHkikcgrsKcEgr33D uj0sRPYPNVsQ== X-IronPort-AV: E=Sophos;i="5.75,295,1589241600"; d="scan'208";a="54787643" Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2a-6e2fc477.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 29 Jun 2020 19:20:55 +0000 Received: from EX13MTAUEE002.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2a-6e2fc477.us-west-2.amazon.com (Postfix) with ESMTPS id 942DDA2269; Mon, 29 Jun 2020 19:20:53 +0000 (UTC) Received: from EX13D08UEE004.ant.amazon.com (10.43.62.182) by EX13MTAUEE002.ant.amazon.com (10.43.62.24) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 19:20:35 +0000 Received: from EX13MTAUEE002.ant.amazon.com (10.43.62.24) by EX13D08UEE004.ant.amazon.com (10.43.62.182) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 29 Jun 2020 19:20:35 +0000 Received: from dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (172.22.96.68) by mail-relay.amazon.com (10.43.62.224) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Mon, 29 Jun 2020 19:20:35 +0000 Received: by dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com (Postfix, from userid 4335130) id 5419940348; Mon, 29 Jun 2020 19:20:35 +0000 (UTC) Date: Mon, 29 Jun 2020 19:20:35 +0000 From: Anchal Agarwal To: Roger Pau =?iso-8859-1?Q?Monn=E9?= Message-ID: <20200629192035.GA13195@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> References: <7FD7505E-79AA-43F6-8D5F-7A2567F333AB@amazon.com> <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200617083528.GW735@Air-de-Roger> <20200619234312.GA24846@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200622083846.GF735@Air-de-Roger> <20200623004314.GA28586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200623081903.GP735@Air-de-Roger> <20200625183659.GA26586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200626091239.GA735@Air-de-Roger> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200626091239.GA735@Air-de-Roger> User-Agent: Mutt/1.5.21 (2010-09-15) Precedence: Bulk X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, Jun 26, 2020 at 11:12:39AM +0200, Roger Pau Monn wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On Thu, Jun 25, 2020 at 06:36:59PM +0000, Anchal Agarwal wrote: > > On Tue, Jun 23, 2020 at 10:19:03AM +0200, Roger Pau Monn wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > On Tue, Jun 23, 2020 at 12:43:14AM +0000, Anchal Agarwal wrote: > > > > On Mon, Jun 22, 2020 at 10:38:46AM +0200, Roger Pau Monn wrote: > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > > > > > > > > > On Fri, Jun 19, 2020 at 11:43:12PM +0000, Anchal Agarwal wrote: > > > > > > On Wed, Jun 17, 2020 at 10:35:28AM +0200, Roger Pau Monn wrote: > > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 16, 2020 at 09:49:25PM +0000, Anchal Agarwal wrote: > > > > > > > > On Thu, Jun 04, 2020 at 09:05:48AM +0200, Roger Pau Monn wrote: > > > > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > On Wed, Jun 03, 2020 at 11:33:52PM +0000, Agarwal, Anchal wrote: > > > > > > > > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > > > > > > > > + xenbus_dev_error(dev, err, "Freezing timed out;" > > > > > > > > > > > + "the device may become inconsistent state"); > > > > > > > > > > > > > > > > > > > > Leaving the device in this state is quite bad, as it's in a closed > > > > > > > > > > state and with the queues frozen. You should make an attempt to > > > > > > > > > > restore things to a working state. > > > > > > > > > > > > > > > > > > > > You mean if backend closed after timeout? Is there a way to know that? I understand it's not good to > > > > > > > > > > leave it in this state however, I am still trying to find if there is a good way to know if backend is still connected after timeout. > > > > > > > > > > Hence the message " the device may become inconsistent state". I didn't see a timeout not even once on my end so that's why > > > > > > > > > > I may be looking for an alternate perspective here. may be need to thaw everything back intentionally is one thing I could think of. > > > > > > > > > > > > > > > > > > You can manually force this state, and then check that it will behave > > > > > > > > > correctly. I would expect that on a failure to disconnect from the > > > > > > > > > backend you should switch the frontend to the 'Init' state in order to > > > > > > > > > try to reconnect to the backend when possible. > > > > > > > > > > > > > > > > > From what I understand forcing manually is, failing the freeze without > > > > > > > > disconnect and try to revive the connection by unfreezing the > > > > > > > > queues->reconnecting to backend [which never got diconnected]. May be even > > > > > > > > tearing down things manually because I am not sure what state will frontend > > > > > > > > see if backend fails to to disconnect at any point in time. I assumed connected. > > > > > > > > Then again if its "CONNECTED" I may not need to tear down everything and start > > > > > > > > from Initialising state because that may not work. > > > > > > > > > > > > > > > > So I am not so sure about backend's state so much, lets say if xen_blkif_disconnect fail, > > > > > > > > I don't see it getting handled in the backend then what will be backend's state? > > > > > > > > Will it still switch xenbus state to 'Closed'? If not what will frontend see, > > > > > > > > if it tries to read backend's state through xenbus_read_driver_state ? > > > > > > > > > > > > > > > > So the flow be like: > > > > > > > > Front end marks XenbusStateClosing > > > > > > > > Backend marks its state as XenbusStateClosing > > > > > > > > Frontend marks XenbusStateClosed > > > > > > > > Backend disconnects calls xen_blkif_disconnect > > > > > > > > Backend fails to disconnect, the above function returns EBUSY > > > > > > > > What will be state of backend here? > > > > > > > > > > > > > > Backend should stay in state 'Closing' then, until it can finish > > > > > > > tearing down. > > > > > > > > > > > > > It disconnects the ring after switching to connected state too. > > > > > > > > Frontend did not tear down the rings if backend does not switches the > > > > > > > > state to 'Closed' in case of failure. > > > > > > > > > > > > > > > > If backend stays in CONNECTED state, then even if we mark it Initialised in frontend, backend > > > > > > > > > > > > > > Backend will stay in state 'Closing' I think. > > > > > > > > > > > > > > > won't be calling connect(). {From reading code in frontend_changed} > > > > > > > > IMU, Initialising will fail since backend dev->state != XenbusStateClosed plus > > > > > > > > we did not tear down anything so calling talk_to_blkback may not be needed > > > > > > > > > > > > > > > > Does that sound correct? > > > > > > > > > > > > > > I think switching to the initial state in order to try to attempt a > > > > > > > reconnection would be our best bet here. > > > > > > > > > > > > > It does not seems to work correctly, I get hung tasks all over and all the > > > > > > requests to filesystem gets stuck. Backend does shows the state as connected > > > > > > after xenbus_dev_suspend fails but I think there may be something missing. > > > > > > I don't seem to get IO interrupts thereafter i.e hitting the function blkif_interrupts. > > > > > > I think just marking it initialised may not be the only thing. > > > > > > Here is a short description of what I am trying to do: > > > > > > So, on timeout: > > > > > > Switch XenBusState to "Initialized" > > > > > > unquiesce/unfreeze the queues and return > > > > > > mark info->connected = BLKIF_STATE_CONNECTED > > > > > > > > > > If xenbus state is Initialized isn't it wrong to set info->connected > > > > > == CONNECTED? > > > > > > > > > Yes, you are right earlier I was marking it explicitly but that was not right, > > > > the connect path for blkfront will do that. > > > > > You should tear down all the internal state (like a proper close)? > > > > > > > > > Isn't that similar to disconnecting in the first place that failed during > > > > freeze? Do you mean re-try to close but this time re-connect after close > > > > basically do everything you would at "restore"? > > > > > > Last time I checked blkfront supported reconnections (ie: disconnect > > > from a backend and connect again). I was assuming we could apply the > > > same here on timeout, and just follow the same path where the frontend > > > waits indefinitely for the backend to close and then attempts to > > > reconnect. > > > > > > > Also, I experimented with that and it works intermittently. I want to take a > > > > step back on this issue and ask few questions here: > > > > 1. Is fixing this recovery a blocker for me sending in a V2 version? > > > > > > At the end of day it's your feature. I would certainly prefer for it > > > to work as good as possible, this being a recovery in case of failure > > > just make sure it does something sane (ie: crash/close the frontend) > > > and add a TODO note. > > > > > > > 2. In our 2-3 years of supporting this feature at large scale we haven't seen this issue > > > > where backend fails to disconnect. What we are trying to do here is create a > > > > hypothetical situation where we leave backend in Closing state and try and see how it > > > > recovers. The reason why I think it "may not" occur and the timeout of 5HZ is > > > > sufficient is because we haven't come across even a single use-case where it > > > > caused hibernation to fail. > > > > The reason why I think "it may" occur is if we are running a really memory > > > > intensive workload and ring is busy and is unable to complete all the requests > > > > in the given timeout. This is very unlikely though. > > > > > > As said above I would generally prefer for code to handle possible > > > failures the best way, and hence I think here it would be nice to > > > fallback to the normal disconnect path and just wait for the backend > > > to close. > > > > > Do you mind throwing some light in here, what that path may be, if its > > straight forward to fix I would like to debug it a bit more. May be I am > > missing some of the context here. > > So the frontend should do: > > - Switch to Closed state (and cleanup everything required). > - Wait for backend to switch to Closed state (must be done > asynchronously, handled in blkback_changed). > - Switch frontend to XenbusStateInitialising, that will in turn force > the backend to switch to XenbusStateInitWait. > - After that it should just follow the normal connection procedure. > > I think the part that's missing is the frontend doing the state change > to XenbusStateInitialising when the backend switches to the Closed > state. > > > I was of the view we may just want to mark frontend closed which should do > > the job of freeing resources and then following the same flow as > > blkfront_restore. That does not seems to work correctly 100% of the time. > > I think the missing part is that you must wait for the backend to > switch to the Closed state, or else the switch to > XenbusStateInitialising won't be picked up correctly by the backend > (because it's still doing it's cleanup). > > Using blkfront_restore might be an option, but you need to assert the > backend is in the initial state before using that path. > Yes, I agree and I make sure that XenbusStateInitialising only triggers on frontend once backend is disconnected. msleep in a loop not that graceful but works. Frontend only switches to XenbusStateInitialising once it sees backend as Closed. The issue here is and may require more debugging is: 1. Hibernate instance->Closing failed, artificially created situation by not marking frontend Closed in the first place during freezing. 2. System comes back up fine restored to 'backend connected'. 3. Re-run (1) again without reboot 4. (4) fails to recover basically freezing does not fail at all which is weird because it should timeout as it passes through same path. It hits a BUG in talk_to_blkback() and instance crashes. Anyways just wanted to paint out a picture that there may be something more happening here which needs a persistent debugging. > > > You likely have this very well tuned to your own environment and > > > workloads, since this will now be upstream others might have more > > > contended systems where it could start to fail. > > > > > I agree, however, this is also from the testing I did with 100 of runs > > outside of EC2 running few tests of my own. > > > > 3) Also, I do not think this may be straight forward to fix and expect > > > > hibernation to work flawlessly in subsequent invocations. I am open to > > > > all suggestions. > > > > > > Right, adding a TODO would seem appropriate then. > > > > > Just to double check, I will send in a V2 with this marked as TO-DO? > > I think that's fine. Please clearly describe what's missing, so > others know what they might have to implement. > Ack. > Thanks, Roger. > Thanks, Anchal From xen-devel-bounces@lists.xenproject.org Mon Jun 29 19:35:26 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 19:35:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpzYl-0004sc-Sq; Mon, 29 Jun 2020 19:35:19 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpzYk-0004sX-IL for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 19:35:18 +0000 X-Inumbo-ID: a8bd6e36-ba3f-11ea-858f-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a8bd6e36-ba3f-11ea-858f-12813bfff9fa; Mon, 29 Jun 2020 19:35:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=e5d3XftqDK5hVvur02rEDJcEXqviBlNbQ76SfSDJGwg=; b=537lac6L0USwiAfdg7TcdWoUt Yw2U+/eWFdCcEj1xNz3WKgqomikDJKfmT8DGhI8AEef+Hht1O3uEzJNw9uCKYPO0EVstmDX0GZD6N YCY8YbXQ6dBSUzPFg8shetFD/77qvVXNH9l6nBTzUerrhMcTZbgdyLCIay3DUkusekiLA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpzYi-0002mu-0U; Mon, 29 Jun 2020 19:35:16 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpzYh-00080a-N0; Mon, 29 Jun 2020 19:35:15 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpzYh-00064B-MA; Mon, 29 Jun 2020 19:35:15 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151448: tolerable FAIL X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=88cfd062e8318dfeb67c7d2eb50b6cd224b0738a X-Osstest-Versions-That: xen=88cfd062e8318dfeb67c7d2eb50b6cd224b0738a From: osstest service owner Date: Mon, 29 Jun 2020 19:35:15 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151448 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151448/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151437 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151437 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151437 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151437 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151437 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151437 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151437 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151437 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151437 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a baseline version: xen 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a Last test of basis 151448 2020-06-29 06:27:51 Z 0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Published tested tree is already up to date. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 20:01:22 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 20:01:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpzxg-0007MU-2y; Mon, 29 Jun 2020 20:01:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpzxe-0007MP-Nx for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 20:01:02 +0000 X-Inumbo-ID: 411cdba0-ba43-11ea-8592-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 411cdba0-ba43-11ea-8592-12813bfff9fa; Mon, 29 Jun 2020 20:01:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3X0FhQkLHnwT2PD8fwbsSqEARgl/2yFwh2SlhmgwrU4=; b=CK7nX4hId5OdJ//WFnMy5zHCS jGB8dc6IwJMzDzIO4QerUG/pi3OmMLwAddHTQHb5J3P21h30+k7IjcMunZ2i9aiq24YJePPNGgrBB EJF8SKrK4vgrLXR0YI+dJgJZNGgLM7Awum5E6H4Svrz+kNnocVLUo1HGp/Au1e/C+VQ38=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jpzxc-0003Lu-E3; Mon, 29 Jun 2020 20:01:00 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jpzxb-0000zO-SH; Mon, 29 Jun 2020 20:00:59 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jpzxb-00068J-Rf; Mon, 29 Jun 2020 20:00:59 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151457: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=0e2e54966af556f4047c1048855c4a071028a32d X-Osstest-Versions-That: xen=da53345dd5ff7d3a34e83587fd375c0b7722f46c From: osstest service owner Date: Mon, 29 Jun 2020 20:00:59 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151457 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151457/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 0e2e54966af556f4047c1048855c4a071028a32d baseline version: xen da53345dd5ff7d3a34e83587fd375c0b7722f46c Last test of basis 151454 2020-06-29 13:01:35 Z 0 days Testing same since 151457 2020-06-29 17:01:22 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Roger Pau Monné jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git da53345dd5..0e2e54966a 0e2e54966af556f4047c1048855c4a071028a32d -> smoke From xen-devel-bounces@lists.xenproject.org Mon Jun 29 23:46:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 23:46:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq3Tf-00089t-4r; Mon, 29 Jun 2020 23:46:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq3Td-00089n-5z for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 23:46:17 +0000 X-Inumbo-ID: b5e71332-ba62-11ea-b7bb-bc764e2007e4 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b5e71332-ba62-11ea-b7bb-bc764e2007e4; Mon, 29 Jun 2020 23:46:11 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 295E220780; Mon, 29 Jun 2020 23:46:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593474370; bh=WDGpgzzhrbi6jQoYwzCQkNgOhgPsy28c3rLvtZR7RUk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Pf5MDB7DOBdEr6c0RglkzzT1r3dTYzbt2u/c7A3AdRs/o8UoRl6QypV4aghq8AZ4i IJAPil2gChGThnm9ZkxQxnhckYBUxA9BiGW12zOqqiKnj7oshyDxTRcpd1NDKRLeO1 Tc1pH31YrW/NkNz+YyAWrTi3TIP+BTENO+WdOpEk= Date: Mon, 29 Jun 2020 16:46:09 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: "Michael S. Tsirkin" Subject: Re: [PATCH] xen: introduce xen_vring_use_dma In-Reply-To: <20200626110629-mutt-send-email-mst@kernel.org> Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Peng Fan , Stefano Stabellini , konrad.wilk@oracle.com, jasowang@redhat.com, x86@kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, iommu@lists.linux-foundation.org, linux-imx@nxp.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, linux-arm-kernel@lists.infradead.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 26 Jun 2020, Michael S. Tsirkin wrote: > On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote: > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma APIs to map the > > > > > > > > ring: when xen_swiotlb is enabled the dma API is required. When it is > > > > > > > > disabled, it is not required. > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to translate > > > > > > foreign mappings (memory coming from other VMs) to physical addresses. > > > > > > On x86, it also uses dma_ops to translate Linux's idea of a physical > > > > > > address into a real physical address (this is unneeded on ARM.) > > > > > > > > > > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be used on Xen/x86 > > > > > > always and on Xen/ARM if Linux is Dom0 (because it has foreign > > > > > > mappings.) That is why we have the if (xen_domain) return true; in > > > > > > vring_use_dma_api. > > > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* > > > > > forces DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > > > > > Unfortunately as a result Xen never got around to > > > > > properly setting VIRTIO_F_IOMMU_PLATFORM. > > > > > > > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this because > > > > the usage of swiotlb_xen is not a property of virtio, > > > > > > > > > Basically any device without VIRTIO_F_ACCESS_PLATFORM > > > (that is it's name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is > > > what linux calls it) is declared as "special, don't follow normal rules > > > for access". > > > > > > So yes swiotlb_xen is not a property of virtio, but what *is* a property > > > of virtio is that it's not special, just a regular device from DMA POV. > > > > I am trying to understand what you meant but I think I am missing > > something. > > > > Are you saying that modern virtio should always have > > VIRTIO_F_ACCESS_PLATFORM, hence use normal dma_ops as any other devices? > > I am saying it's a safe default. Clear VIRTIO_F_ACCESS_PLATFORM if you > have some special needs e.g. you are very sure it's ok to bypass DMA > ops, or you need to support a legacy guest (produced in the window > between virtio 1 support in 2014 and support for > VIRTIO_F_ACCESS_PLATFORM in 2016). Ok thanks. I understand and it makes sense to me. > > > > > > You might have noticed that I missed one possible case above: Xen/ARM > > > > > > DomU :-) > > > > > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even initialized. So if > > > > > > (xen_domain) return true; would give the wrong answer in that case. > > > > > > Linux would end up calling the "normal" dma_ops, not swiotlb-xen, and > > > > > > the "normal" dma_ops fail. > > > > > > > > > > > > > > > > > > The solution I suggested was to make the check in vring_use_dma_api more > > > > > > flexible by returning true if the swiotlb_xen is supposed to be used, > > > > > > not in general for all Xen domains, because that is what the check was > > > > > > really meant to do. > > > > > > > > > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is wrong with that? > > > > > > > > swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops are the > > > > ones that are used. So you are saying, why don't we fix the default > > > > dma_ops to work with virtio? > > > > > > > > It is bad that the default dma_ops crash with virtio, so yes I think it > > > > would be good to fix that. However, even if we fixed that, the if > > > > (xen_domain()) check in vring_use_dma_api is still a problem. > > > > > > Why is it a problem? It just makes virtio use DMA API. > > > If that in turn works, problem solved. > > > > You are correct in the sense that it would work. However I do think it > > is wrong for vring_use_dma_api to enable dma_ops/swiotlb-xen for Xen/ARM > > DomUs that don't need it. There are many different types of Xen guests, > > Xen x86 is drastically different from Xen ARM, it seems wrong to treat > > them the same way. > > I could imagine some future Xen hosts setting a flag somewhere in the > platform capability saying "no xen specific flag, rely on > "VIRTIO_F_ACCESS_PLATFORM". Then you set that accordingly in QEMU. > How about that? Yes, that would be fine and there is no problem implementing something like that when we get virtio support in Xen. Today there are still no virtio interfaces provided by Xen to ARM guests (no virtio-block/net, etc.) In fact, in both cases we are discussing virtio is *not* provided by Xen; it is a firmware interface to something entirely different: 1) virtio is used to talk to a remote AMP processor (RPMesg) 2) virtio is used to talk to a secure-world firmware/OS (Trusty) VIRTIO_F_ACCESS_PLATFORM is not set by Xen in these cases but by RPMesg and by Trusty respectively. I don't know if Trusty should or should not set VIRTIO_F_ACCESS_PLATFORM, but I think Linux should still work without issues. The xen_domain() check in Linux makes it so that vring_use_dma_api returns the opposite value on native Linux compared to Linux as Xen/ARM DomU by "accident". By "accident" because there is no architectural reason why Linux Xen/ARM DomU should behave differently compared to native Linux in this regard. I hope that now it is clearer why I think the if (xen_domain()) check needs to be improved anyway, even if we fix generic dma_ops with virtio interfaces missing VIRTIO_F_ACCESS_PLATFORM. From xen-devel-bounces@lists.xenproject.org Mon Jun 29 23:49:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 29 Jun 2020 23:49:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq3WQ-0008IN-NF; Mon, 29 Jun 2020 23:49:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq3WP-0008IH-Vs for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 23:49:10 +0000 X-Inumbo-ID: 1f989b3e-ba63-11ea-85a8-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1f989b3e-ba63-11ea-85a8-12813bfff9fa; Mon, 29 Jun 2020 23:49:09 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7889C20780; Mon, 29 Jun 2020 23:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593474548; bh=YbTxDsPQ5DXse6zCMw0MuvKG3mwFGMtOfnE1ikxlpqo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oupK0XZKr1tf9ZlB/vvhwl1g6l2FOT5EFgGIhASbYWQH4kL3mAqIIY0pFydyMp7AX ofoJ8l5Iy8Aj26eVYnf5X4wsVYL6+cyWfbFqp0keEtaF2uTu23UBwDyP6etUS+vytZ X2bXG5S9JLED91Z9FLDjXkzy6mkStrMTTdctv8GQ= Date: Mon, 29 Jun 2020 16:49:07 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Peng Fan Subject: RE: [PATCH] xen: introduce xen_vring_use_dma In-Reply-To: Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , Stefano Stabellini , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "Michael S. Tsirkin" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "virtualization@lists.linux-foundation.org" , "linux-arm-kernel@lists.infradead.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 29 Jun 2020, Peng Fan wrote: > > > If that is the case, how is it possible that virtio breaks on ARM > > > using the default dma_ops? The breakage is not Xen related (except > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. Is the stack trace above for the RPMesg issue or for the Trusty issue? If it is the stack trace for RPMesg, can you also post the Trusty stack trace? Or are they indentical? From xen-devel-bounces@lists.xenproject.org Tue Jun 30 01:40:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 01:40:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5Fs-0002Wt-2C; Tue, 30 Jun 2020 01:40:12 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5Fq-0002Wo-ON for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 01:40:10 +0000 X-Inumbo-ID: 9f9716b2-ba72-11ea-85ad-12813bfff9fa Received: from EUR01-DB5-obe.outbound.protection.outlook.com (unknown [40.107.15.50]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9f9716b2-ba72-11ea-85ad-12813bfff9fa; Tue, 30 Jun 2020 01:40:06 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lwdYoXgJsqF/Ba6f9pApxpysKoUGdA2aLQE10N31TJ6BUeJLPvHuwOeW7KUYM61WLVknYhH/LXLDFaIkem4FsW30dBiw48r0n5Y08mhgKazIGmUIvepqFQ8q+prHd6cvWf5YpKmIZ/6dY5ckrdkDG+Cb9x3knOnWo62GMscpCpBvyCqmlq72UZE9lGgPRYO9vLvQpt6n6ZBRcvsWw/2PABBkN6uiOgCxK+yOD6XEeu2zf/hUqD12BcIBRlZ6MHN0psOWifZ0MYHWJZTVIAYfqnKQxtv38Tt18LQWQU7j5kF4pZydRkoxYiQG68D6Wct3Uc1Af/IwT6zkWby26Odf9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Os/L3ofogs4QnE3I4j6ChyfYRUtY/PkOePGOECaI4Rw=; b=XS0p9SIQbUw2hbz3kgfL9boi2YDEnv4ZfgFcS19SDOU+JTI063UY7mYWCOQ/FAcLo8BYBspe5l3UIDapVXdmjL3V1gxynbJoYaHjxpT4HPExuBh93QVsfsE8bwdc2VoNsEGLzQOsC7h0WcEjPtFqzU33ciheDrRfOX76BjEH01uHMvzkXwBBsvuc217oIF7KdlAKQh32TmpnGxykvPo9BkbHEDZtmpSK0fCSZsNRAEtouSjrM5mqjPuPCjeGpg3GlhblLkQLuAhhGtdRP9w+HNto3NRcVmx2riYUW7geRqfzP36F5qrxjOuiW6iyJa0rsHk6rJqVonGgP4q8KFjz0Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass header.d=nxp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Os/L3ofogs4QnE3I4j6ChyfYRUtY/PkOePGOECaI4Rw=; b=SIUtU52KmEIjVdAzSMkzw43JN60lwgwW9mb5JEwJZXGyO/ajajW8uoez8Ru40WfHuI20iwoz2VlJWEkTPCd7XGlKH6pZA3GQ0eUYP2eNzY9bfp0qU00+4cuDVuqARY1J6RCjqgmWaW/B2OV+DoSzwvAPclfi9q094UUmqatI6r0= Received: from AM5PR0402MB2756.eurprd04.prod.outlook.com (2603:10a6:203:99::22) by AM6PR0402MB3414.eurprd04.prod.outlook.com (2603:10a6:209:3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Tue, 30 Jun 2020 01:40:04 +0000 Received: from AM5PR0402MB2756.eurprd04.prod.outlook.com ([fe80::c9df:97b8:717f:4026]) by AM5PR0402MB2756.eurprd04.prod.outlook.com ([fe80::c9df:97b8:717f:4026%11]) with mapi id 15.20.3131.027; Tue, 30 Jun 2020 01:40:04 +0000 From: Peng Fan To: Stefano Stabellini Subject: RE: [PATCH] xen: introduce xen_vring_use_dma Thread-Topic: [PATCH] xen: introduce xen_vring_use_dma Thread-Index: AQHWSgTusARd8c8cRkWwDit233DtZajneYoAgACU6oCAAC7QAIAAEpoAgAAGSwCAAUK2gIABcSaAgAPk6cCAAVzJgIAAHp3A Date: Tue, 30 Jun 2020 01:40:04 +0000 Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=nxp.com; x-originating-ip: [119.31.174.71] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b75792b5-e5d1-4c0b-081b-08d81c968338 x-ms-traffictypediagnostic: AM6PR0402MB3414: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0450A714CB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7WCT6RiseFesBShkHVBnV2FCzUhsw8gvSHLEH4mVyVFri8AEkPA8XiQbkCXUGwvzDPU96bmzhKzktp9QQ8+2zquY5HE4fNyyop0COeDZ1Yh+ULDSAy2ShKl3GJiDcIIW7LmwPT0Qxen574QCunXvZpNgS7DrgumeytRCOuhAlaQl3xAZdeQd4cq2GghAwMSAICfZkV/OcEprRoY+BEkxCgv8TFPVhgAxDZFmqWzSY3UbshN5yGyifVbcaRYnOrFsVuGH7/2NCumsioPwhk7PChPmh9Ch7tp0rG9Mp2sO9GTyntnrehdCNjzBEkAXCBAXwY3awM6R5m4zsfVLB8oEAw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5PR0402MB2756.eurprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(376002)(39860400002)(366004)(136003)(4326008)(33656002)(71200400001)(54906003)(55016002)(478600001)(2906002)(8936002)(316002)(64756008)(66946007)(5660300002)(186003)(8676002)(26005)(66446008)(66556008)(66476007)(7416002)(76116006)(6506007)(86362001)(6916009)(7696005)(9686003)(44832011)(83380400001)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: GbS6ZBFkKhkkm1Av9YeK/lLrX4eW+v1S3Pktq12AahC54zKYzQ0h5BG6y1U208oNrMiHKAHpWB5ADzCekfPXNt0MSZvZlXwtkqiSgolUHeRHwU1xOiO8C+NtQbTYvyx5hayI2/pgdqAILf34V6KbeebG1W8js5rAp+u6mbgKXBlz/uj8fv8NqVkoOEVgd93U9MF2tOeBkDDfuUT7i1nxX4xblTqQW6Tshry9o6oFPmf7C46N/6vP4u1/J0oZxfXsiNnHlPkr9R11M1r2NtqkCsiKt/MFxoUvoQYlud2Diw9ozlmUCIxXZGg/pFuGqSpzsa0tcFZoRe5JLF2bqRwfhsfeNo9EXqWlfxGEPvCrlyA/GD01n2p/Lx5ZpWF3sjlp9iTMtMvOy7fKfTSW7Q6zQ8pul+sGAzrNHr/xLKbi9y3OoO7uXsH8fHWRIi+R6x1Gyu9hlZDpBynAOCPsaxDYHj85waI6oCswKUkQvz+LXmcw8aBx3d84IZ8OzExQ40tv Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM5PR0402MB2756.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b75792b5-e5d1-4c0b-081b-08d81c968338 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 01:40:04.4195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vptcANgzBq7lW9lMrp9tt+P5TCgJqX/u4747fKLCGFJF81+HJ12Z2GtjIoBRNLnsmx9joyCF9ud7c8Ld/2F8Sg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0402MB3414 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "virtualization@lists.linux-foundation.org" , "iommu@lists.linux-foundation.org" , "Michael S. Tsirkin" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "linux-arm-kernel@lists.infradead.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > Subject: RE: [PATCH] xen: introduce xen_vring_use_dma >=20 > On Mon, 29 Jun 2020, Peng Fan wrote: > > > > If that is the case, how is it possible that virtio breaks on ARM > > > > using the default dma_ops? The breakage is not Xen related (except > > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > > > vring_map_one_sg -> vring_use_dma_api > > > > -> dma_map_page > > > > -> __swiotlb_map_page > > > > ->swiotlb_map_page > > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > > dev_addr)), size, dir); > > > > However we are using per device dma area for rpmsg, phys_to_virt > > > > could not return a correct virtual address for virtual address in > > > > vmalloc area. Then kernel panic. > > > > > > > > I must be missing something. Maybe it is because it has to do with > RPMesg? > > > > > > I think it's an RPMesg bug, yes > > > > rpmsg bug is another issue, it should not use dma_alloc_coherent for > > reserved area, and use vmalloc_to_page. > > > > Anyway here using dma api will also trigger issue. >=20 > Is the stack trace above for the RPMesg issue or for the Trusty issue? The stack trace you pasted is rpmsg issue. > If it is the stack trace for RPMesg, can you also post the Trusty stack t= race? Or > are they indentical? There is no stack dump here. It successfully using swiotlb to do a map, but we actually no need swiotlb in domu to do the map. Thanks, Peng. From xen-devel-bounces@lists.xenproject.org Tue Jun 30 01:50:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 01:50:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5Py-0003Ol-2l; Tue, 30 Jun 2020 01:50:38 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5Px-0003Og-Ao for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 01:50:37 +0000 X-Inumbo-ID: 17972d72-ba74-11ea-bb8b-bc764e2007e4 Received: from mail-pl1-x644.google.com (unknown [2607:f8b0:4864:20::644]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 17972d72-ba74-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 01:50:36 +0000 (UTC) Received: by mail-pl1-x644.google.com with SMTP id u9so4212695pls.13 for ; Mon, 29 Jun 2020 18:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=xbDPOfO5dEbdEvgJJa4Ml3IePWDMkowsVt6h1wk1qyg=; b=N2fg+fr8mqvdKWpq9X9sEDS0YRXkxTaCEaHnSynv0E+CJmWBkqAxjGBhqoYQpIBufO onfhne3a+qibTxaHP2kik1llKVIdvui6mdH2hgy2xdnHGHwu6Le2LzVLnsL+BjBCMI3r NOoRqe/khCIJcI2yYujX13iu3UJyFh9iho2n3CeK172KdOuOdfQkvopN36wrBEQw6q7q xdS3samPZIlTqqPfLEPfAynW2LtOodTm/IGlvPwFh7BkNeiHdZRXugNEnX5vDN0jp/1Q JppX7rIRimsVdR8YZ7mmtUFujE3F/dwwXqjZM7DeuEpmeAss4ZnlUtFF4ahp4zJtYlVL TN4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xbDPOfO5dEbdEvgJJa4Ml3IePWDMkowsVt6h1wk1qyg=; b=c8dVXLbczI26gKVdzSKZAGgv+hQ7wqsjQcfgv9+HZfduyUB0lndw+6iaoSlkNUSHaV Y/QyQhgk2YGQSKKPA1zA9EMyq2b17gPG9HGOzhSi254CgM/u9ga4Sz89aIXDgV2Wd7pI Ryfq7OOhWRv0aIj4xoiCJo431rbCgXsoXo/KG9jCXGsh6uJO32fdZdL/sw4CsOgjSbTM 5hWpDpMb5iouhMwMP9LzgtxaLsvSS04lW18Ci+tAf5pcLamwYWDOWaUhiZR5UjNMYzmq 1SFnOqm5L94gwnoY9tqi0AsZVqNhAdPvaK/O2i96LTkPQIdDW4FVm1Q/VxH4G6hK/Ch3 TFCA== X-Gm-Message-State: AOAM5307klCCRmTMGR5m31gYDYkr7ih/r8r2lQnVxBki896085O6x+M+ 1pyGZPP4FjquNGt+lnQ3TTE= X-Google-Smtp-Source: ABdhPJwYSRXrEaDV1d+CJQ7e8CQjvlAOuwOviKCnwuwwolCNe1gAB3GOHaLDv7hzTlN5Pk2kDEv7oQ== X-Received: by 2002:a17:902:7e04:: with SMTP id b4mr7222010plm.295.1593481835725; Mon, 29 Jun 2020 18:50:35 -0700 (PDT) Received: from piano ([2601:1c2:4f00:c640:fc6:7318:8185:4d2d]) by smtp.gmail.com with ESMTPSA id z13sm782982pfq.220.2020.06.29.18.50.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 18:50:35 -0700 (PDT) Date: Mon, 29 Jun 2020 18:50:33 -0700 From: Bobby Eshleman To: Stefano Stabellini Subject: Re: [RFC XEN PATCH 00/23] xen: beginning support for RISC-V Message-ID: <20200630015033.GA8470@piano> References: <20200616035100.GA19383@piano> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "dan@dlrobertson.com" , "julien@xen.org" , "wl@xen.org" , "konrad.wilk@oracle.com" , "George.Dunlap@eu.citrix.com" , "andrew.cooper3@citrix.com" , "ian.jackson@eu.citrix.com" , "bobby.eshleman@starlab.io" , Alistair Francis , "jbeulich@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 16, 2020 at 01:16:10PM -0700, Stefano Stabellini wrote: > On Mon, 15 Jun 2020, Bobby Eshleman wrote: > > On Tue, Jun 16, 2020 at 01:10:17AM +0000, Alistair Francis wrote: > > > On Mon, 2020-06-15 at 18:03 -0700, Stefano Stabellini wrote: > > > > Any updates? I am looking forward to this :-) > > > > > > > It has been on a slow burn since I became a new dad (shortly after the RFC). > > I've gradually regained free time, and so I've been able to change that > > slow burn to a moderate burn in the last couple weeks. > > > > Most of my progress has been around build environment improvements. I've done > > some work stripping it down to the bare minimum required to build a new arch > > and rooting the commit history from there, and some work with incorporating it > > into the gitlab CI, containerizing the build and QEMU run, etc... > > > > As far as hypervisor status: I'm just about done with incorporating the boot > > module FDT parsing code, extracting kernel info and ram regions > > (taken/generalized from arch/arm), plus implementing the arch-specific pieces > > of domain_create(). > > > > On the verge of being able to dive into a guest kernel and see what breaks > > first :) > > > > I'm expected to commit an extra day or two per week in the next month or so at > > Vates, so this will considerably bump up my cadence in comparison to the last > > few months. > > Great to hear and congratulations! I'll stay tuned. Next time I'll try > to rebuild and run your series on QEMU, I might ask you for some help > with the setup. > Thanks! And absolutely, feel free :) From xen-devel-bounces@lists.xenproject.org Tue Jun 30 01:51:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 01:51:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5R1-0003Sz-Cm; Tue, 30 Jun 2020 01:51:43 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5R0-0003Ss-Jc for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 01:51:42 +0000 X-Inumbo-ID: 3e9a68da-ba74-11ea-8496-bc764e2007e4 Received: from mail-pl1-x641.google.com (unknown [2607:f8b0:4864:20::641]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3e9a68da-ba74-11ea-8496-bc764e2007e4; Tue, 30 Jun 2020 01:51:42 +0000 (UTC) Received: by mail-pl1-x641.google.com with SMTP id o1so1252515plk.1 for ; Mon, 29 Jun 2020 18:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=QcL0Zhl1N0pMgp2Kkm1GtLuYDs4t+krbYwO8zi652js=; b=RmMcKr+aj3J04hYD4Md41hjVR1MEd+7NN/yPHbRA6KJM78V9AGcpu2w4Fl+ozQlJUK xw0Fs9vP9Xu/FR3Pmxx/ZXqxwtlQ7UmM4dGwpIfWKBaDZC0PnBO/Cui2o3Q9f9jeCMRy cat0NFLGhZGX7MoP1i3Ez1wZWRemgGOyDmCj4GmxRi/X+dCToHiJKl5gotI/vI6WaOSV by0LKl5oLBYfHHGE3eACm/8RSfyBmE6Bqkvbk5c9Z5HpqzbS8jQf7E6SY56Tz4kLm1W4 Fkw0rtfVJ9VCiUSXaKPqoDZ/+d+CcrbWzwkG81X80CS2KKLwtkd65sEwMmjV8FBZnaRi UP7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=QcL0Zhl1N0pMgp2Kkm1GtLuYDs4t+krbYwO8zi652js=; b=BeopoYUPctldUWvs1Qp7odm/7fpSAtm5FW55CnHUYOJuhIOv+3gQWTfQ6KWIGW6fGD ZScwaT+zesPMoEDvj470QzHx2Y50UhjnZMV+jVCKenpaG/byxGI3ZFsigH4T+YSK3Gco kNgusPywt3fCveJ8LSGNCbYMUvd8+59qeke36efXA1F9mXKShmvOc2+fzT1M5Y+pK9AE Qqz7cs/6m3SReJTYmGEGxXMjet+tNql0mJF/+Kp1jLrCde9g4BtFaQDA171aPZgl/haS M12sM/C6+vhHzhFXhD6TVSDOyJbHQveO+hZQ9MfXhe1lNIqVEc6qor2AZ6BkLT5+4psX DipQ== X-Gm-Message-State: AOAM533m8vL1x+HuKZw6/H/fROBPYVzOQOLrejG05S8f+wvjckz8IqJt +zcs3p8m+ySpKJM+xw7ced8= X-Google-Smtp-Source: ABdhPJzx6J2dwWA2DSaJGKE/ibstVv3AI5P31Opftw6WFWiKgmcTvV4Nx/SjyquY73oqj4NF8YLTWQ== X-Received: by 2002:a17:90a:e28c:: with SMTP id d12mr21246421pjz.122.1593481901256; Mon, 29 Jun 2020 18:51:41 -0700 (PDT) Received: from piano ([2601:1c2:4f00:c640:fc6:7318:8185:4d2d]) by smtp.gmail.com with ESMTPSA id x1sm650990pju.3.2020.06.29.18.51.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 18:51:40 -0700 (PDT) Date: Mon, 29 Jun 2020 18:51:38 -0700 From: Bobby Eshleman To: Jan Beulich Subject: Re: [RFC XEN PATCH 22/23] riscv: Add sysctl.c Message-ID: <20200630015138.GB8470@piano> References: <7ebc34d888493f27302ed0a53e09216233cc9e7e.1579615303.git.bobbyeshleman@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Bobby Eshleman , Dan Robertson , Alistair Francis , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 01:43:40PM +0200, Jan Beulich wrote: > On 22.01.2020 02:59, Bobby Eshleman wrote: > > --- /dev/null > > +++ b/xen/arch/riscv/sysctl.c > > @@ -0,0 +1,31 @@ > > +/****************************************************************************** > > + * Arch-specific sysctl.c > > + * > > + * System management operations. For use by node control stack. > > + * > > + * Copyright (c) 2012, Citrix Systems > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +void arch_do_physinfo(struct xen_sysctl_physinfo *pi) { } > > + > > +long arch_do_sysctl(struct xen_sysctl *sysctl, > > + XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) > > +{ > > + return -ENOSYS; > > At the example of this (there may be more in this series) - -EOPNOTSUPP > please. Only top level hypercall handlers ought to produce -ENOSYS, for > major hypercall numbers with no handler. > Got it, will do. Thanks! From xen-devel-bounces@lists.xenproject.org Tue Jun 30 01:55:40 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 01:55:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5Um-0003dg-Tb; Tue, 30 Jun 2020 01:55:36 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5Um-0003db-0B for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 01:55:36 +0000 X-Inumbo-ID: c9c89f6c-ba74-11ea-bb8b-bc764e2007e4 Received: from mail-pg1-x544.google.com (unknown [2607:f8b0:4864:20::544]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c9c89f6c-ba74-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 01:55:35 +0000 (UTC) Received: by mail-pg1-x544.google.com with SMTP id z5so9177079pgb.6 for ; Mon, 29 Jun 2020 18:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=HS5e6zKVS7g0I3TN+ey+83qSL6DZHPtxKHOSz1FdQDs=; b=bKMCFJdzFr2fziAS/VIVfQXtcuD/fDv6UAZQo09MfEsJCiz2XGUWXRfFqbLc14eoCa 6+I6FFSfmaA51Iz6uH7wvw6A3uPJhBID1+t9IFgX3SAhI4DwySZ56CBxYUEpwcTKcjg7 TbNxCP5qvmIPUCg0eIRi4MWQ6E72ecKZdnosN8bTO7x+zjVDbzBsc9Ft8tymBz4gArfM XFC+ciq18jxocs73kwb0dktvZAgG2737LM15wQ0sCDH+d9JfogCgU54baDYzTWShqB/J xe/SSxw952HyhvB49xZdbSreoxjip4iWqYITKUapZ3FPQZLwaI5h7FeBWQ1xN9uUaYUC ZuJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=HS5e6zKVS7g0I3TN+ey+83qSL6DZHPtxKHOSz1FdQDs=; b=aWoFBbyjHJL2UUbGVsdOg67FDyC6LdI1Y6bof14OJaApahEZ9rbkFXGASdXiGsa4UW 2uy1INw4X3S8lYDI5rMhIZH8UarjQ3yHf6akBc3NJl4wu1Rfe84DBDcwRiDwLZHVcd76 n8oIKvUyDx3II5ePyxpXfANnFEkroMpG62NE8oSGDY47evaacM6WelKMzYbMh1juDb1S awcEM3HuZxgrVRK+V47Fqs05fhyzWBjr6xeJKvFMj5MJ+oaXkAlyTXRux6rWnO7ri9WE khOLX5QciJkPZKhfr5AleMlWJSDT1jehQQp923VKvAzpdyggSqJYdHbdW3XN286iWvxb GVQQ== X-Gm-Message-State: AOAM533QnnpP2sNPu0XMjKTI5mmIyIJ/Clnq7rHeHURtNULWU2cuHcif 9fPMDFsSU4e5pVupKp2Wtc8= X-Google-Smtp-Source: ABdhPJxCjuyup9Tg7rRoCza+5VC4sO3bwCj0cTuYeATLryWCQ6Qz2BNm/uPx4FRzAAEdbx8L62x+1Q== X-Received: by 2002:a63:e057:: with SMTP id n23mr12657995pgj.368.1593482134739; Mon, 29 Jun 2020 18:55:34 -0700 (PDT) Received: from piano ([2601:1c2:4f00:c640:fc6:7318:8185:4d2d]) by smtp.gmail.com with ESMTPSA id h17sm859224pgv.41.2020.06.29.18.55.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 18:55:34 -0700 (PDT) Date: Mon, 29 Jun 2020 18:55:32 -0700 From: Bobby Eshleman To: Jan Beulich Subject: Re: [RFC XEN PATCH 19/23] riscv: Add the lib directory Message-ID: <20200630015532.GC8470@piano> References: <65b894a039c4097a25a8d0b19e56646574159b14.1579615303.git.bobbyeshleman@gmail.com> <8e76ed4b-6d96-40ad-54bc-4243e6d12915@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8e76ed4b-6d96-40ad-54bc-4243e6d12915@suse.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Bobby Eshleman , Dan Robertson , Alistair Francis , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 22, 2020 at 01:38:20PM +0200, Jan Beulich wrote: > On 22.01.2020 02:58, Bobby Eshleman wrote: > > From: Alistair Francis > > > > Add the lib directory with find_next_bit support. > > > > This was taken from Linux > > As was Arm64's - the two definitely would want folding. > Indeed. I'm finding a good more overlap with arch/arm as I move forward, so expect to see a good degree of folding between the two in v2. From xen-devel-bounces@lists.xenproject.org Tue Jun 30 02:27:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 02:27:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5zX-0006SP-BY; Tue, 30 Jun 2020 02:27:23 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5zV-0006SK-F2 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 02:27:21 +0000 X-Inumbo-ID: 38050ab6-ba79-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 38050ab6-ba79-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 02:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8R9azClGWpePbulnEKQ0ki1UM3zQX3PSKWkdpEF8HLk=; b=66lBx+IA/TN0ttuLi5MpMO3Cq 6bL7K1SF9OJHQWjLl7LQfjdScqygKD0Kv1RcgPiSCyrq8ugW264/5GCAx4nPxNaPMC0+v/vDVxrKN 5+eiQmXA4jXW0yRO08ysvkxOtgDOCtDfFWnYT70LT6XNYYeMmHp7W+JCsPVz+/UGNTBW4=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq5zR-0004OW-B6; Tue, 30 Jun 2020 02:27:17 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jq5zR-0000oA-2r; Tue, 30 Jun 2020 02:27:17 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jq5zR-0002q9-2A; Tue, 30 Jun 2020 02:27:17 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151452: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-i386-xl-pvshim:xen-boot:fail:heisenbug linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Tue, 30 Jun 2020 02:27:17 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151452 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151452/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which are failing intermittently (not blocking): test-amd64-i386-xl-pvshim 7 xen-boot fail pass in 151441 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail in 151441 never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 11 days Failing since 151236 2020-06-19 19:10:35 Z 10 days 12 attempts Testing same since 151441 2020-06-28 23:39:48 Z 1 days 2 attempts ------------------------------------------------------------ 468 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 22365 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 30 05:17:30 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 05:17:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq8dt-0003bD-8B; Tue, 30 Jun 2020 05:17:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq8ds-0003b4-K9 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 05:17:12 +0000 X-Inumbo-ID: f351263a-ba90-11ea-85ba-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id f351263a-ba90-11ea-85ba-12813bfff9fa; Tue, 30 Jun 2020 05:17:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZHx0hzFw6rFvv6jX4eiZnGzLHg6kjo2jT7aLyk1D1sg=; b=ErOALIzDIgVSj8LVvJj11XtZ5 J2xIz1FGnSdIIHepK0vBuqrYbXzqBRUL819KAlpCvOCTc799MP0RIP4tYxCCB5u9yetv9x5TWnVz4 GH5jG8xM3ptWsXLtSq5U8CFGeqSdUW96k/5pvPSUidi3ZmjqQjX6CJdMrShdSK2/qu4Rc=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq8dq-0007zs-EG; Tue, 30 Jun 2020 05:17:10 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jq8dp-0007hX-PO; Tue, 30 Jun 2020 05:17:09 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jq8dp-00076W-Og; Tue, 30 Jun 2020 05:17:09 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151459: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=e7651153a8801dad6805d450ea8bef9b46c1adf5 X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Tue, 30 Jun 2020 05:17:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151459 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151459/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: qemuu e7651153a8801dad6805d450ea8bef9b46c1adf5 baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 17 days Failing since 151101 2020-06-14 08:32:51 Z 15 days 16 attempts Testing same since 151435 2020-06-28 15:39:59 Z 1 days 3 attempts ------------------------------------------------------------ People who touched revisions under test: Ahmed Karaman Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Andrew Jones Ani Sinha Anthony PERARD Ard Biesheuvel Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Cleber Rosa Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé Daniele Buono David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Finn Thain Geoffrey McRae Gerd Hoffmann Greg Kurz Guenter Roeck Gustavo Romero Helge Deller Huacai Chen Huacai Chen Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jay Zhou Jean-Christophe Dubois Jiaxun Yang Jingqi Liu John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Liao Pingfang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marcelo Tosatti Marek Marczykowski-Górecki Mark Cave-Ayland Markus Armbruster Masahiro Yamada Max Filippov Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Raphael Norwitz Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Shameer Kolothum Stefan Berger Stefan Berger Stefan Hajnoczi Tao Xu Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 14356 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 30 06:02:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 06:02:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq9LY-0007az-SE; Tue, 30 Jun 2020 06:02:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq9LX-0007ac-91 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 06:02:19 +0000 X-Inumbo-ID: 3df482a8-ba97-11ea-bb8b-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3df482a8-ba97-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 06:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PmlWXP1COLyczFfArJg3FSAnbEmzpnz680fkDjIgmIQ=; b=HorUBTpAjOYJQk/WZNidZYxgp NUXZ4NsYYzQvWMTERU8J46iMcgZchZD3EwnXioidQe2dOM9pdusZeXOoMc+T3obgoGnqZQAtNamPO HdL1Yn0nLLviadCkp49x0mVHhfmaa8nMne+jithPxzWXhyNKPfkMuAvCybXIK+lYfp7yU=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq9LQ-0000Ry-JA; Tue, 30 Jun 2020 06:02:12 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jq9LP-0001Mh-VP; Tue, 30 Jun 2020 06:02:12 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jq9LP-0002eS-Uk; Tue, 30 Jun 2020 06:02:11 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [ovmf test] 151465: all pass - PUSHED X-Osstest-Versions-This: ovmf=00217f1919270007d7a911f89b32e39b9dcaa907 X-Osstest-Versions-That: ovmf=0f01cec52f4794777feb067e4fa0bfcedfdc124e From: osstest service owner Date: Tue, 30 Jun 2020 06:02:11 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151465 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/151465/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 00217f1919270007d7a911f89b32e39b9dcaa907 baseline version: ovmf 0f01cec52f4794777feb067e4fa0bfcedfdc124e Last test of basis 151451 2020-06-29 10:12:21 Z 0 days Testing same since 151465 2020-06-30 01:43:31 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Tomas Pilar jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 0f01cec52f..00217f1919 00217f1919270007d7a911f89b32e39b9dcaa907 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Tue Jun 30 06:13:25 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 06:13:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq9W9-0008UL-Sl; Tue, 30 Jun 2020 06:13:17 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq9W8-0008UG-RS for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 06:13:17 +0000 X-Inumbo-ID: c82a6752-ba98-11ea-b7bb-bc764e2007e4 Received: from EUR04-HE1-obe.outbound.protection.outlook.com (unknown [40.107.7.71]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c82a6752-ba98-11ea-b7bb-bc764e2007e4; Tue, 30 Jun 2020 06:13:15 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NI+5iJI7bVggoSGXeuI2UylzrQGYOwzhAY0t+7Xj3gBd0+Oj8kwFdUC63wwdXWaMz7lctjkpG6kb3ugY6rvIlW0BQyhugTXAnBpElY8o0fepUjo8kCm/HFWDh86TZ/D2MnB3vLERUM972hKTDXrTgvwH20LbgYZySoXf97ZAv5fZ3b5jcTsF705fZctBDXYVUmBXP342m3z56YKU1qEweG3fe6BLG30+Ekhm1ZxKS+8vfSMaje4zLKc4Dc0N5whmJYzFosEz+oYkuWg2HlAEzp2qU+9tu86wuWg0mbWRVPRNKOGwAoWFt/+SrI1UD4EVrrboSJfiBQ7sV2jfwfSFPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=61vwN2V36GBMz5mPLFU4NiZAqYGrODMeIOVzsgiE85w=; b=lMJHq0EuRi6qNpo6qCFBLXOJc2/TkGt5LtWVMHP6r7k3EpcKfWGrs+MkqffL98fBvlEQMkdgtfFO/CgppoVMroG17Z7jiW5DMStlHN7SGPMzQ/zfs8y9E7yxyPwF50AOZ1niY3RI0knvWanxDy3mIpg98Ysab3Jx9qE9i0LrHoOHCDMZpYqwvVAcMHsT86HZcVrdghXIib60HJfLN2O41Ny1tVi333xremXLSWwGYDLtCWzcMxTL7V2uNJDiXYej9kXZE8BoQIe0n9rgK/5rfc1y5ojHnW2LyLZsZG38Rjsezg86isl3t5S8/ED3G25dLQVe/EKvEB4FY1E9YxbVow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=61vwN2V36GBMz5mPLFU4NiZAqYGrODMeIOVzsgiE85w=; b=Ok/h4mF2NNC1LSclaZqiM3uUPBr92r4wYKwizp7z1Ic9yUBJaZtt4MwxPHWUsHQqp3PRTZ2EDe/2nuUhhJ6WHirvid2mFjsFbpu5UXq35VzH6rMJZqlqPxkIX21RzcwFRGsKPkOqjwaNjvMYH1f0F7yDddkrtZVhW7Ksu6xvRW4Edxv+gmHAhEG0p4t9jXG5qehPRUni3HyjcLNTqNR6BqqBKgpI3BrBLA6j+5zEggt+8vzKUPwon04Qvie1XtZFzyPRgaSWc28VJXCoI8CZ9BQXgZDPja6d27sPoKA+lUEP9P24/Y9TAK0CV+Qref9meZDTphceOfBuNitHz7cJXg== Received: from DB7PR03MB3993.eurprd03.prod.outlook.com (2603:10a6:5:38::26) by DBBPR03MB5414.eurprd03.prod.outlook.com (2603:10a6:10:d8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Tue, 30 Jun 2020 06:13:13 +0000 Received: from DB7PR03MB3993.eurprd03.prod.outlook.com ([fe80::e500:29a2:9c1a:bdfe]) by DB7PR03MB3993.eurprd03.prod.outlook.com ([fe80::e500:29a2:9c1a:bdfe%7]) with mapi id 15.20.3131.027; Tue, 30 Jun 2020 06:13:12 +0000 From: Oleksandr Andrushchenko To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" , "ian.jackson@eu.citrix.com" , "wei.liu2@citrix.com" , "konrad.wilk@oracle.com" Subject: Re: [PATCH 1/2] xen/displif: Protocol version 2 Thread-Topic: [PATCH 1/2] xen/displif: Protocol version 2 Thread-Index: AQHWLoWtcyE1H7HtP020nOg+0Ywa4ajvaVUAgAGEr4A= Date: Tue, 30 Jun 2020 06:13:12 +0000 Message-ID: References: <20200520090425.28558-1-andr2000@gmail.com> <20200520090425.28558-2-andr2000@gmail.com> <84d975e3-0cea-becb-f505-856368a63fb7@suse.com> In-Reply-To: <84d975e3-0cea-becb-f505-856368a63fb7@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 57d80ae7-5901-42e3-50e3-08d81cbcab76 x-ms-traffictypediagnostic: DBBPR03MB5414: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0450A714CB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ow76W9sF7wbpSUjRpdEaMx43LZ3i4ZFZQP/Xtq3Jrr2mR59NvAeOjKyQkckMltcYlxV66pcxdufFJ3JNcL3vKPz65v0UGn673MCdGZLuRjvPotVXyCDDu3FdqBHZvXPwbHbR8WL0b9+nEicqHHacvD+tHlcMe9OqF17X5SzWcvRg1Xz+x/ChvsmVosDPONm4OUZx4NBCWgO1ZDvWMRHQtgkCE1VfKRjqNorWIUC0h+8NeNf0RBh0SgYbcawfAt1ep0+5iSMVZY7oN8hWt23xPthb/iYwL3mxqfjeamrwxwQdoEi+X9gxO5BbDQL6TmswbU1xCtSsN3S/KmGl9R9yjw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR03MB3993.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(39860400002)(136003)(366004)(376002)(31686004)(5660300002)(66476007)(66556008)(6512007)(8936002)(53546011)(2616005)(66446008)(66946007)(64756008)(6506007)(76116006)(86362001)(91956017)(478600001)(6486002)(31696002)(83380400001)(2906002)(36756003)(316002)(26005)(8676002)(110136005)(71200400001)(186003)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JsgkQC0z861VS9OQSq/P017xls4QyqQPdCQ4ymB2X59tj/0tjHBrLdLRhcdlE2mt0dYbRLvXeFE8oFpyhkwwd0ZTwjZqG1KeKpNLmymU3JEPxZpQvlhZ5kADpFSnLlB5FBVrzl3ZOTtB0sntMO35qqhXR926aLGX7Yaohgm9fvmbSXrkEC+mSYcBcqNU87PfwEj775mbXDyKAihvzdAUQBjczyhy3D7Hpicq78PTntLsNCEL1o0/GjN2n0Od6l+T3HZQVeNKp0wIQhpFn8wXUljQ7xhoEnBpJfsKWlhiU+ROEocxBoejRouoQmELN1uY3tckht47G5w9mHlMLf5dtv4XgWMfc/rVGX9s+e0CGHpZws5a6lXOpGqrT83S8hq7ROtxBFYf2/b8qlKd8XoWxXSS5rfsEVKoweyQvRYphxgjUU6Qt3wukzvN09nshC48YjKsBd0CxkL4rn0/fYmkSkE6yvg093P0ckzAIKJOUsE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR03MB3993.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 57d80ae7-5901-42e3-50e3-08d81cbcab76 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 06:13:12.7333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WAbxOPvO/MnL7pSMoQclDjaKdbZFVhcLP6tktqhVn5j11gQwHQ5kSmmXHWlqTSwkFp/1DipJgRhq9FHhSw50Nqe2m9mcNGt3VH2sUQaM/IShSATwYRanlxy7yx5yZhh0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5414 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gNi8yOS8yMCAxMDowMiBBTSwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4gT24gMjAuMDUuMjAg MTE6MDQsIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPj4gRnJvbTogT2xla3NhbmRy IEFuZHJ1c2hjaGVua28gPG9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPg0KPj4NCj4+ IDEuIENoYW5nZSBwcm90b2NvbCB2ZXJzaW9uIGZyb20gc3RyaW5nIHRvIGludGVnZXINCj4+DQo+ PiBWZXJzaW9uIHN0cmluZywgd2hpY2ggaXMgaW4gZmFjdCBhbiBpbnRlZ2VyLCBpcyBoYXJkIHRv IGhhbmRsZSBpbiB0aGUNCj4+IGNvZGUgdGhhdCBzdXBwb3J0cyBkaWZmZXJlbnQgcHJvdG9jb2wg dmVyc2lvbnMuIFRvIHNpbXBsaWZ5IHRoYXQNCj4+IG1ha2UgdGhlIHZlcnNpb24gYW4gaW50ZWdl ci4NCj4+DQo+PiAyLiBQYXNzIGJ1ZmZlciBvZmZzZXQgd2l0aCBYRU5ESVNQTF9PUF9EQlVGX0NS RUFURQ0KPj4NCj4+IFRoZXJlIGFyZSBjYXNlcyB3aGVuIGRpc3BsYXkgZGF0YSBidWZmZXIgaXMg Y3JlYXRlZCB3aXRoIG5vbi16ZXJvDQo+PiBvZmZzZXQgdG8gdGhlIGRhdGEgc3RhcnQuIEhhbmRs ZSBzdWNoIGNhc2VzIGFuZCBwcm92aWRlIHRoYXQgb2Zmc2V0DQo+PiB3aGlsZSBjcmVhdGluZyBh IGRpc3BsYXkgYnVmZmVyLg0KPj4NCj4+IDMuIEFkZCBYRU5ESVNQTF9PUF9HRVRfRURJRCBjb21t YW5kDQo+Pg0KPj4gQWRkIGFuIG9wdGlvbmFsIHJlcXVlc3QgZm9yIHJlYWRpbmcgRXh0ZW5kZWQg RGlzcGxheSBJZGVudGlmaWNhdGlvbg0KPj4gRGF0YSAoRURJRCkgc3RydWN0dXJlIHdoaWNoIGFs bG93cyBiZXR0ZXIgY29uZmlndXJhdGlvbiBvZiB0aGUNCj4+IGRpc3BsYXkgY29ubmVjdG9ycyBv dmVyIHRoZSBjb25maWd1cmF0aW9uIHNldCBpbiBYZW5TdG9yZS4NCj4+IFdpdGggdGhpcyBjaGFu Z2UgY29ubmVjdG9ycyBtYXkgaGF2ZSBtdWx0aXBsZSByZXNvbHV0aW9ucyBkZWZpbmVkDQo+PiB3 aXRoIHJlc3BlY3QgdG8gZGV0YWlsZWQgdGltaW5nIGRlZmluaXRpb25zIGFuZCBhZGRpdGlvbmFs IHByb3BlcnRpZXMNCj4+IG5vcm1hbGx5IHByb3ZpZGVkIGJ5IGRpc3BsYXlzLg0KPj4NCj4+IElm IHRoaXMgcmVxdWVzdCBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBiYWNrZW5kIHRoZW4gdmlzaWJs ZSBhcmVhDQo+PiBpcyBkZWZpbmVkIGJ5IHRoZSByZWxldmFudCBYZW5TdG9yZSdzICJyZXNvbHV0 aW9uIiBwcm9wZXJ0eS4NCj4+DQo+PiBJZiBiYWNrZW5kIHByb3ZpZGVzIGV4dGVuZGVkIGRpc3Bs YXkgaWRlbnRpZmljYXRpb24gZGF0YSAoRURJRCkgd2l0aA0KPj4gWEVORElTUExfT1BfR0VUX0VE SUQgcmVxdWVzdCB0aGVuIEVESUQgdmFsdWVzIG11c3QgdGFrZSBwcmVjZWRlbmNlDQo+PiBvdmVy IHRoZSByZXNvbHV0aW9ucyBkZWZpbmVkIGluIFhlblN0b3JlLg0KPj4NCj4+IDQuIEJ1bXAgcHJv dG9jb2wgdmVyc2lvbiB0byAyLg0KPj4NCj4+IFNpZ25lZC1vZmYtYnk6IE9sZWtzYW5kciBBbmRy dXNoY2hlbmtvIDxvbGVrc2FuZHJfYW5kcnVzaGNoZW5rb0BlcGFtLmNvbT4NCj4+IC0tLQ0KPj4g wqAgeGVuL2luY2x1ZGUvcHVibGljL2lvL2Rpc3BsaWYuaCB8IDgzICsrKysrKysrKysrKysrKysr KysrKysrKysrKysrKystLQ0KPj4gwqAgMSBmaWxlIGNoYW5nZWQsIDgwIGluc2VydGlvbnMoKyks IDMgZGVsZXRpb25zKC0pDQo+Pg0KPj4gZGlmZiAtLWdpdCBhL3hlbi9pbmNsdWRlL3B1YmxpYy9p by9kaXNwbGlmLmggYi94ZW4vaW5jbHVkZS9wdWJsaWMvaW8vZGlzcGxpZi5oDQo+PiBpbmRleCBj YzVkZTljYjFmMzUuLjRkNDNiYTUwNzhjOCAxMDA2NDQNCj4+IC0tLSBhL3hlbi9pbmNsdWRlL3B1 YmxpYy9pby9kaXNwbGlmLmgNCj4+ICsrKyBiL3hlbi9pbmNsdWRlL3B1YmxpYy9pby9kaXNwbGlm LmgNCj4+IEBAIC0zOCw3ICszOCw3IEBADQo+PiDCoMKgICrCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFByb3RvY29sIHZlcnNpb24NCj4+ICoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKg0KPj4gwqDCoCAqLw0KPj4gLSNkZWZpbmUgWEVORElTUExfUFJPVE9D T0xfVkVSU0lPTsKgwqDCoMKgICIxIg0KPj4gKyNkZWZpbmUgWEVORElTUExfUFJPVE9DT0xfVkVS U0lPTsKgwqDCoMKgIDINCj4NCj4gVGhpcyBpcyBub3QgdmVyeSBuaWNlIHJlZ2FyZGluZyBjb21w YXRpYmlsaXR5Lg0KPg0KPiBDYW4ndCB5b3UgYWRkIGEgbmV3IG1hY3JvIGZvciB0aGUgaW50ZWdl ciB2YWx1ZT8NCg0KV2UgY2FuIGxlYXZlIGl0IGFzIGlzLCBlLmcuIGRlZmluZSBYRU5ESVNQTF9Q Uk9UT0NPTF9WRVJTSU9OIGFzICIyIiwNCg0Kc28gd2UgZG8gbm90IGJyZWFrIHRoZSBleGlzdGlu ZyB1c2Vycy4gVGhlbiBpZiBldmVyeSB1c2VyIG9mIHRoZSBoZWFkZXIgaGFzDQoNCml0cyBsb2Nh bCBjb3B5ICh0aGlzIGlzIHdoYXQgd2Ugbm93IHVzZSBpbiB0aGUgZGlzcGxheSBiYWNrZW5kKSwg dGhlbiB0aGF0DQpsb2NhbCBjb3B5IGNhbiBiZSBjaGFuZ2VkIGluIGEgd2F5IHN1aXRhYmxlIGZv ciB0aGUgY29uY3JldGUgdXNlciwgZS5nLiAiMiINCg0KcmVkZWZpbmVkIHRvIDIuIFRoaXMgY2Fu bm90IGJlIGRvbmUgKD8pIGZvciB0aGUgTGludXggS2VybmVsIHRob3VnaC4NCg0KT3Igd2UgY2Fu IGhhdmUNCg0KI2RlZmluZSBYRU5ESVNQTF9QUk9UT0NPTF9WRVJTSU9OwqDCoMKgwqAgIjIiDQoN CiNkZWZpbmUgWEVORElTUExfUFJPVE9DT0xfVkVSU0lPTl9JTlTCoCAyDQoNCkp1cmdlbiwgd2hh dCdzIHlvdXIgcHJlZmVyZW5jZSBoZXJlPw0KDQo+DQo+IEFuZCBwbGVhc2UgYWRkIGNvbW1lbnRz IGZ1cnRoZXIgZG93biB3aGljaCBhZGRpdGlvbnMgYXJlIHJlbGF0ZWQgdG8NCj4gdGhlIG5ldyB2 ZXJzaW9uLg0KSSB3aWxsIGFmdGVyIHRoZSByZXZpZXcgaXMgZG9uZSBhbmQgb3RoZXIgY29tbWVu dHMgYXJlIGZpeGVkDQo+DQo+DQo+IEp1ZXJnZW4NCg0KVGhhbmsgeW91LA0KDQpPbGVrc2FuZHIN Cg== From xen-devel-bounces@lists.xenproject.org Tue Jun 30 07:04:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 07:04:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAJI-00049M-CR; Tue, 30 Jun 2020 07:04:04 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAJH-00049H-O1 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 07:04:03 +0000 X-Inumbo-ID: e0897bba-ba9f-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e0897bba-ba9f-11ea-8496-bc764e2007e4; Tue, 30 Jun 2020 07:04:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6C4F3AAC3; Tue, 30 Jun 2020 07:04:01 +0000 (UTC) Subject: Re: [PATCH 1/2] xen/displif: Protocol version 2 To: Oleksandr Andrushchenko , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" , "ian.jackson@eu.citrix.com" , "wei.liu2@citrix.com" , "konrad.wilk@oracle.com" References: <20200520090425.28558-1-andr2000@gmail.com> <20200520090425.28558-2-andr2000@gmail.com> <84d975e3-0cea-becb-f505-856368a63fb7@suse.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Tue, 30 Jun 2020 09:03:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 30.06.20 08:13, Oleksandr Andrushchenko wrote: > On 6/29/20 10:02 AM, Jürgen Groß wrote: >> On 20.05.20 11:04, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> 1. Change protocol version from string to integer >>> >>> Version string, which is in fact an integer, is hard to handle in the >>> code that supports different protocol versions. To simplify that >>> make the version an integer. >>> >>> 2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE >>> >>> There are cases when display data buffer is created with non-zero >>> offset to the data start. Handle such cases and provide that offset >>> while creating a display buffer. >>> >>> 3. Add XENDISPL_OP_GET_EDID command >>> >>> Add an optional request for reading Extended Display Identification >>> Data (EDID) structure which allows better configuration of the >>> display connectors over the configuration set in XenStore. >>> With this change connectors may have multiple resolutions defined >>> with respect to detailed timing definitions and additional properties >>> normally provided by displays. >>> >>> If this request is not supported by the backend then visible area >>> is defined by the relevant XenStore's "resolution" property. >>> >>> If backend provides extended display identification data (EDID) with >>> XENDISPL_OP_GET_EDID request then EDID values must take precedence >>> over the resolutions defined in XenStore. >>> >>> 4. Bump protocol version to 2. >>> >>> Signed-off-by: Oleksandr Andrushchenko >>> --- >>>   xen/include/public/io/displif.h | 83 +++++++++++++++++++++++++++++++-- >>>   1 file changed, 80 insertions(+), 3 deletions(-) >>> >>> diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h >>> index cc5de9cb1f35..4d43ba5078c8 100644 >>> --- a/xen/include/public/io/displif.h >>> +++ b/xen/include/public/io/displif.h >>> @@ -38,7 +38,7 @@ >>>    *                           Protocol version >>> ****************************************************************************** >>>    */ >>> -#define XENDISPL_PROTOCOL_VERSION     "1" >>> +#define XENDISPL_PROTOCOL_VERSION     2 >> >> This is not very nice regarding compatibility. >> >> Can't you add a new macro for the integer value? > > We can leave it as is, e.g. define XENDISPL_PROTOCOL_VERSION as "2", > > so we do not break the existing users. Then if every user of the header has > > its local copy (this is what we now use in the display backend), then that > local copy can be changed in a way suitable for the concrete user, e.g. "2" > > redefined to 2. This cannot be done (?) for the Linux Kernel though. > > Or we can have > > #define XENDISPL_PROTOCOL_VERSION     "2" > > #define XENDISPL_PROTOCOL_VERSION_INT  2 > > Jurgen, what's your preference here? I would prefer the latter, as it avoids the need to modify the header when copying it to a local project. Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 30 07:09:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 07:09:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAOw-0004Jq-0B; Tue, 30 Jun 2020 07:09:54 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAOu-0004Jl-V7 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 07:09:53 +0000 X-Inumbo-ID: b0ebf292-baa0-11ea-8496-bc764e2007e4 Received: from mail-lf1-x144.google.com (unknown [2a00:1450:4864:20::144]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id b0ebf292-baa0-11ea-8496-bc764e2007e4; Tue, 30 Jun 2020 07:09:52 +0000 (UTC) Received: by mail-lf1-x144.google.com with SMTP id c11so10712716lfh.8 for ; Tue, 30 Jun 2020 00:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=o1LXN36/WVqpU6kcPnZDclIZrD+xs4anX1eIXGT39b4=; b=IFGOYbb9INSLIDilYbpOVrfA7hz2JAY9xBmYGaDpaLwpMCQQNrDCbkp31eo50vSW05 4bAPRnVADQuTsJsJPNkoA+C0k0vtdiFPT0YUdI0C7ZpgVxOaAo0bFPRtj91Mlr3Higan CKefCbITS80OGPLa2rAT6zWgV47nVMKkDRORvSfidI845KGga9GC1p4KieKA+qQ2oT0Y cOEmX1v/qGz4O9IdU/GF+wwCjsE38BsroEyN9FAmn1EXKZlzMnkWtDz9RIBEyTiHSsm5 zNk8y/M5WvQ1687Zo1BIzoUWL8E1vwG745Y3wpNAgSkLceF/+RD5p5qgYu+RNS8jtJUx mTiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=o1LXN36/WVqpU6kcPnZDclIZrD+xs4anX1eIXGT39b4=; b=XN5LDhFMnT38jJBqRxKFMub+FbKprmYvkZ+FPL0unqxwYKFYCUU3pJX3duj+DFz9Ci rODkY4ShhTJd1L1QWHAlflLgLv9CSqiNpUzgG9mzXMeD1GFIYzB0hjVekLmMuIryfQFL bg0eJhETJaOLqx9aJhuFe7gLAl23yb/WSFV3VqjeeaXwhpk2cgxBHxP8rGOqCBKyolJz RM/itEvG7v0+YJU4eHyMk+rKPC1lW4B640U/DKL3pjp+GYq8ner6vBbzu1jVOjsovG2x SsMO1DNJzDES1x+BPQ4tuzEnD0K8RRCC+imnYd3W6NlZ/yjtnzbde+C3Hkx3qzCkoe05 anBQ== X-Gm-Message-State: AOAM531Z8zRg995GKNiYFi4wRppIUEQz1ZLQckJJebkv//kn9En9+iSk 8Z39izSx370S2G7TK5LcIz4= X-Google-Smtp-Source: ABdhPJxXZljZRO71aVvKrJMyXwabP2OvOIZJQBfRej1E4gjDp7JPnQhn9EnjTscTFjmhEUgBSxjeOA== X-Received: by 2002:a19:a417:: with SMTP id q23mr10854424lfc.181.1593500990783; Tue, 30 Jun 2020 00:09:50 -0700 (PDT) Received: from [192.168.10.4] ([185.199.97.5]) by smtp.gmail.com with ESMTPSA id 132sm488735lfl.37.2020.06.30.00.09.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 00:09:50 -0700 (PDT) Subject: Re: [PATCH 1/2] xen/displif: Protocol version 2 To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" , "ian.jackson@eu.citrix.com" , wl@xen.org, "konrad.wilk@oracle.com" References: <20200520090425.28558-1-andr2000@gmail.com> <20200520090425.28558-2-andr2000@gmail.com> <84d975e3-0cea-becb-f505-856368a63fb7@suse.com> From: Oleksandr Andrushchenko Message-ID: <80bfd713-9556-42d7-6bf7-dee85fdf8c10@gmail.com> Date: Tue, 30 Jun 2020 10:09:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/30/20 10:03 AM, Jürgen Groß wrote: > On 30.06.20 08:13, Oleksandr Andrushchenko wrote: >> On 6/29/20 10:02 AM, Jürgen Groß wrote: >>> On 20.05.20 11:04, Oleksandr Andrushchenko wrote: >>>> From: Oleksandr Andrushchenko >>>> >>>> 1. Change protocol version from string to integer >>>> >>>> Version string, which is in fact an integer, is hard to handle in the >>>> code that supports different protocol versions. To simplify that >>>> make the version an integer. >>>> >>>> 2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE >>>> >>>> There are cases when display data buffer is created with non-zero >>>> offset to the data start. Handle such cases and provide that offset >>>> while creating a display buffer. >>>> >>>> 3. Add XENDISPL_OP_GET_EDID command >>>> >>>> Add an optional request for reading Extended Display Identification >>>> Data (EDID) structure which allows better configuration of the >>>> display connectors over the configuration set in XenStore. >>>> With this change connectors may have multiple resolutions defined >>>> with respect to detailed timing definitions and additional properties >>>> normally provided by displays. >>>> >>>> If this request is not supported by the backend then visible area >>>> is defined by the relevant XenStore's "resolution" property. >>>> >>>> If backend provides extended display identification data (EDID) with >>>> XENDISPL_OP_GET_EDID request then EDID values must take precedence >>>> over the resolutions defined in XenStore. >>>> >>>> 4. Bump protocol version to 2. >>>> >>>> Signed-off-by: Oleksandr Andrushchenko >>>> --- >>>>    xen/include/public/io/displif.h | 83 +++++++++++++++++++++++++++++++-- >>>>    1 file changed, 80 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h >>>> index cc5de9cb1f35..4d43ba5078c8 100644 >>>> --- a/xen/include/public/io/displif.h >>>> +++ b/xen/include/public/io/displif.h >>>> @@ -38,7 +38,7 @@ >>>>     *                           Protocol version >>>> ****************************************************************************** >>>>     */ >>>> -#define XENDISPL_PROTOCOL_VERSION     "1" >>>> +#define XENDISPL_PROTOCOL_VERSION     2 >>> >>> This is not very nice regarding compatibility. >>> >>> Can't you add a new macro for the integer value? >> >> We can leave it as is, e.g. define XENDISPL_PROTOCOL_VERSION as "2", >> >> so we do not break the existing users. Then if every user of the header has >> >> its local copy (this is what we now use in the display backend), then that >> local copy can be changed in a way suitable for the concrete user, e.g. "2" >> >> redefined to 2. This cannot be done (?) for the Linux Kernel though. >> >> Or we can have >> >> #define XENDISPL_PROTOCOL_VERSION     "2" >> >> #define XENDISPL_PROTOCOL_VERSION_INT  2 >> >> Jurgen, what's your preference here? > > I would prefer the latter, as it avoids the need to modify the header > when copying it to a local project. > Ok, I'll have 2 definitions then Anything else (beside the comments on new functionality) I can add/change before sending v2 of the patch? > > Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 30 07:30:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 07:30:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAii-0006eN-Qm; Tue, 30 Jun 2020 07:30:20 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAih-0006eI-O8 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 07:30:19 +0000 X-Inumbo-ID: 8ab6ddaa-baa3-11ea-85ce-12813bfff9fa Received: from mail.tttech.com (unknown [217.19.35.52]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8ab6ddaa-baa3-11ea-85ce-12813bfff9fa; Tue, 30 Jun 2020 07:30:16 +0000 (UTC) IronPort-SDR: rM+8U2QEUf+c0nXTPJGgmcvVX800eNEt5ydJmBRrXbahfXebUNal0tCo2tSrzT58RCFFky6m+2 anxDNrDLUtcbHS8VxAWEiigRnMSGgNuTCkiu/ph+XtWwnD4WBZ53AZk0DybHUVYpVywIXhrnBQ oVoxFZGfC5wVOE73a39qe4HxFbFCTKRYbNw9wrJXedg4yRmKxS6sMZH/zVKJJv1g1aySHN18gD hzfijrJEVgUQx4s/aiBDaRtocBkt6O8eQlnpeLxy/9mbA4PTdY2DtEhQ2lkKsd+uMRoDg2EBmS HXU= X-IronPort-AV: E=Sophos;i="5.75,296,1589234400"; d="scan'208";a="9465337" Received: from unknown (HELO mail.tttech.com) ([10.108.0.226]) by mail-int.tttech.com with ESMTP; 30 Jun 2020 09:30:15 +0200 Received: from EXVIE02.ds1.internal (10.108.0.226) by EXVIE02.ds1.internal (10.108.0.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 30 Jun 2020 09:30:15 +0200 Received: from EXVIE02.ds1.internal ([fe80::4ccf:d313:b2a8:c054]) by EXVIE02.ds1.internal ([fe80::4ccf:d313:b2a8:c054%6]) with mapi id 15.01.1913.007; Tue, 30 Jun 2020 09:30:15 +0200 From: Jan Ruh To: =?iso-8859-1?Q?Roger_Pau_Monn=E9?= Subject: AW: Kernel requires x86-64 CPU, after modifying arch_shared_info struct Thread-Topic: Kernel requires x86-64 CPU, after modifying arch_shared_info struct Thread-Index: AQHWTehUS5L/6eMJQEyE2773H88H5KjvLyGAgAAjyHb//+y6AIABg+n8 Date: Tue, 30 Jun 2020 07:30:14 +0000 Message-ID: References: <6f88fc3e2795436fa1f30dd026dd8eda@tttech.com> <20200629091823.GF735@Air-de-Roger> , <20200629101728.GH735@Air-de-Roger> In-Reply-To: <20200629101728.GH735@Air-de-Roger> Accept-Language: de-DE, en-GB, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.102.6.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Roger, thanks for your time, your remark that you cannot see how it has to do with= the shared_info got me to step-by-step revert all changes I have done. Tur= ns out a few weeks ago when implementing a sysctl I must have accidentally = deleted the architecture specific syctl in the default case of the common s= ysctl. This leads to Xen quietly defaulting to a x86_32 CPU. Jan. CONFIDENTIALITY: The contents of this e-mail are confidential and intended = only for the above addressee(s). If you are not the intended recipient, or = the person responsible for delivering it to the intended recipient, copying= or delivering it to anyone else or using it in any unauthorized manner is = prohibited and may be unlawful. If you receive this e-mail by mistake, plea= se notify the sender and the systems administrator at straymail@tttech.com = immediately. From xen-devel-bounces@lists.xenproject.org Tue Jun 30 07:30:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 07:30:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAjJ-0006gh-3l; Tue, 30 Jun 2020 07:30:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAjH-0006gU-Ip for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 07:30:55 +0000 X-Inumbo-ID: a1a63e66-baa3-11ea-8496-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a1a63e66-baa3-11ea-8496-bc764e2007e4; Tue, 30 Jun 2020 07:30:54 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D59BBAAC3; Tue, 30 Jun 2020 07:30:53 +0000 (UTC) Subject: Re: [PATCH 1/2] xen/displif: Protocol version 2 To: Oleksandr Andrushchenko , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" , "ian.jackson@eu.citrix.com" , wl@xen.org, "konrad.wilk@oracle.com" References: <20200520090425.28558-1-andr2000@gmail.com> <20200520090425.28558-2-andr2000@gmail.com> <84d975e3-0cea-becb-f505-856368a63fb7@suse.com> <80bfd713-9556-42d7-6bf7-dee85fdf8c10@gmail.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: <9150a2ad-7c08-1f93-674a-963341bf0ece@suse.com> Date: Tue, 30 Jun 2020 09:30:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <80bfd713-9556-42d7-6bf7-dee85fdf8c10@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 30.06.20 09:09, Oleksandr Andrushchenko wrote: > On 6/30/20 10:03 AM, Jürgen Groß wrote: >> On 30.06.20 08:13, Oleksandr Andrushchenko wrote: >>> On 6/29/20 10:02 AM, Jürgen Groß wrote: >>>> On 20.05.20 11:04, Oleksandr Andrushchenko wrote: >>>>> From: Oleksandr Andrushchenko >>>>> >>>>> 1. Change protocol version from string to integer >>>>> >>>>> Version string, which is in fact an integer, is hard to handle in the >>>>> code that supports different protocol versions. To simplify that >>>>> make the version an integer. >>>>> >>>>> 2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE >>>>> >>>>> There are cases when display data buffer is created with non-zero >>>>> offset to the data start. Handle such cases and provide that offset >>>>> while creating a display buffer. >>>>> >>>>> 3. Add XENDISPL_OP_GET_EDID command >>>>> >>>>> Add an optional request for reading Extended Display Identification >>>>> Data (EDID) structure which allows better configuration of the >>>>> display connectors over the configuration set in XenStore. >>>>> With this change connectors may have multiple resolutions defined >>>>> with respect to detailed timing definitions and additional properties >>>>> normally provided by displays. >>>>> >>>>> If this request is not supported by the backend then visible area >>>>> is defined by the relevant XenStore's "resolution" property. >>>>> >>>>> If backend provides extended display identification data (EDID) with >>>>> XENDISPL_OP_GET_EDID request then EDID values must take precedence >>>>> over the resolutions defined in XenStore. >>>>> >>>>> 4. Bump protocol version to 2. >>>>> >>>>> Signed-off-by: Oleksandr Andrushchenko >>>>> >>>>> --- >>>>>    xen/include/public/io/displif.h | 83 >>>>> +++++++++++++++++++++++++++++++-- >>>>>    1 file changed, 80 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/xen/include/public/io/displif.h >>>>> b/xen/include/public/io/displif.h >>>>> index cc5de9cb1f35..4d43ba5078c8 100644 >>>>> --- a/xen/include/public/io/displif.h >>>>> +++ b/xen/include/public/io/displif.h >>>>> @@ -38,7 +38,7 @@ >>>>>     *                           Protocol version >>>>> ****************************************************************************** >>>>> >>>>>     */ >>>>> -#define XENDISPL_PROTOCOL_VERSION     "1" >>>>> +#define XENDISPL_PROTOCOL_VERSION     2 >>>> >>>> This is not very nice regarding compatibility. >>>> >>>> Can't you add a new macro for the integer value? >>> >>> We can leave it as is, e.g. define XENDISPL_PROTOCOL_VERSION as "2", >>> >>> so we do not break the existing users. Then if every user of the >>> header has >>> >>> its local copy (this is what we now use in the display backend), then >>> that >>> local copy can be changed in a way suitable for the concrete user, >>> e.g. "2" >>> >>> redefined to 2. This cannot be done (?) for the Linux Kernel though. >>> >>> Or we can have >>> >>> #define XENDISPL_PROTOCOL_VERSION     "2" >>> >>> #define XENDISPL_PROTOCOL_VERSION_INT  2 >>> >>> Jurgen, what's your preference here? >> >> I would prefer the latter, as it avoids the need to modify the header >> when copying it to a local project. >> > Ok, I'll have 2 definitions then > > Anything else (beside the comments on new functionality) I can add/change > > before sending v2 of the patch? I would have said so. :-) Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 30 07:39:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 07:39:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqArf-0006xJ-19; Tue, 30 Jun 2020 07:39:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqArd-0006xE-UM for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 07:39:34 +0000 X-Inumbo-ID: d4ad1a5e-baa4-11ea-85cf-12813bfff9fa Received: from EUR01-HE1-obe.outbound.protection.outlook.com (unknown [40.107.13.78]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d4ad1a5e-baa4-11ea-85cf-12813bfff9fa; Tue, 30 Jun 2020 07:39:30 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QZVDP+oGMllMHaNhD6Rb8oy0A1jqb83/hn/FX0GiK8m0kl76D8raFpKhxw9F+hthMZIT0avKBEg86pTvdmWMCz8BbmFI+rX5/cxIeqrQIXh/j3cARRy6+Hgtm1CZXLpGvGW2KloDBh15LnRWab16W5+l1EmdDtnTPOLQpQn1y00+ZX/zUWcOmt8xnAqIyfLUwdL/wnFHGUc57mvQxkQei9Bs+wA4WdE1W0zX4LctNY9iwLWtnD30fZz4FLxnCdRrZ2UkUaYL/HjccevQtnADHxuG1ZogxMO8JolloYwVWF85ODGdfth+w/XHrxSna4mpHF8MRuVmVqqORga8xzJuhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GMJAFR1JjL+CbT7kzT03kNDIMEYU4+z+Z9sUa8/Y0tQ=; b=WFRYS6qnEn1rg9fbNBmeeHGoIeYsC/tOpAox1ylxXAAb2UHYlJzi/6I4wbJWvs+WCPuKvI3C+i1Uj+HDWoqGyuGla4DEQmlL9fi+5C9vHXMXPBIpP4Xc/ZQ1ysKc+lX0R/RFVEzB8KBfckV9ls4GZg4Syc64EyfZupwdZ63mHn/LhX1h57O8GGNcA5r2/FH7buz01x3vk5Oebaz1A0H1oJajhHkF729win7myY/8meblNURlLDDG48Nb1NP4LJLXj9gWN6hUTPg8EVpV2Dzne4qYqwYvqwDesLregXcZM/RALKVavUeIt+v16co4Z9aJ8Rh7NtzHOABFZCLUSUZshw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GMJAFR1JjL+CbT7kzT03kNDIMEYU4+z+Z9sUa8/Y0tQ=; b=qrIQuQKews2Kov9qX21GBRTKdIa5cCJHz8gvlD+W3BvrcGgtc0Wt7bIqOwh+lcvYsK4lW3l0SuxMYZcggiXIfo5ACcpTEVarQAA4O6MoSs5spRMhdoYnRSBvZJ2MmM27FXP1l3MA6Ks6+Vdqp2djOSHUVUGMPUE1N0oQRHxDUSELaqLgjCa7IzRiBsIK5m0oXWI0EOQJ9Rz4h6VcBPrM0WmNKo5ecZW5jE8+AcA5PlVkL4VUT6bywAGitI4XZOI1bFqzX+22Jyco88PhqIFmspsABavPjzgrp8RhA2xPpJGVWtQ1hmjLhv08fIShxGM8lTy3NSc/avgEP6hnG/xRqw== Received: from DB7PR03MB3993.eurprd03.prod.outlook.com (2603:10a6:5:38::26) by DB8PR03MB5963.eurprd03.prod.outlook.com (2603:10a6:10:ee::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Tue, 30 Jun 2020 07:39:27 +0000 Received: from DB7PR03MB3993.eurprd03.prod.outlook.com ([fe80::e500:29a2:9c1a:bdfe]) by DB7PR03MB3993.eurprd03.prod.outlook.com ([fe80::e500:29a2:9c1a:bdfe%7]) with mapi id 15.20.3131.027; Tue, 30 Jun 2020 07:39:27 +0000 From: Oleksandr Andrushchenko To: =?utf-8?B?SsO8cmdlbiBHcm/Dnw==?= , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" , "ian.jackson@eu.citrix.com" , "wl@xen.org" , "konrad.wilk@oracle.com" Subject: Re: [PATCH 1/2] xen/displif: Protocol version 2 Thread-Topic: [PATCH 1/2] xen/displif: Protocol version 2 Thread-Index: AQHWLoWtcyE1H7HtP020nOg+0Ywa4ajvaVUAgAGEr4CAAA4xgIAAAaAAgAAF5ICAAAJjgA== Date: Tue, 30 Jun 2020 07:39:27 +0000 Message-ID: <24252f32-ef40-0daf-a585-36cb00f149d0@epam.com> References: <20200520090425.28558-1-andr2000@gmail.com> <20200520090425.28558-2-andr2000@gmail.com> <84d975e3-0cea-becb-f505-856368a63fb7@suse.com> <80bfd713-9556-42d7-6bf7-dee85fdf8c10@gmail.com> <9150a2ad-7c08-1f93-674a-963341bf0ece@suse.com> In-Reply-To: <9150a2ad-7c08-1f93-674a-963341bf0ece@suse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44a96f0c-3b04-43e6-6e7a-08d81cc8b7bb x-ms-traffictypediagnostic: DB8PR03MB5963: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0450A714CB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uxnLF1RDrz7a8HcstAB022on/1RItWDflJkXuH2XajhGGkx7fH4WjvEf+mHg81/q8lNa6Pso2vGEkTry6vXObhXlH5LcFsJM8cuf60wfe2MUm5u7ck5KwUPvOKw1RC9HaVyJUzbPMSadzDBTl2W/lPZGGThDteTBs9BDBu7APKlbKsT6Cb6V6dUT8sLEq5ox8gu/JeaWWZ7deppppkah05p9t7tuLl+leYW2UojuAga/hBx2vhHtbVRn4uOllO8MM/4Ve9xalzqRl8/jxswLzJkr5jEmA7ijezZGDt9krXvN9w7GbgxhoMMFBkG1ZQLo+pmVlnCJHNE0WHRdk8Cfsg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR03MB3993.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(346002)(136003)(39860400002)(376002)(5660300002)(31696002)(2616005)(31686004)(478600001)(53546011)(83380400001)(36756003)(66574015)(316002)(6486002)(64756008)(66446008)(2906002)(66476007)(66946007)(6506007)(8676002)(76116006)(8936002)(66556008)(6512007)(91956017)(71200400001)(186003)(110136005)(86362001)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6ZAANq/hNUEhW6QjlTRY7GIRoREHaVIIwyPLTzGzwXzSJKg77p8r2/rIDvCnfgQ9t/6PvkZlsa8qO+j+KyduIjj1sVE3cYMrprW1y/2v8go07qom2CIGtvSHkSqtnvbeFMrsPB9lk2puP0yhe56K3TqBIkjRS9etbqPyBGTuLEpMN7i5NNWbYyweBiUQqjcIU330lnXISJkeuCKlDwCoPw7dkfmmV48Jyf8xu2RVsi5BHGMsjqHRTgh5fXYQ+cUgoMhH15jvwZ3BwutCxyTp6IhTrTmALwAaKDxlOMQsCJfLpwwxN7KwHKtW/tXX1opn7IxUPrbsS1TsaEHdSvHhodhnmgE1kfX7DZHbmPEz6ygC83q+K8LicVYe2dsRc7y2ybYvKVONPoNzN5PvfZ9dBLFBvz2YHP91EboIqu3bobPweo85UGy89ld2GjHVaY8hNozI+CmKRVChflgJ+FO3wewKxFqKUPkE1VmAGoZbIns= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR03MB3993.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44a96f0c-3b04-43e6-6e7a-08d81cc8b7bb X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 07:39:27.3896 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xNkDTMKpUT5+2gvE7kr55RJHD5+gtnBkOzaoFcWkvPsSFfjVLtCYcC/IfnqIe28cbE9ddKa1eecP5eoEEBzj0z+U7PvkhWgOSl/Mj4xUEB+Wxk3gJpSrAQOKXWp0vxwD X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB5963 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" T24gNi8zMC8yMCAxMDozMCBBTSwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4gT24gMzAuMDYuMjAg MDk6MDksIE9sZWtzYW5kciBBbmRydXNoY2hlbmtvIHdyb3RlOg0KPj4gT24gNi8zMC8yMCAxMDow MyBBTSwgSsO8cmdlbiBHcm/DnyB3cm90ZToNCj4+PiBPbiAzMC4wNi4yMCAwODoxMywgT2xla3Nh bmRyIEFuZHJ1c2hjaGVua28gd3JvdGU6DQo+Pj4+IE9uIDYvMjkvMjAgMTA6MDIgQU0sIErDvHJn ZW4gR3Jvw58gd3JvdGU6DQo+Pj4+PiBPbiAyMC4wNS4yMCAxMTowNCwgT2xla3NhbmRyIEFuZHJ1 c2hjaGVua28gd3JvdGU6DQo+Pj4+Pj4gRnJvbTogT2xla3NhbmRyIEFuZHJ1c2hjaGVua28gPG9s ZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPg0KPj4+Pj4+DQo+Pj4+Pj4gMS4gQ2hhbmdl IHByb3RvY29sIHZlcnNpb24gZnJvbSBzdHJpbmcgdG8gaW50ZWdlcg0KPj4+Pj4+DQo+Pj4+Pj4g VmVyc2lvbiBzdHJpbmcsIHdoaWNoIGlzIGluIGZhY3QgYW4gaW50ZWdlciwgaXMgaGFyZCB0byBo YW5kbGUgaW4gdGhlDQo+Pj4+Pj4gY29kZSB0aGF0IHN1cHBvcnRzIGRpZmZlcmVudCBwcm90b2Nv bCB2ZXJzaW9ucy4gVG8gc2ltcGxpZnkgdGhhdA0KPj4+Pj4+IG1ha2UgdGhlIHZlcnNpb24gYW4g aW50ZWdlci4NCj4+Pj4+Pg0KPj4+Pj4+IDIuIFBhc3MgYnVmZmVyIG9mZnNldCB3aXRoIFhFTkRJ U1BMX09QX0RCVUZfQ1JFQVRFDQo+Pj4+Pj4NCj4+Pj4+PiBUaGVyZSBhcmUgY2FzZXMgd2hlbiBk aXNwbGF5IGRhdGEgYnVmZmVyIGlzIGNyZWF0ZWQgd2l0aCBub24temVybw0KPj4+Pj4+IG9mZnNl dCB0byB0aGUgZGF0YSBzdGFydC4gSGFuZGxlIHN1Y2ggY2FzZXMgYW5kIHByb3ZpZGUgdGhhdCBv ZmZzZXQNCj4+Pj4+PiB3aGlsZSBjcmVhdGluZyBhIGRpc3BsYXkgYnVmZmVyLg0KPj4+Pj4+DQo+ Pj4+Pj4gMy4gQWRkIFhFTkRJU1BMX09QX0dFVF9FRElEIGNvbW1hbmQNCj4+Pj4+Pg0KPj4+Pj4+ IEFkZCBhbiBvcHRpb25hbCByZXF1ZXN0IGZvciByZWFkaW5nIEV4dGVuZGVkIERpc3BsYXkgSWRl bnRpZmljYXRpb24NCj4+Pj4+PiBEYXRhIChFRElEKSBzdHJ1Y3R1cmUgd2hpY2ggYWxsb3dzIGJl dHRlciBjb25maWd1cmF0aW9uIG9mIHRoZQ0KPj4+Pj4+IGRpc3BsYXkgY29ubmVjdG9ycyBvdmVy IHRoZSBjb25maWd1cmF0aW9uIHNldCBpbiBYZW5TdG9yZS4NCj4+Pj4+PiBXaXRoIHRoaXMgY2hh bmdlIGNvbm5lY3RvcnMgbWF5IGhhdmUgbXVsdGlwbGUgcmVzb2x1dGlvbnMgZGVmaW5lZA0KPj4+ Pj4+IHdpdGggcmVzcGVjdCB0byBkZXRhaWxlZCB0aW1pbmcgZGVmaW5pdGlvbnMgYW5kIGFkZGl0 aW9uYWwgcHJvcGVydGllcw0KPj4+Pj4+IG5vcm1hbGx5IHByb3ZpZGVkIGJ5IGRpc3BsYXlzLg0K Pj4+Pj4+DQo+Pj4+Pj4gSWYgdGhpcyByZXF1ZXN0IGlzIG5vdCBzdXBwb3J0ZWQgYnkgdGhlIGJh Y2tlbmQgdGhlbiB2aXNpYmxlIGFyZWENCj4+Pj4+PiBpcyBkZWZpbmVkIGJ5IHRoZSByZWxldmFu dCBYZW5TdG9yZSdzICJyZXNvbHV0aW9uIiBwcm9wZXJ0eS4NCj4+Pj4+Pg0KPj4+Pj4+IElmIGJh Y2tlbmQgcHJvdmlkZXMgZXh0ZW5kZWQgZGlzcGxheSBpZGVudGlmaWNhdGlvbiBkYXRhIChFRElE KSB3aXRoDQo+Pj4+Pj4gWEVORElTUExfT1BfR0VUX0VESUQgcmVxdWVzdCB0aGVuIEVESUQgdmFs dWVzIG11c3QgdGFrZSBwcmVjZWRlbmNlDQo+Pj4+Pj4gb3ZlciB0aGUgcmVzb2x1dGlvbnMgZGVm aW5lZCBpbiBYZW5TdG9yZS4NCj4+Pj4+Pg0KPj4+Pj4+IDQuIEJ1bXAgcHJvdG9jb2wgdmVyc2lv biB0byAyLg0KPj4+Pj4+DQo+Pj4+Pj4gU2lnbmVkLW9mZi1ieTogT2xla3NhbmRyIEFuZHJ1c2hj aGVua28gPG9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPg0KPj4+Pj4+IC0tLQ0KPj4+ Pj4+IMKgwqAgeGVuL2luY2x1ZGUvcHVibGljL2lvL2Rpc3BsaWYuaCB8IDgzICsrKysrKysrKysr KysrKysrKysrKysrKysrKysrKystLQ0KPj4+Pj4+IMKgwqAgMSBmaWxlIGNoYW5nZWQsIDgwIGlu c2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pDQo+Pj4+Pj4NCj4+Pj4+PiBkaWZmIC0tZ2l0IGEv eGVuL2luY2x1ZGUvcHVibGljL2lvL2Rpc3BsaWYuaCBiL3hlbi9pbmNsdWRlL3B1YmxpYy9pby9k aXNwbGlmLmgNCj4+Pj4+PiBpbmRleCBjYzVkZTljYjFmMzUuLjRkNDNiYTUwNzhjOCAxMDA2NDQN Cj4+Pj4+PiAtLS0gYS94ZW4vaW5jbHVkZS9wdWJsaWMvaW8vZGlzcGxpZi5oDQo+Pj4+Pj4gKysr IGIveGVuL2luY2x1ZGUvcHVibGljL2lvL2Rpc3BsaWYuaA0KPj4+Pj4+IEBAIC0zOCw3ICszOCw3 IEBADQo+Pj4+Pj4gwqDCoMKgICrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIFByb3RvY29sIHZlcnNpb24NCj4+Pj4+PiAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioNCj4+Pj4+PiDCoMKgwqAgKi8NCj4+Pj4+PiAtI2RlZmluZSBYRU5ESVNQTF9QUk9UT0NP TF9WRVJTSU9OwqDCoMKgwqAgIjEiDQo+Pj4+Pj4gKyNkZWZpbmUgWEVORElTUExfUFJPVE9DT0xf VkVSU0lPTsKgwqDCoMKgIDINCj4+Pj4+DQo+Pj4+PiBUaGlzIGlzIG5vdCB2ZXJ5IG5pY2UgcmVn YXJkaW5nIGNvbXBhdGliaWxpdHkuDQo+Pj4+Pg0KPj4+Pj4gQ2FuJ3QgeW91IGFkZCBhIG5ldyBt YWNybyBmb3IgdGhlIGludGVnZXIgdmFsdWU/DQo+Pj4+DQo+Pj4+IFdlIGNhbiBsZWF2ZSBpdCBh cyBpcywgZS5nLiBkZWZpbmUgWEVORElTUExfUFJPVE9DT0xfVkVSU0lPTiBhcyAiMiIsDQo+Pj4+ DQo+Pj4+IHNvIHdlIGRvIG5vdCBicmVhayB0aGUgZXhpc3RpbmcgdXNlcnMuIFRoZW4gaWYgZXZl cnkgdXNlciBvZiB0aGUgaGVhZGVyIGhhcw0KPj4+Pg0KPj4+PiBpdHMgbG9jYWwgY29weSAodGhp cyBpcyB3aGF0IHdlIG5vdyB1c2UgaW4gdGhlIGRpc3BsYXkgYmFja2VuZCksIHRoZW4gdGhhdA0K Pj4+PiBsb2NhbCBjb3B5IGNhbiBiZSBjaGFuZ2VkIGluIGEgd2F5IHN1aXRhYmxlIGZvciB0aGUg Y29uY3JldGUgdXNlciwgZS5nLiAiMiINCj4+Pj4NCj4+Pj4gcmVkZWZpbmVkIHRvIDIuIFRoaXMg Y2Fubm90IGJlIGRvbmUgKD8pIGZvciB0aGUgTGludXggS2VybmVsIHRob3VnaC4NCj4+Pj4NCj4+ Pj4gT3Igd2UgY2FuIGhhdmUNCj4+Pj4NCj4+Pj4gI2RlZmluZSBYRU5ESVNQTF9QUk9UT0NPTF9W RVJTSU9OwqDCoMKgwqAgIjIiDQo+Pj4+DQo+Pj4+ICNkZWZpbmUgWEVORElTUExfUFJPVE9DT0xf VkVSU0lPTl9JTlTCoCAyDQo+Pj4+DQo+Pj4+IEp1cmdlbiwgd2hhdCdzIHlvdXIgcHJlZmVyZW5j ZSBoZXJlPw0KPj4+DQo+Pj4gSSB3b3VsZCBwcmVmZXIgdGhlIGxhdHRlciwgYXMgaXQgYXZvaWRz IHRoZSBuZWVkIHRvIG1vZGlmeSB0aGUgaGVhZGVyDQo+Pj4gd2hlbiBjb3B5aW5nIGl0IHRvIGEg bG9jYWwgcHJvamVjdC4NCj4+Pg0KPj4gT2ssIEknbGwgaGF2ZSAyIGRlZmluaXRpb25zIHRoZW4N Cj4+DQo+PiBBbnl0aGluZyBlbHNlIChiZXNpZGUgdGhlIGNvbW1lbnRzIG9uIG5ldyBmdW5jdGlv bmFsaXR5KSBJIGNhbiBhZGQvY2hhbmdlDQo+Pg0KPj4gYmVmb3JlIHNlbmRpbmcgdjIgb2YgdGhl IHBhdGNoPw0KPg0KPiBJIHdvdWxkIGhhdmUgc2FpZCBzby4gOi0pDQoNClRoYW5rIHlvdSwNCg0K dGhlIHNlcmllcyBhbHNvIGhhcyBhIHBhdGNoIGZvciBsaWJnbnR0YWIuIERvIHlvdSB3YW50IG1l IHRvIHNlbmQgdGhlIHByb3RvY29sIHBhdGNoDQoNCnNlcGFyYXRlbHkgb3Igc2hvdWxkIHdlIHdh aXQgZm9yIElhbiBhbmQgV2VpIHRvIHJldmlldz8gVGhlc2UgY2hhbmdlcyBhcmUgcmVsYXRlZCwN Cg0KdGh1cyBJIHNlbnQgdGhlbiB0b2doZXRlcg0KDQo+DQo+DQo+IEp1ZXJnZW4NCg0KVGhhbmsg eW91LA0KDQpPbGVrc2FuZHINCg== From xen-devel-bounces@lists.xenproject.org Tue Jun 30 07:47:17 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 07:47:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAz0-0007nY-8y; Tue, 30 Jun 2020 07:47:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAyy-0007nA-4u for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 07:47:08 +0000 X-Inumbo-ID: df882274-baa5-11ea-8496-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id df882274-baa5-11ea-8496-bc764e2007e4; Tue, 30 Jun 2020 07:46:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Reply-To:Message-Id:Date:Subject:To:From:Sender:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lJNTlZjxIYh1xD/yBA//CRnxEGYheSdh39GysEDIMuk=; b=2wF5GDm/oNQ6PsGEJgc3VHl4d8 tqpk+UPTCbBwHBMEhUZ+pbQ3tkBS/3V4V1DkqsH/rjdFI90Ift3QBvaEnIhiN2iC8ceQ73L7s5aX4 AhioMzlKWqy1WfCLRWmv36qLPXy2IoSW0z9449OEldqwN+1HsQ5ZHWX4EzbrmnIZPV4Q=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqAyn-0002O4-0R; Tue, 30 Jun 2020 07:46:57 +0000 Received: from 54-240-197-238.amazon.com ([54.240.197.238] helo=CBG-R90WXYV0.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jqAym-0007Sl-Lz; Tue, 30 Jun 2020 07:46:56 +0000 From: Paul Durrant To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Subject: Xen 4.14 RC4 Date: Tue, 30 Jun 2020 08:46:55 +0100 Message-Id: <20200630074655.252-1-paul@xen.org> X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: xen-devel@lists.xenproject.org, paul@xen.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi all, Xen 4.14 RC4 is tagged. You can check that out from xen.git: git://xenbits.xen.org/xen.git 4.14.0-rc4 For your convenience there is also a tarball at: https://downloads.xenproject.org/release/xen/4.14.0-rc4/xen-4.14.0-rc4.tar.gz And the signature is at: https://downloads.xenproject.org/release/xen/4.14.0-rc4/xen-4.14.0-rc4.tar.gz.sig Please send bug reports and test reports to xen-devel@lists.xenproject.org. When sending bug reports, please CC relevant maintainers and me (paul@xen.org). As a reminder, there will be a Xen Test Day. Please see the test day schedule at https://wiki.xenproject.org/wiki/Xen_Project_Test_Days and test instructions at https://wiki.xenproject.org/wiki/Xen_4.14_RC_test_instructions. Paul Durrant From xen-devel-bounces@lists.xenproject.org Tue Jun 30 07:57:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 07:57:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqB8x-0000QH-62; Tue, 30 Jun 2020 07:57:27 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqB8w-0000QC-EU for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 07:57:26 +0000 X-Inumbo-ID: 55448dc6-baa7-11ea-85d4-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 55448dc6-baa7-11ea-85d4-12813bfff9fa; Tue, 30 Jun 2020 07:57:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B7D77AAC3; Tue, 30 Jun 2020 07:57:23 +0000 (UTC) Subject: Re: [PATCH 1/2] xen/displif: Protocol version 2 To: Oleksandr Andrushchenko , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" , "ian.jackson@eu.citrix.com" , "wl@xen.org" , "konrad.wilk@oracle.com" References: <20200520090425.28558-1-andr2000@gmail.com> <20200520090425.28558-2-andr2000@gmail.com> <84d975e3-0cea-becb-f505-856368a63fb7@suse.com> <80bfd713-9556-42d7-6bf7-dee85fdf8c10@gmail.com> <9150a2ad-7c08-1f93-674a-963341bf0ece@suse.com> <24252f32-ef40-0daf-a585-36cb00f149d0@epam.com> From: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= Message-ID: Date: Tue, 30 Jun 2020 09:57:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <24252f32-ef40-0daf-a585-36cb00f149d0@epam.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 30.06.20 09:39, Oleksandr Andrushchenko wrote: > On 6/30/20 10:30 AM, Jürgen Groß wrote: >> On 30.06.20 09:09, Oleksandr Andrushchenko wrote: >>> On 6/30/20 10:03 AM, Jürgen Groß wrote: >>>> On 30.06.20 08:13, Oleksandr Andrushchenko wrote: >>>>> On 6/29/20 10:02 AM, Jürgen Groß wrote: >>>>>> On 20.05.20 11:04, Oleksandr Andrushchenko wrote: >>>>>>> From: Oleksandr Andrushchenko >>>>>>> >>>>>>> 1. Change protocol version from string to integer >>>>>>> >>>>>>> Version string, which is in fact an integer, is hard to handle in the >>>>>>> code that supports different protocol versions. To simplify that >>>>>>> make the version an integer. >>>>>>> >>>>>>> 2. Pass buffer offset with XENDISPL_OP_DBUF_CREATE >>>>>>> >>>>>>> There are cases when display data buffer is created with non-zero >>>>>>> offset to the data start. Handle such cases and provide that offset >>>>>>> while creating a display buffer. >>>>>>> >>>>>>> 3. Add XENDISPL_OP_GET_EDID command >>>>>>> >>>>>>> Add an optional request for reading Extended Display Identification >>>>>>> Data (EDID) structure which allows better configuration of the >>>>>>> display connectors over the configuration set in XenStore. >>>>>>> With this change connectors may have multiple resolutions defined >>>>>>> with respect to detailed timing definitions and additional properties >>>>>>> normally provided by displays. >>>>>>> >>>>>>> If this request is not supported by the backend then visible area >>>>>>> is defined by the relevant XenStore's "resolution" property. >>>>>>> >>>>>>> If backend provides extended display identification data (EDID) with >>>>>>> XENDISPL_OP_GET_EDID request then EDID values must take precedence >>>>>>> over the resolutions defined in XenStore. >>>>>>> >>>>>>> 4. Bump protocol version to 2. >>>>>>> >>>>>>> Signed-off-by: Oleksandr Andrushchenko >>>>>>> --- >>>>>>>    xen/include/public/io/displif.h | 83 +++++++++++++++++++++++++++++++-- >>>>>>>    1 file changed, 80 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h >>>>>>> index cc5de9cb1f35..4d43ba5078c8 100644 >>>>>>> --- a/xen/include/public/io/displif.h >>>>>>> +++ b/xen/include/public/io/displif.h >>>>>>> @@ -38,7 +38,7 @@ >>>>>>>     *                           Protocol version >>>>>>> ****************************************************************************** >>>>>>>     */ >>>>>>> -#define XENDISPL_PROTOCOL_VERSION     "1" >>>>>>> +#define XENDISPL_PROTOCOL_VERSION     2 >>>>>> >>>>>> This is not very nice regarding compatibility. >>>>>> >>>>>> Can't you add a new macro for the integer value? >>>>> >>>>> We can leave it as is, e.g. define XENDISPL_PROTOCOL_VERSION as "2", >>>>> >>>>> so we do not break the existing users. Then if every user of the header has >>>>> >>>>> its local copy (this is what we now use in the display backend), then that >>>>> local copy can be changed in a way suitable for the concrete user, e.g. "2" >>>>> >>>>> redefined to 2. This cannot be done (?) for the Linux Kernel though. >>>>> >>>>> Or we can have >>>>> >>>>> #define XENDISPL_PROTOCOL_VERSION     "2" >>>>> >>>>> #define XENDISPL_PROTOCOL_VERSION_INT  2 >>>>> >>>>> Jurgen, what's your preference here? >>>> >>>> I would prefer the latter, as it avoids the need to modify the header >>>> when copying it to a local project. >>>> >>> Ok, I'll have 2 definitions then >>> >>> Anything else (beside the comments on new functionality) I can add/change >>> >>> before sending v2 of the patch? >> >> I would have said so. :-) > > Thank you, > > the series also has a patch for libgnttab. Do you want me to send the protocol patch > > separately or should we wait for Ian and Wei to review? These changes are related, > > thus I sent then togheter This is something to ask the tools maintainers IMO. Juergen From xen-devel-bounces@lists.xenproject.org Tue Jun 30 08:30:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 08:30:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqBem-00049z-8P; Tue, 30 Jun 2020 08:30:20 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqBek-00049u-Uc for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 08:30:18 +0000 X-Inumbo-ID: ed8e4488-baab-11ea-bb8b-bc764e2007e4 Received: from esa6.hc3370-68.iphmx.com (unknown [216.71.155.175]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ed8e4488-baab-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 08:30:18 +0000 (UTC) Authentication-Results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: vJWCbZ24qNBCnRa1jeMfzFihapPAEXWOb/MH/cTYYQUyip68MUIwSFss/OBbvXPJYIxsyk1cMP fykjYjWPPolzXUfAKEKbi8v5e6uTYPGHa6se6prvblrrjZ315fDhXE1Ldp+PwYlfxKFSuTxQzJ fPz8b/Ptrkeq2wV7Rn+c0mEizLc08zRTfpE0PDc/3s/85ulln/xVa/ZpKNcjFMEisNHCGoh3Sk yQnP6MGeMNavHGNxNXThtwWpJyX4Yohpdvq55ZlG0FcG1zCwqQ5tX3XMLY0i4aQJXKK1yVMij0 oLM= X-SBRS: 2.7 X-MesageID: 21593289 X-Ironport-Server: esa6.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,296,1589256000"; d="scan'208";a="21593289" Date: Tue, 30 Jun 2020 10:30:06 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Anchal Agarwal Subject: Re: [PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation] Message-ID: <20200630083006.GJ735@Air-de-Roger> References: <20200604070548.GH1195@Air-de-Roger> <20200616214925.GA21684@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200617083528.GW735@Air-de-Roger> <20200619234312.GA24846@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200622083846.GF735@Air-de-Roger> <20200623004314.GA28586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200623081903.GP735@Air-de-Roger> <20200625183659.GA26586@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> <20200626091239.GA735@Air-de-Roger> <20200629192035.GA13195@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200629192035.GA13195@dev-dsk-anchalag-2a-9c2d1d96.us-west-2.amazon.com> X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Valentin, Eduardo" , "len.brown@intel.com" , "peterz@infradead.org" , "benh@kernel.crashing.org" , "x86@kernel.org" , "linux-mm@kvack.org" , "pavel@ucw.cz" , "hpa@zytor.com" , "tglx@linutronix.de" , "sstabellini@kernel.org" , "Kamata, Munehisa" , "mingo@redhat.com" , "xen-devel@lists.xenproject.org" , "Singh, Balbir" , "axboe@kernel.dk" , "konrad.wilk@oracle.com" , "bp@alien8.de" , Boris Ostrovsky , "jgross@suse.com" , "netdev@vger.kernel.org" , "linux-pm@vger.kernel.org" , "rjw@rjwysocki.net" , "linux-kernel@vger.kernel.org" , "vkuznets@redhat.com" , "davem@davemloft.net" , "Woodhouse, David" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, Jun 29, 2020 at 07:20:35PM +0000, Anchal Agarwal wrote: > On Fri, Jun 26, 2020 at 11:12:39AM +0200, Roger Pau Monné wrote: > > So the frontend should do: > > > > - Switch to Closed state (and cleanup everything required). > > - Wait for backend to switch to Closed state (must be done > > asynchronously, handled in blkback_changed). > > - Switch frontend to XenbusStateInitialising, that will in turn force > > the backend to switch to XenbusStateInitWait. > > - After that it should just follow the normal connection procedure. > > > > I think the part that's missing is the frontend doing the state change > > to XenbusStateInitialising when the backend switches to the Closed > > state. > > > > > I was of the view we may just want to mark frontend closed which should do > > > the job of freeing resources and then following the same flow as > > > blkfront_restore. That does not seems to work correctly 100% of the time. > > > > I think the missing part is that you must wait for the backend to > > switch to the Closed state, or else the switch to > > XenbusStateInitialising won't be picked up correctly by the backend > > (because it's still doing it's cleanup). > > > > Using blkfront_restore might be an option, but you need to assert the > > backend is in the initial state before using that path. > > > Yes, I agree and I make sure that XenbusStateInitialising only triggers > on frontend once backend is disconnected. msleep in a loop not that graceful but > works. > Frontend only switches to XenbusStateInitialising once it sees backend > as Closed. The issue here is and may require more debugging is: > 1. Hibernate instance->Closing failed, artificially created situation by not > marking frontend Closed in the first place during freezing. > 2. System comes back up fine restored to 'backend connected'. I'm not sure I'm following what is happening here, what should happen IMO is that the backend will eventually reach the Closed state? Ie: the frontend has initiated the disconnection from the backend by setting the Closing state, and the backend will have to eventually reach the Closed state. At that point the frontend can initiate a reconnection by switching to the Initialising state. > 3. Re-run (1) again without reboot > 4. (4) fails to recover basically freezing does not fail at all which is weird > because it should timeout as it passes through same path. It hits a BUG in > talk_to_blkback() and instance crashes. It's hard to tell exactly. I guess you would have to figure what makes the frontend not get stuck at the same place as the first attempt. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 30 08:42:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 08:42:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqBqD-000537-Cl; Tue, 30 Jun 2020 08:42:09 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqBqB-00052m-AC for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 08:42:07 +0000 X-Inumbo-ID: 8fb25136-baad-11ea-85d6-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 8fb25136-baad-11ea-85d6-12813bfff9fa; Tue, 30 Jun 2020 08:41:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XfGLlweefk5MqUmpVbcHA+2379xYlLhWZVfw1XQT2qA=; b=E2ImUmrKaxPlWw6gGbK+L0baG e5a+v/M3xQiI7o2ZBo9dzstEr1O4yslo+JnEx/PYLXRCSZKKy9wdbtqR3eKmKheAHCXWklGDkqBI/ IQlRRMCrHIScpKW6/OnDloPl0yQjLTvSL29ENPOhBefwKU73p4WLYhH9gkkUcH/ADriXk=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqBq2-0003vp-JP; Tue, 30 Jun 2020 08:41:58 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jqBq2-0001rk-5O; Tue, 30 Jun 2020 08:41:58 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jqBq2-0008Ov-4o; Tue, 30 Jun 2020 08:41:58 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151461: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=da53345dd5ff7d3a34e83587fd375c0b7722f46c X-Osstest-Versions-That: xen=88cfd062e8318dfeb67c7d2eb50b6cd224b0738a From: osstest service owner Date: Tue, 30 Jun 2020 08:41:58 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151461 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151461/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151448 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151448 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151448 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151448 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151448 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151448 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151448 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151448 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 151448 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen da53345dd5ff7d3a34e83587fd375c0b7722f46c baseline version: xen 88cfd062e8318dfeb67c7d2eb50b6cd224b0738a Last test of basis 151448 2020-06-29 06:27:51 Z 1 days Testing same since 151461 2020-06-29 19:39:16 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Jan Beulich jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 88cfd062e8..da53345dd5 da53345dd5ff7d3a34e83587fd375c0b7722f46c -> master From xen-devel-bounces@lists.xenproject.org Tue Jun 30 09:43:21 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 09:43:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqCn4-0001VZ-8o; Tue, 30 Jun 2020 09:42:58 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqCn2-0001VU-Nm for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 09:42:57 +0000 X-Inumbo-ID: 11a77fec-bab6-11ea-bb8b-bc764e2007e4 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (unknown [40.107.22.41]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 11a77fec-bab6-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 09:42:53 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NcJyvzceWJxQvwzEJn/unQ/w7YHl8nRlNOG9AbUSDYFi4AGOZ6gSaBrJEzuf5rnuenWE8P6pGiF50ev2hgG2jSfrwkQWQ4J/rICy+1OXo78LEDmnzFX5jjRV5VljWu4S2/b1Mv2tYkEB84/H5wg0miRvntMWMSL8A/Vdx0KQIkE5rgoRg7VnUoi22mLlYm/1JoDmfRERw2EGdzH4XgeXI+hlkoLdo4FFnsjz2boheHqvlsegLJ1aowXmlN1uxs6sfiUVPhsV0Q3PjzguZ7blVnSE4uVubti5ijgwKzB71n+AUK8wluuVeRqNWdzrQY6jPoRYmUZTZwtYBYUt4MZ7Cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZAYV/fPERlBKmfHX9kr4E69CpyHZBcKQdUD7fHXbbHU=; b=ghfi9hn2UDX3Q2jql2aqQH3bx6ZQl+DSnzd5qOdfcgiF7Ur4w6Ot4IP82z6NcKebg4YgLjhz7N9uryKtotUaNy+te9tKE/YtGbbvr8b0GHjKy9wAus9h5q+XTpd5vPbph4jeGjQAWA0vEkzR4Fq6Hbmt4ZyigiotAyNOJxGNrzjNEz/jECgrnQlLOHpSScgGWHQ4rgK4g5q3uAd6a8H3SA0qbp11J7JYBzvtt2PwyaHTdysSpw62tf4xld54Y79p4Lu/jvBgV7RXnEJo6fifeDnnLcYLB+F3QtPa9s1zCKxgwKx2q40RBWOZl8uivt/NxejNv4wpVkSdVYPZmdVFcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=epam.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZAYV/fPERlBKmfHX9kr4E69CpyHZBcKQdUD7fHXbbHU=; b=MhfuTo4tSOfM6PzeRM1WPRz/5PP0EKMhQdRygVg+mFJxbbFVwkDUoXpK3tMq9ByrcYAaZentWR/EKnEFX0CAsA3i0Ovr/iHj4Zv2nKiGR2Aqwdb3Ny4Rvop/G+wBu3wbQ9eL/EXQobgpZveAYyy+y57QhiJY+F+FGzM3liDsgkCaVdKhVCN7iOUQCmcKKSkycrQDR0q3uTk+UWGyZYfOOvf/YdciPZ31QCGUQ9jC9FRL/6C6zsqMRuC+g1OFFo9vGH014xTYkBZorTD7BEuxHiPrpW+RlKPTe5A6Paz68oyoOrUJT/zhemIWQnp2N5tXbspfMI2/ju6mlNBQLpE5LQ== Received: from DB7PR03MB3993.eurprd03.prod.outlook.com (2603:10a6:5:38::26) by DB7PR03MB3994.eurprd03.prod.outlook.com (2603:10a6:5:32::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Tue, 30 Jun 2020 09:42:52 +0000 Received: from DB7PR03MB3993.eurprd03.prod.outlook.com ([fe80::e500:29a2:9c1a:bdfe]) by DB7PR03MB3993.eurprd03.prod.outlook.com ([fe80::e500:29a2:9c1a:bdfe%7]) with mapi id 15.20.3131.027; Tue, 30 Jun 2020 09:42:52 +0000 From: Oleksandr Andrushchenko To: Oleksandr Andrushchenko , "ian.jackson@eu.citrix.com" , "wl@xen.org" Subject: Re: [PATCH 2/2] libgnttab: Add support for Linux dma-buf offset Thread-Topic: [PATCH 2/2] libgnttab: Add support for Linux dma-buf offset Thread-Index: AQHWLoWvWdjq7ozlqkeaZNP0F/2zoKjxKJiA Date: Tue, 30 Jun 2020 09:42:51 +0000 Message-ID: <548f327b-d466-f1df-ef17-80f2d3d42286@epam.com> References: <20200520090425.28558-1-andr2000@gmail.com> <20200520090425.28558-3-andr2000@gmail.com> In-Reply-To: <20200520090425.28558-3-andr2000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=epam.com; x-originating-ip: [185.199.97.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9dcecf73-7351-43a4-e75d-08d81cd9f549 x-ms-traffictypediagnostic: DB7PR03MB3994: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0450A714CB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZCqpwoc0oLR+11MDX6ELfHxM4NvPb/J9py941mLgwfHSL4E9FkfEhZ9i4q8Jur3Lokmlp6k4VkGHfZFzhkMxWfpfw7fZfzRf7bYZspVq+79cNl6+ZlfdSm9jRJIevXLRMPpaAQPfbUomCzjCAOUkbdgks/f4WT4HuKuWsG0PPgmG07kZsomJAOjxwNzqC4eIi3Ud3XC4YkGarVmAuwA1c4iuqcSWTRNX/mkI9QQH0Z2c76YCHAywiVVRCtPGhW4wlwdmNTWQXYWzyPc0L3a4xPhpuxmIcxz35FyJ7W5DPRCVrvXYYi2vCBMAhvIPpMJ5dzVY5QbVekuo5cf65SuVzPR/B84isyKxGtb/g5uhWT4lSyDpLi4k5K0/LXMyGHaadRW8qNLrV6vP3IgHnbGXXTn1dfE6iVawHIOSDQvir/3ltkl6OC7kL37wdSsMvB1eP9+7L0asHI6K4vapt6GfYQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR03MB3993.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(376002)(346002)(39860400002)(478600001)(86362001)(4326008)(186003)(5660300002)(83380400001)(2616005)(26005)(71200400001)(31696002)(110136005)(316002)(36756003)(30864003)(6486002)(6512007)(966005)(8676002)(8936002)(53546011)(6506007)(31686004)(66946007)(54906003)(2906002)(66476007)(91956017)(76116006)(66446008)(64756008)(66556008)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 76QaCB2YBPDRv1KoyPI+n4JZ/c4BQglz2PKm9wWZRnT4RRYPhMjMsBayY50gx+DxcYIKlY1JetDFLtoMLybzRiXCbyTsS+le2ldykHDWDTKbEEXsX6ELA1e5FPFQLDVl0iOsn5shdZ92CnIpB2UwHobgA985S9X9XhqiZJivzDhQT3ewdxM9kEC9+s1QAydNDWcqm7kpxZ2eC0M/8/zPuWWuNtO2WOFLZMqgYfNYv/vksNp26OM7WY7lcTIOBhqyS2zfVM02WCYVaWW2zXNTPazZI5vISXDie/uSOwbSTb9bYmvSyvwMaFud51xiq5mYMkytzjydOEV6WcTNPREl3pLftZtezScYncfHaVdtTXnfRhE556PJJG0lfCOfQDaEpcTy6+GGJ/9GwXNLdCmLhxTlZerm5x9zAD+DGRQuMhLLiDOoVMbmU4AOY7cDDa83FxTlz5BCqSkOzowPL8o3updMi6jmiHaiGy+8pZY2Wi4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2E3BDFAF6AF5964C8E4E6BEB7F7A8F74@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: epam.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR03MB3993.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9dcecf73-7351-43a4-e75d-08d81cd9f549 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2020 09:42:51.9678 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b41b72d0-4e9f-4c26-8a69-f949f367c91d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RVquSB99nHHyHBkNwps1Sz7I3ER6mpF3CXgzQNrNnqbN+YsMlPs5Fvj4ekThESzT45RpQshPqUZocO1CtlXz82Q093tUG41XnzQxAoyU/+X7eitjdDlL/xdVVMgFTAwk X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR03MB3994 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" SWFuLCBXZWksIHdvdWxkIHlvdSBtaW5kIGxvb2tpbmcgYXQgdGhlIGJlbG93IHBsZWFzZT8NCg0K VGhhbmsgeW91IGluIGFkdmFuY2UsDQoNCk9sZWtzYW5kcg0KDQpPbiA1LzIwLzIwIDEyOjA0IFBN LCBPbGVrc2FuZHIgQW5kcnVzaGNoZW5rbyB3cm90ZToNCj4gRnJvbTogT2xla3NhbmRyIEFuZHJ1 c2hjaGVua28gPG9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPg0KPg0KPiBBZGQgdmVy c2lvbiAyIG9mIHRoZSBkbWEtYnVmIGlvY3RscyB3aGljaCBhZGRzIGRhdGFfb2ZzIHBhcmFtZXRl ci4NCj4NCj4gZG1hLWJ1ZiBpcyBiYWNrZWQgYnkgYSBzY2F0dGVyLWdhdGhlciB0YWJsZSBhbmQg aGFzIG9mZnNldCBwYXJhbWV0ZXINCj4gd2hpY2ggdGVsbHMgd2hlcmUgdGhlIGFjdHVhbCBkYXRh IHN0YXJ0cy4gUmVsZXZhbnQgaW9jdGxzIGFyZSBleHRlbmRlZA0KPiB0byBzdXBwb3J0IHRoYXQg b2Zmc2V0Og0KPiAgICAtIHdoZW4gZG1hLWJ1ZiBpcyBjcmVhdGVkIChleHBvcnRlZCkgZnJvbSBn cmFudCByZWZlcmVuY2VzIHRoZW4NCj4gICAgICBkYXRhX29mcyBpcyB1c2VkIHRvIHNldCB0aGUg b2Zmc2V0IGZpZWxkIGluIHRoZSBzY2F0dGVyIGxpc3QNCj4gICAgICBvZiB0aGUgbmV3IGRtYS1i dWYNCj4gICAgLSB3aGVuIGRtYS1idWYgaXMgaW1wb3J0ZWQgYW5kIGdyYW50IHJlZmVyZW5jZXMg cHJvdmlkZWQgdGhlbg0KPiAgICAgIGRhdGFfb2ZzIGlzIHVzZWQgdG8gcmVwb3J0IHRoYXQgb2Zm c2V0IHRvIHVzZXItc3BhY2UNCj4NCj4gU2lnbmVkLW9mZi1ieTogT2xla3NhbmRyIEFuZHJ1c2hj aGVua28gPG9sZWtzYW5kcl9hbmRydXNoY2hlbmtvQGVwYW0uY29tPg0KPiAtLS0NCj4gICB0b29s cy9pbmNsdWRlL3hlbi1zeXMvTGludXgvZ250ZGV2LmggIHwgNTMgKysrKysrKysrKysrKysrKysN Cj4gICB0b29scy9saWJzL2dudHRhYi9NYWtlZmlsZSAgICAgICAgICAgIHwgIDIgKy0NCj4gICB0 b29scy9saWJzL2dudHRhYi9mcmVlYnNkLmMgICAgICAgICAgIHwgMTUgKysrKysNCj4gICB0b29s cy9saWJzL2dudHRhYi9nbnR0YWJfY29yZS5jICAgICAgIHwgMTcgKysrKysrDQo+ICAgdG9vbHMv bGlicy9nbnR0YWIvaW5jbHVkZS94ZW5nbnR0YWIuaCB8IDEzICsrKysNCj4gICB0b29scy9saWJz L2dudHRhYi9saWJ4ZW5nbnR0YWIubWFwICAgIHwgIDYgKysNCj4gICB0b29scy9saWJzL2dudHRh Yi9saW51eC5jICAgICAgICAgICAgIHwgODYgKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+ ICAgdG9vbHMvbGlicy9nbnR0YWIvbWluaW9zLmMgICAgICAgICAgICB8IDE1ICsrKysrDQo+ICAg dG9vbHMvbGlicy9nbnR0YWIvcHJpdmF0ZS5oICAgICAgICAgICB8ICA5ICsrKw0KPiAgIDkgZmls ZXMgY2hhbmdlZCwgMjE1IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4NCj4gZGlmZiAt LWdpdCBhL3Rvb2xzL2luY2x1ZGUveGVuLXN5cy9MaW51eC9nbnRkZXYuaCBiL3Rvb2xzL2luY2x1 ZGUveGVuLXN5cy9MaW51eC9nbnRkZXYuaA0KPiBpbmRleCBkMTYwNzYwNDRjNzEuLjBjNDMzOTNj YmVlNSAxMDA2NDQNCj4gLS0tIGEvdG9vbHMvaW5jbHVkZS94ZW4tc3lzL0xpbnV4L2dudGRldi5o DQo+ICsrKyBiL3Rvb2xzL2luY2x1ZGUveGVuLXN5cy9MaW51eC9nbnRkZXYuaA0KPiBAQCAtMjc0 LDQgKzI3NCw1NyBAQCBzdHJ1Y3QgaW9jdGxfZ250ZGV2X2RtYWJ1Zl9pbXBfcmVsZWFzZSB7DQo+ ICAgICAgIHVpbnQzMl90IHJlc2VydmVkOw0KPiAgIH07DQo+ICAgDQo+ICsvKg0KPiArICogVmVy c2lvbiAyIG9mIHRoZSBpb2N0bHMgYWRkcyBAZGF0YV9vZnMgcGFyYW1ldGVyLg0KPiArICoNCj4g KyAqIGRtYS1idWYgaXMgYmFja2VkIGJ5IGEgc2NhdHRlci1nYXRoZXIgdGFibGUgYW5kIGhhcyBv ZmZzZXQNCj4gKyAqIHBhcmFtZXRlciB3aGljaCB0ZWxscyB3aGVyZSB0aGUgYWN0dWFsIGRhdGEg c3RhcnRzLg0KPiArICogUmVsZXZhbnQgaW9jdGxzIGFyZSBleHRlbmRlZCB0byBzdXBwb3J0IHRo YXQgb2Zmc2V0Og0KPiArICogICAtIHdoZW4gZG1hLWJ1ZiBpcyBjcmVhdGVkIChleHBvcnRlZCkg ZnJvbSBncmFudCByZWZlcmVuY2VzIHRoZW4NCj4gKyAqICAgICBAZGF0YV9vZnMgaXMgdXNlZCB0 byBzZXQgdGhlIG9mZnNldCBmaWVsZCBpbiB0aGUgc2NhdHRlciBsaXN0DQo+ICsgKiAgICAgb2Yg dGhlIG5ldyBkbWEtYnVmDQo+ICsgKiAgIC0gd2hlbiBkbWEtYnVmIGlzIGltcG9ydGVkIGFuZCBn cmFudCByZWZlcmVuY2VzIGFyZSBwcm92aWRlZCB0aGVuDQo+ICsgKiAgICAgQGRhdGFfb2ZzIGlz IHVzZWQgdG8gcmVwb3J0IHRoYXQgb2Zmc2V0IHRvIHVzZXItc3BhY2UNCj4gKyAqLw0KPiArI2Rl ZmluZSBJT0NUTF9HTlRERVZfRE1BQlVGX0VYUF9GUk9NX1JFRlNfVjIgXA0KPiArICAgIF9JT0Mo X0lPQ19OT05FLCAnRycsIDEzLCBcDQo+ICsgICAgICAgICBzaXplb2Yoc3RydWN0IGlvY3RsX2du dGRldl9kbWFidWZfZXhwX2Zyb21fcmVmc192MikpDQo+ICtzdHJ1Y3QgaW9jdGxfZ250ZGV2X2Rt YWJ1Zl9leHBfZnJvbV9yZWZzX3YyIHsNCj4gKyAgICAvKiBJTiBwYXJhbWV0ZXJzLiAqLw0KPiAr ICAgIC8qIFNwZWNpZmljIG9wdGlvbnMgZm9yIHRoaXMgZG1hLWJ1Zjogc2VlIEdOVERFVl9ETUFf RkxBR19YWFguICovDQo+ICsgICAgdWludDMyX3QgZmxhZ3M7DQo+ICsgICAgLyogTnVtYmVyIG9m IGdyYW50IHJlZmVyZW5jZXMgaW4gQHJlZnMgYXJyYXkuICovDQo+ICsgICAgdWludDMyX3QgY291 bnQ7DQo+ICsgICAgLyogT2Zmc2V0IG9mIHRoZSBkYXRhIGluIHRoZSBkbWEtYnVmLiAqLw0KPiAr ICAgIHVpbnQzMl90IGRhdGFfb2ZzOw0KPiArICAgIC8qIE9VVCBwYXJhbWV0ZXJzLiAqLw0KPiAr ICAgIC8qIEZpbGUgZGVzY3JpcHRvciBvZiB0aGUgZG1hLWJ1Zi4gKi8NCj4gKyAgICB1aW50MzJf dCBmZDsNCj4gKyAgICAvKiBUaGUgZG9tYWluIElEIG9mIHRoZSBncmFudCByZWZlcmVuY2VzIHRv IGJlIG1hcHBlZC4gKi8NCj4gKyAgICB1aW50MzJfdCBkb21pZDsNCj4gKyAgICAvKiBWYXJpYWJs ZSBJTiBwYXJhbWV0ZXIuICovDQo+ICsgICAgLyogQXJyYXkgb2YgZ3JhbnQgcmVmZXJlbmNlcyBv ZiBzaXplIEBjb3VudC4gKi8NCj4gKyAgICB1aW50MzJfdCByZWZzWzFdOw0KPiArfTsNCj4gKw0K PiArI2RlZmluZSBJT0NUTF9HTlRERVZfRE1BQlVGX0lNUF9UT19SRUZTX1YyIFwNCj4gKyAgICBf SU9DKF9JT0NfTk9ORSwgJ0cnLCAxNCwgXA0KPiArICAgICAgICAgc2l6ZW9mKHN0cnVjdCBpb2N0 bF9nbnRkZXZfZG1hYnVmX2ltcF90b19yZWZzX3YyKSkNCj4gK3N0cnVjdCBpb2N0bF9nbnRkZXZf ZG1hYnVmX2ltcF90b19yZWZzX3YyIHsNCj4gKyAgICAvKiBJTiBwYXJhbWV0ZXJzLiAqLw0KPiAr ICAgIC8qIEZpbGUgZGVzY3JpcHRvciBvZiB0aGUgZG1hLWJ1Zi4gKi8NCj4gKyAgICB1aW50MzJf dCBmZDsNCj4gKyAgICAvKiBOdW1iZXIgb2YgZ3JhbnQgcmVmZXJlbmNlcyBpbiBAcmVmcyBhcnJh eS4gKi8NCj4gKyAgICB1aW50MzJfdCBjb3VudDsNCj4gKyAgICAvKiBUaGUgZG9tYWluIElEIGZv ciB3aGljaCByZWZlcmVuY2VzIHRvIGJlIGdyYW50ZWQuICovDQo+ICsgICAgdWludDMyX3QgZG9t aWQ7DQo+ICsgICAgLyogUmVzZXJ2ZWQgLSBtdXN0IGJlIHplcm8uICovDQo+ICsgICAgdWludDMy X3QgcmVzZXJ2ZWQ7DQo+ICsgICAgLyogT1VUIHBhcmFtZXRlcnMuICovDQo+ICsgICAgLyogT2Zm c2V0IG9mIHRoZSBkYXRhIGluIHRoZSBkbWEtYnVmLiAqLw0KPiArICAgIHVpbnQzMl90IGRhdGFf b2ZzOw0KPiArICAgIC8qIEFycmF5IG9mIGdyYW50IHJlZmVyZW5jZXMgb2Ygc2l6ZSBAY291bnQu ICovDQo+ICsgICAgdWludDMyX3QgcmVmc1sxXTsNCj4gK307DQo+ICsNCj4gICAjZW5kaWYgLyog X19MSU5VWF9QVUJMSUNfR05UREVWX0hfXyAqLw0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9n bnR0YWIvTWFrZWZpbGUgYi90b29scy9saWJzL2dudHRhYi9NYWtlZmlsZQ0KPiBpbmRleCAyZGE4 ZmJiYjdmNmYuLjVlZTJkOTY1MjE0ZiAxMDA2NDQNCj4gLS0tIGEvdG9vbHMvbGlicy9nbnR0YWIv TWFrZWZpbGUNCj4gKysrIGIvdG9vbHMvbGlicy9nbnR0YWIvTWFrZWZpbGUNCj4gQEAgLTIsNyAr Miw3IEBAIFhFTl9ST09UID0gJChDVVJESVIpLy4uLy4uLy4uDQo+ICAgaW5jbHVkZSAkKFhFTl9S T09UKS90b29scy9SdWxlcy5taw0KPiAgIA0KPiAgIE1BSk9SICAgID0gMQ0KPiAtTUlOT1IgICAg PSAyDQo+ICtNSU5PUiAgICA9IDMNCj4gICBMSUJOQU1FICA6PSBnbnR0YWINCj4gICBVU0VMSUJT ICA6PSB0b29sbG9nIHRvb2xjb3JlDQo+ICAgDQo+IGRpZmYgLS1naXQgYS90b29scy9saWJzL2du dHRhYi9mcmVlYnNkLmMgYi90b29scy9saWJzL2dudHRhYi9mcmVlYnNkLmMNCj4gaW5kZXggODg2 YjU4ODMwM2EwLi5iYWYwZjYwYWE0ZDMgMTAwNjQ0DQo+IC0tLSBhL3Rvb2xzL2xpYnMvZ250dGFi L2ZyZWVic2QuYw0KPiArKysgYi90b29scy9saWJzL2dudHRhYi9mcmVlYnNkLmMNCj4gQEAgLTMx OSw2ICszMTksMTQgQEAgaW50IG9zZGVwX2dudHRhYl9kbWFidWZfZXhwX2Zyb21fcmVmcyh4ZW5n bnR0YWJfaGFuZGxlICp4Z3QsIHVpbnQzMl90IGRvbWlkLA0KPiAgICAgICBhYm9ydCgpOw0KPiAg IH0NCj4gICANCj4gK2ludCBvc2RlcF9nbnR0YWJfZG1hYnVmX2V4cF9mcm9tX3JlZnNfdjIoeGVu Z250dGFiX2hhbmRsZSAqeGd0LCB1aW50MzJfdCBkb21pZCwNCj4gKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZmxhZ3MsIHVpbnQzMl90IGNvdW50LA0K PiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB1aW50MzJf dCAqcmVmcywNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWlu dDMyX3QgKmRtYWJ1Zl9mZCwgdWludDMyX3QgZGF0YV9vZnMpDQo+ICt7DQo+ICsgICAgYWJvcnQo KTsNCj4gK30NCj4gKw0KPiAgIGludCBvc2RlcF9nbnR0YWJfZG1hYnVmX2V4cF93YWl0X3JlbGVh c2VkKHhlbmdudHRhYl9oYW5kbGUgKnhndCwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1aW50MzJfdCBmZCwgdWludDMyX3Qgd2FpdF90b19tcykNCj4gICB7 DQo+IEBAIC0zMzEsNiArMzM5LDEzIEBAIGludCBvc2RlcF9nbnR0YWJfZG1hYnVmX2ltcF90b19y ZWZzKHhlbmdudHRhYl9oYW5kbGUgKnhndCwgdWludDMyX3QgZG9taWQsDQo+ICAgICAgIGFib3J0 KCk7DQo+ICAgfQ0KPiAgIA0KPiAraW50IG9zZGVwX2dudHRhYl9kbWFidWZfaW1wX3RvX3JlZnNf djIoeGVuZ250dGFiX2hhbmRsZSAqeGd0LCB1aW50MzJfdCBkb21pZCwNCj4gKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGZkLCB1aW50MzJfdCBjb3VudCwN Cj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90ICpyZWZz LCB1aW50MzJfdCAqZGF0YV9vZnMpDQo+ICt7DQo+ICsgICAgYWJvcnQoKTsNCj4gK30NCj4gKw0K PiAgIGludCBvc2RlcF9nbnR0YWJfZG1hYnVmX2ltcF9yZWxlYXNlKHhlbmdudHRhYl9oYW5kbGUg KnhndCwgdWludDMyX3QgZmQpDQo+ICAgew0KPiAgICAgICBhYm9ydCgpOw0KPiBkaWZmIC0tZ2l0 IGEvdG9vbHMvbGlicy9nbnR0YWIvZ250dGFiX2NvcmUuYyBiL3Rvb2xzL2xpYnMvZ250dGFiL2du dHRhYl9jb3JlLmMNCj4gaW5kZXggOTJlNzIyOGEyNjcxLi4zYWYzY2VjODAwNDUgMTAwNjQ0DQo+ IC0tLSBhL3Rvb2xzL2xpYnMvZ250dGFiL2dudHRhYl9jb3JlLmMNCj4gKysrIGIvdG9vbHMvbGli cy9nbnR0YWIvZ250dGFiX2NvcmUuYw0KPiBAQCAtMTQ0LDYgKzE0NCwxNSBAQCBpbnQgeGVuZ250 dGFiX2RtYWJ1Zl9leHBfZnJvbV9yZWZzKHhlbmdudHRhYl9oYW5kbGUgKnhndCwgdWludDMyX3Qg ZG9taWQsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg cmVmcywgZmQpOw0KPiAgIH0NCj4gICANCj4gK2ludCB4ZW5nbnR0YWJfZG1hYnVmX2V4cF9mcm9t X3JlZnNfdjIoeGVuZ250dGFiX2hhbmRsZSAqeGd0LCB1aW50MzJfdCBkb21pZCwNCj4gKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZmxhZ3MsIHVpbnQzMl90 IGNvdW50LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB1 aW50MzJfdCAqcmVmcywgdWludDMyX3QgKmZkLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB1aW50MzJfdCBkYXRhX29mcykNCj4gK3sNCj4gKyAgICByZXR1cm4gb3Nk ZXBfZ250dGFiX2RtYWJ1Zl9leHBfZnJvbV9yZWZzX3YyKHhndCwgZG9taWQsIGZsYWdzLCBjb3Vu dCwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJl ZnMsIGZkLCBkYXRhX29mcyk7DQo+ICt9DQo+ICsNCj4gICBpbnQgeGVuZ250dGFiX2RtYWJ1Zl9l eHBfd2FpdF9yZWxlYXNlZCh4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsIHVpbnQzMl90IGZkLA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IHdhaXRfdG9f bXMpDQo+ICAgew0KPiBAQCAtMTU2LDYgKzE2NSwxNCBAQCBpbnQgeGVuZ250dGFiX2RtYWJ1Zl9p bXBfdG9fcmVmcyh4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsIHVpbnQzMl90IGRvbWlkLA0KPiAgICAg ICByZXR1cm4gb3NkZXBfZ250dGFiX2RtYWJ1Zl9pbXBfdG9fcmVmcyh4Z3QsIGRvbWlkLCBmZCwg Y291bnQsIHJlZnMpOw0KPiAgIH0NCj4gICANCj4gK2ludCB4ZW5nbnR0YWJfZG1hYnVmX2ltcF90 b19yZWZzX3YyKHhlbmdudHRhYl9oYW5kbGUgKnhndCwgdWludDMyX3QgZG9taWQsDQo+ICsgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBmZCwgdWludDMyX3QgY291 bnQsIHVpbnQzMl90ICpyZWZzLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdWludDMyX3QgKmRhdGFfb2ZzKQ0KPiArew0KPiArICAgIHJldHVybiBvc2RlcF9nbnR0YWJf ZG1hYnVmX2ltcF90b19yZWZzX3YyKHhndCwgZG9taWQsIGZkLCBjb3VudCwgcmVmcywNCj4gKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkYXRhX29mcyk7DQo+ ICt9DQo+ICsNCj4gICBpbnQgeGVuZ250dGFiX2RtYWJ1Zl9pbXBfcmVsZWFzZSh4ZW5nbnR0YWJf aGFuZGxlICp4Z3QsIHVpbnQzMl90IGZkKQ0KPiAgIHsNCj4gICAgICAgcmV0dXJuIG9zZGVwX2du dHRhYl9kbWFidWZfaW1wX3JlbGVhc2UoeGd0LCBmZCk7DQo+IGRpZmYgLS1naXQgYS90b29scy9s aWJzL2dudHRhYi9pbmNsdWRlL3hlbmdudHRhYi5oIGIvdG9vbHMvbGlicy9nbnR0YWIvaW5jbHVk ZS94ZW5nbnR0YWIuaA0KPiBpbmRleCAxMTFmYzg4Y2FlYjMuLjA5NTZiZDkxZTBkZiAxMDA2NDQN Cj4gLS0tIGEvdG9vbHMvbGlicy9nbnR0YWIvaW5jbHVkZS94ZW5nbnR0YWIuaA0KPiArKysgYi90 b29scy9saWJzL2dudHRhYi9pbmNsdWRlL3hlbmdudHRhYi5oDQo+IEBAIC0zMjIsMTIgKzMyMiwx OSBAQCBpbnQgeGVuZ250dGFiX2dyYW50X2NvcHkoeGVuZ250dGFiX2hhbmRsZSAqeGd0LA0KPiAg ICAqIFJldHVybnMgMCBpZiBkbWEtYnVmIHdhcyBzdWNjZXNzZnVsbHkgY3JlYXRlZCBhbmQgdGhl IGNvcnJlc3BvbmRpbmcNCj4gICAgKiBkbWEtYnVmJ3MgZmlsZSBkZXNjcmlwdG9yIGlzIHJldHVy bmVkIGluIEBmZC4NCj4gICAgKg0KPiArICogVmVyc2lvbiAyIGFsc28gYWNjZXB0cyBAZGF0YV9v ZnMgb2Zmc2V0IG9mIHRoZSBkYXRhIGluIHRoZSBidWZmZXIuDQo+ICsgKg0KPiAgICAqIFsxXSBo dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9lbGl4aXIuYm9vdGxpbi5jb20vbGlu dXgvbGF0ZXN0L3NvdXJjZS9Eb2N1bWVudGF0aW9uL2RyaXZlci1hcGkvZG1hLWJ1Zi5yc3RfXzsh IUdGXzI5ZGJjUUlVQlBBIW5CQUJrUHBFeVFXMV81blBFOW5ieUNiRWFDdlJqWFF4T0JLUnBSU0lH VWdBZHFjYzBWQ200akwtOWNDYWJjV05EUzRiY19EUjZRJA0KPiAgICAqLw0KPiAgIGludCB4ZW5n bnR0YWJfZG1hYnVmX2V4cF9mcm9tX3JlZnMoeGVuZ250dGFiX2hhbmRsZSAqeGd0LCB1aW50MzJf dCBkb21pZCwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90 IGZsYWdzLCB1aW50MzJfdCBjb3VudCwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGNvbnN0IHVpbnQzMl90ICpyZWZzLCB1aW50MzJfdCAqZmQpOw0KPiAgIA0KPiAraW50 IHhlbmdudHRhYl9kbWFidWZfZXhwX2Zyb21fcmVmc192Mih4ZW5nbnR0YWJfaGFuZGxlICp4Z3Qs IHVpbnQzMl90IGRvbWlkLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB1aW50MzJfdCBmbGFncywgdWludDMyX3QgY291bnQsDQo+ICsgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNvbnN0IHVpbnQzMl90ICpyZWZzLCB1aW50MzJfdCAqZmQsDQo+ ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRhdGFfb2Zz KTsNCj4gKw0KPiAgIC8qDQo+ICAgICogVGhpcyB3aWxsIGJsb2NrIHVudGlsIHRoZSBkbWEtYnVm IHdpdGggdGhlIGZpbGUgZGVzY3JpcHRvciBAZmQgaXMNCj4gICAgKiByZWxlYXNlZC4gVGhpcyBp cyBvbmx5IHZhbGlkIGZvciBidWZmZXJzIGNyZWF0ZWQgd2l0aA0KPiBAQCAtMzQ1LDEwICszNTIs MTYgQEAgaW50IHhlbmdudHRhYl9kbWFidWZfZXhwX3dhaXRfcmVsZWFzZWQoeGVuZ250dGFiX2hh bmRsZSAqeGd0LCB1aW50MzJfdCBmZCwNCj4gICAvKg0KPiAgICAqIEltcG9ydCBhIGRtYS1idWYg d2l0aCBmaWxlIGRlc2NyaXB0b3IgQGZkIGFuZCBleHBvcnQgZ3JhbnRlZCByZWZlcmVuY2VzDQo+ ICAgICogdG8gdGhlIHBhZ2VzIG9mIHRoYXQgZG1hLWJ1ZiBpbnRvIGFycmF5IEByZWZzIG9mIHNp emUgQGNvdW50Lg0KPiArICoNCj4gKyAqIFZlcnNpb24gMiBhbHNvIHByb3ZpZGVzIEBkYXRhX29m cyBvZmZzZXQgb2YgdGhlIGRhdGEgaW4gdGhlIGJ1ZmZlci4NCj4gICAgKi8NCj4gICBpbnQgeGVu Z250dGFiX2RtYWJ1Zl9pbXBfdG9fcmVmcyh4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsIHVpbnQzMl90 IGRvbWlkLA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGZk LCB1aW50MzJfdCBjb3VudCwgdWludDMyX3QgKnJlZnMpOw0KPiAgIA0KPiAraW50IHhlbmdudHRh Yl9kbWFidWZfaW1wX3RvX3JlZnNfdjIoeGVuZ250dGFiX2hhbmRsZSAqeGd0LCB1aW50MzJfdCBk b21pZCwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGZk LCB1aW50MzJfdCBjb3VudCwgdWludDMyX3QgKnJlZnMsDQo+ICsgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1aW50MzJfdCAqZGF0YV9vZnMpOw0KPiArDQo+ICAgLyoNCj4gICAg KiBUaGlzIHdpbGwgY2xvc2UgYWxsIHJlZmVyZW5jZXMgdG8gYW4gaW1wb3J0ZWQgYnVmZmVyLCBz byBpdCBjYW4gYmUNCj4gICAgKiByZWxlYXNlZCBieSB0aGUgb3duZXIuIFRoaXMgaXMgb25seSB2 YWxpZCBmb3IgYnVmZmVycyBjcmVhdGVkIHdpdGgNCj4gZGlmZiAtLWdpdCBhL3Rvb2xzL2xpYnMv Z250dGFiL2xpYnhlbmdudHRhYi5tYXAgYi90b29scy9saWJzL2dudHRhYi9saWJ4ZW5nbnR0YWIu bWFwDQo+IGluZGV4IGQyYTliN2UxOGJlYS4uZGRmNzdlMDY0YjA4IDEwMDY0NA0KPiAtLS0gYS90 b29scy9saWJzL2dudHRhYi9saWJ4ZW5nbnR0YWIubWFwDQo+ICsrKyBiL3Rvb2xzL2xpYnMvZ250 dGFiL2xpYnhlbmdudHRhYi5tYXANCj4gQEAgLTM2LDMgKzM2LDkgQEAgVkVSU18xLjIgew0KPiAg IAkJeGVuZ250dGFiX2RtYWJ1Zl9pbXBfdG9fcmVmczsNCj4gICAJCXhlbmdudHRhYl9kbWFidWZf aW1wX3JlbGVhc2U7DQo+ICAgfSBWRVJTXzEuMTsNCj4gKw0KPiArVkVSU18xLjMgew0KPiArICAg IGdsb2JhbDoNCj4gKwkJeGVuZ250dGFiX2RtYWJ1Zl9leHBfZnJvbV9yZWZzX3YyOw0KPiArCQl4 ZW5nbnR0YWJfZG1hYnVmX2ltcF90b19yZWZzX3YyOw0KPiArfSBWRVJTXzEuMjsNCj4gZGlmZiAt LWdpdCBhL3Rvb2xzL2xpYnMvZ250dGFiL2xpbnV4LmMgYi90b29scy9saWJzL2dudHRhYi9saW51 eC5jDQo+IGluZGV4IGEwMWJiNmM2OThjNi4uNzVlMjQ5ZmIzMjAyIDEwMDY0NA0KPiAtLS0gYS90 b29scy9saWJzL2dudHRhYi9saW51eC5jDQo+ICsrKyBiL3Rvb2xzL2xpYnMvZ250dGFiL2xpbnV4 LmMNCj4gQEAgLTM1Miw2ICszNTIsNTEgQEAgb3V0Og0KPiAgICAgICByZXR1cm4gcmM7DQo+ICAg fQ0KPiAgIA0KPiAraW50IG9zZGVwX2dudHRhYl9kbWFidWZfZXhwX2Zyb21fcmVmc192Mih4ZW5n bnR0YWJfaGFuZGxlICp4Z3QsIHVpbnQzMl90IGRvbWlkLA0KPiArICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBmbGFncywgdWludDMyX3QgY291bnQsDQo+ ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnN0IHVpbnQzMl90 ICpyZWZzLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50 MzJfdCAqZG1hYnVmX2ZkLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1aW50MzJfdCBkYXRhX29mcykNCj4gK3sNCj4gKyAgICBzdHJ1Y3QgaW9jdGxfZ250ZGV2 X2RtYWJ1Zl9leHBfZnJvbV9yZWZzX3YyICpmcm9tX3JlZnNfdjIgPSBOVUxMOw0KPiArICAgIGlu dCByYyA9IC0xOw0KPiArDQo+ICsgICAgaWYgKCAhY291bnQgKQ0KPiArICAgIHsNCj4gKyAgICAg ICAgZXJybm8gPSBFSU5WQUw7DQo+ICsgICAgICAgIGdvdG8gb3V0Ow0KPiArICAgIH0NCj4gKw0K PiArICAgIGZyb21fcmVmc192MiA9IG1hbGxvYyhzaXplb2YoKmZyb21fcmVmc192MikgKw0KPiAr ICAgICAgICAgICAgICAgICAgICAgICAgICAoY291bnQgLSAxKSAqIHNpemVvZihmcm9tX3JlZnNf djItPnJlZnNbMF0pKTsNCj4gKyAgICBpZiAoICFmcm9tX3JlZnNfdjIgKQ0KPiArICAgIHsNCj4g KyAgICAgICAgZXJybm8gPSBFTk9NRU07DQo+ICsgICAgICAgIGdvdG8gb3V0Ow0KPiArICAgIH0N Cj4gKw0KPiArICAgIGZyb21fcmVmc192Mi0+ZmxhZ3MgPSBmbGFnczsNCj4gKyAgICBmcm9tX3Jl ZnNfdjItPmNvdW50ID0gY291bnQ7DQo+ICsgICAgZnJvbV9yZWZzX3YyLT5kb21pZCA9IGRvbWlk Ow0KPiArICAgIGZyb21fcmVmc192Mi0+ZGF0YV9vZnMgPSBkYXRhX29mczsNCj4gKw0KPiArICAg IG1lbWNweShmcm9tX3JlZnNfdjItPnJlZnMsIHJlZnMsIGNvdW50ICogc2l6ZW9mKGZyb21fcmVm c192Mi0+cmVmc1swXSkpOw0KPiArDQo+ICsgICAgaWYgKCAocmMgPSBpb2N0bCh4Z3QtPmZkLCBJ T0NUTF9HTlRERVZfRE1BQlVGX0VYUF9GUk9NX1JFRlNfVjIsDQo+ICsgICAgICAgICAgICAgICAg ICAgICBmcm9tX3JlZnNfdjIpKSApDQo+ICsgICAgew0KPiArICAgICAgICBHVEVSUk9SKHhndC0+ bG9nZ2VyLCAiaW9jdGwgRE1BQlVGX0VYUF9GUk9NX1JFRlNfVjIgZmFpbGVkIik7DQo+ICsgICAg ICAgIGdvdG8gb3V0Ow0KPiArICAgIH0NCj4gKw0KPiArICAgICpkbWFidWZfZmQgPSBmcm9tX3Jl ZnNfdjItPmZkOw0KPiArICAgIHJjID0gMDsNCj4gKw0KPiArb3V0Og0KPiArICAgIGZyZWUoZnJv bV9yZWZzX3YyKTsNCj4gKyAgICByZXR1cm4gcmM7DQo+ICt9DQo+ICsNCj4gICBpbnQgb3NkZXBf Z250dGFiX2RtYWJ1Zl9leHBfd2FpdF9yZWxlYXNlZCh4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZmQs IHVpbnQzMl90IHdhaXRfdG9fbXMpDQo+ICAgew0KPiBAQCAtNDEzLDYgKzQ1OCw0NyBAQCBvdXQ6 DQo+ICAgICAgIHJldHVybiByYzsNCj4gICB9DQo+ICAgDQo+ICtpbnQgb3NkZXBfZ250dGFiX2Rt YWJ1Zl9pbXBfdG9fcmVmc192Mih4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsIHVpbnQzMl90IGRvbWlk LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZmQs IHVpbnQzMl90IGNvdW50LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdWludDMyX3QgKnJlZnMsDQo+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB1aW50MzJfdCAqZGF0YV9vZnMpDQo+ICt7DQo+ICsgICAgc3RydWN0IGlvY3RsX2dudGRl dl9kbWFidWZfaW1wX3RvX3JlZnNfdjIgKnRvX3JlZnNfdjIgPSBOVUxMOw0KPiArICAgIGludCBy YyA9IC0xOw0KPiArDQo+ICsgICAgaWYgKCAhY291bnQgKQ0KPiArICAgIHsNCj4gKyAgICAgICAg ZXJybm8gPSBFSU5WQUw7DQo+ICsgICAgICAgIGdvdG8gb3V0Ow0KPiArICAgIH0NCj4gKw0KPiAr ICAgIHRvX3JlZnNfdjIgPSBtYWxsb2Moc2l6ZW9mKCp0b19yZWZzX3YyKSArDQo+ICsgICAgICAg ICAgICAgICAgICAgICAgICAoY291bnQgLSAxKSAqIHNpemVvZih0b19yZWZzX3YyLT5yZWZzWzBd KSk7DQo+ICsgICAgaWYgKCAhdG9fcmVmc192MiApDQo+ICsgICAgew0KPiArICAgICAgICBlcnJu byA9IEVOT01FTTsNCj4gKyAgICAgICAgZ290byBvdXQ7DQo+ICsgICAgfQ0KPiArDQo+ICsgICAg dG9fcmVmc192Mi0+ZmQgPSBmZDsNCj4gKyAgICB0b19yZWZzX3YyLT5jb3VudCA9IGNvdW50Ow0K PiArICAgIHRvX3JlZnNfdjItPmRvbWlkID0gZG9taWQ7DQo+ICsNCj4gKyAgICBpZiAoIChyYyA9 IGlvY3RsKHhndC0+ZmQsIElPQ1RMX0dOVERFVl9ETUFCVUZfSU1QX1RPX1JFRlNfVjIsIHRvX3Jl ZnNfdjIpKSApDQo+ICsgICAgew0KPiArICAgICAgICBHVEVSUk9SKHhndC0+bG9nZ2VyLCAiaW9j dGwgRE1BQlVGX0lNUF9UT19SRUZTX1YyIGZhaWxlZCIpOw0KPiArICAgICAgICBnb3RvIG91dDsN Cj4gKyAgICB9DQo+ICsNCj4gKyAgICBtZW1jcHkocmVmcywgdG9fcmVmc192Mi0+cmVmcywgY291 bnQgKiBzaXplb2YoKnJlZnMpKTsNCj4gKyAgICAqZGF0YV9vZnMgPSB0b19yZWZzX3YyLT5kYXRh X29mczsNCj4gKyAgICByYyA9IDA7DQo+ICsNCj4gK291dDoNCj4gKyAgICBmcmVlKHRvX3JlZnNf djIpOw0KPiArICAgIHJldHVybiByYzsNCj4gK30NCj4gKw0KPiAgIGludCBvc2RlcF9nbnR0YWJf ZG1hYnVmX2ltcF9yZWxlYXNlKHhlbmdudHRhYl9oYW5kbGUgKnhndCwgdWludDMyX3QgZmQpDQo+ ICAgew0KPiAgICAgICBzdHJ1Y3QgaW9jdGxfZ250ZGV2X2RtYWJ1Zl9pbXBfcmVsZWFzZSByZWxl YXNlOw0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9nbnR0YWIvbWluaW9zLmMgYi90b29scy9s aWJzL2dudHRhYi9taW5pb3MuYw0KPiBpbmRleCBmNzhjYWFkZDMwNDMuLjI5ODQxNmIyYTk4ZCAx MDA2NDQNCj4gLS0tIGEvdG9vbHMvbGlicy9nbnR0YWIvbWluaW9zLmMNCj4gKysrIGIvdG9vbHMv bGlicy9nbnR0YWIvbWluaW9zLmMNCj4gQEAgLTEyMCw2ICsxMjAsMTQgQEAgaW50IG9zZGVwX2du dHRhYl9kbWFidWZfZXhwX2Zyb21fcmVmcyh4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsIHVpbnQzMl90 IGRvbWlkLA0KPiAgICAgICByZXR1cm4gLTE7DQo+ICAgfQ0KPiAgIA0KPiAraW50IG9zZGVwX2du dHRhYl9kbWFidWZfZXhwX2Zyb21fcmVmc192Mih4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsIHVpbnQz Ml90IGRvbWlkLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1 aW50MzJfdCBmbGFncywgdWludDMyX3QgY291bnQsDQo+ICsgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGNvbnN0IHVpbnQzMl90ICpyZWZzLCB1aW50MzJfdCAqZmQsDQo+ ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGRhdGFf b2ZzKQ0KPiArew0KPiArICAgIHJldHVybiAtMTsNCj4gK30NCj4gKw0KPiAgIGludCBvc2RlcF9n bnR0YWJfZG1hYnVmX2V4cF93YWl0X3JlbGVhc2VkKHhlbmdudHRhYl9oYW5kbGUgKnhndCwNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzJfdCBmZCwg dWludDMyX3Qgd2FpdF90b19tcykNCj4gICB7DQo+IEBAIC0xMzMsNiArMTQxLDEzIEBAIGludCBv c2RlcF9nbnR0YWJfZG1hYnVmX2ltcF90b19yZWZzKHhlbmdudHRhYl9oYW5kbGUgKnhndCwgdWlu dDMyX3QgZG9taWQsDQo+ICAgICAgIHJldHVybiAtMTsNCj4gICB9DQo+ICAgDQo+ICtpbnQgb3Nk ZXBfZ250dGFiX2RtYWJ1Zl9pbXBfdG9fcmVmc192Mih4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsIHVp bnQzMl90IGRvbWlkLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dWludDMyX3QgZmQsIHVpbnQzMl90IGNvdW50LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdWludDMyX3QgKnJlZnMsIHVpbnQzMl90ICpkYXRhX29mcykNCj4gK3sN Cj4gKyAgICByZXR1cm4gLTE7DQo+ICt9DQo+ICsNCj4gICBpbnQgb3NkZXBfZ250dGFiX2RtYWJ1 Zl9pbXBfcmVsZWFzZSh4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsIHVpbnQzMl90IGZkKQ0KPiAgIHsN Cj4gICAgICAgcmV0dXJuIC0xOw0KPiBkaWZmIC0tZ2l0IGEvdG9vbHMvbGlicy9nbnR0YWIvcHJp dmF0ZS5oIGIvdG9vbHMvbGlicy9nbnR0YWIvcHJpdmF0ZS5oDQo+IGluZGV4IGM1ZTIzNjM5YjE0 MS4uMDcyNzE2MzdmNjA5IDEwMDY0NA0KPiAtLS0gYS90b29scy9saWJzL2dudHRhYi9wcml2YXRl LmgNCj4gKysrIGIvdG9vbHMvbGlicy9nbnR0YWIvcHJpdmF0ZS5oDQo+IEBAIC0zOSw2ICszOSwx MSBAQCBpbnQgb3NkZXBfZ250dGFiX2RtYWJ1Zl9leHBfZnJvbV9yZWZzKHhlbmdudHRhYl9oYW5k bGUgKnhndCwgdWludDMyX3QgZG9taWQsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB1aW50MzJfdCBmbGFncywgdWludDMyX3QgY291bnQsDQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB1aW50MzJfdCAqcmVmcywgdWludDMy X3QgKmZkKTsNCj4gICANCj4gK2ludCBvc2RlcF9nbnR0YWJfZG1hYnVmX2V4cF9mcm9tX3JlZnNf djIoeGVuZ250dGFiX2hhbmRsZSAqeGd0LCB1aW50MzJfdCBkb21pZCwNCj4gKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZmxhZ3MsIHVpbnQzMl90IGNv dW50LA0KPiArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zdCB1 aW50MzJfdCAqcmVmcywgdWludDMyX3QgKmZkLA0KPiArICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB1aW50MzJfdCBkYXRhX29mcyk7DQo+ICsNCj4gICBpbnQgb3NkZXBf Z250dGFiX2RtYWJ1Zl9leHBfd2FpdF9yZWxlYXNlZCh4ZW5nbnR0YWJfaGFuZGxlICp4Z3QsDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyX3QgZmQs IHVpbnQzMl90IHdhaXRfdG9fbXMpOw0KPiAgIA0KPiBAQCAtNDYsNiArNTEsMTAgQEAgaW50IG9z ZGVwX2dudHRhYl9kbWFidWZfaW1wX3RvX3JlZnMoeGVuZ250dGFiX2hhbmRsZSAqeGd0LCB1aW50 MzJfdCBkb21pZCwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1aW50 MzJfdCBmZCwgdWludDMyX3QgY291bnQsDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgdWludDMyX3QgKnJlZnMpOw0KPiAgIA0KPiAraW50IG9zZGVwX2dudHRhYl9kbWFi dWZfaW1wX3RvX3JlZnNfdjIoeGVuZ250dGFiX2hhbmRsZSAqeGd0LCB1aW50MzJfdCBkb21pZCwN Cj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMl90IGZkLCB1 aW50MzJfdCBjb3VudCwNCj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHVpbnQzMl90ICpyZWZzLCB1aW50MzJfdCAqZGF0YV9vZnMpOw0KPiArDQo+ICAgaW50IG9zZGVw X2dudHRhYl9kbWFidWZfaW1wX3JlbGVhc2UoeGVuZ250dGFiX2hhbmRsZSAqeGd0LCB1aW50MzJf dCBmZCk7DQo+ICAgDQo+ICAgaW50IG9zZGVwX2dudHNocl9vcGVuKHhlbmdudHNocl9oYW5kbGUg Knhncyk7 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 09:52:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 09:52:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqCwb-0002OD-9e; Tue, 30 Jun 2020 09:52:49 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqCwZ-0002O8-ME for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 09:52:47 +0000 X-Inumbo-ID: 733fdabe-bab7-11ea-bb8b-bc764e2007e4 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 733fdabe-bab7-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 09:52:46 +0000 (UTC) Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: gVZvxBZMlRM36DI2IQ85ziOnmOn8wXZFjJk5PxZidKig1Ws2jsO4QkTEQsmloz1KwMZQfvV5m5 kYMW7FReUe/cku5IJpYhTGVONoeEjhHnZwsR7/j/K3i6JpQz2R2AiDstG+xLVBMX0opxbO7cdj WVo8rsWryf60yYOMp8fuB1BdZ/+rTZ/+3vwLVUA4sHJQ3YP+B3i6B4w9/OcYCHtCxJfmuL0whS D/ksR8l0vYJv/wvDw8nkGyPdgCmVtj7cusXhPGqt1l7K3SNfSzrWJEjHkyC3GTt1XbSjCdzNlC f6o= X-SBRS: 2.7 X-MesageID: 21567700 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,297,1589256000"; d="scan'208";a="21567700" Date: Tue, 30 Jun 2020 11:52:39 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH] x86: fix compat header generation Message-ID: <20200630095239.GK735@Air-de-Roger> References: <0e617191-d61f-08e2-eaa9-b324cd6501f0@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline In-Reply-To: <0e617191-d61f-08e2-eaa9-b324cd6501f0@suse.com> X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , George Dunlap , Andrew Cooper , Ian Jackson , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" I'm not familiar with compat header generation, sorry if the comments below are obvious or plain wrong. On Mon, Jun 29, 2020 at 05:50:59PM +0200, Jan Beulich wrote: > As was pointed out by "mm: fix public declaration of struct > xen_mem_acquire_resource", we're not currently handling structs > correctly that has uint64_aligned_t fields. #pragma pack(4) suppresses > the necessary alignment even if the type did properly survive (which > it also didn't) in the process of generating the headers. Overall, > with the above mentioned change applied, there's only a latent issue > here afaict, i.e. no other of our interface structs is currently > affected. > > As a result it is clear that using #pragma pack(4) is not an option. > Drop all uses from compat header generation. Make sure > {,u}int64_aligned_t actually survives, such that explicitly aligned > fields will remain aligned. Arrange for {,u}int64_t to be transformed > into a type that's 64 bits wide and 4-byte aligned, by utilizing that > in typedef-s the "aligned" attribute can be used to reduce alignment. > > Note that this changes alignment (but not size) of certain compat > structures, when one or more of their fields use a non-translated struct > as their type(s). This isn't correct, and hence applying alignof() to > such fields requires care, but the prior situation was even worse. Just to clarify my understanding, this means that struct fields that are also structs will need special alignment? (because we no longer have the 4byte packaging). I see from the generated headers that uint64_compat_t is already aligned to 4 bytes, and I assume something similar will be needed for all 8byte types? > There's one change to generated code according to my observations: In > arch_compat_vcpu_op() the runstate area "area" variable would previously > have been put in a just 4-byte aligned stack slot (despite being 8 bytes > in size), whereas now it gets put in an 8-byte aligned location. Is there someway that we could spot such changes, maybe building a version of the plain structures with -m32 and comparing against their compat versions? I know we have some compat checking infrastructure, so I wonder if we could use it to avoid issues like the one we had with xen_mem_acquire_resource, as it seems like something that could be programmatically detected. > Signed-off-by: Jan Beulich > > --- a/xen/include/Makefile > +++ b/xen/include/Makefile > @@ -34,15 +34,6 @@ headers-$(CONFIG_XSM_FLASK) += compat/xs > cppflags-y := -include public/xen-compat.h -DXEN_GENERATING_COMPAT_HEADERS > cppflags-$(CONFIG_X86) += -m32 > > -# 8-byte types are 4-byte aligned on x86_32 ... > -ifeq ($(CONFIG_CC_IS_CLANG),y) > -prefix-$(CONFIG_X86) := \#pragma pack(push, 4) > -suffix-$(CONFIG_X86) := \#pragma pack(pop) > -else > -prefix-$(CONFIG_X86) := \#pragma pack(4) > -suffix-$(CONFIG_X86) := \#pragma pack() > -endif > - > endif > > public-$(CONFIG_X86) := $(wildcard public/arch-x86/*.h public/arch-x86/*/*.h) > @@ -57,16 +48,16 @@ compat/%.h: compat/%.i Makefile $(BASEDI > echo "#define $$id" >>$@.new; \ > echo "#include " >>$@.new; \ > $(if $(filter-out compat/arch-%.h,$@),echo "#include <$(patsubst compat/%,public/%,$@)>" >>$@.new;) \ > - $(if $(prefix-y),echo "$(prefix-y)" >>$@.new;) \ > grep -v '^# [0-9]' $< | \ > $(PYTHON) $(BASEDIR)/tools/compat-build-header.py | uniq >>$@.new; \ > - $(if $(suffix-y),echo "$(suffix-y)" >>$@.new;) \ > echo "#endif /* $$id */" >>$@.new > mv -f $@.new $@ > > +.PRECIOUS: compat/%.i > compat/%.i: compat/%.c Makefile > $(CPP) $(filter-out -Wa$(comma)% -include %/include/xen/config.h,$(XEN_CFLAGS)) $(cppflags-y) -o $@ $< > > +.PRECIOUS: compat/%.c Not sure if it's worth mentioning that the .i and .c files are now kept. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 30 10:21:45 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 10:21:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqDOR-0005CR-Lj; Tue, 30 Jun 2020 10:21:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqDOP-0005CM-95 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 10:21:34 +0000 X-Inumbo-ID: 77bc6fea-babb-11ea-85ef-12813bfff9fa Received: from mo4-p00-ob.smtp.rzone.de (unknown [81.169.146.163]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 77bc6fea-babb-11ea-85ef-12813bfff9fa; Tue, 30 Jun 2020 10:21:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1593512491; s=strato-dkim-0002; d=aepfle.de; h=Message-Id:Date:Subject:Cc:To:From:X-RZG-CLASS-ID:X-RZG-AUTH:From: Subject:Sender; bh=CjGBpohQCR2QX4LL+omL6oSa12vdHDQzy8BpzpjGH4M=; b=QtUu50fr9+M5jpROsEmkoUabUXEy0xiLYCTCk9+qmK7LNGLmRAXk1GJZUFI2yFBUlx wQt1TXelbcLSja7X+SoCuHFwFO/3w0Yy65BsfIXE0YmGtM8UB6UQXb4ZbufX08BfYfuI L1Vlgj2V5nCULUPJsKbJ05u2BxxgyavhMKIOMSKojv7uW22zReb5EzH8R7Zd9ZMr7/h4 kUohWVHEwGEg+rUhw3ZrghROhWmzpQHRboQwaRLduvqejhp/DWY/+Y5H9YieWbvwcuVf iQZc1xqPA0hYWfABlVV/JZnR35COykJ/U3bo5X/SyxxYSKeZZVSTtgbPaWII4B+qwHtL AsOw== X-RZG-AUTH: ":P2EQZWCpfu+qG7CngxMFH1J+3q8wa/QXkBR9MXjAuznLRsvz6zGrN/JP267TqQ==" X-RZG-CLASS-ID: mo00 Received: from sender by smtp.strato.de (RZmta 46.10.5 AUTH) with ESMTPSA id m032cfw5UALNLRc (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) (Client did not present a certificate); Tue, 30 Jun 2020 12:21:23 +0200 (CEST) From: Olaf Hering To: xen-devel@lists.xenproject.org Subject: [PATCH v1] kconfig: fix typo in XEN_SHSTK description Date: Tue, 30 Jun 2020 12:21:19 +0200 Message-Id: <20200630102119.16870-1-olaf@aepfle.de> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Andrew Cooper , Olaf Hering , Wei Liu , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Rename 'vai' to 'via'. Signed-off-by: Olaf Hering --- xen/arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 4a2ec87ff5..a636a4bb1e 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -113,7 +113,7 @@ config XEN_SHSTK This option arranges for Xen to use CET-SS for its own protection. When CET-SS is active, 32bit PV guests cannot be used. Backwards - compatiblity can be provided vai the PV Shim mechanism. + compatiblity can be provided via the PV Shim mechanism. config SHADOW_PAGING bool "Shadow Paging" From xen-devel-bounces@lists.xenproject.org Tue Jun 30 10:28:32 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 10:28:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqDV5-0005Oh-Dg; Tue, 30 Jun 2020 10:28:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqDV3-0005Ob-P5 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 10:28:25 +0000 X-Inumbo-ID: 6db279da-babc-11ea-bb8b-bc764e2007e4 Received: from mail-wr1-x42c.google.com (unknown [2a00:1450:4864:20::42c]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6db279da-babc-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 10:28:25 +0000 (UTC) Received: by mail-wr1-x42c.google.com with SMTP id g18so19602986wrm.2 for ; Tue, 30 Jun 2020 03:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=13o5nDkHqBf+jwyO4Tv9Vn/lkiEHiRzatByRaiR9K2o=; b=RJ7nWdZdT0shRGKcjVOLXMSzGtbBUl/gsR3PXa0jztjog+4+H6X/XH8H6FrlIZWCW3 HbRouufLNIdOxxG1xTZ7synFl410supWK0tLIgjrubrUluN1FZzPQE820hvmk/iuZhgP miul/BRl6deezi3HWWRZrJT50xSs3gDQxSRtsgb9jXGLz6GIRp6PvJTakAaX5GSA2cnG bOay+ZuwOS5Nptftj19f0r1vxs/d6l1atoGJ+agyVJ+OVsgC7xreuKyz21BZQHsgA9yo weaxEVCTth38+MP0QJ0QvbTlOgV1WykKKHE+26RKBU/ZdP+mC36Hj2RlVlZLH9VJNEAZ NyQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :thread-index:content-language; bh=13o5nDkHqBf+jwyO4Tv9Vn/lkiEHiRzatByRaiR9K2o=; b=lkgBjFxFAxQ8wsd/pxalSsgEQkA6DJNAffNRAcGE721BsdXOTkBbOuDCU4JT1f2hli ruongn68xU/XqjJ/rB6aFXrvbusuvCxmbLCNtbeqNFs0P7wm9TlFX57GN7l2wQmHakP4 rxHsAxPUji4xFqR03yog6crz4iT3E6dKnc3/GOWUNQmkZhBgyVAB22HQnBI/D8ztMNsR bBWoeuYhVUrFgAA/jDUR/5yVqr5k6fLF93YOpGYfGAjB8svEhUv4Hg2zcbhJBxJz7OO4 uhsozRJQU3aQRvq3P0GQq2rS2S5KU2yjCeKm4lSMyNAqvnA2UAB7dc4Ny19H79d+RNcm hcsA== X-Gm-Message-State: AOAM5331iBb33tUyQPh/hs1cfmGGZx9JQhBRJCz0LVk6gSaQ73OywJqG wLMfaBWmMXTs+CWW1AeEHuw= X-Google-Smtp-Source: ABdhPJy5Yd+pxDaOdBLlteKDvUPlUYU+qKcBCuNP9ML7SaYv20YFND2WFdc9lLPqurLXaD3/7/poIg== X-Received: by 2002:adf:e944:: with SMTP id m4mr21578689wrn.252.1593512904154; Tue, 30 Jun 2020 03:28:24 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-230.amazon.com. [54.240.197.230]) by smtp.gmail.com with ESMTPSA id e23sm2854276wme.35.2020.06.30.03.28.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 03:28:23 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Olaf Hering'" , References: <20200630102119.16870-1-olaf@aepfle.de> In-Reply-To: <20200630102119.16870-1-olaf@aepfle.de> Subject: RE: [PATCH v1] kconfig: fix typo in XEN_SHSTK description Date: Tue, 30 Jun 2020 11:28:22 +0100 Message-ID: <000101d64ec9$2eb0cca0$8c1265e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKLPLlB1TIkcMYbmItBc8SAdVu6nKeHGHhQ Content-Language: en-gb X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Andrew Cooper' , 'Jan Beulich' , 'Wei Liu' , =?utf-8?Q?'Roger_Pau_Monn=C3=A9'?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Xen-devel On Behalf Of = Olaf Hering > Sent: 30 June 2020 11:21 > To: xen-devel@lists.xenproject.org > Cc: Andrew Cooper ; Olaf Hering = ; Wei Liu ; Jan > Beulich ; Roger Pau Monn=C3=A9 = > Subject: [PATCH v1] kconfig: fix typo in XEN_SHSTK description >=20 > Rename 'vai' to 'via'. >=20 > Signed-off-by: Olaf Hering > --- > xen/arch/x86/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig > index 4a2ec87ff5..a636a4bb1e 100644 > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -113,7 +113,7 @@ config XEN_SHSTK >=20 > This option arranges for Xen to use CET-SS for its own protection. > When CET-SS is active, 32bit PV guests cannot be used. Backwards > - compatiblity can be provided vai the PV Shim mechanism. > + compatiblity can be provided via the PV Shim mechanism. >=20 > config SHADOW_PAGING > bool "Shadow Paging" Since it's trivial and cosmetic only this can go in 4.14, so... Reviewed-by: Paul Durrant Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Tue Jun 30 10:53:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 10:53:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqDsc-0007rn-So; Tue, 30 Jun 2020 10:52:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqDsc-0007rf-3y for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 10:52:46 +0000 X-Inumbo-ID: d1fcdaea-babf-11ea-bca7-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d1fcdaea-babf-11ea-bca7-bc764e2007e4; Tue, 30 Jun 2020 10:52:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D9ACDACE1; Tue, 30 Jun 2020 10:52:40 +0000 (UTC) Subject: Re: [PATCH] x86: fix compat header generation To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <0e617191-d61f-08e2-eaa9-b324cd6501f0@suse.com> <20200630095239.GK735@Air-de-Roger> From: Jan Beulich Message-ID: <7d991541-84df-b18c-acde-449d3edae384@suse.com> Date: Tue, 30 Jun 2020 12:52:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200630095239.GK735@Air-de-Roger> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Paul Durrant , George Dunlap , Andrew Cooper , Ian Jackson , "xen-devel@lists.xenproject.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 30.06.2020 11:52, Roger Pau Monné wrote: > On Mon, Jun 29, 2020 at 05:50:59PM +0200, Jan Beulich wrote: >> As was pointed out by "mm: fix public declaration of struct >> xen_mem_acquire_resource", we're not currently handling structs >> correctly that has uint64_aligned_t fields. #pragma pack(4) suppresses >> the necessary alignment even if the type did properly survive (which >> it also didn't) in the process of generating the headers. Overall, >> with the above mentioned change applied, there's only a latent issue >> here afaict, i.e. no other of our interface structs is currently >> affected. >> >> As a result it is clear that using #pragma pack(4) is not an option. >> Drop all uses from compat header generation. Make sure >> {,u}int64_aligned_t actually survives, such that explicitly aligned >> fields will remain aligned. Arrange for {,u}int64_t to be transformed >> into a type that's 64 bits wide and 4-byte aligned, by utilizing that >> in typedef-s the "aligned" attribute can be used to reduce alignment. >> >> Note that this changes alignment (but not size) of certain compat >> structures, when one or more of their fields use a non-translated struct >> as their type(s). This isn't correct, and hence applying alignof() to >> such fields requires care, but the prior situation was even worse. > > Just to clarify my understanding, this means that struct fields that > are also structs will need special alignment? (because we no longer have > the 4byte packaging). They may need in principle, but right now there's no instance of such as per my comparing of the generated binaries. > I see from the generated headers that uint64_compat_t is already > aligned to 4 bytes, and I assume something similar will be needed for > all 8byte types? If there are native types that get re-used (rather than re-created as compat version in the compat headers, which would then necessarily derive from {u,}int64_t directly or indirectly, as there's no other non-derived 8-byte type that's legitimate to use in public headers - e.g. "unsigned long long" is not legitimate to be used, and all "unsigned long" instances [if there are any left] get converted to "unsigned int"), yes. >> There's one change to generated code according to my observations: In >> arch_compat_vcpu_op() the runstate area "area" variable would previously >> have been put in a just 4-byte aligned stack slot (despite being 8 bytes >> in size), whereas now it gets put in an 8-byte aligned location. > > Is there someway that we could spot such changes, maybe building a > version of the plain structures with -m32 and comparing against their > compat versions? Depends on what "comparing" here means. Yes, something could presumably be invented. But it may also be that we'd be better of doing away with the re-use of native structs. But of course doing so will have significant fallout, which right now I have no good idea how to deal with. > I know we have some compat checking infrastructure, so I wonder if we > could use it to avoid issues like the one we had with > xen_mem_acquire_resource, as it seems like something that could be > programmatically detected. Yes, having this properly checked would definitely be nice. It's just the "how" that's unclear to me here. >> @@ -57,16 +48,16 @@ compat/%.h: compat/%.i Makefile $(BASEDI >> echo "#define $$id" >>$@.new; \ >> echo "#include " >>$@.new; \ >> $(if $(filter-out compat/arch-%.h,$@),echo "#include <$(patsubst compat/%,public/%,$@)>" >>$@.new;) \ >> - $(if $(prefix-y),echo "$(prefix-y)" >>$@.new;) \ >> grep -v '^# [0-9]' $< | \ >> $(PYTHON) $(BASEDIR)/tools/compat-build-header.py | uniq >>$@.new; \ >> - $(if $(suffix-y),echo "$(suffix-y)" >>$@.new;) \ >> echo "#endif /* $$id */" >>$@.new >> mv -f $@.new $@ >> >> +.PRECIOUS: compat/%.i >> compat/%.i: compat/%.c Makefile >> $(CPP) $(filter-out -Wa$(comma)% -include %/include/xen/config.h,$(XEN_CFLAGS)) $(cppflags-y) -o $@ $< >> >> +.PRECIOUS: compat/%.c > > Not sure if it's worth mentioning that the .i and .c files are now > kept. Ouch - these weren't supposed to be left in. They were just for my debugging. Thanks for noticing. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:13:57 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:13:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqF8t-00064Y-Jw; Tue, 30 Jun 2020 12:13:39 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqF8s-00064T-Fu for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:13:38 +0000 X-Inumbo-ID: 1fb85d58-bacb-11ea-860b-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1fb85d58-bacb-11ea-860b-12813bfff9fa; Tue, 30 Jun 2020 12:13:36 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B6427AE70; Tue, 30 Jun 2020 12:13:35 +0000 (UTC) Subject: Re: [PATCH for-4.14 v4] x86/tlb: fix assisted flush usage To: Roger Pau Monne References: <20200626155723.91558-1-roger.pau@citrix.com> From: Jan Beulich Message-ID: Date: Tue, 30 Jun 2020 14:13:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626155723.91558-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 26.06.2020 17:57, Roger Pau Monne wrote: > Commit e9aca9470ed86 introduced a regression when avoiding sending > IPIs for certain flush operations. Xen page fault handler > (spurious_page_fault) relies on blocking interrupts in order to > prevent handling TLB flush IPIs and thus preventing other CPUs from > removing page tables pages. Switching to assisted flushing avoided such > IPIs, and thus can result in pages belonging to the page tables being > removed (and possibly re-used) while __page_fault_type is being > executed. > > Force some of the TLB flushes to use IPIs, thus avoiding the assisted > TLB flush. Those selected flushes are the page type change (when > switching from a page table type to a different one, ie: a page that > has been removed as a page table) and page allocation. This sadly has > a negative performance impact on the pvshim, as less assisted flushes > can be used. Note the flush in grant-table code is also switched to > use an IPI even when not strictly needed. This is done so that a > common arch_flush_tlb_mask can be introduced and always used in common > code. > > Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush > using an IPI (flush_tlb_mask_sync, x86 only). Note that the flag is > only meaningfully defined when the hypervisor supports PV or shadow > paging mode, as otherwise hardware assisted paging domains are in > charge of their page tables and won't share page tables with Xen, thus > not influencing the result of page walks performed by the spurious > fault handler. > > Just passing this new flag when calling flush_area_mask prevents the > usage of the assisted flush without any other side effects. > > Note the flag is not defined on Arm. > > Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') > Reported-by: Andrew Cooper > Signed-off-by: Roger Pau Monné In principle Reviewed-by: Jan Beulich A few cosmetic remarks though: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -2894,7 +2894,17 @@ static int _get_page_type(struct page_info *page, unsigned long type, > ((nx & PGT_type_mask) == PGT_writable_page)) ) > { > perfc_incr(need_flush_tlb_flush); > - flush_tlb_mask(mask); > + if ( (x & PGT_type_mask) && > + (x & PGT_type_mask) <= PGT_root_page_table ) > + /* > + * If page was a page table make sure the flush is > + * performed using an IPI in order to avoid changing > + * the type of a page table page under the feet of > + * spurious_page_fault. > + */ > + flush_tlb_mask_sync(mask); > + else > + flush_tlb_mask(mask); Effectively this now is the only user of the new macro. I'd prefer avoiding its introduction (and hence avoiding the questionable "_sync" suffix), doing flush_mask(mask, FLUSH_TLB | (... ? FLUSH_FORCE_IPI : 0)); here and ... > @@ -148,9 +158,24 @@ void flush_area_mask(const cpumask_t *, const void *va, unsigned int flags); > /* Flush specified CPUs' TLBs */ > #define flush_tlb_mask(mask) \ > flush_mask(mask, FLUSH_TLB) > +/* > + * Flush specified CPUs' TLBs and force the usage of an IPI to do so. This is > + * required for certain operations that rely on page tables themselves not > + * being freed and reused when interrupts are blocked, as the flush IPI won't > + * be fulfilled until exiting from that critical region. > + */ > +#define flush_tlb_mask_sync(mask) \ > + flush_mask(mask, FLUSH_TLB | FLUSH_FORCE_IPI) > #define flush_tlb_one_mask(mask,v) \ > flush_area_mask(mask, (const void *)(v), FLUSH_TLB|FLUSH_ORDER(0)) > > +/* > + * Alias the common code TLB flush helper to the sync one in order to be on the > + * safe side. Note that not all calls from common code strictly require the > + * _sync variant. > + */ > +#define arch_flush_tlb_mask flush_tlb_mask_sync ... #define arch_flush_tlb_mask(mask) \ flush_mask(mask, FLUSH_TLB | FLUSH_FORCE_IPI) here. I'd be okay making these adjustments while committing, if you and others don't object. Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:17:10 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:17:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFCI-0006Ca-3b; Tue, 30 Jun 2020 12:17:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFCH-0006CD-2f for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:17:09 +0000 X-Inumbo-ID: 9b07e71c-bacb-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9b07e71c-bacb-11ea-b7bb-bc764e2007e4; Tue, 30 Jun 2020 12:17:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Wh+ERGwaSgQoVC0gBmNoPrJ178ku6oXLzQRRd1vAyLU=; b=38hsA4jtGAmB0a/AW6RGAuWWY 4/JEOAbgDZ1GOOwznhYWAUFOWo0IG94GzD1wyUTDZzDEeoiH+Rv98lsjRrd6pPIBsJoC87EDbB9eH WlrTJGOTEoTccAyuLJT2riFTQpnE66i90IQov030z23bva8ASgTl/vBy8EWr4ESQOSVPg=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFCA-0007zP-LQ; Tue, 30 Jun 2020 12:17:02 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jqFCA-0003aP-CP; Tue, 30 Jun 2020 12:17:02 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jqFCA-0002ux-Bm; Tue, 30 Jun 2020 12:17:02 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 151469: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=4268e187531eb370bc6fbac4496018bb7fef6716 X-Osstest-Versions-That: libvirt=d482cf6bef484e697f1dbb99f2504e7d67b149e7 From: osstest service owner Date: Tue, 30 Jun 2020 12:17:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151469 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/151469/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151417 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151417 test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 12 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 13 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-libvirt 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt 4268e187531eb370bc6fbac4496018bb7fef6716 baseline version: libvirt d482cf6bef484e697f1dbb99f2504e7d67b149e7 Last test of basis 151417 2020-06-28 04:19:04 Z 2 days Testing same since 151469 2020-06-30 04:19:06 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Akarshan Biswas Andrea Bolognani Daniel P. Berrange Daniel P. Berrangé Fedora Weblate Translation Julien Humbert Michal Privoznik Weblate jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/libvirt.git d482cf6bef..4268e18753 4268e187531eb370bc6fbac4496018bb7fef6716 -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:12 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFTb-0007q0-LE; Tue, 30 Jun 2020 12:35:03 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFTa-0007pv-Lk for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:02 +0000 X-Inumbo-ID: 1c286414-bace-11ea-860f-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1c286414-bace-11ea-860f-12813bfff9fa; Tue, 30 Jun 2020 12:34:59 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 0B87CA37E4; Tue, 30 Jun 2020 14:34:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id EAA8DA37E2; Tue, 30 Jun 2020 14:34:56 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id gvwubWuY7bvm; Tue, 30 Jun 2020 14:34:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3AD71A37E4; Tue, 30 Jun 2020 14:34:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tFbQ69aFBKZj; Tue, 30 Jun 2020 14:34:56 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 0525AA37E2; Tue, 30 Jun 2020 14:34:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id E48842255E; Tue, 30 Jun 2020 14:34:25 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ltQoc2YjWCCQ; Tue, 30 Jun 2020 14:34:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 5388A2252B; Tue, 30 Jun 2020 14:34:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nzLQXCLE_Qn8; Tue, 30 Jun 2020 14:34:20 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 176942200C; Tue, 30 Jun 2020 14:34:20 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 00/10] Implement support for external IPT monitoring Date: Tue, 30 Jun 2020 14:33:43 +0200 Message-Id: X-Mailer: git-send-email 2.17.1 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Kevin Tian , Stefano Stabellini , tamas.lengyel@intel.com, Jun Nakajima , Wei Liu , Andrew Cooper , Michal Leszczynski , Ian Jackson , George Dunlap , Jan Beulich , Anthony PERARD , luwei.kang@intel.com, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Intel Processor Trace is an architectural extension available in modern Intel family CPUs. It allows recording the detailed trace of activity while the processor executes the code. One might use the recorded trace to reconstruct the code flow. It means, to find out the executed code paths, determine branches taken, and so forth. The abovementioned feature is described in Intel(R) 64 and IA-32 Architectures Software Developer's Manual Volume 3C: System Programming Guide, Part 3, Chapter 36: "Intel Processor Trace." This patch series implements an interface that Dom0 could use in order to enable IPT for particular vCPUs in DomU, allowing for external monitoring. Such a feature has numerous applications like malware monitoring, fuzzing, or performance testing. Also thanks to Tamas K Lengyel for a few preliminary hints before first version of this patch was submitted to xen-devel. Changed since v1: * MSR_RTIT_CTL is managed using MSR load lists * other PT-related MSRs are modified only when vCPU goes out of context * trace buffer is now acquired as a resource * added vmtrace_pt_size parameter in xl.cfg, the size of trace buffer must be specified in the moment of domain creation * trace buffers are allocated on domain creation, destructed on domain destruction * HVMOP_vmtrace_ipt_enable/disable is limited to enabling/disabling PT these calls don't manage buffer memory anymore * lifted 32 MFN/GFN array limit when acquiring resources * minor code style changes according to review Changed since v2: * trace buffer is now allocated on domain creation (in v2 it was allocated when hvm param was set) * restored 32-item limit in mfn/gfn arrays in acquire_resource and instead implemented hypercall continuations * code changes according to Jan's and Roger's review Changed since v3: * vmtrace HVMOPs are not implemented as DOMCTLs * patches splitted up according to Andrew's comments * code changes according to v3 review on the mailing list Michal Leszczynski (10): x86/vmx: add Intel PT MSR definitions x86/vmx: add IPT cpu feature tools/libxl: add vmtrace_pt_size parameter x86/vmx: implement processor tracing for VMX common/domain: allocate vmtrace_pt_buffer memory: batch processing in acquire_resource() x86/mm: add vmtrace_buf resource type x86/domctl: add XEN_DOMCTL_vmtrace_op tools/libxc: add xc_vmtrace_* functions tools/proctrace: add proctrace tool docs/man/xl.cfg.5.pod.in | 10 + tools/golang/xenlight/helpers.gen.go | 2 + tools/golang/xenlight/types.gen.go | 1 + tools/libxc/Makefile | 1 + tools/libxc/include/xenctrl.h | 39 +++ tools/libxc/xc_vmtrace.c | 73 +++++ tools/libxl/libxl.h | 8 + tools/libxl/libxl_create.c | 1 + tools/libxl/libxl_types.idl | 2 + tools/proctrace/COPYING | 339 ++++++++++++++++++++ tools/proctrace/Makefile | 48 +++ tools/proctrace/proctrace.c | 163 ++++++++++ tools/xl/xl_parse.c | 20 ++ xen/arch/x86/domain.c | 11 + xen/arch/x86/domctl.c | 48 +++ xen/arch/x86/hvm/vmx/vmcs.c | 7 +- xen/arch/x86/hvm/vmx/vmx.c | 89 +++++ xen/arch/x86/mm.c | 25 ++ xen/common/domain.c | 46 +++ xen/common/memory.c | 32 +- xen/include/asm-x86/cpufeature.h | 1 + xen/include/asm-x86/domain.h | 4 + xen/include/asm-x86/hvm/hvm.h | 38 +++ xen/include/asm-x86/hvm/vmx/vmcs.h | 4 + xen/include/asm-x86/hvm/vmx/vmx.h | 14 + xen/include/asm-x86/msr-index.h | 37 +++ xen/include/public/arch-x86/cpufeatureset.h | 1 + xen/include/public/domctl.h | 27 ++ xen/include/public/memory.h | 1 + xen/include/xen/domain.h | 2 + xen/include/xen/sched.h | 4 + 31 files changed, 1094 insertions(+), 4 deletions(-) create mode 100644 tools/libxc/xc_vmtrace.c create mode 100644 tools/proctrace/COPYING create mode 100644 tools/proctrace/Makefile create mode 100644 tools/proctrace/proctrace.c -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFTn-0007qf-TB; Tue, 30 Jun 2020 12:35:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFTm-0007qV-M6 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:14 +0000 X-Inumbo-ID: 24b551fa-bace-11ea-bb8b-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 24b551fa-bace-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 12:35:13 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id B3983A37EC; Tue, 30 Jun 2020 14:35:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A61BEA37EA; Tue, 30 Jun 2020 14:35:11 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1_3k26MCDEPO; Tue, 30 Jun 2020 14:35:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2BD43A37E8; Tue, 30 Jun 2020 14:35:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8H_NizuV-mB5; Tue, 30 Jun 2020 14:35:11 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id EF7E4A37E6; Tue, 30 Jun 2020 14:35:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id E02E82262F; Tue, 30 Jun 2020 14:34:40 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id GU5N094yJdgX; Tue, 30 Jun 2020 14:34:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 65ED522617; Tue, 30 Jun 2020 14:34:35 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J5WRtkotLrCM; Tue, 30 Jun 2020 14:34:35 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 3BEEC22613; Tue, 30 Jun 2020 14:34:35 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 01/10] x86/vmx: add Intel PT MSR definitions Date: Tue, 30 Jun 2020 14:33:44 +0200 Message-Id: <2ff9ecee8367e814a29b17a34203bda0e3c48d74.1593519420.git.michal.leszczynski@cert.pl> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: tamas.lengyel@intel.com, Wei Liu , Andrew Cooper , Michal Leszczynski , Jan Beulich , luwei.kang@intel.com, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Define constants related to Intel Processor Trace features. Signed-off-by: Michal Leszczynski --- xen/include/asm-x86/msr-index.h | 37 +++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h index b328a47ed8..0203029be9 100644 --- a/xen/include/asm-x86/msr-index.h +++ b/xen/include/asm-x86/msr-index.h @@ -69,6 +69,43 @@ #define MSR_MCU_OPT_CTRL 0x00000123 #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) +/* Intel PT MSRs */ +#define MSR_RTIT_OUTPUT_BASE 0x00000560 + +#define MSR_RTIT_OUTPUT_MASK 0x00000561 + +#define MSR_RTIT_CTL 0x00000570 +#define RTIT_CTL_TRACEEN (_AC(1, ULL) << 0) +#define RTIT_CTL_CYCEN (_AC(1, ULL) << 1) +#define RTIT_CTL_OS (_AC(1, ULL) << 2) +#define RTIT_CTL_USR (_AC(1, ULL) << 3) +#define RTIT_CTL_PWR_EVT_EN (_AC(1, ULL) << 4) +#define RTIT_CTL_FUP_ON_PTW (_AC(1, ULL) << 5) +#define RTIT_CTL_FABRIC_EN (_AC(1, ULL) << 6) +#define RTIT_CTL_CR3_FILTER (_AC(1, ULL) << 7) +#define RTIT_CTL_TOPA (_AC(1, ULL) << 8) +#define RTIT_CTL_MTC_EN (_AC(1, ULL) << 9) +#define RTIT_CTL_TSC_EN (_AC(1, ULL) << 10) +#define RTIT_CTL_DIS_RETC (_AC(1, ULL) << 11) +#define RTIT_CTL_PTW_EN (_AC(1, ULL) << 12) +#define RTIT_CTL_BRANCH_EN (_AC(1, ULL) << 13) +#define RTIT_CTL_MTC_FREQ (_AC(0x0F, ULL) << 14) +#define RTIT_CTL_CYC_THRESH (_AC(0x0F, ULL) << 19) +#define RTIT_CTL_PSB_FREQ (_AC(0x0F, ULL) << 24) +#define RTIT_CTL_ADDR(n) (_AC(0x0F, ULL) << (32 + (4 * (n)))) + +#define MSR_RTIT_STATUS 0x00000571 +#define RTIT_STATUS_FILTER_EN (_AC(1, ULL) << 0) +#define RTIT_STATUS_CONTEXT_EN (_AC(1, ULL) << 1) +#define RTIT_STATUS_TRIGGER_EN (_AC(1, ULL) << 2) +#define RTIT_STATUS_ERROR (_AC(1, ULL) << 4) +#define RTIT_STATUS_STOPPED (_AC(1, ULL) << 5) +#define RTIT_STATUS_BYTECNT (_AC(0x1FFFF, ULL) << 32) + +#define MSR_RTIT_CR3_MATCH 0x00000572 +#define MSR_RTIT_ADDR_A(n) (0x00000580 + (n) * 2) +#define MSR_RTIT_ADDR_B(n) (0x00000581 + (n) * 2) + #define MSR_U_CET 0x000006a0 #define MSR_S_CET 0x000006a2 #define CET_SHSTK_EN (_AC(1, ULL) << 0) -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFTq-0007re-AA; Tue, 30 Jun 2020 12:35:18 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFTp-0007rV-TM for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:17 +0000 X-Inumbo-ID: 25f5084e-bace-11ea-8610-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 25f5084e-bace-11ea-8610-12813bfff9fa; Tue, 30 Jun 2020 12:35:15 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id AAE72A37EB; Tue, 30 Jun 2020 14:35:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A849BA37EA; Tue, 30 Jun 2020 14:35:13 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZLnNPnFfY-W8; Tue, 30 Jun 2020 14:35:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 11CC5A37E6; Tue, 30 Jun 2020 14:35:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id q8_vUUrJFBBB; Tue, 30 Jun 2020 14:35:12 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id D117DA37EA; Tue, 30 Jun 2020 14:35:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id BF312225EF; Tue, 30 Jun 2020 14:34:42 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JT2YUD5paWCp; Tue, 30 Jun 2020 14:34:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 3005822622; Tue, 30 Jun 2020 14:34:37 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Lh4oKCBtqFik; Tue, 30 Jun 2020 14:34:37 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 09ADC224C7; Tue, 30 Jun 2020 14:34:37 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 02/10] x86/vmx: add IPT cpu feature Date: Tue, 30 Jun 2020 14:33:45 +0200 Message-Id: <7302dbfcd07dfaad9e50bb772673e588fcc4de67.1593519420.git.michal.leszczynski@cert.pl> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Kevin Tian , Stefano Stabellini , tamas.lengyel@intel.com, Jun Nakajima , Wei Liu , Andrew Cooper , Michal Leszczynski , Ian Jackson , George Dunlap , Jan Beulich , luwei.kang@intel.com, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Check if Intel Processor Trace feature is supported by current processor. Define vmtrace_supported global variable. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/vmx/vmcs.c | 7 ++++++- xen/common/domain.c | 2 ++ xen/include/asm-x86/cpufeature.h | 1 + xen/include/asm-x86/hvm/vmx/vmcs.h | 1 + xen/include/public/arch-x86/cpufeatureset.h | 1 + xen/include/xen/domain.h | 2 ++ 6 files changed, 13 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index ca94c2bedc..b73d824357 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -291,6 +291,12 @@ static int vmx_init_vmcs_config(void) _vmx_cpu_based_exec_control &= ~(CPU_BASED_CR8_LOAD_EXITING | CPU_BASED_CR8_STORE_EXITING); + rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); + + /* Check whether IPT is supported in VMX operation. */ + vmtrace_supported = cpu_has_ipt && + (_vmx_misc_cap & VMX_MISC_PT_SUPPORTED); + if ( _vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_SECONDARY_CONTROLS ) { min = 0; @@ -305,7 +311,6 @@ static int vmx_init_vmcs_config(void) SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS | SECONDARY_EXEC_XSAVES | SECONDARY_EXEC_TSC_SCALING); - rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL ) opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING; if ( opt_vpid_enabled ) diff --git a/xen/common/domain.c b/xen/common/domain.c index 7cc9526139..0a33e0dfd6 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -82,6 +82,8 @@ struct vcpu *idle_vcpu[NR_CPUS] __read_mostly; vcpu_info_t dummy_vcpu_info; +bool_t vmtrace_supported; + static void __domain_finalise_shutdown(struct domain *d) { struct vcpu *v; diff --git a/xen/include/asm-x86/cpufeature.h b/xen/include/asm-x86/cpufeature.h index f790d5c1f8..8d7955dd87 100644 --- a/xen/include/asm-x86/cpufeature.h +++ b/xen/include/asm-x86/cpufeature.h @@ -104,6 +104,7 @@ #define cpu_has_clwb boot_cpu_has(X86_FEATURE_CLWB) #define cpu_has_avx512er boot_cpu_has(X86_FEATURE_AVX512ER) #define cpu_has_avx512cd boot_cpu_has(X86_FEATURE_AVX512CD) +#define cpu_has_ipt boot_cpu_has(X86_FEATURE_IPT) #define cpu_has_sha boot_cpu_has(X86_FEATURE_SHA) #define cpu_has_avx512bw boot_cpu_has(X86_FEATURE_AVX512BW) #define cpu_has_avx512vl boot_cpu_has(X86_FEATURE_AVX512VL) diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h index 906810592f..0e9a0b8de6 100644 --- a/xen/include/asm-x86/hvm/vmx/vmcs.h +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h @@ -283,6 +283,7 @@ extern u32 vmx_secondary_exec_control; #define VMX_VPID_INVVPID_SINGLE_CONTEXT_RETAINING_GLOBAL 0x80000000000ULL extern u64 vmx_ept_vpid_cap; +#define VMX_MISC_PT_SUPPORTED 0x00004000 #define VMX_MISC_CR3_TARGET 0x01ff0000 #define VMX_MISC_VMWRITE_ALL 0x20000000 diff --git a/xen/include/public/arch-x86/cpufeatureset.h b/xen/include/public/arch-x86/cpufeatureset.h index 5ca35d9d97..0d3f15f628 100644 --- a/xen/include/public/arch-x86/cpufeatureset.h +++ b/xen/include/public/arch-x86/cpufeatureset.h @@ -217,6 +217,7 @@ XEN_CPUFEATURE(SMAP, 5*32+20) /*S Supervisor Mode Access Prevention */ XEN_CPUFEATURE(AVX512_IFMA, 5*32+21) /*A AVX-512 Integer Fused Multiply Add */ XEN_CPUFEATURE(CLFLUSHOPT, 5*32+23) /*A CLFLUSHOPT instruction */ XEN_CPUFEATURE(CLWB, 5*32+24) /*A CLWB instruction */ +XEN_CPUFEATURE(IPT, 5*32+25) /* Intel Processor Trace */ XEN_CPUFEATURE(AVX512PF, 5*32+26) /*A AVX-512 Prefetch Instructions */ XEN_CPUFEATURE(AVX512ER, 5*32+27) /*A AVX-512 Exponent & Reciprocal Instrs */ XEN_CPUFEATURE(AVX512CD, 5*32+28) /*A AVX-512 Conflict Detection Instrs */ diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h index 7e51d361de..6c786a56c2 100644 --- a/xen/include/xen/domain.h +++ b/xen/include/xen/domain.h @@ -130,4 +130,6 @@ struct vnuma_info { void vnuma_destroy(struct vnuma_info *vnuma); +extern bool_t vmtrace_supported; + #endif /* __XEN_DOMAIN_H__ */ -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:23 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFTv-0007tD-J5; Tue, 30 Jun 2020 12:35:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFTu-0007rV-S2 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:22 +0000 X-Inumbo-ID: 27355b6e-bace-11ea-8610-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 27355b6e-bace-11ea-8610-12813bfff9fa; Tue, 30 Jun 2020 12:35:17 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id D9E08A37EA; Tue, 30 Jun 2020 14:35:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id CC5CEA37EC; Tue, 30 Jun 2020 14:35:15 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id yqXAxhkte2Sl; Tue, 30 Jun 2020 14:35:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id F2078A37F2; Tue, 30 Jun 2020 14:35:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nyGj-uRfaFYR; Tue, 30 Jun 2020 14:35:14 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id A9B48A37E6; Tue, 30 Jun 2020 14:35:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 96E1522622; Tue, 30 Jun 2020 14:34:44 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xRYgAYFC3oz1; Tue, 30 Jun 2020 14:34:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id DDD4F2262A; Tue, 30 Jun 2020 14:34:38 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xrYKXSnKJAb1; Tue, 30 Jun 2020 14:34:38 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id B0221224C7; Tue, 30 Jun 2020 14:34:38 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 04/10] x86/vmx: implement processor tracing for VMX Date: Tue, 30 Jun 2020 14:33:47 +0200 Message-Id: <70df90dad7e759f4bb3dba405dc45e372a57fab7.1593519420.git.michal.leszczynski@cert.pl> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , tamas.lengyel@intel.com, Jun Nakajima , Wei Liu , Andrew Cooper , Michal Leszczynski , Jan Beulich , luwei.kang@intel.com, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Use Intel Processor Trace feature in order to provision vmtrace_pt_* features. Signed-off-by: Michal Leszczynski --- xen/arch/x86/hvm/vmx/vmx.c | 89 ++++++++++++++++++++++++++++++ xen/include/asm-x86/hvm/hvm.h | 38 +++++++++++++ xen/include/asm-x86/hvm/vmx/vmcs.h | 3 + xen/include/asm-x86/hvm/vmx/vmx.h | 14 +++++ 4 files changed, 144 insertions(+) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index ab19d9424e..db3f051b40 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -508,11 +508,24 @@ static void vmx_restore_host_msrs(void) static void vmx_save_guest_msrs(struct vcpu *v) { + uint64_t rtit_ctl; + /* * We cannot cache SHADOW_GS_BASE while the VCPU runs, as it can * be updated at any time via SWAPGS, which we cannot trap. */ v->arch.hvm.vmx.shadow_gs = rdgsshadow(); + + if ( unlikely(v->arch.hvm.vmx.pt_state && + v->arch.hvm.vmx.pt_state->active) ) + { + rdmsrl(MSR_RTIT_CTL, rtit_ctl); + BUG_ON(rtit_ctl & RTIT_CTL_TRACEEN); + + rdmsrl(MSR_RTIT_STATUS, v->arch.hvm.vmx.pt_state->status); + rdmsrl(MSR_RTIT_OUTPUT_MASK, + v->arch.hvm.vmx.pt_state->output_mask.raw); + } } static void vmx_restore_guest_msrs(struct vcpu *v) @@ -524,6 +537,17 @@ static void vmx_restore_guest_msrs(struct vcpu *v) if ( cpu_has_msr_tsc_aux ) wrmsr_tsc_aux(v->arch.msrs->tsc_aux); + + if ( unlikely(v->arch.hvm.vmx.pt_state && + v->arch.hvm.vmx.pt_state->active) ) + { + wrmsrl(MSR_RTIT_OUTPUT_BASE, + v->arch.hvm.vmx.pt_state->output_base); + wrmsrl(MSR_RTIT_OUTPUT_MASK, + v->arch.hvm.vmx.pt_state->output_mask.raw); + wrmsrl(MSR_RTIT_STATUS, + v->arch.hvm.vmx.pt_state->status); + } } void vmx_update_cpu_exec_control(struct vcpu *v) @@ -2240,6 +2264,60 @@ static bool vmx_get_pending_event(struct vcpu *v, struct x86_event *info) return true; } +static int vmx_init_pt(struct vcpu *v) +{ + v->arch.hvm.vmx.pt_state = xzalloc(struct pt_state); + + if ( !v->arch.hvm.vmx.pt_state ) + return -EFAULT; + + if ( !v->arch.vmtrace.pt_buf ) + return -EINVAL; + + if ( !v->domain->vmtrace_pt_size ) + return -EINVAL; + + v->arch.hvm.vmx.pt_state->output_base = page_to_maddr(v->arch.vmtrace.pt_buf); + v->arch.hvm.vmx.pt_state->output_mask.raw = v->domain->vmtrace_pt_size - 1; + + if ( vmx_add_host_load_msr(v, MSR_RTIT_CTL, 0) ) + return -EFAULT; + + if ( vmx_add_guest_msr(v, MSR_RTIT_CTL, + RTIT_CTL_TRACEEN | RTIT_CTL_OS | + RTIT_CTL_USR | RTIT_CTL_BRANCH_EN) ) + return -EFAULT; + + return 0; +} + +static int vmx_destroy_pt(struct vcpu* v) +{ + if ( v->arch.hvm.vmx.pt_state ) + xfree(v->arch.hvm.vmx.pt_state); + + v->arch.hvm.vmx.pt_state = NULL; + return 0; +} + +static int vmx_control_pt(struct vcpu *v, bool_t enable) +{ + if ( !v->arch.hvm.vmx.pt_state ) + return -EINVAL; + + v->arch.hvm.vmx.pt_state->active = enable; + return 0; +} + +static int vmx_get_pt_offset(struct vcpu *v, uint64_t *offset) +{ + if ( !v->arch.hvm.vmx.pt_state ) + return -EINVAL; + + *offset = v->arch.hvm.vmx.pt_state->output_mask.offset; + return 0; +} + static struct hvm_function_table __initdata vmx_function_table = { .name = "VMX", .cpu_up_prepare = vmx_cpu_up_prepare, @@ -2295,6 +2373,10 @@ static struct hvm_function_table __initdata vmx_function_table = { .altp2m_vcpu_update_vmfunc_ve = vmx_vcpu_update_vmfunc_ve, .altp2m_vcpu_emulate_ve = vmx_vcpu_emulate_ve, .altp2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc, + .vmtrace_init_pt = vmx_init_pt, + .vmtrace_destroy_pt = vmx_destroy_pt, + .vmtrace_control_pt = vmx_control_pt, + .vmtrace_get_pt_offset = vmx_get_pt_offset, .tsc_scaling = { .max_ratio = VMX_TSC_MULTIPLIER_MAX, }, @@ -3674,6 +3756,13 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs) hvm_invalidate_regs_fields(regs); + if ( unlikely(v->arch.hvm.vmx.pt_state && + v->arch.hvm.vmx.pt_state->active) ) + { + rdmsrl(MSR_RTIT_OUTPUT_MASK, + v->arch.hvm.vmx.pt_state->output_mask.raw); + } + if ( paging_mode_hap(v->domain) ) { /* diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h index 1eb377dd82..8f194889e5 100644 --- a/xen/include/asm-x86/hvm/hvm.h +++ b/xen/include/asm-x86/hvm/hvm.h @@ -214,6 +214,12 @@ struct hvm_function_table { bool_t (*altp2m_vcpu_emulate_ve)(struct vcpu *v); int (*altp2m_vcpu_emulate_vmfunc)(const struct cpu_user_regs *regs); + /* vmtrace */ + int (*vmtrace_init_pt)(struct vcpu *v); + int (*vmtrace_destroy_pt)(struct vcpu *v); + int (*vmtrace_control_pt)(struct vcpu *v, bool_t enable); + int (*vmtrace_get_pt_offset)(struct vcpu *v, uint64_t *offset); + /* * Parameters and callbacks for hardware-assisted TSC scaling, * which are valid only when the hardware feature is available. @@ -655,6 +661,38 @@ static inline bool altp2m_vcpu_emulate_ve(struct vcpu *v) return false; } +static inline int vmtrace_init_pt(struct vcpu *v) +{ + if ( hvm_funcs.vmtrace_init_pt ) + return hvm_funcs.vmtrace_init_pt(v); + + return -EOPNOTSUPP; +} + +static inline int vmtrace_destroy_pt(struct vcpu *v) +{ + if ( hvm_funcs.vmtrace_destroy_pt ) + return hvm_funcs.vmtrace_destroy_pt(v); + + return -EOPNOTSUPP; +} + +static inline int vmtrace_control_pt(struct vcpu *v, bool_t enable) +{ + if ( hvm_funcs.vmtrace_control_pt ) + return hvm_funcs.vmtrace_control_pt(v, enable); + + return -EOPNOTSUPP; +} + +static inline int vmtrace_get_pt_offset(struct vcpu *v, uint64_t *offset) +{ + if ( hvm_funcs.vmtrace_get_pt_offset ) + return hvm_funcs.vmtrace_get_pt_offset(v, offset); + + return -EOPNOTSUPP; +} + /* * This must be defined as a macro instead of an inline function, * because it uses 'struct vcpu' and 'struct domain' which have diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h b/xen/include/asm-x86/hvm/vmx/vmcs.h index 0e9a0b8de6..64c0d82614 100644 --- a/xen/include/asm-x86/hvm/vmx/vmcs.h +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h @@ -186,6 +186,9 @@ struct vmx_vcpu { * pCPU and wakeup the related vCPU. */ struct pi_blocking_vcpu pi_blocking; + + /* State of processor trace feature */ + struct pt_state *pt_state; }; int vmx_create_vmcs(struct vcpu *v); diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h index 111ccd7e61..be7213d3c0 100644 --- a/xen/include/asm-x86/hvm/vmx/vmx.h +++ b/xen/include/asm-x86/hvm/vmx/vmx.h @@ -689,4 +689,18 @@ typedef union ldt_or_tr_instr_info { }; } ldt_or_tr_instr_info_t; +/* Processor Trace state per vCPU */ +struct pt_state { + bool_t active; + uint64_t status; + uint64_t output_base; + union { + uint64_t raw; + struct { + uint32_t size; + uint32_t offset; + }; + } output_mask; +}; + #endif /* __ASM_X86_HVM_VMX_VMX_H__ */ -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFU0-0007vo-SN; Tue, 30 Jun 2020 12:35:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFTz-0007rV-SD for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:27 +0000 X-Inumbo-ID: 26eac194-bace-11ea-8610-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 26eac194-bace-11ea-8610-12813bfff9fa; Tue, 30 Jun 2020 12:35:17 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2E156A37F2; Tue, 30 Jun 2020 14:35:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id DBA3EA37EA; Tue, 30 Jun 2020 14:35:14 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6c6ZlYgi4yYs; Tue, 30 Jun 2020 14:35:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id EB504A37EF; Tue, 30 Jun 2020 14:35:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DLC0qsDeFUTK; Tue, 30 Jun 2020 14:35:13 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id C1F57A37E6; Tue, 30 Jun 2020 14:35:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id B009A22620; Tue, 30 Jun 2020 14:34:43 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id REfR4kavPwNO; Tue, 30 Jun 2020 14:34:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 0D78E22625; Tue, 30 Jun 2020 14:34:38 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SG5vQoo2xMmh; Tue, 30 Jun 2020 14:34:37 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id D1D2A224C7; Tue, 30 Jun 2020 14:34:37 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 03/10] tools/libxl: add vmtrace_pt_size parameter Date: Tue, 30 Jun 2020 14:33:46 +0200 Message-Id: <5f4f4b1afa432258daff43f2dc8119b6a441fff4.1593519420.git.michal.leszczynski@cert.pl> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Stefano Stabellini , tamas.lengyel@intel.com, Wei Liu , Andrew Cooper , Michal Leszczynski , Ian Jackson , George Dunlap , Jan Beulich , Anthony PERARD , luwei.kang@intel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Allow to specify the size of per-vCPU trace buffer upon domain creation. This is zero by default (meaning: not enabled). Signed-off-by: Michal Leszczynski --- docs/man/xl.cfg.5.pod.in | 10 ++++++++++ tools/golang/xenlight/helpers.gen.go | 2 ++ tools/golang/xenlight/types.gen.go | 1 + tools/libxl/libxl.h | 8 ++++++++ tools/libxl/libxl_create.c | 1 + tools/libxl/libxl_types.idl | 2 ++ tools/xl/xl_parse.c | 20 ++++++++++++++++++++ xen/common/domain.c | 12 ++++++++++++ xen/include/public/domctl.h | 1 + 9 files changed, 57 insertions(+) diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in index 0532739c1f..78f434b722 100644 --- a/docs/man/xl.cfg.5.pod.in +++ b/docs/man/xl.cfg.5.pod.in @@ -278,6 +278,16 @@ memory=8096 will report significantly less memory available for use than a system with maxmem=8096 memory=8096 due to the memory overhead of having to track the unused pages. +=item B + +Specifies the size of processor trace buffer that would be allocated +for each vCPU belonging to this domain. Disabled (i.e. B +by default. This must be set to non-zero value in order to be able to +use processor tracing features with this domain. + +B: The size value must be between 4 kB and 4 GB and it must +be also a power of 2. + =back =head3 Guest Virtual NUMA Configuration diff --git a/tools/golang/xenlight/helpers.gen.go b/tools/golang/xenlight/helpers.gen.go index 935d3bc50a..ecace9634e 100644 --- a/tools/golang/xenlight/helpers.gen.go +++ b/tools/golang/xenlight/helpers.gen.go @@ -1117,6 +1117,7 @@ return fmt.Errorf("invalid union key '%v'", x.Type)} x.ArchArm.GicVersion = GicVersion(xc.arch_arm.gic_version) x.ArchArm.Vuart = VuartType(xc.arch_arm.vuart) x.Altp2M = Altp2MMode(xc.altp2m) +x.VmtracePtOrder = int(xc.vmtrace_pt_order) return nil} @@ -1592,6 +1593,7 @@ return fmt.Errorf("invalid union key '%v'", x.Type)} xc.arch_arm.gic_version = C.libxl_gic_version(x.ArchArm.GicVersion) xc.arch_arm.vuart = C.libxl_vuart_type(x.ArchArm.Vuart) xc.altp2m = C.libxl_altp2m_mode(x.Altp2M) +xc.vmtrace_pt_order = C.int(x.VmtracePtOrder) return nil } diff --git a/tools/golang/xenlight/types.gen.go b/tools/golang/xenlight/types.gen.go index 663c1e86b4..f9b07ac862 100644 --- a/tools/golang/xenlight/types.gen.go +++ b/tools/golang/xenlight/types.gen.go @@ -516,6 +516,7 @@ GicVersion GicVersion Vuart VuartType } Altp2M Altp2MMode +VmtracePtOrder int } type domainBuildInfoTypeUnion interface { diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 71709dc585..891e8e28d6 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -438,6 +438,14 @@ */ #define LIBXL_HAVE_CREATEINFO_PASSTHROUGH 1 +/* + * LIBXL_HAVE_VMTRACE_PT_ORDER indicates that + * libxl_domain_create_info has a vmtrace_pt_order parameter, which + * allows to enable pre-allocation of processor tracing buffers + * with the given order of size. + */ +#define LIBXL_HAVE_VMTRACE_PT_ORDER 1 + /* * libxl ABI compatibility * diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 75862dc6ed..651d1f4c0f 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -608,6 +608,7 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config, .max_evtchn_port = b_info->event_channels, .max_grant_frames = b_info->max_grant_frames, .max_maptrack_frames = b_info->max_maptrack_frames, + .vmtrace_pt_order = b_info->vmtrace_pt_order, }; if (info->type != LIBXL_DOMAIN_TYPE_PV) { diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl index 9d3f05f399..1c5dd43e4d 100644 --- a/tools/libxl/libxl_types.idl +++ b/tools/libxl/libxl_types.idl @@ -645,6 +645,8 @@ libxl_domain_build_info = Struct("domain_build_info",[ # supported by x86 HVM and ARM support is planned. ("altp2m", libxl_altp2m_mode), + ("vmtrace_pt_order", integer), + ], dir=DIR_IN, copy_deprecated_fn="libxl__domain_build_info_copy_deprecated", ) diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c index 61b4ef7b7e..4eba224590 100644 --- a/tools/xl/xl_parse.c +++ b/tools/xl/xl_parse.c @@ -1861,6 +1861,26 @@ void parse_config_data(const char *config_source, } } + if (!xlu_cfg_get_long(config, "vmtrace_pt_size", &l, 1) && l) { + int32_t shift = 0; + + if (l & (l - 1)) + { + fprintf(stderr, "ERROR: pt buffer size must be a power of 2\n"); + exit(1); + } + + while (l >>= 1) ++shift; + + if (shift <= XEN_PAGE_SHIFT) + { + fprintf(stderr, "ERROR: too small pt buffer\n"); + exit(1); + } + + b_info->vmtrace_pt_order = shift - XEN_PAGE_SHIFT; + } + if (!xlu_cfg_get_list(config, "ioports", &ioports, &num_ioports, 0)) { b_info->num_ioports = num_ioports; b_info->ioports = calloc(num_ioports, sizeof(*b_info->ioports)); diff --git a/xen/common/domain.c b/xen/common/domain.c index 0a33e0dfd6..27dcfbac8c 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -338,6 +338,12 @@ static int sanitise_domain_config(struct xen_domctl_createdomain *config) return -EINVAL; } + if ( config->vmtrace_pt_order && !vmtrace_supported ) + { + dprintk(XENLOG_INFO, "Processor tracing is not supported\n"); + return -EINVAL; + } + return arch_sanitise_domain_config(config); } @@ -443,6 +449,12 @@ struct domain *domain_create(domid_t domid, d->nr_pirqs = min(d->nr_pirqs, nr_irqs); radix_tree_init(&d->pirq_tree); + + if ( config->vmtrace_pt_order ) + { + uint32_t shift_val = config->vmtrace_pt_order + PAGE_SHIFT; + d->vmtrace_pt_size = (1ULL << shift_val); + } } if ( (err = arch_domain_create(d, config)) != 0 ) diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index 59bdc28c89..7b8289d436 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -92,6 +92,7 @@ struct xen_domctl_createdomain { uint32_t max_evtchn_port; int32_t max_grant_frames; int32_t max_maptrack_frames; + uint8_t vmtrace_pt_order; struct xen_arch_domainconfig arch; }; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:33 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFU5-0007yO-Bk; Tue, 30 Jun 2020 12:35:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFU4-0007rV-SN for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:32 +0000 X-Inumbo-ID: 2d6897e5-bace-11ea-8610-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2d6897e5-bace-11ea-8610-12813bfff9fa; Tue, 30 Jun 2020 12:35:29 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 5445DA37F3; Tue, 30 Jun 2020 14:35:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3B0B7A37FB; Tue, 30 Jun 2020 14:35:27 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3XChIHKLaS_2; Tue, 30 Jun 2020 14:35:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id BBF7AA37F9; Tue, 30 Jun 2020 14:35:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8hxz5J2M2ELj; Tue, 30 Jun 2020 14:35:26 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 2B04DA37F3; Tue, 30 Jun 2020 14:35:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 8F7152262A; Tue, 30 Jun 2020 14:34:45 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id OtfMRFhj4Dx2; Tue, 30 Jun 2020 14:34:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 1DA3A22558; Tue, 30 Jun 2020 14:34:40 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id g85ttXe7J3M0; Tue, 30 Jun 2020 14:34:40 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id E4C23223E7; Tue, 30 Jun 2020 14:34:39 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 06/10] memory: batch processing in acquire_resource() Date: Tue, 30 Jun 2020 14:33:49 +0200 Message-Id: X-Mailer: git-send-email 2.17.1 In-Reply-To: References: In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Stefano Stabellini , tamas.lengyel@intel.com, Wei Liu , Andrew Cooper , Michal Leszczynski , Ian Jackson , George Dunlap , Jan Beulich , luwei.kang@intel.com Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Allow to acquire large resources by allowing acquire_resource() to process items in batches, using hypercall continuation. Signed-off-by: Michal Leszczynski --- xen/common/memory.c | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/xen/common/memory.c b/xen/common/memory.c index 714077c1e5..3ab06581a2 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -1046,10 +1046,12 @@ static int acquire_grant_table(struct domain *d, unsigned int id, } static int acquire_resource( - XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg) + XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg, + unsigned long *start_extent) { struct domain *d, *currd = current->domain; xen_mem_acquire_resource_t xmar; + uint32_t total_frames; /* * The mfn_list and gfn_list (below) arrays are ok on stack for the * moment since they are small, but if they need to grow in future @@ -1077,8 +1079,17 @@ static int acquire_resource( return 0; } + total_frames = xmar.nr_frames; + + if ( *start_extent ) + { + xmar.frame += *start_extent; + xmar.nr_frames -= *start_extent; + guest_handle_add_offset(xmar.frame_list, *start_extent); + } + if ( xmar.nr_frames > ARRAY_SIZE(mfn_list) ) - return -E2BIG; + xmar.nr_frames = ARRAY_SIZE(mfn_list); rc = rcu_lock_remote_domain_by_id(xmar.domid, &d); if ( rc ) @@ -1135,6 +1146,14 @@ static int acquire_resource( } } + if ( !rc ) + { + *start_extent += xmar.nr_frames; + + if ( *start_extent != total_frames ) + rc = -ERESTART; + } + out: rcu_unlock_domain(d); @@ -1600,7 +1619,14 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg) case XENMEM_acquire_resource: rc = acquire_resource( - guest_handle_cast(arg, xen_mem_acquire_resource_t)); + guest_handle_cast(arg, xen_mem_acquire_resource_t), + &start_extent); + + if ( rc == -ERESTART ) + return hypercall_create_continuation( + __HYPERVISOR_memory_op, "lh", + op | (start_extent << MEMOP_EXTENT_SHIFT), arg); + break; default: -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFUA-00081C-Lk; Tue, 30 Jun 2020 12:35:38 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFU9-0007rV-SP for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:37 +0000 X-Inumbo-ID: 2d6897e6-bace-11ea-8610-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2d6897e6-bace-11ea-8610-12813bfff9fa; Tue, 30 Jun 2020 12:35:29 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 6140EA37F9; Tue, 30 Jun 2020 14:35:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 484D2A37FA; Tue, 30 Jun 2020 14:35:27 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZlCGzAO2pZSL; Tue, 30 Jun 2020 14:35:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id AB7D4A37F8; Tue, 30 Jun 2020 14:35:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HSr51uoiqUOZ; Tue, 30 Jun 2020 14:35:26 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 28DAAA37EA; Tue, 30 Jun 2020 14:35:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 13D1622625; Tue, 30 Jun 2020 14:34:45 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HP0zBV_9dGFy; Tue, 30 Jun 2020 14:34:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 814842262E; Tue, 30 Jun 2020 14:34:39 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MsyLsha6KguP; Tue, 30 Jun 2020 14:34:39 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 60E77224C7; Tue, 30 Jun 2020 14:34:39 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 05/10] common/domain: allocate vmtrace_pt_buffer Date: Tue, 30 Jun 2020 14:33:48 +0200 Message-Id: <0e02c97054da6e367f740ab8d2574e2d255553c8.1593519420.git.michal.leszczynski@cert.pl> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Stefano Stabellini , tamas.lengyel@intel.com, Wei Liu , Andrew Cooper , Michal Leszczynski , Ian Jackson , George Dunlap , Jan Beulich , luwei.kang@intel.com, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Allocate processor trace buffer for each vCPU when the domain is created, deallocate trace buffers on domain destruction. Signed-off-by: Michal Leszczynski --- xen/arch/x86/domain.c | 11 +++++++++++ xen/common/domain.c | 32 ++++++++++++++++++++++++++++++++ xen/include/asm-x86/domain.h | 4 ++++ xen/include/xen/sched.h | 4 ++++ 4 files changed, 51 insertions(+) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index fee6c3931a..0d79fd390c 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -2199,6 +2199,17 @@ int domain_relinquish_resources(struct domain *d) altp2m_vcpu_disable_ve(v); } + for_each_vcpu ( d, v ) + { + if ( !v->arch.vmtrace.pt_buf ) + continue; + + vmtrace_destroy_pt(v); + + free_domheap_pages(v->arch.vmtrace.pt_buf, + get_order_from_bytes(v->domain->vmtrace_pt_size)); + } + if ( is_pv_domain(d) ) { for_each_vcpu ( d, v ) diff --git a/xen/common/domain.c b/xen/common/domain.c index 27dcfbac8c..8513659ef8 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -137,6 +137,31 @@ static void vcpu_destroy(struct vcpu *v) free_vcpu_struct(v); } +static int vmtrace_alloc_buffers(struct vcpu *v) +{ + struct page_info *pg; + uint64_t size = v->domain->vmtrace_pt_size; + + if ( size < PAGE_SIZE || size > GB(4) || (size & (size - 1)) ) + { + /* + * We don't accept trace buffer size smaller than single page + * and the upper bound is defined as 4GB in the specification. + * The buffer size must be also a power of 2. + */ + return -EINVAL; + } + + pg = alloc_domheap_pages(v->domain, get_order_from_bytes(size), + MEMF_no_refcount); + + if ( !pg ) + return -ENOMEM; + + v->arch.vmtrace.pt_buf = pg; + return 0; +} + struct vcpu *vcpu_create(struct domain *d, unsigned int vcpu_id) { struct vcpu *v; @@ -162,6 +187,9 @@ struct vcpu *vcpu_create(struct domain *d, unsigned int vcpu_id) v->vcpu_id = vcpu_id; v->dirty_cpu = VCPU_CPU_CLEAN; + if ( d->vmtrace_pt_size && vmtrace_alloc_buffers(v) != 0 ) + return NULL; + spin_lock_init(&v->virq_lock); tasklet_init(&v->continue_hypercall_tasklet, NULL, NULL); @@ -188,6 +216,9 @@ struct vcpu *vcpu_create(struct domain *d, unsigned int vcpu_id) if ( arch_vcpu_create(v) != 0 ) goto fail_sched; + if ( d->vmtrace_pt_size && vmtrace_init_pt(v) != 0 ) + goto fail_sched; + d->vcpu[vcpu_id] = v; if ( vcpu_id != 0 ) { @@ -422,6 +453,7 @@ struct domain *domain_create(domid_t domid, d->shutdown_code = SHUTDOWN_CODE_INVALID; spin_lock_init(&d->pbuf_lock); + spin_lock_init(&d->vmtrace_lock); rwlock_init(&d->vnuma_rwlock); diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h index 6fd94c2e14..b01c107f5c 100644 --- a/xen/include/asm-x86/domain.h +++ b/xen/include/asm-x86/domain.h @@ -627,6 +627,10 @@ struct arch_vcpu struct { bool next_interrupt_enabled; } monitor; + + struct { + struct page_info *pt_buf; + } vmtrace; }; struct guest_memory_policy diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index ac53519d7f..48f0a61bbd 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -457,6 +457,10 @@ struct domain unsigned pbuf_idx; spinlock_t pbuf_lock; + /* Used by vmtrace features */ + spinlock_t vmtrace_lock; + uint64_t vmtrace_pt_size; + /* OProfile support. */ struct xenoprof *xenoprof; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:46 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFUI-00085I-0E; Tue, 30 Jun 2020 12:35:46 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFUG-00084T-HL for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:44 +0000 X-Inumbo-ID: 36b14328-bace-11ea-8496-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 36b14328-bace-11ea-8496-bc764e2007e4; Tue, 30 Jun 2020 12:35:43 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id DC3E5A3802; Tue, 30 Jun 2020 14:35:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id D8935A3801; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1lhq1HLaEDyM; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 48D23A3800; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Hygtmvh7zNLG; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1E693A37FB; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id BC8B322591; Tue, 30 Jun 2020 14:34:46 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id VUKdIBoPhtuc; Tue, 30 Jun 2020 14:34:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 4BE85225A6; Tue, 30 Jun 2020 14:34:41 +0200 (CEST) X-Quarantine-ID: <8aap-g1DnW7g> X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8aap-g1DnW7g; Tue, 30 Jun 2020 14:34:41 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 2916C22554; Tue, 30 Jun 2020 14:34:41 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 08/10] x86/domctl: add XEN_DOMCTL_vmtrace_op Date: Tue, 30 Jun 2020 14:33:51 +0200 Message-Id: <5578c50c2c1803ccd1c92d125c6b1febf1415a8a.1593519420.git.michal.leszczynski@cert.pl> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Stefano Stabellini , tamas.lengyel@intel.com, Wei Liu , Andrew Cooper , Michal Leszczynski , Ian Jackson , George Dunlap , Jan Beulich , luwei.kang@intel.com, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Implement domctl to manage the runtime state of processor trace feature. Signed-off-by: Michal Leszczynski --- xen/arch/x86/domctl.c | 48 +++++++++++++++++++++++++++++++++++++ xen/include/public/domctl.h | 26 ++++++++++++++++++++ 2 files changed, 74 insertions(+) diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index 6f2c69788d..a041b724d8 100644 --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -322,6 +322,48 @@ void arch_get_domain_info(const struct domain *d, info->arch_config.emulation_flags = d->arch.emulation_flags; } +static int do_vmtrace_op(struct domain *d, struct xen_domctl_vmtrace_op *op, + XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) +{ + int rc; + struct vcpu *v; + + if ( !vmtrace_supported ) + return -EOPNOTSUPP; + + if ( !is_hvm_domain(d) ) + return -EOPNOTSUPP; + + if ( op->vcpu >= d->max_vcpus ) + return -EINVAL; + + v = domain_vcpu(d, op->vcpu); + rc = 0; + + switch ( op->cmd ) + { + case XEN_DOMCTL_vmtrace_pt_enable: + case XEN_DOMCTL_vmtrace_pt_disable: + vcpu_pause(v); + spin_lock(&d->vmtrace_lock); + + rc = vmtrace_control_pt(v, op->cmd == XEN_DOMCTL_vmtrace_pt_enable); + + spin_unlock(&d->vmtrace_lock); + vcpu_unpause(v); + break; + + case XEN_DOMCTL_vmtrace_pt_get_offset: + rc = vmtrace_get_pt_offset(v, &op->offset); + break; + + default: + rc = -EOPNOTSUPP; + } + + return rc; +} + #define MAX_IOPORTS 0x10000 long arch_do_domctl( @@ -337,6 +379,12 @@ long arch_do_domctl( switch ( domctl->cmd ) { + case XEN_DOMCTL_vmtrace_op: + ret = do_vmtrace_op(d, &domctl->u.vmtrace_op, u_domctl); + if ( !ret ) + copyback = true; + break; + case XEN_DOMCTL_shadow_op: ret = paging_domctl(d, &domctl->u.shadow_op, u_domctl, 0); if ( ret == -ERESTART ) diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h index 7b8289d436..f836cb5970 100644 --- a/xen/include/public/domctl.h +++ b/xen/include/public/domctl.h @@ -1136,6 +1136,28 @@ struct xen_domctl_vuart_op { */ }; +/* XEN_DOMCTL_vmtrace_op: Perform VM tracing related operation */ +#if defined(__XEN__) || defined(__XEN_TOOLS__) + +struct xen_domctl_vmtrace_op { + /* IN variable */ + uint32_t cmd; +/* Enable/disable external vmtrace for given domain */ +#define XEN_DOMCTL_vmtrace_pt_enable 1 +#define XEN_DOMCTL_vmtrace_pt_disable 2 +#define XEN_DOMCTL_vmtrace_pt_get_offset 3 + domid_t domain; + uint32_t vcpu; + uint64_aligned_t size; + + /* OUT variable */ + uint64_aligned_t offset; +}; +typedef struct xen_domctl_vmtrace_op xen_domctl_vmtrace_op_t; +DEFINE_XEN_GUEST_HANDLE(xen_domctl_vmtrace_op_t); + +#endif /* defined(__XEN__) || defined(__XEN_TOOLS__) */ + struct xen_domctl { uint32_t cmd; #define XEN_DOMCTL_createdomain 1 @@ -1217,6 +1239,7 @@ struct xen_domctl { #define XEN_DOMCTL_vuart_op 81 #define XEN_DOMCTL_get_cpu_policy 82 #define XEN_DOMCTL_set_cpu_policy 83 +#define XEN_DOMCTL_vmtrace_op 84 #define XEN_DOMCTL_gdbsx_guestmemio 1000 #define XEN_DOMCTL_gdbsx_pausevcpu 1001 #define XEN_DOMCTL_gdbsx_unpausevcpu 1002 @@ -1277,6 +1300,9 @@ struct xen_domctl { struct xen_domctl_monitor_op monitor_op; struct xen_domctl_psr_alloc psr_alloc; struct xen_domctl_vuart_op vuart_op; +#if defined(__XEN__) || defined(__XEN_TOOLS__) + struct xen_domctl_vmtrace_op vmtrace_op; +#endif uint8_t pad[128]; } u; }; -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFUJ-00086Z-9d; Tue, 30 Jun 2020 12:35:47 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFUH-00084u-6R for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:45 +0000 X-Inumbo-ID: 36959ab0-bace-11ea-8610-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 36959ab0-bace-11ea-8610-12813bfff9fa; Tue, 30 Jun 2020 12:35:43 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id A9886A3800; Tue, 30 Jun 2020 14:35:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A711FA3802; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JziU2kPEFnPj; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 3D95EA37FE; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0-sn10WueO7f; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1A422A37F8; Tue, 30 Jun 2020 14:35:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 016AA223C3; Tue, 30 Jun 2020 14:34:46 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vlc-Ku5jd70r; Tue, 30 Jun 2020 14:34:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 94DB822591; Tue, 30 Jun 2020 14:34:40 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gWn4M7wYhlp7; Tue, 30 Jun 2020 14:34:40 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 72A7622564; Tue, 30 Jun 2020 14:34:40 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 07/10] x86/mm: add vmtrace_buf resource type Date: Tue, 30 Jun 2020 14:33:50 +0200 Message-Id: <2446caa5be5eca36f0b5ca47d2edcbd6f7792484.1593519420.git.michal.leszczynski@cert.pl> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Julien Grall , Stefano Stabellini , tamas.lengyel@intel.com, Wei Liu , Andrew Cooper , Michal Leszczynski , Ian Jackson , George Dunlap , Jan Beulich , luwei.kang@intel.com, =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Allow to map processor trace buffer using acquire_resource(). Signed-off-by: Michal Leszczynski --- xen/arch/x86/mm.c | 25 +++++++++++++++++++++++++ xen/include/public/memory.h | 1 + 2 files changed, 26 insertions(+) diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index e376fc7e8f..bb781bd90c 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4624,6 +4624,31 @@ int arch_acquire_resource(struct domain *d, unsigned int type, } break; } + + case XENMEM_resource_vmtrace_buf: + { + mfn_t mfn; + unsigned int i; + struct vcpu *v = domain_vcpu(d, id); + rc = -EINVAL; + + if ( !v ) + break; + + if ( !v->arch.vmtrace.pt_buf ) + break; + + mfn = page_to_mfn(v->arch.vmtrace.pt_buf); + + if ( frame + nr_frames > (v->domain->vmtrace_pt_size >> PAGE_SHIFT) ) + break; + + rc = 0; + for ( i = 0; i < nr_frames; i++ ) + mfn_list[i] = mfn_x(mfn_add(mfn, frame + i)); + + break; + } #endif default: diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index dbd35305df..f823c784c3 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -620,6 +620,7 @@ struct xen_mem_acquire_resource { #define XENMEM_resource_ioreq_server 0 #define XENMEM_resource_grant_table 1 +#define XENMEM_resource_vmtrace_buf 2 /* * IN - a type-specific resource identifier, which must be zero -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFUK-00087i-L0; Tue, 30 Jun 2020 12:35:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFUJ-00084u-Sh for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:47 +0000 X-Inumbo-ID: 36959ab3-bace-11ea-8610-12813bfff9fa Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 36959ab3-bace-11ea-8610-12813bfff9fa; Tue, 30 Jun 2020 12:35:45 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id AF98AA3809; Tue, 30 Jun 2020 14:35:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id A8019A3803; Tue, 30 Jun 2020 14:35:43 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vXvkS0S1AS_i; Tue, 30 Jun 2020 14:35:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 19328A3805; Tue, 30 Jun 2020 14:35:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mmHnl1MeRBTT; Tue, 30 Jun 2020 14:35:43 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id F0694A3803; Tue, 30 Jun 2020 14:35:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id E92A62258D; Tue, 30 Jun 2020 14:34:47 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id iRG1SBdsY0N9; Tue, 30 Jun 2020 14:34:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 559AA225E5; Tue, 30 Jun 2020 14:34:42 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ohvGC64yklKc; Tue, 30 Jun 2020 14:34:42 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 2E61F2252B; Tue, 30 Jun 2020 14:34:42 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 09/10] tools/libxc: add xc_vmtrace_* functions Date: Tue, 30 Jun 2020 14:33:52 +0200 Message-Id: <03c751efa273bf2a2b1575b0175219577da42e39.1593519420.git.michal.leszczynski@cert.pl> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: In-Reply-To: References: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: tamas.lengyel@intel.com, Michal Leszczynski , luwei.kang@intel.com, Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Add functions in libxc that use the new XEN_DOMCTL_vmtrace interface. Signed-off-by: Michal Leszczynski --- tools/libxc/Makefile | 1 + tools/libxc/include/xenctrl.h | 39 +++++++++++++++++++ tools/libxc/xc_vmtrace.c | 73 +++++++++++++++++++++++++++++++++++ 3 files changed, 113 insertions(+) create mode 100644 tools/libxc/xc_vmtrace.c diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile index fae5969a73..605e44501d 100644 --- a/tools/libxc/Makefile +++ b/tools/libxc/Makefile @@ -27,6 +27,7 @@ CTRL_SRCS-y += xc_csched2.c CTRL_SRCS-y += xc_arinc653.c CTRL_SRCS-y += xc_rt.c CTRL_SRCS-y += xc_tbuf.c +CTRL_SRCS-y += xc_vmtrace.c CTRL_SRCS-y += xc_pm.c CTRL_SRCS-y += xc_cpu_hotplug.c CTRL_SRCS-y += xc_resume.c diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h index 113ddd935d..66966f6c17 100644 --- a/tools/libxc/include/xenctrl.h +++ b/tools/libxc/include/xenctrl.h @@ -1585,6 +1585,45 @@ int xc_tbuf_set_cpu_mask(xc_interface *xch, xc_cpumap_t mask); int xc_tbuf_set_evt_mask(xc_interface *xch, uint32_t mask); +/** + * Enable processor trace for given vCPU in given DomU. + * Allocate the trace ringbuffer with given size. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @return 0 on success, -1 on failure + */ +int xc_vmtrace_pt_enable(xc_interface *xch, uint32_t domid, + uint32_t vcpu); + +/** + * Disable processor trace for given vCPU in given DomU. + * Deallocate the trace ringbuffer. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @return 0 on success, -1 on failure + */ +int xc_vmtrace_pt_disable(xc_interface *xch, uint32_t domid, + uint32_t vcpu); + +/** + * Get current offset inside the trace ringbuffer. + * This allows to determine how much data was written into the buffer. + * Once buffer overflows, the offset will reset to 0 and the previous + * data will be overriden. + * + * @parm xch a handle to an open hypervisor interface + * @parm domid domain identifier + * @parm vcpu vcpu identifier + * @parm offset current offset inside trace buffer will be written there + * @return 0 on success, -1 on failure + */ +int xc_vmtrace_pt_get_offset(xc_interface *xch, uint32_t domid, + uint32_t vcpu, uint64_t *offset); + int xc_domctl(xc_interface *xch, struct xen_domctl *domctl); int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl); diff --git a/tools/libxc/xc_vmtrace.c b/tools/libxc/xc_vmtrace.c new file mode 100644 index 0000000000..32f90a6203 --- /dev/null +++ b/tools/libxc/xc_vmtrace.c @@ -0,0 +1,73 @@ +/****************************************************************************** + * xc_vmtrace.c + * + * API for manipulating hardware tracing features + * + * Copyright (c) 2020, Michal Leszczynski + * + * Copyright 2020 CERT Polska. All rights reserved. + * Use is subject to license terms. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; + * version 2.1 of the License. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; If not, see . + */ + +#include "xc_private.h" +#include + +int xc_vmtrace_pt_enable( + xc_interface *xch, uint32_t domid, uint32_t vcpu) +{ + DECLARE_DOMCTL; + int rc; + + domctl.cmd = XEN_DOMCTL_vmtrace_op; + domctl.domain = domid; + domctl.u.vmtrace_op.cmd = XEN_DOMCTL_vmtrace_pt_enable; + domctl.u.vmtrace_op.vcpu = vcpu; + + rc = do_domctl(xch, &domctl); + return rc; +} + +int xc_vmtrace_pt_get_offset( + xc_interface *xch, uint32_t domid, uint32_t vcpu, uint64_t *offset) +{ + DECLARE_DOMCTL; + int rc; + + domctl.cmd = XEN_DOMCTL_vmtrace_op; + domctl.domain = domid; + domctl.u.vmtrace_op.cmd = XEN_DOMCTL_vmtrace_pt_get_offset; + domctl.u.vmtrace_op.vcpu = vcpu; + + rc = do_domctl(xch, &domctl); + if ( !rc ) + *offset = domctl.u.vmtrace_op.offset; + return rc; +} + +int xc_vmtrace_pt_disable(xc_interface *xch, uint32_t domid, uint32_t vcpu) +{ + DECLARE_DOMCTL; + int rc; + + domctl.cmd = XEN_DOMCTL_vmtrace_op; + domctl.domain = domid; + domctl.u.vmtrace_op.cmd = XEN_DOMCTL_vmtrace_pt_disable; + domctl.u.vmtrace_op.vcpu = vcpu; + + rc = do_domctl(xch, &domctl); + return rc; +} + -- 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:35:51 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:35:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFUN-0008AE-3H; Tue, 30 Jun 2020 12:35:51 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFUL-00084T-Fq for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:35:49 +0000 X-Inumbo-ID: 386884e2-bace-11ea-8496-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 386884e2-bace-11ea-8496-bc764e2007e4; Tue, 30 Jun 2020 12:35:46 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id C9722A3808; Tue, 30 Jun 2020 14:35:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id C6F14A380A; Tue, 30 Jun 2020 14:35:44 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id FQulLJynH1yD; Tue, 30 Jun 2020 14:35:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 23389A3807; Tue, 30 Jun 2020 14:35:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WizpvhWplQ1k; Tue, 30 Jun 2020 14:35:43 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id F3578A3801; Tue, 30 Jun 2020 14:35:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 2655C2231C; Tue, 30 Jun 2020 14:34:50 +0200 (CEST) X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id m9xyphjmeEWn; Tue, 30 Jun 2020 14:34:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 7701E22606; Tue, 30 Jun 2020 14:34:43 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at belindir.nask.net.pl X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References" Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ecl5c91OY5f7; Tue, 30 Jun 2020 14:34:43 +0200 (CEST) Received: from mq-desktop.cert.pl (unknown [195.187.238.217]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 5067F225E6; Tue, 30 Jun 2020 14:34:43 +0200 (CEST) From: =?UTF-8?q?Micha=C5=82=20Leszczy=C5=84ski?= To: xen-devel@lists.xenproject.org Subject: [PATCH v4 10/10] tools/proctrace: add proctrace tool Date: Tue, 30 Jun 2020 14:33:53 +0200 Message-Id: <0ab003238e4e666d3847024b8917dbc11c40fecb.1593519420.git.michal.leszczynski@cert.pl> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: MIME-Version: 1.0 In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: tamas.lengyel@intel.com, Michal Leszczynski , luwei.kang@intel.com, Ian Jackson , Wei Liu Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" From: Michal Leszczynski Add an demonstration tool that uses xc_vmtrace_* calls in order to manage external IPT monitoring for DomU. Signed-off-by: Michal Leszczynski --- tools/proctrace/COPYING | 339 ++++++++++++++++++++++++++++++++++++ tools/proctrace/Makefile | 48 +++++ tools/proctrace/proctrace.c | 163 +++++++++++++++++ 3 files changed, 550 insertions(+) create mode 100644 tools/proctrace/COPYING create mode 100644 tools/proctrace/Makefile create mode 100644 tools/proctrace/proctrace.c diff --git a/tools/proctrace/COPYING b/tools/proctrace/COPYING new file mode 100644 index 0000000000..c0a841112c --- /dev/null +++ b/tools/proctrace/COPYING @@ -0,0 +1,339 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 59 Temple Place, Suite 330, Boston, MA 02111-130= 7 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it= . + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange;= or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new version= s +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and condition= s +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number o= f +this License, you may choose any version ever published by the Free Soft= ware +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the autho= r +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software an= d +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRAN= TY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS= ED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK A= S +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRIT= ING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGE= S, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARIS= ING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITE= D +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTH= ER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these ter= ms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; If not, see . + + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `sho= w w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropri= ate +parts of the General Public License. Of course, the commands you use ma= y +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacke= r. + + , 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program i= nto +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with = the +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. diff --git a/tools/proctrace/Makefile b/tools/proctrace/Makefile new file mode 100644 index 0000000000..2983c477fe --- /dev/null +++ b/tools/proctrace/Makefile @@ -0,0 +1,48 @@ +# Copyright (C) CERT Polska - NASK PIB +# Author: Micha=C5=82 Leszczy=C5=84ski +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; under version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +XEN_ROOT=3D$(CURDIR)/../.. +include $(XEN_ROOT)/tools/Rules.mk + +CFLAGS +=3D -Werror +CFLAGS +=3D $(CFLAGS_libxenevtchn) +CFLAGS +=3D $(CFLAGS_libxenctrl) +LDLIBS +=3D $(LDLIBS_libxenctrl) +LDLIBS +=3D $(LDLIBS_libxenevtchn) +LDLIBS +=3D $(LDLIBS_libxenforeignmemory) + +.PHONY: all +all: build + +.PHONY: build +build: proctrace + +.PHONY: install +install: build + $(INSTALL_DIR) $(DESTDIR)$(sbindir) + $(INSTALL_PROG) proctrace $(DESTDIR)$(sbindir)/proctrace + +.PHONY: uninstall +uninstall: + rm -f $(DESTDIR)$(sbindir)/proctrace + +.PHONY: clean +clean: + $(RM) -f $(DEPS_RM) + +.PHONY: distclean +distclean: clean + +iptlive: iptlive.o Makefile + $(CC) $(LDFLAGS) $< -o $@ $(LDLIBS) $(APPEND_LDFLAGS) + +-include $(DEPS_INCLUDE) diff --git a/tools/proctrace/proctrace.c b/tools/proctrace/proctrace.c new file mode 100644 index 0000000000..22bf91db8d --- /dev/null +++ b/tools/proctrace/proctrace.c @@ -0,0 +1,163 @@ +/***********************************************************************= ******* + * tools/proctrace.c + * + * Demonstrative tool for collecting Intel Processor Trace data from Xen= . + * Could be used to externally monitor a given vCPU in given DomU. + * + * Copyright (C) 2020 by CERT Polska - NASK PIB + * + * Authors: Micha=C5=82 Leszczy=C5=84ski, michal.leszczynski@cert.pl + * Date: June, 2020 + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; under version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; If not, see . + */ + +#include +#include +#include +#include + +#include +#include +#include + +#define BUF_SIZE (16384 * XC_PAGE_SIZE) + +volatile int interrupted =3D 0; + +void term_handler(int signum) { + interrupted =3D 1; +} + +int main(int argc, char* argv[]) { + xc_interface *xc; + uint32_t domid; + uint32_t vcpu_id; + + int rc =3D -1; + uint8_t *buf =3D NULL; + uint64_t last_offset =3D 0; + + xenforeignmemory_handle *fmem; + xenforeignmemory_resource_handle *fres; + + if (signal(SIGINT, term_handler) =3D=3D SIG_ERR) + { + fprintf(stderr, "Failed to register signal handler\n"); + return 1; + } + + if (argc !=3D 3) { + fprintf(stderr, "Usage: %s \n", argv[0]); + fprintf(stderr, "It's recommended to redirect this" + "program's output to file\n"); + fprintf(stderr, "or to pipe it's output to xxd or other program.= \n"); + return 1; + } + + domid =3D atoi(argv[1]); + vcpu_id =3D atoi(argv[2]); + + xc =3D xc_interface_open(0, 0, 0); + + fmem =3D xenforeignmemory_open(0, 0); + + if (!xc) { + fprintf(stderr, "Failed to open xc interface\n"); + return 1; + } + + rc =3D xc_vmtrace_pt_enable(xc, domid, vcpu_id); + + if (rc) { + fprintf(stderr, "Failed to call xc_vmtrace_pt_enable\n"); + return 1; + } + + fres =3D xenforeignmemory_map_resource( + fmem, domid, XENMEM_resource_vmtrace_buf, + /* vcpu: */ vcpu_id, + /* frame: */ 0, + /* num_frames: */ BUF_SIZE >> XC_PAGE_SHIFT, + (void **)&buf, + PROT_READ, 0); + + if (!buf) { + fprintf(stderr, "Failed to map trace buffer\n"); + return 1; + } + + while (!interrupted) { + uint64_t offset; + rc =3D xc_vmtrace_pt_get_offset(xc, domid, vcpu_id, &offset); + + if (rc) { + fprintf(stderr, "Failed to call xc_vmtrace_pt_get_offset\n")= ; + return 1; + } + + if (offset > last_offset) + { + fwrite(buf + last_offset, offset - last_offset, 1, stdout); + } + else if (offset < last_offset) + { + // buffer wrapped + fwrite(buf + last_offset, BUF_SIZE - last_offset, 1, stdout)= ; + fwrite(buf, offset, 1, stdout); + } + + last_offset =3D offset; + usleep(1000 * 100); + } + + rc =3D xenforeignmemory_unmap_resource(fmem, fres); + + if (rc) { + fprintf(stderr, "Failed to unmap resource\n"); + return 1; + } + + rc =3D xenforeignmemory_close(fmem); + + if (rc) { + fprintf(stderr, "Failed to close fmem\n"); + return 1; + } + + rc =3D xc_vmtrace_pt_disable(xc, domid, vcpu_id); + + if (rc) { + fprintf(stderr, "Failed to call xc_vmtrace_pt_disable\n"); + return 1; + } + + rc =3D xc_interface_close(xc); + + if (rc) { + fprintf(stderr, "Failed to close xc interface\n"); + return 1; + } + + return 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * tab-width: 4 + * indent-tabs-mode: nil + * End: + */ --=20 2.20.1 From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:48:29 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:48:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFgU-0001IS-AL; Tue, 30 Jun 2020 12:48:22 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFgT-0001IN-3S for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:48:21 +0000 X-Inumbo-ID: fa225742-bacf-11ea-8615-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id fa225742-bacf-11ea-8615-12813bfff9fa; Tue, 30 Jun 2020 12:48:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=z7jc5NzfTkp8y5Cz8EXxkRyo5Q5w5XhhJH6y+Igibds=; b=33apq4HhaQC2e4pLznWqAg3tP/ 1P0V6U+FC/fTBGn7I/RBkoxe5tcYa2oFwsAmz6X7+4tRapC/7L+kJFqXDgZt+cUclYd+jUap4aWrN paDcuhqPDpZG9criQcUBEqQzqny4AziomBprLg91Tl6xFijmh9i1/jJz6ieMoeU2NfPY=; Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFgN-00007W-V4; Tue, 30 Jun 2020 12:48:15 +0000 Received: from [54.239.6.187] (helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jqFgN-0005z1-Mk; Tue, 30 Jun 2020 12:48:15 +0000 Subject: Re: [PATCH for-4.14 v4] x86/tlb: fix assisted flush usage To: Roger Pau Monne , xen-devel@lists.xenproject.org References: <20200626155723.91558-1-roger.pau@citrix.com> From: Julien Grall Message-ID: Date: Tue, 30 Jun 2020 13:48:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200626155723.91558-1-roger.pau@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , Jan Beulich , Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Hi Roger, On 26/06/2020 16:57, Roger Pau Monne wrote: > Commit e9aca9470ed86 introduced a regression when avoiding sending > IPIs for certain flush operations. Xen page fault handler > (spurious_page_fault) relies on blocking interrupts in order to > prevent handling TLB flush IPIs and thus preventing other CPUs from > removing page tables pages. Switching to assisted flushing avoided such > IPIs, and thus can result in pages belonging to the page tables being > removed (and possibly re-used) while __page_fault_type is being > executed. > > Force some of the TLB flushes to use IPIs, thus avoiding the assisted > TLB flush. Those selected flushes are the page type change (when > switching from a page table type to a different one, ie: a page that > has been removed as a page table) and page allocation. This sadly has > a negative performance impact on the pvshim, as less assisted flushes > can be used. Note the flush in grant-table code is also switched to > use an IPI even when not strictly needed. This is done so that a > common arch_flush_tlb_mask can be introduced and always used in common > code. > > Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush > using an IPI (flush_tlb_mask_sync, x86 only). Note that the flag is > only meaningfully defined when the hypervisor supports PV or shadow > paging mode, as otherwise hardware assisted paging domains are in > charge of their page tables and won't share page tables with Xen, thus > not influencing the result of page walks performed by the spurious > fault handler. > > Just passing this new flag when calling flush_area_mask prevents the > usage of the assisted flush without any other side effects. > > Note the flag is not defined on Arm. > > Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') > Reported-by: Andrew Cooper > Signed-off-by: Roger Pau Monné Acked-by: Julien Grall Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:49:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:49:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFhD-0001MI-Nz; Tue, 30 Jun 2020 12:49:07 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFhD-0001MD-50 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:49:07 +0000 X-Inumbo-ID: 15068bd2-bad0-11ea-bca7-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 15068bd2-bad0-11ea-bca7-bc764e2007e4; Tue, 30 Jun 2020 12:49:06 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 368E3A2C39; Tue, 30 Jun 2020 14:49:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 1E886A17B5; Tue, 30 Jun 2020 14:49:04 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pfbd0BAHAd95; Tue, 30 Jun 2020 14:49:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 708D3A2A96; Tue, 30 Jun 2020 14:49:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dUw5_E_x6lqn; Tue, 30 Jun 2020 14:49:03 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 36B30A17B5; Tue, 30 Jun 2020 14:49:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 221D92249E; Tue, 30 Jun 2020 14:48:33 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id stYIECpH3HxV; Tue, 30 Jun 2020 14:48:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 7E7712256A; Tue, 30 Jun 2020 14:48:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RncgdOjtiJ9c; Tue, 30 Jun 2020 14:48:27 +0200 (CEST) Received: from [192.168.70.4] (unknown [195.187.238.48]) by belindir.nask.net.pl (Postfix) with ESMTPSA id 1927C21EB1; Tue, 30 Jun 2020 14:48:26 +0200 (CEST) Subject: Re: [PATCH v4 00/10] Implement support for external IPT monitoring To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , xen-devel@lists.xenproject.org References: From: Hubert Jasudowicz Message-ID: Date: Tue, 30 Jun 2020 14:48:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Stefano Stabellini , tamas.lengyel@intel.com, Jan Beulich , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , luwei.kang@intel.com, Jun Nakajima , Anthony PERARD , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/30/20 2:33 PM, Micha=C5=82 Leszczy=C5=84ski wrote: > From: Michal Leszczynski >=20 > Intel Processor Trace is an architectural extension available in modern= Intel=20 > family CPUs. It allows recording the detailed trace of activity while t= he=20 > processor executes the code. One might use the recorded trace to recons= truct=20 > the code flow. It means, to find out the executed code paths, determine= =20 > branches taken, and so forth. >=20 > The abovementioned feature is described in Intel(R) 64 and IA-32 Archit= ectures=20 > Software Developer's Manual Volume 3C: System Programming Guide, Part 3= ,=20 > Chapter 36: "Intel Processor Trace." >=20 > This patch series implements an interface that Dom0 could use in order = to=20 > enable IPT for particular vCPUs in DomU, allowing for external monitori= ng. Such=20 > a feature has numerous applications like malware monitoring, fuzzing, o= r=20 > performance testing. >=20 > Also thanks to Tamas K Lengyel for a few preliminary hints before > first version of this patch was submitted to xen-devel. >=20 > Changed since v1: > * MSR_RTIT_CTL is managed using MSR load lists > * other PT-related MSRs are modified only when vCPU goes out of conte= xt > * trace buffer is now acquired as a resource > * added vmtrace_pt_size parameter in xl.cfg, the size of trace buffer > must be specified in the moment of domain creation > * trace buffers are allocated on domain creation, destructed on > domain destruction > * HVMOP_vmtrace_ipt_enable/disable is limited to enabling/disabling P= T > these calls don't manage buffer memory anymore > * lifted 32 MFN/GFN array limit when acquiring resources > * minor code style changes according to review >=20 > Changed since v2: > * trace buffer is now allocated on domain creation (in v2 it was > allocated when hvm param was set) > * restored 32-item limit in mfn/gfn arrays in acquire_resource > and instead implemented hypercall continuations > * code changes according to Jan's and Roger's review >=20 > Changed since v3: > * vmtrace HVMOPs are not implemented as DOMCTLs > * patches splitted up according to Andrew's comments > * code changes according to v3 review on the mailing list >=20 >=20 > Michal Leszczynski (10): > x86/vmx: add Intel PT MSR definitions > x86/vmx: add IPT cpu feature > tools/libxl: add vmtrace_pt_size parameter > x86/vmx: implement processor tracing for VMX > common/domain: allocate vmtrace_pt_buffer > memory: batch processing in acquire_resource() > x86/mm: add vmtrace_buf resource type > x86/domctl: add XEN_DOMCTL_vmtrace_op > tools/libxc: add xc_vmtrace_* functions > tools/proctrace: add proctrace tool >=20 > docs/man/xl.cfg.5.pod.in | 10 + > tools/golang/xenlight/helpers.gen.go | 2 + > tools/golang/xenlight/types.gen.go | 1 + > tools/libxc/Makefile | 1 + > tools/libxc/include/xenctrl.h | 39 +++ > tools/libxc/xc_vmtrace.c | 73 +++++ > tools/libxl/libxl.h | 8 + > tools/libxl/libxl_create.c | 1 + > tools/libxl/libxl_types.idl | 2 + > tools/proctrace/COPYING | 339 ++++++++++++++++++++ > tools/proctrace/Makefile | 48 +++ > tools/proctrace/proctrace.c | 163 ++++++++++ > tools/xl/xl_parse.c | 20 ++ > xen/arch/x86/domain.c | 11 + > xen/arch/x86/domctl.c | 48 +++ > xen/arch/x86/hvm/vmx/vmcs.c | 7 +- > xen/arch/x86/hvm/vmx/vmx.c | 89 +++++ > xen/arch/x86/mm.c | 25 ++ > xen/common/domain.c | 46 +++ > xen/common/memory.c | 32 +- > xen/include/asm-x86/cpufeature.h | 1 + > xen/include/asm-x86/domain.h | 4 + > xen/include/asm-x86/hvm/hvm.h | 38 +++ > xen/include/asm-x86/hvm/vmx/vmcs.h | 4 + > xen/include/asm-x86/hvm/vmx/vmx.h | 14 + > xen/include/asm-x86/msr-index.h | 37 +++ > xen/include/public/arch-x86/cpufeatureset.h | 1 + > xen/include/public/domctl.h | 27 ++ > xen/include/public/memory.h | 1 + > xen/include/xen/domain.h | 2 + > xen/include/xen/sched.h | 4 + > 31 files changed, 1094 insertions(+), 4 deletions(-) > create mode 100644 tools/libxc/xc_vmtrace.c > create mode 100644 tools/proctrace/COPYING > create mode 100644 tools/proctrace/Makefile > create mode 100644 tools/proctrace/proctrace.c >=20 FYI, this patchset is also available at: https://github.com/icedevml/xen/tree/ipt-patch-v4 Hubert Jasudowicz From xen-devel-bounces@lists.xenproject.org Tue Jun 30 12:52:11 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 12:52:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFk9-0002Aj-6e; Tue, 30 Jun 2020 12:52:09 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFk7-0002Aa-M0 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 12:52:07 +0000 X-Inumbo-ID: 80d19c3a-bad0-11ea-bb8b-bc764e2007e4 Received: from mail-ed1-x543.google.com (unknown [2a00:1450:4864:20::543]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 80d19c3a-bad0-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 12:52:07 +0000 (UTC) Received: by mail-ed1-x543.google.com with SMTP id d15so16046682edm.10 for ; Tue, 30 Jun 2020 05:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=3gN6LhDZ3WO6b+v/EAtB65ovPUJ5OfHHriG5/WGDqaI=; b=pvVxXlQZy7X4EJVdzbjqo3BIRxt6u29gGnuOO/VTKYY2G83axV0OzfN9FXfO5Uc+eE zLGPBPO8Ml8WC1y7aejwbzilb50BmrLAQd8Q+BqF9sVrohi8OAvnCRMoIE8Rf8goLS08 0N2Zk38utjgxxzn5EoghB7eJPHuyt6cmIxKQPYb/4kBgxGIeOyFxAdAuqCasmi2EV2Vj h4PoSnYNNKgF28TJSzVC9OwP4EMdHtDLwUv2V6sPuEMGhncglH6poFdzylpdH6dzOiJC z5Vp5cikBbUWCalfzLhTYrR2FI2DSAP2cLq2s3bd6Sq1Bgrb5uwV+xPmnF+7Muf/cIgo pTSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :thread-index:content-language; bh=3gN6LhDZ3WO6b+v/EAtB65ovPUJ5OfHHriG5/WGDqaI=; b=JJodXoJ/MenPBaJgyMiAcFQt4AwaOT2lFpfBCIsNlCzfOq/BH0wFlJQ+PJ0phIBZlT TvwNT2bwBVlohxpngWsvPnR83tCvYmdm2H30Cqiy5BhGqO2pofGj5wVijXytr/sHl12c 49+Hhcq0KTbD0pJzI5jBF1tst/5ryXr93TFR39gX3ZLTdqR+4DxspysZBd2TU8cnZBFN 1gZXMlTtthWW6DnkAOVJGJ1OyK2aLMphfh+1/WXDbjYjtqGWpcNt2VUQw8pnNcxsB6d1 Kacu56AfL3GWewhJXiRkzCjrK0xHRoL0Wpbgb81MQEi7Mpd/xJ4TjFDWtZtuPhinfb/e 3l+A== X-Gm-Message-State: AOAM531bPMPuYOglpG9kZIBa/ur5mWvH8f7c9w9ISPMKbAJ7dm/9L08w slNoeVDOviqje89PiypPZY8= X-Google-Smtp-Source: ABdhPJwDX5d7ICGG+Ej8J7zNh0awLsjM3HqQWK3MzQtsZ6k8NXYYtE3xXXRRAMosSEm3Z6yf1O8oZA== X-Received: by 2002:a50:8143:: with SMTP id 61mr23160507edc.202.1593521526254; Tue, 30 Jun 2020 05:52:06 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-238.amazon.com. [54.240.197.238]) by smtp.gmail.com with ESMTPSA id h2sm2753569edk.54.2020.06.30.05.52.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 05:52:05 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Julien Grall'" , "'Roger Pau Monne'" , References: <20200626155723.91558-1-roger.pau@citrix.com> In-Reply-To: Subject: RE: [PATCH for-4.14 v4] x86/tlb: fix assisted flush usage Date: Tue, 30 Jun 2020 13:52:04 +0100 Message-ID: <000301d64edd$41fa4cf0$c5eee6d0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEPrqt6NsU03o2hOfg+V497vZFhIwIMPTDRqm37HcA= Content-Language: en-gb X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Stefano Stabellini' , 'Wei Liu' , 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Jan Beulich' , 'Volodymyr Babchuk' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Julien Grall > Sent: 30 June 2020 13:48 > To: Roger Pau Monne ; = xen-devel@lists.xenproject.org > Cc: paul@xen.org; Stefano Stabellini ; = Volodymyr Babchuk > ; Andrew Cooper = ; George Dunlap > ; Ian Jackson ; = Jan Beulich ; > Wei Liu > Subject: Re: [PATCH for-4.14 v4] x86/tlb: fix assisted flush usage >=20 > Hi Roger, >=20 > On 26/06/2020 16:57, Roger Pau Monne wrote: > > Commit e9aca9470ed86 introduced a regression when avoiding sending > > IPIs for certain flush operations. Xen page fault handler > > (spurious_page_fault) relies on blocking interrupts in order to > > prevent handling TLB flush IPIs and thus preventing other CPUs from > > removing page tables pages. Switching to assisted flushing avoided = such > > IPIs, and thus can result in pages belonging to the page tables = being > > removed (and possibly re-used) while __page_fault_type is being > > executed. > > > > Force some of the TLB flushes to use IPIs, thus avoiding the = assisted > > TLB flush. Those selected flushes are the page type change (when > > switching from a page table type to a different one, ie: a page that > > has been removed as a page table) and page allocation. This sadly = has > > a negative performance impact on the pvshim, as less assisted = flushes > > can be used. Note the flush in grant-table code is also switched to > > use an IPI even when not strictly needed. This is done so that a > > common arch_flush_tlb_mask can be introduced and always used in = common > > code. > > > > Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB = flush > > using an IPI (flush_tlb_mask_sync, x86 only). Note that the flag is > > only meaningfully defined when the hypervisor supports PV or shadow > > paging mode, as otherwise hardware assisted paging domains are in > > charge of their page tables and won't share page tables with Xen, = thus > > not influencing the result of page walks performed by the spurious > > fault handler. > > > > Just passing this new flag when calling flush_area_mask prevents the > > usage of the assisted flush without any other side effects. > > > > Note the flag is not defined on Arm. > > > > Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when = available') > > Reported-by: Andrew Cooper > > Signed-off-by: Roger Pau Monn=C3=A9 >=20 > Acked-by: Julien Grall >=20 And... Release-acked-by: Paul Durrant From xen-devel-bounces@lists.xenproject.org Tue Jun 30 13:04:09 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 13:04:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFve-00038N-B7; Tue, 30 Jun 2020 13:04:02 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqFvc-00038I-Kn for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 13:04:00 +0000 X-Inumbo-ID: 29365518-bad2-11ea-bca7-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 29365518-bad2-11ea-bca7-bc764e2007e4; Tue, 30 Jun 2020 13:03:59 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: SmFXgo6Z9wuA3UXh/7Qd6NGLn4cCut5oS8NbKqkID7dSCrtmTDxZoUTXIVr/PXztvaJdWICsl+ nMM0Syc2UBjv0HS4MEZPg2RlYA8Irmx8Zah/WpGOs4dn68baAxDhsrrF/BzMz2D2vnXOZYN7LF UAZUnfYi5FZCsUxg37ekwvkRSQoutHvIeT4FUvtIPTBasLqpE4wySI4cRDez4RlqhCRuIWRomX Q6oZod9wrMPCbpfm0gGwIY8Pix6F+H6pLcTVKI/70uGouCr85HoO10tuWA3hPK4s5C4sGqQuG3 +sY= X-SBRS: 2.7 X-MesageID: 21277757 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,297,1589256000"; d="scan'208";a="21277757" Date: Tue, 30 Jun 2020 15:03:51 +0200 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Subject: Re: [PATCH for-4.14 v4] x86/tlb: fix assisted flush usage Message-ID: <20200630130351.GL735@Air-de-Roger> References: <20200626155723.91558-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: AMSPEX02CAS02.citrite.net (10.69.22.113) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , paul@xen.org, Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org, Volodymyr Babchuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 30, 2020 at 02:13:36PM +0200, Jan Beulich wrote: > On 26.06.2020 17:57, Roger Pau Monne wrote: > > Commit e9aca9470ed86 introduced a regression when avoiding sending > > IPIs for certain flush operations. Xen page fault handler > > (spurious_page_fault) relies on blocking interrupts in order to > > prevent handling TLB flush IPIs and thus preventing other CPUs from > > removing page tables pages. Switching to assisted flushing avoided such > > IPIs, and thus can result in pages belonging to the page tables being > > removed (and possibly re-used) while __page_fault_type is being > > executed. > > > > Force some of the TLB flushes to use IPIs, thus avoiding the assisted > > TLB flush. Those selected flushes are the page type change (when > > switching from a page table type to a different one, ie: a page that > > has been removed as a page table) and page allocation. This sadly has > > a negative performance impact on the pvshim, as less assisted flushes > > can be used. Note the flush in grant-table code is also switched to > > use an IPI even when not strictly needed. This is done so that a > > common arch_flush_tlb_mask can be introduced and always used in common > > code. > > > > Introduce a new flag (FLUSH_FORCE_IPI) and helper to force a TLB flush > > using an IPI (flush_tlb_mask_sync, x86 only). Note that the flag is > > only meaningfully defined when the hypervisor supports PV or shadow > > paging mode, as otherwise hardware assisted paging domains are in > > charge of their page tables and won't share page tables with Xen, thus > > not influencing the result of page walks performed by the spurious > > fault handler. > > > > Just passing this new flag when calling flush_area_mask prevents the > > usage of the assisted flush without any other side effects. > > > > Note the flag is not defined on Arm. > > > > Fixes: e9aca9470ed86 ('x86/tlb: use Xen L0 assisted TLB flush when available') > > Reported-by: Andrew Cooper > > Signed-off-by: Roger Pau Monné > > In principle > Reviewed-by: Jan Beulich > A few cosmetic remarks though: > > > --- a/xen/arch/x86/mm.c > > +++ b/xen/arch/x86/mm.c > > @@ -2894,7 +2894,17 @@ static int _get_page_type(struct page_info *page, unsigned long type, > > ((nx & PGT_type_mask) == PGT_writable_page)) ) > > { > > perfc_incr(need_flush_tlb_flush); > > - flush_tlb_mask(mask); > > + if ( (x & PGT_type_mask) && > > + (x & PGT_type_mask) <= PGT_root_page_table ) > > + /* > > + * If page was a page table make sure the flush is > > + * performed using an IPI in order to avoid changing > > + * the type of a page table page under the feet of > > + * spurious_page_fault. > > + */ > > + flush_tlb_mask_sync(mask); > > + else > > + flush_tlb_mask(mask); > > Effectively this now is the only user of the new macro. I'd prefer > avoiding its introduction (and hence avoiding the questionable > "_sync" suffix), doing > > flush_mask(mask, FLUSH_TLB | (... ? FLUSH_FORCE_IPI : 0)); Right, maybe placing the '(x & PGT_type_mask) && (x & PGT_type_mask) <= PGT_root_page_table' condition inside the parameter list of flush_mask will make the code hard to read, so it might be worth to keep the if? > here and ... > > > @@ -148,9 +158,24 @@ void flush_area_mask(const cpumask_t *, const void *va, unsigned int flags); > > /* Flush specified CPUs' TLBs */ > > #define flush_tlb_mask(mask) \ > > flush_mask(mask, FLUSH_TLB) > > +/* > > + * Flush specified CPUs' TLBs and force the usage of an IPI to do so. This is > > + * required for certain operations that rely on page tables themselves not > > + * being freed and reused when interrupts are blocked, as the flush IPI won't > > + * be fulfilled until exiting from that critical region. > > + */ > > +#define flush_tlb_mask_sync(mask) \ > > + flush_mask(mask, FLUSH_TLB | FLUSH_FORCE_IPI) > > #define flush_tlb_one_mask(mask,v) \ > > flush_area_mask(mask, (const void *)(v), FLUSH_TLB|FLUSH_ORDER(0)) > > > > +/* > > + * Alias the common code TLB flush helper to the sync one in order to be on the > > + * safe side. Note that not all calls from common code strictly require the > > + * _sync variant. > > + */ > > +#define arch_flush_tlb_mask flush_tlb_mask_sync > > ... > > #define arch_flush_tlb_mask(mask) \ > flush_mask(mask, FLUSH_TLB | FLUSH_FORCE_IPI) Sure. Feel free to slightly adjust the comment, I think doing s/Alias/Force/ would be enough. > here. I'd be okay making these adjustments while committing, if > you and others don't object. That's fine, I leave to your judgment whether to use the ternary operator in the _get_page_type case. Roger. From xen-devel-bounces@lists.xenproject.org Tue Jun 30 13:15:36 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 13:15:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqG6c-00041l-Dz; Tue, 30 Jun 2020 13:15:22 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqG6b-00041R-00 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 13:15:21 +0000 X-Inumbo-ID: bc888344-bad3-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id bc888344-bad3-11ea-b7bb-bc764e2007e4; Tue, 30 Jun 2020 13:15:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JI71WsBIrD3EU7SVdFpy13cYbkkGhwqO/Khf9QMRvak=; b=v0QwJyJ6jnB7M+QojzMzFEIeM aevASqrdSHRNadWUyG12LiuyCG5Glp7l6IqTh8BiAkwkGQn0k04Qz9w/X0UXio5rzcRMCVZXLaM/1 I4WieDucJ7MT/Fzjx13SqHpd+YqGMowIqBMyik+AJHUQs09UpHA4lJzE29Nn/W0f1Z1BA=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqG6V-0000gE-1l; Tue, 30 Jun 2020 13:15:15 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jqG6U-0005mZ-Nz; Tue, 30 Jun 2020 13:15:14 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jqG6U-0006CE-Mp; Tue, 30 Jun 2020 13:15:14 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable-smoke test] 151476: tolerable all pass - PUSHED X-Osstest-Failures: xen-unstable-smoke:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable-smoke:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: xen=23ca7ec0ba620db52a646d80e22f9703a6589f66 X-Osstest-Versions-That: xen=0e2e54966af556f4047c1048855c4a071028a32d From: osstest service owner Date: Tue, 30 Jun 2020 13:15:14 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151476 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/151476/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: xen 23ca7ec0ba620db52a646d80e22f9703a6589f66 baseline version: xen 0e2e54966af556f4047c1048855c4a071028a32d Last test of basis 151457 2020-06-29 17:01:22 Z 0 days Testing same since 151476 2020-06-30 11:00:51 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Olaf Hering jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-libvirt pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 0e2e54966a..23ca7ec0ba 23ca7ec0ba620db52a646d80e22f9703a6589f66 -> smoke From xen-devel-bounces@lists.xenproject.org Tue Jun 30 13:59:38 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 13:59:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqGnH-0007Mn-Rj; Tue, 30 Jun 2020 13:59:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqGnG-0007Mi-Nl for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 13:59:26 +0000 X-Inumbo-ID: e7e30e3c-bad9-11ea-bca7-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id e7e30e3c-bad9-11ea-bca7-bc764e2007e4; Tue, 30 Jun 2020 13:59:25 +0000 (UTC) Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: CdQDhhe/vltse0IAgZlqTjOb33oITBRQkWwnnAUWMqaDjQkGRd6MqEuQLO/+CTqMXjFgNhUWqB JQBFCCHtm1puW3hrPoIjtPK8ernonrSNiXM8VsGkdgzqFokXl+t43w61LqIv1NHI3ZZfZpWHuk 9VboYHAo/oukmhdxNbvsIf3tRDtl7Z1SClc12+m0i4kYRHmiUl5tuHkqDpnMmSSkMBySYTQjdy MTaGqtKs2CeNWNR+ARHaGj9+wIe/TIJbhnbzg+H/fCR14M0LRAER+lU6hYaKtoACQVCCA34/r4 0sE= X-SBRS: 2.7 X-MesageID: 21272894 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,297,1589256000"; d="scan'208";a="21272894" Date: Tue, 30 Jun 2020 14:59:21 +0100 From: Anthony PERARD To: Jason Andryuk Subject: Re: [PATCH] xen: Fix xen-legacy-backend qdev types Message-ID: <20200630135921.GB2030@perard.uk.xensource.com> References: <20200624121939.10282-1-jandryuk@gmail.com> <000a01d64a23$4a595e90$df0c1bb0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Stefano Stabellini , QEMU , Paul Durrant Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 08:52:44AM -0400, Jason Andryuk wrote: > On Wed, Jun 24, 2020 at 8:30 AM Paul Durrant wrote: > > > > > -----Original Message----- > > > From: Jason Andryuk > > > Sent: 24 June 2020 13:20 > > > To: Stefano Stabellini ; Anthony Perard ; Paul > > > Durrant ; xen-devel@lists.xenproject.org > > > Cc: Jason Andryuk ; qemu-devel@nongnu.org > > > Subject: [PATCH] xen: Fix xen-legacy-backend qdev types > > > > > > xen-sysdev is a TYPE_SYS_BUS_DEVICE. bus_type should not be changed so > > > that it can plug into the System bus. Otherwise this assert triggers: > > > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > > > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > > > failed. > > > > > > TYPE_XENBACKEND attaches to TYPE_XENSYSBUS, so its class_init needs to > > > be set accordingly to attach the qdev. Otherwise the following assert > > > triggers: > > > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > > > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > > > failed. > > > > > > TYPE_XENBACKEND is not a subclass of XEN_XENSYSDEV, so it's parent > > > is just TYPE_DEVICE. Change that. > > > > > > Signed-off-by: Jason Andryuk > > > > Clearly we raced. This patch and my patch #1 are identical so I'm happy to give my ack to this. > > Yeah, looks like you beat me by a hair :) > > Either way it gets fixed is fine by me. Since there's a choice to make, I think I'll take this patch, but I will add: Fixes: 81cb05732efb ("qdev: Assert devices are plugged into a bus that can take them") Thanks, -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Jun 30 14:37:54 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 14:37:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqHOB-0002Ho-1U; Tue, 30 Jun 2020 14:37:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqHO9-0002HU-Ga for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 14:37:33 +0000 X-Inumbo-ID: 37d3b77a-badf-11ea-8640-12813bfff9fa Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 37d3b77a-badf-11ea-8640-12813bfff9fa; Tue, 30 Jun 2020 14:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=90Yog8jfoQDINf42/azSEGka0LQkVk7MyVpGXd4jycs=; b=TaoqvlxIun8F06rd1NvELQBzA r9szVpIxUvDJnMYSW4btQhHkcVPFUu3VBlZV6s0+gByVzolOGm8Fv7LzVXiCnBtpLSfIuPUrJBJ4h 1+l1DslVgEx88LoU0hBm/sOlWmld3ybdD44oyfBgYb8AnpMx8LwgXg1mXEuMWtmv25lOI=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqHO2-0002Ez-3D; Tue, 30 Jun 2020 14:37:26 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jqHO1-0008Ri-NU; Tue, 30 Jun 2020 14:37:25 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jqHO1-0006d8-MN; Tue, 30 Jun 2020 14:37:25 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [linux-linus test] 151467: regressions - FAIL X-Osstest-Failures: linux-linus:test-arm64-arm64-libvirt-xsm:guest-start/debian.repeat:fail:regression linux-linus:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking linux-linus:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-i386-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking linux-linus:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking linux-linus:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking X-Osstest-Versions-This: linux=7c30b859a947535f2213277e827d7ac7dcff9c84 X-Osstest-Versions-That: linux=1b5044021070efa3259f3e9548dc35d1eb6aa844 From: osstest service owner Date: Tue, 30 Jun 2020 14:37:25 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151467 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/151467/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151214 test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151214 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151214 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151214 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151214 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass version targeted for testing: linux 7c30b859a947535f2213277e827d7ac7dcff9c84 baseline version: linux 1b5044021070efa3259f3e9548dc35d1eb6aa844 Last test of basis 151214 2020-06-18 02:27:46 Z 12 days Failing since 151236 2020-06-19 19:10:35 Z 10 days 13 attempts Testing same since 151467 2020-06-30 02:29:41 Z 0 days 1 attempts ------------------------------------------------------------ 478 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 22766 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 30 15:09:14 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 15:09:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqHsd-0004rN-KY; Tue, 30 Jun 2020 15:09:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqHsb-0004qr-Ix for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 15:09:01 +0000 X-Inumbo-ID: 9ffd562c-bae3-11ea-b7bb-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 9ffd562c-bae3-11ea-b7bb-bc764e2007e4; Tue, 30 Jun 2020 15:08:59 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: OjpqnZo3XH7g7b87jmn7DyAGGy6bnb1vG0VaLDdwnbRe5viygiv6JcLiAhoVymBXSaSdifaKYW bu0yCX7KWl3TJWfIEmK9avXh/VBUr6kY2qjK36Fhl+ov/GVYjrQdWlcZjEwZbCuQvvEXoNC1DX uFgiDiABsgJwowLWz9ZYhrlqb/o5mUsCSgMw/LRuw7UfHl+SUQoBXSlKUfYBXoyhPnE2ud8a3U wNQQ83m4aRjNZbCYpsogUZkLpa/mDZfMfOkrXd+R3XWBTTuyXg27l+UEIkPf8F1lI5KZzaKOJ2 sPg= X-SBRS: 2.7 X-MesageID: 21294008 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,297,1589256000"; d="scan'208";a="21294008" Date: Tue, 30 Jun 2020 16:08:49 +0100 From: Anthony PERARD To: Paul Durrant Subject: Re: [PATCH 2/2] xen: cleanup unrealized flash devices Message-ID: <20200630150849.GA2110@perard.uk.xensource.com> References: <20200624121841.17971-1-paul@xen.org> <20200624121841.17971-3-paul@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200624121841.17971-3-paul@xen.org> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Eduardo Habkost , "Michael S. Tsirkin" , Paul Durrant , Jason Andryuk , qemu-devel@nongnu.org, Paolo Bonzini , xen-devel@lists.xenproject.org, Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, Jun 24, 2020 at 01:18:41PM +0100, Paul Durrant wrote: > From: Paul Durrant > > The generic pc_machine_initfn() calls pc_system_flash_create() which creates > 'system.flash0' and 'system.flash1' devices. These devices are then realized > by pc_system_flash_map() which is called from pc_system_firmware_init() which > itself is called via pc_memory_init(). The latter however is not called when > xen_enable() is true and hence the following assertion fails: > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > Assertion `dev->realized' failed > > These flash devices are unneeded when using Xen so this patch avoids the > assertion by simply removing them using pc_system_flash_cleanup_unused(). > > Reported-by: Jason Andryuk > Fixes: ebc29e1beab0 ("pc: Support firmware configuration with -blockdev") > Signed-off-by: Paul Durrant > Tested-by: Jason Andryuk Reviewed-by: Anthony PERARD I think I would add: Fixes: dfe8c79c4468 ("qdev: Assert onboard devices all get realized properly") as this is the first commit where the unrealized flash devices are an issue. -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Jun 30 15:17:20 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 15:17:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqI0Z-0005hW-Ee; Tue, 30 Jun 2020 15:17:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqI0Y-0005hR-LL for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 15:17:14 +0000 X-Inumbo-ID: c693eda4-bae4-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x331.google.com (unknown [2a00:1450:4864:20::331]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c693eda4-bae4-11ea-b7bb-bc764e2007e4; Tue, 30 Jun 2020 15:17:14 +0000 (UTC) Received: by mail-wm1-x331.google.com with SMTP id w3so7522349wmi.4 for ; Tue, 30 Jun 2020 08:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=U6gpWx6s17H1M9VJ6Oh9vPNBpxTYgr9zPk06ZNP9duI=; b=Ja3Hoc6gm808R+iiHXJ+YTAB271DNWOUMLTS3qsKPBA7ZFG3UVpjeCbmkTMVW/MmmS udqS+4mb3AruFaeVOe0C1raIYsMTMceHOAnlWJJuMLTmY87Z0vXABnTM335EqBF9tT1Q NzE0qFz2yvj+xh39kjoODv61pD10rsrqDAxgZABMBIwu8dBOabU7Gs4wxsWLNiIrUwhZ kzFSeIakj5PM4qlq4H8sdRLeOHdcQjgwUdBJ0b0eLdqn6EBP1UuqdP1aHYem9B7FtvCL XNln51//kteHAqh2OuA5CRnQH7n0GV2dcinLuyUabbNegMRIQ/MkZX7rb/m/r21kcm6I NDAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :thread-index:content-language; bh=U6gpWx6s17H1M9VJ6Oh9vPNBpxTYgr9zPk06ZNP9duI=; b=L3ym1ZbwJUMA9jBxNRw2oHcU5O+lY0AUD5Hx/mGMe4PF6dsLa7+EY4vJGqPfp7hR2a g7Jd15oRvl3D/Z+8jx4bwrJnIpG0KOgIbJd42GDcPKIGKdtWZvWlgKTTI6Kmzwr5/I42 LwArqaMw8DhERl9aqkm8caQOTTGMMJCmj7MvfPapX0lw68oYfvSVj9V+Iu5y+QSQ+GCs Xdaikn3FrXZwo/ryH3jbFJS42D3yHs5apBp/44Xl+I5mD4ODq34gnF4trtE5FdTgcYeo CLB34VLiNL/gXwXemuYI2+b7YhE54qeNMGYcjb93NlsiCm3CSCrz1TM4au2zzdrIp5+I iltA== X-Gm-Message-State: AOAM531nBWHS5mYBN/jHpjYfj4wzn6vWaNwJTLOVqbNy8vgBtE3bf4aw 8hzZd0tGvnSN2RxGv/dPmoE= X-Google-Smtp-Source: ABdhPJz5rAGiFZIDrdJqvVJJ5HKWQXmPiwBmtxY124AwSoiwMS1+l2nVEKBvptNnZcYRRS1epYZK1A== X-Received: by 2002:a7b:c348:: with SMTP id l8mr23780539wmj.54.1593530233192; Tue, 30 Jun 2020 08:17:13 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-230.amazon.com. [54.240.197.230]) by smtp.gmail.com with ESMTPSA id j41sm4207738wre.12.2020.06.30.08.17.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 08:17:12 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: "'Anthony PERARD'" References: <20200624121841.17971-1-paul@xen.org> <20200624121841.17971-3-paul@xen.org> <20200630150849.GA2110@perard.uk.xensource.com> In-Reply-To: <20200630150849.GA2110@perard.uk.xensource.com> Subject: RE: [PATCH 2/2] xen: cleanup unrealized flash devices Date: Tue, 30 Jun 2020 16:17:11 +0100 Message-ID: <000401d64ef1$87c8d8a0$975a89e0$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJSqy6H9p+wwq7WTKLIQgTsJ4xkIwGyH0+lAR9Jc9Sn4gFdsA== Content-Language: en-gb X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Eduardo Habkost' , "'Michael S. Tsirkin'" , 'Paul Durrant' , 'Jason Andryuk' , qemu-devel@nongnu.org, 'Paolo Bonzini' , xen-devel@lists.xenproject.org, 'Richard Henderson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Anthony PERARD > Sent: 30 June 2020 16:09 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; qemu-devel@nongnu.org; Eduardo Habkost ; > Michael S. Tsirkin ; Paul Durrant ; Jason Andryuk > ; Paolo Bonzini ; Richard Henderson > Subject: Re: [PATCH 2/2] xen: cleanup unrealized flash devices > > On Wed, Jun 24, 2020 at 01:18:41PM +0100, Paul Durrant wrote: > > From: Paul Durrant > > > > The generic pc_machine_initfn() calls pc_system_flash_create() which creates > > 'system.flash0' and 'system.flash1' devices. These devices are then realized > > by pc_system_flash_map() which is called from pc_system_firmware_init() which > > itself is called via pc_memory_init(). The latter however is not called when > > xen_enable() is true and hence the following assertion fails: > > > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > > Assertion `dev->realized' failed > > > > These flash devices are unneeded when using Xen so this patch avoids the > > assertion by simply removing them using pc_system_flash_cleanup_unused(). > > > > Reported-by: Jason Andryuk > > Fixes: ebc29e1beab0 ("pc: Support firmware configuration with -blockdev") > > Signed-off-by: Paul Durrant > > Tested-by: Jason Andryuk > > Reviewed-by: Anthony PERARD > > I think I would add: > > Fixes: dfe8c79c4468 ("qdev: Assert onboard devices all get realized properly") > > as this is the first commit where the unrealized flash devices are an > issue. OK. Paul > > -- > Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Jun 30 15:20:07 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 15:20:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqI3I-0006Fk-Sx; Tue, 30 Jun 2020 15:20:04 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqI3H-00062X-HB for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 15:20:04 +0000 X-Inumbo-ID: 2ad5f906-bae5-11ea-864a-12813bfff9fa Received: from us-smtp-1.mimecast.com (unknown [205.139.110.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 2ad5f906-bae5-11ea-864a-12813bfff9fa; Tue, 30 Jun 2020 15:20:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593530401; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=3Q68uV4NKCffVlEx9DmYr8Tcy2UpV4TM2zGQR62nl10=; b=EeNwzWoKOg0m2RVZu6dcT/Ll34IavyPy5Qf0pYYznrMqsq5Itgd/VOyOCGlLA4KOf0W33T JzD6TjJpzpoUhWRv7U37UrgHu7OLgwEPigNRcWXySnmstZiBNMpj71TS850bBBAESJLGfb +nKOpr2EM7VaTlkl78IZ3TZKQwj4wPk= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-44-6gHfxwZ-M3Cs-gVDEWjYDw-1; Tue, 30 Jun 2020 11:19:56 -0400 X-MC-Unique: 6gHfxwZ-M3Cs-gVDEWjYDw-1 Received: by mail-ed1-f71.google.com with SMTP id v8so10500734edj.4 for ; Tue, 30 Jun 2020 08:19:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=3Q68uV4NKCffVlEx9DmYr8Tcy2UpV4TM2zGQR62nl10=; b=FBT/ntQWWgiQukk2ZNfXA7Wnof5ytcV5wEfq0TQ+EsfeTsXOwwKonGs/JIP4j5wwMd nOCB0hOL7IJyeiqEv6HnY9v1BMXptIPEaiWhMR6Azqq3s2cKR4OxKCaUJmdUajQB8AuN mQgCX65euqQQNLWU+TKXys/Can/FYCCFRAqGfUAy8RHIFawx5aWZMWQow3e3XABMVpeu oJLppjXmhxRXb9QCiQhd6CeyehB4FnJkTXhrsB5EWg1TWDwOoDgQcbRv0Bx8eEX97Q5H /6npUj7hX/SeIldOgi32968HiMz2qHAStZeyVXrHFatrkih/grT+te3dxP2TH20hL1He d2Aw== X-Gm-Message-State: AOAM533OvJTbSJsekHS2J0QVdbVZW4pvDIkCTr9bJiUm9fYaSX+JemE2 dz1ByklWlRvgjGoI0VVt/3T592NtX0TNhZCmptJ/NsbhKA3AI74cyWe42fftfcICaUtGFK1JOrw O3wrrk/xx9l06T4dWXfWP/96Qk34= X-Received: by 2002:a17:906:4086:: with SMTP id u6mr20093275ejj.9.1593530395530; Tue, 30 Jun 2020 08:19:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx968WRLbUisR+Ua1av2ZFZrg5txPJ4uxePXOJef4L9Vgi/0Ql6VBEd7JzAxiIPxCPm9IU36A== X-Received: by 2002:a17:906:4086:: with SMTP id u6mr20093262ejj.9.1593530395330; Tue, 30 Jun 2020 08:19:55 -0700 (PDT) Received: from [192.168.1.40] (1.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.1]) by smtp.gmail.com with ESMTPSA id k15sm2231802eji.49.2020.06.30.08.19.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 08:19:54 -0700 (PDT) Subject: Re: [PATCH 1/2] xen: fix legacy 'xen-sysdev' and 'xen-backend' bus types To: Paul Durrant , xen-devel@lists.xenproject.org, qemu-devel@nongnu.org References: <20200624121841.17971-1-paul@xen.org> <20200624121841.17971-2-paul@xen.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: Date: Tue, 30 Jun 2020 17:19:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200624121841.17971-2-paul@xen.org> Content-Language: en-US Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=philmd@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Anthony Perard , Paul Durrant , Stefano Stabellini , Jason Andryuk Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/24/20 2:18 PM, Paul Durrant wrote: > From: Paul Durrant > > 'xen-sysdev' plugs into the 'System' bus type, not 'xen-sysbus. That bus type > is what 'xen-backend' plugs into. > 'xen-sysdev' is drived form 'sys-bus-device' so the bus type need not be > overridden. 'xen-backend' is derived from 'device', which plugs into the > generic 'bus' type, so its bus type should be overridden to 'xen-sysbus'. > > Without this patch, the following assertion will fail: > > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)' > failed. > > Reported-by: Jason Andryuk > Fixes: 81cb05732efb ("qdev: Assert devices are plugged into a bus that can take them") > Signed-off-by: Paul Durrant > --- > Cc: Stefano Stabellini > Cc: Anthony Perard > --- > hw/xen/xen-legacy-backend.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/xen/xen-legacy-backend.c b/hw/xen/xen-legacy-backend.c > index 2335ee2e65..c5c75c0064 100644 > --- a/hw/xen/xen-legacy-backend.c > +++ b/hw/xen/xen-legacy-backend.c > @@ -789,11 +789,12 @@ static void xendev_class_init(ObjectClass *klass, void *data) > set_bit(DEVICE_CATEGORY_MISC, dc->categories); > /* xen-backend devices can be plugged/unplugged dynamically */ > dc->user_creatable = true; > + dc->bus_type = TYPE_XENSYSBUS; > } > > static const TypeInfo xendev_type_info = { > .name = TYPE_XENBACKEND, > - .parent = TYPE_XENSYSDEV, > + .parent = TYPE_DEVICE, > .class_init = xendev_class_init, > .instance_size = sizeof(struct XenLegacyDevice), > }; > @@ -824,7 +825,6 @@ static void xen_sysdev_class_init(ObjectClass *klass, void *data) > DeviceClass *dc = DEVICE_CLASS(klass); > > device_class_set_props(dc, xen_sysdev_properties); > - dc->bus_type = TYPE_XENSYSBUS; > } > > static const TypeInfo xensysdev_info = { > Reviewed-by: Philippe Mathieu-Daudé From xen-devel-bounces@lists.xenproject.org Tue Jun 30 15:26:08 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 15:26:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqI93-0006eJ-Mi; Tue, 30 Jun 2020 15:26:01 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqI91-0006eE-Q4 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 15:25:59 +0000 X-Inumbo-ID: ff73de4f-bae5-11ea-864e-12813bfff9fa Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id ff73de4f-bae5-11ea-864e-12813bfff9fa; Tue, 30 Jun 2020 15:25:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593530758; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=TgmQ2qPZaMql3FNmjFEGdsNRy1PraDve/uxYO4ofKOE=; b=EivupubK8RjURwFAMTEwZKMfp/TVPtf0tcxQIyyzbGWUDWesqmw1WNacJvUdDKTLCLc3IU cPjsDQbTdX2i8unJDIRwV5utchCbiJNULb+3pj+4tGuju744N24KPQK5ZdLUcHb2uBCdiX 9GdQcucJaDZ37bBl7iL5+igbsO6huHw= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-295-_cgXzliRO2qif8QcNEdxAQ-1; Tue, 30 Jun 2020 11:25:56 -0400 X-MC-Unique: _cgXzliRO2qif8QcNEdxAQ-1 Received: by mail-ed1-f72.google.com with SMTP id h5so17329664edl.7 for ; Tue, 30 Jun 2020 08:25:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=TgmQ2qPZaMql3FNmjFEGdsNRy1PraDve/uxYO4ofKOE=; b=m7Jyjw687RhBWZFiLGqpvAe5Xrh+1xOr5Jn7VE1ifsJ0Qqh4wkzsgwcGuWPHSAQuIe gT2agG1BHSDJfUBQTiYcX8quYSr3ouKQ6Timp9mcITQviBHm5UvniCitTqLWT2E51b4t X3Y09ePZt2cJLgJN+UkpHZ4nAtzEiSS/0GTyexjKo0OYmUy86/DAv9CbqCQQeVfQA58w LofCmn2XrUUlNyLNdJO5//EkdP778/S/9WrMWICRK4KI5FiB2c8PUX406YtQZNndZmHN /zC8Xs1vA+84U8jFYGYJ4YjWgNiufuvo4fZR5rU+gJsE5R/gBsr5EAb4QRqOlp7zpWMh 7uCw== X-Gm-Message-State: AOAM532V4U2ET1czHegp0BOBS5gr6nqGzxPwo4YzMC4uDQJ9YKvRgWys 60dywrKfkxs+HSbSsU9PF1BPJkTICWmh2i3B9ur3zzqde0Hv5NBJIM21sLTc5Pm4mD7ftZqCRRY 8dikW5uJmPUXk09l1ed5S4TqmynM= X-Received: by 2002:aa7:d049:: with SMTP id n9mr16524092edo.39.1593530755308; Tue, 30 Jun 2020 08:25:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5tYsh8vTJLx6oVLu+kxWJAfWgGHr3oq2bkuchH0QACjfzGcYkSC7JX+uAed7ZNz1+qmaYuQ== X-Received: by 2002:aa7:d049:: with SMTP id n9mr16524086edo.39.1593530755146; Tue, 30 Jun 2020 08:25:55 -0700 (PDT) Received: from [192.168.1.40] (1.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.1]) by smtp.gmail.com with ESMTPSA id s1sm3242130edy.1.2020.06.30.08.25.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 08:25:54 -0700 (PDT) Subject: Re: [PATCH 2/2] xen: cleanup unrealized flash devices To: Paul Durrant , xen-devel@lists.xenproject.org, qemu-devel@nongnu.org References: <20200624121841.17971-1-paul@xen.org> <20200624121841.17971-3-paul@xen.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: <33e594dd-dbfa-7c57-1cf5-0852e8fc8e1d@redhat.com> Date: Tue, 30 Jun 2020 17:25:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200624121841.17971-3-paul@xen.org> Content-Language: en-US Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=philmd@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Eduardo Habkost , Jason Andryuk , Paul Durrant , "Michael S. Tsirkin" , Paolo Bonzini , Richard Henderson Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/24/20 2:18 PM, Paul Durrant wrote: > From: Paul Durrant > > The generic pc_machine_initfn() calls pc_system_flash_create() which creates > 'system.flash0' and 'system.flash1' devices. These devices are then realized > by pc_system_flash_map() which is called from pc_system_firmware_init() which > itself is called via pc_memory_init(). The latter however is not called when > xen_enable() is true and hence the following assertion fails: > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > Assertion `dev->realized' failed > > These flash devices are unneeded when using Xen so this patch avoids the > assertion by simply removing them using pc_system_flash_cleanup_unused(). > > Reported-by: Jason Andryuk > Fixes: ebc29e1beab0 ("pc: Support firmware configuration with -blockdev") > Signed-off-by: Paul Durrant > Tested-by: Jason Andryuk > --- > Cc: Paolo Bonzini > Cc: Richard Henderson > Cc: Eduardo Habkost > Cc: "Michael S. Tsirkin" > Cc: Marcel Apfelbaum > --- > hw/i386/pc_piix.c | 9 ++++++--- > hw/i386/pc_sysfw.c | 2 +- > include/hw/i386/pc.h | 1 + > 3 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > index 1497d0e4ae..977d40afb8 100644 > --- a/hw/i386/pc_piix.c > +++ b/hw/i386/pc_piix.c > @@ -186,9 +186,12 @@ static void pc_init1(MachineState *machine, > if (!xen_enabled()) { > pc_memory_init(pcms, system_memory, > rom_memory, &ram_memory); > - } else if (machine->kernel_filename != NULL) { > - /* For xen HVM direct kernel boot, load linux here */ > - xen_load_linux(pcms); > + } else { > + pc_system_flash_cleanup_unused(pcms); TIL pc_system_flash_cleanup_unused(). What about restricting at the source? -- >8 -- --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1004,24 +1004,26 @@ void pc_memory_init(PCMachineState *pcms, &machine->device_memory->mr); } - /* Initialize PC system firmware */ - pc_system_firmware_init(pcms, rom_memory); - - option_rom_mr = g_malloc(sizeof(*option_rom_mr)); - memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE, - &error_fatal); - if (pcmc->pci_enabled) { - memory_region_set_readonly(option_rom_mr, true); - } - memory_region_add_subregion_overlap(rom_memory, - PC_ROM_MIN_VGA, - option_rom_mr, - 1); - fw_cfg = fw_cfg_arch_create(machine, x86ms->boot_cpus, x86ms->apic_id_limit); - rom_set_fw(fw_cfg); + /* Initialize PC system firmware */ + if (!xen_enabled()) { + pc_system_firmware_init(pcms, rom_memory); + + option_rom_mr = g_malloc(sizeof(*option_rom_mr)); + memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE, + &error_fatal); + if (pcmc->pci_enabled) { + memory_region_set_readonly(option_rom_mr, true); + } + memory_region_add_subregion_overlap(rom_memory, + PC_ROM_MIN_VGA, + option_rom_mr, + 1); + + rom_set_fw(fw_cfg); + } if (pcmc->has_reserved_memory && machine->device_memory->base) { uint64_t *val = g_malloc(sizeof(*val)); --- > + if (machine->kernel_filename != NULL) { > + /* For xen HVM direct kernel boot, load linux here */ > + xen_load_linux(pcms); > + } > } > > gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled); > diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c > index ec2a3b3e7e..0ff47a4b59 100644 > --- a/hw/i386/pc_sysfw.c > +++ b/hw/i386/pc_sysfw.c > @@ -108,7 +108,7 @@ void pc_system_flash_create(PCMachineState *pcms) > } > } > > -static void pc_system_flash_cleanup_unused(PCMachineState *pcms) > +void pc_system_flash_cleanup_unused(PCMachineState *pcms) > { > char *prop_name; > int i; > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h > index e6135c34d6..497f2b7ab7 100644 > --- a/include/hw/i386/pc.h > +++ b/include/hw/i386/pc.h > @@ -187,6 +187,7 @@ int cmos_get_fd_drive_type(FloppyDriveType fd0); > > /* pc_sysfw.c */ > void pc_system_flash_create(PCMachineState *pcms); > +void pc_system_flash_cleanup_unused(PCMachineState *pcms); > void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory); > > /* acpi-build.c */ > From xen-devel-bounces@lists.xenproject.org Tue Jun 30 15:45:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 15:45:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqIRN-0008K6-9r; Tue, 30 Jun 2020 15:44:57 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqIRM-0008K1-5R for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 15:44:56 +0000 X-Inumbo-ID: a4368060-bae8-11ea-bb8b-bc764e2007e4 Received: from mail-ed1-x542.google.com (unknown [2a00:1450:4864:20::542]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a4368060-bae8-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 15:44:54 +0000 (UTC) Received: by mail-ed1-x542.google.com with SMTP id d18so11032031edv.6 for ; Tue, 30 Jun 2020 08:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=GY90tjVc3dz3ZsYcA/otGwLV4gaxfByMnXZMah28RCM=; b=KuF0autV0BsLguYgjnHsgWoAnaa4mDiKSUzaCjUmpj62bWNbJXo58zboack4wN2CT8 hatf6w0t4Cb/x9IrjwEujJ9a45QMyNGn8RTWuqUQ1i40RXfA1yHNrs+x16BVVedQzlhX OzLLKt/Qz7AFlM3WWKx98ttfyE2Vw3jakDCAw5JRclz15qqfnVM2s6ENUrEuF0RIGYqM U5MYdGpInUpFGJWFZn4C7EVCXgeYBkB3Pe8DD7swPyBxOovROF+qQUAUyut6a1NzJE4h 8cZJLl+DDEwWlQ3fpiW7WMmlJjvMZJHEUSyTvcQKt8BD04stj3wETGCvbOrCiJpC/M0d b3/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:to:cc:references:in-reply-to :subject:date:message-id:mime-version:content-transfer-encoding :thread-index:content-language; bh=GY90tjVc3dz3ZsYcA/otGwLV4gaxfByMnXZMah28RCM=; b=RlNb1zAqyAHI1eX4E3T7t+UzO8BDirpI3qB4RJsQ2k7ncIsKEC1pDWzPbG2/r9tgfE 7AuOeluRc1iko6lB+3wPKTEDbfPSdYxtvpjzHnjJyTwEvUochNmDHbrEJuWrmpDyGXeP r87I8QnXW1cAMPZ6hVZyNuxtOLGejlRZvzUYHbXdXRtZ0ofCCawoY8jXq9aSB6E3MdzE suHucQ5gCPo9K03rOyxbE0IKhlGRsMMSFrACwwXReLq2k8Lye+zuqqQIoY0fCqYjs6K3 bpXK+gy5OEOD3mrlBIzVxxPtqfgb0gea14ZcNUx/ERkD+S0sVFXQOV2pJQmA0eKZsrMn Aj/A== X-Gm-Message-State: AOAM532kNmIsgY8AG2LyvwHLYMQb0+/RGdetZMBfujtORU5omi42cErn acv82AekSp0wBAbz6/hk6xiw5ALP/iQ= X-Google-Smtp-Source: ABdhPJzHUnxWh8qjel8nZAx7oK8ZduyhLvOGu/Q7Ix5WOT1Z1L/O9SkYMq9n24/rDbpkNha4B8/RJQ== X-Received: by 2002:aa7:c987:: with SMTP id c7mr23163919edt.268.1593531893554; Tue, 30 Jun 2020 08:44:53 -0700 (PDT) Received: from CBGR90WXYV0 (54-240-197-238.amazon.com. [54.240.197.238]) by smtp.gmail.com with ESMTPSA id x10sm2397768ejc.46.2020.06.30.08.44.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jun 2020 08:44:52 -0700 (PDT) From: Paul Durrant X-Google-Original-From: "Paul Durrant" To: =?utf-8?Q?'Philippe_Mathieu-Daud=C3=A9'?= , , References: <20200624121841.17971-1-paul@xen.org> <20200624121841.17971-3-paul@xen.org> <33e594dd-dbfa-7c57-1cf5-0852e8fc8e1d@redhat.com> In-Reply-To: <33e594dd-dbfa-7c57-1cf5-0852e8fc8e1d@redhat.com> Subject: RE: [PATCH 2/2] xen: cleanup unrealized flash devices Date: Tue, 30 Jun 2020 16:44:51 +0100 Message-ID: <000701d64ef5$6568f660$303ae320$@xen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJSqy6H9p+wwq7WTKLIQgTsJ4xkIwGyH0+lAvluRd+n0zP24A== Content-Language: en-gb X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: paul@xen.org Cc: 'Eduardo Habkost' , 'Jason Andryuk' , 'Paul Durrant' , "'Michael S. Tsirkin'" , 'Paolo Bonzini' , 'Richard Henderson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" > -----Original Message----- > From: Philippe Mathieu-Daud=C3=A9 > Sent: 30 June 2020 16:26 > To: Paul Durrant ; xen-devel@lists.xenproject.org; = qemu-devel@nongnu.org > Cc: Eduardo Habkost ; Michael S. Tsirkin = ; Paul Durrant > ; Jason Andryuk ; Paolo = Bonzini ; > Richard Henderson > Subject: Re: [PATCH 2/2] xen: cleanup unrealized flash devices >=20 > On 6/24/20 2:18 PM, Paul Durrant wrote: > > From: Paul Durrant > > > > The generic pc_machine_initfn() calls pc_system_flash_create() which = creates > > 'system.flash0' and 'system.flash1' devices. These devices are then = realized > > by pc_system_flash_map() which is called from = pc_system_firmware_init() which > > itself is called via pc_memory_init(). The latter however is not = called when > > xen_enable() is true and hence the following assertion fails: > > > > qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: > > Assertion `dev->realized' failed > > > > These flash devices are unneeded when using Xen so this patch avoids = the > > assertion by simply removing them using = pc_system_flash_cleanup_unused(). > > > > Reported-by: Jason Andryuk > > Fixes: ebc29e1beab0 ("pc: Support firmware configuration with = -blockdev") > > Signed-off-by: Paul Durrant > > Tested-by: Jason Andryuk > > --- > > Cc: Paolo Bonzini > > Cc: Richard Henderson > > Cc: Eduardo Habkost > > Cc: "Michael S. Tsirkin" > > Cc: Marcel Apfelbaum > > --- > > hw/i386/pc_piix.c | 9 ++++++--- > > hw/i386/pc_sysfw.c | 2 +- > > include/hw/i386/pc.h | 1 + > > 3 files changed, 8 insertions(+), 4 deletions(-) > > > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c > > index 1497d0e4ae..977d40afb8 100644 > > --- a/hw/i386/pc_piix.c > > +++ b/hw/i386/pc_piix.c > > @@ -186,9 +186,12 @@ static void pc_init1(MachineState *machine, > > if (!xen_enabled()) { > > pc_memory_init(pcms, system_memory, > > rom_memory, &ram_memory); > > - } else if (machine->kernel_filename !=3D NULL) { > > - /* For xen HVM direct kernel boot, load linux here */ > > - xen_load_linux(pcms); > > + } else { > > + pc_system_flash_cleanup_unused(pcms); >=20 > TIL pc_system_flash_cleanup_unused(). >=20 > What about restricting at the source? > And leave the devices in place? They are not relevant for Xen, so why = not clean up? Paul =20 > -- >8 -- > --- a/hw/i386/pc.c > +++ b/hw/i386/pc.c > @@ -1004,24 +1004,26 @@ void pc_memory_init(PCMachineState *pcms, > &machine->device_memory->mr); > } >=20 > - /* Initialize PC system firmware */ > - pc_system_firmware_init(pcms, rom_memory); > - > - option_rom_mr =3D g_malloc(sizeof(*option_rom_mr)); > - memory_region_init_ram(option_rom_mr, NULL, "pc.rom", = PC_ROM_SIZE, > - &error_fatal); > - if (pcmc->pci_enabled) { > - memory_region_set_readonly(option_rom_mr, true); > - } > - memory_region_add_subregion_overlap(rom_memory, > - PC_ROM_MIN_VGA, > - option_rom_mr, > - 1); > - > fw_cfg =3D fw_cfg_arch_create(machine, > x86ms->boot_cpus, = x86ms->apic_id_limit); >=20 > - rom_set_fw(fw_cfg); > + /* Initialize PC system firmware */ > + if (!xen_enabled()) { > + pc_system_firmware_init(pcms, rom_memory); > + > + option_rom_mr =3D g_malloc(sizeof(*option_rom_mr)); > + memory_region_init_ram(option_rom_mr, NULL, "pc.rom", = PC_ROM_SIZE, > + &error_fatal); > + if (pcmc->pci_enabled) { > + memory_region_set_readonly(option_rom_mr, true); > + } > + memory_region_add_subregion_overlap(rom_memory, > + PC_ROM_MIN_VGA, > + option_rom_mr, > + 1); > + > + rom_set_fw(fw_cfg); > + } >=20 > if (pcmc->has_reserved_memory && machine->device_memory->base) { > uint64_t *val =3D g_malloc(sizeof(*val)); > --- >=20 > > + if (machine->kernel_filename !=3D NULL) { > > + /* For xen HVM direct kernel boot, load linux here */ > > + xen_load_linux(pcms); > > + } > > } > > > > gsi_state =3D pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled); > > diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c > > index ec2a3b3e7e..0ff47a4b59 100644 > > --- a/hw/i386/pc_sysfw.c > > +++ b/hw/i386/pc_sysfw.c > > @@ -108,7 +108,7 @@ void pc_system_flash_create(PCMachineState = *pcms) > > } > > } > > > > -static void pc_system_flash_cleanup_unused(PCMachineState *pcms) > > +void pc_system_flash_cleanup_unused(PCMachineState *pcms) > > { > > char *prop_name; > > int i; > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h > > index e6135c34d6..497f2b7ab7 100644 > > --- a/include/hw/i386/pc.h > > +++ b/include/hw/i386/pc.h > > @@ -187,6 +187,7 @@ int cmos_get_fd_drive_type(FloppyDriveType fd0); > > > > /* pc_sysfw.c */ > > void pc_system_flash_create(PCMachineState *pcms); > > +void pc_system_flash_cleanup_unused(PCMachineState *pcms); > > void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion = *rom_memory); > > > > /* acpi-build.c */ > > From xen-devel-bounces@lists.xenproject.org Tue Jun 30 16:23:44 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 16:23:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqJ2l-0003hD-Ag; Tue, 30 Jun 2020 16:23:35 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqJ2j-0003h8-UF for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 16:23:33 +0000 X-Inumbo-ID: 0a1e3b98-baee-11ea-865a-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 0a1e3b98-baee-11ea-865a-12813bfff9fa; Tue, 30 Jun 2020 16:23:32 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id EC75AADE4; Tue, 30 Jun 2020 16:23:31 +0000 (UTC) Subject: Re: [PATCH v4 01/10] x86/vmx: add Intel PT MSR definitions To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= References: <2ff9ecee8367e814a29b17a34203bda0e3c48d74.1593519420.git.michal.leszczynski@cert.pl> From: Jan Beulich Message-ID: Date: Tue, 30 Jun 2020 18:23:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <2ff9ecee8367e814a29b17a34203bda0e3c48d74.1593519420.git.michal.leszczynski@cert.pl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: tamas.lengyel@intel.com, Wei Liu , Andrew Cooper , luwei.kang@intel.com, xen-devel@lists.xenproject.org, =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 30.06.2020 14:33, Michał Leszczyński wrote: > From: Michal Leszczynski > > Define constants related to Intel Processor Trace features. > > Signed-off-by: Michal Leszczynski This needs re-basing onto current staging, now that Andrew's patch to add the MSR numbers has gone in. Apart from this a couple of cosmetic requests: > --- a/xen/include/asm-x86/msr-index.h > +++ b/xen/include/asm-x86/msr-index.h > @@ -69,6 +69,43 @@ > #define MSR_MCU_OPT_CTRL 0x00000123 > #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) > > +/* Intel PT MSRs */ > +#define MSR_RTIT_OUTPUT_BASE 0x00000560 > + > +#define MSR_RTIT_OUTPUT_MASK 0x00000561 > + > +#define MSR_RTIT_CTL 0x00000570 > +#define RTIT_CTL_TRACEEN (_AC(1, ULL) << 0) The right side is indented one space too many - see the similar #define in context above. > +#define RTIT_CTL_CYCEN (_AC(1, ULL) << 1) > +#define RTIT_CTL_OS (_AC(1, ULL) << 2) > +#define RTIT_CTL_USR (_AC(1, ULL) << 3) > +#define RTIT_CTL_PWR_EVT_EN (_AC(1, ULL) << 4) > +#define RTIT_CTL_FUP_ON_PTW (_AC(1, ULL) << 5) > +#define RTIT_CTL_FABRIC_EN (_AC(1, ULL) << 6) > +#define RTIT_CTL_CR3_FILTER (_AC(1, ULL) << 7) > +#define RTIT_CTL_TOPA (_AC(1, ULL) << 8) > +#define RTIT_CTL_MTC_EN (_AC(1, ULL) << 9) > +#define RTIT_CTL_TSC_EN (_AC(1, ULL) << 10) The double blanks on the earlier lines exist such that here you can reduce to a single one. You'll also find examples of this further up in the file. > +#define RTIT_CTL_DIS_RETC (_AC(1, ULL) << 11) > +#define RTIT_CTL_PTW_EN (_AC(1, ULL) << 12) > +#define RTIT_CTL_BRANCH_EN (_AC(1, ULL) << 13) > +#define RTIT_CTL_MTC_FREQ (_AC(0x0F, ULL) << 14) 0xf please (i.e. lower case and no random number of leading zeros). > +#define RTIT_CTL_CYC_THRESH (_AC(0x0F, ULL) << 19) > +#define RTIT_CTL_PSB_FREQ (_AC(0x0F, ULL) << 24) > +#define RTIT_CTL_ADDR(n) (_AC(0x0F, ULL) << (32 + (4 * (n)))) Strictly speaking we don't need the parentheses around the operands of binary * here - in mathematics precedence between + and * is well defined. (We do parenthesize certain other expressions, when the precedence may not be as well known.) Thanks, Jan From xen-devel-bounces@lists.xenproject.org Tue Jun 30 17:10:04 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 17:10:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqJlR-00071F-ST; Tue, 30 Jun 2020 17:09:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqJlQ-000718-9N for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 17:09:44 +0000 X-Inumbo-ID: 7d1c26d6-baf4-11ea-bb8b-bc764e2007e4 Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 7d1c26d6-baf4-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 17:09:42 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: uVxal5l+6qY90nygpfB30oTzqbO5tiCQpFNAcwlNWp/lC1QdaD/x4TOO5b12IEipt9G9ObkKuh 6O0lHAK3GNf4PdcQQTqP+MO7a+z4W3rjv0ApHbppJwntDKo4EGx/Rtns3wpC9WyJFHompHytjM qfi2ZxOIqBhyqUqTqmvSpYfgjbYckqdDPiGJ3+DvbbwUgMHXv2puRS1q/78UAKshPBbi/IceH6 sNNm02BAsrAKU9LEx6ZwQRl3Z2NacZjfpx6r9fp591da3wPqSsCX2AdVgSstTlG7sWXYE/7P8P IUI= X-SBRS: 2.7 X-MesageID: 21309442 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,298,1589256000"; d="scan'208";a="21309442" From: Anthony PERARD To: Subject: [XEN PATCH] hvmloader: Fix reading ACPI PM1 CNT value Date: Tue, 30 Jun 2020 18:09:13 +0100 Message-ID: <20200630170913.123646-1-anthony.perard@citrix.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Andrew Cooper , Ian Jackson , Jan Beulich , Anthony PERARD , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" In order to get the CNT value from QEMU, we were supposed to read a word, according to the implementation in QEMU. But it has been lax and allowed to read a single byte. This has changed with commit 5d971f9e6725 ("memory: Revert "memory: accept mismatching sizes in memory_region_access_valid"") and result in hvmloader crashing on the BUG_ON. Signed-off-by: Anthony PERARD --- I'll try to have the QEMU implementation changes to allow reading a byte, but it would probably by nice to not have to change qemu. --- tools/firmware/hvmloader/hvmloader.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/firmware/hvmloader/hvmloader.c b/tools/firmware/hvmloader/hvmloader.c index 598a22627872..bdcbe4a26664 100644 --- a/tools/firmware/hvmloader/hvmloader.c +++ b/tools/firmware/hvmloader/hvmloader.c @@ -256,7 +256,7 @@ static const struct bios_config *detect_bios(void) static void acpi_enable_sci(void) { - uint8_t pm1a_cnt_val; + uint16_t pm1a_cnt_val; #define PIIX4_SMI_CMD_IOPORT 0xb2 #define PIIX4_ACPI_ENABLE 0xf1 @@ -265,11 +265,11 @@ static void acpi_enable_sci(void) * PIIX4 emulation in QEMU has SCI_EN=0 by default. We have no legacy * SMM implementation, so give ACPI control to the OSPM immediately. */ - pm1a_cnt_val = inb(ACPI_PM1A_CNT_BLK_ADDRESS_V1); + pm1a_cnt_val = inw(ACPI_PM1A_CNT_BLK_ADDRESS_V1); if ( !(pm1a_cnt_val & ACPI_PM1C_SCI_EN) ) outb(PIIX4_SMI_CMD_IOPORT, PIIX4_ACPI_ENABLE); - pm1a_cnt_val = inb(ACPI_PM1A_CNT_BLK_ADDRESS_V1); + pm1a_cnt_val = inw(ACPI_PM1A_CNT_BLK_ADDRESS_V1); BUG_ON(!(pm1a_cnt_val & ACPI_PM1C_SCI_EN)); } -- Anthony PERARD From xen-devel-bounces@lists.xenproject.org Tue Jun 30 17:27:41 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 17:27:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqK2d-0000CD-Gc; Tue, 30 Jun 2020 17:27:31 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqK2c-0000C8-Bs for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 17:27:30 +0000 X-Inumbo-ID: f83cb842-baf6-11ea-bb8b-bc764e2007e4 Received: from us-smtp-delivery-1.mimecast.com (unknown [207.211.31.120]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id f83cb842-baf6-11ea-bb8b-bc764e2007e4; Tue, 30 Jun 2020 17:27:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593538047; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=oqaF53js116BFuwCtw9OPfpHPGSljyERaOiFUdX/2cY=; b=JLCJnRonvLSBEU+mhg/euJC4KbxMq+pI8SX2pkT+9LRUbRMnSFVX0Ry7b3vZdRcggnWSjw vojhap1ndNdJJFSEOIF3ukiNmLsj7SEOyvupW3iCHSMWealSF4QR12sspZRNSoktL744/a EIm075fJFJzBHT4bdDzSrf/QorVvEa0= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-101-6bzu-WqhPD2vZc1MPwEz0A-1; Tue, 30 Jun 2020 13:27:25 -0400 X-MC-Unique: 6bzu-WqhPD2vZc1MPwEz0A-1 Received: by mail-ed1-f71.google.com with SMTP id x20so17581452edr.20 for ; Tue, 30 Jun 2020 10:27:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oqaF53js116BFuwCtw9OPfpHPGSljyERaOiFUdX/2cY=; b=P2JHjslwd6eeTUHC4n0zfXVpFOj+K4LC54o2d76jHumd2wLaC3mtnq99S2CBYsJPBW mULiurVfZ+R62Fft7wq556yXbveJHgsPV6L8yPcExnrgQ8zvVudpdPEg5FtZBAbWao/N 3Em6oP2SjEG9QbH7Es/QBZPy/IIvnBEWgtsbcJl8PHs65a39Obygss6DZ9EzJS7e6B3o RCl8BqjiGyb7kvnp9VbwLDuyvNaq2QRPfMMRyXfRyycnS3hmr+t4AGrlHfF76RVfc1oF GujWLhQbh9aaB+j0IQl+amd6d7CCns4TrWodHBFLlIYfVXwx55yzgYNTZUrxua3nTS0X t3pQ== X-Gm-Message-State: AOAM532Qb+bzXVBnM+qUaoBPqsCd11PTKP1QNtVh8r4nOSTeUWGNhL1/ 7qsPXrtJV9Iw+Rtsb0vyUjFP2gBJSu0YIkq4E838Y2UN+4e6wzFliP9ULVnf6Smqbk4V198L6on SHPl23CAlAopu0++n826xGweT6OQ= X-Received: by 2002:a17:906:d9c4:: with SMTP id qk4mr20323088ejb.100.1593538044377; Tue, 30 Jun 2020 10:27:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzTRshH+tCbYqBRZoSrP2wOTHAhNfEEVSe9WoaeIdjWw3EP94byVU+BJoJjNvqHzssgxk8aLQ== X-Received: by 2002:a17:906:d9c4:: with SMTP id qk4mr20323075ejb.100.1593538044167; Tue, 30 Jun 2020 10:27:24 -0700 (PDT) Received: from [192.168.1.40] (1.red-83-51-162.dynamicip.rima-tde.net. [83.51.162.1]) by smtp.gmail.com with ESMTPSA id g21sm3546337edu.2.2020.06.30.10.27.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 10:27:23 -0700 (PDT) Subject: Re: [PATCH 2/2] xen: cleanup unrealized flash devices To: paul@xen.org, xen-devel@lists.xenproject.org, qemu-devel@nongnu.org References: <20200624121841.17971-1-paul@xen.org> <20200624121841.17971-3-paul@xen.org> <33e594dd-dbfa-7c57-1cf5-0852e8fc8e1d@redhat.com> <000701d64ef5$6568f660$303ae320$@xen.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Autocrypt: addr=philmd@redhat.com; keydata= mQINBDXML8YBEADXCtUkDBKQvNsQA7sDpw6YLE/1tKHwm24A1au9Hfy/OFmkpzo+MD+dYc+7 bvnqWAeGweq2SDq8zbzFZ1gJBd6+e5v1a/UrTxvwBk51yEkadrpRbi+r2bDpTJwXc/uEtYAB GvsTZMtiQVA4kRID1KCdgLa3zztPLCj5H1VZhqZsiGvXa/nMIlhvacRXdbgllPPJ72cLUkXf z1Zu4AkEKpccZaJspmLWGSzGu6UTZ7UfVeR2Hcc2KI9oZB1qthmZ1+PZyGZ/Dy+z+zklC0xl XIpQPmnfy9+/1hj1LzJ+pe3HzEodtlVA+rdttSvA6nmHKIt8Ul6b/h1DFTmUT1lN1WbAGxmg CH1O26cz5nTrzdjoqC/b8PpZiT0kO5MKKgiu5S4PRIxW2+RA4H9nq7nztNZ1Y39bDpzwE5Sp bDHzd5owmLxMLZAINtCtQuRbSOcMjZlg4zohA9TQP9krGIk+qTR+H4CV22sWldSkVtsoTaA2 qNeSJhfHQY0TyQvFbqRsSNIe2gTDzzEQ8itsmdHHE/yzhcCVvlUzXhAT6pIN0OT+cdsTTfif MIcDboys92auTuJ7U+4jWF1+WUaJ8gDL69ThAsu7mGDBbm80P3vvUZ4fQM14NkxOnuGRrJxO qjWNJ2ZUxgyHAh5TCxMLKWZoL5hpnvx3dF3Ti9HW2dsUUWICSQARAQABtDJQaGlsaXBwZSBN YXRoaWV1LURhdWTDqSAoUGhpbCkgPHBoaWxtZEByZWRoYXQuY29tPokCVQQTAQgAPwIbDwYL CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQSJweePYB7obIZ0lcuio/1u3q3A3gUCXsfWwAUJ KtymWgAKCRCio/1u3q3A3ircD/9Vjh3aFNJ3uF3hddeoFg1H038wZr/xi8/rX27M1Vj2j9VH 0B8Olp4KUQw/hyO6kUxqkoojmzRpmzvlpZ0cUiZJo2bQIWnvScyHxFCv33kHe+YEIqoJlaQc JfKYlbCoubz+02E2A6bFD9+BvCY0LBbEj5POwyKGiDMjHKCGuzSuDRbCn0Mz4kCa7nFMF5Jv piC+JemRdiBd6102ThqgIsyGEBXuf1sy0QIVyXgaqr9O2b/0VoXpQId7yY7OJuYYxs7kQoXI 6WzSMpmuXGkmfxOgbc/L6YbzB0JOriX0iRClxu4dEUg8Bs2pNnr6huY2Ft+qb41RzCJvvMyu gS32LfN0bTZ6Qm2A8ayMtUQgnwZDSO23OKgQWZVglGliY3ezHZ6lVwC24Vjkmq/2yBSLakZE 6DZUjZzCW1nvtRK05ebyK6tofRsx8xB8pL/kcBb9nCuh70aLR+5cmE41X4O+MVJbwfP5s/RW 9BFSL3qgXuXso/3XuWTQjJJGgKhB6xXjMmb1J4q/h5IuVV4juv1Fem9sfmyrh+Wi5V1IzKI7 RPJ3KVb937eBgSENk53P0gUorwzUcO+ASEo3Z1cBKkJSPigDbeEjVfXQMzNt0oDRzpQqH2vp apo2jHnidWt8BsckuWZpxcZ9+/9obQ55DyVQHGiTN39hkETy3Emdnz1JVHTU0Q== Message-ID: <9e591254-d215-d5af-38d2-fd5b65f84a43@redhat.com> Date: Tue, 30 Jun 2020 19:27:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <000701d64ef5$6568f660$303ae320$@xen.org> Content-Language: en-US Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=philmd@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Eduardo Habkost' , 'Jason Andryuk' , 'Paul Durrant' , "'Michael S. Tsirkin'" , 'Paolo Bonzini' , 'Richard Henderson' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 6/30/20 5:44 PM, Paul Durrant wrote: >> -----Original Message----- >> From: Philippe Mathieu-Daudé >> Sent: 30 June 2020 16:26 >> To: Paul Durrant ; xen-devel@lists.xenproject.org; qemu-devel@nongnu.org >> Cc: Eduardo Habkost ; Michael S. Tsirkin ; Paul Durrant >> ; Jason Andryuk ; Paolo Bonzini ; >> Richard Henderson >> Subject: Re: [PATCH 2/2] xen: cleanup unrealized flash devices >> >> On 6/24/20 2:18 PM, Paul Durrant wrote: >>> From: Paul Durrant >>> >>> The generic pc_machine_initfn() calls pc_system_flash_create() which creates >>> 'system.flash0' and 'system.flash1' devices. These devices are then realized >>> by pc_system_flash_map() which is called from pc_system_firmware_init() which >>> itself is called via pc_memory_init(). The latter however is not called when >>> xen_enable() is true and hence the following assertion fails: >>> >>> qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly: >>> Assertion `dev->realized' failed >>> >>> These flash devices are unneeded when using Xen so this patch avoids the >>> assertion by simply removing them using pc_system_flash_cleanup_unused(). >>> >>> Reported-by: Jason Andryuk >>> Fixes: ebc29e1beab0 ("pc: Support firmware configuration with -blockdev") >>> Signed-off-by: Paul Durrant >>> Tested-by: Jason Andryuk >>> --- >>> Cc: Paolo Bonzini >>> Cc: Richard Henderson >>> Cc: Eduardo Habkost >>> Cc: "Michael S. Tsirkin" >>> Cc: Marcel Apfelbaum >>> --- >>> hw/i386/pc_piix.c | 9 ++++++--- >>> hw/i386/pc_sysfw.c | 2 +- >>> include/hw/i386/pc.h | 1 + >>> 3 files changed, 8 insertions(+), 4 deletions(-) >>> >>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c >>> index 1497d0e4ae..977d40afb8 100644 >>> --- a/hw/i386/pc_piix.c >>> +++ b/hw/i386/pc_piix.c >>> @@ -186,9 +186,12 @@ static void pc_init1(MachineState *machine, >>> if (!xen_enabled()) { >>> pc_memory_init(pcms, system_memory, >>> rom_memory, &ram_memory); >>> - } else if (machine->kernel_filename != NULL) { >>> - /* For xen HVM direct kernel boot, load linux here */ >>> - xen_load_linux(pcms); >>> + } else { >>> + pc_system_flash_cleanup_unused(pcms); >> >> TIL pc_system_flash_cleanup_unused(). >> >> What about restricting at the source? >> > > And leave the devices in place? They are not relevant for Xen, so why not clean up? No, I meant to not create them in the first place, instead of create+destroy. Anyway what you did works, so I don't have any problem. Reviewed-by: Philippe Mathieu-Daudé > > Paul > >> -- >8 -- >> --- a/hw/i386/pc.c >> +++ b/hw/i386/pc.c >> @@ -1004,24 +1004,26 @@ void pc_memory_init(PCMachineState *pcms, >> &machine->device_memory->mr); >> } >> >> - /* Initialize PC system firmware */ >> - pc_system_firmware_init(pcms, rom_memory); >> - >> - option_rom_mr = g_malloc(sizeof(*option_rom_mr)); >> - memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE, >> - &error_fatal); >> - if (pcmc->pci_enabled) { >> - memory_region_set_readonly(option_rom_mr, true); >> - } >> - memory_region_add_subregion_overlap(rom_memory, >> - PC_ROM_MIN_VGA, >> - option_rom_mr, >> - 1); >> - >> fw_cfg = fw_cfg_arch_create(machine, >> x86ms->boot_cpus, x86ms->apic_id_limit); >> >> - rom_set_fw(fw_cfg); >> + /* Initialize PC system firmware */ >> + if (!xen_enabled()) { >> + pc_system_firmware_init(pcms, rom_memory); >> + >> + option_rom_mr = g_malloc(sizeof(*option_rom_mr)); >> + memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE, >> + &error_fatal); >> + if (pcmc->pci_enabled) { >> + memory_region_set_readonly(option_rom_mr, true); >> + } >> + memory_region_add_subregion_overlap(rom_memory, >> + PC_ROM_MIN_VGA, >> + option_rom_mr, >> + 1); >> + >> + rom_set_fw(fw_cfg); >> + } >> >> if (pcmc->has_reserved_memory && machine->device_memory->base) { >> uint64_t *val = g_malloc(sizeof(*val)); >> --- >> >>> + if (machine->kernel_filename != NULL) { >>> + /* For xen HVM direct kernel boot, load linux here */ >>> + xen_load_linux(pcms); >>> + } >>> } >>> >>> gsi_state = pc_gsi_create(&x86ms->gsi, pcmc->pci_enabled); >>> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c >>> index ec2a3b3e7e..0ff47a4b59 100644 >>> --- a/hw/i386/pc_sysfw.c >>> +++ b/hw/i386/pc_sysfw.c >>> @@ -108,7 +108,7 @@ void pc_system_flash_create(PCMachineState *pcms) >>> } >>> } >>> >>> -static void pc_system_flash_cleanup_unused(PCMachineState *pcms) >>> +void pc_system_flash_cleanup_unused(PCMachineState *pcms) >>> { >>> char *prop_name; >>> int i; >>> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h >>> index e6135c34d6..497f2b7ab7 100644 >>> --- a/include/hw/i386/pc.h >>> +++ b/include/hw/i386/pc.h >>> @@ -187,6 +187,7 @@ int cmos_get_fd_drive_type(FloppyDriveType fd0); >>> >>> /* pc_sysfw.c */ >>> void pc_system_flash_create(PCMachineState *pcms); >>> +void pc_system_flash_cleanup_unused(PCMachineState *pcms); >>> void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory); >>> >>> /* acpi-build.c */ >>> > > From xen-devel-bounces@lists.xenproject.org Tue Jun 30 17:37:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 17:37:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqKC2-00015T-Iu; Tue, 30 Jun 2020 17:37:14 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqKC1-00015O-Ed for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 17:37:13 +0000 X-Inumbo-ID: 544516c4-baf8-11ea-8678-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 544516c4-baf8-11ea-8678-12813bfff9fa; Tue, 30 Jun 2020 17:37:12 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: +Np/BWtx/I4QIB4sV5N2Yq25bSkFW8TR+l9C7IrlpO9A1kqCJ8vK73ynl0/IQN9QoHpofXj80+ e7BVcFeZVcfooUrBJS/9ZnIDnYSfKCf3/gvZRoYiUb97YPL8ZG0l7SGUoIQN8nMnx8msLVYQwC wX/dI0iqcdbTHpiIQn42pSfQQqbUE6biBGKUW2ZHHha+CuMy5IV+6qLCh7/VIfCdfS105OsL8g YMtgPMSq18GHQEKdo6mQBPI61qr2b6ox9edoV+zRRjbl3h4c8g4fZH0slpIBq/9U7g9z3HnHKU 8qc= X-SBRS: 2.7 X-MesageID: 21312351 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,298,1589256000"; d="scan'208";a="21312351" Subject: Re: [PATCH v4 01/10] x86/vmx: add Intel PT MSR definitions To: =?UTF-8?Q?Micha=c5=82_Leszczy=c5=84ski?= , References: <2ff9ecee8367e814a29b17a34203bda0e3c48d74.1593519420.git.michal.leszczynski@cert.pl> From: Andrew Cooper Message-ID: Date: Tue, 30 Jun 2020 18:37:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <2ff9ecee8367e814a29b17a34203bda0e3c48d74.1593519420.git.michal.leszczynski@cert.pl> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: tamas.lengyel@intel.com, luwei.kang@intel.com, Wei Liu , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 30/06/2020 13:33, Michał Leszczyński wrote: > diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h > index b328a47ed8..0203029be9 100644 > --- a/xen/include/asm-x86/msr-index.h > +++ b/xen/include/asm-x86/msr-index.h > @@ -69,6 +69,43 @@ > #define MSR_MCU_OPT_CTRL 0x00000123 > #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) > > +/* Intel PT MSRs */ > +#define MSR_RTIT_OUTPUT_BASE 0x00000560 > + > +#define MSR_RTIT_OUTPUT_MASK 0x00000561 > + > +#define MSR_RTIT_CTL 0x00000570 > +#define RTIT_CTL_TRACEEN (_AC(1, ULL) << 0) > +#define RTIT_CTL_CYCEN (_AC(1, ULL) << 1) In addition to what Jan has said, please can we be consistent with an underscore (or not) before EN.  Preferably with, so these would become TRACE_EN and CYC_EN. That said, there are a lot of bit definitions which aren't used at all.  IMO, it would be better to introduce defines when you use them. Thanks, ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 30 18:04:05 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 18:04:05 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqKbs-0003aS-Q4; Tue, 30 Jun 2020 18:03:56 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqKbr-0003aN-HX for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 18:03:55 +0000 X-Inumbo-ID: 0f91b268-bafc-11ea-b7bb-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 0f91b268-bafc-11ea-b7bb-bc764e2007e4; Tue, 30 Jun 2020 18:03:54 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id o8so19667447wmh.4 for ; Tue, 30 Jun 2020 11:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9M1CDfK/H2cl9/qGX30wrOtT6hGs97JvaCKGnxd5S70=; b=YItEk2D7psW7cr5wyH/lVxKXLVq/wwkkYdensuGwK4RQolGup6xCQRRPNIBiBQ1fJx fwL0MYLpxa0EkAmkhttNNbbpgtsul4t4gEq55FKmGDD7TG1nFRAba0VnnPr8otaxJ9uV uTUL48J4fRhRfHJR9LOT8+7aBdGkZTLSfzf8nSEXmhGO5UcqHA/bk1D+PkHBr/MkeHBD WsKenlK0KidZf2oXvOnzo36HSAjj2Bhabs9H/rsbzfLSUjGAI3NjYrHbJQN5jSa5o/IO 1S4cBwHb3fU1RpGfPBBR+ODr4/ic2zZGopSotaj2h2s+Xd/qf3KOOvTZ5LhoqkXpd7YE zU3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9M1CDfK/H2cl9/qGX30wrOtT6hGs97JvaCKGnxd5S70=; b=NXvfXw/XOz+jwRGr1FWMpJq2j7KUitzv+fHZMXsDUUL0Wm/YRZCnWBJkOqqq2kxjFY qBKSLFkBg84AwiBdzh5ta/b6NAtMDM93s7A7F/Fmlt5/oflatQpPOc+yHFOY6mLFCzAo HtXUpYRlaRGWVdirsxziw6Q2pmvQsMpCtq5kblDmfdEJKC8pmCdPkvjE/0QXI0h+pnmt YJtgb3HG1AUCyXv2qkVButXZxnin2s2baXzOZRaGnVyux2DkjNEMupOvhBdVdpW1r1Up BF3wDFb4DcmpirGj05S/UlFtJuL4wJe/iGel8vcPp9mVUUmfaX6iFeH6x5Nl6iI4JwDC Iqdg== X-Gm-Message-State: AOAM533XPM1b4OTRwDhiSMcC6spdobF8zeRmRNW8fbq/VmZ8pCx5FKKp sCnAjEjA9n0V4vs4ScJPrN5LacmHf3iihTuy7+Y= X-Google-Smtp-Source: ABdhPJyTsRreoepnB3x4IosE1ZWCrvEFCF/ygbRyfqS85KQD0WrHaKBzwBRTsbweG0fA5wJWZy8jQ4PcTS4sA+b3NIQ= X-Received: by 2002:a1c:b103:: with SMTP id a3mr22448753wmf.186.1593540233987; Tue, 30 Jun 2020 11:03:53 -0700 (PDT) MIME-Version: 1.0 References: <2ff9ecee8367e814a29b17a34203bda0e3c48d74.1593519420.git.michal.leszczynski@cert.pl> In-Reply-To: From: Tamas K Lengyel Date: Tue, 30 Jun 2020 12:03:17 -0600 Message-ID: Subject: Re: [PATCH v4 01/10] x86/vmx: add Intel PT MSR definitions To: Andrew Cooper Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , =?UTF-8?B?TWljaGHFgiBMZXN6Y3p5xYRza2k=?= , "Kang, Luwei" , Jan Beulich , Xen-devel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Tue, Jun 30, 2020 at 11:39 AM Andrew Cooper wrote: > > On 30/06/2020 13:33, Micha=C5=82 Leszczy=C5=84ski wrote: > > diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-= index.h > > index b328a47ed8..0203029be9 100644 > > --- a/xen/include/asm-x86/msr-index.h > > +++ b/xen/include/asm-x86/msr-index.h > > @@ -69,6 +69,43 @@ > > #define MSR_MCU_OPT_CTRL 0x00000123 > > #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) > > > > +/* Intel PT MSRs */ > > +#define MSR_RTIT_OUTPUT_BASE 0x00000560 > > + > > +#define MSR_RTIT_OUTPUT_MASK 0x00000561 > > + > > +#define MSR_RTIT_CTL 0x00000570 > > +#define RTIT_CTL_TRACEEN (_AC(1, ULL) << 0) > > +#define RTIT_CTL_CYCEN (_AC(1, ULL) << 1) > > In addition to what Jan has said, please can we be consistent with an > underscore (or not) before EN. Preferably with, so these would become > TRACE_EN and CYC_EN. > > That said, there are a lot of bit definitions which aren't used at all. > IMO, it would be better to introduce defines when you use them. In the past I found it very valuable when this type of plumbing was already present in Xen instead of me having to go into the SDM to digg out the magic numbers. So while some of the bits might not be used right now I also don't see any downside in having them, just in case. Tamas From xen-devel-bounces@lists.xenproject.org Tue Jun 30 18:28:28 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 18:28:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqKzI-0005Jh-Tw; Tue, 30 Jun 2020 18:28:08 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqKzH-0005Ii-NE for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 18:28:07 +0000 X-Inumbo-ID: 6fed66b8-baff-11ea-bca7-bc764e2007e4 Received: from bagnar.nask.net.pl (unknown [195.187.242.196]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6fed66b8-baff-11ea-bca7-bc764e2007e4; Tue, 30 Jun 2020 18:28:05 +0000 (UTC) Received: from bagnar.nask.net.pl (unknown [172.16.9.10]) by bagnar.nask.net.pl (Postfix) with ESMTP id 25AC4A2D96; Tue, 30 Jun 2020 20:28:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 16CBCA2D72; Tue, 30 Jun 2020 20:28:03 +0200 (CEST) Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id I0y3I5AYCRFX; Tue, 30 Jun 2020 20:28:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by bagnar.nask.net.pl (Postfix) with ESMTP id 7BF66A2D96; Tue, 30 Jun 2020 20:28:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at bagnar.nask.net.pl Received: from bagnar.nask.net.pl ([127.0.0.1]) by localhost (bagnar.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JG6rGhqEI7gX; Tue, 30 Jun 2020 20:28:02 +0200 (CEST) Received: from belindir.nask.net.pl (belindir-ext.nask.net.pl [195.187.242.210]) by bagnar.nask.net.pl (Postfix) with ESMTP id 48370A2D72; Tue, 30 Jun 2020 20:28:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id 304442263B; Tue, 30 Jun 2020 20:27:32 +0200 (CEST) Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SG0nOzTI3QWF; Tue, 30 Jun 2020 20:27:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by belindir.nask.net.pl (Postfix) with ESMTP id B9AD12263E; Tue, 30 Jun 2020 20:27:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at belindir.nask.net.pl Received: from belindir.nask.net.pl ([127.0.0.1]) by localhost (belindir.nask.net.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mU_Kj1y3yhuY; Tue, 30 Jun 2020 20:27:26 +0200 (CEST) Received: from belindir.nask.net.pl (belindir.nask.net.pl [172.16.10.10]) by belindir.nask.net.pl (Postfix) with ESMTP id 99E292263B; Tue, 30 Jun 2020 20:27:26 +0200 (CEST) Date: Tue, 30 Jun 2020 20:27:26 +0200 (CEST) From: =?utf-8?Q?Micha=C5=82_Leszczy=C5=84ski?= To: Tamas K Lengyel Message-ID: <1131260497.16365560.1593541646453.JavaMail.zimbra@cert.pl> In-Reply-To: References: <2ff9ecee8367e814a29b17a34203bda0e3c48d74.1593519420.git.michal.leszczynski@cert.pl> Subject: Re: [PATCH v4 01/10] x86/vmx: add Intel PT MSR definitions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.16.10.10] X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - GC83 (Win)/8.6.0_GA_1194) Thread-Topic: x86/vmx: add Intel PT MSR definitions Thread-Index: 1izXA+9OHj2ZDOZvjmC0NbckxdYjcQ== X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tamas K Lengyel , Wei Liu , Andrew Cooper , Jan Beulich , Xen-devel , "Kang, Luwei" , Roger Pau =?utf-8?Q?Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" ----- 30 cze 2020 o 20:03, Tamas K Lengyel tamas.k.lengyel@gmail.com napisa= =C5=82(a): > On Tue, Jun 30, 2020 at 11:39 AM Andrew Cooper > wrote: >> >> On 30/06/2020 13:33, Micha=C5=82 Leszczy=C5=84ski wrote: >> > diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr= -index.h >> > index b328a47ed8..0203029be9 100644 >> > --- a/xen/include/asm-x86/msr-index.h >> > +++ b/xen/include/asm-x86/msr-index.h >> > @@ -69,6 +69,43 @@ >> > #define MSR_MCU_OPT_CTRL 0x00000123 >> > #define MCU_OPT_CTRL_RNGDS_MITG_DIS (_AC(1, ULL) << 0) >> > >> > +/* Intel PT MSRs */ >> > +#define MSR_RTIT_OUTPUT_BASE 0x00000560 >> > + >> > +#define MSR_RTIT_OUTPUT_MASK 0x00000561 >> > + >> > +#define MSR_RTIT_CTL 0x00000570 >> > +#define RTIT_CTL_TRACEEN (_AC(1, ULL) << 0) >> > +#define RTIT_CTL_CYCEN (_AC(1, ULL) << 1) >> >> In addition to what Jan has said, please can we be consistent with an >> underscore (or not) before EN. Preferably with, so these would become >> TRACE_EN and CYC_EN. >> >> That said, there are a lot of bit definitions which aren't used at all. >> IMO, it would be better to introduce defines when you use them. >=20 > In the past I found it very valuable when this type of plumbing was > already present in Xen instead of me having to go into the SDM to digg > out the magic numbers. So while some of the bits might not be used > right now I also don't see any downside in having them, just in case. >=20 > Tamas +1 for keeping the unused #defines, this is a helpful piece of knowledge which speeds up further patch development. It doesn't affect the compilatio= n nor runtime time and it doesn't occupy too much space in the code so I woul= d opt for keep it. I will rebase this series onto latest master within patch v5. The remaining patches in this series are not affected and still could be reviewed, so I will wait a few days before posting the new version. Best regards, Micha=C5=82 Leszczy=C5=84ski CERT Polska From xen-devel-bounces@lists.xenproject.org Tue Jun 30 18:54:47 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 18:54:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqLOv-0007hS-5i; Tue, 30 Jun 2020 18:54:37 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqLOt-0007h7-Qz for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 18:54:35 +0000 X-Inumbo-ID: 1ffded72-bb03-11ea-bca7-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1ffded72-bb03-11ea-bca7-bc764e2007e4; Tue, 30 Jun 2020 18:54:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8ghiF/vsK158x7B8VPS3Sns/pNNm0Imm8Qv1hYOaGZs=; b=pZOzp9DygoPU+AwdzW2VM3uYi T4TSTHfC96Qt2ALqNHIHZwWtTrZ3QGO3apxfFSBRvThyy9QCJ3AfkpOV/dePRQIpPjJgOdUjo9jLk pM6ImhuzlpIPqLyRh5yy1GGOlmlD3+dtBHZ95/piXBtrv+RrRm9LmKns8ar2iJZpxn71M=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqLOl-0007Tx-TP; Tue, 30 Jun 2020 18:54:27 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jqLOl-0006Im-Ll; Tue, 30 Jun 2020 18:54:27 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jqLOl-0003V4-KP; Tue, 30 Jun 2020 18:54:27 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [qemu-mainline test] 151471: regressions - FAIL X-Osstest-Failures: qemu-mainline:test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt-vhd:debian-di-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-win7-amd64:windows-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-intel:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ovmf-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qcow2:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-amd:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-xl-qemuu-debianhvm-amd64:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:debian-hvm-install:fail:regression qemu-mainline:test-amd64-i386-freebsd10-i386:guest-start:fail:regression qemu-mainline:test-amd64-i386-qemuu-rhel6hvm-intel:redhat-install:fail:regression qemu-mainline:test-amd64-amd64-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-amd64-i386-freebsd10-amd64:guest-start:fail:regression qemu-mainline:test-amd64-i386-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-amd64-libvirt-pair:guest-start/debian:fail:regression qemu-mainline:test-armhf-armhf-xl-vhd:debian-di-install:fail:regression qemu-mainline:test-arm64-arm64-libvirt-xsm:guest-start:fail:regression qemu-mainline:test-armhf-armhf-libvirt-raw:debian-di-install:fail:regression qemu-mainline:test-amd64-amd64-xl-qemuu-ws16-amd64:windows-install:fail:regression qemu-mainline:test-armhf-armhf-libvirt:guest-start:fail:regression qemu-mainline:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking qemu-mainline:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: qemuu=fc1bff958998910ec8d25db86cd2f53ff125f7ab X-Osstest-Versions-That: qemuu=9e3903136d9acde2fb2dd9e967ba928050a6cb4a From: osstest service owner Date: Tue, 30 Jun 2020 18:54:27 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151471 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/151471/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-libvirt-vhd 10 debian-di-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-intel 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-qemuu-nested-amd 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. vs. 151065 test-amd64-i386-freebsd10-i386 11 guest-start fail REGR. vs. 151065 test-amd64-i386-qemuu-rhel6hvm-intel 10 redhat-install fail REGR. vs. 151065 test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 151065 test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 151065 test-amd64-amd64-libvirt-pair 21 guest-start/debian fail REGR. vs. 151065 test-armhf-armhf-xl-vhd 10 debian-di-install fail REGR. vs. 151065 test-arm64-arm64-libvirt-xsm 12 guest-start fail REGR. vs. 151065 test-armhf-armhf-libvirt-raw 10 debian-di-install fail REGR. vs. 151065 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151065 test-armhf-armhf-libvirt 12 guest-start fail REGR. vs. 151065 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass version targeted for testing: qemuu fc1bff958998910ec8d25db86cd2f53ff125f7ab baseline version: qemuu 9e3903136d9acde2fb2dd9e967ba928050a6cb4a Last test of basis 151065 2020-06-12 22:27:51 Z 17 days Failing since 151101 2020-06-14 08:32:51 Z 16 days 17 attempts Testing same since 151471 2020-06-30 05:19:07 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Ahmed Karaman Aleksandar Markovic Alex Bennée Alex Williamson Alexander Bulekov Alexey Krasikov Alistair Francis Allan Peramaki Andrew Jones Ani Sinha Anthony PERARD Ard Biesheuvel Artyom Tarasenko Aurelien Jarno Babu Moger BALATON Zoltan Bin Meng Cathy Zhang Christian Borntraeger Claudio Fontana Cleber Rosa Colin Xu Cornelia Huck Cédric Le Goater Daniel P. Berrangé Daniele Buono David Carlier David Gibson David Hildenbrand Derek Su Dr. David Alan Gilbert Edgar E. Iglesias Eduardo Habkost Emilio G. Cota Eric Auger Eric Blake Eric Farman Erik Smit Evgeny Yakovlev fangying Farhan Ali Finn Thain Geoffrey McRae Gerd Hoffmann Greg Kurz Guenter Roeck Gustavo Romero Helge Deller Huacai Chen Huacai Chen Ian Jiang Igor Mammedov Janne Grunau Jason Wang Jay Zhou Jean-Christophe Dubois Jiaxun Yang Jingqi Liu John Snow Jon Doron Joseph Myers Julio Faracco Kevin Wolf Klaus Jensen Klaus Jensen Laurent Vivier Laurent Vivier Leonid Bloch Leonid Bloch Li Qiang Liao Pingfang Like Xu Lingfeng Yang Liran Alon Lukas Straub Maciej S. Szmigiero Magnus Damm Mao Zhongyi Marcelo Tosatti Marek Marczykowski-Górecki Mark Cave-Ayland Markus Armbruster Masahiro Yamada Max Filippov Max Reitz Michael S. Tsirkin Pan Nengyuan Paolo Bonzini Pavel Dovgalyuk Pavel Dovgalyuk Peter Maydell Peter Xu Philippe Mathieu-Daude Philippe Mathieu-Daudé Philippe Mathieu-Daudé Prasad J Pandit Raphael Norwitz Richard Henderson Richard W.M. Jones Robert Foley Roman Bolshakov Roman Kagan Roman Kagan Sai Pavan Boddu Sebastian Rasmussen Sergio Lopez Shameer Kolothum Stefan Berger Stefan Berger Stefan Hajnoczi Tao Xu Thomas Huth Tong Ho Volker Rümelin WangBowen Wei Huang Wei Wang Ying Fang Yoshinori Sato Yuri Benditovich Zhang Chen jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm fail test-amd64-i386-xl-qemuu-debianhvm-i386-xsm fail test-amd64-amd64-libvirt-xsm fail test-arm64-arm64-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemuu-rhel6hvm-amd fail test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail test-amd64-i386-freebsd10-i386 fail test-amd64-amd64-qemuu-nested-intel fail test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemuu-rhel6hvm-intel fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt fail test-amd64-i386-libvirt fail test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair fail test-amd64-i386-libvirt-pair fail test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw fail test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow fail test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 14425 lines long.) From xen-devel-bounces@lists.xenproject.org Tue Jun 30 20:49:48 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 20:49:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqNC4-0008EV-6R; Tue, 30 Jun 2020 20:49:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqNC2-0008EL-7Y for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 20:49:26 +0000 X-Inumbo-ID: 2e381060-bb13-11ea-8695-12813bfff9fa Received: from esa2.hc3370-68.iphmx.com (unknown [216.71.145.153]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 2e381060-bb13-11ea-8695-12813bfff9fa; Tue, 30 Jun 2020 20:49:24 +0000 (UTC) Authentication-Results: esa2.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: scvk6xkOra2VNUp2WDoOp2BS7us9n4dJl76LOt5U3vJY6+wdXitUXZMuml49ND1jDzDgX4P8dk as9r+kg0tjG4z048xv4GIyRXZPRZ5Z0OmeY7c5JzXZ9VXsjK1xCNOLgx0BNK0ggPvoutLTmXFx 2s84OFREV2OfDTkAZuEZyJ0a7d9wXgrV7n78v1513utyP2lR5Z9VY5Keze/LdjdOTGb/ex7lbg bOB+eA3lB7ga6WPBZmW/aHPkRe0nRYBL0phS5vsOrXz46ohK6CHvwk9gT/QVfsaGNPzLrvLpbN Vxk= X-SBRS: 2.7 X-MesageID: 21343897 X-Ironport-Server: esa2.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.75,298,1589256000"; d="scan'208";a="21343897" Subject: Re: [PATCH] x86/cpuid: Expose number of vCPUs in CPUID.1.EBX To: Hubert Jasudowicz , References: <8174d110-be3b-5735-9085-f35f7f0318ab@cert.pl> From: Andrew Cooper X-Enigmail-Draft-Status: N11100 Message-ID: <03c4c8e1-5924-9b85-6e1b-023ae24745f3@citrix.com> Date: Tue, 30 Jun 2020 21:49:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <8174d110-be3b-5735-9085-f35f7f0318ab@cert.pl> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To AMSPEX02CL02.citrite.net (10.69.22.126) X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Wei Liu , Jan Beulich , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 19/06/2020 15:19, Hubert Jasudowicz wrote: > On 6/18/20 6:51 PM, Andrew Cooper wrote: >> On 18/06/2020 17:22, Hubert Jasudowicz wrote: >>> When running under KVM (or presumably other hypervisors) we enable >>> the CPUID.1.EDX.HTT flag, thus indicating validity of CPUID.1.EBX[23:16] >>> - maximum number of logical processors which the guest reads as 0. >>> >>> Although this method of topology detection is considered legacy, >>> Windows falls back to it when CPUID.0BH.EBX is 0. >>> >>> CPUID.1.EBX[23:16] being equal to 0, triggers memory corruption in >>> ntoskrnl.exe as Windows assumes that number of logical processors would >>> be at least 1. Memory corruption manifests itself while mapping >>> framebuffer for early graphical subsystem, causing BSOD. >>> >>> This patch fixes running nested Windows (tested on 7 and 10) with KVM as >>> L0 hypervisor, by setting the value to maximum number of vCPUs in domain. >>> >>> Signed-off-by: Hubert Jasudowicz >> I'm afraid fixing guest topology is more complicated than just this.  On >> its own, I'm not sure if this is safe for VMs migrating in. >> >> While I agree that Xen's logic is definitely broken, I suspect the >> conditions for the BSOD are more complicated than this, because Windows >> does work fine when there is no KVM in the setup described. >> >> ~Andrew >> > After some more testing, I've managed to boot Windows by explicitly configuring the guest > with cpuid="host,htt=0". If I understand correctly, the default behavior is to > enable HTT for the guest and basically pass through the value of CPUID.1.EBX[23:16] > without any sanity checks. > > The reason this works in other setups is that the non-zero value returned by real hardware > leaks into the guest. In my setup, what Xen sees is: > CPUID.1h == EAX: 000806ea EBX: 00000800 ECX: fffab223 EDX: 0f8bfbff > > In terms of VM migration, this seems already broken because guest might read different > values depending on what underlying hardware reports. The patch would at least provide > some consistency between hosts. Another solution would be not to enable HTT bit by default. Apologies for the delay replying.  (I've been attempting to finish the reply for more than a week now, but am just far too busy). Xen's behaviour is definitely buggy.  I'm not trying to defend the mess it is currently in. The problem started (AFAICT) with c/s ca2eee92df44 in Xen 3.4 (yup - you're reading that right), which is still reverted in XenServer because it broke migration across that changeset.  (We also have other topology extensions which are broken in different ways, and I'm still attempting to unbreak upstream Xen enough to fix it properly). That changeset attempted to expose hyperthreads, but keep them somewhat hidden by blindly asserting that APIC_ID shall now be vcpu_id * 2. Starting with 4.14-rc3, the logic patched above can now distinguish between a clean boot, and a migration in from a pre-4.14 version of Xen, where the CPUID settings need re-inventing out of thin air. Anyway - to this problem specifically. It seems KVM is giving us HTT=0 and NC=0.  The botched logic above has clearly not been run on a pre-HTT processor, and it trips up properly under KVM's way of doing things. How is the rest of the topology expressed?  Do we get one socket per vcpu then, or is this example a single vcpu VM? I'm wondering if the option least likely to break migration under the current scheme would be to have Xen invent a nonzero number there in the HVM policy alongside setting HTT. ~Andrew From xen-devel-bounces@lists.xenproject.org Tue Jun 30 22:13:15 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 22:13:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqOUn-0006uk-L8; Tue, 30 Jun 2020 22:12:53 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqOUm-0006uf-R4 for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 22:12:52 +0000 X-Inumbo-ID: d6e792b6-bb1e-11ea-86a3-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id d6e792b6-bb1e-11ea-86a3-12813bfff9fa; Tue, 30 Jun 2020 22:12:52 +0000 (UTC) Received: from localhost (mobile-166-175-191-139.mycingular.net [166.175.191.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D16072081A; Tue, 30 Jun 2020 22:12:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593555171; bh=h1obBUyTPJ75QgeorGRJK1b9zJ+cbov4c/nHPyLr+yw=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=M/84Qq3eKACfAHQjDCkpV3cm4rQfN9fudLtrODHV/aJYn7tGBP4MbNKzLWTc4wcbQ 8wxU6ED77IYa/Qy/hiMpWO6dMSUxGVVEE//2L7iGf/0Lt9kZ4iUwcFbIHZrWAum8Iq d1+6PKGsAIhjnkj3qCRYtXN45CyM9IaaV6LCntes= Date: Tue, 30 Jun 2020 17:12:49 -0500 From: Bjorn Helgaas To: Colin King Subject: Re: [PATCH] xen/pci: remove redundant assignment to variable irq Message-ID: <20200630221249.GA3491219@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200409114118.249461-1-colin.king@canonical.com> X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Konrad Rzeszutek Wilk , linux-pci@vger.kernel.org, x86@kernel.org, kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Bjorn Helgaas , xen-devel@lists.xenproject.org, Thomas Gleixner , Boris Ostrovsky Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" [+cc Juergen, Boris] On Thu, Apr 09, 2020 at 12:41:18PM +0100, Colin King wrote: > From: Colin Ian King > > The variable irq is being initialized with a value that is never read > and it is being updated later with a new value. The initialization is > redundant and can be removed. > > Addresses-Coverity: ("Unused value") > Signed-off-by: Colin Ian King Applied to pci/virtualization for v5.9, thanks! I don't see this in linux-next yet, but if anybody else would prefer to take it, let me know and I'll drop it. > --- > arch/x86/pci/xen.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/pci/xen.c b/arch/x86/pci/xen.c > index 91220cc25854..80272eb49230 100644 > --- a/arch/x86/pci/xen.c > +++ b/arch/x86/pci/xen.c > @@ -63,7 +63,7 @@ static int xen_pcifront_enable_irq(struct pci_dev *dev) > static int xen_register_pirq(u32 gsi, int gsi_override, int triggering, > bool set_pirq) > { > - int rc, pirq = -1, irq = -1; > + int rc, pirq = -1, irq; > struct physdev_map_pirq map_irq; > int shareable = 0; > char *name; > -- > 2.25.1 > From xen-devel-bounces@lists.xenproject.org Tue Jun 30 22:21:53 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 22:21:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqOdR-0007mO-JE; Tue, 30 Jun 2020 22:21:49 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqOdQ-0007mJ-7H for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 22:21:48 +0000 X-Inumbo-ID: 15432312-bb20-11ea-86a4-12813bfff9fa Received: from GBR01-LO2-obe.outbound.protection.outlook.com (unknown [40.107.10.113]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 15432312-bb20-11ea-86a4-12813bfff9fa; Tue, 30 Jun 2020 22:21:46 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QlVADUyp02L4liYBJT+4Wfh54VZXXIefrz5iOo2QzrAfTWVbc4i6DHrXq6ohNFIJD8N9StyBaf4ZODmk/nLh/ggSGE9SXimqBFzag5Z7018PsGBF5PbEt5OGYVbqnWYRwOJ4xM09ot/polQiZYy2AS6Zoavhwp//pELMcaY+CZsbzKZCrFO05L/9EE9OPhFsErthisR1J+nxuDDOHKG3gym+RWjuEV7si92sxMZU11oogZRGfgChCGK1adwJ15H1l6MVgnXpt2KL3TTCj5w5NjCpPWORFalvudmcULVxRakE8WC1/QuUH5tOfjCMAJsuAocKGCCgQ0z+PqH4pPYjhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3bZaYZ3iWlRtW7dKIEC/KR6HBTcOrwUs3Zqf1StHpjY=; b=lX35n+NW8q8QsPx8zGUJe4awpC5i1p6vbr/9Xnqd3F+CUXdKlDqJCd5yioR9lLsP2Qdf9NjuYUra8A9nqYn61KnRU9qrrPuEjDn4YcivohIhGLe/uHokcBVfryHufhW2jC2K0Mi8h68YBTZfO+MhGb54teQFy6UHRFcZuLP5uyFoZVfS88S13rXtYqFnEDaMQ0PwPUEKik9nxlcJ4iz1ANpbb0YrEi/FqI7ASeQCobDzg5qIJoGB7QCru2C6do9q+tjSdqQC9McQ640LqX0ZXuQ5TNm9NVK8Wav9pyzFx8lS1Bu4vn+wvULbTLc1JrPWr0bJ8fgYH7H6APcfIsloXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=durham.ac.uk; dmarc=pass action=none header.from=durham.ac.uk; dkim=pass header.d=durham.ac.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=durhamuniversity.onmicrosoft.com; s=selector2-durhamuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3bZaYZ3iWlRtW7dKIEC/KR6HBTcOrwUs3Zqf1StHpjY=; b=VnMtykoTTjZJKSTQdKx3Qd2w7EwHpilIkUZm6F2Tjrh35QxwTV23sUFvdo1aiokmw5orpUxn0xFYeSxVLF4kECCro6fpggbWrTY3Hbkl5CnJ1Tpq1X+bvGY7CPgikZtnsM3kXKrhuvVRjvi8GMlivTgND8yITkP3gQDt4JnHfJY= Authentication-Results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=durham.ac.uk; Received: from CWLP265MB1634.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:32::19) by CWLP265MB1027.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:2c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Tue, 30 Jun 2020 22:21:44 +0000 Received: from CWLP265MB1634.GBRP265.PROD.OUTLOOK.COM ([fe80::d4cb:ad6a:b891:13d8]) by CWLP265MB1634.GBRP265.PROD.OUTLOOK.COM ([fe80::d4cb:ad6a:b891:13d8%6]) with mapi id 15.20.3131.028; Tue, 30 Jun 2020 22:21:44 +0000 Date: Tue, 30 Jun 2020 23:21:36 +0100 (BST) From: Michael Young X-X-Sender: michael@austen3.home To: xen-devel@lists.xenproject.org Subject: Build problems in kdd.c with xen-4.14.0-rc4 Message-ID: Content-Type: text/plain; format=flowed; charset=US-ASCII X-ClientProxiedBy: LO2P265CA0440.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::20) To CWLP265MB1634.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:32::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from broadband.bt.com (2a00:23c4:921a:2100:1097:224c:243b:f186) by LO2P265CA0440.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Tue, 30 Jun 2020 22:21:43 +0000 X-X-Sender: michael@austen3.home X-Originating-IP: [2a00:23c4:921a:2100:1097:224c:243b:f186] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dd2cb3ee-4db0-425b-5ce0-08d81d43f839 X-MS-TrafficTypeDiagnostic: CWLP265MB1027: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:146; X-Forefront-PRVS: 0450A714CB X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0E2EzV2v3neoelojHGDN+wtn0xpFNNF07yTui7efBV4aSavbH2kGLZYLRMq+HPbd/dkrVyALI9UkRIi/R5WASvMZXB79Im0iu5z1KkxDOAQUtoD3uaOYNsL2HZjtFYRFs3bOfKYY6eX7Sj9LWMZEnu36aIszjmW62PhQHuh5djlyo084vrDdeXXJELSbk6Oh12Mffb8omXXYiOITIJQfEepBpKMFgRECnxQGsdBJiBFcw2lV+6fdm5Mex9OobXVJ3JsQ4lv5mSOiZOSx9P0/MnWzGtE2tOYMT7K0u18XuUdJoMX8GU/sbhxcChe1a/fP6nxreWgaOc6FE0lRuEh3BC3PsTEdQA8RgCnsMIOO5co/aN+1WAeTcMqT1LyoqNYjl28Il212dCwhnClB4k8Rhw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CWLP265MB1634.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(366004)(136003)(396003)(5660300002)(52116002)(6506007)(36756003)(6486002)(6666004)(186003)(16526019)(478600001)(966005)(2906002)(83380400001)(8936002)(86362001)(66556008)(9686003)(6512007)(6916009)(4326008)(4743002)(66946007)(316002)(8676002)(66476007)(786003); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: hmKWtnp1ytG5QZtNmb3ivyzJ4Fw83ilojBhFOpBTq6JydUTZOKYUqiu289mQ9MagQKz3iF7ODhGfe1UfS081BTUSweOc/jgd0jNl3AecSNxolGANxKLuNnAhOsFAScvqYMIAdn24rFLzvapCuviaqyzKKPy4JImDSmRw1XnPu6rNIKarsVCQd4x/+ZvqqeQjo5CScWaNBYpJ3K3fRZjepPtfbebFXPueR71Dx1JLQe75xnIyUc8QstbH/3LqKYgi+R+i9UPiD1CuwtcQPcMnLjv2CYgfKaG2CaeEle1jzIZiabRhI6Cev6iL1DMpGKsNJgU/OleQ/D+iGP2y6dgPRrsK6IjpBPFrPuD56UAVsouTNaoW8v58KycItvbCJ3mZSHe1LKjGggRQzQZNVh0ETTCGYupaa7/qcjTAlaCZuqY14pFY/s/a+p/8nOxlH9OC8L0uWYpE6AimT+I6KcYvIqYBG/oKsDHVlwr4jVUJMR9jcHQN46sqAGvZ9lYgImdk5nClNpLbMX3Fn5PUs3PuVhMc6VcIuj7A5wIe4J+0J9VfrV/jMbSPOik2iDAYT5+5 X-OriginatorOrg: durham.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: dd2cb3ee-4db0-425b-5ce0-08d81d43f839 X-MS-Exchange-CrossTenant-AuthSource: CWLP265MB1634.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2020 22:21:43.9813 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 7250d88b-4b68-4529-be44-d59a2d8a6f94 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: oUv4elOUcJg0NqUyzcIaFF2kPlB3LFYqtRPI2QKf/hfI7813L+jWrCmx5wzU/hn5nJvzPn736Go7NvlXDUFw1Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWLP265MB1027 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Tim Deegan Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" I get the following errors when trying to build xen-4.14.0-rc4 kdd.c: In function 'kdd_tx': kdd.c:754:15: error: array subscript 16 is above array bounds of 'uint8_t[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds] 754 | s->txb[len++] = 0xaa; | ~~~~~~^~~~~~~ kdd.c:82:17: note: while referencing 'txb' 82 | uint8_t txb[sizeof (kdd_hdr)]; /* Marshalling area for tx */ | ^~~ kdd.c: In function 'kdd_break': kdd.c:819:19: error: array subscript 16 is above array bounds of 'uint8_t[16]' {aka 'unsigned char[16]'} [-Werror=array-bounds] 819 | s->txb[sizeof (kdd_hdr) + i] = i; | ~~~~~~^~~~~~~~~~~~~~~~~~~~~~ kdd.c:82:17: note: while referencing 'txb' 82 | uint8_t txb[sizeof (kdd_hdr)]; /* Marshalling area for tx */ | ^~~ In file included from /usr/include/stdio.h:867, from kdd.c:36: In function 'vsnprintf', inlined from 'kdd_send_string' at kdd.c:791:11: /usr/include/bits/stdio2.h:80:10: error: '__builtin___vsnprintf_chk' specified bound 65519 exceeds destination size 0 [-Werror=stringop-overflow=] 80 | return __builtin___vsnprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 81 | __bos (__s), __fmt, __ap); | ~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[4]: *** [/builddir/build/BUILD/xen-4.14.0-rc4/tools/debugger/kdd/../../../tools/Rules.mk:216: kdd.o] Error 1 The first two array-bounds errors seem to be a result of the kdd: stop using [0] arrays to access packet contents patch at http://xenbits.xenproject.org/gitweb/?p=xen.git;a=commit;h=3471cafbdda35eacf04670881dd2aee2558b4f08 which reduced the size of txb from sizeof (kdd_hdr) + 65536 to sizeof (kdd_hdr) which means the code now tries to write beyond the end of txb in both cases. Michael Young From xen-devel-bounces@lists.xenproject.org Tue Jun 30 22:25:18 2020 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 30 Jun 2020 22:25:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqOgl-0007uo-2o; Tue, 30 Jun 2020 22:25:15 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqOgi-0007uI-Qf for xen-devel@lists.xenproject.org; Tue, 30 Jun 2020 22:25:12 +0000 X-Inumbo-ID: 8f694464-bb20-11ea-b7bb-bc764e2007e4 Received: from mail.xenproject.org (unknown [104.130.215.37]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 8f694464-bb20-11ea-b7bb-bc764e2007e4; Tue, 30 Jun 2020 22:25:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xenproject.org; s=20200302mail; h=Date:From:Subject:MIME-Version: Content-Transfer-Encoding:Content-Type:Message-ID:To:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ezpk0Pm+jddqnSmCKSDhcCsO9P9MEQZQSOEupR24LrM=; b=UYd2OlbE7L9qNQJL+TDIifqgT Dm7uFPX3Be6/pzlYoWoIFBCDzyoIcXwnrZlbS96nWDsbSkPIoXoFGRdRxqaSQodnej8VDunvd/EVR UH5OnnHKxZsFcPCxzIkyf9p7r5QcAl+UnPQ08EmrQVShxSkmTfeadKXu9/4kHQcsjvYUo=; Received: from host146.205.237.98.conversent.net ([205.237.98.146] helo=infra.test-lab.xenproject.org) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jqOgg-0002wx-6H; Tue, 30 Jun 2020 22:25:10 +0000 Received: from [172.16.144.3] (helo=osstest.test-lab.xenproject.org) by infra.test-lab.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jqOgf-0000Nw-TC; Tue, 30 Jun 2020 22:25:09 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.89) (envelope-from ) id 1jqOgf-0002Ed-Ru; Tue, 30 Jun 2020 22:25:09 +0000 To: xen-devel@lists.xenproject.org, osstest-admin@xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [xen-unstable test] 151473: regressions - FAIL X-Osstest-Failures: xen-unstable:test-amd64-amd64-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:regression xen-unstable:test-amd64-i386-xl-qemuu-ws16-amd64:windows-install:fail:regression xen-unstable:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemuu-win7-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemuu-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-amd64-i386-xl-pvshim:guest-start:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-seattle:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-thunderx:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-arm64-arm64-xl-xsm:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-arndale:saverestore-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-multivcpu:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-rtds:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-i386-xl-qemut-ws16-amd64:guest-stop:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-cubietruck:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit2:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-vhd:saverestore-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking xen-unstable:test-amd64-amd64-qemuu-nested-amd:debian-hvm-install/l1/l2:fail:nonblocking X-Osstest-Versions-This: xen=0e2e54966af556f4047c1048855c4a071028a32d X-Osstest-Versions-That: xen=da53345dd5ff7d3a34e83587fd375c0b7722f46c From: osstest service owner Date: Tue, 30 Jun 2020 22:25:09 +0000 X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" flight 151473 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/151473/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR. vs. 151461 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail REGR. vs. 151461 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 saverestore-support-check fail like 151461 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 151461 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 151461 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 151461 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 151461 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 151461 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 151461 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail like 151461 test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass test-armhf-armhf-xl 13 migrate-support-check fail never pass test-armhf-armhf-xl 14 saverestore-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass version targeted for testing: xen 0e2e54966af556f4047c1048855c4a071028a32d baseline version: xen da53345dd5ff7d3a34e83587fd375c0b7722f46c Last test of basis 151461 2020-06-29 19:39:16 Z 1 days Testing same since 151473 2020-06-30 08:47:12 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Roger Pau Monné jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops pass build-i386-pvops pass test-xtf-amd64-amd64-1 pass test-xtf-amd64-amd64-2 pass test-xtf-amd64-amd64-3 pass test-xtf-amd64-amd64-4 pass test-xtf-amd64-amd64-5 pass test-amd64-amd64-xl pass test-amd64-coresched-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-coresched-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm fail test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 pass test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine pass test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-livepatch pass test-amd64-i386-livepatch pass test-amd64-amd64-migrupgrade pass test-amd64-i386-migrupgrade pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu pass test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds pass test-arm64-arm64-xl-seattle pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-arm64-arm64-xl-thunderx pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. ------------------------------------------------------------ commit 0e2e54966af556f4047c1048855c4a071028a32d Author: Roger Pau Monné Date: Mon Jun 29 18:03:49 2020 +0200 mm: fix public declaration of struct xen_mem_acquire_resource XENMEM_acquire_resource and it's related structure is currently inside a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the hypervisor or the toolstack only. This is wrong as the hypercall is already being used by the Linux kernel at least, and as such needs to be public. Also switch the usage of uint64_aligned_t to plain uint64_t, as uint64_aligned_t is only to be used by the toolstack. Doing such change will reduce the size of the structure on 32bit x86 by 4bytes, since there will be no padding added after the frame_list handle. This is fine, as users of the previous layout will allocate 4bytes of padding that won't be read by Xen, and users of the new layout won't allocate those, which is also fine since Xen won't try to access them. Note that the structure already has compat handling, and such handling will take care of copying the right size (ie: minus the padding) when called from a 32bit x86 context. This is true for the compat code both before and after this patch, since the structures in the memory.h compat header are subject to a pragma pack(4), which already removed the trailing padding that would otherwise be introduced by the alignment of the frame field to 8 bytes. Fixes: 3f8f12281dd20 ('x86/mm: add HYPERVISOR_memory_op to acquire guest resources') Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich Release-acked-by: Paul Durrant (qemu changes not included)